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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Важно!

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

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

• Определите и проверьте цели точки восстановления (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 с большим объемом памяти. Как правило, чтобы сократить ненужные затраты на управление, избегайте развертывания большого количества пулов узлов.

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

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

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

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

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

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

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

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

Обновления

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

• Подпишитесь на общедоступную стратегию развития AKS и заметки о выпуске на 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. Аналитика контейнеров в Monitor обеспечивает подключение, включает встроенные возможности мониторинга и предоставляет более сложные возможности благодаря встроенной поддержке Prometheus.

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

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

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

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

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

Примечание

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

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

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

Для сценариев рабочей нагрузки на основе веб-приложений и на основе API Служба приложений может быть возможной альтернативой AKS. Она предоставляет платформу контейнеров с низким уровнем трения без сложностей Kubernetes. Полный набор рекомендаций см. в статье Вопросы надежности для Служба приложений и операционной эффективности для Служба приложений.

надежность;

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

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

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

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

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

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

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

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

Мониторинг

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

• Журналы диагностики можно использовать для приема журналов уровня приложения и платформы в Log Analytics, службе хранилища Azure или стороннем средстве с помощью Центры событий Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

надежность;

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

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

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

Блокировка образа

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

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

Изображения с тегами

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

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

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

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

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

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

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

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

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

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

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

Рекомендации и рекомендации по проектированию для Функции Azure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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