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.

Konfiguration der bereitgestellten Parallelität für eine Event-Funktion

In Lambda ist Parallelität die Anzahl der In-Flight-Anfragen, die Ihre Event-Funktion derzeit bearbeitet. Es gibt zwei Arten von Gleichzeitigkeitskontrollen:

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. Weitere Informationen zur Konfiguration der reservierten Gleichzeitigkeit finden Sie unter Konfiguration reservierter Parallelität für eine Event-Funktion.

Konfigurieren von Provisioned Concurrency

Sie können bereitgestellte Parallelitätseinstellungen für eine Lambda-Ereignisfunktion mithilfe der Lambda-Konsole oder der Lambda-API konfigurieren.

Sie können in Ihrem Konto Gleichzeitigkeit bis zur nicht reservierten Konto-Gleichzeitigkeit minus 100 konfigurieren. Die verbleibenden 100 Parallelitätseinheiten sind für Event-Funktionen vorgesehen, die keine reservierte Parallelität verwenden. Wenn Ihr Konto beispielsweise ein Parallelitätslimit von 1.000 hat und Sie keiner Ihrer anderen Event-Funktionen eine reservierte oder bereitgestellte Parallelität zugewiesen haben, können Sie maximal 900 bereitgestellte Parallelitätseinheiten für eine einzelne Event-Funktion konfigurieren.

Die Konfiguration der bereitgestellten Parallelität für eine Event-Funktion hat Auswirkungen auf den Parallelitätspool, der anderen Eventfunktionen zur Verfügung steht. Wenn Sie beispielsweise 100 bereitgestellte Parallelitätseinheiten für konfigurierenfunction-a, müssen sich andere Eventfunktionen in Ihrem Konto die verbleibenden 900 Parallelitätseinheiten teilen. Das gilt auch, wenn function-a nicht alle 100 Einheiten verwendet.

Es ist möglich, derselben Event-Funktion sowohl reservierte Parallelität als auch bereitgestellte Parallelität zuzuweisen. In solchen Fällen darf die bereitgestellte Gleichzeitigkeit die reservierte Gleichzeitigkeit nicht überschreiten.

Diese Einschränkung gilt auch für Versionen von Event Function. Die maximale bereitgestellte Parallelität, die Sie einer bestimmten Version der Ereignisfunktion zuweisen können, ist die reservierte Parallelität der Ereignisfunktion abzüglich der bereitgestellten Parallelität in anderen Versionen der Ereignisfunktion.

Verwenden Sie für die Konfiguration der bereitgestellten Gleichzeitigkeit mithilfe der Lambda-API die folgenden API-Operationen:

Verwenden Sie beispielsweise den Befehl, um die bereitgestellte Parallelität mit der AWS Command Line Interface (CLI) zu konfigurieren. put-provisioned-concurrency-config Der folgende Befehl weist 100 Einheiten bereitgestellter Parallelität für den BLUE Alias einer Ereignisfunktion mit dem Namen zu: my-function

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 Parallelität für eine Event-Funktion

Sie können die Parallelitätsmetriken jeder aktiven Event-Funktion mithilfe von Metriken anzeigen. CloudWatch Insbesondere zeigt Ihnen die ConcurrentExecutions Metrik die Anzahl der gleichzeitigen Aufrufe von Event Functions in Ihrem Konto.

Aus dem vorherigen Diagramm geht hervor, dass diese Ereignisfunktion durchschnittlich 5 bis 10 gleichzeitige Anfragen zu einem bestimmten Zeitpunkt bearbeitet und bei 20 Anfragen ihren Höhepunkt erreicht. Nehmen wir an, Ihr Konto enthält noch viele andere Event-Funktionen. Wenn diese Ereignisfunktion für Ihre Anwendung von entscheidender Bedeutung ist und Sie bei jedem Aufruf eine Antwort mit niedriger Latenz benötigen, konfigurieren Sie mindestens 20 bereitgestellte Parallelitätseinheiten.

Denken Sie daran, dass Sie die Gleichzeitigkeit auch mit der folgenden Formel berechnen können:

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.

Bei der Konfiguration der bereitgestellten Parallelität schlägt Lambda vor, zusätzlich zu der Menge an Parallelität, die Ihre Event-Funktion normalerweise benötigt, einen Puffer von 10% hinzuzufügen. Wenn Ihre Event-Funktion beispielsweise normalerweise bei 200 gleichzeitigen Anfragen ihren Höhepunkt erreicht, legen Sie die bereitgestellte Parallelität auf 220 fest (200 gleichzeitige Anfragen + 10% = 220 bereitgestellte Parallelität).

Optimieren Sie den Code der Event-Funktion bei Verwendung der bereitgestellten Parallelität

Wenn Sie bereitgestellte Parallelität verwenden, sollten Sie erwägen, Ihren Event-Funktionscode umzustrukturieren, um ihn für eine geringe Latenz zu optimieren. Für Eventfunktionen, die bereitgestellte Parallelität verwenden, führt Lambda während der Zuweisungszeit jeden Initialisierungscode aus, z. B. das Laden von Bibliotheken und das Instanziieren von Clients. Daher ist es ratsam, möglichst viele Initialisierungen außerhalb des Haupthandlers für Ereignisfunktionen zu verschieben, um zu vermeiden, dass die Latenz bei tatsächlichen Aufrufen der Ereignisfunktion beeinträchtigt wird. Im Gegensatz dazu bedeutet das Initialisieren von Bibliotheken oder das Instanziieren von Clients innerhalb Ihres Haupthandlercodes, dass Ihre Event-Funktion dies bei jedem Aufruf ausführen muss (dies geschieht unabhängig davon, ob Sie die bereitgestellte Parallelität verwenden).

