跳到主要内容

Azure FabricとSQL Databaseミラーリング

Microsoft Fabricの**ミラーリング（Mirroring）**機能を使用すると、Azure SQL Databaseのデータをリアルタイムに近い形でFabric OneLakeに複製し、Power BIなどの分析ツールで即座にデータを利用できるようになります。

この記事では、ミラーリングの仕組み、本番データベースへの負荷、およびPower BIの従来の接続モードとの違いについて解説します。

Microsoft Fabricとミラーリングの概要​

Microsoft Fabricは、データエンジニアリング、統合、サイエンス、分析、BIを統合したSaaSプラットフォームです。

ミラーリングは、Azure SQL Databaseなどの運用データベースからFabricのOneLake（統合データレイク）へ、データを継続的かつ自動的に複製する機能です。データはオープンなDelta Parquet形式で保存され、Fabric上のすべてのワークロード（SQL分析エンドポイント、Spark、Power BI）から直接アクセス可能になります。

主な特徴​

  • ノーコード・ゼロETL: 複雑なETLパイプライン（Data Factoryなど）を構築・管理する必要がありません。
  • Near Real-Time: データの変更は数秒〜数分でFabric側に反映されます。
  • Direct Lake: Power BIからデータをインポートすることなく、OneLake上のDelta Parquetファイルを直接読み取るため、インポート並みの高速パフォーマンスを提供します。
  • セキュアな接続: ワークスペースID (Workspace Identity) を利用することで、パスワード管理不要のセキュアな認証が可能です。

アーキテクチャと仕組み​

Azure SQL Databaseのミラーリングは、従来のSQLトリガーや定期的なクエリ実行ではなく、トランザクションログの変更を検知する技術に基づいています。

  1. 変更検知: Azure SQL Databaseのエンジン内部にあるChange Feed機能が、トランザクションログ（Transaction Log）をスキャンし、データの変更（INSERT/UPDATE/DELETE）を特定します。
  2. ランディングゾーンへの転送: 変更データはFabric管理下のランディングゾーンにプッシュされます。
  3. Deltaテーブルへの適用: Fabric側のレプリケーターが変更データを処理し、OneLake上のDelta Parquetテーブルにマージします。

このプロセスは完全にマネージドサービスとして提供され、ユーザーは複製の詳細を気にする必要がありません。

本番データベースへの負荷影響​

ミラーリングを導入する際、最も重要な懸念事項は**「本番のトランザクション処理（OLTP）に影響を与えるか？」**という点です。

全体的な評価​

ミラーリングは、従来の「全件または差分SELECTクエリを実行するETL」と比較して、本番データベースへの負荷は大幅に低い設計になっています。しかし、ゼロではありません。

リソース消費（CPU/IO）​

  • ログスキャン: トランザクションログを読み取るために、ソースデータベースのCPUとIOリソースを消費します。
  • 初期スナップショット: ミラーリング開始時（または再シード時）には、全テーブルのデータを読み取るため、一時的に高い負荷がかかる可能性があります。
  • バックオフ機能: システムが過負荷を検知した場合、ミラーリングプロセスは自動的にバックオフ（速度抑制）を行い、本番ワークロードを優先する仕組みがあります。

ログ領域への影響（重要）​

  • ログの切り捨て遅延: ミラーリングが停止したり、大幅に遅延したりすると、未転送のログレコードを保持するためにトランザクションログの切り捨て（Truncation）が保留される可能性があります。これにより、ログファイルが肥大化し、最悪の場合はディスク容量不足で更新ができなくなるリスクがあります。
  • この挙動は、レプリケーションやCDC（Change Data Capture）と同様です。

結論​

  • 一般的なワークロードでは安全に使用できます。
  • 非常に書き込みが激しいシステムや、リソースに余裕がない（DTU/vCore使用率が常に高い）システムでは、事前にPoC（概念実証）を行うことを推奨します。

Power BI接続モードとの比較​

Power BIでAzure SQL Databaseをデータソースとする場合、従来は「インポート」と「DirectQuery」が主流でした。ミラーリング（Direct Lake）は第3の、そしてしばしば最適な選択肢となります。

特徴ミラーリング (Direct Lake)インポート (Import Mode)DirectQuery
ソースDBへの負荷低 - 中
ログベースの複製のため効率的。
分析クエリはソースに飛ばない。		一時的に高
更新時に大量のSELECTが走る。
分析クエリはソースに飛ばない。		高 - 非常に高
レポート操作ごとにソースへクエリが飛ぶ。
同時接続数が増えると危険。
データの鮮度ほぼリアルタイム
(数秒〜数分遅延)		低い
スケジュール更新（1日8回/48回など）に依存。		リアルタイム
常に最新データを表示。
レポート表示速度非常に高速
FabricのコンピュートでParquetを直接読む。		非常に高速
Power BIメモリ上のデータを読む。		遅い
ソースDBの応答速度とネットワークに依存。
ETLの必要性不要 (自動同期)必要 (Power Queryで加工)不要

推奨される使い分け:

  • ミラーリング: リアルタイムに近い分析が必要で、ソースDBへの分析クエリ負荷をゼロにしたい場合、または大規模データを扱う場合。
  • インポート: データ量が少なく、Fabricを使用しないスタンドアロンのPower BIレポートの場合。
  • DirectQuery: 厳密なリアルタイム性が必須（秒単位の遅れも許容できない）な場合のみ。ただしパフォーマンスチューニングが困難。

