Dans cet article, nous couvrirons les principaux enseignements applicables à tous les développeurs de jeux multijoueurs concernant la migration de l’architecture de Player Unknown's: Battlegrounds d’une orchestration de serveurs de jeu basée sur des lobbies à une orchestration basée sur des conteneurs.

La présentation a été présenté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 sur plusieurs années pour transformer l’infrastructure de PUBG: Battlegrounds', passant de serveurs historiques basés sur EC2 à un écosystème Kubernetes entièrement conteneurisé.

Leur expérience offre des enseignements précieux pour les développeurs de jeux, bien qu’elle révèle aussi les complexités et les coûts souvent négligés de l’auto‑gestion d’une infrastructure aussi sophistiquée.

D’une architecture héritée à une conteneurisation moderne

PUBG: Battlegrounds, l’un des trois jeux les plus joués sur Steam au moment des faits, fonctionnait avec une architecture en deux composants.

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

JungHun Kim, responsable 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 que les équipes DevOps provisionnent de nouveaux environnements de test. Ce goulot d’étranglement impactait fortement la vélocité de développement et la productivité des équipes.

Le parcours de modernisation a commencé en novembre 2018 avec les serveurs de session, suivi des serveurs de lobby en octobre 2019, et a culminé avec l’utilisation de serveurs à processeurs basés sur ARM en juin 2023. Chaque phase traitait des points de douleur spécifiques tout en introduisant de nouvelles complexités.

La première percée de KRAFTON est venue de la reconnaissance 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 à conteneuriser ces services au sein d’Amazon EKS, en créant des catégories de ressources partagées et dédiées. Ce changement d’architecture a réduit le temps de création des environnements QA de 20-60 minutes à moins de 5 minutes. Les équipes ont obtenu des capacités en libre‑service via une interface web accessible aux designers, développeurs, ingénieurs QA et chefs de produit.

Migration en production et complexité du service mesh

Le déplacement des charges de travail de production s’est avéré bien plus complexe que pour les environnements QA.

Les systèmes de production exigent l’absence totale de purge de base de données, des stratégies de migration en douceur et des plans de rollback complets. L’équipe a mis en œuvre des mécanismes sophistiqués de découverte de services à l’aide de clusters pour synchroniser les adresses IP, les noms de service et les données de localisation.

Cependant, des problèmes d’équilibrage du trafic sont apparus pendant la migration. Le pool de connexions créait une répartition inégale de la charge entre les services, forçant l’équipe à adopter le service mesh Istio pour une gestion dynamique du trafic, une sécurité renforcée et une meilleure observabilité.

Orchestration des serveurs de session : Agones et ses limites

Les serveurs de session présentaient 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, en maintenant l’état du jeu sans stockage persistant. KRAFTON devait monter en charge jusqu’à des centaines de milliers de sessions simultanées tout en conservant des temps de réponse constants et une bonne 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 jeu comme des déploiements Kubernetes, avec un pod GameServer par instance de jeu. Les Fleets gèrent des groupes de GameServers, tandis que les FleetAutoscalers prennent en charge la gestion de capacité. L’architecture a permis un bin-packing sophistiqué sur des clusters Kubernetes partagés, avec plusieurs environnements coexistant au sein du même cluster via des espaces de noms.

Bien que KRAFTON ait obtenu des résultats techniques impressionnants, Agones souffrait d’un défi majeur selon JungHun Kim : un temps de bootstrap serveur de 15 minutes, devenu un goulot d’étranglement lors des événements de montée en charge. La décomposition de la chronologie a révélé plusieurs délais cumulatifs : provisionnement d’instance (1-3 minutes), bootstrap d’instance (2-3 minutes) et provisionnement de pod (5-10 minutes). Ces délais créaient des difficultés de montée en charge pendant les périodes de pointe, lorsque les joueurs avaient besoin d’une disponibilité immédiate des serveurs.

Les solutions de KRAFTON ont exigé un investissement d’ingénierie considérable. Ils ont adopté Karpenter pour réduire les délais de lancement EC2 et implémenté un proxy de registre de conteneurs avec Harbor, un cache S3 et une distribution CloudFront. Ces optimisations ont réduit le bootstrap de plus de 15 minutes à 3-4 minutes, mais ont exigé une expertise Kubernetes approfondie et une maintenance continue.

Les coûts cachés de l’auto‑gestion

Les réalisations techniques et le succès de KRAFTON étaient évidents. Pour un studio sans l’échelle de KRAFTON, la question du coût et de la complexité se pose.

Gérer Karpenter comme solution open source nécessitait une expertise dédiée dont les studios peuvent manquer. L’équipe KRAFTON avait besoin de connaissances spécialisées dans plusieurs domaines : réseau Kubernetes, configuration du service mesh Istio, gestion des serveurs de jeu, optimisation des registres de conteneurs et systèmes de build multi‑architecture.

Ces optimisations exigent une expertise Kubernetes poussée et une maintenance continue. L’équipe DevOps dédiée de KRAFTON a montré qu’elle pouvait gérer cette complexité et réussir, mais les studios plus petits font face à d’importantes contraintes de ressources. C’est donc une question que les petits studios doivent se poser : peuvent‑ils consacrer suffisamment de ressources à la maîtrise de ces technologies tout en restant concentrés sur le développement du jeu.

