Dans cet article, nous aborderons les informations clés applicables à tous les développeurs de jeux multijoueurs en ce qui concerne la migration de l'architecture de Player Unknown de Battlegrounds, basée sur le lobby vers l'orchestration de serveurs de jeux basés sur des conteneurs.

La présentation a été réalisée en 2024 par JinHun Kim, alors responsable de l'équipe DevOps chez KRAFTON, aux côtés de Minsuk Kim et Minwook Chun. Elle met en lumière leur parcours pluriannuel transformant l'infrastructure de PUBG: Battlegrounds des serveurs traditionnels basés sur EC2 à un écosystème Kubernetes entièrement conteneurisé.

Leur expérience offre des informations précieuses aux développeurs de jeux, bien que cela révèle également les complexités et les coûts cachés de l'auto-gestion d'une telle infrastructure sophistiquée.

De l'Architecture Héritée à la Conteneurisation Moderne

PUBG: Battlegrounds, l'un des trois jeux les plus populaires de Steam à l'époque, fonctionnait sur une architecture à deux composants.

Le lobby sert de point d'entrée pour le matchmaking, les opérations en boutique et la personnalisation. Ensuite, les serveurs de session géraient le gameplay principal de bataille royale à 100 joueurs à travers des régions distribuées dans le monde entier.

JungHun Kim, chef de l'équipe DevOps chez KRAFTON, a expliqué leur défi initial : le "workflow de création d'environnements QA" nécessitait de 20 minutes à une heure pour les équipes DevOps afin de provisionner de nouveaux environnements de test. Ce goulot d'étranglement a gravement impacté la rapidité du développement et la productivité de l'équipe.

Le parcours de modernisation a commencé en novembre 2018 avec les serveurs de session, suivi des serveurs de lobby en octobre 2019, et s'est terminé par l'utilisation de serveurs à processeur ARM en juin 2023. Chaque étape a résolu des problèmes spécifiques tout en introduisant de nouvelles complexités.

La première percée de KRAFTON est survenue lorsqu'ils ont reconnu que les environnements QA traditionnels basés sur EC2 étaient gourmands en ressources et difficiles à partager. Chaque environnement nécessitait de nombreux services AWS : instances EC2, CodeDeploy, CloudFront, Elastic Load Balancing, DynamoDB, ElastiCache, OpenSearch, Kinesis, Data Firehose, SQS, VPC, Auto Scaling, Route 53, IAM et S3.

La solution consistait à containeriser ces services dans Amazon EKS, créant des catégories de ressources partagées et dédiées. Ce changement architectural a réduit le temps de création des environnements QA de 20-60 minutes à moins de 5 minutes. Les équipes ont gagné des capacités d'auto-service à travers une interface web accessible aux concepteurs, développeurs, ingénieurs QA et chefs de produit.

Migration en Production et Complexité du Réseau de Services

Le déplacement des charges de travail en production s'est avéré bien plus complexe que celui des environnements QA.

Les systèmes de production nécessitent une vidange zéro de base de données, des stratégies de migration progressive, et des plans de retour complètes. L'équipe a mis en place des mécanismes sophistiqués de découverte de services utilisant des clusters pour synchroniser les adresses IP, les noms de services et les données de localisation.

Cependant, des problèmes de répartition de trafic sont apparus lors de la migration. La mise en commun des connexions a créé une distribution inégale de la charge sur les services, forçant l'équipe à adopter le réseau de services Istio pour la gestion dynamique du trafic, la sécurité renforcée et l'amélioration de l'observabilité.

Orchestration des Serveurs de Session: Agones et ses Limitations

Les serveurs de session ont présenté des défis uniques par rapport aux services de lobby sans état. Chaque serveur de session exécute des serveurs dédiés Unreal Engine, maintenant l'état du jeu sans stockage persistant. KRAFTON devait s'adapter à des centaines de milliers de sessions simultanées tout en maintenant des temps de réponse cohérents et une efficacité des coûts.

