Równoważenie obciążenia i awaria

1) Cele i terminy

Równoważenie rozdziela ruch pomiędzy instancje/strefy/regiony dla wydajności i odporności.
Awaria - kontrolowana awaria.
RTO/RPO - Cel odzyskiwania czasu i dopuszczalna utrata danych.
SLO: docelowy poziom dostępności/opóźnienia; służy jako „brama” do automatycznej feilover i rolki.

2) Warstwy bilansujące

2. 1 L4 (TCP/UDP)

Plusy: wydajność, prostota, TLS passthrough. Minusy: Brak zrozumienia/plików cookie.
Przykłady: NLB/GLB, HAProxy/Envoy L4, IPVS.

2. 2 L7 (HTTP/gRPC)

Plusy: trasa/nagłówki, wagi kanaryjskie, lepkie. Minusy: droższe w procesorze/opóźnienia.
Przykłady: NGINX/HAProxy/Envoy/Cloud ALB/API Gateway.

2. 3 Globalny

DNS/GSLB: kontrole zdrowotne + odpowiedź geo/ważona.
Anycast/BGP: jeden IP na całym świecie, najbliższy punkt ogłoszenia.
CDN/Edge: Cache/Feilover na obwodzie.

3) Algorytmy dystrybucji

Okrągłe/ważone - podstawowe.
Najmniej połączeń/opóźnień - dla „ciężkich” wniosków.
Konsekwentne hashing - lepkość użytkownika/najemcy bez sesji centrum.
Lokalizacja oparta na Hash - dla buforów i usług stacjonarnych.

4) Sesje i lepkie

Cookie-sticky: L7 LB ustawia plik cookie, aby powrócić do instancji.
Src-IP lepki: na L4, gorzej z NAT/CGNAT.
Spójne hashing: lepsze dla poziomych buforów/czatów.
Cel: jeśli to możliwe, wykonaj bezpaństwowca, w przeciwnym razie - wyjąć stan (sesje w Redis/DB) w celu uproszczenia awarii.

5) Niezawodność: kontrola zdrowia i usuwanie z obrotu

Aktywne kontrole: HTTP 200/sondy głębokiej ścieżki biznesowej (np. „/healthz/withdraw ”z zależnościami).
Pasywne (wykrywanie zewnętrzne): wyrzut pleców przy 5xx/timeouts.
Rozgrzewka: płynne włączenie nowych instancji (powolny start).
Graceful drenaż - Usuń z basenu → czekać na żądania, aby zakończyć.

NGINX (przykład):

nginx upstream api {
zone api 64k;
least_conn;
server app-1:8080 max_fails=2 fail_timeout=10s;
server app-2:8080 max_fails=2 fail_timeout=10s;
keepalive 512;
}
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;

Wykrywanie zewnętrzne wysłannika (fragment):

yaml outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

6) Zarządzanie błędami: timeout/retry/circuit-breaking

Timeouts: krótszy niż czas klienta; określić na trasie.
Powtórzenia: 1-2 z jitterem i idempotencją; zakaz przekaźników na POST bez kluczy idempotencji.
Wyłącznik: ograniczenie jednoczesnych żądań/błędów; „półotwarte” odzyskiwanie.
Budżety: Przekwalifikowanie limitów/łączenie pęknięć, aby nie organizować samodzielnego DDOS.

7) Wzory kubernetów

ClusterIP/NodePort/LoadBalancer/Ingress - podstawowe prymitywy.
Gotowość/Urok: ruch tylko na gotowych płytach.
Budżet PodDis nie może jednocześnie upuścić replik N.
HPA/VPA: skalowanie metodą CPU/RED, link do LB.
Topologia/Topologia Aware Wskazówki: lokalizacja według strefy.
Typ usługi = LoadBalancer (strefa): co najmniej 2 repliki w każdej AZ.

Przykład gotowości na trasę krytyczną:

yaml readinessProbe:
httpGet: { path: /healthz/dependencies, port: 8080 }
periodSeconds: 5 failureThreshold: 2

8) Ruch transgraniczny i międzyregionalny

Multi-AZ (w obrębie regionu): równomiernie rozprowadzać (strefa LB), przechowywać - repliki synchroniczne.

Wielobranżowe:

Active-Active: oba regiony obsługują ruch; bardziej złożone - potrzebujesz replikacji danych, spójności i trasy geograficznej.
Active-Passive: główny region służy, rezerwat - "gorący/ciepły/zimny. "Łatwiejsze, szybsze przełączanie, ale wyższe RPO.

Strategie GSLB:

Geo-DNS (najbliższy region).
Ważony DNS (kanary/redystrybucja).
Oparte na opóźnieniach (pomiary RTT).
Failover = przez sygnały zdrowia/dostępności (sondy z wielu punktów widzenia).

9) Dane i awaria

Pamięć podręczna/stan: jeśli to możliwe - regionalnie lokalny; dla Active-Active - CRDT/spójne hashes.

DB:

