🌉
【AWS + Google Cloud】ETLデータフローを新規構築しました

Taro
2025/08/04に公開
AWS
Google Cloud
tech
 はじめに弊社サービスであるFANTSを販売・提供・運営するにあたって、日々様々なデータが社内に蓄積されています。
アプリケーションで用いるDBはもちろんですが、Google Analytics、Salesforceなど様々なサービスにデータが格納されています。

これらのデータはそれぞれが非常に貴重な情報源ですが、サービスごとに点在しているため、全体像を把握したり、より深い分析に活用したりするには課題がありました。
この課題を解決するために、今回新たにAWSとGoogle Cloudを組み合わせてETLデータフローを構築することにしました。

本記事では、Amazon AuroraのデータをBigQueryからクエリできるようにしたデータフローの部分について紹介したいと思います。

 サービスの紹介私たちは、オンラインコミュニティのプラットフォームサービス「FANTS(ファンツ)」を提供・開発しています。

https://fants.jp/

 FANTSを取り巻くデータ環境FANTSは、主にAWSを用いた開発・運用を行っています。
アプリケーションはAWS上で動作
DBはAmazon Auroraを使用
加えて、下記のサービスなども利用しています。
ユーザー行動分析: Google Analytics 4 (GA4)
顧客管理・営業活動: Salesforce
このように、FANTSを取り巻くデータは様々なデータソースに分散しています。

 解決したい課題FANTSの成長に伴い、社内には日々膨大なデータが蓄積されています。しかし、これらのデータが複数のサービスに分散しているため、データソースを横断した統合的な分析が困難という課題に直面していました。
結果として、サービス全体を通したユーザー行動の一連の流れを正確に把握したり、ボトルネックを特定したりすることが難しい状況でした。これにより、迅速な意思決定や効果的な施策立案に支障が出ていました。

 なぜAWS + Google Cloudの構成なのか?FANTSのデータ環境でご紹介したように、私たちのアプリケーション基盤はAWSで動いています。

今でも社内にはETL基盤は存在しており、一部のデータ分析には利用していました。
一方で、既存のETL基盤にはいくつかの課題がありました。
AWSに閉じた基盤だったため、Google AnalyticsやSalesforceといった外部サービスからのデータを取り込みには対応していない
長年運用されてきた基盤のため、現在のデータ規模や分析要件には最適とは言えず、より効率的でスケーラブルな構成への刷新が必要
これらの課題を解決し、すべてのデータを一元的に扱える分析基盤を構築するため、私たちはAWSとGoogle Cloudのハイブリッド構成を選択しました。
特にGoogle Cloudの活用は、以下の点で大きなメリットがあると考えました。
ユーザー行動分析に不可欠なGA4のデータは、BigQueryへ直接連携が可能で、非常にスムーズかつ効率的なデータ取り込みが期待できる
Looker Studioとの連携が強力で、ビジネスユーザーが容易にデータへアクセスできる環境を構築できる
以上のことから、既存のAWS環境を活かしつつ、データ分析基盤においてはGoogle Cloudの強みを活用することで、堅牢で柔軟なETLデータフローが実現できると考えました。

 今回構築したETLデータフロー分散した各種データソースをGoogle Cloudに集結させるにあたって、本記事では、その中でも特に主要なデータであるAmazon AuroraのデータをBigQueryからクエリできるようにするためのデータフローについてご紹介します。
今回構築したETLデータフローの構成図は下記のとおりです。

(細かいリソースに関しては省略しています)

まずはAWS側の解説をします。



Auroraの自動スナップショットの取得完了イベントをトリガーとしてデータフローを動かすようにしています。

スナップショットはままでは使えないので、スナップショットのエクスポート機能を使ってparquet形式でS3に出力するようにしています。

エクスポートが終わり次第、Glue ETL Jobを用いてBigQueryでクエリしやすいようにデータを加工しています。ここでは主に日毎のデータを効率よくBigQueryでクエリするために、Hive形式のパーティショニングの追加などの処理を行っています。

