AWS Builder Center: Learn, Build and Connect with builders in the AWS community
AWS Builder Center is the official home for builders on AWS. Share and read what others are working on, follow people who inspire you, explore training and workshops, and find tools to support what you're building.
Warum wird meine Lambda-Funktion mit einer Amazon-SQS-Ereignisquelle nicht optimal skaliert?
Die AWS Lambda-Funktion für meine Amazon Simple Queue Service (Amazon SQS)-Warteschlangenereignisquelle wird nicht wie erwartet skaliert. Ich möchte die optimale Parallelität konfigurieren.
Lösung
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.
Standardmäßige Parallelitä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 keine Aufrufprobleme vorliegen, dann erhöhe die Batch-Größe für deine Ereignisbenachrichtigung, bis die Metrik Dauer keine Spitzenwerte mehr aufweist. Weitere Informationen findest du unter Arten von Metriken für Lambda-Funktionen.
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ätigen, dass Amazon SQS die Nachrichten zu einer Warteschlange hinzugefügt hat
Um zu überprüfen, ob Amazon SQS die neuen Nachrichten zu einer Warteschlange hinzugefügt hat, überprüfe die Metrik NumberOfMessagesSent der Warteschlange.
Bestätigen, dass der Verbraucher den ReceiveMessage-API-Aufruf durchgeführt hat
Um zu überprüfen, ob der Verbraucher den ReceiveMessage-API-Aufruf durchgeführt hat, überprüfe die Metrik NumberOfMessagesReceived der Warteschlange.
Hinweis: Spitzenwerte in der Metrik NumberOfEmptyReceives zeigen, dass der Verbraucher den ReceiveMessage-API-Aufruf durchgeführt hat, der Aufruf jedoch keine Nachricht aus der Warteschlange zurückgibt. Dieses Problem tritt auf, wenn sich keine Nachrichten in der Warteschlange befinden.
Bereitgestellten Modus mit Amazon-SQS-Ereignisquellenzuordnungen verwenden
Verwende den bereitgestellten Modus für Workloads, um den Durchsatz deiner Ereignisquellenzuordnung fein abzustimmen und Grenzwerte für die Ereignisabrufer festzulegen. Eine Zuordnung von Amazon-SQS-Ereignisquellen, die mit dem bereitgestellten Modus konfiguriert ist, skaliert dreimal schneller und unterstützt eine 16-mal höhere Parallelität als die Standardfunktionalität von Amazon-SQS-Ereignisquellenzuordnungen.
Es hat sich bewährt, den bereitgestellten Modus für SQS-ereignisgesteuerte Workloads mit strengen Leistungsanforderungen zu verwenden. Beispielsweise bei Finanzdienstleistungsunternehmen, die Marktdaten-Feeds verarbeiten, sowie bei E-Commerce-Plattformen, die personalisierte Empfehlungen in Echtzeit bereitstellen.
Weitere Informationen findest du unter AWS Lambda verbessert die Ereignisverarbeitung mit dem bereitgestellten Modus für die Zuordnung von SQS-Ereignisquellen.
Hinweis: Der bereitgestellte Modus verursacht zusätzliche Kosten. Weitere Informationen findest du unter AWS Lambda – Preise.
Ähnliche Informationen
- Themen
- Compute
- Tags
- AWS Lambda
- Sprache
- Deutsch
Ähnliche Videos


Relevanter Inhalt
AWS OFFICIALAktualisiert vor 2 Jahren
AWS OFFICIALAktualisiert vor 2 Jahren
AWS OFFICIALAktualisiert vor einem Jahr