TiDB CloudでTiDB Node Groupsの一般提供とTiKVのストレージタイプが変更になりました！
2025.04.04ゲームソリューション部の えがわ です。
TiDB Cloudの2025年4月1日のリリースで、2つの重要な機能が追加されました。
TiDB Node Groupが一般提供（GA）となり、TiKVのストレージタイプとしてStandard Storageが導入されました。
これらの機能について詳しく見ていきましょう。
TiDB Node Groupの一般提供開始
TiDB Node Group機能がTiDB Cloud Dedicatedで一般提供（GA）となりました。
この機能は単一クラスター内で細かなコンピューティングリソース分離を実現し、マルチテナントやマルチワークロードのシナリオにおけるパフォーマンスとリソース割り当てを最適化します。
TiDB Node Groupとは
TiDB Node Groupは、TiDBクラスター内でコンピューティングリソース（TiDBノード）をグループ化する機能です。
各ノードグループはそれぞれ独立したTiDBノードの集合として機能し、特定のワークロードやアプリケーション用に最適化されたリソース構成を持つことができます。
TiDBには「Resource Control」というリソース分離機能があります。
これらの機能を比較すると、以下のような違いがあります：
| 項目 | Resource Control | Node Group |
|---|---|---|
| パフォーマンス分離 | 優先度と割り当てベースの分離 | ワークロード間の完全なパフォーマンス分離 |
| 接続方法 | 単一エンドポイント | ノードグループごとに独立したエンドポイント |
Node Groupの技術的な仕組み
Node Groupは、TiDBクラスターのアーキテクチャ内で以下のように機能します：
-
共有ストレージレイヤー - すべてのノードグループは同じTiKVストレージクラスターを共有します。
-
分離されたコンピューティングレイヤー - 各ノードグループには専用のTiDBノード（SQLレイヤー）が割り当てられます。これにより、クエリ処理リソースが分離され、あるグループの高負荷が他のグループに影響を与えることを防ぎます。
-
統合管理 - すべてのノードグループは同じクラスター管理インターフェイスから操作でき、運用の簡素化とより効率的なモニタリングが可能です。
具体的なユースケース
ケース1: マイクロサービス毎にNode Groupを作成
課題:
- 一つのクラスター内での特定サービスの高負荷が他サービスに影響
- サービス毎に異なるリソース要件への対応が困難
- 性能調整やメンテナンスが全体に影響
解決策:
- Webアプリケーション用ノードグループ: 高トラフィックのクエリ処理に最適化
- ユーザー管理用ノードグループ: 安定した認証処理のための専用リソース確保
結果/メリット:
- 単一クラスターの管理性を維持しながらサービス間の性能分離を実現
- サービス毎のスケーリングが可能になり運用効率が向上
ケース2: OLTPとOLAP（分析）ワークロードの分離
課題:
- 分析クエリ（OLAP）が重いため、トランザクション処理（OLTP）のパフォーマンスに影響
- リソース競合によりビジネスクリティカルな処理が遅延するリスク
- 分析と運用を別システムに分離すると管理コストとデータ同期の問題が発生
解決策:
- OLTP用ノードグループ: 高スループットの短いトランザクションを処理するための最適化
- OLAP用ノードグループ: メモリ容量を増強し、複雑な分析クエリを効率的に処理
結果/メリット:
- 分析クエリ実行中もアプリ処理が安定したパフォーマンスを維持
- システム全体の複雑性を低減しながら両方のワークロードに最適な環境を提供
ケース3: マルチテナント環境
課題:
- あるテナントの高負荷が他のテナントのパフォーマンスに影響
- テナント間のパフォーマンス保証（SLA）の維持が困難
- 個別クラスターでテナントを分離すると管理コストが増大
解決策:
- プレミアムテナント用ノードグループ: 専用のノードを割り当て
- 標準テナント用ノードグループ: 共有リソースプールで効率的に運用
結果/メリット:
- テナントごとに明確なSLAを設定・維持することが可能
- 重要顧客に一貫したパフォーマンスを提供しながら、全体のコスト効率を確保
- テナント数の増加にも柔軟にスケール可能な基盤を実現
- 単一クラスターでの運用により管理オーバーヘッドとコストを削減
ケース4: 開発/テスト/QA環境の統合
課題:
- 環境ごとに個別のクラスターを維持するコストとオーバーヘッドが大きい
- 環境間の構成差異によるバグや問題の発生リスク
結果/メリット:
- 開発からテスト、QA環境が同一データモデルと一貫したインフラでテスト可能
- 環境ごとにリソース配分を最適化しコスト効率を向上
- リソース使用率の向上による全体的なインフラコスト削減
使用方法
クラスター変更画面で簡単にGroupを追加可能です。
※Node Groupを使用するには、TiDBノードが8vCPU以上必要です。
※5つまでGroupを作成できます。
各Node Group毎に接続を設定可能です。
Standard Storageタイプ
AWS上のTiDB Cloud DedicatedクラスターでTiKVノード用のStandard Storageタイプが導入されました。
このストレージタイプは、パフォーマンスとコスト効率のバランスを取りながら、ほとんどのワークロードに適しています。
主な利点
パフォーマンスの向上
- Raftログとデータストレージ間のI/O競合を減少させるために、ディスクリソースを十分に確保します
- これによりTiKVの読み書きパフォーマンスが向上します
安定性の向上
- 重要なRaft操作をデータワークロードから分離することで、より予測可能なパフォーマンスを実現します
コスト効率
- 以前のストレージタイプに比べて、競争力のある価格でより高いパフォーマンスを提供します
Basic StorageとStandard Storageの比較
| 項目 | Basic Storage | Standard Storage |
|---|---|---|
| I/O競合 | 発生しやすい | 大幅に軽減 |
| 料金 | 通常料金 | 少し高い |
Standard Storageのパフォーマンス向上の仕組み
TiKVでは2種類の重要なディスク操作が行われています：
-
Raftログの書き込み - Raftとは分散システムでデータの一貫性を保つための合意（コンセンサス）アルゴリズムです。簡単に言えば、複数のサーバー間でデータが確実に同期されるようにする仕組みで、その動作記録がRaftログです。このログ記録は耐久性とデータ一貫性に必須です。
-
データの読み書き - 実際のユーザーデータの保存と取得のための操作です。
従来のBasic Storageでは、これら2つの操作が同じディスクリソースを共有していたため、I/O（入出力）の競合が発生していました。特に書き込みが多いワークロードでは、Raftログの書き込みとデータの書き込みが互いに干渉し、パフォーマンスのボトルネックとなっていました。
Standard Storageでは、Raftログ用に専用のディスクリソースを確保することで、この問題を解決しています：
- リソース分離 - Raftログとデータストレージが別々のリソースを使用するため、互いに干渉しません
- I/O競合の軽減 - 両方の操作が独立して最適なパフォーマンスを発揮できます
- 書き込み応答時間の短縮 - Raftログの書き込みが高速化され、全体の応答時間が改善します
これは自動車の交通システムに例えると、一般車両と緊急車両のために別々の専用レーンを設けるようなものです。緊急車両（Raftログ）は常に迅速に移動でき、一般車両（データ操作）も渋滞の影響を受けにくくなります。
大型トラックがRaftログのイメージ
適応されるクラスター
Standard Storageタイプは、2025年4月1日以降にAWS上で作成された対応バージョン（バージョン >= 7.5.5、8.1.2、または8.5.0）のTiDB Cloud Dedicatedクラスターに自動的に適用されます。
既存のクラスターは引き続き以前のBasic Storageタイプを使用します。
Standard StorageとBasic Storageは価格が異なります。詳細については価格をご確認ください。
2025/04/04現在はStandard Storageのみ選択可能になっています。
さいごに
TiDB CloudのNode GroupとStandard Storageの導入により、より柔軟かつ効率的なデータベース運用が可能になりました。
特にマルチテナント環境や高いパフォーマンスが求められるワークロードにとって、これらの機能は大きなメリットがあります。
皆さんもTiDB Cloudの新機能を試してみてはいかがでしょうか。
この記事がどなたかの参考になれば幸いです。
