Choisir un modèle de déploiement Microsoft Fabric

Lorsque vous déployez Microsoft Fabric, vous devez décider comment structurer les capacités, les espaces de travail et les éléments au sein de votre organisation. Le bon modèle de déploiement dépend de vos besoins en matière de gouvernance, de sécurité, d’isolation des performances et de gestion des coûts. Ce guide aide les architectes et les équipes de plateforme à évaluer quatre modèles de déploiement et à comprendre les considérations et compromis pour chacun d’eux.

Hiérarchie à quatre niveaux

Le diagramme suivant montre la hiérarchie à quatre niveaux qui définit tous les déploiements Fabric.

Téléchargez un fichier Visio de cette architecture.

La hiérarchie de déploiement s'écoule de votre client Microsoft 365 jusqu'à des éléments individuels. Votre choix de modèle de déploiement détermine la façon dont vous utilisez chaque niveau.

• Niveau du locataire. En haut se trouve votre client Microsoft 365, qui fonctionne comme la frontière d'identité et d'administration pour votre organisation. Votre tenant Fabric existe dans ce tenant Microsoft 365, et toutes les ressources Fabric se trouvent dans le périmètre de ce tenant unique. Les paramètres au niveau du locataire, y compris Microsoft Entra Conditional Access, les liens privés et les étiquettes de sensibilité, s’appliquent à toutes les capacités et espaces de travail.

• Niveau de capacité. Configurez au moins une capacité Fabric au sein d’un locataire Microsoft 365. Chaque capacité est liée à une région de Azure spécifique et a une référence SKU F spécifique qui détermine les ressources de calcul disponibles mesurées en unités de capacité (UC). Les capacités contrôlent la résidence des données et fournissent des limites de facturation. Une seule capacité peut héberger plusieurs espaces de travail.

• Niveau de l’espace de travail. Chaque capacité contient un ou plusieurs espaces de travail. Les espaces de travail sont les principaux conteneurs pour la collaboration et la gouvernance. Ils définissent le contrôle d’accès via quatre rôles d’espace de travail (Administrateur, Membre, Contributeur et Visionneuse), prennent en charge l’intégration Git pour le contrôle de version et servent d’étendue pour les pipelines de déploiement. Un espace de travail appartient à une unité de capacité à la fois. La migration de capacité de la même région est simple. La migration interrégionale est possible, mais vous devez supprimer et recréer la plupart des éléments Fabric, tels que les lakehouses, les entrepôts, les notebooks et les pipelines. Par conséquent, préférez la migration de même région.

• Niveau de l’élément. Les espaces de travail contiennent des éléments Fabric tels que des entrepôts de données (lakehouses), entrepôts, notebooks, pipelines, modèles sémantiques, rapports et tableaux de bord. Les éléments héritent des autorisations d’espace de travail par défaut. Les rôles de sécurité Microsoft OneLake fournissent un contrôle d’accès granulaire au niveau de la table, du dossier, de la colonne et de la ligne, mais ils s’appliquent uniquement aux utilisateurs du rôle Visionneuse. Les administrateurs, les membres et les contributeurs de l’espace de travail contournent les rôles de sécurité OneLake.

Les contraintes de licence et de type d’espace de travail suivantes déterminent souvent le modèle de déploiement le plus pratique :

• Les nouveaux espaces de travail démarrent sur une capacité partagée, sauf si vous les réaffectez. Chaque locataire dispose d’une capacité partagée qui héberge Mes espaces de travail et peut héberger des espaces de travail Power BI Pro ou Premium par utilisateur (PPU). Pour implémenter un modèle de déploiement régi de Fabric pour les charges de travail de production, il est généralement nécessaire de réaffecter les espaces de travail à une capacité Fabric dédiée dans l'environnement locataire.

• PPU n'est pas un substitut à la capacité Fabric. PPU fournit les fonctionnalités Premium de Power BI par utilisateur, mais elle n'inclut pas la capacité Fabric. Pour créer ou exécuter des éléments autres que Power BI Fabric tels que les Lakehouses, entrepôts et notebooks, vous avez besoin d’une capacité F.

• Le type d’espace de travail affecte ce que le modèle peut héberger. Les modèles de déploiement Fabric de cet article supposent que les espaces de travail de Fabric de référence SKU sont soutenus par F. Les références SKU A et EM prennent uniquement en charge les éléments Power BI, de sorte qu'ils ne peuvent pas prendre en charge les modèles de déploiement de bout en bout Fabric.

• Power BI licences de visionneuse peuvent modifier le coût d’un schéma. Sur les capacités de F64 et plus, les utilisateurs disposant du rôle Visionneuse peuvent accéder à Power BI content avec une licence gratuite. Pour les capacités plus réduites, les consommateurs de Power BI ont besoin d’une licence Pro, PPU (Per User) ou d’essai. Ce seuil peut réduire l’efficacité des coûts d’un modèle centralisé pour les grandes populations de lecteurs.

• La création et le partage de Power BI nécessitent au moins un utilisateur Pro ou PPU. Même si un espace de travail utilise Fabric capacité, les organisations ont besoin d’utilisateurs disposant de licences Pro ou PPU pour créer et partager des éléments Power BI.

Components

