Att driftsätta i molnet

(1)

Examensarbete

Tryggve Blom 2012-06-28

Att driftsätta i molnet

En undersökning i kostnader och skalningsmöjligheter.

(2)

Abstrakt

När en ny webbapplikation skall lanseras och driftsättas är det svårt att i förhand veta vilken datatrafik och belastning som tjänsten behöver vara dimensionerad för.

Rapporten följer en webbapplikation som inte är förberedd för uppskalning till att bli separerad i olika komponenter för ökad skalbarhet och driftsäkerhet.

I rapporten genomförs även en komparativ studie på olika typer av molntjänster som erbjuder infrastruktur (IaaS)-, plattform (PaaS)- och mjukvara (SaaS) som en tjänst.

Målet med undersökningen var att hitta en kostnadseffektiv metod för att expandera applikationens infrastruktur och flytta implementationen till molnet.

Resultatet och slutsatsen visar att den dyraste lösningen inte alltid är den bästa och i slutändan kan företag betalar pengar för resurser som de inte utnyttjar.

(3)

Förord

Att driftsätta en webbapplikation i molnet och undersöka vad som döljer sig bakom molnets täta mystik är någonting som jag länge velat göra.

Möjligheten uppstod när företaget jag genomförde mitt examensarbete hos ville undersöka hur deras applikationer var anpassade för skalbarhet och expandering i molnet. Jag såg min chans att utforska ämnet cloud computing och fördjupa mig inom de olika tjänster som erbjuds.

Jag vill rikta ett särskilt stort tack till Tommie Podzemski på Rekrytema Sweden AB för allt stöd och hjälp under mitt arbete med rapporten och genomförandet av testningen.

Tack till Patrik Riske på Rekrytema Sweden AB för hjälp med illustrationer till rapporten och allt stöd och samarbete under applikationsutvecklingen.

Ett stort tack går även till min handledare John Häggerud på Linnéuniversitetet för all hjälp under rapportskrivandet.

Slutligen vill jag tacka Dave Brubeck och Frank Sinatra för sällskapet under alla kvällar och nätter vid sammanställningen av denna rapport.

(4)

Innehållsförteckning

1. Introduktion ... 1

1.1 Bakgrund ... 1

1.2 Syfte ... 2

1.3 Frågeställningar ... 3

1.4 Avgränsningar ... 3

1.4.1 Session och Cache ... 3

1.4.2 Tjänsteföretag ... 3

1.4.3 Personalkostnader ... 4

1.4.4 Driftsäkerhet ... 4

1.4.5 Sekretess ... 4

2. Teknisk bakgrund ... 5

2.1 Cloud computing ... 5

2.1.1 Mjukvara som en tjänst (Software as a Service) ... 5

2.1.2 Plattform som en tjänst (Platform as a Service) ... 6

2.1.3 Infrastruktur som en tjänst (Infrastructure as a Service) ... 6

2.2 Skalbarhet ... 6

2.2.1 Vertikal skalning ... 7

2.2.2 Horisontell skalning ... 7

2.3 Driftsäkerhet ... 8

2.4 Utility Computing ... 8

3. Metod ... 10

3.1 Applikationen ... 10

3.2 Infrastrukturer ... 10

3.2.1 Scenario 1 ... 11

3.2.2 Scenario 2 ... 11

3.2.3 Scenario 3 ... 12

3.2.4 Scenario 4 ... 12

3.3 Testning ... 13

3.4 Priser ... 13

3.5 Metoddiskussion ... 14

(5)

4. Resultat ... 15

4.1 Scenario 1 ... 15

4.1.1 Skalning ... 15

4.1.2 Prestanda ... 16

4.2 Scenario 2 ... 16

4.2.1 Skalning ... 17

4.3 Scenario 3 ... 17

4.3.1 Skalning ... 18

4.4 Scenario 4 ... 20

4.4.1 Skalning ... 20

4.5 Summering... 22

5. Slutsats ... 23

6. Källförteckning ... 26

7. Bilagor ... 28

7.1 Bilaga 1: Scenario 1 ... 28

(6)

1. Introduktion

När en ny webbapplikation skall lanseras och driftsättas är det svårt att i förhand veta vilken datatrafik och belastning som tjänsten behöver vara dimensionerad för. Hos många mindre företag är det i första hand viktigt att tjänsten lanseras över huvud taget.

I det enklaste scenariot kommer det innebära att applikationen driftsätts med webbserver och databas på en maskin i företagets infrastruktur.

Men vad händer när tjänsteanvändandet och behovet av infrastruktur ökar?

Traditionellt har företag haft alternativen att köpa in mer hårdvara och utöka den befintliga infrastrukturen eller ta hjälp av ett webbhostingföretag som säljer utrymme på en fysisk eller virtuell plattform (VPS) i deras infrastruktur.

Det har blivit mer vanligt att företag köper dessa tjänster från leverantörer som använder sig av så kallad Cloud Computing¹

Rapporten kommer följa en webbapplikation som inte är förberedd för uppskalning till att bli separerad i olika komponenter för ökad skalbarhet och driftsäkerhet.

Undersökningen kommer redovisa hur driftsäkerhet och dataintegritet kan förbättras vid en expandering av infrastrukturen och tjänsteanvändandet.

. Rapporten kommer undersöka vilken nytta molntjänster kan bidra med som de traditionella tjänsterna har saknat.

Undersökningen kommer också belysa de kostnader som är kopplade till de olika alternativen och komma till en slutsats om vilket sätt som är att föredra för mindre företag som står inför funderingen att flytta till molnet.

1.1 Bakgrund

Undersökningen i rapporten är genomförd tillsammans med Rekrytema Sweden AB.

