CDC

AWS環境で実現するには、主に以下の2つの方法が主流です。

それぞれの構成と特徴を詳しく解説します。

1. AWS DMS (Database Migration Service) を利用した構成

AWS DMSは、データベース間のデータ移行や継続的なレプリケーション（CDC）を行うための専用サービスです。

RDS for MySQLの設定:
- MySQLの**バイナリログ（Binlog）**を有効にし、フォーマットをROWに設定します。DMSはこれを読み取って変更を追跡します。（CDCの必須設定）
AWS DMS コンポーネント:
- レプリケーションインスタンス: データ移行（レプリケーション）を実行する専用のEC2インスタンスです。ソースとターゲットの間でデータを読み書きし、マッピングや変換を行います。
- ソースエンドポイント: RDS for MySQLへの接続情報を定義します。
- ターゲットエンドポイント: Amazon Redshiftへの接続情報を定義します。
- 移行タスク: CDC（継続的レプリケーション）を定義するコア設定です。どのテーブルを移行するか、フルロード後にCDCを継続するかなどを指定します。
データフロー:
- RDS for MySQLで変更（UPDATE/INSERT/DELETE）が発生すると、その変更がBinlogに記録されます。
- DMSのレプリケーションインスタンスがBinlogを継続的に読み取ります。
- DMSは変更データをRedshiftに適した形式に変換し、Redshiftクラスターに書き込みます（通常はS3経由でCOPYコマンドを使用）。

項目	メリット	デメリット
柔軟性	非常に高く、多種多様なデータベースに対応。テーブルやスキーマのフィルタリング、データ変換（トランスフォーメーション）も可能。
コスト		レプリケーションインスタンスの料金が継続的に発生する。
運用		インスタンスの管理（サイズ選定、冗長性など）や、Binlogの保持期間の管理が必要。
安定性	実績が豊富で安定しているが、タスク設定やインスタンスサイズによってはチューニングが必要になる場合がある。

これは、2023年以降に登場した新しい機能で、最もシンプルかつ管理負担の少ないCDCの方法です。現時点ではAurora MySQLからRedshiftへの統合が中心ですが、RDS for MySQLへの対応も進んでいます。

RDS for MySQL (または Aurora MySQL) の設定:
- 特別なCDC設定は不要で、通常のBinlogを有効にするだけで済みます。
ゼロ ETL 統合の作成:
- AWSコンソールで、ソースのRDS for MySQL/AuroraとターゲットのRedshiftクラスターを選択し、「統合」を作成します。
データフロー:
- RDS側で発生したデータ変更が、AWSのインフラストラクチャによって自動的にRedshiftにレプリケートされます。
- ユーザーは、中間でDMSインスタンスを管理したり、タスクを監視したりする必要がありません。

項目	メリット	デメリット
シンプルさ	圧倒的に簡単。DMSのようなレプリケーションインスタンスやタスク設定が不要で、運用管理負担が最小限。
コスト	DMSの専用インスタンス料金が不要（ただし、統合に伴うデータ転送やストレージの料金は発生）。
パフォーマンス	AWSネイティブな連携により、低レイテンシで一貫性の高いレプリケーションが期待できる。
制限		対応リージョンやデータベースバージョン、機能に制限がある場合がある（利用前に公式ドキュメントで確認が必要）。
柔軟性		DMSほど詳細なデータ変換やフィルタリングの柔軟性はない。

ユースケース	推奨構成	理由
最新の機能と最小限の運用負担を求める場合	2. ゼロ ETL 統合	設定がシンプルで、AWSがスケーリングと管理を担ってくれるため。
特殊なデータ変換・フィルタリングが必要な場合	1. AWS DMS	DMSの「移行タスク」で、スキーマやカラムレベルの詳細な制御が可能なため。
Aurora MySQLを使用している場合	2. ゼロ ETL 統合	Aurora MySQLからの統合は既に広く利用可能で、性能と管理面で優位性があるため。

もし、RDS for MySQLからRedshiftへのゼロ ETL統合が利用可能であれば、まずそちらを検討されることを強く推奨します。利用できない、または特殊な要件がある場合は、AWS DMSが標準的な選択肢となります。