弹性扩缩容器云 Auto-scaling containerized cloud applications: A workload-driven approach

Auto-scaling containerized cloud applications: A workload-driven approach

Personal Summary

该方法不在直接预测资源，首先 基于K-Means算法判断资源扩缩所处的那个阶段【高增长与高缩小，稳定增长与缩小，缓慢增长与缩小】，然后通过使用CNN来对时间序列做出预测,最后基于预测的结果来对资源做出调整。文章使用了间接的方法来做出预测，即先通过聚类方法判断扩缩的阶段，再通过另一个指标来做出扩缩，读者认为这种方法规避了直接预测时间序列延后性的问题。
本文是基于阈值来被动和主动结合做出调整

1. 被动方法 - 即达上升或者下降幅度到某个阈值$(upper/low)threshold$下触发调整策略，文章在调整策略上设置一个参数$Sv$z
2. 主动方法 - 通过CNN先做出时间序列的预测，得到预测曲线后，根据window length大小和预测的时间长度$prediction-size$将预测的序列分割为$ps/wl$段，通过YCSB之前做出的聚类模型我们使用动态时间扭曲算法DTW来计算出每段与聚类结果的距离，这样我们就可以将$ps/wl$小段的时间序列分别标识出不同的阶段，如$[hign,medium,low,high,low,....]$，然后通过使用扩缩参数 S v S_v Sv通过PACE模型做出放缩策略 过程如下图
   

Related Work

1. 基于阈值
2. 强化学习
3. 排队论
4. 控制论
5. 时间序列分析
6. 水平扩缩
7. 垂直扩缩

结论

基于阈值的扩展方法无法应对高突发性的工作负载，在指标强烈波动的突发性工作负荷行为下，基于阈值的方法的有效性是值得怀疑的。RL算法存在几个问题，包括在找到一个可接受的解决方案之前，需要很长的训练时间和糟糕的性能。排队理论模型的主要限制是，当应用环境发生变化时，它们需要重新计算

Method

在这项工作中，我们提出了PACE，一个能够实现容器化云应用垂直自动扩展的框架。PACE监测和分析资源使用指标，根据工作负载的需求，自动分配CPU和内存资源给容器。我们的解决方案实现了一种混合方法，包括反应式和主动式自动扩展技术。特别是，我们使用基于阈值的自动扩展规则来避免系统故障，并使用基于CNN和K-means算法的主动自动扩展技术来生成包含未来工作负载需求的弹性扩展策略。所提出的框架支持实时自动扩展，以确保在各种实际情况下的应用性能

PACE框架由一个支持反应式和主动式扩展技术的混合自动缩放器组成。因此，拟议的框架能够根据应用需求进行细粒度的资源配置。在这种情况下，PACE使用基于阈值的自动扩展规则，以防止系统达到饱和水平时出现系统故障，同时它还引入了一种基于机器学习的方法，根据未来的工作负载需求调整系统资源。因此，PACE根据阈值参数（下限或上限）、扩展参数和内存使用指标自动调整云资源。例如，如果上限值参数等于80%，缩放参数等于 ，每次内存使用百分比超过80%的值时，PACE就会为容器分配2GB的额外内存。必须提到的是，Linux cgroups已经被用来支持资源分配。虽然，各种资源使用指标可以通过简化的基于阈值的规则来处理，但为了确保其他资源（如vCPU核心）的可用性，更先进的技术是必要的。
在本文中，我们提出了一种混合机器学习方法，根据未来的工作负载需求来配置云资源。更详细地说，我们使用历史数据来训练K-means聚类算法，以便根据CPU利用率水平将时间序列划分为高、中、低需求集群。然后，使用动态时间扭曲arycenter Averaging（DBA）[43]方法计算每个集群的平均序列，并分别作为高、中、低需求组的代表序列。因此，目标应用程序被部署并基于CPU使用百分比指标进行监控。后者被用作CNN模型的输入，以预测未来的工作负载需求。然后，预测的序列被分割成基于时间窗口长度参数的小序列。动态时间扭曲算法（DTW）[44]被用来计算每个片段与高、中、低需求群组的三个代表性序列之间的距离。最后，每个片段都继承了最接近的代表序列的标签。
图3说明了PACE框架的主动自动扩展阶段。在第一阶段，主要的应用程序被基于CPU使用百分比指标进行监控。在第二阶段，CPU使用百分比被用作CNN模型的训练输入，该模型产生未来的预测。在第三阶段，预测的序列被分割成基于时间窗口长度参数的更小的序列，即…。最后，在第四阶段，根据从每个K-means聚类中提取的代表性序列，每个段被标记为高、中或低需求。鉴于预测的工作负载已被分割并标记为高、中或低需求，PACE框架创建一个扩展计划，根据应用需求自动调整容器的资源

