1. Qu'est-ce que le Load Balancing ?
Définition et rôle fondamental dans les architectures web.
Le répartiteur de charge
Le Load Balancing (ou répartition de charge) est un dispositif qui distribue le trafic réseau ou applicatif sur un ensemble de serveurs (le pool de backends). Son but est d'optimiser l'utilisation des ressources, de maximiser le débit, de réduire le temps de réponse et surtout d'éviter la surcharge d'un seul serveur.
Pourquoi est-ce indispensable ?
Sans répartition de charge, votre infrastructure possède un SPOF (Single Point of Failure). Si votre unique serveur tombe, le service s'arrête. Le load balancing permet la Haute Disponibilité (redondance) et la Scalabilité horizontale (ajout de serveurs pour absorber la croissance du trafic).
2. Les Algorithmes de répartition
Comment le répartiteur choisit-il le serveur de destination ?
Round Robin (Tourniquet)
C'est l'algorithme le plus simple : les requêtes sont envoyées aux serveurs de manière séquentielle. Il est idéal quand les serveurs ont des capacités identiques.
- Points positifs : Simplicité extrême, aucun overhead, équité parfaite sur des serveurs identiques.
- Points négatifs : Inefficace si les serveurs ont des puissances différentes ou si certaines requêtes sont plus lourdes que d'autres.
Exemple de configuration HAProxy :
backend app_servers
balance roundrobin
server s1 192.168.1.10:80 check
server s2 192.168.1.11:80 check
Weighted Round Robin
Chaque serveur possède un poids proportionnel à sa capacité de traitement. Un serveur plus puissant traitera une proportion plus importante de requêtes.
- Points positifs : Adapté aux parcs serveurs hétérogènes, comportement prévisible.
- Points négatifs : Nécessite une configuration manuelle des poids et ne s'adapte pas à la charge réelle instantanée.
Exemple de configuration HAProxy :
backend app_servers
balance roundrobin
server s1 192.168.1.10:80 check weight 100
server s2 192.168.1.11:80 check weight 200
Least Connections (Moins de connexions)
Cet algorithme envoie la nouvelle requête au serveur qui a le moins de connexions actives. Très efficace pour les sessions à durées variables.
- Points positifs : Équilibre dynamique efficace, idéal pour les connexions persistantes (Bases de données, WebSockets).
- Points négatifs : Overhead léger pour le suivi des connexions, peut être trompeur si les requêtes n'ont pas la même complexité.
Exemple de configuration HAProxy :
backend app_servers
balance leastconn
server s1 192.168.1.10:80 check
server s2 192.168.1.11:80 check
Weighted Least Connections
Combine l'algorithme des moins de connexions avec un système de poids pour favoriser les serveurs les plus robustes ayant peu de charge active.
- Points positifs : Le plus précis pour des infrastructures mixtes avec des sessions longues.
- Points négatifs : Plus gourmand en ressources de calcul pour l'équilibreur (overhead).
Exemple de configuration HAProxy :
backend app_servers
balance wlc
server s1 192.168.1.10:80 check weight 100
server s2 192.168.1.11:80 check weight 200
Least Response Time
Dirige les requêtes vers le serveur ayant le temps de réponse le plus court et le moins de connexions actives. Idéal pour une réactivité maximale.
- Points positifs : Optimise directement l'expérience utilisateur, évite les serveurs ralentis.
- Points négatifs : Calcul intensif, risque d'instabilité si les temps de réponse varient brutalement.
Exemple de configuration HAProxy :
backend app_servers
balance rtime # Requiert HAProxy 2.x+
server s1 192.168.1.10:80 check
server s2 192.168.1.11:80 check
IP Hash / Source Hash
L'adresse IP de l'utilisateur détermine le serveur de destination, garantissant la persistance de session (stickiness).
- Points positifs : Persistance sans gestion de cookies côté serveur.
- Points négatifs : Déséquilibre possible si beaucoup d'utilisateurs partagent la même IP (Proxy/NAT), redistribution totale si le nombre de serveurs change.
Exemple de configuration HAProxy :
backend app_servers
balance source
server s1 192.168.1.10:80 check
server s2 192.168.1.11:80 checkRandom (Aléatoire)
L'équilibreur de charge choisit un serveur au hasard dans le pool. Simple et statistiquement efficace sur des volumes de trafic massifs.
| Info : C'est l'algorithme par défaut depuis la version 3.3 de HAProxy. |
- Points positifs : Overhead nul, très performant pour les clusters à très grande échelle.
- Points négatifs : Aucune garantie d'équité on de petits volumes de requêtes.
Exemple de configuration HAProxy :
backend app_servers
balance random
server s1 192.168.1.10:80 check
server s2 192.168.1.11:80 check3. Outils et Exemples d'applications
Les solutions logicielles et cloud courantes.
Logiciels spécialisés
- HAProxy : Le standard de l'industrie pour la haute performance et la fiabilité. Découvrir la formation HAProxy.
- Traefik : Conçu pour le cloud-native, idéal pour Docker et Kubernetes. Découvrir la formation Traefik.
- Nginx : Serveur web polyvalent avec des fonctions de répartition robustes.
Cloud et Matériel
- Cloud Load Balancers : AWS ELB, Azure Load Balancer ou Google Cloud LB sont des services managés très populaires.
- Hardware : Des équipements physiques comme F5 BIG-IP, bien que moins fréquents aujourd'hui au profit du logiciel et du cloud.
Conclusion
Un élément critique pour la résilience.
L'évolution vers le Service Mesh
Le load balancing ne se limite plus à l'entrée du réseau. Dans les architectures microservices (Kubernetes), on utilise des Service Meshes (comme Istio ou Linkerd) pour gérer la répartition de charge directement entre les composants internes de l'application.