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 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.

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

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.

Themen

• Init-Phase

• Fehler in der Initialisierungsphase

• Wiederherstellungsphase ( SnapStart nur Lambda)

• Invoke-Phase

• Fehler während der Aufrufphase

• Shutdown-Phase

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)

• Alle Runtime-Hooks vor dem Checkpoint ausführen (nur Lambda) SnapStart

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 einen Laufzeit-Hook vor dem Prüfpunkt haben, wird der Code am Ende der Init-Phase ausgeführt.

Anmerkung

Das 10-Sekunden-Timeout gilt nicht für Funktionen, die bereitgestellte Parallelität verwenden oder. 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-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 Init Phase erfolgreich ist, gibt Lambda das INIT_REPORT Protokoll nicht aus, es sei denn SnapStart, die bereitgestellte Parallelität ist aktiviert. SnapStart und bereitgestellte Parallelitätsfunktionen werden immer ausgegeben. 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 einen Runtime-Hook nach der Wiederherstellung haben, wird der Code am Ende der Phase ausgeführt. Restore Die Dauer der Runtime-Hooks nach der Wiederherstellung wird Ihnen in Rechnung gestellt. Die Runtime muss geladen werden und Runtime-Hooks nach der Wiederherstellung 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.

  Beachten Sie, dass der Lambda-Reset den Inhalt des /tmp-Verzeichnisses vor der nächsten Init-Phase nicht 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 geringfügige Unterschiede in Struktur und Inhalt der Systemprotokollmeldungen und Trace-Segmente auftreten, die von verschiedenen Lambda-Funktionen in Ihrem AWS-Konto.

  Wenn die Systemprotokollkonfiguration Ihrer Funktion auf Klartext eingestellt ist, wirkt sich diese Änderung auf die Protokollnachrichten 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 umgesetzt, und alle Funktionen AWS-Regionen außer China und den GovCloud Regionen werden auf die Verwendung der Protokollnachrichten und Trace-Segmente 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 Falle eines Laufzeit- oder Erweiterungsabsturzes enthält die REPORT-Zeile auch ein Feld ErrorType.

  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 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 Inits auftreten, meldet Lambda nicht explizit eine zusätzliche INIT-Phase in Logs. CloudWatch Stattdessen stellen Sie möglicherweise fest, dass die Dauer in der REPORT-Zeile eine zusätzliche INIT-Dauer plus die INVOKE-Dauer enthält. Nehmen wir zum Beispiel an, 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 Zugriff auf Echtzeit-Telemetriedaten für Erweiterungen über die 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. Lambda beendet jedoch alle paar Stunden die Ausführungsumgebungen, um Laufzeitaktualisierungen und -wartungen zu ermöglichen – selbst bei Funktionen, die kontinuierlich aufgerufen werden. Sie sollten nicht davon ausgehen, dass die Ausführungsumgebung auf unbestimmte Zeit bestehen bleibt. Weitere Informationen finden Sie unter Implementieren Sie 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.

Kaltstarts und Latenzzeiten

Wenn Lambda eine Anfrage zur Ausführung einer Funktion über die Lambda-API erhält, bereitet der Dienst zunächst eine Ausführungsumgebung vor. Während dieser Initialisierungsphase lädt der Dienst Ihren Code herunter, startet die Umgebung und führt jeglichen Initialisierungscode außerhalb des Haupthandlers aus. Schließlich führt Lambda den Handlercode aus.

In diesem Diagramm werden die ersten beiden Schritte des Herunterladens des Codes und der Einrichtung der Umgebung häufig als „Kaltstart“ bezeichnet. Diese Zeit wird Ihnen nicht in Rechnung gestellt, aber dadurch verlängert sich die Latenz Ihrer gesamten Aufrufdauer.

Nach Abschluss des Aufrufs ist die Ausführungsumgebung eingefroren. Um das Ressourcenmanagement und die Leistung zu verbessern, behält Lambda die Ausführungsumgebung für einen bestimmten Zeitraum bei. Wenn während dieser Zeit eine weitere Anfrage für dieselbe Funktion eingeht, kann Lambda die Umgebung wiederverwenden. Diese zweite Anfrage wird in der Regel schneller abgeschlossen, da die Ausführungsumgebung bereits vollständig eingerichtet ist. Dies wird als „Warmstart“ bezeichnet.

