TiDB Cloud Dedicatedのスケールアップ、スケールアウトをやってみた
ゲームソリューション部の えがわ です。
本記事は「ゲーソル・ギョーソル Advent Calendar 2024」の17日目のエントリとして、TiDB Cloud Dedicatedのスケールアップ、スケールアウトについて確認してみます。
環境
- TiDB Cloud Dedicated: 8.1.1
- Kong Insomnia(リクエスト定期実行用)
やってみる
スケールアップやスケールアウト時の挙動も確認するため、常にサンプルアプリケーションからリクエストを実行しておきます。
サンプルアプリケーション(TODOアプリ)をローカル環境で起動し、データベースをTiDB Cloud Dedicatedにしています。
APIクライアントツールとしてKong Insomniaを使用して、一定間隔でリクエストを行います。
※TODOを格納するテーブルのIDにはオートインクリメントが設定されています。
スケールの変更方法
変更方法は「・・・」を押下しModifyを選択します。
変更はGUIで変更することが可能です。
スケールアップ+アウト
各コンポーネントのスペックと数を変更します。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| TiDB | 4vCPU 16GiB x 1 | 8vCPU 16GiB x 2 |
| TiKV | 4vCPU 16GiB x 3 | 8vCPU 32GiB x 3 |
変更途中ですが、一定間隔でリクエストしてみます。
左がTiDBのコンソール画面、中央右側がAPIクライアントツールの画面です。
問題なくリクエストが行えており、IDが単調増加しているのがわかります。
さらに、TiDBノードが1台完了した状態で一定間隔でリクエストしてみます。
IDが30,000台になっています。
これはオートインクリメントの範囲をTiDBノードがキャッシュしているためです。
TiDBノードのスケールアウトに伴い0~30,000までの範囲が失われ、30,001~採番が始まっています。
TiDBのオートインクリメントに関しては以下をご確認ください。
TiDBノードの変更が完了した状態でも一定間隔でリクエストしてみます。
IDが30,000台、60,000台となっています。
これも上記と同様にTiDBノード毎にID範囲をキャッシュしているためです。
スケーリング時間
先ほど行ったスケールアップ+アウトの時間を計測してみます。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| TiDB | 4vCPU 16GiB x 1 | 8vCPU 16GiB x 2 |
| TiKV | 4vCPU 16GiB x 3 | 8vCPU 32GiB x 3 |
17分ほどかかりました。
参考としてさらにスケールアウトしてみます。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| TiDB | 8vCPU 16GiB x 2 | 8vCPU 16GiB x 3 |
| TiKV | 8vCPU 32GiB x 3 | 8vCPU 32GiB x 6 |
3分ほどで完了しました。
追加するノード数にもよりますが、スケールアウトだけであれば短時間で完了することが可能です。
さいごに
TiDB Dedicatedのスケールアップ、スケールアウトについて確認してみました。
各ノードのスペックを変更しても、ダウンタイムが発生しないため気軽に変更を行えます。
この記事がどなたかの参考になれば幸いです。
