Alles im Blick

Serverless Computing: Mehr als nur ein Hype

Stefan Marx

© Shutterstock / satvarika

Serverless ist schon vor einer Weile im Mainstream angekommen: Immer mehr Unternehmen setzen auf Architekturen, die auch schlanke Function-as-a-Service-Kapazitäten unterstützen. In diesem Artikel gibt Stefan Marx, Director Product Management für die EMEA-Region bei Datadog, Einblicke in die Vorteile, die der „serverlose“ Ansatz mit sich bringt.

Das Konzept von Serverless-betriebenen Anwendungslandschaften steht aktuell hoch im Kurs. Wie der aktuelle „The State of Serverless“ Report von Datadog zeigt, nutzt heute – fünf Jahre nach dem Launch von AWS Lambda – die Hälfte der Teilnehmer, die auf Amazon Web Services setzen, bereits eben diese Technologie. Und es sind nicht nur die kleinen, jungen Unternehmen, sondern vor allem Großunternehmen und Konzerne mit einem umfassenden Cloud-Ökosystem: Mehr als zwei Drittel von ihnen setzen bereits auf den ereignisgesteuerten und serverlosen Service. Bei kleinen Unternehmen ist es aktuell nur jedes fünfte.

Eine besondere Beziehung besteht laut Report zwischen der Nutzung von Container-Technologien und Serverless-Architekturen, denn letztendlich verfolgen beide Ansätze das selbe Ziel: Ressourcen zu schonen. 80 Prozent der Unternehmen mit Containern im Einsatz nutzen auch Lambda. Die schon in den frühen Tagen von Lambda verfügbaren Programmiersprachen Python und JavaScript (via Node.js) dominieren auch heute noch das Tagesgeschäft. 86 Prozent der Unternehmen nutzen eine der beiden Sprachen beziehungsweise Frameworks. C# (via .NET Core), Go und Ruby – alle erst seit 2018 in Lambda unterstützt – schließen erst langsam auf.

Damit die Vorteile – vor allem geringere Kosten und ein komfortables Anwendungsmanagement – nicht ins Gegenteil umschlagen, sollten Admins ihre Serverless-Umgebung allerdings zu keinem Zeitpunkt aus den Augen verlieren. Hier hilft ein vielseitiges Monitoring weiter.

Neue Metriken

Mit AWS Lambda erstellen Entwickler serverlose Anwendungen ohne dabei Infrastrukturressourcen wie Serverkapazität, Netzwerk oder Sicherheitspatches bereitstellen oder warten zu müssen. AWS Lambda ist ereignisgesteuert, wird also als Reaktion auf Ereignisse von anderen Diensten oder direkt von einer Aktion des Nutzers ausgelöst. Der Dienst läuft nur dann, wenn er benötigt wird. Gezahlt wird nur für die eigentliche Servernutzung und Laufzeit. Aber wie behält man etwas verlässlich im Blick, das nicht dauerhaft läuft? Da AWS Lambda die Infrastrukturressourcen verwaltet, können typische Systemmetriken wie die CPU-Auslastung nicht erfasst werden. Stattdessen meldet Lambda die Leistung und Effizienz einer Funktion, wie sie genutzt werden. Um Lambda also effektiv zu überwachen, muss klar sein, wie die Funktionen genutzt werden, welche Art von Ressourcen sie für eine effiziente Ausführung benötigen und wie Anfragen und andere Dienste mit der Funktion interagieren.

Häufen sich Anfragen, könnte die Performance der Serverless-Funktion darunter leiden, wenn sie nicht genügend Nebenläufigkeit für die Verarbeitung dieses Datenverkehrs aufweist. Der Fehler eines vorgeschalteten Dienstes könnte die Ausführung des Funktionscodes verhindern. Die Kosten für AWS Lambda ergeben sich aus der Laufzeit einer Funktion, dem genutzten Speicher und der Anzahl an Requests. Unerkannte Fehlfunktionen können den Kostenrahmen also schnell sprengen.

