View a markdown version of this page

Verarbeitung mit niedriger Latenz für Kafka-Ereignisquellen - 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.

Verarbeitung mit niedriger Latenz für Kafka-Ereignisquellen

AWS Lambda unterstützt nativ die Ereignisverarbeitung mit niedriger Latenz für Anwendungen, die konsistente End-to-End-Latenzen von weniger als 100 Millisekunden erfordern. Auf dieser Seite finden Sie Konfigurationsdetails und Empfehlungen zur Aktivierung von Workflows mit geringer Latenz.

Verarbeitung mit geringer Latenz aktivieren

Um die Verarbeitung mit geringer Latenz für eine Kafka-Zuordnung von Ereignisquellen zu aktivieren, ist die folgende Grundkonfiguration erforderlich:

  • Aktivieren Sie den Bereitstellungsmodus. Weitere Informationen finden Sie unter Modus bereitgestellter Kapazität.

  • Setzen Sie den Parameter MaximumBatchingWindowInSeconds der Zuordnung von Ereignisquellen auf 0. Weitere Informationen finden Sie unter Batching-Verhalten.

Fine-tuning Ihr Kafka ESM mit niedriger Latenz

Beachten Sie die folgenden Empfehlungen, um Ihre Kafka-Zuordnung von Ereignisquellen für geringe Latenz zu optimieren:

Konfiguration des Bereitstellungsmodus

Im Bereitstellungsmodus für das Kafka-Eventquellen-Mapping können Sie den Durchsatz Ihres Eventquellen-Mappings optimieren, indem Sie eine Mindest- und Höchstanzahl von Ressourcen konfigurieren, die als Event-Poller bezeichnet werden. Ein Event-Poller (oder Poller) stellt eine Rechenressource dar, die einer Eventquellen-Mapping im bereitgestellten Modus zugrunde liegt und bis zu 5 Durchsätze zuweist. MB/s Jeder Ereignis-Poller unterstützt bis zu 5 gleichzeitige Lambda-Aufrufe.

Um die optimale Poller-Konfiguration für Ihre Anwendung zu ermitteln, berücksichtigen Sie Ihre maximale Erfassungsrate und Ihre Verarbeitungsanforderungen. Sehen wir uns ein vereinfachtes Beispiel an:

Bei einer Batchgröße von 20 Datensätzen und einer durchschnittlichen Dauer der Zielfunktion von 50 ms kann jeder Poller 2.000 Datensätze pro Sekunde verarbeiten, wobei ein Limit von 5 festgelegt ist. MB/s Dies wird wie folgt berechnet: (20 Datensätze × 1000ms/50ms) × 5 gleichzeitige Lambda-Aufrufe. Wenn Ihre gewünschte Spitzenerfassungsrate also 20 000 Datensätze pro Sekunde beträgt, benötigen Sie mindestens 10 Ereignis-Poller.

Anmerkung

Wir empfehlen, zusätzliche Ereignis-Pollers als Puffer bereitzustellen, um einen konstanten Betrieb bei maximaler Kapazität zu vermeiden.

Der Bereitstellungsmodus skaliert Ihre Ereignis-Poller automatisch basierend auf den Datenverkehrsmustern innerhalb der konfigurierten minimalen und maximalen Ereignis-Poller, was eine Neugewichtung auslösen und somit zusätzliche Latenz verursachen kann. Sie können Auto Scaling deaktivieren, indem Sie denselben Wert für den minimalen und maximalen Ereignis-Poller konfigurieren.

Weitere Überlegungen

Zu den weiteren Überlegungen gehören:

  • Kaltstarts durch den Aufruf Ihrer Lambda-Zielfunktion können möglicherweise die End-to-End-Latenz erhöhen. Um dieses Risiko zu verringern, sollten Sie erwägen, die bereitgestellte Parallelität oder die Zielfunktion Ihres SnapStart Eventquellen-Mappings zu aktivieren. Optimieren Sie außerdem die Speicherzuweisung Ihrer Funktion, um eine konsistente und optimale Ausführung sicherzustellen.

  • Wenn der Wert auf 0 gesetzt MaximumBatchingWindowInSeconds ist, verarbeitet Lambda sofort alle verfügbaren Datensätze, ohne darauf zu warten, dass die gesamte Batchgröße aufgefüllt ist. Wenn Ihre Batchgröße beispielsweise auf 1.000 Datensätze festgelegt ist, aber nur 100 Datensätze verfügbar sind, verarbeitet Lambda diese 100 Datensätze sofort, anstatt darauf zu warten, dass sich die gesamten 1.000 Datensätze ansammeln.

Wichtig

Die optimale Konfiguration für eine Verarbeitung mit geringer Latenz hängt stark von Ihrer spezifischen Workload ab. Wir empfehlen dringend, verschiedene Konfigurationen mit Ihrer tatsächlichen Workload zu testen, um die besten Einstellungen für Ihren Anwendungsfall zu ermitteln.