Avancerad prediktiv och proaktiv autoskalning

Özgür Bal autoskalning Leave a Comment

I vårt förra inlägg introducerade vi grunderna inom autoskalning. Vi tog upp vad autoskalning är, varför det är viktigt och hur det funkar med monitorering, mätvärden och så vidare. I det här inlägget går vi på djupet. Vi kommer se hur en autoskalare avgör hur mycket den behöver skala er mängd servrar och hur en autoskalare fungerar internt. Vi använder oss av Elastisys cloud platform för denna presentation av det uppenbara skälet att vi är dess utvecklare och därför känner till den bäst. Vi kommer också diskutera hur den använder prediktioner (förutsägelser) för att proaktivt avgöra hur resursbehovet utvecklas över tid och förser er applikation med just-in-time capacity. Ta en god kopp kaffe (får vi föreslå en strålande Café moca?) och läs vidare!

autoscaler_prediction_subsystem.png

Varför prediktiv och proaktiv autoskalning är viktig

När Elastisys grundades 2011 var molnet redan rejält hypat, men hur det faktiskt användes inom industrin liknade absolut inte dagens användning. Idag använder företag i högre utsträckning molnets dynamiska natur och flyttar över mer och mer databehandling till molnet. Ökat molnanvändande kombinerat med att tjänsterna och dess användningsmönster är mer dynamiska innebär att företag kan göra applikationerna mer robusta och säkerställa högre prestanda även vid oväntade användningsmängder samt stora besparingar genom effektivare resursutnyttjande.

Adrian Cockcroft, tidigare Cloud Architect hos Netflix och numera Technology Fellow hos Battery Ventures, hävdade i ett keynote-föredrag vid UCC 2014 att hans erfarenhet säger att prediktiv autoskalning sparar upp till 70% i molnkostnader. Hur fick han den erfarenheten? Netflix insåg att enkel regelbaserad reaktiv autoskalning som erbjuds av diverse molnleverantörer omöjligen kunde erbjuda den autoskalningslösning de behövde. Eftersom Netflix har avsevärda utvecklingsresurser utvecklade de en egen proaktiv autoskalare. Den är dock inte tillgänglig utanför Netflix.

Kostnadsbesparingsargumentet är förstås starkast för företag som har stora mängder servrar i molnet. Företag som inte har så många servrar, och därmed mindre potential för besparing genom att stänga av servrar som inte används, tjänar stort på att automatiskt säkerställa prestandan och tillgängligheten hos deras applikationer även om stora och plötsliga anstormningar av kunder eller besökare försöker nyttja tjänsten samtidigt. Det är en inte helt lätt uppgift, speciellt om man inte är van vid eller är förberedd för den typen av plötslig ökning. Forskning visar att 75% av besökare inte skulle återvända till en sida som tar mer än 4 sekunder att ladda. Att misslyckas på den punkten kan vara avgörande för ett företags framgång på dagens Internet, oavsett företagets storlek.

Reaktiv autoskalning är självklart att föredra framför att inte ha någon autoskalningslösning alls. Dess främsta nackdel är att den ofrånkomligen är steget efter, då den ju reagerar på att applikationen har för lite kapacitet tillgänglig och först då försöker öka resursmängden. Sådana ökningar tar tid. Om vi dessutom använder enkla tröskelvärdesbaserade skalningsregler som de flesta molnleverantörer erbjuder kommer vi bara långsamt nå fram till rätt resursnivå (uppnå konvergens mellan resursefterfrågan och -tillgänglighet). Om vi använder prediktiv autoskalning för att proaktivt göra skalningsbeslut kan vi få näst intill omedelbar konvergens och alla applikationens användare upplever att applikationen tycks ha obegränsad mängd resurser.

När vi nu alltså vet varför prediktiv och proaktiv autoskalning är viktig, låt oss se hur den uppnås.

 

“Hitta värdet av X!”

Förra blogginlägget hade en förädiskt enkel fråga i slutet:

Grundläggande autoskalning är reaktiv: tillgänglig mängd resurser ändras som en reaktion på att något tröskelvärde har passerats. […] lägg till X servrar […] hur räknas egentligen rätt värde av X ut?

Det är ofta relativt enkelt att märka om en applikation har för lite resurser: det tar lång tid att ladda, vissa anrop kommer aldrig fram och i värsta fall kan komponenter krascha. Men att avgöra hur mycket extra kapacitet som krävs har två förutsättningar:

Det förstnämnda ger oss en bild av hur stort problemet är och det senare hur stor lösningen måste vara.

