SQL MI の Change Event Streaming｜CDC との違いと有効化手順

はじめに

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

これまで Azure 環境での代表的なデータ連携は、Azure Data Factory（ADF）を用いたバッチ処理（ETL）が一般的でした。ファイル配置を起点とした自動取り込みの構成は、関連記事『ADF ストレージイベントトリガーで CSV を自動取り込みする手順』で解説しています。

今回、Azure SQL Managed Instance（SQL MI）向けに 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 へほぼリアルタイムに配信する機能です。

参考: What is change event streaming（Microsoft Learn）
“CES captures and publishes incremental changes of data to an Azure Event Hubs destination in near real-time.”
（CES はデータの増分変更をキャプチャし、Azure Event Hubs の宛先へニアリアルタイムで発行します。）
https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/change-event-streaming/overview?view=sql-server-ver17

なお、CES が直接ストリーミングする宛先は Azure Event Hubs です。Microsoft Fabric の Eventstreams などは、Event Hubs を経由して下流で変更を受け取る構成になります。

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

オンプレミスの SQL Server から SQL MI へ移行された基幹業務アプリケーションの多くは、もともとイベントを発行する設計になっていません。こうしたシステムをイベント駆動型へモダナイズしようとすると、通常はアプリケーションコードの改修が必要になります。CES を利用すれば、アプリケーションに手を加えることなく、データ層から直接、変更イベントをプッシュ配信できます。

参考: Stream data in near real time from SQL MI to Azure Event Hubs – Public preview（Microsoft Community Hub）
“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

これにより、既存アプリケーションの安定性を保ったまま、マイクロサービスへの段階的な機能移行や、他プラットフォームとのリアルタイム連携を進めやすくなります。

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

CES はトランザクションログベースのキャプチャを使用するため、SQL MI のプライマリワークロードへの影響を抑えやすい設計です（ただしログ肥大化には注意が必要です。詳細は後述の制約セクションで解説します）。

発行されるイベントは、業界標準の CloudEvents 仕様に準拠した構造化フォーマットで出力されます。操作の種類（Insert など）、主キー、変更前後の値（before / after）がペイロードに含まれ、形式は JSON（ネイティブ）または Avro Binary を選択できます。標準化された形式のため、下流のコンシューマー（Azure Functions やサードパーティ製アプリケーション）は、複雑なパース処理を実装せずに変更を解釈できます。

従来の CDC や ADF との違い・適材適所の判断基準

データ変更をキャプチャする手法として、従来の CDC や ADF と比較し、CES が適するシナリオを整理します。

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

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

参考: Stream data in near real time from SQL MI to Azure Event Hubs – Public preview（Microsoft Community Hub）
“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（プッシュ方式）が適しています。なお、CES と CDC は同一データベースで併用できない点に注意が必要です（詳細は後述の制約セクションで解説します）。

ADF などの ETL ツールとの比較

ADF は、大規模なデータウェアハウス構築や、複雑なデータ変換を伴うバッチ処理に適しています。一方で、パイプラインの実行間隔やコンピュートの起動によるオーバーヘッドがあるため、リアルタイム連携には向きません。

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

CES・CDC・ADF の比較

「アクションの起点」として変更を即座に使いたい場合は CES、差分の履歴取得は CDC、大規模な変換・集計を伴うバッチは ADF、という使い分けが基本になります。CES と CDC は同一 DB で併用できないため、移行・設計時にはどちらを採用するかの判断が必要です。

CES の有効化手順（T-SQL）

ここでは、SQL MI から Azure Event Hubs へ AMQP プロトコル＋ SAS トークン認証で配信する場合の基本的な流れを紹介します。Microsoft Entra 認証は現時点で Azure SQL Database のみの対応のため、SQL MI では共有アクセスポリシー（SAS）を用います。

参考: Configure change event streaming（Microsoft Learn）
“Enable change event streaming for a user database. Create an event stream group. With this group, configure the destination, credentials, message size limits, and partitioning schema.”
（ユーザーデータベースで CES を有効化し、ストリームグループを作成します。このグループで宛先・資格情報・メッセージサイズ上限・パーティション方式を構成します。）
https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/change-event-streaming/configure?view=sql-server-ver17

事前準備

• 対象 SQL MI の更新ポリシーが「Always up to date」または「SQL Server 2025」であること。
• 対象データベースが FULL 復旧モデルであること。
• Azure Event Hubs の名前空間・インスタンスを用意し、Send 権限を持つ共有アクセスポリシーから SAS トークンを生成しておくこと（SAS トークンは公式手順の PowerShell スクリプト等で生成できます）
• 操作アカウントが対象 DB の db_owner ロール、または CONTROL DATABASE 権限を持つこと。

