Skalierung einer Lambda-Funktion

Nebenläufigkeit ist die Anzahl der laufenden Anfragen, die Ihre AWS Lambda-Funktion gleichzeitig bearbeitet. Für jede gleichzeitige Anfrage stellt Lambda eine separate Instance Ihrer Ausführungsumgebung bereit. Wenn Ihre Funktionen mehr Anfragen erhalten, sorgt Lambda automatisch für die Skalierung der Anzahl der Ausführungsumgebungen, bis Sie das Gleichzeitigkeitslimit für Ihr Konto erreichen. Standardmäßig stellt Lambda Ihrem Konto eine Gesamtnebenläufigkeitsgrenze von 1 000 gleichzeitigen Ausführungen für alle Funktionen in einer AWS-Region bereit. Um Ihre speziellen Kontoanforderungen zu unterstützen, können Sie eine Kontingenterhöhung anfordern und Gleichzeitigkeitskontrollen auf Funktionsebene konfigurieren, damit Ihre kritischen Funktionen nicht gedrosselt werden.

In diesem Thema wird die Gleichzeitigkeit und Funktionsskalierung in Lambda erläutert. Am Ende dieses Themas werden Sie in der Lage sein, die Gleichzeitigkeit zu berechnen, die beiden Hauptoptionen für die Gleichzeitigkeitskontrolle (reserviert und bereitgestellt) zu visualisieren, geeignete Einstellungen für die Gleichzeitigkeitskontrolle zu schätzen und Metriken zur weiteren Optimierung anzuzeigen.

Sections

• Verstehen und Visualisieren der Gleichzeitigkeit
• So berechnen Sie die Gleichzeitigkeit
• Gleichzeitigkeit im Vergleich zu Anforderungen pro Sekunde
• Reservierte Gleichzeitigkeit und bereitgestellte Gleichzeitigkeit
• Gleichzeitigkeitskontingente
• Konfigurieren reservierter Gleichzeitigkeit
• Konfigurieren von Provisioned Concurrency
• Lambda-Skalierungsverhalten
• Überwachen der Gleichzeitigkeit

Verstehen und Visualisieren der Gleichzeitigkeit

Lambda ruft Ihre Funktion in einer sicheren und isolierten Ausführungsumgebung auf. Um eine Anfrage zu bearbeiten, muss Lambda zuerst eine Ausführungsumgebung initialisieren (die Initialisierungsphase), bevor es zum Aufrufen Ihrer Funktion verwendet wird (die Aufrufphase):

Anmerkung

Die tatsächliche Initialisierungs- und Aufrufdauer kann von vielen Faktoren abhängen, z. B. von der von Ihnen ausgewählten Laufzeit und dem Lambda-Funktionscode. Das vorherige Diagramm soll nicht die genauen Proportionen der Initiierungs- und Aufrufphasendauer darstellen.

Im vorherigen Diagramm wird ein Rechteck verwendet, um eine einzelne Ausführungsumgebung darzustellen. Wenn Ihre Funktion ihre allererste Anfrage erhält (dargestellt durch den gelben Kreis mit der Bezeichnung 1), erstellt Lambda eine neue Ausführungsumgebung und führt den Code während der Initialisierungsphase außerhalb Ihres Haupthandlers aus. Anschließend führt Lambda den Haupthandlercode Ihrer Funktion während der Aufrufphase aus. Während des gesamten Prozesses ist diese Ausführungsumgebung ausgelastet und kann keine anderen Anfragen verarbeiten.

Wenn Lambda die Verarbeitung der ersten Anfrage abgeschlossen hat, kann diese Ausführungsumgebung weitere Anfragen für dieselbe Funktion verarbeiten. Für nachfolgende Anfragen muss Lambda die Umgebung nicht neu initialisieren.

Im vorherigen Diagramm verwendet Lambda die Ausführungsumgebung erneut, um die zweite Anfrage zu verarbeiten (dargestellt durch den gelben Kreis mit der Bezeichnung 2).

Bisher haben wir uns nur auf eine einzige Instance Ihrer Ausführungsumgebung konzentriert (d. h. eine Gleichzeitigkeit von 1). In der Praxis muss Lambda möglicherweise mehrere Instances der Ausführungsumgebung parallel bereitstellen, um alle eingehenden Anfragen zu verarbeiten. Wenn Ihre Funktion eine neue Anfrage erhält, können zwei Dinge passieren:

• Wenn eine vorinitialisierte Instance der Ausführungsumgebung verfügbar ist, verwendet Lambda diese, um die Anfrage zu verarbeiten.

• Andernfalls erstellt Lambda eine neue Instance der Ausführungsumgebung, um die Anfrage zu verarbeiten.

Lassen Sie uns beispielsweise untersuchen, was passiert, wenn Ihre Funktion 10 Anfragen erhält:

Im vorherigen Diagramm stellt jede horizontale Ebene eine einzelne Instance der Ausführungsumgebung dar (von A bis F). So behandelt Lambda jede Anfrage:

