关于serverless:为什么-Serverless-能提升资源利用率

木吴|阿里云智能高级技术专家

业务的负载往往不是变化无穷的，而是随着工夫出现肯定的高低稳定。传统的利用构建形式个别是备足充沛的资源以保障业务可用性，造成资源利用率不高的景象。随着容器技术的遍及，利用能够通过弹性伸缩或者利用混部的形式来晋升资源利用率，但因为资源管理的复杂度，难以在业务可用性和资源利用率上获得较好的均衡。
Serverless 平台的呈现，将资源管理的责任从用户侧转移到平台侧。这种责任转移可能让用户专一在业务开发上，而平台自身利用其资源规模和负载多样性的劣势，专一在资源利用率的晋升上。业务应用 Serverless 平台可能大幅晋升资源利用率，实现降本提效的成果。

利用率的问题

业务的负载是动态变化的，而资源的弹性往往跟不上负载变动，所以会呈现资源利用率不高的状况。为了简化部署运维的复杂度，个别利用在部署时往往指定固定的实例数，此时资源和负载的变动如下图所示：

能够看到，有大量的工夫存在资源的节约，按日均匀资源利用率来计算不到 30%。而资源利用率间接关系到老本，如果资源利用率晋升一倍，老本就能降落 50%。最现实的状况是资源齐全贴合负载，如下图所示：

但事实的状况是很难做到，起因有两个：

1. 负载的变动能够是很快的，然而资源的创立却须要更长的工夫
2. 资源的弹性成功率不是 100%，出于稳定性思考须要预留资源 Buffer

因而，理论的资源情况是介于上述两种状况之间，业务开发者能够通过一些伎俩来晋升资源利用率，使其迫近 100%。接下来咱们看一下一些罕用的晋升资源利用率的伎俩。

晋升利用率 - 弹性伸缩

容器化的利用通常会应用弹性伸缩来晋升资源利用率。最典型的是应用 K8s 的 HPA 策略，设置一个 CPU 利用率阈值，当容器的 CPU 利用率超过阈值时主动减少容器，低于阈值时主动缩小容器。应用 HPA 后业务负载和资源变动状况如下：

能够看到，在新增的资源创立实现之前，已有的资源要留有一些余量以缓冲负载的回升。在下面这种阶梯形的资源变动状况下利用率是多少呢？让咱们来定量地剖析一下。

能够看到，须要预留的资源和负载的上升幅度以及扩容工夫无关。假如在扩容工夫 T 内，负载从 A 回升到 B，理论须要的资源从 xA 扩容到 xB。为了在资源创立实现之前可能接住负载，当负载为 A 时须要有的资源量是 xB，则资源利用率是负载增长斜率和扩容工夫的一个函数。当负载的增长比例 K 确定时，资源利用率 Util 是一个对于扩容工夫 T 的反向函数，扩容工夫越短，则资源利用率越高。
例如在负载每分钟减少 100% 的状况下，资源利用率和扩容工夫的关系。

• 当扩容工夫为 1 分钟时，资源利用率为 50%
• 当扩容工夫为 5 分钟时，资源利用率为 17%

扩容工夫是晋升资源利用率的要害。从负载开始回升，到新容器创立实现，整个扩容工夫能够分解成如下图所示：

1. 反应时间

   1. 指标采集工夫：例如 CPU 指标的采集须要取一段时间内的 CPU 均匀利用率
   2. 决策工夫：例如 CPU 指标的采集须要间断 N 次大于阈值才会触发扩容

2. 启动工夫

   1. 零碎冷启动：零碎筹备机器和容器环境的工夫
   2. 利用冷启动：容器启动后利用的初始化工夫，例如 JVM 的启动，初始化中间件，加载数据等等

如何缩短扩容工夫？上面比照 K8s 和函数计算 FC 在各个阶段的优化：

镜像：3s
容器池化、代码包 / 镜像减速 |
| 利用冷启动 | 10ms ~ 10min | 10ms ~ 10min |

函数计算 FC 通过申请级别的调度，将反应时间缩短到 0；通过代码包和镜像减速，将冷启动工夫优化到最低 200ms。在利用冷启动工夫雷同的状况下，函数计算 FC 的扩容工夫比 K8s 快 1 分钟。若利用冷启动较快 (10s)，则函数计算 FC 的资源利用率会大幅优于 K8s；若利用冷启动较慢 (1min)，则 K8s 的利用率和函数计算 FC 差距变小。如下图所示：

利用冷启动工夫的优化，在函数计算 FC 场景下可能大幅晋升资源利用率。然而因为利用冷启动和具体的应用逻辑相干，比拟难做通用的优化。一些可能的优化方向有：

1. 利用革新：将 Java 利用革新成 Nodejs/Python 等轻量的函数，将镜像革新成代码包形式，但革新代价较大。
2. 函数快照：将曾经初始化实现的函数实例做成镜像，通过镜像疾速拉起新的实例。但镜像突破了实例的独特性，例如一些利用初始化生成的 UUID 在同一镜像拉起的实例中会抵触。
3. 数据加载减速：一些利用在初始化时须要从 OSS 加载大量数据，零碎能够通过 Cache/P2P 等形式减速数据的加载

总结下 HPA 存在的一些问题：

1. 弹性速度问题：弹性速度慢导致 buffer 留得多，利用率低
2. 缩容速度问题：缩容速度慢，有察看窗口

3. CPU 阈值难以设置：靠业务教训，往往过低

   晋升利用率 - 混部超卖

   容器化的利用晋升资源利用率的另一种形式是混部和超卖。容器集群的应用模式有两种：

4. 经典 K8s 模式：有节点池，Pod 创立在节点上，须要关注容器利用率和节点资源分配率
5. Serverless K8s 模式：无节点池，Pod 由 Serverless Container 承载，只须要关注容器资源利用率

