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

by CyberAgent

Slide 1

Slide 1 text

『呪術廻戦ファントムパレード』の大規模アクセスを支えるインフラ構成と最適化 1 SRE / 呪術廻戦ファントムパレード島田裕基　Shimada Hiroki

Slide 2

Slide 2 text

自己紹介 2 - 名前 - 島田裕基（Shimada Hiroki） - 経歴 - 2012年新卒でサイバーエージェントに入社 - ゲーム事業にてさまざまなゲームの新規開発・運用・改善を担当 - 『呪術廻戦ファントムパレード』 - SREとしてインフラの構築や負荷監視などに従事 - Cloudを駆使してアプリ実行基盤の構築とコスト管理などに責任を持つ

Slide 3

Slide 3 text

3 『呪術廻戦ファントムパレード』とは

Slide 4

Slide 4 text

4 『呪術廻戦ファントムパレードは、 2018年より「週刊少年ジャンプ」（集英社）にて連載中の芥見下々（あくたみげげ）氏による人気漫画を原作としたTVアニメ『呪術廻戦』を元にした、作品初のスマートフォンゲームです。 TVアニメ『呪術廻戦』の第1期の物語を追体験できるだけでなく、福岡を舞台にした『ファンパレ』オリジナルのストーリーが楽しめるコマンドバトルRPGとなっています。

Slide 5

Slide 5 text

アジェンダ 5 - はじめに - インフラ構成 - 負荷試験 - リリース時の負荷状況 - リリース後の最適化 - まとめ

Slide 6

Slide 6 text

はじめに 6

Slide 7

Slide 7 text

前提 7 11/21 リリースリリース前の負荷試験〜リリース後1ヶ月経過時点でのお話引用元 : 『呪術廻戦ファントムパレード（ファンパレ）』公式X

Slide 8

Slide 8 text

ユーザ規模とアクセス負荷の見積もり 8 大人気タイトルとしての要件: 300万DAUに耐えうるインフラ過去のタイトルの実績より APIサーバのRPS: 目標DAUの1.5%相当を目安 = 45,000RPS アセット配信: 最大DL bytes 400Gbps リリース2.5ヶ月前に負荷試験で達成済み!!

Slide 9

Slide 9 text

ユーザ規模とアクセス負荷の見積もり 9 引用元 : 『呪術廻戦』公式X APIサーバのRPS: 45,000RPS 120,000RPS アセット配信最大DL bytes: 400Gbps 6,000Gbps 障害リスクを最小限にする目的で大幅上方修正引用元 : 『呪術廻戦』公式X リリース3週間前に変更!!

Slide 10

Slide 10 text

インフラ構成 10

Slide 11

Slide 11 text

簡易的なインフラ構成図 11

Slide 12

Slide 12 text

インフラ構成の決定と特徴 12 - 弊社ではGCP, AWSそれぞれのCloud使用経験あり - ゲーム系で一番負荷問題になりうるDBリソースを何にするかで検討 - AWSのAurora Serverless v2の使用を検討 - ゲームサーバには弊社で利用実績のあるECS Fargateを使用 - ゲームAPIとお知らせAPIのエンドポイントを分けることで、メンテナンス中でもお知らせを表示・更新できる仕様に - ゲームAPIの前段にCloud Frontを挟むことで、上り通信料の削減と地域制限(日本のみ配信)を実現 - アセット配信にはCloud Front + S3構成を使用

Slide 13

Slide 13 text

- Amazon Auroraのサーバーレス版 - アプリケーションの需要に応じて自動的にスケールアップ/ダウンする - v1よりもスムーズなスケーリングが可能 - インスタンスクラスの1つとみなされるので、v1と異なり同クラスター内でプロビジョニングDBと共存が可能 - ただしプロビジョニングDBよりも割高なので、負荷変動が少なかったり、負荷予測が可能なアプリケーションは利用が適さない - ACU(Aurora Capacity Unit)という単位が使用され、0.5~128の範囲でスケールされる Aurora Serverless v2とは 13

Slide 14

Slide 14 text

- リリース時の柔軟なスペック変更が可能 - DBのスペック変更にメンテナンスが必要なくなる - 深夜の低アクセス時に自動でスケールダウンが可能 - 予想外の負荷上昇時にスケールアウトが可能 - プロビジョニングDBと共存が可能なので、なにか問題があった際も、フェイルオーバーで入れ替えが可能 Aurora Serverless v2を選択した理由 14

Slide 15

Slide 15 text

