Warum wird meine Lambda-Funktion mit einer Amazon-SQS-Ereignisquelle nicht optimal skaliert?

Behebung

Hinweis: Wenn du eine Amazon SQS-Warteschlange als Ereignisquelle konfigurierst, können Lambda-Funktionen optimal auf bis zu 300 weitere Instances pro Minute hochskalieren. Die maximale Anzahl gleichzeitiger Ausführungen für Standardwarteschlangen beträgt 1250. Wenn du die FIFO (First-In, First-Out)-Zuordnung von Ereignisquellen verwendest, können Funktionen parallel zur Anzahl der aktiven Nachrichtengruppen abskaliert werden.

Identifizierung und Lösung von Problemen beim Aufrufen der Lambda-Funktion

Um Skalierungsfehler zu vermeiden, drosselt Lambda die Funktionsskalierung, wenn Aufrufprobleme auftreten. Nachdem du die Probleme behoben hast, skaliert Lambda die Funktion weiter. Weitere Informationen findest du unter Backoff-Strategie für fehlgeschlagene Aufrufe. Informationen zum Beheben von Fehlern beim Aufrufen von Lambda-Funktionen findest du unter Behandeln von Fehlern für eine SQS-Ereignisquelle in Lambda und Wie behebe ich Lambda-Funktionsfehler?

Konfiguration der Lambda-Funktion mit optimaler Parallelität

Reservierte Parallelität

Wenn du reservierte Parallelität für deine Funktion konfiguriert hast, drosselt Lambda die Funktion, wenn die Funktion den reservierten Wert erreicht. Zuordnungen von Ereignisquellen beinhalten keine reservierte Parallelität und können mehr Nachrichten aus der Warteschlange verarbeiten als an die Funktion gesendet werden.

Die minimale reservierte Parallelität für die Funktion muss für Standard-SQS-Warteschlangen 1250 betragen und der Gesamtzahl der aktiven Nachrichtengruppen für FIFO-Warteschlangen entsprechen. Es hat sich bewährt, die reservierte Parallelität höher als die Anzahl der Nachrichtengruppen in der FIFO-Warteschlange festzulegen. Eine geringere reservierte Parallelität kann zu Verzögerungen bei der Verarbeitung in der FIFO-Warteschlange führen und die Funktion drosseln.

Wichtig: Um die Anzahl gleichzeitiger Aufrufe zu begrenzen, verwende die maximale Parallelitätseinstellung für Amazon SQS-Ereignisquellen anstelle der reservierten Parallelität.

Standardparallelität

Das AWS-Konto hat ein Standard-Parallelitätskontingent von 1000 für alle Funktionen in demselben Konto und derselben AWS-Region. Funktionen werden skaliert, bis sie die maximal verfügbare Parallelität erreicht haben. Wenn alle Funktionen den Pool von 1000 Parallelität verwenden, drosselt Lambda die Aufrufe.

Lambda schränkt ein, wie schnell die Funktionen skaliert werden können, sodass plötzliche Spitzen des Datenverkehrs nicht zu einer übermäßigen Skalierung der Funktionen führen. Lambda-Funktionen werden anfänglich auf der Grundlage der Parallelitätsskalierungsrate skaliert. Da die Parallelitätsskalierungsrate auf Funktionsebene liegt, kann jede Funktion im Konto unabhängig von anderen Funktionen skaliert werden. Die Parallelitätsskalierungsrate unterscheidet sich auch vom Parallelitätskontingent auf Kontoebene, das die Gesamtmenge der Parallelität angibt, die den Funktionen zur Verfügung steht.

Hinweis: Die standardmäßige Parallelität unterscheidet sich von der bereitgestellten Parallelität. Weitere Informationen findest du unter Reservierte Parallelität und bereitgestellte Parallelität verstehen.

Einstellung für maximale Parallelität

Wenn du die maximale Parallelität für eine Ereignisquelle festlegst, gilt dieser Wert nur für diese bestimmte Ereignisquelle. Weitere Ereignisquellen ohne maximale Parallelität verwenden das verbleibende Parallelitätskontingent des Kontos oder die reservierte Parallelität.

Du kannst die Einstellung für maximale Parallelität und die reservierte Parallelität zusammen verwenden. Es hat sich bewährt, die maximale Parallelität niedriger als die reservierte Parallelität der Funktion festzulegen, damit Funktionen nicht gedrosselt werden.

Sicherstellen, dass die Amazon-SQS-Warteschlange genügend Nachrichten enthält, damit die Lambda-Funktion skaliert werden kann

Wenn du eine Amazon SQS-Warteschlange zum Aufrufen einer Lambda-Funktion konfiguriert hast, skaliert Lambda Aufrufe nur, wenn sich Nachrichten in der Warteschlange befinden.

Um mithilfe von Amazon CloudWatch zu überprüfen, wie viele Nachrichten in der Warteschlange verarbeitet werden müssen, überprüfe die Metrik ApproximateNumberOfMessagesVisible der Warteschlange.

Wenn die Metrik niedrig oder bei 0 ist, kann die Funktion nicht skaliert werden.

Wenn die Metrik hoch ist und es keine Aufrufprobleme gibt, erhöhe die Batch-Größe in der Ereignisbenachrichtigung, bis die Metrik für die Dauer nicht mehr ansteigt. Weitere Informationen zu Metriken für Lambda findest du unter Arten von Metriken.

Hinweis: Die maximale Batch-Größe für eine Amazon-SQS-Standardwarteschlange beträgt 10000 Datensätze. Bei FIFO-Warteschlangen beträgt die maximale Batch-Größe 10 Datensätze.

Bestätigung, dass Amazon SQS die Nachrichten zu einer Warteschlange hinzufügt

Um dich zu vergewissern, dass Amazon SQS die neuen Nachrichten zu einer Warteschlange hinzufügt, überprüfe die Metrik NumberOfMessagesSent der Warteschlange.

Bestätigung, dass der Verbraucher den ReceiveMessage-API-Aufruf tätigt

Um zu überprüfen, ob der Verbraucher den ReceiveMessage-API-Aufruf durchführt, überprüfe die Metrik NumberOfMessagesReceived der Warteschlange.

Hinweis: Spitzen in der Metrik NumberOfEmptyReceives zeigen, dass der Verbraucher den ReceiveMessage-API-Aufruf durchführt, der Aufruf jedoch keine Nachricht aus der Warteschlange zurückgibt. Dieses Problem tritt auf, wenn sich keine Nachrichten in der Warteschlange befinden.

Ähnliche Informationen

Verwendung von Lambda mit Amazon SQS

Verwaltung der Parallelität von AWS-Lambda-Funktionen