Einführung
Eine Anwendung braucht manchmal mehr und später weniger Server. Du definierst zwei Richtlinien, erweiterst von zwei auf drei und kehrst zu zwei zurück. Du prüfst echte HTTP-Antworten und wie Gruppengrenzen weitere Änderungen verhindern.
Du solltest Startvorlagen, Auto Scaling-Gruppen und ALB-Prüfungen kennen. Die neue Umgebung liefert eine unabhängige gesunde Gruppe application-fleet mit zwei Instanzen, Vorlage, Netzwerk und ALB. Frühere Ressourcen werden nicht wiederverwendet.
Prüfungsbezug
Einführende Praxis für SAA-C03 Domain 2 und SOA-C03 Domain 2: Kapazität, Skalierungsaktionen und Load-Balancer-Integration.
Skalierungsrichtlinien definieren
Du prüfst die Gruppe und erstellst Richtlinien ohne Kapazitätsänderung.
Wechsle ins Arbeitsverzeichnis und prüfe die Startkapazität:
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"
Erwarte Minimum 2, Wunsch 2, Maximum 3 und zwei gesunde Ziele in AWS View. Eine Skalierungsrichtlinie definiert eine Anpassung. ChangeInCapacity ändert eine absolute Zahl: 1 fügt einen Server hinzu, -1 entfernt einen.
Erstelle zwei SimpleScaling-Richtlinien. Eine Abkühlzeit lässt eine Aktion normalerweise abschließen, bevor eine weitere Alarmaktion folgt. Speichere hier 30 Sekunden:
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}'
Das Erstellen führt Richtlinien nicht aus. Dieses Lab nutzt --no-honor-cooldown für kontrollierte Änderungen. Zeitliche Cooldown-Durchsetzung und CloudWatch-Alarme werden nicht gezeigt. In Produktion verwenden metrische Richtlinien Alarme; Target Tracking folgt einem Zielwert. Automatische Rückkopplung und CPU-Last werden hier nicht geprüft.
Auf drei Server erweitern
Du führst die positive Richtlinie aus und prüfst echte Antworten des zusätzlichen Servers.
Scale-out fügt Instanzen hinzu. Führe die Richtlinie aus und warte auf 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}'
Erwarte Kapazität 3 und drei aktuelle IDs. Die Gruppe startet den neuen Server aus der Vorlage und registriert ihn automatisch.
Führe dieselbe Richtlinie am Maximum erneut aus und prüfe die Kapazität:
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}'
Die Kapazität bleibt 3; die Anpassung überschreitet das Gruppenmaximum nicht. Die Grenze betrifft Serverzahl, nicht Anfragen pro Server.
Sende neun Anfragen und vergleiche IDs mit den drei aktuellen Instanzen:
for request in 1 2 3 4 5 6 7 8 9; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Öffne AWS View. Prüfe Wunsch 3, drei gesunde Ziele und echte 200-Antworten aller IDs mit Send request. Eine zusätzliche API-Ressource beweist keine Verkehrsverarbeitung.
Beispiel: Wunschkapazität drei, der zusätzliche Server liefert HTTP 200. Deine IDs unterscheiden sich.
Reduzieren und das Minimum erhalten
Du reduzierst die Kapazität und bestätigst zwei verfügbare Server.
Scale-in entfernt Instanzen. Führe die negative Richtlinie aus und warte auf gesunde aktuelle Ziele:
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}'
Erwarte zwei aktuelle IDs und eine Instanz terminated. Die Gruppe wählt den entfernten Server; nicht immer den neuesten. Er darf nicht mehr zu den aktiven Zielen gehören.
Führe die negative Richtlinie am Minimum erneut aus und prüfe die Kapazität:
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}'
Wunsch bleibt 2; die Richtlinie unterschreitet das Minimum nicht. Sende sechs Anfragen an die verbleibende Gruppe:
for request in 1 2 3 4 5 6; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Prüfe in AWS View zwei gesunde Ziele und 200-Antworten beider aktuellen IDs. Die beendete ID darf nicht in neuen Antworten erscheinen. Geprüft werden Lebenszyklus und Routing, keine Entleerungszeit oder Sitzungserhaltung.
Richtlinien entfernen und vorbereitete Gruppe erhalten
Du löschst deine Richtlinien, nachdem die Gruppe wieder zwei Server besitzt.
Lösche beide Richtlinien und prüfe den verbleibenden Bestand:
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}'
Die Richtlinienliste sollte [] sein, die Gruppe Minimum 2, Wunsch 2, Maximum 3. Richtlinienlöschung beendet die vorhandenen Server nicht. Behalte Gruppe, Vorlage, ALB und Netzwerk; AWS View zeigt weiterhin zwei gesunde Server.
Zusammenfassung
Du hast positive und negative einfache Richtlinien erstellt, echte Erweiterung von zwei auf drei und Reduktion auf zwei beobachtet und beide Grenzen geprüft. Echte HTTP-Antworten und native Beendigung bestätigten das Ergebnis. Anschließend wurden Richtlinien entfernt und die Gruppe erhalten.
Du unterscheidest Konfiguration, ausdrückliche Ausführung und metrische Auslösung. Die Challenge nutzt Routing- und Zustandsdiagnose für einen neuen Server ohne Verkehr.
