好好活就是有意义的事,有意义的事就是好好活
Nightcore: Efficient and Scalable Serverless Computing for Latency-Sensitive, Interactive Microservices
Nightcore: Efficient and Scalable Serverless Computing for Latency-Sensitive, Interactive Microservices

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

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

Please wait while flipbook is loading. For more related info, FAQs and issues please refer to DearFlip WordPress Flipbook Plugin Help documentation.

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)。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注