Zones d'accessibilité et régions croisées

1) Termes et objectifs

La zone de disponibilité (ZA) est un centre de données isolé à l'intérieur de la région (propre puissance/réseau).
La région est un groupe AZ avec une géographie générale et des retards.

• RTO (Recovery Time Objective) - Combien de temps vous pouvez ne pas fournir le service.
• RPO (Recovery Point Objective) - Quel volume de données est autorisé à perdre.

Habituellement : à l'intérieur de la région, nous visons RTO ≤ 5-15 min, RPO ~ 0-1 min, interrégional - RTO ≤ 1 h, RPO ≤ 5 min (dépend du produit et du budget).

2) Modèles architecturaux

2. 1 À l'intérieur de la région (multi-AZ)

Couche Steless : distribuée selon AZ ; équilibrage - L4/L7 avec les contrôles de santé.
Couche stateful : clusters avec réplication synchrone (ou quorum) entre AZ.
Cache/files d'attente : clusters, avec chardage AZ et failover automatique.

2. 2 Interrégionale (multi-région)

Active-Active : les deux régions acceptent le trafic.

latence minimale pour les utilisateurs, récupération rapide ; complexité − consistance et conflits.
Active-Passive (hot/warm) : la région principale sert, la deuxième est en attente chaude/chaude.

données plus simples, moins chères ; − ci-dessus RTO.
Pilot-Light : minimum « lightning » (les données sont synchronisées, les calculs se déroulent en cas d'accident).
DR-backup : backup et script de récupération uniquement (le moins cher et le plus lent).

3) Données et consistance

3. 1 Bases de données

Quorum synchrone (RPO≈0, ↑latentnost) : PostgreSQL avec standbys synchrones dans la région ; OBD distribués (CockroachDB/Cassandra) avec quorum local (Quorum local) et équilibrage AZ.
Interrégional asynchrone (RPO> 0, ↓latentnost) : réplication logique Postgres/MySQL ; «global tables» в KV/NoSQL; CDC→strim dans une autre région.
Entrées en conflit : pour active-active, utilisez CRDT/versioning ou la stratégie « source de vérité » (leader-region per key/tenant).

3. 2 Event-sorcing et files d'attente

Files d'attente/strim (Kafka/Pulsar/SQS) : mirror-topics ou réplicateurs croisés ; la clé est l'idempotence des consumers et le dedup par clé.
Webhooks et partenaires externes : signer, avoir un replay, stocker des offset/chekpoints dans les deux zones.

3. 3 Cache

Caches locaux par région (write-through/refresh-ahead) ; cache global partagé uniquement pour les KV robustes (sinon split-brain). Handicapé par événements (pub/sub), TTL est conservateur.

4) Trafic global et boucle réseau

GSLB/DNS : Géo-/Latinity-based routing, health-checks, « traffic-weights » pour les canaries et les accidents.
Anycast/Edge : nous rapprochons l'entrée de l'utilisateur, puis de la région la plus proche.
Failover-politics : pools régionaux upstream's, interdiction de 0-RTT sur les voies critiques, délais bas aux dépendances interrégionales.
Politiques rétroactives : exponentielle backoff + gitter, limitation de total-deadline, idempotent PUT/POST avec 'Idempotency-Key'.

5) Kubernetes et service-mesh

5. 1 Multi-AZ en une seule grappe

topology spread constraints по `topology. kubernetes. io/zone`.
PodDisruptionBudget и priority classes.
NodeAffinity/Anti-Affinity - éviter la co-localisation des répliques.
Zones de stockage : PV avec réplication AZ ou systèmes en volume distribués.

5. 2 Multi-region (multi-cluster)

Clusters per-region + GitOps (Argo CD/Flux) pour la synchronisation déclarative.
Service Mesh (Istio/Linkerd) : locality-aware load-balancing et failover entre les régions ; mTLS, identité commune.
Traffic-shifting : par étapes, 1%→10%→50 % par nouvelle région ; le stylo « parier 0 % » instantanément.

6) Sélection RTO/RPO et ancrage aux modèles

7) Test de tolérance aux pannes (DR)