• Microsoft 365 tenant : Une identité et une limite administrative pour votre organisation. Il héberge Microsoft Entra ID (anciennement Azure Active Directory) pour l’authentification et l’autorisation.

• Fabric capacity : Ressource de calcul et de facturation utilisée dans une région spécifique Azure, par exemple USA Est ou Europe Ouest. Pour réduire les coûts, vous pouvez suspendre les capacités quand elles ne sont pas utilisées.

• Fabric workspace : Un conteneur de collaboration pour les éléments Fabric. Il prend en charge le contrôle d’accès en fonction du rôle (RBAC), l’intégration Git et les pipelines de déploiement. Pour le regroupement logique, vous pouvez affecter des espaces de travail à des domaines Fabric.

• Éléments de Fabric : artéfacts de données et d’analytique tels que lakehouses, entrepôts de données, notebooks, pipelines, flux de données, modèles sémantiques, rapports et tableaux de bord.

• Domaines de Fabric : regroupements logiques qui organisent les espaces de travail par unité commerciale ou domaine d'activité. Les domaines prennent en charge la gouvernance déléguée et apparaissent dans le catalogue OneLake pour être découverts et supervisés.

• OneLake : Un lac de données unifié et hiérarchique où les locataires contiennent des espaces de travail, qui contiennent des éléments. Fabric stocke les données dans OneLake. OneLake prend en charge les API Azure Data Lake Storage, les raccourcis vers le stockage externe et l’intégration à des outils Data Lake Storage, tels que Azure Storage Explorer et AzCopy.

• OneLake catalog : Une interface centralisée pour rechercher, régir et sécuriser les données Fabric dans l'ensemble du locataire. Les utilisateurs peuvent accéder au catalogue à l’aide d’outils tels que Microsoft Teams, Excel et Microsoft Copilot Studio.

Comprendre les niveaux de déploiement de "Fabric"

La structure, les objectifs, les exigences de sécurité, la mise à l’échelle, le modèle de gouvernance et le cycle de vie des applications de votre organisation influencent les décisions à chaque niveau de déploiement. Pour plus d’informations sur chaque niveau, consultez hiérarchie à quatre niveaux.

• Les capacités contrôlent la résidence des données et la distribution géographique. Les organisations qui opèrent dans plusieurs emplacements géographiques peuvent utiliser des capacités dans différentes régions Azure pour contrôler où les données sont stockées. Chaque capacité est liée à une région Azure spécifique, qui prend en charge plusieurs déploiements géographiques entre les régions. Pour prendre en charge la gouvernance centralisée, les domaines Fabric peuvent regrouper des espaces de travail et leurs capacités associées à travers les régions.

• Les espaces de travail servent de limites de gouvernance et de sécurité principales. Chaque espace de travail définit le contrôle d’accès via quatre rôles, prend en charge le contrôle de version via l’intégration Git et sert d’étendue pour les pipelines de déploiement. Pour centraliser la découverte de contenu et de collaboration, utilisez le catalogue OneLake pour implémenter une expérience unifiée de découverte et de gouvernance sur les données OneLake du locataire. Les utilisateurs peuvent rechercher et interagir avec du contenu à partir d’outils tels que Teams et Excel via ce catalogue.

• Chaque niveau influence les choix de cycle de vie des applications. Les fonctionnalités telles que les pipelines de déploiement et la gestion du cycle de vie ne sont pas disponibles dans les modèles à espace de travail unique, car elles nécessitent des espaces de travail distincts. Les organisations qui utilisent des domaines pour regrouper des espaces de travail peuvent déléguer l’administration au niveau du domaine sans privilèges d’administrateur client, ce qui affecte la façon dont les équipes gèrent les versions et la gouvernance entre les unités commerciales.

Modèles courants dans tous les déploiements

Tous les modèles de déploiement Fabric partagent les caractéristiques fondamentales suivantes :

• Espaces de travail en tant que limites pour la mise à l’échelle, la gouvernance et la sécurité. Les modèles de déploiement utilisent Fabric espaces de travail comme unité principale pour l’organisation d’éléments, les autorisations et l’étendue des fonctionnalités DevOps. Quel que soit le modèle que vous choisissez, les espaces de travail définissent la limite de collaboration et de contrôle d’accès.

• Fabric domaines pour la délégation entre plusieurs espaces de travail et unités commerciales. Utilisez les domaines Fabric pour la délégation. Vous pouvez gérer plusieurs espaces de travail qui peuvent appartenir à la même unité commerciale, ou gérer des données appartenant à un domaine métier et s’étend sur plusieurs espaces de travail. Pour gérer et régir les données au niveau du domaine, vous pouvez ajuster les paramètres au niveau du locataire et utiliser une configuration spécifique au domaine pour ces paramètres.

• Capacités de mise à l’échelle du calcul avec une capacité dédiée par espace de travail pour des garanties de performances. Si vous devez répondre à des niveaux de performances spécifiques, utilisez Fabric capacités pour mettre à l’échelle les ressources de calcul et offrir des capacités dédiées par espace de travail. Les organisations qui ont besoin d'une isolation de charge de travail pour les tâches sensibles aux performances peuvent affecter ces espaces de travail à une capacité distincte qui a une allocation de CU garantie.

