Zone de disponibilitate și regiuni încrucișate

1) Termeni și obiective

Zona de disponibilitate (AZ) - un centru de date izolat în regiune (capacitate proprie/rețea).
Regiune - grup AZ cu geografie comună și întârzieri.

• RTO (Recovery Time Obiectiv) - cât timp nu puteți oferi un serviciu.
• RPO (Recovery Point Obiectiv) - cât de multe date pot fi pierdute.

De obicei: in cadrul regiunii vizam RTO ≤ 5-15 minute, RPO ~ 0-1 minute, interregional - RTO ≤ 1 ora, RPO ≤ 5 minute (in functie de produs si buget).

2) Modele arhitecturale

2. 1 În interiorul regiunii (multi-AZ)

Strat apatrid: distribuit peste AZ; echilibrare - L4/L7 cu controale de sănătate.
Strat statuar: clustere cu replicare sincronă (sau cvorum) între AZ.
Cache/cozi: grupate, cu ascuțire AZ și failover automat.

2. 2 Interregional (multi-regiune)

Activ-Activ: Ambele regiuni primesc trafic.

Latenţă minimă a utilizatorului, recuperare rapidă, consistenţă − şi complexitate conflictuală

Activ-pasiv (cald/cald): regiunea principală servește, a doua - în anticipare caldă/caldă.

date mai simple, mai ieftine, − RTO mai mare.
Pilot-Light: „lumină” minimă (datele sunt sincronizate, calculele se desfășoară în caz de accident).
DR-backup: numai copii de rezervă și scenariu de recuperare (cel mai ieftin și mai lent).

3) Date și consecvență

3. 1 Baze de date

Cvorum sincron (RPO≈0, ↑latentnost): PostgreSQL cu standbyuri sincrone în regiune; baze de date distribuite (GandachDB/Cassandra) cu cvorumuri locale (Local Quorum) și echilibrare AZ.
Asincron interregional (RPO> 0, ↓latentnost): replicare logică Postgres/MySQL; „tabele globale” в KV/NoSQL; CDC→strim în altă regiune.
Intrări contradictorii: Pentru activ-activ, utilizați CRDT/versioning sau leader-regiune per cheie/chiriaș.

3. 2 Evenimente-aprovizionare și cozi

Cozi/fluxuri (Kafka/Pulsar/SQS-like): subiecte-oglindă sau replicatoare transregionale; cheie - idempotența consumatorilor și blocajul cheie.
Webhooks și parteneri externi: semnați, reluați, stocați punctele de control/offset în ambele zone.

3. 3 Numerar

Cache-uri locale pe regiune (write-through/refresh-ahead); cache global partajat pentru KV-uri durabile numai (aka split-creier). Dezactivarea după eveniment (pub/sub), TTL - conservator.

4) Bucla globală de trafic și rețea

GSLB/DNS: rutare pe bază de geo-/latență, controale de sănătate, trafic-greutăți pentru canari și accidente.
Anycast/Edge: aducem intrarea mai aproape de utilizator, apoi de cea mai apropiată regiune sănătoasă.
Politici de eșec: bazine regionale în amonte, interzicerea 0-RTT pe căi critice, termene scăzute pentru dependențele interregionale.
Politici de retransmitere: backoff exponențial + jitter, constrângere cu termen limită total, PUT/POST idempotent cu „Idempotency-Key”.

5) Kubernete și plasă de serviciu

5. 1 Multi-AZ într-un singur cluster

topologia răspândește constrângeri по 'topologie. kubernetes. io/zona ".
PodDisruptionBudget и clase prioritare.
NodeAffinity/Anti-Affinity - Evitați copia co-locație.
Zone de stocare: PV cu sisteme de replicare AZ sau volum distribuit.

5. 2 Multi-regiune (multi-cluster)

Clustere separate pe regiune + GitOps (Argo CD/Flux) pentru sincronizare declarativă.
Service Mesh (Istio/Linkerd): echilibrarea încărcăturii și failover între regiuni; mTLS, identitate comună.
Deplasarea traficului: treptat 1%→10%→50% către o nouă regiune; mâner „pune 0%” instantaneu.

6) Selectarea RTO/RPO și legarea modelului

7) Testarea toleranței la erori (DR)

