AWS Elastic Beanstalkによるアプリケーションのデプロイと運用

AWS Elastic Beanstalkは、アプリケーションをアップロードすると、実行に必要なAWSリソースをまとめて構築し、デプロイやスケーリング、ヘルス監視を支援するPaaSです。開発者はOSやロードバランサー、Auto Scalingの設定を個別に組み立てる代わりに、アプリケーションのコードやコンテナと環境設定を用意して、管理の一部をElastic Beanstalkへ委ねられます。

Elastic Beanstalk自体がアプリケーションを実行する仮想マシンなのではありません。環境の構成に応じて、Elastic Load Balancing、Amazon EC2、EC2 Auto Scaling、Amazon S3、Amazon CloudWatch、AWS CloudFormationなどのサービスを使います。Elastic Beanstalkはそれらのリソースの作成や設定を調整しますが、アプリケーションの設計、アクセス権、ネットワーク、データ保護、運用要件の決定は利用者が担います。Elastic Beanstalk自体の追加料金ではなく、主に環境で使うEC2、ロードバランサー、ストレージ、監視などのAWSリソースに対して料金が発生します。構成と稼働時間に応じた課金単位はElastic Beanstalkの料金ページで確認します。

Java、.NET、Node.js、PHP、Python、Ruby、GoなどのプラットフォームやDockerを利用でき、環境に合ったアプリケーションのバンドルをデプロイします。環境ごとにプラットフォームのバージョンや構成を選び、後からアプリケーションの新しいバージョンをデプロイできます。

アプリケーション、バージョン、環境

Elastic Beanstalkでは、アプリケーションが管理のまとまり、アプリケーションバージョンがデプロイ可能なコードのスナップショット、環境がそのバージョンを動かすAWSリソースの集合です。環境は一つのアプリケーションバージョンを実行し、設定を変えて別の環境として開発・テスト・本番などを分けることができます。アップロードされたソースバンドルはS3に保存され、指定したバージョンを環境へデプロイします。

環境のプロビジョニングでは、Elastic BeanstalkがCloudFormationスタックなどを通じてリソースを作成・管理します。Webサーバー環境をロードバランス構成にするとロードバランサーとEC2 Auto Scalingグループが使われ、負荷や設定に応じてEC2インスタンスが増減します。単一インスタンス構成ではロードバランサーを置かずに簡単な環境を作ることもできます。どの構成でも、EC2インスタンスの数、ロードバランサーの方式、監視設定などは環境の要件に合わせて決めます。

Webサーバー環境とWorker環境

環境層はアプリケーションの役割を分けるための構成です。よく使われるのはHTTPリクエストを受け付けるWebサーバー環境と、キューから処理を受け取るWorker環境です。

Webサーバー環境

Webサーバー環境は、ブラウザーやAPIクライアントからのHTTPリクエストを受け取り、アプリケーションを実行します。ロードバランサーを備えた構成では、リクエストを複数のEC2インスタンスへ分散し、Auto Scalingでインスタンス数を調整できます。短時間で応答できる処理をWeb層で完了させ、時間のかかる処理はキューへ渡すと、リクエストを受け付ける層が長い処理に占有されにくくなります。

Worker環境

Worker環境は、Webリクエストへの即時応答が必要ない処理や、比較的長く実行される処理に向きます。環境にはEC2 Auto ScalingグループとAmazon SQSキューが関連付けられ、各EC2インスタンスではElastic Beanstalkのインスタンス上のデーモンがキューをポーリングします。デーモンは取り出したメッセージを、HTTP POSTリクエストとして同じインスタンス上のアプリケーションへ渡します。アプリケーションはPOSTリクエストとして届くタスクを処理します。

Web層のアプリケーションはAWS SDKなどを使ってSQSへメッセージを送信できます。たとえば、Webアプリケーションが大量の売上レポート生成を受け付けたら、要求をキューへ登録して受付結果を返します。Worker環境はメッセージを受け取り、レポートを作成してS3に保存し、処理結果を利用者が取得できる状態にします。Web層とWorker層を分けることで、重いバックグラウンド処理がHTTPリクエストの応答を妨げにくくなり、処理量に応じた個別のスケーリングもしやすくなります。

キューにメッセージがあるだけでタスクが成功したとは限りません。アプリケーション側は失敗時の再試行、重複実行への耐性、処理時間と可視性タイムアウト、失敗メッセージの扱いなどを設計します。デーモンはSQSからメッセージをアプリケーションへ届ける仕組みであり、アプリケーション固有の処理結果や冪等性までは自動で保証しません。