課金とコストへの影響​

各接続モードには、異なる課金発生ポイントがあります。

  1. ミラーリング (Fabric)

    • OneLakeストレージ: 複製データの保存容量に対して課金されます（Azure Data Lake Storage Gen2相当）。
    • Fabric容量 (Compute): データの閲覧・クエリ（Power BIからのアクセスなど）にはCapacity Unit (CU)を消費します。
    • 複製プロセス: SQL DBからOneLakeへの複製処理自体のコンピュートは無料です（CUを消費しません）。

  2. インポート (Import Mode)

    • Power BIライセンス: データセットサイズに応じてPro, Premium Per User, Premium容量の契約が必要です。
    • 隠れたコスト: データ更新時の高負荷に耐えるため、ソースDBを一時的に高価なティア（vCore増強など）にする必要がある場合があります。また、リージョン間転送が発生する場合はデータ送信料がかかります。

  3. DirectQuery

    • ソースDBリソース: レポートユーザーの操作ごとにクエリが飛ぶため、快適なレスポンスを維持するにはソースDBを大幅にオーバープロビジョニング（高スペック化）する必要があり、結果的に最も高コストになる可能性があります。

制限事項と前提条件​

導入前に以下の制限と前提条件を確認してください（詳細は公式ドキュメントを参照）。

  1. サービス階層の要件
    • vCoreモデル: すべてのサービス階層がサポートされています。
    • DTUモデル: 100 DTU未満のデータベースはサポートされていません（Free, Basic, Standard S0-S2は不可）。Standard S3以上、またはPremiumが必要です。
  2. 排他機能
    • 既にCDC (Change Data Capture) や Azure Synapse Link for SQL が有効になっているデータベースでは、ミラーリングを有効にできません。
  3. ネットワーク要件
    • Azure SQL Databaseのファイアウォール設定で「Azure サービスおよびリソースがこのサーバーにアクセスすることを許可する」を有効にする必要があります。
    • または、プライベートエンドポイントやVNet統合を使用している場合は、ミラーリング接続用に適切なネットワーク設定が必要です。
  4. テーブル要件:
    • 主キー（Primary Key）を持つテーブルが推奨されます（一部ヒープテーブルのサポートも進行中ですが、主キーありが基本です）。
    • 特定のデータ型（JSON, Geometryなど）や機能（Temporal Tablesなど）には制約がある場合があります。

セキュリティと認証 (ベストプラクティス)​

Microsoftは、SQL Databaseへの接続にワークスペースID (Workspace Identity) を使用することをベストプラクティスとして推奨しています。

推奨構成: ワークスペースID (Managed Identity) の設定​

ワークスペースIDを使用することで、パスワード管理が不要になり、ワークスペースのライフサイクルと権限が同期する（ワークスペースを削除すると権限も消える）ため、セキュリティリスクを最小限に抑えられます。

前提条件:

  • Fabric管理ポータルで「ワークスペースIDを使用する」設定が有効であること。
  • Azure SQL Database論理サーバーにMicrosoft Entra 管理者が設定されていること。

ユーザー作成と権限付与（最小権限アプローチ）​

Entra管理者としてSQL Databaseに接続し、以下のクエリを実行します。db_owner を使用する方法もありますが、以下のロール構成であればより権限を絞ることが可能です。

  1. Masterデータベースでの作業

    サーバーレベルの読み取り権限を付与します。

    -- Masterデータベースに管理者で接続して実行
    -- ※[MyFabricWorkspace] は実際のFabricワークスペース名に置き換えてください
    CREATE LOGIN [MyFabricWorkspace] FROM EXTERNAL PROVIDER;
    ALTER SERVER ROLE [##MS_ServerStateReader##] ADD MEMBER [MyFabricWorkspace];

  2. 対象データベースでの作業

    ミラーリング対象のデータベースに対して権限を付与します。

    -- 対象のユーザーデータベースに接続して実行
    CREATE USER [MyFabricWorkspace] FOR LOGIN [MyFabricWorkspace];

    -- ミラーリング構成とデータ読み取りに必要な権限を付与
    GRANT SELECT, ALTER ANY EXTERNAL MIRROR TO [MyFabricWorkspace];

認証方法の比較​

認証方法推奨度メリット・デメリット
ワークスペース ID推奨パスワード不要。セキュリティライフサイクルが自動化される。
SQL 認証非推奨パスワードの定期的なローテーションや漏洩リスクの管理が必要。
サービスプリンシパル可自動化には適しているが、別途App Registrationとシークレットの管理が必要。

まとめ​

Azure Fabricのミラーリング機能は、運用データベースと分析基盤の間の壁を取り払う強力な機能です。

  • 負荷分離: 分析クエリの負荷を本番DBからFabric上のOneLakeへオフロードできます。
  • 鮮度と速度: DirectQueryのリアルタイム性と、インポートモードの高速なレスポンスを両立します（Direct Lake）。
  • シンプルさ: 複雑なETLパイプライン管理から解放されます。

既存のPower BI環境で更新遅延やソースDBへの負荷問題に直面している場合、Fabricミラーリングへの移行を検討する価値があります。