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 des implications considérables dans d’autres domaines de conception. Azure offre finalement une multitude de plateformes de données relationnelles, non relationnelles et analytiques, qui diffèrent considérablement dans la 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éraabilité, le coût et la complexité. Par exemple, la capacité à fonctionner dans une configuration d’écriture multirégion aura un impact essentiel sur l’adéquation à une plateforme mondialement disponible.

Cette zone de conception s’étend sur la conception d’applications, fournissant des considérations et des recommandations clés pour informer 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 qu’est une charge de travail stratégique ?

Les quatre vs de Big Data

Les « quatre vs du Big Data » fournissent un framework pour mieux comprendre les caractéristiques requises pour une plateforme de données hautement disponible et comment les données peuvent être utilisées pour optimiser la valeur métier. Cette section explore donc comment les caractéristiques volume, vélocité, variété et veracity peuvent être appliquées au niveau conceptuel pour aider à concevoir une plateforme de données à l’aide de technologies de données appropriées.

• olume V: quantité de données entrantes pour informer la capacité de stockage et les exigences de hiérarchisation , c’est-à-dire la taille du jeu de données.
• Velocity : vitesse à laquelle les données sont traitées, en tant que lots ou flux continus , c’est-à-dire le débit de flux.
• Ariety V: l’organisation 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 entre plusieurs magasins ou types.
• Veracity : inclut la provenance et la curation des jeux de données considérés pour la gouvernance et l’assurance 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 futurs prévus en fonction des taux de croissance des données prévus alignés sur les objectifs et plans métier.

  • Le volume de données doit englober les données elles-mêmes 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.
  • Il peut y avoir des implications significatives sur les coûts associés à l’expansion des données.

• 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 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 c’est le cas, pendant combien de temps ?
  • Quelles sont les procédures d’atténuation ? et l’atténuation exigera-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 avec laquelle les données sont émises à partir de différents composants d’application, ainsi que les exigences de débit pour la validation et la récupération des données rapides 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 le scénario de charge de travail, par exemple celles qui sont lourdes 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 ?

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

  • L’optimisation de la configuration pour un débit élevé entraîne des compromis, qui doivent être entièrement compris.
  • Les modèles de persistance et de messagerie au niveau de la 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 retournent-t-elle des codes d’échec pendant que le plan de contrôle continue à fonctionner ?
  • La plateforme de données active-t-elle la limitation et, le cas échéant, pendant combien de temps ?

• La recommandation de conception d’application fondamentale pour utiliser une distribution géographique active-active présente des défis liés à la cohérence des données.

  • Il existe un compromis entre cohérence et 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 est le coût de la cohérence des données.

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

• Les réplicas en lecture seule (intrarégion et interrégion) peuvent être utilisés pour réduire la latence des allers-retours et distribuer le trafic pour améliorer les performances, le débit, la disponibilité et l’extensibilité.

• 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 des clients de bout en bout.

  • Les délais d’expiration et les stratégies de cache 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 non relationnel ou un schéma variable ?
  • Comment l’application interroge-t-elle les données ? Et les requêtes dépendent-elles des concepts de couche 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é tel que 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.

• Outre les plateformes de données relationnelles ou non relationnelles, les plateformes de données graphiques ou clé-valeur peuvent également convenir à certaines charges de travail de données.

  • Certaines technologies s’adressent aux modèles de données de 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, les services d’application individuels peuvent être créés avec des magasins de données optimisés pour des scénarios distincts plutôt qu’en fonction d’un magasin de données monolithique unique.

  • Les 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 colocalisation.
  • L’utilisation de plusieurs technologies de données ajoute un degré de surcharge de gestion pour maintenir les technologies englobantes.

