Chez Edgegap, nous nous concentrons sur la simplification de l’utilisation d’infrastructures distribuées pour les développeurs. Notre plateforme, basée sur la conteneurisation et les microservices, automatise le déploiement et la gestion des serveurs de jeu sur une infrastructure hautement distribuée afin que les studios de jeux puissent se concentrer sur ce qui compte pour leur jeu et leurs joueurs.

Nous rencontrons parfois des studios de jeux qui comparent ce que nous faisons au projet Agones. Cependant, nous avons constaté que pour certains cas d’usage, Agones n’était pas idéal, et que les coûts pour l’exécuter et le gérer peuvent rapidement devenir prohibitifs.

Kubernetes se dirige-t-il vers les services managés ?

Il y a dix ans, chaque entreprise hébergeait et gérait ses propres serveurs de messagerie. Microsoft vendait des licences pour son serveur de messagerie sur site, Microsoft Exchange, comme des petits pains. Aujourd’hui ? La plupart des PME utilisent un serveur de messagerie managé. Microsoft ne publie pas la répartition entre Office 365 et les licences Exchange auto-hébergées, mais elles sont directement corrélées en sens inverse. D’ici quelques années, on dira probablement la même chose de Kubernetes et des services construits dessus.

Agones n’est-il qu’un logiciel simple ?

Qu’implique réellement l’exécution d’Agones ?

En apparence, Agones ressemble à un rêve pour la plupart des développeurs de jeux multijoueurs. C’est un logiciel de gestion de flotte open source construit sur Kubernetes pour gérer et faire évoluer les serveurs de jeu à la demande.

Cependant, les équipes de développement peuvent constater que la réalité opérationnelle est plus exigeante que prévu. Exécuter Agones est à la fois difficile et chronophage, même pour des équipes expérimentées. Cela nécessite une compréhension approfondie de la technologie elle-même ainsi que l’expertise appropriée pour maintenir et gérer correctement le cluster. C’est particulièrement vrai pour les clusters hautement distribués, qui peuvent être encore plus complexes. À mesure que le nombre de régions et de pays augmente, la complexité de la gestion du déploiement et de la configuration du cluster augmente également, ce qui peut rendre difficile de garantir que tous les composants du cluster sont correctement configurés et fonctionnent ensemble.

Étant un projet open source, le coût du logiciel Agones lui-même est généralement gratuit, ce qui semble excellent. Cependant, vous réaliserez rapidement que les coûts et les ressources nécessaires pour le mettre en place et le gérer peuvent devenir substantiels.

Installer et gérer Agones nécessite une bonne compréhension de Kubernetes (K8), des systèmes d’exploitation Linux et une maîtrise d’un langage de programmation comme Python ou Go. En outre, les ingénieurs doivent avoir de l’expérience avec des technologies de conteneurisation comme Docker et containerD et être familiers avec le réseau, la sécurité et l’automatisation. Enfin, votre équipe doit posséder un savoir-faire sur les technologies cloud ou le matériel sur site. C’est probablement pour cela que les ingénieurs DevOps de la Bay Area gagnaient, en moyenne, 200 k USD par an fin 2022.

Le coût de l’infrastructure sous-jacente dépendra de l’endroit où vous choisissez d’héberger votre ou vos clusters Kubernetes. Par exemple, supposons que vous l’hébergiez sur votre propre matériel. Dans ce cas, le coût inclura le prix des serveurs physiques, l’électricité et les autres ressources nécessaires à leur fonctionnement, ainsi que l’assurance du bâtiment, des ingénieurs et tout ce qui va avec. Si vous l’hébergez chez un fournisseur cloud, le coût correspondra au prix des machines virtuelles et de tout autre service utilisé, comme le stockage et le réseau. Les factures d’infrastructure cloud peuvent rapidement gonfler sur des postes comme les IP publiques, le trafic réseau, les équilibreurs de charge, le stockage, les appels API et les frais de support -- et la vision globale est souvent plus difficile à lire qu’elle ne devrait l’être. Nous avons créé notre calculateur de tarification spécifiquement pour donner aux studios une vision plus claire de ce que coûte réellement l’hébergement et l’orchestration de serveurs de jeu.

En plus des coûts d’infrastructure et de logiciel, il peut y avoir des coûts associés aux outils ou services supplémentaires que vous utilisez avec Kubernetes. Par exemple, vous pouvez devoir payer pour un équilibreur de charge, des services de supervision et de journalisation, ou une plateforme d’intégration et de déploiement continus (CI/CD). Les coûts spécifiques dépendront des outils et services que vous choisissez.

Il est facile de supposer qu’une machine virtuelle à faible coût sera suffisante pour exécuter ce logiciel open source, mais le coût total de l’infrastructure est généralement bien plus élevé.

Cap sur les services managés

Comme la transition depuis les serveurs Exchange il y a quelques années, les services managés ont commencé à remplacer l’auto-hébergement. L’utilisation d’un service Kubernetes entièrement managé offre de nombreux avantages. Pour commencer, cela vous enlève le fardeau de la gestion et de la maintenance du cluster. Cela peut faire gagner un temps et des efforts considérables à votre équipe, lui permettant de se concentrer sur des tâches plus importantes.

De plus, un service entièrement managé peut offrir un accès à un support expert et à des conseils. Cela peut être particulièrement utile pour les organisations nouvelles sur Kubernetes ou incertaines de la meilleure façon d’utiliser cette technologie. Avec un service managé, vous pouvez obtenir de l’aide et des recommandations de professionnels expérimentés qui comprennent profondément la technologie et peuvent fournir des analyses et des orientations précieuses.

