Web Services QoS: External SLAs and Internal Policies Or: How do we deliver what we promise?

Transcription

1 Web s QoS: Exteral SLAs ad Iteral Policies Or: How do we deliver what we promise? Heiko Ludwig IBM T.J. Watso Research Ceter hludwig@us.ibm.com Abstract With Web services startig to be deployed withi orgaizatios ad beig offered as paid services across orgaizatioal boudaries, quality of service (QoS) has become oe of the key issues to be addressed by providers ad cliets. While methods to describe ad advertise QoS properties have bee developed, the mai outstadig issue remais how to implemet a service that lives up to promised QoS properties. This keyote speech revisits the curret state of the art of QoS maagemet applied today to Web services ad raises a set of research issues that origiate i the virtualizatio aspect of services ad are specific to QoS maagemet i a services eviromet beyod what is addressed so far by work i the areas of distributed systems ad performace maagemet. 1. Itroductio Whether offered withi a orgaizatio or as a part of a paid service across orgaizatioal boudaries, qualityof-service (QoS) aspects of services are importat i a service-orieted computig eviromet. Dealig with QoS is a sig of a techology goig beyod its stage of iitial experimetatio to a productio deploymet ad may recet activities related to QoS of Web services idicate that this is becomig a icreasigly relevat topic. Efforts i the past years maily focused o describig, advertisig ad sigig up to Web ad Grid services at defied QoS levels. This icludes HP s Web s Maagemet Framework (WSMF) [1], IBM s Web Level Agreemet (WSLA) laguage [2,3], the Web s Offer Laguage (WSOL) [4] as well as approaches based o WS-Policy [5]. These efforts eable us to describe quality metrics of services, such as respose time, ad the associated service level objectives flexibly ad i a way that is meaigful for the busiess eeds of a service cliet. However, oe of the challegig issues is to associate or derive a system cofiguratio that delivers the QoS of a Web service described usig the abovemetioed approaches. I may cases this is o-trivial. Sometimes we ca rely o experiece with tested, dedicated system cofiguratios to decide, for example, the size of a cluster for a particular workload guarateeig a particular respose time for a give percetile of requests. I additio, maagig a service at differet QoS levels o the same ifrastructure is ot easy. While maagig QoS i distributed systems is ot a ovel problem, a umber of additioal issues arise i the cotext of a service-orieted computig eviromet. Those issues arise from the specific properties of Web services. For example, cross-orgaizatioal Web services may be accessed through the public Iteret ad cliet side QoS metrics have to iclude etwork properties i additio to properties of the service-implemetig applicatio itself. I additio, composite ad recursively aggregated services ad the ability to aggregate is see as a key beefit of Web services gai ew QoS properties that are ot always easily derived from its parts. The objective of this keyote is to revisit the state of the art i maagig QoS i distributed systems ad to raise the ew issues that we face i a eviromet of -orieted Architectures (SOAs). First, we revisit ad discuss further ope issues related to QoS maagemet of Web services i geeral. Subsequetly, we ivestigate how existig approach from the area of distributed systems ad performace maagemet help address some of the QoS maagemet issues. Fially, we elaborate o the outstadig issues that are ot solved so far ad potetial directios to address them i further research by the Web services commuity. 2. Issues of Web services QoS The first step to maage Web services quality is to defie it. While this is importat for Web services as well as i traditioal distributed systems, explicit defiitio is particularly importat i a eviromet trascedig orgaizatioal boudaries. Quality is expressed referrig to observable parameters relatig to a o-fuctioal property, for example the respose time of a request. A level of quality is agreed upo as a costrait over those parameters, potetially depedet o a precoditio. Hece, the party offerig a Web service, i agreemet with its customers ad users, will defie the QoS parameters ad the particular istaces of the service to which these parameters relate. I the case of a Web service, a parameter such as respose time ca relate to a

