Module 1 — Nginx : répartition de charge, testée en la cassant

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 8 minutes

---

Pourquoi répartir la charge

Une seule instance d’une application a une capacité limitée et représente un point de panne unique. Un répartiteur de charge (load balancer) se place devant plusieurs instances identiques et distribue les requêtes entre elles — à la fois pour la performance (paralléliser la charge) et la résilience (une instance en panne n’arrête pas le service).

Le montage de démonstration

Trois instances identiques d’une petite API Flask (chacune ne se distingue que par une variable d’environnement BACKEND_ID), et un Nginx configuré comme reverse proxy devant elles :

nginx.conf

events {}

http {
  upstream backend_pool {
    server backend1:5000;
    server backend2:5000;
    server backend3:5000;
  }

  server {
    listen 80;
    location / {
      proxy_pass http://backend_pool;
      proxy_set_header Host $host;
    }
  }
}

Le bloc upstream définit un pool de serveurs équivalents ; proxy_pass http://backend_pool fait suivre chaque requête vers l’un d’entre eux, selon l’algorithme de répartition choisi (par défaut : round-robin, un serveur après l’autre, dans l’ordre).

La répartition, observée en conditions réelles

$ curl -s http://localhost:8080/
Réponse du backend 1
$ curl -s http://localhost:8080/
Réponse du backend 2
$ curl -s http://localhost:8080/
Réponse du backend 3
$ curl -s http://localhost:8080/
Réponse du backend 1
$ curl -s http://localhost:8080/
Réponse du backend 2
$ curl -s http://localhost:8080/
Réponse du backend 3

Le cycle 1 → 2 → 3 → 1 → 2 → 3 est exactement le comportement round-robin attendu — vérifié en envoyant réellement les requêtes, pas en le supposant à partir de la documentation.

Casser volontairement un backend, pour voir ce qui se passe vraiment

La question qui compte en production n’est pas « est-ce que ça marche quand tout va bien ? » mais « que se passe-t-il quand un serveur tombe ? ». Réponse testée réellement, en arrêtant le conteneur backend2 :

$ docker stop reseaux-lb-backend2-1
reseaux-lb-backend2-1

$ curl -s http://localhost:8080/
Réponse du backend 1
$ curl -s http://localhost:8080/
Réponse du backend 3
$ curl -s http://localhost:8080/
Réponse du backend 3
$ curl -s http://localhost:8080/
Réponse du backend 1
$ curl -s http://localhost:8080/
Réponse du backend 3
$ curl -s http://localhost:8080/
Réponse du backend 1

Aucune requête n’échoue, et aucune ne tombe sur le backend 2 : Nginx, dès la première tentative de connexion refusée vers backend2, l’exclut automatiquement du pool pour les requêtes suivantes (comportement de bascule passive, activé par défaut) — sans configuration additionnelle, sans intervention humaine, et sans qu’aucun client n’ait vu d’erreur. C’est exactement le comportement qu’on attend d’un load balancer en production : une panne d’un serveur backend doit être invisible pour l’utilisateur final.

Ce que ce test ne couvre pas (et qu’il faut connaître)

Ce comportement de bascule passive par défaut a une limite réelle : Nginx ne retire un serveur qu’après avoir constaté un échec (une requête arrive, échoue, puis le serveur est marqué indisponible pour un temps fail_timeout, 10 secondes par défaut) — la toute première requête envoyée vers un backend fraîchement tombé peut donc échouer avant que Nginx ne le sache. Pour une détection proactive (retirer un serveur avant qu’un vrai client n’essaie de l’atteindre), il faut des contrôles de santé actifs (health_check en Nginx Plus, ou une solution équivalente comme HAProxy avec ses propres check périodiques) — une nuance qui distingue une configuration de load balancing basique d’une configuration réellement prête pour la production.

Prochaine étape

Réseaux cloud et Kubernetes : Services, Ingress et concepts réseau