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

La présentation a été effectuée en 2024 par JungHun Kim, alors DevOps Team Lead chez KRAFTON, aux côtés de Minsuk Kim et Minwook Chun. Elle met en lumière leur parcours de plusieurs années pour transformer l'infrastructure de PUBG: Battlegrounds, passant d'anciens serveurs basés sur EC2 à un écosystème Kubernetes entièrement conteneurisé.

Leur expérience offre des perspectives précieuses pour les développeurs de jeux, bien qu'elle révèle également les complexités et les coûts souvent sous-estimés de l'autogestion d'une infrastructure aussi sophistiquée.

De l'architecture existante à la conteneurisation moderne

PUBG: Battlegrounds, l'un des trois jeux les plus joués sur Steam en termes de joueurs simultanés à l'époque, fonctionnait sur une architecture à deux composants.

Le salon 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 différentes régions du monde.

JungHun Kim, DevOps Team Lead chez KRAFTON, a expliqué leur défi initial : le « flux de création d'environnement d'assurance qualité (QA) » nécessitait de 20 minutes à une heure pour que les équipes DevOps provisionnent de nouveaux environnements de test. Ce goulot d'étranglement a gravement affecté la vitesse de développement et la productivité de l'équipe.

Le parcours de modernisation a débuté en novembre 2018 avec les serveurs de session, s'est poursuivi avec les serveurs de salon en octobre 2019, et a culminé avec l'utilisation de serveurs à processeurs ARM en juin 2023. Chaque phase a répondu à des difficultés spécifiques tout en introduisant de nouvelles complexités.

La première avancée majeure de KRAFTON est née du constat 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 a consisté à 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 de l'environnement QA de 20-60 minutes à moins de 5 minutes. Les équipes ont obtenu des capacités de libre-service via une interface utilisateur Web accessible aux concepteurs, développeurs, ingénieurs QA et chefs de produit.

Migration en production et complexité du maillage de services (Service Mesh)

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

Les systèmes de production nécessitent l'absence totale de purge de base de données, des stratégies de migration fluide et des plans de retour arrière complets. L'équipe a mis en place des mécanismes sophistiqués de découverte de services à l'aide de clusters pour synchroniser les adresses IP, les noms de services et les données de localisation.

Cependant, des problèmes d'équilibrage de trafic sont apparus lors de la migration. Le multiplexage de connexions a créé une répartition inégale de la charge entre les services, contraignant l'équipe à adopter le maillage de services 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 salon 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 monter en charge jusqu'à des centaines de milliers de sessions simultanées tout en maintenant des temps de réponse constants et une rentabilité financière.

Ils ont évalué Agones, une plateforme open-source d'orchestration de serveurs de jeux multijoueurs basée sur Kubernetes. Agones gère les serveurs de jeu comme des 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 des capacités. L'architecture a permis un bin-packing sophistiqué sur des clusters Kubernetes partagés, plusieurs environnements coexistant au sein du même cluster grâce aux espaces de noms (namespaces).

Bien que KRAFTON ait obtenu des résultats techniques impressionnants, Agones souffrait d'un problème majeur selon JungHun Kim : un temps d'initialisation (bootstrapping) du serveur de 15 minutes, devenu un goulet d'étranglement lors des montées en charge. L'analyse détaillée de ce délai a révélé plusieurs retards cumulés : le provisionnement de l'instance (1-3 minutes), l'initialisation de l'instance (2-3 minutes) et le provisionnement du pod (5-10 minutes). Ces retards ont créé des difficultés lors des pics d'utilisation, lorsque les joueurs avaient besoin d'une disponibilité immédiate des serveurs.

Les solutions de KRAFTON ont nécessité des investissements substantiels en ingénierie. Ils ont adopté Karpenter pour réduire les délais de lancement d'EC2 et ont mis en place un proxy de registre de conteneurs avec Harbor, la mise en cache S3 et la distribution CloudFront. Ces optimisations ont réduit l'initialisation 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'autogestion

Les accomplissements techniques et le succès de KRAFTON étaient évidents. Pour un studio qui n'a pas l'envergure de KRAFTON, la question du coût et de la complexité se pose.

La gestion de Karpenter en tant que solution open-source a nécessité une expertise dédiée qui peut manquer à d'autres studios. L'équipe de KRAFTON avait besoin de connaissances spécialisées dans plusieurs domaines : réseau Kubernetes, configuration du maillage de services Istio, gestion des serveurs de jeu, optimisation du registre de conteneurs et systèmes de compilation multi-architectures.

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

