Nebenläufigkeit, Drosselung und reservierte Nebenläufigkeit

Lambda skaliert, indem mehrere gleichzeitige Ausführungen Ihrer Funktion gestartet werden – eine pro gleichzeitig eintreffendem Ereignis. Wenn 100 Anfragen gleichzeitig eintreffen, führt Lambda 100 parallele Instanzen Ihrer Funktion aus. AWS verwaltet die zugrunde liegende Infrastruktur automatisch. Das Konkurrenzlimit auf Kontoebene beträgt standardmäßig 1.000 gleichzeitige Ausführungen pro Region (ein weiches Limit, das über eine Service-Quota-Anfrage erhöht werden kann).

Die Konkurrenz wird folgendermaßen berechnet: Konkurrenz = Anfragen pro Sekunde × durchschnittliche Dauer in Sekunden. Wenn Ihre Funktion 500 Anfragen pro Sekunde verarbeitet und jede Anfrage 0,2 Sekunden dauert, benötigen Sie 100 gleichzeitige Ausführungen. Wenn Sie diese Formel verstehen, können Sie abschätzen, ob die Limits Ihres Kontos ausreichen und ob Sie vor einem Ereignis mit hohem Datenverkehr eine Erhöhung der Kontingente beantragen müssen.

Wenn Lambda mehr Anfragen erhält, als das Konkurrenzlimit zulässt, drosselt es die überschüssigen Anfragen. Bei synchronen Aufrufen (z. B. über API Gateway) erhalten gedrosselte Anfragen sofort einen 429 TooManyRequestsException, der vom Aufrufer behandelt werden muss. Bei asynchronen Aufrufen (z. B. bei S3-Ereignissen) reiht Lambda die Ereignisse ein und wiederholt sie bis zu 6 Stunden lang, bevor sie an eine Dead-Letter-Queue gesendet werden.

Reserved Concurrency garantiert eine bestimmte Anzahl gleichzeitiger Ausführungen für eine bestimmte Funktion und reserviert diese aus dem Kontingent des Kontos. Sie erfüllt zwei Zwecke: (1) Sie garantiert Kapazität – der Funktion steht diese Anzahl an Ausführungen immer zur Verfügung, selbst wenn andere Funktionen das Kontingent des Kontos beanspruchen. (2) Sie begrenzt die Konkurrenz – die Funktion kann die reservierte Anzahl niemals überschreiten und schützt dadurch nachgelagerte Abhängigkeiten vor Überlastung.

Ein wichtiges Prüfungsszenario: Eine Lambda-Funktion schreibt in eine RDS-Datenbank, die auf 50 Verbindungen begrenzt ist. Ohne Einschränkungen der Konkurrenz könnte Lambda auf Hunderte gleichzeitige Ausführungen skalieren und alle Datenbankverbindungen aufbrauchen, wodurch für jede Funktion Fehler auftreten. Wenn Sie Reserved Concurrency auf 40 setzen, stellt Lambda sicher, dass nie mehr als 40 gleichzeitige Datenbankverbindungen verwendet werden, und schützt so die RDS-Instance. Dies ist ein wichtiges Muster für jede Lambda-Funktion, die einen Service mit begrenzter Verbindungsanzahl aufruft.

Provisioned Concurrency initialisiert eine festgelegte Anzahl von Lambda-Ausführungsumgebungen vor, sodass sie ohne Cold Start sofort antworten können. Dies ist entscheidend für latenzempfindliche APIs, bei denen selbst ein Cold Start von 100 ms nicht akzeptabel ist. Für Provisioned Concurrency zahlen Sie einen Stundensatz, auch wenn die Umgebungen ungenutzt sind. Kombinieren Sie sie daher mit Auto Scaling, um die bereitgestellte Kapazität anhand der erwarteten Datenverkehrsmuster anzupassen.

