TiDB Cloudにおけるオートスケールの実現

DBRE (DataBase Reliability Engineering) チームの taka-h です。 2025 年 10 月の TiDB User Day において、[オートスケールについて取組み中(P. 81)であることをご紹介](https://static.pingcap.co.jp/files/2025/10/20165547/TiUD2025-Mercari.pdf)しました。この記事では、このその後のオートスケールの取り組み状況についてお伝えします。 結論としては、2025 年 11 月時点で、DBRE が管理する TiDB 移行済みの全クラスタで TiDB の水平方向オートスケール導入が完了し、その後も安定稼働しています。 次の画像は、メルカリ内のとある Cluster(l1-2) で、オートスケールが CPU 利用率の平均値を 60 パーセント前後に保つように動作している様子を示したものです。 ![image](https://storage.googleapis.com/prd-engineering-asset/2026/04/3ebdbf5d-cleanshot-2026-04-10-at-16.43.50@2x.png) なお、TiDB Cloud にはいくつかの製品ラインアップがありますが、本記事での以後の TiDB Cloud という言葉は、いわゆるサーバーレスではない「TiDB Cloud Dedicated」を指すものとします。 ## 背景：なぜ TiDB Cloud でオートスケールが必要だったか メルカリでは、最初に TiDB のオートスケールの実装をすることを決め、初期の実装ターゲットを TiDB に絞ってオートスケールの導入を進めました。 まずはこの経緯を簡単に説明します。 ## 実装決定に至った経緯 最初に既存のライブラリの実装状況を調査しました。 TiDB を Kubernetes 上でホスティングするためのライブラリとしては、[tidb-operator](https://github.com/pingcap/tidb-operator) があります。このライブラリでオートスケールが実装されていれば、我々が利用している TiDB のマネージドサービスである TiDB Cloud でもオートスケールが近々実現されることが想定されます。 オートスケール導入を検討した当時は、次の状況でした。 - 当初実装されていたオートスケールの機能が削除されていた - TiDB Cloud の開発ロードマップにオートスケールの機能が入っていない （最新の [tidb-operator v2 では CRD の sub resources に対応](https://docs.pingcap.com/tidb-in-kubernetes/dev/v2-vs-v1/#support-status-and-scale-sub-resources)しています） また、TiDB Cloud は自動での水平/垂直のオートスケールの機能が提供されていない一方で、スケール変更について API が提供されています。 [https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Cluster/operation/UpdateCluster](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Cluster/operation/UpdateCluster) API があれば、オートスケールは実現のための必要条件を満たすので、まずはオートスケールの実現のため実装を進めることとしました。 ## 実装対象の選定 オートスケールの実装を決めた後、最初にオートスケール化の対象を決める必要があります。 メルカリにおける TiDB Cloud のコストの構成としては、オートスケール導入前の時点で、大雑把に TiKV が 6 割程度、TiDB が 2 割程度でありました。TiKV が実データを持つのに対し、TiDB はステートレスでオートスケールに対する考慮事項が少なく、比較的容易に実現できますので、まずは実装対象を TiDB とし、要件を定義の上実装することにしました。 [https://docs.pingcap.com/tidb/stable/tidb-architecture/](https://docs.pingcap.com/tidb/stable/tidb-architecture/) ![image](https://storage.googleapis.com/prd-engineering-asset/2026/04/cbb01885-cleanshot-2026-04-10-at-15.56.19@2x.png) ## 方針 1：Kubernetes HPA 活用，しかしマネージドサービス特有の壁があった (オートスケール v1) 実装範囲を決めた後、最初は Kubernetes HPA(Horizontal Pod Autoscaler) を活用して実装する方針としました。ここではその最初の方針決定の経緯、そして方針変更に至った経緯を順に説明します。 要件を定義の上 LLM で実装する予定でしたので、フルカスタム実装でもよかったのですが、主に、社内で [Elasticsearch のオートスケールが実現されていた](https://engineering.mercari.com/blog/entry/20230620-f0782fd75f/) ため、これと同様に Kubernetes の Native のオートスケールの機能の活用して実現することに決定しました。 具体的には、実績があり安心できるという理由の他には、Kubernetes Native のオートスケールを利用すると、次の利点がありました。 - 考慮すべき様々な一般的な考慮事項が既に満たされており、これを活用することでその実装が不要になり、開発すべき機能のスコープが絞られる 例) スラッシング回避 (Thrashing avoidance)、一度に増減できるノード数上限、など - datadog 経由のメトリクス連携を既存のオートスケールの機能でできる クレデンシャルのセットアップなども追加で不要 - 運用が他の Kubenetes のものとそろう ## 既存のパターンとの違い：Pod が管理する Cluster に存在しない 既存の Elasticsearch のオートスケールと今回の TiDB Cloud では、前提条件が大きく異なります。既存のパターンは「自分たちが運用する Kubernetes クラスタ上で Pod が動いている」ことを前提に、HPA が Pod のスケールを制御していました。 一方で、TiDB Cloud を利用する場合、実際の Pod は TiDB Cloud 上で動作しており、メルカリが管理する Kubernetes クラスタ上には存在しません。このため、既存パターンと同様に HPA を適用しようとすると「スケール対象として参照できる Pod がない」という問題に直面します。 そこで、TiDB Cluster を表す Custom Resource（カスタムリソース）を定義し、これを HPA（Horizontal Pod Autoscaler：水平ポッド自動スケーラ）のスケール対象として扱う方針で検討を進めました（次節で説明します）。 ## Kubernetes の HPA による実際には存在しない Pod を持つ対象への対応 ここでやりたかったのは、TiDB Cloud の TiDB ノード数変更を、Kubernetes の HPA の仕組みに乗せて自動化することです。そのために、TiDB Cluster を表す Custom Resource（カスタムリソース）を定義し、HPA がその replicas（レプリカ数）を増減できる構成を検討しました。** しかし、HPA が Custom Resource（カスタムリソース）をスケール対象として扱うには、scale subresource（/scale：スケーリングサブリソース）を提供する必要があり、あわせて labelSelectorPath の定義が求められます。labelSelectorPath は、本来スケール対象に紐づく Pod 群を特定するための情報です。 [https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) TiDB Cloud では該当 Pod が自クラスタに存在しないため、この前提を満たせず、通常の形では HPA が成立しませんでした。一方で、[External Metrics（外部メトリクス）で AverageValue を使う場合に限り、結果的に selector が評価に使われない挙動](https://github.com/kubernetes/kubernetes/blob/ee1ff4866e30ac3685da3e007979b0e9ab7651a6/pkg/controller/podautoscaler/horizontal.go#L699-L718)があり、labelSelectorPath をダミーにしても動作しました（ただし仕様保証がなく、運用上のリスクが残ります）。 [https://docs.cloud.google.com/kubernetes-engine/docs/tutorials/autoscaling-metrics](https://docs.cloud.google.com/kubernetes-engine/docs/tutorials/autoscaling-metrics) : autoscaling/v1beta1（旧形式） metrics: - type: External external: metricName: pubsub.googleapis.com|subscription|num_undelivered_messages metricSelector: matchLabels: resource.labels.subscription_id: my-subscription targetAverageValue: "2" : autoscaling/v2 (現行推奨) metrics: - type: External external: metric: name: pubsub.googleapis.com|subscription|num_undelivered_messages selector: matchLabels: resource.labels.subscription_id: my-subscription target: type: AverageValue averageValue: "2" ## 方針 2: フルカスタムへ切り替え、運用可能な形へ収束 (オートスケール v2) ステージング環境までは、何とかこの実装で動作はしたのですが、External Metrics 連携が想定通りに動作せず、次の理由から Custom Resource を定義し、reconcile のループを回すところだけ残し、その他をフルカスタム実装に切り替えることにしました。 - Native HPA の機能を活用している既存の実装は、現状利用している特定のパターンが将来的に利用できなくなる可能性が払拭できない - デバッグが困難を極めた - LLM でオートスケールのような「よくある」実装が非常に容易になっている フルカスタム実装に切替えてから、オートスケールで考慮すべき一般的な考慮事項についての学びを 1 つ 1 つ獲得しながら、下記の方針で、迅速にそして大きな問題なくオートスケールを導入完了できました。 - 最低限担保すべき範囲が明確になっており、そこが正確に実装できていること - 想定外であった場合に、それを検知する実装/設計になっていること つまり、当初は実装精度が十分ではなく、オートスケールの制御精度もやや低い状態でした。そこで初期は目標値を保守的に設定し、まずは一定のコスト削減を達成しました。あわせて、目標値との差分（猶予）を確保しつつ、想定外を検知できる仕組みを用意しました。そのうえで、運用しながら段階的に精度を高めていきました。精度が低い状態を許容するには、想定外の事態や異常の検知が十分に検討され、適切に実装されていることが前提になります。 ## 最低限担保すべき範囲 オートスケールでは、ある指定されたメトリックが目標値になるようリソースを増減させます。 運用開始時に、この目標値に余裕を持たせる前提であれば、 - 最小ノード数を一定以下にしないこと - 一度に可能な増減ノード数を制御できていること - ノード増減操作の連続操作に制約を与えること が期待通りに動作していれば、提供するサービス品質に影響が発生するということはないと考えました。 ## 想定外を検知する実装/設計 最低限担保する範囲を厳密に守りながら、実装速度を優先し、運用中に改善を重ねていく前提で開発を進める方針でしたので、運用中の改善を許容するためには「異常な状態」をうまく検知できる必要があり、そのために必要なメトリクス/アラートについて、事前に多くの検討を行いました。 ここでの検討事項には、次の 3 つのポイントがありました。 1. 制御するパラメータに対する適切なアラート設計/設定 現時点では CPU 利用率を一定範囲にコントロールすることを目標にオートスケールを運用しています。当たり前ですが、利用率が低すぎれば、それはリソースが有効に活用できておらず、利用率が高すぎれば、サービスの提供品質に問題がでる、こういったことが起きない範囲にコントロールすることを目指します。 - オートスケールでの制御目標値 - 実際のアラートの閾値 (Cluster/Node) 上記のような値を適切な上下関係に設定し、運用を行うこととしました。 ![image](https://storage.googleapis.com/prd-engineering-asset/2026/04/b3659087-generated-image-1776263205379.jpg) **2. 依存関係のモニタリング** オートスケールが依存している API の品質や問題に対して異常検知を行うことが重要であると考えました。今回は現状のメトリクスを把握するための Datadog の API、そして TiDB Cloud の API が該当します。 例えば、API レスポンスが遅くなったり、特定のエラーコードが一定以上発生したり、データ点が欠損したり、あるいは、変更操作を起こった際の所要時間をモニタリングし、これが期待値通りかを観測する、といったことです。 ![image](https://storage.googleapis.com/prd-engineering-asset/2026/04/ed97ef0b-cleanshot-2026-04-16-at-11.48.15@2x.png) ![image](https://storage.googleapis.com/prd-engineering-asset/2026/04/e39903c7-cleanshot-2026-04-16-at-11.46.41@2x.png) **3. オートスケールの想定内・想定外の規定** オートスケールでは、ノードを追加したり、削除したり、変更操作を随時行っています。 一方で、あるノードの予期せぬ再起動、といったことも発生します。 外部から観測できるメトリクス (Cluster の状態や、Node の Uptime など) から、どのような状態/変化が想定通りか、あるいは想定外かを考え、規定しています。 ## これらを可能にした周辺改善 オートスケールは、当たり前のように実施しなければならない項目ではありますが、それを実現するために、メルカリ社そして TiDB Cloud の提供元である PingCAP 社の様々な改善がありました。 一番大きなものは、TiDB Cloud の TiDB のスケール操作 (スケールアップ/スケールダウン/スケールイン) が graceful ではなかった点を、メルカリ/PingCAP 社で改善したことです ([TiDB User Day 2025 P.36~](https://static.pingcap.co.jp/files/2025/10/20165547/TiUD2025-Mercari.pdf))。 そして、TiDB Cloud の Datadog における CPU メトリクスの値の信頼性が十分でないことや、オートスケールなどに利用するのが難しいといった問題への対処、また、オートスケールを API で実施する際の [権限制御の改善](https://docs.pingcap.com/tidbcloud/release-notes-2025/#august-12-2025) などが挙げられます。 度重なる要望に対して、改善を積み重ねていただいた PingCAP 社には改めて感謝します。 ## 今後：TiKV への展開の難しさと次の一手 現在、より大きなコスト割合を占める TiKV のスケーリングに取り組んでいます。 TiKV はデータを保持するため、これを水平スケールする際には、データの偏りをなくすためのリバランス（データ再配置）が必要です。水平スケールの戦略を取るためには、スケールインの際には削除対象のノードのすべてのデータを他のノードに移動してからでないと、ノードを削除できません。 現在、「1 日の中で負荷が上下し、TiKV で必要なリソースが変化するので、これに最適なリソースにし、コストを抑制しながら必要なリソースを必要なだけ確保したい」という要望があります。データのリバランスは、既存のノードの性能にも影響を与える可能性があり、そのため一般的にはその速度がある程度抑制されています。水平スケールに求めるスケール速度が、このような 1 日の中でノードを増減する必要があるという場合において、スケールインは不向きであるといえるでしょう。また、逆にもう少し長いスパンでのスケールの自動追従であれば、コストに対するインパクトがそこまでないため実現の重要性は下がるでしょう。 これに対して、リバランスの速度を調整するという選択肢も考えられます。しかし、現状では TiDB ではこのリバランスの設定を含む、TiKV の設定変更に対して API が提供されておらず、現状取りうる手段は、サポートチケット経由での設定の変更依頼が必要です。 そこで、まずは垂直スケールの機能の導入を目指しています。 ## TiKV の垂直スケールにおけるメモリ有効活用 今後も追加で様々な課題が見つかるかとは思いますが、現状、大きなインスタンスクラスで TiKV を運用した場合、メモリを有効活用できない課題がありましたので、それを解決しています。 MySQL やその他のデータストアや、システムでもよくある問題ですが、データベースをホストしているノードの安定稼働のために、データベース以外、あるいは主に利用するリソース以外で利用するリソースを一定割合確保するため、主に利用するメモリの利用率を保守的に設定することがあります。 TiDB においては、TiKV の block_cache.capacity（ブロックキャッシュ容量）、memory_usage_limit（メモリ使用量制限）といった設定が主に積極的に活用したいリソースですが、現状の TiKV の実装状況で発生している拘束条件として、これらのパラメータについては、初期値は固定の割合で指定されるものの、初期値ではない値に変更する場合に、利用するメモリ利用量を数値で指定する必要がありました。 [https://docs.pingcap.com/tidb/stable/tikv-configuration-file/#memory-usage-limit](https://docs.pingcap.com/tidb/stable/tikv-configuration-file/#memory-usage-limit) [https://docs.pingcap.com/tidb/stable/tikv-configuration-file/#capacity](https://docs.pingcap.com/tidb/stable/tikv-configuration-file/#capacity) ![image](https://storage.googleapis.com/prd-engineering-asset/2026/04/af30892e-cleanshot-2026-04-21-at-10.31.27@2x.png) 前述の通り、TiDB Cloud ではこれらの設定を変更する API も存在しないため、メモリを有効活用するためにメモリ利用量を値を指定して変更する場合、現状ではサポートチケット経由で変更依頼が必要です。この状況では、負荷に合わせて自動で垂直スケール（vertical scaling）したいといった場合に、サポートチケット経由での変更が必要となり、結果として適切にメモリ利用量を追従させることができません。 すなわち、TiKV を大きなインスタンスクラスで運用した場合、メモリが余剰しリソースを有効活用できないという問題がありました。具体的には block-cache.capacity のデフォルト値の 45% に近い、50% 前後までしか、メモリを活用できませんでした。 そこで、TiKV のメモリを割合で指定し、大きなインスタンスクラスで運用する場合に、これを大きな値に設定できるように修正しました。この修正は master ブランチにマージ済みで、次のマイナーバージョンである 8.5.7 で利用可能になる見込みです。 [https://github.com/tikv/tikv/pull/19419](https://github.com/tikv/tikv/pull/19419) ## まとめ メルカリでは TiDB Cloud を運用しており、負荷に合わせ TiDB の水平方向のオートスケールを安定的に運用しています。これにより、TiDB の 50% 前後のコストが削減されました（トータルでは、全体の 2 割の約半分、の削減効果）。 既存の Kubernetes のネイティブ機能を活用する方針で初期の検討を始め、ステージング環境までも動作させたものの、LLM によって再実装を行ったこと、また、LLM での実装については、 - 最低限担保すべき範囲が明確になっており、そこが正確に実装できていること - 想定外であった場合に、それを検知する実装/設計になっていること を基本方針として迅速に実装を完了させたこと、 一見当たり前のようにみえる、オートスケールの実現自体には、実はとても大変な基礎的な改善の数々があること、また、最後に TiKV の垂直スケールでメモリを有効活用するため、修正をコントリビュートしていること、をお伝えしました。 最後に、現在メルカリでは、この記事の発行者の所属する DBRE チームの EM(Engineering Manager) を募集しています。詳しくは[こちら](https://apply.workable.com/mercari/j/7AD4EF9218)をご覧ください。

TiDB Cloudにおけるオートスケールの実現

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

調べる

選ぶ

サイト