GCPで完結させたゲームプラットフォームのアーキテクチャ　開発期間は短くしつつ、自由度を失わないための工夫

賞金がもらえるゲームプラットフォームの仕組み

菊池貴則氏（以下、菊池）：こんにちは。ガンホーの菊池です。よろしくお願いします。弊社の紹介をさせていただきます。

最近はタイトルも充実してきましたが、もともとはPC向けオンラインゲームとして17年前に『ラグナロクオンライン』を発表しました。ですので、歴史的には古い部類に入ってきたかなと思います。

ゲームの技術も進歩する中で常に創造と挑戦をして、世界中の人々にエンターテインメントを通じて感動と楽しい経験を提供することをミッションに、ゲームの開発、運営、企画をしております。

齋藤将平氏（以下、齋藤）：次は私の紹介をさせていただくのですが、アイレット株式会社を知っている方はいますか？

（会場挙手）

お、けっこういるんですね。ありがとうございます。

弊社はデザインからシステムの設計開発、クラウドの構築から運用保守のサービスとして「cloudpack（クラウドパック）」を提供しています。

ゲーム業界とのお付き合いも多く、モバイルのアプリからデータ分析基盤まで作っています。2017年からKDDIグループに参画いたしまして、エンタープライズ領域からゲーム領域まで幅広くやらせていただいています。

菊池：今日は弊社の子会社であるmspo株式会社が提供するゲームプラットフォームのアーキテクトについて説明させてください。まずmspoの紹介なんですが、昨年の4月に設立しまして、吉本興業株式会社とサイバーエージェント株式会社とのジョイントベンチャーです。

設立のきっかけは、弊社のグループ会社がUSにありまして、その会社はもともとモバイルの決済系プラットフォームを作っていて「m sports」というサービスをUS国内でHTML5ベースのゲームとしてリリースしました。

それを日本展開するための会社として、広告のプロであるサイバーエージェントさんに声をかけて、さらにご縁があってよしもとさんもゲームに力を入れていきたいということで、よしもとさんのプロモーション力を活用して展開するために、ジョイント・ベンチャーを作って始めました。

mspoというプラットフォームのビジネスロジックを説明します。

基本的には広告収入がベースになります。広告収入をユーザーに還元しつつ、デベロッパーにも還元して、一部をmspoの収入とします。ユーザーに還元した分は、iTunes、Amazon、Google Payなどのギフトカードとして受け取ることができるプラットフォームになります。

開発期間はできるだけ短く、自由度は担保する

菊池：そうしてやってきたのですが、6ヶ月ほど運営してみる中で、いろいろな問題が出てきました。例えば日米間で技術要件を詰めるといったことは、時差の関係でなかなかリアルタイムのコミュニケーションが難しいと感じました。

あとは、もともとそのUSのグループ会社には優秀な技術者がいたんですが、その分、日本のゲームの文化等をなかなか受け入れてくれなくて。それはなぜ必要なのかを理解してもらうために時間がかなりかかったことが、数回レベルではなくかなり起きてしまいました。

今年年明けに弊社のCEOである森下と話をして、一からガンホー主体でプラットフォームを作り直す話になり、2月頃にプロジェクトが始まりました。そこから開発パートナーを探すことにしました。

一番大きな特徴は、アプリのデベロッパーが容易に導入できるプラットフォームということです。もともとmspoはカジュアルゲームですので、空き時間に遊んでもらうのを目的として、1ゲームあたりマックス3分くらいのゲームがメインです。そういったゲームをこのプラットフォームに導入していくことができます。その中で、アプリの開発期間をできるだけ短くしたいという要望がmspoの社長からありました。1アプリあたり3ヶ月、長くても6ヶ月で出したい。プラットフォーム導入期間は短ければ短いほうがいいということで、そこが一番大きな要件でした。

とはいえ自由度も担保はしたかったので、バックエンドのAPIは基本的にはRESTにしました。mspoのプラットフォーム機能部分を、ゲーム内にREST APIで呼んでもらうのもありですし、開発したくないのであればプラットフォームとしてWebViewでも提供しています。

広告部分については、いろいろな広告のSDKがある中で、そこはひとまとめにしてSDK化して導入しています。あとは個人のデベロッパーの場合はマッチングサーバーまで作ってもらうのはけっこうつらいですが、要件的にはマッチングサーバーが必要になってしまうので、それもこちらで準備をしています。

また、広告とゲームとユーザーの行動を統合管理して一気に分析したい。それをまたゲームの中に戻すことをどうしてもやりたかったので、ここも技術要件に入れました。

個人的には、僕はもともとエンジニアをやっていたので、新しいサービスを作るときはなにかしら新しい要素を入れたい思いがあったので、このようなプラットフォームを開発しようと決めました。

システム構成はすべてをGCPで完結

齋藤：そんな技術要件がありまして、アイレットでできることは何かと考えました。mspoの技術的なチャレンジポイントについてお話します。

