Présentation de Quasar
Le mardi 14 septembre 2021 est une date clé qui marque la fin d'une ère mais aussi l'accès à une mine d'opportunités pour EVE Online. Caché au milieu des lumières aveuglantes de la nouvelle ENJ et sous les pixels des projets de compétences, un changement fondamental s'apprête à voir le jour dans l'évolution future d'EVE Online.
C'est en 2011 que la couche de réseaux a été fondamentalement modifiée pour la dernière fois, avec l'implémentation d'IOCP de CCP, « CarbonIO », qui est devenu par la suite la fondation de la célèbre dilatation du temps. Si au départ, sous le nom de « Project Sanguine » ne se cachait qu'un brouillon, la réflexion débuta avec le problème d'espace qui entravait CarbonIO. À chaque optimisation d'EVE, il faut négocier prudemment avec le Global Interpreter Lock (verrou d'interpréteur global ou GIL) de Python. Seulement voilà, Python ne sait faire qu'une chose à la fois. Que ce soit via l'adoption par EVE du langage de programmation Stackless Python, l'implémentation d'IOCP via StacklessIO puis CarbonIO et la conception coopérative autour de la dilatation du temps, tout tend à maintenir l'illusion : New Eden respire. Et s'il n'était pas utile d'avoir recours au GIL à chaque fois qu'une idée émerge ? Comment tirer profit de la tendance de l'industrie du hardware à délaisser la vitesse des processeurs individuels au profit d'une généralisation du multicœur ?
De nombreuses expériences, annexes au Project Sanguine, ont été menées dans ce sens, la plus connue du grand public étant EVE: Aether Wars. L'objectif n'était pas de modifier fondamentalement le modèle de communication d'EVE Online, mais plutôt son système de simulation. Le Project Sanguine, quant à lui, s'est attaqué aux parties plus rébarbatives que représente l'ensemble dense de fonctionnalités d'EVE. Si New Eden n'avait pas à s'occuper de tous les à-côtés, simuler la présence de près de 9 000 joueurs au même endroit serait plus rapide. Le Project Sanguine s'est donc concentré sur deux objectifs : esquiver le GIL et faire place nette pour plusse-de-lasers.
Le Project Sanguine sous sa forme initiale a vu le jour avec l'ESI et la première itération de l'EVE Portal fin 2016. À travers tous ces projets, un nouveau paradigme fut établi au sein de l'architecture du serveur d'EVE Online : un bus de messages. Grâce à cette nouvelle échappatoire, les problèmes associés au GIL furent appréhendés différemment, avec une vision plus claire de leurs nombreuses manifestations : routage des messages, sérialisation et transmission. Si un vaisseau tire un laser au milieu de 1 000 autres vaisseaux, alors 1 000 messages doivent être envoyés sur-le-champ aux quatre coins de la planète. La simulation doit transmettre ce message à 1 000 destinataires sous la forme d'une copie (routage de messages), convertir ces données en format filaire (sérialisation), puis les envoyer via le fil (transmission). Dans la plupart des cas, CarbonIO a répondu à chacun de ces problèmes, mais toujours sous le contrôle du GIL. EVE Online a longtemps utilisé CarbonIO, mais beaucoup de choses ont changé dans les méandres de l'Internet depuis 2011.
Compte tenu de l'évolution des modèles dans ce nouvel écosystème, il était clair qu'un protocole plus homogène devait être mis en place si ce paradigme devait être exploité. Grâce à l'intégration du gRPC, il est devenu possible de combiner les capacités de routage du bus de messages avec la sérialisation hyper rapide des tampons de protocole (norme des messages gRPC). La planification pour la transmission des données avec le GIL reste requise, mais elle est désormais mise en tampon à un niveau supérieur sur un fil à part. Cela signifie que transmissions, sérialisations et routages de messages se font tous en dehors du GIL, à l'exception de la copie de mémoire qui doit intervenir entre temps. On peut difficilement faire plus rapide.
Plusse-de-lasers
Un tuyau a ainsi été attaché à New Eden, mais pour mener où ? Avec la création de l'ESI, d'autres technologies cloud-native telles que Kubernetes ont été adoptées. Et alors que le besoin de primitives concurrentes simples se faisait ressentir pour digérer ces informations, un transfert vers Go a été opéré. Ces technologies se cumulant dans un écosystème qui leur était propre, le premier objectif consistait à créer des fonctionnalités afin de tirer profit de la nouvelle compatibilité avec New Eden, avec des standards modernes. Vous en avez déjà vu un paquet.
La première fonctionnalité était le tracker d'activité. Connecté au tuyau, ce tracker contrôle la respiration de New Eden pour suivre la progression de toutes vos prouesses. La fonctionnalité Opportunités en est une autre variante. Elle tente de prédire la trajectoire que va emprunter un capsulier pour mettre l'accent sur les parties les plus intéressantes de New Eden. Le bus de messages a également été utilisé pour alimenter les classements des sites d'expérimentation abyssaux. Un énorme travail a été réalisé pour fournir aux équipes de développement un écosystème afin que ces fonctionnalités leur permettent d'exploiter toute la puissance d'une architecture de messages. En revanche, il y a un fossé entre les capacités de chacune de ces fonctionnalités : le client de bureau.
Avant l'existence des projets de compétences, chaque fonctionnalité convoyait « secrètement » des données vers Tranquility via CarbonIO. Cela n'est plus le cas, car les opérations des projets de compétences non seulement sont transmises via le gRPC, mais en plus n'entrent jamais en contact avec Tranquility ou sa base de données.
En quoi est-ce si important de contourner Tranquility et sa base de données ? Pour bien le comprendre, il faut d'abord parler des échecs. Notre aventure nous a menés vers de nouvelles techniques et des outils inédits qui nous permettent de visualiser New Eden. L'un des concepts est le traçage distribué qui utilise l'un de nos nouveaux jouets favoris : Honeycomb.io. (Pour en savoir plus sur cette aventure, cliquez ici.) Une fois armés de nos nouveaux jouets, nous avons vite compris ce qu'il se passait lors de la mise en ligne des projets de compétences :
On pouvait aussi estimer que, de manière générale, la performance était convenable, même s'il y avait encore des progrès à faire :
Le lendemain matin, un singe du chaos est apparu et s'est mis à harceler les pauvres hamsters :
Oui, il faut bien 500 000 millisecondes, soit 8 minutes et 20 secondes, pour envoyer un message. Difficile de comprendre le phénomène en détail si l'on est sobre et sans tableau blanc. Mais voici ce qu'il faut retenir de cet échec : Tranquility n'a pas crashé, des milliers de joueurs n'ont pas été déconnectés et la plupart n'ont même pas été affectés par le problème (la majorité des messages sont toujours regroupés tout en bas du graphique). Cela s'explique par le fait que nous ne communiquons pas du tout avec Tranquility au sens classique du terme. Les proxys traditionnels n'utilisent pas CarbonIO et ne vont pas dans le nœud du serveur puis dans la base de données. À la place, Tranquility se concentre sur l'essentiel et le client de bureau d'EVE communique via le gRPC dans le nouvel écosystème où le service des projets de compétences est en place avec sa propre base de données.
Comme vous en souvenez certainement, il y a peu, un volcan a été drainé pour tester une journée sans maintenance sur Tranquility. L'une des caractéristiques les plus puissantes du nouvel écosystème : zéro maintenance. Il n'a pas été nécessaire de redémarrer Tranquility pour sauver les projets de compétences. Et il n'a pas non plus fallu déployer un patch pour le serveur ni pour le client de bureau.
C'est un aperçu de ce qui attend le Project Sanguine, lequel va devenir la nouvelle plateforme technologique d'EVE : Quasar. Nous avons le sentiment que le moment était opportun pour lui donner un nom afin de mieux saisir ce qu'il représente et qu'il soit mieux référencé. Cela vous donne également un meilleur aperçu de toutes les avancées technologiques récentes réalisées dans EVE et de la manière dont elles s'alignent avec notre volonté de préparer le jeu pour une troisième décennie de succès. Heureux hasard, ce quadrant s'appelle Gateway (passerelle), car il annonce l'utilisation directe des passerelles gRPC.
Et puis, un nom pareil, ça fleure bon l'espace.C'est juste parfait.
Et ensuite ?
Nous continuons à faire place nette en remettant en état de nombreux anciens services, ce qui nous permettra d'avancer dans deux directions : construire plus de capacités fondatrices pour Quasar, notamment en manipulant plus que juste les projets de compétences dans l'univers ; et mettre à niveau les systèmes anciens pour ouvrir la voie à une itération plus rapide.
Qu'est-ce que cela signifie pour un capsulier moyen ? Plus d'occasions de révéler des fonctionnalités plus puissantes sur plus de médias.
Il a également été envisagé de publier des données de simulation via Quasar... mais ça, c'est un sujet pour plus tard !
