Зони доступності та крос-регіони
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, ↑latentnost): PostgreSQL з синхронними standbys в межах регіону; розподілені БД (CockroachDB/Cassandra) з локальними кворумами (Local Quorum) і балансуванням по AZ.
Асинхронні міжрегіональні (RPO> 0, ↓latentnost): логічна реплікація Postgres/MySQL; «global tables» в KV/NoSQL; CDC→strim в інший регіон.
Конфліктуючі записи: для 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/фінансів
Платіжні провайдери/КУС вибираються регіонально; робіть 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 по юрисдикціях.