华为云Serverless再度创新：高效的资源优化调度系统入选ATC'24

1. USENIX ATC（USENIX Annual Technical Conference) 是计算机系统领域国际顶级学术会议之一（CCF-A），在国际上享有极高的学术声誉，2024年录用率仅为8%。来自华为云中间件团队、上海交通大学IPADS实验室的论文《Harmonizing Efficiency and Practicability: Optimizing Resource Utilization in Serverless Computing with JIAGU》[1]成功入选ATC 2024。
2. 如何提高资源利用率一直是 Serverless 领域乃至云平台面临的优化难题之一，本文将介绍华为云Serverless在高效、高密度调度优化方面的探索历程，并揭秘30%+ 利用率提升背后的原理。

Serverless作为一种新的架构范式，引领着云厂商基础设施的变革与云服务的演进，凭借着按量付费、自动弹性、免运维的特点吸引越来越多的企业与用户关注。主流云服务商不断地推出 Serverless 相关的云产品和新功能，其中华为云对Serverless在高效、高密度调度优化方面深入探索后，推出函数即服务(Function-As-A-Service)产品-FunctionGraph，作为华为云全域Serverless的核心产品，其覆盖边缘计算、车联网、AI应用等场景，此次揭秘华为云Serverless 30%+ 利用率提升的探索历程。

1、Serverless平台资源利用率的巨大挑战

提高资源利用率一直是 Serverless 领域乃至云平台面临的优化难题之一，华为云对平台运行的函数实例数据进行分析，发现不同的Serverless函数在CPU或内存利用率上有较大的提升空间。图1是实例内资源浪费的示意图。这表明，资源利用不足的问题主要由如下两个因素造成。

规格过配：为了保证性能与可靠性，用户通常会考虑最坏的情况，从而指定相对较大的函数规格。即使实例满负载也无法充分利用分配的资源。这就造成了图1中①部分的资源浪费。

空闲实例：在实际业务应用中，每个实例所服务的用户负载往往会存在波动性。当实例负载较低时会空闲出部分资源，而这些资源无法被其他实例使用，这会产生图1中②部分的资源浪费。

图1 资源利用率提升空间（源于论文）

为了提高Serverless集群利用率，现有方案主要针对以下两个方向进行优化：

一是通过超分（overcommit）减少实例资源的过量分配[2]，通过scheduler在节点上部署更多的函数实例，来减少①部分的浪费；

二是通过实例快速缩容（autoscaling）应对负载（RPS）的动态波动[3]，尽量使每个实例的负载接近饱和负载，减少实例空闲造成的②部分的资源浪费。

然而，如何在现有调度系统中有效的使用这两个措施存在巨大的挑战：

首先，超分很有可能导致性能下降从而违背QoS(Quality-of-Service)，常见的作法是通过预测性能以避免违背QoS，这将在调度路径上引入模型推理，而预测精度越高意味着计算复杂，从而调度开销越大，简单的计算却难以有效保证QoS，存在预测精度与调度开销之间的权衡；其次，当负载波动时，为了快速释放空闲实例资源，需要更敏感的自动扩容能力来灵活地调整实例个数，也意味着要更多额外的冷启动，那么如何在资源利用率和冷启动开销之间进行权衡成了难题。

2、基于JIAGU的高效调度：华为云对资源利用率的优化探索

2.1、系统架构

为了应对上述技术挑战，我们可以考虑以下两点：

预测与决策解耦。预测精度和调度成本之间的权衡来自于预测和决策的耦合，即往往在调度期间进行代价高昂的模型推断。我们可以将预测和决策解耦。具体来说，调度器可以在新实例到来之前对资源环境进行建模，并基于假设进行提前预测。当一个新的实例到来，并且调度时的资源环境符合我们之前的假设时，可以直接根据准备好的决策来进行调度。这提供了一个无需推理的调度快速路径。

资源释放和实例淘汰解耦。资源利用率和冷启动开销之间的权衡来自于资源释放和实例驱逐的耦合。相反，我们可以解耦资源释放和实例驱逐。具体来说，即使一个实例没有被驱逐，我们也可以调整路由，不向它发送请求，将负载较低的实例中的请求路由到其他实例中，达到与实际驱逐类似的资源释放效果。调整路由的开销远小于实际的冷启动开销。因此，通过这种方式，我们可以以更高的灵敏度释放/回收资源以应对负载波动，同时避免过多的额外冷启动开销。