Ils ont évalué Agones, une plateforme open-source d'orchestration de serveurs de jeux multijoueurs construite sur Kubernetes. Agones gère les serveurs de jeux comme les déploiements Kubernetes, avec un pod GameServer par instance de jeu. Les flottes gèrent des groupes de GameServers, tandis que les FleetAutoscalers s'occupent de la gestion de la capacité. L'architecture a permis un emballage sophistiqué des bins à travers des clusters Kubernetes partagés avec plusieurs environnements coexistant dans le même cluster en utilisant des espaces de noms.

Bien que KRAFTON ait atteint des résultats techniques impressionnants, Agones souffrit d'un défaut critique selon JungHun Kim : un délai de démarrage des serveurs de 15 minutes qui est devenu un goulot d'étranglement lors des événements de mise à l'échelle. La décomposition de la chronologie a révélé plusieurs délais de couplage : le provisionnement des instances (1-3 minutes), le démarrage des instances (2-3 minutes) et le provisionnement des pods (5-10 minutes). Ces retards ont créé des défis de mise à l'échelle pendant les périodes de pointe lorsque les joueurs avaient besoin d'une disponibilité immédiate des serveurs.

Les solutions de KRAFTON ont nécessité un investissement substantiel en ingénierie. Ils ont adopté Karpenter pour réduire les délais de lancement d'EC2 et mis en place un proxy de registre de conteneurs avec Harbor, un cache S3 et une distribution CloudFront. Ces optimisations ont réduit le démarrage de plus de 15 minutes à 3-4 minutes, mais ont exigé une expertise approfondie de Kubernetes et une maintenance continue que la plupart des studios ne peuvent pas supporter.

Les Coûts Cachés de l'Auto-Gestion

Les réalisations techniques de KRAFTON ont entraîné des coûts et des complexités considérables.

Gérer Karpenter en tant que solution open-source a nécessité une expertise dédiée que la plupart des studios n'ont pas. L'équipe avait besoin de connaissances spécialisées dans plusieurs domaines : la mise en réseau Kubernetes, la configuration du réseau de services Istio, la gestion des serveurs de jeux, l'optimisation des registres de conteneurs et les systèmes de construction multi-architectures.

Ces optimisations exigent une expertise approfondie de Kubernetes et une maintenance continue. L'équipe DevOps dédiée de KRAFTON pouvait gérer cette complexité, mais les petits studios font face à des contraintes de ressources importantes. Peu de studios peuvent consacrer suffisamment de ressources pour maîtriser ces technologies tout en maintenant le focus sur le développement de jeux.

Le parcours d'infrastructure a consommé des années d'efforts en ingénierie qui auraient pu être dirigés vers des améliorations de gameplay, de nouvelles fonctionnalités, ou du contenu supplémentaire. Cela représente un coût d'opportunité significatif pour les studios de développement de jeux.

Une Voie Plus Simple à Suivre

Plutôt que de reproduire le parcours d'infrastructure complexe de KRAFTON, les développeurs de jeux devraient envisager des solutions entièrement gérées comme la plateforme d'orchestration de serveurs de jeux d'Edgegap. Grâce à son approche de cohabitation hautement optimisée, tous les jeux utilisant la plateforme Edgegap garantissent un temps de démarrage de serveur de jeu à froid de 3 secondes en moyenne, selon Philip Cote, CTO de Edgegap, éliminant les délais de 15 minutes qui ont tourmenté l'implémentation d'Agones de KRAFTON.

Cela signifie que les joueurs attendant qu'un serveur de jeu soit déployé doivent attendre dans une file d'attente pendant que la ressource actuelle est recyclée. Plus concrètement, cela signifie qu'un serveur de jeu n'est pas capable d'être déployé et que les joueurs attendant dans la file d'attente se frustrent et cessent de jouer à votre jeu multijoueur complètement, car 34% se détourneront de votre jeu selon le rapport de Latence en Ligne.

