Le jeu EVE Online a adopté une approche non conventionnelle de l’observabilité distribuée en raison de la nature de son architecture ancienne et de l’ampleur de sa simulation temporelle. Plutôt que d’envoyer tous les segments puis de décider à la fin de la trace lesquels conserver, la plateforme utilise l’échantillonnage dès le début de la trace, avec un mélange d’échantillons déterministes et ajustés dynamiquement, afin de préserver une image exploitable du système sans ralentir la simulation ni augmenter la facture des données d’observabilité.
Nicholas Herring, de CCP Games, a présenté cette expérience dans un article publié par InfoQ, expliquant qu’EVE Online fonctionne dans un univers partagé unique regroupant tous les joueurs, et non sur des serveurs régionaux distincts. Son ancien système et l’environnement plus récent connu sous le nom de Quasar échangent environ 30 000 messages par seconde. La plateforme comprend également des millions de lignes de C, C++, Python et SQL, ce qui fait de l’introduction d’une nouvelle couche centralisée d’observabilité un défi opérationnel à part entière.
Pourquoi la plateforme n’a-t-elle pas adopté l’échantillonnage différé ?
La décision était liée aux performances et aux contraintes du système existant. Une partie d’EVE Online fonctionne avec Stackless Python 2.7 sur un seul processeur logique. L’équipe a donc estimé que l’extraction de tous les segments, suivie de leur envoi vers un point central pour traitement, pourrait nuire à la simulation elle-même. L’échantillonnage différé exige également de regrouper les segments en un seul endroit, ce qui peut masquer de grandes parties du système en cas de défaillance du chemin ou de la connexion d’agrégation.
À l’inverse, l’échantillonnage dès le début permet à chaque composant de prendre sa décision localement. Lorsque certaines parties se dégradent, l’équipe peut déduire l’emplacement du problème en observant les différences dans la capacité de ces parties à envoyer leurs données, plutôt que de perdre la visibilité sur l’ensemble du système.
Un mélange de déterminisme et d’EMA
Les anciens systèmes utilisent un échantillonnage déterministe afin de réduire le coût et l’impact sur les performances. Les composants plus récents de Quasar tirent quant à eux parti d’un algorithme de moyenne mobile exponentielle, ou EMA, qui surveille des clés telles que le type de message protobuf et sa fréquence d’apparition. Plus un message se répète fréquemment, plus son taux d’échantillonnage est réduit ; les messages rares ont, eux, davantage de chances d’apparaître.
Cette approche contribue à réduire le bruit produit par les événements répétitifs, comme le tir d’un très grand nombre de projectiles ou les changements d’apparence des vaisseaux. L’équipe ne s’appuie toutefois pas uniquement sur elle, car certains événements importants proviennent des anciens systèmes ou doivent être garantis au moins une fois. La répartition de l’EMA entre plusieurs instances produit ce que la présentation appelle le « high-water mark » : un seuil pratique minimal de volume de données qui ne peut pas être facilement réduit après l’augmentation du nombre d’instances, de l’espace des clés ou du taux de messages.
Qu’est-ce qui change en pratique ?
L’expérience montre que le réglage de l’observabilité ne commence pas par le choix d’un outil de traçage, mais par la compréhension de la nature des événements que l’équipe souhaite mesurer. CCP Games utilise des indicateurs de fonctionnalités pour intensifier temporairement l’observabilité d’une zone, d’un vaisseau ou d’un personnage donné, ou pour réduire l’observabilité des domaines moins importants. Elle s’appuie également sur des outils qui affichent les taux d’échantillonnage et déduisent le volume réel des événements, plutôt que de lire les chiffres bruts comme s’ils représentaient l’univers entier.
Dans l’une des configurations de Quasar, la plateforme a utilisé environ 60 millions d’événements par jour, en visant une utilisation proche de 90 % du quota disponible. Cela permet d’activer une observabilité intensive lorsque cela est nécessaire, tout en réduisant le risque de dépasser le coût prévu. Cette flexibilité exige toutefois une discipline opérationnelle : la présentation a évoqué des cas où des indicateurs d’observabilité avaient été laissés activés, ce qui a entraîné des alertes concernant l’augmentation des dépenses.
Limites à prendre en compte
Cette approche n’offre pas tous les avantages de l’échantillonnage différé. L’équipe ne peut pas contrôler ultérieurement le ratio entre réussites et échecs de la même manière, et les indicateurs de niveau de service peuvent donc devenir excessivement sensibles lorsque l’événement est très rare. L’expérience a également conclu que la prise de décisions d’échantillonnage au sein des clients de bureau pouvait masquer des interactions importantes ; c’est pourquoi l’équipe étudie le déplacement de cette décision vers un réseau de confiance au sein de l’infrastructure dorsale.
La conclusion pratique n’est pas que l’échantillonnage dès le début est toujours supérieur, mais que les contraintes réelles peuvent rendre un mélange de déterminisme, d’EMA et d’activation temporaire plus adapté qu’une architecture centralisée coûteuse. La valeur de cette approche reste liée à la capacité de l’équipe à définir ce qui mérite d’être observé, à comprendre le seuil de coût incompressible et à conserver au moins un échantillon de chaque type d’événement important.