Sledge: a Serverless-first, Light-weight Wasm Runtime for the Edge
Metadane
- Autorzy: Sean Boucher, Anuj Kalia, David G. Andersen, Michael Kaminsky (Carnegie Mellon University + Intel Labs)
- Rok: 2020
- Źródło: ACM/IFIP International Middleware Conference (Middleware 2020), pp. 265–279
- DOI/Link: 10.1145/3423211.3425680
- Status: reference
- Cytowania: ~100+
- Tagi:
#reference#serverless#webassembly#edge-computing#runtime
Streszczenie
Sledge to serverless-first edge runtime oparty na WebAssembly jako mechanizmie izolacji. Zaprojektowany dla deploymentu na urządzeniach edge (w tym ARM), gdzie zasoby są ograniczone. Główna innowacja: cooperative scheduler (zamiast preemptive) eliminujący overhead context switch, oraz WASM sandboxing zamiast OS-level isolation.
System hostuje wiele funkcji Wasm w jednym procesie z cooperative multitasking. Funkcje muszą wywoływać punkty yield — podobnie jak green threads lub async/await. Eliminuje overhead syscall i context switch jądra.
Kluczowe Wnioski
- Architektura: jeden proces, wiele Wasm sandboxów z cooperative scheduling
- Izolacja: WASM linear memory + brak dostępu do systemu plików/sieciowego (bez OS overhead)
- Platform: x86_64 + ARM (kluczowe dla edge)
- Throughput: wyższy niż Docker dla short-lived HTTP functions na edge
- Latencja: niski jitter dzięki cooperative scheduling (brak preemption)
Metodologia
Implementacja w C na bare metal Linux. Ewaluacja na Intel Xeon + ARM Cortex-A57. Workloady: HTTP echo, image resize, AES encryption. Porównanie z Docker (cold start, throughput) i Node.js (baseline JS).
Główne Koncepcje
- Cooperative scheduling: funkcja jawnie oddaje kontrolę w punktach yield (vs preemptive OS scheduling)
- WASM sandbox: izolacja przez WebAssembly linear memory, bez OS namespaces
- Serverless-first design: runtime zoptymalizowany pod short-lived functions, nie pod długo żyjące usługi
- Edge deployment: obsługa ARM, niskie zużycie zasobów
Wyniki
Sledge osiąga niższy overhead izolacji niż Docker przy zachowaniu bezpieczeństwa. Cooperative scheduler redukuje jitter latencji. Praca demonstruje że WASM jest viable jako mechanizm izolacji dla edge serverless.
Luka dla JE
Gap badawczy: Sledge mierzy latencję i throughput, ale nie energię. Dla projektu JE:
- Sledge (WASM, cooperative) vs Node.js (process, preemptive) — który model izolacji jest energetycznie tańszy dla JS workloadów?
- ARM deployment Sledge to bezpośredni kontekst dla edge JS runtimes (Cloudflare Workers na ARM)
- Cooperative scheduling może być bardziej energooszczędny (brak overhead context switch) — niezbadane
Jest to referencja dla JE-14 (koszt izolacji) i JE-15 (EcoRuntime — cooperative scheduling jako opcja).
Powiązane Tematy
- Faasm (Shillaker 2020) — WASM isolation dla stateful serverless (pokrewna architektura)
- Firecracker (Agache 2020) — MicroVM (silniejsza izolacja, wyższy overhead)
- WinterCG — standard API dla JS runtimes (Sledge jest WASM, nie JS-specific)
- Cloudflare Workers — V8 Isolates (JS-native, nie WASM-first)
Notatki
Publikacja dodana jako referencja. Brak PDF.