Considérations relatives à la plateforme de données pour les charges de travail stratégiques sur Azure

La sélection d’une plateforme de données d’application efficace est un autre domaine de décision crucial, qui a de profondes implications dans d’autres domaines de conception. Azure offre en fin de compte une multitude de plateformes de données relationnelles, non relationnelles et analytiques, qui diffèrent considérablement en termes de capacité. Il est donc essentiel que les exigences non fonctionnelles clés soient pleinement prises en compte en même temps que d’autres facteurs de décision tels que la cohérence, l’opérabilité, le coût et la complexité. Par exemple, la capacité à fonctionner dans une configuration d’écriture multirégion aura un impact critique sur l’adéquation à une plateforme disponible dans le monde entier.

Cette zone de conception s’étend sur la conception de l’application, en fournissant des considérations et des recommandations clés pour guider la sélection d’une plateforme de données optimale.

Important

Cet article fait partie de la série de charges de travail stratégiques Azure Well-Architected . Si vous n’êtes pas familiarisé avec cette série, nous vous recommandons de commencer par ce qui est une charge de travail stratégique ?

Les quatre vs du Big Data

Les « quatre vs du Big Data » fournissent une infrastructure permettant de mieux comprendre les caractéristiques requises pour une plateforme de données hautement disponible et la façon dont les données peuvent être utilisées pour optimiser la valeur de l’entreprise. Cette section explore donc comment les caractéristiques Volume, Velocity, Variety et Veracity peuvent être appliquées au niveau conceptuel pour aider à concevoir une plateforme de données à l’aide des technologies de données appropriées.

• olume V: quantité de données entrantes pour informer les exigences en matière de capacité de stockage et de hiérarchisation, c’est-à-dire la taille du jeu de données.
• Elocity V: la vitesse à laquelle les données sont traitées, soit sous forme de lots, soit de flux continus, c’est-à-dire le débit de flux.
• Ariety V: la organization et le format des données, la capture de formats structurés, semi-structurés et non structurés, c’est-à-dire les données sur plusieurs magasins ou types.
• Eracity V: inclut la provenance et la conservation des jeux de données considérés pour la gouvernance et l’assurance de la qualité des données, c’est-à-dire la précision des données.

Remarques sur la conception

Volume

• Volumes de données existants (le cas échéant) et prévus à l’avenir en fonction des taux de croissance des données prévus alignés sur les objectifs et les plans de l’entreprise.

  • Le volume de données doit englober les données proprement dites et les index, les journaux, les données de télémétrie et d’autres jeux de données applicables.
  • En règle générale, les grandes applications vitales pour l’entreprise et stratégiques génèrent et stockent des volumes élevés (exprimés en Go et To) tous les jours.
  • L’extension des données peut avoir d’importantes conséquences sur les coûts.

• Le volume de données peut fluctuer en raison de l’évolution des circonstances métier ou des procédures de nettoyage.

• Le volume de données peut avoir un impact profond sur les performances des requêtes de la plateforme de données.

• Atteindre les limites du volume de la plateforme de données peut avoir un impact important.

  • Cela entraînera-t-il un temps d’arrêt ? et si oui, pendant combien de temps ?
  • Quelles sont les procédures d’atténuation ? et l’atténuation nécessite-t-elle des modifications d’application ?
  • Y aura-t-il un risque de perte de données ?

• Des fonctionnalités comme la durée de vie (TTL) peuvent permettre de gérer la croissance des données en supprimant automatiquement les enregistrements à l’issue d’un délai écoulé, en créant ou en modifiant des enregistrements.

  • Par exemple, Azure Cosmos DB fournit une fonctionnalité TTL intégrée.

Vélocité

• La vitesse à laquelle les données sont émises à partir de différents composants d’application et les exigences de débit pour la rapidité de validation et de récupération des données sont essentielles pour déterminer une technologie de données optimale pour les scénarios de charge de travail clés.

  • La nature des exigences de débit diffère selon les scénarios de charge de travail, tels que ceux qui sont lourds en lecture ou en écriture.
    • Par exemple, les charges de travail analytiques doivent généralement répondre à un débit de lecture important.
  • Quel est le débit requis ? Et comment le débit devrait-il augmenter ?
  • Quelles sont les exigences de latence des données à P50/P99 sous les niveaux de charge de référence ?

• Des fonctionnalités telles que la prise en charge d’une conception sans verrou, le réglage des index et les stratégies de cohérence sont essentielles pour atteindre un débit élevé.

  • L’optimisation de la configuration pour le haut débit entraîne des compromis, qui doivent être entièrement compris.
  • Les modèles de persistance et de messagerie de niveau de charge, tels que CQRS et Event Sourcing, peuvent être utilisés pour optimiser davantage le débit.

• Les niveaux de charge fluctuent naturellement dans de nombreux scénarios d’application, avec des pics naturels qui demandent un degré d’élasticité suffisant pour gérer la demande variable tout en préservant le débit et la latence.

  • La scalabilité agile est essentielle à une prise en charge efficace de niveaux de débit et de charge variables sans surapprovisionner les niveaux de capacité.
    • Le débit de lecture et d’écriture doit être mis à l’échelle en fonction des exigences et de la charge d’application.
    • Les opérations de mise à l’échelle verticale et horizontale peuvent être appliquées pour répondre à l’évolution des niveaux de charge.

• L’impact des baisses de débit peut varier en fonction du scénario de charge de travail.

  • Y aura-t-il une interruption de connectivité ?
  • Les opérations individuelles retourneront-t-elle des codes d’échec pendant que le plan de contrôle continue de fonctionner ?
  • La plateforme de données active-t-elle la limitation et, si c’est le cas, pendant combien de temps ?

• La recommandation fondamentale de conception d’application pour utiliser une distribution géographique active-active présente des défis en matière de cohérence des données.

  • Il existe un compromis entre la cohérence et les performances en ce qui concerne la sémantique transactionnelle ACID complète et le comportement de verrouillage traditionnel.
    • La réduction de la latence d’écriture se fera au détriment de la cohérence des données.

• Dans une configuration d’écriture multirégion, les modifications devront être synchronisées et fusionnées entre tous les réplicas, avec la résolution des conflits si nécessaire, ce qui peut avoir un impact sur les niveaux de performances et la scalabilité.

• Les réplicas en lecture seule (intra-région et interrégion) peuvent être utilisés pour réduire la latence aller-retour et la distribution du trafic afin d’améliorer les performances, le débit, la disponibilité et la scalabilité.

• Une couche de mise en cache peut être utilisée pour augmenter le débit de lecture afin d’améliorer l’expérience utilisateur et les temps de réponse du client de bout en bout.

  • Les délais d’expiration du cache et les stratégies doivent être pris en compte pour optimiser la recentité des données.

Variété

• Le modèle de données, les types de données, les relations de données et le modèle de requête prévu vont fortement affecter les décisions concernant la plateforme de données.

  • L’application nécessite-t-elle un modèle de données relationnelles ou peut-elle prendre en charge un modèle de données variable ou non relationnel ?
  • Comment l’application interroge-t-elle les données ? Et les requêtes dépendent-elles de concepts de couche de base de données tels que les jointures relationnelles ? Ou l’application fournit-elle une telle sémantique ?

• La nature des jeux de données considérés par l’application peut être variée, du contenu non structuré comme des images et des vidéos, ou des fichiers plus structurés tels que CSV et Parquet.

  • Les charges de travail d’application composites ont généralement des jeux de données distincts et des exigences associées.

• En plus des plateformes de données relationnelles ou non relationnelles, les plateformes de données de graphe ou de clé-valeur peuvent également convenir à certaines charges de travail de données.

  • Certaines technologies s’adressent aux modèles de données à schéma variable, où les éléments de données sont sémantiquement similaires et/ou stockés et interrogés ensemble, mais diffèrent structurellement.

• Dans une architecture de microservice, des services d’application individuels peuvent être créés avec des magasins de données distincts optimisés pour les scénarios plutôt que de dépendre d’un seul magasin de données monolithique.

  • Des modèles de conception tels que SAGA peuvent être appliqués pour gérer la cohérence et les dépendances entre différents magasins de données.
    • Les requêtes directes inter-bases de données peuvent imposer des contraintes de co-emplacement.
  • L’utilisation de plusieurs technologies de données ajoutera une certaine surcharge de gestion pour maintenir les technologies englobantes.

• Les ensembles de fonctionnalités de chaque service Azure diffèrent selon les langages, les SDK et les API, ce qui peut avoir un impact considérable sur le niveau de paramétrage de la configuration qui peut être appliqué.

• Les fonctionnalités d’alignement optimisé avec le modèle de données et les types de données inclus influencent fortement les décisions de la plateforme de données.

  • Couches de requête telles que les procédures stockées et les mappeurs relationnels d’objet.
  • Fonctionnalité de requête indépendante du langage, telle qu’une couche d’API REST sécurisée.
  • Fonctionnalités de continuité d’activité, telles que la sauvegarde et la restauration.

• Les magasins de données analytiques prennent généralement en charge le stockage polyglotte pour différents types de structures de données.

  • Les environnements d’exécution analytique, tels qu’Apache Spark, peuvent avoir des restrictions d’intégration pour analyser les structures de données polyglottes.

• Dans un contexte d’entreprise, l’utilisation de processus et d’outils existants, ainsi que la continuité des compétences, peuvent avoir une incidence significative sur la conception de la plateforme de données et la sélection des technologies de données.

Véracité

• Plusieurs facteurs doivent être pris en compte pour valider l’exactitude des données au sein d’une application, et la gestion de ces facteurs peut avoir une incidence significative sur la conception de la plateforme de données.

  • Cohérence des données.
  • Fonctionnalités de sécurité de la plateforme.
  • Gouvernance des données.
  • Gestion des modifications et évolution des schémas.
  • Dépendances entre les jeux de données.

