Verwenden von Lambda mit Amazon MQ - AWS Lambda
Verstehen der Lambda-Verbrauchergruppe für Amazon MQ

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 MQ

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.

Amazon MQ ist ein verwalteter Message-Broker-Service für Apache ActiveMQ und RabbitMQ. Mit einem Message Broker können Software-Anwendungen und -Komponenten mithilfe verschiedener Programmiersprachen, Betriebssysteme und formeller Messaging-Protokolle entweder über Themen- oder Queue-Ereigniszielen miteinander kommunizieren.

Amazon MQ kann auch Amazon Elastic Compute Cloud (Amazon EC2) -Instances in Ihrem Namen verwalten, indem es ActiveMQ- oder RabbitMQ-Broker installiert und verschiedene Netzwerktopologien und andere Infrastrukturanforderungen bereitstellt.

Verwenden Sie eine Lambda-Funktion, um Datensätze von Ihrem Amazon-MQ-Message-Broker zu verarbeiten. Lambda ruft Ihre Funktion über ein Ereignisquellen-Zuweisung auf, eine Lambda-Ressource, die Nachrichten von Ihrem Broker liest und die Funktion synchron aufruft.

Warnung

Zuordnungen 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?. AWS

Das Amazon-MQ-Ereignisquellen-Zuweisung hat die folgenden Konfigurationseinschränkungen:

  • Parallelität – Lambda-Funktionen, die eine Amazon MQ-Zuordnung von Ereignisquellen verwenden, haben eine Standardeinstellung für maximale Parallelität. Für ActiveMQ begrenzt der Lambda-Service die Anzahl der gleichzeitigen Ausführungsumgebungen auf fünf pro Amazon MQ-Zuordnung von Ereignisquellen. Für RabbitMQ ist die Anzahl der gleichzeitigen Ausführungsumgebungen auf 1 pro Amazon MQ-Zuordnung von Ereignisquellen begrenzt. Selbst wenn Sie die reservierten oder bereitgestellten Parallelitätseinstellungen Ihrer Funktion ändern, stellt der Lambda-Service keine weiteren Ausführungsumgebungen zur Verfügung. Um eine Erhöhung der standardmäßigen maximalen Parallelität für eine einzelne Amazon MQ MQ-Ereignisquellenzuordnung zu beantragen, wenden Sie sich an Support die UUID der Ereignisquellenzuweisung sowie an die Region. Da Erhöhungen auf der Ebene der spezifischen Zuordnung von Ereignisquellen und nicht auf der Ebene des Kontos oder der Region vorgenommen werden, müssen Sie für jede Zuordnung von Ereignisquellen manuell eine Skalierungserhöhung anfordern.

  • Kontoübergreifend – Lambda unterstützt keine kontoübergreifende Verarbeitung. Sie können Lambda nicht zur Verarbeitung von Datensätzen von einem Amazon-MQ-Message Broker verwenden, der sich in einem anderen  AWS-Konto befindet.

  • Authentifizierung — Für ActiveMQ wird nur SimpleAuthenticationPluginActiveMQ unterstützt. Für RabbitMQ wird nur der PLAIN-Authentifizierungsmechanismus unterstützt. Benutzer müssen zur Verwaltung ihrer Anmeldeinformationen verwenden AWS Secrets Manager . Weitere Informationen zur ActiveMQ-Authentifizierung finden Sie unter Integrieren von ActiveMQ-Brokern mit LDAP im Amazon-MQ-Entwicklerhandbuch.

  • Verbindungskontingent – Broker haben eine maximale Anzahl zulässiger Verbindungen pro Wire-Level-Protokoll. Dieses Kontingent basiert auf dem Instance-Typ des Brokers. Weitere Informationen finden Sie im Abschnitt Broker in Kontingente in Amazon MQ im Amazon-MQ-Entwicklerhandbuch.

  • Konnektivität – Sie können Broker in einer öffentlichen oder privaten Virtual Private Cloud (VPC) erstellen. Für private Zwecke VPCs benötigt Ihre Lambda-Funktion Zugriff auf die VPC, um Nachrichten zu empfangen. Weitere Informationen finden Sie unter Konfigurieren Sie die Netzwerksicherheit, weiter unten in diesem Abschnitt.

  • Ereignisziele – Es werden nur Warteschlangenziele unterstützt. Sie können jedoch ein virtuelles Thema verwenden, das sich intern wie ein Thema verhält, während es mit Lambda als eine Warteschlange interagiert. Weitere Informationen finden Sie unter virtuelle Ziele auf der Apache-ActiveMQ-Website und virtuelle Hosts auf der RabbitMQ-Website.

  • Netzwerktopologie – Für ActiveMQ wird nur ein Einzelinstance- oder Standby-Broker pro Ereignisquellen-Zuweisung unterstützt. Für RabbitMQ wird nur eine Einzelinstance-Broker- oder Cluster-Bereitstellung pro Ereignisquellen-Zuweisung unterstützt. Single-Instance-Broker benötigen einen Failover-Endpunkt. Weitere Informationen zu diesen Broker-Bereitstellungsmodi finden Sie unter Aktive MQ-Broker-Architektur und Broker-Architektur von Rabbit MQ im Entwicklerhandbuch für Amazon MQ.

  • Protokolle – Die unterstützten Protokolle hängen vom Typ der Amazon-MQ-Integration ab.

    • Für ActiveMQ-Integrationen verwendet Lambda Nachrichten mithilfe des OpenWire /Java Message Service (JMS) -Protokolls. Es werden keine anderen Protokolle unterstützt, um Nachrichten zu verbrauchen. Innerhalb des JMS-Protokolls werden nur TextMessage und BytesMessage unterstützt. Lambda unterstützt auch benutzerdefinierte JMS-Eigenschaften. Weitere Informationen zum OpenWire Protokoll finden Sie OpenWireauf der Apache ActiveMQ-Website.

    • Bei RabbitMQ-Integrationen verbraucht Lambda Nachrichten mit dem AMQP-0-9-1-Protokoll. Es werden keine anderen Protokolle unterstützt, um Nachrichten zu verbrauchen. Weitere Informationen zur Implementierung des AMQP 0-9-1-Protokolls durch RabbitMQ finden Sie im Kompletten AMQ-0-9-1-Referenzhandbuch auf der RabbitMQ-Website.

