🕶️
TiDB User Day 2025 に参加なぅ

2025/10/03に公開
今年も TiDB User Day に参加しています！
去年に引き続き今年もライブブログやってみようと思います。(めっちゃ久々ｗ)
最初のセッションはごめんなさい、ちょっといろいろあってライブブログはスキップしています

 東京ガス内製開発チームリーダーが語る TiDB本番運用の今

 講演者東京ガス株式会社　リビング戦略部 デジタルプロダクト推進グループ
Platform Team Lead　青木 翔平 氏
Software Engineering Team Lead　中島 潤耶 氏 → 迫田 賀章氏
東京ガス
第３創業期
脱炭素化による地球環境への貢献 & デジタル化による収益拡大


アプリケーション開発 Team から見た TiDB
内製開発の取り組み
エネルギー公理全面自由化による変化
選ばれる存在になったことで、デジタル接点によるお客様の獲得や体験価値の向上が喫緊の課題になった
エンジニアリングチームを立ち上げ、内製開発を推進


事業組織内にプロダクト開発・運用の内製化に必要な人材が在籍し、ビジネス・デザイン・テクノロジーの距離感が近い状態で開発を行なっている
同じ組織にいるからこそ、一体となって価値を届けられる
プロダクト組織内にプロダクト開発の内製化に必要な人材が在籍し、プロダクト開発を推進


my TOKYO GAS
ガス料金、使用料等をみえる
リニューアルのタイミングで完全内製化を実現
フロントエンド領域の内製化
最初はフロントから、バックエンドは外注という形で進めたが。。。
現状の課題
レガシーシステムの API 改修が困難であったため、BFF 内部にドメインに変換する処理が構築されている、内製開発がフロントエンド領域に限定されていたことで開発の柔軟性が低下
my TOKYO GAS で扱うデータは他サービスでも有用であることから my TOKYO GAS というサービス自体が他の BtoC サービスの共通基盤として機能しており、開発の柔軟性が低下



バックエンド領域への内政化の拡大
ドメイン層のマイクロサービス化と共通基盤化
料金やポイントなど、東京ガスとして汎用的に利用できるドメインの処理・データをマイクロサービスとして切り出し共通基盤化
my TOKYO GAS 以外のサービスも共通利用できるように開発


データベースの選定
my TOKYO GAS は 500万弱のユーザーが利用しており、それに耐えうるアーキテクチャが必要となった
将来的に1000万以上のユーザーになる可能性
ユーザーが登録するデータのレコード数は膨大

内政チームの置かれている状況
内製化のためのエンジニアを多く抱えているわけではない
障害対応や保守運用も自分たちで担う
エンジニアも事業を考え、技術鵜を通じて事業に貢献することが求められている

エンジニアもビジネスに深く関わり、ビジネス価値に直結する開発にエンジニアの力を注ぎたい
TiDB の導入検証へ





TiDB 導入に向けて検証したこと
MySQL との互換性は？
特定の製品仕様にアプリケーションコードを依存させたくない

本当に期待したパフォーマンスを出せるか？
500万弱のユーザーの生成できるデータを保存でき、パフォーマンス劣化が生じないか


結果
TiDB の導入を決定、一部課題があった
ID の採番方式
AUTO INCREMENT
単調増加しない

AUTO INCREMENT(MySQL 互換モード)
単調増加する
書き込み性能が劣化する

AUTO_RUNDOM
ランダムに採番


Connection Pool
クラスタにあるノードのうち一台が落ちた場合、Connection が破棄されるまで負荷が集中する
コネクションのライフサイクルを短めに設定し、短時間で接続が分散されるようにする


外部キー制約
外部キー制約はパフォーマンスの低下を起こす可能性があり、利用を慎重に検証する必要あり
負荷試験の結果
131rps で 5分間の負荷をかけた結果、多数のリクエストでタイムアウトが発生

TiDB は共有ロックを持っていないため排他ロックになってしまう

INSERT する前後だけ、そのセッションにおける外部キー制約チェックを OFF にする処理をアプリケーション側で実装
結果として大幅改善ができた



バッチ処理での利用
バッチ処理は大規模なデータを取得するものだったが、２つの TiDB ノードに交互にリクエストを投げている様子が観測された
暫定的な対応としてメモリ解放のための時間を設けた
Node Group が GA
現在検証中





さまざまな検証の結果本番プロダクトでの TiDB の採用を決定

導入してみて
1年弱運用した中で DB 起因での問題は発生していない
いくつか TiDB であることを気にする必要がある
データ量による影響が限定的な点は大きなメリットであり、設計・運用工数を削減できる
データベース設計・運用工数を抑え、鍵ラテ他開発チームのリソースをよりビジネス領域に充てられた



Platform Team から見た TiDB
開発期間での悩みポイント
どの TiDB 製品を選択すべきか
TiDB Self-Managed
TiDB Cloud Serverless
TiDB Cloud Dedicated

TiDB Cloud Dedicated を採用する場合、クラスターの単位をどうするか
クラスタを一つに集約するか、サービスごとに分離するか
当時
全ての環境で TiDB Cloud Dedicated を採用
本番環境、STG環境では可用性確保、安定運用、監査ログの取得
DEV 環境はその要件はなかったが、一旦運用面から DEV も採用


TiDB クラスタ構成の方針検討
新規マイクロサービス開発を気に SW チームとクラスタ構成について議論を実施
新規マイクロサービスを既存 TiDB クラスタに集約する方針で開発を進める
バッチ処理による負荷をオンライン処理から分離するために Node Group の利用を検証する




Node Group の検証
オンライン処理中にバッチ処理を実行する負荷テストを実施
各 Node Group で処理実行中の時間のみに負荷が発生するようになった
Node Group を分離してもバッチ処理が正常に終了


TiDB を採用して良かった点
TiDB を起因とするトラブルは未発生
日常的なメンテナンス工数が少ない

気にしないといけないところ
TiDB Cloud ユーザーの権限粒度
求めているレベルよりも粗い
API を活用し、GitHub Actions などで細かい権限設定をしている

オートスケーリング
Native としてのオートスケーリングはない

