Microsoft Fabric デプロイ パターン

この記事では、Microsoft Fabric をデプロイするときに選択できる 4 つのデプロイ パターンについて説明します。 各デプロイ パターンに関する考慮事項、推奨事項、および非可逆的決定の可能性について説明します。

各 Fabric デプロイ パターンについて、次の設計領域について説明します。

• ガバナンス
• セキュリティ
• 管理
• DevOps
• 使いやすさ
• パフォーマンスとスケール
• 請求とコスト管理

Fabric デプロイのレベル

Fabric のデプロイには、テナント、容量、ワークスペース、項目の 4 つのレベルがあります。 最上位レベルは Fabric テナントです。 各テナントには 1 つ以上の容量を含めることができます。各容量には 1 つ以上のワークスペースを含めることができます。また、各ワークスペースには 0 個以上の Fabric アイテムを含めることができます。

セキュリティ、スケール、ガバナンス、およびアプリケーション ライフサイクルの領域における組織の構造または目標は、デプロイ パターンの選択に影響を与える可能性があります。 デプロイ パターンが異なると、デプロイのレベルにさまざまな柔軟性と強調が提供されます。

たとえば、組織はドメインを使用すると、Fabric でワークスペースをグループ化できます。 同様に、組織が共同作業やコンテンツの検索に使用できる一元化されたオプションが必要な場合、Fabric の OneLake データ ハブ は一元化されたアクセス ポイントを提供し、Microsoft Teams や Excel などの他の使い慣れた製品と統合されます。

Fabric では、異なる地理的な場所に部署を持つ大規模な組織は、容量を使用してそのデータが存在する場所を制御できます。 Fabric ドメインを使用すると、異なる地理的な場所から動作する事業部門を 1 つのユニットとして管理できます。これは、ドメインが異なる地域のワークスペースに及ぶためです。

デプロイ パターンを選択する際の Fabric レベルとその役割の詳細については、「Microsoft Fabric の概念とライセンス」を参照してください。

Fabric デプロイ パターンの配置方法

すべての Fabric デプロイ パターン:

• スケール、ガバナンス、セキュリティの境界として Fabric ワークスペースを使用します。
• 同じ部署に属する複数のワークスペースを管理する場合や、部署に属するデータが複数のワークスペースにまたがる場合はFabric ドメイン を使用します。 ドメイン レベルでデータを管理するためのテナント レベルの設定をいくつか設定すると、それらの設定にドメイン固有の構成を使用できます。
• Fabric 容量を使用してコンピューティング リソースをスケーリングし、特定のパフォーマンス レベルを満たす必要がある場合は、ワークスペースごとに専用の容量をプロビジョニングします。
• 機能が Fabric で使用できない場合は、Microsoft クラウド (Microsoft Azure、Microsoft 365 など) から同等の機能を使用するように拡張します。
• OneLake データ ハブを使用して、データ資産の検出と使用を促進します。
• OneSecurity を使用して、データ資産のデータ セキュリティ ポリシーを設定します。

ビジネス要件に基づくシナリオ

この記事では、次のシナリオを使用して、各デプロイ パターンがさまざまなビジネス要件にどのように対処できるかについて説明します。

• シナリオ 1: データの使用に対する制限を低くして、複数の分野にまたがって協働できるチームを編成することで、市場投入までの時間を短縮 (または低速) したい組織向け。 このシナリオでは、モノリシック展開パターンを使用すると組織が有利になります。 組織は、1 つのワークスペースで運用および管理します。 詳細については、「パターン1: モノリシック デプロイ」を参照してください。
• シナリオ 2: インフラストラクチャの提供と管理を担当する中央チームと共に、チームが作業するための分離された環境を提供する必要がある組織向け。 このシナリオは、データ メッシュを実装する組織にも適しています。 このシナリオでは、組織は、共有容量を使用するか、個別の容量を持つ複数のワークスペースを実装できます。 詳細については、「パターン 2: 1 つの Fabric 容量によってサポートされる複数のワークスペース」および「パターン 3: 個別の容量によってサポートされる複数のワークスペース」を参照してください。
• シナリオ 3: 部署またはチームが独自のデータ プラットフォームを制御および管理する自由性を与える、完全に分散化されたモデルを必要とする組織向け。 このシナリオでは、組織はそれぞれ専用の容量を持つ場合や、場合によっては複数の Fabric テナントを使用する個別のワークスペースを使用するデプロイ モデルを選択できます。 詳細については、「パターン 3: 個別容量でサポートされている複数のワークスペース」および「パターン 4: 複数の Fabric テナント」を参照してください。
• シナリオ 4: 組織は、複数のパターンを組み合わせて要件を満たすハイブリッド アプローチを使用することを選択できます。 たとえば、組織は、他の部署用に個別の専用ワークスペースと個別の容量を使用しながら、特定の事業単位 (モノリシック展開パターン) 用に 1 つのワークスペースを設定できます。

パターン 1: モノリシック デプロイ

