Clusters Auto Scaling Valkey et Redis OSS - Amazon ElastiCache

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Clusters Auto Scaling Valkey et Redis OSS

Prérequis

ElastiCache Auto Scaling se limite aux éléments suivants :

  • Clusters Valkey ou Redis OSS (mode cluster activé) exécutant Valkey 7.2 ou version 6.0 du moteur Redis OSS

  • Hiérarchisation des données (mode cluster activé) clusters exécutant Valkey 7.2 ou version ultérieure OSS du moteur Redis 7.0.7

  • Tailles d'instance : grandeXLarge, 2 XLarge

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

  • Auto Scaling in n' ElastiCache 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 Auto Scaling avec Valkey ou Redis OSS

ElastiCache la mise à l'échelle automatique avec Valkey ou Redis OSS est la possibilité d'augmenter ou de diminuer automatiquement le nombre de fragments ou de répliques souhaités dans votre service. ElastiCache ElastiCache 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 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 Application Auto Scaling AWS CLI ou Application Auto Scaling API pour appliquer une politique de dimensionnement basée sur une métrique prédéfinie ou personnalisée.

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

ElastiCache avec Valkey ou Redis, OSS prend en charge les types de politiques de dimensionnement automatique suivants :

Image de mise à l'échelle automatique pour ElastiCache Valkey ou Redis OSS

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

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

  2. ElastiCache le dimensionnement automatique avec Valkey ou Redis OSS 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 mesure 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 pour évaluer votre politique de dimensionnement.

  4. ElastiCache avec Valkey ou Redis OSS Auto Scaling, émet une demande de modification pour ajuster la capacité de votre cluster.

  5. ElastiCache avec Valkey ou Redis, OSS 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 comment ElastiCache fonctionne Valkey ou Redis OSS 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éterminez également une valeur cible CPU d'utilisation pour le UsersCluster cluster. ElastiCache auto scaling utilise son algorithme de suivi des cibles pour s'assurer 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 avec Valkey ou Redis OSS 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 des cibles à mise à l'échelle automatique vise à maintenir l'utilisation de la cible à la valeur que vous avez choisie ou à un niveau proche de celle-ci sur le long terme.

IAMAutorisations requises pour Auto Scaling

ElastiCache avec Valkey ou Redis OSS Auto Scaling est rendu possible par une combinaison de ElastiCache CloudWatch, et Application Auto Scaling. APIs Les clusters sont créés et mis à jour avec ElastiCache (RedisOSS), les alarmes sont créées avec CloudWatch et les politiques de dimensionnement sont créées avec Application Auto Scaling. Outre les IAM autorisations standard pour créer et mettre à jour des clusters, l'IAMutilisateur qui accède aux paramètres d' ElastiCache Auto Scaling doit disposer des autorisations appropriées pour les services qui prennent en charge le dimensionnement dynamique. IAMles utilisateurs doivent être autorisés à 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 OSS automatique ElastiCache with Valkey ou Redis a également besoin d'une autorisation pour décrire vos clusters et vos CloudWatch alarmes, ainsi que d'autorisations pour modifier votre capacité ElastiCache cible en votre nom. Si vous activez Auto Scaling pour votre cluster, il crée un rôle lié à un service nommé. AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG Ce rôle lié au service accorde à ElastiCache Auto Scaling l'autorisation de décrire les alarmes correspondant à vos politiques, de surveiller la capacité actuelle de la flotte et de modifier la capacité de la flotte. Le rôle lié au service est le rôle par défaut pour le dimensionnement ElastiCache automatique. Pour plus d'informations, consultez la section Rôles liés à un service pour ElastiCache (Redis) OSS 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. Utilisez une seule métrique de suivi : déterminez si votre cluster comporte CPU ou non des charges de travail gourmandes en données et utilisez une métrique prédéfinie correspondante pour définir la politique de mise à l'échelle.

    • Moteur CPU : ElastiCachePrimaryEngineCPUUtilization (dimension du fragment) ou ElastiCacheReplicaEngineCPUUtilization (dimension de la réplique)

    • 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 avec Valkey ou Redis OSS 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 utilise Valkey ou Redis OSS 7.0 ou une version ultérieure et que votre application utilise Functions, nous vous recommandons de charger toutes vos fonctions sur toutes les partitions avant de les redimensionner afin que votre cluster ne se retrouve pas avec des fonctions différentes sur différentes 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.