Server schalen voor games: horizontaal vs verticaal

Wanneer een gameserver begint te groeien, is de eerste concrete beslissing meestal je strategie voor server schalen: dezelfde machine groter maken (verticaal) of de last over meer machines verdelen (horizontaal)? Beide zijn geldige routes, maar welke bij jou past, hangt af van de architectuur van je game, je aantal spelers en waar de bottleneck zich werkelijk bevindt. Dit artikel vergelijkt beide aanpakken op een praktische, technische manier.

Verticaal schalen: één krachtigere machine

Verticaal schalen (scale up) betekent meer CPU-cores, meer RAM of snellere schijven toevoegen aan je bestaande server. Het grootste voordeel is eenvoud: er verandert niets in je code en je ontwijkt de complexiteit van gedistribueerde systemen. Eén process, één database, één game-wereldstate die in het geheugen wordt bewaard — omdat alles op één plek staat, blijft de latency laag.

Klassieke MMO-architecturen zoals Metin2 of Tibia zijn goede voorbeelden: het meeste van de spellogica draait in één game process, in gedeeld geheugen. In zo'n systeem wordt van 200 naar 800 spelers gaan vaak opgelost met een snellere CPU en meer RAM. Bij cloudproviders kan dat zo simpel zijn als een instance in een paar minuten naar een grotere tier herschalen.

Maar verticaal schalen heeft een hard plafond:

• Fysieke limiet: zelfs de grootste machine raakt op een gegeven moment door de toe te voegen cores heen.
• Enkel faalpunt: valt die machine uit, dan valt de hele game uit. Er is geen redundantie.
• Niet-lineaire kosten: topklasse hardware wordt onevenredig duur per core.
• Single-core bottleneck: draait je game loop op één thread, dan is zelfs een machine met 32 cores beperkt door de snelheid van die ene thread.

Horizontaal schalen: meer machines

Horizontaal schalen (scale out) betekent de last over meerdere servers verdelen. In games is dat zelden "splits dezelfde wereld over twee machines", want game-state delen is lastig. In de praktijk komt horizontaal schalen meestal in een van deze patronen:

• Sharding: elke machine host een aparte wereld/realm/room. Spelers worden over shards verdeeld en hebben onderling geen directe interactie.
• Servicescheiding: onderdelen als auth, chat, matchmaking en betalingen worden aparte services die onafhankelijk schalen.
• Match-gebaseerde servers: in FPS/MOBA-achtige games draait elke match op een kortlevende server-instance; een orchestrator vult lege servers.

De kracht van de horizontale aanpak is elasticiteit: machines toevoegen als de last stijgt, weghalen als die daalt. Eén machine die uitvalt sleept niet het hele systeem mee. Daar staat de prijs van gedistribueerd zijn tegenover: state delen, communicatie tussen services, consistentie en deploymentcomplexiteit.

De echte vraag: waar zit de bottleneck?

Neem de schaalbeslissing op basis van meting, niet van gevoel. Vind eerst de echte bottleneck. Voor een snelle blik op Linux:

# Algemene last en CPU per core
htop

# Elke core afzonderlijk (om een single-thread bottleneck te zien)
mpstat -P ALL 1

# Disk-I/O-druk
iostat -x 1

# Aantal en status van netwerkverbindingen
ss -s

Deze output wijst de weg. Zit één core continu op 100% terwijl de rest idle is, dan is je probleem een game loop die niet parallelliseert; meer machines lossen dat niet op — je hebt een snellere CPU of threadscheiding in de code nodig. Zijn alle cores vol, dan helpt verticaal schalen een tijdje. Zit de bottleneck in de database, dan is noch horizontaal noch verticaal schalen van de app genoeg; repareer eerst de queries en indexen.

Meestal het juiste antwoord: eerst verticaal, daarna opsplitsen

Een realistisch groeipad ziet er zo uit. Begin met één goed geconfigureerde machine en schaal verticaal; dat is de goedkoopste en snelste route. Zet ondertussen de eenvoudigste horizontale stap: verplaats de database naar een eigen machine. Het game process en MySQL scheiden geeft vaak op zichzelf al veel verlichting, omdat de twee niet langer om dezelfde CPU en schijf vechten.

De volgende stap is de stateless onderdelen afsplitsen: chat, web-API, matchmaking. Die schalen moeiteloos horizontaal achter een load balancer (zoals nginx of HAProxy). Splits de eigenlijke game-wereld zo laat mogelijk; sharding is meestal het lastigste deel en moet alleen gebeuren als je het echt nodig hebt.

# Stateless API-services balanceren met nginx
upstream game_api {
    least_conn;
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    server 10.0.0.13:8080;
}

server {
    listen 80;
    location /api/ {
        proxy_pass http://game_api;
    }
}

Kosten en operationeel verschil

Verticaal schalen is operationeel goedkoop: één machine te beheren, één logstroom, één deploy. Maar zodra het de hardwarelimiet raakt, exploderen de kosten en is de flexibiliteit weg. Horizontaal schalen kan efficiënter zijn per eenheid hardware, maar voegt teamkosten toe: monitoring, service discovery, gedistribueerde logs, complexere deployments. Voor een klein project is vroeg horizontaal schalen vaak over-engineering.

• Weinig spelers, één wereld: schaal verticaal, splits de DB af.
• Veel realms/rooms: groei horizontaal met realm-gebaseerde sharding.
• Match-gebaseerde game: een dynamische serverpool aangestuurd door een orchestrator.
• Single-thread bottleneck: profile eerst de code; hardware lost het niet op.

Veelgestelde vragen

Wat probeer ik eerst, horizontaal of verticaal?

Bijna altijd verticaal. Overstappen naar een grotere machine duurt minuten en de code verandert niet. Pak horizontaal schalen pas aan als je het hardwareplafond nadert of als redundantie echt kritiek is.

Kan ik één game-wereld over twee machines splitsen?

Meestal niet, of in elk geval niet eenvoudig. Dezelfde wereld delen vereist dat de state consistent blijft over machines, wat erg moeilijk is. Kies liever aparte werelden (shards) of servicescheiding.

Lost schalen een database-bottleneck op?

Repareer eerst de queries en indexen. Een trage query wordt niet sneller door machines toe te voegen. Zijn de indexen eenmaal goed, dan worden stappen als read replicas of een aparte DB-server zinvol.

Wil je de bottleneck correct diagnosticeren voordat je je server vergroot, dan bekijk ik samen met jou je game-architectuur en bepalen we de schaalroute die het beste bij je past. Neem contact op en laten we het over je project hebben.