Aller au contenu

AWS Mis à jour le 2026-01-02

Warm pools — passer le scale-out de minutes à secondes quand le démarrage est lent

Vous pouvez cuire une AMI plus mince et vous attendrez encore une minute. Certaines charges veulent la machine prête en vingt secondes. Les warm pools tiennent des instances pré-démarrées à l'arrêt et les amènent à InService dans le temps que met le LB à les vérifier.

L’ASG scale quand le CPU passe 70 %. Le modèle de lancement référence une AMI cuite chaque nuit ; les données utilisateur téléchargent deux fichiers de configuration depuis SSM, tirent une image de conteneur de 600 Mo, exécutent les migrations de base comme contrôle de cohérence, puis signalent le lifecycle hook pour marquer l’instance InService. Bout en bout, quatre minutes entre « AWS lance une instance » et « ALB retourne 200 ». Pour une courbe diurne douce, quatre minutes suffisent. Pour une vraie surge — l’envoi marketing à 10 h envoie 4× le trafic en trois minutes — le temps que les nouvelles instances soient en service, le pic est à moitié fini, la flotte initiale est clouée à 100 % CPU, et un quart des requêtes ont expiré en attente. La correction n’est pas une AMI plus mince. La correction, c’est les warm pools.

Ce qui se passe

Un warm pool est un tampon d’instances pré-lancées et pré-démarrées tenues dans l’état Arrêté ou Hiberné à côté de la flotte active de l’ASG. Quand le scale-out se déclenche, l’ASG tire une instance du warm pool, la démarre, exécute ce que le lifecycle hook warm-vers-actif exige, et la met InService. Le chemin de lancement saute les parties lentes — provisionnement d’AMI, téléchargement des données utilisateur, pull de conteneur — parce que tout ça a déjà tourné quand l’instance est entrée dans le warm pool.

Les transitions d’état :

  1. Création du warm pool. L’instance est lancée depuis le modèle de lancement, exécute le boot standard (cloud-init, données utilisateur, installation de paquets), puis transitionne vers le lifecycle hook d’état warm. C’est là que vous terminez le démarrage.
  2. Résident du warm pool. L’instance passe à Arrêté (EBS préservé, pas de coût de calcul), Hiberné (RAM préservée sur disque, pas de coût de calcul, restauration plus rapide), ou En marche (coût de calcul facturé, restauration la plus rapide — utile seulement pour le cas le plus sensible à la latence).
  3. Transition warm-vers-actif. L’ASG décide de scaler. L’instance warm choisie est démarrée, exécute le lifecycle hook warm-vers-actif (où vous tirez la dernière configuration et signalez la disponibilité au LB), et l’ASG la transfère dans la flotte principale en InService.

Trois états de résidence, trois compromis :

  • Arrêté — coûte juste le stockage EBS pendant la chauffe. Le temps de restauration est le démarrage à froid de l’OS plus votre hook warm-vers-actif. Typiquement 30 à 60 secondes. Bon pour presque tous les cas.
  • Hiberné — la RAM est snapshottée sur disque à l’arrêt, restaurée au démarrage. L’OS ne démarre pas ; le noyau reprend où il était. Le temps de restauration est de 15 à 30 secondes. Coûte de l’espace disque en plus pour le dump RAM. Bon quand l’état en mémoire de l’application compte (JVM chauffée, cache peuplé) et que vous le voulez plus vite qu’un stop/start.
  • En marche — coût plein d’instance. La restauration est juste le hook warm-vers-actif, souvent sous 10 secondes. Presque jamais le bon choix en production — à ce stade vous payez l’instance pour ne rien faire.

