クエリ優先度 - Amazon Redshift

クエリ優先度

すべてのクエリの重要性が同じわけではなく、多くの場合、1 つのワークロードまたはユーザーセットのパフォーマンスが重要になる場合があります。自動 WLM を有効にしている場合は、優先度の値を設定して、ワークロードでのクエリの相対的な重要度を定義することができます。優先度はキューに指定され、キューに関連付けられたすべてのクエリに継承されます。クエリをキューに関連付けるには、ユーザーグループとクエリグループをキューにマッピングします。次の優先度を設定することができます (優先順位が高~低の順に表示)。

  1. HIGHEST

  2. HIGH

  3. NORMAL

  4. LOW

  5. LOWEST

管理者は、これらの優先度を使用して、同じリソースに対して競合する異なる優先度のクエリがある場合に、ワークロードの相対的な重要性を示します。Amazon Redshift は、システムにクエリを許可するとき、およびクエリに割り当てられるリソースの量を決定するときに優先度を使用します。デフォルトでは、クエリは、優先度を NORMAL に設定して実行されます。

追加の優先度 CRITICAL は、HIGHEST よりも優先度が高く、スーパーユーザーが利用できます。この優先度を設定するには、CHANGE_QUERY_PRIORITY 関数、 CHANGE_SESSION_PRIORITY 関数、および CHANGE_USER_PRIORITY 関数を使用できます。これらの関数を使用するアクセス許可をデータベースユーザーに付与するには、ストアドプロシージャを作成し、ユーザーにアクセス許可を付与します。例については、「CHANGE_SESSION_PRIORITY」をご参照ください。

注記

一度に実行できる CRITICAL クエリは 1 つのみです。

抽出、変換、ロード (ETL) ワークロードの優先度が分析ワークロードの優先度よりも高い例を見てみましょう。ETL ワークロードは 6 時間ごとに実行され、分析ワークロードは 1 日中実行されます。クラスターで分析ワークロードのみが実行されている場合は、システム全体が最適化され、最適なシステム使用率で高いスループットが得られます。ただし、ETL ワークロードは優先度が高いため、このワークロードが開始されると優先して処理されます。ETL ワークロードの一部として実行されるクエリは、受け入れ中と、受け入れ後の優先リソース割り当て中に優先度が上がります。結果として、ETL ワークロードは、システムで他に何が実行されているかに関係なく、予測どおりに実行されます。そのため、予測可能なパフォーマンスと、管理者がビジネスユーザーにサービスレベルアグリーメント (SLA) を提示する機能を提供します。

特定のクラスター内では、優先度の高いワークロードの予測可能なパフォーマンスは、優先度の低い他のワークロードのコストになります。優先度の低いワークロードでは、重要の高いクエリが完了するまで待機するため、実行時間が長くなる場合があります。また、優先度の高いクエリを同時に実行している場合は、リソースの割合が小さくなるために実行時間が長くなる場合があります。優先度の低いクエリでリソース不足に悩まされることはありませんが、進行するペースは遅くなります。

前述の例で、管理者は、分析ワークロードの同時実行スケーリングを有効にすることができます。これにより、ETL ワークロードが高い優先度で実行されていても、そのワークロードはスループットを維持できます。

キュー優先度を設定する

自動 WLM を有効にしている場合、各キューには優先度の値があります。クエリは、ユーザーグループとクエリグループに基づいてキューにルーティングされます。キューの優先順位を NORMAL に設定して開始します。キューのユーザーグループとクエリグループに関連付けられたワークロードに基づいて、優先度を高くまたは低く設定します。

キューの優先度は、Amazon Redshift コンソールで変更できます。Amazon Redshift コンソールの [Workload Management] (ワークロード管理) ページにキューが表示され、[Priority] (優先度) などのキューのプロパティを編集できるようになります。CLI または API オペレーションを使用して優先度を設定するには、wlm_json_configuration パラメータを使用します。詳細については、Amazon Redshift クラスター管理ガイドの「ワークロード管理の設定」を参照してください。

次の wlm_json_configuration の例では、3 つのユーザーグループ (ingestreportinganalytics) を定義します。これらのグループのいずれかのユーザーから送信されたクエリは、優先度 (highestnormallow) のそれぞれで実行されます。

