预测技术在美团弹性伸缩场景的探索与应用

管理企业大规模服务的弹性伸缩场景中，往往会面临着两个挑战：第一个挑战是精准的负载预测，由于应用实例的启动需要一定预热时间，被动响应式伸缩会在一段时间内影响服务质量；第二个挑战是高效的资源分配，即在保障服务质量的同时控制资源成本。为了解决这些挑战，美团基础技术部与中国人民大学信息学院柴云鹏教授团队展开了“预测技术在弹性伸缩场景的应用”科研合作，相关论文《PASS: Predictive Auto-Scaling System for Large-scale Enterprise Web Applications》在具有国际影响力的会议The Web Conference 2024（CCF-A类会议）上作为Research Full Paper发表。

1 背景

在管理企业大规模服务弹性伸缩的场景下，Web应用的负载时序数据分析和预测至关重要。然而，由于应用的周期性特征和负载的复杂性，寻找一种能够适应所有应用的预测模型成为了一项挑战。首先，应用的负载数据往往具有周期性，这就需要在进行分析和预测时，需要考虑到这种周期性的影响。其次，由于业务特征的差异，预测算法可能在不同的应用下表现出差异化的效果，不存在“one-size-fits-all”的情况。例如，经测试发现，虽然在线模型的预测效果大多数时候好于离线模型，但在一些规律的突增情况下，在线模型经常存在滞后性的问题。这些问题都需要在对应用负载时序数据分析和预测时，进行深入的研究和探讨。

除了准确的负载预测，还需要高效的弹性伸缩策略。目前，业界常用的弹性伸缩策略有基于规则的阈值法、基于控制论的目标追踪和排队论。然而，我们发现这些方法并不能有效地保障QoS（Quality of Service，服务质量），尤其是QoS包含对尾延迟的要求时，其背后原因是这些策略的性能模型并不准确。阈值法和目标追踪的性能模型是“当QPS或CPU利用率在给定的范围内时QoS达标”。但这些阈值通常是根据人工经验设置的，并不总是准确。排队论根据统计模型推导在给定的负载和资源下业务的延迟，但它依赖的理论假设（例如用户请求到来的分布）并不总在现实中成立，使其估算的延迟和真实值有偏差。我们在测试中也发现了排队论估算的延迟会略低于真实延迟，因而导致出现服务质量不达标。此外，基于AI的弹性伸缩方法例如强化学习并不一定适用企业的生产环境，因为AI模型缺乏一定的可解释性，且可能会在线上做出有QoS违例风险的行为。

2 探索分析

2.1 预测实验探索

发现1：由于预测算法的固有限制，没有一种单一的算法能够在所有类别的时序数据中都提供最佳的预测效果。多样化的预测算法对于美团丰富的业务流量预测更有效。

我们对美团的服务流量数据进行周期检测（计算ACF自相关系数），发现92.80%的应用表现出强周期性（相关系数大于0.8），4.55% 显示出弱周期性（相关系数介于0.5~0.8之间），只有2.65%的应用没有表现出明显的周期性（相关系数小于0.5）。因此，对于美团内的大多数服务，可以使用模型可靠地预测QPS流量数据。

我们使用225个美团真实服务流量数据对业界常用的预测算法进行了测试。实验结果表明，预测效果最好的算法并不是单一的，而是取决于业务流量的具体特征。如图1(a)和(b)所示，我们使用三个代表性服务的流量数据来说明周期因子算法（Seasonal index）和 patchTST模型的预测效果。 在图1(a)中，对于服务1，周期因子算法显著优于patchTST，而在图1(b)中，对于服务2，patchTST却又比周期因子预测效果更好。这一实验说明了最优预测算法的动态多样性，我们需要针对业务流量特征选择最合适的预测算法。

发现2：在线预测提供了较高的平均预测准确度，但在“突变特征”表现不佳。 相比之下，离线预测可以捕获“突变特征”，但存在明显的“振幅偏差”问题。

