【TiDB User Day2025】リリース時のアクセス急増をいかにしてノーメンテで乗り越えたか〜『Shadowverse: Worlds Beyond』におけるTiDB採用のゲームサーバー設計〜

Slide 1

Slide 1 text

1/59 TiDB User Day 2025 リリース時のアクセス急増をいかにしてノーメンテで乗り越えたか〜『Shadowverse: Worlds Beyond』における TiDB 採用のゲームサーバー設計〜株式会社Cygames サーバーサイドエンジニア/ 青木淳

Slide 2

Slide 2 text

2/59 Cygamesについて最高のコンテンツを作る会社

Slide 3

Slide 3 text

3/59 Cygamesについてゲームの企画・開発・運営、アニメーション製作、漫画事業多様なエンターテインメントを届ける

Slide 4

Slide 4 text

4/59 自己紹介青木淳株式会社Cygames サーバーサイド/エンジニアスマｰトフォンやPCゲームの運用・開発を経て、 2022年より株式会社Cygamesに合流。『Shadowverse: Worlds Beyond』のサーバーサイド開発を担当。

Slide 5

Slide 5 text

5/59 本セッションについてテーマ『Shadowverse: Worlds Beyond』におけるスケーラビリティ実現のための技術選択と設計思想分散データベースTiDBの採用における効果と注意点、運用上の学び

Slide 6

Slide 6 text

6/59 1. シャドバとは 2. シャドバWBの構成 3. 従来のDBからTiDBへ 4. TiDBを使うために 5. リリースアジェンダ

Slide 7

Slide 7 text

7/59 1. シャドバとは

Slide 8

Slide 8 text

8/59 Shadowverse 4000種を超える美麗カード！本格スマホカードバトル！「進化」で勝利を！ 2016年6月17日対戦型オンラインDCG App Store / Google Play / DMM GAMES / Steam リリース日ジャンルプラットフォーム

Slide 9

Slide 9 text

9/59 Shadowverse: Worlds Beyond Shadowverseの正統後継作！新たな次元のデジタルカードゲーム！「超進化」が実現！リリース日ジャンルプラットフォーム 2025年6月17日対戦型オンラインDCG App Store / Google Play / Steam / Epic Games Store

Slide 10

Slide 10 text

10/59 シャドバWBとは

Slide 11

Slide 11 text

11/59 バトル機能とパーク機能バトルパーク

Slide 12

Slide 12 text

12/59

Slide 13

Slide 13 text

13/59 2. シャドバWBの構成

Slide 14

Slide 14 text

14/59 バックエンドで採用している技術クラウドプラットフォームコンテナオーケストレーション REST API リアルタイム通信データベース ECS php

Slide 15

Slide 15 text

15/59 リアルタイム通信とは REST API ユーザーからサーバーへのリクエスト/レスポンスのやりとりリアルタイム通信他のプレイヤーの行動がそのままゲームに反映カード操作アクションパークでのアバターの動き  

Slide 16

Slide 16 text

