はじめに
最近 Amazon RDS Blue/Green Deployments なるものがリリースされました。今回は実際に Blue/Green のスイッチオーバーまでやってみました。
検証準備
- Aurora MySQL クラスターの準備。最初 MySQL8.0系を選択しましたが、こちらは対応しておりませんでした。ちゃんとドキュメント読んでからやりましょう。今回は MySQL5.7系で起動しておきます。
- パラメータグループを編集して、バイナリログを有効化します。(binlog_format → MIXED)
検証開始
クラスターを選択し、「アクション」から「ブルー/グリーンデプロイの作成」をクリックする。
ブルー/グリーンデプロイの作成画面にて、「Blue-Green 環境識別子」を入力する。今回は推奨とあるので、MySQL8.0系へのスイッチオーバーを実施してみる。(失敗フラグ)
「Green DB インスタンスの月額料金の見積もり」も出してくれるのでとても安心できますね。内容に問題が無ければ、「ステージング環境の作成」をクリックします。
しばらくして、「Blue-Green 環境の作成に失敗しました」とエラーが表示されました。
エラーステータスでロールが「ブルー/グリーンデプロイ」となっているリソースを選択し、「ログとイベント」で確認してみると、今回ブルー環境で指定した t3.small は MySQL8.0系インスタンスがサポートしていないタイプなので起動できていない事がわかりました。(じゃあ、推奨で。と突き進み、無事フラグ回収)
ちなみに、起動している様に見えるグリーン環境は MySQL5.7系で起動されていました。笑
一旦「ブルー/グリーンデプロイ」ロールを削除し、ブルー環境と同バージョンで再挑戦。
次はうまく行ったようです。特にエラー無くグリーン環境が作成されたました。
グリーン環境のクラスターに MySQL クライアントで接続してみます。
やはり、普通に MySQL レプリケーションが設定されていました。正常にレプリケーションができている事がわかったので、「アクション」から「切り替え」をクリックします。
切り替えの概要、レプリカ設定の詳細を確認します。タイムアウトの設定は、切り替えにかかる制限時間を指定できます。この時間をすぎるとスイッチオーバーはされません。では、切り替えをクリックします。
スイッチオーバーが完了すると、下記のよう状態になります。database-1 が database-1-old1 に名前変更され、staging-database-1 が database-1 に名前変更されるイメージでしょうか。これを手動でやると名前変更時にインスタンス再起動が走るので、そのあたりはブルー/グリーン両方で一時的に書き込みをロックし、データの整合性を保った上で名前変更処理をマネージドサービス内でうまいことやってくれてる感じなんですかね。
まとめ
今までは、スナップショットから別のクラスターを起動させ、ポジションをログから取得して手動で MySQL レプリケーションを設定する場面などありましたが、そのあたりが完全にマネージドサービス化された印象です。他にもマネージドサービスならではの機能がありますが、今回の検証はここまでにします。
今後、バージョンアップ対応やメンテナンス対応がスムーズに行える良い機能ですね。是非活用して行きたいです。
投稿者プロフィール

-
AWS認定12冠
趣味 : スプラトゥーン
最新の投稿
AWS2025年1月5日Migration Evaluator について調べてみた
AWS2024年1月9日Amazon S3 Express One Zone を使ってみた
マイグレーション2024年1月9日AWS Migration Hub を使ってみた
AWS2024年1月9日AWS Application Discovery Service (ADS) を使ってみた