TiDB Cloudにおける新機能: TiDB Node Groupが使えるようになりました！
はじめに
TiDB Cloud(2025/1/9時点においては、TiDB Cloud Dedicatedクラスターのみ)において、TiDB Node Groupなる機能が追加された為、どのような機能なのかをざっくり説明いたします。
TiDB Node Group
TiDB Node Groupとは、TiDB Cloud Dedicatedクラスターにおいて有効化することができる機能で、TiDBノードだけを物理的に分離し(エンドポイントも別で生える)、それぞれ接続するアプリケーションごとでTiDBノードにおけるコンピューティングリソースを物理的に割り当てることができる機能になります。
ちなみに、既存の機能として(こちらはTiDB CloudだけではなくOSS版も利用可能)、Resource Controlと呼ばれる機能がありますが、こちらは、TiDBノードだけではなく、TiKVノード側も含めてのリソース制御を論理的に可能にするものになります。
設定の仕方についての詳細は、下記のドキュメントをご参照いただければと思いますが、TiDBならではの**リクエストユニット(RU)**という、CPU、IOPS、および IO 帯域幅のメトリックなどを抽象化した概念で計算されるもので、この割合を元にどのアプリケーション、どのユーザ、どの、セッションレベルでリクエストが来たものに対してリソース制御をするのかという機能となります。
TiDB Node Groupは何が美味しいの？
例えばアプリケーションAとアプリケーションBが存在していたとします。
TiDB Node Groupを使うことで、1つのTiDBクラスターに複数DBを論理的に統合した後にアプリケーションAとアプリケーションBそれぞれが1つのTiDBクラスターのエンドポイントに対して接続をかけたとすると、互いのアプリケーションによるリソース使用量が食い合いノイジーネイバーを起こす可能性は考えられると思います。
この際に、今回でたTiDB Node Groupを活用すれば、アプリケーションAからの接続は、TiDB Node GroupにおけるエンドポイントAに対してアクセスするように設定し、アプリケーションBからの接続はTiDB Node GroupにおけるエンドポイントBに対してアクセスするように設定することで、物理的にリソースの分離を行えるので、ノイジーネイバー問題が簡単にTiDBノードの世界では無くなることになります。
※ただし、TiKVノードにおいてはリソースの使用については分離されないので、注意は必要です。
もしTiKVノードまで考慮したいのあれば、Resource Controlと併用で活用することをお勧めします。
ユースケース
なので、想定されるユースケースをいつくか挙げてみます。
-
たとえば、とあるワークロードにおいてトランザクションによる実行時間が長く、他から接続されているアプリケーションの応答時間に影響が出ているような課題があったとします。
このTiDB Node Groupを活用すれば、影響を与えているトランザクションからの接続は、専用に割り当てたTiDBノードで捌かせて、他サービスからの接続についてはこれまでのTiDBノードで処理されるなどができることになります。 -
それ以外だと、たとえばアプリケーションからの流れるトランザクションがあった状態で、DB運用者がサービスの都合上、どうしてもDDLの更新、たとえば時間のかかるインデックスの追加など(TiDBではDDLはオンラインが実行可能です。これはDML流れている状態でもDDLを実行できることを意味します。)
を実行しようとしたした際に、本番ワークロードのパフォーマンスに影響を与えてしまうことを危惧するのではないでしょうか。この際に、TiDB Node Groupを活用すれば、DDL実行タスク用のTiDBノードを用意することが可能となります。
しかもTiDBノードをエンドポイントで分けているだけなので、たとえば、アプリケーションAとアプリケーションBがあった際に、アプリケーションAでは高パフォーマンスを求められるためTiDBノードが4台必要だが、アプリケーションBではまだそこまでユーザ数がおらずそこまでパフォーマンスがいらない為、TiDBノードを2台で運用したいなど、サービスごとにTiDBノードの数を調整しながら運用することができるのも嬉しいポイントですね！
実際に使ってみたい方は、ぜひ下記のドキュメントをご参照ください！
ではまた！
参考資料
Discussion