Выберите схему доступности между зонами и регионами

Начните с операции пользователя

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

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

Для иллюстрации: доступность по времени 99,9% допускает 43,2 минуты недоступности за месяц из 30 дней. У SLO по запросам другой знаменатель. Ни один из этих показателей не определяет допустимую потерю данных и не гарантирует максимальную длительность отдельного простоя.

Разберитесь в границах отказов

Зона доступности AWS (Availability Zone, AZ) — изолированная инфраструктурная зона внутри региона (Region). Регион содержит несколько AZ. Multi-region схема распределяет компоненты нагрузки между регионами. У других поставщиков свои границы и поведение сервисов. Изучите выбранный сервис.

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

Проследите полный путь запроса

Рассмотрим вымышленный сервис бронирования. Веб-реплики работают в двух AZ. Обе используют одну базу данных и один исходящий gateway в AZ A. Gateway нужен для обращения к поставщику платежей.

При отказе AZ A веб-реплика в AZ B может оставаться исправной, а бронирование — не работать. Команда должна оценить базу данных, сетевой путь, сервис идентификации, платёжную зависимость и маршрутизацию. Изучите фактический режим управляемой базы данных: репликация, failover и поведение чтения зависят от продукта и конфигурации.

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

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

Решите, устранит ли проблему ещё один регион

Работа в нескольких регионах добавляет передачу данных, дублирующие ресурсы, координацию развёртываний и эксплуатационную работу. Active/passive поддерживает одну среду в готовности принять трафик. В active/active трафик обслуживает больше одной среды. Требования к готовности и поведению данных различаются.

Для сервиса бронирования параллельная запись вызывает вопрос: могут ли два региона продать одно и то же место? Определите, кто принимает окончательное решение о бронировании и что происходит при прерывании репликации. «Реплицировать базу данных» — неполный ответ.

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

Свяжите доступность с восстановлением

HA обрабатывает определённые отказы во время работы. Disaster recovery восстанавливает пригодный к использованию сервис и его данные после нарушающего работу события. Multi-region сервису всё равно нужен план восстановления после удаления или повреждения данных.

Документируйте выбранные сценарии отказов и те сценарии, которые бизнес принимает как риск. Согласованно обновляйте тесты и определения инфраструктуры при изменении приложения. Продолжите с урока о RTO, RPO и disaster recovery.