Les groupes Auto Scaling EC2

Une plateforme de streaming fait tourner 12 instances EC2 derrière un Application Load Balancer. Le pic de trafic dure environ 3 heures en soirée, du lundi au vendredi. Le reste du temps, 3 instances suffiraient largement, mais la flotte reste à 12 parce que personne ne veut être celui qui l'a réduite la semaine d'un lancement. Puis un samedi, une instance sature son disque, cesse de répondre, et reste morte jusqu'au lundi matin : aucun health check n'était relié à quoi que ce soit capable d'agir.

Ce sont 2 pannes différentes, et un groupe Auto Scaling les corrige avec le même mécanisme. C'est un ensemble d'instances EC2 qu'AWS maintient à une taille que vous déclarez, en lançant et en terminant des instances pour tenir cette taille, et en remplaçant toute instance qui cesse de paraître saine. Les politiques de scaling qui font bouger cette taille arrivent à la leçon suivante. Celle-ci traite de la mécanique en dessous, parce que presque toutes les erreurs de scaling en production viennent d'ici, et non de la politique.

Trois nombres, et une politique n'en déplace qu'un

Un groupe Auto Scaling se définit par 3 valeurs de capacité.

• La capacité minimum est un plancher. Le groupe ne descend jamais en dessous.
• La capacité maximum est un plafond. Le groupe ne monte jamais au-dessus.
• La capacité desired est le nombre d'instances que le groupe cherche à faire tourner à cet instant.

Prenez minimum 2, desired 6, maximum 12. Le groupe lance 6 instances. Si une politique calcule plus tard qu'il faut 15 instances pour tenir le CPU à sa cible, le groupe monte à 12 et s'arrête, parce que 15 dépasse le plafond. Si un calcul de scale in dit qu'une seule instance suffit, le groupe descend à 2 et s'arrête.

La phrase à retenir : une politique de scaling modifie la capacité desired, et seulement elle. Le minimum et le maximum sont des bornes qui contraignent le résultat. Une lecture erronée traîne ici. Fixer la capacité maximum à 12 ne veut pas dire que le groupe fait tourner 12 instances. Cela veut dire qu'il n'en fera jamais tourner plus de 12. Un groupe collé à son maximum parce que la capacité desired y a été poussée est une situation complètement différente d'un groupe à 6 avec de la marge jusqu'à 12, et l'examen aime les énoncés où le groupe a déjà atteint son plafond pendant que la politique a l'air cassée.

Un groupe sans aucune politique de scaling a aussi de la valeur. Avec une capacité desired figée à 6, le groupe surveille quand même ces 6 instances et remplace celles qui échouent à un health check. Maintenir la capacité et faire varier la capacité sont 2 fonctionnalités distinctes, et la première justifie à elle seule de créer un groupe, même pour une flotte dont la taille ne bouge jamais.

Le launch template est le plan de construction

Le groupe doit savoir quoi lancer. Cela vient d'un launch template : ID d'AMI, type d'instance, paire de clés, security groups, IAM instance profile, block device mappings, user data, et le reste de la surface de lancement EC2.

Les launch templates sont versionnés. Vous créez la version 3 avec une nouvelle AMI, vous pointez le groupe dessus, et toute instance lancée à partir de cet instant utilise la version 3 pendant que les instances existantes continuent avec ce qu'elles avaient au lancement. Cet historique de versions est ce qui fait fonctionner la politique de terminaison par défaut et l'instance refresh, et les 2 reviennent plus loin.

La vieille launch configuration existe encore dans d'anciens comptes et d'anciens supports. Elle n'est pas versionnée, elle ne se modifie pas (on la remplace), et AWS ne l'étend plus aux nouvelles fonctionnalités EC2. Traitez « migrer le groupe d'une launch configuration vers un launch template » comme la réponse attendue dès qu'un scénario mentionne du Spot et de l'On-Demand dans un même groupe, plusieurs types d'instances, ou un instance refresh : aucun des 3 ne fonctionne avec une launch configuration.

Les health checks décident de ce qui est remplacé

Une instance dans un groupe Auto Scaling démarre à l'état Healthy et y reste tant que rien ne dit le contraire. Le groupe écoute plusieurs sources :

Ce tableau cache la mauvaise configuration la plus fréquente du sujet, alors disons-la à voix haute. Par défaut, un groupe Auto Scaling n'utilise que les status checks EC2. Une instance dont l'application renvoie un HTTP 500 à chaque requête passe quand même ces contrôles, parce que l'hyperviseur va bien et que le système d'exploitation tourne. L'ALB, lui, s'en aperçoit, marque la cible unhealthy et cesse de lui envoyer du trafic. Le groupe Auto Scaling ne la remplace pas, et vous vous retrouvez indéfiniment avec un groupe qui annonce 6 instances saines derrière un target group qui en annonce 5. Activer le health check Elastic Load Balancing sur le groupe est ce qui referme cet écart.

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --health-check-type ELB \
  --health-check-grace-period 300