在线预测模型实时地获取最新的数据输入，输出未来一小段时间（如：15分钟）的预测数据。 离线预测模型无需实时数据输入，直接预测未来较长一段时间（如：1天）的预测数据。 由于缺乏最新实时数据的输入，离线模型往往无法达到和在线模型相同的预测准确性。但在一些有规律的突增时间点，离线模型能够捕捉到突变的周期性特征，从而取得“及时”的预测效果。例如，在周期性“突变特征”的情况下，在线模型可能会表现出预测滞后（图1(c)中的黑色圆圈突出显示）。 这种滞后效应会持续一段时间，我们称之为“脏区间”。

相反，离线模型有效地捕获这些信息，从而能够及时进行预测。然而，离线模型存在着“振幅偏差”的问题，即特征的形状被准确地表示，但其绝对值存在差异（见图1(d)）。“突变特征”在美团服务中尤其普遍，这是由于美团许多业务都存在午、晚流量高峰。虽然“突变特征”只占实际时间序列数据的一小部分，但这些特征的精确预测对于在生产环境中维持QoS至关重要。

2.2 伸缩方法分析

发现3：云平台广泛使用的弹性伸缩方法并不能有效保障QoS，特别是当QoS要求对尾延迟的保障时。 与平均响应时间RT相比，当QoS要求为TP999尾延迟时，表1中几种方法的QoS保障率都显著降低。然而，大多数业务应用都需要关于尾延迟的保障，这使得弹性伸缩方法效率并不高，要么接受QoS违例，要么多冗余资源。

发现4：这些弹性伸缩方法的性能模型不够准确。基于阈值的规则和目标跟踪背后的性能模型实际上是“当QPS或CPU利用率在一定范围内时QoS达标”。 而这个范围的参数是根据人工经验确定的。表1的结果证明它并不完全有效。另外，排队论因为过于依赖理论假设而不够准确，导致其估计的RT低于真实值，从而出现QoS违例。

目前云平台的常见弹性伸缩方法有以下几种：

• 阈值法：基于一系列包含阈值的规则来进行弹性伸缩。以CPU资源利用率为例，当资源利用率超过上限阈值时，增加资源，反之，当利用率低于下阈值时，减少资源。阈值参数通常凭经验设置。
• 目标追踪：一种基于反馈的控制论方法，将某个指标（例如CPU资源利用率）维持在特定范围内。当实际资源利用率不在设定范围内时，系统会根据当前状态自动计算需要伸缩的实例数量。例如，假设CPU和流量呈线性相关的前提下，当前10个实例的平均CPU资源利用率为80%，目标值为50%，则实例需要扩容为80%*10/50%=16个实例。
• 排队论：根据排队论模型计算性能指标（例如延迟）并进行相应的伸缩以确保QoS达标。常见的𝑀/𝑀/𝑠模型表示请求到达和处理的时间呈指数分布，共有𝑠服务器并行处理。阿里巴巴的弹性伸缩框架AHPA使用排队论作为性能模型。
• 强化学习：弹性伸缩模块充当代理并与环境交互，在每次执行伸缩操作后接收奖励反馈。它通过反复试验建立状态（当前监控指标）和动作（伸缩多少实例）之间的映射模型。

大部分云平台使用的弹性伸缩方法都是简单或直接的，比如：阈值法、目标跟踪和排队论。强化学习和其他人工智能相关方法使用较少，因为它们可能会影响在线业务的性能。 我们使用若干具有代表性的后端服务测试了常用弹性伸缩方法的QoS保障率。由于我们的主要目的是验证QoS保障率，因此我们使用了阶梯式增加的工作负载。QoS保障率和资源成本的结果如表1所示。QoS保障率是用QoS保障时长除以总时长计算得出的。资源成本由实例数随时间（分钟）的积分得到。

3 技术方案