このデプロイ パターンでは、すべてのユース ケースに対応するために 1 つのワークスペースをプロビジョニングします。 すべての部署は、同じ 1 つのワークスペース内で動作します。

1 つの Fabric 容量をプロビジョニングし、それに 1 つのワークスペースをアタッチする場合、次の点が該当します。

• すべての Fabric アイテムは、同じプロビジョニングされた容量を共有します。 他のワークロードで同じ容量が使用されるため、クエリまたはジョブの完了にかかる時間は異なります。
• ワークスペースの最大容量ユニット (CU) は、可能な限り最大の F SKU または P SKU に制限されます。 Data Engineering エクスペリエンスでは、個別の Spark プールをプロビジョニングして、プロビジョニングされた CU の外部で Fabric Spark に必要なコンピューティング容量を移動できます。
• ワークスペースを対象とする機能は、そのワークスペースを共有するすべての部署に適用されます。
• すべてのワークスペース項目とデータは、1 つのリージョンに存在します。 このパターンは、複数地域のシナリオには使用できません。
• デプロイ パイプラインやライフサイクル管理など、複数のワークスペースに依存する機能は使用できません。
• 1 つのワークスペースに関連付けられている制限が適用されます。
• 特定の SKU に関連付けられている容量の制限が適用されます。

次の 1 つ以上の理由から、このデプロイ パターンを実装することを選択できます。

• 組織には複雑なエンジニアリング要件がない、ユーザー ベースが小さい、またはセマンティック モデルが小さい。
• 組織は 1 つのリージョンで動作する。
• 主に、部署間の組織の分離に関心がない。
• 組織では、Git とコード リポジトリを共有するなど、ワークスペース単位の機能は不要。
• レイクハウス メダリオン アーキテクチャを実装したい。 組織が 1 つのワークスペースに制限されている場合は、ワークスペース内に別のレイクハウスを作成することで、ブロンズ、シルバー、ゴールドのレイヤーを個別に実現できます。
• 組織の部署はロールを共有しており、ワークスペース内のユーザーに対して同じワークスペース レベルのアクセス許可を持つことが許容されます。 たとえば、異なる部署に属する複数のユーザーが 1 つのワークスペースの管理者である場合、ワークスペース内のすべてのアイテムに対して同じ権限を持ちます。
• 組織は、ジョブの完了時間の変動を許容できます。 組織にパフォーマンス保証の要件がない場合 (たとえば、ジョブは特定の期間に完了する必要があるなど)、部署間でプロビジョニングされた容量を 1 つ共有することは許容されます。 容量が共有されている場合、ユーザーはいつでもクエリを実行できます。 ジョブを実行できる CU の数は、容量で実行されている他のクエリによって異なります。 ジョブの完了時間が変動する可能性があります。
• 組織は、1 つの Fabric 容量を使用して、(CU の観点から) すべてのビジネス要件を達成できます。

次の表に、このデプロイ パターンを採用する決定に影響を与える可能性がある考慮事項を示します。

パターン 2: 1 つの Fabric 容量でサポートされる複数のワークスペース

このデプロイ パターンでは、個別のワークスペースを使用します。 1 つの容量がワークスペース間で共有されるため、いつでも同時に実行されるワークロードは、ジョブと対話型クエリのパフォーマンスに影響する可能性があります。

1 つの Fabric 容量をプロビジョニングし、それに複数のワークスペースをアタッチする場合、次の点が該当します。

• すべての Fabric アイテムは、同じプロビジョニングされた容量を共有します。 他のワークロードで同じ容量が使用されるため、クエリまたはジョブの完了にかかる時間は異なります。
• ワークスペースで使用できる最大 CU は、可能な限り最大の F SKU または P SKU に制限されます。 Data Engineering エクスペリエンスでは、個別の Spark プールをプロビジョニングして、プロビジョニングされた CU の外部で Fabric Spark に必要なコンピューティング容量を移動できます。
• ワークスペースを対象とする機能は、そのワークスペースを共有するすべての部署に適用されます。
• すべてのワークスペース項目とデータは、1 つのリージョンに存在します。 このパターンは、複数地域のシナリオには使用できません。
• デプロイ パイプラインやライフサイクル管理など、個別のワークスペースを必要とする DevOps 機能を使用できます。
• 1 つのワークスペースに関連付けられている制限が適用されます。
• 特定の SKU に関連付けられている容量の制限が適用されます。

次の 1 つ以上の理由から、このデプロイ パターンを実装することを選択できます。

