クエリ優先度 - Amazon Redshift
キュー優先度を設定するQMR を使用したクエリ優先度の変更クエリ優先度をモニタリングする

クエリ優先度

すべてのクエリの重要性が同じわけではなく、多くの場合、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 つのユーザーグループ (ingest、reporting、analytics) を定義します。これらのグループのいずれかのユーザーから送信されたクエリは、優先度 (highest、normal、low) のそれぞれで実行されます。

[
    {
        "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 クエリモニタリングルール」を参照してください。