P2P, relais et instances de conteneurs : une analyse approfondie des ressources de développement, des performances et des problèmes de sécurité pour les jeux multijoueurs

Ce qui suit est la transcription de la présentation de Michal Buras au Live Service Game Summit (2024.09.10).

Le takeaway prévu est une meilleure compréhension des différentes technologies réseau disponibles ainsi que des avantages et des défis de différentes infrastructures de jeux. Plus particulièrement, le pair à pair comme technologie et ses défis, notamment la migration d'hôte, et comment cela impacte vos ressources de développement.


Principaux enseignements

1. Qu'est-ce que le réseau pair à pair dans l'infrastructure des jeux multijoueurs

  • Le P2P est souvent perçu comme simple, où les joueurs se connectent en utilisant l'adresse IP publique de l'hôte, mais des défis surgissent en raison de la traduction d'adresse réseau (NAT), rendant la communication directe plus complexe.

  • Dans le réseau pair à pair (P2P), les joueurs se connectent directement les uns aux autres via un "serveur d'écoute" hébergé sur la machine d'un joueur.

  • Ce type de circulation "serveur d'écoute" est bloqué par la plupart des fournisseurs car il est sujet à abus. Ainsi, l'alternative est un serveur "STUN", souvent appelé "Relais".

  1. Avantages et inconvénients des relais dans l'infrastructure des jeux multijoueurs

Avantages

  • Les serveurs relais gèrent la traversée NAT, permettant aux joueurs de se connecter sans partager leurs adresses IP privées.

  • Certaines services de relais, comme Epic Online Services (EOS), proposent des relais gratuits sans coûts initiaux ni de maintenance, simplifiant le développement initial.

Inconvénients

  • Les serveurs relais introduisent une latence supplémentaire, car les paquets doivent passer par un nœud supplémentaire, impactant négativement l'expérience des joueurs.

  • Un contrôle limité sur le routage des joueurs peut mener à des connexions à forte latence si les joueurs sont dirigés vers des relais éloignés.

  • Des préoccupations de sécurité, comme l'exposition des données des joueurs à travers des lobbies dans certaines implémentations.

  1. Le coût caché des relais : migration d'hôte

Migration d'hôte: Si le joueur hôte part, la session de jeu se termine pour tous les joueurs, nécessitant que le jeu change le rôle d'hébergement à un autre joueur en milieu de partie.

Pourquoi c'est coûteux

  • Implémenter la migration d'hôte implique de remodeler de nombreuses fonctionnalités du jeu, nécessitant un temps et des ressources de développeur significatifs.

  • Les studios de jeux peuvent avoir besoin de personnel supplémentaire juste pour gérer la complexité accrue, entraînant des coûts d'environ 15 000 $ par mois.

  • La migration d'hôte aggrave également l'expérience utilisateur, car elle n'est pas transparente et cause souvent des interruptions dans le gameplay.

4. Pourquoi les serveurs autoritaires avec orchestration sont l'infrastructure idéale pour les jeux commerciaux

Serveurs autoritaires: Ces serveurs dédiés contrôlent tous les aspects du jeu, garantissant un jeu équitable en éliminant la dépendance à la machine d'un seul joueur.

Avantages:

  • Résout des problèmes comme la migration d'hôte et la mauvaise expérience des joueurs en cas de déconnexion soudaine de l'hôte, garantissant un environnement stable et contrôlé.

  • Les serveurs autoritaires offrent une meilleure performance et sécurité, réduisant les risques d'exposition des données des joueurs et minimisant les problèmes de latence.

  • Orchestration : Utiliser un service comme l'infrastructure de serveur conteneurisé d'Edgegap permet une allocation de serveurs en temps réel, évolutive, qui s'ajuste au trafic des joueurs, réduisant les coûts en ne payant que pour le temps de serveur actif.

Présentation - Transcription complète

Introductions

Bonjour à tous,