Rekrytema har många års erfarenhet inom rekrytering, samarbete och utveckling av medarbetare och ledare inom den offentliga och den privata sektorn.

Företaget står inför en expandering av verksamheten mot den europeiska marknaden och det är av intresse att undersöka hur affärssystemet kan skalas upp för att möta en högre belastning och samtidigt bevara driftsäkerhet och dataintegritet.

(7)

Det är också intressant att utreda vilka kostnader dessa förändringar kan medföra på kort och lång sikt beroende på det alternativ de väljer.

Den applikation som står till grund för genomförandet av undersökningen heter JobMatch och är en tjänst för att profilera kandidater för olika yrkesroller.

Huvudscenariot för en användare är att personen loggar in med ett unikt test id och svarar på tvåhundra flervalsfrågor. Därefter stänger användaren ner tjänsten.

Företaget uppskattar att det tar varje användare ungefär 45 minuter innan alla frågor är besvarade.

Med tanke på mängden frågor och den tid som tjänsten tar i anspråk av varje

användare är det av stor vikt att säkerställa dataintegriteten och driftsäkerheten. Att en användare behöver göra om hela processen på grund av ett tekniskt fel kommer resultera i att företaget tappar kredibilitet och vid upprepade incidenter kommer det innebära förlorade kunder och intäkter som resultat.

Företaget har en implementation som hanterar tjänstens nuvarande behov men deras problem är att tjänsten är begränsad till den befintliga infrastrukturen.

Företaget ställer stora krav på att applikationen alltid skall finnas tillgänglig och ser en fara i den nuvarande situationen där applikationen endast finns på en datorinstans.

Slutar den instansen att fungera slutar tjänsten att fungera. Därför är det viktigt att hitta en implementation som erbjuder en bättre driftsäkerhet.

Eftersom Rekrytema planerar en expansion på den europeiska marknaden vill de även vara förberedda på en framtida utökning av deras infrastruktur och vill förbättra möjligheterna till att ha en skalbar och driftsäker applikation.

1.2 Syfte

Syftet med rapporten är att ge företag som inför en stundande utökning av verksamheten funderar på att flytta sin infrastruktur in i molnet underlag att fatta egna beslut.

Rapporten kommer arbeta med att hitta en implementation av en webbapplikation som gör tjänsten skalbar och driftsäker på ett sätt som även är kostnadseffektivt.

Givet den applikation rapporten har som utgångspunkt och genom att jämföra

parametrar som kostnader och skalbarhet hos olika tjänstemodeller kommer rapporten presentera ett resultat av undersökningen och avrunda med några reflektioner i den

(8)

1.3 Frågeställningar

• Vilka alternativ finns det när ett företag behöver expandera sin verksamhet från att vara driftsatt på en datorinstans till att möta en situation med betydligt högre krav på datatrafik och resurser?

• Vilka kostnader är inblandade i de olika alternativen för molntjänster kontra fysisk hosting?

• Vad innebär det kostnadsmässigt om tjänsteanvändandet ökar och resurserna behöver skalas upp?

• Vad händer om det blir mindre trafik till tjänsten än vad som uppskattades?

1.4 Avgränsningar

Detta kapitel tar upp områden som inte kommer avhandlas i rapporten. Många av dessa är dock viktiga för företag att känna till och ha i åtanke.

1.4.1 Session och Cache

Med stora horisontellt skalade modeller²

Alternativet är att designa applikationen att arbeta utan att använda sig av en session på den serverinstans som den arbetar på. Detta är hur applikationen som används i undersökningen är implementerad.

dyker det upp en problematik med att arbeta med cache på serverinstanserna. Finns det bara en maskin så behåller den cachen i sitt internminne, men vid horisontell skalning är det inte garanterat att samma maskin svarar på varje anrop. Rapporten kommer inte gå in på hur den situationen hanteras utan kan bara konstatera att det finns lösningar för det på marknaden som är väl utspridda och beprövade.

1.4.2 Tjänsteföretag

Det finns en stor arena med tjänsteleverantörer i molnet likväl som på den traditionella marknaden. I rapporten kommer tre företag stå till grund för jämförelser.

(9)

Amazon (aws.amazon.com) är en av de största leverantörerna för cloud computing tjänster på marknaden. I undersökningen används några av dessa varav främst Infrastructure as a Service (IaaS)-baserade tjänster.

PHPFog (www.phpfog.com) är ett företag som erbjuder Platform as a Service (PaaS)- baserade tjänster inom molnet.

För fysisk hostning kommer tjänster från FS-Data (www.fsdata.se) stå till grund för rapporten eftersom det är där företaget har sin infrastruktur idag.

1.4.3 Personalkostnader

Personalkostnader för administration, inlärning av nya system och hantering av olika mjukvaror för infrastrukturen är ingenting som rapporten kommer mäta eller ta hänsyn till. Det är väldigt olika mellan företag vilken kunskap som finns och därför svårt att avgöra i en mätning vilken tidsåtgång som behövs för underhållsarbete. Dessa är dock viktiga parametrar för ett företag att begrunda när man skall välja plattform.

1.4.4 Driftsäkerhet

Beträffande driftsäkerhet finns det många frågeställningar företag kan göra.

Kan kostnaden i att tjänsten inte är tillgänglig under längre tidsperioder mätas? Hur stora sannolikheter har de olika modellerna för driftstörningar/avbrott?

Rapporten begränsas till att undersöka hur en infrastruktur och applikationsdesign som minimerar risken för att applikationen blir otillgänglig kan skapas. De olika leverantörernas tillgänglighet undersöks inte i denna rapport.

1.4.5 Sekretess

