【CEDEC 2021】『NieR Re[in]carnation』における負荷試験の効果的な運用方法とは　技術・チームの両面から実践内容を紹介

 
コンピュータエンターテインメント協会（CESA）は、8月24日～26日の期間、オンラインにて、国内最大のゲーム開発者向けカンファレンス「コンピュータ・エンターテインメント・デベロッパーズ・カンファレンス 2021」（CEDEC 2021）を開催した。

本稿では、8月24日に行われた、アプリボット・ソフトウェアエンジニアの斎藤樹氏による講演「大型リリースを支えるサーバーアプリケーションの可用性の高め方 ～NieR Re[in]carnation における実践～」をレポートしていく。


▲斎藤氏は『NieR Re[in]carnation』でバックエンドのパフォーマンス改善、英語版・韓国版向けの実装を担当している。

まず始めに斎藤氏は、本講演で伝えたいこととして「負荷試験の”正当性”の重要性」を挙げた。これは、さまざまな制約によって正当性が担保されない状況が発生するためと説明した。このほか、実際にどのような対策を行ったかという「負荷試験の実践内容」や「障害モードの分析から得られること」についても伝えていくという。

次に、背景として『NieR Re[in]carnation』ではリリース当初より安定的なサービス提供を行えていることを紹介。さらに、『NieR Re[in]carnation』に関しては韓国語版・英語版に関しても同様に安定していることを付け加えた。

というのも、同社では過去にリリースしたタイトルでリリース直後に障害となるケースもあったという。そこで、過去事例を踏まえてより入念に本リリースを想定した負荷試験を実施したとのこと。同時に、負荷試験を実行するという技術面だけではなく、チームとして監査していく仕組みも強化したという背景がある。

1. NieR Re[in]carnationのシステム構成

ここから講演の本題へ。省略された形ではあるが、以下はアプリケーションサーバーのシステム構成の概略図となる。



性質については、Amazon ECS上に事前ビルドしたAPIサーバーイメージをデプロイするシンプルな構成となっていると紹介。また、Bliue/Green Deployが可能で合ったり、API、データストアともにほぼ全てのコンポーネントがユーザー数に対してスケーリング可能になっている。データストアに関しては冗長化された構成となっており、Redis Clusterを利用しており、Auroraに関しても冗長化されているとのこと。

モニタリングの様子は以下の通り。



何かアラートがあった際にはサマリーがSlackに通知され、リンクをクリックすることでDataDogへ遷移する。一定以上のエラーが発生した場合には、電話によるアラートもあるとのこと。また、Redash上からもログを検索可能となっている。過去の事例から入念にログ設計を行っており、不具合調整の簡略化やstats化される前提で実装されているため柔軟に対応可能となっている。

2.負荷試験の効果的な運用

負荷試験とは、想定されるユーザー数に対してサービスが提供可能であることを保証するものである。例えば、APIサーバーの台数やインスタンス、データベースのサイズは適切かといった部分の正当性のチェックであると説明した。

こうした要求されるクオリティでユーザー体験を提供できるかというところのチェックも必要となる。具体的には、アプリで遊んでいる際に遅延がないか、安定したレイテンシでのサービス提供の継続性や、さまざまなエラーに対して耐障害性がどれくらいあるか、冗長化された構成に切り替わるかを調べるという。

また、先のシステム構成図では省略されていたが、補助的インフラのインテグレーションの正当性のチェックも必要となる。例として、ログ出力・集計を外部サービスとして実装した場合は、それをインテグレーションした状態で負荷試験を実施する必要があることや、各種ダッシュボードについてもダッシュボード側への負荷が原因でパフォーマンスが見られなくならないかなども確認しなければならない。ほかにも、外部サービスの連携部分にリクエストが偏った場合には、そちらが落ちないか、エラーが発生しないかをチェックする必要があると述べた。

●負荷試験（技術編）
ここからは、負荷試験の技術面について解説。最初に必要なものを以下の通りに紹介した。



では、実際に負荷試験を実施したところどのようなことが起きるのか。

まず、そもそもシナリオを書く工数が大きく「シナリオが壊れがち」という問題が起きる。最新のサーバー環境やアプリケーションバージョンに追従しなければならず、データに関しても同じことが言えると説明した。

また、「実運用に近いユーザーデータを再現するのが難しい」。これは、認証情報の適切な作成や、実運用データは実際にリリースしないと再現しづらいという理由がある。苦労して用意したデータが最新の試験環境では動かないことも。

