• 2 min read

Azure Cosmos DB : repousser les limites des bases de données globalement distribuées

By Dharma Shukla, Founder of Azure Cosmos DB, Technical Fellow, Microsoft
Depuis sa création en 2010, en tant que base de données née dans le cloud, nous avons soigneusement pensé et conçu Azure Cosmos DB pour exploiter les trois propriétés fondamentales du cloud.

Depuis sa création en 2010, en tant que base de données née dans le cloud, nous avons soigneusement pensé et conçu Azure Cosmos DB pour exploiter les trois propriétés fondamentales du cloud :

  • Distribution globale grâce à la réplication multimaître transparente.
  • Extensibilité élastique du débit et du stockage dans le monde entier grâce au partitionnement horizontal.
  • Architecture mutualisée à granularité fine grâce à la pile système hautement régie par les ressources, de bout en bout, du moteur de base de données au protocole de réplication.

Cosmos DB compose ces trois propriétés d’une manière novatrice pour offrir une extensibilité élastique, tant des écritures que des lectures, partout dans le monde, avec une latence à un chiffre en millisecondes dans plus de 99 pour cent des cas, et une haute disponibilité de 99,999 %. Le service réplique vos données de manière transparente, et fournit une image système unique de votre base de données Cosmos globalement distribuée, avec un choix de cinq modèles de cohérence bien définis (spécifiés avec TLA+), pendant que vos utilisateurs écrivent et lisent dans des réplicas locaux distribués dans le monde entier. Depuis le lancement du service l’année dernière, sa croissance a justifié nos choix de conception et les compromis d’ingénierie uniques que nous avons faits.

Écritures ultra-rapides évolutives globalement

En tant que l’un des services fondamentaux d’Azure, Cosmos DB s’exécute par défaut dans chaque région Azure. Au moment de la rédaction du présent document, Cosmos DB opère dans plus de 50 régions géographiques, et des dizaines de milliers de clients ont configuré leurs bases de données Cosmos pour qu’elles soient répliquées globalement dans un nombre quelconque de ces régions.

Si nos clients utilisaient leurs bases de données Cosmos pour couvrir plusieurs régions, jusqu’à présent, ils ne pouvaient en désigner qu’une seule pour les écritures (et lectures), toutes les autres étant destinées aux lectures. Après avoir rigoureusement testé le service en exécutant des charges de travail internes de Microsoft pendant quelques années, nous sommes aujourd’hui extrêmement fiers d’annoncer que vous pourrez configurer vos bases de données Cosmos pour que celles-ci disposent de plusieurs régions d’écriture (configuration dite « multimaître »). Cette capacité, à son tour, vous apportera les avantages suivants :

  • Disponibilité de 99,999 % en écriture et en lecture dans le monde entier : en plus de la disponibilité pour la lecture de 99,999 %, Cosmos DB offre désormais une disponibilité pour l’écriture de 99,999 %, garantie par des contrats de niveau de service financiers.
  • Extensibilité élastique pour l’écriture et la lecture dans le monde entier : en plus des lectures, vous pouvez désormais mettre à l’échelle les écritures de façon élastique partout dans le monde. La livraison du débit que votre application configure sur un conteneur (ou une base de données) Cosmos DB est garantie dans toutes les régions, et adossée à des contrats de niveau de service assortis de pénalités financières.
  • Latences de lecture et d’écriture à un chiffre en millisecondes au 99ème centile, dans le monde entier : en plus de garantir des latences de lecture à un chiffre en millisecondes, Cosmos DB offre désormais une latence d’écriture inférieure à 10 millisecondes au 99e percentile, partout dans le monde, adossée à des contrats de niveau de service assortis de pénalités financières.
  • Multiples modèles de cohérence bien définis : le protocole de réplication de Cosmos DB est conçu pour offrir cinq modèles de cohérence bien définis, pratiques et intuitifs, permettant de créer facilement des applications correctes globalement distribuées. Nous avons également rendu disponibles les spécifications TLA+ de haut niveau pour les modèles de cohérence.
  • Extensibilité illimitée des points de terminaison : le protocole de réplication de Cosmos DB est conçu pour mettre à l’échelle de façon homogène des centaines de centres de données et des milliards d’appareils. L’architecture considère à égalité une région Azure ou un appareil de périmètre : tous deux sont capables d’héberger des réplicas DB Cosmos et d’intervenir en tant que véritables pairs dans le protocole de réplication multimaître.
  • MongoDB, Cassandra, SQL, Gremlin et Tables multimaîtres : en tant que base de données multimodèle et multi-API, Cosmos DB offre une prise en charge native compatible avec le protocole filaire pour les API SQL (Cosmos DB), Cassandra (CQL), MongoDB, Stockage Table et Gremlin. Avec Cosmos DB, vous pouvez disposer d’un service de base de données sans serveur entièrement géré, sécurisé, conforme, et économique pour vos applications MongoDB et Cassandra, une fois encore adossé à des contrats de niveau de service complets à la pointe du secteur. Les fonctionnalités répertoriées ci-dessus sont désormais disponibles pour toutes les API prises en charge par Cosmos DB, dont Cassandra, MongoDB, Gremlin, Stockage Table et SQL. Par exemple, vous pouvez désormais avoir une base de données MongoDB multimaître globalement distribuée ou une base de données de graphiques accessible Apache Gremlin, alimentées par Cosmos DB.

