写点什么

首个跨平台的 Serverless 基准测评系统:华为云联合上海交大联合发布 ServerlessBench 2.0

历川、平山、冯嘉

  • 2022-08-01
  • 本文字数:4192 字

    阅读完需:约 14 分钟

首个跨平台的 Serverless 基准测评系统:华为云联合上海交大联合发布ServerlessBench 2.0

Key Takeaways


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 应用程序。

Open Serverless Benchmark Initiative


为推动开放、开源、跨平台兼容的 Serverless 基准测评的规范化、标准化建设,华为云与上海交大联合提出业界首个 Open Serverless Benchmark Initiative (OSBI)。OSBI 包含两个规范和一个模型:自定义度量规范 (Metric Specification, MS),自定义基准规范 (Pillar Specification, PS), 和自定义模型 (Model), 如图 1 所示。



图 1: OSBI - Open Serverless Benchmark Initiative


其中,自定义度量规范为 Serverless 特性指标的设计提供了规范化接口和扩展标准;自定义基准规范为测评场景用例的设计提供了标准化模板;自定义模型旨在提供统一的、跨平台兼容的指标设计和用例部署标准,包括多平台的接入标准和基准用例的生命周期管理标准等。同时,OSBI 支持申明式测评配置,以及一键式跨平台的对比分析。

ServerlessBench 2.0 发布


聚焦 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 2.0 介绍


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 类跨平台测试基准


首批针对开源 Serverless 平台的测评结果


作为 ServerlessBench 2.0 的首批测评结果,我们此次选取四大 serverless 开源平台 OpenWhisk,OpenFaaS,Knative,Fission,作为测评对象,部分关键测评结果展示如下。

1.冷、热启动时延


测试从调用 invoke 指令到函数的第一条指令的时间差。图 4 所展示的结果为 p90 的时延开销。可以看到,OpenFaaS 在冷热启动性能上表现最差;得益于资源池预热技术,Fission 在冷启动性能上表现最佳。



图 4:四大 Serverless 开源平台“冷、热启动时延”测评结果对比

2. 冷、热执行时延


利用 Float Operation,测量函数本身的运行时延,考察冷、热启动对函数执行时间的影响,结果如图 5 所示。OpenWhisk 和 OpenFaaS 上函数执行时延基本不受冷热启动的影响。但相比于冷启动,Knative 和 Fission 在热启动的情况下,执行时延都有所改善。



图 5:四大 Serverless 开源平台“冷、热执行时延”测评结果对比

3. 请求并发数对 QoS 的影响


利用 Float Operation,计算不同并发数下函数实例的 p90 时延,该用例度量的是平台的函数密度支持能力。从图 6 可以看到,除 Fission 外,其它三大平台上,随并发请求数的增长,函数实例的 p90 时延基本呈线性增长。同“冷、热启动时延”的结果相似,由于 Fission 预置了一部分通用资源池,在并发请求数增长的初期,函数 p90 时延没有明显增长;但随着并发数的继续增长,资源池被逐步消耗,直至需要进行补充时,时延出现显著增长。



图 6:四大 Serverless 开源平台“请求并发数对 QoS 的影响”测评结果对比


这里需要指出,在各大云服务提供的 Serverless 或函数系统中,请求并发数对函数执行时延或业务 QoS 的影响是一个更加复杂的过程,还包括其它多个影响因素,如单实例并发数,最大并发实例数限制,平台扩容策略,实例调度策略等。

4. 弹性扩容能力


利用 Float Operation,测试并观察实例数量从 1 伸缩到某个较大值的过程中,多实例启动尾时延的大小。图 7 展示 OpenFaaS 和 Knative 从 1 个实例弹性扩容到 10 个实例的结果。



图 7:OpenFaaS 和 Knative “弹性扩容能力”测评结果对比

5.平台性价比


利用 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 的繁荣发展。


作者介绍:


历川,华为云 Serverless 研发专家


平山,华为云中间件 Serverless 负责人


冯嘉,华为云中间件首席专家


参考链接:


[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

2022-08-01 14:336871

评论

发布
暂无评论
发现更多内容

烘焙工业4.0:自动化升级与制造执行MES系统的深度赋能

万界星空科技

mes 万界星空科技mes 食品MES 食品加工行业 烘焙行业

StarRocks 3.5 新特性解读:Snapshot 快照恢复、大导入性能全面升级、分区管理更智能

StarRocks

存算分离 iceberg 物化视图 Snapshot 快照 StarRocks 3.5

德比软件基于生成式 AI 的智能酒店数据匹配系统

亚马逊云科技 (Amazon Web Services)

《HarmonyOSNext全流程订阅开发指南:从配置到挽留的终极方案》

Turing_010

HarmonyOS NEXT仓颉开发语言实战案例:电影App

幽蓝计划

harmoyos

生产物料管理混乱怎么办?一文教你搞清BOM 清单和 MRP 需求!

积木链小链

数字化转型 智能制造 生产管理

HarmonyOS NEXT仓颉开发语言实战案例:外卖App

幽蓝计划

HarmonyOS

Windows Terminal - 现代化、功能丰富的终端应用

qife122

windows 终端

“过度采集”还是“必要防护”? 隐私与安全的终极博弈

权说安全

零信任

DApp 开发中的安全测试

北京木奇移动技术有限公司

dapp开发 区块链开发 软件外包公司

AI 技术在线上英语学习中的应用

北京木奇移动技术有限公司

软件外包公司 AI英语学习 AI技术应用

Airtable 太贵了?5 个自托管替代方案成本&功能对比

NocoBase

开源 低代码 零代码 Airtable 自托管

MyEMS开源能源管理系统核心代码解读007

开源能源管理系统

开源 能源管理 代码解读

淘宝API系列:淘宝商品详情接口详解

tbapi

淘宝商品详情接口 淘宝API 天猫商品详情接口

大数据-26 ZooKeeper 分布式协调框架 简介与配置 Leader Follower Observer

武子康

Java 大数据 hadoop zookeeper 分布式

Coremail受邀亮相华为开发者大会

科技热闻

MyEMS开源能源管理系统核心代码解读009

开源能源管理系统

开源 能源管理

企业 IM 即时通讯底座,支持局域网通讯

BeeWorks

即时通讯 私有化部署

2025华为HMS for Car全球生态峰会:同心聚力共筑生态联盟

极客天地

团队创收遇瓶颈,Alpha系统解锁律所管理高效模式

科技汇

Unity Catalog 三大升级:Data+AI 时代的统一治理再进化

StarRocks

AI LakeHouse StarRocks Apache Iceberg

数据要素如何赋能企业创新

郑州埃文科技

数据要素

MyEMS开源能源管理系统核心代码解读008

开源能源管理系统

开源 能源管理

《HarmonyOSNext自动续期订阅支付全攻略 | 从环境检测到防漏单指南》

Turing_010

私有化 IM 即时通讯,BeeWorks 支持国产化

BeeWorks

即时通讯 私有化部署

AI 开发英语学习 App 的技术

北京木奇移动技术有限公司

软件外包公司 AI英语学习 AI技术应用

LLM 学习资料

Joseph295

今夏增长卷上天?看百度商家智能体玩转服务预约!

新消费日报

DApp 开发的技术方案

北京木奇移动技术有限公司

dapp开发 区块链开发 软件外包公司

这些面试问题,最好提前准备

王中阳Go

面试技巧

什么是数据聚合(Data Aggregation)?

镜舟科技

数据库 列式存储 StarRocks 物化视图 数据聚合

首个跨平台的 Serverless 基准测评系统:华为云联合上海交大联合发布ServerlessBench 2.0_语言 & 开发_InfoQ精选文章