ワークフローの最後に、Google Cloud側で用意したAPI Gatewayを呼び出すLambdaを実行しています。
次にGoogle Cloud側の解説をします。



Storage Transfer Service(STS)を使ってS3から高速かつ安全にデータを転送するようにしています。

GCSへ転送されてきたデータはDataplexにより自動でスキャンされ、メタデータカタログへ登録・更新されるようにしています。

Dataplexを用いることで、GCS上のデータをBigQueryから透過的にクエリすることができるようになります。

 今回の構成のポイント今回のETLデータフローでは、特に下記の点に注力して技術選定やデータフローを構築しました。
メンテナンスコストの削減
社内ですでに動いているETLデータフローはAWS Step Functionsで構成されています。このワークフローは非常に多くのLambdaと複雑なステートの条件分岐によって構成されており、メンテナンス・デバッグといった点が課題となっていました。

今回の新規構成では、AWS Step Functionsの最適化されたサービスと Step Functions の統合機能やJSONataを積極的に持ちることで、自前のコードを可能な限り減らし、非常にシンプルな構成にすることができました。
パフォーマンス改善
上記で説明したように、既存のETLデータフローは複雑な構成だったため十分なパフォーマンス改善ができませんでした。

今回の新規構成はシンプルな構成になったおかげで、ボトルネックの特定や改善がしやすくなりました。

改善の結果、既存のETLデータフローは日々3時間30分〜4時間程度かかっていましたが、今回の構成では1時間30分程度で完了するようになり、おおよそ2.3倍の高速化を実現しました。
Storage Transfer Serviceの使用
STSを使うことによって、S3からGCSへの高速かつ安全なデータ転送を実現しました。

また、STSには重複するデータの取り扱いに関する設定が可能で、転送済みのデータに関しては転送をスキップすることができるので大変便利です。
Dataplexの使用
今回のキモです。GCSに格納されたParquet形式のデータはDataplexによって自動的にスキャンされ、そのスキーマ情報がメタデータカタログに登録されます。Dataplexはテーブルの追加やカラム構造の変化も自動でカタログに反映してくれます。これにより、BigQuery上では常に最新の状態のテーブルに対する透過的なクエリを実現しました。

 まとめと今後の展望今回、AWSとGoogle Cloudを組み合わせた新たなETLデータフローを構築したことで、FANTSのデータ活用は更に進化し、ビジネスの意思決定を加速させる大きな一歩を踏み出すことができました。
AWS + Google Cloudのハイブリッド構成により、分散していた多様なデータソースをBigQueryに集約できるようにしました。これにより、ユーザーの行動分析や、データに基づいた迅速な意思決定と施策立案を推進できるようになりました。
また、メンテナンスコストと今後の運用を見越してサーバーレスアーキテクチャを採用し、ワークフローを徹底的に簡素化しました。これにより、運用負荷の削減とデータ処理のパフォーマンスを大幅に向上させることができました。Dataplexによるスキーマ自動管理も導入したことで、データ構造の変化に柔軟に対応し、データ活用の柔軟性と信頼性を高めることができました。
今後は、さらなるデータソースの統合や、BigQueryに集約されたデータを活用した機械学習の応用など、より高度なデータ活用を目指し、ビジネス価値の最大化に貢献していきたいと思います。

 おわりに私たちの開発環境はAWSがほぼ全てで、Google Cloudの本格的な導入は今回が初めてでした。Google Cloudにおけるソリューション検討や技術選定を進めるにあたり、議論の相手としてGeminiやChatGPTが大変役に立ちました。
AIによる回答は誤った情報も含まれていることがあるため、最終的には公式ドキュメントでの確認や実環境での検証は今まで通り必須ですが、アイデア出しや技術選定におけるとっかかりの部分に大きく貢献してくれました。