CodeIQ MAGAZINECodeIQ MAGAZINE

Google Cloud Platform、BigQueryを活用したKPI分析の環境作り─Aimingのインフラと共通基盤はこうして作られた

2016.11.02 Category:インタビュー Tag: , , , , ,

  • 56
  • このエントリーをはてなブックマークに追加

Aimingはゲーム開発・運営を支えるインフラや共通基盤作りにも力を入れている。
Googleのクラウド型データベースを活用して、社内の誰もがKPIを分析できる環境を作り上げているゲーム開発・運営を支えるインフラや共通基盤チームに話を聞いた。
by 馬場美由紀 (CodeIQ中の人)

これまで10分かかった分析がわずか10秒に。BigQueryを採用した理由

ソーシャルゲームや本格的なMMOPRGに限らず、オンラインでつながるゲームではユーザーの動向をデータで把握し、KPIを分析しながら、それをゲームの改善につなげていく業務が欠かせない。

Aimingでは、Google Cloud Platform(GCP)上で BigQueryを動かしながらデータ分析をしているということで、クラウド活用の先進例として紹介されることもある。

同社のインフラエンジニアマネージャー野下洋氏、リードソフトウェアエンジニアの芝尾幸一郎氏、堀井啓真氏の話を聞いた。

──そもそもAimingにおけるデータ分析の歴史とはどんな流れだったんですか。

芝尾:初期の頃のデータベースは、MongoDBを使っていました。ただデータ件数が数億件とかになると、もうMongoDBでは難しい。そこでトレジャーデータ社のクラウドで(ベースはHadoop)で分析することにしました。2013年春頃だったと思います。

解析基盤をHadoopにしたおかげで、数億件のデータを貯めたまま集計することができるようにはなりました。しかし、Hadoop上のデータを分析するために、SQLを使って検索できるHiveを使っていましたが、やはり時間がかかる。

一度、クエリーを送ると結果が出るまでに10分。その間にふっと気を失って寝ちゃいますよ(笑)。データ分析は何度も仮説・検証を繰り返していく作業ですから、瞬間的に返って来ないと分析が億劫になるんです。

そこでもっと速い環境はないものかと探しているとき、GoogleからGCP上で動くBigQueryというものがあると、CTOの小林に教えられ、さっそく試してみることにしました。2014年の秋ですね。

株式会社Aiming 開発グループ リードソフトウェアエンジニア 芝尾幸一郎氏
Aimingではデータ分析を担当。ゲームのログを収集するための基盤を開発し、データを分析して、各ゲームタイトルの開発・運営チームに提案している。かつてのドワンゴ時代は、iPhone向けのニコニコ動画アプリを開発。個人の趣味でニコニコ動画のランキングサイトを作っていたことがあり、データ分析の仕事を任されるようになる。それ以来、データ分析が専門になった。

野下:そもそもGCPが登場したのが、2013年12月ぐらい。最近はHadoopからのBigQueryへの移行事例はたくさん報告されているけれど、国内のゲーム会社ではAimingはかなり早いほうだと思います。

芝尾:使ってみてこれはすごいと思いました。Hadoopで10分かかっていたのが10秒でできちゃうんですから。2015年夏までにはHadoopにあったデータを全部BigQueryに入れ直し、Hadoopは捨てました。

作った努力よりも使われるための努力が大切──モノリスプロジェクトとは

──こうした解析基盤の選定も含めて、データ分析プロジェクト全体を「モノリス(Monolith)」プロジェクトと社内では呼んでいるんですよね。

芝尾:そうです。BigQueryからデータを引っ張ってきて、全てのタイトルを横断して、ゲームの売上やアクティブユーザー数、継続率などのKPIが見られるWebサイトを作ったんですが、それも「モノリス」と呼んでいます。

タイトル固有のクエスト進捗や人気アイテムなどを集計した個別KPIもここでわかります。1時間毎の推移、日別、週別、月別の推移をグラフ化することも可能です。

野下:ただ、トレジャーデータからの移行作業は結構大変でしたね。