C由5个元素组成，[1,2,3,4,5] 每个元素都定义了分配给Linux容器的vCPU核心。集合W由4个元素组成，每个元素都定义了YCSB工作负载的类型[A,B,C,D]。例如，(A,1)对包括在Redis容器中执行的YCSB工作负载A，有1个vCPU核心。表1显示了基于集合的笛卡尔积的数据集配置。 总共有20个配置被用来产生不同的CPU模式，同时Prometheus[45]监控引擎收集CPU利用率指标。必须提到的是，为了确保可重复性，每次运行都是由10次平均运行组成的。因此，我们运行20×10个实验，每个实验300秒，我们对结果进行平均，得到20个运行，每个配置一个。在这项工作中，PACE框架每15秒做一次缩放决定，因此每个300秒的运行被分割成20段，每段15秒。因此，我们形成了一个由400个序列组成的单变量时间序列数据集，用来训练K-means算法，将每个序列划分为高、中、低需求群组。然后，计算每个集群的平均序列，并将其作为一个群体的代表。

为了支持时间序列预测阶段，我们部署并监控我们的目标应用程序，其中包括部署在GCP中的Redis容器。然后，我们执行了YCSB的工作负载，以展示一个真实世界的案例场景。结果，形成了一个单变量时间序列数据集，其中有一列CPU利用率和每个值的时间步长作为隐含变量。该数据集作为CNN模型的输入，用于预测未来的事件，这些事件将根据从K-means聚类中提取的代表性序列被标记为高、中或低需求。

Reactive

PACE服务的弹性过程使反应式和主动式自动扩展技术得以实现，以确保云应用的QoS要求。反应式方法支持根据从运行系统中收集的监测数据按需分配资源。我们正在使用基于阈值的规则来触发基于应用内存使用百分比的扩展行动。因此，建议的框架考虑以下三个参数来启动反应式自动扩展：（i）上限值参数 UT，（ii）下限值参数LT和（iii）扩展参数Sv。PACE框架对监测到的数据进行即时分析，如果内存使用百分比超过上限值参数UT，则增加分配的内存资源。另一方面，如果内存使用百分比低于下限参数LT，PACE将减少分配的内存资源。在这种情况下，缩放参数Sv定义了PACE在每个缩放动作上分配或取消分配的内存量（单位：GB）。例如，如果下限参数被设置为25%（LT=0.25），缩放参数被设置为2（Sv=2），那么每次内存使用百分比下降到0.25%以下时，PACE框架将从运行的容器中减去2GB的内存。被动式技术的弹性过程如下。

1. 用户配置输入参数，包括上限值、下限值和规模参数。
2. PACE框架启动监控引擎，根据给定的搜刮时间间隔（如5秒）检索应用程序和资源使用指标。
3. Redis被部署在GCP上，同时YCSB工作负载被执行，以展示真实世界的应用范式。

最后，PACE对监测到的数据进行实时分析，并应用基于阈值的规则来触发扩展决策。

Proactive

虽然，基于阈值的规则在处理内存资源需求方面很有效，但需要更先进的技术来确保CPU资源的可用性。这是由于在YCSB工作负载运行阶段，CPU的使用比例波动很大。因此，一个反应式的方法会引入违反QoS的行为，因为它在应用程序已经达到饱和水平时触发了规模决定[46]。

尽管如此，我们引入了一种主动的自动扩展方法，以纳入未来的工作负载需求并满足应用需求。在聚类阶段，PACE使K-means算法根据CPU利用率指标将历史时间序列划分为高、中、低需求集群。因此，DBA方法被用作全局平均方法来计算每个集群的平均序列。这三个平均序列分别构成高、中、低需求集群的代表序列。

在预测阶段，CNN模型被用来预测基于预测步骤参数的未来工作负荷需求，即预测步骤数。然后，预测的序列根据时间窗口长度参数被分割成更小的序列，该参数定义了在PACE做出新的扩展决定之前的时间，单位为秒。DTW算法被用来计算每个片段与高、中、低需求集群的代表序列之间的距离。因此，每个段都继承了最接近的代表序列的标签。最后，部署管理器根据每个段的标签和缩放参数来调整容器的资源。主动式方法的弹性过程如下。

