WLM クエリモニタリングルール - Amazon Redshift

WLM クエリモニタリングルール

Amazon Redshift ワークロード管理では、クエリモニタリングルールは、WLM キューのメトリクスベースのパフォーマンスの境界を定義し、クエリがこれらの境界を超えた場合のアクションを指定します。例えば、実行時間の短いクエリ専用のキューには、60 秒以上実行されるクエリをキャンセルするルールを作成できます。デザインの不十分なクエリを追跡する目的で、ネステッドループを含むクエリを記録する別のルールを設定することができます。

ワークロード管理 (WLM) 構成の一部としてクエリモニタリングルールを定義します。1 つのキューに対して最大 25 個のルールを定義できます。ルールの総数はキュー全体で最大 25 個に制限されています。各ルールには最大 3 つの条件または述語と 1 つのアクションが含まれます。述語は、メトリクス、比較条件 (=, <, or > )、および値で構成されています。いずれかのルールのすべての述語が満たされると、ルールのアクションがトリガーされます。ルールアクションは、前述のようにログ、ホップ、中止を指定できます。

指定のキューのルールは、そのキューで実行中のクエリにのみ適用されます。ルールは他のルールに依存しません。

WLM は 10 秒ごとにメトリクスを評価します。同じ期間に複数のルールがトリガーされると、WLM は最も重大なアクション (中止、ホップ、ログ) を開始します。アクションがホップまたは中止の場合、アクションは記録され、クエリはキューから削除されます。アクションがログ場合、キューはキューで実行されます。WLM はルールごとにクエリあたり 1 つのログアクションを開始します。キューに他のルールが含まれている場合、これらのルールは引き続き有効です。アクションがホップで、クエリが別のキューにルーティングされる場合、新しいキューのルールが適用されます。特定のクエリに対して実行されるクエリのモニタリングと追跡アクションの詳細については、ショートクエリアクセラレーションを使用する にあるサンプルコレクションを参照してください。

ルールの述語がすべて満たされると、WLM は STL_WLM_RULE_ACTION システムテーブルに行を書き込みます。さらに、Amazon Redshift は、現在実行されているクエリのクエリメトリクスを STV_QUERY_METRICS に記録します。完了したクエリのメトリクスは STL_QUERY_METRICS に保存されます。

クエリモニタリングルールの定義

WLM 構成の一部としてクエリモニタリングルールを作成します。このルールは、クラスターのパラメータグループ定義の一部として定義します。

ルールは AWS Management Consoleを使用して作成するか、JSON でプログラム的に作成できます。

注記

プログラム的にルールを作成することを選択した場合は、コンソールを使用して、パラメータグループ定義に含める JSON を生成することを強くおすすめします。詳細については、Amazon Redshift 管理ガイドの「コンソールを使用してクエリモニタリングルールを作成または変更する」および「AWS CLI によるパラメータ値を設定する」を参照してください。

クエリモニタリングルールを定義するには、次の要素を指定します。

  • ルール名 – ルール名は WLM 設定内で一意である必要があります。ルール名には最大で 32 文字の英数字または下線を使用できます。スペースまたは疑問符を含めることはできません。キューごとの 25 個までルールを指定できます。すべてのキューでのルールは合計 25 個までです。

  • 1 つ以上の述語 – ルールごとに最大 3 つのルールを定義できます。いずれかのルールのすべての述語が満たされると、関連付けられたアクションがトリガーされます。述語はメトリクス名、演算子 (=、<、または >)、および値で定義されます。例: 「query_cpu_time > 100000」。メトリクスのリストと各メトリクスの値については、このセクションの Amazon Redshift のクエリモニタリングメトリクスのプロビジョニング を参照してください。

  • アクション – 複数のルールがトリガーされると、WLM は最も重大なアクションのルールを選択します。想定されるアクションの重大度は昇順で次のようになります。

    • ログ – STL_WLM_RULE_ACTION システムテーブルにクエリに関する情報を記録します。ログレコードを書き込むだけの場合はログアクションを使用します。WLM は最大でクエリごと、ルールごとにログを 1 つ作成します。ログアクションの後、他のルールは有効な状態を維持し、WLM はひき続きクエリをモニタリングします。

    • ホップ (手動 WLM でのみ利用可能) – アクションを記録して、次に一致するキューにクエリをホップします。一致するキューがない場合、クエリはキャンセルされます。QMR は、CREATE TABLE AS (CTAS) ステートメントと読み取り専用クエリ (SELECT ステートメントなど) のみホップします。詳細については、「WLM クエリキューのホッピング」を参照してください。

    • 中断 – アクションをログに記録してクエリをキャンセルします。QMR は、COPY ステートメント、および ANALYZE や VACUUM などのメンテナンスオペレーションを停止しません。

    • 優先度の変更 (自動 WLM でのみ使用可能) – クエリの優先度を変更します。

