Elastic Beanstalk 環境へのアプリケーションのデプロイ

AWS Elastic Beanstalk コンソールを使用して、更新したソースバンドルをアップロードして Elastic Beanstalk 環境にデプロイするか、以前にアップロードしたバージョンを再デプロイできます。

各デプロイはデプロイ ID で識別されます。デプロイ ID は 1 から始まり、デプロイするか、インスタンスの設定を変更するたびに、1 ずつ増えます。Elastic Beanstalk では、拡張ヘルスレポートを有効にした場合、インスタンスのヘルスステータスのレポート時に、ヘルスコンソールと EB CLI の両方でデプロイ ID が表示されます。デプロイ ID は、ローリング更新が失敗したときにお客様の環境の状態を調べるために役立ちます。

Elastic Beanstalk には、いくつかのデプロイポリシーと設定が用意されています。ポリシーの設定と追加設定の詳細については、「デプロイポリシーと設定」を参照してください。以下の表では、ポリシーとそのポリシーをサポートする環境の種類を示しています。

サポートされているデプロイメントポリシー
デプロイメントポリシー	負荷分散された環境	単一インスタンス環境	レガシー Windows サーバー環境†
All at once	はい	はい	はい
ローリング	はい	☓いいえ	はい
Rolling with an additional batch (追加バッチによるローリング)	はい	☓いいえ	☓いいえ
イミュータブル	はい	はい	☓いいえ
Traffic splitting (トラフィック分割)	はい (Application Load Balancer)	☓いいえ	☓いいえ

† この表では、レガシー Windows Server 環境は、IIS 8.5 より前の IIS バージョンを使用する Windows Server プラットフォーム設定に基づいています。

警告

一部のポリシーでは、デプロイ時または更新時にすべてのインスタンスが置き換えられます。これにより、累積したすべての Amazon EC2 バーストバランスが失われます。次の場合に発生します。

• インスタンスの置換を有効にしたマネージドプラットフォームの更新

• イミュータブルな更新

• イミュータブルな更新またはトラフィック分割を有効にしたデプロイ

デプロイポリシーの選択

アプリケーションに適切なデプロイポリシーを選択することは、いくつかの考慮事項のトレードオフであり、特定のニーズに左右されます。「デプロイポリシーと設定」ページには、各ポリシーについての詳細情報があり、一部のポリシーについては仕組みが詳しく説明されています。

以下のリストには、さまざまなデプロイポリシーについての概要情報があり、関連する考慮事項が追加されています。

• All at once (一度にすべて) - 最も迅速なデプロイ方法。サービスの短期間の停止が許容され、迅速なデプロイが重要である場合に適しています。この方法では、Elastic Beanstalk は新しいアプリケーションバージョンを各インスタンスにデプロイします。その後、ウェブプロキシまたはアプリケーションサーバーを再起動する必要があります。したがって、ユーザーがアプリケーションを短時間使用できなくなる (可用性が低くなる) ことがあります。

• Rolling (ローリング) - ダウンタイムを回避し、可用性の低下を最小限に抑えます。ただし、デプロイ時間は長くなります。サービスの完全停止期間が許容されない場合に適しています。この方法では、アプリケーションはお客様の環境で一度に 1 バッチのインスタンスにデプロイされます。ほとんどの帯域幅はデプロイ全体で保持されます。

• Rolling with additional batch (追加バッチによるローリング) - 可用性の低下を回避します。ただし、[Rolling (ローリング)] 方法よりもデプロイ時間が長くなります。デプロイ全体で同じ帯域幅を保持する必要がある場合に適しています。この方法では、Elastic Beanstalk はインスタンスの追加バッチを起動し、ローリングデプロイを実行します。追加バッチの起動に時間をかけることで、デプロイ全体で同じ帯域幅が確実に保持されます。

• Immutable (イミュータブル) - 低速のデプロイ方法。既存のインスタンスを更新するのではなく、常に新しいアプリケーションバージョンを新しいインスタンスにデプロイします。また、デプロイが失敗した場合に迅速かつ安全にロールバックできるという追加の利点もあります。この方法では、Elastic Beanstalk はイミュータブルな更新を実行してアプリケーションをデプロイします。イミュータブルな更新では、環境内で 2 番目の Auto Scaling グループが起動し、新しいインスタンスがヘルスチェックに合格するまで、新しいバージョンが旧バージョンと並行してトラフィックを提供します。