最近では当たり前のようになってるCloud SpannerとComputeEngineを組み合わせて、どんどん作っていくところもありましたが、なるべくマネージドサービスを使っていくことにしました。もちろん高い耐障害性を考えて開発を行っています。

また、認証基盤を開発するのもやめようということで、Firebaseによる認証を、Cloud Endpointsと連携させました。他には、アプリケーション用のデータベースと収集データを分析用DBにシームレスに連携することをすごく意識して作りました。DBが複数分かれたとしても、シームレスに連携するものを用意しようと思いました。

今回、菊池さんから「GCPでいくぞ」と連絡が入りましたので、すべてGCPで完結させる、といったことが技術的なチャレンジポイントになります。

こういった構成図になっています。

タイトルにもあるとおり、分析基盤としてLookerを使わせていただきました。最初、Lookerを使おうと考えていたときは、まだGoogleに買収されることが発表されていませんでした。後に「Looker社がGoogleに買収される」というニュースが出たのでちょっと驚きだったんですが、これはこれでGCP1つで完結するのでおもしろいのかなと思いました。

残念ながらまだGKEは使ってはいないんですが、基本的な構成としてはこのような構成を取っております。マッチングサーバーはElixirを使って連携しています。

クラウドストレージからSpannerのところでは、Cloud Data FusionによってBigQueryに入れ、そこでLookerが分析を行っています。

インスタンスの起動が早い一方、デメリットも

齋藤：GCPのメリットとデメリットについてです。本日会場にいらっしゃっている方々はすでにだいたい理解してるような内容になってしまうので申し訳ないんですが、僕らはとくにいろいろなクラウドを扱っているので、よかった部分としては、やはりバックエンドのハードウェアはライブマイグレーションがすごくよくできているなと感じました。

インスタンスのメンテナンス対応についても、ゲームを止めたくないという要件もありましたので、そこをしっかり解決できるイメージです。

あとはクラウドではあるあるですが、インターネット環境に開放されたサービスが多くて接続環境に縛られないところ。あとはGUIからのCloud Shellが意外と使いやすく、対応しやすかったです。

他には、やはりインスタンスの起動ですね。我々もいろいろ運用している中で、本当に早かったので、そこはメリットだと感じております。

一方、デメリットについてです。デメリットというほどの内容でもありませんが、「ツールに似た名称が多かった」とエンジニアチームは言ってます。あとはインスタンス名の初期設定をしたあとに変更できないという意見も少しありました。

ユーザサイドでの変更要素が多く、覚えなくてはいけない事項が若干多かったなという印象です。デメリットというより、まだうちのスキル不足もあるので、ぜんぜん解決できる問題でもあります。

多種多様なデータソースにつなげられる分析基盤「Looker」

菊池：先ほどもお話にあったとおり、僕のわがままもあり分析基盤にはLookerを採用してもらいました。ちなみにLookerを聞いたことのある方や、使っている方はどのくらいいますか？

（会場挙手）

まだ少ないですね。Looker自体はお世話になってる知り合いの方に紹介をしてもらいました。初めて知ったのは去年のre:Inventの直前くらいですね。re:InventでLookerのブースに行って、イケてるなとは思いつつ、自分でも情報収集をしていました。年明けにこのプロジェクトが始まったときに、なにか新しい要素の1つとして全然ありだなという感触はあったので入れました。

基本的にはこんな方針です。Lookerはみなさんが思っている以上に簡単に、多種多様なデータソースにつなぐことができます。もともとBigQueryで全部まとめる方針ではありましたが、多種多様なデータソースにつなぐことができるので、他への移行もしやすいですし、ベンダーロックもかかりにくいのでLookerを採用しました。

齋藤：ビジュアル的にもいろいろ用意されています。

我々自身はとにかく開発に集中できて、分析側とうまく連携ができたと感じています。2行目に書いてあるアジャイル開発という意味では、1週間のスプリントでどんどんレポートが作られていく流れができたのがすごくいい面でした。よりプログラムライクに作られているプラットフォームなのかなと思います。

菊池：おっしゃるとおりです。

グローバル展開に向けて、さらに強力なプラットフォームにするために

齋藤：では、今後のチャレンジです。

菊池：今後、mspoのプラットフォームでやっていきたいことはまだまだいっぱいあるんですが、その一部を紹介します。先日Slackでクローズドなイベントでもお話しましたが、SlackとLookerとGCPの組み合わせがけっこう強力だなと感じています。

Lookerを入れようと決めた理由の1つで、わりと大きな要因なんですが、Slackとの連携がめちゃくちゃイケています。Slackのbotも作りやすいし、botから特定のダッシュボードの情報を引けたり、簡単なクエリが叩けたりします。

コスト面も考えると、ExcelかCSVか画像かPDFかを選んで、Lookerから毎日のレポートをSlackに投げることができます。また、そこに対してライセンスフィーはかからず、コスト面でも優位性が大きいので、Lookerを入れています。

