产品战略专家梁宁确认出席AICon北京站,分享AI时代下的商业逻辑与产品需求 了解详情
写点什么

首个跨平台的 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:336584

评论

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

Android音视频--H,flutter小程序开发

android 程序员 移动开发

Android高工面试(难度:四星(1),2021Android高级面试题总结

android 程序员 移动开发

Android高阶:了解这些知识点,学习Binder就不成问题(1)

android 程序员 移动开发

深入剖析Redis客户端Jedis的特性和原理

vivo互联网技术

数据库 redis Jedis 集群

Android:手把手教你实现在XML中配置网易云歌手详情滑动效果

android 程序员 移动开发

APP瘦身大法--AndResGuard的使用,android地图开发框架

android 程序员 移动开发

BAT同系列公司面试总结,哪些你所不知道的,学习android的好书

android 程序员 移动开发

BAT常见Android面试20题详解,985研究生入职电网6个月

android 程序员 移动开发

Android:三四十岁的大龄程序员如何对后辈评价“太水技术低

android 程序员 移动开发

App 竟然是这样跑起来的 —— Android App_Activity 启动流程分析

android 程序员 移动开发

关于数据导入,教你几招

Simon

MySQL

Android题集四大组件之Content provider、BroadcastReceiver

android 程序员 移动开发

Android高级面试题大全(持续更新中),字节跳动厂内部超高质量Flutter+Kotlin笔记

android 程序员 移动开发

Android:怎么看待大厂面试门槛越来越高,,让你明明白白的使用RecyclerView

android 程序员 移动开发

Android:让你明明白白的使用RecyclerView—,retrofit优点

android 程序员 移动开发

App黑白化实现扩展,一键护眼模式,给App,安卓事件分发机制面试

android 程序员 移动开发

Base64 的原理、实现及应用,面试字节跳动Android工程师该怎么准备

android 程序员 移动开发

Android高工面试(难度:四星,2021大厂Android知识点总结

android 程序员 移动开发

Android:金九银十怎么从中小企业挤进一线大厂?大厂面试题问的深度

android 程序员 移动开发

Android:年过35岁的程序员还有出路吗?面试了一个-46-岁程序员后

android 程序员 移动开发

基线模型开源分享及深度讲解 | 2021 MAXP 直播第二讲:基于DGL的图机器学习任务

亚马逊云科技 (Amazon Web Services)

人工智能 图神经网络 创新大赛

APP瘦身大法--AndResGuard的使用(1),为什么阿里的程序员成长如此之快

android 程序员 移动开发

BAT资深面试官-带你破解Android高级面试,渣本逆袭大厂面经分享

android 程序员 移动开发

Android高阶:了解这些知识点,学习Binder就不成问题,androidapp开发教程推荐

android 程序员 移动开发

一个递归调用引发的 “血案”

神策技术社区

App基于手机壳颜色换肤?先尝试一下用 KMeans 来提取图像中的主色

android 程序员 移动开发

App怎么做才能永不崩溃,一文详解

android 程序员 移动开发

AsyncTask相关知识,安卓工程师面试题及答案

android 程序员 移动开发

这个深秋,StarRocks喊你一起来撸码 | StarRocks Hacker Meetup 报名开启

StarRocks

数据库 Meetup StarRocks

Android高级工程师BAT面试题及知识点整理大全(Java基础+Android

android 程序员 移动开发

(完整版)直播回顾:2021 MAXP 无服务器赛题讲解

亚马逊云科技 (Amazon Web Services)

人工智能 云计算 创新大赛

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