DMMがMySQLのリプレース先としてGoogle Cloud SpannerとTiDBを比較、採用したのはTiDB。比較内容や結果を語る［PR］
今回は「DMMがMySQLのリプレース先としてGoogle Cloud SpannerとTiDBを比較、採用したのはTiDB。比較内容や結果を語る［PR］」についてご紹介します。
関連ワード （大体、未満、軽量等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
オンラインゲーム、電子書籍、動画配信を始めとする60以上のサービスを提供しているDMM。同社の共通基盤を提供する組織「DMMプラットフォーム」は、オンプレミス上で稼働していたMySQLのリプレース先の検討過程でNewSQLのGoogle Cloud SpannerとTiDB/TiDB Cloudを比較しました。
その比較の結果、採用されたのはTiDB Cloudでした。
比較検討の結果として完成度はSpannerの方が高いとしながらも、なぜ同社はTiDB Cloudを採用したのか、そして実際に運用してどうだったのか。その内容が2024年7月3日に都内で行われたイベント「TiDB User Day 2024」のセッションで語られました。
本記事ではその概要を紹介します。
オンプレミスのMySQLをリプレイスする
「DMMプラットフォーム」に所属するpospome（ぽすぽめ）氏。
pospome氏が所属するDMMプラットフォームは、エンジニア数は120名以上。レガシーシステムのリプレースプロジェクトとしてインフラのクラウド化とGo言語へのリライトを進めていました。
DMMプラットフォームには「認証チーム」と「認可チーム」があり、両チームはオンプレミスでMySQLを運用していることから、リプレースプロジェクトとして、スケールするSQLデータベース、いわゆるNewSQLの採用を検討し始めました。
NewSQLの採用を検討し始めた理由は3つ。
1つ目は認証チームと認可チームのアプリケーションが止まってしまうとDMMの全サービスが止まるため、単一障害点のないデータベースが望ましいため。
2つ目はバージョンアップ時のダウンタイムをなくしたいため、そして3つ目がライトの水平スケールだと説明されました。
「MySQLは、リードであればレプリカをスケールさせるだけでいいんですけど、ライトはどうしても上限があるので、このライトがスケールしないという課題も、中長期的なサービスの成長を考えると解消したいという気持ちがありました。」（pospome氏）
NoSQLを検討したものの難しいと判断
NewSQLの前には、ライトがスケールし、バージョンアップ時のダウンタイムもなくせるNoSQLが検討されました。
しかしデータ構造をNoSQL向けに変更する必要があり、アプリケーションの改修も発生し、何よりNoSQLを使いこなすための学習コストがかかることなどから、NoSQLへの移行は難しいと判断されました。
そこで候補となったのが、SQLに対応しつつスケールする能力を備えたNewSQLです。
ただしNewSQLも万能ではないとpospome氏は指摘します。
その理由として、NewSQLではスケーラビリティを実現するために分散した複数のノード間の通信が発生するためレイテンシが高くなること、そのために高い性能を実現しようとするとNewSQLの方がどうしても必要なノード、コンピューティングリソースが増えてしまうため、費用が高くなる傾向にあることなどを挙げました。
SpannerとTiDBの比較を開始
その上で、NewSQLの代表であるSpannerと、NewSQLの1つでありMySQL互換のTiDB/TiDB Cloudの比較検討が行われたのです。
まずシステムアーキテクチャの比較では、両者が似ているとしたものの、SpannerはGoogleのインフラレベルで設計され最適化されていると評価しました。
パフォーマンスについては環境依存のため判断は難しいとしつつも、強整合性を保証したSELECTのQPSについてはSpannerの方が高いのではないか、とのこと。
ジョインのパフォーマンスについても、Spannerには親子関係にあるデータを物理的に同じ場所に配置するインターリーブという機能があることから有利だとしました。
既存データベースとの互換性について
既存データベースとの互換性について。
SpannerはGoogleSQLというGoogleオリジナルのSQLを扱いますが、PostgreSQL互換機能も備えているため、DMMプラットフォームの選択肢としてはMySQL対応のコードをPostgreSQL対応に改修してSpannerを利用する選択肢もあったとpospome氏は説明します。
ただしPostgreSQL互換機能を使うには「PGAdapter」というプロキシを利用する必要があり、自分でCloud Run上などにPGAdapterをホスティングしなければなりません。これを理由としてPGAdapterのパターンは見送ると判断されました。
「なぜかというとPostgreSQL対応への移行にはそれなりの工数がかかるであろうっていうこと、そしてPGAdapterとずっと付き合っていかなければなりません。
これらを頑張るのであれば、Spannerにネイティブ対応した方がいいだろうということでこのパターンは見送りました。」（pospome氏）
TiDBのオンライン分析処理
次にオンライン分析処理です。
pospome氏は、NoSQLはデータが複数のノードに散るので、SumやAvarageアベレージのような集計処理が結構苦手だとした上で、従来のRDBも集計処理が得意というわけではないが、RDBではデータが1つのホストで完結するのでNewSQLよりは得意かな、と説明します。
TiDBでは「TiFlash」というコンポーネントで分析処理が可能になります。
TiFlashは、オンライン分析処理専用のノードで、TiKVのノードのデータを同期して持つため、データを二重で持つことになります。データの同期はTiDBが裏側で実行してくれます。
MySQL互換のクエリを利用することができるので、トランザクション処理であってもオンライン分析処理であってもクエリを透過的に扱うことができます。
ただし、TiFlashを利用するにはTiFlashノードを常時稼働させる必要があるため、コストパフォーマンスは微妙だとpospome氏は評価する一方、TiDB 7.0以降では高コストパフォーマンスで使える仕組みが入るとのことです。
一方のSpannerでオンライン分析処理を行うには、何らかの方法でBigQueryと連携する必要があります。
ローカル開発について
ローカル開発に関しては、TiDBは「tiup」というツールで軽量ながら本物のTiDBをローカルPCやCI環境で起動可能。各種検証に利用できます。ここはすごく便利だなとpospome氏は評価します。
一方でSpannerはローカル開発用のエミュレータを提供していますが、SpannerはクライアントとgRPCで通信するため、本物のSpannerをGoogle Cloud上に立ててローカルからアクセスする形で開発すればいいのではないかと、pospome氏は考えているとのことです。
DMMプラットフォームはTiDBを選択した
これらの比較検討の結果を、pospome氏は次のようにまとめました。
「個人的にはSpannerの方がやはり完成度が高いと思います。なぜかというと、Googleの資金力とか開発力が背景にあるからです。インフラも含めてColossusとかGPSとか原子時計とか、そういったのも含めて最適化されている点、さらにクラウドサービスとしての品質もGoogle Cloudには敵わないでしょう。
ただ、SpannerはTiDBの直接的な競合になるのかというと、意外とすみ分けできているのではないかと思ってます。
例えばTiDBはオープンソースなので、オンプレミスの会社からするとTiDBがファーストチョイスになるかもしれないですし、MySQL互換機能によって既存のMySQLのエコシステムをそのまま利用できるところにアドバンテージを感じている企業であれば、TiDBがファーストチョイスになるかなと思います。
そしてAWSを使いたい企業にとっては、TiDB CloudではAWS上でTiDBのマネージドサービスを利用できます。
ということでDMMプラットフォームとしては、最終的にTiDB Cloudを採用することに決定しました。
Spannerほどではないにしても、TiDBも、ものすごく良いソフトウェアだと思いますし、日本国内の企業が扱うトラフィック程度であれば十分利用できると思ってます。
我々としてはレガシーシステムをリプレースするという目的があるので、MySQL互換が決め手となってTiDB Cloudを選択しました。」
pospome氏は、移行作業に関しても大きなトラブルなく終わったとしています。
半年ほどTiDB Cloudを運用してみてどうか？
では、実際に運用してみてどうか。
「半年ほど動かしていますが、安定して動いてます。リプレースがまだ途中なので大体4500QPSくらいをさばいています。
トラブルとしては、我々側でキャパシティプランニングをミスしてレイテンシが悪化したこと、TiKVのバグを踏んだこともありましたが、その程度です。
レイテンシに関しては、TiDBのノードのCPU使用率が80を超えてくると悪化します。
CPU使用率が80未満だと大体どのクエリでも、99パーセンタイルが数ミリから数十ミリ秒ぐらいですが、80を超えてくると500ミリ秒とか600ミリ秒みたいなオーダーにりますね。ですから80を超えないようにキャパシティプランニングしています。
リプレースが完了すると大体1万5000QPSくらいまでいくと思っています。
やはり一番安心なのはこのライトがスケールするという点で、最初に話した通り各サービスからのスケール依頼に怯えなくて良くなったのは結構嬉しい点です。」（pospome氏）
NewSQLは従来のRDBの上位互換ではない
一方でコストパフォーマンスについては、従来のRDBのほうがよいとpospome氏は指摘します。別チームの負荷試験によると、Amazon Auroraと同じQPSをTiDB Cloudで出そうとすると、インフラ費用が2倍かかることが分かったとのことです。
これは冒頭のNewSQLの説明にあるとおり、NewSQLではスケーラビリティのために分散した複数のノードでの通信が発生するためにレイテンシが高くなる傾向にあり、高いQPSを実現しようとすると、より多くのコンピューティングリソースが要求されるためです。
そのため、NewSQLは従来のRDBの上位互換というわけではないとpospome氏。
MySQL互換については、既存の開発ツールや運用エコシステムに変更なく、エンジニアが持つ知見をそのまま使えるとのこと。
ただし、TiDBの内部の仕組みはMySQLとは異なるため、学習コストはかかること、特にキャパシティプランニングやトラブルシューティングについては試行錯誤してることもあるとしました。
「例えば、なぜか5分間だけレイテンシが悪化した、というときに何が原因かをMySQLの知見で深掘りできるかというと難しいと思います。ですので、TiDB Cloudを利用する場合はエンタープライズサポートを契約した方がいいと思います。」（pospome氏）
監視についてはTiDB CloudがDatadogやNew Relicと連携できる点は便利としつつも、TiDB Cloudのインフラが原因でメトリクスが高く出てしまうという問題によってあまり使えるモノではないため、TiDB Cloudの管理画面を利用するしかないとのこと。
このTiDB Cloudの管理画面は、各種メトリクスが1週間分ぐらいしか表示できないなど使いにくさがあるため、改善してほしいとしています。
また、要望としてはTiDB Cloudのオートスケーラの実装や、TiDB Cloudのバックアップとリストア機能をデータベース単位で行えるようにしてほしい、といったものが挙がりました。
pospome氏は最後にまとめとして、Googleのインフラレベルで最適化されているSpannerは完成度が高く、一方でTiDBもよいプロダクトであり、TiDB Cloudも安定して動いているとして、セッションを終えました。
≫TiDB | MySQL互換のNewSQLデータベース | PingCAP株式会社
（本記事はPingCAP提供のタイアップ記事です）