Von den Ereignissen, die eine Funktion aufrufen, bis hin bis zur Verarbeitung von Anfragen, gibt es in AWS Lambda unterschiedlichste Variablen, die DevOps-Teams helfen, Engpässe und Fehler zu identifizieren und Kosten effektiv zu verwalten. Lambda liefert standardmäßig eine Reihe von Metriken, mit denen die Effizienz des Codes sowie Aufrufe und die Nebenläufigkeit überwacht werden können. Einige dieser Metriken sind automatisch über CloudWatch verfügbar, wie die Laufzeit (Duration) oder Fehler (Errors), während andere aus den Lambda-Logs extrahiert werden müssen.

Kosten im Blick

Die Überwachung der Laufzeit einer Funktion hilft, die Kosten zu verwalten und festzustellen, welche Funktionen optimiert werden können oder sollten. Eine langsame Codeausführung kann das Ergebnis sogenannter Kaltstarts oder einer hohen Code-Komplexität sein. Wenn die Funktion auf Dienste von Drittanbietern oder andere AWS-Dienste angewiesen ist, können auch Faktoren wie die Netzwerklatenz die Ausführungszeit beeinflussen. Lambda begrenzt dabei die Ausführungszeit einer Funktion auf 15 Minuten, bevor diese beendet wird und einen Timeout-Fehler auslöst. Die Überwachung der Duration hilft, das Risiko eines Timeouts zu minimieren.

Da Serverless nach Nutzung abgerechnet wird, schlägt nur der tatsächliche Nutzen, also reale Operationen, zu Buche. Die zugrundeliegenden Server laufen nicht dauerhaft und unabhängig von ihrer Auslastung – entsprechend fallen keine Kosten für Leerlauf an. Kein Wunder also, dass bei den Teilnehmern des Reports zum Beispiel die durchschnittliche Lambda-Funktionen eine Laufzeit von unter 800 Millisekunden hat, ein Fünftel der Funktionen sogar eine von weniger als 100 Millisekunden. Laut dem „State of Serverless“ Report haben die Serverless-Funktionen bei einem Viertel der Unternehmen jedoch eine Lebensdauer von drei Sekunden. Bei 12 Prozent der Unternehmen sind es sogar zehn oder mehr Sekunden. Diese Unternehmen verschenken im Zweifel bares Geld und wissen es im schlimmsten Fall nicht einmal. Ist die Latenz an einigen Stellen zu hoch, können die erwarteten, niedrigen Kosten nicht erreicht werden.

Da neben der zeitlichen Komponente auch die Größe der Funktion eine Rolle spielt, beschränken knapp die Hälfte der Unternehmen ihre Funktionen auf die Mindestgröße von 128 MB. Nur 14 Prozent sind größer als 512 MB. Von der 3.008 MB-Obergrenze in AWS Lambda sind alle Teilnehmer jedoch weit entfernt. Der Speichergröße Grenzen zuzuweisen kann jedoch direkten Einfluss auf die Duration haben, da die Funktion mit zu wenig Speicherplatz langsamer läuft. Wird jedoch zu viel Speicher zugewiesen, liegt dieser brach und produziert unnötige Kosten. Es gilt also das richtige Maß zu finden und sicherzustellen, dass die Kostenbilanz eines serverlosen Function-as-a-Service-Dienstes tatsächlich den Erwartungen entspricht.

Serverless in der Queue

