「プリコネR」が無障害で全世界リリースを達成できた理由　海外展開における負荷試験の重要性

自己紹介

加藤雅氏：みなさん、こんにちは。グリーエンターテインメント株式会社の加藤です。本日は「海外展開と負荷試験」という内容で発表します。

まず自己紹介します。加藤雅と言います。2017年にグリーエンターテインメントの前身であるファンプレックスに入社し、サーバーエンジニアとして、いくつかのネイティブアプリの開発に参加しました。

その後、チーフエンジニアとして、エンジニアのスケジュールの調整や育成を経験しました。現在はエンジニアマネージャーとして、エンジニアのマネジメントやアサインの調整を担当しています。

セッションのアジェンダ

それではさっそく、アプリ海外展開の事例の紹介します。今回、株式会社Cygamesさまのスマホアプリである「PRINCESS CONNECT! Re:Dive」の海外展開版として、英語版アプリの開発を担当しました。本日はこちらの開発事例に関して紹介します。

本日の発表内容は記載のとおりに進めます。

まず、本プロダクトの開発体制およびインフラ構成について説明します。本アプリを開発するうえで、IPホルダーとしてCygamesさま、海外のパブリッシャーとしてCrunchyroll GAMESさま、そしてディベロッパーとしてグリーエンターテインメント。この3社で開発を行いました。また、リリース後も3社共同運営の体制で運営を行っています。

インフラ構成と運営形式

次に、インフラ構成について説明します。今回、グリーエンターテインメント側で新たにインフラを構築することになったため、クラウドサービスであるAmazon Web Servicesを活用し、インフラの構築をしました。また、インフラ構成として、Webで一般的な構成であるLAMP環境、分析ツールとしてはGoogle CloudのBigQueryを活用しています。

次に、簡単ですがインフラの構成図を記載しました。この他にもいくつかのAWSのサービスやサーバーの負荷分析ツールなどを活用し、日々エラー分析や負荷の監視などを行っています。

次に、運営形式について紹介します。今回は、タイムマシン運営という形式で運営を行っています。タイムマシン運営とは、日本版の最新アプリと同じものをそのまま運営するのではなく、キャラクターの追加やイベントの開催スケジュールなど、日本版で追加されたタイミングと同じ時期に、順次対応していく運営の形式になります。それに伴い、アプリのコードに関しても、日本版に追従するかたちでバージョンアップをしていくイメージです。

次に開発期間について紹介しようと思いますが、ここで最初のクイズです。日本版のアプリをローカライズを行い、リリースするまでに開発期間はどの程度かかると思いますか。（選択肢は）3ヶ月、6ヶ月、9ヶ月、12ヶ月となっています。

（投票を受けて）今のところ圧倒的に9ヶ月に投票されてますね。12ヶ月にも投票されました、ありがとうございます。

ではそろそろ回答を発表します。正解は6ヶ月です。

2020年6月から6ヶ月間、開発を行いました。まず、α開発期間として開発環境の整備を行い、サーバーやインフラの最適化を行いました。次に、β開発期間としてUIやストーリーなどの翻訳対応を行い、翻訳したものに対してランゲージQAを実施し、そのフィードバック対応などを行いました。

次に、RC（release candidate）版開発期間として、本番環境のインフラ構成や負荷試験の実施を行いました。その後に申請などの準備を整え、2020年12月にソフトローンチという、特定の地域にユーザー数を絞った状態でリリースを行いました。そして2021年1月に、晴れて全世界リリースとなるグローバルローンチを迎えました。

今回、全世界リリースとなるグローバルローンチを迎えるにあたって、ユーザー数やアクセス頻度など、日本国内でのリリースとは異なる状況が見込まれます。したがって、グローバルに最適化した本番環境の準備が重要になってきます。

そこで今回は、RC版開発期間に実施した負荷試験にフォーカスして、紹介できればと思います。

負荷試験の概要とシナリオ

まず、負荷試験の概要についてです。今回負荷試験を実施した理由として、最適化した本番環境の動作検証を行い、インフラ構成のボトルネックの洗い出しなどを行うこと。また、分析ツールや監視ツールなどの機能テストなどを主な目的として実施しました。

