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.
Verwenden von Lambda mit Amazon SQS
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.
Mit einer Lambda-Funktion können Sie Nachrichten in einer Amazon-SQS-Warteschlange (Amazon Simple Queue Service) verarbeiten. Lambda unterstützt sowohl Standard-Warteschlangen als auch First-In-First-Out-Warteschlangen (FIFO) für Zuordnungen von Ereignisquellen. Sie können den Bereitstellungsmodus auch verwenden, um dedizierte Polling-Ressourcen für Ihre Amazon SQS-Ereignisquellenzuordnungen zuzuweisen. Die Lambda-Funktion und die Amazon SQS-Warteschlange müssen sich in derselben AWS-Region befinden, obwohl sie unterschiedlich sein können. AWS-Konten
Eine Beispielfunktion, die Amazon SQS-Nachrichten verarbeitet, finden Sie unter. Tutorial: Verwenden von Lambda mit Amazon SQS Informationen zur kontoübergreifenden Verarbeitung finden Sie unter. Tutorial: Verwenden einer kontoübergreifenden Amazon SQS SQS-Warteschlange als Ereignisquelle Eine vollständige Liste der Konfigurationsoptionen, finden Sie unter Lambdaparameter für Amazon-SQS-Zuordnungen von Ereignisquellen.
Bei der Verarbeitung von Amazon-SQS-Nachrichten müssen Sie eine Logik für teilweise Batch-Antworten implementieren, um zu verhindern, dass versucht wird, erfolgreich verarbeitete Nachrichten erneut zu verarbeiten, wenn einige Nachrichten in einem Batch fehlschlagen. Das Batch Processor-Hilfsprogramm von Powertools für AWS Lambda vereinfacht diese Implementierung, indem es die partielle Batch-Antwortlogik automatisch verarbeitet, wodurch die Entwicklungszeit reduziert und die Zuverlässigkeit verbessert wird.
Themen
Verständnis des Polling- und Batching-Verhaltens für Amazon-SQS-Zuordnungen von Ereignisquellen
Verwenden Sie den bereitgestellten Modus mit Amazon SQS-Ereignisquellenzuordnungen
Konfiguration des bereitgestellten Modus für die Amazon SQS-Ereignisquellenzuordnung
Beispiel für ein Standard-Warteschlangen-Nachrichtenereignis
Erstellen und Konfigurieren einer Amazon SQS-Zuordnung von Ereignisquellen
Konfiguration des Skalierungsverhaltens für SQS-Zuordnungen von Ereignisquellen
Behandlung von Fehlern für eine SQS-Ereignisquelle in Lambda
Lambdaparameter für Amazon-SQS-Zuordnungen von Ereignisquellen
Verwendung der Ereignisfilterung mit einer Amazon-SQS-Ereignisquelle
Tutorial: Verwenden einer kontoübergreifenden Amazon SQS SQS-Warteschlange als Ereignisquelle
Verständnis des Polling- und Batching-Verhaltens für Amazon-SQS-Zuordnungen von Ereignisquellen
Mit Amazon-SQS-Zuordnungen von Ereignisquellen fragt Lambda die Warteschlange ab und ruft Ihre Funktion synchron mit einem Ereignis auf. Jedes Ereignis kann einen Batch von mehreren Nachrichten aus der Warteschlange enthalten. Lambda empfängt diese Ereignisse jeweils stapelweise und ruft Ihre Funktion für jeden Stapel einmal auf. Wenn Ihre Funktion einen Batch erfolgreich verarbeitet, löscht Lambda deren Nachrichten aus der Warteschlange.
Wenn Lambda einen Batch empfängt, bleiben die Nachrichten in der Warteschlange, werden aber für die Dauer der Zeitbeschränkung für die Sichtbarkeit der Warteschlange ausgeblendet. Wenn Ihre Funktion alle Nachrichten im Batch erfolgreich verarbeitet hat, löscht Lambda die Nachrichten aus der Warteschlange. Wenn Ihre Funktion bei der Verarbeitung eines Batches auf einen Fehler stößt, werden standardmäßig alle Nachrichten in diesem Batch nach Ablauf des Zeitlimits für die Sichtbarkeit wieder in der Warteschlange sichtbar. Deshalb muss der Funktionscode in der Lage sein, dieselbe Nachricht mehrmals ohne unbeabsichtigte Begleiterscheinungen zu verarbeiten.
Warnung
Zuordnung von Lambda-Ereignisquellen 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
Um zu verhindern, dass Lambda eine Nachricht mehrfach verarbeitet, können Sie entweder Ihre Ereignisquellenzuordnung so konfigurieren, dass Fehler bei Batch-Elementen in Ihre Funktionsantwort aufgenommen werden, oder Sie können die DeleteMessage API verwenden, um Nachrichten aus der Warteschlange zu entfernen, sobald Ihre Lambda-Funktion sie erfolgreich verarbeitet.
Weitere Informationen zu Konfigurationsparametern, die Lambda für SQS-Zuordnungen von Ereignisquellen unterstützt, finden Sie unter Erstellen einer SQS-Zuordnung von Ereignisquellen.
Verwenden Sie den bereitgestellten Modus mit Amazon SQS-Ereignisquellenzuordnungen
Für Workloads, bei denen Sie den Durchsatz Ihrer Zuordnung von Ereignisquellen optimieren müssen, können Sie den Bereitstellungsmodus verwenden. Im Bereitstellungsmodus definieren Sie Mindest- und Höchstgrenzen für die Anzahl der bereitgestellten Ereignis-Poller. Diese bereitgestellten Event-Poller sind auf Ihre Zuordnung von Ereignisquellen ausgerichtet und können unerwartete Nachrichtenspitzen durch reaktionsschnelle Autoskalierung bewältigen. Die Amazon SQS-Ereignisquellenzuordnung, die mit dem Bereitstellungsmodus konfiguriert ist, skaliert dreimal schneller (bis zu 1.000 gleichzeitige Aufrufe pro Minute) und unterstützt eine 80-mal höhere Parallelität (bis zu 100.000 gleichzeitige Aufrufe) als die standardmäßige Amazon SQS-Funktion zur Zuordnung von Ereignisquellen.
Wir empfehlen, den Bereitstellungsmodus für ereignisgesteuerte Amazon SQS-Workloads zu verwenden, für die strenge Leistungsanforderungen gelten, z. B. Finanzdienstleister, die Marktdatenfeeds verarbeiten, E-Commerce-Plattformen, die personalisierte Empfehlungen in Echtzeit bereitstellen, und Spieleunternehmen, die Live-Spielerinteraktionen verwalten. Die Verwendung des Bereitstellungsmodus verursacht zusätzliche Kosten. Eine detaillierte Preisgestaltung finden Sie unter Preise. AWS Lambda
Jeder Event-Poller im bereitgestellten Modus kann bis zu 1% MB/s des Durchsatzes, bis zu 10 gleichzeitige Aufrufe oder bis zu 10 Amazon SQS-Polling-API-Aufrufe pro Sekunde verarbeiten. Der Bereich der akzeptierten Werte für die Mindestanzahl von Event-Pollern (MinimumPollers) liegt zwischen 2 und 200, der Standardwert ist 2. Der Bereich der zulässigen Werte für die maximale Anzahl von Event-Pollern (MaximumPollers) liegt zwischen 2 und 10.000, der Standardwert ist 200. MaximumPollers muss größer oder gleich sein MinimumPollers.
Bestimmung der erforderlichen Event-Poller
Um die Anzahl der Event-Poller abzuschätzen, die erforderlich sind, um eine optimale Nachrichtenverarbeitungsleistung bei Verwendung des bereitgestellten Modus für SQS ESM sicherzustellen, erfassen Sie die folgenden Metriken für Ihre Anwendung: Spitzenereignisse pro Sekunde, die eine Verarbeitung mit niedriger Latenz erfordern, durchschnittliche SQS-Ereignisnutzlastgröße, durchschnittliche Lambda-Funktionsdauer und konfigurierte Batchgröße.
Zunächst können Sie anhand der folgenden Formel die Anzahl der SQS-Ereignisse pro Sekunde (EPS) schätzen, die von einem Event-Poller für Ihre Arbeitslast unterstützt werden:
EPS per event poller = minimum( ceiling(1024 / average event size in KB), ceiling(10 / average function duration in seconds) * batch size, min(100, 10 * batch size) )
Anschließend können Sie mithilfe der folgenden Formel die Anzahl der mindestens erforderlichen Poller berechnen. Diese Berechnung stellt sicher, dass Sie ausreichend Kapazität bereitstellen, um Ihre Anforderungen an den Spitzenverkehr zu bewältigen.
Required event pollers = (Peak number of events per second in Queue) / EPS per event poller
Stellen Sie sich eine Arbeitslast mit einer Standard-Batchgröße von 10, einer durchschnittlichen Ereignisgröße von 3 KB, einer durchschnittlichen Funktionsdauer von 100 ms und der Anforderung vor, 1.000 Ereignisse pro Sekunde zu verarbeiten. In diesem Szenario unterstützt jeder Event-Poller ungefähr 100 Ereignisse pro Sekunde (EPS). Daher empfehlen wir, die Mindestanzahl an Pollern auf 10 festzulegen, um Ihren Anforderungen in Spitzenverkehrszeiten angemessen gerecht zu werden. Wenn Ihr Workload dieselben Eigenschaften hat, aber eine durchschnittliche Funktionsdauer von 1 Sekunde hat, unterstützt jeder Poller nur 10 EPS, sodass Sie mindestens 100 Poller konfigurieren müssen, um 1.000 Ereignisse pro Sekunde bei niedriger Latenz zu unterstützen.
Wir empfehlen, eine Standard-Batchgröße von 10 oder höher zu verwenden, um die Effizienz von Event-Pollern im bereitgestellten Modus zu maximieren. Höhere Batchgrößen ermöglichen es jedem Poller, mehr Ereignisse pro Aufruf zu verarbeiten, was den Durchsatz und die Kosteneffizienz verbessert. Berücksichtigen Sie bei der Planung Ihrer Event-Poller-Kapazität mögliche Verkehrsspitzen und erwägen Sie, Ihren MinimumPollers-Wert etwas höher als den berechneten Mindestwert festzulegen, um einen Puffer zu schaffen. Überwachen Sie außerdem Ihre Workload-Merkmale im Laufe der Zeit, da Änderungen der Nachrichtengröße, der Funktionsdauer oder der Verkehrsmuster Anpassungen Ihrer Event-Poller-Konfiguration erforderlich machen können, um eine optimale Leistung und Kosteneffizienz zu gewährleisten. Für eine präzise Kapazitätsplanung empfehlen wir, Ihre spezifische Arbeitslast zu testen, um den tatsächlichen Gewinn pro Aktie zu ermitteln, den jeder Event-Poller erzielen kann.
Konfiguration des bereitgestellten Modus für die Amazon SQS-Ereignisquellenzuordnung
Sie können den bereitgestellten Modus für Ihre Amazon SQS-Ereignisquellenzuordnung mithilfe der Konsole oder der Lambda-API konfigurieren.
Um den bereitgestellten Modus für eine bestehende Amazon SQS-Ereignisquellenzuordnung (Konsole) zu konfigurieren
-
Öffnen Sie die Seite Funktionen
der Lambda-Konsole. -
Wählen Sie die Funktion mit der Amazon SQS-Ereignisquellenzuordnung aus, für die Sie den bereitgestellten Modus konfigurieren möchten.
-
Wählen Sie Konfiguration und anschließend Auslöser aus.
-
Wählen Sie die Amazon SQS-Ereignisquellenzuordnung aus, für die Sie den bereitgestellten Modus konfigurieren möchten, und wählen Sie dann Bearbeiten aus.
-
Wählen Sie unter Konfiguration der Zuordnung von Ereignisquellen die Option Bereitstellungsmodus konfigurieren aus.
-
Geben Sie für die Mindestanzahl an Event-Pollern einen Wert zwischen 2 und 200 ein. Wenn Sie keinen Wert angeben, wählt Lambda den Standardwert 2.
-
Geben Sie für maximale Anzahl von Event-Pollern einen Wert zwischen 2 und 10.000 ein. Dieser Wert muss größer oder gleich Ihrem Wert für Minimum Event Pollers sein. Wenn Sie keinen Wert angeben, wählt Lambda einen Standardwert von 200.
-
-
Wählen Sie Speichern.
Sie können den bereitgestellten Modus programmgesteuert mithilfe des ProvisionedPollerConfig Objekts in Ihrem konfigurieren. EventSourceMappingConfiguration Mit dem folgenden UpdateEventSourceMapping CLI-Befehl werden beispielsweise ein MinimumPollers Wert von 5 und ein MaximumPollers Wert von 100 konfiguriert.
aws lambda update-event-source-mapping \ --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \ --provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'
Nachdem Sie den Bereitstellungsmodus konfiguriert haben, können Sie die Verwendung von Event-Pollern für Ihren Workload beobachten, indem Sie die ProvisionedPollers-Metrik überwachen. Weitere Informationen finden Sie unter Metriken zur Zuordnung von Ereignisquellen.
Um den bereitgestellten Modus zu deaktivieren und zum Standardmodus (bei Bedarf) zurückzukehren, können Sie den folgenden UpdateEventSourceMapping CLI-Befehl verwenden:
aws lambda update-event-source-mapping \ --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \ --provisioned-poller-config '{}'
Anmerkung
Der bereitgestellte Modus kann nicht zusammen mit der Einstellung für maximale Parallelität verwendet werden. Wenn Sie den bereitgestellten Modus verwenden, steuern Sie die maximale Parallelität über die maximale Anzahl von Event-Pollern.
Weitere Informationen zur Konfiguration des bereitgestellten Modus finden Sie unter. Erstellen und Konfigurieren einer Amazon SQS-Zuordnung von Ereignisquellen
Beispiel für ein Standard-Warteschlangen-Nachrichtenereignis
Beispiel Amazon-SQS-Nachrichtenereignis (Standardwarteschlange)
{ "Records": [ { "messageId": "059f36b4-87a3-44ab-83d2-661975830a7d", "receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...", "body": "Test message.", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1545082649183", "SenderId": "AIDAIENQZJOLO23YVJ4VO", "ApproximateFirstReceiveTimestamp": "1545082649185" }, "messageAttributes": { "myAttribute": { "stringValue": "myValue", "stringListValues": [], "binaryListValues": [], "dataType": "String" } }, "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue", "awsRegion": "us-east-2" }, { "messageId": "2e1424d4-f796-459a-8184-9c92662be6da", "receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...", "body": "Test message.", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1545082650636", "SenderId": "AIDAIENQZJOLO23YVJ4VO", "ApproximateFirstReceiveTimestamp": "1545082650649" }, "messageAttributes": {}, "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue", "awsRegion": "us-east-2" } ] }
Lambda fragt standardmäßig bis zu 10 Nachrichten in Ihrer Warteschlange sofort ab und sendet diesen Batch an die Funktion. Damit die Funktion nicht mit einer kleinen Anzahl von Datensätzen aufgerufen wird, können Sie die Ereignisquelle so konfigurieren, dass die Datensätze bis zu 5 Minuten lang gepuffert werden, indem Sie ein Batch-Fenster konfigurieren. Vor dem Aufrufen der Funktion fragt Lambda weiter Nachrichten aus der Standardwarteschlange ab, bis das Batch-Fenster abläuft, das Nutzlastkontingent pro Aufruf erreicht ist oder die konfigurierte maximale Batch-Größe erreicht ist.
Wenn Sie ein Batch-Fenster verwenden und Ihre SQS-Warteschlange sehr wenig Datenverkehr enthält, wartet Lambda möglicherweise bis zu 20 Sekunden, bevor Sie Ihre Funktion aufruft. Dies gilt auch, wenn Sie ein Batch-Fenster unter 20 Sekunden festlegen.
Anmerkung
In Java können beim Deserialisieren von JSON Nullzeigerfehler auftreten. Dies könnte daran liegen, dass die Groß- und Kleinschreibung von „Records“ und „eventSourceARN“ vom JSON-Objektmapper konvertiert wird.
Beispiel für ein FIFO-Warteschlangen-Nachrichtenereignis
Bei FIFO-Warteschlangen enthalten Datensätze zusätzliche Attribute, die mit der Deduplizierung und Sequenzierung zusammenhängen.
Beispiel Amazon-SQS-Nachrichtenereignis (FIFO-Warteschlange)
{ "Records": [ { "messageId": "11d6ee51-4cc7-4302-9e22-7cd8afdaadf5", "receiptHandle": "AQEBBX8nesZEXmkhsmZeyIE8iQAMig7qw...", "body": "Test message.", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1573251510774","SequenceNumber": "18849496460467696128", "MessageGroupId": "1","SenderId": "AIDAIO23YVJENQZJOL4VO","MessageDeduplicationId": "1","ApproximateFirstReceiveTimestamp": "1573251510774" }, "messageAttributes": {}, "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:fifo.fifo", "awsRegion": "us-east-2" } ] }