まだそこが実装できていないところではあるので、今後、実装していけるかなと考えています。

齋藤：ちなみに、ちょっと宣伝になってしまいますが、我々はLookerのパートナーになりました。本日発表しましたので、なにかLookerのことで相談がありましたらよろしくお願いいたします。

（会場笑）

菊池：あとはプラットフォーム部分。まだGCEを使っていて、GKEをもっと最適化していいアーキテクトにできるはずなので、そこも来年手を入れたいなと思っています。

mspoは実はすでにリリースしていて、ファーストパーティーで今回2つのアプリを出しています。今月末からmspo自体のプロモーションもかけていって、来年末にはグローバル展開をしていきたいと考えています。その準備段階としてSpannerを採用しているので、そこに向けてもっと強力な基盤にしていきたいと考えています。

クイズの自動生成は、実は一番やりたいなと思っています。ファーストパーティーで作ってるものにクイズアプリがあるんですが、そこでなにかおもしろいことができないかとずっと考えています。

クイズアプリはけっこう単純だし広がりがないですし、なかなか難しいのですが、現場のプランナーと一緒に、ネットニュースなどいろいろな情報をキュレーションして、機械学習をかけて分析して、自動的にクイズの生成ができないかとふんわり考えています。

みなさんならなんとなくできそうじゃんと思うかもしれませんが、キュレーションの部分や、どうフィルタリングをかけるか、バズっているかどうかの判定が難しいので、そのあたりをうまくできたらとは思っています。

齋藤：では、少し短くなりましたが以上になります。ここからは、質疑応答の時間とさせていただきます。よろしくお願いします。

GCPは学習しやすいか？

司会者：いくつか質問いただいているので、人気のものから質問していきたいと思います。

「AWSの知識があってGCPにまだ慣れていないエンジニアの場合、どれくらいでキャッチアップできますか？」。とくにアイレットさんは他社クラウドさんにも強いと思うので、内部のエンジニア育成などをどうされていたか教えてください。

齋藤：AWSのエンジニアは相当強いですね（笑）。GCPに関しましては本当にまだまだ少ないのですが、実際にこういうかたちで案件に携わらせていただくと、学習スピードはかなり早かったと思っています。

正直1、2ヶ月もあればクラウドエンジニアなら問題ないかなと。覚えてしまえばそんなに大きく変わりません。それぞれのマネージドサービスをうまく利用して学習してもらいたいなと僕は思いますね。

ちなみに、エンジニアの採用は積極的に行なっていますので、よろしくお願いします。

（会場拍手）

司会者：ありがとうございます。菊池さんはいかがですか？

菊池：僕の知っている限り、ガンホーではGCPの導入はほとんどなくて。個人的にはGCPはAWSでCLI使っていたら、そんなにつらくないと思います。ですが、Webコンソールで作業してしまっているとGCPはコマンドラインでなければできないことがまだまだ多かったりするので、そこでつまずくパターンはあるかなって感じです。でも、そこも覚えてしまえばいいだけなので、やる気があればすぐ覚えられるじゃないかなぁって感じですね（笑）。

司会者：1、2ヶ月くらいで？

菊池：そうですね、そんなにつらくないと思います。全部わかる単語になっているので、学習コストはあまり変わらないと思います。

Data Fusionを選択した理由

司会者：ありがとうございます。では、次の質問にいきたいと思います。「SpannerからBQにデータを送る際にData Fusionを選択した理由を教えてください」。

菊池：選択肢はけっこういろいろあったんですが、一番の理由は設定が簡単だったからです。

Googleの方と相談しつついろいろなパターンを協議したんですが、結局Data Fusionは費用はちょっとかかるけれど、出たばかりでおもしろいサービスだし、使おうかなと思いました。実際使ってみると簡単に設定できましたし、よかったかなと思います。

司会者：ありがとうございます。比較的新しいプロダクトですが、Data Fusionの導入でなにか問題は発生しましたか？

菊池：いや、とくになかったですね。

司会者：お、すばらしいですね。ありがとうございます。では、Spannerに関する質問です。「最近Spannerの可用性はノード1つでも担保されるようになりましたが、その発表後、ノード数を減らしたりしていますか？　ふだん何ノードくらい立ててますか？」という質問になります。言える限りで大丈夫です。

菊池：まだサービスして間もなく安全を取りたいので、テスト環境やステージングでは1ノードだけにしていて、プロダクションはミニマムで3ノードになってます。そこはとくに触っていません。パフォーマンスも問題なくて、「ちょっと余ってるかな」くらいの感じですが、たぶんそのままいくと思います。

プラットフォームなのであまり変更する気はなくて、これからユーザーがどれくらい来るかも読めていないプラットフォームなので、おそらくそこも触らないでいくかなと思ってます。

司会者：わかりました。ありがとうございます。では一旦質疑応答を締め切ります。菊池さん齋藤さんありがとうございました。

齋藤：ご清聴ありがとうございました。

菊池：ありがとうございます。

（会場拍手）