Amazon Redshift DB開発者ガイド – クエリパフォーマンスチューニング(3).ワークロード管理の実装

Amazon Redshift DB開発者ガイド

#データベース

#Amazon Redshift

#AWS

しんや

2013.08.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amazon Redshiftには、復数のクエリキューを定義し、実行時にクエリを適切なキューで走らせる事が出来るワークロード管理(WLM:Workload Management)というものがあります。

実行時間の長いクエリは、パフォーマンスのボトルネックになる事があります。例えば、あるデータウェアハウスで、ユーザーが2つのグループを持っているとします。1つのグループは、幾つかの大規模なテーブルから行を選択し、並べ替え、時折実行時間の長いクエリを送信します。2つ目のグループは頻繁に1〜2つのテーブルから少数の行を選択し、数秒で終るような実行時間の短いクエリを送信します。この状況では、実行時間の短いクエリは長く実行時間の掛かるクエリが完了するまで待機する必要が出て来ます。

実行時間の長いクエリ及び短いクエリに対する個別のキューを作成する際、WLM構成を変更する事により、システムのパフォーマンスとユーザーエクスペリエンスを向上させる事が出来ます。実行時には、クエリをキューに割り当てる事はユーザーグループまたはクエリグループに応じて対応する事が出来ます。

クエリキューの定義

デフォルトでは、1つのキューで構成されているクラスタはクラスタは同時に5つのクエリを実行する事が出来ます。また、Amazon Redshiftはクラスタ上に1つの専用スーパーユーザーキューを確保しています。スーパーユーザーキューは設定変更は行えません。

注意：
スーパーユーザーキューの主な目的はトラブルシューティングを支援する事です。
ルーチンのクエリを実行する為に使うべきものではありません。

スーパーユーザーキューに加えて8つのクエリキューを定義する為に、クラスタのWLM構成を変更出来ます。実行時には、Amazon Redshiftはユーザグループとクエリグループに基づいてキューにクエリを割り当てます。ユーザーグループとクエリグループにクエリを割り当てる方法の詳細については、Assigning queries to queuesをご参照ください。

各キューに対して、以下の内容を設定します。

同時実行レベル(Concurrency level)
ユーザーグループ(User groups)
クエリグループ(Query groups)
ワイルドカード(Wildcards)
WLMタイムアウト(WLM timeout)

同時実行レベル(Concurrency level)

キュー内のクエリーは、キューに対して定義された同時実行レベルに達するまで同時に稼働します。後続のクエリは、キューで待機しています。各キューは、同時に15のクエリまで実行するように構成出来ます。予約されているスーパーユーザーキューを除き、全てのユーザー定義キューの最大合計同時実行レベルは15です。Amazon Redshiftはキュー内の各クエリのスロットに等しく、固定のメモリシェアを割り当てます。

ユーザーグループ(User groups)

キューには、ユーザーグループのカンマ区切りのリストを割り当てる事が出来ます。記載されているユーザーグループのメンバがクエリを実行すると、そのクエリは対応するキューで実行されます。キューに割り当てる事が出来るユーザーグループの数に、設定上限はありません。

クエリグループ(Query groups)

キューにはクエリグループのカンマ区切りのリストを割り当てる事が出来ます。クエリグループは単なるラベルです。実行時には、一連のクエリにクエリグループラベルを割り当てる事が出来ます。記載されているクエリグループに割り当てられているクエリは、対応するキューで実行されます。設定出来るクエリグループの数に上限はありません。

ワイルドカード(Wildcards)

個別に、またはワイルドカードを使用してキューにユーザーグループとクエリグループを割り当てる事が出来ます。例えば、もしdba_*をクエリのユーザーグループに追加した場合、dba_で始まるユーザー名を持つユーザによって実行されるあらゆるクエリががそのキューに割り当てられます。ワイルドカードはデフォルトでは無効になっています。

AWSの管理コンソールでキューのワイルドカードの使用を有効にするには、"ワークロードの管理構成"の"User Group Wildcards"のチェックボックスをonにします。APIまたはCLIを使用してワイルドカードを有効にするには、query_group_wild_cardまたはuser_group_wild_cardの値を1に設定します。

WLMタイムアウト(WLM timeout)

WLMキュー内に与えられたクエリの使用可能な時間の量を制限する為に、各キューのWLMタイムアウト値を設定する事が出来ます。timeoutパラメータはミリ秒単位で時間を設定し、Amazon Redshiftはクエリキャンセル前に実行するためにキュー内のクエリを待ちます。

