【Azure】SQL Managed Instance 向け CES（変更イベントストリーミング）の概要と CDC との比較

はじめに

既存のビジネスアプリケーションを Azure へ移行する際、「アプリケーション自体を改修せずに、データベースの変更を他のシステムへリアルタイムに連携したい」という課題に直面するケースは少なくありません。

これまで、Azure 環境における代表的なデータ連携アプローチとしては、以下の関連記事で紹介しているような Azure Data Factory（ADF）を用いたバッチ処理（ETL）が一般的でした。

しかし今回、Azure SQL Managed Instance 向けに Change Event Streaming（CES）がパブリックプレビューとして提供されたことで、より低遅延かつシンプルな「イベント駆動型」のデータ連携が可能になりました。

本記事では、この CES の機能概要と SQL MI 環境へ導入するメリットを解説し、従来の CDC（変更データキャプチャ）や ADF との違い、および具体的なアーキテクチャ構成について客観的な視点で考察します。

CES（Change Event Streaming）の概要と SQL MI への導入メリット

Change Event Streaming（CES）は、データベース内で確定（コミット）された行レベルの変更データ（INSERT、UPDATE、DELETE）をキャプチャし、Azure Event Hubs や Fabric Eventstreams に対してほぼリアルタイムに配信する機能です。

既存のモノリスアプリケーションを書き換えずにリアルタイム連携を実現

オンプレミスの SQL Server から Azure SQL Managed Instance（SQL MI）へ移行されたシステム（基幹業務アプリケーションなど）の多くは、元々イベントを発行するような設計になっていません。

このような既存システムをイベント駆動型アーキテクチャへモダナイズしようとすると、通常はアプリケーションコードの大幅な改修が必要になります。しかし CES を利用すれば、アプリケーションに手を加えることなく、データベース層（データ層）から直接変更イベントをプッシュ配信することが可能になります。

参考: Stream data in near real time from SQL MI to Azure Event Hubs – Public preview
“With CES, you do not need to retrofit an older application to emit events itself. You can publish changes at the data layer and let downstream services react from there.” （CES を使用すると、イベントを発行するために古いアプリケーションを改修する必要はありません。データ層で変更を公開し、そこから下流のサービスを反応させることができます。）
https://techcommunity.microsoft.com/blog/azuresqlblog/stream-data-in-near-real-time-from-sql-mi-to-azure-event-hubs—public-preview/4504212

これにより、既存のアプリケーションの安定性を保ったまま、新しいマイクロサービスへの段階的な機能移行（モノリスの解体）や、他プラットフォームとのリアルタイム連携を安全に進めることができます。

JSON（CloudEvents 標準）フォーマットによるイベントの発行

CES はトランザクションログベースのキャプチャを使用するため、SQL MI のパフォーマンスに与える影響は最小限に抑えられます。

発行されるイベントは、業界標準である CloudEvents 仕様に準拠した構造化 JSON フォーマットで出力され、操作の種類（Insert など）や主キー、変更前後の値（before/after）がペイロードに含まれます。 この標準化されたフォーマットにより、下流のコンシューマー（Azure Functions やサードパーティ製アプリケーション）は、複雑なパース処理を実装することなく、容易にデータ変更を解釈してアクションを実行できます。

従来の CDC（変更データキャプチャ）や ADF との違い・適材適所の判断基準

Azure 環境においてデータ変更をキャプチャする手法として、従来の CDC（Change Data Capture）や ADF（Azure Data Factory）を利用するケースと比較し、CES が適しているシナリオを整理します。

SQL Server ネイティブの CDC との違い（ポーリングとプッシュ方式）

従来の SQL Server に実装されている CDC は、変更履歴をシステムテーブルに記録し、アプリケーションが定期的にクエリを実行して変更を取得する「ポーリング（Polling）方式」です。これに対し、CES はトランザクションログから直接変更を読み取り、外部のメッセージバスへ「プッシュ（Push）方式」で配信します。

参考: Stream data in near real time from SQL MI to Azure Event Hubs – Public preview
“Instead of relying on periodic polling, custom ETL jobs, or additional connectors, CES lets SQL push changes out as they happen.” （定期的なポーリング、カスタム ETL ジョブ、または追加のコネクタに依存する代わりに、CES を使用すると、SQL は変更が発生したときにそれをプッシュできます。）
https://techcommunity.microsoft.com/blog/azuresqlblog/stream-data-in-near-real-time-from-sql-mi-to-azure-event-hubs—public-preview/4504212

データベースへのクエリ負荷を減らし、ミリ秒から秒単位のリアルタイム性（低遅延）が求められるイベント駆動型のユースケースでは、ポーリング間隔の制約を受けない CES（プッシュ方式）の採用が推奨されます。

Azure Data Factory などの ETL ツールを利用する場合との比較

前回の記事で紹介した ADF は、大規模なデータウェアハウス構築や、複雑なデータ変換（Transform）を伴うバッチ処理に優れています。しかし、パイプラインの実行間隔やコンピュートの起動によるオーバーヘッドがあるため、リアルタイム連携には不向きです。

