Redis sur Linux : installation, configuration et sécurisation production

Table des matières :

Redis en production sur Linux, ce n’est pas “juste” un apt install redis. C’est un service réseau à très haut débit, souvent critique (cache applicatif, sessions, queues, locks), et donc un point de défaillance et une surface d’attaque. Les exemples ci-dessous sont validés pour Debian 12 / Ubuntu 24.04, Redis 7.x (paquet de la distribution), et un contexte e‑commerce type PrestaShop 8/9 sur PHP 8.2/8.3.

Redis en environnement Linux : ce que vous déployez réellement

Redis est un data store en mémoire orienté structures (strings, hashes, lists, sets, sorted sets, streams), avec un modèle d’exécution principalement single-thread pour la majorité des commandes (l’I/O peut être multithread selon version/config). Ça lui donne une latence très basse, mais implique aussi un point d’attention : un seul client qui envoie des opérations coûteuses (ou des scripts Lua mal maîtrisés) peut impacter tout le monde.

En prod, Redis sert rarement “juste” de cache. On le voit pour : cache HTTP applicatif (fragments), cache d’objets, verrous distribués (stock, checkout), anti-concurrence (réservation), rate limiting, et asynchrone léger via Streams. Sur PrestaShop, Redis est typiquement branché comme cache via l’extension PHP, et parfois pour des usages plus “métier” (locks sur stock).

Un mini‑scénario typique en e‑commerce : pendant un pic (soldes / campagne Ads), un module commence à écrire des clés “cache” sans TTL (ou avec un TTL très long). Redis grossit, la fragmentation mémoire augmente, puis vous observez (a) des évictions si maxmemory est atteint, (b) ou pire, du swap si maxmemory n’est pas défini → latences côté PHP → augmentation du TTFB → paniers abandonnés. L’intérêt de Redis en prod est réel, mais il faut le traiter comme un composant à budget mémoire et à contrat d’usage.

Pour le contexte applicatif, vous pouvez recouper avec :

Côté sécurité, Redis a une posture claire : le service doit rester dans un environnement de confiance. La documentation officielle insiste sur le fait que Redis est conçu pour être accessible par des clients de confiance dans des environnements de confiance, et qu’il faut donc éviter toute exposition directe à Internet (voir Redis Docs – Security). Traduction opérationnelle : pas d’exposition Internet, pare‑feu, segment réseau dédié, authentification/ACL, et TLS si vous traversez un réseau non maîtrisé.

Choix du mode d’installation : paquets distro vs build source (et pourquoi ça compte)

Sur Debian/Ubuntu, le choix le plus simple et le plus maintenable reste le paquet de distribution (redis-server) : intégration systemd, chemins standard /etc/redis/, logs gérés, utilisateur dédié (redis), et mises à jour de sécurité via APT. Le compromis : vous ne serez pas forcément sur la toute dernière mineure de Redis, mais en prod e‑commerce, la stabilité et la reproductibilité priment (y compris pour les redémarrages planifiés et les rollbacks).

Compiler depuis les sources (ou utiliser un dépôt tiers) peut être pertinent dans deux cas : (1) vous avez une contrainte fonctionnelle très précise (module, TLS/build options spécifiques), (2) vous devez uniformiser une version Redis dans un parc hétérogène. En contrepartie, vous portez la charge des upgrades, du packaging (systemd unit, user, logrotate), et du hardening. Si vous n’avez pas de pipeline infra solide, c’est souvent une fausse bonne idée.

Enfin, clarifiez l’architecture dès maintenant : Redis sur le même host que PHP‑FPM/MySQL (latence minimale, simplicité) vs Redis sur un nœud dédié (isolement ressources, meilleure sécurité).