WLMのタイムアウト機能は、statement_timeout設定に似ています。(statement_timeout設定がクラスタ全体に適用され、WLMタイムアウトが特定の単一キューに適用される、という事を除けばですが)

AWS管理コンソールを使用してWLMタイムアウトパラメータを設定するには、"ワークロード管理の設定"タブに移動し、各キューのタイムアウトフィールドをにミリ秒数を設定します。0を指定するか、空白にするとWLMのタイムアウト設定は無効になります。WLMのタイムアウトはデフォルトで無効となっています。

APIまたはCLIを使用してWLMタイムアウト値を設定するには、max_execution_timeパラメータを使用します。クラスタ用のstatement_timeout設定パラメータを設定するには、クラスタのパラメータグループの構成を変更します。変更するパラメータグループの詳細については、Amazon Redshift Parameter Groupsをご参照ください。

もし、WLMタイムアウト(max_execution_time)とstatement_timeoutの両方が指定されていた場合、より設定値が短い方が使われます。

デフォルトキュー

WLM構成で定義された最後のキューは、デフォルトキューです。デフォルトキューに対し、同時実行レベルとタイムアウト設定は変更する事が出来ますが、ユーザーグループまたはクエリグループを含める事は出来ません。デフォルトのキューは8つのクエリキューの制限と15の同時クエリの制限に対してカウントされます。

スーパーユーザーキュー

スーパーキュー内のクエリを実行するには、ユーザーは、スーパーユーザーとしてログインする必要があり、あらかじめ定義された'superuser'クエリグループ内のクエリを実行する必要があります。

WLMキュー割り当ての規則

ユーザーがクエリを実行すると、WLMはこれらのルールに基いて最初に一致したキューにクエリを割り当てます。

1.ユーザーがスーパーユーザーとしてログインし、'superuser'ラベルのクエリグループでクエリを実行する場合、クエリはスーパーユーザーキューに割り当てられます。
2.ユーザがリストされているユーザー·グループに属している場合、クエリは最初に対応するキューに割り当てられます。
3.ユーザーがリストされクエリグループ内のクエリを実行した場合、クエリは最初に対応するキューに割り当てられます。
4.クエリが、任意の基準を満たしていない場合、クエリはWLM構成で定義された最後のキューであるデフォルトキューに割り当てられます。

以下の表は、スーパーユーザーキューと4つのユーザー定義のキューとWLM構成を示します。

キュー	同時実行数	ユーザーグループ	クエリグループ
Superuser	1		superuser
1	2	user_group_1
2	2		query_group_A
3	4	user_group_2	query_group_B
Default	4

キューの割り当て例

以下の例では、どのようにしてユーザーグループやクエリグループの内容によってクエリがキューに割り当てられているかを示しています。ユーザーグループやクエリグループに対して実行時にクエリを割り当てる方法の詳細については、クエリをキューへ割り当てるをご参照ください。

この例では、ステートメントの最初のセットはユーザーグループにユーザーを割り当てる為の3つの方法を示しています。

ユーザーanalyst1はユーザーグループuser_group_2に属しています。
analyst1によって実行されるクエリはquery_group_Aに属していますが、このクエリはQueue3に割り当てられました。ユーザーグループのチェックがクエリグループのチェックより前に発生したからです。

WLM構成を変更する

クエリキューはWLM構成で定義されています。WLM構成は1つまたは復数のクラスタに関連付ける事が出来る、パラメータグループの編集可能なパラメータ(wlm_json_configuration)です。

WLM構成を作成する最も簡単な方法は、キューのセットを定義するためにAmazon Redshiftの管理コンソールを使用する事です。また、Amazon Redshiftのコマンドラインインタフェース(CLI)やAmazon Redshift APIを使用する事が出来ます。

WLM構成の変更については、Amazon Redshift Parameter Groupsをご参照ください。

注意：
WLM構成を変更した後、クラスタを再起動する必要があります。

クエリをキューへ割り当てる

以下の例では、ユーザーグループとクエリグループに応じてキューにクエリを割り当てています。

ユーザーグループに基づいてキューにクエリを割り当てる

ユーザグループ名がキュー定義に表示されている場合、そのユーザグループのメンバーによって実行されるクエリは、対応するキューに割り当てられます。以下の例では、SQLコマンド：CREATE USER,CREATE GROUP,ALTER GROUPを使いユーザーグループを作成、ユーザーをグループに割り当てています。

create group admin_group with user admin246, admin135, sec555;
create user vp1234 in group ad_hoc_group password 'vpPass1234';
alter group admin_group add user analyst44, analyst45, analyst46;

