Warum dauert es so lange, bis die asynchronen Ereignisquellen meine Lambda-Funktion auslösen?

Kurzbeschreibung

Wenn Sie asynchrone Aufrufe mit Ihren Lambda-Funktionen verwenden, stellen Sie möglicherweise fest, dass das Auslösen Ihrer Ereignisse länger dauert als erwartet. Auch kann es vorkommen, dass Ihre Ereignisse an die Warteschlange für unzustellbare Nachrichten (Dead-Letter Queue, DLQ) gesendet werden, ohne vom Lambda-Service zur weiteren Verarbeitung abgerufen zu werden.

Es gibt verschiedene AWS-Services, die Lambda-Funktionen asynchron aufrufen:

• Amazon Simple Storage Service (Amazon S3)
• Amazon Simple Notification Service (Amazon SNS)
• Amazon Simple Email Service (Amazon SES)
• AWS CloudFormation
• Amazon CloudWatch Logs
• Amazon CloudWatch Events
• AWS CodeCommit
• AWS Config

Lösung

Verzögerungen beim Aufrufen

Im Allgemeinen kann es aufgrund der asynchronen Behandlung von Anforderungen zu Verzögerungen kommen.

• Wenn Sie eine Anforderung übermitteln, wird sie an eine interne asynchrone Warteschlange gesendet. Lambda ruft Anforderungen aus der internen asynchronen Warteschlange ab und sendet die Anforderung dann zur weiteren Verarbeitung an die Lambda-Funktion. Falls im Zusammenhang mit Ihrer Lambda-Funktion Fehler auftreten, kann es zu einer Verzögerung in Amazon CloudWatch Logs für Ihre Funktion kommen. Verzögerungen können auch auftreten, wenn die Anforderungen auf Funktionsebene gedrosselt werden.
• Wenn auf Funktionsebene keine Fehler- oder Drosselungsdatenpunkte vorliegen, überprüfen Sie die Metriken auf regionaler Ebene auf Fehler und Drosselungen. Wenn andere Funktionen asynchron aufgerufen werden und Fehler auftreten, kommt es bei diesen Funktionen zu erheblichen Verzögerungen. Das bedeutet: Auch wenn für Ihre Funktion keine Fehler- oder Drosselungsdatenpunkte vorhanden sind, können sich die Aufrufe oder Anforderungen für die Funktion trotzdem verzögern.
• Wenn andere Funktionen, die sich in der gleichen Region befinden wie Ihre Lambda-Funktion, mehrmals asynchron aufgerufen werden, führt dies zu einem Stau in der internen Warteschlange. Erhöhen Sie zur Lösung dieses Problems die Gleichzeitigkeit auf regionaler Ebene.
• Aktivieren Sie AWS X-Ray für Ihre Lambda-Funktion, um den Rückstand der internen Warteschlange zu überprüfen. Wenn AWS X-Ray aktiviert ist, können Sie die Verweildauereigenschaft nutzen. Diese Eigenschaft zeigt, wie lange sich Anforderungen insgesamt in der internen Warteschlange befinden, bevor der Lambda-Service sie zur Verarbeitung an die Lambda-Funktion sendet.
• Richten Sie eine funktionsspezifische Gleichzeitigkeit (oder reservierte Gleichzeitigkeit) ein, um Funktionen vor einem Warteschlangenstau zu schützen.

Doppelter Aufruf

Lambda ist ein verteilter Dienst und stellt sicher, dass Ihre Funktion mindestens einmal aufgerufen wird. Wenn die Funktion jedoch mehr als einmal aufgerufen wird, kann es zu Duplikaten kommen. Überprüfen Sie die CloudWatch-Protokolle auf solche doppelten Aufrufe.

• Es empfiehlt sich, dafür zu sorgen, dass Ihre Funktion doppelte Anforderungen behandeln kann. Weitere Informationen finden Sie unter Wie mache ich meine Lambda-Funktion idempotent?
• Sehen Sie sich die CloudWatch-Protokolle für Lambda an und überprüfen Sie die Anforderungs-IDs für Ihre Funktion. Anhand der Protokolle können Sie überprüfen, ob doppelte Ereignisse die gleiche Anforderungs-ID besitzen. Anforderungs-IDs bleiben während des gesamten Lebenszyklus eines asynchronen Aufrufs für Lambda gleich. Sind die Anforderungs-IDs identisch, überprüfen Sie, ob für die Funktion Fehlerdatenpunkte vorhanden sind, die dazu geführt haben, dass der Aufruf wiederholt und dupliziert wurde.
• Sind die Anforderungs-IDs unterschiedlich, handelt es sich um clientseitige doppelte Aufrufe.

Fehlende Aufrufe

Sehen Sie sich die CloudWatch-Protokolle an, um zwischen fehlenden und verzögerten Aufrufen zu unterscheiden. Folgen Sie bei verzögerten Aufrufen den Schritten, die weiter oben in diesem Artikel im Abschnitt „Verzögerte Aufrufe“ beschrieben wurden.

Fehlende Aufrufe treten auf, wenn nicht genügend Gleichzeitigkeit vorhanden ist, um die Anforderung zu verarbeiten. Wenn die Funktion über reservierte Gleichzeitigkeit verfügt und Fehler auftreten, bleibt die Anforderung sehr lange in der asynchronen Warteschlange. Die Anforderung wird dann gelöscht, ohne von Lambda verarbeitet zu werden. Sehen Sie sich die Metrik AsyncEventsDropped an, um die Anzahl von Ereignissen zu überprüfen, die gelöscht wurden, ohne die Funktion auszuführen.

Wenn Sie eine Warteschlange für unzustellbare Nachrichten konfiguriert haben, überprüfen Sie diese Warteschlange oder das Ziel für nicht erfolgreiche Verarbeitungen auf die Anforderung. Wenn ein Ereignis in der internen Warteschlange nach sechs Stunden abläuft, kann die Anforderung an die Warteschlange für unzustellbare Nachrichten gesendet werden, ohne von Lambda verarbeitet zu werden.

Metriken für asynchrone Aufrufe

Mehr Informationen zur Überprüfung weiterer Metriken für asynchrone Aufrufe finden Sie unter Einführung neuer Metriken für asynchrone Aufrufe für AWS Lambda.

Verwandte Informationen

Asynchroner Aufruf

Behandeln der Idempotenz von Lambda-Funktionen mit AWS Lambda Powertools

Arbeiten mit Lambda-Funktionsmetriken