Comment travailler en mode Cluster avec Amazon ElastiCache for Redis

Un de nos aspects préférés d’AWS est le grand nombre de blocs de construction disponibles pour traiter un large éventail de cas d’utilisation technique. Amazon ElastiCache pour Redis est l’un de ces blocs de construction. Bien que le plus souvent pensé pour les besoins de mise en cache rapide des bases de données, ElastiCache est assez flexible et rapide (microsecondes). Par le passé, nous avons discuté de la façon d’effectuer des requêtes géospatiales et de créer un tableau de bord en temps réel (article en anglais) avec ElastiCache.

Dans cet article, nous décrivons comment vous pouvez tirer parti d’ElastiCache pour Redis avec le mode cluster activé pour améliorer la fiabilité et la disponibilité avec peu de changement à vos applications existantes. Le principal avantage du mode Cluster est la mise à l’échelle horizontale de votre cluster Redis, avec un impact presque nul sur les performances du cluster, comme nous le montrerons plus tard. Si vous avez déjà rencontré un cluster Redis qui est sur ou sous-provisionné ou que vous voulez simplement mieux comprendre son fonctionnement interne, la suite de cet article est faite pour vous.

Avant de nous plonger dans les détails, examinons brièvement les options de configuration lors du lancement d’un cluster ElastiCache pour Redis. Comme indiqué dans le diagramme suivant, vous avez la possibilité d’utiliser l’une des trois configurations de cluster : (1) nœud unique, (2) mode cluster désactivé et (3) mode cluster activé. Quel que soit le mode, tous les nœuds d’un cluster donné seront du même type de nœud (en termes d’instance EC2 sous-jacente) et de configuration.

Les trois modes diffèrent principalement par la fiabilité, la disponibilité et le comportement de mise à l’échelle. Pour une application de production, envisagez d’utiliser une configuration qui inclut la réplication pour améliorer la protection de vos données. À l’exception du nœud principal, si un nœud rencontre un souci pour une raison ou une autre, vous ne perdrez pas de données car elles ont été répliquées sur d’autres nœuds. Si le nœud principal échoue, vous risquez de perdre certaines données en raison de la latence de réplication. Le tableau suivant passe en revue les principales différences entre les configurations ElastiCache pour Redis :

Utilisation du mode Cluster

Comme indiqué ci-dessus, lors de la création d’environnements de production, vous devez envisager d’utiliser une configuration avec réplication, sauf si vous pouvez facilement recréer vos données. L’activation du mode Cluster offre un certain nombre d’avantages supplémentaires pour la mise à l’échelle de votre cluster. En bref, il vous permet de mettre à l’échelle le nombre de partitions (mise à l’échelle horizontale) au lieu de faire varier le type de nœud (mise à l’échelle verticale). Cela signifie que le mode Cluster peut évoluer vers de très grandes quantités de stockage (potentiellement des centaines de téraoctets) sur 90 partitions, alors qu’un seul nœud ne peut stocker en mémoire que la capacité du type d’instance utilisée.

Le mode Cluster permet également une plus grande flexibilité lors de la conception d’applications avec des besoins de stockage inconnus ou une activité d’écriture intense. Pour des applications avec une forte activité en lecture, nous pouvons mettre à l’échelle une seule partition en ajoutant des réplicas en lecture, jusqu’à cinq, alors qu’une application ayant une forte activité en écriture pourra bénéficier de points de terminaison d’écriture supplémentaires lorsque le mode cluster est activé. [source]

ElastiCache pour Redis avec le mode Cluster activé fonctionne en répartissant l’espace clé de cache sur plusieurs partitions. Cela signifie que vos données et vos accès en lecture/écriture à ces données sont répartis sur plusieurs nœuds Redis. En répartissant la charge sur un plus grand nombre de nœuds, nous pouvons à la fois améliorer la disponibilité et réduire les goulots d’étranglement pendant les pics d’activité, tout en fournissant plus d’espace mémoire qu’un seul nœud ne pourrait offrir. Comme nous le verrons prochainement, les clients Redis qui prennent en charge la mise en cluster vous permettent de spécifier un seul point de terminaison, puis de faire la correspondance interne des noeuds du cluster de manière transparente.

Partitionnement (sharding) des données

Redis exploite un partitionnement dans lequel chaque clé de cache correspond à un hash slot. Au sein du cluster, il y a 16 384 emplacements de hachage disponibles. Ces emplacements sont répartis entre le nombre total de fragments dans le cluster. Par défaut, ElastiCache distribue également les emplacements entre les partitions, mais vous pouvez également personnaliser le schéma de distribution si nécessaire.

