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 では、WLM 設定を変更して、実行時間が長いクエリと短いクエリ用に異なるキューを作成することによって、システムパフォーマンスとユーザーエクスペリエンスを管理できます。
ユーザーが Amazon Redshift でクエリを実行すると、クエリはクエリキューにルーティングされます。各クエリキューには、いくつかのクエリスロットが含まれています。各キューには、クラスターの使用可能なメモリの一部が割り当てられます。キューのメモリは、キューのクエリスロットに分けられます。Amazon Redshift では、自動 WLM を使用してクエリの同時実行数を管理できます。詳細については、「[自動 WLM の実装](automatic-wlm.md)」を参照してください。
または、クエリキューごとに WLM プロパティを設定できます。このようにして、メモリをスロット間に割り当てる方法と、ランタイムに特定のキューにクエリをルーティングする方法を指定します。実行時間の長いクエリをキャンセルするように WLM プロパティを設定することもできます。
デフォルトでは、Amazon Redshift は次のクエリキューを設定します。
+ **つのスーパーユーザーキュー**
スーパーユーザーキューは、スーパーユーザー専用に予約されており、設定することはできません。このキューを使用するのは、システムに影響を与えるクエリを実行したり、トラブルシューティング目的でクエリを実行したりする場合に限ります。例えば、ユーザーの実行時間が長いクエリをキャンセルしたり、ユーザーをデータベースに追加したりする必要がある場合にこのキューを使用します。これを使用してルーチンクエリを実行しないでください。このキューはコンソールには表示されませんが、データベースのシステムテーブルに 5 番目のキューとして表示されます。スーパーユーザーキューでクエリを実行するには、ユーザーはスーパーユーザーとしてログインし、事前定義された `superuser` クエリグループを使用してクエリを実行する必要があります。
+ **つのデフォルトのユーザーキュー**
デフォルトキューは、最初は 5 つのクエリを同時に実行するように設定されています。手動 WLM を使用するときには、デフォルトキューの同時実行数、タイムアウト、メモリ割り当ての各プロパティを変更することはできますが、ユーザーグループまたはクエリグループを指定することはできません。デフォルトキューは、WLM 設定の最後のキューにする必要があります。他のキューにルーティングされないクエリはすべて、デフォルトキューで実行されます。
クエリキューは WLM 設定で定義されます。WLM 設定はパラメータグループの編集可能なパラメータ（`wlm_json_configuration`）であり、1 つ以上のクラスターと関連付けることができます。詳細については、「*Amazon Redshift 管理ガイド*」の「[ワークロード管理の設定](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)」を参照してください。
デフォルトの WLM 設定にクエリキューを追加することができます (最大合計 8 つのユーザーキュー)。クエリキューごとに以下を設定できます。
+ 同時実行スケーリングモード
+ 同時実行レベル
+ ユーザーグループ
+ クエリグループ
+ 使用する WLM メモリの割合
+ WLM タイムアウト
+ WLM クエリキューのホッピング
+ クエリのモニタリングルール
## 同時実行スケーリングモード
同時実行スケーリングが有効化された状態で、読み取りと書き込みクエリの同時実行の増加に対応する必要がある場合、Amazon Redshift は新たなクラスター容量を自動的に追加します。クエリをメインクラスターと同時実行スケーリングクラスターのどちらで実行しても、ユーザーには最新のデータが表示されます。
WLM キューを設定することで、どのクエリを同時実行スケーリングクラスターに送信するかを管理します。キューに対して同時実行スケーリングを有効にすると、対象クエリは待機することなく同時実行クラスターに送信されます。詳細については、「[同時実行スケーリング](concurrency-scaling.md)」を参照してください。
## 同時実行レベル
キューのクエリは、キューに対して定義された WLM クエリスロットの数または*同時実行*レベルに達するまで、同時に実行されます。その後、以降のキューはキューで待機します。
**注記**
WLM の同時実行レベルは、クラスターに対して同時実行可能なユーザー接続の数とは異なります。詳細については、「*Amazon Redshift 管理ガイド*」の「[クラスターへの接続](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-to-cluster.html)」を参照してください。
自動 WLM 設定 (推奨) では、同時実行レベルは **[自動]** に設定されます。Amazon Redshift はメモリをクエリに動的に割り当てます。その後、同時実行数が決まります。これは、実行中のクエリとキューに登録されたクエリの両方に必要なリソースに基づきます。自動 WLM は設定できません。詳細については、「[自動 WLM の実装](automatic-wlm.md)」を参照してください。
手動 WLM 設定では、Amazon Redshift は各キューに固定量のメモリを静的に割り当てます。キューのメモリは、クエリスロットに均等に分割されます。例として、キューにクラスターのメモリの 20% が割り当てられ、スロットが 10 個ある場合、各クエリにはクラスターのメモリの 2% が割り当てられます。メモリ割り当ては、同時実行されるクエリの数とは関係なく、固定量のままです。このようにメモリ割り当てが固定されているため、スロット数が 5 のときにメモリ内で全体を実行できるクエリは、スロット数が 20 に引き上げられると、中間結果をディスクに書き込むことが必要になる場合があります。この場合、キューのメモリにおける各クエリのシェアは、5 分の 1 から 20 分の 1 に減少します。ディスク I/O が余分に発生すると、パフォーマンスが低下する可能性があります。
すべてのユーザー定義キューの最大スロット数は 50 です。このため、デフォルトキューを含むすべてのキューの合計スロット数が制限されます。制限の対象とならない唯一のキューは、予約済みのスーパーユーザーキューです。
デフォルトでは、手動 WLM キューの同時実行レベルは 5 です。次のような場合は、同時実行レベルを引き上げるとワークロードに良い影響があることがあります。
+ 多数の小さいクエリが長時間実行クエリを強制的に待機させられている場合は、より多いスロット数のキューを別に作成し、小さいクエリをそのキューに割り当てます。キューの同時実行レベルが高いと各クエリスロットに割り当てられるメモリは少なくなるものの、クエリが小さい方が必要なメモリが少なくなります。
**注記**
ショートクエリアクセラレーション (SQA) を有効にすると、WLM によって実行時間が短いクエリが実行時間が長いクエリよりも優先されます。このため、ショートクエリ用の個別のキューは、大部分のワークフローで不要になります。詳細については、「[ショートクエリアクセラレーション](wlm-short-query-acceleration.md)」を参照してください。
+ それぞれが単一のスライス上のデータにアクセスする複数のクエリがある場合は、それらのクエリを同時に実行するように個別の WLM キューを設定します。Amazon Redshift は、同時実行クエリを別々のスライスに割り当てます。これにより、複数のクエリを複数のスライスで並行して実行できます。例えば、クエリが分散キーに関する述語を持つ単純な集計である場合、クエリのデータは単一のスライスに配置されます。
### 手動 WLM の例
この例は、スロットとメモリの割り当て方法を示す簡単な手動 WLM シナリオです。手動 WLM は、次の 3 つのキューを使用して実装します。
+ *データインジェストキュー* - これは、データを取り込むために設定されます。クラスターのメモリの 20% が割り当てられ、5 つのスロットがあります。その後、キュー内で 5 つのクエリを同時に実行でき、それぞれにメモリの 4% が割り当てられます。
+ *データサイエンティストキュー* - これは、メモリを大量に消費するクエリ用に設計されています。クラスターのメモリの 20% が割り当てられ、5 つのスロットがあります。その後、キュー内で 5 つのクエリを同時に実行でき、それぞれにメモリの 8% が割り当てられます。
+ *デフォルトキュー* - これは組織内のほとんどのユーザー向けに設計されています。これには、一般にクエリの実行時間が短いか中程度であり、複雑ではない営業グループや経理グループも含まれます。クラスターのメモリの 40% が割り当てられ、40 のスロットがあります。このキューでは 40 のクエリを同時に実行でき、各クエリにはメモリの 1% が割り当てられます。すべてのキューの制限は 50 であるため、これは、このキューに割り当てることができる最大スロット数です。
自動 WLM を実行し、15 を超えるクエリを並列実行する必要があるワークロードの場合は、同時実行スケーリングを有効にすることをお勧めします。これは、クエリスロット数を 15 より大きくすると、システムリソースの競合が発生し、単一クラスターの全体的なスループットが制限される可能性があるためです。同時実行スケーリングでは、設定された数の同時実行スケーリングクラスターまで数百のクエリを並列実行できます。同時実行スケーリングクラスターの数は、[max\_concurrency\_scaling\_clusters](r_max_concurrency_scaling_clusters.md) によって制御されます。同時実行スケーリングの詳細については、「[同時実行スケーリング](concurrency-scaling.md)」を参照してください。
詳細については、「[クエリパフォーマンスの向上](query-performance-improvement-opportunities.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 シェル形式のワイルドカードを使用して割り当てることができます。パターンマッチングでは大文字と小文字が区別されません。
例えば、ワイルドカード文字「\*」は任意の文字数に一致します。例えば、キューのユーザーグループのリストに `dba_*` を追加すると、`dba_` で始まる名前を持つグループに属する、ユーザーが実行するすべてのクエリは、そのキューに割り当てられます。例は、`dba_admin` や `DBA_primary` です。ワイルドカード文字「?」は、任意の 1 文字に一致します。したがって、キューにユーザーグループ `dba?1` が含まれている場合、`dba11` と `dba21` は一致しますが、`dba12` は一致しません。
ワイルドカードはデフォルトでオフになっています。
## 使用する WLM メモリの割合
自動 WLM 設定の場合、メモリの割合は **auto** に設定されます。詳細については、「[自動 WLM の実装](automatic-wlm.md)」を参照してください。
手動 WLM 設定の場合、クエリに割り当てる使用可能なメモリの量を指定するには、`WLM Memory Percent to Use` パラメータを設定できます。デフォルトでは、各ユーザー定義キューには、ユーザー定義クエリで使用可能なメモリが均等に割り当てられます。例えば、4 つのユーザー定義キューがある場合、各キューには使用可能なメモリの 25 パーセントが割り当てられます。Superuser キューには、独自に割り当てられているメモリがあり、変更できません。割り当て量を変更するには、各キューのメモリの割合を整数で割り当てます (最大で合計 100 パーセント)。未割り当てのメモリは Amazon Redshift によって管理され、処理用に追加メモリをリクエストするキューに一時的に付与できます。
例えば、4 つのキューを設定する場合、20 パーセント、30 パーセント、15 パーセント、15 パーセントのようにメモリを割り当てることができます。残りの 20 パーセントは未割り当てになり、サービスによって管理されます。
## WLM タイムアウト
WLM タイムアウト (`max_execution_time`) は廃止されました。代わりに、`query_execution_time` を使用してクエリモニタリングルール (QMR) を作成して、経過したクエリ実行時間を制限します。詳細については、「[WLM クエリモニタリングルール](cm-c-wlm-query-monitoring-rules.md)」を参照してください。
各キューについて WLM タイムアウト値を設定することで、特定の WLM キュー内でクエリが使用できる時間を制限することができます。タイムアウトパラメータは、クエリをキャンセルまたはホップする前に Amazon Redshift がクエリの実行を待機する時間を、ミリ秒単位で指定します。タイムアウトはクエリの実行時間に基づいていて、キューでの待機時間は含まれません。
WLM は、[CREATE TABLE AS](r_CREATE_TABLE_AS.md) (CTAS) ステートメントと読み取り専用クエリ (SELECT ステートメントなど) のホップを試みます。ホップできないクエリはキャンセルされます。詳細については、「[WLM クエリキューのホッピング](wlm-queue-hopping.md)」を参照してください。
WLM タイムアウトは returning 状態に達したクエリには適用されません。クエリの状態を表示するには、[STV\_WLM\_QUERY\_STATE](r_STV_WLM_QUERY_STATE.md) システムテーブルを参照してください。COPY ステートメントとメンテナンスオペレーション (ALTER、ANALYZE、VACUUM など) は、WLM タイムアウトの対象ではありません。
WLM タイムアウトの機能は、[statement\_timeout](r_statement_timeout.md) 設定パラメータと似ています。相違点は、`statement_timeout` 設定パラメータがクラスター全体に適用されるのに対して、WLM タイムアウトは WLM 設定の単一のキューに固有であることです。
[statement\_timeout](r_statement_timeout.md) も指定されている場合、statement\_timeout および WLM タイムアウト (max\_execution\_time) の低い方が使用されます。
## クエリのモニタリングルール
クエリモニタリングルールは、WLM キューのメトリクスベースのパフォーマンスの境界を定義し、クエリがこれらの境界を超えた場合のアクションを指定します。例えば、実行時間の短いクエリ専用のキューには、60 秒以上実行されるクエリをキャンセルするルールを作成できます。デザインの不十分なクエリを追跡する目的で、ネステッドループを含むクエリを記録する別のルールを設定することができます。詳細については、「[WLM クエリモニタリングルール](cm-c-wlm-query-monitoring-rules.md)」を参照してください。