.ebextensionsによる環境のカスタマイズ

Elastic Beanstalkが用意する標準環境に固有の設定を加えるには、アプリケーションのソースバンドル内に .ebextensions ディレクトリを作成し、.config 拡張子のYAMLファイルを置きます。Elastic Beanstalkは環境作成やデプロイの際に設定ファイルを読み取り、パッケージの導入、ファイルの配置、コマンドの実行、環境オプションの設定などを行います。

よく使う設定セクションには次のものがあります。

セクション	用途
packages	OSのパッケージ管理機構を使って必要なパッケージをインストールする
sources	アーカイブなどのソースをダウンロードして展開する
files	インスタンス上に設定ファイルやスクリプトなどを配置し、内容や権限を指定する
commands	アプリケーションの展開前など、環境のセットアップ時にシェルコマンドを実行する
container_commands	アプリケーションのステージング後、デプロイ前にアプリケーション配置に関連するコマンドを実行する
option_settings	Elastic Beanstalkの名前空間に属する環境設定値を宣言する

たとえば、共通のログ転送パッケージを導入し、設定ファイルを所定の場所へ置いてサービスを起動する処理を設定ファイルにまとめれば、環境を作り直したときにも同じ構成を再現できます。インスタンスに手作業で設定して終わりにするより、設定をアプリケーションと一緒にバージョン管理することで、環境間の差や再構築漏れを減らせます。

.ebextensionsはElastic Beanstalkに環境設定やリソース作成を指示する設定形式です。CloudFormationの設定ファイルと同じものではありませんが、Elastic Beanstalkの背後ではCloudFormationスタックが環境のリソース管理に使われます。シェルコマンドによる変更はOSやプラットフォームのバージョンに依存することがあるため、対象環境で検証し、繰り返し適用できる内容に保ちます。パスワードやAPIキーなどの秘密情報をソースバンドルへ直接書かず、実行時に安全な仕組みから取得する設計も必要です。

アプリケーションのデプロイ方式

Elastic Beanstalkのデプロイポリシーは、新しいアプリケーションバージョンを環境へ展開する方法を決めます。選択肢によって、更新中に維持できる処理容量、デプロイに必要な追加リソース、失敗時の戻しやすさが異なります。

方式	更新の進め方	容量・運用上の特徴
All at once	環境内のインスタンスをまとめて更新する	最短で展開しやすい一方、更新中にアプリケーションが応答できない時間が発生し得る。小規模な開発環境など、停止を許容できる場合に向く
Rolling	インスタンスを指定したバッチに分け、順番に更新する	更新中のバッチをサービスから外すため、残りのインスタンスが処理を続ける。更新中は利用可能な容量が一時的に減る
Rolling with additional batch	最初に追加のインスタンスバッチを起動して新バージョンを配置し、その後に既存インスタンスをバッチ単位で置き換える	追加バッチを先に用意するため、通常のRollingで生じる容量低下を避けながら更新できる。更新中は一時的にインスタンス数と費用が増える
Immutable	新しいAuto Scalingグループに新バージョンのインスタンスを起動し、正常性を確認してから既存グループと切り替える	既存インスタンスを残したまま新しい環境を検証できる。失敗時は新しいグループを破棄して旧環境を維持しやすいが、展開中の追加容量が必要
Traffic splitting	新バージョンの一時的なインスタンス群へリクエストの一部を流し、設定した評価期間を経てトラフィックを切り替える	Application Load Balancerを使うロードバランサー環境で利用する。実トラフィックを使って新バージョンを段階的に確認でき、問題があれば切り替えを中止する

Rollingと追加バッチの違い

Rollingでは更新対象のバッチをロードバランサーなどから切り離してから更新します。残りのバッチがリクエストを処理しますが、環境全体のインスタンス数が変わらないままなら、更新中は処理能力が小さくなります。負荷の高い時間帯にデプロイすると、残ったインスタンスへ負荷が集中する可能性があります。

Rolling with additional batchでは、既存のバッチに手を付ける前に、新バージョン用の追加バッチを一つ起動します。この追加分が新しいバージョンで稼働してから、元のインスタンスを順番に置き換えるため、更新中も元の環境規模に相当する処理容量を保ちやすくなります。その代わり、デプロイ中には元の台数を超えるインスタンスが一時的に必要です。容量を保つ選択肢であって、追加コストや追加インスタンス上限が不要になるわけではありません。

