Le load balancing est une technique clé de la haute disponibilité. Il répartit les requêtes entre plusieurs serveurs pour maximiser performance et résilience. HAProxy et Nginx en sont les références open source.
Le principe
Un répartiteur de charge (load balancer) reçoit toutes les requêtes entrantes sur un point unique, puis les distribue entre plusieurs serveurs backend identiques. Du point de vue de l'utilisateur, le service semble unique et unifié. Du point de vue technique, la charge est répartie et les pannes sont transparentes.
HAProxy
HAProxy (High Availability Proxy) est un load balancer spécialisé, très performant. Il gère le trafic TCP/HTTP, peut absorber des millions de requêtes par seconde, et offre une configuration fine. Utilisé par GitHub, Instagram, Reddit. Léger, éprouvé, documenté.
Nginx
Nginx est à l'origine un serveur web, mais fait aussi très bien office de load balancer. Avantage : un seul logiciel sert à la fois le contenu statique, le SSL termination, la compression et le load balancing. Idéal pour les configurations simples à moyennes. Nginx Plus (version payante) ajoute des fonctionnalités enterprise.
Les algorithmes de répartition
Round Robin : rotation équitable entre les serveurs (simple et souvent efficace). Least Connections : envoie vers le serveur avec le moins de connexions actives (meilleur en cas de requêtes de durées variables). IP Hash : même IP toujours vers le même serveur (utile pour les sessions non partagées). Weighted : serveurs avec des capacités différentes.
Les health checks
Le load balancer vérifie régulièrement la santé de chaque backend (par exemple, toutes les 5 secondes). Si un serveur ne répond pas ou répond avec une erreur, il est retiré automatiquement du pool. Sa restauration automatique est aussi gérée dès qu'il redevient sain.
La persistance de session
Certaines applications stockent l'état utilisateur localement (mauvaise pratique moderne). Dans ce cas, le load balancer doit envoyer chaque utilisateur toujours vers le même serveur. Cookie de session, IP stickiness sont les techniques disponibles. Mieux vaut concevoir des applications stateless.
Le SSL termination
Le load balancer peut traiter le SSL/TLS avant de transmettre en clair aux serveurs backend. Avantage : centraliser la gestion des certificats, décharger les backends. Inconvénient : le trafic interne n'est pas chiffré. Le chiffrement de bout en bout reste préférable pour les données sensibles.
Architecture typique
Deux load balancers en actif-passif (ou actif-actif), chacun redondé, devant N serveurs applicatifs. Les LB eux-mêmes sont exposés via une IP flottante qui bascule en cas de panne. Pour approfondir, consultez notre article failover et cluster actif-passif.
Kubernetes et les services cloud
Dans un environnement cloud, le load balancing est souvent un service managé (AWS ELB/ALB, GCP Load Balancer, Azure Load Balancer). Kubernetes intègre ses propres mécanismes (Services, Ingress). Dans ces contextes, HAProxy reste utile pour des besoins spécifiques, mais moins central. Pour plus d'informations, consultez notre article haute disponibilité et redondance et notre guide complet.
