Planification de la capacité Redis avec des exemples pratiques

La planification de la capacité Redis transforme des estimations vagues en étapes concrètes et reproductibles : mesurer ce qui compte, dimensionner la mémoire et le CPU avec des marges de sécurité, choisir des politiques de persistance et d'éviction adaptées à la criticité des données, et vérifier les résultats avec des diagnostics concrets. Ce guide présente un inventaire des versions et de l'environnement, un parcours de configuration sécuritaire, des exemples de dimensionnement détaillés, des vérifications de validation, les modes de défaillance courants avec actions de récupération, et une liste de contrôle opérationnelle à exécuter mensuellement ou avant les lancements majeurs.

Inventaire des versions et de l'environnement

Capturez un instantané précis de votre état actuel avant d'apporter des modifications. Cet inventaire devient votre référence de base et votre point de retour arrière.

Enregistrez les éléments suivants :

• Version et options de compilation de Redis (ex. : redis-server --version, vérifiez l'allocateur jemalloc vs glibc).
• Topologie : autonome, primaire-réplica, ou Redis Cluster ; nombre de primaires et de réplicas.
• Mode de persistance : aucun, RDB, AOF (appendfsync always|everysec|no), ou les deux.
• Paramètres d'éviction : maxmemory, maxmemory-policy.
• Modèle de données : nombre de clés par type, tailles moyennes des clés et valeurs, couverture TTL (% de clés avec TTL), plus grosses clés.
• Profil de trafic : mélange lecture/écriture, opérations par seconde, concurrence de pointe, cibles de latence P99.
• Réplication : nombre de réplicas, RTT réseau, lag de réplication acceptable.
• Ressources hôtes : RAM, CPU (cœurs et fréquence), bande passante NIC, capacité de stockage et IOPS/latence.
• Comportement des clients : timeouts, pooling de connexions, conscience du cluster (pour Redis Cluster).

Collectez les métriques de référence avec redis-cli :

Mémoire et fragmentation :

• redis-cli INFO memory
• redis-cli MEMORY STATS
• redis-cli MEMORY DOCTOR

Charge de travail et latence :

• redis-cli INFO stats
• redis-cli --latency
• redis-cli --latency-history

Espace de clés :

• redis-cli INFO keyspace
• Échantillonnage des tailles de clés : redis-cli --scan | head -n 1000 | xargs -n1 redis-cli MEMORY USAGE

Réplication et persistance :

• redis-cli INFO replication
• redis-cli INFO persistence

Conservez ces instantanés pour au moins une période de pointe et une fenêtre de maintenance (lorsque les réécritures de persistance peuvent se produire).

Parcours de configuration sécuritaire

Concevez pour la sécurité d'abord. Les choix suivants réduisent les surprises et rendent les décisions d'échelle réversibles.

Marge de mémoire

• Visez un used_memory en régime permanent (incluant la surcharge de l'allocateur) à 70 % ou moins de la RAM système dédiée à Redis.
• Tenez compte de la fragmentation. Multiplier par un facteur entre 1,2 et 1,5 est un point de départ pratique ; utilisez MEMORY STATS pour affiner.
• Si vous utilisez une persistance basée sur fork (sauvegarde RDB, réécriture AOF), laissez une marge supplémentaire pour le copy-on-write pendant les opérations en arrière-plan. Des taux d'écriture plus élevés nécessitent plus de marge temporaire.

maxmemory et politique d'éviction

• Pour les caches : définissez maxmemory et utilisez une politique allkeys (allkeys-lru ou allkeys-lfu) pour que Redis puisse libérer de la charge de façon prévisible.
• Pour les jeux de données faisant autorité : évitez l'éviction si possible ; limitez la création de clés en amont ou partagez (sharding) pour garder la mémoire sous contrôle.
• Placez une alerte claire près de 80-85 % de maxmemory et un seuil d'action ferme près de 90-95 %.

Persistance

• AOF everysec est un point de départ équilibré pour de nombreuses charges de travail.
• Planifiez les bgsave RDB pendant les fenêtres creuses ou désactivez-les si l'AOF répond déjà aux besoins de durabilité.
• Assurez-vous d'une capacité disque suffisante pour la croissance de l'AOF et pour les fichiers temporaires pendant la réécriture.

Réplication et basculement

• Maintenez au moins un réplica pour la haute disponibilité quand le jeu de données est important.
• Surveillez le lag de réplication et la santé du lien ; ajoutez de la marge réseau pour les pics.

CPU et concurrence

• L'exécution des commandes Redis est mono-thread ; assurez une performance monocœur suffisante et évitez les clés chaudes qui sérialisent le trafic.
• Maintenez le CPU sous ~60 % sur le cœur le plus sollicité en pointe.

Timeouts clients et backpressure

• Définissez les timeouts clients pour échouer rapidement pendant les incidents.
• Utilisez un pooling de connexions raisonnable et le pipelining pour réduire la surcharge par requête.

Dimensions de capacité à modéliser

Exemples pratiques de dimensionnement

Ces exemples construits montrent comment bâtir des estimations défendables. Remplacez les entrées par vos mesures.

Exemple A : Cache de sessions sur un primaire unique avec un réplica

Hypothèses (construites) :

• 5 000 000 clés de session ; taille moyenne de clé 32 octets ; valeurs JSON d'environ 256 octets.
• TTL : 100 % des clés expirent en <= 24 h.
• Surcharge objet : estimation de 50 octets par paire clé-valeur (variable selon le type et l'encodage).
• Facteur allocateur et méta : 1,2.
• Facteur de fragmentation : 1,3 initialement, améliorant à 1,2 après défragmentation.
• Réplication : 1 réplica (2 copies en RAM au total).
• Persistance : AOF everysec, réécriture périodique ; pas de snapshots RDB.

Estimation mémoire par clé :

• Octets de données = clé(32) + valeur(256) + surcharge(50) = 338 octets.
• Appliquer le facteur allocateur/méta : 338 * 1,2 = 405,6 octets.
• Appliquer la fragmentation : 405,6 * 1,3 = 527,28 octets.

Mémoire du jeu de données (primaire seulement) :

• 5 000 000 * 527,28 octets ≈ 2,63 Go.

Avec un réplica :

• RAM totale sur les deux nœuds ≈ 5,26 Go.

Marge de sécurité sur chaque nœud :

• Ajouter 30 % de marge pour les pics et événements opérationnels : 2,63 Go * 1,3 ≈ 3,42 Go par nœud.
• Choisir une instance d'au moins 8 Go de RAM par nœud si Redis est le seul processus majeur, pour que le régime permanent reste bien sous 70 %.

Réglage maxmemory (primaire) :

• Définir maxmemory ≈ 3,5 Go, politique allkeys-lfu (pour un cache). Cela permet des évictions contrôlées avant OOM.

Disque pour AOF :

• Attendre une taille AOF de l'ordre du jeu de données logique avec variance de compactage. Provisionner au moins 2-3x la taille AOF attendue pour accommoder la réécriture (fichiers temporaires) et la croissance pendant les pics.

Objectifs de vérification :

• evicted_keys reste bas et stable ; taux d'accès acceptable pour votre application.
• used_memory < 70 % de la RAM et mem_fragmentation_ratio diminue après la montée en charge.

Exemple B : Catalogue produits sur Redis Cluster (faisant autorité, pas d'éviction)

Hypothèses (construites) :

• 20 000 000 clés sur 6 primaires ; clé moyenne 24 octets ; valeur moyenne 512 octets (hashes mélange ziplist/hashtable).
• Pas d'éviction autorisée ; l'amont limite les écritures.
• Réplication : 1 réplica par primaire.
• Persistance : snapshots RDB nocturnes ; pas d'AOF.
• Taux d'écriture : 5 000 ops/sec en pointe total, majoritairement lectures.

Estimation mémoire par clé (primaire) :

• Octets de données = 24 + 512 + 70 octets surcharge ≈ 606 octets.
• Facteur allocateur/méta : 1,2 -> 727,2 octets.
• Facteur de fragmentation : 1,25 -> 909 octets.

Nombre de clés par primaire : ~3,33 M. Mémoire par primaire : 3,33 M * 909 octets ≈ 3,03 Go.

Dimensionnement des nœuds et marge :

• Avec un réplica, cible RAM par nœud : 3,03 Go + 30 % marge ≈ 3,94 Go.
• Choisir 8-16 Go de RAM par nœud pour permettre la croissance et la surcharge des snapshots.

Considérations sur les snapshots RDB :

• Planifier les snapshots en creux. Pendant bgsave, le copy-on-write peut temporairement augmenter la mémoire si beaucoup de pages sont modifiées ; assurez-vous que la marge suffit pour votre taux d'écriture.

Pas de politique d'éviction :

• Ne pas définir maxmemory ou mettre la politique sur noeviction. Ajouter des alertes quand used_memory dépasse 60-65 % de la RAM pour agir avant que la pression ne monte.

Débit :

• Avec principalement des lectures et de petits objets, la performance monocœur devrait suffire. Distribuez les clés uniformément pour éviter les shards chauds. Surveillez l'équilibre des slots du cluster et migrez si nécessaire.

Feuille de travail rapide pour vos estimations

Vérification et diagnostics

Après tout changement de capacité, vérifiez les résultats avec des contrôles mesurables. Concentrez-vous sur ces domaines.

Mémoire et fragmentation :

• redis-cli INFO memory — Confirmez used_memory et used_memory_rss. Maintenez mem_fragmentation_ratio stable et près de votre attente (ex. 1,1-1,5 selon l'allocateur et la charge).
• redis-cli MEMORY STATS — Inspectez la fragmentation de l'allocateur, mémoire active vs résidente, et mémoire de pointe.
• redis-cli MEMORY DOCTOR — Obtenez des suggestions lisibles sur la fragmentation et les motifs d'allocation.

Espace de clés et santé des objets :

• redis-cli INFO keyspace — Suivez le nombre de clés et les expirations. Assurez-vous que le ratio de clés avec TTL correspond au design.
• Repérez les grosses clés (peuvent causer latence et déséquilibre mémoire) : redis-cli --scan | xargs -n1 -P4 redis-cli MEMORY USAGE | sort -nr | head -50

Latence et débit :

• redis-cli --latency --latency-history — Assurez-vous que la latence P99 reste dans le SLO en pointe.
• redis-cli INFO stats | egrep "instantaneous_ops_per_sec|keyspace_hits|keyspace_misses|evicted_keys|expired_keys" — Surveillez les évictions inattendues ou pics de miss.

Réplication et persistance :

• redis-cli INFO replication — Confirmez le rôle, offsets des réplicas, et lag petits et stables.
• redis-cli INFO persistence — Vérifiez aof_rewrite_in_progress, rdb_bgsave_in_progress, statut et durée de la dernière réécriture/sauvegarde.

Marge de ressources :

• Vérifications OS : RAM libre, cœur CPU le plus occupé, utilisation NIC, IOPS/latence disque.
• Assurez-vous que Redis reste sous les seuils de régime permanent choisis (ex. <70 % RAM, <60 % CPU cœur le plus occupé).

Signaux d'échelle et seuils (ajustez pour vos SLO)

Modes de défaillance et récupération

Préparez les réponses avant qu'elles ne soient nécessaires. Voici les problèmes courants et actions de récupération pratiques.

1. Pression mémoire et évictions

• Symptômes : evicted_keys en hausse, erreurs OOM avec noeviction, timeouts clients.
• Actions immédiates :
• Pour les caches : augmenter temporairement maxmemory si marge existe ; ou passer à allkeys-lfu pour améliorer la qualité de rétention.
• Pour les stores faisant autorité : bloquer la création de nouvelles clés en amont ; supprimer les clés non essentielles ; partager (sharding) ou monter en vertical.
• Vérifications cause racine : grosses clés temporaires, valeurs surdimensionnées, régression TTL, pic de fragmentation.
• Retour arrière : rétablir la politique d'éviction si elle dégrade le taux d'accès ; restaurer le maxmemory précédent après nettoyage.
• Vérification : used_memory revient sous le seuil ; évictions stabilisées ; latence P99 normale.

1. Pics de latence pendant RDB ou réécriture AOF

• Symptômes : Latence P99 élevée ; temps de fork long ; RSS augmentée par copy-on-write.
• Actions immédiates :
• Déplacer snapshot ou réécriture en creux ; réduire la fréquence temporairement.
• Si nécessaire, désactiver le mode de persistance moins critique pour la durée (ex. CONFIG SET save ""). Réactiver après la fenêtre.
• Moyen terme :
• Augmenter la marge RAM ; réduire l'amplification d'écriture ; ajuster le jeu de données vers des objets plus petits.
• Vérification : temps de fork acceptables ; latence revient à la ligne de base ; persistance complète dans la fenêtre.

1. Lag de réplication et risque de basculement

• Symptômes : réplica en retard sur le primaire ; instabilité du lien ; backlog croissant.
• Actions immédiates :
• Vérifier santé réseau et bande passante ; assurer que les réplicas ne sont pas I/O bound par la persistance.
• Réduire la charge temporairement ou ajouter des réplicas plus près des clients.
• Retour arrière :
• Si un changement de topologie a causé le lag, rétablir et réessayer en creux.
• Vérification : offset du réplica rattrape ; métriques de lag s'aplatissent ; répétition de basculement réussie.

1. Saturation disque par croissance AOF

• Symptômes : fichiers AOF approchent la capacité disque ; réécriture ne peut compléter.
• Actions immédiates :
• Déclencher réécriture manuelle en creux ; assurer assez d'espace libre pour fichiers temporaires.
• Ajuster temporairement appendfsync pour réduire l'I/O si latence impactée.
• Moyen terme :
• Augmenter la capacité disque ; implémenter TTL sur données non critiques ; compresser les valeurs en amont si acceptable.
• Vérification : aof_current_size stable ou réduite ; réécritures complètent avec succès ; latence dans le SLO.

1. Clé chaude ou shard chaud

• Symptômes : usage CPU inégal, cœur unique saturé, pics de latence locaux.
• Actions :
• Identifier les clés chaudes via moniteur de latence ou stats de commandes ; diviser ou mettre en cache les résultats chauds au niveau application ; ajouter du sharding si nécessaire.
• Vérification : ops et latence se distribuent uniformément sur cœurs/shards.

Liste de contrôle opérationnelle

Utilisez cette liste reproductible mensuellement et avant les lancements majeurs.

• Inventaire et référence
• Enregistrer version Redis, topologie, persistance, politique d'éviction.
• Capturer INFO memory, stats, keyspace, replication, persistence.
• Conserver une vue métrique 24h avec marqueurs de pointe.

• Mémoire et marges de sécurité
• Confirmer used_memory <= 70 % de la RAM dédiée.
• Examiner mem_fragmentation_ratio et stats allocateur.
• Valider que maxmemory et politique correspondent à la criticité des données.

• Persistance et stockage
• Vérifier que les fenêtres de réécriture/sauvegarde sont en creux.
• Confirmer capacité disque >= 2-3x AOF attendu ou suffisant pour artefacts RDB.
• Vérifier que le statut de la dernière réécriture/sauvegarde est OK.

• Réplication et basculement
• Assurer présence des réplicas, santé, et lag faible.
• Répéter le basculement en fenêtre de maintenance et documenter les résultats.

• Charge de travail et latence
• Comparer latence P99 vs SLO en pointe.
• Examiner slowlog pour nouveaux motifs ; optimiser ou diviser les commandes lourdes.

• Points chauds et croissance
• Scanner pour grosses clés ou clés chaudes ; atténuer au besoin.
• Réestimer la mémoire avec derniers comptages et tailles de clés ; ajuster le plan d'échelle.

• Alerting
• Alertes configurées pour mémoire, évictions, latence, lag réplication, et durée persistance.

• Pilote avant déploiement
• Tester un changement étroit et mesurable d'abord (ex. nouvelle politique d'éviction sur un nœud canary), puis étendre une fois vérifié.

Conclusion

La planification de la capacité pour Redis est une pratique cyclique : mesurer, décider, vérifier, et ajuster. Commencez par un pilote étroit et facile à inspecter, puis montez en charge une fois que vos estimations tiennent. Maintenez une marge de régime permanent, alignez l'éviction et la persistance à la criticité de vos données, et validez les changements avec des diagnostics concrets. Avec ces étapes et marges de sécurité, vous pouvez échelonner de façon prévisible et récupérer rapidement quand la réalité vous surprend.