• Dans toute application distribuée avec plusieurs réplicas de données, il existe un compromis entre cohérence et latence, comme indiqué dans les théorèmes CAP et PACELC .

  • Lorsque les lecteurs et les rédacteurs sont distribués séparément, une application doit choisir de retourner soit la version la plus disponible d’un élément de données, même si celle-ci est obsolète par rapport à une écriture (mise à jour) de cet élément de données qui vient de se terminer dans un autre réplica, ou la version la plus à jour de l’élément de données, ce qui peut entraîner une latence supplémentaire pour déterminer et obtenir l’état le plus récent.
  • La cohérence et la disponibilité peuvent être configurées au niveau de la plateforme ou au niveau de la demande de données individuelle.
  • Quelle est l’expérience utilisateur si les données doivent être traitées à partir d’un réplica le plus proche de l’utilisateur qui ne reflète pas l’état le plus récent d’un autre réplica ? par exemple, l’application peut-elle prendre en charge la distribution de données obsolètes ?

• Dans un contexte d’écriture multirégion, quand le même élément de données est modifié dans deux réplicas d’écriture distincts avant que l’une ou l’autre modification puisse être répliquée, un conflit est créé qui doit être résolu.

  • Des stratégies de résolution des conflits standardisées, telles que « Last Write Wins », ou une stratégie personnalisée avec une logique personnalisée peuvent être appliquées.

• L’implémentation des exigences de sécurité peut avoir un impact négatif sur le débit ou les performances.

• Le chiffrement au repos peut être implémenté dans la couche application à l’aide du chiffrement côté client et/ou de la couche de données à l’aide du chiffrement côté serveur si nécessaire.

• Azure prend en charge différents modèles de chiffrement, notamment le chiffrement côté serveur qui utilise des clés gérées par le service, des clés gérées par le client dans Key Vault ou des clés gérées par le client sur du matériel contrôlé par le client.

  • Avec le chiffrement côté client, les clés peuvent être gérées dans Key Vault ou un autre emplacement sécurisé.

• Le chiffrement de liaison de données MACsec (IEEE 802.1AE MAC) est utilisé pour sécuriser tout le trafic se déplaçant entre les centres de données Azure sur le réseau principal Microsoft.

  • Les paquets sont chiffrés et déchiffrés sur les appareils avant d’être envoyés, ce qui empêche les attaques physiques de type « man-in-the-middle » ou snooping/wiretapping.

• Authentification et autorisation du plan de données et du plan de contrôle.

  • Comment la plateforme de données authentifie-t-elle et autorise-t-elle l’accès aux applications et l’accès opérationnel ?

• Observabilité grâce à la surveillance de l’intégrité de la plateforme et de l’accès aux données.

  • Comment l’alerte sera-t-elle appliquée pour les conditions en dehors des limites opérationnelles acceptables ?

Recommandations relatives à la conception

Volume

• Assurez-vous que les volumes de données futurs associés à la croissance organique ne devraient pas dépasser les capacités de la plateforme de données.

  • Prévoyez des taux de croissance des données en phase avec les plans d’entreprise et utilisez des taux établis pour éclairer sur les besoins en capacité continus.
  • Comparez les volumes d’enregistrements agrégés et par données aux limites de la plateforme de données.
  • Si un risque existe que les limites soient atteintes dans des circonstances exceptionnelles, veillez à mettre en place des atténuations opérationnelles pour éviter les temps d’arrêt et une perte de données.

• Surveillez le volume de données et vérifiez-le par rapport à un modèle de capacité, en tenant compte des limites d’échelle et des taux de croissance des données attendus.

  • Assurez-vous que les opérations de mise à l’échelle s’alignent sur les exigences de stockage, de performances et de cohérence.
  • Lorsqu’une nouvelle unité d’échelle est introduite, les données sous-jacentes peuvent devoir être répliquées, ce qui prendra du temps et entraînera probablement une pénalité de performances pendant la réplication. Assurez-vous donc que ces opérations sont effectuées en dehors des heures d’ouverture critiques si possible.

• Définissez des niveaux de données d’application pour classifier les jeux de données en fonction de l’utilisation et de la criticité afin de faciliter la suppression ou le déchargement des données plus anciennes.

  • Envisagez de classer les jeux de données en niveaux « chaud », « chaud » et « froid » (archive).
    • Par exemple, les implémentations de référence fondamentales utilisent Azure Cosmos DB pour stocker des données « chaudes » qui sont activement utilisées par l’application, tandis que stockage Azure est utilisé pour les données d’opérations « froides » à des fins analytiques.

• Configurez des procédures d’entretien pour optimiser la croissance des données et améliorer l’efficacité des données, telles que les performances des requêtes et la gestion de l’expansion des données.

  • Configurez l’expiration de durée de vie (TTL) pour les données qui ne sont plus requises et qui n’ont pas de valeur analytique à long terme.
    • Vérifiez que les anciennes données peuvent être hiérarchisées en toute sécurité dans le stockage secondaire, voire supprimées purement et simplement, sans impact négatif sur l’application.
  • Déchargez les données non critiques dans un stockage froid secondaire, mais conservez-les à des fins analytiques et pour répondre aux besoins d’audit.
  • Collecter des statistiques de télémétrie et d’utilisation de la plateforme de données pour permettre aux équipes DevOps d’évaluer en permanence les exigences d’entretien et les magasins de données de taille appropriée.

• En ligne avec une conception d’application de microservice, envisagez l’utilisation de plusieurs technologies de données différentes en parallèle, avec des solutions de données optimisées pour des scénarios de charge de travail spécifiques et des besoins en volume.

  • Évitez de créer un magasin de données monolithique unique où il peut être difficile de gérer le volume de données résultant de la croissance.

Vélocité

• La plateforme de données doit par nature être conçue et configurée pour prendre en charge le haut débit, avec des charges de travail séparées dans différents contextes pour optimiser les performances à l’aide de solutions de données optimisées pour les scénarios.

  • Vérifiez que le débit de lecture et d’écriture pour chaque scénario de données peut être mis à l’échelle en fonction des modèles de charge attendus, avec une tolérance suffisante pour les écarts imprévus.
  • Séparez les différentes charges de travail de données, telles que les opérations transactionnelles et analytiques, en contextes de performances distincts.

• Niveau de charge via l’utilisation d’une messagerie asynchrone non bloquante, par exemple à l’aide des modèles CQRS ou Event Sourcing .

  • Il peut y avoir une latence entre les demandes d’écriture et le moment où de nouvelles données sont disponibles pour la lecture, ce qui peut avoir un impact sur l’expérience utilisateur.
    • Cet impact doit être compris et acceptable dans le contexte des exigences métier clés.

• Assurez l’extensibilité agile pour prendre en charge des niveaux de débit et de charge variables.

  • Si les niveaux de charge sont très volatiles, envisagez de surprovisionner les niveaux de capacité pour garantir le maintien du débit et des performances.
  • Testez et validez l’impact sur les charges de travail d’application composites lorsque le débit ne peut pas être maintenu.

• Donnez la priorité aux services de données natifs Azure avec des opérations de mise à l’échelle automatisées pour apporter une réponse rapide à la volatilité de la charge.

  • Configurez la mise à l’échelle automatique en fonction des seuils internes au service et des seuils définis par l’application.
  • La mise à l’échelle doit commencer et se terminer dans des délais conformes aux exigences de l’entreprise.
  • Pour les scénarios où une interaction manuelle est nécessaire, établissez des « playbooks » opérationnels automatisés qui peuvent être déclenchés au lieu d’effectuer des actions opérationnelles manuelles.
    • Déterminez si des déclencheurs automatisés peuvent être appliqués dans le cadre d’investissements d’ingénierie ultérieurs.

• Surveillez le débit de lecture et d’écriture des données d’application par rapport aux exigences de latence P50/P99 et alignez-les sur un modèle de capacité d’application.

• Le débit excédentaire doit être géré de manière appropriée par la plateforme de données ou la couche d’application et capturé par le modèle d’intégrité pour la représentation opérationnelle.

• Implémentez la mise en cache pour les scénarios de données « chauds » afin de réduire les temps de réponse.

  • Appliquez des stratégies appropriées pour l’expiration du cache et la conservation de la maison afin d’éviter la croissance des données galopante.
    • Expirer les éléments du cache lorsque les données de stockage changent.
    • Si l’expiration du cache est strictement basée sur la durée de vie (TTL), l’impact et l’expérience client de la distribution de données obsolètes doivent être compris.

Variété

• Conformément au principe d’une conception cloud et native Azure, il est vivement recommandé de hiérarchiser les services Azure managés afin de réduire la complexité opérationnelle et de gestion, et de tirer parti des futurs investissements de Microsoft dans la plateforme.

• Conformément au principe de conception d’application des architectures de microservice faiblement couplés, autorisez les services individuels à utiliser des magasins de données distincts et des technologies de données optimisées pour les scénarios.

  • Identifiez les types de structure de données que l’application gérera pour les scénarios de charge de travail spécifiques.
  • Évitez de créer une dépendance vis-à-vis d’un magasin de données monolithique unique.
    • Considérez le modèle de conception SAGA où il existe des dépendances entre les magasins de données.

• Vérifiez que les capacités nécessaires sont disponibles pour les technologies de données sélectionnées.

  • Assurer la prise en charge des langages et des fonctionnalités du KIT de développement logiciel (SDK) requis. Toutes les fonctionnalités ne sont pas disponibles de la même manière pour chaque langue/KIT de développement logiciel (SDK).

Véracité

• Adoptez une plateforme de données multirégion et répartissez les réplicas entre les régions pour bénéficier d’une fiabilité, d’une disponibilité et de performances optimales en rapprochant les données des points de terminaison d’application.

  • Distribuer des réplicas de données entre Zones de disponibilité (AZ) au sein d’une région (ou utiliser des niveaux de service redondants interzones) pour optimiser la disponibilité intrarégion.

• Lorsque les exigences de cohérence le permettent, utilisez une conception de plateforme de données d’écriture multirégion pour optimiser la disponibilité et la fiabilité globales.

  • Tenez compte des exigences métier pour la résolution des conflits lorsque le même élément de données est modifié dans deux réplicas d’écriture distincts avant que l’une ou l’autre modification ne puisse être répliquée et créer ainsi un conflit.
    • Utiliser des stratégies de résolution des conflits standardisées telles que « Le dernier gagne » dans la mesure du possible
      • Si une stratégie personnalisée avec une logique personnalisée est requise, assurez-vous que les pratiques DevOps CI/CD sont appliquées pour gérer la logique personnalisée.

