Comment couper un cache d’objets existant, saturé de clés accumulées depuis des mois, sans jamais laisser le serveur applicatif encaisser brutalement toutes les requêtes qu’il absorbait jusque-là ? C’est la question posée avant la migration d’un site à fort trafic vers un nouveau serveur Redis, en remplacement d’une installation Memcached vieillissante.
Une bascule directe, désactiver l’ancien cache puis activer le nouveau, aurait provoqué exactement le scénario redouté : un cache vide face à un trafic qui, lui, ne ralentit jamais le temps qu’un nouveau cache se remplisse naturement requête après requête.
Étape 1 : faire tourner les deux caches en écriture simultanée
La première étape a consisté à modifier le connecteur de cache d’objets pour qu’il écrive simultanément dans l’ancien système et dans le nouveau serveur Redis, tout en continuant à lire exclusivement depuis l’ancien. Cette double écriture, maintenue plusieurs jours, a permis à Redis d’accumuler progressivement les mêmes clés que l’ancien cache, sans jamais servir la moindre lecture depuis le nouveau serveur pendant cette phase.
Étape 2 : mesurer le taux de remplissage du nouveau cache
Avant toute bascule de lecture, un contrôle a comparé le nombre de clés présentes dans chaque système, ainsi que le taux de succès de lecture simulée sur un échantillon de clés fréquemment consultées. L’objectif : s’assurer que le nouveau cache Redis contenait déjà, au moment de la bascule, l’essentiel des données réellement utiles au fonctionnement courant du site, pas seulement un sous-ensemble partiel.
- Comparer le nombre total de clés entre l’ancien cache et Redis après quarante-huit heures de double écriture.
- Interroger un échantillon de clés à forte fréquence d’accès et vérifier leur présence dans les deux systèmes.
- Prolonger la période de double écriture si le taux de correspondance reste insuffisant, plutôt que de basculer prématurément.
Étape 3 : basculer la lecture, garder l’écriture double un temps
Une fois le taux de correspondance jugé satisfaisant, la lecture a été basculée vers Redis, tout en conservant temporairement l’écriture double vers l’ancien système, par prudence, pendant encore vingt-quatre heures. Cette précaution a permis un retour en arrière immédiat en cas d’anomalie détectée après bascule, sans aucune perte de données ni retour à un cache froid.
Étape 4 : couper l’ancien cache une fois la confiance établie
Passé ce délai de sécurité sans incident constaté, l’écriture vers l’ancien système a été désactivée, puis le serveur Memcached correspondant arrêté définitivement. À aucun moment de cette procédure le serveur applicatif n’a eu à traiter une charge équivalente à celle d’un cache totalement vide.
- Double écriture activée pendant plusieurs jours, sans bascule de lecture.
- Vérification chiffrée du taux de correspondance entre les deux caches avant toute bascule.
- Bascule de lecture avec écriture double maintenue temporairement, pour un retour en arrière possible.
- Coupure de l’ancien système seulement après une période de confiance sans incident.
Une migration de cache réussie ne se remarque pas : c’est précisément l’objectif recherché.
Ce que cette procédure ne couvre pas
Le dimensionnement du serveur Redis lui-même, en mémoire et en nombre de connexions maximales supportées, reste un chantier distinct, à traiter en amont de la migration plutôt que pendant celle-ci.
Un incident évité grâce à la période de double écriture
Un contrôle mené le second jour de double écriture a révélé une divergence sur un petit groupe de clés : celles générées par un module de recommandation de contenu, dont la structure de sérialisation n’était pas correctement interprétée par le nouveau connecteur Redis. Sans la période de double écriture, cette anomalie ne serait apparue qu’après la bascule complète, avec un risque de données incohérentes servies aux visiteurs pendant plusieurs heures avant détection.
La correction du connecteur, une fois cette divergence identifiée, a pris moins d’une heure de développement, mais elle n’aurait jamais été repérée à temps sans cette phase de vérification préalable, ce qui illustre l’intérêt de ne jamais sauter cette étape même sous pression de calendrier.
En résumé
Migrer un cache d’objets sur un site à fort trafic sans période de cache froid demande de renverser l’ordre naturel des opérations : écrire dans les deux systèmes avant de lire depuis le nouveau, vérifier le taux de remplissage avant de basculer, et ne couper l’ancien système qu’une fois la confiance établie sur la durée. Cette rigueur, un peu plus longue à mettre en œuvre qu’une bascule directe, a permis d’éviter tout impact perceptible côté visiteurs pendant l’ensemble de la migration.
