Skalierungsrichtlinie auf Basis von Amazon SQS - Amazon EC2 Auto Scaling

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.

Skalierungsrichtlinie auf Basis von Amazon SQS

Wichtig

Die folgenden Informationen und Schritte zeigen Ihnen, wie Sie den SQS Amazon-Warteschlangen-Backlog pro Instance anhand des ApproximateNumberOfMessages Queue-Attributs berechnen, bevor Sie ihn als benutzerdefinierte Metrik für CloudWatch veröffentlichen. Sie können jetzt jedoch die Kosten und den Aufwand für die Veröffentlichung Ihrer eigenen Metrik sparen, indem Sie metrische Berechnungen verwenden. Weitere Informationen finden Sie unter Erstellen Sie mithilfe metrischer Mathematik eine Skalierungsrichtlinie für die Zielverfolgung.

In diesem Abschnitt erfahren Sie, wie Sie Ihre Auto Scaling Scaling-Gruppe als Reaktion auf Änderungen der Systemlast in einer Amazon Simple Queue Service (AmazonSQS) -Warteschlange skalieren können. Weitere Informationen darüber, wie Sie Amazon verwenden könnenSQS, finden Sie im Amazon Simple Queue Service Developer Guide.

Es gibt einige Szenarien, in denen Sie über eine Skalierung als Reaktion auf Aktivitäten in einer SQS Amazon-Warteschlange nachdenken könnten. Angenommen, Sie haben eine Webanwendung, mit der Benutzer Bilder hochladen und online verwenden können. In diesem Szenario erfordert jedes Image eine Größenanpassung und Codierung, bevor es veröffentlicht werden kann. Die App läuft auf EC2 Instances in einer Auto Scaling Scaling-Gruppe und ist so konfiguriert, dass sie Ihre typischen Upload-Raten verarbeitet. Fehlerhafte Instances werden beendet und ersetzt, um stets dieselbe Anzahl an Instances zu nutzen. Die App platziert die Bitmap-Rohdaten der Bilder zur Verarbeitung in einer SQS Warteschlange. Sie verarbeitet die Bilder und veröffentlicht die verarbeiteten Bilder, wo sie von Benutzern angezeigt werden können. Die Architektur für dieses Szenario funktioniert gut, wenn die Anzahl der Image-Uploads nicht im Laufe der Zeit variiert. Wenn sich die Anzahl der Uploads jedoch mit der Zeit ändert, könnten Sie eine dynamische Skalierung in Betracht ziehen, um die Kapazität Ihrer Auto-Scaling-Gruppe zu skalieren.

Zielverfolgung mit der richtigen Metrik verwenden

Wenn Sie eine Skalierungsrichtlinie für die Zielverfolgung verwenden, die auf einer benutzerdefinierten SQS Amazon-Warteschlangenmetrik basiert, kann sich die dynamische Skalierung effektiver an die Nachfragekurve Ihrer Anwendung anpassen. Weitere Informationen zum Auswählen von Metriken für die Zielverfolgung finden Sie unter Auswahl von Metriken.

Das Problem bei der Verwendung einer CloudWatch SQS Amazon-Metrik wie ApproximateNumberOfMessagesVisible für die Zielverfolgung besteht darin, dass sich die Anzahl der Nachrichten in der Warteschlange möglicherweise nicht proportional zur Größe der Auto Scaling Scaling-Gruppe ändert, die Nachrichten aus der Warteschlange verarbeitet. Das liegt daran, dass die Anzahl der Nachrichten in Ihrer SQS Warteschlange nicht nur die Anzahl der benötigten Instances bestimmt. Tatsächlich kann die Anzahl der Instances in Ihrer Auto-Scaling-Gruppe von mehreren Faktoren abhängen, einschließlich der für die Verarbeitung einer Nachricht benötigten Zeit und der akzeptablen zeitlichen Latenz (Warteschlangenverzögerung).

Die Lösung besteht darin, eine Rückstand pro Instance-Metrik zu verwenden, deren Zielwert der zulässige Rückstand pro Instance ist, der aufrechterhalten werden soll. Sie können diese Zahlen wie folgt berechnen:

  • Backlog pro Instanz: Um Ihren Backlog pro Instanz zu berechnen, beginnen Sie mit dem ApproximateNumberOfMessages Queue-Attribut, um die Länge der SQS Warteschlange zu bestimmen (Anzahl der Nachrichten, die aus der Warteschlange abgerufen werden können). Dividieren Sie diese Zahl durch die laufende Kapazität der Flotte, welche bei einer Auto-Scaling-Gruppe die Anzahl der Instances mit dem Status InService ist, um so den Rückstand pro Instance zu erhalten.

  • Zulässiger Rückstand pro Instance: Um Ihren Zielwert zu berechnen, bestimmen Sie zunächst, welche zeitliche Latenz Ihre Anwendung akzeptieren kann. Dann dividieren Sie den akzeptablen Latenzwert durch die durchschnittliche Zeit, die eine EC2 Instanz für die Verarbeitung einer Nachricht benötigt.

