SQL Serverのレプリケーションと変更データキャプチャ（CDC）を、同じもののように扱ってしまうケースは少なくありません。両者は内部の仕組みの一部を共有していますが、実際に担っている役割はまったく異なります。この違いを設計前に正しく理解できているかどうかが、きれいにスケールするシステムと、半年後に手直しを繰り返すシステムの分かれ目になります。

では、どちらを選ぶべきなのでしょうか。答えは、何を実現したいかによって変わります。レポート用のレプリカを最新に保つことと、データウェアハウスへ増分更新を送り込むことは別の課題です。コンプライアンス対応のために完全な変更履歴を残すことも、また別の課題になります。

SQL Serverには、それぞれの用途に合わせた専用の機能が用意されています。選択を誤ると、運用上の負債が積み重なっていきます。本記事では、レプリケーションとCDCの仕組みの違いから、パフォーマンスへの影響、企業での使い分けの基準までを整理します。

レプリケーションとCDCの違いとは？

SQL Serverのレプリケーションは、データベースを同期状態に保つための仕組みです。ソースデータベースのスキーマとデータを1つ以上のターゲットへコピーします。変更を反映することで、各サブスクライバーを常に最新の状態に保ちます。ターゲットは常に問い合わせ可能なレプリカとなり、配信処理そのものはプラットフォームが管理します。各方式の設定手順まで詳しく知りたい方は、SQL Serverレプリケーション完全ガイドで基礎から解説しています。

CDCはログベースの追跡機能です。トランザクションログを非同期に読み取り、すべての挿入・更新・削除を変更テーブルへ書き込みます。各行について、変更前と変更後の状態を記録します。レプリカを保持するわけではありません。後続のシステムやETLパイプライン、分析ツールが利用できる詳細な変更フィードを生成する点が特徴です。CDCの仕組みや各種手法をさらに詳しく知りたい方は、CDCとは？基本から仕組みまで解説で整理しています。

SQL Serverのレプリケーションはどう動く？

レプリケーションは、パブリッシャー・ディストリビューター・サブスクライバーという3つの役割で構成されます。パブリッシャーはソースデータベースです。レプリケーション対象となるアーティクル（テーブル、ビュー、ストアドプロシージャなど）の集合であるパブリケーションを定義します。ディストリビューターはレプリケーションのメタデータとキューに入ったトランザクションをディストリビューションデータベースに保持し、ソースとターゲットの間のバッファとして機能します。サブスクライバーはレプリケートされたデータを受け取り、適用する役割を担います。

• スナップショットレプリケーション：スケジュールされた間隔でデータセット全体をコピーします。変更頻度が低い小規模な参照テーブルに向いており、他のすべてのレプリケーション方式も初回同期にはスナップショットを使用します。

• トランザクショナルレプリケーション：まずスナップショットで開始します。その後、コミットされたトランザクションをニアリアルタイムでサブスクライバーへストリーミングします。順序とトランザクション境界を保持するため、低レイテンシのレポーティングやOLTPワークロードのオフロードに標準的に選ばれる方式です。

• マージレプリケーション：パブリッシャーとサブスクライバーの双方向での編集に対応し、競合の検出と解決の仕組みを備えています。支店やモバイルアプリケーションのように、複数のノードで書き込みが発生する分散環境やオフライン環境向けに設計されています。

• ピアツーピアレプリケーション：複数のノードをパブリッシャーとサブスクライバーの両方として接続し、アクティブ・アクティブ構成を実現します。読み取りのスケーリングと可用性を高められますが、競合解決の機能は組み込まれていません。そのため、同じ行が複数の場所で同時に更新されないよう、書き込みを分割しておく必要があります。

Log Reader Agentは、ソースのトランザクションログからコミット済みのトランザクションを読み取ります。読み取ったトランザクションは、ディストリビューションデータベースへ転送されます。Distribution Agentはそこからトランザクションを取得し、サブスクライバーへ適用します。パブリッシュされたデータベースには、それぞれ専用のLog Reader Agentが割り当てられます。

CDCはどのように動作する？

CDCも同じトランザクションログを読み取りますが、その目的は配信ではなく観測です。テーブルでCDCを有効にすると、SQL Serverはソースのスキーマをミラーした変更テーブルを作成し、次の5つのメタデータ列を追加します。

• __$start_lsn：コミット時のログシーケンス番号

• __$end_lsn：列自体は存在するものの常にNULLで、非サポートです。使用しないでください

• __$seqval：トランザクション内の操作の順序

• __$operation：1=削除、2=挿入、3=更新前イメージ、4=更新後イメージ

• __$update_mask：どの列が変更されたかを示すビットマスク