さらに、外部連携系のAPIなどが存在した場合は、上手くフックする必要があるなど「試験するのが難しいAPIが存在しがち」という問題もある。

最後に、大きなリソースを使用することで費用的な制約が厳しくなり、シナリオを実行するためのコスト（人件費）もかさむため、長時間の試験が難しい。

このような問題を技術的に解決していく必要がある。対策について話す前に斎藤氏は、前提として負荷試験中のシステム構成を紹介した。


▲補足として、全てのインスタンスは本番と同じスケールのものを別VPC上に用意したと説明した。なお、CI/CD基盤は共通で使えるようになっているため、デプロイ先を切り替えるだけで良いという。

負荷試験プログラムそのものの実装に関してはGatlingでシナリオを作成したものがベースとなっている。




▲上記はGatling上から出力したグラフとなる。毎秒のリクエストや同時に存在しているユーザーの数などを表示してくれる機能がある。

また、負荷試験プログラムそのものを実装することで、単体テスト・結合テストを充実させることによりシナリオの保守性を向上させることができると斎藤氏はここで改めて解説。



ここからは実際に負荷試験で用いたシナリオの種類について紹介していく。

まずは「定常試験」について。こちらの目的はサービスの通常時負荷の確認となる。基本的には全APIを網羅していて、適切なリクエスト比率、武器・キャラの強化、クエストの実行などは多めに、滅多に実行されない名前の変更などは少なめに設定されている。また、想定ユーザー数が並行して実行できることが必要となる。そうして事前に想定するユーザー流入に耐えるかどうかを判断するものとなっている。

2つ目は「スパイク試験」について。こちらの目的は瞬間的な高付加時のパフォーマンスをチェックするものとなる。例えば、新しい施策のリリース時や、時刻予告した全体メンテナンス開け、キャッシュが存在しない状態での瞬間的にアクセスした場合、日付変更時など特定時刻で内部的に処理が増えるタイミングに負荷が瞬間的に増大するケースがある。こういったものをシミュレーションするシナリオとなる。

最後に「耐久試験」について。目的は、数日流して性能劣化や変調が見られないかを確認するものとなる。DBなどはIOPSやQPSが極端に変化していないか（上限に当たっていないか）、共有キャッシュのメモリを使い切っていないか、各種リソースに身に覚えのない使用がないかをチェックするものになっている。これに関しては、数ヶ月経過相当のユーザーデータを入れたうえで試験することで、スロークエリなどの注意すべき警告、エラーログが発生しないかを確認するものとなる。これにより、例えばN＋1問題のような効果があった場合にはそれを発見することができるほか、ユーザー数比例の問題があった場合にそれをチェックすることができる。最低限4～5日間、もしくは運用想定のユーザーデータの容量相当のシナリオを流しっぱなしにする必要がある。例えば、「○○万ダウンロード達成」というような状況を想定できるかというシナリオになっている。

以下は実際に作成されている負荷試験シナリオである。
・「ゲーム開始後、チュートリアルクリア後にアカウントを放置する」
・「特定時刻に特定の機能を一斉に利用する」
・「一定時間同じ機能を周回的に利用し続ける」
・「ごく短期間に上記を繰り返す」
・デバッグのためのシナリオ
なお、上記の全てが短時間で終了するものではないため、繰り返しや待ち時間を極力排除するようにしてシナリオそのもののデバッグを行えるようにしたものも存在しているという。

●負荷試験（チーム編）
ここからは負荷試験のチーム面について解説。

『NieR Re[in]carnation』をリリースするにあたって、「APIサーバー実装者」「アプリボットSREチームメンバー」「CAグループ横断組織メンバー」で負荷試験チームを構成した。日々の合議のスタイルとしては、Slack上で随時試験結果をレポート（レポートアップロード自体は自動化されているのでURLを貼るだけ）、毎日の朝会、定例として週一度のミーティングなどを行ってきた。結果として、複数人で負荷試験に対して監査の役割をお願いできるのは客観性の観点で負荷試験のクオリティが高まってありがたかったと斎藤氏は述べた。

