基于组件服务质量和服务性能的云服务性能瓶颈诊断方法
郭军 , 马安香 , 闫永明 , 孟煜 , 张斌     
东北大学 计算机科学与工程学院, 沈阳 110819
摘要:瓶颈组件服务的诊断是保障面向服务业务流程的云服务系统性能的关键环节。传统诊断方法是通过评估组件服务的最大运行时延来确定导致整个组合服务质量变差的组件服务,未考虑组件服务的重要性,影响判断的准确性。该文在分析了各个组件服务质量的基础上,综合评估组件服务质量和重要性,提出了一种基于组件服务质量和服务性能的云服务性能瓶颈诊断方法,用来确定云服务瓶颈组件服务。仿真实验的结果验证了该瓶颈诊断方法的有效性和准确性。
关键词云服务     组件     瓶颈诊断     服务质量     服务性能    
Cloud service performance bottleneck diagnosis based on the component service quality and performance
GUO Jun, MA Anxiang, YAN Yongming, MENG Yu, ZHANG Bin     
School of Computer Science and Engineering, Northeastern University, Shenyang 110819, China
Abstract:Bottlenecks in component services need to be identified to ensure the performance of cloud service system-oriented service business processes. Traditional approaches for evaluating component service bottlenecks often evaluate the maximum run time delay in the component services to determine the cause of the quality-of-service deterioration. However, these approaches do not consider the importance of the component services, which influences the evaluation accuracy. A cloud service bottleneck diagnostic method is given here based on the quality of service on the various components in the analysis for comprehensive assessments of the quality of service and the component importance to identify cloud service bottlenecks in component services. Simulations show the effectiveness and accuracy of this bottleneck diagnosis method.
Key words: cloud services     component     bottleneck diagnosis     service quality     service performance    

面向服务业务流程的云服务是以工作流形式描述的,工作流中的每个任务均绑定在相应的组件服务之上,这些组件服务协同完成云服务,并直接影响云服务的服务性能[1-2]。组件服务经常需要在云环境资源池中部署多个副本来提高云服务的整体处理能力[3-4],因此基于多副本的云服务被广泛应用。

在复杂多变的运行环境中,组件服务经常因为某些原因(用户大量并发请求、组件服务处理能力较差等),出现服务性能下降的现象,从而影响云服务的整体服务性能。如何保障基于多副本的云服务的可靠性,是一个具有挑战性的问题[5]

为了保障云服务的性能,人们研究了很多服务调整方法[6-9],但是对整个云服务进行资源处理成本较大,因此需要首先确定严重影响云服务性能的瓶颈组件服务,之后针对这个瓶颈组件服务进行优化处理,这样能在资源有限的情况下以最小的成本来保障云服务的性能[10-11]。目前,服务组合的瓶颈服务诊断主要是通过评估服务的最大运行时延来确定导致整个组合服务质量变差的服务[12]。根据最大运行时延在一定程度上可以确定瓶颈组件服务,但是如果得到的瓶颈组件相对整个云服务来说并不是重要的组件,则这个瓶颈组件也不是影响云服务性能最大的关键组件,这时即使调整这个组件服务,也不能最大程度地调优云服务的性能。

当云服务承担的负载过重即并发量过大时,本文在分析了各个组件服务质量的基础上,综合评估组件服务质量和重要性,提出了一种基于组件服务质量和服务性能的云服务性能瓶颈诊断方法,用来确定云服务瓶颈组件服务。最后,通过仿真实验验证本文的瓶颈诊断方法的有效性和准确性。

1 云服务性能瓶颈诊断的基本思想

云服务性能瓶颈诊断是通过综合分析组件服务的服务质量和重要性,来确定严重影响云服务性能的瓶颈组件服务。

1.1 基于组件副本的云服务性能瓶颈问题

基于组件副本的云服务中,每个组件服务在虚拟机资源池中部署了一个或多个服务副本。通常一个组件服务副本数目越多,其处理能力越好,但是对服务每增量部署一个副本都需要一定的成本代价,因此为了节省成本,应该只对瓶颈组件服务进行副本增量部署,以此来提升处理能力。

