TiDB Cloudのカスタムコントローラーによるオートスケール対応

TiDB Cloud dedicatedにおけるTiKVのオートスケール対応について紹介します。TiKVの水平スケール、垂直スケールでそれぞれ何が起こるか、どういう時にどちらが適しているかの整理を提示します。また、TiKVの水平スケールにおいて発生した問題への対応をいくつかご紹介します。

Transcript

1. TiDB User Group 10, 2026年9月11日 TiDB Cloudのカスタムコントローラーによる オートスケール対応 株式会社メルカリ DBREチーム 前田 敦史 (まえあつ) 1
2. 本日の発表 • これまでの発表内容 • TiKVの 垂直スケール vs 水平スケール • TiKV 水平スケールの実践における課題 • a. 負荷の偏り b. 一括でスケールするか、小刻みにスケールするか c. 負荷分散が遅い お知らせ a. メルカリのコントリビューション(terraform provider) b. TiDB User Day c. 絶賛採用中 2
3. 今日伝えたいこと • オートスケールのブログの記事の続きの取り組み. ◦ メルカリはTiDBに対して、深いレベルで取り組んでいる • メルカリでは、DBREチームのメンバーを募集中 3
4. これまでの発表内容概要 • メルカリでは2025/11にステートレスなTiDBの水平方向のスケール を実現. ◦ TiDB CloudのAPIを利用して、Google Cloudのk8sのカスタ ムコントローラーとして実装 2025/11 4
5. 本日: TiKVのオートスケールについて お断り: 時間がなくなったら、お知らせコーナーを優先し、 残りはブログ記事での紹介にします。 5
6. TiDB(TiKV)のアーキテクチャ (1/2) • TiKVは実データを持つ ◦ 同時にTiKVはコンピュートリソースも持つ 必要なコンピュートリソースが 1日の中で 変化する場合、水平スケールで対処でき る 6
7. TiDB(TiKV)のアーキテクチャ (2/2) • PDはデータの場所を管理 • デフォルトで3つの複製 • 「リージョン」と呼ばれる単位で データは管理される 7
8. TiDB Cloudの制約 補足: TiDB Cloudはtidb-operator v1で ノード数をコントロールしています. • TiKVのノード数は3の倍数 ◦ • ゾーンごとにノード数は同一 ▪ asia-northeast1-a ▪ asia-northeast1-b インスタンスクラスまたはノード数 ▪ asia-northeast1-c TiDBまたはTiKVの変更をした際, クラスターはmodifying状態となり、再度 available状態になるまで追加の操作はできない 8
9. TiDBの実装 : TiKVの水平スケール (1/2) • スケールアウト (水平スケール) ◦ ◦ ◦ ◦ ノードを追加してクラスターはすぐに availableになる (※) 見かけ上、リーダー移動から始まる リージョン（実データ）の移動は時間が かかる リーダーの移動は短時間で終わるた め、読みとり負荷の分散は比較的短 時間で終わる(※2) ※TiDB Cloudの仕様 ※2 標準動作であるリーダーノードへの読み取り(tidb_replica_read: leader)を利用の場合 9
10. TiDBの実装: TiKVの水平スケール (2/2) • スケールイン (水平スケール) ◦ ◦ 全てのデータを退避完了後に初 めてノードが削除(コスト削減)可 能 一般的に長い間modifying状態 になる(※) ※TiDB Cloudの仕様 10
11. TiDBの実装: TiKVの垂直スケール • 実データの移動を伴わない • リーダーを退避するだけ ◦ • 既存のノードの負荷はこのリーダー退避で 1 ノードあたりのリーダー数が増え、今までより 高負荷になる PDのスケールが必要になる時もある(※) ◦ PDリーダーの変更は短時間のレイテンシ悪 化を伴う可能性がある ※TiDB Cloudの仕様 11
12. TiKV水平スケール vs 垂直スケール (1/2) 水平スケール 垂直スケール リージョン移動 Yes No TiKVプロセス再起動 no Yes スケールの粒度 細かい 粗い 通常SKUは2倍, 4倍... といった粒度でのみ提供 される. スケール時間 一時的な性能低下 /リスク ローリスク ハイリスク とても重要だが次のページで説明 12
13. TiKV水平スケール vs 垂直スケール (2/2) • スケール時間: ◦ データサイズ、TiKVノード数に依存 ◦ ◦ 一般にリージョン移動は時間がかかる data size CPUバウンドだとスケールしやすい一方、 水平スケールの下限値としてデータサイズ で制約を受ける. Vertical Scale Horizontal Scale the number of TiKV Nodes 13
14. メルカリにおけるTiKVスケール • 2026/06に水平、垂直スケール両方実現済 (ど ちらか片方のみ有効化の前提 ) 当初垂直スケールを優先、しかし、キャンペーン時のマニュアル水平スケールで下記 を確認し、水平スケール自動化を優先することに • a. 性能影響が予想より小さい b. スケール所要時間が予想より短時間 本日は以下の流れで、水平スケールの課題への取り組みを紹介 a. 用語の整理 b. 負荷の偏り c. 一括でスケールするか、小刻みにスケールするか d. 負荷分散が遅い 14
16. 水平スケール実践による課題1 : 負荷の偏り • 水平スケールを実践したところ、ノードごとの負荷の偏りが発生しうまく 効率化できない事象が発生 負荷の偏りのイメージ 最もCPU利用率の高いノードに合わせてサイジン グせざるを得ないので効率が悪くなる 16
17. 水平スケール実践による課題1 : 負荷の偏り • Action: ◦ 1. 高負荷なテーブルをマニュアルで分散させる ◦ 2. 対象テーブルのデータ移動を固定化 ※TiDB Cloudでのチケットによる操作です(標準メニューではそのような機能はありません). 感 謝 17
18. 水平スケール実践による課題1 : 負荷の偏り • Action: ◦ 1. 高負荷なテーブルをマニュアルで分散させる ◦ 2. 対象テーブルのデータ移動を固定化 ◦ 3. 固定化を解除 => また偏る ※TiDB Cloudでのチケットによる操作です(標準メニューではそのような機能はありません). 感 謝 18
19. 水平スケール実践による課題1 : 負荷の偏り • ホットなリージョンは自動でバランスされるのでは？ 19
20. 水平スケール実践による課題1 : ホットリージョンの仕組み (1/2) • ホットリージョンの仕組み (ホットとは.) ◦ ◦ ◦ ホット判定は 3 次元の OR — どれか 1 つでも閾値超過ならホット ▪ byte 通信帯域 B/s ／ key 走査キー数 /s ／ query リクエスト数 /s ▪ read の query = Coprocessor + Get + Scan 収集経路が read / write で非対称 ▪ read: store heartbeat 10s の peer毎の統計 ▪ write: region heartbeat 60s ホット peer が 60 件以上あるストアでは動的閾値, 60件未満は固定閾値 ▪ max(固定下限, そのストアの上位 60番目の負荷 × 0.8) ◦ HotDegree(連続して hot と判定された回数) >= 3 でスケジューラーの対象 ◦ 判定単位は peer = リージョン × ストア 20
21. 水平スケール実践による課題1 : ホットリージョンの仕組み (2/2) • なぜ自動でバランスされない(ことがある)のか ◦ スケジューラが見るのは 3 次元のうち 2 次元だけ ▪ read: [query, byte] / write-leader: [query, byte] / write-peer: [byte, key] ▪ CPU コストの偏りは考慮されない ◦ クラスタの平均から約 10% 離れていないと動かさない ◦ v8.5.7 で read CPU が次元として追加 （PD#5718 / TiKV#19373） 21
22. 水平スケール実践による課題1 : まとめ • v8.5.7より前ではCPU読み取り負荷がホットの指標として考慮されない • データサイズが小さく通信帯域ではホットとみなされないが、CPU利用率が高い クエリが流通するテーブルは要注意 ◦ スケールを繰り返すと CPU利用率が必然的に偏る ◦ メルカリでは、該当テーブルは一時的に (v8.5.7にあげるまでは )TiDBでは読み取りトラフィック を扱わないこととした (書き込み: TiDB、読み取り: MySQL) • v8.5.7ではCPU利用率が考慮される ◦ https://docs.pingcap.com/tidb/stable/release-8.5.7/#performance ◦ https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues/#cpu-awar e-hot-region-scheduling-for-read-hotspots 22
23. 水平スケール実践による課題2 : 一括でスケールするか、小刻みにスケールするか • (TiDB Cloudでは)スケールアウトは一気に、スケールインは徐々に、が良さそう ◦ スケールアウト ▪ 内部実装の問題でリーダー移動などが発生している際に modifyingからavailableへのステータス更新 がブロックされ、TiKV を小刻みにスケールアウトすると、 TiDBのスケールアウトができなくなる . ▪ ◦ 必要なリソースを数時間前にまとめてスケールアウトさせる方が効率が良い スケールイン ▪ 基本的に時間がかかる. TiKVスケールイン時には、TiDBスケールインもしたい。変更 (スケールイン)中は ステータスがmodifying中になり、TiDBのスケールインがブロックされるため、スケールインは 1段階ず つ実施。 ▪ カスタムコントローラーで、TiDBのスケールインとTiKVのスケールインどちらを実施するとどちらがコスト 削減効果が大きいか、を判断させ実施させる。 ※ TiKVのスケール変更は時間がかかる可能性があるので、 TiKVのスケール前に、 (必要がある時に限り ) 事前にTiDBノードをバッファーとして追加する機能を実装済み . 23
24. 水平スケール実践による課題3 : 負荷分散するのが遅い • 期待値 ◦ 読み取り負荷が中心のワークロードでは、リーダー移動が終わると、負荷が分散され る • 発生したこと: リージョン移動が全て終わらないと負荷が均衡しない ◦ リーダー移動 ◦ リージョン移動 ◦ 負荷均衡(ホットリージョン移動) 24
25. 水平スケール実践による課題3 : 負荷分散するのが遅い • Action ◦ どのような実装かを確認する ◦ 特定のスケジューラーを一時的に止めて様子を観察する ※TiDB Cloudでのチケットによる操作です(標準メニューではそのような機能はありません). 感謝 • 制限事項 ◦ TiDB CloudではPDの統計情報のダッシュボードは公開されていない ◦ (チケットで特定の時間のxxの統計が欲しい、とリクエストすることはできる.) 25
26. 水平スケール実践による課題3 : 負荷分散するのが遅い 26
27. 水平スケール実践による課題3 : 負荷分散するのが遅い • balance-hot-region-schedulerの方がPriority Queueの優先度の重みが大きい のにも関わらず、エンキューされたものがstore-limitによる制限でキャンセルされ、移 動が阻害されていた. • 途中で、balance-region-schedulerだけを停止して、各種メトリクスの挙動を観察 27
28. 水平スケール実践による課題3 : 負荷分散するのが遅い • • store-limit-version: v2 ◦ https://docs.pingcap.com/tidb/stable/pd-configuration-file/#store-limit-version-new-in-v710 ◦ https://docs.pingcap.com/tidb/stable/configure-store-limit/#principles-of-store-limit-v2 store-limitによらない制御が効く . v2の設定でホットリージョンの移動を早くできるこ とを確認. 28
29. 水平スケール実践による課題3 : まとめ • 課題 ◦ • リージョン移動が終わらないとホットリージョンが移動せず負荷均衡しない問題があった 解析結果 ◦ balance-hot-region-schedulerはエンキュー間隔が長い、balance-region-schedulerによって大量にエ ンキューにされるといった理由により、優先的にデキューされるはずのホットリージョンの移動が、 store-limitの 制限によりキャンセルされていることが確認された . • 対策 ◦ • store-limit-version: v2 を利用するとホットリージョン移動が store-limitにブロックされない 注 ◦ その他、様々なパラメーターがあり、役割を理解しパラメータを調整する必要があります 29
30. お知らせ 30
31. メルカリのコントリビューション • TiDB Cloudのユーザー、Changefeedの管理がterraformでできま す! ◦ ◦ API ▪ 5/26 member API is available ▪ 7/7 Changefeed API is available terraform provider(PR): マージされていませんがメルカリでは商用環境で利用中 ▪ member #256, 6/1 ▪ Changefeed (Kafka, MySQL sink only) #265, 7/9 TiDB CloudのChangefeedは本体の機能の多く (Table Filter, Event Filterなど) をサポートしており、 terraformによる管理が非常に有用 . また、GUI経由の変更はリクエストから反映までラグがあり、 API経由(terraform) 方が停止、再開などを含む変更が速くできます . 31
32. TiDB User Day 2026 (10/29 木, 10/30 金) • メルカリもセッションがあります, 10/30(金) 10:50 - 11:20 ◦ https://pingcap.co.jp/tidb-user-day/ 32
33. We are Hiring! • 「メルカリ DBRE workable」で検索を! ◦ Individual Contributor ▪ https://apply.workable.com/mercari/j/ACD2689E9E/ ◦ Engineering Manager ▪ • https://apply.workable.com/mercari/j/7AD4EF9218/ TiDB関連の技術ブログもご覧ください ◦ https://engineering.mercari.com/blog/tag/tidb/ ◦ https://engineering.mercari.com/blog/tag/database/ 33
34. Thank you! 34
35. • 35