▶ Autoskalning i praktiken

Özgür Bal Okategoriserad Leave a Comment

autoscaling-in-practice-notext

Hur autoskalar vi i praktiken? Var börjar man och vilka förändringar, om några, måste vi göra i vår applikation för att kunna autoskala? Finns det fler saker vi måste tänka på? Detta är det tredje inlägget i serien om autoskalning. Introduktion till autoskalning inledde med grunderna: beskrev problemet som autoskalning löser, introducerade några termer och motiverade varför autoskalning är viktigt. Avancerad prediktiv och proaktiv autoskalning beskrev hur vi kan förutsäga framtida resursbehov för att få ännu bättre autoskalningsbeteende och presenterade hur Elastisys prediktiva och proaktiva autoskalare fungerar. I det här inlägget presenterar vi en checklista bestående av generella frågor som måste besvaras innan vi kan autoskala en applikation. Med den informationen tillgänglig visar vi sedan hur man använder Elastisys autoskalare i City Cloud.

Checklista för autoskalning

Det finns en checklista som vi behöver gå igenom innan vi kan autoskala en applikation. Frågorna som måste besvaras är:

  1. Vilka komponenter av applikationen skall autoskalas?
  2. Vilken kapacitet/storlek skall varje serverinstans ha?
  3. Hur automatiserar vi att göra en ny serverinstans fullt fungerande?
  4. Hur hittar serverinstanser varandra (service discovery) och därefter börja synkronisera/samarbeta?
  5. Vilka mätvärden avgör när vi skall skala?
  6. Vilken kapacitet har en serverinstans (i termer av mätvärdet/-na)?
  7. Vilka begränsningar på antalet serverinstanser har vi?

Läs vidare för ytterligare information kring dessa frågor.

1. Vilka komponenter av applikationen skall autoskalas?

Applikationer består oftast av väldefinierade komponenter. Om man installerar WordPress-bloggmotorn på en server så sparar inte själva WordPress-mjukvaran innehållet i ens blogginlägg utan ber en databasserver (exempelvis MySQL eller MariaDB) att göra det. Den bryr sig heller inte om hur man kommunicerar via HTTP med besökarnas webbläsare, utan ber en webbserver (exempelvis Apache eller NGINX) att göra det.

Två aspekter är mycket viktiga för autoskalning: hur väl dessa komponenter skalar horisontellt (genom att öka eller minska antalet instanser av komponenten) och hur de har utplacerats (jfr engelskans deployment). Att utplacera alla komponenter på en och samma server är trevligt ur prestandaperspektiv (inga nätverksfördröjningar mellan komponenterna!), men det är riktigt dåligt ur ett horisontellt skalningsperspektiv. Anledningarna till detta är flera, men de två viktigaste är:

  • om applikationen lider av att det inte finns tillräckligt många instanser av en specifik komponent är det inte vettigt att samtidigt skala upp övriga — varken ur ett prestanda- eller kostnadseffektivitetsperspektiv och
  • om vi bara klonar en serverinstans kommer vi också vara tvungna att genomföra en stor mängd konfigurationsändringar bara för att se till att de två instanserna hålls i synk.

Vår utplaceringsstrategi skall bara placera komponenter på en och samma server ifall det är vettigt ur horisontellt skalningsperspektiv. I fallet WordPress betyder det att vi kan köra WordPress tillsammans med en webbserver, men håller databasen på en annan server. Använder vi till exempel memcached för att snabba upp bloggen genom att undvika ställa frågor till databasen, bör den också vara på en separat server.

Skalning av WordPress Figur 1. Ensam allt-i-ett Linux-Apache-MariaDB-PHP (LAMP) server jämfört med en fullt skalbar WordPress-installation, där varje typ av komponent kan skalas oberoende av de andra.

2. Vilken kapacitet/storlek skall varje serverinstans ha?

Nu när vi vet vilka komponenter som skall köras på varje server måste vi lista ut hur dessa servrar startas. Vi måste definiera kapacitetskrav så vi vet vilken storlek av virtuell maskin (VM) eller container vi skall begära från molnleverantören. Vilken storlek som krävs är relaterat till vilken programvara vi tänker köra samt hur mycket extra jobb det är för programmen att synkroniseras mellan instanser. Om varje ny instans kräver bara lite synkronisering kan man komma undan med att lägga till många, men små, nya instanser. Om varje ny instans måste synkronisera mycket med sina gruppmedlemmar, som till exempel en distribuerad databas gör, kommer man förmodligen vilja hålla antalet instanser nere, men då ha större instanser med högre prestanda.

