简介：USENIX ATC (USENIX Annual Technical Conference) 学术会议是计算机系统畛域的顶级会议，入选中国计算机协会（CCF）举荐 A 类国内会议列表；本次会议共投稿 341 篇论文，接管 64 篇，录用率 18.8%。阿里云 Serverless 团队第一个提出在 FaaS 场景下的去中心化疾速镜像散发技术，团队创作的论文被 USENIX ATC’21 录用。

作者 | 王骜
起源 | Serverless 公众号

导读

​
USENIX ATC (USENIX Annual Technical Conference) 学术会议是计算机系统畛域的顶级会议，入选中国计算机协会（CCF）举荐 A 类国内会议列表；本次会议共投稿 341 篇论文，接管 64 篇，录用率 18.8%。

阿里云 Serverless 团队第一个提出在 FaaS 场景下的去中心化疾速镜像散发技术，团队创作的论文被 USENIX ATC’21 录用。以下是论文核心内容解读，重点在缩短阿里云函数计算产品 Custom Container Runtime 的函数冷启动端到端提早。

USENIX ATC 将于 7.14-7.16 在线上举办，论文信息见：
https://www.usenix.org/conference/atc21/presentation/wang-ao​

摘要

Serverless Computing（FaaS）是一种新的云计算范式，它容许客户只关注本身的代码业务逻辑，零碎底层的虚拟化、资源管理、弹性伸缩等都交给云零碎服务商进行保护。Serverless Computing 上反对容器生态，解锁了多种业务场景，然而因为容器镜像简单，体积较大，FaaS 的 workload 动态性高且难以预测等个性，诸多业界当先的产品和技术并不能很好的利用于 FaaS 平台之上，所以高效的容器散发技术在 FaaS 平台上面临着挑战。
​
在这篇论文中，咱们设计并提出 FaaSNet。FaaSNet 是一个具备高伸缩性的轻量级零碎中间件，它利用到镜像减速格局进行容器散发，指标作用场景是 FaaS 中突发流量下的大规模容器镜像启动（函数冷启动）。FaaSNet 的外围组件蕴含 Function Tree (FT)，是一个去中心化的、自均衡的二叉树状拓扑构造，树状拓扑构造中的所有节点全副等价。

咱们将 FaaSNet 集成在函数计算产品上，试验结果表明，在高并发下的申请量下，相比原生函数计算（Function Compute, 下称 FC），FaaSNet 能够为 FC 提供 13.4 倍的容器启动速度。并且对于因为突发申请量带来的端到端提早不稳固工夫，FaaSNet 相比 FC 少用 75.2% 的工夫能够将端到端提早复原到失常程度。
​

论文介绍

1. 背景与挑战

FC 于 2020 年 9 月反对自定义容器镜像（https://developer.aliyun.com/article/772788）性能，相继 AWS Lambda 在同年 12 月颁布了 Lambda container image 反对，表明 FaaS 拥抱容器生态的大趋势。并且函数计算在 2021 年 2 月上线了函数计算镜像减速（https://developer.aliyun.com/article/781992）性能。函数计算这两项性能解锁了更多的 FaaS 利用场景，容许用户无缝将本人的容器业务逻辑迁徙到函数计算平台上，并且能够做到 GB 级别的镜像在秒级启动。

当函数计算后盾遇到大规模申请导致过多的函数冷启动时，即便有镜像减速性能的加持，也会对 container registry 带宽带来微小压力，多台机器同时对同一个 container registry 进行镜像数据的拉取，导致容器镜像服务带宽瓶颈或限流，使得拉取下载镜像数据工夫变长（即便在镜像减速格局下）。较为间接的做法能够进步函数计算后盾 Registry 的带宽能力，然而这个办法不能解决基本问题，同时还会带来额定的零碎开销。

1）Workload 剖析

咱们首先对 FC 两大区域（北京和上海）的线上数据进行了剖析：

