Відзначимо: коли хмарний провайдер перестає відповідати, бізнес втрачає $10 000 на годину. За даними Gartner, середня вартість хвилини простою в enterprise — $5 600, а 90% компаній, які пережили годинний збій, втрачають понад $1 млн. Мультирегіональне розгортання не рятує — vendor outage виводить з ладу всі зони доступності. Єдиний надійний сценарій — автоматичне перемикання між AWS та GCP, cross-cloud failover. Ми проектуємо cloud-agnostic архітектуру, яка гарантує доступність 99.99%+ і перемикання за хвилини.
Наше рішення використовує контейнеризацію на Kubernetes, Terraform для управління інфраструктурою обох хмар, логічну реплікацію PostgreSQL для синхронізації даних та автоматичний детектор збоїв. На відміну від мультирегіонального підходу, cross-cloud виключає єдину точку відмови на рівні провайдера. Додаток продовжує працювати, навіть якщо AWS us-east-1 повністю недоступний. Cloudflare DNS failover перемикає трафік за 60 секунд, а warm standby скорочує витрати на резервування до 30% порівняно з повним копіюванням.
| Параметр | Мультирегіональний | Cross-cloud failover |
|---|---|---|
| Захист від vendor outage | Ні | Так |
| Єдина точка відмови провайдера | Є | Немає |
| Складність | Середня | Висока |
| Вартість DR (витрати) | ~70% від production | ~40% від production |
Чек-лист перевірки failover
- Всі компоненти cloud-agnostic (немає DynamoDB, SQS, Lambda).
- Реплікація PostgreSQL працює з лагом не більше секунд.
- Cloudflare health checks налаштовані з 3+ геоточок.
- Terraform-модулі для другого провайдера протестовані.
- Процедура failback описана та протестована.
Обмеження одного провайдера
Прив'язка до однієї хмари — єдина точка відмови. Навіть мультирегіональна відмовостійкість не рятує від глобального збою площини управління (IAM, DNS). Логічна реплікація PostgreSQL дозволяє тримати дані синхронізованими з мінімальним лагом.
Передумови для cross-cloud failover
Без цих умов failover не спрацює:
- Cloud-agnostic архітектура — додаток не використовує DynamoDB, SQS, Lambda. Тільки PostgreSQL, Redis, об'єктне сховище через сумісний API.
- Контейнеризація — Kubernetes забезпечує однорідне середовище. Helm-чарти для обох областей.
- Синхронізація даних — механізм реплікації з лагом у секунди.
- Infrastructure as Code — Terraform описує інфраструктуру обох провайдерів. Без цього відновлення затягується на години.
Як працює DNS failover?
Cloudflare — оптимальний вибір для перемикання між провайдерами. Він не належить жодному з хмарних гігантів і підтримує health checks + load balancing. Cloudflare оновлює DNS записи за 60 секунд, що вдвічі швидше за стандартні NS-сервери. Cloudflare DNS failover у 3 рази надійніше, ніж AWS Route53, оскільки не залежить від AWS.
import CloudFlare cf = CloudFlare.CloudFlare(token=CF_TOKEN) def switch_to_provider(zone_id: str, record_name: str, new_ip: str): records = cf.zones.dns_records.get(zone_id, params={'name': record_name}) record_id = records[0]['id'] cf.zones.dns_records.put( zone_id, record_id, data={ 'type': 'A', 'name': record_name, 'content': new_ip, 'ttl': 60, 'proxied': True } ) Cloudflare Load Balancing з health checks автоматизує перемикання. Моніторинг кількох ендпоінтів з різних точок світу.
Синхронізація даних між AWS та GCP
PostgreSQL з логічною реплікацією через pglogical — тримаємо дві бази майже в реальному часі. Реплікація PostgreSQL між хмарами працює з лагом менше секунди, що в 10 разів швидше за звичайну потокову реплікацію.
Джерело (AWS RDS) — публікація:
SELECT pglogical.create_node( node_name := 'provider', dsn := 'host=aws-rds.example.com dbname=mydb' ); SELECT pglogical.create_replication_set('default'); SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']); Приймач (GCP Cloud SQL) — підписка:
SELECT pglogical.create_node( node_name := 'subscriber', dsn := 'host=gcp-cloudsql.example.com dbname=mydb' ); SELECT pglogical.create_subscription( subscription_name := 'from_aws', provider_dsn := 'host=aws-rds.example.com dbname=mydb' ); Лаг реплікації моніториться через pg_stat_replication. При активації failover промотуємо GCP: відключаємо підписку та виконуємо pg_promote().
Об'єктне сховище: rclone синхронізує S3 → GCS кожні 5 хвилин для критичних даних. GCP Cloud Storage обходиться на 15% дешевше AWS S3, що робить його економічно вигідним вибором для DR. Економія на DR-інфраструктурі становить $2000 на місяць для типових проектів.
rclone sync s3:production-bucket gcs:dr-bucket --transfers 32 --checkers 16 --log-level INFO Автоматичний детектор збою
Зовнішні health checks з кількох геоточок виявляють outage.
import asyncio import httpx PROVIDERS = { 'aws': 'https://aws-endpoint.example.com/health', 'gcp': 'https://gcp-endpoint.example.com/health', } async def check_provider_health(provider: str, url: str) -> bool: async with httpx.AsyncClient(timeout=10) as client: try: resp = await client.get(url) return resp.status_code == 200 except Exception: return False async def monitor_and_failover(): while True: results = await asyncio.gather(*[ check_provider_health(p, u) for p, u in PROVIDERS.items() ]) aws_ok, gcp_ok = results current_active = get_current_active_provider() if not aws_ok and current_active == 'aws' and gcp_ok: trigger_failover_to_gcp() await asyncio.sleep(30) Покрокова процедура failover
- Детектувати збій (автоматично або вручну).
- Зупинити запис у primary provider DB (запобігти split-brain).
- Промотувати DR DB в GCP як новий primary.
- Оновити Cloudflare DNS / Load Balancer на GCP endpoints.
- Запустити масштабування GCP кластеру до production-потужності (якщо warm standby).
- Перевірити health всіх компонентів в GCP.
- Зняти maintenance page / відновити трафік.
Весь процес: 5–15 хвилин при automated failover, 15–30 хвилин при manual.
Як виконується зворотний failover (failback)?
Failback складніший за перемикання. При відновленні основного провайдера:
- Не перемикатися одразу — переконатися в стабільності.
- Синхронізувати дані назад (GCP → AWS за час outage).
- Перемкнути трафік у maintenance window.
- Перевірити повноту даних.
Обсяг робіт з впровадження failover
Ми виконуємо повний цикл: аудит архітектури на cloud-agnostic, проектування Terraform-модулів для другого провайдера, налаштування реплікації PostgreSQL та об'єктного сховища, автоматизація failover через Cloudflare та моніторинг. Результат — документація, скрипти та інструкції для вашої команди. Вартість проекту під ключ — від $15 000, термін — від 20 днів. Пишіть нам для детальної оцінки.
| Етап | Термін |
|---|---|
| Попередній аудит | 2–3 дні |
| Terraform для другого провайдера | 5–10 днів |
| Налаштування реплікації даних | 5–10 днів |
| Автоматизація failover + детектор | 3–5 днів |
| Тестування повного failover cycle | 3–5 днів |
Що входить у роботу
- Аудит поточної архітектури та cloud-agnostic рекомендації.
- Розробка Terraform-модулів для AWS та GCP.
- Налаштування логічної реплікації PostgreSQL.
- Впровадження автоматичного failover (Cloudflare DNS + health checks).
- Створення runbook для failover/failback.
- Проведення тестового failover.
- Навчання вашої команди.
- Підтримка протягом 1 місяця після впровадження.
Наші інженери мають сертифікації AWS та GCP, понад 7 років досвіду в multi-cloud проектах. Оцінка вашої архітектури — безкоштовно. Зв'яжіться з нами для консультації. Замовте аудит поточної інфраструктури.