[ { "user_group": [ "ingest" ], "priority": "highest", "queue_type": "auto" }, { "user_group": [ "reporting" ], "priority": "normal", "queue_type": "auto" }, { "user_group": [ "analytics" ], "priority": "low", "queue_type": "auto", "auto_wlm": true } ]

クエリモニタリングルールを使用してクエリ優先度を変更する

クエリモニタリングルール (QMR) を使用すると、実行中の動作に基づいてクエリの優先度を変更できます。変更するには、アクションに加えて、QMR 述語で priority 属性を指定します。詳細については、「WLM クエリモニタリングルール」を参照してください。

例えば、10 分以上実行される優先度 high として分類されたクエリをキャンセルするルールを定義できます。

"rules" :[ { "rule_name":"rule_abort", "predicate":[ { "metric_name":"query_cpu_time", "operator":">", "value":600 }, { "metric_name":"query_priority", "operator":"=", "value":"high" } ], "action":"abort" } ]

もう一方の例では、1 TB を超えるディスクに溢れる現在の優先度 normal のクエリのクエリ優先度を lowest に変更するルールを定義します。

"rules":[ { "rule_name":"rule_change_priority", "predicate":[ { "metric_name":"query_temp_blocks_to_disk", "operator":">", "value":1000000 }, { "metric_name":"query_priority", "operator":"=", "value":"normal" } ], "action":"change_query_priority", "value":"lowest" } ]

クエリ優先度をモニタリングする

クエリの待機および実行の優先度を表示するには、stv_wlm_query_state システムテーブルの query_priority 列を表示します。

query | service_cl | wlm_start_time | state | queue_time | query_priority ---------+------------+----------------------------+------------------+------------+---------------- 2673299 | 102 | 2019-06-24 17:35:38.866356 | QueuedWaiting | 265116 | Highest 2673236 | 101 | 2019-06-24 17:35:33.313854 | Running | 0 | Highest 2673265 | 102 | 2019-06-24 17:35:33.523332 | Running | 0 | High 2673284 | 102 | 2019-06-24 17:35:38.477366 | Running | 0 | Highest 2673288 | 102 | 2019-06-24 17:35:38.621819 | Running | 0 | Highest 2673310 | 103 | 2019-06-24 17:35:39.068513 | QueuedWaiting | 62970 | High 2673303 | 102 | 2019-06-24 17:35:38.968921 | QueuedWaiting | 162560 | Normal 2673306 | 104 | 2019-06-24 17:35:39.002733 | QueuedWaiting | 128691 | Lowest

完了したクエリのクエリ優先度をリストするには、stl_wlm_query システムテーブルの query_priority 列を参照してください。

select query, service_class as svclass, service_class_start_time as starttime, query_priority from stl_wlm_query order by 3 desc limit 10;
query | svclass | starttime | query_priority ---------+---------+----------------------------+---------------------- 2723254 | 100 | 2019-06-24 18:14:50.780094 | Normal 2723251 | 102 | 2019-06-24 18:14:50.749961 | Highest 2723246 | 102 | 2019-06-24 18:14:50.725275 | Highest 2723244 | 103 | 2019-06-24 18:14:50.719241 | High 2723243 | 101 | 2019-06-24 18:14:50.699325 | Low 2723242 | 102 | 2019-06-24 18:14:50.692573 | Highest 2723239 | 101 | 2019-06-24 18:14:50.668535 | Low 2723237 | 102 | 2019-06-24 18:14:50.661918 | Highest 2723236 | 102 | 2019-06-24 18:14:50.643636 | Highest

ワークロードのスループットを最適化するために、Amazon Redshift はユーザーが送信したクエリの優先順位を変更することがあります。Amazon Redshift は、高度な機械学習アルゴリズムを使用して、この最適化がワークロードに利点をもたらす時期を判断し、次のすべての条件が満たされたときに自動的に適用します。

  • 自動 WLM は有効になっています。

  • 定義される WLM キューは 1 つだけです。

  • クエリの優先順位を設定するクエリモニタリングルール (QMR) が定義されていません。このようなルールには、QMR メトリクス query_priority または QMR アクション change_query_priority が含まれます。詳細については、「WLM クエリモニタリングルール」を参照してください。