はじめに
Aurora MySQLなどのRDSを使ってデータベースの運用をしている場合、定期的にバージョンアップ作業は必要となってきます。
しかしバージョンアップ作業は数十分程度かかることがあり、その間はDBへの接続ができなくなるためサービスの停止作業が必要となってしまいます。
そういったダウンタイムを最小限に抑えるため、RDSではBlue/Green Deploymentsが提供されています。
今回はCloudFormationで管理されたAurora MySQLでBlue / Green Deploymentsを使ってバージョンアップした場合、どのような影響があるのかを検証してみます。
前提
以下のようなAurora MySQLで検証します。
- DBエンジン: Aurora MySQL
- DBエンジンバージョン: 2.07.5 ※検証時に利用できたバージョンです
- ライターインスタンス: 1台（db.t3.medium）
- リーダーインスタンス: 1台（db.t3.medium）
- IAMロール: アタッチ済み
また、こちらのRDSに関してはCloudFormationで管理されています。
Blue / Green Deploymentsを使ったバージョンアップ
ではここからBlue / Green Deploymentsを使って2.07.8へのバージョンアップを行っていきます。
まずはDBクラスターにBlue / Green Deploymentsを作成します。
以下の設定でBlue / Green Deploymentsを作成します。
- 識別子: 任意
- DBエンジンバージョン: 2.07.8 ※検証時に利用できたバージョンです
- DBクラスターパラメータグループ: アップデート前と同じDBクラスターパラメータグループ
- DBパラメータグループ: アップデート前と同じDBパラメータグループ
作成後完了するまで30分ほどかかるためしばらく待ちます。作成が完了した際は以下の画像のようにBlueクラスタとGreenクラスタが存在する形になります。
作成が完了したら実際に切り替えを行っていきます。
切り替えは作成したBlue / Green Deploymentsを選択後、アクション > 切り替えから切り替えを実施します。
切り替え自体は数分で終わり、イベントを確認しても3分で切り替えができていることが確認できました。
切替後は2つDBクラスターが存在しており、古いDBクラスター・インスタンスは識別子の後ろにoldがつけられています。
検証
ではここからCloudFormationスタックで定義されたDBエンジンバージョンと、実際にバージョンアップされたDBエンジンバージョンを合わせられるのか確認していきます。
CloudFormationのドリフトを確認すると該当のRDSクラスターに差分があり、DBエンジンバージョンとIAMロールに差分が確認できます。
※実際には3つのプロパティで差分が検知されています
次にCloudFormationで定義されているDBエンジンバージョンをバージョンアップごのバージョンに変更して変更セットを作成します。
ここでは想定通りRDSクラスターに対して変更があることを確認できます。
作成した変更セットを実行すると数分（検証時は1分）程度で実行が完了します。この場合にDBのバージョンアップが発生する場合は数十分程度の更新時間が発生する想定のため、DBのバージョンアップ作業は行われていないことが確認できます。
再度ドリフトを確認すると、DBエンジンバージョンの差分が消えていることが確認できます。
※実際には2つのプロパティで差分が検知されています
おわりに
以上、今回はCloudFormationで管理されたAurora MySQLをBlue / Green Deploymentsでバージョンアップしてみました。
結果としてはCloudFormationスタックで定義されたDBエンジンバージョンは、バージョンアップ後にスタックのバージョンを変更することでスタックと差分を作ることなく、なおかつBlue / Green Deploymentsで最小限のダウンタイムでバージョンアップできることが確認できました。
今後RDSクラスタのバージョンアップを検討されている方はぜひBlue / Green Deploymentsを使ってみてはいかがでしょうか？