Même host : idéal si vous visez le socket Unix, si votre shop est mono‑VM et que la latence doit être minimale. Attention au “bruit” CPU/RAM : PHP‑FPM + MySQL + Redis sur une petite VM, ça peut devenir imprévisible lors d’un pic.
Nœud dédié : intéressant si vous avez déjà un réseau privé (VLAN, VPC, Security Groups) et si vous voulez isoler la RAM Redis (et éviter qu’un runaway PHP ne le pénalise). En contrepartie, vous ajoutez un hop réseau et vous devez être rigoureux sur pare‑feu, ACL, et éventuellement TLS.

Sur des boutiques avec trafic irrégulier (soldes), Redis peut se faire “manger” la RAM par des clés non TTL ou des pools trop agressifs. Une mauvaise politique mémoire Redis se traduit par des symptômes côté web (latence, erreurs 503). Pour corréler infra/app, gardez sous la main un runbook de diagnostic (exemple : guide de diagnostic des erreurs 503 (logs & ressources)).

Installation sur Debian/Ubuntu (systemd) : base saine et vérifications

Sur Debian 12 / Ubuntu 24.04 :

sudo apt update
sudo apt install -y redis-server redis-tools
sudo systemctl enable --now redis-server

Premiers checks “non négociables” : version, service, et ping local.

redis-server --version
systemctl status redis-server --no-pager
redis-cli ping

Ajoutez un contrôle simple mais très utile : vérifier où Redis écoute réellement (TCP, socket Unix, IP). Ça évite les surprises quand vous durcissez le réseau.

ss -lntp | grep redis || true
ss -lx | grep redis || true

Avant toute modification, identifiez le chemin de config réellement utilisé. Sur Debian/Ubuntu, c’est typiquement /etc/redis/redis.conf et la unit systemd inclut parfois des overrides. Inspectez :

systemctl cat redis-server

À ce stade, ne tombez pas dans le piège classique : “ça répond, donc c’est OK”. Un Redis prod doit aussi passer une validation de ressources Linux (limites de fichiers, backlog, THP). Redis lui‑même vous mettra des warnings dans les logs au démarrage. Consultez :

journalctl -u redis-server -n 200 --no-pager

Astuce d’exploitation : faites une sauvegarde de la config avant hardening/optimisation, et versionnez‑la (Git / Ansible / Puppet). Une modif Redis “à la main” à 2h du matin est une dette technique quasi garantie.

Configuration production : mémoire, persistence, latence et réglages kernel

La RAM est la contrainte centrale. Sans maxmemory, Redis va consommer jusqu’à épuiser la mémoire (OOM killer ou swap → latence catastrophique). Définissez une enveloppe réaliste, tenant compte de PHP‑FPM, du buffer cache Linux, et de MySQL.

Un ordre de grandeur pragmatique sur une VM “web + DB + Redis” : ne pas donner 100% de la RAM à Redis. Laissez de la marge au système et aux autres processus (et rappelez‑vous que des forks peuvent survenir lors de snapshots/AOF rewrite). Sur un serveur dédié Redis, vous pouvez être plus agressif, mais gardez quand même de la marge pour l’OS et la fragmentation.

Exemple (à adapter) dans /etc/redis/redis.conf :

maxmemory 2gb
maxmemory-policy allkeys-lru

La politique d’éviction est un choix métier : allkeys-lru est souvent acceptable pour du cache applicatif (on préfère perdre du cache que tomber). Pour des données critiques (queues, verrous), ne stockez pas dans la même instance que du cache non critique, ou segmentez au minimum par DB/logique et TTL stricts, en assumant que l’éviction peut casser des workflows. En e‑commerce, c’est typiquement une raison valable de dédier une instance Redis aux jobs/streams/locks.

Autres réglages “production‑friendly” souvent utiles (sans sur‑optimiser) :

timeout 0
tcp-keepalive 300
databases 16

timeout 0 évite de couper des clients “silencieux” si votre appli maintient des connexions longues (à valider selon votre client PHP).
tcp-keepalive aide à détecter des connexions mortes (utile quand Redis est sur un nœud dédié derrière du NAT / load balancer).

