セミナー

【CEDEC 2022】『ガルパ』が周年イベント時に発生する突発的大量アクセスへの負荷対策を紹介　2年間の失敗事例から学びを得た今年の負荷対策方法とは

2022.08.25 11:11

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

本稿では、8月23日に行われた、Craft Egg・バックエンドチームの常山貴行氏、高川雄平氏による講演「『ガルパ』周年イベントの突発的大量アクセスにおける負荷対策について」をレポートしていく。

Craft Eggが開発・運営するスマートフォン向けリズムゲーム『バンドリ！ガールズバンドパーティ！』（以下、『ガルパ』）は2022年3月に運用6年目を迎えた。運用が長く続くほどユーザーデータは肥大化していき、所々に思わぬボトルネックが発生する。また、スマートフォン向けゲームでは「周年」が最もアクセスが集中する日となる。『ガルパ』では3周年・4周年の当日に、様々なボトルネックが要因でアクセス障害が発生した。

本セッションではバックエンドチーム担当者が、3周年・4周年の苦い経験を経て、5周年時にアクセス障害の解決に成功した、『ガルパ』の「リベンジ劇」を紹介した。
まずは常山氏が登壇し、本セッションの概要を紹介した。

▲『ガルパ』は現在5周年を迎え、6周年には大型アップデートを予定している。

『ガルパ』の周年イベントは1年で最も盛り上がる日となっており、特徴として以下の2点があることを挙げた。

・メンテナンス同時刻に周年特別番組の配信
・メンテナンス明けにユーザーが一斉にログイン

周年を迎える際には毎年大きな新機能をリリースしているため、7時間ほどのメンテナンスを経て日付が変わる0時頃にメンテナンスを完了。そこからユーザーが一斉にログインしてくるのだという。下記のグラフからも、メンテナンスが明けた瞬間からアクセスが跳ね上がっていることが分かる。

こうした周年イベントの特徴から、失敗事例と失敗を踏まえた対策していく。

●3周年の負荷試験対策と結果

まずは3周年の際に行った負荷対策と傾向について。『ガルパ』では、周年イベントの負荷対策として、負荷試験とボトルネックの改善を繰り返し行っている。その中で、3周年を迎える際の負荷試験の問題点として下記の3つを挙げた。

▲本番当日まで1ヶ月しか期間がない中、負荷試験環境をいちから作り上げていったという。

まずは2周年時のデータを参考にリクエストを捌く目標値を13000req/sに設定。最初はシナリオが軽いAPIから始め、徐々に重いAPIを試していったという。以下の図は、本番と同じ構成の環境を負荷試験用に構築したもの。

『ガルパ』では通常50台のAPIサーバを使用しているが、周年イベント時などアクセス数が集中する際には125台に増やしている。データベースは本番同等のデータが必要となるため、35台分をスナップショットから復元した。

3周年時の負荷試験では、JAVAの負荷試験ツールとして知られるJMeterを採用。JMeterサーバ1台あたりにどれほどの負荷を掛けられるか検証した後、JMeterをmaster/slave構成にして少しずつslaveを増やしていったという。ところが、slave4台目あたりからパフォーマンスが上がらなくなってしまった。そこで、master1台に対してslaveは3台までとし、1セット4台構成を10セット（計40台）作成して検証。その結果から、理論上はあと40セット必要という計算になった。

そうすると、AWSのインフラコストが高くなってしまうことが問題に。また、本番では瞬間的に負荷が掛かるが、JMeterでは瞬間的な負荷を再現できなかった。こうした多くの問題を抱えたまま、負荷試験も中途半端な状態で本番当日を迎えることとなってしまったと当時を振り返った。結果として、本番当日はメンテナンス明け10分ほどでアプリが重くなり緊急メンテナンスへ。

後日、原因を調査したところ、下記のような点が問題になっていたことが明らかになった。

●4周年の負荷試験対策と結果

続いて、4周年の際に行った負荷対策とその結果について。まず、3周年の際にボトルネックとなっていたマスターデータ取得APIを軽くするために、マスターデータの圧縮を行った。元々1リクエスト辺り8メガあったマスターデータのサイズを、1,2メガまでサイズダウンすることに成功。また、tomcatのデフォルトスレッド数を200→600に引き上げた。さらに、ログイン時のプレゼントBOX履歴削除が重い動作だったため、一時的に処理しない制御を実装した。

また、3周年時にはインフラコストが高くなってしまったことや、JMeterでは本番相当の負荷が掛けられなかったことから下記の対策を実施。

こうして準備をして4周年当日に臨んだが、またしてもアプリが重くなり緊急メンテナンスという結果に。調査したところ、アプリが重くなった原因はiOSの仕様変更でバージョンによってGameCenterの仕様が異なり引き継ぎができなくなる不具合を直した際に、適切なテーブルのINDEXを貼り忘れていたことだった。『ガルパ』はリズムゲームであることから、iPhoneからiPadなど端末を切り替えてプレイするユーザーが想定以上に多かったと常山氏は語った。

想定外のところでアクセス障害が起きてしまったことから、今後は全体的・定期的に新機能追加のタイミングで負荷試験を実施する必要があると認識したという。また、負荷試験環境の準備で試験実施までに半日ほどかかっていたことから、定期的に実施するためには、より短時間で構築できるやり方を模索する必要があるとの反省を述べた。

ここからは高川氏が登壇し、5周年の負荷対策と結果、今後の展望について話を展開した。

●5周年の負荷試験対策と結果