コスト管理
API で自動起動・停止する仕組みを実装
リソースコントロール、Node Group でリソースを管理



TiDB 導入の最大の利点は・・・
エンジニアが事業貢献に集中できる


 Aurora→TiDB：1年間の移行プロジェクトとマルチテナント運用の全貌
レバテック株式会社　レバテック開発部　DevOps推進グループリーダー 金澤 伸行 氏
ざっくりまとめ
Aurora から TiDB への移行で約40スキーマを1年かけて完了、DMS 移行の課題や AUTO INCREMENT 問題を地道に解消
移行後はインデックス最適化や Node Group 活用などでメモリ・パフォーマンス課題を改善し、運用を安定化
運用工数が大幅削減され、権限管理やバックアップの自動化など DevOps 体制が進化して「運用が楽になった」
移行作業について
体制
移行には時間とコストがかかる
役割分担をして開発部全体の協力を得ながらスムーズな移行を目指す

責務を明確にした

移行方法
メンテナンスはこのタイミングでは入れた
Amazon DMS を採用
移行時にスキーマ名が重複するケースがあった
積極的におすすめはしない


事業調整 → 移行準備 → 移行をひたすら繰り返す

移行状況
約40スキーマを Aurora から TiDB に移行完了


移行に伴って発生した問題
データ移行でのつらみ
DMS でテーブル定義を連携すると必要最低限しか連携されない
外部キー制約やインデックスが作られない

デフォルトの COLLATION や CHARASET が異なる
Timestamp がずれる
UTC → JST の変更が必要


AUTO INCREMENT 問題
連番を AUTO INCREMENT で担保していたシステムが存在
接続する TiDB が切り替わると ID が飛んだリ戻ったりする

パフォーマンス
Aurora によって隠蔽されていたクエリ自体の問題が表面化
Aurora にいかに助けられていたかを改めて実感
TiDB に移行しただけではパフォーマンスが上がることはない
TiDB に合わせたチューニングが必要



メモリ管理
検索系のページで実行されるクエリ
クエリ結果が大量
大量同士の JOIN
TiDB ノードで JOIN する際のデータ量が多くメモリを逼迫

OOM によってノードの入れ替えが発生すると瞬断


RU の管理
Request Unit
単一のリクエストで消費されるリソースの単位

どう頑張っても予測できないので実際に移行するまでわからない
概算は出る
RU が消費されるタイミングはシステムによってばらつきがある
それぞれのピークに合わせて RU の最大値を設定
場合によってキャパシティを超えてしまう

クラスタの上限に合計値を合わせる
余分にリソースがかかってしまう




対応
AUTO INCREMENT
MySQL モードで対応
デメリット
一台のノードで 4000毎に ID をキャッシュする
TiDB Node 再起動や入れ替えによって ID が最大 4000飛ぶ
キャッシュする範囲は変えられない

ID の偏りにより TiKV で適切なリージョン分割がされない
ID の発行を1台の Node に依存することになる


Sequence テーブルも検討したが現時点では利用していない
連番じゃなくてもいいけど ID が大きく飛ぶことを避けたい場合
AUTO_ID_CACHE=2 みたいな使い方を一部で検証したがキャッシュの生成頻度増加などパフォーマンスに影響が出る

PK に依存した形には避ける

パフォーマンス
まずは INDEX をつけていく
INDEX Lookup を減らす
カバリングインデックスを設定する
書き込みへの影響は考慮が必要

JOIN の最適化
JOIN 前に必要なデータをシェラス

STRAIGHT_JOIN 等の仕様
JION を諦める
TiFlush に頼る
クエリの速度はある程度改善したケースがあったため、恒久対応ではなく、暫定対応とした


メモリ管理
パフォーマンス改善に取り組むことで解消されるケースが多い
INDEX の活用
JOIN の最適化

システム変数メモリ上限を設ける
想定外のメモリ消費には高係
一部システムとしての要件を満たせなくなるケースあり

Node Group を活用し TiDB Node を分割する
データ連携用の Node Group
移行用の Node Group
通常運用用の Node Group

データ取得を TiFlush に寄せる
チューニングが難しいケースで有効
JOIN が TiFlush ないで全て消費され、結果のみを TiDB に返すようになる


RU の管理
現状大きな問題にはなっていないため、最適化できていない
今後 RU 設定値の見直しとプライオリティの調整を行う予定

とはいえ必要なこと
基本的に、まずは普通のチューニングをやる
MySQL で適切なクエリが実行されていれば、特別なチューニングはほとんど必要ない
Aurora でやれることをやっていればもっと楽に移行できた


運用で工夫したこと
ユーザーやリソースグループをコード管理
誰がどのスキーマにどの権限でアクセス可能かを可視化したい
採用や異動による権限変更を容易にしたい
変更の履歴を残したい
全てスクリプトで実施


スキーマ毎のバックアップの仕組みの構築
公式のバックアップはクラスタ単位
復元の際は別クラスタを立てる方式

テーブル単位のバックアップとリストアの仕組みの構築を試みる
tiup dumping によるバックアップ作成
import into でリストア実行
現在検証環境で利用しながら構築中
公式から仕組みが提供されることに期待




今後の展望
NewRelic 連携による監視強化
メトリクス
RU は過去1日までしかデータ見れない
その他のメトリクスは過去7日

アラート
RU に対するアラート設定ができない
柔軟なトリガーが設定できない


TiProxy 導入による可用性改善
現在は Node 再起動や入れ替えによって瞬断が発生する
これを解消したい


他にも
動的なスケーリング
TiCDC によるデータ連携
分析観点での TiFlush の活用
ベクトル検索
,,,


MySQL のように使うための工夫 → TiDB としてどう活用するか

まとめ
移行は大変
ほとんどは Aurora に隠されていた問題が顕在化されただけ
DB の機能に依存した実装はしないほうがいい
Aurora でやれることをやってから TiDB を検討することをお勧め

運用は非常に楽になった
移行期間中にバージョンアップ
メンテナンスなしで無事終了
チケット起票して見守るだけ

