L’optimisation des journaux de serveurs afin d’améliorer l’expérience du joueur

En novembre 2020, un joueur de Rainbow Six Siege publie une vidéo sur Twitter qui démontre que l’enregistrement des impacts de ses coups semble échouer lors d’un match.

Quand l’équipe de prod de R6S tombe sur la vidéo, elle s’emploie à déboguer le problème — même si le seul indice qu’elle a est ce tweet, le bogue n’ayant jamais été soumis officiellement.

En effet, les dévs de R6S tentent d’investiguer ou d’évaluer tout bogue, qu’il soit noté officiellement par l’entremise de R6fix, une plateforme à partir de laquelle les membres de la communauté peuvent soumettre un rapport de bogue directement au Jira de l’équipe de prod, ou officieusement, à travers les diverses sous-sections de l’internet.

On a le doigt sur le pouls de la communauté en tout temps, indique Jason Egginton, chef d’équipe informatique-réseaux de Rainbow Six Siege. Alors on réagit aux publications de nos membres.

Cela dit, la vision de l’équipe de dév de répondre à toute rétroaction de la communauté doit s’entrecroiser avec la réalité de l’équipe des opérations , qui, elle, doit pouvoir stocker des pétaoctets de données de manière efficace et pratique.

Il s’agit d’un dilemme «dév vs ops» que l’équipe réseaux a entrepris de résoudre au cours de la dernière année.

La face cachée de l’observabilité

Parlons de données. Les serveurs de Rainbow Six Siege répartis sur tous les continents hébergent plusieurs millions de matchs par jour. Chaque match génère un journal de dix à 50 mégaoctets; on calcule donc que cinq à sept téraoctets de données sont générés quotidiennement, pour un total de 200 téraoctets de données mensuellement.

Une saison de Rainbow Six Siege dure trois mois. Si l’équipe veut se permettre de comparer les régressions et améliorations d’une saison à l’autre, elle devra donc stocker ses données pour au moins six mois, ce qui veut dire stocker 1,2 pétaoctet de données en tout temps.

D’ordre général, le stockage de données est dispendieux. Le stockage de pétaoctets de données sur de longues périodes est une proposition quasi abyssale. Ainsi, jusqu’à récemment, les serveurs de R6S ne stockaient tout simplement pas toutes les données. À la place, les serveurs recueillaient plutôt les journaux dits «exploitables» (c’est-à-dire ceux qui pourraient mener à une action directe, par exemple les erreurs ou avertissements saisis par le système), ainsi qu’un échantillon aléatoire du restant des journaux d’événements bruts, «au cas où». Il s’agissait de suffisamment de données pour permettre aux équipes de détecter les attaques DDoS, les tricheurs, les pertes de performance, les bogues, ainsi que d’autres événements qui donnent un aperçu de l’état des serveurs et de la qualité de jeu.

Il ne s’agissait pas, toutefois, de suffisamment de données pour résoudre les aléatoires problèmes répertoriés sur le web. Le résultat: un dév étudiant une capture d’écran ou une vidéo devait non seulement passer beaucoup de temps à tout simplement identifier le serveur hébergeant le match en question, mais il y avait fort à parier que les données dont le dév avait besoin n’avaient pas été stockées.

Par ailleurs, les journaux n’étaient conservés que quelques jours — l’enquêteur devait donc agir rapidement. Ce n’est pas rien quand l’enquête repose sur une capture d’écran anonyme et sans date.

Le rêve en dév: la facilité

«Je peux vous dire d’expérience que d’avoir une chance sur n’importe quoi de trouver le journal d’événement de jeu dont tu as besoin, c’est très frustrant, dit Egginton. C’est bien mieux de pouvoir garantir d’avance que les journaux existeront quand quelqu’un ira à leur recherche. »

Alors essentiellement, je me suis posé la question: pourquoi ne peut-on pas tout avoir, tout le temps? demande-t-il tout naturellement. Pour commencer, on doit conserver les données de manière efficace, parce que c’est coûteux.

Après un an de R et D, l’équipe a conçu un système à deux niveaux pour conserver des pétaoctets de données, lequel se base sur l’importance ou la pertinence des données.

Le gros des données — c’est-à-dire les journaux bruts, ou chaque ligne de code de chaque match saisi par chaque serveur — est maintenant envoyé à une solution de stockage infonuagique de données peu coûteuse à long terme (Stockage Blob). Ces journaux utilisent le format de données JSON qui est rapide à produire, hautement compressible et facilement interrogeable.

Ensuite, un sous-ensemble de ces données brutes est dirigé à une base de données Elasticsearch, une solution de stockage à haute performance.

«Nous dirigeons les informations généralisées, les erreurs et les avertissements, ce genre de chose, à l’Elasticsearch afin de pouvoir garder l’œil sur les serveurs de jeu et d’assurer leur bon fonctionnement, dit Egginton. En même temps, nous produisons des métadonnées dans un autre répertoire de l’Elasticsearch. Nous utilisons l’Elasticsearch beaucoup plus efficacement maintenant; nous ne sauvegardons plus des données juste au cas où, ce qui réduit considérablement les coûts.»