Lambda-Verhalten für Anfragen 1 bis 10
Anforderung	Lambda-Verhalten	Reasoning
1	Stellt neue Umgebung A bereit	Dies ist die erste Anfrage. Es sind keine Instances der Ausführungsumgebung verfügbar
2	Stellt neue Umgebung B bereit	Die vorhandene Instance der Ausführungsumgebung A ist ausgelastet
3	Stellt neue Umgebung C bereit	Die vorhandenen Instances der Ausführungsumgebung A und B sind beide ausgelastet
4	Stellt neue Umgebung D bereit	Die vorhandenen Instances der Ausführungsumgebung A, B und C sind alle ausgelastet
5	Stellt neue Umgebung E bereit	Die vorhandenen Instances der Ausführungsumgebung A, B, C und D sind alle ausgelastet
6	Wiederverwendung von Umgebung A	Die Instance der Ausführungsumgebung A hat die Verarbeitung von Anfrage 1 abgeschlossen und ist jetzt verfügbar
7	Wiederverwendung von Umgebung B	Die Instance der Ausführungsumgebung B hat die Verarbeitung von Anfrage 2 abgeschlossen und ist jetzt verfügbar
8	Wiederverwendung von Umgebung C	Die Instance der AusführungsumgebungB hat die Verarbeitung von Anfrage 3 abgeschlossen und ist jetzt verfügbar
9	Stellt neue Umgebung F bereit	Die vorhandenen Instances der Ausführungsumgebung A, B, C, D und E sind alle ausgelastet
10	Wiederverwendung von Umgebung D	Die Instance der Ausführungsumgebung D hat die Verarbeitung von Anfrage 4 abgeschlossen und ist jetzt verfügbar

Wenn Ihre Funktion mehr gleichzeitige Anfragen erhält, erhöht Lambda als Reaktion darauf die Anzahl der Instances der Ausführungsumgebung. Die folgende Animation verfolgt die Anzahl der gleichzeitigen Anfragen im Laufe der Zeit:

Durch das Einfrieren der vorherigen Animation an sechs verschiedenen Zeitpunkten erhalten wir das folgende Diagramm:

Im vorherigen Diagramm können wir zu jedem Zeitpunkt eine vertikale Linie zeichnen und die Anzahl der Umgebungen zählen, die diese Linie schneiden. Dadurch erhalten wir die Anzahl der gleichzeitigen Anfragen zu diesem Zeitpunkt. Beispielsweise gibt es zum Zeitpunkt t1 drei aktive Umgebungen, die drei gleichzeitige Anfragen bearbeiten. Die maximale Anzahl gleichzeitiger Anfragen in dieser Simulation wird zum Zeitpunkt t4 erreicht, an dem sechs aktive Umgebungen sechs gleichzeitige Anfragen bearbeiten.

Zusammengefasst beschreibt die Gleichzeitigkeit Ihrer Funktion die Anzahl der Anfragen, die diese gleichzeitig verarbeitet. Als Reaktion auf eine Zunahme der Gleichzeitigkeit Ihrer Funktion stellt Lambda mehr Instances der Ausführungsumgebung bereit, um die Anfragenachfrage zu erfüllen.

So berechnen Sie die Gleichzeitigkeit

Im Allgemeinen ist die Gleichzeitigkeit eines Systems die Fähigkeit, mehr als eine Aufgabe gleichzeitig zu bearbeiten. In Lambda beschreibt die Gleichzeitigkeit die Anzahl der Anfragen, die Ihre Funktion gleichzeitig bearbeitet. Eine schnelle und praktische Methode zur Messung der Gleichzeitigkeit einer Lambda-Funktion ist die Verwendung der folgenden Formel:

Concurrency = (average requests per second) * (average request duration in seconds)

Gleichzeitigkeit unterscheidet sich von Anfragen pro Sekunde. Nehmen wir beispielsweise an, Ihre Funktion erhält durchschnittlich 100 Anfragen pro Sekunde. Wenn die durchschnittliche Dauer einer Anfrage 1 Sekunde beträgt, beträgt die Nebenläufigkeit ebenfalls 100:

Concurrency = (100 requests/second) * (1 second/request) = 100

Wenn die durchschnittliche Anfragedauer jedoch 500 ms beträgt, liegt die Nebenläufigkeit bei 50:

Concurrency = (100 requests/second) * (0.5 second/request) = 50

Was bedeutet eine Gleichzeitigkeit von 50 in der Praxis? Wenn die durchschnittliche Anfragedauer 500 ms beträgt, können Sie davon ausgehen, dass eine Instance Ihrer Funktion zwei Anfragen pro Sekunde verarbeiten kann. Dementsprechend sind 50 Instances Ihrer Funktion erforderlich, um eine Last von 100 Anfragen pro Sekunde zu verarbeiten. Eine Gleichzeitigkeit von 50 bedeutet, dass Lambda 50 Instances der Ausführungsumgebung bereitstellen muss, um diesen Workload ohne Drosselung effizient zu bewältigen. So drückt man dies in Gleichungsform aus:

Concurrency = (100 requests/second) / (2 requests/second) = 50

Wenn Ihre Funktion die doppelte Anzahl von Anfragen empfängt (200 Anfragen pro Sekunde), aber nur die Hälfte der Zeit benötigt, um jede Anfrage zu verarbeiten (250 ms), beträgt die Nebenläufigkeit immer noch 50:

