Von Amazon ECS verwaltetes Skalierungsverhalten

Wenn Sie Auto Scaling Scaling-Gruppenkapazitätsanbieter haben, die verwaltete Skalierung verwenden, schätzt Amazon ECS die optimale Anzahl von Instances, die Sie Ihrem Cluster hinzufügen können, und bestimmt anhand des Werts, wie viele Instances angefordert oder veröffentlicht werden müssen.

Verhalten für die verwaltete Skalierung nach oben

Amazon ECS wählt für jede Aufgabe einen Kapazitätsanbieter aus und folgt dabei der Kapazitätsanbieterstrategie des Service, der eigenständigen Aufgabe oder der Cluster-Standardeinstellung. Amazon ECS folgt den restlichen Schritten für einen einzelnen Kapazitätsanbieter.

Aufgaben ohne Kapazitätsanbieterstrategie werden von Kapazitätsanbietern ignoriert. Eine ausstehende Aufgabe, für die es keine Kapazitätsanbieterstrategie gibt, führt bei keinem Kapazitätsanbieter zum Aufskalieren. Aufgaben oder Services können keine Strategie für einen Kapazitätsanbieter festlegen, wenn diese Aufgabe oder dieser Service einen Starttyp festlegt.

Im Folgenden wird das Scale-Out-Verhalten detaillierter beschrieben.

• Gruppieren Sie alle Bereitstellungsaufgaben für diesen Kapazitätsanbieter so, dass jede Gruppe genau die gleichen Ressourcenanforderungen hat.

• Wenn Sie mehrere Instance-Typen in einer Auto-Scaling-Gruppe verwenden, werden die Instance-Typen in der Auto-Scaling-Gruppe nach ihren Parametern sortiert. Zu diesen Parametern gehören vCPU, Speicher, elastische Netzwerkschnittstellen (ENIs), Ports und GPUs. Die kleinsten und größten Instance-Typen für jeden Parameter werden ausgewählt. Weitere Informationen zur Auswahl des Instance-Typs finden Sie unter EC2 Amazon-Container-Instances für Amazon ECS.

  Wichtig

  Wenn eine Gruppe von Aufgaben einen Ressourcenbedarf hat, der größer ist als der kleinste Instance-Typ in der Auto-Scaling-Gruppe, dann kann diese Gruppe von Aufgaben nicht mit diesem Kapazitätsanbieter ausgeführt werden. Der Kapazitätsanbieter skaliert die Auto-Scaling-Gruppe nicht. Die Aufgaben verbleiben im Status PROVISIONING.

  Um zu verhindern, dass Aufgaben im Status PROVISIONING verbleiben, empfehlen wir Ihnen, separate Auto-Scaling-Gruppen und Kapazitätsanbieter für unterschiedliche Mindestressourcenanforderungen zu erstellen. Wenn Sie Aufgaben ausführen oder Services erstellen, fügen Sie nur Kapazitätsanbieter zur Kapazitätsanbieterstrategie hinzu, die die Aufgabe auf dem kleinsten Instance-Typ in der Auto-Scaling-Gruppe ausführen können. Für andere Parameter können Sie Platzierungsbeschränkungen verwenden

• Für jede Aufgabengruppe berechnet Amazon ECS die Anzahl der Instances, die zum Ausführen der nicht platzierten Aufgaben erforderlich sind. Diese Berechnung verwendet eine binpack-Strategie. Diese Strategie berücksichtigt die vCPU, den Arbeitsspeicher, die Elastic Network Interfaces (ENI), die Ports und die GPUs Anforderungen der Aufgaben. Es berücksichtigt auch die Ressourcenverfügbarkeit der EC2 Amazon-Instances. Die Werte für die größten Instance-Typen werden als maximale berechnete Instance-Anzahl behandelt. Die Werte für den kleinsten Instance-Typ werden als Schutz verwendet. Wenn der kleinste Instance-Typ nicht mindestens eine Instance der Aufgabe ausführen kann, betrachtet die Berechnung die Aufgabe als nicht kompatibel. Daher wird die Aufgabe von der Aufskalierungsberechnung ausgeschlossen. Wenn alle Aufgaben nicht mit dem kleinsten Instance-Typ kompatibel sind, stoppt das Auto Scaling des Clusters und der Wert CapacityProviderReservation bleibt auf dem Wert targetCapacity.