为了解决这些问题，我们提出了 PASS（Predictive Auto-Scaling System），这是一种为企业大规模在线Web应用定制的预测弹性伸缩系统。为了保障预测框架准确性和鲁棒性，我们根据每个应用的特征，动态匹配和校准其适合的预测算法，有效应对了业务负载的多样性。我们进一步建立了基于在线历史日志的性能模型以保障多样化的QoS，可解释的同时不会对在线业务产生负面影响。 除了基于负载预测和性能模型的主动伸缩以外，我们还设计了响应式的兜底策略，以及时应对因不准确的预测或意外事件导致的服务质量违例。在美团广泛的业务应用和真实负载下，相对于表1中其它方法，PASS 表现更优于SOTA，以更少的资源成本实现更高的负载预测准确度和更低的QoS违例。

PASS的整体架构如图2所示。ELPA（Ensemble Learning-based Prediction Algorithm）实时准确地预测业务负载的QPS时序数据。通过查询基于历史日志构建的性能模型，PASS在不违反QoS的前提下，预测伸缩到业务所需的实例数量。此外，PASS还持续监控QoS指标，如果发现由于预测不准导致的QoS违例，PASS会基于当前真实的延迟校正预测结果，并伸缩到适当数量的实例，以快速消除QoS违例。

3.1 ELPA预测模型

我们提出了ELPA（Ensemble Learning-based Prediction Algorithm）预测算法框架（如图3所示）。对于每一类业务的实时流量，ELPA采用一组相应的在线和离线模型来提供预测服务。我们首先从一系列不同的在线模型中选择一个能够为当前时间序列数据提供最准确预测的模型。然后，为了更好地预测“突变特征”，我们使用一个表现最好的离线预测模型代替在线模型。此外，我们使用振幅调整来改善离线预测时可能出现的“振幅偏差”问题，从而进一步增强预测性能。

3.2 性能模型设计

我们提出了基于日志的性能模型（Log-based Performance Model）。主要包括：性能模型构建与模型训练校准两部分。

性能模型构建：Algorithm1说明了如何基于历史日志（不需要对应用进行画像）构建性能模型。 我们从监控系统获取服务的日志，包括QPS、实例数、QoS指标等信息。 输入的QoS由服务设置，当QoS发生变化时需要重新建立性能模型。我们首先按实例数量聚合输入日志并遍历所有日志（第 1-9 行）。 第4行按照“cap”的粒度（例如最大QPS的千分之一）聚合QPS，以减少数据数量和算法开销。 第5-8行统计QoS违例的发生次数。由于系统故障等因素可能导致某些记录不准确，因此在评估某个QPS的保障率时，我们不仅计算当前的QPS记录，还综合考虑所有较低的QPS记录（第10-19行）。第20行的排序规则是优先考虑大于给定阈值𝛿的QoS保证率，然后按QPS降序排序。𝛿可以根据业务的需求进行调整（默认为0.99），衡量对QoS违例的容忍度。𝛿越接近1，容忍度越低。最后，我们将排序后的第一个QPS指定为当前实例数可以处理的最大流量（第21行）。

模型训练校准：直接根据监控日志构建的性能模型表可能不准确。当应用程序设置的弹性伸缩参数不合理时（例如水平扩容步长较大或资源冗余过多），可能会导致某些实例数没有监控日志，或者数据量极少。这可能会导致最初构建的表中条目丢失或不准确。 为了解决这个问题，我们首先保证原表数据保持非严格单调增长，空的或较低的QPS被之前较高的QPS替换。 然后，对于实例数量增加但QPS不变的部分，我们根据相邻QPS计算斜率并更新它们。 例如，初始化的性能模型映射为{5 : 30, 7 : 20, 8 : 60}，使用实例5的QPS替换实例6和7后，则变为{5 : 30,6 : 30,7 : 30,8 : 60}。 然后，根据实例5和8之间的QPS差异，我们更新实例6和7的QPS，得到{5 : 30,6 : 40,7 : 50,8 : 60}。 此外，我们在每天低峰时段使用最新的监控日志定期重建性能模型，以保持准确性。

3.3 Hybrid Auto-scaling方案设计

