企業が「NewSQL」を採用するメリットは？ PingCAP CTOに聞く「TiDB」開発の理由：詳説探究！DBエンジニアが征く（3）

分散SQLDB「TiDB」をOSSで公開し、開発を進めているPingCAPでCTOを務めるEd Huang氏と対談。TiDBの開発を始めたいきさつや、企業はRDBからNewSQLに移行すべきなのかなどについて聞きました。

[小林隆浩，野村総合研究所]

PingCAP CTO Ed Huang氏

　連載第2回ではCockroachDB、YugabyteDB、TiDBなどのNewSQLが、2021年にリリースした内容を振り返りました。NewSQLと呼ばれる新たなデータベース（DB）の目指す方向性が少しずつ見えてきたのではないでしょうか。

　第3回は分散SQLDBの「TiDB」をオープンソースで公開し開発を進めているPingCAP CTO（最高技術責任者）のEd Huang氏（以後、エド）に、NewSQLと呼ばれるDBはどこに向かうのか、TiDBはどのような立ち位置を目指して開発を進めているのか聞きました。

TiDB Cloudのアーキテクチャとは

小林　はじめまして、お会いできて光栄です。

Ed Huang（エド）　PingCAPでCTOをしているエドです。今日はよろしくお願いします。

小林　連載第2回でも紹介したように、PingCAPは「TiDB Cloud Developer Tier」を発表し、TiDBを開発者が気軽に試せる環境を整えてきたように見えます。この辺りの技術的なお話を聞かせてください。マネージドサービスとして利用できるTiDB Cloudは、どのようなアーキテクチャで作られているのでしょうか。例えば、CockroachLabsが2021年に発表した「CockroachDB Serverless」はKubernetesをプラットフォームとして利用していること（ブログ記事）で大きく注目を集めました。

（補足）TiDBについて

　TiDBはOSSとして開発されたスケールアウト可能なリレーショナルデータベースです。MySQL互換で既存のアプリケーションからの移行が容易でありながら、合意プロトコルであるRaftを用いたレプリケーションにより高い可用性とスケーラビリティを実現しています。また、列ストアの構造を併せ持つことで分析クエリにも高速に応答可能で、単一でリアルタイムなデータストアは組織内の全ての階層で意思決定を改善します。

エド　まず、Kubernetesに分散SQLDBを展開できる「TiDB Operator」は、PingCAPでも実績のあるデプロイ方式です。DBのデプロイにコンテナ技術を用いることで、リソースを細かく制御して活用できます。

小林　ということは、リソースを細かく分割してシェアするDeveloper TierもKubernetesを用いて管理しているのでしょうか。

エド　はい、Kubernetesをプラットフォームとして採用しています。「Gardener」というOSS（オープンソースソフトウェア）を利用し、Kubernetesクラスタを構築、管理する取り組みをしています。TiDB Cloudのアーキテクチャは今後、公開していく予定で、クラウドネイティブなシステムを運用するユーザーには参考になるでしょう。

小林　それは興味深いですね。マネージドサービスのプラットフォームとしてのKubernetesは、一般的になりつつあるように見えます。一方、マネージドサービス同士でアーキテクチャが似てきたり、APIが共通してきたりすると、差別化が難しくなります。つまり、TiDBは技術的に優れた分散SQLDBですが、その水平スケーラビリティや高可用性はクラウドの特徴として当たり前のものとして受け取られ、TiDB Cloudの差別化要因にはならないのではないかと考えています。

エド　その点はおっしゃる通りです。Amazon Web Services（AWS）が提供するAmazon AuroraでもわれわれのTiDB Cloudでも、非機能要件を満たせれば詳細は知らなくてもよいというユーザーがいるのも事実です。差別化をするには活発なコミュニティーの存在が重要だと考えています。端的にいえば、TiDBのアーキテクチャを理解して試してくれるファンを増やすということです。そうしたファンの方々がクラウドでマネージドサービスを利用する際には、TiDB Cloudが選択肢となってくるでしょう。コミュニティーを醸成することで、TiDBを“知って”“選ぶ”人々が増えていくと考えています。

小林　なるほど、CNCF（Cloud Native Computing Foundation）での積極的な活動もコミュニティーを盛り上げるのに効果的ですね。ところで、マネージドサービスを採用する場合にはクラウド事業者自体の障害が心配になります。TiDB Cloudはそうした障害には影響されない、マルチクラウドなサービスを提供する予定はありますか。

エド　現在、複数のクラウド事業者をまたがった構成でのサービス提供を検討中です。このようなクロスクラウドのマネージドサービスは、PingCAPのようなDBベンダーだからこそ提供できる形態で、ユーザーにも大きなメリットとなります。このようなDBaaS（Database as a Service）を構築するには、各クラウド事業者が提供するサービス（特にその違い）を正しく評価して、それらを組み合わせる能力が重要になってくるでしょう。

小林　それは非常に期待できるサービスです。私個人の考えですが、米国、中国で分散SQLDBが広まっているのは、国土が広くジオパーティショニング（データごとに利用される場所の近くに分散配置する機能）が注目されているからではないかと捉えています（参考記事）。それらは国土が狭い日本でも、同様に重要な機能となるでしょうか。

