ServerlessBench 2.0发布：华为云联合上海交大，推动 Serverless 基准测评规范化、标准化
1. 华为云联合上海交大，首次提出 Open Serverless Benchmark Initiative (OSBI) , 推动 Serverless 基准测评规范化、标准化；
2.OSBI 由自定义度量规范 (Metric Specification, MS)，自定义基准规范 (Pillar Specification, PS), 和自定义模型（Model）组成；
3.OSBI 发布首个跨平台的 Serverless 基准测评系统 ServerlessBench 2.0, 聚焦 FaaS 关键特性，提供丰富的测评基准和指标，并发布了针对四大开源 Serverless 平台的首批测评报告；
4.OSBI ServerlessBench 2.0 是“服务器无感知创新计划”的首个亮相项目, 该创新计划旨在联合产学研用各方，推动通用全场景 Serverless 技术的发展和规范化建设。
受益于其按用付费 (pay-per-use)、自动弹性伸缩 (auto-scaling)、以及屏蔽后端复杂性的特征，Serverless 正成为下一代云计算的新范式[1]。与此同时，能够封装并兼容多平台、支持关键指标度量的基准测试系统，对于 Serverless 计算实现可持续的降本增效而言，至关重要。一方面，Serverless 系统设计者可以利用基准测试平台，刻画系统的关键性能指标，如冷 / 热启动时延、弹性扩容速度、QoS 保证下的最大并发等，为增强系统架构的性能提供 “度量先行”的有效工具；另一方面，Serverless 应用开发者可以借助基准测试对不同的 Serverless 平台进行对比和选择，从而设计并开发出更加高性能、低成本的 Serverless 应用程序。
为推动开放、开源、跨平台兼容的 Serverless 基准测评的规范化、标准化建设，华为云与上海交大联合提出业界首个 Open Serverless Benchmark Initiative (OSBI)。OSBI 包含两个规范和一个模型：自定义度量规范 (Metric Specification, MS)，自定义基准规范 (Pillar Specification, PS), 和自定义模型 (Model), 如图 1 所示。
图 1: OSBI - Open Serverless Benchmark Initiative
其中，自定义度量规范为 Serverless 特性指标的设计提供了规范化接口和扩展标准；自定义基准规范为测评场景用例的设计提供了标准化模板；自定义模型旨在提供统一的、跨平台兼容的指标设计和用例部署标准，包括多平台的接入标准和基准用例的生命周期管理标准等。同时，OSBI 支持申明式测评配置，以及一键式跨平台的对比分析。
聚焦 FaaS 场景，OSBI 发布业界首个多平台兼容的 Serverless 基准测评系统 ServerlessBench 2.0。ServerlessBench 1.0 是针对 Serverless 计算的关键特性和指标而设计的基准测试平台，由上海交通大学研究团队发表于云计算顶级会议 SoCC 2020[2]。此次，华为云联合上海交大，在 ServerlessBench 1.0 的基础上，通过进一步的封装、抽象、扩展和强化，重磅推出 OSBI ServerlessBench 2.0，为社区提供涵盖 12 类基础性度量基准、5 大类跨平台度量基准、4 大类关键特性指标、且多平台兼容的 Serverless 开放测评系统。
同时，OSBI ServerlessBench 2.0 是“服务器无感知创新计划”的首个亮相项目成果。服务器无感知创新计划由中国信通院、上海交大、华为云联合推动落地，旨在链接产学研用各方，凝聚社区力量，围绕技术研究和标准制定等，促进通用全场景 Serverless 的蓬勃发展和规范化建设[3]。
ServerlessBench 考虑 Serverless 计算中的四大类关键指标：通信性能（communication performance），启动时延（startup latency），无状态开销 (stateless overhead)，和资源使用效率 (resource utilization)。复杂的 Serverless 应用一般由多个函数组合实现，因此，通信性能指标主要度量函数间通信的效率问题，如常见的函数组合模型 sequence chain 和 nested chain 等。Serverless 函数通常运行时间较短，大多集中在百毫秒级至秒级的范围[4]，且函数执行环境按需加载，自动扩容，因此冷启动、热启动等时延开销是 Serverless 系统和应用最为关注的性能指标之一。在无状态开销指标中，通常包括依赖外部存储服务进行传递的显式状态（如函数逻辑本身所涉及的状态），以及可能影响系统性能的隐式状态（如会话缓存等）。资源使用效率指标主要衡量性价比问题，对于平台，如何在函数混合部署且保证业务 QoS 的前提下提升资源利用率，对用户而言，如何配置合理的资源规格来使得应用性能和成本之间取得最佳平衡。
围绕四大类关键指标，ServerlessBench 提供包括资源需求（Bench Pillar 1-varied resource needs），数据迁移开销（Bench Pillar 5-Data transfer costs）, 和 CPU 争用（Bench Pillar 12-CPU contention）等在内的 12 类基准，如表 1 所示。
表 1：ServerlessBench 1.0 提供的 12 类基准
为良好地兼容多平台, 依据 OSBI-Model, ServerlessBench 2.0 提供了统一的测评接口，对不同 Serverless 平台之间的异构性进行封装，包括统一的函数接口、统一的返回格式，统一的资源配置，以及统一的依赖包装等，如图 2 所示。这里以开源 Serverless 系统为例。
图 2：ServerlessBench 2.0 的多平台兼容性（以开源 Serverless 系统为例）
具体以函数调用入口为例，如图 3 所示，四大开源 Serverless 平台 OpenWhisk，OpenFaaS, Knative，Fission 的入口函数都不相同。针对该场景，ServerlessBench 2.0 通过接口抽象，封装了统一的入口函数 def handler(event, context)（这里以 Python 为例），从而使得在跨平台的对比中，无须再关心平台之间的接口差异性。
图 3：ServerlessBench 2.0 为多平台提供统一的函数调用入口（以 Python 为例）
在多平台兼容的基础上，遵循 OSBI-MS 和 OSBI-PS 规范，ServerlessBench 2.0 对表 1 所列的测试基准进行了扩展，新增了冷热启动开销、冷热执行开销、保证 QoS 的最大并发、弹性扩容速度、性价比等 5 大类跨平台基准，如表 2 所示；同时，更多跨平台基准还在持续更新中，如带有函数链的 Serverless 应用等。
表 2：ServerlessBench 2.0 新增 5 类跨平台测试基准
作为 ServerlessBench 2.0 的首批测评结果，我们此次选取四大 serverless 开源平台 OpenWhisk，OpenFaaS，Knative，Fission，作为测评对象，部分关键测评结果展示如下。
测试从调用 invoke 指令到函数的第一条指令的时间差。图 4 所展示的结果为 p90 的时延开销。可以看到，OpenFaaS 在冷热启动性能上表现最差；得益于资源池预热技术，Fission 在冷启动性能上表现最佳。
图 4：四大 Serverless 开源平台“冷、热启动时延”测评结果对比
利用 Float Operation，测量函数本身的运行时延，考察冷、热启动对函数执行时间的影响，结果如图 5 所示。OpenWhisk 和 OpenFaaS 上函数执行时延基本不受冷热启动的影响。但相比于冷启动，Knative 和 Fission 在热启动的情况下，执行时延都有所改善。
图 5：四大 Serverless 开源平台“冷、热执行时延”测评结果对比
利用 Float Operation，计算不同并发数下函数实例的 p90 时延，该用例度量的是平台的函数密度支持能力。从图 6 可以看到，除 Fission 外，其它三大平台上，随并发请求数的增长，函数实例的 p90 时延基本呈线性增长。同“冷、热启动时延”的结果相似，由于 Fission 预置了一部分通用资源池，在并发请求数增长的初期，函数 p90 时延没有明显增长；但随着并发数的继续增长，资源池被逐步消耗，直至需要进行补充时，时延出现显著增长。
图 6：四大 Serverless 开源平台“请求并发数对 QoS 的影响”测评结果对比
这里需要指出，在各大云服务提供的 Serverless 或函数系统中，请求并发数对函数执行时延或业务 QoS 的影响是一个更加复杂的过程，还包括其它多个影响因素，如单实例并发数，最大并发实例数限制，平台扩容策略，实例调度策略等。
利用 Float Operation，测试并观察实例数量从 1 伸缩到某个较大值的过程中，多实例启动尾时延的大小。图 7 展示 OpenFaaS 和 Knative 从 1 个实例弹性扩容到 10 个实例的结果。
图 7：OpenFaaS 和 Knative “弹性扩容能力”测评结果对比
利用 Numpy Matmul，逐步调整给函数所分配的资源数量，测量并观察资源数量对函数的执行时延（图 8）与函数实例成本（图 9）的影响。该用例反映的是相同资源开销下，函数在不同 Serverless 平台上的性能表现。图 8 和图 9 展示了在 OpenFaaS 和 Knative 上的部分结果。
图 8：OpenFaaS 和 Knative“平台性价比：资源与执行时长”测评结果
图 9：OpenFaaS 和 Knative“平台性价比：资源与实例成本”测评结果
OSBI 及其 ServerlessBench 2.0 建立在开源开放的理念之上，将由社区共同运营并持续共建。华为云将继续联合上海交大，推出包括华为云 FunctionGraph 在内的各大公有云服务 Serverless 平台的测评报告，并贡献给社区。另外，我们正在为 OSBI 和 ServerlessBench 2.0 建立项目主页，并推动源码开源等工作。关于 ServerlessBench 1.0 的详细信息，可参见项目主页[5]和 github 主页 [6]。
此次 OSBI 和 ServerlessBench 2.0 的发布，旨在联合社区共建 Serverless 基准测评的规范与标准。华为云结合自身丰厚的技术积累与多年的发展经验，积极参与、主导相关技术及其服务的规范建设和标准制定, 如 FunctionGraph 与 CNCF Serverless Workflow 携手开拓 Serverless 编排新时代[7]。同时，我们期待与更多的 Serverless 爱好者及从业人员共同推动 OSBI 和 ServerlessBench 2.0 的繁荣发展。
参考链接：
[1].Schleier-Smith, et al. (2021). What serverless computing is and should become: The next phase of cloud computing. Communications of the ACM, 64(5), 76-84.
[2].Yu, T., et al. (2020). Characterizing serverless platforms with ServerlessBench. In Proceedings of the 11th ACM Symposium on Cloud Computing (pp. 30-44).
[3].https://mp.weixin.qq.com/s/vuhqCweenT7sozNzInavyQ
[4].Shahrad, M., et al. (2020). Serverless in the wild: Characterizing and optimizing the serverless workload at a large cloud provider. In 2020 USENIX Annual Technical Conference (USENIX ATC 20) (pp. 205-218).
[5].https://serverlessbench.systems/
[6].https://github.com/SJTU-IPADS/ServerlessBench
[7].https://bbs.huaweicloud.com/blogs/336135
字节将大幅压缩招聘规模；滴滴被罚 80 亿，违法行为持续 7 年；各国软件开发者薪资统计：中国上榜全球开发者薪酬最低国家名单 | Q 资讯
点个在看少个 bug 👇
相关内容
微信扫码咨询专知VIP会员