Amazon Redshift: WLM(Workload Management)のクエリ同時実行制限値が緩和されました

#Amazon Redshift

#AWS

しんや

2014.04.28

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

先日2014/04/18のRelease Notesにて、Amazon RedshiftのWLM(Workload Management)に於ける同時実行の制限(上限値)を増やせるようになりました。当エントリではその内容について実際に変更してみるなどしてみたいと思います。

Release: Amazon Redshift on 2014-04-18 : Release Notes : Amazon Web Services

クエリキューの定義とは

Amazon Redshiftでは、ユーザー定義のクエリキューで最大50のクエリを同時実行出来るような設定が可能となりました。これにより、ユーザーがWLM構成を変更する事でシステムのパフォーマンス管理に対するより柔軟な対応が行えるようになります。

WLM及び、当エントリでの焦点となる『同時実行数』については以下公式ドキュメントに記載がなされています。

Defining query queues - Amazon Redshift(関連ドキュメント:英語版)
クエリキューの定義 - Amazon Redshift(関連ドキュメント:日本語訳)

クエリキューを含めたWLMについては以下URLからそれぞれ参照可能です。

Implementing workload management - Amazon Redshift(関連ドキュメント:英語版)
ワークロード管理の実装 - Amazon Redshift(関連ドキュメント:日本語訳)

また、このテーマについてはcon_mame(TwitterID:@con_mame)さんがブログでとても分かり易いエントリを書いていますので理解の参考にして頂ければと思います。

デフォルトでは、WLMキューは同時並行処理レベル：5が設定されています。ワークロードでは以下の様な場合、この値をより多いものに設定する事でメリットが得られるかも知れません。

多くの小さなクエリが、重い処理(クエリ実行時間が長く掛かるもの)によって実行を待たされているような場合、同時並行処理レベルが高い(数値の大きい)新たなキューを作成し、そのキューに(待たされている)小さいクエリを割り当てます。同時並行処理レベルが高いキューはそれぞれのクエリスロットに対して割り当てられているメモリは少ないですが、小さなクエリではメモリをそれほど必要としません。
単一スライス上のデータそれぞれにアクセスする複数のクエリがある場合、それらクエリを同時に実行する為に別々にWLMキューを設定します。Amazon Redshiftは複数のクエリを複数のスライス上で並列に実行させるために、それぞれのスライスに対してクエリを割り当てます。

公式ドキュメントで言及されているベストプラクティスとしては、同時並行処理レベルを15以下とする事がオススメされているようです。クラスタ内の全てのコンピュートノード、ノード上の全スライスがクエリの同時並行処理に参加しています。この同時実行性を増加させる事で、システムリソースの競合が増え、全体のスループットが制限されるため、無闇に多い値を設定すれば良い、というものでも無さそう。

各キューに割り当てられているメモリは、そのキュー内のクエリスロット間で分割されます。クエリに対して利用可能となるメモリの量はクエリが実行しているクエリスロットに対して割り当てられたメモリの量となります。これは実際に同時並行処理されているクエリの数には関係ありません。同時並行レベルが5の場合にメモリ内で完全に実行可能となるクエリは、同時並行レベルが20に増加した場合はディスクに中間結果を書き込む必要が出て来るかも知れません。追加で発生するディスクI/Oが、パフォーマンスを低下させる可能性が出てきます。

特定のクエリが、単一のクエリスロットに割り当てられているものよりも多くのメモリを必要とする場合、wlm_query_slot_countパラメータを増やす事によって使用可能なメモリを増やす事が出来ます。以下例では値を10に設定しスロットを増やした後、VACUUM処理を実行。VACUUM処理実行後はその値を1に戻しています。

wlm_query_slot_count - Amazon Redshift

set wlm_query_slot_count to 10; 
vacuum; 
set wlm_query_slot_count to 1;

変更前(デフォルト値)の内容及び挙動の確認

クラスタに紐付くパラメータグループを選択し、WLMタブを開いてみます。確かにデフォルト値である5が設定されていますね。キューも1つのみ存在する形となっています。

そして今回、同時接続確認用に計7人分のDBユーザー・パスワードを用意。そして重めのクエリを発行する操作を同時で実行してみました。実行直後にRedshiftの管理コンソールでクエリの状況を確認してみましょう。見てみると5個までしか表示がされていません。

先行して実行されたクエリが幾つか終了すると、6個目7個目のクエリも表示されてきました。確かにクエリの制御が為されているようです。

パラメータの変更及び反映内容の確認

では今回の本題となる部分に行ってみましょう。先程確認した管理コンソール上のWLMの設定値を変更してみます。これまでは上限値が15だったものが、今回の更新で50に引き上げられました。ここでは試しに25を設定してみます。設定後[Save Changes]を押下。

保存が完了すると、自動的にクラスタに対する反映が始まります。pending-rebootと表示された時点でクラスタの再起動(reboot)を行い、最終的にステータスがavailableとなれば反映完了です。

先程行った同時実行のアクションを再度行ってみます。今度は7人全員分のクエリが一挙に表示されましたね！25人同時はさすがに今回検証するのは断念しましたが(笑)、恐らくこの設定値で25クエリまでの同時実行が可能になっているものと思われます。

まとめ

以上、クエリ同時実行の制御に関してWLM設定値を変更する事で対応が可能となり、またその上限値が引き上げられた事も確認出来ました。BIツールからRedshiftクラスタに対するアクセスについては、分析を行うユーザー(数人想定)だけでなく、クラスタに対して何らかの参照を行うユーザー(数人〜数十人を想定？)経由のアクセスも考えられます。その際にデフォルト値の5のままではケースによっては処理を待たされる場合もありますのでこの値を調整して対応する必要性が出て来るでしょう。今回はクラスタ全体の設定値の上限値変更のみでしたが、WLMではより細やかな設定が行えます。その辺りは公式ドキュメント等を参考にしてみてください。

また、WLMについては、以下STVテーブルで内容を確認出来るようです。必要に応じてご利用下さい。

スナップショットデータの STV テーブル (英語版) (日本語版)
- STV_WLM_CLASSIFICATION_CONFIG (英語) (日本語) ：WLM の現在の分類ルールを表示。
- STV_WLM_QUERY_QUEUE_STATE (英語) (日本語) ：サービスクラスのクエリキューの現在の状態を記録。
- STV_WLM_QUERY_STATE (英語) (日本語) ：WLM に追跡されているクエリの現在の状態を記録。
- STV_WLM_QUERY_TASK_STATE (英語) (日本語) ：サービスクラスクエリタスクの現在の状態を表示。
- STV_WLM_SERVICE_CLASS_CONFIG (英語) (日本語) ：WLM のサービスクラス設定を記録。
- STV_WLM_SERVICE_CLASS_STATE (英語) (日本語) ：サービスクラスの現在の状態を表示。