Concurrency = (200 requests/second) * (0.25 second/request) = 50

Testen Sie Ihr Verständnis von Gleichzeitigkeit

Angenommen, Sie haben eine Funktion, deren Ausführung im Durchschnitt 200 ms benötigt. Während der Spitzenlast beobachten Sie 5 000 Anfragen pro Sekunde. Wie hoch ist die Gleichzeitigkeit Ihrer Funktion während der Spitzenlast?

Antwort

Die durchschnittliche Funktionsdauer beträgt 200 ms oder 0,2 Sekunden. Mithilfe der Nebenläufigkeitsformel können Sie die Zahlen einfügen, um eine Nebenläufigkeit von 1 000 zu erhalten:

Concurrency = (5,000 requests/second) * (0.2 seconds/request) = 1,000

Alternativ bedeutet eine durchschnittliche Funktionsdauer von 200 ms, dass Ihre Funktion 5 Anfragen pro Sekunde verarbeiten kann. Um den Workload von 5 000 Anfragen pro Sekunde zu bewältigen, benötigen Sie 1 000 Instances der Ausführungsumgebung. Die Gleichzeitigkeit beträgt also 1 000:

Concurrency = (5,000 requests/second) / (5 requests/second) = 1,000

Gleichzeitigkeit im Vergleich zu Anforderungen pro Sekunde

Wie im vorherigen Abschnitt erwähnt, unterscheidet sich die Gleichzeitigkeit von den Anforderungen pro Sekunde. Diese Unterscheidung ist besonders wichtig, wenn Sie mit Funktionen arbeiten, die eine durchschnittliche Anforderungsdauer von weniger als 100 ms haben.

In der Regel kann jede Instance Ihrer Ausführungsumgebung maximal 10 Anforderungen pro Sekunde bearbeiten. Dieser Grenzwert gilt für synchrone On-Demand-Funktionen sowie für Funktionen, die bereitgestellte Nebenläufigkeit verwenden. Wenn Sie mit diesem Grenzwert nicht vertraut sind, wissen Sie vielleicht nicht, warum es bei solchen Funktionen in bestimmten Szenarien zu einer Drosselung kommen kann.

Stellen Sie sich etwa eine Funktion mit einer durchschnittlichen Anforderungsdauer von 50 ms vor. Bei 200 Anforderungen pro Sekunde lautet die Gleichzeitigkeit dieser Funktion wie folgt:

Concurrency = (200 requests/second) * (0.05 second/request) = 10

Aufgrund dieses Ergebnisses ließe sich davon ausgehen, dass Sie nur 10 Instances der Ausführungsumgebung benötigen, um diese Last zu bewältigen. Die jeweilige Ausführungsumgebung kann jedoch nur 10 Ausführungen pro Sekunde verarbeiten. Das bedeutet, dass Ihre Funktion bei 10 Ausführungsumgebungen von insgesamt 200 Anforderungen nur 100 Anforderungen pro Sekunde verarbeiten kann. Bei dieser Funktion kommt es zu einer Drosselung.

Fazit: Sie müssen bei der Konfiguration der Nebenläufigkeitseinstellungen für Ihre Funktionen sowohl Nebenläufigkeit als auch Anforderungen pro Sekunde berücksichtigen. In diesem Fall benötigen Sie 20 Ausführungsumgebungen für Ihre Funktion, obwohl sie nur eine Nebenläufigkeit von 10 hat.

Testen Sie Ihr Verständnis von Gleichzeitigkeit (Funktionen unter 100 ms)

Angenommen, Sie haben eine Funktion, deren Ausführung im Durchschnitt 20 ms benötigt. Während der Spitzenlast beobachten Sie 3 000 Anfragen pro Sekunde. Wie hoch ist die Gleichzeitigkeit Ihrer Funktion während der Spitzenlast?

Antwort

Die durchschnittliche Funktionsdauer beträgt 20 ms oder 0,02 Sekunden. Mit der Gleichzeitigkeitsformel können Sie die Zahlen einfügen, um eine Gleichzeitigkeit von 60 zu erhalten:

Concurrency = (3,000 requests/second) * (0.02 seconds/request) = 60

Die jeweilige Ausführungsumgebung kann jedoch nur 10 Anforderungen pro Sekunde verarbeiten. Bei 60 Ausführungsumgebungen kann Ihre Funktion maximal 600 Anforderungen pro Sekunde verarbeiten. Um die 3 000 Anforderungen vollständig bearbeiten zu können, benötigt Ihre Funktion mindestens 300 Instances der Ausführungsumgebung.

Reservierte Gleichzeitigkeit und bereitgestellte Gleichzeitigkeit

Standardmäßig verfügt Ihr Konto über eine Nebenläufigkeitsgrenze von 1 000 gleichzeitigen Ausführungen für alle Funktionen in einer Region. Ihre Funktionen teilen sich diesen Pool von 1 000 gleichzeitigen Anwendungen auf Bedarfsbasis. Ihre Funktionen werden gedrosselt (d. h. sie beginnen, Anfragen zu verwerfen), wenn Ihnen die verfügbare Nebenläufigkeit ausgeht.

