AWS Elastic Beanstalkのデプロイポリシーがなかなか覚えられないなぁ…
そのお悩みを解決します！
エンジニアの皆さん。
日々の業務、そして学習お疲れ様です！学習は順調に進んでいますか？？
アプリケーションが動作するインフラ環境のデプロイを自動化してくれるAWS Elastic Beanstalk(以降、Elastic Beanstalkと表記します)
Elastic Beanstalkのこれらのデプロイポリシーの違いを自分の言葉で説明することはできますか？
- All at once (一度にすべて)
- Rolling (ローリング)
- Rolling with additional batch (追加バッチによるローリング)
- Immutable (イミュータブル)
- Traffic splitting (トラフィック分割)
………
………………………
できましたでしょうか？
本記事ではElastic Beanstalkのデプロイポリシーについて、初心者にわかりやすいよう皆さん大好きな国民的アニメ「ポ◯モン」に例えながら図解付きで解説していきます。
本記事を読んだ後にこういう風に捉えると覚えやすいなぁって共感して頂けると嬉しいです。それではどうぞ！
- これからAWSを学んでいく初学者の方
- デプロイポリシーを覚えられない方
- なんとなく理解したつもりでいるけど、改めて復習したい方
- Elastic Beanstalkの機能
- Elastic Beanstalkのハンズオン例
Elastic Beanstalkとは
Elastic Beanstalkとはアプリケーションが動作するインフラ環境のデプロイを自動化してくれるサービスです。
※今回はデプロイポリシーに絞ってお話しするため、具体的な機能については省略しています。
具体的な機能については、こちらの公式のBlackBeltを確認してみて下さい。（ちなみにデプロイポリシーに関する説明はp.31からです！）
AWS Black Belt Online Seminar 2017 AWS Elastic Beanstalk
デプロイポリシー
Elastic Beanstalkではアプリケーションの新しいバージョンをデプロイするときにどのようにデプロイするか決めます。その時の方法をデプロイポリシーと呼びます。 デプロイポリシーにはこのような種類があります。
| No. | デプロイポリシー | 特徴 |
| 1 | All at once (一度にすべて) | 既存インスタンスに同時にデプロイするポリシー |
| 2 | Rolling (ローリング) | 既存インスタンスを利用してデプロイするポリシー |
| 3 | Rolling with additional batch (追加バッチによるローリング) | インスタンス数を維持したまま新規と既存インスタンスを利用してデプロイするポリシー |
| 4 | Immutable (イミュータブル) | 既存インスタンスを更新せず、新規インスタンスを利用してデプロイするポリシー |
| 5 | Traffic splitting (トラフィック分割) | 新規インスタンスで処理するが、さらにトラフィック制御をし、振り分け先を変更してデプロイするポリシー （カナリアリリースとも呼ばれます） |
これだけでは理解しにくいですね。
各ポリシーのデプロイ方法を解説するために、ここからは国民的アニメ「ポ◯モン」に例えてみましょう。このように定義します。
この状態から、各デプロイポリシーでどのようにデプロイ（進化）していくのか解説していきます！
All at once (一度にすべて)
一時的に戦闘不能になってもいいから早く進化させたい！
この場合はAll at once (一度にすべて) を選択しましょう。
All at once (一度にすべて) は既存インスタンスに同時にデプロイするポリシーです。 「一度にすべて」という名前の通り、一気に進化させます。
このように全てのトラ◯セルが一気に進化し始めます。 そのため進化が完了するまでの間、虫取り少年は使うポ◯モンがいません。 つまりサービス停止の状態になります。
進化完了後に、バタ◯リーが使えるようになります。
このように短期間のダウンタイムが存在しますが、デプロイポリシーの中で一番簡単かつ最も迅速に進化できるポリシーです。
- 既存インスタンスへのデプロイ
- 最も迅速にデプロイできる
- 短時間のダウンタイムが発生
Rolling (ローリング)
戦闘不能状態になるのはまずいなぁ…手持ちの数を維持したまま進化させたい！
この場合はRolling (ローリング) を選択しましょう。
Rolling (ローリング) は既存インスタンスを利用してデプロイするポリシーです。
このポリシーでデプロイするときは予めバッチサイズというものを設定しなければいけません。
このバッチサイズではデプロイを進める割合もしくはインスタンスの個数を決定します。
今回は割合50%で考えてみましょう。
バッチサイズ50%のため、4匹中2匹を進化させます。 そのため、まずは2匹を一時的に使用しないように虫かごから出します。（ロードバランサからデタッチします。）
そして、進化させます。
進化中は2匹でしか戦えないため、使えるポ◯モンの数が減っている状況になります。
2匹の進化完了後、再度虫かごに戻します。（ロードバランサにアタッチします。）
進化前後が混在しているため、虫取り少年は一時的にトラ◯セルもしくはバタ◯リーのどちらかで戦うことになります。
その後、残りのトラ◯セル2匹も進化させます。
この間も一度虫かごから取り出すため、一時的に2匹でしか戦えません。
進化完了後、全てバタ◯リーで戦えるようになります。
- 既存インスタンスへのデプロイ
- ダウンタイム発生しない
- キャパシティが一時的に減る
- 新旧アプリケーションが混在する時間がある
Rolling with additional batch (追加バッチによるローリング)
戦えるポ◯モンの数を維持したまま進化させたいなぁ！
この場合はRolling with additional batch (追加バッチによるローリング) を選択しましょう。
Rolling with additional batch (追加バッチによるローリング) はインスタンス数を維持したまま新規と既存インスタンスを利用してデプロイするポリシーです。
Rollingポリシーと同じようにバッチサイズを設定します。
ここでも割合50%で考えてみましょう。
まずこのようにバッチサイズ分2匹の新しいトラ◯セルを追加します。
このように追加することで使用できるポ◯モンの数を維持したままにできます。
進化完了後、戦えるように虫かごに入れます。（ロードバランサにアタッチします。）
この間も進化前と後が混在しているため、虫取り少年は一時的にトラ◯セルもしくはバタ◯リーのどちらかで戦うことになります。
その後、次のバッチサイズ分のトラ◯セルを虫かごから取り出し、進化させます。
進化完了後、再度使用できるように虫かごに入れます。
これで4匹が進化できたため、最後に元のトラ◯セルはバイバイします。
Rollingと違って、キャパシティを維持したままデプロイできるため本番で採用されやすいポリシーです。
- ダウンタイム発生しない
- 新旧アプリケーションが混在する時間がある
- 既存と新規インスタンスへのデプロイ
- キャパシティを維持したままデプロイする
- Rollingよりもデプロイ所要時間がかかる
Immutable (イミュータブル)
既存のトラ○セルは残したまま、追加のトラ○セルを進化させたいなぁ
この場合はImmutable (イミュータブル)を選択しましょう。
Immutable (イミュータブル)は既存インスタンスを更新せず、新規インスタンスを利用してデプロイするポリシーです。
まずこのように最初に新しいグループを作成し、そこに1匹のトラ◯セルを追加します。
進化完了後、虫かごに入れて戦える状態か確認をします。
戦える状態であれば残り3匹のインスタンスを追加し、進化させます。
進化完了後、虫かごに入れます。
この間も進化前と後が混在しているため、虫取り少年は一時的にトラ◯セルもしくはバタ◯リーのどちらかで戦うことになります。
最後にトラ◯セルの方のグループを終了します。
- 新規インスタンスへのデプロイ – ダウンタイム発生しない
- デプロイに時間がかかる
- キャパシティが一時的に増える
- 新旧アプリケーションが混在する時間がある
Traffic splitting (トラフィック分割)
一定期間進化後のバタ◯リーを使用して、問題なさそうなら全部バタ◯リーにしたい
この場合はTraffic splitting (トラフィック分割)を選択しましょう。
Traffic splitting (トラフィック分割)は新規インスタンスで処理するが、さらにトラフィック制御をし、振り分け先を変更してデプロイするポリシーです。
このデプロイ方法はカナリアリリースとも呼ばれます
一部のユーザにのみ新バージョンを公開したいときに使われる手法だよ！
まずはImmutableポリシーと同じように別のグループを作成しておきます。
そして予め設定したトラフィック分割量と評価時間の間だけ、進化後のバタ◯リーが使えるようになります。
そして問題なければ、全体をバタ◯リー方に切り替え、最後にトラ◯セルの方のグループを終了します。
- 新規インスタンスへのデプロイ
- 新バージョンで不具合があった時、一部ユーザーには影響が出る
- デプロイに時間がかかる
- 新旧アプリケーションが混在する時間がある
おまけ：Blue/Greenデプロイ
同時にトラ◯セルとバタ◯リーで戦うのは嫌だなぁ。進化後のバタ◯リーだけで戦いたい！
この場合はBlue/Greenデプロイを選択しましょう。
Blue/Greenデプロイは2つの環境を用意し、デプロイ完了後にスイッチのように新環境に切り替えるデプロイ方法です。旧環境をBlue、新環境をGreenと呼びます。
厳密にはElastic Beanstalkで用意されているデプロイポリシーではありません。
しかしデプロイをするときに違うバージョンが混在する時間をなくしたい場合に有用な方法です！
まず、今ある虫かごと同じものを用意します。
作成した虫かご内のトラ◯セルをAll at Onceポリシーで一気に進化させます。
進化完了後に戦闘状態であることが確認できたら、虫かごを切り替えます。（DNS名の切り替え）
これにより、虫取り少年はバタ◯リーでのみ戦えるようになります。
- 新環境の作成
- デプロイに時間がかかる（DNS名の入れ替えなど）
- 旧バージョンへの戻し（ロールバック）が用意
- 新旧アプリケーションが混在する時間がない
以上です！
まとめ
今回はAWSサービスの中からElastic Beanstalkのデプロイポリシーに絞ってお話ししました。
なんとなく理解できたのではないでしょうか？
デプロイポリシーは実際にハンズオンで触りながら覚えることで、さらに理解が深まると思います！
もっとAWSについて学びたい！
AWS初学者の方は会員制コミュニティ付きの動画で学べるAWS学習オンラインスクールCloudTechがおすすめ！
CloudTechについてはこちらの記事でご紹介しているので、参考にしてみて下さい。
今だけお得に入会できるクーポンコード配布中！
それでは、これからも一緒に学んで、自己価値を高めていきましょう〜！
最後まで、お読み頂きありがとうございました！
参考文献
本記事を作成するにあたり、こちらのブログ記事や本を参考にさせて頂きました！
今回解説していないElastic Beanstalkの具体的な機能についても詳しく解説されており、どれもAWS初学者にとって、とても分かりやすい内容になっています。
よかったら参考にしてみて下さい！
コメント