『呪術廻戦 ファントムパレード』の大規模アクセスを支えるインフラ構成と最適化【CAGC2024】

TVアニメ『呪術廻戦』初のスマホゲーム『呪術廻戦 ファントムパレード』は、多くのユーザーに遊ばれ大量のアクセスが来ることが予想されていました。
本セッションでは、高負荷が予想される中、どのようにインフラを構築し負荷対策を行ったのか、実際のインフラ構成図をお見せしながらお話しします。
また、アプリリリース前に行った負荷試験の流れや、リリース後の負荷状況について、具体的なメトリクスの数字をお見せしながらご紹介します。

https://cagc.cyberagent.co.jp/2024/session/index.html?id=tisydb2t59

©芥見下々／集英社・呪術廻戦製作委員会　©Sumzap, Inc.／TOHO CO., LTD.
Copyright © CyberAgent, Inc.

Transcript

1. 『呪術廻戦 ファントムパレード』の 大規模アクセスを支えるインフラ構成と最適化 1 SRE / 呪術廻戦 ファントムパレード 島田 裕基　Shimada Hiroki
2. 自己紹介 2 - 名前 - 島田 裕基（Shimada Hiroki） - 経歴 - 2012年新卒でサイバーエージェントに入社 - ゲーム事業にてさまざまなゲームの新規開発・運用・改善を担当 - 『呪術廻戦 ファントムパレード』 - SREとしてインフラの構築や負荷監視などに従事 - Cloudを駆使してアプリ実行基盤の構築とコスト管理などに責任を持つ
3. 3 『呪術廻戦 ファントムパレード』とは
4. 4 『呪術廻戦 ファントムパレードは、 2018年より「週刊少年ジャンプ」 （集英社）にて連載中の 芥見下々（あくたみげげ）氏による 人気漫画を原作としたTVアニメ 『呪術廻戦』を元にした、作品初の スマートフォンゲームです。 TVアニメ『呪術廻戦』の第1期の物語を 追体験できるだけでなく、福岡を舞台にした 『ファンパレ』オリジナルの ストーリーが楽しめる コマンドバトルRPGとなっています。
5. アジェンダ 5 - はじめに - インフラ構成 - 負荷試験 - リリース時の負荷状況 - リリース後の最適化 - まとめ
6. はじめに 6
7. 前提 7 11/21 リリース リリース前の負荷試験〜リリース後1ヶ月経過時点でのお話 引用元 : 『呪術廻戦 ファントムパレード（ファンパレ） 』公式X
8. ユーザ規模とアクセス負荷の見積もり 8 大人気タイトルとしての要件: 300万DAUに耐えうるインフラ 過去のタイトルの実績より APIサーバのRPS: 目標DAUの1.5%相当を目安 = 45,000RPS アセット配信: 最大DL bytes 400Gbps リリース2.5ヶ月前に 負荷試験で達成済み!!
9. ユーザ規模とアクセス負荷の見積もり 9 引用元 : 『呪術廻戦』公式X APIサーバのRPS: 45,000RPS 120,000RPS アセット配信 最大DL bytes: 400Gbps 6,000Gbps 障害リスクを最小限にする目的で大幅上方修正 引用元 : 『呪術廻戦』公式X リリース3週間前に変更!!
10. インフラ構成 10
11. 簡易的なインフラ構成図 11
12. インフラ構成の決定と特徴 12 - 弊社ではGCP, AWSそれぞれのCloud使用経験あり - ゲーム系で一番負荷問題になりうるDBリソースを何にするかで検討 - AWSのAurora Serverless v2の使用を検討 - ゲームサーバには弊社で利用実績のあるECS Fargateを使用 - ゲームAPIとお知らせAPIのエンドポイントを分けることで、 メンテナンス中でもお知らせを表示・更新できる仕様に - ゲームAPIの前段にCloud Frontを挟むことで、上り通信料の削減と地 域制限(日本のみ配信)を実現 - アセット配信にはCloud Front + S3構成を使用
13. - Amazon Auroraのサーバーレス版 - アプリケーションの需要に応じて自動的にスケールアップ/ダウンする - v1よりもスムーズなスケーリングが可能 - インスタンスクラスの1つとみなされるので、v1と異なり 同クラスター内でプロビジョニングDBと共存が可能 - ただしプロビジョニングDBよりも割高なので、負荷変動が少なかったり、 負荷予測が可能なアプリケーションは利用が適さない - ACU(Aurora Capacity Unit)という単位が使用され、0.5~128の範囲でス ケールされる Aurora Serverless v2とは 13
14. - リリース時の柔軟なスペック変更が可能 - DBのスペック変更にメンテナンスが必要なくなる - 深夜の低アクセス時に自動でスケールダウンが可能 - 予想外の負荷上昇時にスケールアウトが可能 - プロビジョニングDBと共存が可能なので、なにか問題があった際も、 フェイルオーバーで入れ替えが可能 Aurora Serverless v2を選択した理由 14
15. ECS Fargateとは 15 Amazon Elastic Container Service (ECS) で動作するサーバレスな コンテナ実行環境 コンテナを実行するホスト(クラスター)の管理が不要 コンテナ コンテナ ホスト1 コンテナ コンテナ ホスト1 コンテナ ホスト2 コンテナ [スケーリング動作]
16. Fargate Spot 16 AWS re:Invent 2019で発表された Fargate Spot - EC2スポットインスタンスのFargate版 - 共用の空きキャパシティを使用することで通常の30%の価格で使用可能 - クラスターにCapacity Providerの概念が追加
 Base Weight Fargete 5 1 Fargate Spot 0 4 合計タスク数 5 6 10 25 26 27 28 29 30 Fargete 5 5 5 5 5 5 5 5 6 Fargate Spot 0 1 5 20 21 22 23 24 24 [キャパシティープロバイダーの動作]
