Ce billet est la première partie d’une série en deux parties sur la manière dont les organisations utilisent Azure Cosmos DB pour répondre à des besoins réels et sur ce que cela leur apporte. Dans la partie 1, nous explorons les défis qui ont conduit les développeurs de service pour Minecraft Earth à choisir Azure Cosmos DB et comment ils l’utilisent pour capturer presque toutes les actions effectuées par chaque joueur dans le monde entier, avec une latence très faible. Dans la partie 2, nous examinons la charge de travail de la solution et les avantages qu’ont obtenu les développeurs du service Minecraft Earth en se basant sur Azure Cosmos DB.

Extension du monde de Minecraft dans notre monde réel

Vous avez probablement entendu parler du jeu Minecraft, même si vous n’y avez pas joué vous-même. Il s’agit du jeu vidéo le plus adapté de tous les temps, qui a vendu plus de 176 millions de copies depuis 2011. Aujourd’hui, Minecraft a plus de 112 millions de joueurs mensuels, qui peuvent découvrir et collecter des matériaux bruts, créer des outils et bâtir des structures ou des terrains dans le monde 3D immersif avec génération procédurale. En fonction du mode de jeu, les joueurs peuvent également combattre les adversaires contrôlés par ordinateur et coopérer avec, ou se battre contre, d’autres joueurs.

En mai 2019, Microsoft a annoncé la version à venir de Minecraft Earth, qui a commencé son déploiement mondial en décembre 2019. Contrairement aux jeux précédents de la franchise Minecraft, Minecraft Earth passe à un tout nouveau niveau en permettant aux joueurs d’expérimenter le monde de Minecraft dans notre monde réel grâce à la puissance de la réalité augmentée.

Pour les joueurs Minecraft, l’expérience est immédiatement familière, bien qu’elle soit profondément intégrée au monde qui les entoure. Toutefois, pour les développeurs de l’équipe Minecraft chez Microsoft, la livraison de Minecraft Earth, en particulier les services backend faisant autorité requis pour prendre en charge le jeu, a nécessité la création de quelque chose d’entièrement nouveau.

Nathan Sosnovske, ingénieur logiciel senior de l’équipe de développement des services Minecraft Earth, explique :

« Avec Minecraft Vanilla, même si vous pouviez héberger votre propre serveur, il n’existait pas d’autorité de service centralisée. Minecraft Earth est basé sur un service centralisé et faisant autorité, le premier service « lourd » que nous avons eu à créer pour la franchise Minecraft. »

Dans cette étude de cas, nous examinerons quelques-uns des défis qu’ont dû relever les développeurs de service Minecraft Earth qui devaient répondre à un cahier des charges précis, et nous verrons comment ils ont utilisé Azure Cosmos DB pour y répondre.

Le défi technique : éviter les décalages dans le jeu

Au sein du client Minecraft Earth, qui s’exécute sur les appareils iOS et Android prenant en charge la réalité augmentée, presque toutes les actions qu’un joueur effectue génère une écriture dans le service Minecraft Earth principal. Chaque écriture est une publication REST qui doit être immédiatement acceptée et reconnue afin d’éviter tout décalage visible dans le jeu.

« Du point de vue des services, Minecraft Earth requiert des écritures à faible latence et des lectures à latence moyenne », explique Sosnovske. « Les écritures doivent être rapides, car le client nécessite une confirmation sur chacune d’elles. Par exemple, lorsqu’un joueur appuie sur une ressource pour voir ce qu’elle contient, nous ne voulons pas que les visuels se bloquent pendant le traitement de la requête REST correspondante. Les lectures à latence moyenne sont acceptables parce que nous pouvons utiliser la simulation côté client jusqu’à ce que le modèle de sauvegarde derrière le service puisse être mis à jour pour la lecture. »

Pour compliquer le défi, les développeurs de service Minecraft Earth devaient assurer des écritures à faible latence, quelle que soit la localisation du joueur. Cela nécessitait l’exécution de copies du service dans plusieurs emplacements au sein de chaque zone géographique où Minecraft Earth était proposé, avec l’intelligence intégrée servant à router le client Minecraft Earth vers l’emplacement le plus proche où le service est déployé.

« La latence réseau type entre les côtes Est et Ouest des États-Unis est de 70 à 80 millisecondes », déclare Sosnovske. « Si un joueur à New York devait s’appuyer sur un service s’exécutant à San Francisco, ou vice versa, le retard dans le jeu serait inacceptable. En même temps, le jeu est appelé Minecraft Earth, ce qui signifie que nous devons permettre aux joueurs de San Francisco et de New York de partager la même expérience dans le jeu. Pour ce faire, nous devons répliquer le service (et ses données) dans plusieurs centres de données répartis géographiquement au sein de chaque zone géographique. »

La solution : un modèle d’approvisionnement en événements basé sur Azure Cosmos DB

Pour répondre à leurs exigences techniques, les développeurs de service Minecraft Earth ont implémenté un modèle d’approvisionnement en événements basé sur Azure Cosmos DB.

