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 を実装する
<a name="cm-c-defining-query-queues"></a>

手動 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 クエリキューのホッピング
+ クエリのモニタリングルール

## 同時実行スケーリングモード
<a name="concurrency-scaling-mode"></a>

同時実行スケーリングが有効化された状態で、読み取りと書き込みクエリの同時実行の増加に対応する必要がある場合、Amazon Redshift は新たなクラスター容量を自動的に追加します。クエリをメインクラスターと同時実行スケーリングクラスターのどちらで実行しても、ユーザーには最新のデータが表示されます。

WLM キューを設定することで、どのクエリを同時実行スケーリングクラスターに送信するかを管理します。キューに対して同時実行スケーリングを有効にすると、対象クエリは待機することなく同時実行クラスターに送信されます。詳細については、「[同時実行スケーリング](concurrency-scaling.md)」を参照してください。

## 同時実行レベル
<a name="cm-c-defining-query-queues-concurrency-level"></a>

キューのクエリは、キューに対して定義された 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 の例
<a name="cm-c-defining-query-queues-concurrency-level-example"></a>

 この例は、スロットとメモリの割り当て方法を示す簡単な手動 WLM シナリオです。手動 WLM は、次の 3 つのキューを使用して実装します。
+ *データインジェストキュー* - これは、データを取り込むために設定されます。クラスターのメモリの 20% が割り当てられ、5 つのスロットがあります。その後、キュー内で 5 つのクエリを同時に実行でき、それぞれにメモリの 4% が割り当てられます。
+ *データサイエンティストキュー* - これは、メモリを大量に消費するクエリ用に設計されています。クラスターのメモリの 20% が割り当てられ、5 つのスロットがあります。その後、キュー内で 5 つのクエリを同時に実行でき、それぞれにメモリの 8% が割り当てられます。
+ *デフォルトキュー* - これは組織内のほとんどのユーザー向けに設計されています。これには、一般にクエリの実行時間が短いか中程度であり、複雑ではない営業グループや経理グループも含まれます。クラスターのメモリの 40% が割り当てられ、40 のスロットがあります。このキューでは 40 のクエリを同時に実行でき、各クエリにはメモリの 1% が割り当てられます。すべてのキューの制限は 50 であるため、これは、このキューに割り当てることができる最大スロット数です。

自動 WLM を実行し、15 を超えるクエリを並列実行する必要があるワークロードの場合は、同時実行スケーリングを有効にすることをお勧めします。これは、クエリスロット数を 15 より大きくすると、システムリソースの競合が発生し、単一クラスターの全体的なスループットが制限される可能性があるためです。同時実行スケーリングでは、設定された数の同時実行スケーリングクラスターまで数百のクエリを並列実行できます。同時実行スケーリングクラスターの数は、[max\$1concurrency\$1scaling\$1clusters](r_max_concurrency_scaling_clusters.md) によって制御されます。同時実行スケーリングの詳細については、「[同時実行スケーリング](concurrency-scaling.md)」を参照してください。

詳細については、「[クエリパフォーマンスの向上](query-performance-improvement-opportunities.md)」を参照してください。

## ユーザーグループ
<a name="cm-c-defining-query-queues-user-groups"></a>

各ユーザーグループ名を指定するか、ワイルドカードを使用して、一連のユーザーグループをキューに割り当てることができます。リストされたユーザーグループのメンバーがクエリを実行すると、そのクエリは対応するキューで実行されます。キューに割り当てることができるユーザーグループの数に設定された制限はありません。詳細については、「[ユーザーグループに基づくクエリのキューへの割り当て](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups)」を参照してください。

## ユーザーロール
<a name="cm-c-defining-query-queues-user-roles"></a>

各ユーザーロールを指定するか、ワイルドカードを使用して、一連のユーザーロールをキューに割り当てることができます。リストされたユーザーロールのメンバーがクエリを実行すると、そのクエリは対応するキューで実行されます。キューに割り当てることができるユーザーロールの数に設定された制限はありません。詳細については、「[ユーザーロールに基づくクエリのキューへの割り当て](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles)」を参照してください。

## クエリグループ
<a name="cm-c-defining-query-queues-query-groups"></a>

各クエリグループ名を指定するか、ワイルドカードを使用して、一連のクエリグループをキューに割り当てることができます。クエリグループはラベルにすぎません。実行時に、一連のクエリにクエリグループラベルを割り当てることができます。一覧表示されたクエリグループに割り当てられたクエリは、対応するキューで実行されます。キューに割り当てることができるクエリグループの数に設定された制限はありません。詳細については、「[クエリグループへのクエリの割り当て](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group)」を参照してください。

## ワイルドカード
<a name="wlm-wildcards"></a>

WLM キュー設定でワイルドカードを有効にした場合は、ユーザーグループやクエリグループをキューに個別に割り当てるか、Unix シェル形式のワイルドカードを使用して割り当てることができます。パターンマッチングでは大文字と小文字が区別されません。

