Мультирегіон розгортання: гео-маршрутизація, DNS failover

Наша компанія має 7+ років досвіду в DevOps, реалізували понад 20 мультирегіонних проектів. Ми налаштовуємо мультирегіон розгортання (multi-region edge deployment) для глобальних продуктів. Це забезпечує відмовостійкість через географічну надлишковість та мінімальні затримки завдяки proximity-маршрутизації. Наші сертифіковані інженери мають досвід роботи з AWS, GCP та Azure, гарантуючи SLA до 99,99%.

Типовий сценарій: розробники розгортають другий регіон, копіюють Terraform-конфіги, змінюють region = "ap-southeast-1" — і виявляють, що state файл спільний, S3-бакет для зберігання стейту в us-east-1, і terraform apply у Сінгапурі конфліктує зі стейтом з Європи. Або забувають, що RDS Multi-AZ — це не те саме, що cross-region реплікація, і другий регіон отримує read-only репліку з відставанням у 3–5 секунд, що ламає write-логіку застосунку.

Інший кейс — DNS failover без health checks. Route 53 Weighted/Latency routing відправляє трафік у найближчий регіон, але якщо регіон деградує (відповідає, але з помилками 502), health check на HTTP 200 не спрацьовує, і клієнти отримують помилки замість перемикання. Потрібен health check на рівні застосунку — ендпоінт /health повинен перевіряти залежності: БД, кеш, зовнішні сервіси.

Чому відмовостійкість вимагає двох регіонів?

Один регіон — це ставка на те, що AWS eu-west-1 або GCP europe-west4 не впадуть. Для глобального продукту це неприйнятно: latency з Азії до європейського регіону становить 150–200 мс, що вбиває інтерактивність. Multi-region edge deployment вирішує обидві задачі: відмовостійкість через geographic redundancy та продуктивність через proximity до користувача. Ми гарантуємо, що ваша архітектура витримає відмову цілого регіону без втрати даних.

Як налаштувати DNS failover з health checks?

Для надійного failover використовуємо Route 53 Latency-based routing з health checks.

1. Створіть ендпоінт /health/deep, який перевіряє всі залежності.
2. Налаштуйте health check з failure_threshold = 2 та request_interval = 10 секунд — два невдалих check поспіль виводять регіон з ротації.
3. Налаштуйте DNS-запис з latency_routing_policy та прив'яжіть health check.

Приклад Terraform:

resource "aws_route53_health_check" "eu_west_1" {
  fqdn = "api-eu.company.internal"
  port = 443
  type = "HTTPS"
  resource_path = "/health/deep"
  failure_threshold = 2
  request_interval = 10
  tags = {
    Region = "eu-west-1"
  }
}

resource "aws_route53_record" "api_global" {
  zone_id = var.hosted_zone_id
  name = "api.company.com"
  type = "A"
  latency_routing_policy {
    region = "eu-west-1"
  }
  set_identifier = "eu-west-1"
  health_check_id = aws_route53_health_check.eu_west_1.id
  alias {
    name = aws_lb.eu_alb.dns_name
    zone_id = aws_lb.eu_alb.zone_id
    evaluate_target_health = true
  }
}

failure_threshold = 2 та request_interval = 10 означають: два послідовних неуспішних checks за 20 секунд — регіон вилітає з rotation. При request_interval = 30 (дефолт) це вже хвилина деградації до перемикання.

Active-Active vs Active-Passive: що вибрати?

Вибір архітектури визначає інші рішення. Active-Active архітектура знижує затримки в 5 разів порівняно з Active-Passive.

Active-Passive простіший: основний регіон обслуговує весь трафік, резервний стоїть у гарячому резерві. Перемикання — ручне або через DNS failover. RTO від 2 до 15 хвилин. Підходить для B2B SaaS, де downtime дорогий, але не катастрофічний.

Active-Active — трафік розподіляється між регіонами одночасно, latency оптимальний, немає простою при відмові одного регіону. Складність: потрібна eventual consistency або multi-master реплікація даних. Конфлікти записів у різних регіонах — реальна проблема.

Для більшості задач добре працює гібрид: Active-Active для stateless шару (API, фронтенд, кеш), Active-Passive для stateful (PostgreSQL з streaming replication, Redis Sentinel).