設定の流れ

対象のユーザーデータベースにコンテキストを切り替え、次の順で実行します。< > の値は環境に合わせて置き換えてください。

USE <データベース名>;

-- 1. マスターキーを作成
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<複雑なパスワード>';

-- 2. SAS トークンを格納するデータベーススコープ資格情報を作成
CREATE DATABASE SCOPED CREDENTIAL <資格情報名>
    WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
    SECRET = '<生成した SAS トークン>'; -- "SharedAccessSignature sr=" から始まる文字列全体

-- 3. CES を有効化
EXEC sys.sp_enable_event_stream;

-- 4. ストリームグループ（宛先・認証・サイズ・パーティション）を作成
EXEC sys.sp_create_event_stream_group
    @stream_group_name      = N'<ストリームグループ名>',
    @destination_type       = N'AzureEventHubsAmqp',
    @destination_location   = N'<Event Hubs ホスト名>/<Event Hubs インスタンス名>',
    @destination_credential = <資格情報名>,
    @max_message_size_kb    = 256,
    @partition_key_scheme   = N'None';

-- 5. 対象テーブルをストリームグループに追加
EXEC sys.sp_add_object_to_event_stream_group
    N'<ストリームグループ名>',
    N'<スキーマ名>.<テーブル名>';

@partition_key_scheme の既定は None（ラウンドロビン）で、ほかに StreamGroup / Table / Column を選べます。@max_message_size_kb は宛先 Event Hubs の上限に合わせて調整します（既定 256 KB、最大 1 MB）。Kafka プロトコルを使う場合は @destination_type を N'AzureEventHubsApacheKafka' とし、ホスト名にポート（例: :9093）を含めます。

設定状況の確認

有効化の状態は、システムカタログビューで確認できます。

-- CES が有効なデータベースを確認
SELECT name, is_event_stream_enabled
FROM sys.databases
WHERE is_event_stream_enabled = 1;

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（Microsoft Community Hub）
“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 へ一度ストリーミングし、ルーティングや配信の負荷をメッセージバス側へオフロードする構成です。これにより、パブリッシャー（SQL MI）とサブスクライバー（下流システム）の疎結合化につながります。

Azure Functions によるマイクロサービスやキャッシュ・検索インデックスの更新

Event Hubs に流れてきたイベントをトリガーとして、Azure Functions などのサーバーレスコンピューティングを起動できます。これにより、特定テーブルの INSERT や UPDATE を検知して Azure Cache for Redis を更新したり、Azure AI Search のインデックスを再構築したりするロジックを、元のアプリケーションコードに依存せずに実装できます。

CES の制約事項・非対応機能

CES の採用可否を判断するうえで重要な制約を整理します。「できないこと」を事前に把握することで、設計段階での手戻りを防げます。

併用・前提に関する制約

CDC・レプリケーション等と同一 DB で併用不可

CDC が有効なデータベース、トランザクションレプリケーション、Fabric Mirrored Databases、Azure Synapse Link が構成されたデータベースでは CES を有効化できません。一方、変更追跡（Change Tracking）は併用できます。

FULL 復旧モデルが前提

CES はトランザクションログを読み取るため、対象 DB は完全（FULL）復旧モデルである必要があります。

書き込み可能なプライマリ DB のみ

可用性グループのセカンダリや Managed Instance リンクのセカンダリは、ストリーミングのソースにできません。

ビュー・インデックス付きビューは対象外

参考: Configure change event streaming – Limitations（Microsoft Learn）
“CES only supports databases configured with the full recovery model.”
（CES は完全復旧モデルで構成されたデータベースのみをサポートします。）
https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/change-event-streaming/configure?view=sql-server-ver17

データ・スキーマに関する制約

既存データのスナップショットなし

CES は有効化前のデータを送信しません。送信対象は有効化後の変更のみです。

DDL イベントは発行されない

スキーマ変更（DDL）のイベントは発行されません。CES 構成済みのテーブル・列のリネームは失敗します（データベース名の変更は可能）

対象は DML のみ

INSERT / UPDATE / DELETE が対象です。

操作上の制限

CES 有効中のテーブルでは、主キー制約の追加・削除、TRUNCATE TABLE、ALTER TABLE SWITCH PARTITION がサポートされません。

非対応の列の型

geography、geometry、image、json、rowversion / timestamp、sql_variant、text / ntext、vector、xml、ユーザー定義型（UDT）はスキップされます。

