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

by gree_tech

Embed

Start on current slide

Slide 1

Slide 1 text

「魔法少女まどか☆マギカ Magia Exedra」におけるバックエンドの技術選定株式会社WFS エンジニア清水稔貴 1

Slide 2

Slide 2 text

清水稔貴経歴 23/4~ : 新卒入社 23/4 ~ :『SINoALICE』 23/11 ~ :『アサルトリリィ Last Bullet』 24/10 ~ :『魔法少女まどか☆マギカ Magia Exedra』株式会社WFS サーバーエンジニア 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

本講演について ● 「魔法少女まどか☆マギカ Magia Exedra」ではGoogle Cloudを採用 ○ ポケラボブランドでは初 ○ 2025/3 国内・海外同時リリース ● Google Cloudの採用背景について ● 対応内容について ● 過去運用タイトルに比べて、運用・費用のコストはどう変わったか 5

Slide 6

Slide 6 text

サーバー構成 6

Slide 7

Slide 7 text

7 技術選定する理由なぜするの？

Slide 8

Slide 8 text

8 技術選定する理由コストの抑制コスト = サーバー費用, 人, 運用, 開発...etc

Slide 9

Slide 9 text

9 技術選定する理由コスト = サーバー費用, 人, 運用, 開発...etc 運用できるの？開発できるの？性能は問題ない？コストの抑制

Slide 10

Slide 10 text

Google Cloud採用背景① - 前提ときっかけ ● 技術選定時は「株式会社ポケラボ」 ○ 2025/1に「株式会社WFS」と統合 ○ 今まではGoogle Cloud以外のサービスを用いていた ● 当時WFS内でGoogle Cloud採用のプロダクトが増加 ○ 運用実績のあるプロダクトを参考にできる ○ 「今までのサービス」 or 「Google Cloud」 10

Slide 11

Slide 11 text

Google Cloud採用背景② - 抑制したいコスト 11 ● 過去プロダクトにおける、DB(MySQL)コストの問題サーバー費用 ● サーバー費用全体の大部分を占める ● ポケラボはGvGのプロダクトが多い ○ リアルタイムバトルが売り ○ バトル用のDBを別で用意

Slide 12

Slide 12 text

Google Cloud採用背景② - 抑制したいコスト 12 運用(人的)コスト ● DBのスペック変更 ○ メンテナンス必須 ○ インフラチームとの連携 ● シャーディング(水平分散)が必須 ○ パフォーマンス向上のため ○ スケールインが大変サーバー費用 ● サーバー費用全体の大部分を占める ● ポケラボはGvGのプロダクトが多い ○ リアルタイムバトルが売り ○ バトル用のDBを別で用意 ● 過去プロダクトにおける、DB(MySQL)コストの問題

Slide 13

Slide 13 text

13 Cloud Spannerを選定 Google Cloud採用背景② - DBコストの解決策

Slide 14

Slide 14 text

Google Cloud採用背景② - Could Spannerの魅力 ● 簡単なスケーリング ○ CPUやメモリ、ストレージの増減 ■ ノード数の増減(ワンクリック or 自動)で実現 ■ ダウンタイムなし ○ シャーディング ■ トラフィック変化に応じて自動で行う(スプリット分割) 14 node1 node2 nodeX

Slide 15

Slide 15 text

Google Cloud採用背景② - 抑制したいコスト 15 ● 過去プロダクトにおける、DB(MySQL)コストの問題サーバー費用 ● サーバー費用全体の大部分を占める ● ポケラボはGvGのプロダクトが多い ○ リアルタイムバトルが売り ○ バトル用のDBを別で用意運用(人的)コスト ● DBのスペック変更 ○ メンテナンス必須 ○ インフラチームとの連携 ● シャーディング(水平分散)が必須 ○ パフォーマンス向上のため ○ スケールインが大変

Slide 16

Slide 16 text

サーバー費用 ● サーバー費用全体の大部分を占める ● ポケラボはGvGのプロダクトが多い ○ リアルタイムバトルが売り ○ バトル用のDBを別で用意運用(人的)コスト ● DBのスペック変更 ○ メンテナンス必須 ○ インフラチームとの連携 ● シャーディング(水平分散)が必須 ○ パフォーマンス向上のため ○ スケールインが大変 Google Cloud採用背景② - 抑制したいコスト 16 ● 過去プロダクトにおける、DB(MySQL)コストの問題大幅削減

