Lambda-Ausführungsumgebung - AWS Lambda
Laufzeitumgebungs-Lebenszyklus

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.

Lambda-Ausführungsumgebung

Lambda ruft Ihre Funktion in einer Ausführungsumgebung auf, die eine sichere und isolierte Laufzeitumgebung bereitstellt. Die Ausführungsumgebung verwaltet die Ressourcen, die zum Ausführen Ihrer Funktion erforderlich sind. Die Ausführungsumgebung bietet auch Lebenszyklusunterstützung für die Laufzeit der Funktion und alle externen Erweiterungen die mit Ihrer Funktion verknüpft sind.

Die Laufzeitumgebung der Funktion kommuniziert Lambda mit der Laufzeit-API. Erweiterungen kommunizieren mit Lambda über die Erweiterungs-API. Erweiterungen können mithilfe der Telemetrie-API auch Protokollnachrichten und andere Telemetriedaten von der Funktion empfangen.

Architekturdiagramm der Ausführungsumgebung.

Wenn Sie Ihre Lambda-Funktion erstellen, geben Sie Konfigurationsinformationen an, z. B. den verfügbaren Arbeitsspeicher und die maximal zulässige Ausführungszeit für Ihre Funktion. Lambda verwendet diese Informationen, um die Ausführungsumgebung einzurichten.

Die Laufzeit der Funktion und jede externe Erweiterung sind Prozesse, die innerhalb der Ausführungsumgebung ausgeführt werden. Berechtigungen, Ressourcen, Anmeldeinformationen und Umgebungsvariablen werden von der Funktion und den Erweiterungen gemeinsam genutzt.

Lebenszyklus der Lambda-Ausführungsumgebung

Auf die Init-Phase folgen ein oder mehrere Funktionsaufrufe. Wenn keine Aufrufanforderungen vorhanden sind, initiiert Lambda die Shutdown-Phase.

Jede Phase beginnt mit einem Ereignis, das Lambda an die Laufzeit und an alle registrierten Erweiterungen sendet. Die Laufzeit und jede Erweiterung zeigen den Abschluss durch Senden einer Next-API-Anfrage an. Lambda friert die Ausführungsumgebung ein, wenn die Laufzeit und jede Erweiterung abgeschlossen sind und keine ausstehenden Ereignisse vorhanden sind.

Init-Phase

Lambda führt in der Init-Phase drei Aufgaben aus:

  • Alle Erweiterungen starten (Extension init)

  • Laufzeit-Bootstrap (Runtime init)

  • Ausführen des statischen Codes der Funktion (Function init)

  • LaufzeitbeforeCheckpoint-Hooks ausführen ( SnapStart nur Lambda)

Die Init-Phase endet, wenn die Laufzeit und alle Erweiterungen signalisieren, dass sie bereit sind, indem sie eine Next-API-Anforderung senden. Die Init-Phase ist auf 10 Sekunden begrenzt. Wenn alle drei Aufgaben nicht innerhalb von 10 Sekunden abgeschlossen werden, versucht Lambda die Init-Phase zum Zeitpunkt des ersten Funktionsaufrufs mit dem konfigurierten Funktionstimeout erneut.

Wenn Lambda SnapStart aktiviert ist, findet die Init-Phase statt, wenn Sie eine Funktionsversion veröffentlichen. Lambda speichert einen Snapshot des Arbeitsspeichers und des Festplattenzustands der initialisierten Ausführungsumgebung, speichert den verschlüsselten Snapshot und speichert ihn im Cache für den Zugriff mit geringer Latenz. Wenn Sie über einen beforeCheckpoint-Laufzeit-Hook verfügen, wird der Code am Ende der Init-Phase ausgeführt.

Anmerkung

Das Timeout von 10 Sekunden gilt nicht für Funktionen, die bereitgestellte Gleichzeitigkeit oder verwenden SnapStart. Für bereitgestellte Gleichzeitigkeit und SnapStart Funktionen kann Ihr Initialisierungscode bis zu 15 Minuten lang ausgeführt werden. Das Zeitlimit beträgt 130 Sekunden oder das konfigurierte Funktions-Timeout (maximal 900 Sekunden), je nachdem, welcher Wert höher ist.

Wenn Sie die bereitgestellte Gleichzeitigkeit verwenden, initialisiert Lambda die Ausführungsumgebung, wenn Sie die PC-Einstellungen für eine Funktion konfigurieren. Lambda stellt außerdem sicher, dass initialisierte Ausführungsumgebungen vor Aufrufen immer verfügbar sind. Möglicherweise treten Lücken zwischen den Aufruf- und Initialisierungsphasen Ihrer Funktion auf. Abhängig von der Laufzeit- und Speicherkonfiguration Ihrer Funktion können beim ersten Aufruf in einer initialisierten Ausführungsumgebung auch variable Latenzzeiten auftreten.