挿入と削除は、それぞれ変更テーブルに1行を生成します。更新の場合は、変更前イメージと変更後イメージの2行が生成されます。この完全な履歴を残せる点が、CDCをよりシンプルな変更追跡の仕組みと区別する特徴です。

トリガーベースの変更キャプチャとは異なり、CDCはユーザートランザクションの中で同期的なロジックを実行しない点が特徴です。キャプチャジョブはコミット後に非同期で実行されるため、本番環境の書き込みパフォーマンスへの影響はほとんどありません。利用側は、変更テーブルを直接スキャンしません。代わりに、ログシーケンス番号（LSN）の範囲を指定したテーブル値関数を通じて変更を取得します。

運用面で知っておきたい点として、キャプチャジョブの処理が遅れたり完全に停止したりすることがあります。その場合、トランザクションログを切り詰められなくなります。ログファイルはキャプチャ処理が追いつくまで肥大化を続けます。負荷の高いシステムでジョブを監視していないと、短時間で深刻な状態に陥ることがあります。

レプリケーションの4方式は何が違う？

レプリケーションとCDCはそれぞれ何を記録する？

レプリケーションは、行の現在の状態をサブスクライバーへ届けます。同期サイクルの間に1つの行が5回変更されたとしても、サブスクライバーが目にするのは最終的な値だけです。現在の状態だけを必要とする運用系の参照であれば問題ありませんが、変更の全履歴が必要な用途には向きません。

CDCは、途中のすべての状態を記録します。5回変更された行であれば、変更テーブルには5件のエントリが生成されます。それぞれに、行全体のデータと操作のメタデータが含まれます。更新では、変更前と変更後の両方のイメージが記録されます。そのため、コンプライアンス対応や監査ログにとって、変更テーブルは有用な情報源になります。最終的な値だけでなく、変更の内容そのものを理解する必要がある後続システムにとっても同様です。

CDCは主キーによる検索に依存せず行全体を記録するため、主キーを持たないテーブルでも変更テーブルを利用できます。

パフォーマンスへの影響と運用コストは？

レプリケーションとCDCはいずれも、稼働中のテーブルへ直接クエリを発行するのではなく、トランザクションログを読み取ります。そのため、トリガーベースの方式よりも影響は小さくなります。ただし、負荷が現れる場所はそれぞれ異なる点に注意が必要です。

レプリケーションの場合、主なコストは次の3つです。

• エージェント処理（Log Reader AgentとDistribution Agentが常時稼働する）

• ディストリビューションデータベースのI/O

• サブスクライバーへのネットワークトラフィック

サブスクライバー数が多くなると、ディストリビューションデータベースがボトルネックになります。

CDCの場合、キャプチャジョブは追跡対象のDML操作が発生するたびに行全体のデータを変更テーブルへ書き込む仕組みです。更新頻度の高いテーブルでは、変更テーブルは急速に肥大化します。クリーンアップジョブは既定で1日1回実行され、履歴を3日分保持します。ただし、負荷の高い環境ではこの既定値の調整が必要になることが多いです。キャプチャジョブが停止するとログの切り詰めがブロックされ、問題がさらに深刻になります。

• キャプチャジョブのステータスだけでなく、レイテンシも監視する

• 3日間の保持期間が後続システムの消費ペースに合わない場合は、保持期間を調整する

• スキーマ変更や大量バッチロードの後は、トランザクションログの増加を確認する

• クリーンアップジョブがスケジュールどおりに行を削除しているかを確認する

この負荷のかかり方は、更新の入り方によって逆転します。同じ行を何度も更新するワークロードでは、レプリケーションは更新の回数をそのまま配信するため、スループットがかえって悪化することがあります。一方CDCは、cdc.fn_cdc_get_net_changes_* を使えば同じ行への複数回の更新を最終的な1件へ圧縮して取り出せます。更新頻度が高いテーブルほど、CDCのほうが有利になりやすい傾向があります。

レプリケーションとCDCは同時に使える？

CDCとトランザクショナルレプリケーションは、同じデータベース上で共存が可能です。両者は内部で同じログ読み取り処理であるsp_replcmdsを使用します。両方が有効な場合、Log Reader Agentがすべてのログ読み取りを担います。そのうえで、ディストリビューションデータベースとCDCの変更テーブルの両方にデータを供給します。単独のCDCキャプチャジョブは、同じログ読み取り呼び出しを2つのプロセスが競合しないように停止されます。

後からトランザクショナルレプリケーションを無効にすると、SQL Serverはキャプチャジョブを再作成します。この共存自体は問題なく機能します。ただし、Log Reader Agentに問題が発生すると、レプリケーションの配信とCDCのキャプチャの両方に同時に影響が及ぶため、監視の重要性がより高くなります。

