Load Balancer

Un load balancer (répartiteur de charge) est un composant réseau qui distribue le trafic entrant entre plusieurs serveurs ou instances backend. Son objectif : améliorer la disponibilité, les performances et la tolérance aux pannes d’une application.

Rôle principal

Objectif	Mécanisme
Disponibilité	Health checks continus — si un backend tombe, le trafic est redirigé vers les backends sains
Scalabilité	Les backends peuvent être ajoutés ou retirés sans interruption de service
Performance	La charge est répartie pour éviter la saturation d’un seul serveur
Tolérance aux pannes	Aucun single point of failure côté backend

L4 vs L7 : les deux grandes familles

Critère	Load Balancer L4 (Transport)	Load Balancer L7 (Application)
Couche OSI	Couche 4 (TCP/UDP)	Couche 7 (HTTP/HTTPS)
Décision basée sur	IP source/destination + port	URL, méthode HTTP, headers, cookies
Inspection du contenu	Non — flux TCP/UDP opaque	Oui — décode le protocole applicatif
Terminaison TLS	Pass-through ou TLS offloading	TLS offloading natif
Fonctionnalités avancées	Rapide, simple, universel	Routage par path/host, réécriture URL, WAF, sticky sessions
Exemple AWS	NLB (Network Load Balancer)	ALB (Application Load Balancer)
Exemple Kubernetes	Service type: LoadBalancer + kube-proxy	Ingress Controller (nginx, traefik, etc.)

Algorithmes de répartition

Algorithme	Description	Cas d’usage
Round Robin	Chaque requête → backend suivant en rotation	Serveurs homogènes, requêtes de durée similaire
Least Connections	Vers le backend avec le moins de connexions actives	Requêtes de durée variable (long polling, WebSocket)
IP Hash	Hash de l’IP source → backend fixe (session sticky)	Applications avec état de session
Weighted Round Robin	Poids par backend (ex. 70% / 30%)	Backends de capacités différentes
Random	Sélection aléatoire	Simple, scalable sur gros clusters
Least Response Time	Backend avec le temps de réponse le plus court	Applications sensibles à la latence

Health Checks

Le load balancer sonde régulièrement chaque backend pour détecter les pannes :

# Exemple de configuration health check (AWS ALB)
healthCheckProtocol: HTTP
healthCheckPath: /health
healthCheckIntervalSeconds: 30
healthyThresholdCount: 2      # 2 succès consécutifs → backend sain
unhealthyThresholdCount: 3    # 3 échecs consécutifs → backend retiré du pool

Types AWS

Type	Couche	Protocoles	Cas d’usage
ALB (Application LB)	L7	HTTP, HTTPS, WebSocket	APIs REST, microservices, routage par path/host
NLB (Network LB)	L4	TCP, UDP, TLS	Hautes performances, IP statique, non-HTTP
CLB (Classic LB)	L4/L7	HTTP, HTTPS, TCP	Legacy uniquement (déprécié)
GWLB (Gateway LB)	L3	IP	Inspection de trafic via appliances tierces (firewall, IDS)

Schéma de fonctionnement

Client
  ↓
[ Load Balancer ] ← health checks continus
  ├── Backend 1  (sain ✅)
  ├── Backend 2  (sain ✅)
  └── Backend 3  (défaillant ❌ → exclu du pool)

En relation avec

• DNS — le load balancer est exposé via un enregistrement DNS (ex. A ou CNAME vers le LB)
• Internet Gateway (IGW) — un load balancer public (ALB/NLB) est accessible via l’IGW
• TLS et SSL — le trafic entre le LB et les backends peut être sécurisé via mTLS
• kube-proxy — dans Kubernetes, kube-proxy assure le load balancing L4 interne (Services ClusterIP)
• Reverse Proxy — le LB L7 est souvent aussi un reverse proxy (routage par path/host, TLS offloading)