• Testez et validez les fonctionnalités de sauvegarde et de restauration, ainsi que les opérations de basculement par le biais de tests de chaos dans les processus de livraison continus.

• Exécutez des benchmarks de performances pour vous assurer que les exigences de débit et de performances ne sont pas affectées par l’inclusion des fonctionnalités de sécurité requises, telles que le chiffrement.

  • Assurez-vous que les processus de livraison continue prennent en compte le test de charge par rapport à des benchmarks de performances connus.

• Lors de l’application du chiffrement, il est vivement recommandé d’utiliser des clés de chiffrement gérées par le service dans le but de réduire la complexité de gestion.

  • S’il existe une condition de sécurité spécifique à remplir pour les clés gérées par le client, veillez à ce que des procédures de gestion de clés appropriées soient appliquées pour garantir la disponibilité, la sauvegarde et la rotation de toutes les clés en question.

Notes

Lors de l’intégration à une implémentation organisationnelle plus large, il est essentiel qu’une approche centrée sur l’application soit appliquée pour l’approvisionnement et le fonctionnement des composants de la plateforme de données dans une conception d’application.

Plus spécifiquement, pour optimiser la fiabilité, il est essentiel que les composants de la plateforme de données individuels répondent de manière appropriée à l’intégrité de l’application par le biais d’actions opérationnelles qui peuvent inclure d’autres composants d’application. Par exemple, dans un scénario où des ressources supplémentaires de la plateforme de données sont nécessaires, la mise à l’échelle de la plateforme de données avec d’autres composants d’application en fonction d’un modèle de capacité sera probablement nécessaire, éventuellement via la fourniture d’unités de mise à l’échelle supplémentaires. Cette approche sera finalement limitée s’il existe une dépendance matérielle d’une équipe d’opérations centralisée pour résoudre les problèmes liés à la plateforme de données en isolement.

En fin de compte, l’utilisation de services de données centralisés (c’est-à-dire central it DBaaS) introduit des goulots d’étranglement opérationnels qui entravent considérablement l’agilité grâce à une expérience de gestion largement noncontextualisée, et doivent être évités dans un contexte stratégique ou critique pour l’entreprise.

Références supplémentaires

Des conseils supplémentaires sur la plateforme de données sont disponibles dans le Guide de l’architecture Azure Application.

• Arbre de décision Azure Data Store
• Critères de choix d’un magasin de données
• Magasins de données non relationnelles
• Magasins de données OLTP relationnels

Magasin de données d’écriture multirégion distribué à l’échelle mondiale

Pour répondre pleinement aux aspirations actives et actives distribuées à l’échelle mondiale d’une conception d’application, il est vivement recommandé d’envisager une plateforme d’écriture de données distribuées multirégions, où les modifications apportées à des réplicas distincts pouvant être écrits sont synchronisées et fusionnées entre tous les réplicas, avec la résolution des conflits si nécessaire.

Important

Les microservices ne nécessitant pas tous un magasin de données d’écriture multirégion distribué, il faut donc tenir compte du contexte architectural et des exigences métier de chaque scénario de charge de travail.

Azure Cosmos DB fournit un magasin de données NoSQL distribué à l’échelle mondiale et hautement disponible, offrant des écritures multirégions et une cohérence ajustable prête à l’emploi. Les considérations et recommandations de conception de cette section se concentrent donc sur une utilisation optimale d’Azure Cosmos DB.

Considérations en matière de conception

Azure Cosmos DB

• Azure Cosmos DB stocke les données dans des conteneurs, qui sont des magasins transactionnels indexés et basés sur des lignes conçus pour permettre des lectures et des écritures transactionnelles rapides avec des temps de réponse de l’ordre de millisecondes.

• Azure Cosmos DB prend en charge plusieurs API différentes avec différents ensembles de fonctionnalités, tels que SQL, Cassandra et MongoDB.

  • Azure Cosmos DB for NoSQL de première partie fournit l’ensemble de fonctionnalités le plus riche et est généralement l’API où les nouvelles fonctionnalités seront disponibles en premier.

• Azure Cosmos DB prend en charge les modes de connectivité passerelle et direct, où Direct facilite la connectivité via TCP aux nœuds Azure Cosmos DB réplica back-end pour améliorer les performances avec moins de tronçons réseau, tandis que la passerelle fournit une connectivité HTTPS aux nœuds de passerelle front-end.

  • Le mode direct n’est disponible que lors de l’utilisation d’Azure Cosmos DB pour NoSQL et n’est actuellement pris en charge que sur les plateformes sdk .NET et Java.

• Dans les régions avec zone de disponibilité, Azure Cosmos DB offre une prise en charge de la redondance des zones de disponibilité (AZ) pour la haute disponibilité et la résilience aux défaillances zonales au sein d’une région.

• Azure Cosmos DB gère quatre réplicas de données au sein d’une même région et, lorsque la redondance de zone de disponibilité (AZ) est activée, Azure Cosmos DB garantit que les réplicas de données sont placés sur plusieurs AZ pour vous protéger contre les défaillances zonales.

  • Le protocole de consensus Paxos est appliqué pour obtenir le quorum entre les réplicas au sein d’une région.

• Un compte Azure Cosmos DB peut facilement être configuré pour répliquer des données dans plusieurs régions afin d’atténuer le risque d’indisponibilité d’une seule région.

  • La réplication peut être configurée avec des écritures à une seule région ou des écritures multirégions.
    • Avec les écritures dans une seule région, une région « hub » principale est utilisée pour traiter toutes les écritures et si cette région « hub » devient indisponible, une opération de basculement doit se produire pour promouvoir une autre région comme accessible en écriture.
    • Avec les écritures multirégions, les applications peuvent écrire dans n’importe quelle région de déploiement configurée, ce qui répliquera les modifications entre toutes les autres régions. Si une région n’est pas disponible, les régions restantes seront utilisées pour traiter le trafic d’écriture.

• Dans une configuration d’écriture multirégion, des conflits de mise à jour (insérer, remplacer, supprimer) peuvent se produire lorsque les rédacteurs mettent à jour simultanément le même élément dans plusieurs régions.

• Azure Cosmos DB fournit deux stratégies de résolution des conflits, qui peuvent être appliquées pour résoudre automatiquement les conflits.

  • Last Write Wins (LWW) applique un protocole d’horloge de synchronisation de temps à l’aide d’une propriété d’horodatage _ts définie par le système comme chemin de résolution des conflits. Si d’un conflit, l’élément ayant la valeur la plus élevée pour le chemin de résolution de conflit devient gagnant, et si plusieurs éléments ont la même valeur numérique, le système sélectionne un gagnant afin que toutes les régions puissent converger vers la même version de l’élément engagé.
    • Avec les conflits de suppression, la version supprimée gagne toujours sur les conflits d’insertion ou de remplacement, quelle que soit la valeur du chemin de résolution des conflits.
    • La stratégie Dernière écriture prioritaire (LWW) est la stratégie de résolution de conflit par défaut.
    • Lors de l’utilisation d’Azure Cosmos DB pour NoSQL, une propriété numérique personnalisée telle qu’une définition d’horodatage personnalisé peut être utilisée pour la résolution des conflits.
  • Les stratégies de résolution personnalisées permettent à la sémantique définie par l’application de rapprocher les conflits à l’aide d’une procédure stockée de fusion inscrite qui est appelée automatiquement lorsque des conflits sont détectés.
    • Le système fournit exactement une garantie pour l’exécution d’une procédure de fusion dans le cadre du protocole d’engagement.
    • Une stratégie de résolution des conflits personnalisée n’est disponible qu’avec Azure Cosmos DB pour NoSQL et ne peut être définie qu’au moment de la création du conteneur.

• Dans une configuration d’écriture multirégion, il existe une dépendance à une seule région « hub » Azure Cosmos DB pour effectuer toutes les résolutions de conflit, le protocole de consensus Paxos étant appliqué pour obtenir le quorum entre les réplicas au sein de la région hub.

  • La plateforme fournit une mémoire tampon de messages pour les conflits d’écriture au sein de la région hub afin de fournir un niveau de charge et de redondance pour les erreurs temporaires.
    • La mémoire tampon est capable de stocker quelques minutes de mises à jour en écriture nécessitant un consensus.

L’orientation stratégique de la plateforme Azure Cosmos DB est de supprimer cette dépendance à région unique pour la résolution des conflits dans une configuration d’écriture multirégion, en utilisant une approche Paxos en 2 phases pour atteindre le quorum au niveau mondial et au sein d’une région.

• La région « hub » principale est déterminée par la première région dans laquelle Azure Cosmos DB est configuré.

  • Un ordre de priorité est configuré pour d’autres régions de déploiement satellite à des fins de basculement.

• Le modèle de données et le partitionnement entre les partitions logiques et physiques jouent un rôle important dans l’obtention de performances et de disponibilité optimales.

• Lorsqu’il est déployé avec une seule région d’écriture, Azure Cosmos DB peut être configuré pour le basculement automatique en fonction d’une priorité de basculement définie, compte tenu de tous les réplicas de région de lecture.

• Le RTO fourni par la plateforme Azure Cosmos DB est d’environ 10 à 15 minutes, ce qui capture le temps écoulé pour effectuer un basculement régional du service Azure Cosmos DB en cas de sinistre catastrophique affectant la région du hub.

  • Ce RTO est également pertinent dans un contexte d’écriture multirégion, étant donné la dépendance à une seule région « hub » pour la résolution des conflits.
    • Si la région « hub » devient indisponible, les écritures effectuées dans d’autres régions échouent une fois la mémoire tampon de message remplie, car la résolution des conflits ne peut pas se produire tant que le service ne bascule pas et qu’une nouvelle région hub n’est pas établie.

L’orientation stratégique de la plateforme Azure Cosmos DB consiste à réduire le RTO à environ 5 minutes en autorisant les basculements au niveau de la partition.

• Les objectifs de point de récupération (RPO) et les objectifs de temps de récupération (RTO) sont configurables via des niveaux de cohérence, avec un compromis entre la durabilité des données et le débit.

  • Azure Cosmos DB fournit un RTO minimal de 0 pour un niveau de cohérence détendu avec des écritures multirégions ou un RPO de 0 pour une cohérence forte avec une région d’écriture unique.