Lambda-User haben eine große Auswahl an Technologien, wenn es darum geht, ihre Funktionen mit der Infrastruktur und den Anwendungskomponenten zu verbinden. Sobald eine Funktion ausgelöst wird, sendet sie die von ihr erzeugten Daten häufig an eine Message Queue, die die Daten an andere Lambda-Funktionen, serverbasierte Anwendungen oder Cloud-Dienste weiterleitet. Message Queues helfen Unternehmen, das „pay only for what you use“-Modell von Serverless zu nutzen. Anstatt dass eine Funktion eine andere Funktion aufruft und untätig auf eine Antwort wartet (und abrechenbare Aufrufzeit in Anspruch nimmt), können serverlose Funktionen Aufrufe asynchron über eine Nachrichtenwarteschlange durchführen. Und weil Funktionen flüchtig und zustandslos sind, lesen oder schreiben sie oft aus einem separaten, persistenten Datenspeicher.

Unter den Diensten, die in der gleichen Anfrage wie eine Lambda-Funktion aufgerufen oder abgefragt werden, hat Amazon DynamoDB die Nase vorn. Der Key-Value-Dokumentenspeicher ist eine natürliche Ergänzung zu Lambda-Funktionen, da es sich um einen gehosteten, automatisch skalierenden Datenspeicher handelt, der eine niedrige Latenzzeit verspricht. Die nächst populärste Wahl für Datenspeicher in Lambda-Anwendungsfällen sind SQL-Datenbanken (ob Amazon RDS-Instanzen oder selbstverwaltete Datenbanken) beziehungsweise Amazon S3. Amazon SQS (Simple Queue Service) ist die erste Wahl für eine Message Queue in Lambda, gefolgt von Amazon Kinesis und Amazon SNS (Simple Notification Service). SQS ist eine logische Ergänzung für serverlose Architekturen: Es ist einfach einzurichten und zu skalieren, relativ kostengünstig und bietet eine enge Integration mit Lambda.

Sobald ein Ereignis in die Queue gestellt wurde, übernimmt Lambda den Rest. Wenn eine Funktion einen Fehler zurückgibt – als Ergebnis eines Timeout oder eines Problems im Funktionscode – versucht Lambda die Verarbeitung des Ereignisses bis zu zwei Mal zu wiederholen, bevor es verworfen oder an die Queue zurückgeben wird, wenn die Funktion nicht genügend Nebenläufigkeit hat, um sie zu verarbeiten.

Egal, ob eine Lambda-Funktion synchron, asynchron oder über einen Data Stream beziehungsweise eine Queue aufgerufen wird: Lambda generiert Metriken und Logs, mit denen alle Aufrufe in Echtzeit überwacht werden können. Lambda gibt Standardmetriken wie die Anzahl der Aufrufe, Fehler und Drosselungen für alle Funktionen aus, unabhängig von der Art des Aufrufs. Die Metrik enthält aber keine Aufruffehler oder interne Dienstfehler von anderen AWS-Diensten. Lambda generiert aber auch unterschiedliche Metriken, je nach Aufruftyp und wie eine Funktion mit dem Fehler umgeht. Und wenn diese Metriken mit Lambda-Logs korreliert werden, ergibt sich ein vollständiges Bild des Problems.

Nebenläufigkeit am Limit

Die Überwachung der Nebenläufigkeit hilft, übermäßig bereitgestellte Funktionen zu verwalten und Funktionen zu skalieren, um den Ablauf des Anwendungsverkehrs zu optimieren. Standardmäßig bietet Lambda einen Pool von bis zu 1.000 gleichzeitigen Ausführungen pro Region. Diesen Pool teilen sich alle Funktionen eines Nutzers in eben einer Region. Wichtig ist also, dass sich die Funktionen nicht gegenseitig blockieren. Aus diesem Grund kann für bestimmte Funktionen auch Nebenläufigkeit reserviert werden. Egal, ob diese letztlich von der Funktion genutzt wird oder nicht, keine andere kann diese Reserve blockieren. Hier sollte aber darauf geachtet werden, mit einer solchen Reserve nicht die Performance anderer Funktionen negativ zu beeinflussen, denn ist ein Limit erreicht, werden Funktionen gedrosselt.

