Amazon RDS Blue/Greenデプロイを試してみた

準備
Blue/Greenデプロイをおこなう
注意
1. ステージング環境となるGreenではスキーマの変更に注意が必要
まとめ
参考

準備

下記の構成を準備する

Blue/Greenデプロイをおこなう

Blue/Greenデプロイを実施したいインスタンスを選択し、アクションからブルー/グリーンデプロイの作成を選択

GreenとなるDBインスタンスの識別子を入力
エンジンバージョンをBlueから上げて8.0.31を選択する
※ infoに記載されているように、VPCやサブネットグループなどが変更できる。

設定内容に問題がなければ、ステージング環境を作成を選択

GreenのDBインスタンスが作成中の間は画像のようになる。
test-dbはBlue
test-db-greenはgreenになっている
※test-db-greenには識別子の末尾にユニークな文字列が追加されている

test-dbのステータスも変更中となるがこの間もDBインスタンスには接続できた
確認方法としては直接DBインスタンスにてselect文を実行

完了までに2~30分かかった。
データの量によってはもっと時間がかかることが想定される

識別子test-db-greenを選択すると以下のような内容が表示される

伏せているのでわかりにくいが、ネットワークやセキュリティの設定値は、
全てBlueと同じ値となっています。

上記の状態で現在Blueのtest-dbに対してデータを追加したところ
Greenであるtest-db-greenにも反映されているのが確認できました。

早速、Greenを昇格させてみたいと思います。
test-db-greenを選択してアクションから切り替えを選択

確認画面が表示されます
今回はエンジンバージョンだけ変更しておきます
タイムアウトの設定では、切り替えにかかる時間が設定値よりもかかる場合にロールバックして、切り替えをキャンセルしてくれます。
確認したら切り替えを選択

切り替え中となっています
約1分ほど待ってからリロードすると…

切り替えが完了しています
test-dbを確認するとエンジンバージョンは8になっていて、test-db-old1という識別子に変わった元test-dbのエンジンバージョンは5なので、greenだったDBインスタンスへと切り替わったことになります。
データも確認したところ欠損はありません。

注意

ステージング環境となるGreenではスキーマの変更に注意が必要

DEFAULT必須
列の順番・名前の変更は不可
本番環境でInsertした場合にデータはステージング環境にも反映される兼ね合いで、ステージング環境のみに存在する列があり値が必須な場合、エラーとなりレプリケーションができなくなる。
ステージング環境のみにスキーマを変更する場合は要注意してください。
読み取り専用のためパラメータの変更が必要
read_onlyをfalseで設定しないとスキーマの編集ができない
まとめ
切り替えはほんとに早かったのでもしも稼働中のサービスで実施する場合には、最低限のダウンタイムでデプロイができると感じた
MySQL限定なので要注意
Aurora MySQL DB クラスターで実施する場合には、DBクラスターパラメータグループでバイナリログを有効にする必要がある