ImmutableとTraffic splitting

Immutableは、新バージョン用のインスタンスを現在のインスタンスとは別のAuto Scalingグループに用意する方式です。新しいグループのヘルスチェックが成功した後に切り替えるため、ローリング更新より新旧バージョンを分離しやすく、問題があれば新しいグループを削除して旧バージョンを残せます。

Traffic splittingも新しいバージョンを別のインスタンス群へデプロイしますが、いきなり全トラフィックを切り替えず、指定した割合のリクエストを一定時間流して評価する点が特徴です。Application Load Balancerを使うロードバランサー環境で利用し、新バージョンのエラー率や応答を確認してから移行を完了できます。評価中に必要となる追加容量も見積もります。

Blue/Greenデプロイとの区別

Blue/Greenは、既存環境（Blue）を動かしたまま別の環境（Green）を作って新バージョンを検証し、問題がなければDNS名を切り替える環境単位のリリース方式です。Elastic Beanstalkでは環境を複製して新バージョンをデプロイし、CNAMEスワップでトラフィック先を切り替える方法があります。

Rolling、Immutableなどが一つの環境に対する環境内デプロイポリシーであるのに対し、Blue/Greenでは独立した二つの環境を運用して切り替えます。Blue/Greenは迅速な切り戻しがしやすい一方、切り替え前後に二つの環境を維持する費用や、データベーススキーマなどの互換性を考慮します。

デプロイ方式の考え方はECSやLambdaでも使われますが、具体的な設定項目や切り替え機構はサービスごとに異なります。Elastic Beanstalkでのバッチ更新を、ECSやLambdaでも同じ操作で設定できるという意味ではありません。

要件に応じた選び方

デプロイポリシーは「どれが最も安全か」だけで決めるのではなく、必要な稼働容量と許容できる停止時間を先に確認します。検討時には次の観点を組み合わせます。

• 停止を許容でき、短時間で展開したい: All at onceを検討する。停止が起こり得るため、本番の常時稼働要件には合うかを確認する。
• 追加容量を抑えながら少しずつ更新したい: Rollingを使う。バッチサイズと更新中の残存容量で、ピーク負荷を処理できるかを計算する。
• 更新中も元の処理容量を維持したい: Rolling with additional batchを選択肢にする。追加インスタンス分の容量と料金を確保する。
• 新旧を分離して正常性を確かめてから切り替えたい: Immutableを検討する。デプロイ中に新しいインスタンス群を追加できる必要がある。
• 実際のリクエストを一部だけ新バージョンへ流して評価したい: 条件を満たす環境でTraffic splittingを検討する。
• 独立した新環境を十分に検証し、環境単位で切り替えたい: Blue/Greenを選ぶ。CNAME切り替え、二重環境の費用、データ互換性、切り戻し計画を準備する。

試験で押さえるポイント

問題文に「コードをアップロードするだけで、基盤構築やデプロイを簡略化する」とあればElastic Beanstalkが候補です。利用者が完全な基盤を意識しなくてよいという意味ではなく、Elastic BeanstalkがEC2やロードバランサーなどを組み合わせて環境を作り、利用者がその設定とアプリケーションを運用します。

非同期処理の要件では、Webサーバー環境がAWS SDKなどを介してSQSへメッセージを送り、Worker環境のEC2インスタンス上にあるデーモンがポーリングしてアプリケーションへ渡す流れを想起します。長いタスクをWebリクエスト処理から切り離せますが、失敗時の再試行や重複処理に対する責任はアプリケーション側に残ります。

ローリングデプロイの選択肢では、Rollingは更新中に一時的な容量低下が起こり得ること、Rolling with additional batchは先に追加バッチを起動するため既存規模の容量を保ちやすいことを区別します。容量確保や切り戻しをより重視するならImmutable、段階的な実トラフィック評価が必要ならTraffic splitting、環境そのものを切り替える要件ならBlue/Greenを検討します。

公式ドキュメント

• AWS Elastic Beanstalk デベロッパーガイド
• Elastic Beanstalkのアーキテクチャ
• 環境層の管理とWorker環境
• .ebextensionsによる高度な環境カスタマイズ
• アプリケーションのデプロイポリシー
• Elastic Beanstalkの料金