Décennies de recherche + Ingénierie rigoureuse = Cosmos DB

imageL’année dernière, lors du lancement de Cosmos DB, nous avons écrit une présentation technique de Cosmos DB, accompagnée d’une entrevue vidéo avec le lauréat du Turing Award, le Dr Leslie Lamport, décrivant les fondements techniques de Cosmos DB. Dans le droit fil de cette tradition, voici la nouvelle entrevue vidéo de Leslie décrivant l’évolution de l’architecture de Cosmos DB, l’application de TLA+ dans la conception de son protocole de réplication novateur, et la manière dont Cosmos DB a conjugué des décennies de recherche sur les systèmes distribués, de Paxos aux protocoles épidémiques, et son ingénierie de classe mondiale, pour vous permettre de créer des applications réellement à l’échelle du cosmos.

Ce blog explore un peu plus profondément l’architecture de distribution globale de Cosmos DB, notamment la nouvelle fonctionnalité permettant d’activer plusieurs régions d’écriture pour votre base de données Cosmos. Dans les sections suivantes, nous abordons le modèle du système pour la distribution mondiale de Cosmos DB, avec sa conception anti-entropie pour la mise à l’échelle des écritures à travers le monde.

Modèle du système pour la distribution globale

Cosmos DB étant un service fondamental d’Azure, il est déployé dans toutes les régions d’Azure du monde entier, dont les clouds publics, souverains, DoD et du secteur public. À l’intérieur d’un centre de données, nous déployons et gérons le service Cosmos DB sur des « tampons » massifs de machines, chacune avec un stockage local dédié. À l’intérieur d’un centre de données, Cosmos DB est déployé dans de nombreux clusters, chacun pouvant exécuter 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.

image

Figure 1 : topologie du système

La distribution globale dans Cosmos DB est une solution clé en main. À tout moment, en quelques clics (ou par programmation à l’aide d’un appel d’API), les clients peuvent ajouter (ou supprimer) un nombre illimité de régions géographiques associées à leur base de données Cosmos. Une base de données Cosmos comprend à son tour une série de conteneurs Cosmos. Dans Cosmos DB, les conteneurs font office d’unités logiques de distribution et d’extensibilité. Les collections, tables et graphiques que vous créez sont représentés (en interne) sous la forme de conteneurs Cosmos. Les conteneurs sont totalement indépendants du schéma et fournissent un espace pour les requêtes. Toutes les données d’un conteneur Cosmos sont automatiquement indexées lors de l’ingestion. Cela permet aux utilisateurs d’interroger les données sans devoir se préoccuper du schéma ou de la gestion d’index, en particulier dans une configuration globalement distribuée.

Comme le montre la figure 2, les données d’un conteneur sont distribuées en deux dimensions :

  • À l’intérieur d’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 de ressources sous-jacentes (distribution locale).
  • Chaque partition de ressources est également répliquée dans les différentes régions géographiques (distribution mondiale).

Quand une application utilisant Cosmos DB met à l’échelle le débit de façon élastique (ou consomme davantage de stockage) sur un conteneur Cosmos, Cosmos DB exécute de manière transparente les opérations de gestion des partitions (fractionnement, clonage, suppression, etc.) dans toutes les régions. Indépendamment de l’échelle, de la distribution ou des défaillances, Cosmos DB continue à fournir une image système unique des données à l’intérieur des conteneurs globalement distribués dans un nombre quelconque de régions.

