コンテンツに移動
Google Cloud

株式会社バンダイナムコスタジオ様の導入事例動画: Google App Engine の活用で、ゲームリリース後のトラブルとは無縁の「平和な日々」という驚きを体験

2018年7月4日
Google Cloud Japan Team

https://storage.googleapis.com/gweb-cloudblog-publish/images/logo_bandai.max-400x400.png

ゲームアプリ「アイドルマスター ミリオンライブ! シアターデイズ」(配信元:株式会社バンダイナムコエンターテインメント)の開発にあたり、株式会社バンダイナムコスタジオは Google Cloud Platform(GCP)の導入を決断します。
Google App Engine(GAE) は、スケーリングが極めて高速であり、突発的なアクセス数増加にも柔軟に対応することが可能です。この GAE を活用し、大きなメリットを生み出した同社の事例をご紹介します。

Video Thumbnail

■ 利用している Google Cloud Platform サービス

Google App EngineGoogle Kubernetes EngineCloud DatastoreBigQueryGoogle Stackdriver など

株式会社バンダイナムコスタジオ

アーケードや家庭用ゲームの他、モバイル向 けのソーシャルゲームにも積極的に取り組み 多くのヒットを生み出しています。「Innovation through Creativity」を スローガンに時代の先頭に立ち、新たな広がりと深み をもった数々の人気ゲームタイトルを世に送り出すことで、社会に「夢・遊び・感動」を 提供することをモットーにしています。

IaaS ベースのインフラの課題とソーシャルゲーム運用の難しさ

数多くの人気コンテンツを提供する株式会社バンダイナムコスタジオ。同社のモバイル用ゲームコンテンツの提供は i モード時代の 1999 年からで、当初システムはオンプレミスでしたが、2012 年頃から、あるクラウドサービス(IaaS)への移行を始めました。
ただ、この IaaS サービスにはいくつか課題があったと保科さんは言います。「大量のアクセスのため、コンテンツによっては十数台のデータベースサーバーを並列化して運用するのですが、サーバーが増えれば増えるだけ障害発生率も増加していたのです。また IaaS では 1 度データベースの構成を決めると、サーバーの増減は簡単ではありません。さらにフロント側の Web サーバーのスケーリングでは、台数の変更に時間がかかり、実際のアクセス増減にうまく追従できない問題がありました。」(保科さん)

ソーシャルゲームでは、リリース直後、テレビ CM 放映時、ゲーム紹介の動画配信などをきっかけに「スパイク」と呼ばれる急激なアクセス数の増加が発生します。「スパイクの発生を予測することは極めて困難です。SNS など我々の知らないところで注目が集まり、それをきっかけに爆発的なアクセスが殺到しスパイクが発生することもあります。」(八重樫さん)
スパイクが発生した際、Web サーバーを迅速にスケールアウトして台数を増やせば、レスポンス低下などの問題を避けられますが、スパイクが去ってアクセスが落ち着いた後に、増やした台数を元に戻さなければ、無用なコストが発生し続けます。従来の IaaS では、このようなアクセス数の増減に完全に自動的には追従できず、人手による監視や運用の手間が随時発生する課題がありました。
またデータベースについても、実際のアクセスにより必要となった規模・処理能力が、最初の見積もりを外した場合は、適正な構成に変更するまで、辛いメンテナンスの時間を過ごすことになります。

こうした背景から今回のゲームアプリ「アイドルマスター ミリオンライブ! シアターデイズ」(配信元:株式会社バンダイナムコエンターテインメント)の開発にあたって、同社は Google Cloud Platform(GCP)の導入を決断します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/pHeZKN1tuT31-LrcCyASpK6jRDLalgju6vYPxsHjFh.max-1600x1600.PNG
「アイドルマスター ミリオンライブ! シアターデイズ」
(配信元:株式会社バンダイナムコエンターテインメント)
©窪岡俊之 ©BANDAI NAMCO Entertainment Inc.

「今回のゲームでは、サービス開始後にどの程度のアクセス数が集まるか予測できず、適切なデータベースや Web サーバーの規模を事前に決めることは困難でしたが、その頃 Google App Engine(GAE)について知り、データベースの Cloud Datastore がほぼ無制限の自動スケール性能を持つこと、Web サーバーのプログラミング言語に Go を使えば起動がすごく速く、スパイクを含むアクセス数の極端な増減にも自動で対応できることを知りました。実際にテストでも、よい手応えを感じられ、よし GCP を使ってみよう!と考えました。」(保科さん)
GCP の採用においては、エンジニア側の熱意も大きかったようです。「GAE と Datastore、Go 言語でやりたいという思いがエンジニアにすごくあったんです。社内からは、本当に GAE で大丈夫かという声もありました。そこで事前に負荷試験を実施したり、GCP パートナーの協力のもと開発体制を整えたりと取り組みを進めました。そういった社内での努力、エンジニア以外のステークホルダーに向けたアピールの甲斐もあり、最終的に GCP の採用に至りました。」(保科さん)

Google App Engine の活用でエンジニアが開発に集中できる環境を構築

