Load Balancing : stratégies et algorithmes pour la haute disponibilité

Pourquoi le Load Balancing

Le load balancing distribue le trafic entrant entre plusieurs serveurs pour éviter la surcharge d'un seul nœud. C'est la première ligne de défense pour la haute disponibilité et la scalabilité horizontale. Sans load balancer, votre application a un Single Point of Failure.

Couches de Load Balancing

Le load balancing peut opérer à différentes couches du modèle OSI, chacune avec ses avantages.

• Layer 4 (Transport) : route basée sur IP/port, très rapide, pas d'inspection du contenu (ex: AWS NLB)
• Layer 7 (Application) : route basée sur le contenu HTTP (URL, headers, cookies), plus flexible (ex: NGINX, HAProxy, AWS ALB)
• DNS Load Balancing : distribue au niveau DNS, simple mais peu de contrôle (ex: Route 53 weighted routing)

Algorithmes de répartition

Le choix de l'algorithme impacte directement la distribution de charge et les performances perçues par les utilisateurs.

Round Robin         → Distribution séquentielle, simple et équitable
                      Idéal : serveurs homogènes, requêtes similaires

Weighted Round Robin → Poids proportionnel à la capacité du serveur
                      Idéal : serveurs hétérogènes

Least Connections   → Route vers le serveur avec le moins de connexions actives
                      Idéal : requêtes de durée variable (WebSocket, uploads)

IP Hash             → Hash de l'IP client → même serveur (sticky sessions)
                      Idéal : applications stateful sans session store externe

Consistent Hashing  → Minimise la redistribution quand un nœud est ajouté/retiré
                      Idéal : caches distribués (Redis cluster, CDN)

Health Checks et Failover

Un load balancer ne sert à rien s'il envoie du trafic vers des serveurs morts. Les health checks sont essentiels : le LB interroge périodiquement chaque backend et retire automatiquement les nœuds en échec du pool.

• Health check actif : le LB envoie des requêtes périodiques (GET /health) — délai de détection configurable
• Health check passif : le LB analyse les réponses du trafic réel — détection plus rapide mais moins fiable
• Graceful degradation : en cas de surcharge, servir une version dégradée plutôt qu'une erreur 503
• Circuit breaker : couper le trafic vers un backend qui échoue trop souvent, réessayer périodiquement