sponsored by PingCAP株式会社 | 制作：Publickey
目次
国内最大級のフリマアプリ「メルカリ」のバックエンドデータベースは、50台以上のMySQLサーバがオンプレミスのデータセンターで稼働しており、40TBを越えるデータサイズのデータベースを保持していると、2023年12月に都内で開催されたイベント「db tech showcase 2023 Tokyo」のセッションで、同社のDBRE（Database Reliability Engineer）を務める本田恭氏が明らかにしました。
そしてそのデータベースの規模の大きさゆえにいくつかの課題もあるため、新たなデータベースの候補として、MySQL互換でNewSQLの代表的なデータベースサービスである「TiDB Cloud」をPoC（Proof of Concept：概念検証）として評価。その結果も発表されました。
メルカリの大規模データベースにおける課題とはどのようなもので、その解決策として検証されたTiDBはどのように評価されたのか。セッションのポイントをダイジェストで紹介しましょう。
メルカリの大規模データベースにおける課題とは
本田氏は、メルカリの大規模データベースにおける課題を次のように説明しました。
まず、データサイズが大きいためスキーマ変更などのDDL（Data Definition Language）の実行に時間がかかり、サービス影響を出さずに切り替え可能となるまでには数週間かかることもざらにあること。
処理を分散するためにデータベースが垂直分割されているものの、過去に行われた分割が現在のアプリケーションのロジックと紐付いていないため、データベースをまたいだトランザクションなどが実行できず不便な点があること。
さらに、レプリカセットのセットアップにも24時間以上かかるため急なトラフィック増への対応も難しく、オンプレミスで運営しているためにサーバの調達から稼働させるまでにも時間がかかるとしました。
TiDB Cloudがメルカリのワークロードに耐えるか
こうした課題を解決する候補の1つとして、本田氏はTiDB Cloudの名前を挙げました。
「ライトがスケールアウトできること、スケールの速さからコスト最適化も可能であること。MySQLとの高い互換性やキャパシティの上限がないことから、サービス成長のブロッカーとはならないこと。そしてデータセンターでの運用の問題、工数だったりセキュリティなどを解決できるのではないかと、私たちの運用課題の解決策となるのではないかと考えて、候補の1つになりました」（本田氏）。
そこで、TiDB Cloudがメルカリのワークロードに耐えうるかという、性能面での評価が行われたのです。
評価項目はスループット、レイテンシ、レプリケーションの3つ。
スループットは本番環境で実際に流れているクエリを使って、現在と未来で想定されているQPSをさばけるかを確認します。目安は150万QPSを越えられるかどうか。
レイテンシも本番のデータと実際のクエリを使って、負荷がほとんどないベストな状態でのレイテンシと、ある程度負荷がある状態のレイテンシを計測し、MySQLとTiDBの速さの違いがどのくらいあるのかを知っておくことで、移行前後でのサービスへの影響を評価します。目標値となるレイテンシ以下かどうかが計測されます。
レプリケーションは本番データベースからレプリカを作成し、データの整合性が取れるまでの時間を計測します。これは7日以内に終了するかどうかが目安となります。
ただし、本番環境で使われているすべてのクエリを評価環境で網羅することは不可能なので、主要なマイクロサービスで使われている代表的なクエリ以外はSysbenchで対応することにします。
スループット、レイテンシ、レプリケーションのそれぞれについて目標値を設定して評価が開始されました。
スループットは450万QPSを突破
ここからは評価の結果です。
スループットのベンチマークテストでは、チューニングについてはいくつかのパラメータを調整しています。今回の環境下では、Clusterd IndexとPlan Cacheが特に効果があり採用されました。
目標値の150万QPSを達成したときのTiDB Cloudの構成は、TiDBが100台以上でTiKVは80台以上、PD（Placement Driver：クラスタを管理するサーバ）は3台でした。
そして最終的には、何と450万QPSを突破できたと報告されました。
レイテンシは目標値の1.5倍程度に
今回のPoCの必要条件の一つがスループットの達成であったことから、レイテンシの評価時の各種パラメータはスループットの目標値を達成したときのものが流用されています。
メルカリのデータセンター内ではMySQLサーバのネットワークレイテンシが小数点以下1桁のミリ秒なのに対して、TiDB Cloudは通信がアベイラビリティゾーンをまたぐ可能性があるなど、値が大きくなることが予想されました。
またテスト環境からTiDB Cloudのクラウドに対しても3ミリ秒から4ミリ秒かかるため、その値も上乗せされることになります。
結果をグラフ化したものが以下です。
MySQLはグラフのマーカーが見えないくらい値が小さく、大きくても0.5ミリ秒程度。一方、TiDB Cloudは負荷が低い状態から中程度の負荷でも20ミリ秒から40ミリ秒ぐらい。高負荷時には上限の80ミリ秒に張り付いています。
これは想定したレイテンシの目標値の1.5倍、高負荷だと10倍以上の結果となりました。
レプリケーションは想定より短時間で完了
レプリケーションのテストは次のような構成で行われました。
まずリレーレプリカからTiDB Cloudへ、そしてTiDB Cloudから切り戻し用のMySQLのFallbackへとデータを同期して、Fallback用とTiDB Cloudで整合性を確認する、というものです。
このレプリケーションの動作は97時間ほどで全てが終わりました。つまり100時間未満で完了したということで、これは当初の目標であった7日間、168時間を大幅に下回る結果でした。
TiDB Cloudのスケーラビリティに限界は見えなかった
評価結果をまとめると次のようになりました。
TiDB Cloudを使った感想を本田氏は次のように語りました。
「TiDB Cloudのスケーラビリティについては限界は見えなかった、という感じです。スケールアウトさえすれば、クラウドなのでお金はかかりますが、それに応じたスループットを得ることはできます。そういう観点では限界はないなっていう感じでした。
ただ、TiDB Cloudを実際に本番で使うにはいくつかの懸念もあります。
1つは、ここでは紹介していませんが、いくつかバグがあったこと。
また、（TiDB Cloudを構成するコンポーネントである）TiKVとPDについては、私たちはまったく触ることができなかったり、メトリクスもほとんど見えないみたいな感じだったりしました。そういう状態はDBREにとって優しい状態かと言われると必ずしもそうではない感じなので、このあたりはちょっと改善を期待しているところです。
レイテンシについては、思った以上に悪くはありませんでしたが速くもなく、課題は残るなというところなので、これに対しても何らかの対応が必要になると感じました」。
また本田氏は、今回の検証がTiDB Cloudの提供元であるPingCAPからのサポートのおかげで無事に終わったと説明しました。
「開発チームを巻き込んだサポートだったり、質問に対して迅速にご対応いただいたこと、それぞれのフェーズでの測定などもしてもらい、私たちのチームのTiDB Cloudへの理解が深まりました。また、そのおかげで性能検証を無事終わらせることができたとおもいます」（本田氏）。
※ この記事「メルカリの本番環境で流れているクエリを使って、MySQL互換のTiDB Cloudを評価。40TBを越えるDBの大規模トラフィックに耐えられたか？」は、Pubickeyの許可を得て転載しています