• 图（a）剖析了函数冷启动中，FC 零碎 pull image 的提早，能够看到在北京和上海别离有 ~80% 和 ~90% 的拉去镜像提早大于 10 秒；
• 图（b）展现 pull image 在整个冷启动中的占比，同样能够发现，北京区域内 80% 的函数，上海区域内 90% 的函数拉取镜像工夫会占据大于整个冷启动中 60% 的提早；

workload 的分析表明，函数的冷启动绝大多数工夫花在了容器镜像数据的获取之上，所以优化此局部提早能够大大提高函数的冷启动体现。

依据线上运维的历史记录，某大用户的代表在刹时会并发拉起 4000 个函数镜像，这些镜像的大小解压前为 1.8GB，解压后大小为 3-4GB，在大流量的申请达到开始拉起容器的霎时，就收到了容器服务的流控报警，造成了局部申请提早被缩短，重大的时候会收到了容器启动失败的提醒。这类问题场景都是亟需咱们来解决的。

2）State-of-the-art 比照

学术界和工业界有若干相干技术能够减速镜像的散发速度，例如：

阿里巴巴的 DADI：
https://www.usenix.org/conference/atc20/presentation/li-huiba
蜻蜓：
https://github.com/dragonfly/dragonfly
以及 Uber 开源的 Kraken：
https://github.com/uber/kraken/

• DADI

DADI 提供了一种十分高效的镜像减速格局，能够实现按需读取（FaaSNet 也利用到了容器减速格局）。在镜像散发技术上，DADI 采纳了树状拓扑构造，以镜像 layer 粒度进行节点间的组网，一个 layer 对应一个树状拓扑构造，每一个 VM 会存在于多颗逻辑树中。DADI 的 P2P 散发须要依赖若干性能规格（CPU、带宽）较大的 root 节点来负责数据回源角色、保护拓扑中 peer 的管理者角色；DADI 的树状构造偏动态，因为容器 provisioning 的速度个别不会继续很久，所以默认状况下，DADI 的 root 节点会在 20 分钟后将拓扑逻辑遣散，并不会始终保护上来。

• 蜻蜓

蜻蜓同样也是一个基于 P2P 的镜像、文件散发网络，其中的组件包块 Supernode（Master 节点），dfget（Peer 节点）。相似于 DADI，蜻蜓同样依赖于若干大规格的 Supernode 才能够撑起整个集群，蜻蜓同样通过地方 Supernode 节点来治理保护了一个全链接的拓扑构造（多个 dfget 节点别离奉献同一个文件的不同 pieces 已达到给指标节点点对点传输的目标），Supernode 性能会是整个集群吞吐性能的潜在瓶颈。

• Kraken

Kraken 的 origin、tracker 节点作为地方节点治理整个网络，agent 存在于每个 peer 节点上。Kraken 的 traker 节点只是治理组织集群中 peer 的连贯，Kraken 会让 peer 节点之间自行沟通数据传输。但 Kraken 同样是一个以 layer 为单位的容器镜像散发网络，组网逻辑也会成为较为简单的全连贯模式。
​
通过对上述三种业界当先的技术阐释，咱们能够看到几个共同点：

• 第一，三者均以 image layer 作为散发单位，组网逻辑过于细粒度，导致每个 peer 节点上可能会同时有多个 active 数据连贯；
• 第二，三者都依赖于地方节点进行组网逻辑的治理以及集群内的 peer 节点协调，DADI 和蜻蜓的地方节点还会负责数据回源，这样的设计要求在生产应用中，须要部署若干大规格的机器来承当十分高的流量，同时还须要进行调参来达到预期的性能指标。

咱们带着上述的一些前提条件来反观在 FC ECS 架构下的设计，FC ECS 架构中的每个机器的规格为 2 CPU 核、4GB 内存以及 1Gbps 内网带宽，并且这些机器的生命周期是不牢靠的，随时可能被回收。

这样带来了三个较为重大的问题：

