Trois pannes d’hébergeur en dix-huit mois, toutes causées par le même incident matériel sur un unique VPS, ont fini par convaincre qu’une seule zone de disponibilité ne suffisait plus pour ce site marchand. La question n’était pas de savoir s’il fallait répartir la charge sur deux zones distinctes, mais dans quel ordre s’y prendre sans tout casser en cours de route.
Cet article détaille les étapes suivies pour faire cette transition, sans entrer dans le détail de la réplication de base de données elle-même, qui a fait l’objet d’un chantier séparé une fois l’architecture générale posée.
Étape 1 : sortir les médias du disque local
Avant même d’envisager un deuxième serveur, il fallait résoudre un problème simple : les fichiers uploadés vivaient sur le disque du VPS. Dupliquer le serveur applicatif sans régler ce point aurait créé deux copies divergentes des médias en quelques jours. La première étape a donc consisté à migrer le répertoire wp-content/uploads vers un stockage objet compatible S3, avec le plugin d’offload habituellement utilisé sur ce type de projet, configuré pour réécrire les URLs des médias vers le nouveau stockage.
Cette étape seule a pris une semaine, essentiellement consacrée à vérifier qu’aucun chemin de fichier n’était codé en dur dans le thème ou dans une extension tierce, ce qui aurait cassé l’affichage après la bascule.
Étape 2 : dupliquer l’applicatif, pas encore la base
Le deuxième serveur a été provisionné dans une zone géographique distincte du premier, avec la même image système et la même configuration PHP, déployée via le même pipeline que le serveur d’origine. À ce stade, la base de données restait unique et hébergée sur le premier serveur, le second s’y connectant à distance via une liaison chiffrée.
# wp-config.php sur le second serveur
define( 'DB_HOST', 'ip-privee-serveur-1:3306' );
define( 'DB_NAME', getenv('DB_NAME') );
define( 'DB_USER', getenv('DB_USER') );
define( 'DB_PASSWORD', getenv('DB_PASSWORD') );
Cette configuration intermédiaire, volontairement temporaire, a permis de valider que le second serveur fonctionnait correctement avant d’aborder la question plus complexe de la réplication de la base elle-même, laissée à un chantier ultérieur distinct de celui-ci.
Étape 3 : la bascule de trafic, la partie la plus délicate
Une fois les deux serveurs opérationnels, il restait à décider comment router le trafic entre eux. Deux options ont été comparées : un enregistrement DNS avec plusieurs adresses IP en round-robin, ou un répartiteur de charge dédié devant les deux serveurs. Le DNS multi-IP a été écarté car il ne détecte pas la panne d’un serveur : les visiteurs continuent d’être orientés vers l’adresse en défaut tant que le DNS n’est pas modifié manuellement.
Le choix s’est porté sur un répartiteur de charge managé, positionné devant les deux VPS, avec une vérification de santé toutes les dix secondes sur une route dédiée qui renvoie un code 200 tant que PHP-FPM et la connexion à la base répondent normalement.
- Basculement automatique en moins de trente secondes en cas de défaillance d’un serveur
- Aucune modification DNS à effectuer en cas de panne, contrairement à l’approche round-robin
- Un léger surcoût mensuel, jugé négligeable au regard du coût d’une indisponibilité
Ce qui a été sous-estimé
Le cache d’objet, jusque-là backé par une instance locale sur le premier serveur, ne pouvait plus fonctionner de la même façon avec deux serveurs applicatifs distincts : chacun aurait maintenu son propre cache, désynchronisé de l’autre. Il a fallu migrer vers un cache d’objet partagé, accessible depuis les deux serveurs, une étape non anticipée dans le calendrier initial et qui a ajouté près d’une semaine au projet.
Les sessions PHP posaient le même type de problème, résolu en configurant leur stockage vers ce même cache partagé plutôt que sur le disque local de chaque serveur.
Notre verdict
Répartir sur deux zones de disponibilité ne se résume pas à dupliquer un serveur : c’est avant tout un exercice qui consiste à identifier, un par un, tout ce qui reposait implicitement sur l’unicité du serveur d’origine, du stockage des médias au cache d’objet en passant par les sessions. La base de données, souvent perçue comme l’obstacle principal, s’est révélée être la dernière pièce du puzzle, une fois que tout le reste avait déjà été rendu partageable entre les deux zones.
