Dans cet article, nous couvrirons les principales conclusions qui s'appliquent à tous les développeurs de jeux multijoueurs concernant la migration de Player Unknown's: Battlegrounds d'une architecture basée sur le lobby à une orchestration de serveur de jeu basée sur des conteneurs.

La présentation a été présentée en 2024 par JinHun Kim, alors chef d'é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' d'anciens serveurs basés sur EC2 à un écosystème Kubernetes entièrement conteneurisé.

Leur expérience offre des insights précieux pour les développeurs de jeux, bien qu'elle révèle également les complexités cachées et les coûts de l'auto-gestion d'une infrastructure aussi sophistiquée.

De l'architecture héritée à la conteneurisation moderne

PUBG: Battlegrounds, un des trois principaux jeux sur Steam par le nombre de joueurs actuels à l'époque, fonctionnait sur une architecture à deux composants.

Le lobby sert de point d'entrée pour le matchmaking, les opérations de magasin et la personnalisation. Ensuite, les serveurs de session géraient le gameplay de battle royale à 100 joueurs répartis dans le monde entier.

JungHun Kim, chef d'équipe DevOps chez KRAFTON, a expliqué leur défi initial : le "workflow de création d'environnement QA" nécessitait de 20 minutes à une heure pour que les équipes DevOps puissent fournir de nouveaux environnements de test. Ce goulot d'étranglement impactait gravement 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, suivi des serveurs de lobby en octobre 2019, et s'est culminé avec l'utilisation de serveurs sur processeurs ARM en juin 2023. Chaque phase a abordé des problèmes 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, 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 en self-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

Déplacer les charges de travail en production s'est avéré bien plus complexe que les environnements QA.

Les systèmes de production nécessitent l'absence de vidage de la base de données, des stratégies de migration en douceur et des plans de retour arrière complets. L'équipe a mis en œuvre des mécanismes de découverte de services sophistiqués utilisant des 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. La mise en commun des connexions a créé une répartition inégale de la charge entre les services, obligeant l'équipe à adopter le service mesh Istio pour une gestion dynamique du trafic, une sécurité accrue et une meilleure observabilité.

Orchestration des serveurs de session : Agones et ses limitations

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, maintenant l'état du jeu sans stockage persistant. KRAFTON devait évoluer vers des centaines de milliers de sessions simultanées tout en maintenant des temps de réponse cohérents et une efficacité économique.

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 gèrent la capacité. L'architecture a permis un bin-packing sophistiqué à travers des clusters Kubernetes partagés avec plusieurs environnements coexistant au sein du même cluster à l'aide de namespaces.

Bien que KRAFTON ait atteint des résultats techniques impressionnants, Agones a souffert d'un défaut critique selon JungHun Kim : un temps de démarrage de serveur de 15 minutes qui est devenu un goulot d'étranglement lors des événements d'évolution. L'analyse du calendrier a révélé plusieurs retards en chaîne : provisionnement des instances (1-3 minutes), démarrage des instances (2-3 minutes), et 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 de serveurs disponibles immédiatement.

Les solutions de KRAFTON nécessitaient un investissement substantiel en ingénierie. Ils ont adopté Karpenter pour réduire les délais de lancement EC2 et ont mis en œuvre 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 demandé une expertise Kubernetes approfondie et une maintenance continue que la plupart des studios ne peuvent pas soutenir.

Les coûts cachés de l'auto-gestion

Les réalisations techniques de KRAFTON ont été obtenues au prix de coûts et de complexité considérables.

Gérer Karpenter comme une solution open source nécessitait 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 : mise en réseau Kubernetes, configuration de service mesh Istio, gestion de serveurs de jeu, optimisation de registres de conteneurs et systèmes de construction multi-architectures.

Ces optimisations exigent une expertise Kubernetes approfondie 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 significatives. Peu de studios peuvent consacrer suffisamment de ressources pour maîtriser ces technologies tout en maintenant leur concentration sur le développement de jeux.

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

Un chemin plus simple

Plutôt que de reproduire le parcours complexe d'infrastructure 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. Grâce à son approche de co-location hautement optimisée, tous les jeux utilisant la plateforme d'Edgegap garantissent un temps de démarrage du serveur de jeu à partir d'un démarrage à froid de 3 secondes en moyenne selon Philip Cote, CTO chez Edgegap, éliminant les retards de 15 minutes qui ont affecté la mise en œuvre Agones de KRAFTON.

Cela signifie que les joueurs en attente d'un déploiement de serveur de jeu doivent patienter dans une file d'attente pendant que la ressource actuelle est recyclée. Plus concrètement, cela signifie qu'un serveur de jeu n'a pas la possibilité d'être déployé et que les joueurs en attente dans la file d'attente se frustrent et cessent de jouer à votre jeu multijoueur complètement, car 34 % abandonneront votre jeu selon le rapport sur la latence en ligne.

La plateforme s'adapte automatiquement à 14 millions d'utilisateurs simultanés en 60 minutes, dépassant de loin les besoins de la plupart des jeux. Plus important encore, elle supprime le besoin d'équipes DevOps dédiées pour gérer Kubernetes, les registres de conteneurs, les services mesh et les algorithmes de mise à l'échelle.

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

PUBG dispose-t-il de serveurs dédié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 offrent 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 gérant un match de 100 joueurs. Ces serveurs avec état gèrent toute la logique de jeu, les calculs physiques, et les interactions des joueurs sans compter sur un stockage persistant entre les matchs. Les serveurs de lobby utilisent des microservices .NET sans état connectés à des solutions de stockage géré, permettant une mise à l'échelle horizontale et une tolérance aux pannes.

Où sont situés les serveurs PUBG ?

PUBG opère une infrastructure de serveurs distribuée mondialement avec des serveurs de session déployés à travers plusieurs régions AWS. Les services de lobby se concentrent sur us-east-1, servant de plaque tournante centrale 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 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 exige toujours que les développeurs de jeux achètent des emplacements individuellement pour garantir 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 exploite le réseau sans région le plus vaste et le premier mondial. Cela signifie que votre jeu multijoueur peut déployer son serveur de jeu à tous les plus de 615 emplacements dans le monde à 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 attentivement si construire et gérer une infrastructure complexe basée sur Kubernetes s'aligne avec leurs compétences de base et leur disponibilité en ressources.

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

Les plateformes entièrement gérées comme Edgegap offrent les mêmes avantages de performance—scalabilité instantanée, distribution mondiale, et faible latence—sans nécessiter d'équipes d'infrastructure spécialisées ou des années de travail d'implémentation. 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 sont détenus par leurs propriétaires respectifs.