Bei Funktionen, die On-Demand-Gleichzeitigkeit nutzen, initialisiert Lambda gelegentlich Ausführungsumgebungen vor Aufrufanfragen. In diesem Fall stellen Sie möglicherweise auch eine Zeitlücke zwischen der Initialisierungs- und der Aufrufphase Ihrer Funktion fest. Wir empfehlen Ihnen, sich nicht von diesem Verhalten abhängig zu machen.

Fehler in der Initialisierungsphase

Wenn eine Funktion in der Init-Phase abstürzt oder ein Timeout auftritt, gibt Lambda Fehlerinformationen im INIT_REPORT-Protokoll aus.

Beispiel – INIT_REPORT-Protokoll für Timeout
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
Beispiel – INIT_REPORT-Protokoll für den Erweiterungsfehler
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash

Wenn die -InitPhase erfolgreich ist, gibt Lambda das INIT_REPORT Protokoll nicht aus, es sei denn, SnapStart ist aktiviert. SnapStart Funktionen geben immer ausINIT_REPORT. Weitere Informationen finden Sie unter Überwachung für Lambda SnapStart.

Wiederherstellungsphase ( SnapStart nur Lambda)

Wenn Sie zum ersten Mal eine SnapStart Funktion aufrufen und wenn die Funktion hochskaliert wird, nimmt Lambda neue Ausführungsumgebungen aus dem persistenten Snapshot wieder auf, anstatt die Funktion von Grund auf neu zu initialisieren. Wenn Sie über einen afterRestore()-Laufzeit-Hook verfügen, wird der Code am Ende der Restore-Phase ausgeführt. Die Dauer von afterRestore()-Laufzeit-Hooks wird Ihnen in Rechnung gestellt. Die Laufzeit (JVM) muss geladen werden und afterRestore()-Laufzeit-Hooks müssen innerhalb des Timeout-Limits(10 Sekunden) abgeschlossen werden. Andernfalls erhalten Sie eine SnapStartTimeoutException. Wenn die Restore-Phase abgeschlossen ist, ruft Lambda den Funktionshandler (Invoke-Phase) auf.

Fehler in der Wiederherstellphase

Wenn die Restore-Phase fehlschlägt, gibt Lambda Fehlerinformationen im RESTORE_REPORT-Protokoll aus.

Beispiel – RESTORE_REPORT-Protokoll für Timeout
RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
Beispiel – RESTORE_REPORT-Protokoll für einen Laufzeit-Hook-Fehler
RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError

Weitere Informationen zum RESTORE_REPORT-Protokoll finden Sie unter Überwachung für Lambda SnapStart.

Invoke-Phase

Wenn eine Lambda-Funktion als Antwort auf eine Next-API-Anforderung aufgerufen wird, sendet Lambda ein Invoke-Ereignis an die Laufzeit und an jede Erweiterung.

Die Timeout-Einstellung der Funktion begrenzt die Dauer der gesamten Invoke-Phase. Wenn Sie beispielsweise die Zeitüberschreitung für die Funktion auf 360 Sekunden festlegen, müssen die Funktion und alle Erweiterungen innerhalb von 360 Sekunden abgeschlossen werden. Beachten Sie, dass es keine unabhängige Post-Invoke-Phase gibt. Die Dauer ist die Summe der gesamten Aufrufzeit (Laufzeit + Erweiterungen) und wird erst berechnet, wenn die Funktion und alle Erweiterungen vollständig ausgeführt wurden.

Die Invoke-Phase endet nach der Laufzeit und alle Erweiterungen signalisieren durch Senden einer Next-API-Anforderung dass sie abgeschlossen sind.

Fehler während der Aufrufphase

Wenn die Lambda-Funktion während der Invoke-Phase abstürzt oder das Zeitlimit überschreitet, setzt Lambda die Ausführungsumgebung zurück. Das folgende Diagramm veranschaulicht das Verhalten der Lambda-Ausführungsumgebung bei einem Aufruffehler:

In folgendem Diagramm:

  • Ist die erste Phase die INIT-Phase, die ohne Fehler läuft.

  • Ist die zweite Phase die INVOKE-Phase, die ohne Fehler läuft.

  • Angenommen, Ihre Funktion tritt zu einem Aufruffehler auf (z. B. ein Funktionstimeout oder einen Laufzeitfehler). Die dritte Phase mit der Bezeichnung INVOKE MIT FEHLER veranschaulicht dieses Szenario. Wenn dies geschieht, führt der Lambda-Service einen Neustart durch. Der Reset verhält sich wie ein Shutdown-Ereignis. Zuerst beendet Lambda die Laufzeit und sendet dann ein Shutdown-Ereignis an jede registrierte externe Erweiterung. Das Ereignis enthält den Grund für das Abschalten. Wenn diese Umgebung für einen neuen Aufruf verwendet wird, initialisiert Lambda die Erweiterung und die Laufzeit als Teil des nächsten Aufrufers erneut.

    Anmerkung

    Der Lambda-Reset löscht den/tmpVerzeichnisinhalt vor der nächsten Init-Phase. Dieses Verhalten stimmt mit der regulären Shutdown-Phase überein.

  • Die vierte Phase stellt die INVOKE-Phase unmittelbar nach einem Aufruffehler dar. Hier initialisiert Lambda die Umgebung erneut, indem es die INIT-Phase erneut ausführt. Dies wird als unterdrückte Initialisierung bezeichnet. Wenn unterdrückte Initialisierungen auftreten, meldet Lambda nicht explizit eine zusätzliche INIT-Phase in - CloudWatch Protokollen. Stattdessen stellen Sie möglicherweise fest, dass die Dauer in der REPORT-Zeile eine zusätzliche INIT-Dauer plus die INVOKE-Dauer enthält. Angenommen, Sie sehen die folgenden Protokolle in CloudWatch:

    2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST 
