Amazon Redshift クラスターのサイズ変更をやってみた

2019.08.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS事業本部@福岡オフィスの梶原です。 Amazon Redshift クラスターのサイズ変更を実施する機会がありましたので、作業手順を共有します。

Redshiftのクラスターのサイズ変更を行う際にはElastic-Resize(伸縮自在なサイズ変更)Classic-Resize(従来のサイズ変更)があります。 また、メンテナンスウィンドウなどを設けず、クラスターへの書き込みを継続する必要がある場合には、「スナップショット、復元、およびサイズ変更」の一連の作業を実施しつつ、移行途中に書き込まれたデータを転送する必要があります。

Elastic-Resize(伸縮自在なサイズ変更)とは

伸縮自在なサイズ変更は、クラスターのサイズを変更する最速の方法です。伸縮自在なサイズ変更は、既存のクラスターにあるノードを追加または削除し、自動的にデータを新しいノードに再分散します。新しいクラスターを作成しないため、伸縮自在なサイズ変更オペレーションは、素早く (通常は数分以内に) 完了します。

https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/rs-resize-tutorial.html#elastic-resize

Classic-Resize(従来のサイズ変更)とは

従来のサイズ変更オペレーションでは、データはコンピューティングノードまたはソースクラスターのノードから、コンピューティングノードまたはターゲットクラスターのノードに並列コピーされます。これに要する時間は、小さい方のクラスターにあるデータの量とノードの数によって異なります。数時間で終わることもあれば、2~3 日かかる可能性もあります。

https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/rs-resize-tutorial.html#classic-resize

Elastic-Resizeの制約、注意事項など

上記の内容を鑑みると、Classic-Resizeの場合、Elastic-Resizeに比べサイズ変更が終了するまでの時間に大きく隔たりがあるため、積極的にClassic-Resizeを選択する理由はあまりないかと思いますが、現時点では下記の制約事項がありますので、制約事項に当てはまる場合は、Classic-Resizeを実施する必要があることをご承知おきください

  • Amazon Redshiftクラスタのバージョンが1.0.4852以上
  • 単一ノードクラスターは不可
  • 伸縮自在なサイズ変更は、EC2 VPC プラットフォームを使用するクラスターにのみ使用できます。
  • 新しいノード設定では、既存のデータに対して十分なストレージが必要です。ノードを追加するときでも、データが再分配される方法のために、新しい設定に十分なストレージがない場合があります。
  • (特にノード数を減らす場合には実施できない場合がありますので、ご注意ください)
  • リサイズ時にはバキューム操作は行われないため、リサイズ後にバキューム操作が必要な場合は別途、実施を計画する必要があります。

Elastic-Resizeで変更可能なノード数

Elastic-Resizeでリサイズ可能なノード数を表にまとめると下記のようになります。 元のノード数についてはすべては掲載していませんが ds2.large, dc2.largeについては、元のノード数の半分, or 2倍 ds2.8xlarge, dc2.8xlargについては、元のノード数の半分まで減らすことができる, or 2倍まで増やすことが可能です。 リサイズ後に1/2以下または、2倍以上にリサイズしたい場合はClassic-Resizeを実施します。

ds2.large,dc2.large

ノードタイプ 元のノード数 減少(x 1/2) 増加(x 2)
ds2.large, dc2.large 1 - 2
ds2.large, dc2.large 2 1 4
ds2.large, dc2.large 4 2 8
ds2.large, dc2.large 8 4 16
ds2.large, dc2.large 16 8 32
ds2.large, dc2.large 32 16 -

ds2.8xlarge,dc2.8xlarge

ノードタイプ 元のノード数 減少(x 1/2 最小) 増加(x 2最大)
ds2.8xlarge, dc2.8xlarge 2 - 3~4
ds2.8xlarge, dc2.8xlarge 4 2~3 5~8
ds2.8xlarge, dc2.8xlarge 8 4~7 9~16
ds2.8xlarge, dc2.8xlarge 16 8~15 17~32
ds2.8xlarge, dc2.8xlarge 32 16~31 33~64
ds2.8xlarge, dc2.8xlarge 64 32~63 65~128
ds2.8xlarge, dc2.8xlarge 128 64~127 -

作業手順

スナップショットの取得

必須作業ではありませんが、万一にそなえクラスターのスナップショットを取得します。

  1. Redshiftクラスターのコンソールから、バックアップを選択し、「スナップショットの取得」を選択します。
  2. スナップショットの保持期間等を設定し、スナップショットを取得します。

Elastic-Resize(伸縮自在なサイズ変更)の実施

  1. Redshiftクラスターのコンソールから、「クラスター」を選択し、「サイズ変更クラスター」を選択します。

  1. Type of resizeから「Elastic Resize」を選択します。
  2. ノード数で変更したいノード数を選択します。
  3. サイズ変更を選択し、リサイズを実施します。

  1. 実施後は、イベント、ステータス等を確認し、正常にリサイズが終了するまで待ちます。

Classic-Resize(従来のサイズ変更)の実施

  1. Redshiftクラスターのコンソールから、「クラスター」を選択し、「サイズ変更クラスター」を選択します。
  2. Type of resizeから「Classic Resize」を選択します。
  3. ノード数で変更したいノード数を選択します。
  4. サイズ変更を選択し、リサイズを実施します。

  1. 実施後は、イベント、ステータス等を確認し、正常にリサイズが終了するまで待ちます。

※Classic-Resizeの場合は、リサイズ時にクラスターの再起動等を伴います。

まとめ

勘の良い方はお気づきになったかもしれませんが、当初2->4->8という段階的なリサイズを計画していたのですが、現在のところ連続してリサイズを行うことはできないようで、Elastic-Resizeで実施可能なノード数のリセットを行う場合は一度Classic-Resizeを実施する必要があります。 Elastic-Resizeの使いどころですが、Classic-Resizeにくらべかなり短い時間でノード数が変更できるので、クラウドの良さを生かし、負荷に応じた増減を実施することができるかと思います。

ただ、常時使用を予定しているElastic-Resizeのノード数などを考慮して、Classic-Resizeを実施し、必要となる増減数を計画するなどを行う必要があるかと思います。

おまけ

リサイズ中に気づいたんですが、こんなところにキャンセルボタンが!!!ということで、 以前はリサイズを開始すると終了するまでキャンセルを行うことは出来なかったのですが、機能追加によりリサイズ途中でのキャンセルを実施することが可能になっていました。

参考

Amazon Redshift 新機能:『Elastic Resize』で短時間でのノード数変更(リサイズ)が可能になりました https://dev.classmethod.jp/cloud/aws/amazon-redshift-elastic-resize/

Amazon Redshift でのクラスターのサイズ変更 https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/rs-resize-tutorial.html