Die Skalierung von Lambda-Ereignisfunktionen verstehen

Parallelität ist die Anzahl der laufenden Anfragen, die Ihre AWS Lambda Event-Funktion gleichzeitig bearbeitet. Für jede gleichzeitige Anfrage stellt Lambda eine separate Instance Ihrer Ausführungsumgebung bereit. Wenn Ihre Event Functions mehr Anfragen erhalten, übernimmt Lambda automatisch die Skalierung der Anzahl der Ausführungsumgebungen, bis Sie das Parallelitätslimit Ihres Kontos erreicht haben. Standardmäßig bietet Lambda Ihrem Konto ein Gesamt-Parallelitätslimit von 1.000 gleichzeitigen Ausführungen für alle Event-Funktionen in einem. AWS-Region Um Ihren spezifischen Kontoanforderungen gerecht zu werden, können Sie eine Erhöhung des Kontingents beantragen und Parallelitätskontrollen auf Funktionsebene konfigurieren, sodass Ihre kritischen Event-Funktionen nicht gedrosselt werden.

In diesem Thema werden Parallelitätskonzepte und die Skalierung von Event Functions in Lambda erklärt. 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.

Verstehen und Visualisieren der Gleichzeitigkeit

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

Im vorherigen Diagramm wird ein Rechteck verwendet, um eine einzelne Ausführungsumgebung darzustellen. Wenn Ihre Event-Funktion ihre allererste Anfrage erhält (dargestellt durch den gelben Kreis mit Bezeichnung1), erstellt Lambda eine neue Ausführungsumgebung und führt den Code während der Init-Phase außerhalb Ihres Haupthandlers aus. Dann führt Lambda den Haupthandlercode Ihrer Event-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 Event-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 Instanzen der Ausführungsumgebung parallel bereitstellen, um alle eingehenden Anfragen zu verarbeiten. Wenn Ihre Event-Funktion eine neue Anfrage erhält, kann eines von zwei Dingen passieren:

Lassen Sie uns zum Beispiel untersuchen, was passiert, wenn Ihre Event-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:

Wenn Ihre Event-Funktion mehr gleichzeitige Anfragen empfängt, erhöht Lambda als Reaktion darauf die Anzahl der Instanzen 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.

Zusammenfassend lässt sich sagen, dass die Parallelität Ihrer Event-Funktion die Anzahl der gleichzeitigen Anfragen ist, die sie gleichzeitig bearbeitet. Als Reaktion auf eine Zunahme der Parallelität Ihrer Event-Funktion stellt Lambda mehr Instanzen der Ausführungsumgebung bereit, um den Anforderungsbedarf zu decken.

Berechnung der Parallelität für eine Event-Funktion

Im Allgemeinen ist die Gleichzeitigkeit eines Systems die Fähigkeit, mehr als eine Aufgabe gleichzeitig zu bearbeiten. In Lambda ist Parallelität die Anzahl der laufenden Anfragen, die Ihre Event-Funktion gleichzeitig bearbeitet. Eine schnelle und praktische Methode zur Messung der Parallelität einer Lambda-Ereignisfunktion 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 zum Beispiel an, Ihre Event-Funktion empfängt im Durchschnitt 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 Ereignisfunktion 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), dann ist die Parallelität immer noch 50:

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

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

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

Verständnis der reservierten Gleichzeitigkeit und der bereitgestellten Gleichzeitigkeit

Standardmäßig gilt für Ihr Konto ein Parallelitätslimit von 1.000 gleichzeitigen Ausführungen für alle Event-Funktionen in einer Region. Ihre Event Functions teilen sich diesen Pool von 1.000 gleichzeitigen Vorgängen auf On-Demand-Basis. Bei Ihren Event-Funktionen kommt es zu einer Drosselung (d. h. sie fangen an, Anfragen zu verwerfen), wenn Ihnen die verfügbare Parallelität ausgeht.

Einige Ihrer Event-Funktionen sind möglicherweise wichtiger als andere. Aus diesem Grund möchten Sie möglicherweise Parallelitätseinstellungen konfigurieren, um sicherzustellen, dass wichtige Ereignisfunktionen die Parallelität erhalten, die sie benötigen. Es gibt zwei Arten von Gleichzeitigkeitskontrollen: reservierte Gleichzeitigkeit und bereitgestellte Gleichzeitigkeit.

Reservierte Gleichzeitigkeit

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

Reservierte Parallelität legt die maximale und minimale Anzahl gleichzeitiger Instances fest, die Sie Ihrer Event-Funktion zuordnen möchten. Wenn Sie einer Event-Funktion reservierte Parallelität zuweisen, kann keine andere Event-Funktion diese Parallelität verwenden. Mit anderen Worten, die Einstellung einer reservierten Parallelität kann sich auf den Parallelitätspool auswirken, der anderen Ereignisfunktionen zur Verfügung steht. Eventfunktionen, die nicht über reservierte Parallelität verfügen, teilen sich den verbleibenden Pool an nicht reservierter Parallelität.