2 idividual ivocatio of a operatio or a class of operatios all havig the same (idividual) quality properties of havig a aggregate property, e.g., the average respose time of this class of operatios or aother stochastic metric. A further step i maagig Web services QoS is the defiitio of the sematics of the QoS parameters. A Web service ad its subscribers ad users must uderstad what is meat. It is importat what is measured where. For performace-orieted metrics this ca be at differet poits, as figure 1 illustrates. poit of measuremet Server Figure 1: Poits of measuremets defiig sematics of metrics. Respose time measuremets take from the Web service cliet are etirely differet from those take o the etwork betwee cliet ad service, the applicatio server iboud queue of a service provider or the service applicatio itself. Hece, eve a seemigly simple metric such as respose time eeds further qualificatio. Furthermore, aggregate properties must be defied, e.g., average respose time. I this case, it is importat to uderstad the averagig widow, possibly a samplig rate ad other aspects of the aggregatio. The defiitio of QoS parameters correspods to the establishmet of a otology betwee a service provider ad its cliets. A otology ca be established i two approaches. (1) It ca be a defiitio of terms ad, potetially, the sematics of the relatioships betwee them, as facilitated by DAML ad OIL [6]. This approach results i a fixed set of well uderstood terms i our case the QoS parameters. (2) Aother approach uses costructive otologies. Based o a set of well-kow defied terms (as i 1) ad a set of well-kow compositio operators, ew terms (QoS) parameters ca be defied by composig ew parameters out of existig oes usig the operators. For example, a average respose time ca be defied by applyig the average operator to the selectio of respose times of a operatio i the past miute. I this example, respose time is a well-defied parameter ad average ad selectio are compositio operators. This is a approach that is proposed by WSLA. While it is easier to implemet applicatios that ca deal with a fixed set of terms that are all kow at the time of system implemetatio, costructive otologies provide more flexibility. Havig established commo uderstadig of quality of service parameters ad the associated guaratees give by the provider, it also has to be established to which relatioships betwee a cliet ad a server a QoS guaratee applies. A service may provide the same quality to all requestig cliets, to each cliet idividually or to a defied set of cliets that a provider orgaizatio ad a orgaizatio requirig a QoS level for multiple cliets agree upo i a cotract, which is also called a SLA. 1 2 Cotract Server Figure 2: Cotracts defiig the scope of quality guaratees. s will refer to the cotract whe requestig service accordig to a particular quality level. The differet scopig approaches of QoS guaratees require differet meas of establishig a particular quality level for a cliet: If a QoS level is associated with a service a cliet searches for a suitable service i a directory, e.g., UDDI ad retrieves its quality defiitio, e.g., stated as a WS-Policy expressio. I the case of a idividual cliet or a cotract, a egotiatio mechaism, which ca be very simple - must be provided. Oce the cotract is established, the provider orgaizatio must provisio a service-implemetig system such that it behaves as it has bee agreed upo. This ivolves derivig the amout of resources eeded ad the rutime maagemet of resources. However, this is ot simple. While we have developed improvable approaches to the issues raised above, the issue of provisioig ad rutime maagig a Web service-implemetig system is ot equally well uderstood yet. I the ext sectio, we discuss what distributed systems ad performace maagemet approaches ca provide. 3. Implemetig service quality curret approaches Differet QoS parameters require differet types of resources ad differet approaches to rutime maagemet. Performace or respose time maagemet deals with shared or dedicated resources to be allocated to a particular scope of quality. It is based o the model that multiple workloads compete for resource, each workload havig particular characteristics. Availability maagemet is based o a model of failure of resources ad allocates shared or dedicated redudacies. The maagemet of those parameters has bee subject of research outside the scope of Web services. There are, of

