Elastic Beanstalkとは
Elastic Beanstalkは、Java、.NET、PHP、Node.js、Python、Ruby、Go などを使用して開発されたプログラムをApache、Nginx、Passenger、IIS など使い慣れたサーバーでデプロイおよびスケーリングするためのサービス。インフラストラクチャの準備、運営から、アプリケーションスタック (プラットフォーム) の管理までをElastic Beanstalkが担当するため、ネットワーク設定や保守などの作業が不要。
All at Once、ローリング、追加バッチとローリング、イミュータブル、ブルー/グリーンなどの複数のポリシーからデプロイ方法を選択可能である。
Elastic Beanstalkを使用するにあたっての利用料金は不要で、デプロイしたAWSリソースに対する通常の使用料金のみ課金される。
使用するAWSリソースとその機能について、十分な知識を有する場合は、CloudFormationテンプレートを作成して運用することが望ましい。
Elastic Beanstalkは、複数のアプリケーションを作成することが可能で、各アプリケーションは、Application Version、Environment（デプロイ済みのアプリケーション）やEnvironment Tier（Environmentの種別）、Environment Configuration（Environmentの設定）を有する。
Application Version
デプロイ可能なコードを指し、S3上でバージョン管理される。
Environment Tier
HTTP リクエストを処理し、ウェブアプリケーションを実行可能なWebサーバ環境と、Amazon SQSキューからタスクを引き出し、バッチ処理などをスケーラブルに実行可能なワーカー環境の2つから選択することが可能である。
Webサーバ環境
Webサーバ環境で構築されるEC2のソフトウェアスタックは、選択したコンテナタイプ（テンプレート）によって異なる。また、ホストマネージャー（HM）と呼ばれるソフトウェアコンポーネントも実行され、アプリケーションのデプロイの実行や、アプリケーションの監視等も行なっている。
ワーカー環境
完了するまでに長い時間がかかる処理は、SQSを用いたワーカー環境で実行することが望ましい。ワーカー環境では、Amazon SQS キューを管理しタスクを実行するSQSデーモンが実行される。また、cron.yamlにタスクを記述することで、タスクの定期実行を行うことも可能である。
設計上の注意事項
スケーラビリティを確保する方法として、スケールアップ（垂直スケーリング）とスケールアウト（水平スケーリング）が存在が、スケールアップは過剰なリソースの準備となるなど問題点が存在するため、Elastic Beanstalkアプリケーションは、必要に応じてスケールアウトできる耐障害性に優れた疎結合コンポーネントを使用して、できるだけステートレスにする必要がある。
また、耐障害性を有するように、必ず故障から自動回復できるように設計、実装、およびデプロイする必要がある。
アプリケーションの管理
ソースコードをアップロードするたびに、新たなバージョンラベルを付与し、アプリケーションバージョンを作成する。古いアプリケーションバージョンは削除することも可能で、削除してもデプロイ済みのEnvironmentには影響を与えない。
アプリケーションバージョンライフサイクルポリシーを設定することで、過去のバージョンを自動的に削除することが可能である。保有するバージョンの数、もしくは期間を設定でき、これを超えるとサービスが自動でアプリケーションバージョンを削除する。
アプリケーションは、ソースバンドルと呼ばれる処理プログラムを含む必要があり、ソースバンドルは、単一のZIPファイルまたはWARファイルで構成される必要がある。AWS Toolkit for Eclipse等を使用して開発を行なっている場合は、ツールが正しく構造化した上でZIP化してくれる。
Environmentの管理
1つのアプリケーションは、開発環境、統合環境、本番環境など複数のEnvironmentをデプロイすることができる。新たなEnvironmentを作成する場合は、
- プラットフォーム
- Application Version もしくは 新たなソースバンドル
- Environment Tier（ウェブ環境/ワーカー環境）
等を指定する。作成したEnvironmentを終了すると、デプロイしたリソースの全てが削除される。
デプロイ
Environmentをデプロイする際には、複数のデプロイ方法の中から1つを選択することが可能である。
| 方法 | デプロイメントポリシー | 内容 | 制約 | 時間 | ダウンタイム | DNS変更 |
|---|---|---|---|---|---|---|
| All at Once | All at Once | 現行のインスタンス全てに新たなコードを適用する | 速 | 有 | 無 | |
| Rolling | Rolling | 現行のインスタンスに順に新たなコードを適用する | 単一インスタンス環境では選択できない | やや速 | 無 | 無 |
| Rolling with additional batch | Rolling with additional batch | 新たなインスタンスと現行のインスタンスの一部に新たなコードを適用する | 単一インスタンス環境では選択できない | 中 | 無 | 無 |
| Immutable | Immutable | 新たなインスタンスに新たなコードを適用する | 遅 | 無 | 無 | |
| Blue/Green | Rolling with additional batch もしくは Immutable | 新たなインスタンス（と現行のインスタンスの一部）に新たなコードを適用する | 単一インスタンス環境では選択できない | 遅 | 無 | URL Swap もしくは DNS切り替え |
Rollingを用いてデプロイする場合は、更新するバッチサイズを指定する。また、Route53の加重ラウンドロビンを利用することで、新バージョンを徐々に適用していくことも可能である。
プラットフォームの更新
アプリケーションを実行しているプラットフォームの更新を定期的に、もしくは手動で行うことが可能である。また、マイナーアップデートを含めるのか、パッチの適用だけなのかについても選択することができる。