スキーマ変更はどう影響する？

どちらの機能も、何らかの対応なしにスキーマ変更をスムーズに処理することはできません。

CDCの場合、テーブルで有効にするだけであればアプリケーションコードの変更は必要ありません。変更テーブルは独立したオブジェクトであり、ソースのスキーマ自体は変わらないためです。しかし、追跡対象のテーブルに列を追加した場合、SQL ServerのCDCはそれを自動的には認識しません。新しいキャプチャインスタンスを作成し、古いインスタンスを削除する必要があります。この操作は、変更フィードを利用している後続のパイプラインでテーブル全体の再取得を発生させます。

レプリケーションも同様に影響を受けやすい仕組みです。パブリッシュされたアーティクルへのスキーマ変更には、手動での再設定が必要になることがあります。場合によっては、スナップショットの再初期化が必要になることもあります。

スキーマ変更の手順は、必要になってから作るのではなく、事前に整えておくべきです。

企業でレプリケーションが向いているのはどんな場面？

• 読み取りのスケーリング：レポート用のクエリをサブスクライバーへオフロードし、OLTPのパフォーマンスを守る

• 高可用性・災害対策：すぐにプロモートできるウォームスタンバイを維持する

• 分散配置：支店やリージョンごとのサーバーを中央データベースと同期させておく

• リアルタイムの運用レポーティング：本番インスタンスに大きな負荷をかけずに、ニアリアルタイムでデータへアクセスする

企業でCDCが向いているのはどんな場面？

• ウェアハウス・データレイクへの増分ETL：実行ごとにテーブル全体を再読み込みするのではなく、変更された行だけを送信する

• ストリーミングパイプライン：KafkaやKinesisなどのメッセージキューへ変更イベントを送り、リアルタイム処理を行う

• 監査とコンプライアンス：すべてのデータ変更を、タイムスタンプ付きで完全に記録する

• マイクロサービスのイベントソーシング：データベースの変更をイベントとして扱い、後続のアプリケーションロジックを駆動する

• 分析・AIワークロード：バッチウィンドウによるデータの遅延を発生させずに、分析システムを最新の状態に保つ

• DB移行・クラウド移行：初期ロードで既存データを移したうえで、その後の差分をCDCで追いかけることで、切り替え時のダウンタイムを最小限に抑える

CDCの変更テーブルに記録される変更前・変更後のイメージは、BIやAIのユースケースで特に価値があります。値が変更される前の状態を知ることは、現在の値と同じくらい重要だからです。

クラウド・ハイブリッド環境との互換性は？

Azure SQL DatabaseでもCDCはサポートされていますが、キャプチャのスケジューラはAzure側が内部で管理しています。キャプチャジョブは20秒ごと、クリーンアップジョブは1時間ごとに実行されます。いずれの間隔も、ユーザーが設定を変更することはできません。Azure SQL DatabaseでCDCを有効にすると、Accelerated Database Recovery機能の一部である積極的なログ切り詰めが無効になります。その結果、トランザクションログの使用量が増加します。

Azure SQL Managed Instanceは、オンプレミスのSQL Serverに近い挙動をします。SQL Server Agentのジョブは通常どおり動作し、各パラメーターも設定可能です。インスタンス自体が、パブリッシャー、ディストリビューター、サブスクライバーのいずれとしても機能できます。

Azure SQL Databaseは、レプリケーション構成の中でプッシュ型のサブスクライバーとしてのみ機能します。ディストリビューションデータベースをホストすることや、パブリッシャーとして動作することはできません。この制約は、プロジェクトを始めた時点で多くのチームが想定している以上に、ハイブリッド構成の選択肢を狭めます。

複雑化と保守運用で気をつけるべき点は？

1年間問題なく動いていたレプリケーション構成であっても、データ量が増え、ディストリビューションデータベースの保守が行われないままになることがあります。その場合、レイテンシの問題が生じてきます。ピーク負荷を想定してサイズ設計されていないCDC構成も同様です。ログが満杯になるまで気づかれないまま、遅延が進んでいくことがあります。

どちらの方式でも、チームが見落としやすい障害パターンは静かに進行するタイプです。エージェントの履歴上は正常に見えるジョブが、実際には少しずつ遅延を蓄積しているケースです。稼働状況の監視だけでなく、レイテンシの監視も設定しておく必要があります。

レプリケーションとCDCが向かないのはどんな場面？

どちらの方式も万能ではありません。選定の段階で「向かない」と分かっていれば、あとから設計をやり直すコストを避けられます。