La health check grace period de cette commande est la deuxième chose à régler correctement. C'est la durée minimale pendant laquelle une instance fraîchement en service est laissée tranquille avant qu'un verdict unhealthy puisse la terminer. Les health checks Elastic Load Balancing commencent dès l'enregistrement de l'instance, donc une application qui a besoin de 4 minutes pour chauffer ses caches échouerait à ses premiers contrôles et se ferait tuer pour ça. La grace period achète ce temps.

Les valeurs par défaut ne sont pas les mêmes partout, et c'est un vrai piège :

• Console : 300 secondes
• AWS CLI ou SDK : 0 seconde, ce qui désactive complètement la grace period

Un groupe créé par un template CloudFormation ou un script CLI sans grace period explicite juge donc ses instances dès la première seconde, et une flotte au démarrage lent peut tomber dans une boucle où chaque remplaçante est tuée avant d'avoir fini de démarrer. Une exception s'applique pendant la grace period : si l'instance quitte l'état EC2 running, parce que quelqu'un l'a arrêtée par exemple, le groupe la marque Unhealthy et la remplace immédiatement, sans attendre.

Ne résolvez pas le problème en poussant la grace period à une heure. Une grace period élevée est du temps mort pendant lequel une instance réellement cassée reste en service. Le meilleur correctif, traité dans la leçon sur le cycle de vie, est un lifecycle hook de lancement qui garde l'instance hors service jusqu'à la fin de son bootstrap, ce qui vous laisse une grace period basse.

Deux comportements de plus à garder en tête : le remplacement pour cause de health check n'attend pas de cooldown, et une instance déjà marquée unhealthy saute entièrement l'évaluation de la politique de terminaison. Les instances unhealthy ne sont pas choisies, elles sont simplement retirées.

L'équilibre zonal passe avant tout le reste

Vous donnez des sous-réseaux au groupe, et chaque sous-réseau vit dans une seule zone de disponibilité. Quand le groupe lance une instance, il choisit la zone activée qui en contient le moins, et dans cette zone le sous-réseau qui a le plus d'adresses IP libres. Quand il termine, il regarde d'abord la zone qui en contient le plus.

Cet ordre compte plus qu'il n'y paraît. L'équilibre zonal est évalué avant la politique de terminaison, toujours. Un groupe avec 5 instances dans us-east-1a et 3 dans us-east-1b terminera donc dans us-east-1a, même si la seule instance vraiment la plus ancienne du groupe se trouve dans us-east-1b. Quand un scénario dit « l'instance la plus récente a été terminée et nous ne comprenons pas pourquoi », le déséquilibre zonal est presque toujours la réponse.

Les groupes se déséquilibrent pour des raisons ordinaires : une zone a manqué de capacité pendant un moment puis s'est rétablie, vous avez changé les zones activées, vous avez mis des instances en standby, ou un prix Spot est repassé sous votre maximum dans une zone qui en était sortie. Quand cela arrive, le groupe déclenche une activité de rééquilibrage entre zones de disponibilité. Il lance d'abord la nouvelle instance et termine l'ancienne ensuite, donc un rééquilibrage ne creuse jamais votre capacité.

Lancer avant de terminer pose un problème évident quand le groupe est déjà au maximum, et AWS l'a réglé avec une exception documentée : pendant un rééquilibrage, le groupe peut temporairement dépasser la capacité maximum de 10 % ou d'une instance, selon ce qui est le plus grand. La marge ne dure que le temps du rééquilibrage, quelques minutes en général. Si même ce dépassement est inacceptable, une instance maintenance policy vous laisse fixer une plage de pourcentages sains à la place.

Quelle instance meurt lors d'un scale in

Une fois la zone choisie, la politique de terminaison par défaut parcourt les instances non protégées dans cet ordre :

1. Les configurations obsolètes d'abord. Pour un groupe sur launch templates, cela veut dire les instances lancées depuis une launch configuration, puis celles lancées depuis un launch template différent, puis celles sur la version la plus ancienne du launch template actuel.
2. La plus proche de sa prochaine heure de facturation. S'il reste plusieurs candidates, le groupe prend celle qui est la plus proche de sa prochaine heure de facturation, et départage au hasard. Cette étape pèse bien moins qu'avant, puisque la plupart des usages EC2 se facturent à la seconde.

L'objectif de conception est de retirer naturellement les configurations périmées au fil des scale in, ce qui explique qu'un groupe qui monte et descend au fil de la journée converge tout seul vers la version actuelle du launch template.

