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 WLM は、自動 WLM または手動 WLM で実行するように設定できます。
Amazon Redshift では、同時実行クエリとユーザーワークロードを管理および優先順位付けして、パフォーマンスとリソース使用率を最適化できます。ワークロード管理 (WLM) を使用すると、キュー、ユーザーグループ、その他のコンストラクトを定義して、さまざまなタイプのクエリやユーザーに割り当てられたリソースを制御できます。
以下のセクションでは、Amazon Redshift のワークロード管理機能の概要、および管理機能の設定とモニタリングについて説明します。
**自動 WLM**
システムのスループットを最大化し、リソースを効率的に使用するには、Amazon Redshift で、同時実行クエリを自動 WLM で実行するためのリソースの分割方法を管理できます。*自動 WLM* は、クエリの実行に必要なリソースを管理します。Amazon Redshift は、ディスパッチされたクエリごとに割り当てる同時実行クエリ数とメモリ量を決定します。Amazon Redshift で、同時実行クエリを実行するためにリソースの分割方法を管理する場合は、自動 WLM を使用します。詳細については、「[自動 WLM の実装](automatic-wlm.md)」を参照してください。
同時実行スケーリングや自動 WLM を使用すると、一貫した高速のクエリパフォーマンスで、事実上無制限の同時ユーザーと同時クエリをサポートできます。詳細については、「[同時実行スケーリング](concurrency-scaling.md)」を参照してください。
**注記**
ほとんどの場合では、自動 WLM を使用することをお勧めします。手動 WLM を使用していて、自動 WLM から/に移行する場合は、「[手動 WLM から自動 WLM に移行する](#wlm-manual-to-automatic)」を参照してください。
自動 WLM では、キュー内のワークロードのクエリ優先順位を定義できます。クエリの優先度の詳細については、「[クエリ優先度](query-priority.md)」を参照してください。
**手動 WLM**
複数のセッションやユーザーが同時にクエリを実行している場合があります。一部のクエリがクラスターリソースを長時間消費して、他のクエリのパフォーマンスに影響を与えることがあります。手動 WLM は、特殊なユースケースでこれを管理するのに役立ちます。同時実行をより細かく制御する場合は、手動 WLM を使用してください。
WLM 設定を変更して、実行時間が長いクエリと短いクエリ用に異なるキューを作成することによって、システムパフォーマンスを管理できます。実行時に、ユーザーグループまたはクエリグループに従って、これらのクエリをキューに配信できます。
クエリを実行するユーザーや指定したラベルに基づいて特定のキューにクエリをルーティングするためのルールを設定できます。各キューに割り当てるメモリの量を設定することによって、大きいクエリを他のキューよりメモリの多いキューで実行することもできます。また、実行時間が長いクエリを制限するようにクエリモニタリングルール (QMR) を設定することもできます。詳細については、「[手動 WLM を実装する](cm-c-defining-query-queues.md)」を参照してください。
**注記**
手動 WLM クエリキューのクエリスロットは合計 15 個以下にすることをお勧めします。詳細については、「[同時実行レベル](cm-c-defining-query-queues.md#cm-c-defining-query-queues-concurrency-level)」を参照してください。
手動 WLM 設定では、キューに割り当てることができる最大スロット数は 50 であることに注意してください。ただし、これは、自動 WLM 設定で Amazon Redshift クラスターが常に 50 個のクエリを同時に実行するという意味ではありません。これは、必要なメモリやクラスター上の他の種類のリソース割り当てに基づいて変わる可能性があります。
**Topics**
+ [WLM モードの切り替え](#cm-c-switching-mode)
+ [WLM 設定の変更](#cm-c-modifying-wlm-configuration)
+ [自動 WLM の実装](automatic-wlm.md)
+ [手動 WLM を実装する](cm-c-defining-query-queues.md)
+ [同時実行スケーリング](concurrency-scaling.md)
+ [ショートクエリアクセラレーション](wlm-short-query-acceleration.md)
+ [WLM キュー割り当てルール](cm-c-wlm-queue-assignment-rules.md)
+ [キューへのクエリの割り当て](cm-c-executing-queries.md)
+ [WLM の動的設定プロパティと静的設定プロパティ](cm-c-wlm-dynamic-properties.md)
+ [WLM クエリモニタリングルール](cm-c-wlm-query-monitoring-rules.md)
+ [WLM システムテーブルとビュー](cm-c-wlm-system-tables-and-views.md)
## WLM モードの切り替え
Amazon Redshift コンソールを使用して、自動または手動 WLM を有効にできます。
1. [**Switch WLM mode (WLM モードの切り替え)**] を選択します。
1. 自動 WLM に設定するには、**自動 WLM** を選択します。このオプションでは、最大 8 個のキューを使用してクエリを管理します。[**メモリ**] フィールドと [**Concurrency on main (メインでの同時実行数)**] フィールドはいずれも、[**Auto (自動)**] に設定されます。デフォルトでは、クエリの優先度は、**[通常]** に設定されます。
1. この手動設定を有効にするには、Amazon Redshift コンソールで **[手動 WLM]** に切り替えます。このオプションでは、管理する対象のキューと、[**メモリ**] フィールドおよび [**Concurrency on main (メインでの同時実行数)**] フィールドの値を指定します。手動設定では、クエリキューを最大 8 個設定できます。さらに、これらのキューごとに同時実行できるクエリの数を設定できます。
## WLM 設定の変更
WLM の設定を変更する最も簡単な方法は、Amazon Redshift コンソールを使用することです。AWS CLI または Amazon Redshift API を使用することもできます。
クラスターの自動 WLM と手動 WLM を切り替えると、クラスターは `pending reboot` 状態になります。次のクラスターを再起動するまで、変更は有効になりません。
WLM 設定の変更についての詳細は、*Amazon Redshift 管理ガイド*の「[ワークロード管理の設定](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)」を参照してください。
### 手動 WLM から自動 WLM に移行する
システムのスループットを最大化し、リソースを最も効果的に使用するには、キューに自動 WLM を設定することをお勧めします。手動 WLM から自動 WLM へのスムーズな移行をセットアップするには、次のアプローチを検討してください。
手動 WLM から自動 WLM に移行し、クエリの優先度を使用するには、新しいパラメータグループを作成し、そのパラメータグループをクラスターにアタッチすることをお勧めします。詳細については、「[Amazon Redshift 管理ガイド](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html)」の「*Amazon Redshift パラメータグループ*」を参照してください。
**重要**
パラメータグループを変更したり、手動から自動 WLM に切り替えたりするには、クラスターを再起動する必要があります。詳細については、「[WLM の動的設定プロパティと静的設定プロパティ](cm-c-wlm-dynamic-properties.md)」を参照してください。
3 つの手動 WLM キューがある例を見てみましょう。ETL ワークロード、分析ワークロード、およびデータサイエンスワークロードごとに 1 つ。ETL ワークロードは 6 時間ごとに実行され、分析ワークロードは終日実行されており、データサイエンスワークロードはいつでも急増する可能性があります。手動 WLM では、ビジネスに対する各ワークロードの重要性の理解に基づいて、各ワークロードキューが取得するメモリと同時実行性を指定します。メモリと同時実行性を指定するのは、理解するのが難しいだけでなく、クラスターリソースが静的に分割され、ワークロードのサブセットのみが実行されているときに無駄になります。
クエリの優先度を指定した自動 WLMを使用して、ワークロードの相対的な優先度を示し、前述の問題を回避できます。この例では、以下のステップを行います。
+ 新しいパラメータグループを作成し、[**Auto WLM**] モードに切り替えます。
+ ETL ワークロード、分析ワークロード、データサイエンスワークロードの 3 つのワークロードのそれぞれにキューを追加します。**手動 WLM** モードで使用されたワークロードごとに、同じユーザーグループを使用します。
+ ETL ワークロードの優先度を `High`、分析ワークロードは `Normal`、データサイエンスは `Low` に設定します。これらの優先順位は、さまざまなワークロードまたはユーザーグループに対するビジネスの優先順位を反映しています。
+ オプションで、ETL ワークロードが 6 時間ごとに実行されている場合でも、これらのキューのクエリで一貫したパフォーマンスが得られるように、分析キューまたはデータサイエンスキューの同時実行スケーリングを有効にします。
クエリの優先度を使用すると、クラスターで分析ワークロードのみが実行されている場合は、システム全体を独占できます。これにより、高いスループットが得られ、システム使用率も向上します。ただし、ETL ワークロードは優先度が高いため、このワークロードが開始されると優先して処理されます。ETL ワークロードの一部として実行されるクエリは、受け入れ時だけでなく、受け入れ後も優先リソース割り当てを得ることができます。結果として、ETL ワークロードは、システムで他に何が実行されているかに関係なく、予測どおりに実行されます。優先度の高いワークロードの予測可能なパフォーマンスには、実行時間が長く、優先度の低い他のワークロードのコストがかかります。これは、クエリで、重要度が高いクエリが完了するのを待機しているか、優先度の高いクエリを同時に実行している場合は、リソースの割合が小さくなるためです。Amazon Redshift で使用されているスケジューリングアルゴリズムにより、優先度の低いクエリがリソース不足に悩まされることはなく、遅いペースで進行し続けます。
**注記**
タイムアウトフィールドは、自動 WLM では使用できません。代わりに、QMR ルールである `query_execution_time` を使用します。詳細については、「[WLM クエリモニタリングルール](cm-c-wlm-query-monitoring-rules.md)」を参照してください。
QMR アクションである HOP は、自動 WLM には使用できません。代わりに、`change priority` アクションを使用します。詳細については、「[WLM クエリモニタリングルール](cm-c-wlm-query-monitoring-rules.md)」を参照してください。
クラスターでは、自動 WLM キューと手動 WLM キューの使用方法が異なるため、設定が混乱する可能性があります。例えば、自動 WLM キューでは優先度プロパティを設定できますが、手動 WLM キューでは設定できません。パラメータグループ内で、自動 WLM キューと手動 WLM キューを混在させないようにしてください。代わりに、自動 WLM に移行するときに新しいパラメータグループを作成します。