INFORMATION Technology (IT) infrastructure management

Transcription

1 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY Buine-Driven Long-term Capacity Planning for SaaS Application David Candeia, Ricardo Araújo Santo and Raquel Lope Abtract Capacity Planning i one of the activitie developed by Information Technology department over the year, it aim at etimating the amount of reource needed to offer a computing ervice. Thi activity contribute to achieving high Quality of Service level and alo to puruing better economic reult for companie. In the Cloud Computing context, one plauible cenario i to have Software-a-a-Service (SaaS) provider that build their IT infratructure acquiring reource from Infratructure-a-a-Service (IaaS) provider. SaaS provider can reduce operational cot and complexity by buying intance from a reervation market, but then need to predict the number of intance needed in the long-term. Thi work invetigate how important i the capacity planning in thi context and how imple buine-driven heuritic for long-term capacity planning impact on the profit achieved by SaaS provider. Simulation experiment were performed uing ynthetic e-commerce workload. Our analyi how that propoed heuritic increae SaaS provider profit, on average, at 9.651% per year. Analying uch reult we demontrate that capacity planning i till an important activity, contributing to the increae of SaaS provider profit. Beide, a good capacity planning may alo avoid bad reputation due to unacceptable performance, which i a gain very hard to meaure. Index Term Capacity Planning, Cloud Computing, Software-a-a-Service. 1 INTRODUCTION INFORMATION Technology (IT) infratructure management i a dicipline that aim at achieving tability and control of an IT infratructure [1]. IT management i important to meet QoS requirement and to achieve an efficient ue of the infratructure. Deciion made in uch dicipline have an impact on the infratructure owner buine bottom line and, becaue of thi, IT infratructure management evolved to conider buine apect [1]. Planning the amount of computing reource needed to deliver a computing ervice (i.e., application) i one of the activitie of an IT infratructure management platform, which i called capacity planning. Before Cloud Computing, capacity planning typically involved overproviioning of the IT infratructure [2] a a common olution to deal with workload peak. Cloud Computing ha brought ome noveltie: provider offer computing ervice in different market; client can buy computing ervice and tart them quickly. Three main type of ervice are commonly preented [3]: Infratructure-a-a-Service (IaaS), Platform-aa-Service (PaaS) and Software-a-a-Service (SaaS); all thee ervice are acquired in a pay-per-ue manner. In thi paper, we conider a cenario in which a SaaS provider i a conumer of one IaaS provider [4]. IaaS provider typically offer everal type of virtual intance configuration: different amount of CPU unit, David Candeia i with Intituto Federal de Educação, Ciência e Tecnologia da Paraíba, Campina Grande, Paraíba, Brail. david.maia@ifpb.edu.br. Raquel Lope and Ricardo Araújo Santo are with Univeridade Federal de Campina Grande - UFCG. raquel@computacao.ufcg.edu.br, ricardo@ld.ufcg.edu.br Manucript received May 28, 214 memory and torage. Furthermore, IaaS provider uually offer virtual intance in two different market, each one with different charging trategie and QoS offered: (i) in the on-demand market, available intance of the IaaS provider are acquired with no long-term commitment by paying an uage fee for each uage charging period (typically an hour). The IaaS provider doe not guarantee that the conumer will receive the amount of intance required; (ii) in the reervation market, intance can be reerved for longer future interval (typically greater than one year) by paying an upfront reervation fee. A the IaaS conumer ue reerved intance, he pay a dicounted uage fee (compared to the on-demand uage fee) for each uage charging period. The IaaS provider enure that reerved intance will be available whenever the IaaS conumer wihe to ue them within the reervation interval. Cloud Computing alo brought ome challenge for capacity planning. Firt, a capacity planner now ha acce to everal type of intance and market to build the IT infratructure. With o many option, the capacity planning algorithm may achieve better reult, but at the cot of higher complexity. Second, the capacity planner ha to deal with the uncertainty of future workload prediction, which i typically a very hard tak to accomplih. Thi tak i epecially hard for SaaS provider that have contract that may pan from one week to ome month and uer that may quit whenever they want, a an open ytem. It i hard to predict the real uage of the ytem by each tenant. Finally, it i alo a challenge to model the impact that capacity planning deciion may have on the buine. Impact on QoS of the ervice offered may lead to ervice level agreement (SLA) violation, which may lead to penaltie and bad

