Introduktion till autoskalning

Özgür Bal autoskalning Leave a Comment

Servrar är internettjänsters arbetshästar. Antingen har de något att göra, eller så väntar de på arbete. Deras väntetid kostar dock också pengar. En molntjänst sägs vara överprovisionerad då för många servrar (eller molninstanser) är igång utan att ha tillräckligt att göra. När motsatsen inträffar, när det är för mycket arbete för att den mängd servrar vi har skall hinna med, sägs tjänsten vara underprovisionerad. Autoskalning är den automatiserade processen som identifierar när en applikation antingen är över- eller underprovisionerad och sedan rättar till detta genom att begära eller släppa ifrån sig servrar. Innan vi kunde hyra kapaciteten i molnet tog det mycket tid att skaffa nya servrar. Det kunde ta timmar eller till och med dagar. Nuförtiden går det på några minuter istället, i och med att vi hyr kapacitet från vår molnleverantör. Detta gör att våra tjänsters datorresurser kan växa och krympa snabbt och autoskalning är därför en av molnets främsta försäljningsargument.

autoscaling

Varför är autoskalning viktigt?

Överprovisionering slösar pengar. Beroende på applikationens storlek kan detta antingen vara mycket eller lite. En av våra kunders applikationer har stora lastvariationer varje dygn: det skiljer en faktor åtta mellan hur mycket resurser de behöver som mest och som minst! Innan vi hjälpte dem var deras strategi, som så många andras, att helt enkelt ha en massa extra kapacitet igång hela tiden. För att klara av oväntad extrabelastning hade de dessutom lite extra mariginal, för säkerhets skull. Att undvika detta överprovisioneringsslöseri påverkar direkt deras vinstmariginal: varje krona som sparas ökar direkt deras vinst. Kostnaderna för underprovisionering är svårare att mäta, men det gör dem bara mer intressanta. Om en reklamkampanj lyckas bli en viral succé, vad är då kostnaden av att många nya potentiella kunder möts av en långsam eller icke-fungerande hemsida? Hur många möjliga försäljningar förlorar en e-handlare på att sidan är för långsam att surfa på? Studier visar att långsamma sajter har stor påverkan på företagens rykte och försäljningsvolym. Datoranvändare känner sig frustrerade av långsamma sidor, spenderar mindre pengar hos e-handlare med långsamma sajter och otillgänglighet kostar stora pengar när affärskritiska system drabbas. Google bestraffar även långsamma sajter i deras sidrankningsalgoritmer.

Hur fungerar autoskalning?

Autoskalning är i grunden en tvåstegsprocess. Först avgörs hur väl mängden tillgängliga resurser matchar efterfrågan. Därefter anpassas mängden resurser för att uppnå rätt förhållande. Säg att vi på dagtid har så många användare att det krävs fem servrar, men att vi bara har tre tillgängliga. Autoskalaren skall då se till att starta upp två till. När vi har färre användare under natten skall autoskalaren krympa vår server-pool till en eller kanske två servrar, så att vi sparar pengar. För att kunna göra denna bedömning måste autoskalaren övervaka applikationen och ha tillgång till dess monitoreringsdata. Detta data måste vara tillräckligt färskt och ge användbar information gällande molnapplikationens status. Bra mätvärden är sådana som visar status för ett funktionslager i applikationen och som inte begränsas av hur stor vår nuvarande server-pool är. Ett exempel på ett bra mätvärde är hur många besökare vår sajt har just nu (hämtat från lastbalanseraren). Ett dåligt mätvärde är hur stor belastning våra servrars processorer har. Svagheten med det senare är att det ju inte visar hur stor den ytterligare efterfrågan är, bara att nuvarande server-pool är för liten. Grundläggande autoskalning är reaktiv: tillgänglig mängd resurser ändras som en reaktion på att något tröskelvärde har passerats. En typisk kedjereaktion skulle kunna vara:

  • lägg till X servrar,
  • vänta till dessa har startats och kommit igång fullständigt
  • undersök ifall tillgång och efterfrågan på kapacitet matchar varandra nu, eller om vi måste göra om från början.

Denna autoskalningsvariant fungerar tämligen väl för applikationer som har små och långsamma fluktuationer i användning. För att korrekt hantera större och snabbare variationer måste autoskalaren vara smartare. Hur ser en sådan ut, vad kan den göra åt dessa svårigheter? Och, på tal om svårigheter, hur räknas egentligen rätt värde av X ut? Räknas det ens ut, eller följer vi bara någon regel som inte tittar på verkligheten? Bara lugn, det är just sånt vi är här för! I kommande blogginlägg kommer vi bjuda in er att dyka djupare ned i vår fascinerande värld av automatiserad administration av molntjänster.

En framåtblick

I kommande inlägg i denna autoskalningsserie kommer vi gå djupare gällande både generella principer för automatiserad administration av molntjänster och specifikt se hur Elastisys Cloud Platform fungerar och stödjer i detta. Vi kommer visa hur man startar plattformen i City Cloud och låter den administrera ens applikationer där, vilket gör er molntjänst robustare samt förbättrar dess prestanda och kostnadseffektivitet. Hur hanterar ni era nuvarande variationer i användning? Hör av er i kommentarsfältet nedanför!

 

Om artikelförfattaren

elastisysDetta har varit ett gästinlägg av elastisys, ett svenskt uppstartsföretag som knoppats av från forskningsgruppen inom distribuerade system vid Umeå universitet. Elastisys skapar produkter och tjänster baserade på gruppens forskning för att hjälpa företag förbättra sina molnapplikationers robusthet, prestanda och kostnadseffektivitet. Det går att hitta Elastisys på diverse sociala medier och dess hem här på webben: elastisys.com.

larslarsson

Lars är en mjukvaruarkitekt hos elastisys som specialiserat sig på forskning och utveckling av skalbara system. När han inte är direkt inblandad i mjuvaruutveckling föreläser han om avancerade ämnen inom distribuerade system och om analys och design av molntjänster. Kontakta honom via email eller besök hans profil på LinkedIn.