Serverless Advent Calendar 2025 4日目の記事です。
Game Server Services(GS2) の話ですが、ゲームはなんなのか？というと大人の事情で何とはここでは書きづらいので、以下のページの情報を見て脳内で結合してください。
GS2 のアーキテクチャは以下で公開されています。
かなり古い内容ですので現在の構成とは若干異なる部分もありますが、大まかにはあっています。
ローンチの3ヶ月前から負荷テストを本格的に開始し、ゲームシステムの性質上サーバーへのアクセス数が多くなることを明確に予測できました。
更に、初動もかなり大きくなることが想定され、見積もった結果100万rps以上を捌ける状態でローンチを迎えなければならないことが予想されました。
当時のGS2は10万rpsを捌けるように各種緩和手続きを済ませていましたが、100万rpsオーバーとなると、さらなる緩和が必要であることは疑いようがありませんでした。
緩和手続き
初期の負荷テストの結果、新しく緩和が必要そうなコンポーネントは以下でした。
- API Gateway
- Lambda
- DynamoDB
- Firehose
API Gateway
GS2 では API Gateway のなかでも HTTP API と WebSocket を使用しています。
- リクエスト数/秒(HTTP API / WebSocket共通の項目)
- WebSocket の新規接続数/秒
の緩和が必要だったため、交渉を続けました。
しかし、リクエスト数/秒 はどれだけ交渉を続けても、いい返事をもらうことができず、最終的に HTTP API については ALB の Lambda統合 を利用するように設計から変更することにしました。
Lambda
こちらも交渉の末、10万同時実行までは緩和してもらえたのですが、これでは理論値が100万rpsで、余裕を持った構成にすることは難しかったです。
そこで、ECS + Fargate を利用して、一時的に Lambda で処理していた処理をコンテナに逃がせるようにすることで余裕を確保することにしました。
Fargate
というわけで、Fargate の vCPU 数の緩和です。
実はこれも難航しました。あとになってわかりましたが、ゲームがローンチした今年上半期は東京リージョン全体でインスタンスが枯渇する状態になりましたが、かなり在庫が逼迫していたようで、API Gateway にしても Lambda にしても、Fargate にしてもインスタンスが不足している中で緩和作業を進めるというのが難しかったようです。
EC2
というわけで、ECS on EC2 にすることにして、一旦 Lambda の代替となるキャパシティの確保ができました。
DynamoDB
なんの問題もなくスループットの引き上げができました。
Firehose
この子もなかなか難航し、結局ストリームを10分割をしてそれぞれの上限を引き下げることでなんとか緩和を通すことができました。
その後
Lambda で動くように作っていたコードを ECS で動くことを確認する。アクセスを API Gateway 経由で受け取るのではなく、ALB 経由でも受け取れるようにするといった細かな（細かくないよｗ）作業を行なってローンチ当日を迎えて、実際にピーク60万rpsを処理することができました。
その後、トラフィックが落ち着いてきたタイミングで ECS をなくして、Lambda だけにし、再びフルサーバーレス構成に戻し現在に至ります。
API Gateway(HTTP API) に関しては ALB のままの方がコストパフォーマンスが良さそうなので、そのままにしています。
おまけ
ゲームは日付変更のタイミングで全員がログアウトするため、いろんなデータをフェッチする関係でAPIリクエストがおおくなりがちなログイン処理が一斉に走り、ここが日常的なピークになります。
現在もこのタイミングだけは 10秒間に1000ランタイム起動 のコールドスタートのペースでは間に合わずにスロットリングしてしまうことがあるため、オートスケーリングを有効にした Provisioned Capacity で補っています。
さいごに
大規模なサーバーレスアプリケーションを運用した際にどこで緩和手続きが必要になり、それぞれコンポーネントの緩和のハードさのイメージを共有させていただきました。
ちなみに、同等の緩和をバージニアリージョンでも実施しましたが、Firehose / Lambda は東京リージョンよりは明らかに楽で、API Gateway は東京リージョンと似たような傾向を感じました。
Firehose / Lambda はEC2の在庫さえあれば緩和してもらいやすかったのかな？という印象です。
API Gateway では、トラフィック管理、CORS サポート、認可とアクセスコントロール、スロットリング、モニタリング、API バージョン管理など、最大数十万規模 の同時 API コールの受け入れと処理に伴うすべてのタスクを取り扱います。
API Gateway のランディングページ にも上記のような記述がありますし、そもそも 100万rps はサポート外ということなのでしょう。
結論としては、この規模をサーバーレスで捌くのは 2025年時点では事前にだいぶ調整しないと厳しいことがわかりました。少なくとも1年は余裕を持った方が良さそうで、それでも実現できるかはわかりません。
幸いにも移行コストが高い DynamoDB は余裕そうなので、トラフィックの上限が読みきれない場合はいざという時に API Gateway / Lambda / Firehose あたりのレイヤーは ALB / ECS / DataStream へと差し替えられる設計にしておくのが良さそうです。
免責
re:invent 2025 の内容を把握する前に記事を書いているので、発表内容によっては状況が変わっている可能性があります。