• Les ensembles de fonctionnalités pour chaque service Azure diffèrent entre les langages, les SDK et les API, ce qui peut considérablement affecter le niveau de réglage 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 englobants influenceront 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 objet.
  • Fonctionnalité de requête neutre en 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 de runtime analytique, tels qu’Apache Spark, peuvent avoir des restrictions d’intégration pour analyser des 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 un impact significatif sur la conception et la sélection de technologies de données sur la plateforme 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.
  • Évolution de la gestion des modifications et du schéma.
  • Dépendances entre jeux de données.

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

  • Lorsque les lecteurs et les enregistreurs sont distribués séparément, une application doit choisir de retourner la version la plus rapide disponible d’un élément de données, même si elle est obsolète par rapport à une écriture juste-terminée (mise à jour) de cet élément de données dans un autre réplica, ou la version la plus récente 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 servies à 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, 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 puisse être répliquée, un conflit est créé qui doit être résolu.

  • Des stratégies de résolution de conflit 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.

• support Azure 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 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 « man-in-the-middle » ou d’usurpation/wiretapping.

• Authentification et autorisation au plan de données et au 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é par le biais de la surveillance de l’intégrité de la plateforme et de l’accès aux données.

  • Comment les alertes seront-elles appliquées pour les conditions en dehors des limites opérationnelles acceptables ?

Recommandations relatives à la conception

Volume

• Assurez-vous que les futurs volumes de données associés à la croissance organique ne sont pas censés dépasser les fonctionnalités de 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.

  • Vérifiez 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 a été introduite, les données sous-jacentes doivent peut-être être répliquées, ce qui prendra du temps et introduirea probablement une pénalité de performances pendant la réplication. Ainsi, assurez-vous que ces opérations sont effectuées en dehors des heures d’ouverture critiques si possible.

• Définissez les niveaux de données d’application pour classifier les jeux de données en fonction de l’utilisation et de la criticité pour faciliter la suppression ou le déchargement de 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 les données « chaudes » utilisées activement par l’application, tandis que Stockage Azure est utilisée pour les données d’opérations « froides » à des fins analytiques.

• Configurez les procédures de nettoyage pour optimiser la croissance des données et optimiser 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 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.
  • Collectez les 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 de ménage 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 être conçue et configurée de manière inhérente pour prendre en charge un débit élevé, 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 par scénario.

  • 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 de la 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 lorsque de nouvelles données sont disponibles en lecture, ce qui peut avoir un impact sur l’expérience utilisateur.
    • Cet impact doit être compris et acceptable dans le contexte des principales exigences métier.

• Assurez-vous de l’évolutivité agile pour prendre en charge les niveaux de débit et de charge variables.

  • Si les niveaux de charge sont hautement volatiles, envisagez de surprovisionner les niveaux de capacité pour garantir que le débit et les performances sont maintenus.
  • 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 lancer et se terminer dans des délais conformes aux exigences métier.
  • 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 des investissements d’ingénierie suivants.

• 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é correctement par la plateforme de données ou la couche 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 les stratégies appropriées pour l’expiration du cache et la conservation à domicile afin d’éviter la croissance des données en cours d’exécution.
    • Expirez les éléments de 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 du service des données obsolètes doivent être comprises.

Variété

• En s’alignant sur le principe d’une conception native cloud et 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 investissements futurs de la plateforme Microsoft.

• En s’alignant sur le principe de conception d’application des architectures de microservice faiblement couplées, autorisez les services individuels à utiliser des magasins de données distincts et des technologies de données optimisées par scénario.

  • 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 dans lequel les dépendances entre les magasins de données existent.

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

  • Assurez-vous que la prise en charge des langages et des fonctionnalités du Kit de développement logiciel (SDK) requis est prise en charge. Toutes les fonctionnalités ne sont pas disponibles pour chaque langage/SDK de la même manière.

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.

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

• Lorsque les exigences de cohérence le permettent, utilisez une conception multirégion de plateforme de données d’écriture pour optimiser la disponibilité globale 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 puisse être répliquée et ainsi créer un conflit.
    • Utiliser des stratégies de résolution de conflit standardisées, telles que « Dernière victoire » dans la mesure du possible
      • Si une stratégie personnalisée avec une logique personnalisée est requise, vérifiez que les pratiques CI/CD DevOps sont appliquées pour gérer la logique personnalisée.

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

