「初音ミク -TAP WONDER-」を支えるクラウド基盤　“PaaS初心者”のゲーム企業が挑んだ、アクセス集中に耐えるインフラ構築

　「初音ミク」をテーマにしたスマートフォン向けゲーム「初音ミク -TAP WONDER-」（ミクたぷ）。全世界に配信している同作は、実は提供元のエイチームにとって初めてゲームの提供基盤に「Google Kubernetes Engine」（GKE）といったPaaS（アプリの実行、開発に必要な環境をクラウド経由で提供するサービス）を組み込んだ作品という。

　エイチームではこれまで、ITインフラリソースのみをクラウド経由で提供するIaaSをゲームの提供基盤に使ったり、分析基盤や開発環境でIaaSとPaaSを併用したりはしていたものの、ゲームの本番環境でPaaSを活用したことはなかった。

　しかし、ミクたぷの開発では本番環境でもPaaSを活用し、2020年6月のリリース当日に起きたアクセス集中にも耐える基盤を準備できたという。“PaaS初心者”だった同社による挑戦の詳細を、リードエンジニアの堀さんに聞いた。

PaaS活用の狙いは「スケールしやすさ」

　ミクたぷは、画面をタップすることで初音ミクのライブを成功させ、衣装などのアイテムを集める基本無料のゲームだ。初音ミクに加え、「鏡音リン・レン」「巡音ルカ」といったキャラクターのファンの利用を見込んだ作品で、全世界に向けてリリースしたため公開当初は大きなアクセスを見込んでいた。

　ミクたぷの開発に当たり、エイチームがこれまで使ってこなかったPaaSの利用を決めた理由は、アクセス数の増減に合わせ、サーバの性能や数を調整するスケールアップ・スケールアウトをしやすくするためだ。ミクたぷはプレイヤーの規模が読みにくく、サーバの性能や数を調整しやすくしておく必要があった。

　「ミクたぷに限った話ではないが、ゲームサービスはどうしてもリリース時のプレイヤー数が読みにくい。事前登録数などを基にある程度予測を立ててはいたが、実際はリリースしてみるまでは分からなかった」

　同社はこれまで、ゲーム配信の本番環境ではクラウドサービスのIaaS機能のみを使っており、基盤に乗せるアプリなどは自社開発したものなどを使っていた。しかしこの方法では、アクセス数の増減に合わせてデータベース基盤などを拡張する際、自社のインフラエンジニアに作業してもらう必要があり、対応に時間がかかる場合があった。

　この状況を打開すべく同社が注目したのが、クラウド上での運用・保守を提供元に任せられるマネージド型のPaaSを採用することだ。

「GKE」「Cloud Spanner」活用で柔軟性を確保

　ゲームの提供基盤には、米Googleのクラウドサービス「Google Cloud Platform」を選んだ。これらの課題解決に同サービスのPaaSが役立つと考えたためだ。実際には、1つのOS上でアプリを動かす環境を作り、サーバのように使う「コンテナ技術」の管理ツールをマネージドサービスとして使えるGKEや、アクセスの負荷などに合わせてスケーリングしやすいデータベース「Cloud Spanner」といったサービスを活用した。

　コンテナの管理ツールとしてにGKEを採用したのは、もともと社内で研究が進んでいたコンテナを活用するためだ。エイチームではコンテナの活用に前向きな社員が多く、利用が検討されていた。しかしコンテナはあくまで仮想化技術の一つで、スケールしやすくするには自動でスケールする仕組みを一から作るか、「Kubernetes」といったコンテナの管理ツールを使う必要がある。

　インフラエンジニアにこれまでのような負担をかけず、コンテナの活用とスケールしやすさを両立するには、GKEのようにコンテナの管理ツールをマネージドで使える環境が必要だったという。

　Cloud Spannerは、エイチームがこれまで使っていたデータの保存方法との相性を考慮して採用した。同社では基本的に、データをシャーディング（データをユーザーのIDごとに分け、格納するデータベースを分割する手法）してデータベースに保存している。

　ミクたぷ以外のプロジェクトでは自力でデータを分割しており、特にトラブルなどは起きていなかった。しかし、一度スケールすると元に戻しにくく、余計なコストが発生しやすかったため、マネージドサービスであるCloud Spannerを採用して改善したかったという。

リリース時のアクセス集中にも対応、ただし課題も浮き彫りに

　マネージドサービスを活用して開発したミクたぷの提供基盤。スケールしやすさを重視する方針が奏功し、リリース時に発生した大量のアクセスにも過不足なく対応できたという（アクセス数は非公開）。

　「事前登録数が50万件と多かったので、オーバースペックなくらい事前に（サーバの規模を）拡大して挑んだ。アクセスが落ち着くにつれ縮小させ、リソースを抑えられた」

　一方で、実際に使ってみると課題も浮き彫りになった。開発環境でCloud Spannerを使うとき、コストがかさんだ点だ。

　堀さんによれば、Cloud Spannerはテスト用の環境で試用する場合でも実際に利用するときと同じ料金を支払う必要があるという。米Googleがシミュレーターを提供しているものの、ゲームで活用する場合に必要な機能が十分でないため、結局は1個当たり最低で7万円程度の料金を支払い、実物を導入しなければならず、複数のテスト用環境で使うとコストがかさんだという。

　ただし、現在はインスタンスを0.1単位で借りられる機能のプレビュー版が出ているため、今後はこれを使うことで費用を抑えられると堀さんは期待している。

この記事の著者

関連記事

• 

  開発環境をAzureに移行したらテレワーク中の出社が減りました　「オンプレはもう限界」──ゲーム企業が成し遂げたクラウド移行の舞台裏

• 

  まるで“SIer版ヤシマ作戦”　「エヴァ」公式アプリを配信基盤含め1カ月で開発　エンジニア2人の失敗できない挑戦記

• 

  前澤氏の“お金配り”、アプリ化したらアクセス殺到　数十万トラフィックをさばく「kifutown」の裏側

• 

  10倍に膨れたAWS運用費をどう減らす？　ユーザー急増のnoteが挑む「コスト削減作戦」の裏側

• 

  「アマゾンって通販のやつ？」な“昭和企業”がAWS移行できたワケ　「白い恋人」製造元の情シス奮闘記