Persistence : RDB, AOF, ou les deux. RDB (snapshots) est simple mais peut perdre des secondes/minutes selon intervalle. AOF journalise chaque écriture, réduit la perte en cas de crash, mais augmente I/O et temps de restart (replay). Une base prod “cache only” peut être sans persistence ; une base “queue/stream” sans persistence est un pari risqué.

Les réglages suivants sont une base courante :

appendonly yes
appendfsync everysec
save 900 1
save 300 10
save 60 10000

Deux points opérationnels souvent oubliés :

Espace disque : AOF peut grossir, puis se réécrire (rewrite). Vérifiez la place disponible sur la partition qui contient /var/lib/redis (par défaut sur Debian/Ubuntu).
Temps de redémarrage : si l’AOF est volumineux, le replay peut être long. Testez un redémarrage hors pic et mesurez. (Un “restart” qui met 90 secondes peut être OK si vous avez un fallback, pas si Redis est un SPOF.)

Côté kernel, trois réglages reviennent constamment.

1) Overcommit : Redis recommande d’activer l’overcommit mémoire pour éviter des échecs d’allocations lors de forks (RDB/AOF rewrite). La recommandation et la commande associée sont documentées ici (voir Redis Docs – Linux kernel settings).

2) Transparent Huge Pages (THP) : souvent source de spikes de latence. Désactivez‑le au boot (méthode dépend distro). Pour un test immédiat :

cat /sys/kernel/mm/transparent_hugepage/enabled
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

Pour le rendre persistant, préférez une méthode propre (service systemd/GRUB selon distro). Sur un serveur e‑commerce, l’objectif est simple : éviter que la latence “pique” de façon sporadique, car côté PHP, ça se traduit vite par des timeouts.

3) Backlog & somaxconn : si vous voyez des TCP backlog warnings, ajustez :

sudo sysctl -w net.core.somaxconn=1024

Ces paramètres doivent être persistés via /etc/sysctl.d/99-redis.conf (plutôt que modifier sysctl.conf “à la main”). En bonus, surveillez aussi le swap : Redis peut fonctionner avec du swap, mais les performances s’effondrent. En pratique, on vise un système qui ne swappe pas sous charge normale (et on alerte si ça arrive).

Sécurisation : réseau, ACL, socket Unix, TLS et hardening systemd

Règle n°1 : ne pas exposer Redis sur Internet. Même avec mot de passe, c’est une mauvaise idée (bruteforce, vulnérabilités clients, erreurs de config). Utilisez un réseau privé, un security group, ou au minimum un pare‑feu local strict. Côté conf, commencez par limiter l’écoute :

bind 127.0.0.1 ::1
protected-mode yes
port 6379

Après changement, vérifiez que vous n’avez pas “laissé traîner” une écoute sur 0.0.0.0 :

ss -lntp | grep 6379 || true

Si Redis est consommé uniquement localement (même host), privilégiez le socket Unix : latence faible, pas d’ouverture TCP, permissions POSIX. Exemple :

port 0
unixsocket /run/redis/redis.sock
unixsocketperm 770

Test rapide côté CLI :

redis-cli -s /run/redis/redis.sock ping

Ajoutez ensuite les droits via groupe (ex: www-data ou l’utilisateur PHP‑FPM) selon votre modèle. Attention : donner accès au socket = donner accès total à Redis. On ne “bricole” pas ça en prod : on audite qui est membre du groupe.

Authentification : oubliez requirepass seul sur du multi‑app. Depuis Redis 6, utilisez ACL (users, commandes autorisées, patterns de clés). Exemple minimal :

user default off
user app on >S3cr3tP4ss ~cache:* +get +set +del +expire +ttl +pttl +ping

Bon réflexe : valider vos ACL et les commandes autorisées/interdites :