• Catalogue OneLake pour la découverte des ressources et l’onglet Sécuriser pour les stratégies de sécurité des données. Pour promouvoir la découverte et l’utilisation des ressources de données dans votre tenant, utilisez le catalogue OneLake. Pour afficher, surveiller et configurer des rôles de sécurité entre les espaces de travail et les éléments, utilisez l’onglet Sécuriser dans le catalogue OneLake.

• Extension aux fonctionnalités Microsoft Cloud si les fonctionnalités natives Fabric ne sont pas disponibles. Si aucune fonctionnalité native n'est disponible, les modèles de déploiement peuvent s'étendre pour utiliser des fonctionnalités équivalentes à partir du Microsoft Cloud, telles que Azure et Microsoft 365. Par exemple, les organisations peuvent utiliser Azure Pipelines ou GitHub Actions pour l'orchestration d'intégration continue et de livraison continue (CI/CD) si Fabric pipelines de déploiement ne couvrent pas leurs exigences d'automatisation inter-espaces de travail. Les organisations peuvent également utiliser Microsoft Purview pour la gouvernance des données à l’échelle de l’entreprise qui s’étend sur Fabric et les sources de données non Fabric.

Sélectionner un modèle de déploiement

Les scénarios suivants décrivent les exigences métier courantes et les modèles de déploiement qui les traitent. Utilisez ces scénarios pour identifier le modèle qui convient le mieux à votre organisation.

• Scénario 1 : Délai de commercialisation plus rapide avec collaboration entre équipes. Si votre organisation souhaite accélérer le délai de commercialisation, la collaboration entre équipes et les restrictions inférieures à l’utilisation des données, vous pouvez implémenter un modèle de déploiement monolithique . Dans ce scénario, votre organisation opère et gère un espace de travail unique.

  Utiliser le modèle 1 : déploiement monolithique.

• Scénario 2 : Environnements d’équipe isolés avec gestion centralisée de l’infrastructure. Si votre organisation souhaite fournir des environnements d’équipe isolés et une équipe de gestion d’infrastructure centrale, vous pouvez implémenter plusieurs espaces de travail qui utilisent une capacité partagée ou des capacités distinctes. Ce scénario convient également aux organisations qui souhaitent implémenter une architecture de maillage de données.

  Utiliser le modèle 2 : plusieurs espaces de travail, une capacité unique ou le modèle 3 : plusieurs espaces de travail, des capacités distinctes.

• Scénario 3 : Autonomie complète de l’unité commerciale sur les plateformes de données. Si votre organisation souhaite un modèle entièrement décentralisé qui donne aux unités commerciales ou aux équipes la liberté de contrôler et de gérer leurs propres plateformes de données, vous pouvez implémenter un modèle de déploiement qui utilise des espaces de travail parate avec une capacité dédiée ou plusieurs locataires Fabric.

  Utilisez Modèle 3 : Plusieurs espaces de travail, capacités distinctes ou Modèle 4 : Plusieurs clients Fabric.

• Scénario 4 : Approche hybride qui combine plusieurs modèles. Si votre organisation souhaite une solution hybride qui utilise plusieurs modèles pour répondre à ses exigences, vous pouvez implémenter une approche hybride. Par exemple, vous pouvez configurer un espace de travail unique pour des unités commerciales spécifiques, comme dans un modèle de déploiement monolithique, et séparer des espaces de travail dédiés et des capacités distinctes pour d’autres unités commerciales.

Modèle 1 : déploiement monolithique

Dans ce modèle de déploiement, vous allouez un espace de travail pour tous les cas d’usage. Toutes les unités commerciales fonctionnent dans le même espace de travail.

Les caractéristiques suivantes s’appliquent à ce modèle :

• Fabric éléments partagent la même capacité. Le temps nécessaire à une requête ou à un travail varie en fonction des autres charges de travail qui utilisent la même capacité.

• Le nombre maximal d’unités de calcul dans l’espace de travail est limité à la plus grande référence SKU F possible. Pour les expériences d’ingénierie des données et de science des données, les administrateurs de capacité peuvent configurer la facturation de mise à l’échelle automatique pour Apache Spark afin de déplacer la capacité de calcul utilisée par le moteur Spark en dehors des unités de gestion allouées.

• Les fonctionnalités qui sont étendues à un espace de travail s’appliquent à toutes les unités commerciales qui partagent l’espace de travail.

• Tous les éléments et données de l’espace de travail se trouvent dans une seule région. Vous ne pouvez pas utiliser ce modèle pour les scénarios géographiques multiples.

• Les fonctionnalités qui s’appuient sur plusieurs espaces de travail ne sont pas disponibles, par exemple les pipelines de déploiement et la gestion du cycle de vie.

• Les limitations d’un espace de travail unique s’appliquent.

• Des limitations de capacité de référence SKU spécifiques s’appliquent.

Quand utiliser ce modèle

Vous pouvez implémenter ce modèle de déploiement si :

• Votre organisation n’a pas de exigences d’ingénierie complexes, elle a une petite base d’utilisateurs, ou elle a de petits modèles sémantiques.

• Votre organisation opère dans une seule région.

• La séparation organisationnelle entre les divisions n'est pas votre préoccupation première.