3 course, may more parameters such as time to recover, etc. A umber of performace maagemet techologies, such as workload maagers ad etwork dispatchers, have bee developed to cotrol respose times of idividual systems ad clusters ad various availability maagemet approaches. However, it is ot straightforward to cofigure, for example, workload maagers to satisfy respose time goals for a set of differet scopes of quality for Web services as well as for ay distributed system. I this sectio, we outlie some typical approaches how QoS parameters are maaged i distributed systems today. Sice performace maagemet is typically the first QoS aspect that eeds to be addressed, we focus o this parameter i the subsequet discussio. 3.1 Allocatig dedicated resources A approach to maage performace of workloads that is frequetly used is the allocatio of dedicated resources to the differet workload. A umber of servers ruig a service applicatio are the resources to be allocated. cliets sed messages to access services. A dispatcher receives those messages from cliets ad assigs the requests to servers to be processed. Multiple algorithms ca be used for the dispatchig of requests for the same service, from simple roud robi to algorithms that take ito accout the curret workload o the servers ad the expected time to start processig a ew call. The dispatcher measures performace QoS parameters such as respose time ad makes those values available to a provisioig maager. Accordig to the performace goal of the service, the provisioig maager adds ew servers to the server pool of a particular service i case of goal uderachievemet or withdraws servers i case of overachievemet. Addig a server to a pool typically ivolves the istallatio ad cofiguratio of the service applicatio ad the recofiguratio of the dispatcher, which ivolves costs i terms of setup time. Provisioig maagers use iformatio o provisioig cost, movig averages of workloads ad sometimes sophisticated models of future behavior of cliets to make their decisios [7]. I a typical eviromet, however, a service provider would offer multiple services or qualities. The illustratio i figure 3 outlies a typical multi-service cofiguratio. While the mai compoets stay the same, the provisioig maager has to decide to which server pool for a particular service a give server is assiged. I additio, if multiple services caot meet their performace goals, it must arbitrate which service is give preferece ad receives additioal resources ad from which service they are take. To be able to arbitrate, the provisioig maager must have a utility fuctio describig the value of reachig or missig each services performace objectives to be able to compute the margial beefits of allocatig a server to oe service or aother. Utility Fuctio 1 2 Provisioig Moitor QoS Parameters Reallocate Server 1 1 Server m 1 Server 2 Server z 2 Figure 3: Allocatig dedicated resources. Usig this approach of dedicated resources a service provider ca also offer the sematically same service at differet quality of service levels by makig them techically separate services. Hece, a service provider ca allocate separate servers for each customer requestig a ew performace level. The dispatcher is relatively simple ad a differet dispatcher ca be used for each idividual service. 3.2 differetiatio o shared resources I some cases, usig dedicated resources ad offerig differet performace levels as separate services either uses resources well or provides a flexible ad geeral iterface to a service from a cliet s poit of view. Hece, a more sophisticated dispatcher is used such as the oe proposed i Levy et al [8]. Utility Fuctios of Respose Time Classes Gold Gold Silver Silver Silver Broze Workload Moitor Goal Compliace Re-adjust Parameters C P S R Policig Classificatio & Admissio Cotrol Schedulig & Flow Cotrol Routig Server 1 Applicatio Server Applicatio Figure 4: Maagig shared resources. Figure 4 illustrates a cofiguratio of a more sophisticated dispatcher for shared resources. A key approach to reduce the umber of server pools for differet performace levels is the establishmet of a small umber of performace classes to which idividual performace guaratees ca be mapped. For

4 example, oe could establish a class of requests respoded to i less tha oe secod, less tha 5 secods, less tha 10 secods, ad best effort. A performace guaratee for a cliet of 6 secods could the be mapped to the less-tha- 5-secod class. This results i a lower umber of server pools to deal with, eve if idividual servers are ot shared betwee differet types of services. Typically, however, each server would have multiple service applicatio istalled to icrease flexibility. Those classes of service are ofte private to the service provider ad ot disclosed to its customers. I additio, all cliets use the same dispatcher for all requests, labelig the request with the particular scope of quality they require, for example i the SOAP header of a Web service request. Give a mix of cliet requests as iput ad a set of flexible ad shared resources, the dispatcher processes requests i multiple steps: First, it is verified that a icomig message is allowed at a requested level of performace (admissio cotrol) ad it is classified to the iteral classes of service. Subsequetly, the request is put ito a queue associated with its class of service. Each queue has a give legth to esure that the performace guaratee associated with its class of service ca be met. The policig fuctio checks the queue status before queuig the request. The, a scheduler ad flow cotroller takes requests from the class of service queues. There are multiple algorithms to take requests from queue. A frequetly used approach is weighted roud robi. Each queue is give a weight, e.g., 5 (best), 2 (medium) ad 1 (worst). Whe server capacity becomes available, the scheduler takes 5 requests from the best queue, 2 from the medium ad 1 from the worst, ad the starts over at the best. Whe o request is waitig i a queue, it is skipped. Fially, the router puts the ext request o a server to be processed. This fuctio is equivalet to the dispatcher fuctio i the case of dedicated resources as discussed above. The class-of-service weights of the dispatcher are determied by a workload maager that supervises the dispatcher. Drive by a utility fuctio describig the beefits of the classes of service, the workload maager moitors the goal compliace of the classes of services ad readjusts the weights of the correspodig queues. For example, if ot may best requests are arrivig at a give momet ad performace goals are exceeded but medium goals are ot met, the medium request queue will be give more weight at the expese of the best queue. A example of a more complex workload maager for is WLM [9]. Usig this approach of shared resources, resource usage is sigificatly higher for services beig offered at differet performace levels at the expese of a more sophisticated dispatcher, which could become a bottle eck, ad a classificatio of performace levels that ca lead to over-servig may requests. 3.3 Combiig approaches To avoid a dispatcher bottle eck ad to deal with differet services ad large umbers of performace classes o those differet services, those above-metioed approaches are ofte combied, as outlied i figure 5. 1 Cotractig Goal 1 Broze 2 Respose Time Goal Pealties Cotractig Provisioig Workload Utility Fuctios of s Utility Fuctios of Respose Time Classes Figure 5: Combiig approaches for comprehesive respose time maagemet. The server pool is divided by the provisioig maager ito servers associated with a particular service, to a set of operatios of a service, or further ito servers dedicated to oe or more classes of service. As discussed above, the provisioig maager uses a utility fuctio for the arbitratio betwee its segmets. The requests to each of the segmets of servers are drive by a separate dispatcher. A dispatcher is associated to a workload maager that periodically reevaluates the parameters of its schedulig algorithm, e.g., the queue weights. This raises the issue where the utility fuctios come from. If the service provider offers differetiated services, a cotractig fuctio allows prospective customers to subscribe to a service ad egotiate the QoS terms as well as the pricig ad pealty coditios. Based o pridig ad pealty, the cotractig fuctio derives the correspodig utility fuctios for provisioig ad workload maager. Depedig o the flexibility offered to customers i the subscriptio process, the derivatio of the utility fuctios is ofte ot a automated process but may ivolve cosideratios of a system admiistrator of the service provider that is familiar with the cost fuctios of the server cluster [10]. 3.4 Implemetig other QoS aspects Server 1 1 Server m 1 Server 2 Server z 2 I additio to performace maagemet, aother mai QoS parameter that is importat to service providers ad cliets is availability. All major vedors of systems maagemet software such as IBM/Tivoli, Hewlett- Packard ad Hitachi address this issue. I the cotext of

