TiDBオートスケーリング：クラウドネイティブアプリケーション用の分散SQLを使用する理由

※このブログは2023年6月20日に公開された英語ブログ「TiDB Auto Scaling: Why Distributed SQL for Cloud-Native Applications」の拙訳です。

さまざまなワークロードに応じて迅速かつ効率的にスケーリングする機能は、あらゆるデータベースシステムにとって極めて重要な機能です。オートスケーリングはデータベースが計算リソースを自動的に調整できるようにする機能です。利点として、突発的なワークロード急増時のパフォーマンスの向上や、需要が少ない期間中の費用対効果が含まれます。

PingCAPによって開発されたTiDBは、水平方向のスケーラビリティ、強力な一貫性、および高可用性を提供する、高度なオープンソースの分散SQLデータベースです。そのクラウドネイティブアーキテクチャは、クラウドプラットフォームに関係なく、効率的でシームレスなオートスケーリングのためにコンピューティングをストレージから分離します。

このブログでは、Amazon Web Services (AWS) での実際のセットアップを通じて実証された、TiDBのオートスケーリング機能のアーキテクチャと運用の詳細について説明します。

オートスケーリングアーキテクチャの調査

TiDBはさまざまなクラウドプラットフォームでの自動的な水平スケーリングを備えたクラウドネイティブアーキテクチャを採用しています。このデモでは、Auto Scaling groups、CloudWatch、EventBridge、Lambda、Simple Queue Service、Network Load Balancerなど、さまざまなAWSサービスを使用してTiDBのオートスケーリングソリューションを構築しました。

図1. オートスケーリングアーキテクチャ

デモの主なコンポーネントは次のとおりです。

• Auto Scaling groups：各TiDBコンポーネントは、独自のEC2 Auto Scaling groups内にカプセル化されます。これによりEC2インスタンスタイプやEBSファミリーなどのコンポーネントごとに独立した構成調整が可能になります。
• リソースのモニタリングと管理：AWS CloudWatchは、EC2 Auto Scaling groupsがEC2インスタンスのスケーリングポリシーを実行している間、リソースの使用状況をリアルタイムでモニタリングします。この組み合わせにより、自動的かつ応答性の高いスケーリング調整が保証されます。
• カスタムイベントリスナー：TiDBのコンポーネント管理ユーティリティであるTiUPを通じて、TiDBクラスター内のさまざまなコンポーネントの自動管理とスケーリングを容易にするカスタムイベントリスナープログラム。
• フロントエンドネットワークロードバランサー：クライアントとのやりとりを強化するために、ネットワークロードバランサーは、クライアントに対するSQLレイヤーのスケーリング操作の影響を軽減します。これにより、TiKVサーバーの水平スケーリング操作がクライアントから分離され、オートスケーリングプロセス中にクライアントアプリケーションの機能が中断されないようになります。

動作中のTiDBオートスケーリング

アーキテクチャの概要を説明したので、TiDBのオートスケーリング機能のリアルタイムデモを見ていきましょう。

初期クラスタの構築とデモ設計

デモンストレーションは3つのTiKVノード (ストレージレイヤー) と2つのTiDBノード (ステートレスSQLレイヤー) で構成されるクラスターから始めます。

次に、TiDBクラスタにデータを継続的に挿入するクライアントプログラムを開始します。同時にTiDBに挿入されたデータのクエリ専用のターミナルウィンドウを保持しておくことで、システムの動作をリアルタイムで観察できます。

図2. 初期クラスタ構築

TiDB Auto Scaling groupでオートスケーリングをトリガーするために、簡単なメトリックである平均CPU使用率を採用しています。平均CPU使用率を約30%に維持することを目指しています。このしきい値を一定期間超えると、スケールアウトプロセスがトリガーされ、EC2インスタンスの追加が開始されます。逆にこのしきい値を下回ると、それに応じてEC2インスタンスの数が減少します。これはスケールインと呼ばれます。

注：オートスケーリングのトリガーとしてCPU使用率を使用しますが、実際の環境で収集および集計できる任意の適切なメトリクスを使用できます。

クライアントアプリケーションの安定性を確保するために、スケールアウトには積極的な戦略を採用し、スケールインには保守的な戦略を採用しています。

SQLレイヤーのオートスケーリング

まずEC2コンソールで、SQLレイヤー内の既存のTiDBサーバーのCPUを占有するスクリプトを実行して、オートスケーリングイベントをトリガーします。

ec2-user@ip-10-90-4-224 scripts]$ ./sd-002-csp-demo-hog-db.sh
tiup is checking updates for component cluster
Starting component
'cluster' : /home/ec2-user/.tip/components/cluster/v1.12.1/tiup-cluster display tidb-demo
hog 10.90.1.70
hog 10.90.2.73

オートスケーリングプロセスは、CPU使用率が30%を超えると開始され、指定された期間持続します。この間イベントリスナープログラムはイベントをキャプチャし、TiUPユーティリティを使用して新しいEC2インスタンスを準備し、その後TiDBクラスタのSQLレイヤーに追加します。

