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.
Grundlegendes zur Lambda Managed Instance-Ausführungsumgebung
Lambda Managed Instances bieten ein alternatives Bereitstellungsmodell, bei dem Ihr Funktionscode auf kundeneigenen Amazon EC2-Instances ausgeführt wird, während Lambda die betrieblichen Aspekte verwaltet. Die Ausführungsumgebung für Managed Instances weist mehrere wichtige Unterschiede zu den Lambda-Funktionen (Standard) auf, insbesondere in der Art und Weise, wie sie gleichzeitige Aufrufe verarbeitet und Container-Lebenszyklen verwaltet.
Hinweis: Informationen zur Lambda-Ausführungsumgebung (Standard) finden Sie unter Grundlegendes zum Lebenszyklus der Lambda-Ausführungsumgebung.
Lebenszyklus der Ausführungsumgebung
Der Lebenszyklus einer Lambda Managed Instances-Funktionsumgebung unterscheidet sich in mehreren wesentlichen Punkten von Lambda (Standard):
Init-Phase
Während der Init-Phase führt Lambda die folgenden Schritte aus:
-
Initialisieren und registrieren Sie alle Erweiterungen
-
Bootstrappen Sie den Runtime-Einstiegspunkt. Runtime erzeugt die konfigurierte Anzahl von Runtime-Workern (die Implementierung hängt von der Laufzeit ab)
-
Führen Sie den Funktionsinitialisierungscode aus (Code außerhalb des Handlers)
-
Warten Sie, bis mindestens ein Runtime-Worker die Bereitschaft signalisiert, indem Sie aufrufen
/runtime/invocation/next
Die Init-Phase gilt als abgeschlossen, wenn die Erweiterungen initialisiert wurden und mindestens ein Runtime-Worker aufgerufen hat. /runtime/invocation/next Die Funktion ist dann bereit, Aufrufe zu verarbeiten.
Anmerkung
Bei Lambda Managed Instances-Funktionen kann die Initialisierung bis zu 15 Minuten dauern. Das Timeout ist das Maximum von 130 Sekunden oder das konfigurierte Funktions-Timeout (bis zu 900 Sekunden).
Invoke-Phase
Die Aufrufphase für Lambda Managed Instances-Funktionen weist mehrere einzigartige Merkmale auf:
Kontinuierlicher Betrieb. Im Gegensatz zu Lambda (Standard) bleibt die Ausführungsumgebung kontinuierlich aktiv und verarbeitet Aufrufe, sobald sie ankommen, ohne dass zwischen den Aufrufen eingefroren wird.
Parallele Verarbeitung. In derselben Ausführungsumgebung können mehrere Aufrufe gleichzeitig ausgeführt werden, wobei jeder von einem anderen Runtime-Worker verarbeitet wird.
Unabhängige Timeouts. Das konfigurierte Timeout der Funktion gilt für jeden einzelnen Aufruf. Wenn bei einem Aufruf ein Timeout auftritt, markiert Lambda diesen bestimmten Aufruf als fehlgeschlagen, unterbricht jedoch weder andere laufende Aufrufe noch beendet die Ausführungsumgebung.
Umgang mit Gegendruck. Wenn alle Runtime-Worker mit der Verarbeitung von Aufrufen beschäftigt sind, werden neue Aufrufanforderungen abgelehnt, bis ein Worker verfügbar ist.
Fehlerbehandlung und Wiederherstellung
Die Fehlerbehandlung in Lambda Managed Instances-Funktionsumgebungen unterscheidet sich von der in Lambda (Standard):
Runtime-Worker-Fehler. Wenn ein Runtime-Worker-Prozess abstürzt, arbeitet die Ausführungsumgebung mit den verbleibenden gesunden Workern weiter.
Die Erweiterung stürzt ab. Wenn ein Erweiterungsprozess während der Initialisierung oder des Vorgangs abstürzt, wird die gesamte Ausführungsumgebung als fehlerhaft markiert und beendet. Lambda erstellt eine neue Ausführungsumgebung, um sie zu ersetzen.
Nein. reset/repair Im Gegensatz zu Lambda (Standard) versuchen Managed Instances nicht, die Ausführungsumgebung nach Fehlern zurückzusetzen und neu zu initialisieren. Stattdessen werden fehlerhafte Container beendet und durch neue ersetzt.
Timeouts aufrufen
Wenn bei einem einzelnen Aufruf das Zeitlimit überschritten wird, gibt Lambda einen Task timed out after <timeout> seconds Fehler mit dem Status Funktionsfehler an den Aufrufer zurück. Lambda Managed Instances beendet Ihren Code jedoch nicht gewaltsam — er wird in der Ausführungsumgebung weiter ausgeführt. Als Funktionsentwickler sind Sie dafür verantwortlich, den Timeout zu erkennen und zu behandeln.
Das Kontextobjekt macht die verbleibende Zeit für den Aufruf verfügbar. Ein Wert von Null oder ein negativer Wert gibt an, dass das Zeitlimit für den Aufruf abgelaufen ist. Andere gleichzeitige Aufrufe in der Ausführungsumgebung setzen die Verarbeitung normal fort.
Wiederholungsverhalten
Wenn ein Aufruf das Zeitlimit überschreitet:
-
Synchrone Aufrufe: Der Anrufer erhält den Timeout-Fehler und ist für den erneuten Versuch verantwortlich.
-
Asynchrone Aufrufe: Lambda-Wiederholungsversuche basieren auf der Wiederholungsrichtlinie Ihrer Funktion (Standardeinstellung: 2 Wiederholungen). Wenn alle Wiederholungsversuche ausgeschöpft sind, wird das Ereignis an die konfigurierte Warteschlange für unzustellbare Nachrichten oder an das Ziel bei einem Ausfall gesendet, falls vorhanden.
-
Zuordnungen der Ereignisquellen: Das Wiederholungsverhalten hängt von der Konfiguration der Ereignisquelle ab (z. B. Stapelgröße, Halbierung bei Fehlern, maximale Anzahl von Wiederholungsversuchen). Der Batch kann je nach Ihren Wiederholungsrichtlinien erneut versucht oder bei einem Ausfall an ein Ziel gesendet werden.
Was passiert, wenn Sie den Timeout nicht einhalten
Wenn Ihr Code die verbleibende Zeit nicht überprüft und die Ausführung stoppt:
-
Der Aufruf ist bereits als fehlgeschlagen markiert. Lambda hat bereits einen Timeout-Fehler an den Anrufer zurückgegeben — jede Arbeit, die Ihr Code nach dem Timeout abschließt, geht aus Sicht des Aufrufers effektiv verloren.
-
Ressourcen bleiben verbraucht. Ihr Code belegt weiterhin einen Runtime-Worker-Slot, wodurch die Parallelität reduziert wird, die für neue Aufrufe auf dieser Instance verfügbar ist.
-
Nichtdeterministisches Verhalten. Ihr Code stoppt nicht, wenn der Timeout ausgelöst wird — er läuft im Hintergrund weiter. Das bedeutet, dass auch dann noch Nebenwirkungen auftreten können, wenn Lambda dem Aufrufer bereits mitgeteilt hat, dass der Aufruf fehlgeschlagen ist.
Ihr Handler schreibt beispielsweise einen Datensatz in DynamoDB, dann wird der Timeout ausgelöst und Lambda gibt einen Timeout-Fehler an den Aufrufer zurück, aber Ihr Code läuft immer noch und sendet eine SNS-Benachrichtigung. Der Anrufer wiederholt den Aufruf, wodurch der Datensatz erneut geschrieben und die Benachrichtigung erneut gesendet wird. Sie haben jetzt doppelte Daten und doppelte Benachrichtigungen — und es gibt keine einfache Möglichkeit herauszufinden, welche von dem „fehlgeschlagenen“ Aufruf stammen, der noch im Hintergrund lief.
Umgang mit Timeouts in Ihrem Code
Verwenden Sie das Kontextobjekt, um die verbleibende Zeit zu überprüfen und die Verarbeitung vor dem Timeout zu beenden. Konfigurieren Sie einen Puffer, der auf der erwarteten Dauer Ihrer nächsten Arbeitseinheit basiert. Wenn beispielsweise die Verarbeitung jedes Elements etwa 500 ms dauert, legen Sie den Puffer auf mindestens 500 ms plus Spielraum fest.
Sprachspezifische Beispiele für die Behandlung von Timeouts finden Sie im Abschnitt zum Anforderungskontext auf jeder Laufzeitseite:
