[アップデート]Aurora Global DatabaseにBlue/Greenデプロイがサポートされました

こんにちは！クラウド事業本部の吉田です。

2025/11/14に、Aurora Global DatabaseにBlue/Greenデプロイがサポートされました。

Amazon RDS Blue/Green deployments now supports Aurora Global Database - AWS
Introducing fully managed Blue/Green deployments for Amazon Aurora Global Database | AWS Database Blog

今までGlobal Database上でBlue/Greenデプロイを実現するには、下記の記事のような工夫をする必要がありました。
Aurora Global DatabaseだってBlue/Greenデプロイしたい #AWS - Qiita

今回のアップデートによって、AWSのマネージド機能でBlue/Greenデプロイが出来るようになりました。朗報ですね。

早速、Aurora Global DatabaseのBlue/Greenデプロイを試してみようと思います。

事前作業

Blue環境からGreen環境へのレプリケーションのため、バイナリログが有効化されている必要がございます。

MySQLの場合は、クラスターパラメーターグループのパラメーターである「binlog_format」をデフォルトの「OFF」から変更する必要があります。
「MIXED」なども選択できますが、AWSの推奨値としては「ROW」となります。

デフォルトのクラスターパラメーターグループを利用している場合は、カスタムのクラスターパラメーターグループを作成する所から始まります。
また、「binlog_format」のタイプはStaticとなるため、パラメーターの反映のためにインスタンスの再起動が必要となります。

PostgreSQLを利用している場合は、下記の公式ドキュメントを確認していただくようお願いいたします。

Amazon Aurora でのブルー/グリーンデプロイの作成 - Amazon Aurora

Blue/Greenデプロイ検証

概要

下記の構成のGlobal Databaseを作成しました。

• プライマリーリージョンは東京、セカンダリーリージョンはバージニア北部
• プライマリークラスターはライターインスタンス1つ、セカンダリークラスターはヘッドレスクラスター
• エンジンバージョンは8.0.mysql_aurora.3.04.0

今回は、「8.0.mysql_aurora.3.04.0」を「8.0.mysql_aurora.3.10.0」にマイナーバージョンアップグレードしてみます。

手順

グローバルデータベースを選択した後、「アクション」→「ブルー/グリーンデプロイの作成」をクリックします。

適当なデプロイ名を設定した後は、Green環境の設定をします。

エンジンバージョンはアップグレード先のエンジンバージョン(8.0.mysql_aurora.3.10.0)、クラスターパラメーターグループはBlue環境で利用していたカスタムのクラスターパラメーターグループを指定します。

設定が完了すると、設定の確認画面に移ります。
わかりやすいBlue/Green環境の概要図が表示されます。

概要図の下には、Blue/Green環境の設定の比較表があります。
問題がなければ、「作成」をクリックします。

Blue/Green環境が作成し始めると、作成状況を知らせるメッセージ画面が上の方に出てきます。
「詳細を表示」をクリックすると、各イベントの進捗状況が見れます。

Blue/Greenデプロイメントのステータスが「利用可能」となりましたら、Blue/Greenデプロイの準備は完了となります。
BlueアイコンのGlobal Databaseと、GreenアイコンのGlobal Databaseが作成されていることがわかります。

Blue/Greenデプロイメントを選択すると、Blue環境とGreen環境の差分がメッセージとして出してくれています。便利ですね。

Blue環境とGreen環境に切り替える準備ができましたら、Blue/Greenデプロイメントを選択し「アクション」→「切り替え」をクリックします。

改めて、Blue/Green環境の概要図と設定値が確認できます。
スイッチオーバー(切り替え)のタイムアウトも設定できます。
問題がなければ、「切り替え」をクリックします。

切り替え中も、先ほどBlue/Green環境の作成時と同じく、各イベントの進捗状況を確認できます。

Blue/Greenデプロイメントのステータスが「切り替え完了」に更新されました。
青いBlueアイコンがついたGlobal Databaseと、暗いBlueアイコンのGlobal Databaseがあります。
青いBlueアイコンの方のGlobal Databaseは先ほどのGreen環境、暗いBlueアイコンのGlobal Databaseは先ほどのBlue環境となっております。

今のBlue環境のエンジンバージョンは「8.0.mysql_aurora.3.10.0」となっているはずなので、青いBlueアイコンの方のGlobal Databaseを確認します。
ちゃんと「8.0.mysql_aurora.3.10.0」となっていますね。

後述しますが、AuroraのBlue/Greenデプロイは切り戻しに対応しておりません。
したがって、Blue/Greenデプロイメントは切り替えをした後は不要となります。
Blue/Greenデプロイメントを選択すると、削除を推奨するメッセージも出てきます。

Blue/Greenデプロイメントを選択し「アクション」→「削除」をクリックして、Blue/Greenデプロイメントを削除します。

Blue/Greenデプロイ時のコネクション状況

