选择语言

COLA:面向云微服务的集体自动扩缩容

分析COLA,一种创新的微服务应用自动扩缩容器,它通过全局优化虚拟机分配,在满足端到端延迟目标的同时最小化成本。
apismarket.org | PDF Size: 1.6 MB
评分: 4.5/5
您的评分
您已经为此文档评过分
PDF文档封面 - COLA:面向云微服务的集体自动扩缩容

1. 引言

云应用从单体架构向松耦合微服务的转变,给资源管理带来了显著的复杂性。开发人员必须决定为每个微服务分配多少计算资源(例如,容器副本、虚拟机)。这一决策对开发者的运营成本和应用程序用户的端到端延迟体验都至关重要。传统的自动扩缩容方法,例如水平Pod自动扩缩容(HPA),基于CPU利用率等本地指标独立地扩缩每个微服务。然而,这种方法并非最优,因为它忽略了应用工作流中微服务之间的相互依赖关系。COLA(集体自动扩缩容器)被提出作为一种解决方案,它以全局目标在所有微服务间协同分配资源:在确保应用程序端到端延迟低于指定目标的同时,最小化美元成本。

2. 独立自动扩缩容的问题

当前行业标准的自动扩缩容以分布式、按微服务的方式运行。每个服务在其自身资源利用率(CPU、内存)超过阈值时触发扩缩容操作(添加/移除虚拟机或Pod)。其根本缺陷在于,这种局部视角未能考虑应用程序的全局性能。如果链中的另一个服务仍然是瓶颈,那么改善一个微服务的延迟可能对用户感知的整体延迟影响微乎其微。这导致了低效的资源分配——过度配置某些服务,而对关键瓶颈服务配置不足——导致成本增加却未能达到期望的延迟服务水平目标(SLO)。

3. COLA:集体自动扩缩容方法

COLA将自动扩缩容问题重新定义为约束优化问题。它用一个单一的、集中式的控制器取代了多个独立的自动扩缩容器,该控制器对应用程序的微服务拓扑和性能具有全局可见性。

3.1. 核心优化框架

目标被形式化如下:

  • 目标: 最小化总计算成本。
  • 约束: 应用程序端到端平均或尾部延迟 ≤ 目标延迟。
  • 决策变量: 分配给每个微服务 $i$ 的虚拟机(或副本)数量,记为 $n_i$。

这是一个复杂的非线性优化问题,因为 $n_i$ 与端到端延迟之间的关系并非简单直接,而是依赖于工作负载模式和服务间通信。

3.2. 离线搜索过程

由于资源供应和性能稳定所需的时间,在线求解此优化问题是不切实际的。因此,COLA采用了离线搜索过程

  1. 工作负载应用: 对应用程序施加一个代表性工作负载。
  2. 瓶颈识别: 识别最拥堵的微服务(负载下CPU利用率增幅最大)。
  3. 通过多臂老虎机问题分配资源: 对于瓶颈服务,使用多臂老虎机公式确定最优的虚拟机数量。“奖励”函数平衡了延迟改善与成本增加。
  4. 迭代: 对下一个最拥堵的微服务重复步骤2-3,直到满足全局延迟目标。
  5. 策略生成: 结果是生成一个扩缩容策略(从工作负载特征到资源分配的映射),该策略可以在线部署。

COLA可以在已知工作负载之间进行插值,如果遇到未见的工作负载模式,则会回退到默认的自动扩缩容器。

4. 技术细节与数学公式

核心优化问题可以抽象地表示为:

$$\min_{\{n_i\}} \sum_{i=1}^{M} C_i(n_i)$$ $$\text{约束条件: } L_{e2e}(\{n_i\}, \lambda) \leq L_{target}$$ $$n_i \in \mathbb{Z}^+$$ 其中:

  • $M$:微服务数量。
  • $n_i$:微服务 $i$ 的资源单元(例如,虚拟机)数量。
  • $C_i(n_i)$:微服务 $i$ 拥有 $n_i$ 个单元时的成本函数。
  • $L_{e2e}$:端到端延迟函数,依赖于所有 $n_i$ 和工作负载强度 $\lambda$。
  • $L_{target}$:期望的延迟SLO。
COLA搜索过程中第3步的“老虎机问题”涉及将瓶颈服务的每个可能的虚拟机分配视为一个“臂”。拉动一个臂对应于供应该配置并测量由此产生的成本-延迟权衡。可以使用上置信界(UCB)等算法来高效地探索和利用配置空间。

5. 实验结果与评估

在Google Kubernetes Engine(GKE)上,COLA与多个基线自动扩缩容器(基于利用率的和基于机器学习的)进行了严格评估。

5.1. 实验设置

  • 应用程序: 5个开源微服务应用(例如,Simple WebServer, BookInfo, Online Boutique)。
  • 平台: GKE Standard(用户管理节点)和 GKE Autopilot(提供商管理基础设施)。
  • 基线: 标准HPA(基于CPU)、先进的基于机器学习的自动扩缩容器。
  • 工作负载: 63种不同的工作负载模式。
  • 目标: 满足指定的中位数或尾部(例如,p95)延迟SLO。

5.2. 关键性能指标

SLO达成率

53/63

COLA达到延迟目标的工作负载数量。

平均成本降低

19.3%

与次便宜的自动扩缩容器相比。

最具成本效益的策略

