【Microsoft Fabric⑤】運用とガバナンス｜容量・コスト・CI/CD・閉域

Azure

いよいよMicrosoft Fabricシリーズの最終回です。第1〜4回で、Fabricの「集める→整える→可視化する→リアルタイム／AIで活用する」を一通り見てきました。しかし実務では、作って終わりではありません。「コストを管理し、変更を安全にリリースし、データを閉域とガバナンスで守る」——この運用の3点セットが揃って、初めて本番で使える分析基盤になります。今回はその締めくくりを整理します。

Fabricの機能は分かってきた。でも「いくらかかるの？」「本番にどう反映するの？」「セキュリティは？」の運用面が、いちばん不安なんだよね。

この記事は、Fabricシリーズの第5回（最終回）として、運用の3テーマを整理します。

  • 容量（F SKU）/ コスト管理 を理解している
  • Git統合 / デプロイパイプライン（CI/CD）を理解している
  • プライベートリンク / Entra・Purview（閉域・ガバナンス）を理解している

容量（F SKU）とコスト管理

第1回で、Fabricの処理を動かすエンジンが 容量（Capacity） だと整理しました。この容量が、そのままコストの中心になります。

Fabricの課金は、容量のサイズを表す F SKU（F2〜F2048）を単位とし、その容量が供給する CU（Capacity Unit）の消費で計算されます。ワークロードの種類ごとに別料金ではなく、「1つの容量をみんなで使う」というシンプルな考え方です。

F SKUの数字は容量の大きさで、F2が最小、F2048が最大。数字が2倍になれば、おおむねパワーも料金も2倍というイメージです。ノートブックの実行もパイプラインの処理もPower BIのクエリも、すべてこの1つの容量のCUを分け合って消費します。

【容量とCU消費のイメージ】

  容量 F64（CUプールを供給）
  ┌───────────────────────────┐
  │  ノートブック実行  ██        │
  │  パイプライン処理  ███       │  ← 全部が同じCUプールを
  │  Power BIクエリ   ██        │     分け合って消費
  │  Data Agent       █         │
  └───────────────────────────┘
   使用量が容量を超えそう → スロットリング or 上位SKUへ

  ★「容量メトリックアプリ」で使用量を監視できる

コスト管理の要は 「容量メトリックアプリ」 です。これで「どのワークスペースの・どの処理が・どれだけCUを食っているか」を可視化でき、上限に近づいていないか監視できます。Azureのコスト分析で「増分を特定して原因を追う」のと同じ発想で、Fabricでも使用量を見て、必要なら容量サイズを上げ下げするのが運用の基本です。

容量はIaCでも管理できます。オーナーの得意なTerraform（azurerm）なら、Fabric容量リソースはこう書けます（Bicepではなくazurermで統一）。

# Terraform (azurerm) で Fabric 容量を作成する例
resource "azurerm_fabric_capacity" "this" {
  name                = "fabriccap01"
  resource_group_name = azurerm_resource_group.this.name
  location            = "japaneast"

  sku {
    name = "F64"   # F2〜F2048 から選ぶ
    tier = "Fabric"
  }

  administration_members = ["admin@example.com"]

  tags = {
    env = "prod"
  }
}

Terraformで容量を管理しておけば、「検証環境はF2、本番はF64」のようにコードで環境差を明示でき、増減もplan差分で安全に確認しながら反映できます。一時的に使わない時間帯は容量を一時停止（pause）して課金を止める、といった運用もしやすくなります。

【ここが説明できればOK①】
「Fabricの課金はF SKU（F2〜F2048）のCU消費で決まり、全ワークロードが同じ容量を分け合う。容量メトリックアプリで使用量を監視し、必要に応じてサイズ調整や一時停止でコスト管理する」——これを説明できれば、1つ目のチェックはクリアです。

Git統合とデプロイパイプライン（Fabric のCI/CD）

次は、作った成果物を「安全に本番へ届ける」仕組みです。ノートブックやパイプライン、セマンティックモデルを本番ワークスペースで直接編集していると、ミスがそのまま事故になります。ここでFabricが用意しているのが Git統合 と デプロイパイプライン です。CI/CDの経験があれば、考え方はそのまま通用します。

  • Git統合：ワークスペースをGit（Azure DevOps ReposやGitHub）に接続し、成果物をソース管理する仕組み。ノートブックやレポートの変更履歴を残し、ブランチで作業し、レビューを経てマージ——という開発フローをFabricの成果物にも適用できます。
  • デプロイパイプライン：開発 → テスト → 本番という複数ワークスペース間で、成果物を環境昇格させる仕組み。開発ワークスペースで検証したものを、ワンクリック（や自動化）で本番へ押し上げます。