基于此，我们设计了一个高效、高密度的QoS感知调度系统JIAGU（甲骨），如图2所示。首先，我们设计了一种预决策调度，可以在低调度延迟的情况下做出准确的预测。在创建实例时，会对其部署后的性能进行预测，在不违反QoS的前提下，尽量提高实例的部署密度，以充分利用资源。其次，采用了两阶段扩缩容设计，在负载波动情况下，以最小的开销高效利用资源。

图2 JIAGU 系统设计（来源于论文）

2.2、系统设计

QoS预测模型：QoS感知调度建立在能够精确预测各函数在特定资源条件下的性能的基础上。与现有工作以实例粒度做性能预测不同，JIAGU利用了同一函数多个实例之间的同构性，以函数为粒度做性能预测，并引入了并发度作为每个函数的新特征。如图3所示，这有效地降低了输入维数，从而减少了训练开销，并可能缓解“维数诅咒”。其中QoS考虑了性能目标，主要以尾延迟为指标，但可以扩展到其他指标。

图3 预测模型（来源于论文）

节点容量表：为将预测和决策解耦，对于每一个部署的函数，提前预测新实例的性能，基于QoS保证原则的计算它在该节点上的容量，最终计算出节点上每个函数的容量表。“容量”表示该函数能够在当前环境下部署的不违背QoS的最大并发实例数。之后，当调度器做出调度决策时，它可以通过表查询的方式，即检查函数实例部署后并发度是否超过该函数的容量，来预测QoS违规，而无需进行模型推断。这就是调度“Fast path”。此外，只有当传入实例所属的函数不在该节点的容量表中时，例如函数第一次部署到该节点上时，才需要对关键路径进行预测，此为“Slow path”。而实际负载的结果显示，超过80%的调度通过Fast path。

容量异步更新：由于部署新函数可能会对节点上其他函数施加资源干扰，从而导致它们的QoS违反。因此，引入了异步更新容量，当新函数被调度到节点时，它会触发更新容量表，更新在调度关键路径之外异步完成。即保证了容量表始终最新，又避免了容量更新引入额外的调度开销。

并发度感知调度：云上最极端的调用模式之一是负载峰值，当负载快速上升，需要同时创建多个函数实例。若如图4（a）所示的每个实例的创建都进行一次预测，将会带来巨大的调度开销。基于此，JIAGU 进一步采用并发感知调度，它在负载高峰时对同一个函数并发传入的实例进行调度。容量的计算方式，不仅考虑到是否可以部署下一个实例，还考虑了可以部署多少个下一个实例，如图4（b）所示，当同一函数的多个实例到达时，如果该函数在节点上的容量足以容纳这些新的实例，则多个实例的调度和异步更新可以被批处理，只需要进行一次。

图4  并发度感知调度（来源于论文）

两阶段扩缩容：当前通用的实例驱逐策略是当负载下降时，针对空闲实例等待一段时间后直接进行驱逐，如图5（a）所示，这种直接缩容的方式在负载波动的场景下往往会导致更频繁的冷启动。为了将资源释放与实例淘汰解耦，考虑如图5中（b）所示两阶段扩缩容：

一阶段：当负载下降时，在驱逐实例之前，会先以更高的敏感性调整路由，将请求发送到更少的实例，从而使部分实例处于空闲状态；

二阶段：当处于空闲状态一段时间后，再进行实例资源的释放。如果负载在空闲实例被释放之前再次上升，则可以通过重路由以最小的开销使实例重新工作。此外，为了应对某个节点的容量满了，而其上的处于空闲状态的情况，会提前将空闲实例迁移到其他节点上，以减少冷启动的开销。

图5 两阶段缩容设计（来源于论文）

2.3、效果验证

基于云上的真实负载数据我们验证分析了JIAGU的调度性能，如下图6（a）部分结果所示，相比于当前先进的基于模型的调度器Gsight[4]（发表于SC’21）相比，其调度成本降低了81.0%–93.7%，这是因为 JIAGU的基于节点容量的调度策略可以大幅减少模型推理的数量, 从而在多次冷启动中避免了推理开销。如图6（b）(c)所示在不同运行时的场景下，JIAGU的冷启动延迟相比Gsight分别降低了57.4%和20%。总的来说JIAGU在调度性能上普遍优于当前的基于模型的调度器。

图6 调度性能验证结果（来源于论文）