Rapporten kommer inte avhandla hur leverantörerna använder den data kunder sparar i deras infrastruktur. Har företaget höga krav på integritet och sekretess är det viktigt att undersöka de avtal som leverantörerna erbjuder gällande äganderätt, sekretess och dataintegritet.

(10)

2. Teknisk bakgrund

I det här kapitlet förklaras många av de begrepp som återkommer och är viktiga för rapporten.

2.1 Cloud computing

Begreppet molntjänster (cloud computing) har varit en välanvänd term inom IT- branschen i många år. Dock finns det ingen vedertagen definition av uttrycket.

Gartner, ett världsledande amerikanskt företag inom IT-forskning och rådgivning har gett sin definition:

“Gartner defines cloud computing as a style of computing where massively scalable IT-related capabilities are provided “as a service” using Internet technologies to multiple external customers”. [1]

Cloud computing innebär alltså att stora skalbara resurser görs tillgängliga för kunder i form av tjänster via Internet.

Det finns tre olika inriktningar på de tjänster som erbjuds inom molnet.

Företag kan investera i mjukvara-, plattform- eller infrastruktur som en tjänst. De engelska begreppen är Software as a Service (SaaS), Platform as a Service (PaaS) och Infrastructure as a Service (IaaS).

2.1.1 Mjukvara som en tjänst (Software as a Service)

Det blir mer vanligt att företag erbjuder programvaror som tjänster via Internet [2].

Det traditionella sättet att distribuera mjukvara är att varje användare av tjänsten har en lokal kopia av mjukvaran installerad på sin dator. Med SaaS kopplar användaren upp sig till en centraliserad tjänst och arbetar med programvaran genom webbläsaren [3, sid 50]. Många typer av programvaror lämpar sig bra för den här typen av

arbetssätt. E-posthantering har under många år varit ett bra exempel på hur en lyckad SaaS har fungerat. Andra exempel finns bland annat inom ordbehandling med t.ex.

Google Docs (docs.google.com) och även inom ekonomibranschen med tjänster som Fortnox (www.fortnox.se).

(11)

2.1.2 Plattform som en tjänst (Platform as a Service)

Den här modellen innebär att kunden köper en färdig plattform att driftsätta

webbapplikationer på [3, sid 49]. Olika plattformar erbjuds av tjänsteleverantörer där webbserver, databas och andra mjukvaror görs tillgängliga för kunden. I tjänsten ingår att den underliggande mjukvaran i plattformen uppdateras och underhålls så kunden kan flytta fokus till att arbeta med sitt affärssystem [3, sid 48].

En molnbaserad PaaS är flexibel eftersom den underliggande infrastrukturen är virtuell [4] och därför skalbar på ett mer enkelt sätt gentemot traditionell fysisk hårdvara.

Ett företag som erbjuder PaaS på den svenska marknaden är City Cloud

(www.citycloud.se) och på den internationella marknaden finns det många fler som exempelvis Google App Engine (developers.google.com/appengine) och PHPFog (www.phpfog.com).

2.1.3 Infrastruktur som en tjänst (Infrastructure as a Service)

De tidigare två modellerna, SaaS och PaaS har i stort handlat om att tjänsten varit baserad på en viss mjukvara som kunden använder sig av. Denna mjukvara måste köras på någon form av hårdvara.

IaaS är tjänster där kunder köper virtuella maskiner där de själva administrerar och installerar programvaror efter eget önskemål [3, sid 34]. Tjänsten är alltså en virtuell dator vilken konfigureras hårdvarumässigt efter kundens beställning. Sedan är det upp till kunden att själv installera, underhålla och uppdatera de mjukvaror som krävs för att driftsätta webbapplikationer.

Den virtuella modellen innebär att infrastrukturen är skalbar om kunden får ett ökat behov av datakraft [3, sid 39].

Två stora leverantörer av IaaS på marknaden är Amazon (aws.amazon.com) och Rackspace (www.rackspace.com).

2.2 Skalbarhet

Begreppet skalbar har funnits med länge men har aldrig varit lätt att definiera [5].

Studier har visat att det finns olika typer av skalbarhet [6]. Rapporen använder skalbarhet när den beskriver de åtgärder som finns för att förbättra en applikations

(12)

förutsättningar för att ta emot en större arbetsbelastning i form av trafik eller datalagring. Applikationen i sig måste ha en arkitektur som är skalbar men implementationen av själva skalbarheten sker oftast i den underliggande infrastrukturen eller plattformen som används för att driftsätta tjänsten.

Det finns två metoder för skalning, vertikal och horisontell [7].

2.2.1 Vertikal skalning

Att förändra sin infrastruktur vertikalt innebär att man utökar datorkraften på den befintliga hårdvaran genom att installera en snabbare processor, minnesmoduler med högre kapacitet eller en hårddisk med större lagringsutrymme. Dessa komponenter kommer innebära att mjukvarorna som driver applikationen ges bättre förutsättningar att utföra sitt arbete snabbt och effektivt vilket innebär att tjänsten kan ta emot mer trafik och lagra mer data.

För att skala virtuella infrastrukturer med vertikal skalning tilldelas mer resurser genom virtualiseringsmjukvaran. Dock måste tjänsten tas ur bruk för att förändringarna skall kunna gå att genomföra [8].

Vertikal skalning är lämplig för tjänster som har en konstant hög belastning eftersom resurserna då utnyttjas maximalt.

2.2.2 Horisontell skalning

Att implementera horisontell skalning innebär att man utökar antalet maskiner som används för att driftsätta tjänsten. Finns det ett underskott i de resurser som krävs för att ta emot den inkommande datatrafiken till tjänsten löser man det genom att fördela trafiken till ytterligare maskiner som kan göra samma saker som de tidigare