• Votre organisation n'a pas besoin de fonctionnalités liées à l'espace de travail, telles que le partage de référentiels de code avec Git.

• Vous souhaitez implémenter une architecture en médaillon de type Lakehouse. Si votre organisation utilise un seul espace de travail, vous pouvez créer des lakehouses distincts au sein de l’espace de travail pour gérer les couches bronze, argent et or.

• Les unités commerciales de votre organisation partagent des rôles et vous pouvez disposer des mêmes autorisations au niveau de l’espace de travail pour les utilisateurs de l’espace de travail. Par exemple, si plusieurs utilisateurs de différentes unités commerciales sont des administrateurs d’un seul espace de travail, ils ont les mêmes droits sur tous les éléments de l’espace de travail.

• Votre organisation tolère les heures d’achèvement des travaux variables. Si une capacité est partagée, les utilisateurs peuvent exécuter des requêtes à tout moment. Le nombre d’unités de calcul disponibles pour exécuter un travail dépend des autres requêtes qui s’exécutent sur la capacité, ce qui peut entraîner des temps d’achèvement des tâches variables.

• Votre organisation peut répondre à ses besoins métier CU grâce à une seule capacité de Fabric.

Considérations relatives à la zone de conception

Le tableau suivant présente des considérations susceptibles d’influencer votre décision d’utiliser ce modèle de déploiement.

Modèle 2 : Plusieurs espaces de travail, capacité unique

Dans ce modèle de déploiement, vous allouez plusieurs espaces de travail sur une seule capacité partagée. Les espaces de travail partagent cette capacité, de sorte que les charges de travail simultanées peuvent affecter les performances des travaux et des requêtes interactives.

Les caractéristiques suivantes s’appliquent à ce modèle :

• Fabric éléments partagent la même capacité. Le temps nécessaire à une requête ou à un travail varie en fonction des autres charges de travail qui utilisent la même capacité.

• Le nombre maximal d’unités de calcul dans l’espace de travail est limité à la plus grande référence SKU F possible. Pour les expériences d’ingénierie des données et de science des données, les administrateurs de capacité peuvent configurer la facturation automatique pour Spark afin de déplacer la capacité de calcul utilisée par le moteur Spark en dehors des unités de capacité allouées.

• Les fonctionnalités liées à un espace de travail s'appliquent à toutes les divisions qui le partagent.

• Tous les éléments et données de l’espace de travail se trouvent dans une seule région. Vous ne pouvez pas utiliser ce modèle pour les scénarios géographiques multiples.

• Vous pouvez utiliser des fonctionnalités DevOps qui nécessitent des espaces de travail distincts, tels que les pipelines de déploiement et la gestion du cycle de vie.

• Les limitations d’un espace de travail unique s’appliquent.

• Des limitations de capacité de référence SKU spécifiques s’appliquent.

Quand utiliser ce modèle

Vous pouvez implémenter ce modèle de déploiement si :

• Vous souhaitez une architecture hub-spoke qui centralise certains aspects de l’opération d’environnement d’analyse et décentralise d’autres.

• Vous souhaitez une décentralisation opérationnelle et de gestion variable. Par exemple, votre organisation peut héberger les couches bronze et argent d’une architecture de médaillon dans un espace de travail et héberger la couche or dans un espace de travail distinct. Cette séparation reflète souvent des responsabilités opérationnelles distinctes, par exemple, où une équipe gère les couches bronze et argent, et une autre équipe gère la couche d’or.

• Vous n’êtes pas principalement préoccupé par la gestion des performances et l’isolation des charges de travail.

• Votre organisation n’a pas besoin de déployer des charges de travail dans différentes régions géographiques. Toutes les données doivent résider dans une région.

• Votre organisation peut nécessiter des espaces de travail distincts, car :

  • Les membres de l’équipe responsable des charges de travail se trouvent dans différents espaces de travail.

  • Vous voulez créer des espaces de travail distincts pour chaque type de charge de travail. Par exemple, vous pouvez créer un espace de travail pour l’ingestion de données, comme les pipelines de données, les dataflows ou l’ingénierie des données, et un espace de travail distinct pour la consommation via un entrepôt de données. Cette conception fonctionne bien si des équipes distinctes sont responsables de chaque charge de travail.

  • Vous souhaitez implémenter une architecture de maillage de données qui regroupe un ou plusieurs espaces de travail dans un domaine Fabric.

• Votre organisation peut déployer des espaces de travail distincts en fonction de la classification des données.

Considérations relatives à la zone de conception

Le tableau suivant présente des considérations susceptibles d’influencer votre décision d’utiliser ce modèle de déploiement.

Modèle 3 : Plusieurs espaces de travail, capacités distinctes

Dans ce modèle de déploiement, vous allouez plusieurs espaces de travail entre des capacités de Fabric distinctes, qui fournissent une gouvernance et une isolation des performances entre les unités commerciales.

Les caractéristiques suivantes s’appliquent à ce modèle :

• La référence SKU F ou P la plus grande possible attachée à un espace de travail détermine le nombre maximal d’unités de capacité qu’un espace de travail peut utiliser.

• Des espaces de travail distincts créent une décentralisation organisationnelle et de gestion.