同时我们评估了JIAGU在资源利用率提升和QoS保障方面的效果，如图7所示，与现有流行的调度器Kubernetes、Gsight[4]、Owl[5]相比，在维持相当的QoS保障性的基础上，JIAGU实现了最高的资源利用率，实例密度比Kubernetes高54.8%，比Gsight高22.0%，比Owl高38.3%。可见当用户负载下降时，JIAGU可以快速利用不饱和实例的资源。

图7 资源利用率验证结果（来源于论文）

3、总结与展望

本文介绍了华为云对调度优化这一业界难题的探索之路，创新性提出了基于JIAGU的高效的资源优化调度系统，通过在现网的大规模验证，我们发现JIAGU在不同资源密集型业务混部的场景，保证QoS不影响的前提下实现了资源利用率30%+的提升，欢迎大家来体验。同时我们也在持续探索、优化调度能力，面向GPU等资源异构资源，结合函数画像实现精准调度。

此外在其它关键技术上，华为云FunctionGraph在过去一年内陆续构建了多项能力，旨在优化平台极致性能。在冷启动优化方面，探索了基于进程级快照的Java冷启动加速方案 [6]，节省了框架与业务初始化时间（占Java应用冷启动时间的90%），通过函数镜像预加载技术，大幅缩减了函数代码下载解压时间，实现了冷启动时延降低90%+；在弹性效率方面，面向水平弹性决策与启动时间长的问题，一方面通过流量预测进行实例预热，另一方面构建了实例垂直弹性能力，实现毫秒级响应；在函数间通信性能方面，通过多语言Runtime加速、统一消息结构免序列化、集成Kmesh加速节点内数据转发等技术，实现亚毫秒级低时延函数互调，为微服务Serverless化保驾护航；在边缘计算方面，自研了基于WASM轻量级安全沙箱的调度底座，在高并发下实现小于3ms的冷启动的极致弹性能力，且支持可编程CDN，云边一体。

FunctionGraph 作为华为元戎内核加持的下一代 Serverless 函数计算与编排服务，致力于持续为用户提供方便、迅捷的 Serverless 服务体验。您可以登录华为云 FunctionGraph 控制台来深入体验，更多信息请参阅 华为云FunctionGraph 官方文档 [7] 。后续我们将分享更多围绕通用全场景 Serverless 的前沿理论及其案例实践，回馈社区。

作者：思远

审稿：清源、旧浪

参考文献

[1] Qingyuan Liu, Yanning Yang, Dong Du, Yubin Xia, Ping Zhang, Jia Feng, James Larus, Haibo Chen. Harmonizing Efficiency and Practicability: Optimizing Resource Utilization in Serverless Computing with Jiagu. USENIX Annual Technical Conference, Santa Clara, CA, USA, July 2024.

[2] Suyi Li, Wei Wang, Jun Yang, Guangzhen Chen, and Daohe Lu. Golgi:Performance-aware, resource-efficient function scheduling for serverless computing. In Proceedings of the 2023 ACM Symposium on Cloud Computing, SoCC ’23, page 32–47, New York, NY, USA, 2023.Association for Computing Machinery

[3] Haoran Qiu, Weichao Mao, Chen Wang, Hubertus Franke, Alaa Youssef, Zbigniew T. Kalbarczyk, Tamer Ba¸sar, and Ravishankar K. Iyer. AWARE: Automate workload autoscaling with reinforcement learning in production cloud systems. In 2023 USENIX Annual Technical Conference (USENIX ATC 23), pages 387–402, Boston, MA, July 2023. USENIX Association.

[4] Laiping Zhao, Yanan Yang, Yiming Li, Xian Zhou, and Keqiu Li. Understanding, predicting and scheduling Serverless workloads under partial interference. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC’21, New York, NY, USA, 2021. Association for Computing Machinery.

 [5] Huangshi Tian, Suyi Li, Ao Wang, Wei Wang, Tianlong Wu, and Haoran Yang. Owl: Performance-aware scheduling for resource-efficient function-as-a-service cloud. In Proceedings of the 13th Symposium on Cloud Computing, SoCC ’22, pages 78–93, New York, NY, USA, 2022. Association for Computing Machinery

[6] https://www.infoq.cn/article/bdczHWk9LxuOC9GrVToL?utm_source=related_read&utm_medium=article

[7] https://support.huaweicloud.cn/functiongraph/index.html