Performance-Optimierung für AWS Lambda

Optimale Performance für AWS Lambda ist für das Cloud-Budget Ihres Unternehmens von großer Relevanz. Verstärkt werden die Vorteile in diesem Zusammenhang dadurch, dass Amazon Web Services (AWS) das Management von Server- und anderen Cloud-Ressourcen mit Lambda deutlich vereinfacht. Insbesondere zur schnellen Skalierung und für Prototypen neuer Features und Produkte ist dies enorm hilfreich. 

Die damit verbundenen Aufgaben lassen sich zudem auch automatisieren – eine Möglichkeit, die jedem Unternehmen, das dem ursprünglichen Aggregatszustand eines Startups in der Gründungsphase entwachsen ist, viel Zeit und Geld sparen kann. 

Was ist AWS Lambda?

Amazon Web Services (AWS) bietet mit Lambda einen eventgesteuerten Service, bei dem die für Ihre Infrastruktur benötigten Cloud-Ressourcen automatisch via Code zur Verfügung gestellt werden, ohne dass Sie dafür selbst tätig werden müssen. Um die Provisionierung brauchen Sie sich also ebenso wenig Gedanken machen wie um die Betriebssystemwartung, Skalierung oder andere Management-Aufgaben. 

Die Abrechnung erfolgt dabei entsprechend der Ausführungsdauer der Computing-Ressourcen, also ab dem Zeitpunkt, zu dem Ihre Funktion via Event Notification Trigger oder Direktaufruf gestartet wird. Genau das sollten Sie also im Blick behalten, damit Sie feststellen können, ob bzw. wie sich unnötige Kosten bei der Lambda-Nutzung vermeiden lassen. 

AWS bietet hierfür zwar eine Monitoring-Lösung, die jedoch eher rudimentär gehalten ist. So bietet sie weder den vollen Kontext zum Ursprung von Trigger-Events, noch Distributed Tracing oder detaillierte Performance-Daten zu Ausführungsdauer, Kaltstarts, Ausnahmen oder Tracebacks. Um das Verhalten Ihrer Lambda-Funktionen in dieser Detailtiefe ausleuchten zu können, bedarf es einer Lösung für durchgängiges Monitoring. 

Speicher und sein Einfluss auf die Lambda-Performance

Einer der wichtigsten Faktoren, die es im Kontext der Laufzeit von Lambda-Funktionen zu beachten gilt, ist die Speicherausstattung. Die von AWS angebotenen Optionen reichen hier von 128 MB bis 10,24 GB pro Funktion. Gerade für Funktionen, die kleiner dimensioniert sind, dürfte allerdings bereits die Minimalausstattung ausreichen. Zudem nimmt die Lambda-Performance mehr oder weniger proportional zum Umfang des zugewiesenen Speichers zu. 

Nun wird über die Speicherausstattung aber auch in etwa die Performance bestimmt, die hinsichtlich virtueller CPUs, Netzwerk und Festplatte zur Verfügung steht. Und damit wiederum kann unerwartetes Verhalten Ihrer Funktionen einhergehen, z. B. Performance-Drosselungen beim Überschreiten von Threshold-Werten für parallele Ausführungen, wenn die CPU-Auslastung übermäßig steigt. 

Komplex gestaltet sich das Performance-Benchmarking nicht zuletzt auch angesichts dessen, dass die Ausführung von Lambda-Funktionen ja auf ein kleinstmögliches Maß reduziert werden soll. Denn mehr CPU-Ausstattung bedeutet zwar bis zu einem gewissen Grad auch schnellere Performance für die zugehörige Funktion. Über diesen hinaus schrumpft der dadurch erzielte Gewinn jedoch signifikant. Der Grund hierfür ist, dass die Nutzungsdauer in 100-Millisekunden-Intervallen abgerechnet wird. Ganz gleich, ob Sie also etwa 120 oder 150 ms in Anspruch nehmen, wird beides am Ende mit 200 ms zu Buche schlagen. 

Troubleshooting und Optimierung Ihrer Lambda-Performance

Zur Begrenzung der Kostenentwicklung empfiehlt sich daher durchgängiges Monitoring Ihrer Lambda-Funktionen auf Anomalien. Denn so können Sie diese ggf. direkt debuggen und behalten zudem die zugehörigen Code-Ausführungen ganz allgemein klarer im Blick. Noch wichtiger wird dies in komplexen Infrastrukturen. Denn darin sind diese Serverless-Funktionen oft durch diverse Trigger-Events miteinander verknüpft, was sich negativ auf ihre Performance auswirken kann. Wo die Ursache hierfür dann genau liegt, lässt sich in derart verteilten Systemen jedoch nur schwer zurückverfolgen. 

Allgemeine Problemstellungen in diesem Zusammenhang sind: 

Übermäßig dimensionierte Funktionen

