Failover automatique ElastiCache — ce qui se passe vraiment durant ces quelques secondes

Ce guide explique ce qui se passe pendant un failover automatique (basculement) dans Amazon ElastiCache pour Redis. Il s’adresse aux équipes qui exploitent Redis en production sur ce service. ElastiCache est le service Redis géré d’AWS. Avec Multi-AZ activé, il garde un réplica (une copie vivante de vos données) dans une deuxième zone de disponibilité, soit un centre de données distinct dans la même région. Quand le nœud primaire tombe, ElastiCache promeut ce réplica pour le remplacer.

Prenons une vraie nuit. À 3 h 14, le primaire dans us-east-1b subit une panne matérielle, et le failover automatique promeut le réplica dans us-east-1c. L’alerte se résout avant que l’ingénieur de garde soit complètement réveillé. Le lendemain matin, le tableau de bord montre un creux de 12 secondes où environ 0,4 % des requêtes ont retourné une erreur 500. L’équipe parle d’un failover réussi et passe à autre chose. Ces 12 secondes contenaient pourtant des écritures rejetées, des reconnexions clientes et un changement de primaire. Les sections qui suivent détaillent chaque étape, la bonne réaction côté client, pourquoi le failover ne se déclenche parfois pas même quand le primaire est dégradé, et quoi faire dans ce cas.

Ce qui se passe

Le failover automatique d’ElastiCache est un wrapper géré autour de vérifications de santé style Sentinel Redis plus des événements d’infrastructure AWS. Le déroulement ressemble à ceci.

Détection (1–3 secondes). ElastiCache surveille continuellement chaque nœud via le plan de gestion. Les signaux de panne incluent : refus de connexion TCP, timeout de réponse sur PING, CPU soutenu près de 100 %, ou un événement EC2 indiquant que l’hôte sous-jacent a échoué. Le seuil de détection par défaut est conservateur — un seul ping manqué ne déclenche pas de failover. Une poignée d’échecs consécutifs ou un signal d’infrastructure clair, oui.

Décision de promotion (1–2 secondes). Une fois le primaire jugé mort, ElastiCache choisit un réplica à promouvoir. La décision considère le décalage de réplication (le réplica le plus à jour gagne), le placement AZ (préfère rester multi-AZ), et la santé du nœud. Si le cluster a Multi-AZ activé avec failover automatique, la promotion est entièrement automatique. Sinon, le cluster stagne dans un état dégradé jusqu’à intervention manuelle.

Mise à jour DNS (1–5 secondes). L’endpoint primaire du cluster est un enregistrement Route 53 pointant vers le primaire actuel. À la promotion, ElastiCache met à jour l’enregistrement DNS pour pointer vers le nouveau primaire. Le TTL est court (typiquement 5–10 secondes), mais chaque client doit le respecter. Les clients avec un DNS mis en cache longuement continueront de frapper l’ancien endpoint.

Reconfiguration des réplicas (5–10 secondes). Les réplicas restants (et l’ancien primaire rétrogradé s’il revient) doivent réinitialiser la réplication et pointer vers le nouveau primaire. Pendant cette fenêtre, le cluster apparaît multi-primaire pour les clients connectés à des nœuds spécifiques — l’ancien primaire peut répondre READONLY aux écritures, le nouveau primaire les accepte, et les réplicas peuvent avoir un bref rattrapage de réplication avant de servir des lectures cohérentes.

Reconnexion cliente (variable, 0–30 secondes). Chaque bibliothèque cliente gère le failover différemment. Certaines détectent la déconnexion immédiatement et se reconnectent via le DNS de l’endpoint primaire, qui résout maintenant vers le nouveau nœud. Certaines maintiennent la connexion TCP morte jusqu’à ce que l’OS la fasse expirer, ce qui est beaucoup plus long. Les clients qui ont résolu l’endpoint primaire une fois au démarrage et ont mis en cache l’IP ne verront jamais le nouveau primaire sans un rafraîchissement explicite.

L’indisponibilité observable totale est dominée par la plus longue de ces phases. Avec des clients en bonne santé et Multi-AZ activé, 5–15 secondes est typique. Avec des clients qui mettent en cache le DNS ou ne réessaient pas, le même failover peut sembler être une panne de 60 secondes du point de vue d’un seul serveur applicatif même si le cluster s’est rétabli en 8 secondes.

Le cas rare où le failover automatique ne se déclenche pas : ElastiCache distingue les pannes « dures » (nœud injoignable, hôte arrêté) des « problèmes mous » (nœud répond lentement, retourne des erreurs mais reste joignable). Un événement read-only sur le primaire — par exemple, une condition out-of-memory déclenchant des tempêtes d’éviction mais le nœud répond encore au TCP — peut ne pas déclencher de failover même quand le primaire est effectivement inutile. Le réplica est sain, mais le cluster ne le promeut jamais parce que techniquement le primaire répond toujours à PING.

Comment vérifier

Trois vérifications d’observabilité vous disent ce que le cluster a fait et comment les clients ont géré.

Événements CloudWatch autour du failover. ElastiCache publie des événements pour chaque transition d’état.

aws elasticache describe-events \
  --source-identifier saas-prod-001 \
  --source-type cache-cluster \
  --start-time $(date -u -v-1d +%Y-%m-%dT%H:%M:%S) \
  --duration 60 \
  --max-records 50

Les événements à voir dans un failover réussi : Replication group ... primary location changed from <az> to <az>, Failover from primary node ... completed. Le temps entre le premier événement et l’événement de complétion est le temps de récupération côté cluster.

Taux d’erreur par client pendant la fenêtre. Côté application, ce qui compte est le taux d’erreur des requêtes pendant la fenêtre de failover. Filtrez les logs d’accès pour la fenêtre de failover et comptez les réponses 5xx par code d’erreur amont.

