「マルチクラウド」な、Aimingのインフラ環境

芝尾　私は、Aimingで主にデータ分析の基盤作成と、実際のデータ分析を担当しています。

前職のドワンゴにいるときに、趣味でニコニコ動画のランキングサイトを作っていまして。それが当時のCTOに見つかり、「数字が好きそうだからデータ分析やってみてよ」と（笑）。そこからデータ分析を始め、今に至ります。

野下　私は2013年にAimingにジョインし、今は日本とフィリピンのメンバーで構成される、インフラチームのマネージャーをしています。

弊社のインフラは、複数のクラウドサービスを組み合わせて使う「マルチクラウド」で構築しています。「どのクラウドを使うのか」という選択や、構築の自動化、運用のバックアップといった基本的な仕組み作りを日本で行い、落ち着いてきたらフィリピンの子会社に渡しています。

マルチクラウド化というと、「ひとつのツールで全てのクラウドを操作できるか」という点に目が行きがちだと思うんです。ですがそれを考えていると、ゲームのスピード感についていけなくなります。

なので弊社では、たとえ手動で構築することになっても、「何をやりたいのか」や「何を使いたいのか」を優先して、複数の環境をガンガン取り入れていますね。

「ゲームの特性」と「クラウドの特性」を見極めて選定

野下　ゲームは大きく分けると、リアルタイム性の高いものと、HTTPプロトコルを使ったソーシャルゲームの2つがあります。

リアルタイム性の高いゲームは、より高いスペックを必要とすることが多いため、データベース部分だけ物理サーバーを使ったりします。国内のクラウドサービスの中には、物理サーバーを利用できるクラウドサービスがあるので、そういったサービスを活用しています。

逆に、HTTPだけのシンプルなゲームだと、単純にサーバー台数を増やしていくだけなので、拡張しやすいAmazon Web Services（AWS）や、Google Cloud Platform（GCP）を使うことが多いです。

クラウドサービスを選定するときには、必ずベンチマークを取ります。そうすると、やはりクラウドごとに傾向のようなものが出てきます。例えばディスクのI/Oが出たり、新しい世代のCPUが入っているため、CPUの性能が高かったり。

ゲームによって、ディスクI/Oが多かったり、ひたすらCPUが必要だったりと特性があります。その特性を元に、コストや提供されている機能のバランスを見て、タイトルごとにチョイスします。

新しいクラウドは、まず海外や社内環境で実験的に活用

野下　新しいクラウドサービスを使うときは、まずはWebサイトであったり、社内ツール周りをそのクラウドで動かしてみています。

また、海外でもサービス・ゲームを展開しているので、まずは海外で試してみるというのもありますね。試してみていけそうなら、日本のタイトルでも使ってみたり、段階的に使うようにしています。

GCPは、日本リージョンは発表されているけれどまだ使えない状態（※2016年8月現在）なので、今は海外だけで使っている状態ですね。リアルタイム性の高いゲームだと特に、遠いリージョンにあるとレイテンシが問題になる可能性があるので、日本のサービスでは利用していません。

ですが、例えばGoogle BigQueryのように、サービス単体では素晴らしいものがあるので、ユーザーに直接影響のないところでは、どんどん使っています。

Aimingを支えるKPIツール「Monolith」とは！？

芝尾　私のいるデータ分析チームで開発している、データ分析基盤「Monolith」は、バックエンドにBigQueryを使っています。

今までのゲーム業界って、CDやDVDにマスタデータを焼くまでが仕事で、データ分析が活発じゃなかったんですね。それがソーシャルゲームの時代になると、ユーザーがどこに面白さを感じているかを統計的に理解して、改善していこうと、各社が分析基盤を作るようになったんです。

弊社の「Monolith」は、課金額やアクティブユーザー数といったKPIを、タイトル横断で見られるようなツールです。管理画面から登録したSQLを実行して、結果をタイトルごとにグラフにして表示してくれます。

▼タイトル横断でKPIが見られる

Monolithの仕組みを実現したのは、BigQueryの「速さ」

芝尾　以前は、MySQLや別のデータウェアハウスを使っていたのですが、次第に集計時間が問題になってきたんです。数十億件のレコードを対象にすると、集計に数分かかるようになってしまって。分析をするときはいろいろな切り口で何度もクエリを叩くので、待ち時間が多くなってしまうんです。

そこでBigQueryに移行したのですが、その理由は大きく3つほどあります。まず、データを蓄積するだけなら相当安いということですね。

次にデータ容量の制限です。以前使っていたデータウェアハウスでは、最大レコード数が1プロジェクト500億件という制限がありました。弊社の一番人気があるタイトル「剣と魔法のログレス」では、1日2億レコードを超えるので、1年分のデータも入らないんです。BigQueryであれば、そういった容量の制限もありません。

そして最後に、一番大きかったのがレスポンスタイムですね。数億件のデータを集計しても2、3秒で返ってくるんです。これなら、誰でもSQLを書いて、集計してというのが待ち時間なくできるなと思いました。

KPI可視化のツールには、バッチ処理で数時間に1回集計して、それを中間テーブルに保存して表示するものも多いです。ですが、それではリアルタイムの数値ではないし、何か間違いがあって再集計するのにも時間がかかります。

Monolithは、中間テーブルを持たなくても使える、シンプルな仕組みになっています。SQLだけ持っていて、それを発行して、グラフ化して返す。BigQueryが数秒で結果を出してくれるおかげで、実現できているんです。

社内ツールであっても「ユーザーテスト」を実施！？その理由は…

芝尾　基盤はある程度作ったので、次はデータ分析をする文化を浸透させるというのに軸足を移しているところです。実はMonolith自体のKPIも取っていまして（笑）。いまだと、アクティブユーザーが100人くらいですね。

というのも、実は弊社では、Monolithのようなデータ分析ツールを何度も作ろうとしていて、これが3代目なんです。以前はMongoDBを自前で構築して、保守が面倒になって使われなくなったこともあり…。

Monolithは使ってもらえるために、UIにもとても気を使っています。社内ツールなのにユーザビリティテストをしているんですよ（笑）。あまり使っていなさそうな人に、「何月何日の数値を見てください」という課題を出して、操作している様子をすべて録画して。それを何度も繰り返して、改善しています。

また、非エンジニアの人でも使えるように、社内向けにSQL入門の勉強会も開催しています。WHERE文からGROUP BY文まで、ステップ・バイ・ステップで、実データを使って学習しています。

社内ツールって、「作っても使われない」という問題がどうしても出てくるんです。私はエンジニア出身なので、「作って終わり」の発想になりがちなのですが、Monolithは「どうしたらみんなに使ってもらえるか」を考えるのが大変でしたね。

今後も「主体的に」、技術を追求していく

芝尾　弊社には主体的に動ける人が集まっているので、どうやったらMonolithの社内認知度を高められるか、ということも考えていけるエンジニアが多いですね。認知度を上げるために、マスコットキャラクターを作るコンテストも実施しました（笑）。

▼Monolithマスコットキャラクターのコンテスト

野下　GCPを最初に導入したときも、たぶん1ヶ月もかからないで移行ができたんです。これが他の会社だと、「何で移行するの？」という話になって進まないと思うんですよね。下の声を潰さないという文化を大事にしているのが、弊社の良いところかなと思います。

今後は、最近の新しいコンテナ技術だったり、Amazon Auroraのような技術にも手を出していきたいなと思っています。新しい技術に対してのスピード感は上げていきながら、既存のインフラの精度も追求していけたらなと思っています。（了）