[post-views]
À un certain niveau de trafic ou de criticité, un simple serveur ne suffit plus pour héberger un site WordPress : limite CPU/RAM, maintenance risquée, indisponibilité lors des mises à jour, pics de charge. La solution consiste alors à passer à une architecture multi-serveurs avec load balancer.
Dans ce guide, nous allons voir comment faire passer WordPress à l’échelle : rôle du load balancer, organisation des serveurs web, base de données partagée, gestion des sessions, des médias, du cache et des mises à jour dans un environnement distribué.
Résumé rapide : Pour scaler WordPress, vous placez un load balancer en frontal (Nginx, HAProxy, Cloudflare, etc.), plusieurs serveurs web derrière, une base de données centralisée (voire répliquée), un cache partagé (Redis, object storage pour les médias) et une stratégie de déploiement cohérente. Le but : répartir la charge, assurer la haute disponibilité et éviter les points uniques de défaillance.
Sommaire
1. Quand faut-il envisager un load balancer pour WordPress ?
Tout le monde n’a pas besoin d’une architecture multi-serveurs. Vous pouvez commencer à y réfléchir si :
- les ressources de votre serveur sont régulièrement saturées malgré l’optimisation,
- vous avez des pics de trafic significatifs (campagnes, médias, évènements),
- la haute disponibilité est critique (site métier, e-commerce),
- vous voulez pouvoir maintenir un serveur sans couper le site.
Avant de passer à l’architecture load balancer, assurez-vous d’avoir déjà optimisé :
- PHP-FPM,
- MySQL/MariaDB,
- Redis,
- Cloudflare ou équivalent,
- le code WordPress lui-même (plugins, thème).
2. Architecture de base avec load balancer
L’architecture typique :
- Un load balancer (LB) en frontal : Nginx, HAProxy, ou un service managé (ELB, Cloudflare Load Balancing).
- 2+ serveurs web derrière (WordPress + PHP-FPM).
- Une base de données centrale (MariaDB/MySQL), potentiellement répliquée.
- Redis pour le cache objet, éventuellement partagé.
- Un stockage partagé ou externe pour les médias.
Le load balancer reçoit toutes les requêtes HTTP/HTTPS et les distribue aux serveurs web selon une politique :
- round-robin,
- ajustée par charge,
- avec ou sans affinité de session.
3. Sessions, cache et état partagé
WordPress est principalement stateless, mais certains éléments doivent être partagés entre les serveurs :
3.1. Sessions PHP
Évitez de stocker les sessions dans le système de fichiers local de chaque serveur. Sinon, un utilisateur pourrait se connecter sur le serveur A, puis être redirigé sur le serveur B sans session valide.
Solutions :
- Stocker les sessions dans Redis.
- Ou utiliser un hash de cookie pour faire de l’“affinité” côté load balancer (sticky sessions), bien que ce soit moins idéal en haute disponibilité.
3.2. Cache objet (Redis)
Avec plusieurs serveurs, un cache objet local à chaque instance perd en efficacité. Il est préférable d’utiliser un Redis central pour :
- partager le cache entre les serveurs web,
- assurer des invalidations cohérentes,
- éviter de dupliquer inutilement la mémoire.
3.3. Cache de page
Pour le cache HTML, plusieurs options :
- Cache de page géré par un plugin côté WordPress (stocké sur chaque serveur ou dans Redis).
- Cache en bordure (CDN/Cloudflare) avec une bonne stratégie de purge.
Idéalement, la plus grosse partie du trafic anonyme est servie directement par le CDN, ce qui réduit la charge globale sur l’architecture multi-serveurs.
4. Base de données : centralisation et haute disponibilité
Dans une architecture avec plusieurs serveurs web, la base de données reste souvent un point central.
4.1. Base unique, serveurs multiples
Au début, vous pouvez :
- garder une seule base de données,
- augmenter ses ressources (RAM, tuning InnoDB),
- utiliser un monitoring sérieux (slow queries, charge, etc.).
C’est la configuration la plus simple : tous les serveurs web se connectent à la même base.
4.2. Réplication et haute dispo
Pour aller plus loin, vous pouvez mettre en place :
- une réplication primaire-secondaire (lectures sur les secondaires, écriture sur le primaire),
- des solutions de haute disponibilité (MariaDB Galera, MySQL InnoDB Cluster, etc.),
- un proxy SQL (HAProxy, ProxySQL) pour distribuer les requêtes.
Attention : WordPress écrit beaucoup en base (options, sessions, transients, etc.). Il faut donc être très soigneux sur la cohérence des données lorsque vous utilisez des setups multi-primaires ou des réplications asynchrones.
5. Médias et fichiers : stockage partagé ou externe
Si chaque serveur web a son propre wp-content/uploads local, vous aurez rapidement des problèmes
:
- un fichier uploadé sur le serveur A ne sera pas sur le serveur B,
- les sauvegardes sont plus compliquées,
- les déploiements deviennent fragiles.
5.1. Stockage partagé (NFS, cluster FS)
Une solution classique consiste à utiliser un stockage partagé :
- NFS monté sur tous les serveurs web,
- ou un système de fichiers distribué (plus complexe).
Les uploads sont ainsi visibles par tous les serveurs. Inconvénient : le stockage devient un point critique et doit être fiable et performant.
5.2. Stockage externe type S3
Une autre approche consiste à utiliser un stockage objet (S3 ou compatible), via un plugin WordPress :
- les fichiers sont uploadés vers S3,
- les URLs d’images pointent directement vers ce stockage,
- le serveur web ne conserve que peu ou pas de fichiers médias locaux.
C’est souvent plus scalable et plus résilient, surtout si vous avez déjà un CDN devant vos sites.
6. Déploiement, mises à jour et maintenance
Avec plusieurs serveurs web, les déploiements doivent être maîtrisés :
- le code (thème, plugins, mu-plugins) doit être synchronisé entre les serveurs,
- les mises à jour doivent être testées avant déploiement,
- idéalement, un outil de déploiement (Git, CI/CD) pousse les modifications simultanément sur les instances.
Stratégies possibles :
- déploiement depuis un dépôt Git vers chaque serveur,
- images Docker mises à jour et redéployées derrière le load balancer,
- mises à jour WordPress pilotées depuis un seul serveur, puis synchronisation.
Pendant la maintenance, le load balancer peut :
- retirer temporairement un serveur du pool,
- laisser le trafic continuer vers les autres,
- puis le réintégrer une fois la mise à jour terminée.
FAQ – Scalabilité & load balancer pour WordPress
Un load balancer suffit-il pour rendre WordPress “scalable” ?
Non. Le load balancer est une brique importante, mais il faut aussi :
- optimiser les serveurs web,
- gérer le cache (Redis, CDN),
- dimensionner la base,
- gérer les médias et les sessions.
C’est l’ensemble de l’architecture qui rend WordPress scalable, pas seulement le LB.
Cloudflare remplace-t-il un load balancer ?
Cloudflare apporte déjà beaucoup (CDN, WAF, cache, protection DDoS). Avec certaines offres, il propose aussi des fonctionnalités de load balancing. Mais même avec Cloudflare, il faudra organiser vos serveurs d’origine et votre base pour supporter la charge.
Faut-il absolument plusieurs bases de données pour scaler WordPress ?
Non. Beaucoup d’architectures scalable commencent avec une seule base bien dimensionnée, avec éventuellement un replica pour les lectures. Le passage à des architectures plus complexes (sharding, multi-bases) vient plus tard, pour des besoins très spécifiques.
Combien de serveurs web faut-il pour un site WordPress à fort trafic ?
Il n’y a pas de chiffre universel. Deux serveurs derrière un load balancer sont souvent un bon début pour la haute disponibilité. Ensuite, vous ajoutez des instances en fonction des métriques : CPU, RAM, temps de réponse, taux de cache, etc.
Les plugins WordPress fonctionnent-ils tous bien en multi-serveurs ?
La plupart oui, à condition que les sessions, le cache et les médias soient gérés correctement. Certains plugins qui s’appuient sur le système de fichiers local ou sur des transients non partagés peuvent nécessiter des ajustements ou des tests plus poussés.
Conclusion : de WordPress “monoserver” à WordPress “plateforme”
Passer un WordPress d’un simple serveur unique à une architecture avec load balancer et plusieurs serveurs web est un vrai changement de paradigme. Vous ne gérez plus seulement un site, mais une plateforme : load balancer, serveurs web, base, cache, stockage, déploiement, monitoring.
En construisant cette architecture étape par étape – d’abord un serveur bien optimisé, puis un deuxième, un load balancer, un cache partagé, un stockage médias externe – vous faites passer votre site (ou votre parc) dans une autre catégorie : celle des infrastructures capables d’absorber la charge, de résister aux pannes et de grandir avec les besoins métiers.