次に、負荷試験の準備として使用するツールの選定を行いました。今回、JMeter（Apache JMeter）というツールを使用しました。こちらを選定した理由としては、古くから使われているためWeb上に情報が多くあること、比較的セットアップが簡単であること。また、グリーエンターテインメントの過去に扱ったプロダクトで使用実績などがあり、使用を決定しました。

次に、負荷試験のシナリオに関して説明します。今回、シナリオをいくつか準備して負荷試験を実施しました。このシナリオとは、ある操作や処理の一連の流れのことで、チュートリアル完了までのフローなど、想定されるリクエストの一塊を指します。

このシナリオを一斉に数多く実施し、サーバーに負荷をかけることで、事前にどの程度の負荷がかかるのか、また、CPUやメモリなど、どこに高負荷がかかりボトルネックになるかなどを確認できます。

今回負荷試験で実施したシナリオは、チュートリアルを完了するまでの一通りのAPI、いくつかのクエストを周回するクエスト周回フロー、アリーナの対戦相手を更新するフローなど、リリース時に負荷が予想されるシナリオをいくつか準備して実行しました。

負荷試験で発生した2つの事例

それではさっそく、負荷試験で実際に発生した事例の紹介します。まず、localhostで使用していたmemcachedの挙動に関してです。データアクセスの高速化を図るため、memcachedを用いて処理の高速化を図っていました。しかし、このlocalhostのmemcachedが、想定よりかなり大きな負荷がかかることがわかりました。

原因を調べていったところ、本番環境のインフラ構成をした時に、PIDファイルの設定にミスがあり、キャッシュデータが正しく生成されておらず、1度だけ実行されるはずの大量のデータセットが毎回実行され、高負荷がかかっていたことがわかりました。

キャッシュデータがない場合、都度データアクセスが走り、動作的には正常に動いているように見えるため、負荷試験を実施するまで検知できませんでした。

この対応として設定を見直し、キャッシュデータが正しく生成されるように対応しました。挙動的に検知が難しかったこともあり、負荷試験を行うことで発見することができた不具合とはいえ、発見できて本当に助かりました。

次に、負荷をかける側のシナリオ実行サーバーで起こった事例です。いくつかシナリオを実行し、サーバーに負荷をかけていったのですが、なかなか思うように負荷がかからず、想定していたリクエスト数などに届かない状況に陥りました。

シナリオ実行サーバーを調査したところ、サーバーのメモリ不足や、javaのガベージコレクトなどが発生していたことにより、サーバーの性能が発揮できず、高負荷がかけられていないことがわかりました。

そこで、まずはサーバーのスペックアップを実施し、java設定の見直しも行いました。また、シナリオ実行サーバー側に関しても、CPUなどをモニタリングを行えるように対応しました。

負荷試験の場合、どうしてもアプリ側のサーバーにチューニングに意識が向いてしまいますが、シナリオ実行サーバーに関しても最適化を行うことが必要だと学びました。

続いて、サーバー費用に関しての事例です。負荷試験実施時はもちろん本番リリースを想定した構成でサーバーを稼働させるため、サーバーの台数やインスタンスのクラスなど、本番想定の構成で稼働させます。そうなると、費用に関してもそれなりにかかります。

ただ、先ほど紹介した問題などの調査を行っている間や、業務がない土日など、試験を実施していない期間にサーバーを稼働させていると、余計な費用がかかってしまいます。

そこで試験のスケジュールを見直し、試験実施期間と調査期間のスケジュールを分け、調査期間中はWebサーバーのスケールインをしたり、DBサーバーを一時的に落とす、キャッシュサーバーはノード数を減らすなど、サーバーを余計に稼働させる時間を少なくするようにしました。

サーバー費用に関しては、大規模になればなるほど大きな費用がかかってくるため、事前の準備も大事だと学びました。このように、負荷試験を行うことで得た知見はいくつかありました。

負荷試験で得られた結果

負荷試験を行ったことによって、最終的に得られた結果についてまとめてみました。

