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

所要時間2分

Amazon Redshift クラスターのサイズを変更することを検討しており、それがパフォーマンスと請求にどのように影響するかを知りたいと思っています。

解決策

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

伸縮自在なサイズ変更: 伸縮自在なサイズ変更がオプションとして利用できる場合は、これを使用してノードタイプ、ノード数、またはその両方を変更します。ノード数のみを変更すると、クエリは一時的に一時停止され、接続は開いたままになります。伸縮自在なサイズ変更には 10〜15 分かかります。サイズ変更操作中、クラスターは読み取り専用になります。
従来のサイズ変更: クラスターのサイズまたはノードの変更が伸縮自在なサイズ変更でサポートされていない場合は、従来のサイズ変更を使用してください。従来のサイズ変更は、ターゲットクラスターを作成し、データとメタデータをソースクラスターからターゲットに移行します。ターゲットノードタイプ RA3 を使用すると、ソースクラスターが再起動し、数分間使用できなくなります。再起動後、クラスターは読み取りおよび書き込み操作が可能になります。サイズ変更はバックグラウンドで続行されます。別のタイプのターゲットノードを使用する場合、再起動後、データがターゲットクラスターに移行される間、クラスターは読み取り専用になります。移行が完了すると、ターゲットクラスターはエンドポイントで更新され、読み取りおよび書き込みタスクが可能になります。使用するターゲットノードタイプの詳細については、「従来のサイズ変更」を参照してください。
スナップショット、復元、サイズ変更: 従来のサイズ変更操作中にクラスターが使用可能であることを確認するには、まず既存のクラスターをコピーします。次に、新しいクラスターのサイズを変更します。スナップショットの作成後にデータをソースクラスターに書き込む場合は、データを手動でコピーする必要があります。新しく作成されたターゲットクラスターへのこの手動データコピーは、移行が完了した後に行う必要があります。

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

サイズ変更の前提条件

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

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

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新バージョンの AWS CLI を使用していることを確認してください。クラスターが伸縮自在なサイズ変更の対象になっている場合、出力は AWS CLI の次の例のようになります。

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

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

{
  "NodeConfigurationOptionList": []
}

パフォーマンスベンチマーク

サイズ変更の決定に利用するため、既存のクラスターワークロードとターゲットクラスターワークロードでベンチマークテストを実行します。

サイズ変更のオペレーション速度

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

ソースクラスターのワークロード。
ソースからターゲットクラスターに転送されたテーブルの数とサイズ。
データがコンピュートノードとスライス全体にどれだけ均等に分散されているか。
ソースクラスターとターゲットクラスターのノード構成。

注: 大量のデータがあるクラスターで従来のサイズ変更を実行し、ノードが RA3 ではない場合、データ移行が遅くなる可能性があります。数テラバイト (TB) のデータを含むクラスターの移行には数日かかることがあります。RA3 ノードのデータ転送はより迅速に完了します。

オペレーション速度を最適化する

従来のサイズ変更またはスナップショットと復元操作に必要な時間を短縮するには、次の操作を行います。

RA3 ノードタイプに移行します。サイズ変更が速くなります。
GitHub ウェブサイトの AWS ラボのリポジトリからテーブルインスペクタースクリプトを実行して、偏りのあるテーブルを特定します。適切な分散キーを選択してテーブルの偏りを修正します。詳細については、「Amazon Redshift エンジニアリングの高度なテーブルデザインプレイブック: 分散スタイルと分散キー」を参照してください。
未使用のテーブルを削除します。未使用のテーブルを特定するには、GitHub ウェブサイトの AWS ラボのリポジトリからスキャンされていないテーブルの概要スクリプトを実行します。
注: スキャンされていないテーブルの概要には、最近の履歴 (2～5 日間) のみが表示されます。GitHub ウェブサイトのシステムオブジェクト永続化ユーティリティを使用して、長期間にわたる使用状況データをキャプチャします。
GitHub ウェブサイトの AWS ラボリポジトリから、統計が欠落しているテーブルを特定します。次に、それらのテーブルで ANALYZE コマンドを実行します。

サイズ変更パフォーマンスの最適化の詳細については、「Amazon Redshift のパフォーマンスチューニングテクニック Top 10」を参照してください。Amazon Redshift コンソールを使用してサイズ変更オペレーションのステータスを確認するには、クラスターの詳細ページの [ステータス] タブを選択します。[ステータス] タブには、平均転送レート、経過時間、残り時間が表示されます。

トラブルシューティング

サイズ変更操作中、テーブルのサイズは増減します。この動作は想定されているものです。詳細については、「Amazon Redshift クラスター内のテーブルが消費するディスクストレージ容量が予想よりも多いまたは少ないのはなぜですか?」を参照してください。
AWS CLI でクラスターのステータスが NONE の場合、ターゲットクラスターはまだプロビジョニング中です。ターゲットクラスターがプロビジョニングされている時点では、まだコピーされていません。ターゲットクラスターがプロビジョニングされると、ステータスは IN_PROGRESS に変わります。
AWS CloudFormation StackSets のサイズが変更されず、内部エラーメッセージが表示される場合は、クラスターが伸縮自在なサイズ変更の対象かどうかを確認してください。エラーメッセージは次のようなものです。「An internal error has occurred.Please try your query again at a later time.」これは、CloudFormation スタックが伸縮自在なサイズ変更を使用しており、Classic:false がデフォルトで設定されているために発生します。
「Please choose a larger target cluster,」というエラーメッセージが表示される場合、データはターゲットクラスターに収まりません。ノードの数を増やすか、別のノードタイプに変更して Amazon Redshift クラスターのサイズを変更してください。
Amazon Redshift コンソールのクラスターリストから [サイズ変更をキャンセル] を選択して、サイズ変更オペレーションを完了する前にキャンセルします。詳しくは、「スナップショット、復元、サイズ変更」を参照してください。

サイズ変更されたクラスターの請求

サイズ変更の実施中は、使用可能なクラスターの料金が請求されます。たとえば、サイズ変更の実施中は、ソース構成の料金が請求されます。サイズ変更が完了すると、ソース構成に対する請求は発生しなくなります。クラスターのステータスが使用可能に変わるとすぐに、ターゲット構成の請求が開始されます。
小さいノードタイプ (large、xlarge) を大きいノードタイプ (8xlarge) にサイズ変更すると、クラスターはノードごとにより多くのストレージを必要とします。ノードあたりのストレージが多いほど、COMMIT を実行したときに書き込まれるメタデータが多くなります。したがって、単一の COMMIT オペレーションの基本コストは、ノードが大きいほど高くなります。複数の小さな COMMIT オペレーションを同時に実行すると、パフォーマンスが低下する可能性があります。パフォーマンスを向上させるには、複数の変更を 1 つの COMMIT オペレーションにまとめます。
リザーブドインスタンスを購入した場合、請求額はサイズ変更されたクラスター設定、リザーブドノードタイプ、リザーブドノード数によって異なります。詳細については、「リザーブドノードの動作」を参照してください。