Moin Community,
dieses Thema sollte nicht zu ernst genommen werden und diente eher als eine Art Experiment um die Möglichkeiten
einer MMORPG Serverarchitektur zu testen. Die gesammelten Erfahrungen würde ich bis zu einem gewissen Grad teilen
und eventuell kann der eine oder andere auch weitere Ideen reinbringen. Vorab möchte ich sagen jeder der diesen kleine Bericht
liest und mich anschreibt und fragt ob er die Serverfiles für dieses Projekt haben kann, es gleich lassen kann. Mir gehören die Fiels nicht
und habe selbst nur ca. 5% des Codes beigetragen. Ich habe hauptsächlich die Infrastruktur aufgesetzt und verwaltet, sowie
die Architektur designed.
Worum geht es denn nun eigentlich ?
Wie die meisten wissen handelt es sich beim Metin2 Server um eine monolithische Anwendung
"Monolithic applications are designed to handle multiple related tasks. They’re typically complex applications that encompass several tightly coupled functions.As you can imagine, given their broad scope, monolithic tools tend to have huge code bases. Making a small change in a single function can require compiling and testing the entire platform, which goes against the agile approach today’s developers favor."
Heutzutage setzen wir im modernen Umfeld auf Service basierte Architekturen, dass heißt wir brechen große Applikationen in mehre, teilweise auch hunderte kleine Applikationen auf und lassen die miteinander kommunizieren. Dies hat viele Vorteile wie:
- Einfach zu maintainender code, da die Services unabhängig voneinander funktionieren und ledgelich eine abstracke Schnitstelle bieten
- Seperations of concerns: Ein service hat immer nur 1 Aufgabe/Domain die er behandelt.
- Übersichtlicherer Code
- No single point of failure
- Schnellere compile times
- Gezielte verticale/horizontale Skalierung
- etc.
Wir haben im Rahmen dieses Experiments die Serverarchitektur in 3 Services aufgeteilt (ja man kann diese noch weiter aufteilen, aber wird extrem complex)
- Auth
- Chat ( Beinhaltet nur den Worldchat sowie private Chat + offline messages)
- World
Was mussten wir vorher erledigen?
- Update den komplleten Serverside & Clientside Code auf C++17/C++20
- Update sämtlicher Libs
- Update des MySQL Connectors
- Anpassungen der SQL Query systems
- Rewrite des kompletten Chat Systems
- Rewrite des kompletten Auth Systems ( Implementierung einer Methode, sodass die anderen Systeme/Instancen vom Auth wussten)
- Rewrite des Networkings
Wie hosten wir so eine Architektur?
Gute Frage wir hosten es natürlich in der Cloud. In welcher Cloud ? In unserem Fall haben wir das Experiment in der GCP (Google Cloud Platform) gehostet.
Aber gleichermaßen hätten wir Aamazon Web Services, Microsoft Azure, oder IBM Cloud oder Digitalocean verwenden können. Ja uns ist es bewusst das diese
aktiv gegen DCMA vorgehen aber mit einer TCP proxy vor dem ganzen System wird der Traffic nur den proxy geroutet und keiner weiß wo ihr eiegentlich hostet.
Welche Services verwenden wir?
- GKE Autopilot ( Manged Kubernetes Kluster im Autopilot modus)
- Compute Engines (Fancy name für VPS)
- Cloud SQL (Fancy version of MySQL in der Cloud mit sharding und edge locations)
- Cloud Bigtable ( NoSQL Database für Playerlogs (werde ich nicht thematisieren))
- Cloud Amor ( Firewall von Google (werde ich auch nicht thematisieren))
- Cloud Loadbalancing
Bitte melden Sie sich an, um dieses Bild zu sehen.
Was ist Kubernetes?
Kubernetes ist ein Container Orchestration System. Es erlaubt uns Services in Docker Containern zu definieren und diese automatisch zu skalieren.
Jedder Container ist ein sogenannter POD. Diesem können mehr vCPUs oder Ram je nach Auslastung zugewiesen werden. Da aber nicht jeder Service
mit mehr Ressourcen besser skaliert, können auch sogenannte Replicas eingesetzt werden. Das sind exakte kopien des Services und die user werden mittels
des Cloud Load Balancers auf die Instanzen verteilt. In GKE können wir Scaling-Rules setzen z.B. je nach Network/vCPU/RAM Verbrauch. Beispielweise sagen wir
user Auth POD hatte eine Rule für Replica-Saklierung bei 80% Auslastung von vCPU und RAM. Sollte dies erreicht werden instanziert das System automatisch eine weiteren Auth Server.
In diesesm Beispiel erlauben wir es nur den Auth Service mehre PODs zu instanzieren. Chat und Game Server bekommen je nach Auslastung mehr Hardware Ressourcen zugewiesen.
Außerdem prüft Kubernetes ob die PODs noch alive sind, sollte einer nicht mehr funktionieren, wird dieser zerstört und ein neuer aufgesetzt.
Was bringt uns das jetzt?
Ganz einfach kosten sparen und je nach auslatung nachskalieren und unnötigerweise selber einen neuen Server aufzusetzen.
Wenn Beispielsweise nur 100 Spieler online sind skalieren die PODs runter z.B. downscaled der Server von 4vCPU und 8 GB Ram runter auf 2vCPU und 4 GB ram. Je nach Auslastung.
Wir nutzen nur die Ressourcen die wir wirklich brauchen. Dies spaar uns Kosten, da das Billing teilweise pro Sekunde/Stunde funktioniert.
Was haben wir beobachtet im Rahmen des Experiments:
- Reduction in Packetanzahl/Packetcomplexity um ca. 10-20% auf dem Gameserver
- Du bekommst den Server nicht down, beim besten willen nicht. Es sei du hast Fehler im Code.
- Bugs mehr als Deadline 2 - wir haben nicht alles gefixt, da es nur ein Experiment war
- Metin2 in die Cloud zu ziehen ist lustig aber absolut Sinnlos, solange man keine License hat
- Teuer für normale Hosting Verhältnisse wie OVH, HETZNER etc.
- Viel Zeit & Erfahrene Entwickler braucht es
- Einer musste Cloud Kentnisse haben und basic DevOps Knowledge besitzen
- Lasst es einfach sein wir haben eigentlich nur Zeit verschwendet.
Nun die Kosten:
- Cloud SQL : Pro vCPU 36,1$ , Pro GB RAM 6,13$, PRO GB SSD Speicher 0,17$ (Alles pro Monat)
- GKE Autopilot: Pro vCPU 32,4850$ , Pro GB Ram 3,5934245$, Pro GB SDD Speicher 0,04$ pro Monat, GKE 0,10$/STD Mangement Gebühr
- etc.
Am ende hätte man bei Livebetrieb eine Rechnung pro Monat im Bereich von 500-1500€ je nach Spieler Anzahl. Achtung vor Kostdesasters!
Es gibt keine Billing Limit, da ihr Kreditkarte oder Konto hinterlegen müsst. Ihr könnt den maximalen Verbrauch über Billing Rules setzen.
Fazit:
Wie ich schon mehrfach angeteasert habe war der Zeitaufwand viel zu hoch und auch die Hostingkosten rentieren sich nur für die größten Server.
Ihr solltet also nie mit dem Gedanken spielen Metin2 Cloud ready zu gestallten. Aber für diejenigen die eventuell davon träumen irgendwann
ihr eigenes Spiel zu entwickeln kann ich die Cloud nur empfhelen. Am Ende dieses Projektes ist ein halbfertiges Produkt entsanden welches
mehr Bugs und Probleme besitzt, als es uns Lieb ist.
Ich danke euch dass ich eure Zeit verschwenden konnte.