エド　ジオパーティショニングは良い機能ですが、米国、中国で頻繁に使われているとは言えません。それよりも急速なビジネスの成長を支えるために、高いスケーラビリティを持つDBとしてTiDBを採用するケースが圧倒的に増えている印象です。日本でもデジタルトランスフォーメーション（DX）が進む中で大量のデータが生まれるため、その受け皿として分散SQLDBは一層注目を集めていくと見ています。

小林　今後の方向性としてぜひ伺いたいのですが、TiDBはこれまでのRDBを置き換えるものなのでしょうか。それともスケーラビリティに優れたNoSQLが、さらに進化した形と考えるべきなのでしょうか。

エド　RDBからTiDBに移行する案件もありますが、既存DBMSで十分なら置き換える必要はないでしょう。NoSQLからの置き換えではKVS（Key-Value Store）よりも複雑なデータモデル、クエリを求めてTiDBを利用するケースがあり、われわれにとってもチャンスになると考えています。

TiDB、TiKVの開発の歴史

小林　ここからはTiDBの開発の歴史を伺います。エドさんはDB技術やOSSのコミュニティーと、これまでどのように関わってきましたか。

エド　MySQLをメインに、DBとは約20年間接してきました。そして2010年前後に、中国でモバイルを中心にインターネットトラフィックが急増する中で、RDBからNoSQLにシフトして「HBase」「Cassandra」「MongoDB」などに関わることになりました。ここ約10年間は分散システムに取り組んでいます。「Codis」というプロキシベースの高性能なRedisクラスタを提供するOSSのオーナーとしても活動していました。

小林　なぜ、そこから分散SQLDBを開発しようと考えたのでしょうか。技術面、ビジネス面でチャンスがあると思いましたか。

エド　分散システムの概念を用いてRDBをスケールさせるGoogle Spannerから着想を得ています。マイクロサービス化において課題となる、分散ストレージやDBの問題を解決してアプリケーション開発者を支援しようと思い立ちました。Spannerの論文を読みながらビルディングブロックのうちで何が重要かを検討し、分散ストレージの必要性に気が付きました。そこでTiKVの開発に取り組みました。

エド　また、KVSベースのDBはビジネスとしての課題がありました。開発者はSQLに馴染（なじ）んでおり、これがMySQLインタフェースを持つTiDBにつながりました。関連技術の成熟も分散DBの開発を後押ししました。高性能なSSDが登場し、データセンターのネットワークも低遅延になっていきました。ソフトウェアでもPaxosやRaftなどを取り込んだものが開発され始め、TiDB開発の下地がそろってきています。

小林　過去のTiDBはHDFS（Hadoop Distributed File System）ベースだったとのことですが、そこからどのようにアーキテクチャを変更していきましたか。

エド　もともとはApache HBaseの上にSQLレイヤーを開発しようとしていましたが、中で使われていたJavaがDBのような低レイテンシのシステムには向いていませんでした。さらにHDFSという分散ファイルシステムにHBaseというKVS、さらにSQLのクエリレイヤーを重ねるとオーバーヘッドが大きくなります。オーバーヘッドを取り除きながら、HDFSとHBaseで担保されていた可用性、スケーラビリティをネイティブな形で実現するという考えで、TiKVを開発していきました。

小林　TiKVは、単体でもNoSQLとして利用可能なポテンシャルがあるようにも見えます。

エド　私もCassandraと比較しても、性能や安定性の面で優れていると考えています。マルチレコードのトランザクションをサポートしていたり、ストレージ抽象化レイヤーなしでRaftを採用していたりするので性能面でも有利です。しかし、TiKV自体はTiDBからの利用に特化しているので、単体として使うには周辺機能で不十分な面もあるでしょう。

小林　TiDBをMySQL互換として開発したのはなぜでしょうか。CockroachDBやYugabyteDBのように、PostgreSQL互換という選択肢はありましたか。

エド　MySQL互換として開発した理由の一つは、中国でMySQLのユーザーが圧倒的に多いことが挙げられますね。私自身がMySQLに偏っていたことも影響しています。

小林　ビジネス的にはOracleのようなライセンスビジネスを目指していたのでしょうか。それともPerconaのようなOSSDBのサポートビジネスでしょうか。

エド　当初はRed Hatのようにプロフェッショナルサービスを提供するビジネスで考えていました。現在はTiDB Cloudも展開していますので、Amazon AuroraやSnowflakeのように、マネージドなDBサービスによる利用料ビジネスも加えて、2軸で考えています。

小林　なるほど、ありがとうございます。TiDBを開発したいきさつから、将来的にTiDB Cloudも加えて目指す所までさまざまな話を伺えました。

エド　こちらこそPingCAPとして目指す所がクリアになった気がします。ありがとうございました。

対談を終えて

　本連載の第3回では、NewSQL開発の最前線に立つエドと対談しました。OSSとして優れたDBを開発するだけでなく、それを多くのユーザーに使ってもらうためのマネージドサービス化も進めており、DB技術者に限らず参考になる話だったのではないでしょうか。今後も、自社のDB技術やビジネスに関する対談をしたい人はぜひお問い合わせください。引き続きよろしくお願いします。

筆者紹介

小林隆浩

野村総合研究所にてさまざまなプロジェクトで基盤担当のエンジニアとして経験を積む。なかでもデータベースに関する設計、運用、トラブルシューティングなどの業務で実績があり、得意とするDBMSはOracle DatabaseおよびPostgreSQL。データベースや基盤技術に関するコミュニティーに積極的に参加し、国内外のカンファレンスで登壇実績を持つ。