Quasar ist hier
Dienstag, der 14. September 2021 ist ein Wendepunkt, der das Ende einer Ära bedeutet und EVE Online beträchtliche Möglichkeiten bietet. Verloren im grellen Licht der neuen NPE und unter den Pixeln der Skillpläne verborgen, wartet eine fundamentale Veränderung der Zukunft von EVE Online.
Die Netzwerkschicht wurde zuletzt im Jahr 2011 grundlegend verändert, als CCP IOCP als „CarbonIO“ implementierte, was letztlich die Grundlage für die berüchtigte Zeitdilatation bildete. Was zunächst als Gekritzel unter der Überschrift „Project Sanguine“ begann, entwickelte sich bald zu Überlegungen zum Problembereich von CarbonIO. Jede Optimierung in EVE muss auf den Global Interpreter Lock (GIL) von Python abgestimmt werden. Einfach ausgedrückt: Python kann immer nur eine Sache gleichzeitig tun. EVE verwendet Stackless Python, hat IOCP mittels StacklessIO und CarbonIO implementiert und verfolgt bei der Zeitdilatation einen kooperativen Ansatz. All diese Bemühungen dienen dem Zweck, die beliebte Illusion zu wahren, dass New Eden lebt und atmet. Was, wenn man nicht bei jeder neuen Idee den GIL im Hinterkopf haben müsste? Wie kann man davon profitieren, dass sich die Hardware-Industrie auf die Anzahl der Kerne statt auf die individuelle Taktfrequenz konzentriert?
Diesbezüglich wurden viele Experimente durchgeführt, die mit Project Sanguine in Verbindung stehen. Das bekannteste davon war das Projekt EVE: Aether Wars. Das Ziel lag dabei nicht in der fundamentalen Änderung des Kommunikationsmodells von EVE Online, sondern in der Änderung des Simulationsmodells. Im Gegensatz dazu lag bei Project Sanguine der Fokus auf dem komplexen Feature-Set von EVE und damit auf langweiligeren Aspekten. Die Simulation von nahezu 9000 Spielern im selben Raum könnte schneller durchgeführt werden, müsste New Eden sich nicht zusätzlich auf alle anderen Punkte auf seiner Liste Gedanken machen. Project Sanguine hatte somit zwei festgelegte Ziele: den GIL umgehen und Platz für mehr Laser schaffen.
Project Sanguine trat zunächst Ende 2016 in Form des ESI und der ersten Version von EVE Portal in Erscheinung. Mithilfe dieser Projekte wurde ein neues Paradigma in der Server-Architektur von EVE Online eingeführt – ein Message Bus. Dank dieser Hintertür wurden die durch den GIL bedingten Bottlenecks wiederentdeckt. Diesmal war jedoch eindeutiger zu sehen, in welcher Form sie sich manifestieren: Nachrichten-Routing, Serialisierung und Übertragung. Schießt ein Schiff inmitten von 1000 Schiffen einen Laser ab, müssen weltweit umgehend 1000 Nachrichten gesendet werden. Die Simulation muss diese Nachricht als Kopie an 1000 Empfänger adressieren (Nachrichten-Routing), die Daten in ein Datenübertragungsformat umwandeln (Serialisierung) und die Daten schließlich über das Wire senden (Übertragung). In den meisten Fällen hat CarbonIO jedes dieser Probleme behoben, allerdings stets unter „Aufsicht“ des GIL. CarbonIO hat EVE Online eine ganze Weile gute Dienste geleistet, doch seit 2011 hat sich in der stürmischen See des Internets viel getan.
Nachdem wir die Entwicklung der Muster im neuen Ökosystem beobachtet hatten, wurde ersichtlich, dass ein stärker standardisiertes Protokoll her musste, wenn das Paradigma jemals Anwendung finden sollte. Dank der Integration von gRPC war es möglich, die Nachrichten-Routing-Leistung des Message Bus mit der blitzschnellen Serialisierung der Protocol Buffers (Nachrichtenstandard von gRPC) zu kombinieren. Für die Übertragung muss man die Daten zwar immer noch auf den GIL abstimmen, allerdings wird dies nun in einem separaten Thread auf einer höheren Ebene zwischengespeichert. Somit erfolgen die Übertragung, Serialisierung und das Nachrichten-Routing außerhalb des GIL. Allein die Speicherkopie muss noch zwischendurch stattfinden. Viel schneller kann der Prozess nicht ablaufen.
Mehr Laser
New Eden verfügte jetzt über einen Datenkanal, doch wohin fließen all die Daten? Mit Beginn des ESI-Aufbaus wurden auch zunehmend Cloud-basierte Technologien wie Kubernetes eingeführt. Als man außerdem erkannte, dass für die Verarbeitung dieser Informationen simple Parallelitätsprimitive nötig waren, wandte man sich verstärkt Go zu. Als diese Technologien sich allmählich zu einem eigenen Ökosystem entwickelten, wurden Features erstellt, um von der neuen Möglichkeit, mit New Eden arbeiten und dabei auf moderne Standards zurückgreifen zu können, zu profitieren. Viele dieser Standards habt ihr bereits kennengelernt.
Der Aktivitätentracker war der erste. Er verbindet sich eigenständig mit dem Datenkanal und überwacht New Edens Atmung, um sämtliche eurer Exploits nachzuverfolgen. Mit den Gelegenheiten existiert zudem eine abgewandelte Form, die versucht, die Flugbahnen von Kapselpiloten zu berechnen, und interessantere Gebiete in New Eden hervorzuheben. Der Message Bus wurde außerdem zum Betreiben der Ranglisten des Testgelände des Abgrunds genutzt. Es war ein enormer Aufwand, den Entwicklerteams ein Ökosystem bereitzustellen, das die Vorteile einer Nachrichtenarchitektur mit diesen Features nutzen kann. Jedoch weist jedes dieser Features auf ein Leistungsdefizit hin: den Desktop-Client.
Bis zur Einführung der Skillpläne hatte jedes Feature mittels CarbonIO Daten nach Tranquility „geschmuggelt“. Dies ist nicht länger der Fall, da Skillplanvorgänge ausschließlich über gRPC kommuniziert werden und außerdem niemals mit Tranquility oder seiner Datenbank in Berührung kommen.
Wieso ist es so wichtig, Tranquility und seine Datenbank zu umgehen? Um das in Gänze verstehen zu können, muss man zunächst über die Fehlschläge sprechen. Unserer Reise hat uns unter anderem zu vielen neuen Techniken und Tools geführt, mit denen wir New Eden betrachten können. Eines dieser Konzepte ist das verteilte Tracing, das unser neues Lieblingsspielzeug einsetzt: Honeycomb.io. (Mehr dazu erfahrt ihr hier.) Als das Tool mit den neuen schicken Spielzeugen ausgestattet wurde, war klar, was nach seiner Veröffentlichung mit den Skillplänen geschehen würde:
Generell zeigte sich außerdem, dass die Leistung zwar in Ordnung war, aber noch deutlich Luft nach oben hatte.
Am nächsten Morgen erschien dann ein Chaosaffe, der anfing, die Hamster zu belästigen:
Ganz recht, es dauerte 500.000 Millisekunden (acht Minuten und 20 Sekunden), um eine Nachricht zu senden. Um die Details zu verstehen, greift man besser zu Fanfest-Bier und einem Whiteboard. Hier sind die wichtigsten Fakten zu diesem Ausfallzustand: Tranquility wurde nicht abgeschaltet, die Verbindung tausender Spieler wurde nicht unterbrochen und die meisten Spieler waren nicht betroffen (Im unteren Teil des Graphen seht ihr, dass ein Großteil der Nachrichten noch immer verpackt ist). Das liegt daran, dass wir überhaupt nicht im traditionellen Sinne über Tranquility kommunizieren. Das bedeutet: kein CarbonIO, das mit den klassischen Proxys kommuniziert, die erst an den Server-Knoten und schließlich an die Datenbank weiterleiten. Stattdessen konzentriert sich Tranquility auf wichtigere Aspekte und der Desktop-Client von EVE kommuniziert per gRPC mit dem neuen Ökosystem, in dem sich der Skillplan-Dienst mit einer eigenen Datenbank befindet.
Wie ihr euch vielleicht erinnert, wurde vor Kurzem einem Vulkan die Energie entzogen, um einen Keine-Downtime-Test für Tranquility durchzuführen. Eine der stärksten Eigenschaften dieses neuen Ökosystems: keine Downtime. Es war nicht nötig, Tranquility neu zu starten, um die Skillpläne zu retten. Es musste weder für den Server noch für den Desktop-Client ein Patch herausgegeben werden.
Das ist ein Blick auf die Entwicklung von Project Sanguine hin zur neuen Technologieplattform von EVE: Quasar. Wir hatten das Gefühl, dass es jetzt an der Zeit war, ihr einen Namen zu geben, damit sie leichter verständlich ist und man sich besser auf sie beziehen kann. Außerdem wollten wir euch einen genaueren Einblick in die jüngsten technologischen Fortschritte von EVE und geben und euch zeigen, wie diese EVE auf ein erfolgreiches drittes Jahrzehnt vorbereiten. Es ist eine glückliche Fügung, dass der aktuelle Quadrant den Namen „Gateway“ trägt und gleichzeitig die direkte Verwendung der gRPC-Gateways einläutet.
Und nun ja, Weltraumbegriffe. Die klingen einfach Hammer.
Was kommt als Nächstes?
Als Nächstes werden wir viele alte Dienste überarbeiten, um zweierlei Dinge voranzutreiben: Einerseits möchten wir die grundlegende Leistung für Quasar ausbauen, um mehr als nur Skillpläne im Universum zu bearbeiten. Andererseits wollen wir veraltete Systeme normalisieren, um den Weg für eine schnellere Iteration zu ebnen.
Welche Folgen hat das für gewöhnliche Kapselpiloten? Es tun sich noch mehr Gelegenheiten auf, noch mächtigere Features in noch mehr Medien zu entdecken.
Wir haben außerdem mit dem Gedanken gespielt, Simulationsdaten über Quasar zu veröffentlichen … das kann aber noch eine Weile dauern.