Von der Praxis, die Businesslogik komplett oder große Teile davon auf eine Funktion allein zu konzentrieren, ist nicht nur ganz generell abzuraten, sondern auch aus Sicht der Kosten. Denn die fallen umso höher aus, je länger eine aufgerufene Funktion ausgeführt wird. Ein Monolith (oder „Lambdalith“), der große Teile Ihres Codes in einer Funktion verdichtet, ist daher wenig zielführend. Verteilen Sie ihn stattdessen auf so kleine Lambda-Funktionen wie möglich. 

Kaltstarts

Das Verhalten Ihrer Funktionen wird sich zudem nur dann wie erwartet einstellen, wenn Sie sie in regelmäßigen Abständen aufrufen. Dies beugt Latenzen vor, die mit dem Kaltstart bzw. der damit verbundenen Initialisierung der Funktionen einhergehen.

Zeitlimits für die Funktionsausführung

Für Lambda-Funktionen gilt ein Timeout-Threshold von 15 Minuten. Daher sollten Ihre Funktionen schlank und für möglichst kurze Ausführungszeiten angelegt sein. Zeitintensive Workloads wie große Datenbanken oder ähnlich langwierige Verarbeitungsaufgaben sind auf AWS Lambda also zu vermeiden.

Maximalzahl paralleler Ausführungen

Immer wenn ein Service eine Funktion zum ersten Mal aufruft, wird eine Instanz erstellt. Ruft der Service nun noch während der Ausführung seiner erstmaligen Anfrage dieselbe Funktion erneut auf, erstellt AWS eine neue Instanz. Für die Anzahl dieser zur Verarbeitung der Anfragen erstellten Instanzen besteht jedoch ein Limit von 1000 parallelen Ausführungen pro AWS-Region.

Auf Anfrage lässt sich dieses Limit erhöhen, allerdings muss diese mindestens 2 Wochen im Voraus erfolgen. Wird das Limit in der Zwischenzeit überschritten, drosselt AWS die Performance – etwas, das Sie sicher vermeiden wollen, wenn der Traffic auf Ihrer Anwendung zum Black Friday oder in anderen saisonalen Hochphasen durch die Decke geht. 

Für AWS Lambda steht zwar ein Power Tuning Tool zur Verfügung, mit dem Sie näherungsweise ermitteln können, wie sich Anpassungen der Speicherausstattung Ihrer Funktion auf deren Performance und Kosten auswirken. Die Detailtiefe dieser Prognosen lässt jedoch zu wünschen übrig. Denn ein Gesamtbild der Faktoren, aufgrund derer die Kosten potenziell höher ausfallen, wird daraus nicht erkennbar. 

Klarheit zu Optimierungspotenzialen oder Wegen zur Vermeidung dieser gängigen Problemszenarien werden Sie damit also nicht erhalten. Genau deshalb benötigen Sie eine Lösung für durchgängiges Monitoring Ihrer Funktionen, die über die Funktionalität des Tuning-Tools hinaus Folgendes bietet:

• Monitoring sämtlicher Aufrufe von Lambda-Instanzen
• Alert-Definition basierend auf beliebigen Kriterien zum Funktionsaufruf
• Fehleranalysen
• Zentrale Sicht auf sämtliche Lambda-Funktionen in allen AWS-Regionen

Die Devise lautet hier „Sehen heißt Verstehen“. Denn die Lösung eines Problems erschließt sich erst, wenn Sie es klar nachvollziehen können. Und dazu wiederum benötigen Sie den kompletten Kontext. 

Ihr Sichtfenster für mehr AWS-Erfolg: Observability mit New Relic

New Relic bietet eine kompakte Monitoring-UI für Lambda, die alles vereint, was Sie benötigen. Und das bei hoher Kosteneffizienz: Bereits die Einrichtung ist mit unserer Integration für AWS Lambda in Minutenschnelle erledigt.

 Nicht weniger spannend sind dabei die Monitoring-Features selbst:

• Ansicht sämtlicher Aufrufe von Lambda-Funktionen: Umfassende Details zu Ausführungsdauer, Tracebacks, Kaltstarts und mehr
• Insights zu Events: Kontext und Attribute zur Ermittlung der Ursache von Funktionsaufrufen, darunter etwa API-Gateway, ALB SNS, SQS oder DynamoDB 
• Distributed Tracing: Klarheit zum Pfad der Anfragen, die zu Ihren Lambda-Funktionen führen 
• Logs in Context: Erfassung komplett auf Aufruf- und Funktionsebene, dies ergänzend zu allen Metrics, Attributen und Trace-Daten
• Inventarisierte Tags und Metadaten: Informationen zu AWS-Entitäten für detaillierten Analysen von Metadaten-Attributen zu Funktionskonfigurationen oder zu den Aufrufen selbst