Amazon Redshift 高い同時実行性と一貫したパフォーマンスを提供する新機能『Concurrency Scaling』がリリースされました

目次

• はじめに
• 最新クラスタにアップデート
• Concurrency Scalingとは
• Concurrency Scaling の仕組み
• Concurrency Scaling の利用条件
• Concurrency Scaling の設定方法
• Concurrency Scaling を設定したクラスタにクエリを実行
• Concurrency Scaling の料金
• 最後に

はじめに

本日、未明にAWS Blogにて昨年のre:Invent2018で発表のあった『Concurrency Scaling for Amazon Redshift』のリリースが発表されました。『Concurrency Scaling for Amazon Redshift』は、従来クラスタに加えてスケーリングするクラスタを組み合わせて、従来より遥かに高い同時実行性と一貫した高速なパフォーマンスを提供する新機能です。（re:Invent2018では、Werner Vogels さん自らConcurrency Scalingを紹介していました）

New – Concurrency Scaling for Amazon Redshift – Peak Performance at All Times - https://t.co/hQajHsravh - #AWS #AWSSummit pic.twitter.com/KJQkQt5NfD

— Jeff Barr ☁️ (@ ? ) (@jeffbarr) March 27, 2019

• New – Concurrency Scaling for Amazon Redshift – Peak Performance at All Times

最新クラスタにアップデート

クラスタを確認すると、新しいクラスタ(Cluster Version 1.0.6805 )がスタンバイしていたので、新機能や改善点を確認したところ『Concurrency Scaling』と記載があります。

脊髄反射的に [はい、いますぐアップデートします] ボタンをポチッ、、、アップデート。

Concurrency Scalingとは

AWSの大薗さんのBlackbeltの資料にある通り、従来クラスタ（メインクラスタ）に加えてスケーリングするクラスタ（スケーリングクラスタ）を組み合わせて、従来より遥かに高い同時実行性と一貫した高速なパフォーマンスを提供する新機能です。参照系クエリ数に応じて自動的にクラスター数を増減します。エンドポイントは従来通りメインクラスタに対して接続します。更新系クエリは、メインクラスタで通常どおり続行されます。参照系クエリはメインクラスタとスケーリングクラスタのどちらで実行されても、ユーザーは常にデータの整合性は保たれます。

つまり、利用者はAmazon Redshiftの『Concurrency Scaling』の機能を有効にすると、Redshiftに接続するアプリケーションは設定変更せずに直ちに利用可能になり、参照系クエリが整合性は保たれた状態でスケールします。

Concurrency Scaling の仕組み

最初にどの様にメインクラスタとスケーリングクラスタがデータを同期するかについて解説します。Redshiftはデータの更新が発生すると自動的にスナップショット（下の図の「バックアップ」）をS3（下の図のRedshift Managed S3）に作成します。Concurrency Scaling が有効なRedshiftでは、このスナップショットを用いてクエリを実行するスケーリングクラスタ（下図の右）を自動的に起動して待機します。スケーリングクラスタは、高速なS3上のスナップショットからデータを読み取るだけで済むようにコンピューティングとストレージが分離されており、起動が早いのでしょう。しかし、データの整合性をスナップショットのみに依存すると応答性能が極端に遅くなるので、更新された最新のデータはメインクラスタから取得します。そうすることで、コストを抑え、迅速かつ柔軟にクラスタを伸縮し、データの整合性を確保しています。

つぎに、クエリがスケーリングクラスタにルーティングされる仕組みについて解説します。WLMの同時実行数（query_concurrency）の範囲内のクエリについては従来通りメインクラスタで実行しますが、同時実行数を超えるクエリを実行しなければならない場合にスケーリングクラスタにルーティングされます。つまり、一時的なバーストクエリはスケーリングクラスタにルーティングされますが同時実行数を超えることがほとんどない環境であれば1日1時間分のConcurrency Scalingの無料のクレジット範囲でバーストクエリの処理についても対応できるということになります。

仕組みがわかると、なぜ線形スケールするのかが理解できたと思います。一方、更新クエリはメインクラスタで実行されるため、スケールしないことも納得できるはずです。

Concurrency Scaling の利用条件

メインクラスタの条件

メインクラスタが以下の要件を満たしていないと、クエリはConcurrency Scalingクラスタにルーティングされません。

• EC2-VPCプラットフォーム
• ノードタイプはdc2.8xlarge、ds2.8xlarge、dc2.large、またはds2.xlargeのいずれかです
• 最大32個のコンピュートノード
• シングルノードクラスタはサポートしません

Concurrency Scalingの対象クエリ

以下のクエリが、Concurrency Scalingの対象となります。

