Le Load Balancer


Infrastructure & Réseaux
Posté le 21 juillet 2025 · Par elysee

Chaque jour, des milliers d’utilisateurs se connectent pour consulter leurs e-mails, échanger des messages ou travailler sur leurs projets. Un nombre incalculable de paquets réseau transitent chaque seconde entre des milliers de serveurs, tous optimisés pour répondre le plus rapidement possible et distribuer efficacement les ressources.


Mais qui dit multiplication des utilisateurs, dit aussi requêtes simultanées, risques de surcharge, lenteurs, voire pannes.


Dans cette course à la performance et à la réactivité, de nombreuses techniques sont mises en œuvre pour garantir une distribution fluide et équilibrée de la charge : le load balancing en est l’une des clés.

Le Load Balancing est un processus clé en informatique, souvent utilisé dans l’architecture des systèmes distribués. Il permet de répartir un ensemble de tâches ou de requêtes sur plusieurs ressources (comme des serveurs) afin de réduire la surcharge, améliorer les performances globales et garantir une haute disponibilité. Il s’applique principalement au niveau des protocoles d’application tels que HTTP/HTTPS, FTP, SMTP, DNS, SSH, etc., pour gérer efficacement le trafic réseau.


Schéma d'un load balancer distribuant le trafic

Concrètement, au lieu que chaque client s’adresse directement à un serveur donné, toutes les requêtes sont envoyées à une adresse réseau centrale — celle du load balancer. Celui-ci se charge alors de rediriger le trafic vers les serveurs disponibles, selon différents critères (algorithmes, charge actuelle, disponibilité, etc.).


Ce mécanisme permet d’éviter les surcharges, d’améliorer les performances globales du système et de garantir une haute disponibilité du service.

Load Balancing : niveau 4 vs niveau 7


Il existe plusieurs types de load balancers, selon le niveau du modèle OSI sur lequel ils opèrent :

  • Niveau 4 (transport) : l’équilibrage se fait sur la base des adresses IP, des ports TCP ou UDP. Le load balancer ne « voit » pas le contenu des requêtes, il se contente de router le trafic selon des règles de bas niveau.
    Exemple : HAProxy ou AWS Network Load Balancer.
  • Niveau 7 (application) : l’équilibrage se fait en analysant le contenu des requêtes HTTP, comme l’URL, les cookies, ou les en-têtes. Cela permet une répartition plus fine et contextuelle.
    Exemple : NGINX, Traefik, ou AWS Application Load Balancer.

Ce choix dépend du type d’application, du besoin en personnalisation et des performances attendues.

Principaux algorithmes d’équilibrage:

Le Round Robin DNS :


round_rogin

Le Round Robin DNS est un algorithme d’équilibrage de charge qui permet de répartir le trafic entre plusieurs serveurs en associant plusieurs adresses IP à un même nom de domaine.

Contrairement à d’autres méthodes, cette technique ne nécessite aucun équipement physique dédié. Elle repose sur le fonctionnement du serveur DNS autoritaire (authoritative nameserver).

Elle est facile à mettre en place via l’interface de gestion DNS de votre fournisseur :

  • en ajoutant plusieurs enregistrements A (pour IPv4),
  • ou des enregistrements AAAA (pour IPv6).

Avantage : simplicité de configuration.
Limite : pas de gestion intelligente de la charge réelle (le DNS ne “voit” pas si un serveur est saturé ou indisponible).

load balancers logiciels et matériels:

— logicielles:


Nginx :


nginx est un logiciel open-source qui fait office de serveur web, de reverse proxy et de load balancer. Il est reconnu pour sa faible consommation mémoire et sa grande rapidité, ce qui en fait un choix privilégié dans les environnements à fort trafic.


Pour configurer Nginx comme load balancer, on utilise la directive upstream dans le fichier de configuration, qui permet de déclarer plusieurs serveurs backend :


http {
    upstream backend_servers {
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend_servers;
        }
    }
}

Par défaut, Nginx applique le round robin, mais il supporte aussi :

  • least_conn : vers le serveur avec le moins de connexions actives
  • ip_hash : pour garder la session sur le même serveur

choisir une méthode d’équilibrage de charge:

NGINX en charge quatre méthodes d’équilibrage de charge : Round Robin, Least Connections, IP Hash et Generic Hash.

Note: Lors de la configuration d’une méthode autre que Round Robin, mettez la directive correspondante (haship_hashleast_connleast_time, ou random) au-dessus de la liste de server directives dans le upstream {} bloc.

1- Round Robin (Default)


upstream backend {
   # no load balancing method is specified for Round Robin
   server backend1.example.com;
   server backend2.example.com;
}

Contrairement au Round Robin DNS, les reverse proxies comme NGINX permettent un équilibrage de charge plus intelligent et dynamique, avec prise en compte des connexions actives, de l’adresse IP du client, ou de la clé de hachage.


