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

2025/10/03 TiDB User Day2025

Transcript

1. 1/59 TiDB User Day 2025 リリース時のアクセス急増をいかにしてノーメンテで乗り越えたか 〜『Shadowverse: Worlds Beyond』における TiDB 採用のゲームサーバー設計 〜 株式会社Cygames サーバーサイド エンジニア/ 青木 淳
2. 2/59 Cygamesについて 最高のコンテンツを作る会社
3. 3/59 Cygamesについて ゲームの企画・開発・運営、アニメーション製作、漫画事業 多様なエンターテインメントを届ける
4. 4/59 自己紹介 青木 淳 株式会社Cygames サーバーサイド/エンジニア スマｰトフォンやPCゲームの運用・開発を経て、 2022年より株式会社Cygamesに合流。 『Shadowverse: Worlds Beyond』のサーバーサイド開発を担当。
5. 5/59 本セッションについて テーマ 『Shadowverse: Worlds Beyond』における スケーラビリティ実現のための技術選択と設計思想 分散データベースTiDBの採用における 効果と注意点、運用上の学び
6. 6/59 1. シャドバとは 2. シャドバWBの構成 3. 従来のDBからTiDBへ 4. TiDBを使うために 5. リリース アジェンダ
7. 7/59 1. シャドバとは
8. 8/59 Shadowverse 4000種を超える美麗カード！ 本格スマホカードバトル！ 「進化」で勝利を！ 2016年6月17日 対戦型オンラインDCG App Store / Google Play / DMM GAMES / Steam リリース日 ジャンル プラットフォーム
9. 9/59 Shadowverse: Worlds Beyond Shadowverseの正統後継作！ 新たな次元のデジタルカードゲーム！ 「超進化」が実現！ リリース日 ジャンル プラットフォーム 2025年6月17日 対戦型オンラインDCG App Store / Google Play / Steam / Epic Games Store
10. 10/59 シャドバWBとは
11. 11/59 バトル機能とパーク機能 バトル パーク
12. 12/59
13. 13/59 2. シャドバWBの構成
14. 14/59 バックエンドで採用している技術 クラウド プラットフォーム コンテナ オーケストレーション REST API リアルタイム通信 データベース ECS php
15. 15/59 リアルタイム通信とは REST API ユーザーからサーバーへの リクエスト/レスポンスのやりとり リアルタイム通信 他のプレイヤーの行動がそのままゲームに反映 カード操作アクション パークでのアバターの動き  
16. 16/59 システム構成図 ALB 内部ALB Fargate (内部APIサーバー） Fargate (APIサーバー） APIサーバー 2種類に分けて運用 ①クライアントからアクセス可能なAPIサーバー ②内部専用のAPIサーバー ALBを経由して通信 リアルタイム通信サーバー コンテンツ毎にクラスターを分けて運用 クライアントと直接通信 TiDB Cloud 永続性のあるデータを管理 ゲームサーバーとVPCピアリング接続 ElastiCache EC2 (リアルタイム通信 サーバー）
17. 17/59 3. 従来のRDBMSからTiDBへ
18. 18/59 従来のRDBMSの問題点 負荷が高くなる → システムスケールが必要 スケールアウトする → メンテナンス時間が必要 メンテ中はサービス停止 → ユーザーに迷惑をかける ユーザー増加 → 単一DBでは限界 分割で対応 → システムが複雑化 複雑になる → 運用コストが跳ね上がる さらに負荷が増えたら → もっと複雑に 負荷増加の ジレンマ 複雑化の 悪循環 こんな問題点ありませんか？
19. 19/59 従来のRDBMSスケールアウト Aさん Bさん イベントデータ取得 Aさんの ユーザーデータ取得 ショップデータ取得 Bさんの ユーザーデータ取得 APIサーバー データベース データベース データベース データベース
20. 20/59 計画通りにいかない… リリース時の課題点ありませんか？ 事前準備もバッチリ！でも想定以上のユーザーが殺到 プロダクトとしては大成功！ ...なのにシステムが悲鳴をあげてしまう システムを守るには → メンテナンスで一時停止が必要 嬉しい 悲鳴の ジレンマ 初回訪問のユーザー → プレイできずに離脱 口コミで広まってる最中に → サービス停止で勢いストップ 一度離れたユーザー → 戻ってくるのは難しい... 機会損失 の連鎖
21. 21/59 RDBMSのシームレスなスケーリング シームレスなスケーリング メンテ無しで負荷に応じて柔軟なスケール 以前より課題を解決するためにCygamesでは、 調査、検証を進め、TiDBを採用する事にした
22. 22/59 TiDBを選択した理由について 1. データの完全性を担保できる 2. CygamesではMySQLを使用している 3. サーバーリソースをより上手く使える
23. 23/59 TiDBを選択した理由について 課題改善 ≠ 価値提供 ゲームとして成立させるには、 データの完全性が必要不可欠！ TiDBは分散型でありながら 完全性を担保！ 1. データの完全性を担保できる
24. 24/59 TiDBを選択した理由について TiDBはMySQLのインターフェースをそのまま使⽤できる MySQLとの互換性が⾼く普段MySQLを 扱っているアプリケーション開発者としては扱いやすい 2. CygamesではMySQLを使用している
25. 25/59 TiDBを選択した理由について TiDBは必要なリソースに ターゲットを絞ってスケールできるため バランスよくリソースを使⽤できる 特にTiDBノードはステートレスであり 必要に応じてより柔軟にスケールできるため コスト削減も期待できる 3. サーバーリソースをより上手く使える
26. 26/59 課題解決のTiDB https://tech.cygames.co.jp/archives/3566/ 参考リンク 「最高のコンテンツ」を支える、Cygamesのデータベース技術の今までとこれから ～次世代データベース[TiDB」の検証を開始したCygamesの取り組み～ 詳細は「Cygames Engineers' Blog」で！
27. 27/59 従来のRDBMSからTiDBへ（まとめ） シャドバWBは TiDBでゲーム開発にチャレンジ！ システムスケールにはメンテナンスが必要 運用年数や、ユーザー数の増加に伴うシステムの複雑化 従来のRDBMSの問題点 RDBMSのシームレスなスケーリングが必要 課題解決のため
28. 28/59 4. TiDBを使うために
29. 29/59 考えを変える必要性 社内メンバーにTiDBの理解を広める MySQLとの互換性は高いのでそのまま使う事が可能だが、 効率面、性能面では従来の意識で実装するのは× TiDBの調査・検証を行った横断チームが中心となり、 社内勉強会を開催
30. 30/59 シャドバWBでもノウハウを生かす MySQLとは違う… 特定ノードに負荷集中する危険性 ホットスポット 分散キーを意識しないと性能劣化 インデックス設計
31. 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
32. 32/59 詳細資料 https://tech.cygames.co.jp/archives/3631/ 参考リンク 詳細は「Cygames Engineers' Blog」で！ TiDBにおけるテーブル設計と最適化の事例
33. 33/59 トランザクション分離レベルはREAD COMMITTEDにする トランザクション分離レベル MySQLもTiDBもデフォルトのトランザクション分離レベルは REPEATABLE READだがそれぞれで挙動が異なる トランザクション内でのスナップショットのタイミング ①MySQL = Select を実行したとき ②TiDB = トランザクションが開始されたとき MySQLと同じ認識で実装すると、他のコネクションで 更新した値を上書きしてしまう可能性がある
34. 34/59 詳細資料 https://tech.cygames.co.jp/archives/3667/ 参考リンク Shadowverse: Worlds Beyond にみる TiDB 活用術 詳細は「Cygames Engineers' Blog」で！
35. 35/59 Webサーバー、リアルタイムサーバー Locust、DFrameを使ってテスト 負荷試験 各サービス毎に障害を起こしてテスト 障害試験 負荷をかけながらスケールする スケーラビリティ試験 数日間、負荷を掛け続ける 耐久試験 事前準備
36. 36/59 スケーラビリティ試験 スケールアウト スケールアップ スケールイン スケールダウン TiDB TiKV TiKVはいずれも問題なし → 状況に応じてスケール戦略を選択する方針に TiDBの再起動は接続中のコネクションが切断される → 切断後、アプリ側で再接続・再実行が必要 → 確実性をとりサービス稼働中はスケールアウトのみにする方針に
37. 37/59 TiDBを使うために（まとめ） TiDBに合わせてエンジニアの思考もアップデート →ホットスポット、インデックス設計、トランザクション分離レベル… 各種試験で性能をしっかり確認 →負荷試験、障害試験、耐久試験、スケーラビリティ試験
38. 38/59 5. リリース
39. 39/59 リリース話の前におさらい リリース時には予期しない負荷が発生する 安定したサービス提供が必要 サーバー台数で安定性をカバーする…？ サーバーリソースを上手く使った運用方法を追求 リリース時の不確実性に対して リソース需要の不確実性に強い柔軟なシステムで 最高のゲーム体験を提供する！ シャドバWB構成コンセプト
40. 40/59 シャドバWBが選べる2つの戦略 2つの戦略でシャドバWBのリリースを迎える！ サーバー台数を増やす スケールアウト サーバーを増やす方が素早く、全体性能の調整が効く今回の基本戦略 2のべき乗で性能が上がっていく サーバーのスペックを上げる スケールアップ
41. 41/59
42. 42/59 リリース当日の全体像 リリース直後 昼のピークタイム 負荷を予測し 夜に向けて最終調整 人が最も増える 夜のピークタイム システムスケール アクセスが急増 詳しく見ていきましょう 夜の負荷対策 システムスケール 無事リリースを 乗り越えた！ APIサーバー TiDB TiKV
43. 43/59 12:00 12:15 11:45 11:30 リリース直後 シャドバWB オープン 口コミで 広がっていく 徐々に流入が始まる 12:00頃～ アクセスが急増 APIリクエスト数 事前告知は【12:00頃】 期待以上の反響！
44. 44/59 昼のピークタイム① APIサーバーのCPU使用率が 8割近くなったので システムスケールを判断 CPU使用率が急激に増加したので、 スケールアウトで 素早く対応することにした グラフの上り方から1.5倍の台数で 落ち着くと予想 アクセス急増で システム負荷も高くなる APIサーバーシステム スケールを検討する APIサーバーの スケールアウトを判断 APIサーバーの CPU使用率 11:30 11:45 12:00
45. 45/59 昼のピークタイム② アクセス急増で システム負荷も高くなる TiDBのシステム スケールを検討する TiDBの スケールアウトを判断 TiDBの CPU使用率 TiDBのCPU使用率が 8割に近くなったので システムスケールを判断 CPU使用率が急激に増加したため、 スケールアウトで 素早く対応することにした 1.2倍の台数にし、 少しづつ様子を見ることにした 11:30 11:45 12:00
46. 46/59 昼のピークタイム③ APIサーバー スケールアウト開始 12:12頃から 新しいAPIサーバーが 立ち上がる 新しいサーバーへ リクエストが流れる CPU使用率が ガクッと下がる APIサーバーの CPU使用率 ノーメンテで実行！ 12:10 12:05 12:00 12:15 12:20 12:25
47. 47/59 TiDBノード スケールアウト開始 12:16頃から 新しいTiDBノードが 立ち上がる CPU使用率が 若干低くなる 負荷に 注意しながら監視 昼のピークタイム④ TiDBの CPU使用率 ノーメンテで実行！ 12:10 12:05 12:00 12:15 12:20 12:25
48. 48/59 昼のピークタイム後 昼のピークタイムは乗り越えたが… TiKVのCPU使用率が6割に達していた 夜はさらなる負荷増加が予想される 夜のピークタイムは昼以上のアクセスが発生 夜間バックアップ処理による追加負荷 TiKVのスケールアップを検討する。 スケールアウトは、以下の理由により除外 データリバランスによるCPUリソース消費 処理完了時間が不明 1日のピークタイム前のため安全性を重視 昼のピークアウト を確認 夜のピークタイムに向け サーバー増強を検討 PingCAPさんと相談 TiKVのスケール アップを検討 TiKVのCPU使用率 11:30 12:00 12:30 13:00 13:30
49. 49/59 夜のピークタイム前① 検証開始 負荷を掛けながら TiKVをスケールアップする ダウンタイム0、エラーもなく スケールアップの確認が出来る TiKVのスケールアップを念のため再試験 目標 ダウンタイム0でTiKVのスケールアップが可能か確認 エラーなくスケール処理が完了することを確認 手段 負荷試験ツールを使用して継続的に負荷をかける 負荷実行中にTiKVのスケールアップを実施 結果 目標を達成し、スケールアップ準備が完了 夜間の負荷増加に対応可能
50. 50/59 夜のピークタイム前② 18:00 ～ 負荷が高まっていく 昼のピークタイム時の 負荷を超える 夜のピーク前にTiKVの スケールアップを判断 TiKVのCPU使用率 13:00 14:00 15:00 16:00 17:00 18:00 19:00
51. 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のメモリ使用率
52. 52/59 こうしてリリース日を 無事乗り越える事が出来た！ 夜のピークタイム ピークタイムは50万QPS！ システムは既に増強していたため、危険域には届かなかった TiKVのスケールアップから しばらくしてピークタイムを迎える ピークアウトを確認 リリース日が終了
53. 53/59 リリース（まとめ） ノーメンテのシステムスケールで 最高のゲーム体験を提供！ 期待以上の反響でリリース告知時間からアクセスが急増 急激な負荷にもAPIサーバーと TiDBのスケールアウトで ノーメンテ対応！ 夜のピークタイムに向けて TiKVのスケールアップで ノーメンテ対応！
54. 54/59 運用上の知見
55. 55/59 オンラインDDLで問題発生 オンラインDDL実行時に、lock wait timeoutが発生 TiDBノード 1台だけメモリ使用率が高く GCが走りCPU使用率が上がった これにより、そのノードが担当した トランザクションが遅くなった 何が起こった？
56. 56/59 統計情報の履歴を保存する機能の問題 analyze tableの度に統計情報を自動記録する機能 過去の実行計画を再現できるようにするため 各tableは自動でanalyzeすることがあり、 定期的に記録される 統計履歴が多くなりすぎて、メモリがひっ迫した 本番環境ではオフにすることにした 原因はTiDBの統計履歴 https://github.com/pingcap/tidb/issues/59560 参考リンク  
57. 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のみ対応    
58. 58/59 本セッションのまとめ 最高のゲーム体験のためECS、TiDBで 柔軟なシステムを実現 TiDBに合わせてエンジニアの思考もアップデート リリース当日50万QPSのアクセスを ノーメンテで乗り越えた
59. 59/59