C’est quoi un load balancer en termes simples ?

Un load balancer est un composant placé devant plusieurs serveurs qui répartit entre eux les requêtes entrantes. Aucun serveur n’est ainsi débordé, et si l’un tombe, les autres continuent de servir : le site reste en ligne et absorbe plus de trafic qu’une seule machine ne le pourrait.

Quelle différence entre la répartition Layer 4 et Layer 7 ?

Un load balancer Layer 4 achemine par IP et port sans inspecter le trafic, ce qui est rapide et fonctionne pour n’importe quel protocole. Un load balancer Layer 7 comprend HTTP : il peut router selon l’URL, le nom d’hôte ou les en-têtes et terminer le TLS. Le Layer 7 est typique des applis web ; le Layer 4 est choisi quand la vitesse brute prime.

Quels sont les algorithmes de répartition courants ?

Les plus courants sont round-robin (chaque serveur à tour de rôle), least connections (le serveur avec le moins de connexions actives), IP hash (le même client atteint toujours le même serveur) et pondéré (les serveurs plus puissants reçoivent plus de trafic). Le round-robin est le choix simple par défaut quand les serveurs se ressemblent.

Programmation · Serveurs · Réseau

C’est quoi un load balancer ?

Q: Quelle différence entre un load balancer et un reverse proxy ?

La répartition de charge est l’une des tâches qu’un reverse proxy peut accomplir. Un reverse proxy est la notion plus large de porte d’entrée qui peut router, mettre en cache, terminer le TLS et répartir la charge. Un load balancer est cette même porte d’entrée concentrée sur la répartition du trafic entre les backends. Des outils comme Nginx et HAProxy font les deux.

Par ColdwastMis à jour le 26 juin 20268 min de lecture#load-balancer#scaling#networking

Des serveurs montés en baie dans un centre de données — Un load balancer se place devant plusieurs serveurs identiques et répartit entre eux les requêtes entrantes, pour qu’aucune machine ne porte seule toute la charge.

Un seul serveur a ses limites. Quand le trafic dépasse ce qu’une seule machine peut servir — ou que vous ne pouvez tout simplement pas vous permettre que le site tombe si cette machine flanche — vous en faites tourner plusieurs copies et placez un load balancer devant elles. Ce guide explique ce qu’est un load balancer, comment il décide où va chaque requête, et comment il se rattache au reverse proxy que vous connaissez peut-être déjà.

L’idée de base : partager le travail

Un load balancer est un composant qui reçoit les requêtes entrantes et les distribue sur un pool de serveurs backend — généralement des copies identiques de la même appli. Pour le visiteur, il n’y a qu’une seule adresse ; derrière, le load balancer répartit discrètement le trafic pour qu’aucun serveur ne soit débordé. Il résout deux problèmes à la fois : la montée en charge (absorber plus de trafic qu’une seule machine ne le pourrait) et la disponibilité (si un serveur meurt, les autres continuent de servir).

Ce second point est celui qu’on sous-estime. Un load balancer vérifie en continu si chaque backend est en bonne santé et cesse d’envoyer du trafic à ceux qui ne répondent plus. Un seul serveur défaillant ne fait plus tomber tout le site — sa part de requêtes est simplement réacheminée vers les serveurs sains.

Comment il décide : les algorithmes de répartition

Le load balancer a besoin d’une règle pour choisir quel serveur traite la prochaine requête. Les plus courantes sont :

Round-robin — confier chaque nouvelle requête au serveur suivant, à tour de rôle. Simple et équitable quand les serveurs se ressemblent.
Least connections (moins de connexions) — envoyer la requête au serveur qui a actuellement le moins de connexions actives. Plus pertinent quand les requêtes ont des coûts variables.
IP hash — choisir le serveur en fonction de l’IP du client, pour que le même visiteur retombe toujours sur le même backend (utile pour la persistance de session).
Pondéré (weighted) — donner aux serveurs plus puissants une part de trafic plus importante.

Une baie de serveurs aux voyants d’état lumineux dans un centre de données — Les health checks permettent au load balancer de contourner automatiquement un serveur défaillant — les voyants restent allumés même quand une machine décroche.

Layer 4 vs Layer 7

Les load balancers travaillent à l’un de deux niveaux. Un répartiteur de Layer 4 (transport) achemine par adresse IP et port sans regarder le contenu du trafic — rapide et indépendant du protocole. Un répartiteur de Layer 7 (application) comprend HTTP : il peut router selon le chemin d’URL, le nom d’hôte ou les en-têtes, terminer le TLS et prendre des décisions plus fines. Le Layer 7 est le choix courant pour les applis web ; le Layer 4 l’emporte quand la vitesse brute compte plus qu’un routage conscient du contenu.

Load balancer vs reverse proxy

C’est la question qui embrouille tout le monde. La réponse honnête : la répartition de charge est l’une des tâches qu’un reverse proxy peut accomplir. Un reverse proxy est la notion plus large — un serveur placé devant vos backends, capable de router, mettre en cache, terminer le TLS et répartir la charge. Un « load balancer », c’est cette même porte d’entrée concentrée sur la tâche de répartition. En pratique, les outils se recoupent : Nginx, HAProxy et Caddy font tous office de load balancers, et un load balancer cloud est une version managée du même rôle.

Où tournent les load balancers

On les rencontre sous quelques formes. Les load balancers logiciels — Nginx, HAProxy, Traefik — tournent sur un serveur que vous contrôlez. Les load balancers cloud (AWS, Google Cloud, Azure) sont des services managés que vous configurez plutôt que d’héberger. Et dans les plateformes de conteneurs comme Kubernetes, la répartition de charge est intégrée et étale le trafic sur les pods au fil de leurs apparitions et disparitions. Quel que soit votre choix, il vous faudra plus d’un backend — typiquement quelques serveurs faisant tourner des copies identiques de l’appli.

En résumé

Un load balancer répartit les requêtes entrantes entre plusieurs serveurs pour que le système absorbe plus de trafic et survive à la panne d’un serveur. Il choisit un backend via un algorithme comme round-robin ou least connections, vérifie la santé de chaque serveur, et peut travailler au niveau transport (L4) ou application (L7). Voyez-le comme la tâche de répartition d’un reverse proxy — la pièce qui transforme une appli sur une seule machine en un service qui monte en charge et reste en ligne.