Multi-AZ (мультизональная) архитектура — что это и как работает

Multi-AZ означает развёртывание компонентов приложения в нескольких Availability Zones внутри одного региона. AZ — это физически изолированные дата-центры с независимой подачей питания и сетевой инфраструктурой, но с низкой задержкой между ними. Цель — защититься от отказа одной зоны.

Как это делается на практике:

• Compute: инстансы/под-копии приложения в нескольких AZ; авто-скейлинг группы распределены по AZ.

• Балансировка: региональный load balancer распределяет трафик по AZ и делает health checks.

• Хранение: блочное хранилище часто привязано к AZ → используют репликацию/snapshots или распределённые файловые/объектные системы с multi-AZ репликацией.

• База данных: варианты — synchronous multi-AZ репликация с автоматическим failover (active-passive) или асинхронные реплики для чтения (active-active для чтения).

• Состояние: приложения проектируют stateless или выносят состояние в разделяемые сервисы (cache, DB, object storage), доступные из всех AZ.

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

Multi-region архитектура — что это и как работает

Multi-region — развёртывание в нескольких географически разнесённых регионах. Используется для защиты от региональных outage, уменьшения сетевой задержки для глобальных пользователей и для соответствия требованиям локального хранения данных.

Ключевые паттерны:

• Active-Passive (primary в одном регионе, standby в другом): асинхронная репликация, переключение через DNS/GSLB или manual failover. Низкие требования к согласованности, но RPO > 0.

• Active-Active: оба региона обрабатывают трафик; нужна глобальная маршрутизация и механизм разрешения конфликтов/консистентности (multi-master DB или application-level merging). Подходит, если приложение спроектировано на eventual consistency.

• Read-replica pattern: первичный регион для записей, удалённые регионы обслуживают чтения (меньше записи → локальная скорость чтения).

Компоненты: глобальный DNS/traffic manager с health checks, CDN для статики, кэширование на месте, cross-region репликация БД/объектов, синхронизация секретов и конфигурации.

Особенности и трейн-оффы:

• Латентность и стоимость: межрегиональная репликация дороже и медленнее; egress-трафик между регионами стоит денег.

• Согласованность: чаще используется асинхронная репликация → возможна потеря последних транзакций (RPO). Для сильной консистентности нужны распределённые БД с высокой стоимостью/сложностью.

• Операционная сложность: тестирование failover, синхронизация конфигураций, сложные runbooks.

Когда что выбирать

• Multi-AZ — базовый минимум для HA внутри региона; обязательна для production-кластера.

• Multi-region — когда нужно защититься от регионального катастрофа, обеспечить низкую задержку глобальным пользователям или удовлетворить требования соответствия/локализации данных.

Практические рекомендации и лучшие практики

• Делайте приложения stateless; сессии — в распределённом store (Redis с репликацией/пersistence).

• Для RDB: рассматривайте read-replicas в других регионах и регулярные тесты failover; для критичных данных — multi-master или специализированные глобальные БД.

• Используйте глобальный load balancing / DNS с health checks и low TTL для быстрого переключения; учитывайте DNS-caching при планировании RTO.

• Кеширование у границы (CDN) и локальные кэши в каждом регионе для снижения межрегионального трафика.

• Автоматизируйте репликацию конфигураций и секретов; применяйте IaC и CI/CD для синхронного развёртывания.

• Тестируйте DR: симулируйте падение AZ и целого региона; прогоняйте recovery drills и измеряйте RTO/RPO.

• Планируйте бюджет: multi-region увеличивает расходы (дублирование ресурсов, egress).

Операционные аспекты

• Документируйте runbooks для автоматического и ручного failover.

• Мониторьте latency, replication lag, error rates и строите алерты по деградации.

• Управляйте данными о соответствии (data residency) и шифрованием при репликации.

Задачи проектирования multi-AZ vs multi-region сводятся к балансировке требований к доступности, латентности, консистентности, стоимости и операционной сложности.