grep "23:14:" /var/log/app/access.log \
  | awk '$9 >= 500 { print $9, $NF }' \
  | sort | uniq -c | sort -rn

Une distribution saine montre un bref pic de 502 ou 504 du répartiteur de charge, atteignant un sommet pendant quelques secondes et se dissipant. Une mauvaise distribution montre le taux d’erreur ne se dissipant pas pendant 30+ secondes, ce qui signifie que les clients ne se reconnectent pas — c’est un problème de configuration cliente, pas un problème ElastiCache.

Décalage de réplication juste avant le failover. Si le failover automatique a été forcé par un primaire dégradé plutôt qu’une panne dure, le réplica promu pouvait être en retard de plusieurs secondes. Toute écriture acceptée dans ces dernières secondes est perdue.

aws cloudwatch get-metric-statistics \
  --namespace AWS/ElastiCache \
  --metric-name ReplicationLag \
  --dimensions Name=CacheClusterId,Value=saas-prod-002 \
  --start-time $(date -u -v-1h +%Y-%m-%dT%H:%M:%S) \
  --end-time   $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 60 \
  --statistics Maximum \
  --query 'Datapoints[?Maximum > `1.0`]' \
  --output text

Le décalage de réplication devrait normalement se mesurer en millisecondes (sous 1 seconde). Un décalage soutenu de plusieurs secondes pointe vers un débit d’écriture saturant la réplication ou une contrainte réseau entre AZ. Le décalage compte le plus au moment du failover.

Pour les tests planifiés, ElastiCache expose une API TestFailover. C’est ce qu’on utilise pour exercer le chemin de failover en préproduction ou pour valider que les clients de production gèrent.

aws elasticache test-failover \
  --replication-group-id saas-prod \
  --node-group-id 0001

L’appel est limité en fréquence — vous pouvez le déclencher une fois par groupe de nœuds toutes les cinq minutes, et seulement cinq fois par groupe de nœuds par 24 heures. L’appel retourne immédiatement; le failover réel prend les 5–15 secondes habituelles. Observer les taux d’erreur pendant l’appel donne une mesure réelle du comportement des clients, pas une simulation.

La correction

Quand le failover automatique a fait sa job mais que les clients n’ont pas rattrapé en douceur, la correction est côté client, pas côté cluster.

Réglez le respect du TTL DNS court côté client. Les applications Java avec le cache DNS JVM par défaut de « pour toujours » ne verront pas le nouveau primaire. Mettez networkaddress.cache.ttl à 30 ou 60 secondes dans java.security, ou comme drapeau JVM :

-Dsun.net.inetaddr.ttl=30

Les clients Node et Python respectent généralement le résolveur DNS de l’OS, qui respecte le TTL de l’enregistrement. Mais les connexions à longue durée établies avant l’expiration du TTL ne bougent pas tant que la connexion ne tombe pas. Forcez la chute avec la stratégie de réessai du client.

Configurez le réessai client avec la gestion READONLY. Le patron de l’article sur le magasin de sessions s’applique ici : reconnectOnError d’ioredis retournant true sur READONLY fait que le client lâche et se reconnecte. phpredis bénéficie d’une vérification ping dans le chemin de réinitialisation du pool. lettuce (Java) gère cela nativement via ClusterTopologyRefreshOptions.

Lâchez les connexions agressivement sur l’oisiveté. Les connexions TCP à longue durée survivent au failover seulement si l’OS détecte le distant mort et envoie FIN/RST. Le keepalive TCP sur un intervalle de 60 secondes fait que cela arrive dans environ 60 secondes. Sans keepalive, une connexion morte peut persister pendant des heures du point de vue de l’OS.

new Redis({
  // ... autres options
  family: 4,
  keepAlive: 60000,
});

Quand le failover automatique ne se déclenche pas mais que le cluster est dégradé, la réponse est manuelle.

Invoquez manuellement le failover avec TestFailover. C’est la même API utilisée pour les tests planifiés. Si le primaire répond à PING mais se comporte mal (tempête d’éviction, latence élevée, mémoire épuisée avec noeviction), l’appel promeut le réplica plus sain.

Vérifiez que Multi-AZ est réellement activé. Un nombre surprenant de tickets « le failover automatique n’a pas eu lieu » se résolvent en « le failover automatique était désactivé dans la configuration du cluster ». Les clusters mono-AZ ne basculent pas automatiquement. Les clusters de production devraient toujours avoir Multi-AZ activé avec failover automatique en marche.

aws elasticache describe-replication-groups \
  --replication-group-id saas-prod \
  --query 'ReplicationGroups[].[ReplicationGroupId,AutomaticFailover,MultiAZ]' \
  --output table

AutomaticFailover et MultiAZ devraient tous deux indiquer enabled.

Le cadre à retenir : un failover n’est pas une « chose qui arrive instantanément ». C’est une transition d’état de 5–15 secondes durant laquelle les clients doivent coopérer. La job du cluster est de détecter, promouvoir et mettre à jour le DNS. La job du client est de lâcher les connexions mortes, réessayer sur READONLY et respecter le TTL DNS court. La plupart des tickets « ElastiCache a eu une panne » sont en réalité des tickets « le client n’a pas géré un failover de 10 secondes en douceur ». Corrigez le comportement du client, et le temps de récupération naturel du cluster devient la réalité opérationnelle.

Stack Harbor conçoit les topologies Redis dans le cadre du travail sur le palier cluster en Gestion AWS et de la couche Clusters HA. Si une dégradation du primaire n’a jamais déclenché de failover et que votre équipe a dû intervenir, commencez par une consultation d’infrastructure.