Настройка Multi-Region Failover для глобального веб-приложения
Multi-region failover защищает от катастроф целого региона: отключения дата-центра AWS us-east-1, аварии на подводном кабеле, блокировки IP-адресов в конкретной стране. Это следующий уровень после одиночного server failover — сложнее, дороже, но необходим для приложений с пользователями по всему миру или жёсткими требованиями по доступности.
Стратегии развёртывания
Active-Passive. Основной регион обслуживает весь трафик. Резервный — горячий стендбай, данные реплицируются, но трафик не принимается. При сбое основного — Route 53 / Cloudflare переключает DNS.
Плюсы: проще в управлении, дешевле (резервный регион может работать на уменьшенной мощности). Минусы: RTO 1-5 минут, пользователи в резервном регионе получают повышенную латентность.
Active-Active. Оба (или все) региона обслуживают трафик одновременно. GeoDNS направляет пользователей к ближайшему региону. При сбое одного — трафик перераспределяется.
Плюсы: лучшая латентность глобально, RTO близок к нулю для пользователей незатронутых регионов. Минусы: сложная синхронизация данных между регионами, конфликты записей в distributed database.
DNS-маршрутизация с геолокацией
AWS Route 53 Latency-Based Routing + Health Checks:
Route 53 → Latency policy
us-east-1: ALB endpoint + Health check
eu-west-1: ALB endpoint + Health check
ap-southeast-1: ALB endpoint + Health check
При падении health check региона →
трафик автоматически на оставшиеся регионы
Cloudflare Load Balancing с Traffic Steering: Geo Steering или Dynamic Steering (на основе реального RTT). Обнаружение сбоя за 10-60 секунд, переключение — секунды.
Репликация данных между регионами
Главная проблема multi-region — данные. Пользователь записал данные в us-east-1, при failover попал в eu-west-1 — данных нет.
Для PostgreSQL: AWS Aurora Global Database — репликация с лагом < 1 секунды, промоция резервного региона за ~1 минуту. Или CockroachDB / Spanner как нативно geo-distributed БД.
Для stateless-данных: S3 Cross-Region Replication — файлы реплицируются автоматически. CloudFront с несколькими origin.
Для сессий: Redis с репликацией между регионами (AWS ElastiCache Global Datastore) или JWT-токены (stateless по природе).
Для очередей: AWS SQS не реплицируется между регионами автоматически — нужен дизайн с учётом региональной изоляции или использование Kafka с MirrorMaker 2.
Тестирование: chaos engineering на региональном уровне
Проверка multi-region failover без реального сбоя региона:
- Блокировка трафика на уровне ALB — целевая группа получает 0 здоровых инстансов
- AWS Fault Injection Simulator — симуляция задержек и сбоев компонентов региона
- Route 53 Health Check → forced failure — перевести health check в unhealthy вручную через API
Фиксировать: время обнаружения сбоя (должно быть < 60s), время переключения DNS (TTL-зависимо, обычно 60-120s), поведение активных пользователей (сбросились ли сессии, потерялись ли данные in-flight).
Управление конфигурацией
Каждый регион должен быть идентично настроен. Infrastructure as Code — обязательно:
- Terraform с workspace per region или separate state files
- Одни и те же Docker-образы (ECR replication или private registry per region)
- Secrets Manager replication (AWS Secrets Manager multi-region)
Конфигурационный дрейф между регионами — основная причина того, что failover работает на тестах, но ломается в продакшене.
Стоимость и компромиссы
Active-passive: +40-60% к стоимости инфраструктуры одного региона. Active-active: +80-120% (полная копия каждого региона + cross-region трафик).
Для большинства проектов — active-passive с hot standby достаточно. Active-active нужен при: > 100k RPS, глобальная аудитория с требованиями по латентности, SLA 99.99%+.
Сроки реализации
- Active-passive (2 региона, DNS failover) — 1-2 недели
- Aurora Global Database + приложение — 2-3 недели
- Active-active с синхронизацией данных — 4-8 недель
- Полное тестирование + runbook + мониторинг — +1 неделя