💽

Amazon RDS Blue/Green Deployments を色々と検証してみた!

2023/01/25に公開

こんにちは! スターフェスティバルでインフラエンジニアをやっております @koonagiです。

早いことにもう1月も終わりますね。
1月のうちにブログを書こうと思っていたら、あっという間に終盤になってしまっていて急いでこの記事を書いていますw

さて、先月のre:Inventでリリースされた Amazon RDS Blue/Green Deployments について、最近検証したのでそのことについて書いていこうと思います。

Aurora v1(MySQL 5.6)が2月末でサポート終了となるため、Aurora v2(MySQL 5.7)へのバージョンアップの際にAmazon RDS Blue/Green Deploymentsを活用しようと考えており、事前準備として検証を進めました。

Amazon RDS Blue/Green Deploymentsとは

公式からの引用です。

ブルー/グリーンデプロイでは、本番環境をデプロイおよびテストし、フルマネージド型のステージング環境を作成しながら、現在の本番データベースを安全に保つことができます。ワンクリックすればほんの 1 分ほどで、ステージング環境を新たな本番システムに昇格できます。その際、アプリケーションへの変更やデータの損失は発生しません。 引用元

制限事項にも記載がありますが、クロスリージョンレプリカやRDSプロキシを利用している環境等では利用できないので注意が必要です。

切り替えまでのステップ

概ね3ステップでBlue/Green環境の切り替えをすることができます。簡単ですね!
マネージメントコンソールからポチポチでいけます。

STEP1: (有効化されていない場合は)バイナリログの有効化
STEP2: Green環境の作成
STEP3: 切り替えの実行

Amazon RDS Blue/Green Deploymentsは、バイナリログの有効化が必須なので利用を検討している方は注意が必要です。

検証したあれこれ

Amazon RDS Blue/Green Deployments はまだリリースされて一ヶ月の機能で情報が少ないため色々検証してみました。その結果を記載していきます。

Q1.バイナリログの有効化に停止は発生するか

結論: バイナリログ有効化時に再起動が発生するため、停止が発生する

切り替えまでのステップでも記載しましたが、Aurora Blue/Green Deploymentsを利用するには、バイナリログの有効化が必要となります。
クラスターパラメーターグループのbinlog_formatのパラメーターをMIXEDに変更する必要があり、binlog_formatは適用タイプがstaticのためAuroraの再起動が必要になります。そのため、再起動の時間だけ停止します。

Q2.Green環境作成時にDBの停止は発生するか

検証結果: ライター(読み書き)、リーダー(読み込み)どちらも停止もなし

CPU利用率については、ライターのCPU使用率5%ほど1分間増えただけで、後は平常と変わらず。
リーダーについてはCPU使用率に変化はなし。

Q3.Green環境の作成時間はどれくらいか

検証結果: 下記環境のAuroraクラスターでは、Green環境の作成時間は約1時間

* 構成
	* ライター: 1台
	* リーダー: 1台
* ディスク使用量 : 10GB
* Blue環境バージョン  : Mysql 5.6
* Green環境バージョン : Mysql 5.7

Green環境のバージョンがBlue環境よりも高い場合、複製後にバージョンアップが走る仕様のため結構時間がかかりました。同一のバージョンの場合はもう少し早いのではと思っています。

Q4.切り替え時の停止はどれくらいか

検証結果: 書き込み約2分、読み込み数秒の停止

1秒に1回ライターへの読み書き、リーダーへの読み込みをするスクリプトを使って切り替え時の停止時間を計測してみました。

書き込みについては、公式では1分程度の停止と記載がありましたが、私達の環境ではが2分停止しました。挙動としては、切り替え時にライターがRead onlyに切り替わり書き込みエラーとなります。2分ほど待つと書き込みができるようになるという感じでした。
読み込みについては、ライター/リーダーどちらの読み込みも1度エラーとなり、その後は正常に読み込みができたので、数秒の停止かなという感覚です。読み込みは切り替えによる影響はほぼないですね。

Q5.切り替え後に切り戻しはできるか

結論: できない

切り替え後の旧Blue環境は、Read onlyのクラスターとして切り離されます。旧Green環境からのレプリケーションも切断されているため、切り戻しをする場合はスナップショットなどから復元する必要があります。(切り戻しできるようにしてほしいいい

Q6.旧Blueの環境から、Green環境を再度つくることはできるか

結論: できない

上の検証結果にも書いてますが切り替え後の旧Blue環境は、Read onlyのクラスターとして切り離されるため? Green環境を作ることはできませんでした。マネージメントコンソール上では、ブルー/グリーン デプロイメントの作成の項目がグレーアウトされます。

Q7.Blue環境への書き込みはどれくらいの時間でGreen環境に反映されるか

検証結果: ほぼリアルタイム

Blue環境でDBやテーブルの作成、更新を行いどれくらいの時間でGreenに反映されるかチェックしたのですが、ほぼリアルタイムで反映されました。Blueに書き込んで、Greenを見に行ったら反映済みの状態というスピード感です。

つまったところ

いくつか詰まった部分があったので、その部分も記載していきます。

Green環境が作成できない

原因: binlog_formatがROWになっていた

Green環境を作成しようとしたところ、以下のようなエラーとなり作成にできなかったのですが、binlog_formatが ROW になっているのが原因でした。エラーメッセージわかりずらい。

Blue環境への書き込みがGreenに反映されない

原因: 不明
Blue環境への書き込みテストをした際に、いつまでもGreenに反映されない場合がありました。特にログなどにエラーなどは吐かれておらず、色々調査してもわからなかったため、Green環境を再作成したらうまくいきました。

Green環境の作成が終わらない

原因: 不明
Green環境を作成して数時間作成が終わらないということがありました。こちらもGreen環境を再作成したら、うまくいきました。

最後に

Amazon RDS Blue/Green Deployments はβ版なのでまだ予期せぬエラーがあったりしますね。ただ、これまでRDSをほぼ無停止で切り替えようとしたら、DMSの設定やDNSの切り替え等が必要でしたが、それらをAWS側ですべてやってくれるのでオペレーションがとても楽になりました...!
すごい良い機能なので皆様も是非使ってみてください😺

スタフェステックブログ

Discussion

ログインするとコメントできます