【要約】Aurora MySQL→BigQueryのデータ転送パイプラインをFivetranに移行している話 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
メドレーのSREチームは、Aurora MySQLからBigQueryへのデータ転送にEmbulkを使用していた。しかし、Embulkのメンテナンスモード移行と、バッチ転送特有の課題に直面した。
- ・Embulkのメンテナンスモード移行に伴う運用・セキュリティリスク。
- ・バッチ転送によるデータ鮮度の低さと、物理削除への追従困難。
- ・スキーマ変更のたびに発生する手動設定の運用コスト。
- ・月間数TBに及ぶ全件転送によるネットワークコストの増大。
// Approach
チームは、データ鮮度の向上と運用コスト削減を目的に、CDC方式への移行を選択した。具体的にはFivetranを採用し、以下の手法でパイプラインを構築した。
- ・Hybrid Deploymentを利用し、自社VPC内のAgentからアウトバウンド通信のみで転送。
- ・Auroraのバイナリログを読み取り、変更分のみをBigQueryへ転送。
- ・BQのスキャンコスト抑制のため、PKでのクラスタリングと日時でのパーティショニングを適用。
- ・命名規則の制約を回避するため、Raw層とView層を分離した構成を採用。
// Result
CDCへの移行により、データ鮮度の向上と運用負荷の軽減、ネットワークコストの削減を実現した。
- ・ニアリアルタイムなデータ鮮度の確保。
- ・バイナリログ利用によるソースDBへの負荷軽減。
- ・スキーマ変更の自動追従による開発工数の削減。
- ・今後の展望として、Iceberg Table等のOTFへの移行を検討中。
Senior Engineer Insight
> EmbulkのEOLを見据えたリスク回避は極めて妥当である。FivetranのHybrid Deploymentによるセキュリティ確保は、個人情報を扱う現場では必須要件だ。ただし、BigQueryのパーティショニング自動設定の欠如や、型変換の挙動といった「SaaS特有の制約」への対策が不可欠となる。View層での吸収やスクリプトによるテーブル管理など、泥臭い運用設計が成功の鍵を握る。コスト面ではMARの特性を理解し、コネクション設計を最適化すべきである。