クエリグループにクエリを割り当てる

適切なクエリグループにクエリを割り当てることによって、実行時にキューに照会を割り当てることができます。クエリグループを開始するには、setコマンドを使用します。

SET query_group TO 'group_label';

'group_labelは' WLM構成にリストされているクエリグループのラベルです。

クエリグループをリセットするか、現在のログインセッションを終了するまでは、SET query_groupコマンドの後に実行するすべてのクエリは、指定されたクエリグループのメンバとして実行されます。Amazon Redshiftのオブジェクトを設定・リセットの詳細については、コマンドリファレンスのSET及びRESETをご参照ください。

指定したクエリグループラベルは、現在のWLM構成に含まれている必要があります。そうでない場合は、SET query_groupコマンドはクエリキューに影響を与える事はありません。

TO句で定義されたラベルは、トラブルシューティングのためにラベルを使用できるように、クエリのログに記録されています。 query_group設定パラメータの詳細については、設定リファレンスのquery_groupをご参照ください。

以下例では、クエリグループ："priority"を設定し、クエリグループをリセットする一環として2つのクエリを実行しています。

set query_group to 'priority';
select count(*)from stv_blocklist;
select query, elapsed, substring from svl_qlog order by query desc limit 5; 
reset query_group;

スーパーユーザーキューにクエリを割り当てる

スーパーユーザーキューに照会を割り当てるには、スーパーユーザーとしてAmazon Redshiftにログインした後、'superuser'グループでクエリを実行します。後続の問合せはスーパーキューに実行しないように作業が完了したら、クエリグループをリセットします。

この例では、スーパーユーザーのキューで実行する2つのコマンドを割り当てています。

set query_group to 'superuser';
analyze;
vacuum; 
reset query_group;

ワークロードの管理の監視

WLMは、内部的に定義されたWLMサービス·クラスに応じてクエリキューを設定します。Amazon Redshiftは、WLM構成で定義されたキューと一緒に、これらのサービス·クラスに応じて、いくつかの内部キューを作成します。ターム(term)キューおよびサービス·クラスは、しばしば、システムテーブルと同義の扱いで使用されます。

WLM固有のシステムテーブルを使用してクエリ、キュー、およびサービスクラスのステータスを表示できます。次の操作を実行するには、以下のシステムテーブルを照会します。

どのクエリが追跡されていて、何のリソースがワークロードマネージャーに割り当てられているかを見ます。
クエリが割り当てられているキューを参照します。
現在のワークロードマネージャーによって追跡されているクエリのステータスを表示します。

テーブル名	詳細
STL_WLM_ERROR	WLM関連のエラーイベントのログが含まれています。
STL_WLM_QUERY	WLMによって追跡されているリストクエリ。
STL_WLM_CLASSIFICATION_CONFIG	WLMの現在の分類ルールを表示します。
STL_WLM_QUERY_QUEUE_STATE	クエリキューの現在の状態を記録します。
STL_WLM_QUERY_STATE	WLMによって追跡されているクエリの現在の状態のスナップショットを提供します。
STL_WLM_QUERY_TASK_STATE	クエリタスクの現在の状態を含みます。
STL_WLM_SERVICE_CLASS_CONFIG	レコードWLMのサービスクラスの設定。
STL_WLM_SERCICE_CLASS_STATE	サービスクラスの現在の状態。

あなたは、システムテーブルにクエリを追跡するためにタスクIDを使用しています。以下の例では、最近送信されたユーザークエリのタスクIDを取得する方法を示しています。

select task from stl_wlm_query where exec_start_time =(select max(exec_start_time) from stl_wlm_query); 

task 
------ 
137 
(1 row)

また以下の例では、現在実行中または様々なサービスクラス（キュー）で待機しているクエリを表示します。このクエリでは、Amazon Redshiftための全体的な同時ロードを追跡するのに便利です。

select * from stv_wlm_query_state order by query;

xid |task|query|service_| wlm_start_  |  state  |queue_ | exec_
    |    |     |class   | time        |         |time   | time
----+----+-----+--------+-------------+---------+-------+--------
2645| 84 | 98  | 3      | 2010-10-... |Returning|   0   | 3438369
2650| 85 | 100 | 3      | 2010-10-... |Waiting  |   0   | 1645879
2660| 87 | 101 | 2      | 2010-10-... |Executing|   0   | 916046
2661| 88 | 102 | 1      | 2010-10-... |Executing|   0   | 13291
(4 rows)

上記例では、4つのクエリを示しています。