• レプリケーションが向かない場面：参照側にも強い整合性が求められるクエリ（サブスクライバーは結果整合であるため、わずかな遅延も許容できない処理はオフロードできません）と、同一行への書き込みが集中するホットレコード（更新がそのまま配信され、負荷の逃げ場がなくなります）

• CDCが向かない場面：変更頻度が極端に高いテーブル（変更テーブルとログの増加が、キャプチャとクリーンアップの処理速度を上回ります）と、最終的な値だけで十分な小規模テーブル（変更履歴を使わないのであれば、運用の手間に見合いません）

レプリケーションとCDC、導入時のベストプラクティス

レプリケーションの場合

具体的な設定手順は、SQL Serverレプリケーション設定方法でネイティブ機能とノーコードツールの比較も含めて解説しています。

• 初期化時の共有ロックを最小限に抑えるため、同時実行のスナップショット処理を使う

• ディストリビューションデータベースの保持期間は、既定値ではなく復旧に必要な期間に合わせて設定する

• サブスクライバーの再初期化は、実際に必要になって焦る前に、負荷の低い時間帯にテストしておく

CDCの場合

• 後続システムが必要としているテーブルだけでCDCを有効にする（すべてのテーブルを追跡すると、メリット以上に負荷が増える）

• キャプチャジョブがログの先頭付近を維持できるよう、maxtransとpollingintervalを調整する

• スキーマ変更の手順を文書化し、最初の本番スキーマ変更が発生する前にテストしておく

• 最初のテーブルへのCDC有効化はメタデータ作成のあいだクエリをブロックするため、アクセスのないダミーテーブルで先に有効化しておく

• 保持期間とクリーンアップの削除件数は既定値のままにせず、ロックエスカレーションが起きない範囲まで小さくして様子を見る

CData SyncならレプリケーションとCDCをどう両立できる？

多くの企業環境は、「レプリケーションだけ」あるいは「CDCだけ」ですっきり収まるものではありません。1つのSQL Serverデータベースに、レポート用のレプリカと、SnowflakeやRedshiftのウェアハウスへの増分フィードの両方が必要になることもあります。それぞれ異なる鮮度・履歴の要件を持つ利用者に対応する必要があるためです。

CData Syncなら、この2つのパターンを1つのプラットフォームで扱えます。SQL Serverをデータソースとする場合、Syncは SQL Server 組み込みのCDCまたはchange tracking機能に対応しています。いずれもログベースのCDCとして動作します。ソーステーブルへ直接クエリを発行するのではなく、変更履歴ビューから読み取ります。そのため、ソースデータベースへの負荷を抑えられます。

Syncにおける2つのモードには、実務上の違いがあります。change trackingはソース側のスキーマ変更（新しい列の追加や型の変更）を、宛先へ自動的に反映します。一方のCDCはこれを行いません。SQL ServerのネイティブCDCが新しい列を自動的には追跡しないためです。列を追加する場合は、前述のキャプチャインスタンスの作り直しが必要になり、Syncもこの再取得の影響を引き継ぎます。この違いを事前に理解しておくことで、スキーマ管理が大幅にシンプルになります。なお、CData Syncには変更検知の粒度が異なる標準ジョブとCDCジョブという2つのジョブタイプもあり、標準ジョブとCDCジョブの違いで使い分けの基準を解説しています。

Syncは、オンプレミス、自社クラウド環境（AWS、Azure、GCP）、あるいはCDataがホストするマネージドサービスとしてデプロイできます。そのため、インバウンドのファイアウォール変更やソース側への追加エージェントを必要とせずに、ハイブリッドなアーキテクチャに組み込めます。対応する宛先にはSnowflake、Amazon Redshift、Google BigQuery、Databricksをはじめとする従来型データベース群があります。さらに、400種類以上のデータソースと宛先に対応しています。SQL Server以外では、Oracle DBのログベースCDCをAmazon Redshiftへ同期する実装例をOracle DBのCDC実装例（Redshift連携）で紹介しています。

実際の運用でも、この使い分けは効いてきます。商業印刷分野の製造業では、20以上のビジネスユニットと40のデータベースに分散していたデータを、ソースDBへ負荷をかけずにCDCで取り込む構成を選びました。500以上のテーブルをSnowflakeへ統合し、2名のデータチームで月間6〜7億行を扱える体制になっています。詳細は製造業でのCDC活用事例で紹介しています。

よくある質問

レプリケーションとCDCを1プラットフォームで運用

SQL Serverでレプリカ用のレプリケーションと分析用のCDCを別々に構築すると、運用負荷が増えます。CData Syncなら、チーム全体で両方を1つのプラットフォームからノーコードに構築できます。

SQL Serverのレプリケーションとchange tracking・CDCの両方を、実際に試してみませんか。CData Syncの30日間無料トライアルから今すぐ始められます。