Less Provisioning: A Hybrid Resource Scaling Engine for Long-running Services with Tail Latency G..._综合

Less Provisioning: A Hybrid Resource Scaling Engine for Long-running Services with Tail Latency Guarantees

IEEE Transactions on Cloud Computing, 2020, CCF C类。然而其实是作者另外一篇2018年B类的补充版本，所以其实这篇应该算是B类（我个人觉得够不上A类，不过也不好说）

这篇论文和我之前做调度的思路基本是一致的，只不过用的方法不太一样。虽然我现在也不做调度就是了……

想法其实很简单，就是分了两种情况构建预测式调度，根据访问量预测资源占用率从而完成调度（虽然强调的点不是调度，但确实是可以用的）

有周期性的流量：直接用基于卷积的方式计算出周期长度，然后估计到达模式（这一部分没太看明白），最后使用了推荐系统中的协同过滤来预测资源占用率，并基于此进行资源分配。
对于没有周期性的流量，使用小波分解+ARIMA进行流量预测，然后使用了一种比例算法来进行资源预测。

初步的印象是尽管想法很新颖，结果也还不错(最终的目标是要保证SLO，虽然从头到尾SLO在调度过程中就没有出现过，除了数据选择部分)。但是这个方法成立的基础其实有些依赖于一个假设，即在一个很长的时间段内，对于相同的流量，CPU占用率是几乎不变的。我觉得如果有这么简单，我直接打一个测试流量建立一个映射就好了，为什么要费这么大的功夫。

优点也挺明显的，可解释性很强，并且如果假设成立的时候确实能做到非常准确，而且计算代价很小（主要代价来源于聚类部分）。

摘要

现代的资源管理系统一般使用资源超分配技术来保证长期运行应用的低延迟(low tail latency)，这样的结果会导致严重的资源浪费与服务成本的增加。我们提出了混合资源调度引擎HRSE来解决这个问题，允许面对周期性和非周期性的流量提出更有效的资源分配方式来保证SLO。

HRSE采用了一种基于卷积的时间序列分析方法来识别流量中的模式。如果流量的模式被发现了，会使用一种基于topK技术的协同过滤算法来估计需要的刚刚好的资源。否则，会采用基于小波分解的方式来捕获非周期性流量中存在的短期波动，并预测未来的资源消需求。

为了更好地保证SLO，HRSE系统采用了在线的再分配技术来动态调整资源以应对突发的流量。我们在Docker平台上部署实验并使用真实生产平台下的日志来进行模拟。

1 Introduction

介绍背景：现在为了保证长期运行应用的响应时间延迟，一般会采用静态的基于最大访问量的资源分配方式。保证响应时间SLO是为了提高利润，而保证的时候会遇到两个挑战：第一是流量具有突发性；第二是相同的流量可能会有完全不同的表现，作者将这种现象解释为资源共享。

因此，我们想要使用最少的资源来满足SLO，同时尽量降低超分配资源带来的代价。现有的系统分为两类，一类采用静态分配的方式，会给随时间变化的流量分配固定数量的资源；另外一种采用动态分配的方式，但是针对的对象是批处理应用，而批处理应用关心的是任务的执行时间而非响应时间。

最小化资源超分配代价依赖于对流量的精确预测，进行了以下工作

找周期长度，按周期分配
如何为非周期性流量分配资源（无需先验知识，不用对应用进行测试）
应对突发流量

2 Motivation

进行了一系列的分析，对网络流量的性质进行了比较系统的描述。并且通过实验证明了多余资源的存在是完全无用的，通过使用后台应用占用多余资源的方式证明了，多余资源的存在对于降低应用的响应时间没有任何帮助，因此尽量少的减少资源分配是可行的。

3 Architecture and design

预处理：对时间序列聚类进行符号化处理，应该是SAX方法，只是作者没有使用这个名字。
周期计算：使用基于卷积的方式计算周期的长度。说实话没看明白
估计到达模式：计算出"best-fit"的模式来与原数据相匹配，说实话也没看明白。作者的想法就是对其进行建模，即新估计出来的周期内的预测值，每一个与之前所有周期内对应时间的预测值的差值的平方之和要最小。将其作为一个p个变量（每个周期的长度为p个点）的IQP问题进行求解。作者使用了Cplex来求解。
资源估计：使用了推荐系统中的协同过滤技术。协同过滤技术说的是用户打分问题，即如何估算没有被用户打分的商品的分数。

有周期性数据的资源估计

协同过滤的对应，将每一个周期作为用户，其中的实际流量数与资源占用率作为商品，这些值的估算值作为评分。

因为协同过滤算法是相关性算法，难以处理大量用户（复杂度较高），作者采用了K-means聚类算法。原本计算的时候需要计算一个用户与其他所有用户的相似度与商品评分差值，现在只需要计算与K个中心的相似度与差值即可。

会在最相似的聚类中选择K个用户来进行相似度度量，从而进行计算。同时考虑到如果流量预测值相差过大就没有意义了，还加了个限制条件。

最终相当于根据流量预测值与真实值之间的关系（相似性）计算出一个相关系数，这个相关系数与之前的CPU占用率加权，估算出未来一个周期的CPU占用率。

无周期性数据的资源估计

流量预测采用的是ARIMA+小波分解，说实话没怎么看明白它ARIMA的参数是怎么选的，不过也不用看明白。

对于资源的预测采用的是基于聚类的方式进行的。首先是将请求率分成k组Gk，每一个组在空间上是有一段持续时间的（见原图Fig9）。

对于预测值 $r^h\hat{r}_h$ ，论文将其分配给了与它最相似的组 $G_x$ 上。这样，使用过去 $G_x$ 的资源占用率，我们就能获得未来资源占用率的估计值。

首先，我们删除过去持续时间中那些违反了SLO的记录（如果某一个持续段SLO违约时间比例高于阈值，则此段删除）。总共有N个，每一个用 $SlxS^x_l$ 来代替，x表示是哪一个聚类，l表示是第几个持续段。

然后，使用 $G_x$ 中的请求到达率和它们对应的资源利用率来决定 $r^h\hat{r}_h$ 相关的资源利用率。

$Ra(ri,r^h)=rir^hRa(r_i,\hat{r}_h)=\frac{r_i}{\hat{r}_h}$ （当预测值准确度够高，即小于一定的阈值时）

后面就使用访问量预测值与实际值之间的比值来估计资源占用率的比值，从而估算资源占用率

4 实验

使用RUBiS在Docker上进行部署。固定了15个容器不变，来运行各种应用，但是会调整处理器的数量。（大概是这个意思？说实话我觉得scaling不调整容器数量算什么东西）

比较亮眼的是本文采用的算法实际上是与peak-based的算法进行对比。这个peak-based算法总是使用上一个周期流量的最大值来作为下一个周期资源分配的依据，因此一般是很难违约的，反倒是容易资源浪费。对比结果还可以，资源浪费低，但是响应时间略高，可以接受。