本ゲームの開発は、GAE で行われました。大量アクセスへの対処は、検証時の負荷テスト時に想定される 2 倍以上の負荷をかけ問題がないことを確かめました。サービスインした 2017 年 6 月 29 日正午、当時を宮野さんは次のように振り返ります。
「サービスイン後、サーバーエンジニア全員で、Stackdriver Logging や Stackdriver Monitoring を使ってモニタリングし、さらにお客さまが SNS で発信する生の反応をチェックしながらサーバーの状況を見守りました。予想以上のお客さまに遊んでいただき、リセマラ(リセットマラソン)もありましたが、アクセス数の増加、スパイクによるトラブルは発生せず、期待以上の安定動作で大量のアクセスを耐えきってくれました。ゲーム操作を自動化するプログラムボットのアクセスも多数確認されましたが、GAE の自動スケール性能を上回ることはなく、お客さまのアクセスには影響しませんでした。」

公開から半年以上が経過した今も、Cloud Datastore を含むサーバーインフラの構成変更は 1 度もなく、すべては GAE の自動スケールで運用されており、サーバーアプリケーションの更新もサービスを停止せずに行われています。運営中も絶えず開発が必要なソーシャルゲームにおいて、完全無停止の自動化インフラ運用がもたらすメリットは極めて大きいといえます。この安定稼働について、1 つの大きな利点は GAE のバージョン機能です。本機能は、バージョンアップの際、従来の環境に手を加えず、別系統として新バージョンを用意しておき旧バージョンから瞬間的に切り替えられます。
「デプロイが本当にしやすいんですよね。秒間数千リクエストがあり、かつ数百のインスタンスが稼働している状況でも、バージョン機能なら普通に新しいバージョンに切り替えられます。」(保科さん)
「従来は、デプロイのためのインフラ安定のために、大変な時間と労力を要していました。また運用中のデプロイは完了までに数 10 分かかったり、サービスが不安定になったりするリスクが伴うのですが、GAE なら、バージョン機能で瞬間的かつ安全に切り替えられるし、問題があったら即座に元のバージョンに戻せる。これは感動しましたね。」(八重樫さん)

さらに八重樫さんは、GCP は運用でよく使われるユースケースがしっかり考えられていると話します。「GAE のバージョン機能のように、『普通、こう作るよね』という仕組みが、はじめからわかりやすい形でドキュメントと共に用意されていて、期待通りに動いてくれる。これはすごく重要なことです。不要な試行錯誤をせずとも GCP の機能をフル活用できたのは本当にありがたかった。」

今回は、ログ解析基盤として BigQuery が使われています。ゲームシステムからのログは膨大で、社内のログ解析基盤では処理しきれないほどでしたが、BigQuery は、タイミングやクエリの性質を気にせず、任意のログを探し出すことがスムーズに行えたと評価します。
「今回のプロジェクトで、BigQuery はあらゆるところで活用されています。特に Stackdriver Logging との連携により、アクセスログが 1 日や 1 時間などではなく 1 分未満のディレイで BigQuery のテーブルにストリーミング挿入され、それに対して様々なクエリを発行できる機能があり、これにより直近 1 分から数ヶ月といったスパンのアクセス分析をリアルタイムに実施できます。様々な不具合や障害に対する早期対応には BigQuery は欠かせません。」(八重樫さん)

今回の GCP の導入効果を振り返ると、インフラ運用負荷の大幅な低減があったと言います。「IaaS ベースですと、仮想マシンに必要なソフトウェアのインストール・設定、独自開発など、ある程度はエンジニアをインフラ運用や開発に割かざるを得ないんです。でも GAE なら、そのような時間は全体からみたらごくわずか。エンジニア全員がゲーム開発に注力できました。」(宮野さん)

他の Google サービスとの統合による利便性の高さも大きかったと語るのは八重樫さんです。「クラウドのコンソールへのアクセスや、ゲーム管理画面へのログインなどでも Google アカウントが使えるので、新たに認証・認可の仕組みがいらないことは楽でした。Google アカウントはほぼ皆使っているので、新規メンバーでも即座にプロジェクトに入れますし、シームレスに使える Google スプレッドシートも、自動化のスクリプティング環境や API が整備されており、よいところを挙げるときりがありません。Excel ファイルの添付メールが飛び交っていた頃とは一線を画していると思います。」

「GAE や Google サービスを活用できるまでには相応のコストが必要でしたが、トータルではそれを上回るメリットが得られました。GAE と Go 言語による開発で最大のパフォーマンスを引き出すには、設計思想やベストプラクティスの理解が必要です。今回短期間での開発の達成には、我々の努力や覚悟以外にも、有償トレーニングや高度なサポートプランといったプロフェッショナルの力を借用するコストが必要でした。しかしその苦労やコストと引き換えに、ゲームリリース後の我々の労力は大幅に軽減され、今は平和な日々を送れていることは、大いに強調したいですね。」(八重樫さん)

GCP のその他の導入事例はこちらをご覧ください。

投稿先