Elastic Virtual Machine Scheduling for Continuous Air Traffic Optimization

Transcription

1 lastic Virtual Machin Schuling for Continuous Air Traffic Optimization Shigru Imai, Stacy Pattrson, an Carlos A. Varla Dpartmnt of Computr Scinc Rnsslar Polytchnic Institut Abstract As w ar facing vr incrasing air traffic man, it is critical to nhanc air traffic capacity an allviat human controllrs workloa by viwing air traffic optimization as a continuous/onlin straming problm. Air traffic optimization is commonly formulat as an intgr linar programming (ILP) problm. Sinc ILP is NP-har, it is computationally intractabl. Morovr, a fluctuating numbr of flights changs computational man ynamically. In this papr, w prsnt an lastic milwar framwork that is spcifically sign to solv ILP problms gnrat from continuous air traffic strams using a Lagrangan approximation ovr an IaaS clou. W propos a mol-bas spculativ VM schuling algorithm: it implmnts a tim sris priction mol to ci whn to allocat/allocat VMs, an it also uss a rsourc priction mol to stimat how many VMs to allocat/allocat. xprimnts show that our spculativ VM schuling algorithm can achiv a similar prformanc to a static schul whil using 49% lss VM hours for a smoothly changing air traffic. Howvr, for a sharply changing air traffic, our spculativ VM schuling algorithm costs slightly mor VM hours to achiv th sam prformanc. Our algorithm is abl to aapt ynamically to potntially unforsn fluctuating man with a rasonabl priction accuracy. 1. Introuction Th numbr of flight passngrs is xpct to rach 7.3 billion by 2034 globally, which rquirs a 4.1% avrag growth in flight capacity in vry yar from 2014 on [1]. Air traffic optimization is crucial to nhanc flight capacity an also allviat human controllrs workloa. Air traffic managmnt problms ar commonly formulat as intgr linar programs (ILP), which ar known to b NPhar [2]. Thrfor, larg-scal ILP problms ar computationally intractabl. Morovr, sinc th numbr of flights fluctuats a lot in practic, computational mans for air traffic optimization also chang ynamically. For xampl, Figur 1 shows how th numbr of commrcial flights in th U.S. chang ovr 24 hours from 4am ST on January 18th, Onc air traffic hits th pak at aroun 1pm, it graually rops an vntually rachs 200 at aroun 3am. To kp up with th fluctuating computing mans in a cost-fficint way, w can ynamically allocat an allocat virtual machins (VMs) from Infrastructur-as-a- Srvic (IaaS) clou computing provirs. Th challng is ynamically choosing th right numbr of VMs that satisfis computational mans at th lowst possibl cost. Figur 1. xampl of U.S. flights on January 18th, 2014 (crat from ata availabl on [3]). ILP has a lot of practical applications, an som of thm hav a strong tim-pnncy. xampls of such applications inclu: public transportation routing [4], invstmnt portfolio optimization [5], an markting bugt optimization [6], [7]. Just as air traffic managmnt, public transportation routing has similar charactristics:.g., th numbr of buss changs pning on tim of th ay. Invstmnt portfolios must b valuat prioically to kp up with stock markts. Avrtisrs look for an optimal way of spning thir mony across both traitional an onlin mia; howvr, avrtismnt costs always chang spcially for onlin avrtismnts such as Googl A- Wors [8] bcaus of its biing mchanism [7], [9]. Ths tim-pnnt factors can fluctuat th computational cost of optimization to a larg gr. lastic ILP milwar is potntially usful for many application aras consiring ths applications tim-pnnt bhaviors. To implmnt such an lastic ILP milwar, w can ithr aaptivly ajust th numbr of VMs at runtim without any prior knowlg of th application or proactivly prict th numbr of VMs using a rsourc priction mol. Th formr inclus a thrshol-bas approach, as us in Amazon s Auto Scaling [10], an rinforcmnt larning [11], [12]. In this papr, w tak th lattr approach with th intntion to improv th rsourc utilization, cost, an latncy violations. That is, w mol rquir computational rsourcs to solv an ILP problm formulat for air traffic

