AWS RedshiftのElastic resizeを試してみた

Redshift Elastic resize

従来のリサイズ方法 Classic resize ではクラスター自体の再作成行いノードの増減させる方法でしたが、
Elastic resizeではクラスターにノードを追加する処理となるためノードの変更にかかる時間を大幅に短縮できるようです。

2019/03/20現在、Elastic resizeはインスタンスタイプがdc1ファミリーでは利用できず、
dc2.large, ds2.xlargeでは1/2か2倍のノード数、
dc2.8xlarge, ds2.8xlargeでは1/2～2倍のノード数が選択可能です。

元のノード数が4の場合それぞれ以下のノード数が選択できます。

また、元のノード数を基準としているようで、
4ノード → 8ノード → 16ノードのようなリサイズを行うことはできませんでした。

今回はdc2.large、ノード数2のクラスターに8GB程度のデータを投入しClassic resizeとElastic resizeでノード数変更にかかった時間を測定してみました。
ノード数2から4への拡張と、4から2への縮小でそれぞれ測定しています。

ノード数2から4への拡張(31分)

ノード数4から2への縮小(29分)

Classic resizeでは拡張、縮小共に30分程度でした。

ノード数2から4への拡張(9分)

ノード数4から2への縮小(7分)

Elastic resizeでは拡張、縮小共に10分未満でした。

変更できるノード数に制限があるものの
短時間でノードの変更が行えるため必要になった時だけ拡張する、より「クラウドらしい」使い方が
Elastic resizeで実現できるのではないでしょうか。

記事一覧