Uppgift 2: Moln och kapacitet

Examinationsuppgift 2 fokuserar på molnplattformar och kapacitetshantering. Den examineras genom en skriftlig rapport som lämnas in via GitLab samt peer-review av en annan students rapport (som tilldelas dig efter inlämning). Examinationen genomförs individuellt.

Bakgrund

En (påhittad) kund utvecklar och driftar ett applikation som gör det roligt och motiverande att lära sig nya språk genom gamification. Användare kan följa sitt lärande och tävla mot sig själva och andra. Tjänsten är för närvarande i öppen beta, så den är gratis att använda så länge man registrerar sig.

För att testa idéen utvecklade kunden en databasdriven webbapplikation i Django (webbramverk för Python) och lanserade denna via en hyrd server hos en lokal webbhost. De har skalat maskinen vertikalt några gånger för att hantera ökade behov, men börjar närma sig gränsen för vad som är möjligt. Nästa steg är att flytta applikationen till en molnplattform, men då kunden inte kan något som sådana har de hyrt in dig som konsult för att undersöka vad som är möjligt, hur man bör flytta, och vad det skulle kosta.

Webbapplikationen

Webbapplikationen är för närvarande en monolit i Django, men kunden har gjort en funktionell nedbrytning för att kunna fortsätta skala hos sin nuvarande webbhost (genom att hyra flera serverar som kör delar av applikationen). Då denna nedbrytning har anpassats efter nuvarande förutsättningar är de beredda att ändra om molnplattformen kräver det för att optimera kapacitet och kostnad.

Nedan följer en skiss av applikationen.

fig21

En lastbalanserare distribuerar trafiken över två front-end noder. Dessa kör en node.js applikation som sätter samman en HTML-sida baserat på data från ett antal interna REST-tjänster. Lastbalanseraren kör en enkel round-robin-strategi för att balansera mellan de två noderna.

REST-tjänsterna är namngivna efter vad de gör. Pilarna mellan visar beroenden mellan dem, dvs en REST-tjänst kan göra anrop i pilens riktning. Auth används för att skapa och kontrollera användaruppgifter, logga in användare, hantera lösenord, osv. Den är fristående de andra, det vill säga all kontroll om av en användare sker via front-end. Auth är implementerad som en Python Flask-applikation och sparar all data den behöver i en Postgres-databas.

Assets hanterar all grafik samt videor och ljudklipp som används i quizar och lektioner. Dessa lagras för närvarande som blob:ar i en Postgres-databas. Lessons har en uppsättning kurser och lektioner som en användare kan titta på. En kurs eller lektions innehåll är fördefinierat, så tjänsten hanterar textbeskrivningar av detta men hänvisningar till sig själv (en kurs består av lektioner, t.ex.) och olika "assets", som Lessons-tjänsten kan slå upp via Assets-tjänsten. Den kan också hämta lämpliga övningar via Quiz-tjänsten. Lektioner och kurser sparas i en no-SQL mongoDB. Quiz hanterar övningar som användaren antingen kan starta direkt eller via en kurs/lektion. Övningarna lagras i en Postgres-databas. Alla lektioner, kurser, övningar och "assets" en användare tittar på lagras i Log-tjänsten samt metadata kring dessa, t.ex. hur många rätt en användare hade på en övning, hur lång tid det tog, vilka lektioner den följt, position i videor, osv. All denna metadata lagras i en no-SQL mongoDB.

Stats hanterar en användares statistik och hela gamification-delen. Här kan en användare se vilka "badges" den låst upp, hur den förhåller sig mot andra användare, och så vidare. Alla uppgifter baseras på data från Log-tjänsten, och för att minska belastningen på denna sparas uppgifterna i en memcache. För att hitta rimlig svårighetsgrad på uppgifter kan Quiz-tjänsten hämta uppgifter från Stats.

Då gamification kräver en hel del beräkningar sker dessa offline. Varje natt sammanställs en användares progression via Calc-tjänsten. Denna har en lokal Postgres-databas som innehåller regler för t.ex. badges. Den hämtar data och skickar tillbaka data till Log.

Kapacitetsbehov

Kunden uppskattar att följande behövs för att hantera nuvarande krav på kapacitet.

NamnAntalCPUerMinne (GB)Lagring (GB)Kommentar
Lastbalanserare1---Skall klara 50 - 2500 QPS (Queries Per Second) via HTTPS.
Front-end2121-
Postgres RDBS42125 - 1000Assets använder 1000 GB, övriga 25
no-SQL mongoDB22125 - 1000Log använder 1000GB och Lessons 25GB
memcache12165Främst lagring för operativsystem och applikationskod
Calc14165Främst lagring för operativsystem och applikationskod
Övriga tjänster6225Främst lagring för operativsystem och applikationskod

Trafiken ligger i snitt på ca 50 QPS, men kan toppa på ca 2500 QPS under vissa kortare perioder under vissa dagar eller under kortare perioder (dagar) till följd av t.ex. en marknadsföringskampanj. Kunden förväntar sig att trafiken kommer att dubbleras under översiktlig framtid, dvs att normalen blir 100 QPS och att topparna når 5000 QPS. En molnlösning måste kunna skala för att hantera detta.

Ditt uppdrag

Kunden är intresserad av vilken molnplattform den bör använda, hur applikationen kan föras över till denna (t.ex. hur skissen ovan kommer att förändras) samt ungefär hur mycket drift kommer att kosta för nuvarande kapacitet och framtida skalning.

De är särskilt intresserade av:

  • Vilka garantier för tillgänglighet ger molnplattformen och vad händer om de inte lever upp till detta? Applikationen lovar 98% upptid, så molnplattformen måste minst garantera detta.
  • Vilket stöd finns för lastbalansering?
  • Vilket stöd finns för att automatiskt skala frontend och andra tjänster?
  • Kan databasen som lagrar blob:ar bytas mot något bättre? Kunden avser att öka videoinnehållet i applikationen till ca 1000 timmar 1080p på kort sikt. De är osäkra på exakt hur stora filerna kommer att bli, men räknar med ca 20GB per timme för video. Övriga (dvs grafik och ljud) behöver ca 500 GB och de tror inte att detta kommer att öka.

Vad kommer nuvarande kapacitet att kosta per månad och hur mycket dyrare blir skalningen då man ökar med 1000 timmar video och upp till 5000 QPS? För att hantera 5000 QPS uppskattar kunden att man måste dubbla antalet front-end servrar samt skala databaserna databaslagringen med ca 150% och lägga till en två extra servrar för tre av de övriga tjänsterna (vilka spelar inte någon roll för denna uppgift).

Kunden har inte någon åsikt om vilken molnplattform som skall användas, så du får välja vilken du vill undersöka (av GCP, AWS och Azure).

Krav på rapport

  1. Din rapport skall vara tillgäng via repot för Examinationsuppgift 2 i PDF senast vid deadline. Den får finnas i andra format, men måste finnas i PDF.
  2. Skriv inte namn och id i din rapport, så peer-review kan ske anonymt.
  3. Inkludera en kort beskrivning av den molnplattform du valde.
  4. Rapporten skall utförligt besvara de frågor kunden har.
  5. Rapporten bör skrivas på svenska, men det är tillåtet att skriva på engelska om man vill. Tänk på stavning och grammatik!

Deadlines

  • Rapporten skall vara tillgängligt i ditt repo exam2 senast den 11/10.
  • Peer-review skickas ut 12/10 med instruktioner. Den skall vara klar och tillgänglig via exam2 senast den 18/10.
  • En version som åtgärdar feedback från examinator och peer-review skall finnas tillgänglig i exam2 vid kursens slut.