Redshiftでの伸縮自在なサイズおよびノードタイプ変更

XplentyのCTOでもあるMark Smallcombeによるブログ「Elastic Node Resizing in Redshift 」について翻訳したものを紹介します。

はじめに

Amazon Redshiftはパワフルで機能豊富なデータウェアハウスソリューションであり、そのスケーラビリティの高さは高く評価されています。しかし、拡大するビジネスニーズに対応するためには、スケールアップが重要な機能である一方で、スケールダウンもまた重要です。そこで役立つのが、ノードタイプ間をまたいだElastic Node Resizingです。

Redshiftのユーザーは、毎日、あるいは毎時間同じコンピュートとストレージの容量を必要としているわけではありません。例えば、クラスタの容量は夜間や週末にスケールダウンすることがよくあります。さらに、Redshiftのコンピュートとストレージの要件は、予測不可能な動作（例えば、ディープLセンサーのネットワークからの新しいデータの到着など）に基づいて、迅速にスケールアップまたはスケールダウンする必要があるかもしれません。

幸いなことに、ユーザーがRedshiftプラットフォームの利用を迅速かつ効率的に調整するためのオプションがこれまで以上に増えました。4月には、Redshiftは伸縮自在なサイズおよびノードタイプ変更をサポートすると発表しました。では、これがRedshiftユーザーにとって何を意味し、この新機能は実際にどのように機能するのでしょうか？

Redshiftの伸縮自在なサイズ変更とは？

RedshiftのElastic Resizing機能は、2018年11月に初めて発表されました。Redshiftのウェブサイトによると、この機能を利用することで、ユーザーは 「ノードを追加してパフォーマンスを向上させ、要求の厳しいワークロードのためのストレージを増やしたり、ノードを削除してコストを節約したりすることで、Amazon Redshiftクラスタのサイズを数分で変更することができます。」とあります。

Elasticリサイジングは、ユーザーがRedshiftクラスタのサイズを変更するための新しい選択肢であることを意味しています。Redshiftのサイズ変更オプションは、それ以外にも2つあります。

従来のサイズ変更：Classic resizingでは、クラスタ内のノード数やノードの種類を変更することができます。Classic resizingでは、元のクラスタ内のテーブルが新しいクラスタに複製されます。元のクラスタは、操作が完了するまで読み取り専用モードのままです。
スナップショット、リストア、およびサイズ変更: 伸縮自在なサイズ変更と従来のサイズ変更の中間にあたる方法であり、元のクラスタはそれぞれ利用できなくなるか、読み取り専用になります。リサイズ操作中にクラスタへのアクセスを維持したい場合は、代わりに元のクラスタのスナップショットを取得し、新しいスナップショットをリサイズすることができます。ただし、この方法では元のクラスタへのアクセスは維持されますが、一貫性を保証するために、サイズ変更が完了する前に元のクラスタに対して行われた書き込み操作を複製する必要があります。

以下では、伸縮自在なサイズ変更について詳しく見ていきます。

Redshiftでの伸縮自在なサイズ変更はどのように機能するのですか？

Redshiftの伸縮自在なサイズ変更を使うことにより、Redshiftのクラスタに素早くノードを追加したり、削除したりすることができます。従来のリサイズのように新しいクラスタを作成するのではなく、伸縮自在なサイズ変更では元のクラスタのノード数を変更します。Redshiftでの伸縮自在なサイズ変更の手順は以下の通りです。

Step1: Redshiftは元のクラスタのスナップショットを取得します。これには、通常はクラスタスナップショットに含まれないステージングテーブルなどのバックアップしないテーブルが含まれます。自動スナップショットを有効にしている場合や、最近手動でスナップショットを取得した場合は、スナップショット操作がより速くなります。
Step2: Redshiftはリサイズ操作を開始します。このステップは通常数分もかかりません。元のクラスタ上の既存のワークロードは保留されます。Redshiftは現在のセッション接続を開いたままにし、クエリをキューに入れます。この段階で、クラスタでは新しい接続やクエリを受け付けず、一部の既存のセッションやクエリはタイムアウトする可能性があります。
Step3: Redshiftはセッション接続を復元し、クエリを通常通りに処理できるようにします。その間、Redshiftはバックグラウンドで新しいノードスライスにデータを再分配します。レプリケーション処理が完了するまでは、クラスタが通常よりも遅くなることがあります。

Amazonは、ほとんどの場合、伸縮自在なサイズ変更は数分で完了すると主張しており、従来のサイズ変更よりも大幅に速くなります。しかし、実際の伸縮自在なサイズ変更の速度は、以下のような多くの要因に依存します。

• 元のクラスタ上の既存のワークロード。
• 複製されるデータベーステーブルの数とサイズ。
• クラスタ内の異なるコンピュートノード間のデータの分布。

伸縮自在なサイズ変更を高速化するために、Amazonは以下のようなRedshiftのベストプラクティスを推奨しています。

• RedshiftのTable Skew Inspector SQLスクリプトを使用して、「Redshift Table Data Skew」、つまり異なるノードスライス間で不均等に分散しているデータベーステーブルを特定する。歪んだテーブルを修正することにより、リサイズ操作の並列性を向上させることができます。
• 使われていない不要なデータやテーブルを削除する。 これらの推奨事項の中には、伸縮自在なサイズ変更操作に特有のものもあれば、Redshiftの一般的なベストプラクティスであるものもあります。Redshiftのデプロイメントの最適化について詳しく知りたい方は、こちらの記事 Top 14 Performance Tuning Techniques for Amazon Redshiftをチェックしてみてください。

ノードタイプ間でのRedshiftの伸縮自在なサイズ変更

