Hvad kræver det egentlig at hoste en app, hvor tusindvis af brugere spiller samtidig i realtid? Mere end de fleste tror. Og mindre end hostingudbydere gerne vil sælge dig.
Realtid er ikke det samme som en hjemmeside
En statisk hjemmeside sender HTML til browseren og er færdig. Forbindelsen lukkes, og serveren glemmer, at du eksisterer, indtil du klikker igen. En spilapps backend gør det modsatte: den holder forbindelsen åben, så længe du spiller. Hver brugerhandling, hvert nyt tal i bingo, hver chatbesked, det hele sendes frem og tilbage i realtid via WebSockets eller lignende protokoller. Det betyder konstant trafik, ikke bare ved sidevisninger. Serveren skal altså holde styr på hundredevis af samtidige forbindelser uden forsinkelse, og det stiller krav til både CPU og hukommelse på en helt anden måde end et standard CMS eller en WordPress-side.
Latency er fjenden her.
Går der 300 millisekunder for meget, føles spillet langsomt og uresponsivt. Går der et helt sekund, forlader brugerne appen og kommer ikke tilbage. For mobilspil er grænsen endnu lavere, fordi folk spiller på farten med ustabilt signal, der skifter mellem mobilmaster og wifi-netværk undervejs. Det kræver servere tæt på brugerne, typisk via et CDN eller edge-netværk med compute-kapacitet i den region, hvor dine brugere befinder sig. En server i Frankfurt hjælper ikke en bruger i Aalborg, hvis pingen er 80 ms, når den kunne være 15 ms fra en node i København. Og den forskel mærker brugeren, selvom de ikke ved, hvad ping er.
Skalerbarhed uden overpriser
Spilleapps har ujævn trafik. Det er nemlig ikke som en nyhedsside, der har nogenlunde forudsigelig belastning henover dagen. Kl. 14 en tirsdag er der måske 200 brugere online. Kl. 20 en lørdag kan der være 5.000. Og lige efter en kampagne på sociale medier kan tallet eksplodere til noget helt tredje. Den forskel er enorm, og den stiller helt konkrete krav til infrastrukturen, som mange udviklere ikke tænker over, før appen allerede er gået ned under belastningen.
Traditionel hosting med faste servere betyder, at du enten betaler for kapacitet, du ikke bruger det meste af tiden, eller at appen går ned, når trafikken topper. Ingen af delene er acceptable for en app, der vil beholde sine brugere i et marked, hvor konkurrenten er et enkelt klik væk. Containerbaserede løsninger som Kubernetes gør det muligt at skalere op og ned automatisk baseret på den aktuelle belastning. Men opsætningen er ikke triviel. Det kræver DevOps-kompetencer, løbende overvågning og vedligeholdelse af konfigurationen.
Og prisen følger med. Mange app-udviklere undervurderer hostingomkostningerne markant, fordi de regner på gennemsnitstrafik i stedet for spidsbelastning. En solid infrastruktur koster typisk 2-5 gange mere end det, man først estimerer, når man medregner database-replikering, daglig backup, overvågningsværktøjer, logning og fejlhåndtering. Så regnestykket er ikke bare “hvad koster en server”, men “hvad koster det at holde appen oppe, når 4.000 mennesker trykker på den samtidig en fredag aften”.
Database og tilstand
Spildata er anderledes end e-handelsdata på en måde, der har store konsekvenser for valg af database. En webshop skriver til databasen, når nogen bestiller noget. Det sker måske et par hundrede gange i timen for en travl butik. Et onlinespil skriver potentielt flere gange i sekundet per bruger. Hvert træk, hvert tal, hver statusopdatering, hver chatbesked. Det kræver en database, der kan håndtere mange samtidige skrivninger uden at låse og uden at miste data undervejs.
Redis til caching af sessiondata, PostgreSQL med connection pooling til persistente data, eller dedikerede spildatabaser bruges til formålet afhængigt af spillets art og skala. Men valget afhænger nemlig af, hvad spillet gør i praksis. Et bingospil med chatfunktion har andre krav end et MMORPG med tusindvis af samtidige spillere i samme verden, men det er stadig markant mere krævende end en blog eller en webshop, der bare skal gemme ordrer og kundeoplysninger. Sammenligningssider som den bedste bingo app giver et overblik over, hvad slutbrugeren oplever i den færdige app, men bag hver af dem ligger en hostinginfrastruktur, der håndterer netop de udfordringer, der er beskrevet her. Det, brugeren ser som en simpel appoplevelse, er resultatet af mange lag teknologi, der arbejder sammen.
Sikkerhed og oppetid
Spilleapps er mål for DDoS-angreb. Ikke altid fra sofistikerede hackere med komplekse motiver, men fordi konkurrenter eller utilfredse brugere kan købe et angreb for under 100 kr. online, og det kræver ingen teknisk viden at sætte i gang. En hostingløsning uden DDoS-beskyttelse er altså en konkret risiko for enhver spilapps tilgængelighed, ikke bare en teoretisk mangel, man kan ignorere i starten.
Hertil kommer kravet om oppetid. En e-handelsside kan overleve 30 minutters nedetid midt om natten uden katastrofe, fordi de fleste kunder sover. Et spil, der går ned midt i en runde, mister brugere permanent, fordi frustration over tabt fremgang og afbrudt oplevelse er langt sværere at tilgive end en side, der loader langsomt. 99,9 % oppetid lyder flot i en hostingpakke. Men det er stadig 8,7 timers nedetid om året fordelt på uforudsigelige tidspunkter. For spilapps er 99,95 % mere realistisk som minimumskrav, og selv det kræver redundante servere i flere geografiske zoner med automatisk failover.
Hvad skal du kigge efter
Vælg hosting med WebSocket-support ud af boksen, ikke som tillægspakke eller beta-feature. Tjek om autoskalering er inkluderet i prisen eller koster ekstra per instans. Spørg til database-IOPS og samtidige forbindelser, ikke bare lagerplads og båndbredde, som er de tal, hostingudbydere helst fremhæver, fordi de ser imponerende ud. Og hav en plan for, hvad der sker, når trafikken tredobles på en fredag aften, fordi en influencer deler din app med 200.000 følgere.
Det er nemlig ikke et spørgsmål om “hvis”, men “hvornår”. Moderne spilapps stiller krav, som de fleste standard hostingpakker slet ikke opfylder, uanset hvor flotte tallene ser ud i salgsmaterialet. Jo før du tager den erkendelse alvorligt og vælger infrastruktur derefter, jo færre brugere mister du, når det virkelig gælder. Og det er jo i sidste ende brugerne, hele forretningen hviler på. Ingen brugere, ingen forretning. Så simpelt er det.