• 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 les tests de charge par rapport aux 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.

Remarque

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 plateforme de données dans une conception d’application.

Plus précisément, pour optimiser la fiabilité, il est essentiel que les composants de la plateforme de données répondent correctement à 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 de plateforme de données supplémentaires 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, potentiellement par le biais de l’approvisionnement d’unités d’échelle supplémentaires. Cette approche sera finalement limitée s’il existe une dépendance difficile d’une équipe d’opérations centralisée pour résoudre les problèmes liés à la plateforme de données en isolation.

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é par le biais d’une expérience de gestion largement intextualisée et qui 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 d’architecture des applications Azure.

• Arbre de décision du magasin de données Azure
• 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 tenir pleinement compte des aspirations actives distribuées à l’échelle mondiale d’une conception d’application, il est vivement recommandé de prendre en compte une plateforme de données d’écriture multirégion distribuée, où les modifications apportées aux réplicas pouvant être séparés sont synchronisées et fusionnées entre tous les réplicas, avec résolution des conflits si nécessaire.

Important

Les microservices ne nécessitent peut-être pas tous un magasin de données d’écriture multirégion distribué. Vous devez 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é et hautement disponible à l’échelle mondiale, offrant des écritures multirégions et une cohérence paramétrable prête à l’emploi. Les considérations et recommandations relatives à la conception dans cette section se concentrent donc sur une utilisation optimale d’Azure Cosmos DB.

Considérations sur la conception

Azure Cosmos DB

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

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

  • Azure Cosmos DB pour NoSQL fournit le jeu de fonctionnalités le plus riche et est généralement l’API où de nouvelles fonctionnalités seront disponibles en premier.

• Azure Cosmos DB prend en charge les modes de passerelle et de connectivité directe, où Direct facilite la connectivité via TCP aux nœuds de réplica Azure Cosmos DB principaux 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 frontend.

  • Le mode direct est disponible uniquement lors de l’utilisation d’Azure Cosmos DB pour NoSQL et n’est actuellement pris en charge que sur les plateformes du Kit de développement logiciel (SDK) .NET et Java.

• Dans les régions activées pour la zone de disponibilité, Azure Cosmos DB offre une prise en charge de la redondance de la zone 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 dans une seule 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 se protéger contre les défaillances zonales.

  • Le protocole de consensus Paxos est appliqué pour atteindre 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 entre 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 à une seule région, une région principale « hub » 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éplique les modifications entre toutes les autres régions. Si une région n’est pas disponible, les régions restantes sont utilisées pour traiter le trafic d’écriture.

• Dans une configuration d’écriture multirégion, les conflits de mise à jour (insertion, remplacement, suppression) peuvent se produire lorsque les enregistreurs mettent simultanément à jour 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é timestamp _ts définie par le système comme chemin de résolution des conflits. Si un élément est en conflit avec la valeur la plus élevée pour le chemin de résolution de conflit devient le 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 validé.
    • Avec les conflits de suppression, la version supprimée gagne toujours en conflit 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 aux sémantiques définies par l’application de rapprocher les conflits à l’aide d’une procédure stockée de fusion inscrite 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 de conflit personnalisée est disponible uniquement 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 vis-à-vis d’une seule région « hub » Azure Cosmos DB pour effectuer toutes les résolutions de conflit, avec le protocole de consensus Paxos appliqué pour atteindre le quorum entre les réplicas au sein de la région hub.

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

L’orientation stratégique de la plateforme Azure Cosmos DB consiste à supprimer cette dépendance de 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 à un niveau global et au sein d’une région.

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

  • Un ordre de priorité est configuré pour des régions de déploiement satellite supplémentaires à 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, en capturant le temps écoulé pour effectuer un basculement régional du service Azure Cosmos DB si une catastrophe catastrophique a un impact sur la région hub.

  • Ce RTO est également pertinent dans un contexte d’écriture multirégion, compte tenu de la dépendance d’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 après le remplissage de la mémoire tampon de message, 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 est établie.

