Skalierungsrichtlinien: Target Tracking und Step Scaling

Eine statische gewünschte Kapazität funktioniert bei konstantem Datenverkehr, aber der Datenverkehr in der Praxis schwankt. Mit Scaling-Richtlinien kann eine Auto Scaling Group die gewünschte Kapazität automatisch anhand von Metriken anpassen. AWS bietet drei zentrale dynamische Richtlinientypen: Target Tracking, Step Scaling und Simple Scaling. Für die SAA-C03-Prüfung sind Target Tracking und Step Scaling besonders wichtig.

Target Tracking Scaling funktioniert wie ein Thermostat: Sie geben eine Metrik und einen Zielwert an, und AWS berechnet automatisch, wie viele Instances hinzugefügt oder entfernt werden müssen, damit die Metrik bei diesem Zielwert bleibt. Wenn Sie beispielsweise eine durchschnittliche CPU-Auslastung von 50 % anstreben und die Auslastung auf 80 % steigt, fügt die ASG genügend Instances hinzu, um die CPU-Auslastung wieder auf 50 % zu bringen. AWS verwaltet sowohl das Auf- als auch das Herunterskalieren für Sie.

Target Tracking unterstützt standardmäßig mehrere vordefinierte Metriken: ASGAverageCPUUtilization, ASGAverageNetworkIn, ASGAverageNetworkOut und die ALB-spezifische Metrik ALBRequestCountPerTarget. Für anwendungsspezifische KPIs (Warteschlangentiefe, aktive Verbindungen, benutzerdefinierte Geschäftsmetriken) können Sie eine benutzerdefinierte CloudWatch-Metrik angeben. Benutzerdefinierte Metriken ermöglichen eine deutlich genauere Steuerung der Faktoren, die Ihre Skalierungsentscheidungen auslösen.

Nach einem Aufskalierungsereignis wartet die ASG eine Abkühlzeit (standardmäßig 300 Sekunden), bevor sie ein weiteres Aufskalieren bewertet. Dadurch erhalten neu gestartete Instances Zeit, Datenverkehr zu verarbeiten, sodass sich die Metrik stabilisieren kann. Ebenso verhindert eine Abkühlzeit beim Herunterskalieren, dass unmittelbar nach dem Hinzufügen von Kapazität Instances vorzeitig beendet werden. Für Target Tracking empfiehlt AWS außerdem eine Aufwärmzeit, damit neue Instances die Metrik nicht beeinflussen, bevor sie vollständig initialisiert sind.

Step Scaling reagiert auf CloudWatch-Alarme, indem abhängig davon, wie weit die Metrik einen Schwellenwert überschreitet, eine bestimmte Anzahl von Instances hinzugefügt oder entfernt wird. Sie definieren mehrere Schrittanpassungen; jeder Schritt deckt einen Metrikbereich ab und legt eine Kapazitätsänderung fest. Beispiel: Bei einer CPU-Auslastung von 60–70 % wird 1 Instance hinzugefügt, bei 70–90 % werden 3 Instances hinzugefügt und bei über 90 % werden 5 Instances hinzugefügt. So erhalten Sie abgestufte, verhältnismäßige Reaktionen auf unterschiedliche Lastniveaus.

Step Scaling erfordert einen bereits vorhandenen CloudWatch-Alarm. Der Alarm überwacht eine Metrik und wechselt in den Status ALARM, wenn ein Schwellenwert überschritten wird. Die Scaling-Richtlinie verwendet anschließend Schrittanpassungen, die anhand des Metrikwerts relativ zum Alarmschwellenwert ausgewählt werden. Sie können festlegen, ob der Anpassungstyp ChangeInCapacity (N hinzufügen), ExactCapacity (auf N setzen) oder PercentChangeInCapacity (um N % skalieren) lautet.