Lambda unterstützt automatisch die neuesten Versionen von ActiveMQ und RabbitMQ, die Amazon MQ unterstützt. Die neuesten unterstützten Versionen finden Sie in den Amazon-MQ-Versionshinweisen im Amazon-MQ-Entwicklerhandbuch.

Anmerkung

Amazon MQ hat standardmäßig ein wöchentliches Wartungsfenster für Broker. Während dieses Zeitfensters sind Broker nicht verfügbar. Für Broker ohne Standby kann Lambda während dieses Fensters keine Nachrichten verarbeiten.

Themen

Verstehen der Lambda-Verbrauchergruppe für Amazon MQ

Um mit Amazon MQ zu interagieren, erstellt Lambda eine Verbrauchergruppe, die aus Ihren Amazon-MQ-Brokern lesen kann. Die Verbrauchergruppe wird mit derselben ID wie die Ereignisquellen-Zuweisung-UUID erstellt.

Für Amazon-MQ-Ereignisquellen batcht Lambda Datensätze und sendet sie in einer einzigen Nutzlast an Ihre Funktion. Um das Verhalten zu steuern, können Sie das Batch-Fenster und die Batch-Größe konfigurieren. Lambda pullt Nachrichten, bis es die Nutzlastgröße von maximal 6 MB verarbeitet, das Batch-Fenster abläuft oder die Anzahl der Datensätze die volle Batch-Größe erreicht. Weitere Informationen finden Sie unter Batching-Verhalten.

