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

• 2.1 预测实验探索

• 2.2 伸缩方法分析

• 3.1 ELPA预测模型
• 3.2 性能模型设计
• 3.3 Hybrid Auto-scaling方案设计

• 4.1 实验环境
• 4.2 预测算法评估
• 4.3 端到端效果评估

1 背景

2 探索分析

| 2.1 预测实验探索

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

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

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

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

| 2.2 伸缩方法分析

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

| 3.1 ELPA预测模型

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

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方案设计

4 测试结果

| 4.1 实验环境

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

| 4.2 预测算法评估

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

结论2：离线模型虽然擅长捕捉数据的“突变特征”，但其预测结果和真实值存在显著差异。而在线模型在有效预测这些“突变特征”方面面临挑战。通过两个模型的集成和振幅校准的应用，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的资源成本都是最低的。

5 经验总结

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

|| 合作方简介 ||