【AWS】Elastic Beanstalkのデプロイポリシーを整理する

はじめに

アプリケーションは、ほとんどの場合で「作ったら終わり」でなく、改修が行われます。
そして、改修を終えたアプリケーションは、デプロイ（稼働中のアプリケーションとの入れ替え）する必要があります。

この時、「サービスを停止して良いか？」、「問題発生時の対処をどうするか？」などの考慮を怠ると、利用者（お客様）へ迷惑をかけてしまいます。

AWSでは、よくあるデプロイ方式をパターン化し、ナレッジとして公開しています。

今回は、AWSが公開している「デプロイメントポリシー」について、ポイントを絞って紹介します。

「デプロイメントポリシー」の比較

全体像を掴むために、AWSが公開しているデプロイメントポリシーを表にまとめました。

ポリシー	デプロイ先 インスタンス	ダウン タイム	所要 時間	追加 費用	失敗時の影響	失敗時のリカバリ
All at once	既存	あり	小	なし	リカバリ完了まで ダウンタイム発生	改修前プログラムを 手動でデプロイ
Rolling	既存	なし	中	なし	リカバリ完了まで 可用性の低下	改修前プログラムを 手動でデプロイ
Rolling with additional batch	既存 & 新規	なし	中	あり (中)	リカバリ完了まで 可用性の低下	改修前プログラムを 手動でデプロイ
Immutable	新規	なし	大	あり (大)	最小限	新インスタンスの終了
Traffic splitting	新規	なし	大	あり (大)	最小限	新インスタンスの終了
Blue/Green	新規	なし	大	あり (大)	最小限	DNSの切り替え

「デプロイメントポリシー」の６種類

All at once

稼働中の全インスタンスで改修済みプログラムを一気に置き換える方式です。

最も単純です、迅速にデプロイを完了させることができます。
しかし、デプロイを稼働中インスタンスで実施するため、インスタンスの停止（再起動）が必要な場合があります。
加えて、デプロイ失敗時は「改修済プログラムも元のプログラムに置き戻す作業」が必要となります。

アプリケーションのダウンタイムが許容できるなら、候補となるデプロイ方式です。

Rolling

稼働中のインスタンスをグループに分けます。
そして、改修済みプログラムをグループ単位に順次置き換える方式です。

稼働中のインスタンスを残しつつデプロイできるため、アプリケーションを止める必要がありません。
しかし、グループ単位でデプロイ作業を行うため、デプロイ時間が長くなります。
加えて、デプロイ中は稼働中のインスタンス数が減少するため、利用状況によっては可用性が低下します。

デプロイ時間に余裕があり、利用状況が低い時間を見計らえるなら、候補となるデプロイ方式です。

Rolling with additional batch

ベースはRollingと同じで、稼働中のインスタンスをグループに分けます。
それに加え、可用性を維持するために追加の新規インスタンスを作成します。
そして、改修済みプログラムをデプロイした新規インスタンスを使いつつ、稼働中インスタンスはグループ単位に順次置き換える方式です。
※最終的に、余分なインスタンスは削除してインスタンス数を元に戻します。

稼働中のインスタンスを残しつつデプロイできるため、アプリケーションを止める必要がありません。
さらに、インスタンス数も維持されるので、可用性の低下も防ぐことができます。
しかし、Rollingと同様にグループ単位でデプロイ作業を行うため、デプロイ時間が長くなります。
加えて、追加で新規インスタンスを作成することから、費用が増加します。

デプロイ時間に余裕はあるが可用性の低下は許容できない。
それを回避するための費用負担は許容できるなら、候補となるデプロイ方式です。

Immutable 

改修済みプログラムに置き換え済みの新規インスタンスを別途作成します。
そして、デプロイタイミングで稼働中インスタンスと新規インスタンスを切り替える方式です。

デプロイ後も旧インスタンス（元稼働中インスタンス）が残り続けるので、デプロイ失敗時の戻し作業が容易にできます。
しかし、デプロイ準備期間からデプロイ後（旧インスタンスを削除するまで）は、２倍の料金が発生します。

大規模リリースなど安全性を重視し、そのための費用負担を許容できるなら、候補となるデプロイ方式です。

Traffic splitting

