Datastreamの導入と運用する際に気をつけたいポイント
株式会社enechain / 山田龍寬
メンバー / データエンジニア
| ツールの利用開始時期 | 事業形態 |
|---|---|
| 2025年5月 | B to B |
| ツールの利用開始時期 | 2025年5月 |
|---|---|
| 事業形態 | B to B |
アーキテクチャ
アーキテクチャの意図・工夫
バッチ取り込みを定期的に行い洗い替えテーブル(latestテーブル)を作成しつつ、Datastreamで変更イベントを別のテーブル(cdcテーブル)へと保存しています。latestテーブルとcdcテーブルを組み合わせて、PostgreSQLの状態をニアリアルタイムに提供しています(realtimeテーブル)。また、変更イベントと日毎にとっているスナップショットテーブルを組み合わせることで、任意の時間の状態を再現するテーブル関数も提供しています(time machineテーブル)。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
enechainではプロダクトのDBとしてCloudSQL for PostgreSQLを採用しており、分析等の目的のためにBigQueryへとデータを取り込む仕組みを運用しています。この仕組みは定期的に起動し、CloudSQL上のテーブルの内容でBigQuery上のテーブルを丸々置き換える、いわゆる洗い替えを行い、BigQuery上への同期を行っています。バッチ的な取り込みを運用する中で、プロダクト側からいくつかの課題や要望が上がってきました。
1. 同期頻度をあげて欲しい、リアルタイムに計算処理を行いたい
仕組み上はバッチ的な取り込みのスケジュール間隔を短くして高頻度な同期を実現できますが、プロダクト側が期待している遅延時間内でのBigQueryへの同期を保証するものでもないことと、今現在実現できていたとしても近い将来データ量の増加とともに破綻してしまうことが目に見えています。もちろん取り込み頻度が高くなることで、BigQueryのコンピュート料金もそれだけ増加してしまいます。 これらのことから、バッチ的な取り込み以外の方法でニアリアルタイムにBigQueryへ同期できるようにする必要がありました。
2. テーブルの更新履歴を記録したい
別のプロダクトからは、更新が多いテーブルの変更履歴を記録しておきたいという要望がありました。 バッチ的な取り込み実行時に、変更履歴を作る機能(前回の取り込み時と新しい取り込み時にできたテーブル間の差分からプライマリキーベースでの変更履歴をつくる)をすでに実装していましたが、定期実行される間隔ごとの差分しか作れないので、定期実行の間に特定のプライマリキーのレコードが複数回更新された場合などはその差分を作れず、今のままでは要件を満たせませんでした。そのため、CloudSQL側で変更があるたびにその変更を取り込めるような仕組みが新たに必要でした。
どのような状態を目指していたか
PostgreSQLの変更履歴をBigQuery上に溜め、それらの履歴を組み合わせて最新のテーブルの状態を再現できれば、2つの要望を叶えることができます。加えて、少ない導入コストと運用コスト、対象テーブルを絞って小さく導入でき、後々対象を拡大できる拡張性も必要でした。
比較した軸
導入コストが少ないこと。マネージドサービスからはじめ、必要になってからインフラの構築が伴うツールに手を伸ばしたい。
選定理由
CloudSQLからBigQueryへの連携が容易なこと、Google Cloudが提供しているマネージドサービスであり、導入コストが少ないため。また、変更イベントのリアルタイムな取得、対象テーブルを絞って導入できるといった必要としていた機能も備えていたため。
導入の成果
改善したかった課題はどれくらい解決されたか
プロダクトからの要望はどちらも満たすことができました。 サービス提供時のCloudSQLでは行わないような操作のタイミングでの同期的な作業は何度か発生しましたが、総じて安定した稼働をしてくれており、採用時の狙い通り少ないコストで運用を行えています。
どのような成果が得られたか
ニアリアルタイムな同期を行えるようになり、取り込み頻度をむやみやたらに短くする必要性が減りました。また、副産物として、変更イベントを利用して任意の時刻を再現するビューを提供できるようになり、その時の状態(いわゆる断面)をピンポイントに取得でき、シミューレーションや計算処理に利用できるようになりました。
導入時の苦労・悩み
プロダクト側と同期的に、順番を気にしながら行う必要がある作業がたびたび発生します。
CloudSQLの再起動が伴う
DatastreamはPostgreSQLの論理レプリケーションを利用するため、 まずは有効化する必要があります。 これはGoogle Cloudのドキュメントにある通りなのですが、データベースフラグのlogical_decodingを有効化する作業は、CloudSQLの再起動を伴うため、注意が必要です。 Datastreamを導入する際には、既存のDBに対して追加で作業をすることになると思うので、 プロダクト側とメンテナンス等の日程調整を行い導入を進める必要があります。
PostgreSQL for CloudSQLのメジャーバージョンアップ時にレプリケーションスロットが消える
PostgreSQLはメジャーバージョンアップ時に、レプリケーションスロットの情報を引き継がないため、 メジャーバージョンアップ作業後にレプリケーションスロットの再作成が必要です。 この場合、Datastreamの再作成は不要で、Google Cloudのコンソールから「ストリームの復元」をポチっとすることで復旧できるため、対応自体は簡単です。
とはいえ、プロダクトに何かしらの方法でレプリケーションスロットを作成するクエリを実行してもらわないといけないため、 緊張感のあるクエリの直接実行か、わざわざマイグレーションファイルを用意するといった手間をプロダクト側に取らせることになります
対象テーブルを増やす時は順番が大事
CDC対象のテーブルを増やしたい場合は、以下のステップを踏む必要があります。
- 新しい対象テーブルにアクセスできるようにする
- 新しい対象テーブルをパブリケーションに追加する
- Datastreamの対象に新しい対象テーブルを追加する
パブリケーションに新しいテーブルを追加していない状態で、Datastream側の更新を行うと、Datastreamはエラーを吐いてしまいます。 責任範囲として、ステップ1,2はプロダクト側に実行してもらい、ステップ3をこちらのチームで行う場合がほとんどだと思います。 そのため、プロダクト側のリリーススケジュールとの調整も含め、2チーム間で連携をして順番に進める必要があるので、注意が必要です。
サポートされていないデータ型がある
Datastreamではサポートされていないデータ型がいくつかあり、そうしたカラムはCDC対象から除外されてしまい、カラムが足りないテーブルがBigQuery上に作成されます。ニアリアルタイム性を求める利用者が、このサポート外のデータ型をもつカラムを利用している場合、 その要件を満たすことができなくなってしまいます。 一方で、こうしたCDCによる取り込み設定はDB上にテーブルができてから後追いで入れることが多いため、 Datastreamでサポートしていないからとテーブルのデータ型の変更をプロダクト側に求めるのはとてもハードルが高く、 現実的ではありません。現状よい解決方法は見つかっていないです。
導入に向けた社内への説明
上長・チームへの説明
導入スピードと運用コストをなるべく小さな状態でスタートしたかったため、まずはマネージドサービスを利用してみて、要件の足りない部分(先にあげたプロダクト側の要望)が出てきたらOSS等の検討をすることに。
活用方法
よく使う機能
- 変更イベントの保存
ツールの良い点
- CloudSQLからBigQueryへの連携が容易
- ほぼリアルタイムに変更イベントがBigQueryへ保存される
- 対象テーブルを絞って小さく始めることができる
ツールの課題点
- サポートされていないカラムが存在する
- PostgreSQLのスキーマ変更に合わせてBigQueryテーブルスキーマを変更してくれるが、テーブルの再作成が必要になる場合、Datastreamでは対応できず、その間流れてくる変更イベントはすべて破棄される
- BigQueryを宛先にすると、デッドレターキューのような退避先を設定できない
- Datastreamの宛先をCloud Storageにして、そのファイル群をDataflowで処理することでカスタマイズ可能ではある
- PostgreSQLの障害等に伴う昇格等に対応できない
- クロスリージョンレプリカへの対応
- (PostgreSQLのバージョンによっては工夫したらできそうではある)
ツールを検討されている方へ
導入自体はすぐにできますし、総じて安定した稼働をしてくれており、平常時の運用自体はとても楽ですが、プロダクトとの同期的な作業が必要になる場面があるため、密に連携を取る必要があります。 また、データソースのレプリケーションについての一定の知識が必要になること、サポート対象外のカラムはBigQuery上にカラムがつくられなかったり、スキーマ変更でデータ型が変換できない場合、変更イベントが破棄される点にも注意が必要です。
今後の展望
CloudSQLインスタンスのレプリカからの昇格に現在対応できていない状態です。特にクロスリージョンレプリカの権限昇格時にはDatastreamによる変更イベントの取得をどうにかできないかと考えています。PostgreSQLの新しいバージョンでは論理レプリケーションに更新が入っているので、それが利用できないか期待しています。
株式会社enechain / 山田龍寬
メンバー / データエンジニア
よく見られているレビュー
株式会社enechain / 山田龍寬
メンバー / データエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


