Налаштування 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 близько до нуля для користувачів непостраждалих регіонів. Недоліки: складна синхронізація даних між регіонами, конфлікти записів у розподіленій базі даних.
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-розподілена БД.
Для 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 або окремі 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 тиждень