Répartition de charge (load balancing) : expliqué simplement.

La répartition de charge (load balancing) consiste à distribuer le trafic réseau entrant entre plusieurs serveurs, pour qu'aucun serveur ne soit débordé pendant que d'autres restent inactifs. Un répartiteur de charge se place devant un ensemble de serveurs et décide, pour chaque requête entrante, quel serveur doit la traiter, selon un algorithme comme le round robin ou les connexions les moins nombreuses. C'est ce qui permet à un site ou une API de continuer à servir le trafic de manière fiable à mesure que l'usage grandit, et de continuer à fonctionner même si un serveur du parc tombe en panne.

Sans répartition de charge, faire évoluer un service signifie agrandir un seul serveur (mise à l'échelle verticale), ce qui a des limites physiques strictes ; avec la répartition de charge, une équipe peut plutôt ajouter des serveurs (mise à l'échelle horizontale) et laisser le répartiteur distribuer le trafic entre eux.

Un répartiteur de charge effectue en général aussi des contrôles de santé sur chaque serveur du parc, et cesse de router du trafic vers tout serveur qui ne répond plus, pour qu'aucun utilisateur ne tombe sur une instance morte. Une configuration minimale de contrôle de santé pour un répartiteur peut ressembler à ceci :

upstream backend {
server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.3:8080 max_fails=3 fail_timeout=30s;
}

Les répartiteurs de charge opèrent à différentes couches du réseau : un répartiteur de couche 4 route le trafic selon l'adresse IP et le port, tandis qu'un répartiteur de couche 7 peut inspecter la requête HTTP elle-même (chemin d'URL, en-têtes, cookies) et router plus finement, par exemple en envoyant tout le trafic API vers un parc de serveurs et toutes les requêtes d'assets statiques vers un autre.

• Répartiteur matériel : un boîtier physique dédié, courant dans les grands data centers on-premise.
• Répartiteur logiciel : un programme comme Nginx ou HAProxy exécuté sur un serveur ou une machine virtuelle standard.
• Répartiteur cloud : un service managé proposé par un fournisseur cloud ou CDN, qui monte en charge automatiquement sans infrastructure à maintenir.
• Répartition par DNS : distribue le trafic en renvoyant des IP de serveur différentes selon les clients au niveau du DNS, une méthode plus grossière mais simple.

• Toujours associer la répartition de charge à des contrôles de santé, pour que le trafic cesse automatiquement d'aller vers un serveur en panne ou lent au lieu de dégrader l'expérience des utilisateurs réels.
• Choisir les sessions persistantes (router un utilisateur toujours vers le même serveur) seulement quand c'est nécessaire, car elles réduisent la flexibilité du répartiteur et peuvent créer des points de surcharge.
• Surveiller les temps de réponse et les taux d'erreur par serveur, pas seulement le trafic global, pour repérer un serveur sous-performant avant qu'il ne plombe tout le parc.
• Prévoir une redondance pour le répartiteur lui-même ; un répartiteur unique sans failover devient à son tour un point de défaillance unique.

La répartition de charge rend possible la mise à l'échelle horizontale, permettant à l'infrastructure de grandir en ajoutant des serveurs plutôt qu'en surdimensionnant indéfiniment une seule machine, et c'est une brique de base de toute architecture haute disponibilité : si un serveur tombe en panne ou a besoin de maintenance, le répartiteur le contourne simplement, sans que les utilisateurs ne remarquent rien. Pour tout produit anticipant une vraie croissance de trafic, la répartition de charge est l'une des premières briques d'infrastructure à bien poser, bien avant qu'elle ne devienne un goulot d'étranglement.

Quand nous concevons l'hébergement et l'infrastructure pour nos clients, nous mettons en place la répartition de charge dès que la fiabilité ou le trafic attendu justifie plus d'un seul serveur, que ce soit via le répartiteur managé d'un fournisseur cloud ou un réseau CDN en périphérie. Le site ou l'application reste ainsi réactif pendant les pics de trafic et résilient à la panne d'un seul serveur. Voir notre service website pour savoir comment nous mettons en place l'hébergement et l'infrastructure.