Heute haben nur 4,2 Prozent aller Funktionen, die mit Datadog überwacht werden, eine konfigurierte Grenze, obwohl sich die meisten Organisationen der optionalen Grenze bewusst sind. Denn 88,6 Prozent der Unternehmen, die Lambda einsetzen, haben für mindestens eine Funktion in ihrer Umgebung einen entsprechenden Schwellenwert definiert, nicht aber für das Gros. Die Funktionen, die eine definierte Nebenläufigkeitsgrenze haben, werden mit weit größerer Wahrscheinlichkeit gedrosselt. Über ein Auswertungsfenster von fünf Tagen wurden 8,3 Prozent der Funktionen mit einer Gleichzeitigkeitsgrenze mindestens einmal gedrosselt, im Vergleich zu nur 0,3 Prozent der Funktionen, die nur durch Grenzen pro Region und nicht pro Funktion eingeschränkt sind. Das ist besonders bei synchronen Anfragen wichtig, da Lambda nicht versucht, diese erneut auszuführen. Eine ständige Drosselung könnte ein Indiz dafür sein, dass es mehr Anfragen gibt, als die Funktionen bewältigen können, und dass die Kapazität nicht ausreicht. Generell können Alerts über einen bestimmten Schwellenwert informieren.

Timeouts

Jede Lambda-Funktion hat ein konfigurierbares Timeout, das von 1 Sekunde bis 15 Minuten reicht. Die meisten Funktionen verwenden kurze Timeouts: zwei Drittel der konfigurierten Timeouts betragen 60 Sekunden oder weniger. (Der Standard-Timeout bei der Erstellung einer Funktion beträgt 3 Sekunden).

Kurze Timeouts sind sinnig, weil hängende Funktionen Kosten verursachen und die Lambda-Anwendungsarchitektur oft eine schnelle Reaktion erfordert. Das Amazon API Gateway, das häufig zur Bereitstellung einer REST-Schnittstelle vor einer Lambda-Funktion verwendet wird, hat eine maximale Timeout-Einstellung von 29 Sekunden. Daher führt jede Lambda-Funktion hinter einem API-Gateway, die länger als 29 Sekunden für die Antwort benötigt, zu einem Fehler, selbst wenn Lambda seine Arbeit erfolgreich abschließt. Trotz dieser Überlegungen wurden viele Funktionen so konfiguriert, dass sie die maximal zulässigen Timeouts verwenden – sowohl die aktuelle 900-Sekunden-Grenze als auch die frühere Grenze von 300 Sekunden (die bis Oktober 2018 in Kraft war).

Einbettung in das Gesamtbild

Anwendungen mit Serverless-Funktionen sind in mehrere, kleinere Komponenten aufgeteilt. Die isolierte Überwachung der Lambda-Funktionen bietet dadurch keinen vollständigen Einblick in den Pfad einer Anfrage durch die serverlose Architektur. In jedem Fall lohnt sich der Einsatz der Amazon-hauseigenen Monitoring-Tools, um Logs, Traces, Metriken und Ereignisse sowie Requests aus Lambda und anderen AWS-Services im Blick zu behalten. Die Verknüpfung aller von Lambda ausgegebenen Metriken sowie Logs und Performance-Daten mit einem übergreifenden Cloud-Monitoring-Tool liefert letztlich ein vollständiges Bild aller serverlosen Anwendungen.

Verwandte Themen:

Geschrieben von
Stefan Marx

Stefan Marx ist Director Product Management für die EMEA-Region beim Cloud-Monitoring-Anbieter Datadog. Marx ist seit über 20 Jahren in der IT-Entwicklung und -Beratung tätig. In den vergangenen Jahren arbeitete er mit verschiedenen Architekturen und Techniken wie Java Enterprise Systemen und spezialisierten Webanwendungen. Seine Tätigkeitsschwerpunkte liegen in der Planung, dem Aufbau und dem Betrieb der Anwendungen mit Blick auf die Anforderungen und Problemstellungen hinter den konkreten IT-Projekten.

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: