RDS for SQL ServerをRDS for MySQLと比較してみた VersionUp & Edition編

AWS運用自動化サービス「Cloud Automator」
この記事は1年以上前に書かれたものです。
内容が古い可能性がありますのでご注意ください。

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

SQL-Server-2012

前回」に引き続き、RDS for SQL Serverについて深堀していきます。
今回は以下の2点について比較していきます。

  1. メジャーVersionUpについての比較
  2. SQL ServerのEditionとLicenseの組み合わせによる制限

はじめに

改めて、今回比較する対象をまとめます。

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

メジャーVersionUpについての比較

RDSには、メジャーバージョンアップを行ってくれる機能が存在します。

RDSVerUp

RDS for MySQLの場合、↑の図の通りModifyからDB Engine Versionを変更し、後はApplyするだけで適用されます。
補足情報ですが、Multi-AZ構成を取っていたとしてもメジャーバージョンアップにはダウンタイムが発生しますので運用上注意が必要です。

質問1

さて、ここで質問です。本メジャーバージョンアップの機能はRDS for SQL Serverでも提供されているでしょうか?

早速答えです。

RDSVerup2

答えは、メジャーバージョンアップの機能はRDS for SQL Serverでも提供されている、となります。
この機能は、東京/バージニアのリージョン関係なしに、どちらでもご利用頂けます。

実際にやってみました。以下の図では、RDS for SQL ServerのVer10を、Ver11にバージョンアップしております。

RDSVerUp3

なおメジャーバージョンアップは処理に時間がかかりますので、実施する際にはコピーした環境で先に実施し、ダウンタイムがどの程度か、計測されてからの方が良いでしょう。

さて、このままではつまらないので、やはりもう1歩先に進んでみましょう。

質問2

次の質問です。メジャーバージョンアップの機能はMulti-AZ構成を取っているRDS for SQL Serverでも提供されているでしょうか?

早速ですが、答えはYesで、メジャーバージョンアップの機能はMulti-AZ構成を取っているRDS for SQL Serverでも提供されているとなります。

実はこちら、過去はNoで、提供されていませんでした。いつの間にやらAWSさんが対応してくれておりました。
昔は「一度Single-AZ構成に戻してからVersionUpをし、その後にMulti-AZ構成に戻す」という結構な手間がかかった作業でしたが、今はサクッとできるようになっています。

こちらも実際にやってみました。
なお、東京リージョンではMulti-AZが提供されていないため、バージニアで実施します。

RDS_OptionG00

RDSのメニューの「Modify」から、「DB Engine Version」を変更し、適用します。
↑の図では、RDS for SQL Serverの2012(Ver11)を、2014(Ver12)にバージョンアップしています。

RDS_OptionG000

Apply Immediatelyとすると、↑の図の通りUpgradeが始まります。
Eventには開始のゴングとして

May 6 7:05 PM
DB instance restarted

が記載されていました。これがスタートの合図です。

そしてここから、ちょっとしたことがあってとても待つことになりました。

RDS_Upgrade1

根気よく待っていると、10:49 PM・・・つまり3時間44分後にStatusが「backing-up」になってくれました。
ここまで来れば後は少しです・・・さらに待つと、

RDS_Upgrade2

やっと「Available」になってくれました!
完了は10:58 PMで、7:05 PMから3時間53分かかりました。

RDS_Upgrade3

終わった後、パラメータグループを見ると「pending-reboot」となっており気になったのでrebootをかけておきました。

RDS_Upgrade4

rebootしたので解消されています。
これで、実際にMulti-AZ構成でメジャーバージョンアップが出来ることが判りました。

ここまでのまとめ

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

比較対象 1.RDS for MySQL(Tokyo) 2.RDS for SQL Server(Virginia) 3.RDS for SQL Server(Tokyo)
メジャーバージョンアップがRDSの機能で可能か?
Multi-AZ構成でメジャーバージョンアップがRDSの機能で可能か?

※「-」については、そもそもMulti-AZ構成が取れないため対象外として「-」にしています

