「Blue/Green Deployments on AWS」を読んで、Blue/Greenデプロイメントのやり方を学んだ

概要

ブルーグリーンデプロイメントのAWSホワイトペーパー https://d1.awsstatic.com/whitepapers/AWS_Blue_Green_Deployments.pdf

AWSのサービスやツールを使った Blue/Green デプロイメントを実装する方法が学べます。

以下、読書メモです。

Blue/green deployments can mitigate common risks associated with deploying software, such as downtime and rollback capability.

(Blue/green デプロイメントは、ダウンタイムやロールバックのようなリスクを和らげる。)

makitani.net

カナリアリリースとは、プロダクトやサービスの新機能を一部のユーザーのみに対して利用できるようにすること。

(中略)

炭鉱でのガス漏れ事故を防ぐために、無臭ガスに敏感な鳥(カナリア)を鳥かごに入れて炭鉱に持ち込んだ実験が由来。

blue/gree デプロイメントを計画する時、環境の境界 を考える必要がある。すなわち、where have things changed and what needs to be deployed to make those changes live

影響がある要因は以下のようなもの。

• Application architecture
• Organizational
• Risk and complexity
• People
• Process
• Cost

Blue/Green デプロイメントを可能にするAWSのツールとサービス

• Amazon Route 53
  • DNSレコードとTTLを調整して、トラフィックの向き先を変える
• Elastic Load Balancing
  • Auto Scaling などと組み合わせて使う
• Auto Scaling
  • Auto Scaling group内でEC2インスタンスを立ち上げるためのテンプレートはlaunch configurations と呼ばれる
  • Auto Scaling グループからの一時的なインスタンスの削除 - Amazon EC2 Auto Scaling (日本語)
• AWS Elastic Beanstalk
  • Auto Scaling と Elastic Load Balancing をサポートしている
• AWS OpsWorks
  • スタック全体をクローンすることにより、blue/green環境を構築する
• AWS CloudFormation
  • Route 53 DNS か Elastic Load Balancing などで blue/green 環境をプロビジョンする
• Amazon CloudWatch
  • blue/green デプロイメントではヘルスチェックを行う

Amazon Route 53 でDNSルーティングを更新する方法

この方法が適用できる環境は

• public か Elastic な IPアドレスがある単一のインスタンス
• Elastic Load Balance または サードパーティのロードバランサーの後ろにあるインスタンスグループ
• フロントエンドとして Elastic Load Balancing と Auto Scaling が適用されたインスタンス
• Elastic Load Balancing によってロードバランシングされているAmazon EC2 Container Service(Amazon ECS)クラスタ上で動いているサービス
• Elastic Beanstalk環境のWeb層
• IP または DNS エンドポイントが公開されているその他の設定

Amazon Route 53 の設定で重み付き分布設定を調整することに依って、徐々にgreen環境にトラフィックを流すことができる(カナリアリリース)

DNS TTLはクライアントがクエリ結果のキャッシュをどれくらいの期間保持するかを決定している。

Elastic Load Balancer の裏側で Auto Scaling Group を入れ替える方法

• Elastic Load Balancing の詳細 - Elastic Load Balancing
• Auto Scaling グループからの一時的なインスタンスの削除 - Amazon EC2 Auto Scaling (日本語)

トラフィックマネージメントについては、DNSの方法とは違う粒度になるが、Auto Scaling groups の設定でコントロールすることができる。

DNSの複雑さはなくなるので、トラフィックの移動自体はより得策。さらに、ロードバランサーがすでに温まっている状態なので、プロダクションのフローに関してサポートできていると自信が持てる。

Auto Scaling Group Launch Configurations を更新する方法

launch configuration には以下のような情報が含まれている。

• AMI ID
• インスタンスタイプ
• キーペア
• 一つ以上のセキュリティグループ
• ブロックデバイスマッピング

Auto Scaling group には、唯一つの launch configuration を関連付けることができ、編集することができない。launch configuration を変更するときは、新しいものと入れ替える必要がある。

新しい launch configuration が配置された後、古いインスタンスに影響を与えることなく、新しいインスタンスが立ち上がる。

Auto Scaling はデフォルトのtermination policyに従って、古い launch configuration で立ち上がったインスタンスをグループから排除する。

しかしながら、知っておくべきことは、もしAZがアンバランスな場合、バランスを取るために新しく立ち上がったインスタンスを削除しうる。

1) Auto Scaling group と Elastic Load Balancing でblue環境を始める。 2) 新しいバージョンをデプロイするために、新しいlaunch configurationでAuto Scaling groupを更新する。ここで、もとのサイズの2倍のスケールとなる 3) Auto Scaling group を元のサイズに縮小させる。デフォルトでは古いlaunch configuration のインスタンスが削除される。すばやくロールバックができるようにスタンバイステートをインスタンスに持たせることもできる(https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-enter-exit-standby.html) 4) ロールバックをするためには、古いlaunch configurationに更新する。1 〜 3 のステップとは逆のことが起きる。

Elastic Beanstalk Application の環境で入れ替える方法

Beanstalk は、in-place なデプロイも設定できる。 Blue/Green なデプロイも設定できる。

docs.aws.amazon.com

1) Elastic Beanstalk のコンソールで、 Actions の Swap Environment URL を選ぶ。 2) Elastic Beanstalk はRoute 53でURLをスイッチさせる 3) ロールバックの場合は再び Swap Environment URL を実行すると良い

AWS OpsWorks のスタックをクローンし、DNSを更新する方法

データ同期とスキーマ変更のベストプラクティス

Blue/Green デプロイメントが推奨できない場合

• スキーマの変更が複雑な場合
• "deployment aware" なアプリケーションの場合
• 既製のアプリのupdate/upgradeプロセスがblue/greenデプロイメントにフレンドリーでない場合

Appendix

各手法のリスクの表が載っている。