Serverless遇到 FinOps: Economical Serverless
摘要:本文基于FunctionGraph在Serverless 领域的FinOps探索和实践,提出业界首个Serverless函数总成本估计模型
历川:华为云Serverless研发专家
平山:华为云中间件Serverless负责人
冯嘉:华为云中间件首席专家
Key Takeaways:
1)尽管Serverless的迅猛发展吸引了广泛深入的关注,Serverless函数总成本的事先估计仍缺乏有效的理论指导。本文基于FunctionGraph在Serverless 领域的FinOps探索和实践,提出业界首个Serverless函数总成本估计模型;
2)根据对成本模型的关键因素分析,提出五大类函数运行成本的优化方法;同时,为更好地帮助用户实现降本增效,华为云首次提出透明、高效、一键式的 “用户函数成本研究中心”。
问题引言
Serverless 精确到毫秒级的按用付费模式使得用户不再需要为资源的空闲时间付费。然而,对于给定的某个应用函数,由于影响其计费成本的因素并不唯一,使得用户对函数运行期间的总计费进行精确的事先估计变成了一项困难的工作。
以传统云资源的周期性租赁模式为例,通过周期数乘以周期单价,用户可以很容易地估计出租赁期间的总费用,形成清晰的心理账户预期,即使在云平台采用阶梯定价或价格歧视策略的情形下,计算租赁总成本也不是一件难事。
但在Serverless场景中,事先估计函数总成本仍缺乏有效的理论指导。一方面,影响函数计费的关键因素不唯一,如包括函数内存规格、单实例并发度、函数执行时长等;另一方面,函数调用流量的波动通常具有随机性和非平稳性,使得基于流量的“按用计费”具有较大的不确定性。
当然,寻找函数计费的理论指导主要是为用户评估函数总成本提供一种有效依据,但更加重要地,如何进一步利用估计模型,帮助用户优化应用函数及其配置选择,进而显著降低用户函数总成本,是Serverless领域中,FinOps亟待回答的问题。
FinOps聚焦云上资源管理和成本优化,通过有机链接技术、业务、和财务专业人士,来优化用户、企业、组织的云资源成本,提高云上业务的投入-产出比 [1]。本文结合华为云FunctionGraph在Serverless 领域的FinOps探索和实践,剖析Serverless场景下的函数计费模式和关键影响因素,介绍一种对函数运行期间总计费进行事先估计的模型框架; 更重要地,该模型为帮助用户优化函数运行总成本、提升用户云上Serverless资源管理效能,实现经济型 (Economical) Serverless 提供有效依据。
一. 名词解释与背景知识
首先对表1所列的几个概念做简要说明。
表1:Serverless函数常见名词
内存规格 (Memory):内存规格也即函数规格、函数实例规格,表示Serverless平台为函数的单个实例所分配的资源大小,一般表示为函数可使用的内存大小,由用户指定;实例可使用的CPU份额与内存大小成正比。Serverless云平台通常提供多种规格供用户选择,以FunctionGraph为例,用户可选15种函数规格,如图1所示。
图1:FunctionGraph提供多种函数内存规格
函数执行时延 (Function Execution Time): 这里指完成一次调用请求响应的过程中,函数本身执行所消耗的时间,主要由函数代码逻辑决定。一般地,对于CPU密集型的函数,增大函数资源规格(内存-CPU Share),可以显著降低函数执行时延。但对于消耗大部分时间在网络IO等操作上的函数,增大资源规格对执行时延的改善则非常有限。
单实例最大并发度 (Maximum Requests per Instance):函数的单个实例可以同时处理的最大请求数,主要适用于函数执行过程中有显著时间在等待下游服务返回的场景,如访问数据库操作或磁盘IO等。对于相同的流量负载,提高函数的单实例并发度可以降低按量实例个数,为用户节省计费,同时,也可以降低函数调用请求的冷启动比例。
单函数最大实例数 (Maximum Instances per Function):指同一函数同一时刻下同时运行的实例数上限。对用户来说,最大实例数可以防止异常流量洪峰下或函数发生故障时由于云平台的过度扩容而导致的费用失控;对云平台来说,最大实例数可以防止异常情况下平台资源被部分函数耗光,从而保障不同函数间的性能隔离。
二. 函数计费与成本模型
单实例视角下的函数计费估计模型,可参考 [2]。在真实生产环境中,除异步函数外,Serverless云平台通常采用FCFS(First Come First Serve)的方式响应调用请求,对于函数流量的潮汐波动,平台通过自动扩缩容实例进行自适应,系统中运行的并发实例数随时间的变化,可以由一个分段常线性函数完全刻画,如图2所示。
图2:函数并发实例数随扩缩容过程的变化
尽管不同Serverless云厂商之间的计费方法存在差异,函数计费一般主要包括两部分:对函数所使用资源的计费以及对请求次数的计费,表示如下:
后半部分代表云平台提供的免计费总量,与函数调用流量以及函数配置无关。
三. 成本优化方法讨论
有了函数成本的估计模型,就可以对影响用户成本的关键因素进行讨论。 在估计式 (1) 中,忽略云平台提供的免计费总量,函数月度总成本的结构如下:
Point 1: 优化函数代码逻辑本身,降低函数执行时延
对于同样的函数流量负载,更低的执行时延 可以为用户节省更多计费成本。在用户业务逻辑允许的前提下,不断优化函数代码、提高函数执行效率是软件工程本身天然的诉求,但在Serverless场景下,这一点显得更为迫切。
具体地,考虑采用Python、Nodejs等轻量化编程语言,减少函数初始化配置中的非必要项,将连接其它服务如数据库等的操作尽量移到函数执行入口之前的初始化阶段完成,简化代码逻辑等。
另外,为帮助用户掌握函数运行情况,FunctionGraph为应用函数提供深度可视化的可观测能力,支持丰富的观测指标配置,包括调用次数、错误次数、运行时延等,如图3所示的函数运行时间监控示例。
图3: FunctionGraph 函数运行时间监控示例
Point 2: 优化函数代码包、依赖包、镜像大小
当函数调用触发冷启动的时候,从计费角度看,冷启动时延包含在执行时延 中一起计费,而冷启动中有相当比例的时延消耗在云平台从第三方存储服务(如华为云对象存储服务OBS)中下载用户的代码包、依赖包,或从镜像仓库服务中拉取用户应用镜像,如图4所示。尽管为了优化冷启动性能,目前大部分云平台均会采用各类缓存机制,对用户代码和镜像进行预缓存,但实例启动中消耗在用户代码加载上的时延仍然十分显著。因此,应尽可能优化函数代码包大小,包括对依赖包、镜像等进行瘦身,进而降低计费时长。
图4:冷热启动下的计费时长及优化点
Point 3: 编写功能聚焦的轻量化函数
在Serverless编程框架下,尽可能将函数编写为轻量型的、功能聚焦的程序代码,即“functions should be small and purpose-built”[3];让“一个函数只做一件事”,一方面,功能单一的函数,运行时延也更容易针对性地进行优化;另一方面,当一个函数内同时实现多个功能的时候,大概率会以所有功能都在性能上同时做出妥协为结果,最终提高了函数运行期间总计费。
图5:华为云FunctionGraph 函数流示例
若应用函数的确需要提供多个功能,可以考虑将大函数分解为多个小函数,然后通过函数编排的方式实现整体逻辑, 如图5所示的FunctionGraph函数流功能。大函数分解也是Serverless计算中用户处理超时(timeout)等异常场景的最佳实践之一 [4]。
Point 4: 业务模型支持的前提下,采用单实例多并发
从公式(2)的函数成本结构中可以看出,在用户业务模型支持的前提下,配置一定的单实例并发度 ,可以有效降低函数月度总成本;若用户不进行配置,云平台默认值通常为1,即单个实例同一时刻只能处理一个请求;因此,在函数被并发调用的情形下,平台会启动多个实例进行响应,从而增大了计费实例数目,如图6所示;同时,采用单实例多并发,也能改善调用请求处于等待状态的尾时延。
图6:单实例并发度:计费时长视角和实例数视角
当然,单实例并发度并非越高越好,例如,过高的并发度设置会使得函数实例内多线程之间的资源竞争加剧(e.g., CPU contention),导致函数响应性能恶化,影响用户应用的QoS指标等。同时,如本文在背景知识中所提,并非所有的应用函数都适合设置单实例多并发。单实例多并发主要适用于函数执行过程中有相当比例的时延消耗在等待下游服务返回的场景,这类场景下,实例资源如CPU等有显著比例处于空闲等待状态,如访问数据库、消息队列等中间件、或磁盘IO、网络IO等。单实例多并发也需要用户在函数代码中对错误捕获(e.g., 考虑请求级别的错误捕获粒度)和全局共享变量的线程安全(e.g., 加锁保护)问题进行适配。
Point 5: 函数资源规格的选择需考虑对执行时延的影响
最后讨论函数资源规格的选择问题。从公式(2)明显可以看出,更大规格的实例内存 对应更高的计费成本。但内存规格的选择,需要同时考虑对函数执行时延 的影响。从用户函数的角度看,函数执行时延除了由代码本身的业务逻辑决定之外,还受实例运行时可使用资源大小的影响。更大的实例规格,对应更大的可使用内存和更多的CPU份额,从而可能显著改善高内存占用型或CPU密集型函数的执行性能,降低执行时延;当然,这种改善也存在上限,超过某个资源规格后,资源的增加对降低函数执行时延的效果几乎可以忽略,如图7中虚线所表示的过程。上述事实表明,对于给定的用户函数,为降低总计费成本,需要配置合理的实例规格 ,使得 尽可能取得最小值,如图7中实线所表示的过程。
图7:函数规格的选择需同时考虑对成本和执行时延的影响
图8:函数计费成本的关键因素分析
四. Serverless函数成本研究中心
为用户降本增效,是FunctionGraph的核心理念。尽管前文分析的五种函数成本优化手段是站在用户视角下的讨论,但我们认为这些问题远不是只属于用户需要考虑的范围;相反地,FunctionGraph在持续探索如何最大限度地帮助用户在Serverless领域实现最佳的FinOps效果,让用户能够真正享受到Economical Serverless的福利;例如,在实例级别的深度可视化、可观测性前提下,帮助用户实现函数FinOps全流程的自动化,为用户提供透明、高效、一键式的函数资源管理和成本优化服务。
图9. 在线式资源消耗感知与规格动态推荐
为此,基于内部实践,FunctionGraph 将于近期推出“用户函数成本研究中心 – Cost Analysis and Optimization Center”, 为用户提供包括离线式函数最佳配置调优(offline power tuning)、在线式资源消耗感知与规格动态推荐(online resource recommendation, 如图9所示)、预测性函数弹性预览(predictive auto-scaling preview)等在内的多个重量级特性服务,最大限度降低用户实现函数FinOps的技术门槛,为用户业务开发、Serverless化改造等提供极致便捷性。
五. 总结与展望
本文主要讨论了Serverless计算场景下的FinOps 问题,给出了业界首个用户函数总成本估计模型,并根据该模型,为用户优化应用函数、提升Serverless资源管理效能、降低总成本提供理论参考和实践依据。
一项新兴技术领域的兴起,首先需要回答的问题是“Why & Value”, FunctionGraph作为华为元戎加持的下一代Serverless函数计算与编排服务,结合FinOps等技术理念,持续为用户提供经济型Serverless服务。 后续我们将分享更多围绕通用全场景Serverless的前沿理论及其案例实践,回馈社区,包括FunctionGraph在微服务Serverless化上的实践经验等。
参考资料:
[1] What is FinOps: https://www.finops.org/introduction/what-is-finops/
[2] Running Lambda Functions Faster and Cheaper: https://levelup.gitconnected.com/running-lambda-functions-faster-and-cheaper-416260fbc375?gi=4370e4c57684
[3] AWS Lambda Cost Optimizations Strategies That Work. https://dashbird.io/blog/aws-lambda-cost-optimization-strategies/
[4] Timeout Best Practices. https://lumigo.io/learn/aws-lambda-timeout-best-practices/
Serverless遇到 FinOps: Economical Serverless的更多相关文章
- Serverless 遇到 FinOps: Economical Serverless
Serverless 遇到 FinOps: Economical Serverless 摘要:本文基于 FunctionGraph 在 Serverless 领域的 FinOps 探索和实践,提出业界 ...
- 从零入门 Serverless | 在线应用的 Serverless 实践
作者 | 唐慧芬(黛忻) 阿里云产品专家 导读:毫无疑问,Serverless 能够在效率和成本上给用户带来巨大收益.那具体到落地又应该怎么做呢?本文就给大家详细解读 Serverless 的落地实践 ...
- 【转】OpenStack和Docker、ServerLess能不能决定云计算胜负吗?
还记得在十多年前,SaaS鼻祖SalesForce喊出的口号『No Software』吗?SalesForce在这个口号声中开创了SaaS行业,并成为当今市值460亿美元的SaaS之王.今天谈谈『No ...
- Serverless 架构:用服务代替服务器
Serverless 架构:用服务代替服务器 转载本文需注明出处:EAII企业架构创新研究院(微信号:eaworld),违者必究.如需 加入微信群参与微课堂.架构设计与讨论直播请直接回复此公众号:&q ...
- Serverless架构详解:开发者如何专注于业务代码本身?
本文来自腾讯云技术沙龙,本次沙龙主题为Serverless架构开发与SCF部署实践 演讲嘉宾:黄文俊,曾负责企业级存储.企业级容器平台等产品的架构与开发,目前主要负责SCF腾讯无服务器云函数产品相关. ...
- Serverless 架构的优点和缺点
Serverless 的优势 在我使用 Serverless Framework 开发 AWS Serverless 应用的过程中,最方便的莫过于,第一次部署和第二次.第三次部署没有什么区别.只需要执 ...
- serverless 项目配置及创建helloworld应用(二)
阅读目录 一:学习使用AWS Lambda来作为服务器引擎 二:使用serverless环境搭建 三:创建我们的第一个应用,hello world 服务 回到顶部 一:学习使用AWS Lambda来作 ...
- Containers vs Serverless:你选择谁,何时选择?
两者都是当今技术时代的热门话题,也都被视为是开发技术的竞争对手. 首先,还有相当多的好奇和担心.此外,两者都是可供工程师使用的.高效的.机器无关的抽象. 但是,在冠军之间,有一个不可逾越的鸿沟.你要么 ...
- 当我们在聊 Serverless 时你应该知道这些
作者 | 杨泽强(竹涧)阿里云技术专家 说起当前最火的技术,除了最新的区块链.AI,还有一个不得不提的概念是 Serverless.Serverless 作为一种新型的互联网架构,直接或间接推动了云计 ...
- 云开发如何解决serverless对端的最后一公里问题
前端圈从来不缺少新的技术.点子和话题,有些留下来了而有些则转瞬即逝.在决定一种新技术是否能够长久的所有因素里,最核心的必然是自身实力过硬能够经受住实践检验.而除此之外,这项技术所解决问题的广泛程度.受 ...
随机推荐
- CompletableFuture异步优化代码
CompletableFuture异步编排优化代码 我们在项目开发中,有可能遇到一个接口需要调用N个服务的接口.比如用户请求获取订单信息,需要调用用户信息.商品信息.物流信息等接口,最后再汇总数据统一 ...
- Arrays.asList()把数组转换成集合时,不能使用其修改集合相关的方法
Arrays.asList()把数组转换成集合时,不能使用其修改集合相关的方法,此处测试代码如下,这里使用add方法: 1 public class main { 2 public static vo ...
- C#经典十大排序算法(完结)
C#冒泡排序算法 简介 冒泡排序算法是一种基础的排序算法,它的实现原理比较简单.核心思想是通过相邻元素的比较和交换来将最大(或最小)的元素逐步"冒泡"到数列的末尾. 详细文章描述 ...
- Util应用框架 UI 开发快速入门
本文是Util应用框架 Angular UI 开发快速入门教程. Util前端技术概述 Util 应用框架目前仅支持用于开发管理后台的 UI. 本文介绍了 Util UI 的技术特点和功能支持. UI ...
- unity UGUI 正交相机实现图片的透视旋转效果
UI透视效果常见的就是绕x轴或y轴旋转,来达到近大远小的效果.正经要做透视UI的话肯定直接用透视相机,如果透视效果用的极少(就一张图)不改动相机类型才按这种思路进行. 最简单直接的想法就是把矩形的图片 ...
- 自定义Graph Component:1-开发指南
可以使用自定义NLU组件和策略扩展Rasa,本文提供了如何开发自己的自定义Graph Component指南. Rasa提供各种开箱即用的NLU组件和策略.可以使用自定义Graph Compo ...
- Kafka 集群如何实现数据同步?
哈喽大家好,我是咸鱼 最近这段时间比较忙,将近一周没更新文章,再不更新我那为数不多的粉丝量就要库库往下掉了 T﹏T 刚好最近在学 Kafka,于是决定写篇跟 Kafka 相关的文章(文中有不对的地方欢 ...
- Android 11 使用 BroadcastReceiver 监听短消息
使用装有MIUI系统的小米手机,静态注册的广播接收器监听短消息. 在AndroidManifest.xml中声明权限 <uses-permission android:name="an ...
- H.264 和 H.265对比
前言 H.264标准正式发布于2003年3月,距今已经20多年了,但它仍然是当下最流行的视频编解码标准. H.265正式发布于2013年4月.虽然H.265标准是围绕着H.264进行制定的,也保留了原 ...
- 🔥🔥Java开发者的Python快速进修指南:面向对象基础
当我深入学习了面向对象编程之后,我首先感受到的是代码编写的自由度大幅提升.不同于Java中严格的结构和约束,Python在面向对象的实现中展现出更加灵活和自由的特性.它使用了一些独特的关键字,如sel ...