2 managmnt. Morovr, w us an autorgrssiv tim sris priction mol to ci whn to allocat/allocat VMs in a spculativ mannr. To th bst of our knowlg, this is th first attmpt to prsnt an lastic milwar framwork spcifically sign to solv ILP problms crat from continuous air traffic strams. Hr is th summary of our contributions: W vlop an lastic milwar framwork (Sction 3) to solv optimization problms crat from continuously incoming air traffic strams (Sction 2) ovr IaaS clous. Th framwork obtains an approximat solution to ILP problms using a twolvl optimization tchniqu bas on Lagrangan composition [13]. W sign VM schuling algorithms that ar spcifically sign to solv ILP problms gnrat from continuous air traffic strams (Sction 4). W us a tim sris priction mol to ci whn to allocat VMs an w also us a rsourc priction mol to stimat how many VMs to allocat. Th rsourc priction mol stimats rquir VM rsourcs givn th numbr of flight routs an targt procssing latncy by using linar rgrssion. xprimnts show that our spculativ VM schuling algorithm can achiv a similar prformanc to a static schul whil using 49% lss VM hours for a smoothly changing air traffic. Our algorithm is abl to aapt ynamically to potntially unforsn fluctuating man with a rasonabl priction accuracy. Th rst of th papr is organiz as follows. First, in Sction 2, w formulat an air traffic managmnt problm as an ILP problm an scrib how w apply Lagrangan composition to th fin ILP problm. Nxt, w prsnt th sign of our lastic air traffic managmnt milwar in Sction 3 an VM schuling algorithms in Sction 4. Thn, in Sction 5, w prsnt valuation rsults for th propos VM schuling mtho. Finally, w prsnt rlat work in Sction 6 an conclu th papr in Sction Air Traffic Managmnt Problm 2.1. Problm Formulation Th Link Transmission Mol (LTM) [14] is an air traffic flow managmnt mol that optimizs nationwi air traffic by formulating it as an ILP problm. Cao an Sun compos th original LTM problm into multipl subproblms using Lagrangan composition an us MapRuc [15] to approximat th solution to larg scal LTM problms in paralll [16]. Our work is inspir by thir approach. W formulat a simplifi vrsion of th LTM problm that capturs th computationally intnsiv natur of th original LTM problm. Figur 2 shows an xampl of th simplifi air traffic managmnt problm. A rout conncts a partur airport an an arrival airport, an it consists of multipl links that ar istribut ovr multipl sctors. As illustrat in th xampl, th sam sctor at th cntr of th gri is shar by multipl routs, thrfor congstion must b controll. > ^ Figur 2. xampl of th simplifi air traffic managmnt problm. W can formaliz th simplifi air traffic managmnt problm as an ILP problm as follows: maximiz subjct to Kÿ c i x i (1) Kÿ A i x i ď b (2) 0 ď x P r1, K s, (3) ÿn i x j i ď P r1, Ks, (4) j 1 whr x j i P Z ě 0, A i P t0, 1u S,Ni, b P Z S ě 0, c i P R Ni ě 0, i P Z ě 0. Th objctiv of this optimization problm is to assign an ial numbr of flights to ach sctor so that w can maximiz th air traffic capacity whil satisfying capacity of ach sctor. Givn constants ar: th numbr of routs K, th numbr of links of th i-th rout N i pi 1,..., Kq, an th numbr of sctors S. Th numbr of flights for a rout i is xprss as a vctor x i rx 1 i, x2 i,..., xni i s, whr x j i P Z ě 0 is th numbr of flights at link j of th rout i. x i pi 1,..., Kq ar th variabls to b optimiz subjct to th following capacity constraints: Sctor capacity: Total numbr of flights in a sctor s must b lss than or qual to b s P Z ě 0 ps 1,..., Sq (Inquality (2)). Rout capacity: Total numbr of flights on a rout i must b lss than or qual to i P Z ě 0 pi 1,..., Kq (Inquality (4)). Th objctiv function ř K c i x i is fin with vctors c i rc 1 i, c2 i,..., cni i s pi 1,..., Kq, whr c j i P R ě 0 trmins th gr of prfrnc of assigning flights

3 on link j of rout i. W can st highr valus for lss congst sctors an lowr valus for highly congst sctors. Th sctor capacity constraint is fin by Inquality (2) using S ˆ N i matrics A i pi 1,..., Kq an a vctor b rb 1, b 2,..., b S s, whr b s P Z ě 0. For a rout i, th mapping of links to sctors naturally ictats th construction of A i ; ach lmnt a sj taks th valu of 1 if link j is on sctor s, othrwis 0. ach lmnt of b trmins th sctor capacity of a corrsponing sctor. A solution to this problm capturs th two important proprtis of th original LTM problm that affct th computational workloa. First, aing a nw rout incrass th numbr of variabls in proportion to th numbr of links on th rout. Scon, ach A i matrix is xtrmly spars, which significantly affcts th ifficulty of satisfying constraints bcaus thr ar vry fw numbr of variabls in ach constraint Lagrangan Dcomposition ILP is NP-har. Thus, it is common to us algorithms that fin an approximat solution in a rasonabl amount of tim. Lagrangan composition is a popular tchniqu to obtain an approximat solution to ILP problms, an it was us for LTM in [16]. Lagrangan composition offrs a way to split a largr linar intgr problm into multipl smallr sub-problms by rlaxing complicating constraints. For our air traffic managmnt problm scrib in Sction 2.1, th complicating constraint is th sctor capacity constraint (Inquality (2)), which prohibits us from sparating th original problm into K sub-problms with Inquality (3) an (4). By constructing a Lagrangan rlaxation of th original problm, w can bring th complicating constraints to th objctiv function as a pnalty trm as follows: Kÿ maximiz c i x ÿ K i λ A i x i b (5) subjct to 0 ď x i, ÿn i j 1 x j i ď i whr λ P R S ě 0 is a vctor of Lagrang multiplirs. Now, w can compos th problm (5) into a smallr sub-problms, on for ach rout i: maximiz c i λ A i x i (6) subjct to 0 ď x i, ÿn i j x j i ď i. Nxt, w fin th mastr ual problm of th Lagrangan (5), which is rsponsibl for upating λ: minimiz gpλq subjct to 0 ď λ, Kÿ pc i λ A i qx i ` λ b (7) Algorithm 1: Two-lvl ILP optimization input : A i, c i, ipi 1,..., Kq, b, λ init, δ, I output: x ipi 1,..., Kq, minobj 1 t Ð 0; 2 λptq Ð λ init; 3 minobj Ð Doubl.MAX VALU; 4 whil Itrations minobj not improv mor than δ% ă I o 5 // Solv K sub-problms 6 for i 1 to K o 7 x i Ð solvilppa i, c i, i, λptqq; 8 n 9 // Upat mastr objctiv 10 obj Ð compobjpa 1,..., A K, b, c 1,..., c K, x 1,..., x K, λq; 11 if obj ă minobj thn 12 minobj Ð obj; 13 n 14 // Upat λ for th nxt itration 15 α 1 t ; 16 λpt ` 1q Ð λptq α graintpa i, b, x iq; 17 t Ð t ` 1; 18 n 19 rturn x ipi 1,..., Kq, minobj; whr x i is th optimal solution to th sub-problm (6) for a rout i. To solv λ for th ual problm (7), w us th graint mtho: K Bg Bλ b ÿ A i x i (8) λpt ` 1q λptq α Bg Bλ, (9) whr α is a small positiv stp-siz. As shown in Algorithm 1, w itrativly solv th K sub ILP problms to fin optimal x i pi 1,..., Kq for a spcific λ (Lin 7) an upat λ for th mastr ual problm (Lin 16). W kp track of th minimum valu of objctiv (minobj), an if it is not improv by mor than δ% for I itrations, w go out from th whil loop an rturn th final rsults. 3. lastic Air Traffic Managmnt Milwar 3.1. Backgroun Systm intraction. W assum that th usr of th milwar is a human air traffic controllr who uss output of our milwar for air traffic control activity. W also assum that som flight information provirs (.g., FlightAwar [17]) or airplans irctly sn th latst flight status information to th milwar (s Figur 3). Sinc air traffic managmnt is tim critical, th milwar tris to schul VMs so that th optimization rsult can b us by th usr in a timly mannr. Hnc, th usr can configur latncy to rqust how quickly th application shoul rturn th rsult.

