Guide de migration du serveur de jeu dédié

Cet article traite des considérations relatives au déplacement des serveurs de jeux informatiques vers Google Cloud Platform (GCP). Aujourd'hui, la plupart des jeux en ligne comportent des processus de serveur de jeu dédiés qui s'exécutent sur des machines virtuelles ou physiques. Ce guide est destiné aux développeurs de jeux et aux équipes chargées des opérations familiarisés avec l'exécution de processus de serveur de jeux dédiés, sur site ou dans le cloud. Même si la migration des serveurs de jeux vers GCP pose un certain nombre de problèmes, la flexibilité accrue peut offrir des avantages non négligeables, y compris un modèle de facturation avantageux, une infrastructure mondiale de pointe et des technologies cloud dernier cri. Ce guide a pour but de vous aider à démarrer votre migration. L'industrie du jeu vidéo n'a pas de terminologie standard, donc pour les besoins de cet article :

  • Machine fait référence à la machine physique ou virtuelle sur laquelle les processus du serveur de jeu sont exécutés.
  • Serveur de jeu fait référence au processus de serveur de jeu. Plusieurs processus de serveur de jeu peuvent s'exécuter simultanément sur un même ordinateur.
  • L'instance fait référence à un processus unique du serveur de jeu.

Raisons d'exécuter des serveurs de jeux sur GCP

De plus en plus de studios de jeux déplacent leurs serveurs de jeux dédiés vers le cloud pour s'affranchir de la nécessité de faire correspondre leurs achats de matériel avec l'estimation difficile du nombre de joueurs au moment du lancement. La capacité à gérer de manière transparente les pics d'activité et à ne payer que ce que vous utilisez permet d'éliminer un risque important. Parmi ces avantages, on compte :

  • Les VM Google Compute Engine sont facturées à la minute, pas à l'heure. Des remises automatiques sont systématiquement appliquées aux VM que vous continuez à exploiter. Il n'est pas nécessaire de réserver de la capacité et d'assumer les risques de coûts associés.
  • Les formes de VM personnalisées vous permettent de ne payer que la quantité de processeurs et de mémoire réellement utilisée par les serveurs de jeux dédiés.
  • Les VM Compute Engine démarrent très rapidement, de quelques secondes (Linux) à quelques minutes (Windows).
  • La disponibilité régionale étendue vous permet de placer vos serveurs de jeux près de vos clients. L'espace réseau global par défaut permet à ces serveurs de communiquer facilement avec vos services existants sans travail supplémentaire.
  • Vous pouvez provisionner des environnements ponctuels pour le développement, les tests de contrôle qualité ou les événements en quelques minutes et les ignorer dès qu'ils ne sont plus nécessaires, sans aucun engagement et sans impact sur les autres environnements.
  • Vous pouvez facilement configurer des versions hébergées dans Google Cloud Storage en tant qu'origine CDN ou distribuer des versions directement à partir de buckets.
  • Les instantanés d'artefacts de version sur des disques distincts peuvent permettre des mises à niveau faciles de l'OS, ainsi que la promotion de version en production à l'aide de liens symboliques.

Utiliser des projets pour séparer des environnements

Il n'est pas rare que le développement, le test, la préproduction et les environnements publics soient séparés en différents projets. Les projets sont légers et peuvent facilement être créés et détruits. Un autre modèle répandu consiste à créer un projet pour un environnement de test, à déployer une version, à faire exécuter des tests de confiance au contrôle qualité et à détruire le projet lorsque la version est prête à être promue ou rejetée. Cela garantit également la séparation des ressources et des quotas. Par exemple, une mauvaise exécution des tests ne peut pas affecter les services de production en surchargeant les ressources. En outre, le fait de détruire un projet supprime toujours toutes les ressources qu'il contient, garantissant ainsi que vous n'avez pas oublié les environnements de test ou de développement apparaissant sur votre facture.

Obtenir des versions sur le cloud

Le téléchargement de versions sur Cloud Storage n'engendre que le coût de stockage par Go. Une fois effectué, il est facile d'utiliser ce téléchargement comme origine CDN ou de distribuer des versions à d'autres studios ou prestataires. Vous pouvez définir la Durée de vie des objets téléchargés à l'aide de la gestion du cycle de vie des objets pour que vos tâches administratives restent gérables et vos coûts limités.

Distribution

