Nightcore: Efficient and Scalable Serverless Computing for Latency-Sensitive, Interactive Microservices

Abstract

微服务架构是一种流行的软件工程方法，用于构建灵活的、大规模的在线服务。无服务器函数或函数即服务 (FaaS) 提供了一个简单的无状态函数编程模型，它可以取代容器化 RPC 服务器, 很自然的成为实现微服务的无状态 RPC 处理程序的基础 。但是，当前的无服务器平台具有毫秒级的运行时开销，无法满足现有交互式微服务要求的严格的亚毫秒级延迟目标.

我们展示了 Nightcore，这是一种无服务器函数运行时，具有微秒级开销，可在函数之间提供基于容器的隔离。 Nightcore 的设计仔细考虑了具有微秒级开销的各种因素，包括函数请求的调度、通信原语、I/O 的线程模型和并发函数执行。 Nightcore 目前支持用 C/C++、Go、Node.js 和 Python 编写的无服务器函数。我们的评估表明，在运行对延迟敏感的交互式微服务时，Nightcore 实现了 1.36× – ×2.93 倍的更高吞吐量和高达 69% 的尾部延迟降低.

Introduction

微服务架构是一种流行的软件工程方法，用于构建大规模在线服务。它已被亚马逊、Netflix、LinkedIn、Uber 和 Airbnb 等大公司广泛采用 [1, 4, 5, 42, 47]。微服务架构使大型系统能够更快地发展，因为每个微服务都是独立开发、测试和部署的 [36, 49]。微服务通过预定义的 API 相互通信，主要使用远程过程调用 (RPC) [70]。因此，微服务的主要设计模式是每个微服务都是一个 RPC 服务器，它们部署在容器编排平台（如 Kubernetes）之上 [29, 54, 70]。

Serverless为构建基于微服务的应用程序提供了一种新方法 [10, 18, 44, 52]，其好处是大大降低了操作复杂性 (&2)。无服务器函数或函数即服务 (FaaS) 提供了一种简单的无状态函数编程模型。这些函数为在微服务中实现无状态 RPC 处理程序提供了一个自然的基础，作为容器化 RPC 服务器的替代方案。然而，现成的 FaaS 系统的调用延迟开销从几毫秒到几十毫秒不等 [14, 55, 84]（见表 1），这使得它们成为对延迟敏感的交互式微服务的糟糕选择，其中 RPC 处理程序只运行数百微秒到几毫秒 [70, 83, 100, 101]（见图 1）。微服务架构也意味着 FaaS 系统的高调用率，带来了性能挑战。以图 1 为例，一个上传新社交媒体帖子的请求会产生 15 个无状态 RPC（图中蓝色框）。我们在此工作负载上的实验表明，每秒 100K RPC 是一个现实的性能目标，可以在使用五个 8-vCPU RPC 服务器虚拟机的非无服务器部署下实现。一个 FaaS 系统要想高效支持交互式微服务，至少要达到现有 FaaS 系统无法实现的两个性能目标：（1）调用延迟开销在 100𝜇s 以内； (2) 在低CPU使用的情况下, 调用率必须扩展到 100K/s。

之前的一些研究 [62, 98] 通过利用基于软件的故障隔离 (SFI) 将 FaaS 运行时开销减少到微秒级，这削弱了不同功能之间的隔离保证。 我们更喜欢容器提供的更强隔离，因为这是容器化 RPC 服务器设置的标准，并由流行的 FaaS 系统（如 Apache OpenWhisk [50] 和 OpenFaaS [37]）提供。 但是在提供容器隔离的同时实现我们的性能目标是一项技术挑战。

我们展示了 Nightcore，这是一种无服务器功能运行时，旨在将高性能与基于容器的隔离相结合。 任何微秒或更大规模的性能开销都可能阻止 Nightcore 达到其性能目标，从而在 FaaS 系统中激发“寻找杀手级微秒”[60]。

