Équilibrage de charge

1) Pourquoi et où elle est en architecture

• disponibilité (sans point de panne unique), latence (p95 vers le bas), échelle (horizontale), sécurité (TLS/WAF), gestion des sorties (canary/blue-green).

• Edge/Global: Anycast, GSLB/GeoDNS, CDN/Edge-LB, DDoS.
• L4 (TCP/UDP) : NLB, maglev, proxy sans terminaison.
• L7 (HTTP/2, gRPC, WebSocket, QUIC) : routage par chemin/en-têtes/étiquettes, cache/compression/retrai.
• Data-tier: DB-прокси (PgBouncer/ProxySQL), Redis Cluster/Consistent Hash, Kafka partitioning.

2) Modèles et algorithmes d'équilibrage

Round-Robin (RR) : simple uniforme.
Least Connections (LC) : bon pour les connexions longues (WS, gRPC).
Least Request/Power-of-Two (P2C) : comparer deux aléatoires est un bon équilibre vitesse/qualité.
Weighted RR/LC : poids pour canary/nodules « chauds ».
Consistent Hashing (CH) : collant de session sans table (cart, Redis).
Maglev/Flow-hash : distribution rapide L3/L4 avec résistance au flapping.
Latency-aware : choix par glissant p50/p95.
EWMA : prend en compte l'historique des retards.

Recommandation : par défaut, P2C (least-request) sur L7 ; pour le stateful/cache - consistance hash ; для WS/gRPC — least-connections.

3) Santé des aptrimes : contrôles et « expulsions »

Health-checks: TCP, HTTP 200/匹配 тела, gRPC status; intervalles/délais/seuil d'erreur.
Outlier Ejection : auto-exclusion des instances « bruyantes » (consecutive-5xx, success-rate-ejection).
Slow-start & warmup : entrée douce de nouvelles instances (augmentation progressive du poids).
Drainage de connexion : lors de l'arrêt/dégonflage - « coller » les connexions actives sans falaise.

4) Sessions et collantes (stick...)

Cookie-stickiness (L7): `Set-Cookie: lb=<id>; SameSite; Secure`.
CH par la clé : 'hash (userId'sessionId 'cartId)'.
IP-hash - seulement dans les réseaux fermés (NAT casse).
TTL collante + fallback lors de l'évocation du nodule.
Important : réduisez le besoin de collant → gardez la condition hors de l'instance (Redis/DB/JWT).

5) Équilibrage global (GTM/GSLB)

Anycast + health-probe : une IP, trafic vers le PoP le plus proche ; Faylover automatique.
GeoDNS/Latency-DNS : réponse par géo/latence.
Clusters régionaux : les « données des résidents » restent dans la région (RGPD) ; failover interrégional avec réplication.
Politiques : géo-blocs, « autocérégion » par compte/token.

6) Protocoles et caractéristiques

HTTP/2 : multiplex, priorités ; Il faut un pool de connection compétent pour l'apstream.
gRPC : strimes à longue durée de vie, connexions → least, chèques de santé agressifs.
WebSocket/SSE : collant par connect, gros idle-timauts, TCP keep-alive.
QUIC/HTTP/3 : démarrage rapide, résistance à la perte ; suivez MTU/path-MTU.
TLS-Termination/mTLS : terminer sur le edge/L7-LB ; l'intérieur est mTLS/identity (SPIFFE).

7) Protection contre la surcharge (contrôle overload)

Rate-limit: per-IP, per-key, per-route; burst+sustain.
Concordance adaptative (Envoy) : limite dynamique des requêtes simultanées.
Queue/Surge-buffer : taille de file limitée avec un refus honnête 503.
Hedging/Parallel racing : duplication des requêtes lentes (idempotent uniquement).
Timeout budget : connect/read/write séparé.
Backpressure : '503 + Retry-After', retraits exponentiels client avec gitter.
Protection slow-loris : temps de lecture/écriture, vitesse minimale.

8) Sorties et gestion du trafic

Canary (weighted): 1–5–10–25–50–100% с guardrails (p95, 5xx, timeouts).
Bleu-Vert : pull instantané, retour en arrière - DNS/LB.
Shadow/Mirror : copie des demandes sans impact sur la réponse ; masquage du PII.
Header/Claim-routing: `X-Canary: 1` или `JWT. claims. region/role`.

9) Skaling automatique et drainage

HPA/ASG по CPU+RPS+p95+queue-depth.
PreStop hook : attendre la fin des connexions.
Warm pool/instance reuse : réduction des départs à froid.
Capacity planning : cible 'utilisation 60-70 %' à p95 en règle.

10) Observabilité et SLO