• Amazon ECS veröffentlicht die CapacityProviderReservation Metrik in CloudWatch Bezug darauf, minimumScalingStepSize ob einer der folgenden Punkte zutrifft.

  • Die maximale berechnete Instance-Anzahl ist geringer als die minimale Skalierungsschrittgröße.

  • Der niedrigere Wert der maximumScalingStepSize oder der maximalen berechneten Instanzanzahl.

• CloudWatch Alarme verwenden die CapacityProviderReservation Metrik für Kapazitätsanbieter. Wenn die CapacityProviderReservation-Metrik größer als der targetCapacity-Wert ist, erhöhen Alarme auch die DesiredCapacity der Auto-Scaling-Gruppe. Der targetCapacity Wert ist eine Einstellung des Kapazitätsanbieters, die während der Aktivierungsphase für die auto Skalierung des Clusters an den CloudWatch Alarm gesendet wird.

  Die Standardeinstellung targetCapacity ist 100%.

• Die Auto Scaling Scaling-Gruppe startet zusätzliche EC2 Instances. Um eine übermäßige Bereitstellung zu verhindern, stellt Auto Scaling sicher, dass die Kapazität der kürzlich gestarteten EC2 Instances stabilisiert wird, bevor neue Instances gestartet werden. Auto Scaling prüft, ob alle vorhandenen Instances die instanceWarmupPeriod (jetzt abzüglich der Startzeit der Instance) überschritten haben. Das Scale-Out ist für Instances blockiert, die sich innerhalb von befinden. instanceWarmupPeriod

  Die Standardanzahl von Sekunden für das Aufwärmen einer neu gelaunchten Instance beträgt 300.

Weitere Informationen finden Sie unter Detaillierte Informationen zum Auto Scaling von Amazon-ECS-Clustern.

Überlegungen zum Aufskalieren

Berücksichtigen Sie Folgendes für den Aufskalierungs-Prozess:

• Obwohl es mehrere Platzierungs-Einschränkungen gibt, empfehlen wir, dass Sie nur die distinctInstance-Einschränkung für die Aufgabenplatzierung nutzen. Dies verhindert, dass der Aufskalierungs-Prozess angehalten wird, da Sie eine Platzierungs-Einschränkung verwenden, die nicht mit den Stichproben-Instances kompatibel ist.

• Die verwaltete Skalierung funktioniert am besten, wenn Ihre Auto-Scaling-Gruppe dieselben oder ähnliche Instance-Typen verwendet.

• Wenn ein Aufskalierungsprozess erforderlich ist und derzeit keine Container-Instances laufen, skaliert Amazon ECS zunächst immer auf zwei Instances und führt dann weitere Aufskalierungs- oder Abskalierungsprozesse durch. Bei jedem weiteren Aufskalieren wird auf die Aufwärmphase der Instance gewartet. Bei Aufskalierungsprozessen wartet Amazon ECS nach einem Aufskalierungsprozess immer 15 Minuten, bevor Abskalierungsprozesse gestartet werden.

• Der zweite Aufskalierungs-Schritt muss warten, bis das instanceWarmupPeriod abläuft, was sich auf die Gesamtskalierungsgrenze auswirken kann. Wenn Sie diese Zeit reduzieren müssen, stellen Sie sicher, dass sie groß genug instanceWarmupPeriod ist, damit die EC2 Instance den Amazon ECS-Agenten starten und starten kann (wodurch eine Überbereitstellung verhindert wird).

• Cluster-Auto-Scaling unterstützt Startkonfiguration, Startvorlagen und mehrere Instance-Typen in der Auto-Scaling-Gruppe des Kapazitätsanbieters. Sie können auch die attributbasierte Instance-Typauswahl ohne mehrfache Instance-Typen verwenden.

