Distribution mondiale des données avec Azure Cosmos DB - sous le capot

  • S’applique à: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

Azure Cosmos DB est un service de base dans Azure, il est donc déployé dans toutes les régions Azure dans le monde entier, y compris les clouds publics, souverains, département de la défense (DoD) et les clouds gouvernementaux.

De manière générale, les données des conteneurs Azure Cosmos DB sont partitionnées horizontalement en plusieurs ensembles de réplication, qui répliquent les écritures, dans chaque région. Les jeux de réplicas s’engagent de manière durable à l’aide d’un vote par la majorité.

Chaque région contient toutes les partitions de données d’un conteneur Azure Cosmos DB, et peut servir des lectures ainsi que des écritures quand les écritures multirégions sont activées. Si votre compte Azure Cosmos DB est distribué entre N régions Azure, il y aura au moins N x 4 copies de toutes vos données.

À l’intérieur d’un centre de données, nous déployons et gérons Azure Cosmos DB sur des clusters massifs de machines, chacune avec un stockage local dédié. Dans un centre de données, Azure Cosmos DB est déployé sur de nombreux clusters, chacun exécutant potentiellement plusieurs générations de matériel. Les machines au sein d’un cluster sont généralement réparties sur 10 à 20 domaines d’erreur pour assurer la haute disponibilité au sein d’une région. L’image suivante montre la topologie du système de distribution mondiale Azure Cosmos DB :

Topologie du système

La distribution globale dans Azure Cosmos DB est une solution clé en main : à tout moment, en quelques clics ou par programmation à l’aide d’un appel d’API, vous pouvez ajouter ou supprimer les régions géographiques associées à votre base de données Azure Cosmos DB. Une base de données Azure Cosmos DB, à son tour, se compose d’un ensemble de conteneurs Azure Cosmos DB. Dans Azure Cosmos DB, les conteneurs servent d’unités logiques de distribution et d’extensibilité. Les collections, tables et graphiques que vous créez sont (en interne) tout simplement des conteneurs Azure Cosmos DB. Les conteneurs sont totalement indépendants du schéma et délimitent le champ des requêtes. Les données d’un conteneur Azure Cosmos DB sont automatiquement indexées lors de l’ingestion. L’indexation automatique permet aux utilisateurs d’interroger les données sans les tracas associés à la gestion du schéma ou de l’index, en particulier dans une configuration globalement distribuée.

  • Dans une région spécifique, les données d’un conteneur sont distribuées à l’aide d’une clé de partition que vous fournissez, et gérées de manière transparente par les partitions physiques sous-jacentes (distribution locale).

  • Chaque partition physique est également répliquée entre les régions géographiques (distribution mondiale).

Quand une application utilisant Azure Cosmos DB met à l’échelle le débit de façon élastique sur un conteneur Azure Cosmos DB ou consomme davantage de stockage, Azure Cosmos DB gère de manière transparente les opérations de gestion des partitions (fractionnement, clonage, suppression) dans toutes les régions. Indépendamment de la mise à l’échelle, de la distribution ou des défaillances, Azure Cosmos DB continue de fournir une image système unique des données au sein des conteneurs, qui sont distribuées globalement sur n’importe quel nombre de régions.

Comme le montre l’illustration suivante, les données d’un conteneur sont distribuées en deux dimensions - dans une ou plusieurs régions, à l’échelle mondiale :

Partitions physiques

Une partition physique est implémentée par un groupe de réplicas appelé jeu de réplicas. Chaque machine héberge des centaines de réplicas correspondant à diverses partitions physiques au sein d’un ensemble fixe de processus, comme le montre l’illustration ci-dessus. Les réplicas correspondant aux partitions physiques sont distribués de façon dynamique, et leur charge est équilibrée sur les machines au sein d’un cluster et sur les centres de données au sein d’une région.

Une réplique n'appartient qu'à un seul locataire Azure Cosmos DB. Chaque réplica héberge une instance du moteur de base de données d’Azure Cosmos DB, qui gère les ressources ainsi que les index associés. Le moteur de base de données Azure Cosmos DB fonctionne sur un système de type arS (atom-record-sequence). Le moteur ignore le concept de schéma et brouille la frontière entre la structure et les valeurs d’instance des enregistrements. Azure Cosmos DB parvient à une indépendance complète du schéma en indexant automatiquement et efficacement tout ce qui est ingéré, ce qui permet aux utilisateurs d’interroger leurs données globalement distribuées sans devoir se préoccuper du schéma ou de la gestion d’index.

Le moteur de base de données Azure Cosmos DB se compose de composants, notamment l’implémentation de plusieurs primitives de coordination, des runtimes de langage, du processeur de requêtes et des sous-systèmes de stockage et d’indexation responsables du stockage transactionnel et de l’indexation des données, respectivement. Pour assurer la durabilité et la haute disponibilité, le moteur de base de données stocke ses données et son index sur des disques SSD, et les réplique entre les instances du moteur de base de données au sein des ensembles de réplicas. Les locataires plus importants correspondent à une plus grande échelle de capacité de traitement et de stockage, et possèdent des répliques de plus grande capacité ou en plus grand nombre, voire les deux. Chaque composant du système étant entièrement asynchrone, jamais un thread ne bloque, et chaque thread effectue un travail de courte durée n’induisant pas de basculements de thread superflus. Une limitation du débit et une contre-pression sont appliquées à la pile entière, du contrôle d’admission à tous les chemins d’E/S. Le moteur de base de données Azure Cosmos DB est conçu pour exploiter la concurrence fine et fournir un débit élevé tout en fonctionnant avec des quantités frugales de ressources système.

