Қолжетімділік аймақтары және кросс-өңірлер

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)

Stateless-қабат: AZ бойынша бөлінген; теңгерім - health-checks-пен L4/L7.
Stateful-қабат: AZ арасында ілеспе репликасы (немесе кворумы) бар кластерлер.
Кэш/кезек: кластерлік, AZ бойынша шардталған және автоматты failover.

2. 2 Өңіраралық (multi-region)

Active-Active: екі өңір де трафикті қабылдайды.

пайдаланушылардың ең аз жасырындылығы, тез қалпына келуі; − консистенттілік пен жанжалдардың күрделілігі.
Active-Passive (hot/warm): негізгі өңір қызмет көрсетеді, екіншісі - ыстық/жылы күтуде.

− RTO-дан жоғары.
Pilot-Light: ең аз «от» (деректер үндестіріледі, есептеулер авария кезінде ашылады).
DR-backup: тек бэкаптар және қалпына келтіру сценарийі (ең арзан және ең баяу).

3) Деректер және консистенттілік

3. 1 Дерекқорлар

Синхронды кворумды (RPO ≈ 0, ↑ латенттілік): Өңір шегінде синхронды standbys бар PostgreSQL; жергілікті кворумдармен (Local Quorum) және AZ бойынша теңгеріммен бөлінген БД (CockroachDB/Cassandra).
Асинхрондық өңіраралық (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 шектеу, idempotent PUT/POST с 'Idempotency-Key'.

5) Kubernetes және сервис-меші

5. 1 Multi-AZ бір кластерде

topology spread constraints по `topology. kubernetes. io/zone`.
PodDisruptionBudget и priority classes.
NodeAffinity/Anti-Affinity - репликалардың біркелкі орналасуынан аулақ болу.
Сақтау аймақтары: АЗ бойынша репликациясы бар PV немесе бөлінген 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 және өңірлер арасындағы өзара сенім; ACL бойынша кросс-аймақтық egress.

10) Құны және үнемдеу

Edge-кэш + SWR - өңіраралық egress деңгейін төмендету.
Әртүрлі сақтау сыныптары (hot/warm/cold) және downsampling метриктер/логтар.
Өңірлер бойынша авто-scale профильдері (түнгі минимум).
Суреттердің ұқсастығы + ауыспалы/Helm values арқылы сараланған конфигурация.

11) Антипаттерндер

Бүкіл жүйеге бір Stateful шебері; кворумсыз split-brain.
Аймақаралық синхронды жазба жалғыз RDBMS (көтерілмейтін жасырын).
CRDT → кептелістері мен «фантомдары» жоқ күшті консистенциясы бар жаһандық кэш.
Ұқсастығы жоқ ретраялар → операциялардың/төлемдердің телнұсқалары.
Бірыңғай «жаһандық» SLO - бір өңірдің сәтсіздігін жасырады.
Тұрақты DR-жаттығулар жоқ - жоспарлар ұрыста жұмысқа қабілетсіз.

12) iGaming/Қаржы ерекшелігі

Төлем провайдерлері/АЖК өңірлік түрде таңдалады; PSP арқылы smart-routing жасаңыз health-сигналдармен, failover резервтегімен.
Юрисдикциясы: ел/өңір ішінде PII және операциялар журналдарын сақтау; кросс-өңір - тек агрегаттар/анонимдер.
Лимиттер/жауапты ойын: жергілікті ережелер мен сағаттар - өңірлер арасында «маңдайына» реплика жасамаңыз, оқиғалық консистенттілікті пайдаланыңыз.
Бонустар/теңгерім: іспеттес кілттер және «ақиқат көзі» per tenant/region; DR кейін reconcile-джобалар.

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: 30s

13. 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 салыңыз. RTO/RPO үшін паттернді (active-active/standby) және құнды таңдаңыз, деректерді саналы түрде репликалаңыз (кворумдар/CDC/CRDT), жаһандық трафикті GSLB/Anycast және locality-aware теңгерімі арқылы басқарыңыз. Міндетті: теңсіздік, қысқа таймауттар, тұрақты DR-жаттығулар, SLO/region/AZ қималарындағы метриктер. iGaming/Қаржы үшін өңірлік PSP/KYC, деректерге қойылатын талаптарды және юрисдикциялар бойынша бөлек SLO қосыңыз.