• Les organisations peuvent évoluer au-delà d’une région à l’aide de capacités et d’espaces de travail dans différentes régions géographiques.

• Vous pouvez utiliser les fonctionnalités complètes de Fabric, car les unités commerciales peuvent avoir plusieurs espaces de travail dans des capacités distinctes et regroupées via des domaines Fabric.

• Les limitations de l’espace de travail pour un seul espace de travail s’appliquent, mais vous pouvez créer de nouveaux espaces de travail à mettre à l’échelle au-delà de ces limites.

• Des limitations spécifiques de capacité des SKU s’appliquent, mais vous pouvez étendre les unités de calcul à l’aide de capacités distinctes.

• Vous pouvez utiliser le catalogue OneLake pour découvrir Fabric éléments et leurs états de certification.

• Les domaines peuvent regrouper des espaces de travail de sorte qu'une seule unité métier puisse en exploiter et en gérer plusieurs.

• Les raccourcis OneLake éliminent les copies physiques de données pour réduire le déplacement des données. Les raccourcis OneLake offrent également un accès contrôlé et inter-espaces de travail via OneLake et ne transfèrent pas la propriété des données sous-jacentes.

Quand utiliser ce modèle

Vous pouvez implémenter ce modèle de déploiement si :

• Votre organisation veut déployer des frameworks architecturaux tels qu'un maillage de données ou une fabrique de données.

• Vous voulez privilégier la flexibilité dans la manière dont vous structurez les capacités et les espaces de travail.

• Vous travaillez dans différentes régions géographiques. Dans ce cas, créez une capacité et un espace de travail distincts pour passer à un modèle de déploiement multicapacité et multiworkspace.

• Vous travaillez à grande échelle et avez des exigences pour évoluer au-delà des limites d'un SKU à unité de capacité unique ou d'un espace de travail unique.

• Vous disposez de charges de travail qui doivent toujours se terminer dans un délai spécifique ou répondre à des objectifs de niveau de service (ONS) basés sur les performances. Vous pouvez configurer un espace de travail distinct avec capacité Fabric pour répondre aux objectifs de niveau de service (SLO) pour ces charges de travail.

Considérations relatives à la zone de conception

Le tableau suivant présente des considérations susceptibles d’influencer votre décision d’utiliser ce modèle de déploiement.

Modèle 4 : Plusieurs locataires Fabric

Dans ce modèle de déploiement, toutes les instances de Fabric sont des entités distinctes en ce qui concerne la gouvernance, la gestion, l’administration, l’échelle et le stockage.

Les caractéristiques suivantes s’appliquent à ce modèle :

• Les ressources des locataires sont strictement séparées.

• Les plans de gestion entre locataires sont séparés.

• Les locataires sont des entités distinctes, chacune avec ses propres processus de gouvernance et de gestion et chacune administré indépendamment.

• Vous pouvez utiliser des pipelines de données ou des capacités d'ingénierie des données pour partager ou accéder aux données entre les clients Fabric.

Quand utiliser ce modèle

Vous pouvez implémenter ce modèle de déploiement si :

• Votre organisation a plusieurs locataires Fabric en raison d’une acquisition d’entreprise.

• Votre organisation souhaite configurer un locataire Fabric spécifiquement pour une unité commerciale ou une filiale plus petite.

Évaluer d’autres plateformes

Si les exigences de votre organisation ne s'alignent pas sur les modèles de déploiement basés sur Fabric, tenez compte des alternatives contraintes suivantes :

• Azure Data Factory avec Data Lake Storage ou OneLake, y compris les architectures hybrides Data Factory et Fabric

  Les organisations qui ont besoin d’un contrôle d’orchestration explicite ou d’une modernisation par phases peuvent utiliser Data Factory pour l’ingestion et l’orchestration de pipeline et Data Lake Storage comme base de stockage. Dans un modèle hybride, les pipelines de données gérés par Data Factory peuvent charger des données dans OneLake, tandis que Fabric gère la création de ressources de données analytiques. Cette approche prend en charge l’adoption incrémentielle de Fabric et préserve les modèles d’intégration établis.

• Data Lake Storage, Azure Databricks et Power BI

  Les organisations qui préfèrent une architecture PaaS (Platform as a Service) plutôt qu’une plateforme SaaS (Software as a Service) unifiée peuvent créer un patrimoine de données à l’aide de Data Lake Storage pour le stockage, Azure Databricks pour l’ingénierie et l’analytique des données, et Power BI pour la modélisation sémantique et la création de rapports. Cette approche offre un contrôle et une flexibilité maximales, mais nécessite une augmentation de l’effort d’intégration et augmente la complexité opérationnelle et la surcharge de gouvernance.

Considérations

Ces considérations mettent en œuvre les piliers du Well-Architected Framework, qui est un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d'une charge applicative. Pour plus d’informations, consultez le Well-Architected Framework.

Les tables par modèle de motif précédemment décrites dans cet article utilisent des zones de conception spécifiques aux décisions de déploiement de Fabric, telles que la gouvernance, la sécurité, l’administration, DevOps, la facilité d’utilisation, les performances et la facturation. Les sous-sections suivantes fournissent des conseils complémentaires organisés par pilier du Cadre Well-Architected. Utilisez les tables par modèle pour comparer les modèles. Utilisez ces sous-sections pour obtenir des conseils architecturaux croisés qui s’appliquent quel que soit le modèle que vous choisissez.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d'informations, veuillez consulter la liste de vérification de la conception pour la fiabilité.