まず、Webサーバーの台数の最適化ができました。当初、全世界リリースを行う上で想定したユーザーのアクセスをさばくため、それなりのサーバー台数を準備してリリースを行う予定でした。

しかし、負荷試験を行うことでインフラが最適化でき、結果として当初想定していた4分の1程度の台数で、リリース時の負荷に耐えられる試算ができました。これにより、想定していたサーバー費用をかなり削減することができたので、大きな結果だと言えます。

また、サーバーの潜在能力の確認できました。理論値でしたが、想定したユーザー数の何倍程度までアクセスがきてもサーバーが耐えられるかの試算ができ、想定以上のアクセス数があったとしても、どの程度まで耐えられるか、またメンテナンスが必要になるラインもある程度試算でき、リリースに向けて余裕を持ったインフラ構成を達成できました。

全世界リリース後の結果

さて、このようにしっかりと準備を進め全世界リリースを迎えましたが、ここでリリース後の結果に関して少しお伝えできればと思います。負荷試験以外にもさまざまな準備を行い、万全の体制でリリースを迎えた結果、無事インフラ関連の障害なく、全世界リリースを達成できました。

私自身、この規模のリリースは初めての経験だったため、内心とても心配していましたが、しっかりと準備を行い、万全の体制で臨めば、全世界リリースという大きなリリースであっても、障害を発生させることなく達成できるという実績を得られました。

また、その他の結果として、最終的に160ヶ国ほどの国にリリースされ、リリース後約2ヶ月で200万ダウンロードを達成できました。素晴らしいスタートが切れたと考えています。

さて、ここで2つ目のクイズを出したいと思います。ゲームをプレイするうえで、やはりゲームリソースのダウンロードは必要な要素で、本アプリでもCDN（Content Delivery Network）というサービスを用いて、リソースの提供をしていました。

初月、数多くのユーザーにプレイしていただきましたが、そのリソースダウンロードの総量は、何バイトほどかかったでしょうか。つまり、CDNの初月の総バイト量は、どの程度いったと思いますか。（選択肢は）3ギガバイト、3テラバイト、3ペタバイト、3エクサバイトと4つ準備してみました。

（投票を受けて）3ペタバイトが70パーセントほどいっていますね。次に3テラバイト、3エクサバイトとなっています。0を並べるとなかなか大きな数字に見えますが、果たしてどのぐらいいったでしょうか。3ペタバイトが一番多そうですね。

そろそろ回答を発表します。結果、3ペタバイト、最終的になんと3.4ペタバイトという数字になりました。

私も今まで何タイトルかスマホアプリの運営を行ってきましたが、ペタバイトという数字をリアルで見たのは初めてでした。本当に数多くのユーザーの方に遊んでいただけたんだな、と感じました。

負荷試験を行えば、万全の体制でリリースできる

それでは全体のまとめに移ります。今回、負荷試験にフォーカスして紹介しましたが、全世界リリースという経験をとおして、あらためて負荷試験を行う大切さを学びました。

事前に負荷試験を実施することで、リリース前にしっかりとした準備を行うことができ、障害を発生させることなく、全世界リリースを達成できました。もし実施していなければ、今回のような安定したリリースは達成できなかったかな、と感じております。

また、今回自分自身もさまざまな知見を得ましたが、他のプロダクトで実施した時の知見や、インフラの担当の方が今まで得てきた知見などもとても役に立ち、ボトルネックの早期発見につながりました。今回のような事例をとおして得た経験や、知見を蓄積していくことの重要性を知りました。

そして、グローバル展開を行うことで、日本でリリースする場合とは比べものにならないほど数多くのユーザーの方々にゲームをプレイしてもらえるという、大きな可能性を感じました。

今回は時間の関係上、細かく説明できなかった点も多々ありましたが、グリーエンターテインメントのホームページのTECH BLOGでも一部紹介しているので、もし気になった方は見てもらえると幸いです。

今回、海外展開と負荷試験という経験をとおして、数多くの知見が得られました。この経験を活かして、今後のゲーム市場をより盛り上げていきたいと考えています。本日はご清聴ありがとうございました。