Den Lebenszyklus der Lambda-Ausführungsumgebung verstehen - AWS Lambda
Laufzeitumgebungs-LebenszyklusUmsetzung der Staatenlosigkeit

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.

Den Lebenszyklus der Lambda-Ausführungsumgebung verstehen

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 Laufzeit der Funktion kommuniziert über die Runtime mit Lambda. API Erweiterungen kommunizieren mit Lambda über die Erweiterungen API. Erweiterungen können mithilfe der Telemetrie auch Protokollnachrichten und andere Telemetriedaten von der Funktion empfangen. API

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

Lambda-Lebenszyklusphasen: Init, Invoke, Shutdown

Jede Phase beginnt mit einem Ereignis, das Lambda an die Laufzeit und an alle registrierten Erweiterungen sendet. Die Laufzeit und jede Erweiterung geben den Abschluss an, indem eine Anfrage gesendet wird. Next API 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)

  • Führen Sie alle beforeCheckpoint Runtime-Hooks aus ( SnapStart nur Lambda)

Die Init Phase endet, wenn die Runtime und alle Erweiterungen durch Senden einer Next API Anfrage signalisieren, dass sie bereit sind. 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 10-Sekunden-Timeout gilt nicht für Funktionen, die bereitgestellte Parallelität oder verwenden. SnapStart Bei bereitgestellter Parallelität 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 Log für Timeout
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
Beispiel — INIT _ REPORT protokolliert den Fehler bei der Erweiterung
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash

Wenn die Init Phase erfolgreich ist, gibt Lambda das Protokoll nicht aus INIT_REPORT — es sei denn, es SnapStartist aktiviert. SnapStart Funktionen senden immer aus. INIT_REPORT Weitere Informationen finden Sie unter Überwachung für Lambda SnapStart.

Wiederherstellungsphase ( SnapStart nur Lambda)

Wenn Sie eine SnapStartFunktion zum ersten Mal aufrufen und die Funktion skaliert 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 Runtime (JVM) muss geladen und die afterRestore() Runtime-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 logge dich für das Timeout ein
RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
Beispiel — RESTORE _ REPORT protokolliert den Ausfall eines Runtime-Hooks
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 Anfrage 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 Aufrufphase endet nach der Laufzeit und alle Erweiterungen signalisieren, dass sie fertig sind, indem sie eine Anfrage senden. Next API

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:

Beispiel für eine Ausführungsumgebung: Init, Invoke, Invoke with Error, Invoke, Shutdown

In folgendem Diagramm:

  • Die erste Phase ist die INITPhase, die ohne Fehler läuft.

  • Die zweite Phase ist die INVOKEPhase, die ohne Fehler läuft.

  • Angenommen, Ihre Funktion tritt zu einem Aufruffehler auf (z. B. ein Funktionstimeout oder einen Laufzeitfehler). Die dritte Phase, beschriftet INVOKEWITHERROR, 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.

    Beachten Sie, dass der Lambda-Reset den /tmp Verzeichnisinhalt nicht vor der nächsten Init-Phase löscht. Dieses Verhalten stimmt mit der regulären Shutdown-Phase überein.

    Anmerkung

    AWS implementiert derzeit Änderungen am Lambda-Service. Aufgrund dieser Änderungen können Sie geringfügige Unterschiede zwischen der Struktur und dem Inhalt von Systemprotokollnachrichten und Trace-Segmenten feststellen, die von verschiedenen Lambda-Funktionen in Ihrem AWS-Konto ausgegeben werden.

    Wenn die Systemprotokollkonfiguration Ihrer Funktion auf Klartext eingestellt ist, wirkt sich diese Änderung auf die Protokollmeldungen aus, die in CloudWatch Logs erfasst werden, wenn bei Ihrer Funktion ein Aufruffehler auftritt. Die folgenden Beispiele zeigen Protokollausgaben sowohl in alten als auch in neuen Formaten.

    Diese Änderungen werden in den kommenden Wochen implementiert, und alle Funktionen AWS-Regionen außer China und den GovCloud Regionen werden auf die Verwendung von Protokollnachrichten und Trace-Segmenten im neuen Format umgestellt.

    Beispiel CloudWatch Protokolliert die Protokollausgabe (Laufzeit- oder Erweiterungsabsturz) — alter Stil
    START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason
