# Redis Cluster contre Redis Sentinel pour 500 sites WordPress

> Haute disponibilité et performance comparées entre les deux architectures Redis pour un réseau communal, avec le point précis où Sentinel cesse de suffire face à la charge.

- Auteur : WordPress Développement
- Publié le : 2021-10-22
- Mis à jour le : 2021-10-22
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/redis-cluster-vs-sentinel-500-sites/

## L’essentiel

- Sentinel suffit tant que le jeu de données tient sur un seul nœud
- Cluster distribue les données mais complique les opérations transversales
- Le point de bascule dépend du volume, pas seulement du nombre de sites

Redis Sentinel ou Redis Cluster : la question se pose systématiquement dès qu'un réseau de sites WordPress dépasse quelques dizaines d'instances partageant la même infrastructure de cache. Pour un réseau communal regroupant 500 sites, cette question a été tranchée après un test de charge comparatif plutôt que sur la seule base de la documentation officielle Redis.

## Ce que fait chaque architecture

Redis Sentinel assure la haute disponibilité d'un jeu de données qui reste entièrement répliqué sur chaque nœud : un nœud maître reçoit les écritures, des nœuds réplicas suivent, et Sentinel bascule automatiquement un réplica en maître en cas de panne. Toutes les données restent disponibles sur chaque nœud, ce qui simplifie les opérations de lecture mais limite la capacité totale du système à la mémoire d'un seul serveur.

Redis Cluster, à l'inverse, distribue les données sur plusieurs nœuds maîtres via un système de hachage en 16 384 slots, chaque nœud ne portant qu'une partie du jeu de données total. La capacité totale du cluster peut ainsi dépasser la mémoire d'une seule machine, au prix d'une complexité opérationnelle supérieure : certaines commandes multi-clés ne fonctionnent que si les clés concernées appartiennent au même slot.

## Comparatif appliqué au cas des 500 sites communaux

| Critère | Redis Sentinel | Redis Cluster |
| --- | --- | --- |
| Capacité mémoire totale | Limitée à un seul nœud | Somme des nœuds maîtres |
| Complexité opérationnelle | Faible, proche d'un maître-réplica classique | Élevée, gestion des slots et du rééquilibrage |
| Compatibilité multi-clés (MGET, pipelines) | Totale | Limitée aux clés du même slot (hash tags requis) |
| Bascule en cas de panne | Automatique via quorum Sentinel | Automatique par nœud, plus granulaire |
| Coût d'infrastructure | Un maître + réplicas | Plusieurs nœuds maîtres + réplicas par nœud |

> L'essentiel à retenir : Sentinel suffit tant que le jeu de données tient sur un seul nœud ; Cluster distribue les données mais complique les opérations transversales ; Le point de bascule dépend du volume, pas seulement du nombre de sites

## Le point de bascule mesuré sur ce réseau

Le test de charge a consisté à simuler la montée en charge progressive du réseau, en ajoutant des sites fictifs générant un volume de cache représentatif (options, transients, fragments de requêtes) jusqu'à observer une dégradation. Avec Redis Sentinel sur un nœud maître disposant de 16 Go de RAM allouée au cache, la dégradation est apparue nettement au-delà de 12 Go de données réellement en cache : le temps de réponse moyen des commandes `GET` a commencé à augmenter sensiblement, un signe que la mémoire disponible pour les structures internes de Redis (et non plus seulement les données) devenait insuffisante.

Ce seuil de 12 Go ne dépend pas directement du nombre de sites (500 dans ce cas) mais du volume cumulé de données mises en cache par l'ensemble du réseau, ce qui signifie qu'un réseau de sites à fort contenu dynamique atteindra ce point de bascule plus vite qu'un réseau de sites majoritairement statiques, même à nombre de sites identique.

## Pourquoi Sentinel a finalement été retenu, pour l'instant

Malgré ce seuil identifié, le réseau communal a conservé Redis Sentinel, pour deux raisons pratiques. D'abord, le volume réel de cache mesuré en production restait à ce stade sous les 8 Go, avec une marge confortable avant d'atteindre le seuil de dégradation observé en test. Ensuite, la simplicité opérationnelle de Sentinel, en particulier pour les commandes multi-clés utilisées par certaines extensions de cache d'objets, évitait de devoir réécrire ou valider la compatibilité de ces extensions avec les contraintes de hachage par slot imposées par Cluster.

## Ce qui ferait basculer vers Cluster

- Un dépassement durable du seuil de mémoire identifié en test, plutôt qu'un pic ponctuel absorbable par une purge de cache.
- L'arrivée de nouveaux sites au contenu fortement dynamique (recherche facettée, personnalisation par utilisateur), qui gonflerait rapidement le volume de cache par site.
- Un besoin de répartir la charge d'écriture sur plusieurs nœuds maîtres plutôt que sur un seul, si le débit d'écriture devenait lui-même un goulot d'étranglement.

> Le choix entre Sentinel et Cluster ne se tranche jamais sur le nombre de sites seul : c'est le volume de données réellement mises en cache qui détermine le point de bascule.

## En résumé

Pour un réseau de 500 sites WordPress, Redis Sentinel reste une architecture pertinente tant que le volume cumulé de cache reste sous le seuil de dégradation propre à la capacité mémoire du nœud maître, mesuré ici autour de 12 Go. Redis Cluster devient nécessaire lorsque ce volume dépasse durablement la capacité d'une seule machine, au prix d'une complexité opérationnelle supplémentaire à anticiper, notamment sur la compatibilité des commandes multi-clés utilisées par les extensions de cache existantes.