Lors de l’écriture ou de la lecture de données sur le cluster, le client calculera quel emplacement de hachage utiliser via un algorithme simple : CRC16 (key) mod 16384. Dans le cas d’ElastiCache pour Redis, le client détermine lui-même quelle partition utiliser en fonction de l’espace clé. En poussant plus de travail au client, nous atténuons les points de défaillance uniques potentiels en permettant au client d’atteindre n’importe quel fragment dans le cluster. Comme nous le verrons prochainement, lors de la connexion initiale au cluster Redis, le client va résoudre et gérer la correspondance de l’espace de clés qui peut être utilisé pour identifier sur quel nœud une clé de hachage particulière peut être trouvée.

Le diagramme suivant montre comment l’espace clé Redis est réparti sur le nombre souhaité de fragments et comment une application cliente détermine sur quelle partition les données doivent être stockées. Dans la section suivante, nous allons explorer comment configurer le mode Cluster sur ElastiCache.

Lancement d’un cluster ElastiCache pour Redis

ElastiCache vous permet de lancer rapidement et facilement un nouveau cluster Redis à l’aide de la console AWS, CLI ou SDK. Ici, nous allons lancer un nouveau cluster, en activant le mode cluster, à l’aide de la console AWS :

Ouvrez la console AWS dans votre navigateur favori et accédez à ElastiCache. Cliquez sur le bouton bleu « Créer » au milieu de la page. Pour ce cluster, nous allons sélectionner le moteur Redis et activer le mode Cluster.

Ensuite, indiquez un nom et une description à votre cluster. Vous pouvez également sélectionner une version de moteur, mais nous vous recommandons généralement d’utiliser la dernière version disponible du moteur Redis. Nous pouvons également spécifier le nombre de fragments et de réplicas par partition. Notre cluster sera composé du nombre de fragments spécifié (encore une fois, jusqu’à 90), chacun avec le nombre spécifié de réplicas. Ici, trois fragments, chacun avec deux réplicas, conduit à un total de neuf nœuds dans notre cluster (trois réplicas primaires + deux réplicas de chaque).

ElastiCache propose une variété de types d’instance de cache à choisir, en fonction de vos besoins en matière de stockage et de performance. Le choix de différents types de nœuds vous permet de mettre à l’échelle verticale la capacité des nœuds dans chaque partition ainsi que la capacité globale du cluster. En utilisant le mode cluster par opposition à la mise à l’échelle d’un seul nœud, nous réduisons le nombre d’interruptions dues à la mise à l’échelle et pouvons mieux répondre à l’évolution des besoins de notre application, ce qui pourrait réduire les coûts. Tous les nœuds de votre cluster seront composés du même type de nœud.

Sous Paramètres Redis avancés, nous pouvons contrôler la distribution de l’espace de clé dans notre cluster. Par défaut, ElastiCache distribuera équitablement les clés entre les partitions, bien que vous puissiez spécifier une distribution personnalisée si vous le souhaitez. Une distribution personnalisée peut s’avérer utile si vous prévoyez un petit nombre de paires clé-valeur dans votre cluster soit relativement plus grandes que d’autre. En personnalisant la distribution, nous pourrions pousser un ou plusieurs de ces objets plus important sur une partition dédiée à son propre espace de clés.

Après avoir configuré la mise en réseau, la sauvegarde et la sécurité de votre cluster, cliquez sur Créer au bas de la page pour commencer la création du nouveau cluster. Le cluster sera disponible dans quelques minutes :

Connexion à votre cluster

Une fois que votre cluster est « available » (disponible), il est prêt à l’emploi. Vous pouvez vous connecter au cluster à l’aide du point de terminaison (endpoint) de configuration répertorié dans la console AWS. Par exemple, nous pouvons utiliser l’interface de ligne de commande Redis pour nous connecter au cluster et demander des informations sur l’espace de clé/les emplacements dans le cluster depuis une instance utilisant le même VPC :

$ redis-cli -c -h mycluster.cache.amazonaws.com -p 6379
 
mycluster:6379> CLUSTER SLOTS
1) 1) (integer) 0
   2) (integer) 5461
   3) 1) "172.31.26.164"
      2) (integer) 6379
      3) "bb550a5c91a35d88caa9e636bffa1830093d4895"
   4) 1) "172.31.49.34"
      2) (integer) 6379
      3) "0200ff55ccc7e5cb6b4387443ebdb9652af23504"
   5) 1) "172.31.8.200"
      2) (integer) 6379
      3) "31646876f16baaab749043c406e06d0553287655"
2) ...
3) ...
 
mycluster:6379> CLUSTER KEYSLOT foo
(integer) 12182

