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 selbstverwalteter Apache Kafka-Nachrichten mit Lambda

Hinzufügen eines Kafka-Clusters als Ereignisquelle

Um eine Ereignisquellenzuordnung zu erstellen, fügen Sie Ihren Kafka-Cluster als einen Lambda-Funktions-Auslöser hinzu und verwenden Sie dabei die Lambda-Konsole, ein AWS -SDK oder die AWS Command Line Interface (AWS CLI).

In diesem Abschnitt wird beschrieben, wie Sie mit der Lambda-Konsole und AWS CLI ein Ereignisquellen-Zuweisung erstellen.

Voraussetzungen

Anpassbare Konsumentengruppen-ID

Wenn Sie Kafka als Ereignisquelle einrichten, können Sie eine Konsumentengruppen-ID angeben. Diese Konsumentengruppen-ID ist eine vorhandene Kennung für die Kafka-Konsumentengruppe, der Ihre Lambda-Funktion beitreten soll. Mit diesem Feature können Sie alle laufenden Kafka-Datensatzverarbeitungs-Setups nahtlos von anderen Verbrauchern auf Lambda migrieren.

Wenn Sie eine Konsumentengruppen-ID angeben und sie innerhalb dieser Konsumentengruppe weitere aktive Poller gibt, verteilt Kafka Nachrichten an alle Konsumenten. Mit anderen Worten, Lambda erhält nicht alle Nachrichten zum Thema Kafka. Wenn Sie möchten, dass Lambda alle Nachrichten im Thema verarbeitet, deaktivieren Sie alle anderen Poller in dieser Konsumentengruppe.

Wenn Sie außerdem eine Konsumentengruppen-ID angeben und Kafka eine gültige vorhandene Konsumentengruppe mit derselben ID findet, ignoriert Lambda die StartingPosition-Parameter für Ihre Ereignisquellen-Zuweisung. Stattdessen beginnt Lambda mit der Verarbeitung von Datensätzen gemäß dem zugesagten Versatz der Konsumentengruppe. Wenn Sie eine Konsumentengruppen-ID angeben und Kafka keine vorhandene Konsumentengruppe finden kann, konfiguriert Lambda Ihre Ereignisquelle mit der angegebenen StartingPosition.

Die Konsumentengruppen-ID, die Sie angeben, muss unter all Ihren Kafka-Ereignisquellen eindeutig sein. Nachdem Sie eine Kafka-Ereignisquellenzuordnung mit der angegebenen Konsumentengruppen-ID erstellt haben, können Sie diesen Wert nicht aktualisieren.

Hinzufügen eines selbstverwalteten Kafka-Clusters (Konsole)

Befolgen Sie diese Schritte, um Ihren selbstverwalteten Apache-Kafka-Cluster und ein Kafka-Thema als Auslöser für Ihre Lambda-Funktion hinzuzufügen.

Selbstverwaltetes Apache-Kafka-Cluster hinzufügen (AWS CLI)

Verwenden Sie die folgenden AWS CLI Beispielbefehle, um einen selbstverwalteten Apache Kafka-Trigger für Ihre Lambda-Funktion zu erstellen und anzuzeigen.

Verwenden von SASL/SCRAM

Wenn Kafka-Benutzer über das Internet auf Ihre Kafka-Broker zugreifen, geben Sie das Secrets-Manager-Secret an, das Sie für die SASL/SCRAM-Authentifizierung erstellt haben. Im folgenden Beispiel wird der create-event-source-mapping AWS CLI Befehl verwendet, um eine Lambda-Funktion mit dem Namen einem Kafka-Thema namens my-kafka-function zuzuordnen. AWSKafkaTopic

aws lambda create-event-source-mapping \ 
  --topics AWSKafkaTopic \
  --source-access-configuration Type=SASL_SCRAM_512_AUTH,URI=arn:aws:secretsmanager:us-east-1:111122223333:secret:MyBrokerSecretName \
  --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \
  --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'

Verwenden einer VPC

Wenn nur Kafka-Benutzer in Ihrer VPC auf Ihre Kafka-Broker zugreifen, müssen Sie Ihre VPC, Subnetze und VPC-Sicherheitsgruppe angeben. Im folgenden Beispiel wird der create-event-source-mapping AWS CLI Befehl verwendet, um eine Lambda-Funktion mit dem Namen einem Kafka-Thema namens my-kafka-function zuzuordnen. AWSKafkaTopic

aws lambda create-event-source-mapping \ 
  --topics AWSKafkaTopic \
  --source-access-configuration '[{"Type": "VPC_SUBNET", "URI": "subnet:subnet-0011001100"}, {"Type": "VPC_SUBNET", "URI": "subnet:subnet-0022002200"}, {"Type": "VPC_SECURITY_GROUP", "URI": "security_group:sg-0123456789"}]' \
  --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \
  --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'

Den Status mit dem anzeigen AWS CLI

