【セッションレポート】 「魔法少女まどか☆マギカ Magia Exedra」での負荷試験の実践と学び #CEDEC2025

【セッションレポート】 「魔法少女まどか☆マギカ Magia Exedra」での負荷試験の実践と学び #CEDEC2025

『魔法少女まどか☆マギカ Magia Exedra』において、GKE・Spanner・Memcached・PHP 構成で 40,000 RPS の負荷試験を実施した事例が紹介されたセッションレポートです。Memcached のコネクション枯渇や Spanner のトランザクション競合など、実際に顕在化した問題への対応策や、国内外同時リリースに備えた構成・検証方法について解説されました。

登壇者: 悦田 潤哉 (株式会社WFS)
日時: 2025 年 7 月 24 日 (木) 18:00 ~ 18:25
会場: CEDEC2025 第 8 会場
カテゴリ: ENG (エンジニアリング) | ショートセッション | 公募

概要

本セッションでは、WFS による大規模ソーシャルゲーム開発における負荷試験の実例が紹介されました。対象となったのは、国内外同時リリースを前提とした新作ゲーム『魔法少女まどか☆マギカ Magia Exedra』です。GKE (Google Kubernetes Engine) 、Cloud Spanner 、Memorystore for Memcached 、PHP という構成で構築されたサーバー環境に対して、 最大40,000 RPS (リクエスト/秒) の負荷を jmeter で再現した検証事例が語られました。

単にリクエスト数を稼ぐだけでなく、試験中に浮き彫りになったボトルネック (Memcached のコネクション枯渇、Spanner のトランザクション失敗、kube-dns のスケール不足など) とその解決策、さらにはグローバル展開を想定した負荷分散設計や再現手法など、実践的な知見に富む内容でした。次節以降では、試験の目的、顕在化した課題とその対処、そしてセッションを通じた学びについて順に振り返ります。

負荷試験の目的

『魔法少女まどか☆マギカ Magia Exedra』はリッチな演出を特徴とする大規模ソーシャルゲームであり、国内外を同時に対象としたリリースを控えていました。こうした環境下では、事前に高い同時接続数や大量トラフィックを想定し、システムがスケーラビリティと持続性の両面で十分な耐性を持つかを検証する必要がありました。

セッションでは、特に以下の 4 つの観点が負荷試験の主な目的として挙げられました。

  1. 性能評価: GKE 上に構築された PHP アプリケーションと Spanner の間で、想定トラフィック下でも安定して処理が行えるか
  2. 運用の持続性: 想定を超えるリクエストが継続的に流入した場合にも、インフラや DNS 解決基盤 (例:kube-dns) が破綻しないか
  3. ログの完全性: 高負荷下でも各種ログが欠損せず取得できるか。エラーハンドリングや監視精度への影響も検証ポイント
  4. グローバル同時接続の再現: 海外からのアクセスを模擬することで、ネットワークレイヤーやリクエスト分布に起因する遅延・輻輳へ備える

特に「短期的なピーク耐性」だけでなく、「中長期の運用を見据えた構造的な強度評価」が意識されていた点が印象的でした。

試験中に顕在化した問題とその解決策

40,000 RPS を目標とした負荷試験の過程では、システムの複数レイヤーにおいてさまざまな課題が浮き彫りになりました。セッションではそれらの課題を、「性能評価における問題」と「運用・オペレーション上の問題」に分けて整理し、対応策とともに紹介していました。

性能評価における課題

  • Memcached のコネクション枯渇
    大量の同時接続により、Memorystore for Memcached のコネクションリミットに達するケースが発生。コネクションプールの最適化とスケーリング戦略の見直しにより対応しました。
  • Spanner でのデータ取得失敗
    高頻度のリクエストにより、Spanner のトランザクションがアボートする事象が多発。特に絶対値での更新が衝突の原因となっていたため、相対値での更新ロジックへ変更することでトランザクションの成功率を向上させました。
  • APC キャッシュのミス率増加
    Pod 起動直後に APCu キャッシュのヒット率が極端に低下し、初期の応答性能が著しく悪化。これに対しては、ウォームアップ処理の導入やキャッシュプリロードの工夫が講じられました。

運用・オペレーション上の課題

  • kube-dns のスケール不足
    多数のコンテナが並列に起動する状況下で、DNS クエリが集中し、名前解決に時間がかかる問題が発生。CoreDNS への移行や AutoScaler の設定見直しを通じて、DNS レイヤーのスケーラビリティを確保しました。
  • ログ欠損のリスク
    高負荷時にログ収集コンポーネントがボトルネックとなり、一部のログが欠落するケースが見られました。バッファサイズの調整や非同期処理の導入が検討されました。

こうした課題は、いずれもサービスイン後に発生すれば致命的な障害となりかねないものでしたが、負荷試験の段階で抽出・対処できたこと自体が、大きな成果であるといえるでしょう。

まとめ

本セッションを通じて印象的だったのは、「とにかく高い負荷をかける」ことを目的とせず、サービス提供時の現実的な運用リスクを可視化するための負荷試験として丁寧に設計されていた点です。構成要素ごとに課題を切り分け、Memcached や Spanner といったミドルウェアの特性に応じた対策を講じていた様子は、単なるベンチマークを超えた運用試験としての深みを感じました。

DNS 解決やログ収集といった 地味ではあるが確実にトラブルになりやすい部分にもきちんと目を向け、事前に課題を洗い出す姿勢は、大規模なソーシャルゲーム開発に関わるエンジニアにとって重要なものといえるでしょう。

国内外同時リリースという高い要求水準に対し、実戦的かつ綿密な検証を通じてシステムの信頼性を担保したプロセスは、タイトルのクオリティを裏で支える「縁の下の力持ち」としての技術力を示すものでした。

この記事をシェアする

facebookのロゴhatenaのロゴtwitterのロゴ

© Classmethod, Inc. All rights reserved.