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.
Mise à l'échelle automatique des clusters Valkey et Redis OSS
Conditions préalables
ElastiCache La mise à l'échelle automatique est limitée aux éléments suivants :
-
Clusters Valkey ou Redis OSS (mode cluster activé) exécutant Valkey 7.2 et versions ultérieures ou exécutant Redis OSS 6.0
-
Hiérarchisation des données (mode cluster activé) clusters exécutant Valkey 7.2 et versions ultérieures ou exécutant Redis OSS 7.0.7
-
Tailles d'instance : Large, XLarge, 2xLarge
-
Familles de types d'instances : R8g, R7g, R6g, R6gd, R5, M8g, M7g, M6g, M5, C8gn, C7gn
-
La mise à l'échelle automatique n' ElastiCache est pas prise en charge pour les clusters exécutés dans des banques de données globales, des avant-postes 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 permet 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 la mise à l'échelle automatique, vous devez définir et appliquer une politique de dimensionnement qui utilise CloudWatch les mesures et les valeurs cibles que vous attribuez. ElastiCache la mise à l'échelle automatique utilise cette politique pour augmenter ou diminuer le nombre d'instances en réponse aux charges de travail réelles.
Vous pouvez utiliser le Console de gestion AWS 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 Console de gestion AWS. Les métriques personnalisées ne sont pas disponibles pour la sélection à l'aide de la Console de gestion AWS. 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 pour Valkey et Redis OSS prend en charge la mise à l'échelle pour les dimensions suivantes :
-
Partitions — Partitions automatiques add/remove dans le cluster, comme pour le repartitionnement manuel en ligne. Dans ce cas, la mise à l'échelle ElastiCache automatique déclenche la mise à l'échelle en votre nom.
-
Répliques : add/remove répliques automatiques dans le cluster, de la même manière que les opérations de Increase/Decrease réplication manuelles. ElastiCache mise à l'échelle automatique des adds/removes répliques Valkey et Redis OSS de manière uniforme sur tous les fragments du cluster.
ElastiCache pour Valkey et Redis OSS prend en charge les types de politiques de dimensionnement automatique suivants :
-
Politiques de dimensionnement Suivi de la cible— Augmentez ou diminuez le nombre de shards/replicas fois que votre service exécute 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.
-
Mise à l'échelle planifiée pour votre application. — ElastiCache pour Valkey et Redis OSS, la mise à l'échelle automatique peut augmenter ou diminuer le nombre d'exécutions de shards/replicas votre service en fonction de la date et de l'heure.
Les étapes suivantes résument le processus de dimensionnement automatique ElastiCache pour Valkey et Redis OSS, comme indiqué dans le schéma précédent :
-
Vous créez une politique de dimensionnement ElastiCache automatique pour votre groupe de réplication.
-
ElastiCache la mise à l'échelle automatique 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.
-
Si la valeur de métrique configurée dépasse votre objectif d'utilisation (ou tombe en dessous de l'objectif) pendant une durée spécifique, CloudWatch déclenche une alarme qui invoque le dimensionnement automatique pour évaluer votre politique de dimensionnement.
-
ElastiCache auto scaling émet une demande de modification pour ajuster la capacité de votre cluster.
-
ElastiCache traite la demande de modification en augmentant (ou en diminuant) dynamiquement la Shards/Replicas capacité du cluster afin qu'elle se rapproche de votre utilisation cible.
Pour comprendre le fonctionnement d' ElastiCache Auto Scaling, supposons que vous ayez un cluster nomméUsersCluster. En surveillant les CloudWatch métriques pourUsersCluster, vous déterminez le nombre maximum de fragments dont le cluster a besoin lorsque le trafic est à son maximum et le nombre minimum de fragments lorsque le trafic est à son point le plus bas. Vous définissez également une valeur cible pour l'utilisation du processeur pour le UsersCluster cluster. ElastiCache auto scaling utilise son algorithme de suivi des cibles pour s'assurer que les fragments provisionnés UsersCluster sont ajustés selon les besoins afin que l'utilisation reste égale ou proche de la valeur cible.
Note
La mise à l'échelle peut prendre un temps considérable et nécessiter des ressources de cluster supplémentaires pour le rééquilibrage des fragments. ElastiCache Auto Scaling modifie les paramètres des ressources uniquement lorsque la charge de travail réelle reste élevée (ou réduite) pendant une période prolongée de plusieurs minutes. L'algorithme de suivi des cibles à mise à l'échelle automatique cherche à maintenir l'utilisation cible à la valeur que vous avez choisie ou à proximité de celle-ci sur le long terme.
Autorisations IAM requises pour Auto Scaling
ElastiCache pour Valkey et Redis OSS Auto Scaling est rendu possible par une combinaison des API ElastiCache, CloudWatch, et Application Auto Scaling. Les clusters sont créés et mis à jour avec ElastiCache, les alarmes sont créées avec CloudWatch et 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 paramètres ElastiCache Auto Scaling doit disposer des autorisations appropriées pour les services prenant en charge la mise à l'échelle dynamique. Dans cette politique la plus récente, nous avons ajouté la prise en charge de la mise à l'échelle verticale de Memcached, avec l'action. elasticache:ModifyCacheCluster Les utilisateurs IAM doivent disposer des autorisations nécessaires pour utiliser les actions indiquées dans l’exemple de politique suivant :
Service-linked rôle
Le service de dimensionnement automatique ElastiCache pour Valkey et Redis OSS 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é à un service accorde l'autorisation de dimensionnement ElastiCache automatique pour décrire les alarmes relatives à vos politiques, surveiller la capacité actuelle de la flotte et modifier la capacité de la flotte. Le rôle lié à un service est le rôle par défaut pour la mise à l'échelle ElastiCache automatique. Pour plus d'informations, consultez Service-linked les rôles ElastiCache pour la mise à l'échelle automatique de Redis OSS dans le Guide de l'utilisateur de l'application Auto Scaling.
Bonnes pratiques pour Auto Scaling
Avant de vous inscrire à Auto Scaling, nous vous recommandons de procéder comme suit :
-
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) ouElastiCacheReplicaEngineCPUUtilization(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 l'utilisation de politiques multiples par dimension sur le cluster. ElastiCache pour Valkey et Redis OSS Auto Scaling agrandira la cible évolutive si l'une des politiques de suivi des cibles est prête à être étendue, mais ne sera étendue que si toutes les politiques de suivi des cibles (avec la partie évolutive activée) sont prêtes à être intégrées. 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.
-
-
Mesures personnalisées pour le suivi des cibles : soyez prudent lorsque vous utilisez des mesures personnalisées pour le suivi des cibles, car la mise à l'échelle automatique convient le mieux à l'échelle, car elle est out/in proportionnelle à l'évolution des mesures 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.
-
Mise à l'échelle planifiée : si vous constatez que votre charge de travail est déterministe (elle est atteinte high/low à 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 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.
-
Désactiver Scale-In : la mise à l'échelle automatique sur Target Tracking est idéale pour les clusters dont la charge increase/decrease de travail est progressive, car spikes/dip les métriques peuvent déclencher des out/in oscillations d'échelle consécutives. 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.
-
Testez votre application : nous vous recommandons de tester votre application avec vos Min/Max charges de travail estimées afin de déterminer le minimum et le maximum absolus shards/replicas requis pour le cluster tout en créant des politiques de dimensionnement afin d'é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.
-
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.
-
AutoScaling on Target Tracking convient parfaitement aux clusters présentant une répartition uniforme des charges de travail entre les shards/replicas dimensions. Une distribution non uniforme peut conduire à :
-
Mise à l'échelle lorsque cela n'est pas nécessaire en raison de spike/dip la charge de travail sur quelques appareils shards/replicas.
-
Pas de mise à l'échelle lorsque cela est nécessaire en raison de la moyenne globale proche de la cible, même s'il fait chaud shards/replicas.
-
Note
Lors de la mise à l'échelle de votre cluster, les fonctions chargées dans l'un des nœuds existants (sélectionnés au hasard) ElastiCache seront automatiquement répliquées vers 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
Après vous être inscrit à AutoScaling, notez les points suivants :
-
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. -
increasing/decreasing shards/replicas Dépassement manuel de la Min/Max capacité configurée lors de la création de la politique.
-
