论文阅读-一个用于云计算中自我优化的通用工作负载预测框架，

论文标题：A Self-Optimized Generic Workload Prediction Framework for Cloud Computing

概述

准确地预测未来的工作负载，如作业到达率和用户请求率，对于云计算中的资源管理和弹性非常关键。然而，设计一个通用的工作负载预测器，并使其适用于各种类型的工作负载，具有很大的挑战性，因为工作负载的种类繁多且随着时间动态变化。由于这些挑战，现有的工作负载预测器通常是手动调优的，以便在最大程度上提高精度，针对特定（类型的）工作负载。这种需要个体调整预测器的必要性，也使得从先前研究中复现结果变得非常困难，因为预测器的设计与工作负载之间存在强烈的依赖关系。

在本论文中，我们提出了一种新颖的通用工作负载预测框架LoadDynamics，它可以为任何工作负载提供高精度的预测。 LoadDynamics采用了Long-Short-Term-Memory模型，并可以自动优化其内部参数，以实现高精度的个体工作负载预测。我们使用表示公共云应用程序、科学应用程序、数据中心作业和Web应用程序的混合工作负载跟踪来评估LoadDynamics。评估结果显示，LoadDynamics的平均预测误差仅为18％，至少比最先进的工作负载预测技术低6.7％。在每种工作负载中，LoadDynamics的误差也仅比通过穷举搜索找到的最佳预测器高1％。当应用于Google Cloud时，启用了LoadDynamics的自动缩放策略通过将作业周转时间至少减少24.6％和将虚拟机过度配置至少减少4.8％而优于先进的预测器。

关键词-云计算； 工作负载预测； 长短期记忆； 自我优化框架； 资源管理；

I. 引言

准确预测未来的工作负载，例如在下一个时间间隔内到达的作业或用户请求的数量，长期以来一直被认为是有效弹性伸缩（它使得云基础设施能够根据负载的变化自动调整资源）的主要要求[1] - [3]。通过准确的工作负载预测，用户或云服务提供商可以设计更好的自动缩放策略或虚拟机调度管理器，提前适当地配置虚拟机（VM）或容器，以避免资源过度或不足配置，以及资源冷启动[4]，[5]所带来的负面性能影响，这可能导致服务级别协议（SLA）违规或过高的云使用成本。

然而，由于工作负载模式（例如周期性、突发性或增长）在不同作业类型之间存在大量变化[6]，因此准确的工作负载预测是一个具有挑战性的问题。图1显示了来自Google数据中心[7]，Facebook数据中心[8]和维基百科[9]的作业工作负载跟踪。如图1所示，不同云应用程序之间的工作负载模式差异很大。例如，维基百科的工作负载表明存在强烈的季节性，而其他工作负载则没有明显的周期性。此外，工作负载内的模式也可能随时间而变化，如Google工作负载前半部分的高峰和Facebook工作负载的高波动所示。工作负载模式的多样性要求工作负载预测器针对每个工作负载进行调整和优化，以确保高准确性。工作负载内的变更要求预测器足够复杂，能够识别并准确预测一个工作负载内的各种模式。

通常，没有统计、时间序列和机器学习方面专业知识的普通云用户很可能难以为自己的工作负载设计出如此复杂的预测器[10]。理想情况下，应该提供一种通用的工作负载预测框架（例如由云服务提供商提供），可以为各种动态工作负载生成准确的预测器，以帮助普通云用户最大程度地利用自动缩放的好处。

之前的研究中的工作负载预测器通常是针对特定工作负载或特定类型的工作负载开发的[11] - [16]。这些预测器没有被设计成通用的，通常在应用于其他工作负载时预测精度较低。此外，需要针对每个（类型的）工作负载手动调整预测器的必要性，还使得很难复现以前研究所呈现的预测结果。我们之前也探索了通用的工作负载预测框架[3]，但是这个先前的框架的准确性仍有提高的空间。

