Aurora MySQL を Blue/Green Deployment でマイナーバージョンアップしてみた

こんにちは！クラウド事業本部のおつまみです。

今回 Aurora MySQL のバージョンアップを Blue/Green Deployment で実施する機会があったので、実際に実施した手順を紹介します。

背景

今回のバージョンアップを実施した背景として、Aurora MySQL 3.09 の標準サポート終了日が 2026年8月31日 であることが挙げられます。

サポート終了後もAWSの延長サポートを利用することは可能ですが、追加費用が発生します。今回はサポート期限内にLTS版である 3.10.3 へのアップグレードを実施しました。

参考：Aurora MySQL のリリースカレンダー - AWS

構成

Blue/Green Deploymentとは

Blue/Green Deployment は、本番環境（ブルー）を稼働させたまま、ストレージレベルで複製した新環境（グリーン）を作成し、グリーン側でバージョンアップや動作検証を行ってから切り替え（スイッチオーバー）する手法です。

デプロイの流れは以下の5ステップです。

1. グリーン環境の作成 — ブルー環境からワンクリックでグリーン環境を作成（ストレージ共有のためデータコピー不要）
2. 検証・テスト — グリーン環境でバージョンアップを適用し、動作・互換性を検証
3. 切り替え（スイッチオーバー） — 数秒〜数十秒の短時間でグリーンへ切り替え
4. グリーンが本番に昇格 — 書き込み可能な本番環境として稼働開始
5. ブルーは旧環境へ — 元のブルーは自動的に旧環境（-old1）として保持され、必要に応じて削除

主なメリットは以下の通りです。

• ダウンタイム最小化 — 今回の実測では切り替え約40秒（binlog変更後のWriter再起動を含めると合計約2分）
• 安全な検証 — 本番影響なしにグリーン環境で十分な事前検証が可能
• 切り替え前であれば引き返せる — 切り替え（スイッチオーバー）前であればブルー環境に戻すだけ
• アプリ変更不要 — エンドポイント・クラスター名が自動的に引き継がれる

参考：Amazon Aurora ブルー/グリーンデプロイの概要 - Amazon Aurora

実施手順

STEP 1: 事前スナップショット取得

作業前にスナップショットを取得しておきます。万が一のロールバック用です。

コンソールの場合

1. RDSコンソール → データベース → 対象クラスターを選択
2. アクション → スナップショットを取得 をクリック
3. スナップショット名を入力して スナップショットを取得 をクリック
4. スナップショット メニューでステータスが 利用可能 になるまで待機

（スクリーンショット推奨：スナップショットが「利用可能」になった状態）

CLIの場合

aws rds create-db-cluster-snapshot \
  --db-cluster-identifier db-iroha-prod \
  --db-cluster-snapshot-identifier db-iroha-prod-pre-upgrade-20260826

完了確認：

aws rds describe-db-cluster-snapshots \
  --db-cluster-snapshot-identifier db-iroha-prod-pre-upgrade-20260826 \
  --query 'DBClusterSnapshots[0].Status' \
  --output text
# → available が返ればOK

STEP 2: binlog_format を MIXED に変更

ブルーグリーンデプロイメントはバイナリログ（binlog）レプリケーションを使用します。binlog_format が ROWもしくはMIXED に変更しておきます。
変更に伴い、BG作成前にインスタンスの再起動まで完了させる必要があります。

コンソールの場合

パラメータグループの変更:

1. RDSコンソール → パラメータグループ → 対象のクラスターパラメータグループを選択
2. 編集 をクリック
3. binlog_format を検索し、値を MIXED に変更
4. 変更を保存 をクリック

インスタンスの再起動（Reader → Writer の順）:

1. RDSコンソール → データベース → Readerインスタンスを選択
2. アクション → 再起動 をクリック → 確認して 再起動 をクリック
3. ステータスが 利用可能 に戻ったことを確認
4. 同じ手順で Writerインスタンスを再起動

CLIの場合

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name db-iroha-prod-mysql8 \
  --parameters ParameterName=binlog_format,ParameterValue=MIXED,ApplyMethod=pending-reboot

Reader → Writer の順で再起動します。

# Reader を先に再起動
aws rds reboot-db-instance \
  --db-instance-identifier db-iroha-prod-instance-1