云服务的性能瓶颈诊断综合评估了组件服务的服务质量和重要性,其相关的概念描述如下:

1) 组件服务的平均运行时延,即从向组件服务发出请求到组件服务或其副本完成服务并返回信号的整个服务运行时间。其决定因素有:组件服务的平均数据量、组件服务的平均最小处理时间、组件服务所能承担的最大并发请求量和当前并发请求量。组件服务的平均运行时延与组件服务执行的平均数据量成正比,与当每个处理节点具有最大可用资源时的组件服务的平均最小处理时间成正比,与组件服务各副本最大并发请求量的总和成正比,与组件服务各副本的空闲负载(最大并发请求量与当前并发请求量的差) 成反比。

2) 组件服务重要性,即一个组件服务在多副本的情况下对其他组件服务甚至云服务的关联程度和影响程度,即当这个组件服务出现问题时,影响其他组件服务及整体服务性能的程度。组件服务ci的重要性值可以用v(ci) 表示,i=1, 2, …, n。重要性是由组件服务与其他组件服务之间的调用关系和调用频率近似评估的。

3) 组件服务调用关系,即组件服务被哪些组件服务调用以及调用了哪些组件服务。通过组件服务调用关系,可以得到某个组件服务在关联关系方面所影响的组件服务的个数,即一旦这个组件服务出现问题,受其影响的组件服务的个数。

4) 组件服务调用频率,即在一段时间内,某组件服务被其他各个组件服务调用的次数,或者这一组件服务在整个服务运行过程中被调用的次数。一般调用频率大的组件服务出现问题时,将会对云服务的性能造成较大影响。

1.2 云服务性能瓶颈诊断方法

在诊断瓶颈组件服务时,需要评估所有组件服务的服务质量和重要性。其中,服务质量根据组件服务运行时延来评估,组件服务的重要性则是分析组件服务的调用关系和调用频率[13],再根据PageRank来对组件服务进行重要性计算。在确定了各个组件服务的服务质量和重要性值之后,综合这两方面进行瓶颈组件服务选择,得到影响云服务性能最大的瓶颈组件服务,具体过程如图 1所示。

图 1 瓶颈诊断基本过程

2 云服务性能瓶颈诊断的关键算法 2.1 组件服务平均运行时延的评估方法

云服务的组件服务集合为C(c1, …, ci, …, cj, …, cn),其中i, j∈[1, n],只要ij,则ci不是cj的副本。每个组件服务都有各自的副本集合,例如ci的副本集合为Ci(c1, …, ck, …, cm)。其中:m为组件服务ci的副本数,ck为组件服务ci的第k个副本。

为了评估组件服务的平均运行时延,首先介绍组件服务相关参数符号,如表 1所示。

表 1 组件服务相关参数符号
符号名含义
DT (ci)组件服务ci的平均运行时延
DA (c′k)组件服务副本c′k执行的平均数据量
MT (c′k)当组件服务副本c′k拥有最大可用资源时的最小处理时间
ML (c′k)组件服务副本c′k能运行的最大并发请求数
CL (c′k)组件服务副本c′k当前的并发请求数

组件服务ci的平均运行时延可通过式(1) 计算得到,

$ \begin{array}{*{20}{c}} {{\rm{DT}}\left({{c_i}} \right)=\frac{1}{{n_i^2}} \cdot \sum\limits_{k=1}^{{n_i}} {{\rm{DA}}\left({c_k^i} \right)\cdot \sum\limits_{k=1}^{{n_i}} {{\rm{MT}}\left({{{c'}_k}} \right)} } \cdot }\\ {\frac{{\sum\limits_{k=1}^{{n_i}} {{\rm{ML}}\left({c_k^i} \right)} }}{{\sum\limits_{k=1}^{{n_i}} {{\rm{ML}}\left({c_k^i} \right)-\sum\limits_{k=1}^{{n_i}} {{\rm{CL}}\left({{{c'}_k}} \right)} } }}.} \end{array} $ (1)
2.2 组件服务重要性的评估方法

当组件服务cini个副本,cjnj个副本时,组件服务cjci调用的频率则可以通过计算所有副本之间调用的频率之和得到,

