テクノロジカルマーケティング部データプラットフォームグループの池谷です。
社内の Web ログ基盤を、GA4 と BigQuery をベースとする構成に刷新したプロジェクトについてご紹介します。
なにをしたか
弊社には Livesense Analytics (以下 LA) という AWS の Redshift を DWH としたデータ基盤があります。Web ログやアプリログだけでなく、事業部が保持するマスタデータのコピーも Redshift を通して社内に提供しています。ユーザー行動の分析や施策の評価、レコメンドのデータソース等で全社的に利用されています。
LA の歴史は長く、機能によっては 10 年近く提供し続けているものもあります。その中でも Web ログを収集し加工する部分は技術的負債も多く、運用面でも苦労していました。もともと Web ログの収集ツールは内製していたのですが、この度 GA4 (Google Analytics 4) をベースとしたものに作り変えることにしました。
これまでの Web ログ基盤とその課題
アーキテクチャ
こちらがこれまでの Web ログ基盤の概略図です。他のフローもあったりするのですが、ここでは省略しています。
データフロー内の左端の Web API がログ収集の受け口になっています。
ログはまず S3 に集められます。その後 EMR や Lambda にて、セッション情報の付加や分析のための情報の追加などの加工処理が施され、最終的に Redshift に格納されます。いわゆる ETL という形式をとっていたわけですね。
課題
この仕組みには大きく 2 つの課題がありました。
システムの複雑性
最も大きな課題はシステムの複雑性です。Web ログの収集と加工を行うシステムを内製するには、ログの送信を担う JavaScript の開発や加工ロジックの開発、ワークフローの構築など、幅広い技術が必要であり、開発もデータフローも複雑になりがちです。
また、弊社は事業部制を採っているのですが、時とともに事業部ごとに加工ロジックや加工フローに差異が生じてしまっていました。
このようなこともあり、今となっては例えば Elastic Beanstalk や Lambda の代わりとなる Fargate のようなより良い選択肢も登場していますが、なかなか乗り換えられないでいました。
ウェブのトレンドに追従できていない
近年の Web 技術の変遷やトレンドの変化は激しく、それらに追従できていないことも課題のひとつでした。たとえば SPA (Single Page Application) での利用時において、特殊ケースの考慮が不十分でした。
他にもプライバシー保護など、トラッキングまわりには大きなトレンドが存在しています。頻繁に変わるブラウザの API の仕様変更への追従には、工数も相当かかります。
これからの Web ログ基盤と解決された課題
GA4 について
GA4 は Universal Analytics の後継で、以下のような特徴を持っています。
- トラッキングツールのデファクトスタンダードである
- Web とアプリを統一的に扱える
- SPA にも標準対応している
- BigQuery へエクスポートする機能がある
もともと LA は Universal Analytics を参考に作られていたということもあり、上記のような特徴を加味した上で、GA4 を利用することに決めました。
アーキテクチャ
GA4 のイベントを BigQuery へ出力する機能としてはデイリーエクスポートとストリーミングエクスポートの 2 つが提供されていますが、そのうちのストリーミングエクスポートを利用しています。
加工処理は BigQuery 内で閉じているため、もともと ETL だったものが、ELT へと変わったわけですね。
社内の各種システムが Redshift へ接続しているため、現状は最終的に Redshift へコピーするようにしています。また、ユーザーの乗り換えコストを下げるため、旧ログと同様の形式になるように加工を施すようにしています。
また、ワークフローの実行には GKE 上で Argo Workflow を利用しています。
得られた恩恵
上に挙げた課題がまるっと解決されました。
- データフローが簡素化！
- 構成するシステムが減り、データフローを一気通貫で動かせるようになりました。
- デプロイが簡単！
- GKE の部分はもともとあった機械学習基盤をそのまま真似て構築しました。
- 冪等性がある！
- ログの収集やストリーム処理など複雑な部分はすべて GA4 側に吸収されたことにより、データ加工と Redshift への投入のみに注力しやすくなり、冪等性を持たせることができるようになりました。運用も楽になりますね。ありがとう冪等性。
- データフローや仕様が統一された！
- 事業部間のデータフローや仕様の差異を解消しました。その上である程度は旧ログに合わせるようには務めましたが、一部の仕様は変更しました。仕様変更をご快諾くださった各事業部のみなさんありがとうございました。
- デファクトスタンダードに乗っかれる！
- GA4 特有の癖はあるにはありますが、Web のトレンドに乗りやすく、今後も継続的に開発されることが期待できるのは良いですね。
大変だったところ
仕様の把握
僕自身 GA4 と BigQuery は初めて触りますし、LA についてもよく知らなかったので、各種ツールやシステムの仕様を把握するところからプロジェクトは始まりました。LA についてはドキュメントに残された情報が少なかったため、コードを読み込むことも多かったかなと思います。
あとから GA4 や LA の細かい仕様に気づき、そんなんあったんか...となった場面も何回かありました。はじめから情報収集が完璧にできるわけではないので、これ自体は仕方ないかなと思います。プロジェクトの前提が崩れるような制限が後から発覚するようなことが無かったのは幸いでした。
複数の事業部との連携
これまで内製化していた Web ログ収集ツールを GA4 に置き換えるわけなので、Web サービスを運営している各事業部に以下のようなことをお願いする必要がありました。
- GA4 を導入してもらう
- 新旧ログの仕様の違いを理解してもらう
- 新旧ログの差分について納得してもらう
- 分析クエリやシステムを、新ログを参照するように改変してもらう
これを全社横断的に同時並行で進める難しさというのは、エンジニアとしてはなかなか経験できないものだったと思います。
加工フローの実装部分は自分 (や自分が所属するチームのメンバー) でやるわけですから、コントロールできる部分も大きいです。しかし各事業部に上記のようなことをお願いするとなれば事情は全く異なります。事業部やチームごとにその規模も違いますし、ログの量も違います。ログを業務でどれくらい使っているかの違いもあれば、工数の余裕度にも違いがあります。そんな中で各担当者とコミュニケーションを取りながら物事を進めていくのは簡単ではなかったかなと思います。
工夫したこと
文書に残す
GA4 や BigQuery、LA の仕様から、作業メモや事業部へ通知する事柄など、とにかくあらゆることを文書形式で残しました。雑多な作業メモ以外は、自分以外の人が見ても分かるようにある程度は体裁を整えるように意識しました。このプロジェクトではプログラムの何倍も日本語を書いていたように思います。
データの使われ方を理解する
上でも述べたように、旧フローと同様の形式になるように GA4 ログにも加工を施していますが、異なるツールから得られたログなのでどうしても差分が生まれます。その差分の影響がどれほどのものかをデータの利用者に説明するために、そもそもログデータがどのように利用されているかを把握するようにしていました。具体的には、モニタリングクエリを紐解いたりアプリケーションコードを読んだりなどしていました。
差分の影響度についてはデータの利用者にお任せすることもできましたが、自分でコントロールできる範囲を広げることで、結果的にプロジェクトがスムーズに進むと考えました。
さいごに
部屋の掃除って面倒だなと思いつつも、やると気持ちがいいですよね。それと同じでシステムもきれいにするととてもすっきりします。データ基盤の一部だけとはいえ、運用コストを大きく下げる目処が付いて良かったです。将来的には DWH を BigQuery に移行したり、リアルタイムログを活用したり、やりたいことも広がりました。
それだけでなく、全社横断的に進めるプロジェクトということもあり、個人的には非常に大きな成長機会となりました。ここで得た学びは、データ基盤のさらなる改善に活かしたいと思います。