ECS Fargateとは 15 Amazon Elastic Container Service (ECS) で動作するサーバレスなコンテナ実行環境コンテナを実行するホスト(クラスター)の管理が不要コンテナコンテナホスト1 コンテナコンテナホスト1 コンテナホスト2 コンテナ [スケーリング動作]

Slide 16

Slide 16 text

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 [キャパシティープロバイダーの動作]

Slide 17

Slide 17 text

負荷試験 17

Slide 18

Slide 18 text

負荷試験で確認する箇所 18 ① ② ※ アセット部の負荷試験に関しては、基盤部分で他タイトルの運用実績があるので、今回はスキップ

Slide 19

Slide 19 text

負荷試験流れ 19 1. 目標値の設定(45,000RPS -> 120,000RPS) 2. ①(ECS Fargate)の単体での限界値測定 3. ②(Aurora Serverless v2)の単体での限界値測定 4. 2,3をスケールアップ限界まで測定 5. 2,3,4を繰り返し、アプリケーションコードのエラー・遅い処理・データ量が多い処理・Slowqueryなどを潰す 6. ①②を目標値に届くまでスケールアウト

Slide 20

Slide 20 text

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で運用する

Slide 21

Slide 21 text

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 ※ リリース前にシナリオが固定しきらなかった影響で分割数に対してスペックが倍々になっていない

Slide 22

Slide 22 text

負荷試験の結果 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タスク必要となる

Slide 23

Slide 23 text

リリース時の負荷状況 23

Slide 24

Slide 24 text

API部の主要メトリクス - ALB 24 Game API ピークトラフィック 11/21 21:57 〜 17,103RPS (120,000RPS までALB事前暖気を申請) ※ リリースから24時間経過時のメトリクス

Slide 25

Slide 25 text

アセット部の主要メトリクス 25 Cloud Front Asset Request ピークトラフィック 11/21 12:10 〜 530,000RPS (4,000,000RPS まで緩和を実施) Asset Download ピークトラフィック 11/21 12:10 〜 670Gbps (6,000Gbps まで緩和を実施) ※ リリースから12時間経過時のメトリクス

Slide 26

Slide 26 text

リソースの主要メトリクス ECS Fargate タスク数: 1000タスク CPU使用率5%未満 Aurora ACU: 128 クラスター数: 32 CPU使用率10%未満 26 ※ リリースから12時間経過時のメトリクス

Slide 27

Slide 27 text

リリース時の負荷状況 27 - 実際の負荷は負荷試験目標値の1/7 程度 - かなりしっかり負荷試験を行えたので、負荷による不具合はなし - ただしリソースがオーバースペックなためインフラコストが大 - リリース後の対応として、コスト削減が早急に求められる APIサーバのRPS: 120,000RPS 17,103RPS アセット配信最大DL bytes: 6000Gbps 670Gbps

Slide 28

Slide 28 text

リリース後の最適化 28

Slide 29

Slide 29 text

最適化の優先順位 29 まずは前提として闇雲に手を付けず、効果の大きいものから対応をする全体コストの8割はDB, 1割がECSということが分かるコスト

Slide 30

Slide 30 text

DBの最適化 30 コストインパクトの大きいDBの削減から最適化を行うプロビジョニングDBの場合メンテを入れないとスケールダウンが行えないが、 Serverless v2を使用していることで、ノーメンテナンスで最適化可能 Min ACUを128 -> 16まで段階的に下げた [対応内容] ※ 3回目の最適化タイミングでMax値も上げたため相対的なCPU使用率が下がって見えていることに注意 Min値を下げても CPU使用率が低いため、これ以上の最適化にはクラスター統合が必要と判断

Slide 31

Slide 31 text

ECSの最適化 31 次にコストインパクトの大きいECS Fargateの削減を行う単純なタスク数の削減の他にオンデマンドとSpotの割合の変更も行っている [対応内容] タスク数を1000 -> 150まで段階的に減らした

Slide 32

Slide 32 text

最適化の効果 32 リリースから24時間以内に最適化対応が行えたそれによりDB・ECS、そして全体でも1/5程度のコストに落とすことができたコスト

Slide 33

Slide 33 text

まとめ 33

Slide 34

Slide 34 text

まとめ 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

Slide 35

Slide 35 text

まとめ 35 負荷の値が目標値までいかなかった要因としては、昔と比べクライアントに処理を持たせることで、通信頻度を大幅に減少させられたことが大きいですとはいえリリース時はどれほどのアクセスになるのかを予想することは難しく、むしろ余剰リソースをどれだけ早く削れるかが求められています今回採用した「ECS Fargate」と「Aurora Serverless v2」は、全体の処理を止めることなくスケールを行うことができ、コストをリリースから24時間以内に1/5まで削減することができました