La direction 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 d’activité mensuel, qui est calculé comme étant de 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ées par nombre total de demandes 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 des comptes de base de données limités à 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ées 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, la mise à l’échelle standard et automatique, qui sont mesurés à l’aide d’unités de requête par seconde (RU/s).

  • Le débit standard alloue des 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 approvisionné statique avec une charge de travail variable peut entraîner des erreurs de limitation, ce qui aura un impact sur la disponibilité perçue de l’application.

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

• Quand Azure Cosmos DB est répliqué dans plusieurs régions, les unités de requête provisionnée (RU) sont facturées par région.

• Il existe un delta de coût important entre une configuration d’écriture multirégion et d’écriture à une seule région qui, dans de nombreux cas, peut rendre une plateforme de données Azure Cosmos DB multimaître prohibitive.

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

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

• Le stockage consommé est facturé en tant que taux fixe pour la quantité totale de stockage consommée pour héberger des données et des index pendant une heure donnée.

• Sessionest le niveau de cohérence par défaut et le plus largement 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 des 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 ressources 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 aux ressources affiné à l’aide du contrôle d’accès en fonction du rôle (RBAC) Microsoft Entra.

  • La restriction de l’accès au plan de contrôle via des clés ou des jetons de ressource désactive les opérations du plan de contrôle pour les clients utilisant des kits SDK Azure Cosmos DB et doit donc être soigneusement évaluée et testée.
  • Le disableKeyBasedMetadataWriteAccess paramètre peut être configuré via des définitions IAC de modèle ARM ou via une stratégie Azure intégrée.

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

  • Les administrateurs d’applications peuvent créer des attributions de rôles pour les utilisateurs, les groupes, les principaux de service ou les identités managées pour accorder ou 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 permet d’accéder 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, similaire au contributeur de compte DocumentDB, mais ne permet pas de gérer les clés ou les attributions de rôles.

• Les ressources Azure Cosmos DB (comptes, bases de données et conteneurs) peuvent être protégées contre une modification ou une suppression incorrectes à 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 une ressource est hérité par toutes les ressources enfants. Par exemple, un verrou de ressource défini sur le compte Azure Cosmos DB est 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 limité 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 de 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 vers le conteneur Azure Cosmos DB source ; il n’inclut pas de 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é par le flux de modification du conteneur source.

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

