Методология проектирования для устойчивых рабочих нагрузок в Azure
Для создания устойчивого приложения на любой облачной платформе требуется технический опыт и понимание принципов устойчивого развития в целом и для конкретной облачной платформы.
Эта методология проектирования направлена на то, чтобы помочь получить представление о создании более углеродно-эффективных решений, измерении углеродного воздействия и, в конечном счете, сокращении ненужного потребления энергии и выбросов.
1. Проектирование в соответствии с бизнес-требованиями
К предприятиям во всем мире предъявляют разные требования. Следует ожидать, что рекомендации по обзору и проектированию, предоставляемые этой методологией проектирования, приведут к различным решениям по проектированию и компромиссам для различных сценариев и организаций.
Определите бизнес-требования и приоритеты, а затем изучите методологии проектирования в соответствии с этими требованиями.
2. Оценка областей проектирования с использованием принципов проектирования
Ознакомьтесь с принципами проектирования устойчивого развития и областями проектирования ниже для рабочих нагрузок устойчивости.
Решения, принятые в каждой области проектирования, будут отражены в других областях проектирования. Изучите рекомендации и рекомендации в каждой области проектирования, чтобы понять последствия и влияние, а также все известные компромиссы.
Области проектирования:
- Проектирование приложений
- Платформа приложений
- Развертывание и тестирование
- Операционные процедуры
- Хранилище
- Сеть и подключение
- Безопасность
3. Понимание выбросов
Чтобы снизить выбросы, необходимо понять, как измерить усилия по обеспечению устойчивости.
Кратко о областях выбросов
В корпорации Майкрософт мы сегментируем выбросы парниковых газов (ПГ) на три категории в соответствии с Протоколом по парниковым газам.
- Выбросы в области 1: прямые выбросы, создаваемые вашей деятельностью.
- Выбросы в области 2: косвенные выбросы, которые возникают в результате производства электроэнергии или тепла, которое вы используете.
- Выбросы в области 3: косвенные выбросы от всех других видов деятельности, в которые вы участвуете. Для бизнеса эти выбросы в области 3 могут быть обширными. Они должны учитываться по всей цепочке поставок, материалов в зданиях, рабочих поездок сотрудников и жизненного цикла его продукции (включая электроэнергию, потребляемую клиентами при использовании продуктов). Выбросы в области 3 компании часто гораздо важнее, чем выбросы в области 1 и 2 вместе взятые.
Как клиент, контекст выбросов в области 3 может быть конфигурацией сети и доставкой, энергопотреблением и устройствами за пределами центра обработки данных. Если приложение использует избыточную пропускную способность или размер пакета, это будет влиять с момента выхода трафика из центра обработки данных через различные прыжки в Интернете, вплоть до устройства конечного пользователя. Таким образом, снижение пропускной способности сети может оказать значительное влияние на всю цепочку доставки. Те же рекомендации относятся к вычислительным ресурсам, хранилищу данных, решениям платформы приложений, проектированию приложений и т. д.
Дополнительные сведения и определения см. в техническом документе по методологии области 3 Azure, опубликованном в 2021 г.
Измерение и отслеживание влияния углерода
Корпорация Майкрософт согласуется с Green Software Foundation, ответственной за создание спецификации Software Carbon Intensity (SCI).
Для измерения углеродного воздействия приложения GSF предоставил методологию оценки под названием SCI, рассчитанную следующим образом:
SCI = ((E*I)+M) per R
Где:
E
= энергия, потребляемая программной системой. Измеряется в кВт*ч.I
= предельные выбросы углерода на основе местоположения. Выбросы углерода на кВт*ч энергии, гCO2/кВт*ч.M
= воплощенные выбросы программной системы. Углерод, который испускается через оборудование, на котором работает программное обеспечение.R
= функциональная единица, которая представляет собой способ масштабирования приложения; на дополнительного пользователя, на вызов API, на службу и т. д.
Учитывая эти знания, важно учитывать не только инфраструктуру приложений и оборудование, но и пользовательские устройства и масштабируемость приложений, так как это может значительно изменить воздействие на окружающую среду.
Ознакомьтесь с полной спецификацией SCI на сайте GitHub.
Отслеживание углерода и отчетность с помощью Баланс выбросов углекислого газа
Корпорация Майкрософт предлагает Баланс выбросов углекислого газа для Azure и Microsoft 365, которая помогает измерять облачные выбросы и потенциал экономии углерода.
Мы рекомендуем использовать это средство для получения аналитических сведений и прозрачности, необходимых для понимания углеродного следа, а также для измерения и отслеживания выбросов с течением времени.
Скачайте Баланс выбросов углекислого газа приложение Power BI для Azure, чтобы приступить к работе.
Использование Microsoft Sustainability Manager
Клиенты , использующие Microsoft Cloud for Sustainability , могут использовать Microsoft Sustainability Manager. Это расширяемое решение объединяет аналитику данных и обеспечивает комплексное, интегрированное и автоматизированное управление устойчивостью для организаций на любом этапе их устойчивого развития. Она автоматизирует ручные процессы, позволяя организациям более эффективно регистрировать, сообщать и сокращать выбросы.
Использование прокси-решения для измерения выбросов
Одним из способов оценки выбросов углерода в результате рабочих нагрузок является проектирование архитектуры прокси-решения на основе модели SCI , как описано выше.
Определение прокси-серверов для приложений можно выполнять различными способами. Например, с помощью этих переменных:
- Любой известный выброс углерода в инфраструктуре
- Стоимость инфраструктуры
- Выбросы углерода в пограничных службах и инфраструктуре
- Число пользователей, одновременно использующих приложение.
- Метрики приложения для информирования о производительности с течением времени
Спроектируя уравнение с использованием указанных выше переменных, вы можете оценить показатель углерода (аппроксимацию), что поможет вам понять, создаете ли вы устойчивые решения.
Существует также аспект производительности приложения. Можно связать производительность с затратами и выбросами и предположить, что эта связь дает значение. С помощью этого отношения можно упростить представление следующим образом:
Производительность приложения | Стоимость приложения | Вероятный результат |
---|---|---|
Высокий | Без изменений | Оптимизированное приложение |
Высокий | Ниже | Оптимизированное приложение |
Без изменений или понижения | Выше | Согласно зеленым принципам, более высокая стоимость энергии может привести к более высоким выбросам углерода. Таким образом, можно предположить, что приложение создает ненужные выбросы углерода. |
Высокий | Высокий | Приложение может производить ненужный углерод |
Таким образом, при создании панели мониторинга оценки углерода можно использовать следующие прокси-серверы:
- Стоимость
- Производительность
- Выбросы углекислого газа в инфраструктуре (если известные или доступные)
- Использование с течением времени (запросы, пользователи, вызовы API и т. д.)
- Любые дополнительные измерения, относящиеся к приложению
4. Модель общей ответственности для обеспечения устойчивости
Сокращение выбросов является общей ответственностью между поставщиком облачных служб и клиентом при проектировании и развертывании приложений на платформе.
Способы сокращения выбросов
Сокращение выбросов углерода может произойти с помощью трех возможных решений:
- Нейтрализация углерода; компенсация выбросов углерода
- Избегание углерода; не испускает углерод, в первую очередь
- Удаление углерода; вычитание углерода из атмосферы
Цель зеленого программного обеспечения заключается в том, чтобы избежать ненужных выбросов в первую очередь, поэтому активно работает в направлении более устойчивого будущего. Кроме того, удаление углерода является предпочтительной целью удаления выбросов из нашей атмосферы.
Корпорация Майкрософт стремится к углероду к 2030 году, а к 2050 году удалила весь углерод , который компания выбрасывала с момента ее основания в 1975 году.
Совместная ответственность
Корпорация Майкрософт как поставщик облачных служб отвечает за центры обработки данных, в котором размещаются ваши приложения.
Однако развертывание приложения в облаке Майкрософт не делает его устойчивым автоматически, даже если центры обработки данных оптимизированы для устойчивости. Приложения, которые не оптимизированы, по-прежнему могут испускать больше углерода, чем необходимо.
Рассмотрим пример.
Вы развертываете приложение в службе Azure, но используете только 10 % выделенных ресурсов. Подготовленные ресурсы используются недостаточно, что в конечном счете приводит к ненужным выбросам.
Это поможет, если вы рассмотрите возможность масштабирования до соответствующего уровня ресурса (для обеспечения прав) или развертывания дополнительных приложений в одних и том же подготовленных ресурсах.
Мы рекомендуем сделать приложения более эффективными, чтобы максимально эффективно использовать емкость центра обработки данных. Устойчивость — это общая цель ответственности, которая должна объединить усилия поставщика облачных служб и клиентов в разработке и реализации приложений.
Дальнейшие действия
Ознакомьтесь с принципами проектирования для обеспечения устойчивости.
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе:Отправить и просмотреть отзыв по