Auto Scaling des clusters ElastiCache for Redis - Amazon ElastiCache for Redis

Auto Scaling des clusters ElastiCache for Redis

Prerequisites

ElastiCache for Redis Auto Scaling est limité aux éléments suivants :

  • Cluster Redis (mode cluster activé) exécutant le moteur Redis version 6.0 et ultérieure

  • Familles de types d'instance - R5, R6g, M5, M6g

  • Tailles d'instance : Large, XLarge, 2xLarge

  • Auto Scaling dans ElastiCache for Redis n'est pas prise en charge pour les clusters s'exécutant dans les entrepôts de données globaux, les Outposts ou Local Zones.

  • AWS Auto Scaling pour ElastiCache for Redis n'est pas disponible dans les régions suivantes : Chine (Beijing), Chine (Ningxia), AWS GovCloud (USA-Ouest) et AWS GovCloud (USA Est).

Gestion automatique de la capacité avec ElastiCache for Redis Auto Scaling

La scalabilité automatique ElastiCache for Redis est la possibilité d'augmenter ou de diminuer automatiquement les partitions ou les réplicas souhaitées dans votre service ElastiCache for Redis. ElastiCache for Redis utilise le service Application Auto Scaling pour fournir cette fonctionnalité. Pour en savoir plus, veuillez consulter Application Auto Scaling. Pour utiliser la scalabilité automatique, vous définissez et appliquez une politique de mise à l'échelle qui utilise les métriques CloudWatch et les valeurs cibles que vous attribuez. La scalabilité automatique ElastiCache for Redis utilise la politique pour augmenter ou diminuer le nombre d'instances en réponse aux charges de travail réelles.

Vous pouvez utiliser AWS Management Console pour appliquer une politique de dimensionnement basée sur une métrique prédéfinie. Une métrique predefined metric est définie dans une énumération de telle sorte que vous pouvez la spécifier par son nom dans le code ou l'utiliser dans la AWS Management Console. Les métriques personnalisées ne sont pas disponibles pour la sélection à l'aide de la AWS Management Console. Vous pouvez également utiliser la AWS CLI ou l'API Auto Scaling de l'application pour appliquer une politique de mise à l'échelle basée sur une métrique personnalisée ou prédéfinie.

ElastiCache for Redis prend en charge la mise à l'échelle pour les dimensions suivantes :

  • Partitions – Ajouter/supprime automatiquement des partitions dans le cluster de manière similaire au repartitionnement manuel en ligne. Dans ce cas, la scalabilité automatique ElastiCache for Redis déclenche la mise à l'échelle en votre nom.

  • Réplicas – Ajouter/supprimez automatiquement des réplicas dans le cluster de manière similaire aux opérations manuelles d'augmentation/diminution des réplicas. La scalabilité automatique ElastiCache for Redis ajoute/supprime uniformément les réplicas sur toutes les partitions du cluster.

ElastiCache for Redis prend en charge les types de politique de scalabilité automatique suivants :

Les étapes suivantes résument le processus de scalabilité automatique ElastiCache for Redis, comme illustré dans le diagramme précédent :

  1. Vous créez une politique de scalabilité automatique ElastiCache for Redis pour votre groupe de réplication ElastiCache for Redis.

  2. La scalabilité automatique ElastiCache for Redis crée une paire d'alarmes CloudWatch en votre nom. Chaque paire représente vos limites supérieure et inférieure pour les métriques. Ces alarmes CloudWatch sont déclenchées lorsque l'utilisation réelle du cluster s'éloigne de votre utilisation cible pendant une période de temps continue. Vous pouvez afficher les alarmes dans la console.

  3. Si la valeur de métrique configurée dépasse votre utilisation cible (ou en deçà de la cible) pendant une durée spécifique, CloudWatch déclenche une alarme qui fait appel à la scalabilité automatique ElastiCache for Redis pour évaluer votre politique de mise à l'échelle.

  4. La scalabilité automatique ElastiCache for Redis émet une requête de modification pour ajuster la capacité de votre cluster.

  5. ElastiCache for Redis traite la requête de modification, en augmentant (ou en réduisant) de manière dynamique la capacité de partitions et réplicas du cluster, de sorte que celle-ci se rapproche de votre utilisation cible.

