[やってみた]RedshiftクラスターをスナップショットからRA3へ移行してみた

梶原大使

2020.03.31

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

AWS事業本部梶原＠福岡オフィスです。

既存のRedshiftをスナップショットから次世代コンピュートインスタンス『RA3』に移行する機会がありましたので、手順等を共有します。

Redshiftの次世代コンピュートインスタンス『RA3』とは

Amazon Redshift の新機能 – 次世代コンピュートインスタンスと、マネージドで分析に最適化したストレージ https://aws.amazon.com/jp/blogs/news/amazon-redshift-update-next-generation-compute-instances-and-managed-analytics-optimized-storage/

Nitroベースの次世代コンピュートインスタンスをローンチします。このローンチは、ネットワークの広帯域化、Amazon Simple Storage Service (S3)を背後に持つSSDベースのローカルストレージを利用するマネージドストレージ、そしてS3との間で行き来するデータの動きを最適化するための複合的で高度なデータ管理技術といった、アーキテクチャの改良を利用しています。

SSDのキャッシュとS3のストレージを組み合わせたNitoroベースの新しいインスタンスタイプになります。詳しくは参考情報等をご確認ください

RA3へ移行手段

RA3へ移行する際は現在のところ、以下の2つの移行方法があります

クラスターのサイズ変更からRA3を選択(ReadOnly状態 2時間~2日)
スナップショットからの移行(数分~)

※時間は移行の全体時間ではなく新規RA3クラスターが起動する時間となります

今回は移行手順は「2. スナップショットからの移行」を選択しています。手順は以下のようになります。

移行

前提条件（事前準備）

移行時のダウンタイムは許容するものとします
- インスタンスタイプ、ノードサイズにもよりますが全体作業時間は2H程度となります（移行リハーサルを行い時間計測してください）
既存クラスターのスナップショットを利用し、移行先のインスタンスを作成します
- スナップショットからの復元のノードの種類にRA3が候補に出てくることを確認してください。
事前に既存のクラスターの設定（ネットワーク、セキュリティグループ、パラメータ）は精査、確認済みとします
事前にRA3クラスターにてワークロード、パフォーマンスの確認等は実施しているものとします
- 移行リハーサルを行いスナップショットから作成したクラスターで検証することをお勧めします
今回ご案内するのはRedshiftの移行手順のみなので、非機能要件(コスト計画、移行計画、役割分担等)の検討は別途実施してください

移行作業概要

既存のRedshiftで実施されている処理を停止
- 移行作業中も接続、クエリー等はできますが、移行時のデータはスナップショット時点のデータとなることをご注意ください
自動スナップショットをマニュアルコピーする
- 移行時既存のインスタンスを削除する際に自動で取得されたスナップショットは削除されますので、必要なスナップショットは事前にコピーをしてください
ElasticIPの確保(パブリックアクセスが必要な場合)
スナップショットからRA3インスタンスを作成する
- IAMRole
- ネットワークとセキュリティ
- バックアップ設定
- デフォルト設定でなければ、既存のインスタンスの設定を確認しておいてください
検証作業
既存のインスタンスを削除する
- 移行した新しいインスタンスをそのまま使用する場合は不要です
新規インスタンスの名前を既存のインスタンスの名前に変更する
新規インスタンスに既存のインスタンスのEIPを割り当てる(パブリックアクセスが必要な場合)
移行後検証

移行するインスタンスサイズにもよると思いますが作業全体で 1.5時間程度かかりました移行する際に検証時間を長く取る場合は検証時間を考慮にいれてください。

平行期間が存在することになりますが、新規インスタンスと既存インスタンスを並行稼働させ、同じ処理等を実施し、検証することをお勧めします。

移行作業

1. 既存のRedshiftで実施されている処理を停止

必ず必要な作業ではないですが、しかかり中の処理や状態依存の処理がある場合は、スナップショットをとる前に処理を停止してください

2. 自動スナップショットをマニュアルコピーする

自動で取得されているスナップショットを「自動スナップショットをコピー」します
- 状況により最新のスナップショット他、２～３コピーを行います。
自動スナップショットの取得時間が意図した時間でなければ手動で「スナップショットを作成」します
※注意ここでスナップショットのコピーを行なわない場合、既存のインスタンスの削除のタイミングで自動で取得されたスナップショットは削除されるのでご注意ください

3. ElasticIPの確保(パブリックアクセスが必要な場合)

EC2のコンソール側でEIPを取得します
- 固定のIPアドレスが不要であれば作成時になしを指定します

4. スナップショットからRA3インスタンスを作成する

先ほど取得したスナップショットから復元したいスナップショットを選択し、「スナップショットから復元」を選択します。
クラスター設定
- ノードの種類でRA3を選択します(RA3)
- ノードで必要なノード数を選択します
- 現在のインスタンス、ノード等を元に推奨設定が表示される場合もありますので参考にしてください