• Azure Cosmos DB offre un contrat SLA de 99,999 % pour la disponibilité en lecture et en écriture pour les comptes de base de données configurés avec plusieurs régions Azure comme accessibles en écriture.

  • Le contrat SLA est représenté par le pourcentage de temps de fonctionnement mensuel, qui est calculé comme 100 % - Taux d’erreur moyen.
  • Le taux d’erreur moyen est défini comme la somme des taux d’erreur pour chaque heure du mois de facturation divisé par le nombre total d’heures dans le mois de facturation, où le taux d’erreur correspond au nombre total de demandes ayant échoué divisé par le nombre total de demandes ayant échoué au cours d’un intervalle d’une heure donné.

• Azure Cosmos DB offre un contrat SLA de 99,99 % pour le débit, la cohérence, la disponibilité et la latence pour les comptes de base de données étendus à une seule région Azure lorsqu’ils sont configurés avec l’un des cinq niveaux de cohérence.

  • Un contrat SLA de 99,99 % s’applique également aux comptes de base de données couvrant plusieurs régions Azure configurés avec l’un des quatre niveaux de cohérence détendus.

• Il existe deux types de débit qui peuvent être provisionnés dans Azure Cosmos DB, standard et mise à l’échelle automatique, qui sont mesurés à l’aide d’unités de requête par seconde (RU/s).

  • Le débit standard alloue les ressources nécessaires pour garantir une valeur de RU/s spécifiée.
    • Standard est facturé toutes les heures pour le débit provisionné.
  • La mise à l’échelle automatique définit une valeur de débit maximale, et Azure Cosmos DB effectue automatiquement un scale-up ou un scale-down en fonction de la charge de l’application, entre la valeur de débit maximale et un minimum de 10 % de la valeur de débit maximale.
    • La mise à l’échelle automatique est facturée toutes les heures pour le débit maximal consommé.

• Le débit statique approvisionné avec une charge de travail variable peut entraîner des erreurs de limitation, ce qui aura un impact sur la disponibilité perçue des applications.

  • La mise à l’échelle automatique protège contre les erreurs de limitation en permettant à Azure Cosmos DB d’effectuer un scale-up en fonction des besoins, tout en conservant la protection des coûts en redescendant lorsque la charge diminue.

• Quand Azure Cosmos DB est répliqué dans plusieurs régions, les unités de demande provisionnée sont facturées par région.

• Il existe un delta de coût important entre une configuration d’écriture multirégion et une configuration d’écriture à une seule région, ce qui peut, dans de nombreux cas, rendre prohibitif le coût d’une plateforme de données Azure Cosmos DB multi-master.

Lecture/écriture d’une seule région	Écriture dans une seule région - Lecture dans une région double	Lecture/écriture à double région
1 unité de requête	2 RU	4 RU

Le delta entre écriture à une seule région et écriture multirégion est en fait inférieur au ratio 1 :2 reflété dans le tableau ci-dessus. Plus précisément, des frais de transfert de données interrégions sont associés aux mises à jour en écriture dans une configuration en écriture unique, qui n’est pas capturé dans les coûts de ru comme avec la configuration d’écriture multirégion.

• Le stockage consommé est facturé sous forme de forfait pour la quantité totale de stockage (Go) consommée pour héberger les données et les index pendant une heure donnée.

• Session est le niveau de cohérence par défaut et le plus couramment utilisé, car les données sont reçues dans le même ordre que les écritures.

• Azure Cosmos DB prend en charge l’authentification via une identité Microsoft Entra ou des clés et jetons de ressource Azure Cosmos DB, qui fournissent des fonctionnalités qui se chevauchent.

• Il est possible de désactiver les opérations de gestion des ressources à l’aide de clés ou de jetons de ressource pour limiter les clés et les jetons de ressource aux opérations de données uniquement, ce qui permet un contrôle d’accès affiné aux ressources à l’aide de Microsoft Entra contrôle d’accès en fonction du rôle (RBAC).

  • La restriction de l’accès au plan de contrôle par le biais de clés ou de jetons de ressources désactive les opérations de plan de contrôle pour les clients qui utilisent des SDK Azure Cosmos DB et doit donc être évaluée et testée de manière approfondie.
  • Le disableKeyBasedMetadataWriteAccess paramètre peut être configuré via des définitions IaC de modèle ARM ou via un Azure Policy intégré.

• Microsoft Entra prise en charge RBAC dans Azure Cosmos DB s’applique aux opérations de gestion des comptes et des plans de contrôle des ressources.

  • Les administrateurs d’application peuvent créer des attributions de rôles pour les utilisateurs, les groupes, les principaux de service ou les identités managées afin d’accorder ou de refuser l’accès aux ressources et aux opérations sur les ressources Azure Cosmos DB.
  • Plusieurs rôles RBAC intégrés sont disponibles pour l’attribution de rôle, et les rôles RBAC personnalisés peuvent également être utilisés pour former des combinaisons de privilèges spécifiques.
    • Le lecteur de compte Cosmos DB active l’accès en lecture seule à la ressource Azure Cosmos DB.
    • Le contributeur de compte DocumentDB permet la gestion des comptes Azure Cosmos DB, y compris les clés et les attributions de rôles, mais n’active pas l’accès au plan de données.
    • Opérateur Cosmos DB, qui est similaire à Contributeur de compte DocumentDB, mais ne permet pas de gérer des clés ou des attributions de rôles.

• Les ressources Azure Cosmos DB (comptes, bases de données et conteneurs) peuvent être protégées contre toute modification ou suppression incorrecte à l’aide de verrous de ressources.

  • Les verrous de ressources peuvent être définis au niveau du compte, de la base de données ou du conteneur.
  • Un verrou de ressource défini sur sur une ressource sera hérité par toutes les ressources enfants. Par exemple, un verrou de ressources défini sur le compte Azure Cosmos DB sera hérité par toutes les bases de données et conteneurs au sein du compte.
  • Les verrous de ressources s’appliquent uniquement aux opérations de plan de contrôle et n’empêchent pas les opérations de plan de données, telles que la création, la modification ou la suppression de données.
  • Si l’accès au plan de contrôle n’est pas restreint avec disableKeyBasedMetadataWriteAccess, les clients pourront effectuer des opérations de plan de contrôle à l’aide de clés de compte.

• Le flux de modification Azure Cosmos DB fournit un flux chronologique des modifications apportées aux données dans un conteneur Azure Cosmos DB.

  • Le flux de modification inclut uniquement les opérations d’insertion et de mise à jour dans le conteneur Azure Cosmos DB source ; il n’inclut pas les suppressions.

• Le flux de modification peut être utilisé pour gérer un magasin de données distinct du conteneur principal utilisé par l’application, avec des mises à jour continues du magasin de données cible alimentées par le flux de modification du conteneur source.

  • Le flux de modification peut être utilisé pour remplir un magasin secondaire pour une redondance supplémentaire de la plateforme de données ou pour des scénarios analytiques ultérieurs.

• Si les opérations de suppression affectent systématiquement les données dans le conteneur source, le magasin alimenté par le flux de modification sera imprécis et ne sera pas réflectif des données supprimées.

  • Un modèle de suppression réversible peut être implémenté afin que les enregistrements de données soient inclus dans le flux de modification.
    • Au lieu de supprimer explicitement les enregistrements de données, les enregistrements de données sont mis à jour en définissant un indicateur (par IsDeletedexemple) pour indiquer que l’élément est considéré comme supprimé.
    • Tout magasin de données cible alimenté par le flux de modification doit détecter et traiter les éléments avec un indicateur supprimé défini sur True ; au lieu de stocker les enregistrements de données supprimés de manière réversible, la version existante de l’enregistrement de données dans le magasin cible doit être supprimée.
  • Une durée de vie courte (TTL) est généralement utilisée avec le modèle de suppression réversible afin qu’Azure Cosmos DB supprime automatiquement les données expirées, mais uniquement après qu’elles soient reflétées dans le flux de modification avec l’indicateur supprimé défini sur True.
    • Effectue l’intention de suppression d’origine tout en propageant la suppression via le flux de modification.

• Azure Cosmos DB peut être configuré en tant que magasin analytique, qui applique un format de colonne pour les requêtes analytiques optimisées afin de résoudre les problèmes de complexité et de latence qui se produisent avec les pipelines ETL traditionnels.

• Azure Cosmos DB sauvegarde automatiquement les données à intervalles réguliers sans affecter les performances ou la disponibilité, et sans consommer de RU/s.

