組み込みアナリティクスを低コストで作りたい
Yusuke Kawabataドクセルはじめ、自分で運営するサービスに組み込みのアナリティクスを提供したいと考えている。個人的にはアーキテクチャのコスパを考えてしまうので、アナリティクスはいままで取り組んできたことがなかったのだ。いつも顧客のGAを設置できる、あるいはマルチテナント製品なら任意のJavaScript製品を張ることができるようにしている。
Yusuke Kawabataしかし、非エンジニア向け製品、あるいは部署導入の製品を運営していると以下のような声がよく届く
- 複数のSaaSを組み合わせずに完結してほしい
- Analyticsのタグの張り方がわからない
- 全社導入のAnalytics製品は簡単に発行してもらえない
- そんなに高機能なものはなくていい
こんな感じである。とくにGoogle AnalyticsがGA4に切り替わったあたりから「自分で設計しないとダメになって扱えない」という声を聴くようになった。BQみたいな高機能製品との統合が進んだ結果、直帰率みたいなわかりやすい指標がデフォルトだと簡単に扱えず、それなりに習熟しないと扱えないのだ。
というか、ぶっちゃけそこまでのものは求めていないケースが多い。大半の人にとっては、PV,UUがコンテンツ別であれば事足りるのだ。たとえばよく見られている年代がわかったところで、運用に生かしたり広告の配分を変えたりするだろうか？ほとんどの場合はその調整をするまでにもっとやることが山ほどあるはずだ。
そういった、9割の人のためのアクセス解析ツールを作りたいと思う。
Yusuke Kawabataひとまず、アクセス解析の知識が全くないので、有名どころのOSSプロダクトをのぞいてみることにした。
実装はいろいろあるが、どれもGAのリプレースを主眼としており、ファーストパーティデータ、プライバシーフレンドリーをうたっている。またCookie freeをうたっているものもありどうしているのかみてみたが、単純にIPアドレスとUser Agent、年月日などからハッシュ値をだしてユニークユーザの定義としているものが多いように見えた。
Yusuke Kawabata次にアーキテクチャを見るとサーバ側の言語はともかく、DBはMySQL、PostgreSQL、ClickHouseあたりがおおかった。とくにClickHouseは最近注目されていて、アクセス解析のためのDBともいえるようだ。
ここでコスパの話に戻るが、Google Analyticsの功罪により、ほとんどのユーザにとってアクセス解析単体にお金を払う文化はまだ少ないように思う。いっぽうで、設計に気を付けないと一瞬でクラウド破産してしまうのがこの辺の製品だと思っている。
たとえば、ドクセルだと1日15万イベントくらいが発生しているのだが、単純にこのイベント量を受けるとなると安定したインフラ環境が必要だ。大目に見て月間500万のリクエストをとりこぼすことなく、毎月蓄積し、取り出さなければならない。
まずデータの保管だが、ペイロードを256バイトとすると、
5000000*256/1000/1000/1000=1.28GiB、12か月で15GiBくらいだ。意外と大したことないな。
HA構成で組むと1GBあたり50円くらいなので、750円
それよりもクエリが大変なのでHA構成で7GBメモリ、4vCPUくらいで組むと7-8万円くらいだろうか。マネージドDBだとこれくらいのコスト感になる。
となると自前でVPSなどに組んでしまうのがこの円安のご時世なのでいいのかもしれない。マネージドにどっぷりつかってしまったので、いまさらOSやミドルウェアのメンテはやりたいくないが、がんばろう。
Yusuke Kawabataあと一応候補として残しておくべきは、自前でGCPで組んでBigQueryで取り出す感じだな。StackDriver？にLogAnalyticsもあらたに登場したので、候補としては残しておきたいが、いかんせんアナリティクス製品のアーキテクチャ設計の勘所がないので、まずは世にあるOSS製品ベースで1年くらい知見をためてみたい。前年同期比とかいろんなニーズ出るかもしれないし、お財布と相談してGA4みたいに14か月データを保持する気持ちでやってみよう。
Yusuke Kawabataumamiを動かしてみたのだが、おおむね良いのだがちょっとだけ痒いところに手が届かない。個人的にできれば直接呼び出すのではなくてキュー経由で使いたく、UserAgentがパラメータで渡せないことと、冪等性を担保するためのメッセージIDを記録する部分が欲しいなと思った
Yusuke Kawabata次にPlausibleのコードを読んでみる。うわーElixirかぁ～と思いながらもじっくり見てみる。DB構成としてはPostgressとClickHouse。ClickHouse強いな。しかし知見がないミドルウエアを本番投入するのは怖いのでumami、MySQLベースで考えるか～
Yusuke Kawabataそもそもどのプロダクトも、「ひたすら生ログを追記していく」方式なのは少し気になった。すぐにパフォーマンス劣化しそうなのに。ぱっと思いつくのは、時間別、日別に集計した結果だけ保存しとけばいいじゃん！！という感じだが、それだとだめなことで後で気づく。
単純にメトリクスやディメンションの組み合わせに対応するためには、ほぼ生に近いログを集計するしかないのだ。
- 1時間毎のPV×path
- 日毎のブラウザ×OS×スクリーンサイズ
- 1時間毎のコンバージョンイベント(複数)/UUでCVR算出
みたいなことを考えると、結局へたすると生ログより行数が増えちゃうんですよね。となると集計クエリに強いClickHoseが導入されるのは確かにわかる。
Yusuke Kawabataあと上で書いたBQはどうなのかという話だけど、レスポンスの即時性という意味でもClickhouseのほうがアクセス解析向きのようだ。
Yusuke Kawabataというわけで、さんざん悩んだ結果だけど、
- umamiを使うか、参考に自前で作りつつ、キューの仕組みを追加
- 最初はMySQLで、顧客に提供する限定的なメトリクスのみバッチで事前集計
- 同様にバッチで1時間ごとの生ログをエクスポート、ClickHouseに取り込んで遊ぶ
こんな感じがよさそう～
Yusuke Kawabata「バッチだったらBigQueryでよくね？」といわれてたしかに～となったので、BigQueryで構築することにしました。別でスクラップ立てます。