À partir de ce novembre, Amazon Web Service (AWS) GameLift prend désormais en charge des conteneurs entièrement gérés (un whole 5 ans après que nous avons signalé qu'il en manquait), ce qui 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 mettre à l'échelle des serveurs de jeux multijoueurs.

Décomposons cela, et plus important encore - demandons si l'ajout de conteneurs est suffisant pour améliorer réellement l'orchestration des jeux multijoueurs et l'expérience de jeu en ligne pour ses joueurs.

Quels sont les conteneurs AWS Gamelift pour les jeux multijoueurs

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

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

GameLift améliore également la mise en relation des joueurs et la gestion des sessions, fournissant des outils pour optimiser les expériences 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 que AWS ne dit pas sur les conteneurs ECS sur Gamelift pour les jeux multijoueurs

AWS Gamelift prend en charge les conteneurs, mais il lui manque encore de la transparence dans des domaines critiques pour l'optimisation de l'orchestration des serveurs de jeux qui aident les studios à réduire leurs coûts d'hébergement et à maximiser l'expérience de jeu en ligne - à savoir l'allocation, la mise à l'échelle, la distribution dans les régions, la mise en relation, et la simplicité d'intégration & d'utilisation.

Allocation

Tout d'abord, AWS n'est pas clair sur le fonctionnement de l'allocation dans Gamelift.

L'allocation est la quantité d'espace occupée par les serveurs de jeux sur la machine virtuelle (VM). Au-delà d'être un processus d'intégration douloureux pour les studios de jeux, cela signifie qu'il est difficile d'optimiser le « remplissage » de votre serveur de jeu pour les machines virtuelles afin de maximiser votre utilisation par vCPU.

Ce manque de transparence signifie que les studios paient pour une capacité non utilisée et des coûts supplémentaires de DevOps liés à la gestion de la complétion.

Deuxièmement, vous avez toujours un minimum de 30 % de surcharge car Gamelift doit préchauffer les machines virtuelles, de sorte que le conteneur de flotte puisse démarrer les conteneurs. Bien que vous puissiez configurer une valeur inférieure dans Gamelift, cela entraînera une longue période (lue: une durée qui casse l'expérience des joueurs) pendant la montée en charge où il n'y aura pas assez de capacité.

Faites attention au calculateur de Gamelift ; ils définissent par défaut une surcharge de 10 % que nous n'avons jamais vu atteinte sur le terrain, avec des instances spot qui nécessitent que votre binaire de jeu (et mode de jeu) prennent en charge l'arrêt à quelques minutes d'avis.

Ce qui, concrètement, signifie que si vous n'utilisez pas un serveur suffisamment grand, cela signifie une mauvaise expérience pour le joueur, comme une latence et des images perdues dues à la surcharge du serveur. À ce stade, vous pourriez aussi bien utiliser la mise en réseau pair-à-pair (P2P) à la place.

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

Mise à l'échelle

AWS ne clarifie pas comment fonctionne la mise à l'échelle de ses VM. La principale valeur ajoutée de Gamelift est la capacité de mise à l'échelle des VM à la demande, mais ils ne mentionnent pas comment cela fonctionne pour les conteneurs dans leur documentation. 

S'ils prélancent des conteneurs, alors nous revenons à la question de la mise à l'échelle ; comment savent-ils quand mettre à l'échelle puisque les conteneurs occupent déjà de l'espace sur la machine ?

S'ils déploient des conteneurs à la volée, à quelle vitesse cela se fait-il (mise à l'échelle verticale des serveurs de jeux) et comment cela fonctionne-t-il à travers les régions sélectionnées (mise à l'échelle horizontale) ?

Edgegap fournit un déploiement de conteneurs à la volée qui garantit jusqu'à 40 déploiements de serveurs de jeux, soutenus pendant 60 minutes. AWS est l'un des fournisseurs d'Edgegap, mais elle utilise également 16 fournisseurs (au moment de l'écriture) pour mettre à l'échelle verticalement votre jeu à l'emplacement que vous souhaitez.

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 du serveur de jeu. Une amélioration massive de la qualité de vie pour tout jeu en ligne par rapport aux 10+ secondes rapportées ailleurs.

Contrairement à AWS, Edgegap déploie votre serveur de jeu dans tous ses 615+ emplacements dans le monde à la demande. Bien qu'il soit formidable de mettre à l'échelle dans 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 monter et descendre à travers le monde pour offrir une excellente expérience de jeu en ligne aux joueurs du monde entier.

Distribution dans les régions

Le cloud public, y compris AWS, vous fait payer pour les machines virtuelles (que vous ayez ou non des serveurs de jeux en cours d'exécution), vous devrez payer pour chaque région où vous souhaitez avoir une présence.

Vous souhaitez 10 régions, qui seraient le minimum pour un « AA » ou un « triple-I, jeu indépendant » afin de maintenir une latence à des niveaux suffisamment bas pour que les joueurs apprécient le 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 un co-locataire sur votre serveur que vous payez entièrement, cela peut facilement multiplier vos coûts par 5 à 8 fois.

De nouveaux services d'orchestration pour l'hébergement de serveurs de jeux, comme Edgegap, utilisent plutôt un modèle de paiement à l'utilisation. Ce qui 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. Un véritable changeur de règles en termes de prix.

De plus, alors qu'Edgegap exploite le plus grand réseau de périphérie au monde, il peut fournir une réduction de latence de 58 % en moyenne par rapport à une orchestration de cloud public traditionnel.

Utilisation avec la mise en relation / les lobbys

Un autre défi est que votre système de matchmaking ou votre lobby doit choisir quelle localisation est la meilleure. Vous devrez créer des régions dans votre système de matchmaking, et plus vous essayez de réduire la latence (en ajoutant des régions dans AWS), plus votre temps d'attente de matchmaking sera long car vous ne pourrez pas effectuer de matchs entre régions.

Le système de matchmaking d'Edgegap est le seul système de matchmaking avec des paramètres basés sur la latence par défaut, ce qui vous aide à déployer le serveur de jeu avec la latence la plus basse pour vos joueurs.

Facilité d'intégration et d'utilisation

La définition de simplicité d'AWS est un post de blog à ce sujet qui prend 10 pages pour expliquer comment cela fonctionne.

La dure réalité est qu'il nécessite que vous intégriez et configuriez Gamelift, ce qui est en soi un défi, et un ensemble complet d'ECS qui orchestrera les conteneurs.

Une fois le travail d'intégration terminé, ce n'est que le début - vous aurez besoin d'au moins 1 ingénieur ou DevOps qui surveillera ces derniers et gérera les variations de votre trafic.

De plus, il n'est pas clair si vous pouvez faire des éléments personnalisés par conteneurs, par exemple, comme injecter des variables d'environnement.

L'avantage des serveurs de jeu « juste à temps », qui chargent des données pour être entièrement personnalisées comme le contenu généré par les utilisateurs (UGC), contourne complètement ce problème. 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, ou HIBERWORLD’s des centaines de milliers de types de jeux et cartes développés par UGC.

Les conteneurs sont-ils suffisants pour AWS Gamelift ?

Pour les jeux utilisant actuellement Gamelift, et qui souhaitent passer aux conteneurs grâce à leur facilité d'utilisation, peut-être que c'est suffisant pour la situation.

Malheureusement, si vous souhaitez disposer d'une solution plus flexible qui vous permet de tirer parti de centaines de localisations de manière juste à temps, payez au fur et à mesure (et ne pas avoir à gérer quoi que ce soit), vous devriez probablement envisager la nouvelle génération de services d'orchestration de serveurs de jeux – y compris Edgegap.