Pour comprendre la manière dont fonctionne la scalabilité automatique ElastiCache for Redis, supposons que vous ayez un cluster nommé UsersCluster. En surveillant les métriques CloudWatch pour UsersCluster, vous déterminez le nombre Max de partitions dont le cluster a besoin lorsque le trafic est à son pic et le nombre Min de partitions lorsque le trafic est à son point le plus bas. Vous décidez également d'une valeur cible pour l'utilisation du processeur pour le UsersCluster d'un cluster. ElastiCache for Redis Auto Scaling utilise son algorithme de suivi de cible pour s'assurer que les partitions provisionnées de UsersCluster sont ajustées selon les besoins de sorte que l'utilisation reste égale ou proche de la valeur cible.

Note

La mise à l'échelle peut prendre un certain temps et nécessiter des ressources de cluster supplémentaires pour rééquilibrer les partitions. ElastiCache for Redis Auto Scaling modifie les paramètres de débit provisionné uniquement lorsque la charge de travail réelle reste élevée (ou basse) pendant une période continue de plusieurs minutes. L'algorithme de suivi de cible et d’échelonnement ElastiCache for Redis cherche à garder l'utilisation cible au niveau ou proche de la valeur choisie sur le long terme.

Autorisations IAM requises pour ElastiCache for Redis Auto Scaling

ElastiCache for Redis Auto Scaling est rendu possible grâce à une combinaison des API ElastiCache pour Redis, CloudWatch et Application Auto Scaling. Les clusters sont créés et mis à jour avec ElastiCache pour Redis, les alarmes sont créées avec CloudWatch et les politiques de mise à l’échelle sont créées avec Application Auto Scaling. En plus des autorisations IAM standard pour la création et la mise à jour des clusters, l’utilisateur IAM qui accède aux paramètres d’ElastiCache for Redis Auto Scaling doit disposer des autorisations appropriées pour les services qui prennent en charge la mise à l’échelle dynamique. Les utilisateurs IAM doivent disposer des autorisations nécessaires pour utiliser les actions indiquées dans l’exemple de politique suivant :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "application-autoscaling:*", "elasticache:DescribeReplicationGroups", "elasticache:ModifyReplicationGroupShardConfiguration", "elasticache:IncreaseReplicaCount", "elasticache:DecreaseReplicaCount", "elasticache:DescribeCacheClusters", "elasticache:DescribeCacheParameters", "cloudwatch:DeleteAlarms", "cloudwatch:DescribeAlarmHistory", "cloudwatch:DescribeAlarms", "cloudwatch:DescribeAlarmsForMetric", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics", "cloudwatch:PutMetricAlarm", "cloudwatch:DisableAlarmActions", "cloudwatch:EnableAlarmActions", "iam:CreateServiceLinkedRole", "sns:CreateTopic", "sns:Subscribe", "sns:Get*", "sns:List*" ], "Resource": "arn:aws:iam::123456789012:role/autoscaling-roles-for-cluster" } ] }

Rôle lié à un service

Le service de scalabilité automatique ElastiCache for Redis nécessite également l'autorisation de décrire vos clusters et alarmes CloudWatch, ainsi que des autorisations lui permettant de modifier votre capacité cible en votre nom. Si vous activez Auto Scaling pour votre cluster ElastiCache for Redis, il crée un rôle lié à un service nommé AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG. Ce rôle lié au service accorde à ElastiCache for Redis Auto Scaling la permission de décrire les alarmes pour vos politiques, de contrôler la capacité actuelle de la flotte et de modifier la capacité de la flotte. Le rôle lié à un service est le rôle par défaut pour ElastiCache for Redis Auto Scaling. Pour plus d'informations, veuillez consulter Rôles liés aux services de scalabilité automatique ElastiCache for Redis dans le Guide de l'utilisateur Application Auto Scaling.

Bonnes pratiques pour Auto Scaling