maskinerna.

Virtuella infrastrukturer skalas horisontellt på samma sätt fast du tillför då fler virtuella maskiner till infrastrukturen.

Horisontell skalning innebär med rätt förutsättningar att tjänsten inte behöver stängas ner för att kunna skalas. Resurserna ökar i infrastrukturen oberoende av varandra och de kontrollsystem som finns anpassar sig efter de nya förutsättningarna och utnyttjar resurserna optimalt.

(13)

Horisontell skalning bidrar även med redundans i systemet. Slutar en maskin att svara kan en annan maskin utföra arbetet istället.

För en applikation som generellt har en låg trafikbelastning men vid vissa tidpunkter har ett ökat tjänsteanvändande är horisontell skalning att föredra. Rätt använt innebär modellen små utgifter och optimalt användande av resurser.

2.3 Driftsäkerhet

Swedish Standards Institute (SIS) definierar begreppet driftsäkerhet enligt följande:

“förmågan hos en enhet att kunna utföra avkrävd funktion under angivna betingelser vid ett givet tillfälle eller under ett angivet tidsintervall, förutsatt att erforderliga stödfunktioner finns tillgängliga” [9].

Driftsäkerhet mäts genom tillgänglighet [10].

Tiden som enheten är otillgänglig subtraheras från enhetens planerade tid för tillgänglighet. Differensen mellan dessa är måttet på enhetens driftsäkerhet.

Driftsäkerheten hos en webbtjänst är beroende av tillgängligheten hos flera stödfunktioner i den underliggande infrastrukturen och dessa bör således tas i begrundande för att säkerställa en hög driftsäkerhet i webbappliaktionen.

2.4 Utility Computing

Den vanligaste betalningsmodell som tjänsteleverantörer av molntjänster använder sig av heter utility computing. En bra definition på begreppet är:

“Utility computing is a service provisioning model in which a service provider makes computing resources and infrastructure management available to the customer as needed, and charges them for specific usage rather than a flat rate.” [11].

Utility computing definieras alltså som en modell där tjänsteleverantörer gör

datorresurser och infrastrukturer tillgängliga åt sina kunder i enlighet med kundernas behov.

Modellen brukar jämföras med hur el- och vattenbolag tar betalt för sina tjänster [12]

och innebär att betalningen står i relation till hur mycket kunden har använt.

(14)

Inom mjukvarubranschen visar modellen en stor nytta för många företag. Tidigare har investeringar i licenser och mjukvaror för hela företag varit kostsamma men

nödvändiga för att kunna använda programvaror. Med utility computing och SaaS behöver företag inte längre äga mjukvaror eller licenser till de mjukvaror som används och kostnaden för företagen står i relation till tjänsteanvändandet.

Även inom PaaS- och IaaS-sektionerna är prismodellen och tjänsterna tillsammans en stor fördel gentemot traditionella metoder. Företag som generellt sett har en låg trafikbelastning på sin tjänst måste ändå äga hårdvara eller betala tjänsteföretag för resurser som står outnyttjade stor del av tiden. När tillfälliga ökningar i trafikbelastning uppkommer kan infrastrukturer och plattformar beställas och utnyttjas under en kort tid och företaget betalar bara för de extra resurserna så länge de används.

(15)

3. Metod

I rapporten genomförs en komparativ studie av utvalda scenarion och infrastrukturer.

Målet är att hitta en kostnadseffektiv metod för att expandera en webbapplikations resurser.

3.1 Applikationen

JobMatch består i att 200 flervalsfrågor besvaras av en inloggad användare.

Processen är uppdelad i mindre sektioner där användaren besvarar fem frågor per sektion. Efter att en sektion blivit genomförd skickas svaren till en databas för persistent lagring innan nästa sektion laddas.

Denna implementation minskar risken med att all data från en process tappas om applikationen skulle sluta fungera och användaren av tjänsten kan istället fortsätta från den sektion i testet personen befinner sig på när tjänsten återigen är tillgänglig.

I dagsläget finns databasen på samma maskin som den webbserver som driftsätter applikationen vilket innebär att tjänsten inte är horisontellt skalbar.

Rapporten kommer undersöka vilka möjligheter som uppkommer när databas och webbserver skiljs åt. Det kommer även skapas ett API till databasen för att se vilka alternativ det bidrar med i infrastrukturen.

3.2 Infrastrukturer

Följande testsvit är framtagen där olika metoder och scenarion undersöks i syfte att hitta en implementation som är kostnadseffektiv och flexibel i sin skalbarhet. Även kapaciteten på infrastrukturen mäts för att undersöka huruvida behovet för det befintliga tjänsteanvändandet tillgodoses.

(16)

3.2.1 Scenario 1

Inledningsvis undersöks de möjligheter som finns på den infrastruktur som används idag. Driftsättningen sker hos ett hostingföretag på en virtuell server (VPS) där webbserver och databas är på samma maskin.

3.2.2 Scenario 2

Scenariot använder sig av virtuella instanser hos Amazon genom Amazon EC2.

Inför detta scenario har applikationen skrivits om för att möjliggöra horisontell skalning av infrastrukturen.

Genom att separera databasen från samma maskin som webbservern kan modellen utökas med fler webbservrar som pratar med samma databas. I detta scenario används bara en instans för webbserver.

Två maskiner hos Amazon kommer användas för scenariot, en som driftsätter applikationen och en som driftsätter databasen och ett API som har skapats genom vilket applikationen kommunicerar med databasen.

I detta scenario tillför inte APIet någonting med hänsyn till skalbarhet eller driftsäkerhet utan det skapades för framtida scenarion.

(17)

3.2.3 Scenario 3

