Med en rasende vagtmand i hælene drøner du af sted hen over skinnerne, mens du indsamler guldmønter på stribe og springer for livet mellem modkørende tog.
Sådan lyder gameplayet i en nøddeskal i spilsuccesen Subway Surfers fra danske Kiloo og Sybo, som lige nu spilles af flere end 25 millioner smartphone- og tablet-brugere hver dag.
Men det er ikke kun fingrene på touchskærmen, der skal reagere hurtigt og konsekvent.
Det samme skal datacenteret hos det danske firma Zitcom A/S, som Kiloo har hyret til at spænde en private cloud ud under Subway Surfers. Det fortalte partner i Zitcom A/S Stefan Rosenlund på Version2's datacenterkonference i sidste uge.
Uden cloud-backend'en ville Kiloo og Sybo have gevaldige problemer med at betjene de mange millioner brugere, der typisk sender omkring 4.000 forespørgsler af sted mod backend'en. Hvert sekund.
For mens selve spillet er en traditionel app, der installeres og spilles på mobilen eller tabletten, kommer backend'en på banen, når brugerne udfordrer hinanden via eksempelvis Facebook.
Kiloo lagrer spildata som blandt andet highscores fra den enkelte spiller i backend'en på Zitcoms platform.
»Det er en vigtig del af spillet, og det servicerer vi i vores datacenter,« fortæller Stefan Rosenlund, partner i Zitcom, til Version2.
Valgte dansk sparring
Kiloo kunne i princippet have gået til internationale cloud-giganter som Amazon for at få cloud-backend'en på plads.
Men samarbejdet med Zitcom blev til, fordi spilfirmaet gerne ville have en dansk partner at sparre med om de vigtige spørgsmål omkring infrastruktur og software.
Ifølge Stefan Rosenlund er datacenteret hos Zitcom dimensioneret til at klare store belastninger, som kan være svære at forudsige omfanget af på forhånd.
»Vi har et højt skalerbart cloud-setup, som gør, at vi kan servicere eksempelvis et top-3 spil i iTunes,« siger han til Version2.
Succesen med Subway Surfers har oversteget forventningerne, fortæller han. Det har fået betydning for valget af database.
Kiloo’s database-backend har fra begyndelsen været bygget op på den kendte open source-database MySQL. Men på grund af den store interesse for spillet burde man i stedet have valgt et alternativ som MongoDB fra NoSQL-familien, der er kendt for at skalere langt bedre. Det kan blive en løsning på den længere bane.
»Det er alment kendt, at MySQL ikke er særlig skaleringsvenlig. Derfor har opgaven været at få MySQL-serveren tunet til at håndtere de mange queries,« siger Stefan Rosenlund til Version2.
Foreløbig har Zitcom dog løst problemerne ved at optimere konfigurationen af databasen og placere den på hurtige SSD'er fra Fusion IO - »SSD'er på speed«, som Stefan Rosenlund kalder dem.
En anden forbedring er hentet ved at skifte load balancer-leddet fra den kendte webserver Apache og over til dens mindre kendte lillebror, den russiske webserver med navnet nginx. Den håndterer de cirka 4.000 forespørgsler med blot to CPU-kerner og to gigabyte ram.
»nginx balancerer alle brugerne ud over et applikations-cluster (med seks Apache-servere, red.), og det er den virkelig god til,« siger Stefan Rosenlund.
Sikrer overdimensionering fremover
Netværket i datacenteret er baseret på et netværks-fabric fra Cisco, nærmere betegnet Nexus. Derudover har Zitcom sat sin lid til et standard VMware-miljø, hvor hver hypervisor i de fysiske Dell blade-servere er bestykket med mindst to CPU'er med hver seks kerner og 192 gigabyte ram.
Desuden kan der nævnes et Dell Compellant SAN, som nginx og applikationsserverne kører på, samt et Next Generation firewall-cluster fra Fortinet.
Alt i alt er der tale om et setup, som ifølge Stefan Rosenlund ikke har problemer med at følge med Subway Surfers.
»Det har været et kæmpe arbejde i at få det hele til at spille sammen. Det sværeste har været at komme over på en load-balanceret løsning baseret på nginx og at få MySQL-serveren til at skalere op,« siger han.
»Men nu ruller det bare. Lige nu er det overdimensioneret, og det skal vi løbende sikre, at det bliver ved med at være,« siger Stefan Rosenlund til Version2.
jeg forstår det rigtigt er der tale om en nginx mod 6x tomcat, op imod en fælles mysql, kan man virkelig kalde det for cloud ? og hvilke dele er virtualiseret ?
http://tomcat.apache.org/ ?
Vi bruger ikke Tomcat, det er almindelig Apache httpd.
I dette setup skal du se Apache serverne som applikationsservere og nginx som load balancer.
Alle dele af setuppet er virtualiseret.
Med mindre der automatisk provisioneres ekstra Apache backends efter behov, og de automatisk fjernes når behovet falder, uden at nogen tekniker skal gøre en finger, så er det bare et helt almindeligt non-cloud setup. Det samme med MySQL backends - men det lyder som om man kun har én, og så ryger cloud fidusen. Hvis ikke det er elastisk og skalerbart på alle punkter, så er det jo fis at at kalde det cloud.
Personligt synes jeg det eneste man kan tillade sig at have manuel proces for, er det at udvide med det fysiske jern. Hvis Der pludselig kommer 10x så mange brugere, så skal direktøren selv kunne hamre (f.eks) 4 stk jern i blade-chassiset, og 10 ekstra diske i storage, og vente, og vide at nu kommer der mere kraft i "skyen".
Er man ikke der, så er det ikke Cloud, men fintunet traditionel hosting.
Men, som det er nu, så kan alt få et stjerne-formet Cloud klistermærke, hvis bare det ikke er en it-fiasko, og der ofres it-presse-tid på det, for i 2013, så må det vel næsten være cloud hvis bare det virker? En artikel kan man jo altid hamre af, det er billig spalteplads.
Når nu snakken er i gang, så skal der da lyde en ros for faktisk at have lavet et system der virker og er overdimenstioneret, og håndterer en dansk international spilsuccess - for det er der trods alt andre der ikke har formået. Godt gået! :-)
Interessant pointe.
På version2 datacenter 2013 konference, blev der også snakket meget cloud.
Men alle har næsten deres holdning til hvad Cloud er, hvor nogle siger det skal direkte være elastisk, og andre egentlig syntes at Cloud bare skal være virtualiseret.
cloud er for mig en samling af teknologier som gør det muligt hurtigt at skalere sine ressourcer op og ned, i den forbindelse indgår virtualisering, et godt api og deling af ressourcer med andre i samme sky, det kan godt være en privat sky hvor flere virksomheder samarbejder om et fælles datacenter, men jeg syntes ikke en helt privat sky er det samme, fordi det er ikke godt at køre med overkacipet, det er spild af penge, det skal helst passe til behovet og være super nemt hurtigt at ændre hvis der opstår spidsbelastninger. Ellers et super interessandt setup som man kan lære lidt af.
Tillykke med succesen. Og at i har valgt den nemme vej til skalering af jeres database :)
Der er ikke nogen endelig definition på hvad cloud er, hver udbyder har sin egen definition. Hvergang jeg ser order bytter jeg det altid ud med "internettet" eller "en bunke computere".
Ovenstående setup ville jeg betegne som et cluster, ikke som en cloud løsning. Men hvis det hele kører på et vmware setup så kan jeg godt forstå at de kalder det en cloud løsning.
Men jeg er enig i at databasen udgør et problem, jeg er dog ikke enig i at det ikke kan løses. Der findes flere forskellige muligheder for at skalere MySQL Databaser.
F.eks. http://www.percona.com/software/percona-xtradb-cluster
defination af cloud
http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
men det er jo altid op til debat
For mig er det altså ikke andet end hosting, ikke cloud.
Cloud er elastik og kan flyttes fra datacenter til datacenter...
Men cloud er virkeligt et buzzword og der er >mange< definitioner på hvad cloud er...
Min ældste på ni kom hjem og snakkede om subway surfers som hun havde prøvet i en uendelighed, indtil hun fik det installeret på vores iPad. Det er aldrig sket før med noget spil. Hvor er det for sejt at det er et dansk firma der står bag.
Alt held og lykke med spilprojekterne fremad.
Og jeg synes cloud/ikke-cloud er mindre vigtigt, og et sidespor. 4000 connections i sekundet, det er fedt når man klarer den slags trafik.
Hvis i ser med har jeg et par spørgsmål:
1) hvad er en "connection", er det en https request på port 80 der rammer databasen hver gang, eller har vi noget caching på spil?
2) Har i haft nogle skalerings "ildebrænde" undervejs, som i måtte slukke undervejs?
Nu når der står der er succes med at bruge Nginx som load balancer, har der mon så også været forsøgt at bruge den til applikationsserverne?
Min erfaring med Nginx er at den skalerer langt bedre end Apache HTTPD, og med langt færre ressourcer. Hvis flaskehalsen omkring applikationsserverne, og grunden til der skal være seks af dem, er f.eks. PHP eller hvilket sprog koden nu måtte været skrevet i, kunne der sikkert være noget perfomance at hente ved at skifte Apache ud, da man så ville bruge færre ressourcer på at håndtere HTTP forespørgsler, og dermed have flere til at køre sin egen kode.
Hvorfor ikke Litespeed Webserver?
"1) hvad er en "connection", er det en https request på port 80 der rammer databasen hver gang, eller har vi noget caching på spil?"
Der er tale om en nyetableret HTTP connection mod nginx load balanceren.
Én HTTP connection er ikke nødvendigvis lig ét MySQL kald. Der bliver udnyttet memcache for at sammenlægge nogle forespørgsler, så man kan gøre nogle ting samlet.
Når vi har haft gang i tænketanken om de tekniske beslutninger i setuppet, så er der ingen tvivl om at man har skullet tænke en smule alternativt i forhold til hvodan man ofte gør. Ofte, så er udfordringen at folk laver meget tunge og store ting, men her er problemet at der er virkelig mange, meget små ting, så selv den mindste smule overhead der er blevet skåret væk har i det store billede temmelig meget betydning.
"2) Har i haft nogle skalerings "ildebrænde" undervejs, som i måtte slukke undervejs?"
Uden tvivl. Spillet startede med at ligge på en enkelt lille virtuel server med en LAMP stack installeret. Der er ingen tvivl om at vi nogle gange har måttet træffe nogle beslutninger i en fart for at kunne følge med den pludselige success af spillet.
Heldigvis har vi på intet tidspunkt haft problemer med vores infrastruktur så vi har skullet til at vente på leverancer af nyt jern. Det skal dog ingen hemmelighed være, at der er forsvundet nogle aftener og nætter med at sidde og nurse serverne når presset fra det internationale publikum er aller størst.
Vi har forsøgt at udskifte Apache med en løsning baseret på nginx og forskellige implementeringer af brugen af PHP.
Fælles for dem var, at når der kom rigtig meget load på, så blev der spawned voldsomt mange processer og så begyndte fastcgi backends at lave timeouts og give "temporarily unavailable"-svar. Applikationssvartiderne var også væsentligt højere, for de kald der ikke fejlede.
Vi har i mange andre tilfælde stor success med at gøre ting hurtigere ved brugen af nginx med PHP, men bare ikke her.
Løsningen er blevet Apache som er skraldet helt ned, så alle unødvendige moduler er fjernet. Vi har vurderet at en applikationssvartid på under 3 ms i gennemsnit inkl. db kald er acceptabelt.
Imponerende started (Især når man tænker på hvad man kan lave af ulykker i PHP) . Nu skriver du http, og ikke https. Vil det sige at jeg kan begynde at lytte trafik af, og fuske mig en sindssyg score?
Det er almindelige HTTP kald, der flyttes ingen sensitive data.
Det er ikke noget HTTPS kan ændre på, det vil kun give en kryptering af transporten. Det ville være meget dumt at lave en app og basere sikkerheden i API'et alene på det faktum at der kun kommer kald via HTTPS.
Det er ikke vanskeligt at finde frem til hvilke kald der laves til HTTPS, når man har adgang til den ene af enderne i kommunikationen.