Lambda-Ereignisquellenzuweisung - AWS Lambda

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Lambda-Ereignisquellenzuweisung

Anmerkung

Wenn Sie Daten an ein anderes Ziel als eine Lambda-Funktion senden oder die Daten vor dem Senden anreichern möchten, finden Sie weitere Informationen unter Amazon EventBridge Pipes.

Eine Ereignisquellenzuordnung ist eine Lambda-Ressource, die aus einer Ereignisquelle liest und eine Lambda-Funktion aufruft. Sie können Ereignisquellen-Zuweisungen zum Verarbeiten von Elementen aus einem Stream oder einer Warteschlange in Services verwenden, die keine Lambda-Funktionen direkt aufrufen. Auf dieser Seite werden die Services beschrieben, die Lambda für Zuordnungen von Ereignisquellen bereitstellt, und die Feinabstimmung des Batching-Verhaltens.

Eine Ereignisquellen-Zuweisung verwendet die Berechtigungen in der Ausführungsrolle der Funktion zum Lesen und Verwalten von Elementen in der Ereignisquelle. Berechtigungen, Ereignisstruktur, Einstellungen und Abrufverhalten variieren je nach Ereignisquelle. Weitere Informationen finden Sie in dem verküpften Thema für den Service, den Sie als Ereignisquelle verwenden.

Um eine Ereignisquelle mit der AWS Command Line Interface (AWS CLI) oder einem AWS-SDK zu verwalten, können Sie die folgenden API-Operationen verwenden:

Warnung

Lambda-Ereignisquellenzuordnungen verarbeiten jedes Ereignis mindestens einmal, und es kann zu einer doppelten Verarbeitung von Datensätzen kommen. Um mögliche Probleme im Zusammenhang mit doppelten Ereignissen zu vermeiden, empfehlen wir Ihnen dringend, Ihren Funktionscode idempotent zu machen. Weitere Informationen finden Sie im Knowledge Center unter Wie mache ich meine Lambda-Funktion idempotent?. AWS

Erstellen einer Ereignisquellenzuordnung

Um eine Zuordnung zwischen einer Ereignisquelle und einer Lambda-Funktion zu erstellen, erstellen Sie einen Trigger in der Konsole oder verwenden Sie den create-event-source-mappingBefehl.

Um Berechtigungen hinzuzufügen und einen Trigger zu erstellen
  1. Fügen Sie Ihrer Ausführungsrolle die erforderlichen Berechtigungen hinzu. Einige Dienste, wie Amazon SQS, verfügen über eine AWS verwaltete Richtlinie, die die Berechtigungen beinhaltet, die Lambda benötigt, um aus Ihrer Ereignisquelle zu lesen.

  2. Öffnen Sie die Seite Funktionen der Lambda-Konsole.

  3. Wählen Sie den Namen einer Funktion aus.

  4. Wählen Sie unter Function overview (Funktionsübersicht) die Option Add trigger (Trigger hinzufügen).

    Abschnitt „Funktionsübersicht“ der Lambda-Konsole
  5. Wählen Sie einen Auslösertyp aus.

  6. Konfigurieren Sie die erforderlichen Optionen und wählen Sie dann Add (Hinzufügen) aus.

Um eine Ereignisquellenzuordnung zu erstellen ()AWS CLI

Das folgende Beispiel verwendet die AWS CLI , um eine Funktion mit dem Namen einem DynamoDB-Stream my-function zuzuordnen, den ihr Amazon-Ressourcenname (ARN) spezifiziert, mit einer Batchgröße von 500.

aws lambda create-event-source-mapping --function-name my-function --batch-size 500 --maximum-batching-window-in-seconds 5 --starting-position LATEST \ --event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2023-06-10T19:26:16.525

Die Ausgabe sollte folgendermaßen aussehen:

{ "UUID": "14e0db71-5d35-4eb5-b481-8945cf9d10c2", "BatchSize": 500, "MaximumBatchingWindowInSeconds": 5, "ParallelizationFactor": 1, "EventSourceArn": "arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2019-06-10T19:26:16.525", "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "LastModified": 1560209851.963, "LastProcessingResult": "No records processed", "State": "Creating", "StateTransitionReason": "User action", "DestinationConfig": {}, "MaximumRecordAgeInSeconds": 604800, "BisectBatchOnFunctionError": false, "MaximumRetryAttempts": 10000 }

Die Zuordnung einer Ereignisquelle wird aktualisiert

Um eine Ereignisquellenzuordnung zu aktualisieren (Konsole)
  1. Öffnen Sie die Seite Funktionen der Lambda-Konsole.

  2. Wählen Sie eine Funktion aus.

  3. Wählen Sie Konfiguration und dann Trigger.

  4. Wählen Sie den Trigger aus und wählen Sie dann Bearbeiten.

Um eine Ereignisquellenzuordnung zu aktualisieren (AWS CLI)

Verwenden Sie den update-event-source-mapping-Befehl. Im folgenden Beispiel wird die maximale Parallelität für eine Amazon SQS SQS-Ereignisquelle konfiguriert.

aws lambda update-event-source-mapping \ --uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \ --scaling-config '{"MaximumConcurrency":5}'

Löschen einer Ereignisquellenzuordnung

Wenn Sie eine Funktion löschen, löscht Lambda die zugehörigen Ereignisquellenzuordnungen nicht. Sie können Zuordnungen von Ereignisquellen in der Konsole oder mithilfe der API-Aktion löschen. DeleteEventSourceMapping

Um Zuordnungen von Ereignisquellen zu löschen (Konsole)
  1. Öffnen Sie die Seite mit den Zuordnungen von Ereignisquellen in der Lambda-Konsole.

  2. Wählen Sie die Zuordnungen der Ereignisquellen aus, die Sie löschen möchten.

  3. Geben Sie im Dialogfeld Ereignisquellenzuordnungen löschen den Text Löschen ein, und wählen Sie dann Löschen aus.

Um eine Ereignisquellenzuordnung zu löschen ()AWS CLI

Verwenden Sie den delete-event-source-mapping-Befehl.

aws lambda delete-event-source-mapping \ --uuid a1b2c3d4-5678-90ab-cdef-11111EXAMPLE

Batching-Verhalten

Ereignisquellenzuordnungen lesen Elemente aus einer Zielereignisquelle. Standardmäßig batcht eine Ereignisquellenzuordnung Datensätze in einer einzigen Nutzlast, die Lambda an Ihre Funktion sendet. Um das Batching-Verhalten zu optimieren, können Sie ein Batching-Fenster (MaximumBatchingWindowInSeconds) und eine Batch-Größe (BatchSize) konfigurieren. Ein Batch-Fenster ist die maximale Zeitspanne zur Erfassung von Datensätzen in einer einzigen Nutzlast. Eine Batch-Größe ist die maximale Anzahl von Datensätzen in einem einzigen Batch. Lambda ruft Ihre Funktion auf, wenn eines der folgenden drei Kriterien erfüllt ist:

  • Das Batching-Fenster erreicht seinen Maximalwert. Das Standardverhalten des Batching-Fensters hängt von der jeweiligen Ereignisquelle ab.

    • Für Kinesis-, DynamoDB- und Amazon SQS SQS-Ereignisquellen: Das Standard-Batch-Fenster beträgt 0 Sekunden. Das bedeutet, dass Lambda Batches nur dann an Ihre Funktion sendet, wenn entweder die Batchgröße erreicht oder die Nutzlastgrößenbeschränkung erreicht ist. Um ein Batching-Fenster festzulegen, konfigurieren Sie. MaximumBatchingWindowInSeconds Sie können diesen Parameter auf einen beliebigen Wert zwischen 0 und 300 Sekunden in Schritten von 1 Sekunde festlegen. Wenn Sie ein Batching-Fenster konfigurieren, beginnt das nächste Fenster, sobald der vorherige Funktionsaufruf abgeschlossen ist.

    • Für Amazon-MSK-, selbstverwaltete Apache-Kafka-, Amazon-MQ- und Amazon-DocumentDB-Ereignisquellen: Das standardmäßige Batching-Fenster beträgt 500 ms. Sie können MaximumBatchingWindowInSeconds auf einen beliebigen Wert von 0 Sekunden bis 300 Sekunden in Sekundenschritten einstellen. Ein Batch-Fenster beginnt, sobald der erste Datensatz eintrifft.

      Anmerkung

      Da Sie MaximumBatchingWindowInSeconds nur in Sekundenschritten ändern können, können Sie nicht zu dem Standard-Batch-Fenster von 500 ms zurückkehren, nachdem Sie es geändert haben. Um das Standard-Batch-Fenster wiederherzustellen, müssen Sie eine neue Ereignisquellenzuordnung erstellen.

  • Die Batch-Größe wird erreicht. Die minimale Batch-Größe beträgt 1. Die Standard- und die maximale Batch-Größe hängen von der Ereignisquelle ab. Weitere Informationen zu diesen Werten finden Sie unter BatchSize-Spezifikation für die CreateEventSourceMapping-API-Operation.

  • Die Nutzlastgröße erreicht 6 MB. Sie können dieses Limit nicht ändern.

Das folgende Diagramm verdeutlicht diese Bedingungen. Angenommen, ein Batch-Fenster beginnt bei t = 7 Sekunden. Im ersten Szenario erreicht das Batch-Fenster sein Maximum von 40 Sekunden bei t = 47 Sekunden nach dem Erfassen von 5 Datensätzen. Im zweiten Szenario erreicht die Batch-Größe 10, bevor das Batch-Fenster abläuft, sodass das Batch-Fenster früh endet. Im dritten Szenario wird die maximale Nutzlastgröße erreicht, bevor das Batch-Fenster abläuft, sodass das Batch-Fenster frühzeitig endet.

Ein Batch-Fenster läuft ab, wenn eines der folgenden drei Kriterien erfüllt ist: Das Batch-Fenster erreicht seinen Maximalwert, die Batch-Größe wird erreicht oder die Nutzlastgröße erreicht 6 MB.

Das folgende Beispiel zeigt eine Ereignisquellen-Zuweisung, die aus einem Kinesis-Stream liest. Wenn bei einem Batch von Ereignissen alle Verarbeitungsversuche fehlschlagen, sendet die Ereignisquellen-Zuweisung-Details über den Batch an eine SQS-Warteschlange.

Eine Ereignisquellen-Zuweisung liest aus einem Kinesis-Stream. Sie stellt Datensätze lokal in die Warteschlange, bevor sie an die Funktion gesendet werden.

Der Ereignisbatch ist das Ereignis, das Lambda an die Funktion sendet. Es handelt sich um einen Batch von Datensätzen oder Nachrichten, die aus den Elementen kompiliert werden, die von der Ereignisquellenzuordnung bis zum Ablauf des aktuellen Batch-Fensters gelesen werden.

Bei Kinesis- und DynamoDB-Streams erstellt eine Zuordnung von Ereignisquellen einen Iterator für jeden Shard im Stream und verarbeitet die Elemente in jedem Shard der Reihe nach. Sie können die Ereignisquellen-Zuweisung so konfigurieren, dass sie nur die neuen Elemente liest, die im Stream erscheinen, oder dass sie bei älteren Elementen beginnt. Verarbeitete Elemente werden nicht aus dem Stream entfernt und können von anderen Funktionen oder Konsumenten verarbeitet werden.

Lambda wartet mit dem Senden des nächsten zu verarbeitenden Stapels nicht, bis ggf. konfigurierte Lambda-Erweiterungen abgeschlossen sind. Anders ausgedrückt: Ihre Erweiterungen werden möglicherweise weiter ausgeführt, während Lambda den nächsten Stapel von Datensätzen verarbeitet. Dies kann zu Drosselungsproblemen führen, wenn Sie gegen eine Einstellung oder gegen einen Grenzwert im Zusammenhang mit der Parallelität Ihres Kontos verstoßen. Um zu erkennen, ob möglicherweise ein Problem vorliegt, müssen Sie Ihre Funktionen überwachen sowie überprüfen, ob für Ihre Zuordnung von Ereignisquellen unerwartet hohe Parallelitätsmetriken vorliegen. Aufgrund der kurzen Zeit zwischen den Aufrufen kann Lambda kurzzeitig eine höhere Gleichzeitigkeitsnutzung als die Anzahl der Shards melden. Dies kann sogar für Lambda-Funktionen ohne Erweiterungen gelten.

Wenn Ihre Funktion einen Fehler zurückgibt, verarbeitet die Ereignisquellenzuordnung standardmäßig das gesamte Batch erneut, bis die Funktion erfolgreich ist oder die Elemente im Batch ablaufen. Um eine ordnungsgemäße Verarbeitung zu gewährleisten, unterbricht die Ereignisquellenzuordnung die Verarbeitung für den betroffenen Shard, bis der Fehler behoben ist. Sie können die Zuordnung von Ereignisquellen so konfigurieren, dass alte Ereignisse verworfen oder mehrere Stapel parallel verarbeitet werden. Wenn Sie mehrere Batches parallel verarbeiten, ist die ordnungsgemäße Verarbeitung für jeden Partitionsschlüssel immer noch gewährleistet, aber die Ereignisquellenzuordnung verarbeitet gleichzeitig mehrere Partitionsschlüssel im selben Shard.

Für Stream-Quellen (DynamoDB und Kinesis) können Sie die maximale Anzahl von Wiederholungsversuchen von Lambda konfigurieren, wenn Ihre Funktion einen Fehler zurückgibt. Service-Fehler oder Drosselungen, bei denen der Stapel Ihre Funktion nicht erreicht, zählen nicht zu den Wiederholungsversuchen.

Sie können die Ereignisquellen-Zuweisung auch so konfigurieren, dass ein Aufrufdatensatz an einen anderen Service gesendet wird, wenn ein Ereignisbatch verworfen wird. Lambda unterstützt die folgenden Ziele für Ereignisquellen-Zuweisungen.

  • Amazon SQS – Eine SQS-Warteschlange.

  • Amazon SNS – Ein SNS-Thema.

Der Aufrufdatensatz enthält Details zum fehlgeschlagenen Ereignisbatch im JSON-Format.

Das folgende Beispiel zeigt einen Aufrufdatensatz für einen Kinesis-Stream.

Beispiel Aufrufdatensatzglauben
{ "requestContext": { "requestId": "c9b8fa9f-5a7f-xmpl-af9c-0c604cde93a5", "functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction", "condition": "RetryAttemptsExhausted", "approximateInvokeCount": 1 }, "responseContext": { "statusCode": 200, "executedVersion": "$LATEST", "functionError": "Unhandled" }, "version": "1.0", "timestamp": "2019-11-14T00:38:06.021Z", "KinesisBatchInfo": { "shardId": "shardId-000000000001", "startSequenceNumber": "49601189658422359378836298521827638475320189012309704722", "endSequenceNumber": "49601189658422359378836298522902373528957594348623495186", "approximateArrivalOfFirstRecord": "2019-11-14T00:38:04.835Z", "approximateArrivalOfLastRecord": "2019-11-14T00:38:05.580Z", "batchSize": 500, "streamArn": "arn:aws:kinesis:us-east-2:123456789012:stream/mystream" } }

Lambda unterstützt auch die Verarbeitung in der Reihenfolge für FIFO-Warteschlangen (First-In, First-Out), die auf die Anzahl der aktiven Nachrichtengruppen skaliert wird. Bei Standard-Warteschlangen werden Elemente nicht unbedingt der Reihe nach verarbeitet. Lambda skaliert hoch, um eine Standardwarteschlange so schnell wie möglich zu verarbeiten. Wenn ein Fehler auftritt, sendet Lambda Batches als einzelne Elemente an die Warteschlange zurück und verarbeitet sie möglicherweise in einer anderen Gruppierung als im ursprünglichen Batch. Gelegentlich kann es vorkommen, dass die Ereignisquellen-Zuweisung dasselbe Element aus der Warteschlange zweimal erhält, auch wenn kein Funktionsfehler aufgetreten ist. Lambda löscht Elemente aus der Warteschlange, nachdem sie erfolgreich verarbeitet wurden. Sie können die Quellenwarteschlange so konfigurieren, dass Elemente an eine Warteschlange für unzustellbare Nachrichten oder ein Ziel gesendet werden, wenn Lambda sie nicht verarbeiten kann.

Weitere Informationen zu Services, die Lambda-Funktionen direkt aufrufen, finden Sie unter Verwendung AWS Lambda mit anderen Diensten.

Konfigurieren von Zielen für Aufrufe zur Zuordnung von Ereignisquellen

Um Datensätze zu fehlgeschlagenen Aufrufen zur Zuordnung von Ereignisquellen beizubehalten, fügen Sie der Zuordnung von Ereignisquellen Ihrer Funktion ein Ziel hinzu. Die Konfiguration von Zielen für Aufrufe zur Zuordnung von Ereignisquellen wird nur für Kinesis-, DynamoDB- und Kafka-basierte Ereignisquellen unterstützt. Jeder Datensatz, der an das Ziel gesendet wird, ist ein JSON-Dokument mit Details zum Aufruf. Wie Einstellungen zur Fehlerbehandlung können Sie Ziele für eine Funktion, eine Funktionsversion oder einen Alias konfigurieren.

Anmerkung

Bei Aufrufen zur Zuordnung von Ereignisquellen können Sie nur Datensätze für fehlgeschlagene Aufrufe beibehalten. Bei anderen asynchronen Aufrufen können Sie Datensätze sowohl für erfolgreiche als auch für fehlgeschlagene Aufrufe speichern. Weitere Informationen finden Sie unter Konfigurieren von Zielen für den asynchronen Aufruf.

Sie können jedes Amazon-SNS-Thema oder jede Amazon-SQS-Warteschlange als Ziel konfigurieren. Für diese Zieltypen sendet Lambda die Datensatzmetadaten an das Ziel. Nur für Kafka-basierte Ereignisquellen können Sie auch einen Amazon-S3-Bucket als Ziel wählen. Wenn Sie einen S3-Bucket angeben, sendet Lambda den gesamten Aufrufdatensatz zusammen mit den Metadaten an das Ziel.

In der folgenden Tabelle finden Sie eine Zusammenfassung der Arten der unterstützten Ziele für Aufrufe zur Zuordnung von Ereignisquellen. Damit Lambda erfolgreich Datensätze an das von Ihnen ausgewählte Ziel senden kann, stellen Sie sicher, dass die Ausführungsrolle Ihrer Funktion auch die entsprechenden Berechtigungen enthält. In der Tabelle wird auch beschrieben, wie jeder Zieltyp den JSON-Aufrufdatensatz empfängt.

Zieltyp Unterstützt für die folgenden Ereignisquellen Erforderliche Berechtigungen Zielspezifisches JSON-Format

Amazon-SQS-Warteschlange

  • Kinesis

  • DynamoDB

  • Selbstverwaltetes Apache Kafka und verwaltetes Apache Kafka

Lambda übergibt die Aufrufdatensatz-Metadaten als Message an das Ziel.

Amazon SNS-Thema

  • Kinesis

  • DynamoDB

  • Selbstverwaltetes Apache Kafka und verwaltetes Apache Kafka

Lambda übergibt die Aufrufdatensatz-Metadaten als Message an das Ziel.

Amazon-S3-Bucket

  • Selbstverwaltetes Apache Kafka und verwaltetes Apache Kafka

Lambda speichert den Aufrufdatensatz zusammen mit den zugehörigen Metadaten am Ziel.

Das folgende Beispiel zeigt, was Lambda bei einem fehlgeschlagenen Aufruf der Kinesis-Ereignisquelle an eine SQS-Warteschlange oder ein SNS-Thema sendet. Da Lambda nur die Metadaten für diese Zieltypen sendet, verwenden Sie die Felder streamArn, shardId, startSequenceNumber und endSequenceNumber, um den vollständigen Originaldatensatz abzurufen.

{ "requestContext": { "requestId": "c9b8fa9f-5a7f-xmpl-af9c-0c604cde93a5", "functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction", "condition": "RetryAttemptsExhausted", "approximateInvokeCount": 1 }, "responseContext": { "statusCode": 200, "executedVersion": "$LATEST", "functionError": "Unhandled" }, "version": "1.0", "timestamp": "2019-11-14T00:38:06.021Z", "KinesisBatchInfo": { "shardId": "shardId-000000000001", "startSequenceNumber": "49601189658422359378836298521827638475320189012309704722", "endSequenceNumber": "49601189658422359378836298522902373528957594348623495186", "approximateArrivalOfFirstRecord": "2019-11-14T00:38:04.835Z", "approximateArrivalOfLastRecord": "2019-11-14T00:38:05.580Z", "batchSize": 500, "streamArn": "arn:aws:kinesis:us-east-2:123456789012:stream/mystream" } }

Ein Beispiel für DynamoDB-Ereignisquellen finden Sie unter Fehlerbehandlung. Ein Beispiel für Kafka-Ereignisquellen finden Sie unter Ausfallziele für selbstverwaltetes Apache Kafka oder Ausfallziele für Amazon MSK.