# Reader が available になったことを確認してから Writer を再起動
aws rds reboot-db-instance \
  --db-instance-identifier db-iroha-prod-instance-1-ap-northeast-1a

STEP 3: ブルーグリーンデプロイメントの作成

コンソールの場合

1. RDSコンソール → データベース → 対象クラスターを選択
2. アクション → Blue/Green デプロイメントを作成 をクリック
3. 以下を設定して Blue/Green デプロイメントを作成 をクリック
   • Blue/Green デプロイメント識別子: 任意の名前（例: db-iroha-prod-bg-20260826）
   • DB エンジンバージョン: 8.0.mysql_aurora.3.10.3
   • DB クラスターパラメータグループ: db-iroha-prod-mysql8
4. ステータスが 利用可能 になるまで待機（30〜40分程度）

BG作成直後はステータスが「プロビジョニング」になります。

しばらくすると新環境（グリーン）のインスタンスが「作成中」で出現してきます。

CLIの場合

aws rds create-blue-green-deployment \
  --blue-green-deployment-name db-iroha-prod-bg-20260826 \
  --source arn:aws:rds:ap-northeast-1:123456789012:cluster:db-iroha-prod \
  --target-engine-version 8.0.mysql_aurora.3.10.3 \
  --target-db-cluster-parameter-group-name db-iroha-prod-mysql8

ステータス確認（AVAILABLE になるまで待機、30〜40分程度）：

aws rds describe-blue-green-deployments \
  --filters Name=blue-green-deployment-name,Values=db-iroha-prod-bg-20260826 \
  --query 'BlueGreenDeployments[0].Status' \
  --output text

ステータスが「利用可能」になれば準備完了です。新環境（グリーン）が3.10.3で起動していることが確認できます。

STEP 4: 新環境（グリーン）の確認

コンソールの場合

1. RDSコンソール → Blue/Green デプロイメント → 作成したデプロイメントを選択
2. グリーン環境 セクションに表示されているクラスター名・バージョンを確認
3. 新環境（グリーン）のクラスターをクリックして エンジンバージョン が 8.0.mysql_aurora.3.10.3 であることを確認

コンソールではブルー（B）とグリーン（G）のアイコンで区別できます。グリーン環境のバージョンが3.10.3になっていることを確認します。

CLIの場合

CLIでは GreenDeploymentIdentifier が null のため、SwitchoverDetails[].TargetMember のARNから新環境（グリーン）のクラスターIDを取得します。

aws rds describe-blue-green-deployments \
  --filters Name=blue-green-deployment-name,Values=db-iroha-prod-bg-20260826 \
  --query 'BlueGreenDeployments[0].{BGID:BlueGreenDeploymentIdentifier,SwitchoverDetails:SwitchoverDetails}' \
  --output json

取得した新環境（グリーン）のクラスターIDでバージョンを確認します

aws rds describe-db-clusters \
  --db-cluster-identifier <新環境（グリーン）のクラスターID> \
  --query 'DBClusters[0].{EngineVersion:EngineVersion,Status:Status}' \
  --output json
# → 8.0.mysql_aurora.3.10.3 / available であることを確認

STEP 5: 切り替え（スイッチオーバー）実行

ダウンタイムポイント: 切り替え（スイッチオーバー）中のダウンタイムは今回の実績で約5秒程度でした。

コンソールの場合

1. RDSコンソール → Blue/Green デプロイメント → 作成したデプロイメントを選択
2. スイッチオーバー をクリック
3. 確認ダイアログでデプロイメント名を入力して スイッチオーバー をクリック
4. ステータスが スイッチオーバー完了 になるまで待機

切り替え完了後、コンソールのステータスが「切り替え完了」になり、本番クラスター（ブルー）のバージョンが3.10.3に切り替わります。旧環境（-old1）が3.09.0のまま残っているのも確認できます。

CLIの場合

BlueGreenDeploymentIdentifier を変数に取得してから実行します：

BG_ID=$(aws rds describe-blue-green-deployments \
  --filters Name=blue-green-deployment-name,Values=db-iroha-prod-bg-20260826 \
  --query 'BlueGreenDeployments[0].BlueGreenDeploymentIdentifier' \
  --output text)

aws rds switchover-blue-green-deployment \
  --blue-green-deployment-identifier $BG_ID \
  --switchover-timeout 300