Jede Schrittanpassung verfügt über eine MetricIntervalLowerBound und optional über eine MetricIntervalUpperBound. Die Grenzen beziehen sich auf den Alarmschwellenwert. Wenn der Alarmschwellenwert bei 60 % CPU liegt, wird LowerBound=0, UpperBound=10 bei einer CPU-Auslastung von 60–70 % ausgelöst; LowerBound=10, UpperBound=null wird bei einer CPU-Auslastung von über 70 % ausgelöst. Dieser gestufte Ansatz stellt sicher, dass starke Lastspitzen sofort eine umfangreiche Kapazitätserhöhung auslösen, statt mehrere Alarmzyklen abzuwarten.

Simple Scaling ist der Vorgänger von Step Scaling. Wie Step Scaling erfordert es einen CloudWatch-Alarm, fügt bei dessen Auslösung jedoch eine feste Anzahl von Instances hinzu oder entfernt sie und wartet anschließend, bis die gesamte Abkühlzeit abgelaufen ist, bevor es erneut bewertet. Dadurch reagiert es bei schnell wechselnder Last träge. Step Scaling wird bevorzugt, weil es bei einer Verschärfung der Bedingungen weiterhin ausgelöst werden kann, ohne die vollständige Abkühlzeit abzuwarten, und proportional reagiert.

Manchmal möchten Sie verhindern, dass bestimmte Instances beim Herunterskalieren beendet werden – beispielsweise eine Instance, auf der ein lang laufender Batchauftrag ausgeführt wird. Sie können den Scale-In-Schutz für Instances über die Konsole oder die CLI für einzelne Instances aktivieren. Wenn die ASG Kandidaten für die Beendigung auswählt, überspringt sie geschützte Instances. Denken Sie daran, den Schutz nach Abschluss des Auftrags zu entfernen. Andernfalls kann die ASG möglicherweise überhaupt nicht herunterskalieren, wenn alle Instances geschützt sind.

Sie können eine ASG mit mehreren Scaling-Richtlinien verknüpfen. Wenn sowohl eine Target-Tracking- als auch eine Step-Scaling-Richtlinie vorhanden ist, verwendet die ASG die Richtlinie, die die größere Aufskalierungsmaßnahme empfiehlt (die konservativere Option). Beim Herunterskalieren setzt sich die Richtlinie durch, die das Entfernen der geringsten Anzahl von Instances empfiehlt. Dadurch wird verhindert, dass das System zwischen einer Über- und einer Unterversorgung schwankt. Ein gängiges Muster ist eine Target-Tracking-Richtlinie für den Normalbetrieb und eine Step-Scaling-Richtlinie zum Schutz vor Notfall-Lastspitzen.

Beginnen Sie bei den meisten Webanwendungen mit Target Tracking für CPU oder die Anzahl der Anforderungen pro Ziel. Dafür ist nur eine minimale Konfiguration erforderlich, und AWS übernimmt die Berechnungen. Verwenden Sie Step Scaling, wenn Sie abgestufte, verhältnismäßige Reaktionen auf unterschiedliche Lastintensitäten benötigen. Legen Sie die minimale Kapazität immer so hoch fest, dass der Grundlastverkehr ohne Aufskalieren bewältigt werden kann, da das Skalieren Zeit benötigt. Überwachen Sie die CloudWatch-Metriken GroupDesiredCapacity und GroupInServiceInstances, um zu überprüfen, ob Ihre Richtlinien erwartungsgemäß funktionieren.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Target Tracking Scaling berechnet und führt automatisch Auf- und Herunterskalierungsmaßnahmen aus, um eine Metrik bei einem gewünschten Wert zu halten (z. B. 50 % CPU); Step Scaling löst proportional größere Reaktionen aus, wenn eine Metrik höhere Schwellenwerte überschreitet, und verwendet dafür auf CloudWatch-Alarmen basierende Schrittanpassungen; und das Kombinieren von Richtlinien in einer ASG ist sicher – die ASG verwendet die konservativste Empfehlung zum Aufskalieren und die am wenigsten aggressive Empfehlung zum Herunterskalieren. Als Nächstes sehen wir uns geplante und prädiktive Skalierung für bekannte Datenverkehrsmuster an.