株式会社Aiming 企画・開発グループ インフラエンジニアマネージャー 野下 洋氏
椎葉忠志Aiming CEOが以前に創業したONE-UPというゲーム開発会社で、自社開発ゲームを海外にライセンス・アウトする際の、インフラを含めたプロダクトマネージャーを経験。2013年にONE-UPからAimingに転職。現在はライセンス系、自社開発系に関わらず、ゲーム開発のためのインフラサーバーの構築・運用のマネージャーを担当。

芝尾:新しいものだから、その頃は事例がなかった。トレジャーデータに入っているデータは実はAWS上にある。それをまずS3にエクスポートし、さらにGCPにコピーしなくちゃならない。

アメリカのデータセンターにあるものをアジアのGCPに送る。大陸をまたぐから、すごい時間がかかる。少しずつ進めていくんだけれど、1日で50GBずつぐらいしかできなかったり……。

各タイトルから上がってくるJSONデータのフォーマットを、BigQueryに読ませようとすると、タイムゾーンの表記の仕方が違うので、それを手直す作業とか、結構泥臭い作業もありました。

BigQuery自体がフォーマット決め打ちみたいなところがあって、それにユーザー側が対応しなくてはならない。

しかし一旦、BigQueryに移行しちゃえばスピードが圧倒的に速い。なんでこんなに速いのか。普通は大規模分散コンピューティングといっても10~20CPUのところ、BigQueryは1かたまりのデータを一挙に5000台ぐらいのCPUに分散して計算している。

CPUがあり余っている会社の力技による解決方法。いかにもGoogleらしいと思いますね(笑)。

──BigQueryへの移行にあたっては、戸惑いはありませんでしたか。

芝尾:多少はあったけれど、こっちのほうが正しい道だという予感がありました。私は、すべてのデータベースは、レコードが1万~10万件レベルのときのMySQLのような振る舞いをすべきだと思っているんです。

MySQLは何かを集計するときにいちいち中間テーブルなど生成しないじゃないですか。結果も数秒で帰ってくる。データが数億件とかの大規模になってもそうあってほしい。

Hadoopは中間テーブルを使わないという意味では正しいんだけど、ものすごく時間がかかる。ところが、BigQueryは中間テーブルを生成しないし、なにより速い。正しい進化形はこちらだろうと。

社内に「誰もがデータ分析するのが当たり前」の文化を

──分析するにしても、特定の担当者だけしか扱えないとなると、会社全体として分析をする文化にはつながらない。誰もが気軽にデータ分析が行える仕組みが必要ですね。

芝尾:まさに、モノリスプロジェクトの目的はそこにあります。エンジニアやモノリスチームだけでなく、普段はSQLとかに縁のない運営や企画の人たちにも使ってほしい。

自分自身でデータを分析し、タイトルを改善して いく。そういう文化を社内に創りだすことが最も大切なことなんです。そのために、僕らはデータ抽出や集計のお手伝いをしたり、定期的にSQL講座やデータ分析の講座を開いたりしています。

社内の認知度を高めるために、モノリスのマスコットを決めようと、社内コンテストを開催したら、20通も応募がありました。

デザイナーだけじゃなくて、総務の人も応募してくれた。さらに「Monolith-Sun」という社内情報誌まで作っています。9月に創刊号をPDFで発行しましたが、これは月刊体制で続けていきたい。

野下:単に共通基盤を作っただけでなく、使ってもらう。そのためのプロモーションをやらないと使ってもらえないんです。

芝尾:モノリスプロジェクトでは、作った努力よりも使われるための努力が大切だと痛感しています。そもそもデータ分析は企画や運営の人にとってこそ興味があるもの。ところが彼らはSQLが書けないからエンジニアに依頼してくる。

でも、開発系のエンジニアって仕事が忙しいし、そういう依頼にいちいち応えるのは面倒だと思っちゃう。自分ももともとサーバー系エンジニアなんで、そのあたりの事情はよくわかるんです。

つまり、ニーズのある人とそれを実現する人が離れてしまうのはよくない。だからこそ、いまデータを分析したい人がその場ですぐに答えを得られるということが重要なんです。

売上集計、認証・課金系何でもOK──オベリスクとLINKプロジェクト

──もう一つ、社内プロジェクトに「オベリスク(Obelisk)」というものがあると伺いました。これは堀井さんが担当?