在这篇论文中，我们提出了一个名为LoadDynamics的通用工作负载预测框架，可以为各种动态工作负载生成高精度的工作负载预测器。LoadDynamics采用了机器学习模型——长短期记忆（LSTM）[17]来进行预测。然而，机器学习模型无法自动为任何工作负载生成准确的预测器，除非进行适当的超参数调整，例如调整模型的层数。为了解决这个问题并提高对个体工作负载的预测准确性，LoadDynamics还通过使用贝叶斯优化来自动优化为每个工作负载训练的模型的超参数。通过这种自我优化，LoadDynamics能够生成针对个体工作负载进行优化的高精度预测器。此外，与普通的前馈神经网络和许多其他机器学习技术不同，LSTM模型能够追踪数据中相对较长的依赖关系，使其有可能在仔细选择超参数的情况下检测和预测工作负载中的各种模式[18]，[19]。

我们将LoadDynamics应用于云中四种不同类型的工作负载的14种工作负载配置。使用LoadDynamics的工作负载的平均预测误差为18％，表明LoadDynamics可以为具有动态变化的各种类型的工作负载提供高精度的预测。与三种最先进的工作负载预测器相比，LoadDynamics的预测误差分别减小了6.7％，14.1％和14.5％。为了证明LoadDynamics的更高准确性确实可以改善自动扩展，我们还在Google Cloud上使用LoadDynamics实现了一种预测性自动扩展策略。实验结果显示，与两种最先进的预测器相比，使用LoadDynamics的自动扩展将云应用程序的平均完成时间减少了24.6％和38.1％。LoadDynamics还可以通过减少虚拟机过度配置来提高云资源效率，减少了4.8％和17.2％。

本文的贡献包括：

• 1）设计了LoadDynamics，一个工作负载预测框架，能够自动优化其预测器以为个体工作负载提供高准确性的预测，相对于最先进的工作负载预测技术，LoadDynamics提供了显著更高的准确性。
• 2）对14种具有不同模式和应用类型的工作负载配置进行全面评估，以证明LoadDynamics确实可以为具有动态变化的各种工作负载提供高精度的预测。
• 3）通过案例研究证明了LoadDynamics的高精度预测可以进一步提高实际公共云上自动扩展的效果。

本文的其余部分组织如下：第二节正式定义了工作负载预测问题；第三节详细介绍了LoadDynamics的设计，包括其LSTM模型、超参数优化和工作流程；第四节给出了LoadDynamics的实验评估；第五节讨论了限制和未来工作；第六节讨论了相关工作；第七节总结了本文。

II. 问题定义与动机

A. 问题定义

对于典型的执行机器学习训练/推断作业、高性能计算应用程序和提供网络请求的云系统，一系列作业或请求在不同时刻到达。这些作业或请求可以被划分为时间间隔，并用每个时间间隔中到达的作业或请求数量来描述。例如，图1a中显示的Google工作负载被划分为30分钟的时间间隔。在第一个30分钟的时间间隔内，有814k个作业。在第二和第三个时间间隔内，分别有757k和791k个作业。图1b中的Wikipedia工作负载也被划分为30分钟的时间间隔，前三个时间间隔分别有5.4、5.2和4.9百万个用户请求。

假设在某个时间间隔，用户希望提前为下一个时间间隔到达的作业/请求分配虚拟机（VM）。对于用户来说，最好的选择是分配恰好能够容纳下一个时间间隔的作业/请求的VM。分配过少的VM（欠配置）会导致在作业/请求已经到达后需要按需创建额外的VM，可能违反性能目标。分配过多的VM（过配置）会导致部分VM闲置运行，浪费金钱。为了分配正确数量的VM，用户需要知道下一个时间间隔中将到达的作业/请求数量。

本文解决的问题是预测下一个时间间隔中将到达的作业/请求数量。在本文的其余部分，我们定义第i个时间间隔的作业到达率（JAR）为该时间间隔内到达的作业/请求数量。不失一般性，假设在第（i-1）个时间间隔，当前和前一个时间间隔的JAR已知，并且要预测第i个时间间隔的JAR。为了确保我们的预测框架适用于各种类型的工作负载，第i个时间间隔的JAR仅基于前n个时间间隔的JAR进行预测。设Ji−1 ... Ji−n表示从（i-1）个时间间隔到（i-n）个时间间隔的实际JAR。设Pi表示第i个时间间隔的预测JAR。则Pi的预测问题可以表示为：