La distribution globale de Azure Cosmos DB repose sur deux abstractions clés : replica-sets et partition-sets. Un jeu de réplicas est un bloc de construction modulaire pour la coordination, et un jeu de partitions est une superposition dynamique d’une ou plusieurs partitions physiques distribuées géographiquement. Pour comprendre le fonctionnement de la distribution globale, nous devons comprendre ces deux abstractions clés.

Ensembles de réplicas

Une partition physique est matérialisée sous la forme d’un groupe de réplicas auto-géré et dont la charge est équilibrée de façon dynamique, réparti sur plusieurs domaines d’erreur, appelé jeu de réplicas. Celui-ci implémente collectivement le protocole de machine à état répliqué pour rendre les données de la partition physique hautement disponibles, durables et cohérentes. L’appartenance au jeu de réplicas N est dynamique. Elle fluctue entre NMin et NMax en fonction des échecs, des opérations d’administration et du délai de régénération/récupération des réplicas ayant échoué. En fonction des changements d’appartenance, le protocole de réplication reconfigure également la taille des quorums de lecture et d’écriture. Pour distribuer uniformément le débit affecté à une partition physique donnée, nous appliquons deux idées :

  • Tout d’abord, le coût du traitement des demandes d’écriture sur le leader est plus élevé que celui de l'application des mises à jour sur le serveur secondaire. En conséquence, davantage de ressources du système sont budgétées pour le leader en comparaison des suiveurs.

  • Deuxièmement, autant que possible, le quorum de lecture pour un niveau de cohérence donné est composé exclusivement des réplicas d’abonnés. Nous évitons de contacter l’organisateur pour servir les lectures, sauf si cela est indispensable. Nous appliquons diverses idées issues des recherches menées sur la relation entre la charge et la capacité dans les systèmes basés sur un quorum pour les cinq modèles de cohérence pris en charge par Azure Cosmos DB.

Pour plus d’informations sur les jeux de réplicas et leur relation avec les partitions physiques, consultez les jeux de réplicas de partition.

Ensembles de partitions

Un groupe de partitions physiques, une de chacune des régions configurées avec la base de données Azure Cosmos DB, est composé pour gérer le même ensemble de clés répliqué dans toutes les régions configurées. Cette primitive de coordination supérieure est appelée groupe de partitions. Il s’agit d’une superposition dynamique distribuée géographiquement de partitions physiques gérant un ensemble de clés donné. Si une partition physique (un jeu de réplicas) est circonscrite à l’intérieur d’un cluster, un groupe de partitions peut couvrir plusieurs clusters, centres de données et régions géographiques, comme le montre l’illustration ci-dessous :

Jeux de partitions

Vous pouvez considérer un jeu de partitions comme un « super jeu de réplicas » dispersé géographiquement, composé de plusieurs jeux de réplicas possédant le même ensemble de clés. Comme pour un jeu de réplicas, l’appartenance d’un groupe de partitions est également dynamique : elle varie en fonction des opérations implicites de gestion des partitions physiques pour ajouter/supprimer de nouvelles partitions à/partir d’un jeu de partitions donné (par exemple, lorsque vous effectuez un scale-out du débit sur un conteneur, ajoutez/supprimez une région à votre base de données Azure Cosmos DB ou en cas d’échec). Chaque partition (d’un groupe de partitions) gérant l’appartenance au groupe de partitions à l’intérieur de son propre jeu de réplicas, l’appartenance est entièrement décentralisée et hautement disponible. Lors de la reconfiguration d’un groupe de partitions, la topologie de la superposition entre les partitions physiques est également établie. La topologie est sélectionnée de façon dynamique en fonction du niveau de cohérence, de la distance géographique et de la bande passante réseau disponible entre les partitions physiques source et cible.

Le service vous permet de configurer vos bases de données Azure Cosmos DB avec une ou plusieurs régions d’écriture. Selon le choix opéré, des groupes de partitions sont configurés pour accepter les écritures dans une région précise ou dans toutes les régions. Le système utilise un protocole consensuel imbriqué à deux niveaux. Un niveau opère à l’intérieur des réplicas d’un jeu de réplicas d’une partition physique acceptant les écritures, et l’autre opère au niveau d’un groupe de partitions pour fournir des garanties d’ordre complètes pour toutes les écritures validées à l’intérieur du groupe de partitions. Ce consensus imbriqué à plusieurs niveaux est vital pour l’implémentation de nos contrats SLA rigoureux en matière de haute disponibilité, ainsi que pour l’implémentation des modèles de cohérence qu’Azure Cosmos DB offre à ses clients.

Résolution de conflits

