Strefy dostępności i regiony krzyżowe
1) Warunki i cele
Strefa dostępności (AZ) - odizolowane centrum danych w regionie (własna pojemność/sieć).
Region - grupa AZ o wspólnej geografii i opóźnieniach.
- RTO (Recovery Time Objective) - ile czasu nie można zapewnić usługi.
- RPO (Recovery Point Objective) - ile danych można stracić.
Zazwyczaj: w obrębie regionu dążymy do RTO ≤ 5-15 minut, RPO ~ 0-1 minut, międzyregionalnie - RTO ≤ 1 godzina, RPO ≤ 5 minut (w zależności od produktu i budżetu).
2) Modele architektoniczne
2. 1 Wewnątrz regionu (multi-AZ)
Warstwa bezpaństwowa: rozłożona na AZ; bilansowanie - L4/L7 z kontrolami zdrowotnymi.
Warstwa statywna: klastry z synchroniczną replikacją (lub kworum) między AZ.
Cache/kolejki: klastrowane, z AZ shading i automatyczne awaryjne.
2. 2 Międzyregionalne (wielobranżowe)
Active-Active: Oba regiony otrzymują ruch.
Minimalna opóźnienie użytkownika, szybkie odzyskiwanie, − spójność i złożoność konfliktu
Aktywny-pasywny (gorący/ciepły): główny region służy, drugi - w gorącym/ciepłym oczekiwaniu.
prostsze dane, tańsze; − wyższe RTO.
Pilot-Light: minimalne „światło” (dane są synchronizowane, obliczenia rozwijają się w razie wypadku).
Kopia zapasowa DR: tylko kopie zapasowe i scenariusz odzyskiwania (najtańszy i najwolniejszy).
3) Dane i spójność
3. 1 Bazy danych
Kworum synchroniczne (RPO ≤ 0, latentnost): PostgreSQL z synchronicznymi standbys w regionie; rozproszone bazy danych (CockroachDB/Cassandra) z lokalnymi kworumami (Local Quorum) i bilansowaniem AZ.
Asynchroniczne międzyregionalne (RPO> 0, latentnost): logiczne replikacje Postgres/MySQL; „tabele globalne” - KV/NoSQL; CDC → strim do innego regionu.
Sprzeczne wpisy: W przypadku aktywnego użycia CRDT/versioning lub leader-region na klucz/najemcę.
3. 2 Zdarzenia i kolejki
Kolejki/strumienie (Kafka/Pulsar/SQS-like): lusterka-tematy lub replikatory międzyregionalne; klucz - idempotencja konsumentów i impas klucza.
Haki internetowe i partnerzy zewnętrzni: sign, have replay, store offset/checkpoints in both zones.
3. 3 Środki pieniężne
bufory lokalne na region (odpis/odświeżanie); globalny wspólny pamięć podręczna tylko dla trwałych KV (aka split-brain). Wyłączenie przez wydarzenie (pub/sub), TTL - konserwatywne.
4) Globalny ruch i pętla sieciowa
GSLB/DNS: trasy oparte na geo-/latencji, kontrole zdrowotne, wagi ruchu dla kanarni i wypadków.
Anycast/Edge: zbliżamy wejście do użytkownika, a następnie do najbliższego zdrowego regionu.
Polityka awaryjna: regionalne rezerwy w górę rzeki, zakaz 0-RTT na ścieżkach krytycznych, niskie czasy zależności międzyregionalnej.
Polityka retrasy: wykładnicze backoff + jitter, ograniczenie terminowe, idempotent PUT/POST z „Idempotence-Key”.
5) Kubernety i siatka serwisowa
5. 1 Multi-AZ w jednym klastrze
topologia rozprzestrzenia się w ograniczeniach dotyczących topologii. kubernetes. io/strefa ".
Klasa priorytetowa budżetu PodDis .
Powinowactwo węzłowe/anty-powinowactwo - Unikać repliki co-location.
Miejsca przechowywania: PV z replikacją AZ lub rozproszonymi systemami głośności.
5. 2 Wielobranżowe (wielomianowe)
Oddzielne klastry na region + GitOps (Argo CD/Flux) do synchronizacji deklaracyjnej.
Siatka serwisowa (Istio/Linkerd): równoważenie obciążenia i awaria między regionami ze względu na lokalizację; mTLS, wspólna tożsamość.
Przesunięcie ruchu: stopniowo 1% → 10% → 50% do nowego regionu; uchwyt „umieścić 0%” natychmiast.
6) Wybór RTO/RPO i wiązanie wzoru
7) Badanie tolerancji błędów (DR)
GameDays: Scenariusz kwartalny „region/AZ out”.
Zastrzyki chaosu: opóźnienia sieciowe, straty pakietów, odłączenie brokera/bazy w jednym AZ.
RTO/RPO rzeczywiste: pomiar czasu przełączania i utraty danych, publikacja raportu.
Książki startowe: instrukcje krok po kroku i „czerwone przyciski” do przełączania (wagi DNS, flagi funkcji, wyłączanie ciężkich funkcji).
8) Obserwowalność i zarządzanie
plasterki metryczne według regionu/AZ/najemca; p95/p99 opóźnienie trasy.
Budżety SLO i błędów na region i na globalną pulę.
Wpisy: degradacja jednego regionu nie powinna przywoływać „dżemu”, jeśli drugi normalnie przewozi ruch.
Треса: bagaż „region”, „az”, „failover = true/false”; „Ile próśb poszło do awarii”.
9) Bezpieczeństwo i zgodność
Miejsce zamieszkania danych: powiązanie danych dotyczących PII/płatności z określonymi regionami (jurysdykcją).
Sekrety: KMS/inteligentny HSM z przekrojowymi klawiszami i rotacją; Oddzielne kluczowe materiały dla każdego regionu.
mTLS i wzajemne zaufanie między regionami; ograniczenie międzyregionalnego wyjścia przez ACL.
10) Koszty i oszczędności
Krawędź pamięci podręcznej + SWR - zmniejszenie międzyregionalnego wyjścia.
Różne klasy przechowywania (gorący/ciepły/zimny) i metryki/dzienniki downsampling.
Profile autokalibrowe według regionu (minimum nocne).
Tożsamość obrazu + zróżnicowana konfiguracja za pomocą zmiennych środowiskowych/wartości Helm.
11) Antypattery
Jeden Statious Master na system; podział mózgu bez kworum.
Międzyregionalne synchroniczne pisanie do pojedynczego RDBMS (nieznośne opóźnienie).
Globalny pamięć podręczna o silnej konsystencji bez CRDT → zatory i fantomy.
Przekłada bez idempotencji → duplikat transakcji/płatności.
Pojedynczy „globalny” SLO - ukrywa porażkę jednego regionu.
Nie ma regularnych ćwiczeń DR - plany są nieoperacyjne w walce.
12) Szczegóły dotyczące iGaming/Finance
Dostawcy płatności/CCP są wybierani regionalnie; robić inteligentne routing przez PSP z sygnałami zdrowotnymi, niepowodzenie kopii zapasowej.
jurysdykcja: przechowywanie dzienników transakcji PII i w kraju/regionie; cross-region - tylko agregaty/anonimowe.
Limity/odpowiedzialna zabawa: lokalne zasady i godziny - nie replikować „głowa-on” między regionami, używać spójności wydarzeń.
Bonusy/saldo: idempotentne klucze i „źródło prawdy” na lokatora/region; pogodzić się z pracą po DR.
13) Mini przepisy (pseudo-liczby)
13. 1 Wysłannik świadomy lokalizacji + awaria
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 Topologia kubernetów
yaml spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }13. 3 DNS Waga Feilover (pomysł)
"waga (ue) = 90", "waga (us) = 10" → po zdegradowaniu "eu 'automatycznie przechodzi do" nas ". Kontrole zdrowotne i obniżone TTL (ale nie zbyt agresywne, 30-120 s).
14) Lista kontrolna gotowości Prod
- RTO/RPO na usługę zdefiniowaną i uzgodnioną z firmą.
- Bezpaństwowiec dystrybuowany w całej AZ; statyczny ma kworum/replikację i wyraźny model spójności.
- Replikacja przekrojowa (asynchron/CDC), badania zderzeniowe/deduplicacyjne.
- GSLB/Anycast są skonfigurowane, kontrole zdrowotne i wagi są zautomatyzowane.
- Kubernetes: topologia-spread, PDB, anty-powinowactwo; multi-cluster GitOps.
- Retrai z jitterem, idempotencja na piśmie; krótkie czasy międzyregionalnie.
- ćwiczenia DR, zmierzone rzeczywiste RTO/RPO; bieżąca książka startowa.
- Obserwowalność według regionu/AZ, SLO i szybkość spalania na sekcjach, wpisy nie „dżem” normalnej pracy.
- Rezydencja/tajemnice/klucze danych są zgodne z wymogami regulacyjnymi.
- Ekonomia: egress, przechowywanie, profile autoskalowe pod kontrolą.
15) TL; DR
Zbuduj multi-AZ jako warstwę bazową, wielobranżową jako ubezpieczenie biznesowe. Wybierz wzór (aktywny/czuwający) dla RTO/RPO i kosztów, powielaj dane świadomie (kworums/CDC/CRDT), zarządzaj globalnym ruchem za pośrednictwem GSLB/Anycast i równoważenia świadomego lokalizacji. Obowiązkowe: idempotencja, krótkie czasy, regularne ćwiczenia DR, SLO/metryki na kawałki regionu/AZ. W przypadku iGaming/Finance dodaj regionalny PSP/KYC, wymagania dotyczące danych i podziel SLO według jurysdykcji.