手厚いサポート
困った時はいつでも相談できるサポート体制
DB エンジニアがチームに増えたと錯覚するレベル




 モンスター級のデータを捌け！ “助けて！”を助ける モンスターハンターワイルズのDB
株式会社カプコン　モンスターハンターワイルズ
リードサーバーエンジニア　筑紫啓雄 氏
サーバーエンジニア　戎脇涼 氏
ざっくりまとめ
クロスプレイ実現のためにモンハンワイルズでは自社ネットワーク＋AWS基盤上で構築、膨大なリアルタイムトラフィックを捌く必要があった
救難信号レコード管理に TiDB を採用し、自動シャーディング・スケールインアウト・TTL などで爆発的なデータの生成削除に対応
結果としてノーメンテでスケール調整可能な高可用DB運用を実現、TiDB が“モンスター級”の負荷を支える基盤となった
前作とのネットワークにおける大きな違い
自社ではネットワークを管理せず、1st パーティプラットフォームのネットワークを利用してオンラインを実現
別プラットフォームとは一緒に遊べないという課題があった

自社で管理するネットワークを用意することによってプラットフォームを超えて一緒に遊べるクロスプレイを実現

モンスターハンターワイルズは AWS 利用
EKS on Fargate + VPC Lattice
リアルタイムサーバはレイテンシをできるだけ少なくするため複数リージョンに設置
こっちは Fargate は使っていない

AWS リソースへのアクセスは API サーバを経由
クエストセッションは P2P 通信
ピーク時 100万人以上同接
API サーバ 1600 vCPU
リアルタイムサーバ後継 18000vCPU
…

API サーバはスケールアウトでトラフィックを分散
場合によって別リージョンから拝借

データを扱う部分がスケールが難しい
単一の DB では耐えられないトラフィック
途中でスケールが簡単にできる
巨大なトラフィックに耐えられる
運用負荷が少ない

Dynamo DB
対象を一人に取るデータを扱う機会が多い
事前申請したユニットベースで性能が決まる
スケールアウトは Quota 申請した分まで可能
複雑な検索に弱い
モンスタハンターワイルズでも複雑なクエリが必要になるケースがある
カーディナリティも低い
DynamoDB では耐えられず、RDB を使わざるを得ない


RDB
カーディナリティが低いので INDEX 効果が薄い
リードライト両方の頻度が高い
レコード数も多い
チューニング後に取れる解決方法は？
性能でゴリ押す・・・
水平分散
台数に応じて増やすことができる
アプリの複雑化やユーザー数でてを入れる可能性が高い




TiDB を利用
開発当初は Aurora Serverless v2 を利用
水平分散の複雑さを考慮して TiDB
ダウンタイムなしでスペック変更可能
台数増減も簡単にできる
マネージドサービス
MySQL 互換なので移行も楽

他の選択肢
DSQL
Spanner
Cockroach DB




ワイルズのどこで TiDB を使ったのか
救難信号！
オーダー
クロスプラットフォーム
検索条件を増やしたい
前作より便利に
満員時の挙動
ホスト切断時の挙動

クエスト P2P セッションは別サービスで


立ちはだかる壁
クエストセッション(実態)は外部サービス
独自サーバからセッションの開始・終了が取れない
でも、終了したクエストのレコードは消えて欲しい

検索条件の種類は開発初期に確定
諸々合わせて 10 種類
各条件、どんな組み合わせが使われるかは不明
データの傾向が事前に読めない

全世界・全プラットフォーム同時発売は初めて
初日の同接数が全然読めない


救難信号レコードの特性
揮発性が高いデータ
最長でも生存期間は1時間程度、平均 10~20分程度
レコードの作成・削除が常に行われ続ける

これ、本当に RDB で管理していいのか？
カーディナリティがとても低い
常に作成・削除が行われるレコード
検索条件は複雑だけど構造化されている、全文検索までは不要
総レコードは数万から数十万くらいの想定
他に適したプロダクトが思い浮かばない
最初は Aurora Serverless v2 を使用


設計
DynamoDB RDB の二重管理
DynamoDB には「クエストセッション情報」
RDB には「検索レコード」

RDB の懸念
検索条件は 10種類程度
毎回全条件指定されるわけではない
何が来るかわからないので頻出クエリを絞れない

全パターンをカバーするインデックスを貼ると 100以上
レコード作成・削除時のインデックス再構築コストを懸念

このカーディナリティならフルスキャンでも変わらない？
そんなことはなかった。。。


テーブル分割
いくつかの条件をテーブル名で持つ
クロスプレイ設定、プラットフォーム、フィールド、難易度
絶対に無くならない・使用頻度が低い条件
200テーブル程度になった


これらの条件は検索クエリに含めない
4条件指定されている時は対象テーブルを一意に特定
条件を満たすテーブルから複数選んでクエリを投げる
1テーブル15インデックス程度に収まった

定義ファイルや各種SQLは自動生成

未解決問題
「条件の偏り」はみ考慮
条件毎に参照頻度が異なる
クロス有効・無効で大きくレコード数が異なる
人気クエストは少数のテーブルに集中しそう

規模的に1node では負荷を捌けない
一般対策
テーブルを複数ノードにシャーディング
とりあえず今すぐ動くものが必要
全てを棚上げして月日が経つ



TiDB を使うことによって棚上げしていた問題が解決した
何が解決したのか
自動データベースシャーディング
水平方向のシャーディングは TiDB にお任せ
1テーブルの孵化を複数ノードで処理

テーブル分割自体はそのままにしておく
大した管理コストではない & インデックス構築の負荷は厳しそう



流石に考えが甘かった
負荷試験でそれなりに詰まる
レコードの作成・削除の頻度が高いことによる負荷
TiDB は追記型
履歴データが大量に溜まって性能悪化


履歴データを減らす、見ないようにする対策を入れる
Compaction Filter の無効化
In-Memory Engine の利用 (当時は experimental なので検証だけ…)


その他のチューニング
レコード作成リクエストのキューイング
API サーバー → SQS → レコード更新ワーカー
API レスポンスタイムへの DB 性能影響軽減
ワーカー数により TiDB への同時アクセス数を制御