2 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY of 1.4% and 9.25%) and the mall number of SLA violation achieved by propoed heuritic. Fig. 1. A workload example reputation, or even looing important conumer. All thee apect turn capacity planning in the Cloud Computing context a non trivial problem. Conidering the growing number of application running in the cloud, whether academic or indutrial, it important to tudy capacity planning heuritic and trategie. A good capacity planning reerve expected well ued reource in the reervation market, in order to achieve cot reduction, intead of only uing the more expenive reource from the on-demand market. For low ued reource, the on-demand market might be the bet choice. Alo, IaaS provider enure that reerved reource are available whenever they are needed, contributing to improving the availability of the SaaS application being offered. Capacity planner can combine reource from the on-demand and reervation market in order to improve application QoS and cot reduction. Imagine an application with it varying reource demand, a preented in the curve of Figure 1. It i clear that if 32 intance are reerved, lot of intance will not be efficiently ued, which reult in wate of money. Certainly, the bet deciion i to reerve ome number of intance between 14 and 18 intance from the reervation market, and acquire more intance from the ondemand market when needed. Although the rationale behind thi idea i apparently very imple, in practice it i difficult to achieve uch a good heuritic, mainly becaue it i hard to predict the real demand of the application. Beide, there i the rik of having requet for intance not atified from the on-demand market. Thi work focu on the capacity planning for long future interval (e.g., one year), evaluating heuritic that ue a workload prediction to define how many intance mut be acquired from the reervation market. We propoe two heuritic baed on literature concept and compare them with other four heuritic, one of them being an optimal olution. Analying the reult we how the importance of performing a capacity planning, the improvement in the SaaS provider profit (mean value 1.1 Contribution and Structure of the Paper The major contribution of thi work are three-fold: (i) we propoe an utility model to guide and evaluate capacity planning. Our model conider the paya-you-go apect of Cloud Computing, the receipt of the SaaS provider and the cot related to offering a SaaS application; (ii) we propoe two capacity planning heuritic that combine uual literature concept, the utility model propoed, intance acquiition from the on-demand and reervation market and the uage of different reervation market. Our focu i on evaluating the combination of uch point on both imple propoed heuritic. One of the heuritic alo perform a imple evaluation of the poibility of uing intance of different type; (iii) we compare propoed heuritic to four reference heuritic uing imulation experiment and a ynthetic e-commerce workload baed on real world parameter [5] [6]. The ret of thi paper i organized a follow: Section 2 dicue the related work. Section 3 preent the utility model propoed. Section 4 preent the two capacity planning heuritic propoed. Section 5 preent the imulation environment ued in our experiment and Section 6 contain the evaluation of propoed heuritic. Finally, Section 7 dicue concluion and poible future reearch direction. 2 RELATED WORK Capacity planning tudie have preented throughout the year a et of tream in the literature, each with it particular feature. Recently, the tudy of elaticity olution wa highlighted [7]. A firt analyi can eparate tudie in two world: reactive and predictive approache [7]. Reactive approache act only after a condition i atified, while predictive approache anticipate ytem load to etimate the amount of neceary reource. Conidering workload prediction we can point longterm and hort-term capacity planning olution. On the one hand, a long-term capacity planning [8], [9], [1], [11] ue workload prediction for a long future interval of time (e.g., a year) and etimate the amount of computing reource needed to deliver the application during uch interval. In thi work, we aume that longterm capacity planning reult can guide the acquiition of intance at an IaaS provider reervation market. On the other hand, a hort-term capacity planning [12], [13], [14], [15], [16] ue workload prediction for managing reource for a future hort interval of time (e.g., an hour), optimiing the amount that will be acquired or releaed. The etimation of the amount of neceary reource can be baed on operational metric or buine metric. A capacity planning baed on operational metric focu on meeting operational metric target. Thee target

3 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY can be defined in term of availability [17], repone time [18], CPU uage, power conumption [7] or a combination of uch metric [19]. Uing only operational metric to plan an infratructure, without conidering metric uch a cot and receipt, can lead to an infratructure configuration that meet operational target, but that i an economically infeaible olution. In order to deal with thi problem, buine-driven IT management olution [1] aim at combining operational and buine metric in the deciion-making. Capacity planning olution baed on buine metric can conider infratructure cot [2] [21] [14] [15] [1] [11] [16], lo incurred due to conumer defection [8] [9], SLA violation [8] [9] [7] and buine profit/revenue [22] [23] [24] [25] [26] when planning IT infratructure. A more high level model, buine model enable the merge of operational metric like power conumption and buine metric [26]. Our tudy reemble other capacity planning tudie a we conider buine metric in the capacity planning. However, ome apect can be pointed to ditinguih our tudy from the other: (i) we captured the buine model of a real SaaS provider profit uing a linear utility function that combine the revenue for the different plan with different penaltie incurred due to SLA violation; (ii) it i not from our knowledge the exitence of tudie that combine profit evaluation and the capacity planning of SaaS provider uing intance acquired from different market of an IaaS provider; (iii) propoed heuritic combine thi utility model with concept of reource utilization and Queueing Theory to produce good reult. So, our work can be een a complementary to previou tudie. 3 UTILITY MODEL Utility [27] i a microeconomic concept ued to tate the preference of agent (i.e., ervice provider and their conumer), with higher value typically tating greater preference. Agent ue uch preference to guide their behavior: they attempt to achieve the outcome they mot prefer. A utility function map a pace of outcome onto utility value. A utility function can combine different apect and metric, implifying the evaluation and choice proce done by agent. The utility model propoed map the profit of a SaaS provider, obtained a a reult of offering an application, onto an utility value. A capacity planning agent can ue thi model to build a capacity plan that maximize the utility value, which tranlate to maximize the SaaS provider profit. Our utility model combine three main component: (i) the revenue obtained from charging conumer that ue the SaaS application; (ii) the cot of buying intance from a IaaS provider; (iii) penaltie related to SLA violation. 3.1 Revenue Model The utility model propoed conider that SaaS provider can offer one or many plan to their conumer, o that each conumer chooe the plan that bet fit it need and contract it in order to ue the SaaS application. A a reult of evaluating current SaaS provider, the revenue model developed aim at covering the main apect dicovered: (i) SaaS conumer are typically charged periodically (i.e., per month or year); (ii) each application ha it uage retriction pecified in the plan offered by the provider; (iii) a contract etablihed between a SaaS provider and a SaaS conumer define provider reimburement rule. A SaaS provider develop and offer an application A to a et U of SaaS conumer, U = {u 1, u 2,..., u U }. In order to offer thi application, the provider build a portfolio of plan P = {p 1, p 2,..., p P }, where each plan p j aim at meeting a demand of a pecific cla of conumer, o it expected that P < U. Each conumer u k u k U, chooe and ign a contract related to a plan p j p j P, in order to ue application A. After igning the contract of plan p j, a conumer u k can ue application A for an interval [n b k, ne k ], where n e k nb k (for example, if a plan p j i emiannual then n e k nb k = 6 month). For implicity, all plan offered by a SaaS provider are accounted by uing the ame fixed uage period duration (e.g., one month) and period n with value 1 mark the launch of the application. Alo, we conider that new conumer can only enter the ytem jut before a new uage period n tart. A time pae, n i incremented to indicate current uage period. By the time u k ign the contract (i.e., in n b k ), the SaaS provider mut configure and deploy application A to erve it pecific conumer. To thi end, the SaaS conumer u k can be requeted to pay a configuration fee Ij b. Thi fee depend on the plan p j contracted. During the term of p j, a well a in equential interval in which the conumer renew the contract, the configuration fee Ij b i not charged again. The provider will only charge thi fee again if the conumer change the contracted plan. The function i b : N + {, Ij b } given by i b k(n) = { I b j if n = n b k otherwie define if conumer u k mut pay a configuration fee in an uage period n. In order to ue application A during each uage period n, the conumer u k mut pay an uage fee I j to the SaaS provider. Thi fee hould be enough to cover SaaS provider cot of acquiring neceary reource to offer application A to conumer u k. The fee I j depend on the plan p j contracted by conumer u k. Regardle if the conumer remain in her plan or change to a new one, the fee I j i alway charged. The function i u : N + {, I j } given by i u k (n) = { Ij + e j,n if n b k n ne k otherwie define the uage fee payed by a conumer u k in an uage period n. (1) (2)

4 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY Each plan p j define the et of reource that can be ued by a SaaS conumer while uing application A. For example, it i common that during an uage period n a conumer u k ue a certain amount of torage and tranfer a certain amount of data over the network. Each plan p j define limit for each computing reource a conumer can ue during an uage period n. If during an uage period n a conumer u k exceed uch limit, the SaaS provider charge u k an extra fee e j,n. Thi extra fee i proportional to the amount of extra reource ued by the conumer. Finally, a plan p j i aociated with a ervice level agreement (SLA), repreented here a SLA j. For implicity, a SLA i defined by the tuple < A MIN, T MAX >, which value mut apply for each uage period n. A MIN repreent the lowet required availability for application A and T MAX repreent a repone time percentile accepted for requet proceing (e.g., 95% of requet mut be proceed within 8 econd). According to SaaS provider buine evaluation, it may be feaible to define a SLA for each plan p j in order to offer a higher quality of ervice to plan that contribute more to the buine. Furthermore, if the SaaS provider violate SLA j, a function M j (n) indicate, for a certain uage period n, the penalty that the provider mut pay to the correponding conumer. The value of the penalty i proportional to the intenity of the violation and may be defined differently for each plan offered. Penaltie payment i included in the cot model preented in Section 3.2. Given the above apect of plan, it neceary to define how the SaaS provider charge each conumer u k. During an uage period n the SaaS provider mut do the accounting of reource conumption for each conumer u k. With thi accounting, the provider calculate the amount of reource ued inide plan limit and the amount of extra reource ued. The revenue obtained by a SaaS provider from the payment of a conumer u k, in any period n, i given a a combination of uage and configuration fee: i k (n) = i b k(n) + i u k (n) (3) Evaluating the et U of conumer that contracted application A, we can calculate the total revenue obtained by a SaaS provider in an uage period n a: i(n) = k= U k=1, u k U i k (n) (4) The revenue obtained by a SaaS provider during an interval D of uage period, where D = [n b, n e ] and n e n b, i given by the function ι : [n b, n e ] R +, where n b, n e N + : ι(d) = n e n=n b i(n) (5) We can ue the revenue model preented above to calculate the revenue obtained by a SaaS provider in a pat interval D, or even to etimate the revenue in a future interval D. In thi cae, it neceary to characterize the future et P of SaaS provider plan and to etimate the future workload that will be ubmitted by a et U of etimated future conumer. 3.2 Cot Model A a SaaS provider acquire computing reource from an IaaS provider to build it IT infratructure, we conider that the following cot exit: (i) cot related to uing acquired reource; (ii) cot related to reerving reource. Beide thee cot, a SaaS provider pend money a a reult of SLA violation, which may lead to the payment of penaltie to SaaS conumer. Each IaaS provider ha a et O of reource clae being offered. Thee reource clae can be, for example: (i) virtual intance; (ii) torage reource; (iii) data tranfer reource. Each reource cla o o O, define a et S o of reource type offered in thi cla. Each reource type S o, i aociated with an uage cot c, which indicate the minimal charge unit of the type. For example, conidering the Amazon EC2 1 ervice, a mall intance ( = mall and o = virtual intance) ha an uage cot c mall = $, 6 2 for each hour of uage. We conider that all reource from the ame cla o are charged according to the ame minimal charge unit (i.e., for each hour). The IaaS provider ha an accounting ytem that regiter, for each period n and for each SaaS provider, the amount of reource ued, a well a their type. Thi ytem i then queried to report total reource conumption. For each reource type and each period n, counter a n are incremented every time the SaaS provider ue a reource of type within period n. For example, uppoe that during the firt accounting period, n = 1, a large intance ( = large) ha been ued for 1 hour. In thi cenario, the counter a 1 large would be 1. The cot of the SaaS provider aociated with IaaS reource uage in a period n, whether obtained in the on-demand or reervation market, i defined by the function ca : N + R + given by: ca(n) = o O [ S o a n c Even the ue of reerved reource can be accounted in the equation above ince thoe reource are related to a type and a uage cot c repreenting the fee practiced in the reervation market. Beide the cot related to reource uage, the SaaS provider ha another cot related to the act of reerving Amazon EC2 ervice value in 213. ] (6)

5 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY reource in advance from the IaaS provider. A reervation of reource of type S o, i alway aociated with an amount of reource reerved (r ), an upfront reervation fee (f ) and the interval in which uch reource will be available for ue. Thu, we can define a reervation contract a: V =< o,, r, f, n b, n e > where n b and n e indicate, repectively, the period at which reource are available and the time limit to ue uch reource. It i noteworthy that the interval [n b, n e ] hould be defined conidering the period in which the SaaS provider will be uing reource to offer it application. The et γ repreent the et of reervation contract etablihed between the SaaS provider and the IaaS provider. It important to remember that current IaaS provider only offer the poibility of reerving proceing reource (i.e., virtual intance), but the cot model propoed here i flexible to conider other clae of reource that may be available for reervation in the future. Upfront reervation fee paid by the SaaS provider can be amortized over the interval [n b, n e ]. Thu, each period n ha a cot component related to the amortization of the reervation contract defined in γ. Thi cot component can be calculated uing the function cv : N + R + given by: { f r <o,,r,f,n cv(n) = b,ne > γ if n b n e nb n n e otherwie (7) Defined the cot component related to reource uage, ca(n), and reource reervation, cv(n), the total cot of a SaaS provider in a period n can be calculated uing the function c : N + R + given by: etimate the cot in a future interval D. In thi cae, it neceary to etimate the future workload and reource uage from an IaaS provider in each period n. 3.3 Utility Model The utility function 3 propoed in thi work i defined in term of the profit achieved by a SaaS provider. Once the revenue model and the cot model are defined the utility function of a SaaS provider in an interval D, where D = [n b, n e ] and n e n b, i defined by the function υ : [n b, n e ] R, where n b, n e N + : υ(d) = ι(d) α(d) (1) We can ue thi utility function to evaluate the utility obtained by a SaaS provider in a pat interval D, and alo to etimate the future utility of a SaaS provider (in a buine-driven capacity planning). During the capacity planning, the function υ allow an agent to etimate SaaS provider utility over a et of poible capacity plan and elect the mot beneficial plan to the buine. 4 CAPACITY PLANNING HEURISTICS We propoe two capacity planning heuritic: (i) one baed on intance utilization (UT); and (ii) one baed on Queueing Theory (QN). Both heuritic receive a input the prediction of a future workload for a time interval D, where D i the interval being planned. Thi prediction can be obtained from hitorical data of the SaaS application execution. Both heuritic conider more than one reervation market, each market offering a better cot according to reerved intance uage. Both heuritic ue the utility model and the workload prediction to produce a capacity plan indicating the amount and type of intance to reerve in each reervation market. c(n) = ca(n) + cv(n) + p(n) (8) where p(n) = u k U M j(n) repreent all penaltie paid by a SaaS provider to it conumer in a period n. A provider mut pay a penalty to a conumer u k whenever SLA j, etablihed in the contracted plan p j, i violated. A SLA violation, a mentioned in Section 3.1, i related to availability or repone time violation, according to retriction etablihed in the plan p j contracted by the conumer. The function M j (n) can be ued to model different penaltie value according to violation interval or to model ingle penalty value. Finally, it poible to evaluate the total cot of a SaaS provider in an interval D, where D = [n b, n e ] and n e n b, uing the function α : [n b, n e ] R +, where n b, n e N + : n e α(d) = c(n) (9) n=n b We can ue the cot model preented here to calculate a SaaS provider cot in a pat interval D, or even to 4.1 Heuritic baed on Intance Utilization - UT Thi heuritic focu on evaluating a trace of intance uage. The trace indicate the amount of intance ued and the correponding amount of hour during which thee intance were ued (e.g., a SaaS provider ued 19 intance of type mall for 1 hour and 5 intance of type mall for 15 hour). Thi trace mut be conitent with future workload prediction. UT ue thi trace a input of the algorithm preented in Algorithm 1. If a trace of intance uage doe not exit, one can be produced by imulating predicted workload proceing. We conider that predicted workload proceing imulation ue a workload prediction compoed of requet arrival time and proceing demand. The proceing demand etimation conider a bae intance. In imulation, a Dynamic Proviioning Sytem (DPS) periodically (i.e., hourly) acquire on-demand intance from an IaaS provider. Simulated DPS i baed on the behavior of a 3 A more detailed verion of the utility model can be found at davidcmm/utilitymodel

6 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY real DPS. We aume that the DPS chooe the correct type and amount of intance in order to meet SLA etablihed between the SaaS provider and it client. After imulation, for example, a trace may indicate that 2 intance were ued for 3 hour and 3 intance were ued for 5 hour. Once we have a trace of intance uage, we have to adapt it for Algorithm 1. We conider that if 2 intance were ued for 2 hour and 3 intance were ued for 2 hour, in fact, 2 intance were ued for 4 hour. When 3 intance are acquired to proce the workload we conider that we can keep the 2 intance, previouly acquired, and add other intance to meet workload demand. In thi example, Algorithm 1 would receive two tuple indicating intance uage: 4, 2, indicating that 2 intance were ued for 4 hour, and 2, 3, indicating that 3 intance were ued for 2 hour. UT ue the cot model propoed in Section 3.2 and intance uage to plan the infratructure. For each intance type and each reervation market, UT calculate the minimal utilization rate that make a reerved intance cheaper than an on-demand intance (line 3). An utilization rate repreent the percentage of a time interval (e.g., 5% of the reervation interval) in which the intance i ued. Such rate i calculated baed on uage cot (c ) of on-demand and reervation market and on reervation fee (f ). For example, UT can find that a mall intance hould be ued for at leat 5% of the reervation interval in reervationm arket1 in order to be cheaper than an on-demand mall intance. Alo, UT can find that a mall intance hould have an utilization rate of at leat 7% in reervationm arket2. Uing thee information, UT ort reervation market from the one with the lowet minimal utilization rate to the one with the highet utilization rate (line 4). In the next tep, UT calculate, for each intance type and amount of intance ued (amount), obtained from the trace, the average utilization rate of uch intance (line 7). UT look for the reervation market with greater minimal utilization rate that i lower than or equal to the average intance utilization rate (line 8 to 12). Thi market i elected a betm arket (line 1) and will be ued to reerve intance. For example, uppoe that reervationm arket1 ha a minimal utilization rate of 5% and reervationm arket2 ha a minimal utilization rate of 7%. Alo, uppoe that the average utilization rate for 1 intance of type mall i 9%. Analying uch value, UT reerve thee intance in reervationm arket2 for the interval being planned. After chooing the market that offer the bet cot for reerving amount intance of type, UT evaluate the amount of intance to reerve. Intance of ame type can be reerved in different reervation market. To conider thi, UT calculate the amount of intance of type to reerve in betm arket a the difference between current amount of intance being evaluated (amount) and the total amount of intance of type already reerved (line 13 and 14). After evaluating the whole et of intance uage data, UT ha a capacity plan (capacityp lan) containing the type and amount of intance to reerve in each reervation market (line 17). Algorithm 1. UT reervation algorithm. 1: function UTRESERVATION Input: Set (con ) containing tuple uage, amount indicating the amount of hour ued by each amount of intance of type acquired. Tuple are orted in acending order of amount of intance ued. Input: A et (reervationm arket) containing the reervation market that can be ued to reerve intance. Output: UT return a capacity plan (capacityp lan) containing the type, amount of intance to be reerved and reervation market to be ued. 2: for all in type 1, type 2,..., type n do 3: Calculate minimal utilization rate (minimalutilization market ) for each reervation market in market 4: Sort market, in acending order, according to minimalutilization market 5: totalreerved 6: for all uage, amount in con do 7: intanceutilization = uage / (planning interval length in hour); 8: for all market in reervationm arket do 9: if intanceu tilization minimalutilization market then 1: betm arket reervationm arket; 11: end if 12: end for 13: capacityp lan[betm arket][]+ = amount totalreerved 14: totalreerved+ = amount totalreerved; 15: end for 16: end for 17: return capacityp lan 18: end function 4.2 Heuritic baed on Queue Network - QN QN heuritic ue Queueing Theory concept [28] uch a mean arrival rate and mean ervice time. Such concept are ued to model the IT infratructure that will be ued to proce the workload. We conider that intance are ued to proce requet and that queue are formed according to the workload ubmitted. The tep of the algorithm are preented in Algorithm 2. Intead of uing information of each requet to be ubmitted in predicted workload, QN ue a workload ummary. Thi ummary contain etimation for each hour of the future workload. Each hour etimation i compoed of: requet mean arrival rate ( λ); requet mean ervice time ( S); mean number of uer (N); uer mean think time (Z); intance utilization rate target (ρ). The utilization rate target ρ repreent the maximum utilization expected for an intance, for example, a maximum utilization of 7%. The workload ummary can

7 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY be etimated conidering hitorical workload trace and workload growth etimate. Uing the workload ummary (epecially λ and S), QN etimate the total CPU demand (T ) needed to proce future workload (line 2). Alo, QN conider the cot model propoed in Section 3.2 to find the minimal utilization rate (minimalutilization market ) that make a reerved intance cheaper than an on-demand intance. To do thi, QN aociate uage cot (c ) of on-demand and reervation market and reervation fee (f ) to find minimalutilization market (line 5). Uing T and minimalutilization market, QN calculate the larget number of reerved intance of type that could be ued to proce the workload (line 6 to 1). Thi value i ued to limit the amount of intance in the plan that will be evaluated. For example, uppoe that for a certain workload MAX mall = 1 and MAX large = 3. QN evaluate all 44 capacity plan reulting of combination containing from to 1 mall intance and from to 3 large intance. After chooing the plan to evaluate, QN etimate the utility of each of thee plan (line 14 to 33). For each hour of the predicted workload, QN determine the amount of intance to be ued from the on-demand and reervation market. Firt, QN ditribute arriving requet (according to mean arrival rate λ) in reerved intance calculating the amount of incoming requet that can be proceed without violating the repone time etablihed in the SLA and without exceeding intance utilization rate target ρ (line 17 to 2). If not all requet could be proceed uing reerved intance, QN aume that on-demand intance can be acquired. The throughput of thee intance i ued to find the amount of on-demand intance needed to proce remaining requet (line 21 and 22). QN alo conider a rik (line 23) that the on-demand market denie ervice (i.e., can not provide the amount of ondemand intance needed). In thi cae, ome requet are not be proceed and the SLA might be violated (line 24). We conider that the on-demand market can deny ervice for two reaon: (i) the SaaS provider ha reached the limit of intance that can be acquired from the IaaS provider; (ii) the IaaS provider doe not have enough intance to offer 4. After etimating the amount of intance to be ued from the on-demand and reervation market, QN look for the bet reervation market to buy uch intance (line 26 to 28). QN calculate the cot of acquiring reerved intance in each reervation market uing the cot model propoed in Section 3.2. Then, QN chooe the market that give the lowet cot. Finally, QN calculate an etimated utility value for the capacity plan being evaluated uing the utility model preented in Section 3.3 (line 29). After etimating the utility of thee plan, QN check if it i the plan with 4 Such rik of intance denial i real for current player of IaaS, a can be een for example at Amazon AWS greater utility (line 3 to 32) in order to return it a the plan to be ued in the infratructure (line 34). Algorithm 2. QN reervation algorithm. 1: function QNRESERVATION Input: A et (reervationm arket) containing the reervation market that can be ued to reerve intance Input: A ummary (predictedw orkload) of the predicted workload for an interval D containing, for each hour of the predicted workload: λ, S, N, Z Input: Intance utilization target: ρ Output: QN return a capacity plan (capacityp lan) containing the type, amount of intance to be reerved and reervation market to be ued. 2: T = planning interval hour m=1 S m λ m 3: for all market in reervationm arket do 4: for all in type 1, type 2,..., type n do 5: Calculate minimalutilization market baed on c on demand, c market, f 6: demand market T/(minimalUtilization market planning interval hour) 7: end for 8: if demand market MAX then 9: MAX demand market 1: end if 11: end for 12: poiblep lan build all poible capacity plan with amount of intance from to MAX 13: capacityp lan null 14: for all plan poiblep lan do 15: utility[plan] 16: for all hour in predictedw orkload do 17: for all in type 1, type 2,..., type n do 18: rereq the amount of requet proceed uing reerved intance (intance utilization limited to ρ) 19: reervedhour + = rereq S m 2: end for 21: ondemreq the amount of requet proceed uing on-demand intance 22: ondemandhour+ = ondemreq S m 23: notp roceed+ = the amount of requet not proceed in current hour 24: violation+ = the amount of requet that violated the SLA in current hour 25: end for 26: for all in type 1, type 2,..., type n do 27: Chooe market market that give the lowet cot for reervedhour 28: end for 29: utility[plan] = etimatereceipt() etimatecot(reervedhour, ondemandhour) etimatep enaltie(notp roceed, violation) 3: if utility[plan] utility[capacityp lan] then 31: capacityp lan plan 32: end if 33: end for

8 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY : return capacityp lan 35: end function 5 SIMULATOR 5.1 Simulation Model Propoed heuritic were evaluated through imulation experiment. Exitent imulator, uch a CloudSim 5, were not ued for two reaon: (i) the difficulty of adapting them to upport the utility model propoed (Section 3); (ii) the amount of detail that are not the focu of thi work (e.g., virtual machine allocation model and energy conumption model). Intead, we developed an extenion 6 of the SaaSim framework 7 [29] conidering Verification & Validation technique propoed by [3]. Our imulation model conider a SaaS provider offering one application to it conumer. The SaaS provider IT infratructure i compoed of virtual intance acquired from an IaaS provider. The imulation ha two main phae: (i) capacity planning, thi phae conider one heuritic to build a capacity plan; and (ii) workload execution, thi phae procee the workload conidering intance reerved in the capacity planning phae and extra on-demand intance that might be acquired. In the firt phae, a capacity planning heuritic conider a workload prediction for a future interval D to build the capacity plan. A perfect workload predictor might not be ued in a real cenario, o to model the predictor preciion we conider a prediction error related to the amount of SaaS client ubmitting requet to a SaaS provider. For example, an error of 1% mean that if the real workload i compoed of 1 client, the predictor etimate a workload compoed of 11 client. On the other hand, an error of 1% mean that if the real workload i compoed of 1 client, the predictor etimate a workload compoed of 9 client. The econd phae aim at evaluating the capacity planning performed in the firt phae. We imulate workload proceing uing reerved and on-demand intance acquired from an IaaS provider. In the end of the imulation, we calculate the utility obtained by the SaaS provider a a reult of uing the capacity plan produced. It important to remember that the workload of each SaaS conumer i an aggregation of requet ubmitted by end uer. We conider that a requet arrive to be proceed, a weighted round-robin load balancer ditribute them in the available intance. The round-robin policy ued conider the amount of virtual CPU in each intance and ditribute requet proportionally to uch amount of CPU (i.e., an intance with 2 CPU receive the double of requet received by a one CPU intance). Each intance proce requet according to a conolidated model [31]. An intance can proce an amount of m requet in parallel, controlled by a et of m token Available at 7 Available at Fig. 2. Sytem Model: general view of queue and requet proceing that repreent available thread (Figure 2). A a requet arrive, it acquire a token and enter the proceing queue. If no token are available, the requet wait at a backlog queue, which work in a firt-come firt-erved policy (FCFS), until a token i available. If backlog i full, the requet i dicarded. The proceing queue work in a time haring policy 8. Beide proceing demand, each requet ha a data tranfer demand. Alo, each SaaS conumer ha a torage demand related to hoting it application and uer record. We aume that the IaaS provider meet thee two demand regardle of the choice and negotiation of intance. The aociated cot i calculated according to the model preented in Section 3.2. Web application typically preent a variable workload [32], o a DPS i ued to control the amount of intance in the hort-term. We conider an unrealitic perfect DPS that know the future workload and ue thi information to buy intance from the IaaS provider. Although thi implification i unrealitic, it i important to focu on evaluating the quality of the capacity planning performed. 5.2 Simulation Model Intance A preliminary full factorial deign pointed workload prediction error and capacity planning heuritic a the main factor that influence SaaS provider profit. Experiment conducted later alo pointed the on-demand denial of ervice rik a another important factor. Our experiment tried to explore everal combination of uch factor, while other variable received fixed value. 8 A requet can ue the CPU for an interval, typically very mall, and then the CPU i allocated to another requet in the proceing queue. Thu, all requet are imultaneouly proceed and delay related to contention are captured.

9 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY TABLE 1 SaaS provider monthly fee Plan Price Bronze $24.95 Gold $79.95 Diamond $ Our analyi i not exhautive and different level could be ued for thee fixed variable, but we are confident that our approach wa enough to evaluate the trend of heuritic and get idea of future work. Well-known IaaS and SaaS provider were ued a the bai to intantiate the utility model propoed in Section 3. For the revenue model, three plan offered by BigCommerce in 211 were conidered (Table 1): Bronze, Gold and Diamond. BigCommerce charge it conumer monthly (n i equal to 1 month). A contribution margin of 3% wa choen for each plan according to what i practiced in the market 9. Regarding SLA, the availability (A MIN ) and repone time limit (T MAX ) were intantiated in range. We conider that the SaaS provider etablihe a repone time limit (T MAX ) of 2 econd. If requet proceing take more than 2 econd, we conider that thee requet were lot. If le than.1% of the requet are lot, due to repone time or availability problem, the SaaS provider doe not pay any penalty to it conumer. If le than 1% of the requet are lot, the provider pay a penalty correponding to 25% of the value of the plan contracted. If le than 5% of the requet are lot, the provider pay a penalty correponding to 5% of the value of the plan. Finally, if more than 5% of the requet are lot, the penalty correpond to the whole value of the contract. Regarding the cot model, the IaaS provider imulated wa baed on the price of the Amazon EC2 ervice in 213. Three intance type were conidered: mall (1 virtual CPU), large (2 virtual CPU) and xlarge (4 virtual CPU). The only difference conidered between thee three type i the amount of virtual CPU. After an intance i requeted from an IaaS provider there i a period, conidered here a 5 minute [21], to tart the intance and the application. We alo conidered three reervation market: a light utilization, a medium utilization and a heavy utilization. Each of thi market offer a better cot according to the uage of reerved intance. Uage cot of uch intance (Table 2), per hour, and upfront reervation fee (Table 3) are preented. We conider that one of the reaon that the ondemand market denie ervice i becaue the IaaS provider doe not have enough intance to offer. To model uch apect, an on-demand denial of ervice rik, which repreent the probability of not being attended when requiring an intance from the on-demand market, i conidered. We conider that the capacity planning inter- 9 qpmd.html TABLE 2 Virtual intance uage price for each IaaS provider market IaaS provider market Small Large Xlarge On-demand $.6 $.24 $.48 Light $.34 $.136 $.271 Medium $.21 $.84 $.168 Heavy $.14 $.56 $.112 TABLE 3 Virtual intance upfront fee for a one year reervation IaaS provider market Small Large Xlarge Light $61 $243 $486 Medium $139 $554 $118 Heavy $169 $676 $1352 val D ha three type of interval according to workload variation over the interval [5]. For each type of interval we aociate a denial of ervice rik, and interval with higher workload preent a higher denial of ervice rik. We conider two cenario of rik: (i) rik of 1%, 5% and 1%; (ii) rik of 5%, 1% and 5%. The firt cenario repreent a IaaS provider that care about it reputation and the quality of the ervice offered, while the econd cenario repreent a provider that doe not care o much about it reputation. We imulated a workload correponding to an interval of 1 year (i.e., D = 1 year). A total of 1 SaaS conumer were uniformly ditributed among the three plan offered by the SaaS provider. Workload prediction error initially conidered were 2%, % and 2%. For each combination of thee variable level a total of 7 different ynthetic workload were imulated to calculate confidence interval of 95%. Arlitt et al. [5] how that an e-commerce workload ha ome peak during the day (between 9: and 21:) and the week (ome day have more and other le load than typical day). A workload peak correpond to twice the mean amount of requet, while lighter period correpond to 5% of the mean amount of requet. Thee invariant were combined with SaaS plan price, contribution margin and uage limit to calculate the requet arrival rate of each SaaS provider plan during an year (Table 4). Moreover, ome pecial event (e.g., Chritma) caue peak load compared to typical week [5]. Workload ued in imulation were generated by GEIST [33], while workload prediction were derived from thee workload. GEIST generate a workload auming a Poion ditribution a the marginal ditribution of the arrival proce and then add multifractal and elf-imilarity propertie. Finally, we conidered requet proceing demand baed on [6].

10 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY TABLE 4 Requet arrival rate for a typical week of the workload TABLE 5 T-tet and Wilcoxon tet reult Workload day Bronze Gold Diamond Typical day.58 req/.176 req/.65 req/ Peak day.117 req/.35 req/ 1.3 req/ Light day.29 req/.9 req/.325 req/ 6 EVALUATION QN and UT heuritic were compared to four reference trategie/heuritic: 1) one baeline trategy that only ue intance acquired from the on-demand market - named ON; 2) one heuritic that reerve 2% of the intance needed to proce the workload peak, uing only mall intance from the heavy utilization reervation market - named ST 1 ; 3) a heuritic (COHR ), baed on [1], that ue the three reervation market conidered and a prediction of the amount of intance to be ued. It tet a et of poible capacity plan containing from to an upper bound amount of intance in order to chooe the capacity plan with the lowet etimated cot; 4) an optimal trategy that know the exact amount of intance that will be ued by the DPS to proce the future workload - named OP. It tet a et of capacity plan containing from the mallet to the highet amount of intance that will be ued by the DPS and chooe the capacity plan with the bet etimated utility value. Our analyi focu on two metric: 1) the SaaS provider utility (Section 3.3); and 2) the gain, in percentage, obtained by each heuritic in comparion to the utility obtained by our baeline trategy (ON). Thi gain i given by: gain(υ A (D), υ ON (D)) = 1 (υ A(D) υ ON (D)) υ ON (D) (11) Firt, we verify the feaibility of the capacity planning performed by evaluated heuritic/trategie. The null hypothei υ ST (D) = υ UT (D) = υ QN (D) = υ COHR (D) = υ ON (D) wa rejected according to the analyi of variance (ANOVA) performed with a p- value of 1.952e 12. A pot-hoc analyi wa performed to evaluate if any heuritic obtained utilitie imilar to the one obtained by ON. We concluded that υ UT (D), υ QN (D), υ COHR (D), υ ST (D) > υ ON (D). Evaluated heuritic preent different gain from each other, and different from zero, o they increae the utility of the SaaS provider in comparion to uing ON. According to Shapiro-Wilk normality tet, heuritic utilitie are normally ditributed while gain are not. So, in order to compare heuritic, we performed Student t-tet for heuritic utilitie and Wilcoxon igned-rank tet for gain. Analying the reult of uch tet (Table 5) we could oberve that QN and UT alway preent the 1 ST heuritic reerve 2% of the amount of intance needed to proce the workload peak ince 2% i an expected utilization for an infratructure that i planned for a workload peak [2]. Prediction Error Rik of 1%, 5% and 1% Rik of 5%, 1% and 5% -2% UT > QN > QN > UT > ST COHR ST > COHR % UT > QN > QN > UT > ST > COHR COHR > ST 2% QN > UT > QN > UT > ST > COHR ST > COHR TABLE 6 Average gain for different prediction error level Heuritic Prediction Error of -2% Prediction Error of % Prediction Error of 2% QN [8.83%; 9.5%] [1.2%; 1.43%] [1.27%; 1.36%] UT [1.23%; 1.28%] [1.64%; 1.68%] [9.24%; 9.32%] ST [7.7%; 7.83%] [8.89%; 8.97%] [8.99%; 9.9%] COHR [4.64%; 4.74%] [7.12%; 8.9%] [4.21%; 4.31%] bet reult. QN perform better than the other heuritic when the on-demand market rik or the workload prediction error increae. QN i the only heuritic that ue directly the on-demand market rik, o a the rik increae QN perceive that the on-demand market can not be truted to provide intance and trie to reerve more intance (Figure 3) in order to avoid denying ervice to application end uer. However, other heuritic do not notice uch need in the cenario imulated and do not increae the amount of intance to be reerved. Since the capacity planning of evaluated heuritic increaed the SaaS provider utility in comparion to the ON trategy, the next tep of the pot-hoc analyi conited of quantifying the gain obtained. Table 6 preent the gain obtained by each heuritic at different workload prediction error for the cenario of rik of 1%, 5% and 1%. Although the bet (1.66% - error of %) and wort (4.5% - error of 2%) average gain obtained eem to be mall, they can repreent larger aving to a SaaS provider a higher i the profit of the SaaS provider. The difference in heuritic gain can be explained analying reervation, preented in Figure 3, and intance utilization (i.e., percentage of the reervation interval in which the intance wa ued), preented in Figure 4. We can oberve that QN and UT intance were reerved in two market (heavy and light utilization) and that, in both market, intance were very ued. Since the lowet expected utilization for light market i 28%, for medium i 5% and for heavy i 75%, reerved intance were cheaper than on-demand intance. UT reerved a larger amount of well ued intance in the heavy market, thu obtaining the bet cot reduction and greater utilitie. QN obtained good cot reduction reerving different intance type (i.e., mall, large and xlarge). QN variation in intance type reduced the abolute amount of intance reerved and increaed

