機械学習を用いた新機能『Amazon Redshift Automatic Workload Management (Auto WLM)』を実際に試してみました
昨年のre:Invent2018で紹介のあった Automatic Workload Management (Auto WLM) は、機械学習アルゴリズムを用いてクラスターのリソースを動的に管理する新機能です。先日、東京リージョンとバージニアリージョンでリリースされたことを確認できましたので、早速試してみました。
Automatic Workload Management (Auto WLM)とは
最初にWorkload Management(WLM)について解説します。Redshift はクライアントからクエリを受信すると、ユーザーに割り当てられたクエリキュー追加、順に取り出してクエリを実行します。このとき、実行時間が短いクエリは、実行時間が長いクエリが完了するまでキューで待機しなければならない場合があり、クラスタ全体のボトルネックになることがあります。Workload Management(WLM)とは、用途ごとにクエリーの並列度やメモリ（％）の上限を設けた複数のキューを設定・管理する機能です。下記の図では、ロングクエリ用とショートクエリ用のクエリグループを作成して、それぞれのキューにユーザーを割り当てます。２つのキューは分離されているため、ショートクエリ用のキューを利用しているユーザーはロングクエリの影響を受けずにすばやく応答を受けられます。
しかし、従来のWLM では、ユーザーがクエリの同時実行数とメモリの割り当てを事前に指定する必要がありました。新しい Automatic Workload Management (Auto WLM) は、機械学習アルゴリズムを用いてクエリを実行するために必要なリソースを動的に管理する機能です。Amazon Redshift は、ディスパッチされたクエリごとに割り当てる同時実行クエリ数とメモリ量を決定します。オプションのクエリ同時実行数やメモリ割り当てをリアルタイムで計算することで、Automatic Workload Management (Auto WLM) はクラスタのワークロードに対して最大のパフォーマンスを提供します。
以降では、従来のWLMを「Manual WLM」、新しいAutomatic Workload Management (Auto WLM)を「Auto WLM」と呼びます。
Manual WLMのデフォルトでは、クエリの同時実行数が 5 で、 5 つに均等にメモリが配分されます。Auto WLM は、クエリに必要なリソースを自動的に決定し、ワークロードに基づいて同時実行数を自動調整します。大量のリソースを必要とするクエリがシステムにある場合 (大きなテーブル間のハッシュ結合など)、同時実行数は減ります。実行時間の短いクエリー (挿入、削除、スキャン、単純な集計など) を送信すると、同時実行数は増えます。
Auto WLM の設定
設定方法
Auto WLM を Amazon Redshift コンソールを使用して有効にするには、[Workload Management]画面を開き、[Switch WLM mode]を押します。
引き続き、[Auto WLM] の順に選択して、[Save]ボタンを押します。
設定を直ちに反映するには、Redshiftクラスタを再起動してください。
Auto WLM が有効になっているかどうかを確認
Auto WLM が有効になっているかどうかを確認するには、次のクエリを実行します。クエリが 1 行を返した場合、Auto WLM は有効になっています。
select * from stv_wlm_service_class_config where service_class = 100; -[ RECORD 1 ]------------+----------------------------------------------------------------- service_class | 100 queueing_strategy | Start time queue policy num_query_tasks | -1 target_num_query_tasks | -1 evictable | true eviction_threshold | 20000000 query_working_mem | -1 target_query_working_mem | -1 min_step_mem | 5 name | Service class with auto concurrency max_execution_time | 0 user_group_wild_card | false query_group_wild_card | false concurrency_scaling | off
同時実行数の確認
同時実行数とスロットごとに割り当てられるメモリは動的に変化します。以下のSQLで同時実行数を確認できます。 25クエリのうち、11クエリは実行中（RUNNING）、それ以外は14クエリは実行待ち状態(QueuedWaiting)であることが確認できます。service_class「100」は、Auto WLMのキューで動作していることを表します。
select xid, query, trim(state), service_class, queue_time, exec_time from stv_wlm_query_state where service_class > 4; xid | query | btrim | service_class | queue_time | exec_time ----------+--------+---------------+---------------+------------+----------- 34923011 | 498287 | QueuedWaiting | 100 | 37426289 | 0 34923019 | 498288 | QueuedWaiting | 100 | 36693350 | 0 34923034 | 498291 | QueuedWaiting | 100 | 31607929 | 0 34923038 | 498292 | QueuedWaiting | 100 | 30788099 | 0 34923061 | 498295 | QueuedWaiting | 100 | 26466904 | 0 34923062 | 498296 | QueuedWaiting | 100 | 26457543 | 0 34923094 | 498302 | QueuedWaiting | 100 | 16917993 | 0 34923095 | 498303 | QueuedWaiting | 100 | 16823381 | 0 34923101 | 498304 | QueuedWaiting | 100 | 15743397 | 0 34923107 | 498305 | QueuedWaiting | 100 | 11473297 | 0 34923113 | 498306 | QueuedWaiting | 100 | 9977922 | 0 34923128 | 498308 | QueuedWaiting | 100 | 4793323 | 0 34923137 | 498310 | QueuedWaiting | 100 | 1708386 | 0 34923144 | 498312 | QueuedWaiting | 100 | 87751 | 0 34922978 | 498281 | Running | 100 | 51611360 | 1001452 34923138 | 498311 | Running | 100 | 0 | 1466484 34922977 | 498280 | Running | 100 | 50042518 | 2629435 34922941 | 498275 | Running | 100 | 49552714 | 7349706 34922927 | 498273 | Running | 100 | 49163420 | 12539077 34922915 | 498271 | Running | 100 | 45908994 | 20668234 34923050 | 498294 | Running | 100 | 10309011 | 17918265 34922946 | 498276 | Running | 100 | 46189206 | 9982800 34922990 | 498283 | Running | 100 | 25660247 | 17402580 34922969 | 498279 | Running | 100 | 41109972 | 12022989 34923083 | 498301 | Running | 100 | 0 | 18087347 (25 rows)
Concurrency ScalingやShort Query Acceleration(SQA)との併用可能
Auto WLMとConcurrency Scaling
Manual WLM から Auto WLMに変更にすると、1 つのキューが追加され、[Memory] フィールドと [Concurrency on main] フィールドは [auto] に設定されます。[Concurrency Scaling]を [auto] にすることで併用可能です。
例えば、バッチ処理用のキュー（batch）とデフォルトキューの２つ登録されているパラメータグループに対して、Auto WLMに設定を変更すると以下のように1 つのキューが追加されます。（14〜19行目）
設定の中に"auto_wlm" : trueを含むWLMのキューがあると、バッチ処理用のキュー（batch）とデフォルトキューは機能せず、Auto WLMのキューが機能します。逆に"auto_wlm" : trueがないと、バッチ処理用のキュー（batch）とデフォルトキューが有効になりManual WLMの動作になります。
[ {
"query_concurrency" : 3,
"query_group" : [ "batch" ],
"query_group_wild_card" : 0,
"user_group" : [ ],
"user_group_wild_card" : 0
}, {
"query_concurrency" : 5,
"query_group" : [ ],
"query_group_wild_card" : 0,
"user_group" : [ ],
"user_group_wild_card" : 0
}, {
"query_group" : [ ],
"query_group_wild_card" : 0,
"user_group" : [ ],
"user_group_wild_card" : 0,
"concurrency_scaling" : "auto",
"auto_wlm" : true
}, {
"short_query_queue" : true
} ]
Short Query Acceleration(SQA)
Redhistクラスタで、下記のクエリを数分ごとに実行すると、機能しているサービスクラス(svc_class)のcountの増加を確認できます。Auto WLMは設定済みなので サービスクラス「100」はcountが増加します。Short Query Acceleration(SQA)のサービスクラス「14」のcountも増加することが確認できました。Short Query Acceleration(SQA)は、Auto WLMが管理しているキューとは別に動作しているようです。
select service_class as svc_class, count(*), avg(datediff(microseconds, queue_start_time, queue_end_time)) as avg_queue_time, avg(datediff(microseconds, exec_start_time, exec_end_time )) as avg_exec_time from stl_wlm_query where service_class > 4 group by service_class order by service_class; svc_class | count | avg_queue_time | avg_exec_time -----------+-------+----------------+--------------- 6 | 2394 | 12364993 | 9024724 7 | 52 | 60764314 | 25081324 14 | 550 | 0 | 7916589 15 | 1440 | 0 | 217315 100 | 356 | 68727699 | 23098295 (5 rows)
上記のサービスクラス(svc_class)に割り当てられている ID は以下のとおりです。
| ID | サービスクラス |
|---|---|
| 1～4 | 将来の利用のために予約されています。 |
| 5 | スーパーユーザーキューで使用します。 |
| 6～13 | WLM 設定で定義されている手動 WLM キューで使用します。 |
| 14 | Short Query Acceleration(SQA)で使用します。 |
| 15 | Amazon Redshift で実行されるメンテナンスアクティビティ用に予約されています。 |
| 100 | auto_wlm が true の場合に自動 WLM キューで使用します。 |
まとめ
Auto WLM は、機械学習アルゴリズムを用いてクラスターのリソースを動的にチューニングを自動化する素晴らしい機能です。今年になってから、Auto VACUUM DELETE（削除済み領域のコンパクション）やAuto ANALYZE（統計情報の自動更新）など、Redshiftはメンテナンス作業が軽減されてる機能が追加されています。WLMのチューニングをAuto WLMを利用してワークロード管理も自動化しましょう。
合わせて読みたい
Amazon Redshift 高い同時実行性と一貫したパフォーマンスを提供する新機能『Concurrency Scaling』がリリースされました
機械学習を用いた新機能『Amazon Redshift Short Query Acceleration(SQA)』を実際に試してみました
![[レポート] インシデント発生に備えるための議論をする tabletop「Incident response tabletop: Supply chain」 #GHJ205-R #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
![[レポート]re:Invent 2024のEXPO会場で救急セットを作ったりして #GiveBack しよう #AWSreInvent #ACT126](https://devio2024-media.developers.io/image/upload/v1733389602/user-gen-eyecatch/myjtprkzjjcwvxmf8enu.png)