Ce parcours d'infrastructure a nécessité des années d'efforts d'ingénierie spécialisée. Cela représente un coût d'opportunité significatif que les studios doivent soupeser attentivement par rapport aux priorités de leur propre feuille de route.

Une voie plus simple pour aller de l'avant ?

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 jeu d'Edgegap. De son côté, le temps médian de déploiement de serveur d'Edgegap est de 2 secondes à partir d'un démarrage à froid : provisionné à partir de zéro plutôt qu'alloué sur un serveur déjà en cours d'exécution, et mesuré jusqu'à ce que le conteneur soit prêt, avant le démarrage du moteur de jeu (données de la plateforme, en date de septembre 2026). C'est un tout autre ordre de grandeur par rapport aux délais d'initialisation de 15 minutes rencontrés par KRAFTON avec son implémentation d'Agones.

Cela signifie que les joueurs en attente du déploiement d'un serveur de jeu doivent patienter dans une file d'attente pendant que la ressource actuelle est recyclée. Plus concrètement, cela implique qu'un serveur de jeu ne peut pas être déployé immédiatement et que les joueurs en file d'attente se lassent et cessent définitivement de jouer à votre jeu multijoueur, 34 % d'entre eux risquant d'abandonner votre jeu d'après le rapport Online Latency.

La plateforme d'Edgegap s'adapte automatiquement jusqu'à 14 millions d'utilisateurs simultanés en 60 minutes, dépassant largement les exigences de la plupart des jeux. Plus important encore, elle élimine le besoin d'équipes DevOps dédiées pour gérer Kubernetes, les registres de conteneurs, les maillages de services 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 de l'infrastructure, tout en bénéficiant des avantages de performance et d'échelle que KRAFTON a mis des années à mettre en œuvre pour obtenir 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, tant pour les composants de salon que pour les sessions. Contrairement aux réseaux peer-to-peer, les serveurs dédiés assurent 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 serveur dédié Unreal Engine, chacune prenant en charge une partie à 100 joueurs. Ces serveurs avec état gèrent toute la logique de jeu, les calculs physiques et les interactions entre joueurs sans dépendre d'un stockage persistant entre les parties. Les serveurs de salon utilisent des microservices .NET sans état connectés à des backends de stockage gérés, ce qui permet une mise à l'échelle horizontale et une tolérance aux pannes.

Où se trouvent les serveurs de 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 salon se concentrent dans « us-east-1 », faisant office 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 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 ainsi l'expérience compétitive dans un jeu où chaque milliseconde compte. La stratégie de répartition géographique équilibre la rentabilité financière avec les exigences de performance tout en conservant des opérations de salon centralisées.

Le modèle de tarification régionale d'AWS oblige les développeurs à acheter des emplacements individuellement pour assurer une couverture mondiale.

Les développeurs de jeux à la recherche d'une solution moderne peuvent plutôt utiliser la plateforme d'orchestration d'Edgegap, qui s'appuie sur le premier et le plus vaste réseau sans région au monde. Cela permet à votre jeu multijoueur de déployer ses serveurs de jeu sur plus de 615 emplacements dans le monde à un prix unique, permettant à 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 doivent évaluer avec soin si la mise en place et la gestion d'une infrastructure complexe basée sur Kubernetes s'alignent avec leurs compétences clés et leurs ressources disponibles.

KRAFTON a obtenu des résultats impressionnants, mais son parcours de plusieurs années a nécessité des efforts d'ingénierie considérables, comme ils l'ont souligné dans la présentation. La question est de savoir si des studios plus petits peuvent se permettre de se détourner du développement de leur jeu de base. Bien que ce soit un choix envisageable pour certains, d'autres studios peuvent manquer de ressources considérables et de l'expertise DevOps dédiée nécessaires pour concevoir et maintenir une infrastructure Kubernetes complexe.

Des plateformes entièrement gérées comme Edgegap offrent les mêmes avantages en matière de performances (mise à l'échelle instantanée, distribution mondiale et faible latence) sans nécessiter d'équipes d'infrastructure spécialisées ni d'années de travail d'implémentation. Les studios peuvent atteindre des capacités d'infrastructure du niveau de KRAFTON grâce à une intégration simplifiée fournie par des plateformes comme Edgegap, tout en permettant à leurs talentueux développeurs de se concentrer 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.