Ein Dienst auf Amazon ECS vergleicht in festen Abständen die gemessene CPU- oder Speicherauslastung mit einer Zielvorgabe und ändert danach die Anzahl seiner Tasks. Standardmäßig liegt zwischen zwei Messungen eine Minute. Bei plötzlichen Lastspitzen entscheidet dieses Intervall darüber, wie lange Nutzer auf Antworten warten oder in Timeouts laufen. Bei ECS Service Auto Scaling zählt damit die Messfrequenz stärker als die Regelkonfiguration.
Wer Skalierung für Container plant, muss zwei getrennte Zeiträume auseinanderhalten: die Zeit bis eine Regel einen Scale-out beschließt, und die Zeit bis die zusätzlichen Tasks tatsächlich Last aufnehmen. Die von AWS veröffentlichten Benchmark-Zahlen zeigen, dass beide Größen zusammenhängen, aber nicht gleich schnell besser werden. Sie erklären auch, warum überprovisionierte Kapazität oft keine Vorsicht ist, sondern eine Reaktion auf träge Messwerte.
Target Tracking arbeitet wie ein Thermostat mit langsamer Messung
Target Tracking ist die einfachste Form der Skalierung auf Amazon ECS: Du wählst einen Zielwert für eine Metrik, etwa 60 Prozent durchschnittliche CPU-Auslastung, und ECS fügt Tasks hinzu oder entfernt sie, um den Dienst in der Nähe dieses Werts zu halten. Alarme und Step-Scaling-Regeln musst du nicht selbst pflegen, weil der Mechanismus vollständig verwaltet läuft. Das reicht für die meisten Arbeitslasten.
Nimm als Bild einen Thermostat, der die Raumtemperatur nur einmal pro Minute misst. Steigt die Wärme schnell, reagiert die Heizung erst, wenn der Raum längst zu warm ist, und pendelt danach über das Ziel hinaus. Wer weiß, dass sein Thermometer träge ist, heizt vorsorglich auf Reserve – im Containerbetrieb sind das zusätzliche Tasks, die dauerhaft laufen, obwohl sie nur während der Skalierungsverzögerung gebraucht werden. Diese Lücke nennen viele Teams Überprovisionierung.
Bei gleichmäßigem, langsam steigendem Traffic fällt das kaum auf, weil eine Minute Messabstand im Verhältnis zur Lastkurve kurz genug ist. Bei einem plötzlichen Sprung kann ein Dienst dagegen mehrere Minuten brauchen, bis er die Änderung erkennt und Kapazität ergänzt. In dieser Zeit bedient er Anfragen langsam oder gar nicht.
Zwei Änderungen: feinere Metriken und ein kürzerer Publishing-Pfad
ECS veröffentlicht CPU- und Speicherauslastung jetzt zusätzlich zur Standardauflösung von 60 Sekunden in einer Auflösung von 20 Sekunden. AWS Application Auto Scaling nutzt diese hochauflösenden Metriken für Target Tracking, sodass das Bestätigungsfenster für eine Skalierungsentscheidung nur noch Sekunden statt Minuten umfasst. Der Dienst kann damit deutlich früher entscheiden, Kapazität hinzuzufügen.
Häufigere Datenpunkte helfen allerdings nur, wenn sie auch schnell genug ankommen. Deshalb hat ECS den Pfad optimiert, der eine Messung von einem laufenden Task bis zur verfügbaren CloudWatch-Metrik transportiert. Jeder Wert wird dadurch mit deutlich geringerer Verzögerung veröffentlicht. Die Skalierungsregel sieht die aktuelle Last nahezu in dem Moment, in dem sie entsteht. Beide Änderungen wirken zusammen: mehr Messpunkte und aktuellere Messpunkte.
Die in der Ankündigung veröffentlichten Zahlen trennen die beiden Effekte. Die Zeit bis zum Auslösen eines Scale-out sank um 76 Prozent, von 363 auf 86 Sekunden; die Zeit vom Auslösen bis zum Platzieren der neuen Tasks fiel um 72 Prozent, von 386 auf 109 Sekunden. Der erste Wert beschreibt die Entscheidung, der zweite die Ausführung. In der Gegenüberstellung der Lastkurven folgt ein Dienst mit 20-Sekunden-Metriken der Anfragerate eng, während ein Dienst mit 60-Sekunden-Metriken in großen Stufen nachzieht, die Spitze überschießt und nach dem Abflauen nur langsam Kapazität zurückgibt.
Wie AWS die Skalierung vermessen hat
Die belastbareren Zahlen stammen nicht aus der Mechanik, sondern aus einem standardisierten Lasttest mit einer realen Anwendung. Das AWS-Benchmarking-Team verglich dieselbe Konfiguration einmal mit 60-Sekunden- und einmal mit 20-Sekunden-Metriken, auf Amazon ECS mit AWS Fargate und mit ECS Managed Instances. Der Test lief in der Region US West (Oregon) mit amd64-Tasks von je einer vCPU, Target Tracking auf 60 Prozent durchschnittlicher CPU-Auslastung und einer Spanne von 1 bis 128 Tasks.
Die Last erzeugte k6 als ansteigende Ankunftsrate entlang einer Glockenkurve, alle 30 Sekunden neu gesetzt, mit bis zu 32.000 virtuellen Nutzern und einem Request-Timeout von 90 Sekunden. Jede Anfrage berechnete eine Monte-Carlo-Schätzung von Varianz und Median über 100.000 Stichproben einer abgeschnittenen Normalverteilung, in der jeweiligen Sprache umgesetzt. Ausgewertet wurde der Median über 24 Läufe pro Profil.
Drei Profile stehen für unterschiedliche Realanwendungen: Ein Rust-Dienst auf dem Rocket-Framework startet schnell, braucht rund 1 Millisekunde pro Anfrage und wächst über 30 Minuten von etwa 200 auf 20.000 Anfragen pro Sekunde, bevor er über weitere 30 Minuten abflaut. Ein Java-Dienst mit rund 10 Millisekunden Rechenzeit pro Anfrage durchläuft drei Zyklen von je zehn Minuten Anstieg und Abfall zwischen etwa 40 und 4.000 Anfragen pro Sekunde und benötigt JVM-Warmlaufzeit – der Worst Case für Kaltstarts. Ein Node.js-Dienst mit etwa 15 Millisekunden pro Anfrage hält die Last zehn Minuten niedrig, steigt über 50 Minuten, hält zehn Minuten und fällt dann abrupt von rund 2.000 auf 20 Anfragen pro Sekunde.
Die wichtigste Metrik war die SLA-Verletzungszeit: die Summe aller 6-Sekunden-Fenster, in denen mehr als zehn Prozent der Anfragen scheiterten. Als Fehler zählte alles über zwei Sekunden Antwortzeit, jeder Fehlercode und jede verworfene Anfrage. Die Zwei-Sekunden-Grenze ist bewusst streng gewählt, weil reale Timeouts erst bei 90 Sekunden greifen. Gemessen werden sollte die Zeit, in der Nutzer tatsächlich Probleme hatten, nicht nur die Zeit bis zur Skalierung.
SLA-Verletzungen und Rückbau in Zahlen
Beim Rust-Profil mit graduellem Anstieg fiel die SLA-Verletzungszeit auf Fargate um 69 Prozent, von 2.013 auf 633 Sekunden, also von etwa 34 auf 11 Minuten. Auf Managed Instances sank sie um 98 Prozent, von 1.692 auf 30 Sekunden. Beim Java-Profil mit wiederholten Spitzen ging sie auf Fargate um 49 Prozent zurück, von 2.232 auf 1.131 Sekunden, und auf Managed Instances um 53 Prozent, von 1.593 auf 750 Sekunden. Beim Node.js-Profil mit stetem Wachstum fiel sie auf Fargate von 750 auf 3 Sekunden und auf Managed Instances von 969 auf 102 Sekunden – Rückgänge von 99 und 89 Prozent.
Beim Rückbau nach dem Peak ändern sich die Werte ebenfalls deutlich. Im Rust-Profil sank die Scale-down-Dauer auf Fargate von 1.943 auf 42 Sekunden und auf Managed Instances von 2.343 auf 37 Sekunden, jeweils ein Rückgang um 98 Prozent – aus über einer halben Stunde wurde weniger als eine Minute. Im Java-Profil fiel sie auf Fargate von 4.120 auf 2.102 Sekunden und auf Managed Instances von 2.091 auf 1.679 Sekunden, im Node.js-Profil von 3.853 auf 2.803 Sekunden beziehungsweise von 3.680 auf 1.878 Sekunden.
Die beiden letzten Profile profitieren beim Rückbau weniger, weil sie den Traffic abrupt beenden und den schnelleren Metriken damit ein kürzeres Zeitfenster bleibt, in dem sie überhaupt etwas ändern können. Die Streuung war ebenfalls geringer: Mit 20-Sekunden-Metriken lieferten wiederholte Läufe nahezu dieselben Ergebnisse, während die 60-Sekunden-Variante deutlich stärker schwankte. Für Kapazitätsentscheidungen ist planbare Skalierung oft wertvoller als ein einzelner guter Spitzenwert.
Warum Managed Instances stärker profitieren als Fargate
Auf ECS Managed Instances laufen mehrere Tasks pro Instanz, sodass ECS einen neuen Task auf einer bereits laufenden Instanz mit freier Kapazität platzieren kann. In diesem Fall muss keine neue Instanz bereitgestellt werden, und das Container-Image liegt häufig schon aus früheren Task-Starts im Cache dieser Instanz. Der Schritt von der Entscheidung zur laufenden Kapazität wird dadurch kurz. Deshalb treten die größten Verbesserungen der SLA-Verletzungszeit dort auf.
Auf Fargate läuft jeder Task in einer eigenen, isolierten Umgebung, die ECS bei Bedarf bereitstellt und in die das Image erst geladen werden muss. Das kostet Zeit in jedem Skalierungsschritt, unabhängig von der Messfrequenz. Die schnelleren Metriken beschleunigen also für beide Rechenoptionen die Entscheidung gleichermaßen; Managed Instances setzen diese Entscheidung nur früher in laufende Kapazität um.
Was das für Kapazitätsreserve und Antwortzeiten bedeutet
Der wichtigste Effekt in der Praxis: Endnutzer erleben kürzere Zeit langsame oder fehlgeschlagene Anfragen. Wenn ein Dienst früher reagiert, gerät er gar nicht erst so weit ins Hintertreffen, und die Spitze muss nicht erst durch einen Rückstand hindurch abgearbeitet werden. Für dich als Betreiber heißt das: Der Puffer, den du bisher als Sicherheitsmarge vorgehalten hast, lässt sich reduzieren, ohne dass die Antwortzeiten leiden.
Es gibt aber Grenzen. Bei Diensten mit langsamer Initialisierung, etwa JVM-Warmlaufzeit, bleibt die Zeit bis zur Arbeitsfähigkeit eines neuen Tasks bestehen, auch wenn der Entschluss früher fällt. Bei Lastprofilen, die abrupt enden, bringt die feinere Messung beim Rückbau weniger, weil die Kapazität ohnehin schnell überflüssig wird. Und feinere CloudWatch-Metriken haben eine eigene Metrik-Klasse mit anderer Preislogik, die du gegen die eingesparte Reservekapazität rechnen solltest.
Für die meisten Dienste mit unregelmäßigen Lastspitzen bleibt die Rechnung einfach: Zwischen 20 und 60 Sekunden Messabstand liegt der Unterschied zwischen einem Thermostat, der die Temperatur im Raum hält, und einem, der sie erst bemerkt, wenn alle schon schwitzen. Amazon ECS Auto Scaling wird damit nicht intelligenter, aber deutlich kürzer blind – und dieser Teil entscheidet bei Container-Skalierung meist über die Latenz.
Quelle: aws.amazon.com