Quand les warm pools gagnent leur place :

  • AMI lourdes par nécessité. Une AMI de 12 Go prend du temps à se provisionner dans le cache du magasin d’instance. Un warm pool sort ce provisionnement du chemin critique du scale-out.
  • Démarrage long. Scripts de données utilisateur qui tirent des images de conteneurs, exécutent des migrations, vont chercher des secrets dans SSM, s’enregistrent au service discovery. Tout ce qui passe 60 secondes de démarrage est un candidat.
  • Charges en rafale avec exigences de scale-out vives. Envois marketing, ouvertures de billetterie, batchs planifiés avec SLA strict sur le temps de complétion.
  • Runtimes sensibles au chauffage de JVM ou autres. Une machine qui vient de démarrer a des caches froids et un JIT non optimisé. L’hibernation préserve l’état mémoire chauffé.

Quand les warm pools sont mauvais :

  • Charges diurnes douces. Si votre scale-out se déclenche 20 minutes avant le pic et rampe sur une heure, les quatre minutes de démarrage ne pèsent pas. Le coût du warm pool est gaspillé.
  • Charges avec déploiements de code fréquents. Chaque déploiement d’une nouvelle AMI invalide le warm pool ; les instances cyclent, vous payez la re-chauffe, le tampon est vide jusqu’à ce que les nouvelles soient prêtes. Faisable mais ajoute du frottement.
  • Petites flottes. Un warm pool de 2 instances et un ASG qui scale 1-à-la-fois est surconçu. Le seuil tourne autour de « ASG avec au moins 10 instances et des événements de scale-out notables ».

Comment vérifier

Vérifier si un warm pool est configuré sur un ASG :

aws autoscaling describe-warm-pool \
  --auto-scaling-group-name my-burst-asg \
  --output json

Si pas de warm pool, l’appel retourne un objet WarmPool vide. Un warm pool configuré retourne son état, sa taille min, sa capacité préparée max, et l’état du pool (Stopped, Hibernated, ou Running).

Pour voir le contenu réel du warm pool :

aws autoscaling describe-warm-pool \
  --auto-scaling-group-name my-burst-asg \
  --query 'Instances[].[InstanceId,LifecycleState]' \
  --output table

États de cycle de vie pour une instance warm : Warmed:Pending, Warmed:Pending:Wait, Warmed:Pending:Proceed, Warmed:InService, Warmed:Hibernated, Warmed:Stopped. Warmed:InService est l’état prêt-à-transitionner — c’est là que vous voulez que le pool soit stable.

Pour chronométrer la transition warm-vers-actif (la métrique qui compte), regarder les activités de scaling et le delta lancement-vers-InService de l’instance :

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name my-burst-asg \
  --max-items 20 \
  --query 'Activities[?contains(Description, `Warm`)].[StartTime,EndTime,Description]' \
  --output table

Une transition de warm pool saine se complète en 30 à 60 secondes pour Stopped, 15 à 30 pour Hibernated. Si vous voyez des transitions plus longues, le lifecycle hook warm-vers-actif est le suspect — habituellement il attend le grace-period du LB plutôt que de faire du vrai travail.

La correction

Le motif de lifecycle hook qui prépare correctement une instance warm :

  1. Deux hooks, deux phases. Un hook EC2_INSTANCE_LAUNCHING se déclenche quand l’instance est créée et entre dans le warm pool. Un autre EC2_INSTANCE_LAUNCHING se déclenche quand l’instance passe de warm à actif. Même nom de hook, mais phase de cycle de vie différente. Votre script de hook doit vérifier Origin et Destination dans le message pour savoir quelle phase il traite.

  2. En phase warm, faire le démarrage lent : tirer les images de conteneurs, exécuter les migrations comme contrôle, aller chercher la configuration de base dans SSM, enregistrer les métriques de base dans CloudWatch. L’instance n’est pas encore dans le LB, donc pas d’inquiétude trafic. Utiliser le timeout de hook complet (une heure) au besoin.

  3. En phase warm-vers-actif, faire seulement le travail rapide et sensible au temps : tirer la dernière configuration (au cas où elle a changé pendant la chauffe), démarrer les processus applicatifs, signaler la disponibilité au LB, s’enregistrer au service discovery. Tout ce qui peut être fait au moment warm devrait déjà être fait.

Configurer le warm pool sur un ASG existant :