其中f是一个预测模型，n是在预测中使用的过去JAR的数量。LoadDynamics的主要任务是确定每个工作负载的这个函数f。需要注意的是，这里做出的一个隐含假设是Ji与前n个JAR相关并依赖于它们，这对于真实工作负载通常是正确的[20]。然而，确切的前几个JAR的数量（即n的值）与Ji的相关性是特定于工作负载的。因此，还需要确定n的值。

B. 研究目的

图2显示了使用先前研究基于三种不同预测方法（CloudInsight [3]、CloudScale [1]和Wood等人的预测器[2]）对图1中的三种工作负载进行的预测误差（MAPE，在第四节定义）。这些预测方法按照原始作者的建议实现了配置。需要注意的是，CloudInsight是一个集成预测器，它从一组预测模型（如随机森林、ARIMA和SVR）中选择最佳预测器。因此，CloudInsight代表了过去使用这些模型的研究中最好的预测准确性。

正如图中所示，这些现有的预测方法都无法始终对所有工作负载实现低于50％的误差。其中一些预测方法是针对具有明显季节性趋势的Web工作负载设计的。因此，对于非季节性数据中心工作负载，它们的准确性较低。这种高误差通常会导致严重的资源欠配置和过配置问题。这些误差也表明有改进预测准确性的空间和必要性。

III. LoadDynamics的设计

A. LSTM和超参数优化

工作负载中的模式通常可以通过连续时间间隔的JAR中的长期和短期趋势/依赖关系来表示。例如，工作负载的长期趋势（JAR依赖性）可能是每天作业数量持续增长，而短期趋势（JAR依赖性）可能表明作业数量根据一天中的时间波动。然而，云工作负载经常产生复杂的非线性依赖关系，传统的时间序列预测模型（如ARIMA及其变种）可能无法捕捉到这些趋势/依赖关系[21]。为了捕捉这些趋势/依赖关系，我们提出使用长短期记忆（LSTM）网络，因为它被设计用于有效地学习长期依赖关系[17]。

图3显示了LSTM如何预测第i个时间间隔的JAR，即Pi。M代表训练好的LSTM单元。C是作为时间状态信息的长期记忆的细胞记忆。h是从先前的LSTM单元（M）输出的隐藏状态。给定长度为n的输入序列Ji−n,...,Ji−1，LSTM网络递归地更新值以获得Ci−2和hi−2。最后，将丢失的输出hi−1馈送到全连接层T以产生最终输出Pi。

C和h都由LSTM单元（M）的内部操作确定，如图4所示。

设t为LSTM网络中时间间隔的一般形式，t ∈ {i − n, i − n + 1,...,i − 1}。M中的四个门（it，ft，ot和gt）通过调节信息在网络中的流动量计算Ct和ht的值。在时间间隔t，网络以Jt、ht−1和Ct−1作为输入，并按以下方式更新内存和门的值：

其中，符号表示两个矩阵的Hadamard乘积，σ是sigmoid函数，Wa、Ua和ba分别表示门的权重和偏置。输入门it确定从输入中写入细胞记忆的新信息量，遗忘门ft允许网络擦除过去的信息Ct−1。输出门ot控制从Ct输出的信息量。通过增加更多的LSTM层或增加LSTM单元（即记忆细胞Ct的大小）来控制LSTM网络学习依赖关系的能力。这种控制意味着LSTM网络的准确性取决于其超参数值的正确选择，如LSTM层数、Ct的大小和历史长度（输入序列的长度n）。

然而，找到一组好的超参数是一个非常复杂的任务[10]。例如，当历史长度n太小时，模型很难学习跨越较长时间的依赖关系。另一方面，当n太大时，模型可能会学习到不相关的依赖关系，并遭受爆炸/消失梯度问题[22]，导致预测准确性差并产生高计算开销。类似的问题也存在于细胞记忆C的大小（单元数量）和LSTM层数。细胞记忆由长度为s的向量C ∈ Rs表示。如果C向量的大小and/or层数太大，会增加LSTM模型的复杂性。复杂模型通常需要更大的训练数据集，但在实践中可能无法收集到。增加的模型复杂性还可能导致过拟合的风险增加，即训练的LSTM模型可能与训练数据过度拟合，失去了可靠预测未来数据的能力，而这些数据不一定与训练数据非常相似。增加的模型复杂性还可能导致更高的计算成本。另一方面，如果C向量的大小和/或层数太小，LSTM模型所表示的预测器类可能无法捕捉数据中的复杂时间依赖关系，导致预测准确性差[23]，[24]。除了历史长度、细胞记忆向量大小和层数之外，第四个超参数也可能显著影响训练的LSTM模型的准确性，这就是训练数据批次的大小。尽管批次大小不像其他三个超参数那样影响LSTM模型的内部结构，但它可能会影响训练过程的有效性，从而影响训练模型的准确性[10]。因此，我们在LoadDynamics中将批次大小也视为超参数。