1. 用户配置输入参数，包括预测步骤参数 ，时间窗口长度参数和规模参数。
2. PACE框架启动监控引擎，检索应用和资源使用指标。
3. 历史数据用于训练K-means算法，该算法将时间序列聚类为高、中、低需求聚类。然后，DBA方法被用来计算每个集群的平均序列。这三个平均序列分别构成高、中、低需求类别的代表序列。
4. Redis被部署在GCP上，YCSB工作负载被执行，以强调运行系统。
5. CNN模型根据CPU使用百分比指标进行训练，并根据预测步骤参数产生未来预测。
6. 根据时间窗口长度参数，将预测的序列分割成更小的序列。
7. 每个片段都继承了基于DTW算法的最接近的代表序列的标签。
8. PACE创建一个缩放计划，包括每个片段的缩放决定。
9. 最后，PACE部署管理器将资源分配给正在运行的应用程序。

为了证明上述相互作用，我们提出了一个简单的例子，涉及到我们的主动自动缩放方法。例如，如果CNN模型预测了未来60秒的CPU利用率（Ps = 60），时间窗口长度参数为15秒，PACE框架将把预测分成4个序列（Ps/Wl）。然后，我们使用DBA方法计算每个片段与三个代表性序列(从高、中、低需求集群中提取的)之间的DTW距离。因此，每个序列将被标记为高、中或低需求，其值将被储存在一个数组中，即。Sr = [High,Medium,Medium,Low]，然后，PACE将产生一个扩展计划，称为Sp，在接下来的60秒内，如Sp = [Vc Sv , Vc，Vc , Vc-Sv] 其中Vc代表vCPU核心的初始数量，Sv代表扩展参数，指定将从运行的容器中增加或减少的vCPU核心数量。这个例子表明，应用程序应该在第一段[高]时增加初始资源[Vc Sv]，在接下来的两段[中，中]时返回到初始的vCPU核心数量（Vc,Vc），在最后一段[低]时减少资源（Vc-Sv）

Evaluation

Reactive Proactive

PACE框架实现了一种反应式自动扩展方法，以自动调整虚拟资源，确保QoS要求。如激励实验所示，内存使用指标对于确保系统的可持续性和避免应用程序达到饱和水平时的系统故障至关重要。为了解决这个问题，PACE启用了一个基于阈值的扩展规则，在内存超过预定的阈值时，即时扩展分配的资源。

为了评估和证明PACE的有效性，在GCP中部署了一个中等规模的虚拟机，有16个vCPU内核，64GB内存和350GB硬盘。然后，Redis NoSQL数据库被部署在一个docker容器中。首先，我们为容器分配了2个vCPU核心（0和1）和32GB内存。此外，我们使用YCSB Redis workload-a作为应用实例，用于记录用户会话中最近的操作的会话存储[47]。我们将记录和操作数设置为5,000,000，分别有50%的读取和50%的更新操作。此外，我们将上限值参数UT设置为80%，缩放参数Sv设置为2，这意味着每次内存使用百分比超过80%时，PACE框架会自动为容器分配两个额外的GB内存。图4显示了我们在Redis中执行YCSB工作负载时，左轴上的内存使用百分比和右轴上的分配内存（GB）。

为了进一步评估PACE框架，我们在YCSB工作负载执行期间监测Redis的应用性能。图5显示了在与图4相同的时间间隔内，Redis每秒执行的操作。如图5所示，在负载阶段，每秒操作数在8,428和13,477之间波动。图5表明，在整个实验过程中，应用程序的性能没有受到影响，而执行的操作仍然在8,000以上。

在这里，我们展示了PACE框架基于基于阈值的扩展规则自动扩展容器化应用程序的能力。在这个实验中，我们表明反应式方法是理想的，可以防止应用程序达到饱和水平，从而导致系统故障和违反QoS。

在这个实验中，我们展示了PACE框架在主动式自动扩展技术之后的有效性。如前所述，PACE框架使用K-means将时间序列分为高、中、低需求类别。基于不同的系统和工作负载配置，产生了一个用于工作负载表征的历史数据集。后者被用来训练K-means算法，其预定值为 ，即聚类的数量。如图6所示，K-means算法根据CPU的利用水平将时间序列数据分为高、中、低需求集群。每个时间序列由15秒内的15个时间段组成。

DBA平均法已被用于K-means学习算法，该算法产生的类内惯性为0.053。图6显示了红色的平均集群序列，分别作为高、中、低需求集群的代表序列。高需求集群的代表序列在88%和98%之间波动，表明CPU资源被过度利用。另一方面，中等需求集群的代表序列既没有利用不足也没有过度利用资源，其数值分别在45%和53%之间。最后，低需求集群的代表序列的数值在18%和31%之间，表明运行的系统没有得到充分利用。在这种情况下，PACE框架使用K-means来自动描述基于平均CPU利用率水平的未来工作负载需求，无需用户干预。

