Równoważenie obciążenia w operacjach

1) Dlaczego zespół operacyjny musi zarządzać bilansowaniem

Równoważenie obciążenia nie dotyczy tylko dystrybucji zapytań. Jest to warstwa zarządzania ryzykiem i wynikami: ograniczenie promienia awarii, przewidywalne opóźnienia, korzyści skali, izolacja „hałaśliwych sąsiadów”, bezpośredni wpływ na realizację SLO i koszty incydentów.

2) Warstwy bilansujące: Sieć do operacji biznesowych

L3/L4 (IP/port): proste i szybkie (DSR, ECMP, IPVS, LVS). Idealny do usług TCP/UDP, brokerów, bram.
L7 (HTTP/gRPC/WebSocket): routing ścieżki/nagłówka/metadanych; polityka kanaryjska, A/B, geo i świadomość klienta.
GSLB/GeoDNS/Anycast: globalna dystrybucja według regionów/RoR, opóźnienie, bliskość i zdrowie regionalne.
Równoważenie wewnątrz usługi: klienci z odkryciem usług (xDS, konsul, Eureka), balancery klienta (gRPC pick_first/round_robin), siatka serwisowa.

3) Algorytmy dystrybucji i kiedy je stosować

Round-Robin (RR): Prosta obudowa podstawowa dla jednorodnych węzłów i krótkich zapytań.
Najmniejsze połączenia (LC): lepsze dla różnych okresów zapytania.
Least Request/Peak EWMA: adaptacyjnie zmniejsza opóźnienia dla „długich” żądań i hałasu.
Ważony RR/LC: uwzględnia moc węzłów lub „bariery kosztowe”.
Spójne Hashing (Rendezvous/Maglev): dla klawiszy lepkich (użytkownik, stół/pokój, koszyk), zmniejsza zmianę trasy podczas skalowania.
Moc dwóch wyborów: Dobre przybliżenie LC przy dużym obciążeniu przy mniejszej telemetrii.
Hedged/Retry Budgeted Requests: równoległe wnioski o nadrobienie zaległości z przekwalifikowaniem budżetu na p99.

4) Sesje, stan i lepkość

Sesje sticky (cookie/IP/identifier) - gdy pamięć podręczna jest zaludniona lokalnie lub istnieje stanowczy kontekst (na przykład stół na żywo w iGaming).
Minusy: efekt hotspot, trudniej jest ewakuować węzły.
Rozwiązanie: krótka lepkość TTL, przeniesienie stanu do sklepów zewnętrznych (Redis, sklep sesyjny), udostępnianie-nic i event-sourcing tam, gdzie to możliwe.

5) Kontrole zdrowotne i ochrona przed klapami

L7 kontroli zawartości (asssert według ciała/nagłówka) zamiast 200-as-sukces.
Próbki połączone: TCP + HTTP + wewnętrzne '/gotowe 'z różnymi terminami.
Debowns: n awarie → wyjątek; m sukcesy → powrót do puli.
Wykrywanie zewnętrzne - automatyczne wyłączenie węzłów o wysokiej prędkości błędu/opóźnienia (wyrzut).

6) Polityka Timeout, Retray i Backpressure

Przekaźniki zorientowane na budżet: ograniczenie całkowitego czasu użytkowania (na przykład 800 ms SLA → retriable 2 × 200 ms + margines).
Wyłączniki: ograniczają jednoczesne żądania/połączenia/błędy.
Limity kwot/stawek: domyślne limity „per-najemca/per-IP/per-key” na samej krawędzi.
Kolejkowanie po stronie serwera: krótkie kolejki lub awaria z oczywistą degradacją, aby nie „overclock” ogon opóźnienia.

7) Globalna tolerancja bilansowania i błędów

Geo-routing: latency-based, customer region, health.
Anycast + sondy zdrowotne: natychmiastowa konwergencja tras w miarę upadku PoP.
Hierarchia awaryjna: RoR → region → oblako; zimno/ciepło/gorąco DR.
Partytura drogowa: izolacje produktowe/prawne (kraje, dostawcy płatności, segmenty VIP).

8) Równoważenie nici i czasu rzeczywistego

WebSocket/SSE/gRPC-stream: długoterminowe połączenia → monitorowanie połączeń/węzła, redystrybucja w skali-out.
Przyklejone przez użytkownika lub przez pokój/stół poprzez konsekwentne hashing.
Drenaż/PreStop Haki: prawidłowo eksmitować połączenia podczas uwalniania i autoskale.

9) Bezpieczeństwo na obwodzie

zakończenie TLS, HSTS, ALPN; mTLS na wschód-zachód.
Zarządzanie WAF/bot do balancera aplikacji.
DDoS-бавита: limity stawek, challenge-/proof-of-work, scrubbing upstream.
Polityka jako kod (OPA/Kyverno/Envoy RBAC).