4 Clou ploymnt. Th milwar is sign to work on an IaaS clou. Th IaaS clou can b privat, public, or hybri; howvr, th schuling algorithm prsnt in Sction 4.3 is optimiz for public IaaS clous u to its billing cycl awar schuling. Th billing cycl is th unit of montary charg (.g., 1 hour for Amazon C2 [18]). Th schulr only trminats VMs just bfor thir billing cycl so that th application can us th VMs computing powr until th last minut Application Implmntation W us Spark [19], a gnral clustr computing ngin, to implmnt Algorithm 1. Spark s high-lvl abstractions for istribut programming an in-mmory ata procssing faturs ar suitabl for th itrativ ILP problm solving procss. Spark applications run on a clustr consisting of a mastr no an multipl workr nos. In Algorithm 1, xcutors running on th workr nos xcut Lin 7 to solv K sub-problms in paralll, an th rst of th co is xcut on th mastr no. Whil Spark allows us to cach paramtrs A i, c i, i for sub-problms on ach workr no, th mastr ns to broacast th upat valu of λ to th workrs in ach itration. Whn xcutors solv th sub-problms, w us lp solv [20] sinc it is opn-sourc an thra-saf. Sinc Spark runs multipl thras in on xcutor procss in paralll, thra safty is a rquir proprty for th ILP problm solvr Milwar Architctur Figur 3 illustrats th architctur of th propos milwar framwork. W scrib how th milwar works, stp by stp, as follows: Stp 1: Th Controllr prioically pulls (.g., vry 5 minuts) flight status information in th quu such as airplan positions an flights partur an arrivals. Stp 2: Th Controllr crats an ILP problm instanc from th obtain flight status information an thn pushs it to th VM Schulr with rqust procssing latncy (.g., 4 minuts). Stp 3: Th VM Schulr uss a tim sris priction mol an a rsourc priction mol to stimat th rquir numbr of VMs to finish th optimization within th rqust procssing latncy. Stp 4: Th VM Schulr allocats or allocats VMs accoringly by calling clou APIs such as th ons provi by Amazon C2 [21]. Stp 5: Th Controllr rqusts th Application Launchr to run th ILP application. vn though flight status information flows into th milwar continuously, th milwar procsss th information collct within a sliing tim winow. W can s this as a iscrtiz stram procssing mol just as us in Spark straming [19]. Z sd W h W/>W D D Z Figur 3. Architctur of th lastic air traffic managmnt milwar framwork. 4. Virtual Machin Schuling In Sction 4.1, w first confirm how th ILP optimization application scrib in Sction 3.2 prforms on actual VMs through a prliminary xprimnt. Nxt, in Sction 4.2, w scrib a rsourc priction mol crat using linar rgrssion. Finally, in Sction 4.3, bas on obsrvations from th prliminary xprimnt an th rsourc priction mol, w prsnt two VM schuling algorithms: basschulr an spcschulr Prformanc Charactrization of ILP Optimization To unrstan how th Spark application works, w conuct a prliminary xprimnt with th following sttings: Numbr of links pr rout: gnrat from a Gaussian istribution (avrag = 19, varianc = 9). Numbr of sctors: 1024 ma of a 32 by 32 gri just as shown in Figur 2. Convrgnc critrion: th valu of mastr ual objctiv in quation (7) os not improv mor than 1% for 1000 itrations (i.., δ 1, I 1000 in Algorithm 1). Spark stting: 1 xcutor pr cor. W tst 50 application runs with ranomly slct VM instancs an numbr of routs from th following options: VM instancs for Spark workr nos: {c4.larg, c4.xlarg, c4.2xlarg} instanc typs availabl from Amazon C2 (s Tabl 1). Up to fiv instancs can b crat for ach instanc typ.