• Azure Cosmos DB peut être configuré selon deux modes de sauvegarde distincts.

  • Périodique est le mode de sauvegarde par défaut pour tous les comptes, où les sauvegardes sont effectuées à intervalles réguliers et les données sont restaurées en créant une demande avec l’équipe du support technique.
    • La période de conservation périodique des sauvegardes par défaut est de huit heures et l’intervalle de sauvegarde par défaut est de quatre heures, ce qui signifie que seules les deux dernières sauvegardes sont stockées par défaut.
    • L’intervalle de sauvegarde et la période de rétention sont configurables dans le compte.
      • La période de rétention maximale s’étend à un mois avec un intervalle de sauvegarde minimal d’une heure.
      • Une attribution de rôle au « rôle lecteur de compte Cosmos DB » Azure est requise pour configurer la redondance du stockage de sauvegarde.
    • Deux copies de sauvegarde sont incluses sans coût supplémentaire, mais les sauvegardes supplémentaires entraînent des coûts supplémentaires.
    • Par défaut, les sauvegardes périodiques sont stockées dans un stockage Geo-Redundant (GRS) distinct qui n’est pas directement accessible.
      • Le stockage de sauvegarde existe dans la région « hub » principale et est répliqué dans la région jumelée via la réplication du stockage sous-jacent.
      • La configuration de redondance du compte de stockage de sauvegarde sous-jacent est configurable pour stockage redondant interzone ou stockage Locally-Redundant.
    • L’exécution d’une opération de restauration nécessite une demande de support , car les clients ne peuvent pas effectuer directement une restauration.
      • Avant d’ouvrir un ticket de support, la période de conservation des sauvegardes doit être augmentée à au moins sept jours dans les huit heures suivant l’événement de perte de données.
    • Une opération de restauration crée un compte Azure Cosmos DB dans lequel les données sont récupérées.
      • Un compte Azure Cosmos DB existant ne peut pas être utilisé pour la restauration
      • Par défaut, un nouveau compte Azure Cosmos DB nommé <Azure_Cosmos_account_original_name>-restored<n> sera utilisé.
        • Ce nom peut être ajusté, par exemple en réutilisant le nom existant si le compte d’origine a été supprimé.
    • Si le débit est provisionné au niveau de la base de données, la sauvegarde et la restauration se produisent au niveau de la base de données
      • Il n’est pas possible de sélectionner un sous-ensemble de conteneurs à restaurer.
  • Le mode de sauvegarde continue permet une restauration à n’importe quel moment au cours des 30 derniers jours.
    • Les opérations de restauration peuvent être effectuées pour revenir à un point dans le temps (PITR) spécifique avec une granularité d’une seconde.
    • La fenêtre disponible pour les opérations de restauration est de 30 jours maximum.
      • Il est également possible de restaurer l’état d’instanciation de la ressource.
    • Les sauvegardes continues sont effectuées dans chaque région Azure où existe le compte Azure Cosmos DB.
      • Les sauvegardes continues sont stockées dans la même région Azure que chaque réplica Azure Cosmos DB, à l’aide du stockage Locally-Redundant (LRS) ou du stockage redondant interzone (ZRS) dans les régions qui prennent en charge Zones de disponibilité.
    • Une restauration en libre-service peut être effectuée à l’aide des artefacts Portail Azure ou IaC tels que des modèles ARM.
    • La sauvegarde continue présente plusieurs limitations .
      • Le mode de sauvegarde continue n’est actuellement pas disponible dans une configuration d’écriture multirégion.
      • Seuls Azure Cosmos DB pour NoSQL et Azure Cosmos DB pour MongoDB peuvent être configurés pour la sauvegarde continue à l’heure actuelle.
      • Si la durée de vie d’un conteneur est configurée, les données restaurées qui ont dépassé sa durée de vie peuvent être immédiatement supprimées
    • Une opération de restauration crée un compte Azure Cosmos DB pour la restauration dans le temps.
    • Il existe un coût de stockage supplémentaire pour les opérations de sauvegarde et de restauration continues.

• Les comptes Azure Cosmos DB existants peuvent être migrés de Périodique vers Continu, mais pas de Continu vers Périodique ; la migration est unidirectionnel et non réversible.

• Chaque sauvegarde Azure Cosmos DB est composée des données proprement dites et des détails de configuration pour le débit provisionné, les stratégies d’indexation, les régions de déploiement et les paramètres de durée de vie du conteneur.

  • Les sauvegardes ne contiennent pas de paramètres de pare-feu, de listes de contrôle d’accès de réseau virtuel, de paramètres de point de terminaison privé, de paramètres de cohérence (un compte est restauré avec la cohérence de session), de procédures stockées, de déclencheurs, d’UDF ou de paramètres multirégions.
    • Les clients sont responsables du redéploiement des fonctionnalités et des paramètres de configuration. Ils ne sont pas restaurés via la sauvegarde Azure Cosmos DB.
  • Azure Synapse données de magasin analytique Link ne sont pas non plus incluses dans les sauvegardes Azure Cosmos DB.

• Il est possible d’implémenter une fonctionnalité de sauvegarde et de restauration personnalisée pour les scénarios où les approches périodiques et continues ne conviennent pas.

  • Une approche personnalisée introduit des coûts importants et des frais administratifs supplémentaires, qui doivent être compris et évalués avec soin.
    • Les scénarios de restauration courants doivent être modélisés, tels que l’altération ou la suppression d’un compte, d’une base de données, d’un conteneur, sur un élément de données.
    • Les procédures d’entretien doivent être implémentées pour empêcher l’expansion des sauvegardes.
  • Le stockage Azure ou une autre technologie de données peuvent être utilisés, comme un autre conteneur Azure Cosmos DB.
    • Stockage Azure et Azure Cosmos DB fournissent des intégrations natives avec des services Azure tels que Azure Functions et Azure Data Factory.

• La documentation Azure Cosmos DB indique deux options potentielles pour implémenter des sauvegardes personnalisées.

  • Flux de modification Azure Cosmos DB pour écrire des données dans une installation de stockage distincte.
    • Une fonction Azure ou un processus d’application équivalent utilise le processeur de flux de modification pour se lier au flux de modification et traiter les éléments dans le stockage.
  • Les sauvegardes personnalisées continues ou périodiques (par lots) peuvent être implémentées à l’aide du flux de modification.
  • Le flux de modification Azure Cosmos DB ne reflète pas encore les suppressions. Par conséquent, un modèle de suppression réversible doit être appliqué à l’aide d’une propriété booléenne et d’une TTL.
    • Ce modèle n’est pas requis lorsque le flux de modification fournit des mises à jour de fidélité totale.
  • Azure Data Factory connecteur pour Azure Cosmos DB (connecteurs d’API Azure Cosmos DB pour NoSQL ou MongoDB) pour copier des données.
    • Azure Data Factory (ADF) prend en charge l’exécution manuelle et la planification, la fenêtre De basculement et les déclencheurs basés sur les événements.
      • Prend en charge à la fois le stockage et Event Grid.
    • ADF convient principalement aux implémentations de sauvegarde personnalisées périodiques en raison de son orchestration par lots.
      • Il est moins adapté aux implémentations de sauvegarde continue avec des événements fréquents en raison de la surcharge d’exécution de l’orchestration.
    • ADF prend en charge Azure Private Link pour les scénarios de sécurité réseau élevée

Azure Cosmos DB est utilisé dans la conception de nombreux services Azure. Par conséquent, une panne régionale importante pour Azure Cosmos DB aura un effet en cascade sur différents services Azure au sein de cette région. L’impact précis sur un service particulier dépend fortement de la façon dont la conception du service sous-jacente utilise Azure Cosmos DB.

Recommandations relatives à la conception

Azure Cosmos DB

• Utilisez Azure Cosmos DB comme plateforme de données principale lorsque les exigences le permettent.

• Pour les scénarios de charge de travail stratégiques, configurez Azure Cosmos DB avec une réplica d’écriture à l’intérieur de chaque région de déploiement afin de réduire la latence et de fournir une redondance maximale.

  • Configurez l’application pour hiérarchiser l’utilisation des réplica Azure Cosmos DB locales pour les écritures et les lectures afin d’optimiser la charge de l’application, les performances et la consommation de RU/s régionales.
  • La configuration d’écriture multirégion est très coûteuse et doit être hiérarchisée uniquement pour les scénarios de charge de travail nécessitant une fiabilité maximale.

• Pour les scénarios de charge de travail moins critiques, donnez la priorité à l’utilisation d’une configuration d’écriture à une seule région (lors de l’utilisation de Zones de disponibilité) avec des réplicas en lecture distribués à l’échelle mondiale, car cela offre un niveau de fiabilité élevé de la plateforme de données (SLA de 99,999 % pour la lecture, 99,995 % pour les opérations d’écriture) à un prix plus attrayant.

  • Configurez l’application pour utiliser le réplica de lecture Azure Cosmos DB local pour optimiser les performances de lecture.

• Sélectionnez une région de déploiement « hub » optimale où la résolution des conflits se produira dans une configuration d’écriture multirégion, et toutes les écritures seront effectuées dans une configuration d’écriture à une seule région.

  • Tenez compte de la distance par rapport à d’autres régions de déploiement et de la latence associée lors de la sélection d’une région primaire, ainsi que des fonctionnalités requises telles que Zones de disponibilité prise en charge.

• Configurez Azure Cosmos DB avec la redondance de zone de disponibilité (AZ) dans toutes les régions de déploiement avec la prise en charge d’AZ, pour garantir la résilience aux défaillances zonales au sein d’une région.

• Utilisez Azure Cosmos DB pour NoSQL, car il offre l’ensemble de fonctionnalités le plus complet, en particulier en ce qui concerne l’optimisation des performances.

  • D’autres API doivent principalement être prises en compte pour les scénarios de migration ou de compatibilité.
    • Lorsque vous utilisez d’autres API, vérifiez que les fonctionnalités requises sont disponibles avec le langage et le Kit de développement logiciel (SDK) sélectionnés pour garantir une configuration et des performances optimales.

• Utilisez le mode connexion directe pour optimiser les performances réseau via une connectivité TCP directe aux nœuds Azure Cosmos DB back-end, avec un nombre réduit de « tronçons » réseau.

Le contrat SLA Azure Cosmos DB est calculé en faisant la moyenne des demandes ayant échoué, ce qui peut ne pas s’aligner directement sur un budget d’erreur de niveau de fiabilité de 99,999 %. Lors de la conception d’un SLO à 99,999 %, il est donc essentiel de planifier l’indisponibilité d’écriture Azure Cosmos DB régionale et multirégion, en veillant à ce qu’une technologie de stockage de secours soit positionnée en cas de défaillance, telle qu’une file d’attente de messages persistante pour une relecture ultérieure.

• Définissez une stratégie de partitionnement sur des partitions logiques et physiques pour optimiser la distribution des données en fonction du modèle de données.

  • Réduisez les requêtes entre les partitions.
  • Testez et validez de manière itérative la stratégie de partitionnement pour garantir des performances optimales.

• Sélectionnez une clé de partition optimale.

  • La clé de partition ne peut pas être modifiée une fois qu’elle a été créée dans la collection.
  • La clé de partition doit être une valeur de propriété qui ne change pas.
  • Sélectionnez une clé de partition qui a une cardinalité élevée, avec une large plage de valeurs possibles.
  • La clé de partition doit répartir uniformément la consommation de ru et le stockage des données sur toutes les partitions logiques pour garantir même la consommation des RU et la distribution du stockage entre les partitions physiques.
  • Exécutez des requêtes de lecture sur la colonne partitionnée pour réduire la consommation et la latence des RU.

