[A类排队论多层应用多线程]Integrating Concurrency Control in n-Tier Application Scaling Management in the Cloud

Integrating Concurrency Control in n-Tier Application Scaling Management in the Cloud

IEEE Transactions on Parallel and Distributed Systems,2019. CCF A类

VM背景下的n层应用调度，最大的贡献是对多层应用在多线程环境下的服务时间的估计建模。

背景

作者发现在进行硬件调度之后，如果没有适当地进行软件设置（这里指的是并发量设置，比如Apache服务器的线程池大小、Tomcat的线程池大小、TomcatDB连接数大小等），则系统所能达到的并发量（throughput,我认为这里指的是处理速度）难以达到一个较高的水平，在文中这被称为Performance Degradation with sub-optimal concurrency setting。此处见原图3

建模

作者使用了G/G/m模型进行建模，主要是描述Throughput的最大值，我目前还是没有看懂公式，我的理解是它通过一系列变换（主要是与M/M/n的近似），构建了系统单位时间内的最大处理量与一系列能够测量出来的值的关系。然后这些能测量出的值一般是通过online measurement进行更新，有一些值是通过离线测试来进行的。

比较核心的一点就是它对在多线程环境下的服务时间进行了建模估计，从结果上来说应该还不错吧。核心公式是$S_b^{\ast }=S_b^0+{\alpha }_b(N_b-1)+{\beta }_b{N}_b(N_b-1)$，所有下标带b的表示瓶颈层。

核心用意就是说使用单线程对应的服务时间$S_b^0$，线程数$N_b$，以及两个与硬件设置和流量特性相关的参数${\alpha }_b$，${\beta }_b$来估算出当前瓶颈层的服务时间，从而为后面估算throughput的最大值提供指导，并给出throughput达到最大值的条件$N_b=\sqrt{\frac{S_b^0-{\alpha }_b}{{\beta }_b}}$。

参数估计与验证

所建立的这个Concurrency-aware model的目标就是建立request processing concurrency in Tomcat和system throughput之间的关系（而且似乎是相关关系），所以验证指标选用的是R^2值。用的建模方法是Least-Square Fitting analysis来进行估算。

会根据最终预测的结果对模型进行调整，来保证准确性。作者提到，$S_b^0$实际上是与硬件配置和流量特性相关的量，并不一定保持不变，因此要进行实时的计算。

动态调度算法

分为两个部分：VM-level scaling和soft resource scale。两者是同步进行的，即VM开始调度的时候会调整对应层的连接数。

VM-level scaling用的是很简单的预设阈值法来进行调入调出。唯一的亮点就是用了快增慢缩方法。

soft resouece scaling这里比较复杂，分为两种情况。如果选择是缩减实例，则直接获得当前层的最佳并发量；如果选择是增加实例，则会根据下一层的最佳并发量来计算当前层的最佳并发量，具体计算过程如下：

• nTier数组表示每一层的VM数量，scaleTier为当前的瓶颈层，scaleTier+1为瓶颈层的下一层。scaleStep为伸缩的单位，在扩容中一般为1.

optAlloc = ModelPredict(scaleTier+1)
soft[scaleTier] = (optAlloc*nTier[scale+1])/(nTier[scaleTier]+sclaeStep)

即确保当前瓶颈层与下一层的并发量是一致的。

实验结果分析

实验结果主要是与Amazon EC2-AutoScaler进行对比，从大的方向上来看，作者所采用的方法CPU占用率会在同等情况下偏高，但是响应时间确实是一直控制的很低，流量也都得到了处理。

从一些细节进行分析，Amazon EC2调度器所遇到的问题是一个瓶颈层的迁移问题，即进行扩容操作后，下游服务的处理能力跟不上，导致响应时间反而提升。

这里我还是存在一些疑问，我在思考原文是否采用了准入控制或者熔断之类的策略，或者它根本没有将没进入系统的流量的等待时间纳入考量，不然这个结果似乎并不合理。