5 Numbr of routs: {128, 256, 512, 1024} TABL 1. AMAZON C2 VM INSTANC TYPS USD IN XPRIMNTS (INFORMATION AS OF NOVMBR 2015). Nam vcpu cors Cost [USD/hr] Instanc limits c4.larg c4.xlarg c4.2xlarg Figur 4 prsnts th rlationship btwn total numbr of cors us by th VMs an th application xcution tim. First, w obsrv that th prformanc varianc is rlativly small (at most 7%) rgarlss of VM configurations as long as w us th sam numbr of cors for th sam numbr of routs. This is u to th fact that w assign on thra pr cor, an thrfor, w n up using th sam numbr of thras vn for iffrnt VM configurations as long as thy hav th sam numbr of cors. Scon, as w can clarly s from th graph, th application xcution tim os not improv significantly from aroun 18 to 20 cors for all numbrs of routs. This bhavior is consistnt with a prformanc analysis of a K-mans Spark application rport in [22], in which th prformanc convrgs at aroun 15 thras. Thy conclu that multi-thra computation ovrha (i.., work tim inflation [23]) an loa imbalanc caus th scalability bottlnck. Sinc our application an K-mans hav a similar synchronization pattrn (i.., both ar itrativ an synchroniz all workrs btwn vry itration), this analysis applis to our cas as wll. Ths achiv th targt procssing latncy. W us linar rgrssion with a non-linar transform to mol th rlationship btwn th two input paramtrs: procssing latncy l an numbr of routs r, an th output: numbr of cors c. W sampl 50 application runs using th sam xprimntal sttings as th prliminary xprimnt in Sction 4.1, but this tim with uniformly ranom numbrs of routs btwn 100 an Subsquntly, w tst fiv non-linar transforms to trmin which on bst fits th sampl training ata as shown in Tabl 2. As th transformation bcoms mor complx, corrlation btwn th mol an th training ata improvs. Bas on this rsult, w hav intifi Φ -2:2 to b th most corrlat with th ata. W thus us this mol in our algorithms. Th numbr of cors can b obtain as follows: fpl, rq w Φ -2:2 pl, rq, (10) whr w rw 1, w 2,..., w 11 s is a wight vctor acquir from linar rgrssion of th numbr of cors givn th latncy an th numbr of routs. TABL 2. NON-LINAR TRANSFORMS USD FOR LINAR RGRSSION. Nam Transformation vctor Corrlation Φ -1 r1{r, 1{l, 1s Φ 2 r1, r, l, r 2, rl, l 2 s Φ -2 r1{r 2, 1{rl, 1{l 2, 1{r, 1{l, 1s Φ -2:1 r1{r 2, 1{rl, 1{l 2, 1{r, 1{l, 1, r, ls Φ -2:2 r1{r 2, 1{rl, 1{l 2, 1{r, 1{l, 1, r, l, r 2, rl, l 2 s lastic Schuling Algorithms l l l l Th VM Schulr prioically calls on of th schuling algorithms to kp th procssing latncy consistnt. W scrib two schuling algorithms for th VM Schulr that us th mol prsnt in Sction 4.2. Ky notations us in th algorithms ar summariz in Tabl 3. Figur 4. Charactristics of th ILP problm xcution tim. obsrvations la to th following cisions for th rsourc allocation mtho sign: Th unit of rsourc ()allocation is th numbr of cors. Sinc th prformanc an cost pr cor is qual among {c4.larg, c4.xlarg, c4.2xlarg}, w o not istinguish on VM instanc typ from anothr. W st th uppr limit for th numbr of cors that w allocat to match th application s inhrnt scalability limitations Rsourc Priction Mol Th VM Schulr introuc in Sction 3.3 ns a mol to trmin how many rsourcs it shoul allocat to TABL 3. KY NOTATIONS USD IN SCHDULING ALGORITHMS. Nam Dscription l rq Rqust procssing latncy. r t Numbr of routs to procss at tim t. t up VM startup tim. fpl, rq Rsourc priction mol that pricts th numbr of cors to satisfy latncy l whn procssing r routs. V act St of VMs that ar activly us by th application. V il St of VMs to b rmov at th n of nxt billing cycl. V spc St of spculativ VMs to b allocat. V St of currntly allocat VMs. V V act Y V il. t bc pvq Nxt billing cycl tim of a VM v P V. cpvq Numbr of cors of a VM v P V Baslin Schuling. Th baslin schuling algorithm (basschulr) is shown in Algorithm 2. This algorithm rspons to incrasing computational man by crating nw VMs, whil at th sam tim, tris to tak

6 avantag of xisting VMs vn whn thy ar not n to achiv rquir procssing latncy. First, w compar th availabl numbr of cors c all with rquir cors c rq stimat from th rsourc priction mol f (Lin 1-3). If thr ar nough cors, w sort V in scning orr of nxt billing cycls (th VM with th latst billing cycl coms first) (Lin 5). Thn, w lt slctvms slct at last c rq worth of VMs from th sort V an put thm to V act an th rst of VMs to V il (Lin 6 an 7). Furthr, if thr still rmains VMs in V il such that thir billing cycls com aftr th tim that w xpct th application to finish, w utiliz thos VMs V xtra too (Lin 9-11). At this point, VMs in V il ar xpct to n thir billing cycls bfor th application finishs, an thrfor thy will b allocat. If thr ar not nough cors to satisfy th rqust latncy, w hav to allocat nw VMs to satisfy th rqust latncy. Sinc nwly allocat VMs tak t up tim bfor thy bcom fully oprational, w can only start running th application aftr t up tim has pass. Thrfor, w st a tightr alin l rq t up an stimat th numbr of cors to allocat c alloc again (Lin 15). Thn, w call th allocvms sub-routin to allocat at last c alloc worth of VMs an upat V act an V il accoringly. Algorithm 2: basschulr (Baslin VM schuling algorithm) input : l rq, r t, t up, V output: V act, V il 1 c rq Ð rfpl rq, r tqs; 2 c all Ð ř vpv cpvq; 3 if c rq ď c all thn 4 // Thr ar nough cors 5 Sort v P V in scning orr of t bc pvq; 6 V act Ð slctvmspc rq, V q; 7 V il Ð V V act; 8 V xtra tv v P V il, t ` l rq ă t bc pvqu; 9 if V xtra H thn 10 V act Ð V act Y V xtra; 11 V il Ð V il V xtra; 12 n 13 ls 14 // Not nough cors, allocat VMs 15 c alloc Ð rfpl rq t up, r tqs c all ; 16 V act Ð V Y allocvmspc alloc q; 17 V il Ð H; 18 n 19 rturn V act, V il ; Spculativ Schuling. Th spculativ schuling algorithm (spcschulr) is shown in Algorithm 3. This algorithm taks avantag of futur computational man priction an tris to allocat VMs bfor thy ar n. By oing so, w can avoi waiting a VM startup tim bfor running th application. W prict th numbr of routs for tim t ` 1 using a slop comput from r t an r t 1 as follows. r t`1 r t r t 1 t pt 1q ` r t 2r t r t 1. (11) This priction mol is quivalnt to an autorgrssiv mol (i.., AR(2)) just as us in [24], [25]. Th spcschulr first obtains a baslin configuration using th basschulr an computs all of availabl numbr of cors in c all (Lin 2-3). Nxt, spcschulr pricts th numbr of routs for th nxt stp in ˆr t`1 by using th priction mol of quation (11) (Lin 5). Using ˆr t`1 an th rsourc priction mol f, w stimat a spculativ rquir cors ĉ rq. Finally, if w n mor cors at nxt tim stp than what w currntly hav (c all ă ĉ rq ), thn w schul to launch VMs that ar worth ĉ rq c all cors just bfor th nxt tim stp (Lin 8 an 10). Algorithm 3: spcschulr (Spculativ VM schuling algorithm) input : l rq, r t, r t 1, t up, V output: V act, V il, V spc 1 // Obtain a baslin configuration first 2 pv act, V il q Ð basschulrpl rq, r t, t up, V q; 3 c all Ð ř vpv cpvq; 4 // Spculativ VM allocation 5 ˆr t`1 Ð prictnumroutspr t, r t 1q; 6 ĉ rq Ð rfpl rq, ˆr t`1qs; 7 V spc Ð H; 8 if c all ă ĉ rq thn 9 // Schul to finish launching V spc VMs bfor th nxt tim stp 10 V spc Ð schulallocvmspĉ rq c all q; 11 n 12 rturn V act, V il, V spc; VM Allocation Policy. Givn th numbr of cors, w allocat VMs from a limit pool of VMs whn xcuting allocvms (Lin 16, Algorithm 2) an schulallocvms (Lin 10, Algorithm 3). Whn slcting VMs, w try to allocat a VM typ with smallr numbr of cors. If a VM typ rachs its instanc cration limit, thn w try to allocat VM typs with biggr numbr of cors until at last th rqust numbr of cors is allocat. In cas of Amazon C2, w try to allocat c4.larg instancs first, an thn w try c4.xlarg follow by c4.2xlarg. Th rason that w giv priority to smallr instancs is bcaus thy hav finr cor granularity. That is, w woul hav a highr chanc of allocating xact numbr of cors so that w can avoi ovr provisioning of VMs. 5. valuation W first introuc simulation bas xprimntal sttings in Sction 5.1. Nxt, w valuat th propos algorithms lastic bhavior in Sction 5.2. Thn, w compar th propos algorithms prformanc with static VM schuling an thrshol-bas auto scaling in Sction 5.3 an 5.4 rspctivly.

7 5.1. xprimntal Sttings Th xprimnts ar simulation-bas. W vlop a simulator that xcuts propos VM schuling algorithms. Using th gnrat schuls by th simulator, w manually allocat an allocat VMs on Amazon C2 clou an run th Spark application to valuat us VM hours, cost, an latncy violations bas on actual xcution tim. W us two 3-hour rout atasts for tsting: th first on is call Nationwi that w crat from th 24-hour ral nationwi flights shown in Figur 1, an th scon on is call Dallas that w crat bas on a simulat flights ovr Dallas/Fort Worth ara [26]. Both hav almost th sam pak numbr of routs, about 1200, but th pattrns of fluctuation ar iffrnt. Whil Nationwi has a smooth curv, Dallas has stp spiks, as shown in Figur 7. W us th following tst paramtrs for valuation: Schuling intrval: 5 minuts (36 schuling problms ovr 3 hours). Rqust procssing latncy (l rq ) : 4 minuts. VM startup tim (t up ): 90 scons. VM instancs for Spark s workr nos: {c4.larg, c4.xlarg, c4.2xlarg} (s Tabl 1 for tails). Up to fiv instancs can b crat for ach instanc typ. Billing cycl: 1 hour (Amazon C2 s fault) lastic Bhavior Confirmation Nationwi Datast. Rsults for basschulr an spcschulr for th Nationwi atast ar shown in Figur 5(a)-(). From Figur 5(a), w s that th baslin schulr allocats VMs, initially for 8 cors at 1900 scons an thn for 12 cors at 3900 scons. Looking at Figur 5(b), w notic that thr ar two ips in rqust latncy at th sam tim as th schulr allocats nw VMs. This lowr latncy corrspons to th valu of l rq t up (= 150 scons) at Lin 15 of Algorithm 2. To account for th VM startup tim, w intntionally st a tightr latncy. Thrfor, th schuling algorithm has to allocat rlativly larg numbr of cors. Sinc ths cors ar mor than nough to satisfy th rgular rquir latncy l rq (= 240 scons), thr ar prios (2100 to 2700 scons, 3900 scons to th n) whn xcution tim stays lowr than rquir, that is, rsourcs ar ovr-provision uring ths prios. This is a limitation of th ractiv approach. Thr ar four latncy violations occurring at 1800, 3300, 3600, an 3900 scons rspctivly. At ths tims, thr ar xactly th sam numbr of cors availabl as th rsourc priction mol stimat. This mans that th priction mol unrstimat th numbr of cors n to satisfy th rqust latncy. Th avrag priction rror of xcution tim for th four violations is 12%. This rsult suggsts that th accuracy of rsourc priction is limit an w may n to ovr-provision VMs intntionally. Th total cost for th bas schulr is $1.72 an latncy violations ar 4 out of 36. From Figur 5(c), w can visually confirm that th spculativ schulr graually allocats smallr numbrs of cors, unlik th baslin schulr which abruptly allocats largr numbrs of cors. This is a irct ffct of th spculativ VM allocation. In fact, all th allocat VMs ar launch by schulallocvms at Lin 10 in Algorithm 3. Sinc thr ar alray nough cors by th tim basschulr at Lin 2 tris to schul, it os not n to crat any nw VMs. As a rsult, thr ar no latncy rops in Figur 5(). Th total cost for th spculativ schulr is $1.01 an latncy violations ar 2 out 36. Th cost is a 41% improvmnt compar to th baslin schulr. Figur 6 shows a VM allocation squnc from th spculativ schulr crat from th Nationwi atast. W can s that fiv c4.larg instancs (ID = 0 to 4) ar allocat by 2910 scons, an thn a c4.xlarg instanc (ID = 5) is allocat at 3210 scons. Intrstingly, at 9900 scons, th schulr chooss to kp th c4.xlarg instanc insta of th c4.larg (ID = 4) instanc vn though th c4.larg can also satisfy th rqust procssing latncy. This is bcaus th c4.xlarg will hav th billing cycl latr than th c4.larg os; howvr, in a truly continuous optimization scnario, it may b lss critical bcaus wast VM hours will b ngligibl compar with th application xcution tim Dallas Datast. Rsults for basschulr an spcschulr for th Dallas atast ar shown in Figur 7(a)-(). From Figur 7(a), w can confirm that th baslin schulr allocats VMs for 6 cors at 1200 scons an thn for 12 cors at 7800 scons. In Figur 7(c), th spculativ schulr follows changs of th routs smoothly for th first stag of th squnc; howvr, at 7500 scons, it fails to prict th numbr of routs corrctly an ns up allocating lss VMs than actually n at 7800 scons. It allocats two mor VMs at 7800 scons an that is th rason why w s a rqust latncy rop at 7500 scons of Figur 7(). Th currnt slop-bas tim sris prictor cannot kp up with sun rout changs. Apart from th tim sris priction failur of th spculativ schulr, both schulrs ar abl to aapt to th spik an allocat/allocat VMs succssfully. For th bas schulr, th total cost is $0.83 an latncy violations ar 2 out of 36. For th spculativ schulr, thy ar $1.38 an 1 out 36 rspctivly Comparison with Static Schuling lastic schuling can aapt to unforsn fluctuating man whras static schuling cannot. W compar static schuling against our propos lastic algorithms to confirm th ffctivnss of our approach s aaptivity. xprimntal sttings ar th sam as Sction 5.2, an w us both Nationwi an Dallas atasts. For th static schuling, w tst VM configurations with cors = t2, 4, 8, 10, 12, 14, 16u for Nationwi an t2, 6, 8, 10, 12u for Dallas. Comparison of VM hours, cost, an th prcntag of latncy violations ar shown in Tabls 4 an 5, rspctivly, for th Nationwi an Dallas atasts. Sinc static schuls o not wast any VM hours at all (i.., thy

8 Z Z Z Z > Z > > Z > Figur 5. xprimntal rsults for th Nationwi atast Figur 6. VM allocation squnc for th spculativ schuling algorithm crat from th Nationwi atast. o not visit a situation as in Figur 6), w comput th cost for our lastic schulrs in proportion to th xcution tim for fairnss. In th tabls, VM hours mans th nt numbr of cors us ovr 3 hours of th xprimnts. Th prcntag of latncy violations is comput out of 36 schuling problms ovr 3 hours. For th Nationwi atast, th spculativ schulr succssfully improvs ovr th baslin schulr in trms of latncy violations by 50% with 41% lss VM hours an cost. Th prformanc of th static schul with 12 cors is comparabl to th spculativ schulr (0% vs. 5.56% violations). Whn comparing th two, th spculativ schulr achivs a similar prformanc with 49% lss VM hours an cost. For th Dallas atast, th bas schulr improvs latncy violations ovr th closst static allocation approach (6 cors) by 66% spit it uss 17% lss VM hours. Whn comparing to th static schul with 8 cors, th spculativ schulr slightly ovr-provisions u to inaccuracy of both tim sris an rsourc prictions. That is, it spns 5% mor VM hours an cost, but qually prforms as th static schulr with 8 cors in trms latncy violations. Whil our lastic schuling policy xhibits a small prcntag of latncy violations, w not that any static schulr, othr than a vry highly provision on, will not b abl to guarant zro latncy violations. For any static VM allocation, thr is a possibility that it will not b sufficint for som lvl of man. Our lastic schulrs, TABL 4. VM HOURS, COST, AND LATNCY VIOLATIONS FOR LASTIC AND STATIC SCHDULING ALGORITHMS (NATIONWID DATAST). Policy Cors VM hours Cost Violations [cor hour] [USD] [%] Static Auto Scaling 2 to lastic (bas.) 2 to lastic (spc.) 2 to TABL 5. VM HOURS, COST, AND LATNCY VIOLATIONS FOR LASTIC AND STATIC SCHDULING ALGORITHMS (DALLAS DATAST). Policy Cors VM hours Cost Violations [cor hour] [USD] [%] Static lastic (bas.) 2 to lastic (spc.) 2 to on th othr han, succssfully aapt to unforsn computational man changs an scal VMs accoringly with rasonably low cost Comparison with Auto Scaling Sinc thrshol-bas auto scaling is commonly us as an application-agnostic scaling tchniqu, w tst it against our application awar approach. W us th sam xprimntal sttings as Sction 5.2. W implmnt th following ruls that ar compatibl to Amazon Auto Scaling [10]: VM instanc typ: c4.larg. VM allocation: minimum 1, maximum 5 instancs.

9 Z Z Z Z > Z > > Z > Figur 7. xprimntal rsults for th Dallas atast. Rul to scal up: if th avrag CPU utilization of allocat VMs is consistntly abov 70% for 2 minuts, a on VM. Rul to scal own: if th avrag CPU utilization of allocat VMs is consistntly blow 30% for 2 minuts, ruc on VM. Coolown prio: onc scaling cision is ma, no nw scaling activity is prform for 300 scons. VM trmination: th instanc that is closst to th nxt billing cycl is chosn to trminat. Figur 8 shows avrag CPU utilization an th numbr of VMs ovr th 3 hour xprimnt prio. Th auto scalr succssfully incrass VMs up to 4, an thn crass thm to 1. Th rsults ar summariz in Tabl 4. Sinc th thrshol-bas auto scalr is not awar of th application prformanc rquirmnt (i.., 240 scons latncy) at all, it unr-provisions th VMs an ns up proucing rlativly many latncy violations compar to our lastic schulrs. Figur 8. CPU utilization an VM allocation by a thrshol-bas auto scaling. 6. Rlat Work First an formost, rlat work is an air traffic flow managmnt mol optimizing nationwi air traffic [16]. Cao an Sun formulat th air traffic managmnt problm as an ILP problm an compos it into multipl subproblms using Lagrangan composition. Furthr, thy us MapRuc [15] to solv th Lagrangan rlaxation of th larg LTM problm in paralll [16]. Thy only consir fix-siz clustrs as a running nvironmnt; howvr, w apply it to an IaaS clou an support auto scaling of VMs. Also, our approach is awar of billing cycls an tris not to rnw VM lass unlss ncssary. Many tchniqus hav bn vlop to automatically scal VM allocations [27]. Autorgrssion an ARMA ar wily us to prict tim sris an hav bn succssfully appli to auto-scaling clou systms [24], [25]. If th systm forss a man spik in avanc, it can allocat nw VMs an mak thm ray bfor th spik actually arrivs. As long as priction accuracy is rasonably high, tim sris priction approachs ar ffctiv. Anothr common approach is thrshol-bas such as offr in Amazon Auto Scaling [10]. For xampl, usrs can configur a policy that crats a nw VM if th CPU utilization consistntly gos abov 70%. This approach is simpl an asy to us; howvr, sinc it only racts to simpl mtrics, from our xprimnt, it cannot optimally allocat VMs to mt th application spcific prformanc targt (.g., procssing latncy). Othr auto scaling tchniqus inclu rinforcmnt larning an control thory bas approachs. Rinforcmnt larning (RL) tchniqus try to scal VMs without any prior knowlg about th application [11], [12]. RL agnts larn appropriat actions by intracting with nvironmnts, but it rquirs a long tim to fin an optimal solution. In control thory bas approachs, a controllr tris to control th systm to follow som sir valu by using fback from th systm. For xampl, th controllr controls th numbr of VMs to kp th systm s throughput consistnt [28], [29]. Unlik th control thory bas approachs, our mol bas approach os not rquir onlin mol upats. Thrfor, it is xpct to work as soon as th systm starts running. As a tra-off, th mols in our approach cannot aapt at run tim.

10 7. Conclusion an Futur Work In this papr, w prsnt an lastic milwar framwork that is spcifically sign to solv ILP problms gnrat from continuous air traffic strams ovr an IaaS clou. W propos a spculativ VM schuling algorithm with tim sris an rsourc priction mols. xprimnts show that our spculativ VM schuling algorithm can achiv a similar prformanc to a static schul whil using 49% lss VM hours for a smoothly changing air traffic. Howvr, for a sharply changing air traffic, our spculativ VM schuling algorithm costs slightly mor VM hours to achiv th sam prformanc. Our algorithm is abl to aapt ynamically to potntially unforsn fluctuating man with a rasonabl priction accuracy. W plan to improv mol priction accuracy spcially for tim sris using a mor complx mol (.g., ARMA). W hav svral potntial irctions for futur work. First, w woul lik to apply our milwar to othr application aras sinc th concpt of solving larg scal ILP problms crat from continuous ata stram is wily applicabl. Caniat application aras inclu: public transportation routing [4], invstmnt portfolio optimization [5], an markting bugt optimization [6], [7]. Scon, w plan to xplor othr moling tchniqus for pricting rsourc allocation. Finally, w plan to xtn our framwork to support othr optimization policis such as bugt constrain an alin constrain policis. Acknowlgmnts This rsarch is partially support by th DDDAS program of th Air Forc Offic of Scintific Rsarch, Grant No. FA an NSF Awars, Grant No , , an Th authors woul lik to thank an Amazon Wb Srvics ucational rsarch grant an a Googl Clou Crits Awar. Rfrncs [1] Intrnational Air Transport Association (IATA), Nw IATA Passngr Forcast Rvals Fast-Growing Markts of th Futur, Octobr [2] C. H. Papaimitriou an K. Stiglitz, Combinatorial optimization: algorithms an complxity. Courir Corporation, [3] G, G Flight Qust Challng 2, flight2-final/ata. [4] J.-F. Corau, P. Toth, an D. Vigo, A Survy of Optimization Mols for Train Routing an Schuling, Transportation Scinc, vol. 32, no. 4, pp , [5] C. Papahristooulou an. Dotzaur, Optimal portfolios using linar programming mols, Journal of th Oprational rsarch Socity, vol. 55, no. 11, pp , [6] T. Lu an C. Boutilir, Dynamic sgmntation for larg-scal markting optimization, in Intrnational Confrnc on Machin Larning 2014 Workshop on Customr Lif-Tim Valu Optimization in Digital Markting, Jun [7] Z. Abrams, O. Mnlvitch, an J. Tomlin, Optimal livry of sponsor sarch avrtismnts subjct to bugt constraints, Procings of th 8th ACM Confrnc on lctronic Commrc - C 07, p. 272, [8] Googl, Googl AWors, [9]. vn-ar, Y. Mansour, V. Mirrokni, S. Muthukrishnan, an U. Naav, Bi Optimization in Broa-Match A Auctions, Procings of th 18th Intrnational Confrnc on Worl Wi Wb, p. 10, [Onlin]. Availabl: [10] Amazon Wb Srvics, Auto Scaling, autoscaling/. [11] X. Dutrilh, S. Kirgizov, O. Mlkhova, J. Malnfant, N. Rivirr, an I. Truck, Using rinforcmnt larning for autonomic rsourc allocation in clous: Towars a fully automat workflow, in ICAS 2011, Th Svnth Intrnational Confrnc on Autonomic an Autonomous Systms, 2011, pp [12]. Barrtt,. Howly, an J. Duggan, Applying rinforcmnt larning towars automating rsourc allocation an application scalability in th clou, Concurrncy an Computation: Practic an xprinc, vol. 25, no. 12, pp , [13] D. P. Palomar an M. Chiang, A tutorial on composition mthos for ntwork utility maximization, I Journal on Slct Aras in Communications, vol. 24, no. 8, pp , [14] Y. Cao an D. Sun, A Link Transmission Mol for Air Traffic Flow Managmnt, Journal of Guianc, Control, an Dynamics, vol. 34, no. 5, pp , [15] J. Dan an S. Ghmawat, MapRuc: Simpli Data Procssing on Larg Clustrs, Procings of 6th Symposium on Oprating Systms Dsign an Implmntation, pp , [16] Y. Cao an D. Sun, Migrating Larg-Scal Air Traffic Moling to th Clou, Journal of Arospac Information Systms, vol. 12, no. 2, pp , [Onlin]. Availabl: /1.I [17] FlightAwar, FlightAwar, [18] Amazon Wb Srvics, Amazon lastic Comput Clou (Amazon C2), [19] Th Apach Softwar Founation, Apach Spark, apach.org/. [20] LGPL opn sourc projct, lp solv: linar intgr programming solvr, [21] Amazon Wb Srvics, Amazon lastic Comput Clou (Amazon C2) API Rfrnc, APIRfrnc/. [22] A. J. Awan, M. Brorsson, V. Vlassov, an. Aygua, Prformanc Charactrization of In-Mmory Data Analytics on a Morn Clou Srvr, arxiv: , [23] S. L. Olivir, B. R. D Supinski, M. Schulz, an J. F. Prins, Charactrizing an mitigating work tim inflation in task paralll programs, Scintific Programming, vol. 21, pp , [24] G. Chn, W. H, J. Liu, S. Nath, L. Rigas, L. Xiao, an F. Zhao, nrgy-awar srvr provisioning an loa ispatching for connction-intnsiv intrnt srvics. in NSDI, vol. 8, 2008, pp [25] N. Roy, A. Duby, an A. Gokhal, fficint autoscaling in th clou using prictiv mols for workloa forcasting, in Clou Computing (CLOUD), 2011 I Intrnational Confrnc on. I, 2011, pp [26] Yiyuan Zhao an Joachim K. Hochwarth an Ariann A. Hrsru, Comprhnsiv Dynamic Air Traffic Systm Simulation (ComDATSS, ComDATSS/. [27] T. Lorio-Botran, J. Migul-Alonso, an J. A. Lozano, A Rviw of Auto-scaling Tchniqus for lastic Applications in Clou nvironmnts, Journal of Gri Computing, vol. 12, no. 4, pp , [Onlin]. Availabl: s [28] X. Dutrilh, N. Rivirr, A. Morau, J. Malnfant, an I. Truck, From ata cntr rsourc allocation to control thory an back, in Clou Computing (CLOUD), 2010 I 3r Intrnational Confrnc on. I, 2010, pp [29] X. Bu, J. Rao, an C.-Z. Xu, Coorinat slf-configuration of virtual machins an appliancs using a mol-fr larning approach, Paralll an Distribut Systms, I Transactions on, vol. 24, no. 4, pp , 2013.