Das Konfigurieren der reservierten Gleichzeitigkeit wird auf das gesamte Gleichzeitigkeitslimit Ihres Kontos angerechnet. Für die Konfiguration der reservierten Parallelität für eine Event-Funktion fallen keine Gebühren an.

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

In diesem Diagramm liegt das Limit für die Parallelität Ihres Kontos für alle Event-Funktionen in dieser Region auf dem Standardlimit von 1.000. Angenommen, Sie haben zwei kritische Ereignisfunktionenfunction-orange, function-blue die routinemäßig mit hohen Aufrufvolumen rechnen. 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 Event-Funktionen in Ihrem Konto die verbleibenden 200 Einheiten der uneingeschränkten Parallelität teilen.

Das Diagramm enthält fünf wichtige Punkte:

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

Informationen zur Verwaltung reservierter Parallelitätseinstellungen für Ihre Event-Funktionen finden Sie unter. Konfiguration reservierter Parallelität für eine Event-Funktion

Bereitgestellte Gleichzeitigkeit

Sie verwenden reservierte Parallelität, um die maximale Anzahl von Ausführungsumgebungen zu definieren, die für eine Lambda-Ereignisfunktion reserviert sind. Keine dieser Umgebungen ist jedoch vorinitialisiert. Infolgedessen können Ihre Event-Function-Aufrufe länger dauern, da Lambda zuerst die neue Umgebung initialisieren muss, bevor Sie sie zum Aufrufen Ihrer Event-Funktion verwenden 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.

Bei der bereitgestellten Parallelität handelt es sich um die Anzahl der vorinitialisierten Ausführungsumgebungen, die Sie Ihrer Event-Funktion zuweisen möchten. Wenn Sie die bereitgestellte Parallelität für eine Event-Funktion festlegen, initialisiert Lambda diese Anzahl von Ausführungsumgebungen, sodass diese bereit sind, sofort auf Anfragen von Event-Funktionen zu reagieren.

Bei der Verwendung von bereitgestellter Gleichzeitigkeit erneuert Lambda weiterhin die Ausführungsumgebung im Hintergrund. Dies kann beispielsweise nach einem Aufruffehler der Fall sein. Lambda stellt jedoch zu jedem Zeitpunkt sicher, dass die Anzahl der vorinitialisierten Umgebungen dem Wert der bereitgestellten Parallelitätseinstellung Ihrer Event-Funktion entspricht. Wichtig: Selbst wenn Sie die bereitgestellte Parallelität verwenden, kann es dennoch zu einer Kaltstartverzögerung kommen, wenn Lambda die Ausführungsumgebung zurücksetzen muss.

Im Gegensatz dazu kann Lambda bei Verwendung von reservierter Parallelität eine Umgebung nach einer gewissen Zeit der Inaktivität vollständig beenden. Das folgende Diagramm veranschaulicht dies, indem der Lebenszyklus einer einzelnen Ausführungsumgebung verglichen wird, wenn Sie Ihre Event Function mit reservierter Parallelität und bereitgestellter Parallelität konfigurieren.

Das Diagramm enthält vier wichtige Punkte:

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 Event-Funktionen in Ihrem Konto, einschließlichfunction-orange, können die verbleibenden 600 Einheiten unreservierter Parallelität verwenden.

Das Diagramm enthält fünf wichtige Punkte:

Im vorherigen Beispiel wurde nur die bereitgestellte Nebenläufigkeit berücksichtigt. In der Praxis können Sie für eine Event-Funktion sowohl die bereitgestellte als auch die reservierte Parallelität festlegen. Sie könnten dies tun, wenn Sie über eine Ereignisfunktion verfügen, die an Wochentagen eine konstante Anzahl von Aufrufen verarbeitet, aber am Wochenende routinemäßig Verkehrsspitzen verzeichnet. 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:

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 Parallelität kann sich auf den Parallelitätspool auswirken, der anderen Eventfunktionen zur Verfügung steht. Für die Konfiguration der bereitgestellten Parallelität fallen Gebühren für Sie an. AWS-Konto

Informationen zur Verwaltung der bereitgestellten Parallelitätseinstellungen für Ihre Eventfunktionen finden Sie unter. Konfiguration der bereitgestellten Parallelität für eine Event-Funktion Informationen zum Automatisieren der bereitgestellten Gleichzeitigkeitsskalierung basierend auf einem Zeitplan oder der Anwendungsnutzung finden Sie unter Auto Scaling von Anwendungen zur Automatisierung der Verwaltung von Gleichzeitigkeit bei der Bereitstellung.

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. Für jede Event-Funktion kann Lambda jede Minute bis zu 6.000 Ausführungsumgebungen bereitstellen, unabhängig davon AWS-Region. Dies entspricht exakt der Skalierungsrate für Parallelität bei Event Functions.

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. Wenn Sie beispielsweise 5 000 bereitgestellte Gleichzeitigkeit anfordern, kann keine Ihrer Anfragen bereitgestellte Gleichzeitigkeit verwenden, bis Lambda die Zuweisung der 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.

