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.
# Verstehen der Skalierung von Lambda-Funktionen
**Parallelität** 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](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/) und Gleichzeitigkeitskontrollen auf Funktionsebene konfigurieren, damit Ihre kritischen Funktionen nicht gedrosselt werden.
In diesem Thema werden Gleichzeitigkeitskonzepte 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.
**Topics**
+ [
## Verstehen und Visualisieren der Gleichzeitigkeit
](#understanding-concurrency)
+ [
## Berechnen der Gleichzeitigkeit einer Funktion
](#calculating-concurrency)
+ [
## Verständnis der reservierten Gleichzeitigkeit und der bereitgestellten Gleichzeitigkeit
](#reserved-and-provisioned)
+ [
## Gleichzeitigkeit und Anforderungen pro Sekunde verstehen
](#concurrency-vs-requests-per-second)
+ [
## Gleichzeitigkeitskontingente
](#concurrency-quotas)
+ [
# Konfigurieren reservierter Gleichzeitigkeit für eine Funktion
](configuration-concurrency.md)
+ [
# Konfigurieren von Provisioned Concurrency für eine Funktion
](provisioned-concurrency.md)
+ [
# Lambda-Skalierungsverhalten
](scaling-behavior.md)
+ [
# Überwachen der Gleichzeitigkeit
](monitoring-concurrency.md)
## Verstehen und Visualisieren der Gleichzeitigkeit
Lambda ruft Ihre Funktion in einer sicheren und isolierten [Ausführungsumgebung](lambda-runtime-environment.md) auf. Um eine Anfrage zu bearbeiten, muss Lambda zuerst eine Ausführungsumgebung initialisieren (die [Initialisierungsphase](lambda-runtime-environment.md#runtimes-lifecycle-ib)), bevor es zum Aufrufen Ihrer Funktion verwendet wird (die [Aufrufphase](lambda-runtime-environment.md#runtimes-lifecycle-invoke)):
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-1-environment.png)
**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.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-2-two-requests.png)
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:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-3-ten-requests.png)
Im vorherigen Diagramm stellt jede horizontale Ebene eine einzelne Instance der Ausführungsumgebung dar (von `A` bis `F`). So behandelt Lambda jede Anfrage:
| 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ührungsumgebung**B** 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:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-4-animation.gif)
Durch das Einfrieren der vorherigen Animation an sechs verschiedenen Zeitpunkten erhalten wir das folgende Diagramm:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-5-animation-summary.png)
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.
## Berechnen der Gleichzeitigkeit einer Funktion
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
```
## Verständnis der reservierten Gleichzeitigkeit und der bereitgestellten 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. Bei Ihren Funktionen kommt es zu einer Drosselung (d. h. sie beginnen, Anfragen zu verwerfen), wenn Ihnen die verfügbare Parallelität 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 Parallelität**, um die maximale und die minimale Anzahl gleichzeitiger Instances festzulegen, um einen Teil der Parallelität 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. Wenn für eine Funktion Gleichzeitigkeit reserviert ist, kann keine andere Funktion diese Gleichzeitigkeit nutzen.
+ 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 Parallelität legt die maximale und minimale Anzahl der gleichzeitigen Instances fest, 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:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-6-reserved-concurrency.png)
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 Parallelität legt eine Obergrenze für die maximale und minimale Parallelität Ihrer Funktion fest. Dies bedeutet, dass Ihre Funktion keine für andere Funktionen reservierte Gleichzeitigkeit oder Gleichzeitigkeit aus dem nicht reservierten Pool verwenden kann. Darüber hinaus dient die reservierte Parallelität sowohl als Untergrenze als auch als Obergrenze. Sie reserviert die angegebene Kapazität ausschließlich für Ihre Funktion und verhindert gleichzeitig, dass sie über diese Grenze hinaus skaliert wird. 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 für eine Funktion](configuration-concurrency.md).
### 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](lambda-runtime-environment.md#cold-start-latency) 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 beide SnapStart und die bereitgestellte Parallelität auf derselben Funktionsversion verwenden. Weitere Informationen zu SnapStart Funktionen, Einschränkungen und unterstützten Regionen finden Sie unter. [Verbesserung der Startleistung mit Lambda SnapStart](snapstart.md)
Bei der Verwendung von bereitgestellter Gleichzeitigkeit erneuert Lambda weiterhin die Ausführungsumgebung im Hintergrund. Dies kann beispielsweise [nach einem Aufruffehler](lambda-runtime-environment.md#runtimes-lifecycle-invoke-with-errors) der Fall sein. Lambda stellt jedoch zu jedem Zeitpunkt sicher, dass die Anzahl der vorinitialisierten Umgebungen dem Wert der von Ihrer Funktion bereitgestellten Gleichzeitigkeitseinstellung 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 einem Zeitraum der Inaktivität vollständig beenden. Das folgende Diagramm veranschaulicht dies, indem der Lebenszyklus einer einzelnen Ausführungsumgebung beim Konfigurieren Ihrer Funktion mit reservierter Gleichzeitigkeit mit bereitgestellter Gleichzeitigkeit verglichen wird.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-7-reserved-vs-provisioned.png)
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:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-8-provisioned-concurrency.png)
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:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-9-reserved-and-provisioned.png)
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](gettingstarted-limits.md) 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. Für die Konfiguration der bereitgestellten Parallelität fallen Gebühren für Sie an. 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 für eine Funktion](provisioned-concurrency.md). 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](provisioned-concurrency.md#managing-provisioned-concurency).
### 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 Funktion kann Lambda jede Minute bis zu 6.000 Ausführungsumgebungen bereitstellen, unabhängig davon AWS-Region. Dies entspricht exakt der [Skalierungsrate für die Gleichzeitigkeit](scaling-behavior.md#scaling-rate) von Funktionen.
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.
| 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. |
## Gleichzeitigkeit und Anforderungen pro Sekunde verstehen
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.
Für alle Funktionen in Ihrem Konto erzwingt Lambda ein Limit für Anfragen pro Sekunde, das dem 10-fachen der Gleichzeitigkeit Ihres Kontos entspricht. Da der Standardgrenzwert für die Gleichzeitigkeit von Konten beispielsweise 1 000 beträgt, können die Funktionen in Ihrem Konto maximal 10 000 Anfragen pro Sekunde verarbeiten.
Stellen Sie sich etwa eine Funktion mit einer durchschnittlichen Anforderungsdauer von 50 ms vor. Bei 20 000 Anforderungen pro Sekunde lautet die Gleichzeitigkeit dieser Funktion wie folgt:
```
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 Begrenzung auf 10 000 Anfragen pro Sekunde kann Ihre Funktion jedoch nur 10 000 der insgesamt 20 000 Anfragen pro Sekunde bearbeiten. 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 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.
**Anmerkung**
Basierend auf diesem Limit für Anfragen pro Sekunde ist es falsch zu sagen, dass jede Lambda-Ausführungsumgebung nur maximal zehn Anfragen pro Sekunde verarbeiten kann. Anstatt die Auslastung einer einzelnen Ausführungsumgebung zu beobachten, berücksichtigt Lambda bei der Berechnung der Quoten nur die Gesamtgleichzeitigkeit und die Gesamtanforderungen pro Sekunde.
### 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 30 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. Mithilfe der Parallelitätsformel können Sie die Zahlen einfügen, um eine Parallelität von 600 zu erhalten:
```
Concurrency = (30,000 requests/second) * (0.02 seconds/request) = 600
```
Standardmäßig scheint eine Kontogleichzeitigkeitslimit von 1 000 ausreichend zu sein, um diese Last zu bewältigen. Das Limit für Anfragen pro Sekunde von 10 000 reicht jedoch nicht aus, um die eingehenden 30 000 Anfragen pro Sekunde zu verarbeiten. Um den 30 000 Anfragen in vollem Umfang gerecht zu werden, müssen Sie eine Erhöhung des Kontogleichzeitigkeitslimits auf 3 000 oder mehr beantragen.
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-Funktionen, Funktionen, die bereitgestellte Gleichzeitigkeit verwenden, und [Skalierungsverhalten bei Gleichzeitigkeit](scaling-behavior.md). 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:
+ Bei einer Funktion, die On-Demand-Parallelität verwendet, kann es zu einem Anstieg der Parallelität um 500 Mal alle 10 Sekunden oder um 5 000 Anfragen pro Sekunde alle 10 Sekunden kommen, je nachdem, was zuerst eintritt.
+ Angenommen, Sie haben eine Funktion, die eine bereitgestellte Gleichzeitigkeitszuweisung von 10 hat. Diese Funktion geht nach 10 Gleichzeitigkeiten oder 100 Anfragen pro Sekunde, je nachdem, was zuerst eintritt, in die On-Demand-Gleichzeitigkeit über.
## 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](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) 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.
+ Sowohl auf Konto- als auch auf Funktionsebene erzwingt Lambda außerdem ein Limit für Anfragen pro Sekunde, das dem Zehnfachen der entsprechenden Gleichzeitigkeitsquote entspricht. Dies gilt beispielsweise für die Gleichzeitigkeit auf Kontoebene, für Funktionen, die die Gleichzeitigkeit auf Abruf verwenden, für Funktionen, die die provisorische Gleichzeitigkeit verwenden und für das [Skalierungsverhalten der Gleichzeitigkeit](scaling-behavior.md). Weitere Informationen finden Sie unter [Gleichzeitigkeit und Anforderungen pro Sekunde verstehen](#concurrency-vs-requests-per-second).
Um Ihr aktuelles Kontingent für Parallelität auf Kontoebene zu überprüfen, verwenden Sie 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 **Gleichzeitigkeits-Skalierungsrate** ist die maximale Rate, mit der Funktionen in Ihrem Konto als Reaktion auf erhöhte Anforderungen skaliert werden können. (Das heißt, sie gibt an, wie schnell Lambda neue Ausführungsumgebungen erstellen kann.) Die Skalierungsrate für die Gleichzeitigkeit unterscheidet sich von der Gleichzeitigkeitsgrenze auf Kontoebene, die die Gesamtmenge der Gleichzeitigkeit darstellt, die Ihren Funktionen zur Verfügung steht.
**In jeder AWS-Region Funktion beträgt Ihre Skalierungsrate für Parallelität 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 Funktion in Ihrem Konto unabhängig von anderen Funktionen skaliert werden kann.
Weitere Informationen zum Skalierungsverhalten finden Sie unter [Lambda-Skalierungsverhalten](scaling-behavior.md).
# Konfigurieren reservierter Gleichzeitigkeit für eine Funktion
In Lambda beschreibt die [Gleichzeitigkeit](lambda-concurrency.md) die Anzahl der In-Flight-Anfragen, die Ihre Funktion gleichzeitig bearbeitet. Es gibt zwei Arten von Gleichzeitigkeitskontrollen:
+ Reservierte Gleichzeitigkeit – Hiermit wird sowohl die maximale als auch die minimale Anzahl der gleichzeitigen Instances festgelegt, die Ihrer Funktion zugewiesen sind. Wenn für eine Funktion Gleichzeitigkeit reserviert ist, kann keine andere Funktion diese Gleichzeitigkeit nutzen. Reservierte Gleichzeitigkeit ist nützlich, um sicherzustellen, dass Ihre kritischsten Funktionen immer genügend Gleichzeitigkeit haben, um eingehende Anfragen zu bearbeiten. Darüber hinaus kann reservierte Gleichzeitigkeit verwendet werden, um die Gleichzeitigkeit einzuschränken, um zu verhindern, dass nachgelagerte Ressourcen wie Datenbankverbindungen überlastet werden. Die reservierte Gleichzeitigkeit dient sowohl als Untergrenze als auch als Obergrenze. Sie reserviert die angegebene Kapazität ausschließlich für Ihre Funktion und verhindert gleichzeitig, dass sie über diese Grenze hinaus skaliert wird. Für die Konfiguration reservierter Gleichzeitigkeit für eine Funktion wird keine zusätzliche Gebühr erhoben.
+ Die bereitgestellte Gleichzeitigkeit beschreibt die Anzahl der vorinitialisierten Ausführungsumgebungen, die Ihrer Funktion zugewiesen sind. Diese Ausführungsumgebungen sind bereit, sofort auf eingehende Funktionsanforderungen zu reagieren. Bereitgestellte Gleichzeitigkeit ist nützlich, um Kaltstartlatenzen für Funktionen zu reduzieren, und wurde entwickelt, um Funktionen mit Antwortzeiten im zweistelligen Millisekundenbereich verfügbar zu machen. Im Allgemeinen profitieren interaktive Workloads am meisten von diesem Feature. Dabei handelt es sich um Anwendungen, bei denen Benutzer Anfragen initiieren, wie z. B. Web- und Mobilanwendungen und sie reagieren am empfindlichsten auf Latenz. Asynchrone Workloads, wie Datenverarbeitungspipelines, reagieren häufig weniger empfindlich auf Latenz und benötigen daher in der Regel keine bereitgestellte Gleichzeitigkeit. Die Konfiguration von bereitgestellter Gleichzeitigkeit verursacht Gebühren für Ihr AWS-Konto.
In diesem Thema wird beschrieben, wie Sie reservierte Gleichzeitigkeit verwalten und konfigurieren. Eine konzeptionelle Übersicht über diese beiden Arten von Gleichzeitigkeitssteuerungen finden Sie unter [Reservierte Gleichzeitigkeit und bereitgestellte Gleichzeitigkeit](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned). Weitere Informationen zum Konfigurieren der bereitgestellten Gleichzeitigkeit finden Sie unter [Konfigurieren von Provisioned Concurrency für eine Funktion](provisioned-concurrency.md).
**Anmerkung**
Lambda-Funktionen, die mit einer Amazon-MQ-Ereignisquellenzuordnung verknüpft sind, haben standardmäßig die maximale Gleichzeitigkeit. Für Apache Active MQ ist die maximale Anzahl der gleichzeitigen Instances 5. Für Rabbit MQ ist die maximale Anzahl der gleichzeitigen Instances 1. Wenn Sie für Ihre Funktion eine reservierte oder bereitgestellte Parallelität festlegen, werden diese Grenzwerte nicht geändert. Um eine Erhöhung der standardmäßigen maximalen Parallelität bei der Verwendung von Amazon MQ zu beantragen, wenden Sie sich an. Support
**Topics**
+ [
## Konfigurieren reservierter Gleichzeitigkeit
](#configuring-concurrency-reserved)
+ [
## Genaue Schätzung reservierter Gleichzeitigkeit für eine Funktion
](#estimating-reserved-concurrency)
## Konfigurieren reservierter Gleichzeitigkeit
Sie können die Einstellungen der reservierten Gleichzeitigkeit für eine Funktion in der Lambda-Konsole oder mit der Lambda-API konfigurieren.
**Reservieren von Gleichzeitigkeit für eine Funktion (Konsole)**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie die Funktion aus, für sie Sie Gleichzeitigkeit reservieren möchten.
1. Wählen Sie **Konfiguration** und anschließend **Gleichzeitigkeit** aus.
1. Wählen Sie unter **Concurrency (Parallelität)** die Option **Edit (Bearbeiten)**.
1. Wählen Sie **Reserve concurrency (Parallelität reservieren)**. Geben Sie die Menge an Gleichzeitigkeit an, die für die Funktion reserviert werden soll.
1. Wählen Sie **Speichern**.
Sie können bis zum Wert von **Nicht reservierte Kontonebenläufigkeit** minus 100 reservieren. Die verbleibenden 100 Gleichzeitigkeitseinheiten sind für Funktionen bestimmt, die keine reservierte Gleichzeitigkeit verwenden. Wenn für Ihr Konto beispielsweise eine Gleichzeitigkeitsbeschränkung von 1 000 gilt, können Sie nicht alle 1 000 Gleichzeitigkeitseinheiten für eine einzelne Funktion reservieren.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-reserve-over-limit.png)
Das Reservieren von Gleichzeitigkeit für eine Funktion hat Auswirkungen auf den Pool, der für andere Funktionen verfügbar ist. Wenn Sie beispielsweise 100 Gleichzeitigkeitseinheiten für `function-a` reservieren, müssen sich andere Funktionen in Ihrem Konto die verbleibenden 900 Gleichzeitigkeitseinheiten teilen, auch wenn `function-a` nicht alle 100 reservierten Gleichzeitigkeitseinheiten verwendet.
Um eine Funktion absichtlich zu drosseln, setzen Sie die reservierte Gleichzeitigkeit dafür auf 0. Dadurch kann die Funktion keine Ereignisse mehr verarbeiten, bis Sie die Beschränkung aufheben.
Verwenden Sie für die Konfiguration von reservierter Gleichzeitigkeit mithilfe der Lambda-API die folgenden API-Vorgänge:
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)
+ [GetFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConcurrency.html)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)
Um beispielsweise reservierte Gleichzeitigkeit mit der AWS Command Line Interface (CLI) zu konfigurieren, verwenden Sie den `put-function-concurrency`-Befehl. Der folgende Befehl reserviert 100 Gleichzeitigkeitseinheiten für eine Funktion namens `my-function`:
```
aws lambda put-function-concurrency --function-name my-function \
--reserved-concurrent-executions 100
```
Die Ausgabe sollte ungefähr wie folgt aussehen:
```
{
"ReservedConcurrentExecutions": 100
}
```
## Genaue Schätzung reservierter Gleichzeitigkeit für eine Funktion
Wenn Ihre Funktion gerade Datenverkehr verarbeitet, können Sie ihre Gleichzeitigkeitsmetriken ganz einfach mit [CloudWatch-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) anzeigen. Insbesondere zeigt Ihnen die `ConcurrentExecutions`-Metrik die Anzahl der gleichzeitigen Aufrufe für jede Funktion in Ihrem Konto.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
Aus dem vorstehenden Diagramm geht hervor, dass diese Funktion jederzeit im Durchschnitt 5 bis 10 gleichzeitige Anforderungen verarbeitet und an einem typischen Tag Spitzenwerte von 20 Anforderungen erreicht. Angenommen, Ihr Konto enthält viele andere Funktionen. ** Wenn diese Funktion für Ihre Anwendung von entscheidender Bedeutung ist und Sie keine Anforderungen abbrechen möchten**, verwenden Sie mindestens 20 als Einstellung für die reservierte Gleichzeitigkeit.
Denken Sie alternativ daran, dass Sie die Gleichzeitigkeit auch mit der folgenden Formel [berechnen](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency) können:
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
Wenn Sie die durchschnittlichen Anforderungen pro Sekunde mit der durchschnittlichen Anforderungsdauer in Sekunden multiplizieren, erhalten Sie eine grobe Schätzung, wie viel Gleichzeitigkeit Sie reservieren müssen. Sie können die durchschnittlichen Anfragen pro Sekunde anhand der `Invocation`-Metrik und die durchschnittliche Anfragedauer in Sekunden anhand der `Duration`-Metrik schätzen. Weitere Details finden Sie unter [Verwendung von CloudWatch-Metriken mit Lambda](monitoring-metrics.md).
Sie sollten auch mit Ihren vor- und nachgelagerten Durchsatzbeschränkungen vertraut sein. Lambda-Funktionen lassen sich zwar nahtlos abhängig von der Last skalieren, aber vor- und nachgelagerte Abhängigkeiten verfügen möglicherweise nicht über die gleichen Durchsatzfähigkeiten. Wenn Sie die Skalierbarkeit Ihrer Funktion begrenzen müssen, konfigurieren Sie die reservierte Gleichzeitigkeit für Ihre Funktion.
# Konfigurieren von Provisioned Concurrency für eine Funktion
In Lambda beschreibt die [Gleichzeitigkeit](lambda-concurrency.md) die Anzahl der In-Flight-Anfragen, die Ihre Funktion gleichzeitig bearbeitet. Es gibt zwei Arten von Gleichzeitigkeitskontrollen:
+ Reservierte Gleichzeitigkeit – Hiermit wird sowohl die maximale als auch die minimale Anzahl der gleichzeitigen Instances festgelegt, die Ihrer Funktion zugewiesen sind. Wenn für eine Funktion Gleichzeitigkeit reserviert ist, kann keine andere Funktion diese Gleichzeitigkeit nutzen. Reservierte Gleichzeitigkeit ist nützlich, um sicherzustellen, dass Ihre kritischsten Funktionen immer genügend Gleichzeitigkeit haben, um eingehende Anfragen zu bearbeiten. Darüber hinaus kann reservierte Gleichzeitigkeit verwendet werden, um die Gleichzeitigkeit einzuschränken, um zu verhindern, dass nachgelagerte Ressourcen wie Datenbankverbindungen überlastet werden. Die reservierte Gleichzeitigkeit dient sowohl als Untergrenze als auch als Obergrenze. Sie reserviert die angegebene Kapazität ausschließlich für Ihre Funktion und verhindert gleichzeitig, dass sie über diese Grenze hinaus skaliert wird. Für die Konfiguration reservierter Gleichzeitigkeit für eine Funktion wird keine zusätzliche Gebühr erhoben.
+ Die bereitgestellte Gleichzeitigkeit beschreibt die Anzahl der vorinitialisierten Ausführungsumgebungen, die Ihrer Funktion zugewiesen sind. Diese Ausführungsumgebungen sind bereit, sofort auf eingehende Funktionsanforderungen zu reagieren. Bereitgestellte Gleichzeitigkeit ist nützlich, um Kaltstartlatenzen für Funktionen zu reduzieren, und wurde entwickelt, um Funktionen mit Antwortzeiten im zweistelligen Millisekundenbereich verfügbar zu machen. Im Allgemeinen profitieren interaktive Workloads am meisten von diesem Feature. Dabei handelt es sich um Anwendungen, bei denen Benutzer Anfragen initiieren, wie z. B. Web- und Mobilanwendungen und sie reagieren am empfindlichsten auf Latenz. Asynchrone Workloads, wie Datenverarbeitungspipelines, reagieren häufig weniger empfindlich auf Latenz und benötigen daher in der Regel keine bereitgestellte Gleichzeitigkeit. Die Konfiguration von bereitgestellter Gleichzeitigkeit verursacht Gebühren für Ihr AWS-Konto.
In diesem Thema wird beschrieben, wie Sie bereitgestellte Gleichzeitigkeit verwalten und konfigurieren. Eine konzeptionelle Übersicht über diese beiden Arten von Gleichzeitigkeitssteuerungen finden Sie unter [Reservierte Gleichzeitigkeit und bereitgestellte Gleichzeitigkeit](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned). Weitere Informationen zur Konfiguration der reservierten Gleichzeitigkeit finden Sie unter [Konfigurieren reservierter Gleichzeitigkeit für eine Funktion](configuration-concurrency.md).
**Anmerkung**
Lambda-Funktionen, die mit einer Amazon-MQ-Ereignisquellenzuordnung verknüpft sind, haben standardmäßig die maximale Gleichzeitigkeit. Für Apache Active MQ ist die maximale Anzahl der gleichzeitigen Instances 5. Für Rabbit MQ ist die maximale Anzahl der gleichzeitigen Instances 1. Wenn Sie für Ihre Funktion eine reservierte oder bereitgestellte Parallelität festlegen, werden diese Grenzwerte nicht geändert. Um eine Erhöhung der standardmäßigen maximalen Parallelität bei der Verwendung von Amazon MQ zu beantragen, wenden Sie sich an. Support
**Topics**
+ [
## Konfigurieren von Provisioned Concurrency
](#configuring-provisioned-concurrency)
+ [
## Genaue Schätzung der erforderlichen bereitgestellten Gleichzeitigkeit für eine Funktion
](#estimating-provisioned-concurrency)
+ [
## Optimierung des Funktionscodes bei Verwendung der bereitgestellten Gleichzeitigkeit
](#optimizing-latency)
+ [
## Verwendung von Umgebungsvariablen zur Anzeige und Steuerung des bereitgestellten Gleichzeitigkeitsverhaltens
](#pc-environment-variables)
+ [
## Verstehen des Protokollierungs- und Abrechnungsverhaltens bei bereitgestellter Gleichzeitigkeit
](#pc-logging-behavior)
+ [
## Auto Scaling von Anwendungen zur Automatisierung der Verwaltung von Gleichzeitigkeit bei der Bereitstellung
](#managing-provisioned-concurency)
## Konfigurieren von Provisioned Concurrency
Sie können die Einstellungen der bereitgestellten Gleichzeitigkeit für eine Funktion mit der Lambda-Konsole oder mit der Lambda-API konfigurieren.
**So weisen Sie einer Funktion bereitgestellte Gleichzeitigkeit zu (Konsole)**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie die Funktion aus, der Sie bereitgestellte Gleichzeitigkeit zuweisen möchten.
1. Wählen Sie **Konfiguration** und anschließend **Gleichzeitigkeit** aus.
1. Wählen Sie unter **Provisioned concurrency configurations (Bereitgestellte Gleichzeitigkeitskonfigurationen)** die Option **Add (Hinzufügen)** aus.
1. Wählen Sie den Qualifizierungstyp und den Alias oder die Version aus.
**Anmerkung**
Sie können die bereitgestellte Gleichzeitigkeit nicht mit der \$1LATEST-Version einer Funktion verwenden.
Wenn Ihre Funktion eine Ereignisquelle hat, müssen Sie sicherstellen, dass die Ereignisquelle auf den richtigen Funktionsalias bzw. die richtige Funktionsversion verweist. Anderenfalls verwendet Ihre Funktion keine bereitgestellten Gleichzeitigkeitsumgebungen.
1. Geben Sie unter **Bereitgestellte Gleichzeitigkeit** eine Zahl ein.
1. Wählen Sie **Speichern**.
Sie können in Ihrem Konto Gleichzeitigkeit bis zur **nicht reservierten Konto-Gleichzeitigkeit** minus 100 konfigurieren. Die verbleibenden 100 Gleichzeitigkeitseinheiten sind für Funktionen bestimmt, die keine reservierte Gleichzeitigkeit verwenden. Wenn Ihr Konto beispielsweise einen Gleichzeitigkeitsgrenzwert von 1 000 aufweist und Sie keiner anderen Funktion reservierte oder bereitgestellte Gleichzeitigkeit zugewiesen haben, können Sie maximal 900 bereitgestellte Gleichzeitigkeitseinheiten für eine einzelne Funktion konfigurieren.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/provisioned-concurrency-over-limit.png)
Die Konfiguration der bereitgestellten Gleichzeitigkeit für eine Funktion wirkt sich auf den Pool für die Gleichzeitigkeit aus, der für andere Funktionen verfügbar ist. Wenn Sie beispielsweise 100 bereitgestellte Gleichzeitigkeitseinheiten für `function-a` konfigurieren, müssen sich andere Funktionen in Ihrem Konto die verbleibenden 900 Gleichzeitigkeitseinheiten teilen. Das gilt auch, wenn `function-a` nicht alle 100 Einheiten verwendet.
Sie können für eine Funktion sowohl reservierte als auch bereitgestellte Gleichzeitigkeit festlegen. In solchen Fällen darf die bereitgestellte Gleichzeitigkeit die reservierte Gleichzeitigkeit nicht überschreiten.
Dieser Grenzwert gilt auch für Funktionsversionen. Die maximale Menge an bereitgestellter Gleichzeitigkeit, die Sie einer bestimmten Funktionsversion zuweisen können, entspricht der reservierten Gleichzeitigkeit der Funktion abzüglich der in anderen Funktionsversionen bereitgestellten Gleichzeitigkeit.
Verwenden Sie für die Konfiguration der bereitgestellten Gleichzeitigkeit mithilfe der Lambda-API die folgenden API-Operationen:
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [GetProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html)
+ [ListProvisionedConcurrencyConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
Um beispielsweise bereitgestellte Gleichzeitigkeit mit der AWS Command Line Interface (CLI) zu konfigurieren, verwenden Sie den `put-provisioned-concurrency-config`-Befehl. Der folgende Befehl weist 100 Einheiten bereitgestellter Gleichzeitigkeit für den Alias `BLUE` einer Funktion namens `my-function` zu:
```
aws lambda put-provisioned-concurrency-config --function-name my-function \
--qualifier BLUE \
--provisioned-concurrent-executions 100
```
Die Ausgabe sollte ungefähr wie folgt aussehen:
```
{
"Requested ProvisionedConcurrentExecutions": 100,
"Allocated ProvisionedConcurrentExecutions": 0,
"Status": "IN_PROGRESS",
"LastModified": "2023-01-21T11:30:00+0000"
}
```
## Genaue Schätzung der erforderlichen bereitgestellten Gleichzeitigkeit für eine Funktion
Sie können die Gleichzeitigkeitsmetriken jeder aktiven Funktion mithilfe von [CloudWatch-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) anzeigen. Insbesondere zeigt Ihnen die `ConcurrentExecutions`-Metrik die Anzahl der gleichzeitigen Aufrufe für Funktionen in Ihrem Konto.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
Aus dem vorstehenden Diagramm geht hervor, dass diese Funktion jederzeit im Durchschnitt 5 bis 10 gleichzeitige Anforderungen verarbeitet und Spitzenwerte von 20 Anforderungen erreicht. Angenommen, Ihr Konto enthält viele andere Funktionen. ** Wenn diese Funktion für Ihre Anwendung von entscheidender Bedeutung ist und Sie bei jedem Aufruf eine Reaktion mit geringer Latenz wünschen**, legen Sie für die bereitgestellte Gleichzeitigkeit eine Zahl fest, die größer oder gleich 20 ist.
Denken Sie daran, dass Sie die [Gleichzeitigkeit auch mit der folgenden Formel berechnen können](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency):
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
Um abzuschätzen, wie viel Gleichzeitigkeit Sie benötigen, multiplizieren Sie die durchschnittlichen Anfragen pro Sekunde mit der durchschnittlichen Anfragedauer in Sekunden. Sie können die durchschnittlichen Anfragen pro Sekunde anhand der `Invocation`-Metrik und die durchschnittliche Anfragedauer in Sekunden anhand der `Duration`-Metrik schätzen.
Beim Konfigurieren der bereitgestellten Gleichzeitigkeit schlägt Lambda vor, einen Puffer von 10 % zusätzlich zu der Menge an Gleichzeitigkeit einzuplanen, die Ihre Funktion normalerweise benötigt. Wenn die Funktion normalerweise bei 200 gleichzeitigen Anforderungen Spitzenwerte erreicht, sollten Sie die bereitgestellte Gleichzeitigkeit auf 220 festlegen (200 gleichzeitige Anforderungen \$1 10 % = 220 bereitgestellte Gleichzeitigkeit).
## Optimierung des Funktionscodes bei Verwendung der bereitgestellten Gleichzeitigkeit
Wenn Sie bereitgestellte Gleichzeitigkeit verwenden, sollten Sie Ihren Funktionscode so umstrukturieren, dass er für niedrige Latenzzeiten optimiert ist. Bei Funktionen, die bereitgestellte Gleichzeitigkeit verwenden, führt Lambda jeglichen Initialisierungscode, wie das Laden von Bibliotheken und die Instanziierung von Clients, während der Zuweisungszeit aus. Daher bietet es sich an, möglichst viele Initialisierungen außerhalb des Hauptfunktionshandlers zu verschieben, um bei tatsächlichen Funktionsaufrufen Latenzprobleme zu vermeiden. Im Gegensatz dazu bedeutet die Initialisierung von Bibliotheken oder die Instanziierung von Clients innerhalb Ihres Haupthandler-Codes, dass Ihre Funktion dies bei jedem Aufruf ausführen muss (dies geschieht unabhängig davon, ob Sie die bereitgestellte Gleichzeitigkeit verwenden).
Bei On-Demand-Aufrufen muss Lambda den Initialisierungscode möglicherweise jedes Mal neu ausführen, wenn die Funktion einen Kaltstart durchführt. In diesem Fall können Sie die Initialisierung einzelner Fähigkeiten verschieben, bis Ihre Funktion sie benötigt. Sehen Sie sich zum Beispiel den folgenden Steuerungsablauf für einen Lambda-Handler an:
```
def handler(event, context):
...
if ( some_condition ):
// Initialize CLIENT_A to perform a task
else:
// Do nothing
```
Im vorherigen Beispiel entschied sich der Entwickler dagegen, `CLIENT_A` außerhalb des Haupthandlers zu initialisieren, und initialisierte ihn stattdessen innerhalb der `if`-Anweisung. Auf diese Weise führt Lambda diesen Code nur aus, wenn die Bedingung `some_condition` erfüllt wird. Wenn `CLIENT_A` außerhalb des Haupthandlers initialisiert wird, führt Lambda diesen Code bei jedem Kaltstart aus. Das kann die Gesamtlatenz erhöhen.
Sie können Kaltstarts messen, während Lambda aufsteigt, indem Sie Ihre Funktion um eine Röntgenüberwachung ergänzen. Eine Funktion, die bereitgestellte Gleichzeitigkeit verwendet, weist kein Kaltstartverhalten auf, da die Ausführungsumgebung vor dem Aufruf vorbereitet wird. Bereitgestellte Gleichzeitigkeit muss jedoch auf eine [bestimmte Version oder einen Alias](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) einer Funktion angewendet werden, nicht auf die \$1LATEST-Version. Falls weiterhin ein Kaltstartverhalten auftritt, stellen Sie sicher, dass Sie die Alias-Version aufrufen, für die bereitgestellte Gleichzeitigkeit konfiguriert ist.
## Verwendung von Umgebungsvariablen zur Anzeige und Steuerung des bereitgestellten Gleichzeitigkeitsverhaltens
Es ist möglich, dass Ihre Funktion die gesamte bereitgestellte Gleichzeitigkeit verbraucht. Lambda verwendet On-Demand-Instances, um zusätzlichen Datenverkehr zu verarbeiten. Um festzustellen, welche Art von Initialisierung Lambda für eine bestimmte Umgebung verwendet hat, überprüfen Sie den Wert der Umgebungsvariable `AWS_LAMBDA_INITIALIZATION_TYPE`. Diese Variable hat zwei mögliche Werte: `provisioned-concurrency` oder `on-demand`. Der Wert von `AWS_LAMBDA_INITIALIZATION_TYPE` ist unveränderlich und bleibt während der gesamten Lebensdauer der Umgebung konstant. Um den Wert einer Umgebungsvariablen in Ihrem Funktionscode zu überprüfen, finden Sie unter [Abrufen von Lambda-Umgebungsvariablen](configuration-envvars.md#retrieve-environment-variables).
Bei Verwendung der .NET 8-Laufzeit können Sie die Umgebungsvariable `AWS_LAMBDA_DOTNET_PREJIT` konfigurieren, um die Latenz für Funktionen zu verbessern, auch wenn diese keine bereitgestellte Gleichzeitigkeit verwenden. Die .NET-Laufzeitumgebung führt für jede Bibliothek, die der Code zum ersten Mal aufruft, eine verzögerte Kompilierung und Initialisierung durch. Daher kann der erste Aufruf einer Lambda-Funktion länger dauern als nachfolgende Aufrufe. Um dies zu verhindern, können Sie einen von drei Werten für `AWS_LAMBDA_DOTNET_PREJIT` wählen:
+ `ProvisionedConcurrency`: Lambda führt für alle Umgebungen, die bereitgestellte Gleichzeitigkeit verwenden, eine zeitliche JIT-Kompilierung durch. Dies ist der Standardwert.
+ `Always`: Lambda führt für jede Umgebung eine zeitliche JIT-Kompilierung durch, auch wenn die Funktion keine bereitgestellte Gleichzeitigkeit verwendet.
+ `Never`: Lambda deaktiviert die JIT-Kompilierung für alle Umgebungen vorab.
## Verstehen des Protokollierungs- und Abrechnungsverhaltens bei bereitgestellter Gleichzeitigkeit
Für bereitgestellte Gleichzeitigkeitsumgebungen wird der Initialisierungscode Ihrer Funktion während der Zuordnung und alle paar Stunden ausgeführt, da Lambda aktive Instances Ihrer Umgebung recycelt. Lambda rechnet die Initialisierung auch dann ab, wenn die Umgebungs-Instance niemals eine Anforderung verarbeitet. Die bereitgestellte Gleichzeitigkeit wird laufend ausgeführt und getrennt von den Initialisierungs- und Aufrufkosten in Rechnung gestellt. Weitere Einzelheiten finden Sie unter [AWS Lambda-Preise](https://aws.amazon.com/lambda/pricing/).
Wenn Sie eine Lambda-Funktion mit bereitgestellter Gleichzeitigkeit konfigurieren, initialisiert Lambda diese Ausführungsumgebung vor, sodass sie vor Aufrufanforderungen verfügbar ist. Lambda protokolliert bei jeder Initialisierung der Umgebung das Feld [Initialisierungsdauer](lambda-runtime-environment.md#runtimes-lifecycle-ib) der Funktion in einem [platform-initReport](telemetry-schema-reference.md#platform-initReport)-Protokollereignis im JSON-Protokollierungsformat. Um dieses Protokollereignis zu sehen, konfigurieren Sie Ihre [JSON-Protokollebene](monitoring-cloudwatchlogs-logformat.md) auf mindestens `INFO`. Sie können die [Telemetrie-API](telemetry-api-reference.md) auch verwenden, um Plattformereignisse zu verarbeiten, bei denen das Feld „Initialisierungsdauer“ gemeldet wird.
## Auto Scaling von Anwendungen zur Automatisierung der Verwaltung von Gleichzeitigkeit bei der Bereitstellung
Application Auto Scaling ermöglicht es Ihnen, die bereitgestellte Gleichzeitigkeit nach einem Zeitplan oder basierend auf der Auslastung zu verwalten. Wenn Sie vorhersehbare Auslastungsmuster für Ihre Funktion beobachten, verwenden Sie die geplante Skalierung. Wenn Sie möchten, dass Ihre Funktion einen bestimmten Auslastungsprozentsatz beibehält, verwenden Sie eine Richtlinie für die Zielverfolgungsskalierung.
**Anmerkung**
Wenn Sie Auto Scaling von Anwendungen verwenden, um die bereitgestellte Gleichzeitigkeit Ihrer Funktion zu verwalten, stellen Sie sicher, [dass Sie zuerst einen anfänglichen Wert für die bereitgestellte Gleichzeitigkeit konfigurieren](#configuring-provisioned-concurrency). Wenn Ihre Funktion keinen anfänglichen Gleichzeitigkeitswert hat, kann die Application Auto Scaling die Funktionsskalierung möglicherweise nicht ordnungsgemäß durchführen.
### Geplante Skalierung
Application Auto Scaling ermöglicht es Ihnen, Ihren eigenen Skalierungsplan entsprechend vorhersehbarer Laständerungen festzulegen. Weitere Informationen und Beispiele finden Sie unter [Geplante Skalierung für Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) im Benutzerhandbuch für Application Auto Scaling und unter [Planen von mit AWS Lambda bereitgestellter Gleichzeitigkeit für wiederkehrende Spitzenauslastungen](https://aws.amazon.com/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/) auf dem AWS-Compute-Blog.
### Zielverfolgung
Bei der Zielverfolgung erstellt und verwaltet Application Auto Scaling eine Reihe von CloudWatch-Alarmen basierend auf der von Ihnen definierten Skalierungsrichtlinie. Wenn diese Alarme aktiviert werden, passt Application Auto Scaling mithilfe der bereitgestellten Gleichzeitigkeit automatisch die Anzahl der zugewiesenen Umgebungen an. Verwenden Sie die Zielverfolgung für Anwendungen, die keine vorhersehbaren Auslastungsmuster aufweisen.
Verwenden Sie die API-Operationen `RegisterScalableTarget` und `PutScalingPolicy` Application Auto Scaling, um die bereitgestellte Gleichzeitigkeit mithilfe der Zielverfolgung zu skalieren. Wenn Sie beispielsweise die AWS Command Line Interface (CLI) verwenden, gehen Sie wie folgt vor:
1. Registrieren Sie den Alias einer Funktion als Skalierungsziel. Im folgenden Beispiel wird der BLUE-Alias einer Funktion mit dem Namen registriert `my-function`:
```
aws application-autoscaling register-scalable-target --service-namespace lambda \
--resource-id function:my-function:BLUE --min-capacity 1 --max-capacity 100 \
--scalable-dimension lambda:function:ProvisionedConcurrency
```
1. Wenden Sie eine Skalierungsrichtlinie auf das Ziel an. Im folgenden Beispiel wird Application Auto Scaling so konfiguriert, dass die bereitgestellte Gleichzeitigkeitskonfiguration für einen Alias so angepasst wird, dass die Auslastung bei 70 % liegt. Sie können jedoch jeden beliebigen Wert zwischen 10 % und 90 % anwenden.
```
aws application-autoscaling put-scaling-policy \
--service-namespace lambda \
--scalable-dimension lambda:function:ProvisionedConcurrency \
--resource-id function:my-function:BLUE \
--policy-name my-policy \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration '{ "TargetValue": 0.7, "PredefinedMetricSpecification": { "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization" }}'
```
Die Ausgabe sollte in etwa wie folgt aussehen:
```
{
"PolicyARN": "arn:aws:autoscaling:us-east-2:123456789012:scalingPolicy:12266dbb-1524-xmpl-a64e-9a0a34b996fa:resource/lambda/function:my-function:BLUE:policyName/my-policy",
"Alarms": [
{
"AlarmName": "TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7",
"AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7"
},
{
"AlarmName": "TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66",
"AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66"
}
]
}
```
Application Auto Scaling erstellt zwei Alarme in CloudWatch. Der erste Alarm wird ausgelöst, wenn die Auslastung der bereitgestellten Gleichzeitigkeit konstant 70 % überschreitet. In diesem Fall weist Application Auto Scaling mehr bereitgestellte Gleichzeitigkeit zu, um die Auslastung zu reduzieren. Der zweite Alarm wird ausgelöst, wenn die Auslastung konstant unter 63 % (90 % des 70-%-Ziels) liegt. In diesem Fall reduziert Application Auto Scaling wird die bereitgestellte Gleichzeitigkeit des Alias.
**Anmerkung**
Lambda gibt die Metrik `ProvisionedConcurrencyUtilization` nur aus, wenn Ihre Funktion aktiv ist und Anforderungen empfängt. In Zeiten der Inaktivität werden keine Messwerte ausgegeben, und Ihre Auto-Scaling-Alarme wechseln in den Status `INSUFFICIENT_DATA`. Infolgedessen kann die Anwendung von Auto Scaling die von Ihrer Funktion bereitgestellte Gleichzeitigkeit nicht anpassen. Dies kann zu einer unerwarteten Abrechnung führen.
Im folgenden Beispiel skaliert eine Funktion basierend auf der Auslastung zwischen einem minimalen und einem maximalen Umfang bereitgestellter Gleichzeitigkeit.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/features-scaling-provisioned-auto.png)
**Legende**
+ ![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/features-scaling-provisioned.instances.png) Funktions-Instances
+ ![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/features-scaling-provisioned.open.png) Offene Anforderungen
+ ![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/features-scaling-provisioned.provisioned.png) Bereitgestellte Concurrency
+ ![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/features-scaling-provisioned.standard.png) Standard-Gleichzeitigkeit
Wenn die Anzahl der offenen Anforderungen zunimmt, erhöht Application Auto Scaling die bereitgestellte Gleichzeitigkeit in großen Schritten, bis sie das konfigurierte Maximum erreicht. Danach kann die Funktion weiter die standardmäßige, nicht reservierte Gleichzeitigkeit skalieren, falls das Kontogleichzeitigkeitslimit nicht erreicht ist. Wenn die Auslastung sinkt und niedrig bleibt, verringert Application Auto Scaling die bereitgestellte Gleichzeitigkeit in kleineren periodischen Schritten.
Beide Alarme für Application Auto Scaling verwenden standardmäßig die Durchschnittsstatistik. Funktionen, die in kurzen Abständen auftretende Auslastungsmuster aufweisen, lösen diese Alarme möglicherweise nicht aus. Nehmen wir zum Beispiel an, Ihre Lambda-Funktion wird schnell ausgeführt (d. h. 20–100 ms) und der Datenverkehr kommt in kurzen Schüben (Bursts). In diesem Fall übersteigt die Anzahl der Anfragen die zugewiesene, bereitgestellte Gleichzeitigkeit während eines Bursts. Beim Application Auto Scaling muss die Burst-Last jedoch mindestens 3 Minuten lang aufrechterhalten werden, um zusätzliche Umgebungen bereitzustellen. Außerdem benötigen beide CloudWatch-Alarme 3 Datenpunkte, die den Zieldurchschnitt erreichen, damit die Auto-Scaling-Richtlinie aktiviert wird. Wenn bei Ihrer Funktion ein schneller Anstieg des Datenverkehrs auftritt, kann die Verwendung der **Maximum**-Statistik anstelle der **Durchschnitts**statistik effektiver sein, um die bereitgestellte Gleichzeitigkeit zu skalieren und Kaltstarts zu minimieren.
Weitere Informationen zu Zielverfolgungs-Skalierungsrichtlinien finden Sie unter [Zielverfolgungs-Skalierungsrichtlinien für das Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html).
# Lambda-Skalierungsverhalten
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 **Gleichzeitigkeits-Skalierungsrate** ist die maximale Rate, mit der Funktionen in Ihrem Konto als Reaktion auf erhöhte Anforderungen skaliert werden können. (Das heißt, sie gibt an, wie schnell Lambda neue Ausführungsumgebungen erstellen kann.) Die Skalierungsrate für die Gleichzeitigkeit unterscheidet sich von der Gleichzeitigkeitsgrenze auf Kontoebene, die die Gesamtmenge der Gleichzeitigkeit darstellt, die Ihren Funktionen zur Verfügung steht.
## Nebenläufigkeitsskalierungsrate
**In jedem AWS-Region und für jede Funktion beträgt die Skalierungsrate für die Gleichzeitigkeit 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 Funktion in Ihrem Konto unabhängig von anderen Funktionen skaliert werden kann.
**Anmerkung**
In der Praxis versucht Lambda, Ihre Nebenläufigkeitsskalierungsrate kontinuierlich im Laufe der Zeit aufzufüllen, anstatt alle 10 Sekunden eine einzige Nachfüllung von 1 000 Einheiten durchzuführen.
Lambda sammelt keine ungenutzten Teile Ihrer Nebenläufigkeitsskalierungsrate an. Das bedeutet, dass Ihre Skalierungsrate zu jedem Zeitpunkt immer maximal 1 000 Nebenläufigkeitseinheiten beträgt. Wenn Sie beispielsweise in einem 10-Sekunden-Intervall keine der verfügbaren 1 000 Nebenläufigkeitseinheiten verwenden, werden Sie im nächsten 10-Sekunden-Intervall keine 1 000 zusätzlichen Einheiten ansammeln. Ihre Skalierungsrate für Nebenläufigkeit liegt im nächsten 10-Sekunden-Intervall immer noch bei 1 000.
Solange Ihre Funktion weiterhin eine steigende Anzahl von Anfragen erhält, skaliert Lambda mit der schnellsten Rate, die Ihnen zur Verfügung steht, bis zum Nebenläufigkeitslimit Ihres Kontos. Sie können das Volumen der Nebenläufigkeit einschränken, die einzelne Funktionen verwenden können, indem Sie die [reservierte Nebenläufigkeit konfigurieren](configuration-concurrency.md). Wenn Anforderungen schneller eingehen, als Ihre Funktion sie skalieren kann, oder wenn Ihre Funktion die maximale Nebenläufigkeit erreicht hat, schlagen weitere Anforderungen mit einem Drosselungsfehler (Statuscode 429) fehl.
# Überwachen der Gleichzeitigkeit
Lambda gibt CloudWatch Amazon-Metriken aus, um Sie bei der Überwachung der Parallelität Ihrer Funktionen zu unterstützen. In diesem Thema werden diese Metriken und ihre Interpretation erläutert.
**Topics**
+ [
## Allgemeine Metriken für Gleichzeitigkeit
](#general-concurrency-metrics)
+ [
## Metriken für Provisioned Concurrency
](#provisioned-concurrency-metrics)
+ [
## Die Metrik `ClaimedAccountConcurrency`
](#claimed-account-concurrency)
## Allgemeine Metriken für Gleichzeitigkeit
Verwenden Sie die folgenden Metriken, um die Gleichzeitigkeit Ihrer Lambda-Funktionen zu überwachen. Die Granularität für jede Metrik ist 1 Minute.
+ `ConcurrentExecutions` – Die Anzahl der aktiven gleichzeitigen Aufrufe zu einem bestimmten Zeitpunkt. Lambda gibt diese Metrik für alle Funktionen, Versionen und Aliasse aus. Für jede Funktion in der Lambda-Konsole zeigt Lambda das Diagramm für `ConcurrentExecutions` nativ auf der Registerkarte **Überwachung** unter **Metriken** an. Sehen Sie sich diese Metrik mit **MAX** an.
+ `UnreservedConcurrentExecutions` – Die Anzahl der aktiven gleichzeitigen Aufrufe, die nicht reservierte Gleichzeitigkeit verwenden. Lambda gibt diese Metriken for alle Funktionen in einer Region aus. Sehen Sie sich diese Metrik mit **MAX** an.
+ `ClaimedAccountConcurrency` – Die Menge an Gleichzeitigkeit, die für On-Demand-Aufrufe nicht verfügbar ist. `ClaimedAccountConcurrency` entspricht `UnreservedConcurrentExecutions` plus dem Betrag der zugewiesenen Gleichzeitigkeit (d. h. der gesamten reservierten Gleichzeitigkeit plus der gesamten bereitgestellten Gleichzeitigkeit). Wenn das Kontogleichzeitigkeitslimit für `ClaimedAccountConcurrency` überschritten wird, können Sie [ein höheres Kontogleichzeitigkeitslimit beantragen](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/). Sehen Sie sich diese Metrik mit **MAX** an. Weitere Informationen finden Sie unter [Die Metrik `ClaimedAccountConcurrency`](#claimed-account-concurrency).
## Metriken für Provisioned Concurrency
Verwenden Sie die folgenden Metriken, um Lambda-Funktionen mit bereitgestellter Gleichzeitigkeit zu überwachen. Die Granularität für jede Metrik ist 1 Minute.
+ `ProvisionedConcurrentExecutions` – Die Anzahl der Instances der Ausführungsumgebung, die einen Aufruf bei bereitgestellter Gleichzeitigkeit aktiv verarbeiten. Lambda gibt diese Metrik für jede Funktionsversion und jeden Alias aus, wobei die bereitgestellte Gleichzeitigkeit konfiguriert ist. Sehen Sie sich diese Metrik mit **MAX** an.
`ProvisionedConcurrentExecutions` entspricht nicht der Gesamtzahl der bereitgestellten Gleichzeitigkeit, die Sie zuweisen. Nehmen wir zum Beispiel an, Sie weisen einer Funktionsversion 100 Einheiten der bereitgestellten Gleichzeitigkeit zu. Wenn in einer bestimmten Minute höchstens 50 dieser 100 Ausführungsumgebungen gleichzeitig Aufrufe verarbeiten, dann ist der Wert von **MAX**(`ProvisionedConcurrentExecutions`) 50.
+ `ProvisionedConcurrencyInvocations` – Die Häufigkeit, mit der Lambda Ihren Funktionscode mit bereitgestellter Gleichzeitigkeit aufruft. Lambda gibt diese Metrik für jede Funktionsversion und jeden Alias aus, wobei die bereitgestellte Gleichzeitigkeit konfiguriert ist. Sehen Sie sich diese Metrik mit **SUM** an.
`ProvisionedConcurrencyInvocations` unterscheidet sich von `ProvisionedConcurrentExecutions` dadurch, dass `ProvisionedConcurrencyInvocations` die Gesamtzahl der Aufrufe zählt, während `ProvisionedConcurrentExecutions` die Anzahl der aktiven Umgebungen zählt. Um diesen Unterschied zu verstehen, betrachten Sie das folgende Szenario:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/concurrency-metrics-pc-executions-vs-invocations.png)
In diesem Beispiel nehmen wir an, dass Sie 1 Aufruf pro Minute erhalten und jeder Aufruf 2 Minuten dauert. Jeder orangefarbene horizontale Balken steht für eine einzelne Anfrage. Nehmen wir an, dass Sie dieser Funktion 10 Einheiten der bereitgestellten Gleichzeitigkeit zuweisen, sodass jede Anforderung mit bereitgestellter Gleichzeitigkeit ausgeführt wird.
Zwischen den Minuten 0 und 1 trifft `Request 1` ein. **Bei Minute 1** ist der Wert für **MAX**(`ProvisionedConcurrentExecutions`) 1, da in der vergangenen Minute höchstens 1 Ausführungsumgebung aktiv war. Der Wert für **SUM**(`ProvisionedConcurrencyInvocations`) ist ebenfalls 1, da in der letzten Minute 1 neue Anforderung eingegangen ist.
Zwischen den Minuten 1 und 2 trifft `Request 2` ein, während `Request 1` weiterläuft. **Bei Minute 2** ist der Wert für **MAX**(`ProvisionedConcurrentExecutions`) 2, da in der letzten Minute höchstens 2 Ausführungsumgebungen aktiv waren. Der Wert für **SUM**(`ProvisionedConcurrencyInvocations`) ist jedoch 1, da in der letzten Minute nur 1 neue Anforderung eingegangen ist. Dieses Verhalten der Metrik setzt sich bis zum Ende des Beispiels fort.
+ `ProvisionedConcurrencySpilloverInvocations` – Die Häufigkeit, mit der Lambda Ihre Funktion bei standardmäßiger (reservierter oder nicht reservierter) Gleichzeitigkeit aufruft, wenn die gesamte bereitgestellte Gleichzeitigkeit verwendet wird. Lambda gibt diese Metrik für jede Funktionsversion und jeden Alias aus, wobei die bereitgestellte Gleichzeitigkeit konfiguriert ist. Sehen Sie sich diese Metrik mit **SUM** an. Der Wert von `ProvisionedConcurrencyInvocations` \$1 `ProvisionedConcurrencySpilloverInvocations` sollte der Gesamtzahl der Funktionsaufrufe (d. h. der `Invocations`-Metrik) entsprechen.
`ProvisionedConcurrencyUtilization` – Der prozentuale Anteil der bereitgestellten Gleichzeitigkeit, der genutzt wird (d. h. der Wert von `ProvisionedConcurrentExecutions` geteilt durch die Gesamtmenge der bereitgestellten Gleichzeitigkeit). Lambda gibt diese Metrik für jede Funktionsversion und jeden Alias aus, wobei die bereitgestellte Gleichzeitigkeit konfiguriert ist. Sehen Sie sich diese Metrik mit **MAX** an.
Nehmen wir zum Beispiel an, Sie teilen einer Funktionsversion 100 Einheiten der bereitgestellten Gleichzeitigkeit zu. Wenn in einer bestimmten Minute höchstens 60 dieser 100 Ausführungsumgebungen gleichzeitig Aufrufe verarbeiten, dann ist der Wert von **MAX**(`ProvisionedConcurrentExecutions`) 60 und der Wert von **MAX**(`ProvisionedConcurrencyUtilization`) ist 0,6.
Ein hoher Wert für `ProvisionedConcurrencySpilloverInvocations` kann darauf hinweisen, dass Sie zusätzliche bereitgestellte Gleichzeitigkeit für Ihre Funktion zuteilen müssen. Alternativ können Sie [Application Auto Scaling konfigurieren, um die automatische Skalierung der bereitgestellten Gleichzeitigkeit](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html#managing-provisioned-concurency) auf der Grundlage von vordefinierten Schwellenwerten zu steuern.
Umgekehrt können konstant niedrige Werte für `ProvisionedConcurrencyUtilization` darauf hindeuten, dass Sie Ihrer Funktion zu viel bereitgestellte Gleichzeitigkeit zugeteilt haben.
## Die Metrik `ClaimedAccountConcurrency`
Lambda verwendet die Metrik `ClaimedAccountConcurrency`, um zu ermitteln, wie viel Gleichzeitigkeit in Ihrem Konto für On-Demand-Aufrufe verfügbar ist. Lambda berechnet `ClaimedAccountConcurrency` mit der folgenden Formel:
```
ClaimedAccountConcurrency = UnreservedConcurrentExecutions + (allocated concurrency)
```
`UnreservedConcurrentExecutions` ist die Anzahl der aktiven gleichzeitigen Aufrufe, die nicht reservierte Gleichzeitigkeit verwenden. Die zugewiesene Gleichzeitigkeit ist die Summe der folgenden beiden Teile (wobei `RC` für „reservierte Gleichzeitigkeit“ und `PC` für „bereitgestellte Gleichzeitigkeit“ steht):
+ Die gesamte `RC` aller Funktionen in einer Region.
+ Die gesamte `PC` aller Funktionen in einer Region, die `PC` verwenden, ohne Funktionen, die `RC` verwenden.
**Anmerkung**
Sie können einer Funktion nicht mehr `PC` als `RC` zuweisen. Somit ist die `RC` einer Funktion immer größer oder gleich der `PC`. Um den Beitrag zur zugewiesenen Gleichzeitigkeit für solche Funktionen mit `PC` und `RC` zu berechnen, berücksichtigt Lambda nur `RC`, welches das Maximum der beiden ist.
Lambda verwendet die Metrik `ClaimedAccountConcurrency` anstelle von `ConcurrentExecutions`, um zu ermitteln, wie viel Gleichzeitigkeit für On-Demand-Aufrufe verfügbar ist. Die Metrik `ConcurrentExecutions` ist zwar nützlich, um die Anzahl der aktiven gleichzeitigen Aufrufe nachzuverfolgen, spiegelt jedoch nicht immer die tatsächliche Verfügbarkeit von Gleichzeitigkeit wider. Das liegt daran, dass Lambda bei der Bestimmung der Verfügbarkeit auch die reservierte und die bereitgestellte Gleichzeitigkeit berücksichtigt.
Stellen Sie sich zur Veranschaulichung von `ClaimedAccountConcurrency` ein Szenario vor, in dem Sie sehr viel reservierte und bereitgestellte Gleichzeitigkeit für Ihre Funktionen konfigurieren, die weitgehend ungenutzt bleiben. Gehen Sie im folgenden Beispiel nun davon aus, dass Ihr Kontogleichzeitigkeitslimit 1 000 beträgt und dass Ihr Konto über zwei Hauptfunktionen verfügt: `function-orange` und `function-blue`. Sie weisen `function-orange` 600 reservierte Gleichzeitigkeitseinheiten zu. Sie weisen `function-blue` 200 bereitgestellte Gleichzeitigkeitseinheiten zu. Nehmen wir an, dass Sie im Laufe der Zeit zusätzliche Funktionen bereitstellen und das folgende Datenverkehrsmuster beobachten:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/claimed-account-concurrency.png)
Im vorherigen Diagramm stehen die schwarzen Linien für die tatsächliche Nutzung der Gleichzeitigkeit im Zeitverlauf, und die rote Linie für den Wert `ClaimedAccountConcurrency` im Zeitverlauf. In diesem Szenario beträgt der Wert von `ClaimedAccountConcurrency` mindestens 800, obwohl die tatsächliche Gleichzeitigkeitsauslastung aller Funktionen gering ist. Das liegt daran, dass Sie insgesamt 800 Gleichzeitigkeitseinheiten für `function-orange` und `function-blue` zugewiesen haben. Aus Sicht von Lambda haben Sie diese Gleichzeitigkeit zur Nutzung „beansprucht“, sodass Ihnen praktisch nur noch 200 Gleichzeitigkeitseinheiten für andere Funktionen zur Verfügung stehen.
Für dieses Szenario beträgt die zugewiesene Gleichzeitigkeit in der `ClaimedAccountConcurrency`-Formel 800. Daraus können wir den Wert von `ClaimedAccountConcurrency` an verschiedenen Stellen im Diagramm ableiten:
+ Bei `t1`, `ClaimedAccountConcurrency` ist der Wert 800 (800 \$1 0 `UnreservedConcurrentExecutions`).
+ Bei `t2`, `ClaimedAccountConcurrency` ist der Wert 900 (800 \$1 100 `UnreservedConcurrentExecutions`).
+ Bei `t3`, `ClaimedAccountConcurrency` ist der Wert wieder 900 (800 \$1 100 `UnreservedConcurrentExecutions`).
### Einrichtung der `ClaimedAccountConcurrency` Metrik in CloudWatch
Lambda gibt die `ClaimedAccountConcurrency` Metrik in aus. CloudWatch Verwenden Sie diese Metrik zusammen mit dem Wert von `SERVICE_QUOTA(ConcurrentExecutions)`, um die prozentuale Nutzung der Gleichzeitigkeit in Ihrem Konto zu ermitteln, wie in der folgenden Formel dargestellt:
```
Utilization = (ClaimedAccountConcurrency/SERVICE_QUOTA(ConcurrentExecutions)) * 100%
```
Der folgende Screenshot zeigt, wie Sie diese Formel grafisch darstellen können. CloudWatch Die grüne `claim_utilization`-Linie steht für die Gleichzeitigkeitsauslastung in diesem Konto, die bei etwa 40 % liegt:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/claimed-account-concurrency-cloudwatch-graph.png)
Der vorherige Screenshot enthält auch einen CloudWatch Alarm, der in den `ALARM` Status wechselt, wenn die Parallelitätsauslastung 70% übersteigt. Sie können die `ClaimedAccountConcurrency`-Metrik zusammen mit ähnlichen Alarmen verwenden, um proaktiv zu bestimmen, wann Sie möglicherweise ein höheres Kontengleichzeitigkeitslimit beantragen müssen.