SEUSS：Skip Redundant Paths to Make Serverless Fast 阅读报告

SEUSS 阅读报告

一、论文研究背景、动机与主要贡献

研究背景与动机

​ 首先论文引入了一个计算机领域普遍存在的问题：计算冗余。

​ 计算冗余具体在Serverless 中，可以用Figure1说明：一次完整的函数调用可以细分为多个阶段，如果我们在中间某个阶段保有缓存，下次函数调用从缓存开始，那么一次函数的启动速度将大幅加快（启动时间大幅缩短）。这就是用计算缓存的思想解决Serverless中的计算冗余问题。

• 在传统的解决方案里，我们对于每一次函数调用开启一个专用的容器或者虚拟机，这样的方法是资源密集的，会进行大量重复步骤，出现大量重复的状态

• 本论文提出了一个轻量级的解决方法：从快照部署

主要贡献

​ 论文提出了SEUSS(serverless excution using snapshots) 操作系统。SEUSS在FaaS环境中实现，在性能上具有快速部署和高密度缓存的特点，通过从Unikernel快照部署函数来实现这些期望的属性。

​ 具体实现时，将函数逻辑、语言解释器和SEUSS OS三者打包到unikernel中，并且应用页面级共享的技术（如下图(a)）实现缓存技术。

​ Unikernel的平面地址空间机制使得我们可以方便地将函数运行的某个具体的状态捕获，成为一个内存中的快照。这样从快照去开启一个unikernel跳过了：

• 启动单内核
• 初始化语言
• 导入代码和编译项

​ 也可以说，SEUSS的核心思路是通过unikernel捕获到的快照可供后续使用：可以从unikernel快照部署函数。

2. SEUSS方法论

​ 下面我们详细分析整个SEUSS的设计。首先是Unikernel Context：

2.1 Unikernel Context

​ Unikernel提供了一种机制，用来封装和观察无服务器函数的执行状态。

​ 在SEUSS中，每个单内核上下文(UC)由一个高级语言解释器(例如，Node.js, Python)组成，它可以导入和执行函数代码。

2.2 SnapShots

​ 快照的概念，类似于VMWare中某个虚拟机的快照，我们可以快速从一个虚拟机快照，启动一个处于某个状态的虚拟机。在本论文中，快照是一个只读的数据对象，它表示一个UC的瞬时执行状态（即它的地址空间和寄存器）。快照可以在函数执行的任意一个时间点保存快照，但是如果每次都保存一个完整的快照，就会导致多个快照之间存在重复内容。

​ 为了解决该冗余问题，本论文引入了快照栈的概念。

2.3 SnapShots Stack

​ 快照堆栈表示快照之间跨时间的沿袭关系，将每一个快照视为快照堆栈中上一个快照的页面级差异。怎么理解呢？

​ 简单的说，可以认为他只存储差异部分。可以类比于去计算求解一个大规模问题时采用的增量计算的概念——每次只在上次计算的基础上计算一个$\Delta$。这里是存储上一个页面基础上的差异部分，也就是说我们存储一个增量快照。

​ 以下图为例：一个FaaS平台想要快照JavaScript函数Foo()和Bar()的完全初始化状态。

• 第一种情况：只使用快照机制：

  平台需要两个UC快照，每个功能对应一个。如果解释器是100MB，每个函数增加1MB，我们需要202mb的存储空间。

• 第二种情况是我们引入快照栈：

  我们需要使用三个快照，一个缓存初始化的JavaScript解释器，第二个缓存Foo()差异，第三个缓存Bar()差异。这需要102mb，因为两个函数快照共享解释器

​ 这就是SEUSS解决重复和冗余的一个重要思想。

Anticipatory Optimizations

​ 方案的最后一点是预期优化。AO 的思想是我们在捕获快照之前进行预估，确定在捕获快照的合理时间点，避免过多捕获快照导致的空间冗余和捕获时间不当导致的安全性问题和函数运行错误。

3.SEUSS 实践

​ 我们重点讲解这个 SEUSS 实践的案例。

• 过程C与快照B

​ 从时间轴向后看，最开始是一个构造环境和运行时的过程，语言解释器和Invocation Driver会被加载。在调用驱动程序启动之后，将获取运行时快照B。快照B是一个基本快照，基本快照的数量很少，每个语言的解释器只有一个。可以看到这个快照也是体积最大的。从快照B部署UC，即为coldest path

• 过程W与快照S

​ 接着向后，Invocation Driver将函数和命令发送到单内核，经过编译后，我们若在这里进行一个快照就是快照S，若从快照S部署UC，我们称作Warm path

• 过程H

​ 最后，我们向其中传入参数，参数传入后，就可以运行了。对于这个过程我们称为hot path。

​ 上述的快照B和快照S如何使用呢？

• 当我们不存在具体函数的快照时，我们从基本快照 快照B 部署UC

  这样可以有效减少构建环境和初始化运行时的时间开销

• 若存在函数的快照时，我们从该快照创建UC，跳过代码导入，编译阶段。

  从这个快照部署UC，那么直接导入参数就可以运行。

这样通过快照的使用实现计算缓存。

4.实现

下面是整个实验实现的架构。

• EBBRT [35]框架构建的SEUSS OS原型
• Rumprun
• UCS在用户模式（环3）中执行，并具有基于页面的硬件保护
• Seuss OS中的网络层伪装了进入UCS的流量，允许外部TCP连接从访客功能中初始化

---

​ 对于实现部分，这里详细说明的是快照技术的实现和写时复制的思想，这是SEUSS减少冗余的核心之一。

​ Seuss OS使用对硬件页表的直接访问来捕获快照，部署UCS，并在快照堆栈和UCS上启用页面级共享。我们针对下面三个方面说明：

• 何时触发快照的捕获？

​ 使用x86 debug寄存器来触发快照的创建。在希望保存位置设置断点，当发生单步中断时，就会陷入到内核模式之后跳转到中断处理程序，中断处理程序将UC状态进行快照。

• 快照的使用？

​ 为了保持快照的轻量，我们每个快照仅将肮脏的页面克隆，即采用copy-on-write的思想。在论文实现中使用了硬件语义，通过X86 Dirty Bits跟踪页面使用。

• 怎样部署快照？

​ 从快照部署始于创建新的UC，进行的是页面的浅拷贝。

5.总结

论文的优点：

• 快照的不同：基本快照和特定状态的快照

  前者具有消除冗余计算的长期价值，后者是短暂可丢弃的。做这样的区分可以显著提高性能

• 页面级共享

  减少冗余的关键思想

• 使用的技术较为简单

• 由于缓存存在能够处理爆发式的请求

缺点：

• 页面级的共享：容易受到侧通道攻击和硬件级别漏洞的影响
• 未来若考虑并行程度和规模的提高，需要采用更加新进的共享技术