Diese beiden Konzepte werden häufig verwechselt, dienen jedoch unterschiedlichen Zwecken. Reserved Concurrency begrenzt die Kapazitätszuweisung aus dem Kontingent des Kontos und garantiert sie – sie beseitigt KEINE Cold Starts. Provisioned Concurrency hält Ausführungsumgebungen vorab warm, um Cold Starts zu vermeiden – sie verhindert NICHT, dass andere Funktionen denselben Pool verwenden. Verwenden Sie Reserved Concurrency, um den Durchsatz zu begrenzen, und Provisioned Concurrency, um die Latenz zu verbessern. Beide können für dieselbe Funktion gemeinsam verwendet werden.

Lambda skaliert nicht sofort auf die vollständige Konkurrenz. Es gibt ein Burst-Limit auf Kontoebene (die anfängliche Skalierungsrate), das je nach Region variiert – typischerweise 3.000 Ausführungen im anfänglichen Burst, danach 500 zusätzliche Ausführungen pro Minute, bis das Limit erreicht ist. Verwenden Sie für Anwendungen, die plötzliche massive Spitzen erwarten (viraler Datenverkehr, Blitzverkäufe), Provisioned Concurrency, um genügend Umgebungen vorab zu initialisieren, sodass das Burst-Limit während des anfänglichen Anstiegs keine Drosselung verursacht.

Überwachen Sie die Lambda-Konkurrenz mit diesen wichtigen CloudWatch-Metriken:

• ConcurrentExecutions: aktuelle Anzahl der laufenden Instanzen
• Throttles: Anzahl der gedrosselten Aufrufe (sollte in einem fehlerfreien System null sein)
• UnreservedConcurrentExecutions: nicht reservierter Pool auf Kontoebene
• ProvisionedConcurrencyUtilization: Anteil der genutzten bereitgestellten Kapazität

Richten Sie Alarme für Throttles ein, um benachrichtigt zu werden, bevor sich die Drosselung auf Endbenutzer auswirkt.

Wenn Sie Systeme entwerfen, die Lambda synchron aufrufen (API Gateway, direkte SDK-Aufrufe), implementieren Sie im Aufrufer einen exponentiellen Backoff mit Jitter. AWS-SDKs verfügen über eine integrierte Wiederholungslogik. Bei Lambda-Funktionen hinter API Gateway müssen Sie 429-Antworten jedoch in Ihrer Clientanwendung behandeln. Bei SQS-getriggerten Lambda-Funktionen übernimmt der SQS-Service die Wiederholungsversuche selbst. Legen Sie Maximum Receives für die Quellwarteschlange passend fest und konfigurieren Sie für erschöpfte Wiederholungsversuche eine DLQ.

Bei Kinesis Data Streams und DynamoDB Streams wird die Lambda-Konkurrenz durch die Anzahl der Shards (Kinesis) beziehungsweise Partitionen (DynamoDB) begrenzt. Jeder Shard bzw. jede Partition wird von genau einer gleichzeitigen Lambda-Ausführung verarbeitet. Wenn Sie 10 Kinesis-Shards haben, führt Lambda für diesen Trigger bis zu 10 gleichzeitige Ausführungen aus. Das bedeutet, dass Drosselungsprobleme bei streambasierten Triggern normalerweise durch eine Erhöhung der Shard-Anzahl und nicht durch eine Anhebung der Konkurrenzlimits gelöst werden.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Reserved Concurrency garantiert und begrenzt zugleich die gleichzeitigen Ausführungen einer Funktion, um nachgelagerte Services zu schützen und die Verfügbarkeit sicherzustellen. Provisioned Concurrency initialisiert Umgebungen vorab, um Cold Starts bei latenzempfindlichen Workloads zu vermeiden. Drosselung zeigt sich bei synchronen Aufrufen als 429-Fehler und bei asynchronen Aufrufen als eingereihten Wiederholungsversuchen. Überwachen Sie sie mit der CloudWatch-Metrik Throttles. Als Nächstes befassen wir uns mit Lambda Layers und Bereitstellungspaketen zur Verwaltung umfangreicher Abhängigkeiten.