Suivi de cible vs scaling par paliers — choisir la bonne politique d'ASG selon la charge

L’ASG a été monté il y a deux ans avec une seule politique de suivi de cible : tenir la moyenne CPU à 50 %. Ça a marché un an. Puis la charge a changé — un nouveau batch envoie ses logs aux quinze minutes, le pic dure 90 secondes, la machine atteint 95 % de CPU pendant. Le suivi de cible voit le pic, scale, ajoute deux instances. Quatre-vingt-dix secondes plus tard le pic est fini et les nouvelles instances sont inactives. Cinq minutes après ça, le cooldown se libère, le suivi voit une moyenne CPU à 28 %, scale à la baisse, retire deux instances. Puis le prochain batch arrive. L’ASG oscille maintenant sur un cycle de 15 minutes, coûte des heures-instance en trop et déclenche une petite tempête de notifications à chaque tour. La bonne réponse n’est pas « ajuster la cible » — c’est choisir la bonne forme de politique pour le comportement de la charge.

Ce qui se passe

L’ASG a trois types de politique. Le scaling simple est le modèle original, à seuil unique : quand une alarme se déclenche, change la capacité de N. C’est l’héritage. AWS le garde pour compatibilité. Ne pas l’utiliser pour rien de neuf. Les deux autres sont le vrai choix.

Le suivi de cible est le défaut moderne. Vous choisissez une métrique (CPU, octets réseau, nombre de requêtes par cible, ou une métrique custom) et une valeur cible. AWS vous crée deux alarmes CloudWatch — une « au-dessus », une « en dessous » — et la politique ajoute ou enlève de la capacité pour tenir la métrique près de la cible. La math qu’AWS fait derrière est prudente : il estime combien d’instances il aurait fallu pour tenir la cible pendant la période d’alarme, puis prend une fraction du delta pour éviter le dépassement.

Le suivi de cible brille quand :

La métrique est à peu près linéaire avec la capacité. Le CPU et le nombre de requêtes par cible en sont les exemples canoniques.
La charge est en régime permanent avec tendance — courbes diurnes, croissance hebdomadaire lente, pics prévisibles. Le genre de chose que produit un palier web SaaS.
Vous ne voulez pas maintenir les définitions d’alarme vous-même. Le suivi de cible possède les alarmes qu’il crée.

Le scaling par paliers est le modèle explicite. Vous définissez une alarme CloudWatch vous-même, vous y attachez une politique de paliers, et vous spécifiez les paliers de scaling selon la distance à la cible. Par exemple : alarme quand CPU > 70 % sur 2 des 3 dernières périodes. Paliers : +1 instance entre 70 et 80 %, +2 entre 80 et 90 %, +4 au-dessus de 90 %.

Le scaling par paliers brille quand :

La charge est pilotée par événements ou cron — batchs, ETL, tests de charge planifiés. La métrique ne bouge pas en douceur.
La bonne réponse à un dépassement de 10 points est différente de la bonne réponse à un dépassement de 30 points. Le suivi de cible traite les deux pareillement par rapport à l’erreur.
Vous devez scaler sur une métrique non linéaire — profondeur de file où ajouter un consommateur divise par deux la profondeur, pas l’ajuste d’une fraction lisse.
Vous voulez des définitions d’alarmes explicites et auditables dans l’IaC. Les alarmes du scaling par paliers sont les vôtres ; celles du suivi de cible sont gérées par AWS et plus dures à raisonner dans un diff Terraform.

Le motif d’oscillation en intro est le mode d’échec le plus commun du suivi de cible. Ça arrive quand la métrique pique plus vite que l’action de scaling ne peut effectuer son effet. Le suivi voit le pic, déclenche l’alarme haute, demande N instances de plus. Le temps que les instances soient chaudes et passent les health checks, le pic est fini. Maintenant la métrique est sous la cible, l’alarme basse se déclenche, la politique scale à la baisse. Le motif recommence au prochain batch.

L’autre mode d’échec : le suivi de cible sur une métrique non linéaire avec la capacité. Si vous scalez sur « mémoire disponible » et que la charge est en rafale, doubler la flotte ne divise pas par deux la pression mémoire pendant la rafale — la rafale est finie avant que les nouvelles instances acceptent du trafic. La cible n’est jamais atteinte, la politique continue d’ajouter, le plafond vous sauve.

Comment vérifier

Pour voir si le suivi de cible oscille, tirer l’historique des activités des 24 dernières heures :

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name my-app-prod-asg \
  --max-items 100 \
  --query 'Activities[].[StartTime,StatusCode,Description]' \
  --output table

Un suivi de cible en régime permanent sain montre une poignée d’activités par jour, surtout pendant les transitions diurnes. L’oscillation montre des paires scale-out / scale-in rapprochées — souvent dans la même heure. Si vous voyez « Launching a new EC2 instance » suivi en moins de dix minutes par « Terminating EC2 instance », le suivi de cible se bat contre lui-même.