Je suis Michal et aujourd'hui je voulais vous montrer le parcours que nous avons suivi pour créer une solution multijoueur parfaite pour Six Days in Fallujah, en particulier notre analyse des solutions pair à pair et comment gérer la migration d'hôte. De plus, nous allons parler de l'hébergement de jeux sur serveur dédié.

Le takeaway que vous aurez, espérons-le, est une meilleure compréhension des différentes technologies disponibles et des avantages ainsi que des défis de différentes infrastructures de jeux.

En décomposant, nous examinerons le pair à pair comme technologie et ses défis, en particulier la migration d'hôte, et comment cela impacte vos ressources de développement.

Ensuite, nous examinerons différentes options d'infrastructure d'hébergement de serveurs dédiés, y compris les serveurs bare metal, les machines virtuelles de calcul et les instances de conteneur.

À propos du conférencier

Mais d'abord, un peu sur moi. Je suis Michal Buras, Lead Networking / Online Engineering pour Six Days in Fallujah. Le jeu a eu un lancement très réussi et nous continuons à le développer dans le temps.

Personnellement, j'ai été dans le développement de jeux pendant six ans, dix ans dans le développement de logiciels. J'ai commencé dans la réalité virtuelle pour l'industrie initialement, mais pas pour les jeux et je voulais faire des jeux. Alors, j'ai rejoint le [Groupe de jeux multijoueurs] (MPG), où j'ai fait un travail fascinant sur le réseau parmi d'autres choses. Et après cela, j'ai travaillé comme généraliste pour Breach Studios, mais je voulais vraiment faire du réseau, alors j'ai rejoint Highwire Games.

Objectif de la présentation

Pourquoi suis-je ici, n'est-ce pas ?

Après le lancement initial, on m'a demandé à mon équipe d'ajouter la migration d'hôte à Six Days, car c'est essentiel pour notre expérience et pour que le jeu reste en ligne. Ce que j'ai réalisé, c'est qu'il y avait un manque d'informations et d'analyses [disponibles] entre les différentes technologies, à savoir pair à pair contre l'hébergement dédié.

De plus, par curiosité, je voulais évaluer si le [réseau] pair à pair était vraiment la solution rentable que nous continuons à dire dans le développement de jeux.

Enfin, j'espère que cette exploration aidera à informer les autres et à faire croître les connaissances disponibles pour la communauté des développeurs de jeux dans son ensemble.

Le réseau pair à pair dans les jeux multijoueurs - Les bases

Je réalise que tout le monde dans la salle n'est peut-être pas ingénieur, alors voici un aperçu rapide des bases du pair à pair et comment connecter les joueurs via le réseau.

Le pair à pair, comme on dit, est censé être super simple. Le jeu crée un serveur d'écoute et avec l'IP publique, vous connectez tous les joueurs au serveur. Et malheureusement, la vérité n'est pas aussi simple qu'elle en a l'air car votre IP publique n'est pas votre propre IP publique.

Cela signifie que l'adresse IP est partagée. Votre fournisseur Internet regroupe plusieurs utilisateurs sous une seule IP avec un processus appelé traduction d'adresse réseau.

La seule différence est le numéro de port qui vous est temporairement assigné lorsque vous demandez une page Web ou une autre ressource. Pour les non-ingénieurs, pensez à l'IP du serveur comme à un bloc d'appartements. Cependant, comme il y a plusieurs appartements dans chaque immeuble. Chaque fois que vous commandez une pizza, on vous donne un numéro d'appartement unique, et le numéro change avec le temps.

Et cela entraîne beaucoup de confusion.

Nous devons trouver un mécanisme pour obtenir le numéro assigné et partager cette information d'une manière ou d'une autre avec d'autres joueurs.

Réseau pair à pair - Serveurs STUN

Cette solution s'appelle un serveur STUN. Pensez-y comme aux Pages Jaunes. Si vous voulez que les gens puissent trouver votre entreprise, vous devez mettre à jour les Pages Jaunes avec votre numéro actuel.