Notre conception de la propagation des mises à jour, de la résolution des conflits et du suivi de la causalité s’inspire de travaux antérieurs menés sur les algorithmes épidémiques et le système Bayou. Si les noyaux des idées ont survécu et offrent un cadre de référence commode pour communiquer la conception de système d’Azure Cosmos DB, ils ont également subi une transformation importante au fur et à mesure de leur application au système Azure Cosmos DB. Cela était nécessaire car les systèmes précédents n’étaient conçus ni avec la gouvernance des ressources, ni avec l’échelle à laquelle Azure Cosmos DB doit opérer, ni pour offrir les capacités (par exemple, la cohérence en fonction de l’obsolescence limitée) et les contrats SLA rigoureux et complets qu’Azure Cosmos DB offre à ses clients.

Rappelez-vous qu’un jeu de partitions est distribué dans plusieurs régions et suit le protocole de réplication d'Azure Cosmos DB (écritures multi-régionales) pour répliquer les données entre les partitions physiques constituant un jeu de partitions donné. Chaque partition physique (d’un groupe de partitions) accepte des écritures et sert des lectures, généralement aux clients locaux dans cette région. Les écritures acceptées par une partition physique à l’intérieur d’une région sont validées durablement et rendues hautement disponibles à l’intérieur de la partition physique avant d’être confirmées au client. Il s’agit d’écritures provisoires propagées à d’autres partitions physiques à l’intérieur du groupe de partitions à l’aide d’un canal anti-entropie. Les clients peuvent demander des écritures provisoires ou validées en transmettant un en-tête de requête. La propagation anti-entropie (y compris la fréquence de propagation) est dynamique, basée sur la topologie du groupe de partitions, la proximité régionale des partitions physiques et le niveau de cohérence configuré. À l’intérieur d’un groupe de partitions, Azure Cosmos DB suit un schéma de validation principal avec une partition arbitre sélectionnée de manière dynamique. La sélection de l’arbitre est dynamique et fait partie intégrante de la reconfiguration du jeu de partitions en fonction de la topologie de la superposition. Les écritures validées (dont les mises à jours de plusieurs lignes/par lots) sont garanties ordonnées.

Nous employons des horloges vectorielles codées (contenant un identificateur de région et des horloges logiques correspondant à chaque niveau de consensus respectivement du jeu de réplicas et du groupe de partitions) pour le suivi de la causalité et les vecteurs de version afin de détecter et résoudre les conflits de mises à jour. La topologie et l’algorithme de sélection de pair sont conçus pour assurer un stockage fixe minimal et une surcharge réseau minimale des vecteurs de version. L’algorithme garantit la propriété de convergence stricte.

Pour les bases de données Azure Cosmos DB configurées avec plusieurs régions d’écriture, le système offre des stratégies flexibles de résolution automatique des conflits parmi lesquelles les développeurs peuvent choisir, notamment :

  • Procédure Dernière écriture prioritaire (Last-Write-Wins/LWW) qui, par défaut, utilise une propriété timestamp définie par le système (basée sur le protocole d’horloge de synchronisation de l’heure). Azure Cosmos DB vous permet également de spécifier toute autre propriété numérique personnalisée à utiliser pour la résolution des conflits.
  • Stratégie (personnalisée) de résolution des conflits définie par l’application (exprimée via des procédures de fusion), conçue pour la réconciliation sémantique définie par l’application des conflits. Ces procédures sont appelées lors de la détection de conflits d’écriture-écriture sous les auspices d’une transaction de base de données côté serveur. Le système fournit exactement une garantie pour l’exécution d’une procédure de fusion dans le cadre du protocole d’engagement. Plusieurs échantillons de résolution des conflits sont à votre disposition.

Modèles de cohérence

Que vous ayez configuré votre base de données Azure Cosmos DB avec une ou plusieurs régions d’écriture, vous pouvez choisir parmi cinq modèles de cohérence bien définis. Ces modèles vont de la cohérence forte à la cohérence éventuelle, et affectent la façon dont les réplicas au sein des ensembles de partitions synchronisent les données.

Dans le contexte de la distribution mondiale :

  • L’obsolescence limitée utilise le protocole anti-entropie avec un débit limité, ce qui garantit que les préfixes ne s’accumulent pas et que les écritures ne sont pas limitées inutilement.
  • La cohérence de session garantit une lecture et une écriture unitones, la lecture de votre propre écriture, que l’écriture suive la lecture, ainsi qu’un préfixe cohérent, dans le monde entier.
  • Une cohérence forte nécessite une réplication synchrone entre les régions, ce qui signifie que les comptes d’écriture multirégion ne bénéficient pas d’une faible latence d’écriture ou d’une haute disponibilité en écriture lors de l’utilisation de ce niveau.

Pour plus d’informations sur la sémantique de niveau de cohérence et les garanties, consultez Niveaux de cohérence dans Azure Cosmos DB. Les modèles de cohérence sont également décrits mathématiquement à l’aide des spécifications TLA+.

Étapes suivantes

Découvrez ensuite comment configurer la distribution mondiale à l’aide les articles suivants :

  • Last updated on