超参数n（历史长度）、s（C向量的大小）、批次大小和层数的适当值取决于工作负载，并且需要在训练M之前确定。图5比较了对Google工作负载（图1a）上进行了100个不同LSTM模型的预测误差（MAPE），其中x轴上的值对应不同的超参数组合。结果表明，选择更好的超参数组合可以将预测误差减少三倍。不幸的是，鉴于各种工作负载及其动态变化的多样性，手动选择每个工作负载的最佳超参数是不可行的。由于组合数量的组合爆炸，穷举搜索最佳超参数也是不切实际的。

为了解决这个挑战，我们使用贝叶斯优化来智能地搜索每个工作负载和/或工作负载的一部分的更好的超参数集[25]。贝叶斯优化（BO）通过一种称为高斯过程（GP）的非线性回归技术来搜索更好的超参数[26]。BO是一个迭代的优化过程。在每次迭代中，BO使用已经探索过的超参数集和使用这些超参数构建的LSTM模型的准确性来建立一个带有GP的回归模型。然后，使用回归模型预测一组新的可能更好的超参数。这组新的超参数用于训练一个新的LSTM模型，并使用交叉验证数据集评估其准确性。经过固定次数的迭代，从这些迭代中找到的最佳LSTM模型被选择为预测器。

除了BO，先前的工作还提出了其他优化技术来优化超参数。特别是，我们还尝试了随机搜索和网格搜索[27]，[28]。然而，在我们的实验中，网格搜索在改善超参数方面效果不如BO。随机搜索可以找到与BO确定的超参数具有相似准确性的超参数。然而，根据我们的经验，随机搜索通常需要更长的执行时间。因此，LoadDynamics只采用了BO。

B. LoadDynamics的工作流程

LoadDynamics的一般工作流程由三个阶段组成：（i）模型训练，（ii）超参数优化，（iii）预测阶段。

对应于这三个阶段，工作负载中的过去和未来JARs（Java Archive？表示工作负载）包括三个部分：（a）用于训练模型M和T的l个样本的训练数据集，（b）用于超参数优化的m个样本的交叉验证数据集，（c）JAR的预测。前两个部分（a和b）来自过去（已知）的JARs，第三个部分（c）用于未来（未知）的JARs。图6显示了LoadDynamics的整体工作流程。请注意，图6中带有数字的每个矩形表示LoadDynamics中的一个内部步骤。图7显示了工作负载JARs的这三个部分。

如图6所示，训练阶段从随机选择的一组超参数开始。这组超参数用于配置初始LSTM模型，然后使用训练数据集进行训练（步骤1）。训练后，生成一个新的LSTM模型A。该模型A包括一个新的LSTM模型M和一个全连接层T，如图3所示。在步骤2中，使用模型A对交叉验证集中的JARs进行验证。对于所有Ji−1 ...Ji−m的JARs，使用A生成相应的预测Pi−1 ...Pi−m。然后将预测的JARs与实际JARs进行比较，计算A的平均预测误差。在验证完成后，将A及其预测误差存储在数据库中。对于步骤3，还使用A的超参数和误差来使用贝叶斯优化从预定义的可能超参数搜索空间中选择一组新的、可能更准确的超参数。然后，使用新的超参数配置和训练一个新的LSTM模型（步骤1）。这个训练和优化过程将重复maxIters次。在这些迭代之后，将比较所有经过验证的模型，并选择具有最低误差的模型M作为实际的工作负载预测器f（步骤4）。然后，将该预测器f用于预测未来的JARs（步骤5）。

