Leaf in the Wild : Square Enix fait évoluer TOMB RAIDER, HITMAN ABSOLUTION, DEUS EX et bien d'autres titres, avec MongoDB

Note de l'éditeur : Cette publication a été actualisée le 30 juin 2015, en raison du passage de MongoDB Management Service (MMS) à MongoDB Cloud Manager. Pour en savoir plus, cliquez ici.

MongoDB Enterprise Advanced permet à un seul administrateur d'assurer une disponibilité continue, 24h/24, 7j/7, sur des dizaines de clusters partitionnés

Avec des titres aussi populaires que TOMB RAIDER et FINAL FANTASY, Square Enix compte parmi les principales entreprises internationales d'édition de jeux vidéos. Suite à sa politique de développement de jeux en ligne, Square Enix a rapidement atteint les limites de scalabilité de ses bases de données relationnelles, et a donc décidé de migrer vers MongoDB. En adoptant une base de données en mode service mutualisée, Square Enix a pu consolider ses instances de base de données, améliorant ainsi ses performances et sa fiabilité. Des outils opérationnels avancés permettent aux équipes opérationnelles de Square Enix de monter en charge des dizaines de clusters de bases de données à la demande et d'assurer une disponibilité 24h/24, 7j/7 à ses joueurs, partout dans le monde, en employant un seul administrateur.

Tandis que le salon E3 Expo de cette année approche, j'ai pu m'entretenir avec Tomas Jelinek, Administrateur des opérations en ligne senior chez Square Enix Europe pour parler de la manière dont ses plateformes avaient évolué pour répondre à la demande de millions de joueurs connectés partout dans le monde.

Pouvez-vous commencer par nous présenter brièvement Square Enix ?

Square Enix est l'un des principaux fournisseurs internationaux de contenus de divertissements numériques. Son influence est prépondérante. Notre catalogue contient de grands noms du jeu vidéo, tels que FINAL FANTASY, DRAGON QUEST, TOMB RAIDER, HITMAN, DEUS EX et JUST CAUSE, qui, ensemble, se sont vendus à des millions d'exemplaires.

Nous cherchons toujours à repousser les limites de la créativité et de l'innovation en fournissant des contenus et des produits de divertissement de qualité. Comme le secteur du jeu vidéo se situe au croisement des Big Data, de la mobilité et du Cloud computing, nos plateformes d'infrastructure sont essentielles pour garder un avantage compétitif et offrir à nos joueurs une expérience unique.

Nous avons quelques annonces très intéressantes à faire à l'occasion de l'E3, et elles me rendent particulièrement fier et heureux de travailler au sein de l'équipe opérationnelle dont les efforts concourent au bon fonctionnement de nos plateformes de jeux.

Expliquez-nous comment Square Unix utilise MongoDB.

Au début, nos jeux fonctionnaient sur une plateforme ou les données étaient stockées dans des bases de données relationnelles à l'ancienne. Mais cela n'était pas suffisant pour supporter la multiplication de nos titres, la complexification de nos jeux et la croissance incroyable de nos jeux de données. Nous avons donc développé notre suite en ligne mutualisée : une infrastructure centralisée et partagée utilisée dans toute l'entreprise. Nous avons fourni MongoDB en tant que service à l'ensemble de nos studios et développeurs. Dans le cadre de cette suite en ligne, nous avons développé une API qui permet à nos studios d'utiliser MongoDB pour stocker et gérer des indicateurs, des profils de joueurs, des informations d'équipe, des tableaux de classements et des concours. Nous utilisons également MongoDB pour permettre à nos joueurs de partager des messages sur toutes les plateformes prises en charge telles que PlayStation, Xbox, PC, interfaces web, iOS, Android, etc. L'objectif principal de la suite en ligne est de prendre en charge les fonctionnalités requises pour tous les jeux.