La plateforme s'adapte automatiquement à 14 millions d'utilisateurs simultanés en 60 minutes, dépassant de loin les exigences de la plupart des jeux. Le plus important, c'est qu'elle élimine le besoin d'équipes DevOps dédiées pour gérer Kubernetes, les registres de conteneurs, les réseaux de services et les algorithmes de mise à l'échelle.

Les studios peuvent concentrer leurs ressources d'ingénierie sur le développement de jeux plutôt que sur la gestion de l'infrastructure, tout en réalisant les performances et les avantages d'échelle que KRAFTON a mis des années à mettre en œuvre.

PUBG A-t-il des Serveurs Dédicés ?

Oui, PUBG: Battlegrounds fonctionne entièrement sur des serveurs dédiés pour les composants de lobby et de session. Contrairement au réseau peer-to-peer, les serveurs dédiés fournissent une gestion d'état de jeu autoritaire, des capacités antitriche et des performances cohérentes indépendamment des connexions de chaque joueur.

Les serveurs de session exécutent les instances de serveur dédié Unreal Engine, chacun gérant un match à 100 joueurs. Ces serveurs avec état gèrent toute la logique du jeu, les calculs physiques et les interactions des joueurs sans se fier au stockage persistant entre les parties. Les serveurs de lobby utilisent des microservices stateless .NET connectés à des backends de stockage gérés, permettant une mise à l'échelle horizontale et une tolérance aux pannes.

Où Sont Situés les Serveurs de PUBG ?

PUBG exploite une infrastructure serveur distribuée mondialement avec des serveurs de session déployés à travers plusieurs régions AWS. Les services de lobby se concentrent dans us-east-1, servant de hub central pour la gestion des utilisateurs et les opérations de matchmaking.

Les serveurs de session se déploient dynamiquement en fonction de la demande des joueurs et de la distribution géographique. Cette approche minimise la latence en plaçant les serveurs de jeu plus près des populations de joueurs, améliorant ainsi l'expérience compétitive dans un jeu où les millisecondes comptent. La stratégie de distribution géographique équilibre l'efficacité des coûts avec les exigences de performance tout en maintenant des opérations de lobby centralisées.

AWS demande toujours aux développeurs de jeux d'acheter des emplacements individuellement pour assurer une couverture globale. Les développeurs de jeux ayant besoin d'une solution moderne peuvent plutôt utiliser la plateforme d'orchestration Edgegap, qui s'appuie sur le plus grand réseau sans région du monde. Cela permet à votre multijoueur de déployer leur serveur de jeu dans les 615+ emplacements mondiaux à un prix unique, ce qui permet à Edgegap de réduire la latence de 58% en moyenne et offre une latence inférieure à 50 ms à 78% de la base de joueurs du jeu.

Conclusion

Les développeurs de jeux devraient évaluer soigneusement si la construction et la gestion d'une infrastructure complexe basée sur Kubernetes correspondent à leurs compétences de base et à leur disponibilité en ressources.

KRAFTON a obtenu des résultats impressionnants, mais leur parcours pluriannuel a consommé d'importants efforts d'ingénierie que les petits studios ne peuvent pas se permettre de détourner du développement principal des jeux. La plupart des studios de jeux manquent des ressources étendues de KRAFTON et de l'expertise DevOps dédiée nécessaire pour construire et maintenir une infrastructure Kubernetes complexe.

Les plateformes entièrement gérées comme Edgegap offrent les mêmes avantages en termes de performance—mise à l'échelle instantanée, distribution mondiale, et faible latence—sans nécessiter d'équipes d'infrastructure spécialisées ou des années de travail de mise en œuvre. Les studios peuvent atteindre des capacités d'infrastructure de niveau KRAFTON grâce à une intégration simple tout en concentrant leurs développeurs talentueux sur la création d'expériences de jeu exceptionnelles plutôt que sur la gestion de systèmes d'orchestration de conteneurs.

---

Cet article est basé sur et cite l'article original de KRAFTON publié ici. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.