クエリキャッシュ導入
共通キャッシュサーバを利用
同一検索クエリは3秒間だけキャッシュ
アプリケーションレイヤーでの実装



OBT、本番リリース時
負荷が下がってきたタイミングでスケールインを実施
TiDB, TiKV
ノーメンテナンス、オンサービス
全くトラブルなし

一部のクエストのみが遊ばれるような環境
２、３テーブルにレコードが集中
TiDB 側に分散を完全に任せたが特に問題なし
最大レコード数は 10万レコード程度



TiDB を導入して嬉しかったこと
いつでも性能調整できる安心感
スケールイン・アウトがサービス影響なしで行える
気軽に増やせて、気軽に減らせる

TTL の利用
どうしても消え残るレコードが存在
TTL で勝手に消えてくれて助かる

水平シャーディングは完全に任せきり
任せきりでもうまく分散してくれた
レコード０状態から急激なレコード増加がある場合は注意おかも。。。
削除が多い場合も注意



まとめ
TiDB は大規模でダウンタイムなしなプロダクトの DB では有力候補


 AI駆動開発時代におけるTiDB Cloud活用術
クラスメソッド株式会社　クラスメソッドゲームソリューション部　ソリューションアーキテクト　頴川 武生 氏
ざっくりまとめ
生成AIがコードを書く時代では、AIが理解しやすく扱いやすい「AI-Ready」なデータベースが重要
TiDB Cloud は MySQL互換・標準SQL・HTAP構成により、AIとの親和性が高く自然言語SQL生成やベクトル検索にも対応
クラスメソッドは Auth0 や Kong などと組み合わせて、AI駆動開発を支えるモダンなクラウドアーキテクチャを提案
message
生成 AI がコードを書く時代、データベースも ”AI-Ready” であるべきだ

誰もがフルスタック開発者に
アーキテクチャ設計
自然言語で要件定義
技術スタック最適化

コード実装
フロントエンド
バックエンドAPI
テストコード

デプロイ
CICDパイプライン
メトリクス
監視


データベースで詰まる現実
技術選定
何を選択すればいいのかわからない
ローカル環境での起動方法

デプロイ
ホスティングとは別にリソースが必要

コスト
起動しているだけで料金がかかる場合が多い


AI が書きやすいデータベースとは
学習データが豊富
MySQL, PostgreSQL

シンプルで予測可能な構造
正規化されたテーブル設計
明確な外部キー関係
一貫性のあるデータ型

標準的な構文に準拠
SQL標準
NoSQLは方言が多く、AIが生成するコードが動かない可能性

クラウドネイティブ
API ベースのアクセス

TiDB Cloud は AI 駆動開発に最適
学習データが豊富
MySQL 互換

標準的な構文
特殊な方言が少ない

予測可能な動作
ACID,外部キー

クラウドネイティブ

AI のよくある失敗は TiDB Cloud のツールで解決

AI-Ready なデータベースとは？
AI がその能力を最大限に発揮できるように設計された、AI にとって「気が利く」データベース、とここでは定義
3つの要素
言葉で対話できる
Chat2Query
自然言語で SQL を生成
API も提供可能


意味を理解する
ベクトル検索
セマンティック検索で RAG 実装が簡単
一部のリージョンでは自動埋め込みにも対応


常に最新の情報を持つこと
HTAP アーキテクチャ
OLTP と OLAP が共存




AI 工藤開発の完璧な相棒
AI が書きやすい
AI アプリに必要
コスト
充実した無料枠


高速な開発が生む「次の課題」
シャドウITの増殖
認証・認可の複雑化
セキュリティ

クラスメソッドと始めるモダン開発
Auth0やKong など、モダンな SaaS を適切に組み合わせる
AWS だけではない
全体最適を提案できる




 TiDBを活用したクラウドネイティブミッションクリティカルシステムの実現
TIS株式会社　サービスプラットフォーム第１部　セクションチーフ　根来 和輝 氏
ざっくりまとめ
日本の多くのミッションクリティカルシステムがレガシー技術に依存し、DX や最新技術導入の足枷になっている
TIS は「Lerna」スタックを開発し、Design for Failure思想と TiDB を組み合わせて高可用・高一貫性・ゼロダウンタイム運用を実現
TiDB のリソース制御や分散トランザクション特性を活かし、クラウドネイティブ環境でも99.9999%稼働を目指す高レジリエンスな基盤を構築
なぜ実現する必要があるのか？
ミッションクリティカルシステムはレガシーな技術に頼ってきた
ビジネス機会損失に直結するため 24/365 稼働が必須
金額等を不整合なく更新しなければならない
FT サーバを採用すると障害発生リスクや開発コストの観点で過去資産の利用が最適解になりやすく古いプログラミングデータや固定長データといったレガシー技術への依存が生じやすい


レガシーシステムが日本の IT 活用の足枷になっている
日本企業の61％が保有するレガシーシステムが足枷になり DX が進まず産業競争力が低下の一途を辿っている
生成 AI などの最新テクノロジーを活用しおづらい
技術者の確保が難しい
利用技術の撤退や一方的な値上げなど
状況の変化に対応しずらい


脱却したいが、その壁
99.999% の効果養成を実現する必要があるがインフラ障害が必ず発生する前提に立つ必要がある
分散することで通う政治向上を図る設計が必要だが、データを分散すると一貫性の維持が難しくなる
システムの構成変更をオンデマンドで実施したいが無停止で行う必要がある
従来とは異なる方法論が必要


Lerna ソフトウェアスタックを開発
Design for Failure な設計思想
高いレジ離縁シートスケーラビリティ
ゼロダウンタイムな運用
データベースには TiDB を採用し、トランザクションの高い可用性と強い一貫性を実現

「高レジリエンスオプション」サービスを始めた
Lerna をはじめとする TIS のノウハウを活用
ミッションクリティカルなシステム開発



どのように実現するのか？
クラウドネイティブなシステムでは障害が必ず起きる前提に立った設計が必要
AZ 間のネットワーク障害に備える
TiDB は一貫性を維持する代わりに孤立した AZ のクエリを拒否する

重要なワークロードの即応性を保護する
オンライン処理のワークロードが最も重要
TiDB のリソース制御構造でオンライン処理の即応性を保護