Blue/Greenデプロイ時のコネクション状況を把握するために、下記の内容のPythonスクリプトとシェルスクリプトを作成しました。

• 既存コネクション接続状況をログに出力するPythonスクリプト
  • コネクション作成後、コネクションを維持。切断されたら接続エラーをログに出力
• 新規コネクション接続状況をログに出力するシェルスクリプト
  • 0.1秒ごとにAuroraに接続し、接続できなかった場合に接続エラーをログに出力

接続先はプライマリークラスターのクラスターエンドポイントとなります。

2つのスクリプトのログを確認しますと、やはりBlue/Greenデプロイといえど既存コネクションは切断されますし新規コネクションを作成できない時間が発生することがわかりました。

[root@ip-10-0-175-21 ~]# cat persistent_connection_check.log
[2025-11-22 10:17:39] --- 接続監視スタート ---
[2025-11-22 10:17:39] 接続を確立しています...
[2025-11-22 10:17:39] 接続確立成功！この接続を維持します。
[2025-11-22 11:25:22] !!! FAILED !!! (Count: 1) - Error: (2013, 'Lost connection to MySQL server during query')

[root@ip-10-0-175-21 ~]# tail -f connection_monitor.log
--- 接続監視スタート: 2025-11-22 10:17:27 ---
2025-11-22 11:25:21.661807034: FAILED (Count: 1)

わかったこと

Global DatabaseのBlue/Greenデプロイを試して、わかったことをまとめます。

①ヘッドレスクラスターはヘッドレスクラスターのまま作成される

ヘッドレスクラスターがある場合、Green環境でもヘッドレスクラスターのまま作成されるのかそれともインスタンスも作成されるのか確認しました。
検証結果としましては、「ヘッドレスクラスターはヘッドレスクラスターのまま作成される」でした。
「Blue/Greenデプロイ完了後、ヘッドレスクラスターにするためにわざわざインスタンスを削除する」という運用は発生しなさそうです。

②マイナーバージョンアップグレードにおいて、セカンダリークラスターをグローバルデータベースからデタッチしなくても良い

インプレースアップグレードでは、特定のエンジンバージョン以降はセカンダリークラスターをグローバルデータベースからデタッチしてからではないと、マイナーバージョンアップグレードを実行できませんでした。
詳細は、私の過去の記事を参照してください。

Aurora MySQLバージョンが3.04.*または2.12.*以降の場合、Aurora MySQLグローバルデータベースのマイナーバージョンアップグレードの手順が変更されています | DevelopersIO

Blue/Greenデプロイの場合、Global DatabaseはBlue/Green環境で別物となるので、上記の制限は気にしなくても良いということだと思われます。

Blue/Greenデプロイの考慮事項

便利なBlue/Greenデプロイですが、いくつか考慮事項があります。

①コネクションは切断される

「Blue/Greenデプロイ時のコネクション状況」セクションでまとめている通り、コネクション切断なしで切り替えることは難しいです。
影響は最小限にすることはできますが、全く無いという訳ではありません。
そのため、作業の時間帯は慎重に検討する必要があります。

②マネージドな切り戻しに対応していない

次に、マネージドな切り戻しに対応していない点です。
CodeDeployのように「切り替え後に問題が発生した場合、すぐにBlue環境に切り戻す」ということができないです。

そのため、手動でBlue環境とGreen環境のクラスター名を変更する必要があります。
詳細な切り戻し方法は、下記の記事が参考になります。

Aurora Blue/Green Deploymentsによるダウンタイムを最小限に抑えたメジャーアップグレードの実現 - ZOZO TECH BLOG

また、Blue/Green環境の切り替えを実施した時点でBlue/Green環境間のレプリケーションが止まるため、切り替え後のGreen環境に保存されたデータの移行作業なども発生します。

③RDS Proxyに対応していない

RDS Proxyを利用したままBlue/Greenデプロイを実行できません。
下記の記事はRDS ProxyがあるAuroraでBlue/Greenデプロイする方法を解説をされておりますが、RDS Proxyを外す時の影響を考えるとインプレースアップグレードで対応することを推奨されています。

【Amazon Aurora MySQL】ProxyがあるAurora MySQLでBlue/Greenアップグレードを実施したい場合の手順 - サーバーワークスエンジニアブログ

その他の制限事項

他にも様々な制限事項があります。
詳細は下記の公式ドキュメントを参照してください。

Amazon Aurora ブルー/グリーンデプロイメントの制限事項と考慮事項 - Amazon Aurora

さいごに

Aurora Global DatabaseのBlue/Greenデプロイを検証しました。
Blue/Greenデプロイに対応していないためGlobal Databaseの採用を見送っているシステムがありましたら、これを機にGlobal Databaseに切り替えることも検討してください。

この記事がどなたかのお役に立てれば嬉しいです。
以上、クラウド事業本部の吉田でした！