Bonnes Pratiques HAProxy : Optimisation, Sécurité et Haute Disponibilité

1. Optimisation des Performances #

Assurer que HAProxy utilise au mieux les ressources disponibles pour traiter le trafic.

Paramètres globaux et réutilisation #

Pour tirer le meilleur parti de HAProxy, certains paramètres globaux sont indispensables pour limiter la charge sur les backends et assurer la résilience réseau.

• Maxconn : Définit la limite globale de connexions (ex: 10 000).
  Avantage : Protège le système contre l'épuisement de la RAM et des descripteurs de fichiers.
  Risque : Si la valeur est trop basse, HAProxy rejettera des clients légitimes lors des pics de trafic.
• Keep-alive : Activez option http-keep-alive.
  Avantage : Réduit la latence en réutilisant les connexions TCP existantes (évite le 3-way handshake répétitif).
  Risque : Peut maintenir trop de connexions ouvertes sur des serveurs backend limités si le timeout est trop long.
• Retries & Redispatch :
  Avantage : Améliore la disponibilité perçue par l'utilisateur. Si un serveur tombe pile au moment de la requête, HAProxy réessaie sur un autre.
  Risque : Peut aggraver la surcharge d'un cluster si les serveurs tombent à cause d'une saturation (effet cascade).

global
    maxconn 10000
    log stdout format raw local0

defaults
    option http-keep-alive
    retries 3
    option redispatch

Optimisation des Timeouts #

Une erreur fréquente est de conserver les valeurs par défaut. Il faut définir des timeouts explicites.

• Standards : 5s pour la connexion, 30s pour le client et le serveur.
  Avantage : Libère rapidement les ressources bloquées par des clients ou des serveurs léthargiques.
  Risque : Un timeout serveur trop court coupera des transferts de fichiers volumineux ou des exports longs.
• Protection Slowloris : Gardez un timeout http-request court (5s).
  Avantage : Empêche un attaquant de saturer les connexions en envoyant les headers très lentement.

defaults
    timeout connect 5s
    timeout client 30s
    timeout server 30s

backend slow_api
    timeout server 2m

Choisir le bon algorithme #

Le choix de l'algorithme impacte directement l'utilisation de vos ressources et la qualité de l'expérience utilisateur. Pour approfondir les mécanismes théoriques, consultez notre article : Le Load Balancing : Principes, Algorithmes et Cas d'usage.

• Round Robin :
  Avantage : Simplicité, équité parfaite si les requêtes sont homogènes.
  Risque : Inefficace si certains serveurs sont plus puissants que d'autres ou si certaines requêtes sont beaucoup plus lourdes.
• Least Connections :
  Avantage : Algorithme le plus intelligent pour l'APM ; il évite d'envoyer du trafic vers un serveur déjà en train de peiner.
  Risque : Moins performant sur des flux très courts car le calcul du nombre de connexions ajoute un léger overhead.
• Source Hash :
  Avantage : Persistance sans injecter de cookies.
  Risque : Déséquilibre si de nombreux utilisateurs sortent derrière un même proxy/NAT d'entreprise (une seule IP pour des milliers de clients).

2. Sécurité et Durcissement (Hardening) #

Protéger vos applications contre les menaces courantes via HAProxy.

Gestion du TLS/SSL #

Le chiffrement TLS est fondamental pour la sécurité des communications. HAProxy permet de centraliser la terminaison SSL.

• HTTP/2 via ALPN :
  Avantage : Accélère le chargement des pages via le multiplexage.
  Risque : Consomme un peu plus de CPU sur HAProxy pour la gestion des flux.
• HSTS :
  Avantage : Empêche les attaques de downgrade SSL (Man-in-the-Middle).
  Risque : Si vous perdez vos certificats ou souhaitez repasser en HTTP, les navigateurs bloqueront l'accès jusqu'à expiration du max-age (souvent 1 an).

Désactivation des protocoles obsolètes #

Pour protéger vos flux contre les vulnérabilités protocolaires (POODLE, BEAST), il est impératif de limiter les protocoles acceptés.

• TLS 1.2 / 1.3 uniquement :
  Avantage : Niveau de sécurité maximal conforme aux standards PCI-DSS / RGPD.
  Risque : Incompatibilité avec de très vieux clients (vieux terminaux de paiement, vieux navigateurs Android/IE).

global
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11

Protection contre les Attaques (DDoS, Slowloris) #

HAProxy peut servir de première ligne de défense contre les attaques de type DDoS ou Slowloris via des stick-tables.

