NewSQLを使えば新しいデータの置き方も可能になる　分散配置検証で分かったTiDBインスタンスの挙動

処理の高速化

水戸部章生氏：今までの話を振り返ると、Two Phase CommitはTSOを取得したり、リージョンの位置を把握したり、prewriteしたり、非常に何回もやり取りをするんだなと思いました。このような処理を改善すべく、2021年4月16日に新しいバージョンが出ました。TiDB 5.0では、これらの処理の高速化もサポートしています。

（スライドを指して）1つ目は非同期commitです。今までのcommitは、TSOは取得できますが、commitをするとprewriteをして、prewriteが終わるとまたcommit用のTSOを取得して、commit primaryを行ったらSuccessを返して、そのあとsecondaryのcommitが走るような流れでした。TiDB 5.0については、今回は紹介する時間がありません（笑）。

commit TSをどのようなロジックで設定しているか、別の機会で紹介できればと思います。prewriteをして確定すると、このデータはもう大丈夫ということで、commit処理を非同期で実施するので、ステップが1つ減ることになります。

そのほか、同じリージョンにだけデータを書き込む場合には、1PC、1Phase Commitで書き込む仕組みになっています。こちらは単純に、prewriteなしで1Phase Commitを行う仕組みによって、高速化を図っています。

TiDBの排他制御設定

また、TiDBはデフォルトでは悲観ロックになっています。もちろん他社のデータベースにはデフォルトでは悲観ロックになっているようなものもあるので、それらと合わせる意味もあります。また、先ほど話したとおり、CASやprewriteなどで実際にデータを書き込んだものの、ロックを取られていて元に戻さなければならない時には高負荷になってしまうので、先にロックを取得するような仕組みも使っています。

悲観ロックは、速くするためにいくつか技術的なことを行っています。1つは、メモリ上に2 Phase lockを置くこと。さらに、TiKVのnodeにコーディネーターの役割を持たせて、2PCブロックを回避することです。

（スライドを指して）簡単な図ですが、一番上にコーディネーターの動きがあります。下は、パーティシペーターです。最初にロックを取ったところでそれぞれのパーティシペーターが連絡をして、しっかり取り終わったあとにまた連絡を取り合うような流れで、回数を減らす動きをしています。

TiDBのロードマップ

TiDBのロードマップも共有したいと思っています。TiDBはだいたい1年に1回くらいメジャーバージョンが上がっているので、たぶんこのTiDB 6.0も2022年には出るのではないかなと思っていますが（笑）。日々改善しているようなプロダクトです。

TiDB 6.0では、MySQL 8.0のCompatibilityを取る予定です。また、Cross-region deployment。複数のリージョンをまたいでやっていますが、TiDB 6.0では大阪のアクセスは大阪だけ、東京のアクセスは東京だけといった処理ができるようなデプロイメントもやろうとしています。

ほかにPoint-in-Time-Recoveryです。PiTRやDistributed bulk data importingのような機能も鋭意開発している状況です。（スライドを指して）一応ロードマップを示しますが、計画が変わる可能性もあるので、現状の共有として見ておいてもらえたらと思います。

アジア規模の分散配置検証

最後におまけとして、AWS上での東京・大阪＋ソウルの分散配置を少し試してみました。NewSQLなので先ほど話した地球規模まではいけませんでしたが、アジア規模でやってみました（笑）。

私たちのTiDBはAWSでインスタンスを生成して、デプロイが非常に簡単になっています。tiupコマンドで作ったyamlを読み込むと、すぐにインスタンスが作成されて稼働できるという2ステップで作っています。

今回のストアの配置は、大阪リージョンにTiKVと呼ばれるRaftのデータ置き場を3つ、東京リージョンに3つ、ソウルリージョンに1つとなっています。3つのコピーなので、それぞれのデータがしっかり分散されるような仕組みで置いています。

（スライドを指して）東京側に負荷をかけるインスタンスを生成して、この負荷だけを行ってみました。実際やってみると、少しレイテンシーが高くなっています。95パーセントタイルで89ミリセクです。99.9パーセントタイルでは252ミリセクになっていますが、今回はソウルリージョンにもリーダーを配置してしまっています。

