Kapazität und Verfügbarkeit

Die Anwendungsverfügbarkeit ist von entscheidender Bedeutung, um eine fehlerfreie Erfahrung zu bieten und die Anwendungslatenz zu minimieren. Die Verfügbarkeit hängt von Ressourcen ab, die zugänglich sind und über genügend Kapazität verfügen, um die Nachfrage zu decken.AWSbietet mehrere Mechanismen zur Verwaltung der Verfügbarkeit. Für Anwendungen, die auf Amazon ECS gehostet werden, umfassen diese Autoskalierung und Availability Zones (AZs). AutoScaling verwaltet die Anzahl der Tasks oder Instanzen basierend auf den von Ihnen definierten Metriken, während Availability Zones es Ihnen ermöglichen, Ihre Anwendung an isolierten, aber geografisch nahen Standorten zu hosten.

Wie bei Aufgabengrößen, Kapazität und Verfügbarkeit stellen bestimmte Kompromisse dar, die Sie berücksichtigen müssen. Idealerweise wäre die Kapazität perfekt auf die Nachfrage abgestimmt. Es gäbe immer gerade genug Kapazität, um Anforderungen zu bedienen und Aufträge zu verarbeiten, um Service Level Objectives (SLOs) zu erfüllen, einschließlich einer niedrigen Latenz und Fehlerrate. Die Kapazität würde niemals zu hoch sein, was zu übermäßigen Kosten führt; sie wäre auch nie zu niedrig, was zu hohen Latenz- und Fehlerraten führt.

Autoskalierung ist ein latenter Prozess. Zunächst müssen Echtzeit-Metriken an CloudWatch übermittelt werden. Dann müssen sie für die Analyse aggregiert werden, was abhängig von der Granularität der Metrik bis zu mehrere Minuten dauern kann. CloudWatch vergleicht die Metriken mit Alarmschwellenwerten, um einen Mangel oder einen Überschuss an Ressourcen zu identifizieren. Um Instabilität zu vermeiden, konfigurieren Sie Alarme so, dass der eingestellte Schwellenwert für einige Minuten überschritten werden muss, bevor der Alarm ausgelöst wird. Es braucht auch Zeit, um 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 Überprovisioning einen gewissen Spielraum aufrechterhalten. Dies kann dazu beitragen, kurzfristige Ausbrüche in der Nachfrage zu bewältigen. Dies hilft Ihrer Anwendung auch, zusätzliche Anforderungen zu bearbeiten, ohne die Sättigung zu erreichen. Als bewährte Methode können Sie Ihr Skalierungsziel zwischen 60 und 80% der Auslastung festlegen. Dies hilft Ihrer Anwendung, zusätzliche Bedarfsausbrüche besser zu handhaben, während zusätzliche Kapazität noch im Prozess der Bereitstellung ist.

Ein weiterer Grund, warum Sie eine Überbereitstellung empfehlen, besteht darin, dass Sie schnell auf Fehler der Availability Zone reagieren können.AWSempfiehlt, dass Produktionsarbeitslasten von mehreren Availability Zones aus bedient werden. Dies liegt daran, dass bei einem Fehler der Availability Zone Ihre Aufgaben, die in den verbleibenden Availability Zones ausgeführt werden, weiterhin den Bedarf erfüllen können. Wenn Ihre Anwendung in zwei Availability Zones ausgeführt wird, müssen Sie die Anzahl der normalen Aufgaben verdoppeln. Dies ist so, dass Sie sofortige Kapazität bei jedem potenziellen Ausfall bereitstellen können. Wenn Ihre Anwendung in drei Availability Zones ausgeführt wird, wird empfohlen, dass Sie das 1,5-fache Ihrer normalen Task-Anzahl ausführen. Das heißt, führen Sie drei Aufgaben für jeweils zwei aus, die für das normale Servieren benötigt werden.

Maximierung der Skalierungsgeschwindigkeit

Autoskalierung ist ein reaktiver Prozess, der Zeit benötigt, um wirksam zu werden. Es gibt jedoch einige Möglichkeiten, die Zeit zu minimieren, die für die Skalierung erforderlich ist.

Minimieren Sie die Bildgröße. Größere Bilder benötigen länger, um aus einem Bild-Repository herunterzuladen und zu entpacken. Wenn Sie Bildgrößen kleiner halten, wird daher die Zeit reduziert, die für den Start eines Containers benötigt wird. 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 Ihr ImageFROMScratch und schließen Sie nur Ihre binäre Anwendung in das resultierende Bild ein.

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

• Fügen Sie keine Build-Artefakte in Ihr endgültiges Bild ein. Die Verwendung von mehrstufigen Builds kann dabei helfen.