クエリのランタイムを制限するには、WLM タイムアウトを使用する代わりにクエリモニタリングルールを作成することをお勧めします。例えば、次の JSON スニペットに示すように、max_execution_time を 50,000 ミリ秒に設定できます。

"max_execution_time": 50000

ただし、次の JSON スニペットに示すように、query_execution_time を 50 秒に設定する同等のクエリモニタリングルールを定義します。

"rules": [ { "rule_name": "rule_query_execution", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 50 } ], "action": "abort" } ]

クエリモニタリングルールを作成または変更するステップについては、Amazon Redshift 管理ガイドの「コンソールを使用してクエリモニタリングルールを作成または変更する」および「wlm_json_configuration パラメータのプロパティ」を参照してください。

クエリモニタリングルールの詳細は次のトピックで確認できます。

Amazon Redshift のクエリモニタリングメトリクスのプロビジョニング

次のテーブルに、クエリモニタリングルールで使用されるメトリクスを説明します (これらのメトリクスは、STV_QUERY_METRICS および STL_QUERY_METRICS システムのテーブルに保存されるメトリクスとは異なります)。

指定のメトリクスについて、パフォーマンスしきい値はクエリレベルまたはセグメントレベルのいずれかで追跡されます。セグメントとステップの詳細については、「クエリプランと実行ワークフロー」を参照してください。

注記

WLM タイムアウト パラメータは、クエリモニタリングルールとは異なります。

メトリクス 名前 説明
CPU 時間のクエリ query_cpu_time クエリに使用される CPU 時間 (秒)。CPU timeQuery execution time とは異なります。

有効な値は 0~999,999 です。

ブロック読み取り query_blocks_read クエリによって読み取られた 1 MB データブロックの数。

有効な値は 0~1,048,575 です。

行数のスキャン scan_row_count

スキャンステップの行数。行数は、削除対象としてマークされた行 (非実体の行) をフィルタリングする前およびユーザー定義のクエリフィルタが適用される前に出力された合計行数を表します。

有効な値は 0~999,999,999,999,999 です。

クエリ実行時間 query_execution_time 経過したクエリ実行時間 (秒)。キューでの待機時間は実行時間に含まれません。

有効な値は 0~86,399 です。

クエリキュー時間 query_queue_time キューでの待機に費やされた時間(秒単位)。

有効な値は 0~86,399 です。

CPU の使用 query_cpu_usage_percent クエリが使用する CPU 容量の割合。

有効な値は 0~6,399 です。

ディスクへのメモリ query_temp_blocks_to_disk 中間結果の書き込みに使用される一時ディスク容量 (1 MB ブロック)。

有効な値は 0~319,815,679 です。

CPU スキュー cpu_skew 任意のスライスの最大 CPU 使用量とすべてのスライスの平均 CPU 使用量の比率。このメトリクスはセグメントレベルで定義されます。

有効な値は 0~99 です。