Einige Ihrer Funktionen sind möglicherweise kritischer als andere. Daher sollten Sie die Nebenläufigkeitseinstellungen konfigurieren, um sicherzustellen, dass kritische Funktionen die benötigte Gleichzeitigkeit erhalten. Es gibt zwei Arten von Gleichzeitigkeitskontrollen: reservierte Gleichzeitigkeit und bereitgestellte Gleichzeitigkeit.

• Verwenden Sie die reservierte Gleichzeitigkeit, um einen Teil der Gleichzeitigkeit Ihres Kontos für eine Funktion zu reservieren. Dies ist nützlich, wenn Sie nicht möchten, dass andere Funktionen die gesamte verfügbare nicht reservierte Gleichzeitigkeit in Anspruch nehmen.

• Verwenden Sie die bereitgestellte Gleichzeitigkeit, um eine Reihe von Umgebungs-Instances für eine Funktion vorab zu initialisieren. Dies ist nützlich, um Kaltstartlatenzen zu reduzieren.

Reservierte Gleichzeitigkeit

Wenn Sie sicherstellen möchten, dass für Ihre Funktion jederzeit ein gewisses Maß an Gleichzeitigkeit verfügbar ist, verwenden Sie reservierte Gleichzeitigkeit.

Reservierte Nebenläufigkeit ist die maximale Anzahl der gleichzeitigen Instances, die Sie Ihrer Funktion zuweisen möchten. Wenn Sie einer Funktion reservierte Gleichzeitigkeit zuweisen, kann keine andere Funktion diese Gleichzeitigkeit nutzen. Mit anderen Worten, das Festlegen von reservierter Gleichzeitigkeit kann sich auf den Gleichzeitigkeits-Pool auswirken, der anderen Funktionen zur Verfügung steht. Funktionen, die nicht über reservierte Gleichzeitigkeit verfügen, teilen sich den verbleibenden Pool an nicht reservierter Gleichzeitigkeit.

Das Konfigurieren der reservierten Gleichzeitigkeit wird auf das gesamte Gleichzeitigkeitslimit Ihres Kontos angerechnet. Für die Konfiguration reservierter Gleichzeitigkeit für eine Funktion wird keine Gebühr erhoben.

Betrachten Sie das folgende Diagramm, um die reservierte Gleichzeitigkeit besser zu verstehen:

In diesem Diagramm ist das Gleichzeitigkeitslimit Ihres Kontos für alle Funktionen in diesem Bereich auf das Standardlimit von 1 000 festgelegt. Angenommen, Sie haben zwei kritische Funktionen, function-blue und function-orange, die routinemäßig hohe Aufrufvolumina erwarten. Sie entscheiden sich, 400 Einheiten reservierter Gleichzeitigkeit für function-blue und 400 Einheiten reservierter Gleichzeitigkeit für function-orange einzusetzen. In diesem Beispiel müssen sich alle anderen Funktionen in Ihrem Konto die verbleibenden 200 Einheiten an nicht reservierter Gleichzeitigkeit teilen.

Das Diagramm enthält fünf wichtige Punkte:

• Bei t1 beginnen sowohl function-orange als auch function-blue mit dem Empfang von Anfragen. Jede Funktion beginnt, ihren zugewiesenen Teil der reservierten Gleichzeitigkeitseinheiten zu verbrauchen.

• Bei t2 erhalten function-orange und function-blue stetig mehr Anfragen. Gleichzeitig stellen Sie einige andere Lambda-Funktionen bereit, die mit dem Empfang von Anfragen beginnen. Sie weisen diesen anderen Funktionen keine reservierte Nebenläufigkeit zu. Diese beginnen mit der Verwendung der verbleibenden 200 Einheiten der nicht reservierten Gleichzeitigkeit.

• Bei t3 erreicht function-orange die maximale Gleichzeitigkeit von 400. Obwohl es an anderer Stelle in Ihrem Konto ungenutzte Gleichzeitigkeit gibt, kann function-orange nicht darauf zugreifen. Die rote Linie zeigt an, dass function-orange gedrosselt wird und Lambda-Anfragen möglicherweise verwirft.

• Bei t4 beginnt function-orange weniger Anfragen zu erhalten und wird nicht mehr gedrosselt. Ihre anderen Funktionen erfahren jedoch einen Anstieg des Datenverkehrs und werden gedrosselt. Obwohl es an anderer Stelle in Ihrem Konto ungenutzte Gleichzeitigkeit gibt, können diese anderen Funktionen nicht darauf zugreifen. Die rote Linie zeigt an, dass Ihre anderen Funktionen gedrosselt werden.

• Bei t5 beginnen andere Funktionen weniger Anfragen zu erhalten und werden nicht mehr gedrosselt.

Anhand dieses Beispiels können Sie sehen, dass die Reservierung von Gleichzeitigkeit folgende Auswirkungen hat:

