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.
GAMEREL03-BP01Surveillez les interruptions des serveurs de jeu et utilisez les données pour améliorer l'architecture d'hébergement afin d'atteindre les objectifs de fiabilité
Surveillez les statistiques des serveurs de jeu et l'impact des pannes ou des dégradations de performances, telles que l'augmentation de la latence en cas de charge, sur le comportement des joueurs au fil du temps afin de pouvoir ajuster la stratégie d'hébergement de votre serveur de jeu pour répondre aux exigences de fiabilité de votre jeu. L'infrastructure du serveur de jeu à dégrader doit être immédiatement mise hors service si elle a un impact sur les joueurs ou remplacée de manière proactive lorsqu'aucune session de joueur active n'est hébergée sur le serveur.
Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé
Directives d’implémentation
Dans les scénarios où les jeux sont hébergés sous forme d'API REST, la fiabilité du système peut être gérée comme les architectures d'applications Web traditionnelles, dans lesquelles le trafic peut être équilibré de manière distribuée sur plusieurs serveurs afin de réduire le risque de défaillance des serveurs.
Pour le jeu synchrone en temps réel, une session de jeu est généralement hébergée sur un processus de serveur de jeu exécuté sur une machine virtuelle, ou une instance de serveur de jeu, car l'état de jeu doit être maintenu de manière performante et répliqué sur les clients de jeu connectés. Cette implémentation signifie que l'expérience du joueur est étroitement liée aux performances et à la fiabilité du processus du serveur de jeu qui héberge sa session de jeu. Ce type d'architecture rend la gestion de la fiabilité des serveurs de jeu plus complexe que les approches traditionnelles.
Pour atténuer l'impact d'une panne de serveur de jeu, configurez votre jeu de manière à effectuer en permanence des mises à jour asynchrones de l'état de jeu d'un joueur vers un cache ou une base de données hautement disponible telle qu'Amazon ElastiCache (Redis OSS) ou Amazon MemoryDB.
Cependant, cette approche augmente le coût et la complexité de la gestion de cet état externe et peut ne pas convenir aux jeux rapides ou compétitifs où les changements d'état sont si fréquents et se produisent à une telle échelle que l'introduction même d'un magasin de données en cache en mémoire performant entraînerait un retard de réplication trop important pour être utile pour restaurer une session. Pour les jeux de cette nature, l'approche optimale consiste à accepter la perte du serveur et à renvoyer le joueur dans un lobby de jeu pour trouver une autre session ou vous pouvez le rediriger automatiquement vers une autre session de jeu.
Capturez autant de données de journal utiles sur la cause de l'interruption du serveur afin de pouvoir étudier le problème ultérieurement. Amazon GameLift fournit des conseils pour résoudre les problèmes liés à la flotte et permet d'accéder à distance aux instances d'Amazon GameLift Fleet.
Étapes d’implémentation
-
Surveillez les statistiques des serveurs de jeu pour détecter toute dégradation des performances, et supprimez ou remplacez les serveurs dégradés si nécessaire pour maintenir la fiabilité.
-
Utilisez Amazon ElastiCache ou MemoryDB pour les mises à jour asynchrones de l'état du jeu afin de permettre la restauration de session après une panne du serveur lorsque cela est possible.
-
Capturez des données de journal détaillées sur les interruptions du serveur à des fins d'investigation et de débogage, en tirant parti d'outils tels qu'Amazon GameLift pour la surveillance de la flotte et l'accès à distance.