Équilibrage de charge et échec

Équilibrage de charge et échec

1) Objectifs et termes

L'équilibrage répartit le trafic entre les instances/zones/régions pour la performance et la durabilité.
Failover - basculement contrôlé en cas de panne.
RTO/RPO : temps de récupération cible et perte de données admissible.
SLO : niveau cible de disponibilité/latence ; sert de « porte » pour le faussaire automatique et le recul.

2) Couches d'équilibrage

2. 1 L4 (TCP/UDP)

Avantages : performance, simplicité, TLS passthrough. Inconvénients : aucune compréhension de l'itinéraire/cookies.
Exemples : NLB/GLB, HAProxy/Envoy L4, IPVS.

2. 2 L7 (HTTP/gRPC)

Avantages : routage sur le chemin/headers, poids canaris, sticky. Inconvénients : plus cher par CPU/latence.
Exemples : NGINX/HAProxy/Envoy/Cloud ALB/API Gateway.

2. 3 Niveau mondial

DNS/GSLB : health-checks + réponse géo/pondérée.
Anycast/BGP : une IP dans le monde, le point d'annonce le plus proche.
CDN/Edge : cache/faussaire sur le périmètre.

3) Algorithmes de distribution

Round-robin/weighted - de base.
Least connections/latency - pour les demandes « lourdes ».
Consistance hashing - adhésif par clé (user/tenant) sans session de centre.
Hash-based locality - pour les caches et les services stateful.

4) Sessions et adhésifs (sticky)

Cookie-sticky : L7 LB installe un cookie pour revenir à l'instance.
Sticky src-IP : sur L4, pire avec NAT/CGNAT.
Consistent hashing : Mieux pour les caches/chats horizontaux.
S'il est possible de faire le service stateless, sinon, sortez l'état (sessions dans Redis/DB) pour simplifier l'échec.

5) Fiabilité : Santé-checks et sortie de rotation

Active checks : HTTP 200/échantillons profonds du chemin d'affaires (par exemple, '/healthz/withdraw 'avec des dépendances).
Passive (outlier detection) : éjection des backends à 5xx/taimauts.
Warm-up : incluez en douceur de nouvelles instances (slow-start).
Graceful drain : supprimer du pool → attendre que les requêtes soient terminées.

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;

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

6) Gestion des pannes : timeout/retry/circuit-breaking

Timeouts : plus court que le délai d'attente du client ; définir un per-route.
Retries : 1-2 avec gitter et idempotence ; interdiction des retraits de POST sans clés d'idempotence.
Circuit breaker : limiter les requêtes/erreurs simultanées ; une reprise « semi-ouverte ».
Budgets : limites de rétrospective/fusion des bourgs pour ne pas organiser un self-DDOS.

7) Modèles de Kubernetes

ClusterIP/NodePort/LoadBalancer/Ingress sont les primitives de base.
Read..../Liveness : trafic uniquement sur les pods prêts à l'emploi.
PodDissolutionBudget : Ne pas permettre la chute simultanée de N répliques.
HPA/VPA : mise à l'échelle des métriques CPU/RED, couplage avec LB.
ServiceTopology/Topology Aware Hints : localité par zone.
Service type = LoadBalancer (zonal) : Au minimum, 2 répliques par AZ.

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

8) Trafic croisé et croisé régional

Multi-AZ (à l'intérieur de la région) : répartir uniformément (LB zonal), stocker - répliques synchrones.

• Active-Active : les deux régions desservent le trafic ; Plus complexe : la réplication des données, la cohérence et l'acheminement géographique sont nécessaires.
• Active-Passive : la région principale sert, la réserve est « chaud/chaud/froid ». Commutation plus facile, plus rapide, mais au-dessus du RPO.

• Geo-DNS (région la plus proche).
• Weighted DNS (canaries/redistribution).
• Latency-based (mesures RTT).
• Failover = par signaux de santé/disponibilité (probes provenant de plusieurs points de vantage).

9) Données et échec

