NewSQL DBの国内カンファレンス「TiDB User Day 2022」開催、クラウドネイティブ環境の次世代DBは「MySQL互換」がカギ

2022年7月7日、国内最大級のNewSQLデータベースカンファレンス「TiDB User Day 2022」が開催されました。本記事では、中でも興味深いセッションが3つありましたので、レポートしたいと思います。

創業者からの挨拶
(PingCAP共同創業者 兼 CTO Ed Huang氏)

まず、創業者のEd Huang氏からのビデオによる挨拶がありましたので、そちらから紹介しましょう。

Ed氏は7年前にPingCAPを設立しましたが、それまでは大手のインターネット企業でMySQLの管理をしていました。その会社が急成長しMySQLのスケーラビリティ問題に直面したとき、一般的な解決方法であるシャーディングではGROUP BYなどの複雑なSQLが使えないなど、アプリケーション開発者からも不評で困っていました。そのとき、Google Spannerの論文を目にし、「これこそDBの未来だ」と感じて、TiDBを開発しようと思い立ちます。SQLやトランザクションなど既存のDBの良い点と新しい技術を組み合わせることで、分散データベースを開発したのです。

PingCAP共同創業者 兼 CTO Ed Huang氏

PinCAPの社名の由来は、分散システムのエンジニアに馴染みのあるCAP定理の「CAP」とネットワークトラブルの原因を調査する時に使用するネットワークコマンドの「Ping」を合わせたものです。

最近、ベテランのエンジニア達が、トラディショナルなDB企業から次世代DBであるNewSQL企業に移っているというトレンドがあるようで、MySQLのコアなストレージエンジンであるInnoDBの開発者で、MySQLのテックリードのSunny Bains氏もPingCAPに入社したとのこと。彼は現在、TiDBのストレージエンジンを開発しています。

「日本のマーケットには既に多くのTiDBユーザがいて、非常に有望な市場だと思っています。日本のユーザが特に気にしている点は『データのセキュリティ』『高可用性』『ACIDトランザクション』などで、これらは正にTiDBの目指すところで、日本のユーザニーズを的確にとらえていると思います。また、日本のMySQLコミュニティは非常にアクティブで勢いがあるので、これもMySQL互換のTiDBの追い風になると思っています」

「TiDBの今。そしてこれから起きること。」
(PingCAP株式会社 Japan CTO 林 正記氏)

「TiDB」はMySQLと互換性があるオープンソースの分散データベースで、「TiDB」と呼ばれるMySQLプロトコルを理解するコンポーネントと「TiKV」と呼ばれる実際にデータを格納するコンポーネントなどから構成されています。

TiDBには3つの特徴があります。1つは水平スケーラビリティで、MySQLユーザが性能問題を解決するのに役立ちます。もう1つは「HTAP(Hybrid Transaction Analytic Process)」と呼ばれるOLTPとOLAPの両方のワークロードを実現する機能です。最後の1つは、クラウドネイティブというところで「TiDB Cloud」というフルマネージドのDBaaSだけでなく、Kubernetesで動かすためのTiDB Operatorも用意している点です。

現在、TiDBはOSSとしても高い評価を得ており、多くのGitHub Starsを獲得していたり、多くの技術者がコントリビュートしています。また、TiKVとChaos-MeshはCNCFのHosted Projectとして開発が進められているだけでなく、Gartnerの評価も徐々に上がってきており、市場での注目度が高まってきています。日本でも2021年からさまざまな形で情報を発信しており、各種イベントでの顧客事例や顧客自身での情報発信も進んでいます。

「AWS/GCPベースのSaaSシステムはTiDBとの相性が抜群!」
(株式会社スマレジ開発本部 開発部 古橋 朋孝氏)

低価格で高性能な「クラウドPOSレジ」というビジネスを展開しているスマレジでは、インフラには主にAWSを利用しています。サービスの稼働年数が2011年から既に10年以上経過しており、登録店舗数は11万店舗以上と急増しています。また、データ保持期間を半永久的にしているため、データの蓄積量も加速度的に増加しています。

データの蓄積量が増加していくことで「管理画面のレスポンスが遅くなってきた」というユーザの声もあり、調査をしてみると原因の大半はDBのスロークエリだと分かりました。さまざまな対策を施してきたものの小手先のチューニングでは限界があり、長期的な安定稼働を目的に抜本的な対策を検討することにしました。

もともと、MySQL互換のAuroraを書き込み用のインスタンスと読み込み用のインスタンスのクラスタ構成で、EC上のアプリケーションからそれぞれのインスタンスにアクセスしていました。このような構成の中でアプリケーションに手を加えずにDBだけを更新し、なおかつメンテナンス時間を最小にする方法を検討することにしました。

当初は、AWSのRedshiftを検討しましたが、オンライン処理には向かないということもあり、今回の要件には合わないため見送りました。またOracleなどのRDBMS製品も検討しましたが、MySQLの互換性がない場合は移行が難しく、今後の運用方法が変化するなどで影響範囲が大きくなることが予想されるため見送り。他にもHeatwaveも見送りするなどで、最終的にMySQLと互換性のあるTiDBにたどり着きました。

TiDBを採用することでアプリケーションを変更する必要がなく、またフルマネージドサービスのTiDB Cloudを利用すればシンプルな構成で既存のAWS環境と接続できるというメリットがありました。しかし、既存のAuroraを一気に移行することにはリスクがあると感じたので、まず読み込み用のインスタンスのみをTiDBに移行することにしました。稼働状況も良く、性能的にも問題なければ全面的に移行するというシナリオです。本来、TiDBは読み込みよりも書き込み性能の方が良いので、この構成ではうまみは少ないのですが、このような構成にしました。

検証にあたっては、PingCAP社の手厚い技術支援を得ながら無償のトライアル期間を有効活用し、既存のAuroraよりも平均で3〜4倍、最大で10倍高速になるという結果が出ました。中には内部的なアーキテクチャの違いによりAuroraより遅いクエリもありましたが、メモリを多用するクエリにはTiFlashを活用することで対応しました。また、並列度を上げるParallel Applyを活用することでサブクエリにも有効で、ほとんどのクエリが高速化できました。

結論としては、AWSやGCPベースのSaaSシステムでMySQL系のDBに性能問題を抱えているのであれば、TiDBがお勧めであるということのようです。

＊　＊　＊

今後、クラウドネイティブな環境で求められる分散データベースが次世代DBとして注目を浴びることになると思いますが、その中で「MySQL互換」という切り口で登場したのがTiDBで、既に日本でも事例が出てきています。既存のインタフェースを活用することでアプリケーションを変更せずにスケーラビリティを手に入れられるということは、大きなアドバンテージになると思います。今後の展開に注視したいと思います。