自動 WLM を使用して Amazon Redshift のワークロードを管理するにはどうすればよいですか?

最終更新日: 2020 年 10 月 15 日

さまざまなワークロードがあり、自動ワークロード管理 (WLM) を使用して別々のキューを作成したいと考えています。Amazon Redshift の自動 WLM を使用してワークロードを管理および優先順位付けするにはどうすればよいですか?

簡単な説明

Amazon Redshift の自動 WLM は、メモリと同時実行性を動的に管理し、さまざまなワークロードのクエリに優先順位を付けるのに役立ちます。自動 WLM を使用することにより、Amazon Redshift は次の条件に従ってリソース割り当てを管理します。

  • クエリが Amazon Redshift に送信されると、リソースはクエリ優先順位に従って割り当てられます。
  • 競合するワークロードがない場合、優先順位の低いクエリはすべてのシステムリソースにアクセスできます。
  • 同時ワークロードの場合、優先順位の高いクエリが選択されます。優先順位の高いクエリには、優先順位の低いクエリよりも多くのリソースが割り当てられます。
  • 優先順位の高いワークロードの予測可能なパフォーマンスは、他の優先順位の低いワークロードを犠牲にしています。
    注: 優先順位の低いクエリは、遅いペースで進行する可能性があります。しかし、Amazon Redshift では、優先順位の低いクエリが実行されないことがないようにします。
  • 優先順位の低いワークロードは、優先順位のステータスまたは少ないリソースでの作業が原因で、実行時間がより長くなることがあります。

Amazon Redshift の自動 WLM を効果的に使用するには、次の点を考慮してください。

  • キューに優先順位を割り当てます。
  • クエリの優先順位を変更します。
  • クエリの優先順位を監視します。
  • 割り当てられた優先順位に従ってクエリが実行されているかどうかを確認します。

解決方法

キューへの優先順位の割り当て

自動 WLM を使用してワークロードを管理するには、次の手順を実行します。

1.    ワークロードを定義し、カテゴリ (ETL、ダッシュボード、分析など) に分離します。

2.    個々のユーザーを識別し、ワークロードに応じてグループ化します。

3.    特定のユーザーまたはクエリグループに異なるキューを作成して割り当てます。詳細については、キューへのクエリの割り当てを参照してください。

4.    キューの同時実行スケーリングを有効にして、Amazon Redshift が必要に応じて自動的にクラスター容量を追加するようにします。たとえば、トラフィックにバーストが発生する傾向がある場合に、キューの同時実行スケーリングを有効にできます。詳細については、同時実行スケーリングキューを設定するを参照してください。

自動 WLM 用の JSON 設定例を次に示します。

[ {
  "query_group" : [ ],
  "query_group_wild_card" : 0,
  "user_group" : [ "ETL_users" ],
  "user_group_wild_card" : 1,
  "priority" : "highest",
  "queue_type" : "auto",
  "auto_wlm" : true    
}, {
  "query_group" : [ ],
  "query_group_wild_card" : 0,
  "user_group" : [ "Dashboard_users" ],
  "user_group_wild_card" : 0,
  "priority" : "high",
  "queue_type" : "auto",
  "auto_wlm" : true
}, {
  "query_group" : [ "Adhoc_query" ],
  "query_group_wild_card" : 1,
  "user_group" : [ "Analytics_users" ],
  "user_group_wild_card" : 1,
  "priority" : "normal",
  "queue_type" : "auto",
  "auto_wlm" : true
}, {
  "query_group" : [ ],
  "query_group_wild_card" : 0,
  "user_group" : [ ],
  "user_group_wild_card" : 0,
  "priority" : "low",
  "queue_type" : "auto",
  "auto_wlm" : true
}, {
  "short_query_queue" : true
} ]

注: クエリの優先順位を設定しない場合、すべてのキューは自動的に「通常」の優先順位ステータスに設定されます。

クエリの優先順位の変更

Amazon Redshift では、WLM クエリ監視ルール (QMR) または組み込み関数を使用して、キューの優先順位を変更できます。

方法 1: WLM クエリ監視ルール

メトリクスベースのパフォーマンス境界に従ってワークロードを管理する場合は、WLM クエリ監視ルールを使用します。WLM クエリ監視ルールを設定するときは、クエリ優先順位メトリクスとクエリ優先順位アクションを指定します。例:

{
  "query_group" : [ ],
  "query_group_wild_card" : 0,
  "user_group" : [ ],
  "user_group_wild_card" : 0,
  "rules" : [ {
    "rule_name" : "long_running_queries",
    "predicate" : [ {
      "metric_name" : "query_execution_time",
      "operator" : ">",
      "value" : 3600
    } ],
    "action" : "change_query_priority",
    "value" : "high"
  } ],
  "priority" : "low",
  "queue_type" : "auto",
  "auto_wlm" : true
}, {
  "short_query_queue" : true
} ]

方法 2: 組み込み関数

