WASM vs. Container-Kaltstarts: Was Laufzeiten sagen

Kaltstart bezieht sich auf die zusätzliche Latenz, die eine Anforderung verursacht, wenn die Ausführungsumgebung initialisiert werden muss, bevor der Anwendungscode ausgeführt wird. Bei einer klassischen Edge- oder serverlosen Funktion ist dies alles andere als ein Randfall: Eine Plattform, die zwischen zwei Verkehrsspitzen auf null Instanzen herunterfährt oder ihre Ausführung auf Dutzende geografisch verteilter Edge-Knoten verteilt, zahlt diese Kosten dauerhaft und nicht nur bei der ersten Bereitstellung.

Das Thema hat im WASM-Ökosystem eine fast symbolische Bedeutung erlangt, seit im März 2019 ein Satz von Solomon Hykes, Mitbegründer von Docker, auf Twitter veröffentlicht wurde: „Wenn WASM+WASI 2008 existiert hätte, hätten wir Docker nicht erstellen müssen. So wichtig ist es. WebAssembly auf dem Server ist die Zukunft des Computings.“ Dies ist die Meinung eines anerkannten Praktikers, keine Messung. Es erklärt, warum das Thema fasziniert, nicht jedoch Ersetzen Sie eine bezogene Figur.

Aurabase bietet zwei Pfade für seine Edge-Funktionen: den Studio-Editor, der Code in der Deno-Laufzeit ausführt, wie in unserem Supabase-Migrationsleitfadendokumentiert, und die aura functions deployCLI, die einen separaten Pfad für in Rust geschriebene und auf Wasmtime in WASM kompilierte Funktionen anstrebt. Es ist dieser zweite Weg, den dieser Artikel beleuchtet, ohne ihm eine Kaltstartfigur zu nennen, die es noch nicht gibt.

Der Unterschied ergibt sich nicht aus einer absolut gesehen schnelleren Laufzeit, sondern aus einem kürzeren Stapel von Schritten zwischen der Abfrage und dem Anwendungscode.

Durch das Starten eines Containers wird der Host-Kernel mobilisiert: Erstellen eines neuen Prozesses, Einrichten der Kontrollgruppen und Namespaces, die ihn isolieren, Mounten der Ebenen des Images und anschließendes Starten der Anwendungslaufzeit im Inneren (Node.js und seine V8-Engine beispielsweise haben selbst Initialisierungskosten). Jeder Schritt fügt Systemaufrufe hinzu und, für ein Bild, das lokal nie gesehen wird, einen Netzwerk-Download, bevor er überhaupt beginnt.

Ein WebAssembly-Modul ist auf der Sprachebene der virtuellen Maschine isoliert, nicht auf der Betriebssystemebene. Ein Modul zu instanziieren bedeutet, seinen linearen Speicher zuzuweisen, seine Importe zu binden und dann zu seinem Einstiegspunkt zu springen, alles innerhalb des bereits gestarteten Prozesses der Host-Laufzeit. Keine neuen Prozesse, keine Image-Ebenen, keine Standard-Dateisystem-Mounts.

Durch die Wahl des Kompilierungsmodus wird eine zusätzliche Variable hinzugefügt. Wasmtime kompiliert beim Laden des Moduls über sein Cranelift-Backend zu JIT oder kann es vorab mit wasmtime compilevorkompilieren, wodurch eine .cwasm-Datei erstellt wird, die bereits in nativen Maschinencode umgewandelt wurde. Durch die frühe Kompilierung (AOT) wird der Kompilierungsschritt aus dem kritischen Pfad der Anfrage entfernt: Dies ist genau der Hebel, den eine kaltstartempfindliche Edge-Architektur aktivieren muss.

# Tatsächlicher Auszug aus dem Aurabase-Repository
# WASM-Laufzeit
wasmtime = { version = "43", features = ["async", "cranelift"] }

Hierbei handelt es sich um eine Produktionsabhängigkeit, nicht um eine Entwicklungsabhängigkeit: Sie bestätigt, dass Wasmtime tatsächlich auf dem CLI-Pfad der Aurabase-Edge-Funktionen ausgeführt wird. Es werden jedoch keine Latenzzahlen bestätigt, was auch so bleibt, solange kein datierter Benchmark veröffentlicht wird.

In diesem Bereich ist die stärkste Quelle ein Branchenforschungsbericht und kein Marketing-Blogbeitrag. Firecracker, die leichte microVM-Technologie, die von AWS entwickelt und insbesondere für Lambda und Fargate verwendet wird, wurde auf der USENIX NSDI 2020-Konferenz von Agache et al. vorgestellt. im Artikel „Firecracker: Lightweight Virtualization for Serverless Applications“.

Dieses Papier dokumentiert eine Startzeit von weniger als 125 ms und einen Speicher-Overhead von weniger als 5 MiB pro Mikro-VM, mit der Möglichkeit, Tausende von Mikro-VMs auf derselben physischen Maschine auszuführen. Hierbei handelt es sich um eine datierte Zahl (2020), die aus einer von Experten begutachteten wissenschaftlichen Veröffentlichung stammt und seitdem in der Literatur zur serverlosen Isolation häufig zitiert wird.

Ein Standard-Docker-Container ist im Allgemeinen länger: von einigen hundert Millisekunden bis zu mehreren Sekunden, abhängig von der Größe des Images, der Notwendigkeit, es herunterzuladen, und der Startzeit der eingebetteten Anwendungslaufzeit. Im Gegensatz zu Firecracker wird hier keine einzelne Zahl allgemein zitiert: Das Ergebnis hängt zu sehr vom getesteten Bild für einen einzelnen Wert ab, um einen Konsens zu erzielen.

