MySQL互換でフルマネージドな分散型データベース「TiDB Cloud」をご存じでしょうか？ 「TiDB Cloud」は、大規模なSQLを提供するためにフルスクラッチで開発されたオープンソースソフトウェアのデータベース。分散環境を前提に設計されており、自由自在なスケーラビリティを実現しているのが特徴です。MySQLのエキスパートたちが長年悩まされてきたシャーディングなどに起因して発生する課題をスッキリ解決できることから注目を集めており、世界の名だたる企業が採用しています。
そこで今回は、「TiDB Cloud」を開発するPingCAP株式会社（以下、PingCAP）のSenior ArchitectであるSunny Bains氏と、日本法人代表取締役社長のエリック・ハン氏に、「TiDB Cloud」の特徴や設計の経緯などを伺いました。
目次
プロフィール
チタンのような堅牢なデータベースを目指して「TiDB」と命名
――はじめに、読者にそれぞれ自己紹介をお願いします。
Sunny Bains氏（以下、Bains）：私は2000年からずっと、データベースのカーネルやストレージエンジンといったコアな部分の開発に取り組んできました。PingCAPにジョインしたのは2022年4月で、現在はクラウドチームに属しています。入社前はオラクルのソフトウェア開発部門のシニアディレクターとして、MySQLの最も大切なエンジンであるInnoDBに関わっていました。
Eric Han氏（以下、Eric）：来日してから13年が経ちました。キャリア最初期の2年間はインフラエンジニアとして働き、その後、約10年間は外資系メーカーでプリセールスなどを経験しました。2年前にPingCAP日本法人の立ち上げに伴ってジョインし、現在はPingCAPの日本代表となり、日々、市場開拓とコミュニティ構築に取り組んでいます。
――TiDB Cloudというサービス名がクールだなと思うのですが、命名の由来を聞かせていただけますか？
Eric：TiDBの「Ti」は「チタン（Titan）」の元素記号「Ti」を意味しています。チタンのような堅牢なデータベースという意味でTiDBと命名しました。そしてフルマネージドサービスとしての名がTiDB Cloudということになります。
ちなみにTiDBの「Ti（タイ）」の読みと、日本の縁起物の魚である鯛（たい）があわさった「ピン（Ping）ちゃん」というキャラクターもいます。
PingCAP Japan 公式キャラクター ピンちゃん
Bains：PingCAPという社名の由来も興味深いと思います。データベースに関わる人ならよく知っている、ネットワーク状況を確認するコマンド「Ping」と、分散コンピュータシステムのマシン間の情報複製に関する定理「CAP定理」の「CAP」の2つをあわせたのが、PingCAPです。
――おふたりは、なぜPingCAPにジョインしようと思ったのでしょうか？
Bains：新しいと思える発想で、ゼロからデータベースを作ろうとしているPingCAPに感化されたのです。転職を考えたとき「ここしかない」と思っていました。私はMySQLに長らく携わってきて、その難しさを知っているからこそモチベーションが上がって、PingCAPに入る決断をしました。
Eric：モチベーションという意味では近いです。TiDBは、日本法人が立ち上がる前から多くのユーザーに使われていて、本当にエンジニアの助けになるソリューションだと思いました。そしてPingCAPが社会の大きな問題を受け止めて解決しようとしている姿勢に共感して入社を決めました。加えて、いわゆる「ゼロイチ」に、1度携わってみたいと思ったことも理由です。
TiDB CloudはMySQL互換のオープンソースのデータベース
――TiDB Cloudの概要を教えてください。
Bains：TiDB Cloudは、MySQLと互換性があるオープンソースの新しいデータベースで、特徴の1つはスケーラブルな分散DBだということです。
ここでいうスケーラブルとは、クラウドの機能を活用することを意味しています。TiDB Cloudでは、クラウドの柔軟なインフラストラクチャーと様々なクラウドサービスを利用できます。例えば低コストで大容量のデータを保存できる「Amazon S3」のようなオブジェクトストレージが使えます。
これを「エラスティシティ（elasticity）」と呼んでいます。「弾力性」と訳されることもあるのですが、ソフトウェアとハードウェアを柔軟に伸縮させて使うことができるイメージです。つまり、必要なときに必要な量だけのリソースを使えるという特性をTiDB Cloudは持っているのです。
活用イメージとしては、一例ですが「Amazon プライムセール」や中国の「独身の日」のような、短期間での巨大なECのセールです。TiDB Cloudなら、一時的に巨大なコンピューティングリソースが必要になる際に、そのときだけクラウドのリソースを使うことができるのです。これはユーザーにとってメリットが大きい、非常に理にかなった使い方だと思います。
またTiDBの内部でもエラスティシティ（弾力性）を活用しています。少々テクニカルな話ですが、データ構造として「LSM」を使ってデータを保存しています。この方法では定期的にデータを圧縮するオペレーションが必要になるのですが、このオペレーションのためにコンピュータリソースを使うと、データベース本来の機能が影響を受けてしまうのです。
そこで、圧縮するときはAWSの「スポットインスタンス」という、非常に低コストでコンピューティングリソースを利用できるサービスを利用して、データに圧縮をかけます。このようにTiDBの内部でもクラウドを活用しています。
TiDB Cloudは分散システムなので、クラウドの性質を利用してスケールアウト（Scale out） しやすいです。そして必要なくなったらリソースを開放して小さくする、スケールイン（Scale in）もしやすいというメリットがあります。
――他の特徴を教えてください。
Bains：TiDB Cloudの2点目の特徴は「ハイアベイラビリティ（High Availability）」です。日本語では、「高可用性」と訳され、「HA」と表記されることもあります。オンプレミスで提供するのと同様、基本的にずっと使い続けられるといった意味合いだと考えてください。
クラウドで提供されるサービスは、クラウドプロバイダーが提供するインフラストラクチャーを使います。「アベイラビリティゾーン（Availability Zone：AZ）」と一般に言われているものです。
アベイラビリティゾーンとは、データセンターのようなもの。オンプレミスと比べると、クラウドはアベイラビリティゾーンを利用しており物理的には複数のデータセンターを使うため、ネットワーク速度において多少のレイテンシーが発生するかもしれません。しかしTiDB Cloudでは複数のインスタンスを使って高可用性を実現しているため、オンプレミスとクラウドで使用感覚を変えることなく、ずっと利用できるのが特徴となっています。
3つ目はアナリティクス（Analytics）です。TiDB Cloudの最も特徴的な点だと思います。TiDBは「TiFlash」という分析エンジンを備えています。内部的には、先ほどお話した「Amazon S3」を「TiKV」という分散データベースのストレージエンジンと「TiFlash」の両方で使っています。
CDC（変更データキャプチャ）をユーザーが望むもの、例えば「Snowflake」や「BigQuery」などにリアルタイムで連携することもできますが、「TiDB Cloud」は内部に分析用のエンジンを備えているのが特徴です。
最後にアプリケーションの移行が簡単なこともTiDBの特徴のひとつです。既にMySQLを使っているユーザーがTiDB Cloudに移行するとき、TiDBは、MySQLとほぼ同じように使うことができます。そのため、ユーザーは何の抵抗もなく移行することができるのです。
――続いて、TiDB Cloudを使用するメリットを教えてください。
Bains：多くのユーザーがクラウドに移行する理由の1つはメンテナンス性の高さだと思います。クラウドに移行することで、メンテナンスの手間やコストの低減を狙うわけです。TiDB Cloudを使えば、大幅に手間やコストを減らすことができます。TiDB Cloudは既にあるクラウドサービスと効率的に手間なく連携することを重視し、実現しました。
またPingCAPはTiDBのエキスパートなので、ユーザーは基本的にTiDB Cloudの運用を我々に任せてしまえるのもメリットだと思います。
シャーディングなどでDBに課題を抱えた有名企業が採用
――TiDBはどのような企業で使われていますか？
Eric：日本国内において、業種や業界を問わずに採用いただくケースが増えています。既に日本では50社以上が採用またはPoC（概念実証）を行っています。
実際のところ、TiDBは日本法人を立ち上げる前から某ペイメントサービスで使われていました。他には、VODサービスの「U-NEXT」など、トラフィックが急増しているサービスがTiDBを採用しています。
2年前に日本法人をスタートしてからは、ゲーム、Eコマースに関わる企業が興味を持ってくださることが増えました。PingCAPの事例ページを確認していただくと、例えばゲーム業界では「カプコン」、Eコマースでは「@cosme（株式会社アイスタイル運営）」での活用事例を知っていただけます。
他にもクラウドPOSレジの「スマレジ」や、ソフトバンクグループの決済・金融事業を担う「SBペイメントサービス」での採用事例もあります。最近は金融関係、小売業からの問い合わせが大幅に増えました。
――金融や小売は莫大なデータ量を扱いますし、ゲームはスピードが求められます。いずれもTiDB Cloudなら対応できる領域ですね。
Eric：はい。最も分かりやすいケースだと思います。一方で、高可用性のユースケースも増えてきました。例えば、ペイメントサービスを展開する「ELESTYLE」です。
「ELESTYLE」では既存のデータベースで性能的には大きな問題はありませんでしたが、毎年のアップグレードや障害対応でサービスが止まることがあり、この障害に対応するためにTiDB Cloudに乗り換えることになりました。
――海外ではいかがですか？
Bains：ヨーロッパでは、フィンテック系スタートアップの「ボルト（Bolt）」がTiDB Cloudを使っています。インドで巨大なECモールを展開する「フリップカート（Flipkart）」や、世界第2の銀行といわれている「中国建設銀行」もユーザーです。
アメリカではバケーションレンタルサービスを行う「Airbnb」、写真共有サービスの「Pinterest」、「Pokémon GO」のような位置情報を活用したゲームを開発している「Niantic」、そして世界的SNSツールの1つである「LinkedIn」も挙げられます。
――世界の名だたる企業が並んでいますね。
Bains：私が最近知って興味深いと感じたのが、イタリアの都市、つまりパブリックセクターでもTiDB Cloudを使っていただいていることでした。
事例をいろいろ挙げましたが、基本的にTiDBは、業種業界を問わず、スケーラビリティに課題を抱えているMySQLユーザーに採用いただくケースが多いですね。データベースを複数使うシャーディングをしなければならなかった企業がTiDBを導入して問題を解決してきました。
設計段階から分散環境を取り入れ、フルスクラッチで実装
――TiDBは、どのような課題をもとに作られたのでしょうか？
Bains：TiDBは、PingCAPのCTOのエド（Ed Huang氏）、CEOのマックス（Max Liu氏）、Dylan Cuiの3名が創り出しました。
彼らは元々、大手ISPのエンジニアでした。当時、非常に業績が伸びていて、常にスケールアウトやインフラを大きくするプレッシャーにさらされながらもサービスレベルを落とせないため、眠れない夜をずっと過ごしていたのです。そんなときに、GoogleのSpannerとトランザクションの論文を読んで、「これが我々の進む道だ」と直感してTiDBを作ることを決意したそうです。
TiDBができる前は、アプリケーションのデベロッパーはシャーディングを前提にモノづくりをしていました。シャーディングをするということは、複数のデータベースにデータが分けて置かれているわけですから、シャーディングをまたいだデータ集計はできませんでした。
ところが、TiDBができてシャーディングをしなくてもデータをスケーラブルに保持できるようになると、できることが増えるので、アプリケーションのデベロッパーはやることが多くなるという話もあります。つまり、できることが増えて仕事が変わってしまったのです。以前とは逆の意見をもらうようになってしまったという言い方もできますね（笑）。
――フルスクラッチでTiDBを作ったのは、MySQLの課題を解決するにはそうするしかないと考えたからでしょうか？
Bains：もちろんです。最初に、なぜTiDBをフルスクラッチで作ったかという点で理解しなければいけないのは、MySQLは本質的に1ノード（シングルノード）のシステムだということです。
そしてMySQLのデータベースの中にはオプティマイザーもストレージエンジンもありますが、分散環境で使うことが考えられていません。一応、レプリケーションなども存在しますが、基本的に後付けの機能で、本質的にはシングルノードのシステムだというのが、MySQLの特徴です。
逆にTiDBは最初から、分散環境で使うことを想定して作られたシステムです。ですから、最初からスケールアウトを念頭に置いて開発されています。先ほどの話に出てきたデータベースオプティマイザーを例にすると、TiDBのそのストレージエンジンは基本的には分散環境で動いていますので、オプティマイザーも分散環境で実行することができます。
言い換えると、MySQLのようにシングルノードで動いているのか、レプリケーションで動いているのかということを気にする必要が一切ないということです。ここが大きな違いです。
もう1つのポイントは、MySQLは1990年代に考えられたアーキテクチャーだということです。少し脱線しますが、GoogleやAmazonといったインターネットでイノベーションを起こした会社はデータベースカンパニーではありません。つまり、従来の1990年代のデータベースの考え方ではイノベーションを起こせなかったということです。
TiDBは、2000年代以降のインターネットでのイノベーションに基づいた発想から作られています。ですから、1990年代に作られたMySQLのコードを使うことができなかったのだと思います。
TiDBは、先ほどお話したデータベースのエンジンとストレージエンジン、それからメタデータを管理するエンジンといった、すべてのコンポーネントをスケールアウトできます。しかしMySQLでは不可能です。MySQL交換の一部のデータベース、例えばAWSのオーロラは、一部スケールアウトできますが、書き込みのノードは1個です。このような考え方の違いがあると思います。
Eric：MySQLのソースコードを一切使わずに1行目から書き始めるのは、勇気が必要だったと思いますね。
次の10年、15年を切り開く、未来に繋がる開発を支援する
――長らくMySQL開発で活躍されてきたBainsさんから見て、TiDBを他の類似サービスと比較した際の強みを教えてください。
Bains：TiDBの1番の強みは、やはり自動的にスケールアウトできることですが、さらにいうとアプリケーションを変えなくて良いという点です。デベロッパーが自分のラップトップでアプリケーションの開発をしているとき、アプリケーションを200TBにスケールアウトしたときでも同じものが動きます。何も変えずに動作させることができるのは大きな強みだと思っています。
――TiDBの、プロダクトとしての今後の展望を教えてください。
Bains：将来のTiDBのビジョンについては、2023年7月7日に開催した「TiDB User Day 2023」でCTOのエドから話がありましたが、すべてのユーザーにTiDB Serverlessを使ってもらいたいと考えています。今後の展望は、具体的には3つあります。
1つはマルチテナントということです。複数のデータベースを1つの大きいデータベースシステムの中に保有することは、コスト削減のために非常に有効だと考えています。
次が先ほど話したTiDB Serverlessです。ユーザーがスケールアウトとかスケールインといったことを一切気にしなくても良くなり、データベースを使うことだけに専念できるようにします。
3つ目がQOS（サービス品質）です。TiDB Cloudでは、安心してお使いいただける環境を提供し続けます。これは対障害性ということもありますし、サービスレベルを高く維持し続けることでもあります。これが、将来的なTiDB Cloudのビジョンです。
もう1つ、生成AIに限らずAIをプロダクトに取り込んでいくこともロードマップには入っています。既にPingCAPはAIによってクエリーを生成する「Chat2Query（チャット・ツー・クエリー）」という機能を提供していますが、その他にも、データベースのインデックスを自動で作る機能などをAIで実現し、プロダクトの中で活用しようと考えています。
――Bainsさんは、2023年7月7日に開催された「TiDB User Day 2023」に伴って来日されました。イベントでは複数の企業から事例が紹介されましたが、どのような感想を持たれましたか？
Bains：会場での熱気に驚かされました。データベースに大きな情熱を持っている方々が集い、話せて、有意義なイベントだったと思います。
非常に難しく困難な課題に取り組んでいるユーザーが、自身の言葉でTiDBの良さを話してくれるプレゼンテーションには大きな感銘を受けました。そしてTiDBが多くの方々の困難な業務の中で役に立っていると実感でき、大規模な環境で活用されている実例が示されて非常に嬉しかったですね。
――最後に日本のMySQLなどに関わる開発者とエンジニアに一言メッセージをお願いします。
Bains：MySQLは巨大なシェアを持っています。その一番の理由は、シンプルでしっかり動くことだと思います。MySQLに関わるエキスパートたちは、MySQLを活用し、MySQLの限界にチャレンジしてきており、おそらく元々の開発者が想定していないレベルで非常に大規模なスケールのMySQLのクラスターを作って運用しています。
ただ、それは同時に技術的負債を一緒に持たせてしまっている面があると思っています。今後データは減ることはなく、どんどん増えていく一方だというのも事実です。
TiDBは、エキスパートたちが考えている、シャーディングやスケールといった課題を考え抜いて生まれてきました。ですから、MySQLの課題を解決している部分があります。
MySQLに関わるエンジニアの方々にお伝えしたいのは、これまでの10年、15年存在してきた、既に解決された課題に労力をかけるのはやめて、これから先の10年、15年に関わる問題に取り組んでいきましょうということです。そのためにTiDBにチャレンジしてみてください。そしてもっと大きな、未来に繋がる課題に着手してみませんか、とお伝えしたいです。
Eric：日本でのTiDBの採用実績が増えている中で、日本特有の大きな2つの傾向が見られてきています。1つはやはり、エンジニアリソースが潤沢ではないことです。そのため、運用コストの削減が求められます。もう1点は、ローカルのサポートが必要だということです。
運用コスト面では、PingCAPはTiDBでシャーディング運用から解放されることをアピールしています。先日の「TiDB User Day 2023」で聞いたのですが、シャーディングの準備にあたって、2～3名のエンジニアを3ヶ月フルでリソース投入する必要があるなど大きな手間がかかることが多いようです。また、これまでのシングルノードのデータベースですと、バージョンアップやマスターノードの故障などがサービスダウンに繋がっています。
このような運用コストの削減でTiDBの導入を検討していただいているケースが増えています。その意味では、日本の大規模サービスの運用コストを削減する観点だけでなく、中規模のサービス、あるいはスモールスタートサービスでも有効だと考えています。
日本では、日本語でのしっかりしたサポート体制が求められていることも把握しており、日本でのサポート体制をさらに充実させる取り組みを進めています。
TiDBはMySQLのインターフェースを借りていて、喋る言葉は同じですが中身が全く違います。MySQLユーザーなら違和感もハードルもなく使っていただけて、今まで抱えてきた課題を解決できると思いますので、ぜひ一度検討してみてください。
編集後記
「TiDB」「PingCAP」の命名センスがCoolだと感じましたが、お話を伺うと、PingCAPの社会課題に真っ向から取り組む姿勢もCoolだと思いました。その真っ直ぐな姿勢は、日本法人の活動にも表れていて、取材の合間にEric氏が日本でのサポート強化について真剣に語っておられたのが印象に残っています。
これからデータは増えることはあっても減ることはありません。MySQLを使っていて「壁」にぶつかっている企業や団体は問題の解決と「未来」を考えて、ぜひ一度、TiDBの利用を検討してみてはいかがでしょうか？
取材／文：神田 富士晴
撮影：豊崎