• 読み取り専用のSELECTクエリ
• インターリーブソートキーを使用したテーブルを参照しないクエリ
• クエリは外部テーブルを参照するAmazon Redshift Spectrumを使用しない
• クエリがスケーリングクラスタにルーティングされるためには、キューイングが発生する（同時実行数を超える）必要があります

スケーリングクラスタへのクエリーのルーティングはわずかなオーバーヘッドを伴うため、ショートクエリはメインクラスタで実行されます。ショートクエリは、Short Query Acceleration （SQA）アルゴリズムを使用して識別されます。

Concurrency Scaling の設定方法

WLMのキューにConcurrency Scaling modeの設定

WLM（ワークロード管理）のキューをConcurrency Scalingキューとして有効に設定することで、クエリをConcurrency Scalingクラスターにルーティングします。Concurrency Scalingを有効にするには、Concurrency Scaling modeをautoに設定します。ワークロードマネージャ（WLM）キューをConcurrency Scalingキューとして有効にすることで、クエリをConcurrency Scalingクラスターにルーティングします。なお、設定の反映にクラスタの再起動は不要です。設定するとConcurrency Scalingキューにルーティングされたクエリの数がキューの設定した同時実行数を超えると、クエリがConcurrency Scalingクラスタに送信されます。

Concurrency Scalingの最大クラスタ数（max_concurrency_scaling_clusters）の指定

Concurrency Scalingが有効になっている場合にConcurrency Scalingクラスタの最大数を設定します。Concurrency Scalingがさらに必要な場合は、この値を増やしてください。（なお、この値の上限値10上限緩和申請が可能です。）この値を小さくすると、Concurrency Scalingクラスターの使用量とそれに伴う請求額が減少します。

今回は、最大値の10を設定しました。1（デフォルト）から10に変更するとMax Configured Concurrency Scaling Clustersが過去の実績値に基づき、すぐに10 Cluster起動されました。

• 参考：max_concurrency_scaling_clusters

Concurrency Scaling を設定したクラスタにクエリを実行してみましたが...

上記の設定を有効にすると、スケーリングクラスタ（下記の図、Max Configured Concurrency Scaling Cluster）が10に達し、同時に25クエリを実行すると、WLMのキュー（下記の図、Queue Length by WLM Queue）が同時実行数の5を超えることで、スケーリングクラスタにルーティングされることはずでした。しかし、スケーリングクラスタの稼働状況（下記の図、Concurrency Scaling Activity）の値に変化がないことから、スケーリングクラスタにルーティングされていないようです。検証の着手が早すぎたのかもしれません、、、パフォーマンス改善の詳細については、後日ブログにてご報告します。

「試してみました」 リベンジブログを書きました。

高い同時実行性と一貫したパフォーマンスを提供する新機能『Concurrency Scaling for Amazon Redshift』を実際に試してみました

Concurrency Scaling の料金

気になる利用費は、追加したクラスターで稼働したクエリに対して１分単位の従量課金となります。しかし、クラスタ毎に1日1時間分のConcurrency Scalingのクレジットが提供され、最大30時間の無料のConcurrency Scalingクレジットを累積できます。そのため、多くの利用者はConcurrency Scalingを無料でご利用いただけるのではないかと考えています。

つまり、Concurrency Scalingの機能を有効にしただけでは利用費は発生せず、１時間までなら無料で利用できるということです。

例えば、米国東部（US-East）の10台のコンピュートノードを含む DC2.8XLノードのRedshiftクラスターは、1時間あたり48ドルです。無料のConcurrency Scalingクレジットを超えて、2つの一時クラスターが5分間使用されるシナリオを考えてみましょう。Concurrency Scalingの1秒あたりのオンデマンドレートは、48ドル* 1/3600 = 1秒あたり0.013ドルです。この場合のConcurrency Scalingの追加コストは、1秒あたり0.013ドル* 300秒* 2一時クラスタ= 8ドルです。したがって、この場合のAmazon Redshiftクラスターと2つの一時クラスターの合計コストは56ドルです。

最後に

『Concurrency Scaling』は、Redshiftの中で最も大きなアップデートです。多くの同時ユーザーとクエリの実行に対して一貫して高速のクエリパフォーマンスを提供し、必要に応じて容量を自動的に増減させる機能は、これまで不向きだったスパイクアクセスに対して迅速かつ柔軟に対応できるはずです。クラスタ毎に1日1時間分のConcurrency Scalingの無料クレジットが提供されていますので、まずはこの機能を有効にして効果を確認していただけるはずです。今回の検証では、着手が早すぎたのかもしれませんが動作の確認に至っておりません。パフォーマンス改善の詳細については、後日ブログにてご報告しますのでしばらくお待ち下さい。