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.
Konfigurieren von Amazon MSK-Ereignisquellen für Lambda
Um einen Amazon MSK-Cluster als Ereignisquelle für Ihre Lambda-Funktion zu verwenden, erstellen Sie eine Ereignisquellenzuordnung, die die beiden Ressourcen verbindet. Auf dieser Seite wird beschrieben, wie Sie eine Ereignisquellenzuordnung für Amazon MSK erstellen.
Auf dieser Seite wird davon ausgegangen, dass Sie Ihren MSK-Cluster und die Amazon Virtual Private Cloud (VPC), in der er sich befindet, bereits ordnungsgemäß konfiguriert haben. Informationen zum Einrichten Ihres Clusters oder Ihrer VPC finden Sie unterKonfiguration Ihres Amazon MSK-Clusters und Ihres Amazon VPC-Netzwerks für Lambda.
Themen
Verwenden eines Amazon MSK-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 der von Ihnen angegebenen Startposition. Nach erfolgreicher Verarbeitung wird Ihr Kafka-Thema Ihrem Kafka-Cluster zugeordnet.
Lambda liest Nachrichten sequentiell für jede Kafka-Themenpartition. 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.
Nachdem Lambda jeden Batch verarbeitet hat, werden die Offsets der Nachrichten in diesem Batch festgeschrieben. 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.
Anmerkung
Während Lambda-Funktionen in der Regel ein maximales Timeout-Limit von 15 Minuten haben, unterstützen Ereignisquellenzuordnungen für Amazon MSK, selbstverwaltetes Apache Kafka, Amazon DocumentDB, Amazon MQ für ActiveMQ und RabbitMQ nur Funktionen mit einem maximalen Timeout-Limit von 14 Minuten.
Erstellen einer Ereignisquellenzuordnung für eine Amazon MSK-Ereignisquelle
Um eine Ereignisquellenzuordnung zu erstellen, können Sie die Lambda-Konsole, die AWS Command Line Interface (CLI) oder ein AWS SDK
Anmerkung
Wenn Sie die Ereignisquellenzuordnung erstellen, erstellt Lambda eine Hyperplane-ENI im privaten Subnetz, das Ihren MSK-Cluster enthält, sodass Lambda eine sichere Verbindung herstellen kann. Diese Hyperplane-ENI ermöglicht es, die Subnetz- und Sicherheitsgruppenkonfiguration Ihres MSK-Clusters zu verwenden, nicht Ihre Lambda-Funktion.
Mit den folgenden Konsolenschritten wird ein Amazon MSK-Cluster als Auslöser für Ihre Lambda-Funktion hinzugefügt. Unter der Haube entsteht dadurch eine Ressource zur Zuordnung von Ereignisquellen.
So fügen Sie Ihrer Lambda-Funktion (Konsole) einen Amazon-MSK-Auslöser hinzu
-
Öffnen Sie die Seite Funktion
der Lambda-Konsole. -
Wählen Sie den Namen der Lambda-Funktion, zu der Sie einen Amazon MSK-Trigger hinzufügen möchten.
-
Wählen Sie unter Function overview (Funktionsübersicht) die Option Add trigger (Trigger hinzufügen).
-
Wählen Sie unter Trigger-Konfiguration die Option MSK aus.
-
Gehen Sie wie folgt vor, um Ihre Kafka-Cluster-Details anzugeben:
-
Wählen Sie für MSK-Cluster Ihren Cluster aus.
-
Geben Sie als Themenname den Namen des Kafka-Themas ein, von dem Nachrichten abgerufen werden sollen.
-
Geben Sie unter Nutzergruppen-ID gegebenenfalls die ID einer Kafka-Verbrauchergruppe ein, der Sie beitreten möchten. Weitere Informationen finden Sie unter Anpassbare Konsumentengruppen-ID.
-
-
Nehmen Sie für die Cluster-Authentifizierung die erforderlichen Konfigurationen vor. Weitere Informationen zur Clusterauthentifizierung finden Sie unterKonfiguration von Cluster-Authentifizierungsmethoden.
-
Aktivieren Sie Authentifizierung verwenden, wenn Lambda beim Verbindungsaufbau die Authentifizierung mit Ihrem MSK-Cluster durchführen soll. Eine Authentifizierung wird empfohlen.
-
Wenn Sie Authentifizierung verwenden, wählen Sie unter Authentifizierungsmethode die zu verwendende Authentifizierungsmethode aus.
-
Wenn Sie Authentifizierung verwenden, wählen Sie als Secrets Manager Manager-Schlüssel den Secrets Manager Manager-Schlüssel, der die für den Zugriff auf Ihren Cluster erforderlichen Authentifizierungsdaten enthält.
-
-
Nehmen Sie unter Event Poller-Konfiguration die erforderlichen Konfigurationen vor.
-
Wählen Sie Trigger aktivieren, um den Trigger unmittelbar nach der Erstellung zu aktivieren.
-
Wählen Sie aus, ob Sie den Bereitstellungsmodus für Ihre Ereignisquellenzuordnung konfigurieren möchten. Weitere Informationen finden Sie unter Skalierungsmodi für den Event-Poller.
-
Wenn Sie den Bereitstellungsmodus konfigurieren, geben Sie einen Wert für Minimale Anzahl an Ereignisabfragen, einen Wert für Maximale Anzahl an Ereignisabfragen oder beide Werte ein.
-
-
Wählen Sie unter Startposition aus, wie Lambda mit dem Lesen aus Ihrem Stream beginnen soll. Weitere Informationen finden Sie unter Startpositionen für Abfragen und Streams.
-
-
Nehmen Sie unter Batching die erforderlichen Konfigurationen vor. Weitere Informationen zur Batchverarbeitung finden Sie unter. Batching-Verhalten
-
Geben Sie für Batchgröße die maximale Anzahl von Nachrichten ein, die in einem einzelnen Batch empfangen werden sollen.
-
Geben Sie für Batchfenster die maximale Anzahl von Sekunden ein, die Lambda mit dem Sammeln von Datensätzen verbringt, bevor die Funktion aufgerufen wird.
-
-
Nehmen Sie unter Filterung die erforderlichen Konfigurationen vor. Weitere Informationen zur Filterung erhalten Sie unter Verwendung der Ereignisfilterung mit einer Amazon MSK-Ereignisquelle.
-
Fügen Sie unter Filterkriterien Definitionen für Filterkriterien hinzu, um zu bestimmen, ob ein Ereignis verarbeitet werden soll oder nicht.
-
-
Nehmen Sie unter Fehlerbehandlung die erforderlichen Konfigurationen vor. Weitere Hinweise zur Fehlerbehandlung finden Sie unterErfassen von verworfenen Chargen für eine Amazon MSK Ereignisquelle.
-
Geben Sie für Ziel bei Ausfall den ARN Ihres Ziels bei einem Ausfall an.
-
-
Geben Sie unter Tags die Tags ein, die dieser Ereignisquellenzuordnung zugeordnet werden sollen.
-
Wählen Sie hinzufügen aus, um den Auslöser zu erstellen.
Sie können die Ereignisquellenzuordnung auch mithilfe der AWS CLI mit dem create-event-source-mappingmy-msk-function ausgehend von der LATEST Nachricht dem AWSKafkaTopic Thema zuzuordnen. Dieser Befehl verwendet das SourceAccessConfigurationObjekt auch, um Lambda anzuweisen, bei der Verbindung mit dem Cluster die SASL/SCRAM-Authentifizierung zu verwenden.
aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function --source-access-configurations '[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]'
Wenn der Cluster mTLS-Authentifizierung verwendet, fügen Sie ein SourceAccessConfigurationObjekt hinzu, das einen Secrets Manager Manager-Schlüssel-ARN spezifiziertCLIENT_CERTIFICATE_TLS_AUTH. Dies wird im folgenden Befehl gezeigt:
aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function --source-access-configurations '[{"Type": "CLIENT_CERTIFICATE_TLS_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]'
Wenn der Cluster die IAM-Authentifizierung verwendet, benötigen Sie kein SourceAccessConfigurationObjekt. Dies wird im folgenden Befehl gezeigt:
aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function
Konfiguration von Cluster-Authentifizierungsmethoden
Lambda benötigt die Erlaubnis, auf Ihren Amazon MSK-Cluster zuzugreifen, Datensätze abzurufen und andere Aufgaben auszuführen. Amazon MSK unterstützt mehrere Methoden zur Authentifizierung bei Ihrem MSK-Cluster.
Methoden zur Cluster-Authentifizierung
Nicht authentifizierter Zugriff
Wenn keine Clients über das Internet auf den Cluster zugreifen, können Sie einen nicht authentifizierten Zugriff verwenden.
SASL/SCRAM-Authentifizierung
Lambda unterstützt die Authentifizierung (Simple Authentication and SecurityLayer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) mit der SHA-512-Hash-Funktion und der Transport Layer Security (TLS) -Verschlüsselung. Damit Lambda eine Verbindung zum Cluster herstellen kann, speichern Sie die Authentifizierungsdaten (Benutzername und Passwort) in einem Secrets Manager-Geheimnis und verweisen Sie bei der Konfiguration Ihrer Ereignisquellenzuordnung auf dieses Geheimnis.
Weitere Informationen zur Verwendung von Secrets Manager finden Sie unter Authentifizierung von Anmeldedaten mit Secrets Manager im Amazon Managed Streaming for Apache Kafka Developer Guide.
Anmerkung
Amazon MSK unterstützt keine SASL/PLAIN-Authentifizierung.
Gegenseitige TLS-Authentifizierung
Mutual TLS (mTLS) ermöglicht eine bidirektionale Authentifizierung zwischen dem Client und dem Server. Der Client sendet ein Zertifikat an den Server, damit der Server den Client verifizieren kann. Der Server sendet außerdem ein Zertifikat an den Client, damit der Client den Server verifizieren kann.
Bei Amazon MSK-Integrationen mit Lambda fungiert Ihr MSK-Cluster als Server und Lambda als Client.
-
Damit Lambda Ihren MSK-Cluster verifizieren kann, konfigurieren Sie ein Client-Zertifikat als Secret in Secrets Manager und verweisen in Ihrer Konfiguration für die Zuordnung von Ereignisquellen auf dieses Zertifikat. Das Client-Zertifikat muss von einer Zertifizierungsstelle (CA) im Trust Store des Servers signiert werden.
-
Der MSK-Cluster sendet auch ein Serverzertifikat an Lambda. Das Serverzertifikat muss von einer Zertifizierungsstelle (CA) im AWS Trust Store signiert werden.
Amazon MSK unterstützt keine selbstsignierten Serverzertifikate. Alle Broker in Amazon MSK verwenden öffentliche Zertifikate, die von Amazon Trust Services
Das Secret CLIENT_CERTIFICATE_TLS_AUTH erfordert ein Zertifikatfeld und ein Feld für einen privaten Schlüssel. Für einen verschlüsselten privaten Schlüssel erfordert das Secret ein Passwort für den privaten Schlüssel. Sowohl das Zertifikat als auch der private Schlüssel müssen im PEM-Format vorliegen.
Anmerkung
Lambda unterstützt die Verschlüsselungsalgorithmen mit privaten Schlüsseln PBES1
Das Zertifikatfeld muss eine Liste von Zertifikaten enthalten, beginnend mit dem Client-Zertifikat, gefolgt von etwaigen Zwischenzertifikaten und endend mit dem Root-Zertifikat. Jedes Zertifikat muss in einer neuen Zeile mit der folgenden Struktur beginnen:
-----BEGIN CERTIFICATE----- <certificate contents> -----END CERTIFICATE-----
Secrets Manager unterstützt Secrets von bis zu 65 536 Bytes, was genügend Platz für lange Zertifikatsketten bietet.
Der private Schlüssel muss im Format PKCS #8
-----BEGIN PRIVATE KEY----- <private key contents> -----END PRIVATE KEY-----
Verwenden Sie für einen verschlüsselten privaten Schlüssel die folgende Struktur:
-----BEGIN ENCRYPTED PRIVATE KEY----- <private key contents> -----END ENCRYPTED PRIVATE KEY-----
Im folgenden Beispiel sehen Sie den Inhalt eines Secrets für mTLS-Authentifizierung mit einem verschlüsselten privaten Schlüssel. Fügen Sie für einen verschlüsselten privaten Schlüssel das Passwort für den privaten Schlüssel in das Secret ein.
{ "privateKeyPassword": "testpassword", "certificate": "-----BEGIN CERTIFICATE----- MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw ... j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk cmUuiAii9R0= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb ... rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg== -----END CERTIFICATE-----", "privateKey": "-----BEGIN ENCRYPTED PRIVATE KEY----- MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp ... QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA== -----END ENCRYPTED PRIVATE KEY-----" }
Weitere Informationen zu mTLS für Amazon MSK und Anweisungen zum Generieren eines Client-Zertifikats finden Sie unter Gegenseitige TLS-Client-Authentifizierung für Amazon MSK im Amazon Managed Streaming for Apache Kafka Developer Guide.
IAM-Authentifizierung
Sie können AWS Identity and Access Management (IAM) verwenden, um die Identität von Clients zu authentifizieren, die eine Verbindung zum MSK-Cluster herstellen. Bei der IAM-Authentifizierung stützt sich Lambda auf die Berechtigungen in der Ausführungsrolle Ihrer Funktion, um eine Verbindung zum Cluster herzustellen, Datensätze abzurufen und andere erforderliche Aktionen auszuführen. Eine Beispielrichtlinie, die die erforderlichen Berechtigungen enthält, finden Sie unter Autorisierungsrichtlinien für die IAM-Rolle erstellen im Amazon Managed Streaming for Apache Kafka Developer Guide.
Wenn die IAM-Authentifizierung in Ihrem MSK-Cluster aktiv ist und Sie kein Geheimnis angeben, verwendet Lambda standardmäßig automatisch die IAM-Authentifizierung.
Weitere Informationen zur IAM-Authentifizierung in Amazon MSK finden Sie unter IAM-Zugriffskontrolle.
So wählt Lambda einen Bootstrap-Broker
Lambda wählt einen Bootstrap-Broker basierend auf den auf Ihrem Cluster verfügbaren Authentifizierungsmethoden aus und ob Sie ein Geheimnis für die Authentifizierung angeben.. Wenn Sie ein Geheimnis für MTLs oder SASL/SCRAM angeben, wählt Lambda automatisch diese Authentifizierungsmethode. Wenn Sie kein Geheimnis angeben, wählt Lambda die stärkste Authentifizierungsmethode aus, die in Ihrem Cluster aktiv ist. Im Folgenden ist die Reihenfolge der Priorität aufgeführt, in der Lambda einen Broker auswählt, von der stärksten zur schwächsten Authentifizierung:
mTLS (Geheimnis für mTLS bereitgestellt)
SASL/SCRAM (secret provided for SASL/SCRAM)
SASL IAM (kein Geheimnis angegeben und IAM-Authentifizierung aktiv)
Nicht authentifiziertes TLS (kein Geheimnis bereitgestellt und IAM-Authentifizierung nicht aktiv)
Klartext (kein Geheimnis angegeben und sowohl IAM-Authentifizierung als auch nicht authentifiziertes TLS sind nicht aktiv)
Anmerkung
Wenn Lambda keine Verbindung zum sichersten Brokertyp herstellen kann, versucht Lambda nicht, eine Verbindung zu einem anderen (schwächeren) Brokertyp herzustellen. Wenn Sie möchten, dass Lambda einen schwächeren Brokertyp wählt, deaktivieren Sie alle stärkeren Authentifizierungsmethoden in Ihrem Cluster.
Anpassbare Konsumentengruppen-ID
Wenn Sie Kafka als Ereignisquelle einrichten, können Sie eine Benutzergruppen-ID angeben.
Kafka verteilt Nachrichten an alle Verbraucher in einer Verbrauchergruppe. Wenn Sie eine Nutzergruppen-ID angeben, die andere aktive Verbraucher hat, empfängt Lambda nur einen Teil der Nachrichten aus dem Kafka-Thema. Wenn Sie möchten, dass Lambda alle Nachrichten im Thema verarbeitet, schalten Sie alle anderen Verbraucher in dieser Verbrauchergruppe aus.
Wenn Sie außerdem eine Nutzergruppen-ID angeben und Kafka eine gültige bestehende Nutzergruppe mit derselben ID findet, ignoriert Lambda die StartingPositionfür Ihre Ereignisquellenzuordnung. 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.
Startpositionen für Abfragen und Streams
Der StartingPosition Parameter teilt Lambda mit, wann mit dem Lesen von Nachrichten aus Ihrem Stream begonnen werden soll. Es stehen drei Optionen zur Auswahl:
-
Aktuell — Lambda beginnt unmittelbar nach dem neuesten Datensatz im Kafka-Thema mit dem Lesen.
-
Horizont kürzen — Lambda beginnt mit dem Lesen ab dem letzten unbeschnittenen Datensatz im Kafka-Thema. Dies ist auch der älteste Datensatz in diesem Thema.
-
Beim Zeitstempel — Lambda beginnt mit dem Lesen an einer durch einen Zeitstempel definierten Position in Unix-Zeitsekunden. Verwenden Sie den StartingPositionTimestamp Parameter, um den Zeitstempel anzugeben.
Die Stream-Abfrage während der Erstellung oder Aktualisierung einer Ereignisquellenzuordnung ist letztendlich konsistent:
-
Bei der Erstellung der Zuordnung von Ereignisquellen kann es mehrere Minuten dauern, bis mit der Abfrage von Ereignissen aus dem Stream begonnen wird.
-
Bei Aktualisierungen der Ereignisquellenzuordnungen kann es bis zu 90 Sekunden dauern, bis das Abrufen von Ereignissen aus dem Stream beendet und erneut gestartet wird.
Dieses Verhalten bedeutet, dass, wenn Sie die Startposition für den Stream angebenLATEST, bei der Zuordnung der Ereignisquellen Ereignisse während einer Erstellung oder Aktualisierung übersehen werden könnten. Um sicherzustellen, dass keine Ereignisse übersehen werden, geben Sie entweder TRIM_HORIZON oder anAT_TIMESTAMP.
Skalierungsmodi für den Event-Poller
Sie können zwischen zwei Modi der Event-Poller-Skalierung für Ihr Kafka-Event-Quellen-Mapping wählen:
Skalierungsmodi
On-Demand-Modus (Standard)
Wenn Sie anfänglich eine Amazon MSK-Ereignisquelle erstellen, weist Lambda eine Standardanzahl von Ereignis-Pollern zu, um alle Partitionen im Kafka-Thema zu verarbeiten. Lambda skaliert die Anzahl der Event-Poller basierend auf der Nachrichtenlast automatisch nach oben oder unten.
In Intervallen von einer Minute wertet Lambda den Offset-Lag aller Partitionen des Themas 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.
Modus bereitgestellter Kapazität
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. 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 Amazon MSK-Zuordnung von Ereignisquellen über die Konsole oder die Lambda-API konfigurieren.
So konfigurieren Sie den Modus bereitgestellter Kapazität für eine Zuordnung von Ereignisquellen von Amazon MSK (Konsole)
-
Öffnen Sie die Seite Funktionen
der Lambda-Konsole. -
Wählen Sie die Funktion mit der Amazon MSK-Zuordnung von Ereignisquellen aus, für die Sie den Bereitstellungsmodus konfigurieren möchten.
-
Wählen Sie Konfiguration und anschließend Auslöser aus.
-
Wählen Sie die Amazon MSK-Zuordnung von Ereignisquellen, für die Sie den Bereitstellungsmodus konfigurieren möchten und wählen Sie dann Bearbeiten.
-
Wählen Sie unter Konfiguration der Zuordnung von Ereignisquellen die Option Bereitstellungsmodus konfigurieren aus.
-
Geben Sie für Minimum Event Pollers einen Wert zwischen 1 und 200 ein. Wenn Sie keinen Wert angeben, wählt Lambda einen Standardwert von 1.
-
Geben Sie für Maximum Event Pollers einen Wert zwischen 1 und 2000 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 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.
Erstellen von kontenübergreifenden Zuordnungen von Ereignisquellen
Sie können private Multi-VPC-Konnektivität verwenden, um eine Lambda-Funktion mit einem bereitgestellten MSK-Cluster in einem anderen AWS-Konto zu verbinden. Multi-VPC-Konnektivität verwendet AWS PrivateLink, wodurch der gesamte Datenverkehr im AWS Netzwerk bleibt.
Anmerkung
Sie können keine kontenübergreifenden Zuordnungen von Ereignisquellen für Serverless-MSK-Cluster erstellen.
Um eine kontenübergreifende Zuordnung von Ereignisquellen zu erstellen, müssen Sie zunächst die Multi-VPC-Konnektivität für den MSK-Cluster konfigurieren. Verwenden Sie beim Erstellen der Zuordnung von Ereignisquellen den ARN der verwalteten VPC-Verbindung anstelle des Cluster-ARNs, wie in den folgenden Beispielen gezeigt. Der CreateEventSourceMappingVorgang unterscheidet sich auch je nachdem, welchen Authentifizierungstyp der MSK-Cluster verwendet.
Beispiel – Erstellen Sie eine kontoübergreifende Zuordnung von Ereignisquellen für einen Cluster, der die IAM-Authentifizierung verwendet
Wenn der Cluster die rollenbasierte IAM-Authentifizierung verwendet, benötigen Sie kein Objekt. SourceAccessConfiguration Beispiel:
aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7\ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function
Beispiel – Erstellen Sie eine kontoübergreifende Zuordnung von Ereignisquellen für einen Cluster, der die SASL/SCRAM-Authentifizierung verwendet
Wenn der Cluster die SASL/SCRAM-Authentifizierung verwendet, müssen Sie ein SourceAccessConfigurationObjekt angeben, das einen geheimen Secrets Manager Manager-ARN spezifiziert, SASL_SCRAM_512_AUTH und einen geheimen ARN hinzufügen.
Es gibt zwei Möglichkeiten, Secrets für kontenübergreifende Zuordnungen von Amazon-MSK-Ereignisquellen mit SASL/SCRAM-Authentifizierung zu verwenden:
-
Erstellen Sie ein Secret im Lambda-Funktionskonto und synchronisieren Sie es mit dem Cluster-Secret. Erstellen Sie eine Rotation, um die beiden Secrets synchron zu halten. Mit dieser Option können Sie das Secret vom Funktionskonto aus kontrollieren.
-
Verwenden Sie das Secret, das dem MSK-Cluster zugeordnet ist. Dieses Secret muss kontoübergreifenden Zugriff auf das Lambda-Funktionskonto ermöglichen. Weitere Informationen finden Sie unter Berechtigungen für AWS Secrets Manager -Secrets für Benutzer in einem anderen Konto.
aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7\ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function \ --source-access-configurations'[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:444455556666:secret:my-secret"}]'
Beispiel – Erstellen Sie eine kontoübergreifende Zuordnung von Ereignisquellen für einen Cluster, der die mTLS-Authentifizierung verwendet
Wenn der Cluster mTLS-Authentifizierung verwendet, müssen Sie ein SourceAccessConfigurationObjekt angeben, das einen geheimen ARN von Secrets Manager spezifiziertCLIENT_CERTIFICATE_TLS_AUTH. Das Secret kann im Clusterkonto oder im Lambda-Funktionskonto gespeichert werden.
aws lambda create-event-source-mapping \ --event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7\ --topics AWSKafkaTopic \ --starting-position LATEST \ --function-name my-kafka-function \ --source-access-configurations'[{"Type": "CLIENT_CERTIFICATE_TLS_AUTH","URI": "arn:aws:secretsmanager:us-east-1:444455556666:secret:my-secret"}]'
Alle Konfigurationsparameter für Amazon MSK-Ereignisquellen
Alle Lambda-Ereignisquelltypen verwenden dieselben CreateEventSourceMappingUpdateEventSourceMappingAPI-Operationen. Allerdings gelten nur einige der Parameter für Amazon MSK, wie in der folgenden Tabelle dargestellt.
| Parameter | Erforderlich | Standard | Hinweise |
|---|---|---|---|
|
AmazonManagedKafkaEventSourceConfig |
N |
Enthält das ConsumerGroupId Feld, das standardmäßig einen eindeutigen Wert hat. |
Kann nur auf „Erstellen“ festgelegt werden |
|
BatchSize |
N |
100 |
Höchstwert: 10 000. |
|
DestinationConfig |
N |
N/A |
Erfassen von verworfenen Chargen für eine Amazon MSK Ereignisquelle |
|
Aktiviert |
N |
True |
|
|
EventSourceArn |
Y |
N/A |
Kann nur auf „Erstellen“ festgelegt werden |
|
FilterCriteria |
N |
N/A |
Steuern Sie, welche Ereignisse Lambda an Ihre Funktion sendet |
|
FunctionName |
Y |
N/A |
|
|
KMSKeyArn |
N |
N/A |
|
|
MaximumBatchingWindowInSeconds |
N |
500 ms |
|
|
ProvisionedPollersConfig |
N |
|
|
|
SourceAccessConfigurations |
N |
Keine Anmeldedaten |
Anmeldeinformationen zur SASL/SCRAM- oder CLIENT_CERTIFICATE_TLS_AUTH (MutualTLS)-Authentifizierung für Ihre Ereignisquelle |
|
StartingPosition |
Y |
N/A |
AT_TIMESTAMP, TRIM_HORIZON, oder LATEST Kann nur auf „Erstellen“ festgelegt werden |
|
StartingPositionTimestamp |
N |
N/A |
Erforderlich, wenn auf StartingPosition AT_TIMESTAMP gesetzt ist |
|
Tags |
N |
N/A |
|
|
Themen |
Y |
N/A |
Kafka-Thema-Name Kann nur auf „Erstellen“ festgelegt werden |
