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 Ausführungsumgebung von Lambda Managed Instances
Lambda Managed Instances bieten ein alternatives Bereitstellungsmodell, bei dem Ihr Funktionscode auf kundeneigenen Amazon EC2 EC2-Instances ausgeführt wird, während Lambda die betrieblichen Aspekte verwaltet. Die Ausführungsumgebung für Managed Instances weist mehrere wichtige Unterschiede zu Lambda-Funktionen (Standard) auf, insbesondere darin, 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 Funktionsausführungsumgebung für Lambda Managed Instances 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
-
Bootstrap für den Laufzeit-Einstiegspunkt. Runtime erzeugt die konfigurierte Anzahl von Runtime-Workern (die Implementierung hängt von der Laufzeit ab)
-
Führen Sie den Initialisierungscode der Funktion aus (Code außerhalb des Handlers)
-
Warten Sie, bis mindestens ein Runtime-Worker die Bereitschaft signalisiert, indem er aufruft
/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
Für Funktionen von Lambda Managed Instances 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 Funktionen von Lambda Managed Instances weist mehrere einzigartige Merkmale auf:
Kontinuierlicher Betrieb. Im Gegensatz zu Lambda (Standard) bleibt die Ausführungsumgebung kontinuierlich aktiv und verarbeitet Aufrufe, sobald sie eintreffen, ohne dass sie zwischen den Aufrufen einfrieren.
Parallele Verarbeitung. In derselben Ausführungsumgebung können mehrere Aufrufe gleichzeitig ausgeführt werden, wobei jeder Aufruf 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 eine Zeitüberschreitung eintritt, markiert Lambda diesen bestimmten Aufruf als fehlgeschlagen, unterbricht jedoch keine anderen laufenden Aufrufe und beendet die Ausführungsumgebung nicht.
Behandlung von Gegendruck. Wenn alle Runtime-Worker mit der Verarbeitung von Aufrufen beschäftigt sind, werden neue Aufrufanforderungen zurückgewiesen, bis ein Worker verfügbar ist.
Fehlerbehandlung und Wiederherstellung
Die Fehlerbehandlung in Umgebungen zur Funktionsausführung von Lambda Managed Instances unterscheidet sich von Lambda (Standard):
Fehler beim Runtime-Worker. Wenn ein Runtime-Worker-Prozess abstürzt, arbeitet die Ausführungsumgebung mit den verbleibenden fehlerfreien Workern weiter.
Die Erweiterung stürzt ab. Wenn ein Erweiterungsprozess während der Initialisierung oder des Betriebs 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 Timeout ü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 läuft weiterhin in der Ausführungsumgebung. Als Funktionsentwickler sind Sie dafür verantwortlich, das Timeout zu erkennen und zu behandeln. Das Kontextobjekt gibt die verbleibende Zeit für den Aufruf an. Ein Wert von Null oder einem negativen Wert gibt an, dass das Zeitlimit für den Aufruf überschritten wurde. Andere gleichzeitige Aufrufe in der Ausführungsumgebung setzen die Verarbeitung normal fort.
Wiederholungsverhalten
Wenn bei einem Aufruf das Timeout überschritten wird:
-
Synchrone Aufrufe: Der Anrufer erhält den Timeout-Fehler und ist dafür verantwortlich, es erneut zu versuchen.
-
Asynchrone Aufrufe: Lambda-Wiederholungen basierend auf der Wiederholungsrichtlinie Ihrer Funktion (Standard: 2 Wiederholungen). Wenn alle Wiederholungsversuche erschöpft sind, wird das Ereignis an die konfigurierte Warteschlange für unzustellbare Nachrichten oder, falls vorhanden, an das Ziel für den Fall eines Fehlers gesendet.
-
Zuordnungen von Ereignisquellen: Das Verhalten bei Wiederholungen hängt von der Konfiguration der Ereignisquelle ab (z. B. Batchgröße, Halbierung bei Fehler, maximale Anzahl von Wiederholungsversuchen). Der Batch kann je nach Ihren Wiederholungsrichtlinien erneut versucht oder an ein Ziel gesendet werden, wenn ein Fehler auftritt.
Was passiert, wenn Sie das Timeout nicht bewältigen
Wenn Ihr Code die verbleibende Zeit nicht überprüft und die Ausführung stoppt:
-
Der Aufruf ist bereits als fehlgeschlagen markiert. Lambda hat dem Aufrufer bereits einen Timeout-Fehler zurückgegeben — jede Arbeit, die Ihr Code nach dem Timeout abschließt, geht aus Sicht des Aufrufers praktisch verloren.
-
Ressourcen werden weiterhin verbraucht. Ihr Code belegt weiterhin einen Runtime-Worker-Slot, wodurch die Parallelität, die für neue Aufrufe auf dieser Instance zur Verfügung steht, reduziert wird.
-
Nichtdeterministisches Verhalten. Ihr Code stoppt nicht, wenn der Timeout ausgelöst wird, sondern läuft weiter im Hintergrund. Das bedeutet, dass Nebenwirkungen immer noch auftreten können, nachdem Lambda dem Anrufer 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 weiterhin eine SNS-Benachrichtigung. Der Aufrufer wiederholt den Aufruf, wodurch der Datensatz erneut geschrieben und die Benachrichtigung erneut gesendet wird. Sie haben jetzt doppelte Daten und doppelte Benachrichtigungen — und es ist nicht leicht zu erkennen, welche von dem „fehlgeschlagenen“ Aufruf stammen, der immer 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 die Verarbeitung jedes Elements beispielsweise etwa 500 ms benötigt, legen Sie den Puffer auf mindestens 500 ms plus Rand fest.
Sprachspezifische Beispiele für die Behandlung von Timeouts finden Sie im Abschnitt zum Anforderungskontext auf jeder Runtime-Seite:
