Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Bewährte Methoden für Auto Scaling und Kapazitätsmanagement in Amazon ECS
Sie können containerisierte Anwendungs-Workloads aller Größen in Amazon ECS ausführen. Dazu gehören minimale Testumgebungen und große Produktionsumgebungen, die auf globaler Ebene betrieben werden.
Bei Amazon ECS zahlen Sie, wie bei allen AWS Services, nur für das, was Sie tatsächlich nutzen. Wenn Sie Ihre Anwendung entsprechend entwerfen, können Sie Kosten sparen, indem Sie nur die Ressourcen nutzen, die Sie benötigen, wenn Sie sie benötigen.
Die folgenden Empfehlungen zeigen Ihnen, wie Sie Ihre Amazon-ECS-Workloads ausführen, um Ihre Service Level Objectives zu erreichen und gleichzeitig kostengünstig zu arbeiten.
**Topics**
+ [
# Bestimmung der Aufgabengröße für Amazon ECS
](capacity-tasksize-best-practice.md)
+ [
# Optimierung von Service-Auto-Scaling von Amazon ECS
](capacity-autoscaling-best-practice.md)
+ [
# Kapazität und Verfügbarkeit von Amazon ECS
](capacity-availability-best-practice.md)
+ [
# Amazon-ECS-Cluster-Kapazität
](capacity-cluster-best-practice.md)
+ [
# Auswahl der Fargate-Aufgabengrößen für Amazon ECS
](fargate-task-size-best-practice.md)
+ [
# Beschleunigung der Kapazitätsbereitstellung für Amazon-ECS-Cluster mit Kapazitätsanbietern in Amazon EC2
](capacity-cluster-speed-up-ec2-best-practice.md)
# Bestimmung der Aufgabengröße für Amazon ECS
Eine der wichtigsten Optionen bei der Bereitstellung von Containern in Amazon ECS sind Ihre Container- und Aufgabengrößen. Sowohl Ihre Container- als auch Ihre Aufgabengröße sind für die Skalierung und Kapazitätsplanung von entscheidender Bedeutung.
Amazon ECS verwendet zwei Ressourcenmetriken für Kapazität: CPU und Arbeitsspeicher. Amazon ECS misst CPU in Einheiten von 1/1 024 einer vollen vCPU (wobei 1 024 Einheiten einer ganzen vCPU entsprechen). Amazon ECS misst Arbeitsspeicher in Megabyte.
In Ihrer Aufgabendefinition können Sie Ressourcenreservierungen und -limits angeben.
Wenn Sie eine Reservierung angeben, geben Sie die Mindestmenge an Ressourcen an, die eine Aufgabe benötigt. Ihre Aufgabe erhält mindestens die Menge an Ressourcen, die Sie anfordern. Ihre Anwendung kann möglicherweise mehr CPU oder Arbeitsspeicher beanspruchen als die von Ihnen angegebene Reservierung. Dies unterliegt jedoch allen Limits, die Sie ebenfalls angegeben haben.
Wenn Sie mehr als den Reservierungsbetrag verwenden, wird dies als Bursting bezeichnet. Bursting bedeutet, dass Ihre Anwendung mehr Ressourcen verbraucht, als Sie reserviert haben, aber innerhalb der angegebenen Limits bleibt. Amazon ECS garantiert Reservierungen. Wenn Sie beispielsweise Amazon-EC2-Instances verwenden, um Kapazität bereitzustellen, platziert Amazon ECS keine Aufgabe auf einer Instance, bei der die Reservierung nicht erfüllt werden kann.
Ein Limit ist die maximale Menge an CPU-Einheiten oder Arbeitsspeicher, die Ihr Container oder Ihre Aufgabe verwenden kann. Wenn Ihr Container versucht, mehr CPU als diesen Grenzwert zu verwenden, drosselt Amazon ECS ihn. Wenn Ihr Container versucht, mehr Arbeitsspeicher als diesen Grenzwert zu verwenden, stoppt Amazon ECS Ihren Container.
Die Auswahl dieser Werte kann eine Herausforderung darstellen. Welche Werte für Ihre Anwendung am besten geeignet sind, hängen stark von den Ressourcenanforderungen Ihrer Anwendung ab.
Auslastungstests Ihrer Anwendung sind der Schlüssel zu einer erfolgreichen Planung des Ressourcenbedarfs. Auslastungstests helfen Ihnen dabei, die Anforderungen Ihrer Anwendung besser zu verstehen.
## Statusslose Anwendungen
Für zustandslose Anwendungen, die horizontal skaliert werden, wie z. B. eine Anwendung hinter einem Load Balancer, empfehlen wir, dass Sie zunächst ermitteln, wie viel Arbeitsspeicher Ihre Anwendung bei der Bearbeitung von Anfragen verbraucht.
Zu diesem Zweck können Sie herkömmliche Tools wie `ps` oder `top` verwenden. Sie können auch Überwachungslösungen wie CloudWatch Container Insights verwenden.
Wenn Sie eine CPU-Reservierung festlegen, sollten Sie überlegen, wie Sie Ihre Anwendung skalieren möchten, um Ihre Geschäftsanforderungen zu erfüllen.
Sie können kleinere CPU-Reservierungen, wie z. B. 256 CPU-Einheiten (oder 1/4 vCPU), verwenden, um feinkörnig aufzuskalieren und so die Kosten zu minimieren. Ihre Anwendung kann jedoch möglicherweise nicht schnell genug skaliert werden, um erhebliche Nachfragespitzen zu bewältigen.
Sie können größere CPU-Reservierungen verwenden, um schneller auf- und abzuskalieren. Auf diese Weise können Sie Nachfragespitzen schneller ausgleichen. Größere CPU-Reservierungen kosten jedoch mehr.
## Andere Anwendungen
Bei Anwendungen, die nicht horizontal skaliert werden können, wie z. B. Singleton Worker oder Datenbankserver, sind die verfügbaren Kapazitäten und Kosten Ihre wichtigsten Überlegungen.
Wählen Sie die Größe des Arbeitsspeichers und der CPU auf der Grundlage der Belastungstests aus, die Sie benötigen, um den Datenverkehr zu bedienen und Ihr Service Level Objectives zu erreichen. Amazon ECS stellt sicher, dass Ihre Anwendung auf einem Host mit ausreichender Kapazität platziert wird.
# Optimierung von Service-Auto-Scaling von Amazon ECS
Ein Amazon-ECS-Service ist eine verwaltete Sammlung von Aufgaben. Jedem Service ist eine Aufgabendefinition, eine gewünschte Anzahl von Aufgaben und eine optionale Platzierungsstrategie zugeordnet.
Service-Auto-Scaling von Amazon ECS funktioniert über den Application-Auto-Scaling-Service. Application Auto Scaling verwendet CloudWatch Metriken als Quelle für Skalierungsmetriken. Es verwendet auch CloudWatch Alarme, um Schwellenwerte dafür festzulegen, wann Ihr Service erweitert oder verkleinert werden soll.
Sie geben die Schwellenwerte für die Skalierung an. Sie können ein metrisches Ziel festlegen, das als *Skalierung der Ziel-Nachverfolgung* bezeichnet wird. Sie können auch Schwellenwerte angeben, was als *schrittweise Skalierung* bezeichnet wird.
Nachdem Sie Application Auto Scaling konfiguriert haben, berechnet es kontinuierlich die entsprechende gewünschte Anzahl an Aufgaben für den Service. Der Service benachrichtigt Amazon ECS auch, wenn sich die gewünschte Anzahl an Aufgaben ändern sollte, entweder durch Auf- oder Abskalieren.
Um Service-Auto-Scaling effektiv nutzen zu können, müssen Sie eine geeignete Skalierungsmetrik auswählen. In den folgenden Abschnitten wird erläutert, wie Sie eine Metrik auswählen.
## Charakterisierung Ihrer Anwendung
Um eine Anwendung richtig zu skalieren, müssen Sie die Bedingungen kennen, unter denen Sie Ihre Anwendung skalieren und wann Sie sie skalieren sollten.
Im Wesentlichen sollten Sie Ihre Anwendung skalieren, wenn prognostiziert wird, dass die Nachfrage die Kapazität übersteigt. Umgekehrt können Sie Ihre Anwendung skalieren, um Kosten zu sparen, wenn die Ressourcen den Bedarf übersteigen.
### Identifizieren einer Nutzungsmetrik
Für eine effektive Skalierung müssen Sie eine Metrik identifizieren, die auf Auslastung oder Sättigung hinweist. Diese Metrik muss die folgenden Eigenschaften aufweisen, um für die Skalierung nützlich zu sein.
+ Die Metrik muss mit der Nachfrage korreliert sein. Wenn Sie die Ressourcen konstant halten, sich aber der Bedarf ändert, muss sich auch der Metrikwert ändern. Die Metrik sollte steigen oder sinken, wenn die Nachfrage steigt oder sinkt.
+ Der metrische Wert muss proportional zur Kapazität abskaliert werden. Wenn die Nachfrage konstant bleibt, muss das Hinzufügen weiterer Ressourcen zu einer proportionalen Änderung des Metrikwerts führen. Eine Verdoppelung der Anzahl der Aufgaben sollte also zu einer Verringerung der Metrik um 50 % führen.
Der beste Weg, eine Nutzungsmetrik zu ermitteln, sind Belastungstests in einer Vorproduktionsumgebung, wie z. B. einer Staging-Umgebung. Kommerzielle und Open-Source-Lösungen für Lasttests sind weit verbreitet. Diese Lösungen können in der Regel entweder synthetische Last erzeugen oder echten Benutzerverkehr simulieren.
Um mit dem Auslastungstest zu beginnen, sollten Sie zunächst Dashboards für die Nutzungsmetriken Ihrer Anwendung erstellen. Zu diesen Kennzahlen gehören CPU-Auslastung, Speicherauslastung, I/O Betriebsabläufe, I/O Warteschlangentiefe und Netzwerkdurchsatz. Sie können diese Metriken mit einem Service wie CloudWatch Container Insights sammeln. Sie können die Metriken auch erfassen, indem Sie Amazon Managed Service für Prometheus zusammen mit Amazon Managed Grafana verwenden. Stellen Sie während dieses Prozesses sicher, dass Sie Kennzahlen zu den Antwortzeiten oder den Abschlussquoten Ihrer Anwendung erfassen und grafisch darstellen.
Beginnen Sie beim Auslastungstest mit einer geringen Anzahl von Anfragen oder Auftrags-Injektionsrate. Halten Sie diese Rate mehrere Minuten lang konstant, damit sich Ihre Anwendung aufwärmen kann. Erhöhen Sie dann langsam die Geschwindigkeit und halten Sie sie einige Minuten lang konstant. Wiederholen Sie diesen Zyklus und erhöhen Sie die Rate jedes Mal, bis die Antwort- oder Abschlusszeiten Ihrer Anwendung zu langsam sind, um Ihre Service-Level-Ziele zu erreichen (SLOs).
Untersuchen Sie beim Belastungstest die einzelnen Nutzungsmetriken. Die Metriken, die mit der Auslastung steigen, eignen sich am besten als Ihre besten Nutzungsmetriken.
Identifizieren Sie als Nächstes die Ressource, deren Sättigung erreicht ist. Untersuchen Sie gleichzeitig auch die Nutzungsmetriken, um festzustellen, welche sich auf hoher Ebene zuerst abflachen. Oder untersuchen Sie zuerst, welches System seinen Höhepunkt erreicht und dann Ihre Anwendung zum Absturz bringt. Wenn die CPU-Auslastung beispielsweise von 0 % auf 70–80 % steigt, wenn Sie mehr Last hinzufügen, dann kann man mit Sicherheit sagen, dass die CPU ausgelastet ist. Je nach CPU-Architektur erreicht die Auslastung möglicherweise nie 100 %. Gehen Sie beispielsweise davon aus, dass die Speicherauslastung zunimmt, wenn Sie mehr Last hinzufügen, und Ihre Anwendung dann plötzlich abstürzt, wenn sie das Speicherlimit für Aufgaben oder Amazon-EC2-Instances erreicht. In dieser Situation ist es wahrscheinlich der Fall, dass der Arbeitsspeicher vollständig verbraucht wurde. Möglicherweise werden mehrere Ressourcen von Ihrer Anwendung verwendet. Wählen Sie daher die Metrik aus, die die Ressource darstellt, die zuerst erschöpft ist.
Versuchen Sie abschließend erneut, die Auslastung zu testen, nachdem Sie die Anzahl der Aufgaben oder Amazon-EC2-Instances verdoppelt haben. Gehen Sie davon aus, dass die Schlüsselmetrik halb so schnell wie zuvor steigt oder sinkt. Wenn dies der Fall ist, ist die Metrik proportional zur Kapazität. Dies ist eine gute Nutzungsmetrik für Auto Scaling.
Betrachten Sie nun dieses hypothetische Szenario. Nehmen wir an, Sie führen einen Auslastungstest für eine Anwendung durch und stellen fest, dass die CPU-Auslastung bei 100 Anfragen pro Sekunde irgendwann 80 % erreicht. Wenn Sie mehr Last hinzufügen, erhöht sich die CPU-Auslastung nicht mehr. Dadurch reagiert Ihre Anwendung jedoch langsamer. Dann führen Sie den Auslastungstest erneut durch und verdoppeln dabei die Anzahl der Aufgaben, halten aber die Geschwindigkeit auf dem vorherigen Spitzenwert. Wenn Sie feststellen, dass die durchschnittliche CPU-Auslastung auf etwa 40 % sinkt, ist die durchschnittliche CPU-Auslastung ein guter Kandidat für eine Skalierungsmetrik. Bleibt die CPU-Auslastung dagegen bei 80 %, nachdem die Anzahl der Aufgaben erhöht wurde, ist die durchschnittliche CPU-Auslastung keine gute Skalierungsmetrik. In diesem Fall benötigen Sie mehr Nachforschungen, um eine geeignete Metrik zu finden.
### Allgemeine Anwendungsmodelle und Skalierungseigenschaften
Sie können Software aller Art in AWS ausführen. Viele Workloads sind selbst entwickelt, während andere auf beliebter Open-Source-Software basieren. Unabhängig davon, woher sie stammen, haben wir einige gängige Entwurfsmuster für Services beobachtet. Wie Sie effektiv skalieren, hängt zu einem großen Teil vom Muster ab.
#### Der effiziente CPU-gebundene Server
Der effiziente CPU-gebundene Server nutzt fast keine anderen Ressourcen als den CPU- und Netzwerkdurchsatz. Jede Anfrage kann von der Anwendung alleine bearbeitet werden. Anfragen hängen nicht von anderen Services wie Datenbanken ab. Die Anwendung kann Hunderttausende von gleichzeitigen Anfragen verarbeiten und dafür mehrere CPUs effizient nutzen. Jede Anfrage wird entweder von einem dedizierten Thread mit geringem Arbeitsspeicheraufwand bedient, oder es gibt eine asynchrone Ereignisschleife, die auf jeder CPU läuft, die Anfragen bearbeitet. Jedes Replikat der Anwendung ist gleichermaßen in der Lage, eine Anfrage zu verarbeiten. Die einzige Ressource, die vor der CPU aufgebraucht sein könnte, ist die Netzwerkbandbreite. Bei CPU-gebundenen Services macht die Speicherauslastung selbst bei Spitzendurchsatz nur einen Bruchteil der verfügbaren Ressourcen aus.
Sie können CPU-basiertes Auto Scaling für diese Art von Anwendung verwenden. Die Anwendung bietet maximale Flexibilität in Bezug auf die Skalierung. Sie können es vertikal skalieren, indem Sie größere Amazon EC2 EC2-Instances oder Fargate V CPUs bereitstellen. Sie können auch horizontal skalieren, indem Sie weitere Replikate hinzufügen. Durch das Hinzufügen weiterer Replikate oder die Verdoppelung der Instance-Größe kann die durchschnittliche CPU-Auslastung im Verhältnis zur Kapazität um die Hälfte reduziert werden.
Wenn Sie Amazon-EC2-Kapazität für diese Anwendung verwenden, sollten Sie erwägen, sie auf für Datenverarbeitung optimierte Instances wie die `c5`- oder `c6g`-Familie zu platzieren.
#### Der effiziente arbeitsspeichergebundene Server
Der effiziente arbeitsspeichergebundene Server weist pro Anforderung eine beträchtliche Menge an Arbeitsspeicher zu. Bei maximaler Nebenläufigkeit, aber nicht unbedingt bei Durchsatz, wird der Arbeitsspeicher erschöpft, bevor die CPU-Ressourcen aufgebraucht sind. Der einer Anforderung zugeordnete Arbeitsspeicher wird freigegeben, wenn die Anforderung endet. Zusätzliche Anforderungen können akzeptiert werden, solange Arbeitsspeicher verfügbar ist.
Sie können arbeitsspeicherbasiertes Auto Scaling für diese Art von Anwendung verwenden. Die Anwendung bietet maximale Flexibilität in Bezug auf die Skalierung. Sie können es sowohl vertikal skalieren, indem Sie größere Amazon-EC2- oder Fargate-Arbeitsspeicherressourcen zur Verfügung stellen. Sie können auch horizontal skalieren, indem Sie weitere Replikate hinzufügen. Durch das Hinzufügen weiterer Replikate oder die Verdoppelung der Instance-Größe kann die durchschnittliche Speicherauslastung im Verhältnis zur Kapazität um die Hälfte reduziert werden.
Wenn Sie Amazon-EC2-Kapazität für diese Anwendung verwenden, sollten Sie erwägen, sie auf arbeitsspeicheroptimierte Instances wie die `r5`- oder `r6g`-Familie zu platzieren.
Einige arbeitsspeichergebundene Anwendungen geben den Arbeitsspeicher, der einer Anforderung zugeordnet ist, nicht frei, wenn diese beendet ist, sodass eine Verringerung der Nebenläufigkeit nicht zu einer Verringerung des verwendeten Arbeitsspeichers führt. Aus diesem Grund wird empfohlen, keine arbeitsspeicherbasierte Skalierung zu verwenden.
#### Der Worker-basierte Server
Der Worker-basierte Server verarbeitet nacheinander eine Anfrage für jeden einzelnen Worker-Thread. Bei den Worker-Threads kann es sich um leichtgewichtige Threads wie POSIX-Threads handeln. Sie können auch Threads mit höherem Gewicht sein, wie z. B. UNIX-Prozesse. Unabhängig davon, um welchen Thread es sich handelt, gibt es immer eine maximale Nebenläufigkeit, die die Anwendung unterstützen kann. Normalerweise wird das Limit für die Nebenläufigkeit proportional zu den verfügbaren Arbeitsspeicherressourcen festgelegt. Wenn das Limit für die Nebenläufigkeit erreicht ist, platziert die Anwendung zusätzliche Anfragen in einer Backlog-Warteschlange. Wenn die Backlog-Warteschlange überläuft, lehnt die Anwendung sofort weitere eingehende Anfragen ab. Zu den gängigen Anwendungen, die diesem Muster entsprechen, gehören der Apache Webserver und Gunicorn.
Die Nebenläufigkeit von Anfragen ist normalerweise die beste Metrik für die Skalierung dieser Anwendung. Da es für jedes Replikat ein Limit für die Nebenläufigkeit gibt, ist es wichtig, eine Aufskalierung vorzunehmen, bevor das durchschnittliche Limit erreicht wird.
Der beste Weg, Metriken zur Parallelität von Anfragen zu erhalten, besteht darin, sie von Ihrer Anwendung melden zu lassen. CloudWatch Jedes Replikat Ihrer Anwendung kann die Anzahl der gleichzeitigen Anfragen als benutzerdefinierte Metrik mit hoher Frequenz veröffentlichen. Wir empfehlen, die Frequenz auf mindestens einmal pro Minute einzustellen. Nachdem mehrere Berichte gesammelt wurden, können Sie die durchschnittliche Nebenläufigkeit als Skalierungsmetrik verwenden. Sie berechnen diese Metrik, indem Sie die gesamte Nebenläufigkeit durch die Anzahl der Replikate dividieren. Wenn beispielsweise die Gesamtzahl der Nebenläufigkeit 1 000 beträgt und die Anzahl der Replikate 10 beträgt, beträgt die durchschnittliche Nebenläufigkeit 100.
Wenn Ihre Anwendung hinter einem Application Load Balancer steht, können Sie die `ActiveConnectionCount`-Metrik für den Load Balancer auch als Faktor in der Skalierungsmetrik verwenden. Sie müssen die `ActiveConnectionCount`-Metrik durch die Anzahl der Replikate dividieren, um einen Durchschnittswert zu erhalten. Sie müssen den Durchschnittswert für die Skalierung verwenden und nicht den reinen Zählwert.
Damit dieses Design optimal funktioniert, sollte die Standardabweichung der Antwortlatenz bei niedrigen Anforderungsraten gering sein. Wir empfehlen, dass in Zeiten geringer Nachfrage die meisten Anfragen innerhalb kurzer Zeit beantwortet werden, und es gibt nicht viele Anfragen, deren Beantwortung deutlich länger als der Durchschnitt dauert. Die durchschnittliche Antwortzeit sollte in der Nähe des 95. Perzentils der Antwortzeit liegen. Andernfalls kann es zu Warteschlangenüberläufen kommen. Dies führt zu Fehlern. Wir empfehlen, dass Sie bei Bedarf zusätzliche Replikate bereitstellen, um das Risiko eines Überlaufs zu minimieren.
#### Der wartende Server
Der wartende Server verarbeitet jede Anfrage in gewissem Maße, ist jedoch in hohem Maße von einem oder mehreren nachgelagerten Services abhängig, damit er funktioniert. Container-Anwendungen nutzen häufig stark nachgelagerte Services wie Datenbanken und andere API-Services. Es kann einige Zeit dauern, bis diese Services reagieren, insbesondere in Szenarien mit hoher Kapazität oder hoher Nebenläufigkeit. Dies liegt daran, dass diese Anwendungen in der Regel nur wenige CPU-Ressourcen verwenden und gleichzeitig den verfügbaren Arbeitsspeicher maximal ausnutzen.
Der wartende Server eignet sich entweder für das speichergebundene Servermuster oder das Worker-basierte Servermuster, je nachdem, wie die Anwendung konzipiert ist. Wenn die Nebenläufigkeit der Anwendung nur durch den Arbeitsspeicher begrenzt ist, sollte die durchschnittliche Speicherauslastung als Skalierungsmetrik verwendet werden. Wenn die Nebenläufigkeit der Anwendung auf einem Worker-Limit basiert, sollte die durchschnittliche Nebenläufigkeit als Skalierungsmetrik verwendet werden.
#### Der Java-basierte Server
Wenn Ihr Java-basierter Server CPU-gebunden ist und proportional zu den CPU-Ressourcen skaliert, ist er möglicherweise für das effiziente CPU-gebundene Servermuster geeignet. Wenn das der Fall ist, könnte die durchschnittliche CPU-Auslastung als Skalierungsmetrik geeignet sein. Viele Java-Anwendungen sind jedoch nicht CPU-gebunden, was ihre Skalierung schwierig macht.
Für eine optimale Leistung empfehlen wir, dem Java Virtual Machine (JVM)-Heap so viel Arbeitsspeicher wie möglich zuzuweisen. Neuere Versionen der JVM, einschließlich Java 8 Update 191 oder höher, legen die Heap-Größe automatisch so groß wie möglich fest, damit sie in den Container passt. Das bedeutet, dass in Java die Speicherauslastung selten proportional zur Anwendungsauslastung ist. Mit steigender Anforderungsrate und Nebenläufigkeit bleibt die Speicherauslastung konstant. Aus diesem Grund empfehlen wir nicht, Java-basierte Server auf der Grundlage der Speicherauslastung zu skalieren. Stattdessen empfehlen wir in der Regel, je nach CPU-Auslastung zu skalieren.
In einigen Fällen kommt es bei Java-basierten Servern zu einer Heap-Erschöpfung, bevor die CPU-Auslastung erreicht wird. Wenn Ihre Anwendung bei hoher Nebenläufigkeit zur Heap-Erschöpfung neigt, sind durchschnittliche Verbindungen die beste Skalierungsmetrik. Wenn Ihre Anwendung bei hohem Durchsatz zur Heap-Erschöpfung neigt, sind durchschnittliche Anforderungsraten die beste Skalierungsmetrik.
#### Server, die andere Garbage-Collection-Laufzeiten verwenden
Viele Serveranwendungen wie .NET und Ruby basieren auf Laufzeiten, die Garbage Collection durchführen. Diese Serveranwendungen passen möglicherweise in eines der zuvor beschriebenen Muster. Wie bei Java empfehlen wir jedoch nicht, diese Anwendungen auf der Grundlage des Arbeitsspeichers zu skalieren, da ihre beobachtete durchschnittliche Speicherauslastung oft nicht mit dem Durchsatz oder der Nebenläufigkeit übereinstimmt.
Für diese Anwendungen empfehlen wir, die CPU-Auslastung entsprechend zu skalieren, wenn die Anwendung CPU-gebunden ist. Andernfalls empfehlen wir, die Skalierung auf der Grundlage Ihrer Lasttestergebnisse auf der Grundlage des durchschnittlichen Durchsatzes oder der durchschnittlichen Nebenläufigkeit durchzuführen.
#### Auftragsprozessoren
Viele Workloads beinhalten asynchrone Auftragsverarbeitung. Dazu gehören Anwendungen, die Anfragen nicht in Echtzeit empfangen, sondern stattdessen eine Arbeitswarteschlange abonnieren, um Aufträge zu erhalten. Für diese Art von Anwendungen ist die richtige Skalierungsmetrik fast immer die Warteschlangentiefe. Ein Anstieg der Warteschlange ist ein Hinweis darauf, dass die ausstehende Arbeit die Verarbeitungskapazität übersteigt, wohingegen eine leere Warteschlange darauf hindeutet, dass mehr Kapazität als zu erledigende Arbeit vorhanden ist.
AWS Messaging-Dienste wie Amazon SQS und Amazon Kinesis Data Streams bieten CloudWatch Metriken, die für die Skalierung verwendet werden können. Für Amazon SQS ist `ApproximateNumberOfMessagesVisible` die beste Metrik. Für Kinesis Data Streams sollten Sie die `MillisBehindLatest`-Metrik verwenden, die von der Kinesis Client Library (KCL) veröffentlicht wurde. Diese Metrik sollte für alle Verbraucher gemittelt werden, bevor sie für die Skalierung verwendet wird.
# Kapazität und Verfügbarkeit von Amazon ECS
Die Verfügbarkeit von Anwendungen ist entscheidend für ein fehlerfreies Erlebnis und für die Minimierung der Anwendungslatenz. Die Verfügbarkeit hängt davon ab, ob Ressourcen verfügbar sind und über ausreichend Kapazität verfügen, um den Bedarf zu decken. AWS bietet mehrere Mechanismen zur Verwaltung der Verfügbarkeit. Für Anwendungen, die Sie auf Amazon ECS hosten, gehören dazu Autoscaling und Availability Zones (AZs). Auto Scaling verwaltet die Anzahl der Aufgaben oder Instances auf der Grundlage von Metriken, die Sie definieren, während Availability Zones es Ihnen ermöglichen, Ihre Anwendung an isolierten, aber geografisch nahe gelegenen Standorten zu hosten.
Wie bei der Aufgabengröße stellen Kapazität und Verfügbarkeit gewisse Kompromisse dar, die Sie berücksichtigen müssen. Im Idealfall wäre die Kapazität perfekt auf die Nachfrage abgestimmt. Es würde immer gerade genug Kapazität zur Verfügung stehen, um Anfragen zu bearbeiten und Jobs so zu bearbeiten, dass die Service Level Objectives (SLOs), einschließlich einer niedrigen Latenz und Fehlerrate, erfüllt werden. Die Kapazität wäre niemals zu hoch, was zu übermäßigen Kosten führen würde, und sie würde auch niemals zu niedrig sein, was zu hohen Latenzen und Fehlerraten führen würde.
Auto Scaling ist ein latenter Prozess. Zunächst CloudWatch müssen Sie Echtzeit-Metriken erhalten. Anschließend CloudWatch müssen sie für die Analyse aggregiert werden, was je nach Granularität der Metrik bis zu mehreren Minuten dauern kann. CloudWatch vergleicht die Metriken mit den Alarmschwellenwerten, um einen Mangel oder Überschuss an Ressourcen zu ermitteln. Um Instabilität zu vermeiden, sollten Sie Alarme so konfigurieren, dass der festgelegte Schwellenwert einige Minuten lang überschritten werden muss, bevor der Alarm ausgelöst wird. Außerdem dauert es einige Zeit, neue Aufgaben bereitzustellen und Aufgaben zu beenden, die nicht mehr benötigt werden.
Aufgrund dieser potenziellen Verzögerungen im System sollten Sie durch Überprovisionierung einen gewissen Spielraum wahren. Eine übermäßige Bereitstellung kann dazu beitragen, kurzfristige Bedarfsspitzen zu bewältigen. Auf diese Weise kann Ihre Anwendung auch zusätzliche Anfragen bearbeiten, ohne dass eine Sättigung erreicht wird. Als bewährte Methode sollten Sie Ihr Skalierungsziel auf einen Wert zwischen 60 und 80 % der Auslastung festlegen. Auf diese Weise kann Ihre Anwendung zusätzliche Bedarfsspitzen besser bewältigen, während zusätzliche Kapazität noch bereitgestellt wird.
Ein weiterer Grund, warum wir eine Überversorgung empfehlen, besteht darin, dass Sie schnell auf Ausfälle in der Availability Zone reagieren können. AWS empfiehlt, dass Produktionsworkloads von mehreren Availability Zones aus bedient werden. Dies liegt daran, dass Ihre Aufgaben, die in den verbleibenden Availability Zones ausgeführt werden, auch bei einem Ausfall der Availability Zone den Bedarf decken können. Wenn Ihre Anwendung in zwei Availability Zones ausgeführt wird, müssen Sie die Anzahl Ihrer normalen Aufgaben verdoppeln. Auf diese Weise können Sie bei einem möglichen Ausfall sofort Kapazität bereitstellen. Wenn Ihre Anwendung in drei Availability Zones ausgeführt wird, empfehlen wir, dass Sie das 1,5-fache Ihrer normalen Aufgabenanzahl ausführen. Führen Sie also für jeweils zwei Aufgaben, die für die normale Ausführung erforderlich sind, drei Aufgaben aus.
## Maximierung der Skalierungsgeschwindigkeit
Auto Scaling ist ein reaktiver Prozess, dessen Wirksamkeit einige Zeit in Anspruch nimmt. Es gibt jedoch einige Möglichkeiten, den Zeitaufwand für die Aufskalierung zu minimieren.
**Die Image-Größe minimieren.** Das Herunterladen und Entpacken größerer Images aus einem Image-Repository dauert länger. Wenn Sie also die Image-Größen kleiner halten, verringert sich die Zeit, die ein Container benötigt, um zu starten. Um die Image-Größe zu reduzieren, können Sie die folgenden spezifischen Empfehlungen befolgen:
+ Wenn Sie eine statische Binärdatei erstellen oder Golang verwenden können, erstellen Sie Ihr `FROM`-Image von Grund auf und fügen Sie nur Ihre Binäranwendung in das resultierende Image ein.
+ Verwenden Sie minimierte Basis-Images von vorgelagerten Distributionsanbietern wie Amazon Linux oder Ubuntu.
+ Nehmen Sie keine Build-Artefakte in Ihr endgültiges Image auf. Die Verwendung mehrstufiger Builds kann dabei helfen.
+ Kompaktieren Sie `RUN`-Phasen, wo immer es möglich ist. In jeder `RUN`-Phase wird eine neue Image-Ebene erstellt, was zusätzlichen Datenverkehr zum Herunterladen der Ebene führt. Eine einzelne `RUN`-Phase, in der mehrere Befehle mit `&&` verknüpft sind, hat weniger Ebenen als eine Phase mit mehreren `RUN`-Phasen.
+ Wenn Sie Daten, wie z. B. ML-Inferenzdaten, in Ihr endgültiges Image aufnehmen möchten, schließen Sie nur die Daten ein, die für den Start und die Bereitstellung des Datenverkehrs erforderlich sind. Wenn Sie Daten bei Bedarf von Amazon S3 oder einem anderen Speicher abrufen, ohne den Service zu beeinträchtigen, speichern Sie Ihre Daten stattdessen an diesen Orten.
**Bewahren Sie Ihre Images in der Nähe auf.** Je höher die Netzwerklatenz ist, desto länger dauert es, das Image herunterzuladen. Hosten Sie Ihre Images in einem Repository in derselben AWS Region, in der sich Ihr Workload befindet. Amazon ECR ist ein leistungsstarkes Image-Repository, das in jeder Region verfügbar ist, in der Amazon ECS verfügbar ist. Vermeiden Sie es, das Internet oder einen VPN-Link zu nutzen, um Container-Images herunterzuladen. Das Hosten Ihrer Images in derselben Region verbessert die allgemeine Zuverlässigkeit. Dadurch wird das Risiko von Netzwerkverbindungs- und Verfügbarkeitsproblemen in einer anderen Region gemindert. Alternativ können Sie auch die regionsübergreifende Amazon-ECR-Replikation implementieren, um dies zu unterstützen.
**Reduzieren Sie die Schwellenwerte für Load-Balancer-Zustandsprüfungen.** Load Balancer führen Zustandsprüfungen durch, bevor sie Datenverkehr an Ihre Anwendung senden. Die Standardkonfiguration für Zustandsprüfungen für eine Zielgruppe kann 90 Sekunden oder länger dauern. Währenddessen überprüft der Load Balancer den Zustand und empfängt Anfragen. Wenn Sie das Intervall für Zustandsprüfungen und die Anzahl für den Schwellenwert verringern, kann Ihre Anwendung den Datenverkehr schneller annehmen und die Last anderer Aufgaben verringern.
**Ziehen Sie die Kaltstartleistung in Betracht.** Einige Anwendungen verwenden Laufzeiten wie die Java-Perform-Kompilierung Just-In-Time (JIT). Der Kompilierungsprozess kann zumindest beim Start die Leistung der Anwendung zeigen. Eine Möglichkeit, das Problem zu umgehen, besteht darin, die latenzkritischen Teile Ihres Workloads in Sprachen umzuschreiben, die keine Leistungseinbußen beim Kaltstart zur Folge haben.
**Verwenden Sie schrittweise Skalierungsrichtlinien, nicht Skalierungsrichtlinien für die Ziel-Nachverfolgung.** Sie haben mehrere Application-Auto-Scaling-Optionen für Amazon-ECS-Aufgaben. Die Zielverfolgung ist der am einfachsten zu verwendende Modus. Damit müssen Sie lediglich einen Zielwert für eine Metrik festlegen, z. B. die durchschnittliche CPU-Auslastung. Anschließend verwaltet der Autoscaler automatisch die Anzahl der Aufgaben, die erforderlich sind, um diesen Wert zu erreichen. Mit der schrittweisen Skalierung können Sie schneller auf Bedarfsänderungen reagieren, da Sie die spezifischen Schwellenwerte für Ihre Skalierungsmetriken definieren und festlegen, wie viele Aufgaben hinzugefügt oder entfernt werden müssen, wenn die Schwellenwerte überschritten werden. Und was noch wichtiger ist: Sie können sehr schnell auf Änderungen der Nachfrage reagieren, indem Sie die Zeitspanne, in der ein Schwellenwertalarm überschritten wird, auf ein Minimum reduzieren. Weitere Informationen finden Sie unter [Service Auto Scaling ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)im *Amazon Elastic Container Service Developer Guide*.
Wenn Sie Amazon-EC2-Instances zur Bereitstellung von Cluster-Kapazität verwenden, sollten Sie die folgenden Empfehlungen berücksichtigen:
**Verwenden Sie größere Amazon-EC2-Instances und schnellere Amazon-EBS-Volumes.** Sie können die Geschwindigkeit beim Herunterladen und Vorbereiten von Images verbessern, indem Sie eine größere Amazon-EC2-Instance und ein schnelleres Amazon-EBS-Volume verwenden. Innerhalb einer bestimmten Amazon-EC2-Instance-Familie steigt der maximale Durchsatz von Netzwerk und Amazon EBS mit zunehmender Instance-Größe (z. B. von `m5.xlarge` auf `m5.2xlarge`). Darüber hinaus können Sie Amazon-EBS-Volumes anpassen, um deren Durchsatz und IOPS zu erhöhen. Wenn Sie beispielsweise `gp2`-Volumes verwenden, sollten Sie größere Volumes verwenden, die einen höheren Basisdurchsatz bieten. Wenn Sie `gp3`-Volumes verwenden, geben Sie bei der Erstellung des Volumes den Durchsatz und die IOPS an.
**Verwenden Sie den Bridge-Netzwerkmodus für Aufgaben, die auf Amazon-EC2-Instances ausgeführt werden.** Aufgaben, die den `bridge`-Netzwerkmodus in Amazon EC2 verwenden, starten schneller als Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden. Wenn der `awsvpc`-Netzwerkmodus verwendet wird, fügt Amazon ECS der Instance eine Elastic-Network-Schnittstelle (ENI) hinzu, bevor die Aufgabe gestartet wird. Dies führt zu zusätzlicher Latenz. Bei der Verwendung von Bridge-Netzwerken gibt es jedoch mehrere Kompromisse. Für diese Aufgaben gibt es keine eigene Sicherheitsgruppe, und es gibt einige Auswirkungen auf das Load Balancing. Weitere Informationen finden Sie unter [Load-Balancer-Zielgruppen](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html) im *Benutzerhandbuch für Elastic Load Balancing*.
## Umgang mit Nachfrageschocks
Bei einigen Anwendungen kommt es zu plötzlichen starken Nachfrageschocks. Dies geschieht aus einer Vielzahl von Gründen: ein Nachrichtenereignis, ein großer Verkauf, ein Medienereignis oder ein anderes Ereignis, das sich viral verbreitet und dazu führt, dass der Datenverkehr in sehr kurzer Zeit schnell und deutlich zunimmt. Wenn dies nicht geplant ist, kann dies dazu führen, dass die Nachfrage die verfügbaren Ressourcen schnell übersteigt.
Der beste Weg, mit Nachfrageschocks umzugehen, besteht darin, sie zu antizipieren und entsprechend zu planen. Da die automatische Skalierung einige Zeit in Anspruch nehmen kann, empfehlen wir, dass Sie Ihre Anwendung aufskalieren, bevor der Nachfrageschock einsetzt. Um optimale Ergebnisse zu erzielen, empfehlen wir, einen Geschäftsplan zu erstellen, der eine enge Zusammenarbeit zwischen Teams vorsieht, die einen gemeinsamen Kalender verwenden. Das Team, welches das Ereignis plant, sollte im Voraus eng mit dem für die Anwendung zuständigen Team zusammenarbeiten. Dies gibt dem Team genügend Zeit, um einen klaren Zeitplan zu erstellen. Sie können die Kapazität so planen, dass sie vor dem Eregnis aufskaliert und nach dem Ereignis wieder abskaliert wird. Weitere Informationen finden Sie unter [Geplante Skalierung](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) im *Benutzerhandbuch für Application Auto Scaling*.
Wenn Sie einen Enterprise-Support-Plan haben, sollten Sie unbedingt mit Ihrem Technical Account Manager (TAM) zusammenarbeiten. Ihr TAM kann Ihre Service Quotas überprüfen und sicherstellen, dass alle erforderlichen Kontingente erhöht werden, bevor das Ereignis eintritt. So überschreiten Sie nicht versehentlich Ihre Servicekontingente. Ihr TAM kann Ihnen auch helfen, indem Services wie Load Balancer vorgewärmt werden, um sicherzustellen, dass Ihr Ereignis reibungslos abläuft.
Der Umgang mit ungeplanten Nachfrageschocks ist ein schwierigeres Problem. Ungeplante Schocks können, sofern das Ausmaß groß genug ist, schnell dazu führen, dass die Nachfrage die Kapazität übersteigt. Die Nachfrage kann auch die Reaktionsfähigkeit der automatischen Skalierung übersteigen. Der beste Weg, sich auf ungeplante Schocks vorzubereiten, ist eine Überbereitstellung von Ressourcen. Sie müssen über genügend Ressourcen verfügen, um den zu erwartenden maximalen Verkehrsbedarf jederzeit bewältigen zu können.
Die Aufrechterhaltung der maximalen Kapazität zur im Vorgriff auf ungeplante Nachfrageschocks kann kostspielig sein. Um die Auswirkungen auf die Kosten zu minimieren, suchen Sie nach einer Metrik oder einem Ereignis als Frühindikator, das darauf hindeutet, dass ein großer Nachfrageschock unmittelbar bevorsteht. Wenn die Metrik oder das Ereignis zuverlässig eine deutliche Vorwarnung bietet, beginnen Sie sofort mit dem Aufskalierungsprozess, wenn das Ereignis eintritt oder wenn die Metrik den von Ihnen festgelegten Schwellenwert überschreitet.
Wenn Ihre Anwendung zu plötzlichen, ungeplanten Nachfrageschocks neigt, sollten Sie erwägen, Ihrer Anwendung einen Hochleistungsmodus hinzuzufügen, der unkritische Funktionen einbüßt, aber wichtige Funktionen für einen Kunden beibehält. Gehen Sie beispielsweise davon aus, dass Ihre Anwendung von der Generierung teurer benutzerdefinierter Antworten zur Bereitstellung einer statischen Antwortseite übergehen kann. In diesem Szenario können Sie den Durchsatz erheblich erhöhen, ohne die Anwendung überhaupt skalieren zu müssen.
Schließlich können Sie erwägen, monolithische Service aufzuteilen, um Nachfrageschocks besser bewältigen zu können. Wenn es sich bei Ihrer Anwendung um einen monolithischen Service handelt, der teuer in der Ausführung und langsam zu skalieren ist, können Sie möglicherweise leistungskritische Teile extrahieren oder neu schreiben und sie als separate Services ausführen. Diese neuen Services können dann unabhängig von weniger kritischen Komponenten skaliert werden. Wenn Sie die Flexibilität haben, leistungskritische Funktionen getrennt von anderen Teilen Ihrer Anwendung zu skalieren, können Sie sowohl den Zeitaufwand für die Kapazitätserweiterung reduzieren als auch Kosten sparen.
# Amazon-ECS-Cluster-Kapazität
Sie können einem Amazon-ECS-Cluster auf verschiedene Weise Kapazität zur Verfügung stellen. Sie können beispielsweise Amazon-EC2-Instances starten und sie mithilfe des Amazon ECS-Container-Agenten beim Start im Cluster registrieren. Diese Methode kann jedoch schwierig sein, da Sie die Skalierung selbst verwalten müssen. Daher wird empfohlen, Amazon-ECS-Kapazitätsanbieter zu verwenden. Kapazitätsanbieter verwalten die Ressourcenskalierung für Sie. Es gibt drei Arten von Kapazitätsanbietern: Amazon EC2, Fargate und Fargate Spot. Weitere Informationen zu Fargate-Kapazitätsanbietern finden Sie unter [Amazon-ECS-Cluster für Fargate-Workloads](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html) und für EC2-Workloads unter [Amazon-ECS-Cluster für EC2-Workloads](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html).
Die Kapazitätsanbieter von Fargate und Fargate Spot übernehmen den Lebenszyklus der Fargate-Aufgaben für Sie. Fargate bietet On-Demand-Kapazitäten und Fargate Spot bietet Spot-Kapazität. Wenn Sie eine Aufgabe starten, stellt Amazon ECS eine Fargate-Ressource für Sie bereit. Diese Fargate-Ressource enthält die Arbeitsspeicher- und CPU-Einheiten, die direkt den Grenzwerten auf Aufgabenebene entsprechen, die Sie in Ihrer Aufgabendefinition deklariert haben. Jede Aufgabe erhält ihre eigene Fargate-Ressource, wodurch eine 1:1-Beziehung zwischen der Aufgabe und den Rechenressourcen hergestellt wird.
Aufgaben, die in Fargate Spot ausgeführt werden, können unterbrochen werden. Unterbrechungen treten nach einer zweiminütigen Warnung auf. Diese treten in Zeiten starker Nachfrage auf. Fargate Spot eignet sich am besten für unterbrechungstolerante Workloads wie Batch-Aufträge und Entwicklungs- oder Staging-Umgebungen. Sie eignen sich auch für jedes andere Szenario, in dem hohe Verfügbarkeit und geringe Latenz keine Voraussetzung sind.
Sie können Fargate-Spot-Aufgaben zusammen mit Fargate-On-Demand-Aufgaben ausführen. Wenn Sie diese zusammen verwenden, erhalten Sie Burst-Kapazität zu geringeren Kosten.
Amazon ECS kann auch die Amazon-EC2-Instance-Kapazität für Ihre Aufgaben verwalten. Jeder Amazon-EC2-Kapazitätsanbieter ist einer von Ihnen angegebenen Amazon-EC2-Auto-Scaling-Gruppe zugeordnet. Wenn Sie den Amazon-EC2-Kapazitätsanbieter verwenden, behält Cluster Auto Scaling die Größe der Amazon-EC2-Auto-Scaling-Gruppe bei, um sicherzustellen, dass alle geplanten Aufgaben platziert werden können.
# Auswahl der Fargate-Aufgabengrößen für Amazon ECS
Für AWS Fargate Aufgabendefinitionen müssen Sie CPU und Speicher auf Aufgabenebene angeben und müssen keinen Overhead berücksichtigen. Sie können auch die CPU- und Speicherauslastung für Fargate-Aufgaben auf Container-Ebene festlegen. Das ist jedoch optional. Die Ressourcenlimits müssen größer oder gleich den von Ihnen angegebenen Reservierungen sein. In den meisten Fällen können Sie sie auf die Summe der Reservierungen der einzelnen Container festlegen, die in Ihrer Aufgabendefinition deklariert sind. Runden Sie dann die Zahl auf die nächste Fargate-Größe auf. Weitere Informationen zu den verfügbaren Größen finden Sie unter [CPU und Arbeitsspeicher für Aufgaben](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-size).
# Beschleunigung der Kapazitätsbereitstellung für Amazon-ECS-Cluster mit Kapazitätsanbietern in Amazon EC2
Kunden, die Amazon ECS in Amazon EC2 ausführen, können [Amazon ECS Cluster Auto Scaling (CAS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html) nutzen, um die Skalierung von Amazon-EC2-Auto-Scaling-Gruppen (ASG) zu verwalten. Mit CAS können Sie Amazon ECS so konfigurieren, dass Ihre ASG automatisch skaliert wird, sodass Sie sich ganz auf die Ausführung Ihrer Aufgaben konzentrieren können. Amazon ECS stellt sicher, dass die ASG nach Bedarf auf- und abskaliert wird, ohne dass weitere Eingriffe erforderlich sind. Amazon-ECS-Kapazitätsanbieter werden verwendet, um die Infrastruktur in Ihrem Cluster zu verwalten, indem sichergestellt wird, dass genügend Container-Instances vorhanden sind, um die Anforderungen Ihrer Anwendung zu erfüllen. Weitere Informationen zur Funktionsweise von Amazon-ECS-CAS finden Sie unter [Deep Dive in Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).
Da CAS bei der Anpassung der Cluster-Kapazität auf einer CloudWatch basierten Integration mit ASG basiert, hat es eine inhärente Latenz, die mit der Veröffentlichung der CloudWatch Metriken, der Zeit, die die Metrik benötigt, `CapacityProviderReservation` um CloudWatch Alarme zu verletzen (sowohl hoch als auch niedrig), und der Zeit, die eine neu gestartete Amazon EC2 EC2-Instance zum Aufwärmen benötigt, verbunden. Sie können folgende Aktionen durchführen, um CAS reaktionsschneller zu machen und Bereitstellungen zu beschleunigen:
## Größen der schrittweisen Skalierung von Kapazitätsanbietern
Amazon ECS-Kapazitätsanbieter werden irgendwann grow/shrink die Container-Instances so einrichten, dass sie die Anforderungen Ihrer Anwendung erfüllen. Die Mindestanzahl von Instances, die Amazon ECS startet, ist standardmäßig auf 1 festgelegt. Dies kann Ihre Bereitstellungen verlängern, wenn mehrere Instances für die Ausführung Ihrer ausstehenden Aufgaben erforderlich sind. Sie können die [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) über die Amazon-ECS-API erhöhen, um die Mindestanzahl von Instances zu erhöhen, die Amazon ECS gleichzeitig auf- oder abskaliert. Wenn [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) zu niedrig ist, kann dies einschränken, wie viele Container-Instances gleichzeitig auf- oder abskaliert werden, was Ihre Bereitstellungen verlangsamen kann.
**Anmerkung**
Diese Konfiguration ist derzeit nur mit der Option [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)oder verfügbar [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) APIs.
## Instance-Aufwärmphase
Die Instance-Aufwärmphase ist der Zeitraum, nach dem eine neu gestartete Amazon EC2 EC2-Instance zu den CloudWatch Metriken für die Auto Scaling Scaling-Gruppe beitragen kann. Nach Ablauf der angegebenen Aufwärmphase wird die Instance auf die aggregierten Metriken der ASG angerechnet, und CAS fährt mit der nächsten Berechnungsiteration fort, um die Anzahl der benötigten Instances zu schätzen.
Der Standardwert für [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod)ist 300 Sekunden. Sie können ihn auf einen niedrigeren Wert konfigurieren, indem Sie [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)oder verwenden, um eine reaktionsschnellere Skalierung zu [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) APIs erzielen.
## Freie Kapazität
Wenn Ihr Kapazitätsanbieter keine Container-Instances für die Aufgabenplatzierung zur Verfügung hat, muss er die Cluster-Kapazität erhöhen (aufskalieren), indem er Amazon-EC2-Instances im laufenden Betrieb startet und wartet, bis sie hochgefahren sind, bevor er Container auf ihnen starten kann. Dies kann die Startrate von Aufgaben erheblich senken. Sie haben hier zwei Optionen.
In diesem Fall erhöht sich die effektive Startrate von Aufgaben, wenn Amazon-EC2-Kapazitäten bereits gestartet und bereit sind, Aufgaben auszuführen. Sie können die `Target Capacity`-Konfiguration verwenden, um anzugeben, dass Sie freie Kapazitäten in Ihren Clustern beibehalten möchten. Wenn Sie beispielsweise für `Target Capacity` einen Wert von 80 % festlegen, geben Sie an, dass Ihr Cluster jederzeit 20 % freie Kapazität benötigt. Dank dieser freien Kapazität können alle eigenständigen Aufgaben sofort gestartet werden, wodurch sichergestellt wird, dass das Starten von Aufgaben nicht gedrosselt wird. Der Nachteil dieses Ansatzes sind potenziell höhere Kosten für die Beibehaltung von freier Cluster-Kapazität.
Ein alternativer Ansatz, den Sie in Betracht ziehen können, besteht darin, Ihrem Service mehr Spielraum zu verleihen, nicht dem Kapazitätsanbieter. Das bedeutet, dass Sie, anstatt die `Target Capacity`-Konfiguration zu reduzieren, um freie Kapazitäten bereitzustellen, die Anzahl der Replikate in Ihrem Service erhöhen können, indem Sie die Skalierungsmetrik der Ziel-Nachverfolgung oder die Schwellenwerte für die schrittweise Skalierung des Service-Auto-Scaling ändern. Beachten Sie, dass dieser Ansatz nur bei stark beanspruchten Workloads hilfreich ist, aber keine Auswirkungen hat, wenn Sie neue Services bereitstellen und zum ersten Mal von 0 auf N Aufgaben wechseln. Weitere Informationen zu den zugehörigen Skalierungsrichtlinien finden Sie unter [Skalierungsrichtlinien für die Ziel-Nachverfolgung](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) oder [Schrittweise Skalierungsrichtlinien](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html)