その他の検討事項
障害が発生してもシステム関連系の整合性を保つ
キャパシティの変更を無停止で実施する
バージョンアップを無停止で実行する
…




 TiDB導入、本当に大丈夫？〜不安を解消する開発・運用サポートの舞台裏〜
アイレット株式会社　カスタマー支援事業部　事業部長　本田 卓 氏
ざっくりまとめ
TiDB は「MySQL のすごい版」という期待に対し、PingCap の手厚い技術支援が不安を払拭してくれる
Slack 上での即時対応や負荷試験・構築・スケール運用まで具体的かつ実践的なサポートを提供
初めての TiDB 導入でも「わからないから教えて」で安心して進められる環境が整っている
TiDB に抱く夢と現実と希望
開発現場が抱く夢
TiDB はMySQLのすごい版
めんどくさいシャーディングやスケーリングを全てやってくれる

現実
TiDB の利用経験が少ないけど使いこなせるか
MySQL 互換だからとすぐに飛びついてしまっていいか？
問題が起きた時にインターネット上にあるだけで解決できるか

希望

PingCap はどんなサポートをしてくれるか？
Slack に Join してくれその場で質疑応答に対応してくれる
テンプレ返答が返ってくることはない
負荷試験やレビュー資料なども確認、協力してくれる
TiDB 利用での問題などを定期的に確認してくれる

実際のサポート事例
主キーに設定する ID の生成方法について
Snowflake で大丈夫、と明確に返答をもらえる
別のアルゴリズム所感ももらえる

開発環境の構築はどう使い分けたらいいか？
細かくわかりやすく教えてくれる

負荷試験をサポートしてくれると聞いたが。。。
PingCap 側でも時間を共有すれば伴走してくれる
事前に対応したほうがいいことなどのアドバイスももらえる
プライベート提供なども先行提供してくれる

スケールイン・アウトにかかる時間について
標準的な時間を明確に示してくれる
曖昧な返答はない

ローカル環境の構築について (TiDB Software 版の利用)
OS レイヤーのサポートもしてくれる
有償版使えば解決などに促されない

緊急メンテナンスウィンドウの連絡
直接連絡をくれる
影響範囲を明示してくれる


まとめ
チャットベースなので質問をしやすく返答も早い
リリースまでに生じる疑問や不安の解消にとことん付き合ってくれる
返答と共にベストプラクティスのアドバイスがついてくることが多い

初 TiDB で自信がなくても大丈夫
わからないから教えて、で大丈夫
かなり親身に相談に乗ってくれる




 リリース時のアクセス急増をいかにしてノーメンテで乗り越えたか 〜『Shadowverse: Worlds Beyond』におけるTiDB採用のゲームサーバー設計〜
株式会社Cygames　サーバーサイド　エンジニア　青木 淳 氏
ざっくりまとめ
Shadowverse: Worlds Beyond は TiDB を採用し、AWS ECS 環境でシームレスなスケールアウト／アップを実現
リリース直後のアクセス急増時もノーメンテで対応し、最大 50万 QPS を安定処理
TiDB の分散構造と MySQL 互換性を活かしつつ、エンジニア側もホットスポット対策やインデックス設計を最適化して最高のゲーム体験を支えた

Shadowverse WB の構成について
Cloud
AWS ECS

Rest API
PHP