Il est courant d'héberger des éléments et des binaires dans le cloud à l'aide d'un magasin d'objets tel que Cloud Storage ou d'un stockage de blocs, tel que des disques persistants. Tous les processus existants utilisant le S3 d'Amazon Web Service peuvent être facilement modifiés ou étendus pour utiliser Cloud Storage, car ils sont compatibles avec les API. Bien que le stockage d'éléments sur Cloud Storage soit un excellent moyen de distribuer des versions aux clients, aux CDN et même aux bureaux distants, copier des données de Cloud Storage sur les VM de votre serveur de jeu peut augmenter le temps de chargement. Cette approche n'est donc pas recommandée. De nombreux clients possédant un grand nombre de serveurs de jeux dédiés seront déjà familiarisés avec le schéma de "façonnage" d'images de disque comportant déjà toutes les bibliothèques et tous les éléments et binaires nécessaires pour démarrer une nouvelle VM de serveur de jeu dédiée. Cette stratégie est aussi valable sur GCP que sur site ou sur d'autres clouds. Cependant, nous vous recommandons d'associer des instantanés avec des disques en lecture seule, comme détaillé dans la section suivante, car cela présente des avantages significatifs.

Stratégie d'instantanés avec disques en lecture seule

Dans la plupart des jeux, la version de l'OS et du serveur de jeu peut être modifiée indépendamment. Nous vous recommandons de ne pas compiler le jeu sur le disque de l'OS, mais sur un disque persistant distinct, avec les artefacts de compilation nécessaires liés de manière symbolique à leur répertoire prévu. Cette configuration crée un workflow propre pour la distribution de plusieurs versions sur une VM. Il vous suffit de placer chaque version sur son propre disque, d'attacher tous les disques à la VM et de mettre à jour les liens symboliques lorsque vous êtes prêt à changer de version de serveur de jeu. Les versions précédentes sur des disques distincts peuvent rester connectées jusqu'à ce que vous soyez sûr que la nouvelle version est stable, ce qui permet des rollbacks rapides. Vous pouvez joindre des disques persistants à plusieurs VM, ce qui réduit les coûts et élimine le besoin de distribuer des éléments à toutes les VM.

Lorsque vous implémentez cette approche dans le cadre d'un pipeline de développement de jeux, nous vous recommandons de configurer votre système de version de manière à prendre les mesures nécessaires pour créer le disque avec tous les fichiers d'artefact dans la structure du répertoire approprié. Par exemple, vous pouvez utiliser un simple script qui exécute les commandes gcloud, ou un plug-in GCP pour le système de compilation de votre choix. Nous vous recommandons également de créer plusieurs copies du disque et de connecter les VM à ces copies de manière équilibrée, tant pour des considérations relatives au débit que pour gérer le risque de défaillance. Notez que vous pouvez créer simultanément plusieurs disques persistants à partir d'un seul instantané, ce qui constitue un moyen efficace de générer rapidement plusieurs copies de disque de la même version du serveur de jeux.

Réseau

GCP s'exécute sur le réseau de fibre optique privé et sur mesure de Google qui offre une très faible latence entre les principaux points de présence métropolitains (POP, Points of Presence) et les centres de données GCP. Le modèle de mise en réseau de GCP vous permet de maintenir le trafic essentiel lié au jeu sur le réseau Google entre la région hébergeant vos serveurs et le PoP Google le plus proche possible du FAI de votre client. Ce mode de fonctionnement est diamétralement opposé aux stratégies de routage de type "patate chaude" couramment proposées par d'autres fournisseurs, qui tentent d'acheminer votre trafic vers l'Internet public dès que celui-ci quitte les VM. Le réseau de Google peut offrir une fiabilité plus élevée et une latence plus prévisible pour vos joueurs.

De plus, GCP utilise par défaut un espace réseau mondial. Il n'est pas nécessaire de "connecter" différentes régions ou zones à l'aide de VPN ou d'autres logiciels de mise en réseau. Si vous démarrez une VM dans la zone us-central1-b et une autre dans eu-central1-a, puis que vous les configurez pour utiliser le même réseau, elles peuvent se joindre l'une et l'autre sans configuration supplémentaire. L'ensemble du trafic interzone reste sur le réseau privé de Google et ne subit aucune latence imputable à des sauts supplémentaires causés par BGP sur l'Internet public.

Mise en réseau entre les projets

Par défaut, chaque projet GCP que vous créez représente son propre réseau global isolé. Les VM ne pourront pas communiquer entre elles sans passer par l'Internet public si elles se trouvent sur des projets distincts. Bien qu'il existe plusieurs façons d'établir une mise en réseau des différents projets, nous vous recommandons d'utiliser un seul projet pour exécuter les serveurs et les services que vous souhaitez voir communiquer entre eux dans un espace réseau privé.

Mise en réseau GCP pour les serveurs de jeux