除了预测伸缩，我们还设计了基于排队论的响应式兜底策略，用于处理由于预测不准或热点事件负载突增导致的 QoS 违例。PASS 实时监控应用程序的性能指标。如果检测到QoS违例，PASS将根据 M/M/s排队论模型修改预测的QPS，并重新查询性能模型以快速扩容适当数量的实例。 具体而言，排队论模型如下公式所示：

𝑠表示当前实例的数量，𝑢代表每个实例的瓶颈QPS，𝑝表示延迟的百分比，以及𝑡指的𝑝百分位尾延迟。使用排队理论来估计QPS而不是延迟的原因是，从排队论推导出的延迟往往低于实际值（2.2节中排队论的QoS保障率偏低证明了这一点），因此从实际延迟推导出的QPS将高于实际值。我们基于更高的QPS进行扩容，以快速响应QoS违例并将损失降至最低。并且我们通过实验表明，这部分资源冗余并不会导致大量浪费。

4 测试结果

4.1 实验环境

应用选择：我们从美团的各个业务线中随机抽取了225个应用，以验证预测模型的准确性。这些应用的历史QPS数据是从美团内部的统一在线监控平台获得的。我们根据数据的预测难度将其分为三个不同的级别。其中，164个服务被定义为简单（具有单一波形模式，并表现出“单峰和多峰”特征），48个服务被定义为中等难度（具有单一波形模式，并表现出“尖峰”或“方形”特征），13个服务被定义为难（混合波形模式，例如“尖峰+方形”）。我们还选择了几个具有代表性的应用进行端到端评估。这些应用是后端服务，提供C端用户基本属性、用户行为查询、搜索和聊天功能。我们记录了在线请求流量，并在离线环境中回放，以恢复真实的在线环境。为了减少时间和资源成本，我们对记录的流量进行了切片，忽略了无法触发弹性伸缩的长期稳定的低峰值负载。

对比Baseline：我们比较了各种类型的SOTA预测算法和弹性伸缩方法。预测算法包括：离线算法（周期因子、Prophet）和在线算法（LSTNet、PatchTST和TIDE）。我们评估的在线算法旨在预测从当前时刻开始的第三个时间点的值（时间粒度为5min，也就是预测未来15min），即horizon等于3。这足以满足预测伸缩的要求，因为绝大多数的应用实例能够在15分钟以内完成启动。弹性伸缩方法包括：目标跟踪和AHPA。由于目标跟踪通常可以比具有相同参数的阈值法更快地扩展到目标范围（第2.2节也表明目标跟踪的性能更好），我们没有比较阈值法。其中AHPA是阿里巴巴基于排队论的SOTA预测弹性伸缩方法。

4.2 预测算法评估

结论1：ELPA预测框架结合了在线和离线模型的优势，在绝大多数场景中都取得最好的预测准确度。

（每一行和每一列分别比较所有方法在特定级别的数据集和特定指标上的结果。粗体突出显示每个指标的最佳结果；𝑀𝑒𝑡𝑟𝑖𝑐𝑠_𝑎𝑣𝑔表示当前难度级别数据集的平均预测结果，而𝑊𝑖𝑛𝑛𝑒𝑟显示了按数据集类型评估的方法在准确性方面优于其他方法的比例）

我们对ELPA以及其他五种广泛使用的预测算法进行了评估。表2显示了各种预测算法的准确度比较。ELPA明显优于单个预测算法，由于其实现了一组优化规则，用于选择最合适的在线/离线组合，并使用振幅校准来预测特定时间段的数据。

结论2：离线模型虽然擅长捕捉数据的“突变特征”，但其预测结果和真实值存在显著差异。而在线模型在有效预测这些“突变特征”方面面临挑战。通过两个模型的集成和振幅校准的应用，ELPA框架表现出显著的鲁棒性。

