[アップデート] RDS Custom for SQL Server がマルチ AZ デプロイをサポートしました

いわさです。

今朝のアップデートで Amazon RDS の RDS Custom for SQL Server でマルチ AZ デプロイ機能がサポートされました。

RDS Custom for SQL Server は re:Invent 2021 で GA となった RDS for SQL Server の機能です。
従来は RDS for SQL Server ではアクセス出来ない機能や制限事項などが理由で RDS for SQL Server が採用出来ない場合は SQL Server on EC2 が選択肢でしたが、RDS Custom for SQL Server では SQL Server on EC2 のようにユーザーが管理すべき領域が増えますが、一部の RDS マネージドな機能を利用出来るメリットがあります。

これまで

RDS Custom for SQL Server では自動バックアップなどの機能は利用出来ていたのですが、マルチ AZ はこれまでサポートされておらず、これまでは公式ドキュメントに次のように記述されていました。

RDS Custom for SQL Server インスタンス間のレプリケーションをサポートするために、Always On Availability Groups (AGs) を使用して高可用性 (HA) を構成できます。プライマリ DB インスタンスは、データをスタンバイインスタンスに自動的に同期します。

ハイアベイラビリティー環境は、次の方法で設定できます。

• 異なるアベイラビリティーゾーン (AZ) のスタンバイインスタンスを、AZ 障害への耐性を持つように設定します。
• スタンバイデータベースをマウントモードまたは読み取り専用モードにします。

...

• Always On AG を設定して、ハイアベイラビリティーインスタンスをモニタリングします。

要は SQL Server の Always On を使って自己管理しなさいという意味だった思うので、SQL Server on EC2 と同じような設定や運用が必要になります。
それが今回のアップデートで、標準の RDS と同じような感覚でマルチ AZ 機能を有効化しフェイルオーバー出来るようになりました。

なお、対象エディションは Enterprise Edition と Standard Edition の他に、Web Edition でもサポートされています。(!!)
※ RDS for SQL Server (2019/2017) の場合は Enterprise Edition と Standard Edition のみです。

Region and version availability
Multi-AZ deployments for RDS Custom for SQL Server are supported for the following SQL Server editions:
- SQL Server 2019 Enterprise Edition
- SQL Server 2019 Standard Edition
- SQL Server 2019 Web Edition

セカンダリインスタンスはリードレプリカとして利用することは出来ず、同期レプリケーションになるため書き込みレイテンシーが増加する可能性があるという点は、RDS for SQL Server のマルチ AZ と同様です。

マルチ AZ を有効化するだけだが前提条件に注意

手順としては、RDS Custom for SQL Server の構築時に次の「可用性と耐久性」パネルの「マルチ AZ 配置」で「スタンバイインスタンスを作成する（本番環境向けに推奨）」を選択するだけです。
ただしいくつか構築前に注意事項があるので後述します。

次のように DB サブネットに従って複数サブネットへインスタンスが展開されます。

RDS Custom のエンドポイントからの名前解決先は特定 AZ のインスタンスとなっています。

% nslookup hoge0408custom.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com
Server:        127.0.2.2
Address:    127.0.2.2#53

Non-authoritative answer:
hoge0408custom.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com    canonical name = ec2-18-182-178-21.ap-northeast-1.compute.amazonaws.com.
Name:    ec2-18-182-178-21.ap-northeast-1.compute.amazonaws.com
Address: 18.182.178.21

作成前に前提条件を満たす必要がある

構築前に次の公式ドキュメントを必ず確認し、前提条件を満たすようにしましょう。
この前提条件を満たしていないと構築に失敗あるいはシングル AZ 状態に戻ると記述されています。
私が試した際にはシングル AZ とマルチ AZ 構成をいったりきたりを繰り返し構築中のままずっと完了しない状態になっていました。

サポートされているカスタムエンジンバージョン（CEV）を指定する必要があり、それについては構築時にエラーとなりますが、それ以外の前提条件はチェックされずに構築フェーズが進行されます。

