はじめに
既報 の通り、Aurora MySQL 8.4のリリースに伴い、Aurora MySQL 3の標準サポート終了日が2028年4月30日に決定しました。そろそろバージョンアップの計画を立て始めている方もいらっしゃるのではないでしょうか。
バージョンアップにおいて最も頭を悩ませるのが「メンテナンスに伴うダウンタイム」ですが、その強力なソリューションとなるのが Blue/Green Deployments （以下、B/Gデプロイ）です。しかし、本番環境に投入するとなると「本当にこの手順で大丈夫か？」「切り替え時に事故らないか？」と不安になる方も多いのではないでしょうか。
本記事では、B/Gデプロイの基本的な仕組みを押さえつつ、「いざ本番環境へ投入する」となった際に慌てないためのチェックリストをフェーズ別にまとめました。事前検証や作業計画の策定にぜひお役立てください。
【おさらい】Aurora の Blue/Green Deployments とは？
一言で言うと、「本番環境（Blue）のクローン環境（Green）を数クリックで自動作成し、裏でデータを同期（レプリケーション）し続けながら、安全に接続先だけを切り替える機能」です。
主な仕組みとメリット
- 本番（Blue）に影響を与えず検証可能：Green側にだけ新しいエンジンバージョンやパラメータを適用し、本番と切り離された状態で十分なテストが行えます。
- 接続先エンドポイントが変わらない：切り替え（Switchover）時、AWS側でエンドポイントが指すDBインスタンスを裏で入れ替えるため、アプリケーション側の接続文字列を変更する必要がありません。
- ダウンタイムの最小化：データ同期（バイナリログ等）が追いついたタイミングで一瞬（通常1分未満）だけ書き込みをブロックして切り替えるため、長時間のメンテナンス停止枠を回避できます。
詳細につきましては、公式ユーザーガイドの該当ページも必要に応じてご参照ください。
本記事では、Blue=Aurora MySQL 3.x、Green=Aurora MySQL 8.4として進めていきます。
それでは、本番投入前に確認すべきポイントをチェックリスト形式で見ていきましょう。
【事前準備】作成前のチェックリスト
コンソールで「Blue/Green デプロイの作成」を押す前に、AWSコンソールや設定画面で確認する項目です。
□ binlog_format が OFF になっていないか？
確認場所： RDSコンソール ➔ 該当のDBクラスター選択 ➔ 「設定」タブ内 DB クラスターのパラメータグループ
理由： B/Gデプロイはバイナリログ（binlog）でデータを同期します。OFF になっているとB/G環境を作成できません。事前に ROW に変更してDBクラスターの再起動が必要です。
□ バイナリログの保持期間が NULL になっていないか？
確認場所： DBへ接続し CALL mysql.rds_show_configuration; を実行（binlog retention hours の値を確認）
理由： B/GデプロイはBlueからGreenへバイナリログ（binlog）を使ってデータ同期を行います。保持期間が未設定（NULL）の場合、ログがすぐに自動削除されて同期が途切れたり、B/G環境の作成・同期に失敗する原因になります。事前に十分な保持期間（例: 24時間等）を設定しておく必要があります 。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
-- 現在の設定確認 CALL mysql.rds_show_configuration; +------------------------+-------+------------------------------------------------------------------------------------------------------+ | name | value | description | +------------------------+-------+------------------------------------------------------------------------------------------------------+ | binlog retention hours | NULL | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. | +------------------------+-------+------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) Query OK, 0 rows affected (0.00 sec) -- バイナリログの保持期間を24時間に設定する CALL mysql.rds_set_configuration('binlog retention hours', 24); Query OK, 0 rows affected (0.01 sec) -- 設定変更後の確認 CALL mysql.rds_show_configuration; +------------------------+-------+------------------------------------------------------------------------------------------------------+ | name | value | description | +------------------------+-------+------------------------------------------------------------------------------------------------------+ | binlog retention hours | 24 | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. | +------------------------+-------+------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) Query OK, 0 rows affected (0.00 sec) |
□ 8.4用の「新しいカスタム DB クラスターパラメータグループ」を用意したか？
確認場所： RDSコンソール ➔ パラメータグループ ➔ パラメータグループの作成（タイプ: DB Cluster Parameter Group / ファミリー: aurora-mysql8.4）
理由： 3.x系（8.0互換 / aurora-mysql8.0）のパラメータグループは 8.4 では直接流用できません。ファミリー aurora-mysql8.4 の DB クラスターパラメータグループ をあらかじめ作成しておき、Green環境作成時にそれを指定します。例えば Aurora 3 ➔ 8.4 でデフォルト値が変更されているクラスターパラメータ（innodb_... 等）に関して、現行環境と同一の動作としたい場合は、必要なカスタム値をこの新しいパラメータグループに適用しておく必要があります。主要パラメータのデフォルト値変更につきましては以下の弊社ブログにて触れていますので必要に応じてご確認ください。
Aurora MySQL 8.4リリース！変更点と3系EOLに向けた注意点
□ 8.4で追加された新予約語・キーワード（QUALIFY, PARALLEL 等）をオブジェクト名やクエリで使っていないか？
確認場所： テーブル名・列名・ストアドプロシージャの定義文、およびアプリ側のSQL文
理由： MySQL 8.4 で新たに予約語となったキーワード（MANUAL, PARALLEL, QUALIFY, TABLESAMPLE など）をバックティック（`）で囲まずに識別子として使用していると、アップグレード後にクエリが構文エラー（Syntax Error）で失敗します。
補足： この項目はAWSの自動事前チェック（Pre-checks）では検知されないため、8.4環境（Green環境）に接続してアプリの回帰テストを行うか、MySQL 8.4 予約語一覧 を元にスキーマ定義を事前に確認しておく必要があります。
□ Blue環境で自動バックアップが有効になっているか？
確認場所： RDSコンソール ➔ 該当のDBクラスター選択 ➔ 「メンテナンスとバックアップ」タブ（または aws rds describe-db-clusters の BackupRetentionPeriod）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
aws rds describe-db-clusters \ --db-cluster-identifier 【Blue環境のクラスター識別子】\ --query "DBClusters[*].[DBClusterIdentifier, BackupRetentionPeriod]" \ --output table -- 確認例 aws rds describe-db-clusters \ --db-cluster-identifier auroralab-test \ --query "DBClusters[*].[DBClusterIdentifier, BackupRetentionPeriod]" \ --output table ------------------------------ | DescribeDBClusters | +-----------------------+----+ | auroralab-test | 7 | +-----------------------+----+ |
理由： バックアップ保持期間が 0（無効）になっていると、B/Gデプロイ環境の作成自体がエラーで失敗します。前提条件を満たすため、事前にバックアップ保持期間を 1日以上 に設定しておく必要があります。また、作業直前の状態へ戻すためのセーフティネット（Point-in-Time Restore）としても必須です。
□ 【補足確認】アプリのDB接続ライブラリと認証プラグイン
確認場所： アプリのDB接続設定 / 依存ライブラリ / DBユーザー作成SQL
実挙動： Aurora MySQL 8.4 では互換性維持のため mysql_native_password プラグインが有効化されたまま維持されています。そのため、3.x からアップグレードした既存ユーザーはもちろん、8.4 で新規作成するユーザーであっても IDENTIFIED WITH mysql_native_password を明示指定すれば引き続き利用可能です。
注意点： ただし、8.4 ではデフォルトの認証プラグインが caching_sha2_password に変更されています。認証プラグインを省略して新規ユーザーを作成した場合や、最新の認証方式へ移行する場合は、アプリ側の接続ライブラリ（mysql2 や最新の Connector/J 等）が caching_sha2_password に対応しているか事前に確認しておくと安全です。
公式ドキュメント参照：
Connectivity and security changes in Aurora MySQL 8.4 (AWS re:Post)
【検証・監視】切り替え（Switchover）前のチェックリスト
Green環境（8.4）が立ち上がり、アップグレード先の環境でのテストを行います。
その後、いざ切り替えを行う直前の確認項目です。
□ スイッチオーバーのタイムアウト（Switchover Timeout）値を定義したか？
確認場所： 事前の作業計画書 / スイッチオーバー実行直前のダイアログ画面（設定入力欄）
理由： スイッチオーバー実行時、タイムアウト時間（デフォルト: 300秒）の指定を求められます。書き込みブロックやデータ同期がこの時間内に完了しない場合、自動的に処理がキャンセル（ロールバック）されて元のBlue環境が保護されます。当日コンソール前で慌てないよう、「アプリ側の許容停止時間（RTO）に合わせて何秒に設定するか」を作業前にあらかじめ決定しておきましょう。
□ CloudWatchで AuroraBinlogReplicaLag （または ReplicaLag）が 0 秒近くになっているか？
確認場所： CloudWatch ➔ メトリクス ➔ RDS
理由： BlueからGreenへのデータ同期が遅れていると、切り替え処理が安全のために自動キャンセルされます。ほぼ 0 に張り付いていることを確認します。
□ 長時間実行されている未コミットのトランザクションがないか？
確認場所： DBへ接続し SHOW FULL PROCESSLIST; を実行
理由： 長時間走り続けている UPDATE/INSERT やバッチ処理があると、スイッチオーバー時の「書き込みブロック（In-flight write blocking）」に失敗してタイムアウトします。バッチ処理等が動いていない時間帯を狙いましょう。
-
☐ AWSの「事前チェック（Pre-checks）」でエラーが出ていないか？
-
確認場所：
- スイッチオーバー実行時のダイアログ画面内（リアルタイム判定）
- スイッチオーバー失敗時に B/G デプロイ詳細画面の上部に表示される通知バナー（エラーメッセージ）
- 理由： 切り替え実行時、AWS が自動でガードレール（レプリケーション遅延の有無や書き込みロックの可否など）をチェックします。エラーが出ている場合はスイッチオーバーが自動キャンセルされるため、表示されたエラー内容に従って対処（遅延の解消やバッチ処理の停止など）を行います。
-
確認場所：
【事前検証・当日】切り替えに伴うアプリ挙動のチェックリスト
本番切り替えの当日までに確認・判断すべきポイントです。切り替え実行時および実行直後に、アプリケーションへ影響を与えないための確認ポイントです。
□ 切断時のアプリの「再接続（リトライ）」挙動をテストしたか？
確認場所： ステージング環境等での動作確認
理由： 切り替えの数十秒間、既存のコネクションは切断されます。アプリ側で自動リトライ（再接続）が働き、エラーにならずに復帰できるかを確認しておきます。
-
☐ アプリ側の「DNSキャッシュ設定（TTL）」と「コネクション再接続処理」を確認したか？
- 確認場所： アプリサーバーの起動オプション（Java JVM 設定等） / アプリチームへのヒアリング
- 理由： スイッチオーバー時、Aurora エンドポイントの IP アドレスが切り替わります。AWS 側の DNS TTL は 5秒 と非常に短く設定されていますが、アプリ側（特に Java/JVM）で DNS を長期間キャッシュ（
ttl=-1等）していると、旧 DB へ接続し続けて障害になります。 - 公式ドキュメント参照：
【切り替え後】後処理と切り戻し（Rollback）のチェックリスト
無事に8.4 への切り替えが終わった後の後処理と、万が一のケースへの備えです。
□ 旧環境（Blue）の保持期間と削除タイミングを決めているか？
確認場所： RDSコンソール ➔ データベース一覧（-old1 という名前の旧DBが残る）
理由： スイッチオーバー後、旧環境は自動削除されません。切り替え直後の切り戻し用として一定期間保持し、切り替え後の正常稼働が確認できた段階で手動削除するルールを決めておきましょう。放置するとDB2台分の料金が二重でかかり続けます！
□ 万が一の「切り戻し（Rollback）」時、切り替え後のデータが戻らないことを理解しているか？
確認場所： 運用チーム内での認識合わせ
超重要： スイッチオーバー後、新環境（8.4）に書き込まれたデータは、旧環境（3.x）へ自動でバックポート（逆同期）されません。「何かあったら旧環境に戻す」というプランを立てる場合は、データ損失の許容範囲や手動でのデータリカバリ手順をあらかじめ定義しておく必要があります。
まとめ
Aurora MySQL 3系のサポート終了時期を見据えると、今後のメジャーバージョンアップにおいて Blue/Green Deployments は必須の知識と言えます。
仕組み自体は非常に洗練されていますが、「切り替え時のタイムアウトとコネクション挙動」、そして「切り戻し時のデータ同期の不連続性」という2つのポイントを正しく理解しておくことが成功の要です。
計画的なアップグレードに向けて、まずはテスト環境やハンズオンで一度スイッチオーバーの挙動を体験してみてはいかがでしょうか。
本記事が、皆さまの本番アップグレード計画の第一歩となれば幸いです！
