Aujourd’hui, les entreprises expérimentent le changement le plus important de notre économie dans une génération et réalisent que le plein potentiel du cloud via la transformation numérique n’a jamais été plus grand.
Les données ont un rôle de plus en plus important dans le renforcement des modèles d’entreprise et dans l’offre de services publics améliorés, mais la majeure partie de leur potentiel reste inexploitée.
Azure Synapse Analytics est un service d’analyse illimité permettant d’intégrer les deux mondes du Big Data et de l’entreposage de données (Data Warehouse) au sein d’une puissante plateforme unifiée de classe Entreprise.
It’s no secret that organizations consider data as one of their most valuable assets and are investing to build their capability for data-driven decision making.
Commencez immédiatement à travailler sur votre premier projet avec le nouveau Centre de connaissances dans Azure Synapse Studio.
Azure Synapse Analytics is a new type of analytics platform that enables you to accelerate your time-to-insight with a unified experience and—just as important—save on costs while doing so.
Azure Data Share in-place Sharing for Azure Data Explorer, now generally available, enables you to share big data easily and securely between internal departments and with external partners, vendors, or customers for near real-time collaboration.
This post is part 2 of a two-part series about how organizations use Azure Cosmos DB to meet real world needs, and the difference it’s making to them.
This post is part 1 of a two-part series about how organizations use Azure Cosmos DB to meet real world needs, and the difference it’s making to them.
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.
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.
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.
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. »
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 :
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.
