Amazon Elastic Beanstalkではアプリケーションごとの利用用途や許容ダウンタイムなどの要件により、いくつかのデプロイ方法(デプロイポリシー)を選択できるようになっているそうです。(´Д｀)
デプロイポリシー概要
| デプロイポリシー | 概要 |
|---|---|
| Rolling | バッチサイズに合わせてデプロイする。例えばパッチサイズが50%の場合半分のインスタンスに対してデプロイする。|なし|遅 |
| Rolling with additional batch | Rollingと同様だがキャパシティが100%を維持するようにデプロイする。|なし|遅 |
| Immutable | 既存のインスタンスは変更せず、AutoScalingGroupを新たに１つ作成し、そちらに1台ずつインスタンスを追加してデプロイし、デプロイ完了後旧AutoScalingGroupは削除される。|なし|遅 |
| Traffic splitting | Canaryテストのデプロイ方法。受信トラフィックの一部を使用して新しいアプリケーションをテストしながらデプロイする。|なし|遅 |
| Blue/Green | 新しい環境を構築し、そちらにすべてデプロイし、完了後DNSを切り替える形でデプロイする。|なし|最遅 |
環境毎での利用可能デプロイポリシー
| デプロイポリシー | 負荷分散環境 | 単一インスタンス環境 | レガシーWindowsサーバ環境 |
|---|---|---|---|
| All at Once | 可 | 可 | 可 |
| Rolling | 可 | 不可 | 可 |
| Rolling with additional batch | 可 | 可 | 可 |
| Immutable | 可 | 可 | 不可 |
| Traffic splitting | 可 | 不可 | 不可 |
| Blue/Green | 可 | 可 | 可 |
デプロイポリシー メリット・デメリット
| デプロイポリシー | メリット・デメリット |
|---|---|
| All at Once | デプロイ速度が速い。デプロイ中はインスタンスがサービス停止になるためダウンタイムが発生する。新旧のバージョンが混在する時間がある。 |
| Rolling | バッチサイズに合わせてデプロイする。例えばパッチサイズが50%の場合半分のインスタンスに対してデプロイする。新旧のバージョンが混在する時間がある。 |
| Rolling with additional batch | Rollingと同様だがキャパシティが100%を維持するようにデプロイする。新旧のバージョンが混在する時間がある。 |
| Immutable | 既存のインスタンスは変更せず、AutoScalingGroup新たに１つ作成し、そちらにインスタンスを追加してデプロイし、デプロイ完了後古いAutoScalingGroupは削除される。新旧のバージョンが混在する時間がある。 |
| Traffic splitting | 新旧のバージョンが混在する時間がある。 |
| Blue/Green | 旧(Blue)環境とはDNSも違う新(Green)環境を作成し、新環境にデプロイする。デプロイ完了後急環境は削除される。新旧のバージョンの混在時間が発生しない。DNSCacheにより切り替え完了までに時間がかかる。DNSレコードの変更が必要。 |
Blue/GreenとImmutableの違い
Immutableは新を1台デプロイし、旧を1台削除することを繰り返すため、新旧のバージョンが混在する時間が発生する。Blue/Greenは新しい環境を作成し、新(Green)環境のデプロイが完了後DNSの切り替えでデプロイを行うため、新旧のバージョン混在時間は発生しない。
感想
Immutableはよく聞く単語ですね！[不変]だそうです。英語がわかれば意味も見えてくるので覚えたい、、、
