La boutique en ligne d’un client vendant des pièces détachées automobiles tournait depuis quatre ans sur Memcached comme cache d’objet persistant. Le trafic avait triplé, l’équipe technique s’était étoffée, et le choix s’est porté sur Redis pour ses structures de données plus riches et sa meilleure intégration avec les outils de supervision déjà en place ailleurs dans l’infrastructure. La question n’était pas de savoir lequel des deux est le meilleur choix technique dans l’absolu, mais comment faire cette bascule sans qu’un seul visiteur ne s’en aperçoive.
Sur un site qui traite plusieurs commandes par minute aux heures de pointe, couper brutalement le cache d’objet revient à envoyer tout le trafic directement sur MySQL pendant plusieurs minutes, le temps que le nouveau cache se remplisse. C’est exactement le scénario que cette migration devait éviter.
Préparer le terrain avant toute bascule
La première étape a consisté à installer Redis en parallèle de Memcached, sur un serveur dédié, sans toucher à la configuration de production. Le plugin redis-cache a été déployé mais désactivé, le temps de vérifier que le serveur Redis répondait correctement aux commandes de base :
redis-cli -h 10.0.0.12 ping
redis-cli -h 10.0.0.12 info memoryUn second point de vigilance portait sur la mémoire allouée : Redis et Memcached ne gèrent pas l’éviction des clés de la même façon. La politique maxmemory-policy a été réglée sur allkeys-lru pour reproduire un comportement proche de celui de Memcached, évitant les mauvaises surprises le jour de la bascule.
La phase de double écriture
Plutôt qu’un basculement direct, un petit module maison a été inséré temporairement dans un must-use plugin, en s’accrochant aux fonctions de cache d’objet de WordPress. À chaque écriture dans le cache, la valeur était envoyée à la fois vers Memcached, toujours actif en lecture pour les visiteurs, et vers Redis, en silence, pour l’alimenter progressivement sans qu’il ne serve encore aucune requête réelle.
Valider avant de couper Memcached
Après quarante-huit heures de double écriture, un script de validation comparait, pour un échantillon de clés représentatives (menus, requêtes de produits, fragments de panier), la valeur stockée côté Memcached et celle stockée côté Redis. L’objectif n’était pas une égalité stricte, certaines valeurs évoluant en continu, mais une cohérence de structure et une fraîcheur comparable.
- Vérification que Redis contenait bien les mêmes groupes de cache que Memcached (options, terms, posts, woocommerce).
- Contrôle du taux de « miss » sur Redis, qui devait être proche de zéro après la période de préchauffage.
- Test de charge synthétique avec Apache Bench sur un environnement de préproduction identique, pour comparer les temps de réponse moyens entre les deux backends.
Le test de charge a montré un temps de réponse moyen légèrement meilleur sous Redis sur les requêtes de catalogue, ce qui a confirmé la pertinence du choix technique sans que ce soit l’objectif premier de la migration.
Le jour de la bascule
La coupure de Memcached a été programmée un mardi à 5 heures du matin, horaire de trafic le plus faible observé sur les statistiques des trois mois précédents. La configuration de wp-config.php a été modifiée pour ne plus pointer que vers Redis, puis le cache d’objet a été vidé une seule fois pour repartir sur une base propre :
wp cache flush
wp redis statusAucune erreur 500 n’a été relevée dans les journaux applicatifs dans les trente minutes suivant le changement, et le temps de réponse moyen mesuré par l’outil de supervision externe est resté stable, sans pic visible. Le serveur Memcached a été laissé éteint mais installé pendant une semaine supplémentaire, par prudence, avant d’être définitivement désinstallé.
Ce que cette migration a appris à l’équipe
La double écriture temporaire, souvent réservée aux migrations de base de données, s’applique très bien à un changement de backend de cache. Elle transforme une opération binaire et risquée en une transition progressive et observable. Le coût en développement reste modeste : quelques dizaines de lignes de code, retirées une fois la migration terminée.
Sur ce type de migration, le budget temps à prévoir pour la phase d’observation compte souvent plus que celui de l’implémentation elle-même : ne pas se précipiter sur la coupure a évité toute mauvaise surprise.
Notre verdict
Une bascule de cache d’objet sans coupure n’exige pas d’outillage sophistiqué : un plugin de double écriture temporaire, une phase de validation rigoureuse et un horaire de coupure choisi avec soin suffisent. Cette méthode reste valable pour toute migration future de backend de cache, quel que soit le sens du changement.
