写点什么

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

评论

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

Zebec Chain缘何能成为新晋应用链,熊市下又为何值得我们关注?

股市老人

WEB23

Lenyi

网络安全 CTF ctfshow 爆破

Flink 在米哈游的应用实践

Apache Flink

大数据 flink 实时计算

FFA 2022 主会场 Keynote:Flink Towards Streaming Data Warehouse

Apache Flink

大数据 flink 实时计算

OpenTelemetry系列 (四)| 如何使用Java Agent来实现无侵入的调用链

骑牛上青山

Java javaagent 调用链 OpenTelemetry 微服务调用链

学生管理系统

KING

架构实战营 3-4 架构设计后期随堂练习

西山薄凉

「架构实战营」

Web入门开发【二】

小院里的霍大侠

编程开发 初学者 入门实战 Web入门

模块三-外包学生管理系统的架构文档

悟空

学生管理系统架构

基于Go的缓存实现

俞凡

架构

架构误区系列10:不合理的分层

agnostic

软件分层

SRE运维解密-应对过载

董哥的黑板报

微服务 SRE 限流 SRE实践

2022年浪过的那些城市

SAP虾客

杭州 2022年 无锡 东莞 SAP项目

【Java基础】Win10如何配置jdk环境变量(配置java环境变量)

No8g攻城狮

Java、 java 并发 Java IO

Java中Map集合的三种遍历方式

@下一站

Java 程序设计 map 12月日更 12月月更

2022-12-24:给定一个字符串s,其中都是英文小写字母, 如果s中的子串含有的每种字符都是偶数个, 那么这样的子串就是达标子串,子串要求是连续串。 返回s中达标子串的最大长度。 1 <= s的长

福大大架构师每日一题

Linux 算法 Shell 福大大

HTTP通用首部字段

穿过生命散发芬芳

HTTP 12月月更

设计模式之美——对扩展开放、对修改关闭

GalaxyCreater

设计模式

WEB21

Lenyi

网络安全 CTF ctfshow 爆破

SAP MM SPED输出报错-No authorization for delivery from shipping point US##-之对策

SAP虾客

SAP MM SPED VL31N 公司间STO

架构实战营 3-5 消息队列备选架构随堂练习

西山薄凉

「架构实战营」

YOLOv5全面解析教程②:如何制作训练效果更好的数据集

OneFlow

人工智能 深度学习 数据集

MMEval正式支持OneFlow评测

OneFlow

机器学习 深度学习 算法

【web 开发基础】PHP 中的预定义数组详解之一 (47)

迷彩

数组 全局变量 PHP基础 预定义数组

为什么更推荐使用组合而非继承关系?

JAVA旭阳

Java 架构

Android Studio开发Android APP

芯动大师

Android Studio 开发环境 新建工程

Flink 1.16:Hive SQL 如何平迁到 Flink SQL

Apache Flink

大数据 flink 实时计算

Web入门:CSS下拉图片

小院里的霍大侠

JavaScript Web 初学者 入门者

极客时间运维训练营第九周作业

好吃不贵

设计模式之美——里式替换(LSP)

GalaxyCreater

设计模式

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