• Wenn Sie eine Auto-Scaling-Gruppe mit On-Demand-Instances und mehreren Instance-Typen oder Spot-Instances verwenden, platzieren Sie die größeren Instance-Typen höher in der Prioritätsliste und geben Sie keine Gewichtung an. Die Angabe einer Gewichtung wird derzeit nicht unterstützt. Weitere Informationen finden Sie unter Auto-Scaling-Gruppen mit mehreren Instance-Typen im AWS Auto Scaling -Benutzerhandbuch.

• Amazon ECS startet dann entweder minimumScalingStepSize, wenn die maximal berechnete Instance-Anzahl kleiner als die minimale Skalierungsschrittgröße ist, oder den niedrigeren Wert von maximumScalingStepSize oder der maximal berechneten Instance-Anzahl.

• Wenn ein Amazon ECS-Service oder eine Aufgabe run-task startet und die Container-Instances des Kapazitätsanbieters nicht über genügend Ressourcen verfügen, um die Aufgabe zu starten, begrenzt Amazon ECS die Anzahl der Aufgaben mit diesem Status für jeden Cluster und verhindert, dass Aufgaben dieses Limit überschreiten. Weitere Informationen finden Sie unter Amazon-ECS-Service-Kontingente.

Verwaltetes Abskalierungs-Verhalten

Amazon ECS überwacht Container-Instances für jeden Kapazitätsanbieter in einem Cluster. Wenn eine Container-Instance keine Aufgaben ausführt, gilt die Container-Instance als leer und Amazon ECS startet den Abskalierungsprozess.

CloudWatch Scale-In-Alarme benötigen 15 Datenpunkte (15 Minuten), bevor der Scale-In-Prozess für die Auto Scaling Scaling-Gruppe beginnt. Nachdem der Abskalierungs-Prozess gestartet wurde, bis Amazon ECS die Anzahl der angemeldeten Container-Instances reduzieren muss, legt die Auto-Scaling-Gruppe fest, dass der DesireCapacity-Wert größer als eine Instance und weniger als 50 % pro Minute sein soll.

Wenn Amazon ECS eine Aufskalierung anfordert (wenn CapacityProviderReservation größer als 100 ist), während ein Abskalierungs-Prozess durchgeführt wird, wird der Abskalierungs-Prozess angehalten und bei Bedarf von Neuem gestartet.

Im Folgenden wird das Abskalierungsverhalten im Detail beschrieben:

1. Amazon ECS berechnet die Anzahl der leeren Container-Instances. Eine Container-Instance gilt als leer, auch wenn keine Daemon-Aufgaben ausgeführt werden.

2. Amazon ECS setzt den Wert CapacityProviderReservation auf eine Zahl zwischen 0–100, die anhand der folgenden Formel das Verhältnis zwischen der erforderlichen Größe der Auto-Scaling-Gruppe und der tatsächlichen Größe darstellt, ausgedrückt in Prozent. Anschließend veröffentlicht Amazon ECS die Metrik für CloudWatch. Weitere Informationen darüber, wie die Metrik berechnet wird, finden Sie unter Deep Dive im Cluster-Auto-Scaling von Amazon-ECS

   CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100

3. Die CapacityProviderReservation Metrik generiert einen CloudWatch Alarm. Dieser Alarm aktualisiert den DesiredCapacity-Wert für die Auto-Scaling-Gruppe. Anschließend wird eine der folgenden Aktionen ausgeführt:

   • Wenn Sie die vom Kapazitätsanbieter verwaltete Terminierung nicht verwenden, wählt die Auto Scaling Scaling-Gruppe EC2 Instances mithilfe der Auto Scaling Scaling-Gruppenbeendigungsrichtlinie aus und beendet die Instances, bis die Anzahl der EC2 Instances den DesiredCapacity erreicht. Die Container-Instances werden dann vom Cluster abgemeldet.

   • Wenn alle Container-Instances einen verwalteten Beendigungsschutz verwenden, entfernt Amazon ECS den Abskalierungsschutz für leere Container-Instances. Die Auto Scaling Scaling-Gruppe kann dann die EC2 Instances beenden. Die Container-Instances werden dann vom Cluster abgemeldet.