例えば、ワイルドカード文字「\$1」は任意の文字数に一致します。例えば、キューのユーザーグループのリストに `dba_*` を追加すると、`dba_` で始まる名前を持つグループに属する、ユーザーが実行するすべてのクエリは、そのキューに割り当てられます。例は、`dba_admin` や `DBA_primary` です。ワイルドカード文字「?」は、任意の 1 文字に一致します。したがって、キューにユーザーグループ `dba?1` が含まれている場合、`dba11` と `dba21` は一致しますが、`dba12` は一致しません。

ワイルドカードはデフォルトでオフになっています。

## 使用する WLM メモリの割合
<a name="wlm-memory-percent"></a>

自動 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 タイムアウト
<a name="wlm-timeout"></a>

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\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) システムテーブルを参照してください。COPY ステートメントとメンテナンスオペレーション (ALTER、ANALYZE、VACUUM など) は、WLM タイムアウトの対象ではありません。

WLM タイムアウトの機能は、[statement\$1timeout](r_statement_timeout.md) 設定パラメータと似ています。相違点は、`statement_timeout` 設定パラメータがクラスター全体に適用されるのに対して、WLM タイムアウトは WLM 設定の単一のキューに固有であることです。

[statement\$1timeout](r_statement_timeout.md) も指定されている場合、statement\$1timeout および WLM タイムアウト (max\$1execution\$1time) の低い方が使用されます。

## クエリのモニタリングルール
<a name="wlm-query-monitoring-rules"></a>

クエリモニタリングルールは、WLM キューのメトリクスベースのパフォーマンスの境界を定義し、クエリがこれらの境界を超えた場合のアクションを指定します。例えば、実行時間の短いクエリ専用のキューには、60 秒以上実行されるクエリをキャンセルするルールを作成できます。デザインの不十分なクエリを追跡する目的で、ネステッドループを含むクエリを記録する別のルールを設定することができます。詳細については、「[WLM クエリモニタリングルール](cm-c-wlm-query-monitoring-rules.md)」を参照してください。

# WLM クエリキューのホッピング
<a name="wlm-queue-hopping"></a>

Amazon Redshift では、WLM (ワークロード管理) のクエリキューホッピングを有効にすることで、ワークロードの同時実行とリソース割り当てを管理できます。この機能を使用すると、リソースが利用可能になったときに、割り当てられたキューから優先度の高いキューに一時的に「ホップ」するクエリが可能になり、全体的なクエリパフォーマンスとシステム使用率が向上します。以下のセクションでは、Amazon Redshift での WLM クエリキューホッピングの設定と使用に関する詳細なガイダンスを提供します。

クエリは、[WLM タイムアウト](cm-c-defining-query-queues.md#wlm-timeout)または[クエリモニタリングルール (QMR) のホップアクション](cm-c-wlm-query-monitoring-rules.md#cm-c-wlm-defining-query-monitoring-rules)に基づいてホップされる場合があります。クエリは、手動 WLM 設定でのみホップできます。

クエリがホップされると、WLM は、[WLM キュー割り当てルール](cm-c-wlm-queue-assignment-rules.md)に基づき、次に一致するキューへのクエリのルーティングを試みます。クエリが他のいずれのキュー定義とも一致しない場合、クエリはキャンセルされます。クエリはデフォルトキューに割り当てられません。

## WLM タイムアウトのアクション
<a name="wlm-queue-hopping-summary"></a>

次の表は、WLM タイムアウト時におけるクエリのタイプ別の動作をまとめたものです。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/wlm-queue-hopping.html)

## WLM タイムアウトキューのホッピング
<a name="wlm-timeout-queue-hopping"></a>

WLM は、以下のタイプのクエリをタイムアウト時にホップします。
+ WLM 状態が `running` の、SELECT ステートメントなどの読み取り専用クエリ。クエリの WLM 状態を確認するには、[STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) システムテーブルで STATE 列を表示します。
+ CREATE TABLE AS (CTAS) ステートメント。WLM キューのホッピングでは、ユーザー定義とシステム生成の両方の CTAS ステートメントがサポートされます。
+ SELECT INTO ステートメント。

WLM タイムアウトの対象でないクエリは、完了するまで元のキューで実行を継続します。以下のタイプのクエリは、WLM タイムアウトの対象外です。
+ COPY ステートメント
+ メンテナンスオペレーション (ALTER、ANALYZE、VACUUM など)
+ WLM 状態が `returning` になった、SELECT ステートメントなどの読み取り専用クエリ。クエリの WLM 状態を確認するには、[STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) システムテーブルで STATE 列を表示します。

WLM タイムアウトによるホッピングの対象でないクエリは、タイムアウト時にキャンセルされます。以下のタイプのクエリは、WLM タイムアウトによるホッピングの対象外です。
+ INSERT、UPDATE、および DELETE ステートメント
+ UNLOAD ステートメント
+ ユーザー定義関数 (UDF)

## WLM タイムアウト時のクエリの再割り当てと再開
<a name="wlm-timeout-reassigned-and-restarted-queries"></a>

クエリがホップされ一致するキューが見つからない場合、クエリはキャンセルされます。

