Критически важная архитектура в Azure

Azure Front Door
Реестр контейнеров Azure
Служба Azure Kubernetes (AKS)
Управление доступом на основе ролей в Azure

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

Основные стратегии проектирования

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

Критически важные рабочие нагрузки обычно нацелены на SLO 99,99% или выше, что соответствует разрешённому ежегодному простоя в 52 минуты и 35 секунд. Поэтому все охватываемые решения по проектированию предназначены для достижения этого целевого SLO.

Это важно

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

  • Избыточность в слоях

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

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

    • Выберите ресурсы, поддерживающие глобальное распределение.

      См. Well-Architected критически важные рабочие нагрузки: глобальное распределение.

  • Метки развертывания

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

    См. Well-Architected критически важные рабочие нагрузки: архитектура единиц масштабирования.

  • Надежные и повторяемые развертывания

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

    • Реализуйте конвейеры развертывания с нулевым простоем (синее/зеленое). Конвейеры сборки и выпуска должны быть полностью автоматизированы для развертывания меток в виде одной операционной единицы с использованием синих и зеленых развертываний с применением непрерывной проверки.

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

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

    См. Well-Architected критически важные рабочие нагрузки: развертывание и тестирование.

  • Анализ деятельности

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

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

      Ознакомьтесь с Well-Architected критически важными рабочими нагрузками: моделирование состояния.

Области проектирования

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

Область проектирования Описание
Платформа приложений Варианты и способы устранения рисков инфраструктуры для потенциальных случаев сбоя.
конструктор приложений Шаблоны проектирования, позволяющие масштабировать и обрабатывать ошибки.
Сеть и подключение Рекомендации по маршрутизации входящего трафика на метки.
Платформа данных Выбор технологий хранилища данных, основывающийся на оценке характеристик необходимых объемов, скоростей, разнообразия и достоверности.
Развертывание и тестирование Стратегии для конвейеров CI/CD и рекомендаций по автоматизации с включенными сценариями тестирования, такими как синхронизированное тестирование нагрузки и тестирование внедрения сбоев (хаос).
Моделирование работоспособности Анализ влияния на клиента и корреляция мониторинга для определения общей работоспособности приложения в аспектах наблюдаемости.
Безопасность Устранение векторов атак с помощью модели Microsoft Zero Trust.
Операционные процедуры Процессы, связанные с развертыванием, управлением ключами, исправлением и обновлениями.

Дальнейшие действия

Критически важный: платформа приложений