Le trafic de ce client a grossi de façon régulière pendant deux ans, jusqu’à dépasser la capacité confortable d’un seul serveur applicatif lors des pics de fin de mois. La solution retenue en 2021, un DNS round-robin simple entre deux serveurs, avait déjà montré ses limites : pas de détection de panne réelle, pas de répartition selon la charge effective de chaque nœud, et surtout aucune notion de session cohérente d’un visiteur à l’autre des requêtes.
Passer à HAProxy en frontal a permis de résoudre ces trois limites d’un coup, avec une exigence particulière propre à WordPress et surtout à WooCommerce sur ce projet : la persistance de session, pour qu’un visiteur en train de finaliser son panier ne se retrouve jamais renvoyé vers un serveur différent en plein milieu de son parcours d’achat.
Pourquoi le DNS round-robin ne suffisait plus
Un DNS round-robin distribue les requêtes en alternance entre plusieurs IP, sans aucune connaissance de l’état réel des serveurs derrière. Si un serveur tombe, le DNS continue à le proposer à une partie des visiteurs jusqu’à ce qu’un humain retire manuellement l’enregistrement, un délai incompatible avec les exigences de disponibilité du client. HAProxy, en frontal actif, sonde en permanence la santé de chaque serveur et retire immédiatement de la rotation celui qui ne répond plus correctement.
Configuration de base : répartition et contrôle de santé
frontend web_frontend
bind *:443 ssl crt /etc/haproxy/certs/exemple.fr.pem
default_backend wordpress_backend
backend wordpress_backend
balance roundrobin
option httpchk GET /wp-json
http-check expect status 200
cookie SRVID insert indirect nocache
server app1 10.0.0.11:80 check cookie app1
server app2 10.0.0.12:80 check cookie app2
server app3 10.0.0.13:80 check cookie app3
L’option httpchk GET /wp-json interroge une route standard de l’API REST de WordPress pour valider qu’un serveur répond correctement, plutôt que de se contenter d’un simple ping TCP qui ne garantirait pas que l’application PHP fonctionne réellement derrière.
La persistance de session, point critique pour WooCommerce
La directive cookie SRVID insert indirect nocache insère un cookie identifiant le serveur qui a traité la première requête d’un visiteur, et HAProxy réutilise ensuite systématiquement ce même serveur pour toutes les requêtes suivantes de cette session, tant que le cookie est présent et que le serveur reste sain. Cela évite le scénario redouté : un visiteur qui ajoute un article au panier sur le serveur 1, puis dont la requête suivante atterrit sur le serveur 2 qui n’a aucune connaissance de ce panier si les sessions PHP restent locales à chaque machine.
| Approche | Comportement en cas de panne d’un nœud |
|---|---|
| DNS round-robin simple | Continue à proposer le nœud en panne jusqu’à intervention manuelle |
| HAProxy avec contrôle de santé | Retire le nœud en quelques secondes automatiquement |
Ce que la persistance par cookie ne règle pas seule
La persistance de session côté HAProxy résout le routage des requêtes, mais ne règle pas à elle seule le partage réel des données de session PHP entre serveurs : si le serveur identifié par le cookie tombe en panne en cours de session, HAProxy redirigera la requête suivante vers un autre nœud qui, sans mécanisme de partage de session applicatif, ne connaîtra rien du panier en cours. Ce sujet de partage de session entre serveurs web, traité séparément sur ce blog, reste complémentaire de la configuration HAProxy, pas remplacé par elle.
- HAProxy garantit qu’un visiteur reste collé au même serveur tant que celui-ci fonctionne.
- Un mécanisme de session partagée (Redis notamment) garantit la continuité si ce serveur tombe malgré tout en panne.
- Les deux combinés offrent la meilleure robustesse, chacun seul laisse une faille.
Réglages de montée en charge progressive
Lors de l’ajout d’un nouveau serveur au pool, HAProxy propose un mécanisme de montée en charge progressive (slowstart) qui évite d’envoyer immédiatement une part complète du trafic à un serveur qui vient tout juste de démarrer, le temps que ses caches internes (opcache PHP, cache d’objets local le cas échéant) se réchauffent.
server app3 10.0.0.13:80 check cookie app3 slowstart 30sUn répartiteur de charge mal réglé donne l’illusion de la haute disponibilité tout en cassant discrètement l’expérience utilisateur : un panier vidé sans explication reste, du point de vue du client final, une panne, même si le serveur, lui, répond parfaitement.
Supervision de HAProxy lui-même
HAProxy expose une interface de statistiques (stats) qui permet de suivre en temps réel la répartition de charge entre les trois serveurs, le nombre de connexions actives par nœud et l’historique des bascules liées aux contrôles de santé, une visibilité indispensable pour ajuster les seuils au fil du temps plutôt que de deviner.
En résumé
Passer d’un DNS round-robin à HAProxy a changé la nature de la répartition de charge sur ce projet : détection de panne réelle en quelques secondes plutôt qu’intervention manuelle, et surtout persistance de session par cookie qui évite qu’un visiteur en plein achat ne soit redirigé vers un serveur qui ignore tout de son panier. Cette persistance reste complémentaire, pas substituable, à un partage de session applicatif entre les serveurs eux-mêmes.
