Optimieren Sie die 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, die über ausreichend Kapazität verfügen, um den Bedarf zu decken. AWS bietet mehrere Mechanismen zur Verwaltung der Verfügbarkeit. Für Anwendungen, die auf Amazon ECS gehostet werden, gehören dazu Autoscaling und Availability Zones (AZs). Autoscaling 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 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.

Autoscaling ist ein latenter Prozess. Zunächst müssen Echtzeit-Metriken bereitgestellt werden. CloudWatch Anschließend 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 eingestellte Schwellenwert einige Minuten lang überschritten werden muss, bevor der Alarm ausgelöst wird. Außerdem nimmt es Zeit in Anspruch, neue Aufgaben bereitzustellen und Aufgaben zu beenden, die nicht mehr benötigt werden.

Aufgrund dieser potenziellen Verzögerungen im beschriebenen System ist es wichtig, dass Sie durch Überprovisionierung einen gewissen Spielraum wahren. Dies kann dazu beitragen, kurzfristigen Nachfrageschüben Rechnung zu tragen. Auf diese Weise kann Ihre Anwendung auch zusätzliche Anfragen bearbeiten, ohne dass eine Überlastung eintritt. Als bewährte Methode können Sie Ihr Skalierungsziel 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. Wir empfehlen, Produktionsworkloads von mehreren Availability Zones aus zu bedienen. Dies liegt daran, dass bei einem Ausfall der Availability Zone Ihre Aufgaben, die in den verbleibenden Availability Zones ausgeführt werden, den Bedarf weiterhin 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 Task-Anzahl 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

Autoscaling ist ein reaktiver Prozess, dessen Wirksamkeit einige Zeit in Anspruch nimmt. Es gibt jedoch einige Möglichkeiten, den Zeitaufwand für die Skalierung zu minimieren.

Minimiert die Bildgröße. Das Herunterladen und Entpacken größerer Bilder aus einem Bild-Repository dauert länger. Wenn Sie also die Bildgrößen kleiner halten, verringert sich die Zeit, die ein Container benötigt, um zu starten. Um die Bildgröß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 Ihren FROM Image-Scratch und fügen Sie nur Ihre Binäranwendung in das resultierende Image ein.

• Verwenden Sie minimierte Basis-Images von Upstream-Distributionsanbietern wie Amazon Linux oder Ubuntu.

• Nehmen Sie keine Build-Artefakte in Ihr endgültiges Image auf. Die Verwendung mehrstufiger Builds kann dabei helfen.

• Kompakte RUN Stufen, wo immer dies möglich ist. RUNIn jeder Phase wird eine neue Bildebene erstellt, was zu einem zusätzlichen Roundtrip zum Herunterladen der Ebene führt. Eine einzelne RUN Phase, in der mehrere Befehle miteinander verknüpft sind, && hat weniger Ebenen als eine Phase mit mehreren RUN Stufen.

• Wenn Sie Daten, wie z. B. ML-Inferenzdaten, in Ihr endgültiges Bild 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.

Halten Sie Ihre Bilder in der Nähe. Je höher die Netzwerklatenz, desto länger dauert es, das Bild herunterzuladen. Hosten Sie Ihre Bilder in einem Repository in derselben 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 Bilder in derselben Region verbessert die allgemeine Zuverlässigkeit. Dadurch wird das Risiko von Netzwerkverbindungs- und Verfügbarkeitsproblemen in einer anderen Region verringert. Alternativ können Sie auch die regionsübergreifende Amazon ECR-Replikation implementieren, um dies zu unterstützen.

Reduzieren Sie die Schwellenwerte für die Integritätsprüfung des Load Balancers. Load Balancer führen Integritätsprüfungen durch, bevor sie Datenverkehr an Ihre Anwendung senden. Die Standardkonfiguration für Integritätsprüfungen für eine Zielgruppe kann 90 Sekunden oder länger dauern. Währenddessen überprüft der Load Balancer den Integritätsstatus und empfängt Anfragen. Wenn Sie das Intervall für Integritätsprüfungen und die Anzahl der Schwellenwerte verringern, kann Ihre Anwendung den Datenverkehr schneller annehmen und die Belastung anderer Aufgaben verringern.

