Lastausgleich

1) Warum und wo es in der Architektur ist

• Verfügbarkeit (kein Single Point of Failure), Latenz (p95 nach unten), Skalierung (horizontal), Sicherheit (TLS/WAF), Verwaltbarkeit der Releases (canary/blue-green).

• Edge/Global: Anycast, GSLB/GeoDNS, CDN/Edge-LB, DDoS.
• L4 (TCP/UDP): NLB, Maglev, Proxy ohne Terminierung.
• L7 (HTTP/2, gRPC, WebSocket, QUIC): Routing über Pfad/Header/Stempel, Cache/Komprimierung/Retrays.
• Data-tier: DB-прокси (PgBouncer/ProxySQL), Redis Cluster/Consistent Hash, Kafka partitioning.

2) Auswuchtmodelle und Algorithmen

Round-Robin (RR): einfach einheitlich.
Least Connections (LC): Gut für lange Anschlüsse (WS, gRPC).
Least Request/Power-of-Two (P2C): Vergleich von zwei zufälligen - gute Balance von Geschwindigkeit/Qualität.
Weighted RR/LC: Gewichte für kanarische/„ heiße “Knoten.
Consistent Hashing (CH): Sitzungsklebrigkeit ohne Tabelle (cart, Redis).
Maglev/Flow-Hash: schnelle L3/L4-Distribution mit Flapping-Resistenz.
Latenz-aware: Auswahl durch gleitende p50/p95.
EWMA: berücksichtigt die Geschichte der Verzögerungen.

Empfehlung: Standardmäßig P2C (least-request) auf L7; für stateful/caches - consistent hash; для WS/gRPC — least-connections.

3) Gesundheit von Upstreams: Kontrollen und „Vertreibung“

Health-checks: TCP, HTTP 200/匹配 тела, gRPC status; Intervalle/Timeouts/Fehlerschwelle.
Outlier Ejection: automatischer Ausschluss von „lauten“ Instances (consecutive-5xx, success-rate-ejection).
Slow-Start & Warmup: sanfte Einführung neuer Instanzen (allmähliche Gewichtszunahme).
Verbindungszeichnung: wenn aus/deploy - „Nachfüllen“ von aktiven Verbindungen ohne Klippe.

4) Sitzungen und Klebrigkeit (stickiness)

Cookie-stickiness (L7): `Set-Cookie: lb=<id>; SameSite; Secure`.
CH durch den Schlüssel: 'hash (userId' sessionId 'cartId)'.
IP-Hash - nur in geschlossenen Netzwerken (NAT bricht).
TTL Klebrigkeit + Fallback bei Node eviction.
Wichtig: Minimieren Sie die Notwendigkeit der Klebrigkeit → speichern Sie den Zustand außerhalb der Instance (Redis/DB/JWT).

5) Global Balancing (GTM/GSLB)

Anycast + health-probe: eine IP, Verkehr zum nächsten PoP; automatischer Failover.
GeoDNS/Latency-DNS: Antwort nach Geo/Latenz.
Regionale Cluster: „Resident Data“ bleibt in der Region (DSGVO); interregionaler Failover mit Replikation.
Politik: Geo-Blöcke, „stickeregion“ durch Konto/Token.

6) Protokolle und Merkmale

HTTP/2: Multiplex, Prioritäten; benötigen einen kompetenten Verbindungspool für den Upstream.
gRPC: langlebige Streams → Least-Connections, aggressive Health-Checks.
WebSocket/SSE: Klebrigkeit durch Anschluss, große Idle-Timeouts, TCP Keep-Alive.
QUIC/HTTP/3: schneller Start, Widerstand gegen Verlust; MTU/Patch-MTU beachten.
TLS-Termination/mTLS: auf edge/L7-LB terminieren; nach innen - mTLS/Identität (SPIFFE).

7) Überlastschutz (Überlastungskontrolle)

Rate-limit: per-IP, per-key, per-route; burst+sustain.
Adaptive Concurrency (Envoy): Dynamische Grenze für gleichzeitige Abfragen.
Queue/Surge-buffer: begrenzte Warteschlangengröße mit ehrlicher Ablehnung 503.
Hedging/Parallel Racing: Duplizieren von langsamen Anfragen (nur idempotent).
Timeout-Budget: getrennte connect/read/write.
Backpressure: '503 + Retry-After', Client exponentielle Retrays mit Jitter.
Slow-loris-Schutz: Lese/Schreib-Timeouts, Mindestgeschwindigkeit.