IV. 评估

本节提供了LoadDynamics的实验评估。这些评估主要关注LoadDynamics的准确性，以及其对自动扩展的好处。

A. 实验设置

工作负载。使用了来自四个类别的五个工作负载来评估LoadDynamics。这些工作负载包括：1）来自Wikibench [9]的维基百科（Web应用程序）工作负载；2）来自Grid Workload Archive [29]的高性能计算（HPC）工作负载；3）来自Microsoft Azure [30]的公共云工作负载；4）来自Google [7]的数据中心工作负载；以及5）来自Facebook [8]的数据中心工作负载。Google、Facebook和维基百科工作负载的迹线如图1所示，Azure和LCG工作负载的迹线如图8所示。这些工作负载的特征总结在表I中。

为了评估LoadDynamics在不同的时间粒度（可能具有不同的工作负载模式）下是否正常工作，这些工作负载被评估了不同的间隔长度。对于维基百科、Google和LCG工作负载，间隔分别为5、10和30分钟。对于Azure工作负载，由于5分钟间隔下的JAR文件非常小，因此评估间隔为10、30和60分钟。Facebook工作负载相对较短（仅覆盖一天）。为了提供足够的训练样本，Facebook工作负载只评估了5和10分钟的间隔。总体而言，使用了14种不同的工作负载和间隔组合来评估LoadDynamics。在本文的其余部分，我们将具有特定间隔的工作负载称为工作负载配置。

度量标准。预测误差定义为每个预测的绝对百分比误差。对于每个工作负载配置，报告所有预测误差的平均绝对百分比误差（MAPE）。MAPE的计算公式为。

基线。为了比较，我们还报告了来自三种最先进的工作负载预测器的预测误差，包括CloudInsight [3]、CloudScale [1]和Wood等人[2]。CloudInsight是一个集合模型，它从21个预测器池中动态选择最佳预测器，每个预测器都采用不同的建模技术。其中许多技术被之前的工作在工作负载预测中使用过，例如[13]、[15]、[16]、[31]、[32]。所有这21个预测器都列在表II中。CloudInsight还在每隔五个间隔后动态重建其预测器。CloudScale基于快速傅里叶变换（FFT）和离散时间马尔可夫链。它使用FFT检测工作负载中的重复模式，然后将检测到的模式与马尔可夫链一起用于预测工作负载。Wood等人采用鲁棒线性回归来预测工作负载。用线性回归构建的模型在线进行改进以适应变化。

实现。LoadDynamics使用了Tensorflow 1、Scikit-learn 2和GpyOpt 3进行实现。LoadDynamics的训练和推断是在一台16核Intel Xeon Platinum 8153 CPU上执行的。对于LSTM模型的训练，我们使用“均方误差”作为损失函数，Adam优化算法 [33]作为优化器。对于贝叶斯优化，使用了高斯过程 [26]作为概率模型进行回归，使用“期望改进” [34]作为获取函数选择下一组要检查/验证的超参数。

训练集（l）和交叉验证集（m）的大小定义如下。每个工作负载的前60% JAR被设置为训练集，接下来的20%用作交叉验证集，最后的20%用于测试LoadDynamics的准确性。

使用贝叶斯优化搜索更准确的超参数需要定义搜索空间。这个搜索空间表示潜在超参数值的范围，包括历史长度（即n的值）、C向量大小、LSTM层数和批量大小的范围，如第III节所讨论的。表III给出了每个超参数的潜在值范围。除了Facebook工作负载外，其他四个工作负载使用了相同的范围。选择这些范围是因为它们足够大，以涵盖潜在更准确的超参数值。正如后面的评估结果所示，LoadDynamics选择的最佳超参数通常小于范围的最大值。因此，即使对于本文未评估的工作负载，这些范围也可能足够大。对于Facebook工作负载，由于其较短，因此无法支持较大的历史长度，因此其历史长度和C向量大小的范围被缩小以与训练数据大小兼容。除了搜索空间，使用贝叶斯优化还需要定义优化迭代次数（即maxIters图6）。这个迭代次数表示将使用BO生成的超参数集的数量。生成的集合越多，找到高准确性集合的机会就越大，但是更多的迭代也需要更多的执行时间。在我们实现的LoadDynamics中，对所有的工作负载迭代计数设置为100。

