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.

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:

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 im Amazon Elastic Container Service Developer Guide.

Wenn Sie EC2 Amazon-Instances zur Bereitstellung von Cluster-Kapazität verwenden, sollten Sie die folgenden Empfehlungen berücksichtigen:

Verwenden Sie größere EC2 Amazon-Instances und schnellere Amazon EBS-Volumes. Sie können die Geschwindigkeit beim Herunterladen und Vorbereiten von Bildern verbessern, indem Sie eine größere EC2 Amazon-Instance und ein schnelleres Amazon EBS-Volume verwenden. Innerhalb einer bestimmten EC2 Amazon-Instance-Familie steigt der maximale Durchsatz von Netzwerk und Amazon EBS mit zunehmender Instance-Größe (z. B. von m5.xlarge bism5.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 EC2 Amazon-Instances ausgeführt werden. Aufgaben, die den bridge Netzwerkmodus bei Amazon verwenden, EC2 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 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 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.