cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。
下記にあるとおり、Amazon Redshiftのクラスターをリサイズ（ノードタイプ、台数の変更）をするときには、
- 既存のクラスターを読み取り専用にする
- 新しいクラスターを用意する
- データをコピーする
- 内部DNSが切り替わる
という操作がされています。
Amazon Redshift クラスター – Amazon Redshift #クラスターのサイズ変更
ということは、将来的なリサイズを考慮して、サブネットのIPアドレスレンジは、クラスターの最大台数の約2倍のIPアドレスが入るだけ用意しておく必要があるでしょうか？
ということで検証してみました。
VPCサブネットとRedshiftクラスターの作成
- クラスターサブネットグループに所属させるサブネットを /28（利用可能なIPアドレスは11個）で作成します。
- クラスターサブネットグループを作成します
- Redshiftのクラスターを5ノードで構成します（消費IPアドレス：6個）
Redshiftクラスターのリサイズ
この状態だと消費可能なIPアドレスは残り5個なので、ノード数の削減はできても、これ以上増やすことができない気がします。
- Redshiftのクラスターを6ノード（消費IPアドレス：7個）に変更してみます。
- あれ、なんか要求は受け付けてもらえたようで、リサイズ処理が開始しています。
- availableになったので`Node Ip Addresses`を見てみると、Public IPは全て変更されていますが、Private IPは既存のものを全て付け替えたうえで増加分を取得しているようです。
まとめ
- Redshiftのクラスターをリサイズするために空きIPアドレスを確保しておく必要はなさそうだ
- クラスターをリサイズするとPublic IPは全て変更されるようだ
- クラスターをリサイズするとPrivate IPは付け替えられるようだ
元記事は、こちらです。