$ {F_{ij}}=\sum\limits_{{k_1}=1}^{{n_i}} {\sum\limits_{{k_2}=1}^{{n_j}} {{f_{{k_1}{k_2}}}} }. $ (2)

其中:fk1k2为组件服务ci的第k1个组件服务副本调用组件服务cj的第k2个组件服务副本的调用频率,而Fij为组件服务ci调用cj的总调用频率。

组件服务调用关系模型(component relation model,CRM) 是一种描述各个组件服务之间调用关系和调用频率的模型,可以用单向图或矩阵来表示。这里主要针对单向图的云服务进行研究,即组件服务ci调用另一个组件服务cj,则cj不会再调用ci,否则进入死循环。

根据调用关系和调用频率计算每个组件服务相对其他所有组件服务的权值eij,即组件服务ci调用cj的相对频率,如式(3) 所示。同时, 可以建立组件服务调用关系模型,即调用关系矩阵E,如式(4) 所示。

$ {e_{i, j}}=\frac{{{F_{ij}}}}{{\sum\limits_{j=1}^n {{F_{ij}}} }}. $ (3)
$ \begin{array}{*{20}{c}} {\mathit{\boldsymbol{E=}}\left[{\begin{array}{*{20}{c}} {{e_{1, 1}}}&{{e_{1, 2}}}&\cdots &{{e_{1, n}}}\\ {{e_{2, 1}}}&{{e_{2, 2}}}&\cdots &{{e_{1, n}}}\\ \vdots &\vdots &\vdots &\vdots \\ {{e_{n, 1}}}&{{e_{n, 2}}}&\cdots &{{e_{n, n}}} \end{array}} \right], }\\ { \vee i, \sum\limits_{j=1}^n {{e_{i, j}}=1}.} \end{array} $ (4)

可以基于调用关系矩阵画出组件服务调用关系图,其中一个组件服务到所有其他组件服务的边的和为1,如果ci没有出边,则eij=1/n。对于没有调用关系的组件服务可以在关系图中不出现边。关系图示例如图 2所示。

图 2 组件服务调用关系

在得出调用关系后,再通过递归计算向量公式(5),直到各组件服务的重要性值v(ci) 稳定不变,

$ \left[{\begin{array}{*{20}{c}} {v\left({{c_1}} \right)}\\ \vdots \\ {v\left({{c_n}} \right)} \end{array}} \right]=\left[{\begin{array}{*{20}{c}} {\left({1-K} \right)/n}\\ \vdots \\ {\left({1-K} \right)/n} \end{array}} \right]+K \cdot {\mathit{\boldsymbol{E}}^{\rm{T}}}\left[{\begin{array}{*{20}{c}} {v\left({{c_1}} \right)}\\ \vdots \\ {v\left({{c_n}} \right)} \end{array}} \right]. $ (5)

其中,K用来调整组件服务自身重要性和其他组件服务对其重要性的影响,K=0.5,即组件服务自身影响和其他组件服务对它的影响是等重的。组件服务的重要性值是由其自身值(即(1-K)/n) 和其他被此组件服务调用的组件服务的重要性值共同决定。

2.3 瓶颈组件服务的选择算法

在评估了组件服务的服务质量和重要性的基础上,通过式(6) 来计算组件服务的综合评估值(comprehensive evaluation,CE)。综合评估值最大的组件服务将被诊断为瓶颈组件服务。组件服务ci的综合评估值用CE (ci) 表示,

$ {\rm{CE}}\left({{c_i}} \right)=v\left({{c_i}} \right)\cdot {\rm{DT}}\left({{c_i}} \right). $ (6)

可求得具有最大综合评估值的组件服务为瓶颈组件服务CB

$ {C_{\rm{B}}}=\arg \;{\max _{1 \le i \le n}}\left({{\rm{CE}}\left({{c_i}} \right)} \right). $ (7)

综上,本文提出了一种基于组件服务质量和重要性的云服务性能瓶颈诊断算法,具体如图 3所示。

图 3 基于组件服务质量和重要性的性能瓶颈诊断算法

