【精彩内容分享】SoCC 2022 | 大规模云系统自动化容量评估的探索与落地 – DeepScaling

以下内容来自公众号【蚂蚁技术风险TRaaS】

1.前言

在线服务提供商比如Google、Facebook、蚂蚁、腾讯等为了保证自身服务的SLO，在进行资源配置时通常会采取“保守”策略：即配置相对较低的目标CPU利用率，以预防峰值流量带来的冲击，即使这将导致潜在的资源浪费。

但研究表明，服务器集群长期处于较低的CPU利用率，除了物理资源的浪费，能源消耗（电力）同样会大幅增长[12, 18, 19]。针对这个问题，直觉上可以将低负载服务的物理资源腾挪给高负载服务，来提高低负载服务的资源利用率，减少资源浪费和能源消耗，另一方面，更能够有效提升高负载服务的业务体验（例如降低RT、减少error）。

为此，蚂蚁一直在试图寻找一种自动化容量评估系统来使系统的CPU利用率能够被稳定在所需的目标水位，并能够保障我们的服务SLO得到满足。

这项工作在耗时敏感的金融支付服务中，挑战更为严峻：

●首先需要确保以及时、反应迅速的服务来保证用户的体验质量（稳定性）

●其次应当确保适当的资源供应，而不会出现明显的过度供应（有效性）

●并能够适应连续、显著的负载变化（灵活性）

为此，我们结合蚂蚁自身的基础设施架构、线上业务诉求，设计开发了这一套名为DeepScaling的自动化容量评估系统，在减少线上服务器集群资源消耗低同时，保障线上业务SLO不被打破。即通过深度学习方法寻找能够保障服务SLO的最大CPU利用率，并将线上服务CPU利用率稳定在这一水位，以实现资源节省，如下图1所示：

图1.DeepScaling的达成目标示例

这套系统于2020年底开展规划，于2021年上半年完成开发，2021年中投入使用。基于该工作沉淀出的学术论文《DeepScaling: Microservices AutoScaling for Stable CPU Utilization in Large Scale Cloud Systems》[0] 已发表于云计算领域唯一顶会ACM Symposium on Cloud Computing（SoCC) 2022。该工作由蚂蚁集团、重庆大学、加州大学河滨分校(UC Riverside)合作完成。

SoCC 2022从数百篇投稿中仅仅接收了38篇论文，来自世界著名大学如MIT，UCBerkeley，Stanford，UIUC等以及云计算大厂Microsoft，Amazon，Google，IBM等。来自国内企业界的论文包含华为参与的有4篇，阿里巴巴参与的有5篇(恭喜阿里云)，来自蚂蚁的只有我们这一篇。

2.背景和现状

2.1 蚂蚁背景

当前蚂蚁拥有超过大量在线应用部署单元，资源规模庞大，虽然部分应用的峰值CPU利用率较高，但在线应用的平均CPU利用率长期处于低水位，存在大量波谷资源的优化空间。

一个典型的微服务系统如下图2所示，通常以用户请求开始，以对数据的操作结束，且系统中每个微服务节点，由其所在链路层级决定，各自承载不同的业务量，如PV、rpc、msg、dal、cal等，由此导致每个app都具有不同的workload特性。

图2.一个简单的拥有5个微服务的系统架构

另一方面，即使是同一workload类型主导的应用，由于上下游链路承载业务的差异性，波峰波谷周期的差异性，以及系统内部定时任务的差异性，真正建模时也拥有着各种各样的特性。

因此，我们需要一套适合蚂蚁在线应用的全局容量自动化评估体系，满足线上如此复杂业务特性的业务高稳定性和千人千面的需求。

2.2. 业界现状

过往，工业界和学术界对于自动化容量评估的研究，主要可以划分为两大类：

●rule based schemes [2, 3, 7]

●learning-based schemes [4, 8, 10, 13, 14, 15]

Rule based方法通常采取对系统性能指标（如CPU利用率，内存利用率等）/业务指标（如RT、error等）设置阈值的方式，当观测指标上涨超过上界时进行扩容，当观测指标下降低于下界时触发缩容。Rule based方法的主要限制在于，它们需要大量的专家经验/领域知识来为不同的服务设置适当的阈值。此外，为每个微服务设置阈值需要大量人力投入（该成本可能接近甚至超过资源节省的收益），因为大规模工业系统通常有超过数千个微服务，且由于不同的微服务特性不尽相同（如计算密集型和数据密集型等），不同服务的阈值必须以不同的方式进行设置。这在大规模云服务系统中是难以实现，且成本巨大的。

Learning-based方法可以有效地减少人力投入，这在大规模云服务系统中是至关重要的，但目前的研究很少兼顾资源浪费（由于服务负载的变化）和SLO的保证 [14]。而这在生产云环境中却十分常见，例如蚂蚁自身的在线支付系统需要数以万计的容器以满足一天中某些时段的峰值需求，而在其余时间只需要几千个容器，在夜间可能需求更少。但资源管理员倾向于过度提供服务资源以满足高峰期的SLO，导致各种资源的长期处于低利用率状态（平均意义上）。

