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

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

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

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

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

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

Внимание

Эта статья является частью серии жизненно важных рабочих нагрузок в рамках Azure Well-Architected Framework. Если вы не знакомы с этой серией, мы рекомендуем начать с Что такое критически важная рабочая нагрузка?.

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

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

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

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

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

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

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

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

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

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

• Региональные и зональные возможности. Не все службы и возможности доступны в каждом регионе 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) или кэширование на границе, чтобы обеспечить оптимальную сетевую задержку для распределенных баз пользователей. Дополнительные сведения см. в разделах глобальная маршрутизация трафика, доставка приложений и кэширование и доставка статического контента.

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

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

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

Внимание

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

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

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

• Мониторинг. Службам мониторинга может быть трудно получить доступ к приложениям, которые находятся в контейнерах. Обычно требуется стороннее программное обеспечение для сбора и хранения индикаторов состояния контейнера, таких как использование ЦП или ОЗУ.

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

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

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

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

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

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

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

• Храните образы контейнеров в Реестре контейнеров Azure. Используйте георепликацию для репликации образов контейнеров во всех регионах. Включите Microsoft Defender для реестров контейнеров, чтобы обеспечить сканирование уязвимостей для образов контейнеров. Убедитесь, что доступ к реестру управляется идентификатором Microsoft Entra.

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

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

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

Внимание

Служба Azure Kubernetes (AKS) и контейнерные приложения Azure должны быть одними из ваших первых вариантов для управления контейнерами в зависимости от ваших потребностей. Хотя служба приложений Azure не является оркестратором, как удобная в использовании платформа контейнеров, она по-прежнему является подходящей альтернативой AKS.

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

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

Внимание

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

Надежность

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

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

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

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

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

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

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

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

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

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

Изоляция

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

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

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

• Оцените требования к сходству и антисходству приложений и настройте соответствующее совместное размещение контейнеров на узлах.

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

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

• Примените рекомендации по настройке, представленные в стандартных правилах безопасности для AKS.

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

• Используйте управляемые удостоверения вместо субъектов-служб, чтобы избежать управления и смены учетных данных. Вы можете добавить управляемые удостоверения на уровне кластера. На уровне pod можно использовать управляемые удостоверения с помощью Идентификация рабочей нагрузки Microsoft Entra.

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

Обновления

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

• Подпишитесь на общедоступную <a href="https://aka.ms/aks/roadmap" data-linktype="external">дорожную карту AKS и <a href="https://aka.ms/aks/releasenotes" data-linktype="external">заметки о выпусках на GitHub, чтобы оставаться в курсе предстоящих изменений, улучшений и, что самое важное, выпусков и устаревания версий Kubernetes.

• Примените руководство, приведенное в контрольном списке AKS, чтобы обеспечить соответствие лучшим практикам.

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

Сеть

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

Определите приоритет использования Azure CNI после оценки требований к сети и размера кластера. Azure CNI позволяет использовать сетевые политики Azure или Calico для управления трафиком внутри кластера.

Наблюдение

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

• Используйте Azure Monitor и Application Insights для сбора метрик, журналов и данных диагностики в ресурсов AKS для устранения неполадок.

• Включите и просмотрите журналы ресурсов Kubernetes.

• Настройте метрики Prometheus в Azure Monitor. Аналитика контейнеров в Мониторе обеспечивает подключение, обеспечивает возможности мониторинга вне поля и обеспечивает более расширенные возможности с помощью встроенной поддержки Prometheus.

Система управления

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

• Контролируйте, какие функции предоставляются pod, и определяйте, противоречит ли выполнение политике, с помощью Azure Policy. Этот доступ определяется с помощью встроенных политик, которые предоставляет надстройка Azure Policy для AKS.

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

• Используйте дополнение Политика Azure для AKS для управления функциями podов, такими как привилегии корня, и запрета podов, которые не соответствуют политике.

Примечание.

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

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

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

Для сценариев нагрузок на основе веб и API, App Service может быть альтернативой AKS. Она предоставляет платформу контейнеров с низким уровнем трения без сложности Kubernetes. Полный набор рекомендаций см. в статьях "Рекомендации по надежности для службы приложений" и "Операционное совершенство для службы приложений".

Надежность

Оцените использование портов TCP и SNAT. TCP-подключения используются для всех исходящих подключений. Порты SNAT используются для исходящих подключений к общедоступным IP-адресам. Исчерпание портов SNAT — это распространенный сценарий сбоя. Эту проблему следует прогнозировать путем нагрузочного тестирования при использовании Диагностика Azure для мониторинга портов. Если возникают ошибки SNAT, необходимо выполнить масштабирование через большее количество или более крупных рабочих узлов, или внедрить методы написания кода, способствующие сохранению и повторному использованию портов SNAT. Примеры методов написания кода, которые можно использовать, включают пул подключений и отложенную загрузку ресурсов.

Исчерпание TCP-порта — это еще один сценарий сбоя. Происходит, когда количество исходящих подключений из заданного рабочего узла превышает емкость. Количество доступных TCP-портов зависит от размера рабочей роли. См. рекомендации в разделе "Порты TCP и SNAT".

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

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

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

• Помните, что в App Service существует мягкое, обратимое ограничение на количество экземпляров в плане службы приложений.

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

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

Наблюдение

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

• Вы можете использовать диагностическую регистрацию для принятия журналов уровня приложения и платформы в Log Analytics, Azure Хранилище или сторонний инструмент через Azure Event Hubs.

• Мониторинг производительности приложений с помощью Application Insights предоставляет подробные сведения о производительности приложений.

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

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

Развертывание

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

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

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

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

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

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

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

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

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

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

• Убедитесь, что соглашение об уровне обслуживания для общедоступного реестра соответствует вашим целям надежности и безопасности. Обратите особое внимание на ограничения регулирования для вариантов использования, зависящих от Docker Hub.

• Приоритезируйте Реестр контейнеров Azure для размещения образов контейнеров.

Соображения и рекомендации по проектированию контейнерной регистрации Azure

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

Надежность

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

В регионах Azure с поддержкой зон доступности, уровень Premium реестра контейнеров обеспечивает резервирование зон для защиты от зональных сбоев. Уровень "Премиум" также поддерживает частные конечные точки , чтобы предотвратить несанкционированный доступ к реестру, что может привести к проблемам надежности.

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

Блокировка изображений

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

Если вы хотите защитить экземпляр реестра контейнеров от удаления, используйте блокировки ресурсов.

Помеченные изображения

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

Управление удостоверениями и доступом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Необходимо использовать средства сканирования кода в коде Azure Functions и интегрировать эти средства с конвейерами CI/CD.

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Платформа данных