Chaque titre requiert également la prise en charge de ses propres fonctionnalités dans le jeu, c'est pourquoi chacun d'eux bénéficie d'une infrastructure dédiée, connectée à MongoDB, pour stocker son statut et les indicateurs des joueurs, ainsi que des fonctionnalités et contenus spécifiques. Par exemple, Hitman Absolution offre la possibilité aux joueurs de créer leurs propres contrats, puis de les partager avec d'autres joueurs. Tout ceci est géré par MongoDB.

Nous utilisons également MongoDB pour nos services de messageries inter-jeu et de joueur à joueur. Nos sites web et mobiles utilisent MongoDB pour la gestion des contenus et des catalogues de produits.

*Just Cause 3 : prêt à jaillir sur n'importe quelle plateforme près de chez vous. Just Cause 3 © 2015 Square Enix Ltd*

Quelles technologies utilisiez-vous avant MongoDB ? Êtes-vous partis de zéro, ou avez-vous migré à partir d'une autre base de données ?

Le passage vers les jeux en ligne a commencé en 2007. Nous avons utilisé des bases de données relationnelles pour stocker des profils de joueurs et des tableaux de classements, mais aussi pour analyser les indicateurs collectés à partir de l'utilisation de nos jeux. Mais comme notre public en ligne a augmenté, la montée en charge de nos bases de données a commencé à nous poser problème. Nous avons fini par réunir nos équipes de consultants afin d'acquérir le matériel nécessaire pour améliorer nos capacités, mais les bases de données en place ne suffisaient plus.

Nous avons commencé à nous poser de plus en plus de questions sur le devenir de nos données. L'exécution d'une requête d'analyse complexe dans notre base de données relationnelle pouvait prendre jusqu'à 3 semaines ! Nous savions qu'il était temps de chercher une alternative.

Comment avez-vous appris l'existence de MongoDB ? Avez-vous envisagé d'autres possibilités ?

Nous avons lancé nos recherches en vue d'un remplacement dès 2011. Nous avions besoin d'une base de données pouvant répondre aux besoins de nos équipes de développeurs à Montréal et de notre équipe des opérations, ici, à Londres.

Les équipes de développement se souciaient particulièrement de la vitesse à laquelle elles pouvaient développer de nouveaux jeux et ajouter des fonctionnalités pour maximiser le cycle de vie de leurs jeux. Elles devaient également s'assurer que la nouvelle base de données pouvait prendre en charge toutes les fonctionnalités opérationnelles et analytiques dont elles avaient besoin. Il leur fallait donc un schéma flexible et un langage de requête expressif.

Notre équipe opérationnelle, de son côté, devait avaliser les capacités de scalabilité et de robustesse de la base de données. Nous ne pouvions faire, en effet, aucun compromis sur la qualité de l'expérience de nos utilisateurs, quand bien même les développeurs eussent été pleinement satisfaits. Pour éviter tout problème de gestion courante, nous devions également vérifier que la base de données pouvait s'adapter à nos flux de travail opérationnels et à nos outils.

Chaque équipe a effectué ses propres évaluations. Nous avons établi une grille d'évaluation et examiné différentes technologies de bases de données, nouvelles ou déjà éprouvées, parmi lesquelles MongoDB. Nous avons engagé un consultant externe pour nous guider durant ce processus.

Toutes les équipes en sont venues à la même conclusion : la technologie de MongoDB est la plus adaptée à notre plateforme de jeux de nouvelle génération. Et ces requêtes complexes qui nous prenaient 3 semaines avec nos bases de données relationnelles... nous les effectuons à présent en 2 minutes dans MongoDB ! La vitesse des analyses en jeu est démultipliée.

Dans le contexte de l'évolution des bases de données, 2011 semble déjà loin... et je suis sûr que les produits que nous avons évalué ont grandement évolué. Mais nous n'avons jamais regretté d'avoir choisi MongoDB.

Pouvez-vous décrire votre déploiement de MongoDB ?

Aujourd'hui, nous exécutons principalement MongoDB 2.6. Chaque instance de serveur de jeu est déployée sur une machine virtuelle exécutant Ubuntu Linux, Nginx et Jetty, qui se connectent à MongoDB avec le pilote Java.