Regarder la métrique suivie par la politique, avec la fenêtre d’évaluation superposée :

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=AutoScalingGroupName,Value=my-app-prod-asg \
  --start-time $(date -u -v-1d +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 60 \
  --statistics Average \
  --output text

Un graphe d’une charge oscillante montre des pics nets revenant à la base en quelques minutes. Une charge douce montre une courbe lente. Le suivi de cible épouse la deuxième, combat la première.

Pour trouver les alarmes auto-gérées de la politique de suivi :

aws cloudwatch describe-alarms \
  --query 'MetricAlarms[?starts_with(AlarmName, `TargetTracking-`)].[AlarmName,Threshold,EvaluationPeriods]' \
  --output table

Si vous voyez une alarme à 1 période d’évaluation et 60 secondes de période, la politique réagit à chaque minute. C’est rapide pour une charge oscillante — et ça amplifie l’oscillation. Le cooldown de 3 minutes en scale-in et l’exigence 3-sur-3 du suivi de cible aident, mais sur un cycle de 15 minutes ils ne suffisent pas.

La correction

Arbre de décision, dans l’ordre :

La métrique est-elle linéaire avec la capacité ? Si oui, le suivi de cible est dans la course. Si non — par exemple profondeur de file où un consommateur de plus divise par deux la profondeur, ou pression mémoire où les rafales terminent avant que la nouvelle instance soit en service — direction scaling par paliers.

La charge est-elle douce ou en pics ? Douce (courbes diurnes, rampes lentes, croissance graduelle) → suivi de cible. En pics (batchs cron, tests planifiés, surges événementiels) → scaling par paliers.

La bonne réponse varie-t-elle avec la taille du dépassement ? Un dépassement CPU de 5 points sur un palier web mérite un petit changement ; 30 points méritent plus. Le suivi de cible les traite proportionnellement mais avec la même constante de temps. Si vous voulez une réponse explicite non linéaire, scaling par paliers.

Pour le scénario d’oscillation en intro, la correction est de remplacer la politique unique de suivi par une approche en couches :

Couverture de courbe douce par suivi de cible sur ASGAverageCPUUtilization, avec un cooldown plus long et une cible qui laisse plus de marge (40 % plutôt que 50 %).
Couverture de batch par une politique de paliers sur une alarme qui se déclenche seulement quand CPU > 85 % sur 3 des 5 dernières périodes d’une minute — ce que la brève rafale de batch ne soutient jamais. La politique de paliers gère les vrais débordements de charge, pas les pics de 90 secondes.
Scaling prédictif si le batch est planifié et prévisible. aws autoscaling put-scheduled-action permet de monter la taille min avant une fenêtre connue et de la baisser après.

Politique de paliers concrète pour la couverture de batch :

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-app-prod-asg \
  --policy-name scale-out-on-sustained-cpu \
  --policy-type StepScaling \
  --adjustment-type ChangeInCapacity \
  --metric-aggregation-type Average \
  --step-adjustments '[
    {"MetricIntervalLowerBound": 0, "MetricIntervalUpperBound": 10, "ScalingAdjustment": 1},
    {"MetricIntervalLowerBound": 10, "MetricIntervalUpperBound": 20, "ScalingAdjustment": 2},
    {"MetricIntervalLowerBound": 20, "ScalingAdjustment": 4}
  ]'

Les bornes de paliers sont relatives au seuil de l’alarme. Avec une alarme à CPU > 70 %, la politique ajoute 1 instance entre 70 et 80 %, 2 entre 80 et 90 %, 4 au-dessus. L’alarme doit être configurée pour le débordement soutenu (3 des 5 dernières périodes) pour ne pas se déclencher sur le même pic de 90 secondes que le suivi de cible chassait.

Trois règles qui tiennent à chaque revue de politique d’ASG :

Une politique par comportement. Suivi de cible pour la courbe douce. Paliers pour les débordements soutenus. Action planifiée pour les fenêtres connues. Ne pas empiler une cible sur un palier sur la même métrique sans réfléchir à qui gagne quand les deux s’alarment en même temps.

Regarder l’historique avant d’ajuster. Un suivi de cible qui « scale trop » est habituellement un décalage de forme de charge, pas un problème de valeur cible. Baisser la cible fait plus osciller un ASG qui oscille.

Régler un warmup réaliste. Le default_instance_warmup sur l’ASG (et EstimatedInstanceWarmup sur la politique) dit au suivi de cible combien de temps une nouvelle instance met à vraiment porter de la charge. Si vous mettez 60 secondes mais que l’AMI démarre en 4 minutes, la politique voit la métrique encore haute et double le scaling. Pour la plupart des serveurs applicatifs, c’est 300 à 600 secondes, pas 60.

Le suivi de cible est le bon défaut pour un palier web SaaS. Le scaling par paliers est le bon défaut pour le batch et l’événementiel. L’erreur est de tendre vers le suivi de cible partout parce que c’est plus court à écrire, puis à déboguer les oscillations quand la charge ne correspond pas au modèle.

Stack Harbor opère les paliers applicatifs sur ASG et les politiques d’auto-scaling à coût plafonné dans le cadre de Gestion AWS et de la couche Auto-scaling. Si vos événements de scaling sont encore des surprises, commencez par une consultation d’infrastructure.