View a markdown version of this page

Schlüsselkonzepte - AWS Lambda

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.

Schlüsselkonzepte

Wenn Sie die folgenden Kernkonzepte verstehen, können Sie Webanwendungen effektiv bereitstellen und verwalten. Auf dieser Seite werden das Ressourcenmodell einer Webfunktion, die Lebenszyklusstatus jeder Ressource und die Art und Weise behandelt, wie Lambda eingehende HTTP-Anfragen behandelt, behandelt.

Das Ressourcenmodell definiert die Struktur einer Webfunktion. Eine Webfunktion ist die Ressource der obersten Ebene. Sie enthält Revisionen (unveränderliche Schnappschüsse Ihres Codes und Ihrer Konfiguration) und Endpunkte (Netzwerkeingangspunkte, die HTTP-Verkehr zu Ihren Versionen weiterleiten).

Revisionsstatus und Endpunktstatus verfolgen den Fortschritt dieser Ressourcen, während Lambda sie erstellt, bereitstellt und löscht. Durch die Überwachung dieser Zustände erfahren Sie, wann Lambda die Erstellung, Bereitstellung oder Löschung einer Ressource abgeschlossen hat, und hilft Ihnen bei der Diagnose von Fehlern.

Ausführungsumgebungen sind isolierte Recheninstanzen, auf denen Ihr Webserver und Ihre Anwendung ausgeführt werden. Jede Ausführungsumgebung verarbeitet mehrere gleichzeitige HTTP-Anfragen. Lambda erstellt und entfernt automatisch Umgebungen auf der Grundlage Ihrer Webfunktionskonfiguration und Ihres Datenverkehrs.

Die folgenden Abschnitte enthalten detaillierte Informationen zu den einzelnen Kernkonzepten.

Ressourcenmodell

Eine Lambda-Webfunktion besteht aus drei Ressourcentypen in einer Parent-Child-Hierarchie. Die Webfunktion ist die Ressource der obersten Ebene. Revisionen und Endpunkte sind untergeordnete Ressourcen der Webfunktion. Durch das Bereitstellen von Code oder das Ändern der Revisionskonfiguration wird eine neue Revision erstellt. Das folgende Diagramm zeigt eine Webfunktion, deren Endpunkte den Datenverkehr zu ihren Revisionen weiterleiten.

Eine Webfunktion enthält Endpunkte und Revisionen. Der Prod-Endpunkt leitet 90 Prozent des Datenverkehrs an Revision 1 und 10 Prozent an Revision 2 weiter. Der Staging-Endpunkt leitet den gesamten Datenverkehr an Revision 2 weiter.
Web-Funktion

Die Ressource auf oberster Ebene, die Ihre Webanwendung repräsentiert. Eine Webfunktion hat einen Namen, einen ARN und ihren eigenen Lebenszyklusstatus (Ausstehend, Aktiv, Fehlgeschlagen oder Löschen). Sie kann Revisionen und Endpunkte enthalten; alle Revisionen und Endpunkte gehören zu einer einzigen übergeordneten Webfunktion.

Revision

Eine unveränderliche Momentaufnahme Ihres Anwendungscodes und Ihrer Konfiguration. Sie erstellen jedes Mal eine neue Revision, wenn Sie Ihren Code oder Ihre Revisionskonfiguration ändern, z. B. das Anforderungs-Timeout, die maximale Anzahl gleichzeitiger Anfragen pro Ausführungsumgebung oder Umgebungsvariablen. Da Revisionen unveränderlich sind, können Sie jederzeit zu einer früheren Version Ihrer Anwendung zurückkehren, indem Sie den Datenverkehr an eine frühere Version weiterleiten. Bei kanarischen oder blaugrünen Bereitstellungen können Sie den Datenverkehr auf zwei Versionen gleichzeitig verteilen.

Endpunkt