Un autre avantage de l’utilisation d’un service Kubernetes entièrement managé est la capacité à monter en charge rapidement et facilement. Une fois que votre organisation grandit et que vos charges de travail deviennent plus complexes, un service managé peut fournir la flexibilité et l’évolutivité dont vous avez besoin pour suivre le rythme. C’est particulièrement important pour les clusters hautement distribués, qui peuvent être difficiles à gérer et à faire évoluer de manière autonome. Votre objectif est de créer un jeu formidable et à succès, plutôt que de gérer la plomberie sous-jacente qui sert votre jeu aux joueurs.

Globalement, l’utilisation d’un service Agones/Kubernetes entièrement managé peut apporter de nombreux avantages, notamment un gain de temps et d’effort, l’accès à un support expert et la capacité à évoluer rapidement et facilement.

La vraie question est : avez-vous vraiment besoin d’Agones au départ ?

Kubernetes a été initialement conçu pour des technologies web. Elles gèrent des milliers de connexions sans état, servant de petites requêtes pendant une fraction de seconde. Les serveurs de jeu sont à l’opposé de cette philosophie. Les serveurs de jeu et les relais sont stateful, gérant des connexions persistantes pendant 5 à 45 minutes.

L’industrie du jeu est habituée à configurer autant de serveurs que possible et à les garder « en attente » pour que les joueurs puissent s’y connecter. AWS Gamelift a été un précurseur de cette architecture. Avec cette architecture en tête, Agones est une CRD permettant de tels serveurs en attente dans Kubernetes. Cependant, disposer d’instances en attente est inutile et apporte peu de valeur étant donné que Kubernetes n’est pas censé gérer de telles applications stateful au départ.

Depuis son lancement en 2018, Agones a eu du mal à trouver une adéquation claire : la complexité peut être prohibitive pour les petites équipes sans ressources d’ingénierie dédiées importantes, tandis que les grandes équipes ont souvent besoin de capacités hautement distribuées pour lesquelles il n’a pas été conçu.

Prenez le meilleur de l’architecture d’Agones, laissez le mauvais de côté (ou à quelqu’un d’autre)

Agones prend en entrée, de votre part en tant que développeur de jeu, une image de conteneur. Pour ceux qui ne le savent pas, les conteneurs sont une technologie populaire pour déployer et exécuter des applications de manière légère et portable. Ils offrent plusieurs avantages par rapport aux machines virtuelles et aux serveurs bare metal, notamment une efficacité accrue, la portabilité et la flexibilité.

L’un des principaux avantages des conteneurs est qu’ils sont plus efficaces que les machines virtuelles ou les serveurs bare metal. Les conteneurs partagent le système d’exploitation hôte, alors que chaque machine virtuelle s’exécute sur son système d’exploitation invité, ce qui peut être gourmand en ressources. En partageant le système d’exploitation hôte, les conteneurs peuvent utiliser moins de ressources et offrir de meilleures performances que les machines virtuelles.

Un autre avantage des conteneurs est leur portabilité. Contrairement aux machines virtuelles, qui sont liées à un hyperviseur spécifique et à un système d’exploitation hôte, les conteneurs peuvent être déplacés facilement entre différents environnements et plateformes. Cela facilite le déploiement et l’exécution de vos applications sur d’autres infrastructures, qu’elles soient sur site, dans le cloud ou dans une configuration hybride.

En plus d’une efficacité et d’une portabilité accrues, les conteneurs offrent également une plus grande flexibilité. Avec les conteneurs, vous pouvez facilement empaqueter et déployer votre jeu et ses dépendances comme une seule unité, ce qui facilite la mise à jour et la maintenance de vos applications. Cela peut être particulièrement utile pour les architectures microservices, où les applications sont décomposées en composants plus petits et indépendants.

Le temps de démarrage lent des serveurs avec Agones

Le défi final d’Agones est sa capacité à démarrer rapidement les serveurs de jeu pour répondre à l’expérience attendue par les joueurs.

Comme l’ont souligné des tests en conditions réelles sur PUBG, JungHun Kim, Team Lead DevOps chez KRAFTON, a présenté que le temps global de démarrage des serveurs d’Agones lors de la montée en charge peut être de 10 à 15 minutes entre l’approvisionnement des instances (1-3 minutes), l’amorçage des instances (2-3 minutes) et l’approvisionnement des pods (5-10 minutes), sans ajouter l’intégration de Karpenter, comme présenté à l’AWS re:Invent 2024 :

Cela signifie que les joueurs qui attendent qu’un serveur de jeu soit déployé 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 ne peut pas être déployé et que les joueurs en file d’attente se frustrent et arrêtent complètement de jouer à votre jeu multijoueur -- selon le Online Latency Report d’Edgegap, 34 % abandonneront votre jeu dans ces conditions.

Pendant ce temps, grâce à son approche de co-tenance hautement optimisée, la plateforme d’Edgegap offre des temps de démarrage de serveurs de jeu à froid de 3 secondes en moyenne (au moment de la rédaction), selon Philip Cote, CTO chez Edgegap.

Vélocité vs. faire soi-même

Un nombre croissant de fournisseurs proposent des environnements SaaS permettant aux développeurs de jeux d’héberger et de gérer le cycle de vie de leurs jeux sans la surcharge liée à l’exécution directe d’Agones et de Kubernetes. L’industrie du jeu a une longue tradition de construction d’infrastructures sur mesure, et Agones reflète cet instinct -- même si la tendance des services managés est en train de changer la donne. Le principal moteur de la gestion interne d’Agones est souvent une préférence pour le contrôle et la personnalisation, mais cela s’accompagne d’une surcharge significative que les studios doivent soigneusement mettre en balance avec la vélocité de développement. Les compromis -- en coût, en temps et en expérience joueur -- retombent finalement sur le studio et ses joueurs.