Настройка Multi-Region Edge Deployment: гео-маршрутизация, DNS failover

Мы настраиваем 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-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. Ключевой момент — разделение 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"
}

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 — рассчитываются после аудита.

Свяжитесь с нами для аудита вашей архитектуры. Получите консультацию по multi-region deployment и узнайте, как мы можем гарантировать отказоустойчивость и экономию до 40% на трафике.