Design and Evaluation of Automatic Workflow Scaling Algorithms for Multi-Tenant SaaS

Transcription

1 Design and Evaluation of Automati Workflow Saling Algorithms for Multi-Tenant SaaS Ankita Atrey 1, Hendrik Moens 1, Gregory Van Seghbroek 1, Bruno Volkaert 1, and Filip De Turk 1 1 INTEC-IBCN-iMinds, Ghent University, Gaston Crommenlaan, 9050, Gent, Belgium {ankita.atrey, hendrik.moens, gregory.vanseghbroek, bruno.volkaert, Filip.DeTurk}@inte.ugent.be Keywords: Abstrat: Cloud multi-tenany, Cloud simulation, Cloud resoure provisioning, SLA provisioning. Current Cloud software development efforts to ome up with novel Software-as-a-Servie (SaaS) appliations are, just like traditional software development, usually no longer built from srath. Instead more and more Cloud developers are opting to use multiple existing omponents and integrate them in their appliation workflow. Saling the resulting appliation up or down, depending on user/tenant load, in order to keep the SLA, no longer beomes an issue of saling resoures for a single servie, rather results in a omplex problem of saling all individual servie endpoints in the workflow, depending on their monitored runtime behavior. In this paper, we propose and evaluate algorithms through CloudSim for automati and runtime saling of suh multi-tenant SaaS workflows. Our results on time-varying workloads show that the proposed algorithms are effetive and produe the best ost-quality trade-off while keeping Servie Level Agreements (SLAs) in line. Empirially, the proative algorithm with areful parameter tuning always meets the SLAs while only suffering a marginal inrease in average ost per servie omponent of 5 8% over our baseline passive algorithm, whih, although provides the least ost, suffers from prolonged violation of servie omponent SLAs. 1 INTRODUCTION Cloud omputing has redefined the way in whih omputing is pereived today and its use has inreased over the years. Clouds offer many benefits, but ahieving salability and quality of suh servies while ahieving all Servie Level Agreements (SLAs) at a minimal ost is hallenging. With the inreased use of multi-tenany (W.Tsai and Zhong, 2014), (sharing of virtualised resoures among multiple users, thereby inreasing onurreny and lowering virtualisation overhead) and rising popularity of loud servies for large user bases (e.g. Dropbox, Offie365 et.), orretly and automatially saling these servies to deal with urrent user demand beomes very important. Besides this, the majority of the SaaS developers no longer develop their appliations from srath, but utilize speialized existing (loud-based) servies in an appliation workflow. Examples of suh re-usable servie endpoints are payment servies, authorisation servies, loud monitoring / profiling servies, feedbak servies, et. In this work we assume that the resulting SaaS produt/appliation workflow will have to ater to a Servie Level Agreement (SLA) with regards to e.g. response time. The issue we fae when trying to solve the SLA requirements of a multi-tenant workflow is that eah servie omponent in suh a workflow, an have different SLA requirements, and an behave differently when put under multi-tenant load. Manual management of the upsaling or downsaling (i.e. assigning more or fewer resoures on offering that servie) of speifi workflow omponents based on monitored behavior may solve this, but is a proess whih would have to be done ontinuously and, due to the manual intervention, would be errorprone. Therefore, in this work, we present an automated multi-tenant workflow SLA monitoring framework, and algorithms whih an automatially propose saling speifi servie omponents up or down based on their urrent SLA ompliane. The use ase we are investigating in partiular (Fig. 1), is an elasti multi-tenant online ollaborative meeting room tool, onsisting of workflows whih an, for ease of understanding, be simplified to three servie omponents namely enoders, deoders and transoders. Here, an interative professional meeting servie is offered to a group of employees situated aross the globe. Every stream onsists of an enoder, potentially a transoder and a deoder, all of whih have different multi-tenant SLA requirements in order to provide a flawless servie (no A/V inter-

2 Figure 1: Use-ase: An online ollaborative meeting room with partiipants from aross the globe. ruptions, no stuttering, no onnetion loss, et.). Note that users an join or leave these meetings at any point in time, leading to large flutuations in terms of number of tenants urrently using the system. The algorithms proposed in this paper deal with the situation where resoure saling must be performed for eah individual servie omponent of the overall appliation workflow. The runtime behavior of eah omponent is aptured by a generi monitoring mehanism, and is used to keep trak of how this omponent is behaving based on its urrent tenant load and assigned resoures. Thus, we intend to automatially intervene if the load on a partiular servie is beoming too high for it to keep its SLA. Likewise, resoure assignment should also be automatially downsaled to save on resoures and/or budget. The rest of this paper is strutured as follows. Related work is presented in Setion 2, while Setion 3 present the problem statement. Following this, Setion 4 introdues the SLA monitoring-based resoure provisioning algorithms. Setion 5 disusses the evaluation setup after whih Setion 6 disusses the CloudSim evaluation results of the proposed heuristi algorithms. Finally, Setion 7 onludes. disussed semi-automati and automati saling. The authors provide an overview of the pros and ons of semi-automati (users are fored to balane requesting more resoures to avoid under-provisioning versus releasing resoures to avoid over-provisioning) versus automati saling (users follow workloads). User satisfation is the key onern of loud servies, whih, in ertain situations, an be adversely affeted by SLA violations. (Morshedlou and Meybodi, 2014) state that SLA violations depend on some user harateristis, and eventually define two types of user harateristis to redue the impat of SLA violation. Another interesting work (L. Wu and Buyya, 2011), deals with algorithms for automated resoure provisioning of SaaS servies based on their SLA. This work was further extended to develop a method for admission ontrol (L. Wu and Buyya, 2012) of user requests, thus failitating prevention of additional user requests from being aepted whih in turn would lead to violating the SLA of the servie. In ontinuation to this, (L. Wu et al., 2014) also foused on Customer Satisfation Level (CSL) whih depends on the SLA violations. To improve CSL and redue SLA violations, various algorithms are designed based on resoure reservation and request resheduling. The work presented in this paper differs from all the works disussed above, owing to our fous on workflows of servie endpoints, eah with independent runtime behavior, but ontributing to the overall appliation workflow s SLA adherene as well. Various other studies (Taheri et al., 2014) (Glitho, 2011) show that auto-saling for multimedia servies is an atively studied topi of researh. A reent work by (Soltanian et al., 2015) lay their fous on a very speifi sub-problem of saling media servies. This work differs from the work presented in this paper as our fous is to make generi and robust algorithms for the entire servie workflow spetrum. 2 RELATED WORK A lot of work has been performed with regards to Cloud resoure provisioning strategies for IaaS (Infrastruture as servie), PaaS (Platform as a servie) and SaaS (Software as a servie) providers. Moreover, researh on multi-tenany in loud appliations (Guo et al., 2007) with SLA-driven simulations (Antonesu and Braun, 2014) is not unommon today. (Espadasa et al., 2013) have foused on under and over-provisioning of resoures in SaaS and its influene on ost-effetiveness. In their work, a multitenant based resoure alloation model has been designed. Researh done by (Bellenger et al., 2011) 3 PROBLEM DESCRIPTION This setion presents a onise model of multitenant, multi-omponent SaaS workflows, with an introdution of its basi onepts followed by a formal desription of the ARP-M (Automati Resoure Provisioning under Multi-tenany) problem. Table 1 summarizes the notations used in the rest of the paper. The basis of the issue at hand is the observation that loud-based SaaS appliations urrently are, a lot of times, built as workflows of multiple existing servies (albeit with the neessary ustom glue ode to tie all of them together). In multi-tenant usage senarios, as is mostly the ase when dealing with SaaS