现有的 FaaS 系统如 OpenFaaS [37] 和 Apache OpenWhisk [50] 共享一个通用的高级设计：所有功能请求都由前端（主要是 API 网关）接收，然后转发到执行功能代码的独立后端。前端和后端大多在单独的服务器上执行以实现容错，这需要包含至少一次网络往返的调用延迟。尽管数据中心网络性能正在提高，但同一 AWS 区域中两个 VM 之间的往返时间 (RTT) 范围从 101𝜇 到 237𝜇 [25]。 Nightcore 的动机是注意到在函数执行期间进行的内部函数调用的普遍性（参见图 1）。内部函数调用是由微服务的执行生成的，而不是由客户端生成的（在这种情况下，它将是网关接收的外部函数调用）。我们所说的内部函数调用在之前的工作中被称为链式函数调用 [98]。 Nightcore 在进行调用的同一后端服务器上安排内部函数调用，从而消除了通过网关的行程并降低了延迟 (&3.2)。

Nightcore 对内部函数调用的支持使得大多数通信都在本地进行，这意味着其进程间通信 (IPC) 必须是高效的。 流行的、功能丰富的 RPC 库，如 gRPC 为 IPC 工作（通过 Unix 套接字），但 gRPC 的协议增加了约 10𝜇s [60] 的开销，促使 Nightcore 为 IPC 设计自己的消息通道（3.1）。 Nightcore 的消息通道建立在 OS 管道之上，传输固定大小的 1KB 消息，因为之前的研究 [83, 93] 表明 1KB 对大多数微服务 RPC 来说已经足够了。 我们的测量显示 Nightcore 的消息通道在 3.4𝜇 秒内传送消息，而基于 Unix 套接字的 gRPC 需要 13𝜇 秒才能发送 1KB RPC 有效负载。

之前的工作已经显示 Linux 的线程调度器 [60, 92, 100] 中的微秒级延迟，导致数据平面操作系统 [61, 77, 87, 91, 92, 94] 构建自己的调度器以降低延迟。 Nightcore 依赖于 Linux 的调度程序，因为为微秒级任务构建高效的分时调度程序是一个持续的研究主题 [63, 77, 84, 91, 96]。 为了支持 ≥100K/s 的调用率，Nightcore 的引擎（& 4.1）使用事件驱动的并发 [23, 105]，允许它使用少量 OS 线程处理许多并发 I/O 事件。 我们的测量表明，4 个操作系统线程可以处理 100K/s 的调用率。 此外，Nightcore 引擎中的 I/O 线程可以通过消息通道唤醒函数工作线程（执行函数代码的地方），这确保引擎的调度只受到 Linux 调度程序的单个唤醒延迟。

现有的 FaaS 系统不为应用程序提供并发管理。 然而，即使在稳定的外部请求率下，基于阶段的微服务也会产生内部负载变化 [73, 105]。 之前的研究 [38、73、104、105] 表明，对于突发负载过度使用并发会导致整体性能下降。 与现有的 FaaS 系统不同，Nightcore 主动管理并发性，为随输入负载调整的并发函数执行提供动态计算目标（& 3.3）。 Nightcore 的托管并发降低了 CPU 利用率（见图 4），从而提高了整体性能和效率，并在不同的请求率（& 5.2）下保持稳健。

我们在四个交互式微服务上评估 Nightcore 原型，每个微服务都有自定义工作负载。 三个来自 DeathStarBench [70]，一个来自 Google Cloud [29]。 这些工作负载最初是在 RPC 服务器中实现的，我们将它们移植到 Nightcore 以及 OpenFaaS [37] 以进行比较。 评估表明，只有仔细发现并消除微秒级延迟，Nightcore 才能使用无服务器功能高效实现对延迟敏感的微服务。

本文做出以下贡献。

• Nightcore 是针对微秒级微服务优化的 FaaS 运行时。 它实现了低于 100𝜇s 的调用延迟开销，并在 CPU 使用率低的情况下有效支持 100K/s 的调用率。 Nightcore 可在 GitHub ut-osa/nightcore 上公开获得。
• Nightcore 的设计使用多种技术来消除微秒级开销，包括内部函数调用的快速路径、IPC 的低延迟消息通道、I/O 的高效线程以及使用动态计算并发提示的函数执行 (&3)。
• 以容器化的RPC服务器为基准，Nightcore的吞吐量提高了1.36×2.93倍，尾延迟降低了69%，而OpenFaaS仅实现了基准吞吐量的29%×38%，尾延迟提高了3.4倍 (&5)。