RDS for SQL ServerをRDS for MySQLと比較してみた Multi-AZ編

急にRDS、それもfor SQL Serverについて詳しくなりたいと思った、プロジェクトマネージャーのがんも（佐竹）です。

というのも、RDS for SQL Serverは仕様が特殊な事が多く、RDS for MySQLのように考えて勝負に挑むと

「こ・・・こんなハズではッ・・・！？(滝汗)」

みたいなことが起き得る（つまり、ハマる）ので、それを回避するためにこのような記事を書いてみました！
というわけで、早速以下の流れの通りに本編です。

はじめに
Multi-AZについての比較
- 質問1
- 質問2
- 質問3
ここまでのまとめ

はじめに

はじめに、今回比較する対象をまとめます。

No	比較対象エンジン	比較対象Region
1	Amazon RDS for MySQL	Tokyo/ap-northeast-1
2	Amazon RDS for SQL Server	N. Virginia/ us-east-1
3	Amazon RDS for SQL Server	Tokyo/ap-northeast-1

今回、最もよく使われて来ており、利用者のベースとなる(と想定した)東京リージョンのRDS for MySQLを比較の起点にしつつ、それとRDS for SQL Serverがどう異なるのか？を明らかにしながら、さらにRDS for SQL ServerのUS Regionとも比較を行います。

Multi-AZについての比較

早速今回のテーマであるMulti-AZについてお話します。

Multi-AZをご存知ない方に簡単に説明しますと、これはAmazon RDSの機能の1つで、別のデータセンター(Availability Zone)に同期レプリケーションを用意することで、障害時にフェイルオーバーを自動的にしてくれる機能です。なおフェイルオーバー時、スタンバイがプライマリとして昇格します。

質問1

ここで質問です。RDS for SQL Serverでは「Multi-AZ」構成は構築可能でしょうか？

なお、RDS for MySQLではMulti-AZが提供されており、構築可能です。

早速答えですが、答えは

RDS for SQL ServerはMulti-AZに対応している
対応しているRegionは限られている
東京リージョンはMulti-AZに対応していない

となります。

これらが明記されているAWS公式ドキュメントは「コチラ」です。
以下、そのうちのNoteより抜粋します。

ミラーリングによる SQL Server マルチ AZ は現在、米国東部（バージニア北部）、米国西部（オレゴン）、欧州（アイルランド）、およびアジアパシフィック (ソウル) の AWS リージョンで使用できます。将来的には、他のリージョンでもサポートする予定です。

ということで、RDS for SQL ServerでもMulti-AZ構成は可能ですが、2016年5月現在はいまだ東京リージョンで未対応な点ご注意ください。また、知っておいた方が良いかもしれないお話を3つ、以下に記載します。

RDS for SQL ServerがMulti-AZに対応したのは「May 19, 2014」です
RDS for SQL Serverは「プライマリ、ミラーリング監視、およびスタンバイインスタンスを」必要とするため、AZを3つ使用します
セカンダリのスタンバイインスタンスにはライセンスは不要(リンク先の"SQL Server のライセンス"に記載あり)です

東京リージョンでMulti-AZが提供されていない理由は、この[2]に隠されているような気がしますね。さて！ここでもう1歩奥に進んでみましょう。

質問2

次の質問です。RDS for SQL Serverでは「Multi-AZ」構成は「Dedicated Tenancy(Dedicated Instance)」で構築可能でしょうか？

↑の図は、少々わかり難いですがdedicated指定で作成した、RDSのSubnet Groupです。まず、RDS for MySQLでは「Dedicated」でも「Multi-AZ」構成を構築できます。

実際にやってみました。↑図の通り、Multi-AZがdedicatedのVPC及びSubnet指定で構築されております。さて、問題はRDS for SQL Serverです。答えは・・・

残念ながら、RDS for SQL ServerではDedicated Instanceを利用しての構築はできません。
もちろん、東京リージョンはそもそもRDS for SQL ServerのMulti-AZに対応していないので、Dedicated instanceでの構築も不可能です。ちなみに、AWS公式ドキュメント「コチラ」では以下の通りNoteに記載があります。

専用テナンシーのインスタンスでは、ミラーリングを使用するマルチ AZ はサポートされません。

さて！もう！さらにあと一歩！奥へ！

質問3

Multi-AZに関する最後の質問です。Multi-AZ構成で構築するときに、Backup Retantion Periodに「0」を指定し、自動バックアップ機能を無効にした状態でMulti-AZ構成で構築することはできるでしょうか？

自動バックアップは、↑の図のBackup Retention Period(バックアップ保持期間)を「0」に設定することでOFFにできます。

さて、早速RDS for MySQLですが、こちらまたも実際に構築してみました。

↑の図の通り、構築できます。
つまり、RDS for MySQLではMulti-AZを行うにあたり、自動バックアップの仕組みを利用していないのではないか、と思われます。

さて、本命RDS for SQL Serverの方です。答えは！

RDS for SQL Serverでは、Backup Retantion Periodに「0」を指定し、自動バックアップ機能を無効にした状態でMulti-AZ構成を構築はできません。

↑の図の通り、怒られます。
どうやら、RDS for SQL ServerではMulti-AZを行うにあたり、自動バックアップの仕組みを利用しているのではないか、と思われます。

ここまでのまとめ

結果を表にしてみました。

比較対象	1.RDS for MySQL(Tokyo)	2.RDS for SQL Server(Virginia)	3.RDS for SQL Server(Tokyo)
Multi-AZ構成を取れるか？	〇	〇	×
Multi-AZ構成をDedicatedで構築可能か？	〇	×	×
Multi-AZ構成を自動バックアップを無効にして構築可能か？	〇	×	×