Runtime.ExitError
END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB
    Beispiel CloudWatch Protokolliert die Protokollausgabe (Funktions-Timeout) im alten Stil
    START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds
END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3000 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms

    Das neue Format für CloudWatch Protokolle enthält ein zusätzliches status Feld in der REPORT Zeile. Im Fall eines Laufzeit- oder Erweiterungsabsturzes enthält die REPORT Zeile auch ein FeldErrorType.

    Beispiel CloudWatch Protokolliert die Protokollausgabe (Laufzeit- oder Erweiterungsabsturz) — neuer Stil
    START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 133 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError
    Beispiel CloudWatch Protokolliert die Protokollausgabe (Funktions-Timeout) — neuer Stil
    START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3016 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout

  • Die vierte Phase stellt die Phase dar, die INVOKEunmittelbar auf einen fehlgeschlagenen Aufruf folgt. Hier initialisiert Lambda die Umgebung erneut, indem die Phase erneut ausgeführt wird. INIT Dies wird als unterdrückte Initialisierung bezeichnet. Wenn unterdrückte Inits auftreten, meldet Lambda nicht explizit eine zusätzliche INITPhase in Logs. CloudWatch Stattdessen stellen Sie möglicherweise fest, dass die Dauer in der REPORT Zeile eine zusätzliche INITDauer plus die Dauer umfasst. INVOKE Nehmen wir zum Beispiel an, dass Sie die folgenden Logs sehen 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 START Zeitstempeln REPORT und 2,5 Sekunden. Dies entspricht nicht der gemeldeten Dauer von 3022,91 Millsekunden, da die zusätzliche INIT(unterdrückte Init), die Lambda durchgeführt hat, nicht berücksichtigt wird. In diesem Beispiel können Sie ableiten, dass die eigentliche Phase 2,5 Sekunden gedauert hat. INVOKE

    Für mehr Einblick in dieses Verhalten können Sie die Zugreifen auf Echtzeit-Telemetriedaten für Erweiterungen mithilfe der Telemetrie API verwenden. Die API Telemetrie gibt immer dann INIT_STARTINIT_RUNTIME_DONE, phase=invoke wenn zwischen den Aufrufphasen unterdrückte Initialisierungen auftreten, und INIT_REPORT Ereignisse aus.

  • Die fünfte Phase stellt die Phase dar, die ohne Fehler SHUTDOWNablä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 Anfrage.

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. Lambda beendet die Ausführungsumgebungen jedoch alle paar Stunden, um Laufzeitaktualisierungen und Wartungsarbeiten zu ermöglichen — auch für Funktionen, die kontinuierlich aufgerufen werden. Sie sollten nicht davon ausgehen, dass die Ausführungsumgebung auf unbestimmte Zeit bestehen bleibt. Weitere Informationen finden Sie unter Implementierung von Staatenlosigkeit in Funktionen.

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.

Implementierung von Staatenlosigkeit in Funktionen

Wenn Sie Ihren Lambda-Funktionscode schreiben, behandeln Sie die Ausführungsumgebung als zustandslos und gehen Sie davon aus, dass sie nur für einen einzigen Aufruf existiert. Lambda beendet Ausführungsumgebungen alle paar Stunden, um Laufzeitaktualisierungen und Wartungsarbeiten zu ermöglichen — auch für Funktionen, die kontinuierlich aufgerufen werden. Initialisieren Sie jeden erforderlichen Status (z. B. das Abrufen eines Einkaufswagens aus einer Amazon DynamoDB-Tabelle), wenn Ihre Funktion gestartet wird. Übernehmen Sie vor dem Beenden permanente Datenänderungen in dauerhafte Speicher wie Amazon Simple Storage Service (Amazon S3), DynamoDB oder Amazon Simple Queue Service (Amazon). SQS Vermeiden Sie es, sich auf bestehende Datenstrukturen, temporäre Dateien oder Zustände zu verlassen, die sich über mehrere Aufrufe erstrecken, wie Zähler oder Aggregate. Dadurch wird sichergestellt, dass Ihre Funktion jeden Aufruf unabhängig verarbeitet.