この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
日本時間の2018年11月16日、下記ツイートにありますようにAmazon Redshiftにて『Elastic Resize』なる機能・仕組みが新たに導入されました。
Today's #AWSLaunches! 3/5 ⭐ AWS Cost & Usage Reports add Athena integration, Apache Parquet Output & Report Overwrite ⭐ Amazon Redshift announces Elastic resize, so you can add & remove nodes in minuteshttps://t.co/r8ekyCt1bR pic.twitter.com/6469grjiY4
— Amazon Web Services (@awscloud) 2018年11月16日
Amazon Redshift announces Elastic resize: Add and remove nodes in minutes
You can now quickly resize your Amazon Redshift cluster in minutes by adding nodes to get better performance and more storage for demanding workloads or by removing nodes to ... https://t.co/htE8jW6tYY
— What’s New on AWS (@awswhatsnew) 2018年11月15日
Amazon Redshiftクラスターのノード数をこれまでよりはるかに短い時間で増減させる事ができる、Elastic resize機能が発表されました。今までは難しかった、一時的な高負荷処理のためにノードを追加するといった事が可能になります。旧resizeもclassic resizeとして使えます。 https://t.co/iupAoQbqHQ
— Akira Shimosako (@simosako) 2018年11月16日
内容的には『リサイズに関する時間が(条件付きではありますが)大幅に短縮出来るようになりました。』という内容のようです。リサイズ処理は状況によってはかなり時間の掛かる処理のため、この時間が削減出来る...というのは非常に気になるところです。当エントリでは『Elastic Resize』が具体的にどの様なものなのか、実践を交えて確認してみたいと思います。
目次
Elastic Resizeとは
対応するRedshiftのバージョン
Elastic Resize機能については、Amazon Redshiftクラスタのバージョンが1.0.4852以上であれば利用可能となっています。AWS管理コンソールのクラスタ情報内のバージョンをご確認ください。手元で稼働させているAmazon Redshiftクラスタは以下の内容(1.0.4936)でしたので既に条件をクリアしていました。
機能概要
Amazon Redshiftにおける従来のリサイズ処理(Classic Resizeと呼んでいるようです)については、リサイズ前のクラスタからリサイズ後のクラスタに対してデータのCOPYを行う事で対応を行っていました。この手法の場合、リサイズ中のクラスタは読み取り専用となるのと合わせて、(データ量にある程度処理時間が比例する形となってしまう事で)内容によってリサイズ処理完了までに数時間から2〜3日掛かってしまうというケースも発生していました。
この状況が、Elastic Resizeでリサイズを行う事で改善します。
ドキュメントを読んでみると、仕組みとしては『ノードの追加・削除』を行う事でそもそもの作業時間を減らすような構成を取っているようです(新しいクラスタを作成しないため、通常は数分で弾力的なサイズ変更操作が迅速に完了する、との事)。作業中のクラスタは読み取り専用となるという部分は変わりませんが、所要時間は大幅に短縮する事が可能となります。
- 1.クラスタスナップショット
- 2.クラスタのメタデータ移行(状況に応じてセッション・クエリをタイムアウト)
- 3.セッション接続の復元＆クエリの再開
- 4.データをバックグラウンドでノードスライスに再配布
『Elastic Resize』に於ける制約や留意事項については以下のポイントがあります。
- 単一ノードでは利用出来ない
- テーブルのソートやディスクスペースの再利用は行わない(Classic ResizeのようにVACUUMをやってくれる訳では無いので、別途状況に応じてVACUUM処理が必要となる)
- リサイズ後のノード構成は、既存データ用の十分なストレージがあること
- 以下のノードタイプの場合はノード数を2倍または1/2のサイズに変更可能(『4』ノードを倍の『8』または1/2の『2』に変更可能)
- dc2.large
- ds2.xlarge
- 以下のノードタイプの場合はノード数を元サイズの2倍〜1/2のサイズに変更可能(元が16ノードならば8〜32の範囲で任意のノード数に変更可能)
- dc2.8xlarge
- ds2.8xlarge
Elastic Resize実践
では、実際にElastic Resizeを試してみましょう。手元にあるクラスタはdc2.largeの2ノードです。クラスタ規模的には決して大きいものではありませんが、挙動として確認してみたいと思います。
クラスタのメニューから『サイズ変更 クラスター』を選択。
『クラスターのサイズ変更』ウインドウが起動します。リサイズの方式(Type of resize)という選択肢が増え、『Elastic resize』が選べるようになっています。
ノードの種類については変更は不可、ノードの数については2倍の『4』は選べますが、1/2の『1』は選べないようです。(この辺り、前述の"制約"に倣う形となっているようですね)
ちなみにこちらは従来のリサイズ方法(Classic resize)を選択した場合の画面です。
サイズが決まったら変更実施。所要時間9分でリサイズ処理が完了しました。
ちゃんと倍の4ノードになっています。
引き続き、今度は『ノード数を減らす』リサイズを行ってみたいと思います。ここでは4ノードの2倍の『8』と1/2の『2』が選択肢として出てくることを期待したのですが、『8』という数字は出てきませんでした。もしかしたら直後に同じ操作を行った影響からなのかも知れませんね。
まとめ
という訳で、Amazon Redshiftの新機能『Elastic Resize』に関する内容のご紹介でした。
検証に用いた環境はクラスタ規模が小さいものでしたが、それでも少なくとも数十分はリサイズ処理に時間を要していた印象です。それが10分程度で(ノード数増の)リサイズ処理が行えたというのは驚きでした。もっと規模の大きいクラスタ、8xlargeクラスのクラスタ等でも前以て(掛かる時間の確認などは)しておく必要はあるかとは思いますが、それでもこのスケジュール感でリサイズが行える・完了する様になるのであれば非常に嬉しいところです。幾つかの制約はありますが、上手く落としどころを見つけてこのリサイズ処理、活用して行きたいものですね。
10
