Стратегия multi-region

Действуй как Principal Cloud Architect. Спроектируй multi-region архитектуру для: {{service}}. Регионы: {{regions}}.

Шаги

1. Определи требования количественно.

   • RTO (Recovery Time Objective) — сколько минут downtime допустимо.
   • RPO (Recovery Point Objective) — сколько данных можем потерять.
   • Latency target — p95 по регионам.
   • Это диктует архитектуру: RPO=0 + RTO<1min — почти всегда active-active, RTO=15min + RPO=5min — можно active-passive.

2. Выбери модель.

   • Active-active — трафик идёт во все регионы одновременно. Плюсы: latency для каждого региона свой, failover мгновенный. Минусы: конфликты записи, сложная репликация, стоимость x N.
   • Active-passive (warm standby) — один регион принимает трафик, второй прогрет и реплицирует. Плюсы: проще, дешевле. Минусы: RTO 5-15 минут, ресурсы простаивают.
   • Pilot light — только данные реплицируются, инфра поднимается по требованию. RTO часы. Подходит для disaster recovery, не для HA.

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

   • Synchronous (Spanner, Aurora Global для read replicas с пиннингом, etcd RAFT) — RPO=0, но запись = latency между регионами. Не работает для cross-continent.
   • Asynchronous (PostgreSQL streaming, DynamoDB Global Tables, Kafka MirrorMaker) — быстрая запись, RPO = lag (секунды-минуты). При failover можем потерять окно.
   • Для критичных финансовых данных — quorum-based (3 региона, write требует 2 подтверждения).

4. Маршрутизация.

   • Latency-based (Route53 latency policy, GCP Cloud DNS geo) — пользователь к ближайшему здоровому региону.
   • Geo-based — жёсткое привязывание по геолокации (data residency, GDPR).
   • Anycast (CloudFront, Cloudflare) — на edge, на бэкенд решает уже edge-логика.
   • Health checks на стороне DNS + на уровне глобального LB.

5. Failover automation.

   • Триггер: composite health (синтетика + реальные метрики + database write canary).
   • Откат — отдельная процедура с человеком в петле; автоматический "обратный failover" редко безопасен.
   • Регулярные drill'ы: GameDay раз в квартал, иначе runbook устаревает.

6. Split-brain prevention.

   • В active-active с асинхронной репликацией split-brain неизбежен при netsplit. Решения:
     • Sharding по user-id: каждый пользователь "приписан" к региону, write-conflict невозможен.
     • CRDTs для merge-able типов (счётчики, sets).
     • Leader election (Spanner-like consensus) — но тогда писать может только лидер.
   • В active-passive — обязателен fencing: старый primary должен быть выключен (STONITH) до промоушна нового, иначе оба будут принимать запись.

7. Cost trade-offs. Multi-region честно стоит x2-3 от single-region: дублирование compute, cross-region трафик ($0.02-0.09/GB), управленческий overhead. Если RTO позволяет 30 минут — pilot light на порядок дешевле.

Anti-patterns

• ❌ "Сделаем active-active, репликация сама разрулит" — без конфликт-резолюции получишь silent data corruption.
• ❌ Failover на основании одного health check — flap, ложные срабатывания.
• ❌ Cross-region sync replication для high-throughput write — латенси убьёт SLO раньше, чем спасёт.
• ❌ Нет fencing — split-brain → две версии правды → невозможно сшить обратно.
• ❌ Никогда не проверяли failover в проде — в день инцидента runbook не работает.

Формат вывода

## Recommendation
Model: <active-active | active-passive | pilot light>
Justification: <с привязкой к RTO/RPO/latency>

## Data layer
<какой движок, режим репликации, конфликт-резолюция>

## Routing
<DNS/LB стратегия, health checks>

## Failover runbook
1. Detection: ...
2. Decision: ...
3. Execution: ...
4. Verification: ...
5. Rollback: ...

## Drill cadence
<как часто, что включает>

## Cost estimate
<delta vs single-region>

Принцип: multi-region — это не флажок в облаке, это операционная дисциплина. Без drill'ов это театр готовности.