• L’indexation étant également cruciale pour les performances, assurez-vous que les exclusions d’index sont utilisées pour réduire les ru/s et les besoins en stockage.

  • Indexer uniquement les champs nécessaires au filtrage dans les requêtes ; concevoir des index pour les prédicats les plus utilisés.

• Tirez parti des fonctionnalités intégrées de gestion des erreurs, de nouvelles tentatives et de fiabilité plus larges du Kit de développement logiciel (SDK) Azure Cosmos DB.

  • Implémentez la logique de nouvelle tentative dans le Kit de développement logiciel (SDK) sur les clients.

• Utilisez des clés de chiffrement gérées par le service pour réduire la complexité de la gestion.

  • S’il existe une exigence de sécurité spécifique pour les clés gérées par le client, assurez-vous que des procédures de gestion des clés appropriées sont appliquées, telles que la sauvegarde et la rotation.

• Désactivez l’accès en écriture aux métadonnées basées sur des clés Azure Cosmos DB en appliquant le Azure Policy intégré.

• Permettre à Azure Monitor de collecter des métriques clés et des journaux de diagnostic, tels que le débit provisionné (RU/s).

  • Router les données opérationnelles Azure Monitor dans un espace de travail Log Analytics dédié à Azure Cosmos DB et à d’autres ressources globales dans la conception de l’application.
  • Utilisez les métriques Azure Monitor pour déterminer si les modèles de trafic d’application conviennent pour la mise à l’échelle automatique.

• Évaluez les modèles de trafic d’application pour sélectionner une option optimale pour les types de débit provisionnés.

  • Envisagez de mettre à l’échelle automatiquement le débit provisionné pour augmenter automatiquement la demande de charge de travail.

• Évaluez les conseils de performances Microsoft pour Azure Cosmos DB afin d’optimiser la configuration côté client et côté serveur pour améliorer la latence et le débit.

• Lors de l’utilisation d’AKS comme plateforme de calcul : pour les charges de travail nécessitant beaucoup de requêtes, sélectionnez une référence SKU de nœud AKS dont la mise en réseau accélérée est activée pour réduire la latence et les gigues du processeur.

• Pour les déploiements dans une région d’écriture unique, il est vivement recommandé de configurer Azure Cosmos DB pour le basculement automatique.

• Niveau de charge via l’utilisation d’une messagerie asynchrone non bloquante dans les flux système, qui écrivent des mises à jour dans Azure Cosmos DB.

  • Tenez compte de modèles tels que la répartition de la responsabilité des commandes et des requêtes et l’approvisionnement en événements.

• Configurez le compte Azure Cosmos DB pour les sauvegardes continues afin d’obtenir une précision fine des points de récupération au cours des 30 derniers jours.

  • Envisagez l’utilisation des sauvegardes Azure Cosmos DB dans les scénarios où les données contenues ou le compte Azure Cosmos DB sont supprimés ou endommagés.
  • Évitez l’utilisation d’une approche de sauvegarde personnalisée, sauf si cela est absolument nécessaire.

• Il est vivement recommandé de pratiquer des procédures de récupération sur des ressources et des données hors production, dans le cadre de la préparation standard des opérations de continuité d’activité.

• Définissez des artefacts IaC pour rétablir les paramètres de configuration et les fonctionnalités d’une restauration de sauvegarde Azure Cosmos DB.

• Évaluez et appliquez les conseils de contrôle de la base de référence de sécurité Azure pour la sauvegarde et la récupération Azure Cosmos DB.

  • BR-1 : Garantir des sauvegardes automatiques régulières
  • BR-3 : Valider toutes les sauvegardes, y compris les clés gérées par le client
  • BR-4, Atténuer le risque de perte de clés

• Pour les charges de travail analytiques nécessitant une disponibilité multirégion, utilisez le magasin analytique Azure Cosmos DB, qui applique un format de colonne pour les requêtes analytiques optimisées.

Technologies de données relationnelles

Pour les scénarios avec un modèle de données hautement relationnel ou des dépendances sur des technologies relationnelles existantes, l’utilisation d’Azure Cosmos DB dans une configuration d’écriture multirégion peut ne pas être directement applicable. Dans ce cas, il est essentiel que les technologies relationnelles utilisées soient conçues et configurées pour répondre aux aspirations de mode actif-actif multirégional d’une conception d’application.

Azure fournit de nombreuses plateformes de données relationnelles managées, y compris Azure SQL Database et Azure Database pour les solutions relationnelles OSS courantes, notamment MySQL, PostgreSQL et MariaDB. Les considérations de conception et les recommandations de cette section se concentrent donc sur l’utilisation optimale de Azure SQL database et des versions OSS Azure Database pour optimiser la fiabilité et la disponibilité globale.

Considérations en matière de conception

• Alors que les technologies de données relationnelles peuvent être configurées pour mettre facilement à l’échelle les opérations de lecture, les écritures sont généralement contraintes de passer par une seule instance primaire, ce qui impose une contrainte importante sur la scalabilité et les performances.

• Le partitionnement peut être appliqué pour distribuer des données et le traitement entre plusieurs bases de données structurées identiques, partitionnant les bases de données horizontalement pour parcourir les contraintes de la plateforme.

  • Par exemple, le partitionnement est souvent appliqué dans les plateformes SaaS multilocataires pour isoler des groupes de locataires dans des constructions de plateforme de données distinctes.

Azure SQL Database

• Azure SQL Database fournit un moteur de base de données complètement managé qui s’exécute toujours sur la dernière version stable du moteur de base de données SQL Server et du système d’exploitation sous-jacent.

  • Fournit des fonctionnalités intelligentes telles que l’optimisation des performances, la surveillance des menaces et les évaluations des vulnérabilités.

• Azure SQL Database fournit une haute disponibilité régionale intégrée et une géoréplication clé en main pour distribuer les réplicas en lecture dans les régions Azure.

  • Avec la géoréplication, les réplicas de base de données secondaires restent en lecture seule jusqu’à ce qu’un basculement soit lancé.
  • Jusqu’à quatre secondaires sont pris en charge dans la même région ou dans des régions différentes.
  • Les réplicas secondaires peuvent également être utilisés pour l’accès aux requêtes en lecture seule afin d’optimiser les performances de lecture.
  • Le basculement doit être lancé manuellement, mais peut être encapsulé dans des procédures opérationnelles automatisées.

• Azure SQL Database fournit des groupes de basculement automatique, qui répliquent les bases de données sur un serveur secondaire et permettent un basculement transparent en cas de défaillance.

  • Les groupes de basculement automatique prennent en charge la géoréplication de toutes les bases de données du groupe vers une seule instance ou un seul serveur secondaire situé dans une autre région.
  • Les groupes de basculement automatique ne sont actuellement pas pris en charge dans le niveau de service Hyperscale.
  • Les bases de données secondaires peuvent être utilisées pour décharger le trafic de lecture.

• Les réplicas de base de données de niveau de service Premium ou critique pour l'entreprise peuvent être distribués entre Zones de disponibilité sans coût supplémentaire.

  • L’anneau de contrôle est également dupliqué sur plusieurs zones sous la forme de trois anneaux de passerelle (GW).
    • Le routage vers un anneau de passerelle spécifique est contrôlé par Azure Traffic Manager.
  • Lorsque vous utilisez le niveau Critique pour l’entreprise, la configuration de zone redondante est uniquement disponible lorsque le matériel de calcul Gen5 est sélectionné.

• Azure SQL Database offre un contrat SLA de disponibilité de base de référence de 99,99 % sur tous ses niveaux de service, mais fournit un contrat SLA supérieur de 99,995 % pour les niveaux critique pour l'entreprise ou Premium dans les régions qui prennent en charge les zones de disponibilité.

  • Azure SQL niveaux critique pour l'entreprise de base de données ou Premium non configurés pour les déploiements redondants interzone ont un contrat SLA de disponibilité de 99,99 %.

• Lorsqu’il est configuré avec la géoréplication, le niveau critique pour l'entreprise base de données Azure SQL fournit un objectif de temps de récupération (RTO) de 30 secondes pendant 100 % des heures déployées.

• Lorsqu’il est configuré avec la géoréplication, le niveau Azure SQL database critique pour l'entreprise a un objectif de point de récupération (RPO) de 5 secondes pendant 100 % des heures déployées.

• Azure SQL niveau Hyperscale de base de données, lorsqu’il est configuré avec au moins deux réplicas, a un contrat SLA de disponibilité de 99,99 %.

• Les coûts de calcul associés à Azure SQL Database peuvent être réduits à l’aide d’une remise de réservation.

  • Il n’est pas possible d’appliquer une capacité réservée pour les bases de données basées sur DTU.

• La restauration dans le temps peut être utilisée pour renvoyer une base de données et des données contenues à un point antérieur dans le temps.

• La géorestauration peut être utilisée pour récupérer une base de données à partir d’une sauvegarde géoredondante.

Azure Database pour PostgreSQL

• Azure Database pour PostgreSQL est proposé dans trois options de déploiement différentes :

  • Serveur unique, SLA 99,99 %
  • Serveur flexible, qui offre une redondance de zone de disponibilité, SLA 99,99 %
  • Hyperscale (Citus), SLA 99,95 % lorsque le mode haute disponibilité est activé.

• Hyperscale (Citus) offre une scalabilité dynamique par le biais du partitionnement sans modification de l’application.

  • La distribution de lignes de table sur plusieurs serveurs PostgreSQL est essentielle pour garantir des requêtes évolutives dans Hyperscale (Citus).
  • Plusieurs nœuds peuvent contenir collectivement plus de données qu’une base de données traditionnelle et, dans de nombreux cas, utiliser des processeurs worker en parallèle pour optimiser les coûts.

• La mise à l’échelle automatique peut être configurée via l’automatisation des runbooks pour garantir l’élasticité en réponse à l’évolution des modèles de trafic.

• Le serveur flexible offre des économies pour les charges de travail hors production grâce à la possibilité d’arrêter/démarrer le serveur et à un niveau de calcul burstable qui convient aux charges de travail qui ne nécessitent pas de capacité de calcul continue.

• Aucun frais supplémentaire n’est facturé pour le stockage de sauvegarde pour jusqu’à 100 % du stockage serveur approvisionné total.

  • La consommation supplémentaire de stockage de sauvegarde est facturée en fonction de la consommation de Go/mois.