Kaltstarts treten in der Regel bei weniger als 1% der Aufrufe auf. Die Dauer eines Kaltstarts variiert zwischen unter 100 ms und über 1 Sekunde. Im Allgemeinen treten Kaltstarts in der Regel häufiger bei Entwicklungs- und Testfunktionen auf als bei Produktionsworkloads. Das liegt daran, dass Entwicklungs- und Testfunktionen in der Regel seltener aufgerufen werden.

Reduzierung von Kaltstarts mit bereitgestellter Parallelität

Wenn Sie vorhersehbare Funktionsstartzeiten für Ihren Workload benötigen, ist Provisioned Concurrency die empfohlene Lösung, um eine möglichst geringe Latenz zu gewährleisten. Mit dieser Funktion werden Ausführungsumgebungen vorinitialisiert, wodurch Kaltstarts reduziert werden.

Bei einer Funktion mit einer bereitgestellten Parallelität von 6 sind beispielsweise 6 Ausführungsumgebungen vorgewärmt.

Optimierung der statischen Initialisierung

Die statische Initialisierung erfolgt, bevor der Handlercode in einer Funktion ausgeführt wird. Dies ist der von Ihnen bereitgestellte Initialisierungscode, der sich außerhalb des Haupthandlers befindet. Dieser Code wird häufig verwendet, um Bibliotheken und Abhängigkeiten zu importieren, Konfigurationen einzurichten und Verbindungen zu anderen Diensten zu initialisieren.

Das folgende Python-Beispiel zeigt das Importieren und Konfigurieren von Modulen und das Erstellen des Amazon S3 S3-Clients während der Initialisierungsphase, bevor die lambda_handler Funktion während des Aufrufs ausgeführt wird.

import os
import json
import cv2
import logging
import boto3

s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):

  # Handler logic...

Den größten Beitrag zur Latenz vor der Funktionsausführung leistet der Initialisierungscode. Dieser Code wird ausgeführt, wenn eine neue Ausführungsumgebung zum ersten Mal erstellt wird. Der Initialisierungscode wird nicht erneut ausgeführt, wenn ein Aufruf eine warme Ausführungsumgebung verwendet. Zu den Faktoren, die die Latenz des Initialisierungscodes beeinflussen, gehören:

• Die Größe des Funktionspakets in Bezug auf importierte Bibliotheken und Abhängigkeiten sowie Lambda-Schichten.

• Die Menge an Code und die Initialisierungsarbeit.

• Die Leistung von Bibliotheken und anderen Diensten beim Aufbau von Verbindungen und anderen Ressourcen.

Entwickler können eine Reihe von Schritten ergreifen, um die statische Initialisierungslatenz zu optimieren. Wenn eine Funktion viele Objekte und Verbindungen hat, können Sie eine einzelne Funktion möglicherweise in mehrere spezialisierte Funktionen umstrukturieren. Diese sind einzeln kleiner und haben jeweils weniger Initialisierungscode.

Es ist wichtig, dass Funktionen nur die Bibliotheken und Abhängigkeiten importieren, die sie benötigen. Wenn Sie beispielsweise nur Amazon DynamoDB im AWS SDK verwenden, können Sie anstelle des gesamten SDK einen einzelnen Service verlangen. Vergleichen Sie die folgenden drei Beispiele:

// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')

// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')

// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)

Die statische Initialisierung ist oft auch der beste Ort, um Datenbankverbindungen zu öffnen, damit eine Funktion Verbindungen über mehrere Aufrufe derselben Ausführungsumgebung wiederverwenden kann. Möglicherweise verfügen Sie jedoch über eine große Anzahl von Objekten, die nur in bestimmten Ausführungspfaden in Ihrer Funktion verwendet werden. In diesem Fall können Sie Variablen im globalen Bereich langsam laden, um die Dauer der statischen Initialisierung zu reduzieren.

Vermeiden Sie globale Variablen für kontextspezifische Informationen. Wenn Ihre Funktion über eine globale Variable verfügt, die nur für die Lebensdauer eines einzelnen Aufrufs verwendet und für den nächsten Aufruf zurückgesetzt wird, verwenden Sie einen Variablenbereich, der für den Handler lokal ist. Dadurch wird nicht nur verhindert, dass globale Variablen bei Aufrufen verloren gehen, sondern verbessert auch die Leistung der statischen Initialisierung.