• Ihre Funktion kann unabhängig von anderen Funktionen in Ihrem Konto skaliert werden. Alle Funktionen Ihres Kontos in derselben Region, die über keine reservierte Gleichzeitigkeit verfügen, teilen sich den Pool an nicht reservierter Gleichzeitigkeit. Ohne reservierte Gleichzeitigkeit können andere Funktionen möglicherweise Ihre gesamte verfügbare Gleichzeitigkeit verbrauchen. Dadurch wird verhindert, dass kritische Funktion bei Bedarf hochskalieren.

• Ihre Funktion kann nicht unkontrolliert aufskaliert werden. Die reservierte Nebenläufigkeit legt eine Obergrenze für die maximale Gleichzeitigkeit Ihrer Funktion fest. Dies bedeutet, dass Ihre Funktion keine für andere Funktionen reservierte Gleichzeitigkeit oder Gleichzeitigkeit aus dem nicht reservierten Pool verwenden kann. Sie können Gleichzeitigkeit reservieren, um zu verhindern, dass Ihre Funktion die gesamte verfügbare Gleichzeitigkeit in Ihrem Konto verwendet oder nachgelagerte Ressourcen überlastet.

• Möglicherweise können Sie nicht die gesamte verfügbare Gleichzeitigkeit Ihres Kontos nutzen. Das Reservieren von Gleichzeitigkeit wird auf Ihr Kontolimit für Gleichzeitigkeit angerechnet, aber das bedeutet auch, dass andere Funktionen diesen Teil der reservierten Gleichzeitigkeit nicht verwenden können. Wenn Ihre Funktion nicht die gesamte Gleichzeitigkeit verbraucht, die Sie dafür reservieren, verschwenden Sie diese Gleichzeitigkeit effektiv. Das ist kein Problem, es sei denn, andere Funktionen in Ihrem Konto könnten von der ungenutzten Gleichzeitigkeit profitieren.

Informationen zur Verwaltung der reservierten Nebenläufigkeitseinstellungen für Ihre Funktionen finden Sie unter Konfigurieren reservierter Gleichzeitigkeit.

Bereitgestellte Gleichzeitigkeit

Sie verwenden die reservierte Gleichzeitigkeit, um die maximale Anzahl der für eine Lambda-Funktion reservierten Ausführungsumgebungen festzulegen. Keine dieser Umgebungen ist jedoch vorinitialisiert. Infolgedessen können Ihre Funktionsaufrufe länger dauern, da Lambda zuerst die neue Umgebung initialisieren muss, bevor diese zum Aufrufen Ihrer Funktion verwendet werden kann. Wenn Lambda eine neue Umgebung initialisieren muss, um einen Aufruf auszuführen, wird dies als Kaltstart bezeichnet. Um Kaltstarts zu vermeiden, können Sie die bereitgestellte Gleichzeitigkeit verwenden.

Die bereitgestellte Nebenläufigkeit beschreibt die Anzahl der vorinitialisierten Ausführungsumgebungen, die Sie Ihrer Funktion zuweisen möchten. Wenn Sie bereitgestellte Gleichzeitigkeit für eine Funktion festlegen, initialisiert Lambda diese Anzahl von Ausführungsumgebungen, damit sie bereit sind, sofort auf Funktionsanfragen zu reagieren.

Anmerkung

Die Verwendung von bereitgestellter Gleichzeitigkeit verursacht zusätzliche Gebühren für Ihr Konto. Wenn Sie mit den Laufzeiten Java 11 oder Java 17 arbeiten, können Sie Lambda auch verwenden, SnapStart um Kaltstartprobleme ohne zusätzliche Kosten zu beheben. SnapStart verwendet zwischengespeicherte Snapshots Ihrer Ausführungsumgebung, um die Startleistung erheblich zu verbessern. Sie können nicht sowohl SnapStart als auch bereitgestellte Gleichzeitigkeit für dieselbe Funktionsversion verwenden. Weitere Informationen zu SnapStart Funktionen, Einschränkungen und unterstützten Regionen finden Sie unter Verbesserung der Startleistung mit Lambda SnapStart.

Bei der Verwendung von bereitgestellter Gleichzeitigkeit erneuert Lambda weiterhin die Ausführungsumgebung im Hintergrund. Lambda stellt jedoch zu jedem Zeitpunkt sicher, dass die Anzahl der vorinitialisierten Umgebungen dem Wert der von Ihrer Funktion bereitgestellten Gleichzeitigkeitseinstellung entspricht. Dieses Verhalten unterscheidet sich von reservierter Gleichzeitigkeit, bei der Lambda eine Umgebung nach einem Zeitraum der Inaktivität vollständig beenden kann. Das folgende Diagramm veranschaulicht dies, indem der Lebenszyklus einer einzelnen Ausführungsumgebung beim Konfigurieren Ihrer Funktion mit reservierter Gleichzeitigkeit mit bereitgestellter Gleichzeitigkeit verglichen wird.

Das Diagramm enthält vier wichtige Punkte:

Zeit	Reservierte Gleichzeitigkeit	Bereitgestellte Gleichzeitigkeit
t1	Es passiert nichts.	Lambda initialisiert eine Instance der Ausführungsumgebung vorab.
t2	Anfrage 1 wird empfangen. Lambda muss eine neue Instance der Ausführungsumgebung initialisieren.	Anfrage 1 wird empfangen. Lambda verwendet die vorinitialisierte Umgebungs-Instance.
t3	Nach einer gewissen Inaktivität beendet Lambda die aktive Umgebungs-Instance.	Es passiert nichts.
t4	Anfrage 2 wird empfangen. Lambda muss eine neue Instance der Ausführungsumgebung initialisieren.	Anfrage 2 wird empfangen. Lambda verwendet die vorinitialisierte Umgebungs-Instance.

Betrachten Sie das folgende Diagramm, um die bereitgestellte Gleichzeitigkeit besser zu verstehen:

In diesem Diagramm haben Sie eine Kontogleichzeitigkeitslimit von 1 000. Sie entscheiden sich, 400 Einheiten der bereitgestellten Gleichzeitigkeit an function-orange zu vergeben. Alle Funktionen in Ihrem Konto, einschließlich function-orange, können die verbleibenden 600 Einheiten der nicht reservierten Gleichzeitigkeit nutzen.

Das Diagramm enthält fünf wichtige Punkte:

• Bei t1 beginnt function-orange mit dem Empfang von Anfragen. Da Lambda 400 Instances der Ausführungsumgebung vorinitialisiert hat, ist function-orange für den sofortigen Aufruf bereit.

• Bei t2 erreicht function-orange 400 gleichzeitige Anfragen. Infolgedessen geht function-orange die bereitgestellte Gleichzeitigkeit aus. Da jedoch immer noch keine nicht reservierte Gleichzeitigkeit verfügbar ist, kann Lambda dies verwenden, um zusätzliche Anfragen an function-orange zu verarbeiten (es gibt keine Drosselung). Lambda muss neue Instances erstellen, um diese Anfragen zu bearbeiten und bei Ihrer Funktion kann es zu Kaltstartlatenzen kommen.

• Bei t3 kehrt function-orange nach einem kurzen Anstieg des Datenverkehrs zu 400 gleichzeitigen Anfragen zurück. Lambda ist wieder in der Lage, alle Anfragen ohne Kaltstartlatenzen zu bearbeiten.

• Bei t4 kommt es bei Funktionen in Ihrem Konto zu einem starken Anstieg des Datenverkehrs. Dieser Anstieg kann von function-orange oder einer anderen Funktion in Ihrem Konto stammen. Lambda verwendet nicht reservierte Gleichzeitigkeit, um diese Anfragen zu bearbeiten.

• Bei t5 erreichen die Funktionen in Ihrem Konto das maximale Gleichzeitigkeitslimit von 1 000 und es kommt zu Drosselungen.

Im vorherigen Beispiel wurde nur die bereitgestellte Nebenläufigkeit berücksichtigt. In der Praxis können Sie für eine Funktion sowohl die bereitgestellte als auch die reservierte Gleichzeitigkeit festlegen. Sie können dies beispielsweise tun, wenn Sie eine Funktion haben, die wochentags eine konstante Anzahl von Aufrufen verarbeitet, aber an den Wochenenden regelmäßig Datenverkehrsspitzen aufweist. In diesem Fall könnten Sie die bereitgestellte Gleichzeitigkeit verwenden, um eine Basismenge an Umgebungen festzulegen, die Anfragen an Wochentagen verarbeiten, und die reservierte Gleichzeitigkeit verwenden, um die Spitzenlasten am Wochenende zu verarbeiten. Betrachten Sie das folgende Diagramm:

Nehmen wir in diesem Diagramm an, dass Sie 200 Einheiten bereitgestellter Gleichzeitigkeit und 400 Einheiten reservierter Gleichzeitigkeit für function-orange konfigurieren. Da Sie die reservierte Gleichzeitigkeit konfiguriert haben, kann function-orange keine der 600 Einheiten der nicht reservierten Gleichzeitigkeit verwenden.

Dieses Diagramm enthält fünf wichtige Punkte:

• Bei t1 beginnt function-orange mit dem Empfang von Anfragen. Da Lambda 200 Instances der Ausführungsumgebung vorinitialisiert hat, ist function-orange für den sofortigen Aufruf bereit.

• Bei t2 verbraucht function-orange die gesamte bereitgestellte Gleichzeitigkeit. function-orange kann weiterhin Anfragen über reservierte Gleichzeitigkeit bearbeiten, allerdings kann es bei diesen Anfragen zu Kaltstartlatenzen kommen.

• Bei t3 erreicht function-orange 400 gleichzeitige Anfragen. Dadurch verbraucht function-orange die gesamte reservierte Gleichzeitigkeit. Da function-orange keine nicht reservierte Gleichzeitigkeit nutzen kann, werden die Anfragen gedrosselt.

• Bei t4 beginnt function-orange weniger Anfragen zu erhalten und wird nicht mehr gedrosselt.

• Bei t5 sinkt function-orange auf 200 gleichzeitige Anfragen, sodass alle Anfragen wieder bereitgestellte Nebenläufigkeit verwenden können (d. h. keine Kaltstartlatenzen).