图 3算法中输入每个组件服务的重要性值和运行时延大小,输出为瓶颈组件服务CB。这里比较任两个组件服务的综合评估值CE (ci) 和CE (cj),来得到具有最大综合评估值的组件服务(瓶颈组件服务CB)。

3 仿真实验及结果分析

实验环境是一台HP Z820工作站以及若干台HP Compaq 8080台式计算机作为物理机,利用基于内核虚拟机(kernel-based virtual machine, KVM) 技术将服务器虚拟化成3个虚拟机,在虚拟机的Linux操作系统中安装Tomcat中间件来部署Java开发的云服务(包括4个组件服务c1c2c3c4),并在其中一台虚拟机上安装Nginx,依靠Nginx来实现面向多副本的云服务的负载均衡,即同一个部署多个副本的组件服务可以分担所有的用户请求。这里每个副本都是等权重的。

为了验证本文提出的瓶颈诊断方法的效果,本文进行两组对比实验:

1) 对具有最大运行时延的组件服务采取副本增量部署的性能优化措施。对于监测到的每个组件服务及其副本的平均数据量和最小处理时间,采用2.1节中的评估方法可得4个组件服务某一时刻的平均运行时延为:DT (c1)=4.62 s,DT (c2)=28.965 s,DT (c3)=18.989 s,DT (c4)=16.631 s。

由此可知,组件服务c2为具有最大运行时延的组件服务,接下来可以对c2采取增加部署副本的策略,查看云服务的响应时间变化。

2) 对本文提出的瓶颈诊断方法得出的瓶颈组件服务采取副本增量部署的性能优化措施。10 min内各个组件服务的调用次数见表 2

表 2 组件服务调用数量表
组件服务c1c2c3c4
10 min调用次数498249247497

利用2.3节中的计算方法进行处理后,得出的组件服务之间的关联关系矩阵,

$ \mathit{\boldsymbol{E=}}\left[{\begin{array}{*{20}{c}} 0&{0.5}&{0.5}&0\\ 0&0&0&1\\ 0&0&0&1\\ {0.25}&{0.25}&{0.25}&{0.25} \end{array}} \right]. $

根据基于组件服务质量和重要性的瓶颈诊断方法得出瓶颈组件服务为c4之后,对瓶颈组件服务c4采取增加部署副本的策略,查看云服务响应时间的变化。

对以上两组对比实验中的云服务性能优化情况进行监测,即监测云服务的响应时间变化,具体如图 4所示。

图 4 增量部署两种组件服务副本的效果对比

图 4为并发请求数为35时的10 min内所监测的云服务正常运行时响应时间的变化情况。其中: A线为初始云服务的响应时间(响应时间的平均值约为44.65 s),B线为对云服务增加一个具有最大运行时延的组件服务副本时的响应时间(响应时间的平均值为37.04 s),C线为对云服务增加一个瓶颈组件服务副本时的响应时间(响应时间的平均值为34.07 s)。

图 4可知,对基于组件服务质量和重要性的云服务瓶颈诊断得出的瓶颈组件服务,采取增加其副本的方式来保障云服务性能时,比对具有最大运行时延的组件服务采取相同的措施,更能优化云服务的性能。因此,基于组件服务质量和重要性的云服务瓶颈诊断方法更准确和有效。

对于增加组件副本的策略,本文采取每次增加一个组件副本的方式,但是随着副本不断增加,响应时间也不断减小,但是不会一直减小,如图 5所示。

图 5 响应时间随副本个数变化

图 5中,当增量部署一个瓶颈组件服务副本时,云服务的响应时间降低为34.07 s,当增量部署3个副本时,云服务的响应时间降低为21.05 s,但是当增量部署第4个副本时,则为20.46 s,变化不大。因为云服务受所有组件服务的共同影响,当一个瓶颈组件服务被优化时,还可能存在其他瓶颈组件服务,而且云服务为了完成服务都存在一定的最小运行时间。但从实验结果可以看出,通过增加瓶颈组件服务副本进行服务优化的效果要优于通过增加具有最大运行时延组件服务副本的效果。

4 结论

