云原生之深入解析基于FunctionGraph在Serverless领域的FinOps的探索和实践

一、背景

Serverless 精确到毫秒级的按用付费模式使得用户不再需要为资源的空闲时间付费。然而，对于给定的某个应用函数，由于影响其计费成本的因素并不唯一，使得用户对函数运行期间的总计费进行精确的事先估计变成了一项困难的工作。
以传统云资源的周期性租赁模式为例，通过周期数乘以周期单价，用户可以很容易地估计出租赁期间的总费用，形成清晰的心理账户预期，即使在云平台采用阶梯定价或价格歧视策略的情形下，计算租赁总成本也不是一件难事。
但在 Serverless 场景中，事先估计函数总成本仍缺乏有效的理论指导。一方面，影响函数计费的关键因素不唯一，如包括函数内存规格、单实例并发度、函数执行时长等；另一方面，函数调用流量的波动通常具有随机性和非平稳性，使得基于流量的“按用计费”具有较大的不确定性。
当然，寻找函数计费的理论指导主要是为用户评估函数总成本提供一种有效依据，但更加重要地，如何进一步利用估计模型，帮助用户优化应用函数及其配置选择，进而显著降低用户函数总成本，是 Serverless 领域中，FinOps 亟待回答的问题。
FinOps 聚焦云上资源管理和成本优化，通过有机链接技术、业务、和财务专业人士，来优化用户、企业、组织的云资源成本，提高云上业务的投入产出比。结合华为云 FunctionGraph 在 Serverless 领域的 FinOps 探索和实践，剖析 Serverless 场景下的函数计费模式和关键影响因素，分享一种对函数运行期间总计费进行事先估计的模型框架；更重要地，该模型为帮助用户优化函数运行总成本、提升用户云上 Serverless 资源管理效能，实现经济型 Economical Serverless 提供有效依据。
Serverless 函数常见名词：

内存规格	Memory	MB
单实例最大并发度	Maximum Requests per Instance	/
函数执行时延	Function Execution Time	ms
单函数最大实例数	Maximum Instances per Function	/

内存规格（Memory）：内存规格也即函数规格、函数实例规格，表示 Serverless 平台为函数的单个实例所分配的资源大小，一般表示为函数可使用的内存大小，由用户指定；实例可使用的 CPU 份额与内存大小成正比。Serverless 云平台通常提供多种规格供用户选择，以 FunctionGraph 为例，用户可选 15 种函数规格。
函数执行时延（Function Execution Time）：这里指完成一次调用请求响应的过程中，函数本身执行所消耗的时间，主要由函数代码逻辑决定。一般地，对于 CPU 密集型的函数，增大函数资源规格（内存-CPU Share），可以显著降低函数执行时延，但对于消耗大部分时间在网络 IO 等操作上的函数，增大资源规格对执行时延的改善则非常有限。
单实例最大并发度（Maximum Requests per Instance）：函数的单个实例可以同时处理的最大请求数，主要适用于函数执行过程中有显著时间在等待下游服务返回的场景，如访问数据库操作或磁盘 IO 等，对于相同的流量负载，提高函数的单实例并发度可以降低按量实例个数，为用户节省计费，同时，也可以降低函数调用请求的冷启动比例。
单函数最大实例数（Maximum Instances per Function）：指同一函数同一时刻下同时运行的实例数上限。对用户来说，最大实例数可以防止异常流量洪峰下或函数发生故障时由于云平台的过度扩容而导致的费用失控；对云平台来说，最大实例数可以防止异常情况下平台资源被部分函数耗光，从而保障不同函数间的性能隔离。

二、函数计费与成本模型

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

在这里插入图片描述

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

在这里插入图片描述

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

在这里插入图片描述

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

在这里插入图片描述

以一个月作为估计周期，假设一个月内，函数共经历了 n 次扩、缩容，形成了 n 个常线性子区间。先考察单个子区间 ΔT_second 内的计费成本模型，总成本模型则为各个连续子区间的加和。
在时间窗口 ΔT_second 内，假设函数调用次数为 Q_ΔT，则该时间窗内的并发实例数为：

在这里插入图片描述

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

在这里插入图片描述

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

在这里插入图片描述

其中，P_Request 表示每次调用的计费单价，Q=∑ⁿ~i = 1_QΔTi~ 表示函数该月总流量，Cost_{GB-second-free} 为云平台提供的月度免费计量时间，Q_free 为月度免费计量调用次数。
在上式中，单实例并发度 c 和函数规格 M_GB 可以认为在用户配置之后属于常数；α 属于平台侧参数，也可视作常数；对于函数执行时延 μ，实际中通常会由于冷热启动差异、网络抖动、调用请求入参等的不同而波动，且考虑到 Serverless 计费是精确到毫秒级别的，因此严格意义上不能被视作为常数。不过，作为估计模型，这里暂且假定 μ 也为常数。综上，总成本模型可以表示为：