非対応のテーブル機能

クラスター化列ストアインデックス、テンポラル/レジャー履歴テーブル、Always Encrypted、インメモリ OLTP、グラフテーブル、外部テーブルは対象外です。

セキュリティ・ネットワークに関する制約

データはマスクされない

行レベルセキュリティが設定されていても CES は全行の変更を発行し、動的データマスクは適用されません。機密データの取り扱いには注意が必要です。

パブリックエンドポイントのみ

現時点で CES は Azure Event Hubs のパブリックエンドポイントにのみ配信でき、サービスエンドポイントやプライベートエンドポイントは未対応です。

クロスリージョン配信

宛先が別リージョンの場合、データはリージョンをまたいで配信されます。データ所在地・コンプライアンス要件との整合を確認してください。

配信とトランザクションログに関する注意

• 配信保証は at-least-once: 同じイベントが複数回届く可能性があるため、下流コンシューマー側で冪等性を確保する設計が望まれます。
• トランザクションログの肥大化: 配信が保証される性質上、ストリーミング待ちの変更がログに残っている間はログの切り捨てが行われず、ログが増大し得ます。

参考: Configure change event streaming – Transaction log growth（Microsoft Learn）
“Log truncation is prevented as long as there are CES changes to stream from the log.”
（ログからストリーミングすべき CES の変更が残っている間は、ログの切り捨てが行われません。）
https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/change-event-streaming/configure?view=sql-server-ver17

ログが上限に達すると DB への書き込みが失敗するため、SQL MI / SQL Database では、上限に近づくと Microsoft 側が CES を無効化したり、長時間トランザクションを停止したりする場合があります。ログサイズと配信エラーの継続的な監視が重要です。

パブリックプレビュー利用時の注意点と監視

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

CES はすべての SQL MI 環境で既定で有効になるわけではなく、基盤となる SQL Server エンジンのバージョンに依存します。

参考: Configure change event streaming（Microsoft Learn）
“When using change event streaming with Azure SQL Managed Instance, the instance must be configured with the SQL Server 2025 or Always-up-to-date update policy.”
（SQL MI で CES を使う場合、インスタンスは SQL Server 2025 または Always-up-to-date の更新ポリシーで構成されている必要があります。）
https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/change-event-streaming/configure?view=sql-server-ver17

プレビュー機能を利用するには、Azure Portal または ARM テンプレートから、対象 SQL MI の更新ポリシーを「Always up to date」または「SQL Server 2025」に設定します。SQL Server 2022 の更新ポリシーに固定された環境では CES を利用できないため、注意が必要です。

Azure Monitor と SQL 側 DMV による監視

検証・運用フェーズでは、継続的なパフォーマンス監視が重要です。Azure Monitor では、宛先 Event Hubs の「受信メッセージ数（Incoming Messages）」や「スロットルされた要求」のメトリックと、SQL MI 側のトランザクションログ I/O を統合的に可視化し、配信遅延を検知するアラートを設定する運用設計が推奨されます。

あわせて、SQL 側の DMV・システムストアドプロシージャを併用すると、より的確に状態を把握できます。

• sys.dm_change_feed_errors: 配信エラーを返します
• sys.dm_change_feed_log_scan_sessions: ログスキャンの活動状況を返します
• sys.sp_help_change_feed_settings: 構成済み CES の状態・情報を提供します

特に、前述のトランザクションログ肥大化を避けるため、配信エラーとログサイズを定期的に確認する運用が推奨されます。

-- 配信エラーの確認
SELECT * FROM sys.dm_change_feed_errors;

-- CES 構成状況の確認
EXEC sys.sp_help_change_feed_settings;

まとめ

本記事では、SQL MI 向けにパブリックプレビューが開始された CES（Change Event Streaming）の概要、CDC・ADF との違い、有効化手順、利用時の制約を解説しました。

• アプリを改修せず DB 層から Event Hubs へ変更をプッシュ配信できる。
• CloudEvents 準拠の JSON / Avro で操作種別・主キー・変更前後の値を含む。
• プッシュ方式で低遅延だが同一 DB で CDC とは併用できない。
• 更新ポリシーと FULL 復旧を前提に T-SQL でストリームグループを構成する。
• 既存データの初期取得なし、非マスク配信、パブリックエンドポイントのみに注意
• at-least-once 配信のため冪等性を確保し、ログ肥大化と配信エラーを監視する。
• 即時連携は CES、履歴差分は CDC、大規模変換は ADF が適している。

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