Изменить

Поделиться через

Измерение устойчивости приложений Azure с помощью оценки SCI

Azure Monitor
Служба автоматизации Azure
Azure Logic Apps
Хранилище таблиц Azure
Power BI

Решение, описанное в этой статье, поможет вам создать модель устойчивости для приложений, размещенных в Azure. В модели используются прокси-серверы, которые со временем позволяют оценить влияние и эффективность приложения. Оценка называется оценкой углеродной интенсивности программного обеспечения (SCI). Он предоставляет базовые показатели для измерения изменений в выходных данных углерода приложения.

Архитектура

Схема модели устойчивости, которая оценивает влияние углерода приложения.

Скачайте файл Visio для этой архитектуры.

Поток данных

  1. Настройте источники данных приложения, которые будут использоваться для вычисления оценки SCI. Данные могут быть измерения выбросов, предоставляемые колонкой Сокращение выбросов углерода в портал Azure, или могут быть измерениями прокси-сервера из источников или систем, отличных от Майкрософт.
  2. Экспортируйте данные о выбросах углерода в озеро данных.
  3. Используйте обработчики событий, такие как Функции Azure или Azure Logic Apps, чтобы вычислить оценку SCI. Выходные данные — это объем углерода, генерируемого в граммах на единицу, где единица относится к коэффициенту масштабирования приложения или приближению к нему на основе прокси-серверов.
  4. Используйте такие технологии, как Функции Azure, Logic Apps или модули Runbook служба автоматизации Azure для активации формирования спроса на приложение или запуска предопределенного режима эко приложения.
  5. Используйте Power BI для создания отчетов и визуализации оценки и его изменения с течением времени.

Компоненты

  • Колонка Сокращение выбросов углерода в портал Azure предоставляет измерения выбросов углерода рабочих нагрузок Azure на уровне группы ресурсов.
  • API для устойчивого развития облака предоставляет базовые данные для оптимизации углерода. Его можно использовать для получения информации о выбросах вашей подписки.
  • Application Insights — это функция Azure Monitor, которая обеспечивает управление производительностью приложений (APM). Это поможет вам получить полезные сведения о том, как люди используют свое приложение. Эти знания можно использовать для принятия решений на основе данных о повышении эффективности приложения.
  • Хранилище BLOB-объектов Azure хранит данные о выбросах из оптимизации углерода Azure, из пользовательских вычислений или других прокси-серверов для выбросов.
  • Azure Data Lake — это централизованный репозиторий, который выполняет прием и хранение больших объемов данных в исходной форме. Затем данные можно обрабатывать и использовать в качестве основы для различных потребностей аналитики.
  • Azure Logic Apps позволяет создавать и запускать автоматизированные рабочие процессы без кода. С помощью визуального конструктора и выбора из предварительно созданных операций можно быстро создать рабочий процесс, который интегрирует источники прокси-сервера, хранилище данных и системы вычислений эффективности.
  • Функции Azure позволяет запускать небольшие единицы кода. Он автоматически масштабирует ресурсы по требованию и оплачивается только за фактическое время выполнения. Его можно использовать для вычисления устойчивости и хранения их в хранилище BLOB-объектов или озере данных.
  • служба автоматизации Azure обеспечивает автоматизацию процессов с помощью модулей Runbook. Модули Runbook можно использовать для реализации сложной логики с помощью кода PowerShell, который может повлиять на эффективность приложения. Эта служба также может добавить бизнес-ценность, уменьшая ошибки и операционные затраты.
  • Power BI позволяет преобразовать данные в аналитику и отчеты, которые предоставляют аналитические сведения в режиме реального времени.

Альтернативные варианты

Службы Azure, описанные в этой статье, можно заменить аналогичными службами. Чтобы увеличить плотность и использование существующих ресурсов, выполните вычисления с минимальным воздействием на инфраструктуру с помощью служб Azure или средств, которые уже развернуты в вашей среде:

  • Вы можете заменить панели мониторинга Power BI книгами Azure Monitor или службами Azure Managed Grafana.
  • Вы можете заменить Application Insights любым другим средством управления производительностью приложений (APM), таким как управление производительностью приложений Elasticsearch (APM) или OpenAPM.
  • Данные в виде таблиц или неструктурированных данных можно хранить в любой системе записей, таких как MySQL или MariaDB, или Azure Cosmos DB и MongoDB.
  • Если у вас есть работающее пространство Функции Azure или Logic Apps, вы можете регулярно выполнять вычисление из существующих развертываний.
  • Если ресурсы приложения распределяются по нескольким группам ресурсов, можно использовать теги для сопоставления данных о затратах и вычисления объема углерода, генерируемого приложением.

