Comment minimiser les interruptions lors de la mise à l’échelle de mon ElastiCache for Redis ?

Dernière mise à jour : 19/07/2022

Je souhaite minimiser les interruptions lors de la mise à l’echelle de mon Amazon ElastiCache for Redis . Comment procéder ?

Solution

Pour minimiser les interruptions, tenez compte des éléments suivants :

  • Pour minimiser les effets de la synchronisation, évitez la mise à l'échelle pendant des charges de travail élevées. Si le cluster est soumis à une charge de travail élevée et que la mise à l'échelle est anormalement longue, réduisez le nombre de demandes entrantes vers Redis afin d’éviter tout échec de la synchronisation. La synchronisation (sauvegarde en arrière-plan, avec ou sans fonction fork) peut se déclencher lors du processus de mise à l'échelle. La synchronisation est une opération de calcul intense qui consomme de la mémoire supplémentaire. Consultez la statistique SaveInProgress dans Amazon CloudWatch afin de savoir quand la synchronisation a eu lieu. Gardez à l’esprit que cette action collecte des données à chaque minute. De ce fait, la statistique peut ne pas capturer la synchronisation, si celle-ci s’est effectuée en moins d'une minute. Pour plus d'informations sur le suivi de la charge de travail, consultez la section Surveillance des meilleures pratiques avec Amazon ElastiCache for Redis à l'aide d'Amazon CloudWatch.
  • Selon le type de mise à l'échelle, une nouvelle jonction de nœud peut survenir. Lors de la mise à l’échelle, un nœud peut être retiré d'un cluster ou une l’adresse IP d’un nœud peut changer. Amazon ElastiCache for Redis offre différents types de points de terminaison pour la connexion au cluster. Le choix du type de point de terminaison de connexion dépend des exigences de l'application. Une meilleure pratique consiste à tester la mise à l'échelle dans un environnement hors production, afin d'identifier les problèmes inattendus causés par une mauvaise configuration côté client lors de la connexion du cluster Redis.
  • Si le client se connecte à un nouveau réplica en cours de synchronisation, l’erreur suivante s’affichera CHARGEMENT : Redis charge le jeu de données en mémoire. Configurez le client ou le code d'application Redis pour relancer la requête sur un autre réplica, ou envoyer une requête au nœud primaire. Le temps nécessaire au chargement du jeu de données est fonction de la taille des données et de la performance du nœud. Effectuez des tests dans votre environnement de tests afin de déterminer si cela posera un problème.
  • Vous pouvez configurer le cluster pour que la mise à l’échelle se fasse automatiquement, au lieu d'effectuer une mise à l'échelle manuelle. La mise à l'échelle automatique permet d’éviter les problèmes de performance causés par des augmentations soudaines de la charge de travail. Pour plus d'informations, consultez la mise à l’échelle automatique ElastiCache pour les clusters Redis.

Aperçu des interruptions des actions de la mise à l’échelle

Il existe quatre actions de mise à l'échelle :

  • La diminution.
  • L’augmentation.
  • La modification des types de nœuds.
  • La modification du nombre de groupes de nœuds. Ceci n'est pris en charge que pour les clusters Redis (mode cluster désactivé).

Pour plus d'informations, consultez Mise à l'échelle des clusters ElastiCache for Redis.

En général, l’interruption de la mise à l’échelle peut durer quelques secondes au maximum, en fonction de l'action de la mise à l’échelle et de la configuration du cluster. Voici quelques explications sur les interruptions, en fonction du type de cluster et de l’action de mise à l'échelle :

Clusters Redis (mode cluster désactivé)

La diminution : la mise à l'échelle supprime un nœud de réplica des clusters. Vous pouvez exécuter cette action afin de réduire les coûts. N'oubliez pas que cette action de mise à l’échelle réduit également la durabilité des données. Si vos applications utilisent exclusivement un point de terminaison primaire pour se connecter au cluster, la suppression des nœuds de réplica n'entraînera aucune interruption. Ceci en raison du fait que le point de terminaison primaire pointe vers le nœud primaire.

Toutefois, si vos applications utilisent des points de terminaison de lecteur ou des points de terminaison individuels pour la connexion à ce nœud de réplica, la connexion d'origine au nœud de réplica supprimé sera interrompue et l'application devra établir une nouvelle connexion TCP avec d'autres nœuds de réplica. L'application devra par ailleurs effectuer une nouvelle recherche DNS afin d’éviter toute connexion au nœud de réplica supprimé. Si le client utilise des points de terminaison de lecture, la propagation DNS des points de terminaison du lecteur peut entraîner un temps d'arrêt de quelques secondes.

