Faasm: Lightweight Isolation for Efficient Stateful Serverless Computing [zotero-users-5466518-xg9mvxpy]

Our run- time for Faaslets, FAASM, isolates other resources, e.g. CPU and network, using standard Linux cgroups, and provides a low-level POSIX host interface for networking, file system access and dynamic loading. To reduce initialisation times, FAASM restores Faaslets from already-initialised snapshots.

Containers have start-up latencies in the hundreds of milliseconds to several seconds, leading to the cold-start problem in today’s serverless platforms [36, 83].

Terrarium [28] and Cloudflare Workers [22] employ software-based isolation us- ing WebAssembly and V8 Isolates, respectively; Krustlet [54] replicates containers using WebAssembly for memory safety; and SEUSS [16] demonstrates serverless unikernels

Data should be co-located with functions and ac- cessed directly, minimising data-shipping.

Faaslets use a two-tier state architecture, a local tier provides in-memory sharing, and a global tier supports distributed access to state across hosts. The FAASM runtime provides a state management API to Faaslets that gives fine-grained control over state in both tiers

To reduce cold- start time when a Faaslet executes for the first time, it is launched from a suspended state. The FAASM run- time pre-initialises a Faaslet ahead-of-time and snapshots its memory to obtain a Proto-Faaslet, which can be re- stored in hundreds of microseconds.

The host interface provides just enough virtualisation to ensure isolation while adding a negligible overhead. The FAASM runtime1 uses the LLVM compiler toolchain to translate applications to WebAssembly and supports func- tions written in a range of programming languages, including C/C++, Python, Typescript and Javascrip

There is a proposal to add a form of syn- chronised shared memory to WebAssembly [85], but it is not well suited to sharing serverless state dynamically due to the required compile-time knowledge of all shared regions. It also lacks an associated programming model and provides only local memory synchronisation.

The host interface integrates with the serverless runtime through a message bus (see Fig. 1). The message bus is used by Faaslets to communicate with their parent process and each other, receive function calls, share work, invoke and await other functions, and to be told by their parent process when to spawn and terminate.

Dynamic linking. Some legacy applications and libraries re- quire support for dynamic linking, e.g. CPython dynamically links Python extensions. All dynamically loaded code must first be compiled to WebAssembly and undergo the same validation process as other user-defined code (§3.

Faaslets do this by adding the new concept of shared regions to the existing WebAssembly memory model [35]. Shared regions give functions concurrent access to disjoint segments of shared process memory, allow- ing them direct, low-latency access to shared data structures.

Faaslets allocate shared process memory through calls to mmap on the underlying host, passing MAP_SHARED and MAP_ANONYMOUS flags to create shared and private regions, re- spectively, and remap these regions with mremap

When Faaslets are deployed, the compilation phase to gen- erate the WebAssembly binary takes place on a user’s ma- chine. Since that is untrusted, the code generation phase begins by validating the WebAssembly binary, as defined in the WebAssembly specification [35

Faaslets write changes from the local to the global tier by performing a push, and read from the global to the local tier by performing a pull. DDOs may employ push and pull op- erations to produce variable consistency, such as delaying updates in an eventually-consistent list or set, and may lazily pull values only when they are accessed, such as in a dis- tributed dictionary. Certain DDOs are immutable, and hence avoid repeated synchronisation.

The authoritative state value for each key is held in the global tier, which is backed by a distributed key-value store (KVS) and accessible to all Faaslets in the cluster. Faaslets on a given host share a local tier, containing replicas of each state value currently mapped to Faaslets on that host

To achieve this without modifications to the underlying platform’s scheduler, FAASM uses a distributed shared state scheduler similar to Omega [71]. Function calls are sent round-robin to local schedulers, which execute the function locally if they are warm and have capacity, or share it with another warm host if one exists.

Proto-Faaslet snapshot includes a function’s stack, heap, function table, stack pointer and data, as defined in the We- bAssembly specification [35]. Since WebAssembly memory is represented by a contiguous byte array, containing the stack,heap and data, FAASM restores a snapshot into a new Faaslet using a copy-on-write memory mapping.

The increased network transfer, memory usage and du- ration in Knative is caused primarily by data shipping, e.g. loading data into containers.

To highlight the impact of this sharing, we include the proportional set size (PSS) and resident set size (RSS) memory consumption. Initiali- sation times and CPU cycles are measured across repeated executions of a no-op function.

GraalVM has recently added support for WebAssembly and could be adapted for Faaslets