Ein Netzwerkeingangspunkt, der HTTP-Verkehr zu Ihren Revisionen weiterleitet. Jeder Endpunkt hat einen eindeutigen Domainnamen mit TLS, einen Authentifizierungstyp, der den Zugriff steuert, und Skalierungseinstellungen, die die Kapazität definieren. Wenn Sie einen Endpunkt erstellen, wählen Sie seinen Endpunkttyp aus, der seinen geografischen Geltungsbereich festlegt. HomeRegiondient nur dem Verkehr aus der Heimatregion. MultiRegionbedient Datenverkehr aus mehreren Regionen hinter einer globalen Domain, die jede Anfrage auf der Grundlage der Netzwerklatenz nach bestem Wissen und Gewissen an eine Region weiterleitet. PerRegionbedient Traffic aus mehreren Regionen, von denen jede ihre eigene regionale Domain hat, und Sie kontrollieren, wie Kunden jede Region erreichen. Eine Webfunktion kann mehrere Endpunkte haben, von denen jeder eine unabhängige Konfiguration hat. Sie konfigurieren Revisionsgewichte auf einem Endpunkt, um den Datenverkehr an eine oder zwei aktive Revisionen weiterzuleiten.

Status der Revision

Eine Revision durchläuft während ihres Lebenszyklus die folgenden Zustände. Sie können den aktuellen Status überprüfen, indem Sie die Revisionsdetails in der Lambda-Konsole aufrufen GetWebFunctionRevision oder sich diese ansehen.

Status Description Wie geht es weiter?
Ausstehend Lambda erstellt die Revision. Dazu gehört das Herunterladen Ihres Codes von Amazon S3 und die Validierung der Konfiguration. Die Revision wechselt zu Aktiv, wenn die Erstellung erfolgreich ist, oder zu Fehlgeschlagen, wenn ein Fehler auftritt.
Aktiv Die Revision wurde erfolgreich erstellt und kann nun hinter einem Endpunkt abgelegt werden. Die Revision bleibt aktiv, bis Sie sie löschen, Lambda löscht sie während der automatischen Revisionsbereinigung (sieheRevisionsgrenzen und automatische Bereinigung) oder Sie entfernen den Zugriff auf den Quellcode. Wenn Lambda den Zugriff auf den Code verliert, beispielsweise weil die referenzierte Amazon S3 S3-Objektversion gelöscht wurde, wird die Revision in den Status Fehlgeschlagen verschoben (sieheLebenszyklus eines Objekts).
Fehlgeschlagen Lambda konnte die Revision nicht erstellen. Probleme, die Lambda beim Absenden der Anfrage feststellt, führen nicht zu einer Fehlgeschlagenen Revision. Wenn der AWS KMS Schlüssel beispielsweise nicht über ausreichende Berechtigungen verfügt, schlägt die Anfrage mit einer Client-Ausnahme fehl und Lambda erstellt keine Revision. Einzelheiten finden Sie im stateReason Feld in der GetWebFunctionRevision Antwort. Erstellen Sie eine neue Version, um das Problem zu beheben. Fehlgeschlagene Revisionen können den Datenverkehr nicht bedienen.

Endpunktzustände

Ein Endpunkt hat zwei Statusfelder: Er state verfolgt den gesamten Lebenszyklus und updateStatus verfolgt Endpunktaktualisierungen nach der ersten Erstellung. Sie können beide überprüfen, indem Sie anrufenGetWebFunctionEndpoint.

