Fivetranで実現した各マイクロサービスからのデータの集約と削除データの同期

ツール導入前の課題

会員データの検索機能を実装するにあたり、各マイクロサービスに分散したデータを集約するパイプラインが必要でした。

課題としては以下がありました

• 少人数のチームでかつ、アプリケーション側の開発に集中するためにも、パイプラインに関しては開発コスト・保守コストを最小限にする必要があった
• 削除されたデータの同期を自前で実現するには、かなり複雑なコードを書く必要性が予想された

どのような状態を目指していたか

要件を満たしたパイプラインを、より少ない実装コストで実装し、より少ない保守コストでメンテナンスできる状態を目指していました。

• 各APIからデータ取得するパイプラインを自前で実装する

少人数のチームでの開発体制になっているため、できるだけ実装コストと保守コストを抑える必要がありました。その視点で考えたときに、パイプラインの自前での実装には大きなコストがかかると予想される点がいくつかありました。

削除データの検知

各データソースから削除データを正確に検知するためには、削除フラグや削除ログを管理する必要がありますが、アプリケーション側のデータベースに変更を加える必要があるため、実装コストが大きくなることが予想されました。

削除データの同期

検知した削除データを中央のデータストアに反映させるための同期ロジックを構築する必要があります。データストアとしては、BigQueryを用いることになっていました。BigQueryは、データの追加は容易に行えますが、更新は比較的難しいデータベースです。なので、削除データや更新データの同期を自前で実装するには、大きなコストがかかることが予想されました。

保守コスト

上記の理由により、初期実装に時間がかかるのに加えて、保守コストに関しても自前の実装の場合はFivetranを使う場合に比べて大きくなることが容易に予想できました。

既に他チームにて実績があった

既に他チームにて、RDS→Fivetran→BigQueryのパイプラインが動作してる状態だったので、それをそのままトレースできるという利点が大きく、Fivetranでの実現可能性を調べるきっかけになりました。

削除データの同期に関して、Fivetran側で複数の方式が用意されていた

削除データを同期するユースケースに対しては、Fivetran側でいくつか方式が選べるようになっており、こちらを利用することで、開発コストと保守コストを大きく削減できるという点が一番大きかったです。

改善したかった課題はどれくらい解決されたか

データの信用性の確保

削除データの同期を含む差分転送の実装に成功しました。これにより、データの完全性と信用性を担保することができ、データ分析や活用において信頼できるデータ基盤を構築することができました。

パイプライン構築のリードタイム短縮

既に整備されていたRDS→Fivetran→BigQueryのトレースを行うことで、新たな実装にかかるリードタイムを短縮することができました。

保守コストの削減

Fivetranに容易されている仕組みを使って、差分転送や削除データの同期を行っていたため、基本的にコードのメンテナンスなどは発生しない状況を作れました。 動作の監視に関しても、基本的にはFivetran側に用意された仕組みを使うことで実現できました。

PostgreSQL RDSからの差分転送における削除データの同期を実現するところが、一番苦労したポイントかなと思います。他チームでの導入実績があったものの、削除データの同期に関しては知見がなく、想定通りの動作を実現するのにいくつかの課題をクリアする必要がありました。

FivetranにおけるPostgreSQL connectorにはデータの同期方式として、以下の3つの方式が選べます。

• Detect Changes via XMIN
• Detect Changes via Fivetran Teleport Sync
• Logical replication (WAL)

Detect Changes via XMIN

XMINでは削除データの同期が不可能で、今回の要件は満たせず、Logical replicationか、Teleport Syncでの同期を選ぶ必要がありました。

Detect Changes via Fivetran Teleport Sync

TeleportSyncに関しては、データベースで用いているプライマリーキーの型がサポート外で、プライマリーキーの変更はコストが高すぎると判断しました。

Logical replication (WAL)

最終的にこちらの方式で、削除データの同期を実現しました。 こちらも一部データベースの主キーを変更するなどの必要があり、Fivetran側での設定だけでは不可能でした。

具体的には、以下の設定が必要でした。

• 複合主キーを持たない中間テーブルに、複合主キーを設定
• PublicationとReplication Slotの設定

特に、複合主キー周りはアプリケーション側で使用しているデータベーススキーマを設定するライブラリとの相性によっては、かなりハッキーな解決策が必要になるケースがあるので、こちらも注意が必要です。詳しくはこちら

削除データの同期を設定する際に、データベースに依存していくつかの方法が選べるようになっていますが、データベースの設定や構成によっては、どの方法も使えない可能性がありますので、選定時に確認することをおすすめします。

Fivetranは沢山のユースケースやデータソースに対応しているため、データ周りの要件に関しては、積極的に使って実装コストや保守コストを下げていければと思っています。 実際に、請求管理データの取得に関しても、FivetranのLambda Connector を使って実装しました。これに関しても、別の記事にて解説できればと思います。