## Introduction Exécuter Redis en production ne consiste pas seulement à démarrer le serveur. Cela signifie vérifier la version exacte, comprendre comment votre déploiement est câblé, modifier la configuration délibérément et savoir prouver qu'un changement a fonctionné ou revenir en arrière s'il échoue. Cet article est une liste de contrôle pratique pour les développeurs, les ingénieurs DevOps et les équipes techniques de startups qui opèrent Redis eux-mêmes. Chaque élément est lié à la même boucle : observer l'état actuel avec des commandes en lecture seule, définir le résultat attendu avant d'agir, effectuer le plus petit changement qui corrige le problème identifié, vérifier le résultat et conserver un chemin de récupération testé. Les exemples utilisent des espaces réservés explicites comme et afin que vous puissiez les adapter sans exposer de véritables identifiants ou clés privées. L'accent est mis sur les opérations Redis, la configuration, la vérification et la récupération. Les sujets adjacents tels que Node.js, Docker et la surveillance n'apparaissent que lorsqu'ils modifient les prérequis, l'observabilité ou le rayon d'impact d'un changement. ## Inventaire des versions et de l'environnement Avant de toucher à un paramètre Redis, sachez ce que vous exécutez. Les différences de version modifient la syntaxe des commandes, les valeurs par défaut de persistance, les limites de mémoire et le comportement de sécurité. Une liste de contrôle qui ne commence pas ici peut recommander une commande qui n'existe pas dans votre version de Redis. Commencez par capturer la version installée et les détails de construction : redis-server --version redis-cli --version La sortie attendue ressemble à : Redis server v=7.2.4 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64 build=... redis-cli 7.2.4 Si vous vous connectez à un serveur distant, utilisez le point de terminaison et le port documentés, jamais de mots de passe réels dans les exemples : redis-cli -h -p ping Un serveur sain répond PONG . Un délai d'attente ou une erreur NOAUTH indique que l'authentification est requise ou que le point de terminaison est incorrect. Ensuite, capturez la topologie et le rôle du serveur : redis-cli -h -p info replication Recherchez role:master ou role:slave . Dans une configuration Redis Sentinel ou Redis Cluster, exécutez également : redis-cli -h -p sentinel get-master-addr-by-name mymaster redis-cli -h -p cluster nodes La première commande renvoie l'adresse IP et le port du maître actuel pour le groupe surveillé par Sentinel nommé mymaster . La seconde répertorie les nœuds du cluster avec leurs identifiants, leurs rôles et leur état de connexion. Enregistrez ces valeurs et un horodatage UTC avant tout changement. Prérequis pour cette étape : - Redis CLI installé localement ou sur un hôte bastion avec accès réseau à la cible. - Identifiants en lecture seule pour les commandes INFO et PING . Si les ACL sont activées, utilisez un utilisateur avec +ping +info et aucune autorisation d'écriture. - Version Redis confirmée pour sélectionner la syntaxe appropriée à la version. Par exemple, CONFIG GET existe depuis des années, mais les sections INFO ont changé entre les versions 6.x et 7.x. Rayon d'impact : toutes les commandes ici sont en lecture seule. Aucun changement d'état. Vérification : vous connaissez la version exacte, l'hôte, le port, le rôle et la disposition du cluster. C'est votre base de référence. Récupération : aucune récupération nécessaire pour les commandes en lecture seule. Si une commande échoue, vérifiez le réseau, les autorisations ACL et les journaux Redis avant de continuer. ## Chemin de configuration sécurisé Les changements de configuration causent plus d'incidents que le code des fonctionnalités dans de nombreux systèmes. Redis ne fait pas exception : un mauvais paramètre maxmemory peut évincer les clés de manière agressive, une directive save incorrecte peut entraîner une perte de durabilité, et un protected-mode no ouvert sans authentification expose les données. Le chemin sécurisé comporte cinq étapes : - Capturer le paramètre actuel. - Comprendre la valeur par défaut et votre objectif. - Modifier un paramètre délimité. - Vérifier la nouvelle valeur et son effet. - Documenter la restauration. Commencez par lire la configuration actuelle : redis-cli -h -p CONFIG GET maxmemory redis-cli -h -p CONFIG GET maxmemory-policy redis-cli -h -p CONFIG GET save redis-cli -h -p CONFIG GET appendonly Exemple de sortie : 1) "maxmemory" 2) "0" 1) "maxmemory-policy" 2) "noeviction" 1) "save" 2) "3600 1 300 100 60 10000" 1) "appendonly" 2) "no" Cela montre une mémoire illimitée, pas d'éviction, des instantanés RDB avec la fréquence donnée et AOF désactivé. C'est une valeur par défaut courante, mais pas toujours prête pour la production. Supposons que vous souhaitiez plafonner la mémoire à 4 Go et utiliser allkeys-lru pour évincer les clés les moins récemment utilisées lorsque la limite est atteinte : redis-cli -h -p CONFIG SET maxmemory 4gb redis-cli -h -p CONFIG SET maxmemory-policy allkeys-lru Les deux renvoient OK . Vérifiez immédiatement : redis-cli -h -p CONFIG GET maxmemory maxmemory-policy Résultat attendu : 1) "maxmemory" 2) "4294967296" 3) "maxmemory-policy" 4) "allkeys-lru" Vérifiez que le changement est actif en générant une pression mémoire ou en utilisant INFO memory , mais observez seulement ; ne perturbez pas les clés de production. Prérequis : - Redis 4.0 ou version ultérieure pour allkeys-lru avec les améliorations LFU dans les versions ultérieures. Confirmez que votre version prend en charge la politique. - Autorisation d'exécuter CONFIG SET (catégorie ACL @admin ou +config|set explicite). - Connaissance de la quantité de RAM physique du serveur. Ne définissez jamais maxmemory au-dessus de la RAM disponible moins la marge pour les tampons de réplication et la surcharge de fork. Rayon d'impact : maxmemory affecte toutes les clés de la base de données sélectionnée. L'éviction peut supprimer des clés dont les applications ont encore besoin. maxmemory-policy change quelles clés sont évincées. Si vous définissez maxmemory inférieur à l'utilisation actuelle de la mémoire, Redis commence à évincer immédiatement. Récupération : pour revenir en arrière, définissez les anciennes valeurs : redis-cli -h -p CONFIG SET maxmemory 0 redis-cli -h -p CONFIG SET maxmemory-policy noeviction Pour les modifications dans le fichier redis.conf , modifiez le fichier, puis redémarrez ou utilisez CONFIG REWRITE si vous souhaitez une persistance sans redémarrage. Vérifiez avec CONFIG GET après le redémarrage. Capturez toujours les valeurs précédentes dans votre procédure avant de changer. Si le changement implique des paramètres de sécurité comme requirepass ou rename-command , testez d'abord dans un environnement de préproduction. ## Vérification et diagnostic Après tout changement, vérifiez que le système se comporte comme prévu. La vérification ne consiste pas seulement à vérifier la valeur de configuration ; il s'agit de prouver l'effet opérationnel. Utilisez une approche en couches : - Confirmation de configuration : CONFIG GET affiche la valeur active. - Comportement d'exécution : effectuez une opération sûre et minimale qui exerce le comportement modifié. - Contrôles de performance et de santé : assurez-vous qu'il n'y a pas de charge ou d'erreurs inattendues. Par exemple, après avoir activé AOF avec appendonly yes : redis-cli -h -p CONFIG SET appendonly yes redis-cli -h -p CONFIG GET appendonly La deuxième commande doit renvoyer yes . Vérifiez ensuite que la persistance fonctionne réellement : redis-cli -h -p BGREWRITEAOF BGREWRITEAOF renvoie immédiatement après le démarrage de la réécriture en arrière-plan. Vérifiez le journal du serveur ou INFO persistence pour aof_rewrite_in_progress:0 et aof_last_rewrite_time_sec dans la plage habituelle. Diagnostics pour les problèmes courants : - Latence élevée : exécutez redis-cli --latency -h -p et observez pendant 30 secondes. Établissez la latence de base et comparez après les changements. - Fragmentation de la mémoire : champs INFO memory used_memory et used_memory_rss . Si RSS est beaucoup plus élevé que la mémoire utilisée avec un taux de fragmentation > 1,5, envisagez activedefrag yes (Redis 4.0+). - Retard de réplication : sur un réplica, INFO replication affiche master_link_status:up et master_last_io_seconds_ago . Si la valeur augmente continuellement, examinez le réseau ou les E/S disque. Les commandes de diagnostic sont en lecture seule ou à faible impact. Évitez les commandes DEBUG ou MONITOR en production, sauf lors de sessions contrôlées et courtes, car elles peuvent dégrader les performances. Définissez les signaux attendus à l'avance. Par exemple, après avoir changé timeout à 300 secondes pour fermer les connexions inactives, vérifiez avec CONFIG GET timeout , puis testez en ouvrant une connexion et en attendant ; elle doit être fermée par le serveur après le délai. Prérequis : - Accès aux journaux Redis et au tableau de bord des métriques. - Compréhension de la base normale pour votre charge de travail. - Autorisation d'exécuter des commandes de diagnostic sans impact sur le trafic de production. Rayon d'impact : les commandes de diagnostic sont généralement sûres mais peuvent ajouter une charge CPU. MONITOR et KEYS peuvent bloquer ou ralentir le serveur ; évitez-les. Récupération : si la vérification révèle un état inattendu, annulez le changement en utilisant les étapes de récupération de la section précédente et recherchez la cause avant de réappliquer. ## Modes de défaillance et récupération Redis échoue de manière prévisible. Se préparer à la défaillance signifie identifier les modes les plus probables et pratiquer la récupération. ### Modes de défaillance courants - Mémoire insuffisante : maxmemory dépassé et politique noeviction . Les écritures échouent avec OOM command not allowed when used memory > 'maxmemory' . Les applications reçoivent des erreurs. - Échec de persistance : disque plein ou erreur d'E/S pendant la sauvegarde RDB ou l'ajout AOF. Redis peut continuer à servir les lectures mais la durabilité est compromise. - Réplication interrompue : partition réseau entre le maître et le réplica. Le réplica réessaie, mais le retard augmente. - Panne du maître : toutes les écritures échouent jusqu'au basculement. Dans Sentinel, un basculement automatique se produit ; en autonome, une intervention manuelle est nécessaire. - Corruption des données : fichier AOF ou RDB corrompu, provoquant un échec au démarrage. - Tempête de connexions : trop de clients en raison d'une bibliothèque cliente mal configurée ou d'un bug, épuisant les descripteurs de fichiers. ### Procédures de récupération Pour chacun, ayez une procédure testée. Exemple pour la mémoire insuffisante : redis-cli -h -p INFO memory Regardez used_memory , maxmemory , maxmemory_policy . Si la mémoire utilisée est au maximum, décidez : augmenter maxmemory en toute sécurité, changer la politique pour autoriser l'éviction, ou réduire la taille des données en supprimant les clés expirées ou moins critiques en utilisant SCAN + DEL par lots. Exemple d'éviction par lot de clés avec un motif, sans bloquer : redis-cli -h -p --scan --pattern 'temp:*' | while read key; do redis-cli -h -p DEL "$key"; done Mais utilisez avec prudence et après avoir identifié les clés. Préférez UNLINK à DEL pour les grandes clés afin d'éviter le blocage. Pour l'échec de persistance, vérifiez l'espace disque et le journal Redis. Si le disque est plein, libérez de l'espace ou redirigez dir vers un volume plus grand. Si l'AOF est corrompu, utilisez redis-check-aof --fix après avoir arrêté Redis, mais sachez que cela peut tronquer le fichier et perdre des écritures récentes. Pour l'échec de réplication, vérifiez la connectivité réseau et les règles de pare-feu. Vérifiez INFO replication des deux côtés. Si le réplica est trop en retard, il peut effectuer une resynchronisation complète, ce qui charge le maître. Faites-le pendant un trafic faible si possible. Pour une panne du maître sans basculement, restaurez à partir du dernier RDB/AOF et démarrez un nouveau maître. Si vous utilisez Sentinel, assurez-vous que le quorum est atteint et que le basculement se déclenche automatiquement ; testez cela régulièrement. Prérequis : - Sauvegardes testées et récentes. - Alertes de surveillance sur la mémoire, le disque, la réplication et les connexions clients. - Procédures pour chaque mode de défaillance. Rayon d'impact : les actions de récupération affectent souvent toutes les données. Pratiquez dans un environnement de préproduction. Vérification : après la récupération, exécutez des contrôles de santé : PING , INFO mémoire/persistance/réplication et des tests de fumée d'application. ## Liste de contrôle des opérations Utilisez ce résumé comme liste de contrôle reproductible. Chaque élément a un responsable et une fréquence de révision. ### Contrôles quotidiens (responsable : ingénieur de garde, révisé en continu via la surveillance) - Exécutez redis-cli -h -p ping pour confirmer que le serveur répond. - Vérifiez l'utilisation de la mémoire : INFO memory et comparez avec maxmemory . - Surveillez les connexions clients : INFO clients et recherchez les clients bloqués. - Vérifiez l'état de la réplication : INFO replication et assurez-vous que master_link_status:up . - Vérifiez les fichiers journaux pour les erreurs ou avertissements. ### Contrôles hebdomadaires (responsable : ingénieur DevOps, révisé chaque lundi) - Inspectez le journal lent de Redis : SLOWLOG GET 25 et optimisez les commandes lentes. - Examinez les évictions de clés : champs INFO stats evicted_keys et expired_keys . - Vérifiez la persistance : INFO persistence et vérifiez les horodatages et tailles de création des derniers RDB/AOF. - Validez l'intégrité des sauvegardes en restaurant une sauvegarde aléatoire sur une instance de test. ### Contrôles mensuels (responsable : chef d'équipe ou administrateur Redis, révisé mensuellement) - Examinez la configuration par rapport à un modèle de base et documentez les changements. - Réévaluez les limites et politiques de mémoire en fonction des tendances d'utilisation. - Testez le basculement : dans un environnement de préproduction, arrêtez le maître et assurez-vous que Sentinel ou le basculement manuel fonctionne. - Mettez à jour les procédures et les listes de contacts. ### Contrôles trimestriels (responsable : responsable d'ingénierie, révisé trimestriellement) - Examinez les contrôles d'accès et les ACL ; faites tourner les mots de passe si utilisés. - Planifiez la capacité : projetez la croissance de la mémoire et du stockage ; mettez à niveau si nécessaire. - Effectuez un exercice complet de reprise après sinistre. ### Exemple de liste de contrôle avec des valeurs concrètes Contrôle Commande Résultat attendu Signal d'échec Responsable Fréquence Serveur vivant redis-cli -h 10.0.0.5 -p 6379 ping PONG Délai d'attente ou erreur Priya Shah, On-call Quotidien Utilisation de la mémoire redis-cli -h 10.0.0.5 -p 6379 INFO memory used_memory_human inférieur à 80% de maxmemory_human Utilisé > 90% Priya Shah, On-call Quotidien Retard de réplication redis-cli -h 10.0.0.6 -p 6379 INFO replication master_last_io_seconds_ago < 10 > 60 secondes Carlos Mendes, DevOps Hebdomadaire Commandes lentes SLOWLOG GET 10 Pas d'entrées lentes graves ou toutes < 50ms Commandes > 500ms répétées Carlos Mendes, DevOps Hebdomadaire Test de sauvegarde Restaurer le dernier RDB en préproduction Clés restaurées, test de fumée d'application réussi Échec de restauration ou données manquantes Aiko Tanaka, DB Admin Hebdomadaire Exercice de basculement Arrêt simulé du maître en préproduction Sentinel promeut le réplica en 60s Pas de promotion ou split-brain Raj Patel, Eng Manager Mensuel Examen ACL ACL LIST et comparaison avec l'inventaire Tous les utilisateurs ont les autorisations minimales requises Utilisateur inconnu ou autorisation excessive Aiko Tanaka, DB Admin Trimestriel Remplacez les adresses IP, le port et les noms par les vôtres. Ne mettez jamais de mots de passe réels dans ces commandes ; utilisez des variables d'environnement ou demandez les secrets. ## Pièges courants et comment les éviter ### 1. Exécuter Redis avec la configuration par défaut en production Pourquoi cela arrive : la configuration rapide en développement est reportée en production. Comment éviter : créez un redis.conf renforcé avec protected-mode yes , bind sur les interfaces internes, définissez requirepass ou utilisez les ACL, et définissez maxmemory . Comment récupérer : auditez avec CONFIG GET * et corrigez les paramètres ; redémarrez avec une configuration corrigée ou utilisez CONFIG SET et CONFIG REWRITE . ### 2. Utiliser la commande KEYS en production Pourquoi cela arrive : les développeurs utilisent KEYS pattern pour le débogage, sans se rendre compte qu'elle bloque le serveur pour toutes les autres commandes. Comment éviter : utilisez SCAN avec un curseur, qui itère de manière incrémentale. Appliquez avec les ACL : interdisez KEYS pour les utilisateurs d'application. Comment récupérer : si KEYS est en cours d'exécution et provoque de la latence, attendez qu'elle se termine ou, dans les cas extrêmes, redémarrez Redis (dernier recours). Remplacez ensuite toute utilisation de KEYS par SCAN dans le code. ### 3. Ignorer les compromis de persistance Pourquoi cela arrive : supposer que Redis n'est qu'un cache et que la durabilité n'est pas nécessaire, puis perdre des données au redémarrage surprend l'équipe. Comment éviter : choisissez explicitement RDB, AOF ou les deux en fonction de l'objectif de point de récupération. Pour la plupart des productions, activez AOF avec appendfsync everysec et des instantanés RDB périodiques. Comment récupérer : activez AOF et créez un nouvel instantané ; testez la récupération. ### 4. Ne pas définir maxmemory Pourquoi cela arrive : par défaut, maxmemory 0 signifie aucune limite, et le système d'exploitation peut tuer Redis lorsque la mémoire s'épuise. Comment éviter : définissez maxmemory à environ 70-80% de la RAM disponible, et choisissez une politique d'éviction adaptée à vos données. Comment récupérer : définissez maxmemory et la politique, surveillez les évictions. ### 5. Renommer des commandes critiques sans mettre à jour les clients Pourquoi cela arrive : le renforcement de la sécurité renomme CONFIG , FLUSHALL , etc., mais les clients qui les utilisent légitimement se cassent. Comment éviter : auditez l'utilisation des clients avant de renommer ; utilisez les ACL pour restreindre au lieu de renommer pour tout le serveur lorsque c'est possible. Comment récupérer : annulez le renommage ou mettez à jour le code client et redémarrez. ### 6. Ne pas tester le basculement Pourquoi cela arrive : le basculement est complexe et supposé fonctionner parce qu'il est configuré. Comment éviter : planifiez des exercices de basculement réguliers en préproduction et occasionnellement en production si sûr. Comment récupérer : après un vrai basculement, examinez les journaux et la surveillance pour assurer la promotion et la cohérence des données. Chaque piège peut être évité avec de bonnes valeurs par défaut, une surveillance et un examen régulier. Lorsqu'une erreur se produit, la récupération doit être un ensemble d'étapes connues, pas une réponse ad hoc. ## Conclusion Une liste de contrôle des opérations Redis en production ne vaut que par votre volonté de l'utiliser avant et après chaque changement. La discipline fondamentale est l'observation avant l'intervention : capturez la version et la topologie, lisez la configuration actuelle, effectuez un changement délimité avec un résultat attendu défini, vérifiez avec des commandes et des métriques, et gardez un chemin de restauration. Les exemples de cet article montrent les commandes exactes pour l'inventaire, la configuration, le diagnostic et la récupération. Remplacez les espaces réservés par vos hôtes et ports, mais jamais par de véritables identifiants dans un document partagé. Commencez petit : choisissez une vérification à faible risque de la liste de contrôle, enregistrez l'état actuel, exécutez la vérification, comparez au signal attendu, puis développez. Examinez les dépendances telles que les clients Node.js, le réseau Docker ou les intégrations de surveillance uniquement lorsqu'elles affectent le comportement de Redis. Rendez la défaillance visible, protégez les valeurs sensibles, limitez les changements à la ressource prévue et testez la récupération avant qu'un incident ne force la décision. Un Redis bien exploité n'est pas magique ; c'est un ensemble d'habitudes, répétées jusqu'à ce qu'elles deviennent une seconde nature.