当前业界公开的learning-based方案主要以减少系统异常为目标，这些异常通常包括服务RT达到某一临界值，CPU利用率过高，或者出现内存溢出等，此类框架主要以FIRM和Autopilot为代表，分别来自学术界UIUC和Google工业界实践。

●FIRM使用机器学习技术检测服务性能异常（例如，微服务的RT异常升高），以便在发生此类异常时，可以通过添加更多的pod或计算资源来扩容。FIRM最主要的限制在于，只有在性能异常发生后才会进行自动缩放，这有可能使服务异常持续一段较长的时间。大规模的自动缩放可能需要几分钟的冷启动，或者至少几秒钟的热启动。FIRM的另一个限制是，由于通过系统异常进行触发，当分配给微服务的资源超过必要时，它无法提供缩小规模的策略。

●Autopilot将微服务的CPU利用率的时间序列作为输入，通过启发式机制输出目标CPU利用率，然后使用此目标CPU利用率以线性函数折比的形式计算所需的pod数。Autopilot的优势在于设计简洁，但根据我们对Autopilot的实现和实验，Autopilot仍然面临比较严峻的系统稳定性问题，因为对所需pod数量的估计常常不够精确。这主要由如下两个原因导致：（1）CPU利用率和计算资源之间的关系通常是非线性的，而Autopilot则使用完全的线性假设；（2） 不同的微服务对计算和I/O资源的需求通常存在差异，不应简单视为一致。

此外，也有很多工作负载驱动的自动缩放方法。例如，[1]使用回归树来建模pod数量和RT之间的关系，然后生成建议的pod数量，以避免服务RT超时。[13]利用工作负载的当前状态、微服务调用链数据来建模微服务，以及使用图形神经网络（GNN）表示调用结构，其专注于预测尾部延迟，寻求主动优化每个微服务可用的总CPU资源，同时满足延迟SLO。这些基于RT的方法虽然直接对SLO进行优化，但通常难以精确建模，原因在于RT的分布和状态转移比起CPU利用率的刻画，是十分困难的。

由此，一个简单的想法是规避SLO的直接建模，通过一个性能模型来描述服务CPU利用率或内存利用率的变化，来间接反应。例如，[6]建议对每个pod实例的个体性能进行基准测试，并预测工作负载。[17]提出了一种方法，可以自动识别需要扩展的服务，并对其进行扩展以满足SLA，同时为系统提供最佳成本。然而，这些方法在维护SLO之外，对于节省服务资源并未能取得显著成效。

3.DeepScaling详解

DeepScaling提出了一个新的容量评估目标，旨在从一个最初的粗略的目标CPU水位出发，通过机器学习方法，最大化目标CPU利用率（即自动寻找能够保障服务SLO的最大CPU利用率，规避专家经验/领域知识），并将线上服务CPU利用率稳定在这一水位（以实现资源节省）。整体架构如图3所示。

图3.DeepScaling系统架构

3.1 DeepScaling整体架构

整体的系统架构如图3所示，包含如下模块：

●Load Balancer：每个服务的负载均衡强制执行一个策略，将请求公平地分发到为相应服务提供的pods。服务在同一数据中心部署和自动扩展，该区域通常具有相同的硬件配置，以便服务的每个实例，承载大致相同的工作负载，并具有相同的CPU利用率。

●Service Monitor：服务监控侧重于实时收集所有服务的指标，包括七个工作负载指标、CPU利用率、有关实现SLO的信息（RT、error等）以及实例数，收集的数据被聚合到分钟粒度。对所有工作负载度量数据进行汇总，并对每个服务的所有实例的CPU利用率数据进行平均。

●Workload Forecaster：我们分析每个微服务的调用图和主要工作负载指标，然后使用时空图网络（STGNN）预测每个微服务的工作负载。调用图有助于建模服务之间的流量关系。因此，STGNN对每个时间段（例如30分钟）的工作负载指标进行了高度准确的预测，预测的工作负载将被反馈到CPU Utilization Estimator。

●CPU Utilization Estimator：此模块基于7个工作负载指标以及3个特定的辅助变量（服务ID、时间戳和实例计数）估算CPU消耗。这10个（=7+3）指标与CPU利用率之间的非线性关系由深度概率回归网络建模。依据Scaling Decider给出的最新实例数作为输入，本模块输出CPU利用率的估计。

●Scaling Decider：在本模块中，采用强化学习（RL）模型生成自动缩放策略。详细来说，model based DQN模型与CPU Utilization Estimator一起工作，以快速确定最佳服务实例数。为了允许共享策略生成模型中包含多个服务，我们将服务ID包含在DQN模型的经验池中。

●Target level Controller：CPU目标水位(