AWS Elastic Beanstalkで使えるデプロイポリシーを理解する

こんにちは、クラスメソッドのジョン・ヒョンジェです。

今回はAWS Elastic Beanstalkでアプリケーションの新しいバージョンをデプロイするときに使えるデプロイポリシーについて話したいと思います。

デプロイポリシー

AWS Elastic Beanstalkで使えるデプロイポリシーには大きく4つのポリシーがあります。

• All at Once
• Rolling
• Rolling with additional batch
• Immutable

All at Once

All at Onceは同時に全ての既存インスタンスにデプロイをするポリシーです。

バージョン1のアプリケーションを4つのインスタンスで起動していて、このアプリケーションをバージョン2にアップデートすると想定します。

All at Onceポリシーでバージョン2のアプリケーションをデプロイすると、このように全てのインスタンスが一気にデプロイを実行します。そのため、デプロイが実行される間はそれぞれのインスタンスはサービス停止状態になります。

デプロイが終わったら、全てのインスタンスでバージョン2のアプリケーションが起動するようになります。

All at Onceポリシーは短期間のダウンタイムが存在しますが、デプロイポリシーの中で一番簡単で、一番早いポリシーです。

Rolling

Rollingはバッチに新しいバージョンをデプロイするポリシーです。

Rollingポリシーでデプロイするときはバッチサイズを設定する必要があります。バッチサイズを50%にして、バージョン2のアプリケーションをデプロイすると想定します。

バッチサイズを50%に設定しましたので、4つのインスタンスの中で2つのインスタンスにまずデプロイを実行します。この間、デプロイを実行しているバッチのインスタンスはサービス停止状態になりますので、バッチサイズ分キャパシティが減ります。

2つのインスタンスでデプロイが終わったら、2つのインスタンスはバージョン2のアプリケーションを、2つのインスタンスはバージョン1のアプリケーションを起動している状態になります。古いバージョンと新しいバージョンが混在していますので、ユーザーはそれぞれ違うバージョンにアクセスする可能性があります。

その後、残りの2つのインスタンスでもデプロイを実行します。この間も同じくデプロイを実行しているインスタンスはサービス停止状態になり、キャパシティが50%に減ります。

デプロイが終わったら、全てのインスタンスでバージョン2のアプリケーションが起動するようになります。

RollingポリシーはAll at Onceポリシーと比べると、キャパシティが減る時間はありますが、完全なダウンタイムはないのがメリットです。しかし、古いバージョンと新しいバージョンが混在している時間があるのは問題になる恐れがあります。

Rolling with additional batch

Rolling with additional batchはRollingと同じようにバッチに新しいバージョンをデプロイするポリシーです。しかし、デプロイ中キャパシティが100%を維持するように最初に新しいインスタンスをまず追加してデプロイを進みます。

Rollingポリシーと同じようにバッチサイズを設定します。50%に設定したと想定します。

Rolling with additional batchポリシーではこのようにバッチサイズ分の新しいインスタンスを追加してデプロイを実行します。Rollingでは既存のインスタンスでデプロイを実行しましたのでキャパシティがバッチサイズ分減りますが、Rolling with additional batchポリシーでは最初に新しいインスタンスを追加するのでキャパシティを100%に維持することができます。

新しいバッチのインスタンスでのデプロイが終わったら、ロードバランサーにアタッチします。この間もRollingと同じく古いバージョンと新しいバージョンが混在する時間が存在します。

その後、次のバッチサイズ分のインスタンスをロードバランサーからデタッチしてデプロイを実行します。この時も4つのインスタンスが起動されていてキャパシティが100%の状態です。

デプロイが終わって、4つのインスタンスでバージョン2のアプリケーションを起動しています。

最後にバージョン1のアプリケーションを起動している2つのインスタンスを終了します。

Rolling with additional batchはRollingポリシーと違って、デプロイ中にキャパシティが減らないメリットがあります。そのため本番でよく選ばれるポリシーです。しかし、古いバージョンと新しいバージョンが混在する時間があるという問題は残っています。

Immutable

Immutableは既存のインスタンスは変更しないでデプロイをするポリシーです。

今までと同じく4つのインスタンスで起動しているアプリケーションをバージョン1からバージョン2にアップデートすると想定します。

Immutableポリシーではこのように最初に新しいAuto Scaling Groupを作成します。そして、1つのインスタンスを起動してデプロイを実行します。

デプロイが終わったら、ロードバランサーにアタッチして本番でもうまく動くのか確認をします。

うまく動くのを確認した後、新しいAuto Scaling Groupに3つのインスタンスを起動し、デプロイを実行します。

デプロイが終わったらロードバランサーにアタッチします。バージョン1のアプリケーションを起動しているインスタンスグループとバージョン2のアプリケーションを起動しているインスタンスグループがある状態になります。

最後にバージョン1のアプリケーションを起動しているインスタンスグループを終了します。

Immutableポリシーを使うと既存インスタンスの変更なしで新しいバージョンをデプロイすることができます。しかし、Immutableポリシーでも古いバージョンと新しいバージョンが混在している時間は存在します。

環境によって選べるポリシー

環境	選べるポリシー
単一インスタンス	All at Once
	Immutable
Load Balancer, Auto Scaling Group	All at Once
	Rolling
	Rolling with additional batch
	Immutable

Blue/Green(補足)

今までAWS Elastic Beanstalkでよく使われるデプロイポリシーについて話しましたが、Rollingポリシー、Rolling with additional batchポリシー、Immutableポリシーには一つの共通的な問題点がありました。

古いバージョンと新しいバージョンが混在している時間が存在する

もし、デプロイをするときに違うバージョンが混在する時間をなくしたい場合はBlue/Greenデプロイを行う方法があります。

Blue/Greenデプロイ

今までと同じ環境で起動しているアプリケーションをBlue/Greenデプロイでバージョンアップしてみます。

まず、最初に今構築されている環境からcloneを作成します。この2つの環境で違う点はDNS名だけです。

作成したcloneでデプロイを実行します。この時、cloneで起動しているアプリケーションはダウンタイムが発生しても大丈夫なので、All at Onceポリシーでのデプロイを行っても問題ありません。

デプロイが終わってアプリケーションがうまく動くのが確認できたら、既存環境のDNSとcloneのDNSを切り替えます。そうすると、ユーザーは既存のURLで新しいアプリケーションを使うことができます。このように、Blue/Greenデプロイでは古いバージョンと新しいバージョンが混在している時間が存在しません。

Blue/GreenデプロイとImmutableポリシーの違い

Blue/GreenデプロイがImmutableポリシーととても似ていると思われるかもしれませんので、その違いについて少し説明します。

まず、Blue/Greenデプロイでは既存環境からcloneを作成して新しい環境を作ることでデプロイを行います。それで、既存環境とcloneのDNS名が違います。しかし、Immutableポリシーでは新しい環境を作ったり複製したりすることではなく、同じ環境にAuto Scaling Groupだけ追加することです。それで、2つのAuto Scaling Groupが同じDNS名を持っています。

最後に

今回はAWS Elastic Beanstalkで使えるデプロイポリシーとBlue/Greenデプロイについて話しました。

このようなデプロイポリシーって一回覚えても時間が経てば忘れがちなことだと思います。もし、皆さんがデプロイポリシーの内容を忘れてしまった場合、このブログが役に立ったら嬉しいです。