次に、負荷試験を行うにあたって工数がどれくらいかかるかという課題について。アプリの規模にもよるが、シナリオ作成は1ヶ月以上かかる。理由として、シナリオ作成だけではなく、負荷試験を実行するツール群が必要になるためだと説明した。それぞれ使用しているクラウドやアプリケーションの構成が異なるため、テンプレート的なツールが存在しないと解説した。実際、テストケース作成かそれ以上に工数が必要となると話した。また、構成の変更が行われても影響する範囲が限定的なケースもある。シナリオに関しては、ひとつ前のリクエストが失敗した結果、ひとつ後ろのリクエストが失敗するというように芋づる式に失敗する状況に至ることもあるので、ひとつの構成変更が全体に影響を与えることがある。

どれだけ自動化できるかにも依存するが、試験実行には1～2ヶ月はかかってくると言及。実装上の構成の変更や、致命的なアプリケーションロジックの変更を行った場合再実行すると考えると、実際の期間は予想困難となっていると斎藤氏は語った。

今回、『NieR Re[in]carnation』はCBTを実施することが決まっていたため、生のユーザーデータを得られる貴重な機会となった。ほか、CBTのリクエスト分布から、本番環境に必要なリソースを推定することができるなど、以下のようなメリットがあったと解説した。



そうしてリリースを迎えることになったが、リリース前後はシフトを作成し、リリース～48時間分のシフトを組んで、対応体勢を準備。開発メンバーに割り当てるタスクをローテーションすることで知識を平均化していたこともあり、対応はそれぞれのメンバーで独立して行える状況にしていたという。また、障害発生時の対応方法は事前のミーティングで打ち合わせ、runbookを共有。レベルに応じた障害アラートを設定したり、アラートに対して既に対応手順がまとめられている状態となっていた。さらに、各ステークホルダーへの報告経路の定義などを行ったと、リリース前後における体制を紹介した。

告知やマーケティング施策が運用されることもあるが、『NieR Re[in]carnation』に関しては、ユーザーへの影響や各種イベント予定などへの影響を配慮して「○○時にリリース」という情報出しは行わなかったと説明。運用物は事前に打ち合わせ、リリース後の運用計画・ゲーム内施策を鑑みてスケールアウトが必要か判断するなど、連携を密に行うことができたと述べた。

ここまでのまとめとして斎藤氏は、まずはシナリオを作成することが大事だが、そのシナリオが壊れない仕組みを整備することも同様に大切と話す。可能な範囲の作業は自動化し、作業者の負担を軽減することが持続可能な（正当性担保可能な）試験に繋がると語った。

3.負荷試験を踏まえた改善項目とシステムの安定性評価

ここからは負荷試験を踏まえた改善項目とシステムの安定性評価に関する話を展開。まず始めに、実際に行われた改善を以下のように紹介した。


▲KubernetesからAmazon ECSへ移行した理由については上記のように解説。



そのほか、細かい改善として、共有キャッシュのTTLの仕様が曖昧であったため、TTLを必要以上に長くする傾向にあったので適切なTTL設定を行うことでキャッシュ溢れのような状況を防止したことや、一部トランザクションのログの切り分けなどを行ったことを紹介した。




▲システムの構成変更に関しては議論に挙がったが、作り変えやすいシステムとなっていたため問題なく変更を行うことができたという。

最後に、システムの安定性評価として「FMEA」を簡易的に適応して評価を行っていく。

故障モード影響解析「FEMA」とは、故障・不具合の防止を目的とした、潜在的な故障の体系的な分析方法。対象システムに対して、障害モードを列挙する。また深刻度、発生頻度、検知しにくさを障害モードごとに設定してRPN値として計算し、これが高いほど影響が大きいとみなし、その大小によって対処方法を検討する評価手法だと説明した。



・コンポーネント削減により障害モードの対比


こうした改善を行っていった結果、コンポーネントを省略するということは、障害モードを削除するのと同じであると斎藤氏は述べる。削除することによってコンポーネントが削減していた障害モードを増やすことになるが、そのRPN値が低いことを意味するため、使われていない・使用頻度の低いコンポーネントを放置することは障害モードを増やしているのと同じであるためであると斎藤氏は解説した。

また、KubernetesからECSに移行したことにより、LBがマネージドになり、アウトソースによって障害のRPN値が下がった。結果としてRPN値の高い障害モードを削減することとなり、システム全体の安定性に寄与していることが分かったとまとめた。



最後に、本講演のまとめとしてポイントとなっている部分を振り返り、講演の締めとした。

（取材・文 編集部：山岡広樹）