【TiDB GAME DAY 2025】Shadowverse: Worlds Beyond にみる TiDB 活用術

2025/05/30 TiDB Game Day 2025

Transcript

1. 1/72 TiDB GAME DAY 2025 Shadowverse: Worlds Beyond にみる TiDB 活用術 株式会社 Cygames サーバーサイド 宮脇 剛史
2. 2/72 Cygames について 「最高のコンテンツを作る会社」
3. 3/72 Cygames について
4. 4/72 Shadowverse: Worlds Beyond について 2025 年 6 月 17 日 (火) リリース 現在事前登録受付中
5. 5/72 Shadowverse: Worlds Beyond では TiDB を採用
6. 6/ 自己紹介 宮脇 剛史 シニアゲームエンジニア / サーバーサイド サーバーサイドエンジニアとして 複数のタイトルでの運用を経て、 現在はサーバータスクにて横断的な技術支援、 技術検証、負荷試験などを担当。 直近では『Shadowverse: Worlds Beyond』などの TiDB 導入や技術支援を担当し、 大規模データ処理とパフォーマンス最適化を実現。
7. 7/72 プロジェクトとは独立した サーバーサイドセクション内の横断チーム – 技術検証 – 負荷試験 – TiDB の導入支援 – 全社的な FinOps 推進 サーバータスクチームについて
8. 8/72 Shadowverse: Worlds Beyond への支援 – TiDB テーブル設計ガイドラインの共有 – データベースの問題発生時の調査 – テーブル設計、クエリ、ソースコードのレビュー – 負荷試験の実施 サーバータスクチームについて
9. 9/72 1. TiDB 採用に至るまでの検証 2. Shadowverse: Worlds Beyond の TiDB 活用術 – API サーバ実装 – データ運用 – データ分析 3. Shadowverse: Worlds Beyond の負荷試験 4. まとめ アジェンダ
10. 10/72 TiDB 採用に至るまでの検証
11. 11/72 Cygames のサービスでは データベースとして MySQL を採用 垂直分割、水平分割を併用 あるゲームでは 300 台近くの MySQL を使っていたことも Cygames のデータベース
12. 12/72 MySQL ではスケールイン・アウトが難しい 過去の例ではエンジニアが数ヶ月拘束される ゲームは負荷の変動が大きい あるゲームではイベント中 450 万 QPS 近くになるが 平時は 20 万 QPS MySQL では常にピーク時のための リソースを確保することになり無駄が大きい なぜ TiDB なのか
13. 13/72 TiDB の持つ MySQL 互換性、スケーラビリティ、弾力性 に期待 なぜ TiDB なのか
14. 14/72 Cygames では、 TiDB の導入判断のため 2021 年ごろから検証を開始 MySQL との比較や TiDB の特性の把握を目的として 機能検証 や 性能検証 を実施 Cygames における TiDB の検証
15. 15/72 基本的に MySQL との互換性は高い MySQL を使った実装はほぼそのまま動く ただし、細かい部分で挙動が異なるものがある 普段は問題なく動くが、特定の状況で問題になる TiDB 機能検証の結果
16. 16/72 TiDB 性能検証 TiDB をそのまま使うと Aurora よりも性能が出ない
17. 17/72 TiDB 性能検証 テーブル設計、クエリを改善すると TiDB の性能を引き出すことができる
18. 18/72 工夫すれば Cygames の 多くのタイトルで利用可能であると判断 ただし、 TiDB の利用が難しいタイトルもある ゲームロジックがサーバーサイドにあり 通信頻度が非常に高いブラウザゲームなど TiDB 性能検証の結果
19. 19/72 Shadowverse: Worlds Beyond TiDB 活用術
20. 20/72 1. データベース周りの構成 2. API サーバ実装 3. データ運用 4. データ分析 Shadowverse: Worlds Beyond の TiDB 活用術
21. 21/72 Shadowverse: Worlds Beyond の TiDB 活用術 データベース周りの構成
22. 22/72 データベース周りの構成
23. 23/72 Shadowverse: Worlds Beyond の TiDB 活用術 API サーバ実装
24. 24/72 TiDB 活用術: API サーバ実装
25. 25/72 • テーブル・クエリ設計 • トランザクション分離レベル TiDB 活用術: API サーバ実装
26. 26/72 TiDB のプライマリキーやインデックスに注意 auto_increment, auto_random の使用を非推奨 ランダムなユーザー ID など システム全体で分散するものをキーの先頭に置く 詳しくは TiDB GAME DAY 2024 の資料参照 https://tech.cygames.co.jp/archives/3631/ テーブル・クエリ設計の工夫
27. 27/72 MySQL では REPEATABLE READ を使っていた TiDB で 同じように REPEATABLE READ を使うと Lost Update が発生する場合がある TiDB では READ COMMITTED を採用 トランザクション分離レベルの工夫
28. 28/72 説明に使用するテーブル id 1 user_id item_id value 1 1 1 1 2 1 users user_items
29. 29/72 Lost Update TX1 TX2 BEGIN; SELECT value FROM user_items WHERE user_id=1 AND item_id=1; value: 1 を取得 UPDATE user_items SET value=10 WHERE user_id=1; value: 10 に更新 UPDATE user_items SET value=1+1 WHERE user_id=1 AND item_id=1; value: 2 に上書き Lost Update COMMIT;
30. 30/72 Lost Update の回避 TX1 TX2 BEGIN; SELECT * FROM users WHERE id=1 FOR UPDATE; ロック用テーブルで ロック SELECT value FROM user_items WHERE user_id=1 AND item_id=1; value: 1 を取得 BEGIN; SELECT * FROM users WHERE id=1 FOR UPDATE; ロック待ちとなり 更新できない UPDATE user_items SET value=1+1 WHERE user_id=1 AND item_id=1; value: 2 に更新 COMMIT;
31. 31/72 MySQL では REPEATABLE READ のスナップショットは 最初の SELECT を実行したタイミングで取得 SELECT したテーブル以外のデータも同時にスナップショット 排他処理の前に意図せず SELECT をして事故が起きるケースも トランザクション開始直後に排他処理という ルールを守っていれば問題なかった MySQL のスナップショット
32. 32/72 MySQL のスナップショット TX1 TX2 BEGIN; UPDATE user_items SET value=10 WHERE user_id=1; value: 10 に更新 SELECT * FROM users WHERE id=1; ユーザー情報取得 スナップショット UPDATE user_items SET value=20 WHERE user_id=1; value: 20 に更新 SELECT value FROM user_items WHERE user_id=1 AND item_id=1; スナップショットか ら value: 10 を取得 COMMIT;
33. 33/72 TiDB では トランザクション開始時にスナップショットを取得 排他処理の前に誤って SELECT を 実行してしまった場合と同様の問題が発生 TiDB のスナップショット
34. 34/72 TiDB での Lost Update TX1 TX2 BEGIN; スナップショット BEGIN; SELECT * FROM users WHERE id=1 FOR UPDATE; UPDATE user_items SET value=10 WHERE user_id=1; value: 10 に更新 COMMIT; SELECT * FROM users WHERE id=1 FOR UPDATE; ユーザー情報取得 SELECT value FROM user_items WHERE user_id=1 AND item_id=1; スナップショットか ら value: 1 を取得 UPDATE user_items SET value=1+1 WHERE user_id=1 AND item_id=1; value: 2 に上書き Lost Update COMMIT;
35. 35/72 TiDB で Lost Update が発生する問題の対策を検討 1. GET_LOCK / RELEASE_LOCK を使う 2. 更新に関係する SELECT 全てに FOR UPDATE を付ける 3. READ COMMITTED を使う TiDB での Lost Update
36. 36/72 TiDB ではトランザクション開始時に スナップショットが取られる トランザクション開始前に GET_LOCK を使い スナップショット取得前に排他処理をすることで回避 Lost Update 対策 1: GET_LOCK
37. 37/72 TX1 TX2 SELECT GET_LOCK('users:1', 60); ロック BEGIN; スナップショット SELECT GET_LOCK('users:1', 60); ロック待ち SELECT * FROM users WHERE id=1 FOR UPDATE; ユーザー情報取得 SELECT value FROM user_items WHERE user_id=1 AND item_id=1; スナップショットか ら value: 1 を取得 UPDATE user_items SET value=1+1 WHERE user_id=1 AND item_id=1; value: 2 に更新 COMMIT; SELECT RELEASE_LOCK('users:1'); ロック解除 Lost Update 対策 1: GET_LOCK
38. 38/72 SELECT FOR UPDATE はスナップショットを 参照せず最新のデータが取得できる トランザクション中、更新に関わる SELECT 全てに FOR UPDATE を付けることで回避 Lost Update 対策 2: SELECT FOR UPDATE
39. 39/72 Lost Update 対策 2: SELECT FOR UPDATE TX1 TX2 BEGIN; スナップショット BEGIN; SELECT * FROM users WHERE id=1 FOR UPDATE; UPDATE user_items SET value=10 WHERE user_id=1; value: 10 に更新 COMMIT; SELECT * FROM users WHERE id=1 FOR UPDATE; ユーザー情報取得 SELECT value FROM user_items WHERE user_id=1 AND item_id=1 FOR UPDATE; 最新の value: 10 を 取得 UPDATE user_items SET value=10+1 WHERE user_id=1 AND item_id=1; value: 11 に更新 COMMIT;
40. 40/72 REPEATABLE READ の必要性を再検討 – トランザクションの先頭で排他処理を行うため 他トランザクションから同時に更新されることはない – ファジーリードを気にする必要がない – REPEATABLE READ である必要性がない READ COMMITTED を使うことで SELECT は最新データを取得することができる Lost Update 対策 3: READ COMMITTED
41. 41/72 TX1 TX2 BEGIN; BEGIN; SELECT * FROM users WHERE id=1 FOR UPDATE; UPDATE user_items SET value=10 WHERE user_id=1; value: 10 に更新 COMMIT; SELECT * FROM users WHERE id=1 FOR UPDATE; ユーザー情報取得 SELECT value FROM user_items WHERE user_id=1 AND item_id=1; 最新の value: 10 を 取得 UPDATE user_items SET value=10+1 WHERE user_id=1 AND item_id=1; value: 11 に更新 COMMIT; Lost Update 対策 3: READ COMMITTED
42. 42/72 Lost Update 回避方法ごとの性能 (TPS) を比較 シナリオ 1. ユーザー単位でロック 2. そのユーザーのアイテム全 100 件取得 3. その内 1 件を更新 TiDB における Lost Update 対策の性能比較
43. 43/72 TiDB における Lost Update 対策の性能比較 Aurora db.r8g.8xlarge TiDB Cloud TiDB: 8 vCPU, 16 GiB * 2 TiKV: 8 vCPU, 32 GiB * 3 パフォーマンスが良く、対応も容易な READ COMMITED を採用
44. 44/72 • テーブル・クエリ設計 効率の良い参照ができるように プライマリキーやインデックスを設計する • トランザクション分離レベル MySQL と TiDB でスナップショットを取得する タイミングが異なるため Lost Update の可能性がある READ COMMITTED を採用することで回避 API サーバ実装の工夫まとめ
45. 45/72 Shadowverse: Worlds Beyond の TiDB 活用術 データ運用
46. 46/72 TiDB 活用術: データ運用
47. 47/72 • トランザクションサイズによるエラー • 大量のデータの消し込み方法 TiDB 活用術: データ運用
48. 48/72 トランザクションのサイズとは？ TiDB はトランザクション中の更新内容をメモリに溜め込む 溜め込むためのバッファのサイズがトランザクションサイズ トランザクションのバッファのサイズには上限がある 更新量が多いとバッファが溢れトランザクションが失敗する トランザクションサイズによるエラー
49. 49/72 TiDB のトランザクションの仕組み TiKV から更新対象のデータを取得し、更新後のデータをバッファリング
50. 50/72 TiDB のトランザクションの仕組み COMMIT 時にトランザクションのバッファを FLUSH
51. 51/72 TiDB のトランザクションの仕組み 更新データ量が多いとバッファが溢れエラーが発生
52. 52/72 これらのクエリは TiDB でエラーになる可能性がある – 大量のデータをまとめて更新 UPDATE {table} SET value = 100; – データの一括削除 DELETE FROM {table}; – テーブルのメンテナンスのためのデータコピー INSERT INTO {table_new} SELECT * FROM {table_old}; トランザクションサイズにより失敗する例
53. 53/72 TiDBがクエリを自動で分割して実行する BATCH ON id LIMIT 1000 DELETE FROM users; このクエリは以下のように分割、順次実行される DELETE FROM users WHERE id BETWEEN 1 AND 1000; DELETE FROM users WHERE id BETWEEN 1001 AND 2000; 対策 1: Non-Transactional DML ︙
54. 54/72 対策 1: Non-Transactional DML 分割されたクエリは Atomic ではない 対象テーブルに他のクエリが実行されていると 意図しない結果になる可能性がある SHOW PROCESSLIST で進行状況が把握できる
55. 55/72 対策 2: Pipelined DML クエリの実行中、更新データを TiKV に 逐次書き込むことでトランザクションの制限を回避 Non-Transactional DML と異なり Atomic 性が保証される
56. 56/72 対策 2: Pipelined DML トランザクション中の更新データは随時 TiKV に FLUSH する
57. 57/72 トランザクションサイズによるエラーまとめ 大量のデータの更新方法は以下のように整理 基本的なバッチ処理 – スクリプトで 1 行ずつ更新 メンテナンス時の作業 – Non-Transactional DML – Pipelined DML
58. 58/72 大量のデータの消し込み Cygames ではデータ削除に論理削除を採用している データベースの容量確保のため 論理削除後のデータは一定期間経過後に削除する 削除が必要なデータの例 – ログテーブル – プレゼントテーブル（受け取り済みデータ）
59. 59/72 大量のデータの消し込み方法の検討 MySQL ではパーティションドロップを使用 TiDB ではどのように削除するのが良いかを検討 – DELETE による消し込み – TTL による消し込み – パーティションドロップによる消し込み
60. 60/72 DELETE による消し込み • create_time や delete_time が一定期間より 前のものを削除する DELETE クエリを毎日実行 削除対象を検索したり、ストレージに書き込むため データ量の多いテーブルでは TiDB や TiKV の負荷が大きい
61. 61/72 TTL による消し込み • create_time や delete_time に TTL を設定 • 一定時間ごとに自動的に TTL ジョブが実行 • TTLジョブは内部的に SELECT や DELETE を実行し、 データを削除 DELETE による消し込みと同様 TiDB, TiKV の負荷が大きい
62. 62/72 パーティションドロップによる消し込み • create_time や delete_time で 日ごとのパーティションを作成 • パーティションドロップのクエリを毎日実行 他の方法とは異なり TiKV のレイヤーでまとめて削除できるので軽量かつ高速 MySQL と同様にパーティションドロップを採用
63. 63/72 データ運用の工夫まとめ • トランザクションサイズによるエラー TiDB で大量の更新を行うとエラーになる可能性があるため スクリプトによる 1 行ずつの更新か、専用のクエリを使用 • 大量のデータの消し込み方法 パーティションドロップでの消し込みを採用
64. 64/72 Shadowverse: Worlds Beyond の TiDB 活用術 データ分析
65. 65/72 TiDB 活用術: データ分析
66. 66/72 分析基盤: Snowflake 社内共通の分析基盤として Snowflake が既にある 容量確保のため、多くのログデータは S3 上に保存 TiFlash を導入しても分析に必要なデータがない Changefeed は使用せず、別途 ETL サーバを用意 Snowflake上のデータがリアルタイムで更新されると 今までと同じような分析がしづらくなる
67. 67/72 分析基盤の今後 ログデータの保存場所の関係から 今後も分析基盤としての TiFlash の使用は難しい 現在の ETLサーバはコスト、負荷的にも改善の余地がある Changefeed の使用など、より良い構成を今後も検討する
68. 68/72 Shadowverse: Worlds Beyond 負荷試験
69. 69/72 開発中、リリース前に複数回の負荷試験を実施 いずれもデータベース以外の他の要素が先に詰まる TiDB に関しては問題がなかった 本番リリースに向けて TiDB の最適化ができていると判断 負荷試験の結果
70. 70/72 まとめ
71. 71/72 • 検証から得た知見を元に TiDB の活用術を構築 – 最高のコンテンツを作るため、自分たちが使うツールは 時間を掛けてでも検証し、仕組みを理解して、活用する – Cygames は今後も TiDB をデータベースの第一の選択肢として 積極的に取り組んでいく • TiDB を採用した Shadowverse: Worlds Beyond は 6 月 17 日リリース まとめ
72. 72/72