RDS for SQL Serverでメジャーバージョンアップに対応しているバージョン一覧

メジャーバージョンアップを行うに当たり、非常に重要な点が、このバージョンアップ対応バージョンです。

これはSQL Serverに限ったことではないですが、アップグレードに対応しているバージョンと、そうではないバージョンが存在します。
例えば、「AWS公式ドキュメント」からの抜粋となりますが、SQL Server 2014 へアップグレードできるのは以下のバージョンのRDS for SQL Serverのみです。

次の SQL Server バージョンを SQL Server 2014 SP1 CU2 (12.00.4422.0.v1) にアップグレードできます。

10.50.2789.0.v1 (SQL Server 2008 R2 SP1)
10.50.6000.34.v1 (SQL Server 2008 R2 SP3)
11.00.2100.60.v1 (SQL Server 2012 RTM)
11.00.5058.0.v1 (SQL Server 2012 SP2)

これ以外のバージョンでは、2016年5月現在は「 SQL Server 2014 SP1 CU2 (12.00.4422.0.v1) 」へアップグレードできない点にご注意ください。例えば、「11.00.6020.0.v1」は今現在「12.00.4422.0.v1」へアップグレードできません

私、検証中に何でできないのかと1時間くらいハマったんですが、これが原因でした。
気を付けましょう(戒め)。

SQL ServerのEditionとLicenseの組み合わせによる制限

次はエディションについてです。この項目では、RDS for SQL Serverだけの話とさせてください。

SQL Serverには様々なエディションが存在しますが、RDS for SQL Serverで提供されているエディションは以下の4つです。

  • Express
  • Web
  • Standard
  • Enterprise

加えて、RDS for SQL Serverでは以下の2つのライセンス形態が存在します

  • License Included(RDSの時間課金にライセンス利用料金が含まれるモデル)
  • BYOL(Bring Your Own License/ライセンス持ち込みモデル)

これらのエディションとライセンスモデルの組み合わせが、東京リージョンとバージニアリージョンでは仕様が異なっています。以下に、その差を表で示します。
また、Multi-AZ構成もEditionに関係しますので、合わせて記載します。

RDS for SQL Server License Included Bring Your Own License Multi-AZ構成
Express Edition
※利用可能なInstance Typeに制限があり、t2.medium以下のスペックのみ選択が可能
×

×
Web Edition × ×
Standard Edition(SE) Virginia:〇
Tokyo:×
Enterprise Edition(EE)
※2012(V11)のみ提供
2014(V12)は選択不可能

Virginia:〇
※利用可能なInstance Typeに制限があり、r3.2xlarge、r3.4xlarge、r3.8xlargeのみ選択が可能
Tokyo:×

Virginia:〇
Tokyo:×

ハマりそうな点を抜粋します。

  • Enterprise EditionではSQL Server 2014のバージョンでは提供されていない
  • Enterprise EditionではSQL Server 2012のバージョンで提供されているも、License Includedモデルでの提供は東京では選択不可能
  • Multi-AZ構成で構築したい場合は、SEもしくはEEを選択する必要がある

まとめ

この記事では、RDS for MySQLを起点として、RDS for SQL Serverの特にメジャーVersionUpとEditionについて記載しました。
「メジャーVersionUp」に関しては、バージニアリージョンでMulti-AZ構成にて実際に検証してみました。
「Edition」では表にまとめると共に、特に重要な点を抜粋してお伝えしております。
Editionについては、ライセンス利用料が関わってきますので利用にあたっては特にセンシティブな部分です。
様々な制限があるだけではなく、基本的にSQL Serverはコア数課金のライセンスモデルですので、License Includedモデルでコア数が多いInstance Typeを選択する場合は、利用料に十分ご注意ください。

おまけ

せっかくなので、4時間近くかかったRDS for SQL Serverの時のEventをここに掲載しておきます。