• Résilience régionale intégrée. Fabric fournit une résilience régionale intégrée via des zones de disponibilité, où elle est prise en charge. Fabric distribue automatiquement les ressources entre plusieurs zones sans configuration du client. La prise en charge des zones de disponibilité varie selon la région Azure. Pour vérifier si votre région cible prend en charge les zones de disponibilité pour Fabric, consultez Fabric disponibilité de la région.

• La reprise après sinistre nécessite une inscription volontaire et comporte des précautions. La récupération interrégion est disponible via un paramètre d'activation de DR (Disaster Recovery) sur la page des paramètres de capacité. Activez le paramètre de capacité de récupération d’urgence pour répliquer des données OneLake dans les régions jumelées d'Azure à l’aide de la réplication asynchrone.

  Important

  Certaines régions Azure ne sont pas associées à des régions qui prennent en charge Fabric, ce qui peut compromettre les fonctionnalités de récupération d'urgence même si les données sont répliquées. Étant donné que la réplication des données est asynchrone, les données écrites immédiatement avant un sinistre régional peuvent être perdues. Pour plus d’informations, consultez Reliability in Fabric.

• Les modèles à capacité unique concentrent les risques dans une région. Dans les modèles 1 et 2, les charges de travail se trouvent dans une région Azure. Si la région rencontre une panne, tous les espaces de travail sont affectés simultanément. Pour vous protéger contre les défaillances régionales, configurez le paramètre de capacité pour répliquer des données OneLake dans une région jumelée. Planifiez le temps de récupération nécessaire pour restaurer le service dans la région jumelée.

• Les modèles multicapacités offrent une isolation régionale naturelle. Dans les modèles 3 et 4, les capacités dans différentes régions signifient qu’une panne régionale affecte uniquement les capacités de cette région. Les charges de travail dans d’autres régions restent opérationnelles. Ces modèles prennent en charge les exigences de résidence des données et fournissent la base des stratégies régionales actives-passives ou actives-actives.

• La suspension de la capacité affecte la fiabilité. Si vous suspendez une capacité de Fabric pour réduire les coûts, toutes les charges de travail sur cette capacité deviennent indisponibles. Prenez en compte l’effet de fiabilité avant de suspendre une capacité qui prend en charge les charges de travail de production.

• Les raccourcis OneLake introduisent des dépendances externes. Les raccourcis vers des sources de données externes introduisent une dépendance à la disponibilité des sources. Si la source externe n’est pas disponible, les éléments qui s’appuient sur des raccourcis peuvent échouer. Surveillez l’intégrité des sources de données externes et planifiez une dégradation normale.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification pour la révision de conception concernant la sécurité.

• Le modèle de sécurité en couches s’étend sur trois niveaux. Fabric implémente un modèle de sécurité en couches qui s’étend aux niveaux du client, de l’espace de travail et des éléments. Votre choix de modèle de déploiement détermine la façon dont vous segmentez les limites de sécurité. Les modèles à espace de travail unique, tels que le modèle 1, appliquent l’accès uniforme. Les modèles multiworkspace, tels que les modèles 2, 3 et 4, prennent en charge les limites de sécurité par équipe ou par unité commerciale.

Identité et accès

• Appliquez des stratégies d’authentification au niveau du locataire à l’aide de l’accès conditionnel. Utilisez l’accès conditionnel pour appliquer des stratégies d’authentification au niveau du locataire, telles que l’authentification multifacteur, la conformité des appareils et les restrictions basées sur l’emplacement. L’accès conditionnel nécessite une licence Microsoft Entra ID P1.

• Utilisez des rôles d’espace de travail pour contrôler l’accès aux éléments. Attribuez des rôles d’espace de travail pour contrôler qui peut créer, modifier et consommer des éléments dans un espace de travail. Dans les modèles multiworkspace, tels que les modèles 2, 3 et 4, utilisez des espaces de travail distincts pour appliquer les limites de rôle entre les unités commerciales.

• Appliquez un accès granulaire au niveau des données à l’aide de rôles de sécurité OneLake. Utilisez des rôles de sécurité OneLake pour appliquer un contrôle d’accès granulaire au niveau table, dossier, colonne et ligne pour les utilisateurs du rôle Visionneuse. Les administrateurs, les membres et les contributeurs de l’espace de travail contournent ces rôles.

Sécurité du réseau

• Utilisez des liens privés pour le trafic entrant. Utilisez des liens privés pour acheminer le trafic entrant sur le réseau principal de Microsoft au lieu de l’Internet public. Les liens privés au niveau du locataire s’appliquent à tous les espaces de travail. Les liaisons privées au niveau de l’espace de travail fournissent une granularité par espace de travail.

• Utilisez des points de terminaison privés managés pour les connexions Spark sortantes. Utilisez des points de terminaison privés managed pour sécuriser les connexions sortantes à partir de charges de travail Spark vers des sources de données protégées par le pare-feu, telles que Data Lake Storage et Azure SQL Database.