GameDays: trimestrial pe scară largă „regiune/AZ out” scenariu.
Injecții de haos: întârzieri de rețea, pierderi de pachete, deconectare broker/bază într-un singur AZ.
RTO/RPO efectiv: măsurați timpul de comutare și pierderea datelor, publicați raportul.
Runbooks: instrucțiuni pas cu pas și „butoane roșii” pentru comutare (greutăți DNS, feature-flags, dezactivarea caracteristicilor grele).

8) Observabilitate și management

Felii metrice pe regiuni/AZ/chiriași; p95/p99 latenţa traseului.
Bugete SLO și Eroare per regiune și per pool global.
Alerte: degradarea unei regiuni nu trebuie să „blocheze” paginile dacă a doua transportă traficul în mod normal.
Трейсы: bagajele „regiune”, „az”, „failover = true/false”; raportează „câte cereri au eşuat”.

9) Siguranță și conformitate

Rezidența datelor: conectarea datelor PII/de plată la anumite regiuni (jurisdicție).
Secrete: KMS/smart HSM cu chei transregionale și rotație; Materiale cheie separate pe regiune.
mTLS și încrederea reciprocă între regiuni; restricționează ieșirea transregională de către ACL.

10) Costuri și economii

Edge cache + SWR - scăderea ieșirii interregionale.
Diferite clase de depozitare (cald/cald/rece) și downsampling metrics/busteni.
Profile la scară automată în funcție de regiune (minim de noapte).
Identitatea imaginii + configurație diferențiată prin variabile de mediu/valori Helm.

11) Antipattern

Un maestru al statutului pe sistem; creier divizat fără cvorum.
Scrierea sincronă interregională la un singur RDBMS (latență insuportabilă).
Cache global cu consistență puternică fără CRDT → congestie și fantome.
Retrocedări fără idempotență → duplicarea tranzacțiilor/plăților.
Un singur SLO „global” - ascunde eșecul unei regiuni.
Nu există exerciții DR regulate - planurile sunt inoperabile în luptă.

12) Specificul iGaming/Finanțe

Prestatorii de plăți/contrapartidele centrale sunt selectați la nivel regional; face smart-rutare peste PSP cu semnale de sănătate, nu a reușit să backup.
Jurisdicție: deținerea de jurnale de tranzacții PII și în țară/regiune; cross-region - numai agregate/anonime.
Limite/joc responsabil: reguli și ore locale - nu reproduceți „head-on” între regiuni, utilizați consecvența evenimentelor.

Bonusuri/echilibru: chei idempotente și „sursa adevărului” per chiriaș/regiune; reconciliere-locuri de muncă după DR

13) Mini rețete (pseudo-figuri)

13. 1 Trimisul localității-conștient + 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 topologie răspândit

yaml spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }

13. 3 DNS Greutate Feilover (idee)

„greutate (eu) = 90”, „greutate (us) = 10” → atunci când se degradează „eu” se mută automat la „noi”. Controale de sănătate și TTL-uri reduse (dar nu prea agresive, 30-120 s).

14) Lista de verificare Prod Readiness

• RTO/RPO per serviciu definit și convenit cu afacerea.
• Apatrizii distribuiți în AZ; Stateful are cvorum/replicare și un model clar de consistență.
• Replicare transregională (asincron/CDC), teste de coliziune/eliminare a duplicatelor.
• GSLB/Anycast sunt configurate, controalele de sănătate și greutățile sunt automatizate.
• Kubernetes: topologie-spread, PDB, anti-afinitate; multi-cluster GitOps.
• Retrai cu jitter, idempotency on write; scurte intervale de timp interregional.
• exerciții DR, măsurate efectiv RTO/RPO; Runbook curent.
• Observabilitatea pe regiuni/AZ, SLO și burn-rate pe secțiuni, alerte nu „blochează” funcționarea normală.
• Rezidența datelor/secretele/cheile respectă cerințele de reglementare.
• Economie: ieșire, depozitare, profile autoscale sub control.

15) TL; DR

Construiți multi-AZ ca un strat de bază, multi-regiune ca asigurare de afaceri. Alegeți un model (activ-activ/standby) pentru RTO/RPO și costul, replicați datele în mod conștient (cvorum/CDC/CRDT), gestionați traficul global prin GSLB/Anycast și echilibrarea conștientă de locație. Obligatoriu: idempotență, scurte intervale de timp, exerciții DR regulate, SLO/metrici pe felii de regiune/AZ. Pentru iGaming/Finance, adăugați PSP/KYC regional, cerințele de date și SLO-urile divizate în funcție de jurisdicție.