Aurora MySQLでBlueGreenデプロイを使用した際の切り戻し方法

# はじめに
アイスタイルのDBREチームに所属している新卒2年目のisomです。

アイスタイルでは、複数種類のRDBMSを使用していますが、一部でAmazon Auroraを利用しています。
2024年6月頃に、BlueGreenデプロイを使用してAuroraのエンジンバージョンを5.7.mysql_aurora.2.11.1から8.0.mysql_aurora.3.04.2にバージョンアップを行いました。

現在(2024年6月)、BlueGreenデプロイでは切り替え後の切り戻しについてはサポートがされていません。
そのため、今回は6月のリリースの際に考えたAurora MySQLでBlueGreenデプロイを使用した際の切り戻し方法を紹介しようと思います。

:::note info
本番環境での移行で切り戻しが発生しなかったため、ステージ環境での検証まで行っています。
:::

# 実行環境

|  |エンジンバージョン | 
|:-----------|:-----------|
| Blue側       | 5.7.mysql_aurora.2.11.1  | 
| Green側     | 8.0.mysql_aurora.3.04.2   | 


#  DB接続のエンドポイントを変更しない切り戻し手順

1. BlueGreenを削除する
1. （必要に応じて）Green側からBlue側へのレプリケーションを行う
1. アプリケ－ションをメンテナンスの状態にする
1. Green側のエンドポイントを変更する
1. 古いBlue側のエンドポイントをアプリケーションが指定しているエンドポイントに変更する
1. メンテナンスを解除する
1. （レプリケーションを行った場合）レプリケーションの設定を削除する

# 手順詳細
## 0.切り替え後の状態
ブルーグリーンを切り替えた後、下記の画像のような状態となります。
dev-testdbがアプリケーションで利用されるAuroraクラスターです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/651971/f187cc43-b94a-a4a0-683d-23763bad83af.png)


|  |　クラスター名 |エンジンバージョン | 
|:-----------|:-----------|:-----------|
| 古いブルー     | dev-testdb-old1 | 5.7.mysql_aurora.2.11.1  | 
| 新しいブルー    |dev-testdb |  8.0.mysql_aurora.3.04.2   | 

## 1.BlueGreenを削除する
「dev-testdb-bg」を選択し、アクション>「削除」でBGを削除します。
![2024-03-29-01-02-40 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/651971/da8505ba-de5b-5442-c567-a15e5db3564e.png)


削除した後の状態▼
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/651971/42974ed3-2fca-d533-78c8-5b45d6c2d964.png)



## 2.（必要に応じて）Green側からBlue側へのレプリケーションを行う

今回リリースでは、切り戻しの際に停止時間を設けることができたため、mysqldumpとリストアで切り戻しをする予定で進みました。
そのため、今回はレプリケーショの手順は省きます。
もし、レプリケーションを行う場合は、バイナリログレプリケーションやDMSを使用して古いBlue側にレプリケーションを行います。

:::note warn
現在、MySQLでは下位バージョンへのレプリケーションはサポートされていないので、検証を重ねてから取り入れてください。
:::

## 3.アプリケ－ションをメンテナンスの状態にする
データベースへのアクセスを減らすためメンテナンス状態にします

## 4.Green側のエンドポイントを変更する
インスタンス「dev-testdb-instance-1」を選択し、「変更」を押し、クラスター名とインスタンス名を本番環境とは違う名前に変更します。

クラスター名の変更を行うとエンドポイントも一緒に変更されます。
![画像1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/651971/eea6c39d-6dc9-95d8-737b-71f4d78c2f59.png)

## 5. 古いBlue側のエンドポイントをアプリケーションが指定しているエンドポイントに変更する
インスタンス「dev-testdb-old1」を選択し、「変更」を押し、クラスター名とインスタンス名を本番環境のアプリケーションが指定しているエンドポイント名になるように変更します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/651971/e7963c4a-5da8-846f-dd77-1ded65c7d7c8.png)

:::note info
変更に10分ほどかかります。（[参考](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_RenameInstance.html))
:::

上記を行うことで、このようにエンドポイントを元に戻すことができました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/651971/dab92cbc-2a2c-b81a-7b06-6a9544372910.png)

## 6. アプリケ－ションのメンテナンスを解除する
本番環境のエンドポイントで接続ができることを確認してからメンテナンスを解除してください。

## 7. （レプリケーションを行った場合）レプリケーションの設定を削除する

以上になります！

# まとめ
最後まで読んでいただきありがとうございました。

もし、DB接続のエンドポイントが変更可能な場合は下記の順になり、
1. BlueGreenを削除する
1. Green側からBlue側へのレプリケーションを行う
1. アプリケーションのDB接続のエンドポイントを変更する
1. レプリケーションの設定を削除する

という方法になります。こちらは短時間で切り戻し作業ができます。

DB接続のエンドポイントを変更しない切り戻し方法で、検証した際は切り戻しに停止時間が40分ほど必要になりました。BlueGreenを使用した手法は切り戻しなしで考えると素敵ですが、切り戻しが発生すると少し大変だなという印象を受けます。

MySQL8.4以降から下位へのレプリケーションがサポートされるとの発表がありましたのでBlueGreenデプロイも切り戻しのサポートもされるとより便利だなと思います:sparkles: