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

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:

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.

Es gibt drei Hauptkomponenten dieser Konfiguration:

Das folgende Diagramm illustriert die Architektur dieser Konfiguration.

Einschränkungen und Voraussetzungen

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

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.