おはようございます、YASUです。
以前、CodeDeployのBlue/Greenデプロイを整理しましたが、DVAの勉強を進めると、Elastic Beanstalkにも「デプロイポリシー」という、似た名前の仕組みが何種類も出てきます。All at once、Rolling、Immutable…と並ぶと、どれがどれだか分からなくなり、模擬試験でも選択肢を取り違えました。今日は、これを「お店の改装」に例えて整理します。
結論
Elastic Beanstalkのデプロイポリシーは5種類ありますが、判断軸は「ダウンタイムを許せるか」「デプロイ中も処理能力を保ちたいか」「失敗した時にすぐ戻したいか」の3つに絞れました。この3つの質問に答えていくと、選ぶべきポリシーがほぼ決まります。
まず5種類を、お店の改装で例える
複数のEC2インスタンスで動くアプリを、お店の複数の店舗だと考えると分かりやすくなりました(これは自分なりの例えです)。新しいバージョンのデプロイは、お店の改装です。
- All at once:全店舗を一斉に閉めて、まとめて改装する。一番早いが、改装中はお客さんが入れない
- Rolling:店舗を数店ずつのグループに分けて、順番に改装する。全店が閉まることはないが、改装中は店舗数が減るので、お客さんをさばく力は落ちる
- Rolling with additional batch:先に臨時の店舗を出してから、順番に改装していく。店舗数が減らないので、処理能力を保てる。その分、時間とコストはかかる
- Immutable:今の店舗はいじらず、新しい店舗を丸ごと一式建てる。問題なければ新店舗に切り替え、ダメなら新店舗を取り壊すだけなので、元に戻すのが簡単
- Traffic splitting:Immutableと同じく新店舗を建てたうえで、最初は一部のお客さんだけを新店舗に案内する。問題がなければ、全員を新店舗に案内して、旧店舗を閉じる
公式ドキュメントの説明と照らし合わせる
AWS公式ドキュメントでも、それぞれの特徴は次のように書かれていました。
- All at once:最も迅速なデプロイ方法で、短時間の停止が許容できる場合に適している。新バージョンを各インスタンスにデプロイしたあと、ウェブサーバーなどを再起動するため、一時的に利用できなくなる
- Rolling:ダウンタイムを避け、可用性の低下を最小限に抑えられるが、デプロイ時間は長くなる。デプロイ中は、旧バージョンと新バージョンのインスタンスが混在する
- Rolling with additional batch:追加のバッチを先に起動するので、可用性の低下を避けられるが、Rollingよりさらに時間がかかる
- Immutable:新バージョンは常に新しいインスタンスにデプロイされる。別のAuto Scalingグループで起動し、ヘルスチェックに通らなければ新インスタンスを破棄するだけで、元のインスタンスには手を付けないので、素早く安全にロールバックできる
- Traffic splitting:Immutableのデプロイを行ったうえで、決められた時間だけ、トラフィックの一部を新しいインスタンスに流す。問題なければ全トラフィックを新しい側に移す
3つの質問で選ぶ
Q1. 短時間のダウンタイムを許せる?
→ 許せる:All at once(最速)
Q2. デプロイ中も、処理能力を落としたくない?
→ 落ちてもよい:Rolling
→ 落としたくない:Rolling with additional batch
Q3. 失敗した時、すぐ元に戻したい?
→ すぐ戻したい:Immutable
→ 一部のユーザーで様子を見たい:Traffic splitting試験では、問題文の要件から「ダウンタイム」「処理能力」「ロールバックの速さ」「段階的な切り替え」といったキーワードを拾って、この3つの質問に当てはめれば、迷いにくくなりそうです。
試験で狙われそうな落とし穴:環境の種類で使えないポリシーがある
調べていて意外だったのが、環境の種類によって、使えるポリシーが変わるという点です。
- All at once:ロードバランサー環境も、単一インスタンス環境も使える
- Rolling / Rolling with additional batch:ロードバランサー環境のみ。単一インスタンス環境では使えない
- Immutable:ロードバランサー環境も、単一インスタンス環境も使える
- Traffic splitting:Application Load Balancerを使うロードバランサー環境のみ
考えてみれば当然で、インスタンスが1台しかないのに「数台ずつ順番に」は成立しませんし、トラフィックを分けるにはロードバランサーが必要です。ただ、「単一インスタンス環境で、ダウンタイムを避けたい」という問題が出たら、Rollingではなく、Immutableが候補になる、という判断ができるようにしておきたいところです。
ちなみに、デフォルトはAll at onceです。ただし、EB CLIでスケーラブルな環境を作った場合は、Rollingがデフォルトになる、という例外もあるようでした。
CodeDeployのBlue/Greenとの関係
以前整理したCodeDeployのBlue/Greenデプロイは、「新しい環境をまるごと用意して、通信の向き先を切り替える」という方式でした。Elastic Beanstalkでは、ImmutableやTraffic splittingが、この発想に近いポリシーです。一方、環境そのものを2つ用意して、URLを入れ替えるBlue/Greenは、5つのデプロイポリシーとは別の運用方法として扱われます。名前が似ていて混同しやすいので、「Beanstalkのデプロイポリシー(5種類)」と「Blue/Greenデプロイ」は、別の枠で覚えておくと整理しやすそうです。
まとめ
- Elastic Beanstalkのデプロイポリシーは、All at once・Rolling・Rolling with additional batch・Immutable・Traffic splittingの5種類
- 「ダウンタイムを許せるか」「処理能力を保ちたいか」「すぐ戻したいか」の3つの質問で選べる
- Immutableは新しいインスタンスを別に用意するため、失敗しても元の環境に影響せず、ロールバックが早い
- 単一インスタンス環境では、RollingやTraffic splittingは使えない
- デフォルトはAll at onceだが、EB CLIでスケーラブルな環境を作った場合はRollingになる
名前だけ見ると似たものが並んでいて混乱していましたが、お店の改装に例えて整理すると、それぞれの違いがかなり見えやすくなりました。それでは、また明日!
コメント