I/O スキュー io_skew 任意のスライスの最大ブロック読み取り (I/O) とすべてのスライスの平均ブロック読み取りの比率。このメトリクスはセグメントレベルで定義されます。

有効な値は 0~99 です。

結合した行 join_row_count 結合ステップで処理された行数。

有効な値は 0~999,999,999,999,999 です。

ネストしたループ結合行数 nested_loop_join_row_count ネストしたループ結合行数の行数。

有効な値は 0~999,999,999,999,999 です。

返される行数 return_row_count クエリによって返された行の数。

有効な値は 0~999,999,999,999,999 です。

セグメント実行時間 segment_execution_time 単一セグメントで経過した実行時間 (秒)。サンプリングエラーを回避または減少するには、segment_execution_time > 10 をルールに含めます。

有効な値は 0~86,388 です。

Spectrum スキャン行数 spectrum_scan_row_count Amazon Redshift Spectrum クエリにスキャンされる Amazon S3 内のデータ行数。

有効な値は 0~999,999,999,999,999 です。

Spectrum スキャンサイズ spectrum_scan_size_mb Amazon Redshift Spectrum クエリにスキャンされる Amazon S3 内のデータサイズ (MB)。

有効な値は 0~999,999,999,999,999 です。

クエリ優先度 query_priority クエリの優先度です。

有効な値は、HIGHESTHIGHNORMALLOWLOWEST です。大なり (>) 演算子と小なり (<) 演算子を使用して query_priority を比較する場合、HIGHESTHIGH より大きく、HIGHNORMAL より大きい、などがあります。

注記
  • ホップアクションは、query_queue_time 述語ではサポートされていません。つまり、query_queue_time 述語が満たされたときにホップするように定義されたルールは無視されます。

  • 短いセグメントの実行時間は、一部のメトリクスで io_skewquery_cpu_usage_percent などのサンプリングエラーとなる場合があります。サンプリングエラーを回避または減少するには、セグメントの実行時間をルールに含めます。最良な開始ポイントは、segment_execution_time > 10 です。

SVL_QUERY_METRICS ビューは、完了したクエリのメトリクスを示します。SVL_QUERY_METRICS_SUMMARY ビューは、完了したクエリのメトリクスの最大値を示します。このビューの値は、クエリのモニタリングルールを定義するしきい値を決定する際に役立ちます。

Amazon Redshift Serverless のクエリモニタリングメトリクス

次のテーブルでは、Amazon Redshift Serverless のクエリモニタリングルールで使用されるメトリクスについて説明します。

メトリクス 名前 説明
CPU 時間のクエリ max_query_cpu_time クエリに使用される CPU 時間 (秒)。CPU timeQuery execution time とは異なります。

有効な値は 0~999,999 です。

ブロック読み取り max_query_blocks_read クエリによって読み取られた 1 MB データブロックの数。

有効な値は 0~1,048,575 です。

行数のスキャン max_scan_row_count

スキャンステップの行数。行数は、削除対象としてマークされた行 (非実体の行) をフィルタリングする前およびユーザー定義のクエリフィルタが適用される前に出力された合計行数を表します。

有効な値は 0~999,999,999,999,999 です。

クエリ実行時間 max_query_execution_time

経過したクエリ実行時間 (秒)。キューでの待機時間は実行時間に含まれません。クエリが設定された実行時間を超えると、Amazon Redshift Serverless はクエリを中止します。

有効な値は 0~86,399 です。

クエリキュー時間 max_query_queue_time キューでの待機に費やされた時間(秒単位)。

有効な値は 0~86,399 です。

CPU の使用 max_query_cpu_usage_percent クエリが使用する CPU 容量の割合。

有効な値は 0~6,399 です。

ディスクへのメモリ max_query_temp_blocks_to_disk 中間結果の書き込みに使用される一時ディスク容量 (1 MB ブロック)。

有効な値は 0~319,815,679 です。

結合した行 max_join_row_count 結合ステップで処理された行数。