B. LoadDynamics准确性评估

如前所述，通过LoadDynamics获得的每个工作负载的工作负载预测器然后在该工作负载的最后20% JAR上进行测试，以进行准确性评估。在图9中报告了LoadDynamics针对每个工作负载配置的最后20%测试数据的MAPE。为了比较，图9还包括了来自之前工作的基线预测器的MAPE。图9还包括了每个工作负载的最佳LSTM预测器的MAPE（标有“LSTMBruteForce”的条形）。最佳LSTM预测器是通过在超参数优化空间中进行穷举搜索（类似于表III中所示的搜索空间）获得的。一个工作负载的一次穷举搜索可能需要长达6周的时间。意思就是找到了最好的超参数，但是需要花费很长时间。

如图9所示，LoadDynamics可以为评估的工作负载配置提供高度准确的预测。当预测三个维基百科配置时，LoadDynamics的最低MAPE仅为1%。除了间隔为10分钟的Azure，LoadDynamics的MAPE始终低于CloudScale和Wood等人的预测器的MAPE。除了间隔为10分钟的Azure，LoadDynamics的MAPE也要么低于CloudInsight的预测误差，要么与其相似。平均而言，LoadDynamics的MAPE比CloudInsight低约6.7%，比CloudScale低约14.1%，比Wood等人的预测器低约14.5%。CloudScale和Wood等人的预测器采用的是不太能跟踪复杂工作负载模式/依赖关系的预测方法，导致误差较高。CloudInsight采用多种预测技术来处理各种模式。然而，CloudInsight中的这些预测技术也受到其超参数的很大影响。由于CloudInsight使用固定的超参数，如果这些固定的超参数不适合当前的工作负载，其准确性会受到负面影响。此外，LoadDynamics的平均MAPE仅比穷举搜索的预测器的平均MAPE高1%，这表明我们的超参数优化方法能够确定出几乎最佳的超参数。这种接近最佳的准确性也是以更低的成本获得的。与穷举搜索需要1天至6周的搜索时间相比，LoadDynamics在每个工作负载配置上最多只花费了三个小时。值得注意的是，使用LoadDynamics的模型进行推断所需的时间要小得多，不到4.78毫秒。

总体而言，除了一些5分钟或10分钟间隔的情况外，大多数LoadDynamics的MAPE都小于30%。所有14种工作负载配置的平均MAPE仅为18%。这些低误差表明，LoadDynamics确实能够对各种类型的工作负载进行高精度预测。此外，如图1和图8所示，Google、Facebook、Azure和LCG工作负载都具有模式变化。即使在这些模式变化下，LoadDynamics仍然能够提供高精度的预测，表明LoadDynamics的设计使其能够检测和预测一个工作负载中的多个模式。

LoadDynamics最高的MAPE是43%，用于预测5分钟间隔的Facebook工作负载和10分钟间隔的Azure工作负载（这两个工作负载配置的LoadDynamics都有43%的误差）。这种高误差主要是由于每个5分钟或10分钟间隔的相对较低的JAR造成的。总的来说，我们观察到LoadDynamics的MAPE在时间间隔更小的情况下更高，例如Facebook、LCG和Azure工作负载。对于这些工作负载，较小的时间间隔通常具有较小的JAR。这些较小的JAR更容易受到随机突发性的影响，使其更难以预测（随机波动通常缺乏可追踪的模式/依赖关系）。对于较大的工作负载，例如Google和Wikipedia，即使在小间隔下进行预测，其JAR仍然相当大。因此，即使使用LoadDynamics在小间隔下进行预测，它们的预测误差仍然很低。

表IV给出了LoadDynamics选择的超参数的值（通过BO进行选择）。由于空间限制，我们无法提供每个工作负载配置的选择的超参数。相反，报告了所有间隔的最小值和最大值。正如表IV所示，所选的超参数值具有非常高的变异性，这表明如果要手动确定超参数，则可能非常具有挑战性和耗时。因此，LoadDynamics提供的自动超参数优化过程对于构建准确和通用的工作负载预测技术是不可或缺的。这种高变异性还表明有必要为每个工作负载单独优化LSTM模型。此外，对于大多数工作负载配置，所选的超参数值通常低于搜索空间的最大值，这表明搜索空间很可能足够大。

