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

最終更新日: 2022 年 9 月 30 日

Amazon Redshift クラスターのサイズ変更には、次の 4 つの方法があります。

• 伸縮自在なサイズ変更: オプションから伸縮自在なサイズ変更が選択できる場合は、このサイズ変更により、ノードタイプかノード数、またはその両方を変更します。ノード数のみを変更すると、クエリが一時的に停止され、接続は開かれたまま維持されることに注意してください。伸縮自在なサイズ変更には 10 ～ 15 分かかります。サイズ変更のオペレーション中は、クラスターは読み取り専用になります。
• 従来型サイズ変更: 従来型のサイズ変更を使用して、ノードタイプかノード数、またはその両方を変更します。伸縮自在なサイズ変更では使用できない設定でサイズを変更する場合、このオプションを選択します。データ サイズによっては、サイズ変更操作に 2 時間以上、最大で数日かかる場合があります。サイズ変更のオペレーション中は、ソースクラスターは読み取り専用になります。
• スナップショット、復元、およびサイズ変更: 従来のサイズ変更オペレーションの間、確実にクラスターを使用するためには、既存のクラスターをコピーしておきます。その後に、クラスターのサイズを新しく変更します。スナップショットの取得後にソースクラスターに書き込まれたデータは、手動でコピーする必要があります。新しく作成されたターゲットクラスターへの手動によるデータコピーは、移行が完了した後に行う必要があります。
• 高速の従来型サイズ変更: 高速の従来型サイズ変更は、その速度が伸縮自在のサイズ変更と同等で、また、従来型サイズ変更と同様の機能を備えています。このサイズ変更オペレーションには、主に 2 つの段階があります。ステージ 1 (クリティカルパス) では、データがソースクラスターからターゲットクラスターに移行され、ソースクラスターは読み取り専用モードになります。ステージ 2 (オフクリティカルパス) では、以前のデータ配信スタイルで行われたデータの再配布が、バックグラウンドで完了します。この段階の所要時間は、分散するボリュームとクラスターのワークロードによって異なります。

詳細については、「Amazon Redshift でのクラスター管理の概要」を参照してください。

クラスターが伸縮自在なサイズ変更に対応しているかどうかを確認するには、次の AWS CLI または AWS CloudShell コマンドを実行します。

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生する場合は、使用している AWS CLI が最新バージョンであるかを確認してください。

クラスターが伸縮自在なサイズ変更に対応している場合、AWS CLI の出力は次のようになります。

クラスターが伸縮自在なサイズ変更に対応していない場合、AWS CLI の出力は次のようになります。

サイズ変更の前に、既存およびターゲットのクラスターワークロードについてベンチマークテストを実行すると、サイズ変更の決定に役立てられます。

伸縮自在なサイズ変更を使用して、同じノードタイプでクラスターのサイズを変更しても、このオペレーションにより新しいクラスターは作成されません。その結果、オペレーションは速やかに完了します。従来のサイズ変更またはスナップショットや復元オペレーションに必要な時間は、次の要因によって異なる場合があります。

• ソースクラスターのワークロード。
• ソースクラスターからターゲットクラスターに転送されるテーブルの数とサイズ。
• コンピューティングノードとスライスの間で、データがどの程度均等に分散されているか。
• ソースクラスターとターゲットクラスターでのノード設定。

注: 大量のデータを含みノードが RA3 ではないクラスターで、従来型のサイズ変更を実行したは場合、データ移行が低速になることがあります。データが数テラバイト (TB) におよぶクラスターの移行には、数日を要する場合があります。ノードが RA3 の場合のデータ転送は、より早く完了します。

従来型サイズ変更、またはスナップショットと復元のオペレーションが必要とする時間を短縮するには、次を実行します。

