データ可視化推進室の深尾です。
delyではkurashiruリリース当初からデータ分析を重要視してきました。でも初めから使い勝手の良い分析基盤があった訳ではなく、これまでに何度も改良し今は４世代目となる分析基盤を中心に利用しています。今日はその分析基盤のお話です。まずこれまでの歴史から振り返ってみたいと思います。
クラシル分析基盤の歴史
第１世代：Google Analytics
クラシルのリリース初期から導入していたのはGoogle Analyticsです。これは皆さんも使っていることが多いんじゃないかと思います。基本的には無料でログ収集・分析・可視化まですべてやってくれるので導入コストが低く便利です。
その一方でカスタマイズ性は低く、例えば独自の指標を取得してSQLで分析することは無料ではできません（有料サービスを使えばBigQueryにエクスポート可能）。また当初から、いずれA/Bテストを実施することは計画されていたので、そのための分析機能も必要でしたが、Google Analyticsはできることが限られます。そこでカスタムメトリクスを収集してSQLを実行するための第２世代の独自分析基盤を構築しました。
第２世代：fluentd + BigQuery + Redash
モバイルアプリから行動ログを送り、それをfluentdで収集してBigQueryやS3に送ります（僕が入社して初めに取り組んだのがこれでした）。可視化にはRedashを使っています。この基盤は現在でもレガシー基盤として使い続けていますが、fluentdの運用コストがかかることや複雑なSQLを書ける人が限られてしまうことから、より使いやすい分析基盤を模索しており、そこで目をつけたのがFirebase Analyticsでした。
第３世代：Firebase Analytics
ログの収集はFirebaseがやってくれますし、BigQueryにエクスポートする機能もついているので、第２世代の利点を活かしたまま、既存の課題も改善できる予定でした。ところが実際に使って問題となったのはカスタムで設定できるパラメータ数に上限があることでした。つまり独自の指標を分析するのにいずれ限界がくる可能性があります。またBigQueryにエクスポートした時にデータが特定のカラムに偏っており、クエリのスキャンコストが従前より高くなる懸念もあったため、第４世代のデータレイクへ切り替えることになりました。
第４世代：
Kinesis + Athena + Redshift
+ Metabase + 社内製ダッシュボード
これが現在使っているデータ分析基盤です。構成図には載っていませんがログ収集基盤にはAmazon Kinesis Data FirehoseやAWS Glueを使っています。Sunnyと書いてあるのはSPAで作った社内製ダッシュボードです。
ログ収集基盤・データ集計基盤・ダッシュボードのそれぞれをリプレースしています。社内の人的リソースを確保できたことも背景にありますが、独自ダッシュボードを開発するに至った具体的な理由があります。
独自ダッシュボードの開発に至る経緯
構成図にもあるようにRedashに加えてMetabaseというオープンソースのダッシュボードも導入しています。当初はこのMetabaseだけを新ダッシュボードとして使う予定でした。
Redash & Metabase
Redashに対するMetabaseの利点は、動的にクエリを実行しやすいことが１つあるかと思います。例えばダッシュボードに２つの日付を入れるところがあって、O月O日からX月X日までのグラフを表示するといった使い方ができます。そしてRedshiftにデータマート（サマリーテーブル）を構築しておけば、簡単なSELECT文でデータを集計できるので、これまでより多くの人に使ってもらえるというのが開発前のぼくの考えでした。
しかし、実際にユーザーとなる各部署の社員にいろいろ話を聞いてみると、それまでの考えでは浅かったことに気がつきました。
クラシル用語で作られたダッシュボード
データ分析基盤のユーザーが求めていたものはクエリが簡単に書けるダッシュボードではなく、クラシルの用語で構成された画面でした。例えばYahooの社内で使われているダッシュボードだったら「ヤフオク」とか「Yahoo!ニュース」といったメニューがあってそれぞれのメトリクスを見ることができるそうです。
クラシルのダッシュボードなら「検索キーワード」や「再生数」「すべてのレシピ」といったメニューがあれば、SQLを使わないフードコーディネーターやクライアント担当者でもデータを利用できますし、これまでSQLを使ってきたマーケターやエンジニアが分析にかける時間コストを短縮することもできます。
分析基盤のアーキテクチャ
データ分析基盤では、サービスがスケールした時でも集計クエリにかかる時間や費用を抑えられることが求められると思います。そして短期間で開発しなければならない事情もあったので３ヶ月以下で構築する方法を考えました。この辺りはエンジニアのスキルセットとの相性や、事業・組織のフェーズも影響があると思うので、どんなアーキテクチャやフレームワークで構築するのが一番良いということはないと思います。ぼくの場合はRedshiftを2014年ごろから使っておりメリットとデメリットもわかっていたので、これをうまく使ったり、弊社のDevOpsでワークフローサーバとして使ってきたRUNDECKをここでも使ったりすることで全体の開発工数を抑えることができたと思います。ここで社内製ダッシュボード周りのアーキテクチャを紹介します。
（CoreUIのイメージ）
ダッシュボード
- CoreUI (Vue.js) 製
- Single Page Application
- Kubernetes上のNginxコンテナで静的ファイルを配布
- IP制限
- OAuth2でGoogle認証
WebAPI
- Express (Node.js)
- RESTful API
- RedshiftやElasticsearchに接続
- IP制限
集計バッチ
- Python製
- AthenaとRedshiftでSQLを実行
- クエリの結果を別のAthenaテーブルとして使うための独自フレームワークを実装（最近CTAS機能ができましたね^^）
- RUNDECKサーバでスケジュール実行＋ワークフロー管理
DWH
- Amazon Athena + Redshift
- Redshift SpectrumでAthenaのテーブルにアクセス
- AWS Data Migration ServiceによりAuroraのDBと同期
インフラ、CI/CD
- Kubernetes on EC2
- AWS CodeBuild
今後のロードマップ
- 画面追加
- ワークフローのコード化
- ユーザーごとの権限管理
こんな感じでいろいろあるんですが、もし新しい人に入ってもらえたら自分がやりたいところをやってもらったら良いんじゃないかなと個人的には思っています。データ可視化の面白いところは、SPA、UI/UXデザイン、集計バッチやワークフロー管理、Kubernetesなどを広く触れることがあると思います。もし興味があればぜひ一度オフィスに遊びにきてください。
delyでは現在エンジニアを大大大募集中ですよ！