• Si les opérations de suppression affectent régulièrement les données dans le conteneur source, le magasin alimenté par le flux de modification est incorrect et non 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 exemple IsDeleted) 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 des 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 une fois qu’elle est reflétée dans le flux de modification avec l’indicateur supprimé défini sur True.
    • Accomplit 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é en fonction de 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 de support technique.
    • La période de rétention de sauvegarde périodique 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 nécessaire pour configurer la redondance du stockage de sauvegarde.
    • Deux copies de sauvegarde sont incluses sans frais supplémentaires, mais des sauvegardes supplémentaires entraînent des coûts supplémentaires.
    • Par défaut, les sauvegardes périodiques sont stockées dans un stockage géoredondant distinct (GRS) qui n’est pas directement accessible.
      • Le stockage de sauvegarde existe dans la région principale « hub » et est répliqué vers la région jumelée via la réplication de stockage sous-jacente.
      • La configuration de redondance du compte de stockage de sauvegarde sous-jacent est configurable pour le stockage redondant interzone ou le stockage localement redondant.
    • L’exécution d’une opération de restauration nécessite une demande de support, car les clients ne peuvent pas effectuer directement de restauration.
      • Avant d’ouvrir un ticket de support, la période de rétention de sauvegarde 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 où 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 point de temps au cours des 30 derniers jours.
    • Les opérations de restauration peuvent être effectuées pour revenir à un point spécifique dans le temps (PITR) 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 des ressources.
    • 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 localement redondant (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.
    • Il existe plusieurs limitations avec la sauvegarde continue.
      • Le mode de sauvegarde continue n’est actuellement pas disponible dans une configuration en écriture multirégion.
      • Seuls Azure Cosmos DB pour NoSQL et Azure Cosmos DB pour MongoDB peuvent être configurés pour la sauvegarde continue pour l’instant.
      • Si un conteneur a configuré la durée de vie, les données restaurées qui ont dépassé sa durée de vie peuvent être supprimées immédiatement
    • 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 sauvegardes continues et les opérations de restauration.

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

• Chaque sauvegarde Azure Cosmos DB se compose des données et des détails de configuration pour le débit approvisionné, 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 au réseau virtuel, de paramètres de point de terminaison privé, de paramètres de cohérence (un compte est restauré avec cohérence de session), de procédures stockées, de déclencheurs, de fonctions définies par l’utilisateur ou de paramètres multirégions.
    • Les clients sont responsables du redéploiement des fonctionnalités et des paramètres de configuration. Celles-ci ne sont pas restaurées via la sauvegarde Azure Cosmos DB.
  • Les données du magasin analytique Azure Synapse Link ne sont pas 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 sont pas adaptées.

  • Une approche personnalisée introduit des coûts importants et des frais administratifs supplémentaires, qui doivent être compris et soigneusement évalués.
    • 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 l’élément de données.
    • Les procédures de nettoyage doivent être implémentées pour empêcher l’extension de la sauvegarde.
  • Stockage Azure ou une autre technologie de données peut être utilisée, par exemple un autre conteneur Azure Cosmos DB.
    • Stockage Azure et Azure Cosmos DB fournissent des intégrations natives avec des services Azure tels qu’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 établir une liaison au flux de modification et traiter les éléments dans le stockage.
  • Les sauvegardes personnalisées continues ou périodiques (par lot) 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 durée de vie.
    • Ce modèle n’est pas obligatoire lorsque le flux de modification fournit des mises à jour de fidélité complètes.
  • Connecteur Azure Data Factory 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 bascule et les déclencheurs basés sur les événements.
      • Fournit la prise en charge du stockage et d’Event Grid.
    • ADF convient principalement aux implémentations de sauvegarde personnalisées périodiques en raison de son orchestration orientée 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 de service sous-jacente utilise Azure Cosmos DB.

Recommandations relatives à la conception

Azure Cosmos DB

• Utilisez Azure Cosmos DB comme plateforme de données principale où les exigences sont autorisées.

• Pour les scénarios de charge de travail critiques, configurez Azure Cosmos DB avec un réplica en écriture dans chaque région de déploiement pour réduire la latence et fournir une redondance maximale.

  • Configurez l’application pour hiérarchiser l’utilisation du réplica Azure Cosmos DB local pour les écritures et les lectures afin d’optimiser la charge, les performances et la consommation régionale des RU/s.
  • La configuration en écriture multirégion est 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, hiérarchisez l’utilisation de la configuration en écriture à une seule région (lors de l’utilisation de Zones de disponibilité) avec des réplicas de lecture distribués globalement, car cela offre un niveau élevé de fiabilité de la plateforme de données (99,999 % SLA pour les opérations d’écriture) à un prix plus attrayant.

  • Configurez l’application pour utiliser le réplica en 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 en écriture à une seule région.

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

• Configurez Azure Cosmos DB avec redondance de zone de disponibilité (AZ) dans toutes les régions de déploiement avec prise en charge 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 le réglage des performances.

  • Les 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 SDK sélectionnés pour garantir une configuration et des performances optimales.

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

Le contrat SLA Azure Cosmos DB est calculé en 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 pour 99,999 % SLO, il est donc essentiel de planifier l’indisponibilité d’écriture d’Azure Cosmos DB régionale et multirégion, en garantissant qu’une technologie de stockage de secours est positionnée si une défaillance, telle qu’une file d’attente de messages persistante pour la 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 un large éventail de valeurs possibles.
  • La clé de partition doit répartir uniformément la consommation de RU et le stockage de données sur toutes les partitions logiques pour garantir même la consommation et la distribution de stockage de RU sur 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 est également essentielle pour les performances. Assurez-vous que les exclusions d’index sont utilisées pour réduire les besoins en RU/s et 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 au sein du 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, vérifiez que les 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 des métadonnées basées sur des clés Azure Cosmos DB en appliquant l’azure Policy intégré.

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

  • Routez les données opérationnelles Azure Monitor dans un espace de travail Log Analytics dédié à Azure Cosmos DB et à d’autres ressources globales au sein de la conception de l’application.
  • Utilisez les métriques Azure Monitor pour déterminer si les modèles de trafic d’application conviennent à 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 approvisionné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.

• Lorsque vous utilisez AKS comme plateforme de calcul : pour les charges de travail gourmandes en requêtes, sélectionnez une référence SKU de nœud AKS qui a accéléré la mise en réseau activée pour réduire la latence et les gigues du processeur.

• Pour les déploiements de régions d’écriture uniques, il est fortement recommandé de configurer Azure Cosmos DB pour le basculement automatique.

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

  • Envisagez des modèles tels que la séparation des responsabilités de commande et de requête et l’approvisionnement en événements.

• Configurez le compte Azure Cosmos DB pour les sauvegardes continues afin d’obtenir une précision précise 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 absolument nécessaire.

• Il est fortement 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 les 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 instructions de contrôle de 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 automatisées 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 les 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, notamment Azure SQL Database et Azure Database pour les solutions relationnelles OSS courantes, notamment MySQL, PostgreSQL et MariaDB. Les considérations et recommandations relatives à la conception de cette section se concentrent donc sur l’utilisation optimale des versions d’Azure SQL Database et d’Azure Database OSS pour optimiser la fiabilité et la disponibilité globale.

Considérations sur la conception

• Bien que les technologies de données relationnelles puissent être configurées pour mettre à l’échelle facilement les opérations de lecture, les écritures sont généralement contraintes de passer par une seule instance principale, ce qui place une contrainte significative sur l’extensibilité et les performances.

• Le partitionnement peut être appliqué pour distribuer des données et le traitement sur plusieurs bases de données structurées identiques, partitionner horizontalement des bases de données pour parcourir les contraintes de 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 des 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 les mêmes régions ou différentes.
  • Les réplicas secondaires peuvent également être utilisés pour l’accès aux requêtes en lecture seule pour 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 des 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 99,99 % de référence 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é.

  • Les niveaux Critique pour l’entreprise azure SQL Database 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 Azure SQL Database fournit un objectif de temps de récupération (RTO) de 30 secondes pour 100 % des heures déployées.

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

• Le niveau Hyperscale d’Azure SQL Database, configuré avec au moins deux réplicas, dispose d’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 DTU.

• La restauration à un point 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, CONTRAT 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) fournit 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 du runbook pour garantir l’élasticité en réponse à la modification des modèles de trafic.

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