• 内网带宽有余导致在全连贯中较为容易呈现带宽挤兑，导致数据传输性能降落。全连贯的拓扑构造没有做到 function-aware，在 FC 下极易引起系统安全问题，因为每台执行函数逻辑的机器是不被 FC 零碎组件信赖的，会留下租户 A 截取到租户 B 数据的安全隐患；
• CPU 和带宽规格受限。因为函数计算 Pay-per-use 的计费个性，咱们集群内的机器生命周期是不牢靠的，无奈在机器池中拿出若干机器作为地方节点治理整个集群。这部分机器的零碎开销会成为一大部分累赘，还有就是可靠性不能被保障，机器会导致 failure 的状况；FC 所须要的是继承按需付费个性，提供能够刹时组网的技术。
• 多函数问题。上述三者并没有 function-awareness 机制，例如 DADI P2P 中，可能存在单节点存有过多镜像成为热点，造成性能降落的问题。更重大的问题是多函数拉取实质上是不可预测的，当多函数并发拉取打满带宽，同期的从远端下载的服务也会受到影响，如代码包，第三方依赖下载，导致整个零碎呈现了可用性的问题。

带着这些问题，咱们在下一节中具体阐释 FaaSNet 设计方案。

2. 设计方案 – FaaSNet

根据上述三种业界成熟的 P2P 计划，没有做到 function 级别的感知，并且集群内的拓扑逻辑大多为全连贯的网络模式，并且对机器的性能提出了肯定需要，这些前置设定不适配 FC ECS 的零碎实现。所以咱们提出了 Function Tree (下称 FT)，一个函数级别并且是 function-aware 的逻辑树状拓扑构造。
​

1）FaaSNet 架构

图中灰色的局部是咱们 FaaSNet 进行了零碎革新的局部，其余红色模块均连续了 FC 现有的零碎架构。值得注意的是，FaaSNet 所有 Function Tree 均在 FC 的调度器上进行治理；在每一个 VM 上，有 VM agent 来配合 scheduler 进行 gRPC 通信承受上下游音讯；并且，VM agent 也负责上下游的镜像数据获取与散发。
​

2）去中心化的函数 / 镜像级别自均衡树状拓扑构造

为了解决上述三个问题，咱们首先将拓扑构造晋升到了函数 / 镜像级别，这样能够无效升高每一个 VM 上的网络连接数，另外，咱们设计了一种基于 AVL tree 的树状拓扑构造。接下来，咱们具体论述咱们的 Function Tree 设计。

Function Tree

• 去中心化自均衡二叉树拓扑构造

FT 的设计来源于 AVL tree 算法的启发，在 FT 中，目前不存在节点权重这个概念，所有节点等价（包含根节点），当树中增加或删除任意个节点时，整个树都会放弃一个 perfect-balanced 构造，既保证任意一个节点的左右子树的高度差的绝对值不超过 1。当有节点退出或删除后，FT 会本人调整树的形态（左 / 右旋）从而达到均衡构造，如下图右旋示例所示，节点 6 行将被回收，它的回收导致了以节点 1 作为父节点的左右子树高度不均衡，须要进行右旋操作已达到均衡状态，State2 代表旋转后的终态，节点 2 成为了新的树根节点。注：所有节点均代表 FC 中的 ECS 机器。
​

在 FT 中，所有节点全副等价，主要职责包含：1. 从上游节点拉取数据；2. 向上游两个孩子节点散发数据。（留神，在 FT 中，咱们不指定根节点，根节点与其余节点的惟一区别是他的上游为源站，根节点不负责任何的 metadata 治理，下一部分咱们会介绍咱们如何进行元信息的治理）。

• 多个 FT 在多个 peer 节点上的重叠