有効な値は 0~999,999,999,999,999 です。

ネストしたループ結合行数 max_nested_loop_join_row_count ネストしたループ結合行数の行数。

有効な値は 0~999,999,999,999,999 です。

注記
  • ホップアクションは、max_query_queue_time 述語ではサポートされていません。つまり、max_query_queue_time 述語が満たされたときにホップするように定義されたルールは無視されます。

  • 短いセグメントの実行時間は、一部のメトリクスで max_io_skewmax_query_cpu_usage_percent などのサンプリングエラーとなる場合があります。

クエリモニタリングルールテンプレート

Amazon Redshift コンソールを使用してルールを追加すると、事前定義されたテンプレートからルールを作成することを選択できます。Amazon Redshift は、述語のセットを含む新しいルールを作成し、述語にデフォルト値で入力します。デフォルトのアクションはログです。述語とアクションはユースケースに合わせて変更できます。

次の表に利用可能なテンプレートの一覧を示します。

テンプレート名 述語 説明
ネストされたループ結合 nested_loop_join_row_count > 100 ネストしたループ結合は、不完全な結合述語を示すことがあります。この場合、高確率でリターンセットが非常に大きくなります (デカルト積)。少ない行数を使用して潜在的なランナウェイクエリを早期に検出します。
クエリが多くの行を返す return_row_count > 1000000 キューを実行中のシンプルで短いクエリ専用にすると、多くの行数を返すクエリを見つけるルールが含まれる可能性があります。テンプレートはデフォルトで 100 万行を使用します。システムによっては、100 万行で多いとみなされます。またより大きなシステムでは、10 億行で多いとみなされます。
多くの行がある結合 join_row_count > 1000000000 結合ステップの行数が以上に多い場合は、フィルタの制限を厳格化することが必要な可能性があります。テンプレートはデフォルトで 10 億行を使用します。素早くシンプルなクエリを目的にしたアドホック (ワンタイム) キューの場合は、この行数を小さくすることができます。
中間結果を書き込むときの高いディスク使用 query_temp_blocks_to_disk > 100000 現在実行中のクエリが制限を超えてシステム RAM を使用する場合、クエリ実行エンジンは中間結果をディスク (スピルされたメモリ) に書き込みます。通常、この条件は不正なクエリの結果です。また、この不正なクエリはディスク容量の大部分を使用します。ディスク使用量の許容可能なしきい値は、クラスターノードのタイプと数に応じて異なります。テンプレートは、デフォルトで 100,000 ブロックまたは 100 GB を使用します。小さなクラスターでは少ない数を使用できます。
高い I/O スキューで長時間実行されているクエリ segment_execution_time > 120 および io_skew > 1.30 I/O スキューは、1 つのノードスライスの I/O 料金が他のスライスよりもかなり高い場合に発生します。開始点として、1.30 のスキュー (平均 1.3 倍) は高いとみなされます。I/O スキューが高いことが必ず問題であるわけではありませんが、クエリの実行が長時間におよぶなどの状態と組み合わさる場合は、分散スタイルやソートキーに問題がある可能性があります。

クエリのモニタリングルールのシステムテーブルとビュー

ルールの述語がすべて満たされると、WLM は STL_WLM_RULE_ACTION システムテーブルに行を書き込みます。この行には、ルールをトリガーしたクエリとその結果のアクションに関する詳細が含まれます。

さらに、Amazon Redshift では、次のシステムテーブルとビューにクエリメトリクスが記録されます。

  • STV_QUERY_METRICS テーブルは、現在実行中のクエリのメトリクスを表示します。

  • STL_QUERY_METRICS テーブルは完了したクエリのメトリクスを記録します。

  • SVL_QUERY_METRICS ビューは、完了したクエリのメトリクスを示します。

  • SVL_QUERY_METRICS_SUMMARY ビューは、完了したクエリのメトリクスの最大値を示します。