Amazon Redshift クラスタのリサイズ７つのポイント

#Amazon Redshift

#AWS

石川覚

2017.05.31

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

Amazon Redshift は、データの増加やパフォーマンスの増強に伴い、いつでも柔軟かつ安全にクラスタをリサイズできます。リサイズ自体はマネジメントコンソールから変更するだけで、全自動でリサイズできます。今回は Amazon Redshift クラスタのリサイズに関する疑問やよくある質問をまとめました。

１．リサイズ中・リサイズ後

リサイズが終わるまで参照であれば利用可能

リサイズを開始するとバックグラウンドで新しいクラスタをプロビジョニングして、バックグラウンドでデータが新しいクラスタにコピーされます。既存のクラスターは読み取り専用モードになり、リサイズ中もオンラインを維持するので、更新・削除はできませんが参照は可能です。詳細については、Amazon Redshift Database Developer Guide の「Write and read-write operations」を参照してください。

リサイズ中は既存クラスタのAWS費用費のみ

「バックグラウンドで新しいクラスタをプロビジョニング」と聞くと、リサイズ中は新旧クラスタが立ち上がるので両方の利用費が発生するのではないかと心配になりますが、リサイズ中は既存クラスタのAWS利用費のみです。クラスターステータスがサイズ変更（resizing）から使用可能（available）になったら新クラスタのAWS利用費に切り替わります。

リサイズでディスク使用量が減る

新旧ノード間でのデータコピーはパラレルに処理され、分散キー指定したデータは分散キーに従い再配置します。削除済みデータは新しいノードに転送されないので想定よりデータ容量が少なくなることがありますが心配ありません。むしろ、リサイズのタイミングにデータブロックが縮小するのは望ましい動作といえるでしょう。

ノードの追加であれば RI（リザーブドインスタンス）も利用可能

コンピュートノードの数が変更しても、ノードタイプに変更がなければ、購入済みRIは適用されます。

例えば、RIを2ノード分購入済みの状態で、ノード数を4にリサイズすると、 2ノードはRIが適用され、2ノードはオンデマンドインタンスとなります。リサイズでノードタイプを変更するとRIの適用にならないことをご注意ください。

EIPとローカルIPアドレスは変更されない

EIPはもちろんですが、リーダーノードのローカルIPアドレスは変更はされません。新しいクラスタのプロビジョニングが終わると自動的に元のクラスタのIPアドレスにスワップされます。Redshiftに対して、Endpointではなく、やむを得ずEIPもしくはローカルIPアドレス指定で接続している場合でも、接続先のIPアドレス指定の変更は不要です。

※ 本来、Redshiftの接続は、Endpoint を使うのがベストプラクティスです。

Amazon RedshiftとEIPの関連性について

２．リサイズ前にすること

手動スナップショットの取得

万が一の場合にリサイズ開始直前の状態に復旧できるように、リサイズ作業前には「手動スナップショット」を取得してください。Redshiftのデフォルトでは自動スナップショットが約８時間毎もしくは5GB以上のデータ更新毎に自動取得されますが、クラスタを削除すると自動スナップショットも一緒に消えてしまうので、手動スナップショットの取得をおすすめします。

クラスタ設定情報の保存

万が一の場合にスナップショットから復旧するときに VPC やセキュリティグループ、クラスタパラメータグループなどの設定が必要ですので、設定を忘れない様にメモや画面キャプチャーを取るなどして控えておきましょう。

20170531-redshift-resize-amc-info

リサイズ前情報の取得

リサイズによるコンピュートノードの増加に伴い、想定したパフォーマンスやディスク容量が確保できたか等、効果測定するために、以下の情報を取得しておきましょう。

クラスタの設定情報の記録
現在のディスク使用量
処理時間の計測

プライベートIPアドレスの空きがあるか確認する

現時点でのRedshiftのアーキテクチャでは、停止時間を最小化するためにクラスターをバックグランドでもう一つ作成し、データを転送するような形となります。そのため、リサイズの際にはもう一つ新しいクラスターの作成を行うために新規クラスター分の新規のENI（IPアドレスの空き）が必要となります。以上のことから、リサイズを行う際にはIPアドレスの確保ができているかご確認ください。

３．リサイズの方法

マネジメントコンソールからリサイズ

リサイズは、マネジメントコンソールや AWSCLI（AWS SDK）から実施可能ですが、頻繁にすることではないので、最も一般的なマネジメントコンソールからリサイズする方法をご紹介します。

[クラスター] から [サイズ変更] を選択します。

「クラスターのサイズ変更」というダイアログが標示されたら、リサイズ後に設定変更して、[サイズ変更]ボタンを押すだけです。

[番外編] リストアしてBlue/Green-Deployment

新旧を頻繁切り替えて性能評価したり、万が一の場合にすぐに切りも戻しが必要な場合は、既存クラスタとは別に、スナップショットからクラスタを構築して、リサイズしたクラスタを用意して、新旧切り替えるという方法があります。異なるクラスタになりますので、リーダーノードのIPアドレスや endpoint が異なりますので、切り替えるには接続先を変更する必要があります。

事前に endpoint をRoute53のエイリアスとして登録しておき、アプリケーションにはエイリアスを設定することで、切り替えをRoute53のエイリアスのみで済むようにしておくと切り替えの影響範囲を小さくすることができます。

マーティン・ファウラー先生の信者の方は、こちらもぜひ検討してみてください。

４．リサイズの進行状況を確認する方法

マネジメントコンソールから進行状況を確認する

20170531-redshift-resize-amc-status

AWS CLIから進行状況を確認する

より詳細な進行状況を確認するには、AWS CLI から進行状況を確認します。方法につきましては以下のブログを御覧ください。

Redshiftリサイズの進行状況をAWS CLIから確認する

５．リサイズに要する時間

これに要する時間は、小さい方のクラスターにあるデータの量とノードの数によって異なります。数時間で終わることもあれば、2～3 日かかる可能性もあります。

引用：サイズ変更オペレーションの概要

「数時間で終わることもあれば、2～3日」では、リサイズ時間の目処かつかず不安に思うこともあるでしょう。そのような場合は、ある程度のリサイズ時間を事前に把握する方法として、検証用にスナップショットをリストアして、リサイズを時間を事前に計測するすると良いでしょう。なお、私の経験ではノードの追加であれば2～3日かかったことはなく、数時間以内に終わったことがほとんどでした。（弊社メンバーズのお客様であればご相談に乗ることが可能です。）

６．ノード数追加で改善すること

スループットの改善

ノード数を増やすことで、スループット（単位時間あたりの処理性能）の向上が期待できます。スループットの改善が見られない場合は、クエリの処理が特定のスライスに集中している可能性があります。この場合、クエリの処理がスライスに均等になるように分散タイプや分散キーを見直すことで改善できます。

ディスク容量の増加

ノード数を増やし、一台あたりノードに保存するデータ量が減ることによって、クラスタ全体ではさらにデータを保存できるようになります。ノードを追加した後、全体のディスクの空き領域があるのにディスク不足に陥る場合は、データが特定のスライスに偏っていることが考えられます。この場合、データがスライスに均等に保存されるように分散キーを見直すことで改善できます。

リサイズすると同時処理数が増えるか？

ノード数を増やし、一台あたりノードが処理するデータ量が減ることによって、処理時間を短縮することが期待できますが、同時に処理できる数は変わりません。しかし、スループット（単位時間あたりの処理性能）が向上することで、キューに積まれたリクエストがこれまで以上に速く処理され、結果的に実行数が多くなることは期待できます。なお、同時実行数は、WLMの設定値を変更することでチューニングできます。