• 組織が分析環境の運用の一部の側面を一元化し、他の部分を分散化するハブアンドスポーク アーキテクチャが必要です。
• 運用と管理の側面から分散化が必要ですが、程度はさまざまです。 たとえば、メダリオン アーキテクチャのブロンズ レイヤーとシルバー レイヤーを 1 つのワークスペースにデプロイし、ゴールド レイヤーを別のワークスペースにデプロイすることができます。 根拠は、1つのチームがブロンズ レイヤーとシルバー レイヤーを担当し、別のチームがゴールド レイヤーの運用と管理を担当している可能性があります。
• パフォーマンスの管理と、パフォーマンスの観点からのワークロードの分離について、主に心配しているわけではありません。
• レイクハウス メダリオン アーキテクチャの観点から、組織は、ブロンズ、シルバー、ゴールドの各レイヤーを実装するための個別のワークスペースを作成できます。
• 組織は、異なる地理的リージョンにワークロードをデプロイする必要はありません (すべてのデータが 1 つのリージョンに存在する必要があります)。
• 次の 1 つ以上の理由により、組織でワークスペースの分離が必要になる場合があります。
  • ワークロードを担当するチームのメンバーは、異なるワークスペースにあります。
  • ワークロードの種類ごとに個別のワークスペースを作成する必要があります。 たとえば、データ インジェスト用のワークスペース (データ パイプライン、データフロー Gen2、またはデータ エンジニアリング) を作成し、Data Warehouse を介して使用する別のワークスペースを作成できます。 この設計は、個々のチームが各ワークロードを担当する場合に適しています。
  • 1 つまたは複数のワークスペースが Fabric ドメインでグループ化されるデータ メッシュ アーキテクチャを実装する必要があります。
• 組織では、データ分類に基づいて個別のワークスペースをデプロイすることを選択できます。

次の表に、このデプロイ パターンをする決定に影響を与える可能性がある考慮事項を示します。

パターン 3: 個別の容量によってサポートされる複数のワークスペース

このデプロイ パターンでは、ガバナンスとパフォーマンスのために部署間の分離を実現します。

独自のワークスペースを使用して複数の Fabric 容量をプロビジョニングする場合、次の点が該当します。

• ワークスペースにアタッチされている最大の F SKU または P SKU によって、ワークスペースで使用できる最大 CU が決まります。
• 組織と管理の分散化は、個別のワークスペースをプロビジョニングすることによって実現されます。
• 組織は、異なる地理的リージョンに容量とワークスペースをプロビジョニングすることで、1 つのリージョンを超えてスケーリングできます。
• 部署には、個別の容量に含まれる 1 つ以上のワークスペースがあり、Fabric ドメインを使用してグループ化できるため、Fabric のすべての機能を使用できます。
• 1 つのワークスペースに関連付けられている制限が適用されますが、新しいワークスペースを作成することで、これらの制限を超えてスケーリングできます。
• 特定の SKU に関連付けられている容量の制限が適用されますが、個別の容量をプロビジョニングすることで CU をスケーリングできます。
• テナント内のすべてのワークスペース内のすべての Fabric アイテムとその認定資格証状態は、OneLake データ ハブを使用して検出できます。
• ドメインでは、1 つの部署が複数のワークスペースを操作および管理できるように、ワークスペースをグループ化できます。
• OneLake ショートカットを使用すると、データ移動が減り、ワークスペース全体のデータの使いやすさも低下します。

次の 1 つ以上の理由から、このデプロイ パターンを実装することを選択できます。

• 組織は、データ メッシュやデータ ファブリックなどのアーキテクチャ フレームワークをデプロイしたいと考えています。
• 容量とワークスペースを構成する方法の柔軟性に優先順位を付ける必要があります。
• 異なる地理的リージョンで運用しています。 この場合、別の容量とワークスペースをプロビジョニングすることが、このマルチ容量とマルチワークスペースのデプロイ パターンに移行する原動力となります。
• 大規模に運用しており、単一容量 SKU または 1 つのワークスペースの制限を超えてスケーリングする要件があります。
• 特定の時間内に常に完了するか、特定のパフォーマンス SLA を満たす必要があるワークロードがあります。 これらのワークロードのパフォーマンスの保証を満たすために、Fabric 容量によってサポートされる個別のワークスペースをプロビジョニングできます。

次の表に、このデプロイ パターンをする決定に影響を与える可能性がある考慮事項を示します。

パターン 4: 複数の Fabric テナント

個別の Fabric テナントがデプロイされると、Fabric のすべてのインスタンスは、ガバナンス、管理、アドミン、スケール、ストレージに関して個別のエンティティになります。

複数の Fabric テナントを使用する場合、次の点が該当します。

• テナント リソースは厳密に分離されます。
• テナント間の管理プレーンは別々です。
• テナントは個別のエンティティであり、ガバナンスと管理のための独自のプロセスを持つことができますが、個別に管理することもできます。
• データ パイプラインまたはData Engineering 機能を使用して、Fabric テナント間でデータを共有またはアクセスできます。

次の理由から、このデプロイ パターンの実装を選択できます。

• ビジネスの買収により、組織は最終的に複数の Fabric テナントを使用する可能性があります。
• 組織は、部門または小規模な子会社専用に Fabric テナントを設定することを選択できます。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

• ホーリー・ケリー | プリンシパル プログラム マネージャー
• ガビ・ミュエンスター | シニア プログラム マネージャー
• サラス・サシダーラン | シニア プログラム マネージャー
• Amanjeet Singh | プリンシパル プログラム マネージャー