FAASM: Lightweight Isolation for Efficient Stateful Serverless Computing

Abstract

无服务器计算非常适合大数据处理，因为它可以快速且廉价地扩展到数千个并行功能。现有的无服务器平台将功能隔离在短暂的无状态容器中，防止它们直接共享内存。这迫使用户重复复制和序列化数据，增加了不必要的性能和资源成本。我们认为需要一种新的轻量级隔离方法，它支持直接在函数之间共享内存并减少资源开销。

我们介绍了 Faaslets，这是一种用于高性能无服务器计算的新隔离抽象。 Faaslet 使用 WebAssembly 提供的软件故障隔离 (SFI) 来隔离已执行函数的内存，同时允许在同一地址空间中的函数之间共享内存区域。因此，当功能位于同一台机器上时，Faaslet 可以避免昂贵的数据移动。我们的 Faaslets 运行时 FAASM 隔离了其他资源，例如CPU 和网络，使用标准 Linux cgroups，并为网络、文件系统访问和动态加载提供低级 POSIX 主机接口。为了减少初始化时间，FAASM 从已经初始化的快照中恢复 Faaslet。我们将 FAASM 与基于容器的标准平台进行了比较，结果表明，在训练机器学习模型时，它实现了 2 倍的加速，而内存减少了 10 倍；为了服务机器学习推理，FAASM 将吞吐量翻了一番，并将尾部延迟减少了 90%。

Introduction

无服务器计算正在成为部署数据密集型应用程序的流行方式。 功能即服务 (FaaS) 模型将计算分解为许多功能，可以有效地利用云的大规模并行性。 之前的工作已经展示了无服务器如何支持 map/reduce 式作业 [42, 69]、机器学习训练 [17, 18] 和推理 [40] 以及线性代数计算 [73, 88]。 因此，越来越多以不同编程语言实现的应用程序正在迁移到无服务器平台。

Google Cloud Functions [32]、IBM Cloud Functions [39]、Azure Functions [50] 和 AWS Lambda [5] 等现有平台将函数隔离在短暂的无状态容器中。使用容器作为隔离机制给数据密集型应用程序带来了两个挑战，数据访问开销和容器资源占用。

数据访问开销是由基于容器的方法的无状态性质引起的，它强制在外部维护状态，例如在 Amazon S3 [6] 等对象存储中，或在函数调用之间传递。由于每个函数中的重复数据、重复序列化和定期网络传输，这两个选项都会产生成本。这导致当前的应用程序采用低效的“数据传输架构”，即将数据移动到计算中，反之亦然——这种架构在几十年前就被数据管理社区抛弃了 [36]。随着函数数量的增加，这些开销会变得更加复杂，从而减少了无限并行的好处，而这正是使无服务器计算具有吸引力的首要原因。

由于无服务器工作负载的高容量和短期特性，容器资源占用尤其重要。尽管容器比其他机制（例如虚拟机 (VM)）具有更小的内存和 CPU 开销，但在单个短期运行功能的执行与基于进程的容器隔离之间仍然存在阻抗不匹配。容器的启动延迟在数百毫秒到几秒之间，导致当今无服务器平台的冷启动问题 [36, 83]。容器的大内存占用限制了可扩展性——虽然在技术上受限于机器的进程限制，但容器的最大数量通常受可用内存量的限制，在具有 16 GB RAM 的机器上仅支持几千个容器[51]。

当前的数据密集型无服务器应用程序单独解决了这些问题，但从未解决过这两个问题——相反，要么加剧容器资源开销，要么破坏无服务器模型。

一些系统通过在长期存在的 VM 或服务中维护状态来避免数据移动成本，例如 ExCamera [30]、Shredder [92] 和 Cirrus [18]，从而引入了非无服务器组件。为了解决容器的性能开销，系统通常会提高对用户代码的信任度并削弱隔离保证。 PyWren [42] 重用容器来执行多个功能； Crucial [12] 在函数之间共享 Java 虚拟机 (JVM) 的单个实例； SAND [1] 在长寿命容器中执行多个功能，这些容器还运行额外的消息传递服务； Cloudburst [75] 采用了类似的方法，引入了本地键值存储缓存。配置容器以执行多个功能和额外服务会放大资源开销并打破无服务器固有的细粒度弹性扩展。虽然这些系统中有几个通过本地存储减少了数据访问开销，但没有一个提供功能之间的共享内存，因此仍然需要在单独的进程内存中复制数据.