C. 使用自动伸缩评估LoadDynamics

为了证明 LoadDynamics 带来的更高准确性确实可以提高云系统的性能和资源效率，我们将 LoadDynamics 应用于管理在 Google Cloud 中执行的 VM 的自动扩展策略。为简单起见，在这个自动扩展评估中，我们假设所有作业都在一个时间间隔的开始时到达。该自动扩展策略的算法描述如下：

在每个时间间隔，预测下一个时间间隔的作业到达率（JAR）。不失一般性，假设下一个时间间隔是第 i 个时间间隔，Pi 在第（i-1）个时间间隔进行预测。在预测之后，预先在第（i-1）个时间间隔创建 Pi 个 VM，预期 Pi 个作业将在第 i 个时间间隔到达。在第 i 个时间间隔的开始时，到达的作业被发送到创建的 VM 中执行，每个作业一个 VM。如果第 i 个时间间隔到达的作业数大于 Pi（即 Ji> Pi），则发生了 VM 配置不足，需要按需创建更多的 VM 来容纳额外的作业。在 VM 配置不足的情况下，由于 VM 有启动时间，额外的作业需要额外的时间完成。如果第 i 个时间间隔到达的作业数少于 Pi（即 Ji < Pi），则发生了 VM 过度配置，多余的 VM 将空闲运行。在 VM 过度配置的情况下，额外的 VM 会产生不必要的成本。

在这个自动扩展评估中，由于财务限制，我们使用了 Google Cloud 的 n1-standard-1 VM。由于同样的成本问题，只评估了工作负载和预测技术的子集。对于工作负载，仅评估了 Azure 工作负载，时间间隔为 60 分钟。此外，为了符合 Google Cloud 的资源配额并确保合理的实验成本，Azure 工作负载的 JAR 被缩小了 100 倍，以使每个时间间隔到达的作业数少于 50（即每个时间间隔需要创建的 VM 数量少于 50）。我们验证了缩小 JAR 对预测技术的准确性没有影响。对于预测技术，仅评估了 LoadDynamics、CloudInsight 和 Wood 等。CloudScale 的准确性与 Wood 等预测器类似，因此在此评估中被放弃。Cloud Suite 的 In-Memory Analytics 基准用作作业执行，模拟一个处理机器学习训练和推断请求的系统。在每个时间间隔，记录完成所有到达作业所需的时间（即周转时间），并记录虚拟机配置不足和过度配置的百分比（相对于实际所需虚拟机数）。

图 10 显示了所有时间间隔的平均作业周转时间，以及平均虚拟机配置不足和过度配置率。如图所示，在 LoadDynamics 管理下，作业完成的速度比 CloudInsight 快 24.6%，比 Wood 等预测器快 38.1%。这种改进的性能主要是由于 LoadDynamics 下较低的虚拟机配置不足率所致，如图 10b 所示。具体而言，LoadDynamics 的虚拟机配置不足率比 CloudInsight 低 4%，比 Wood 等预测器低 10%。除了性能外，LoadDynamics 还通过较低的虚拟机过度配置率提高了资源利用效率。LoadDynamics 的虚拟机过度配置率比 CloudInsight 低 4.8%，比 Wood 等预测器低 17.2%。这些结果表明，LoadDynamics 带来的高准确性确实可以转化为实际的性能提升和资源效率改进。

V. 讨论和未来工作

其他超参数。除了本文探讨的四个超参数之外，训练和LSTM模型结构还涉及其他超参数。例如，可以使用与tanh函数不同的激活函数。其他损失函数和训练/优化算法也可能影响训练模型的准确性。尽管在我们的实验中，我们观察到调整这些超参数并没有提高评估工作负载的预测准确性，但这些附加的超参数可能会影响将LoadDynamics应用于其他工作负载时的准确性。这些附加的超参数也可以通过LoadDynamics当前的自动优化过程进行优化。然而，由于搜索空间更大，建立预测器可能需要更长的时间。

