RDS(PostgreSQL)のCDCをDatastreamでBigQueryへ〜Publication設定で起きた落とし穴〜

ツール導入前の課題

ワンキャリアでは、アプリケーションのデータベースとして 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 から以下の手順で除外して対処しました。

1. GCP 側の Datastream のストリーム設定で、転送対象から schema_migrations を除外
2. DB 側で ALTER PUBLICATION ... DROP TABLE schema_migrations; のように Publication からテーブルを除外
3. 転送対象外になったことを確認後、Rails の migration を再実行

Datastream では、CDC 転送を停止せずに転送対象テーブルの追加・除外を行えます。そのためダウンタイムが発生せずに対処することができました。追加時は DB 側で Publication への追加が必要です。

また、そもそも主キーやユニークインデックスを持たないテーブルを転送対象に入れる場合は、UPDATE／DELETE の有無や運用影響を事前に確認し、必要性が高いテーブルに限定するのが安全です。

RDS（PostgreSQL）から BigQuery へのリアルタイム連携を検討している方にとって、有力な選択肢です。最大のハードルは PostgreSQL の Publication 設定です。事前に RDS 特有の制約を把握したうえで着手することを強く推奨します。

また、パラメータグループで rds.logical_replication を有効化する際は、RDS インスタンスの再起動が必要になります。本番環境での作業となるため、メンテナンスウィンドウの設定や事前の関係者への周知など、ダウンタイムを考慮した計画を立てることが重要です。

一方で、運用面では Stream を停止せずに、CDC 転送対象のテーブルを追加・除外できる点が便利です。監視したいテーブルが増えた場合や、不要になったテーブルを転送対象から外したい場合でも、Stream を停止せずに柔軟に対応できるため、運用開始後の変更コストを低く抑えられます。

一度設定が完了すれば運用の手間はほとんどかからず、BigQuery 上でリアルタイムデータを活用できる体験には大きな価値があります。マネージドサービスとしての完成度は高く、少人数のデータチームでも十分に運用可能です。