Elastic-Beanstalk-Worker-Umgebungen

Wenn die AWS Elastic Beanstalk-Anwendung zeitaufwendige Operationen oder Workflows ausführt, können Sie diese Aufgaben in eine spezielle Worker-Umgebung auslagern. Das Frontend der Webanwendung von einem Prozess zu entkoppeln, der blockierende Vorgänge ausführt, ist ein gängiger Weg, um die Reaktionsfähigkeit der Anwendung auch bei Auslastung sicherzustellen.

Zu einer zeitaufwendigen Aufgabe zählen alle Vorgänge, die eine erhebliche Verlängerung der Anforderungsverarbeitung verursachen, also z. B. Bild- oder Videobearbeitung, Versenden von E-Mails oder Generieren eines ZIP-Archivs. Diese Vorgänge nehmen nur ein oder zwei Sekunden in Anspruch, jedoch ist eine Verzögerung von wenigen Sekunden ein hoher Wert für eine Webanforderung, die ansonsten in weniger als 500 ms verarbeitet wird.

Eine Möglichkeit besteht darin, einen Worker-Prozess lokal zu erstellen, erfolgreiche Antworten zurückzugeben und die Aufgabe asynchron zu verarbeiten. Das funktioniert, wenn die Instance alle gesendeten Aufgaben verarbeiten kann. Bei hoher Auslastung kann die Instance jedoch durch die Hintergrundaufgaben überlastet werden und daher nicht mehr auf Anforderungen mit höherer Priorität reagieren. Wenn einzelne Benutzer mehrere Aufgaben generieren können, entspricht die gestiegene Auslastung möglicherweise nicht einer höheren Benutzeranzahl, sodass keine effiziente Skalierung der Webserverebene mehr möglich ist.

Sie können die lokale Ausführung zeitaufwendiger Aufgaben verhindern, indem Sie diese – mithilfe des AWS SDKs für Ihre Programmiersprache – an eine Amazon Simple Queue Service (Amazon SQS)-Warteschlange senden, und den Prozess der Aufgabenverarbeitung auf separaten Instances ausführen. Die Worker-Instances verarbeiten Elemente aus der Warteschlange nur, wenn genügend Kapazität für deren Ausführung vorhanden ist. Auf diese Weise wird eine Überlastung verhindert.

Elastic Beanstalk Worker-Umgebungen vereinfachen diesen Prozess mithilfe der Amazon SQS-Warteschlangenverwaltung und der Ausführung eines Daemon-Prozesses auf jeder Instance, der Warteschlangenelemente liest. Wenn der Daemon ein Element aus der Warteschlange abruft, sendet er eine lokale HTTP POST-Anforderung auf Port 80 mit dem Textinhalt der Warteschlangennachricht an http://localhost/. Dann muss die Anwendung nur noch die zeitaufwendige Aufgabe als Reaktion auf die POST-Anforderung ausführen. Sie können den Daemon konfigurieren, um die POST-Anforderung an einen anderen Pfad zu senden, einen anderen MIME-Typ als Anwendung/JSON zu verwenden, die Verbindung zu einer vorhandenen Warteschlange herzustellen oder Verbindungen (maximale gleichzeitige Anforderungen), Timeouts und Wiederholungen einzurichten.

Mit regelmäßigen Aufgaben können Sie den Worker-Daemon so konfigurieren, dass er Nachrichten auf Basis eines Cron-Plans in die Warteschlange stellt. Jede periodische Aufgabe kann die POST-Anforderung an einen anderen Pfad senden. Aktivieren Sie periodische Aufgaben, indem Sie eine YAML-Datei, die den Plan und den Pfad für die einzelnen Aufgaben definiert, in den Quellcode einbinden.

Anmerkung

Die .NET-Plattform auf Windows Server unterstützt keine Worker-Umgebungen.

SQS-Daemon in der Worker-Umgebung

In Worker-Umgebungen wird ein von Elastic Beanstalk bereitgestellter Daemon-Prozess ausgeführt. Dieser Daemon wird regelmäßig mit neuen Funktionen und Fehlerbehebungen aktualisiert. Für die neueste Daemon-Version aktualisieren Sie auf die neueste Plattformversion.

