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

巨大データベースが抱える課題と「TiDB Cloud」の選択

　メルカリのグループミッションである「あらゆる価値を循環させ、あらゆる人の可能性を広げる」を実現するマーケットプレイス事業は、GMV（流通取引総額）および売上収益ともに年々増加傾向にある。同社のビジネス成長は、データベースサーバーのデータ量増加に直結しており、2021年3月時点で20TBを超えていたデータ量は、4年間で2倍の40TB以上にまで成長した。

　従来のアーキテクチャは、Google Cloud上のマイクロサービス群がデータセンター内にある、50台以上の垂直シャーディング済みのMySQLサーバー群に接続する形だ。しかし、この環境はサービスの継続性を脅かす複数の課題を抱えていた。

　たとえば、スケーラビリティの観点では、ハードウェアのキャパシティに上限があるため、急激なリクエストの増加に対応してサーバー台数を増やすことが難しい。こうした環境はElasticity（伸縮性）に乏しく、新たにデータベースサーバーをセットアップする際、OSインストール、PITRリカバリ、レプリケーション設定などを含めて1.5日程度もかかっていた。

　また、Operation（運用）面では、40TBを超えるデータ量を抱えるためレコード数が多く、DDL（データ定義言語）の適用に「数時間から長ければ数日かかるような状況が発生していた」と、DBREチームに所属する小山智之氏は説明する。

　これらの課題を含めて、データセンター固有の運用工数やセキュリティの問題を解消するため、メルカリはデータベースサーバーの移行先としてパブリッククラウドを検討。データベースサービスに対してPoCを実施した結果、TiDB Cloudの選定に至っている。

　具体的にメルカリでは、4つの観点でTiDB Cloudを選定した。第一に書き込みがスケールできる「Scalability（スケーラビリティ）」、第二にクラウドである故に柔軟にサーバーの台数を増減できる「Elasticity」、第三にオンラインDDLのサポートによってDDLを短期間で終えられる「Operation」、そして最後にMySQLとの高い互換性（Compatibility）だ。なお、TiDB Cloudへの移行プロジェクトは2024年10月から始まり、2025年10月現在も継続中だ。

信頼性を重視　メルカリ流「TiDB」移行の8ステップ

　TiDB Cloudへの移行において、いかにダウンタイムを最小限に抑えながら、データの整合性を担保できるのか。メルカリでは、工夫を凝らした移行プロセスを8ステップで実行している。

　まず、移行の事前準備では、「Latency Injection（レイテンシの注入）」が行われた。分散データベースという特性上、MySQLと比較するとユーザーのクエリ送信からシステムが処理結果を返すまで、一定の遅延（レイテンシの増加）が発生してしまう懸念があるからだ。

　そこで、MySQLおよび派生DB用のSQLプロキシである「ProxySQL」をマイクロサービスとMySQLの間に配置し、「＋10ミリ秒／＋20ミリ秒／＋40ミリ秒」と段階的にレイテンシを付与することで、APIレイテンシやエラー、モバイルアプリのレスポンス体験といった観点から影響を評価している。問題が確認されたときには、アプリケーションの修正を実施した。

　また、TiDBへの同期用レプリカ（Relayサーバー）と、TiDBからMySQLへ切り戻す場合のマスタとなるレプリカ（Fallbackサーバー）の2台を用意。PingCAPが提供するダンプツール「Dumpling」を用い、RelayサーバーからTiDB Cloudへ初期データの同期を行い、実行結果に含まれるGTID（静止点）をメモする。その後、MySQL互換データベースからTiDBへのデータ複製ツールである「Data Migration（DM）」を用い、初期同期時にメモしたGTIDを参照してRelayサーバーからTiDBへ差分データ同期を実施した。

　続いて、Fallbackサーバーの付け替えとレプリケーションの停止を実施。Relayサーバー、TiDB、Fallbackサーバーの状態をそろえるため、レプリケーション経路をマスタからRelayサーバーを経由してFallbackサーバーへと変更し、その後マスタからRelayサーバーへのレプリケーションを停止。この時点でRelayサーバー、TiDB、Fallbackサーバーはすべて同じ状態となる。

　さらに、TiDBから別のデータベースへ差分データを同期する「TiCDC」を作成し、TiDBからFallbackサーバーにデータを同期する経路を確立。これによりフォールバック時、MySQLへのデータ同期が可能となった。そして、データの信頼性を確保するため、MySQLプロトコルに対応したDB間の差分比較ツール「sync-diff-inspector」を実行し、RelayサーバーのデータとTiDBを経由したFallbackサーバーのデータを比較することで、データの整合性が取れていることを確認する。整合性を確認した後、マスタからRelayサーバーへのレプリケーションを再開した。