Подробности сценария

Эта архитектура предназначена для сбора данных оптимизации углерода из Azure и других источников, чтобы обеспечить комплексное представление воздействия приложения на окружающую среду. Данные собираются из оптимизации углерода Azure. Для сред, отличных от Azure, прокси-сервер используется для получения соответствующих метрик углерода. После консолидации данных вычисления SCI выполняются для оценки общего углеродного следа. Затем результаты хранятся в учетной записи служба хранилища Azure или озере данных для долгосрочного хранения, что позволяет анализировать бизнес-аналитику и исторические отчеты. Этот подход обеспечивает централизованное отслеживание влияния на выбросы углерода в различных инфраструктурах и поддерживает стратегические усилия по обеспечению устойчивости.

Информация о выбросах углерода частично собирается из колонки портал Azure Сокращение выбросов углерода и частично вычисляется по возможности через прокси-сервер.

Снимок экрана: колонка Сокращение выбросов углерода.

Важно использовать отдельную архитектуру для сбора данных оптимизации углерода Azure по двум ключевым причинам:

  • Данные оптимизации углерода Azure хранятся и отображаются только за последние двенадцать месяцев (в скользящее окно). Если требуется долгосрочное отслеживание углеродного следа, выделенная система обеспечивает хранение подробных исторических сведений.
  • Приложение может охватывать несколько инфраструктур, а Azure — только один компонент. Отдельная архитектура позволяет централизованно отслеживать влияние углерода во всех средах для обеспечения целостного представления и обеспечения более полной аналитики устойчивости.

Примечание.

Парниковые газы не состоят только из углекислого газа, и они не все имеют одинаковое влияние на окружающую среду. Например, одна тонна метана имеет тот же эффект нагрева, что и 80 тонн углекислого газа. В этой статье все нормализовано для эквивалентной меры CO2. Все ссылки на углерод относятся к эквиваленту CO2.

Источники данных

Как правило, следует создать формулу прокси с несколькими переменными. Метрики прокси-сервера, которые вы выбрали, должны представлять поведение и производительность приложения.

Эти метрики используются в этом примере:

  • Выбросы углерода инфраструктуры, извлекаемой из API выбросов углерода. Этот API является источником для Баланс выбросов углекислого газа и колонки Сокращение выбросов углерода в портал Azure. Данные доступны на уровне группы ресурсов, что упрощает отслеживание выбросов приложения.
  • Метрики производительности и масштабирования приложения, собранные из Application Insights:
    • Коэффициент масштабирования (вызовы API, запросы сервера или другая метрика) для приложения
    • Использование процессора
    • Использование памяти
    • Время отклика (отправка и получение)

Руководство по настройке Application Insights для получения необходимых метрик см. в разделе Application Insights для приложений ASP.NET Core.

В уравнение можно добавить другие переменные, например:

  • Пограничные службы и выбросы углерода инфраструктуры.
  • Время подключения пользователей, так как производство электроэнергии и спрос зависят от времени.
  • Любая другая метрика приложения, которая может рассказать о том, как его производительность изменяется с течением времени.

Создав это уравнение в оценку, которая также может отражать количество пользователей, вы создаете ближайшее приближение к оценке углерода. Эта оценка является вашим показателем для дальнейшего изменения и улучшения устойчивости приложения.

Затраты — это еще одно соображение, связанное с производительностью приложения. В большинстве случаев можно установить прямую корреляцию между эффективностью производительности и экономией углерода. Эта корреляция приводит к следующим предположениям:

  • Если производительность выше, но затраты одинаковы, вы оптимизированы для приложения и сократили выбросы углерода.
  • Если затраты сокращаются, но производительность одинакова, вы оптимизируете приложение и сократили выбросы углерода.
  • При увеличении производительности и затрат вы не оптимизировали приложение, и вы увеличили выбросы углерода.
  • Когда увеличение затрат, но производительность снижается или же, вы не оптимизируете приложение и увеличили выбросы углерода (или затраты на энергию выше, что также является причиной более высоких выбросов углерода).

