はじめに

この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧はこちら。

この記事ではElastic Beanstalkに関連する内容を超詳細にまとめています。

具体的には以下流れで説明します。

AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。

この記事を読んでほしい人

Elastic Beanstalkとは開発者がアプリケーションの開発に集中するためのAWSのサービスです。
具体的には、典型的なWeb環境またはキューイングを用いた非同期型のワーカー環境の構築からリリース、運用までの手間を大幅に省いてくれるサービスです。

Amplify同様、作りこみにくいというデメリットがあるのでエンタープライズな実プロジェクトで使うことはほとんどありませんが、試験向けにはデプロイ手法がよく聞かれるので知っておいて損はありません。

Elastic Beanstalkはインフラストラクチャ部分の管理だけではなくアプリケーションの管理もまとめて行うことが可能です。
構成要素は3つ、アプリケーション、アプリケーションバージョン、環境です。

アプリケーションはアプリケーションバージョンと環境の情報を束ねる論理単位です。
1つのアプリケーションにつき複数の環境やアプリケーションバージョンを持つことができ、例えば開発環境と本番環境の2つの環境を1つのアプリケーションで管理することが可能です。

アプリケーションバージョンはデプロイ可能なコードを指し、S3上でバージョン管理されます。
環境ごとに異なるアプリケーションバージョンをデプロイすることが可能です。

環境はインフラストラクチャ部分の設定でウェブサーバ環境とワーカー環境の2種類があります。

ウェブ環境はスケーラブルなウェブアプリケーションを実行するための環境です。
ELBとAuto Scalingでスケーラビリティを確保しています。

一方、ワーカー環境はバッチアプリケーションを実行するための環境です。
こちらはSQSとAuto Scalingでスケーラビリティを確保しています。

環境の種類とは別に環境のタイプと呼ばれる概念があります。

これは、ウェブサーバ環境とワーカー環境どちらであれコスト最適にするかパフォーマンス最適にするかをえらぶためのものでシングルインスタンス環境かAuto Scaling環境かを選んで構築可能です。
シングルインスタンス環境は低コストで運用したい際によく利用します。

Elastic Beanstalkでサポートされているデプロイメントオプションは5つです。

各デプロイメントオプションは以下に表形式でまとめました。

デプロイメントポリシー	詳細	負荷分散された環境のサポート	単一インスタンス環境のサポート
All at once	AutoScalingGroup内のEC2インスタンスをすべて一度に更新	○	○
ローリング	AutoScalingGroup内のEC2インスタンスを指定した台数ずつ更新(一時的な台数減あり)	○	×
追加バッチによるローリング	AutoScalingGroup内のEC2インスタンスを指定した台数ずつ更新(一時的な台数減なし)	○	×
イミュータブル	新しくAutoScalingGroupを作りEC2インスタンス起動後、既存のAutoScalingGroupにインスタンスを移動して更新	○	○
トラフィック分割	新しくAutoScalingGroupを作りトラフィック切り替えを行い更新	○ ※ALB必須	×

具体的なイメージがわくように、EC2インスタンス上のアプリケーションがどのように更新されるかを可視化したのが以下の図です。

All at once は文字通り1度に全台のインスタンスを更新し、ローリングは指定した台数ずつ更新しているのがわかると思います。

ローリングと追加バッチによるローリングの違いは更新中にEC2インスタンスの台数が減少するか維持されるかです。
これはコストとパフォーマンスのどちらを取るかで選ぶことになり、試験でもよく聞かれます。

また、イミュータブルとトラフィック分割の違いは新旧のバージョンに流れるトラフィックを厳密に管理できるかできないかです。

イミュータブルの場合、一時的にですがランダムで新旧どちらかのインスタンスにトラフィックが流れます。
一方、トラフィック分割の場合、新旧それぞれに流すトラフィックの割合を制御することができます。
そのため、Canaryリリースではトラフィック分割を利用します。

また、Elastic BeanstalkのデプロイメントオプションにはないBlue/Greenを実現したい場合にはRoute53を用いたURLのスワップが必要です。

この点も試験でよく聞かれるので、Blue/GreenはElastic BeanstalkのデプロイメントオプションではなくRoute53を用いたURLスワップだと覚えておきましょう。

ここまで、Web環境とワーカー環境はどちらか1つを使う前提で書いていましたが、実は2つの環境をつなぐことも可能です。

具体的には上図の通りリクエストをフロント側のWeb環境で受け、SQSを使って負荷のかかる処理をワーカー環境で非同期に処理するという構成です。
例えば巨大ファイルの圧縮などが想定できます。

なお、繰り返し実施する処理はElastic Beanstalkの中のcron.ymlに処理を記載することで実現できます。

この記事ではElastic Beanstalkに関連する内容を超詳細にまとめました。

次回はAWS SAMについて超詳細解説します。