Malheureusement, cette solution n'est pas sécurisée, car notre numéro d'appartement pourrait être partagé davantage, et quiconque sur Internet pourrait nous envoyer n'importe quoi. La plupart des fournisseurs de services jugent cela non sécurisé et bloquent ce type de circulation.

Réseau pair à pair - Serveurs relais

L'alternative, la seule alternative que nous avons, ce sont les serveurs relais. Votre adresse privée n'est partagée avec personne sauf le serveur qui relaye l'information entre vous et l'autre joueur.

Il y a presque des serveurs sans calcul, mais comme ils nécessitent une certaine puissance de calcul, vous devrez les héberger, ce qui signifie que vous avez besoin d'un fournisseur de services.

Il existe beaucoup de services disponibles qui fournissent des solutions de serveurs relais que nous avons évaluées, mais pour cette présentation, je ne parlerai que de trois que je trouve les plus intéressants.

Relais : Epic Online Service - Aperçu

Tout d'abord, Epic Online Services (EOS) donne des relais gratuits, ce qui signifie zéro coût initial et zéro coût de maintenance.

Cette solution nécessite le moins de développement, ils sont multiplateformes, ont un système de lobby, et la seule chose qui vous manque pour un jeu complet est un système de matchmaking.

Cependant, vous n'avez absolument aucun contrôle sur la façon dont ces joueurs sont routés.

Un serveur relais ajoute un nœud supplémentaire à votre paquet de jeu qu'il doit traverser, ce qui introduit de la latence. Compte tenu du nombre limité de relais, le joueur pourrait être dirigé vers des relais éloignés en fonction de la disponibilité à ce moment-là. Cette forte latence est inacceptable dans un jeu commercial, car elle entraîne une mauvaise expérience de jeu pour le joueur et, par conséquent, une augmentation de l'abandon. Cela entraîne directement des joueurs frustrés sur Discord et une perte de revenus.

Relais : Epic Online Service - Vulnérabilités

Les services en ligne d'Epic peuvent également être vulnérables.

Ceci est un exemple d'un des titres AAA de Steam. Nous avons ici un groupe de joueurs dans le lobby, et ils peuvent échanger des informations qui sont traitées par WebSocket. Lorsque vous créez un jeu en pair à pair, vous rassemblez généralement des informations pertinentes sur le joueur hébergeant le jeu, c'est-à-dire sur son PC, n'est-ce pas ?

En utilisant une simple application appelée Fiddler, vous pouvez accéder à cette base d'informations du lobby et exposer toutes les autres informations privées des joueurs en texte clair. Et cette application prend littéralement deux clics à installer et peut être utilisée par un enfant de dix ans. Donc, quelqu'un pourrait en gros gratter les données [de votre] base de données, n'est-ce pas ?

Et c'est un risque énorme pour un jeu commercial à supporter. Donc, faites attention à ce que vous implémentez en utilisant le système de lobby.

Relais : WebRTC

[Une] alternative de solution pair à pair que j'ai trouvée intéressante est les relais WebRTC. J'ai découvert cette option d'infrastructure grâce à la présentation approfondie d'Outriders de People Can Fly, qui a eu lieu il y a quelques années.

En résumé, c'est une bonne implémentation parce qu'ils réutilisent les serveurs relais, mais ils ont dû modifier beaucoup le code d'Unreal pour y faire face. De plus, ils ont dû héberger les relais eux-mêmes. C'est une infrastructure personnalisée que vous devez construire, tester, optimiser et maintenir, ce qui signifie des coûts mensuels qui auraient pu être dépensés ailleurs.

Cependant, il n'est pas clair s'ils sont vraiment meilleurs en termes de performance par rapport aux relais d'EOS.

Relais : Serveurs auto-développés / auto-hébergés

Ce qui m'amène aux serveurs relais auto-développés. Et dans un des projets, l'idée était que nous pouvions créer un serveur relais dans Unreal Engine qui sérialiserait des paquets, peut-être les analyserait pour prévenir la tricherie. Et cela n'avait pas de sens au niveau conceptuel à cause de la latence et du coût computationnel supplémentaire.

