高い同時実行性と一貫したパフォーマンスを提供する新機能『Concurrency Scaling for Amazon Redshift』を実際に試してみました
目次
はじめに
先日リリースした高い同時実行性と一貫したパフォーマンスを提供する新機能『Concurrency Scaling for Amazon Redshift』を下記のブログにてご紹介しました。世界最速で「試してみた」ブログを書いてやろうという野心が止められず、Jeff BarrさんがTwitterにポストする前にフライング検証したため失敗、、、という悲しい結果に終わりました。今回はそのリベンジブログです。
Amazon Redshift 高い同時実行性と一貫したパフォーマンスを提供する新機能『Concurrency Scaling』がリリースされました
Concurrency Scaling の特長
一般的なデータウェアハウスでは、1日の中でクエリの使用方法が大きく異なります。 ピーク需要に合わせて事前にプロビジョニングするのではなく、コンピューティングが必要とされる期間だけリソースを追加する方が費用対効果が高くなります。
Concurrency Scalingは、同時ユーザとクエリからの大量の要求を処理する必要があるときに、「スケーリングクラスタ」という一時的なキャパシティを追加します。 ワークロードが増加すると、Amazon RedshiftはWLMキューをバイパスして、クエリを自動的にスケーリングクラスタにルーティングします。 Concurrency Scalingを使用すると、実質的に数倍のクエリ並行処理を実現できます。
検証
検証環境
実行するクエリは参照クエリのみです。最も一般的なユースケースを想定しているため、Short Query AccelerationとResult Cachingは、デフォルト動作にしています。しかし、Short Query AccelerationやResult Cachingが機能すると、スケーリングクラスタにルーティングされず検証にならないため、処理時間が平均2分程度のクエリをキャッシュされないように毎回条件を替えて実行しました。
- クラスタ構成：dc2.large x 2
- クラスタバージョン：1.0.6805
- リージョン：バージニア（us-east-1）
- Short Query Acceleration(SQA)：
Dynamic - Result Caching：
on - WLMキューのサイズ：
5 - クエリの負荷：同時実行25
- クエリ：6億レコード中からランダムで範囲選択、ソートして先頭レコードを返す処理
検証方法
WLMキューのサイズ「5」に対して、同時「25」クエリを実行したので、20クエリはキューから溢れてスケーリングクラスタにて処理される想定です。Concurrency Scalingの仕組みや設定方法については、先日書いたブログを御覧ください。
- テスト１（通常）：Concurrency Scaling：
off - テスト２（スケーリングクラスタ１台）：Concurrency Scaling：
autoかつ max_concurrency_scaling_clusters：1 - テスト３（スケーリングクラスタ５台）：Concurrency Scaling：
autoかつ max_concurrency_scaling_clusters：5
なお、どのクエリがスケーリングクラスタにルーティングされたかは、[クエリ]ビューの[Executed on]フィールドがConcurrency Scalingと表示されます。
テスト１（通常）
Concurrency Scalingをoff(無効)（デフォルト）に設定して、1000クエリを実行しました。25クエリ中20クエリは待ち状態となります。
1000クエリ実行するのに1時間18分かかりました。Concurrency Scaling Activetyが0でメインクラスタのみで動作していることが確認できます。また、Concurrency Scaling Usage In Minutes (Sum)は、全く発生していないためグラフすら表示されません。
この数値を基準にConcurrency Scalingの有効性を評価します。
テスト２（スケーリングクラスタ１台）
Concurrency Scalingをauto(自動) 、スケーリングクラスタの最大値（max_concurrency_scaling_clusters）を1（デフォルト）に設定して、1000クエリを実行しました。25クエリ中15クエリは待ち状態となります。クエリを実行すると1分程度でスケーリングクラスタが起動されました。
1000クエリ実行するのに32分かかりました。テスト1と比較すると60%の改善です。Concurrency Scaling Activityからクエリが終了するとスケーリングクラスタが自動的にスケールインしてすることが確認できました。
テスト３（スケーリングクラスタ５台）
Concurrency Scalingをauto(自動) 、スケーリングクラスタの最大値（max_concurrency_scaling_clusters）を5に設定して、1000クエリを実行しました。増減はありますが25クエリ中0〜14クエリが待ち状態となります。クエリを実行すると1分毎に2台、3台、4台と段階的にスケーリングクラスタ起動されました。Max Configured Concurrency Scaling Clusters（最大スケーリングクラスタ数）は5に設定していますが、Concurrency Scaling Activity（実際に起動されたスケーリングクラスタの数）は最大で4でした。その理由は25クエリ処理するのに5台のスケーリングクラスタは不要なため自動起動されなかったと考えられます。
1000クエリ実行するのに14分30秒程度です。テスト1と比較すると81%の改善です。Concurrency Scaling Activityからクエリが終了すると段階的にスケーリングクラスタが自動的にスケールインしてすることが確認できました。
テスト結果
上記のテスト結果を表にまとめました。
- Concurrency Scalingの台数に応じて処理性能が向上する
- 処理総時間（Workload Duration）：スケーリングクラスタ1台で59%の改善、4台で81%の改善
- クエリあたりの処理時間（Workload Duration per Query）：スケーリングクラスタ1台で66%の改善、4台で85%の改善
- レスポンスの平均時間（Respons Time）：スケーリングクラスタ1台で58%の改善、4台で81%の改善
- スケーリングクラスタの自動スケールイン／スケールアウトは、数分で柔軟に素早く増減する
- Max Configured Concurrency Scaling Clusters（最大スケーリングクラスタ数）は
5に設定しても、Concurrency Scaling Activity（実際に起動されたスケーリングクラスタの数）は最大で4でした。 - その理由は25クエリ処理するのに5台のスケーリングクラスタは不要なため自動起動されなかったと考えられる
- 今回の検証の結果ではスケーリングクラスタ１台あたり５クエリを同時実行しているように見える
- 課金はスケーリングクラスタ数ではなく、クエリの実行時間であるためスケーリングクラスタ数を気にする必要はない
ピーク需要の多い時間帯にクエリの実行待ちが生じてパフォーマンスが落ちるユースケースでは特に効果が大きいことが期待できます。
| test # | WLM Concurrency | Workload start time | Workload End time | Workload Duration (sec) | Other Testing info | Begin query ID | End query ID |
|---|---|---|---|---|---|---|---|
| 1 | 5 | 2019-03-29 12:18:53 | 2019-03-29 13:36:52 | 4679 | Concurrent Queries#: 25 | 2900521 | 2901928 |
| 2 | 5 | 2019-03-29 10:40:00 | 2019-03-29 11:11:06 | 1912 (59% ↑) | Concurrent Queries#: 25 | 2896910 | 2898035 |
| 3 | 5 | 2019-03-29 11:43:34 | 2019-03-29 11:58:13 | 879 (81% ↑) | Concurrent Queries#: 25 | 2898761 | 2899884 |
| test # | query# | cached query# | scaled query# | scaled_query per query (%) | Concurrent Scaling Activity# | Workload Duration per Query (sec) | Respons Time (sec) |
|---|---|---|---|---|---|---|---|
| 1 | 1000 | 4 | 0 | 0.000 | 0 (0/0) | 5.76 | 115.730 |
| 2 | 1000 | 9 | 498 | 50.252 | 1 (1/1) | 1.912 (66% ↑) | 48.519 (58% ↑) |
| 3 | 1000 | 5 | 722 | 72.562 | 4 (4/5) | 0.879 (85% ↑) | 21.832 (81% ↑) |
各テストの実行結果のグラフを並べて表示しました。テストの順番が前後していますので、ご注意ください。
考察
スケーリングクラスタは高速かつしなやかに増減するため、仮にデフォルト状態だったとしても利用者は何も意識せずに性能改善を体感できました。仮に環境の違いによって性能改善しない場合でもスケーリングクラスタ上でクエリが実行されませんので課金の心配はありません。更新系クエリー、ショートクエリ、キャッシュされたクエリは従来通りメインクラスタで処理されます。それ以外のクエリはWLMのキューサイズを超えたときにスケーリングクラスタが自動起動、クエリがルーティング、実行されます。
スケーリングクラスタの最大数、WLMのキューサイズ、Short Query Acceleration(SQA)、Result Cachingの効果的な利用など、チューニングの余地はありますが、今回はあえて「デフォルト」の状態でConcurrency Scalingを有効にしてどれくらい改善するかを検証しました。正直ここまで良い結果が得られたのは大変驚きで、画期的な機能であり一時的なピーク需要に備えてConcurrency Scalingを有効にするのを推奨します。今回ご紹介した検証以外に上位のクラスタによる大規模データでも検証を実施しましたが概ね同じような検証結果が得られていますので、様々な環境においてもバーストクエリにおける性能改善が期待できます。
効果的なユースケース
- ピーク需要の多い時間帯にクエリの実行待ちが生じてパフォーマンスが落ちるユースケースでは特に効果が大きい
- BIツールやダッシュボードなどの参照系クエリのスパイクアクセス対策
- データの整合性を確保しつつ参照系クエリのスケールアウトが必要な場合
不向きなユースケース
- 同時実行がWLMのキューサイズを超えないロングクエリーの性能改善
- 更新系クエリの性能改善
- Redshift Spectrumのスケールアップ
- ショートクエリの性能改善
最後に
これまでBIツールやダッシュボードなどの参照系クエリのスパイクアクセス対策するには、データマート等をフロントのRDSにマテリアライズして、スケールアウトしていました。しかし、システムの構成が複雑になり、またマテリアライズしたデータが古くなり、最新の情報を分析する用途では不向きでした。 スケーリングクラスタの増減は高速かつしなやかに増減するため、仮にデフォルト状態だったとしても利用者は何も意識せずに性能改善を体験できることが確認できました。また、性能改善しない場合はスケーリングクラスタでクエリが実行せず課金は発生しませんので活用をご検討ください。
![[レポート]AWSでデータメッシュアーキテクチャを構築する#ANT336 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2022/11/eyecatch_reinvent2022_session-report.png)