今回は東京・大阪間だけでしっかりできるというコンセンサスのためなので、偶数でTiKVを置くとコンセンサスでは過半数が取れないため、ソウルリージョンにだけ1台置いて、そこにはリーダーを置かず、アクセスをしないようにしようと思いました（笑）。しかし、間違ってリーダーも配置してしまったので、89ミリセクと少し高めになっています。

東京・大阪だけでリーダーを配置すると40ミリや30ミリセクくらいになるので、サービスでもけっこう使えるのではないかと思えるくらいのレイテンシーだと思っています。

そして、実際に大阪に落としました。特に大阪がどうというわけではありませんが、たまたま大阪のリージョンの画面を開いていたので（笑）。

実際にリージョンを落としてみたいと思いますが、それはできないので、強制的にインスタンスを落としてみました。その結果、私たちのTiDBのRaftはリーダーのポイントが20秒で移動するようになっています。決して20秒間トランザクションを止めるわけではなく、20秒待機するようなかたちです。

（スライドを指して）上の図がCPUです。下の3つは大阪にあったTiKVノードが落ちているので、右側がなくなっています。一気にCPUが下がって、残りが上がってくる。下の図はTiKVの中にあるリーダーです。リーダーの配置がどうなるか。100個くらいあったリーダーがインスタンスを停止したことによりすべて落ちて、20秒後にほかのリージョンに移動しました。リーダーが移動したことによって、サービスはそのまま継続できます。

トランザクションはエラーなく稼働しているので、TPCC上ではまったくエラーのない状態でした。このようにNewSQLを使うと、新しいデータの置き方もできるのではないかと思っています。

PingCAPの製品とプロジェクト

私から、TiDBがどのような製品か、どのようなトランザクション処理ができるのかを簡単に紹介しました。そして、次のパートも私から始まります（笑）。ここからはPingCAP社として、私たちの製品を少し紹介して売り込もうと思っています。

私たちPingCAPは、製品やプロジェクトを複数持っています。（スライドを指して）こちらは、横軸にサービス型とサブスクリプション型、縦軸にそれぞれのプロダクトと分けて示しています。

左上がNewSQLで、「TiDB Cloud」というクラウド型データベース、フルマネージドサービスを提供しています。今はAWSとGCPの2つはフルマネージドサービスとして提供し、Azureは年内の提供を予定しています。他社のフルマネージドと同じくエンドポイント、つまり、お客さまに渡しても基本的なインフラ部分は私たちが管理する渡し方になります。

また、今紹介したTiDB Cloudの中に入っているTiDB分散型データベースも、通常のプロダクト、製品として出しています。もちろんオープンソースなので、お客さんがダウンロードして使うことも可能です。

NewSQLの中のKey-Valueストアのキーコンポーネント、ACIDサポートをしている「TiKV」と呼ばれるKey-Valueストアも製品として出しています。こちらはCNCFに寄贈しているプロジェクトですが、すでにGraduated Projectという成熟したプロダクトとして認定を受けています。スターも27,000くらい獲得した、非常に勢いのあるKVSだと思っています。

また、CNCFに参画しているので、Kubernetesをはじめ、Podが落ちたとしてもしっかりサービスを継続できます。ネットワークのスピリットを切る、CPUの負荷が上がってくる、メモリ使い切ったなどのシミュレートをするためのカオスエンジニアリングツールも出しています。「Chaos Mesh」と呼ばれるものですが、こちらも使用が可能です。

また、Chaos MeshとTiDB連携してTiPocketと呼ばれるものを作り、相互に連携しています。TiDBのリリースや何かしら不具合があった時のチェックにも、カオスエンジニアリングを使ってTiDBの品質を担保する取り組みを行っています。

さらに、TiDBエコシステムとして、移行・バックアップ・モニタリングツールも非常に充実しています。アップストリーム、ダウンストリームでBinlogを読み込んでTiDBに使わせるほか、Grafanaなどで監視し、TiDB OperatorをKubernetesタイアップでデプロイしています。

そのほか、インターフェイスとしてはSpark SQLもサポートしているので、ぜひお願いします。