D’après la réponse ci-dessus, nous savons que les clés avec des emplacements de hachage allant de 0 à 5461 sont stockées sur un nœud Redis disponible à l’adresse IP 172.31.26.164 (les entrées suivantes sont le port et l’identifiant unique pour ce nœud). Les répliques de ce nœud se trouvent aux adresses IP 172.31.49.34 et 172.31.8.200. Des données similaires sont renvoyées pour les deux autres partitions de notre cluster. Nous pouvons également trouver les plages de slots dans la console AWS :

Bien que vous n’ayez généralement pas besoin de travailler directement avec ces informations, elles fournissent des informations essentielles au client Redis : une correspondance entre les emplacements de hachage et les nœuds. Comme l’interface de ligne de commande Redis, tout SDK Redis que vous utilisez devra prendre en charge le clustering. Tous les SDK ne prennent pas en charge le clustering, bien que l’équipe Amazon ElastiCache s’efforce d’étendre cette prise en charge. En particulier, un SDK doit implémenter deux fonctionnalités : (1) la prise en charge de l’algorithme de hachage de clé et (2) être capable de maintenir la correspondance slot vers nœud. Aujourd’hui, vous pouvez trouver le support pour le clustering en Java, Ruby, Go, Python, et  d’autres langages de programmation.

En Python, la connexion à ElastiCache pour Redis en mode Cluster est simple :

pip install redis-py-cluster
>>> import rediscluster
>>> startup_nodes = [{ "host": "mycluster.cache.amazonaws.com", "port": "6379" }]
>>> client = rediscluster.RedisCluster(startup_nodes=[dict(host="MYHOST", port=6379)], decode_responses=True, skip_full_coverage_check=True)
 
# Retrieve the slot mapping (equivalent of "CLUSTER SLOTS")
>>> client.cluster('slots')
# Calculate hash slot for the key 'foo'
>>> client.cluster('keyslot', 'foo')
12182
# We can set a key without regard for which shard it will be stored on
# as the Redis client SDK will manage this mapping for us.
>>> client.set('foo', 'bar')
True
>>> client.get('foo')
'bar'

Mise à l’échelle du cluster

À mesure que votre application grandit ou gagne en popularité, vous devrez peut-être augmenter la capacité de votre cluster ElastiCache. Le mode Cluster vous permet d’évoluer horizontalement en ajoutant ou en supprimant des partitions plutôt que de mettre à l’échelle verticale un seul nœud. Cette approche améliore la disponibilité de votre cluster car un redémarrage n’est pas nécessaire, bien que vous puissiez constater un certain impact sur les performances au cours du processus (une augmentation de la consommation de CPU dépendant du nombre de clés, le temps de la redistribution de celles-ci).

Conceptuellement, la mise à l’échelle horizontale du cluster est facile à comprendre du côté serveur : une partition est simplement ajoutée ou supprimée. Une fois le nouveau nœud prêt, le cluster devra réaffecter ou équilibrer l’espace de clés entre les nœuds tels que configurés. Lorsque vous utilisez ElastiCache pour Redis, le rééquilibrage est automatique.

Comme indiqué précédemment, le client est responsable de maintenir sa propre correspondance de l’espace de clés au nœud. La façon dont les clients traitent le rééquilibrage est quelque peu différente en ce sens qu’il n’y a aucune notification indiquant que la correspondance des clés a changé. Au lieu de cela, lors de l’opération suivante effectuée par le client, le cluster lui notifiera que la clé a été déplacée :

$ redis-cli -c -h mycluster.cache.amazonaws.com -p 6379
 
mycluster:6379> GET foo
-MOVED 12182 172.31.8.18:6379

Bien que l’opération elle-même soit un processus en deux étapes dans ce cas et peut entraîner une latence supplémentaire pour terminer l’ensemble de l’opération, le client est maintenant conscient de la correspondance de clé mise à jour. À l’avenir, le client peut fonctionner comme il l’a fait précédemment, en utilisant désormais pleinement les partitions disponibles dans le cluster.

Exécution de test : mise à l’échelle du cluster, avant et après

ElastiCache publie un certain nombre de mesures sur Amazon CloudWatch qui peuvent vous aider à surveiller l’utilisation de votre cluster. Parmi ceux-ci, vous en trouverez qui offrent une bonne idée des performances d’ElastiCache et, avec une compréhension de votre application, peuvent être utiles pour déterminer à quel moment le cluster devrait bénéficier d’une mise à l’échelle.