5周年の際には「負荷試験環境の再構築」と「全体的に不安な箇所の負荷試験」を実施。3周年、4周年の際には、負荷試験をまともに実施できない状態だったからこそ、1番成功させなくてはいけない周年の際に失敗してしまったと振り返る。そこで、5周年ではプロジェクトとしても優先度を上げて対応することとなった。

負荷試験環境の再構築を行うにあたって、まずは使用する負荷試験ツールを以下の理由でJMeterからLocustに変更した。

▲他の大手スマホゲームでもLocustを使った事例やドキュメントが多かったことも決め手となった。

新しく構築する負荷試験環境は、ECS Fargate上にLocustを乗せるという形を採用。負荷を掛ける側もスケールアウトをする必要があるので、同じ内容のマシンを何台も簡単に増やすことができるコンテナサービスのECSを選択したと理由を説明した。これまでは負荷を掛ける側の環境を準備するのに半日以上を費やしていたが、今回ECSとLocustの環境を作ることによって数分で環境構築ができるようになり、かなり負荷試験の効率が上がったと述べた。

一方、負荷を掛けられる側の構成もコスト面で工夫を行ったという。今までは、EC2のオンデマンドインスタンスを使用していたが、新基盤では「スポットインスタンス」を採用した。

スポットインスタンスとは、一時的に使用できるインスタンスで、一定時間経過すると自動で返却されるものとなっており、コストが安いというメリットがある。コストについて高川氏は、以下のスライドは少し前に調べたもののため現在は数値が変わっているが、7割ほどのコスト減に成功したと結果を述べた。

▲負荷試験環境でのコストを削減するために、データベースを停止させて少しでもコストが浮くように節約もしたという。

次に、全体的に不安な箇所の負荷試験について。5周年に向けた負荷試験の目的として、「周年明けの瞬間的負荷を問題なく処理できるのか」という点が挙げられる。また、今回も5周年当日までに使えるコストと時間が多くなかったため、負荷試験の対象を以下の3つに限定して行った。

①ログインまでの手順

▲このログインまでの手順がシステムの中で最も多く実行され、重たい処理も大部分を占めているため優先度を上げて検証を行ったという。

②新規に追加する機能

▲手持ちの中から最強のデッキ編成を算出する「編成ランク」は、計算のロジックが複雑になっており、7バンド×4属性で28パターンも同じ計算を行う。ユーザーがガチャを引いたりレベルアップを行うことで再計算されるため、ゲーム全体として見てもかなり重たい処理を追加している。

③既存機能でボトルネックになりうる箇所

▲上記4点に関して問題がないかをチェックしていたところ、「発行数の多いクエリ」にボトルネックになりそうな箇所があったため調査を進めた。高川氏が気になったのはログイン処理のAPIの中身のクエリで、1回のログイン処理に対して全く同じ条件で同じテーブルに対して300～400回もクエリが発行されていた。DBコネクション数の枯渇に繋がるが、実行時間は短いため今回は対応せずに当日を迎えた。

そのほか、以下のような負荷対策を行ったことも併せて紹介した。

そうして迎えた5周年当日。2年間の失敗を乗り越えて無事に周年を迎えることができた。これにより、現状のシステム構成で瞬間的負荷を捌ける実績が生まれた。数字的な目安も分かり、システム的には5～6倍まで余裕があることが確認できたとのこと。

▲このグラフは、5周年のメンテナンス明け1秒間辺りのリクエスト数を示したもの。負荷試験を行ったときに想定していた数の5割程度に留まっていたという。

●6周年に向けて

6周年では、これまで以上に多種多様な機能を追加する超大型アップデートを予定しているため、大量のアクセス数が見込まれている。

まずは、パフォーマンス劣化の対処について。

▲グラフの横軸が年度、縦軸が平均レスポンスタイムとなっている。

上のグラフからは、年々レスポンスタイムが増えていることが分かる。この状態でリクエスト数が多くなるとマシンスペックを上げなければ耐えきれなくなってしまう可能性があるため、リファクタリングやデータの最適化などを行って減らしていきたいと述べた。

また、大型アップデートならではの新しい負荷要因にも対応しなければならないと高川氏は続ける。6周年は今まで以上に大量の機能を追加するため、新しいテーブルもかなり多めに追加していくという。周年リリース後、新しいテーブルに対してユーザーデータが新規に作成されるため、アクセスが集中すると想定以上の負荷がデータベースに掛かると予測している。そのため、メンテナンス中に既存ユーザーのデータを予め作成することによって少しでもデータベースの負荷を減らすという対策も検討していると話した。

●さらにその先の展望

最後に、6周年以降に対応していきたい箇所について。ここでは、特に運用負荷が肥大化している部分について話を展開した。

▲こちらのグラフは累計ダウンロード数を示しており、実際のユーザーゲームデータの数とは乖離があるという。恐らく99％はリセマラされた捨てアカウントで、ほぼ使われることがないデータで埋め尽くされている状態となっている。

データベースのデータ量もパフォーマンスに大きく影響するため、データベースに残しておくのではなく、S3などのストレージに退避させるなどしてデータベースに存在するデータ量を減らせるような体制・状態を作りたいと考えているという。

また、ユニットテストが遅すぎるという問題もある。全てのテストを1回実行するだけで30分を超える場合もあるため、必要なケースだけに絞っていきたいと対策を述べた。

最後に、まとめとして改めて本講演の内容を振り返った。

これまで、2回の失敗と成功を経て全体的に感じたことを発表して講演の締めとした。