Drei Quellen, drei unterschiedliche Status: ein historischer Lieferant, ein Projekt unter der Leitung der Stiftung und eine Forschungsarbeit.

Fastly startete Compute@Edge im Jahr 2019 auf Lucet, seinem eigenen vorkompilierenden WASM-Compiler und seiner Runtime. Bei dieser Markteinführung dokumentierte das Unternehmen WASM-Instanziierungszeiten von unter einer Millisekunde, eine Größenordnung, die einen nachhaltigen Einfluss auf den WASM-Kaltstartdiskurs in der Branche hatte. Im Jahr 2021 stellte Fastly die autonome Entwicklung von Lucet ein und verlagerte seine Bemühungen auf Wasmtime, dessen Cranelift-Kompilierungs-Backend einen Teil dieser Optimierungen übernommen hat: Dies ist einer der Gründe, warum Wasmtime auch heute noch eine Referenz für diese Art von Ladung ist.

WasmEdge, eine WASM-Laufzeit unter CNCF-Governance (ursprünglich SSVM, unterstützt von Second State), behauptet in seiner offiziellen Dokumentation einen deutlich geringeren Start- und Speicherbedarf als ein gleichwertiger Docker-Container, mit einer expliziten Positionierung auf Edge- und IoT-Lasten. Hierbei handelt es sich um eine vom Projektherausgeber selbst veröffentlichte Zahl, die als solche zu lesen ist: eine Produktaussage, keine unabhängige Prüfung.

Auf der Seite der akademischen Forschung baut Faasm (Shillaker & Pietzuch, USENIX ATC 2020, auch in der Vorabveröffentlichung verfügbar) eine zustandsbehaftete serverlose Plattform auf, die auf WebAssembly-Isolation (über WAVM, nicht Wasmtime) basiert, gerade weil es die Instanziierung einer Funktion zu viel geringeren Kosten ermöglicht als die Isolation durch Container oder durch VM. In dem Artikel geht es nicht speziell um Wasmtime, aber er bietet eine unabhängige wissenschaftliche Bestätigung des Strukturarguments im vorherigen Abschnitt.

Wenn man diese drei Laufzeiten nur namentlich vergleicht, verbirgt sich die eigentliche Variable: das gewählte Kompilierungs-Backend, das das Gleichgewicht zwischen Startgeschwindigkeit und Ausführungsleistung radikal verändert.

Singlepass, Wasmers schnellstes Kompilierungs-Backend, existiert genau deshalb, weil sein Team den Kaltstart als eine eindeutige Achse der Leistung bei der stationären Ausführung identifiziert hat: Ein in Singlepass kompiliertes Modul startet schneller, läuft aber bei Spitzenlast langsamer als das gleiche Modul, das in LLVM kompiliert wurde. Es handelt sich um einen akzeptierten Kompromiss, nicht um einen versteckten Fehler.

Diese fünf Zeilen stellen keine einheitliche Klassifizierung dar: Sie stammen aus unterschiedlichen Methoden, Daten und Laufzeitgenerationen. Für eine tiefergehende methodische Kritik der Zuverlässigkeit dieser Art von WASM-Benchmark geht unser Artikel über die Grenzen von WebAssembly-Benchmarks über den vorliegenden Vergleich hinaus, der sich weiterhin auf die konkreten Aussagen der einzelnen Quellen konzentriert.

Der Kaltstartvorteil von WASM kommt vor allem bei den Lasten zum Tragen, die am empfindlichsten auf die Latenz der ersten Anfrage reagieren, und nicht bei allen Lasten gleichermaßen.

Dies belastet insbesondere den sehr unregelmäßigen Edge-Verkehr (Bursts, gefolgt von Stille), die Isolation pro Anfrage statt pro Container, der von mehreren Anfragen gemeinsam genutzt wird, und eine Infrastruktur, die zwischen zwei Spitzen tatsächlich auf null Instanzen herunterfährt, anstatt dauerhaft einen heißen Pool aufrechtzuerhalten. Bei einer stabilen und vorhersehbaren Last, bei der die Instanzen ohnehin heiß bleiben, ist die Kaltstartlücke strukturell weniger wichtig.

WebAssembly unterliegt auch Einschränkungen, die sich vom Kaltstart unterscheiden: Der Zugriff auf das Dateisystem oder das Netzwerk erfolgt über WASI, eine Schnittstelle, die sich abhängig von den Laufzeiten und deren Versionen noch weiterentwickelt, und ein Modul, das für einen schnellen Start kompiliert wurde (Singlepass auf der Wasmer-Seite zum Beispiel), ist nicht unbedingt das schnellste, wenn es einmal unter hoher Last eingerichtet wurde. Kaltstart und Spitzenausführungsleistung bleiben zwei unterschiedliche Achsen, die bei demselben Kompilierungsprofil selten gleichzeitig optimal sind.

Um die Wahl einer Edge-Architektur anhand dieses Kriteriums zu bewerten, muss Aurabase jedem Anbieter drei konkrete Fragen stellen: Welche genaue Laufzeit wird verwendet, welches Kompilierungs-Backend (JIT oder AOT) und wurde die Zahl für den erweiterten Kaltstart von einem unabhängigen Dritten oder nur vom Laufzeitherausgeber selbst gemessen?

Informationen zur Datenbankebene dieses Problems finden Sie in unserem Artikel zum serverlosen Postgres-Kaltstart.