2- Least Connections –  Une requête est envoyée au serveur avec le moins de connexions actives. Cette méthode prend également poids du serveur en considération.


upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

3- IP Hash – Le serveur auquel une requête est envoyée est déterminé à partir de l’adresse IP du client. Dans ce cas, soit les trois premiers octets de l’adresse IPv4, soit l’adresse IPv6 entière sont utilisés pour calculer la valeur de hachage. La méthode garantit que les requêtes provenant de la même adresse parviennent au même serveur, sauf si celui-ci n’est pas disponible.


upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

Si l’un des serveurs doit être temporairement retiré de la rotation de chargement‑équilibrage, il peut être marqué avec le down paramètre. Cela préserve le hachage actuel des adresses IP des clients. Les requêtes qui devaient être traitées par ce serveur sont automatiquement envoyées au serveur suivant du groupe.


upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
}

Generic Hash – Le serveur auquel une requête est envoyée est déterminé à partir d’une clé définie par l’utilisateur‑. Cette clé peut être une chaîne de texte, une variable ou une combinaison. Par exemple, la clé peut être une adresse IP source et un port appariés. Cet exemple utilise un URI :


upstream backend {
    hash $request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}

L’optionnel cohérent paramètre au hash la directive permet ketama cohérent‑équilibrage de charge de hachage. Les requêtes sont réparties uniformément sur tous les serveurs en amont en fonction de la valeur de clé hachée définie par l’utilisateur‑. Si un serveur en amont est ajouté ou supprimé d’un groupe en amont, seules quelques clés sont remappées, ce qui minimise les échecs de cache. Ceci est utile pour équilibrer la charge des serveurs de cache ou d’autres applications qui accumulent de l’état.

HAProxy:

HAProxy est un logiciel gratuit et open source qui offre une haute disponibilité et un équilibrage de charge pour les applications basées sur TCP et HTTP. Il répartit le trafic réseau entrant sur plusieurs serveurs pour garantir une utilisation et une évolutivité optimales.

HAProxy et NGINX peuvent tous deux faire de l’équilibrage de charge, mais ils ont des différences importantes dans leur conception, leur comportement et leurs cas d’usage préférés.

NGINX vs HAProxy : Comparaison d’usage

CritèreNGINXHAProxy
Fonction principaleServeur HTTP + reverse proxyLoad balancer (spécialisé)
Performance bruteExcellente en HTTP, bon généralisteMeilleure sur les charges réseau élevées
Équilibrage niveauL7 (HTTP) + partiel L4L4 (TCP) + L7 (HTTP) très optimisé
Support HTTPS natifOui (certbot, etc.)Possible, mais plus complexe
ConfigurationSimple, fichiers de config lisiblesPlus verbeux mais très précis
Monitoring / statsBasique (module de status)Très détaillé (dashboard intégré)
Utilisation fréquenteReverse proxy web, CDN, cacheLoad balancing pur, haute disponibilité
Consommation mémoireFaibleUltra-optimisée aussi
Hot reload / live updatePas toujours sans coupureOui, sans perturber les connexions

Load Balancer matériel

En support physique, En version matérielle, ce sont des dispositifs physiques installés dans des datacenters spécifiques. Bien qu’il soient capable de gérer et dispatcher un grand volume de trafic sur différent réseau, Ils offrent moins de flexibilité et leurs coûts sont assez élevés.

NomDescription
F5 BIG-IPLe plus connu. Très utilisé en entreprise. Permet du L4 et L7 avec des fonctions avancées (SSL offloading, firewall applicatif, etc.).
Cisco ACE / ACIIntégré dans les solutions réseau Cisco. Moins courant aujourd’hui, mais très robuste dans certains data centers.
Barracuda Load Balancer ADCConnu pour sa simplicité, bon rapport qualité/prix, adapté aux PME. Propose aussi des fonctions de sécurité.

Dans cet article, nous avons clarifié et expliqué quelques-uns des algorithmes de load balancing les plus utilisés.
Mais cette liste est loin d’être exhaustive : des outils comme HAProxy proposent d’autres méthodes avancées de répartition, ainsi que des fonctionnalités clés telles que :

  • les health checks (vérification automatique de l’état des serveurs),
  • la redondance avec des load balancers en mode actif/passif,
  • la reprise automatique en cas de panne.

De leur côté, des solutions commerciales comme NGINX Plus offrent également des fonctionnalités étendues, incluant une gestion fine des sessions, des métriques en temps réel, ou encore le support natif de protocoles spécifiques.

En résumé, le load balancing est un composant essentiel des architectures modernes, garantissant performance, fiabilité et scalabilité. Qu’il soit implémenté par des solutions logicielles comme NGINX ou HAProxy, ou par du matériel spécialisé, il joue un rôle de chef d’orchestre entre les utilisateurs et les serveurs. Le choix du bon algorithme ou de la bonne solution dépendra toujours du contexte d’usage, du budget, et des contraintes techniques.