TiDB Cloudにおけるオートスケールの実現
メルカリの DBRE チームが、TiDB Cloud の API を活用して独自に水平方向オートスケールを実装し、全移行済みクラスタで CPU 利用率を 60% に保つ安定稼働を実現した事例について報告しています。
キーポイント
実装の背景と動機
TiDB Cloud の公式機能としてオートスケールが提供されておらず、既存ライブラリも削除されていたため、API を活用して独自に実現する必要性が生じた。
対象選定と戦略
コスト構成の 6 割を占める TiKV よりも、ステートレスで実装が容易な TiDB をまず対象とし、Kubernetes HPA の活用を検討した。
技術的アプローチと成果
公式機能の不足により API を駆使して独自実装を行い、2025 年 11 月時点で全クラスタで CPU 利用率を平均 60% に保つオートスケールが安定稼働している。
マネージドサービスの課題
Kubernetes ネイティブの HPA を活用する利点がある一方、マネージドサービス特有の制約や機能不足により、完全な自動化には独自の実装が必要となる壁が存在した。
フルカスタム実装への切り替えと基本方針
既存の Native HPA の限界やデバッグ難易度から、LLM を活用してフルカスタム実装へ移行し、「最低限担保すべき範囲の正確な実装」と「想定外状況の検知設計」を基本方針として運用を開始した。
TiKV 垂直スケールにおけるメモリ有効活用の実現
大規模インスタンスでのメモリ未活用課題に対し、設定値を数値指定から割合指定へ変更する機能改善（PR #19419）を行い、次期バージョンで利用可能となることで垂直スケールの自動化を可能にした。
TiDB Cloud 側との連携によるコスト削減効果
Graceful スケール操作や API 権限制御の改善など TiDB Cloud 側の機能強化と協働により、TiDB のコストを約 50%（全体コストの約 10%）削減し、安定的な運用を実現した。
影響分析・編集コメントを表示
影響分析
この記事は、主要なクラウドデータベースサービスが提供する機能の不足を補うためのエンジニアリング的な解決策を示しており、大規模システムにおけるコスト最適化と可用性確保の実践例として価値があります。特に、公式機能が未整備な環境でも API を駆使して独自に自動化基盤を構築できる可能性を証明し、同様の課題を抱える組織にとって重要な参考事例となります。
編集コメント
公式機能の不足を API を活用して独自に解決した事例は、マネージドサービスの限界を理解し、柔軟に対応するエンジニアリング能力の高さを示しています。コスト削減と安定稼働の両立に向けた具体的なアプローチとして、同様の課題を抱える組織にとって非常に参考になる内容です。
DBRE (DataBase Reliability Engineering) チームの taka-h です。
2025 年 10 月の TiDB User Day において、オートスケールについて取組み中(P. 81)であることをご紹介しました。この記事では、このその後のオートスケールの取り組み状況についてお伝えします。
結論としては、2025 年 11 月時点で、DBRE が管理する TiDB 移行済みの全クラスタで TiDB の水平方向オートスケール導入が完了し、その後も安定稼働しています。
次の画像は、メルカリ内のとある Cluster(l1-2) で、オートスケールが CPU 利用率の平均値を 60 パーセント前後に保つように動作している様子を示したものです。
なお、TiDB Cloud にはいくつかの製品ラインアップがありますが、本記事での以後の TiDB Cloud という言葉は、いわゆるサーバーレスではない「TiDB Cloud Dedicated」を指すものとします。
背景：なぜ TiDB Cloud でオートスケールが必要だったか
メルカリでは、最初に TiDB のオートスケールの実装をすることを決め、初期の実装ターゲットを TiDB に絞ってオートスケールの導入を進めました。
まずはこの経緯を簡単に説明します。
実装決定に至った経緯
最初に既存のライブラリの実装状況を調査しました。
TiDB を Kubernetes 上でホスティングするためのライブラリとしては、tidb-operator があります。このライブラリでオートスケールが実装されていれば、我々が利用している TiDB のマネージドサービスである TiDB Cloud でもオートスケールが近々実現されることが想定されます。
オートスケール導入を検討した当時は、次の状況でした。
- 当初実装されていたオートスケールの機能が削除されていた
- TiDB Cloud の開発ロードマップにオートスケールの機能が入っていない
（最新の tidb-operator v2 では CRD の sub resources に対応しています）
また、TiDB Cloud は自動での水平/垂直のオートスケールの機能が提供されていない一方で、スケール変更について API が提供されています。
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/
方針 1：Kubernetes HPA 活用，しかしマネージドサービス特有の壁があった (オートスケール v1)
実装範囲を決めた後、最初は Kubernetes HPA(Horizontal Pod Autoscaler) を活用して実装する方針としました。ここではその最初の方針決定の経緯、そして方針変更に至った経緯を順に説明します。
要件を定義の上 LLM で実装する予定でしたので、フルカスタム実装でもよかったのですが、主に、社内で Elasticsearch のオートスケールが実現されていた ため、これと同様に 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 群を特定するための情報です。
TiDB Cloud では該当 Pod が自クラスタに存在しないため、この前提を満たせず、通常の形では HPA が成立しませんでした。一方で、External Metrics（外部メトリクス）で AverageValue を使う場合に限り、結果的に selector が評価に使われない挙動があり、labelSelectorPath をダミーにしても動作しました（ただし仕様保証がなく、運用上のリスクが残ります）。
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 つのポイントがありました。
- 制御するパラメータに対する適切なアラート設計/設定
現時点では CPU 利用率を一定範囲にコントロールすることを目標にオートスケールを運用しています。当たり前ですが、利用率が低すぎれば、それはリソースが有効に活用できておらず、利用率が高すぎれば、サービスの提供品質に問題がでる、こういったことが起きない範囲にコントロールすることを目指します。
- オートスケールでの制御目標値
- 実際のアラートの閾値 (Cluster/Node)
上記のような値を適切な上下関係に設定し、運用を行うこととしました。
2. 依存関係のモニタリング
オートスケールが依存している API の品質や問題に対して異常検知を行うことが重要であると考えました。今回は現状のメトリクスを把握するための Datadog の API、そして TiDB Cloud の API が該当します。
例えば、API レスポンスが遅くなったり、特定のエラーコードが一定以上発生したり、データ点が欠損したり、あるいは、変更操作を起こった際の所要時間をモニタリングし、これが期待値通りかを観測する、といったことです。
3. オートスケールの想定内・想定外の規定
オートスケールでは、ノードを追加したり、削除したり、変更操作を随時行っています。
一方で、あるノードの予期せぬ再起動、といったことも発生します。
外部から観測できるメトリクス (Cluster の状態や、Node の Uptime など) から、どのような状態/変化が想定通りか、あるいは想定外かを考え、規定しています。
これらを可能にした周辺改善
オートスケールは、当たり前のように実施しなければならない項目ではありますが、それを実現するために、メルカリ社そして TiDB Cloud の提供元である PingCAP 社の様々な改善がありました。
一番大きなものは、TiDB Cloud の TiDB のスケール操作 (スケールアップ/スケールダウン/スケールイン) が graceful ではなかった点を、メルカリ/PingCAP 社で改善したことです (TiDB User Day 2025 P.36~)。
そして、TiDB Cloud の Datadog における CPU メトリクスの値の信頼性が十分でないことや、オートスケールなどに利用するのが難しいといった問題への対処、また、オートスケールを API で実施する際の 権限制御の改善 などが挙げられます。
度重なる要望に対して、改善を積み重ねていただいた 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/#capacity
前述の通り、TiDB Cloud ではこれらの設定を変更する API も存在しないため、メモリを有効活用するためにメモリ利用量を値を指定して変更する場合、現状ではサポートチケット経由で変更依頼が必要です。この状況では、負荷に合わせて自動で垂直スケール（vertical scaling）したいといった場合に、サポートチケット経由での変更が必要となり、結果として適切にメモリ利用量を追従させることができません。
すなわち、TiKV を大きなインスタンスクラスで運用した場合、メモリが余剰しリソースを有効活用できないという問題がありました。具体的には block-cache.capacity のデフォルト値の 45% に近い、50% 前後までしか、メモリを活用できませんでした。
そこで、TiKV のメモリを割合で指定し、大きなインスタンスクラスで運用する場合に、これを大きな値に設定できるように修正しました。この修正は master ブランチにマージ済みで、次のマイナーバージョンである 8.5.7 で利用可能になる見込みです。
https://github.com/tikv/tikv/pull/19419
まとめ
メルカリでは TiDB Cloud を運用しており、負荷に合わせ TiDB の水平方向のオートスケールを安定的に運用しています。これにより、TiDB の 50% 前後のコストが削減されました（トータルでは、全体の 2 割の約半分、の削減効果）。
既存の Kubernetes のネイティブ機能を活用する方針で初期の検討を始め、ステージング環境までも動作させたものの、LLM によって再実装を行ったこと、また、LLM での実装については、
- 最低限担保すべき範囲が明確になっており、そこが正確に実装できていること
- 想定外であった場合に、それを検知する実装/設計になっていること
を基本方針として迅速に実装を完了させたこと、
一見当たり前のようにみえる、オートスケールの実現自体には、実はとても大変な基礎的な改善の数々があること、また、最後に TiKV の垂直スケールでメモリを有効活用するため、修正をコントリビュートしていること、をお伝えしました。
最後に、現在メルカリでは、この記事の発行者の所属する DBRE チームの EM(Engineering Manager) を募集しています。詳しくはこちらをご覧ください。
原文を表示
DBRE (DataBase Reliability Engineering)チームの taka-h です。
2025年10月のTiDB User Dayにおいて、オートスケールについて取組み中(P. 81)であることをご紹介しました。この記事では、このその後のオートスケールの取り組み状況についてお伝えします。
結論としては、2025年11月時点で、DBREが管理するTiDB移行済みの全クラスタでTiDBの水平方向オートスケール導入が完了し、その後も安定稼働しています。
次の画像は、メルカリ内のとあるCluster(l1-2)で、オートスケールがCPU利用率の平均値を60パーセント前後に保つように動作している様子を示したものです。
なお、TiDB Cloudにはいくつかの製品ラインアップがありますが、本記事での以後のTiDB Cloudという言葉は、いわゆるサーバーレスではない「TiDB Cloud Dedicated」を指すものとします。
背景：なぜTiDB Cloudでオートスケールが必要だったか
メルカリでは、最初にTiDBのオートスケールの実装をすることを決め、初期の実装ターゲットをTiDBに絞ってオートスケールの導入を進めました。
まずはこの経緯を簡単に説明します。
実装決定に至った経緯
最初に既存のライブラリの実装状況を調査しました。
TiDBをKubernetes上でホスティングするためのライブラリとしては、tidb-operatorがあります。このライブラリでオートスケールが実装されていれば、我々が利用しているTiDBのマネージドサービスであるTiDB Cloudでもオートスケールが近々実現されることが想定されます。
オートスケール導入を検討した当時は、次の状況でした。
- 当初実装されていたオートスケールの機能が削除されていた
- TiDB Cloudの開発ロードマップにオートスケールの機能が入っていない
（最新の tidb-operator v2ではCRDのsub resourcesに対応しています）
また、TiDB Cloudは自動での水平/垂直のオートスケールの機能が提供されていない一方で、スケール変更についてAPIが提供されています。
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/
方針1：Kubernetes HPA活用, しかしマネージドサービス特有の壁があった (オートスケール v1)
実装範囲を決めた後、最初はKubernetes HPA(Horizontal Pod Autoscaler)を活用して実装する方針としました。ここではその最初の方針決定の経緯、そして方針変更に至った経緯を順に説明します。
要件を定義の上LLMで実装する予定でしたので、フルカスタム実装でもよかったのですが、主に、社内でElasticsearchのオートスケールが実現されていたため、これと同様にKubernetesのNativeのオートスケールの機能の活用して実現することに決定しました。
具体的には、実績があり安心できるという理由の他には、Kubernetes Nativeのオートスケールを利用すると、次の利点がありました。
- 考慮すべき様々な一般的な考慮事項が既に満たされており、これを活用することでその実装が不要になり、開発すべき機能のスコープが絞られる
例) スラッシング回避、一度に増減できるノード数上限、など
- datadog経由のメトリクス連携を既存のオートスケールの機能でできる
クレデンシャルのセットアップなども追加で不要
- 運用が他のKubenetesのものとそろう
既存のパターンとの違い: Podが管理するClusterに存在しない
既存のElasticsearchのオートスケールと今回のTiDB Cloudでは、前提条件が大きく異なります。既存のパターンは「自分たちが運用するKubernetesクラスタ上でPodが動いている」ことを前提に、HPAがPodのスケールを制御していました。
一方で、TiDB Cloudを利用する場合、実際のPodはTiDB Cloud上で動作しており、メルカリが管理するKubernetesクラスタ上には存在しません。このため、既存パターンと同様にHPAを適用しようとすると「スケール対象として参照できるPodがない」という問題に直面します。
そこで、TiDB Clusterを表すCustom Resourceを定義し、これをHPAのスケール対象として扱う方針で検討を進めました（次節で説明します）。
実際のPodがない対象へのHPA
ここでやりたかったのは、TiDB CloudのTiDBノード数変更を、KubernetesのHPAの仕組みに乗せて自動化することです。そのために、TiDB Clusterを表すCustom Resourceを定義し、HPAがそのreplicasを増減できる構成を検討しました。**
しかし、HPAがCustom Resourceをスケール対象として扱うには、scale subresource（/scale）を提供する必要があり、あわせて labelSelectorPath の定義が求められます。labelSelectorPath は、本来スケール対象に紐づくPod群を特定するための情報です。
TiDB Cloudでは該当Podが自クラスタに存在しないため、この前提を満たせず、通常の形ではHPAが成立しませんでした。一方で、External Metricsで AverageValue を使う場合に限り、結果的にselectorが評価に使われない挙動があり、labelSelectorPath をダミーにしても動作しました（ただし仕様保証がなく、運用上のリスクが残ります）。
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つのポイントがありました。
- 制御するパラメータに対する適切なアラート設計/設定**
現時点ではCPU利用率を一定範囲にコントロールすることを目標にオートスケールを運用しています。当たり前ですが、利用率が低すぎれば、それはリソースが有効に活用できておらず、利用率が高すぎれば、サービスの提供品質に問題がでる、こういったことが起きない範囲にコントロールすることを目指します。
- オートスケールでの制御目標値
- 実際のアラートの閾値(Cluster/Node)
上記のような値を適切な上下関係に設定し、運用を行うこととしました。
2. 依存関係のモニタリング
オートスケールが依存しているAPIの品質/問題に対して異常検知を行うことが重要であると考えました。今回は現状のメトリクスを把握するためのdatadogのAPI、そしてTiDB CloudのAPIが該当します。
例えば、APIレスポンスが遅くなったり、特定のエラーコードが一定以上発生したり、データ点が欠損したり、あるいは、変更操作を起こった際の所要時間をモニタリングし、これが期待値通りかを観測する、といったことです。
3. オートスケールの想定内・想定外の規定
オートスケールでは、ノードを追加したり、削除したり、変更操作を随時行っています。
一方で、あるノードの予期せぬ再起動、といったことも発生します。
外部から観測できるメトリクス(Clusterの状態や、NodeのUptimeなど)から、どのような状態/変化が想定通りか、あるいは想定外かを考え、規定しています。
これらを可能にした周辺改善
オートスケールは、当たり前のように実施しなければならない項目ではありますが、それを実現するために、メルカリ社そしてTiDB Cloudの提供元であるPingCAP社の様々な改善がありました。
一番大きなものは、TiDB CloudのTiDBのスケール操作(スケールアップ/スケールダウン/スケールイン)がgracefulではなかった点を、メルカリ/PingCAP社で改善したことです(TiDB User Day 2025 P.36~)。
そして、TiDB CloudのdatadogのCPUメトリクスの値の信頼性が十分でなく、オートスケールなどに利用するのが難しい、といった問題への対処、また、オートスケールをAPIで実施する際の権限制御の改善、などがありました。
度重なる要望に対して、改善を積み重ねていただいた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/#capacity
先述の通り、TiDB Cloudではこれらの設定を変更するAPIもありませんので、メモリを有効活用するためにメモリ利用量を、値を指定して変更する場合、現状サポートチケット経由で変更依頼が必要です。この状況では、負荷に合わせて自動で垂直スケールしたい、といった場合に、サポートチケット経由での変更が必要になり、結果として適切にメモリ利用量を追従させられません。
すなわち、TiKVを大きなインスタンスクラスで運用した場合、メモリが余剰しリソースを有効活用できない、という問題がありました。具体的にはblock-cache.capacityのデフォルト値の45%に近い、50%前後までしか、メモリを活用できませんでした。
そこで、TiKVのメモリを割合で指定し、大きなインスタンスタンスクラスで運用する場合に、これを大きな値に設定することができるように修正しました。この修正はmasterブランチにマージ済みで、次のマイナーバージョンである8.5.7で利用可能になる見込みです。
https://github.com/tikv/tikv/pull/19419
まとめ
メルカリではTiDB Cloudを運用しており、負荷に合わせTiDBの水平方向のオートスケールを安定的に運用しています。これにより、TiDBの50%前後のコストが削減されました（トータルでは、全体の2割の約半分、の削減効果）。
既存のKubernetesのNativeの機能を活用する方針で初期の検討を始め、ステージング環境までも動作させたものの、LLMにて再実装を行ったこと、また、LLMでの実装については、
- 最低限担保すべき範囲が明確になっており、そこが正確に実装できていること
- 想定外であった場合に、それを検知する実装/設計になっていること
を基本方針として迅速に実装を完了させたこと、
一見当たり前のようにみえる、オートスケールの実現自体には、実はとても大変な基礎的な改善の数々があること、また、最後にTiKVの垂直スケールでメモリを有効活用するため、修正をコントリビュートしていること、をお伝えしました。
最後に、現在メルカリでは、この記事の発行者の所属する DBREチーム の EM(Engineering Manager) を募集しています。詳しくはこちらをご覧ください。
関連記事
Kubernetesの自動スケーリングはベンダーツールを超えた新たな可観測性への焦点を要求
KarpenterなどのKubernetes自動スケーラーの採用が加速する中、プラットフォームに依存しない可観測性の実践が登場し、従来のインフラメトリクスから、プロビジョニング動作、スケジューリング遅延、コスト効率への深い洞察へと焦点が移行している。
データは不足していない。不足しているのは想像力だ（8 分読了）
Asuka Zheng は、トレーニングデータの枯渇への不安が市場の実態を捉えていないと指摘し、自身の SRE 代替プロジェクトで世界モデルの訓練が失敗した事例を紹介する。同氏は、最初の異常から完全な解決に至るまでの長期エンドツーエンドの事象軌跡データが存在しないことがボトルネックだったと述べている。
Google、信頼性の高い分散型エージェント実行環境「Agent Executor」を発表
Google は、長期にわたるエージェントワークフローの信頼性と効率を高めるためのオープンソースランタイム標準「Agent Executor」を発表した。同製品は、永続的な実行や安全な隔離機能を提供し、Kubernetes Engine と連携して大規模展開時の計算リソース効率を最適化する。