重要: 組み込み関数には適切なアクセス許可が必要です。組み込み関数を使用するには、スーパーユーザーであるか、スーパーユーザーから組み込み関数を使用するためのアクセス許可が付与されている必要があります。

Amazon Redshift では、組み込み関数は WLM 設定に依存しません。組み込み関数を使用するためのアクセス許可を標準ユーザーに付与するには、SECURITY DEFINER を指定するストアドプロシージャを作成します。その後に、標準ユーザーにアクセス許可を付与します。

スーパーユーザーは、次の組み込み関数を使用してクエリ優先順位を変更できます。

注: 「重大」の優先順位ステータスは、組み込み関数を使用してのみ割り当てることができます。どのような場合であっても、システム内では 1 つの重大なクエリのみが許可されます。

クエリ優先順位の監視

キューまたはアクティブなクエリのクエリ優先順位を確認するには、次のクエリを実行します。

select query, service_class, query_priority, state from stv_wlm_query_state where service_class>=100;

完了したクエリのクエリ優先順位をチェックするには、次のクエリを使用します。

select query, service_class, service_class_start_time as starttime, query_priority
from stl_wlm_query where query=<query_id>;

QMR ルールのためにクエリ優先順位が変更されたかどうかを確認するには、次のクエリを使用します。

select * from stl_wlm_rule_action where query= <Query_ID> and action= ‘change_query_priority’;

出力の action_value 列で、クエリの変更された優先順位を確認します。

QMR 設定を確認するには、次のクエリを実行します。

select * from stv_wlm_QMR_config where action= ‘change_query_priority’;

query_group パラメータの現在の値を確認するには、次のクエリを実行します。

select current_setting(‘query_group’);

自動 WLM キュー設定を確認するには、次のクエリを実行します。

select s.service_class,
rtrim(s.name) as name, s.num_query_tasks as slots, s.query_working_mem as mem, s.max_execution_time as max_time, s.user_group_wild_card as user_wildcard, s.query_group_wild_card as query_wildcard,
rtrim(c.condition) as condition, s.query_priority from stv_wlm_service_class_config s left join stv_wlm_classification_config c on s.service_class = c.action_service_class where s.service_class > 4 order by service_class;

注: auto_wlm が有効で「true」に設定されている場合、サービスクラス ID は 100-107 を示します。 num_query_tasks および query_working_mem 列は、値 -1 も示します。

割り当てられた優先順位に従ってクエリが実行されているかどうかの確認

クエリは、割り当てられた優先順位、クエリ監視ルール、およびユーザーグループとクエリグループの照合ワイルドカードに基づいて、キューにルーティングされます。その後、Amazon Redshift は、最初に一致するキューにクエリを自動的に割り当てます。

クエリが目的のキューで実行されない場合は、次の条件が充足されているかを確認します。

  • ユーザーまたは query_group が「superuser」に設定されている場合: ユーザーまたはクエリグループが「superuser」に設定されている場合、クエリはスーパーユーザーキュー (service_class = 5) で実行されます。
  • ユーザーはユーザーグループのメンバーとしてリストされていますが、その特定のクエリには別のクエリグループが割り当てられています。クエリがリストされたグループメンバーシップとは異なるクエリグループに割り当てられている場合、クエリは最初に一致するキューで実行されます。デフォルトでは、Amazon Redshift のクエリは、キューの設定された優先順位に従って実行されます。
  • 組み込み関数を使用するための不適切なアクセス許可: 組み込み関数 (CHANGE_QUERY_PRIORITYCHANGE_USER_PRIORITYCHANGE_QUERY_PRIORITY など) を使用している場合は、スーパーユーザー権限が必要です。あるいは、スーパーユーザーから組み込み関数を使用するための適切なアクセス許可が付与されている必要があります。
  • ユーザーが複数のグループのメンバーである: 複数のグループのメンバーとしてリストされている場合、クエリは最初に一致するキューに割り当てられます。キューの一致は、WLM クエリ割り当てルールに従って実行されます。

クエリ優先順位が正常に変更されたかどうかを確認するには、次のクエリを実行します。

select query, service_class, query_priority, state from stv_wlm_query_state where query= <Query_ID>;

ユーザーが複数のグループのメンバーとしてリストされているかどうかを確認するには、次のクエリを実行します。

SELECT usename, groname
FROM pg_user, pg_group
WHERE pg_user.usesysid = ANY(pg_group.grolist)
AND pg_group.groname in (SELECT DISTINCT pg_group.groname from pg_group);

クエリグループがクエリに設定されているかどうかを識別するには、次のクエリを実行します。

select q.userid, q.query, rtrim(q.label) as label, w.service_class, w.query_priority from stl_query q join stl_wlm_query w on q.query = w.query where q.query = <Query_ID>;

出力の label 列で、クエリのグループメンバーシップを確認します。クエリに一致するクエリまたはユーザーグループがない場合は、既定のキューで実行されます。</p


この記事はお役に立ちましたか?


請求に関するサポートまたは技術サポートが必要ですか?