止めずに移行　メルカリの40TB超・50台MySQLからTiDB Cloudへ

運用最適化に向けて「Resource Control」「Datadog APM」を活用

　続いて、TiDB Cloudの運用効率と安定性を高めるための2つの主要なツールについても紹介された。その一つとして前田氏は、「『TiDB Resource Control』を使ってほしい」と話す。Resource Controlは、ワークロードを隔離するための論理グループを作成し、CPUとI/Oコストを総合した統一指標「RU（Resource Unit）」による制御機能を持つ。モニタリング指標として非常に有用であり、リソースグループごとにTiKVのCPU利用量やトラフィックなど、詳細なメトリクスを観測できる。

　また、優先度制御やリソース割り当てにより、特定のクエリがリソースを占有することを防ぐなど、全体障害の回避にもつながるという。さらに処理量の多いクエリの優先度を下げてリソース利用量を平準化し、最適化も図れる。

　Resource Controlの導入では、TiKVにおける「Top SQL」機能から負荷傾向を解析し、負荷を発生させているユーザーやクエリを特定。それらのクエリに対してヒント句を付与、あるいはアプリケーションコードの変更なしに「SPM（SQL Plan Management）」を活用してリソースグループを割り当てる。

　実際にメルカリでは「CDC（Change Data Capture）」ユーザーの優先度を下げたり、危険なクエリを停止させたりといったユースケースで活用している。制限をかけた後には、ステートメントサマリーの観測により、Resource Controlによって待機させられた時間を示す「`queued_rc_time`」や、スロークエリの観測から「`wait_resource_control_time`」をチェックし、意図通りに制限できているかを確認しているという。

　そして、もう一つのツールとして挙げられたのは「Datadog APM」だ。メルカリではDatadogが広く利用されており、データベースのモニタリングにも活用することを目指している。前田氏は、データベースでのAI活用の可能性についても言及し、APMに保存されるベースラインの情報（クエリの数、実行時間、実行計画など）の蓄積と活用は、（AI活用において）最も可能性のあるものの一つだと述べた。

　たとえば、MySQLのPerformance Schemaの統計情報はTiDBで利用できないが、TiDBには代替として実行統計やRUを含むリソース使用状況など、103もの属性を持つStatement Summary Tablesが「`information_schema`」に提供されている。

　メルカリでは、このTiDBの豊富な情報を利用することで、既存のDatadogバックエンドを改修せずに動作する「Datadog Database Monitoring for TiDB」を実装。これにより時間・クエリごとのスループットやレスポンスの統計取得、EXPLAIN PLANコマンドの確認が可能となった。特にDatadog標準機能との連携が実現したことで、どのマイクロサービスがどのような負荷を与えているのかを統合的に確認できるようになったという。

　現在メルカリは、TiDBのコスト効率改善や、現状TiDB Cloudが未対応のTiDB Auto Scalingの実装、Datadog Database Monitoringを活用して負荷上昇や障害原因を自然言語で回答するようなAIの実現など、継続的な取り組みを進めているとして、セッションは締めくくられた。