Cache/State : Si possible, régional local ; pour Active-Active - CRDT/hachages constants.

• Réplication synchrone = RPO faible, latence supérieure.
• Asynchrone = latence inférieure, mais RPO> 0.
• Files d'attente : miroirs/haches multiplastres ; déduplication des événements.
• Concevoir l'idempotence des opérations et la mécanique replay.

10) Périmètre : DNS/Anycast/BGP/CDN

DNS : court TTL (30-60s) + checks santé hors de votre réseau.
Anycast : Plusieurs RO avec une IP - le plus proche reçoit le trafic, un faussaire au niveau du routage.
CDN/Edge : cache et « passerelle » pour la protection, statique/médias sont servis lorsque l'origin tombe ; origin-shield + пер-POP health.

11) Exemples de configurations

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

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

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

12) Failover automatique : signaux et gates

T-SLI : 5xx-rate, p95/p99, saturation, handshakes TLS, resets TCP.
SLI d'entreprise : succès des dépôts/paiements, pas d'erreurs de paiement chez PSP.
Gates : si vous dépassez les seuils, désactivez la zone/l'instance, augmentez le poids du pool stable, changez de GSLB.
Runbook : instruction étape par étape de basculement et de retour (rollback).

13) Tests et inspections (chaos & game-days)

Tests de chaos : désactivation de l'AZ/régions, dégradation des bases de données/caches, simulation de packet-loss.
Game-day : un faussaire d'entraînement impliquant des équipes en ligne.
Diagnostic : trace du périmètre aux backends, mise en correspondance des annotations de sortie et des métriques.

14) Sécurité et conformité

mTLS entre les limites de LB↔servisy, WAF/Rate sur le périmètre.
Zones de défaillance/segmentation : isolation blast-radius.
Politiques : interdiction des points de défaillance uniques (SPOF), exigences pour « minimum N répliques/AZ ».

15) Anti-modèles

Un LB/une zone pour l'ensemble du trafic prod (SPOF).
Absence de vérification approfondie '/healthz '(vert - mais OBD/file d'attente non disponible).
Rétractation sans idempotence → prise de transactions/paiements.
Sticky per IP avec NAT de masse → déséquilibre.
Failover DNS avec TTL élevé (horloge avant commutation).
Il n'y a pas de graceful drain à la dérive - la rupture des requêtes.

16) Chèque de mise en œuvre (0-45 jours)

0-10 jours

Déposer les instances selon la ≥2 AZ ; inclure read..../liveness, health-checks.
Configurer L7-timeouts/retries (1 tentative), outlier detection.
Activer graceful drain et slow-start.

11-25 jours

Entrez GSLB (geo/weighted) ou Anycast pour le périmètre.
Poids canaris/politiques d'itinéraire ; sticky via cookie/consistent hash.
Gates SLO pour Auto-Faulover (p95/5xx + Business SLI).

26-45 jours

DR régional : Active-Active ou Active-Passive avec test de traduction.
Jours de chaos avec débranchement AZ/régions, rapports RTO/RPO.
Runbook automatisé et (scripts pause/shift/rollback).

17) Métriques de maturité

Couverture Multi-AZ ≥ 99 % des voies critiques.
DNS/GSLB/Anycast ont été mis en œuvre pour les endpoints publics.
MTTR en cas de chute d'un AZ <5 minutes (p95).
RPO pour les données critiques ≤ cible (par exemple, 30 secondes ≤).
Game-days trimestriels et faussaire planifié réussi.

18) Conclusion

L'équilibrage fiable et l'échec sont des architectures en couches : politiques locales L7 (timeouts/retries/CB, checks de santé), bonne adhérence et hachage, stabilité croisée, et sur le périmètre, GSLB/DNS/Anycast. Ajoutez des gates SLO, de l'idempotence, du graceful drain et des tests de chaos réguliers - et toute perte d'un nœud, d'une zone ou même d'une région deviendra un événement gérable avec un RTO/RPO prévisible.