Change event streamingて何だ？
SQL Server のデータ変更を「イベント」として流す入門
はじめに
SQL Server を使っていると、こんな要望が出てくることがあります。
- 注文が入ったら、すぐに在庫システムへ伝えたい
- 顧客情報が更新されたら、別システムにも反映したい
- 売上データの変更をリアルタイムに分析したい
- 重要テーブルの変更を監査ログとして残したい
- SQL Server の変更を Microsoft Fabric に流したい
従来は、定期的に SELECT して差分を探したり、トリガーを書いたり、CDC を使ったりしていました。
でも、これからは少し考え方が変わります。
データベースの変更を、イベントとして外に流す
この考え方を SQL Server / Azure SQL で実現する機能が Change event streaming です。
この記事のゴール
この記事では、初心者向けに次のことを説明します。
- Change event streaming とは何か
- 従来のポーリングや CDC と何が違うのか
- Event Hubs や Microsoft Fabric とどうつながるのか
- どんな用途に向いているのか
- 使うときに何に注意すべきか
Change event streaming とは
Change event streaming、略して CES は、SQL Server や Azure SQL のデータ変更を Azure Event Hubs にストリーミングする機能です。
Microsoft Learn では、SQL Server 2025、Azure SQL Database、Azure SQL Managed Instance 向けのプレビュー機能として説明されています。CES は、データの増分変更をほぼリアルタイムでキャプチャし、Azure Event Hubs に発行します。対象となる変更には INSERT、UPDATE、DELETE が含まれます。
まずは、全体像を図で見ると分かりやすいです。
一言でいうと、Change event streaming は次のような機能です。
SQL Server のテーブル変更を、外部システムが受け取れるイベントに変換して流す仕組み
何がうれしいのか
従来のシステムでは、データベースの変更を知るために、外部アプリが定期的に SQL Server を見に行くことがよくありました。
この方式は分かりやすいのですが、いくつか問題があります。
- 変更がなくても定期的に SQL Server を読みに行く
- 反映までに遅れが出る
- 差分判定の処理を自分で作る必要がある
- 複数システムが同じテーブルを見に行くと負荷が増える
- 本番データベースに参照が集中しやすい
Change event streaming では、考え方が逆になります。
外部アプリが何度も聞きに行くのではなく、SQL Server 側の変更をイベントとして流します。
ポーリング型とイベント型の違い
ポーリング型のイメージはこうです。
一方、イベント型のイメージはこうです。
ポイントは、SQL Server と後続システムの間に Event Hubs が入ることです。
Event Hubs が間に入ることで、SQL Server と各システムを直接つなげなくて済みます。Event Hubs はリアルタイムデータストリーミングのサービスで、Azure Functions、Azure Stream Analytics、Azure Data Explorer などと連携できます。
何がイベントとして流れるのか
Change event streaming では、変更内容が CloudEvent として Azure Event Hubs に送られます。
Microsoft Learn では、変更内容にはスキーマ、変更前の値、変更後の値などが含まれ、CloudEvent として Azure Event Hubs に送信されると説明されています。また、シリアライズ形式として JSON または Avro Binary を利用できます。
イメージとしては、次のような情報がイベントになります。
例えば、注文テーブルに1行追加されたとします。
INSERT INTO dbo.Orders
(
OrderId,
CustomerId,
Amount,
OrderDate
)
VALUES
(
1001,
200,
9800,
SYSDATETIME()
);
この変更が、Azure Event Hubs にイベントとして流れます。
受け取った側では、次のような処理ができます。
CDC や Change Tracking とは何が違うのか
SQL Server には、以前からデータ変更を追跡する機能があります。
代表的なのが次の2つです。
- Change Data Capture、CDC
- Change Tracking
Microsoft Learn でも、SQL Server のデータ変更追跡機能として CDC と Change Tracking が説明されています。
初心者向けに、かなりざっくり比較すると次のようになります。
| 方式 | ざっくり説明 | 向いている用途 |
|---|---|---|
| トリガー | テーブル変更時に自分で処理を書く | 小規模な個別処理 |
| Change Tracking | どの行が変わったかを軽量に追跡する | データ同期 |
| CDC | 変更内容を記録し、後から取得できるようにする | ETL、監査、差分連携 |
| Change event streaming | 変更内容を Event Hubs に流す | リアルタイム連携、イベント駆動、Fabric 連携 |
図にすると、違いはこうです。
Change event streaming の特徴は、単に変更を記録するだけではなく、変更をイベントとして外へ流す ところにあります。
Event Hubs が入る意味
Change event streaming の送信先は Azure Event Hubs です。
ここが重要です。
もし SQL Server が各システムに直接通知しようとすると、構成が複雑になります。
この形だと、SQL Server 側がいろいろな相手を意識する必要があります。
Event Hubs を間に入れると、こうなります。
SQL Server は Event Hubs に流すだけです。
後続システムは Event Hubs からイベントを受け取ります。
これにより、次のようなメリットがあります。
- SQL Server と後続システムを疎結合にできる
- 複数のシステムが同じ変更イベントを利用できる
- 後続処理を増やしやすい
- SQL Server 側に個別連携処理を詰め込まなくてよい
Microsoft Fabric とつなぐとどうなるか
Change event streaming は Microsoft Fabric とも組み合わせやすい機能です。
Fabric Eventstream は、リアルタイムイベントを取り込み、変換し、Fabric 内のさまざまな宛先にルーティングする機能です。Microsoft Learn では、Eventstream を使ってリアルタイムイベントを取り込み、変換し、Fabric 内の宛先にルーティングできると説明されています。
構成イメージはこうです。
例えば、注文テーブルの変更を Fabric に流すと、次のような使い方ができます。
Microsoft Learn には、Azure SQL Database の変更イベントを Change Event Streaming で Fabric Eventstream のカスタムエンドポイントに流し、Eventstream の SQL operator でテーブルデータを取り出すチュートリアルも用意されています。
設定の大まかな流れ
Change event streaming の設定は、細かく見ると資格情報や接続先などがありますが、全体の流れは次の4ステップです。
Microsoft Learn では、Change event streaming の構成手順として、Event Hubs の用意、ユーザーデータベースでの有効化、event stream group の作成、テーブルの追加が説明されています。
Event stream group とは
Event stream group は、どのテーブルの変更を、どこへ、どのような設定で流すかをまとめる単位です。
ざっくり言うと、
Change event streaming の送信設定をまとめた箱
と考えると分かりやすいです。
超ざっくりした設定イメージ
実際の設定は公式ドキュメントに従う必要がありますが、考え方だけ見ると次のようになります。
-- データベースで Change event streaming を有効化するイメージ
EXEC sys.sp_enable_event_stream;
次に、送信先をまとめる Event stream group を作ります。
-- Event stream group を作成するイメージ
EXEC sys.sp_create_event_stream_group
@stream_group_name = N'order_stream_group',
@destination_type = N'eventhubs';
最後に、変更を流したいテーブルを追加します。
-- 対象テーブルを Event stream group に追加するイメージ
EXEC sys.sp_add_object_to_event_stream_group
@stream_group_name = N'order_stream_group',
@object_name = N'dbo.Orders';
実際には、接続先、認証、資格情報、送信形式、パーティション設定などを指定します。Microsoft Learn では、Microsoft Entra 認証、SAS token、SAS key などの認証方式が説明されています。
どんな用途に向いているか
Change event streaming は、次のような用途に向いています。
1. リアルタイム分析
業務テーブルの変更を Event Hubs や Fabric に流して、リアルタイム分析に使えます。
2. 監査ログ
重要なテーブルの変更を外部に流し、監査用の保存先に記録できます。
3. マイクロサービス連携
1つのサービスで起きたデータ変更を、他のサービスに伝える用途に使えます。
4. Microsoft Fabric 連携
SQL Server の業務データを Fabric のリアルタイム分析基盤に流せます。
注意点
便利な機能ですが、いくつか注意点があります。
1. 現時点ではプレビュー機能
Change event streaming は、SQL Server 2025、Azure SQL Database、Azure SQL Managed Instance 向けのプレビュー機能として説明されています。プレビュー中は仕様や制約が変わる可能性があります。
本番利用を考える場合は、必ず最新の公式ドキュメントを確認した方がよいです。
2. SQL Server では Full recovery model が必要
CES はトランザクションログを読むため、SQL Server データベースでは Full recovery model が必要です。Azure SQL Database と Azure SQL Managed Instance では、すでに FULL であるためこの設定は不要と説明されています。
3. 送信できないとログが伸びる
Change event streaming は at-least-once の配信を前提にしています。
Event Hubs 側の問題、認証情報の期限切れ、ネットワーク設定ミスなどで送信できない状態が続くと、トランザクションログが切り詰められず、ログが伸びる可能性があります。
これはかなり重要です。
Change event streaming は、設定して終わりではありません。
監視が必要です。
4. 1行ごとにイベントが出る
複数行を一括更新した場合でも、影響を受けた各行が個別のイベントとして送信されます。
例えば、次のような更新を実行した場合です。
UPDATE dbo.Orders
SET Status = 'Closed'
WHERE OrderDate < '2026-01-01';
1000行が更新されれば、1000件分のイベントが流れるイメージです。
大量更新を行うシステムでは、イベント量の見積もりが必要です。
5. 有効化前の既存データは流れない
CES を有効化する前から存在していたデータは、自動的にスナップショットとして送信されません。CES が流すのは、有効化後に発生した変更です。
初期データを後続システムに入れたい場合は、別途バッチやコピー処理が必要です。
6. DDL はイベントにならない
CES の対象は INSERT、UPDATE、DELETE の DML です。テーブル定義変更などの DDL 自体はイベントとして送信されません。
ただし、テーブル定義を変えた後の DML イベントにはスキーマ変更の影響が出ます。
つまり、受信側ではスキーマ変更に耐えられる設計が必要です。
7. CDC との併用には注意
Change event streaming の制約では、Change Data Capture が構成されたデータベースでは CES はサポートされないと説明されています。一方で、Change Tracking は CES と併用可能と説明されています。
既存システムで CDC を使っている場合は、CES を追加する前に構成を確認する必要があります。
設計で考えること
Change event streaming は便利ですが、これだけでシステム全体が完成するわけではありません。
特に、次の点は設計が必要です。
重複処理
at-least-once 配信では、同じイベントが複数回届く可能性があります。
そのため、受信側は同じイベントを2回処理しても壊れないようにしておく必要があります。
これを 冪等性 と呼びます。
順序
イベントの順序が重要な場合は、パーティション設計を考える必要があります。
例えば、注文IDごとに順序を守りたいのか、テーブル全体で順序を守りたいのかで設計が変わります。
スキーマ変更
テーブルに列を追加したり、型を変えたりすると、後続システムがイベントを処理できなくなる可能性があります。
JSON で受け取る場合でも、後続処理が列構造を固定的に見ていると壊れます。
監視
最低限、次のような監視が必要です。
- Event Hubs に送信できているか
- 認証情報が期限切れになっていないか
- トランザクションログが肥大化していないか
- Event Hubs 側でスロットリングされていないか
- 後続コンシューマーが遅れていないか
初心者向けに一言でまとめると
Change event streaming は、SQL Server の変更を外に伝えるための新しい入口です。
従来は、外部システムが SQL Server に聞きに行っていました。
Change event streaming では、SQL Server の変更がイベントとして流れます。
つまり、SQL Server を単なるデータ保存場所として見るのではなく、
業務イベントを発信するデータソース
として見ることができます。
まとめ
Change event streaming は、SQL Server や Azure SQL のデータ変更を Azure Event Hubs に流す機能です。
ポイントは次の通りです。
個人的には、Change event streaming は SQL Server 2025 世代の中でもかなり面白い機能だと思います。
これまで SQL Server は、アプリケーションから問い合わせられる存在でした。
これからは、
SQL Server 自身がイベントを発信する
という見方ができます。
これは、SQL Server と Microsoft Fabric、リアルタイム分析、イベント駆動アーキテクチャをつなぐ重要な機能になりそうです。
参考
- Microsoft Learn: 変更イベント ストリーミングとは
- Microsoft Learn: Configure Change Event Streaming
- Microsoft Learn: Frequently Asked Questions for Change Event Streaming
- Microsoft Learn: Microsoft Fabric Eventstreams Overview
- Microsoft Learn: Stream SQL Change Events to Eventstream for Real-Time Processing