こんにちは あるいは こんばんは
SCSKの猿橋です。
昨年末2022/12にAmazon Aurora/RDS向けのフルマネージド型 Blue/Green Deploymentes機能がリリースされました。
色々な記事で試されていますが、まだ不安定でエラーがあるかもしれない、という話が聞かれます。
しかしながら手間がかかるバージョンアップ作業をコンソールでGUIで進められるのは大きなメリットでしょう。
今回はこのBlue/Green Deploymentを試してみました。
Blue/Green Deploymentとは
DBをバージョンアップするにはDBを停止する必要がありますが、なるべくダウンタイムを抑えたいシステムもあるかと思います。
そこで、現行環境：Blue環境に対し、同じ構成の新環境：Green環境を用意＋バージョンアップしておき、DB接続先をBlue⇒Greenに切り替えることでダウンタイムを最小化するリリース手法です。
Amazon AuroraとAmazon RDS MySQLのBlue/Green Deploymentsはフルマネージド型であるため、以下のメリットがあります。
- Blue/Green環境間でデータの不整合が発生しない
・Blue/Green間でレプリカ設定される為、Blue環境にデータ更新が発生してもGreen環境に同期してくれる
・切替する際、Blue環境を読み取り専用に切り替える為、Blue/Green間の不整合は発生しない仕組み - DBエンドポイントが不変
Blue/Green切り替え時、エンドポイントは変わらずDB内部の接続先が切り替わる為、アプリケーション側のDB接続先変更が不要
注意点として、ダウンタイムが発生する場合があります。
- DBパラメータグループでbinlog_formatを変更する際に再起動 もしくは フェイルオーバーでの反映が必要
→ 次項に記載がありますが、前提事項としてbinglog_formatの設定が必要になります - 切り替え時に読み取り専用に切り替わる為、更新処理がエラーとなる
どちらもダウンタイムは短い時間ではありますが、更新エラーなどが許容できない場合は、アプリケーション側でメンテナンス停止やリカバリ処理の検討が必要になるでしょう。
前提事項、トラブルシューティング事項
冒頭に記載した通り、エラーでトラブるケースが多いです。
まずは以下の参考サイトで前提条件とトラブルシューティング事例を確認して準備しておくことをお勧めします。
イレギュラーケース
さらに、イレギュラーではありますが、以下のようなケースもありました。
- Blue/Greenのプロビジョニング後、フェイルオーバーさせてライターインスタンスとリーダーインスタンスが入れ替わった状態でBlue/Greenスイッチオーバ―を実施するとエラーになる
→スイッチオーバ―マッピングでライターとリーダーの組み合わせが決まっているので、それと異なるとエラーになる模様
→再度フェイルオーバーして元に戻せばスイッチオーバ―可能 - 事前にDBクローンでテスト用環境を作ってBlue/Greenできることを検証して、その後元のDBでBlue/Greenを実施しようとしたらGreen環境のプロビジョニングが進まなかった
→Green環境のAuroraバージョンを変えてみたり、カスタムパラメータグループをデフォルトのパラメータグループにしてみたが、解消せず
→AWSサポートに問い合わせた結果、利用しているDBバージョンでバグがあり、バグ修正したとの連絡を受け、ようやくBlue/Green成功（v2.10.3→v3.03.0）
わかったこと
- Greenプロビジョニングが進まない場合、エラーがでないことがあるのでエラーと判断することが難しい
→正常なら1分前後でGreenのインスタンスが表示されるので、いつまでもGreenの表示が出てこなければプロビジョニングに異常が発生した可能性が高い - AWSのバグの可能性もあるのでAWSサポート契約があれば問い合わせてみるのもよい
- プロビジョニング時のエラーログは内部ログなのでAWSサポートしか調査できないログとのこと
（もう少しエラーハンドリングは充実してほしいところですね）
Blue/Green Deployment実行方法
前提
検証用のDBは今回以下の設定で作成しました。
インスタンスタイプ：db.t3.medium
マルチAZ：有効（レプリカを作成）
Default VPC
カスタムパラメータグループ（binlog_format=MIXED設定済み）
暗号化：無効
ブルー/グリーンデプロイメントの作成
Blue：Aurora MySQL v2.11.1
Green：Aurora MySQL v3.03.0
クラスタを選択し、「ブルー/グリーンデプロイメントの作成・新規」を実行
実行すると、1分経たないうちにgreen環境が表示されます（以前はこれが表示されず苦労した）
Green環境のプロビジョニング完了（今回は約46分の処理時間でした）
ダウンタイム計測準備
スイッチオーバ―（切り替え）時にどの程度DBのダウンタイムが発生するか、以下の簡易的なソースで検証してみました（Cloud9にて実行）
Aurora MySQLにはtest_db.test_tableを作成済みです。
selectとinsertを1秒間隔で発行し、エラーの発生状況を観察します。
TestDB.sh
#!/bin/sh
HOST="**your.rds.endpoint.rds.amazonaws.com**"
DB_USER="**your username**"
DB_PASS="**your password**"
CMD_MYSQL="mysql -u $DB_USER -p$DB_PASS -h $HOST test_db"
SQL_CNT="select count(1) from test_table;"
SQL_INS="insert into test_table value ('test', 'test');"
while true
do
RET_INT=`echo $SQL_INS | $CMD_MYSQL`
RET_CNT=`echo $SQL_CNT | $CMD_MYSQL`
echo [`date`] $RET_INT
echo [`date`] $RET_CNT
sleep 1
done
スイッチオーバ―（切り替え）
ブルー/グリーンデプロイのDB識別子を選択し、切り替えを実行
切り替え完了。ログ上では2分強で切り替えが完了していたようです。
DB処理エラーの確認
countが90で止まっている時間帯があります（11:25:04～11:27:17）
この時間帯はinsertに失敗していたと思われます（2分程度）
またselectはログ上からはエラーは読み取れませんでした。
11:25:06のselect countの後、insert処理のログが出力されるまで2分程度かかっているので、insertのDB接続で接続待ちになっていたものと推測されます。
おわりに
今回はBlue/Green Deploymentの有効性を確認することができました。
DBのダウンタイムも都合2回、数分以内なので、よりバージョンアップがやりやすくなったと思います！
一方でエラーが明示的に表示されない不具合事象などにも出会ったので、その際のトラブルシューティングが困難になるケースもあります。
実案件ではAWSサポート契約をしていると思うので、是非活用してみて下さい。