この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、虎塚です。
昨日は、LINE株式会社さんが開催されたイベントLINE DEVELOPER DAY_2015 Tokyoへ参加してきました。
Taichi Hashimotoさんが講演された「B-5: ビッグデータを活用するための分析プラットフォーム 〜データ集計した先に求められる分析技術」を聴きましたので、レポートします。
前半は、さまざまOSSを活用して構築された、社内の利用者のニーズに応じたデータ分析基盤の紹介でした。後半は、KPIを人間が見るのでなく、変化を自動検知して通知するシステムを開発中というお話でした。
以下、レポートです。
データ分析について
LINEにとってデータ分析とは何か
- Collecting: データを集約する
- Reporting: サービスの状況を的確に報告する
- Analyzing: サービスの問題点や改善点を分析できるようになっている
この3つのことを実現するように技術や環境を提供している。
重要だと思うこと
- Collecting
- リーズナブルなデータの集約
- 大量のデータを保持すること
- Reporting
- 柔軟なデータの集計
- わかりやすいチャートでの可視化
- Analyzing
- 簡便で高速なデータの抽出
異なるニーズ
データの利用者によって、求めるものが異なる。
- エンジニアの声
- UIなんてどうでもいいから、生のデータを1箇所に集めて、自分たちがアクセスしやすいようにしたい。
- プランナーの声
- KPIを出してほしい。データはきれいなグラフで可視化されていることが望ましい。そしてExcelでダウンロードできることが非常に重要。
プランナーはエンジニアよりもデータの加工を要望することが多い。これらをふまえて、どういった分析環境が必要か？
for エンジニア
エンジニアに対しては、凝ったことをする必要はないと考えた。SQLなどのクエリを柔軟に発行できるようにする。（エンジニアが自由に実行する）APIによるバッチ処理と連携できるようにする。
次のようなツールを利用している。
- Fluentd: 柔軟なログ収集を可能にするフレームワーク
- Norikra: リアルタイム集計処理システム。ストリーミングデータ処理としてSQLが利用できる
- Shibu / Shibu UI: Webベースのクエリツールとジョブスケジュール。Hadoopに集約されたデータを扱う。
データをHadoopに集約して、クエリが叩けるインタフェースからアクセスしてもらう。リアルタイム処理にはNorikraを使っている。
For プランナー
可視化、ダウンロード、No SQL（SQLを書かなくてもなんとかできるようにする）がポイント。
次のようなツールを利用している。
- Hadoop: 大規模分散データ処理環境。構成は、HDFS, MapReduce, YARN
- Hive: 大規模データに対するDWH
- Presto: 分散データ処理エンジン。Hiveより高速処理できるのでBIツールのバックエンドに利用
- Prestogres: BIとPrestoをつなぐコネクタ
- InfiniDB: MySQLベースのカラム型分散DB。BIツールやクライアントツールから利用するデータを格納
- IBM Cognos: Webベースのレポートオーサリングツール。ランキング変動のヒープマップなど、複雑で手作業で作ると大変なグラフや表を、それなりのコストで作成できるので利用している。
- Pentaho: OLAP（Online Analytical Processing）型の多次元分析用システム
エンジニア用に集計したHadoopクラスタのデータを、さらにプランナー用に流し、Prestoを経由して確認できるようにした。
ソリューション
このように、冒頭で挙げた課題を解決している。
- Collecting
- リーズナブルなデータの集約 → fluentd
- 大量のデータを保持すること → Hadoop
- Reporting
- 柔軟なデータの集計 → Hive / Shibu / Norikra
- わかりやすいチャートでの可視化 → IBM Cognos, Pentaho
- Analyzing
- 簡便で高速なデータの抽出 → Presto, InfiniDB, Pentaho
重要視していること
上記のデータ分析基盤を構築、運用する上で、次の内容を重要視している。
- API連携できるようにすること
- OSSの採用。足りないものは自分たちで作ること
- データをなるべく隠蔽すること。認証をしっかりした上で、ユーザ情報を見せる
- ユーザトラッキングはしないこと。LINEのユーザは非常に多いため、1人のユーザをトラッキングしてもサービス改善に結びつかないと思っている。苦労が多いわりに利がないので、一切やっていない
分析プラットフォームの構成
グローバル化にともない、次のような課題が見えてきた。
- サービスの変化
- グローバル化、多様化に加えて、長寿化（サービスの延命）
- 人の変化
- プランナーの増加
上記の変化を受けて何が起きるかというと、KPIがサービス × メジャー × ディメンジョンで爆発的に増加する。
国別、カテゴリ別などはもちろん、サービス運用を続けるうちに歴史的背景によるフラグが存在したり、人が増えることでいろいろな要望が出たりすることで、KPIが増加する。
KPIが増えると、忙しくなり、だれもKPIをつぶさに見なくなる。そして、サービス運営として何をすればよいかが、だんだんわからなくなってくる。
KPIの変化を人ではなく機械がみる
上記の対策としてチームで考えたのは、KPIを人間が見ずに、KPIの変化を伝えること。たとえば、数十ヶ国 × 数万個のスタンプのKPIを人手で見ると大変なので、自動化して、KPIに特徴的な変化が起きた時に、プランナーやエンジニアに通達する仕組みをつくる。
KPIモニタリングシステムの開発
KPIモニタリングシステムを絶賛開発中で、もう少しで運用をはじめようとしている。
- すべてのKPIトレンド分析を自動化
- 時系列でトレンドを学習して予測値を算出
- 算出された値に対して、検出された値が異常かどうかをみる（ポジティブでもネガティブでも）
- メールやチャットでアラートを伝達する
プランナー用のシステムと別に、KPIのトレンド分析システムを設置する。これには、KafkaとSparkを利用する。各KPIを時系列に並べ、Kafkaで予測値を算出する。実値を見て、通達すべきかそうでないかを判定し、処理をおこなう。
- Timseries Producer: 次元ごとに分解してKafkaへ
- Timseries Monitor: トレンドを学習してモデルを構築し、Kafkaに保存
- Notification Monitor: 予測値よりも実値が大幅に異なる場合、通知する
まとめ
- データ分析環境はHadoopをベースにして構築
- OSSベースで、足りない部分や要望に合わない部分は自分たちで手をいれる
- 認証を入れる（だれがどんなクエリを投げたか、監査ログをとるなど、データを保守的に扱う）
- ユーザ情報（ユーザID）は重要でないのでなるべく隠蔽する
- KPIモニタリングを強化
- 増え続けるKPIを自動的に処理する仕組みをつくる
おわりに
「KPIの変化の通知を自動化する」という非常に興味深いお話でした。
システムのアクセス監視やパフォーマンス監視では、トレンド分析をするのですから、当然といえば当然の発想なのかもしれません。しかし、ビジネスのコアにかかわるロジックにも、それを適用するのがすごいですね。もちろん、発想を実装して実現されるLINEさんの開発者の方の技術力もすごいです。
「何を特徴的なデータと定義するか」が難しそうと想像しますが、そのあたりもLINEさんが得意とされている機械学習を活用して、早々に実現されるのかもしれません。いつか続きのお話をお聴きしたいなあと思いました。
それでは、また。
今回のイベントのその他のレポートは、こちらです。
2
