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

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

Архитектура

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

Поток данных

1. Настройте источники данных приложения, используемые для вычисления оценки SCI, а также операционные данные, такие как затраты и производительность. Данные могут быть измерения выбросов из API службы оптимизации углерода Azure, прокси-измерения из источников, отличных от Майкрософт, или сочетание обоих.

2. Хранилище данных собирает и хранит все точки данных, например экспортированные данные о выбросах.

3. Используйте обработчики событий, такие как Функции Azure или Azure Logic Apps, для вычисления оценки SCI и связанных метрик использования рабочей нагрузки. Например, объем углерода, выбрасываемого в атмосферу в граммах на единицу, где единица относится к коэффициенту масштабирования приложения или является приблизительной оценкой на основе аналогичных показателей.

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

5. Используйте Power BI для создания отчетов и визуализации оценки и ее изменения с течением времени и использования. Вы можете отслеживать оценку SCI и сравнивать производительность и затраты относительно оценки SCI.

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

Компоненты

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

• API Microsoft Cloud для устойчивого развития — это служба данных об устойчивости и выбросах. Он предоставляет базовые данные для углеродной оптимизации и получает сведения о выбросах, связанных с подпиской. В этой архитектуре API предоставляет базовые данные о выбросах, которые дополняют оптимизацию углерода Azure.

• Application Insights — это функция Azure Monitor, которая обеспечивает управление производительностью приложений (APM). Это помогает понять использование приложений для принятия решений на основе данных для повышения эффективности. В этой архитектуре он предоставляет ключевой источник данных для использования рабочей нагрузки и производительности. Эти данные помогают измерять эффективность как функцию работы, выполняемой относительно затрат на углерод.

• Azure Data Lake Storage — это централизованный репозиторий, который обрабатывает и сохраняет большие объемы данных в исходной форме для обработки и аналитики. В этой архитектуре хранятся необработанные данные моментального снимка для вычисления и создания отчетов о производительности рабочей нагрузки.

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

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

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

• Power BI — это платформа бизнес-аналитики и визуализации. Он превращает данные в аналитику и отчеты для получения информации в режиме реального времени. В этой архитектуре она предоставляет панели мониторинга для заинтересованных лиц для оценки целей устойчивости.

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

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

• Замените панели мониторинга Power BI рабочими книгами Azure Monitor или Azure Managed Grafana.

• Замените Application Insights другим средством APM, например Elasticsearch APM или OpenAPM.

• Сохраняйте табличные или неструктурированные прокси-данные в любой системе учета, такие как База данных Azure для MySQL или Azure Cosmos DB для NoSQL.

• Запустите вычисления из существующих развертываний Azure Functions или Logic Apps, если у вас развернуты эти службы.

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

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

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

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

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

• Оптимизация выбросов углерода Azure хранит данные в течение 12 месяцев. Выделенная система обеспечивает хранение исторических сведений для долгосрочного отслеживания.

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

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

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

Анализ отчетов и тенденций

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

Агрегированные данные из Microsoft Cost Management и Azure Monitor позволяют сравнить оценку SCI с результатом работы и денежными затратами.

Осведомленность о углеродных выбросах среды выполнения

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

• Ватт Тайм и карты электроэнергии — это api, отличные от Майкрософт, которые предоставляют данные углеродной интенсивности (I) в реальном времени для локальной сети питания. Так как Azure не публикует данные об углеродной интенсивности центров обработки данных в режиме реального времени, стандартным прокси считается интенсивность местной электросети.

• Application Insights собирает метрики производительности и масштабирования в режиме реального времени для вычисления функциональной единицы (R) и оценки потребления энергии (E):

  • Коэффициент масштабирования (например, вызовы API или активные пользователи)
  • Использование ЦП и памяти
  • Время ответа

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

Попробуйте добавить в уравнение другие переменные, например следующие примеры:

• Граничные сервисы и выбросы углерода инфраструктуры
• Прокси-серверы на основе профилей устройств пользователей
• Время подключения (так как производство электроэнергии и спрос меняются с течением времени)
• Другие метрики приложений, указывающие на изменения производительности

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

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

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

• Снижение затрат на ту же производительность означает, что приложение оптимизировано, а выбросы углерода сокращаются.

• Более высокая производительность в сочетании с более высокими затратами означает, что приложение не оптимизировано и выбросы углерода увеличились.

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

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

Вычисления

Вычислите оценку SCI с помощью следующей формулы, которая представляет частоту выбросов углерода на единицу:

SCI = ((E * I) + M) per R

В этом уравнении используются следующие переменные:

• E — это энергия , потребляемая системой программного обеспечения. Он измеряется в киловатт-часах (kWh).

• I — это интенсивность углерода источника энергии. Он измеряется в граммах эквивалента углекислого газа на киловатт-час (gCO2e/kWh). Это значение зависит от расположения и времени дня.

• M — это воплощенный углерод оборудования. Он представляет собой углерод, который производители, транспортировщики и утилизаторы выделяют во время производства, транспортировки и утилизации оборудования. Программное обеспечение выделяет это статическое значение на основе его доли использования и срока службы.

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

Период времени является важной частью этого вычисления. Интенсивность углерода (I) зависит от нескольких факторов. К этим факторам относятся энергетический набор, изменения погоды, требования к операциям с сеткой, такие как диспетчеризация и сокращение. Для принятия эффективных решений, относящихся к углероду, требуются данные в режиме реального времени или почти в режиме реального времени (ежечасно или реже) из API, отличных от Майкрософт.

Оптимизация углерода Azure предоставляет ежемесячные агрегированные данные о углероде для ресурсов. Эти данные можно использовать для следующих сценариев:

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

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

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

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

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

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

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

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

Оценки SCI и триггеры измерения в режиме реального времени

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

Углеродная рабочая нагрузка реагирует на неблагоприятные условия реального времени. Обычно триггеры среды выполнения используются при попытках оптимизировать компонент углеродной интенсивности (I). Примеры включают следующие сценарии:

• Высокая добыча энергии и спрос, что делает энергию дорогой

• Недоступное электричество из-за стихийных бедствий или геополитических конфликтов

• Внезапная недоступность пограничной инфраструктуры из-за проблем с избыточностью ресурсов или цепочкой поставок

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

• Применяйте плавную деградацию сервисов и функций приложения.

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

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

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

  • Укажите влияние выбора, заявив, как это влияет на экономию углерода или оценку углерода. Например, эко-версия может сэкономить x количество углерода или довести ваш углеродный балл до y количества.

  • Изучите поведение пользователя и измените эко-версию, чтобы отразить их выбор.

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

  Подсказка

  Центр обновления Windows является примером оптимизации среды выполнения. Он использует API с поддержкой углерода для планирования обновлений. Вместо немедленного скачивания обновлений он ждет момента, когда углеродоемкость местной сети (I) низка. Этот подход эффективно снижает объем углеродного следа процесса обновления, не увеличивая общее потребление энергии.

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

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

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

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

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

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

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

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

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

• Цены на Application Insights
• Цены на Logic Apps
• Цены на функции
• Цены на автоматизацию

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

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

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

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

• Отделяйте извлеченные данные путем преобразования и хранения данных в другой системе.

• Замените Data Lake Storage масштабируемой альтернативой, например Azure Cosmos DB для NoSQL.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

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

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

• Чад Киттель | Главный инженер по программному обеспечению, шаблоны и практики Azure

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

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

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

Связанные ресурсы

• Выбор технологии аналитики данных и отчетов в Azure
• Хранение и аналитика данных