Эта корреляция между оценкой SCI, затратами и производительностью приложения уникальна для каждого приложения и зависит от многих факторов. Собирая данные для этих трех переменных, можно создать алгоритм корреляции, позволяющий прогнозировать любой вариант трех переменных и принимать обоснованные решения по архитектуре и шаблонам приложений.

Вычисления

В описанном здесь сценарии невозможно сформировать дискретное вычисление для используемых прокси-серверов. Вместо этого данные, собранные из Баланс выбросов углекислого газа, обрабатываются в качестве отправной точки. Ниже приведен расчет базовых показателей SCI:

SCI = C*R

В этом уравнении:

  • C — это выбросы углерода для приложения. Это значение влияет на развертывание приложения в Azure. Например, если все ресурсы приложения находятся в одной группе ресурсов, C это выбросы углерода для этой группы ресурсов.

    Примечание.

    В настоящее время другие источники выбросов для приложения игнорируются, так как они зависят от архитектуры и поведения пограничных и пользователей. Если вы используете прокси-серверы для данных, вы можете рассмотреть эти источники на следующем шаге.

  • R — это коэффициент масштабирования для приложения. Это может быть число средних одновременных пользователей для периода времени, запросов API, веб-запросов или другой метрики. Это значение важно, так как оно приводит к оценке, которая учитывает общее влияние использования приложения, а не только на его место развертывания.

Период времени, конечно, является еще одним важным аспектом этого вычисления: выбросы углерода для любого устройства или системы, потребляемого энергией, зависят от времени, так как энергетическая сетка может иметь возобновляемые или альтернативные источники энергии (например, солнечная энергия) в некоторые времена, но не в других случаях. Поэтому важно начать с самого короткого периода времени, чтобы повысить точность. Например, можно начать с ежедневного или почасового вычисления.

API выбросов углерода в настоящее время предоставляет ежемесячную информацию о углероде на основе служб в подписке на уровне группы ресурсов. Используя предоставленный REST API, вы можете экспортировать данные о выбросах в озеро данных , в котором хранятся все данные устойчивости для приложения.

Хранилище данных

Вы должны хранить сведения о углеродном и углеродном прокси-сервере, собираемые в решении, которое можно подключить к панелям мониторинга или отчетам. Это позволяет визуализировать оценку углерода с течением времени и принимать обоснованные варианты. Чтобы повысить устойчивость и выровнять рекомендации azure Well-Architected Framework, рекомендуется использовать минимальную жизнеспособную систему. (Дополнительные сведения см. в разделе Рекомендации по проектированию данных и хранилища для устойчивых рабочих нагрузок на платформе Azure и приложений для устойчивых рабочих нагрузок в Azure.) Azure Data Lake Storage используется в этой архитектуре.

Корреляции данных

При начале сбора данных о углероде, производительности и стоимости приложения вы получите ценную информацию, которая позволяет создавать алгоритм корреляции, характерный для вашего приложения и предоставляющий рекомендации при планировании затрат, производительности и оптимизации углерода.

Дополнительные сведения см. в разделе "Выбор алгоритмов для Машинное обучение Azure".

Отображение данных

Вы можете отображать данные и вычисления различными способами, включая настраиваемые панели мониторинга Azure Monitor и простые панели мониторинга Power BI.

Что может активировать триггер оценки SCI?

После того как вы знаете свою оценку устойчивости, вы можете задаться вопросом, как вы можете улучшить его.

Если вы можете оценить влияние углерода приложения с помощью прокси-серверов, следующий шаг — сосредоточиться на определении действий, которые могут быть вызваны неблагоприятными условиями в оценке. Ниже приведены некоторые примеры следующих условий:

  • Производство энергии и спрос на все время высок и поэтому дорого производить.
  • Электричество недоступно. Это условие может быть вызвано стихийным бедствием или геополитическим конфликтом.
  • Внезапная недоступность пограничной инфраструктуры, вызванной проблемами с превышением потребления ресурсов или цепочкой поставок.

