しばたです。
今月頭のはなしですが、これまでプレビュー提供だったAmazon Redshift RA3インスタンスのMulti-AZ構成が一般提供(GA)されることになりました。
AWSからのアナウンスはこちらになります。
Multi-AZ構成について
Amazon Redshift RA3インスタンスのMulti-AZ構成は去年のre:Inventで発表されプレビュー提供されてきました。
基本的な内容については当時の記事をご覧いただくと良いでしょう。
また、AWS Big Data Blogの記事が今回のGAに併せてリライトされているのでこちらもご覧ください。
前提条件および制約
前提条件としてMulti-AZ構成を採れるのは新しい世代であるRA3インスタンスである必要があります。
旧世代のインスタンスタイプは非対応です。
また、サブネットグループは必ず3サブネット(3AZ)以上必要になります。
制約
その他の制約についてはAWSのドキュメントをご覧ください。
こちらの内容からリストアップすると、
- 暗号化されていないデータベースは作成できません (暗号化必須)
- 1AZ当たり最低2台以上のノードが必要です
- 2AZ構成なので合計すると最低4ノード必要
- Zero-ETL integrationは非サポートです
- 他AZへの再配置はできません
- Mulit-AZ構成の場合再配置はAWSで自動的に行われるとのことです
- クラスターの一時停止はできません
- 指定ポートは 5431～5455、8191～8215 の間である必要があります
STL、SVCS、SVL、SVV、STVなビューは使えません- Multi-AZ構成の場合
SYS_なビューのみサポートとのことです
- Multi-AZ構成の場合
- 現時点で利用可能なリージョンは以下となります
- オハイオ、バージニア北部、オレゴン
- ケープタウン
- 香港
- ハイデラバード、ムンバイ
- ジャカルタ、メルボルン、シンガポール、シドニー
- 大阪、ソウル、東京
- カナダ
- フランクフルト、チューリッヒ
- アイルランド、パリ
- ミラン、スペイン
- ストックホルム
- テルアビブ
- バーレーン、アラブ首長国連邦
となります。
利用可能リージョンについては「一部リージョンで不可」という感じですので将来的には対応する予感がします。
また、パフォーマンスを得るためにMulti-AZ構成ではデータベースのトランザクション分離レベルをSNAPSHOT ISOLATIONにすることを推奨とのことでした。
SLA
Multi-AZ構成のSLAについては以下のページを参照してください。
従来のSingle-AZで複数ノードの場合が99.9%に対してMulti-AZ構成では99.99%となっています。
ユースケース
Muti-AZ構成は可用性が上がり高いSLAとなりますが、現状一時停止不可などの制約が付く点や最小ノード数が多くなる点から無条件に導入するものでないと思います。
Single-AZ構成でもCross-AZ cluster recoveryがあり、ダウンタイムは発生するものの高速に復旧できます。
Multi-AZ構成はミッションクリティカルな環境で極限までダウンタイムを発生させたくないケースで導入するものかなという印象です。
試してみた
ここからは簡単に動作確認してみます。
今回は私の検証用AWSアカウントの東京リージョンで新規に環境を作っていきます。
VPCやセキュリティグループ、クラスターサブネットグループなどのリソースは準備済みの状態からスタートします。
マネジメントコンソールから新規にクラスターを作成しウィザードを開始します。
新たに「AZ configration」欄が増えているので「Multi-AZ」を選び「AZ当たりのノード数」を指定します。
今回は最低スペックのra3.xlplusでAZ当たりのノード数は2にしています。
(「設定の概要」欄で2AZ分、合計4ノード必要な旨がわかる)
その他設定は環境に応じた値にします。
(サブネットグループは3AZあるものを選ぶ)
(暗号化必須。自分でKMSキーを用意するか否かだけ選ぶ形に)
(再配置はグレーアウトされ設定不可)
クラスターを作成した結果はこんな感じです。
2つのAZが記載されていることがわかります。
今回はap-northeast-1cがPrimary、ap-northeast-1dがSecondaryでした。
ノード配置はこんな感じです。
VPCエンドポイント設定も2AZに別れており、プレビュー時点からアーキテクチャ上の変化はない模様です。
アクションメニュー
メニュー表示は以下の通りで、「一時停止」や「再配置」がグレーアウトされ利用不可になっています。
クラスターサブネットグループに問題がある場合
なお、クラスター作成時に2AZしかないサブネットグループを指定すると以下のエラーとなります。
Your cluster requires at least 3 Availability Zones in the cluster subnet group to use Multi-AZ. Add more subnet in different Availability Zones into the cluster subnet group.
フェイルオーバー
フェイルオーバーするにはメニューから「Failover primary compute」を選びます。
くどめの確認メッセージが出るので「確認」すればフェイルオーバーを開始します。
フェイルオーバー処理の流れ自体はプレビュー時点のものと同様でした。
処理が完了するまでの時間も5分くらいと変わりない感じでしたが、5分間ずっとダウンタイムだったかは未確認です。(忘れてました...)
ただ、フェイルオーバーの途中経過を見ると、
- Secondary AZのノードがPrimaryに差し変わる (IP不変)
- (旧)Primary AZのノードが見えなくなる
- 単なる削除なのか非表示にされただけなのかは不明
- しばらくして(旧)Primary AZ側ノードが表示されSecondary扱いになる (IPは異なる)
- 上記のあいだVPCエンドポイントIPに変化は無し
という挙動をしていたのでダウンタイムはそこまで長く無いと予想します。
(Secondary AZのノードがPrimaryになっている＋LeaderのIPが変化、旧Primaryのノードが非表示に)
(旧Primary AZでSecondaryとしてノードが復活)
Single-AZ構成への変更
メニューに「Deactivete Multi-AZ」という欄があり、これを選ぶとSingle-AZ構成に変更することができます。
確認画面に遷移し概算費用などが表示されます。
「Deactivate Multi-AZ」のボタンを押すと処理を開始します。
今回はだいたい3分程度で処理が完了しました。
結果としてはSecondary AZのノードとVPCエンドポイントが削除される形になります。
ちなみに、Single-AZからMulti-AZへの変更も可能です。
この場合は「Activate Multi-AZ」となります。
(動作確認はせず)
最後に
以上となります。
Multi-AZ対応を待ち望んでいた方も多いかと思います。
現状いくつか制約がありますが要件に応じて適切なかたちで採用すると良いでしょう。
4