Les groupes à instances mixtes ajoutent une étape en amont. Le groupe décide d'abord si c'est une instance Spot ou On-Demand qui doit partir, pour que la flotte revienne vers le ratio configuré, puis il vérifie si terminer telle instance améliore l'alignement avec votre allocation strategy, et seulement ensuite il retombe sur les configurations obsolètes et l'heure de facturation.

Vous pouvez remplacer la politique quand le défaut ne convient pas :

Quel que soit votre choix, l'équilibre zonal gagne toujours en premier. Une politique de terminaison ne décide que de l'instance à supprimer à l'intérieur de la zone retenue.

Protéger une instance du scale in, et ce que cela ne vous achète pas

Certaines instances ne doivent pas être choisies : un hôte de conteneurs au milieu d'un job, un agent de build à 40 minutes de compilation, un nœud qui détient une session longue. La protection contre le scale in rend une instance inéligible à la terminaison par un événement de scale in. Vous pouvez l'activer sur le groupe pour que chaque nouvelle instance en hérite, puis la retirer instance par instance quand le travail se termine, ce qui est le motif utilisé par les ordonnanceurs de conteneurs.

La moitié importante de cette fonctionnalité, c'est ce qu'elle ne fait pas. La protection contre le scale in n'empêche pas :

• Le remplacement après l'échec d'un health check
• L'interruption d'une instance Spot
• La fin d'une réservation Capacity Block
• La terminaison manuelle via terminate-instance-in-auto-scaling-group
• La terminaison manuelle depuis la console, la CLI ou l'API EC2

Ce dernier point surprend. Pour empêcher un humain de terminer l'instance depuis la console EC2, il vous faut la termination protection EC2, un réglage distinct posé sur l'instance elle-même. Les 2 noms se ressemblent et ne désignent pas la même chose.

Un cas limite apparaît dans de vrais incidents : si toutes les instances du groupe sont protégées et qu'un scale in se déclenche, le groupe décrémente la capacité desired mais ne peut rien terminer. L'historique d'activité enregistre Could not scale to desired capacity because all remaining instances are protected from scale in, et le groupe tourne silencieusement au-dessus de sa propre capacité desired jusqu'à ce qu'une protection soit levée quelque part.

Éteindre une partie du groupe pendant que vous travaillez

Quand vous avez besoin que le groupe cesse d'agir un moment, suspendez des processus individuels plutôt que de supprimer des politiques :

Choisir le bon est une question de diagnostic. Suspendre Launch stoppe le carrousel mais bloque aussi un scale out planifié dont vous avez peut-être encore besoin ; suspendre ReplaceUnhealthy ne stoppe que la boucle de remplacement. Et si un groupe échoue à lancer des instances depuis plus de 24 heures environ, AWS applique de lui-même une suspension administrative. Quand quelqu'un signale qu'un groupe « ne fait plus rien », regardez les processus suspendus avant de regarder la politique.

Conseils pour l'examen

• Un scénario où le groupe refuse de grandir alors que la politique semble correcte est une question de capacité maximum. Lisez les 3 nombres avant de lire la politique.
• « Le load balancer voit la cible unhealthy mais l'instance n'est jamais remplacée » est toujours le type de health check. Le groupe s'en tient aux status checks EC2 par défaut.
• « Les instances sont terminées et relancées en boucle juste après leur lancement » est la health check grace period, et l'indice est un groupe créé en CLI ou en CloudFormation, où le défaut est 0 et non les 300 de la console.
• Ne confondez pas les 2 minuteurs. La health check grace period est le délai avant que les health checks puissent tuer une nouvelle instance. Le cooldown par défaut, 300 secondes, est une pause entre activités de simple scaling et appartient à la leçon suivante.
• « Une instance récente a été terminée avant une plus ancienne » signifie que les zones étaient déséquilibrées. L'équilibre zonal prime sur la politique de terminaison.
• Tout ce qui parle de Spot et d'On-Demand dans un même groupe, de plusieurs types d'instances ou d'instance refresh exclut les launch configurations. La réponse exige un launch template.
• La protection contre le scale in ne bloque que le scale in. Si l'énoncé parle de health check, d'interruption Spot ou d'une personne qui clique sur Terminate, la protection n'est pas la bonne réponse.

Le modèle à emporter dans la leçon suivante est étroit et porteur : le groupe n'a qu'un seul curseur qu'il déplace, la capacité desired, et tout un jeu de règles sur la façon dont les instances sont créées, jugées et choisies pour le retrait autour de ce curseur. Tout ce qui suit, target tracking, step scaling, predictive scaling, n'est qu'une manière différente de décider ce que ce nombre unique devrait valoir.