• KompaktRUNEtappen, wo immer möglich. JedeRUNerstellt eine neue Bildebene, die zu einer zusätzlichen Roundtrip zum Herunterladen des Layers führt. Eine einzelneRUN-Schritt, der mehrere Befehle enthält, die von&&hat weniger Layer als einer mit mehrerenRUN-Stufen.

• Wenn Sie Daten wie ML-Inferenzdaten in Ihr endgültiges Bild aufnehmen möchten, schließen Sie nur die Daten ein, die zum Starten und Starten 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 das Herunterladen des Abbilds. Hosten Sie Ihre Bilder in einem Repository im selbenAWSRegion, in der sich Ihre Arbeitslast befindet. Amazon ECR ist ein hochleistungsfähiges Bild-Repository, das in jeder Region verfügbar ist, in der Amazon ECS verfügbar ist. Vermeiden Sie das Durchlaufen des Internets oder eines VPN-Links, um Container-Images herunterzuladen. Das Hosting Ihrer Bilder in derselben Region verbessert die allgemeine Zuverlässigkeit. Es verringert das Risiko von Netzwerkkonnektivitätsproblemen und Verfügbarkeitsproblemen in einer anderen Region. Alternativ können Sie auch regionsübergreifende Replikation von Amazon ECR implementieren, um dies zu unterstützen.

Reduzieren der Zustandsprüfung für Load Balancer Load Balancer führen Zustandsprüfungen durch, bevor Datenverkehr an Ihre Anwendung gesendet wird. Die Standardkonfiguration für die Integritätsprüfung für eine Zielgruppe kann 90 Sekunden oder länger dauern. Dabei überprüft es den Integritätsstatus und empfangende Anfragen. Wenn Sie das Integritätsprüfungsintervall und die Anzahl der Schwellenwerte verringern, kann Ihre Anwendung den Datenverkehr schneller annehmen und die Belastung für andere Aufgaben verringern.

Berücksichtigen Sie Kaltstart-Leistung. Einige Anwendungen verwenden Laufzeiten wie Java führen Just-In-Time-Kompilierung (JIT) durch. Der Kompilierungsprozess kann mindestens beim Start die Anwendungsleistung anzeigen. Eine Problemumgehung besteht darin, die latenzkritischen Teile Ihrer Arbeitslast in Sprachen neu zu schreiben, die keine Leistungseinbußen bei Kaltstart verursachen.

Verwenden Sie Skalierungsrichtlinien für die Ziel-Nachverfolgung. Sie haben mehrere Optionen für Application Auto Scaling für Amazon ECS-Aufgaben. Die Zielverfolgung ist der einfachste Modus zu verwenden. Damit müssen Sie lediglich einen Zielwert für eine Metrik festlegen, z. B. die durchschnittliche CPU-Auslastung. Anschließend verwaltet der Auto-Scaler automatisch die Anzahl der Aufgaben, die benötigt werden, um diesen Wert zu erreichen. Es wird jedoch empfohlen, stattdessen die Schrittskalierung zu verwenden, damit Sie schneller auf Bedarfsänderungen reagieren können. Mit der Schrittskalierung definieren Sie die spezifischen Schwellenwerte für Ihre Skalierungsmetriken und wie viele Aufgaben hinzugefügt oder entfernt werden sollen, wenn die Schwellenwerte überschritten werden. Und noch wichtiger ist, dass Sie sehr schnell auf Veränderungen der Nachfrage reagieren können, indem Sie die Zeit minimieren, die ein Schwellenalarm verletzt wird. Weitere Informationen finden Sie unterAuto ScalingimAmazon Elastic Container Service-Entwicklerhandbuch.

Wenn Sie Amazon EC2 Instances zur Bereitstellung von Cluster-Kapazität verwenden, beachten Sie die folgenden Empfehlungen:

Verwenden Sie größere Amazon 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 Instance und ein schnelleres Amazon EBS-Volume verwenden. Innerhalb einer bestimmten Amazon EC2 Instance-Familie erhöht sich der maximale Durchsatz von Netzwerk und Amazon EBS, wenn die Instance-Größe zunimmt (z. B.m5.xlargeaufm5.2xlarge) enthalten. Darüber hinaus können Sie Amazon EBS-Volumes anpassen, um deren Durchsatz und IOPS zu erhöhen. Wenn Sie beispielsweisegp2-Volumes verwenden, größere Volumes, die einen höheren Basisdurchsatz bieten. Wenn Siegp3Beim Erstellen des Volumes den Durchsatz und die IOPS an.

