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

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

• Нефункциональные требования к надежности, доступности, производительности и безопасности.
• Факторы принятия решений, такие как масштабируемость, стоимость, операбельность и сложность.

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

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

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

Глобальное распределение ресурсов платформы

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

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

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

Диаграмма, демонстрирующая критически важную архитектуру.

Для критически важных нагрузок следует однозначно предпочесть многорегиональную модель Active/Active. Дополнительные сведения см. в разделе "Глобальное распределение".

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

Рекомендации по проектированию

• Возможности региона и зоны. Не все службы и возможности доступны в каждом регионе Azure. Этот фактор может повлиять на выбор регионов. Также, зоны доступности недоступны в каждом регионе.

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

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

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

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

Рекомендации по проектированию

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

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

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

  Внимание

  Для сценариев, нацеленных на SLO, равный или превышающий 99,99%, рекомендуется как минимум три региона развёртывания. Вычислите составной SLO для всех пользовательских потоков. Убедитесь, что эти целевые объекты соответствуют целевым объектам бизнеса.

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

• Определите и проверьте цели точки восстановления (RPO) и цели времени восстановления (RTO).

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

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

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

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

Контейнеризация

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

Рекомендации по проектированию

• Мониторинг. Azure поддерживает современный мониторинг контейнеров с Azure Managed Prometheus и Azure Monitor для контейнеров. Подробные рекомендации по мониторингу см. в руководстве по проектированию мониторинга. Наиболее заметным подходом телеметрии приложений является OpenTelemetry.

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

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

Рекомендации по проектированию

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

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

• Сделайте контейнеры неизменяемыми и заменяемыми с короткими жизненными циклами.

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

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

Размещение контейнеров и оркестрация

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

• Дерево решений для вычислений
• Сравнение параметров контейнера

Рекомендации и аспекты проектирования для службы Azure Kubernetes

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

Надежность

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

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

Масштабируемость

Учитывайте ограничения масштабирования AKS, такие как количество узлов, пулов узлов на кластер и кластеры на подписку.

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

• Благодаря использованию Node Autoprovisioner (NAP), KEDA, Horizontal Pod Autoscaler (HPA) и Vertical Pod Autoscaler (VPA) можно добиться высокой плотности размещения приложений и быстрого масштабирования без потери стабильности для рабочих нагрузок, которые плохо переносят сбои.

Дополнительные сведения об изоляции, безопасности, обновлениях, сети и мониторинге для AKS см. в руководстве по службе Служба Azure Kubernetes.

Аспекты проектирования и рекомендации для Контейнеры приложений Azure

Контейнеры приложений Azure — это бессерверная платформа контейнеров, которая является сильной альтернативой AKS, если вам не нужен прямой доступ к API Kubernetes. Она устраняет необходимость в большинстве операций по управлению кластером, сохраняя при этом функции, на которые полагаются критически важные рабочие нагрузки:

• Встроенное автомасштабирование на основе KEDA, управляемое событиями, включая масштабирование до нуля для некритических потоков.
• Избыточность зоны доступности и развертывание на основе синей и зеленой версии для безопасных развертываний.
• Встроенная интеграция Dapr для вызова сервисов, управления состоянием и публикации/подписки между микросервисами.
• Интеграция виртуальной сети с частными конечными точками и управляемым удостоверением для сквозного подключения без пароля.

Реестр контейнеров

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

• Используйте уровень Premium и включите георепликацию для каждого региона развертывания, чтобы обеспечить избыточность и загрузки с низкой задержкой.
• Включите зональную избыточность там, где поддерживаются зоны доступности, и ограничьте доступ через частные конечные точки.
• Используйте аутентификацию Microsoft Entra и отключите учетную запись администратора; защитите реестр, используя блокировки ресурсов.
• Избегайте изменения тегов в рабочей среде и используйте блокировки образа и репозитория , чтобы предотвратить случайное удаление или перезапись.
• Реплицируйте критически важные общедоступные образы (например, из Docker Hub) в свой закрытый реестр, чтобы избежать ограничений скорости и рисков, связанных с доступностью внешних сервисов.

Бессерверные вычисления

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

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

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

• Azure API Management. Вы можете использовать Управление API для публикации, преобразования, обслуживания и мониторинга API с повышенной безопасностью, используя уровень потребления.

• Power Apps и Power Automate. Эти средства предоставляют возможности разработки с низким кодом или без кода с простой логикой рабочего процесса и интеграцией, которые можно настроить с помощью подключений в пользовательском интерфейсе.

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

В следующих разделах приведены рекомендации по проектированию и рекомендации по использованию Функции Azure и Logic Apps в качестве альтернативных платформ для некритических сценариев рабочих процессов.

Вопросы проектирования и рекомендации для функций Azure

Критически важные рабочие нагрузки имеют критически важные и некритичные системные потоки. Функции Azure — это жизнеспособный выбор для некритических потоков на основе событий с короткими выполнениями. Подробные инструкции см. в руководстве по службе "Функции".

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

Соображения и рекомендации по проектированию для Azure Logic Apps

Как и Функции Azure, Logic Apps использует встроенные триггеры для обработки на основе событий. Однако вместо развертывания кода приложения можно создавать приложения логики с помощью графического пользовательского интерфейса, который поддерживает такие блоки, как условные, циклы и другие конструкции.

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

Ограниченные миграции через IaaS

Многие приложения, имеющие локальные развертывания, используют технологии виртуализации и избыточное оборудование для обеспечения критически важных уровней надежности. Модернизации часто мешают бизнес-ограничения, которые не позволяют в полной мере соответствовать облачно-нативному базовому уровню — подходу к проектированию по принципу «северной звезды», рекомендуемому для критически важных нагрузок. Поэтому многие приложения используют поэтапный подход с первоначальными облачными развертываниями с помощью виртуализации и Azure Виртуальные машины в качестве основной модели размещения приложений. Использование виртуальных машин инфраструктуры как службы (IaaS) может потребоваться в определенных сценариях.

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

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

Рекомендации по проектированию

• Операционные затраты на использование виртуальных машин IaaS значительно выше, чем затраты на использование служб PaaS из-за требований к управлению виртуальными машинами и операционными системами. Управление виртуальными машинами требует частого развертывания пакетов программного обеспечения и обновлений.

• Azure предоставляет возможности для повышения доступности виртуальных машин:

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

Подробные инструкции по настройке Виртуальные машины Azure см. в руководстве по Виртуальные машины службе.

Рекомендации по проектированию

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

• Разверните три или более виртуальных машин в зонах доступности, чтобы достичь отказоустойчивости на уровне центра обработки данных.

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

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

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

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

• Защита от региональных сбоев путем развертывания виртуальных машин приложений в нескольких Azure регионах. Дополнительные сведения о проверке хаоса см. в разделе "Непрерывная проверка и тестирование". Рекомендации по маршрутизации трафика между активными регионами см. в разделе "Сеть" и "Подключение".

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

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

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

• Реализуйте эксперименты хаоса, чтобы внедрить ошибки приложений в компоненты виртуальных машин и наблюдать за устранением ошибок. Дополнительные сведения см. в разделе «Непрерывная проверка и тестирование».

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

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

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

Ознакомьтесь с рекомендациями по платформе данных.