最初の伸縮自在なサイズ変更操作は2018年11月に導入されました。それは従来のサイズ変更に対する大きな進歩でしたが、伸縮自在なサイズ変更は、ユーザーがクラスタ内のノードタイプを変更できないという制約がありました。

それがすべて変わったのは2020年4月の時点で、Amazonが伸縮自在なサイズ変更による数分でのノードタイプの変更のRedshiftでのサポートを発表したことです。この新機能は、Redshiftのリリースバージョン1.0.10013以降で利用可能です。

ユーザーは、数分で完了する簡単な操作で、ノード数だけでなくノードタイプも変更できるようになりました。例えば、ユーザーは12月に導入されたRedshiftの新しいRA3ノードタイプにアップグレードすることで、Redshiftデータウェアハウスの運用を大幅に中断することなく、クラスタのコンピュートとストレージのニーズを独立してスケーリングすることができます。

Redshiftで伸縮自在なサイズおよびノードタイプ変更を行うには、以下の手順に従います。

1. Amazon Redshift > クラスタ画面でサイズ変更したいクラスタを特定し、クリックします。
2. クラスタダッシュボードで、[Actions] > [Resize]をクリックします。
3. 次の画面では、従来のサイズ変更と伸縮自在なサイズ変更から選択できます。クラスタのダウンタイムに対するRedshiftの推定値に注意して、伸縮自在なサイズ変更を選択します。
4. 新しいクラスタ構成で、ノードの数やタイプを変更します。使用パターンに基づいてRedshiftが推奨する構成を受け入れるか、カスタム構成を選択することができます。
5. 伸縮自在なサイズ変更を実行する時間を選択します。3つのオプションが用意されています。"Resize the cluster now（今すぐ）"、"Schedule resize at a later time（1回だけスケジュール）"、"Schedule recurring resize events(繰り返しスケジューリング)"の3つです。
6. Schedule resize at a later timeをスケジュールする場合は、リサイズアクションに名前を付け、実行する日時を選択します。
7. 設定を再度チェックし、選択したオプションに応じて、「Resize now」または「Schedule resize」をクリックします。

伸縮自在なサイズ変更 実践編

これまで、ノードタイプをまたいだ伸縮自在なサイズ変更という新しい話題について議論してきましたが、実際にはどのような効果があるのでしょうか？

Amazon Web ServicesのクラウドアーキテクトであるBhuvanesh R.氏は最近、Redshiftの新機能をテストしてみました。彼の実験では、16テラバイトのデータサイズを変更し、8ノードのDS2.xlargeノードのクラスタから2ノードのDS2.8xlargeノードのクラスタに移動しました。

この新しい伸縮自在なサイズ変更機能は約25分で完了しました。著者は、伸縮自在なサイズ変更機能がユーザーに与える利便性と時間の節約を称賛していますが、新機能の注目すべき問題点もいくつか挙げています。

• Redshiftのダッシュボードでは、リサイズ操作に10分から15分かかると予測されていたのに対し、実際には25分もかかったと著者は述べています。前述したように、元のクラスタはプロセスが完了するまで読み取り専用のままです。この矛盾を考えると、ユーザーは（念のために）余裕を持ったメンテナンス期間を確保しておくのが良いでしょう。
• サイズ変更が完了すると、ユーザーは元のクラスタの監視メトリクスとデータベース統計情報にアクセスできなくなります。サイズ変更後もこれらの情報へのアクセスを維持したい場合は、データをバックアップするか、外部の場所にエクスポートする必要があるでしょう。
• また、ユーザーはサイズ変更後にRedshiftのシステム情報系のテーブルやビューの多くにアクセスできなくなるようです。著者が指摘しているように、このため、リサイズ前とリサイズ後のクラスタのパフォーマンスを比較することが難しくなっています。

しかし、これらの注意点を念頭に置いた上で、Redshiftの伸縮自在なサイズ変更は、Redshiftの機能セットに新たに追加された貴重な機能です。これは、定期的に伸縮自在なサイズ変更を使用する予定がある場合に特に当てはまります。2019年11月現在、Redshiftはスケジューラ機能を使用した自動化された伸縮自在なサイズ変更をサポートしています。（夜間や特定の曜日にクラスタのワークロードを削減するなどの用途に使うことができます。）

まとめ

AmazonがRedshiftのRedshiftでの伸縮自在なサイズおよびノードタイプ変更を発表したことからわかったことを以下にまとめます。

• クラスタ内のノード数に応じた伸縮自在なサイズ変更は、すでにRedshiftの機能セットに追加された有用なものであり、従来のリサイズやスナップショットなどのRedshiftのリサイズオプションに取って代わる競争力のある選択肢です。
• 速度と利便性を優先し、操作中にクラスタが利用できなくなっても気にしない場合は、伸縮自在なサイズ変更の選択が最も適している可能性が高いです。
• 伸縮自在なサイズ変更機能は、最近発表されたRedshiftがノードタイプに対しても伸縮自在なサイズ変更をサポートするようになったことで強化されたものです。自由にノードタイプを変更できるようになったことで、Redshiftユーザーはより柔軟性、スケーラビリティ、AWSの予算の使い道に対する説明責任を得ることができるようになりました。
• 伸縮自在なサイズ変更は数分以内に完了するはずですが、実際のオペレーションスピードは、元のクラスタ上の既存のワークロードや、複製されるデータベーステーブルの数やサイズなどの要因に左右されます。
• Redshiftでの伸縮自在なサイズおよびノードタイプ変更を実行すると、元のクラスタの監視メトリクスやデータベース統計情報などの情報が削除されるようです。リサイズ後もアクセスを維持したい場合は、必ずこのデータをバックアップしてください。