Time System Notes
May 6, 2016 at 10:58:29 PM UTC+9
Finished DB Instance backup
May 6, 2016 at 10:54:22 PM UTC+9
Backing up DB instance
May 6, 2016 at 10:54:01 PM UTC+9
Emergent Snapshot Request: Databases found to still be awaiting snapshot.
May 6, 2016 at 10:54:01 PM UTC+9
Instance will be degraded while mirroring is reestablished: Databases found to still be awaiting snapshot.
May 6, 2016 at 10:54:00 PM UTC+9
Updated to use DBParameterGroup default.sqlserver-se-12.0
May 6, 2016 at 10:51:39 PM UTC+9
Finished applying off-line patches to DB instance
May 6, 2016 at 10:49:13 PM UTC+9
DB instance restarted
May 6, 2016 at 10:49:01 PM UTC+9
Emergent Snapshot Request: Databases found to still be awaiting snapshot.
May 6, 2016 at 10:49:01 PM UTC+9
Instance will be degraded while mirroring is reestablished: Databases found to still be awaiting snapshot.
May 6, 2016 at 10:48:28 PM UTC+9
DB instance shutdown
May 6, 2016 at 10:44:01 PM UTC+9
Emergent Snapshot Request: Databases found to still be awaiting snapshot.
May 6, 2016 at 10:44:01 PM UTC+9
Instance will be degraded while mirroring is reestablished: Databases found to still be awaiting snapshot.
May 6, 2016 at 10:41:45 PM UTC+9
DB instance shutdown
May 6, 2016 at 10:39:01 PM UTC+9
Emergent Snapshot Request: Databases found to still be awaiting snapshot.
May 6, 2016 at 10:39:01 PM UTC+9
Instance will be degraded while mirroring is reestablished: Databases found to still be awaiting snapshot.
May 6, 2016 at 10:34:01 PM UTC+9
Emergent Snapshot Request: Databases found to still be awaiting snapshot.
May 6, 2016 at 10:34:01 PM UTC+9
Instance will be degraded while mirroring is reestablished: Databases found to still be awaiting snapshot.
May 6, 2016 at 10:24:30 PM UTC+9
DB instance restarted
May 6, 2016 at 10:23:46 PM UTC+9
DB instance shutdown
May 6, 2016 at 10:16:58 PM UTC+9
DB instance shutdown
May 6, 2016 at 10:00:38 PM UTC+9
DB instance restarted
May 6, 2016 at 10:00:00 PM UTC+9
DB instance shutdown
May 6, 2016 at 7:31:03 PM UTC+9
DB instance shutdown
May 6, 2016 at 7:19:26 PM UTC+9
Applying off-line patches to DB instance
May 6, 2016 at 7:19:23 PM UTC+9
Finished DB Instance backup
May 6, 2016 at 7:17:34 PM UTC+9
Backing up DB instance
May 6, 2016 at 7:13:01 PM UTC+9
Finished applying modifications to convert instance to Mirroring
May 6, 2016 at 7:05:39 PM UTC+9
DB instance restarted

後で判明したことですが、AWSサポートから以下の通り連絡がありました。

確認いたしましたところ今回は、パラメーターグループが見つからない旨のエラーが出ており、担当部署での手動対応が行われていたことが確認できました。
問題の検知までの時間や手動対応の時間などにより想定よりも長い時間を要したものと考えられます。

今回、RDS の内部のシステムによるエラーにより時間が掛かった部分はおよそ2時間40分程度となっており、ここから逆算致しますと、正常であれば1時間強で終了していたものと存じます。

なお、今回掛かった時間については、データベースが保持するデータ量やストレージサイズ、インスタンスクラス等様々な要因によって変化致しますのでアップグレードが常に1時間程度で終了するというわけではございませんので今回のDB インスタンスにおける目安の時間とお考え下さい。

場合によってはこのように時間がかかるケースも存在する模様です。
上にも記載しましたが、やはり事前の検証にて実際にかかる時間を測定されてから本番に臨まれる方が良いでしょう。

以上です。長くなりましたが、またお会いしましょう。

 

AWS運用自動化サービス「Cloud Automator」