« Au départ, nous avions envisagé d’utiliser le Stockage Table Azure pour stocker notre journal des événements en ajout seul, mais son manque de contrats SLA pour les latences de lecture et d’écriture rendait cela impossible », déclare Sosnovske. « En fin de compte, nous avons choisi Azure Cosmos DB qui offre des contrats SLA de 10 millisecondes pour les lectures et les écritures, avec la distribution mondiale et les fonctionnalités multimaîtres nécessaires pour répliquer le service dans plusieurs emplacements de chaque zone géographique. »

Avec un modèle d’approvisionnement en événements, au lieu de stocker uniquement l’état actuel des données, le service Minecraft Earth utilise un magasin de données en ajout seul qui est basé sur Azure Cosmos DB pour enregistrer la série complète d’actions effectuées sur les données (dans ce cas, le mappage à chaque action dans le jeu effectuée par le joueur). Après que l’accusé de réception immédiat d’une écriture réussie est retourné au client, les files d’attente qui s’abonnent au magasin d’événements en ajout seul gèrent le post-traitement et appliquent de manière asynchrone les événements collectés à un état de domaine géré dans Stockage Blob Azure. Pour une optimisation maximale, les développeurs de Minecraft Earth ont combiné le modèle d’approvisionnement en événements avec la conception pilotée par domaine, dans laquelle chaque domaine d’application (tel que les articles en stock, les profils de personnages ou les réalisations) a son propre flux d’événements.

« Nous avons modélisé nos données sous forme de flux d’événements stockés dans un journal à ajout seul et modifié un état de modèle en mémoire, qui est utilisé pour générer plusieurs affichages clients », déclare Sosnovske. « Cet état mis en cache est conservé dans le Stockage Blob Azure, qui est suffisamment rapide pour les lectures et permet de conserver un minimum de nos coûts unitaires de demande pour Azure Cosmos DB. À bien des égards, ce que nous avons fait avec Azure Cosmos DB est comme créer un cache d’écriture qui est vraiment résilient. »

Le schéma suivant montre le fonctionnement d’un modèle d’approvisionnement en événements basé sur Azure Cosmos DB :

Mise en place d’Azure Cosmos DB

En choisissant d’utiliser Azure Cosmos DB, les développeurs devaient prendre quelques décisions en matière de conception :

API Azure Cosmos DB. Les développeurs ont choisi d’utiliser l’API Azure Cosmos DB Core (SQL), car elle offrait les meilleures performances et la plus grande facilité d’utilisation, ainsi que d’autres fonctionnalités nécessaires.

« Nous étions en train de créer un système à partir de zéro. Il n’y avait donc pas besoin d’une couche de compatibilité pour nous aider à migrer le code existant », explique Sosnovske. « En outre, certaines fonctionnalités Azure Cosmos DB desquelles nous dépendons, telles que TransactionalBatch, sont prises en charge uniquement avec l’API Core (SQL). En outre, l’API Core (SQL) était vraiment intuitive, car notre équipe était déjà familiarisée avec SQL en général. »

Pour en savoir plus, consultez la présentation de TransactionalBatch dans le SDK .NET.

Clé de partition. Les développeurs ont finalement décidé de partitionner logiquement les données dans Azure Cosmos DB en fonction des utilisateurs.

« Nous avions à l’origine partitionné des données sur les utilisateurs et les domaines (tels que des articles en stock ou des réalisations), mais nous avons constaté que cette répartition était trop granulaire et nous empêchait d’utiliser les transactions de base de données dans Azure Cosmos DB à leur plein potentiel », dit Sosnovske.

Niveau de cohérence. Parmi les cinq niveaux de cohérence pris en charge par Azure Cosmos DB, les développeurs ont choisi la cohérence de session, qu’ils combinaient avec une forte vérification des eTags pour s’assurer que les données étaient correctement écrites.

« Cela fonctionne pour nous en raison de la façon dont nous stockons les données, qui sont modélisées sous forme de journal en ajout seul avec un document principal qui pointe vers la fin du journal », explique Sosnovske. « L’écriture dans la base de données implique la lecture du document principal et de son ETag, la dérivation de l’ID de journal N+1, puis la création d’une opération de traitement transactionnel qui remplace le pointeur principal à l’aide de l’ETag lu précédemment et crée un document pour l’entrée de journal. Dans le cas improbable où le journal a déjà été écrit, la vérification du ETag et la tentative de création d’un document qui existait déjà entraînent l’échec d’une transaction. Cela se produisait indépendamment du fait qu’une autre demande soit écrite avant la nôtre ou que notre requête lise des données légèrement obsolètes. »

Dans la partie 2 de cette série, nous allons examiner la charge de travail actuelle de la solution et les avantages qu’ont obtenu les développeurs du service Minecraft Earth en se basant sur Azure Cosmos DB.

Bien démarrer avec Azure Cosmos DB

• Visiter Azure Cosmos DB
• En savoir plus sur Azure et le gaming