Server-Skalierung für Spiele: horizontal vs. vertikal

Wenn ein Gameserver zu wachsen beginnt, ist die erste konkrete Entscheidung meist die Strategie zur Server-Skalierung: dieselbe Maschine vergrößern (vertikal) oder die Last auf mehr Maschinen verteilen (horizontal)? Beide Wege sind gültig, doch welcher zu dir passt, hängt von der Architektur deines Spiels, der Spielerzahl und davon ab, wo der Engpass tatsächlich liegt. Dieser Artikel vergleicht beide Ansätze praktisch und technisch.

Vertikale Skalierung: eine stärkere Maschine

Vertikale Skalierung (scale up) bedeutet, dem bestehenden Server mehr CPU-Kerne, mehr RAM oder schnellere Festplatten zu geben. Ihr größter Vorteil ist Einfachheit: am Code ändert sich nichts, und du umgehst die Komplexität verteilter Systeme. Ein einziger process, eine einzige Datenbank, ein einziger Spielwelt-State im Arbeitsspeicher — weil alles an einem Ort liegt, bleibt die Latenz niedrig.

Klassische MMO-Architekturen wie Metin2 oder Tibia sind gute Beispiele: der Großteil der Spiellogik läuft in einem einzigen game process, im gemeinsamen Speicher. In einem solchen System löst man den Sprung von 200 auf 800 Spieler oft mit einer schnelleren CPU und mehr RAM. Bei Cloud-Anbietern kann das so einfach sein wie eine Instanz in wenigen Minuten auf eine größere Stufe umzustellen.

Doch die vertikale Skalierung hat eine harte Obergrenze:

• Physische Grenze: Selbst der größten Maschine gehen irgendwann die hinzufügbaren Kerne aus.
• Single Point of Failure: Stirbt diese Maschine, stirbt das ganze Spiel. Es gibt keine Redundanz.
• Nichtlineare Kosten: Top-Hardware wird pro Kern überproportional teuer.
• Single-Core-Engpass: Läuft deine Game Loop auf einem Thread, ist selbst eine 32-Kern-Maschine durch die Geschwindigkeit dieses einen Threads begrenzt.

Horizontale Skalierung: mehr Maschinen

Horizontale Skalierung (scale out) bedeutet, die Last auf mehrere Server zu verteilen. In Spielen heißt das selten „dieselbe Welt auf zwei Maschinen aufteilen", denn Spiel-State zu teilen ist schwer. In der Praxis kommt horizontale Skalierung meist in einem dieser Muster:

• Sharding: Jede Maschine hostet eine eigene Welt/Realm/Room. Spieler werden auf Shards verteilt und interagieren über sie hinweg nicht direkt.
• Service-Zerlegung: Teile wie Auth, Chat, Matchmaking und Zahlungen werden eigene Services, die unabhängig skalieren.
• Match-basierte Server: In FPS-/MOBA-Spielen läuft jedes Match auf einer kurzlebigen Server-Instanz; ein Orchestrator füllt leere Server.

Die Stärke des horizontalen Ansatzes ist Elastizität: Maschinen hinzufügen, wenn die Last steigt, entfernen, wenn sie sinkt. Fällt eine Maschine aus, reißt sie nicht das ganze System mit. Dem steht der Preis des Verteiltseins gegenüber: State-Teilung, Kommunikation zwischen Services, Konsistenz und Deployment-Komplexität.

Die eigentliche Frage: wo ist der Engpass?

Triff die Skalierungsentscheidung durch Messung, nicht aus dem Bauch. Finde zuerst den echten Engpass. Für einen schnellen Blick unter Linux:

# Gesamtlast und CPU pro Kern
htop

# Jeder Kern einzeln (um einen Single-Thread-Engpass zu erkennen)
mpstat -P ALL 1

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

# Anzahl und Zustände der Netzwerkverbindungen
ss -s

Diese Ausgaben weisen die Richtung. Ist ein Kern dauerhaft bei 100%, während die anderen leerlaufen, liegt das Problem an einer Game Loop, die nicht parallelisiert; mehr Maschinen lösen das nicht — du brauchst eine schnellere CPU oder Thread-Trennung im Code. Sind alle Kerne voll, hilft vertikale Skalierung eine Weile. Liegt der Engpass in der Datenbank, reicht weder horizontale noch vertikale App-Skalierung; korrigiere zuerst Queries und Indizes.

Meist die richtige Antwort: erst vertikal, dann zerlegen

Ein realistischer Wachstumspfad sieht so aus. Beginne mit einer einzigen, gut konfigurierten Maschine und skaliere vertikal; das ist der günstigste und schnellste Weg. Mache währenddessen den einfachsten horizontalen Schritt: verlege die Datenbank auf eine eigene Maschine. Den game process von MySQL zu trennen bringt allein oft große Entlastung, weil beide nicht mehr um dieselbe CPU und Festplatte kämpfen.

Der nächste Schritt ist, die zustandslosen Teile abzuspalten: Chat, Web-API, Matchmaking. Diese skalieren hinter einem Load Balancer (etwa nginx oder HAProxy) mühelos horizontal. Spalte die eigentliche Spielwelt so spät wie möglich ab; Sharding ist meist der schwierigste Teil und sollte nur erfolgen, wenn du es wirklich brauchst.

# Zustandslose API-Services mit nginx ausbalancieren
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- und Betriebsunterschied

Vertikale Skalierung ist im Betrieb günstig: eine Maschine zu verwalten, ein Log-Strom, ein Deploy. Doch sobald sie die Hardwaregrenze erreicht, explodieren die Kosten und die Flexibilität ist dahin. Horizontale Skalierung kann pro Hardware-Einheit effizienter sein, bringt aber Teamkosten: Monitoring, Service Discovery, verteilte Logs, komplexere Deployments. Für ein kleines Projekt ist frühes horizontales Skalieren oft Over-Engineering.

• Wenige Spieler, eine Welt: vertikal skalieren, die DB abspalten.
• Viele Realms/Rooms: horizontal mit realm-basiertem Sharding wachsen.
• Match-basiertes Spiel: ein dynamischer Server-Pool, gesteuert von einem Orchestrator.
• Single-Thread-Engpass: zuerst den Code profilen; Hardware löst es nicht.

Häufige Fragen

Was sollte ich zuerst versuchen, horizontal oder vertikal?

Fast immer vertikal. Der Wechsel auf eine größere Maschine dauert Minuten und der Code bleibt unverändert. Greife erst zur horizontalen Skalierung, wenn du dich der Hardwaregrenze näherst oder Redundanz wirklich kritisch ist.

Kann ich eine einzelne Spielwelt auf zwei Maschinen aufteilen?

Meist nein, zumindest nicht einfach. Dieselbe Welt zu teilen erfordert, den State über Maschinen hinweg konsistent zu halten, was sehr schwer ist. Bevorzuge stattdessen getrennte Welten (Shards) oder Service-Zerlegung.

Behebt Skalierung einen Datenbank-Engpass?

Korrigiere zuerst Queries und Indizes. Eine langsame Query wird durch zusätzliche Maschinen nicht schneller. Sind die Indizes erst richtig, ergeben Schritte wie Read Replicas oder ein dedizierter DB-Server Sinn.

Wenn du den Engpass korrekt diagnostizieren willst, bevor du deinen Server vergrößerst, schaue ich mir gemeinsam mit dir deine Game-Architektur an und erarbeite den passenden Skalierungsweg. Kontaktiere mich und lass uns über dein Projekt sprechen.