À partir de novembre 2024, Amazon Web Service (AWS) GameLift prend désormais en charge des conteneurs entièrement gérés, ce que beaucoup dans l’industrie, y compris Edgegap, signalaient comme une lacune de la plateforme depuis plusieurs années. Cela permet enfin aux développeurs d’utiliser des conteneurs, tels que ceux de Docker, pour déployer leur serveur de jeu sur l’orchestration de GameLift afin d’héberger et de faire évoluer des serveurs de jeux multijoueurs.

Décomposons cela et, plus important encore, demandons-nous si l’ajout de conteneurs suffit à véritablement améliorer l’orchestration des jeux multijoueurs et l’expérience de jeu en ligne des joueurs.

Que sont les conteneurs AWS GameLift pour les jeux multijoueurs

En utilisant Amazon Elastic Container Service (ECS) intégré à l’orchestration de GameLift, les développeurs de jeux peuvent gérer les charges de joueurs fluctuantes et rationaliser le déploiement.

Cette configuration permet aux développeurs de personnaliser les environnements d’hébergement de jeu, d’automatiser la mise à l’échelle et de gérer des exigences réseau complexes essentielles aux jeux multijoueurs.

GameLift améliore également l’appariement des joueurs et la gestion des sessions, en fournissant des outils pour optimiser l’expérience des joueurs. Avec cette architecture de service basée sur des conteneurs, les développeurs gagnent en flexibilité opérationnelle, se concentrant davantage sur le gameplay et moins sur l’infrastructure.

Ce qu’il faut examiner de près avec les conteneurs ECS sur GameLift pour les jeux multijoueurs

AWS GameLift prend en charge les conteneurs, mais pour les studios de jeux qui cherchent à réduire les coûts d’hébergement et à maximiser l’expérience des joueurs, plusieurs aspects de la configuration méritent un examen plus attentif, notamment l’allocation, la mise à l’échelle, la distribution par régions, l’appariement et la complexité d’intégration.

Allocation

L’allocation fait référence à l’espace occupé par les serveurs de jeu sur la machine virtuelle (VM). Bien qu’AWS documente l’allocation de vCPU et de mémoire par groupe de conteneurs, l’effort d’intégration important requis de la part des studios de jeux signifie qu’il peut encore être difficile d’optimiser le « remplissage » de votre serveur de jeu pour les machines virtuelles et de maximiser votre utilisation par vCPU en pratique.

Cette complexité signifie que les studios peuvent finir par payer pour une capacité inutilisée, en plus du coût DevOps supplémentaire lié à la gestion du backfilling.

L’architecture de GameLift exige également le préchauffage des machines virtuelles afin que les conteneurs soient prêts à être lancés, ce qui signifie qu’une partie de la capacité de flotte doit être maintenue en réserve comme tampon en permanence. Régler ce tampon trop bas risque d’entraîner des retards prolongés de montée en charge qui affectent directement l’expérience des joueurs. À noter : le tampon par défaut de GameLift est fixé à 10 %, ce qui est généralement inférieur à ce dont les studios ont besoin en production, en particulier pour les jeux avec une demande de joueurs variable ou en pics. La plupart des studios devront augmenter cette valeur, ce qui accroît le coût effectif d’exploitation de leur flotte. Vous pouvez utiliser le calculateur d’Edgegap pour comparer la façon dont les choix de capacité tampon affectent les coûts globaux d’hébergement selon différents scénarios de trafic.

Si vos serveurs se retrouvent en surcapacité en raison de tampons mal configurés, les joueurs subiront de la latence et des pertes d’images. Cela sape la valeur fondamentale de l’orchestration de serveurs dédiés.

Chez Edgegap, nous sommes fiers de notre capacité à offrir aux développeurs de jeux la possibilité d’optimiser leur serveur de jeu et de fractionner leur utilisation de vCPU afin de réduire leurs coûts globaux.

Mise à l’échelle

La documentation de GameLift couvre bien la mise à l’échelle des flottes de conteneurs, y compris l’auto-scaling basé sur des cibles via la console ou le SDK. Cependant, plusieurs questions pratiques restent insuffisamment documentées pour les studios cherchant à optimiser le comportement de mise à l’échelle des flottes de conteneurs, en particulier sur la manière dont la mise à l’échelle interagit avec le préchauffage des conteneurs au niveau des instances.

Si les conteneurs sont pré-lancés sur des instances, comment GameLift détermine-t-il quand effectuer une mise à l’échelle puisque les conteneurs consomment déjà les ressources des instances ? Si les conteneurs sont déployés à la volée, quelle est la vitesse réelle en pratique (mise à l’échelle verticale), et comment cela se comporte-t-il simultanément sur plusieurs régions (mise à l’échelle horizontale) ?

