Standardisieren Sie Ihre Pipelines mit Containern für Lambda

Dieses Jahr hat das AWS Lambda-Team auf der re:Invent einen neuen Workflow für die Paketierung von Cloud-Anwendungen vorgestellt: OCI-Container-Unterstützung für Lambda-Funktionen. Wir werfen einen kurzen Blick darauf, was das ist und wie es funktioniert. Und vor allem, was es für Ihr Team bedeutet, wenn Sie heute mit Serverless-Workloads beginnen.

Container bieten das Potenzial, das vorhandene Wissen in Ihren Teams zu nutzen und einen Teil der Wissenslücke zu Serverless zu schließen. Sie fügen sich nahtlos in Ihre bestehenden Pipelines und Arbeitsabläufe ein und ermöglichen es Ihnen gleichzeitig, Ihren Code in jeder beliebigen Sprache mühelos in Lambda einzubringen. Hier ein kurzer geschichtlicher Abriss, um uns auf den neuesten Stand der Entwicklung von Lambda und Containern zu bringen.

Die Geschichte von AWS Lambda

AWS hat Lambda allgemein verfügbar gemacht bereits im April 2015. Fast 6 Jahre und mehr als 28 Seiten an Blogbeiträgen und Ankündigungen später entwickelt Lambda immer noch in rasantem Tempo neue Funktionen und steht weiterhin an der Spitze der Innovation, wenn es um serverlose Berechnungen geht. Ursprünglich war Lambda nur in einer Sprache verfügbar: Javascript. Die Idee hinter diesem Konzept war es, Benutzern die Möglichkeit zu geben, einfache Verbindungen zwischen AWS-Services herzustellen, z. B. Daten auf eine bestimmte Weise zu manipulieren, bevor sie an einen anderen internen Service weitergegeben werden. All dies konnte getan werden, ohne dass ein einzelner Container oder eine EC2-Instanz ständig laufen musste, was zu enormen Kosteneinsparungen für Unternehmen mit kleinen, selten ausgeführten Aufgaben führte.

Unter der Haube lädt der Lambda-Dienst Ihren verpackten Code aus dem Speicher herunter und führt ihn dann aus. Je kleiner der Code ist, desto schneller kann Lambda mit der Ausführung beginnen. Aus diesem Grund, Lambda strenge Größenbeschränkungen für die Größe des hochgeladenen Codesobwohl sie jetzt großzügiger sind als zu Beginn.

Während Tools wie Docker seit etwa 2011 existieren und die Art und Weise, wie wir Anwendungen bereitstellen, bis heute verändert haben, verfolgt die Containerisierung eine andere Strategie. Da der Zweck darin besteht, nicht nur den Code, sondern auch alle abhängigen Bibliotheken zu verpacken, kann selbst ein Standard-Ubuntu-Container-Image 300 MB überschreiten. Mit der neuen AWS-Ankündigung erlaubt AWS das Hochladen von Container-Images mit einer Größe von bis zu 10 GB. Das übertrifft alles, was vorher möglich war, wo die maximale Größe des Codes 250 MB betragen konnte.

Mit der vollständigen Unterstützung von Containern ist es jetzt einfacher denn je, nicht nur Ihren Code zu verpacken, sondern auch alle Abhängigkeiten, die für die Ausführung erforderlich sind, und zwar mit denselben Tools, die Sie von Diensten wie Docker kennen und lieben. Ich habe bereits erwähnt, dass Lambda den Code herunterladen muss, bevor er ausgeführt wird. Dies führt zu einem Phänomen, das als "Kaltstart" bekannt ist. Beim ersten Aufruf einer Funktion kann es zu einer Verzögerung von mehreren hundert Millisekunden zwischen dem Senden einer Anfrage und dem Beginn der Ausführung kommen. Dieses Problem verschwindet nach dem ersten Aufruf, da dieselbe Ausführungsumgebung wiederverwendet wird. Es kann jedoch zu einem großen Problem werden, wenn Sie bestimmte Anforderungen an die Latenzzeit haben und die Funktion nicht oft ausgeführt wird oder wenn Sie schnell skalieren müssen.

Containerisierung mit AWS Lambda

Die beeindruckendste Leistung ist, dass es dem AWS Lambda-Team jetzt gelungen ist, ganze Container mit einer Größe von bis zu 10 GB unterzubringen, ohne dass sich die Zeit für einen Kaltstart geändert hätte. Wie haben sie das geschafft? Lassen Sie uns tief eintauchen.

Bei der Entwicklung dieser neuen Funktionalität hat sich das Lambda-Team einige wichtige Eigenschaften eines Containers zunutze gemacht:

• Im Allgemeinen basieren Container auf generischen Images mit viel mehr Abhängigkeiten, als der Code tatsächlich benötigt. Nur ein kleiner Teil des Images muss bei der Ausführung tatsächlich verfügbar sein.
• Die überwiegende Mehrheit der Container baut auf weithin verfügbaren öffentlichen Images auf, wobei diese Schichten von mehreren Anwendungen mehrerer Kunden gemeinsam genutzt werden können.
• Innerhalb eines Unternehmens werden viele Ebenen von Anwendungen gemeinsam genutzt, da sie auf Basis der vom Unternehmen definierten Basis-Images arbeiten.

Mit diesen wichtigen Ideen im Hinterkopf ist es möglich, die Datenmenge, die Lambda zu Beginn des Aufrufs herunterladen muss, schnell zu reduzieren.

An dieser Stelle kommt das Konzept des Sparse File System ins Spiel. Wenn eine Lambda-Containerfunktion initialisiert wird, ist das Dateisystem, in dem das Bild vorhanden sein sollte, leer. Wenn die Lambda-Funktion mit der Ausführung beginnt, werden die Daten des Container-Images in Echtzeit in das Dateisystem gestreamt, das ausgeführt werden soll.

Darüber hinaus speichert der Lambda-Dienst einen gemeinsamen Satz von Ebenen für alle Kunden sowie einen Satz von Ebenen für die einzelnen Kunden. Dadurch verringert sich die Wahrscheinlichkeit, dass der Dienst Inhalte aus einem Container-Repository herunterladen muss, was die Ausführung verlangsamen könnte, da das Dateisystem darauf wartet, dass Inhalte eingespeist werden. Dieser Prozess wird durch Deduplizierung auf der Grundlage verschlüsselter Daten durchgeführt, so dass Containerschichten von mehreren Kunden gemeinsam genutzt werden können, ohne dass die Isolierung zwischen ihnen beeinträchtigt wird.

Das letzte Teil des Puzzles ist die Veröffentlichung von ECR public, das Container-Images über das CloudFront Content Delivery Network verteilt, um den Abruf von Images aus jeder Region zu beschleunigen. Dieser Service passt perfekt zu den neuen Funktionen von Lambda, um einen dedizierten Bereich für das Hochladen von Bildern und den nativen Zugriff darauf innerhalb von AWS zu ermöglichen, während gleichzeitig Lambda-spezifische generische öffentliche Bilder erstellt und verteilt werden können.

Erste Schritte mit Serverless

Falls Sie diesen Vortrag verpasst haben re:Invent 2020 Vortragverpasst haben, gibt Marc Brooker einen großartigen Überblick darüber, wie Lamba die Containerfunktionen hinter den Kulissen optimiert, und inspirierte mich zu diesem Artikel.

Was bedeutet das nun für Sie und Ihr Team? Unabhängig davon, ob Sie sich bereits mit Serverless beschäftigt haben oder ganz neu in das Konzept einsteigen, hilft Containers for Lambda dabei, die Wissenslücke zwischen dem Containerisierungsmodell, das Sie kennen, und dem Serverless-Modell, mit dem einige Teams in Ihrem Unternehmen vielleicht gerade erst anfangen, zu schließen. Es ist jetzt möglich, genau dieselben Pipelines, die Sie für die Erstellung von Images für Ihre Kubernetes- oder ECS-Cluster verwenden, auch für die Skalierbarkeit und den jederzeitigen Einsatz von Lambda zu nutzen. Damit können Sie nicht nur Ihren Code in einer beliebigen Sprache, sondern auch alle Ihre Abhängigkeiten schnell in Lambda einbringen, ohne die Leistung Ihres Codes zu beeinträchtigen.

Natürlich gilt nach wie vor die Regel "mehr Code, längere Kaltstarts". Es ist sinnvoll, Ihre Bildgrößen so klein wie möglich zu halten und die Datenmenge zu reduzieren, die Lambda lesen muss. Dieser Blogbeitrag von Rob Sutter enthält viele nützliche Informationen zur Optimierung Ihrer Images für Lambda (und Container im Allgemeinen).

Lambda hilft dabei, die Lücke zwischen Containerisierung und Serverless zu schließen, aber natürlich gibt es noch viel mehr zu beachten, wenn Sie Ihre Workloads auf ein Serverless-Modell umstellen. Ich arbeite seit 2018 an vollständig serverlosen, skalierbaren Workloads. Wenn Sie daran interessiert sind, Ihr Team auf den neuesten Stand von Lambda zu bringen, können Sie sich gerne mit mir oder meinen Kollegen bei Xebia!