アプリケーションログ分析のためのCloud DataflowとBigQueryを活用したデータパイプライン構築事例

前提

弊社では、2021年からBigQueryをメインのデータ基盤として活用しています。今回取り上げる事例は、アプリケーションログをCloud Dataflowを使ってBigQueryに転送するパイプラインの一例で、このパイプラインは2024年6月から導入が開始されました。

ツール導入前の課題

弊社では既にBigQueryを分析基盤として活用しており、RDB、Firestore、外部サービスからのデータ転送パイプラインが整備されていました。しかし、サーバーアプリケーションから任意のログデータや生データを出力し、分析基盤へ転送する仕組みが不足しており、より詳細なデータ分析を行うために、ログデータをBigQueryに転送する新たなパイプラインの構築が必要となりました。

単一の要件でログを分析するだけであれば、Cloud LoggingからBigQueryを直接利用できるLog Analyticsでも十分かもしれませんが、他のデータソースとの連携や柔軟なETL処理を考慮した結果、Cloud Dataflowを活用したパイプラインの構築に至ったという経緯があります。

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

チームの規模やリソースを考えると、大規模な分析基盤を維持することは難しく、次の条件を元に選定しました。

• マネージドサービスを活用することで、メンテナンスコストを抑えれること
• 実装コストを抑え、BigQueryへのデータを転送をシンプルな形でできること
• IaCツール（Terraform）による管理が可能であること
• 類似要件が発生した際に転用・拡張が容易であること

• Google Cloud Workflows
• BigQuery を活用した Log Analytics
• アプリケーションから直接BigQueryへデータを書き込む
• アプリケーションからCloudStrageへ書き込みBigQueryへ書き込む

• より良い方法が見つかった際に、パイプラインの一部を柔軟に変更できるかどうか？

• データレイク（データソース）として利用しているCloud Storageから、シンプルにETL（抽出、変換、ロード）を実行できること。
• TerraformによるIaCが可能であること。

アプリケーション側で分析ログ用のメタデータを設定するだけで、自動的にBigQueryへ転送される仕組みが構築され、ログから分析基盤へのデータ転送がシンプルに実現できたと思っています。

さらに、別の分析要件が発生した際にも、Terraformでコードを修正するだけで新しいデータ転送を実現できる環境が整っており、現状のチーム体制としては十分に対応できています。

パイプライン導入により、アプリケーションログを活用した詳細なプロダクト分析が可能となりました。

データレイク（データソース）からのETL処理には多くの実現方法が存在するため、「Cloud StorageからのETLツールとしてCloud Dataflowを採用することが適切か？」という技術選定が悩みのポイントでした。

Cloud Dataflowの導入自体にも技術的な課題はありましたが、これらはどのツールを選んでも発生するものなので苦労した点ではなかったかなと認識しています。

BigQueryは、BIツールなどエンジニアリング以外の目的でも連携が豊富で、特にクラウドインフラにGoogle Cloudを使用している場合は非常に強力なツールです。公式ドキュメントや他社の導入事例も多く、導入リスクが低いことが魅力です。

一方、ツール連携の選択肢は多いため、自社の環境やチームに合った適切なアーキテクチャを選定することが重要です。事前に調査を行い検討されることをおすすめします。

今後もしばらくはBigQueryを中心としたデータ基盤の運用が続く見込みですが、現状まだまだ整備が整っていない箇所も多いため、サービスごとにメンテナンスしやすいアーキテクチャへと、少しずつ改善を進めていけたらと思っています。