其他系统通过远离容器和虚拟机来减少容器资源占用。 Terrarium [28] 和 Cloudflare Workers [22] 分别使用 WebAssembly 和 V8 Isolates 采用基于软件的隔离； Krustlet [54] 使用 WebAssembly 复制容器以确保内存安全，而 SEUSS [16] 演示了无服务器 unikernel。虽然这些方法减少了资源占用，但它们没有解决数据访问开销，并且仅使用基于软件的隔离并不能隔离资源.

我们观察到无服务器计算可以通过新的隔离抽象更好地支持数据密集型应用程序，该抽象（i）在功能之间提供强大的内存和资源隔离，但（ii）支持有效的状态共享。 数据应与功能位于同一位置并直接访问，从而最大限度地减少数据传输。 此外，这种新的隔离抽象必须 (iii) 允许跨多个主机扩展状态； (iv) 内存占用低，允许在一台机器上运行多个实例； (v) 表现出快速的实例化时间； (vi) 支持多种编程语言，以方便现有应用程序的移植。

在本文中，我们描述了 Faaslets，这是一种用于数据密集型无服务器计算的新型轻量级隔离抽象。 Faaslet 支持具有高效共享内存访问的有状态功能，并由我们的 FAASM 分布式无服务器运行时执行。 Faaslets 具有以下属性，总结了我们的贡献：

(1) Faaslets实现轻量级隔离。 Faaslets 依赖于软件故障隔离 (SFI) [82]，它限制函数访问它们自己的内存。与 Faaslet 关联的函数及其库和语言运行时依赖项被编译为 WebAssembly [35]。 FAASM 运行时然后在单个地址空间内执行多个 Faaslet，每个 Faaslet 都有一个专用线程。对于资源隔离，每个线程的 CPU 周期使用 Linux cgroups [79] 进行限制，并且使用网络命名空间 [79] 和流量整形来限制网络访问。许多 Faaslet 可以在一台机器上高效、安全地执行。

(2) Faaslets 支持高效的本地/全局状态访问。由于 Faaslet 共享相同的地址空间，因此它们可以有效地访问具有本地状态的共享内存区域。这允许数据和函数的共存并避免序列化开销。 Faaslets 使用两层状态架构，本地层提供内存共享，全局层支持跨主机分布式访问状态。 FAASM 运行时为 Faaslets 提供了一个状态管理 API，可以对两个层中的状态进行细粒度控制。 Faaslet 还支持在两层之间具有不同一致性要求的有状态应用程序。

(3) Faaslet 具有快速的初始化时间。为了减少 Faaslet 第一次执行时的冷启动时间，它从挂起状态启动。 FAASM 运行时会提前预初始化 Faaslet 并对其内存进行快照以获得 Proto-Faaslet，该原始 Faaslet 可以在数百微秒内恢复。 Proto-Faaslet 用于快速创建新的 Faaslet 实例，例如避免初始化语言运行时的时间。虽然无服务器快照的现有工作采用单机方法 [1, 16, 25, 61]，但 Proto-Faaslets 支持跨主机恢复并且独立于操作系统。

(4) Faaslets 支持灵活的主机接口。 Faaslet 通过一组类似 POSIX 的网络调用、文件 I/O、全局状态访问和库加载/链接与主机环境交互。这使它们能够支持动态语言运行时，并通过更改少于 10 行的代码来促进现有应用程序的移植，例如 CPython。主机接口提供足够的虚拟化以确保隔离，同时增加可忽略不计的开销。

FAASM 运行时 1 使用 LLVM 编译器工具链将应用程序转换为 WebAssembly，并支持使用多种编程语言编写的函数，包括 C/C++、Python、Typescript 和 Javascript。它与现有的无服务器平台集成，我们描述了使用 Knative [33]，这是一个基于 Kubernetes 的最先进平台。

为了评估 FAASM 的性能，我们考虑了许多工作负载，并将它们与基于容器的无服务器部署进行了比较。在使用 SGD [68] 训练机器学习模型时，我们表明 FAASM 实现了 60% 的运行时间改进、70% 的网络传输减少以及 90% 的内存使用量减少；对于使用 TensorFlow Lite [78] 和 MobileNet [37] 的机器学习推理，FAASM 的最大吞吐量增加了 200% 以上，尾部延迟减少了 90%。我们还展示了 FAASM 使用 Python/Numpy 执行矩阵乘法的分布式线性代数作业，性能开销可忽略不计，网络传输减少 13%。

2 Isolation vs. Sharing in Serverless

共享内存从根本上与隔离目标不一致，因此在多租户无服务器环境中提供对内存中状态的共享访问是一个挑战。