Aurora MySQLのメジャーアップグレードでBlue/Green Deploymentsが利用できないパターン

はじめに

Aurora MySQLを5.7.mysql_aurora.2.07.4から、8.0.mysql_aurora.3.06.0へ上げる機会がありました。
ダウンタイムを抑えるためにBlue/Green Deploymentsを選択しようとしたところ、今回アップグレード対象では Blue/Green Deploymentsが利用できないパターンであることが分かりました。
その時にどうしてBlue/Green Deploymentsが利用できなかったかの理由や、Blue/Green Deploymentsの制約事項について触れていきます。

RDS Blue/Green Deployments 機能について

RDS Blue/Green Deployments機能について簡単にご紹介します。
Aurora 用 Amazon RDS Blue/Green Deploymentsの概要
ダウンタイムが少ないが、環境構築に手間がかかるレプリケーションによるアップグレードをフルマネージドで簡単に実現できるようにした機能です。

RDSにおけるBlue/Green Deploymentsのメリットと注意点

Aurora MySQL Blue/Green Deploymentsを実施するにあたってのメリットと注意点を以下に上げます。
※インプレイスアップデートと比較してのメリットになります。

メリット
- 本稼働環境に対応したステージング環境を簡単に作成できる
- データベースの変更を本稼働環境からステージング環境に自動的にレプリケートする
- 本稼働環境に影響を与えずに、安全なステージング環境でデータベースの変更をテスト可能になる
- データベースパッチとシステムアップデートを最新の状態に保ちます
- 新しいデータベース機能を実装してテストします
- アプリケーションを変更することなく、ステージング環境を新しい本稼働環境に切り替え可能になる
- 組み込みの切り替えガードレールを使用して安全に切り替え可能になる
- 切り替え当日の切り替え時間は通信の向きを変えるだけで済み、ダウンタイムが1分程度で切替完了するのでメンテナンス時間が短いため、当日の作業時間が見積もりやすい
注意点
- RDSのBlue/Green Deploymentsをする場合は、バイナリログが有効になっている必要がある。バイナリログを有効にする場合は再起動が必要になる
- Blue/Green Deploymentsにするとクローンされた分のインスタンス費用がかかる。増分コストについてはRDSコンソールで作成する際に表示されます（2024/05/17時点。）
- Green環境でテストを完了してから切替日までに期間が空く場合、Blue/Green Deployments利用中はクラスターの停止ができないため、いったんBlue/Green Deploymentsを削除しておいて、切替日が近くなったら再作成したほうが、コストが削減できる

制約事項一覧について

公式の制約事項の一覧をご覧ください。

Auroraの設定や構成によってはBlue/Green Deploymentsが利用できないので、事前に制約事項の調査が必要です。

Blue/Green Deploymentsの制限事項
色々な制約事項がありますが、今回アップグレードしようとした環境がAmazon RDS Proxyを利用していたため、 Blue/Green Deploymentsが使えませんでした。

今回は該当しませんでしたが、良く使われている機能についての制限もありますので、何点かピックアップしておきます。

CloudFormationからはBlue/Green Deploymentsが作成できないのでCloudFormationで管理できなくなる
切替後のクラスターはバックトラックが無効になる（MySQL）
- バックトラックは後から有効にできないので、バックトラックを使ってリカバリする設計の場合はつかえない
スケジュール停止運用しているクラスターには使えない
- 開発環境などのコスト削減で停止運用しているクラスターでもBlue/Green Deploymentsが有効な間は停止できない

AWSサポートに確認してみた

念のためAmazon RDS Proxyを利用している制約事項が除外される予定がないかAWSサポートへ確認してみました。
結果として今のところ、AWSとしてのリリースはないことが確認が取れました。（2024/05/17時点。）
その後も制約事項についての新しい発表等はないか確認しておりましたが発表はない状態です。（2024/09/06時点。）

調査結果からの選択したアップグレード方法と結果

結論から記載すると、インプレースアップグレードを選択しました。

移行方式の評価観点は以下の通りです。

サービスのダウンタイム
設定変更作業コスト
ランニング費用のコスト
切替作業の複雑さ

Blue/Green Deployments機能を使わずに、ダウンタイムを小さくする方法としてレプリケーションクラスターを自分で作成して切り替える方法が選択肢としてありますが、作業コストや、接続エンドポイントが変更になるデメリットがあります。
そのため、今回はアップグレード方法から除外し、インプレイスアップグレードを選択しました。
問題なく8.0.mysql_aurora.3.06.0へアップグレードできました。
事前にメンテナンスタイムを設けており、作業時間内と作業前後のアクセスがない状態を確保しました。
ダウンタイムは約30分程度になりました。