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.
Politiques de dimensionnement Suivi de la cible
Grâce aux politiques de suivi des objectifs et d’échelonnement, vous sélectionnez une métrique et définissez une valeur cible. ElastiCache with Valkey ou Redis OSS Auto Scaling crée et gère les CloudWatch alarmes qui déclenchent la politique de dimensionnement et calcule l'ajustement de mise à l'échelle en fonction de la métrique et de la valeur cible. La politique de mise à l'échelle ajoute ou supprime des partitions si nécessaire pour maintenir la métrique à la valeur cible spécifiée ou proche de celle-ci. En plus de maintenir la métrique proche de la valeur cible, une politique de dimensionnement Suivi de la cible s'ajuste également aux fluctuations de la métrique dues à un modèle de charge fluctuant, et minimise les fluctuations rapides dans la capacité du parc.
Par exemple, examinons une politique de mise à l'échelle qui utilise la métrique prédéfinie d'utilisation moyenne de ElastiCachePrimaryEngineCPUUtilization avec une valeur cible configurée. Une telle politique permet de maintenir CPU l'utilisation à la valeur cible spécifiée ou à un niveau proche de celle-ci.
Métriques prédéfinies
Une métrique prédéfinie est une structure qui fait référence à un nom, à une dimension et à une statistique (average) spécifiques d'une CloudWatch métrique donnée. Votre politique Auto Scaling définit les métriques prédéfinies suivantes pour votre cluster :
| Nom de la métrique prédéfinie | CloudWatch Nom de la métrique | CloudWatch Dimension métrique | Types d'instances non éligibles |
|---|---|---|---|
ElastiCachePrimaryEngineCPUUtilization |
|
ReplicationGroupId, Rôle = Principal |
Aucun |
ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage |
|
Métriques du groupe de OSS réplication Valkey ou Redis |
Aucun |
ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage |
|
Métriques du groupe de OSS réplication Valkey ou Redis |
R6gd |
Les types d'instances à niveaux de données ne peuvent pas être utilisésElastiCacheDatabaseMemoryUsageCountedForEvictPercentage, car ils stockent des données à la fois en mémoire et. SSD Le scénario d'utilisation attendu pour les instances à niveaux de données est d'utiliser 100 % de la mémoire et de se remplir selon SSD les besoins.
Critères de Auto Scaling pour les partitions
Lorsque le service détecte que votre métrique prédéfinie est égale ou supérieure au paramètre Cible, il augmente automatiquement la capacité de vos partitions. ElastiCache avec Valkey ou Redis, OSS redimensionne les partitions de votre cluster d'un nombre égal à la plus grande des deux valeurs suivantes : pourcentage de variation par rapport à Target et 20 % des partitions actuelles. Pour la mise à l'échelle, la mise à l'échelle automatique ElastiCache ne sera pas effectuée à moins que la valeur métrique globale ne soit inférieure à 75 % de la cible que vous avez définie.
Pour un exemple de mise à l'échelle, si vous avez 50 partitions et
-
si votre Target atteint 30 %, ElastiCache Valkey ou Redis augmente OSS de 30 %, ce qui se traduit par 65 partitions par cluster.
-
si votre Target atteint 10 %, ElastiCache Valkey ou Redis s'OSSadapte par défaut à un minimum de 20 %, ce qui se traduit par 60 partitions par cluster.
Par exemple, si vous avez sélectionné une valeur cible de 60 %, Valkey ou Redis ne procédera pas ElastiCache à la mise à l'échelle automatique tant que la métrique OSS ne sera pas inférieure ou égale à 45 % (25 % en dessous de la cible de 60 %).
Considérations relatives à Auto Scaling
Gardez les considérations suivantes à l'esprit :
-
Une politique de mise à l'échelle Suivi de la cible suppose qu'elle doit effectuer une montée en charge ; lorsque la métrique spécifiée est au-dessus de la valeur cible. Vous ne pouvez pas utiliser une politique de dimensionnement du suivi des cibles pour effectuer une mise à l'échelle lorsque la métrique spécifiée est inférieure à la valeur cible. ElastiCache avec Valkey ou Redis, OSS redimensionne les partitions d'un écart minimum de 20 % par rapport à la cible des partitions existantes dans le cluster.
-
Une politique de suivi des objectifs et d'échelonnement n'effectue pas de mise à l'échelle lorsque la métrique spécifiée a des données insuffisantes. Elle n'effectue pas de mise à l'échelle horizontale, car elle n'interprète pas des données insuffisantes comme une faible utilisation.
-
Vous pouvez constater des écarts entre la valeur cible et les points de données de métrique réels. Cela est dû au fait qu' ElastiCache avec Valkey ou Redis OSS Auto Scaling agit toujours de manière conservatrice en arrondissant à la hausse ou à la baisse lorsqu'il détermine la capacité à ajouter ou à supprimer. Cela l'empêche d'ajouter une capacité insuffisante ou de retirer trop de capacité.
-
Pour garantir la disponibilité de l'application, le service augmente proportionnellement aux métriques aussi rapidement que possible, mais diminue plus progressivement.
-
Vous pouvez avoir plusieurs politiques de dimensionnement du suivi des cibles pour un OSS cluster ElastiCache avec Valkey ou Redis, à condition que chacune d'elles utilise une métrique différente. L'intention de ElastiCache (RedisOSS) Auto Scaling est de toujours prioriser la disponibilité. Son comportement varie donc selon que les politiques de suivi des cibles sont prêtes à être étendues ou étendues. Il augmentera la taille du service si l'une des politiques Suivi de la cible est prête pour une augmentation de taille, mais la diminuera uniquement si toutes les politiques Suivi de la cible (avec la portion de diminution en charge activée) sont prêtes pour une diminution de taille.
-
Ne modifiez ni ne supprimez les CloudWatch alarmes qui, ElastiCache avec Valkey ou Redis OSS Auto Scaling, gèrent une politique de dimensionnement du suivi des cibles. ElastiCache Auto Scaling supprime automatiquement les alarmes lorsque vous supprimez la politique de dimensionnement.
-
ElastiCache Auto Scaling ne vous empêche pas de modifier manuellement les partitions de cluster. Ces ajustements manuels n'affectent pas les CloudWatch alarmes existantes associées à la politique de dimensionnement, mais peuvent avoir un impact sur les mesures susceptibles de déclencher ces CloudWatch alarmes.
-
Ces CloudWatch alarmes gérées par Auto Scaling sont définies sur la AVG métrique pour toutes les partitions du cluster. Ainsi, avoir des partitions chaudes peut entraîner l'un ou l'autre des scénarios suivants :
-
mise à l'échelle lorsqu'elle n'est pas nécessaire en raison de la charge sur quelques fragments chauds déclenchant une alarme CloudWatch
-
pas de mise à l'échelle lorsque cela est nécessaire en raison de AVG l'agrégation de tous les fragments, ce qui empêche l'alarme de ne pas violer.
-
-
ElastiCache les limites OSS par défaut de Valkey ou Redis sur les nœuds par cluster s'appliquent toujours. Ainsi, lorsque vous optez pour Auto Scaling et si vous prévoyez que le nombre maximal de nœuds dépasse la limite par défaut, demandez une augmentation de limite à AWS Service Limits et choisissez le type de limite Nodes per cluster per instance type (Nœuds par cluster par type d'instance).
-
Assurez-vous que vous disposez de suffisamment d'interfaces réseau élastiques ENIs (Elastic Network Interfaces)VPC, nécessaires lors du scale-out. Pour de plus amples informations, veuillez consulter Interfaces réseau Elastic.
-
Si la capacité disponible n'est pas suffisanteEC2, ElastiCache Auto Scaling ne sera pas redimensionné et sera retardé jusqu'à ce que la capacité soit disponible.
-
ElastiCache (RedisOSS) Auto Scaling pendant le scale-in ne supprimera pas les fragments dont les emplacements ont une taille d'élément supérieure à 256 Mo après la sérialisation.
-
Pendant la réduction de charge, il ne supprimera pas les partitions si la mémoire disponible sur la configuration des partitions résultante est insuffisante.