Notre suite en ligne mutualisée est provisionnée sur le cluster MongoDB principal, doté de 10 partitions. Chaque partition est configurée par un jeu de réplicas à 3 nœuds exécutant un nœud primaire, un nœud secondaire et un arbitre de jeu de répliquas. Chaque instance MongoDB exécute son propre serveur physique dans nos centres de données.

Nous utilisons une autre architecture pour les clusters dédiés aux autres projets prenant en charge des titres individuels. La charge de nos jeux sur le serveur principal est en dents de scie. Il est courant de provisionner plus de 60 serveurs frontaux pour prendre en charge le lancement d'un nouveau jeu, puis de réduire cette charge en fonction du trafic. Nos équipes marketing proposent régulièrement des promotions sur certains jeux. Avec cette approche, il nous suffit d'ajouter des nœuds au cluster en cas de besoin. Ce type de flexibilité est essentiel pour nous permettre de conserver nos coûts aussi bas que possible en évitant un provisionnement à outrance. MongoDB nous a offert une couche de persistance assez solide pour prendre en charge une telle approche.

Plusieurs de nos clusters de jeux dédiés sont déployés sur AWS, et nous avons commencé à utiliser MongoDB Cloud Manager pour automatiser le provisionnement et la configuration, mais aussi pour gérer les mises à niveau.

Je trouve que Cloud Manager est particulièrement utile : il nous permet de gagner un temps précieux. Grâce à lui, nous pouvons monter en charge notre infrastructure sans avoir à augmenter les effectifs de notre personnel opérationnel. Cela signifie que je peux être plus productif et quitter le travail plus tôt !

Provisionnement de MongoDB automatisé sur AWS EC2

Quels outils utilisez-vous pour gérer votre déploiement MongoDB ?

En plus du provisionnement, nous utilisons également Cloud Manager pour collecter des données de télémétrie à partir de nos clusters MongoDB. Nous surveillons en continu et gérons les alertes d'indicateurs clés tels que les compteurs d'opérations, les files d'attentes, les connexions, l'utilisation de la mémoire et du processeur, et les opérations d'entrée-sortie par seconde (IOPS) sur les disques. En établissant des référentiels et des alertes sur ces indicateurs clés, nous pouvons automatiser la montée en charge de MongoDB pour répondre à l'augmentation du trafic, avant que notre service commence à se dégrader.

Pour notre infrastructure principale globale, nous utilisons Nagios et Cacti pour la surveillance et l'automatisation de tous les éléments utilisant Ansible et Puppet.

Nos propriétés Web et mobiles exécutent une configuration légèrement différente, dans laquelle MongoDB est connecté à des services Ruby et Docker pour l'orchestration.

** Pouvez-vous partager certaines de vos meilleures pratiques relatives à la montée en charge de votre infrastructure MongoDB ?**

Pour commencer, il est essentiel de mettre en place une surveillance adéquate. Il ne faut jamais attendre que le système soit en surcharge pour ajouter de la capacité. En effet, s'il reste peu de ressources à votre système, vous aurez beaucoup de mal à effectuer une montée en charge sans affecter les performances de votre application.

Je vous conseille également d'éviter de colocaliser trop de ressources entre différentes applications complètement différentes. Par exemple, le partage de nœuds ou de serveurs de configuration peut compliquer les mises à niveau. C'est pourquoi, je vous recommande d'isoler les composants lorsque vos applications ont des modèles de requêtes et des profils de trafic très différents.

Avez-vous intégré MongoDB à d'autres plateformes d'analyse de données ?

Nous utilisons Pentaho pour afficher sur un tableau de bord les données stockées dans MongoDB.

Les données d'indicateurs collectées à partir des jeux et des joueurs sont stockées dans MongoDB, puis chargées dans un cluster Hadoop Cloudera, afin de mener des analyses hors-ligne plus affinées.

Utilisez-vous des services MongoDB pour prendre en charge votre déploiement ?

