Datastreamの導入と運用する際に気をつけたいポイント

ツール導入前の課題

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対象のテーブルを増やしたい場合は、以下のステップを踏む必要があります。

1. 新しい対象テーブルにアクセスできるようにする
2. 新しい対象テーブルをパブリケーションに追加する
3. Datastreamの対象に新しい対象テーブルを追加する

パブリケーションに新しいテーブルを追加していない状態で、Datastream側の更新を行うと、Datastreamはエラーを吐いてしまいます。 責任範囲として、ステップ1,2はプロダクト側に実行してもらい、ステップ3をこちらのチームで行う場合がほとんどだと思います。 そのため、プロダクト側のリリーススケジュールとの調整も含め、2チーム間で連携をして順番に進める必要があるので、注意が必要です。

サポートされていないデータ型がある

Datastreamではサポートされていないデータ型がいくつかあり、そうしたカラムはCDC対象から除外されてしまい、カラムが足りないテーブルがBigQuery上に作成されます。ニアリアルタイム性を求める利用者が、このサポート外のデータ型をもつカラムを利用している場合、 その要件を満たすことができなくなってしまいます。 一方で、こうしたCDCによる取り込み設定はDB上にテーブルができてから後追いで入れることが多いため、 Datastreamでサポートしていないからとテーブルのデータ型の変更をプロダクト側に求めるのはとてもハードルが高く、 現実的ではありません。現状よい解決方法は見つかっていないです。

導入自体はすぐにできますし、総じて安定した稼働をしてくれており、平常時の運用自体はとても楽ですが、プロダクトとの同期的な作業が必要になる場面があるため、密に連携を取る必要があります。 また、データソースのレプリケーションについての一定の知識が必要になること、サポート対象外のカラムはBigQuery上にカラムがつくられなかったり、スキーマ変更でデータ型が変換できない場合、変更イベントが破棄される点にも注意が必要です。

CloudSQLインスタンスのレプリカからの昇格に現在対応できていない状態です。特にクロスリージョンレプリカの権限昇格時にはDatastreamによる変更イベントの取得をどうにかできないかと考えています。PostgreSQLの新しいバージョンでは論理レプリケーションに更新が入っているので、それが利用できないか期待しています。