Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

GAMEREL01-BP01 Répartissez l'infrastructure de jeu dans plusieurs zones de disponibilité et régions pour améliorer la résilience

Pour minimiser l'impact des défaillances localisées de l'infrastructure sur vos joueurs, vous devez répartir le déploiement de votre infrastructure de manière uniforme sur un nombre suffisant de sites indépendants pour être en mesure de résister à des dégradations inattendues tout en disposant d'une capacité suffisante pour répondre aux besoins de vos joueurs.

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé

Directives d’implémentation

Lorsque vous déployez votre infrastructure de jeu, il est recommandé de répartir uniformément votre capacité entre les différentes zones de disponibilité d'une région afin de pouvoir résister aux perturbations affectant une ou plusieurs zones de disponibilité sans perturber l'expérience des joueurs. Les services backend de jeux tels que les applications Web doivent être équilibrés en charge sur plusieurs zones de disponibilité ou doivent être créés à l'aide de services gérés tels qu' AWS Lambda Amazon API Gateway, qui garantit une haute disponibilité régionale dès la conception. De même, les composants qui conservent leur état, tels que les caches, les bases de données, les files d'attente de messages et les solutions de stockage, doivent être conçus pour assurer la persistance durable des données dans plusieurs zones de disponibilité, ce qui est prévu par la conception dans des services tels qu'Amazon S3, DynamoDB et Amazon SQS, et peut être configuré dans d'autres services.

Lorsque vous concevez l'architecture d'hébergement de votre serveur de jeu dans un souci de résilience, déployez vos flottes de serveurs de jeu de manière uniforme dans les zones de disponibilité de manière Région AWS à maximiser votre accès à la capacité de calcul disponible dans la région et à réduire l'impact des dégradations des zones de disponibilité. Par exemple, vous pouvez configurer Amazon EC2 Auto Scaling pour utiliser les zones de disponibilité. Si une instance EC2 devient défectueuse, EC2 Auto Scaling peut la remplacer et lancer des instances dans d'autres zones de disponibilité si une ou plusieurs zones de disponibilité deviennent indisponibles.

Pour les infrastructures critiques, telles que l'authentification, provisionnez un nombre minimum d'instances viables s'exécutant dans plusieurs zones de disponibilité et utilisez la mise à l'échelle automatique pour gérer les augmentations de charge ou la tolérance aux pannes en cas de dysfonctionnement de l'une des zones de disponibilité.

Déployez votre infrastructure de jeu dans plusieurs régions afin d'en optimiser la disponibilité. Cross-Regional les fonctionnalités de reprise après sinistre telles que les bases de données mondiales Aurora et l'infrastructure redondante qui peut devenir active par un simple changement de DNS déployé dans une région secondaire peuvent assurer la continuité du service en cas de défaillance de la région principale. Bien que nous vous encouragions à utiliser cette méthode pour que vos services principaux de jeu atteignent une haute disponibilité, cette recommandation est particulièrement importante pour vos serveurs de jeu.

Par exemple, dans un jeu multijoueur, la capacité de votre infrastructure pour les serveurs de jeu est susceptible de dépasser la capacité requise pour vos autres services, étant donné que les serveurs de jeu sont utilisés pour héberger des sessions de jeu pour les joueurs. De nombreux jeux choisissent de répartir les joueurs dans des régions de jeu logiques (comme l'ouest et l'est des États-Unis). Pour simplifier l'expérience des joueurs et faciliter l'utilisation d'une infrastructure globale pour héberger des jeux, pensez à dissocier le nom de vos régions de jeu destinées aux joueurs de la région du fournisseur de cloud sous-jacent ou de l'emplacement du centre de données qui héberge physiquement les serveurs de jeu, ainsi que d'autres infrastructures telles que les zones locales ou vos propres centres de données hébergeant des instances de serveurs de jeu prenant en charge cette région de jeu pour les joueurs.

Lors de la conception de votre service de jumelage, déployez une architecture multirégionale avec des déploiements logiciels distincts entre les régions. Découplez le déploiement de votre service de matchmaking des flottes qui hébergent les instances de vos serveurs de jeu afin de pouvoir rediriger les joueurs vers un serveur de jeu dans les régions, quel que soit le déploiement régional de votre service de matchmaking qui a traité la demande de matchmaking.

Concevez une logique dans votre implémentation de matchmaking pour privilégier les régions des serveurs de jeu qui respectent vos règles de latence et d'autres règles, avec la possibilité de rediriger les joueurs vers d'autres régions si la capacité de vos flottes est faible ou en cas de perturbations de l'infrastructure régionale.

Étapes d’implémentation

Ressources