基于组件的云服务系统经常需要在云环境资源池中部署多个副本来提高云服务的整体处理能力。保障服务可靠性的关键问题是找到瓶颈组件。为了诊断云服务的性能瓶颈组件服务,本文在分析了已有瓶颈诊断方法在应对基于多副本的云服务时存在不足的基础上,提出了基于组件服务质量和重要性的云服务性能瓶颈诊断方法,即综合评估组件服务的服务质量和重要性,来确定影响云服务性能最大的瓶颈组件服务。仿真实验验证了本文的瓶颈诊断方法的有效性和准确性。本文研究有助于保障基于多副本的云服务的可靠性。

参考文献
[1] Cardellini V, Casalicchio E, Grassi V, et al. Moses:A framework for QoS driven runtime adaptation of service-oriented systems[J]. IEEE Transactions on Software Engineering, 2012, 38(5): 1138–1159. DOI:10.1109/TSE.2011.68
[2] ZHU Jieming, HE Pinjia, ZHENG Zibin, et al. Towards online, accurate, and scalable QoS prediction for runtime service adaptation[C]//IEEE International Conference on Distributed Computing Systems. Madrid, Spain, 2014:318-327.
[3] Tsai W T, Zhong P, Elston J, et al. Service replication strategies with MapReduce in clouds[C]//2011 Tenth International Symposium on Autonomous Decentralized Systems. Tokyo & Hiroshima, Japan:IEEE Press, 2011:381-388.
[4] Rosa L, Rodrigues L, Lopes A, et al. Self-management of adaptable component-based applications[J]. IEEE Transactions on Software Engineering, 2013, 39(3): 403–421. DOI:10.1109/TSE.2012.29
[5] Mirandola R, Potena P, Riccobene E, et al. A reliability model for service component architectures[J]. Journal of Systems and Software, 2014, 89(2): 109–127.
[6] Binz T, Leymann F, Schumm D. CMotion:A framework for migration of applications into and between clouds[C]//2011 IEEE International Conference on Service-Oriented Computing and Applications (SOCA). Irvine, CA, USA:IEEE Press, 2011:1-4.
[7] 赵秀涛, 张斌, 张长胜. 一种基于服务选取的SBS云资源优化分配方法[J]. 软件学报, 2015, 26(4): 867–885. ZHAO Xiutao, ZHANG Bin, ZHANG Changsheng. Service selection based resource allocation for SBS in cloud environments[J]. Journal of Software, 2015, 26(4): 867–885. (in Chinese)
[8] Vogel T, Giese H. Model-driven engineering of self-adaptive software with EUREMA[J]. ACM Transactions on Autonomous & Adaptive Systems, 2014, 8(4): 1–33.
[9] 杨雷, 邢禾续, 代钰, 等. 考虑虚拟机间性能互扰的虚拟资源分配方法[J]. 通信学报, 2014, 35(9): 79–90. YANG Lei, XING Hexu, DAI Yu, et al. Virtual resource allocation method with the consideration of performance interference among virtual machines[J]. Journal on Commuications, 2014, 35(9): 79–90. (in Chinese)
[10] Iqbal W, Dailey M N, Carrera D, et al. SLA-driven automatic bottleneck detection and resolution for read intensive multi-tier applications hosted on a cloud[C]//International Conference on Grid and Pervasive Computing. Hualien, China, 2010:37-46.
[11] SONG Ying, SUN Yuzhong, SHI Weisong. A two-tiered on-demand resource allocation mechanism for VM-based data centers[J]. IEEE Transactions on Services Computing, 2013, 6(1): 116–129. DOI:10.1109/TSC.2011.41
[12] Jha P, Bali V, Narula S, et al. Optimal component selection based on cohesion and coupling for component based software system under build-or-buy scheme[J]. Journal of Computational Science, 2014, 5(2): 233–242. DOI:10.1016/j.jocs.2013.07.003
[13] ZHENG Zibin, Zhou T C, Lyu M R, et al. Component ranking for fault-tolerant cloud applications[J]. IEEE Transactions on Services Computing, 2012, 5(4): 540–550. DOI:10.1109/TSC.2011.42