I detta scenario utökas infrastrukturen med en lastbalanserare. Två separata instanser med webbservrar driftsätter applikationen oberoende av varandra.

Applikationen kommunicerar fortfarande med det API som återfinns på ytterligare en instans. Databasen har flyttats från den maskinen till en PaaS som heter Amazon RDS.

Totalt kommer tre maskiner användas genom IaaS och databasen driftsätts genom en PaaS. Lastbalanseraren är en tjänst som Amazon erbjuder i det användarkonto som skapas för att använda deras molntjänster.

3.2.4 Scenario 4

Genom det sista scenariot fortsätter undersökningen av en infrastruktur som använder IaaS och PaaS tillsammans. Webbservern implementeras på en instans hos PHPFog - en tjänsteleverantör som erbjuder PaaS. Applikationen kommunicerar med det API som finns kvar på en IaaS-instans hos Amazon. Databasen fortsätter hanteras på en PaaS genom Amazon RDS.

(18)

3.3 Testning

För att mäta kapaciteten på de olika infrastrukturerna kommer en tjänst (SaaS) som heter LoadStorm (www.loadstorm.com) användas. Med detta verktyg kan användaren simulera en given belastning som skickas till applikationen och mäta resultatet av dessa http-anrop för att se hur applikationen och den underliggande infrastrukturen klarar av att ta emot trafikmängden.

Verktyget mäter antalet förfrågningar (requests) och datamängd som skickas totalt och per sekund (bandbredd/throughput). Även svarstiden, tiden från att förfrågan skickas till svaret har kommit tillbaks, redovisas i sekunder för den genomsnittliga svarstiden.

Undersökningen har genomförts genom att 25 samtidiga användare varje sekund har besökt sidan under loppet av fem minuter i ett skede som inneburit att applikationen behöver läsa från databasen, eller göra ett API-anrop - beroende på scenario, innan den har kunnat generera en http-respons.

Rapporten kommer också redovisa processor- och minnesanvändningen på den webbserver som används för att driva applikationen.

3.4 Priser

Priserna från de medverkande tjänsteföretagen baseras på respektive företags prislista som återfinns på deras webbsidor och hämtades 2012-05-10.

De priser som framkommer i resultatdelen gällande Amazons tjänster är beräknade enligt en prismodell där man binder sig i ett år med varje instans. Det finns andra prisplaner från Amazon där företag kan köpa infrastrukturen under en kort period och bara betala för den perioden utan bindningstid.

Alla instanser hos Amazon är belägna inom regionen EU (Irland).

Tjänsten från FS-Data går att teckna som minimum i en månad och undersökningen är använd med det billigaste alternativet.

PHPFog erbjuder en gratis version men det innebär att man delar prestandan med andra användare av leverantörens infrastruktur. Den tjänst som används i rapporten är bunden till det lägsta kostnadsalternativet och kunder kan som minimum betala för en dag enligt vad undersökningen har kommit fram till.

(19)

Rapporten vill ge en överskådlig siffra som grundar sig i att webbtjänsten skall vara tillgänglig alla timmar på dygnet varje dag på året. Priserna som presenteras under resultatet återspeglar således detta utförande.

3.5 Metoddiskussion

Det medför naturligtvis en kostnad att köpa flertalet tjänster bara för att undersöka dem men genom processen får företaget bättre underlag för att göra ett bra beslut i valet av leverantör.

Att genomföra så kallas stresstestning kan vara en bra metod för att testa vid vilken mängd infrastrukturen ger vika. Det innebär dock en kostnad att utföra dessa. Det är bra att tänka igenom vad som är relevant att testa och vad varje testresultat kan ge för upplysningar innan man sätter igång med massiva tester. Vilka siffror är skäliga att undersöka för den verksamhet och applikation som avses?

(20)

4. Resultat

Detta kapitel presenterar resultatet av de mätningar och undersökningar som genomförts av varje scenario och i slutet av kapitlet ges en summering av de olika resultaten.

4.1 Scenario 1

Konfigurationen på den instans som används är:

Processor Minne Hårddisk Månadskostnad

3 GHz Dual Core 1 GB 10 GB 199 kr

Trafikmängden som tillåts enligt tjänsteavtalet är 1000 GB per månad.

Det tillkommer en startavgift för användandet av tjänsten på 499 kr.

Delas avgiften upp under ett år blir det en månadskostnad på 241 kr det första året.

4.1.1 Skalning

Infrastrukturen kan uppgraderas till större modeller enligt följande prislista:

Internminne Hårddisk Trafikmängd Månadskostnad

2 GB 20 GB 2000 GB 399 kr

4 GB 40 GB 4000 GB 699 kr

Samtliga storlekar av tjänsten kan skalas upp vertikalt med följande månadspris:

Minne Hårddisk Trafik

+ 256 MB / 39 kr + 2 GB / 39 kr + 250 GB / 39 kr + 512 MB / 59 kr + 5 GB / 59 kr + 500 GB / 59 kr

(21)

Horisontell skalning är inte möjligt med denna konfiguration eftersom databasen och webbservern ligger på samma datorinstans.

4.1.2 Prestanda

Enligt de tester som genomförts med 25 samtidiga användare per sekund under fem minuter kom följande information:

Genomsnittlig svarstid

Antal fel

Antal Förfrågningar

F/sek (snitt)

F/sek (topp)

Bandbredd (snitt)

Bandbredd (topp)

Överförd datamängd

0,249 0 9,965 28 29 132 kB/s 137 kB/s 46 MB

F/sek utläses förfrågningar per sekund.

De mätningar som gjordes på serverinstansen (Bilaga 1) visade att 2.3% av processorkapaciteten användes och 13% av internminnet.

4.2 Scenario 2