Slide 17

Slide 17 text

サーバー費用 ● サーバー費用全体の大部分を占める ● ポケラボはGvGのプロダクトが多い ○ リアルタイムバトルが売り ○ バトル用のDBを別で用意 Google Cloud採用背景② - 抑制したいコスト 17 ● 過去プロダクトにおける、DB(MySQL)コストの問題無駄を抑える運用(人的)コスト ● DBのスペック変更 ○ メンテナンス必須 ○ インフラチームとの連携 ● シャーディング(水平分散)が必須 ○ パフォーマンス向上のため ○ スケールインが大変大幅削減

Slide 18

Slide 18 text

18 WFS内の導入実績 + Cloud Spannerによるコスト抑制見込み Google Cloud採用をした理由

Slide 19

Slide 19 text

19 技術選定する理由コスト = サーバー費用, 人, 運用, 開発...etc 運用できるの？開発できるの？性能は問題ない？ → WFS内の導入実績コストの抑制

Slide 20

Slide 20 text

20 技術選定する理由コスト = サーバー費用, 人, 運用, 開発...etc 運用できるの？開発できるの？性能は問題ない？ → WFS内の導入実績コストの抑制

Slide 21

Slide 21 text

21 性能面 ● 「内製ライブラリ + Cloud Spanner 」で問題なく動作するか開発面 ● ポケラボ内製ライブラリの改修 ○ 長年の運用実績 ○ Cloud Spanner用に改修 Cloud Spannerを導入するにあたっての課題

Slide 22

Slide 22 text

22 性能面 ● 「内製ライブラリ + Cloud Spanner 」で問題なく動作するか　　→ 改修後に性能試験を実施開発面 ● ポケラボ内製ライブラリの改修 ○ 長年の運用実績 ○ Cloud Spanner用に改修　　→ Cloud Spanner特有の問題 Cloud Spannerを導入するにあたっての課題

Slide 23

Slide 23 text

● ホットスポット ○ あるスプリットにアクセスが集中し、パフォーマンスが低下 ○ スプリットは連続したキーの範囲で作成される ● シーケンシャルなキーを用いると起きやすい 23 内製ライブラリの改修 - spanner特有の問題 pk=1~100 table A (shard1) pk=101~200 ・・・ pk=1001~1100 table A (shard2) table A (shard10)

Slide 24

Slide 24 text

● ホットスポット ○ あるスプリットにアクセスが集中し、パフォーマンスが低下 ○ スプリットは連続したキーの範囲で作成される ● シーケンシャルなキーを用いると起きやすい ○ 例) pk=101~200が頻繁に読み書きされる→shard2にアクセスが集中 24 内製ライブラリの改修 - spanner特有の問題 pk=1~100 table A (shard1) pk=101~200 ・・・ pk=1001~1100 table A (shard2) table A (shard10)

Slide 25

Slide 25 text

● pkにAUTO_INCREMENTを用いているテーブル ○ ある程度の桁数の数値でランダム生成 ● ユーザーに紐づくテーブル ○ userId + マスタIDの複合キーをpkとする ○ 例) ユーザーが所持しているキャラクターのデータ → userId + characterId ● マスタテーブル ○ pkとなるIDは、マスタを作成しているプランナーが決めている ○ app pod(アプリサーバー)起動時に一括で取得してサーバーキャッシュに載せる 25 内製ライブラリの改修 - ホットスポット対応

Slide 26

Slide 26 text

性能検証 - 概要 ● 性能検証のため負荷試験を実施 ○ 内製ライブラリ + Cloud Spannerの性能調査 ○ 改修したライブラリの動作確認 ● リリース時のログインラッシュを想定したシナリオを用意 ○ ログイン→プレゼント受け取り→各種ユーザーデータ取得→ガチャorクエスト周回 26

Slide 27

Slide 27 text

性能検証 - 目標設定 ● 過去プロダクトを参考に目標値を設定 ● シナリオ作成にはJMeterを使用 ○ モニタリング: Grafana ○ ログ調査: Cloud Logging 27 項目 RPS レスポンスタイムエラー率目標値 15,000 Req/Sec p90: 300ms未満 p95: 400ms未満 < 0.01% (アプリ側のerror含む)

