新アーキテクチャ「TiDB X」解説とDedicated比較 TiDB Cloud Premiumのゲーム運用活用を検証

2026年5月22日に開催された「TiDB GAME DAY2026」（運営：PingCAP）で登壇した際の資料です。

TiDBの新アーキテクチャ「TiDB X」をテーマに、「実例・技術・検証」の3部構成で発表しました。
実例としてTiDB Cloud Starterの本番運用事例を紹介し、技術パートではTiDB Xのアーキテクチャと仕組みを解説しました。
さらに検証パートではTiDB Cloud PremiumとTiDB Cloud Dedicatedの比較結果を共有しています。

日本初となるTiDB Cloud Premiumの先行検証内容も含めてご紹介しました！！

Transcript

1. 株式会社オルトプラス　浦谷 和茂 TiDB GAME DAY 2026-5-22
2. • TiDB Xを中心にお話しします。 • TiDB Cloud Premium日本初の先行事例 の検証としてお伝えします。 （PremiumはPrivate Preview版） はじめに
3. © 2026 AltPlus Inc. 3 • 【実例】Starter本番運用事例 • 【技術】新アーキテクチャ「TiDB X」 • 【検証】「Premium / Dedicated」比較 本日のアジェンダ
4. © 2026 AltPlus Inc. 自己紹介 4 株式会社オルトプラス 技術部/エンジニアマネージャー kazushige uratani 浦谷 和茂 2023年6月にオルトプラスに入社 プロジェクトを横断的に見ていますー！！ SRE見ていますー！！ 入社してからずっと「TiDBの推し活」をしてました（笑） TiDBのユーザーコミュニティー「 TiUG」も盛り上げTi！！
5. オルトプラスについて
7. オルトプラスはこんなことやってます！！ IT×エンタメ （非ゲーム領域） 推し活分野やAIを活用した技術を エンタメ領域に向けて展開。 オルトプラスのノウハウで 世界を変えていきます ゲーム開発・運営 （ゲーム領域） 大型IPタイトルからオリジナル タイトルの開発運用まで、ゲーム 開発のスペシャリスト集団が オルトプラスに在籍しています
8. オルトプラスはこんなこともできます！！ 共同開発・開発支援 （人材/コンサル事業他） 多様な経験を積んだ エンジニアが多数在籍。 社内外を問わず一緒に問題を 解決する、頼れる技術屋集団です オルトプラスと グループ会社のSTANDは 「派遣・SES」ができます！！ 多くのBusiness Partner と取引実績あり！！
9. オルトプラスの主なタイトル Everybody Shogi （えぶりばでぃ将棋） 忘却前夜 戦国小町苦労譚 語絵巻 - カタリエマキ - 新感覚カジュアル将棋 パズルゲーム 戦略的なバトルが特徴 のスマホ向けカードRPG フルボイス化＆平沢下戸先生 の魅力溢れるヴィジュアルで 再構築したオーディオノベル
10. リリース予定のタイトル
11. Starter本番運用事例
12. © 2026 AltPlus Inc. 実際のプロダクトにおける TiDB Cloud Starterの 本番運用事例を紹介します。 実 例
13. © 2026 AltPlus Inc. Starter本番運用事例：TiDB Cloud Starterとは 13 フルマネージドのマルチテナント型TiDB • MySQL互換データベース • オートスケーリング • 無料枠 + 従量課金モデル 提供状況：AWS（GA）・Alibaba Cloud（public preview）
14. © 2026 AltPlus Inc. Starter本番運用事例：TiDB Cloud Starterの特徴 14 各組織につき 最大5クラスターまで毎月無料で提供 • 25GiBの行ストレージ • 25GiBの列ストレージ • 250Mのリクエストユニット (RU) 使用頻度の高い5つのクラスターから作成するとよい
15. © 2026 AltPlus Inc. Starter本番運用事例：TiDB Cloud Starterの特徴 15 無料枠のリソース 1クラスターあたり 行ストレージ 5GiB 列ストレージ 5GiB リクエストユニット (RU) 50M（5,000万 RU） 最大5つの クラスター まで無料 ※6クラスター目からクレジットカード登録が必要 AWSの場合は、「AWS Marketplace」との連携でもOK
16. 本番プロダクトでTiDB Cloud Starterを採用
17. 「戦国小町苦労譚 語絵巻 - カタリエマキ -」は 声で楽しむオーディオノベル • 本の進化系 • 新しい読書体験 をコンセプトとしてサービスを提供
18. © 2026 AltPlus Inc. Starter本番運用事例：TiDB Cloud Starterを選んだ理由 18 • 本番運用でも元々小規模サービスである • 運用負荷や運用コストを減らしたい • 将来的に規模が大きくなった場合、 TiDB Cloud上位プランへの移行が容易である
19. © 2026 AltPlus Inc. Starter本番運用事例：リリース前の負荷想定 19 　本プロダクトはオーディオノベルのため、 　ソーシャルゲーム特有の下記の問題がほぼ発生しない • リリース直後の大規模スパイク • Topページへの極端な同時アクセス • ガチャやプレゼント処理による集中アクセス
20. © 2026 AltPlus Inc. Starter本番運用事例：リリース前の負荷想定 20 TiDB Cloud Starterのリソース範囲でも十分に 運用可能と判断しました！！ 負荷想定からの判断結果、 同時アクセスによるスパイクやアクセス集中なし
21. © 2026 AltPlus Inc. Starter本番運用事例：TiDB Cloud Starter導入時の実施内容 21 ①TiDB CloudのOrganization作成 ②TiDB Clusterの作成 ③使用限度額の設定 ④プライベートエンドポイントの作成 （PrivateLink）
22. © 2026 AltPlus Inc. Starter本番運用事例：本番環境の構成図（全体像） 22 Cloud ProviderはAWSを使用
23. © 2026 AltPlus Inc. Starter本番運用事例：本番環境の構成図（接続イメージ） 23 AppからPrivateLink経由でTiDB Cloud Starterへ接続
24. © 2026 AltPlus Inc. Starter本番運用事例：TiDB Cloud Starterの役割 24 • 管理情報：メンテナンス情報やお知らせ • ユーザー情報（課金系以外） • 各種マスターデータ 　主に以下のデータを 　トランザクション性能と安定性を重視して 　TiDB Cloud Starterに保存しています。
25. © 2026 AltPlus Inc. 25 オーディオノベルの登録は大量トランザクションが発生しにくい ユーザー情報（課金系以外） • エピソードの進行状況 • エピソードのしおり • エピソードの購入情報 • 既読フラグなどの状態管理 Starter本番運用事例：TiDB Cloud Starterの役割
26. © 2026 AltPlus Inc. Starter本番運用事例：TiDBを考慮したテーブル設計 26 • 主キー設計 • UUIDのデータ型 　TiDBの分散特性を考慮した結果、 　以下の点を設計時に意識しました。
27. © 2026 AltPlus Inc. Starter本番運用事例：TiDBを考慮したテーブル設計 27 ◆主キー設計 　Auto Incrementは使用せず、 　UUID（v4）を主キーとして採用 • TiDBでは単調増加キーがホットスポット を生みやすい • 分散性能を考慮した設計
28. © 2026 AltPlus Inc. 28 ◆UUIDのデータ型 　Laravel + Filamentを使用しているため、 　下記の方針として設計 • Filament側の実装がUUID文字列前提 • Binary型ではなくCHAR型で管理 推奨はBinary型ですが、基盤処理のオーバーライドコストを考慮し現時点は CHAR型を採用。（負荷試験で問題ないことを確認済み） Starter本番運用事例：TiDBを考慮したテーブル設計
29. © 2026 AltPlus Inc. 29 （補足）ULIDの検討 当初はULIDも検討していたのですが、 時間順でほぼ単調増加となる特性があり、 Regionに負荷が集中する可能性があるため 採用しませんでした。 Starter本番運用事例：TiDBを考慮したテーブル設計
30. © 2026 AltPlus Inc. 30 プロダクトの特性や負荷を見極めれば、 本番でも十分選択肢になると思います！！ Starter本番運用事例 TiDB Cloud Starterでも 本番利用は十分可能！！
31. © 2026 AltPlus Inc. 31 Starter本番運用事例 ブログもありますので、ぜひ！！
32. 新アーキテクチャ「TiDB X」
33. © 2026 AltPlus Inc. TiDBの新アーキテクチャ 「TiDB X」 の仕組みを解説します。 技 術
34. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：ゲーム運用のデータベースの特徴 34 • スパイク型トラフィック • OLTPとOLAPの混在 • バックグラウンド処理による負荷干渉 • 長期運用によるデータ肥大化 ゲームのデータベースは負荷変動が大きく 処理の種類も多種多様である。
35. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：ゲーム運用のデータベースの課題 35 • リリースに備えた過剰スケールアウト • 予測困難な負荷変動へのスケール対応 • クエリ負荷の競合 • スケールに伴う運用負荷 ゲーム運用ではリソース確保やスケール対応が難しく、 効率的な運用が課題となる。
36. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：予測困難な負荷変動へのスケール対応 36 リソース 時間 メトリクス確認 やアラート この期間は ユーザー影響 の可能性がある イベント開始 スケール対応 スケール対応には一定の時間が必要 徐々に改善
37. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：Classic TiDBの簡単な特徴 37 　Classic TiDBは「Shared-Nothing」 • ノード単位でスケール • データ再配置が必要（TiKV） TiDB Cloud Cloud Provider Dedicated AWS・GCP・Azure
38. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：Shared-Nothingについて 38 各ノードが独立して動作しデータを共有しない構造 （TiKVでは各ノードのローカルストレージにデータを保持） 各ノードが独立 Region Region Region Region Region Region ・・・ TiKV Region Region Region Region Region Region ・・・ TiKV ・・・ Region Region Region Region Region Region ・・・ TiKV
39. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：Shared-Nothingの課題 39 Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region スケールアウト スケールイン ノード追加（削除）でRegionの移動を行うため、 データ再配置完了までにかなりの時間を要してしまう。
40. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：Shared-Nothingの課題 40 TiKVノード内のストレージにデータを保存 スケールに時間が必要なため、 再配置のI/Oが追加の負荷となる スケールアウト（イン）にはRegionの再配置が必要
41. © 2026 AltPlus Inc. スケール時間の長期化を解決するために 「TiDB X」が登場！！ （スケール時間を秒単位へ）
42. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：TiDBの新旧比較 42 Classic TiDB TiDB X ノードが主役 （スケールに時間がかかる） ストレージが主役 （秒単位でスケール可能）
43. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：TiDB Xの簡単な特徴 43 　TiDB Xは「Shared-Storage」（cloud native） • データはオブジェクトストレージに集約 • 必要な分だけ即時スケール可能 TiDB Cloud Cloud Provider Starter・Essential・Premium AWS・Alibaba Cloud ※GCP・Azureにも今後対応していく予定です。
44. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：TiDB Xアーキテクチャ 44 https://docs.pingcap.com/tidbcloud/tidb-x-architecture/
45. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：TiDB Xアーキテクチャ 45 従来通り独立 キャッシュとして独立 ユーザーの処理とは関係ない 負荷の高い処理を独立 オブジェクトストレージとして独立
46. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：LSMツリーからLSMフォレストへ 46 Regionごとに 独立したLSMツリー （KVエンジン） TiKVノードごとに 単一のLSMツリー （RocksDB） グローバルミューテックスの競合を解消し、圧縮処理の干渉を低減
47. © 2026 AltPlus Inc. 47 • データはオブジェクトストレージに集約 • Computeと完全分離 　Shared-Nothing → Shared-Storage データ再配置が不要なため秒単位でスケール 新アーキテクチャ「TiDB X」：アーキテクチャの進化
48. © 2026 AltPlus Inc. 48 • Gateway / Compute / Cache • Elastic compute pool 　各レイヤーが独立して動作 必要な分だけリソースを確保して効率化 新アーキテクチャ「TiDB X」：レイヤーの独立性
49. © 2026 AltPlus Inc. 49 　StorageとCacheが連携して動作 必要なデータのみロードし軽量に動作 新アーキテクチャ「TiDB X」：ストレージとキャッシュの役割 • キャッシュレイヤー（TiKV）が 必要なデータをオンデマンドでロード
50. © 2026 AltPlus Inc. 50 • CPU / ディスク容量に応じて拡張 • 数秒でPodが増減してスパイクに即対応 　共有キャッシュを中心に自動スケール 負荷に応じて自動増減し従量課金を実現 新アーキテクチャ「TiDB X」：キャッシュの自動スケーリング
51. © 2026 AltPlus Inc. 51 • 実データコピー不要 • 数秒でスナップショット取得 　バックアップはメタデータ中心 データ量に依存しない高速バックアップ 新アーキテクチャ「TiDB X」：バックアップ
52. © 2026 AltPlus Inc. 52 　重い処理を分離（マイクロサービス化） ユーザー処理と競合せず影響しない 新アーキテクチャ「TiDB X」：ワークロード分離 • 圧縮、統計情報収集、バックアップ • インポート、DDL実行（INDEX作成など）
53. © 2026 AltPlus Inc. 53 • 数秒でスケール • 重い処理中でもゲームに影響なし • ピーク前提のリソース確保が不要 新アーキテクチャ「TiDB X」 　「TiDB X」はゲームワークロード 向きデータベース！！
54. © 2026 AltPlus Inc. 54 　①秒単位でのスケール 新アーキテクチャ「TiDB X」：TiDB Xの4つの特徴 Classic TiDB TiDB X Region Region Region Region Region Region Region Region スケールアウト スケールイン Region Region Region Storage Region Region スケールイン スケールアウト スケールアウト・イン共に Region移動が発生するため 時間がかかる スケールアウト時はストレージから キャッシュへの移動のみ。 スケールインはそのまま削除
55. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：TiDB Xの4つの特徴 55 各レイヤーを 独立して制御 　②レイヤーごとの独立性
56. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：TiDB Xの4つの特徴 56 Compute（TiDB） Storage（S3） Cache（TiKV） S3のデータをロード 　③Compute/Cache/Storageの多層分離
57. © 2026 AltPlus Inc. 新アーキテクチャ「TiDB X」：TiDB Xの4つの特徴 57 OLAP バックグラウンド処理 OLTP 　④ワークロードの分離（負荷干渉なし）
58. © 2026 AltPlus Inc. TiDB Xの分離構成により ゲームDBの理想を実現！！
59. 「Premium / Dedicated」比較
60. © 2026 AltPlus Inc. TiDB Cloud PremiumとDedicatedの違いを、 実際の検証結果を 踏まえて紹介します。 検 証
61. © 2026 AltPlus Inc. 61 「Premium / Dedicated」比較 　今回の検証では 　「TiDB X」の強みである下記を確認 • 数秒でスケール • 重い処理中でもゲームに影響なし • ピーク前提のリソース確保が不要
62. © 2026 AltPlus Inc. 62 「Premium / Dedicated」比較：負荷試験の構成 負荷試験ツール 　Locust（音ゲーAPI・1シナリオ約30分） 比較対象 　Premium（TiDB X） 　Dedicated（Classic TiDB）：v8.5.5 スペック条件 　Premium：MaxRCU=100,000 　　→スロットリング防止で最大値を設定 　Dedicated： 　　TiDB=2（8vCPU, 16GiB）+TiProxy 　　TiKV=3（8vCPU, 32GiB）
63. © 2026 AltPlus Inc. 63 「Premium / Dedicated」比較：負荷試験環境イメージ
64. © 2026 AltPlus Inc. 64 「Premium / Dedicated」比較：負荷試験実行イメージ 負荷試験開始 Login InGame 30分過ぎたあたりからアイテムが枯渇 アイテム枯渇で 徐々にユーザーが離脱 （負荷が落ちる） 負荷試験終了 負荷でQPSが落ちているように見えるので誤解ないように補足
65. © 2026 AltPlus Inc. 65 🎬 S1：イベント開催時のスケールアウト 🎬 S2：IMPORT時のゲームプレイ影響 🎬 S3：INDEX追加時のゲームプレイ影響 🎬 S4：CS調査クエリ実行中のゲームプレイ影響 「Premium / Dedicated」比較：検証シナリオ一覧
66. S1：イベント開催時のスケールアウト
67. © 2026 AltPlus Inc. 67 S1：イベント開催時のスケールアウト 　目的 TiDB Xの「秒単位スケールアウト」 を実測データで検証する
68. © 2026 AltPlus Inc. 68 S1：イベント開催時のスケールアウト 　検証条件 イベント開催時や新規リリース時のような スパイクを発生させる • 想定ユーザー数は10,000人 ◦ 1分以内に到達させる • 想定QPSは約10,000
69. © 2026 AltPlus Inc. 69 S1：イベント開催時のスケールアウト 　Premium検証結果（負荷状況） エラーなし QPSは14000で安定 レイテンシは15ms前後で影響なし スケールアウト中もQPSやレイテンシが安定し、 ゲームAPIへの影響はない状況でした。
70. © 2026 AltPlus Inc. 70 S1：イベント開催時のスケールアウト 　Premium検証結果（リソース消費） 負荷に連動してRUが即座に自動増減しました。 手動操作不要でリソースが最適化されています。 スケールアウト（自動） スケールイン（自動）
71. © 2026 AltPlus Inc. 71 S1：イベント開催時のスケールアウト 　Dedicated検証結果（負荷状況） スケールアウト中もQPSやレイテンシが安定し、 ゲームAPIへの影響はない状況でした。 QPSは14000で安定 レイテンシは15ms前後で影響なし エラーなし
72. © 2026 AltPlus Inc. 72 S1：イベント開催時のスケールアウト 　Dedicated検証結果（リソース消費） スケールアウト LeaderRegion均等中 TiDBは約10分で安定するが、TiKVはLeader/Region 再配置完了まで高負荷状態が継続。（徐々に安定する） ＋3台 ＋2台
73. © 2026 AltPlus Inc. 73 S1：イベント開催時のスケールアウト 　結果のまとめ スケール速度 ゲームへの影響 Premium RUが負荷に連動して 秒で自動スケール スパイク中も レイテンシの影響なし Dedicated 手動対応が必要。 データ再配置で 数分〜数十分かかる 影響なし。ただしTiKV はLeader再配置完了ま で高負荷状態が継続
74. S2：IMPORT時のゲームプレイ影響
75. © 2026 AltPlus Inc. 75 S2：IMPORT時のゲームプレイ影響 　目的 IMPORT（大量書き込み）などの 重い処理をユーザー処理から分離する 効果を検証する
76. © 2026 AltPlus Inc. 76 S2：IMPORT時のゲームプレイ影響 　検証条件 通常プレイ相当のAPIを実行しながら 「IMPORT INTO」を同時に実行する • S3のデータをインポート ◦ 1億を超えるデータ行数 ◦ 10GiBを超えるデータサイズ
77. © 2026 AltPlus Inc. 77 S2：IMPORT時のゲームプレイ影響 Premium Dedicated 約17GiB、約1億3000万件 をIMPORT JOBSで確認
78. © 2026 AltPlus Inc. 78 S2：IMPORT時のゲームプレイ影響 　Premium検証結果（負荷状況） エラーなし QPSは1500で安定 レイテンシは15ms前後で影響なし インポート中はElastic compute poolで分離して いるためゲームAPIへの影響はない状況でした。
79. © 2026 AltPlus Inc. 79 S2：IMPORT時のゲームプレイ影響 　Premium検証結果（リソース消費） 14:32:38 インポート開始 14:56:02 インポート終了 Elastic compute poolで 使用したコストを反映 インポート中のRUは変化がなく、 インポート終了後にRUが消費されていました。
80. © 2026 AltPlus Inc. 80 S2：IMPORT時のゲームプレイ影響 　Dedicated検証結果（負荷状況） ゲームAPIへの影響はないですが、インポート開始後に 平均544msの高レイテンシで一時的に実行されていました。 QPSは1500で安定 レイテンシは15ms前後で影響なし エラーなし インポート時のレイテンシは、 1%が約1秒で、平均は544ms
81. © 2026 AltPlus Inc. 81 S2：IMPORT時のゲームプレイ影響 　Dedicated検証結果（リソース消費） TiDBはインポート中はCPUが常時600%付近。 TiKVはインポート終了間際で400％までスパイク 17:23:11 インポート開始 17:35:10 インポート終了 17:23:11 インポート開始 17:35:10 インポート終了
82. © 2026 AltPlus Inc. 82 S2：IMPORT時のゲームプレイ影響 ゲームへの影響 Premium インポートはElastic compute poolで 分離されているので影響なし Dedicated 一時的に平均544msの高レイテンシ。 TiDBは高負荷継続、TiKVはスパイクが 発生したが、どちらも影響なし 　結果のまとめ
83. S3：INDEX追加時のゲームプレイ影響
84. © 2026 AltPlus Inc. 84 S3：INDEX追加時のゲームプレイ影響 　目的 INDEX作成（DDL）などの 重い処理をユーザー処理から分離する 効果を検証する
85. © 2026 AltPlus Inc. 85 S3：INDEX追加時のゲームプレイ影響 　検証条件 通常プレイ相当のAPIを実行しながら 「ALTER TABLE ADD INDEX 」を 同時に実行する • 10億を超えるデータ行数 • 100GiBを超えるデータサイズ
86. © 2026 AltPlus Inc. 86 S3：INDEX追加時のゲームプレイ影響 Premium Dedicated データ件数（約10億件）をDDL_JOBSで確認 （PremiumのROW_COUNTは0件でしたが追加を確認）
87. © 2026 AltPlus Inc. 87 S3：INDEX追加時のゲームプレイ影響 　Premium検証結果（負荷状況） エラーなし レイテンシは15ms前後で影響なし ユーザー離脱 QPSは1500で安定 INDEX追加中はElastic compute poolで分離して いるためゲームAPIへの影響はない状況でした。
88. © 2026 AltPlus Inc. 88 S3：INDEX追加時のゲームプレイ影響 　Premium検証結果（リソース消費） 16:02:33 INDEX追加開始 16:38:20 INDEX追加終了 Elastic compute poolで 使用したコストを反映 INDEX追加中のRUは変化がなく、 INDEX追加終了後にRUが消費されていました。
89. © 2026 AltPlus Inc. 89 S3：INDEX追加時のゲームプレイ影響 　Dedicated検証結果（負荷状況） エラーなし QPSは1500で安定 レイテンシは15ms前後で影響なし INDEX追加中もQPSやレイテンシが安定し、 ゲームAPIへの影響はない状況でした。
90. © 2026 AltPlus Inc. 90 S3：INDEX追加時のゲームプレイ影響 　Dedicated検証結果（リソース消費） TiDBはINDEX追加中はCPUが常時400%付近。 TiKVはINDEX追加終了間際で800％近くまでスパイク 18:01:04 INDEX追加開始 18:11:14 INDEX追加終了 18:01:04 INDEX追加開始 18:11:14 INDEX追加終了
91. © 2026 AltPlus Inc. 91 S3：INDEX追加時のゲームプレイ影響 　結果のまとめ ゲームへの影響 Premium INDEX追加はElastic compute poolで 分離されているので影響なし Dedicated TiDBは高負荷継続、TiKVはスパイクが 発生したが、どちらも影響なし
92. © 2026 AltPlus Inc. 92 Dedicatedでの負荷制御 IMPORT INTO <table_name> FROM 's3://...' WITH THREAD = 1, MAX_WRITE_SPEED = '100MiB'; IMPORT ADMIN ALTER DDL JOBS <job_id> THREAD = 1, BATCH_SIZE = 64, MAX_WRITE_SPEED = '100MiB'; DDL 同時実行数・書き込み帯域の制限例 処理時間は延びるがゲームへのリソース使用率を抑制できる
93. S4：CS調査クエリ実行中のゲームプレイ影響
94. © 2026 AltPlus Inc. 94 S4：CS調査クエリ実行中のゲームプレイ影響 　目的 OLTPとOLAPの同時実行による ワークロード分離効果を検証する
95. © 2026 AltPlus Inc. 95 S4：CS調査クエリ実行中のゲームプレイ影響 　検証条件 通常プレイ相当のAPIを実行しながら CS調査の重いクエリを同時に実行する • 複数テーブルとJOINするQuery • 数千万件のスキャン • 実行時間は数秒〜数十秒と様々
96. © 2026 AltPlus Inc. 96 S4：CS調査クエリ実行中のゲームプレイ影響 　Premium検証結果（負荷状況） 失敗あり （後で補足） QPSは1500で安定 レイテンシは15ms前後で影響なし CSクエリの実行はTiFlash（Columnar engine）で 実行されるのでゲームAPIへの影響はない状況でした。
97. © 2026 AltPlus Inc. 97 S4：CS調査クエリ実行中のゲームプレイ影響 　Premium検証結果（リソース消費） 単体で連続実行 並列で連続実行 CSクエリ実行中はTiFlashを使用したRUが加算されて 単体・並列共に同様のリソースを使用していました。
98. © 2026 AltPlus Inc. 98 Failed Queriesの原因について CSのQUERYが失敗してRUが低下 レイテンシが落ちていないので ゲームAPIには影響なしと言える 2つ目の山は並列で実行した結果 TiFlashレプリカ=1の設定で負荷が集中し、 一時応答不可のためCS調査クエリ一部失敗
99. © 2026 AltPlus Inc. 99 S4：CS調査クエリ実行中のゲームプレイ影響 　Dedicated検証結果（負荷状況） CS調査クエリ実行中もQPSやレイテンシが安定し、 ゲームAPIへの影響はない状況でした。 QPSは1500で安定 レイテンシは15ms前後で影響なし エラーなし
100. © 2026 AltPlus Inc. 100 S4：CS調査クエリ実行中のゲームプレイ影響 　Dedicated検証結果（リソース消費） TiKVは単体での実行で600%付近、 並列での実行は700%付近までリソースを使用 単体で連続実行 並列で連続実行
101. © 2026 AltPlus Inc. 101 S4：CS調査クエリ実行中のゲームプレイ影響 ゲームへの影響 Premium OLAPはColumnar engineで分離して いるのでOLTPへの影響なし Dedicated CSクエリ実行中はTiKVの高負荷状態が 継続していたが特に影響なし 　結果のまとめ
102. © 2026 AltPlus Inc. 102 S4：[Premium] Columnar engineを無効にして実施 レイテンシは250ms 近くまで上昇 「Columnar engine」無効時はRUが約3倍に増加。 ゲームへの影響防止・コスト削減の両面で有効にするのがよい エラーなし QPSは1500で安定
103. © 2026 AltPlus Inc. 103 TiFlash（Columnar engine）のコスト比較 TiFlashの利用方法 コスト Premium RU消費に含まれる 実行していない間は TiFlashのコストが かからない Dedicated TiFlashインスタンス を別途起動 インスタンスを停止 するまでコストが継続 TiFlashの有効化にはALTER TABLEコマンドが必要
104. オプションの検証
105. © 2026 AltPlus Inc. 105 🎬 S5：Max RCU超過時のスロットリング解消 • Premium専用のシナリオ オプションの検証：検証シナリオ一覧
106. S5：Max RCU超過時のスロットリング解消
107. © 2026 AltPlus Inc. 107 S5：Max RCU超過時のスロットリング解消 　目的 スロットリング発生時にMax RCUを 引き上げてスロットリングの解消を確認 　検証条件 Max RCUを低く設定してスパイク負荷で スロットリングを意図的に引き起こす
108. © 2026 AltPlus Inc. 108 S5：Max RCU超過時のスロットリング解消 　検証結果 • Max RCU20,000（スロットリング発生時） ◦ QPSが頭打ちになる ◦ レイテンシが1秒を超える • Max RCU100,000に引き上げる ◦ スロットリングが即時解消
109. © 2026 AltPlus Inc. 109 S5：Max RCU超過時のスロットリング解消 Max RCU20,000 Max RCU100,000 最小のRCUで開始 スロットリング解消 エラーなし
110. © 2026 AltPlus Inc. 110 S5：Max RCU超過時のスロットリング解消 10000QPSで頭打ち リソース枯渇による スロットリングで QUERYが積み上がり レイテンシが1sを超える QPS低下 Max RCU20,000
111. © 2026 AltPlus Inc. 111 S5：Max RCU超過時のスロットリング解消 RCUが解放されたためQPSが安定 スロットリングが解消されてレイテンシが安定 Max RCU100,000
112. © 2026 AltPlus Inc. 112 最小値 最大値 RCU（MAX） 20,000 100,000 RCU（MIN） 5,000 25,000 RCUの値について（Preview版：GAで変更の可能性あり） • RCUのMAXのみ設定が可能（インターバル12時間） • RCUのMINの値はMAXの1/4の値で自動設定 • 未使用の場合はMINがランニングコスト
113. © 2026 AltPlus Inc. 113 まとめ（TiDB X） • Starter本番運用 ◦ プロダクトの特性や負荷を見極めれば、 本番でも十分選択肢になる • TiDB X（新アーキテクチャ） ◦ Shared-Storageで秒単位スケール ◦ 重い処理でもゲームに影響しない • 検証結果（S1〜S4） ◦ 全シナリオでゲームAPIへの影響なし
114. © 2026 AltPlus Inc. 114 さいごに：TiUGの紹介
115. © 2026 AltPlus Inc. 115 さいごに：TiUGの紹介
116. 116 参加者大歓迎！ スピーカー募集！ 運営メンバー募集！ TiUGは connpass で活動しています！！ https:/ /tiug.connpass.com/
117. TiDB Cloud Premiumは ゲーム運用の課題を解決してもっと楽に！！ ご清聴ありがとうございました