Im folgenden Beispiel wird der get-event-source-mapping AWS CLI Befehl verwendet, um den Status der von Ihnen erstellten Ereignisquellenzuordnung zu beschreiben.

aws lambda get-event-source-mapping
          --uuid dh38738e-992b-343a-1077-3478934hjkfd7

Selbstverwalteter Apache-Kafka-Konfigurationsparameter

Alle Lambda-Ereignisquelltypen verwenden dieselben CreateEventSourceMappingUpdateEventSourceMappingAPI-Operationen. Allerdings gelten nur einige der Parameter für Apache Kafka.

Verwenden eines Kafka-Clusters als Ereignisquelle

Wenn Sie Ihren Apache Kafka-Cluster oder Amazon MSK als Auslöser für Ihre Lambda-Funktion hinzufügen, wird der Cluster als Ereignisquelle verwendet.

Lambda liest Ereignisdaten aus den Kafka-Themen, die Sie wie Topics in einer CreateEventSourceMappingAnfrage angeben, basierend auf den StartingPosition von Ihnen angegebenen Themen. Nach erfolgreicher Verarbeitung wird Ihr Kafka-Thema Ihrem Kafka-Cluster zugeordnet.

Wenn Sie die StartingPosition als LATEST angeben, beginnt Lambda mit dem Lesen der neuesten Nachricht in jeder zum Thema gehörenden Partition. Da es nach der Auslöserkonfiguration eine gewisse Verzögerung geben kann, bevor Lambda mit dem Lesen der Nachrichten beginnt, liest Lambda keine Nachrichten, die innerhalb dieses Zeitraums erzeugt wurden.

Lambda verarbeitet Datensätze von einer oder mehreren Kafka-Themenpartitionen, die Sie angeben, und sendet eine JSON-Nutzlast an Ihre Funktion. Eine einzelne Lambda-Nutzlast kann Nachrichten von mehreren Partitionen enthalten. Wenn mehr Datensätze verfügbar sind, setzt Lambda die Verarbeitung von Datensätzen stapelweise fort, basierend auf dem BatchSize Wert, den Sie in einer CreateEventSourceMappingAnfrage angeben, bis Ihre Funktion das Thema eingeholt hat.

Wenn Ihre Funktion einen Fehler für eine der Nachrichten in einem Batch zurückgibt, wiederholt Lambda den gesamten Nachrichtenbatch, bis die Verarbeitung erfolgreich ist oder die Nachrichten ablaufen. Sie können Datensätze, bei denen alle Wiederholungsversuche fehlschlagen, zur späteren Verarbeitung an ein Ausfallziel senden.

Startpositionen für Abfragen und Streams

Beachten Sie, dass die Stream-Abfrage bei der Erstellung und Aktualisierung der Zuordnung von Ereignisquellen letztendlich konsistent ist.

Dieses Verhalten bedeutet, dass, wenn Sie LATEST als Startposition für den Stream angeben, die Zuordnung von Ereignisquellen bei der Erstellung oder Aktualisierung möglicherweise Ereignisse übersieht. Um sicherzustellen, dass keine Ereignisse übersehen werden, geben Sie die Startposition des Streams als TRIM_HORIZON oder AT_TIMESTAMP an.

Skalierungsverhalten des Nachrichtendurchsatzes für selbstverwaltete Apache-Kafka-Zuordnungen von Ereignisquellen

Sie können zwischen zwei Modi der Skalierung des Nachrichtendurchsatzes für Ihre Amazon MSK-Zuordnung von Ereignisquellen wählen:

Standardmodus (auf Abruf)

Wenn Sie anfänglich eine selbstverwaltete Apache Kafka-Ereignisquelle erstellen, weist Lambda eine Standardanzahl von Event-Pollern zu, um alle Partitionen im Kafka-Thema zu verarbeiten. Lambda erhöht oder verringert automatisch die Anzahl der Ereignis-Poller je nach Nachrichtenlast.

In Intervallen von einer Minute wertet Lambda die Verbraucher-Offsetverzögerung aller Partitionen im Thema aus. Wenn die Offset-Verzögerung zu hoch ist, empfängt die Partition Nachrichten schneller als Lambda sie verarbeiten kann. Falls erforderlich, fügt Lambda dem Thema Ereignis-Poller hinzu oder entfernt sie. Dieser Prozess der automatischen Skalierung durch Hinzufügen oder Entfernen von Ereignis-Pollern erfolgt innerhalb von drei Minuten nach der Auswertung.

Wenn Ihre Ziel-Lambda-Funktion gedrosselt ist, reduziert Lambda die Anzahl der Ereignis-Poller. Diese Aktion verringert den Workload der Funktion, indem sie die Anzahl der Nachrichten reduziert, die Ereignis-Poller abrufen und an die Funktion senden können.

Um den Durchsatz Ihres Kafka-Themas zu überwachen, können Sie die Apache Kafka-Verbrauchermetriken wie consumer_lag und consumer_offset anzeigen.