Replikacja synchroniczna = niski RPO, większa opóźnienie.
Asynchroniczny = niższa opóźnienie, ale RPO> 0.
Kolejki: lusterka/multicluster topicals; deduplikacja zdarzeń.
Projektowanie iempotencji operacji i mechaniki powtórnej.

10) Obwód: DNS/Anycast/BGP/CDN

DNS: krótki TTL (30-60 lat) + kontrola zdrowia poza siecią.
Anycast: kilka POP z jednym IP - najbliższy otrzymuje ruch, feilover jest na poziomie routingu.
CDN/Edge: pamięć podręczna i „brama” do ochrony, statyczne/media są obsługiwane w przypadku upadku pochodzenia; origin-shield + беб-POP zdrowie.

11) Konfiguracje próbki

HAProxy L7:

haproxy defaults timeout connect 2s timeout client 15s timeout server 15s retries 2 option redispatch

backend api balance leastconn option httpchk GET /healthz/dependencies http-check expect status 200 server app1 app-1:8080 check inter 5s fall 2 rise 2 slowstart 3000 server app2 app-2:8080 check inter 5s fall 2 rise 2 slowstart 3000

Plik NGINX sticky ма cookie:

nginx upstream api {
hash $cookie_session_id consistent;
server app-1:8080;
server app-2:8080;
}

Wysłannik retry/timeout (trasa):

yaml route:
timeout: 2s retry_policy:
retry_on: 5xx,connect-failure,reset num_retries: 1 per_try_timeout: 500ms

12) Automatyczne awaryjne: sygnały i bramy

Tech-SLI: 5xx-rate, p95/p99, nasycenie, uściski dłoni TLS, resety TCP.
Business SLI: sukces depozytów/wypłat, brak błędów płatniczych w PSP.
Bramy: w przypadku przekroczenia progów należy wyłączyć strefę/instancję, podnieść wagę puli stabilnej, włączyć GSLB.
Runbook: instrukcja krok po kroku rollback.

13) Testy i inspekcje (chaos i dni gry)

Testy chaosu: wyłączanie AZ/regionów, degradacja DB/pamięci podręcznej, symulacja utraty pakietów.
Dzień gry: Szkolenie Faylover z udziałem zespołów dyżurnych.
Diagnostyka: śledzenie od obwodu do pleców, dopasowanie adnotacji i metryki.

14) Bezpieczeństwo i zgodność

mTLS między LB, WAF/limity stawek na obwodzie.
Strefy awarii/segmentacji: izolacja w promieniu wybuchu.
Polityka: zakaz pojedynczego punktu awarii (SPOF), wymogi dotyczące „minimalnych replik N/AZ”.

15) Anty-wzory

Jedna strefa LB/jedna dla całego ruchu (SPOF).
Brak głębokiej kontroli '/healthz '(zielony - ale DB/kolejka niedostępna).
Przekaźnik bez idempotencji → podwójne transakcje/płatności.
Lepki na IP z masą NAT → nierównowaga.
Feilover DNS z wysokim TTL (godziny przed przełączeniem).
Brak wdzięcznego drenażu po wyczerpaniu - poprosić o przerwę.

16) Lista kontrolna wdrażania (0-45 dni)

0-10 dni

Przypadki post do AZ ≥ 2; umożliwienie gotowości/chęci, kontroli zdrowia.
Konfiguracja L7-timeouts/retries (1 próba), wykrywanie zewnętrzne.
Włącz wdzięczny drenaż i powolny start.

11-25 dni

Wprowadź GSLB (geo/ważone) lub Anycast dla obwodu.
wagi kanaryjskie/polityka tras; lepki przez ciasteczko/spójne hash.
Bramki SLO do auto-feilover (p95/5xx + business SLI).

26-45 dni

DR regionalne: Active-Active lub Active-Passive z testem tłumaczenia.
Dni chaosu z AZ/regiony wyłączone, raporty RTO/RPO.
Zautomatyzowany runbook'i (skrypty pauzy/shift/rollback).

17) Wskaźniki zapadalności

Zasięg multi-AZ ≥ 99% ścieżek krytycznych.
DNS/GSLB/Anycast są wdrażane dla publicznych punktów końcowych.
MTTR, gdy jedna AZ spada <5 minut (p95).
RPO dla danych krytycznych ≤ cel (na przykład ≤ 30 sekund).
Kwartalne dni gry i udane zaplanowane feilover.

18) Wniosek

Niezawodne równoważenie i awaria to architektura warstwowa: L7-policies lokalna (timeouts/retries/CB, health-checks), prawidłowa lepkość i hashing, stabilność strefy poprzecznej oraz na obwodzie - GSLB/DNS/Anycast. Dodaj bramy SLO, idempotencję, wdzięczny drenaż i regularne testy chaosu - a każda utrata węzła, strefy lub nawet regionu stanie się zdarzeniem możliwym do opanowania z przewidywalnym RTO/RPO.

Równoważenie obciążenia i awaria