En smart autoskalare tar båda dessa aspekter i beaktande. Det låter den snabbt stänga gapet mellan resurstillgängligheten och efterfrågan efter detsamma.

En inte-så-smart autoskalare skalar bara upp och ner med en specifik mängd när ett tröskelvärde har passerats, ofta med bara någon enstaka ny server. En vanlig sådan regel ser ut som “när detta värde är högre än Y i si-och-så många minuter, skala upp med Z nya serverinstanser”. Om den specifika mängden servrar är för liten för att täcka den nya resursefterfrågan kommer applikationen fortfarande vara underprovisionerad när skalningen har skett. Då får man vänta en fördefinierad tid (ofta kallad cooldown) och sen göra ett nytt steg och hoppas att man nu är på rätt nivå. Och så vidare. I praktiken innebär det att autoskalaren kryper upp för en trappa när ett rejält hopp hade varit den bättre lösningen.

 

Avancerad prediktiv och proaktiv autoskalning

Att reagera på förändringar är ofrånkomligen att vara minst ett steg efter. Det negativa i sammanhanget har redan inträffat (brist på tillgängliga resurser i autoskalningsfallet) och vi reagerar på det för att avhjälpa problemet (genom att skaffa mer resurser). Människor är dock smarta. Vi vet att om vi kan använda vår erfarenhet för att förutsäga när något negativt håller på att hända så kan vi agera i förväg och i bästa fall förhindra att det negativa inträffar.

Precis som väderleksrapporten hjälper oss undvika att få en planerad picknick förstörd, kan vi undvika kapacitetsproblem genom att använda prediktiva metoder. Dessa baseras på avancerade matematiska och datavetenskapliga modeller och algoritmer som finns tillgängliga och inkluderar:

  • identifiering av återkommande mönster i vårt data,
  • statistisk analys av nuvarande variationer i kapacitetsefterfrågan (korttidsförändringar) och
  • användandet av maskininlärningstekniker.

En väldigt smart autoskalare använder alla dessa för att säkerställa att rätt mängd resurser finns tillgängliga när de faktiskt behövs. Ökar efterfrågan alltid på måndagmorgonen och klingar av när kontorstiden är över? Mönsterigenkänning märker sådant. Är nuvarande ökning relativt liten eller är den anledning att skala upp hela applikationen med en faktor 5? Statistisk analys kan avgöra detta. Vilken effekt hade egentligen en viss skalningshandling för ett visst användningsmönster? Låt autoskalaren lära sig det och lista ut vilka handlingar som är passande för framtiden!

Följande tabell summerar vad vi beskrivit i detta stycke:

Tabell 1. Smartheten hos olika autoskalare.
Känner till problemets storlek Skalar till problemets storlek Reaktiv eller proaktiv
Inte-så-smart Nej Nej Reaktiv
Smart Ja Ja Reaktiv
Väldigt smart Ja Ja Proaktiv

Som referens och som källa till ytterligare insikt erbjuder vi vår jämförelse av autoskalare på marknaden under hösten 2015vår blogg.

 

Autoskalning i Elastisys cloud platform

Nu när vi vet vilka funktioner en autoskalare bör ha, låt oss se hur vi har implementerat en! Det börjar, som alltid, med en sund och rejäl dos teori.

Monitor-Analyze-Plan-Execute loopen

I området autonomic computing identifierade IBM Monitor-Analyze-Plan-Execute (MAPE) loopen, som uttrycker de handlingar som utförs av ett autonomt system, exempelvis autopiloten i ett flygplan eller farthållaren i en bil.

mape-loop
Monitor-Analyze-Plan-Execute (MAPE) loopen.

I Elastisys cloud platform har vi tre separata system som är ansvariga för delar av dessa uppgifter:

  • monitoring subsystem ansvarar för att ta emot, spara och erbjuda tillgång till mätvärden kopplade till de uppsättningar mätvärden som sparas, exempelvis i en tidsseriedatabas,
  • prediction subsystem analyserar monitoring-informationen och räknar ut en plan för hur mängden kapacitet behöver anpassas och
  • cloud pool subsystem utför denna skalningsplan genom att interagera med molnleverantörens system via dess API.

I grund och botten agerar alltså monitoring subsystem källan för indata och cloud pool subsystem är utdatan från systemet. Vi tror mycket på modulär kod och kan därför byta ut såväl monitoring-databasen som cloud pools så att vi är kompatibla med olika tekniker. Cloud pools kan i nuläget arbeta med OpenStack-baserade moln som City Cloud och Amazon EC2 via olika API:er där (vi kan arbeta med såväl vanliga on-demand-instanser som Spot-instanser).