3. Hur automatiserar vi att göra en ny serverinstans fullt fungerande?

När vi bestämt vilken kapacitet en serverinstans skall ha måste vi lista ut hur den skall konfigureras när den startar. Med autoskalning kommer serverinstanser att komma och gå under dygnets alla timmar. Den processen måste automatiseras, så att det inte krävs att en systemadministratör handgripligen måste logga in och sköta om varje ny instans. Antingen gör vi detta genom ett enkelt shell-skript, eller så använder vi mer komplexa och flexibla lösningar för configuration management som Chef, Puppet, Salt eller Ansible.

Oavsett vilken variant vi väljer måste vi generellt installera mjukvara, konfigurera den så den registrerar sig i någon form av register (som en lastbalanserare) och synkronisera med sina gruppmedlemmar.

4. Hur hittar serverinstanser varandra och därefter börja synkronisera/samarbeta?

När en serverinstans startar måste komponenterna som körs däri göra sig tillkänna med övriga komponenter i den gruppen av komponenter. I en webbservers fall betyder det typiskt att den registrerar sig med en lastbalanserare. Databasservrar måste generellt kontakta någon master-nod och sedan göra sig till medlem med en passande roll, efter att ha tagit del av datat som finns sparat i databasen sedan tidigare. Dessa steg måste läggas till i uppstarts-skripten eller configuration management-mjukvaran, så nya instanser är fullgoda medlemmar i den grupp de tillhör.

Några mindre uppenbara fallgropar finns här. Vi använder igen WordPress som exempel (det körs ju ändå på runt 60 miljoner bloggar!). Textinnehåll (sidor, inlägg, kommentarer, etc.) sparas i databasen. Mediafiler (bilderna som tillhör inläggen) hamnar dock lokalt på hårddisken. Så, om vi bara lägger till webbserver mer WordPress-instanser via autoskalning kommer de allihop att kunna svara med rätt textinnehåll, då det kommer från gemensamma databasen, men mediafilerna kommer bara finnas på just den server som råkade ta emot filuppladdningen. Resultatet blir en blogg som är halvtrasig hela tiden — bilder dyker upp ibland, ibland inte. För att undvika detta används ett nätverksfilsystem (exempelvis GlusterFS) för att hålla filsystemet i synk. Alternativet är att använda ett content distribution network för just uppladdade filer.

5. Vilka mätvärden avgör när vi skall skala?

Som vi beskrev i första inlägget är vissa mätvärden lämpligare än andra för autoskalning. Vad vi helst är ute efter är mätvärden som:

  • har att göra bara med just specifikt de aktuella komponenterna och
  • inte är begränsade av nuvarande totala kapaciteten (då det är omöjligt att avgöra hur mycket för lite vi har i nuvarande kapacitet om mätvärdena inte kan visa detta).

Detta betyder alltså att mäta exempelvis CPU-användning över alla servrar vi har just för stunden är dåligt, då värden som slår i taket bara säger oss att vi behöver fler servrar, men inte hur många. Därför är det bättre att mäta, till exempel, antalet inkommande förfrågningar per sekund till en lastbalanserare. Om vi inte har tillräckligt med kapacitet att hantera alla dessa förfrågningar just nu, så vet vi i varje fall hur många fler serverinstanser vi behöver lägga till.

6. Vilken kapacitet har en serverinstans?

Om vi övervakar bra mätvärden (enligt ovan) vet vi hur många serverinstanser vi behöver. Om vi vet att en webbserver för just vår applikation klarar av X förfrågningar per sekund är det jättebra. Då kan vi anpassa antalet serverinstanser vi har relativt den siffran — bara dividera antalet förfrågningar vi behöver kunna klara av med X, så har vi antalet servrar som krävs. Som vi beskrev i andra inlägget måste en autoskalare vara smart för att undvika skala upp och ner snabbt när man befinner sig nära gränsen för att behöva en ny serverinstans, för att undvika att systemet påfrestas i onödan.

7. Vilka begränsningar på antalet serverinstanser har vi?

