概要
メルカリでは、CoreDB と呼ばれる中核データベースを長年オンプレミス上の MySQL で運用してきました。本記事では、2026 年 4 月に完了した MySQL から TiDB への移行を振り返り、長期的なスケーラビリティの改善、弾力的なリソース確保、クラウド化による運用負荷の軽減といった成果を紹介します。また、移行フローや ProxySQL を活用した段階的な切り替えでうまくいった点、実トラフィックを用いた検証やコスト見積もりで直面した課題、移行後に見えてきた改善テーマについても整理します。
TL;DR
- 中核データベースであるCoreDBを 2026/04 にオンプレミスMySQLからTiDBへ移行完了
- 移行により下記の当初目的を達成
- 長期的スケーラビリティの改善
- トラフィック変動に応じたリソース調整
- オンプレミス運用からの脱却
- DBREのEM/ICを募集中
もう少し詳しい内容が知りたい方へのポイントまとめ
- 移行は問題があればMySQLに切り戻し可能な構成を維持しながら実施
- ProxySQLを活用し段階的にTiDBに本番トラフィックを移行
- 切り替えを中央管理し、アプリケーションから透過的な切替を実現
- バッチ(OLAP)エンドポイントの先行移行、切り替え前の実トラフィックの9回のテストで問題を事前に検出
- クエリリプレイによるテストを心がけるも80%負荷再現が当時の限界
- 事前のベンチマークには問題があり、不正確なコスト見積もりに
- TiDB DDLはオンライン化/分散実行による高速化を達成
- DDL運用負荷が減り、「あるべきテーブル定義」ベースに
上記の内容を、記事内で順に説明していきます。
背景
メルカリには、商品・取引・ユーザーなどのクリティカルなビジネスデータを扱う中核データベースとして CoreDB と呼ばれるデータベースがあります。これは、メルカリのサービス開始当初から利用されていたモノリスアプリケーションのデータを格納してきたものです。下記の記事でもある通り、マイクロサービス化とともに、新規のドメインの独立したマイクロサービスに関しては、各々の独立したデータベースを持ち開発チームがデータベースを持つ運用を想定して、データベースも可能なものは分割してきました。しかし、現在でもなお多くのデータが CoreDB に格納されています。
https://www.publickey1.jp/blog/18/mercari_tech_conf_2018.html
この CoreDB は、長らくオンプレミスサーバー上の MySQL で運用してきました。以前は石狩のデータセンターで稼働していましたが、多くのアプリケーションが Google Cloud の東京リージョンへ移行したことを受け、主にアプリケーションとの通信レイテンシを削減する目的で、東京のオンプレミスサーバー上の MySQL へ移行しました。
また、スケールアウト、つまり Read Replica を増やすことで、メルカリのトラフィックの大多数を占める読み取りトラフィックのスケールを実現しながら、同時にスケールアップも行い、運用に収まる現実的な台数を維持しながら運用を行っていました。
https://engineering.mercari.com/blog/entry/20220218-3c7faca4cc/
(Stateful なレガシー MySQL server の章)
また、このスケールアップおよびスケールアウトとともに、必要なデータ保存量やトラフィックの増加に伴い、垂直シャーディングを繰り返してきました。すなわち、データの性質が異なり、結合クエリの発行が必要ない範囲に関しては、ソースおよびレプリカのセット、以後クラスタと呼びます、を分け、複数のクラスタで運用をしてきました。
今回、2026 年 4 月に全ての MySQL サーバーの書き込みトラフィックを TiDB に移行完了しました。それにあたり、当初何を解決したかったか、それがどのようになったかについて簡単に振り返りたいと思います。
移行にあたって、個別の事象としては、数々の解決してきた課題があり、これについては別のブログ記事で紹介します。
TiDB 移行で何を解決したかったか
まずは、移行当初の目的について振り返ります。TiDB 移行により、主に次の 3 つの課題を解決しようと考えていました。
長期のスケーラビリティーの改善
MySQL は Write ノードが単一であるため、書き込み性能を上げるためには、基本的により高性能なサーバーへ置き換えるスケールアップが主な選択肢になります。読み取り性能は Read Replica を増やすことで伸ばしやすい一方、書き込み性能は同じようには水平に伸ばしにくく、大規模なサービスでは長期的な制約になりやすい領域です。
メルカリではスケールアウトとスケールアップを繰り返してきた結果、クラウドなどへの移行を検討する際に、必要なスペックのサーバー、つまりインスタンスクラスがない、あるいは性能が不足する、といったことが発生してきました。また、オンプレミス環境でスケールアップの対応を行うには、非連続なコスト、特にハードウェア調達時に多額のキャッシュアウトが発生し、特異なスペックのサーバーを運用することのリスクなどを含め、限界を迎えつつありました。
トラフィックの増減に対する弾力的なリソース確保
トラフィック増への対応は、物理サーバーの調達、設置など含め、数ヶ月の時間がかかります。また、物理サーバーがある状態でも、スケールアウトを行おうとした場合に、トラフィックの増加に合わせて新規のサーバーをサービスで利用可能にするまでは時間がかかりました。
主に多量のデータを複製する必要があるところに時間がかかったのですが、XtraBackup と呼ばれるオンラインバックアップ取得ツールで一貫性のあるバックアップを取得しながら、データを新規サーバーにストリームで転送し、その後リカバリ、そして遅延の解消といった工程が必要で、最終的に利用可能になるまで全作業で 2 日ほどかかりました。
オンプレミス運用からの脱却
自社のデータセンターで物理サーバーをホスティングしている以上、維持、運用にも一定のエンジニアリングが求められます。一方で、自社データセンターでは何千、何万台以上といった規模のサーバーを運用しているわけではないため、該当スキルを全面に押し出して積極採用するわけにもいきません。さらに、世の中全体としてクラウド化が進んできた現在、オンプレミス環境の運用に関する経験を有するエンジニアの採用自体が難しくなりつつあります。
また、現状の自社のサーバー運用規模においては、OS / MySQL のデプロイといったことからは解放された上で、性能問題などを解決し、高効率化したい要望がありました。
移行によりどうなったか
今回、TiDB への移行が完了し、それぞれどうなったかを振り返ります。
長期スケーラビリティーの改善
書き込み性能に関してもスケールアウトにて対応可能になったことで、書き込みキャパシティーが大幅に向上しました。
TiDB 移行とともに、大量の不要なデータを削除していたのですが、この際に削除を含めた書き込みのボトルネックが MySQL 側、つまり高いハードウェアスペックのサーバーにあり、TiDB 側は十分な余力がある状態でした。
弾力的なリソース確保
物理サーバーの調達の時間が必要なくなったのは当然ながら、物理サーバーでのリストアは 1 日を超える時間がかかっていたところ、1 日の中で負荷に合わせてリソースをスケールできるようになりました。
https://engineering.mercari.com/blog/entry/20260421-7b2dff6bce/
このスケールの速度の変化により、より効率的な、具体的には高いリソース利用率目標での運用が可能になりました。また、必要なリソース量に対して、細かい粒度でのリソース利用量の調整が可能になりました。
オンプレミス運用からの脱却
必要があれば、オンプレミスの MySQL への依存をなくす目処がたち、採用の問題についての懸念事項解消へ大きく前進しました。
また、OS や MySQL のセットアップ、OS への Security Patch 適用、といった問題への対処からも解放されました。
移行全体の振り返り
ここまで、当初の大きな目論見に対して、実際にどうだったかを振り返りました。
ここからは、移行全体でのプロセスとしてうまくいったこと、うまくいかなかったことの振り返りを行います。
うまくいったこと：移行のフロー全体
https://pingcap.co.jp/case-study/mercari-tidb-cloud/
TiDB User Day 2025 でも紹介した上記の切り替えに関する大雑把なフローは、手のかかるものでしたが、事前に多くの課題を抽出可能とし、かつ、仮に問題に直面した場合にも、MySQL に再度トラフィックを戻すことができるシステム構成を整えました。
このような、システムの更新・切り替えに問題があった際に元に戻せるようにすることは、変更の適用における基本事項の 1 つではありますが、愚直にやり切りました。これにより移行の是非の意思決定をスムーズに行うこともでき、移行全体を成功に導きました。
うまくいったこと：バッチエンドポイントの先行リリース
データベースには複数のエンドポイントがあり、また、データベースは複数のマイクロサービスから利用されている状況でした。切り替えを段階的に行う方法は複数考えられ、例えば、マイクロサービス毎に読み取りを切り替えていく、などの方法も考えられました。
その中で、マイクロサービス毎の切り替えは行わず、アプリケーションとデータベースの間に ProxySQL とよばれる Proxy を配置し、Reader エンドポイントに対しては、徐々に TiDB にトラフィックをシフトしていくことにしました。
ProxySQL を活用した目的は、大きく 2 つありました。1 つは、多くのマイクロサービスに対して、接続先データベースの切り替えを透過的に行えるようにすることです。もう 1 つは、切り替え主体である DBRE（DataBase Reliability Engineering）チームがトラフィックの切り替えを一元的に管理し、問題発生時に迅速に対応できるようにすることです。
一方で、Reader エンドポイントの中でも、OLAP（Online Analytical Processing）に近いよりリスクの高いクエリを含むエンドポイント（バッチエンドポイントと呼ぶ）へのトラフィックを先行して切り替えることにし、複数の問題を事前に発見し対処することができました。
バッチエンドポイント切り替えは、その他の Reader エンドポイント切り替えの 5 日前に実施しました。その前に、前提となる MySQL から DM（Data Migration）を通じた TiDB へのデータ同期の遅延の問題を先に解消したり、万が一一定の遅延が発生した際に、TiDB から自動的に MySQL に参照先が戻るような実装を行いました。
https://docs.pingcap.com/tidb/stable/dm-overview/
うまくいかなかったこと：クエリリプレイの限界
TiDB クラスタの移行は、大体トラフィックの少ない順に移行を行い、多くのクラスタは予定通りに進行したものの、一番最後に残った最大のトラフィックをかかえるクラスタで、複数回の予定延伸が発生しました。
移行のフローに記載していないこととして、クエリリプレイを行った上で、一定期間、読み取りの実トラフィックを TiDB に流す、という予行演習・テストを複数回実施しました。
実トラフィックを流すことによるテストは、もちろん一定のリスクがありますが、最終的に全てのトラフィックを TiDB で処理しようとしている、ということから、切替えの必要条件として少なくとも一定時間、実際のトラフィックを切り替え後の構成で処理できている必要があります。
最後の最大のトラフィック流量を持つクラスタでは、永続運用を目指す本番の切り替え前に、9 回実トラフィックを一時的に試験的に実際のサービスに切り替えました。日中のトラフィックがあまり変わらない時間帯で短時間テストを行い、最終的にはピークタイムで問題なく処理できることの確認を行なっています。
この 9 回の中には最終的な本番切り替え成功に導くための、多くの失敗、つまり学びが含まれていました。負荷を増やすと明らかになった不具合事象の発見もあれば、象徴的な事象として、100% の負荷を流したところ、必要なノード数が多くなった結果、TiDB Cloud の監視サーバーが想定していない負荷となり、メトリックが何も見えなくなった、といったことも発生しました。
最終的な動作確認は、実トラフィックで必要なものの、例えば、上記であげたハイトラフィックの状態で監視が正常通り稼働するかなど、できるだけ多くの観点を実際のトラフィックに影響を与えずに確認できるのが望ましいです。実トラフィックの 100% を移行先の環境にミラーして比較ができることが理想的です。
これに対して、メルカリではリプレイツールなどを利用してそれに対応していたものの、一定以上のトラフィック量だと、リプレイによる「取りこぼし」がありました。実際のユーザートラフィックに影響を与えず、できるだけ取りこぼさず本番に近い負荷をかけることが目標で、これに対して独自ツールは当初、最大トラフィックの 50% 程度のリプレイが実現できていました。様々なボトルネックの解析などを経て、最終的にはメルカリの負荷の 80% 程度はリプレイ可能になりました。
しかし、この 80% 以上はリプレイでは負荷再現ができず、ピークトラフィックとのギャップを埋めた上で検証を行うため、実トラフィックによる試験を行いました。この 20% の負荷の差分に対しても、いくつかの問題へ直面するポイントがありました。
うまくいかなかったこと：コスト見積もり
規模の小さいクラスタは予想通りのコストに概ね収まっていましたが、大きなクラスタになるにつれ、予想していたコストとの乖離が大きくなり、予想コスト超過になりました。
予想コストとの乖離の最も支配的な要因は、自社のトラフィックを模擬したベンチマークにおいて、実トラフィックのうち最も負荷割合の高い、複数の行の同時取得の SELECT ... FROM xxx WHERE id IN (...) という SQL に対するベンチマークシナリオの再現度が低かったため、と推測しています。
この問題が発生した経緯としては、ベンチマークデータに対して、大量の IN 句の要素を妥当な数用意するところに一定の難しさがありました。id は、かなりの数を用意しないと、短期間で id の候補がなくなってしまう一方で、id の払い出しが性能ネックになったりベンチマークに影響を与えても困ります。実装上の都合からこれを簡易化した結果、ベンチマークにおいて、負荷の期待値を実際よりも低く見積もる結果となりました。
一方で分散データベースにおいては、データが複数ノードに分散している状態での取得の再現度は極めて重要であり、これに失敗した結果、実際に多くのコンピュートリソースが必要となりました。
移行後に得られた想定以上の効果
全ての DDL（Data Definition Language）に対する運用上の負荷が大きく下がりました。
以前はオンラインスキーマ変更のツールである gh-ost を利用しており、概ね変更の安定性については満足していたものの、次のような問題がありました。
- 一部のケースでは gh-ost が使えない
- 大規模なテーブルの変更は時間がかかる、数週間かかることもある
TiDB では、DDL がオンラインで行われることはもちろん、分散データベースにおける分散実行、DXF（TiDB Distributed eXecution Framework）がとても効いており、基本的には全ての DDL が、MySQL に比べて非常に短期間で完了します。具体的には、数週間かかるものが数時間になる、などのケースがいくつか観測されました。
https://docs.pingcap.com/tidb/stable/tidb-distributed-execution-framework/
このように、DDL に対する運用負荷が下がった結果、一部の非常に大規模なテーブルについては、そのテーブルに関わる設計変更を検討した際に、大規模テーブルの定義の変更を見送るような設計をしがちだったのに対し、どちらのテーブル定義であるべきか、というあるべき論に基づき変更が検討しやすくなりました。
この変化により、テーブル設計の修正を含む最適化などがとてもしやすくなりました。
なお、下記の記事のように、稀なケースで TiDB で DDL にとても時間がかかるケースも観測しましたが、最新のバージョンでは改善されております。
https://engineering.mercari.com/blog/entry/20260304-b782487108/
現在の課題
ここまでで、移行のプロセスでうまくいった点、うまくいかなかった点、移行後に思ったより良かったことについて振り返りました。
最後に、TiDB の移行完了後に対応した、あるいは現在対応している課題についてお知らせします。
分散データベースへの適応
TiDB 切り替え後に、TiDB が分散データベースであることに関連するいくつかの問題への対処を行いました。こちらも追加のブログ記事の公開を予定しております。
コストの問題・安定性の向上
現在のところ、TiDB は全体として非常に安定して稼働しております。
しかし、コスト見積もりが当初予測より上振れたことから、コストの最適化を積極的に行なっております。コストの最適化は、安定性と相反するところであり、最適化を行うことで明らかになる質的な問題を 1 つずつ解消していっております。
ストックアウト問題への対応
クラウドへの移行により、基本的には弾力的なリソース確保ができるようになった一方で、近日のクラウドリソース需要の高まりにより時折発生している、ストック不足のリスクにどのように対応するか、といった検討・検証をしています。
バージョンアップへの対応
TiDB は機能追加や改善の速度が非常に速く、かつ、バージョンアップもオンラインで可能です。
そのため、バージョンアップに迅速に追従し、バージョンアップの恩恵を受けることは TiDB を運用する上では重要です。
一方で、TiDB Cloud では、現状、ダウングレードへのサポートがないため、万が一問題に直面した際に、元のバージョンへ戻せるような仕組みでバージョンアップを行う必要があります。このための手順を確立したり、バージョンアップに対する検証を簡易化するためのツールを開発しています。
TiDB への移行によって多くの課題は解消されましたが、移行完了はゴールではなく、新しい運用フェーズの始まりでもあります。分散データベースやクラウド環境を前提とした運用に適応しながら、コスト、安定性、バージョンアップ対応などを継続的に改善していく必要があります。
まとめ
この記事では、メルカリの中核データベースである CoreDB を MySQL から TiDB へ移行した取り組みを振り返りました。TiDB への移行により、当初の目的であった長期的なスケーラビリティの改善、トラフィックの増減に対する弾力的なリソース確保、そしてクラウド化による運用負荷の軽減について、大きな前進がありました。
移行プロセスでは、事前に設計した移行フローが有効に機能し、ProxySQL を活用したトラフィック切り替えの一元管理や、リスクの高いエンドポイントの先行切り替えによって、問題を段階的に発見・解消できました。一方で、実トラフィックを用いた予行演習では多くの学びがあり、トラフィックリプレイの再現性やコスト見積もりには課題も残りました。
移行後には、DDL の運用負荷が想定以上に下がるなど、TiDB の利点も見えてきました。同時に、分散データベースやクラウド環境を前提とした運用では、コスト、安定性、リソース確保、バージョンアップ対応など、継続的に向き合うべきテーマもあります。今回の移行で得た学びを活かしながら、今後も CoreDB の運用をより安定的で持続可能なものに改善していきます。
おしらせ
最後に、現在メルカリでは、この記事の発行者の所属する DBRE チームの EM（Engineering Manager）および IC（individual Contributor）を募集しています。
この記事を読んで興味を持たれた方は、その旨をお知らせください。
詳しくは以下をご覧ください。