• サイズ変更が高速で行われる RA3 ノードタイプに移行します。
• AWS ラボからテーブルインスペクタースクリプトを実行して、歪みのあるテーブルを識別します。偏ったテーブルを修正するには、適切な分散キーを選択します。詳細については、Amazon Redshift Engineering’s advanced table design playbook: Distribution styles and distribution keys を参照してください。
• 未使用のテーブルを削除します。AWS ラボからスキャンされていないテーブルを要約するスクリプトを実行し、未使用のテーブルを識別します。注: スキャンされていないテーブルの要約には、最近の履歴 (2～5 日間) のみが表示されます。長期間の使用状況をキャプチャするには、System Object Persistence Utility を使用します。
• AWS ラボ から、統計情報が欠落しているテーブルを特定し、それらのテーブルに対し ANALYZE コマンドを実行します。

サイズ変更でのパフォーマンス最適化の詳細については、「Top 10 performance tuning techniques for Amazon Redshift」(Amazon Redshift のパフォーマンスチューニング手法、上位 10 種類) を参照してください。

Amazon Redshift コンソールを使用してサイズ変更オペレーションのステータスを確認するには、クラスターの詳細ページで [Status] (ステータス) タブを選択します。[ステータス] タブには、平均転送速度、経過時間、残り時間が表示されます。

• サイズ変更オペレーション中にテーブルのサイズが増減します。これは想定された動作です。詳細については、「Amazon Redshift クラスターのテーブルが想定と異なるディスクストレージを消費していますが、なぜですか?」を参照してください。
• AWS CLI でクラスターのステータスが [NONE] の場合は、ターゲットクラスターはまだプロビジョニング中です。ターゲットクラスターのプロビジョニング中は、クラスターのコピーはまだ実行されていません。ターゲットクラスターのプロビジョニングが終了すると、ステータスは [IN_PROGRESS] に変わります。
• AWS CloudFormation StackSetsが「An internal error has occurred.Please try your query again at a later time (内部エラーが発生しました。後で再度クエリを実行してください。)」というエラーでサイズ変更に失敗した場合。対象のクラスターが、伸縮自在なサイズ変更に対応しているかどうかを確認してください。デフォルトで Classic:False がセットされているのであれば、CloudFormation スタックは伸縮自在なサイズ変更を使用します。
• 「Please choose a larger target cluster (大きなターゲットクラスターを選択してください)」というエラーメッセージが表示された場合は、ターゲットクラスターがデータを収容しきれていません。ノードを増やすか、別のノードタイプを使用して、Amazon Redshift クラスターのサイズを変更してください。
• サイズ変更オペレーションが完了する前にキャンセルするには、Amazon Redshift コンソールのクラスターリストから [サイズ変更のキャンセル] を選択します。詳細については、スナップショット、リストア、サイズ変更を参照してください。

• サイズ変更オペレーションのあいだは、使用可能なクラスターの料金が請求されます。たとえば、サイズ変更オペレーション中にソース設定に応じた料金が発生します。サイズ変更が完了したら、ソース設定への請求はなくなります。クラスターステータスが [Available] (利用可能) になると、すぐにターゲット設定への請求が開始されます。
• より小さなノードタイプ (large、xlarge) からより大きなノードタイプ (8xlarge) にサイズ変更すると、そのクラスターでは、ノードごとにより多くのストレージが必要になります。ノードあたりのストレージが多いほど、COMMIT の実行時により多くのメタデータが書き込まれます。したがって、より大きなノードでは 1 つの COMMIT オペレーションでの基本料金が高くなります。複数の小さな COMMIT オペレーションを同時に実行すると、パフォーマンスの低下が生じることがあります。パフォーマンスを向上させるには、複数の変更内容を、それぞれ 1 つの COMMIT オペレーションにグループ化します。
• リザーブドインスタンスを購入した場合、請求額はサイズ変更したクラスターの設定、リザーブドノードのタイプ、およびリザーブドノードの数に依存します。詳細については、リザーブドノードの動作を参照してください。