Data Platform室の紹介
茂木高宏氏（以下、茂木）：本セッションに参加していただきありがとうございます。「Access analysis of Data Platform users」というタイトルで、Data Platform室 Data Infrastructureチームの茂木高宏が発表します。
アジェンダです。最初にData Platform室の簡単な紹介を行い、次にData Platformのユーザーアクセス解析の話をして、最後に設計と実装についてお話しします。
簡単にData Platform室を紹介します。ミッションは「世界各国のLINEの従業員にData Platform as a serviceを提供すること」です。実際に我々がやっていることは、データインフラの提供やBIツールを開発して提供しています。イメージとして、社内プロダクトの社内基盤だと思ってください。
具体的には、クラスタやストレージといったHadoopクラスタ、クエリや分析のための中間データ、データの取り込みパイプラインやセルフサービスなツール、Webシステムの開発を行っています。つまり、データに関係する業務を行うためのプロダクトや基盤全般を提供しています。
次に、リソースの規模感です。Hadoopやそれ以外も含めた規模感になっています。そうですね。ワークロードはDAY30万以上、テーブルは5万6千以上の非常に大規模なプラットフォームです。
アクセス解析の6つのKPI
次に、Data Platformの中のHadoopに限定して、世界各国で働いているLINEの従業員、つまり利用ユーザーのアクセス解析について話します。アクセス解析のKPIとして、6つの指標を定義して集計しています。左から順に紹介します。
DAUはDaily Active Userで、日ごとのユニークユーザーの規模感がわかります。MAUはMonthly Active Userで、月ごとのユニークユーザーの規模感がわかります。
DACはDaily Active User Action Countの略で、日ごとのユーザーの利用量、つまり日ごとにどれだけユーザーが利用しているか把握ができます。MACはMonthly Active User Action Countで、DACの月別です。RRはRetention Rateの略で、連続期間内のユーザー定着率です。つまり、ある期間内でユーザーがどれだけ継続的に利用しているか把握が可能です。
DRはDormant rateの略で、RRの反対。連続期間内のユーザー休眠率です。つまり、ある期間内でユーザーがどれだけ休眠したか、どれだけ利用していないか把握可能です。
次にこれらの指標をいくつか紹介します。全部は紹介できないので一部になります。
まずDAUを紹介します。左はある時点でのあるクラスタのYARNのDAUになります。現在は500を超える数値になっています。右はある時点での3つのPrestoクラスタのDAUになります。Prestoクラスタは用途に分けて最適化しているため3つあります。こちらは多いときは200近い数値になっており、合計すると300近い数値になります。
このDAUは直接データを利用しているユーザーのみで、BIツールとダッシュボードから利用しているユーザーはカウントしていないです。含めると数値はもっと大きいと思います。
次にDACを紹介します。左はある時点での、あるクラスタのYARNのDACになります。なお、DACの集計軸は、YARNのアプリケーションサブミット数で成功したアプリケーションに限定しています。つまり、多いときでDAY7万近いYARNのアプリケーションがサブミットされます。
右は、ある時点での3つのPrestoクラスタのDACになります。DAUでも話しましたが、Prestoクラスタは用途に分けて最適化しているため、3つあります。PrestoのDACの集計軸は、クエリ発行数で成功したクエリに限定しています。DAU、DACを紹介しましたが、日々世界各国のLINE従業員がアクセスして、活発的にデータの分析をしています。
数値の活用事例
次に、これらの数値をどのように活用しているのか、事例を1つ紹介します。
オンラインクラスタマイグレーションの社内インフラプロジェクトの例です。HadoopクラスタAとBをHadoopクラスタCにオンラインマイグレーションするプロジェクトがありました。右の円グラフですが、このときのコンセプト的な話で、先ほどのKPIでDAUを組み合わせてこのプロジェクトのゴールとなるKGI指標を新たに作成し、これをプロジェクトとしてトラッキングしています。
作成したKGI指標は、MR、Migration Rateの略で、連続期間内のユーザー移行率を示すものです。左の棒グラフは、HadoopクラスタCのMRのみ記載しています。このMRによって得られたインサイトは、当初KGIの数値の増加が緩やかで、マイグレーションの動線が弱い状況がわかりました。そこで、アクションとして利用者を集めワークショップを行ったところ、マイグレーションの進捗を向上するインサイトが得られました。
我々がここまでやっている理由は、利用者、つまりLINEの従業員が、世界各国から大規模に使うからです。ユーザーのスケジュールに合わせて、マイグレーションを流すためと、コミュニケーションコストを削減するために、ここまでやっています。ここまで紹介したDAUとのKPIは、細かくドリルダウンして参照できるようにしています。
スライドは集計軸を定義したセグメントツリーですが、具体的には、DAUであれば個人アカウントだったり、システムアカウント別に見ることができます。コンポーネントであれば、HiveやYARNごとに見れたり、さらにHiveであればReadクエリ、つまりSELECTクエリで、WriteクエリのINSERTクエリから、DDLクエリを発行したユーザーごとに見ることができます。
事例の設計と実装
次にこれらの設計と実装についてお話しします。まずどのログを利用したかですが、我々が管理しているエコシステムは、非常に多いです。またクラスタもいくつかありました。これらのエコシステム、クラスタから、全般的に汎用的に取れるため、Rangerのauditログを利用しています。
ただし、課題でもあるのですが、PrestoはRangerで管理できていないので、Prestoのクエリログを収集するプラグインを我々で自社開発し、そのクエリログを利用しています。
次に実装です。先ほどのRangerのauditログとPrestoクエリログを収集して、HDFSに保存します。保存したログはAirflowからHiveを利用して集計して、中間データをdailyで作成します。その中間データをBIツールからPrestoを利用して、dailyで可視化分析を行っています。
今後の展望
最後に今後の展望です。3つほどあります。1つ目はこの仕組みを応用して、各ユーザーがどれだけリソースを使ったのか、それをコストに変換してレポートする仕組みです。2つ目はKPIやセグメントを増やすことです。最後は現状はdailyの集計ですが、これをもっとリアルタイムに近い粒度で分析し、意図しない利用の検知などを考えています。
以上で発表を終わります。ご清聴ありがとうございました。