I detta scenario kommer två virtuella instanser reserveras hos Amazon som IaaS för de olika delarna. Konfigurationen för varje instans som används för att driftsätta

applikationen i scenariot är:

2.27 GHz 1.7 GB 160 GB 240 kr

Eftersom två virtuella maskiner har reserverats hos tjänsteleverantören innebär det en total månadskostnad på 480 kr.

Amazon tillämpar utility computing på datatrafik i deras nätverk vilket innebär att kunden betalar för det som används. I Scenario 1 är det gratis trafik upp till 1000GB.

För att jämföra den parametern behöver en kostnad på 56 kronor per månad läggas till i scenario 2, 3 och 4.

(22)

4.2.1 Skalning

Amazon erbjuder många olika storlekar att arbeta med vertikal skalning. Enligt den prismodell som används i undersökningen är nästa storlek konfigurerad som följer:

2.27 GHz Dual Core 3.75 GB 410 GB 480 kr

Horisontell skalning med den här infrastrukturen innebär att du måste köpa till ytterligare tjänster för att det skall fungera. Scenario 3 avhandlar en metod för att hantera horisontell skalning.

4.2.2 Prestanda

Antal fel

0,888 0 1,463 4,1 4,3 17 kB/s 18 kB/s 6 MB

Mätningar på den instans som används för applikationen (Bilaga 2) visar en processoranvändning på 3,9% och minnesanvändning på 35%.

4.3 Scenario 3

Nu har infrastrukturen utökats så att det finns två virtuella instanser som arbetar med att driftsätta applikationen. Dessa två ligger bakom en lastbalanserare som avgör vilken instans som skall ta emot anropet.

Databasen hanteras av ytterligare en tjänst hos Amazon som heter RDS (Relational Database Service). Det är en PaaS modell som innebär att tjänsteleverantören

(23)

underhåller och uppdaterar själva databasplattformen och sköter även backup och säkerhetskopiering av datan.

RDS har även inbyggt stöd för skalning.

Kostnaden för Amazon RDS är 114 kronor per månad.

Applikationen kommunicerar fortfarande med databasen genom det API som finns på ytterligare en virtuell instans. För att applikationen skall fungera används således tre stycken instanser av samma konfiguration som i scenario 2. Infrastrukturen använder även en tjänst av leverantören som lastbalanserar mellan de två instanser som hanterar applikationslogiken.

Månadskostnaden för denna infrastruktur ligger på 3 X 240 kr + 132 kr för lastbalanserare + 114 för databas. Totalt 966 kronor per månad. Då är inte trafikkostnaden på 56 kronor i månaden medräknad.

4.3.1 Skalning

Samma metoder för att skala vertikalt går att implementera för varje instans i kedjan motsvarande den uppskalning som redovisades under scenario 2 i kapitel 5.2.1.

Horisontell skalning är kärnpunkten för den här infrastrukturen. Lastbalanseraren kan ta emot nya instanser som tillkommer under drift vilket ger kunden möjlighet att vid behov reservera ytterligare en instans för 240 kr per månad och utöka infrastrukturens kapacitet.

Tjänsteleverantören har även så kallade microinstanser som kunder kan reservera.

Konfigurationen för en microinstans är:

2.66 GHz 613 MB 10 GB 85 kr

(24)

Dessa är framtagna för tillfälliga behov av mer datakraft. Utan bindningstid kostar en microinstans 4 kronor per dygn att reservera.

Denna modell kräver att kunden själv aktiverar instansen, installerar och introducerar den för infrastrukturen. Det finns även ett alternativ där kunden reserverar en microinstans för 160 kronor per år och när det finns ett behov av den kan systemet aktivera den automatiskt och ha den igång så länge som behovet finns. Den tid instansen är igång kostar 10 öre per timma utöver kostnaden för att ha instansen reserverad under ett år.

Kunden kan aktivera hur många microinstanser - eller vanliga instanser också för den delen - som önskas och behövs.

Den tjänst som krävs för att övervakningen och aktiveringen skall fungera automatiskt ingår i avtalet med tjänsteleverantören men kunden ansvarar för att få tjänsten

aktiverad, automatiserad och inställd för att följa applikationens behov enligt kundens önskemål.

4.3.2 Prestanda

Antal fel

0,916 0 1,467 4,1 4,2 17 kB/s 18 kB/s 6 MB

Mätningar på de instanser som används för applikationen (Bilaga 3) visar att den första instansen belastar 3,7% av processorn medans den andra vilar. Minnesanvändningen på den första maskinen är 30% medans den andra visar 35%.

Lastbalanseraren är inställd på att dirigera trafiken till den instans som svarar snabbast.

(25)

4.4 Scenario 4

I det här scenariot finns databas APIet hos tjänstelevernatören Amazon på samma instans som används i de tidigare modellerna och databasen är driftsatt i Amazon RDS. Applikationen har däremot flyttat ut till tjänsteleverantören PHPFog som erbjuder PaaS, Platform as a Service.

Tjänsten innebär att användaren köper en färdig infrastruktur för att publicera applikationer i. Den instans man får är färdiginstallerad med en webserver och programvara för att hantera PHP och även många ramverk³ inklusive Zend

(framework.zend.com) vilket applikationen i undersökningen är utvecklad i. Företaget har inte samma möjlighet att påverka den underliggande mjukvaran - eller snarare inga möjligheter att påverka den underliggande mjukvaran. Tjänsten innefattar att den mjukvaran underhålls och uppdateras av tjänsteföretaget.

Den virtuella instans som driftsätter PaaS är konfigurerad enligt följande:

Inte tillgänglig 613 MB 10 GB 203 kr