Ziehen Sie die Kaltstartleistung in Betracht. Einige Anwendungen verwenden Laufzeiten, z. B. Java führt Just-In-Time-Kompilierung (JIT) durch. Der Kompilierungsprozess kann zumindest beim Start die Leistung der Anwendung belegen. Eine Behelfslösung besteht darin, die latenzkritischen Teile Ihres Workloads in Sprachen umzuschreiben, die keine Leistungseinbußen beim Kaltstart zur Folge haben.

Verwenden Sie schrittweise Skalierungsrichtlinien, nicht zielgerichtete Skalierungsrichtlinien. Es gibt mehrere Application Auto Scaling Scaling-Optionen für 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.

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

Verwenden Sie größere Amazon EC2 EC2-Instances und schnellere Amazon EBS-Volumes. Sie können die Geschwindigkeit beim Herunterladen und Vorbereiten von Bildern verbessern, indem Sie eine größere Amazon EC2 EC2-Instance und ein schnelleres Amazon EBS-Volume verwenden. Innerhalb einer bestimmten 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 Amazon EC2 EC2-Instances ausgeführt werden. Aufgaben, die den bridge Netzwerkmodus auf 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 interface (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 den Lastenausgleich. Weitere Informationen finden Sie unter Load Balancer-Zielgruppen im Elastic Load Balancing User Guide.

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 Traffic 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 skalieren, 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, das die Veranstaltung plant, sollte im Voraus eng mit dem für die Bewerbung zuständigen Team zusammenarbeiten. Dies gibt dem Team genügend Zeit, um einen klaren Terminplan zu haben. Sie können die Kapazität so planen, dass sie vor der Veranstaltung skaliert und nach der Veranstaltung wieder erhöht wird. Weitere Informationen finden Sie unter Geplante Skalierung im Benutzerhandbuch für Application Auto Scaling.

Wenn Sie einen Enterprise Support-Plan haben, sollten Sie auch mit Ihrem Technical Account Manager (TAM) zusammenarbeiten. Ihr TAM kann Ihre Servicekontingenten überprüfen und sicherstellen, dass alle erforderlichen Kontingente erhöht werden, bevor die Veranstaltung beginnt. Auf diese Weise erreichen Sie nicht versehentlich irgendwelche Servicekontingenten. Sie können Ihnen auch helfen, indem sie Dienste wie Load Balancer vorwärmen, um sicherzustellen, dass Ihre Veranstaltung reibungslos abläuft.

Der Umgang mit ungeplanten Nachfrageschocks ist ein schwierigeres Problem. Ungeplante Schocks können, sofern sie eine ausreichend große Amplitude haben, schnell dazu führen, dass die Nachfrage die Kapazität übersteigt. Sie kann auch die Reaktionsfähigkeit der automatischen Skalierung übersteigen. Der beste Weg, sich auf ungeplante Schocks vorzubereiten, besteht darin, zu viele Ressourcen bereitzustellen. 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 im Vorgriff auf ungeplante Nachfrageschocks kann kostspielig sein. Um die Auswirkungen auf die Kosten zu minimieren, suchen Sie nach einer Frühindikatorkennzahl oder einem Ereignis, das darauf hindeutet, dass ein großer Nachfrageschock unmittelbar bevorsteht. Wenn die Kennzahl oder das Ereignis zuverlässig eine deutliche Vorwarnung bietet, beginnen Sie sofort mit dem Skalierungsprozess, wenn das Ereignis eintritt oder wenn die Kennzahl 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.

Sie können erwägen, monolithische Dienste auseinanderzunehmen, um besser mit Nachfrageschocks umgehen zu können. Wenn es sich bei Ihrer Anwendung um einen monolithischen Dienst 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 Dienste ausführen. Diese neuen Dienste 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.