クラスター詳細
- クラスター識別子を入力します
- 「既存のクラスター識別子-ra3」などがわかりやすいと思います
- データベースポート（オプション）を確認します（既存値あり）

クラスターのアクセス許可 (オプション) を選択し、項目を展開します
- 使用可能な IAM ロールを指定します
- 既存クラスターと同じ値を選択します
- 「IAM ロールを追加」を選択しないとアタッチされたIAMロールに含まれないのでご注意ください

追加設定 [デフォルトを使用]のトグルを変更し、項目を展開します

ネットワークとセキュリティ
- Virtual Private Cloud (VPC)を選択します
- 既存クラスターと同じ値を選択します
- VPC セキュリティグループ
- 既存クラスターと同じ値を選択します
- 複数ある場合は複数選択します
- クラスターサブネットグループ
- 既存クラスターと同じ値を選択します
- アベイラビリティーゾーン
- 既存クラスターと同じ値を選択します
- 拡張された VPC のルーティング
- 既存クラスターと同じ値を選択します
- パブリックアクセス可能
- 既存クラスターと同じ値を選択します
- Elastic IP アドレス
- 既存と同じものは使用できませんので事前に確保したEIP値を選択します

データベース設定
- データベース名を確認します（既存値あり）
- パラメータグループ
- 既存クラスターと同じ値を選択します

メンテナンス
- メンテナンスウィンドウ
- 既存クラスターと同じ値を選択します

モニタリング
- CloudWatch アラーム
- アラームを作成します
  - 注意：最終的には既存クラスターと入れ替えると入れ替え後にCloudWatch アラームは引き継がれますので必須ではありません

バックアップ
- 自動スナップショット
- 自動スナップショットスケジュール
  - グレーアウトされていますので特に選択しません
- スナップショット保持期間
- 既存クラスターと同じ値を選択します
- クロスリージョンスナップショットを設定
- 既存クラスターと同じ値を選択します

一通り値を確認したら [スナップショットからのクラスターを復元]を選択し、クラスターを復元します

クラスターの状態はModifyingとなり、Availableなりますので作成できるまで待ちます

5. 検証作業

クラスターのタイプ、ノード数などにもかかる時間は左右されますがクラスターの状態がAvailableになりましたら、EIPまたエンドポイントを使用して、Redshiftに接続し、データ等の確認、検証作業行います。

6. 既存のインスタンスを削除する

検証作業を終了したら、既存のインスタンスを削除します

該当する既存のクラスターを選択し、アクションから「削除」を選択します。
確認ダイアログが表示されます
クラスター名を確認してください
最終スナップショットを作成にチェックをいれます
「削除」を選択します

7. 新規クラスターの名前を変更する

正常に削除されますと、既存のクラスター名に変更することが可能になるので新規クラスターの名前を変更します。

現在新しいコンソールからクラスター識別子を変更するメニューが見つからなかったので、旧コンソールから変更を実施します
該当する既存のクラスターを選択し、「クラスター」から「変更クラスター」を選択します

8. 新規インスタンスに既存のインスタンスのEIPを割り当てる(パブリックアクセスが必要な場合)

該当するクラスターを選択し、プロパティタブを表示させます
画面下部のネットワークとセキュリティの項目の「パブリックアクセス」可能の横「編集」を選択します

注意：ネットワークとセキュリティの横の「編集」ではないのでご注意ください
直接Elastic IP アドレスを既存のElastic IP アドレスへ変更することはできませんので、一度パブリックアクセスをいいえにして、[確認]します
クラスターの状態はModifyingとなりますので再度Availableになるまでお待ちください
Availableになりましたら、再度
画面下部のネットワークとセキュリティの項目の「パブリックアクセス」可能の横「編集」を選択します
パブリックアクセスを[はい]を選択して、既存のElastic IP アドレスを選択し[確認]を選択します
クラスターの状態はModifyingとなりますので再度Availableにりましたら、Redshift自体の移行作業は終了となります

9. 移行後検証

既存のエンドポイント、EIP等が引き継がれてますので、Redshiftに接続し、確認します
移行時に停止していたロード処理の再開等、新しいインスタンスを使用します

まとめ

既存のクラスターを削除し、新規クラスターに移行することにより、クラスター識別子（エンドポイント）、EIPなどを引き継ぐことができます。また、あるスナップショットからの移行の場合、クラスターの立ち上がりがはやいため、移行時間などがコントロール可能です。正直なところ、かなりデータ量の多いクラスターの為、半日くらいは移行作業時間がかかるかと思っていたのですが思った以上に早く終了しました。データ量やインスタンスタイプにもよると思いますが、RA3への移行や検証を行う際のハードルを下げることができればと思います。こちらの方法以外にも、ReadOnlyの時間が許容できるまた、データ量が少ない場合はサイズ変更による移行も検討できるかと思いますのでご検討ください