Introduction
Une application peut nécessiter davantage de serveurs, puis moins. Vous définirez deux politiques, passerez de deux à trois serveurs puis reviendrez à deux. Vous vérifierez les réponses HTTP réelles et l’effet des limites de capacité.
Vous devez connaître modèles, groupes Auto Scaling et contrôles ALB. Cet environnement neuf fournit le groupe indépendant sain application-fleet de deux instances, son modèle, réseau et répartiteur. Aucun ancien laboratoire n’est réutilisé.
Liens avec les certifications
Pratique introductive de SAA-C03 Domain 2 et SOA-C03 Domain 2 : capacité Auto Scaling, actions de mise à l’échelle et intégration ALB.
Définir les politiques
Vous examinerez la flotte et créerez des politiques sans changer sa capacité.
Entrez dans le dossier et examinez la capacité initiale :
cd /home/labex/project
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'
TG_ARN=$(aws elbv2 \
describe-target-groups \
--names application-targets \
--query 'TargetGroups[0].TargetGroupArn' \
--output text)
LB_DNS=$(aws elbv2 \
describe-load-balancers \
--names application-alb \
--query 'LoadBalancers[0].DNSName' \
--output text)
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
Attendez minimum 2, souhaité 2, maximum 3 et deux cibles saines dans AWS View. Une politique de mise à l’échelle définit un ajustement. ChangeInCapacity change un nombre absolu : 1 ajoute un serveur ; -1 en retire un.
Créez deux politiques SimpleScaling. Le délai de refroidissement permet normalement de stabiliser une action avant la suivante déclenchée par alarme. Enregistrez 30 secondes :
aws autoscaling \
put-scaling-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server \
--policy-type SimpleScaling \
--adjustment-type ChangeInCapacity \
--scaling-adjustment 1 \
--cooldown 30
aws autoscaling \
put-scaling-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server \
--policy-type SimpleScaling \
--adjustment-type ChangeInCapacity \
--scaling-adjustment -1 \
--cooldown 30
aws autoscaling \
describe-policies \
--auto-scaling-group-name application-fleet \
--query 'ScalingPolicies[].{Name:PolicyName,Type:PolicyType,Adjustment:ScalingAdjustment,Cooldown:Cooldown}'
Créer une politique ne l’exécute pas. Ici, --no-honor-cooldown permet des transitions contrôlées. Le respect temporel du cooldown et les alarmes CloudWatch ne sont pas démontrés. En production, les politiques métriques utilisent des alarmes ; target tracking suit une valeur cible. Aucune boucle automatique ni charge CPU n’est testée.
Passer à trois serveurs
Vous exécuterez la politique positive et vérifierez que le serveur supplémentaire répond réellement.
Le scale-out ajoute des instances. Exécutez la politique et attendez ALB :
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server \
--no-honor-cooldown
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'
Attendez capacité 3 et trois IDs actuels. Le groupe utilise son modèle pour le nouveau serveur et l’enregistre automatiquement.
Exécutez à nouveau la politique au maximum puis examinez la capacité :
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server \
--no-honor-cooldown
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Desired:DesiredCapacity,Max:MaxSize,Instances:Instances[].InstanceId}'
La capacité reste 3 ; l’ajustement ne dépasse pas le maximum du groupe. Cette limite concerne les serveurs, pas les requêtes par serveur.
Envoyez neuf requêtes et comparez les IDs aux trois instances actuelles :
for request in 1 2 3 4 5 6 7 8 9; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Ouvrez AWS View. Confirmez souhaité 3, trois cibles saines et réponses réelles 200 des trois IDs avec Send request. Une ressource ajoutée dans l’API ne prouve pas qu’elle traite le trafic.
Exemple : capacité souhaitée trois, le serveur supplémentaire renvoie HTTP 200. Vos IDs seront différents.
Réduire et conserver le minimum
Vous réduirez la capacité et confirmerez que deux serveurs restent disponibles.
Le scale-in retire des instances. Exécutez la politique négative et attendez les cibles saines :
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server \
--no-honor-cooldown
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Instances:Instances[].InstanceId}'
aws ec2 \
describe-instances \
--filters "Name=tag:aws:autoscaling:groupName,Values=application-fleet" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'
Attendez deux IDs actuels et une instance terminated. Le groupe choisit l’instance retirée ; ce n’est pas forcément la plus récente. Elle ne doit plus appartenir aux cibles actives.
Exécutez à nouveau la politique négative au minimum puis examinez la capacité :
aws autoscaling \
execute-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server \
--no-honor-cooldown
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Instances:Instances[].InstanceId}'
La capacité reste 2 ; la politique ne descend pas sous le minimum. Envoyez six requêtes pour tester la flotte restante :
for request in 1 2 3 4 5 6; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Dans AWS View, confirmez deux cibles saines et réponses 200 des IDs actuels. L’ID terminé ne doit pas apparaître dans les nouvelles réponses. L’exercice teste cycle de vie et routage, sans mesurer drainage ni conservation des sessions.
Supprimer les politiques et garder la flotte
Vous supprimerez les politiques après avoir restauré la flotte fournie à deux serveurs.
Supprimez les deux politiques et examinez l’inventaire restant :
aws autoscaling \
delete-policy \
--auto-scaling-group-name application-fleet \
--policy-name add-one-server
aws autoscaling \
delete-policy \
--auto-scaling-group-name application-fleet \
--policy-name remove-one-server
aws autoscaling \
describe-policies \
--auto-scaling-group-name application-fleet \
--query 'ScalingPolicies[].PolicyName'
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Max:MaxSize}'
La liste doit être [], et le groupe minimum 2, souhaité 2, maximum 3. Supprimer les politiques ne termine pas les instances existantes. Conservez groupe, modèle, ALB et réseau ; AWS View doit afficher deux serveurs sains.
Résumé
Vous avez défini des politiques simples positives et négatives, observé le passage réel de deux à trois puis à deux et testé les limites. Vous avez vérifié HTTP réel et terminaison native, puis supprimé les politiques en gardant la flotte restaurée.
Vous distinguez configuration, exécution explicite et déclenchement métrique. Le défi applique le diagnostic du routage et des contrôles à un nouveau serveur sans trafic.
