Berkeley zu Serverless Computing, Teil 2:Perspektiven Wie Function as a Service (FaaS) sein könnte

Serverless hat Stärken, aber als junge Technologie auch noch erhebliche Schwächen. Wie lassen sich diese beseitigen, um Serverless leistungsfähiger zu machen?

Anbieter zum Thema

Dell GmbH

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

Wegen seines aus Anwendersicht vereinfachten Managements könnte Serverless Computing auch zur Alternative für die Private Cloud werden. Doch bis dahin sollten einige Schwächen der Technologie, die heute noch stören, behoben sein.

Wo sie liegen, beschreibt eine Forschergruppe aus den Fakultäten Elektro-Ingenieurwissenschaften und Computer Science an der Universität Berkeley. im Umgang mit gespeicherten Daten und der Kommunikation zwischen Funktionen, so das Forschungspapier: „Cloud Programming Simplified: A Berkeley View on Serverless Computing“.

Berkeley zu Serverless Computing, Teil 1: Die Grenzen

Serverless hinkt bei Datenbanken

Die Gruppe befasste sich aber auch damit, wie die bislang vorhandenen Nachteile von FaaS (Function as a Service) behoben werden könnten. Hierfür gibt es verschiedene Wege. Die Forschungsgruppe setzt bei den Themen Abstraktion, System, Netzwerk, Sicherheit und Computerarchitektur an.

Abstraktion bei FaaS verbessern

Schwierigkeiten ergeben sich heute, weil Entwickler für ihre Funktionen nur den Speicherbedarf und eine Grenze für die Ausführungszeit spezifizieren dürfen. Sinnvoll wäre es, wenn Anwender auch noch spezifische Ressourcen, zum Beispiel Beschleuniger, vorgeben könnten. Ein anderer Weg bestünde darin, dass der interne oder externe Provider eine automatisierte Code-Analyse durchführt und dann automatisch die für die Funktion optimalen Ressourcen bereitstellt.

Zudem kennen Serverless-Plattformen heute die Datenabhängigkeiten zwischen unterschiedlichen Funktionen genauso wenig wie die Menge des erforderlichen Datenaustauschs zwischen ihnen. Das führt gegebenenfalls zu suboptimalen Ausführungszeiten. Hier schlagen die Wissenschaftler aus Berkeley ein API vor, über das eine Applikation ihren Computation-Graph einspielen kann.

Welche Storage ist die richtige?

Serverless-Funktionen brauchen einerseits dauerhafte Storage und andererseits Storage für Daten, die nur vorübergehend gehalten werden. Eine Möglichkeit, letzteren bereitzustellen wäre, einen verteilten In-Memory-Service mit einem optimierten Netzwerkstack zu nutzen. Das kann die Verzögerung auf Mikrosekunden drücken.

Ein entsprechender Service müsste die Speicherkapazität und auch die Verarbeitungsleistung nach Anforderung ad hoc und automatisch anpassen können, also auch nicht mehr benötigten Speicher für andere Aufgaben freigeben. Dass das prinzipiell möglich ist, beweist das Forschungsprojekt RAMCloud, das an der Universität Stanford entwickelt wird. Das „RAM-Cloud“-Storagesystem erreicht mit statistischem Multiplexing geringere Latenzen als beim Rechnen auf einem Server.

Die dauerhafte Storage für das Stateless Computing muss leistungsstark und schnell sein und zudem die Semantik eines Filesystems mitbringen. Die Berkeley-Wissenschaftler schlagen hier vor, einen gemeinsam genutzten SSD-Speicher mit einem verteilten In-Memory-Cache zu kombinieren, wie das etwa der in Berkeley entwickelte Key-Value-Store Key-Value-Store „Anna“ tut.

Entsprechende Storage-Services sollten transparent bereitgestellt und mandantensicher sein. Löschen darf dieser Storage-Bereich nur auf Befehl.

Signalisierung und schneller Start von Serverless-Funktionen

