内容
RDS AuroraのMySQLのバージョンをAurora2(MySQL5.7) ⇒ Aurora3(MySQL8.0)にアップデートする際、先日のre:Invent 2022で発表された「RDSのBlue/Greenデプロイ」という新しい機能を使用してみました。
今回その手順と、詰まったポイントをまとめていきたいと思います。
添付画像の網掛けが多い点はご容赦ください。
目次
Blue/Greenデプロイの概要
Blue/Greenデプロイとは
現在運用中の環境をBlueとして、レプリケーションしたステージング環境（Green環境）を用意します。
Green環境に変更を加え、変更完了後に現在のBlue環境と差し替えることで、新しい環境を反映させていく手法になります。
RDS Blue/Greenデプロイのメリット
- すぐに運用できるステージング環境を簡単に作成できる
- データベースの変更が本番環境からステージング環境に自動的に複製される
- 本番環境に影響を与えることなく、安全なステージング環境でデータベースの変更をテストできる
- データベースのパッチとシステムの更新で最新の状態が保たれる
- 新しいデータベース機能を実装してテストできる
- アプリケーションを変更せずに、ステージング環境を新しい本番環境に切り替えられる
- 切り替えガードレール内蔵で安全に切り替えができる
- スイッチオーバー中のデータ損失を排除できる
- ワークロードにもよりますが、通常は 1 分以内ですばやく切り替えられる
ワークフロー
RDSがプライマリのDBインスタンスの設定をコピーしてGreen環境を作成する。
Green作成時にDBエンジンのアップグレードし、Blueとは別のDBパラメータグループを指定できる。
必要に応じてGreen環境に追加の変更を行う。
手順
全体像
- スナップショットを取得（バックアップ）
- 古いAuroraメジャーバージョン(blue)からクローンを実行し、古いAuroraメジャーバージョン(green)を作成
- greenのメジャーバージョンのアップグレード実行
- Auroraクラスター間で手動のMySQLバイナリログレプリケーションをセットアップして、blueからgreeenにデータの変更をレプリケーション
- green環境でスイッチオーバーの準備が整う予定のダウンタイム期間中に、blue環境を停止し、greenを新しいblueとして使用する
スナップショットを取得
念の為スナップショットは取得しておくことをおすすめしておきます。
- RDS > データベース > 対象のDB > アクション > スナップショットの取得
Blue/Greenデプロイの作成
- RDS > データベース > 対象のDB > アクション > Blue/Greenデプロイの作成
-
設定項目を記入
- Blue-Green 環境識別子：Green環境とわかる名前
- Green DBインスタンスのエンジンバージョン：この時点では現在のAuroraバージョンと合わせないとエラーとなる
- クラスターのパラメーターグループ
- DBインスタンスのパラメーターグループ
-
「ステージング環境の作成」押下
-
作成できたら完了
※注意）詰まりポイント１：クラスターのパラメータグループ設定変更
ここでBlue Green Deployments requires cluster parameter group has binlog enabled.のエラーが表示される場合は、作成元のクラスターのパラメーターグループのbinlog_format パラメータの値を OFF から MIXED に変更する必要があります。
GreenのDBに変更を加える
ここではAuroraのバージョンアップについての例を進めていきます。
Aurora2(MySQL5.7) ⇒ Aurora3(MySQL8.0)
- RDS > データベース > GreenのDBクラスター > 変更
- Auroraのバージョン変更
- パラメータグループも変更する必要があれば変更
- パラメータグループも変更する必要があれば変更
- アップデート中
- この期間中もアプリケーションは正常に稼働
- この期間中もアプリケーションは正常に稼働
変更を加えたGreenのDBをテスト
必要があればRDSのエンドポイントを使用して開発環境のアプリケーションなどから動作テストなど、確認を行う。
GreenをBlueに切り替え
-
RDS > データベース > Green環境 > 変更 > 切り替え
-
内容を確認して切り替え
詰まりポイント３）DB has a different role のエラー
完了
RDS
下記画像のように、Greenのクラスターが昇格していれば完了。
- 古い本番環境はoldの文字列が付与されている
- 新しいSTGの「DB識別子」が本番環境に変更される
- Blue/Greenが「切り替え完了」状態になる
アプリケーション
エンドポイントの紐付けが新しいインスタンスに切り替わるため、エンドポイント自体は変わらない。
よって接続情報を変更する必要なし。
コードを何も変更せずとも、正常にアプリケーションは稼働。
後始末
- 新しく本番環境となったDBインスタンスの識別子を変更（必要あれば）
- 識別子を変更するとエンドポイントが変わるため、アプリケーションやSequelの接続情報変更必要（.envの変更を反映させるまではダウンタイムが発生することになる）
- 古い環境となったDBインスタンスを削除
- ブルーグリーンデプロイメント削除
トラブルシューティング
詰まりポイント１）クラスターのパラメータグループ設定変更
Blue -> Green のレプリケーションにbinlogを使用するため、作成元のパラメータグループを変更する必要がある。
（>> 参考記事）
-
パラメータグループ > 対象のパラメータグループ > binlog_formatをMIXEDに変更
-
クラスターを再起動
- 再起動しないと以下のエラーが出る
- 再起動時に10秒ほどダウンタイムが発生してしまうので、時間帯に注意する
- 再起動しないと以下のエラーが出る
詰まりポイント２）db.t3.small
db.t3.smallはAurora V3に非対応。
db.t3.mediumに上げる必要がある。
DBエンジンバージョン対応表
詰まりポイント３）DB has a different role のエラー
GreenをBlueに切り替えようとした時に下記エラー
DB instance xxx-aurora57-instance-1 has a different role than xxx-aurora57-instance-1-green-5xclwb
(DBインスタンス xxx-aurora57-instance-1 は xxx-aurora57-instance-1-green-5xclwb とは異なる役割を持ちます。)
原因
このエラーは、Greenクラスターのロールが変更されそのクラスタのライターがあるノードから別のノードに切り替わったことが原因。
解決法
Greenクラスタでfailover-db-clusterを呼び出してライターにする。
-
RDS > データベース > エラーが出ているdbインスタンス（ここではxxx-aurora57-1-green-5xclwb）> アクション > フェイルオーバー
-
確認画面 > フェイルオーバー
-
実行完了すると、xxx-aurora57-instance-1-green-5xclwbがライターに昇格する
-
これで再度切り替えを実行すると成功する
最後に
Blue/Greenデプロイを実施した手順をまとめてみました。
事前設定などで怒られることが多く、今回は生じた事象と解決した方法をそのまま記述してみましたが、もっとよい解決方法などあればコメントに残していただけると幸いです。
ここまでお付き合いいただきありがとうございました。