クエリがホップされ一致するキューが見つかった場合、WLM は新しいキューへのクエリの再割り当てを試みます。クエリを再割り当てすることができない場合は、以下に説明するように、クエリが新しいキューで再開されます。

クエリは以下のすべての条件が満たされた場合にのみ再割り当てされます。
+ 一致するキューが見つかった。
+ 新しいキューに、クエリを実行できる十分な空きスロットがある。[wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) パラメータが 1 以上の値に設定されている場合、クエリに複数のスロットが必要になる場合があります。
+ 新しいキューのメモリ量が、クエリが現在使用しているメモリ量と少なくとも同じである。

再割り当てされたクエリは、新しいキューで実行を継続します。中間の結果は保持されるため、合計実行時間に対する影響は最小限です。

再割り当てできないクエリはキャンセルされ、新しいキューで再開されます。中間の結果は削除されます。クエリはキュー内で待機し、十分なスロット数が利用可能になると実行を開始します。

## QMR ホップアクション
<a name="qmr-hop-action-queue-hopping"></a>

次の表は、クエリタイプ別に QMR ホップアクションに基づく動作をまとめたものです。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/wlm-queue-hopping.html)

QMR によってホップされたクエリが再割り当て、再開、またはキャンセルされるかどうかを確認するには、[STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md) システムログテーブルにクエリを実行します。

## QMR ホップアクションによるクエリの再割り当てと再開
<a name="qmr-hop-action-reassigned-and-restarted-queries"></a>

クエリがホップされ一致するキューが見つからない場合、クエリはキャンセルされます。

クエリがホップされ一致するキューが見つかった場合、WLM は新しいキューへのクエリの再割り当てを試みます。クエリを再割り当てすることができない場合は、以下に説明するように、クエリが新しいキューで再開されるか、元のキューで実行を継続します。

クエリは以下のすべての条件が満たされた場合にのみ再割り当てされます。
+ 一致するキューが見つかった。
+ 新しいキューに、クエリを実行できる十分な空きスロットがある。[wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) パラメータが 1 以上の値に設定されている場合、クエリに複数のスロットが必要になる場合があります。
+ 新しいキューのメモリ量が、クエリが現在使用しているメモリ量と少なくとも同じである。

再割り当てされたクエリは、新しいキューで実行を継続します。中間の結果は保持されるため、合計実行時間に対する影響は最小限です。

再割り当てできないクエリは、再開されるか元のキューで実行を継続します。クエリが再開される場合、そのクエリはキャンセルされ、新しいキューで再開されます。中間の結果は削除されます。クエリはキュー内で待機し、十分なスロット数が利用可能になると実行を開始します。

# チュートリアル: 手動ワークロード管理 (WLM) キューの設定
<a name="tutorial-configuring-workload-management"></a>

Amazon Redshift では、手動ワークロード管理 (WLM) キューを設定して、さまざまなタイプのクエリやユーザーにリソースを優先して割り当てることができます。手動 WLM キューを使用すると、特定のキューに対するメモリと同時実行設定を制御できるため、優先度の低いクエリがシステムを占有するのを防ぎながら、重要なワークロードが必要なリソースを確実に得ることができます。以下のセクションでは、ワークロード管理要件を満たすために Amazon Redshift で手動 WLM キューを作成および設定するプロセスについて説明します。

## 概要
<a name="tutorial-wlm-overview"></a>

Amazon Redshift では自動ワークロード管理 (WLM) を設定することをお勧めします。自動 WLM の詳細については、「[ワークロード管理](cm-c-implementing-workload-management.md)」を参照してください。ただし、複数の WLM キューを必要とする場合のために、このチュートリアルでは、Amazon Redshift で手動ワークロード管理 (WLM) を設定するプロセスについて説明します。手動 WLM を設定することで、クラスターのクエリパフォーマンスとリソース割り当てを改善できます。

Amazon Redshift はユーザークエリをキューにルーティングして処理します。WLM は、クエリがキューにルーティングされる方法を定義します。デフォルトで、Amazon Redshift にはクエリに使用できるキューが 2 つあります。1 つはスーパーユーザー用で、もう 1 つはユーザー用です。スーパーユーザーキューは設定ができず、一度に 1 つのクエリしか処理できません。このキューはトラブルシューティング目的のみに使用してください。ユーザーキューは最大 5 件のクエリを一度に処理できますが、必要に応じてキューの同時実行レベルを変更することで、この件数を設定できます。

データベースに対して数人のユーザーがクエリを実行する場合は、別の設定の方が効率的なことがあります。例えば、一部のユーザーが VACUUM のように大量のリソースを使う操作を実行する場合、レポートのようにリソースをあまり使わないクエリに対して悪影響が生じることがあります。このような場合は、キューを追加して、異なるワークロード用に設定することを検討してください。

**予測時間:** 75 分

**推定コスト:** 50 セント

### 前提条件
<a name="tutorial-wlm-prereq"></a>

Amazon Redshift クラスター、サンプル TICKIT データベース、Amazon Redshift RSQL クライアントツールが必要です。これらをまだセットアップしていない場合は、「[Amazon Redshift 入門ガイド](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html)」と「[Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html)」を参照してください。

