Hologres:自動スロットリング (ベータ版)

シナリオ

自動調整による速度制限の原則は、負荷状況に基づいてクエリキューの最大同時実行数を動的に調整することです。仮想ウェアハウスで同時に実行されるクエリの数を制御することにより、計算リソースが過負荷になるのを防ぎます。この機能は、以下のシナリオに適しています。

• 高同時実行シナリオ: 同時実行性が高く、各リクエストのオーバーヘッドが比較的均一な場合、自動調整による速度制限機能は同時実行制限を動的に調整します。 CPU 曲線は最終的に 100% 使用率に達することなく、高レベルで安定します。

  説明

  • 同時実行性が低すぎる場合、自動調整による速度制限機能が同時実行制限を動的に調整すると、CPU 曲線が上下に変動しやすく、「のこぎり歯」パターンが作成され、CPU 使用率が低下します。

  • さらに極端なケースでは、単一の大規模クエリリクエストしかない場合、自動調整による速度制限機能は有効になりません。

• リクエストの遅延が許容されるシナリオ: この機能はトラフィックを制限するため、制限を超えるクエリはクエリキューにキューイングされ、それに応じてこれらのリクエストの待機時間が増加します。

• 予測不可能な高同時実行期間: トラフィックリクエストが急増する時期を予測することが難しく、事前に計算リソースを予約することが難しい場合は、自動調整による速度制限機能を使用してシステムの安定性リスクを軽減できます。

以下のシナリオでは、他のソリューションをお勧めします。

• 明らかな定期的な時間パターン: 毎日のトラフィックのピーク期間が比較的固定されている場合は、仮想ウェアハウスの時間指定スケーリング機能を使用してスケジュールされたスケーリングを行うことをお勧めします。

• 同時実行性が低い大規模クエリ: 自動調整による速度制限機能は、同時実行性が低い大規模クエリには限定的な効果しかありません。これらのリクエストを実行するには、サーバーレス コンピューティング リソースを使用することをお勧めします。詳細については、「サーバーレス コンピューティングのユーザーガイド」をご参照ください。

• リクエスト遅延のゼロトレランス: 高同時実行性と低待機時間の両方の要件に対応するには、計算リソースを増やす必要があります。計算リソースを スケールアウト するか、クエリキューの大規模クエリ制御機能を使用して、実行に時間のかかるリクエストをサーバーレス リソースに転送して実行できます。詳細については、「大規模クエリ制御」をご参照ください。

前提条件

クエリキューを作成済み であること。

使用上の注意

• Hologres V3.1 以降の 仮想ウェアハウス インスタンスのみが自動調整による速度制限をサポートしています。汎用インスタンスはこの機能をサポートしていません。

  説明

  最初に汎用インスタンスを仮想ウェアハウス インスタンスに変換してから、この機能を使用できます。詳細については、「インスタンスのインスタンスタイプを汎用から仮想ウェアハウスに変更する」をご参照ください。

• 自動スロットリングは、クエリキュー内のリクエストにのみ適用されます。これには、engine_type が HQE、PQE、SQE、HiveQE などであるクエリ、および SELECT、INSERT、UPDATE、DELETE、ならびに COPY と CREATE TABLE AS (CTAS) を伴う INSERT などのクエリタイプが含まれます。

• 固定プランに基づくクエリはクエリキューに入らないため、自動調整による速度制限機能の同時実行制限の対象にはなりません。詳細については、「固定プランを使用して SQL 文の実行を高速化する」をご参照ください。リソースとリクエストをより適切に管理するために、異なる仮想ウェアハウスを使用して固定プラン リクエストを他のリクエストから分離することをお勧めします。詳細については、「仮想ウェアハウスの概要」をご参照ください。

自動調整による速度制限を使用する

このセクションでは、仮想ウェアハウスとクエリキューの自動調整による速度制限を構成する方法について説明します。

監視と運用保守

Hologres コンソールでターゲット インスタンス ID をクリックし、[監視情報] ページで インスタンス CPU 使用率 (%) メトリックを表示して、自動調整による速度制限機能の使用状況を監視できます。

例

このセクションでは、PostgreSQL のネイティブ パフォーマンス テスト ツール pgbench を使用して、例と自動調整による速度制限の効果を示します。

1. Hologres にテスト テーブルを作成し、データを挿入します。

   CREATE TABLE tbl_1 (col1 INT, col2 INT, col3 TEXT);
   CREATE TABLE tbl_2 (col1 INT, col2 INT, col3 TEXT);
   INSERT INTO tbl_1 SELECT i, i+1, md5(RANDOM()::TEXT) FROM GENERATE_SERIES (0, 500000) AS i;
   INSERT INTO tbl_2 SELECT i, i+1, md5(RANDOM()::TEXT) FROM GENERATE_SERIES (0, 500000) AS i;

2. 仮想ウェアハウス init_warehouse とクエリキュー default_queue を例として使用して、Hologres でクエリキューの最大同時実行数を 100 に設定します。

   CALL hg_set_query_queue_property ('init_warehouse', 'default_queue', 'max_concurrency', '100');

3. クライアントの pgbench がある bin ディレクトリに、パフォーマンステスト用の SQL ファイル select.sql を作成し、次の SQL 文を記述します：

   EXPLAIN ANALYZE SELECT * FROM tbl_1 LEFT JOIN tbl_2 ON tbl_1.col3 = tbl_2.col3 ORDER BY 1;

4. サーバーの構成ファイルに次のコマンドを追加して保存します。パスワードを環境変数として設定します。

   export PGPASSWORD='<AccessKey_Secret>'

5. クライアントの pgbench がある bin ディレクトリに移動し、次のパフォーマンステスト コマンドを実行します。

   ./pgbench
   -c 30 \
   -j 30 \
   -f select.sql \
   -d <Database> \
   -U <AccessKey_ID> \
   -h <Endpoint> \
   -p <Port> \
   -T 1800

   パラメーター構成の詳細については、「Hologres インスタンスに接続してデータ開発を行う」をご参照ください。

6. パフォーマンステスト中に、Hologres で自動調整による速度制限機能を順番に有効化および無効化し、テストが完了するまで仮想ウェアハウスの CPU 使用率メトリックを観察します。

   -- 自動調整による速度制限を有効にします。
   CALL hg_set_warehouse_adaptive_concurrency_limiting ('init_warehouse', true);
   
   -- 自動調整による速度制限を無効にします。
   CALL hg_set_warehouse_adaptive_concurrency_limiting ('init_warehouse', false);