Kostnaden för instansen på Amazon som driftsätter APIet är 240 kronor.

Kostnaden för databashanteraren (RDS) är 114 kronor.

Totalt 557 kronor i månaden.

Exklusive trafikkostnaden hos Amazon på upp till 56 kronor.

4.4.1 Skalning

Tjänsten från PHPFog går att skala både horisontellt och vertikalt. Likaså de tjänster som används på Amazon.

(26)

Horisontell skalning på PHPFog innebär ytterligare 203 kronor per månad och maskin. Lastbalanserare ingår i priset.

Den uppskalade maskinen behöver inte vara igång hela månaden och kostnaden beräknas per dygn instansen är igång. Kunden ansvarar själv för att skala plattformen under den tid som önskas.

Vertikal skalning innebär en uppgradering av kontot.

I den uppgraderade tjänsten ingår följande konfiguration:

Inte tillgänglig 1.7 GB 50 GB 533 kr

Den tjänsten går även att skala vertikalt för ytterligare 553 kronor per månad och extra instans som aktiveras.

4.4.2 Prestanda

Antal fel

0,684 0 1,506 4,2 4,7 20 kB/s 23 kB/s 7 MB

Minnes- och cpu-mätningar på den virtuella instansen som driver applikationen kan inte genomföras eftersom tillgången till den underliggande infrastrukturen och plattformen är begränsad för kunden.

(27)

4.5 Summering

Jämförelsetabell av kostnader, skalbarhet och svarstider ser ut som följer:

Pris per månad Skalbarhet Svarstid

Scenario 1 241 kr Vertikal 0,249

Scenario 2 480 kr Vertikal 0,888

Scenario 3 966 kr Vertikal och Horisontell 0,916 Scenario 4 557 kr Vertikal och Horisontell 0,684

(28)

5. Slutsats

Undersökningen visade att den infrastruktur som används av företaget idag, med webbserver och databas på samma virtuella maskin, svarade snabbast på de

inkommande anropen. Det var kanske inte förvånande eftersom den arbetar från sin egen disk i motsats till att skicka anrop till ett API på en annan maskin som i sin tur pratar med databasen och sedan väntar på återkopplingen genom samma kedja.

Den modell som uppvisade sämst svarstider var den som använde en lastbalanserare för att dirigera trafiken till den instans som svarade snabbast. Vilken kanske inte heller är en stor överraskning eftersom det är ytterligare en länk i kedjan som först gör ett anrop till varje instans för att kolla vilken som svarar snabbast och sedan skickar trafiken till den.

Det alternativet som har lägst kostnad är den i scenario 1, företagets befintliga system.

Men den arkitekturen är riskabel eftersom företaget “lägger alla ägg i en korg”. Slutar den instansen att svara fungerar inte applikationen längre. Företaget har som

målsättning att applikationen alltid skall svara och därför är det av intresse att göra vissa omstruktureringar för att minimera riskerna för ett eventuellt driftstopp.

Företaget inser att det förmodligen innebär större kostnader än deras befintliga lösning men anser att värdet i att alltid vara tillgänglig för användarna berättigar en kostnad.

Det dyraste alternativet var det som också visade sämst svarstider. Modellen är teoretiskt väldigt intressant eftersom den är förberedd på en horisontell uppskalning, och är även redundant i det att om en av de två instanserna skulle sluta svara så klarar den kvarvarande maskinen av att hantera trafikflödet. Antas en linjär ökning i antal anrop kontra resursåtgång kan trafiken ökas med 2500 procent per instans med den modellen. Detta går naturligtvis att mäta, men den ökningen i antalet användare av tjänsten är orimligt.

Att separera datalagret från affärslagret och flytta över verksamheten till molnet som scenario 2 var ett exempel på visade inga egentliga fördelar. Det blev en högre kostnad och fortfarande fanns det begränsningar i skalbarheten. Förvisso är separationen till de

(29)

testet visade att det behövs fler åtgärder innan förändringarna resulterar i någon mätbar nytta. Att flytta ut databasen från samma maskin som APIet gör detta. Det innebär att varje länk i kedjan går att skala horisontellt oberoende av varandra. Tillförs en lastbalanserare mellan webbserver- och API-instanserna går även APIet att skala och databasen har skalning genom den PaaS som används. Optimalt scenario sett ur driftsäkerhet och skalbarhet men till en hög kostnad.

Vad som hade varit intressant att undersöka är det som avhandlas i kapitel 4.3.1. Att skala ner de virtuella instanserna till de microinstanser som finns hos Amazon och undersöka vilka effekter det ger i pris och vilka belastningar den klarar av.

Resultaten av scenario 4 där två tjänsteleverantörer användes, Amazon som IaaS och PHPFog som PaaS var det scenariot som företaget blev mest intresserad utav. Den visade bra resultat på svarstider samtidigt som den är skalbar horisontellt och vertikalt.

Företaget ser dock att kostnaden fortfarande är hög.

Horisontell skalning genomförs med en imponerande enkelhet. Användaren drar i en regel på tjänsteleverantörens hemsida. Inom minuter har instanserna snurrat igång!

Att sprida ut applikation på olika leverantörer innebär att riskerna för driftstopp sprids ut. Om en leverantör inte svarar kan trafiken flyttas över till en annan leverantör.

Någonting som framkom under testfasen var dock att PHPFog själva använder sig av Amazon för infrastruktur men arbetar på att kunna erbjuda fler leverantörer [13] [14].

Syftet med undersökningen var att hitta en implementation som var driftsäker, skalbar och kostnadseffektiv. Scenario fyra ansågs ha två av dessa tre egenskaper och får därför ses som det bästa alternativet av de som undersöktes. Men under processen

(30)