为了进一步支持我们的方法，我们在GCP中部署了一个中等规模的虚拟机，有16个vCPU内核，64GB内存和350GB硬盘。然后，Redis被部署到一个名为redis-main的docker容器中，作为我们的主应用程序，可以使用两个vCPU核心（0和1）和16GB的内存。此外，为了进一步强调我们的主应用程序，我们构建了一个多租户的云环境，其中应用程序并行执行工作负载，并在同一时间段请求相同数量的资源。我们部署了三个额外的Redis容器，分别为redis-2、redis-3和redis-4。然后，我们加载YCSB workload-c作为用户配置文件缓存的实际应用例子，其中配置文件是在其他地方构建的，如[47]中讨论的。我们将记录和操作数设置为3,000,000，100%的读操作，我们将这种类型的工作负载执行到redis-main。同样地，我们将有500,000条记录的YCSB Redis工作负载-c分别加载到redis-2、redis-3和redis-4。

为了展示过度使用的多租户环境，我们在Redis-main上执行YCSB工作负载，15秒后我们并行执行YCSB工作负载edis-2、redis-3和redis-4。图7显示了9个YCSB工作负载执行期间的CPU使用百分比。当edis-2、redis-3和redis-4保持空闲时，CPU的使用百分比在40%和60%之间波动。相反，一旦我们对edis-2、redis-3和redis-4执行YCSB工作负载，CPU使用百分比达到100%的饱和水平。这种模式在整个实验中不断重复。

为了支持积极主动的方法，PACE框架使用历史数据作为输入来训练CNN模型，产生CPU使用率预测（绿色虚线），如图7所示。我们显示了用于提取预测小波的9个（共20个）训练小波，而我们在训练数据和测试数据中的RMSE分数分别为0.0554和0.0651。

为了进一步证明我们的方法，我们展示了图8，该图说明了CNN的CPU使用率预测（绿色虚线），分配的vCPU核心（红线）和PACE缩放决策期间的CPU使用率比例（蓝线）。在底部，绿色和红色的柱子说明了PACE的扩展决策。在这个实验中，决策时间窗口被设置为15秒，缩放参数Sv为4。因此，PACE框架对预测序列进行分割，每15秒做出一次缩放决策。

更详细地说，绿色条显示，在给定的时间窗口中，PACE框架将预测的CPU使用百分比聚类为中等需求，因此PACE分配了2个vCPU核心给Redis-Main容器。另一方面，红色条表示PACE框架将预测的CPU使用比例聚类为高需求，因此PACE为Redis-Main容器分配了4个额外的vCPU核，从而在该时间段内有6个vCPU核。 如图8所示，PACE框架成功地降低了946到976秒之间的CPU使用率，在这段时间里，预测的CPU使用率已经达到了最高。必须提到的是，CPU使用百分比包括分配给容器的核心的平均CPU使用量

此外，为了确保应用程序的性能，我们监测并收集了在YCSB工作负载执行期间Redis-Main容器中每秒执行的操作。图9显示了Redis-Main容器在与图7相同时间段内的每秒操作数。更详细地说，图9红色阴影区域显示，当Redis-2、Redis-3和Redis-4容器并行执行YCSB工作负载时，容器的性能明显下降。然而，PACE的主动性方法确保了4个额外的vCPU核心被分配给Redis-main容器，以纳入未来的工作负载需求。因此，在超载期间，redis-mai执行的平均每秒操作数从9,173次增加到14,850次。

PACE框架实现了反应式和主动式的扩展技术，以确保不同场景下的高应用性能。在这些实验中，我们引入了一个基于阈值的扩展规则，以保证应用程序的性能，避免系统故障。此外，一种基于时间序列预测和聚类的混合技术在多租户云环境的并发工作负载执行下实现了自动扩展。PACE在两个实验中都保持了应用性能，并保证了QoS要求

Conclusions

在这项工作中，我们提出了PACE，一个在容器化云环境中实现反应式和主动式自动扩展的框架。PACE使用基于阈值的扩展规则，以避免在密集的工作负载任务中出现应用故障。此外，PACE引入了一种主动的自动扩展方法，使用CNN进行时间序列预测和K-means进行时间序列聚类。因此，PACE将未来的序列聚类为高、中、低需求类别，并生成包含未来工作负载需求的弹性扩展策略。实验分析表明，我们的方法在单租户和多租户的云环境中都能确保系统的可持续性和应用性能。我们相信，我们的框架构成了自适应自动扩展方法的基础，确保了云应用的QoS要求。

Reference

Spyridon Chouliaras, Stelios Sotiriadis,Auto-scaling containerized cloud applications: A workload-drivenapproach

这篇好文章是转载于：学新通技术网