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

記事タイトルとURLをコピーする

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

RDS1

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

「こ・・・こんなハズではッ・・・!?(滝汗)」

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

はじめに

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

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)に同期レプリケーションを用意することで、障害時にフェイルオーバーを自動的にしてくれる機能です。なおフェイルオーバー時、スタンバイがプライマリとして昇格します。

RDS_SQL_MultiAZ

質問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つ、以下に記載します。

  1. RDS for SQL ServerがMulti-AZに対応したのは「May 19, 2014」です
  2. RDS for SQL Serverは「プライマリ、ミラーリング監視、およびスタンバイインスタンスを」必要とするため、AZを3つ使用します
  3. セカンダリのスタンバイインスタンスにはライセンスは不要(リンク先の"SQL Server のライセンス"に記載あり)です
東京リージョンでMulti-AZが提供されていない理由は、この[2]に隠されているような気がしますね。 さて!ここでもう1歩奥に進んでみましょう。

質問2

次の質問です。RDS for SQL Serverでは「Multi-AZ」構成は「Dedicated Tenancy(Dedicated Instance)」で構築可能でしょうか? dedicated_subnet_group ↑の図は、少々わかり難いですがdedicated指定で作成した、RDSのSubnet Groupです。 まず、RDS for MySQLでは「Dedicated」でも「Multi-AZ」構成を構築できます。 dedicated_MySQL_RDS 実際にやってみました。↑図の通り、Multi-AZがdedicatedのVPC及びSubnet指定で構築されております。 さて、問題はRDS for SQL Serverです。 答えは・・・ RDS2_error 残念ながら、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構成で構築することはできるでしょうか?

RDS_retention_period

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

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

dedicated_MySQL_RDS2

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

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

RDS2_error2

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構成を自動バックアップを無効にして構築可能か? × ×

このように、3つを比較すると随分と仕様に差があることがわかります。

次回以降、引き続きこれら3つを比較して行きます!
それでは今回はこれにて失礼します。またお会いしましょう。

佐竹 陽一 (Yoichi Satake) 記事一覧はコチラ

SRE2課所属。AWS資格12冠。2010年1月からAWSを利用してきました。
AWSのコスト削減、最適化を得意としています。