2022-12-20T01:00:02.500-08:00 END RequestId: XXX 
2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms 
Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB

    In diesem Beispiel beträgt der Unterschied zwischen den Zeitstempeln BERICHT und START 2,5 Sekunden. Dies entspricht nicht der angegebenen Dauer von 3 022,91 Millsekunden, da es die zusätzliche INIT (unterdrückte Initialisierung), die Lambda ausgeführt hat, nicht berücksichtigt. In diesem Beispiel können Sie ableiten, dass die tatsächliche INVOKE-Phase 2,5 Sekunden gedauert hat.

    Für mehr Einblick in dieses Verhalten können Sie die Lambda-Telemetrie-API verwenden. Die Telemetrie-API gibt INIT_START, INIT_RUNTIME_DONE und INIT_REPORT-Ereignisse mit phase=invoke immer dann aus, wenn unterdrückte Initialisierungen zwischen den Aufrufphasen auftreten.

  • Die fünfte Phase stellt die SHUTDOWN-Phase dar, die fehlerfrei abläuft.

Shutdown-Phase

Wenn Lambda dabei ist, die Laufzeit herunterzufahren, sendet es ein Shutdown-Ereignis an jede registrierte externe Erweiterung. Erweiterungen können diese Zeit für abschließende Bereinigungsaufgaben verwenden. Das Shutdown-Ereignis ist eine Antwort auf eine Next-API-Anforderung.

Duration (Dauer): Die gesamte Shutdown-Phase ist auf 2 Sekunden begrenzt. Wenn die Laufzeit oder eine Erweiterung nicht reagiert, beendet Lambda sie über ein Signal (SIGKILL).

Nachdem die Funktion und alle Erweiterungen abgeschlossen sind, behält Lambda die Ausführungsumgebung für einige Zeit im Vorgriff auf einen anderen Funktionsaufruf bei. Tatsächlich friert Lambda die Ausführungsumgebung ein. Wenn die Funktion erneut aufgerufen wird, aktiviert Lambda die Umgebung zur wieder zur weiteren Verwendung. Die Wiederverwendung der Ausführungsumgebung hat folgende Auswirkungen:

  • Objekte, die außerhalb der Handler-Methode der Funktion deklariert sind, bleiben initialisiert und bieten eine zusätzliche Optimierung, wenn die Funktion erneut aufgerufen wird. Beispiel: Falls Ihre Lambda-Funktion eine Datenbankverbindung herstellt, statt die Verbindung neu herzustellen, wird die ursprüngliche Verbindung bei nachfolgenden Aufrufen verwendet. Wir empfehlen, dass Sie Ihrem Code eine Logik hinzufügen, um zu prüfen, ob eine Verbindung besteht, bevor Sie eine neue erstellen.

  • Jede Ausführungsumgebung stellt Speicherplatz von 512 MB bis 10 240 MB, in 1-MB-Schritten, im Verzeichnis /tmp zur Verfügung. Der Inhalt des Verzeichnisses bleibt bestehen, wenn die Ausführungsumgebung eingefroren ist, und bietet einen temporären Zwischenspeicher, der für mehrere Aufrufe verwendet werden kann. Sie können zusätzlichen Code hinzufügen, um zu prüfen, ob der Cache die gespeicherten Daten enthält. Weitere Informationen zu Beschränkungen der Bereitstellungsgröße finden Sie unter Lambda-Kontingente.

  • Hintergrundprozesse oder Callbacks, die von Ihrer Lambda-Funktion initiiert wurden und nicht abgeschlossen wurden, wenn die Funktion beendet wurde, werden wieder aufgenommen, wenn Lambda die Ausführungsumgebung wiederverwendet. Sie sollten sicherstellen, dass alle Hintergrundprozesse oder Callbacks in Ihrem Code abgeschlossen sind, bevor der Code beendet wird.

Wenn Sie den Code Ihrer Funktion schreiben, gehen Sie nicht davon aus, dass Lambda die Ausführungsumgebung automatisch für künftige Funktionsaufrufe wiederverwendet. Es kann andere Faktoren geben, die erfordern, dass Lambda eine neue Ausführungsumgebung erstellt, was zu unerwarteten Ergebnissen führen kann, etwa zu fehlgeschlagenen Datenbankverbindungen.