堀井:モノリスと一部かぶるところもあるんですが、各タイトルの売上げの数字を、会計担当者に正確に伝えるための集計ツールです。会計の数字はIT監査に耐えなければならないので、どの数字を出すかはシビアな問題。

また、海外のゲームを日本でライセンスして運営する場合(ライセンスイン)だと、そのままでは日本の法律や会計基準に沿った売上げ集計がしにくい。

そういうのを開発・運営側で考えだすと、それだけでも負担がかかる。それを一気にまとめて全部引き受けますということ。

オベリスクは決してスピード感は要求されないけれど、数字が間違っていないことが重要。例えば集計ログが不完全で、100円しか買っていないはずなのに、200円使ったことになっているような、データの矛盾が発生することがあります。

そうした矛盾を発見するとアラートを出して自動的に集計をストップするというような仕組みがオベリスクにはあります。その結果、ゲーム・クライアント側のバグ発見につながったこともあります。

株式会社Aiming 開発グループ リードソフトウェエンジニア 堀井啓真氏
開発グループ全体を見ているが、主に基盤開発に注力してチームのマネジメントも行う。各ゲームタイトルの課金や売上げ状況のログを集計して会計担当に手渡すシステムの自動化や、各タイトルを横断する独自の認証基盤作りも進める。

──そもそも「モノリス」や「オベリスク」の命名の由来は?

堀井:オベリスクは、先にモノリスがあったから、近い雰囲気の名前ということで決めました。モノリスチームの命名規則はみんな映画『2001年宇宙の旅』から来ているんだよね。

芝尾:コードネーム「HAL」とかいう機能もあります(笑)。

堀井:もう一つ、僕らの基盤開発チームがやっているのに「LINK」というプロジェクトがあって、これはタイトル共通の認証・課金のシステムです。

自社開発だけならそんなに問題はないけれど、Aimingには海外からのライセンスインのゲームも多い。なかには認証・課金のところはプラットフォームに全面依存していて、ゲーム内にはその仕組みを持たないゲームもあります。

それを僕らが用意しなくちゃならないんですが、ゲームタイトルごとに作ったらもう大変。そこで、各タイトルに全部使える共通基盤を作っちゃおうということで始めました。

こうした共通基盤づくりは大きな企業だとやっていると思うけれど、当社程度の規模では珍しいかもしれない。エンジニアの人数規模がそんなにはないので、だからこそ共通基盤を開発して効率化しないといけないんです。

「面白そうだ、すぐ使おう」の作風が根付くエンジニア組織

──必要な共通基盤をみんなで創りだすというのは、Aimingの文化といってもいいんでしょうか。

野下:問題があるなら、それを解決したいという欲求は人一倍強いと思いますよ。そのために積極的に新しい技術にアプローチしていくのも、Aimingの文化といえるんじゃないかなあ。

GCPもそうだし、BigQueryもそうです。エンジニアがこれ使いたいと思ったら、よほどお金がかかるものでない限り、いちいち上層部の了解を得なくてもすぐに使える。

発想から決断までのステップが短いんです。オベリスクも裏の見えないところでは、新しい技術を採用していますよね。

_MG_8126

堀井:GoogleのContainer Engine(GKE)ですかね。Webのサーバーとかバッチ処理などのプロセスを一つのコンテナで処理できる。「この技術、使ったら面白そうだよね」「そうだよね」で、あっという間にスタートということはよくあります。

オベリスクはそれほど負荷のかかるシステムじゃないので、まずはGKEを使って、サービスを無停止状態のまま、新しいバージョンをリリースするにはどうしたらいいかという検証ができます。

その検証ができたら、そのノウハウをもっと負荷のかかるプロジェクトに導入することがしやすくなります。

芝尾:そもそもAimingの社風としては、GCPのように、インターネットに自社データを置くことをまったく厭わない、というのがあると思います。まだ、基盤的なデータはオンプレミスでやりたい会社が多いですからね。

野下:たしかに、セキュリティを懸念して、オンプレミスでやりたいという会社は多い。
芝尾:でも、だからといって自社内にHadoopサーバーを何台も置いたら、誰がメンテナンスするのって。とても今の人員では管理できないですよね。

──Aimingは開発者クレドを公開していて、そこには「変化は善なり」と書かれている。それが単に言葉だけじゃなくて、社内風土にまで根づいているということでしょうか。