16/59 システム構成図 ALB 内部ALB Fargate (内部APIサーバー） Fargate (APIサーバー） APIサーバー 2種類に分けて運用 ①クライアントからアクセス可能なAPIサーバー ②内部専用のAPIサーバー ALBを経由して通信リアルタイム通信サーバーコンテンツ毎にクラスターを分けて運用クライアントと直接通信 TiDB Cloud 永続性のあるデータを管理ゲームサーバーとVPCピアリング接続 ElastiCache EC2 (リアルタイム通信サーバー）

Slide 17

Slide 17 text

17/59 3. 従来のRDBMSからTiDBへ

Slide 18

Slide 18 text

18/59 従来のRDBMSの問題点負荷が高くなる → システムスケールが必要スケールアウトする → メンテナンス時間が必要メンテ中はサービス停止 → ユーザーに迷惑をかけるユーザー増加 → 単一DBでは限界分割で対応 → システムが複雑化複雑になる → 運用コストが跳ね上がるさらに負荷が増えたら → もっと複雑に負荷増加のジレンマ複雑化の悪循環こんな問題点ありませんか？

Slide 19

Slide 19 text

19/59 従来のRDBMSスケールアウト Aさん Bさんイベントデータ取得 Aさんのユーザーデータ取得ショップデータ取得 Bさんのユーザーデータ取得 APIサーバーデータベースデータベースデータベースデータベース

Slide 20

Slide 20 text

20/59 計画通りにいかない… リリース時の課題点ありませんか？事前準備もバッチリ！でも想定以上のユーザーが殺到プロダクトとしては大成功！ ...なのにシステムが悲鳴をあげてしまうシステムを守るには → メンテナンスで一時停止が必要嬉しい悲鳴のジレンマ初回訪問のユーザー → プレイできずに離脱口コミで広まってる最中に → サービス停止で勢いストップ一度離れたユーザー → 戻ってくるのは難しい... 機会損失の連鎖

Slide 21

Slide 21 text

21/59 RDBMSのシームレスなスケーリングシームレスなスケーリングメンテ無しで負荷に応じて柔軟なスケール以前より課題を解決するためにCygamesでは、調査、検証を進め、TiDBを採用する事にした

Slide 22

Slide 22 text

22/59 TiDBを選択した理由について 1. データの完全性を担保できる 2. CygamesではMySQLを使用している 3. サーバーリソースをより上手く使える

Slide 23

Slide 23 text

23/59 TiDBを選択した理由について課題改善 ≠ 価値提供ゲームとして成立させるには、データの完全性が必要不可欠！ TiDBは分散型でありながら完全性を担保！ 1. データの完全性を担保できる

Slide 24

Slide 24 text

24/59 TiDBを選択した理由について TiDBはMySQLのインターフェースをそのまま使⽤できる MySQLとの互換性が⾼く普段MySQLを扱っているアプリケーション開発者としては扱いやすい 2. CygamesではMySQLを使用している

Slide 25

Slide 25 text

25/59 TiDBを選択した理由について TiDBは必要なリソースにターゲットを絞ってスケールできるためバランスよくリソースを使⽤できる特にTiDBノードはステートレスであり必要に応じてより柔軟にスケールできるためコスト削減も期待できる 3. サーバーリソースをより上手く使える

Slide 26

Slide 26 text

26/59 課題解決のTiDB https://tech.cygames.co.jp/archives/3566/ 参考リンク「最高のコンテンツ」を支える、Cygamesのデータベース技術の今までとこれから～次世代データベース[TiDB」の検証を開始したCygamesの取り組み～詳細は「Cygames Engineers' Blog」で！

Slide 27

Slide 27 text

27/59 従来のRDBMSからTiDBへ（まとめ）シャドバWBは TiDBでゲーム開発にチャレンジ！システムスケールにはメンテナンスが必要運用年数や、ユーザー数の増加に伴うシステムの複雑化従来のRDBMSの問題点 RDBMSのシームレスなスケーリングが必要課題解決のため

Slide 28

Slide 28 text

28/59 4. TiDBを使うために

Slide 29

Slide 29 text

29/59 考えを変える必要性社内メンバーにTiDBの理解を広める MySQLとの互換性は高いのでそのまま使う事が可能だが、効率面、性能面では従来の意識で実装するのは× TiDBの調査・検証を行った横断チームが中心となり、社内勉強会を開催

Slide 30

Slide 30 text

30/59 シャドバWBでもノウハウを生かす MySQLとは違う… 特定ノードに負荷集中する危険性ホットスポット分散キーを意識しないと性能劣化インデックス設計

Slide 31

Slide 31 text

31/59 対応例 ①インデックスを使う前にPRIMARY Keyを検討する ②時系列にソートできるランダム文字列であるULIDを使う No カラム名データ型 1 user_id bigint 2 gift_id bigint 3 create_at DateTime No インデックスカラム 1 INDEX user_id No カラム名データ型 1 user_id bigint 2 ulid char(26) 3 gift_id bigint 4 create_at DateTime プレゼントBOXを管理するテーブル No インデックスカラム 1 PRIMARY KEY user_id, ulid

Slide 32

Slide 32 text

32/59 詳細資料 https://tech.cygames.co.jp/archives/3631/ 参考リンク詳細は「Cygames Engineers' Blog」で！ TiDBにおけるテーブル設計と最適化の事例

Slide 33

Slide 33 text

33/59 トランザクション分離レベルはREAD COMMITTEDにするトランザクション分離レベル MySQLもTiDBもデフォルトのトランザクション分離レベルは REPEATABLE READだがそれぞれで挙動が異なるトランザクション内でのスナップショットのタイミング ①MySQL = Select を実行したとき ②TiDB = トランザクションが開始されたとき MySQLと同じ認識で実装すると、他のコネクションで更新した値を上書きしてしまう可能性がある

Slide 34

Slide 34 text

34/59 詳細資料 https://tech.cygames.co.jp/archives/3667/ 参考リンク Shadowverse: Worlds Beyond にみる TiDB 活用術詳細は「Cygames Engineers' Blog」で！

Slide 35

Slide 35 text

35/59 Webサーバー、リアルタイムサーバー Locust、DFrameを使ってテスト負荷試験各サービス毎に障害を起こしてテスト障害試験負荷をかけながらスケールするスケーラビリティ試験数日間、負荷を掛け続ける耐久試験事前準備

Slide 36

Slide 36 text

36/59 スケーラビリティ試験スケールアウトスケールアップスケールインスケールダウン TiDB TiKV TiKVはいずれも問題なし → 状況に応じてスケール戦略を選択する方針に TiDBの再起動は接続中のコネクションが切断される → 切断後、アプリ側で再接続・再実行が必要 → 確実性をとりサービス稼働中はスケールアウトのみにする方針に

Slide 37

Slide 37 text

37/59 TiDBを使うために（まとめ） TiDBに合わせてエンジニアの思考もアップデート →ホットスポット、インデックス設計、トランザクション分離レベル… 各種試験で性能をしっかり確認 →負荷試験、障害試験、耐久試験、スケーラビリティ試験

Slide 38

Slide 38 text

38/59 5. リリース

Slide 39

Slide 39 text

39/59 リリース話の前におさらいリリース時には予期しない負荷が発生する安定したサービス提供が必要サーバー台数で安定性をカバーする…？サーバーリソースを上手く使った運用方法を追求リリース時の不確実性に対してリソース需要の不確実性に強い柔軟なシステムで最高のゲーム体験を提供する！シャドバWB構成コンセプト

Slide 40

Slide 40 text

40/59 シャドバWBが選べる2つの戦略 2つの戦略でシャドバWBのリリースを迎える！サーバー台数を増やすスケールアウトサーバーを増やす方が素早く、全体性能の調整が効く今回の基本戦略 2のべき乗で性能が上がっていくサーバーのスペックを上げるスケールアップ

Slide 41

Slide 41 text

41/59

Slide 42

Slide 42 text

42/59 リリース当日の全体像リリース直後昼のピークタイム負荷を予測し夜に向けて最終調整人が最も増える夜のピークタイムシステムスケールアクセスが急増詳しく見ていきましょう夜の負荷対策システムスケール無事リリースを乗り越えた！ APIサーバー TiDB TiKV

Slide 43

Slide 43 text

43/59 12:00 12:15 11:45 11:30 リリース直後シャドバWB オープン口コミで広がっていく徐々に流入が始まる 12:00頃～アクセスが急増 APIリクエスト数事前告知は【12:00頃】期待以上の反響！

Slide 44

Slide 44 text

44/59 昼のピークタイム① APIサーバーのCPU使用率が 8割近くなったのでシステムスケールを判断 CPU使用率が急激に増加したので、スケールアウトで素早く対応することにしたグラフの上り方から1.5倍の台数で落ち着くと予想アクセス急増でシステム負荷も高くなる APIサーバーシステムスケールを検討する APIサーバーのスケールアウトを判断 APIサーバーの CPU使用率 11:30 11:45 12:00

Slide 45

Slide 45 text

45/59 昼のピークタイム② アクセス急増でシステム負荷も高くなる TiDBのシステムスケールを検討する TiDBのスケールアウトを判断 TiDBの CPU使用率 TiDBのCPU使用率が 8割に近くなったのでシステムスケールを判断 CPU使用率が急激に増加したため、スケールアウトで素早く対応することにした 1.2倍の台数にし、少しづつ様子を見ることにした 11:30 11:45 12:00

Slide 46

Slide 46 text

46/59 昼のピークタイム③ APIサーバースケールアウト開始 12:12頃から新しいAPIサーバーが立ち上がる新しいサーバーへリクエストが流れる CPU使用率がガクッと下がる APIサーバーの CPU使用率ノーメンテで実行！ 12:10 12:05 12:00 12:15 12:20 12:25

Slide 47

Slide 47 text

47/59 TiDBノードスケールアウト開始 12:16頃から新しいTiDBノードが立ち上がる CPU使用率が若干低くなる負荷に注意しながら監視昼のピークタイム④ TiDBの CPU使用率ノーメンテで実行！ 12:10 12:05 12:00 12:15 12:20 12:25

Slide 48

Slide 48 text

48/59 昼のピークタイム後昼のピークタイムは乗り越えたが… TiKVのCPU使用率が6割に達していた夜はさらなる負荷増加が予想される夜のピークタイムは昼以上のアクセスが発生夜間バックアップ処理による追加負荷 TiKVのスケールアップを検討する。スケールアウトは、以下の理由により除外データリバランスによるCPUリソース消費処理完了時間が不明 1日のピークタイム前のため安全性を重視昼のピークアウトを確認夜のピークタイムに向けサーバー増強を検討 PingCAPさんと相談 TiKVのスケールアップを検討 TiKVのCPU使用率 11:30 12:00 12:30 13:00 13:30

Slide 49

Slide 49 text

49/59 夜のピークタイム前① 検証開始負荷を掛けながら TiKVをスケールアップするダウンタイム0、エラーもなくスケールアップの確認が出来る TiKVのスケールアップを念のため再試験目標ダウンタイム0でTiKVのスケールアップが可能か確認エラーなくスケール処理が完了することを確認手段負荷試験ツールを使用して継続的に負荷をかける負荷実行中にTiKVのスケールアップを実施結果目標を達成し、スケールアップ準備が完了夜間の負荷増加に対応可能

Slide 50

Slide 50 text

50/59 夜のピークタイム前② 18:00 ～負荷が高まっていく昼のピークタイム時の負荷を超える夜のピーク前にTiKVのスケールアップを判断 TiKVのCPU使用率 13:00 14:00 15:00 16:00 17:00 18:00 19:00

Slide 51

Slide 51 text

51/59 夜のピークタイム前③ 20:30 過ぎから TiKVのスケールアップ開始 20:40頃からTiKVの各ノードが 1つずつローリングアップデートされていく TiKVのCPU使用率 20:30 20:45 21:00 21:15 20:30 20:45 21:00 21:15 ノーメンテで実行！ TiKVのメモリ使用率

Slide 52

Slide 52 text

52/59 こうしてリリース日を無事乗り越える事が出来た！夜のピークタイムピークタイムは50万QPS！システムは既に増強していたため、危険域には届かなかった TiKVのスケールアップからしばらくしてピークタイムを迎えるピークアウトを確認リリース日が終了

Slide 53

Slide 53 text

53/59 リリース（まとめ）ノーメンテのシステムスケールで最高のゲーム体験を提供！期待以上の反響でリリース告知時間からアクセスが急増急激な負荷にもAPIサーバーと TiDBのスケールアウトでノーメンテ対応！夜のピークタイムに向けて TiKVのスケールアップでノーメンテ対応！

Slide 54

Slide 54 text

54/59 運用上の知見

Slide 55

Slide 55 text

55/59 オンラインDDLで問題発生オンラインDDL実行時に、lock wait timeoutが発生 TiDBノード 1台だけメモリ使用率が高く GCが走りCPU使用率が上がったこれにより、そのノードが担当したトランザクションが遅くなった何が起こった？

Slide 56

Slide 56 text

56/59 統計情報の履歴を保存する機能の問題 analyze tableの度に統計情報を自動記録する機能過去の実行計画を再現できるようにするため各tableは自動でanalyzeすることがあり、定期的に記録される統計履歴が多くなりすぎて、メモリがひっ迫した本番環境ではオフにすることにした原因はTiDBの統計履歴 https://github.com/pingcap/tidb/issues/59560 参考リンク  

Slide 57

Slide 57 text

57/59 今後のために 8.2.0より前に作成したクラスタは設定をOFF 8.2.0以降はdefault OFF tidb_enable_historical_statsをOFFに 8.1から8.5へアップデートしたクラスタは要注意 DDL専用のTiDBノードを用意する方法も TiDB CloudのNode GroupでDDL専用インスタンスを用意可能 Dedicatedのみ対応    

Slide 58

Slide 58 text

58/59 本セッションのまとめ最高のゲーム体験のためECS、TiDBで柔軟なシステムを実現 TiDBに合わせてエンジニアの思考もアップデートリリース当日50万QPSのアクセスをノーメンテで乗り越えた

Slide 59

Slide 59 text

59/59