11 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY Reerved CPU 3 2 Type large mall xlarge Reerved CPU 3 2 Type large mall xlarge 1 1 COHR' QN ST UT Heuritic COHR' QN ST UT Heuritic (a) Rik of 1%, 5% and 1% Fig. 3. Intance reerved by each heuritic for a prediction error of % (b) Rik of 5%, 1% and 5% their uage. A expected, ST heuritic obtained cot reduction in comparion to ON ince mall reerved intance were well ued. However, more intance could be reerved intead of being acquired from the on-demand market in order to achieve better cot reduction. COHR heuritic reerved intance were alo well ued, but more intance could be reerved. Moreover, in the evaluated cenario COHR choice of reervation market could be improved (e.g., intance that were reerved in the light market could be reerved in the medium or heavy market for better cot reduction and utility improvement). By analying the optimal heuritic (OP) reult, we could oberve that OP obtained average gain of 1.72% and 11.51% for rik of 1%, 5%, 1% and rik of 5%, 1%, 5%, repectively 11. In order to compare OP with other heuritic, we computed an efficiency a the diviion of the gain obtained by each heuritic and the gain obtained by the OP heuritic. Comparing heuritic and OP for workload prediction error of % (the bet cenario for heuritic), UT achieve an efficiency of 99.42% (±.16%) for rik of 1%, 5%, 1% and QN achieve an efficiency of 96.19% (±1.8%) for rik of 5%, 1%, 5%. Thee value were calculated with a confidence interval of 95%. So, in uch cenario QN and UT achieve utilitie that are cloe to the utilitie obtained by OP. Table 7 preent the efficiencie achieved by QN, UT and ST heuritic conidering the whole et of cenario imulated. By analying uch efficiencie, we can oberve that a the on-demand rik increae UT and ST are the heuritic motly affected. In uch cenario, improvement in the heuritic can be invetigated in order to obtain greater gain and efficiencie. In all cenario the wort percentage of requet lot were.47% for rik 1%, 5% and 1% and.5% for rik 5%, 1%, 5%. Finally, conidering the difficulty in workload predic- 11 Confidence interval are [1.76%; 1.747%] for rik of 1%, 5% and 1% and [9.37%; %] for rik of 5%, 1%, 5%. Heuritic TABLE 7 Heuritic Average Efficiencie Rik of 1%, 5% and 1% Rik of 5%, 1% and 5% QN [ %; %] [74.132%; %] UT [85.553%; %] [ %; %] ST [ %; %] [ %; %] tion, we performed a enitivity analyi of the workload prediction error (Figure 5). Thi analyi attempted to reflect the poibility of uing predictor that reult in different prediction error. We conidered the following prediction error: 4%, 2%, %, 2% and 4%. A expected, the analyi demontrated that the reduction of the workload prediction error improve the gain obtained by evaluated heuritic. Alo, the QN heuritic deal better with poitive prediction error (i.e., overetimating the workload) due to it more conervative prediction. Thi i an important concluion ince provider may try to overetimate intance conumption in order to reduce the rik of denying ervice to end uer. For thee provider, QN i a better choice. 6.1 Dicuion about the heuritic There are ome reaon why one heuritic make better deciion than other. Following we dicu ome of them. Firtly, ON doe not ue reerved intance, which may reduce it chance of being the bet in term of cot. Obviouly, at leat one intance mut be alway allocated to the application, otherwie the application would be unavailable. A reerved intance that i ued all the time i cheaper than an on-demand intance. Secondly, ST i a very imple heuritic that conider only peak load to make thi capacity planning deciion. On the oppoite, QN and UT heuritic conider detail of the load hitory, uch a average demand, waiting

