これはなに？

伸縮自在なサイズ変更を使ってみて、
RedSfhitのノード数変更する際に3回転んだ話です。

伸縮自在なサイズ変更について

伸縮自在なサイズ変更 - クラスターにノードを追加または削除できます。DS2 ノードから RA3 ノードなど、ノードタイプを変更することもできます。伸縮自在なサイズ変更はすばやい操作で、通常は数分で完了します。このため、最初のオプションとしてお勧めします。伸縮自在なサイズ変更を実行すると、データスライスを再分配します。データスライスは、各ノードにメモリとディスク領域に割り当てられるパーティションです。伸縮自在なサイズ変更は、次のような場合に適しています。

簡単にまとめると

ノードタイプを変更
すばやい操作で、通常は数分で完了
ほとんどのクエリが保持

最高か？？

やりたいこと

ra3.xlplus 2ノードで経っているRedSfhitを処理が増える数日だけra3.xlplus 8ノードにしたい！

常に動いているRedSfhit且つ、定期的なリサイズなため「従来のサイズ変更」での変更は避けたい

実際にやってみた

むむ

困ったその①　変更先ノード数の制限

ra3.xlplusのノード数を変更する際、変更先のノード数は2倍もしくは1/2が選択肢となります。
つまり2ノードで動いているRedSfhitは4ノードのみが選択肢になります。

仕様上の問題と分かり次の手段へ。

困ったその②　元のクラスターを基準にノード数が決まる

変更先が２倍にしかできないのであれば、
一度4ノードに上げてから8ノードにするという２段階でノードを増やす手段を考えました。
2ノード　→　4ノード　→　8ノード

が、

実際やってみたがまたもや失敗。

ソース vs ターゲットクラスターサイズ - 伸縮自在なサイズ変更によってサイズ変更可能なノード数と種類の設定は、元のクラスターのノード数と、サイズ変更したクラスターのターゲットノードタイプによって決まります。
https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/managing-cluster-operations.html#rs-resize-tutorial

私は完全にドキュメントのこの言葉の意味を履き違えていました。
「変更前」＝「元のクラスター」ぐらいだと思い、2段階に分ければ問題ないと思っていました。

ここでいう「元のクラスター」は建てたタイミングで選んだノード数を基準とするため、ra3.xlplus、２ノードを４ノードにしたところで変更できる範囲は変わりませんでした。

困ったその③　元のクラスターを思ったより引きずる

ここまできたら最終手段、

スナップショットから復元して新しくRedSfhitを建ててしまおう！！！！

建てたタイミングで選んだノード数を基準とするのであれば、
スナップショットから復元する際にra3.xlplus 4ノードを選択して、建ててみた。

しかし、スナップショットからのリストアする時点ですでに4ノードまでしか選べない。（本来であれば2～16で選択可能）

不安に思いながらリストアしたが、結果は最大ノード数は 4 のままとなり、

失敗。

AWSサポートにも聞いてみたが、
やはり、スナップショットから復元しても元々のクラスターノード数をそのままスライドしまうのは仕様らしい。
「伸縮自在なサイズ変更」では、求めていることはどうしても厳しそうなので「従来のサイズ変更」を使うことを進められました。
一度「従来のサイズ変更」を使えば、「元のクラスターノード数」も更新される。

知ってたら得するかも？

もし今後、ra3.xlplus 2ノードを建てることがあれば、
ra3.xlplus 4ノードで建てて、ノード数をダウンさせてからra3.xlplus 2ノードにしよう。

そうすればra3.xlplus　4ノードが基準となるため、2ノードや8ノードへ柔軟に変更が可能となる。