在线自适应建模 LoadDynamics可能会在工作负载完全改变为任何训练数据中未表示的新模式时出现高预测误差。在这种情况下，需要建立一个全新的预测模型以实现高准确性的预测。为了处理这种情况，LoadDynamics需要能够检测到以前未观察到的新工作负载模式的出现。它还需要能够自适应地重新训练其模型以处理这种剧烈的模式变化。我们计划在未来探索LoadDynamics的这种自适应变体。

VI. 相关工作

有大量的研究提出了从云端[7]、[30]、[36]，高性能计算/网格[29]和Web应用程序[9]等各种工作负载（例如作业到达率、资源需求）进行预测的方法。最常见的方法是将这些工作负载表示为时间序列数据，因此已经应用了各种时间序列模型，例如ES/WMA [13]、[32]、[37]–[39]，AR [40]–[42]，ARMA [14]、[16]，ARIMA [12]、[15]。此外，还采用了基于机器学习和统计分析的方法（如LR [2]、[11]、[43]、[44]，SVR [31]，随机森林 [30]，梯度提升 [30]和FFT [1]），以预测未来工作负载并设计主动资源管理机制。然而，以往的工作负载预测器往往针对特定工作负载进行优化/训练。正如[6]中所评估的那样，不同的预测器仅对特定工作负载产生准确的预测结果，这表明由于缺乏通用性，将这些预测器应用于不同或未知的工作负载模式非常具有挑战性。

为了克服上述方法的局限性，研究人员已经探索了基于多预测器的方法[3]、[20]、[45]–[49]。这些方法采用一组预测器（如多个时间序列和机器学习模型），并通过智能地使用/组合预测器来提高对不同工作负载或工作负载突变的适应性。特别是，CloudInsight [3]采用用户选择的任何预测器，利用多类回归来估计预测器在近期的未来准确性，并将更多权重分配给表现最好的预测器。不幸的是，基于多预测器的方法需要并行处理多个预测器，因此在进行预测时会产生不必要的计算开销。此外，这些方法中使用的预测器必须由用户选择，因此对于没有工作负载预测和特征化背景的普通用户来说，选择框架中使用的预测器是具有挑战性的。此外，这些研究中也存在超参数调优问题。错误选择的超参数仍然可能对这些多预测器方法的预测准确性产生负面影响。

由于深度学习的普及[50]，已经有一些尝试将深度学习模型应用于预测云工作负载[51]–[56]。这些工作与LoadDynamics在使用LSTM [17]或 LSTM 变体作为基础预测器方面具有相似之处。不幸的是，这些方法通常具有以下缺点。首先，LSTM模型仅从有限的工作负载训练，往往导致对训练数据集过拟合，并且对真实世界跟踪的评估并不全面。此外，这些方法如何调整/更新模型超参数尚不清楚，而这往往会改变预测准确性。实际上，如果不知道这些超参数，很难重现以前研究中的预测准确性。与以往的工作不同，LoadDynamics利用贝叶斯优化来进行超参数调整，因此LoadDynamics更加自适应，可以快速调整LSTM预测器，从而有效地处理不同的云工作负载。在第四部分，我们评估了来自Google、Azure、HPC和Web应用程序的多个工作负载的LoadDynamics，结果显示LoadDynamics始终优于最先进的工作负载预测器，表明LoadDynamics足够通用以处理各种工作负载。在LoadDynamics框架中使用模型自我优化也使得更容易复现LoadDynamics的结果。

VII. 结论

本文介绍了LoadDynamics的设计，这是一种用于云计算的通用工作负载预测器。LoadDynamics的目标是提供一种通用且自动化的预测技术，以便准确预测用户应用程序在云上可能遇到的各种动态变化的工作负载。为了实现这一目标，LoadDynamics采用具有自动调整超参数的长短期记忆（LSTM）模型，使其能够构建经过特定工作负载优化的预测器。我们使用来自四种类型云应用的五个真实工作负载跟踪评估了LoadDynamics。评估结果显示，由LoadDynamics构建的预测器在所有工作负载上具有较低的预测误差。LoadDynamics的平均预测误差仅为18%，远低于最先进的工作负载预测器。我们还将LoadDynamics应用于实际云中的自动扩展策略。相比最先进的预测器，LoadDynamics启用的自动扩展策略将转换时间缩短了最多38.1%。