GuntherX's

【文献精读】The Power of Prediction: Microservice Auto Scaling via Workload Learning 微服务下的负载预测及资源分配

Apr 14, 2023 - #Research

Metadata

Abstract

When deploying microservices in production clusters, it is critical to automatically scale containers to improve cluster utilization and ensure service level agreements (SLA). Although reactive scaling approaches work well for monolithic architectures, they are not necessarily suitable for microservice frameworks due to the long delay caused by complex microservice call chains. In contrast, existing proactive approaches leverage end-to-end performance prediction for scaling, but cannot effectively handle microservice multiplexing and dynamic microservice dependencies. In this paper, we present Madu, a proactive microservice auto-scaler that scales containers based on predictions for individual microservices. Madu learns workload uncertainty to handle the highly dynamic dependency between microservices. Additionally, Madu adopts OS-level metrics to optimize resource usage while maintaining good control over scaling overhead. Experiments on large-scale deployments of microservices in Alibaba clusters show that the overall prediction accuracy of Madu can reach as high as 92.3% on average, which is 13% higher than the state-of-the-art approaches. Furthermore, experiments running real-world microservice benchmarks in a local cluster of 20 servers show that Madu can reduce the overall resource usage by 1.7X compared to reactive solutions, while reducing end-to-end service latency by 50%.

Main Content

本工作提出了一种基于单个微服务不确定性分析的OS metric负载预测方案Madu，用以实现微服务场景下的资源分配，以提高资源利用率，保证时延的稳定 ### Madu的背景和贡献

Reactive & Proactive

Reactive的资源调整方法对于微服务框架来说是不可行的，因为微服务的调用链非常复杂，会产生很长的延迟效应，而现有的Proactive的方法也同样没有考虑到微服务的复用性(microservice multiplexing) 和动态依赖性(mircroservice dependencies)。

Q：在微服务下， 为什么Reactive的scaling方法不work？ A： 1. 微服务处理服务请求的调用链可能非常长，这种情况下，调用链底端的微服务可能需要很长时间才会经历负载的变化，而当它观测到负载变化时，可能已经为时过晚了。 2. scaling微服务通常需要从仓库拉去images，这个操作需要数秒来完成，而在线服务的SLAs通常是用几百微秒来定义的，因此reactive的方法常常会导致SLA侵犯。

Q：现有的Proactive的scaling方法为什么不能有效的应用于微服务场景？ 今的微服务预测通常是基于依赖图来进行预测，这种方法没有考虑微服务的两个核心特征： 1. 同一个在线服务可能会产生完全不同拓扑结构的调用图，这种高度动态的特征使得基于图的训练难以在实际中使用(Fig1 (a): Dynamic dependencies)，现有的proactive的autocaling的方法都是基于静态图的所以效果不会好。 2. 单个的microservice可能会被多个在线服务复用，如果独立的训练所有的调用图可能难以解决微服务复用的问题(Fig1 (b): Shared microservices)，一种方法是组合单个服务图形成一个组合图，但是这种方法的可扩展性比较差，因为生产环境通常会包含成千上万个微服务。 image.png

Data-dependent Uncertainty

一个微服务负载除了有周期特征之外，还有很强的[[Data-depentent Uncertainty]]。本文给出的Data-dependent Uncertainty的解释是

That is, peak workloads have much higher variance across different periods (relative to the mean workload) than other workloads due to the dynamic dependency between microservices.

其实这个所谓的Data-depentent Uncertainty并不是微服务独有的，关于这个部分，非常值得深入研究。因为时序预测中这个现象非常普遍，需要去 找一下有没有什么更先进的方法能解决这种不确定性问题。

微服务负载的不确定性

本工作将负载定义为每分钟调用次数(Call Per minute, CPM)

image.png

微服务性能指标

image.png CPU和内存利用率与微服务工作负载的相关性比微服务响应时间更强。因此，Madu转而使用这些操作系统级别的指标来评估微服务的性能以进行资源扩展

本文的贡献

系统总体设计

image.png

Auto-scaler独立于微服务集群运行，在每一分钟的开始，它会向

Madu的设计与实现

微服务负载学习

模型输入(Encoder)：长度为n的向量\(\boldsymbol{X}_t^E=\left[x_{t-n+1}, x_{t-n+2}, \cdots, x_t\right]\) 模型输出(Decoder)：长度为m的向量\(\boldsymbol{X}_t^D=\left[x_{t+1}, x_{t+2}, \cdots, x_{t+m}\right]\) 其中的每一个\(x_i={C_t,t_m,t_h,t_w}\)，\(C_t\)表示\(t\)时刻的CPM，而\(t_m,t_h,t_w\)分别表示分钟、小时和星期，送入时间特征让模型能够学习到时序信息，n和m的值是训练准确率和scaling效率的tradeoff

对于\(s_{t j}=f\left(a_{t j}\right)\)，非随机的注意力机制通常假定\(f\)是一个线性函数，而对于随机注意力机制，则是从一个高斯分布\(s_{t j} \sim \mathbf{N}\left(\mu_{t j}, \sigma_{t j}\right)\)中采样得到的，其中\(\mu_{tj}=W_{\mu j}a_{tj}+b_{\mu j}, \sigma_{tj}=W_{\mu j}a_{tj}+b_{\sigma j}\)，4个\(W\)和\(b\)是由模型学习的参数

微服务性能建模

通过刻画内存利用率以及CPU利用率与CPM的关系可以发现，它们几乎是线性相关的，因此拟合两个线性回归模型就可以了 image.png

在线容器缩放以及缩放优化

根据Performance Profiling拟合出来的线性函数、及Workload Predictor预测的CPM值以及预定的CPU和内存利用率阈值，可以计算出之后m个时间区间内所需要的容器数量，但是同时为了避免大量的调整容器数量（调整容器也同样需要消耗资源并且需要一定的时间），还需要做出一些限制，具体的，需要解决一个最优化问题： \(\begin{aligned} & \min _{\boldsymbol{x}_i} \sum_{k=1}^m\left(x_i(t+k-1)-x_i(t+k)\right)^2 \\ & \text { s.t., } c_i(t+k) \leq x_i(t+k) \leq(1+\rho) \cdot c_i(t+k) .\end{aligned}\) 其中\(c_i\)表示微服务i的容器数量，\(\rho\)是一个预先定义的常量，这是一个[[凸优化问题]]， Madu使用[[CVX sovler]]来解

验证与性能表现

Madu和其他4种算法进行了对比，分别为ARIMA、Seq2Seq、BNN、DUBNN，值得注意的是，在高负载的情况下，DUBNN的表现也很好，但是DUBNN的训练成本要远高于Madu，并且文章解释DUBNN和BNN都需要一个先验估计，这个先验估计选取得不恰当的话会严重影响性能 整体表现上：

image.png
image.png

Appendix

Reading List

Reactive Autoscaling

Proactive Autoscaling

Workload Learning

Microservice Study

attention

Autoscaling

⬆ , ,