Datastream

解決する課題

運用中の本番データベースに重い負荷をかけず、その変更を分析基盤や別システムへ準リアルタイムで届けたい、というニーズに応えます。

• 分析のたびに本番DBへ直接クエリすると負荷が高い → 変更だけを別基盤に流して分析を切り離したい
• バッチで全量コピーすると遅く・重い → トランザクションログ由来の**差分（CDC）**で軽く取り込みたい
• レプリケーション基盤の構築・運用が面倒 → サーバーレスでマネージドに任せたい
• ソースDBと分析用 BigQuery の鮮度差を縮め、ほぼ最新のデータで分析・可視化したい

主要概念と用語

• CDC（Change Data Capture）: テーブルを丸ごと読み直すのではなく、DBのトランザクションログから挿入・更新・削除の変更だけを抽出して伝える方式
• ソース（source）: 変更を取り出す元のデータベース。MySQL / PostgreSQL / Oracle / SQL Server などに対応
• デスティネーション（destination）: 変更を書き込む先。BigQuery または Cloud Storage を選べる
• 接続プロファイル（connection profile）: ソース・デスティネーションへの接続情報（ホスト・認証・ネットワーク経路）を再利用可能な形で定義したもの
• ストリーム（stream）: ソースの接続プロファイルとデスティネーションの接続プロファイルを結びつけ、対象スキーマ・テーブルや取り込み設定を持つ複製ジョブ本体
• バックフィル（backfill）: ストリーム開始時に既存データを一括で初期コピーする処理。以降は CDC で差分のみを継続取り込みする

仕様・制限・クォータ

• 対応ソースは MySQL / PostgreSQL / Oracle / SQL Server など。デスティネーションは BigQuery / Cloud Storage が中心（対応バージョンや組み合わせは更新されるため公式の最新一覧を確認）
• CDC を使うにはソース側でログ出力の有効化が前提。MySQL はバイナリログ、PostgreSQL は論理レプリケーション（レプリケーションスロット）、Oracle はアーカイブログ／補足ロギングなど、エンジンごとの設定が要る
• 取り込みは準リアルタイムであり、厳密な同期ではなく多少の遅延を伴う
• スキーマ変更（列追加など）の追従可否や、特定のデータ型・大きなオブジェクトの扱いには制約がある
• 同時実行ストリーム数やスループットなどに上限があり、プロジェクト／リージョン単位のクォータとして管理される

具体的なクォータ値・対応バージョン・料金は変動するため、本番設計時は公式ドキュメントの最新値を参照してください。

内部の仕組み

Datastream はソースDBのトランザクションログを継続的に読み取り、行レベルの変更イベント（挿入・更新・削除）として取り出します。ストリーム開始時にはまず既存データをバックフィルで初期コピーし、その後はログから得た差分のみを流し続けるため、全量スキャンを繰り返すよりソースDBへの負荷が小さくなります。

取り出した変更は、デスティネーションに応じて書き込み方法が変わります。BigQuery を選ぶと、ソースの変更がテーブルへ準リアルタイムに反映（マージ）され、ほぼ最新の状態を分析対象にできます。Cloud Storage を選ぶと、変更イベントが Avro や JSON などのファイルとして連続的に書き出され、後段の Dataflow や Dataproc などで自由に加工・取り込みできます。

設計パターン / ベストプラクティス

• 分析用途では BigQuery デスティネーションを選び、本番DBの鮮度に近いデータで分析・ダッシュボードを更新する
• 自由な前処理や複数システム連携が要るなら Cloud Storage デスティネーションにし、後段の Dataflow / Dataproc で変換する
• ソース側のログ設定（バイナリログ・論理レプリケーション・アーカイブログなど）を事前に有効化し、ログ保持期間を取り込み遅延より十分長くしておく
• 接続は限定公開（プライベート）接続を基本にし、インターネットへ DB を公開しない
• 対象テーブルやスキーマを必要な範囲に絞り、不要なテーブルまで取り込まないことでスループットとコストを抑える

運用・監視

• Cloud Monitoring / Cloud Logging でストリームの状態・スループット・取り込み遅延（鮮度）を可視化する
• ストリームが一時停止・失敗した場合は、ソース側のログ保持切れ・権限不足・ネットワーク経路を確認する
• ログ保持期間を超えて停止すると差分を取りこぼすおそれがあるため、長期停止時は再バックフィルの要否を検討する
• スキーマ変更を行う際は、追従可否と影響範囲を事前に確認してから適用する

コスト

課金の基本は「処理したデータ量（取り込み・配信されたバイト）」を軸にした従量制です。加えて、デスティネーション側の BigQuery ストレージ／クエリや Cloud Storage 保存、ネットワーク転送など、連携先の費用も合わせて発生します。

定常運用では CDC 差分が中心で軽くなりますが、初回バックフィルや大量更新が走るタイミングでは処理量が増える点に注意します。

セキュリティ

• 転送経路は**限定公開接続（VPC ピアリングなどのプライベート経路）**を基本にし、DB をインターネットへ公開しない
• ソースDBへは専用の最小権限ユーザーで接続し、レプリケーション・読み取りに必要な権限のみを付与する
• アクセス制御は IAM で行い、ストリームや接続プロファイルの操作権限を最小化する
• 保存・転送時の暗号化や監査ログ（Cloud Audit Logs）で、データの流れと操作を追跡できるようにする

関連サービス・比較

GCP 内では、変更を BigQuery に流して分析する、または Cloud Storage に書き出して Dataflow / Dataproc で加工する、という連携が中心になります。Datastream は「ソースから変更を取り出して届ける CDC 部分」を担い、その先の保存・変換・分析は連携先サービスが担当する、という役割分担です。AWS で最も近いのは、DMS（Database Migration Service）の CDC 機能です。

ハンズオン / CLI例

# ソース（MySQL）への接続プロファイルを作成
gcloud datastream connection-profiles create mysql-src \
  --location=asia-northeast1 \
  --type=mysql \
  --mysql-hostname=10.0.0.5 \
  --mysql-port=3306 \
  --mysql-username=datastream \
  --mysql-password=CHANGE_ME_USE_SECRET_MANAGER \
  --display-name="mysql source"

# デスティネーション（BigQuery）への接続プロファイルを作成
gcloud datastream connection-profiles create bq-dest \
  --location=asia-northeast1 \
  --type=bigquery \
  --display-name="bigquery destination"

# ソースとデスティネーションを結ぶストリームを作成
gcloud datastream streams create my-stream \
  --location=asia-northeast1 \
  --source=mysql-src \
  --destination=bq-dest \
  --display-name="mysql to bigquery" \
  --mysql-source-config=source-config.json \
  --bigquery-destination-config=dest-config.json \
  --backfill-all

# ストリームを開始（バックフィル後に CDC へ移行）
gcloud datastream streams update my-stream \
  --location=asia-northeast1 \
  --state=RUNNING \
  --update-mask=state