8) Freigaben und Traffic-Management

Canary (weighted): 1–5–10–25–50–100% с guardrails (p95, 5xx, timeouts).
Blau-Grün: Instant-Switch, Rollback - DNS/LB.
Shadow/Mirror: Kopie der Anfragen ohne Einfluss auf die Antwort; Maskierung von PII.
Header/Claim-routing: `X-Canary: 1` или `JWT. claims. region/role`.

9) Autoscale und Entwässerung

HPA/ASG по CPU+RPS+p95+queue-depth.
PreStop-Haken: Warten Sie, bis die Anschlüsse fertig sind.
Warmschwimmbad/Instanzreuse: Reduzierung von Kaltstarts.
Kapazitätsplanung: Ziel 'utilization 60-70%' bei p95 ist normal.

10) Beobachtbarkeit und SLO

LB-Metriken: RPS, p50/p95/p99, 4xx/5xx, open-connections, queue-len, ejections, retries, hit-ratio des Cache.
Traceparent/x-request-id durch LB → Dienste → DB.
Protokolle: strukturell, PII/PAN-Masken, Korrelation mit dem Apstrom.
SLO entlang der Route: zum Beispiel "latency p95 ≤ 300 ms", "availability ≥ 99. 9%`, `5xx ≤ 0. 5%`.
Alerts: durch Abweichungen (burn-rate SLO, ejection splash, 5xx/timeout growth).

11) Daten und Caches ausgleichen

• Read/Write split (ProxySQL/pgpool) + read-replicas; sticky-txn.
• Failover: synchrones Replikat für RPO = 0 (teurer).

• Redis Cluster + hash-slot; für Sitzungen - CH; timeouts/Retryable errors.

• Balance durch Partitionierung und Verbrauchergruppen; Nicht zu verwechseln mit HTTP-LB.
• Object Storage (S3/MinIO): multi-region failover через GSLB/replication.

12) K8s und Cloud-LBs

Service (ClusterIP/NodePort/LoadBalancer) - Basis-L4.
Ingress/Gateway API - L7-Routing, Kanariengewichte, TLS.
AWS: NLB (L4, hohe Bandbreite), ALB (L7, WAF, Sticky, Header-Routing).
GCP: Global LB (L7/HTTP(S) с Anycast), TCP/UDP proxy LB.
Azure: Front Door (global), Application Gateway (L7), Load Balancer (L4).

13) Beispiele für Konfigurationen

13. 1 NGINX (L7, least_conn, sticky, canary)

nginx upstream api_pool {
least_conn;
server api-1:8080 max_fails=3 fail_timeout=10s;
server api-2:8080 max_fails=3 fail_timeout=10s;
sticky cookie lb_id expires=30m path=/ secure httponly;
}

map $http_x_canary $dst {
default api_pool;
1    canary_pool;
}

upstream canary_pool {
least_conn;
server api-canary:8080 weight=1;
}

server {
listen 443 ssl http2;
location /api/ {
proxy_read_timeout 5s;
proxy_connect_timeout 1s;
proxy_set_header X-Request-Id $request_id;
proxy_pass http://$dst;
}
}

13. 2 HAProxy (P2C, health, slowstart, stick-table)

haproxy backend api balance leastconn option httpchk GET /health default-server inter 3s fall 3 rise 2 slowstart 10s server s1 10. 0. 0. 11:8080 check server s2 10. 0. 0. 12:8080 check stick-table type ip size 100k expire 30m http-request track-sc0 src rate limit per IP http-request deny deny_status 429 if { sc_http_req_rate(0) gt 50 }

13. 3 Envoy (P2C, outlier, retries, adaptive concurrency)

yaml load_assignment: {... }
lb_policy: LEAST_REQUEST least_request_lb_config: { choice_count: 2 }
outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s typed_extension_protocol_options:
envoy. extensions. filters. http. adaptive_concurrency. v3. AdaptiveConcurrency:
gradient_controller_config:
sample_aggregate_percentile: PERCENTILE_50 retry_policy:
retry_on: "5xx,reset,connect-failure"
num_retries: 2 per_try_timeout: 1s

13. 4 Kubernetes (Gateway API, weighted canary)