48/53

在53个成功的工作负载中,COLA在48个上是最便宜的。

小型应用的最优性

~90%

对于可以进行穷举搜索的较小应用程序,COLA在约90%的情况下找到了最优配置。

5.3. 结果总结

结果证明了COLA的显著优势。它在其他方法失败的情况下始终能达到期望的延迟SLO,并且成本大幅降低。成本节省非常显著,以至于运行COLA离线搜索的“训练成本”在几天内就能收回。在GKE Autopilot上,COLA的优势更加明显,因为它有效地利用了提供商管理的抽象层来最小化成本。

图表描述(设想): 柱状图的Y轴可能显示“每个成功请求的成本”或“集群总成本”,X轴是不同的自动扩缩容器(COLA、HPA、ML-A)。COLA的柱状图会显著更低。第二张图表可能显示“延迟SLO违反率”,其中COLA的柱状图接近零,而其他方法显示出更高的违反率。

6. 分析框架与示例案例

分析师视角:四步解构

核心洞见: 本文的根本突破并非花哨的新算法,而是一个关键的视角转变:将整个微服务应用视为一个需要优化的单一系统,而非独立部分的集合。这类似于计算机视觉领域由CycleGAN(Zhu et al., 2017)等模型带来的转变,该模型通过考虑整个变换域的循环一致性,超越了成对图像翻译。COLA将类似的“全局一致性”原则应用于资源管理。

逻辑流程: 论证过程极具说服力且简洁:1)局部最优(按服务扩缩)加总导致全局低效。2)因此,使用全局目标(成本)和全局约束(端到端延迟)。3)由于在线求解太慢,通过离线搜索求解并部署策略。其优雅之处在于使用老虎机问题来高效搜索瓶颈的最优分配,这是一种在系统优化的强化学习研究中得到广泛支持的技术(例如,来自UC Berkeley RISELab的工作)。

优势与不足: 优势: 实证结果非常出色——19.3%的成本降低是董事会级别的数字。离线方法是务实的,避免了运行时的不稳定性。该框架与平台无关。不足: 其致命弱点是对代表性离线工作负载的依赖。在快速演进的应用程序中或遇到“黑天鹅”流量事件时,预先计算的策略可能过时甚至导致灾难性后果。本文中回退到默认自动扩缩容器的做法,对于这种鲁棒性问题只是权宜之计,而非根本解决方案。此外,搜索复杂度很可能随着微服务数量的增加而急剧上升,可能限制其在极其庞大、复杂的应用中的使用。

可操作的见解: 对于云架构师而言,信息很明确:停止孤立地设置CPU阈值。投资于构建或采用全局性能可观测性和集中式决策引擎。从混合方法开始:运用COLA的理念定义关键服务链并在那里应用集体扩缩,同时让不太关键的、独立的服务继续使用传统的HPA。如结果所示,投资回报率可以很快显现。云提供商应注意;像GKE Autopilot这样的工具需要此类智能编排层,才能真正兑现“托管”基础设施的承诺。

7. 应用前景与未来方向

COLA背后的原理具有超越基本虚拟机扩缩的广泛适用性:

  • 多资源与异构扩缩: 未来版本可以协同决定虚拟机规格(内存优化型 vs. 计算优化型)、GPU分配,甚至跨可用区或云提供商的部署,以实现成本和弹性优化。
  • 与服务网格集成: 将COLA与服务网格(如Istio)耦合,将提供更丰富的遥测数据(请求级追踪、依赖关系图),甚至能够直接控制流量路由和熔断,作为优化的一部分。
  • 在线适应与元学习: 主要的研究前沿是克服离线限制。元学习技术可以使COLA基于实时反馈快速在线调整其策略,或在低流量期间安全地探索新配置。
  • 绿色计算目标: 通过整合来自Cloud Carbon Footprint项目等来源的数据,优化目标可以扩展到最小化碳足迹或能耗,与可持续计算倡议保持一致。
  • 策略市场: 对于常见的应用模式(例如,电子商务、媒体流),可以共享或出售预先优化的COLA策略,从而减少单独训练运行的需求。

8. 参考文献

  1. Sachidananda, V., & Sivaraman, A. (2022). COLA: Collective Autoscaling for Cloud Microservices. arXiv preprint arXiv:2112.14845v3.
  2. Zhu, J., Park, T., Isola, P., & Efros, A. A. (2017). Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks. Proceedings of the IEEE International Conference on Computer Vision (ICCV).
  3. Burns, B., Grant, B., Oppenheimer, D., Brewer, E., & Wilkes, J. (2016). Borg, Omega, and Kubernetes. Queue, 14(1), 70–93.
  4. Hoffman, M., Shahriari, B., & Aslanides, J. (2020). Addressing Function Approximation Error in Actor-Critic Methods. Proceedings of the 37th International Conference on Machine Learning (ICML). (Example of advanced RL relevant for online adaptation).
  5. Cloud Carbon Footprint. (n.d.). An open source tool to measure and visualize the carbon footprint of cloud usage. Retrieved from https://www.cloudcarbonfootprint.org/.
  6. Verma, A., Pedrosa, L., Korupolu, M., Oppenheimer, D., Tune, E., & Wilkes, J. (2015). Large-scale cluster management at Google with Borg. Proceedings of the European Conference on Computer Systems (EuroSys).