はじめに

概要

AWSのDVA試験に出題されるElastic Beanstalkについて簡単にまとめました
Beanstalkはアプリのデプロイ環境をまとめて作っちゃうよ〜というサービスです。
読み方はビーンストークだと思います。和訳は「豆の茎」だそうです。なんで？

AWSにはAmplifyというフロントエンドの実行環境を自動で作成してくれるサービスがありますが、
そのバックエンド版という感じでしょうか。

Elastic Beanstalkが作成するサービス

Elastic Beanstalkが自動的に作成してくれるのは以下のサービスです。

EC2
S3
RDS
Elastic Load Balancing
Auto Scaling
CloudWatch
CloudFormation
IAM
Route 53

こんなにもたくさんのサービスを作ってくれるんですね。
これだけのサービスを手動で作成してデプロイまでを考えるととても便利なサービスです。
もちろん必要なリソースのみを起動することができます。

さらに、ローカル環境で作成したソースコードを圧縮してElastic Beanstalkにアップロードするだけで数クリックでデプロイできちゃいます。
至れり尽くせりです。

アップロードしたファイルが間違っていたら？
Elastic BeanstalkにアップロードしたソースコードはS3に保管されます。
このS3バケットではバージョニング機能が有効になっています。
そのため、ソースコードに不具合があった場合は一つ前の、正常に動作していたバージョンに戻すことができます。

ちなみに、古くなったバージョンはライフサイクルポリシーで自動的に削除することができます。

実行環境

実行環境には2種類あります。

ウェブサーバー環境
こちらは上記で説明したようなアプリの実行環境がデプロイできます。
ワーカー環境
ワーカー環境はウェブサーバー環境でデプロイしたアプリで大量の処理が必要な場合などに使われる環境です。
SQSというAWSリソースを用いて、処理を分散させることができます。
この機能を使うことでウェブサーバー環境で処理しきれない分をカバーすることができます。

構造

Elastic Beanstalkの構造は
アプリケーションの下に実行環境が属しています。
ツリー構造で表すとこのような感じです。

デプロイポリシー

アプリケーションが新バージョンとなった際、いくつかのデプロイ方法があります。
以下、表にまとめてみました

デプロイポリシー名	説明	ユースケース
All at once	一度にすべてのインスタンスにアプリをデプロイします。デプロイ中の短い停止があるかもしれません。デプロイ失敗時は手動で戻す必要があります。	小規模なアプリケーション、短期間のダウンタイムが許容される場合、または素早いデプロイが求められる場合に適しています。
Rolling	インスタンスをグループ分けし、順番にアプリをデプロイします。停止なしで更新が可能ですが、一時的に古いバージョンと新しいバージョンが共存します。デプロイ失敗時は手動で戻す必要があります。	ダウンタイムなしでアップデートが必要な場合や、新旧バージョンが一時的に共存しても問題ない場合に適しています。
Rolling with additional batch	新しいインスタンスグループを作成し、新バージョンをデプロイします。古いインスタンスを新しいグループに移動してバージョン切り替え。停止なしで切り替えができますが、デプロイ失敗時は手動で戻す必要があります。	既存のリソースに影響を与えずにデプロイを行いたい場合や、新旧バージョンの共存が問題ない場合に適しています。
Immutable	新しいインスタンスを作成し、新バージョンをデプロイします。デプロイ成功時に新インスタンスで古いインスタンスを置き換えます。デプロイ失敗時は自動で戻ります。停止なしで安全に切り替えができます。	高い安全性が求められるアプリケーションや、自動ロールバックを求める場合に適しています。
Blue/Green	新しい環境を作成し、新バージョンをデプロイします。デプロイ成功時にトラフィックを新環境に切り替えます。デプロイ失敗時は自動で戻ります。新旧バージョンが完全に分離され、停止なしで安全に切り替えができます。トラフィックを段階的に切り替えることで、新バージョンへの移行をテストできます。ロールバックはトラフィックを元環境に戻すだけで容易です。	複雑なアプリケーション、高い可用性が求められる場合、段階的なトラフィック切り替えによるテストが必要な場合に適しています。

めちゃくちゃわかりやすい記事があったので参考にさせて頂きました。
参考：AWS Elastic Beanstalkで使えるデプロイポリシーを理解する　| DeveloperIO

更新タイプ

次に、環境を変更した場合も変更手順についてもいくつか方法があります。
以下、表にまとめます

更新タイプ	説明	ユースケース
無効（Disabled）	環境設定の変更時に自動デプロイを行いません。設定変更後、手動でデプロイする必要があります。	手動でデプロイをコントロールしたい場合や、特定のタイミングでデプロイを行いたい場合に適しています。
ヘルスにもとづくローリング（Rolling Based on Health）	環境のインスタンスをグループに分け、順番に設定変更を適用します。インスタンスのヘルスに基づいて更新を行い、ダウンタイムはありません。	新旧設定が一時的に共存しても問題ない場合、またはダウンタイムが許容されない場合に適しています。
時間にもとづくローリング（Rolling Based on Time）	指定された時間間隔でインスタンスをグループに分け、順番に設定変更を適用します。ダウンタイムはありません。	既存のリソースへの影響を最小限に抑えたい場合や、新旧設定の共存が問題ない場合に適しています。
変更不可（Immutable）	新しいインスタンスを作成し、新しい設定で起動します。設定が成功したら、新しいインスタンスで古いインスタンスを置き換えます。ダウンタイムはありません。	高い安全性が求められる場合や、設定変更に失敗した場合の自動ロールバックが必要な場合に適しています。

まとめ

Elastic Beanstalkで難しいのはデプロイポリシーと更新タイプの選定だと思います。
これらはアプリケーションの要件、ダウンタイム許容レベル、デプロイ速度など様々要件を元に設計する必要があります。

所感

以前にAmplfyを使ってフロントエンドの実装が簡単にできた時に衝撃を受けたのですが、今回Elastic Beanstalkを使ってみてあの時と同じ衝撃がありました。
同じような設計を手動で行った際、各リソースの疎通にかなり苦戦した記憶があるので、こんなにも簡単にデプロイできる仕組みがあるのは素晴らしいですね。