Si vous calculez, ce n'est plus un serveur relais. Cela devient une forme de serveur dédié. Donc, ma recommandation, si vous voulez votre propre technologie de relais, c'est juste de prendre un proxy de GitHub, modifier pour qu'il soit configuré en temps réel. Vous n'avez pas besoin de mettre en œuvre de répétition de paquets, d'ordonnancement, etc., car votre gestionnaire de jeu devrait gérer cela.

Mais si vous prenez un moment de recul en ce moment et pensez à tout cela. À ce stade, vous ne créez pas un jeu, vous construisez une infrastructure. Brûler de l'argent sur des choses qui n'aident pas votre jeu à se développer avec du contenu, de meilleures technologies ou des fonctionnalités.

Quel est l'intérêt ?

Migration d'hôte & Impact sur les défis des relais

Maintenant, tous ces services ont un défi fondamental.

Vous avez besoin d'un mécanisme appelé migration d'hôte, car si le joueur qui héberge le jeu quitte, tout le monde est déconnecté.

C'est un problème fondamental que vous devez résoudre car il tue littéralement la session de jeu d'un bout à l'autre. Un énorme problème pour tout jeu commercial où le multijoueur est essentiel.

Nous avons eu un énorme problème dans Six Days avec des gens qui quittaient simplement le jeu au hasard parce que notre jeu est un jeu difficile. Vous avez une chance, un kill, n'est-ce pas ? Et ils ne sont peut-être pas conscients d'être hôte ou peut-être qu'ils ne se soucient pas d'être hôte. Donc, c'était un briseur de fête.

[Dans] Six Days, j'ai implémenté une migration d'hôte de base en utilisant uniquement le pilote de réseau d'Unreal Engine et cela fonctionne bien dans sa forme très basique. Je ne veux pas entrer trop dans les détails ici puisque cela s'adresse aux geeks d'Unreal, donc vous pouvez me poser des questions en privé après, si vous êtes curieux.

Mais tout le projet nécessitait un refactor complet afin que toutes les fonctionnalités le supportent. Maintenant, chaque petite fonctionnalité, chaque blueprint conçu par un designer devait être retravaillé, et il n'existe pas de solution miracle pour implémenter la migration d'hôte, à moins que votre moteur ne le supporte nativement, mais cela viendra avec un coût en bande passante réseau.

Il y avait trop de risques en gestion de projet pour trop peu de bénéfices par rapport à d'autres alternatives.

Le takeaway étant que, bien que le coût initial des relais ait été faible, la solution de migration d'hôte que vous devez construire devient extrêmement coûteuse. Pas si bon marché après tout.

Toute cette enquête sur les différentes technologies et services nous a amenés à réaliser que la solution "pas chère" qui était le pair à pair, nécessitait de construire un système entier appelé migration d'hôte, qui ne serait pas une résolution transparente et une mauvaise expérience utilisateur, puis nous devrons la maintenir.

Donc soit vous embauchez du personnel supplémentaire, soit vous déplacez votre date de sortie de projet. Dans les deux cas, vous brûlez de l'argent. Tout cela parce que vous augmentez la complexité de littéralement chaque partie du jeu. Notre évaluation est que nous aurions besoin d'un testeur supplémentaire et d'un développeur qui seraient purement assignés à retravailler toutes les fonctionnalités pour progresser.

Cela nous coûterait mensuellement environ 15 000 $. Et cela ne fera qu'augmenter plus tard. Et je veux que vous vous souveniez de cette question, que pouvons-nous obtenir d'autre pour 15K ? Que pouvons-nous obtenir d'autre pour ces ressources de développement ?

Serveurs dédiés - Infrastructure & Répartition des coûts

La prochaine étape était d'évaluer d'autres options, à savoir les serveurs dédiés. Comparons chaque option et faisons une répartition des coûts.