Wenn die Anwendung in der Worker-Umgebung als Antwort 200 OK zurückgibt und damit den Empfang und die erfolgreiche Verarbeitung der Anforderung bestätigt, sendet der Daemon den Aufruf DeleteMessage an die Amazon SQS-Warteschlange, damit die Nachricht aus der Warteschlange gelöscht wird. Gibt die Anwendung eine andere Antwort als 200 OK zurück, stellt Elastic Beanstalk die Nachricht nach Ablauf des konfigurierten ErrorVisibilityTimeout-Zeitraums wieder in die Warteschlange. Falls es gar keine Antwort gibt, platziert Elastic Beanstalk die Nachricht nach Verstreichen des konfigurierten InactivityTimeout-Zeitraums wieder in die Warteschlange, damit sie anderweitig verarbeitet werden kann.

Anmerkung

Die Eigenschaften der Amazon SQS-Warteschlangen (Reihenfolge der Nachrichten, mindestens einmalige Zustellung und Nachrichten-Sampling) können die Entwicklung der Webanwendung in einer Worker-Umgebung beeinflussen. Weitere Informationen finden Sie unter Eigenschaften verteilter Warteschlangen im Amazon Simple Queue Service-Entwicklerhandbuch.

Amazon SQS löscht automatisch Nachrichten, die sich länger als der konfigurierte RetentionPeriod-Zeitraum in der Warteschlange befinden.

Der Daemon legt folgende HTTP-Header fest.

HTTP-Header
Name	Wert
User-Agent	aws-sqsd aws-sqsd/1.11
X-Aws-Sqsd-Msgid	SQS-Nachrichten-ID, mit der Nachrichtenfluten (ungewöhnlich hohe Anzahl neuer Nachrichten) erkannt werden.
X-Aws-Sqsd-Queue	Gibt den Namen der SQS-Warteschlange an.
X-Aws-Sqsd-First-Received-At	Gibt den Zeitpunkt, an dem die Meldung zum ersten Mal empfangen wurde, in koordinierter Weltzeit (UTC) im Format ISO 8601 an.
X-Aws-Sqsd-Receive-Count	Gibt die Anzahl der empfangenen SQS-Nachrichten an.
X-Aws-Sqsd-Attr-message-attribute-name	Benutzerdefinierte Attribute, die der gerade verarbeiteten Nachricht zugeordnet sind. Der tatsächliche Name des Nachrichtenattributs wird mit message-attribute-name angegeben. Alle Nachrichtenattribute im Zeichenfolgen- oder Ziffernformat werden zum Header hinzugefügt. Binary-Attribute werden verworfen und nicht in den Header aufgenommen.
Content-Type	Gibt die Mime-Typkonfiguration an, standardmäßig application/json.

Warteschlangen für unzustellbare Nachrichten

Elastic Beanstalk-WorkerUmgebungen unterstützen Amazon Simple Queue Service (Amazon SQS) Dead-Letter-Warteschlangen. Andere (Quell-) Warteschlangen können Nachrichten, die aus irgendeinem Grund nicht erfolgreich verarbeitet werden konnten, an die Warteschlange für unzustellbare Nachrichten senden. Eine solche Warteschlange für unzustellbare Nachrichten bietet den Vorteil, dass nicht erfolgreich verarbeitete Nachrichten ausgesondert und isoliert werden können. Anschließend können Sie alle Nachrichten analysieren, die an die Warteschlange für unzustellbare Nachrichten gesendet wurden, und ermitteln, warum die Verarbeitung nicht erfolgreich war.

Für eine Worker-Umgebung wird standardmäßig eine Warteschlange für unzustellbare Nachrichten aktiviert, wenn Sie bei der Erstellung der Worker-Umgebungsebene eine automatisch generierte Amazon SQS-Warteschlange angeben. Bei Auswahl einer vorhandenen SQS-Warteschlange für die Worker-Umgebung müssen Sie mithilfe von SQS eine Warteschlange für unzustellbare Nachrichten separat konfigurieren. Weitere Informationen zur Verwendung von SQS zum Konfigurieren einer Warteschlange für unzustellbare Nachrichten finden Sie unter Using Amazon SQS Dead Letter Queues.

Warteschlangen für unzustellbare Nachrichten können nicht deaktiviert werden. Nicht zustellbare Nachrichten werden letztlich immer an eine Warteschlange für unzustellbare Nachrichten gesendet. Sie können diese Funktion jedoch effektiv deaktivieren, indem Sie die Option MaxRetries auf den maximal zulässigen Wert von 100 festlegen.

