「魔法少女まどか☆マギカ Magia Exedra」におけるバックエンドの技術選定

GREE Tech Conference 2025で発表された資料です。
https://techcon.gree.jp/2025/session/TrackB-5

Transcript

1. 「魔法少女まどか☆マギカ Magia Exedra」における バックエンドの技術選定 株式会社WFS エンジニア 清水稔貴 1
2. 清水 稔貴 経歴 23/4~ : 新卒入社 23/4 ~ :『SINoALICE』 23/11 ~ :『アサルトリリィ Last Bullet』 24/10 ~ :『魔法少女まどか☆マギカ Magia Exedra』 株式会社WFS サーバーエンジニア 2
3. ©2024 Magica Quartet/Aniplex,Magia Exedra Project ©WFS 3
4. ©WFS 『魔法少女まどか☆マギカ』シリーズ歴代のシナリオや世界観を追体験！
 歴代の魔法少女たちとともに記憶の光を集めながら魔女結界を探索していく
 ©2024 Magica Quartet/Aniplex,Magia Exedra Project 4
5. 本講演について • 「魔法少女まどか☆マギカ Magia Exedra」ではGoogle Cloudを採用 ◦ ポケラボブランドでは初 ◦ 2025/3 国内・海外同時リリース • Google Cloudの採用背景について • 対応内容について • 過去運用タイトルに比べて、運用・費用のコストはどう変わったか 5
6. サーバー構成 6
7. 7 技術選定する理由 なぜするの？
8. 8 技術選定する理由 コストの抑制 コスト = サーバー費用, 人, 運用, 開発...etc
9. 9 技術選定する理由 コスト = サーバー費用, 人, 運用, 開発...etc 運用できるの？ 開発できるの？ 性能は問題ない？ コストの抑制
10. Google Cloud採用背景① - 前提ときっかけ • 技術選定時は「株式会社ポケラボ」 ◦ 2025/1に「株式会社WFS」と統合 ◦ 今まではGoogle Cloud以外のサービスを用いていた • 当時WFS内でGoogle Cloud採用のプロダクトが増加 ◦ 運用実績のあるプロダクトを参考にできる ◦ 「今までのサービス」 or 「Google Cloud」 10
11. Google Cloud採用背景② - 抑制したいコスト 11 • 過去プロダクトにおける、DB(MySQL)コストの問題 サーバー費用 • サーバー費用全体の大部分を占める • ポケラボはGvGのプロダクトが多い ◦ リアルタイムバトルが売り ◦ バトル用のDBを別で用意
12. Google Cloud採用背景② - 抑制したいコスト 12 運用(人的)コスト • DBのスペック変更 ◦ メンテナンス必須 ◦ インフラチームとの連携 • シャーディング(水平分散)が必須 ◦ パフォーマンス向上のため ◦ スケールインが大変 サーバー費用 • サーバー費用全体の大部分を占める • ポケラボはGvGのプロダクトが多い ◦ リアルタイムバトルが売り ◦ バトル用のDBを別で用意 • 過去プロダクトにおける、DB(MySQL)コストの問題
13. 13 Cloud Spannerを選定 Google Cloud採用背景② - DBコストの解決策
14. Google Cloud採用背景② - Could Spannerの魅力 • 簡単なスケーリング ◦ CPUやメモリ、ストレージの増減 ▪ ノード数の増減(ワンクリック or 自動)で実現 ▪ ダウンタイムなし ◦ シャーディング ▪ トラフィック変化に応じて自動で行う(スプリット分割) 14 node1 node2 nodeX
15. Google Cloud採用背景② - 抑制したいコスト 15 • 過去プロダクトにおける、DB(MySQL)コストの問題 サーバー費用 • サーバー費用全体の大部分を占める • ポケラボはGvGのプロダクトが多い ◦ リアルタイムバトルが売り ◦ バトル用のDBを別で用意 運用(人的)コスト • DBのスペック変更 ◦ メンテナンス必須 ◦ インフラチームとの連携 • シャーディング(水平分散)が必須 ◦ パフォーマンス向上のため ◦ スケールインが大変
16. サーバー費用 • サーバー費用全体の大部分を占める • ポケラボはGvGのプロダクトが多い ◦ リアルタイムバトルが売り ◦ バトル用のDBを別で用意 運用(人的)コスト • DBのスペック変更 ◦ メンテナンス必須 ◦ インフラチームとの連携 • シャーディング(水平分散)が必須 ◦ パフォーマンス向上のため ◦ スケールインが大変 Google Cloud採用背景② - 抑制したいコスト 16 • 過去プロダクトにおける、DB(MySQL)コストの問題 大幅削減
17. サーバー費用 • サーバー費用全体の大部分を占める • ポケラボはGvGのプロダクトが多い ◦ リアルタイムバトルが売り ◦ バトル用のDBを別で用意 Google Cloud採用背景② - 抑制したいコスト 17 • 過去プロダクトにおける、DB(MySQL)コストの問題 無駄を抑える 運用(人的)コスト • DBのスペック変更 ◦ メンテナンス必須 ◦ インフラチームとの連携 • シャーディング(水平分散)が必須 ◦ パフォーマンス向上のため ◦ スケールインが大変 大幅削減
18. 18 WFS内の導入実績 + Cloud Spannerによるコスト抑制見込み Google Cloud採用をした理由
19. 19 技術選定する理由 コスト = サーバー費用, 人, 運用, 開発...etc 運用できるの？ 開発できるの？ 性能は問題ない？ → WFS内の導入実績 コストの抑制
20. 20 技術選定する理由 コスト = サーバー費用, 人, 運用, 開発...etc 運用できるの？ 開発できるの？ 性能は問題ない？ → WFS内の導入実績 コストの抑制
21. 21 性能面 • 「内製ライブラリ + Cloud Spanner 」 で問題なく動作するか 開発面 • ポケラボ内製ライブラリの改修 ◦ 長年の運用実績 ◦ Cloud Spanner用に改修 Cloud Spannerを導入するにあたっての課題
22. 22 性能面 • 「内製ライブラリ + Cloud Spanner 」 で問題なく動作するか 　　→ 改修後に性能試験を実施 開発面 • ポケラボ内製ライブラリの改修 ◦ 長年の運用実績 ◦ Cloud Spanner用に改修 　　→ Cloud Spanner特有の問題 Cloud Spannerを導入するにあたっての課題
23. • ホットスポット ◦ あるスプリットにアクセスが集中し、パフォーマンスが低下 ◦ スプリットは連続したキーの範囲で作成される • シーケンシャルなキーを用いると起きやすい 23 内製ライブラリの改修 - spanner特有の問題 pk=1~100 table A (shard1) pk=101~200 ・・・ pk=1001~1100 table A (shard2) table A (shard10)
24. • ホットスポット ◦ あるスプリットにアクセスが集中し、パフォーマンスが低下 ◦ スプリットは連続したキーの範囲で作成される • シーケンシャルなキーを用いると起きやすい ◦ 例) pk=101~200が頻繁に読み書きされる→shard2にアクセスが集中 24 内製ライブラリの改修 - spanner特有の問題 pk=1~100 table A (shard1) pk=101~200 ・・・ pk=1001~1100 table A (shard2) table A (shard10)
25. • pkにAUTO_INCREMENTを用いているテーブル ◦ ある程度の桁数の数値でランダム生成 • ユーザーに紐づくテーブル ◦ userId + マスタIDの複合キーをpkとする ◦ 例) ユーザーが所持しているキャラクターのデータ → userId + characterId • マスタテーブル ◦ pkとなるIDは、マスタを作成しているプランナーが決めている ◦ app pod(アプリサーバー)起動時に一括で取得してサーバーキャッシュに載せる 25 内製ライブラリの改修 - ホットスポット対応
26. 性能検証 - 概要 • 性能検証のため負荷試験を実施 ◦ 内製ライブラリ + Cloud Spannerの性能調査 ◦ 改修したライブラリの動作確認 • リリース時のログインラッシュを想定したシナリオを用意 ◦ ログイン→プレゼント受け取り→各種ユーザーデータ取得→ガチャorクエスト周回 26
27. 性能検証 - 目標設定 • 過去プロダクトを参考に目標値を設定 • シナリオ作成にはJMeterを使用 ◦ モニタリング: Grafana ◦ ログ調査: Cloud Logging 27 項目 RPS レスポンスタイム エラー率 目標値 15,000 Req/Sec p90: 300ms未満 p95: 400ms未満 < 0.01% (アプリ側のerror含む)
28. 性能検証 - 手順 1. 1 pod, 1 ノードで捌けるRPS数を調査 ◦ podのCPU使用率が60%になるように、VMインスタンスも調整 2. 目標RPSに対してのpod数を試算 ◦ 目標値(1.5万) / 手順1でのRPS 3. 少しずつRPSとpod数を増やして、ノード数を調整 28
29. 性能検証 - 結果 29 • 概ね目標値クリア ◦ GKEノードプールのマシンタイプ: c2-standard-16 ◦ app pod数: 140 (8 vCPU, 12Gi) • 加えて、検証過程で多く出ていたCloud Spannerのエラー対応 RPS spanner ノード数 レスポンスタイム エラー率 1.66万 35 p90: 376ms p95: 400ms 0.0002%
30. 性能検証 - Transaction was aborted 30 • トランザクション間の競合によるエラー ◦ エラー件数: 480件 / 1000万 req ◦ 整合性のための排他制御故に、発生してしまうのは仕方がない • 1つのトランザクションで複数テーブルにアクセスする時に起きやすい ◦ 独自実装した処理 ◦ ライブラリのsingle-useでは発生しない → リトライが仕込まれていた • 独自の実装にもリトライを仕込む ◦ エラー件数: 480 → 12件まで減少
31. 性能検証 - ホットスポットの監視 • Key Visualizer ◦ 横軸 = 時間 ◦ 縦軸 = テーブルのキー(降順) • 色 = リソース使用の度合い ◦ 白くなればなるほどCPUを使用 • 問題となるようなテーブルは1件 ◦ pkのprefixが同じだった 31 Key Visualizerのヒートマップ例
32. 32 技術選定する理由 コスト = サーバー費用, 人, 運用, 開発...etc 運用できるの？ 開発できるの？ 性能は問題ない？ → グループ内の導入実績 → 内製ライブラリ改修 → 性能試験 コストの抑制
33. • 運用コストは激減 ◦ メンテナンスなし、サーバーエンジニアのみでDBスペック変更可能 ◦ シャーディングのスケールイン/アウトの手間もなくなった ▪ ホットスポットに注意 • 通常は少なめのノード数、施策リリース直前にあらかじめ増やす運用 ◦ 急激なアクセス増加への対応 ◦ 過去プロダクトではやりにくかったこと ◦ 施策リリースもメンテナンスなし • リリース初期から目立った障害なし 33 実績 - 運用
34. • DB費用が約2~3割減 ◦ 過去の運営タイトルのリリース後~6ヶ月の費用と比較 ▪ ソロ主体のタイトル ▪ ユーザー規模は異なるため参考値 • まどドラの方がユーザー数は多い • リリース時から比べてDB賃借料は7割まで減 ◦ 負荷を日々調査して少しずつスペックを下げる(メンテナンスなし) ◦ リリース1ヶ月後には半分ほどに削減 34 実績 - 費用
35. • 国内/海外ともに1リージョンで運用(東京リージョン) ◦ 国内に比べてレイテンシは悪化するが問題ないレベル ◦ 運用コスト抑制に繋がった ▪ 海外用にpodを配置する必要がない → デプロイコスト削減 ▪ Cloud Spannerも1インスタンスで運用 → ノードの設定も共通 • Cloud Logging, Cloud Monitoringなどの活用できるサービスが多い ◦ 何も設定しなくても、GKEのpodのログが自動的に送信 35 その他の利点
36. • Cloud SpannerによるDBコスト抑制のため、Google Cloudを採用 ◦ きっかけはWFS内での採用実績 ◦ サーバー費用と人的コストの問題を解決できる見込み • Cloud Spanner移行のため、内製ライブラリの改修と性能試験を実行 ◦ ポケラボ内製ライブラリをCloud Spanner用に対応 ◦ 内製ライブラリ + Cloud Spannerの負荷試験 • 運用コストは激減。費用も減。 ◦ 安定した稼働も続けられている！ 36 まとめ
37. ご清聴ありがとうございました 37