Da eine Funktion oft die Ergebnisse einer anderen verarbeitet, müssen solche Funktionen koordiniert werden. Hierfür eignen sich Signalisierungssysteme. Denn sie haben nur Mikrosekunden Verzögerung, liefern verlässliche Resultate und können Daten auch an viele Empfänger oder spezifische Gruppen versenden.

Das Starten von Funktionen kann durch den Einsatz von Unikernels beschleunigt werden, die für bestimmte Ressourcen vorkonfiguriert sind und die Datenstrukturen statistisch den Ressourcen zuweisen. Zudem arbeiten sie nur mit den Treibern und Bibliotheken, die für die Applikation nötig sind. Jede Applikation braucht allerdings ihren eigenen Unikernel.

Software-Ausblick: Serverless, Funktionen und Unikernels

Was kommt nach den Containern?

Auch applikationsinterne Initialisierungsvorgänge sind eine weitere Verzögerungsquelle für FaaS. Doch könnte die Infrastruktur über eine API ein „Bereit“-Signal schicken, damit Funktionen nicht mit Arbeit beladen werden, bevor sie startbereit sind.

Schnellere, sicherere Kommunikation mit Serverless

Damit die Kommunikation zwischen Funktionen nicht überbordet, kann man für das Abarbeiten mehr Cores bereitstellen. Über sie können die Funktionen vor dem eigentlichen Rechnen Daten gemeinsam nutzen und kombinieren.

Außerdem können mehrere Cloud-Funktionen auf derselben Virtuellen Maschine platziert werden. Schließlich ließe sich ein Computational-Graph für jede Funktion erstellen, so dass die Beziehungen zwischen einzelnen Funktionen und Rechenschritten klar sind und Ressourcen entsprechend verteilt werden können.

Mehr Sicherheit für Serverless

Auf jeden Fall muss verhindert werden, dass eine angreifende Malware-Funktion auf derselben Ressource gemeinsam mit einem Angriffsziel, einer weiteren Funktion, ausgeführt wird. Denn dann kann die Angreifer-Funktion ungehemmt auf die angegriffene Funktion zugreifen. Hier könnten, so die Berkeley-Wissenschaftler, Scheduling-Algorithmen helfen, die potentielle Angreifer erkennen und auf anderen Ressourcen platzieren – allerdings leidet darunter die Gesamt-Systemauslastung.

Problematisch ist die Übertragung von Sicherheitsfunktionen aus dem Server-Rechnen auf Serverless-Plattformen. Dafür braucht man unter Umständen besonders kleinteilig differenzierbare, dynamische Sicherheits-APIs. Auf Systemebene sollte jede Funktion durch sorgfältig differenzierte Zugriffsrechte isoliert werden können, ohne die Startzeit zu verlängern. Hierfür bringen die großen Hyperscaler derzeit spezielle „leichte“ Isolierungstechniken wie „Google gVisor“ oder „AWS Firecracker“. Ob und wann es Entsprechendes für die Private Cloud geben wird, ist noch nicht klar.

Schließlich muss verhindert werden, dass Cloud-Funktionen Informationen wie Zugriffsmuster oder Timing-Informationen nach außen geben. Hier schlagen die Wissenschaftler „vergessliche“ Applikationen vor, die allerdings leider hohen Overhead produzieren.

Das Problem der Prozessorzuteilung bei FaaS

Für Serverless/FaaS optimierte Prozessoren gibt es noch nicht. Doch schon bald könnten auf spezifische Hochsprachen zugeschnittene Recheneinheiten auf den Markt kommen. Ansätze wie „RISC-V“ mit ihrem Baukastencharakter oder die Neoverse-Plattform von ARM sind nur zwei Beispiele, die in diese Richtung weisen.

Die zweite Methode, die die Wissenschaftler vorschlagen, um die Leistung von Serverless Computing zu optimieren, sind „Domain Specific Architectures“ (DAS), also anwendungsspezifische Recheneinheiten. Beispiele dafür gibt es schon: GPUs (Graphical Processing Units) oder TPUs (Tensor Processing Units).

(ID:45781103)