Multi-Region архитектура

Зачем нужен Multi-Region

Multi-Region — развёртывание системы в нескольких географических регионах облачного провайдера. Три основные причины:

Сетевая задержка между регионами

Внутри одного AZ:      < 1ms
Между AZ (один регион): 1-2ms
US East ↔ US West:      ~60ms
US East ↔ EU West:      ~80ms
US East ↔ Asia:         ~150-200ms
EU ↔ Asia:              ~200-300ms

Правило: если P99 latency SLO < 100ms, а пользователи глобальные — multi-region обязателен.

Active-Passive

Один регион обрабатывает весь трафик (Active), второй — горячий standby (Passive), готовый принять нагрузку при failover.

Архитектура

                    ┌──────────────┐
                    │   DNS /      │
                    │   Global LB  │
                    └──────┬───────┘
                           │
              ┌────────────┴────────────┐
              │                         │
    ┌─────────▼─────────┐    ┌─────────▼─────────┐
    │   US-EAST (Active) │    │  EU-WEST (Passive) │
    │                    │    │                    │
    │  ┌──────┐ ┌─────┐ │    │  ┌──────┐ ┌─────┐ │
    │  │ App  │ │ App │ │    │  │ App  │ │ App │ │
    │  └──┬───┘ └──┬──┘ │    │  │(standby)│     │ │
    │     │        │     │    │  └──┬───┘ └──┬──┘ │
    │  ┌──▼────────▼──┐  │    │  ┌──▼────────▼──┐ │
    │  │  Primary DB   │──────▶│  Replica DB    │ │
    │  │  (Read/Write) │  │    │  (Read-only)   │ │
    │  └──────────────┘  │    │  └──────────────┘ │
    └────────────────────┘    └────────────────────┘
              │                         │
         Все запросы            Failover только
              │                  при аварии
              ▼                         ▼
      100% трафика              0% трафика
                                (до failover)

Характеристики

Failover процесс

1. Мониторинг обнаруживает отказ US-EAST
2. Healthcheck подтверждает (избежать false positive)
3. Promote replica в EU-WEST до primary
4. DNS/Global LB переключает трафик на EU-WEST
5. EU-WEST становится Active
6. После восстановления US-EAST — восстановить репликацию

Критичный момент: DNS TTL определяет скорость переключения. Рекомендуется TTL 60 секунд для failover-ready конфигурации.

Active-Active

Все регионы одновременно обрабатывают read и write трафик. Пользователи направляются в ближайший регион.

Архитектура

                    ┌──────────────────┐
                    │  Global DNS /     │
                    │  Latency Routing  │
                    └────────┬─────────┘
                             │
           ┌─────────────────┼─────────────────┐
           │                 │                 │
 ┌─────────▼──────┐  ┌──────▼─────────┐  ┌───▼──────────────┐
 │   US-EAST       │  │   EU-WEST       │  │  ASIA-PACIFIC    │
 │                 │  │                 │  │                  │
 │  ┌────┐ ┌────┐ │  │  ┌────┐ ┌────┐ │  │  ┌────┐ ┌────┐  │
 │  │App │ │App │ │  │  │App │ │App │ │  │  │App │ │App │  │
 │  └──┬─┘ └──┬─┘ │  │  └──┬─┘ └──┬─┘ │  │  └──┬─┘ └──┬─┘  │
 │  ┌──▼──────▼─┐ │  │  ┌──▼──────▼─┐ │  │  ┌──▼──────▼─┐  │
 │  │ DB (R/W)  │◄├──┼──►│ DB (R/W)  │◄├──┼──►│ DB (R/W)  │  │
 │  └───────────┘ │  │  └───────────┘ │  │  └───────────┘  │
 └────────────────┘  └────────────────┘  └─────────────────┘
           │                 │                 │
       US users          EU users          Asia users

Характеристики

Проблема: Write Conflicts

Когда два региона одновременно пишут в одну запись — возникает конфликт.

US-EAST:   UPDATE users SET name = 'John' WHERE id = 1;  (t=0)
EU-WEST:   UPDATE users SET name = 'Johann' WHERE id = 1; (t=0)

Результат: Конфликт! Кто победит?

Стратегии разрешения конфликтов

Шардинг по регионам — самый простой подход

Пользователь зарегистрировался в EU → данные в EU-WEST
Пользователь зарегистрировался в US → данные в US-EAST

Чтение: из "домашнего" региона пользователя
Запись: ТОЛЬКО в "домашний" регион
Кросс-регион: read replica для чтения чужих данных

Репликация данных

Синхронная репликация

Client → Write → Region A (primary)
                     │
                     ├── Replicate to Region B (sync) ── ACK
                     │
                     ▼
              Commit + Response to Client