Sowohl die reservierte Gleichzeitigkeit als auch die bereitgestellte Gleichzeitigkeit werden auf das Gleichzeitigkeitslimit Ihres Kontos und die regionalen Kontingente angerechnet. Mit anderen Worten, die Zuweisung von reservierter und bereitgestellter Gleichzeitigkeit kann sich auf den Gleichzeitigkeit -Pool auswirken, der anderen Funktionen zur Verfügung steht. Die Konfiguration von bereitgestellter Gleichzeitigkeit verursacht Gebühren für Ihre AWS-Konto.

Anmerkung

Wenn die Menge der bereitgestellten Nebenläufigkeit für die Versionen und Aliase einer Funktion zur reservierten Nebenläufigkeit der Funktion hinzukommt, werden alle Aufrufe mit bereitgestellter Nebenläufigkeit ausgeführt. Diese Konfiguration hat auch zur Folge, dass die nicht veröffentlichte Version der Funktion ($LATEST) gedrosselt wird, was die Ausführung verhindert. Sie können nicht mehr bereitgestellte Gleichzeitigkeit als reservierte Gleichzeitigkeit für eine Funktion zuweisen.

Informationen zur Verwaltung der Einstellungen für reservierte Nebenläufigkeit für Ihre Funktionen finden Sie unter Konfigurieren von Provisioned Concurrency. Informationen zum Automatisieren der bereitgestellten Gleichzeitigkeitsskalierung basierend auf einem Zeitplan oder der Anwendungsnutzung finden Sie unter Verwalten der bereitgestellten Gleichzeitigkeit mit Application Auto Scaling.

So weist Lambda bereitgestellte Gleichzeitigkeit zu

Bereitgestellte Gleichzeitigkeit wird nicht sofort nach der Konfiguration online geschaltet. Lambda beginnt die Zuweisung bereitgestellter Gleichzeitigkeit nach ein oder zwei Minuten Vorbereitung. Insbesondere kann Lambda je nach Region zwischen 500 und 3 000 Ausführungsumgebungen gleichzeitig bereitstellen. Nach diesem ersten Burst weist Lambda unabhängig von der Region 500 zusätzliche Umgebungen pro Minute zu, bis die Anforderung erfüllt ist.

Angenommen, Ihr Konto hat ein Gleichzeitigkeitslimit von 10 000. Nehmen wir außerdem an, dass Sie um 10:00 Uhr in USA Ost (Nord-Virginia) 5 000 bereitgestellte Gleichzeitigkeitseinheiten für eine Funktion konfigurieren. So würde Lambda bereitgestellte Gleichzeitigkeitseinheiten zuweisen:

In folgendem Diagramm:

• Anfänglich kann Lambda maximal 3 000 Ausführungsumgebungen bereitstellen, da der anfängliche Grenzwert für die Burst-Gleichzeitigkeit in den USA Ost (Nord-Virginia) bei 3 000 liegt.

• Um 10:00 Uhr: Sie fordern 5 000 bereitgestellte Gleichzeitigkeitseinheiten für diese Funktion an. Lambda beginnt nicht sofort mit der Bereitstellung der Ausführungsumgebungen.

• Um 10:01 Uhr: Lambda beginnt mit der Bereitstellung von 3 000 Umgebungen.

• Von 10:02 bis 10:05 Uhr: Lambda stellt pro Minute 500 weitere Umgebungen bereit. Um 10:05 Uhr ist Lambda damit fertig, Ihrer Funktion 5 000 Umgebungen zuzuweisen.

Wenn Sie eine Anforderung zur Zuweisung bereitgestellter Gleichzeitigkeit einreichen, können Sie erst wieder auf diese Umgebungen zugreifen, wenn Lambda die Zuweisung vollständig abgeschlossen hat. Im vorherigen Szenario können Ihre Anforderungen beispielsweise bis 10:05 Uhr keine bereitgestellte Gleichzeitigkeit verwenden, da Lambda erst dann die Zuweisung Ihrer angeforderten 5 000 Ausführungsumgebungen vollständig abgeschlossen hat.

Vergleich zwischen reservierter und bereitgestellter Gleichzeitigkeit

Die folgende Tabelle fasst reservierte und bereitgestellte Nebenläufigkeit zusammen und vergleicht sie.

