ミクシィXFLAGスタジオの生島 光氏

　AWSの年次カンファレンス「AWS Summit Tokyo 2018」において、ミクシィXFLAGスタジオでモンスト事業本部解析グループの生島 光氏は「2014年当時はサーバで発生したログを『Amazon Simple Storage Service』（Amazon S3）に保存し、そのログを使って分析をしていました。必要に応じてアドホックな分析もできるよう、『Apache Hadoop』のマネージドサービスである『Amazon Elastic MapReduce』（Amazon EMR）をスポットインスタンスとして用意していましたが、それだけでは補えない課題も幾つか抱えていました」と当時を振り返る。

　課題は運用面、データ活用面の双方に及んでいた。運用面では、Amazon EMRの起動やデータウェアハウス構築環境「Apache Hive」（Hadoopで動作するMapReduceアプリケーション）の処理に時間がかかっていたことが挙げられる。アドホックな分析のたびにAmazon EMRを起動していたが、その都度メタ情報を再構築していたため起動に30分ほど要していた。そこでApache Hiveのメタストア（テーブルやロールなどのメタデータ）を「Amazon Relational Database Service」（Amazon RDS）に格納して永続化し、Amazon EMR起動時にはこれを読み込むだけの仕様に変更したところ、5分程度でAmazon EMRが起動するようになった。他にも、日次処理に利用していたApache Hiveの処理速度にも問題があった。日次処理に15時間ほどかかっており、終業時にバッチ処理をスタートしても翌昼まで処理が終わらない状況だったという。

　そこで生島氏は、次のような方法で解決を図った。全てのデータをORC（注1）に変換し、新たに追加されるデータもORCに変換する処理をバッチに追加。「Apache TEZ」を実行エンジンとするなど定番のチューニングも施し、Dynamic Partition機能でデータを分割することで、処理時にスキャンするデータ量も削減した。直列実行ではリソースを使い切れていなかったので、自社開発したジョブフローツールでタスク依存関係に沿ってバッチ処理の順序を最適化し、並列処理ができるものは並列処理するようにしたという。「日次バッチ処理の高速化は、幾つもの技術を複合的に使い実現しました」（生島氏）

※注1　ORC（Optimized Row Columnar）ファイル。Hiveに最適化されたカラム志向型のデータフォーマット。

　こうした進化を経て現在は、AWSサーバプラン「m4.2xlarge」20台で構成したAmazon EMRと、3台の「ds2.8xlarge」、データウェアハウスサービス「Amazon RedShift」を利用して24TBのストレージでログ管理基盤を構成している。Amazon EMRはマスターインスタンスグループもコアインスタンスグループも、スポットインスタンスとして用意し、必要なときのみ起動する仕様だ。2014年から2015年にかけて、これらの基盤を整備した結果、日次バッチ処理にかかる時間は15時間から9時間まで短縮されたそうだ。終業時にスタートすれば、翌朝の業務開始までに終わる時間に収まったわけだ。

データ利活用のハードルを下げるために重ねた工夫

　データ活用面における最初の課題は、ログ分析の手段を持つ人間がエンジニアに限られていたことだ。理由は単純で、Amazon S3に蓄積したログにアクセスするため、SSH で接続する必要があったのだ。コマンドラインインタフェース（CLI）を使いこなせるエンジニアにしかログ分析の手段がなく、ゲーム運営の現場でデータ活用することは難しかった。これを解決するために、同社は幾つかのビジネスインテリジェンス（BI）ツールを導入した。

　「BIツールは目的に応じて市販製品を数種類、使い分けています。いずれも公式のDockerイメージを使ってAWSで利用しています。障害が発生しても自動的に再起動してくれるので、運用に手間がかからないのがポイントです。市販製品だけではカバーできない独自の分析については、内製ツールも併用しています」（生島氏）

　こうしたアクセス経路の整備により、データを分析して活用する道は開けたものの、手軽ではなかった点が課題として残っていた。取り扱っているのがサーバから書き出された生ログデータなので、目的に合わせて分析するためには複雑なクエリを記述しなければならなかったのだ。

　「例えば『ゲームプレイヤーがオンラインでマルチプレイをしたかどうかを知りたい』というだけでも、数十行のクエリを書かなければなりませんでした。しかもそのためには、アプリ開発者視点で作られたログテーブルの意味を理解しなければなりません」（生島氏）

　これを解決するために、生島氏のチームは分析用のテーブルを新たに用意した。頻繁に検索されるデータを、現場目線でも分かりやすいテーブル名で提供することで、データ活用のハードルを下げたのだ。先述のマルチプレイの例で言えば、「is_multi」という分かりやすい名前のカラムが追加され、簡単なクエリでマルチプレイを楽しんだプレイヤーのデータを抽出できるようにした。「アプリ開発者ではなくデータ分析者の視点に立ったテーブル整備には、『Dimension Modeling』という考え方が役立った」と生島氏は言う。

分析しやすいようDimension Modelingという手法でデータを再設計《クリックで拡大》

　「Dimension Modelingは、理解しやすさを重視したデータモデル化の手法です。システムの言葉を、サービスに即した言葉に置き換えていきます。アプリが書き出したファクトに対して、さまざまな切り口（Dimension）を持たせたテーブルを用意して分析スピードを向上させます」（生島氏）

　データ利用のハードルが下がったことで、生島氏が所属するデータ分析チーム以外のメンバーにもデータ活用が広まっていった。そこで新たな課題として浮上したのが、データの信頼性をどのように担保するかということだ。データ分析チームのメンバーやアプリ開発に携わるエンジニアであれば、異常なデータの「違和感」を経験から察知できる。しかしデータ活用が広まれば広まるほど、利用者のITリテラシーは幅広くなり、データを盲信するユーザーも多くなる。誤ったデータに基づいた分析にならないよう、データの信頼性にはこれまで以上に気を配る必要があった。

　「そもそもの前提として、データは壊れるものです。変換処理、通信エラー、バックアップのためのコピーなどの原因によって、データは壊れます。事前のテストで防ぐこともできません。代わりに、データが壊れていないかどうか判別できる仕組みを組み込みました」（生島氏）

現在のログ管理基盤構成《クリックで拡大》

　具体的にはバッチ処理の後半で、データ品質チェックを実行しているという。異なるデータソースでの比較、変換前後の比較、意図しないNULLカラムの検出などによって、データが壊れていないかどうかチェックしている。こうした施策によりエンジニア以外のメンバーも手軽に、しかも安心してデータを分析、活用できるようになった。現在ではデータ分析専任チームの5人に加えて、各サービス担当者約200人がデータにアクセスしている。