Groupes de réplication Redis ElastiCache et mode cluster

Un groupe de réplication ElastiCache est un regroupement logique composé d’un nœud Redis primaire et de jusqu’à 5 réplicas en lecture. Le nœud primaire gère toutes les opérations d’écriture ; les réplicas reçoivent une réplication asynchrone depuis le primaire et servent le trafic de lecture. Les groupes de réplication permettent deux fonctionnalités essentielles : la mise à l’échelle des lectures (répartition des demandes de lecture entre plusieurs réplicas) et la haute disponibilité avec basculement automatique (promotion d’un réplica au rang de primaire en cas de défaillance du primaire). Tous les nœuds d’un groupe de réplication partagent le même jeu de données.

ElastiCache fournit deux points de terminaison DNS pour un groupe de réplication : le point de terminaison primaire pointe toujours vers le nœud primaire actuel (il est automatiquement mis à jour lors d’un basculement) — utilisez-le pour toutes les opérations d’écriture. Le point de terminaison de lecture répartit la charge des demandes de lecture entre tous les réplicas disponibles — utilisez-le pour les opérations de lecture afin de distribuer la charge. Votre application doit gérer deux pools de connexions : un pour le point de terminaison primaire destiné aux écritures et un pour le point de terminaison de lecture destiné aux lectures. Il s’agit du modèle de connexion recommandé pour les groupes de réplication Redis d’ElastiCache.

Lorsque le nœud primaire tombe en panne (ce qu’ElastiCache détecte en quelques secondes grâce aux vérifications d’état), le basculement automatique sélectionne l’un des réplicas en lecture pour le promouvoir au rang de primaire. Le processus de promotion se déroule comme suit : (1) le réplica sélectionné est promu au rang de primaire, (2) l’enregistrement DNS du point de terminaison primaire est mis à jour pour pointer vers le nouveau primaire (TTL d’environ 1 seconde), (3) l’ancien primaire est remplacé par un nouveau réplica. La durée totale du basculement est généralement comprise entre 30 et 60 secondes. Les applications qui utilisent le DNS du point de terminaison primaire se reconnectent automatiquement une fois la propagation DNS effectuée — aucune adresse IP codée en dur n’est nécessaire.

Pour une résilience maximale, répartissez les réplicas entre plusieurs zones de disponibilité. Lorsque vous activez Multi-AZ sur un groupe de réplication, ElastiCache place automatiquement le primaire et les réplicas dans des AZ différentes. Si une AZ entière devient indisponible, le basculement promeut un réplica situé dans une AZ encore opérationnelle. Vous pouvez également spécifier explicitement les AZ préférées pour chaque nœud lors de la création du groupe de réplication à l’aide de l’option --preferred-cache-cluster-a-zs.

Redis Cluster Mode Enabled (CME) partitionne le jeu de données entre plusieurs groupes de nœuds (partitions), chacun contenant un primaire et jusqu’à 5 réplicas. Il s’agit de la solution de partitionnement horizontal de Redis. Le Cluster Mode vous permet de dépasser la capacité mémoire d’un seul nœud : vous pouvez disposer de jusqu’à 500 groupes de nœuds de 500 GB chacun, ce qui permet à un seul cluster Redis de stocker jusqu’à 500 × 500 GB = 250 TB de données. Le Cluster Mode multiplie également le débit d’écriture, car chaque groupe de nœuds traite indépendamment les écritures correspondant à sa plage de clés.

Le Redis Cluster Mode divise l’espace des clés en 16 384 emplacements de hachage. Chaque groupe de nœuds possède une plage contiguë d’emplacements de hachage. Lorsqu’une clé est écrite, Redis calcule CRC16(key) % 16384 afin de déterminer l’emplacement de hachage et, par conséquent, le groupe de nœuds responsable. Votre application doit utiliser un client Redis compatible avec les clusters (tel que redis-py-cluster ou Jedis en mode cluster) qui connaît la carte des emplacements et achemine chaque commande vers le nœud approprié. Les clients standard renvoient des erreurs de redirection MOVED s’ils envoient une clé vers la mauvaise partition.