Avant de vous inscrire à Auto Scaling, nous vous recommandons de procéder comme suit :

  1. Utilisez une seule métrique de suivi – Identifiez si votre cluster a des charges de travail gourmandes en CPU ou en mémoire et utilisez la mesure prédéfinie correspondante pour définir la politique de mise à l'échelle. Nous vous recommandons d'éviter d'avoir plusieurs politiques par dimension sur le cluster, car ElastiCache for Redis Auto Scaling augmentera la cible extensible si l'une des politiques de suivi de cible est prête à être mise à l'échelle, mais ne la mettra à l'échelle que si toutes les politiques de suivi de la cible (avec la partie mise à l'échelle activée) sont prêtes à être mises à l'échelle. Si plusieurs politiques indiquent simultanément à la cible évolutive de procéder à une montée en puissance ou à une diminution de charge, elle effectue la mise à l'échelle en fonction de la politique qui fournit la plus grande capacité à la fois pour la montée et la diminution en charge.

  2. Utilisez une seule dimension – Identifiez si votre cluster a une charge de travail importante en écriture ou en lecture et utilisez la dimension correspondante (partitions/réplicas) pour définir la politique de mise à l'échelle. Le fait d'avoir des politiques sur plusieurs dimensions pour le même cluster peut entraîner des actions de mise à l'échelle par répercussion. Par exemple, si vous créez des politiques de mise à l'échelle sur le processeur du moteur pour les partitions et les réplicas, et si une action de mise à l'échelle est déclenchée sur la dimension de partitions qui ajoute de nouvelles partitions avec leurs réplicas, cette augmentation de nouveaux réplicas peut avoir un impact sur la politique de mise à l'échelle de la dimension du réplica, qui peut déclencher une réduction des réplicas et vice versa. La métrique Avg est utilisée à travers les nœuds du cluster pour les métriques prédéfinies.

  3. Métriques personnalisées pour le suivi de cibles – Soyez prudent lorsque vous utilisez des métriques personnalisées pour le suivi de cibles, car Auto Scaling est mieux adaptée à l'augmentation/diminution proportionnelle aux changements dans les métriques choisies pour la politique. Si de telles métriques qui ne changent pas de manière proportionnelle pour les actions de mise à l'échelle sont utilisées pour la création de politiques, cela peut entraîner des actions d'augmentation et diminution continues pouvant affecter la disponibilité ou le coût.

  4. Mise à l'échelle planifiée – Si vous identifiez que votre charge de travail est déterministe (atteignant les points hauts/bas à un moment précis), nous vous recommandons d'utiliser la mise à l'échelle planifiée et de configurer votre capacité cible en fonction des besoins. Le suivi de cible est le mieux adapté à la charge de travail non déterministe et au cluster pour fonctionner à la métrique cible requise en s'adaptant lorsque vous avez besoin de plus de ressources et lorsque vous en avez besoin.

  5. Désactivation de l'entrée en charge – Auto Scaling sur le suivi de cible est mieux adaptée aux clusters avec une augmentation/diminution progressive de la charge de travail, car les pics/plongées dans les métriques peuvent déclencher des oscillations successives de montée/diminution en charge. Afin d'éviter de telles oscillations, vous pouvez commencer par désactiver la diminution de charge et plus tard, vous pouvez toujours adapter manuellement à vos besoins.

  6. Tester votre application – Nous vous recommandons de tester votre application avec vos charges de travail estimées min et max, afin de déterminer le nombre absolu de partitions/réplicas requis pour le cluster tout en créant des politiques de mise à l'échelle pour éviter les problèmes de disponibilité. Auto Scaling peut être monter en puissance jusqu'au seuil maximum et diminuer en charge jusqu'au seuil minimum configuré pour la cible.

  7. Définissez une valeur cible – Vous pouvez analyser les métriques CloudWatch correspondantes pour l'utilisation du cluster sur une période de quatre semaines afin de déterminer le seuil de valeur cible. Si vous ne savez toujours pas quelle valeur choisir, nous vous recommandons de commencer avec la valeur de métrique prédéfinie minimale prise en charge afin de préférer de monter en puissance pour la disponibilité.

  8. Auto Scaling sur suivi de cible est mieux adapté aux clusters avec une répartition uniforme de la charge de travail entre les dimensions partitions/réplicas. Une distribution non uniforme peut conduire à :

    • Une mise à l'échelle lorsqu'elle n'est pas nécessaire en raison d'une montée/plongée de la charge de travail sur quelques partitions/réplicas chauds.

    • L'absence de mise à l'échelle lorsque cela est nécessaire en raison d'une moyenne globale proche de l'objectif, même si l'on dispose de partitions/réplicas chauds.

Après l'inscription à Auto Scaling, notez les éléments suivants :

  • Il existe des limites sur les configurations Auto Scaling prises en charge. Nous vous recommandons donc de ne pas modifier la configuration d'un groupe de réplication qui s'est inscrit à Auto Scaling. Ci-dessous sont les quelques cas et non limités :

    • Modification manuelle du type d'instance vers des types non pris en charge.

    • Association du groupe de réplication à un entrepôt de données global.

    • Modification du paramètre ReserverMemoryPercent.

    • Augmentation/diminution manuelle des partitions/réplicas au-delà des capacités Min et Max configurées lors de la création de la politique.