历川：华为云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所列的几个概念做简要说明。

表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、函数计费与成本模型

单实例视角下的函数计费估计模型，可参考 [2]。在真实生产环境中，除异步函数外，Serverless云平台通常采用FCFS（First Come First Serve）的方式响应调用请求，对于函数流量的潮汐波动，平台通过自动扩缩容实例进行自适应，系统中运行的并发实例数随时间的变化，可以由一个分段常线性函数完全刻画，如图2所示。

图2：函数并发实例数随扩缩容过程的变化

尽管不同Serverless云厂商之间的计费方法存在差异，函数计费一般主要包括两部分：对函数所使用资源的计费以及对请求次数的计费，表示如下：

，

其中， 表示对资源使用的计费，单位为GB-秒（GB-second）， 表示对调用次数的计费。

为方便计算TotalCost，用表示函数的资源规格，单位为GB, 例如，对于128MB规格的函数，其 ; c表示该函数的单实例并发数, μ表示函数的平均执行时延，单位为毫秒; 并用α (0<α<1)表示Serverless平台的调用链路性能，在最理想的情况下，该指标为1，表示在当前Serverless平台上，该函数响应单个请求的端到端时延等于函数执行时延μ本身，不同Serverless平台的α值可能略有不同，但通常在0.9以上。给定上述指标，可以得到单实例在理想状况下的请求处理能力, 即理论上每秒可以响应的调用次数为：

因此，单实例的实际请求处理能力则为：

我们以一个月作为估计周期。假设一个月内，函数共经历了n次扩、缩容，形成了n个常线性子区间（如图2所示）。先考察单个子区间内的计费成本模型，总成本模型则为各个连续子区间的加和。

在时间窗口内，假设函数调用次数为，则该时间窗内的并发实例数为：

对应的资源计费部分则可表示为：

其中， 表示每GB-秒的资源的计费单价。现在，记第i个子区间为 , 则一个月内的总成本模型可以估计为：

其中， 表示每次调用的计费单价， 表示函数该月总流量， 为云平台提供的月度免费计量时间， 为月度免费计量调用次数。

在上式中，单实例并发度c和函数规格可以认为在用户配置之后属于常数；α属于平台侧参数，也可视作常数；对于函数执行时延μ，实际中通常会由于冷热启动差异、网络抖动、调用请求入参等的不同而波动，且考虑到Serverless计费是精确到毫秒级别的，因此严格意义上不能被视作为常数。不过，作为估计模型，这里暂且假定μ也为常数，综上，总成本模型可以表示为：

后半部分代表云平台提供的免计费总量，与函数调用流量以及函数配置无关。

3、成本优化方法讨论

有了函数成本的估计模型，就可以对影响用户成本的关键因素进行讨论。 在估计式 (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）的函数成本结构中可以看出，在用户业务模型支持的前提下，配置一定的单实例并发度c，可以有效降低函数月度总成本；若用户不进行配置，云平台默认值通常为1，即单个实例同一时刻只能处理一个请求；因此，在函数被并发调用的情形下，平台会启动多个实例进行响应，从而增大了计费实例数目，如图6所示；同时，采用单实例多并发，也能改善调用请求处于等待状态的尾时延。

图6：单实例并发度：计费时长视角和实例数视角

当然，单实例并发度并非越高越好，例如，过高的并发度设置会使得函数实例内多线程之间的资源竞争加剧（e.g., CPU contention），导致函数响应性能恶化，影响用户应用的QoS指标等。同时，如本文在背景知识中所提，并非所有的应用函数都适合设置单实例多并发。单实例多并发主要适用于函数执行过程中有相当比例的时延消耗在等待下游服务返回的场景，这类场景下，实例资源如CPU等有显著比例处于空闲等待状态，如访问数据库、消息队列等中间件、或磁盘IO、网络IO等。单实例多并发也需要用户在函数代码中对错误捕获（e.g., 考虑请求级别的错误捕获粒度）和全局共享变量的线程安全（e.g., 加锁保护）问题进行适配。

Point 5: 函数资源规格的选择需考虑对执行时延的影响

最后讨论函数资源规格的选择问题。从公式（2）明显可以看出，更大规格的实例内存 对应更高的计费成本。但内存规格的选择，需要同时考虑对函数执行时延 的影响。从用户函数的角度看，函数执行时延除了由代码本身的业务逻辑决定之外，还受实例运行时可使用资源大小的影响。更大的实例规格，对应更大的可使用内存和更多的CPU份额，从而可能显著改善高内存占用型或CPU密集型函数的执行性能，降低执行时延；当然，这种改善也存在上限，超过某个资源规格后，资源的增加对降低函数执行时延的效果几乎可以忽略，如图7中虚线所表示的过程。上述事实表明，对于给定的用户函数，为降低总计费成本，需要配置合理的实例规格，使得尽可能取得最小值，如图7中实线所表示的过程。

图7：函数规格的选择需同时考虑对成本和执行时延的影响

例如，考虑实例规格的初始配置为（例如从最小规格开始，i.e., 128MB）, 经测试该规格下函数执行时延为，则可以得到基线，然后逐步增大资源规格，测试对应执行时延，直到某一组出现，使得：

此时表明，资源增大对计费成本的边际提升已经超过了对执行时延的边际改善，因此，从成本的角度看，此时的为帕累托最优解，即最佳规格，对应执行时延为。

最后，图8对上述几个决定函数成本的关键因素做了一个总结，其中，箭头方向表示元素之间的直接影响，“+”号代表成正比，“-”代表成反比。

图8：函数计费成本的关键因素分析

4、 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化改造等提供极致便捷性。

5、 总结与展望

本文主要讨论了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/