12 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY type LARGE SMALL XLARGE type SMALL Heavy Light On demand Heavy Light On demand Utilization.5 Utilization Intance Intance (a) QN (b) UT type SMALL type LARGE SMALL XLARGE Heavy On demand Heavy Light Utilization Utilization Medium 2 3 On demand Intance Intance (c) ST (d) COHR Fig. 4. Intance utilization for a workload prediction error of % and rik of 1%, 5% and 1% time, reource uage, etc. With more detailed information it i poible to make better deciion. For intance, if the peak load i 2 time greater than the average load and it happen jut for a couple of minute during the year, ST will make a bad deciion, allocating far more node than really needed. QN and UT are able to identify uch urge, making deciion more appropriate conidering the workload hitory pattern. Beide, both QN and UT have a kind of what-if engine inide, which imulate deciion made by the DPS conidering the pat workload. With thi engine QN and UT may earch for the bet capacity planning according to the buine utility value. ST doe not conider different poibilitie, it i kind of determinitic, baed only on the previou peak load and on mall intance. QN conider the on-demand market rik, o a the rik increae QN trie to reerve more intance, almot keeping the gain obtained (Figure 5b) while other heuritic obtain lower utilitie. Thi indicate that it i important to conider thi rik, epecially if it i high. COHR doe not conider the on-demand market rik and adaptation performed to verify cot improvement of exchanging mall intance for large or xlarge intance reulted in intance from the heavy market with utilization lower than the threhold of 75%, which i ineficient. Finally, QN and UT are le efficient than OP mainly due to prediction error. For intance, UT with no prediction error lead to an utility very imilar to the optimal. Same occur with QN.