image

Figure 2 : distribution de partitions de ressources en deux dimensions couvrant plusieurs régions du monde.

Physiquement, une partition de ressources 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 de ressources au sein d’un ensemble fixe de processus (voir Figure 1). Les réplicas correspondant aux partitions de ressources 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.

Un réplica n’appartient qu’à un seul client Cosmos DB. Chaque réplica héberge une instance du moteur de base de données de Cosmos DB, qui gère les ressources ainsi que les index associés. Le moteur de base de données de Cosmos DB opère sur un système type basé sur ARS1.  Le moteur ignore complètement le concept de schéma, et brouille la frontière entre la structure et les valeurs d’instance des enregistrements. 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 de Cosmos DB consiste en composants incluant l’implémentation de primitives de coordination, de 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. Pour assurer la durabilité et la haute disponibilité, le moteur de base de données conserve ses données et son index sur des disques SSD, et les réplique sur les instances de moteur de base de données à l’intérieur des jeux de réplicas. Les clients plus importants correspondent à une échelle plus élevée de débit et de stockage, et disposent de réplicas de plus grande capacité ou en plus grand nombre, voire des 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 basculement de thread superflu. 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. Notre moteur de base de données est conçu pour exploiter un accès concurrentiel de granularité fine, et fournir un débit élevé tout en opérant avec une quantité réduite de ressources système.

La distribution globale de Cosmos DB repose sur deux abstractions clés, les jeux de réplicas et les jeux de partitions. Un jeu de réplicas est un bloc modulaire utilisé pour la coordination, et un groupe de partitions est une superposition dynamique de partitions de ressources distribuées géographiquement. Pour comprendre le fonctionnement de la distribution globale, nous devons comprendre ces deux abstractions clés.

Jeux de réplicas – Blocs de coordination

Une partition de ressources 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 de ressources hautement disponibles, durables et fortement 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 de ressources donnée, nous appliquons deux idées. Premièrement, le coût du traitement des demandes d’écriture sur le leader est supérieur à celui de l’application des mises à jour à l’abonné. En conséquence, davantage de ressources système son budgétées pour le leader en comparaison des abonnés. 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 le leader pour servir les lectures, sauf si cela est absolument indispensable. Nous appliquons des idées issues de 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 Cosmos DB.

Groupes de partitions – Superpositions dynamiques distribuées géographiquement