• Il n’existe aucun frais supplémentaire pour le stockage de sauvegarde pour jusqu’à 100 % du stockage serveur provisionné total.

  • Une consommation supplémentaire de stockage de sauvegarde est facturée en fonction de go/mois consommés.

• 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 trois régions Azure ou plus, 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ées aux besoins en volume et en 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 redondant interzone pour répartir les réplicas de base de données critiques métier dans la même région dans 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 la réplication vers des régions de déploiement supplémentaires pour l’optimisation de la lecture et la redondance de la 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, en fonction 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 d’échec impactant le principal et le secondaire dans le groupe de basculement automatique.

Important

Pour les applications prenant en compte plus de quatre régions de déploiement, il est important de prendre en compte le partitionnement ou la refactorisation de l’application pour prendre en charge les technologies d’écriture multirégion, 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 dans une zone géographique unique à un état principal englobant une instance géorépliquée pour un accès en lecture plus uniformément distribué.

• 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 quasiment en temps réel dans Azure SQL DB pour détecter les 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, à l’aide de la surveillance et des alertes pour générer 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 que des mesures rapides puissent être prises lorsque la dégradation du service se produit.

• Optimisez les requêtes, les tables et les bases de données à l’aide d’Query Performance Insights et des recommandations courantes en matière de performances 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 qui affectent la connectivité Azure SQL Database.

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

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

