Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# Amazon Redshift Serverless 容量を計算する
Amazon Redshift Serverless では、ワークロードの要件に合わせてコンピューティングキャパシティが自動的にスケールアップおよびスケールダウンします。コンピューティングキャパシティとは、Amazon Redshift Serverless ワークロードに割り当てられた処理能力とメモリを指します。一般的なユースケースには、ピークトラフィック期間の処理、複雑な分析の実行、大量のデータの効率的な処理などがあります。以下の用語は、Amazon Redshift がコンピューティングキャパシティを管理する方法の詳細を示します。
**RPU**
Amazon Redshift Serverless では、Redshift プロセッシング単位 (RPU) で、データウェアハウスの容量が測定されています。RPU は、ワークロードの処理に使用されるリソースです。1 つの RPU が 16 GB のメモリを提供します。
**基本容量**
この設定は、Amazon Redshift Serverless がクエリの処理に使用するデータウェアハウスの基本容量を指定します。基本容量は、RPU で指定します。基本の容量は、Redshift 処理ユニット (RPU) で設定できます。ベース容量を大きく設定することで、特に大量のリソースを必要とするデータ処理ジョブでは、クエリのパフォーマンスが向上します。Amazon Redshift Serverless のデフォルトの基本容量は、128 RPU です。**ベース容量**設定は、4 RPU～512 RPU の間で調整できます。この値は、4 RPU に設定するか、8 RPU 以上に 8 の増分で (8、16、24...512) 設定できます。この値は、AWS コンソール、`UpdateWorkgroup` API オペレーション、または AWS CLI の `update-workgroup` オペレーションを使用して設定できます。
最小ベース容量の 4 RPU では、データウェアハウスのコストと容量の要件に基づいて、より単純なワークロードからより複雑なワークロードまで柔軟に実行できます。ベース容量の 4 RPU は 32 TB 未満のデータを含むウェアハウスを対象とし、ベース容量の 8、16、24 RPU は 128 TB 未満のデータを必要とするワークロードを対象としています。データ要件が 128 TB を超える場合は、最低 32 RPU のベース容量を使用する必要があります。さらに、列数が多くて同時実行性が高いテーブルがあるワークロードでは、32 RPU 以上のベース容量を使用することをお勧めします。
使用可能な最大ベース容量である 1024 RPU は、ワークロードに最高レベルのコンピューティングリソースを追加します。これにより、複雑性の高いワークロードをサポートする柔軟性が向上し、データのロードとクエリが高速化されます。
**注記**
拡張された最大ベース容量の 1024 RPU は、次の AWS リージョンで使用できます。他のリージョンの場合、最大ベース容量は 512 RPU です。
米国東部 (バージニア北部)
米国東部 (オハイオ)
米国西部 (オレゴン)
欧州 (アイルランド)
欧州 (フランクフルト)
基本容量を 512-1024 に設定すると、RPU を 32 単位で増減できます。
大規模で複雑なワークロードを管理する場合は、Redshift Serverless データウェアハウスのサイズを増やすことを検討してください。大規模なウェアハウスは、より多くのコンピューティングリソースにアクセスできるため、クエリをより効率的に処理できます。
基本容量を増やすことが有益であるインスタンスを次に示します。
+ 実行に時間がかかる複雑なクエリがある
+ テーブルに多数の列がある
+ クエリに多数の JOIN がある
+ クエリが、データレイクなどの外部ソースから大量のデータを集約またはスキャンする
Amazon Redshift Serverless のクォータと制限の詳細については、「[Amazon Redshift Serverless オブジェクトのクォータ](amazon-redshift-limits.md#serverless-limits-account)」を参照してください。
## Amazon Redshift Serverless 容量に関する考慮事項と制限
Amazon Redshift Serverless 容量に関する考慮事項と制限事項は次のとおりです。Redshift Serverless の一般的な考慮事項については、「[Amazon Redshift サーバーレスを使用する場合の考慮事項](serverless-usage-considerations.md)」を参照してください。
+ ベース容量が 4 RPU の設定では、最大 32 TB のマネージドストレージ容量をサポートします。32 TB を超えるマネージドストレージを使用している場合は、8 RPU 未満にベース RPU を設定することはできません。
+ ベース容量が 8 RPU または 16 RPU の設定では、最大 128 TB の Redshift マネージドストレージ容量をサポートします。128 TB を超えるマネージドストレージを使用している場合は、32 RPU 未満にベースを設定することはできません。
+ ワークグループのベース容量を編集すると、ワークグループで実行されているクエリの一部がキャンセルされる場合があります。
+ Redshift Serverless は、以下の増分を使用してデータウェアハウスの RPU をスケールします。
+ 4～8 RPU: 4 RPU ずつ増加します。
+ 8～512 RPU: 8 RPU ずつ増加します。
+ 512～1024 RPU: 32 RPU ずつ増加します。
+ バキュームブーストは 8 RPU 以上でのみサポートされています。8 RPU 以下の場合は、代わりに次のコマンドを使用します。
```
VACUUM [FULL | SORT ONLY | DELETE ONLY | REINDEX | RECLUSTER] [table_name] [TO threshold PERCENT]
```
### 4 つの Redshift 処理ユニット (RPU) 容量を持つ Redshift Serverless
ベース容量として 4 RPU を持つ Redshift Serverless は、小規模または要求の少ないワークロードに最適です。このエントリポイントは、柔軟で費用対効果の高いソリューションを提供します。このエントリレベルの設定は、以下のリソース (最大) を持つデータウェアハウスをサポートします。
+ 最大 32 TB の Redshift マネージドストレージ。
+ テーブルあたり最大 100 列
+ 64 GB のメモリ
これらの制限を超える必要がある場合は、自動スケーリングに依存せずに、ベース容量を手動で増やす必要があります。データウェアハウスを 4 RPU を超えてスケールすると、データウェアハウスは引き続きより多くの RPU を使用し、Amazon Redshift はデータウェアハウスを 4 RPU にスケールダウンしなくなります。
**注記**
ベース容量として 4 RPU を使用する場合、100 列を超えるテーブルを作成できますが、テーブルは 100 列に制限することをお勧めします。この制限を超えると、クエリの実行中にデータウェアハウスのメモリが枯渇してパフォーマンスが低下する場合があります。
以下の AWS リージョンでは、4 RPU を使用するデータウェアハウスを作成できます。
+ 米国東部(オハイオ)
+ 米国東部 (バージニア北部)
+ 米国西部 (北カリフォルニア)
+ 米国西部 (オレゴン)
+ アジアパシフィック (ムンバイ)
+ アジアパシフィック (シンガポール)
+ アジアパシフィック (シドニー)
+ アジアパシフィック (東京)
+ 欧州 (アイルランド)
+ 欧州 (ストックホルム)
## AI 主導のスケーリングと最適化
AI 主導のスケーリングと最適化の機能は、Amazon Redshift Serverless が利用可能なすべての AWS リージョンで利用できます。
Amazon Redshift Serverless には、さまざまなワークロード要件に対応するため、AI 主導の高度なスケーリングと最適化の機能が用意されています。データウェアハウスは、以下のプロビジョニングの課題を抱える場合があります。
+ リソースを大量に消費するクエリのパフォーマンス向上のため、データウェアハウスが過剰にプロビジョニングされる場合がある
+ コスト削減のため、データウェアハウスがプロビジョニング不足になる可能性がある
データウェアハウスのワークロードのパフォーマンスとコストの適切なバランスを取るのは、特にアドホッククエリやデータ量が増加する場合には困難です。リソースの消費量が多いクエリと少ないクエリが混在するワークロードを実行している場合には、インテリジェントなスケーリングが必要です。AI 主導のスケーリングと最適化の機能は、データの増加に応じて Serverless コンピューティング (RPU) を自動的にスケールします。また、コストパフォーマンス目標の範囲内でクエリのパフォーマンスを維持するためにも、この機能が役立ちます。データ量が増えるに従ってコンピューティングリソースが動的に割り当てられるので、クエリが引き続きパフォーマンス目標を達成できます。AI 主導のスケーリングと最適化のおかげで、サービスは変動的なワークロード要件にシームレスに適応することができ、手動による介入や複雑なキャパシティプランニングは必要ありません。
Amazon Redshift Serverless は、クエリの複雑さやデータ量などの要因に基づいて、より包括的で応答性の高いスケーリングソリューションを提供します。この機能により、多様なワークロードや増大するデータセットを柔軟かつ効率的に処理しつつ、ワークロードのコストパフォーマンスを最適化できます。Amazon Redshift Serverless は、Serverless ワークグループに対して指定されたコストパフォーマンス目標を達成するため、Amazon Redshift Serverless エンドポイントに対して AI 主導の最適化を自動的に行います。このような料金パフォーマンスの自動最適化は、ワークロードに設定すべきベース容量が不明な場合や、割り当てられたリソースを増やすことでワークロードの一部で利点が得られる可能性がある場合に特に役立ちます。
**例**
組織で通常実行しているワークロードは 32 RPU しか必要としないのに、突如さらに複雑なクエリが導入された場合、適切なベース容量がわからない場合があります。ベース容量を高く設定すればパフォーマンスは向上しますが、コストも高くなり、コスト予想から外れる可能性があります。Amazon Redshift Serverless は、AI 主導のスケーリングとリソースの最適化を使用して、組織に応じて最適化されたコストを維持しながら、料金パフォーマンスの目標を満たすように RPU を自動的に調整します。この自動最適化は、ワークロードのサイズを問わず役に立ちます。自動最適化を使用すると、複雑なクエリが多数ある場合に、組織の料金パフォーマンス目標の達成につながります。
**注記**
料金パフォーマンス目標は、ワークグループ独自の設定です。ワークグループによって、料金パフォーマンス目標が異なる場合があります。
コストを予測可能な状態に維持するには、Amazon Redshift Serverless がワークロードに割り当てることができる最大容量の制限を設定します。
料金パフォーマンスを設定するには、AWS コンソールを使用します。Serverless ワークグループの作成時に、コストパフォーマンス目標を明示的に有効にしておく必要があります。Serverless ワークグループを作成した後で、コストパフォーマンス目標を変更することもできます。コストパフォーマンス目標を有効にすると、デフォルトでは **[バランスを取る]** に設定されます。
**ワークグループのコストパフォーマンス目標を編集するには**
1. Amazon Redshift Serverless コンソールで、**[ワークグループの設定]** を選択します。
1. 料金パフォーマンス目標を編集するワークグループを選択します。**[パフォーマンス]** タブをクリックして、**[編集]** を選択します。
1. **[コストパフォーマンス目標]** を選択し、スライダーを希望の設定に調整します。
1. **[Save changes]** (変更の保存) をクリックします。
1. Amazon Redshift Serverless がワークロードに割り当てることができる RPU の最大量を変更するには、**[ワークグループの設定]** の **[制限]** タブを選択します。
**[コストパフォーマンス目標]** スライダーを使用して、コストとパフォーマンスの必要なバランスを設定できます。スライダーを動かして、次のいずれかのオプションを選択できます。
+ **[コストの最適化]** - コスト削減を優先します。Amazon Redshift Serverless は、追加料金が発生しない場合は、コンピューティングキャパシティを自動的にスケールアップしようとします。コンピューティングリソースのスケールダウンも試みてコストを削減し、クエリランタイムの向上も図ります。
+ **[バランスを取る]** - パフォーマンスとコストのバランスを図ります。パフォーマンスに配慮してスケールされる分、コストが若干増減する可能性があります。ほとんどの Amazon Redshift Serverless データウェアハウスでは、この設定が推奨されます。
+ **[パフォーマンスの最適化]** - パフォーマンスを優先します。Amazon Redshift はパフォーマンス向上のために積極的にスケールするので、コスト増を招く場合があります。
+ 中間位置: スライダーを **[バランスを取る]** と **[コストの最適化]** との中間位置、または **[パフォーマンスの最適化]** との中間位置に設定することもできます。コストまたはパフォーマンスの最適化に振り切るとやりすぎになる場合は、これらの設定を使用してください。
### コストパフォーマンス目標を選択する際の考慮事項
コストパフォーマンスのスライダーを使用して、ワークロードに必要なコストパフォーマンス目標を選択できます。AI 主導のスケーリングと最適化のアルゴリズムは、時間が経つにつれてワークロード履歴から学習するので、予測と決断の精度が向上します。
**例**
この例では、所要時間が 7 分、コストが 7 USD のクエリについて考えてみます。次の図は、スケーリングなしの場合のクエリのランタイムとコストを示しています。
![\[Amazon Redshift Serverless 自動スケーリングのサンプルクエリのグラフ。\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/images/autoscale_example_query.png)
次に示すように、クエリはいくつかの異なる方法でスケールされます。選択したコストパフォーマンス目標に基づいて、AI 主導のスケーリングはクエリのパフォーマンスとコストのトレードオフを予測し、それに応じてスケールします。さまざまなスライダーオプションを選択した場合の結果は、次のようになります。
![\[Amazon Redshift Serverless 自動スケーリングのサンプルクエリのグラフ。\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/images/autoscale_example_scaling.png)
+ **[コストの最適化]** - **[コストの最適化]** オプションを選択した場合、データウェアハウスはコスト削減の選択肢を優先してスケールします。前の例では、超線形スケーリングアプローチがこの動作を示しています。スケーリングは、スケーリングモデル予測に従って、費用対効果の高い方法で実行できる場合にのみ行われます。スケーリングモデルが、特定のワークロードに対してコスト最適化スケーリングができないと予測した場合、データウェアハウスはスケールしません。
+ **[バランスを取る]** - **[バランスを取る]** を選択した場合、システムはコストとパフォーマンスの両方の考慮事項のバランスを取りながらスケールし、コストは限られた範囲で増加する場合があります。**[バランスを取る]** オプションは、超線形、線形、場合によっては劣線形のワークロードスケーリングを実行します。
+ **[パフォーマンスの最適化]** - **[パフォーマンスの最適化]** オプションを選択した場合は、パフォーマンスを向上させる前述の方法に加えて、コストが高くなり、ランタイムが釣り合う形で改善されない場合でもスケールされます。**[パフォーマンスの最適化]** では、システムは可能であれば超線形スケーリング、線形スケーリング、劣線形スケーリングを実行します。スライダーの位置が **[パフォーマンスの最適化]** 位置に近いほど、Amazon Redshift Serverless で劣線形スケーリングが許容されやすくなります。
**[コストパフォーマンス]** スライダーを設定するときは、次の点に注意してください。
+ コストパフォーマンスの設定はいつでも変更できますが、ワークロードのスケーリングはすぐには変更されません。スケーリングは、システムが現状のワークロードについて学習する従い、時間の経過とともに変化します。Serverless ワークグループを 1～3 日間モニタリングして、新しい設定の影響を確認することをお勧めします。
+ コストパフォーマンススライダーのオプション **[最大容量]** と **[最大 RPU 時間]** は連携します。**[最大容量]** と **[最大 RPU 時間]** は、Amazon Redshift Serverless でデータウェアハウスがスケールできる最大 RPU と、Amazon Redshift Serverless でデータウェアハウスが消費できる最大 RPU 時間を制限するコントロールです。Amazon Redshift Serverless では、コストパフォーマンス目標の設定に関係なく、常にこれらの設定が尊重および適用されます。
### リソースの自動スケーリングのモニタリング
AI 主導の RPU スケーリングは、次の方法でモニタリングできます。
+ Amazon Redshift コンソールで RPU の使用済み容量のグラフを確認します。
+ CloudWatch で `AWS/Redshift-Serverless` および `Workgroup` の `ComputeCapacity` メトリクスをモニタリングします。
+ [SYS\$1QUERY\$1HISTORY](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_HISTORY.html) ビューをクエリします。特定のクエリ ID またはクエリテキストを指定して、期間を特定します。この期間を使用して [SYS\$1SERVERLESS\$1USAGE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_SERVERLESS_USAGE.html) システムビューをクエリし、`compute_capacity` 値を見つけます。`compute_capacity` フィールドには、クエリランタイム中にスケールされた RPU が表示されます。
次の例を参考にして、`SYS_QUERY_HISTORY` ビューをクエリします。サンプル値を実際のクエリテキストに置き換えてください。
```
select query_id,query_text,start_time,end_time, elapsed_time/1000000.0 duration_in_seconds
from sys_query_history
where query_text like ''
and query_text not like '%sys_query_history%'
order by start_time desc
```
次のクエリを実行して、`compute_capacity` が `start_time` から `end_time` の期間中にどのようにスケールされたかを確認します。次のクエリの `start_time` と `end_time` を前述のクエリの出力に置き換えます。
```
select * from sys_serverless_usage
where end_time >= 'start_time'
and end_time <= DATEADD(minute,1,'end_time')
order by end_time asc
```
これらの機能を使用する具体的な手順については、「[Configure monitoring, limits, and alarms in Amazon Redshift Serverless to keep costs predictable](https://aws.amazon.com/blogs/big-data/configure-monitoring-limits-and-alarms-in-amazon-redshift-serverless-to-keep-costs-predictable/)」を参照してください。
### AI 主導のスケーリングと最適化を使用する際の考慮事項
AI 主導のスケーリングと最適化を使用する場合は、次の点を考慮してください。
+ 32～512 のベース RPU を必要とする Amazon Redshift Serverless の既存のワークロードでは、最適な結果を得るために Amazon Redshift Serverless の AI 主導のスケーリングと最適化を使用することをお勧めします。ベース RPU が 32 未満または 512 超のワークロードでは、この機能の使用は推奨されません。
+ コストパフォーマンス目標はワークロードを自動的に最適化しますが、その結果は異なる場合があります。システムが特定のパターンを学習できるように、代表的なワークロードを実行して、この機能をしばらく時間をかけて使用することをお勧めします。
+ AI 主導のスケーリングと最適化は、Amazon Redshift Serverless インスタンスで実行されているワークロードに応じて、最適な時間を使用して Serverless ワークグループに最適化を適用します。
AI 主導の最適化とリソーススケーリングの詳細については、次の動画をご覧ください。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/U3f2FObbvKc)