Auto Scaling ElastiCache pour les clusters Redis

Prérequis

ElastiCache pour Redis Auto Scaling est limité à ce qui suit :

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

• Clusters (mode cluster activé) avec hiérarchisation des données exécutant le moteur Redis versions 7.0.7 et ultérieures

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

• Familles de types d’instances : R7g, R6g, R6gd, R5, M7g, M6g, M5, C7gn

• Auto Scaling in ElastiCache for Redis n'est pas pris en charge pour les clusters exécutés dans des banques de données mondiales, des Outposts ou des Zones Locales.

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

ElastiCache pour Redis, la mise à l'échelle automatique est la possibilité d'augmenter ou de diminuer automatiquement les partitions ou les répliques souhaités 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 le dimensionnement automatique, vous définissez et appliquez une politique de dimensionnement qui utilise CloudWatch les métriques et les valeurs cibles que vous attribuez. ElastiCache pour Redis auto Scaling utilise la politique pour augmenter ou diminuer le nombre d'instances en réponse aux charges de travail réelles.

Vous pouvez utiliser le 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 l'API Application Auto Scaling AWS CLI ou l'API Application Auto Scaling pour appliquer une politique de dimensionnement basée sur une métrique prédéfinie ou personnalisée.

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, ElastiCache pour Redis, le dimensionnement automatique déclenche le dimensionnement 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. ElastiCache pour Redis Auto Scaling, ajoute/supprime des répliques de manière uniforme sur toutes les partitions du cluster.

ElastiCache for Redis prend en charge les types de politiques de dimensionnement automatique suivants :

• Politiques de dimensionnement Suivi de la cible – Augmente ou réduit le nombre de partitions/réplicas exécutées par votre service en fonction d'une valeur cible pour une métrique spécifique. Cette option est similaire à la façon dont votre thermostat maintient la température de votre domicile. Vous sélectionnez une température et le thermostat se charge du reste.

• Dimensionnement planifié pour le dimensionnement automatique d'Application ElastiCache for Redis : augmentez ou diminuez le nombre de partages/répliques exécutés par votre service en fonction de la date et de l'heure.

Les étapes suivantes résument le processus de mise à l'échelle automatique ElastiCache pour Redis, comme indiqué dans le schéma précédent :

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

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

3. Si la valeur de la métrique configurée dépasse votre objectif d'utilisation (ou tombe en dessous de l'objectif) pendant une période donnée, CloudWatch déclenche une alarme qui déclenche le dimensionnement automatique ElastiCache de Redis afin d'évaluer votre politique de dimensionnement.

4. ElastiCache pour Redis Auto Scaling émet une demande de modification pour ajuster la capacité de votre cluster.

5. ElastiCache for Redis traite la demande de modification en augmentant (ou en diminuant) dynamiquement la capacité des partages/répliques du cluster afin qu'elle se rapproche de votre objectif d'utilisation.

Pour comprendre le fonctionnement ElastiCache de Redis Auto Scaling, supposons que vous ayez un cluster nomméUsersCluster. En surveillant les CloudWatch métriquesUsersCluster, vous déterminez le nombre maximum de partitions dont le cluster a besoin lorsque le trafic est à son maximum et le nombre minimal 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 des cibles pour garantir que les partitions provisionnées UsersCluster sont ajustées selon les besoins afin que l'utilisation reste égale ou proche de la valeur cible.

Note

La mise à l'échelle peut prendre un certain temps et nécessitera des ressources de cluster supplémentaires pour que les partitions puissent être rééquilibrées. ElastiCache for Redis Auto Scaling modifie les paramètres des ressources uniquement lorsque la charge de travail réelle reste élevée (ou abaissée) pendant une période prolongée de plusieurs minutes. L'algorithme de suivi ElastiCache des cibles à mise à l'échelle automatique de Redis vise à maintenir l'utilisation de la cible à la valeur que vous avez choisie ou à un niveau proche de celle-ci sur le long terme.

Autorisations IAM requises ElastiCache pour Redis Auto Scaling

ElastiCache for Redis Auto Scaling est rendu possible par une combinaison des API ElastiCache for Redis et Application Auto Scaling. CloudWatch Les clusters sont créés et mis à jour avec ElastiCache Redis, les alarmes sont créées avec et CloudWatch les politiques de dimensionnement sont créées avec Application Auto Scaling. Outre les autorisations IAM standard pour créer et mettre à jour des clusters, l'utilisateur IAM qui accède aux ElastiCache paramètres de Redis Auto Scaling doit disposer des autorisations appropriées pour les services qui prennent en charge le dimensionnement 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 dimensionnement automatique ElastiCache pour Redis a également besoin d'une autorisation pour décrire vos clusters et vos CloudWatch alarmes, ainsi que d'autorisations pour modifier votre capacité cible ElastiCache pour Redis 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 à Redis Auto Scaling l'autorisation de décrire les alarmes relatives à vos politiques, de surveiller 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 ElastiCache pour Redis auto Scaling. Pour plus d'informations, consultez la section Rôles liés à un service ElastiCache pour Redis Auto Scaling dans le Guide de l'utilisateur d'Application Auto Scaling.