10) Obserwowalność i SLO dla bilansowania

SLI: udane żądania, błąd/sec, opóźnienie p50/p95/p99, nasycenie (CPU/conn/epoll).
Na-backend metryki: szybkość żądania, błąd, EWMA-latency → wejście do algorytmów.
Dzienniki L7: korelują z wydaniami (adnotacjami), flagami funkcji, kanarkami.
Allerts: zgodnie z szybkością spalania budżetu błędu i zgodnie z objawami klienta (syntetyka zewnętrzna).

11) Automatyczne skalowanie i opłacalność

HPA/VPA/KEDA: skalowanie przez RPS, kolejki, mierniki użytkownika.
Ważona trasa według kosztów: Tańsze regiony/chmury otrzymują większą wagę przy normalnym obciążeniu.
Ciepłe baseny/ogrzewane: wstępnie ocieplone okazy, aby nie „złapać” zimnego początku.

12) Zarządzanie zmianą: kanaryjski, cień, niebiesko-zielony

Routing kanaryjski: 1% → 5% → 25% z automatycznym zatrzymaniem w warunkach degradacji SLO.
Ruch cieni: duplikat żądań do nowej wersji bez odpowiedzi na klienta (do walidacji).
Niebiesko-zielony: przełączanie stołu VIP/routingu; szybki zwrot.

13) Konfiguracja i GitOps

Jedno źródło prawdy: trasy, wagi, terminy i zasady limitowania - w repozytorium.
Promocja konfiguracji w środy (dev → etap → prod) przez ten sam rurociąg.
Testy walidacji i konfiguracji: lintery, dry-run, symulacja mapy ruchu.

14) Sprawy prywatne (dziedziny regulowane)

Dostawcy płatności/CCS: kanały równoległe, przełączanie przez czas jakości/odpowiedzi; na dostawcę SLO.
Jurysdykcja wielonarodowa: geo-routing, treść/polityka limitowania według krajów.
Segmenty VIP: indywidualne wagi/kanały, podwyższone SLO, „uchwyty” degradacji UX.

15) Anty-wzory

Jeden balancer jako „jeden punkt porażki”.
Sticky over IP za NAT - „lepkie” klastry i skew ruchu.
Uniwersalny RR dla ciężkich/długich żądań - wzrost ogona p99.
Rekolekcje bez budżetu i bez idempotencji to burza próśb.
Kontrola zdrowia tylko TCP - „zielony”, gdy aplikacja nie działa.
„Wieczne” sesje klejące bez TTL - niemożność ewakuacji węzłów.
Konfiguracje są edytowane ręcznie, bez przeglądu i promocji - dryf i incydenty.

16) Lista kontrolna wdrażania

• Wybrany poziom: L4/L7/GSLB, określone cele i obowiązki.
• Algorytm dystrybucji odpowiada profilowi obciążenia (EWMA/LC/Hash).
• Konsekwentne hashing tam, gdzie potrzebny jest kontekst stanowy.
• Połączone kontrole zdrowotne, wytrącanie z rynku zewnętrznego, debunks.
• Terminy/rekolekcje/limity - jak kod, z budżetami czasowymi.
• Obserwowalność na tył i syntetyka klienta; ostrzeżenia o prędkości oparzenia.
• Ruch kanaryjski/niebiesko-zielony + cień; szybki zwrot.
• GitOps dla konfiguracji; próby na sucho i na trasie.
• Plan DR i hierarchia awaryjna (RoR → region → oblako).
• Izolacja VIP/prawnych kohort i dostawców.

17) Przykład przepływu architektonicznego

1. GSLB (latency-based) kieruje klienta do najbliższego zdrowego regionu.
2. Edge/L7 balancer stosuje WAF, TLS, limity stawek, 5% kanarka.
3. Siatka serwisowa dystrybuuje do boisk z LC + EWMA z wyłączeniem odstających.
4. Dla tabel w czasie rzeczywistym - spójne hashing przez 'table _ id', sticky TTL 10 min.
5. Skala HPA obejmuje RPS i kolejki; ciepły basen → brak zimnego startu.
6. Obserwowalność: deska rozdzielcza p50/p95/p99, szybkość błędów, nasycenie, szybkość spalania.
7. W przypadku degradacji: węzły automatycznego wyrzutu, redukcja kanarów, przełączenie do dostawcy zapasowego, rolka wersji.

18) Najważniejsze

Równoważenie obciążenia jest dyscypliną operacyjną, która łączy sieć, aplikację, dane i SLO biznesowe. Odpowiednio dobrany poziom (L4/L7/GSLB), odpowiednie algorytmy, ścisłe kontrole zdrowotne, polityka timeout i retrace, obserwowalność i zarządzanie GitOps przekształcają równoważenie z „box with settings” w mechanizm zrównoważonego i ekonomicznego świadczenia usług.