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. # Scalage prédictif pour Application Auto Scaling La mise à l'échelle prédictive fait évoluer votre application de manière proactive. La mise à l'échelle prédictive analyse les données de charge historiques pour détecter les tendances quotidiennes ou hebdomadaires des flux de trafic. Il utilise ces informations pour prévoir les futurs besoins de capacité afin d'augmenter de manière proactive la capacité de votre application pour qu'elle corresponde à la charge prévue. La mise à l'échelle prédictive se prête particulièrement bien aux situations suivantes : + Trafic cyclique, tel qu'une utilisation intensive des ressources pendant les heures de bureau et une faible utilisation le soir et le week-end + Modèles on-and-off de charge de travail récurrents, tels que le traitement par lots, les tests ou l'analyse périodique des données. + Applications dont l'initialisation prend beaucoup de temps, ce qui en termes de performances se traduit par une latence notable lors des événements de montée en puissance **Topics** + [Comment ça marche](aas-predictive-scaling-how-it-works.md) + [Créer une stratégie de mise à l’échelle prédictive](aas-create-predictive-scaling-policy.md) + [Remplacer la prévision](aas-predictive-scaling-overriding-forecast-capacity.md) + [Utilisation de métriques personnalisées](aas-predictive-scaling-customized-metric-specification.md) # Comment fonctionne la mise à l'échelle prédictive d'Application Auto Scaling Pour utiliser la mise à l'échelle prédictive, créez une politique de mise à l'échelle prédictive qui spécifie la CloudWatch métrique à surveiller et à analyser. Vous pouvez utiliser une métrique prédéfinie ou personnalisée. Pour que la mise à l'échelle prédictive commence à prévoir les valeurs futures, cette métrique doit disposer d'au moins 24 heures de données. Une fois que vous avez créé la stratégie, la mise à l’échelle prédictive commence à analyser les données métriques recueillies au cours des 14 derniers jours afin d’identifier des modèles. Il utilise cette analyse pour générer une prévision horaire des besoins de capacité pour les 48 prochaines heures. Les prévisions sont mises à jour toutes les 6 heures en utilisant les dernières CloudWatch données. À mesure que de nouvelles données arrivent, la mise à l'échelle prédictive est en mesure d'améliorer en permanence la précision des prévisions futures. Vous pouvez d'abord activer le dimensionnement prédictif en mode *prévision uniquement*. Dans ce mode, il génère des prévisions de capacité mais n'adapte pas réellement votre capacité en fonction de ces prévisions. Cela vous permet d'évaluer la précision et la pertinence des prévisions. Après avoir examiné les données de prévision et décidé de commencer le dimensionnement en fonction de ces données, passez la politique de dimensionnement en mode prévision et échelle. Dans ce mode : + Si les prévisions prévoient une augmentation de la charge, la mise à l'échelle prédictive augmentera la capacité. + Si les prévisions prévoient une diminution de la charge, la mise à l'échelle prédictive ne sera pas adaptée pour réduire la capacité. Cela garantit que vous n'intervenez que lorsque la demande baisse réellement, et pas uniquement en fonction des prévisions. Pour supprimer la capacité qui n'est plus nécessaire, vous devez créer une politique de suivi des cibles ou de mise à l'échelle des étapes, car elles répondent aux données métriques en temps réel. Par défaut, la mise à l'échelle prédictive redimensionne vos objectifs évolutifs au début de chaque heure en fonction des prévisions pour cette heure. Vous pouvez éventuellement spécifier une heure de début antérieure en utilisant la `SchedulingBufferTime` propriété dans l'opération `PutScalingPolicy` d'API. Cela vous permet de lancer la capacité prévue avant la demande prévue, ce qui donne à la nouvelle capacité le temps nécessaire pour être prête à gérer le trafic. ## Limite de capacité maximale Par défaut, lorsque des politiques de dimensionnement sont définies, elles ne peuvent pas augmenter la capacité au-delà de sa capacité maximale. Vous pouvez également autoriser l'augmentation automatique de la capacité maximale de la cible évolutive si la capacité prévue approche ou dépasse la capacité maximale de la cible évolutive. Pour activer ce comportement, utilisez les `MaxCapacityBuffer` propriétés `MaxCapacityBreachBehavior` et dans le fonctionnement de l'`PutScalingPolicy`API ou le paramètre de **comportement de capacité maximale** dans le AWS Management Console. **Avertissement** Soyez prudent lorsque vous autorisez l'augmentation automatique de la capacité maximale. La capacité maximale ne revient pas automatiquement à la capacité maximale initiale. ## Commandes couramment utilisées pour la création, la gestion et la suppression des politiques de mise à l'échelle Les commandes couramment utilisées pour travailler avec les politiques de dimensionnement prédictif sont les suivantes : + `register-scalable-target`pour enregistrer AWS ou personnaliser des ressources en tant que cibles évolutives, pour suspendre le dimensionnement et pour reprendre le dimensionnement. + `put-scaling-policy`pour créer une politique de dimensionnement prédictive. + `get-predictive-scaling-forecast`pour récupérer les données de prévision pour une politique de dimensionnement prédictive. + `describe-scaling-activities`pour renvoyer des informations sur les activités de dimensionnement dans un Région AWS. + `describe-scaling-policies`pour renvoyer des informations sur les politiques de dimensionnement dans un Région AWS. + `delete-scaling-policy`pour supprimer une politique de dimensionnement. **Métriques personnalisées** Des métriques personnalisées peuvent être utilisées pour prévoir la capacité requise pour une application. Les métriques personnalisées sont utiles lorsque les métriques prédéfinies ne sont pas suffisantes pour capturer la charge de votre application. ## Considérations Les considérations suivantes s'appliquent lors de l'utilisation de la mise à l'échelle prédictive. + Vérifiez si le dimensionnement prédictif est adapté à votre application. Une application convient parfaitement à la mise à l'échelle prédictive si elle présente des modèles de charge récurrents spécifiques au jour de la semaine ou à l'heure de la journée. Évaluez les prévisions avant de laisser le dimensionnement prédictif faire évoluer activement votre application. + La mise à l'échelle prédictive requiert au moins 24 heures de données historiques pour commencer à élaborer des prévisions. Toutefois, les prévisions sont plus efficaces si les données historiques couvrent deux semaines complètes. + Choisissez une métrique de charge qui représente avec précision la charge complète de votre application et qui constitue l’aspect le plus important de votre application à prendre en compte. # Création d'une politique de dimensionnement prédictive pour Application Auto Scaling L'exemple de politique suivant utilise le AWS CLI pour configurer une politique de dimensionnement prédictif pour le service Amazon ECS. Remplacez chaque *user input placeholder* par vos propres informations. Pour plus d'informations sur les CloudWatch métriques que vous pouvez spécifier, consultez le [PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)manuel *Amazon EC2 Auto Scaling API* Reference. Voici un exemple de stratégie avec une configuration mémoire prédéfinie. ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 40, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceMemoryUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` L'exemple suivant illustre la création de la politique en exécutant la [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)commande avec le fichier de configuration spécifié. ``` aws aas put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` Si elle aboutit, cette commande renvoie l’ARN de la stratégie. ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` # Remplacer des valeurs de prévision à l'aide d'actions planifiées Parfois, vous pouvez disposer d'informations supplémentaires sur de futurs besoins de votre application que le calcul prédictif ne peut pas prendre en compte. Par exemple, les calculs prédictifs peuvent sous-estimer la capacité nécessaire pour un événement marketing à venir. Vous pouvez alors utiliser des actions planifiées pour remplacer temporairement la prévision au cours de périodes ultérieures. Les actions planifiées peuvent être exécutées de manière récurrente, ou à une date et une heure spécifiques en cas de fluctuations ponctuelles de la demande. Par exemple, vous pouvez créer une action planifiée avec une capacité minimale plus élevée que ce qui est prédit. Au moment de l'exécution, Application Auto Scaling met à jour la capacité minimale de votre cible évolutive. Étant donné que la mise à l'échelle prédictive optimise la capacité, une action planifiée avec une capacité minimale supérieure aux valeurs prédites est honorée. Cela permet d'éviter que la capacité soit inférieure à celle prévue. Pour cesser de remplacer la prévision, utilisez une deuxième action planifiée afin de rétablir le paramètre d'origine de la capacité minimale. La procédure suivante présente les étapes à suivre pour remplacer la prévision au cours de périodes ultérieures. **Topics** + [ ## Étape 1 : (facultatif) Analyser les données en séries chronologiques ](#analyzing-time-series-data) + [ ## Étape 2 : créer deux actions planifiées ](#scheduling-capacity) **Important** Cette rubrique part du principe que vous essayez de remplacer les prévisions afin d’atteindre une capacité supérieure à celle prévue. Si vous devez réduire temporairement la capacité sans interférer avec une politique de dimensionnement prédictif, utilisez plutôt le mode *prévision uniquement*. En mode prévisions uniquement, la mise à l'échelle prédictive continuera de générer des prévisions, mais elle n'augmentera pas automatiquement la capacité. Vous pouvez ensuite surveiller l'utilisation des ressources et réduire manuellement la taille de votre groupe selon vos besoins. ## Étape 1 : (facultatif) Analyser les données en séries chronologiques Commencez par analyser les données en séries chronologiques de la prévision. Il s'agit d'une étape facultative, mais elle permet de comprendre les détails de la prévision. 1. **Récupérer la prévision** Une fois la prévision créée, vous pouvez interroger une période spécifique au sein de celle-ci. L'objectif de la requête est d'obtenir une vue complète des données en séries chronologiques d'une période spécifique. Votre requête peut inclure jusqu'à deux jours de données de prévision ultérieures. Si vous utilisez la mise à l'échelle prédictive depuis un certain temps, vous pouvez également accéder à vos données de prévision antérieures. Toutefois, la durée maximale entre le début et la fin est de 30 jours. Pour récupérer les prévisions, utilisez la [get-predictive-scaling-forecast](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/application-autoscaling/get-predictive-scaling-forecast.html)commande. L'exemple suivant permet d'obtenir les prévisions de dimensionnement prédictif pour le service Amazon ECS. ``` aws application-autoscaling get-predictive-scaling-forecast --service-namespace ecs \ --scalable-dimension ecs:service:DesiredCount \ --resource-id 1234567890abcdef0 --policy-name predictive-scaling-policy \ --start-time "2021-05-19T17:00:00Z" \ --end-time "2021-05-19T23:00:00Z" ``` La réponse inclut deux prévisions : `LoadForecast` et`CapacityForecast`. `LoadForecast`affiche les prévisions de charge horaire. `CapacityForecast`affiche les valeurs de prévision de la capacité nécessaire sur une base horaire pour gérer la charge prévue tout en maintenant une valeur spécifiée`TargetValue`. 1. **Identifier la période cible** Indiquez l'heure ou les heures où la fluctuation de la demande ponctuelle devrait avoir lieu. N'oubliez pas que les dates et les heures indiquées dans la prévision sont basées sur le fuseau horaire UTC. ## Étape 2 : créer deux actions planifiées Créez ensuite deux actions planifiées pour une période spécifique où votre application devra gérer une charge plus élevée que celle prédite. Par exemple, si vous organisez un événement marketing qui va générer du trafic sur votre site pendant une période limitée, vous pouvez planifier une action ponctuelle pour mettre à jour la capacité minimale au début de cet événement. Puis vous pouvez planifier une autre action pour rétablir le paramètre d'origine de la capacité minimale à la fin de l'événement. **Pour créer deux actions planifiées pour des événements ponctuels (AWS CLI)** Pour créer les actions planifiées, utilisez la [ put-scheduled-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/application-autoscaling/put-scheduled-action.html)commande. L'exemple suivant définit un calendrier pour Amazon EC2 Auto Scaling qui maintient une capacité minimale de trois instances le 19 mai à 17 h 00 pendant huit heures. Les commandes suivantes montrent comment implémenter ce scénario. La première commande [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) demande à Amazon EC2 Auto Scaling de mettre à jour la capacité minimale du groupe Auto Scaling spécifié à 17 h 00 UTC le 19 mai 2021. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \ --auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3 ``` La deuxième commande indique à Amazon EC2 Auto Scaling de définir la capacité minimale du groupe à 1h00 UTC le 20 mai 2021. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \ --auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1 ``` Après l'ajout de ces actions planifiées au groupe Auto Scaling, Amazon EC2 Auto Scaling effectue les opérations suivantes : + À 17h00 UTC le 19 mai 2021, la première action planifiée s'exécute. Si le groupe compte actuellement moins de trois instances, il passe à trois instances. Pendant ce temps et pendant les huit heures suivantes, Amazon EC2 Auto Scaling peut continuer à monter en puissance si la capacité prévue est supérieure à la capacité réelle ou si une stratégie de mise à l'échelle dynamique est en vigueur. + À 1h00 UTC le 20 mai 2021, la seconde action planifiée s'exécute. Cette action rétablit le paramètre d'origine de la capacité minimale à la fin de l'événement. ### Mise à l'échelle basée sur des planifications récurrentes Pour remplacer la prévision applicable à la même période chaque semaine, créez deux actions planifiées et fournissez la logique d'heure et de date à l'aide d'une expression cron. L'expression cron est constituée de cinq champs séparés par des espaces : [Minute] [Heure] [Jour\$1du\$1Mois] [Mois\$1de\$1Année] [Jour\$1de\$1Semaine]. Ces champs peuvent contenir toutes les valeurs autorisées, y compris des caractères spéciaux. Par exemple, l'expression cron suivante exécute l'action tous les mardis à 6h30. L'astérisque est utilisé comme caractère générique pour représenter toutes les valeurs d'un champ. ``` 30 6 * * 2 ``` # Politique de dimensionnement prédictive avancée utilisant des métriques personnalisées Dans une politique de mise à l'échelle prédictive, vous pouvez utiliser des métriques prédéfinies ou personnalisées. Les métriques personnalisées sont utiles lorsque les métriques prédéfinies ne décrivent pas suffisamment la charge de votre application. Lorsque vous créez une politique de dimensionnement prédictif avec des métriques personnalisées, vous pouvez spécifier d'autres CloudWatch métriques fournies par AWS, ou vous pouvez spécifier des métriques que vous définissez et publiez vous-même. Vous pouvez également utiliser les mathématiques des métriques pour agréger et transformer les métriques existantes en une nouvelle série chronologique qui AWS n'est pas automatiquement suivie. Lorsque vous combinez des valeurs dans vos données, par exemple, en calculant de nouvelles sommes ou moyennes, cela s'appelle l'*agrégation*. Les données résultantes sont appelées un *agrégat*. La section suivante contient les bonnes pratiques et des exemples de construction de la structure JSON pour la politique. **Topics** + [ ## Bonnes pratiques ](#custom-metrics-best-practices) + [ ## Conditions préalables ](#custom-metrics-prerequisites) + [ # Construction du fichier JSON pour les métriques personnalisées ](construct-json-custom-metrics.md) + [ # Considérations relatives aux métriques personnalisées dans le cadre d'une politique de dimensionnement prédictive ](custom-metrics-troubleshooting.md) ## Bonnes pratiques Les bonnes pratiques suivantes peuvent vous aider à utiliser plus efficacement les métriques personnalisées : + Pour la spécification de la métrique de charge, la métrique la plus utile est une métrique qui représente la charge sur votre application. + La métrique de mise à l'échelle doit être inversement proportionnelle à la capacité. En d'autres termes, si la cible évolutive augmente, la métrique de mise à l'échelle devrait diminuer à peu près dans la même proportion. Pour que la mise à l'échelle prédictive se comporte comme prévu, la métrique de charge et la métrique de mise à l'échelle doivent également présenter une forte corrélation entre elles. + L'utilisation cible doit correspondre au type de métrique de mise à l'échelle. Pour une configuration de politique qui utilise l'utilisation du CPU, il s'agit d'un pourcentage cible. Pour une configuration de politique qui utilise le débit, tel que le nombre de demandes ou de messages, il s'agit du nombre cible de demandes ou de messages par instance pendant tout intervalle d'une minute. + Si ces recommandations ne sont pas suivies, les valeurs futures prédites des séries temporelles seront probablement incorrectes. Pour vérifier que les données sont correctes, vous pouvez consulter les valeurs prévisionnelles. Sinon, après avoir créé votre politique de dimensionnement prédictif, inspectez les `CapacityForecast` objets `LoadForecast` et renvoyés par un appel à l'[GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html)API. + Nous vous recommandons vivement de configurer la mise à l'échelle prédictive en mode prévision uniquement pour pouvoir évaluer la prévision avant que la mise à l'échelle prédictive ne commence à mettre activement à l'échelle la capacité. ## Conditions préalables Pour ajouter des métriques personnalisées à votre politique de mise à l'échelle, vous devez disposer des autorisations `cloudwatch:GetMetricData`. Pour spécifier vos propres indicateurs au lieu des indicateurs AWS fournis, vous devez d'abord les publier sur CloudWatch. Pour plus d'informations, consultez la section [Publication de métriques personnalisées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) dans le *guide de CloudWatch l'utilisateur Amazon*. Si vous publiez vos propres métriques, veillez à publier les points de données à une fréquence minimale de cinq minutes. Application Auto Scaling extrait les points de données CloudWatch en fonction de la durée de la période dont elle a besoin. Par exemple, la spécification des métriques de charge utilise des métriques horaires pour mesurer la charge de votre application. CloudWatch utilise vos données métriques publiées pour fournir une valeur de données unique pour toute période d'une heure en agrégeant tous les points de données avec des horodatages correspondant à chaque période d'une heure. # Construction du fichier JSON pour les métriques personnalisées La section suivante contient des exemples de configuration du dimensionnement prédictif pour interroger les données d' CloudWatch Amazon EC2 Auto Scaling. Il existe deux méthodes pour configurer cette option, qui affecteront le format utilisé pour créer le fichier JSON de votre politique de mise à l'échelle prédictive. Lorsque vous utilisez des mathématiques de métriques, le format du fichier JSON varie davantage en fonction des mathématiques de métriques effectuées. 1. Pour créer une politique qui obtient des données directement à partir d'autres CloudWatch indicateurs fournis par AWS ou sur lesquels vous publiez CloudWatch, voir[Exemple de politique de mise à l'échelle prédictive avec des métriques de charge et de mise à l'échelle personnalisées (AWS CLI)](#custom-metrics-ex1). 1. Pour créer une politique capable d'interroger plusieurs CloudWatch mesures et d'utiliser des expressions mathématiques pour créer de nouvelles séries chronologiques basées sur ces mesures, voir[Utiliser des expressions mathématiques de métrique](using-math-expression-examples.md). ## Exemple de politique de mise à l'échelle prédictive avec des métriques de charge et de mise à l'échelle personnalisées (AWS CLI) Pour créer une politique de dimensionnement prédictive avec des métriques de charge et de dimensionnement personnalisées avec le AWS CLI, stockez les arguments pour `--predictive-scaling-configuration` dans un fichier JSON nommé`config.json`. Vous commencez par ajouter des métriques personnalisées en remplaçant les valeurs remplaçables de l'exemple suivant par celles de vos métriques et de votre utilisation cible. ``` { "MetricSpecifications": [ { "TargetValue": 50, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Id": "scaling_metric", "MetricStat": { "Metric": { "MetricName": "MyUtilizationMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Average" } } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "MyLoadMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Sum" } } ] } } ] } ``` Pour plus d'informations, consultez le [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)manuel *Amazon EC2 Auto Scaling API Reference*. **Note** Voici quelques ressources supplémentaires qui peuvent vous aider à trouver des noms de métriques, des espaces de noms, des dimensions et des statistiques pour les CloudWatch métriques : Pour plus d'informations sur les métriques disponibles pour les AWS services, consultez les [AWS services qui publient CloudWatch des métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html) dans le *guide de CloudWatch l'utilisateur Amazon*. Pour obtenir le nom, l'espace de noms et les dimensions exacts (le cas échéant) d'une CloudWatch métrique comportant le AWS CLI, consultez [list-metrics](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/list-metrics.html). Pour créer cette politique, exécutez la [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)commande en utilisant le fichier JSON comme entrée, comme illustré dans l'exemple suivant. ``` aws autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json ``` Si elle aboutit, cette commande renvoie l'Amazon Resource Name (ARN) de la stratégie. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy", "Alarms": [] } ``` # Utiliser des expressions mathématiques de métrique La section suivante fournit des informations et des exemples de politiques de mise à l'échelle prédictive qui montrent comment vous pouvez utiliser les mathématiques de métriques dans votre politique. **Topics** + [ ## Comprendre les mathématiques de métrique ](#custom-metrics-metric-math) + [ ## Exemple de politique de dimensionnement prédictif pour Amazon EC2 Auto Scaling qui combine les métriques à l'aide des mathématiques AWS CLI métriques () ](#custom-metrics-ex2) + [ ## Exemple de politique de dimensionnement prédictif à utiliser dans un scénario de blue/green déploiement (AWS CLI) ](#custom-metrics-ex3) ## Comprendre les mathématiques de métrique Si vous souhaitez simplement agréger des données métriques existantes, les mathématiques CloudWatch métriques vous évitent les efforts et les coûts liés à la publication d'une autre métrique dans CloudWatch. Vous pouvez utiliser n'importe quelle métrique qui AWS fournit, et vous pouvez également utiliser des métriques que vous définissez dans le cadre de vos applications. Pour plus d'informations, consultez la section [Utilisation des mathématiques métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) dans le *guide de CloudWatch l'utilisateur Amazon*. Si vous choisissez d'utiliser une expression mathématique de métrique dans votre politique de mise à l'échelle prédictive, tenez compte des points suivants : + Les opérations mathématiques de métrique utilisent les points de données de la combinaison unique de nom de la métrique, d'espace de noms et de paires clé/valeur de dimension des métriques. + Vous pouvez utiliser n'importe quel opérateur arithmétique (\$1 - \$1/^), fonction statistique (telle que AVG ou SUM) ou toute autre fonction compatible. CloudWatch + Vous pouvez utiliser à la fois des métriques et les résultats d'autres expressions mathématiques dans les formules de l'expression mathématique. + Vos expressions mathématiques de métrique peuvent être composées de différentes agrégations. Cependant, une bonne pratique pour le résultat final de l'agrégation consiste à utiliser `Average` pour la métrique de mise à l'échelle et `Sum` pour la métrique de charge. + Toutes les expressions utilisées dans une spécification de métrique doivent finalement retourner une seule séries temporelles. Pour utiliser les mathématiques de métrique, procédez comme suit : + Choisissez un ou plusieurs CloudWatch indicateurs. Créez ensuite l'expression. Pour plus d'informations, consultez la section [Utilisation des mathématiques métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) dans le *guide de CloudWatch l'utilisateur Amazon*. + Vérifiez que l'expression mathématique de la métrique est valide à l'aide de la CloudWatch console ou de l' CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)API. ## Exemple de politique de dimensionnement prédictif pour Amazon EC2 Auto Scaling qui combine les métriques à l'aide des mathématiques AWS CLI métriques () Parfois, au lieu de spécifier la métrique directement, vous devrez d'abord traiter ses données d'une certaine manière. Par exemple, une application peut extraire le travail d'une file d'attente Amazon SQS et vous souhaitez utiliser le nombre d'éléments dans la file d'attente comme critère de mise à l'échelle prédictive. Le nombre de messages dans la file d'attente ne définit pas uniquement le nombre d'instances dont vous avez besoin. Par conséquent, un travail supplémentaire est nécessaire pour créer une métrique qui peut être utilisée pour calculer le backlog par instance. Ce qui suit est un exemple de politique de mise à l'échelle prédictive pour ce scénario. Il spécifie les métriques de mise à l'échelle et de charge qui sont basées sur la métrique `ApproximateNumberOfMessagesVisible` d'Amazon SQS, qui est le nombre de messages disponibles pour la récupération de la file d'attente. Il utilise également la métrique `GroupInServiceInstances` d'Amazon EC2 Auto Scaling et une expression mathématique pour calculer le backlog par instance pour la métrique de mise à l'échelle. ``` aws autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json { "MetricSpecifications": [ { "TargetValue": 100, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Label": "Get the queue size (the number of messages waiting to be processed)", "Id": "queue_size", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Get the group size (the number of running instances)", "Id": "running_capacity", "MetricStat": { "Metric": { "MetricName": "GroupInServiceInstances", "Namespace": "AWS/AutoScaling", "Dimensions": [ { "Name": "AutoScalingGroupName", "Value": "my-asg" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Calculate the backlog per instance", "Id": "scaling_metric", "Expression": "queue_size / running_capacity", "ReturnData": true } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ], }, "Stat": "Sum" }, "ReturnData": true } ] } } ] } ``` L'exemple renvoie l'ARN de la politique. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy", "Alarms": [] } ``` ## Exemple de politique de dimensionnement prédictif à utiliser dans un scénario de blue/green déploiement (AWS CLI) Une expression de recherche fournit une option avancée dans laquelle vous pouvez demander une métrique à partir de plusieurs groupes Auto Scaling et effectuer des expressions mathématiques sur eux. Cela est particulièrement utile pour les blue/green déploiements. **Note** Un *déploiement bleu/vert* est une méthode de déploiement dans laquelle vous créez deux groupes Auto Scaling distincts mais identiques. Seul l'un des groupes reçoit le trafic de production. Le trafic utilisateur est initialement dirigé vers le groupe Auto Scaling précédent (« bleu »), tandis qu'un nouveau groupe (« vert ») est utilisé pour le test et l'évaluation d'une nouvelle version d'une application ou d'un service. Le trafic utilisateur est transféré vers le groupe Auto Scaling vert après qu'un nouveau déploiement ait été testé et accepté. Vous pouvez ensuite supprimer le groupe bleu après le succès du déploiement. Lorsque de nouveaux groupes Auto Scaling sont créés dans le cadre d'un blue/green déploiement, l'historique des métriques de chaque groupe peut être automatiquement inclus dans la politique de dimensionnement prédictif sans que vous ayez à modifier ses spécifications métriques. Pour plus d'informations, consultez la section [Utilisation des politiques de dimensionnement prédictif d'EC2 Auto Scaling avec des déploiements bleu/vert](https://aws.amazon.com/blogs/compute/retaining-metrics-across-blue-green-deployment-for-predictive-scaling/) sur le Compute Blog. AWS L'exemple de politique suivant montre comment cela peut être fait. Dans cet exemple, la politique utilise la métrique `CPUUtilization` émise par Amazon EC2. Elle utilise la métrique `GroupInServiceInstances` d'Amazon EC2 Auto Scaling et une expression mathématique pour calculer la valeur de la métrique de mise à l'échelle par instance. Elle spécifie également une métrique de capacité pour obtenir la métrique `GroupInServiceInstances`. L'expression de recherche trouve la `CPUUtilization` des instances dans plusieurs groupes Auto Scaling en fonction des critères de recherche spécifiés. Si vous créez ultérieurement un nouveau groupe Auto Scaling qui correspond aux mêmes critères de recherche, `CPUUtilization` des instances dans le nouveau groupe Auto Scaling est automatiquement incluse. ``` aws autoscaling put-scaling-policy --policy-name my-blue-green-predictive-scaling-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json { "MetricSpecifications": [ { "TargetValue": 25, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Id": "load_sum", "Expression": "SUM(SEARCH('{AWS/EC2,AutoScalingGroupName} MetricName=\"CPUUtilization\" ASG-myapp', 'Sum', 300))", "ReturnData": false }, { "Id": "capacity_sum", "Expression": "SUM(SEARCH('{AWS/AutoScaling,AutoScalingGroupName} MetricName=\"GroupInServiceInstances\" ASG-myapp', 'Average', 300))", "ReturnData": false }, { "Id": "weighted_average", "Expression": "load_sum / capacity_sum", "ReturnData": true } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_sum", "Expression": "SUM(SEARCH('{AWS/EC2,AutoScalingGroupName} MetricName=\"CPUUtilization\" ASG-myapp', 'Sum', 3600))" } ] }, "CustomizedCapacityMetricSpecification": { "MetricDataQueries": [ { "Id": "capacity_sum", "Expression": "SUM(SEARCH('{AWS/AutoScaling,AutoScalingGroupName} MetricName=\"GroupInServiceInstances\" ASG-myapp', 'Average', 300))" } ] } } ] } ``` L'exemple renvoie l'ARN de la politique. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-blue-green-predictive-scaling-policy", "Alarms": [] } ``` # Considérations relatives aux métriques personnalisées dans le cadre d'une politique de dimensionnement prédictive Si un problème survient lors de l'utilisation de métriques personnalisées, nous vous recommandons d'effectuer les opérations suivantes : + Si un message d'erreur est fourni, lisez le message et résolvez le problème qu'il signale, si possible. + Si vous n'avez pas validé une expression à l'avance, la [ put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/application-autoscaling/put-scaling-policy.html)commande la valide lorsque vous créez votre politique de dimensionnement. Cependant, il est possible que cette commande ne parvienne pas à identifier la cause exacte des erreurs détectées. Pour résoudre les problèmes, corrigez les erreurs que vous recevez en réponse à une demande de [get-metric-data](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/get-metric-data.html)commande. Vous pouvez également résoudre les problèmes liés à l'expression depuis la CloudWatch console. + Vous devez spécifier `false` pour `ReturnData` si `MetricDataQueries` spécifie la fonction SEARCH() seule sans une fonction mathématique comme SUM(). Cela est dû au fait que les expressions de recherche peuvent renvoyer plusieurs séries temporelles et qu'une spécification métrique basée sur une expression ne peut renvoyer qu'une seule séries temporelles. + Toutes les métriques impliquées dans une expression de recherche doivent avoir la même résolution. **Limitations** Les limites suivantes s'appliquent. + Vous pouvez interroger des points de données de 10 métriques au maximum dans une spécification métrique. + Dans le cadre de cette limite, une expression compte pour une métrique.