大量データの定期的な移動や集計（分析用途）であれば ADF や Fabric へのバッチ連携が適していますが、他のマイクロサービスのトリガーやキャッシュの即時更新など「アクションの起点」としてデータを使う場合は CES を利用するという、適材適所の使い分けがインフラ設計において重要になります。

Azure Event Hubs や Functions を連携させた実践的アーキテクチャ

CES のポテンシャルを最大限に引き出すためには、Azure 上の他サービスと組み合わせたイベント駆動型アーキテクチャ（EDA）の設計が必要です。

Event Hubs をハブとした下流システムへのファンアウト（分散配信）構成

SQL MI から出力された CES のイベントは、Azure Event Hubs に送られます。Event Hubs は、1 つのデータソースからのイベントを複数のシステムへ同時に分配する「ファンアウト（Fan-out）」の中核として機能します。

参考: Stream data in near real time from SQL MI to Azure Event Hubs – Public preview
“Once changes are published to Azure Event Hubs or Fabric Eventstreams, multiple downstream systems can consume them independently.” （変更が Azure Event Hubs または Fabric Eventstreams に公開されると、複数の下流システムがそれらを個別に消費できます。）
https://techcommunity.microsoft.com/blog/azuresqlblog/stream-data-in-near-real-time-from-sql-mi-to-azure-event-hubs—public-preview/4504212

既存のアプリケーションに複数の連携先をハードコーディングするのではなく、データベースから Event Hubs へ一度だけストリーミングし、ルーティングや配信の負荷をメッセージバス側（Event Hubs）に完全にオフロードするアーキテクチャを構築します。これにより、パブリッシャー（SQL MI）とサブスクライバー（下流システム）の疎結合化が実現します。

Azure Functions を用いたマイクロサービスやキャッシュ・検索インデックスの更新

Event Hubs に流れてきた JSON 形式のイベントをトリガーとして、Azure Functions などのサーバーレスコンピューティングを起動できます。

これにより、特定テーブルの INSERT や UPDATE を検知して、Azure Cache for Redis の内容を即座に更新したり、Azure AI Search のインデックスを再構築したりするロジックを、元のアプリケーションコードに一切依存することなく実装可能になります。

パブリックプレビューの設定における注意点と Azure Monitor を活用した監視

現在パブリックプレビューとして提供されている CES を SQL MI 環境に導入するにあたり、インフラエンジニアが事前に把握しておくべき重要な設定要件と運用上のポイントが存在します。

SQL MI の更新ポリシー（Always up to date または SQL Server 2025）の必須設定

CES は、すべての SQL MI 環境でデフォルトで有効になるわけではありません。プラットフォームの基盤となる SQL Server エンジンのバージョンに依存しています。

参考: Stream data in near real time from SQL MI to Azure Event Hubs – Public preview “Just make sure that your SQL MI update policy is set to “Always up to date” or “SQL Server 2025″.” （SQL MI の更新ポリシーが「Always up to date」または「SQL Server 2025」に設定されていることを確認してください。）
https://techcommunity.microsoft.com/blog/azuresqlblog/stream-data-in-near-real-time-from-sql-mi-to-azure-event-hubs—public-preview/4504212

プレビュー機能を利用するためには、Azure Portal または ARM テンプレートから、対象となる SQL MI（Azure SQL Managed Instance）の更新ポリシー（Update policy）を「Always up to date（常に最新）」または「SQL Server 2025」へ明示的に変更する必要があります。レガシーなバージョンに固定されているポリシー環境では、CES の機能自体が利用できないため注意が必要です。

Azure Monitor によるイベント発行の検証とパフォーマンスの監視

CES はトランザクションログベースのキャプチャを利用するため、SQL MI のプライマリワークロードへの影響は最小限に設計されていますが、本番環境への導入に向けた検証フェーズでは継続的なパフォーマンス監視が不可欠です。

運用環境においては、Azure Monitor を用いて宛先である Azure Event Hubs の「受信メッセージ数（Incoming Messages）」や「スロットルされた要求」のメトリックと、SQL MI 側のトランザクションログの I/O 消費量を統合的にダッシュボードで可視化し、イベント配信の遅延を検知するアラートを設定する運用設計が推奨されます。

まとめ

本記事では、Azure SQL Managed Instance 向けにパブリックプレビューが開始された CES（Change Event Streaming）の概要と実践的なアーキテクチャについて解説しました。

• CES は既存のアプリケーションを改修することなく、DB 層からリアルタイムにイベントをプッシュ配信する。
• バッチ処理が得意な ADF や定期ポーリング方式の従来の CDC とは異なり、低遅延な連携に適している。
• Event Hubs と連携させることで、複数のマイクロサービスや検索インデックス等へのファンアウトを実現する。
• プレビュー利用時は、SQL MI の更新ポリシーを「Always up to date」等に設定し、Monitor で監視を行う。

以上、最後までお読みいただきありがとうございました。