はじめに
昨日、「NewSQLデータベースでどう変わる？」というウェビナーを開催しました。
ミックさんとこばさんの「NewSQL徹底入門」書籍刊行記念ということで、おめでとうございます！
ミックさんのプレゼンも、こばさんのプレゼンもNewSQLのアーキテクチャを知るうえでコンパクトかつ網羅的で、非常に参考になります。（たぶんそのうち公開されると思いますので）公開されましたらぜひ御覧ください。
後半は私からTiDB Xの紹介、西さんによるサイバーエージェントでのDifyのRAGデータベースとしてのTiDBの利用、altplusの浦谷さんから既存ゲームをTiDBに移行した事例をお話いただきました。
この記事ではこの後半部分について、TiDB Xの文脈で書いていきます。
TiDB Xとは
最近発表された TiDB Cloud でのTiDBクラスタの新アーキテクチャです。
ここで強調したいのは、このアーキテクチャはいきなり出てきたわけではなく、2021年から提供していたTiDB Cloud Starter(旧Serverless）のアーキテクチャを発展させたものだということです。旧Serverlessのアーキテクチャはこちらに記載があります。
TiDBが元々ベースとしているのはShared Nothing型のアーキテクチャで、ストレージレイヤーであるTiKVはRaftプロトコルによるレプリカを持ち、これにより耐障害性とスケーラビリティを実現しています。
TiDB Xでは、S3を最終ストレージとするShared Everythingアーキテクチャを採用しつつ、TiKVはそのキャッシュレイヤーとして動作します。
TiKVとS3の役割分担の詳細は公開されていないので筆者にも不明なのですが、個人的にはRocksDBのMembuffer/L0/L* くらいまでをTiKVが持ち、深い階層をS3にコピーしているのかな？と思います。コンパクションはS3で、という記述もあるのでひょっとしたらL1からS3が正なのかもしれません。
ウェビナーでは時間の都合上、このアーキテクチャのメリットについて詳しく触れることができませんでしたが、実はaltplus 浦谷さんが説明された移行後の挙動で説明することができます。
TiDB Xの狙い（１）: TiKVのスケールアウト・イン時間の短縮
altplus 浦谷さんの発表では、リリース後に想定外の負荷がありスケールアウトしたこと、そしてコスト削減のためにスケールインを実施したら想定以上に時間がかかってしまったことに触れられていました。資料ではスケールアウト・スケールイン時間の図示がありましたが、現在参照できる下記の記事にも状況の説明があります。
通常のTiDBアーキテクチャでは、TiKVをスケールアウトした際に、
- 新規ノード上にRaftのレプリカを作成します
- 既存ノード上の余剰のレプリカが削除されます
- 新規ノードがRaftリーダーになります（ここは別のスケジューラーで実施されますが、便宜上一連のものとして扱います）
という処理が行われます。ここに実はトレードオフがあり、
- この複製作業を早くすると、既存ノード・新規ノードの両方で大量のIOが発生する
- この複製作業を遅くすると、新規ノードの立ち上がりが遅くなり、追加分の性能が発揮できない
ということになります。この流量はPDのスケジューラーによって制御されており、PDの設定 *-schedule-limit で制御します（TiDB CloudではPDは公開されていないので、チケットで依頼します）
簡単に言えばまっさらな状態で新規TiKVノードを起動するので、既存ノードからデータをコピーする必要があるということです。これはデータ量が大きくなればその分時間がかかります。1TB近くのデータがあれば、時間単位でかかるのもザラです。
そのため、TiKVの性能を変えるには、インスタンスサイズを変えるスケールアップ・ダウンを推奨しています。ただ、この場合は1台1台新しいインスタンスに変更するので、差し替える際に一時的に性能が落ちてしまいます。一概にこちらの方法が良いとは言い切れません。
また、逆にスケールインの際は、Raftレプリカの数が減ることになるので、
- 残存TiKVノードに削除分のRaftレプリカを作成する
- レプリカが作成できたら、削除対象ノード上のRaftレプリカを削除する
- 全部のレプリカが削除できたら、削除対象ノードを削除する
という処理が必要になり、Raftレプリカの削除が完了するまでTiKVは削除できないということになります。こちらが、浦谷さんの説明でサービスのピークまでにスケールインが終わらないと言っていた理由になります。
TiDB Xでは、データのコピー元を広帯域なS3とすることで、既存TiKVノードへの負荷を気にすることなく、全力でデータをコピーすることができます。これにより高速なスケールアウトが可能になります。またスケールインの際は、S3との同期が取れれば、いつでもTiKVノードを削除できます。
TiDB Xは、スパイクワークロード（ウェビナーでは予測不可能なワークロード）により適したアーキテクチャを目指したといえるでしょう。
TiDB Xのねらい（２）: AIエージェントのデータベースとして
もう一つ避けられない話題が、AIエージェントからのデータベースアクセスです。
サイバーエージェント 西さんの発表は、全社的にDifyを採用して、RAGデータベースとしてTiDB Starterを採用したものでした。
DifyからTiDBを利用する際、ユーザーはデータベースを使っていることを意識してはいません。Difyの用語ではナレッジですが、すでに作成された知識ベースをAIが探してタスクを実行します。
エージェントを簡単に作れるのがDifyのメリットですが、それを全社で活用したらどれだけのエージェントがどれだけのクエリを発行するでしょうか？
TiDB Cloud Starterは当初Chat GPTを活用した、「LLMを使ってDBをより手軽に利用できる機能」を実装していました。自然言語からSQLを生成したChat2Queryや、LLMからFunction Callingを容易にするようにSQLをREST APIとして提供する Data Service などです。
LLMの利用がエージェントに変わるにつれ、AI対応機能もエージェントから利用することが前提になってきています。Vectorインデックスは代表例ですが、全文検索もRAGのハイブリッドサーチの文脈で実装されています。
TiDBが元々持つスケーラビリティやHTAPの機能を強化しつつ、AIエージェントにワンストップで対応できるデータベースにしようというコンセプトです。
個人的にはこちらの文脈でTiDB Xのラインナップを見るのが良いのかもと思っています。AIエージェントが基幹業務で利用されるようになると、そのツールも当然基幹業務の非機能要件を満たす必要がでてきます。TiDB Cloud Essential/Premiumのラインナップにより、この文脈でのRAGと基幹業務の両方をサポートできることになります。
おわりに
TiDB XはPingCAPの年次イベントで発表され、突然出てきた印象があったと思いますが、整理すると既存のTiDBアーキテクチャのクラウド適合進化と、AIのトレンドを踏まえたものであることがわかります。
PingCAPが提供するオンラインコースでも機能を学ぶことができますので、是非試してみてください！