Bonnes pratiques pour Auto Scaling

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

1. Utiliser une seule métrique de suivi : identifiez si votre cluster a des charges de travail gourmandes en processeur ou en données et utilisez une métrique prédéfinie correspondante pour définir la politique de mise à l'échelle.

   • Processeur du moteur : ElastiCachePrimaryEngineCPUUtilization (dimension de la partition) ou ElastiCacheReplicaEngineCPUUtilization (dimension du réplica)

   • Utilisation de la base de données : ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage. Cette politique de mise à l'échelle fonctionne de manière optimale lorsque maxmemory-policy est définie sur noeviction sur le cluster.

   Nous vous recommandons d'éviter d'appliquer plusieurs politiques par dimension sur le cluster. ElastiCache pour Redis Auto, la mise à l'échelle de la cible évolutive sera étendue si des politiques de suivi des cibles sont prêtes à être étendues, mais elle ne sera étendue que si toutes les politiques de suivi des cibles (avec la partie scale-in activée) sont prêtes à être étendues. 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. 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 la fonction Auto Scaling est mieux adaptée à la montée en puissance/la mise à l'échelle horizontale proportionnelle aux changements dans les métriques choisies pour la politique. Si ces métriques ne changent pas de manière proportionnelle pour les actions de mise à l'échelle utilisées pour la création de politiques, cela peut entraîner des actions de montée en puissance et de mise à l'échelle horizontale continues pouvant affecter la disponibilité ou le coût.

   Pour les clusters avec hiérarchisation des données (types d'instances de la famille r6gd), évitez d'utiliser des métriques basées sur la mémoire pour la mise à l'échelle.

3. Scalabilité planifiée : si vous identifiez que votre charge de travail est déterministe (atteint un niveau élevé/bas à un moment spécifique), nous vous recommandons d'utiliser la scalabilité planifiée et de configurer votre capacité cible en fonction des besoins. Le suivi de cible est mieux adapté aux charges de travail non déterministes et au cluster pour fonctionner à la métrique cible requise en augmentant la capacité lorsque vous avez besoin de plus de ressources et en la diminuant lorsque vous en avez besoin de moins.

4. Désactiver la mise à l'échelle horizontale : la scalabilité automatique sur le suivi de cible est mieux adaptée aux clusters avec une augmentation/diminution progressive des charges de travail, car les pics/plongées dans les métriques peuvent déclencher des oscillations successives de la montée en puissance/mise à l'échelle horizontale de capacité. Afin d'éviter de telles oscillations, vous pouvez commencer par désactiver la mise à l'échelle horizontale et, par la suite, vous pouvez toujours adapter manuellement à vos besoins.

5. Tester votre application : nous vous recommandons de tester votre application avec vos charges de travail Min/Max estimées, 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é. La scalabilité automatique peut monter en puissance la capacité jusqu'au seuil Max et mettre à l'échelle horizontale la capacité jusqu'au seuil Min configuré pour la cible.

6. Définition de la valeur cible : vous pouvez analyser les CloudWatch mesures correspondantes relatives à l'utilisation du cluster sur une période de quatre semaines afin de déterminer le seuil de valeur cible. Si vous n'êtes toujours pas sûr de la valeur à choisir, nous vous recommandons de commencer par une valeur de métrique prédéfinie minimale prise en charge.

7. AutoScaling le suivi sur Target convient parfaitement aux clusters dotés d'une répartition uniforme des charges de travail entre les dimensions des partitions/répliques. 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.

Note

Lorsque vous agrandissez votre cluster, les fonctions chargées dans l'un des nœuds existants (sélectionnées au hasard) ElastiCache seront automatiquement répliquées sur le ou les nouveaux nœuds. Si votre cluster est doté des versions 7.0 ou ultérieures de Redis et que votre application utilise Redis Functions (Fonctions Redis), nous vous recommandons de charger toutes vos fonctions sur toutes les partitions avant de procéder à la montée en puissance afin que votre cluster ne se retrouve pas avec des fonctions différentes sur diverses partitions.

Après vous être inscrit auprès de AutoScaling, notez ce qui suit :

• Il existe des limitations sur les configurations de scalabilité automatique prises en charge, nous vous recommandons donc de ne pas modifier la configuration d'un groupe de réplication qui est inscrit pour la scalabilité automatique. Voici quelques exemples :

  • Modifier manuellement le 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 ReservedMemoryPercent.

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