エンジンメジャーバージョンアップにどのくらい時間がかかる？
こんにちは！AWS事業本部のおつまみです。
みなさん、マルチAZ配置Amazon RDS for SQL Serverのエンジンメジャーバージョンアップにどのくらい時間がかかるか知りたいな思ったことはありますか？私はあります。
先日こちらの作業を実施することになったので、事前検証としてエンジンメジャーバージョンアップにどのくらい時間がかかるか計測してみました。合わせて、その時に出力されるRDSイベントログの情報も取得しました。
エンジンメジャーバージョンアップを実際にやってみた系の記事があまりなかったので、今後実施される方の参考になれば嬉しいです！
いきなり結論
- マルチAZ配置Amazon RDS for SQL Server（db.r6i.xlarge）の場合、約1時間強時間がかかる。
- エンジンメジャーバージョンアップにかかる時間は、利用するエンジンバージョンや、インスタンスタイプ、データ量などによって異なるので、必ず事前検証を行った上で適用してほしい。
前提知識
エンジンバージョンアップは2種類ある
エンジンバージョンアップには、メジャーバージョンアップとマイナーバージョンアップの2種類があります。
各々のざっくりとした違いはこちらです。
| ー | メジャーバージョンアップ | マイナーバージョンアップ |
|---|---|---|
| 実行方法 | 手動 | 手動、自動 |
| 特徴 | 既存アプリケーションとの下位互換性のないDBの変更が含まれる場合がある | 既存のアプリケーションとの下位互換性がある変更のみ |
詳しくは下記のブログをご参考ください。
例えば、Amazon RDS for SQL Serverの場合は以下となります。
- 14.00.3381.3.v1 → 15.00.4345.5.v1
- メジャーバージョンアップ
- 15.00.4073.23.v1 → 15.00.4345.5.v1
- マイナーバージョンアップ
メジャーバージョンアップは事前検証が必須
エンジンメジャーバージョンアップはマイナーバージョンと違い、必ず事前検証が必要となります。
事前検証を行う目的は以下の通りです。
１. 変更後のアプリケーションの動作に不具合がないこと（互換性）を確認するため
新しいメジャーバージョンでは、廃止された機能や変更された機能が含まれている可能性があります。
そのため、既存のアプリケーションとの互換性が失われることがあり、アップグレード後にアプリケーションが正常に動作しなくなる恐れがあります。
公式ドキュメントにも以下のように記載されています。
DB インスタンスのメジャーバージョンのアップグレードを実行する前に、データベースとそのデータベースにアクセスするすべてのアプリケーションについて、新しいバージョンとの互換性を綿密にテストする必要があります。
２. 本番変更時にかかる時間を計測し、どのくらい作業時間がかかるのかを把握するため
アップグレードにかかる所要時間は、利用するエンジンバージョンや、インスタンスタイプ、データ量などによって異なります。
またエンジンによっては、メジャーバージョンアップ中には、ダウンタイムが必要となります。
そのため、おおよその所要時間を理解するために、まず別のテストインスタンスでアップグレードをテストすることが推奨されています。
事前検証は公式ドキュメントの手順に従い、実施しましょう。
その際、変更予定のスナップショットからの復元もしくはリードレプリカを使用するようにしましょう。
なおメジャーバージョンアップ時には、オプショングループおよびパラメータグループの変更が必要となります。個別にカスタマイズしたものを利用している場合は注意してください。
エンジンバージョンアップ時の挙動
RDSの自動バックアップが有効な場合、バージョンアップグレード処理は以下のようなステップとなります。
- アップグレード前のスナップショットを取得
- DBインスタンスをアップグレード
- アップグレード後のスナップショットを取得
シングルAZ/マルチAZ構成に関わらず同じ挙動となりますが、マルチAZ構成の場合はスタンバイのRDSからスナップショットが取得されます。
図にするとこのようなイメージです。
やってみた
条件
実際にエンジンのメジャーバージョンアップを実施します。
今回はこちらのRDSインスタンスで実行してみます。
| 項目 | 設定値 | 備考 |
|---|---|---|
| エンジンのタイプ | Amazon RDS for SQL Server | |
| エンジンバージョン（変更前） | 14.00.3381.3.v1 | |
| エンジンバージョン（変更後） | 15.00.4345.5.v1 | |
| DB インスタンスクラス | db.r6i.xlarge | |
| マルチ AZ 配置 | あり（ミラーリング） | |
| 自動バックアップ保持期間 | 有効 | |
| 備考 | 新規起動したインスタンスのため、データなし |
下記の公式ドキュメントに従って、エンジンバージョンアップを手動で実行しました。
操作自体はとてもシンプルで「変更」のページから適用したいエンジンバージョンアップを選択し、「すぐに適用」を選択するだけです。
結果、約1時間14分でバージョンアップが完了しました。
出力されたRDSイベントログ
下記のログが出力されていました。
最初の実行時間を00:00:00として、時系列に変換しています。
| 時間 | イベントID | メッセージ | 備考 |
|---|---|---|---|
| 00:00:00 | RDS-EVENT-0001 | Backing up DB instance | |
| 00:03:00 | RDS-EVENT-0002 | Finished DB Instance backup | |
| 00:03:00 | RDS-EVENT-0026 | Applying off-line patches to DB instance | DB インスタンスのオフライン メンテナンス実行中。DB インスタンスは現在利用できません。 |
| 00:11:00 | RDS-EVENT-0004 | DB instance shutdown | |
| 00:21:00 | RDS-EVENT-0004 | DB instance shutdown | |
| 00:21:00 | RDS-EVENT-0006 | DB instance restarted | |
| 00:41:00 | RDS-EVENT-0004 | DB instance shutdown | |
| 00:41:00 | RDS-EVENT-0006 | DB instance restarted | |
| 00:47:00 | RDS-EVENT-0013 | Multi-AZ instance failover started. | |
| 00:47:00 | RDS-EVENT-0049 | Multi-AZ instance failover completed | |
| 00:54:00 | RDS-EVENT-0004 | DB instance shutdown | |
| 00:55:00 | RDS-EVENT-0023 | Emergent Snapshot Request: Databases found to still be awaiting snapshot. | 手動バックアップがリクエストされましたが、現在、Amazon RDS は DB スナップショットの作成中です。Amazon RDS で DB スナップショットの作成が完了した後で、リクエストをもう一度送信してください。 |
| 01:00:00 | RDS-EVENT-0023 | Emergent Snapshot Request: Databases found to still be awaiting snapshot. | |
| 01:00:00 | RDS-EVENT-0004 | DB instance shutdown | |
| 01:00:00 | RDS-EVENT-0006 | DB instance restarted | |
| 01:05:00 | RDS-EVENT-0023 | Emergent Snapshot Request: Databases found to still be awaiting snapshot. | |
| 01:06:00 | RDS-EVENT-0027 | Finished applying off-line patches to DB instance | DB インスタンスのオフラインメンテナンスが完了しました。現在、DB インスタンスは利用できます。 |
| 01:07:00 | RDS-EVENT-0078 | Monitoring Interval changed to 60 | 拡張モニタリングの設定が変更されました。 |
| 01:07:00 | N/A | Performance Insights has been enabled | |
| 01:07:00 | RDS-EVENT-0001 | Backing up DB instance | |
| 01:11:00 | RDS-EVENT-0002 | Finished DB Instance backup | |
| 01:14:00 | RDS-EVENT-0092 | Finished updating DB parameter group |
前提条件でお伝えしたエンジンバージョンアップ時の挙動単位でまとめてみます。
| 時間 | 処理内容 |
|---|---|
| 00:00:00 ~ 00:03:00 | ①アップグレード前のスナップショットを取得の処理 |
| 00:03:00 ~ 01:07:00 | ②DBインスタンスをアップグレード |
| 01:07:00 ~ 01:11:00 | ③アップグレード後のスナップショットを取得の処理 |
なお最後にFinished updating DB parameter groupのイベントが出力されているので、スナップショット取得後にパラメータグループが適用されるみたいでした。
おまけ：エンジンアップデート時のダウンタイムについて
マルチAZ配置のAmazon RDS for SQL Serverの場合、ダウンタイムはフェイルオーバーの間だけとなっています。
DB インスタンスがマルチ AZ 配置にある場合は、プライマリとスタンバイの両方のインスタンスがアップグレードされます。Amazon RDS で、ローリングアップグレードが行われます。フェイルオーバー中にのみ、停止が発生します。
Microsoft SQL Server DB エンジンのアップグレード - Amazon Relational Database Service
しかし、その他のエンジンの場合はマルチ AZ 配置を使用している場合でも、プライマリ DB インスタンスとスタンバイ DB インスタンスの両方が同時にアップグレードされます。
つまり、アップグレードが完了するまでダウンタイムが発生することになります。
データベースエンジンレベルにアップグレードするには、ダウンタイムが必要です。RDS DB インスタンスがマルチ AZ 配置を使用している場合でも、プライマリ DB インスタンスとスタンバイ DB インスタンスの両方が同時にアップグレードされます。これにより、アップグレードが完了するまでダウンタイムが発生することになります。 （引用：必要な Amazon RDS メンテナンスの実行時におけるダウンタイムを最小限に抑える | AWS re:Post）
どうしてもダウンタイムを許容できないシステムの場合は、Blue/Green デプロイメントを利用することも検討してみましょう。
2024/3/13時点でRDS for Maria DB、RDS for MySQL、および RDS for PostgreSQLであれば、利用できます。
さいごに
今回は、マルチAZ配置Amazon RDS for SQL Serverのエンジンメジャーバージョンアップにどのくらい時間がかかるかおよびその時のRDSイベントログの情報をご紹介しました。
想定していたよりもバージョンアップに時間がかかることがわかりました。 エンジンバージョンアップを実行する際は必ず事前検証で時間を見積った上で適用するようにしましょう！
なおワークロードの状況なども加味した上で同条件でないと、事前検証からも大幅に時間が変わるため注意です。
詳細はこちらのブログをご確認ください。
最後までお読みいただきありがとうございました！
どなたかのお役に立てれば幸いです。
以上、おつまみ（＠AWS11077）でした！
参考
DB インスタンスのエンジンバージョンのアップグレード - Amazon Relational Database Service
必要な Amazon RDS メンテナンスの実行時におけるダウンタイムを最小限に抑える | AWS re:Post
Amazon RDS のイベントカテゴリとイベントメッセージ - Amazon Relational Database Service
Microsoft SQL Server DB エンジンのアップグレード - Amazon Relational Database Service
0