Pour l’examen SAA-C03, choisissez le mode sans cluster lorsque : vos données tiennent sur un seul nœud (< ~400 GB après prise en compte de la marge), vous avez besoin d’une configuration primaire/réplica simple ou votre application utilise des opérations complexes sur plusieurs clés (les transactions portant sur plusieurs clés nécessitent que toutes les clés se trouvent dans le même emplacement). Choisissez le mode cluster lorsque : votre jeu de données dépasse la mémoire d’un seul nœud, vous avez besoin d’une mise à l’échelle horizontale du débit d’écriture ou vous prévoyez une croissance future nécessitant un repartitionnement en ligne. Le mode cluster permet d’ajouter des partitions sans interruption de service (repartitionnement en ligne).

ElastiCache Global Datastore étend la réplication Redis à plusieurs Régions AWS. Vous désignez une Région comme cluster principal et ajoutez des clusters secondaires dans d’autres Régions. Les écritures sont dirigées vers le cluster principal ; les clusters secondaires reçoivent une réplication asynchrone, avec un délai généralement inférieur à une seconde. Les clusters secondaires peuvent traiter les lectures locales avec une latence très faible. Global Datastore permet de créer des applications mondiales, dans lesquelles les utilisateurs de différents continents lisent les données depuis la Région la plus proche, ainsi qu’une DR interrégionale, dans laquelle vous pouvez promouvoir un cluster secondaire au rang de cluster principal si la Région principale tombe en panne.

Dans un groupe de réplication Redis sans clustering, les messages de publication/abonnement sont distribués à tous les réplicas : tout abonné connecté à n’importe quel nœud reçoit les messages publiés sur un canal. En revanche, en mode cluster, la publication/abonnement est limitée aux notifications d’espace de clés, et la publication/abonnement fondée sur les canaux ne fonctionne qu’au sein d’un seul fragment, sauf si vous utilisez Redis 7+ avec le partitionnement Pub/Sub (SSUBSCRIBE / SPUBLISH pour une publication/abonnement tenant compte des fragments). Il s’agit d’une limitation importante lors de la conception d’un système de publication/abonnement à grande échelle en mode cluster.

Surveillez la métrique ReplicationLag de CloudWatch sur les réplicas de lecture afin de vérifier qu’ils suivent correctement le nœud principal. Un délai supérieur à quelques secondes indique un goulot d’étranglement sur le réplica (nœud surchargé, problèmes réseau ou volume d’écritures trop important pour être traité par le réplica). Dans les scénarios utilisant Global Datastore, surveillez GlobalDatastoreReplicationLag. Un délai de réplication élevé signifie que les réplicas de lecture peuvent renvoyer des données obsolètes, ce qui est important pour les applications qui exigent une cohérence éventuelle dans des limites strictes.

Vous pouvez effectuer une mise à l’échelle verticale (modifier le type de nœud) ou une mise à l’échelle horizontale (ajouter ou supprimer des réplicas). La modification du type de nœud nécessite un appel modify-replication-group et entraîne un bref basculement lorsqu’elle est appliquée immédiatement : le nœud principal est remplacé par un nouveau nœud du nouveau type. L’ajout de réplicas s’effectue en ligne, sans interruption de service. Pour passer d’un mode sans cluster au mode cluster, vous devez créer un nouveau groupe en mode cluster et effectuer une migration : il n’existe pas de conversion sur place entre les modes cluster et sans cluster.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les groupes de réplication permettent de mettre les lectures à l’échelle grâce aux réplicas et d’assurer une haute disponibilité grâce au basculement automatique, avec des points de terminaison principal et lecteur ; que le mode cluster répartit les données entre jusqu’à 500 groupes de nœuds en utilisant 16 384 emplacements de hachage afin d’effectuer une mise à l’échelle horizontale au-delà de la mémoire d’un seul nœud ; et que Global Datastore réplique les données entre les Régions pour fournir des lectures mondiales à faible latence et une DR interrégionale. Nous allons maintenant étudier les stratégies de mise en cache : le chargement différé et l’écriture directe.