Amazon Redshift Parallel Scaling ガイドとテスト結果

Skyeng では、並列スケーリングを含む Amazon Redshift を使用しているため、dotgo.com の創設者である Stefan Gromoll による intermix.io 向けのこの記事が興味深いと思いました。 翻訳後、データ エンジニア Daniyar Belkhodzhaev からの経験を少し紹介します。

Amazon Redshift アーキテクチャ クラスターに新しいノードを追加することでスケーリングが可能になります。 リクエストのピーク数に対処する必要があると、ノードの過剰プロビジョニングが発生する可能性があります。 同時実行スケーリングは、新しいノードを追加するのとは対照的に、必要に応じてコンピューティング能力を向上させます。

Amazon Redshift の並列スケーリングにより、Redshift クラスターにピーク時のリクエスト量を処理するための追加容量が与えられます。 これは、バックグラウンドでリクエストを新しい「並列」クラスターに移動することで機能します。 リクエストは、WLM の設定とルールに基づいてルーティングされます。

並列スケーリングの価格は、無料利用枠のあるクレジット モデルに基づいています。 無料クレジットを超えると、Parallel Scaling Cluster がリクエストを処理する時間に基づいて支払いが行われます。

著者は、内部クラスターの XNUMX つで並列スケーリングをテストしました。 この投稿では、テスト結果について説明し、開始方法についてのヒントを提供します。

クラスターの要件

並列スケーリングを使用するには、Amazon Redshift クラスターが次の要件を満たしている必要があります。

- プラットホーム： EC2-VPC。
— ノードタイプ: dc2.8xlarge、ds2.8xlarge、dc2.large または ds2.xlarge;
— ノードの数: 2 ～ 32 (単一ノードクラスターはサポートされていません)。

受け入れ可能なリクエストのタイプ

並列スケーリングは、すべての種類のクエリに適しているわけではありません。 最初のバージョンでは、次の XNUMX つの条件を満たす読み取りリクエストのみが処理されます。

— SELECT クエリは読み取り専用です (ただし、より多くのタイプが計画されています)。
— クエリは INTERLEAVED 並べ替えスタイルのテーブルを参照しません。
- クエリは、外部テーブルを参照するために Amazon Redshift Spectrum を使用しません。

Parallel Scaling Cluster にルーティングするには、リクエストをキューに入れる必要があります。 さらに、キューの対象となるクエリ SQA (ショートクエリアクセラレーション)、並列スケールのクラスターでは実行されません。

キューと SQA には適切な構成が必要です Redshift ワークロード管理 (WLM)。 最初に WLM を最適化することをお勧めします。これにより、並列スケーリングの必要性が減ります。 並列スケーリングは一定時間のみ無料であるため、これは重要です。 AWS は、97% の顧客に対して並列スケーリングが無料になると主張しており、価格の問題が生じます。

並列スケーリングのコスト

AWS は、並列スケーリングのためのクレジット モデルを提供します。 アクティブな各クラスター Amazonレッドシフト クレジットは XNUMX 時間ごとに蓄積され、XNUMX 日あたり最大 XNUMX 時間の無料並列スケーリング クレジットが付与されます。

料金を支払うのは、Parallel Scaling Clusters の使用量が受け取ったクレジットの量を超えた場合のみです。

コストは、無料料金を超えて使用される並列クラスターの XNUMX 秒あたりのオンデマンド料金で計算されます。 料金はリクエストの継続時間に対してのみ発生し、Parallel Scaling Cluster がアクティブ化されるたびに最低料金は XNUMX 分となります。 XNUMX 秒あたりのオンデマンド料金は、一般的な価格設定原則に基づいて計算されます。 Amazonレッドシフトつまり、ノードのタイプとクラスター内のノードの数によって異なります。

並列スケーリングの開始

並列スケーリングは、WLM キューごとにトリガーされます。 AWS Redshift コンソールに移動し、左側のナビゲーション メニューから [ワークロード管理] を選択します。 次のドロップダウン メニューからクラスターの WLM パラメーター グループを選択します。

各キューの横に「同時実行スケーリング モード」という新しい列が表示されます。 デフォルトは「無効」です。 「編集」をクリックすると、各キューの設定を変更できます。

設定

並列スケーリングは、適切なリクエストを新しい専用クラスターに転送することで機能します。 新しいクラスターのサイズ (ノードのタイプと数) はメイン クラスターと同じです。

並列スケーリングに使用されるデフォルトのクラスター数は 1 で、合計で最大 10 個のクラスターを構成できます。
並列スケーリングのクラスターの合計数は、max_concurrency_scaling_clusters パラメーターで設定できます。 このパラメータの値を増やすと、追加の冗長クラスタが提供されます。

監視