17. 負荷試験 17
18. 負荷試験で確認する箇所 18 ① ② ※ アセット部の負荷試験に関しては、基盤部分で他タイトルの運用実績があるので、今回はスキップ
19. 負荷試験流れ 19 1. 目標値の設定(45,000RPS -> 120,000RPS) 2. ①(ECS Fargate)の単体での限界値測定 3. ②(Aurora Serverless v2)の単体での限界値測定 4. 2,3をスケールアップ限界まで測定 5. 2,3,4を繰り返し、アプリケーションコードのエラー・遅い処理・ データ量が多い処理・Slowqueryなどを潰す 6. ①②を目標値に届くまでスケールアウト
20. ECS Fargate単体での限界値測定 20 - ECS Fargete以外のリソースは計測に影響がないくらい十分に大きいも のを使用 - ECS FargateのCPU使用率80%を超える負荷を限界点とする - 運用時は倍のアクセスが一時的に来ても耐えられるようにCPU使用率 40%を目安として計算する = 限界RPSの1/2 CPU(vCPU) Memory(GB) 限界RPS 運用RPS 2 8 40 20 4 8 90 45 8 16 200 100 16 32 450 225 [試験結果] サイズが大きい方が若干だが パフォーマンスが出ることが 分かったので 16vCPUで運用する
21. Aurora Serverless v2単体での限界値測定 21 - Aurora以外のリソースは計測に影響がないくらい十分に大きいものを 使用 - ACUはServerless v2の最大値128を固定で使用 - AuroraのCPU使用率65%を超える負荷を限界点とする [試験結果] 分割数 ACU QPS 限界RPS 1 128 105,833 3,800 2 128 211,667 7,500 4 128 428,000 15,000 8 128 846,667 30,000 16 128 2,933,333 75,000 32 128 5,760,000 150,000 ※ リリース前にシナリオが 固定しきらなかった影響で 分割数に対してスペックが 倍々になっていない
22. 負荷試験の結果 22 - 45,000RPSという当初の目標に対してのスペック - ECS Fargate 16vCPU: 45,000 / 225 = 200タスク - Aurora Serverless v2 128ACU: 16クラスター - 120,000RPSという変更後の目標に対してのスペック - ECS Fargate 16vCPU: 120,000 / 225 = 534タスク - Aurora Serverless v2 128ACU: 32クラスター ※ ただし、ECS Fargeteに関しての必要数は、 デプロイにBlue-Greenを採用していたので、2倍の1068タスク必要となる
23. リリース時の負荷状況 23
24. API部の主要メトリクス - ALB 24 Game API ピークトラフィック 11/21 21:57 〜 17,103RPS (120,000RPS までALB事前暖気を申請) ※ リリースから24時間経過時のメトリクス
25. アセット部の主要メトリクス 25 Cloud Front Asset Request ピークトラフィック 11/21 12:10 〜 530,000RPS (4,000,000RPS まで緩和を実施) Asset Download ピークトラフィック 11/21 12:10 〜 670Gbps (6,000Gbps まで緩和を実施) ※ リリースから12時間経過時のメトリクス
26. リソースの主要メトリクス ECS Fargate タスク数: 1000タスク CPU使用率5%未満 Aurora ACU: 128 クラスター数: 32 CPU使用率10%未満 26 ※ リリースから12時間経過時のメトリクス
27. リリース時の負荷状況 27 - 実際の負荷は負荷試験目標値の1/7 程度 - かなりしっかり負荷試験を行えたので、負荷による不具合はなし - ただしリソースがオーバースペックなためインフラコストが大 - リリース後の対応として、コスト削減が早急に求められる APIサーバのRPS: 120,000RPS 17,103RPS アセット配信 最大DL bytes: 6000Gbps 670Gbps
28. リリース後の最適化 28
29. 最適化の優先順位 29 まずは前提として闇雲に手を付けず、効果の大きいものから対応をする 全体コストの8割はDB, 1割がECSということが分かる コスト
30. DBの最適化 30 コストインパクトの大きいDBの削減から最適化を行う プロビジョニングDBの場合メンテを入れないとスケールダウンが行えないが、 Serverless v2を使用していることで、ノーメンテナンスで最適化可能 Min ACUを128 -> 16まで段階的に下げた [対応内容] ※ 3回目の最適化タイミングでMax値も上げたため相対的なCPU使用率が下がって見えていることに注意 Min値を下げても CPU使用率が低いため、 これ以上の最適化には クラスター統合が必要と 判断
31. ECSの最適化 31 次にコストインパクトの大きいECS Fargateの削減を行う 単純なタスク数の削減の他にオンデマンドとSpotの割合の変更も行っている [対応内容] タスク数を1000 -> 150まで段階的に減らした
32. 最適化の効果 32 リリースから24時間以内に最適化対応が行えた それによりDB・ECS、そして全体でも1/5程度のコストに落とすことができた コスト
33. まとめ 33
34. まとめ 34 今回は『呪術廻戦 ファントムパレード』のリリース前負荷試験から、 リリース後の初期インフラ最適化までの話をしてきました APIサーバのRPS: 120,000RPS アセット配信 最大DL bytes: 6,000Gbps [インフラ目標値] [負荷試験実績] ECS Fargate 16vCPU: 1068タスク Aurora Serverless v2 128ACU: 32クラスター [リリース実績] APIサーバのRPS: 17,103RPS アセット配信 最大DL bytes: 670Gbps
35. まとめ 35 負荷の値が目標値までいかなかった要因としては、昔と比べクライアントに 処理を持たせることで、通信頻度を大幅に減少させられたことが大きいです とはいえリリース時はどれほどのアクセスになるのかを予想することは難しく、 むしろ余剰リソースをどれだけ早く削れるかが求められています 今回採用した 「ECS Fargate」と「Aurora Serverless v2」は、 全体の処理を止めることなくスケールを行うことができ、 コストをリリースから24時間以内に1/5まで削減することができました
36. 36 ご清聴ありがとうございました ©芥見下々／集英社・呪術廻戦製作委員会　 ©Sumzap, Inc.／TOHO CO., LTD.