• Rate Limiting :
  Avantage : Bloque automatiquement les IP qui saturent le service avant qu'elles n'atteignent vos serveurs.
  Risque : Risque de faux positifs (ex: une école ou une entreprise sortant avec une seule IP publique sera bloquée si trop d'utilisateurs naviguent simultanément).

Bonnes pratiques WAF (Web Application Firewall) #

HAProxy peut inspecter le contenu des requêtes pour bloquer les tentatives d'injection SQL ou XSS.

• Filtrage de méthodes :
  Avantage : Réduit la surface d'attaque en interdisant des méthodes comme PUT ou DELETE si elles ne sont pas utilisées.
  Risque : Peut casser certaines fonctionnalités d'API modernes si la configuration n'est pas mise à jour.
• Inspection de payload :
  Avantage : Bloque les attaques connues au niveau de la couche 7.
  Risque : Impact significatif sur le CPU si les règles d'inspection (Regex) sont trop complexes ou nombreuses.

Bonnes pratiques ACL #

Les ACL sont le moteur de décision. Une gestion rigoureuse évite les erreurs de routage.

• Nomenclature :
  Avantage : Facilite la lecture des logs et le troubleshooting.
  Risque : Des noms d'ACL flous (ex: acl test) rendent la configuration illisible et dangereuse.
• Externalisation (Maps) :
  Avantage : Permet de mettre à jour des listes (ex: domaines autorisés) sans modifier le fichier principal et parfois sans rechargement via la Runtime API.
  Risque : Nécessite une gestion rigoureuse des fichiers externes pour éviter les fichiers manquants au démarrage.

3. Haute Disponibilité et Résilience #

Assurer la continuité de service et la robustesse de votre infrastructure.

Configuration des Health Checks #

Les health checks évitent d'envoyer des clients vers un serveur 'zombie' (port ouvert mais application crashée).

• Check Applicatif (HTTP) :
  Avantage : Garantit que l'application répond réellement (ex: base de données connectée).
  Risque : Si l'endpoint de santé est trop complexe, le check lui-même peut ralentir le backend (évitez les calculs lourds dans /health).

backend app_servers
    option httpchk GET /health
    http-check expect status 200
    server s1 10.0.0.1:80 check inter 2s fall 3 rise 2

Gestion des Serveurs de Backup et Maintenance #

Prévoyez toujours une issue de secours.

• Serveur de Backup :
  Avantage : Évite la page d'erreur 503 totale. Peut servir à afficher un site statique 'dégradé'.
  Risque : Si le backup n'est jamais testé, il peut échouer au moment où on en a besoin.
• Page de Maintenance :
  Avantage : Communication propre vers les utilisateurs lors d'incidents majeurs.
  Risque : Si elle est mal configurée, elle peut empêcher les robots d'indexation (SEO) de comprendre que le site reviendra.

4. Organisation et Modularité #

Structurer sa configuration pour faciliter l'automatisation et la maintenance.

Séparation des blocs et fichiers multiples #

Dans une infrastructure complexe, avoir un seul fichier de 3000 lignes est une mauvaise pratique majeure.

• Séparation logique : Les sections Global et Defaults doivent être isolées du routage métier.
• Inclusions : Utilisez des dossiers (ex: conf.d/) pour charger vos backends par application.

Avantage : Permet de déployer une nouvelle application (nouveau fichier) via CI/CD sans risquer de corrompre les ACL d'un autre service.
Risque : HAProxy charge les fichiers par ordre alphabétique. L'ordre Global > Defaults > Frontend > Backend doit être respecté.

# Lancer HAProxy en chargeant un répertoire
haproxy -f /etc/haproxy/haproxy.cfg -f /etc/haproxy/conf.d/

5. Maintenance Opérationnelle et Haute Disponibilité #

Gérer les mises à jour et éliminer les points de défaillance uniques (SPOF).

Reload à chaud (Zero Downtime) #

Pour appliquer une modification sans déconnecter les utilisateurs, il ne faut jamais faire un restart du service. Vous devez faire un reload:

systemctl reload haproxy

ou dans le monde Docker par exemple :

sudo docker compose kill -s HUP haproxy

• Master-Worker Mode : Utilisez le mode moderne (standard sous Systemd) qui permet de transférer les sockets d'écoute aux nouveaux processus.
• Avantage : Les sessions longues (WebSockets, transferts) se terminent normalement sur l'ancien processus pendant que le nouveau prend les nouveaux appels.
  Risque : En cas d'erreur de syntaxe, le reload échoue. Toujours tester avant : haproxy -c -f /etc/haproxy/haproxy.cfg.

Haute Disponibilité Réseau (Keepalived) #

Si HAProxy tombe, votre application est injoignable. La solution est de mettre en place un cluster HAProxy Redondant.

• VIP (Virtual IP) : Une adresse IP flottante est gérée par Keepalived via le protocole VRRP.
• Fonctionnement : Si le HAProxy 'Master' ne répond plus, la VIP bascule instantanément sur le 'Backup'.

Avantage : Élimine le SPOF matériel ou logiciel.
Risque : Le 'Split-Brain' (les deux nœuds croient être Master) peut arriver si le lien réseau entre les deux est instable, provoquant des conflits d'IP.

Logging et Monitoring #

Utilisez des logs détaillés pour le debugging applicatif.

frontend http_front
    # Capture le Host et le User-Agent pour l'analyse
    capture request header Host len 64
    capture request header User-Agent len 128