Ce parcours d’infrastructure a consommé des années d’efforts d’ingénierie spécialisés. Il s’agit d’un coût d’opportunité significatif que les studios devraient évaluer attentivement au regard de leurs propres priorités de feuille de route.

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 managées comme la plateforme d’orchestration de serveurs de jeu d’Edgegap. Par ailleurs, grâce à son approche de co‑tenance hautement optimisée, tous les jeux utilisant la plateforme d’Edgegap garantissent un temps de démarrage à froid du serveur de jeu de 3 secondes en moyenne, selon Philip Cote, CTO d’Edgegap, éliminant les délais de 15 minutes rencontrés par KRAFTON avec leur implémentation d’Agones.

Cela signifie que les joueurs qui attendent le déploiement d’un serveur de jeu doivent patienter dans une file pendant que la ressource actuelle est recyclée. Plus concrètement, cela signifie qu’un serveur de jeu ne peut pas être déployé immédiatement, et les joueurs en file s’agacent et arrêtent de jouer à votre jeu multijoueur complètement, car 34 % quitteront votre jeu selon le rapport Online Latency.

La plateforme d’Edgegap s’auto‑met à l’échelle jusqu’à 14 millions d’utilisateurs simultanés en 60 minutes, dépassant largement la plupart des besoins des jeux. Surtout, elle supprime la nécessité d’équipes DevOps dédiées pour gérer Kubernetes, les registres de conteneurs, les service meshes et les algorithmes de mise à l’échelle.

Les studios peuvent concentrer leurs ressources d’ingénierie sur le développement du jeu plutôt que sur la gestion d’infrastructure, tout en obtenant les bénéfices de performance et d’échelle que KRAFTON a mis des années à implémenter avec des résultats de haute qualité.

PUBG dispose‑t‑il de serveurs dédiés ?

Oui, PUBG: Battlegrounds fonctionne entièrement sur des serveurs dédiés pour les composants lobby et session. Contrairement au réseau pair à pair, les serveurs dédiés fournissent une gestion autoritaire de l’état du jeu, des capacités anti‑triche et des performances constantes indépendamment des connexions individuelles des joueurs.

Les serveurs de session exécutent des instances de serveurs dédiés Unreal Engine, chacune gérant un match à 100 joueurs. Ces serveurs avec état gèrent toute la logique de jeu, les calculs physiques et les interactions des joueurs sans s’appuyer sur un stockage persistant entre les matchs. Les serveurs de lobby utilisent des microservices .NET sans état connectés à des backends de stockage managés, permettant la mise à l’échelle horizontale et la tolérance aux pannes.

Où sont situés les serveurs PUBG ?

PUBG exploite une infrastructure de serveurs distribuée à l’échelle mondiale, avec des serveurs de session déployés dans plusieurs régions AWS. Les services de lobby sont concentrés 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 leur répartition géographique. Cette approche minimise la latence en plaçant les serveurs de jeu plus près des populations de joueurs, améliorant 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 et les exigences de performance tout en maintenant des opérations de lobby centralisées.

Le modèle de tarification régionale d’AWS signifie que les développeurs doivent acheter les emplacements individuellement pour assurer une couverture mondiale.

Les développeurs de jeux ayant besoin d’une solution moderne peuvent plutôt utiliser la plateforme d’orchestration d’Edgegap, qui s’appuie sur le plus grand et le premier réseau sans région au monde. Cela permet à votre jeu multijoueur de déployer son serveur de jeu dans les 615+ emplacements dans le monde à un prix unique, ce qui permet à Edgegap de réduire la latence de 58 % en moyenne et d’offrir une latence inférieure à 50 ms à 78 % de la base de joueurs du jeu.

Conclusion

Les développeurs de jeux devraient évaluer attentivement si la construction et la gestion d’une infrastructure complexe basée sur Kubernetes correspondent à leurs compétences clés et à la disponibilité de leurs ressources.

KRAFTON a obtenu des résultats impressionnants, mais leur parcours de plusieurs années a mobilisé des efforts d’ingénierie importants comme ils l’ont souligné dans la présentation. La question est de savoir si les petits studios peuvent se permettre de détourner leurs efforts du développement principal du jeu. Un choix valable pour certains, cependant certains studios peuvent manquer des ressources étendues et de l’expertise DevOps dédiée nécessaires pour construire et maintenir une infrastructure Kubernetes complexe.

Les plateformes entièrement managées comme Edgegap offrent les mêmes bénéfices de performance (mise à l’échelle instantanée, distribution mondiale et faible latence) sans nécessiter d’équipes d’infrastructure spécialisées ni des années de travail d’implémentation. Les studios peuvent atteindre des capacités d’infrastructure de niveau KRAFTON via une intégration simplifiée fournie par des plateformes comme Edgegap, 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 l’article original de KRAFTON et le cite, publié ici. Tous les droits du contenu original appartiennent à leurs propriétaires respectifs.