AWS Redshift コンソールでは、追加のグラフがいくつか利用可能です。 [最大構成同時実行スケーリング クラスター] グラフには、時間の経過に伴う max_concurrency_scaling_clusters の値が表示されます。

アクティブなスケーリング クラスターの数は、ユーザー インターフェイスの「同時実行スケーリング アクティビティ」セクションに表示されます。

[クエリ] タブには、クエリがメイン クラスターで実行されたか並列スケーリング クラスターで実行されたかを示す列があります。

特定のクエリがメイン クラスターで実行されたか、並列スケーリング クラスターを通じて実行されたかに関係なく、クエリは stl_query.concurrency_scaling_status に保存されます。

値 1 はクエリが並列スケール クラスターで実行されたことを示し、他の値はクエリがプライマリ クラスターで実行されたことを示します。

例：

同時実行スケーリング情報は、SVCS_CONCURRENCY_SCALING_USAGE などの他のテーブルやビューにも保存されます。 さらに、並列スケーリングに関する情報を保存するカタログ テーブルが多数あります。

結果

著者らは、18 年 30 月 00 日のグリニッジ標準時約 29.03.2019:3:20 に内部クラスター内の 30 つのキューの並列スケーリングを開始し、00 年 29.03.2019 月 XNUMX 日の約 XNUMX:XNUMX:XNUMX に max_concurrency_scaling_clusters パラメーターを XNUMX に変更しました。

リクエスト キューをシミュレートするために、このキューのスロット数を 15 から 5 に減らしました。

以下は、スロット数を減らした後に実行中およびキューに入れられているリクエストの数を示す intermix.io ダッシュボード グラフです。

キュー内のリクエストの待機時間が増加し、最大時間が 5 分を超えていることがわかります。

この間に何が起こったかについての AWS コンソールからの関連情報は次のとおりです。

Redshift は、構成どおりに 3 つの並列スケーリング クラスターを起動しました。 クラスター内の多くのリクエストがキューに入れられていたにもかかわらず、これらのクラスターは十分に活用されていなかったようです。

使用状況グラフは、スケーリング アクティビティ グラフと相関関係があります。

数時間後、作成者がキューを確認したところ、6 つのリクエストが並列スケーリングで実行されているようでした。 また、ユーザー インターフェイスを介して XNUMX つのリクエストをランダムにテストしました。 複数の並列クラスターが同時にアクティブな場合にこれらの値を使用する方法は確認していません。

所見

並列スケーリングにより、ピーク負荷時にリクエストがキュー内で費やす時間を短縮できます。

基本テストの結果、読み込みリクエストの状況が部分的に改善されていることが判明しました。 ただし、並列スケーリングだけでは同時実行の問題をすべて解決できたわけではありません。

これは、並列スケーリングを使用できるクエリの種類に制限があるためです。 たとえば、作成者はインターリーブされたソートキーを持つテーブルを多数持っており、ワークロードのほとんどは書き込みです。

並列スケーリングは WLM をセットアップするための普遍的なソリューションではありませんが、この機能の使用はシンプルで簡単です。

したがって、著者はこれを WLM キューに使用することをお勧めします。 XNUMX つの並列クラスターから開始し、コンソールを通じてピーク負荷を監視して、新しいクラスターが完全に利用されているかどうかを判断します。

AWS が追加のクエリ タイプとテーブルのサポートを追加するにつれて、並列スケーリングは徐々に効率的になるはずです。

Skyeng データエンジニア Daniyar Belkhodzhaev のコメント

私たち Skyeng も、並列スケーリングの可能性が浮上していることにすぐに気づきました。
特にほとんどのユーザーは追加料金を支払う必要すらないと AWS が見積もっていることを考慮すると、この機能は非常に魅力的です。

偶然にも、24 月中旬に Redshift クラスターへのリクエストが異常に殺到しました。 この期間中、私たちは同時実行スケーリングに頼ることが多く、追加のクラスターが XNUMX 時間停止することなく稼働することもありました。

これにより、キューの問題を完全に解決できなかったとしても、少なくとも許容可能な状況にすることができました。

私たちの観察は、intermix.io の人々の印象とほぼ一致しています。

また、キュー内で待機しているリクエストがあっても、すべてのリクエストがすぐに並列クラスターに転送されるわけではないことにも気付きました。 どうやらこれは、並列クラスターの起動にまだ時間がかかるために発生するようです。 その結果、短期間のピーク負荷中も小さなキューが残り、対応するアラームがトリガーされるまでに時間がかかります。

XNUMX 月に異常な負荷が解消されたため、AWS の予想通り、無料標準の範囲内で時々使用するモードに入りました。
AWS Cost Explorer で並列スケーリングのコストを追跡できます。 サービス - Redshift、使用タイプ - CS (USW2-CS:dc2.large など) を選択する必要があります。

価格について詳しくはロシア語でご覧いただけます ここに。

出所： habr.com