Verwenden von Lambda mit Amazon SQS

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 spezielle Abfrageressourcen für Ihre Amazon SQS SQS-Ereignisquellenzuordnungen zuzuweisen. Die Lambda-Funktion und die Amazon SQS SQS-Warteschlange müssen sich in derselben befinden AWS-Region, obwohl sie sich unterscheiden können. AWS-Konten

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 Utility von Powertools for AWS Lambda vereinfacht diese Implementierung, indem es automatisch die Logik der partiellen Batch-Antwort verarbeitet, wodurch die Entwicklungszeit reduziert und die Zuverlässigkeit verbessert wird.

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.

Um zu verhindern, dass Lambda eine Nachricht mehrfach verarbeitet, können Sie entweder Ihre Ereignisquellenzuordnung so konfigurieren, dass Batch-Elementfehler in Ihre Funktionsantwort aufgenommen werden, oder Sie können die DeleteMessageAPI verwenden, um Nachrichten aus der Warteschlange zu entfernen, wenn 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 des Bereitstellungsmodus mit Amazon SQS 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 mit dem Bereitstellungsmodus konfigurierte Amazon SQS SQS-Ereignisquellenzuweisung skaliert dreimal schneller (bis zu 1.000 gleichzeitige Aufrufe pro Minute) und unterstützt eine 16-mal höhere Parallelität (bis zu 20.000 gleichzeitige Aufrufe) als die standardmäßige Amazon SQS SQS-Funktion zur Zuordnung von Ereignisquellen. Wir empfehlen, den Bereitstellungsmodus für ereignisgesteuerte Amazon SQS 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 Bereitstellungsmodus kann bis zu 1 MB/s Durchsatz, 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 akzeptierten Werte für die maximale Anzahl von Event-Pollern (MaximumPollers) liegt zwischen 2 und 2.000, der Standardwert ist 200. MaximumPollers muss größer oder gleich sein MinimumPollers.

Ermittlung der erforderlichen Event-Poller

Um die Anzahl der Ereignisabfragen zu schätzen, die erforderlich sind, um eine optimale Nachrichtenverarbeitungsleistung sicherzustellen, wenn Sie den Bereitstellungsmodus für SQS ESM verwenden, erfassen Sie die folgenden Metriken für Ihre Anwendung: maximale SQS-Ereignisse pro Sekunde, die eine Verarbeitung mit niedriger Latenz erfordern, durchschnittliche Größe der SQS-Ereignisnutzlast, 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 Ihren Workload 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 anhand der folgenden Formel die Anzahl der mindestens erforderlichen Poller berechnen. Diese Berechnung stellt sicher, dass Sie ausreichend Kapazität bereitstellen, um Ihren Spitzenverkehrsanforderungen gerecht zu werden.

Required event pollers = (Peak number of events per second in Queue) / EPS per event poller

Stellen Sie sich einen Workload mit einer Standard-Batchgröße von 10, einer durchschnittlichen Ereignisgröße von 3 KB, einer durchschnittlichen Funktionsdauer von 100 ms und der Anforderung, 1.000 Ereignisse pro Sekunde zu verarbeiten, vor. In diesem Szenario unterstützt jeder Event Poller ungefähr 100 Ereignisse pro Sekunde (EPS). Daher sollten Sie die Mindestanzahl an Pollern auf 10 festlegen, um Ihren Anforderungen an den Spitzenverkehr 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. Sie müssen also mindestens 100 Poller konfigurieren, um 1.000 Ereignisse pro Sekunde bei niedriger Latenz zu unterstützen.

Wir empfehlen die Verwendung einer Standard-Batchgröße von 10 oder höher, um die Effizienz von Event-Pollern im Bereitstellungsmodus 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 potenzielle Verkehrsspitzen und ziehen Sie in Betracht, den MinimumPollers-Wert etwas höher als das berechnete Minimum festzulegen, um einen Puffer bereitzustellen. Überwachen Sie außerdem Ihre Workload-Merkmale im Zeitverlauf, da Änderungen der Nachrichtengröße, der Funktionsdauer oder der Verkehrsmuster möglicherweise Anpassungen an Ihrer Event-Poller-Konfiguration erforderlich machen, um eine optimale Leistung und Kosteneffizienz zu gewährleisten. Für eine genaue Kapazitätsplanung empfehlen wir, Ihre spezifische Arbeitslast zu testen, um den tatsächlichen Gewinn pro Leistung zu ermitteln, den jeder Event Poller erzielen kann.

Konfiguration des Bereitstellungsmodus für die Zuordnung von Amazon SQS SQS-Ereignisquellen

Sie können den Bereitstellungsmodus für Ihre Amazon SQS SQS-Ereignisquellenzuordnung mithilfe der Konsole oder der Lambda-API konfigurieren.

Sie können den Bereitstellungsmodus programmgesteuert mithilfe des ProvisionedPollerConfig Objekts in Ihrem konfigurieren. EventSourceMappingConfiguration Der folgende UpdateEventSourceMapping CLI-Befehl konfiguriert beispielsweise einen MinimumPollers Wert von 5 und einen MaximumPollers Wert von 100.

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 Bereitstellungsmodus zu deaktivieren und zum Standardmodus (auf Abruf) 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 '{}'

Weitere Informationen zur Konfiguration des Bereitstellungsmodus finden Sie unter. Erstellen und Konfigurieren einer Amazon SQS-Zuordnung von Ereignisquellen

Beispiel für ein Standard-Warteschlangen-Nachrichtenereignis

{
    "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.

Beispiel für ein FIFO-Warteschlangen-Nachrichtenereignis

Bei FIFO-Warteschlangen enthalten Datensätze zusätzliche Attribute, die mit der Deduplizierung und Sequenzierung zusammenhängen.

{
    "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"
        }
    ]
}