GameDays : scénario trimestriel à grande échelle de « l'extinction de la région/AZ ».
Injections Chaos : retards réseau, pertes de paquets, arrêt du courtier/de la base dans une ZA.
RTO/RPO réel : mesurer le temps de commutation et la perte de données, publier le rapport.
Runbooks : instructions étape par étape et « boutons rouges » pour les commutations (weights DNS, feature-flags, désactivation des fiches lourdes).

8) Observation et gestion

Tranches de métriques par région/AZ/tenant ; p95/p99 latence le long des itinéraires.
SLO et Error Budgets par région et par pool mondial.
Alert : la dégradation d'une région ne doit pas « brouiller » la pagination si la seconde transporte le trafic normalement.
Трейсы: baggage `region`, `az`, `failover=true/false`; rapports « combien de demandes sont allées à l'échec ».

9) Sécurité et conformité

Résidence de données : relier les données PII/de paiement à certaines régions (juridiction).
Secrets : KMS/smart HSM avec clés croisées et rotation ; séparez les matériaux clés par région.
mTLS et confiance mutuelle entre les régions ; limitez l'egress cross à l'ACL.

10) Coût et économies

Cache Edge + SWR - réduction de l'egress interrégional.
Différentes classes de stockage (hot/warm/cold) et de downsampling métriques/logs.
Profils auto-scale par région (minimum de nuit).
Identité d'image + configuration différenciée à travers des variables d'environnement/valeurs Helm.

11) Anti-modèles

Un maître Stateful pour l'ensemble du système ; split-brain sans quorum.
Enregistrement synchrone interrégional dans le seul RDBMS (latence inabordable).
Cache global à forte consistance sans CRDT → encombrements et « fantômes ».
Les retraits sans idempotence → les transactions/paiements en double.
Un SLO « mondial » unique cache l'échec d'une région.
Il n'y a pas d'exercices de DR réguliers - les plans ne fonctionnent pas au combat.

12) Spécificité de l'iGaming/Finance

Les fournisseurs de paiement/CUS sont sélectionnés au niveau régional ; Faites un routage intelligent sur PSP avec des signaux de santé, failover sur la sauvegarde.
La juridiction : la conservation PII et les revues des opérations à l'intérieur du pays/région; la région croisée n'est que des agrégats/anonymes.
Limites/jeu responsable : règles locales et horloges - ne répliquez pas « en face » entre les régions, utilisez la cohérence de l'événement.
Bonus/équilibre : clés idempotent et « source de vérité » per tenant/region ; reconcile-jobs après DR.

13) Mini recettes (pseudo-recettes)

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 faussaire de poids DNS (idée)

« weight (eu) = 90 », « weight (us) = 10 » → lorsque « eu » est dégradé automatiquement en « us ». Chèques de santé et TTL réduits (mais pas trop agressifs, 30-120 s).

14) Chèque-liste prod-prêt

• Le service RTO/RPO est défini et harmonisé avec l'entreprise.
• Stateless distribué selon AZ ; stateful a un quorum/réplication et un modèle de cohérence compréhensible.
• Réplication interrégionale (asynchrone/CDC), tests de conflit/déduplicateur.
• GSLB/Anycast sont personnalisés, les tests de santé et les weights sont automatisables.
• Kubernetes: topology-spread, PDB, anti-affinity; multi-cluster GitOps.
• Retraits avec jitter, idempotence sur write ; les brefs timouts sont interrégionaux.
• Exercice DR mesuré par les RTO/RPO réels ; runbook actuel.
• Observation par région/AZ, SLO et rate-burn sur les tranches, les alertes ne « brouillent » pas le fonctionnement normal.
• Les données de résidence/secrets/clés correspondent à la réglementation.
• Économie : egress, stockage, profils de skate auto sous contrôle.

15) TL; DR

Construisez multi-AZ comme une couche de base, multi-région - comme une assurance d'entreprise. Sélectionnez le modèle (active-active/standby) sous RTO/RPO et le coût, répliquez les données en connaissance de cause (quorums/CDC/CRDT), gérez le trafic global via GSLB/Anycast et équilibrage locality-aware. Obligatoire : idempotence, temps courts, exercices de DR réguliers, SLO/métriques sur les tranches région/AZ. Pour iGaming/Finance, ajoutez les PSP/KYC régionaux, les exigences de données et les SLO séparées par pays.