一个 peer 节点上势必会存在同一用户下的不同函数，所以肯定会呈现一个 peer 节点位于多个 FT 的状况。如上图所示，实例中有三个 FT 别离属于 func 0-2。然而因为 FT 的治理是相互独立的，所以即便有重叠下的传输，FT 也是能够帮忙每个节点找到对应的正确的上有节点。
​
另外咱们会将一个机器能够 hold 最大数量函数做限度已达到 function-awareness 的个性，进一步解决了多函数下拉取数据不可控的问题。
​

设计的正确性探讨

• 通过在 FC 上集成，咱们能够看到因为 FT 中的所有节点等价，咱们不须要依赖于任何的地方节点；
• 拓扑逻辑的管理者不存在于集群之中，而是由 FC 的零碎组件（scheduler）来保护这一内存状态，并通过 gRPC 随着创立容器的操作申请下发给每一个 peer 节点；
• FT 完满适配 FaaS workload 的高动态性，以及集群中任何规模的节点退出于来到，FT 会自动更新状态；
• 以函数这一较粗粒度进行组网，并且利用二叉树数据结构来实现 FT，能够大大降低每个 peer 节点上的网络连接数；
• 以函数为隔离进行组网，能够人造实现 function-aware 以进步的零碎的安全性和稳定性。

3. 性能评测

​
试验中咱们选取了阿里云数据库 DAS 利用场景的镜像，以 python 作为 base image，容器镜像解压前大小为 700MB+，领有 29 层 layers。咱们选取压力测试局部进行解读，全副测试后果请参考论文原文。测试零碎咱们比照了阿里巴巴的 DADI、蜻蜓技术和 Uber 开源的 Kraken 框架。
​

1）压力测试

​
压测局部记录的提早为用户感知的端到端冷启动均匀提早。首先咱们能够看出镜像减速性能相比于传统的 FC 能够显著晋升端到端提早，然而随着并发量的进步，更多的机器同时对地方的 container registry 拉取数据，造成了网络带宽的竞争导致端到端提早回升（橘色和紫色 bar）。然而在 FaaSNet 中，因为咱们去中心化的设计，对源站的压力无论并发压力多大，只会有一个 root 节点会从源站拉取数据，并向下散发，所以具备极高零碎伸缩性，均匀提早不会因为并发压力的进步而回升。

​

在压测局部的最初，咱们探索了同一个 VM 上如果搁置不同 image 的函数（多函数）会带来如何的性能体现，这里咱们比拟了开启镜像减速性能并且拆卸 DADI P2P 的 FC（DADI+P2P）和 FaaSNet。
​

上图纵轴示意标准化后的端到端提早程度，随着不同镜像的函数的数量增多，DADI P2P 因为 layer 变多，并且 FC 内每台 ECS 的规格较小，对每台 VM 的带宽压力过大，造成了性能降落，端到端提早已被拉长至 200% 多。然而 FaaSNet 因为在镜像级别建设连贯，连贯数目远远低于 DADI P2P 的 layer tree，所以依然能够放弃较好的性能。​

总结

​
高伸缩性和疾速的镜像散发速度能够为 FaaS 服务商更好的解锁自定义容器镜像场景。FaaSNet 利用轻量级的、去中心化、自均衡的 Function Tree 来防止地方节点带来的性能瓶颈，没有引入额定的系统化开销且齐全复用了现有 FC 的零碎组件与架构。FaaSNet 能够依据 workload 的动态性实现实时组网已达到 function-awareness，毋庸做事后的 workload 剖析与预处理。

FaaSNet 的指标场景不单单局限于 FaaS，在泛滥的云原生场景中，例如 Kubernetes，阿里巴巴 SAE 在应答突发流量的解决上都能够施展拳脚，来解决因为冷启动过多影响用户体验的痛点，从根本上解决了容器冷启动慢的问题。

FaaSNet 是国内首个云厂商在国内顶级会议发表 Serverless 场景下应答突发流量的减速容器启动技术的论文。咱们心愿这一工作能够为以容器为根底的 FaaS 平台提供新的机会，能够齐全关上拥抱容器生态的大门，解锁更多的利用场景，如机器学习、大数据分析等工作。

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。