简介：USENIXATC（USENIXAnnualTechnicalConference）学术会议是计算机系统领域的顶级会议，入选中国计算机学会（CCF）推荐的A类国际会议名单；本次会议共提交论文341篇，接收论文64篇。录取率为18.8%。阿里云Serverless团队率先提出FaaS场景下的去中心化镜像快速分发技术。该团队的论文被USENIXATC'21接收。作者|王敖来源|Serverless公众号简介USENIXATC（USENIXAnnualTechnicalConference）学术会议是计算机系统领域的顶级会议，入选中国计算机学会（CCF）推荐的A类国际会议名单；本次会议共提交论文341篇，录用64篇，录用率为18.8%。阿里云Serverless团队率先提出FaaS场景下的去中心化镜像快速分发技术。该团队的论文被USENIXATC'21接收。以下是对论文核心内容的解读，着重于缩短阿里云函数计算产品CustomContainerRuntime的函数冷启动的端到端延迟。USENIXATC将于7月14日至7月16日在线举行。论文信息参见：https://www.usenix.org/conference/atc21/presentation/wang-ao摘要无服务器计算（FaaS）是一种新的云计算范式。让客户只关注自己的代码业务逻辑，系统底层的虚拟化、资源管理、弹性伸缩等，全部交给云系统服务商维护。ServerlessComputing支持容器生态，解锁多种业务场景。然而，由于容器镜像的复杂性和体积庞大，以及FaaS工作负载的高动态性和不可预测性，许多行业领先的产品和技术无法得到很好的应用。在FaaS平台上，高效的容器分发技术在FaaS平台上面临挑战。在本文中，我们设计并提出了FaaSNet。FaaSNet是一个具有高扩展性的轻量级系统中间件。它使用图像加速格式进行容器分发。目标应用场景为FaaS中突发流量下的大规模容器镜像启动（函数冷启动）。FaaSNet的核心组件包括函数树（FunctionTree，FT），它是一种去中心化的、自平衡的二叉树拓扑结构，树形拓扑结构中的所有节点都是等价的。我们将FaaSNet集成到函数计算产品中。实验结果表明，在高并发请求下，FaaSNet可以为FC提供比原生函数计算（以下简称FC）快13.4倍的容器启动速度。而对于突发请求导致的端到端延迟的不稳定时间，FaaSNet比FC减少了75.2%的时间将端到端延迟恢复到正常水平。论文介绍一、背景与挑战FC于2020年9月支持自定义容器镜像（https://developer.aliyun.com/article/772788）功能，AWSLambda于同年12月宣布支持Lambda容器镜像。说明FaaS拥抱容器生态的大趋势。此外，函数计算于2021年2月推出了函数计算镜像加速（https://developer.aliyun.com/article/781992）功能。函数计算的这两个功能解锁了更多FaaS应用场景，让用户可以无缝迁移自己的容器业务逻辑到函数计算平台，实现GB级镜像秒级启动。当函数计算后台遇到大规模请求导致函数冷启动过多时，即使有镜像加速功能的支持，也会对容器注册中心的带宽带来巨大压力，多台机器会镜像数据同一个容器注册中心同时拉取会导致容器镜像服务出现带宽瓶颈或节流，导致拉取和下载镜像数据（即使是镜像加速格式）的时间更长。更直接的方法可以提高函数计算后台Registry的带宽能力，但这种方法不能解决根本问题，还会带来额外的系统开销。1）工作负载分析我们首先分析了FC两大区域（北京和上海）的在线数据：图（a）分析了FC系统在函数冷启动时拉取镜像的延迟。可以看出，在北京和上海分别有~80%和~90%的pullimage延迟大于10秒；图（b）展示了pullimage在整个冷启动中所占的比例。还可以发现，北京地区80%的功能和上海地区90%的功能拉取镜像的时间会占据整个冷启动延迟的60%以上；对工作负载的分析表明，函数冷启动的大部分时间花在了获取容器镜像数据上，因此优化这部分延迟可以大大改善函数的冷启动行为。根据线上运维的历史记录，一个大用户代表会瞬间并发拉起4000个功能镜像。这些镜像解压前大小为1.8GB，解压后大小为3-4GB。在容器拉起的一瞬间，收到容器服务的流控告警，导致部分请求延时延长，严重时会收到容器启动失败的提示。这类问题场景急需我们去解决。2）学术界和工业界的state-of-the-art比较有几个相关技术可以加速图像的分发，例如：阿里巴巴的DADI：https://www.usenix.org/conference/atc20/presentation/li-huibaDragonfly：https://github.com/dragonfly/dragonfly和Uber开源的Kraken：https://github.com/uber/kraken/DADIDADI提供了非常高效的图片加速格式，可以实现点播阅读（FaaSNet还利用容器加速格式）。在图像分发技术方面，DADI采用树状拓扑结构，以图像层的粒度在节点之间进行组网。一层对应一个树状拓扑，每个VM会存在于多棵逻辑树中。DADI的P2P分发需要依赖多个性能规格（CPU、带宽）较大的根节点来起到数据回源和维护拓扑中peermanager的作用；DADI的树形结构是比较静态的，因为容器的provisioning速度一般不会很快。它会持续很长时间，所以DADI根节点默认会在20分钟后解散拓扑逻辑，永远不会维护。DragonflyDragonfly也是一个基于P2P的镜像和文件分发网络，其组成部分包括Supernode（Master节点）和dfget（Peernode）。与DADI类似，Dragonfly也依赖于几个大型超级节点来支撑整个集群。Dragonfly还通过中心Supernode节点管理和维护一个全链路拓扑（多个dfget节点分别贡献同一个文件的不同片段。以达到点对点传输到目标节点的目的），Supernode性能将是一个整个集群吞吐性能的潜在瓶颈。Kraken的origin和tracker节点作为中心节点管理整个网络，代理存在于每个对等节点上。Kraken的traker节点只管理组织集群中peer的连接，Kraken将允许peer节点相互通信进行数据传输。但Kraken也是一个分层的容器镜像分发网络，组网逻辑会变成更复杂的全连接模式。通过以上三项业界领先技术的讲解，我们可以看到几个共同点：第一，全连接三是使用镜像层作为分发单元，组网逻辑过于细粒度，导致每个peer节点可能同时存在多个活跃的数据连接；其次，这三者都依赖中央节点来管理网络逻辑并协调集群中的对等节点。DADI和Dragonfly的中心节点也负责向源头返回数据。这种设计需要在使用中，需要部署几台大型机器来承受非常大的流量，需要调整参数以达到预期的性能指标。具备以上前提条件，我们再回顾一下FCECS架构下的设计。FCECS架构中每台机器有2个CPU核，4GB内存，1Gbps内网带宽，这些机器的生命周期是不可靠的。,可随时回收。这就带来了三个比较严重的问题：内网带宽不足，更容易有带宽跑满连接，导致数据传输性能下降。全连接的拓扑是非功能感知的，很容易造成FC下的系统安全问题，因为每台执行功能逻辑的机器都不受FC系统组件的信任，留下租户A拦截租户B的数据安全隐患；有限的CPU和带宽规格。由于函数计算的按需计费特性，我们集群中的机器生命周期是不可靠的，不可能拿出机器池中的几台机器作为中心节点来管理整个集群。这部分机器的系统开销会成为很大的负担，可靠性得不到保证，导致机器出现故障；FC需要的是继承按量付费的特性，提供即时联网技术。多功能问题。以上三者都没有功能感知机制。比如在DADIP2P中，可能会出现单个节点上存储过多的图片成为热点，导致性能下降的问题。更严重的问题是，多功能抓取本质上是不可预测的。当多功能并发抓取占满带宽时，同时从远端下载的服务也会受到影响，比如代码包、第三方依赖下载，导致整个系统存在可用性问题.带着这些问题，我们将在下一节详细阐述FaaSNet的设计。2、设计方案——从以上三种业界成熟的P2P方案来看，FaaSNet并没有实现功能级的感知，集群中的拓扑逻辑大部分是全连接网络模型，对机器的性能。配置设置不适合FCECS的系统实现。因此我们提出FunctionTree（以下简称FT），??一种功能级的、功能感知的逻辑树形拓扑结构。1）FaaSNet架构图中灰色部分是我们FaaSNet系统改造的部分，其他白色模块延续了FC现有的系统架构。值得注意的是，FaaSNet的所有FunctionTrees都在FC调度器上进行管理；在每个VM上，都有一个VMagent配合调度器进行gRPC通信，接收上下游消息；而VMAgent还负责上下游镜像数据的获取和分发。2)去中心化函数/镜像级自平衡树形拓扑为了解决以上三个问题，我们首先将拓扑提升到函数/镜像级，可以有效减少每个VM上的网络连接数。此外，我们还设计了一种基于AVL树的树形拓扑结构。接下来，我们详细说明我们的功能树设计。FunctionTree的去中心化自平衡二叉树拓扑结构FT的设计灵感来自AVL树算法。在FT中，目前还没有节点权重的概念。所有节点都是等价的（包括根节点）。当添加或删除任意两个节点时，整棵树会保持一个完美平衡的结构，保证任意节点的左右子树高度差的绝对值不超过1。当一个节点是添加或删除，FT将调整树的形状（左/右旋转）以实现平衡结构。如下图右旋示例，节点6即将被回收，其回收导致节点1作为父节点的左右子树高度不平衡，右旋操作为需要达到平衡状态。State2代表旋转后的最终状态，节点2成为树的新根节点。注：FC中所有节点代表ECS机器。在FT中，所有节点是等价的，主要职责包括：1.从上游节点拉取数据；2.将数据分发给下游的两个子节点。（注意，在FT中，我们没有指定根节点，根节点和其他节点的唯一区别是它的上游是源站，根节点不负责任何元数据管理。在下一部分，我们将介绍我们如何管理元信息）。多个对端节点上的多个FT重叠，必然会在一个对端节点上的同一个用户下产生不同的功能，所以必然存在一个对端节点位于多个FT中的情况。如上图所示，示例中有3个FT属于func0-2。但是，由于FT的管理是相互独立的，即使有重叠传输，FT也可以帮助每个节点找到对应的正确上层节点。另外，我们会限制一台机器最多能持有的函数数为实现了函数感知的特性，进一步解决了多函数下取数据不可控的问题。设计正确性讨论通过在FC上进行集成，我们可以看到，由于FT中的所有节点都是等价的，我们不需要依赖任何一个中心节点；集群中不存在拓扑逻辑的管理器，而是由FC的系统组件（调度器）维护这个内存状态，并通过gRPC连同创建容器的操作请求发送给各个peer节点；FT完美适配集群中FaaS工作负载和任意规模节点的高动态性，加入和离开时，FT会自动更新表单；功能粒度较粗的组网，采用二叉树数据结构实现FT，可以大大减少每个peer节点的网络连接数；以功能隔离组网，自然实现功能感知，提高系统的安全性和稳定性。3.性能评价实验中我们选择了阿里云数据库DAS应用场景的镜像，使用python作为基础镜像，解压前容器镜像大小为700MB+，共有29层。我们选择压力测试部分进行解读。所有测试结果请参考论文原文。对于测试系统，我们对比了阿里巴巴的DADI、蜻蜓科技和Uber开源的Kraken框架。1）压测压测部分记录的时延是用户感知到的平均端到端冷启动时延。首先我们可以看到，镜像加速功能相比传统FC可以显着改善端到端延迟，但是随着并发量的增加，更多的机器同时从中央容器注册中心拉取数据，导致争夺网络带宽导致端到端延迟增加（橙色和紫色条）。但是在FaaSNet中，由于我们去中心化的设计，无论给源站施加多大的压力，只有一个根节点会从源站拉取数据，向下分发，因此具有极高的系统可扩展性。平均延迟不会因并发压力增加而增加。在压测部分的最后，我们探索了将不同镜像的函数（multi-function）放在同一个VM上的性能。这里我们对比了FC（DADI+P2P）和FaaSNet。上图的纵轴代表标准化的端到端延迟水平。随着不同镜像功能的增多，DADIP2P层数越来越多，FC中每个ECS的规格越来越小，对每个VM的带宽造成了压力。太大，导致性能下降，端到端延迟已经拉长到200%以上。但由于FaaSNet在镜像层面建立连接，连接数远低于DADIP2P层树，因此仍能保持良好的性能。总结高扩展性和快速的镜像分发速度可以更好地为FaaS服务商解锁自定义容器镜像场景。FaaSNet采用轻量级、去中心化、自平衡的FunctionTree来避免中心节点带来的性能瓶颈。它不会引入额外的系统开销，并充分重用现有的FC系统组件和架构。FaaSNet可以根据工作负载的动态实时联网，实现功能感知，无需预先进行工作负载分析和预处理。FaaSNet的目标场景并不局限于FaaS。在很多云原生的场景下，比如Kubernetes，阿里SAE可以尽力应对突发流量，解决冷启动过多影响用户体验的痛点。从根本上解决了容器冷启动慢的问题。FaaSNet是国内第一家在国际顶级会议上发表Serverless场景突发流量容器加速启动技术论文的云厂商。我们希望这项工作能够为基于容器的FaaS平台提供新的机会，全面打开拥抱容器生态的大门，解锁更多的应用场景，比如机器学习、大数据分析等任务。版权声明：本文内容由阿里云实名注册用户投稿，版权归原作者所有。阿里云开发者社区不拥有自己的版权，也不承担相应的法律责任。具体规则请参考《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如发现本社区涉嫌抄袭内容，请填写侵权投诉表进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
