クラスターのデータ活用の歴史

こんにちは!2022年4月からクラスター株式会社でデータアナリストをしているyukiです。
データ分析を専任で担当するメンバーの1人目として、日々奮闘中です。

今回はclusterで日々蓄積されているデータについて、リリースから現在までどのように活用されてきたのかを振り返りつつ、これからどう活用していきたいかをお話します。
私の入社以前の内容については、クラスター社を長年支えているエンジニアさんに伺った内容となります。

ちなみに、クラスター社の創業は2015年7月7日で、clusterの正式版リリースは2016年5月31日です。
クラスター社としてはcluster正式版リリース以前にも様々な歴史がありまして、α版を公開したり、まったく別のサービスを制作していたりします。
クラスター社の歴史に興味がある方はtsukasaさんのnoteも併せてご覧ください。

cluster正式版リリース当初

先述の通り、clusterの正式版リリースは2016年5月31日です。
リリース当初のclusterは常設のワールド機能が存在せず、バーチャルイベントを行うためのサービスだったということもあり、頻繁にデータを用いた意思決定を行っていたわけではありませんでした。
確認していたデータは登録ユーザー数やアクティブユーザー数といった簡単なものに限られており、データ集計作業もサービスの本番環境で用いているMySQLに直接接続して行っていました。
当時は週に1,2回程度しかイベントが開催されていなかったため、負荷的な影響もなく、必要十分だったようです。

Redash

cluster正式版リリースから1年後の2017年7月にRedashが導入されました。
導入目的としては、今後サービスが大きくなった際に確認したいデータが増えるだろうという目論見がありつつも、エンジニアがサービスの調査を行いやすくするためという意味合いが大きかったようです。
ちなみに、Redashに保存されている第1号のクエリを確認してみると、登録ユーザー数をカウントするだけのシンプルなselect文が残されていました。

Redash導入の目的は調査用としての意味合いが大きかったとはいえ、MySQLに直接接続しなくてよくなったために様々なダッシュボードが生まれ始めます。
clusterにも新機能としてアバターのアップロードやギフティング機能など様々な機能が追加されましたが、その都度、利用状況を確認していました。
個々の機能だけでなく、サービス全体の指標としてKPIの検討も始まりましたが、ユーザー数や利用時間を確認する程度にとどまっていたようです。

BigQuery

その後、clusterの大規模アップデートとして、2020年3月5日にスマホアプリ対応とワールド機能が同時にリリースされることが決まります。
そのタイミングでユーザーが大幅に増えるだろうという見込みのもと、大量のデータを用いて分析する環境を整えるためにBigQueryが導入されました。

BigQueryのデータ構成としては、Digdagを用いてMySQLのテーブルをそのまま1日1回BigQueryに流す方法をとっています。
Digdagのログを確認すると、初稼働が2020/03/16だったようです。

このBigQuery導入により、データ分析の機運が劇的に高まるかと思いきや、これまでと大きな変化はなかったようです。
というのも、

  • MySQLの構成をそのままBigQueryに保持しているため、データ構造に熟知しているエンジニアがSQLを書く必要がある
  • 1日1回の同期であるためリアルタイム性が求められる集計には活用できない

という点がネックとなっていました。
というわけで、より頻繁・詳細な分析を行うというよりは、Redashのダッシュボードが徐々に増えていくにとどまりました。

Looker

BigQueryの導入後、データ活用が劇的に進んだわけではないものの、データ集計の効率は上がり、徐々にRedashのダッシュボードが増えていきました。
また、そのタイミングで2021年1月に倉井さんがjoinされたことをきっかけに、これまでより頻繁にデータを分析していく流れが生まれました。

しかし、BIツールとしてRedashを用いたデータ活用を進めていくなかで、課題がいくつか明らかになってきました。
具体的には

  • 似たようなクエリが量産されているため、どのクエリが正しい値を集計できる生きたクエリなのか、それともメンテされていないまま放置されている死んだクエリなのかわからない
  • 同じようなクエリでも、クエリを書いた人やタイミングにより細かい条件が異なってしまい、若干数値がずれている
  • (以前からの課題ではあるが)データ構造を熟知したエンジニアでないと正しいクエリが作れない

といったものです。
これらの課題を解決するために、Lookerの導入を進めていくことになります。

私がクラスター社にjoinしたのはちょうどこの頃で、PoCを経てLooker導入を決めたタイミングでした。現在では、私を含めた2名がAnalyticsチームとして、Lookerを用いて、データ定義の整理やダッシュボードの整理を行いながら、アドホックなデータ集計・分析を行っています。

今後やりたいこと

Lookerは現在も継続して開発中で、データの定義を整備することや、主要なダッシュボードの移行を行っている最中です。
まだまだ整備が追いついていない部分がありますが、社内での利用を着実に広めており、当初の課題が解決していっています。
しかし、課題は他にも見えてきています。

  • BigQueryへのデータexportにかかる処理時間が伸び、近い将来に破綻してしまう
  • BigQuery(とそのデータ元である本番環境のMySQL)にあるデータ以外にも様々なデータが蓄積されているが、それらを分析に活かしきれていない

上記の課題を解決すべく、MySQLをそのままBigqueryにexportするだけではなく、新規でデータ収集基盤を内製することを検討しています。
これからもクラスター社全体が、欲しいデータにアクセスでき、データから正しい意思決定とアクションに繋げることができる環境作りを進めていきます。

採用募集中

クラスターでは様々な業種について、絶賛採用募集中です。
興味のある方は是非エントリーをお願いいたします。