Optimiser les performances Redis Cluster : Analyser la latence des commandes par shard en temps réel

En production, un Redis Cluster peut sembler performant à première vue, mais des variations de latence par shard trahissent souvent des déséquilibres de charge, des problèmes réseau ou des configurations sous-optimales. Sans une instrumentation fine, ces anomalies passent inaperçues dans les métriques agrégées, alors qu’elles impactent directement l’expérience utilisateur et la stabilité de votre application.

Ce guide vous explique comment mesurer, analyser et corriger la latence des commandes Redis par shard, en temps réel, pour identifier les goulots d’étranglement avant qu’ils ne dégénèrent en incidents.

Pourquoi la latence par shard est un indicateur clé

Dans un cluster Redis, chaque shard (ou slot hash) gère une partie des données. Si un shard devient un point chaud (hotspot), les commandes qui y sont exécutées peuvent voir leur latence exploser, tandis que les autres restent stables. Par exemple :

Un HGETALL sur un hash volumineux peut passer de 2 ms à 200 ms si le shard est saturé par des requêtes simultanées.
Une réplication asynchrone mal configurée peut introduire des délais invisibles dans les métriques globales.
Un réseau congestionné entre un client et un shard spécifique peut ralentir uniquement les opérations ciblant ce nœud.

Analogie : Imaginez un entrepôt logistique où chaque quai (shard) gère une partie des colis. Si un quai est submergé, les livraisons qui en dépendent sont retardées, même si les autres fonctionnent normalement. Les métriques globales (ex. : « 95% des colis livrés à l’heure ») masquent ce problème.

Sans une surveillance par shard, vous risquez de :

Sous-estimer l’impact des pics de charge sur des données critiques.
Perte de temps à déboguer des problèmes fantômes (ex. : « Pourquoi cette requête est-elle lente ? »).
Dégrader l’expérience utilisateur pour une minorité de requêtes, mais avec un impact disproportionné (ex. : panier d’achat, sessions utilisateurs).

Comment instrumenter la latence des commandes par shard

Pour capturer la latence par shard, vous devez :

Identifier les commandes critiques (ex. : GET, SET, HGETALL, LPUSH).
Associer chaque commande à son shard via le hash slot de la clé.
Mesurer le temps d’exécution de bout en bout (client → serveur → client).
Agrégé les métriques par shard, commande et percentile (P50, P95, P99).

Étapes concrètes avec Redis et un outil d’observabilité

1. Activer le command latency tracking dans Redis

Redis propose un module natif pour suivre la latence des commandes, mais il est global (pas par shard). Pour une granularité fine, utilisez :

LATENCY (Redis 6+) pour les commandes lentes, mais limité aux opérations > 1 ms.
CONFIG SET latency-tracking yes pour activer le suivi, puis LATENCY LATEST pour voir les dernières anomalies.

Limite : Ces outils ne segmentent pas par shard. Il faut donc corréler les logs applicatifs avec les métriques Redis.

2. Instrumenter votre client Redis

Le client Redis (ex. : redis-py, ioredis, Jedis) doit :

Intercepter chaque commande avant envoi.
Calculer le hash slot de la clé (via CRC16(key) % 16384).
Mesurer le temps entre l’envoi de la commande et la réception de la réponse.
Envoyer les métriques à votre outil d’observabilité (ex. : Prometheus, Lescopr).

Exemple en Python avec redis-py et Prometheus :

import time
import redis
from prometheus_client import Summary

# Métrique Prometheus pour la latence par shard
LATENCY_BY_SHARD = Summary(
    'redis_command_latency_seconds',
    'Latence des commandes Redis par shard',
    ['shard', 'command']
)

r = redis.Redis(host='cluster-node', port=6379)

def get_shard(key):
    return hash(key) % 16384  # Simplifié pour l'exemple

def timed_command(command, *args):
    key = args[0] if args else None
    shard = get_shard(key) if key else