• Utilisez des passerelles de données de réseau virtuel lorsque les liens privés au niveau du locataire bloquent les passerelles locales. Lorsque vous activez des liaisons privées au niveau du locataire, les passerelles de données locales ne peuvent pas s’inscrire. Utilisez une passerelle de données de réseau virtuel au lieu de ponts qui connectent des sources de données locales ou virtuelles protégées par un réseau virtuel.

Protection de données

• Appliquez des étiquettes de confidentialité pour la classification des données de bout en bout. Pour la classification et la protection des données, appliquez des étiquettes sensitivité de Microsoft Purview Information Protection aux données qui transitent par Fabric. Les étiquettes suivent les données de la source au rapport.

• Utilisez les journaux d’audit et les outils de conformité pour l’application des stratégies. Pour détecter et répondre aux violations de stratégie, passez en revue les journaux d'audit et utilisez Microsoft Purview Compliance Manager.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez la liste de vérification de conception pour l’optimisation des coûts.

• Coûts de modèle avant de déployer. Les modèles de déploiement affectent votre structure de coûts. Modélisez les coûts de votre scénario en utilisant Fabric tarification et l’estimateur de capacité Fabric.

• Ajustez votre capacité SKU. Ajustez la taille de votre SKU F en fonction des exigences de la charge de travail. Commencez par une référence SKU plus petite et effectuez un scale-up en fonction des besoins. Surveillez la consommation et identifiez les capacités sur provisionnée ou sous-approvisionnées à l’aide de l’application Fabric Capacity Metrics.

• Automatisez la suspension de la capacité pour les environnements hors production. Réduisez les coûts en interrompant les capacités de référence SKU F lorsqu’elles ne sont pas utilisées. Dans les environnements de développement/test, suspendez les capacités en dehors des heures de travail. La suspension rend toutes les charges de travail indisponibles. Envisagez donc l’automatisation via des API Azure Resource Manager Fabric ou des pipelines planifiés.

• Modèles à capacité unique, tels que les modèles 1 et 2, centralisent la facturation, mais limitent la refacturation. Une unité de capacité signifie une facture. La gestion des coûts est centralisée, mais la rétrofacturation aux unités commerciales individuelles n’est pas possible, car toutes les charges de travail partagent la même capacité.

• Modèles multicapacités, tels que les modèles 3 et 4, prennent en charge la rétrofacturation par équipe. Chaque capacité génère son propre compteur de facturation Azure. Vous pouvez facturer des coûts à l’unité commerciale responsable de chaque capacité. Vous pouvez ajuster ou suspendre indépendamment chaque capacité en fonction de la charge de travail qu’elle prend en charge.

• Gérez les coûts de stockage OneLake indépendamment. Le stockage OneLake est facturé à un tarif de paiement à l’utilisation par Go et ne consomme pas d’unités de gestion cloud. Supprimez régulièrement les données inutilisées, y compris les données supprimées de manière réversible et surveillez le stockage via l’application Métriques de capacité Fabric.

• Surveillez séparément le calcul Spark. Pour les charges de travail d’ingénierie des données, vous pouvez utiliser des pools Spark distincts pour déplacer les calculs en dehors du budget CU. Pour éviter les coûts inattendus, surveillez la consommation des unités de calcul Spark.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez Liste de vérification de la conception pour l'excellence opérationnelle.

• Utilisez des pipelines de déploiement pour une promotion échelonnée. Utilisez les pipelines de déploiement de Fabric pour faire passer le contenu par les phases de développement/test et de production. Les pipelines de déploiement nécessitent des espaces de travail distincts. Ils ne sont donc pas disponibles dans le modèle 1. Dans les modèles 2, 3 et 4, créez des espaces de travail dédiés pour chaque étape DTAP. La stratégie de capacité varie selon le modèle.

  • Dans le modèle 2, tous les espaces de travail DTAP partagent la même capacité, ce qui est rentable, mais ne fournit pas d’isolation des performances entre les environnements.

  • Dans le modèle 3, vous pouvez utiliser des capacités dédiées par environnement pour une isolation complète, ou vous pouvez équilibrer les coûts et l’isolation à l’aide d’une capacité partagée pour le développement/test avec une capacité de production distincte.

• Planifiez les environnements de préproduction en tant que décision de conception au niveau de l’espace de travail. Le modèle 1 ne fournit aucune séparation de préproduction, car le développement/test se produit dans l’espace de travail de production. Le modèle 2 prend en charge des espaces de travail de développement, de test et de production distincts sur une capacité partagée, qui convient à la validation fonctionnelle, mais pas aux tests de performances ou de résilience de type production. Le modèle 3 prend en charge la validation de préproduction de type production via des espaces de travail alignés sur l’environnement avec une isolation au niveau de la capacité. Le modèle 4 implique des locataires distincts plutôt que des décisions au niveau de l’espace de travail. Chaque locataire peut choisir indépendamment sa propre topologie d’environnement et n’a pas besoin de correspondre à d’autres locataires.

• Connectez des espaces de travail aux référentiels Git pour le contrôle de code source. Dans les modèles 2 et 3, des espaces de travail distincts par équipe ou charge de travail s’alignent sur des stratégies de branche standard. Dans le modèle 1, toutes les équipes partagent un référentiel unique, qui peut créer une contention de fusion.

