はじめに
6月27日に実施された TiUG #2 で、PingCAP CTOのEd Huangの発表内容の書き起こしです。
当日は通訳として参加しましたが、時間の都合や配信トラブルなどもあったりしてなかなか良い訳にはならなかったのではないかなと反省しております。ここでは、録画から英文テキストを抽出して、より原文に忠実な日本語訳としています。
The Journey from MySQL to TiDB
イントロ
皆さんこんにちは。今日はここに来ることができて本当に嬉しいです。今日はTiDBのハードコアな技術を紹介するつもりはありません。
また、宣伝をするつもりもありません。代わりに、TiDBの道のりについての興味深い事実や楽しいことを紹介したいと思います。
自己紹介
まず、簡単に自己紹介をします。開発者として、多くの成果を紹介するよりも、自分のGitHubページのスクリーンショットを共有する方が好きです。少なくとも、まだコードを書いていることを証明できます。
※Edのgithubはこちらです https://github.com/c4pt0r
TiDBの道のり
今日のトピックはTiDBの道のりについてです。TiDBプロジェクトを始めた9年前のことを覚えています。世界中でこれほど大きな影響を与えるとは想像もしていませんでした。この道のりの非常に重要なマイルストーンについて話したいと思います。
最初のマイルストーンは、プロジェクトを始めた理由と初期の面白い背景です。
二つ目のマイルストーンはプロジェクトの転換点です。当初は分散型のMySQLやPostgreSQLのようなデータベースを作ることを目指していましたが、今日ではOLTPと分析ワークロードの両方を処理できるHTAP機能が最も価値のある機能の一つです。この転換の背後にあるストーリーを共有します。
最後のマイルストーンは、データベースソフトウェアからクラウドデータベースサービスへの移行です。
プロジェクトの始まり
全てのスタートは2015年に始まりました。私たちには三人の共同創業者がいて、Max、Dylan、そして私です。
当時、私たちはAndroidアプリのApp Storeのようなマーケットを提供する急成長中のスタートアップで働いていました。
私たち三人ともエンジニアで、Goが大好きでした。その会社のデータベースとインフラストラクチャチームで働いており、多くのオープンソースプロジェクトをGoで作成していました。
TiDBを始める前に、Maxと私はcodisという有名なオープンソースプロジェクトを作成しました。これは分散型Redisソリューションで、日本にもユーザーがいます。
codisの成功の後、私たちは野心的になりました。キャッシュレイヤーのスケーラビリティの問題を解決したら、次にリレーショナルデータベースのスケーラビリティの問題を解決したいと考えました。
面白いことに、私たちはSQLデータベースを構築した経験が全くありませんでした。この複雑さを知らなかったことが幸いで、もし知っていたらプロジェクトを始めなかったでしょう。
当初はスケーラブルなMySQLを作りたいと思っていました。なぜなら、当時のユーザーの多くがMySQLを非常に単純な方法で使用していたからです。シンプルなクエリやプライマリキーの検索、セカンダリインデックスの使用などです。
私たちは最初に、このようなMySQLのシャーディングソリューションを置き換えるスケーラブルなOLTPデータベースを作ることを目標にしました。
しかし、最初のバージョンをリリースしたとき、誰も本番環境で使おうとしませんでした。人々は新しいデータベースをミッションクリティカルなOLTPワークロードで使用することに慎重でした。
このプロジェクトは野心的でした；シャーディングが不要でスケーラブルなデータベースを想像してみてください。人々はそれを使いたかったのですが、十分な自信がなかったのです。そのため、彼らは我々のDBをバックアップやレプリカとして使い始めました。
もう一つの面白い事実があります。GoプログラマでMySQL関連の作業、binlogを取り扱ったりする場合、go-mysqlという人気のライブラリを使うかもしれませんが、実はこれは初期のPingCAPチームが書いたものです。
このライブラリをベースにして、私たちはシャーディングされたMySQLクラスターのレプリカとしてTiDBを使えるようにするツールを作成しました。つまり複数のシャーディングされたMySQL群を、一つの大きなTiDBテーブルにレプリケーションするものです。
このツールは、元々はMySQLからTiDBへの移行コストを削減するために設計されました。しかし、面白いユースケースを発見することになります。
ユーザーはOLTPワークロードをシャーディングされたMySQLクラスタで実行していました。しかし、分析クエリはシャーディングされたクラスタ上で実行することができません。
しかし、TiDBならそれができます。TiDBにはすべてのデータが入っている上に、MySQLプロトコルをサポートし、強力なSQLエンジンを持っていたからです。TiDBは複雑なクエリや結合を実行でき、リアルタイムでデータを同期できるため、多くのユーザーが分析クエリをTiDBで実行するようになりました。
しかし、当時はびっくりしました。TiDBはそのようなワークロードのために設計されていなかったからです。私たちは困り果てて、顧客やユーザーに対して「あなたはTiDBを間違った方法で使用していますよ」と言いたかったのです。しかし、ユーザーはこのアプローチを非常に気に入っていることがわかりました。
OLTPからHTAPへ
その当時、2016年から2017年頃、私たちにはOLAPや分散コンピューティングのバックグラウンドを持つエンジニアがいませんでした。私たちはOLTPのチームでした。
そこで、OLAPクエリの速度を上げるために、Sparkをスタックに導入しました。特にコンピューティングレイヤーにおいてです。
しかし、これにより、スタックに別のソフトウェアを導入しなければならず、システム全体の複雑さが増しました。それでも、ユーザーはこの複雑さを受け入れ、実際にこの方法を好んでいることがわかりました。
この時点で、私たちはOLTPとOLAPを統合するプラットフォームの構築により多くのリソースを投入することを決定しました。最初に行ったのは、TiFlashと呼ばれるカラムナストレージエンジンを導入し、データスキャンの速度を上げることでした。しかし、TiDBバージョン4.0ではまだSparkに依存していました。
TiDB 5.0では、MPP（Massive Parallel Processing）フレームワークをTiDBのシングルレイヤーに導入し、ストレージエンジンと組み合わせました。これにより、顧客はもうSparkを使用する必要がなくなり、TiDBを統合プラットフォームとして使用できるようになりました。
この道のりは、私が大学でSQLデータベースを学び始めた頃を思い出させます。
最初に使ったデータベースはOracleでした。私の先生たちはOLTPとOLAPの違いを教えず、どんなクエリでもOracleで実行していました。
HTAPプラットフォームを構築した後、TiDBがその時代のようにデータベースを使えるように、開発者を助けていることに気が付きました。過去10年間、データベースは非常に複雑になり、開発者がOLTPとOLAPの違いを理解するのが難しくなっていました。
おそらくこれが（HTAPが)将来のデータベースの目指す姿でしょう。
データベースプラットフォームへ: ２つのアプローチ
次は何でしょうか？私が考えるデータベース業界の、データベース技術の次の大きな変革は、データベースソフトウェアからデータベースプラットフォーム、つまりクラウドサービスへのシフトです。
私は本当にクラウドが新しいオペレーティングシステムになると信じています。昔はデータベースソフトウェアをダウンロードしてラップトップにインストールしていましたが、将来はクラウドが新しいオペレーティングシステムとなり、クラウド上でデータベースをプラットフォームとして実行することになります。
みなさんの中には、「クラウド上で動かす？ そんなに難しく考えることはない。自動デプロイメントのためのオペレーターやTerraformスクリプトを書けばいいじゃないか」と思う方もいるでしょう。わかります。私も当初そう考えていました。
初期の頃、私たちはTiDBオペレーターを書いてオープンソース化すれば済むと考えていました。kubernetesには将来がありそうでしたし、正しい方向性に思えました。それで、TiDBクラウドができると思っていました。しかし全然そんなことはありませんでした。
この図は、TiDBクラウドの最初のバージョンのアーキテクチャを示しています。すべてのボックスを紹介するつもりはありませんが、非常に複雑であることを示したいと思います。TiDBのカーネルは右上のグレーの箱、ほんの一部に過ぎず、他の部分はTiDBをサービスとして構築するためのコンポーネントです。
これが現在のTiDBクラウドのDedicatedティアのアーキテクチャです。多くの部分を簡略化して記載していますが、異なるクラウドベンダーとリージョンごとにグローバルコントロールプレーンとリージョナルコントロールプレーンがあります。それぞれのリージョナルコントロールプレーンが特定のリージョンの専用TiDBクラスターを制御しています。
このアーキテクチャには興味深い話があります。TiDB Cloudはすべてkubernetes上で動いていますが、初期の頃はコントロールプレーンとデータプレーンを一つの大きなモノリシッククラスターにまとめられており、AWSのAPIにかなり依存した作りとなっていました。しかし、現在のアーキテクチャでは、これらの部分を分離し、管理しやすく、スケーラブルにしています。
かなりの労力を費やしてこれを分離し、クラウド中立なアーキテクチャにリファクタリングしました。この分離により、現在は複数のクラウドをサポートできるようになりました。これには多くの時間がかかりましたが、クラウドインフラストラクチャ全体を再構築した結果、今年Azureサポートを追加できるようになったのです。
これが一つ目のアプローチです。
２つ目のアプローチ
最初のアプローチでは、異なるテナントが異なるインフラストラクチャ（例えばEC2の仮想マシンやVPC）を使用しているため、完全な隔離が可能です。しかし、このアーキテクチャの欠点はコストです。例えば、無料ティアを大量のユーザーに提供するため、クラスターを都度起動することはできません。
二年前、私たちはTiDB Serverlessプロジェクトを開始し、共有アーキテクチャを採用しました。すべてのユーザーは論理的かつ仮想的に分割され、同じTiDBクラスターを共有しています。現在、このアーキテクチャで35,000以上のアクティブクラスターが低コストで稼働しています。
実際、私はこのモデルで世界中のすべての開発者に対して、合理的なコストで無料のデータベースサービスを提供できると確信しています。
この二つの異なるアプローチでデータベースサービスを構築することは、全く異なる結果を生み出します。しかし、ユーザーの視点から見ると、これらはすべて一つのTiDBサービスです。
さらに、このデータベースプラットフォームを構築することで、サービス以上のものを得ることができます。例えば、マルチテナンシーや、リソースコントロールなどです。これは、TiDBの最近のバージョンのカーネルに非常にクールな機能が追加されていることからもわかります。これらの機能は、私たちが構築しているクラウドプラットフォームに関連しているものです。
TiDBの哲学
最後に、まとめとして、私がTiDBを構築する道のりの中で本当に信じている哲学を紹介したいと思います。
最初に言えるのは、私たちはクラウドが未来であると本当に信じているということです。これは、このプロジェクトを始めた最初の日からの信念です。
二つ目は、中立性を保つことです。多くのハードウェアやクラウドベンダーが私たちに「特別なハードウェアを構築しています。TiDBはこのハードウェアをサポートできますか？このハードウェアを使用することで非常に良いパフォーマンス向上が期待できます」と言ってきます。しかし、私は常にこのような機会を断ります。なぜなら、ソフトウェアは非常に重要ですし、将来的にはハードウェア層はクラウドインフラストラクチャによって隠されると考えているからです。
（※以降は録音が取得できませんでした！ ごめんなさい。スライドの記載の日本語訳を載せます）
三つ目は、オープンであること。新しいことを受け入れることと、オープンソースであること。
四つめは、データベースはデータベースだけではないということ。エコシステムも同じくらい重要です！
五つ目はシンプルであること。シンプルに保つことは、複雑さに打ち勝つための最強の武器となります。