在经典 K8s 模式下，容器的弹性伸缩并没有晋升资源利用率，即便将容器删除掉了，节点也还在。而节点的弹性伸缩不如容器灵便。在这种状况下，混部和超卖是晋升资源利用率的常见做法。在 K8s 外面通过 resource.request < resource.limit 来实现超卖: K8s 在调度时依据 resource.request 来调配容器，然而依据 resource.limit 来限度容器的资源应用。

能够看到，一个节点上的容器的最大应用资源加起来，会超过节点的资源限度。能这样做的假如是每个容器的资源应用不会同时达到 resource.limit，否则就会产生资源竞争，导致性能降落甚至 OOM。但这样的假如并不总是成立的，每个容器的资源应用是动态变化的，这样就有肯定的概率会呈现资源竞争。混部超卖要达到较好的成果并不容易，影响混部成果的因素包含资源池大小，负载多样性，性能稳定性，超载迁徙策略等。
首先是资源池大小，资源池越大，产生资源竞争的概率就越小。让咱们来定量分析一下竞争的概率：假如有 4 个利用，每个利用的资源使用量有 50% 概率是 1，50% 概率是 2。咱们来比照将它们放在一个大的资源池和两个小的资源池的产生竞争的概率：

能够看到大资源池的概率要显著低于小资源池。最直观的，A 和 C 同时为 2 的时候，在小资源池模式下必然产生竞争，然而在大资源池下未必会产生竞争。对于具体的业务利用来说，因为负载规模不大，资源池也就比拟小，混部产生竞争的概率就会较大。
其次是负载的多样性，负载越多样越互补，混部的成果就越好，资源利用率就越高。这种多样性既包含资源需要的多样性，例如有的负载是 CPU 密集型而有的是 IO 型的；也包含工夫稳定的多样性，例如有的负载是早顶峰而有的是晚顶峰。

对于具体的业务利用来说，负载的多样性不够，资源利用率难以进一步提高。
最初是超载迁徙，当节点的负载过高时，须要将一部分容器迁徙到其余的节点。这个迁徙过程须要是平滑的，不影响业务。在 K8s 中调度器是不感知利用申请流量的，因而在超载迁徙时，须要应用层通过健康检查、优雅高低线等机制配合进行迁徙。如果没有及时迁徙就会导致申请失败影响服务质量。
总结下混部存在的一些问题：

1. 资源池不够大：资源竞争概率高
2. 负载多样性不够：资源竞争概率高，利用率不高

3. 超载迁徙不平滑：节点超载时流量迁徙不平滑

   晋升利用率 – Serverless

   弹性伸缩和混部超卖是晋升资源利用率的无效形式，但因为其固有的复杂度属性，业务开发者往往须要投入较大的精力能力获得较好的成果，而这些基础设施相干的工作，往往不是业务开发者的外围竞争力。业务开发者之所以须要想尽方法来晋升资源利用率，最基本的问题是机器是属于业务开发者的。是否将业务开发者从机器运维中解放出来呢？Serverless 提供了一种产品状态，将资源管理的责任从用户侧转移到平台侧。这样，业务开发者只须要为业务申请付费，而无需关注资源利用率，专一在业务翻新上。

   Serverless 并不是没有服务器了，而是将服务器的治理、运维和利用率晋升这些工作集中到平台侧，施展平台在资源规模、负载多样性上的劣势，晋升机器的资源利用率。下图是 Serverless 零碎的外部架构，通过零碎侧的流量治理、弹性伸缩和混部超卖，晋升集群的资源利用率：

4. 通过深度垂直优化，晋升冷启动速度，做到弹得快
5. 通过排汇不同的业务负载，扩充资源池规模，减少负载多样性，晋升混部效率

从用户侧来看，利用 Serverless 平台提供的能力来晋升业务侧的资源利用率：
a. 申请调度：按申请工夫计费，闲置工夫不计费，实例的工夫利用率为 100%

b. 闲置计费：应答利用冷启动慢的业务，提供预留实例闲置计费，当实例没有申请时，费用升高到 1 /10

c. 动静并发度：针对 CPU 阈值设置过低的问题，零碎依据理论流量动静决定最佳并发度，寻找吞吐拐点

论断

因为负载的动态变化，资源的容量评估和利用率晋升，是困扰业务开发者的问题。通过弹性伸缩和混部超卖来晋升资源利用率的形式因为其固有的复杂度，施行的成果并不现实。Serverless 平台将资源管理的责任从用户侧转移到平台侧，让业务开发者专一在业务开发上，而平台自身利用其资源规模和负载多样性的劣势，专一在资源利用率的晋升上，实现共赢。
对于业务开发者而言，依据利用的特点，能够采取如下的选型门路：

1. 对于启动快的利用，间接应用按量模式，达到 100% 利用率
2. 对于启动慢的利用，能够抉择优化启动速度，也能够抉择应用预留模式 + 闲置计费，晋升利用率
3. 能够立刻开始应用 Serverless 的利用：定时工作，Web-hook

有奖体验

函数计算团队全新上线“ 函数计算 FC 一键部署 通义千问 预体验、文生图、图生图、图生文、文生文 5 大经典 AI 场景 ，让您取得通义千问 30 次对话预体验机会，同时简略、高效实现一键部署图像生成、文字生成服务，速成 AIGC 创作家。

双重奖品设置

• 实现函数计算开明及利用部署，赢取开发者社区 400 积分；
• 加入 AI 生成图像较量赢取 AirPods（第三代）、阿里云定制蓝牙音箱、阿里云定制清雅杯！

参加流动链接👇
https://developer.aliyun.com/topic/aigc_fc#J_5808073260