• Considérez l’utilisation de la restauration à un point dans le temps en tant que playbook opérationnel pour récupérer à partir d’erreurs de configuration graves.

Azure Database pour PostgreSQL

• Le serveur flexible est recommandé pour l’utiliser 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.

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

Mise en cache des 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 de niveau chaud.

Azure fournit plusieurs services avec des fonctionnalités applicables pour la mise en cache de 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é d’accès aux données supplémentaire, car même si une panne a un impact sur les technologies de données sous-jacentes, un 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 de clé NoSQL code source ouvert en mémoire.

• 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 dans différentes régions Azure via la géoréplication.

  • Lorsqu’elle est déployée dans au moins trois régions Azure et trois Zones de disponibilité 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.
  • En cas de déploiement sur trois Zones de disponibilité dans une seule région Azure, un contrat SLA de connectivité de 99,99 % est fourni.

• Le niveau Enterprise Flash s’exécute sur une combinaison de MÉMOIRE RAM et de stockage mémoire non volatile flash, et bien que cela introduit une petite pénalité de performances, elle permet également de très grandes tailles de cache, jusqu’à 13 To avec le clustering.

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

• La fonctionnalité Mises à jour planifiées n’inclut pas les mises à jour Ou mises à jour Azure 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.

• Vérifiez que les instances de réplica sont déployées dans 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 signalez des alertes sur les métriques clés telles que le processeur élevé, 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 la mise à l’échelle du cache.

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

• Configurez les mises à jour planifiées pour prescrire les jours et heures pendant lesquels les mises à jour de Redis Server sont appliquées au cache.

Scénarios analytiques

Il est de plus en plus courant pour les applications stratégiques de considérer les 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 d’exploitation (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 plateforme de données pour des performances acceptables dans leurs contextes respectifs.

Description	Analytique	Transactionnel
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 Create/Update/Delete (CRUD) en quasi-temps réel sur quelques enregistrements
Caractéristiques clés	- Consolider à partir de sources de données d’enregistrement - Stockage basé sur des colonnes - Stockage distribué - Traitement parallèle - Dénormalisé - Lectures et écritures de faible concurrence - Optimiser pour 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 à haute concurrence, mises à jour d’index - Optimiser l’accès rapide aux données avec 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, à l’aide d’une intégration intégrée avec des services Azure tels qu’Azure Cosmos DB pour faciliter l’analytique big data. Les considérations et recommandations relatives à la conception dans cette section se concentrent donc sur l’utilisation optimale d’Azure Synapse et 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 les données consomment le débit et impactent les performances des charges de travail transactionnelles.
  • L’exécution de pipelines ETL rarement pour réduire le débit et les impacts sur les performances entraînent 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 d’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 entre les partitions sur de grands volumes de données, consommant un débit d’unités de requête (RU), 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é qui permet une analytique à grande échelle sur les données Azure Cosmos DB d’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. Par conséquent, aucun flux de modification ou traitement ETL n’est nécessaire.
  • La synchronisation des données de l’opération vers le magasin analytique n’utilise pas les unités de requête 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 d’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 de 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 d’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 d’Azure Synapse Link, le magasin analytique Azure Cosmos DB peut être interrogé directement à partir d’Azure Synapse. Cela permet un traitement transactionnel hybride (HTAP) sans ETL à partir de Synapse, afin que les données Azure Cosmos DB puissent ê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 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.

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

• Les pools Spark Azure Synapse Analytics peuvent interroger le magasin analytique via des tables Spark mises à jour automatiquement ou 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 de pool Azure Synapse SQL 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’apprentissage 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 l’Explorateur de données 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 avoir d’impact sur 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 des 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 un 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 analytique.

  • 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 source Stockage Azure où 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 d’espaces de travail Synapse. Configurez-le avec un espace de noms hiérarchique pour activer Azure Data Lake Gen2.

  • Conservez 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 régionaux ou globaux Stockage Azure 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é