Redshiftアップデート：タイムアウトしたクエリーを別キューに転送する新機能queue hoppingの使い方
Redshiftの新バージョン1.0.1019が１月７日にリリース予告され、その後約２週間かけて各リージョンにデプロイされました。ご利用のRedshiftクラスターのメンテナンスウィンドウの設定にもよりますが、多くのRedshiftクラスターが1.0.1019に更新されていると思います。
- Announcement: Amazon Redshift Maintenance (Jan 07-21, 2016)
- Amazon Redshift supports automatic queue hopping for timed-out queries
この1.0.1019には目立たないながらも便利な新機能”queue hopping for timed-out queries”が追加されています。実運用では使い勝手の良い新機能だと思いますので、少し使い方を解説します。
Redshiftには以前よりワークロードマネジメント（WLM）という機能があり、メモリ使用量や並列度を設定したキューを複数定義し、用途ごとにキューを分けて実行することが可能でした。これによって、並列で実行され１つ１つのクエリーの実行にはあまり時間が掛からないようなインタラクティブなジョブと、バッチ処理用SQLのような応答速度は求められないが長い実行時間を必要とするクエリーを分けて管理が可能になります。
例として、このようなWLMを設定したとしましょう。
User Groupsという所にapp1とapp1batchという設定がありますが、これはRedshiftの中で作成したグループ名のことです。つまりapp1グループに所属するユーザのクエリーは1番目のキュー(#1)に、app1batchに所属するユーザは#2、それ以外のユーザは#3のキューに入ります。複数の条件が一致する場合は、定義により上の方に定義したキューに入ります。
キューではそれぞれ並列度（Concurrency)や、利用メモリ(Memory)を設定できます。およびタイムアウト(Timeout)を設定できます。この例ではキュー#1には20000ms(=20秒)の設定があるため、実行に20秒以上かかったクエリーは停止（terminate）されます。
上の例ではインタラクティブ（20秒以内）に応答が期待できるクエリーはキュー#1で5並列で実行し、長い時間がかかるクエリーはキュー#2で1並列で順に実行するという設計例です。
新機能のQueue Hoppingでは、このタイムアウトが発生した時にクエリーを停止するだけでなく、自動的に次に条件マッチするキューにクエリーを投入しなおしてくれるという機能です。これによって時間がかかり過ぎるクエリーをインタラクティブなクエリーから切り離し、別キューでゆっくり実行させる事が可能になります。クエリーがキャンセルされて次のキューに再投入されても、クライアントにはエラーは返りません。
自動的なクエリー再投入が行われるのはリードオンリー（読み取りのみ）のクエリーだけです。つまり更新処理やDMLは対象外という点に注意してください。
では、試してみましょう！
mydb=# create group app1;
mydb=# create group app1batch;
mydb=# create user test1 in group app1,app1batch password 'xxxxx';
mydb=# grant usage on schema public to group app1;
mydb=# grant usage on schema public to group app1batch;
mydb=# grant all on schema public to group app1;
mydb=# grant all on schema public to group app1batch;
mydb=# grant all on all tables in schema public to group app1;
mydb=# grant all on all tables in schema public to group app1batch;
例では、上のようにapp1とapp1batchというグループを作成してPUBLICスキーマ内の表への権限を与えています。test1ユーザはその両方に所属しているため、test1ユーザのクエリーはWLMの設定上、より上位にあるキュー#1（app1）に投入されます。ここで約30秒かかるクエリーを実行してみましょう。Redshiftの管理コンソールで確認すると、以下のようになりました。
最初3814番として実行されたクエリーが20秒を超えたところでterminate（停止）され、自動的に再度実行されています。再実行時には次にマッチするキューである#2(appb1atch)で実行されており、これにはタイムアウトが設定されていないため、最後まで実行できています。
ただし、一旦キャンセルして再実行しているのでクライアントには（タイムアウトにかった時間＋再実行）の処理時間がかかったように見えます。この例だとSQLを実行したpsqlのコマンドラインにはTime: 50652.376 ms（約50秒)と表示されていました。タイムアウトの20秒＋再実行時間の30秒の合計ですね。
WLMの制御にはQuery Groupという方法もあります。これはRedshiftの所属ユーザには関係なく、クエリー実行前にset query_groupコマンドで実行したいキューを指定します。例えばこのようにWLMを設定したとします。
この状態で新しいユーザtest2を作成します。
mydb=# create user test2 password 'xxxxx';
mydb=# grant usage on schema public to test2;
mydb=# grant all on schema public to test2;
mydb=# grant all on all tables in schema public to test2;
test2でRedshiftに接続して、以下のように実行します。
mydb=> set query_group to 'app2';
mydb=> select ... ;
このようにquery_group変数をセットすることで、キューの指定が可能になります。この例でも同様に最初は上位のキュー#1で実行されて20秒でタイムアウトした後にキュー#2で再実行される事が確認できました。
User GroupとQuery Groupをキューに同時に設定して使うことも可能です。ただし条件マッチの検索はUser Groupが優先されるという事に注意してください。キュー設定の詳細についてはマニュアル（以下）に記載があります。
このようにWLMの新機能Queue hopping for time-out queriesは、多様なクエリーが実行されるRedshiftの運用管理を少し楽にしてくれます。ぜひ運用に取り入れてみてください。
下佐粉 昭（@simosako）
※補足：ブログ執筆時点で、一部のリージョンもしくは一部の環境ではWLMのパラメータグループでキュー設定を変更しようとした時にブラウザがハングするという問題が報告されています。現在修正中とのことです。
コメント