Edgegap propose un déploiement de conteneurs à la volée qui garantit jusqu’à 40 déploiements de serveurs de jeu, maintenus pendant 60 minutes. AWS est l’un des fournisseurs d’Edgegap, mais Edgegap utilise également 16 fournisseurs (au moment de la rédaction) pour faire évoluer verticalement votre jeu à l’emplacement nécessaire.

De plus, le serveur « cold start » d’Edgegap est, en moyenne, de 3 secondes, ce qui signifie plus de jeu et moins d’attente pour le déploiement des serveurs de jeu. Il s’agit d’une amélioration significative des temps d’attente des joueurs par rapport aux durées de démarrage à froid couramment rapportées par les développeurs utilisant d’autres plateformes.

Contrairement à AWS, Edgegap déploie votre serveur de jeu dans ses plus de 615 emplacements dans le monde à la demande. S’il est excellent de monter en charge sur AWS-US-East pour les joueurs de la côte est des États-Unis, la réalité est que votre hébergement de jeu doit pouvoir monter et descendre en charge à travers le monde pour offrir une excellente expérience de jeu en ligne aux joueurs du monde entier.

Distribution par régions

Le cloud public, y compris AWS, vous fait payer les machines virtuelles que vous ayez ou non des serveurs de jeu en cours d’exécution. Vous payez pour chaque région dans laquelle vous voulez être présent.

Vous voulez 10 régions, ce qui serait le minimum pour un « jeu AA » ou un « jeu indépendant triple-I » afin de maintenir la latence à un niveau suffisamment bas pour que les joueurs profitent du jeu avec un minimum de plaintes ? Vous devez payer pour 10 x VM C5 large, au minimum.

Cette approche traditionnelle de l’hébergement signifie que même si vous êtes co-locataire sur un serveur que vous payez entièrement, cette structure de coûts peut multiplier considérablement vos dépenses d’hébergement. La page de tarification d’Edgegap fournit une comparaison directe.

Les nouveaux services d’orchestration pour l’hébergement de serveurs de jeu, comme Edgegap, utilisent plutôt le paiement à l’usage. Cela signifie que vous ne payez que lorsque vos joueurs jouent (c’est-à-dire pendant un déploiement) dans le monde entier au même prix à chaque fois. Cela représente un changement significatif par rapport au modèle de tarification à capacité réservée qu’exige l’orchestration cloud public traditionnelle.

De plus, comme Edgegap s’appuie sur le plus grand réseau edge au monde, il est en mesure d’offrir une réduction de latence moyenne de 58 % par rapport à une orchestration cloud public traditionnelle.

Utilisation avec Matchmaking / Lobby

Un autre défi est que votre système de matchmaking ou votre lobby doit choisir le meilleur emplacement. Vous devrez créer des régions dans votre matchmaker, et plus vous chercherez à réduire la latence (en ajoutant des régions dans AWS), plus votre temps de file d’attente de matchmaking sera long, car vous ne pourrez pas faire de matchs inter-régions.

Le matchmaker d’Edgegap est l’un des seuls matchmakers avec des paramètres natifs basés sur la latence par défaut (au moment de la rédaction), ce qui vous aide à déployer des serveurs de jeu avec la latence la plus faible pour vos joueurs.

Facilité d’intégration et d’utilisation

La propre documentation d’intégration d’AWS pour cette configuration s’étend sur plusieurs guides couvrant la configuration d’ECS, ECR, CodeBuild et CloudFormation, ce qui reflète la complexité réelle impliquée dans la mise en place d’une flotte de conteneurs prête pour la production.

Tout configurer est en soi un chantier important, et une fois le travail d’intégration terminé, ce n’est que le début. Vous aurez besoin d’au moins un ingénieur ou professionnel DevOps pour surveiller et gérer les hauts et les bas de votre trafic.

L’avantage des serveurs de jeu « juste à temps », qui chargent des données pour être entièrement personnalisés comme le contenu généré par les utilisateurs (UGC), contourne entièrement cette complexité. Par exemple, Six Days of Fallujah charge sa carte entièrement générée de manière procédurale pendant le déploiement du serveur de jeu, tout comme HIBERWORLD pour ses centaines de milliers de types de jeux et de cartes développés en UGC.

Les conteneurs sont-ils suffisants pour AWS GameLift ?

Pour les jeux utilisant actuellement GameLift qui veulent passer aux conteneurs grâce à leur facilité d’utilisation, cela peut être suffisant pour leur situation.

Si vous voulez une solution plus flexible qui vous permette de tirer parti de centaines d’emplacements en mode juste-à-temps et paiement à l’usage, sans avoir à en gérer vous-même aucun aspect, vous devriez vous tourner vers la nouvelle génération de services d’orchestration de serveurs de jeu, notamment Edgegap.