13 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY Gain in comparion to ON heuritic COHR' QN ST UT Gain in comparion to ON heuritic COHR' QN ST UT Prediction Error (%) Prediction Error (%) (a) Rik of 1%, 5% and 1% Fig. 5. Senitivity analyi of workload prediction error (b) Rik of 5%, 1% and 5% 6.2 Validity Threat In order to enable the invetigation of the propoed problem ome implification were done, reulting in validity threat. Regarding external validity, a ynthetic e-commerce workload wa ued. Requet arrival were generated uing a outdated workload generator (GEIST) [33] ince more recent workload generator baed on recent workload tudie were not found. Although our utility model cover many IaaS and SaaS provider buine model, our experiment were baed on information of one IaaS provider and one SaaS provider and do not account for enibility of their cot choice. Regarding contruction validity, we modeled the SaaS application a a black box ingle tier application and uer eion were not conidered. 7 CONCLUSIONS AND FUTURE WORK Analying our imulation experiment uing ynthetic e-commerce workload we demontrated that capacity planning hould not be neglected when offering a SaaS application deployed at intance acquired from an IaaS provider. We developed an utility model that conider buine apect related to offering a SaaS application. Thi model guide the capacity planning performed by propoed heuritic, QN and UT. Propoed heuritic were compared to other three olution: (i) a baeline trategy that ue only on-demand intance (ON); (ii) a heuritic (COHR ) baed on [1]; and (iii) a heuritic that conider workload peak to determine the amount of intance to reerve (ST). Analying our reult, all heuritic improve SaaS provider utility in comparion to ON. QN and UT preent the bet reult, improving SaaS provider utility, on average, by 1.4% and 9.25%, repectively. Alo, uch heuritic loe.5% of the requet in the wort cae. Our enitivity analyi demontrated that workload prediction error influence the reult obtained by evaluated heuritic. Large SaaS provider tend to have huge amount of hitorical data and invet in good prediction technique. A a conequence, they get mall prediction error and achieve better capacity planning reult. However, maller SaaS provider may not have acce to uch poibilitie, obtaining larger error and failing to explore the bet of capacity planning heuritic. Simplification conidered reult in validity threat that hould be explored in future work. We plan to ue real e-commerce workload to validate the reult obtained by each heuritic conidered in thi work. Although we ued ynthetic workload in thi work, the utility model propoed a well a the ynthetic e-commerce workload generated conidered real IaaS and SaaS provider information. So, we believe that an overview of heuritic behavior could be etablihed. A more detailed application model can be conidered uing many tier and uer eion. Finally, improvement in heuritic can be invetigated, epecially for cenario of large workload prediction error. ACKNOWLEDGMENTS The author would like to thank Siqi Shen [1] for providing pecification about the original COHR heuritic. REFERENCES [1] A. Moura, J. Sauve, and C. Bartolini, Buine-driven it management-upping the ante of it: exploring the linkage between it and buine to improve both it and buine reult, Communication Magazine, IEEE, vol. 46, no. 1, pp , 28. [2] M. Armbrut, A. Fox, R. Griffith, A. D. Joeph, R. Katz, A. Konwinki, G. Lee, D. Patteron, A. Rabkin, I. Stoica, and M. Zaharia, Above the Cloud : A Berkeley View of Cloud Computing Cloud Computing : An Old Idea Whoe Time Ha ( Finally ) Come, Computing, pp. 7 13, 29. [3] L. Vaquero, L. Rodero-Merino, J. Cacere, and M. Lindner, A break in the cloud: toward a cloud definition, ACM SIGCOMM Computer Communication Review, vol. 39, no. 1, pp. 5 55, 28.

