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.

GAMEOPS03-BP04 Adoptez une stratégie de déploiement qui minimise l'impact sur les joueurs

Intégrez une stratégie de déploiement pour votre logiciel et votre infrastructure de jeu afin de minimiser les temps d'arrêt qui empêchent les joueurs de jouer. Certains types de mises à jour peuvent nécessiter l'installation de nouvelles mises à jour sur le client du jeu, mais concevez le jeu de manière à minimiser ou à éviter les interruptions de service pendant les déploiements.

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

Directives d’implémentation

L'une des étapes les plus importantes à prendre en compte lors de l'élaboration d'une stratégie de déploiement de jeux est de déterminer comment votre infrastructure de jeu sera gérée. Gérez votre infrastructure de jeu à l'aide d'un outil d'infrastructure en tant que code (IaC) tel que AWS CloudFormation Terraform de Hashicorp pour réduire les erreurs humaines lors de la préparation de l'environnement. Les modèles d'infrastructure peuvent être déployés et testés dans des pipelines automatisés, ce qui garantit la cohérence de la configuration des différents environnements de jeu.

Plusieurs stratégies de déploiement peuvent être utilisées pour un jeu :

Substitution roulante

L'objectif principal d'une substitution progressive pour le déploiement est de réaliser la sortie sans arrêter le jeu et sans affecter les joueurs. Il est important que la mise à niveau ou les modifications à effectuer soient rétrocompatibles et fonctionnent de manière adjacente aux versions précédentes du système.

Dans ce déploiement, les instances de serveur sont remplacées de manière incrémentielle (substituées ou déployées) par des instances exécutant la version mise à jour. Cette substitution par roulement peut être réalisée de différentes manières. Par exemple, pour mettre en œuvre des mises à jour continues sur un parc de serveurs de jeu dédiés, une approche typique consiste à créer un nouveau groupe Auto Scaling d'instances EC2 contenant la nouvelle version du serveur de jeu déployée sur celles-ci, puis à rediriger progressivement les joueurs vers les sessions de jeu hébergées sur ce nouveau parc de serveurs. Si une mise à jour du client de jeu associée est requise comme condition préalable à l'utilisation de la nouvelle version du serveur de jeu, vous devez inclure un contrôle de validation pour vérifier que seuls les joueurs sur lesquels cette nouvelle mise à jour du client de jeu est installée sont redirigés vers ces sessions de jeu.

Les parcs de serveurs (par exemple, les groupes EC2 Auto Scaling) contenant l'ancienne version du serveur de jeu ne sont retirés du service que lorsqu'ils ont été vidés des sessions de joueurs actives de manière élégante, généralement en configurant des métriques de serveur personnalisées qui permettent aux équipes chargées des opérations de jeu d'automatiser ce processus. Pour réduire la quantité d'infrastructure et le temps nécessaires à un déploiement continu, une autre approche peut être mise en œuvre : les instances de production existantes sont retirées du service, mises à jour avec la nouvelle version du serveur de jeu, puis réintégrées dans le parc de production. Cette approche réduit la quantité d'infrastructure requise, mais elle augmente également les risques car le nombre de serveurs de jeu en direct disponibles pour les joueurs est réduit à mesure que les serveurs sont remplacés.

Ce modèle peut également être utilisé pour effectuer des déploiements continus sur des services principaux tels que des bases de données, des caches et des serveurs d'applications qui n'hébergent pas de jeu. Tant que ces services sont déployés de manière hautement disponible avec plusieurs instances en cluster, la complexité des déploiements vers ces services devrait être moindre que celle des déploiements vers des serveurs de jeux dédiés.

Blue/green déploiement

L'objectif principal d'un blue/green déploiement dans un jeu est de minimiser les temps d'arrêt tout en permettant de revenir au déploiement précédent en toute sécurité si des problèmes sont identifiés. Il convient aux déploiements dans lesquels deux versions du backend du jeu sont compatibles et peuvent servir les joueurs simultanément.

Dans la stratégie de blue/green déploiement, deux environnements identiques (bleu et vert) sont mis en place. La version du jeu existante est étiquetée en bleu, tandis que la nouvelle version du jeu qui est la cible de déploiement est étiquetée en vert. Lorsque l'environnement vert est prêt pour la migration, vous pouvez configurer votre couche de routage pour renvoyer le trafic vers l'environnement vert tout en conservant l'ancien environnement (bleu) disponible au cas où un retour en arrière serait nécessaire. Dans ce scénario, les mises à jour du routage peuvent nécessiter la mise à jour du service de matchmaking afin de le configurer afin qu'il commence à envoyer des sessions de jeu à la nouvelle flotte, ou dans le cas des services principaux de jeu, il peut s'agir de mettre à jour les enregistrements DNS dans Amazon Route 53 pour votre service ou de modifier le poids des équilibreurs de charge des applications pour envoyer le trafic vers votre nouveau groupe cible.

