AWSのホワイトペーパーから学ぶブルーグリーンデプロイメント

PS課佐竹です。

AWSには様々なブルー/グリーン デプロイメントを行う手法があります。その様々なパターンをホワイトペーパーと共にご紹介したいと思います。

ブルーグリーンデプロイメントとは？

Blue/Green Deployment とは、異なるバージョンのアプリケーションを実行する環境をそれぞれ1つずつ、つまり計2つ作成し、それらの環境間でトラフィックを移動（ブルー⇒グリーンへ移動）させることによって、アプリケーションの新バージョンをリリースするために利用される技術です。

上の図は典型的なブルーグリーンデプロイメントを表しています。本構成図の内容ですが、上から順に「ELB(Elastic Load Balancing)」「EC2 Instance」「RDS(Relational Database Service)」を示しています。

ブルーグリーンデプロイメントのAWSホワイトペーパー

AWSはブルーグリーンデプロイメントのホワイトペーパーを公開しています。

https://d1.awsstatic.com/whitepapers/AWS_Blue_Green_Deployments.pdf

本ホワイトペーパーは2016年8月に公開された少し古い資料ではありますが、とても素晴らしい資料なのでいつか和訳されるだろうとずっと待っているものの、全くもって和訳されないため、本ブログで日本語にて掘り下げたいと思います。
また、このホワイトペーパーは「AWS 認定 DevOps エンジニア – プロフェッショナル」資格試験の勉強にもとても良い資料ですので、本試験の対策/勉強をされている方にも是非お勧めしたいと思います。

以下、本ブログ記事の画像は基本的に上記ホワイトペーパーよりキャプチャし、その構成図ごとに説明をさせて頂きます。

Classic DNS pattern

最初に構成図2として紹介されるのは「クラシックDNSパターン」と名付けられたデプロイメント手法です。AWSのDNSウェブサービスであるRoute 53を利用し、接続先のELBをブルー⇒グリーンへ切り替えることで、トラフィックをグリーンに移動させています。ホワイトペーパーにある構成図ではELBを間に挟む形になっていますが、以下のようにElastic IPを指定して切り替えることもできます。

もちろんELBを間に挟む手法の方がSSLのTerminationやEC2をPublicに晒さない等々の点で優れていることには変わりありませんが、ブルーグリーンデプロイメントが実現可能ということであわせて紹介させて頂きました。

Classic DNS-weighted distribution

構成図3として紹介されるのは「クラシックDNSパターン – 加重配分」です。Route 53には加重レコード（加重エイリアスレコード）を設定可能ですので、重みによって割り振られる先のELBの割合を変えるという手法となります。先に紹介したパターンでは「0か1か」の世界だったのに対し、この手法を使えば「全体の20%のアクセスだけを新バージョンにする」ことが可能です。

Swap Auto Scaling group pattern

図4として示されているのは「オートスケーリンググループ入れ替えパターン」です。Auto ScalingはEC2 Instanceの数を負荷に合わせて自動的に増減させることが可能なスケーリングの機能です。またAuto Scalingは、「Auto Scaling Group(ASG)」の単位で設定されます。このASGごとにELBを複数アタッチすることが可能となっており、図4の右側の図では、1つのELBに2つのASGが紐づいている状態となっています。加えて、ELBの負荷分散は存在する6台に（基本的に）均一に分配されるため、右の図では全体の2/3がブルー環境に、全体の1/3がグリーン環境に分配されることになります。完全にグリーン環境に切り替えたい場合は、ブルー環境のASG設定からELBへの紐付け設定を外すことになります。

Blue Auto Scaling group nodes in standby and decommission

この図5は、図4の補足的な構成となります。「ブルー環境のオートスケーリンググループをスタンバイそして閉鎖状態にする」と訳しますと、わかりやすいかもしれません。まず、Auto Scaling Group(ASG)の中にあるEC2 Instanceは「スタンバイ状態」とすることが可能です。スタンバイ状態にしたInstanceは、ASGから一時的に外された状態になるため、その間にInstanceの中に入ってトラブルシューティングなどを行うことができるのですが、ブルーグリーンデプロイメントではブルー環境とグリーン環境の量をバランスするために利用します。図5の左側の図では、ブルー環境の4台のうち2台がスタンバイ状態とされています。図4の右側ではブルー:グリーンが4:2であったのですが、これで2:2になりました。最後にブルーのASGの値を0にすれば完全にグリーン環境のみとなります。このように段階的に切り替えるメリットは「ロールバックのしやすさ」にあります。スタンバイ状態のInstanceはこの場合「正常」であるものの「トラフィックがこないだけ」ですので、もしすぐに元に戻したいとなればスタンバイ状態を解除すれば良いだけとなります。

Launch configuration update pattern

構成図6は「起動設定更新パターン」です。「Launch configuration」とは、Auto Scaling Group(ASG)がEC2 InstanceをLaunch(起動)するために使用する設定です。つまり「どのAMI(Amazon Machine Image)を元にしてEC2 InstanceをLaunchするのか」が書かれているテンプレートです。この構成ではまず図6の通り、新しいグリーン環境用のLaunch Configuration(v2.0)を作成します。そして次にASGの設定を、グリーン環境用のLaunch Configurationに差し替えます。既に存在しているEC2 Instanceはブルー環境用のLaunch ConfigurationでLaunchされているため影響を受けません。なお1つのASGには1つのLaunch Configurationのみアタッチ可能です。続きます。

Scale up green launch configuration