堀井:そもそもスマホ・ゲームの世界は、AppleやGoogleが新しい技術をどんどん出してくるわけで、新しいモノに臆病になっていたら、この仕事はできないんですよ。

社内にはゲーム開発に使えそうな世界の新技術をリサーチするチャットのチャンネルもあります。最初は誰かが人柱になって報告する。

それが使えるとなると、他のチームも導入する。他のチームが使っているから、自分たちはもっと新しいものを採用しようとか、そういう変な競争もあるけどね(笑)。

野下:効率化を考えると、みんな同じモノをつかったほうがいいけれど、その瞬間、新しい技術に目を閉ざしてしまうことにもなりかねない。

堀井:あと、インフラエンジニアだからといって、ゲームのことはゲーム開発者に全部お任せという風土じゃないですね、うちは。

例えば、データ集計のためにはログの仕様はこうなっているべきだと基盤側のエンジニアが開発側にもの申すということはよくあります。

開発・基盤・運用・企画の間に、境目がない。そのゲームをよくするためなら、できる人ができるところから意見を言い合うという文化は根強いですね。

芝尾:だからこそ、Aimingのエンジニアは新しいことにチャレンジできないタイプはだめかもしれない。チャレンジを続けること自体がストレスになっちゃうもしれないから。

インフラエンジニアのスキルセットが変わる時代に

──そこで採用の話を。どんなエンジニアがいま必要ですか。

野下:私は採用面接に必ず参加しますが、やはり、技術に対してどれだけ貪欲か、新しいことにどれだけ挑戦しているかが、採否の鍵になりますね。

それと、たとえインフラエンジニアでも、ゲーム好きかどうかは重要。ゲームやっていないと人を全く採らないかというとそんなことはないけど、Aimingではやはりゲームが共通言語になっているから。

堀井:最低限、ゲームに拒否感がない人ですね。

野下:勉強会はどんなところに顔を出しているの、とかもよく聞きますね。

堀井:Aimingも会社としてオープンソースのコミュニティをサポートしています。この前も、RubyKaigiのお弁当スポンサーをやりました。そこで出会うエンジニアたちは魅力的な方が多いです。

各プロジェクトが社外向け勉強会を開いて、そこで人材をスカウトするキャラバンプロジェクトとかもやっています。

一方、社内勉強会も盛ん。僕のところでは、Ruby on Railsのソースコードを読む勉強会を細く長くやっている。 突発的に発生する勉強会はそのままハングアウトでビデオ中継したりするので、誰でも見られる。

芝尾:GitHubにコードを上げているような人は採用にあたっても判断しやすい。コードの書き方一つでだいだいその人の資質はわかりますからね。あと、僕個人的にはマイナーな言語に詳しい人には興味がある。今だとElixirかな。

──最後にこれからのみなさんの抱負を。

芝尾:ゲームをDVDのパッケージとして販売していた時代には、ヒットするかどうかはディレクターの勘と経験がモノを言った。しかし、オンラインゲームは修整・改良が絶えずできます。

それを下支えするのがデータの数字。今後は機械学習などの人工知能を使ってデータを分析したり、モデル化による予測も必要になります。そういうデータ分析をする文化を社内に創りたい。

野下:インフラエンジニアというと、かつてはサーバーのキッティングみたいな作業が中心だったが、いまはクラウドサービスを利用するからそんな作業は必要なくて、コードを書くことがメインの仕事になってきています。

つまり、インフラエンジニアのスキルセットががらりと変わりつつある。それに対応できるチームを作ることが、マネージャーとしての私の課題ですね。

堀井:大小さまざまな開発案件があるけれど、どうやったら技術的に新しいものを使えるかは重視したい。新しい技術である分、失敗もするけれど、それも含めて社内の知見になる。

使ってみないとわからないこともたくさんある。技術開発では、効率化とトライ&エラーの両方が同時に必要だと思います。

(執筆:広重隆樹 撮影:平山諭)

  • 56
  • このエントリーをはてなブックマークに追加

■関連記事

今週のPickUPレポート

新着記事

週間ランキング

CodeIQとは

CodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。

CodeIQご利用にあたって
関連サイト
codeiq

リクルートグループサイトへ