Wenn keine Warteschlange für unzustellbare Nachrichten für die Amazon SQS-Warteschlange Ihrer Arbeitsumgebung konfiguriert ist, werden Nachrichten in der Warteschlange von Amazon SQS aufbewahrt, bis der Aufbewahrungszeitraum abgelaufen ist. Weitere Informationen zum Konfigurieren des Aufbewahrungszeitraums finden Sie unter Konfigurieren von Worker-Umgebungen.

Anmerkung

Die Elastic Beanstalk MaxRetries-Option entspricht der SQS MaxReceiveCount-Option. Sofern in der Worker-Umgebung keine automatisch generierte SQS-Warteschlange verwendet wird, lässt sich die Warteschlange für unzustellbare Nachrichten effektiv mit der SQS-Option MaxReceiveCount deaktivieren. Weitere Informationen finden Sie unter Using Amazon SQS Dead Letter Queues.

Weitere Informationen zum Lebenszyklus einer SQS-Nachricht finden Sie unter Message Lifecycle.

Regelmäßige Aufgaben

Sie können periodische Aufgaben in einer cron.yaml-Datei im Quell-Bundle definieren, damit in regelmäßigen Abständen automatisch Aufträge zur Warteschlange der Worker-Umgebung hinzugefügt werden.

Die folgende cron.yaml-Datei erstellt beispielsweise zwei periodische Aufgaben. Die erste läuft alle 12 Stunden und die zweite läuft täglich um 23:00 Uhr UTC.

Beispiel cron.yaml

version: 1
cron:
 - name: "backup-job"
   url: "/backup"
   schedule: "0 */12 * * *"
 - name: "audit"
   url: "/audit"
   schedule: "0 23 * * *"

Die Eingabe für name muss für jede Aufgabe eindeutig sein. Die URL ist der Pfad, an den die POST-Anforderung gesendet wird, um den Auftrag auszulösen. Die Planung erfolgt über einen CRON-Ausdruck, mit dem der Ausführungszeitpunkt der Aufgabe festgelegt wird.

Wenn eine Aufgabe ausgeführt wird, sendet der Daemon eine Nachricht mit einem Header, in dem der auszuführende Auftrag beschrieben wird, an die SQS-Warteschlange der Umgebung. Jede Instance der Umgebung kann die Nachricht annehmen und den Auftrag verarbeiten.

Anmerkung

Bei Konfiguration der Worker-Umgebung mit einer vorhandenen SQS-Warteschlange müssen Sie eine Amazon SQS-FIFO-Warteschlange wählen, regelmäßige Aufgaben werden nicht unterstützt.

Elastic Beanstalk bestimmt anhand der Leader-Wahl, welche Instance der Worker-Umgebung die periodische Aufgabe in die Warteschlange stellt. Jede Instance versucht, durch Schreiben in eine Amazon DynamoDB-Tabelle zum Leader zu werden. Die erste erfolgreiche Instance fungiert als Leader und muss weiterhin in die Tabelle schreiben, um den Leader-Status zu behalten. Wenn der Leader ausfällt, übernimmt rasch eine andere Instance.

Bei regelmäßigen Aufgaben legt der Worker-Daemon die folgenden zusätzlichen Header fest.

HTTP-Header
Name	Wert
X-Aws-Sqsd-Taskname	Bei regelmäßigen Aufgaben ist dies der Name der auszuführenden Aufgabe.
X-Aws-Sqsd-Scheduled-At	Gibt den Zeitpunkt an, für den die regelmäßige Aufgabe geplant war.
X-Aws-Sqsd-Sender-Id	Gibt die AWS-Kontonummer des Absenders der Nachricht an.

Amazon CloudWatch für die automatische Skalierung auf Worker-Umgebungs-Ebene verwenden

Gemeinsam überwachen Amazon EC2 Auto Scaling und CloudWatch die CPU-Auslastung der laufenden Instances in der Worker-Umgebung. Mit der Konfiguration des Auto Scaling-Limits für die CPU-Kapazität geben Sie an, wie viele Instances von der Auto Scaling-Gruppe zur Verarbeitung des Nachrichtendurchsatzes in der Amazon SQS-Warteschlange ausgeführt werden. Jede EC2-Instance veröffentlicht ihre CPU-Auslastungsmetriken anCloudWatch. Mit der Amazon EC2 Auto Scaling-Funktion wird die durchschnittliche CPU-Auslastung aller Instances der Worker-Umgebung vonCloudWatch abgerufen. Sie konfigurieren den oberen und den unteren Grenzwert sowie die Anzahl der Instances, die entsprechend der CPU-Kapazität hinzugefügt oder beendet werden sollen. Wenn von der Amazon EC2 Auto Scaling-Funktion erkannt wird, dass der angegebene obere Grenzwert für die CPU-Kapazität erreicht ist, erstellt Elastic Beanstalk neue Instances in der Worker-Umgebung. Sinkt die CPU-Auslastung wieder unter den Grenzwert, werden die Instances gelöscht.