L'un des inconvénients de la stratégie de blue/green déploiement est le coût inhérent à l'environnement de secours dû à l'infrastructure supplémentaire requise lors de l'exécution du déploiement. Une option pour atténuer ce coût d'infrastructure supplémentaire consiste à envisager d'adopter une variante de blue/green déploiement dans laquelle les nouveaux logiciels de jeu sont déployés sur les mêmes serveurs que ceux déjà déployés en production. Dans ce scénario, un nouveau processus serveur vert peut être démarré avec le nouveau logiciel parallèlement au processus serveur bleu existant, le basculement s'effectuant entre les processus serveur plutôt qu'entre une infrastructure physique distincte. Cette approche peut également accélérer les déploiements de jeux sur une grande partie de l'infrastructure en évitant d'attendre le lancement de nouveaux serveurs dans le cloud. Pour connaître les meilleures pratiques relatives à cette approche de déploiement, consultez la section Blue/Green Déploiements sur AWS.

Déploiement Canary

Le déploiement de Canary est utile pour les développeurs de jeux, car la stratégie peut être appliquée pour publier une version alpha ou bêta anticipée d'un jeu, ou une fonctionnalité de jeu telle qu'un nouveau mode de jeu, une nouvelle carte ou un défi pour un groupe restreint ou restreint de joueurs en production. Un tel déploiement s'appelle un canari. La version peut comporter un suivi et des rapports supplémentaires. Ainsi, lorsque de vrais joueurs jouent à ce jeu ou à cette fonctionnalité, leur télémétrie de jeu est collectée et analysée pour détecter les anomalies et les problèmes.

En ce qui concerne les nouvelles fonctionnalités, les joueurs ne sont pas régulièrement informés à ce sujet, et la télémétrie du jeu est la principale source utilisée pour déterminer si les joueurs rencontrent des problèmes et si la sortie doit être annulée. Dans le même temps, si aucun problème significatif n'est identifié, la fonctionnalité peut être étendue à un plus grand nombre de joueurs pour obtenir des données supplémentaires. Si les joueurs sont avertis, ils peuvent être invités à fournir des commentaires réguliers sur leur expérience. Une telle activité de test serait idéalement coordonnée par une équipe opérationnelle en direct.

En tant que stratégie, le déploiement de Canary peut également être utilisé pour les versions standard afin de mettre progressivement une nouvelle fonctionnalité à la disposition des joueurs. Un avantage potentiel par rapport à blue/green l'environnement standard est qu'un second environnement complet n'est pas nécessaire. La capacité du nouvel environnement réduit détermine le nombre de joueurs à intégrer à la nouvelle fonctionnalité. Avant d'ajouter d'autres joueurs, la capacité doit être adaptée de manière appropriée. Même si cette blue/green technique personnalisée devrait coûter relativement moins cher que la technique standard blue/green, on estime qu'elle pourrait entraîner des coûts supérieurs à ceux de la technique de substitution progressive utilisée dans les déploiements de canaris.

Exécutez un seul Canary dans un environnement de production et concentrez-le sur ses données et ses commentaires. Le déploiement de plusieurs canaris complique le dépannage et l'identification des problèmes de production et altère la qualité des ensembles de données et des commentaires collectés.

Une variante du canari consiste à effectuer une ou plusieurs expériences (généralement des tests d'interface utilisateur) dans le cadre de déploiements ciblés, dans lesquels un ensemble de serveurs principaux de jeu propose une version d'une fonctionnalité et un autre ensemble de même taille propose une autre version de la même fonctionnalité. Aucune infrastructure supplémentaire ou spéciale n'est créée à cet effet, et seuls les serveurs backend sélectionnés reçoivent ces mises à jour. Le résultat des expériences est d'observer la façon dont les joueurs réagissent à chacune des versions d'une même fonctionnalité, de déterminer s'il existe un consensus général d'appréciation ou d'aversion, et d'observer si des problèmes liés à son utilisabilité ou à ses fonctionnalités ont été identifiés. Ces expériences stratégiques sont également appelées A/B tests, et le processus global est appelé A/B tests. À la fin de ces expériences, les données de test nécessaires sont collectées avant de revenir à la version actuelle du système principal du jeu sur les serveurs utilisés pour les tests.

Déploiements traditionnels existants

Dans le style de déploiement traditionnel, pendant une période de maintenance planifiée, le jeu est arrêté et les joueurs connectés sont supprimés ou vidés avant que les instances de serveur du backend du jeu ne soient mises à jour avec les dernières versions de code. Ce déploiement a un impact sur les joueurs à chaque fois qu'il est effectué, et les joueurs doivent en être informés à l'avance. Par conséquent, ce modèle a le plus d'impact sur les joueurs et doit être évité autant que possible.

Une fois la mise à jour déployée, le jeu peut être testé avant d'être ouvert aux joueurs, qui attendraient sa réouverture. Cela peut provoquer un pic de trafic lorsque les joueurs essaient de se connecter et de jouer dans un court laps de temps. Par conséquent, si le jeu n'est pas conçu pour gérer de tels pics de trafic, vous pouvez choisir d'autoriser progressivement les joueurs à revenir dans le jeu par lots.

Vous pouvez également choisir de surapprovisionner l'infrastructure pour maintenir le pic de trafic initial, et une fois le trafic du jeu réglé, les ressources peuvent être réduites. Si nécessaire, effectuez ce type de déploiement en dehors des heures de pointe, lorsque le nombre de joueurs est au plus bas. La maintenance planifiée fréquemment, ainsi que la maintenance prolongée, comportent intrinsèquement un risque d'attrition des joueurs et de perte potentielle de revenus. Les joueurs s'attendent également à des changements après une nouvelle version et peuvent perdre confiance dans le jeu une fois qu'ils y reviennent après une période d'arrêt.

Étapes d’implémentation