垣見です。
通常ProxyがあるAmazon AuroraではBlue/Greenアップグレードをすることはできませんが、無理やり実施するとどうなるか手順をまとめました。
基本おすすめはインプレースアップグレードやバイナリログレプリケーションでのアップデートですが、それらとの比較やBlue/Green Deloymentsの仕様の把握の手助けになれば幸いです。
また、Proxy付け外し関連の項目を除けば通常手順としても使うことが出来るので参考になればと思います。
- はじめに
- このブログでやること
- 注意事項
- バージョンアップ手順 - 事前準備
- バージョンアップ手順 - 本番作業
- 3. RDS Proxy経由で利用しているアプリケーションを停止する
- 4. 移行前(Blue環境)の DB インスタンスから Proxy の関連付けを解除する
- 5. Blue/Green Deployment 環境を作成する
- 6. Green 環境に Proxy を関連付けする
- 7. アプリケーションの利用を再開し、Green 環境で入念な動作確認を行う
- 8. Blue/Green 環境の切り替えの前に、Proxy 経由で利用しているアプリケーションの利用を停止する
- 9. Blue環境の DB インスタンスから Proxy の関連付けを解除する
- 10. Blue/Green環境の切り替えを行う
- 11. 切り替え完了後、Proxy を Green 環境 に関連づける
- 12. アプリケーションの利用を再開する
- 13. Blue/Green Deloyment 環境を削除する
- バージョンアップ手順 - 事後作業
- 終わりに
はじめに
Amazon Aurora MySQL 互換エディション バージョン 2 (MySQL 5.7 互換) は 2024 年 10 月 31 日に標準サポートを終了する予定です。
Amazon Aurora MySQL 互換エディションバージョン 2 の標準サポート終了に向けて準備する
数多のエンジニアが対応に追われたこのお知らせ、SWXでも例外ではありませんでした。
それに関連し、Auroraのアップグレード手順を色々と検証したのでブログにまとめます。（もう少し早く出せればよかったですね）
今回は、RDS Proxyがある場合のBlue/Greenアップグレード（Blue/Green Deoloymentsを使用したアップグレード）の検証です。
Blue/Green Deoloymentsでは既存の環境（Blue環境）から一部変更を加えたレプリカ環境（Green環境）をマネージドで作成し、これをスイッチすることで新たな設定のDBに接続を置き換えられます。
一瞬で切り替えができてアプリケーションのダウンタイムを削減できる！元環境がイミュータブル（不変）だ！と人気のBlue/Green Deoloymentsですが、実はけっこう制約(参考：ブルー/グリーンデプロイの考慮事項と制限）があります。その一つがこれです。
ブルー/グリーンデプロイは、以下の機能ではサポートされていません。
・ Amazon RDS Proxy
・クロスリージョンリードレプリカ
・Aurora Serverless v1 DB クラスター
・Aurora Global Database の一部である DB クラスター
・AWS CloudFormation
そう、RDSのBlue/Green DeploymentsはProxyがある状態では行うことができないのです。
そのためBlue/Green環境作成のためにCLIでRDS Proxyの紐付けを解除する必要があり、RDS Proxy経由のアプリケーションでは結局サービスの停止時間が発生してしまいます。
結論としては以下の通りです。
- ProxyありでBlue/Green DeploymentsをするとProxy解除のために長時間サービスが停止するので、その停止時間が許容できるならインプレースアップグレードで良い
- ステージング環境（Green環境）としてデータベース本体を変えずにテストできるといった利点(参考：Amazon RDS ブルー/グリーンデプロイを使用する利点)も挙げられるが、普通にクローンを作成したほうがシンプル
手順が複雑かつ結局環境を止めてしまうことになるので、私が担当したお客様の場合も結局インプレースアップグレードを実施しました。
ちなみに
ちなみに、一般的に想像される「ブルーグリーン」から誤解しやすいのですが、、Blue/Green Deployment によるマネージドなダウングレード（→いわゆる「アップグレード後の切り戻し」）はできません。
旧クラスターから新DBクラスターへの切り替えはコンソール上のボタンでマネージドに行えるものの、切り戻しに関してはダウンタイムやProxy関連のお客様側での複雑な作業が発生するというデメリットがございます。意外と制約が多いですね。
ただそれでも他の手順と判断できるといいかと感じたため、（そしてせっかく検証したので、）手順をこちらのブログで載せています。
また、今回検証できていないのですが、インプレースアップグレード、Blue/Greenアップグレードの他に、「手動にて旧DBクラスターから新DBクラスターへバイナリログレプリケーションを行う」といった方法もあるようです。
このブログでやること
概要
Amazon Aurora MySQL 2 (MySQL 5.7 互換) をAmazon Aurora MySQL 3（MySQL 8.0 互換) へアップグレードするためのBlue/Green Deploymentsの方法です。
基本的には以下の公式記載の手順を参考にしますが、Proxyに対応するための手順を追加している箇所があります。
参考：AWS公式 Amazon RDS ブルー/グリーンデプロイの概要
作業の流れ
①初期状態。2AZのライターとリーダーのクラスターに、アプリケーションがProxy経由で繋がっている。
②エンジンバージョンをアップグレードしたBlue/Green Deployment環境を作成する。これにより、MySQL8.0互換のレプリカクラスター（Green環境）ができる。Blue/Green環境作成時にはProxyとアプリの関連付けを外す。
※ここから⑤まで本番アプリケーションが停止することになります
③一度アプリケーションとGreen環境の接続や互換に問題が無いかを確かめる。
④Blue/Greenを切り替える。これにより、「古いブルー」と「新しいブルー」ができる。切り替え時にはProxyとアプリの関連付けを外す。
⑤新しいブルーにProxyを関連付けてアプリケーションを再開する。良く確かめる。
⑥Blue/Green Deployment環境を削除する。旧環境はまだ消えていない。
⑦要件次第で旧環境を削除する。
対象
- エンジンバージョン：5.7.mysql_aurora.2.11.5 - メジャーバージョンのデフォルト 5.7
- ライターインスタンス（test-write-1a）とリーダーインスタンス（test-read-1c）の2つのクラスター（database-1）構成のAuroraMySQL
- RDSカスタムクラスターパラメータグループ（test-aurora-mysql57-cpg）を使っており、
binlog_formatがOFF（デフォルト）である（この場合変更処理が必要です） - RDS Proxyが存在する
- マルチAZ配置（Tokyoの1a, 1cのVPCを指定しています）（RDSの対象が3AZ以外のサブネットグループ（1AZ, 2AZ）だと失敗するといった報告が昔はあったようですが、確認したところ2サブネットのサブネットグループでもうまくいきました）
- マスターユーザーの認証情報はSecrets Managerではなくセルフマネージド（※Secrets Managerの場合Blue/Green Deploymentsが基本的にはできません。ご興味がある場合、以下のブログもご確認ください）
注意事項
「はじめに」に記載した内容と重複する部分がありますが、以下懸念点があります。
もし同様の手順を実行する場合、このブログがあくまで検証だということをご理解いただき、 十分に検証を行って他の手順と比較検討したうえ で実施をお願いいたします。
- Proxyを外す間はアプリケーションが使えない状態になります。その停止時間が許容できる場合、インプレースアップグレードがおすすめです。
- 今回はIAM権限周りについては触れませんが、IAM ロールはブルー環境からグリーン環境にコピーされません。ブルー/グリーンデプロイを切り替える前に、IAM ポリシーがグリーン環境に適切に適用されていることを確認してください。
- デフォルトのRDSカスタムパラメータグループ（クラスター）について、
binlog_formatがOFFになっているため、RDSのパラメータグループでバイナリログ出力の有効化設定（binlog_format⇒MIXED）を行い、その後DBの再起動を行う必要があります。 再起動中はRDSが使えない状態 になります - Blue/Green Deployment によるマネージドなダウングレードはできません。旧クラスターから新DBクラスターへの切り替えはマネージドに行えるものの、切り戻しに関してはダウンタイムやProxy関連のお客様側での複雑な作業が発生するというデメリットがございます
- インフラだけ触っていると忘れがちですが、AWSだけでなくMySQL側のドキュメントも見てきちんとアプリ側との互換性も確かめる必要が有ります（戒め）（参考：MySQL 8.0 の新機能）
その他にも今回は触れていない制約や注意事項がございますので、こちらの公式ドキュメントもよくご確認ください：
バージョンアップ手順 - 事前準備
- 以下、もともとあった環境をBlue環境、アップグレード後の環境をGreen環境と表します
1. Green環境用パラメータグループの作成
Green環境用のパラメータグループを作成する
Green環境ではパラメータグループファミリーをaurora-mysql-8.0にする必要があるので、新たなカスタムパラメータグループを作成してください。
パラメータグループ名：<任意の名前> 説明: <任意の説明> パラメータグループファミリー：aurora-mysql-8.0 タイプ: DB Cluster Parameter Group
Green環境用のパラメータbinlog_formatを変更する
- 先ほど作ったパラメータグループを選択＞アクション＞編集 でパラメータグループ
binlog_formatをOFFからMIXEDに変更します。 - またこの際、予め新環境で必要なカスタムパラメータの設定があれば適宜行ってください。
2. Blue環境用のパラメータbinlog_formatを変更する
Blue環境用のパラメータbinlog_formatを変更する
- 対象RDSの現行のカスタムパラメータグループ（クラスター）を選択＞アクション＞編集 で、
binlog_formatをOFFからMIXEDに変更する- カスタムパラメータグループが存在する環境の場合は必要ないですが、もしデフォルトパラメータグループを使っている場合はカスタムパラメータグループを新たに作り直し、そのbinlog_formatを変更して割り当ててください。手順は上記「Green環境用パラメータグループの作成」を参照してパラメータグループファミリー：aurora-mysql-5.7になるよう作成してください。
- クラスタパラメーターグループの変更に「再起動を保留中」がスケジュールされていることを確認する
binlog_format パラメータを OFF から別の値に変更した場合、変更を有効にするには、Aurora DB クラスターを再起動する必要があります。
参考：レプリケーション出典のバイナリログ記録を有効にする
その他参考：AWS公式 DB クラスターパラメータグループのパラメータの変更
Blue環境を再起動する
- クラスター内のプライマリ (ライター) DB インスタンスを選択>アクション>再起動>確認 を実施して、変更を適用する
- プライマリ (ライター) DB インスタンスのステータスが
再起動中から利用可能になったのを確認する - リーダー DB インスタンスを選択>アクション>再起動>確認 を実施して、変更を適用する
- リーダー DB インスタンスのステータスが
再起動中から利用可能になったのを確認する
上記手順はライターとリーダーを独立させて再起動させていますが、クラスターを一度にまとめて再起動することも可能です。再起動時にはアプリケーションを止める場合など、必要に応じて使い分けてください。手順は以下を参考にしてください。
参考：ライターとリーダーの独立した再起動
参考：Aurora クラスター内の DB インスタンスの再起動
データベースに接続し、バイナリログの適切な保持期間を設定する
- 指定時間バイナリログを保持できるようにシステムを構成することで、適切なレプリケーションを維持することができます。
- データベースに接続し、下のようなコマンドを入力することでバイナリログファイルの保持期間を 12時間に設定できます
- ※ログが短期的に急増する場合や負荷が大きなDBの場合、長く設定するとバイナリログが溢れて運用上厳しい可能性があります。また、短く設定すると想定より早くログが消えてしまう可能性がありやりたいこと（レプリケーション）が実現できない場合があります。デフォルトは「NULL（AWSのタイミングで行われる）」という項目なので、仮置きとして今回の数字では12時間を設定しております。必要に応じてご調整ください。
- ご参考までに、検証したところ、この項目を実施しないとBlue/Green Deploymentsでのアップグレード自体が絶対にできないというわけではないようです。データの性質ごと調整するパラメータとしてお考えいただければ幸いです
CALL mysql.rds_set_configuration('binlog retention hours', 12);
参考： AWS公式 レプリケーションソースのバイナリログを不要になるまで保持する AWS公式 ブルー/グリーンデプロイの作成
さらに、バイナリログファイルが消去されないように、バイナリログの保持期間を NULL 以外の値に変更することをお勧めします。詳しくは、「設定」を参照してください。
バージョンアップ手順 - 本番作業
3. RDS Proxy経由で利用しているアプリケーションを停止する
アプリケーション側の手続きに関しましては事前にご確認お願いいたします。
基本的にはアプリケーションサーバーを停止して頂ければ問題はないかとは思いますが、慎重に確認される場合はCloudWatchメトリクスのDatabaseConnectionsなどを見て頂き、接続が無い状態を確認していただけると安全でございます。
4. 移行前(Blue環境)の DB インスタンスから Proxy の関連付けを解除する
検証時点ではマネジメントコンソールから関連付けの解除が行えなかったため、以下 AWS CLI コマンドを用いて関連付けを解除する必要がある認識です。
- CloudShellからCLIコマンドでProxy の関連付け解除を実行してください。
- 例えば以下のような形としてください。参考：AWS公式 RDS Proxy の削除
$ aws rds deregister-db-proxy-targets --db-proxy-name <RDS Proxy名> --target-group-name <ターゲットグループ名> --db-cluster-identifiers <DBクラスター識別子>
- 今回の環境の場合、
aws rds deregister-db-proxy-targets --db-proxy-name proxy-1 --target-group-name default --db-cluster-identifiers database-1となります。 「関連付けられたデータベース」部分が空欄になれば終了です。
ターゲットグループ名は RDS>プロキシ>プロキシ選択>ターゲットグループ のように確認できます。
5. Blue/Green Deployment 環境を作成する
Blue/Green Deployment 環境を作成する際、 移行後の環境 (Green環境) の DB エンジンバージョンとクラスターパラメータグループを指定して DB インスタンスの作成を行うことで、Amazon Aurora MySQL 2 からAmazon Aurora MySQL 3 へのアップグレードが行えます。
RDS>データベース>クラスターを選択>アクション>ブルー/グリーンデプロイの作成-新規 を選択する。
以下を入力し、「ステージング環境の作成」を押す
ブルー/グリーンデプロイ識別子: <任意の名前> グリーンデータベースのエンジンバージョン: Aurora MySQL 3.06.1 (compatible with MySQL 8.0.34) #最新などのアップグレード対象を選んでください グリーンデータベースの DB クラスターパラメータグループ: <先ほど新規作成したMySQL8.0用のパラメータ> #デフォルトは選ばないでください グリーンデータベースの DB パラメータグループ: default.aurora-mysql8.0 #デフォルト。必要があればカスタムで作成しておいてください
- ブルー/グリーンデプロイ環境（
ロール: ブルー/グリーンデプロイとなっている部分）が「ステータス: 利用可能」となったら完了です - Green環境の名前に識別子が付いていますが、このままにしておいても切り替え後にBlue環境と同じ名前になるので気にしなくて大丈夫です。
インスタンスにもよりますが、それなりに時間がかかります。自分がやったときには空のデータベースで45分かかりました。
イベントログ例
イベントログはこんな感じです。
スクショがつぶれて見えなかったらこちらのログをご覧ください。(長いので閉じておきます）
クリックして展開
| ソース | タイプ | 時間 | メッセージ |
|---|---|---|---|
| database-1-green-5pawyl | クラスター | September 27, 2024, 16:55 (UTC+09:00) | DB cluster created |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 16:57 (UTC+09:00) | Cluster topology is updated. |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 16:59 (UTC+09:00) | Binlog position from crash recovery is mysql-bin-changelog.000002 154 |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:01 (UTC+09:00) | DB instance created |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:01 (UTC+09:00) | DB instance shutdown |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:01 (UTC+09:00) | DB instance restarted |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:02 (UTC+09:00) | Replication for the Read Replica resumed |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:03 (UTC+09:00) | Monitoring Interval changed to 60 |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:03 (UTC+09:00) | Performance Insights has been enabled |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:04 (UTC+09:00) | Replication for the Read Replica resumed |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:05 (UTC+09:00) | Finished updating DB parameter group |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:06 (UTC+09:00) | Database cluster engine major version upgrade started. Cluster remains online. |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:07 (UTC+09:00) | Upgrade preparation in progress: Starting online upgrade prechecks. |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:07 (UTC+09:00) | Upgrade preparation in progress: Completed online upgrade prechecks. |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:07 (UTC+09:00) | Taking database cluster offline while the primary instance completes the patch/upgrade process. |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:07 (UTC+09:00) | DB instance shutdown |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:07 (UTC+09:00) | Upgrade preparation in progress: Starting offline upgrade prechecks. |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:07 (UTC+09:00) | Upgrade preparation in progress: Completed offline upgrade prechecks. |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:07 (UTC+09:00) | Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-database-1-green-5pawyl...]. |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:10 (UTC+09:00) | Upgrade in progress: Cloning volume. |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:12 (UTC+09:00) | Upgrade in progress: Purging undo records for old row versions. Records remaining: 2086 |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:15 (UTC+09:00) | DB instance shutdown |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:15 (UTC+09:00) | DB instance restarted |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:16 (UTC+09:00) | Database cluster is online. Workflow is able to make connections to cluster end points. |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:17 (UTC+09:00) | Updated to use DBParameterGroup test-aurora-mysql80-cpg |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:19 (UTC+09:00) | The DB instance will be rebooted after the major version upgrade in order to apply the parameters. |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:19 (UTC+09:00) | Database cluster engine major version has been upgraded. |
| database-1-green-5pawyl | クラスター | September 27, 2024, 17:19 (UTC+09:00) | Database cluster engine major version upgrade complete. |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:21 (UTC+09:00) | DB instance shutdown |
| test-write-1a-green-a3qidx | インスタンス | September 27, 2024, 17:21 (UTC+09:00) | DB instance restarted |
| test-read-1c-green-s8cx1s | インスタンス | September 27, 2024, 17:23 (UTC+09:00) | Cluster topology is updated. |
| test-read-1c-green-s8cx1s | インスタンス | September 27, 2024, 17:26 (UTC+09:00) | DB instance created |
| test-read-1c-green-s8cx1s | インスタンス | September 27, 2024, 17:26 (UTC+09:00) | DB instance shutdown |
| test-read-1c-green-s8cx1s | インスタンス | September 27, 2024, 17:26 (UTC+09:00) | DB instance restarted |
| test-read-1c-green-s8cx1s | インスタンス | September 27, 2024, 17:28 (UTC+09:00) | Monitoring Interval changed to 60 |
| test-read-1c-green-s8cx1s | インスタンス | September 27, 2024, 17:28 (UTC+09:00) | Performance Insights has been enabled |
| test-read-1c-green-s8cx1s | インスタンス | September 27, 2024, 17:29 (UTC+09:00) | Finished updating DB parameter group |
| bgd-ijvtfakjqaftok7n | ブルー/グリーンデプロイ | September 27, 2024, 17:30 (UTC+09:00) | Blue/green deployment tasks completed. You can switch over the deployment. |
進行状況ステータス例
こちらは開始から終了までの進行状況ステータスの時系列スクショです。
ひたすら進行状況ステータスを見続けたところ、特に最初の作成のあたりはイベントログに反映されていないようだということがわかりました。
クリックして展開
※別作業をしながらだったので中盤確認が数分遅れているかもしれないところがあります。
開始：16時45分
終了：17時30分
うまくいかない場合
バイナリログを有効後に更新がない場合、バイナリログを有効後にINSERT文やUPDATE文を実行してみてください
- 再現検証できておらず恐縮ですが、バイナリログを有効後に、INSERT/UPDATEなどの更新系クエリが実行されていない状態で、即座にデプロイメントを有効にし、レプリケーションを開始すると、1つ目のバイナリログが消失し正常なレプリケーションが失敗するバグが確認されているようです
6. Green 環境に Proxy を関連付けする
マネジメントコンソール経由、もしくは以下の AWS CLI コマンドを利用可能です。
マネジメントコンソールの場合：
- RDS>プロキシ>プロキシ選択>ターゲットグループ>ターゲットグループ識別子を選択>編集>データベース: Green環境のレプリカクラスターを選ぶ（その他設定はもともとのアプリケーションとの関係に準拠してください）>変更を保存
- 「接続プールの最大接続数」でエラーが出る場合、デフォルト入力値を一度削除してもう一度入力するとうまくいきます
CLIの場合:
- 以下をCloudShellで実行してください
$ aws rds register-db-proxy-targets --db-proxy-name <プロキシ識別子> --db-cluster-identifiers <DBクラスター識別子>
注意点として、RDS Proxyの仕様上、read_only パラメータが有効になっている場合はアタッチができかねます。
もし、失敗する場合はGreen環境の確認は DB エンドポイント経由で動作確認を行なっていただく、または、read_onlyのパラメータを変更して頂く必要があります。
DB パラメータグループが 1 に設定された read_only パラメータを含む RDS for MySQL DB インスタンスでは、RDS Proxy を使用できません。
参考：Amazon RDS Proxy for Aurora の使用
7. アプリケーションの利用を再開し、Green 環境で入念な動作確認を行う
Green 環境で RDS Proxy 経由のアプリケーションの利用を再開できるようになっているため、ご確認をお願いいたします。
アプリケーション側の手続きに関しましては事前にご確認お願いいたします。
事前にアプリケーションサーバーを停止して頂ければDBへの接続はない問題であると思いますが、慎重に作業を進められる場合は CloudWatchメトリクスのDatabaseConnectionsなどを見て頂き、接続が無い状態を確認していただけると安全でございます。
また、入念な動作確認を行う際、以下 注意点 があります。
- テスト中は、Green環境のデータベースを読み取り専用に保つことを推奨致します。
- Green環境では仕様としてReadOnlyになっているので、書き込み操作を有効にする場合は注意が必要となります。
書き込みをするためには、パラメータグループを変更する必要があります。
- パラメータグループにて、read_only パラメータを0に設定する方法
- RDS>パラメータグループ>Green環境のクラスターパラメータグループを選択>アクション>編集>パラメータグループ
read_onlyを{TrueIfReplica}から0に変更します
- RDS>パラメータグループ>Green環境のクラスターパラメータグループを選択>アクション>編集>パラメータグループ
- Green環境の 再起動 を行ってください
- パラメータグループにて、read_only パラメータを0に設定する方法
8. Blue/Green 環境の切り替えの前に、Proxy 経由で利用しているアプリケーションの利用を停止する
Green環境チェックのためにProxyをもとに戻しましたが、切り替え作業時にはProxyを解除する必要があります。
アプリケーション側の手続きに関しましては事前にご確認お願いいたします。
基本的にはアプリケーションサーバーを停止して頂ければ問題はないかとは思いますが、慎重に確認される場合はCloudWatchメトリクスのDatabaseConnectionsなどを見て頂き、接続が無い状態を確認していただけると安全でございます。
9. Blue環境の DB インスタンスから Proxy の関連付けを解除する
CloudShellから以下のCLIコマンドで実行してください。
$ aws rds deregister-db-proxy-targets --db-proxy-name <プロキシ識別子> --target-group-name <ターゲットグループ名> --db-cluster-identifiers <DBクラスター識別子>
今回の場合はaws rds deregister-db-proxy-targets --db-proxy-name proxy-1 --target-group-name default --db-cluster-identifiers database-1-green-5pawylですね。
10. Blue/Green環境の切り替えを行う
RDS>データベース>Blue/Green Deploymentsを選択>アクション から 「切り替え」を選択する
スイッチオーバーの概要が出るので、間違いないか確認して「切り替え」を選択してください。
- 切り替えを実施すると「ステータス: 切り替え」となります
- 切り替えが完了するとデプロイメントのステータスが「切り替え完了」となります
- Blue環境には「old」の識別子が付き、グリーンは「新しいブルー」となって元のブルーと同じ名前に変わります。
- イベントログはこんな感じになっています
11. 切り替え完了後、Proxy を Green 環境 に関連づける
こちらの変更は非同期で行われるため、変更直後は Blue 環境に接続される可能性がございます。Proxy 経由で接続した際、select version();等で Green 環境に接続されているかどうかご確認ください。
マネジメントコンソールの場合：
- RDS>プロキシ>プロキシ選択>ターゲットグループ>ターゲットグループ識別子を選択>編集>データベース: 新環境のリージョン別クラスターを選ぶ（oldとついていない方）
CLIの場合:
- 以下をCloudShellで実行してください
$ aws rds register-db-proxy-targets --db-proxy-name <プロキシ識別子> --db-cluster-identifiers <DBクラスター識別子>
12. アプリケーションの利用を再開する
アプリケーション側の手続きに関しましては事前にご確認お願いいたします。
基本的にはアプリケーションサーバーを停止して頂ければ問題はないかとは思いますが、慎重に確認される場合はCloudWatchメトリクスのDatabaseConnectionsなどを見て頂き、接続が無い状態を確認していただけると安全でございます。
13. Blue/Green Deloyment 環境を削除する
- ブルー/グリーンデプロイ環境（
ロール: ブルー/グリーンデプロイとなっている部分）を選択（クラスターやインスタンスと間違えないように注意してください）>アクション>削除>ポップアップの指示に従って削除
こんな感じです。
この時点では古いBlue環境は消えません。
あくまでBlue/Green Deployment環境の削除で、バージョンアップ前と後の二つのクラスターが存在する状態になります。
古いBlue環境の削除には事後作業での手作業が必要です。（逆に削除しないこともできます）
バージョンアップ手順 - 事後作業
14. (必要に応じて) 古いBlue 環境を削除する。
切り戻しが発生する場合は削除せず保持しておきます。また、必要に応じ停止期間などをはさんでからの削除としてください。
古いBlue環境は-oldがついた方となるので間違えないようご注意ください。
- 古いBlue 環境のリーダーインスタンスの削除
- 古いBlue 環境のライターインスタンスの削除
- 古いBlue 環境のDBクラスターを削除
参考：AWS公式 Aurora DB クラスターと DB インスタンスを削除する
～完～
終わりに
やっぱりシンプルにインプレースアップグレードが良さそうですね…。
このブログが誰かの助けになれば幸いです。
ちなみにRDSリソースダッシュボードにはProxyが書かれていないため、消し忘れには注意しましょう。あとRDSはスナップショットにもお金がかかるのでくれぐれも（以下略
