Amazon Redshift Serverless 容量を計算する
Amazon Redshift Serverless を使用すると、ワークロードの要件に合わせてコンピューティングキャパシティを自動的にスケールアップおよびスケールダウンできます。コンピューティングキャパシティとは、Amazon Redshift Serverless ワークロードに割り当てられた処理能力とメモリを指します。一般的なユースケースには、ピークトラフィック期間の処理、複雑な分析の実行、大量のデータの効率的な処理などがあります。以下の用語では、コンピューティングキャパシティの設定と管理について詳しく説明します。
RPU
Amazon Redshift Serverless では、Redshift プロセッシング単位 (RPU) で、データウェアハウスの容量が測定されています。RPU は、ワークロードの処理に使用されるリソースです。
基本容量
この設定は、Amazon Redshift Serverless がクエリの処理に使用するデータウェアハウスの基本容量を指定します。基本容量は、RPU で指定します。基本の容量は、Redshift 処理ユニット (RPU) で設定できます。1 つの RPU が 16 GB のメモリを提供します。基本容量を大きく設定することで、特に大量のリソースを消費するデータ処理ジョブでは、クエリのパフォーマンスが向上します。Amazon Redshift Serverless のデフォルトの基本容量は、128 RPU です。AWS コンソール、UpdateWorkgroup
API オペレーション、または AWS CLI の update-workgroup
オペレーションを使用して、[基本容量] 設定を 8 RPU から 512 RPU まで 8 単位 (8、16、24... 512) で調整できます。
最小容量の 8 RPU により、パフォーマンス要件に基づいて、単純なワークロードから複雑なワークロードまで柔軟に実行できるようになりました。8、16、24 RPU の基本 RPU 容量は、128 TB 未満のデータが必要なワークロードを対象としています。データ要件が 128 TB を超える場合は、最低 32 RPU 使用する必要があります。列数が多くて同時実行性が高いテーブルがあるワークロードでは、32 以上の RPU を使用することをお勧めします。
使用可能な最大ベース RPU である 512 RPU は、ワークロードに最高レベルのコンピューティングリソースを追加します。これにより、複雑性の高いワークロードをサポートする柔軟性が向上し、データのロードとクエリが高速化されます。
注記
拡張された最大ベース RPU 容量は 1024 で、次の AWS リージョンで使用できます。
米国東部 (バージニア北部)
米国東部 (オハイオ)
-
米国西部 (オレゴン)
基本容量を 512-1024 に設定すると、RPU を 32 単位で増減できます。
大規模で複雑なワークロードを管理する場合は、Redshift Serverless データウェアハウスのサイズを増やすことを検討してください。大規模なウェアハウスは、より多くのコンピューティングリソースにアクセスできるため、クエリをより効率的に処理できます。ワークグループの最大基本 RPU 容量を増やすには、追加の空き IP アドレスが必要であることに注意してください。空き IP アドレス要件の増加の詳細については、「Amazon Redshift サーバーレスを使用する場合の考慮事項」を参照してください。
基本容量を増やすことが有益であるインスタンスを次に示します。
実行に時間がかかる複雑なクエリがある
テーブルに多数の列がある
クエリに多数の JOIN がある
クエリが、データレイクなどの外部ソースから大量のデータを集約またはスキャンする
Amazon Redshift Serverless のクォータと制限の詳細については、「Amazon Redshift Serverless オブジェクトのクォータ」を参照してください。
Amazon Redshift Serverless 容量に関する考慮事項と制限
Amazon Redshift Serverless 容量に関する考慮事項と制限事項は次のとおりです。
-
8 または 16 RPU の構成では、最大 128 TB の Redshift マネージドストレージ容量をサポートします。128 TB を超えるマネージドストレージを使用している場合は、32 RPU 未満にダウングレードすることはできません。
-
ワークグループのベース容量を編集すると、ワークグループで実行されているクエリの一部がキャンセルされる場合があります。
-
Amazon Redshift Serverless は、キューにクエリがない限り、RPU のスケールアップは実行しません。Amazon Redshift Serverless は、単一のクエリからの負荷の増加に応じた RPU のスケールアップは行いません。このため、リソースを大量に消費する単一のクエリの場合、その時点で処理容量がないと、ワークグループのメモリ不足を引き起こす可能性があります。データウェアハウスで実行する単一のクエリを処理するために十分なベース容量があることを確認します。
AI 主導のスケーリングと最適化 (プレビュー)
これは、プレビューリリースバージョンの Amazon Redshift Serverless での AI 主導のスケーリングと最適化に関するプレリリースドキュメントです。ドキュメントと機能はどちらも変更されることがあります。この機能については、テスト環境のみで使用し、本番環境では使用しないことをお勧めします。プレビューの利用規約については、「AWS のサービス条件 |
このプレビューは以下の AWS リージョン で使用できます。
-
米国東部 (オハイオ) (us-east-2)
-
米国東部 (バージニア北部) (us-east-1)
-
米国西部 (オレゴン) (us-west-2)
-
アジアパシフィック (東京) (ap-northeast-1)
-
欧州 (アイルランド) (eu-west-1)
-
欧州 (ストックホルム) (eu-north-1)
プレビューワークグループを作成して、Amazon Redshift Serverless の新機能をテストできます。これらの機能を本番稼働で使用したり、ワークグループを別のワークグループに移動したりすることはできません。プレビューの利用規約については、「AWS のサービス条件
また、ワークグループの料金パフォーマンス目標を設定して、Redshift がリソースを AI 主導で自動的に最適化できるようにすることもできます。これにより、コストを最適化しながら料金パフォーマンス目標を達成できます。このような料金パフォーマンスの自動最適化は、ワークロードに設定すべきベース容量が不明な場合や、割り当てられたリソースを増やすことでワークロードの一部で利点が得られる可能性がある場合に特に役立ちます。
例えば、通常 32 RPU しか必要としないワークロードを組織で実行していて、複雑なクエリが突然導入された場合、適切なベース容量が把握されていない場合があります。ベース容量を高く設定すると料金パフォーマンスは向上するとはいえ、コストも高くなるため、コストが予想と一致しない可能性があります。Amazon Redshift Serverless は、AI 主導のスケーリングとリソースの最適化を使用して、組織に応じて最適化されたコストを維持しながら、料金パフォーマンスの目標を満たすように RPU を自動的に調整します。この自動最適化は、ワークロードのサイズを問わず役に立ちます。自動最適化を使用すると、複雑なクエリが多数ある場合に、組織の料金パフォーマンス目標の達成につながります。
料金パフォーマンス目標は、ワークグループ独自の設定です。ワークグループによって、料金パフォーマンス目標が異なる場合があります。
コストを予測可能な状態に維持するには、Amazon Redshift Serverless がワークロードに割り当てることができる最大容量の制限を設定します。
料金パフォーマンスを設定するには、AWS コンソールを使用します。デフォルトでは、新しいワークグループを作成すると料金パフォーマンス目標が有効になり、[Balanced] に設定されます。別の料金パフォーマンス目標を設定したり、ワークグループのベース容量を指定したりするには、ワークグループの作成時にカスタマイズした設定を使用します。ワークグループの作成の詳細については、「名前空間を伴うワークグループの作成」を参照してください。
ワークグループの料金パフォーマンス目標を編集するには
-
Amazon Redshift Serverless コンソールで、[ワークグループの設定] を選択します。
-
料金パフォーマンス目標を編集するワークグループを選択します。[パフォーマンス] タブをクリックして、[編集] を選択します。
-
[Price-performance target] を選択して、ワークグループに設定する目標に応じてスライダーを調整します。
-
[Save changes] (変更の保存) をクリックします。
Amazon Redshift Serverless がワークロードに割り当てることができる RPU の最大量を更新するには、ワークグループ設定の [制限] タブに移動します。
AI 主導の最適化とリソーススケーリングの詳細については、次の動画をご覧ください。