AWS re:Post Knowledge Center Feedback Survey

Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.

Amazon Redshift クラスターのサイズを変更する方法を教えてください。

所要時間2分

Amazon Redshift クラスターのサイズを変更したいのですが、リサイズによるパフォーマンスと料金に対する影響を把握しておきたいです。

簡単な説明

クラスターのサイズを変更するには、Elastic リサイズまたは Classic リサイズを使用します。クラスターが適格である場合は、Elastic リサイズの使用をおすすめします。クラスターが適格でない場合は、Classic リサイズを使用してください。

解決策

クラスターの適格性を判断する

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

クラスターが Elastic リサイズに対応しているかどうかを確認するには、AWS CLI コマンド describe-node-configuration-options を実行します。

aws redshift describe-node-configuration-options --cluster-identifier example-cluster-id --action-type resize-cluster

注: example-cluster-id を実際のクラスター ID に置き換えてください。

クラスターが Elastic リサイズに対応している場合、次のような出力が行われます。

{
  "NodeConfigurationOptionList": [
    {
      "NodeType": "dc2.large",
      "NumberOfNodes": 2,
      "EstimatedDiskUtilizationPercent": 0.01
    },
    {
      "NodeType": "ra3.16xlarge",
      "NumberOfNodes": 2,
      "EstimatedDiskUtilizationPercent": 0.01
    }
  ]
}

クラスターが Elastic リサイズの対象ではない場合、次のような出力が行われます。

{
  "NodeConfigurationOptionList": []
}

操作時間を短縮する

同じノードタイプのクラスターに Elastic リサイズを使用する場合、操作では新しいクラスターは作成されず、すぐに完了します。

Classic リサイズを使用する場合、操作時間は次の要因によって異なります。

ソースクラスターのワークロード。
ソースクラスターからターゲットクラスターに転送するテーブルの数とサイズ。
複数のコンピューティングノードとスライスにおけるデータの分布。
ソースクラスターとターゲットクラスターのノード構成。

Classic リサイズの所要時間を短縮するには、次の操作を行います。

RA3 ノードタイプに移行します。
不均一テーブルを特定して修正します。不均一テーブルを特定するには、AWS Labs の table inspector スクリプトを実行します。詳細については、GitHub のウェブサイトで table_inspector を参照してください。不均一テーブルを修正するには、適切な分散キーを選択します。
使用中でないテーブルを削除します。未使用テーブルを特定するには、AWS Labs の unscanned table summary スクリプトを実行します。詳細については、GitHub のウェブサイトで unscanned_table_summary を参照してください。
注: スキャンされていないテーブルの概要には、過去 2 ～ 5 日間の最近の履歴のみが表示されます。長期間の使用状況データをキャプチャするには、システムオブジェクトの永続化ユーティリティを使用します。詳細については、GitHub のウェブサイトで SystemTablePersistence を参照してください。
欠落しているテーブルデータを特定します。欠落しているテーブルデータを特定するには、AWS Labs の missing_table_stats スクリプトを使用します。詳細については、GitHub のウェブサイトで missing_table_stats を参照してください。次に、特定したテーブルに ANALYZE コマンドを実行します。

リサイズのパフォーマンス最適化に関する詳細については、「Amazon Redshift のパフォーマンス調整手法: トップ 10」を参照してください。Amazon Redshift コンソールを使用してリサイズ操作のステータスを確認するには、クラスターの詳細ページで [ステータス] タブを選択します。[ステータス] タブには、平均転送速度、経過時間、残り時間が表示されます。

クラスターのサイズを変更する

Elastic リサイズを使用してクラスターのノードタイプ、ノード数、またはその両方を変更します。

Elastic リサイズではクラスターのサイズまたはノードタイプの変更がサポートされていない場合は、Classic リサイズを使用します。

リサイズ操作のトラブルシューティング

リサイズ操作中、テーブルのサイズは増減する場合があります。詳細については、「Amazon Redshift プロビジョンドクラスターのテーブルが消費するストレージ容量が、想定より多くなったり少なくなったりする理由を知りたいです」を参照してください。

AWS CLI でクラスターのステータスが NONE と表示される場合、Amazon Redshift はまだターゲットクラスターをプロビジョニングしています。ターゲットクラスターのコピーは、プロビジョニング段階が完了するまで行われません。Amazon Redshift がターゲットクラスターをプロビジョニングすると、ステータスは IN_PROGRESS に変わります。

AWS CloudFormation StackSets のサイズが変更されず、内部エラーメッセージが表示される場合は、クラスターが Elastic リサイズの対象かどうかを確認してください。エラーメッセージの例を次に示します。「An internal error has occurred.Please try your query again at a later time. (後ほどクエリを再試行してください)」この問題は、CloudFormation スタックが Elastic リサイズを使用しており、デフォルトで Classic:false が設定されていることが原因で発生します。

「Please choose a larger target cluster,」というエラーメッセージが表示される場合、データをターゲットクラスターに格納できないことを示しています。ノードの数を増やすか、別のノードタイプに変更して Amazon Redshift クラスターのサイズを変更してください。

Classic リサイズ操作を完了前にキャンセルするには、Amazon Redshift コンソールのクラスターリストで [リサイズのキャンセル] を選択します。

サイズ変更されたクラスターに対する料金

リサイズ操作の実行中、AWS では使用可能なクラスターに対する料金が発生します。たとえば、リサイズ操作の実行中は、AWS ではソースの構成に対して料金が発生します。リサイズの完了後は、AWS ではソースの構成に対する料金は発生しません。クラスターのステータスが Available に変更された時点で、ターゲットの構成に対する請求が開始されます。

小容量ノードタイプ (例: large、xlarge) を大容量ノードタイプ (例: 8xlarge) にサイズ変更すると、クラスターではノードごとにより多くのストレージを必要とします。ノードあたりのストレージが増えると、COMMIT 操作の実行時に書き込まれるメタデータも増加します。したがって、単一の COMMIT 操作に対する基本コストは、ノードが大きいほど高くなります。複数の小さな COMMIT オペレーションを同時に実行すると、パフォーマンスが低下する可能性があります。パフォーマンスを向上させるには、複数の変更を単一の COMMIT 操作にまとめます。

リザーブドインスタンスを購入した場合、料金はリサイズしたクラスターの構成、リザーブドノードタイプ、リザーブドノード数によって異なります。詳細については、「リザーブドノードの動作」を参照してください。