• Гарантирует zero data loss (RPO = 0)
• Увеличивает latency на время кросс-регион RTT (60-200ms)
• Одна запись = ожидание подтверждения из удалённого региона

Асинхронная репликация

Client → Write → Region A (primary)
                     │
                     ├── Commit + Response to Client (immediately)
                     │
                     └── Replicate to Region B (async, background)
                              │
                              ▼
                    Replication lag: 100ms - 5s

• Минимальное влияние на latency
• RPO > 0 (возможна потеря последних транзакций)
• Replication lag — ключевая метрика мониторинга

Сравнение подходов к репликации

Инструменты репликации

Disaster Recovery (DR)

Ключевые метрики DR

Стратегии DR

              Стоимость ↑          RTO/RPO ↓
                  │
    Backup/Restore│ ──── RTO: часы,   RPO: часы
                  │
    Pilot Light   │ ──── RTO: минуты, RPO: минуты
                  │
    Warm Standby  │ ──── RTO: минуты, RPO: секунды
                  │
    Active-Active │ ──── RTO: секунды, RPO: ~0
                  │
                  └────────────────────────────────→

Pilot Light

Минимальная инфраструктура в DR-регионе: replica базы данных работает постоянно, compute выключен.

# Terraform — Pilot Light DR region
# Database replica is always running
resource "aws_rds_cluster" "dr_replica" {
  provider               = aws.dr_region
  engine                 = "aurora-postgresql"
  replication_source_arn = aws_rds_cluster.primary.arn
}

# Compute is pre-configured but scaled to 0
resource "aws_ecs_service" "dr_api" {
  provider       = aws.dr_region
  desired_count  = 0  # Scaled to 0 normally

  # During failover: set desired_count = 5
}

DR Testing — обязательная практика

Global Load Balancing

DNS-Based Routing

┌─────────────────────────────────────────────────┐
│              Route 53 / CloudFlare               │
│                                                 │
│  Политики маршрутизации:                         │
│  • Latency-based  → ближайший регион             │
│  • Geolocation    → по стране пользователя       │
│  • Weighted       → 80% US / 20% EU             │
│  • Failover       → primary/secondary            │
│  • Geoproximity   → с bias для тюнинга           │
└─────────────────────────────────────────────────┘

Anycast

Один IP-адрес анонсируется из нескольких точек через BGP. Сетевая инфраструктура направляет трафик к ближайшему POP.

Пользователь в Берлине → 1.2.3.4 → Berlin POP → EU-WEST
Пользователь в Токио   → 1.2.3.4 → Tokyo POP  → AP-NORTHEAST
Пользователь в Нью-Йорке → 1.2.3.4 → NYC POP → US-EAST

Используется CDN (CloudFlare, AWS CloudFront) и сервисами типа Google Global Load Balancer.

Паттерны Multi-Region для System Design

Паттерн: Follow-the-Sun

Данные пользователя "живут" в его регионе. При перемещении — read from local replica, write to home region.

Пользователь (home: EU) путешествует в Азию:
  Read  → AP replica (быстро, eventual consistency)
  Write → EU primary (через кросс-регион, выше latency)

Паттерн: Regional Sharding

Данные жёстко привязаны к региону. Кросс-регион операции через API.

EU shard: пользователи с EU email / EU billing address
US shard: пользователи с US email / US billing address

Паттерн: Global Table + Local Cache

                 ┌─────────────────────┐
                 │   DynamoDB Global    │
                 │   Table (replicated) │
                 └──────────┬──────────┘
                            │
           ┌────────────────┼────────────────┐
           │                │                │
    ┌──────▼──────┐  ┌──────▼──────┐  ┌──────▼──────┐
    │ DAX Cache   │  │ DAX Cache   │  │ DAX Cache   │
    │ US-EAST     │  │ EU-WEST     │  │ AP-SOUTH    │
    └──────┬──────┘  └──────┬──────┘  └──────┬──────┘
           │                │                │
       US Apps          EU Apps          AP Apps

Чек-лист Multi-Region на собеседовании

При проектировании multi-region системы на собеседовании обязательно обсудите:

1. Модель данных: как данные шардируются между регионами?
2. Consistency: strong vs eventual, как разрешаются конфликты?
3. Routing: как пользователь направляется в нужный регион?
4. Failover: автоматический или ручной? RTO/RPO?
5. Тестирование DR: как проверяется failover?
6. Стоимость: обоснование multi-region vs single-region

Итоги

Главное правило: multi-region — это не только техническое решение, но и бизнес-решение. Стоимость x2-x3, сложность x5-x10. Обосновывайте через SLA, compliance и бизнес-требования.