drogs många lärdomar och företaget kommer därför undersöka kostnaderna och arbetet som ligger bakom att själva använda Amazons microinstanser för att driftsätta applikationen med en automatisk lastbalansering. Enligt vad undersökningen kom fram till borde det bli det mest kostnadseffektiva och skalbara alternativet. De instanser som används i scenario tre är (trots sin benämning small hos Amazon) överskalade för applikationen som används i undersökningen.

Problemet med det är att modellen för utility computing inte utnyttjas till sin fulla rätt, utan de gamla traditionella affärsmodellerna fortfarande appliceras. Att använda de nya teknikerna till företagets fördel borde eftersträvas och inte fortsätta betala för resurser som inte används.

Eftersom kunskapen att driftsätta och administrera serverinstanser finns på företaget borde det inte innebära en stor kostnad att utnyttja de verktyg som tillhandahålls.

För ett företag som inte har de nödvändiga resurser som krävs för att arbeta med serverprogramvaror utan är mer inriktade på applikationsutveckling kan det vara en bra idé att fortsätta undersöka PaaS och scenario 4 eftersom företaget då köper de tjänsterna och kan fokusera på sin kärnverksamhet.

Företaget i rapporten kommer förmodligen fortsätta med att arbeta enligt scenario 3 fast skala ner instanserna som används för driftsättningen av applikationen och undersöka närmare hur automatisk skalning och lastbalansering konfigureras.

(31)

6. Källförteckning

[1] Gartner Inc, "Gartner Says Cloud Computing Will Be As Influential As E- business", Gartner newsroom, 26 Juni 2008. [Online] Tillgänglig:

http://www.gartner.com/it/page.jsp?id=707508 [Hämtad: 2012-05-20]

[2] R. P Mahowald, “Worldwide Software as a Service 2011-2015 Forecast”, International Data Corporation (IDC), Augusti 2011. [Online] Tillgänglig:

http://www.idc.com/getdoc.jsp?containerId=229440 [Hämtad: 2012-05-20]

[3] J. W Rittinghouse, J. F Ransome, Cloud Computing. Boca Raton: CRC Press, 2010.

[4] M Healey, C Anderson, J Humphreys, “IBM Virtualization Services”, IDC White paper, Oktober 2008. [Online] Tillgänglig: http://www-

935.ibm.com/services/us/its/pdf/idc_white_paper_for_ibm_on_virtualization_srvcs- v2.pdf [Hämtad 2012-05-20]

[5] L Duboc, D. S Rosenblum, T Wicks, “A Framework for Characterization and Analysis of Software System Scalability”, från Proceedings of the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, Dubrovnik Croatia, September 2007. Copyright 2007 ACM. DOI:

10.1145/1287624.1287679.

[6] A. B Bondi, “Characteristics of scalability and their impact on performance”, från Proceedings of the 2nd international workshop on Software and performance, Ottawa Canada, September 2000. Copyright 2000 ACM. DOI: 10.1145/350391.350432.

[7] M Michael, J. E Moreira, D Shiloach, R. W Wisniewski, “Scale-up x Scale-out: A Case Study using Nutch/Lucene”, från International Parallel and Distributed Processing Symposium, Long Beach California USA, 26-30 Mars 2007. Coptright 2007 IEEE. DOI:

10.1109/IPDPS.2007.370631.

[8] City Cloud, “Vertikal Skalning I City Cloud”, City Cloud Blogg, 29 Februari 2012.

[Online] Tillgänglig: http://www.citycloud.se/cloud/vertikal-skalning-i-city-cloud/

[Hämtad 2012-05-20]

[9] Underhåll – Terminologi, Svensk Standard SS-EN 13306:2010. Tillgänglig:

http://www.sis.se/terminologi-och-dokumentation/ordlistor/tj%C3%A4nster/ss-en- 133062010 [Hämtad 2012-05-20]

(32)

[10] International Electrotechnical Commission (IEC), “Details for IEV number 191- 02-05”, International Electrotechnichal Vocabulary, December 1990. [Online] Tillgänglig:

http://dom2.iec.ch/iev/iev.nsf/display?openform&ievref=191-02-05 [Hämtad 2012- 05-20]

[11] M Rouse, “What is Utility Computing”, SearchDataCenter TechTarget, Juni 2007.

[Online] Tillgänglig: http://searchdatacenter.techtarget.com/definition/utility- computing [Hämtad 2012-05-20]

[12] F Dupre, “Utility (Cloud) Computing…Flashback to 1961 Prof. JohnMcCarty”, Life in the Cloud, Living with Cloud Computing, 25 September 2008. [Online] Tillgänglig:

http://computinginthecloud.wordpress.com/2008/09/25/utility-cloud- computingflashback-to-1961-prof-john-mccarthy [Hämtad 2012-05-23]

[13] L Carlson,”What are the differences between PHPFog, cloudControl and Orchestra?”, Quora, 5 Februari 2011. [Online] Tillgänglig:

http://www.quora.com/What-are-the-differences-between-PHP-Fog-cloudControl- and-Orchestra [Hämtad 2012-05-20]

[14] S Dean, “Lucas Carlson, Founder of Cloud-focused PHP Fog, Reveals What's in His Stack”, Ostatic Blog, 9 Februari 2011. [Online] Tillgänglig:

http://ostatic.com/blog/lucas-carlson-founder-of-cloud-focused-php-fog-reveals- whats-in-his-stack [Hämtad 2012-05-20]

(33)

7. Bilagor

7.1 Bilaga 1: Scenario 1

(34)

7.2 Bilaga 2: Scenario 2

(35)

7.3 Bilaga 3: Scenario 3

(36)

351 95 Växjö / 391 82 Kalmar