### セクション
<a name="tutorial-wlm-steps"></a>
+ [セクション 1: デフォルトキュー処理の動作の理解](#tutorial-wlm-understanding-default-processing)
+ [セクション 2: WLM のクエリキュー設定の変更](#tutorial-wlm-modifying-wlm-configuration)
+ [セクション 3: ユーザーグループとクエリグループに基づいてクエリをキューにルーティング](#tutorial-wlm-routing-queries-to-queues)
+ [セクション 4: wlm\$1query\$1slot\$1count を使用してキューの同時実行レベルを一時的に変更](#tutorial-wlm-query-slot-count)
+ [セクション 5: リソースのクリーンアップ](#tutorial-wlm-cleaning-up-resources)

## セクション 1: デフォルトキュー処理の動作の理解
<a name="tutorial-wlm-understanding-default-processing"></a>

手動 WLM の設定を開始する前に、Amazon Redshift におけるキュー処理のデフォルト動作を理解しておくと役に立ちます。このセクションでは、いくつかのシステムテーブルから情報を返すデータベースビューを 2 つ作成します。その後、いくつかのテストクエリを実行して、クエリがデフォルトでどのようにルーティングされるかを確認します。システムテーブルの詳細については、「[システムテーブルとビューのリファレンス](cm_chap_system-tables.md)」を参照してください。

### ステップ 1: WLM\$1QUEUE\$1STATE\$1VW ビューを作成する
<a name="tutorial-wlm-create-queue-state-view"></a>

このステップでは、WLM\$1QUEUE\$1STATE\$1VW というビューを作成します。このビューは、次のシステムテーブルから情報を返します。
+ [STV\$1WLM\$1CLASSIFICATION\$1CONFIG](r_STV_WLM_CLASSIFICATION_CONFIG.md)
+ [STV\$1WLM\$1SERVICE\$1CLASS\$1CONFIG](r_STV_WLM_SERVICE_CLASS_CONFIG.md)
+ [STV\$1WLM\$1SERVICE\$1CLASS\$1STATE](r_STV_WLM_SERVICE_CLASS_STATE.md)

チュートリアル全体でこのビューを使用して、WLM 設定の変更後にキューがどうなるかをモニタリングします。次の表は WLM\$1QUEUE\$1STATE\$1VW ビューが返すデータについて説明しています。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/tutorial-configuring-workload-management.html)

#### WLM\$1QUEUE\$1STATE\$1VW ビューを作成するには
<a name="how-to-wlm-create-queue-state-view"></a>

1. [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html) を開き、TICKIT サンプルデータベースに接続します。このデータベースがない場合は、「[前提条件](#tutorial-wlm-prereq)」を参照してください。

1. 次のクエリを実行して、WLM\$1QUEUE\$1STATE\$1VW ビューを作成します。

   ```
   create view WLM_QUEUE_STATE_VW as
   select (config.service_class-5) as queue
   , trim (class.condition) as description
   , config.num_query_tasks as slots
   , config.query_working_mem as mem
   , config.max_execution_time as max_time
   , config.user_group_wild_card as "user_*"
   , config.query_group_wild_card as "query_*"
   , state.num_queued_queries queued
   , state.num_executing_queries executing
   , state.num_executed_queries executed
   from
   STV_WLM_CLASSIFICATION_CONFIG class,
   STV_WLM_SERVICE_CLASS_CONFIG config,
   STV_WLM_SERVICE_CLASS_STATE state
   where
   class.action_service_class = config.service_class 
   and class.action_service_class = state.service_class 
   and config.service_class > 4
   order by config.service_class;
   ```

1. 次のクエリを実行して、ビューに含まれる情報を表示します。

   ```
   select * from wlm_queue_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (querytype:any)                           |     5 | 836 |        0 |  false | false   |      0 |         1 |      160
   ```

### ステップ 2: WLM\$1QUERY\$1STATE\$1VW ビューを作成する
<a name="tutorial-wlm-create-query-state-view"></a>

このステップでは、WLM\$1QUERY\$1STATE\$1VW というビューを作成します。このビューは [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md) システムテーブルから情報を返します。

チュートリアル全体でこのビューを使用して、実行中のクエリをモニタリングします。次の表は WLM\$1QUERY\$1STATE\$1VW ビューが返すデータについて説明しています。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/tutorial-configuring-workload-management.html)

#### WLM\$1QUERY\$1STATE\$1VW ビューを作成するには
<a name="how-to-wlm-create-query-state-view"></a>

1. RSQL で次のクエリを実行して、WLM\$1QUERY\$1STATE\$1VW ビューを作成します。

   ```
   create view WLM_QUERY_STATE_VW as
   select query, (service_class-5) as queue, slot_count, trim(wlm_start_time) as start_time, trim(state) as state, trim(queue_time) as queue_time, trim(exec_time) as exec_time
   from stv_wlm_query_state;
   ```

1. 次のクエリを実行して、ビューに含まれる情報を表示します。

   ```
   select * from wlm_query_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    1249 |     1 |          1 | 2014-09-24 22:19:16 | Executing | 0          | 516
   ```

### ステップ 3: テストクエリを実行する
<a name="tutorial-wlm-run-test-queries"></a>

このステップでは、RSQL で複数の接続からクエリを実行し、システムテーブルを確認して、クエリがどのようにルーティングされて処理されたかを判断します。

このステップでは、RSQL ウィンドウを 2 つ開いておく必要があります。
+ RSQL ウィンドウ 1 では、このチュートリアルで既に作成したビューを使用して、キューとクエリの状態をモニタリングするクエリを実行します。
+ RSQL ウィンドウ 2 では、RSQL ウィンドウ 1 に表示される結果を変更する実行時間が長いクエリを実行します。

#### テストクエリを実行するには
<a name="how-to-wlm-run-test-queries"></a>

1. RSQL ウィンドウを 2 つ開きます。既にウィンドウを 1 つ開いている場合は、2 つ目のウィンドウを開くだけでかまいません。どちらの接続にも同じユーザーアカウントを使用できます。

1. RSQL ウィンドウ 1 で、次のクエリを実行します。

   ```
   select * from wlm_query_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    1258 |     1 |          1 | 2014-09-24 22:21:03 | Executing | 0          | 549
   ```

   このクエリは自己参照的な結果を返します。現在実行中のクエリはこのビューからの SELECT ステートメントです。このビューに対するクエリは少なくとも 1 つの結果を常に返します。次のステップで実行時間が長いクエリを開始した後に表示される結果とこの結果を比較します。

1. RSQL ウィンドウ 2 で、TICKIT サンプルデータベースからクエリを実行します。このクエリは約 1 分間実行されるため、その間に WLM\$1QUEUE\$1STATE\$1VW ビューと以前に作成した WLM\$1QUERY\$1STATE\$1VW ビューの結果を確認できます。場合によっては、クエリの実行時間が短くて両方のビューに対してクエリを実行できないことがあります。このような場合は、`l.listid ` でフィルターの値を増やし、実行時間を延長できます。
**注記**  
クエリの実行時間を短縮し、システムパフォーマンスを向上させるために、Amazon Redshift は特定の種類のクエリの結果をリーダーノード上のメモリにキャッシュします。結果のキャッシュが有効になると、その後のクエリはより高速に実行されます。クエリが高速で実行されることを防ぐには、現行のセッションで結果のキャッシュを無効にします。

   現在のセッションに対する結果のキャッシュをオフにするには、以下にあるとおり、[enable\$1result\$1cache\$1for\$1session](r_enable_result_cache_for_session.md) パラメータを `off` に設定します。

   ```
   set enable_result_cache_for_session to off;
   ```

   RSQL ウィンドウ 2 で、次のクエリを実行します。

   ```
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid < 100000;
   ```

1. RSQL ウィンドウ 1 で、WLM\$1QUEUE\$1STATE\$1VW と WLM\$1QUERY\$1STATE\$1VW をクエリし、その結果を以前の結果と比較します。

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (querytype:any)                           |     5 | 836 |        0 |  false | false   |      0 |         2 |      163
                           
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    1267 |     1 |          1 | 2014-09-24 22:22:30 | Executing | 0          | 684
    1265 |     1 |          1 | 2014-09-24 22:22:36 | Executing | 0          | 4080859
   ```

以前のクエリとこのステップでの結果との間には次の違いがあることに注意してください。
+ 現在は WLM\$1QUERY\$1STATE\$1VW に 2 行あります。1 つの結果は、このビューに対して SELECT 操作を実行する自己参照的クエリです。2 つ目の結果は、以前のステップの長時間実行されるクエリです。
+ WLM\$1QUEUE\$1STATE\$1VW の executing 列の値は、1 から 2 に増えました。この列エントリは、キューで 2 つのクエリが実行中であることを意味します。
+ executed 列の値は、キューのクエリを実行するたびに増加します。

WLM\$1QUEUE\$1STATE\$1VW ビューは、キューの全体像と各キューで処理中のクエリの数を把握するのに便利です。WLM\$1QUERY\$1STATE\$1VW ビューは、現在実行中の個々のクエリについてその詳細を把握するのに便利です。

## セクション 2: WLM のクエリキュー設定の変更
<a name="tutorial-wlm-modifying-wlm-configuration"></a>

キューのデフォルトの仕組みが理解できたため、次は手動 WLM を使用してクエリキューを設定する方法について説明します。このセクションでは、クラスターの新しいパラメータグループを作成して設定します。ユーザーキューを 2 つ追加で作成して、クエリのユーザーグループまたはクエリグループラベルに基づいてクエリを受け付けるように、これらのキューを設定します。この 2 つのキューのどちらにもルーティングされないクエリは、実行時にデフォルトキューにルーティングされます。

**パラメータグループの手動 WLM 設定を作成するには**

1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。

1. ナビゲーションメニューで、**[Configurations]** (設定) を選択し、次に **[Workload management]** (ワークロード管理) を選択して **[Workload management]** (ワークロード管理) ページを表示します。

1. [**作成**] を選択して [**パラメータグループの作成**] ウィンドウを表示します。

1. **[パラメータグループ名]** と **[説明]** の両方で **WLMTutorial** を入力し、**[作成]** をクリックしてパラメータグループを作成します。
**注記**  
[**パラメータグループ名**] は作成時にすべて小文字に変換されます。

1. [**ワークロード管理**] ページで、パラメータグループ **wlmtutorial** を選択し、[**パラメータ**] と [**ワークロード管理**] のタブのある詳細ページを表示します。

1. [**ワークロード管理**] タブを開いていることを確認し、[**Switch WLM mode (WLM モードの切り替え)**] を選択して [**Concurrency settings (同時実行設定)**] ウィンドウを表示します。

1. [**Manual WLM (手動 WLM)**] を選択してから [**保存**] を選択し、手動 WLM に切り替えます。

1. [**Edit workload queues (ワークロードキューの編集)**] を選択します。

1. [**キューの追加**] を 2 度選択して、2 つのキューを追加します。現在 [**キュー 1**]、[**キュー 2**]、[**デフォルトキュー**] の 3つのキューがある状態です。

1. それぞれのキューの情報を次のように入力します。
   + **[Queue 1]** (キュー 1) では、**[Memory (%)]** (メモリ (%)) に **30**、**[Concurrency on main]** (メインの同時実行性)に **2**、**[Query groups]** (クエリグループ) に **test** を入力します。その他の設定はデフォルト値のままにしておきます。
   + **[Queue 2]** (キュー 2) では、**[Memory (%)]** (メモリ (%)) に **40**、**[Concurrency on main]** (メインの同時実行性) に **3**、**[User groups]** (ユーザーグループ) に **admin** を入力します。その他の設定はデフォルト値のままにしておきます。
   + デフォルトキューの **[メインでの同時実行]** を 1 以上の値に設定します。**[デフォルトキュー]** は変更しないでください。WLM は、未割り当てのメモリをデフォルトキューに割り当てます。

1. 設定を保存するには [**保存**] を選択します。

次に、手動 WLM 設定を持つパラメータグループをクラスターに関連付けます。

**パラメータグループをクラスターの手動 WLM 設定に関連付けるには**

1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。

1. ナビゲーションメニューから **[Clusters]** (クラスター) を選択し、次に **[Clusters]** (クラスター) を選択してクラスターのリストを表示します。

1. クラスターの詳細を表示するには、`examplecluster` などのクラスターを選択します。次に、**[Properties]** (プロパティ) タブを選択して、そのクラスターのプロパティを表示します。

1. **[Database configurations]** (データベース構成) セクションで、**[Edit]** (編集)、**[Edit parameter group]** (パラメータグループの編集) を選択して、パラメータグループのウィンドウを表示します。

1. **[Parameter groups]** (パラメータグループ) で、以前に作成した **wlmtutorial** パラメータグループを選択します。

1. **[Save changes]** (変更を保存) を選択して、パラメータグループを関連付けます。

   クラスターは変更されたパラメータグループで変更されます。ただし、変更をデータベースにも適用するには、クラスターを再起動する必要があります。

1. クラスターを選択してから、**[Actions]** (アクション) の **[Reboot]** (再起動) を選択します。

クラスターが再起動されると、ステータスは [**利用可能**] に戻ります。

## セクション 3: ユーザーグループとクエリグループに基づいてクエリをキューにルーティング
<a name="tutorial-wlm-routing-queries-to-queues"></a>

クラスターを新しいパラメータグループに関連付けて WLM を設定しました。次に、いくつかのクエリを実行して Amazon Redshift がどのようにクエリをキューにルーティングして処理するかを確認します。

### ステップ 1: データベースのクエリキュー設定を表示する
<a name="tutorial-wlm-view-query-config"></a>

まず、データベースに WLM が正常に設定されていることを確認します。

#### クエリキュー設定を表示するには
<a name="how-to-wlm-view-query-config"></a>

1. RSQL を開き、次のクエリを実行します。クエリは「[ステップ 1: WLM\$1QUEUE\$1STATE\$1VW ビューを作成する](#tutorial-wlm-create-queue-state-view)」で作成した WLM\$1QUEUE\$1STATE\$1VW ビューを使用します。クラスターを再起動する前にセッションをデータベースに接続済みである場合は、再接続する必要があります。

   ```
   select * from wlm_queue_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        0
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        0
   ```

   この結果を、「[ステップ 1: WLM\$1QUEUE\$1STATE\$1VW ビューを作成する](#tutorial-wlm-create-queue-state-view)」で受け取った結果と比較します。キューが 2 つ追加されていることがわかります。キュー 1 は test クエリグループのキューになり、キュー 2 は admin ユーザーグループのキューになっています。

   キュー 3 はデフォルトキューになっています。リストの最後のキューは常にデフォルトキューです。これは、クエリでユーザーグループやクエリグループが指定されていない場合、デフォルトでクエリがルーティングされる先のキューです。

1. 次のクエリを実行して、クエリがキュー 3 で実行されることを確認します。

   ```
   select * from wlm_query_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2144 |     3 |          1 | 2014-09-24 23:49:59 | Executing | 0          | 550430
   ```

### ステップ 2: クエリグループキューを使ってクエリを実行する
<a name="tutorial-wlm-query-group"></a>

#### クエリグループキューを使ってクエリを実行するには
<a name="how-to-wlm-query-group"></a>

1. 次のクエリを実行して、クエリを `test` クエリグループにルーティングします。

   ```
   set query_group to test;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. 他の RSQL ウィンドウから、次のクエリを実行します。

   ```
   select * from wlm_query_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2168 |     1 |          1 | 2014-09-24 23:54:18 | Executing | 0          | 6343309
    2170 |     3 |          1 | 2014-09-24 23:54:24 | Executing | 0          | 847
   ```

   クエリは、test クエリグループ (今はキュー 1) にルーティングされました。

1. キューの状態表示ですべてを選択します。

   ```
   select * from wlm_queue_state_vw;
   ```

   次のような結果が表示されます。

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         1 |        0
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        0
   ```

1. 今度は、クエリグループをリセットして、実行時間が長いクエリを再び実行します。

   ```
   reset query_group;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. ビューに対するクエリを実行して、結果を確認します。

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        1
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         2 |        5
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2186 |     3 |          1 | 2014-09-24 23:57:52 | Executing | 0          | 649
    2184 |     3 |          1 | 2014-09-24 23:57:48 | Executing | 0          | 4137349
   ```

   結果として、クエリが今は再びキュー 3 で実行されています。

### ステップ 3: データベースユーザーとグループを作成する
<a name="tutorial-wlm-create-db-user-and-group"></a>

このキューでクエリを実行する前に、データベースにユーザーグループを作成して、このユーザーグループにユーザーを追加する必要があります。次に、新しいユーザーの認証情報を使って RSQL にログインして、クエリを実行します。データベースユーザーを作成するには、管理ユーザーのようなスーパーユーザーとしてクエリを実行する必要があります。

#### 新しいデータベースユーザーとユーザーグループを作成するには
<a name="how-to-wlm-create-db-user-and-group"></a>

1. RSQL ウィンドウで次のコマンドを実行して、データベースに `adminwlm` という名前の新しいデータベースユーザーを作成します。

   ```
   create user adminwlm createuser password '123Admin';
   ```

1. 続いて、次のコマンドを実行して、新しいユーザーグループを作成し、新しい `adminwlm` ユーザーをそのユーザーグループに追加します。

   ```
   create group admin;
   alter group admin add user adminwlm;
   ```

### ステップ 4: ユーザーグループキューを使ってクエリを実行する
<a name="tutorial-wlm-user-group-query"></a>

次に、クエリを実行し、それをユーザーグループキューにルーティングします。これを行うのは、実行するクエリのタイプを処理するように設定されたキューにクエリをルーティングする場合です。

#### ユーザーグループキューを使ってクエリを実行するには
<a name="how-to-wlm-user-group-query"></a>

1. RSQL ウィンドウ 2 で、次のクエリを実行して、`adminwlm` アカウントに切り替え、そのユーザーとしてクエリを実行します。

   ```
   set session authorization 'adminwlm';
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. RSQL ウィンドウ 1 で、次のクエリを実行して、クエリがルーティングされるクエリキューを確認します。

   ```
   select * from wlm_query_state_vw;
   select * from wlm_queue_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        1
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        8
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2202 |     2 |          1 | 2014-09-25 00:01:38 | Executing | 0          | 4885796
    2204 |     3 |          1 | 2014-09-25 00:01:43 | Executing | 0          | 650
   ```

   このクエリが実行されたキューはキュー 2 (`admin` ユーザーキュー) です。このユーザーとしてログインしてクエリを実行すると、別のクエリグループを指定しない限り、クエリは常にキュー 2 で実行されます。選択されるキューは、キューの割り当てルールによって異なります。詳細については、「[WLM キュー割り当てルール](cm-c-wlm-queue-assignment-rules.md)」を参照してください。

1. 次に、RSQL ウィンドウ 2.から次のクエリを実行します。

   ```
   set query_group to test;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. RSQL ウィンドウ 1 で、次のクエリを実行して、クエリがルーティングされるクエリキューを確認します。

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         1 |        1
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        1
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       10
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2218 |     1 |          1 | 2014-09-25 00:04:30 | Executing | 0          | 4819666
    2220 |     3 |          1 | 2014-09-25 00:04:35 | Executing | 0          | 685
   ```

1. 処理が完了したら、クエリグループをリセットします。

   ```
   reset query_group;
   ```

## セクション 4: wlm\$1query\$1slot\$1count を使用してキューの同時実行レベルを一時的に変更
<a name="tutorial-wlm-query-slot-count"></a>

ときどき、特定のクエリのために一時的にリソースが余分に必要になることがあります。その場合は、wlm\$1query\$1slot\$1count 設定を使って、クエリキューでスロットが割り当てられる方法を一時的に変更することができます。*スロット*は、クエリを処理するために使用されるメモリと CPU の単位です。データベースで VACUUM 操作を実行する場合など、クラスターのリソースを大量に使用するクエリをたまに実行する場合に、スロット数を一時的に変更できます。

クエリのタイプによっては、ユーザーが wlm\$1query\$1slot\$1count を設定することが必要になる場合があります。そのような場合は、WLM 設定を調整し、クエリのニーズにより適したキューをユーザーに提供することを検討します。スロット数を使用して同時実行レベルを一時的に変更する方法の詳細については、「[wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md)」を参照してください。

### ステップ 1: wlm\$1query\$1slot\$1count を使用して同時実行レベルを一時的に変更する
<a name="tutorial-wlm-override-slot-count"></a>

このチュートリアルの目的に合わせて、実行時間が長い同じ SELECT クエリを実行します。そのクエリは `adminwlm` ユーザーとして実行し、wlm\$1query\$1slot\$1count を使ってクエリで使用可能なスロット数を増やします。

#### wlm\$1query\$1slot\$1count を使用して同時実行レベルを一時的に変更するには
<a name="how-to-wlm-override-slot-count"></a>

1. クエリの制限を増やして、WLM\$1QUERY\$1STATE\$1VW ビューをクエリして結果を確認する時間を十分に確保します。

   ```
   set wlm_query_slot_count to 3; 
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. ここで、管理者ユーザーを使用して WLM\$1QUERY\$1STATE\$1VW にクエリを実行し、クエリの動作を確認します。

   ```
   select * from wlm_query_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2240 |     2 |          1 | 2014-09-25 00:08:45 | Executing | 0          | 3731414
    2242 |     3 |          1 | 2014-09-25 00:08:49 | Executing | 0          | 596
   ```

   クエリのスロット数が 3 であることがわかります。この数は、クエリが 3 つのスロットをすべて使ってクエリを処理していること、キューのリソースがすべてそのクエリに割り当てられていることを意味します。

1. 今度は、次のクエリを実行します。

   ```
   select * from WLM_QUEUE_STATE_VW;
   ```

   結果の例は次のとおりです。

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        4
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        3
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       25
   ```

   wlm\$1query\$1slot\$1count 設定は、現在のセッションに対してのみ有効です。そのセッションが期限切れになった場合、または、別のユーザーがクエリを実行する場合は、WLM 設定が使用されます。

1. スロット数をリセットして、テストを再実行します。

   ```
   reset wlm_query_slot_count;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

   結果の例は次のとおりです。

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        2
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        2
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       14
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2260 |     2 |          1 | 2014-09-25 00:12:11 | Executing | 0          | 4042618
    2262 |     3 |          1 | 2014-09-25 00:12:15 | Executing | 0          | 680
   ```

### ステップ 2: 別のセッションからクエリを実行する
<a name="tutorial-wlm-run-queries-from-different-sessions"></a>

次に、別のセッションからクエリを実行します。

#### 別のセッションからクエリを実行するには
<a name="how-to-wlm-run-queries-from-different-sessions"></a>

1. RSQL ウィンドウ 1 および 2 で、次を実行して、テストクエリグループを使用します。

   ```
   set query_group to test;
   ```

1. RSQL ウィンドウ 1 で、実行時間が長い次のクエリを実行します。

   ```
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. RSQL ウィンドウ 1 で実行時間が長いクエリがまだ進行中の間に、以下を実行します。これらのコマンドは、キューのすべてのスロットを使用するようにスロット数を増やした後で、実行時間が長いクエリの実行を開始します。

   ```
   set wlm_query_slot_count to 2;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. 3 つ目の RSQL ウィンドウを開いて、ビューをクエリし、結果を確認します。

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   結果の例は次のとおりです。

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      1 |         1 |        2
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        3
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       18
    
   query | queue | slot_count | start_time          | state         | queue_time | exec_time
   ------+-------+------------+---------------------+---------------+------------+-----------
    2286 |     1 |          2 | 2014-09-25 00:16:48 | QueuedWaiting | 3758950    | 0
    2282 |     1 |          1 | 2014-09-25 00:16:33 | Executing     | 0          | 19335850
    2288 |     3 |          1 | 2014-09-25 00:16:52 | Executing     | 0          | 666
   ```

   最初のクエリではキュー 1 に割り当てられたスロットの 1 つを使用してクエリを実行していることに注意してください。さらに、キュー内で待機しているキューが 1 つあることにも注意してください (`queued` が `1`、`state` が `QueuedWaiting`)。最初のクエリが完了すると、2 つ目のクエリの実行が開始されます。このように実行されるのは、両方のクエリが `test` クエリグループにルーティングされていて、2 つ目のクエリは十分なスロット数が使用可能になるまで処理の開始を待機する必要があるためです。

## セクション 5: リソースのクリーンアップ
<a name="tutorial-wlm-cleaning-up-resources"></a>

クラスターが実行されている限り料金が発生し続けます。このチュートリアルを完了したら、*Amazon Redshift 入門ガイド*の「[ステップ 8: 環境をリセットする](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-clean-up-tasks.html)」のステップに従って、環境を以前の状態に戻します。

WLM の詳細については、「[ワークロード管理](cm-c-implementing-workload-management.md)」を参照してください。