俗にいう「カナリアリリース」方式です。
Immutableと同様に、改修済みプログラムに置き換え済みの新規インスタンスを別途作成します。
そして、デプロイタイミングで何割かの通信量を稼働中インスタンスでなく新規インスタンスに流れるように設定しながら切り替える方式です。
※最終的に、全ての通信が新規インスタンスに流れるようになればデプロイ完了です。

デプロイ直後に不具合が見つかっても、その影響を一部の利用者に限定することができます。
しかし、通信量を適切に切り替え続ける手間、デプロイ準備期間からデプロイ後（旧インスタンスを削除するまで）の料金負担が重くのしかかります。

アプリケーションを短いスパンで開発し続ける体制があり、コスト最適化が図れているなら、候補となるデプロイ方式です。

Blue/Green

基本的な考え方はImmutableと似ており、稼働中環境と新規環境を準備してデプロイタイミングで切り替えます。
これまでの方式は、インスタンスのみ、またはAuto ScalingやLoad Balancerを利用して実現します。
しかし、Blue/GreenではDNSを利用してこの切り替えを行う方式です。

Blue/Greenではデプロイ前後で別環境に切り替わるため、新旧のインスタンスが混在する時間は一切ありません。
しかし、インスタンスだけでなく、ネットワークサービスも含めて新旧環境で用意するため、さらに大きい費用負担となります。

Immutableよりもさらに安全性を重視し、そのための費用負担を許容できるなら、候補となるデプロイ方式です。

「デプロイメントポリシー」の選び方

所要時間（手間）を最小限にしたい

「所要時間（手間）」で考えれば、「All at once」一択です。

デプロイ日程を決めて、決められた時間内でデプロイ作業を完了させます。
デプロイ作業中はアプリケーションが利用できませんが、事前通知して了承を得ておきます。

デプロイ作業が順調に完了し、改修したプログラムも問題なければ、最も効率的は方式です。
しかし、万が一の場合に備え、リカバリ計画を作成することを忘れてはいけません。

費用を最小限にしたい

「費用」で考えれば、「All at once」か「Rolling」が選択肢にあがります。

「All at once」は、「所要時間（手間）」で解説済みなので割愛します。

「Rooling」は、インスタンスをグループ分けして、順次デプロイするのでダウンタイムは発生しません。
グループの分け方によっては可用性が低下する可能性があるため、事前通知して了承を得ておきます。
もし、可用性の低下が許容できない場合は、追加費用を申請して「Rolling with additional batch」の採用も検討しましょう。

全てが順調に完了できたならば、「Rooling」と「Rolling with additional batch」はダウンタイムなしの方式の中で最も効率的です。
しかし、万が一の場合に備え、リカバリ計画を作成することを忘れてはいけません。

失敗時のリスクを最小限にしたい

全ての作業が順調に完了できるように準備を整えますが、残念ながらリスク：0％はあり得ません。
そして、リスクを最小化するためには費用と手間が必要です。

費用と手間を掛けてリスク最小化を目指すならば、「Immutable」、「Traffic splitting」、「Blue/Green」が選択肢にあがります。

「Immutable」と「Traffic splitting」の違いは、デプロイ時に通信を切り替える割合です。
個人的には、原則としては「Immutable」を採用すると考えています。

アプリケーションの改修内容によっては、新旧の並行稼働が不可な場合があります。
まずは、改修内容を確認して「Traffic splitting」を選択できるかを確認しましょう。
その上で、「新旧の並行稼働にメリットがあるか？」を整理します。
手間に見合うメリットがあるならば、「Traffic splitting」を採用しましょう。

「Blue/Green」は、個人的にオーバースペックだと考えています。
まずは、「Immutable」で検討して、どうしても満足できないならば「Blue/Green」を検討し始めれば良いと考えます。

最後に

オンプレミス環境であれば、デプロイ方式は現実的に「All at once」しか選択できなかったでしょう。
しかし、クラウド環境であれば、リソースを柔軟に利用する利点を活かして様々なデプロイ方式を選択できるようなります。

選択肢が増えると学ぶことも増えるので負担が増えてしまいます。
ただし、そのハードルを乗り越えさえすれば、これまで諦めていたことが解決できるかもしれません。

この情報が、皆さんの可能性を広げる手助けになれば幸いです。