図7は図6の後続処理を説明しています。図6の状態で、Auto Scaling Groupの設定を変更し、2倍の数に変更します。この場合であればEC2 Instanceが常に3台並ぶ設定から、6台並ぶ設定に変更を行います。先の設定変更でLaunch Configurationはグリーン環境用のテンプレートに変更されていますので、新しく構築される3台はグリーン環境用のInstanceになります。

Scale down blue launch configuration

図8はさらに図7の後続処理を説明しています。最後にAuto Scaling Group(ASG)の設定を変更してブルー環境のEC2 Instanceを全て削除します。この時、構成図5で説明した「スタンバイ状態」を経ることで、ロールバックを容易にすることも可能です。設定の変更ですが、先と逆の変更で1/2の数に変更します。この図の場合は、常に6台並ぶ設定から、3台並ぶ設定に変更を行っています。なおデフォルトでASGは「古いLaunch ConfigurationでLaunchされたInstanceから順に削除される」設定となっていますので、数を減らせば自動的にブルー環境のInstanceが削除されることになります。

Prepare green Elastic Beanstalk environment

構成図9は一般的なElastic Beanstalk環境を示しているため飛ばして、構成図10になります。AWS Elastic Beanstalkはアプリケーションをデプロイする環境のセットをAWSが作ってくれるサービスで、図10にあるように「ELB＋Auto Scaling＋EC2」のセットを一気に作成してくれます。今までの構成と異なるのはElastic Beanstalkによって「ELBとAuto Scaling Groupが合体」していることです。そのため、ブルーグリーンデプロイメントにおいてもElastic Beanstalkの単位で行うため、「ELBとAuto Scaling Groupが合体」している環境が2つ用意されることになります。フルセットで複製するため、これまでの中でコストは最も高いものとなります。図10の状態では、Route 53はブルー環境を向いています。

Decommission blue Elastic Beanstalk environment

図11では、ブルー環境を廃棄してグリーン環境に切り替えを行っています。図2で紹介したRoute 53で宛先を切り替えている動きになるので、基本的に図2とやっていることは変わりませんが、以下2点補足致します。1つは、この切り替えはElastic Beanstalkの機能で可能ということです。詳しくは公式ドキュメントに譲りますが、Elastic Beanstalkの持っているCNAMEを切り替える機能があり、これを利用することでブルー⇒グリーンの切り替えを行います。たとえこの切り替えで失敗したとしても、ロールバックを行うのが容易である点がメリットとなります。もう1つは、Elastic Beanstalkはバージョン管理の機能を保持しています。これにより、複数のバージョン(具体的には20以上を超えるバージョン)を管理することができるため、バージョン管理の恩恵を受けられるのもElastic Beanstalkを使うメリットになります。

Clone stack to create green environment

図13は図10と対比的に、AWS OpsWorksを利用した構成となります。OpsWorksを利用することで、ChefもしくはPuppetを利用したAWS環境の構成管理が可能となります。Elastic Beanstalkと同様、完全に環境を複製することになりますので、図の通りブルー環境とグリーン環境ではバージョンは異なるものの同じものが隣に並びます。よって、コストは割高です。Elastic Beanstalkと異なるのはバージョン管理の点で、OpsWorksでは直近の5つのデプロイを保持しているため、最大4つ前までバージョンをロールバックすることが可能です。またOpsWorksを利用する場合はRoute 53のレコードを直接修正することになります。ホワイトペーパーには「重み付け」を利用することが記載されていますが、そちらについては図3で説明した通りです。図14はブルー環境を廃棄する図となりますので割愛します。

まとめ

いかがだったでしょうか。ホワイトペーパーでは色々な構成が出てきたと思いますので最後に整理してみましょう。

1. ブルー⇒グリーンの切り替えの基本はDNS(Route 53)で行うものになる
2. Elastic BeanstalkやOpsWorksを利用する場合も基本的にはDNSでの切り替えに倣う
3. Route 53を利用する場合、ブルー⇒グリーンの切り替えは向き先のELBの変更とイコールになる
4. Route 53では重み付けが利用できるため、それを使ってブルー/グリーンのバランスを変更しつつロールバックを行える
5. Auto Scalingを利用することで、ELB配下の環境を入れ替えることが可能でありこの場合Route 53に手を加えない
6. Auto Scalingを利用する場合は、Auto Scaling Group単位で変更するか、Auto Scaling Groupが持つLaunch Configurationで変更するかの2パターンに分かれる
7. Auto Scalingでは「スタンバイ状態」や「起動する数の設定」を利用してブルー/グリーンのInstance数を調整することでロールバックを行える
8. Elastic BeanstalkやOpsWorksを利用する場合、それぞれのサービスがバージョン管理の機能を持っているためその恩恵に与れるが、これらはどれも環境を丸ごと複製するためにコストが高くなる

2016年8月の資料のため、ECS(Docker)が登場しない点は少し惜しいところなのですが、AWSにおけるブルーグリーンデプロイメントの基本が理解できるとても素晴らしい資料ですので、私が紹介した以外の箇所も是非読みこんで頂ければと思います。特にDB(スキーマ)の更新をどうするかについても記載があるので、確認してみてください。

余談ですが、私は過去バックオフィスシステム（勘定系）の保守をしていていました。バージョンアップ時はデータベースにかなりの更新をかけるため、WEB/APは完全停止で行っていました。つまり作業は真夜中になるのですが、終わってびっくり、夜中の3:00(AM)にアプリケーションが起動しなくなりまして、3:00(AM)という時間に会社の先輩に電話をかけたりしていました。そんな私みたいな人が今後1人でも減ったらいいな、なんて思いながらこの記事を終えたいと思います。