Le schéma de mise en réseau le plus courant pour les serveurs de jeux dédiés sur GCP consiste à créer un réseau de "jeux" à l'aide de la console Google Cloud Platform. Configurez ce réseau avec les ports de jeu appropriés ouverts au trafic Internet, ainsi que tous les ports internes requis pour les vérifications de l'état, la surveillance ou la communication du service de plateforme. Ensuite, spécifiez ce réseau lors de la création des VM hébergeant des serveurs de jeu dédiés.

Bonnes pratiques

Une fois les serveurs de jeu migrés vers GCP, vous pourriez trouver des avantages à optimiser davantage les versions de vos serveurs afin d'utiliser l'infrastructure GCP.

Optimisations des processeurs virtuels

Les vitesses d'horloge sont relativement constantes par processeur virtuel, mais Google possède des régions du cloud qui contiennent les dernières architectures de processeurs Intel. Certains utilisateurs de jeux dans Linux ont constaté une accélération pouvant atteindre 20 % de la compilation avec des indicateurs propres à l'architecture et de l'exécution de leurs serveurs dans des régions disposant de processeurs issus de ces familles. La cohérence de vitesse des processeurs virtuels se prête également à une approche évolutive horizontale plutôt que verticale pour les tâches nécessitant une utilisation intensive des processeurs. Si possible, utilisez des threads de calcul et chargez en parallèle votre code pour lui permettre d'utiliser plusieurs processeurs, plutôt que d'avoir besoin de plus de cycles sur un petit nombre de processeurs.

Optimisations du réseau

Bien qu'il existe des frais pour la sortie du trafic, l'entrée est gratuite. Envisagez de recourir à des schémas de communication asymétriques qui utilisent un taux de mise à jour plus élevé pour les paquets provenant du client que ceux provenant du serveur. Souvent, l'effet d'une fréquence de mise à jour du serveur plus faible peut être atténué par une interpolation ou une extrapolation. De plus, si le code de marshaling/sérialisation de votre client et de votre serveur peut être rendu suffisamment efficace, envisagez d'utiliser la compression de paquets pour conserver une taille de paquet réduite.

Optimiser les événements d'analyse et la journalisation

Vous pouvez établir un chemin d'accès à la journalisation et aux événements d'analyse de volume élevé vers Google BigQuery ou Cloud Storage et l'activer ou le désactiver pour chaque processus de serveur de jeu individuel. Cette approche vous permet d'enquêter rapidement sur les failles signalées, d'analyser l'équilibrage du jeu ou de générer des données d'entraînement de ML. Le stockage des données dans l'un ou l'autre des services est très bon marché (102,40 $/mois pour 5 To de stockage actuellement, avec un solide historique de baisse des prix). Elles peuvent être configurées pour expirer automatiquement après une date donnée, ce qui vous permet de contrôler facilement les coûts et le volume de données.

Externaliser l'état du jeu

Notre présentation de l'infrastructure de jeu dans le cloud présente brièvement les avantages potentiels de l'externalisation de l'état. Il peut être intéressant de déterminer quelles parties de votre état de jeu peuvent être externalisées. Une certaine quantité d'état externalisé peut être réalisée aujourd'hui, et de nouvelles technologies cloud améliorent chaque jour cette capacité. L'état externalisé rend possible de nombreuses fonctionnalités intéressantes telles que :

  • Autoriser la migration des processus du serveur de jeu entre VM, pendant la lecture, avec une interruption minimale. Cela peut servir dans de nombreux scénarios, par exemple :

    • pour co-héberger des serveurs de jeu ou des services qui établissent une communication intraserveur de montants importants dans la même région voire sur la même VM, sans chercher à prédire les modèles de trafic de l'utilisateur à l'avance ;
    • pour séparer les processus qui utilisent beaucoup de ressources ;
    • pour migrer à chaud de façon simple depuis les VM qui doivent être arrêtées en vue d'être mises à jour ou supprimées pour réduire leur utilisation après un pic de demandes.
  • Autoriser plusieurs processus à travailler sur différentes parties de la simulation et partager les mises à jour les unes avec les autres dans une mémoire au mode de partage similaire, mais à une plus grande échelle.

  • Autoriser la sauvegarde de la sérialisation d'état sur un disque ou le partage avec un autre serveur de jeu, ce qui peut ouvrir de nouvelles possibilités pour le sport électronique, telles que :

    • des rediffusions capturées par le serveur faisant autorité avec une chaîne de conservation ;
    • des serveurs de jeux dédiés "mis en miroir", permettant à un très grand nombre de spectateurs de jouer en direct sur des clients de jeux.

Étapes suivantes