　加えて、切り替え前の重要な評価として、「クエリリプレイ」を実施。メルカリではTiDBのクエリ負荷やリソース使用量を確認するため、eBPFベースのライブラリを用いた軽量なパケット処理を実現できる独自のクエリリプレイツールを開発している。リプレイ対象のクエリは、参照系であるSELECTクエリのみに絞り、本番環境のアクセスパターンを再現したTiDB環境で負荷を評価した。

　その後、いよいよ本番環境への切り替えを行う。ダウンタイムを最小限に抑えるため、メルカリでは以降の手順を自動化するスクリプトを作成。まずはProxySQLを配置し、DNSで宛先をProxySQLに変更することで、アプリケーションから透過的にTiDBへと切り替える準備をした上で、READトラフィックをTiDBへ切り替えた。

　ここからダウンタイムが発生する作業となり、マスタを読み取り専用モードに変更。DMがオンメモリに持っている同期状態、たとえばGTIDをディスク（テーブル）に書き込ませるため、マスタに「`ALTER TABLE t COMMENT ‘trigger’`」のような空のDDLを発行する。

　その後、すべてのトランザクションがTiDBで実行されているかを確認するため、2つの方法で厳格な整合性チェックを実施した。一つはマスタのGTIDとFallbackのDMメタデータベースに保存されたGTIDの値を比較する方法。もう一つはTiCDCの「`checkpointTS`」の値とマスタが読み取り専用になった直後のタイムスタンプを比較する方法だ。

　整合性を確認できれば、ProxySQLの宛先をMySQLからTiDBに変更し、WRITEトラフィックもTiDBへ向ける。最後に、元のMySQLとFallbackサーバー間でGTIDが異なっているためリセットし、レプリカ群をFallbackサーバーに付け替えることで切り戻し経路を確保し、切り替えを完了した。

　こうした一連のメルカリ流のTiDB移行の特徴は、Latency Injectionや独自ツールを使ったクエリリプレイによる評価、ProxySQLを使った透過的な切り替え、そしてGTIDやCheckpointTSによる厳格な整合性チェックにあると小山氏は説明する。

「信頼性」の向上へ　Graceful Maintenanceの実現

　続いて登壇したDBREチームの前田敦史氏は、移行後のTiDB Cloud環境で直面した、運用上の課題について解説した。まず問題となったのは、システムが正常な処理完了を待たずに処理途中で強制的に停止される、TiDBノードの“Gracefulではない”シャットダウンがサービスに与える影響だ。

　TiDBノード5台のうち1台を非Gracefulなシャットダウンでメンテナンスした場合、単位時間あたりの接続数が大幅に減少し、接続がタイムアウトすることを確認。この影響を分析した結果、通常の処理時間が平均3ミリ秒、接続タイムアウトが3秒というシナリオでは、5台のサーバーのうち1台にタイムアウトを発生させたとき、（ロードバランサーがラウンドロビンだった場合）1/5の確率で1,000倍の処理時間を占有し、結果的にスループットが1/200に落ち込む可能性があると前田氏は説明する。この問題は、特に新規接続時のコネクションタイムアウトによって引き起こされ、影響が大きいため対応が必須だったという。

　そこで新規接続の回数を減らし、ProxySQLのコネクションプーリングを活用することを決めた。ProxySQLを利用すればアプリケーションの変更なく、コネクションプーリングの恩恵を受けられる。加えて、接続に成功したものを再利用し、新規接続をバックエンドで非同期化することで、クライアントからのリクエストで直接接続が失敗する状況も緩和できるからだ。実際の計測結果でも、直接接続の場合と比較してProxySQL経由の場合ではエラーが軽減され、スループットが維持されることが確認された。

　ただし、マネージドサービスであるTiDB CloudでProxySQLを導入する際には注意が必要だ。TiDB Cloudでは、ユーザーはノードグループのエンドポイントにアクセスするが、一般的にProxySQLには個別の接続先に問題があれば、それを切り離す機能が求められる。そのため、バックエンドの切り離し・隔離に配慮した設定が必要だ。たとえば、許容する失敗回数を示す「`shun_on_failures`」や、隔離期間を示す「`shun_recovery_time_sec`」といったパラメータの設定が欠かせない。

　メルカリは、この影響緩和策だけでなく、Graceful Shutdown自体の問題解決を目指し、「TiDB Operator」の利用状況やGKEクラスタの設定値など、詳細な情報をPingCAPに確認し、問題の仮説と改善策を整理・提案した。これを受けてPingCAPは効果検証を実施し、Google CloudでGraceful Maintenanceの機能を2025年5月にリリース。2025年6月には、メルカリの全クラスタに適用が完了している。前田氏は「メルカリは、PingCAPと協力しながらTiDB CloudのGraceful Maintenance化を実現した」と述べた。

運用最適化に向けて「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の実現など、継続的な取り組みを進めているとして、セッションは締めくくられた。