• Surveillez la capacité et l'état de santé de la charge de travail. Utilisez l’application Métriques de capacité Fabric pour surveiller la consommation de capacité, comme l’utilisation de CU, la restriction et les dépassements. Vous pouvez accéder à des données de télémétrie détaillées sur les charges de travail individuelles à l’aide de la surveillance de l’espace de travail. Dans les modèles multicapacité, comme les modèles 3 et 4, vous pouvez déléguer la surveillance à l’équipe responsable de chaque capacité.

• Déléguer l’administration par le biais de domaines Fabric. Dans les modèles 2 et 3, déléguez les paramètres du client et la gestion de l’espace de travail aux administrateurs de domaine sans privilèges d’administrateur client en utilisant les domaines Fabric. Le modèle 1 ne peut pas utiliser de domaines, car tous les éléments se trouvent dans un espace de travail.

• Gérez les capacités à l’aide de l’infrastructure en tant que code (IaC). Créez et gérez des capacités Fabric à l’aide de Bicep ou Terraform. Stockez les définitions d’infrastructure dans le contrôle de code source en même temps que le code d’application.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

• Comprendre le comportement de dimensionnement et de limitation de capacité. Chaque capacité dispose d'une allocation de CU fixe déterminée par sa référence SKU. Si la demande dépasse les CUs disponibles, Fabric applique le throttling et place les demandes en file d'attente. Surveillez les événements de limitation grâce à l'application Fabric Capacity Metrics et augmentez le SKU ou distribuez les workloads sur plusieurs capacités en fonction des besoins.

• Isolez les charges de travail sensibles aux performances sur une capacité dédiée. Dans les modèles 1 et 2, toutes les charges de travail sont en concurrence pour les mêmes unités de calcul. Une requête ou un pipeline de données coûteux peut dégrader les performances des requêtes interactives pour d’autres utilisateurs. Dans les modèles 3 et 4, vous pouvez isoler les charges de travail sensibles à la performance sur une capacité dédiée avec une allocation de CU garantie.

• Configurez des pools Spark pour les charges de travail d’ingénierie des données. Pour les charges de travail d’ingénierie des données, utilisez des pools Spark personnalisés pour contrôler le nombre minimal et maximal de nœuds et prendre en charge la mise à l’échelle automatique. Les réseaux virtuels managés désactivent les pools de démarrage ou les clusters partagés prédéfinis, ce qui augmente le temps de démarrage de la session de secondes à 3 à 5 minutes.

• Placez les capacités proches des producteurs de données et des consommateurs. Dans le modèle 3, vous pouvez utiliser des capacités dans des régions proches des producteurs de données ou des consommateurs, ce qui réduit la latence entre régions. Les raccourcis OneLake peuvent référencer des données dans d’autres régions, mais les lectures interrégions entraînent des coûts de latence et de sortie.

• Appliquez des techniques d’optimisation spécifiques à la charge de travail. Améliorez les performances de balayage à l'aide de Z-Ordering et V-Ordering pour les lakehouses. Pour les entrepôts, optimisez les modèles de requête pour lire des lots plus petits. Réduisez la charge de capacité par rapport au mode Importation à l’aide de Direct Lake mode pour les rapports Power BI.

Matrice de capacité

Les tableaux suivants résument les principales différences dans les fonctionnalités de chaque modèle.

Gouvernance et administration

¹ Les espaces de travail fournissent une certaine isolation, mais tous les espaces de travail partagent une seule capacité, ce qui limite la granularité du suivi et de l’administration de l’utilisation.

² Modèle 4 utilise des locataires distincts plutôt que des domaines. Chaque locataire a son propre modèle d’administration.

Sécurité

Gestion du cycle de vie et devOps

³ Les pipelines de déploiement nécessitent des espaces de travail distincts, qui ne sont pas disponibles dans un modèle monolithique à espace de travail unique.

^{L’intégration Git 4} est disponible, mais toutes les équipes partagent un dépôt unique, qui peut créer une contention de fusion.

Performance et mise à l’échelle

Le risque de limitation est faible si les charges de travail se trouvent sur des capacités dédiées, mais la limitation peut toujours se produire dans une seule capacité si la demande dépasse les unités de capacité disponibles.

Gestion de la facturation et des coûts

⁶ Chaque capacité génère son propre compteur de facturation, de sorte que la facturation est distribuée entre les capacités plutôt que centralisée.

Contributeurs

Microsoft conserve cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• Amanjeet Singh | Responsable du programme principal

Autres contributeurs :

• Lorrin Ferdinand | Principal Consultant
• Holly Kelly | Responsable principale du programme
• Gabi Muenster | Responsable du programme senior
• Sarah Sasidharan | Responsable du programme senior

Pour afficher les profils de LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Concepts et licences Fabric
• Espaces de travail Fabric
• domaines Fabric
• Qu’est-ce que OneLake ?
• Pipelines de déploiement de Fabric
• Reliability in Fabric
• Vue d’ensemble de la sécurité de Fabric

Ressources associées

• Vue d’ensemble des choix technologiques
• Analytics intégration complète avec Fabric
• Intelligence d'affaires d'entreprise avec Fabric
• Builder un lac de terrain vert avec Fabric