リアルタイム通信
Magic Onion (C#)

データベース
TiDB


システム構成図
API サーバ
外部からアクセス可能なサーバ
内部通信専用サーバ
ALB を経由して通信


リアルタイム通信
コンテンツごとにクラスタを分けて適用
クライアントと直接通信

TiDB Cloud
ゲームサーバと VPC ペアリング


従来の RDBMS の問題点
負荷増加のジレンマ
システムスケールが必要
メンテナンス時間が必要
ユーザーに迷惑をかける

複雑化の悪循環
単一 DB では限界

従来の RDBMS のスケールアウト
水平分割
垂直分割

計画通りにいかない
想定以上のユーザーが殺到
プロダクトとしては成功したが、システムは悲鳴をあげてしまう
メンテナンスが必要でサービスが一定期間停止してしまう
機会損失が連鎖する



シームレスなスケーリングで解決
TiDB の選択
データの完全性を担保できる
TiDB は分散型でありながら完全性を担保

Cygames では MySQL を使用している
MySQL 互換性が高くアプリケーション開発者としては扱いやすい

サーバリソースを効率的に活用できる
バランスよく利用可能
Node はステートレスなのでコスト削減にもできる
Cygames の Engineer Blog に出ている



まとめ
従来の問題点
メンテナンスが必要
システムが複雑化する

課題解決のため
シームレスなスケーリングが必要



TiDB を使うために行ったこと
考えを変える必要性
MySQL 互換といえども従来の意識で実装するのはNG
ホットスポット
特定のノードに負荷集中する危険性

インデックス設計
分散キーを意識しないと性能劣化



対応例
MySQL ではインデックスを使う前に Primary Key を検討する
TiDB では時系列にソートできるランダム文字列である ULID を使う

TRUNSACTION 分離レベル
デフォルトは REPEATABLE READ
Shadowverse では READ-COMMITTED に変更

事前準備
負荷試験
障害試験
耐久試験
スケーラビリティ試験
TiKV はいずれも問題なし
状況に応じてスケール戦略を選択する方針に

TiDB はスケールアウト以外の操作でエラーが発生
コネクションが切断される
確実性をとってサービス稼働中はスケールアウトのみにする方針にした



まとめ
TiDB に合わせてエンジニア思考もアップデート
ホットスポット、インデックス設計、トランザクションん分離レベル

準備
負荷試験、障害試験、耐久試験、スケーラビリティ試験



リリース
不確実性に対して
安定したサービス提供が必要
サーバリソースをうまく使った運用方法を追求

２つの戦略
スケールアウト
サーバ台数を増やす

スケールアップ
サーバのスペックを上げる
スケールアウトを基本としつつ、スケールアップも手段に入れ、両輪の戦略でリリースを迎える



リリース直後
徐々に流入が始まる
リリース時間に合わせて右肩上がり、期待以上の反響だった
システムは想定以上の負荷に直面
API サーバの CPU 使用率が8割近くなったのでシステムスケールを判断
CPU 使用率が急激に増加したのでスケールアウトで素早く対応
グラフの上がり方から 1.5倍の台数で落ち着くと予想

TiDB の CPU 使用率が 8割近くなったのでシステムスケールを判断
CPU 使用率が急激に増加したのでスケールアウトで素早く対応
1.2倍の台数にし、少しずつ様子を見ることにした


ノーメンテでシステムスケールを実行
安定化
負荷は緩やかな上昇


PingCap との相談の上、TiKV のスケールアップを検討
ピーク時の使用率が 60% まで上がっていた
夜の更なる負荷増加が予想
夜のピークタイムは昼以上のアクセスが発生
夜間バックアップ処理による追加負荷

TiKV のスケールアウトは以下の理由による除外
データリバランスによって CPU リソース消費
処理完了時間が不明
1日のピークタイム前のため安全性を重視

TiKV のスケールアップを念の為再試験
ダウンタイム０でエラーなくスケールアップが可能か確認
エラーなくスケール処理が完了することを確認
夜間のスケールアップを実行


20:30 ~ スケールアップ開始
20:40頃から TiKV の各ノードが 1つずつローリングアップデートされていく
QPS は 40万程度出ていたがノーメンテで実施

ピークタイムは 50万 QPS 、システムはすでに増強していたため危険域には届かなかった
翌日以降も上がったが問題になることはなかった




まとめ
期待以上の反響でリリース告知時間からアクセスが急増
ノーメンテのシステムスケールで最高のゲーム体験を提供
API サーバと TiDB のスケールアウトでノーメンテ対応
夜のピークに向けた TiKV のスケールアップ




運用上の課題
オンライン DDL
lock wait timeout 頻発
統計情報の履歴を保存する機能の問題
analyze table の旅に統計情報を自動記録する

各テーブルは自動で analyze する

Shadowverse ではこれを OFF に設定
tidb_enable_historical_status



まとめ
最高のゲーム体験のため ECS TiDB で柔軟なシステムを実現
TiDB に合わせてエンジニアの思考もアップデート
リリースもノーメンテで乗り越えた


 ecforceサービス運用者が語るTiDB Cloud本番運用1年半のリアル
株式会社SUPER STUDIO　SREグループ　執行役員　田幸 久志 氏
ざっくりまとめ
RDS/Aurora で350超のDBを運用していた複雑な環境をTiDB Cloudに集約し、運用コストを最大40%削減見込み
移行作業では DM や binlog 設定、AUTO_ID_CACHE の扱いなど細かな課題を地道に解消し、現在は安定運用中
パフォーマンス調整・スケーリング制約・再起動運用など課題は残るが、PingCapの支援と継続的な改善でクラウドネイティブDB運用が定着
TiDB 以降の背景と現状
350超の DB クラスタがそんｚ内することで DB 管理が複雑化
物理コスト・運用コストの増大
サービスを停止するメンテナンス作業
他サービスと連携するアーキテクチャを考える制約

検討・導入経緯
2023/07: コミュニティ版評価開始
2024/01: TiDB Cloud 評価開始
2024/05: 本番導入開始
現在全体の 70% くらい移行完了


コスト効果
移行前の水準で RDS を継続運用した想定と比べ 15% 程度削減されている
最終的に 40% くらいの削減を見込んでいる


移行作業の詳細
移行概要
350超の DB クラスタ (RDS, Aurora)
ショップごとに Database が存在
Database を TiDB に DM でいこうし、アプリケーションの参照先を切り替える

移行手順
移行元の DB の binlog を有効にする
移行元の DB と TiDB クラスタを VPC ペアリングで接続する
移行元の DB からスキーマを dump
スキーマのデータを一部加工し TiDB にインポート
AUTO_ID_CACHE の追加
注意点
1ずつ増えることを保証していない
特に再起動などで亡くなった時に値が数千番規模で飛ぶ
単調増加することを保証するくらいの感覚で使用する


AUTO_INCREMENT の値の削除
移行し始めてから判明した問題に対して対応
スキーマを dump して TiDB にインポートし、DM で同期するまでの間に移行元 DB のデータが増えるとデータが追加できない問題が発生する




切り戻し
TiDB から提案された手順に従って実施

移行時に発生した問題の対応
DM は RCU が設定できるが、RCU の数字を挙げると移行元の負荷が上がるので、移行元の DB スペックに合わせて RCU の数字を調整する
移行元 DB は binlog を有効にする必要がある、binlog を有効にした後、移行が完了するまでに大量アクセスがあると、RDS のディスク使用量が急に圧迫されることがあるので注意する
DM を途中で止めた時、DM の中継サーバと移行元 DM の間でプロセスが残ってしまうことがあるので、DM を止めた場合は DM のプロセスが残っていないかどうか確認する
DM で同期し、TiDB に切り替えたショップでレスポンスが悪く、analyze table を実行して解消するケースが時々発生


運用の変化と対応
基本的に問題なく運用できている
アプリケーションの機能はほとんど手を加えないで動作している
RDS と比べて運用の手間が増えていることはない

パフォーマンス問題への対応
RDS と比べてクエリのレスポンスが遅くなる (ms 単位)
完了までに多くのクエリを必要とする処理が遅くなる
ページのレスポンスが遅くなる
ジョブの実行時間が長くなる

地道にロジックを修正することで対応
N+1 のロジックの修正
繰り返し呼ばれるクエリを redis に逃す


単純に遅くなる以外の障害例
ページのレスポンスが長くなった結果 API のレスポンスが遅くなり ELB のタイムアウトに引っかかり 504 エラーに
ジョブの終了が遅くなることにより、終わる時間を想定して設定していた他の処理に影響
redis にクエリを逃したことで redis のレスポンスが悪くなりアプリケーション全体のレスポンスが悪くなる

クエリあたりのメモリ使用量の上限
今まで引っ掛からなかった一つのクエリを処理するためのメモリ使用量の上限が設定されている
複雑なクエリを生成するロジックで発生
TiDB の設定値で調整することも可能

データマイグレーション
DDL に時間がかかる (最低 0.5s くらいかかる)
数百ショップ分のリリースが同時に実行されるとデータのマイグレーションの worker が詰まり、リリース時間が数時間伸びる
TiDB 設定で調整できるか検証中

その他
今まで ID 順に帰ってきたクエリ結果がバラバラになり、並べ替えをするよう修正
特定の処理で deadlock が起こりやすくなり、TiDB 側の設定を変更
サブクエリで ON句がサポートされておらず、クエリを修正
TiDB のデータサイズ時制限の問題があり、TiDB の設定を調整


TiDB クラスタのスケーリング
TiDB 移行済みのショップについては細かな調整をする必要がなくなった
大きなキャンペーンを計画されている場合のみ DB 側を対応

サーバのスケーリング台数を大きく設定できるようになった
TiDB node をスケールする基準はわかりやすいが、TiKV node をスケールする基準が掴めていない
TiDB クラスタのスケーリング制約
TiDB node の台数を変更するときはあまり制約なし
TiKV node の台数を変更するときは 3台単位
コストインパクトが大きい
スケールが完了するのに時間がかかる (3→9台で 36時間)
スケール中に変更ができない


TiDB クラスタの node の再起動
データの性質の問題か、メモリの使用率があがりがち
メモリの使用率が高い状態が続くとクエリがキャンセルされることが発生するため、時々再起動をする運用をしている
TiDB Cloud コンソールには再起動をするオプションがないのでスケールアップダウンを実施して対応
node を個別指定して再起動できないので 全node で再起動


テーブル数の削減
ショップごとに Database があり、それぞれ数百程度の Table がある
移行元の DB で partition を作成していると TiDB 移行後、それが table として認識される

アラート設計
TiDB Cloud で設定できるアラートは memory, CPU, ストレージのみ
メトリクスで見れる指標でアラートを仕込みたい
NewRelic の活用


TiDB のログ
クエリの実行ログは S3 にエクスポートできる
RDS で保存できた生ログが保存できない
長期保存されていない

監査関連
基本的には問題ない運用ができている
ユーザーの権限設定は大まかなグループでのみ設定可能
ユーザー管理に該当する API がない

コスト関連
RDS コスト以外に VPC Endpoint の料金が追加で発生している
評価環境を作るのに追加でかかる
リストアがクラスタ単位

PingCap のサポート
特に問題なく対応
問い合わせ窓口の他に担当エンジニアがいる
深夜対応にも対応してもらえている




今後の運用課題
パフォーマンス改善
TiDB へ移行するしないに関わらず、サービスのパフォーマンスの改善

hotspot の改善
アクセスが多い場合はスケーリングで解消できる

メモリ使用率の最適化
再起動運用を解消したい



 スケールと信頼性を求めて：メルカリ流TiDB移行とベストプラクティス
株式会社メルカリ　Platform　小山 智之 氏
株式会社メルカリ　Platform　前田 敦史 氏
ざっくりまとめ
40TB超のオンプレMySQLをTiDB Cloudへ移行、ProxySQL＋DM/Dumpling＋TiCDC＋独自クエリリプレイで低ダウンタイムかつ互換性・スケール・運用性を確保
Graceful maintenanceを徹底、connection poolingや監視分界を整理しつつPingCapと協働でシャットダウン挙動を改善して全クラスタに展開
Resource ControlやDatadog連携を実装し、RU配分・優先度制御・SQL Bindingで障害回避とコスト按分を実現、可観測性も強化
プロジェクトの概要・移行の流れ
DB サーバのデータ量
4年間で倍増、40TB+

アプリケーションは Google Cloud、DB サーバはデータセンターに MySQL がインストールされている
DB サーバは 50台以上
データサイズは 40TB+

課題
Scalability
ハードウェアのキャパシティ

Elasticity
新たに DB サーバのセットアップに 1.5日

Operation
DDL 適用に数時間から数日


解決策として TiDB Cloud
移行先を Public Cloud に決定
PoC
観点
Scalability
Elasticity
Operation
Compatibility


プロジェクト概要
移行対象
オンプレミスの MySQLサーバ

期間は 2024-10 ~ 2025-10
影響範囲
メルカリとメルペイの一部


移行の流れ
事前準備
TiDB は分散データベースであるためクエリレーテンシの増加が懸念された
アプリケーションの影響を評価
ProxySQL で再現
評価観点
API レイテンシ
エラー
モバイルアプリのレスポンス体験


マシンの用意
2台のレプリカを作成
Relay
MySQL から TiDB への動機用のレプリカ

Fallback


データの同期
ダンプデータを Dumpling で同期
GTID をメモしておく


差分データの同期
メモしておいた GTID を使って差分同期を実施

Fallback の付け替えとレプリケーション停止
Fallback 用の MySQL へのデータ同期 (TiCDC)
Relay から Fallback へのレプリケーションを停止
TiCDC を作成
TiCDC で TiDB から Fallback へデータ同期

sync-diff-inspector の実行
Relay と Fallback のデータを比較して差分チェック
Master から Relay へのレプリケーションを再開

クエリリプレイ
TiDB のクエリ負荷やリソースの使用量を確認するために独自にクエリのリプレイツールを開発
eBPF ベースのライブラリを使った軽量なパケット処理を実現
SELECT クエリのみ再送

切り替え
透過的に TiDB に切り替えるために ProxySQL を設置
READ のトラフィックを TiDB に切り替え
ダウンタイム
ダウンタイムを最小限にするために、スクリプトを作成し以降の手順を自動化
Master を読み取り専用モードに切り替え
DM がオンメモリに持っているデータをディスクに書かせるために空の DDL を発行
同期確認をするために GTID を比較
TiCDC の Checkpoint TS の値と READ ONLY 後の Checkpoint を発行した直後のタイムスタンプを比較


Proxy SQL の宛先を MySQL から TiDB に切り替えることで Master を切り替え
元の MySQL と GTID が異なるためリセットを行う
元の MySQL にレプリケーションを向ける


まとめ
40TB+ のオンプレミスの DB が存在
スケールの限界、セットアップ所要時間、DDL 時間適用の時間

解決策として TiDB Cloud の採用
書き込みのスケール、柔軟な台数の増減、オンラインDDL、MySQL との互換性

移行
レイテンシ増加の影響評価
クエリリプレイ評価
ProxySQL を使った透過的な切り替え
整合性のチェック



graceful maintenance への取り組み
接続タイムアウトの影響
シナリオの仮定
通常の処理が 3ms
接続タイムアウト 3s
サーバ5台、うち1台がタイムアウト
この状態だと通常の1000倍の時間がかかる



既存接続
発生事象
長いトランザクションが中断される

対応
既知の処理時間ｗの酒メンテナンスを行う
長くない接続についてはある程度緩める
メンテナンス時間とのトレードオフ



新規接続
発生事象
connection refused
connection timed out

特にタイムアウトは大きな影響が発生する
ProxySQL connection pooling
方針
新規接続の回数を減らす

ある程度 backend で非同期咲かされることで解消される部分もある
スケールアウトが遅くなるなどのデメリットもある



ProxySQL の恩恵
都度接続のアプリケーションに対しては大きな効果を発揮する
connection pooling によりエラーが軽減


Managed Service で Proxy SQL を利用する際の注意
ProxySQL と監視責任分界点
デフォルトの設定では異常があれば切り離す
エンドポイントを使用している時に注意が必要
バックエンドの切り離し、隔離に配慮が必要



Graceful Shutdown 事態の改善
直接修正はできないが、改善に向けて取りうる手を取る
発生している問題の仮説と改善を整理して提案
PingCap 社とメルカリの協働により問題が解消
5月にリリースされ、全Clusterに適用



まとめ
PingCap と協力しながら graceful maintenance 化を実現
graceful でないものには配慮が必要


Resource Control (RC)
MySQL では 8.0 〜 Resource Group が利用可能
TiDB の Resource Control
TiDB, TiKV で個別の制御が必要
RU の制御
ランナウェイクエリの検出
セッション管理
SQL Binding の活用


RC は何に活用できるか
Monitoring 指標
優先度制御・リソース割り当てによる全体障害の回避
クエリの制御によるリソース利用料の最適化
コスト按分

RC の導入方法
ユーザーレベルの設定、ヒント句の設定、SPM(specific query patterns) による設定など用途により多様な設定が可能
導入例
リソースを利用しているユーザーを特定
TiKV Top5 SQL などから負荷傾向を解析
負荷を発生させているユーザーを特定
影響を与えているクエリを特定
SPM で対処可能な場合はアプリケーションｗの変えずに SPM で一時的にリソースグループを付与
リソースグループを割り当てると様々なメトリックが観測できる
TiKV のリクエスト数
TiKV CPU 利用時間
読み取りバイト数
書き込みバイト数



実際に制限を入れる
実際の観測
statements_summary の観測
slow query の観測

その他の導入例
CDC ユーザなどの優先度を下げる
危険なクエリを KILL
処理量の多いクエリの優先度を下げる
豊富な QUERY LIMIT パラメータがあり、様々な条件で活用できる






まとめ
RC はすごくおすすめ
RC には柔軟な設定方法がある
導入ステップや監視項目の例について紹介


Datadog APM の活用
Database への AI 活用
APM に保存されるベースライン情報の蓄積、活用は最も可能性のあるものの一つ
datadog はメルカリにはフィットしていた
API の充実
MCP 対応
すでに多くのサービスで活用されていた

datadog monitoring は素晴らしい

現状 TiDB では利用できない
似た機能はあるが Datadog の方が優れている

実装することにした
現状の機能がどのように実装されているか
MySQL と TiDB の差分を理解
どうしたらいいかを考えて実際

MySQL と TiDB の統計情報の違い
MySQL の Performance Schema は利用できない
クラスタ、ノードレベルで統計が存在する
などなど統計情報は難しい

丁寧に紐解いて行った結果 Datadog で見ることができるようになった

Datadog のバックエンドに手を加えずに使える範囲でやれることを実施
できるようになった
時間ごとのクエリ数の数、所要時間の統計
Explain Plan の確認
datadog 標準機能との連携

できていないこと
待機イベントの解析
TiDB 固有の統計情報の蓄積、活用

Datadog に提出したPR 自体は Close されることとなった
メルカリでは利用を継続することを許可してもらった


まとめ
既存の Datadog の backend を回収しなくていい範囲で動作するものを開発

現在の取り組み
コスト効率の改善
Auto Scaling の実装
datadog database monitoring for TiDB の活用
TiDB User Day 2025 に参加なぅ

東京ガス内製開発チームリーダーが語る TiDB本番運用の今

講演者

Aurora→TiDB：1年間の移行プロジェクトとマルチテナント運用の全貌

モンスター級のデータを捌け！ “助けて！”を助けるモンスターハンターワイルズのDB

AI駆動開発時代におけるTiDB Cloud活用術

TiDBを活用したクラウドネイティブミッションクリティカルシステムの実現

TiDB導入、本当に大丈夫？〜不安を解消する開発・運用サポートの舞台裏〜

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

ecforceサービス運用者が語るTiDB Cloud本番運用1年半のリアル

スケールと信頼性を求めて：メルカリ流TiDB移行とベストプラクティス

Discussion

東京ガス内製開発チームリーダーが語る TiDB本番運用の今

講演者

Aurora→TiDB：1年間の移行プロジェクトとマルチテナント運用の全貌

モンスター級のデータを捌け！ “助けて！”を助ける モンスターハンターワイルズのDB

AI駆動開発時代におけるTiDB Cloud活用術

TiDBを活用したクラウドネイティブミッションクリティカルシステムの実現

TiDB導入、本当に大丈夫？〜不安を解消する開発・運用サポートの舞台裏〜

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

ecforceサービス運用者が語るTiDB Cloud本番運用1年半のリアル

スケールと信頼性を求めて：メルカリ流TiDB移行とベストプラクティス

Discussion

モンスター級のデータを捌け！ “助けて！”を助けるモンスターハンターワイルズのDB

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