Terraform: модулі для мультирегіону

Окремий terraform.tfstate для кожного регіону — обов'язково. DynamoDB-таблиця для state locking створюється один раз у home-регіоні.

# terraform/regions/eu-west-1/main.tf	erraform {
  backend "s3" {
    bucket = "terraform-state-company"
    key    = "regions/eu-west-1/terraform.tfstate"
    region = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt = true
  }
}

provider "aws" {
  region = "eu-west-1"
  alias  = "europe"
}

module "app_cluster" {
  source = "../../modules/app-cluster"
  providers = {
    aws = aws.europe
  }
  region = "eu-west-1"
  environment = "production"
  min_capacity = 3
  max_capacity = 20
  db_replica_of = "arn:aws:rds:us-east-1:123456789:db:prod-primary"
}

Як реплікувати базу даних між регіонами?

Для PostgreSQL використовуємо AWS RDS з read replica або Aurora Global Database. Aurora Global Database забезпечує реплікацію з lag менше 1 секунди, що в 3 рази швидше за звичайну cross-region реплікацію.

resource "aws_rds_global_cluster" "main" {
  global_cluster_identifier = "company-global"
  engine                    = "aurora-postgresql"
  engine_version            = "15.4"
  database_name             = "appdb"
}

resource "aws_rds_cluster" "primary" {
  provider                  = aws.primary
  cluster_identifier        = "company-primary"
  global_cluster_identifier = aws_rds_global_cluster.main.id
  engine                    = "aurora-postgresql"
  engine_version            = "15.4"
  # ...
}

resource "aws_rds_cluster" "secondary" {
  provider                  = aws.secondary
  cluster_identifier        = "company-secondary"
  global_cluster_identifier = aws_rds_global_cluster.main.id
  engine                    = "aurora-postgresql"
  # Secondary cluster — read only, failover promotion < 1 min
}

Edge caching через CDN

Статичний контент та API-відповіді, придатні для кешування, роздаються через CDN з edge nodes. Edge caching через CDN зменшує latency в 5 разів. Ключовий момент — розділення cache behavior за URL-патернами. Наприклад, для API з короткими TTL:

# CloudFront behavior: API з короткими TTL
ordered_cache_behavior {
  path_pattern = "/api/public/*"
  target_origin_id = "api-origin"
  cache_policy_id = aws_cloudfront_cache_policy.api_short.id
  # TTL 60 секунд для публічного API
  # Vary по Accept-Language для i18n
  compress = true
  viewer_protocol_policy = "redirect-to-https"
}

Економія на трафіку сягає 40%, що становить до $10 000 на місяць для великих проектів. Для глобального охоплення використовуємо CloudFront або Cloudflare. CloudFront інтегрується з AWS, Cloudflare — з власною edge network.

Observability в мультирегіоні

Метрики та логи з кожного регіону повинні агрегуватися централізовано. Prometheus з remote_write в центральний Thanos або Grafana Mimir — стандартний підхід. Алерти повинні враховувати регіональний контекст, інакше при відмові одного регіону алерт InstanceDown спрацьовує на половину інфраструктури одночасно.

Distributed tracing через OpenTelemetry з експортом в Jaeger або Grafana Tempo: trace_id пробрасується через всі регіони, що дозволяє бачити повний шлях запиту та latency на кожному хопі. Витрати на інфраструктуру observability знижуються на 30% при використанні managed сервісів.

Що входить у роботу

При замовленні послуги ви отримуєте:

• Аудит поточної архітектури з виявленням stateful залежностей
• Проект multi-region інфраструктури (Active-Active/Passive)
• Terraform-модулі для розгортання в кожному регіоні
• Налаштування DNS, health checks та failover
• Реплікацію баз даних (RDS, Aurora, Redis)
• Налаштування observability pipeline
• Документацію та runbook
• Навчання вашої команди
• Підтримку після запуску

Етапи та терміни

Вартість та кінцеві терміни залежать від поточної архітектури, кількості регіонів та вимог до RTO/RPO — розраховуються після аудиту.

Зв'яжіться з нами для аудиту вашої архітектури. Отримайте консультацію з мультирегіон розгортання та дізнайтеся, як ми можемо гарантувати відмовостійкість та економію до 40% на трафіку.