• Traffic splitting (トラフィック分割) - Canary テストのデプロイ方法。受信トラフィックの一部を使用して新しいアプリケーションバージョンのヘルスをテストしながら、残りのトラフィックを古いアプリケーションバージョンで処理され続けるようにする場合に適しています。

以下の表は、デプロイ方法のプロパティを比較したものです。

デプロイ方法
方法	デプロイ失敗の影響	デプロイ所要時間	ゼロダウンタイム	DNS の変更なし	ロールバックプロセス	コードのデプロイ先
All at once	ダウンタイム		☓いいえ	はい	手動再デプロイ	既存のインスタンス
ローリング	サービス停止状態の単一のバッチ。新しいアプリケーションバージョンを実行している、失敗前のすべてのバッチ。	†	はい	はい	手動再デプロイ	既存のインスタンス
Rolling with an additional batch (追加バッチによるローリング)	最初のバッチが失敗した場合、影響は最小限。それ以外の場合は [ローリング] と類似。	†	はい	はい	手動再デプロイ	新規および既存のインスタンス
イミュータブル	最小限		はい	はい	新しいインスタンスの終了	新規のインスタンス
Traffic splitting (トラフィック分割)	新しいバージョンにルーティングされて一時的に影響を受けたクライアントトラフィックの割合	††	はい	はい	トラフィックの再ルーティングと新しいインスタンスの終了	新規のインスタンス
Blue/Green	最小限		はい	☓いいえ	URL のスワップ	新規のインスタンス

† バッチサイズにより異なります。

†† [evaluation time (評価時間)] オプションの設定によって異なります。

新しいアプリケーションバージョンのデプロイ

環境のダッシュボードからデプロイを実行できます。

新しいアプリケーションバージョンを Elastic Beanstalk 環境にデプロイするには

1. Elastic Beanstalk コンソールを開き、[Regions] (リージョン) リストで AWS リージョンを選択します。

2. ナビゲーションペインで、[環境] を選択し、リストから環境の名前を選択します。

   注記

   環境が多数ある場合は、検索バーを使用して環境リストをフィルタリングします。

3. [アップロードとデプロイ] を選択します。

4. 画面上のフォームを使用して、アプリケーションソースバンドルをアップロードします。

5. [Deploy‬] (デプロイ) をクリックします。

以前のバージョンの再デプロイ

アプリケーションの以前にアップロードしたバージョンを、アプリケーションのバージョンのページからその環境のいずれかにデプロイできます。

既存のアプリケーションバージョンを既存の環境にデプロイするには

1. Elastic Beanstalk コンソールを開き、[Regions] (リージョン) リストで AWS リージョンを選択します。

2. ナビゲーションペインで、[アプリケーション] を選択し、リストからアプリケーションの名前を選択します。

   注記

   多数のアプリケーションがある場合は、検索バーを使用してアプリケーションのリストをフィルタリングします。

3. ナビゲーションペインで、アプリケーション名を見つけ、[アプリケーションバージョン] を選択します。

4. デプロイするアプリケーションバージョンを選択します。

5. [アクション]、[デプロイ] の順に選択します。

6. 環境を選択してから、[デプロイ] を選択します。

アプリケーションをデプロイするその他の方法

頻繁にデプロイする場合は、Elastic Beanstalk コマンドラインインターフェイス (EB CLI) を使用してお客様の環境を管理することを検討してください。EB CLI では、ソースコードと共にリポジトリを作成します。また、1 つのコマンドで、ソースバンドルを作成し、Elastic Beanstalk にアップロードして、デプロイすることもできます。

リソースの設定変更や、旧バージョンと同時に実行できない新しいバージョンに依存するデプロイの場合、新しいバージョンで新しい環境を起動し、ブルー/グリーンデプロイ 向けに CNAME スワップを実行します。