L’augmentation : Cette mise à l’échelle ajoute un nœud de réplica dans un cluster existant. Le nœud primaire se synchronise avec les nouveaux nœuds. Afin d’éviter les interruptions au cours de la synchronisation, envisagez d'effectuer une mise à l'échelle à des heures où la charge de travail est minimale.

Modification des types de nœuds : lors de la modification du type de nœud, de nouveaux nœuds du type spécifié sont créés. L'ancien nœud primaire se synchronise avec le nouveau nœud primaire, et le nouveau nœud primaire se synchronise avec les nouveaux nœuds de réplica. Durant cette action de la mise à l'échelle, assurez-vous que :

  • La charge de travail n'est pas si élevée de manière à causer l’échec de la synchronisation.
  • L'adresse IP des nouveaux nœuds peut ne pas être la même que celle des anciens nœuds. Votre application peut nécessiter d'effectuer une nouvelle recherche DNS sur le point de terminaison primaire ou le point de terminaison du lecteur et d'établir de nouvelles connexions au nouveau nœud. La propagation du DNS dure quelques secondes. Une interruption de votre service peut donc survenir avant que le client n'atteigne le nouveau nœud.
    Dans les versions Redis 5.0.5 ou supérieures,l'interruption est réduite au minimum. Le client Redis relancera la demande vers un nouveau nœud si la demande a échoué en raison de l'arrêt de l'ancien nœud. Une meilleure pratique consiste à mettre à niveau vers la nouvelle version de Redis afin de bénéficier des optimisations du service ElastiCache.

Clusters Redis (mode cluster activé)

La diminution : Cette action de mise à l'échelle implique la suppression d'une partition d'un cluster. Avant que la partition ne soit supprimée, les données qu'elle contient sont déplacées vers d'autres nœuds. Ce processus est appelé « repartitionnement ». Le repartitionnement entraîne une charge de travail supplémentaire sur le cluster, et le client doit prendre en charge le cluster Redis. Pour plus d'informations sur la réduction des interruptions lors de la diminution, consultez Meilleures pratiques : redimensionnement de cluster en ligne.

Afin de minimiser les problèmes de performances liés une mise à l'échelle excessive, envisagez une mise à l'échelle progressive. A titre d’exemple, si la cible doit effectuer une mise à l’échelle horizontale de 12 partitions à 6 partitions, passez d'abord de 12 partitions à 9 partitions. Après la mise à l'échelle initiale, vérifiez la performance du cluster pendant les heures de pointe et effectuez ensuite une nouvelle mise à l'échelle.

L’augmentation : cette mise à l'échelle permet d'ajouter une partition à un cluster. Les données des autres partitions sont déplacées vers la nouvelle partition. Ce processus est appelé « repartitionnement ». Le repartitionnement entraîne une charge de travail supplémentaire sur le cluster, et le client doit prendre en charge le cluster Redis. Pour plus d'informations sur la réduction des interruptions lors de l’augmentation, consultez Meilleures pratiques : redimensionnement de cluster en ligne.

Modification des types de nœuds : lors de la « Modification des types de nœuds », pour chaque partition, l'ancien nœud primaire se synchronise avec le nouveau nœud primaire. Ensuite, les nouveaux nœuds primaires se synchronisent avec les nouveaux nœuds de réplica. Durant cette action de la mise à l'échelle, assurez-vous que :

  • La charge de travail n'est pas si élevée de manière à causer l’échec de la synchronisation.
  • L'adresse IP des nouveaux nœuds peut être différente de celle des anciens nœuds. Pour identifier l'adresse IP, votre application peut utiliser la commande des nœuds de cluster ou des emplacements de cluster pour obtenir des informations topologiques à jour du cluster. La plupart des clients Redis qui prennent en charge les clusters Redis sont en mesure de mettre à jour la topologie du cluster. Toutefois, cela nécessitera peut-être que vous configuriez le client Redis. Pour plus d'informations sur la configuration de votre client Redis, consultez la documentation de votre type de client en particulier.

Modification du nombre de groupes de nœuds : la modification du nombre de groupes de nœuds change le nombre de nœuds de réplica dans chaque partition. Lorsque le nombre de nœuds de réplica augmente, de nouveaux nœuds de réplica se joignent au cluster, et le nœud primaire se synchronise avec le nouveau nœud. Vérifiez donc les performances des nœuds primaires avant d'ajouter des nœuds de réplica supplémentaires. Lorsque le nombre de nœuds de réplica diminue, et si le client doit lire à partir d'un nœud de réplica supprimé, le client doit envoyer la demande à l'un des nouveaux nœuds de réplica. Le client doit par ailleurs mettre à jour la topologie du cluster afin d’empêcher l'envoi de nouvelles demandes au nœud supprimé.