Bei Aufrufen auf Abruf muss Lambda Ihren Initialisierungscode möglicherweise jedes Mal erneut ausführen, wenn Ihre Event-Funktion einen Kaltstart erlebt. Für solche Event-Funktionen können Sie sich dafür entscheiden, die Initialisierung einer bestimmten Funktion so lange zu verschieben, bis Ihre Event-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, wenn Lambda skaliert, indem Sie Ihre Event-Funktion um eine X-Ray Überwachung erweitern. Eine Ereignisfunktion, die bereitgestellte Parallelität verwendet, zeigt kein Kaltstartverhalten, da die Ausführungsumgebung vor dem Aufruf vorbereitet wird. Die bereitgestellte Parallelität muss jedoch auf eine bestimmte Version oder einen bestimmten Alias einer Event-Funktion angewendet werden, nicht auf die $LATEST-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 Event-Funktion die gesamte bereitgestellte Parallelität 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. Informationen zum Überprüfen des Werts einer Umgebungsvariablen in Ihrem Event-Funktionscode finden Sie unter. Abrufen von Lambda-Umgebungsvariablen

Wenn Sie die .NET 8-Laufzeit verwenden, können Sie die AWS_LAMBDA_DOTNET_PREJIT Umgebungsvariable konfigurieren, um die Latenz für Ereignisfunktionen zu verbessern, auch wenn sie keine bereitgestellte Parallelität 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-Ereignisfunktion länger dauern als nachfolgende. Um dies zu verhindern, können Sie einen von drei Werten für AWS_LAMBDA_DOTNET_PREJIT wählen:

Verstehen des Protokollierungs- und Abrechnungsverhaltens bei bereitgestellter Gleichzeitigkeit

Bei bereitgestellten Parallelitätsumgebungen wird der Initialisierungscode Ihrer Event Function während der Zuweisung und in regelmäßigen Abständen ausgeführt, wenn Lambda Instanzen 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.

Wenn Sie eine Lambda-Ereignisfunktion mit bereitgestellter Parallelität konfigurieren, initialisiert Lambda diese Ausführungsumgebung vor, sodass sie vor Aufrufanforderungen verfügbar ist. Lambda protokolliert bei jeder Initialisierung der Umgebung das Feld Init Duration der Event Function in einem Platform-InitReport-Protokollereignis im JSON-Protokollierungsformat. Um dieses Protokollereignis zu sehen, konfigurieren Sie Ihre JSON-Protokollebene auf mindestens INFO. Sie können die Telemetrie-API 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 Ihre Event-Funktion vorhersehbare Verkehrsmuster empfängt, verwenden Sie die geplante Skalierung. Wenn Sie möchten, dass Ihre Event-Funktion einen bestimmten Nutzungsgrad beibehält, verwenden Sie eine Skalierungsrichtlinie für die Zielverfolgung.

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 im Application Auto Scaling Scaling-Benutzerhandbuch und Scheduling AWS Lambda Provisioned Concurrency für wiederkehrende Spitzennutzung im AWS Compute-Blog.

Zielverfolgung

Mit der Zielverfolgung erstellt und verwaltet Application Auto Scaling eine Reihe von CloudWatch Alarmen, die darauf basieren, wie Sie Ihre Skalierungsrichtlinie definieren. 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:

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.

Im folgenden Beispiel skaliert eine Event-Funktion je nach Auslastung zwischen einer Mindest- und Höchstmenge an bereitgestellter Parallelität.

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 Event Function weiterhin mit der standardmäßigen, vorbehaltlosen Parallelität skaliert werden, falls Sie das Limit für die Parallelität Ihres Kontos noch nicht erreicht haben. 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, bei denen es zu schnellen Verkehrsspitzen kommt, lösen diese Alarme möglicherweise nicht aus. Nehmen wir zum Beispiel an, dass Ihre Lambda-Ereignisfunktion schnell (d. h. 20-100 ms) ausgeführt wird und Ihr Datenverkehr in schnellen Ausbrüchen erfolgt. In diesem Fall übersteigt die Anzahl der Anfragen die zugewiesene, bereitgestellte Gleichzeitigkeit während eines Bursts.

Bei Application Auto Scaling muss die Burst-Load jedoch mindestens 3 Minuten lang aufrechterhalten werden, um zusätzliche Umgebungen bereitzustellen. Darüber hinaus benötigen beide CloudWatch Alarme 3 Datenpunkte, die den Zieldurchschnitt erreichen, um die Auto Scaling-Richtlinie zu aktivieren. Wenn Ihre Event-Funktion schnell stark ausgelastet ist, kann die Verwendung der Maximum-Statistik anstelle der Durchschnittsstatistik effektiver sein, um die bereitgestellte Parallelität zu skalieren und so Kaltstarts zu minimieren.

Weitere Informationen zu Zielverfolgungs-Skalierungsrichtlinien finden Sie unter Zielverfolgungs-Skalierungsrichtlinien für das Application Auto Scaling.