Avant d'aller plus loin, jetons un coup d'œil à ce graphique. Sur le côté gauche, vous pouvez voir les sessions de jeu de Six Days dans le temps. Ce sont des données historiques réelles sur une période de 24 heures.

Comment lire ceci. Par exemple, le tracé rouge est l'Amérique du Nord Est et à l'UTC zéro a un pic de trente-trois jeux. Cela signifie qu'il y a trente-trois serveurs de Six Days fonctionnant en parallèle.

Comme notre jeu nécessite deux vCPUs ou threads logiques, cette région pour se maintenir nécessiterait soixante-six CPU logiques. Sur le côté droit, vous avez un coût mensuel de cette distribution de jeu. Et cela ne serait que pour une région. Donc, multiplions cela plusieurs fois. Et voyons combien de jeux nous pourrions avoir sur le graphique si nous devions échanger les ressources de développement pour l'infrastructure.

Et le budget supposé était de 15K.

Cloud public (AWS)

Tout d'abord le plus évident, tout le monde va vers AWS.

Voyons ce que nous pouvons obtenir sur le cloud public le plus reconnaissable. J'ai calculé le coût du pic pour chaque région séparément afin de rendre cela aussi précis que possible.

[Six Days a] une génération de cartes procédurales et une IA très sophistiquée, notre jeu nécessite un peu plus de puissance, mais il y a tout de même 2 200 sessions de jeu quotidiennes. Ce n'est pas mal, non ? Et si notre jeu était comme Valorant ou Counter Strike, il y aurait presque 10K sessions de joueurs.

Serveurs bare metal

Le bon vieux bare metal.

Je sais que certains d'entre vous pourraient dire que le bare metal a de meilleures performances et pourrait accueillir 20 pour cent de plus. Dans le cas de Six Days, mon ordinateur portable de jeu ne peut pas exécuter le serveur sur un seul thread logique, donc le calcul reste malheureusement le même.

Peut-être quelque chose de plus simple, comme Valorant, pourrait atteindre 8K comme Amazon.

Quoi qu'il en soit, dans notre cas, ce n'était pas les options. Je dois également noter qu'il pourrait y avoir des options flexibles de bare metal là-bas, où vous pourriez accueillir un peu plus de joueurs, mais je ne pourrais pas les mentionner dans cette présentation.

Instances de conteneurs - Aperçu

Alors j'ai commencé à rechercher des instances de conteneurs, car je me demandais s'il y avait eu des progrès dans la technologie des serveurs de jeux conteneurisés, et j'ai trouvé ces gars-là.

Comme les instances de conteneurs sont entièrement gérées, elles ne nécessitent aucun coût d'ingénierie, je télécharge juste l'image du jeu, je ne me soucie pas des régions, des surcoûts ou de toute configuration que j'ai dû faire avec d'autres technologies d'infrastructure.

C'est ainsi que j'ai découvert Edgegap. Nous avons été les premiers à le développer de manière à ce qu'il soit utilisable pour les jeux multijoueurs.

Instances de conteneurs - Mise en cache d'image

Toutes les entreprises comme Azure, parce que comment suis-je arrivé aux instances de conteneurs ? Je ne suis pas arrivé de nulle part.

La première fois que je faisais de l'infrastructure pour une entreprise de VR, je cherchais d'autres options que le cloud computing évolutif. J'ai trouvé des instances de conteneurs dans Azure, mais elles étaient super, super lentes à déployer.

Parce qu'elles ne font pas de mise en cache d'image, ce qu'Edgegap fait.

J'étais très heureux de trouver que quelqu'un avait enfin implémenté la chose manquante pour les instances de conteneurs. Cela nous permet de gérer deux fois plus que sur le cloud public avec le même budget. Et encore une fois, si ce jeu était comme Valorant, 15K USD couvriraient leur budget mensuel pour l'infrastructure serveur pour héberger tout le jeu.