3 Item Table 1: Summary of the notations used. Definition V The pool of VMs; i,v i V. W Set of workflow requests; j,w j W. D(t) Time varying distribution for varying worfklow requests. C k j A servie omponent for the workflow W j ; k,c k j W j. SLA Ck status j The status (binary) of the SLA of C k j, i.e. met or broken. Nrunning i Number of omponents urrently running on VM V i. Nmax i Maximum number of omponents allowed on VM V i. τ Parameter ontrolling how quikly the Proative algorithm intervenes in terms of saling resoures up or down. Treserve Vi Time required for reservation of a new VM V i. T migrate Time required for migrating a servie omponent to V i. Preserve Vi Penalty inurred due to reservation of a new VM V i. P migrate Penalty inurred owing to migrating omponents to V i. appliations, the performane and salability of eah of these workflow servie omponents an behave differently when ompared to the others, yet all of them have an impat on the overall performane and salability of the SaaS appliation/workflow. We hene define an appliation as a workflow W j W onsisting of one or more omponents C k j W j (see Fig. 2), eah of whih having a separate SLA agreement whih defines a.o. minimal resoure requirements (proessing power, memory, storage, et.) in order to work aording to its speifiations. Servie omponents in suh an appliation workflow, pass their data along the workflow edges to the next servie omponent. In the ase of streaming workflows, omponents reeive streaming data from the workflow omponents whih serve as input, while they themselves stream their output data to the workflow omponents following their exeution. Again as an example, if the workflow in Fig. 2 would be representing a streaming workflow, C 21 would ontinuously send/stream output data to C 31 and C 41, who in turn proess that input data and stream it to C 51. All servie endpoints are hene proessing in parallel. In this paper, and given our use ase of online ollaborative audio/video meetings, we will fous on streaming workflows, whih proess data as long as the meeting is ongoing. It is important to note that this type of workflow, for this type of use ases, does not benefit from assigning more resoures to them than required, as one annot speed up the meeting. As long as the performane SLAs of the onstituent servies are met, the meeting servie will perform as envisioned for those partiipating in it (i.e. overalloating resoures will not lead to shorter meeting durations). To model this, the tenant requests follow a time-varying distribution D(t). We all the problem of automatially provisioning resoures for multi-tenant SaaS appliations as Automati Resoure Provisioning under Multi-tenany (ARP-M) problem; defined formally as follows. Problem. Given a VM pool V, a set of streaming workflow requests W following a distribution D(t), Figure 2: An appliation workflow W 1 omposed of multiple servie omponents and inter-omponent data flows. and the maximum number of requests allowed on eah VM N i max V i V, perform automati resoure provisioning to keep the SLAs, SLA status = f alse, for all the workflow omponents C k j k,c k j W j, j,w j W, while retaining high ost-effiieny and quality of servie for multi-tenant SaaS. 4 RESOURCE PROVISIONING ALGORITHMS In this setion, we desribe our proposed monitoring driven resoure provisioning heuristis for meeting the SLAs while maintaining high ost effiieny. As mentioned in Se. 3, the SLAs of the workflows depend on the SLAs/run-time behavior of eah of its onstituent servie omponents. This is haraterized by the number of omponent instanes Nrunning i, simultaneously running on the respetive provisioned resoures V i V and the maximum number of omponent instanes Nmax i that an be served by the resoures reserved for the omponents at any given time. Additionally, the number of the tenant requests follows a time-varying distribution D(t). Next, we briefly desribe the building bloks of our algorithms: (a) a SLA Monitoring module and (b) a VM Alloation module. SLA Monitoring: Eah omponent C k j of a workflow W j W running on a VM V i V, is assoiated with a binary variable, SLA status, whih assumes the value of False if SLAs are met and True otherwise. Mathematially, SLA status = { f alse, true, if Nrunning i N max i otherwise Keeping trak of the SLA status for eah omponent (whether it is broken or not) is the main task of this module. This monitoring apability plays a entral role in the design of the more involved proposed heuristis, i.e., the reative algorithm (Alg. 3) and the proative algorithm (Alg. 4).

4 VM Alloation: This module failitates on demand reation of new VM instanes based on a speifi VM template from the pool of VMs V. The VM alloations under the passive algorithm are performed in the beginning, and remain fixed throughout, whereas are ontinuously updated for the reative and the proative algorithms. 4.1 Workflow Deployment Algorithm Algorithm 1 desribes the pseudo-ode for the deployment of streaming workflows. As mentioned in Se. 3, the user/tenant requests follow a time-varying distribution D(t). Now, if the inoming requests at time t + 1 are greater than those at time t (line 7), then additional workflows are reated and assigned to the VMs (depending on the resoure provisioning algorithms, lines 8 13), otherwise the additional workflows are aneled and the orresponding resoures on the VMs that were hosting these workflows freed (lines 14 24). Note that, irrespetive of the resoure provisioning algorithm, eah of the servie omponents C k j 1 k W j, of the inoming user/tenant workflow requests W j, are assigned to separate VMs V i 1 i W j, that are urrently aepting requests, from the VM pool V. One these VMs reah their apaity, then depending upon the protools of the resoure provisioning algorithms new VMs are either reserved / not reserved and the pointer to the urrently ative VMs altered/unhanged respetively. 4.2 Passive Algorithm In this algorithm, all the resoures with different properties (storage, CPU, memory et.) are reserved in the beginning of the appliation session. Note that in this algorithm, no new VM reservations happen even if V i pre-reserved V the apaity is reahed, i.e. Nrunning i > N max, i in whih ase the SLAs violate. This algorithm will ahieve good results in terms of Cost and keeping SLAs, only if the request rate is near-onstant and the number of requests an fit in the pre-reserved resoures. The moment more requests arrive, the SLAs will start to violate and remain violated. The ost, however, will naturally remain fixed. 4.3 Reative Algorithm Contrary to the passive algorithm, here new VM reservations are triggered one the number of omponents Nrunning i running on a VM V i exeeds its maximum permissible limit Nmax i (line 6). If the workflow request W j triggered the reservation proess, then l (1 l W j ) new VMs are instantiated from the VM Algorithm 1 Workflow Deployment Algorithm Require: V, Nmax i V i V, W D(t), provisiontype,τ Ensure: SLA status, AvgCost, Cost 1: numrunning 0 2: for eah V i V do 3: Nrunning i 4: for t = 0 to t max do 5: SLA status f alse, AvgCost 0, Cost 0 6: W t D(t); numdeploy W t numrunning 7: if numdeploy 0 then 8: if provisiontype = Passive then 9: PassiveDeploy(W t,v ) 10: else if provisiontype = Reative then 11: ReativeDeploy(W t,v ) 12: else 13: ProativeDeploy(W t,v,τ) 14: else 15: for eah W j W t do 16: Cost j 0 17: for eah C k j W j do 18: Canel C k j and free its resoures on V i 19: Nrunning i running i 20: Cost j Cost j (M i +C i + S i ) 21: if Nrunning i max i then 22: SLA status f alse 23: Cost Cost +Cost j 24: AvgCost AvgCost +Cost j / W j 25: AvgCost AvgCost/ W t 26: numrunning numrunning+numdeploy Algorithm 2 Passive Algorithm Require: V, Nmax i V i V, W D(t) Ensure: SLA status, AvgCost, Cost 1: proedure PASSIVEDEPLOY(W t,v ) 2: for eah W j W t do 3: Cost j 0 4: for eah C k j W j do 5: Deploy C k j on a pre-reserved VM V i 6: N i running N i running + 1 7: if Nrunning i max i then 8: Cost j Cost j + M i +C i + S i 9: else 10: SLA status true 11: Cost Cost +Cost j 12: AvgCost AvgCost +Cost j / W j 13: AvgCost AvgCost/ W t and-above the usual VM utilization osts (line 13). This algorithm reats to the detetion of violation in SLAs, and thus would suffer from small episodes of SLA violations. Although the SLAs would be met for a large portion of the time, there will be a surge in osts (owing to penalties) when the SLAs are broken. 4.4 Proative Algorithm In this algorithm, the SLA monitoring module ontinuously monitors the number of servie omponents

5 Algorithm 3 Reative Algorithm Require: V, Nmax i V i V, W D(t) Ensure: SLA status, Cost, AvgCost, AvgPen, AvgSLABrkD 1: SLABrkD 0, AvgSLABrkD 0 2: proedure REACTIVEDEPLOY(W t,v ) 3: for eah W j W t do 4: Cost j 0, Pen j 0 5: for eah C k j W j do 6: if N i running + 1 > N i max then 7: SLA status true 8: Identify VM V l, with Nrunning l < N max l 9: Deploy C k j on VM V l 10: N l running N l running : Cost j Cost j + M l +C l + S l 12: SLABrkD SLABrkD + T V l reserve + T migrate 13: Pen j Pen j + P V l reserve + P migrate 14: else 15: Nrunning i running i 16: Cost j Cost j + M i +C i + S i 17: Cost Cost +Cost j ; Penalty Penalty + Pen j 18: AvgCost AvgCost +Cost j / W j 19: AvgPen AvgPen + Pen j / W j 20: AvgSLABrkD SLABrkD/ W j 21: AvgCost AvgCost/ W t ; AvgPen AvgPen/ W t 22: AvgSLABrkD AvgSLABrkD/ W t Nrunning i and heks how far this is from the maximum permissible limit Nmax, i for eah VM V i V. To address the limitations mentioned in the reative algorithm the proative algorithm inorporates the use of a parameter τ. The parameter τ failitates the reservation of a new VM V l and the migration of the servie omponents from V i to V l, to be performed while there is still room for more omponents to be exeuted on the VM V i without breaking the SLAs. Using this algorithm, the SLAs of all the omponents remain broken for the time required to reserve new VMs and migrate them from the old VM to the new one respetively, disounting the time duration orresponding to the start of the reservation proess and the time instant at whih the SLA atually got violated. Thus, with a areful seletion of τ, T reserve + T migrate would get subsumed by the differene in the time instant at whih the SLAs atually got violated and the time instant at whih the reservation proess was triggered. This will result in the SLAs to be always met while the waiting time on VMs that need to be started will also be 0. If the parameter τ is too low, additional VMs will be reserved rapidly whih will in turn drive up the ost. Likewise, if the parameter τ is too high, we will spend some extra time to instantiate new VMs. Similar to Alg. 3 penalties are added over-and-above the usual VM utilization osts. Note that sine we preah maximum resoure utilization, although new VM reservations are triggered one the above ondition is met, the servie omponents are migrated only after the VMs ur- Algorithm 4 Proative Algorithm Require: V, Nmax i V i V, W D(t) Ensure: SLA status, Cost, AvgCost, AvgPen, AvgSLABrkD 1: SLABrkD 0, AvgSLABrkD 0 2: proedure PROACTIVEDEPLOY(W t,v,τ) 3: for eah W j W t do 4: Cost j 0, Pen j 0 5: for eah C k j W j do 6: N i running N i running + 1 7: if N i running = τ.n i max + 1 then 8: Identify VM V l, with Nrunning l < N max l 9: StartV M V l t 10: if N i running > N i max then 11: if t StartV M V l < T V l reserve + T migrate then 12: SLA status true 13: extradelay T V l reserve + T migrate t + StartV M V l 14: SLABrkD SLABrkD+extraDelay 15: Pen j Pen j + extradelay T V (P reserve + P migrate ) l reserve +T migrate 16: Deploy C k j on VM V l 17: Nrunning l running l running i running i 18: Cost j Cost j + M l +C l + S l 19: else 20: Cost j Cost j + M i +C i + S i 21: AvgCost AvgCost +Cost j / W j 22: AvgPen AvgPen + Pen j / W j 23: AvgSLABrkD SLABrkD/ W j 24: AvgCost AvgCost/ W t, AvgPen AvgPen/ W t, AvgSLABrkD AvgSLABrkD/ W t rently running them are fully utilized. 5 EVALUATION SETUP 5.1 Media Workflows The media workflow illustrated in Fig. 3, represents a streaming workflow with three omponents namely enoder, transoder and deoder. In streaming workflows servie omponents ontinuously reeive streaming data from other omponents whih serve as their input, while they themselves stream their output data to other workflow omponents following their exeution. Note that even though muh more elaborate workflows exist, this partiular workflow has been hosen to showase the strength of the presented algorithms in an easy-to-grasp manner. 5.2 Evaluation Senario The media workflow disussed in the previous setion is instantiated by multiple users/tenants and submitted to the CloudSim simulator. To showase our simulation results, we assign the streaming workflow requests (D(t)) to follow a normal distribution. We

6 Figure 3: Media workflow with three omponents: Enoder, Transoder and Deoder. Eah omponent has a personal SLA and runs on a VM, made available from a VM pool. generate 200 user requests following a normal distribution, with the time 12 noon set as the mean and 3.5 hours to be the standard deviation. In the beginning of the day requests ome in slowly but gradually these requests inrease and reah a peak during the mid day. For eah user/tenant request a new instane of the workflow W j is reated and the onstituent servie omponents C k j, k C k j W j are provisioned on different VMs V i, available from the VM pool V (the hoie of VM and how this VM pool grows / shrinks is driven depending on the hoie of the algorithm). 5.3 Evaluation Metris We onsider the following metris: SLA Status: The SLA status for eah servie omponent C k j, of eah instane of a workflow W j, running on a VM V i, is defined as a binary variable whih assumes the value of f alse if the SLAs are met, and true otherwise. Average SLA Break Duration: The average SLA break duration is defined as the amount of time the SLA status of a servie omponent is broken over its runtime duration on average. Thus, for a simulation with w workflow requests W j W 1 j w, servie omponents eah C k j W j 1 k, and T C k j slabreak being the duration for whih the SLAs remain broken for a omponent C k j, we mathematially state the following: w 1 (1 w( (T C k j slabreak ))) (1) VM Cost: The VM ost is defined as the sum of all osts related to resoure usage when running the omponents of streaming workflows. Thus, for a simulation with w workflow requests, eah one with omponents, and M k, S k, C k, representing, memory, storage and CPU osts respetively for a omponent C k, we mathematially state the VM ost and the average VM ost as follows: w 1 w( w ( (M k + S k +C k ) ) (2) (1 (M k + S k +C k ) )) (3) Table 2: Parameterized VM Templates. Template Storage CPU RAM Monthly Cost Template 01 4 GB 40 MIPS 128 GB $3.94 Template 02 8 GB 80 MIPS 256 GB $7.88 Penalty: The extra ost inurred over-and-above the normal resoure utilization osts aounts for the inurred penalty. The penalty is mainly due to the side-effets of breaking SLAs, and inludes the ost spent on omponents (in SLA break state), while waiting for (1) a new VM reservation P reserve and (2) migration of omponents from one VM to another P migrate. We mathematially state the Penalty and the average Penalty as follows: w w 1 (1 w( ( (P reservek + P migratek ) ) (4) 5.4 CloudSim Extensions (P reservek + P migratek ) )) (5) The proposed algorithms are implemented and evaluated using the CloudSim (Calheiros et al., 2011) event based simulator. To showase the effetiveness of our algorithms under the proposed evaluation senario, we implemented the following extensions: SLA Monitor: For eah instantiation of the media workflow, the monitoring module heks the SLAs of all the servie omponents (enoder, transoder and deoder), to see whether they hold under the urrent deployment senarios. The SLAs of various omponents are ontinuously monitored by a Monitor event, to failitate triggering of ertain ations based on a threshold τ. Resoure Provisioner: The resoure provisioning module has been extended to implement all monitoring based multi-tenant resoure provisioning algorithms (as defined in Se. 4). Request Generator: extends the Cloudlet lass to support real-time streaming workflows and generates user/tenant workflow requests based on a normal distribution until a lient event stops it. 6 EVALUATION RESULTS As mentioned in Se. 4, the time required to reserve new VMs differs signifiantly from the time required to migrate one omponent from an existing VM instane to another. To this end, we define two variables, T V i reserve and T migrate, that determine the duration for instantiating/reserving new VMs and the duration for migrating omponents to existing VMs respetively. For the simulations, the values of T V i reserve

7 Average SLA Broken Duration (in se) Parameter for Proative Algorithm Figure 4: Variation in the average SLA break duration versus τ for the Proative algorithm. and T migrate were defined as uniform distributions between [60s,75s] and [0.5s,2s] respetively. The osts for the VM templates used, were parameterized based on the Amazon EC2 image 3.8xlarge, with a monthly prie of to provide 32 Million instrutions per seond (MIPS), 60 GB of RAM and 320 GB of storage. This ost was divided equally between seondary-storage, main-memory and CPU, and the onverted unit pries (per MB/hour and MI/hour) were used to alulate the osts for the VM templates used in this paper. The omputed osts for eah VM template are mentioned in Table 2. All the simulations were exeuted using the CloudSim simulator and the proposed extensions, on an Intel(R) Core i5 4-ore mahine with 1.7 GHz CPU and 8 GB RAM running Linux Ubuntu We first analyze the results obtained under the proative algorithm with the variation in the parameter τ from 0 1. It is evident from Fig. 4 that the SLAs of the omponents are met for τ 0.6. One the value of τ rosses 0.6, the average SLA break duration starts inreasing. This inrease is at first gradual till τ 0.75, after whih it starts inreasing rapidly. The average penalty inurred, due to the time required for a new VM reservation T V i reserve (P V i reserve) and for migration of omponents T migrate (P migrate ), during the time when SLAs for the omponents are broken, portrays a similar pattern as depited by the SLA break duration (Fig. 4). Thus, with respet to minimizing the SLA violation duration and minimizing the average penalty, the range 0 τ 0.75 is onsidered to be optimal. Fig. 5 presents the results on average ost inurred with varying τ. The red line represents the average VM ost (Eq. 3), whih is almost onstant with the variation in τ. The green line represents the average penalty inurred due to SLA violation of one or more endpoints, whih has already been analyzed above. The penalty inurred due to the proative reservations of VMs is depited by the blue line. It is evident from Fig. 5 that this penalty linearly dereases with inreasing τ, with its maximum value when τ = 0 and mini- Average Cost (in $) TotalCost VMCost PenaltyVMReserve PenaltySLABreak Parameter for Proative Algorithm Figure 5: Variation in the average ost versus τ for the Proative algorithm. mum value when τ = 1. The total ost represented by the purple line, is the sum of the VM ost and the two penalties disussed above. It is evident that the total ost first linearly dereases till τ = 0.65, beomes almost onstant till τ = 0.75 and then starts to inrease rapidly with the inrease in τ. Thus, with respet to minimizing the total ost, 0.65 τ 0.75 serves as the optimal range for parameter τ. Next, we ompare the total and the average ost for the proposed algorithms (1) passive, (2) reative and (3) proative. Note that the proative algorithm will use τ = 0.60 for all the following omparisons. Fig. 6 portrays the variation in total ost with the time of day for the three proposed algorithms. It is not surprising to see that the passive algorithm possesses the least total ost. Sine, no new VM reservations happen, even when Nrunning i exeeds N max, i the VM osts are kept at a bare minimum. On the other hand, sine new VM reservations happen for both reative and proative algorithms, the osts are naturally higher here. The osts for the reative algorithm are higher, at ertain times, when ompared to the proative algorithm owing to the penalties ourred due to breaking the SLAs. Note that, although the osts inurred by the reative and the proative algorithm are higher when ompared to that of the passive algorithm, this ost is warranted (i.e. it is not due to sub-optimal utilization of VM resoures, but should be seen as a neessity in attaining the workflow SLAs for the given number of multi-tenant requests). Cost (in $) Passive Reative Proative Time of Day (in hours) Figure 6: Comparing variation in the total ost versus the time of day for the passive, reative and proative algorithm.

8 Average Cost (in $) Passive Reative Proative with more advaned issues like dealing with servie robustness and resoure/onnetion failures. Another line of researh will involve mapping SaaS appliations and workflows to the TOSCA standard, thus enabling their standardization and use of management plans (Binz et al., 2014) for automati saling Time of Day (in hours) Figure 7: Comparing variation in the average ost versus the time of day for the passive, reative and proative algorithm. To substantiate the above argument, we also ompare the variation in the average ost, with the time of day for the proposed algorithms. It is evident from Fig. 7 that the average ost of all the three algorithms are almost similar at majority of the time instanes. Note that the portrayed osts also inlude the penalties inurred, if any. At ertain instanes, the average ost of the reative algorithm is the highest, whih is the result of the penalties inurred due to the VM reservation proess starting only after the SLAs are broken. Sine the proative algorithm, triggers the new VM reservation proess prior to deteting violation in the SLAs, the penalties inurred for this algorithm are signifiantly lower when ompared to that of the reative algorithm. The only penalty inurred on the proative algorithm is due to the pre-reservation of VMs, whih is optimized for τ = 0.60 as disussed above. The osts for the proative algorithm are almost similar to that of the passive algorithm, while being marginally higher only at ertain times. To summarize, the proative algorithm with τ in the range 0.60 τ 0.75 serves as the best possible trade-off for minimizing the osts while also keeping the SLAs of the omponents in line. 7 CONCLUSIONS In this paper we have proposed algorithms that allow automati saling of SLA-bound SaaS workflows onsisting of multiple (SaaS) servie endpoints based on monitored appliation multi-tenany (where lient request rates an highly flutuate based on the time of day). The effetiveness of these algorithms was demonstrated using a simulated use ase of a professional loud-based A/V ollaboration servie. These algorithms kept trak of the SLAs of eah workflow omponent and, for the most advaned proative algorithm, reserved new VMs before SLAs were to be broken, thus, providing the best possible trade-off between ost effiieny and quality-of-servie. Future work will see us extending our algorithms ACKNOWLEDGEMENTS This researh is partly funded by the IWT SBO DeCoMAdS projet. REFERENCES Antonesu, A. F. and Braun, T. (2014). Sla-driven simulation of multi-tenant salable loud-distributed enterprise information system. In ARMS- CC. Bellenger, D., Bertram, J., Budina, A., Koshel, A., Pfander, B., and Serowy, C. (2011). Saling in loud environments. In WSEAS. Binz, T., Breitenbüher, U., Kopp, O., and Leymann, F. (2014). Advaned Web Servies, hapter TOSCA: Portable Automated Deployment and Management of Cloud Appliations. Calheiros, R. N., Ranjan, R., Beloglazov, A., Rose, C. A. F. D., and Buyya, R. (2011). Cloudsim: A toolkit for modeling and simulation of loud omputing environments and evaluation of resoure provisioning algorithms. Softw. Prat. Exper., 41(1). Espadasa, J., Molinab, A., Jimneza, G., Molinab, M., Ramreza, R., and Conhaa, D. (2013). A tenant-based resoure alloation model for saling software-as-a-servie appliations over loud omputing infrastrutures. FGCS, 29(1). Glitho, R. H. (2011). Cloud-based multimedia onferening: Business model, researh agenda, state-of-the-art. In CEC. Guo, C. J., Sun, W., Huang, Y., and Gao, B. (2007). A framework for native multi-tenany appliation development and management. In CEC. L. Wu, S. K. G. and Buyya, R. (2011). Sla-based resoure alloation for software as a servie provider (saas) in loud omputing environments. In CCGrid. L. Wu, S. K. G. and Buyya, R. (2012). Sla-based admission ontrol for a software-as-a-servie provider in loud omputing environments. JCSS, 78(5). L. Wu, S. K. G., Versteeg, S., and Buyya, R. (2014). Sla-based resoure provisioning for hosted software-as-a-servie appliations in loud omputing environments. IEEE TSC, 7(3). Morshedlou, H. and Meybodi, M. (2014). Dereasing impat of sla violations:a proative resoure alloation approah for loud omputing environments. IEEE TCC, 2(2). Soltanian, A., Salahuddin, M. A., Elbiaze, H., and Glitho, R. (2015). A resoure alloation mehanism for video mixing as a loud omputing servie in multimedia onferening appliations. In CNSM. Taheri, F., George, J., Belqasmi, F., Kara, N., and Glitho, R. (2014). A loud infrastruture for salable and elasti multimedia onferening appliations. In CNSM. W.Tsai and Zhong, P. (2014). Multi-tenany and sub-tenany arhiteture in software-as-a-servie (saas). In SOSE.