图4提供了ELPA的示例，其中结合了在离线预测模型，并对离线模型进行振幅调整。需要注意的是，“突变特征”可以在各种类型的业务流量中表现出来。由于篇幅限制，我们选择了一个具有代表性的业务负载数据集来突出ELPA的稳健预测能力。图4(a)比较了在线模型（PatchTST）的预测与真实数据。虽然在线模型在大多数情况下显示出很高的预测精度，但在预测“突变特征”时存在显著的滞后问题（黑色圆圈突出显示）。在图4(b)中，蓝色虚线代表离线模型（周期因子）的预测结果，尽管它在大多数情况下和真实值有一定的差距，但及时地预测出了“突变特征”。图4(b)中的红色虚线表示ELPA在离线模型的“突变特征”处的振幅校准结果。最后，图4(c)展示了ELPA的结果，它集成了在线模型和校准的离线模型，表现出准确的预测效果和预测“突变特征”的能力。

4.3 端到端效果评估

结论3：PASS的性能模型准确有效，在所有测试场景中都实现了最高的QoS保障率（表3）。 与目标跟踪和AHPA相比，平均QoS保障率分别提高了5.54%和7.71%。在多个QoS指标的场景6中表现更为明显，PASS的QoS保障率分别提高了19.21%和22.64%。PASS在所有场景中的平均资源成本也是最低的。 平均资源成本较AHPA降低8.91%，较目标跟踪降低17.02%。在场景4中降低了高达40%和52.76%。只有两个场景中PASS的资源成本略高于AHPA，而在所有其他测试中，PASS的资源成本都是最低的。

（每个场景中，第一列是QoS保障率，第二列是资源成本（实例数*小时）； 粗体突出显示每个指标的最佳结果）

我们从两个方面来评估弹性伸缩方法的效果。QoS保障率衡量了应用违反QoS的时间长度，其计算方法为QoS得到保证的持续时间与总时间长度的比值。资源成本通过计算实例数量和时间（以小时为单位）的积分得到。 端到端实验结果如表3所示（测试过程详细监控数据见图5和图6，包括QPS系列、实例数以及TP99、TP999时延等QoS指标）。每个测试场景提供了QoS指标、测试时长以及三种方法的QoS保障率和资源成本。

需要注意的是，应用实例启动时并没有进行预热（例如数据库连接初始化、缓存预测等），因此即使实例提前进行了扩容，初始大量的冷查询仍然会导致尾延迟突然增加。如果业务方在其实例启动逻辑中加入预热，我们的QoS保障率将会进一步提高。

5 经验总结

• 不同企业的应用场景可能各不相同，场景复杂程度也不一，在实际落地过程中，一些顶会算法不一定适用我们场景，这个时候就需要我们仔细甄别，取长补短，围绕自身场景特点进行算法的创新简化。
• 模型并不是越复杂性能越好，要结合预测的特征与场景来选择预测算法。
• 除了模型性能外，模型的可落地性也是非常重要的，比如LSTNet支持同时预测多项时间序列，面对大规模服务时能够极大的减少模型落地的开销。

6 合作方简介

中国人民大学柴云鹏教授团队致力于云计算、数据库等领域的系统研究和研发，近年团队在系统和数据库等领域的重要会议ASPLOS、SOSP、HPCA、SIGMOD、VLDB、ICDE、WWW等发表多篇高水平论文。在云计算领域，该团队针对资源隔离、资源分配、资源调度等核心问题，提出了一系列方法，可以提升各种复杂场景下的资源利用率，同时保障应用的服务质量，推动云计算技术的进步。团队高度重视科研工作的实用价值，积极推进与科技领域企业合作，针对企业面临的核心挑战，将创新性方法在实际系统中实现，推动研究成果的实际落地与应用，同时助力合作伙伴技术能力提升和商业价值实现。

| 关注「美团技术团队」微信公众号，在公众号菜单栏对话框回复【2024年货】、【2023年货】、【2023年货】、【2022年货】、【2021年货】、【2020年货】、【2019年货】、【2018年货】、【2017年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者使用。任何商用行为，请发送邮件至[e-mail]申请授权。