redis-cli ACL LIST
redis-cli ACL GETUSER app
redis-cli ACL CAT

La granularité ACL est un vrai levier de réduction de blast radius : vous pouvez interdire CONFIG, FLUSHALL, KEYS, EVAL, etc. Dans une boutique, ça évite qu’un bug module ou une mauvaise commande en CLI fasse sauter tout le cache en plein pic. Côté exploitation, préférez SCAN à KEYS (car KEYS peut bloquer Redis sur de gros keyspaces).

TLS : Redis supporte TLS nativement (à partir de Redis 6) mais le déploiement a un coût (certificats, CPU, validation). Si Redis traverse un réseau non fiable (multi‑nœuds, cloud, VLAN partagés), TLS est cohérent. Sinon, socket Unix / réseau privé est souvent plus simple et plus performant. La documentation TLS officielle se trouve ici : Redis TLS docs, qui détaille tls-port, tls-cert-file, tls-key-file, tls-ca-cert-file.

Hardening systemd : le paquet distro fournit déjà un user non privilégié. Vous pouvez renforcer via un drop‑in (systemctl edit redis-server) sans modifier la unit d’origine. Exemple pragmatique :

# /etc/systemd/system/redis-server.service.d/hardening.conf
[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/redis /var/log/redis /run/redis
MemoryDenyWriteExecute=true

Deux durcissements souvent utiles en plus, à tester selon votre packaging :

augmenter les fichiers ouverts (Redis + beaucoup de clients) ;
forcer un umask plus strict pour les fichiers générés.

Exemple :

[Service]
LimitNOFILE=65535
UMask=007

Testez systématiquement après durcissement : un mauvais ProtectSystem ou un ReadWritePaths incomplet casse AOF/RDB au redémarrage.

Observabilité et exploitation : métriques, slowlog, latence et capacity planning

Le minimum viable en prod : INFO, SLOWLOG, LATENCY, et des alertes sur mémoire/évictions. Quelques commandes utiles :

redis-cli INFO memory
redis-cli INFO stats
redis-cli SLOWLOG GET 10
redis-cli LATENCY DOCTOR

Surveillez en particulier : used_memory, used_memory_peak, mem_fragmentation_ratio, evicted_keys, keyspace_hits/misses, rejected_connections, et la fréquence des fork (RDB/AOF rewrite).

Pour rendre le slowlog exploitable, assurez-vous qu’il est réglé (valeurs à ajuster selon vos workloads). Par exemple, loguer ce qui dépasse 10 ms :

redis-cli CONFIG SET slowlog-log-slower-than 10000
redis-cli CONFIG SET slowlog-max-len 256

Si mem_fragmentation_ratio part durablement au‑delà de ~1.5, ce n’est pas “magique” : ça se traite (allocator, patterns d’objets, redémarrage contrôlé, upgrade, ou isolation d’instances). Dans certains cas, activer la défragmentation active peut aider, au prix d’un peu de CPU (à valider dans votre contexte) :

activedefrag yes

Pour des métriques time‑series, deux options classiques : exporter Prometheus (redis_exporter) + dashboards Grafana. Vous avez déjà des briques côté site pour la partie visu/supervision :

En alternatif “prêt à diagnostiquer” sur VM, Netdata est souvent plus rapide à mettre en place pour corréler CPU steal, I/O, réseau et process Redis : Netdata monitoring : surveiller AWS, Kubernetes, bases de données et serveurs web.

Côté capacity planning, ne vous fiez pas à une estimation “au doigt”. Mesurez (idéalement depuis le même hôte, ou depuis le même réseau privé, pour éviter de benchmarker surtout la latence réseau) :

redis-benchmark -q -n 200000 -c 50 -P 16 -t get,set

L’objectif n’est pas de se vanter d’un chiffre, mais d’obtenir un ordre de grandeur sur votre CPU/NUMA et de voir l’impact de TLS, de l’AOF, ou d’un stockage plus lent. Dans un setup e‑commerce, une dégradation Redis se traduit souvent par un TTFB qui dérive et des timeouts côté PHP‑FPM. Si vous êtes en phase d’optimisation globale, mettez Redis dans le même tableau que PHP‑FPM/MySQL/OPcache : Performance PrestaShop : benchmarks et optimisation PHP‑FPM, OPCache, MySQL.

Intégration applicative (PHP/PrestaShop) : éviter les erreurs de design qui ruinent Redis

Sur PHP, vous avez deux clients Redis dominants : phpredis (extension C) et Predis (pur PHP). En prod, phpredis est généralement le choix rationnel (latence, CPU). Pour activer/valider l’extension, les subtilités multi‑bases, et la supervision côté PHP : Redis PHP : activer l’extension, choisir les bases et surveiller l’usage.

Dans PrestaShop, Redis sert souvent à absorber : cache de classes, cache Smarty, et caches applicatifs dépendants des modules. Deux points font mal en prod : (1) clés sans TTL (cache qui devient une base), (2) absence de namespace/versioning de clés (un déploiement casse la cohérence).

Adoptez un préfixe versionné (shop:v9:cache:) et gardez la capacité de “purger” par changement de version sans FLUSHALL. Concrètement, ça signifie :

préfixer toutes les clés par application + environnement (prod, staging) ;
ajouter un suffixe de version (ou un numéro de release) ;
éviter les purges globales en prod (préférez une rotation de namespace).

Autre erreur de design classique : faire des opérations “globales” au runtime (ex. KEYS shop:* ou des SMEMBERS énormes). Préférez des structures bornées, des TTL, et des patterns de parcours incrémentaux (SCAN) si vous avez besoin d’inspection.

Si vous gérez des périodes de charge, la stratégie multi‑niveaux (OPcache + Redis + Varnish) évite de sur‑stresser Redis : Optimiser PrestaShop pour les soldes : cache multi‑niveaux et CCC.

Enfin, n’utilisez pas Redis comme “pansement” pour masquer des requêtes SQL lentes ou un modèle de données bancal. Si MySQL est le vrai goulot, Redis ne fera que déplacer la pression (et compliquera le debug). Activez le slow query log, corrigez indexes/queries, puis seulement après, cachez ce qui est cacheable : Requêtes MySQL lentes PrestaShop : activer slow query log.

Checklist de mise en production (courte, mais orientée risques)

Validez ces points avant d’ouvrir le trafic :

Réseau : Redis non exposé publiquement, bind restreint, pare‑feu OK, idéalement socket Unix.
Auth : ACL en place (default off), commandes dangereuses interdites, secrets stockés proprement (Vault/secret manager si possible). Bonus : un compte “admin” séparé (utilisé uniquement en maintenance) et un compte “app” minimaliste.
Mémoire : maxmemory défini, policy cohérente avec l’usage, alertes sur evicted_keys. Vérifiez aussi maxmemory avant les pics (pas après incident).
Persistence : AOF/RDB choisi explicitement, tests de restart (temps de reprise acceptable), sauvegardes si données non reproductibles. Faites au moins un test de restauration (copie de /var/lib/redis vers une VM de test et démarrage).
Kernel : vm.overcommit_memory=1, THP désactivé, somaxconn ajusté, ulimit -n suffisant (souvent via systemd LimitNOFILE). Surveillez le swap : si ça swappe, c’est un incident de perf.
Observabilité : métriques, logs, slowlog, et corrélation avec erreurs applicatives (cf. monitoring d’erreurs PrestaShop : logs PHP, MySQL, JavaScript et alertes e‑mail).

Si vous cochez tout ça, Redis devient un composant prévisible. Si vous laissez des “valeurs par défaut” en prod, il restera rapide… jusqu’au jour où il ne l’est plus, et où vous le découvrirez à 2h du matin pendant un pic.