5 Web services, a service is ot available if it does ot yield respose i a defied amout of time, which is usually much higher tha a respose time guaratee. It is beig addressed by makig redudat resources available, which icludes servers as well as, potetially, etwork coectios. Agai, redudat resources ca be dedicated to a particular scope of QoS or ca be shared betwee multiple services. A utility fuctio drives the arbitratio i case of eed of redudat resources. Other QoS such as time to recover have bee equally addressed i theory ad as available systems. 4. Web services-specific issues As discussed i sectio 3, systems maagemet approaches provide may solutios that ca be adapted to a service-orieted architecture. For example, the dispatcher approach to maage shared resources ca be used by usig a etry i the SOAP header of a message as a label for a requested QoS level. However, i the field of service-orieted computig ad Web services, we face a umber of additioal issues. Those additioal issues regardig the implemetatio of quality of service mostly origiate i the abstract cocept of a service ad its itetioally weak associatio with actual computig ad etworkig resources. 4.1 Takig etworkig ito accout s wat to defie QoS parameters from their perspective. While this is ot so much a issue i traditioal distributed systems, where the etwork ad other system eviromet compoets are uder cotrol of the same orgaizatio, it has to be take ito accout by providers ad users of Web services. Network Ukow Itermediary Network Server Provider Network Figure 6: access over public etworks. May o-corporate etwork users ad small ad medium-sized busiesses do t have QoS guaratees regardig their access to the Iteret. However, it is importat for them to obtai quality of service guaratees as they perceive a service. Iovative solutio are requested to be able to budle QoS properties of a service applicatio with the properties of the provider s etwork, the cliet s etwork ad the etwork coectig both. 4.2 Composite web services s are ofte to be icluded i composite Web services defied usig, for example, BPEL4WS [11] or other descriptio laguages. Usig those laguages ad correspodig workflow maagemet systems, services of differet providers ca be itegrated. Figure 7 outlies a simple example of a stock trade workflow. Get Trade Data >1000 shares y Etry Small Orders Match Sed to Specialist House Trade Figure 7: Cotiget cotrol flow of services. I this case of a process composed of services, we have to uderstad how the idividual QoS properties of oe elemet of a composite service cotribute to the overall QoS of the process. This is particularly iterestig i the case of stochastic QoS: I 90% of the cases, the average respose time will be less tha 2 secods. I additio to the likelihood of differet alteratives o the process graph, we have to take ito accout the QoS properties of idividual services. I the case of processig time, for example, the variace of service processig times of idividual steps is icreased by the variace of the overall process such that a it is difficult to give good aggregate QoS parameters for the whole process. Approaches to address this problem may start with defiig QoS properties of services whe modelig a process ad bidig to particular services [12]. I additio, composite services may specify QoS properties depedet o the iput data ad the expected path of the executio. I additio, alterative services may be ivoked at the same time for a particular step, the best fastest oe used ad the others aborted. However, this area requires more research ad ovel ideas. 4.3 Recursively composed services Fially, composite services as outlied above ca be offered as web services, thereby creatig recursive service relatioships. The figure below shows a multi-level service aggregatio of our previous example. NYSE Stock Quote Stock Quote Frakfurt Stock Quote Lodo Stock Quote Figure 8: Recursive service compositio. y Share Trade Match-makig Accout. Clearig