Die Konsumentengruppe ruft die Nachrichten als ein BLOB von Bytes ab, base64-codiert sie dann in eine einzelne JSON-Nutzlast und ruft dann Ihre Funktion auf. 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.

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. Diese Einschränkung stellt sicher, dass die Ereignisquellenzuordnung Funktionsfehler und Wiederholungsversuche ordnungsgemäß verarbeiten kann.

Sie können die Parallelitätsnutzung einer bestimmten Funktion mithilfe der ConcurrentExecutions Metrik in Amazon CloudWatch überwachen. Weitere Hinweise zur Gleichzeitigkeitsskalierung finden Sie unter Konfigurieren reservierter Gleichzeitigkeit für eine Funktion.

Beispiel Amazon-MQ-Datensatzereignisse
ActiveMQ
{
   "eventSource": "aws:mq",
   "eventSourceArn": "arn:aws:mq:us-east-2:111122223333:broker:test:b-9bcfa592-423a-4942-879d-eb284b418fc8",
   "messages": [
      { 
        "messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1", 
        "messageType": "jms/text-message",
        "deliveryMode": 1,
        "replyTo": null,
        "type": null,
        "expiration": "60000",
        "priority": 1,
        "correlationId": "myJMSCoID",
        "redelivered": false,
        "destination": { 
          "physicalName": "testQueue" 
        },
        "data":"QUJDOkFBQUE=",
        "timestamp": 1598827811958,
        "brokerInTime": 1598827811958, 
        "brokerOutTime": 1598827811959, 
        "properties": {
          "index": "1",
          "doAlarm": "false",
          "myCustomProperty": "value"
        }
      },
      { 
        "messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1",
        "messageType": "jms/bytes-message",
        "deliveryMode": 1,
        "replyTo": null,
        "type": null,
        "expiration": "60000",
        "priority": 2,
        "correlationId": "myJMSCoID1",
        "redelivered": false,
        "destination": { 
          "physicalName": "testQueue" 
        },
        "data":"LQaGQ82S48k=",
        "timestamp": 1598827811958,
        "brokerInTime": 1598827811958, 
        "brokerOutTime": 1598827811959, 
        "properties": {
          "index": "1",
          "doAlarm": "false",
          "myCustomProperty": "value"
        }
      }
   ]
}
RabbitMQ

{
  "eventSource": "aws:rmq",
  "eventSourceArn": "arn:aws:mq:us-east-2:111122223333:broker:pizzaBroker:b-9bcfa592-423a-4942-879d-eb284b418fc8",
  "rmqMessagesByQueue": {
    "pizzaQueue::/": [
      {
        "basicProperties": {
          "contentType": "text/plain",
          "contentEncoding": null,
          "headers": {
            "header1": {
              "bytes": [
                118,
                97,
                108,
                117,
                101,
                49
              ]
            },
            "header2": {
              "bytes": [
                118,
                97,
                108,
                117,
                101,
                50
              ]
            },
            "numberInHeader": 10
          },
          "deliveryMode": 1,
          "priority": 34,
          "correlationId": null,
          "replyTo": null,
          "expiration": "60000",
          "messageId": null,
          "timestamp": "Jan 1, 1970, 12:33:41 AM",
          "type": null,
          "userId": "AIDACKCEVSQ6C2EXAMPLE",
          "appId": null,
          "clusterId": null,
          "bodySize": 80
        },
        "redelivered": false,
        "data": "eyJ0aW1lb3V0IjowLCJkYXRhIjoiQ1pybWYwR3c4T3Y0YnFMUXhENEUifQ=="
      }
    ]
  }
}
Anmerkung

Im RabbitMQ-Beispiel ist pizzaQueue der Name der RabbitMQ-Warteschlange und / der Name des virtuellen Hosts. Beim Empfang von Nachrichten listet die Ereignisquelle Nachrichten unter pizzaQueue::/ auf.