Instances de conteneurs - Orchestration distribuée

Une autre chose intéressante à noter ici est qu'avec les conteneurs, nous ne sommes pas liés à un centre de données spécifique.

Par exemple, nous pouvons héberger un jeu quotidien pour notre ami à Cape Town sans gérer un cluster Kubernetes local qui serait inutilisé le reste du temps. Cela rend notre jeu plus inclusif.

Habituellement, lorsque vous créez un jeu, vous allez pour le fruit le plus facile en termes de régions de jeu, n'est-ce pas ? Mais si vous ajoutez tous ces petits endroits où les gens sont incapables de jouer à cause de la haute latence vers le centre de données, ces petites baies deviennent un vrai bon repas.

Comme il y a beaucoup de discussions ici sur la monétisation des jeux, vous pouvez penser à cela comme une opportunité d'ouvrir de nouveaux marchés qui étaient auparavant inaccessibles.

Cloud public - Capacité gaspillée vs Instances de conteneurs

Pourquoi ces instances de conteneurs sont-elles si bonnes ?

Regardons ce graphique que j'ai fait. La ligne verte est des données réelles de joueurs non moyennées. Comme vous pouvez le voir, elle a des pics, des fluctuations, très difficiles à prédire.

Lorsque nous utilisons des solutions de cloud public, nous devons conserver un surcoût d'anciens serveurs de jeu inutilisés pour accommoder ces joueurs et toute déviation potentielle.

Voilà pourquoi l'augmentation et la diminution de la piscine de serveurs disponible est très lente. Donc, dans le cloud public, toute la zone en dessous de la ligne rouge est ce que vous payez, et la zone en dessous de la ligne verte est ce que vous devriez payer. L'espace en rouge est l'endroit où l'argent s'échappe.

Maintenant, cela est seulement pour une région qui s'élève et se multiplie par le nombre de régions que vous avez.

Les instances de conteneurs résolvent ces problèmes car elles se déploient super vite grâce à la mise en cache d'image que j'ai mentionnée précédemment. Il n'y a pas de délai pour démarrer ou éteindre, de cette manière nous pouvons nous ajuster précisément à la demande en temps réel.

Par conséquent, la ligne bleue s'aligne presque parfaitement avec le trafic des joueurs, et vous finissez par ne payer que pour ce que vous utilisez.

Comparaison finale

Tout cela me ramène à la dernière diapositive de notre présentation, sur comment nous avons géré l'infrastructure réseau dans Six Days. Nous avons constaté que lorsque vous jouez dans une partie privée avec votre ami, le pair à pair sans migration d'hôte est suffisant, et cela représente 40 pour cent de notre trafic.

Conclusion

Quand j'étais enfant, beaucoup de jeux étaient en pair à pair comme Counter Strike. Et il y avait, nous étions des serveurs d'écoute en pair à pair. Et nous n'avions jamais de problèmes avec l'hôte qui partait, car nous nous connaissions, et nous ne voulions pas briser le plaisir. À moins, bien sûr, que maman ne soit entrée dans la pièce et nous ait dit d'arrêter de jouer et de faire nos devoirs, car jouer à des jeux ne vous donnera pas un diplôme en sciences.

Maman avait en partie raison. Mais pour les jeux avec matchmaking avec des personnes aléatoires, le mode pair à pair était un super désastre. Surtout pour un jeu difficile comme le nôtre.

Donc, nous avons des serveurs dédiés sur Edgegap pour les jeux qui sont assortis afin que votre expérience de joueur ne soit pas basée sur un type aléatoire qui quitte rageusement le jeu.

Donc, je vous recommande de tout cœur d'utiliser Edgegap avec votre jeu si vous voulez vraiment de la qualité ainsi que de la quantité.

C'est tout. Merci de votre temps et n'hésitez pas à m'ajouter sur LinkedIn. Merci, les gars !

Sources et/ou collaboration de contenu avec

Michal Buras, Ingénieur Réseaux Principal chez Highwire Games