Когда можно определить точки сбоя, которые могут повлиять на приложение, вы можете решить, какие действия необходимо предпринять для обеспечения устойчивости приложения к пикам углерода.

Вы можете выполнить одно из следующих действий:

  • Примените грациозное снижение служб и функций приложения, как описано в документации по Well-Arcchitected Framework.

  • Создайте версию приложения в эко-режиме. Экологический режим — это более простая, меньшая, более дешевле, более устойчивая версия приложения, которая предлагает минимальные возможности. Вы можете вернуться к этой версии во время пиков выбросов углерода. Вы также можете просто обучить конечных пользователей использовать эко-версию по выбору. Вы можете предоставить "зеленую кнопку", которая позволяет людям использовать более чистый интерфейс, меньше графики и ограниченные функции в обмен на снижение выбросов углерода.

  • Если вы решили привлечь пользователей, вы создадите возможность для изменения культуры вместе с техническим: - Вы можете указать влияние выбора: "Используя эко-версию, вы экономите x объем углерода" или "приведя нашу оценку углерода к объему y". Вы можете понять поведение пользователей и изменить эко-версию, чтобы отразить их выбор. (Возможно, они используют 10% функций и являются идеальным пользователем эко-версии.) — Так как полная версия оптимизирована для выбросов, в идеале можно в конечном итоге объединить две версии.

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

Для дополнительной безопасности можно использовать конечные точки службы Azure виртуальная сеть для удаления общедоступного доступа к интернету к ресурсам службы Azure, разрешая трафик только из виртуальной сети.

С помощью этого подхода вы создадите виртуальную сеть в Azure и создадите конечные точки частной службы для служб Azure. В такие службы трафик будет поступать только из виртуальной сети. Вы также можете связаться с ними из локальной сети через шлюз.

Помните, что для перемещения данных из локальной среды в служба хранилища Azure необходимо разрешить общедоступные IP-адреса из локальной среды или Azure ExpressRoute. Дополнительные сведения см. в статье "Развертывание выделенных служб Azure в виртуальных сетях".

Общие рекомендации по проектированию безопасных решений см . в документации по безопасности Azure.

Оптимизация затрат

Оптимизация затрат заключается в сокращении ненужных расходов и повышении эффективности работы. Дополнительные сведения см. в разделе "Обзор основы оптимизации затрат".

Эту архитектуру можно развернуть с помощью нескольких альтернативных служб Azure. Оно было намеренно сохранено как минимум, чтобы сэкономить на затратах и выбросах углерода.

Хотя мы рекомендуем использовать эквивалентные службы, которые у вас уже есть в развертывании приложений, цены доступны для каждого компонента архитектуры:

Уровень производительности

Эффективность производительности — это возможность масштабирования рабочей нагрузки в соответствии с требованиями, заданными пользователями. Дополнительные сведения см. в разделе "Общие сведения о эффективности производительности".

Основная цель этой архитектуры — обеспечить оценку устойчивости приложений с помощью процесса, который оказывает минимальное влияние на затраты и углерод. Большинство компонентов — это платформа как услуга (PaaS) и бессерверные службы Azure, которые могут масштабироваться независимо на основе использования и трафика.

В этом сценарии интерфейс панели мониторинга и хранилища не предназначен для массового использования и консультаций. Если вы планируете предоставить его большому количеству пользователей, вы можете рассмотреть один из следующих вариантов:

  • Отделяйте извлеченные данные, преобразуя их и сохраняя их в другой системе.
  • Замените Data Lake Storage или хранилище таблиц Azure более масштабируемой структурой данных, например Azure Cosmos DB.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

  • Паола Эннис | Главный менеджер по проектированию взаимодействия с клиентами
  • Дэвиде Бедин | Старший архитектор облачных решений, инновации приложений

Другой участник:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

Эта статья соответствует принципам и методологии Green Software Foundation. Следующий шаг при создании более зеленого приложения — внедрение пакета SDK с поддержкой углерода в приложение, чтобы триггеры могли быть автоматизированы в режиме реального времени при выполнении конкретных условий углерода.

Рекомендации по оптимизации рабочих нагрузок Azure см . в руководстве по облачной рабочей нагрузке по устойчивости.