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/)を参照してください。
# 自動 WLM の実装
自動ワークロード管理 (WLM) では、Amazon Redshift がクエリの同時実行数とメモリの割り当てを管理します。サービスクラスの識別子 100〜107 を使用して、最大 8 つのキューを作成できます。各キューには優先度があります。詳細については、「[クエリ優先度](query-priority.md)」を参照してください。
自動 WLM は、クエリに必要なリソース量を決定し、ワークロードに基づいて同時実行数を調整します。大量のリソースを必要とするクエリがシステムにある場合 (大きなテーブル間のハッシュ結合など)、同時実行数は減ります。軽いクエリ (挿入、削除、スキャン、単純な集計など) を送信すると、同時実行数は増えます。
自動 WLM は、ショートクエリアクセラレーション (SQA) とは別のものであり、クエリの評価方法が異なります。自動 WLM と SQA は連携して動作し、長時間実行されるリソース集約型のクエリがアクティブな場合でも、短時間実行されるクエリや軽量のクエリを完了させることができます。SQA の詳細については、「[ショートクエリアクセラレーション](wlm-short-query-acceleration.md)」を参照してください。
Amazon Redshift では、パラメータグループを使用して、自動 WLM を有効にします。
+ クラスターでデフォルトのパラメータグループを使用している場合は、Amazon Redshift のクラスターで自動 WLM が有効になります。
+ クラスターでカスタムパラメータグループを使用している場合は、自動 WLM を有効にするようにクラスターを設定することができます。自動 WLM の設定用に個別のパラメータグループを作成することをお勧めします。
WLM を設定するには、1 つ以上のクラスターと関連付けることのできるパラメータグループの `wlm_json_configuration` パラメータを編集します。詳細については、「[WLM 設定の変更](cm-c-implementing-workload-management.md#cm-c-modifying-wlm-configuration)」を参照してください。
クエリキューは、WLM 設定内で定義することができます。デフォルトの WLM 設定にクエリキューを追加することができます (最大合計 8 つのユーザーキュー)。クエリキューごとに以下を設定できます。
+ 優先度
+ 同時実行スケーリングモード
+ ユーザーグループ
+ クエリグループ
+ クエリのモニタリングルール
## Priority
ワークロードでのクエリの相対的な重要度を定義するには、優先度の値を設定します。優先度はキューに指定され、キューに関連付けられたすべてのクエリに継承されます。詳細については、「[クエリ優先度](query-priority.md)」を参照してください。
## 同時実行スケーリングモード
同時実行スケーリングが有効化された状態で、読み取りと書き込みクエリの同時実行の増加に対応する必要がある場合、Amazon Redshift は新たなクラスター容量を自動的に追加します。クエリをメインクラスターと同時実行スケーリングクラスターのどちらで実行しても、ユーザーには最新のデータが表示されます。
WLM キューを設定することで、どのクエリを同時実行スケーリングクラスターに送信するかを管理します。キューに対して同時実行スケーリングを有効にすると、対象クエリは待機することなく同時実行クラスターに送信されます。詳細については、「[同時実行スケーリング](concurrency-scaling.md)」を参照してください。
## ユーザーグループ
各ユーザーグループ名を指定するか、ワイルドカードを使用して、一連のユーザーグループをキューに割り当てることができます。リストされたユーザーグループのメンバーがクエリを実行すると、そのクエリは対応するキューで実行されます。キューに割り当てることができるユーザーグループの数に設定された制限はありません。詳細については、「[ユーザーグループに基づくクエリのキューへの割り当て](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups)」を参照してください。
## ユーザーロール
各ユーザーロールを指定するか、ワイルドカードを使用して、一連のユーザーロールをキューに割り当てることができます。リストされたユーザーロールのメンバーがクエリを実行すると、そのクエリは対応するキューで実行されます。キューに割り当てることができるユーザーロールの数に設定された制限はありません。詳細については、「[ユーザーロールに基づくクエリのキューへの割り当て](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles)」を参照してください。
## クエリグループ
各クエリグループ名を指定するか、ワイルドカードを使用して、一連のクエリグループをキューに割り当てることができます。*クエリグループ*はラベルにすぎません。実行時に、一連のクエリにクエリグループラベルを割り当てることができます。一覧表示されたクエリグループに割り当てられたクエリは、対応するキューで実行されます。キューに割り当てることができるクエリグループの数に設定された制限はありません。詳細については、「[クエリグループへのクエリの割り当て](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group)」を参照してください。
## ワイルドカード
WLM キュー設定でワイルドカードを有効にした場合は、ユーザーグループやクエリグループをキューに個別に割り当てるか、Unix シェル形式のワイルドカードを使用して割り当てることができます。パターンマッチングでは大文字と小文字が区別されません。
例えば、ワイルドカード文字「\$1」は任意の文字数に一致します。例えば、キューのユーザーグループのリストに `dba_*` を追加すると、`dba_` で始まる名前を持つグループに属する、ユーザーが実行するすべてのクエリは、そのキューに割り当てられます。例えば、`dba_admin` や `DBA_primary` などがあります。ワイルドカード文字「?」は、任意の 1 文字に一致します。したがって、キューにユーザーグループ `dba?1` が含まれている場合、`dba11` と `dba21` は一致しますが、`dba12` は一致しません。
デフォルトでは、ワイルドカードは有効になっていません。
## クエリのモニタリングルール
クエリモニタリングルールは、WLM キューのメトリクスベースのパフォーマンスの境界を定義し、クエリがこれらの境界を超えた場合のアクションを指定します。例えば、実行時間の短いクエリ専用のキューには、60 秒以上実行されるクエリをキャンセルするルールを作成できます。デザインの不十分なクエリを追跡する目的で、ネステッドループを含むクエリを記録する別のルールを設定することができます。詳細については、「[WLM クエリモニタリングルール](cm-c-wlm-query-monitoring-rules.md)」を参照してください。
## 自動 WLM の設定を確認する
自動 WLM が有効になっているかどうかを確認するには、次のクエリを実行します。クエリより 1 行以上が返る場合、自動 WLM は有効になっています。
```
select * from stv_wlm_service_class_config
where service_class >= 100;
```
次のクエリは、各クエリキュー (サービスクラス) を通過したクエリの数を示しています。また、平均実行時間、待機時間が発生しているクエリの数 (90 パーセンタイル値)、平均待機時間を示しています。自動 WLM クエリでは、サービスクラス 100～107 を使用します。
```
select final_state, service_class, count(*), avg(total_exec_time),
percentile_cont(0.9) within group (order by total_queue_time), avg(total_queue_time)
from stl_wlm_query where userid >= 100 group by 1,2 order by 2,1;
```
自動 WLM で実行されて正常に完了したクエリを確認するには、次のクエリを実行します。
```
select a.queue_start_time, a.total_exec_time, label, trim(querytxt)
from stl_wlm_query a, stl_query b
where a.query = b.query and a.service_class >= 100 and a.final_state = 'Completed'
order by b.query desc limit 5;
```
# クエリ優先度
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)」を参照してください。