aws autoscaling put-warm-pool \
  --auto-scaling-group-name my-burst-asg \
  --min-size 4 \
  --max-group-prepared-capacity 8 \
  --pool-state Stopped \
  --instance-reuse-policy ReuseOnScaleIn=true

Champ par champ :

  • min-size : le nombre minimum d’instances warm à garder en tout temps. 4 veut dire que l’ASG a toujours 4 instances arrêtées prêtes, même quand la flotte active est à son minimum.
  • max-group-prepared-capacity : total actif + warm. 8 veut dire que l’ASG tient actif+warm à 8 quand sous ce nombre. Une fois que la flotte active dépasse 8, plus de réapprovisionnement warm tant que ça ne redescend pas. Ça plafonne le coût.
  • pool-state : Stopped pour la plupart des cas, Hibernated pour les runtimes sensibles au chauffage.
  • instance-reuse-policy : ReuseOnScaleIn=true veut dire que le scale-in rend l’instance au warm pool au lieu de la terminer. Utile pour des motifs diurnes où vous scalez la nuit et remontez le matin — les mêmes instances cyclent, pas de re-démarrage.

Le lifecycle hook pour la phase warm-vers-actif :

aws autoscaling put-lifecycle-hook \
  --auto-scaling-group-name my-burst-asg \
  --lifecycle-hook-name warm-to-active \
  --lifecycle-transition autoscaling:EC2_INSTANCE_LAUNCHING \
  --heartbeat-timeout 300 \
  --default-result ABANDON \
  --notification-target-arn arn:aws:sqs:us-east-1:123456789012:asg-events \
  --role-arn arn:aws:iam::123456789012:role/asg-lifecycle-role

Le script sur l’instance, écoutant SQS ou piloté par EventBridge, lit le message, vérifie les champs Origin / Destination, fait le travail approprié, et complète le hook :

aws autoscaling complete-lifecycle-action \
  --auto-scaling-group-name my-burst-asg \
  --lifecycle-hook-name warm-to-active \
  --lifecycle-action-token "${TOKEN}" \
  --lifecycle-action-result CONTINUE \
  --instance-id "${INSTANCE_ID}"

Le piège du timeout d’une heure : les lifecycle hooks ont un maximum d’une heure, point. Si votre démarrage en phase warm prend plus long (il ne devrait pas, mais les AMI lourdes avec hydratation complète de données parfois oui), il faut étendre avec des appels record-lifecycle-action-heartbeat pendant le travail, chacun réinitialisant le minuteur. Oubliez les heartbeats et le hook expire, l’instance passe à Pending:Wait indéfiniment, et le warm pool refuse de grandir.

Trois règles de dimensionnement du warm pool :

Min-size du warm pool = pic en rafale moins flotte active en régime permanent, arrondi au-dessus. Si le pire cas est un saut soudain de 10 actifs à 18 actifs, le warm pool a besoin d’au moins 8 instances prêtes. Plus grand si vous devez aussi absorber une deuxième rafale avant que le re-chauffage soit complet.

Max-group-prepared-capacity plafonne le coût total. Le régler à la taille max de l’ASG ou juste en dessous. Le warm pool ne grandira pas au-delà, ce qui empêche le warm pool de doubler votre facture si le max de l’ASG est élevé.

Le réapprovisionnement n’est pas instantané. Quand l’ASG tire une instance du warm pool vers l’actif, le warm pool tombe sous min-size et démarre un nouveau lancement. Ce lancement prend le temps de démarrage original complet. Si les rafales arrivent dos à dos, la deuxième peut trouver le warm pool vide. Dimensionner pour le pire-cas-dos-à-dos si votre charge a ce motif.

Toute la mécanique vaut le temps de mise en place quand AMI + démarrage dépassent 90 secondes et que la charge a des événements de scale-out vifs. Sous ce seuil, une cuisson d’AMI plus rapide et des données utilisateur plus minces donnent le même résultat avec moins de pièces mobiles.

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.