特に気をつけるべき点はレプリケーション用のポートと、どうやら SQS を使用しているらしく SQS への通信経路（VPC エンドポイントあるいはパブリックアクセス経路）が必要です。
また EC2 用にインスタンスプロファイルを指定しますが、SQS のアクセス許可が必要となります。

初回はこのあたりを意識せず通常どおりの手順で RDS Custom for SQL Server を構築したところ、次のようにインスタンス変更中のままでマルチ AZ 設定が変更されるような挙動を繰り返していました。この状態でネットワーク設定を見直して設定追加を行うことでデータベース削除せずに構築が進行しました。

フェイルオーバーさせてみる

せっかくなのでフェイルオーバーさせてみました。
通常の RDS と同様で再起動でフェイルオーバーさせることが出来ます。

まず、通常どおりエンドポイントに接続して適当にデータベース・テーブル・レコードを作成します。

% sqlcmd -S hoge0408custom.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com -U admin
Password: 
1> create database hoge
2> go
1> use hoge;
2> go
Changed database context to 'hoge'.
1> create table fuga(id int identity(1,1) primary key, name nvarchar(10));
2> go

1> insert into fuga (name) values ('piyo1');
2> insert into fuga (name) values ('piyo2');
3> insert into fuga (name) values ('piyo3');
4> go

(1 rows affected)

(1 rows affected)

(1 rows affected)
1> select * from fuga;
2> go
id          name      
----------- ----------
          1 piyo1     
          2 piyo2     
          3 piyo3     

(3 rows affected)

続いて、RDS の再起動操作からフェイルオーバーさせます。
なお、マルチ AZ が有効化されている場合の再起動はフェイルオーバー必須でした。

ステータスが切り替わります。1~2 分かかりました。
ただし、マネジメントコンソール上の AZ 表示は初期構築時のプライマリインスタンスの AZ のままでした。何度かフェイルオーバーを試したり時間を置いたりしたのですが、どうやらここの表示や AWS CLI から取得出来るインスタンスの AZ は本日時点で切り替わらないようなので注意が必要です。
ap-northeast-1a で動いていると思いきや ap-northeast-1d で動いていたとかあるかもしれない。

フェイルオーバーは通常の RDS と同じで DNS で切り替わります。
次はフェイルオーバー前後の名前解決結果です。

# フェイルオーバー前
% nslookup hoge0408custom.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com
Server:		127.0.2.2
Address:	127.0.2.2#53

Non-authoritative answer:
hoge0408custom.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com	canonical name = ec2-18-182-178-21.ap-northeast-1.compute.amazonaws.com.
Name:	ec2-18-182-178-21.ap-northeast-1.compute.amazonaws.com
Address: 18.182.178.21

# フェイルオーバー後
% nslookup hoge0408custom.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com
Server:		127.0.2.2
Address:	127.0.2.2#53

Non-authoritative answer:
hoge0408custom.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com	canonical name = ec2-52-193-5-184.ap-northeast-1.compute.amazonaws.com.
Name:	ec2-52-193-5-184.ap-northeast-1.compute.amazonaws.com
Address: 52.193.5.184

フェイルオーバー後、名前解決の結果が ap-northeast-1d の EC2 インスタンスを指すようになりました。

% sqlcmd -S hoge0408custom.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com -U admin
Password: 
1> use hoge;
2> go
Changed database context to 'hoge'.
1> select * from fuga;
2> go
id          name      
----------- ----------
          1 piyo1     
          2 piyo2     
          3 piyo3     

(3 rows affected)

先程登録したデータが取得出来ますね。

さいごに

本日は RDS Custom for SQL Server がマルチ AZ デプロイをサポートしたので、簡単ではありますが実際に構成して確認してみました。

私はこの機能をちょっと待ってました。
SQL Server on EC2 ではなく RDS Custom for SQL Server を検討するシーンがあったのですが、マルチ AZ サポートの状況だけネックになっていたのです。

レプリカラグなどもまだ見てないので、もう少し評価してみたいですね。