Un groupe de partitions de ressources, une de chacune des régions configurées avec la base de données Cosmos, 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 de ressources gérant un ensemble de clés donné. Si une partition de ressources (c’est-à-dire 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 (Figures 2 et 3).

image

Figure 3 : un groupe de partitions est une superposition dynamique de partitions de ressources

Vous pouvez considérer un groupe 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. De façon similaire à un jeu de réplicas, l’appartenance à un groupe de partitions est dynamique. Elle varie en fonction des opérations de gestion de partition de ressources implicites pour ajouter/supprimer des partitions dans un ensemble de partitions donné (par exemple, quand vous augmentez le débit sur un conteneur, ajoutez/supprimez une région pour votre base de données Cosmos, en cas d’échec, etc.). Étant donné que chaque partition (d’un groupe de partitions) gère 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 de ressources 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 de ressources source et cible.

Le service vous permet de configurer vos bases de données Cosmos 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 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 de ressources 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 que Cosmos DB offre à ses clients.

Anti-entropie avec résolution des conflits flexible

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 de Cosmos DB, ils ont également subi une transformation importante au fur et à mesure de leur application au système 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 Cosmos DB doit opérer, ni pour offrir les capacités (par exemple, cohérence en fonction de l’obsolescence limitée) et les contrats SLA rigoureux et complets que Cosmos DB offre à les clients.

Rappelons qu’un groupe de partitions est distribué dans plusieurs régions et suit le protocole de réplication (multimaître) de Cosmos DB pour répliquer les données sur les partitions de ressources constituant un groupe de partitions donné. Chaque partition de ressources (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 de ressources à l’intérieur d’une région sont validées durablement et rendues hautement disponibles à l’intérieur de la partition de ressources avant d’être confirmées au client. Il s’agit d’écritures provisoires propagées à d’autres partitions de ressources à 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 demande. 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 de ressources et le niveau de cohérence configuré. À l’intérieur d’un groupe de partitions, 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 fait partie intégrante de la reconfiguration du groupe de partitions en fonction de la topologie de la superposition. Les écritures validées (dont les mises à plusieurs lignes/par lots) sont garanties totalement 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 Cosmos 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, à savoir :

  1. Stratégie Dernière écriture prioritaire (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). Cosmos DB vous permet également de spécifier toute autre propriété numérique personnalisée à utiliser pour la résolution des conflits.
  2. Stratégie personnalisée de résolution des conflits (exprimée via des procédures de fusion) définie par l’application, conçue pour la réconciliation de 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 sont à votre disposition.
  3. Types de données répliquées sans conflit (CRDT) en mode natif dans le système type (ARS) central de notre moteur de base de données. Cette stratégie permet la résolution automatique des conflits de manière transactionnelle et directement à l’intérieur du moteur de base de données dans le cadre du protocole d’engagement.

Cinq modèles de cohérence définis avec précision

Que vous configuriez votre base de données Cosmos avec une ou plusieurs régions d’écriture, vous pouvez utiliser cinq modèles de cohérence bien définis offerts par le service. En lien avec la prise en charge nouvellement ajoutée de l’activation de plusieurs régions d’écriture, voici quelques aspects remarquables des niveaux de cohérence :

Comme précédemment, la cohérence en fonction de l’obsolescence limitée garantit que toutes les lectures auront lieu dans les k préfixes ou t secondes suivant la dernière écriture dans toute région. De plus, les lectures avec cohérence en fonction de l’obsolescence limitée sont garanties unitones et assorties de garanties de préfixe cohérent. Le protocole anti-entropie opère avec une limite de débit, et garantit que les préfixes ne s’accumulent pas et que la contre-pression sur les écritures ne doive pas être appliquée. Comme précédemment, la cohérence de session garantit une lecture et une écriture unitones, RYOW, que l’écriture suive la lecture, et offre des garanties de préfixe cohérent dans le monde entier. Pour les bases de données configurées avec une cohérence forte, le système revient à une région d’écriture unique en désignant un leader au sein de chaque groupe de partitions.

Les sémantiques des cinq modèles de cohérence sont exposées ici, et décrites mathématiquement à l’aide d’une spécification TLA+ de haut niveau.

Conclusion

En tant que base de données globalement distribuée, Cosmos DB réplique de manière transparente vos données dans un nombre quelconque de régions Azure. Grâce à son architecture innovante de réplication multimaître entièrement décentralisée, vous pouvez mettre à l’échelle de façon élastique les écritures et lectures dans toutes les régions associées à votre base de données Cosmos. La capacité de mettre à l’échelle de façon élastique les écritures globalement en écrivant dans des réplicas locaux de leur base de données Cosmos partout dans le monde a été en développement ces dernières années. Nous sommes heureux que cette fonctionnalité soit désormais à la disposition de tous.

Accusés de réception

Le développement d’Azure Cosmos DB a commencé sous le nom de « Projet Florence » fin 2010, avant de prendre plus d’ampleur et de s’épanouir dans sa forme actuelle. Nos remerciements vont à toutes les équipes de Microsoft qui ont contribué à la robustesse d’Azure Cosmos DB, grâce à leur utilisation poussée du service au fil des années. Nous sommes juchés sur des épaules de géants, tant sont nombreuses les technologies sur lesquelles repose Azure Cosmos DB, dont Compute, Networking et Service Fabric. Et nous leur sommes reconnaissants pour ce soutien continu. Merci au Dr Leslie Lamport de nous avoir inspiré et d’avoir influencé notre approche de la conception des systèmes distribués. Nous sommes très reconnaissants envers nos clients qui se sont appuyés sur Cosmos DB pour créer leurs applications stratégiques, ont repoussé les limites du service, et ont toujours exigé l’excellence. Enfin, dernier point mais non des moindres, nous remercions tous les incroyables cosmonautes qui nous ont accompagnés pour leur engagement et leur attention.

  1. Des grammaires telles que JSON, BSON et CQL sont un strict sous-ensemble du système type ARS.

Depuis sa création en 2010, en tant que base de données née dans le cloud, nous avons soigneusement pensé et conçu Azure Cosmos DB pour exploiter les trois propriétés fondamentales du cloud :

Cosmos DB compose ces trois propriétés d’une manière novatrice pour offrir une extensibilité élastique, tant des écritures que des lectures, partout dans le monde, avec une latence à un chiffre en millisecondes dans plus de 99 pour cent des cas, et une haute disponibilité de 99,999 %. Le service réplique vos données de manière transparente, et fournit une image système unique de votre base de données Cosmos globalement distribuée, avec un choix de cinq modèles de cohérence bien définis (spécifiés avec TLA+), pendant que vos utilisateurs écrivent et lisent dans des réplicas locaux distribués dans le monde entier. Depuis le lancement du service l’année dernière, sa croissance a justifié nos choix de conception et les compromis d’ingénierie uniques que nous avons faits.

Écritures ultra-rapides évolutives globalement

En tant que l’un des services fondamentaux d’Azure, Cosmos DB s’exécute par défaut dans chaque région Azure. Au moment de la rédaction du présent document, Cosmos DB opère dans plus de 50 régions géographiques, et des dizaines de milliers de clients ont configuré leurs bases de données Cosmos pour qu’elles soient répliquées globalement dans un nombre quelconque de ces régions.

Si nos clients utilisaient leurs bases de données Cosmos pour couvrir plusieurs régions, jusqu’à présent, ils ne pouvaient en désigner qu’une seule pour les écritures (et lectures), toutes les autres étant destinées aux lectures. Après avoir rigoureusement testé le service en exécutant des charges de travail internes de Microsoft pendant quelques années, nous sommes aujourd’hui extrêmement fiers d’annoncer que vous pourrez configurer vos bases de données Cosmos pour que celles-ci disposent de plusieurs régions d’écriture (configuration dite « multimaître »). Cette capacité, à son tour, vous apportera les avantages suivants :

Décennies de recherche + Ingénierie rigoureuse = Cosmos DB

imageL’année dernière, lors du lancement de Cosmos DB, nous avons écrit une présentation technique de Cosmos DB, accompagnée d’une entrevue vidéo avec le lauréat du Turing Award, le Dr Leslie Lamport, décrivant les fondements techniques de Cosmos DB. Dans le droit fil de cette tradition, voici la nouvelle entrevue vidéo de Leslie décrivant l’évolution de l’architecture de Cosmos DB, l’application de TLA+ dans la conception de son protocole de réplication novateur, et la manière dont Cosmos DB a conjugué des décennies de recherche sur les systèmes distribués, de Paxos aux protocoles épidémiques, et son ingénierie de classe mondiale, pour vous permettre de créer des applications réellement à l’échelle du cosmos.

Ce blog explore un peu plus profondément l’architecture de distribution globale de Cosmos DB, notamment la nouvelle fonctionnalité permettant d’activer plusieurs régions d’écriture pour votre base de données Cosmos. Dans les sections suivantes, nous abordons le modèle du système pour la distribution mondiale de Cosmos DB, avec sa conception anti-entropie pour la mise à l’échelle des écritures à travers le monde.

Modèle du système pour la distribution globale

Cosmos DB étant un service fondamental d’Azure, il est déployé dans toutes les régions d’Azure du monde entier, dont les clouds publics, souverains, DoD et du secteur public. À l’intérieur d’un centre de données, nous déployons et gérons le service Cosmos DB sur des « tampons » massifs de machines, chacune avec un stockage local dédié. À l’intérieur d’un centre de données, Cosmos DB est déployé dans de nombreux clusters, chacun pouvant exécuter 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.

image

Figure 1 : topologie du système

La distribution globale dans Cosmos DB est une solution clé en main. À tout moment, en quelques clics (ou par programmation à l’aide d’un appel d’API), les clients peuvent ajouter (ou supprimer) un nombre illimité de régions géographiques associées à leur base de données Cosmos. Une base de données Cosmos comprend à son tour une série de conteneurs Cosmos. Dans Cosmos DB, les conteneurs font office d’unités logiques de distribution et d’extensibilité. Les collections, tables et graphiques que vous créez sont représentés (en interne) sous la forme de conteneurs Cosmos. Les conteneurs sont totalement indépendants du schéma et fournissent un espace pour les requêtes. Toutes les données d’un conteneur Cosmos sont automatiquement indexées lors de l’ingestion. Cela permet aux utilisateurs d’interroger les données sans devoir se préoccuper du schéma ou de la gestion d’index, en particulier dans une configuration globalement distribuée.

Comme le montre la figure 2, les données d’un conteneur sont distribuées en deux dimensions :

Quand une application utilisant Cosmos DB met à l’échelle le débit de façon élastique (ou consomme davantage de stockage) sur un conteneur Cosmos, Cosmos DB exécute de manière transparente les opérations de gestion des partitions (fractionnement, clonage, suppression, etc.) dans toutes les régions. Indépendamment de l’échelle, de la distribution ou des défaillances, Cosmos DB continue à fournir une image système unique des données à l’intérieur des conteneurs globalement distribués dans un nombre quelconque de régions.

image

Figure 2 : distribution de partitions de ressources en deux dimensions couvrant plusieurs régions du monde.

Physiquement, une partition de ressources 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 de ressources au sein d’un ensemble fixe de processus (voir Figure 1). Les réplicas correspondant aux partitions de ressources 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.

Un réplica n’appartient qu’à un seul client Cosmos DB. Chaque réplica héberge une instance du moteur de base de données de Cosmos DB, qui gère les ressources ainsi que les index associés. Le moteur de base de données de Cosmos DB opère sur un système type basé sur ARS1.  Le moteur ignore complètement le concept de schéma, et brouille la frontière entre la structure et les valeurs d’instance des enregistrements. 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 de Cosmos DB consiste en composants incluant l’implémentation de primitives de coordination, de 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. Pour assurer la durabilité et la haute disponibilité, le moteur de base de données conserve ses données et son index sur des disques SSD, et les réplique sur les instances de moteur de base de données à l’intérieur des jeux de réplicas. Les clients plus importants correspondent à une échelle plus élevée de débit et de stockage, et disposent de réplicas de plus grande capacité ou en plus grand nombre, voire des 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 basculement de thread superflu. 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. Notre moteur de base de données est conçu pour exploiter un accès concurrentiel de granularité fine, et fournir un débit élevé tout en opérant avec une quantité réduite de ressources système.

La distribution globale de Cosmos DB repose sur deux abstractions clés, les jeux de réplicas et les jeux de partitions. Un jeu de réplicas est un bloc modulaire utilisé pour la coordination, et un groupe de partitions est une superposition dynamique de partitions de ressources distribuées géographiquement. Pour comprendre le fonctionnement de la distribution globale, nous devons comprendre ces deux abstractions clés.

Jeux de réplicas – Blocs de coordination

Une partition de ressources 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 de ressources hautement disponibles, durables et fortement 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 de ressources donnée, nous appliquons deux idées. Premièrement, le coût du traitement des demandes d’écriture sur le leader est supérieur à celui de l’application des mises à jour à l’abonné. En conséquence, davantage de ressources système son budgétées pour le leader en comparaison des abonnés. 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 le leader pour servir les lectures, sauf si cela est absolument indispensable. Nous appliquons des idées issues de 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 Cosmos DB.

Groupes de partitions – Superpositions dynamiques distribuées géographiquement

Un groupe de partitions de ressources, une de chacune des régions configurées avec la base de données Cosmos, 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 de ressources gérant un ensemble de clés donné. Si une partition de ressources (c’est-à-dire 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 (Figures 2 et 3).

image

Figure 3 : un groupe de partitions est une superposition dynamique de partitions de ressources

Vous pouvez considérer un groupe 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. De façon similaire à un jeu de réplicas, l’appartenance à un groupe de partitions est dynamique. Elle varie en fonction des opérations de gestion de partition de ressources implicites pour ajouter/supprimer des partitions dans un ensemble de partitions donné (par exemple, quand vous augmentez le débit sur un conteneur, ajoutez/supprimez une région pour votre base de données Cosmos, en cas d’échec, etc.). Étant donné que chaque partition (d’un groupe de partitions) gère 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 de ressources 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 de ressources source et cible.

Le service vous permet de configurer vos bases de données Cosmos 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 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 de ressources 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 que Cosmos DB offre à ses clients.

Anti-entropie avec résolution des conflits flexible

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 de Cosmos DB, ils ont également subi une transformation importante au fur et à mesure de leur application au système 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 Cosmos DB doit opérer, ni pour offrir les capacités (par exemple, cohérence en fonction de l’obsolescence limitée) et les contrats SLA rigoureux et complets que Cosmos DB offre à les clients.

Rappelons qu’un groupe de partitions est distribué dans plusieurs régions et suit le protocole de réplication (multimaître) de Cosmos DB pour répliquer les données sur les partitions de ressources constituant un groupe de partitions donné. Chaque partition de ressources (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 de ressources à l’intérieur d’une région sont validées durablement et rendues hautement disponibles à l’intérieur de la partition de ressources avant d’être confirmées au client. Il s’agit d’écritures provisoires propagées à d’autres partitions de ressources à 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 demande. 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 de ressources et le niveau de cohérence configuré. À l’intérieur d’un groupe de partitions, 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 fait partie intégrante de la reconfiguration du groupe de partitions en fonction de la topologie de la superposition. Les écritures validées (dont les mises à plusieurs lignes/par lots) sont garanties totalement 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 Cosmos 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, à savoir :

  1. Stratégie Dernière écriture prioritaire (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). Cosmos DB vous permet également de spécifier toute autre propriété numérique personnalisée à utiliser pour la résolution des conflits.
  2. Stratégie personnalisée de résolution des conflits (exprimée via des procédures de fusion) définie par l’application, conçue pour la réconciliation de 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 sont à votre disposition.
  3. Types de données répliquées sans conflit (CRDT) en mode natif dans le système type (ARS) central de notre moteur de base de données. Cette stratégie permet la résolution automatique des conflits de manière transactionnelle et directement à l’intérieur du moteur de base de données dans le cadre du protocole d’engagement.

Cinq modèles de cohérence définis avec précision

Que vous configuriez votre base de données Cosmos avec une ou plusieurs régions d’écriture, vous pouvez utiliser cinq modèles de cohérence bien définis offerts par le service. En lien avec la prise en charge nouvellement ajoutée de l’activation de plusieurs régions d’écriture, voici quelques aspects remarquables des niveaux de cohérence :

Comme précédemment, la cohérence en fonction de l’obsolescence limitée garantit que toutes les lectures auront lieu dans les k préfixes ou t secondes suivant la dernière écriture dans toute région. De plus, les lectures avec cohérence en fonction de l’obsolescence limitée sont garanties unitones et assorties de garanties de préfixe cohérent. Le protocole anti-entropie opère avec une limite de débit, et garantit que les préfixes ne s’accumulent pas et que la contre-pression sur les écritures ne doive pas être appliquée. Comme précédemment, la cohérence de session garantit une lecture et une écriture unitones, RYOW, que l’écriture suive la lecture, et offre des garanties de préfixe cohérent dans le monde entier. Pour les bases de données configurées avec une cohérence forte, le système revient à une région d’écriture unique en désignant un leader au sein de chaque groupe de partitions.

Les sémantiques des cinq modèles de cohérence sont exposées ici, et décrites mathématiquement à l’aide d’une spécification TLA+ de haut niveau.

Conclusion

En tant que base de données globalement distribuée, Cosmos DB réplique de manière transparente vos données dans un nombre quelconque de régions Azure. Grâce à son architecture innovante de réplication multimaître entièrement décentralisée, vous pouvez mettre à l’échelle de façon élastique les écritures et lectures dans toutes les régions associées à votre base de données Cosmos. La capacité de mettre à l’échelle de façon élastique les écritures globalement en écrivant dans des réplicas locaux de leur base de données Cosmos partout dans le monde a été en développement ces dernières années. Nous sommes heureux que cette fonctionnalité soit désormais à la disposition de tous.

Accusés de réception

Le développement d’Azure Cosmos DB a commencé sous le nom de « Projet Florence » fin 2010, avant de prendre plus d’ampleur et de s’épanouir dans sa forme actuelle. Nos remerciements vont à toutes les équipes de Microsoft qui ont contribué à la robustesse d’Azure Cosmos DB, grâce à leur utilisation poussée du service au fil des années. Nous sommes juchés sur des épaules de géants, tant sont nombreuses les technologies sur lesquelles repose Azure Cosmos DB, dont Compute, Networking et Service Fabric. Et nous leur sommes reconnaissants pour ce soutien continu. Merci au Dr Leslie Lamport de nous avoir inspiré et d’avoir influencé notre approche de la conception des systèmes distribués. Nous sommes très reconnaissants envers nos clients qui se sont appuyés sur Cosmos DB pour créer leurs applications stratégiques, ont repoussé les limites du service, et ont toujours exigé l’excellence. Enfin, dernier point mais non des moindres, nous remercions tous les incroyables cosmonautes qui nous ont accompagnés pour leur engagement et leur attention.

  1. Des grammaires telles que JSON, BSON et CQL sont un strict sous-ensemble du système type ARS.