Thema	Reservierte Gleichzeitigkeit	Bereitgestellte Gleichzeitigkeit
Definition	Maximale Anzahl von Instances in der Ausführungsumgebung für Ihre Funktion.	Festgelegte Anzahl von vorbereiteten Instances in der Ausführungsumgebung für Ihre Funktion.
Bereitstellungsverhalten	Lambda stellt neue Instances auf On-Demand-Basis bereit.	Lambda stellt Instances vorab bereit (d. h. bevor Ihre Funktion mit dem Empfang von Anfragen beginnt).
Kaltstartverhalten	Kaltstartlatenz möglich, da Lambda bei Bedarf neue Instances erstellen muss.	Eine Kaltstartlatenz ist nicht möglich, da Lambda keine Instances On-Demand erstellen muss.
Drosselungsverhalten	Die Funktion wurde gedrosselt, als das reservierte Gleichzeitigkeitslimit erreicht wurde.	Wenn die reservierte Gleichzeitigkeit nicht festgelegt ist: Die Funktion verwendet die nicht reservierte Gleichzeitigkeit, wenn das bereitgestellte Gleichzeitigkeitslimit erreicht ist. Wenn reservierte Gleichzeitigkeit festgelegt ist: Funktion wird gedrosselt, wenn das Limit für reservierte Gleichzeitigkeit erreicht wird.
Standardverhalten, falls nicht festgelegt	Die Funktion verwendet nicht reservierte Gleichzeitigkeit, die in Ihrem Konto verfügbar ist.	Lambda stellt keine Instances vorab bereit. Wenn die reservierte Gleichzeitigkeit nicht festgelegt ist, verwendet die Funktion stattdessen die nicht reservierte Gleichzeitigkeit, die in Ihrem Konto verfügbar ist. Wenn reservierte Gleichzeitigkeit festgelegt ist: die Funktion verwendet reservierte Gleichzeitigkeit.
Preisgestaltung	Keine zusätzlichen Gebühren.	Verursacht zusätzliche Gebühren.

Gleichzeitigkeitskontingente

Lambda legt Kontingente für die Gesamtmenge der Nebenläufigkeit fest, die Sie für alle Funktionen in einer Region verwenden können. Diese Kontingente bestehen auf zwei Ebenen:

• Auf Kontoebene können Ihre Funktionen standardmäßig bis zu 1 000 Einheiten an Gleichzeitigkeit verwenden. Informationen zum Erhöhen dieses Limits finden Sie unter Anfordern einer Kontingenterhöhung im Benutzerhandbuch für Service Quotas.

• Auf Funktionsebene können Sie standardmäßig bis zu 900 Nebenläufigkeitseinheiten für alle Ihre Funktionen reservieren. Unabhängig von Ihrem Gesamtlimit für die Kontonebenläufigkeit reserviert Lambda immer 100 Nebenläufigkeitseinheiten für Ihre Funktionen, die Nebenläufigkeit nicht explizit reservieren. Wenn Sie beispielsweise Ihr Limit für die Nebenläufigkeit Ihres Kontos auf 2 000 erhöht haben, können Sie auf Funktionsebene bis zu 1 900 Einheiten an Nebenläufigkeit reservieren.

Um Ihr Kontingent für die Nebenläufigkeit auf Kontoebene zu überprüfen, verwenden Sie die AWS Command Line Interface (AWS CLI), um den folgenden Befehl auszuführen:

aws lambda get-account-settings

Die Ausgabe sollte ungefähr wie folgt aussehen:

{
    "AccountLimit": {
        "TotalCodeSize": 80530636800,
        "CodeSizeUnzipped": 262144000,
        "CodeSizeZipped": 52428800,
        "ConcurrentExecutions": 1000,
        "UnreservedConcurrentExecutions": 900
    },
    "AccountUsage": {
        "TotalCodeSize": 410759889,
        "FunctionCount": 8
    }
}

ConcurrentExecutions ist Ihr Gesamtkontingent für die Nebenläufigkeit auf Kontoebene. UnreservedConcurrentExecutions ist die Menge an verbleibender Nebenläufigkeit, die Sie Ihren Funktionen noch zuweisen können.

Erhält Ihre Funktion mehr Anfragen, sorgt Lambda automatisch für die Skalierung der Anzahl der Ausführungsumgebungen, bis Ihr Konto das Nebenläufigkeitskontingent erreicht. Zum Schutz vor einer Überskalierung als Reaktion auf plötzliche Datenverkehrsspitzen begrenzt Lambda jedoch, wie schnell Ihre Funktionen skaliert werden können. Diese Nebenläufigkeitsskalierungsrate ist die maximale Rate, mit der Funktionen in Ihrem Konto als Reaktion auf erhöhte Anfragen skalieren können. (Das heißt, sie gibt an, wie schnell Lambda neue Ausführungsumgebungen erstellen kann.) Die Nebenläufigkeitsskalierungsrate unterscheidet sich von der Gleichzeitigkeitsgrenze auf Kontoebene, bei der es sich um die Gesamtmenge der für Ihre Funktionen verfügbaren Gleichzeitigkeit handelt.

In jeder AWS-Region-Funktion beträgt Ihre Skalierungsrate für Nebenläufigkeit 1 000 Instances der Ausführungsumgebung alle 10 Sekunden. Mit anderen Worten, alle 10 Sekunden kann Lambda jeder Ihrer Funktionen maximal 1 000 zusätzliche Instances der Ausführungsumgebung zuweisen.

Normalerweise müssen Sie sich über diese Einschränkung keine Gedanken machen. Die Skalierungsrate von Lambda ist für die meisten Anwendungsfälle ausreichend.

Wichtig ist, dass die Nebenläufigkeitsskalierungsrate ein Limit auf Funktionsebene ist. Das bedeutet, dass jede Funktion in Ihrem Konto unabhängig von anderen Funktionen skaliert werden kann.

Weitere Informationen zum Skalierungsverhalten finden Sie unter Lambda-Skalierungsverhalten.