Ein Beispiel: Angenommen, Sie verfügen über eine Auto-Scaling-Gruppe mit 10 Instances und die Anzahl sichtbarer Nachrichten in der Warteschlange (ApproximateNumberOfMessages) ist 1 500. Wenn die durchschnittliche Verarbeitungszeit pro Nachricht 0,1 Sekunden beträgt und die längste akzeptable Latenz 10 Sekunden ist, dann ist der zulässige Rückstand pro Instance 10/0,1, was 100 Nachrichten entspricht. Dies bedeutet, dass 100 der Zielwert für Ihre Ziel-Nachverfolgungsrichtlinie ist. Wenn der Rückstand pro Instance den Zielwert erreicht, wird ein Aufskalierungsereignis ausgelöst. Da der Rückstand pro Instance bereits bei 150 Nachrichten liegt (1 500 Nachrichten / 10 Instances), wird Ihre Gruppe um fünf Instances aufskaliert, um die Proportion zum Zielwert beizubehalten.

Die folgenden Verfahren veranschaulichen, wie Sie die benutzerdefinierte Metrik veröffentlichen und die Skalierungsrichtlinie für die Ziel-Nachverfolgung erstellen, die Ihre Auto-Scaling-Gruppe zum Skalieren basierend auf diesen Berechnungen konfiguriert.

Wichtig

Denken Sie daran, zur Kostensenkung stattdessen metrische Berechnungen zu verwenden. Weitere Informationen finden Sie unter Erstellen Sie mithilfe metrischer Mathematik eine Skalierungsrichtlinie für die Zielverfolgung.

Es gibt drei Hauptkomponenten dieser Konfiguration:

  • Eine Auto Scaling Scaling-Gruppe zur Verwaltung von EC2 Instanzen für die Verarbeitung von Nachrichten aus einer SQS Warteschlange.

  • Eine benutzerdefinierte Metrik, die an Amazon CloudWatch gesendet wird und die Anzahl der Nachrichten in der Warteschlange pro EC2 Instance in der Auto Scaling Scaling-Gruppe misst.

  • Eine Zielverfolgungsrichtlinie, die Ihre Auto Scaling Scaling-Gruppe so konfiguriert, dass sie auf der Grundlage der benutzerdefinierten Metrik und eines festgelegten Zielwerts skaliert. CloudWatch Alarme rufen die Skalierungsrichtlinie auf.

Das folgende Diagramm illustriert die Architektur dieser Konfiguration.

Amazon EC2 Auto Scaling verwendet ein Architekturdiagramm für Warteschlangen

Einschränkungen und Voraussetzungen

Um diese Konfiguration verwenden zu können, müssen Sie die folgenden Einschränkungen beachten:

  • Sie müssen das AWS CLI oder an verwendenSDK, um Ihre benutzerdefinierte Metrik zu CloudWatch veröffentlichen. Anschließend können Sie Ihre Metrik mit dem überwachen AWS Management Console.

  • Die Amazon EC2 Auto Scaling-Konsole unterstützt keine Skalierungsrichtlinien zur Zielverfolgung, die benutzerdefinierte Metriken verwenden. Sie müssen das AWS CLI oder an verwendenSDK, um eine benutzerdefinierte Metrik für Ihre Skalierungsrichtlinie anzugeben.

In den folgenden Abschnitten erfahren Sie, wie Sie das AWS CLI für die Aufgaben verwenden, die Sie ausführen müssen. Um beispielsweise Metrikdaten abzurufen, die die aktuelle Nutzung der Warteschlange widerspiegeln, verwenden Sie den SQS get-queue-attributesBefehl. Stellen Sie sicher, dass Sie den CLI installiert und konfiguriert haben.

Bevor Sie beginnen, müssen Sie über eine SQS Amazon-Warteschlange verfügen, die Sie verwenden können. In den folgenden Abschnitten wird davon ausgegangen, dass Sie bereits über eine Warteschlange (Standard oderFIFO), eine Auto Scaling Scaling-Gruppe und EC2 Instances verfügen, auf denen die Anwendung ausgeführt wird, die die Warteschlange verwendet. Weitere Informationen zu Amazon SQS finden Sie im Amazon Simple Queue Service Developer Guide.

Scale-in-Schutz für Amazon SQS und Instances

Nachrichten, die zum Zeitpunkt der Beendigung einer Instance noch nicht verarbeitet wurden, werden in die SQS Warteschlange zurückgeschickt, wo sie von einer anderen Instance verarbeitet werden können, die noch läuft. Für Anwendungen, in denen Aufgaben mit langer Ausführung ausgeführt werden, können Sie optional den Instance-Scale-in-Schutz verwenden, um die Kontrolle darüber zu haben, welche Warteschlangen-Worker beendet werden, wenn Ihre Auto-Scaling-Gruppe skaliert wird.

Der folgende Pseudocode zeigt eine Möglichkeit zum Schutz langjähriger, warteschlangengesteuerter Worker-Prozesse vor Scale-In-Beendigung.

while (true) { SetInstanceProtection(False); Work = GetNextWorkUnit(); SetInstanceProtection(True); ProcessWorkUnit(Work); SetInstanceProtection(False); }

Weitere Informationen finden Sie unter Gestalten Sie Ihre Anwendungen so, dass sie das Kündigen von Instances ordnungsgemäß handhaben.