急にRDS、それもfor SQL Serverについて詳しくなりたいと思った、プロジェクトマネージャーのがんも（佐竹）です。
「前回」に引き続き、RDS for SQL Serverについて深堀していきます。
今回は以下の2点について比較していきます。
- メジャーVersionUpについての比較
- 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には、メジャーバージョンアップを行ってくれる機能が存在します。
RDS for MySQLの場合、↑の図の通りModifyからDB Engine Versionを変更し、後はApplyするだけで適用されます。
補足情報ですが、Multi-AZ構成を取っていたとしてもメジャーバージョンアップにはダウンタイムが発生しますので運用上注意が必要です。
質問1
さて、ここで質問です。本メジャーバージョンアップの機能はRDS for SQL Serverでも提供されているでしょうか？
早速答えです。
答えは、メジャーバージョンアップの機能はRDS for SQL Serverでも提供されている、となります。
この機能は、東京/バージニアのリージョン関係なしに、どちらでもご利用頂けます。
実際にやってみました。以下の図では、RDS for SQL ServerのVer10を、Ver11にバージョンアップしております。
なおメジャーバージョンアップは処理に時間がかかりますので、実施する際にはコピーした環境で先に実施し、ダウンタイムがどの程度か、計測されてからの方が良いでしょう。
さて、このままではつまらないので、やはりもう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のメニューの「Modify」から、「DB Engine Version」を変更し、適用します。
↑の図では、RDS for SQL Serverの2012(Ver11)を、2014(Ver12)にバージョンアップしています。
Apply Immediatelyとすると、↑の図の通りUpgradeが始まります。
Eventには開始のゴングとして
May 6 7:05 PM
DB instance restarted
が記載されていました。これがスタートの合図です。
そしてここから、ちょっとしたことがあってとても待つことになりました。
根気よく待っていると、10:49 PM・・・つまり3時間44分後にStatusが「backing-up」になってくれました。
ここまで来れば後は少しです・・・さらに待つと、
やっと「Available」になってくれました！
完了は10:58 PMで、7:05 PMから3時間53分かかりました。
終わった後、パラメータグループを見ると「pending-reboot」となっており気になったのでrebootをかけておきました。
rebootしたので解消されています。
これで、実際にMulti-AZ構成でメジャーバージョンアップが出来ることが判りました。
ここまでのまとめ
結果を表にしてみました。
| 比較対象 | 1.RDS for MySQL(Tokyo) | 2.RDS for SQL Server(Virginia) | 3.RDS for SQL Server(Tokyo) |
|---|---|---|---|
| メジャーバージョンアップがRDSの機能で可能か？ | 〇 | 〇 | 〇 |
| Multi-AZ構成でメジャーバージョンアップがRDSの機能で可能か？ | 〇 | 〇 | - |
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
- 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：〇 | 〇 | 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をここに掲載しておきます。確認いたしましたところ今回は、パラメーターグループが見つからない旨のエラーが出ており、担当部署での手動対応が行われていたことが確認できました。
問題の検知までの時間や手動対応の時間などにより想定よりも長い時間を要したものと考えられます。 今回、RDS の内部のシステムによるエラーにより時間が掛かった部分はおよそ2時間40分程度となっており、ここから逆算致しますと、正常であれば1時間強で終了していたものと存じます。 なお、今回掛かった時間については、データベースが保持するデータ量やストレージサイズ、インスタンスクラス等様々な要因によって変化致しますのでアップグレードが常に1時間程度で終了するというわけではございませんので今回のDB インスタンスにおける目安の時間とお考え下さい。
場合によってはこのように時間がかかるケースも存在する模様です。
上にも記載しましたが、やはり事前の検証にて実際にかかる時間を測定されてから本番に臨まれる方が良いでしょう。
以上です。長くなりましたが、またお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