Oui. Nous utilisons MongoDB Enterprise Advanced, pour bénéficier d'un accès aux services d'assistance technique de MongoDB. En cas de problème, l'équipe d'assistance nous aide rapidement. Par exemple, à Noël dernier, nous avons subi une dégradation des performances sur deux clusters. Les ingénieurs de l'assistance technique de MongoDB ont pu rapidement diagnostiquer le problème et en déterminer la cause. Il s'agissait d'un problème matériel sous-jacent. Nous avons ainsi évité tout impact sur l'expérience client pendant l'une de nos périodes les plus chargées de l'année. C'est pourquoi l'assistance technique de MongoDB nous est si précieuse.

Comment pouvez-vous quantifier l'influence de MongoDB sur vos activités ?

L'expérience client est au cœur de tout. Pour garantir sa qualité, nous devons pouvoir procéder rapidement à une montée en charge à la demande lors du lancement de nouveaux jeux. Nous ne pouvons pas tolérer le moindre temps d'arrêt. Nos services doivent rester disponibles 24h/24, 7j/7, durant les pannes et les maintenances planifiées. L'architecture de MongoDB nous permet tout cela.

Nous pouvons à tout moment ajouter et supprimer des nœuds MongoDB des clusters partitionnés. Ceci est crucial lors de l'exécution de différentes tâches de gestion. La quantité de données que nous collectons augmente constamment et les capacités de MongoDB peuvent évoluer au même rythme. L'arrivée d'un jeu génère généralement 120 Go de données par jour. Si on considère que ces données s'ajoutent à celles générées par les autres jeux et à celles des années passées, on peut imaginer à quel point le jeu de données augmente rapidement. Les nouvelles données sont stockées sur des disques rapides, tandis que les anciennes données sont migrées vers des disques plus lents.

Les jeux de réplicas améliorent notre capacité de tolérance et les mises à niveau propagées nous permettent de modifier notre plateforme en maintenant nos services en ligne.

MongoDB nous a permis d'acquérir une efficacité opérationnelle qui est tout à fait cruciale. Je suis en mesure d'exécuter l'intégralité de notre domaine MongoDB pratiquement seul. Cloud Manager, associé à un support proactif, a été essentiel pour parvenir à un tel niveau d'efficacité.

Avez-vous prévu une mise à niveau vers MongoDB 3.0 ?

Nous trouvons cette nouvelle version très attrayante. Son contrôle des accès simultanés plus granulaire permettra d'améliorer nos performances, surtout pour les applications gourmandes en écriture. Comme nos jeux de données continuent d'augmenter, la compression est très importante pour nous permettre d'optimiser notre espace de stockage. Nous prévoyons donc de passer à MongoDB 3.0 cette année.

Quel conseil pourriez-vous donner à quelqu'un qui songerait à utiliser MongoDB pour son prochain projet ?

Il n'y a rien de plus simple que d'essayer MongoDB. Avec Cloud Manager, vous pouvez mettre en place de nouvelles instances sur AWS en quelques secondes. Il vous suffit de charger vos données, et vous pouvez commencer votre test.

Tomas, merci d'avoir pris le temps de partager ces informations avec la communauté MongoDB.


Vous voulez essayer Cloud Manager ? Souscrivez à notre version d'essai gratuit de 30 jours :

Essayer Cloud Manager gratuitement


Les jeux Square Enix s'exécutant sur MongoDB incluent Tombe Raider, Lara Croft and the Guardian of Light, Lara Croft and the Temple of Osiris, Hitman Absolution et Hitman Go:, Deus Ex, Thief, Just Cause 3, Sleeping Dogs, Life is Strange et Nosgoth. DEUS EX, DRAGON QUEST, FINAL FANTASY, HITMAN, JUST CAUSE, SQUARE ENIX, le logo SQUARE ENIX, et TOMB RAIDER sont des marques commerciales ou des marques déposées de Square Enix Group. Toutes les autres marques commerciales appartiennent à leurs propriétaires respectifs.