Konfigurieren des bereitgestellten Modus

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 Meldungsspitzen sofort verarbeiten, wenn sie auftreten. Wir empfehlen die Verwendung des Bereitstellungsmodus für Kafka-Workloads, die strenge Leistungsanforderungen haben.

In Lambda ist ein Event Poller eine Recheneinheit, die bis zu 5% MBps des Durchsatzes verarbeiten kann. Nehmen wir als Referenz an, dass Ihre Ereignisquelle eine durchschnittliche Nutzlast von 1 MB erzeugt und die durchschnittliche Funktionsdauer 1 Sekunde beträgt. Wenn die Nutzlast keiner Transformation (wie Filterung) unterzogen wird, kann ein einzelner Poller 5 MBps Durchsatz- und 5 gleichzeitige Lambda-Aufrufe unterstützen. Die Verwendung des Bereitstellungsmodus verursacht zusätzliche Kosten. Kostenvoranschläge finden Sie unter AWS Lambda -Preise.

Im Bereitstellungsmodus liegt der Bereich der akzeptierten Werte für die Mindestanzahl der Ereignis-Poller (MinimumPollers) zwischen 1 und 200 (einschließlich). Der Bereich der akzeptierten Werte für die maximale Anzahl von Event-Pollern (MaximumPollers) liegt zwischen 1 und einschließlich 2.000. MaximumPollers muss größer als oder gleich MinimumPollers sein. Um eine geordnete Verarbeitung innerhalb der Partitionen zu gewährleisten, begrenzt Lambda das MaximumPollers auf die Anzahl der Partitionen im Thema.

Weitere Einzelheiten zur Auswahl geeigneter Werte für minimale und maximale Ereignis-Poller finden Sie unter Bewährte Verfahren und Überlegungen bei der Verwendung des Bereitstellungsmodus.

Sie können den Bereitstellungsmodus für Ihre selbst verwaltete Apache Kafka-Zuordnung von Ereignisquellen über die Konsole oder die Lambda-API konfigurieren.

Sie können den Bereitstellungsmodus programmgesteuert mithilfe des Objekts in Ihrem konfigurieren. ProvisionedPollerConfig EventSourceMappingConfiguration Der folgende UpdateEventSourceMappingCLI-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 UpdateEventSourceMappingCLI-Befehl verwenden:

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{}'

Bewährte Verfahren und Überlegungen bei der Verwendung des Bereitstellungsmodus

Die optimale Konfiguration der minimalen und maximalen Ereignispoller für Ihre Zuordnung von Ereignisquellen hängt von den Leistungsanforderungen Ihrer Anwendung ab. Wir empfehlen Ihnen, mit den standardmäßigen Minimum Event Pollers zu beginnen, um das Leistungsprofil zu erstellen. Passen Sie Ihre Konfiguration auf der Grundlage der beobachteten Nachrichtenverarbeitungsmuster und Ihres gewünschten Leistungsprofils an.

Erhöhen Sie bei Workloads mit starkem Datenverkehr und strengen Leistungsanforderungen die Mindestanzahl der Event-Poller, um plötzliche Nachrichtenfluten zu bewältigen. Um zu ermitteln, wie viele Event-Poller mindestens erforderlich sind, sollten Sie die Nachrichten pro Sekunde Ihres Workloads und die durchschnittliche Nutzlastgröße berücksichtigen und die Durchsatzkapazität eines einzelnen Event-Pollers (bis zu 5 MBps) als Referenz verwenden.

Um eine geordnete Verarbeitung innerhalb einer Partition aufrechtzuerhalten, begrenzt Lambda die maximale Anzahl der Event-Poller auf die Anzahl der Partitionen im Thema. Darüber hinaus hängt die maximale Anzahl von Event-Pollern, auf die Ihr Zuordnung von Ereignisquellen skaliert werden kann, von den Gleichzeitigkeitseinstellungen der Funktion ab.

Wenn Sie den Bereitstellungsmodus aktivieren, aktualisieren Sie Ihre Netzwerkeinstellungen, um AWS PrivateLink VPC-Endpunkte und zugehörige Berechtigungen zu entfernen.

CloudWatch Amazon-Metriken

Lambda gibt die Metrik OffsetLag aus, während Ihre Funktion Datensätze verarbeitet. Der Wert dieser Metrik ist die Differenz (der Versatz) zwischen dem letzten Datensatz, der ins Kafka-Ereignisquellen-Thema geschrieben wurde, und dem letzten Datensatz, den die Konsumentengruppe Ihrer Funktion verarbeitet hat. Sie können mit OffsetLag die Latenz zwischen dem Hinzufügen eines Datensatzes und der Verarbeitung des Datensatzes durch Ihre Konsumentengruppe abschätzen.

Ein zunehmender Trend in OffsetLag kann auf Probleme mit Pollern in der Konsumentengruppe Ihrer Funktion hinweisen. Weitere Informationen finden Sie unter CloudWatch Metriken mit Lambda verwenden.