Verwenden Sie den Bridge-Netzwerkmodus für Aufgaben, die auf Amazon EC2 Instances ausgeführt werden. Verwenden von Aufgabenbridge-Netzwerkmodus auf Amazon EC2 schneller gestartet als Tasks, die dieawsvpc-Netzwerkmodus. WannawsvpcDamit der -Netzwerkmodus verwendet wird, fügt Amazon ECS eine elastic network interface (ENI) an, bevor die Aufgabe gestartet wird. Dies führt zu einer zusätzlichen Latenz. Es gibt jedoch mehrere Kompromisse für die Verwendung von Bridge-Netzwerken. Diese Aufgaben erhalten keine eigene Sicherheitsgruppe, und es gibt einige Auswirkungen auf den Lastenausgleich. Weitere Informationen finden Sie unterZielgruppen des LastausgleichsimElastic Load Balancing.

Nachfrage-Schocks

Einige Anwendungen erleben plötzliche große Stöße in der Nachfrage. Dies geschieht aus einer Vielzahl von Gründen: eine Nachrichtenveranstaltung, einen großen Verkauf, eine Medienveranstaltung oder ein anderes Ereignis, das virale Ereignis bewirkt, dass der Verkehr schnell und deutlich in einer sehr kurzen Zeitspanne zunimmt. Wenn nicht geplant, kann dies dazu führen, dass der Bedarf die verfügbaren Ressourcen schnell übertrifft.

Der beste Weg, Nachfrageschocks zu handhaben, ist, sie zu antizipieren und entsprechend zu planen. Da die automatische Skalierung Zeit in Anspruch nehmen kann, empfehlen wir, dass Sie Ihre Anwendung skalieren, bevor der Bedarfsschock beginnt. Um die besten Ergebnisse zu erzielen, empfehlen wir, einen Geschäftsplan zu erstellen, der eine enge Zusammenarbeit zwischen Teams beinhaltet, die einen gemeinsam genutzten 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 genug Zeit, um einen klaren Terminplan zu haben. Sie können die Kapazität so planen, dass sie vor dem Ereignis skaliert und nach dem Event skaliert werden kann. Weitere Informationen finden Sie unterGeplante SkalierungimBenutzerhandbuch zum Auto Scaling von Anwendungen.

Wenn Sie über einen Enterprise Support -Plan verfügen, sollten Sie auch mit Ihrem Technical Account Manager (TAM) zusammenarbeiten. Ihr TAM kann Ihre Servicekontingente überprüfen und sicherstellen, dass alle erforderlichen Kontingente vor Beginn des Ereignisses angehoben werden. Auf diese Weise treffen Sie nicht versehentlich Dienstquoten. Sie können Ihnen auch helfen, indem Sie Services wie Load Balancer vorwärmen, um sicherzustellen, dass Ihre Veranstaltung reibungslos läuft.

Der Umgang mit ungeplanten Nachfrageschocks ist ein schwierigeres Problem. Ungeplante Schocks, wenn sie groß genug in der Amplitude sind, können schnell dazu führen, dass die Nachfrage die Kapazität übersteigt. Es kann auch die Fähigkeit zur automatischen Skalierung übertreffen, zu reagieren. Der beste Weg, um sich auf ungeplante Schocks vorzubereiten, besteht darin, Ressourcen zu überlagern. Sie müssen über genügend Ressourcen verfügen, um den maximal erwarteten Datenverkehr jederzeit zu bewältigen.

Die Aufrechterhaltung der maximalen Kapazität im Vorgriff auf ungeplante Nachfrageschocks kann kostspielig sein. Um die Kostenauswirkungen zu verringern, suchen Sie nach einer Kennzahl oder einem Ereignis, das voraussagt, dass ein großer Nachfrageschock bevorsteht. Wenn die Metrik oder das Ereignis zuverlässig einen signifikanten Vorankündigung liefert, beginnen Sie den Scale-Out-Prozess sofort, wenn das Ereignis eintritt oder wenn die Metrik den festgelegten Schwellenwert überschreitet.

Wenn Ihre Anwendung zu plötzlichen, ungeplanten Bedarfsschocks neigt, sollten Sie Ihrer Anwendung einen Hochleistungsmodus hinzufügen, der unkritische Funktionen einbüßt, aber für einen Kunden entscheidende Funktionen beibehält. Angenommen, Ihre Anwendung kann von der Generierung teurer angepasster Antworten auf die Bereitstellung einer statischen Antwortseite wechseln. In diesem Szenario können Sie den Durchsatz deutlich erhöhen, ohne die Anwendung überhaupt zu skalieren.

Zuletzt können Sie in Erwägung ziehen, monolithische Dienste auseinander zu brechen, um mit Nachfrageschocks besser umzugehen. Wenn es sich bei der Anwendung um einen monolithischen Dienst handelt, der teuer ausgeführt und langsam skaliert werden kann, 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 verringern als auch Kosten sparen.