オートスケーリングプロセスが実行されている間、リアルタイムで変化を観察できます。Auto Scaling groupsは、既存のノードのCPU負荷を軽減するために新しいEC2インスタンスを追加します。その結果TiDBサーバーの数が2台から4台に増加し、SQLレイヤーが効果的にスケールアウトされます。

図3. TiDBのオートスケールアウト

TiDBのオートスケーラビリティは、クライアントアプリケーションの中断を回避するようにインテリジェントに設計されていることに注意することが重要です。ネットワークロードバランサーは、SQLレイヤーとクライアント操作の間の干渉を軽減し、シームレスな体験を確保する上で重要な役割を果たします。

ロードバランサーの観点からは、新しく追加されたTiDBサーバーがヘルスチェックに合格するまでに時間がかかる場合があります。ただし、すべてのサーバーが起動して実行されると、クラスタにシームレスに統合され、キャパシティとパフォーマンスが向上します。

図4. TiDBオートスケールのステータス

TiDBのオートスケールインとTiKVのスケールアウト

それではTiKVレイヤーに焦点を移しましょう。SQLレイヤーとTiKVレイヤーの水平方向のスケーラビリティは互いに分離されていることを理解することが重要です。この分離された設計により、特定の要件に基づいて独立したスケーラビリティが可能になります。

TiKVレイヤーの独立したスケーラビリティを実証するために、TiKVのCPU使用率を占有する前に、TiDBサーバーのCPUプレッシャーを解放します。ただし、最初に設定した保守的なスケールイン戦略のため、スケールインが発生するまでに数分かかります。

[root@ip-10-90-1-70 ~]# kill -9 29629
[root@ip-10-90-1-70 ~]# kill -9 29561
[ec2-user@ip-10-90-4-224 scripts]$ ./sd-002-csp-demo-hog-kv.sh
tiup is checking updates for component cluster ...
Starting component 'cluster': /home/ec2-user/.tiup/components/cluster/v1.12.1/tiup-cluster display tidb-demo hog 10.90.1.146
hog 10.90.2.51
hog 10.90.3.222

TiKVレイヤーのオートスケーリング戦略も30%のしきい値に設定されているため、変更を組み合わせると、SQLレイヤーのオートスケールインとTiKVレイヤーのスケールアウトが行われます。

このプロセス中にイベントリスナープログラムはSQLレイヤーのオートスケールインイベントを検出し、クラスタからTiDBサーバーを削除します。TiKVレイヤーは、増大するワークロード需要を満たすためにノードを追加することでスケールアウトします。ご覧のとおり、TiKVノードの数は5つに増えました。

図5. TiKVのスケールアウト

このデモを通じて、実際のビジネス運営を表すサンプルワークロードは目立った影響を与えることなくスムーズに実行され続けました。TiDBのオートスケーリング機能により、システムの安定性と効率性を維持しながら最適なリソース利用が保証されます。

TiKVのオートスケールイン

SQLレイヤーのスケールインと同様に、まずTiKVでのCPUの消費を停止します。保守的なアプローチに従い、安定性を確保するために冷却期間を設けます。イベントリスナープログラムは、CPU使用率の低下を検知し、過剰なリソースの削除をトリガーします。最終的に、TiKVノードは5から3にスケールインします。

図6 TiKVのオートスケールイン

オートスケーリングのデモのまとめ

コンポーネント	初期ノード数	スケールアウト	スケールイン
SQLレイヤー (TiDB)	2	4	2
ストレージレイヤー (TiKV)	3	5	3

需要が高い期間中、SQLレイヤー (TiDB) は2ノードから4ノードにシームレスに拡張され、ワークロードの増加に対応しました。需要の要求が収まるとシステムは自動的に元の構成にスケールバックし、効率と費用対効果を維持します。同様に、ストレージレイヤー (TiKV) で過負荷が発生した場合、ノード数が3から5に増加し、その後ワークロードが正常化するにつれて3に減りました。

このデモ全体を通じて、実行中のワークロードに悪影響はありませんでした。これはビジネス運営を中断することなく動的スケーリングを処理できるTiDBの能力を示しています。

まとめ

TiDBのオートスケーリングソリューションを使用して、システムがどのようにワークロードの変動にインテリジェントに適応し、最適なパフォーマンスとリソース使用率を確保するかを見てきました。

MySQLなどの従来のデータベースと比較して、TiDBのオートスケーリング機能はスケーリングプロセスを合理化します。また、手動による構成変更や複雑なシャーディング技術も不要になります。同様に、Amazon Auroraのようなマネージドデータベースサービスはオートスケーリング機能を提供しますが、TiDBの分離されたスケーリングはそれとは一線を画し、SQLレイヤーとストレージレイヤーをきめ細かく制御できます。

このデモを再現したいですか?関連するすべてのスクリプト、AWS Cloud Formationテンプレート、およびステップバイステップガイドはGitHubで見つけることができます。

オートスケーリングやこの投稿で説明した概念についてさらに詳しく知りたい場合は、無料のオンデマンドコース「TiDB公式オンライントレーニング」にサインアップしてください。