Vi måste sätta lämpliga lägre och övre gränser för hur många serverinstanser vi vill ha. Den undre gränsen säkerställer att vi alltid har en vettig lägstanivå: det får aldrig vara färre än en viss mängd servrar igång vid ett givet tillfälle. Övre gränsen sätts av vår budget. Som beskrevs i andra inlägget är kapacitetsgränserna sista steget i autoskalarens pipeline, och kan därmed inte överstigas.

Autoskalningsexempel

För att tydligt belysa autoskalningen skall vi autoskala en enkel webbapplikation. Vi startar den i City Cloud och använder City Clouds lastbalanserare. Det är inte WordPress (allt för komplicerat för just det här fallet!), utan en enkel Apache-webbserver som hanterar statiska filer. Vi väljer en så enkel applikation för att inte gå vilse bland alla detaljer som man måste ha i åtanke för komplicerade applikationer som WordPress (om det är av intresse, dock, håll dig uppdaterad via vår blogg, en artikel om det är på gång där). Våra svar på autoskalningschecklistan är som följer:

Tabell I. Autoskalningschecklista för vår enkla webbapplikation.
Fråga Svar
Vilka komponenter av applikationen skall autoskalas? Apache webbservrar, som körs i Ubuntu 14.04 LTS
Vilken kapacitet/storlek skall varje serverinstans ha? 1 CPU core, 1 GB RAM
Hur automatiserar vi att göra en ny serverinstans fullt fungerande? Uppdatera paketlistan, installera Apache via repositories.
Hur hittar serverinstanser varandra och därefter börja synkronisera/samarbeta? Ingen synkronisering, men servrar registreras som medlemmar i City Clouds lastbalanserare via en agent-programvara.
Vilka mätvärden avgör när vi skall skala? Förfrågningar per sekund, rapporterade av lastbalanseraren.
Vilken kapacitet har en serverinstans? 100 förfrågningar per sekund*
Vilka begränsningar på antalet serverinstanser har vi? Antalet skall hållas mellan 1 och 20.

* Det är bra att välja en försiktig siffra för en instans kapacitet först och sedan genomföra tester för att hitta var gränsen egentligen går. Kapaciteten är självklart beroende av flertalet faktorer, bland annat hur många processorkärnor och hur mycket internminne varje serverinstans har.

Konfiguration av autoskalare i City Cloud

Här är en screencast, på engelska, om hur vi startar en autoskalare i City Cloud och konfigurerar den för vår enkla applikation enligt checklistan ovan:

I filmen visar vi hur vi:

  • konfigurerar lastbalanserare för vår applikation,
  • skaffar OpenStack API credentials för inloggning mot API:et,
  • registrerar ett SSH-nyckelpar som kan användas till instanser som skapats via OpenStacks API,
  • startar autoskalaren och
  • konfigurerar autoskalaren med hjälp av dess enkla webbgränssnitt, specialbyggt för City Cloud.

Resultatet är en applikation som kommer autoskala enligt de parametrar vi valt. Det är förvisso enkelt att bara svara med statiska sidor, men ytterligare komplexitet kan läggas till i efterhand. Komplexitet gillar ju när allt kommer omkring att växa med tiden, vare sig man vill det eller ej.

Vi har också en screencast där vi visar hur autoskalaren skalar en applikation mellan flera moln: City Cloud och Amazon EC2. Den finns tillgänglig här:

Gå med i Elastisys autoskalnings-beta

Vi jobbar hårt med att göra autoskalaren tillgänglig för alla kunder och att göra processen att komma igång smidigare och smidigare. Om denna serie av inlägg har intresserat dig för autoskalning är du välkommen att gå med i vårt beta-program. Kontakta Elastisys och vi hjälper gladeligen till att få allt att snurra!

Kommande händelser

Vi kommer delta vid #CloudBeerStockholm den 5:e november 2015. Där presenterar vi på engelska med en presentation som heter Autoscaling in a multi-cloud environment, där vi visar ett live-demo som bygger på Elastisys autoskalare och dess City Cloud-webbgränssnitt. Missa det inte, det kommer bli riktigt kul!

Autoskalning av en applikation kan vara komplext, beroende på applikationen. Tillsammans med City Cloud kommer vi hålla ett webinar någon gång i framtiden, där vi diskuterar vilka steg som krävs för att skala upp en WordPress-blogg från en enda server till en fullt skalbar installation, redo att ta emot massiva mängder besökare. Ha koll på den här bloggen och på City Clouds nyhetsbrev 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.