Anmerkung

Sofern beim Beenden einer Instance noch nicht verarbeitete Nachrichten vorhanden sind, werden diese an die Warteschlange zurückgegeben und können von einem anderen Daemon auf einer ausgeführten Instance verarbeitet werden.

Sie können bei Bedarf auch andere CloudWatch-Alarme mithilfe der Elastic-Beanstalk-Konsole, der CLI- oder der Optionsdatei einrichten. Weitere Informationen finden Sie unter Verwenden von Elastic Beanstalk mit Amazon CloudWatch und Erstellen einer Auto Scaling-Gruppe mit Richtlinien für die schrittweise Skalierung.

Konfigurieren von Worker-Umgebungen

Die Verwaltung der Worker-Umgebungskonfiguration erfolgt über die Bearbeitung der Kategorie Worker auf der Seite Configuration (Konfiguration) in der Environment Management Console.

Anmerkung

Sie können die URL-Pfad für die Veröffentlichung von Worker-Warteschlangen-Nachrichten konfigurieren, nicht aber den IP-Port. Elastic Beanstalk sendet Worker-Warteschlangennachrichten immer über Port 80. Die Anwendung der Worker-Umgebung oder ihr Proxy müssen Port 80 überwachen.

So konfigurieren Sie den Worker-Daemon

1. Öffnen Sie die Elastic-Beanstalk-Konsole und wählen Sie in der Liste Regions (Regionen) Ihre AWS-Region aus.

2. Wählen Sie im Navigationsbereich Environments (Umgebungen) aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.

   Anmerkung

   Wenn Sie viele Umgebungen haben, verwenden Sie die Suchleiste, um die Umgebungsliste zu filtern.

3. Wählen Sie im Navigationsbereich Configuration (Konfiguration) aus.

4. Wählen Sie in der Konfigurationskategorie Worker die Option Edit (Bearbeiten).

Die Konfigurationsseite Modify worker (Worker ändern) verfügt über die folgenden Optionen.

Im Abschnitt Queue (Warteschlange):

• Worker queue – Geben Sie die Amazon SQS-Warteschlange an, die vom Daemon gelesen wird. Sofern verfügbar, können Sie eine vorhandene Warteschlange auswählen. Wenn Sie Autogenerated queue (Automatisch generierte Warteschlange) auswählen, erstellt Elastic Beanstalk eine neue Amazon SQS-Warteschlange und eine entsprechende Worker-Warteschlangen-URL.

  Anmerkung

  Wenn Sie Autogenerated queue (Automatisch generierte Warteschlange) auswählen, erstellt Elastic Beanstalk eine Amazon SQS-Standard-Warteschlange. Wenn Sie eine vorhandene Warteschlange auswählen, können Sie entweder eine Standard- oder eine FIFO--Amazon SQS-Warteschlange angeben. Beachten Sie, dass bei Angabe einer FIFO-Warteschlange regelmäßige Aufgaben nicht unterstützt werden.

• Worker queue URL (URL für Worker-Warteschlange) – Wenn Sie eine vorhandene Worker queue (Worker-Warteschlange) auswählen, wird in dieser Einstellung die URL für diese Amazon SQS-Warteschlange angezeigt.

Im Abschnitt Messages (Nachrichten):

• HTTP path – Geben Sie den relativen Pfad zur Anwendung an, die Daten von der Amazon SQS-Warteschlange empfängt. Die Daten werden in den Nachrichtentext einer HTTP POST-Nachricht eingebunden. Der Standardwert ist /.

• MIME type (MIME-Typ) – Geben Sie den von der HTTP POST-Nachricht verwendeten MIME-Typ an. Der Standardwert ist application/json. Allerdings sind alle Werte gültig, da Sie einen eigenen MIME-Typ erstellen und dann angeben können.