Slide 28

Slide 28 text

性能検証 - 手順 1. 1 pod, 1 ノードで捌けるRPS数を調査 ○ podのCPU使用率が60%になるように、VMインスタンスも調整 2. 目標RPSに対してのpod数を試算 ○ 目標値(1.5万) / 手順1でのRPS 3. 少しずつRPSとpod数を増やして、ノード数を調整 28

Slide 29

Slide 29 text

性能検証 - 結果 29 ● 概ね目標値クリア ○ GKEノードプールのマシンタイプ: c2-standard-16 ○ app pod数: 140 (8 vCPU, 12Gi) ● 加えて、検証過程で多く出ていたCloud Spannerのエラー対応 RPS spanner ノード数レスポンスタイムエラー率 1.66万 35 p90: 376ms p95: 400ms 0.0002%

Slide 30

Slide 30 text

性能検証 - Transaction was aborted 30 ● トランザクション間の競合によるエラー ○ エラー件数: 480件 / 1000万 req ○ 整合性のための排他制御故に、発生してしまうのは仕方がない ● 1つのトランザクションで複数テーブルにアクセスする時に起きやすい ○ 独自実装した処理 ○ ライブラリのsingle-useでは発生しない → リトライが仕込まれていた ● 独自の実装にもリトライを仕込む ○ エラー件数: 480 → 12件まで減少

Slide 31

Slide 31 text

性能検証 - ホットスポットの監視 ● Key Visualizer ○ 横軸 = 時間 ○ 縦軸 = テーブルのキー(降順) ● 色 = リソース使用の度合い ○ 白くなればなるほどCPUを使用 ● 問題となるようなテーブルは1件 ○ pkのpreﬁxが同じだった 31 Key Visualizerのヒートマップ例

Slide 32

Slide 32 text

32 技術選定する理由コスト = サーバー費用, 人, 運用, 開発...etc 運用できるの？開発できるの？性能は問題ない？ → グループ内の導入実績 → 内製ライブラリ改修 → 性能試験コストの抑制

Slide 33

Slide 33 text

● 運用コストは激減 ○ メンテナンスなし、サーバーエンジニアのみでDBスペック変更可能 ○ シャーディングのスケールイン/アウトの手間もなくなった ■ ホットスポットに注意 ● 通常は少なめのノード数、施策リリース直前にあらかじめ増やす運用 ○ 急激なアクセス増加への対応 ○ 過去プロダクトではやりにくかったこと ○ 施策リリースもメンテナンスなし ● リリース初期から目立った障害なし 33 実績 - 運用

Slide 34

Slide 34 text

● DB費用が約2~3割減 ○ 過去の運営タイトルのリリース後~6ヶ月の費用と比較 ■ ソロ主体のタイトル ■ ユーザー規模は異なるため参考値 ● まどドラの方がユーザー数は多い ● リリース時から比べてDB賃借料は7割まで減 ○ 負荷を日々調査して少しずつスペックを下げる(メンテナンスなし) ○ リリース1ヶ月後には半分ほどに削減 34 実績 - 費用

Slide 35

Slide 35 text

● 国内/海外ともに1リージョンで運用(東京リージョン) ○ 国内に比べてレイテンシは悪化するが問題ないレベル ○ 運用コスト抑制に繋がった ■ 海外用にpodを配置する必要がない → デプロイコスト削減 ■ Cloud Spannerも1インスタンスで運用 → ノードの設定も共通 ● Cloud Logging, Cloud Monitoringなどの活用できるサービスが多い ○ 何も設定しなくても、GKEのpodのログが自動的に送信 35 その他の利点

Slide 36

Slide 36 text

● Cloud SpannerによるDBコスト抑制のため、Google Cloudを採用 ○ きっかけはWFS内での採用実績 ○ サーバー費用と人的コストの問題を解決できる見込み ● Cloud Spanner移行のため、内製ライブラリの改修と性能試験を実行 ○ ポケラボ内製ライブラリをCloud Spanner用に対応 ○ 内製ライブラリ + Cloud Spannerの負荷試験 ● 運用コストは激減。費用も減。 ○ 安定した稼働も続けられている！ 36 まとめ