【FabricのCI/CD：Git統合 × デプロイパイプライン】

  Git リポジトリ（ソース管理・履歴・レビュー）
        │ 接続
        ▼
 ┌──────────┐   昇格   ┌──────────┐   昇格   ┌──────────┐
 │ 開発       │ ──────► │ テスト     │ ──────► │ 本番       │
 │ワークスペース│          │ワークスペース│          │ワークスペース│
 └──────────┘          └──────────┘          └──────────┘
   ↑ここで開発            ↑ここで検証            ↑利用者はここ

→ 本番を直接いじらず、検証を通ったものだけを昇格

ポイントは、「本番ワークスペースを直接編集しない」という当たり前の規律を、Fabricの成果物にも持ち込める点です。GitHub ActionsやAzure DevOpsでアプリをデプロイするのと同じで、変更はソース管理し、検証環境で確認し、承認を経て本番へ。前回のData Agentも含め、Fabricの多くの成果物がこのGit統合・デプロイパイプラインに対応しています。分析基盤にもソフトウェア開発と同じ「事故らないリリース」の型を適用できる、と理解しておきましょう。

「Git統合＝ソース管理、デプロイパイプライン＝環境昇格」。CI/CDの発想がそのままデータ基盤にも来た、と考えれば怖くないね！

【ここが説明できればOK②】
「Git統合でFabricの成果物をソース管理し、デプロイパイプラインで開発→テスト→本番へ環境昇格する。本番を直接編集せず、検証を通ったものだけを昇格させるCI/CDの型」——これを説明できれば、2つ目のチェックはクリアです。

プライベートリンクとEntra・Purview（閉域・ガバナンス）

最後は、データを守る「閉域」と「ガバナンス」です。組織の重要データを扱う以上、「誰が入れるか」「どこから来られるか」「何を見られるか」を制御しなければなりません。Fabricでは大きく2方向で守ります。

  • プライベートリンク（Private Link）＝経路を閉じる：テナントやワークスペースへの接続を、インターネット経由ではなくプライベートな経路（プライベートIP）に限定します。「公開された入口をなくし、社内ネットワークからしか到達できない」状態を作る、閉域化の中核です。
  • Microsoft Entra ID ＝誰かを確かめる：Fabricへのアクセスは Entra ID（旧Azure AD）認証で統制されます。組織のID基盤と統合され、多要素認証や条件付きアクセスもそのまま効きます。
  • Microsoft Purview ＝中身を統治する：FabricにはPurviewが標準で組み込まれています。機密ラベルの付与、アクセスポリシー、DLP（情報漏えい防止）、監査を、ワークスペースをまたいで一貫して適用できます。第4回のData Agentが「ユーザー権限とPurviewを尊重する」と言っていたのは、まさにこの土台があるからです。
【閉域とガバナンスの3層】

  経路   ： Private Link  → プライベートIP経由に限定
                            （公開の入口をなくす）
  ID     ： Entra ID       → 誰がアクセスできるかを認証
                            （MFA・条件付きアクセス）
  中身   ： Purview        → 機密ラベル・DLP・監査
                            （何を見られるか／記録を残す）

  → 「経路・ID・中身」の3方向でデータを守る

この3つは、Azureの閉域設計で学ぶ「Private Endpointで経路を閉じ、Entra IDでIDを固め、ガバナンスで統制する」という発想の、Fabric版そのものです。個別のAzureサービスで閉域・ID・ガバナンスを設計してきた経験は、Fabricでもそっくり活きます。逆に言えば、Fabricを機に「閉域ネットワーク設計」を体系立てて整理し直すのは、良い学習の機会になります。

【ここが説明できればOK③】
「Private Linkで経路を閉域化し、Entra IDでアクセスを認証し、標準搭載のPurviewで機密ラベル・DLP・監査を効かせる。経路・ID・中身の3方向でFabricのデータを守る」——これを説明できれば、3つ目のチェックはクリアです。

まとめ：Microsoft Fabricシリーズ全5回の総まとめ

最終回の運用3テーマを振り返ります。

  • 容量 / コスト管理：F SKUのCU消費で課金。容量メトリックアプリで監視し、Terraformで環境差を管理
  • Git統合 / デプロイパイプライン：成果物をソース管理し、開発→テスト→本番へ環境昇格するCI/CD
  • Private Link / Entra・Purview：経路・ID・中身の3方向でデータを守る

シリーズ全体を通して、Fabricの本質は「OneLakeという1つの湖を、役割別のワークロードが共有する」一枚岩の構造にありました。データのコピーをなくし、Direct Lakeで速さと鮮度を両立し、Data Agentで自然言語の窓口まで用意する——そのすべてがOneLakeの上に成り立っています。お疲れさまでした。この5回を自分の言葉で説明できれば、Microsoft Fabricの土台はしっかり身についています。

Microsoft Fabricシリーズ 全5回

あわせて読みたい

タイトルとURLをコピーしました