こんにちは、株式会社mikanでデータ分析を担当している @ij_spitz です。

データ分析チームのブログも2本目になりますが、今回は前回の記事で少しだけ頭出しをしていたデータ分析基盤の歴史について書いていきます。

英単語アプリmikanは2014年10月にリリースされたプロダクトでデータ分析基盤も年月を経て変わってきました。

その頃と比べると現在はAWSやGCPで分析系のサービスが充実しており、知見も豊富になってきているので、現行の基盤以外は正直参考になりません。また自分たちでもそんなことをしてたのかと疑いたくなるような運用をしていたので、ツッコミを入れつつ、温かい目で見ていただけると幸いです。笑

第1世代: Redshift（2014年末 ~ 2019年始め）

mikanの初期の分析基盤はRedshiftをメインに置いたものでした。

この頃僕は特にmikanに関わっていたわけではないのですが、2014年末くらいからRedshiftを運用していたという話を聞き、他の企業に比べても早くデータ分析基盤を用意していていたんだなと感じました。

調べたところ、Redshiftが正式にリリースされたのが2013年2月、東京リージョンでリリースされたのが2013年6月だったようです。

ログを収集する部分はFlyDataというサービスを使っていました。この頃はKinesis Data Firehoseのようなマネージドのログ収集サービスがなかったので、各社自前でFluentdを立てたり、試行錯誤していた時代だと思います。

FlyDataは導入のサポートが手厚く、mikanが知見のない中で素早くデータ分析基盤を作ることができたのはFlyDataの功績が大きいです（その節はありがとうございました🙏）。

Redshiftをメインに置いていても、ビジュアライゼーションはどうするかなどの詳細の部分は時期によって変わっているので、時系列に沿って順に紹介してきます。

Redshift → Python CGI → HTML

Redshiftを導入した初期はHTMLでデータを描画していました。弊社の代表が過去の画像を探し出してきてくれましたが、CSSは無く、HTMLっぽさは一切ありません...

ただしこの方法だと

などのデメリットがあり、今考えるととても良い方法には思えません。笑

独自でビューを作っているのでカスタマイズ性はありますが、そこまで複雑な指標を追っていたり、特別な使い方をしたいというわけではなかったので無駄にコストだけ掛かっていました。

Redshift → Python Batch → Spreadsheet

Redshiftを運用し始めてから少し時が経ってからはHTMLを辞めて、Spreadsheetに書き込む運用になりました。HTML時代よりはだいぶマシになりましたが依然として

などのデメリットがありました。

Redshift → Redash

mikanでは2017年の始めくらいから現在もデータのビジュアライゼーションにRedashを使っています。僕が副業としてmikanに関わり始めたのもこの頃で、界隈でもRedashなどのBIツールが使われ出した時期だと思います。

Redashを導入することによって、プログラムを書く必要がなくなり、圧倒的にデータへのアクセスが容易になりました。

またこの頃にRDB上のデータとログをJOINして分析したいなどのニーズも出てきたので、Data Pipelineを使用してPostgresql上のデータをRedshiftに持っていくなどの仕組みも構築していきました。

第2世代: Athena（2019年始め ~ ）

Redashを使うようになってから、ある程度データへのアクセスは容易になりましたが、まだまだ課題はありました。以下がその一例です。

クエリが遅い
- Redshiftのスキーマが列志向ではなく、RDBのようにJOINを前提とする形になっている（1つのユーザーのアクションログがactionsテーブルとparametersテーブルに分かれて保存されており、パラメータを取り出すには2つのテーブルをJOINする必要がある...）
Redshiftの運用コストが掛かる
- 容量を空けるためにログをローテートする必要がある
価格が高い

そんな中で2018年末に、ログの収集に使用していたFlyDataのサービス終了が決まり、Athenaをメインに据えた現状の構成に移行することを決めました。