2026年4月22日の更新で、Azure Database for PostgreSQL と Microsoft Fabric のミラーリングは、運用分析パイプラインでより使いやすい選択肢になりました。結論から言うと、今回のポイントは JSON/JSONB などの PostgreSQL ネイティブ型対応、PostgreSQL 17 未満の高可用性構成への対応拡大、診断しやすいエラーメッセージと UDF、Read Replica を持つプライマリサーバーのブロック解除です。Microsoft は Azure Updates で「Enhanced Mirroring Azure Database for PostgreSQL in Microsoft Fabric」を一般提供として公開し、同日に Microsoft Blog for PostgreSQL でも General Availability Refresh の内容を発表しています。(マイクロソフト Azure)
データエンジニアにとっては、PostgreSQL の業務データを複雑な ETL なしで OneLake に継続レプリケーションしやすくなる更新です。DBA にとっては、HA、Read Replica、WAL、権限、診断の観点で確認すべき項目が増えます。分析リーダーにとっては、Power BI、SQL 分析エンドポイント、AI/データサイエンス用途へ、トランザクションデータをより短いリードタイムでつなげる判断材料になります。
Azure Database for PostgreSQL / Microsoft Fabricの最新動向：Enhanced Mirroringで何が変わったか
Enhanced Mirroring for Azure Database for PostgreSQL in Microsoft Fabric は、Azure Database for PostgreSQL Flexible Server のデータを Microsoft Fabric 側へ継続的に複製し、OneLake、Delta テーブル、SQL 分析エンドポイント、Power BI などで分析しやすくする仕組みです。Microsoft Learn では、Fabric の Mirroring は複雑な ETL を避け、Azure Database for PostgreSQL のデータを Fabric OneLake に継続的にレプリケートするための機能として説明されています。(Microsoft Learn)
従来のデータ連携では、PostgreSQL からデータを抽出し、加工し、データレイクや DWH にロードする処理を別途設計する必要がありました。ミラーリングを使うと、初期スナップショットとその後の変更データを Fabric 側へ継続的に反映できるため、運用データを分析基盤に載せるまでの実装負荷を下げられます。
ただし、これは「何でも同期できる万能レプリケーション」ではありません。基本的には 分析向けの読み取り専用コピーを作る機能として考えるべきです。Fabric 側から PostgreSQL の本番データを更新する用途や、双方向同期、複雑な変換処理を前提にしたデータ統合とは役割が異なります。
2026年4月更新の主なポイント
今回の General Availability Refresh で実務上大きいのは、これまで導入を妨げやすかった制約がいくつか緩和されたことです。特に JSON/JSONB、HA 構成、診断性、Read Replica まわりは、実運用で採用可否に直結します。(TECHCOMMUNITY.MICROSOFT.COM)
| 更新ポイント | これまでの課題 | 実務での意味 |
|---|---|---|
| PostgreSQL ネイティブ型のサポート強化 | JSON/JSONB などの半構造化データで変換や回避策が必要になりやすかった | アプリケーションログ、属性情報、イベントデータを Fabric 側で扱いやすくなる |
varchar(max) / varbinary への透過的なレプリケーション | 独自型や一般的でない型の扱いが分析パイプラインの障害になりやすかった | 型変換のための中間処理を減らせる可能性がある |
| PostgreSQL 17 未満の HA 対応拡大 | HA 構成のために PostgreSQL バージョン要件が導入判断の壁になっていた | 既存の HA 構成を維持したままミラーリングを検討しやすくなる |
| エラーメッセージの改善 | レプリケーション失敗時の原因特定に時間がかかりやすかった | DBA とデータエンジニアが原因を切り分けやすくなる |
| 専用 PostgreSQL UDF の追加 | ポータル画面だけでは事前確認や健全性確認が不十分なケースがあった | SQL で前提条件、拡張機能バージョン、ヘルス状態、テーブル単位の準備状況を確認できる |
| Read Replica を持つプライマリサーバーのブロック解除 | Read Replica を構成した Flexible Server がミラーリング検討から外れやすかった | 読み取りスケールや可用性設計を維持しながら Fabric 連携を検討しやすくなる |
特に JSON/JSONB 対応は、SaaS、EC、IoT、ゲーム、FinTech などで影響が大きい更新です。たとえば、注文テーブルの metadata、ユーザーイベントの properties、デバイスログの payload のような JSONB 列を、事前に文字列化したり別テーブルへ分解したりせず、Fabric の分析ワークロードへ渡しやすくなります。
Enhanced Mirroringの仕組みを簡単に理解する
Fabric Mirroring は、Azure Database for PostgreSQL 側の論理レプリケーションと CDC の考え方をベースにしています。Microsoft Learn によると、ミラーリングを確立すると、初期スナップショットが Parquet 形式で OneLake のランディングゾーンに送られ、Fabric 側の Replicator が Mirrored database の Delta テーブルを作成します。その後の変更もバッチとして送られ、対象の Delta テーブルへ反映されます。(Microsoft Learn)
ざっくり言えば、流れは次のようになります。
| 段階 | 起きること | 確認すべき点 |
|---|---|---|
| 初期設定 | Azure Database for PostgreSQL に必要な ID、WAL、拡張機能、権限を準備する | SAMI、wal_level、azure_cdc、ロール権限 |
| 初期スナップショット | 対象テーブルのデータを OneLake 側へコピーする | ソース DB の CPU、IOPS、WAL、ストレージ |
| 継続レプリケーション | INSERT、UPDATE、DELETE などの変更を Fabric 側へ反映する | レプリケーション状態、遅延、警告、失敗 |
| 分析利用 | SQL 分析エンドポイント、Power BI、Notebook などから利用する | Fabric 側の権限、データ鮮度、ガバナンス |
ここで重要なのは、PostgreSQL の本番処理と Fabric 側の分析処理を分けられることです。本番 DB に直接重い集計クエリを投げるのではなく、OneLake 側に複製されたデータを使って BI や AI ワークロードを回す構成にしやすくなります。
誰にとって重要な更新なのか
データエンジニア：ETLの保守負荷を減らしやすい
データエンジニアにとっての価値は、CDC パイプラインの実装・運用を Fabric のマネージドな仕組みに寄せられる点です。従来は、PostgreSQL からデータを抽出するジョブ、スキーマ変換、データレイクへのロード、差分管理、失敗時の再実行を個別に設計する必要がありました。
Enhanced Mirroring を使うと、PostgreSQL のデータを OneLake 上の分析向け形式へ継続的に届けやすくなります。特に、Power BI ダッシュボード、Fabric Data Engineering、Data Science、AI 用の特徴量作成など、同じデータを複数の分析用途で使う組織では効果が出やすいです。
ただし、変換や品質チェックが不要になるわけではありません。業務定義の統一、PII のマスキング、集計済みマートの作成、データ契約の管理は、Fabric 側の Lakehouse、Warehouse、Dataflow、Notebook などで別途設計する必要があります。
DBA：HA、WAL、権限、診断を事前に見るべき
DBA にとっては、導入前の確認項目が明確になったことが大きなメリットです。Microsoft Learn のチュートリアルでは、SAMI の有効化、wal_level の logical 設定、azure_cdc 拡張機能、ミラー化するデータベースごとの max_worker_processes 増加などが前提条件として示されています。(Microsoft Learn)
また、ミラーリングに使うロールには CREATEDB、CREATEROLE、LOGIN、REPLICATION、azure_cdc_admin などの権限が必要で、対象テーブルの owner であることも求められます。権限不足はポータル上の原因不明エラーにつながりやすいため、DBA が最初に確認すべきポイントです。(Microsoft Learn)
今回追加・強化された UDF は、運用時の切り分けにも役立ちます。
-- CDCミラーリング開始前に、システム要件と構成要件を確認する
SELECT * FROM azure_cdc.check_prerequisites();
-- デプロイ済みのAzure CDC拡張機能バージョンを確認する
SELECT azure_cdc.azure_cdc_version();
-- CDC操作中に検出されたエラーや問題を確認する
SELECT * FROM azure_cdc.get_health_status('', '');
-- ミラーリング対象になり得るテーブルの準備状態を確認する
SELECT * FROM azure_cdc.get_all_tables_mirror_status();これらを本番導入前のチェックリストや障害調査手順に入れておくと、「Fabric 側の問題なのか」「PostgreSQL 側の前提条件なのか」「テーブル定義の問題なのか」を切り分けやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)
分析リーダー：意思決定までのリードタイム短縮が狙える
分析リーダーにとってのポイントは、現場データを BI や AI に載せるまでの時間を短縮できることです。たとえば、注文、在庫、請求、顧客行動、サポート履歴などが PostgreSQL に分散している場合、ミラーリングによって Fabric 側で横断分析しやすくなります。
一方で、ガバナンスの設計は軽視できません。Microsoft Learn では、ソースの Azure Database for PostgreSQL に定義されたアクセス許可は、Fabric OneLake の複製データへ自動的には適用されないと説明されています。つまり、本番 DB 側で細かく制御している権限を、Fabric 側でも再設計する必要があります。(Microsoft Learn)
導入すべきケース、まだ慎重に見るべきケース
Enhanced Mirroring は、次のような環境では優先的に検討する価値があります。
| 判断軸 | 導入に向いているケース | 慎重に見るべきケース |
|---|---|---|
| データソース | Azure Database for PostgreSQL Flexible Server を利用している | オンプレミス PostgreSQL、他クラウド、独自ホスティングが中心 |
| 目的 | 運用データを Power BI、OneLake、AI、データサイエンスに使いたい | 双方向同期や本番 DB 更新を Fabric 側から行いたい |
| データ型 | JSON/JSONB などの半構造化データを分析に使いたい | 非対応型や特殊な構造が多く、事前検証が難しい |
| 可用性 | HA や Read Replica を含む構成で Fabric 連携したい | 頻繁なメジャーバージョンアップ、PITR、構成変更が多い |
| テーブル設計 | 主キーまたは非 NULL の一意インデックスが整っている | 主キーがないテーブルが多く、WAL 増加が懸念される |
| ガバナンス | Fabric 側で権限・監査・共有設計を整備できる | ソース DB の権限がそのまま引き継がれる前提で運用したい |
特に注意したいのは、ミラーリングは「データを Fabric に置けばすぐ安全に共有できる」機能ではないという点です。ソース DB 側の行レベル・列レベルの運用ルール、個人情報の扱い、部門別の参照権限は、Fabric 側の設計として再構成する必要があります。
導入前チェックリスト
サービスと構成の確認
Azure Database for PostgreSQL 側では、Flexible Server、サポート対象バージョン、コンピュート層、ネットワーク構成を確認します。Microsoft Learn の制限事項では、PostgreSQL 14、15、16、17 のサポート、Burstable Compute Tier 非対応、1 データベースを同時に 1 つの Fabric 項目へミラーリングする制限、最大 1,000 テーブルなどが示されています。(Microsoft Learn)
チェック項目は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| PostgreSQL バージョン | 対象バージョンか。HA 構成の場合は今回の更新内容も含めて確認する |
| コンピュート層 | Burstable ではなく、General Purpose または Memory Optimized を使う |
| テーブル数 | ミラーリング対象が 1,000 テーブルを超えないか |
| Fabric 容量 | 容量が有効で稼働中か。一時停止・削除されていないか |
| Fabric テナント設定 | Fabric API と OneLake 外部アクセスに関する設定が有効か |
| ワークスペース権限 | 作成者が Member または Admin ロールを持っているか |
ネットワークと接続
パブリック接続を許可しているサーバーだけでなく、VNET や Private Endpoint を使う環境でもミラーリングは検討できます。ただし、公開接続がなく Azure サービスから接続できない場合は、Virtual Network Data Gateway を用意し、対象ネットワークから Flexible Server に到達できることを確認する必要があります。(Microsoft Learn)
本番環境では、次の観点を事前に確認してください。
| 観点 | 実務上の確認ポイント |
|---|---|
| 到達性 | Fabric から PostgreSQL へ接続できる経路があるか |
| 暗号化 | 接続時の暗号化設定を維持しているか |
| Private Endpoint | VNET Data Gateway から Private Endpoint へ到達できるか |
| ファイアウォール | 必要なネットワークだけを許可しているか |
| 変更管理 | ネットワーク変更時にミラーリング停止が発生しないよう手順化しているか |
権限とセキュリティ
ミラーリング用のロールは、単に SELECT できればよいわけではありません。チュートリアルでは PostgreSQL 認証または Entra ID ロールを使う方法が示されており、レプリケーション管理に必要な権限と、対象テーブルの owner であることが重要です。(Microsoft Learn)
また、ソース DB で定義した権限は Fabric OneLake 側へ自動的に反映されません。これは分析リーダーやセキュリティ担当者が見落としやすい点です。ミラーリング後は、Fabric ワークスペース、SQL 分析エンドポイント、Power BI セマンティックモデル、共有設定の単位でアクセス制御を再設計してください。(Microsoft Learn)
設定の基本手順
本番導入では、いきなり全テーブルをミラーリングするのではなく、影響が読みやすいテーブルから段階的に進めるのが安全です。
| 手順 | 作業 | 失敗しやすいポイント |
|---|---|---|
| 事前棚卸し | 対象テーブル、主キー、データ型、JSON/JSONB、テーブル数を確認する | 主キーなしテーブル、特殊型、テーブル数超過を見落とす |
| PostgreSQL準備 | SAMI、wal_level、azure_cdc、max_worker_processes を設定する | 拡張機能の許可・プリロード後の再起動を忘れる |
| ロール作成 | PostgreSQL ロールまたは Entra ID ロールを用意する | azure_cdc_admin や owner 条件が不足する |
| Fabric作成 | Fabric ポータルで Mirrored Azure Database for PostgreSQL を作成する | Contributor ロールで作業し、必要な再共有権限が足りない |
| 接続設定 | サーバー名、DB名、認証、ゲートウェイを設定する | Private Endpoint 環境でゲートウェイ到達性を確認していない |
| 対象選択 | すべてのデータ、または個別テーブルを選ぶ | 1,000 テーブル制限や不要テーブルを含めてしまう |
| 監視 | レプリケーション状態、行数、最終完了時刻を確認する | 初期コピー中の CPU、IOPS、WAL 増加を見逃す |
| 権限再設計 | Fabric 側の閲覧・共有・Power BI 権限を設定する | ソース DB の権限が引き継がれると誤解する |
Microsoft Learn のチュートリアルでは、ミラーリング開始後に数分待ってから「Monitor replication」で状態を確認し、状態が Running になると同期が進行していることを確認できると説明されています。(Microsoft Learn)
監視とトラブルシューティングで見るべき指標
Fabric ポータルの Monitor replication では、データベースレベルとテーブルレベルの状態、レプリケートされた行数、最終完了時刻を確認できます。状態には Running、Running with warning、Stopping/Stopped、Failed、Paused などがあり、Paused は Fabric 容量の一時停止・再開などと関係する場合があります。(Microsoft Learn)
運用では、次の3層で監視するのが現実的です。
| 監視対象 | 見るもの | 目的 |
|---|---|---|
| PostgreSQL側 | WAL、CPU、IOPS、ストレージ、長時間トランザクション、レプリケーションスロット | ソース DB への影響を抑える |
| Fabric側 | ミラーリング状態、行数、最終完了時刻、警告、失敗 | レプリケーション遅延や停止を検知する |
| ワークスペース監視 | 操作ログ、レプリケーション遅延、失敗イベント、KQL ログ | ダッシュボード化やアラート化を行う |
Microsoft Learn では、Workspace monitoring を有効にすると、ミラー化データベースの実行ログが監視用 KQL データベースの MirroredDatabaseTableExecution テーブルに取り込まれると説明されています。これにより、KQL で詳細ログを照会したり、Power BI や Real-Time Dashboards で監視ダッシュボードを作ったりできます。(Microsoft Learn)
PostgreSQL 側の切り分けでは、従来のビューや関数も役立ちます。たとえば、azure_cdc.tracked_publications、azure_cdc.tracked_batches、pg_stat_activity、pg_replication_slots を確認することで、変更が流れているか、長時間トランザクションが詰まっていないか、レプリケーションスロットが active かを確認できます。(Microsoft Learn)
-- CDCの進行状況を確認
SELECT * FROM azure_cdc.tracked_publications;
-- 変更バッチの生成状況を確認
SELECT * FROM azure_cdc.tracked_batches;
-- 長時間トランザクションの有無を確認
SELECT * FROM pg_stat_activity
WHERE state = 'idle in transaction';
-- レプリケーションスロットの状態を確認
SELECT * FROM pg_replication_slots;運用で失敗しやすいポイント
主キーや一意インデックスがないテーブルを軽く見ない
ミラーリング対象テーブルに主キーまたは適切な一意インデックスがない場合、REPLICA IDENTITY FULL が必要になり、パフォーマンスや WAL 使用量に影響する可能性があります。Microsoft Learn のトラブルシューティングでも、主キーなし・一意インデックスなしの場合は警告として扱われ、追加の WAL 使用や性能問題につながる可能性が示されています。(Microsoft Learn)
本番導入前に、対象テーブルを次のように分類しておくと安全です。
| 分類 | 対応 |
|---|---|
| 主キーあり | 優先的に PoC 対象にする |
| 非 NULL の一意インデックスあり | レプリケーション条件を確認して対象にする |
| 主キーも一意インデックスもなし | WAL 増加と更新頻度を確認し、設計見直しを検討する |
| 更新・削除が多い大規模テーブル | 初期コピーと CDC の負荷を別途見積もる |
DDL変更を通常運用の延長で扱わない
スキーマ変更が多い環境では注意が必要です。Microsoft Learn のトラブルシューティングでは、列名変更、列追加、列削除、主キー変更について一定の挙動が説明されていますが、それ以外の DDL はレプリケーション失敗の原因になり得るとされています。(Microsoft Learn)
たとえば、列を追加した場合、既存行では NULL、新規行では値が入るといった挙動になります。これは分析側で「欠損値」として見えるため、BI レポートや下流のデータマートで意図しない結果を生むことがあります。DDL 変更は、本番 DB の変更作業だけでなく、Fabric 側のデータ利用者にも影響する変更として扱うべきです。
Fabric容量の一時停止・削除を考慮していない
Fabric 容量が一時停止、削除、過負荷になると、ミラーリングにも影響します。Microsoft Learn では、容量が一時停止または削除された場合にミラーリングが停止し、容量再開後も自動で再開されないケースがあるため、ポータルで停止・開始操作が必要になる手順が示されています。(Microsoft Learn)
コスト最適化のために Fabric 容量をスケジュール停止している組織では、ミラーリングも止まる前提で運用設計する必要があります。営業日の朝にダッシュボードが古い、月次処理の前にデータが追いついていない、といった事故を防ぐには、容量再開後のレプリケーション確認を自動監視に組み込むべきです。
公式ドキュメントの更新タイミング差に注意する
今回の 2026年4月更新では、JSON/JSONB 対応や Read Replica を持つプライマリサーバーのブロック解除などが発表されています。一方で、Microsoft Learn の制限事項ページには、時点によって古い制限が残っている場合があります。実際の導入判断では、Azure Updates、Microsoft Blog for PostgreSQL、Microsoft Learn、Azure/Fabric ポータルの表示をあわせて確認してください。(TECHCOMMUNITY.MICROSOFT.COM)
これは「情報が信用できない」という意味ではありません。クラウドサービスでは、リリース発表、ドキュメント更新、リージョン反映、テナント反映に時間差が出ることがあります。本番導入では、対象リージョン・対象テナント・対象サーバーで実際に PoC を行い、サポート状況を確認するのが現実的です。
活用シーンの具体例
SaaSプロダクトの利用ログ分析
SaaS では、ユーザー操作やイベント属性を JSONB に格納しているケースがよくあります。今回の更新により、こうした半構造化データを Fabric 側にレプリケートし、Power BI で利用状況を可視化したり、Notebook で解約予兆モデルの特徴量を作ったりしやすくなります。
具体的には、PostgreSQL の events テーブルをミラーリングし、Fabric 側で「プラン別の機能利用回数」「直近7日間のログイン回数」「エラーイベントの増加」を集計する、といった使い方です。
業務DBを壊さずに経営ダッシュボードを作る
注文、請求、在庫、サポートなどの業務データを PostgreSQL で管理している場合、本番 DB に直接重い集計をかけると性能リスクがあります。ミラーリングで OneLake 側に読み取り専用コピーを作れば、Power BI や SQL 分析エンドポイントで集計しやすくなります。
この場合のポイントは、ミラーリングを「DWH の完成形」と見なさないことです。部門別の KPI、会計上の締め処理、売上認識のロジックなどは、Fabric 側でビューやマートとして整える必要があります。
AI・データサイエンス向けのデータ基盤
顧客属性、利用履歴、課金履歴、問い合わせ履歴を Fabric 側で統合できると、AI やデータサイエンスの前処理が進めやすくなります。Enhanced Mirroring は、PostgreSQL の運用データを OneLake に継続的に届ける入口として使えます。
ただし、AI 用途では個人情報や機密情報の取り扱いが重要です。ミラーリング後に不要な列を見せない、分析用にマスキング済みデータセットを作る、ワークスペース単位でアクセス制御する、といった設計を必ず含めてください。
まず実施すべきアクション
Enhanced Mirroring for Azure Database for PostgreSQL in Microsoft Fabric の 2026年4月更新は、単なる機能追加ではなく、実運用での採用障壁を下げる更新です。特に JSON/JSONB、HA、Read Replica、診断性の改善は、これまで PoC で止まっていた組織にとって再評価する価値があります。
次に取るべき行動は明確です。
| 優先度 | アクション | 目的 |
|---|---|---|
| 高 | ミラーリング候補の PostgreSQL データベースを1つ選ぶ | 影響範囲を限定して検証する |
| 高 | 対象テーブルの主キー、データ型、JSON/JSONB、テーブル数を棚卸しする | 技術的なブロッカーを早期に見つける |
| 高 | Fabric 容量、ワークスペース権限、テナント設定を確認する | ポータル作成時の失敗を防ぐ |
| 中 | azure_cdc UDF を使った事前診断手順を作る | DBA とデータエンジニアの切り分けを標準化する |
| 中 | Fabric 側の権限設計と監視ダッシュボードを用意する | 本番運用でのセキュリティ事故と停止見逃しを防ぐ |
| 中 | 10〜20 テーブル程度で PoC を行う | 初期コピー、CDC、WAL、遅延、BI 利用を確認する |
最初から全データベース・全テーブルを対象にする必要はありません。まずは、ビジネス価値が高く、主キーがあり、JSON/JSONB を含む代表的なテーブルを選び、Fabric 側でどれだけ早く分析に使えるかを検証してください。その結果をもとに、DBA、データエンジニア、分析責任者で本番化の範囲、監視、権限、コストを決めるのが最も安全な進め方です。
コメント