Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# クエリ優先度
Amazon Redshift では、ワークロード管理 (WM) を使用して、同時実行クエリとワークロード間でクエリの優先順位付けとリソース割り当てを管理できます。以下のセクションでは、WM クエリキューの設定、メモリ割り当てや同時実行スケーリングなどのキュープロパティの定義、ワークロード要件に合わせた優先度ルールの実装方法について詳しく説明します。
すべてのクエリの重要性が同じわけではなく、多くの場合、1 つのワークロードまたはユーザーセットのパフォーマンスが重要になる場合があります。[自動 WLM](automatic-wlm.md) を有効にしている場合は、優先度の値を設定して、ワークロードでのクエリの相対的な重要度を定義することができます。優先度はキューに指定され、キューに関連付けられたすべてのクエリに継承されます。クエリをキューに関連付けるには、ユーザーグループとクエリグループをキューにマッピングします。次の優先度を設定することができます (優先順位が高～低の順に表示)。
1. `HIGHEST`
1. `HIGH`
1. `NORMAL`
1. `LOW`
1. `LOWEST`
管理者は、これらの優先度を使用して、同じリソースに対して競合する異なる優先度のクエリがある場合に、ワークロードの相対的な重要性を示します。Amazon Redshift は、システムにクエリを許可するとき、およびクエリに割り当てられるリソースの量を決定するときに優先度を使用します。デフォルトでは、クエリは、優先度を `NORMAL` に設定して実行されます。
追加の優先度 `CRITICAL` は、`HIGHEST` よりも優先度が高く、スーパーユーザーが利用できます。この優先度を設定するには、[CHANGE\$1QUERY\$1PRIORITY](r_CHANGE_QUERY_PRIORITY.md) 関数、 [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md) 関数、および [CHANGE\$1USER\$1PRIORITY](r_CHANGE_USER_PRIORITY.md) 関数を使用できます。これらの関数を使用するアクセス許可をデータベースユーザーに付与するには、ストアドプロシージャを作成し、ユーザーにアクセス許可を付与します。例については、「[CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md)」を参照してください。
**注記**
一度に実行できる `CRITICAL` クエリは 1 つのみです。
ロールバックは必ず CRITICAL の優先度で実行されます。
抽出、変換、ロード (ETL) ワークロードの優先度が分析ワークロードの優先度よりも高い例を見てみましょう。ETL ワークロードは 6 時間ごとに実行され、分析ワークロードは 1 日中実行されます。クラスターで分析ワークロードのみが実行されている場合は、システム全体が最適化され、最適なシステム使用率で高いスループットが得られます。ただし、ETL ワークロードは優先度が高いため、このワークロードが開始されると優先して処理されます。ETL ワークロードの一部として実行されるクエリは、受け入れ中と、受け入れ後の優先リソース割り当て中に優先度が上がります。結果として、ETL ワークロードは、システムで他に何が実行されているかに関係なく、予測どおりに実行されます。そのため、予測可能なパフォーマンスと、管理者がビジネスユーザーにサービスレベルアグリーメント (SLA) を提示する機能を提供します。
特定のクラスター内では、優先度の高いワークロードの予測可能なパフォーマンスは、優先度の低い他のワークロードのコストになります。優先度の低いワークロードでは、重要の高いクエリが完了するまで待機するため、実行時間が長くなる場合があります。また、優先度の高いクエリを同時に実行している場合は、リソースの割合が小さくなるために実行時間が長くなる場合があります。優先度の低いクエリでリソース不足に悩まされることはありませんが、進行するペースは遅くなります。
前述の例で、管理者は、分析ワークロードの[同時実行スケーリング](concurrency-scaling.md)を有効にすることができます。これにより、ETL ワークロードが高い優先度で実行されていても、そのワークロードはスループットを維持できます。
## キュー優先度を設定する
自動 WLM を有効にしている場合、各キューには優先度の値があります。クエリは、ユーザーグループとクエリグループに基づいてキューにルーティングされます。キューの優先順位を `NORMAL` に設定して開始します。キューのユーザーグループとクエリグループに関連付けられたワークロードに基づいて、優先度を高くまたは低く設定します。
キューの優先度は、Amazon Redshift コンソールで変更できます。Amazon Redshift コンソールの **[Workload Management]** (ワークロード管理) ページにキューが表示され、**[Priority]** (優先度) などのキューのプロパティを編集できるようになります。CLI または API オペレーションを使用して優先度を設定するには、`wlm_json_configuration` パラメータを使用します。詳細については、「*Amazon Redshift 管理ガイド*」の「[ワークロード管理の設定](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)」を参照してください。
次の `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 クエリモニタリングルール](cm-c-wlm-query-monitoring-rules.md)」を参照してください。
例えば、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 を超えるディスクに溢れる現在の優先度 `lowest` のクエリのクエリ優先度を `normal` に変更するルールを定義します。
```
"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\$1wlm\$1query\$1state システムテーブルの `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\$1wlm\$1query システムテーブルの `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 クエリモニタリングルール](cm-c-wlm-query-monitoring-rules.md)」を参照してください。