みなさん、こんにちは。サニービュー事業部の小寺です。
当社は今日から１月3日まで冬季休暇です。
re:Inventでも衝撃の発表だったRDSのデータが失われない「Blue/Green Deployments」についてお伝えします。
そもそもBlue/Green デプロイとは
Blue/Greenデプロイってお聞きになったことはありますか。
青／緑の概念で「古いデプロイ・新しいデプロイが同時に混在する環境を構築した後、ロードバランサー等によるルーティングの制御によってトラフィックを切り替え、ダウンタイム無しで環境を切り替える」ことをBlue-Green デプロイと呼びます。
切り替え後もブルー環境は待機状態でしばらく残しておくことができ、グリーン環境で何か致命的な問題が生じた場合にはすぐに元の状態に切り戻し（ロールバック）することができます。
新環境での運用に問題がないことが確認できたら、旧環境は破棄して次のリリースに向けた開発やテスト用の環境として用いることができます。
AWSの他のサービスでも同じBlue/Greenデプロイができます。過去記事ではECSのデプロイ戦略としてご紹介しています→こちら。
本アップデートの内容
本アップデートでマネジメントコンソール上から数ステップでBlue/Greenデプロイの構成が実現できるようになっています。
今回はなんといっても、データベースのBlue/Greenデプロイをマネージドで提供しています。Blue/Greenデプロイを有効化すると本番環境と同期するミラーリング環境が起動されます。ミラーリングなので、データの損失はありません。
利用用途としては、OSのメンテナンス、パッチ適用、スキーマやパラメータの変更時が想定されます。
古いデプロイ環境から新しいデプロイ環境に切り替えて良いという判断ができたら、切り替えの実施ができます。
ステージングから新しい環境に昇格するのにかかる時間はわずか1分です。
切り替え時は古いデプロイ環境も新しいデプロイ環境も書き込みがブロックされ、データ損失が発生しないことが保証されています。古い環境から新しい環境にトラフィックが流れるようになります。
ただ、今日コラムを書く際に調べてみると、Amazon Auroraで以前も少し複雑な方法でしたが、同じBlue/Greenデプロイができたようです。
また、ご利用になる際にの前提条件についてです。
・Blue/Greenデプロイでは現時点でサポートがされていない機能
・Amazon RDSプロキシ
・カスケードリードレプリカ
・クロスリージョンリードレプリカ
・Multi-AZ DB Cluster
・AWS CloudFormation
・Blue/Greenデプロイ時の制限事項
・暗号化されていないDBインスタンスから暗号化されたDBインスタンスへの変更不可
・暗号化されたDBインスタンスから暗号化されていないDBインスタンスへの変更不可
・Blue環境のDBインスタンスより低いエンジンバージョンへの変更不可
・Blue環境とGreen環境のリソースは同じAWSアカウントである必要あり
• Amazon Aurora(MySQL互換)バージョン5.6以上、AmazonRDS for MySQL 5.7以上、Amazon RDS for MariaDB 10.2以上で利用可能
Amazon Auroraで試してみた
(1)検証用にAurora MySQLのクラスターをあらかじめ作っておきます。
(2)「アクション」 ドロップダウンメニューの Create Blue/Green Deployment をクリックします。
このときなぜか「ブルー/グリーンデプロイの作成-ベータ」と表示されました・・。GAされているのにベータと表示されます。
(3)エンジンバージョン、DB クラスターパラメータグループ、グリーンデータベースの DB パラメータグループなど、変更するデータベースの設定を行います。ここでは、Blue-Green環境識別子を「staging-environment-db」として、aurora-mysql8.0を選びました。
制限事項に記載した通り、エンジンバージョンで今のDBより下位バージョンを選ぶことはできません。
(3)「ステージング環境の作成」をクリックします。
(4)「Blue Green Deployments requires cluster parameter group has binlog enabled.」エラーになってしまいました。
この原因はDB クラスターパラメータグループの binlog_format パラメータの値を OFF から MIXED に変更してバイナリロギングを有効にする必要があったため、とのことで、設定変更して、反映のためにDB再起動後、再チャレンジしてうまくいきました。
(5)グリーン環境の作成が始まりました。
作成が完了すると先ほどの画面に表示された通り、グリーン環境分のコストも発生することになります。
(6)グリーン環境データベースを本番環境に切り替える準備ができました！
と、思いきやステータスが「Invalid configuration」になっています。気を取り直して、AuroraはV3でも別インスタンスタイプで再度Blue/Greenデプロイを行いました。
(7)グリーン環境データベースの設定をチェックして、スイッチオーバーの準備を行います。「切り替え」を選びます。
また、タイムアウト設定を設定して、スイッチオーバーの最大制限時間を決定することもできます。Blue/Greenデプロイのスイッチオーバーガードレールで、指定した時間を超過する可能性が検出されると、そのスイッチオーバーはキャンセルされる仕様です。なので、環境に対して変更を加えることはありません。
(8)切り替え中の表示です。
(9)切り替えが完了するとデータベースの名前が「old」とつきます。分かりやすくていいですね。
(10)切り替え完了後、Blue/Green デプロイが古い本番環境（ブルー環境）を自動削除することはありません。必要に応じて、古い本番環境（ブルー環境）にアクセスし、追加の検証やパフォーマンス等の確認を行うことができます。
なお、古い本番環境が不要になった場合は、ユーザーの責任で削除することになっています。古い本番インスタンスには、削除されるまで課金が発生します。
はまりポイント
・クラスターパラメータグループの binlog_format パラメータの値を OFF から MIXEDに変更する必要あり。MIXEED以外の他の値では同じエラーになりました。
・db.t3.smallを使ったAuroraクラスターでV3へのバージョンアップを含めた環境構築はできない。個人的な環境で、お安くV3にしてみたいなーと思っていたのですが、まんまとエラーになりました。
対象リージョン
中国を除くすべてのAWS商用リージョンとAWS GovCloud リージョンにおいて、MySQL 互換 5.6 以降の Amazon Aurora、 Amazon RDS for MySQL メジャーバージョン 5.6 以降、Amazon RDS for MariaDB 10.2 以降で、発表時点からGAになっています。
