TVerの黒瀬です。
先日開催されましたGoogle Cloud Day '23 Tourの東京会場にて、Breakout Session枠で登壇しました。
この記事では、その発表内容について概要を簡単にご紹介いたします。
なお、本発表の細かい内容については下記ページからオンデマンド配信でご覧になれます。
背景
TVerは今後のサービス改善のために、提供中の機能などの利用状況をBigQueryで集計・分析するための環境を持っていました。
そこでは、収集したいログごとに異なるサービス・プロダクトを契約し、それらを突合するなどして集計・分析していました。
課題
この従来の分析環境は次の3つの課題がありました。
- 異なるログ同士の突合に手間がかかる点
- 従来収集していなかったログを後から追加できるかどうかがログ収集サービス・プロダクト依存になっており、拡張性が限られる点
- ログ収集サービス・プロダクトごとに費用がかかるため、分析環境の維持費が高くなる点
方針
そこで、上記の課題を解決することを目的として、弊社での分析に必要なログを統合的に収集・集約するためのログ基盤であるTVerTagを開発することにしました。
アプローチ
収集部分・集約部分それぞれを次の方法で実装することにしました。
収集部分: Cloud CDNとLoad Balancerで構成したEndpointに対するtracking用pixel dataをHTTP GETするアクセスログをCloud Loggingで収集します。
集約部分: アクセスログをCloud Pub/Subへ転送し、それをCloud RunでPullして加工し、Cloud Storageに格納します。集計・分析時はそのCloud StorageをBigQueryのExternal Table経由で参照するようにします。
当初この構成で運用していたのですが、問題が出てきたため、それぞれ次のように解決しました。
External Tableへクエリを実行するためにはExternal TableだけでなくCloud Storageの読み取り権限も必要となり、権限を2重管理する手間が発生しました。そこで当時GAになったBigLakeを利用することで、Cloud Storageへの読み取り権限をBigQueryに移譲させ、結果External Tableへの読み取り権限のみケアすればよくなりました。
Cloud Storageに格納されているオブジェクトの数が増えてくるとExternal Tableへのクエリのレスポンスが悪化しました。そこで、定期的にNative Tableへ取り込むバッチを後段に追加し、集計・分析時はそのNative Tableを参照することで、データ量に対してクエリのレスポンスがスケールするようにしました。
運用実績
ここまでの構成で現在まで運用しており、1日あたりの11億レコード・920GiBのログを処理しており、ピークの時間帯においては秒間で21000アクセスを処理しています。また、ログ欠損によりログを集約できなかった期間は1度も発生せずに運用できています。
リアーキテクチャ
Google Cloudで日々リリースされる新しい機能を利用した構成改善を検討しており、開発中のものですがその一部をご紹介します。
Cloud Loggingでログを収集してからBigQueryのNative Tableへ集約するまでのパスをできるだけ簡素にする方法を検討し、その中でもCloud LoggingのLog Analyticsを利用する方針で進めています。
また、速報版と確定版を使い分ける構成としてLambda Architectureを採用する予定です。
結論
TVerTagによってTVerにおける集計・分析に必要なログを統合的に収集・集約することができるようになりました。
おわりに
今回登壇にあたってはGoogle様のご担当の皆様に多方面でサポートいただきました。
スムーズに準備および登壇に臨むことができました。この場をお借りして御礼申し上げます。
