好好活就是有意义的事,有意义的事就是好好活
Catalyzer: Sub-millisecond Startup for Serverless Computing with Initialization-less Booting
Catalyzer: Sub-millisecond Startup for Serverless Computing with Initialization-less Booting

Catalyzer: Sub-millisecond Startup for Serverless Computing with Initialization-less Booting

Catalyzer: Sub-millisecond Startup for Serverless Computing with Initialization-less Booting

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

Abstract

无服务器计算为高生产力软件开发带来了成本效益和弹性。为此,无服务器沙箱系统必须解决两个挑战:功能实例之间的强隔离,以及确保用户体验的低启动延迟。虽然基于虚拟化的沙箱可以提供强隔离,但沙箱和应用程序的初始化会导致不可忽略的启动开销。由于其与应用程序无关的性质,传统沙箱系统在低延迟启动方面存在不足:它们只能通过虚拟机管理程序和来宾内核定制来减少沙箱初始化的延迟,这是不够的,并且不能减轻大部分启动开销。

本文提出了 Catalyzer,这是一种无服务器沙箱系统设计,可提供强隔离和极快的功能启动。 Catalyzer 不是从头启动,而是从格式良好的检查点映像恢复基于虚拟化的功能实例,从而跳过关键路径上的初始化(无初始化)。 Catalyzer 通过按需恢复用户级内存状态和系统状态来提高恢复性能。我们还提出了一个新的 OS 原语 sfork(沙箱分叉),通过直接重用正在运行的沙箱实例的状态来进一步减少启动延迟。从根本上说,Catalyzer 通过重用状态来消除初始化成本,从而实现对各种无服务器功能的一般优化。评估表明,Catalyzer 将启动延迟降低了几个数量级,在最佳情况下实现了 <1 毫秒的延迟,并显着降低了实际工作负载的端到端延迟。

Introduction

无服务器计算是云计算的新趋势范式,将开发人员从管理服务器的注意力中解放出来,并且已经得到许多平台的支持,包括 Amazon Lambda [2]、IBM Cloud Function [1]、Microsoft Azure Functions [3] 和谷歌云函数 [7]。在无服务器计算中,计算单位是一个函数。当收到服务请求时,无服务器平台会分配一个临时执行沙箱并实例化用户定义的函数来处理请求。这种计算模型将动态管理云资源的责任转移给了云提供商,让开发人员可以完全专注于他们的应用程序逻辑。此外,云提供商可以更有效地管理他们的资源。

临时执行沙箱通常是容器 [1]、虚拟机 [20、44] 或最近提出的轻量级虚拟化设计 [6、8、19、35、37、41、45]。然而,容器实例存在隔离问题,因为它们共享一个内核,这很容易出错。虚拟机可以实现更好的隔离,但太重而无法运行无服务器功能。 Google gVisor [8] 和 Amazon FireCracker [6] 等轻量级虚拟化设计通过自定义主机-访客接口(例如,gVisor 使用进程抽象接口)来实现高性能、易于资源管理和强隔离。


以低延迟执行无服务器功能对于用户体验至关重要 [21, 24, 28, 32, 38],并且仍然是基于虚拟化的沙箱设计的重大挑战。为了解释严重性,我们对DeathStar [22]、电子商务微服务和图像处理功能三个基准进行端到端评估,并将延迟分为“执行”部分和“启动”部分(§ 6.4)。我们计算了测试的 14 个 serverless 函数的“执行/总体”比率,并在图 1 中呈现了 CDF。gVisor 中的 12 个函数(共 14 个)的比率甚至不能达到 30%,表明启动在总体上占主导地位潜伏。长启动延迟,尤其是基于虚拟化的沙箱,已成为无服务器平台的重大挑战。

现有的基于虚拟机的沙箱 [6, 8, 37] 通过虚拟机管理程序定制减少了启动延迟,例如 FireCracker 可以在 100 毫秒内启动一个虚拟机(微型虚拟机)和最小化的 Linux 内核。但是,它们都不能像 JVM 或 Python 解释器设置时间那样减少应用程序初始化延迟。我们对无服务器函数(由五种编程语言编写)的研究表明,大部分启动延迟来自应用程序初始化(Insight I)。

本文提出了 Catalyzer,这是一种促进无服务器计算启动的通用设计。 Catalyzer 的关键思想是从格式良好的检查点图像中恢复实例,从而跳过关键路径上的初始化。该设计基于两个额外的见解:首先,执行阶段的无服务器函数通常只访问初始化阶段(Insight II)中使用的一小部分内存和文件,因此我们可以按需恢复两个应用程序状态(例如,内存中的数据)和系统状态(例如,文件句柄/描述符)。其次,相同函数的沙箱实例具有几乎相同的初始化状态(洞察 III),因此可以重用运行沙箱的大部分状态来产生新的沙箱。具体来说,Catalyzer 采用用户级和系统状态的按需恢复。并且它提出了一个新的 OS 原语 sfork(sandbox fork),通过直接重用正在运行的沙盒实例的状态来进一步减少启动延迟。从根本上说,Catalyzer 通过重用状态来消除初始化成本,从而可以对各种无服务器功能进行一般优化。

我们已经实现了基于 gVisor 的 Catalyzer。我们使用微基准测试和用五种编程语言开发的实际应用程序来衡量性能。

结果表明,Catalyzer 可以在 C-hello(最佳情况)上实现 <1ms 的启动延迟,以及 <2ms 来启动 Java SPECjbb,比基准 gVisor 加速 1000 倍。我们还展示了对服务器机器的评估,并分享了我们从蚂蚁金服的工业发展中吸取的经验教训。本文的主要贡献如下:

  • 无服务器计算延迟开销的详细分析(第 2 节)。
  • 无 Init 启动的通用设计,可促进各种无服务器应用程序的启动(第 3 节和第 4 节)。
  • Catalyzer 在最先进的无服务器沙箱系统 Google gVisor(第 5 节)上的实现。
  • 使用微基准测试和真实世界的无服务器应用程序进行的评估证明了 Catalyzer 的效率和实用性(第 6 节)。
  • 在真实平台上部署 Catalyzer 的经验(第 6.9 节)。

发表回复

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