在这里插入图片描述

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

三、成本优化方法

有了函数成本的估计模型，就可以对影响用户成本的关键因素进行讨论。在上面的估计式中，忽略云平台提供的免计费总量，函数月度总成本的结构如下：

在这里插入图片描述

① 优化函数代码逻辑本身，降低函数执行时延

对于同样的函数流量负载，更低的执行时延μ可以为用户节省更多计费成本。在用户业务逻辑允许的前提下，不断优化函数代码、提高函数执行效率是软件工程本身天然的诉求，但在 Serverless 场景下，这一点显得更为迫切。
具体地，考虑采用 Python、Nodejs 等轻量化编程语言，减少函数初始化配置中的非必要项，将连接其它服务如数据库等的操作尽量移到函数执行入口之前的初始化阶段完成，简化代码逻辑等。
另外，为帮助用户掌握函数运行情况，Function Graph 为应用函数提供深度可视化的可观测能力，支持丰富的观测指标配置，包括调用次数、错误次数、运行时延等，如下所示的函数运行时间监控示例：

在这里插入图片描述

② 优化函数代码包、依赖包、镜像大小

当函数调用触发冷启动的时候，从计费角度看，冷启动时延包含在执行时延 μ 中一起计费，而冷启动中有相当比例的时延消耗在云平台从第三方存储服务（如华为云对象存储服务 OBS）中下载用户的代码包、依赖包，或从镜像仓库服务中拉取用户应用镜像，如下所示：

在这里插入图片描述

尽管为了优化冷启动性能，目前大部分云平台均会采用各类缓存机制，对用户代码和镜像进行预缓存，但实例启动中消耗在用户代码加载上的时延仍然十分显著。因此，应尽可能优化函数代码包大小，包括对依赖包、镜像等进行瘦身，进而降低计费时长。

③ 编写功能聚焦的轻量化函数

在 Serverless 编程框架下，尽可能将函数编写为轻量型的、功能聚焦的程序代码，即“functions should be small and purpose-built”；让“一个函数只做一件事”，一方面，功能单一的函数，运行时延也更容易针对性地进行优化；另一方面，当一个函数内同时实现多个功能的时候，大概率会以所有功能都在性能上同时做出妥协为结果，最终提高了函数运行期间总计费。

在这里插入图片描述

若应用函数的确需要提供多个功能，可以考虑将大函数分解为多个小函数，然后通过函数编排的方式实现整体逻辑，下所示的 FunctionGraph 函数流功能。大函数分解也是 Serverless 计算中用户处理超时（timeout）等异常场景的最佳实践之一。

④ 业务模型支持的前提下，采用单实例多并发

从上面公式的函数成本结构中可以看出，在用户业务模型支持的前提下，配置一定的单实例并发度 c，可以有效降低函数月度总成本；若用户不进行配置，云平台默认值通常为1，即单个实例同一时刻只能处理一个请求；因此，在函数被并发调用的情形下，平台会启动多个实例进行响应，从而增大了计费实例数目，如下所示；同时，采用单实例多并发，也能改善调用请求处于等待状态的尾时延：

在这里插入图片描述

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

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

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

在这里插入图片描述

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

在这里插入图片描述

此时表明，资源增大对计费成本的边际提升已经超过了对执行时延的边际改善，因此，从成本的角度看，此时的 mⁱ_GB 为帕累托最优解，即最佳规格，对应执行时延为 μⁱ。
最后，如下，对上述几个决定函数成本的关键因素做了一个总结，其中，箭头方向表示元素之间的直接影响，“+”号代表成正比，“-”代表成反比：

在这里插入图片描述

四、Serverless 函数成本研究中心

为用户降本增效，是 FunctionGraph 的核心理念，尽管前文分析的五种函数成本优化手段是站在用户视角下的讨论，但这些问题远不是只属于用户需要考虑的范围；相反地，FunctionGraph 在持续探索如何最大限度地帮助用户在 Serverless 领域实现最佳的 FinOps 效果，让用户能够真正享受到 Economical Serverless 的福利；例如，在实例级别的深度可视化、可观测性前提下，帮助用户实现函数 FinOps 全流程的自动化，为用户提供透明、高效、一键式的函数资源管理和成本优化服务。

在这里插入图片描述

为此，基于内部实践，FunctionGraph 将于近期推出“用户函数成本研究中心 – Cost Analysis and Optimization Center”，为用户提供包括离线式函数最佳配置调优（offline power tuning）、在线式资源消耗感知与规格动态推荐（online resource recommendation，如图9所示）、预测性函数弹性预览（predictive auto-scaling preview）等在内的多个重量级特性服务，最大限度降低用户实现函数FinOps 的技术门槛，为用户业务开发、Serverless 化改造等提供极致便捷性。