Зоны доступности и кросс-регионы
1) Термины и цели
Зона доступности (AZ) — изолированный дата-центр внутри региона (собственная мощность/сеть).
Регион — группа AZ с общей географией и задержками.
- RTO (Recovery Time Objective) — сколько времени можно не оказывать сервис.
- RPO (Recovery Point Objective) — какой объем данных допустимо потерять.
Обычно: внутри региона целимся в RTO ≤ 5–15 мин, RPO ~ 0–1 мин, межрегионально — RTO ≤ 1 ч, RPO ≤ 5 мин (зависит от продукта и бюджета).
2) Архитектурные модели
2.1 Внутри региона (multi-AZ)
Статeless-слой: распределен по AZ; балансировка — L4/L7 с health-checks.
Stateful-слой: кластеры с синхронной репликацией (или кворумом) между AZ.
Кэш/очереди: кластерные, с шардированием по AZ и автоматическим failover.
2.2 Межрегионально (multi-region)
Active-Active: оба региона принимают трафик.
минимальная латентность пользователям, быстрое восстановление; − сложность консистентности и конфликтов.
Active-Passive (hot/warm): основной регион обслуживает, второй — в горячем/теплом ожидании.
проще данные, дешевле; − выше RTO.
Pilot-Light: минимальный «огонек» (данные синхронизируются, вычисления разворачиваются при аварии).
DR-backup: только бэкапы и сценарий восстановления (самый дешевый и самый медленный).
3) Данные и консистентность
3.1 Базы данных
Синхронные кворумные (RPO≈0, ↑латентность): PostgreSQL с синхронными standbys в пределах региона; распределенные БД (CockroachDB/Cassandra) с локальными кворумами (Local Quorum) и балансировкой по AZ.
Асинхронные межрегиональные (RPO>0, ↓латентность): логическая репликация Postgres/MySQL; «global tables» в KV/NoSQL; CDC→стрим в другой регион.
Конфликтующие записи: для active-active используйте CRDT/версионирование или стратегию «источник истины» (leader-region per key/tenant).
3.2 Event-сорсинг и очереди
Очереди/стримы (Kafka/Pulsar/SQS-подобные): mirror-topics или кросс-региональные репликаторы; ключ — идемпотентность консьюмеров и дедуп по ключам.
Вебхуки и внешние партнеры: подписывать, иметь replay, хранить offset/чекпоинты в обеих зонах.
3.3 Кэш
Локальные кэши per-регион (write-through/refresh-ahead); глобальный общий кэш только для прочных KV (иначе split-brain). Инвалидировать по событиям (pub/sub), TTL — консервативный.
4) Глобальный трафик и сетевой контур
GSLB/DNS: Geo-/Latency-based routing, health-checks, «traffic-weights» для канареек и аварий.
Anycast/Edge: приближаем вход к пользователю, далее — до ближайшего здорового региона.
Failover-политики: региональные пулы upstream’ов, запрет 0-RTT на критичных путях, низкие таймауты к межрегиональным зависимостям.
Политики ретраев: экспоненциальный backoff + джиттер, ограничение total-deadline, идемпотентные PUT/POST с `Idempotency-Key`.
5) Kubernetes и сервис-меш
5.1 Multi-AZ в одном кластере
topology spread constraints по `topology.kubernetes.io/zone`.
PodDisruptionBudget и priority classes.
NodeAffinity/Anti-Affinity — избегать ко-локации реплик.
Зоны хранения: PV с репликацией по AZ или распределенные volume-системы.
5.2 Multi-region (multi-cluster)
Раздельные кластеры per-регион + GitOps (Argo CD/Flux) для декларативной синхронизации.
Service Mesh (Istio/Linkerd): locality-aware load-balancing и failover между регионами; mTLS, общая идентичность.
Traffic-shifting: поэтапно 1%→10%→50% на новый регион; ручка «поставить 0%» мгновенно.
6) Выбор RTO/RPO и привязка к паттернам
7) Тестирование отказоустойчивости (DR)
GameDays: ежеквартальный полномасштабный сценарий «погас регион/AZ».
Chaos-инъекции: сетевые задержки, потери пакетов, отключение брокера/базы в одной AZ.
RTO/RPO фактические: замеряйте время переключения и потерю данных, публикуйте отчет.
Runbooks: пошаговые инструкции и «красные кнопки» для переключений (DNS weights, feature-flags, отключение тяжелых фич).
8) Наблюдаемость и управление
Срезы метрик по region/AZ/tenant; p95/p99 латентности по маршрутам.
SLO и Error Budgets на регион и на глобальный пул.
Алерты: деградация одного региона не должна «глушить» пейджинг, если второй несет трафик в норме.
Трейсы: baggage `region`, `az`, `failover=true/false`; отчеты «сколько запросов ушло на failover».
9) Безопасность и соответствие
Data residency: привязка PII/платежных данных к определенным регионам (юрисдикция).
Секреты: KMS/смарт-HSM с кросс-региональными ключами и ротацией; разделяйте материалы ключей per-регион.
mTLS и взаимное доверие между регионами; ограничьте кросс-региональные egress по ACL.
10) Стоимость и экономия
Edge-кэш + SWR — снижение межрегионального egress.
Разные классы хранения (hot/warm/cold) и downsampling метрик/логов.
Авто-scale профили по регионам (ночной минимум).
Идентичность образов + дифференцированная конфигурация через переменные окружения/Helm values.
11) Антипаттерны
Один Stateful-мастер на всю систему; split-brain без кворума.
Межрегиональная синхронная запись в единственный RDBMS (неподъемная латентность).
Глобальный кэш с сильной консистентностью без CRDT → заторы и «фантомы».
Ретраи без идемпотентности → дубликаты операций/платежей.
Единый «глобальный» SLO — скрывает провал одного региона.
Нет регулярных DR-учений — планы неработоспособны в бою.
12) Специфика iGaming/финансов
Платежные провайдеры/KYC выбираются регионально; делайте smart-routing по PSP с health-сигналами, failover на резервного.
Юрисдикция: хранение PII и журналов операций внутри страны/региона; кросс-регион — только агрегаты/аноним.
Лимиты/ответственная игра: локальные правила и часы — не реплицируйте «в лоб» между регионами, используйте событийную консистентность.
Бонусы/баланс: идемпотентные ключи и «источник истины» per tenant/region; reconcile-джобы после DR.
13) Мини-рецепты (псевдоконфиги)
13.1 Envoy locality-aware + failover
yaml load_assignment:
endpoints:
- locality: { region: eu, zone: eu-a }
lb_endpoints: [{ endpoint: { address:... } }]
- locality: { region: eu, zone: eu-b }
lb_endpoints: [{ endpoint: { address:... } }]
- locality: { region: us, zone: us-a } # failover target lb_endpoints: [{ endpoint: { address:... } }]
common_lb_config:
zone_aware_lb_config: {}
locality_weighted_lb_config: {}
outlier_detection:
consecutive_5xx: 5 base_ejection_time: 30s13.2 Kubernetes topology spread
yaml spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }13.3 DNS весовой фейловер (идея)
`weight(eu)=90`, `weight(us)=10` → при деградации `eu` автоматически сдвиг в `us`. Health-checks и пониженные TTL (но не слишком агрессивные, 30–120 с).
14) Чек-лист prod-готовности
- Определены RTO/RPO per сервис и согласованы с бизнесом.
- Stateless распределен по AZ; stateful имеет кворум/репликацию и понятную модель консистентности.
- Репликация межрегиональная (асинхрон/CDC), тесты конфликтов/дедупликатора.
- GSLB/Anycast настроены, health-checks и weights автоматизируемы.
- Kubernetes: topology-spread, PDB, anti-affinity; multi-cluster GitOps.
- Ретраи с джиттером, идемпотентность на write; короткие таймауты межрегионально.
- DR-учения, измеренные фактические RTO/RPO; актуальный runbook.
- Наблюдаемость по region/AZ, SLO и burn-rate на срезах, алерты не «глушат» нормальную работу.
- Data residency/секреты/ключи соответствуют регуляторике.
- Экономика: egress, хранение, профили автоскейла под контролем.
15) TL;DR
Стройте multi-AZ как базовый слой, multi-region — как страховку бизнеса. Выберите паттерн (active-active/standby) под RTO/RPO и стоимость, реплицируйте данные сознательно (кворумы/CDC/CRDT), управляйте глобальным трафиком через GSLB/Anycast и locality-aware балансировку. Обязательны: идемпотентность, короткие таймауты, регулярные DR-учения, SLO/метрики на срезах region/AZ. Для iGaming/финансов добавьте региональные PSP/KYC, требования к данным и раздельные SLO по юрисдикциям.