Mise à l'échelle des charges de calcul
Groupes Auto Scaling, politiques target tracking et prédictives, lifecycle hooks et instance refresh, et mise à l'échelle d'ECS, EKS et Lambda.
La mise à l'échelle pose toujours les mêmes trois questions : quel est le plancher, quel est le plafond, et qu'est-ce qui décide du nombre entre les deux. Ce sujet répond à ces questions d'abord pour des instances EC2, puis pour des tâches, des pods et des requêtes. Les quatre leçons vont de la mécanique d'un groupe Auto Scaling jusqu'aux couches de scaling d'ECS, d'EKS et de Lambda, en passant par tout ce qui se joue entre la décision d'ajouter une instance et l'instance qui sert réellement du trafic.
Ce que couvre ce sujet
- Les trois nombres de capacité d'un groupe Auto Scaling, les launch templates, les sources de health check et la grace period qui protège les démarrages lents
- L'équilibre entre zones de disponibilité, la politique de terminaison par défaut, la protection contre le scale in et la suspension de processus
- Les cinq façons de faire bouger la capacité desired : manuelle, planifiée, target tracking, step scaling et predictive scaling
- La différence entre une période de cooldown et un instance warmup, et la règle d'arbitrage quand plusieurs politiques visent le même groupe
- Les états du cycle de vie d'une instance, les lifecycle hooks de lancement et de terminaison, les warm pools, standby et detach
- L'instance refresh : pourcentages d'instances saines, skip matching, checkpoints, bake time et auto rollback, avec les défauts qui changent entre console et CLI
- Application Auto Scaling, les deux couches de scaling d'un cluster ECS sur EC2, la métrique CapacityProviderReservation et le cas Fargate
- Les couches de scaling d'EKS, puis la concurrency Lambda avec les quotas, le rythme de montée et le choix entre reserved et provisioned concurrency
Pourquoi c'est important
La compétence 2.1.1 du SOA-C03 parle de mécanismes de mise à l'échelle dans les environnements de calcul, au pluriel, et l'examen exploite ce pluriel. Les énoncés décrivent un symptôme (des instances relancées en boucle, une capacité qui n'arrive jamais, des tâches figées en PROVISIONING, une fonction throttlée bien sous sa limite) et attendent que vous rattachiez ce symptôme à la bonne couche avant de choisir un correctif.
C'est aussi le sujet où les valeurs par défaut coûtent le plus cher en production. Une health check grace period à 0 en CLI, un groupe qui n'écoute que les status checks EC2, un warm pool dimensionné sur un maximum d'urgence, un instance refresh bloqué par une instance en standby : chacun de ces incidents vient d'un réglage que personne n'a choisi. Connaître les défauts vaut ici autant que connaître les fonctionnalités.