Status Description Wie geht es weiter?
Ausstehend Lambda erstellt den Endpunkt. Dazu gehören die Zuweisung eines Domainnamens, die Bereitstellung von TLS und die Konfiguration des Routings. Dazu gehört auch die Replikation der Konfiguration auf andere PerRegion Endgeräte. MultiRegion AWS-Regionen Der Endpunkt wechselt zu Aktiv, wenn die Erstellung in allen Zielregionen erfolgreich war, oder zu Fehlgeschlagen, wenn ein Fehler auftritt.
Aktiv Der Endpunkt ist bereit, HTTP-Verkehr unter seinem Domainnamen zu empfangen. Clients können Anfragen an den Endpunkt senden. Der Endpunkt bleibt aktiv. Lambda verfolgt nachfolgende Endpunktaktualisierungen vor updateStatus Ort, ohne den Gesamtstatus des Endpunkts zu ändern.
Fehlgeschlagen Die Erstellung ist fehlgeschlagen. Bei MultiRegion PerRegion Endpunkten kann dies auf einen Fehler in einer oder mehreren Zielregionen hinweisen. Einzelheiten finden Sie im stateReason Feld. Überprüfen Sie für MultiRegion PerRegion Endpunkte die regionalEndpoints Einträge für die state und stateReason für jede Region.
Wird gelöscht Lambda löscht den Endpunkt und zieht seinen Domainnamen zurück. Für MultiRegion PerRegion Endpunkte entfernt Lambda den Endpunkt aus allen Regionen. Nach Abschluss des Löschvorgangs wird der Endpunkt dauerhaft entfernt. Sein Domainname ist zurückgezogen und Lambda weist ihn in keinem Konto einem anderen Endpunkt zu. Dieser Vorgang kann nicht rückgängig gemacht werden.

Für einen vorhandenen Endpunkt bleibt Lambda Active während eines Endpunkt-Updates auf state eingestellt. Prüfen updateStatus Sie, ob das neueste Update InProgressSuccessful, oder Failed ist. Wenn Sie beispielsweise die Revisionsgewichte eines Endpunkts ändern, updateStatus state bleibt die InProgress Zeit erhaltenActive. Wenn die neuen Gewichtungen in Kraft sind, updateStatus ändert sich der Wert vonSuccessful.

InProgress

Lambda wendet das Endpunkt-Update an.

Erfolgreich

Das letzte Endpunkt-Update wurde abgeschlossen und ist in Kraft.

Fehlgeschlagen

Das letzte Endpunkt-Update ist fehlgeschlagen. Überprüfen Sie das updateStatusReason Feld und finden Sie regionalEndpoints weitere Informationen. Für MultiRegion und PerRegion Endpunkte verwenden einige Regionen möglicherweise die vorherige Konfiguration, während andere Regionen die angeforderte Konfiguration verwenden. Korrigieren Sie die gemeldete Ursache und rufen Sie dann UpdateWebFunctionEndpoint erneut mit der vorgesehenen Konfiguration an, um den Endpunkt abzustimmen.

Der Status der Webfunktion, der Revisionsstatus und der Endpunktstatus sind unabhängig. Eine Webfunktion kann sich im Status Aktiv befinden, während einer ihrer Endpunkte noch ausstehend oder ausgefallen ist. In ähnlicher Weise kann eine Revision auch dann aktiv sein, wenn derzeit kein Endpunkt Datenverkehr an sie weiterleitet.

Eine aktive Revision, ein aktiver Endpunkt oder ein erfolgreiches Endpunkt-Update bestätigt nicht, dass Ihr Server gestartet wird. Lambda überprüft nicht, ob Ihr Server zuhört, wenn er einen Endpunkt erstellt oder aktualisiert, um eine Revision zu verwenden. Senden Sie nach jeder Bereitstellung eine Testanfrage und überprüfen Sie Ihre Anwendungsprotokolle.

Ausführungsumgebungen

Eine Ausführungsumgebung ist eine isolierte Recheninstanz, in der Ihr Webserver und Ihre Anwendung ausgeführt werden. Wenn der Datenverkehr an Ihrem Endpunkt ankommt, leitet Lambda Anfragen an Ausführungsumgebungen weiter, in denen der Code der aktiven Revision ausgeführt wird.