6 With a icreasig umber of aggregatio steps, stochastic QoS properties get very broad ad meaigless very quickly. How ca we fid meaigful QoS properties for those aggregates ad what are the limits of aggregatio from a QoS poit of view? I additio, how ca a service provider of a aggregate service esure a reasoable level of quality to its cliets, particularly with respect to respose time ad availability? A promisig approach lies i usig the dyamic properties of public Web services i that ca be purchased o the spot from potetially multiple providers. s ca be bought from differet providers ad oly those will be used i a give ivocatio that respod fast. For this approach, we eed mechaisms that ivoke multiple services i parallel ad use the results of the fastest. I additio, we eed the correspodig busiess models for Web services that oly pay (i full) for a service if it was faster tha others. With respect to availability maagemet, service providers ca buy redudat services. However, they must make sure that they, i tur, do ot deped o the same uderlyig service, which would aul their redudacy, at least partially. We eed methods to describe depedecies o other services ad match-makig approaches that take those depedecies ito accout. 5. Coclusios ad call for future work I this keyote we discuss ope research issues related to the QoS maagemet of Web services. While the represetatio of Web services QoS properties has bee addressed i curret work, the implemetatio of QoS relies maily o existig work related to allocatig dedicated resources ad maagig the workload of shared resources. However, due to the virtualizatio of services ad the tred to compose services to complex aggregates ad to re-offer them, ew approaches are eeded to be able to implemet the QoS of those complex services o a level required by busiess customers. More research is eeded to apply the flexibility offered be Web services to solve the problems raised by this flexibility. Refereces [1] N. Cataia, P. Kumar, B. Murray, H. Pourhedari, W. Vambeepe, K. Wurster, Web s Maagemet Framework, Versio 2.0, Hewlett-Packard, -WSM.jsp, July 16, [2] H. Ludwig, A. Keller, A. Da, R. Kig, R. Frack, A service level agreemet laguage for dyamic electroic services, Electroic Commerce Research, Kluwer Academic Publisher, 3:2003, pp [3] H. Ludwig, A. Keller, A. Da, R. Kig, R. Frack, Web Level Agreemet (WSLA) Laguage Specificatio, Versio 1.0, IBM Corporatio, Jauary 28, [4] V. Tosic, B. Pagurek, K. Patel, WSOL A Laguage for the Formal Specificatio of Classes of for Web s. Proc. of ICWS'03 (The 2003 Iteratioal Coferece o Web s), Las Vegas, USA, Jue 23-26, 2003, CSREA Press, pp [5] D. Box, F. Curbera, M. Hodo, C. Kale, D. Lagworthy, A. Nadali, N. Nagaratam, M. Nottigham, C. vo Riege, J. Shewchuk, Web s Policy Framework (WSPolicy), May 28, [6] D. Coolly, F. va Harmele, I. Horrocks, D. L. McGuiess, P. F. Patel-Scheider, L. A. Stei, DAML+OIL (March 2001) Referece Descriptio, W3C, December 18, [7] C. Crawford, A. Da, emodel: Addressig the Need for a Flexible Modelig Framework i Autoomic Computig, IEEE/ACM Iteratioal Symposium o Modelig, Aalysis ad Simulatio of Computer ad Telecommuicatios Systems (MASCOTS 2002). [8] R. Levy, J. Nagarajarao, G. Pacifici, M. Spreitzer, A. N. Tatawi, A. Youssef: Performace Maagemet for Cluster Based Web s, Itegrated Network Maagemet VII, Maagig It All, IFIP/IEEE Eighth Iteratioal Symposium o Itegrated Network Maagemet (IM 2003), IFIP Coferece Proceedigs 246, Kluwer Academic Publisher, 2003, pp [9] J. Ama, C. K. Eilert, D. Emmes, P. Yocom, ad D. Dilleberger, Adaptive algorithms for maagig a distributed data processig workload, IBM Systems Joural, Volume 36, 2, 1997, pp [10] H. Ludwig, Electroic Cotracts, Techology Supportig Busiess Solutios: Advaces i Computatio: Theory ad Practice, Nova Sciece Publishers, 2003, pp [11] T. Adrews, F. Curbera, H. Dholakia, Y Golad, J. Klei, F. Leyma, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, S. Weerawaraa, Busiess Process Executio Laguage for Web s Versio 1.1, ibm.com/developerworks/webservices/library/wsbpel/, 05 May [12] E. Wohlstadter, S. Tai, T. Mikalse, I. Rouvellou, P. Devabu, GlueQoS: Middleware to Sweete Quality-of- Policy Iteractios, Proceedigs 26th Iteratioal Coferece o Software Egieerig (ICSE 2004), Ediburgh, Scotlad, UK, 2004.