yaml apiVersion: gateway. networking. k8s. io/v1 kind: HTTPRoute spec:
rules:
- matches: [{ path: { type: PathPrefix, value: /api }}]
backendRefs:
- name: api-v1 weight: 90 port: 8080
- name: api-v2-canary weight: 10 port: 8080

14) Checklisten

Vor der Freigabe der LB/Route

• Der Algorithmus ist ausgewählt (P2C/LC/CH) für die Art des Verkehrs.
• Health-checks und ejection Schwellenwerte sind konfiguriert.
• Slow-Start, Warmup, Verbindung-Drain enthalten.
• TLS/mTLS, HSTS, sichere Chiffren; HTTP/2/3 wenn nötig.
• Sticky/CH nur bei Bedarf; TTL и fallback.
• Rate-limit/burst, timeouts, retry-budget, adaptive concurrency.
• Logs/Traces: 'trace-id' wird durchquert; Maskierung von PII.
• SLO/alert by p95/5xx/elections/queue-len.
• Kanariengewichte + Rollback-Plan; Schatten bei großen Veränderungen.

Für Zahlungs-/Compliance-Routen

• POST-Idempotenz (Idempotency-Key).
• Failover zwischen PSPs; same-method Überprüfung.
• Die Fehlercodes sind normalisiert; ETA/Gründe pro Kunde.

Für DB/Caches

• RW-Split/Replikate; Timeouts, Netzwerk-Retrys.
• CH/slot-hash für Redis; Schutz vor „heißen Schlüsseln“.
• Überwachung von Latenzen und Replikation-lag.

15) Qualitätskennzahlen (Minimum)

Latency p50/p95/p99 nach Routen/Methoden.
Error rate 4xx/5xx, timeout/overflow.
Open/active connections, queue depth, retry count.
Outlier ejections und Ursachen.
Sticky hit-ratio / cache hit-ratio.
GSLB: regionale Verteilung, Failover, PoP-Verfügbarkeit.

16) Anti-Muster

Eine monolithische LB ohne Redundanz.
Sticky-Sessions „für alles“, anstatt die Bedingung zu nehmen.
Globale endlose Warteschlangen (verstecken das Problem, wachsen p99).
Retrays ohne Jitter/Budget sind ein „Sturm“ von Anfragen.
Vertrauen 'X-Forwarded-For' ohne Liste der vertrauenswürdigen Proxies.
Kein Drain bei Deploys → WS/gRPC-Brüche.
Ignoriert Long-Lived-Anschlüsse beim Auto-Scale.

17) iGaming-Spezifität

Spikes und Turniere: Micro-Cache auf Verzeichnissen/Listen (1-5 s), Auto-Scale der Reihe nach.
Live-Spiele/Streams: LC für lange Verbindungen, Priorität der nächsten PoP.
Zahlungen: Routing nach Geo/Währung/Betrag/Anbieter; strenge Timeouts und Idempotenz.
Verantwortungsvolles Spielen und Compliance: Priorität, Grenz-/Sperranforderungen auch bei Degradierung zu überspringen (fail-open/close per Policy).

18) Umsetzungsprozess (4 Sprints)

1. Verkehrskarte: Protokolle, p95/p99-Lasten, kritische Routen.
2. LB-Konfiguration: Algorithmen, Health/Outlier, TLS, Limits/Timeouts, Observability.
3. GSLB/Edge: Anycast/GeoDNS, PoP-Helschecks, regionale Datenrichtlinien.
4. Release-Strategie: Canary/Shadow, SLO-Alerts, Auto-Scale + Drain, Post-Incident-Analyse.

Abschließender Spickzettel

Wählen Sie einen Algorithmus für die Art des Verkehrs (P2C/LC/CH) und die Dauer des Anschlusses.
Halten Sie den Upstream „gesund“: health-checks + outlier + slow-start + drain.
Verwalten Sie die Spitzenlast: Rate-Limit, adaptive Concurrency, Warteschlangen mit Ausfall.
Nutzen Sie GSLB/Anycast für globale Verfügbarkeit und regionale Compliance.
Beobachtbarkeit und SLO - obligatorisch; releases - via canary/shadow mit Rollback-Plan.
Wo möglich, entfernen Sie die Sitzungsfähigkeit von Instances und die Klebrigkeit von LB.