Lambda verwaltet Ausführungsumgebungen automatisch:

  1. Skalieren — Wenn der Traffic zunimmt, erstellt Lambda zusätzliche Ausführungsumgebungen und startet Ihren HTTP-Server in jeder Umgebung. Lambda skaliert neue Umgebungen vor dem Bedarf, um genügend Spielraum zu haben, sodass Anfragen selten auf den Start einer neuen Umgebung warten (Kaltstart). Wenn eine Webfunktion von Null aus skaliert (die erste Anforderung nach einer Zeit ohne Datenverkehr), kommt es zu einer kurzen Kaltstartverzögerung, während Lambda eine Ausführungsumgebung erstellt. Die Anforderung wartet, bis die Ausführungsumgebung initialisiert wird. Die Anforderung schlägt möglicherweise trotzdem fehl, wenn Ihre Anwendung nicht gestartet wird oder wenn eine Anforderungsrate, eine Ausführungsumgebung oder ein Kontolimit gilt. Details hierzu finden Sie unter Skalierungsverhalten für Lambda Web Functions.

  2. Herunterskalieren — Wenn der Traffic abnimmt, entfernt Lambda Ausführungsumgebungen, die es nicht mehr benötigt, nachdem die laufenden Anfragen nach bestem Wissen abgeschlossen wurden. Lambda skaliert auf Null-Umgebungen, wenn kein Verkehr vorhanden ist.

Die Anzahl der Ausführungsumgebungen und ihre Parallelität werden durch zwei Einstellungen gesteuert:

  • maxEnvironments(Endpunkteinstellung) — Die maximale Anzahl von Ausführungsumgebungen, die Lambda für den Endpunkt in jeder Region erstellen kann. Diese Einstellung ist optional. Wenn es nicht festgelegt ist, skaliert Lambda die Ausführungsumgebungen nach Bedarf, abhängig von Ihren Kontokontingenten.

  • maxConcurrencyPerEnvironment(Revisionseinstellung) — Die maximale Anzahl von HTTP-Anfragen, die eine einzelne Ausführungsumgebung gleichzeitig verarbeitet. Gültige Werte sind 1—128. Der Standardwert ist 64.

Lambda legt für jede Ausführungsumgebung ein dynamisches Parallelitätslimit fest. Dieses Limit wird niemals überschritten. maxConcurrencyPerEnvironment Eine Obergrenze für die Parallelität von Endpunkten wird maxEnvironments mit diesem dynamischen Limit multipliziert. Die tatsächliche Kapazität ist möglicherweise niedriger, da Lambda die Parallelität pro Umgebung auf der Grundlage der Ressourcenauslastung anpasst und Endpunkt- und Kontolimits anwendet. Nehmen wir zum Beispiel an, Sie setzen maxEnvironments auf 20 und auf 64. maxConcurrencyPerEnvironment Der Endpunkt verarbeitet dann bis zu 1.280 gleichzeitige Anfragen in einer Region. Es verarbeitet weniger, wenn Lambda das dynamische Limit unter 64 setzt. Hinweise zu diesen Einstellungen finden Sie unter Skalierungsverhalten für Lambda Web Functions.

Bearbeitung von Anfragen

Ihr Web-Funktionscode wird als Standard-HTTP-Server ausgeführt, der auf einem Port lauscht. Lambda sendet eingehende HTTP-Anfragen an Ihren Server und gibt die Antworten an die Clients zurück. Sie können jedes Node.js Web-Framework, jede Middleware oder jeden Router verwenden.

Der Anforderungslebenszyklus funktioniert wie folgt:

  1. Ein Client sendet eine HTTP-Anfrage an den Domainnamen des Endpunkts.

  2. Lambda authentifiziert die Anfrage (für IamAuthEndpunkte) oder leitet sie weiter (für ApplicationManagedEndpunkte).

  3. Lambda leitet die Anfrage auf der Grundlage der Revisionsgewichte des Endpunkts an eine Ausführungsumgebung weiter.

  4. Der HTTP-Server der Ausführungsumgebung verarbeitet die Anfrage und gibt eine Antwort zurück.

  5. Lambda gibt die Antwort an den Client zurück.

Jede Anfrage kann bis zu 900 Sekunden (15 Minuten) lang ausgeführt werden. Sie können das Timeout mit den timeoutSeconds Einstellungen der Revision zwischen 3 und 900 Sekunden konfigurieren. Das Standard-Timeout beträgt 30 Sekunden.

Jede Ausführungsumgebung für Webfunktionen verarbeitet mehrere gleichzeitige Anfragen, sodass Ihr Anwendungscode für die gleichzeitige Verwendung sicher sein muss. Einzelheiten zum Parallelitätsmodell finden Sie unter. Node.js Ausführungsmodell