Métriques LB : RPS, p50/p95/p99, 4xx/5xx, connexions ouvertes, queue-len, ejections, retries, hit-ratio cache.
Tracing : 'traceparent/x-request-id' via LB → services → OBD.
Logs : structurels, masques PII/PAN, corélation avec apstream.
SLO par itinéraire : par exemple, 'latency p95 ≤ 300 ms', 'availability ≥ 99. 9%`, `5xx ≤ 0. 5%`.
Alerts : par déviation (burn-rate SLO, sursaut d'éjection, croissance 5xx/timeout).

11) Équilibrage des données et des caches

• Read/Write split (ProxySQL/pgpool) + read-replicas; sticky-txn.
• Failover : réplique synchrone pour RPO = 0 (plus cher).

• Redis Cluster + hash-slot; pour les sessions - CH ; Timeouts/Retryable errors.

• Équilibre par le partitioning et les groupes consommateurs ; ne pas confondre avec HTTP-LB.
• Object Storage (S3/MinIO): multi-region failover через GSLB/replication.

12) LB K8s et cloud

Service (ClusterIP/NodePort/LoadBalancer) - L4 de base.
API Ingress/Gateway - routage L7, poids canaris, TLS.
AWS : NLB (L4, haut débit), 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) Exemples de configurations

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) Chèques-feuilles

Avant la sortie de LB/route

• L'algorithme est sélectionné (P2C/LC/CH) sous le type de trafic.
• Les critères de santé et les seuils d'éjection sont configurés.
• Slow-start, warmup, connection-drain inclus.
• TLS/mTLS, HSTS, codes sécurisés ; HTTP/2/3 si nécessaire.
• Sticky/CH seulement si nécessaire ; TTL и fallback.
• Rate-limit/burst, timeouts, retry-budget, adaptive concurrency.
• Logs/tracés : "trace-id'est projeté ; masquage du PII.
• SLO/alertes par p95/5xx/elections/queue-len.
• Poids canaris + plan de retrait ; shadow avec de grands changements.

Pour les itinéraires de paiement/conformité

• Idempotence POST (Idempotency-Key).
• Échec entre PSP ; Vérification par same-method.
• Les codes d'erreur sont normalisés ; ETA/raisons par client.

Pour les bases de données/caches

• RW-split/répliques ; Timaouts, retri-réseau.
• CH/slot-hash pour Redis ; protection contre les « clés chaudes ».
• Suivi des retards et replication-lag.

15) Métriques de qualité (minimum)

Latitude p50/p95/p99 par itinéraires/méthodes.
Error rate 4xx/5xx, timeout/overflow.
Open/active connections, queue depth, retry count.
Edition Outlier et raisons.
Sticky hit-ratio / cache hit-ratio.
GSLB : répartition régionale, faussaires, disponibilité PoP.

16) Anti-modèles

Un LB monolithique sans réservation.
Sticky-session « tout », au lieu de retirer l'état.
Files d'attente infinies mondiales (cacher le problème, pousser p99).
Retrai sans jitter/budget - « tempête » de demandes.
Trust 'X-Forwarded-For' sans liste de proxy de confiance.
Pas de drain pour les débris → les falaises WS/gRPC.
Ne tient pas compte des connexions longues et livrées dans le skate automatique.

17) iGaming-spécificité

Pics et tournois : micro-cache sur les annuaires/listes (1-5 s), auto-skale à tour de rôle.
Live games/streams : LC pour les longs connexions, priorité des PoP les plus proches.
Paiements : routage par géo/devise/montant/fournisseur ; le délai strict et l'idempotence.
Jeu responsable et conformité : priorité à passer les demandes de limitation/verrouillage même en cas de dégradation (fail-open/close par politique).

18) Processus de mise en œuvre (4 sprints)

1. Carte du trafic : protocoles, charges p95/p99, itinéraires critiques.
2. Configuration LB : algorithmes, santé/outlier, TLS, limites/délais, observabilité.
3. GSLB/Edge : Anycast/GeoDNS, chèques PoP, politiques régionales de données.
4. Stratégie de sortie : canary/shadow, SLO-alertes, auto-scale + drain, post-incident.

La trappe finale

Sélectionnez l'algorithme sous le type de trafic (P2C/LC/CH) et la durée du connecteur.
Gardez les apstrymes « sains » : health-checks + outlier + slow-start + drain.
Contrôlez la charge de pointe : rate-limit, concurrency adaptive, file d'attente en panne.
Utilisez GSLB/Anycast pour la disponibilité globale et la conformité par région.
L'observation et le SLO sont obligatoires ; sorties - via canary/shadow avec plan de retour.
Si possible, retirez la session des instances et la collante de LB.