Pour démontrer la mise à l’échelle dans la pratique, nous avons créé le protocole de test simple illustré dans le diagramme ci-dessous. Le protocole de test inclut un nouveau cluster ElastiCache pour Redis avec le mode Cluster activé. Le nouveau cluster commencera avec une partition et un type de nœud de type cache.r5.large. Nous utiliserons une fonction AWS Lambda pour lire et écrire des données dans le cluster. La fonction capture les temps de réponse pour ces opérations et écrira les résultats sur Amazon CloudWatch. Un outil de test de charge populaire, Artillery, exécuté dans une tâche AWS Fargate sera utilisé pour générer du trafic vers un application load balancer invoquant la fonction. Notez que chaque appel de fonction ouvre une nouvelle connexion à ElastiCache dans ce test ; la meilleure pratique Lambda consiste à réutiliser cette connexion lorsque l’environnement d’exécution est réutilisé dans toutes les invocations.

Notre protocole de test nous permet de simuler la charge sur un site Web qui, par exemple, stocke des données de session dans ElastiCache. En utilisant Artillery, nous allons exécuter plusieurs scénarios qui génèrent différents niveaux de charge, d’écriture et de lecture des données de session à partir d’ElastiCache. À mesure que notre site Web devient très populaire (du moins en simulation), nous pouvons constater que nous devons faire évoluer le cluster pour améliorer ses performances.

Les résultats d’une telle simulation sont affichés dans le tableau de bord Amazon CloudWatch ci-dessus. Après une quinzaine de minutes, avec l’utilisation grimpante (bien que le cluster ne présentait pas de problématiques de performance), nous avons ajouté une nouvelle partition à notre cluster, tout en continuant à enregistrer des mesures de latence. Après la création de la nouvelle partition, ElastiCache a automatiquement rééquilibré l’espace de clé entre les deux partitions, affichant la progression dans la console AWS

… jusqu’à ce que le rééquilibrage soit terminé :

Comme indiqué ci-dessus, nous avons capturé le temps de réponse pour les lectures et les écritures dans ElastiCache dans une fonction Lambda qui a ensuite écrit ces données dans CloudWatch Logs. À l’aide de CloudWatch Logs Insights, nous avons regroupé les données par incréments de 30 secondes, puis calculé les percentiles pour comprendre la latence de ces opérations.

Les percentiles sont plus utiles que les moyennes pour évaluer des mesures telles que la latence, car il peut y avoir une ou deux valeurs aberrantes qui modifient une moyenne ou une large distribution des données. Dans les graphiques ci-dessous, nous incluons p50, p90 et p95. Ces mesures signifient, par exemple, que 95 % des demandes dans une période donnée ont été traitées en moins de temps que la mesure indiquée (p. ex., dans les 30 secondes commençant à 10:06, 95 % des lectures ont été renvoyées de Redis à la fonction Lambda en 1,2 ms ou moins, y compris la latence réseau).

Il est important de noter la cohérence générale entre les mesures p90 et p95 pour les lectures (sous 2ms) et les écritures (sous 6ms). ElastiCache est non seulement rapide mais il est également constant dans sa gestion des opérations de lecture et d’écriture. Comme indiqué précédemment, cette simulation a été exécutée en utilisant le type de nœud cache.m5.large, les résultats peuvent varier selon les types de noeuds. Si vous êtes intéressé à exécuter la simulation vous-même, vous pouvez trouver le code source sur Github.

Conclusion

Amazon ElastiCache pour Redis facilite le déploiement et l’exécution de cette base de données populaire. En activant le mode cluster, vous pouvez facilement mettre à l’échelle la capacité de votre cache à la hausse ou à la baisse sans affecter la disponibilité du cluster ni ne vous soucier de dépasser la capacité maximale d’un seul nœud.

Comme nous l’avons mentionné précédemment, ElastiCache pour Redis pousse la gestion de la correspondance de l’espace des clés au client. Cette approche réduit les points de défaillance uniques potentiels tout en permettant au serveur de se concentrer sur la réalisation d’un débit élevé avec une latence minimale. Toute complexité supplémentaire de la gestion de l’espace de clés est généralement absorbée par le client et l’équipe AWS travaille activement à élargir les kits SDK clients compatibles.

ElastiCache peut être utile dans une variété de cas d’utilisation au-delà de la mise en cache de base. Avec le mode Cluster, vous pouvez faire évoluer Redis à des centaines de TB de capacité et à des niveaux d’écriture élevés. Nous sommes impatients de voir comment vous tirez parti de cette capacité. N’hésitez pas à nous contacter sur le forum AWS ElastiCache pour nous faire part de vos commentaires.

Article original contribué par Josh Kahn, Solutions Architect et adapté en français par Maxime Thomas, Architecte de Solutions dans l’équipe AWS France.