登壇者の自己紹介と会社紹介
関口匡稔氏：みなさん、初めまして。PingCAPの関口と申します。残念ながら今日は、当社のCEOのMax（Max Liu氏）が風邪を引いてしまったので、代わりに私が発表させていただきます。よろしくお願いします。
（会場拍手）
Hello, English speakers. I'm Seki from PingCAP as a Solutions Architect, and I'm sorry for that Max won't make it today, and I'll talk this session in Japanese, but if you have any questions, feel free to ask me at the Ask the Speaker forum. Thank you.
今日は、「TiDB Serverless」という、サーバーレスデータベースのお話をしたいと思います。製品紹介をしてもおもしろくないので、TiDB Serverlessをなぜ作ろうと思ったかという話と、どうやって作っているかですね。これは、みなさんがサーバーレスのビジネスやアプリケーションを作る時にたぶん参考になるんじゃないかなと思います。
TiDB Serverlessというデータベースが、実際のアプリケーションにどういうインパクトを与えたかというのを、我々のOSS Insightというサイトの紹介と、それをTiDB Serverlessに置き換えてみましたというお話の中で紹介したいと思います。
あとは、TiDB Serverlessはどういうことができるのかということで、特にサーバーレス的なフィーチャーに特化してお話ししたいと思います。よろしくお願いします。
最初に、会社紹介です。さらっといきますが、当社はPingCAPといいます。創業者の3人が「TiDB」を作ったので、まさにデベロッパーなのですが、彼らが立ち上げた会社になります。2015年創業で、本社はシリコンバレーのサニーベールというところにあります。
世界中に支社があって、グローバル展開でビジネスをやっていますが、日本支社にも30名弱、全世界で見ると550人超の社員がいます。スタートアップですが、日本円にして800億円ぐらいの投資を受けています。
私たちのミッションは、「エンジニアのみなさんに役立つ、スケーラブルなデータベース、スケーラブルなインフラストラクチャーを提供する」ということです。みなさんの会社のビジネスが、アジリティを持って進められるようになること、これがミッションです。
世界で一番進んでいるオープンソースの分散型データベース「TiDB Serverless」
TiDBの話をしたいと思いますが、TiDBをご存じの方は、ちょっと手を挙げていただけますか？ そんなにサインアップしていただいていないと思うんですけど。ジョークです、ジョーク（笑）。
（会場笑）
ジョークですが、TiDBは世界で一番進んでいるオープンソースの分散型データベースです。「MySQL」互換の分散型データベースというので、非常に珍しいと思いますが、それを自負しています。
（スライドの）右側にあるように、大小含めて、3,000社以上のさまざまな企業で使われています。「GitHub」のスターも3万5,000ぐらいあって、かなり人気の高いプロジェクトになっています。知らなかった方は、ぜひ今日覚えていっていただければと思います。
分散データベースを無料で提供するには5,000億円以上かかる
私たちはサーバーレスのTiDB Serverlessをマネージドサービス、Fully Managed Serviceで提供しているのですが、今日のお話は、なぜそれをやろうと思ったか、というところからスタートします。
これは、6年ぐらい前に当社の創業者のMaxとEdが話していたものです。私たちデベロッパーはこういう分散データベースを提供することをミッションとして掲げているわけですが、本当にすべてのデベロッパーに、この分散型、スケーラブルなデータベースをタダで提供するというのを思いついたとして、「それって本当に技術的に可能ですか？」と。もう1つ大問題なのは、「それって本当にコスト的に見合うのか？」という話なんですよね（笑）。
最初に、簡単な計算をやってみましょうかというところで、「じゃあ、デベロッパーはそもそも世界中に何人いますか？」ということでググると、だいたい2,700万人ぐらいいます。
この数について、どう思いますか？ 僕はちょっと少ないなと思いました。日本の人口より少ないことをちょっと不思議に思ったのですが、これぐらいのデベロッパーがいます。
仮に、この2,700万人のデベロッパーに分散型データベースをそのまま渡すとします。みなさんにTiDBそのものを使ってもらおうとすると、少なく見積もっても4台のサーバーが必要です。
仮にt2.nanoで作れるとしても、全員に本当にこのt2.nanoを4台割り当てていくと、2,83ビリオンドルになります。日本円にして、だいたい4,000億円ぐらいかかっちゃうと。会社が成り立たないですよね（笑）。なので、志はすばらしいけど、こんなんじゃ会社やっていけるかという話になります。
ところが、これで終わりではありません。今のは、コンピューティングリソースの話であって、ロードバランサーが必要なので、ELBを足します。するとさらに800ミリオンドルぐらいかかります。トータルで3.6ビリオンドルパーイヤー（$3.6 billion/year）ということで、日本円にするとだいたい5,000億円ぐらいになりますと。ますます無理度が上がってきました。どんな大企業なのよって話になります。
まだ終わりではありません。もっと恐ろしいことに、今データベースの話をしているのですが、ディスクのコストの話をぜんぜんしていないじゃないですか。カウントしていなかったんですね（笑）。少なく見積もっても2倍はかかりますよねということで、その他、モニタリングシステム、ネットワーク、諸々考えると、「やってられませんわ」という話になります。
みなさんも「Copilot」などを使っていると思いますが、どんどん楽になってきて、デベロッパーやろうという人がやはりどんどん増えています。年々人は増えているのに、それを考慮に入れないで、「よし、今年は5,000億円だからなんとかやれるか」と言って、翌年になったら1兆円超えましたでは話になりません。
“伝統的なアーキテクチャ”をやめた
さて、どうするか……まぁ、諦めますかと（笑）。ちょっと夢が膨大すぎましたかねと。それは冗談で、私たちが諦めたのは、今お話しした、要するに分散データベースを各デベロッパーごとに、デディケーテッド（dedicated）で割り当てることです。もうそういう考えはやめましょう、そういうアーキテクチャはやめようということです。
まず何を考えていたかというと、データベースをお使いのみなさんだったらたぶんわかると思いますが、データベースの利用率って、実はそんなに高くないんです。だいたい8割を超えるとアラートを鳴らすように設計されていて、普通はだいたい2割を切っていると思うんですよ。
であれば、使っていない時は止めればいいじゃんと。この発想を基にアーキテクチャを考え直しました。これってみなさんどこかで聞いた話だと思います。そうです、「サーバーレスにしよう」ということがここで生まれました。
使っていない時はもうシャットダウン、ゼロにしてしまって、使う時だけ立ち上がるようなアーキテクチャにしないと、そもそもみなさんにサーバーレスモデルでデータベースを提供するのは割に合わないんですね。
じゃあ、さっきの計算に戻ります。まず、止めていいということになると、普通の「EC2」インスタンスをオンデマンドで立ち上げたり、リザーブドにしておく必要がないので、スポットインスタンスを買いましょう。これで7割ぐらいディスカウントされます。
それから、先ほど言った使用率の話で、だいたい8割・2割の法則で、8割方のリソースはだいたい使っていないので、使える時に使えるという前提で8割カットしましょう。
そうすると計算は、3.6ビリオンドルに0.3と0.2を掛けます。はい、これいくらですか？ と言われた時に、日本人はだいたい、このビリオンとミリオンの計算が難しくて、こんがらがっちゃうんですね。うちのMaxもそうなので、「ChatGPT」に聞きます（笑）。
（会場笑）
「216ミリオンドルです」と出てきました。このスライドを見た時、「この調子でPingCAPの会社は運営していないよな？」って、すごく不安に思ったんですけど（笑）。それは置いておいて、216ミリオンドルです。だいたい日本円にして350億円ぐらいですかね、だいぶ減りました。
アーキテクチャの図を紹介
すごくラフな初回のアーキテクチャがこんな感じです。最初にロードバランサーとゲートウェイがあって、ユーザーのリクエストを振り分けて、コンピューティングの「SQL Layer」と書いてありますが、コンピューティングノードが引き受けます。あと、ストレージレイヤーがあります。データは「S3」に保存する。こんな感じのアーキテクチャを考えました。
いわゆる分散型データベース、NewSQLやDistSQLは、すべてこういうアーキテクチャになっています。コンピュートノードとストレージノードを分けています。
これは、実はサーバーレスに非常に向いています。というのも、先ほど見ていただいたとおり、左側を見ると、「Shared」と書いてあると思いますが、コンピューティングというのは、リクエストごとに固有です。
例えばどのSQLを投げるかは人によって違うじゃないですか。なので、それぞれに割り振らないといけません。それぞれにコアを割り振らないといけないのですが、ストレージは実はやっていることは一緒なんですよ。言われたデータを返しているだけなので、ここはみなさん共有でもぜんぜんかまわない。
ここで先ほどのマルチテナンシーという話が出ましたが、このストレージノードから下は、マルチテナンシーにできるんですね。みんなで共有しようということで、ここでまたコストが稼げる。
コンピュートをさらに重いものと軽いもので分割
さらに進んで、今ストレージとコンピュートを分けて、ストレージをSharedにしました。「コンピュートをさらに分割することはできないんですか？」というところですね。
アプリケーションを作っているデベロッパーの人は、たぶんご存じだと思いますが、アプリケーションのロジックとか計算って、全部同じ粒度じゃないですよね。やはり軽いものと重いものがあって、それぞれ混ざってアプリケーションは構成されていると思います。データベースも一緒です。なので、まずこのライトウェイトなものと、重い計算を分けてみたらどうでしょうと。
データベースにおける軽い計算と重い計算って、じゃあ、なんなのか？ という定義がここに書いてあるのですが、軽い計算というのは、要は、みなさんが投げるクエリそのものです。SELECTであったりINSERT、実はこれらは比較的軽い計算に入ります。
重たいクエリを投げていても、しょせん、1人のユーザーがガサッとやるようなクエリは、軽い部類に入れちゃっていいんじゃないかなと思います。
重たいところというのは、実は、みなさんが見えていない部分なんですね。データベースがバックグラウンドでやっている処理です。ここには、インデックスの再作成とか、テーブル定義の変更とか、さらには統計情報の更新とか、そういったさまざまなオペレーションがあります。特徴としては、だいたい全部のデータベースを舐める処理をしている。
ライトウェイトのほうは、だいたいWHERE句に条件とかをつけると思うし、あとINSERTの部分は別に1個じゃないですか、1行INSERTとかなので、レコード数は限られるんですけど。
ヘヴィーのほうは、もうほぼすべてのレコードを舐めるような処理をやっています。これは非常に重たい処理です。これがバックグラウンドで動いているというところがデータベースになっています。
まず考えたのは、このライトウェイトな部分とヘヴィーウェイトな部分を分けるということです。重たい処理と言っていた部分をマイクロサービスにして外出しにする。
基本的にこのヘヴィーの処理というのは、誰がやるにかかわらず同じ処理をしているんですよ。テーブルを全部舐めて、インデックスを作り直したり、テーブル定義の変更をしたり、統計情報なんてそうですが、今特定のテーブルを1つ見て、どういう分布になっているかというのを別のテーブルに書いたりする。そういった処理は、人によらずだいたい一緒なので、これをマイクロサービスとして外出しにしようと考えました。
みなさん開発者なので経験があるかもしれませんが、重たいやつと軽いやつを混ぜて処理すると、実は軽いやつは、非常に迷惑を被るんですよね。バックグラウンドで重たい処理をガンッとやっているところに、いくら軽い処理をやっても、軽く終わらないんですよね。待たされるか、遅くなるかの2択です。
なので、こういう重たい処理をオフロードをして外に出すと、それだけで、CPUの効率が上がるんですよ。並列数も高まるし処理もすぐ終わるので、それを連続してやることができる。
実際のところ、CPUの稼働率が2倍上がりました。ということは、コストにすると2分の1になります。半分のCPUで済みます。
さらにうれしいことに、レイテンシーも少なくなりました。これは、先ほどの例と一緒で、重たい処理をしているところでいくら軽い処理をしても、遅くなっちゃうんです。重たい処理が抜けるとどうなるかというと、軽い処理だけになるので、その分早いレスポンスが返ってくる。そういう話になります。
スターバックスより安くなった
ここまで来ると、先ほど300ミリオンドルでしたっけ。ちょっと金額を忘れちゃった。年、216ミリオンドルですね、だいたい300億円ぐらいだったものが、ざっくり半分なので、100ミリオンドル……だいたい150億円ぐらいになります。
これを先ほどの2,700万人で割ると、1開発者あたり3.7ドル、たったの3.7ドルです。スターバックスより安いです（笑）。
（会場笑）
1年間データベースを使っても、スターバックス1杯分ということで、ぜんぜん払える額になってきます。現実味が増してきましたよね。
なので、最初めちゃくちゃ無理に思えた5,000億円も無償で提供するという会社、そんなの世の中にどこにいるんだという話になっていましたが、今や一人ひとりにスターバックスをおごる気分ですよ、本当に（笑）。
（会場笑）
それぐらいのところまで来ました。信じられないと思いますが、これがサーバーレスの力なんですよね。先ほどAlex（Alex Debrie氏）がお話ししたマルチテナンシーと、シェアードサービス。要はマイクロサービスとして重たいものを外に切り出すなどのアーキテクチャの力なんです。これが、TiDB Serverlessです。
何も損していないばかりか、むしろ得をするのがサーバーレスの力
まさに今、私たちは提供していますが、これで終わりじゃないです。これでやっと、みなさんにスターバックスの代わりにデータベースを提供するという目標が達成できたので、ここから先は、もうアップサイドだけですね。どんどんどんどん、おもしろ機能を追加していくという楽しいフェーズに入っていくわけです。
じゃあ、どういうことをするかというと、データベースの会社なので、データベースとして良くないといけないんですね。サーバーレスにすることで、データベースは何がいいんですかという話なのですが、先ほどのオフロードの話を思い出してください。重たい処理を共有マイクロサービスとして外に出しましたよね。
例えば4コアのデータベースサーバーがあったら、4コア以上の仕事はできないじゃないですか。でも今、マイクロサービスとして重たい部分を外に出しました。仮に100人ユーザーがいるとして、「その重たいサービスで2コア使っていました」というユーザーが100人いたとしたら、200コア使っても別にいいんですよ、この重たいサービス、共有マイクロサービスは。
ということは、サーバーレスにしたら逆に、この重たいサービスの性能を上げてもいいんです。普通にデータベースを4コアで使っているよりも、サーバーレスにして100人共有にして、100人共有のデカいマイクロサービスを作って、そこにがっつりコアを割り当てると、むしろ重たい処理が早く終わっちゃう。
実際のところ、インデックスの作成や、統計情報更新という処理は、普通のマネージドデータベース、他社さんのマネージドデータベースよりもぜんぜん早く終わります。
もう1つのポイント。私たちは、TiDB ServerlessをAWSの上で提供しています。AWSにはS3があります。S3の耐久度、みなさん言えますか？ 99.……はい、いくつ9が並ぶでしょう？ 言えないと思います。僕もさっきググって調べたのですが、9個並ぶんです（笑）。S3に書いたデータは、ほぼ消えないわけですよ。
そうすると、データベースとして一番重要な、データを保存するという役割は、みんなS3に書けばもうそれでOKになってしまう。わざわざ難しいことをしなくてもS3に書いたらそれでいいんです。もしトラブルがあってノードが倒れたら、S3からデータを戻せばいいんです。
なので、アーキテクチャもすごくシンプルになりますし、みなさんに、安心して使っていただけるデータベースとしての耐障害性を提供できるようになります。
こういうクラウドのインフラを活用して、サービスを巨人の上で提供するというのが、今まさに私たちがやっていることなんです。
最終的な、現在のTiDB Serverlessのアーキテクチャをざっくり書いたものがこちらです。コンピューティングノードですね、ユーザーごとにコンピューティングリソースを割り当てる薄いコンピューティングレイヤーがあって、その下に共有のストレージキャッシュ、それからストレージレイヤー、実際はS3にダンッて書いているだけです。外側に、オフロードされた重たいマイクロサービスがあります。
こういうアーキテクチャにすることで、むしろみなさまのユーザビリティは上がっているんです。何も損していないばかりか、むしろ得をしているというのがサーバーレスの力になります。
（次回につづく）
