RDS(PostgreSQL)のCDCをDatastreamでBigQueryへ〜Publication設定で起きた落とし穴〜
株式会社ワンキャリア / masaki tsukada
メンバー / データエンジニア
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 11名〜50名 | 2025年8月 | B to B B to C |
| ツールの利用規模 | 11名〜50名 |
|---|---|
| ツールの利用開始時期 | 2025年8月 |
| 事業形態 | B to B B to C |
アーキテクチャ

アーキテクチャの意図・工夫
AWS ↔ GCP のクロスクラウド構成
アプリは AWS、データ基盤は GCP という既存の構成を活かすため、Datastream のクロスクラウド対応が必須条件でした。特に、図中の赤枠で囲われているトンネルが複数ある HA VPN 構成は、99.99% のサービス可用性 SLA を実現します。(参考)
CDC(論理レプリケーション)の採用
INSERT/UPDATE/DELETE の差分のみを連携でき、BigQuery 側への負荷やコストを最小化しています
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
ワンキャリアでは、アプリケーションのデータベースとして AWS RDS(PostgreSQL)を利用し、分析基盤として Google BigQuery も活用しています。
当時は BigQuery 上に RDS のデータが存在しておらず、RDS のデータを用いた分析を BigQuery のみで完結できない状態でした。
そのため、RDS のデータを参照する必要がある場合は、Redash から直接 RDS に接続してクエリを実行する運用としていました。
しかし、この運用ではアクセスログと RDSのデータを組み合わせて分析したい場合でも、JOIN した分析がしづらい状況でした。
そこで、RDS のデータを BigQuery に連携し、BigQuery 上で分析を完結できる状態を目指しました。
どのような状態を目指していたか
RDS のデータを BigQuery へリアルタイムで自動連携し、データアナリストやマーケターが分析や施策立案を迅速に行える環境を整備することを目標としました。
比較した軸
- AWS(RDS)と GCP(BigQuery)をまたぐクロスクラウド連携に対応しているか
- PostgreSQL の CDC(論理レプリケーション)に対応しているか
PostgreSQLのCDC(論理レプリケーション)については弊社テックブログの「そもそもCDC(変更データキャプチャ)とは?」という章で解説しております(リンク)。
選定理由
- Datastream が PostgreSQL の論理レプリケーション(CDC)をネイティブにサポートしており、BigQuery へのストリーミング連携をマネージドに実現できる点
- サーバーレスで、保守運用のコストが低いこと
導入の成果
アクセスログとの掛け合わせ分析がリアルタイムで可能に
マーケティング施策において、リアルタイムに状況を把握したい場面でリアルタイムデータが活用できるようになりました。以前はRedashでの対応が必要でしたが、BigQuery上でアクセスログデータとRDSデータを即時に組み合わせた分析が完結できるようになっています。
分析実行時間の改善
Redashに依存していた分析をBigQuery上で完結させられるようになったことで、クエリ実行時間が約20%削減されました。
導入時の苦労・悩み
- RDS のパラメータグループ設定(
rds.logical_replicationの有効化)のために、RDS クラスターの再起動が必要 - 一意なインデックス(主キーまたはユニークインデックス)を持たないテーブルを Publication に追加すると、そのテーブルに対する UPDATE/DELETE が実行できなくなる
Publicationについては弊社テックブログの「そもそもCDC(変更データキャプチャ)とは?」という章で解説しております(リンク)。
特に 2 点目の Publication の追加はアプリケーションにも影響するため、注意が必要です。主キーまたはユニークインデックスの有無を事前に確認し、分析で利用するテーブルのみに対象を絞ることを強く推奨します。
実際に発生した問題
schema_migrations テーブルを Publication 対象に追加したことで、Rails の migration が実行できなくなるという問題にも直面しました。
これは PostgreSQL の論理レプリケーションの仕様に起因します。Publication 対象のテーブルで UPDATE/DELETE をレプリケートするには REPLICA IDENTITY の設定が必要で、デフォルトでは主キーが使用されます。schema_migrations は主キーもユニークインデックスも持たないテーブルのため、DELETE 実行時に以下のエラーが発生し、migration が完走しなくなっていました。
PG::ObjectNotInPrerequisiteState: ERROR: cannot delete from table "schema_migrations" because it does not have a replica identity and publishes deletes
HINT: To enable deleting from the table, set REPLICA IDENTITY using ALTER TABLE.
解決法
問題の原因になっているテーブル(今回であれば schema_migrations)を Publication から以下の手順で除外して対処しました。
- GCP 側の Datastream のストリーム設定で、転送対象から
schema_migrationsを除外 - DB 側で
ALTER PUBLICATION ... DROP TABLE schema_migrations;のように Publication からテーブルを除外 - 転送対象外になったことを確認後、Rails の migration を再実行
Datastream では、CDC 転送を停止せずに転送対象テーブルの追加・除外を行えます。そのためダウンタイムが発生せずに対処することができました。追加時は DB 側で Publication への追加が必要です。
また、そもそも主キーやユニークインデックスを持たないテーブルを転送対象に入れる場合は、UPDATE/DELETE の有無や運用影響を事前に確認し、必要性が高いテーブルに限定するのが安全です。
導入に向けた社内への説明
上長・チームへの説明
運用コストの低さ
GCP のマネージドサービスであるため運用負荷が低く、既存の GCP コストに積み上げる形でコントロールしやすいことを説明しました。
具体的なビジネスニーズ
マーケティング施策において、リアルタイムでデータを確認したいという要件がありました。Redash でも対応は可能でしたが実行に時間を要していたため、分析ニーズに十分応えられていませんでした。
活用方法
- RDS の本番データを BigQuery にリアルタイム同期し、データアナリストが常に最新データを参照できる環境として利用
- マーケティング施策の効果測定において、アクセスログのイベントデータと RDS のユーザーデータを BigQuery 上で JOIN したリアルタイム分析に活用
よく使う機能
BigQuery へのストリーミング書き込み
ツールの良い点
- セットアップのシンプルさ:コードを書かずにCDCパイプラインを構築できる
- BigQueryとの親和性の高さ:同じGCPエコシステム内でのデータ連携のため、設定や権限管理がシームレス
- マネージドサービスとしての安定性:インフラ管理が不要で、少人数のデータチームでも安定運用できる
- クロスクラウド対応:AWS RDSとGCP BigQueryをまたいだリアルタイム連携が実現できる
ツールの課題点
- BigQuery との連携:パーティションテーブルの設定ができない。初回反映時のバックフィルに時間がかかる
- AWS と GCP の VPN 接続構成:Datastream 特有の接続設定(VPN 接続を含む)に関する情報が少なく、学習コストが高かった
ツールを検討されている方へ
RDS(PostgreSQL)から BigQuery へのリアルタイム連携を検討している方にとって、有力な選択肢です。最大のハードルは PostgreSQL の Publication 設定です。事前に RDS 特有の制約を把握したうえで着手することを強く推奨します。
また、パラメータグループで rds.logical_replication を有効化する際は、RDS インスタンスの再起動が必要になります。本番環境での作業となるため、メンテナンスウィンドウの設定や事前の関係者への周知など、ダウンタイムを考慮した計画を立てることが重要です。
一方で、運用面では Stream を停止せずに、CDC 転送対象のテーブルを追加・除外できる点が便利です。監視したいテーブルが増えた場合や、不要になったテーブルを転送対象から外したい場合でも、Stream を停止せずに柔軟に対応できるため、運用開始後の変更コストを低く抑えられます。
一度設定が完了すれば運用の手間はほとんどかからず、BigQuery 上でリアルタイムデータを活用できる体験には大きな価値があります。マネージドサービスとしての完成度は高く、少人数のデータチームでも十分に運用可能です。
株式会社ワンキャリア / masaki tsukada
メンバー / データエンジニア
よく見られているレビュー
株式会社ワンキャリア / masaki tsukada
メンバー / データエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


