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

「信頼性」の向上へ　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化を実現した」と述べた。