Prediction subsystem

Själva kärnan av autoskalaren är i prediction subsystem. Det ser ut som följer:

autoscaler_prediction_subsystem.png
Komponenterna i Elastisys prediction subsystem.

En uppsättning predictors tar mätvärden från olika mätvärden och har som uppgift att räkna ut ett framtida värde för dessa, en prediktion. Hur långt i framtiden kallar vi för prediction horizon och bör vara så väl tilltaget att en ny serverinstans skall kunna skapas och konfigureras så att den är helt med i systemet. Tar det 15 minuter? Bara fem? Rätt svar här beror på många faktorer, inklusive sådana som är applikationsspecifika. Vilken molnleverantör man använder spelar också stor roll. Vår erfarenhet är att City cloud är väldigt snabbt på att starta nya serverinstanser.

Dessa prediktioner konverteras till compute units genom att systemadministratören har uppskattat lämpliga värden (exempelvis 500 anrop per sekund och server). Prediktionerna, som nu är i formen av compute units, matas in i en aggregationsfunktion. I denna kan olika prediktioner tilldelas olika vikt, så olika viktiga mätvärden kan ges olika stor chans att påverka den faktiska skalningshandlingen. Det kanske är mycket viktigt att hålla mängden RAM-användning nere i något fall, eller så är mängden anrop per sekund totalt avgörande. Allt sådant kan fångas upp här. Om det inte finns någon bra anledning att avvika från det, rekommenderar vi generellt att ta maxvärdet av alla prediktioner. Det är enkelt att förstå och resonera kring. Ut från aggregationsfunktionen kommer ett enda prediktionsvärde. Detta matas in i en uppsättning policys, som exempelvis ser till att undvika för frekventa skalningshandlingar — speciellt motsatta sådana.

Frekventa motsatta skalningshandlingar är dåligt, eftersom det leder till en pendeleffekt av att öka och minska mängden kapacitet. Detta skapar onödig oro och belastning på ens applikation, exempelvis då servrar måste registrera och avregistrera sig i något delat register eller ta del av något delat tillstånd. Detta problem löser man i reglerteknik genom att introducera deadband-områden, som förhindrar förändringar från att ske om behovet av förändringar inte är stort nog. Den typen av intelligens, och mer därtill, finns i våra policys.

Deadband.svg
Deadband, skapat av Krishnavedala (eget arbete), via Wikimedia Commons (CC BY-SA 3.0).

Slutligen begränsas prediktionen via en uppsättning schemalagda gränsvärden. Dessa ger systemadministratören fullständig kontroll över både undre och övre gränsen för kapaciteten. Den undre gränsen säkerställer att det alltid finns ett visst minimum av kapacitet tillgängligt och den övre ser till att autoskalningen aldrig går över företagets budget för molnkostnader. Att det går att ange flera schemalagda gränser ger systemadministratören möjlighet att uttrycka finkorniga regler som håll dessa gränser under helger och erbjud kapacitet inom detta spann under kontorstid.

Forskning visar att ingen enda algoritm ensamt kan fånga alla aspekter som behövs för optimal autoskalning. Jämför med väderprognoser: ingen skulle anta att en enda modell för en enda uppsättning mätvärden (historiskt väder på den här platsen, senaste dagens molntäcke, osv.) används för att förutspå vädret. På samma sätt måste vi generellt använda mer en en typ av indata och mer än en typ av modell för att förutsäga resursefterfrågan.

Worldclouds_2009
Worldclouds 2009 av NASA Earth Observatory [Public domain], via Wikimedia Commons.

Elastisys erbjuder en uppsättning av prediktorer, där varje är anpassad efter en viss typ av uppgift. Vissa är bra på att upptäcka återkommande mönster, andra är bra på att upptäcka variationer på kort tid. Vissa använder sig av maskininlärning för att utföra sitt arbete. De finns alla där, redo att aktiveras ifall de behövs.

Användare av vår autoskalningslösning behöver inte bry sig om all denna komplexitet, dock. Vi har vettiga standardvärden, integreringar med vanligt förekommande servermjukvara och monitoring-agenter som gör rapporteringen av mätvärden enkel. Forskning för att automatiskt anpassa och ställa in dessa system enligt klassificering av applikationens belastning över tid pågår ständigt av vårt forskningsteam (nyligt exempel). I nästa inlägg i denna serie gästinlägg visar vi hur man sätter upp systemet i City cloud och hur enkelt det är att integrera med City clouds lastbalanserare. Håll koll på denna blogg för uppdateringar!

 

Om artikelförfattaren

elastisys

Detta är en artikel skriven 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.