• Les coûts de calcul associés à Azure Database pour PostgreSQL peuvent être réduits à l’aide d’une remise de réservation de serveur unique ou d’une remise de réservation Hyperscale (Citus).

Recommandations relatives à la conception

• Envisagez le sharding pour partitionner les bases de données relationnelles en fonction des différents contextes d’application et de données, ce qui vous aidera à gérer les contraintes de la plateforme, à optimiser la scalabilité et la disponibilité et à isoler les erreurs.

  • Cette recommandation est particulièrement répandue lorsque la conception de l’application prend en compte au moins trois régions Azure, car les contraintes technologiques relationnelles peuvent considérablement entraver les plateformes de données distribuées à l’échelle mondiale.
  • Le sharding (ou partitionnement) n’étant pas indiqué pour tous les scénarios d’application, il est nécessaire de procéder à une évaluation en contexte.

• S’il existe des besoins relationnels, privilégiez l’utilisation d’Azure SQL Database pour sa maturité sur la plateforme Azure et son large éventail de fonctionnalités de fiabilité.

Azure SQL Database

• Utilisez le niveau de service Critique pour l’entreprise pour optimiser la fiabilité et la disponibilité, y compris l’accès aux fonctionnalités de résilience critiques.

• Utilisez le modèle de consommation basé sur vCore pour faciliter la sélection indépendante des ressources de calcul et de stockage, adaptée aux besoins en volume et débit de charge de travail.

  • Vérifiez qu’un modèle de capacité défini est appliqué pour informer les besoins en ressources de calcul et de stockage.
    • Envisagez la capacité réservée pour fournir des optimisations potentielles des coûts.

• Configurez le modèle de déploiement Zone-Redundant pour répartir critique pour l'entreprise réplicas de base de données au sein de la même région sur Zones de disponibilité.

• Utilisez la géoréplication active pour déployer des réplicas lisibles dans toutes les régions de déploiement (jusqu’à quatre).

• Utilisez des groupes de basculement automatique pour fournir un basculement transparent vers une région secondaire, avec la géoréplication appliquée pour fournir une réplication vers d’autres régions de déploiement pour l’optimisation de la lecture et la redondance de base de données.

  • Pour les scénarios d’application limités à seulement deux régions de déploiement, l’utilisation de groupes de basculement automatique doit être privilégiée.

• Envisagez des déclencheurs opérationnels automatisés, basés sur des alertes alignées sur le modèle d’intégrité de l’application, pour effectuer des basculements vers des instances géorépliquées en cas de défaillance affectant le principal et le secondaire au sein du groupe de basculement automatique.

Important

Pour les applications qui envisagent plus de quatre régions de déploiement, il convient de prendre sérieusement en compte le partitionnement ou la refactorisation de l’application pour prendre en charge les technologies d’écriture multirégions, telles qu’Azure Cosmos DB. Toutefois, si cela n’est pas possible dans le scénario de charge de travail de l’application, il est conseillé d’élever une région d’une zone géographique unique à un status principal englobant un instance géorépliqué à un accès en lecture distribué plus uniformément.

• Configurez l’application pour qu’elle interroge les instances de réplica pour les requêtes de lecture afin d’optimiser les performances de lecture.

• Utilisez Azure Monitor et Azure SQL Analytics pour obtenir des insights opérationnels en quasi-temps réel dans Azure SQL DB pour la détection des incidents de fiabilité.

• Utilisez Azure Monitor pour évaluer l’utilisation de toutes les bases de données et déterminer si elles ont été bien dimensionnées.

  • Vérifiez que les pipelines CD prennent en compte le test de charge sous des niveaux de charge représentatifs pour valider le comportement de la plateforme de données.

• Calculez une métrique d’intégrité pour les composants de base de données afin d’observer l’intégrité par rapport aux besoins de l’entreprise et à l’utilisation des ressources, en utilisant la surveillance et les alertes pour mener une action opérationnelle automatisée le cas échéant.

  • Assurez-vous que les métriques de performances des requêtes clés sont incorporées afin qu’une action rapide puisse être prise en cas de dégradation du service.

• Optimisez les requêtes, les tables et les bases de données à l’aide de Query Performance Insights et des recommandations de performances courantes fournies par Microsoft.

• Implémentez une logique de nouvelle tentative à l’aide du KIT de développement logiciel (SDK) pour atténuer les erreurs temporaires ayant un impact sur la connectivité de Azure SQL base de données.

• Hiérarchiser l’utilisation de clés gérées par le service lors de l’application du chiffrement transparent des données côté serveur pour le chiffrement au repos.

  • Si des clés gérées par le client ou un chiffrement côté client (AlwaysEncrypted) sont nécessaires, assurez-vous que les clés sont correctement résilientes avec des sauvegardes et des fonctionnalités de rotation automatisées.

• Envisagez l’utilisation de la restauration dans le temps comme playbook opérationnel pour récupérer après des erreurs de configuration graves.

Azure Database pour PostgreSQL

• Il est recommandé d’utiliser le serveur flexible pour les charges de travail critiques pour l’entreprise en raison de sa prise en charge de la zone de disponibilité.

• Lorsque vous utilisez Hyperscale (Citus) pour les charges de travail critiques pour l’entreprise, activez le mode haute disponibilité pour recevoir la garantie SLA de 99,95 %.

• Utilisez la configuration du serveur Hyperscale (Citus) pour optimiser la disponibilité sur plusieurs nœuds.

• Définissez un modèle de capacité pour l’application afin d’informer les besoins en ressources de calcul et de stockage au sein de la plateforme de données.

  • Envisagez la remise de réservation Hyperscale (Citus) pour fournir des optimisations potentielles des coûts.

Mise en cache pour les données de niveau chaud

Une couche de mise en cache en mémoire peut être appliquée pour améliorer une plateforme de données en augmentant considérablement le débit de lecture et en améliorant les temps de réponse du client de bout en bout pour les scénarios de données à chaud.

Azure fournit plusieurs services avec des fonctionnalités applicables pour la mise en cache des structures de données clés, avec des Azure Cache pour Redis positionnés pour extraire et optimiser l’accès en lecture à la plateforme de données. Cette section se concentre donc sur l’utilisation optimale de Azure Cache pour Redis dans les scénarios où des performances de lecture et une durabilité d’accès aux données supplémentaires sont requises.

Remarques sur la conception

• Une couche de mise en cache offre une durabilité supplémentaire de l’accès aux données, car même si une panne a un impact sur les technologies de données sous-jacentes, une instantané de données d’application est toujours accessible via la couche de mise en cache.

• Dans certains scénarios de charge de travail, la mise en cache en mémoire peut être implémentée dans la plateforme d’application elle-même.

Cache Azure pour Redis

• Le cache Redis est un système de stockage en mémoire clé-valeur NoSQL open source.

• Les niveaux Enterprise et Enterprise Flash peuvent être déployés dans une configuration active-active sur Zones de disponibilité au sein d’une région et de différentes régions Azure via la géoréplication.

  • Lorsqu’il est déployé dans au moins trois régions Azure et trois Zones de disponibilité ou plus dans chaque région, avec la géoréplication active activée pour toutes les instances de cache, Azure Cache pour Redis fournit un contrat SLA de 99,999 % pour la connectivité à un point de terminaison de cache régional.
  • Lorsqu’il est déployé sur trois Zones de disponibilité dans une seule région Azure, un contrat SLA de connectivité à 99,99 % est fourni.

• Le niveau Flash Entreprise s’exécute sur une combinaison de mémoire RAM et flash non volatile, et bien que cela entraîne une petite pénalité de performances, il permet également de très grandes tailles de cache, jusqu’à 13 To avec clustering.

• Avec la géoréplication, des frais de transfert de données entre régions s’appliquent également en plus des coûts directs associés aux instances de cache.

• La fonctionnalité de Mises à jour planifiée n’inclut pas les mises à jour Azure ni les mises à jour appliquées au système d’exploitation de machine virtuelle sous-jacent.

• Il y aura une augmentation de l’utilisation du processeur pendant une opération de scale-out pendant la migration des données vers de nouvelles instances.

Recommandations relatives à la conception

• Envisagez une couche de mise en cache optimisée pour les scénarios de données « chaudes » afin d’augmenter le débit de lecture et d’améliorer les temps de réponse.

• Appliquez des stratégies appropriées pour l’expiration et l’entretien du cache afin d’éviter une perte de contrôle de la croissance des données.

  • Envisagez de faire expirer les éléments du cache lorsque les données sous-jacentes changent.

Cache Azure pour Redis

• Utilisez la référence SKU Premium ou Enterprise pour optimiser la fiabilité et les performances.

  • Pour les scénarios où des volumes de données extrêmement importants sont en jeu, le niveau Enterprise Flash est à envisager.
  • Pour les scénarios où seule la géoréplication passive est nécessaire, le niveau Premium peut également être envisagé.

• Déployez les instances de réplica en utilisant la géoréplication dans une configuration active pour toutes les régions de déploiement envisagées.

• Assurez-vous que réplica instances sont déployées sur Zones de disponibilité dans chaque région Azure considérée.

• Utilisez Azure Monitor pour évaluer Azure Cache pour Redis.

  • Calculez un score d’intégrité pour les composants de cache régionaux afin d’observer l’intégrité par rapport aux besoins de l’entreprise et à l’utilisation des ressources.
  • Observez et alertez les métriques clés telles que l’utilisation élevée du processeur, l’utilisation élevée de la mémoire, la charge élevée du serveur et les clés supprimées pour obtenir des informations sur le moment où mettre à l’échelle le cache.

• Optimisez la résilience des connexions en implémentant une logique de nouvelle tentative, des délais d’expiration et en utilisant une implémentation singleton du multiplexeur de connexion Redis.

• Configurez les mises à jour planifiées pour prescrire les jours et heures auxquels les mises à jour redis Server sont appliquées au cache.

Scénarios analytiques

Il est de plus en plus courant pour les applications stratégiques d’envisager des scénarios analytiques comme un moyen de générer une valeur supplémentaire à partir de flux de données englobants. Les scénarios analytiques d’application et opérationnels (AIOps) constituent donc un aspect crucial de la plateforme de données hautement fiable.