• HTTP connections (HTTP-Verbindungen) – Geben Sie die maximale Anzahl gleichzeitiger Verbindungen an, die vom Daemon zu jeder Anwendung auf einer Amazon EC2-Instance hergestellt werden kann. Der Standardwert ist 50. Sie können 1 bis 100 eingeben.

• Visibility timeout – Geben Sie die Zeitspanne, die eine eingehende Nachricht aus der Amazon SQS-Warteschlange zur Verarbeitung gesperrt ist, in Sekunden an. Nach Ablauf des konfigurierten Zeitraums wird die Nachricht in der Warteschlange wieder sichtbar und kann von einem anderen Daemon gelesen werden. Wählen Sie einen Wert aus, der über der erwarteten Verarbeitungszeit der Nachricht durch die Anwendung liegt, bis max. 43200 Sekunden.

• Error visibility timeout – Geben Sie die zu verstreichende Zeitspanne, bevor Elastic Beanstalk eine Nachricht nach einem fehlgeschlagenen Verarbeitungsversuch mit einem expliziten Fehler an die Amazon SQS-Warteschlange zurückgibt, in Sekunden an. Sie können 0 bis 43200 Sekunden eingeben.

Führen Sie im Abschnitt Advanced options (Erweiterte Optionen) Folgendes durch:

• Max retries – Geben Sie die maximale Anzahl der Wiederholversuche für Elastic Beanstalk vor, um die Nachricht an die Amazon SQS-Warteschlange zu senden, bevor die Nachricht in die Warteschlange für unzustellbare Nachrichten verschoben wird. Der Standardwert ist 10. Sie können 1 bis 100 eingeben.

  Anmerkung

  Die Option Max retries (Maximale Wiederholungen) gilt nur für Amazon-SQS-Warteschlangen, die mit einer Warteschlange für unzustellbare Nachrichten konfiguriert sind. Für alle Amazon-SQS-Warteschlangen, die nicht mit einer Warteschlange für unzustellbare Nachrichten konfiguriert sind, werden Nachrichten in der Warteschlange von Amazon SQS aufbewahrt und verarbeitet, bis der durch die Option Retention period (Aufbewahrungszeitraum) angegebene Zeitraum abläuft.

• Connection timeout (Zeitbeschränkung für Verbindung) – Geben Sie die Zeitspanne, die auf erfolgreiche Verbindungserstellungen zu einer Anwendung gewartet wird, in Sekunden an. Der Standardwert ist 5. Sie können 1 bis 60 Sekunden eingeben.

• Inactivity timeout (Zeitbeschränkung für Inaktivität) – Geben Sie die Zeitspanne, die bei einer bestehenden Verbindung zu einer Anwendung auf eine Antwort gewartet wird, in Sekunden an. Der Standardwert ist 180. Sie können 1 bis 36000 Sekunden eingeben.

• Retention period (Aufbewahrungszeitraum) – Geben Sie die Zeitspanne, die eine Nachricht gültig ist und aktiv verarbeitet wird, in Sekunden an. Der Standardwert ist 345600. Sie können 60 bis 1209600 Sekunden eingeben.

Bei Verwendung einer vorhandenen Amazon SQS-Warteschlange kann zwischen den Einstellungen, die Sie bei der Worker-Umgebungserstellung konfiguriert haben, und den direkt von Ihnen in Amazon SQS konfigurierten Einstellungen ein Konflikt entstehen. Wenn beispielsweise der für eine Worker-Umgebung konfigurierte RetentionPeriod-Wert über dem in Amazon SQS festgelegten MessageRetentionPeriod-Wert ist, wird die Nachricht bei einer Überschreitung des MessageRetentionPeriod-Werts von Amazon SQS gelöscht.

Umgekehrt gilt dasselbe: Wenn der in den Worker-Umgebungseinstellungen konfigurierte RetentionPeriod-Wert niedriger ist als der in Amazon SQS definierte MessageRetentionPeriod-Wert, wird die Nachricht vom Daemon gelöscht, bevor Amazon SQS den Löschvorgang ausführt. Der für den Daemon in den Worker-Umgebungseinstellungen konfigurierte Wert setzt den in Amazon SQS eingestellten VisibilityTimeout-Wert für VisibilityTimeout außer Kraft. Stellen Sie sicher, dass Nachrichten angemessen gelöscht werden, indem Sie Ihre Elastic Beanstalk-Einstellungen mit Ihren Amazon SQS-Einstellungen vergleichen.