Les journaux de métadonnées mentionnés par Egginton incluent des renseignements tels que le centre de données, l’identifiant de session, l’identifiant de joueur, ainsi que l’emplacement des données pertinentes dans le Stockage Blob. L’équipe a soigneusement réfléchi aux catégories nécessaires dans le raffinement des données brutes des journaux afin d’assurer des paramètres de recherche optimaux.

Trouver l’aiguille dans la botte de foin, en un seul clic

Au final, la stratégie est plutôt simple : les données de référence et les données critiques sont envoyées à l’Elasticsearch pour les recherches et les visualisations en temps réel, tandis que les données brutes sont envoyées à un stockage peu dispendieux (stockage à froid) et réinsérées sur demande dans l’Elasticsearch (stockage à chaud) avec un simple clic.

Concrètement, ça veut dire qu’un dév qui examine un problème utilise Kibana pour effectuer une recherche de l’index de métadonnées de l’Elasticsearch, utilisant par exemple un paramètre tel que les identifiants des joueurs. La recherche génère l’emplacement du journal d’événements de serveur de jeu, lequel est cliquable et active un service de récupération de données.

Et voilà, avec ce seul clic, les données brutes sont recouvertes et injectées dans l’Elasticsearch, permettant une véritable enquête du problème.

Par le passé, un dév devait effectuer sa recherche via Kibana, puis partir à la recherche des journaux dans Azure — les doigts bien croisés que les journaux avaient, en effet, été conservés dans un des échantillons aléatoires—, puis télécharger le journal et le visionner dans un éditeur de texte…

«Maintenant, c’est simplement un outil, juste Kibana, conclut Egginton. Nous avons une manière très efficace d’enquêter sur un problème et de récupérer les données brutes si on en a besoin.»

Axés sur le résultat: l’expérience du joueur

Ainsi, après un an d’efforts de recherche et d’expérimentation considérables, l’équipe réseau de R6S a réduit un problème kafkaïen à un clic unique: «Notre vision, c’était de donner aux dévs un accès facile à chaque journal et chaque métrique générés par chaque serveur de jeu», dit Egginton.

Le nouveau système, avec son paramétrage optimisé des journaux d’événements de jeu et sa solution en un clic, a été vérifié avec succès sur des serveurs live en début mars 2021, et a été activé lors du lancement de la nouvelle saison de Rainbow Six Siege le 16 mars 2021.

Imagine— avant, tu devais envoyer les journaux à des bases de données dispendieuses au cas où tu en aurais besoin, mais tu ne les utilisais essentiellement pas, dit Egginton. Maintenant, la vision globale est qu’il devrait être tout aussi facile d’enquêter sur quelque chose qui est arrivé il y a trois mois durant un match ou il y a quelques secondes en dév.

Cette nouvelle manière de judicieusement sélectionner les données qui sont envoyées à un stockage plus dispendieux (l’Elasticsearch) versus le stockage moins coûteux (Stockage Blob) pourrait mener à des épargnes de dizaines de milliers de dollars par mois pour R6S, ce qui est remarquable. Mais Egginton, lui, pense déjà aux bogues que les dévs pourront enfin étudier, repérer et résoudre.

«On s’assure tout simplement que nous avons toutes les données de jeu dont nous avons besoin pour enquêter sur n’importe quel problème, dit-il. Nous espérons que la prod sera en mesure d’exploiter cette solution pour accroître notre capacité d’enquêter et régler les problèmes actifs afin d’assurer que les joueurs peuvent s’amuser.»

Retour en arrière à l’enjeu de départ

Qu’est-il donc advenu du problème d’enregistrement des impacts décrit en début d’article?

En utilisant quelques indices de la vidéo — les noms des joueurs qui sont visibles, ainsi que la carte dans laquelle ils jouent —, l’équipe de prod a repéré les serveurs de jeu hébergeant le match. À partir de là, elle a accédé aux journaux et fait une analyse de la situation.

Dans ce cas particulier, il s’avère que le problème n’était pas, en fait, l’enregistrement des impacts. Plutôt, le joueur subissait un décalage important, mais ne recevait pas les signes et rétroactions du jeu qui le lui auraient indiqué. C’est un tout autre problème.

«Les membres de notre communauté nous disent ce que nous devons étudier,» dit Egginton. Et les dévs de R6S ont maintenant encore plus de temps et de ressources pour résoudre ces problèmes grâce à un outil à un seul clic.

Avez-vous un bogue à rapporter à l’équipe Rainbow Six Siege? Vous pouvez évidemment le publier sur YouTube, mais assurez-vous d’aussi le rapporter sur R6fix, la plateforme R6S où les membres de la communauté soumettent leurs rapports de bogue directement au Jira de l’équipe de prod. Les joueurs ont une visibilité du statut de leurs soumissions, ainsi que des renseignements sur les dernières mises à jour et corrections.