完了確認：

aws rds describe-blue-green-deployments \
  --blue-green-deployment-identifier $BG_ID \
  --query 'BlueGreenDeployments[0].Status' \
  --output text
# → SWITCHOVER_COMPLETED

切り替え（スイッチオーバー）後、本番クラスターのバージョンが切り替わっていることを確認します：

aws rds describe-db-clusters \
  --db-cluster-identifier db-iroha-prod \
  --query 'DBClusters[0].{EngineVersion:EngineVersion,Status:Status}' \
  --output json
# → 8.0.mysql_aurora.3.10.3 / available

STEP 6: ブルーグリーンデプロイメント削除 → 旧環境（ブルー）クラスター削除

ここでも大きなハマりポイントがありました。

切り替え（スイッチオーバー）完了後は --delete-target を指定できません。

AWSドキュメントに「デプロイメントのステータスが SWITCHOVER_COMPLETED の場合、--delete-target は指定できない」と明記されています。ブルーグリーンデプロイメントのみ削除し、旧環境（ブルー）クラスター（-old1）は別途削除する必要があります。

さらに、旧環境（ブルー）クラスターには削除保護が引き継がれています。 削除前に無効化が必要です。

注意: 旧環境（ブルー）クラスターは削除するまで課金が継続します。動作確認完了後は速やかに削除してください。

コンソールの場合

BGデプロイメントの削除:

1. RDSコンソール → Blue/Green デプロイメント → 対象を選択
2. 削除 をクリック
3. 「グリーンデータベースを削除しますか？」の選択で 「グリーンデータベースを保持」 を選択（--no-delete-target 相当）
4. デプロイメント名を入力して 削除 をクリック

旧環境（ブルー）クラスター（-old1）の削除:

1. RDSコンソール → データベース → -old1 が付いたインスタンスを選択
2. アクション → 削除 でインスタンスを2台削除
3. -old1 が付いたクラスターを選択 → 変更 → 削除保護 のチェックを外して保存
4. クラスターを選択 → アクション → 削除 → 最終スナップショット不要の場合はチェックを外して削除

旧環境（-old1）の削除が完了すると、本番クラスターのみが3.10.3で残りクリーンな状態になります。

CLIの場合

# Step1: BGデプロイメントを削除（--no-delete-target）
aws rds delete-blue-green-deployment \
  --blue-green-deployment-identifier $BG_ID \
  --no-delete-target

# Step2: 旧環境（ブルー）のインスタンスを削除
aws rds delete-db-instance \
  --db-instance-identifier db-iroha-prod-instance-1-ap-northeast-1a-old1 \
  --skip-final-snapshot

aws rds delete-db-instance \
  --db-instance-identifier db-iroha-prod-instance-1-old1 \
  --skip-final-snapshot

# Step3: 削除保護を無効化
aws rds modify-db-cluster \
  --db-cluster-identifier db-iroha-prod-old1 \
  --no-deletion-protection \
  --apply-immediately

# Step4: 旧環境（ブルー）クラスターを削除
aws rds delete-db-cluster \
  --db-cluster-identifier db-iroha-prod-old1 \
  --skip-final-snapshot

以上で作業完了です。

まとめ

Aurora MySQL のブルーグリーンデプロイメントによるバージョンアップをまとめると以下のとおりです。

1. 切り替え（スイッチオーバー）時のダウンタイムは約5秒程度だった
2. 切り替え完了後は --no-delete-target → 旧環境の削除保護無効化 → delete-db-cluster の順で削除する
3. 実質的なロールバック期限は切り替え（スイッチオーバー）実行前まで（以降はデータ損失を伴う）
4. 動作確認を除いたAWS側の作業は約45分で完了できた（BG作成の待ち時間約30分を含む）

Aurora のバージョンアップを検討されている方の参考になれば幸いです。

最後までお読みいただきありがとうございました。どなたかのお役に立てれば幸いです。

以上、おつまみ（@AWS11077）でした！

参考

• Amazon Aurora ブルー/グリーンデプロイの概要 - Amazon Aurora ユーザーガイド
• Amazon Aurora ブルー/グリーンデプロイの制限と考慮事項 - Amazon Aurora ユーザーガイド
• Aurora MySQL のバージョンアップグレードを振り返る - Nulab