Les charges de travail analytiques et transactionnelles nécessitent différentes fonctionnalités et optimisations de la plateforme de données pour des performances acceptables dans leurs contextes respectifs.

Description	Analytique	Transactionnelle
Cas d’usage	Analyser de très grands volumes de données (« Big Data »)	Traiter de très grands volumes de transactions individuelles
Optimisé pour	Lire des requêtes et des agrégations sur de nombreux enregistrements	Requêtes CRUD (Create/Read/Update/Delete) en quasi-temps réel sur quelques enregistrements
Caractéristiques clés	- Consolider à partir de sources de données d’enregistrement - Stockage basé sur les colonnes - Stockage distribué - Traitement parallèle - Dénormalisé - Lectures et écritures à faible accès concurrentiel - Optimiser le volume de stockage avec compression	- Source de données d’enregistrement pour l’application - Stockage basé sur les lignes - Stockage contigu - Traitement symétrique -Normalisée - Lectures et écritures à accès concurrentiel élevé, mises à jour d’index - Optimiser l’accès rapide aux données avec le stockage en mémoire

Azure Synapse fournit une plateforme analytique d’entreprise qui réunit des données relationnelles et non relationnelles avec des technologies Spark, en utilisant l’intégration intégrée à des services Azure tels qu’Azure Cosmos DB pour faciliter l’analytique du Big Data. Les considérations et recommandations de conception de cette section se concentrent donc sur les Azure Synapse optimales et l’utilisation d’Azure Cosmos DB pour les scénarios analytiques.

Remarques sur la conception

• Traditionnellement, les scénarios analytiques à grande échelle sont facilités par l’extraction de données dans une plateforme de données distincte optimisée pour les requêtes analytiques.
  • Les pipelines d’extraction, de transformation et de chargement (ETL) sont utilisés pour extraire des données qui consomment le débit et ont un impact sur les performances des charges de travail transactionnelles.
  • L’exécution de pipelines ETL rarement pour réduire les impacts sur le débit et les performances entraîne des données analytiques moins à jour.
  • La surcharge de développement et de maintenance du pipeline ETL augmente à mesure que les transformations de données deviennent plus complexes.
    • Par exemple, si les données sources sont fréquemment modifiées ou supprimées, les pipelines ETL doivent tenir compte de ces modifications dans les données cibles pour les requêtes analytiques par le biais d’une approche additive/versionnée, d’un vidage et d’un rechargement, ou de modifications sur place sur les données analytiques. Chacune de ces approches aura un impact dérivé, tel que la recréation ou la mise à jour de l’index.

Azure Cosmos DB

• Les requêtes analytiques exécutées sur des données transactionnelles Azure Cosmos DB sont généralement agrégées sur des partitions sur de grands volumes de données, consommant un débit d’unité de requête (RU) important, ce qui peut avoir un impact sur les performances des charges de travail transactionnelles environnantes.

• Le magasin analytique Azure Cosmos DB fournit un magasin de données orienté colonne entièrement isolé schématisé qui permet l’analytique à grande échelle sur les données Azure Cosmos DB à partir de Azure Synapse sans impact sur les charges de travail transactionnelles Azure Cosmos DB.

  • Lorsqu’un conteneur Azure Cosmos DB est activé en tant que magasin analytique, un nouveau magasin de colonnes est créé en interne à partir des données opérationnelles dans le conteneur. Ce magasin de colonnes est conservé séparément du magasin de transactions orienté ligne pour le conteneur.
  • Les opérations de création, de mise à jour et de suppression sur les données opérationnelles sont automatiquement synchronisées avec le magasin analytique, de sorte qu’aucun flux de modification ou traitement ETL n’est nécessaire.
  • La synchronisation des données entre le magasin opérationnel et le magasin analytique ne consomme pas d’unités de requête (RU) de débit approvisionnées sur le conteneur ou la base de données. Il n’y a aucun impact sur les performances sur les charges de travail transactionnelles. Le magasin analytique ne nécessite pas l’allocation d’unités de requête supplémentaires sur une base de données ou un conteneur Azure Cosmos DB.
  • La synchronisation automatique est le processus dans lequel les modifications des données opérationnelles sont automatiquement synchronisées avec le magasin analytique. La latence de synchronisation automatique est généralement inférieure à deux (2) minutes.
    • La latence de synchronisation automatique peut atteindre cinq (5) minutes pour une base de données avec un débit partagé et un grand nombre de conteneurs.
    • Dès que la synchronisation automatique est terminée, les données les plus récentes peuvent être interrogées à partir de Azure Synapse.
  • Le stockage du Magasin analytique utilise un modèle tarifaire basé sur la consommation qui facture le volume de données et le nombre d’opérations de lecture et d’écriture. La tarification du magasin analytique est distincte de la tarification du magasin transactionnel.

• À l’aide de Azure Synapse Link, le magasin analytique Azure Cosmos DB peut être interrogé directement à partir de Azure Synapse. Cela permet l’absence d’ETL, le traitement hybride Transactional-Analytical (HTAP) à partir de Synapse, de sorte que les données Azure Cosmos DB peuvent être interrogées avec d’autres charges de travail analytiques de Synapse en quasi-temps réel.

• Le magasin analytique Azure Cosmos DB n’est pas partitionné par défaut.

  • Pour certains scénarios de requête, les performances s’améliorent en partitionnant les données du magasin analytique à l’aide de clés fréquemment utilisées dans les prédicats de requête.
  • Le partitionnement est déclenché par un travail dans Azure Synapse qui exécute un notebook Spark à l’aide de Synapse Link, qui charge les données à partir du magasin analytique Azure Cosmos DB et les écrit dans le magasin partitionné Synapse dans le compte de stockage principal de l’espace de travail Synapse.

• Azure Synapse Analytics, les pools SQL Serverless peuvent interroger le magasin analytique via des vues SELECT / OPENROWSET ou des commandes mises à jour automatiquement.

• Azure Synapse Les pools Spark Analytics peuvent interroger le magasin analytique par le biais de tables Spark mises à jour automatiquement ou de la spark.read commande .

• Les données peuvent également être copiées à partir du magasin analytique Azure Cosmos DB dans un pool Synapse SQL dédié à l’aide de Spark, afin que les ressources du pool SQL Azure Synapse approvisionnées puissent être utilisées.

• Les données du magasin analytique Azure Cosmos DB peuvent être interrogées avec Azure Synapse Spark.

  • Les notebooks Spark permettent aux combinaisons de trames de données Spark d’agréger et de transformer des données analytiques Azure Cosmos DB avec d’autres jeux de données, et d’utiliser d’autres fonctionnalités Synapse Spark avancées, notamment l’écriture de données transformées dans d’autres magasins ou l’entraînement de modèles Machine Learning AIOps.

• Le flux de modification Azure Cosmos DB peut également être utilisé pour gérer un magasin de données secondaire distinct pour les scénarios analytiques.

Azure Synapse

• Azure Synapse regroupe des fonctionnalités d’analytique, notamment l’entreposage de données SQL, le Big Data Spark et Data Explorer pour l’analytique des journaux et des séries chronologiques.

  • Azure Synapse utilise des services liés pour définir des connexions à d’autres services, tels que stockage Azure.
  • Les données peuvent être ingérées dans Synapse Analytics via activité Copy à partir de sources prises en charge. Cela permet l’analytique des données dans Synapse sans impacter le magasin de données source, mais ajoute du temps, du coût et de la latence en raison du transfert de données.
  • Les données peuvent également être interrogées sur place dans les magasins externes pris en charge, ce qui évite la surcharge liée à l’ingestion et au déplacement des données. Stockage Azure avec Data Lake Gen2 est un magasin pris en charge pour Synapse et les données exportées Log Analytics peuvent être interrogées via Synapse Spark.

• Azure Synapse Studio unit les tâches d’ingestion et d’interrogation.

  • Les données sources, y compris les données du magasin analytique Azure Cosmos DB et les données d’exportation Log Analytics, sont interrogées et traitées afin de prendre en charge le décisionnel et d’autres cas d’usage analytiques agrégés.

Recommandations relatives à la conception

• Vérifiez que les charges de travail analytiques n’ont pas d’impact sur les charges de travail d’applications transactionnelles pour maintenir les performances transactionnelles.

Application Analytics

• Utilisez Azure Synapse Link avec le magasin analytique Azure Cosmos DB pour effectuer des analyses sur les données opérationnelles Azure Cosmos DB en créant un magasin de données optimisé, qui n’aura pas d’impact sur les performances transactionnelles.

  • Activez Azure Synapse Link sur les comptes Azure Cosmos DB.
  • Créez un conteneur activé pour le magasin analytique ou activez un conteneur existant pour le magasin analytique.
  • Connectez l’espace de travail Azure Synapse au magasin analytique Azure Cosmos DB pour permettre aux charges de travail analytiques dans Azure Synapse d’interroger les données Azure Cosmos DB. Utilisez une chaîne de connexion avec une clé Azure Cosmos DB en lecture seule.

• Hiérarchiser le magasin analytique Azure Cosmos DB avec Azure Synapse Link au lieu d’utiliser le flux de modification Azure Cosmos DB pour gérer un magasin de données analytiques.

  • Le flux de modification Azure Cosmos DB peut convenir à des scénarios analytiques très simples.

AIOps et Operational Analytics

• Créez un espace de travail Azure Synapse unique avec des services liés et des jeux de données pour chaque compte de stockage Azure source auquel les données opérationnelles des ressources sont envoyées.

• Créez un compte de stockage Azure dédié et utilisez-le comme compte de stockage principal de l’espace de travail pour stocker les données et métadonnées du catalogue de l’espace de travail Synapse. Configurez-le avec un espace de noms hiérarchique pour activer Azure Data Lake Gen2.

  • Maintenir la séparation entre les données analytiques sources et les données et métadonnées de l’espace de travail Synapse.
    • N’utilisez pas l’un des comptes de stockage Azure régionaux ou globaux où les données opérationnelles sont envoyées.

Étape suivante

Passez en revue les considérations relatives à la mise en réseau.

Réseau et connectivité