Gleichzeitigkeit und Anforderungen pro Sekunde verstehen

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

Für alle Event-Funktionen in Ihrem Konto erzwingt Lambda ein Limit für Anfragen pro Sekunde, das dem Zehnfachen Ihrer Kontoparallelität entspricht. Da das Standardlimit für die gleichzeitige Nutzung von Konten beispielsweise bei 1.000 liegt, können die Ereignisfunktionen in Ihrem Konto maximal 10.000 Anfragen pro Sekunde verarbeiten.

Stellen Sie sich zum Beispiel eine Ereignisfunktion mit einer durchschnittlichen Anforderungsdauer von 50 ms vor. Bei 20.000 Anfragen pro Sekunde sieht die Parallelität dieser Ereignisfunktion wie folgt aus:

Concurrency = (20,000 requests/second) * (0.05 second/request) = 1,000

Ausgehend von diesem Ergebnis könnte man annehmen, dass die Gleichzeitigkeitsgrenze von 1 000 Konten ausreicht, um diese Last zu bewältigen. Aufgrund der Obergrenze von 10.000 Anfragen pro Sekunde kann Ihre Ereignisfunktion jedoch nur 10.000 Anfragen pro Sekunde von den insgesamt 20.000 Anfragen verarbeiten. Bei dieser Ereignisfunktion kommt es zu einer Drosselung.

Die Lektion besteht darin, dass Sie bei der Konfiguration der Parallelitätseinstellungen für Ihre Ereignisfunktionen sowohl Parallelität als auch Anfragen pro Sekunde berücksichtigen müssen. In diesem Fall müssen Sie eine Erhöhung des Kontogleichzeitigkeitslimits auf 2 000 beantragen, da sich dadurch Ihr Gesamtlimit für Anfragen pro Sekunde auf 20 000 erhöhen würde.

Concurrency = (30,000 requests/second) * (0.02 seconds/request) = 600

Das Limit für Anfragen pro Sekunde gilt für alle Kontingente in Lambda, die Gleichzeitigkeit beinhalten. Mit anderen Worten, sie gilt für synchrone On-Demand-Ereignisfunktionen, für Ereignisfunktionen, die bereitgestellte Parallelität verwenden, und für das Skalierungsverhalten bei Parallelität. Im Folgenden finden Sie beispielsweise einige Szenarien, in denen Sie sowohl Ihre Grenzwerte für Parallelität als auch für Anfragen pro Sekunde sorgfältig abwägen müssen:

Gleichzeitigkeitskontingente

Lambda legt Kontingente für die Gesamtmenge an Parallelität fest, die Sie für alle Eventfunktionen in einer Region verwenden können. Diese Kontingente bestehen auf zwei Ebenen:

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

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

ConcurrentExecutionsist Ihr Gesamtkontingent für Parallelität auf Kontoebene. UnreservedConcurrentExecutionsist die Menge an reservierter Parallelität, die Sie Ihren Event-Funktionen noch zuweisen können.

Wenn Ihre Event-Funktion mehr Anfragen erhält, skaliert Lambda automatisch die Anzahl der Ausführungsumgebungen, um diese Anfragen zu bearbeiten, bis Ihr Konto seine Parallelitätsquote erreicht hat. Zum Schutz vor einer Überskalierung als Reaktion auf plötzliche Datenverkehrsspitzen begrenzt Lambda jedoch, wie schnell Ihre Funktionen skaliert werden können. Diese Skalierungsrate für Parallelität ist die maximale Geschwindigkeit, mit der Event Functions in Ihrem Konto als Reaktion auf erhöhte Anfragen skaliert werden können. (Das heißt, sie gibt an, wie schnell Lambda neue Ausführungsumgebungen erstellen kann.) Die Skalierungsrate für Parallelität unterscheidet sich vom Parallelitätslimit auf Kontoebene, das der Gesamtmenge an Parallelität entspricht, die Ihren Eventfunktionen zur Verfügung steht.

In jeder AWS-Region und für jede Event-Funktion beträgt Ihre Parallelitätsskalierungsrate 1.000 Instanzen der Ausführungsumgebung alle 10 Sekunden (oder 10.000 Anfragen pro Sekunde alle 10 Sekunden). Mit anderen Worten: Lambda kann jeder Ihrer Funktionen alle 10 Sekunden höchstens 1 000 zusätzliche Instanzen der Ausführungsumgebung zuweisen oder 10 000 zusätzliche Anfragen pro Sekunde bearbeiten.

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 Skalierungsrate für die Gleichzeitigkeit eine Grenze auf Funktionsebene darstellt. Das bedeutet, dass jede Event-Funktion in Ihrem Konto unabhängig von anderen Event-Funktionen skaliert werden kann.

Weitere Informationen zum Skalierungsverhalten finden Sie unter Skalierungsverhalten der Event-Funktion.