14 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 2, NO. 1, MAY [4] J. Namjohi and A. Gupte, Service Oriented Architecture for Cloud Baed Travel Reervation Software a a Service, 29 IEEE International Conference on Cloud Computing, pp , Sep. 29. [5] M. Arlitt, D. Krihnamurthy, and J. Rolia, Characterizing the calability of a large web-baed hopping ytem, ACM Tranaction on Internet Technology, vol. 1, no. 1, pp , 21. [6] S. Ranjan, J. Rolia, H. Fu, and E. Knightly, Qo-driven erver migration for internet data center, in Quality of Service, 22. Tenth IEEE International Workhop on. IEEE, 22, pp [7] G. Galante and L. C. E. d. Bona, A urvey on cloud computing elaticity, in Proceeding of the 212 IEEE/ACM Fifth International Conference on Utility and Cloud Computing. IEEE Computer Society, 212, pp [8] F. Marque, J. Sauvé, and A. Moura, Buine-oriented capacity planning of it infratructure to handle load urge, in Network Operation and Management Sympoium, 26. NOMS 26. 1th IEEE/IFIP. IEEE, 26, pp [9] J. Sauve, F. Marque, A. Moura, M. Sampaio, J. Jornada, and E. Radziuk, Optimal deign of e-commerce ite infratructure from a buine perpective, in Sytem Science, 26. HICSS 6. Proceeding of the 39th Annual Hawaii International Conference on, vol. 8. IEEE, 26, pp. 178c 178c. [1] S. Shen, K. Deng, A. Ioup, and D. Epema, Scheduling job in the cloud uing on-demand and reerved intance, pp , 213. [11] S. Chaiiri, B.-S. Lee, and D. Niyato, Optimization of reource proviioning cot in cloud computing, Service Computing, IEEE Tranaction on, vol. 5, no. 2, pp , 212. [12] B. Urgaonkar, P. Shenoy, A. Chandra, P. Goyal, and T. Wood, Agile dynamic proviioning of multi-tier internet application, ACM Tranaction on Autonomou and Adaptive Sytem (TAAS), vol. 3, no. 1, p. 1, 28. [13] Y. Lee, C. Wang, A. Zomaya, and B. Zhou, Profit-driven ervice requet cheduling in cloud, in Proceeding of the 21 1th IEEE/ACM International Conference on Cluter, Cloud and Grid Computing. IEEE Computer Society, 21, pp [14] U. Sharma, P. Shenoy, S. Sahu, and A. Shaikh, A cot-aware elaticity proviioning ytem for the cloud, in Ditributed Computing Sytem (ICDCS), t International Conference on. IEEE, 211, pp [15] U. Sharma, Elatic reource management in cloud computing platform, Ph.D. diertation, Univerity of Maachuett - Amhert, 213. [16] H. Wu, W. Zhang, J. Zhang, J. Wei, and T. Huang, A benefitaware on-demand proviioning approach for multi-tier application in cloud computing, Frontier of Computer Science, vol. 7, no. 4, pp , 213. [17] G. Janakiraman, J. Santo, and Y. Turner, Automated multi-tier ytem deign for ervice availability, in Proceeding of the Firt Workhop on Deign of Self-Managing Sytem. Citeeer, 23. [18] L. Cherkaova, W. Tang, and S. Singhal, An la-oriented capacity planning tool for treaming media ervice, in Dependable Sytem and Network, 24 International Conference on. IEEE, 24, pp [19] D. Menacé, D. Barbará, and R. Dodge, Preerving qo of e- commerce ite through elf-tuning: A performance model approach, in Proceeding of the 3rd ACM conference on Electronic Commerce. ACM, 21, pp [2] A. Stage, T. Setzer, and M. Bichler, Automated capacity management and election of infratructure-a-a-ervice provider, in Integrated Network Management-Workhop, 29. IM 9. IFIP/IEEE International Sympoium on. IEEE, 29, pp [21] L. Wu, S. Garg, and R. Buyya, Sla-baed reource allocation for oftware a a ervice provider (aa) in cloud computing environment, in Cluter, Cloud and Grid Computing (CCGrid), th IEEE/ACM International Sympoium on. IEEE, 211, pp [22] R. Lope, F. Braileiro, and P. Maciel, Buine-driven capacity planning of a cloud-baed it infratructure for the execution of web application, in Parallel & Ditributed Proceing, Workhop and Phd Forum (IPDPSW), 21 IEEE International Sympoium on. IEEE, 21, pp [23] P. Maciel, F. Braileiro, R. Santo, D. Maia, R. Lope, M. Aquino de Carvalho, R. Cota Ribeiro, N. Andrade, and M. Mowbray, Buine-driven hort-term management of a hybrid it infratructure, Journal of Parallel and Ditributed Computing, 211. [24] D. Ardagna, B. Panicucci, and M. Paacantando, A game theoretic formulation of the ervice proviioning problem in cloud ytem, in Proceeding of the 2th international conference on World wide web. ACM, 211, pp [25] D. Candeia, R. Lope, R. A. Santo, and C. Grande-PB-Brail, Planejamento de capacidade a longo prazo dirigido por métrica de negócio para aplicaç oe aa, Simpóio Braileiro de Rede de Computadore e Sitema Ditribuído, pp , 213. [26] F. Liu, Z. Zhou, H. Jin, B. Li, and H. Jiang, On arbitrating the power-performance tradeoff in aa cloud, in Parallel and Ditributed Sytem, IEEE Tranaction on. IEEE Computer Society, 213. [27] J. Wilke, Utility function, price, and negotiation, Market- Oriented Grid and Utility Computing, pp , 28. [28] V. Almeida, Capacity planning for web ervice technique and methodology, Performance Evaluation of Complex Sytem: Technique and Tool, pp , 22. [29] R. A. Santo, Saaim - um framework para imulação de oftware a a ervice, Mater thei, Federal Univerity of Campina Grande, 212. [3] R. Sargent, Verification and validation of imulation model, in Proceeding of the 37th conference on Winter imulation. Winter Simulation Conference, 25, pp [31] D. Menace, V. Almeida, L. Dowdy, and L. Dowdy, Performance by deign: computer capacity planning by example. Prentice Hall, 24. [32] M. Crovella and A. Betavro, Self-imilarity in world wide web traffic: evidence and poible caue, in ACM SIGMETRICS Performance Evaluation Review, vol. 24, no. 1. ACM, 1996, pp [33] K. Kant, V. Tewari, and R. Iyer, Geit: Generator of ecommerce and internet erver traffic, in Proc. of Int. Sympoium on Performance Analyi of Sytem and Software, 21. David Candeia Medeiro Maia i a profeor at the Intituto Federal de Educação, Ciência e Tecnologia da Paraíba, Brazil, and a Ph.D. tudent at the Univeridade Federal de Campina Grande (UFCG), Brazil. He received a B.Sc. degree (29) and a M.Sc. degree (212) at Univeridade Federal de Campina Grande. Hi reearch interet include buine-driven IT management, cloud computing, mart citie and collaborative ytem. Contact him at david.maia@ifpb.edu.br. Ricardo Araújo Santo i currently a Ph.D. tudent at UFCG. He received a B.Sc. (29) and M.Sc. (212) degree in Computer Science at UFCG. He i intereted in Ditributed Sytem, have been involved lately in reearche related to Grid and Cloud Computing, pecially Automated Infratructure Management for Software a a Service Application. Contact him at ricardo@ld.ufcg.edu.br. Raquel Vigolvino Lope i a Profeor at UFCG, Brazil. She received a B.Sc. degree in Computer Science from the Univeridade Federal da Paraíba, Brazil (2), an M.Sc. degree (22) and D.Sc. (27) degree from the ame Univerity. Her reearch interet include buine-driven IT management, autonomic computing and performance evaluation and modelling of ditributed ytem. Contact her at raquel@computacao.ufcg.edu.br.