AWS Elastic Beanstalk
開発者ガイド

デプロイポリシーと設定

AWS Elastic Beanstalk は、デプロイポリシーも含めデプロイを処理するいくつかのオプションを提供します ([All at once]、[Rolling]、[Rolling with additional batch]、[Immutable])。これらのオプションによって、バッチサイズやデプロイ中のヘルスチェックの動作を設定できます。デフォルトでは、環境は一括デプロイを使用します。EB CLI で環境を作成し、それが自動スケーリング環境である (--single オプションを指定していない) 場合は、ローリングデプロイが使用されます。

[Rolling] (ローリング) デプロイでは、Elastic Beanstalk は環境の EC2 インスタンスを複数のバッチに分割し、アプリケーションの新しいバージョンを一度に 1 つのバッチにデプロイするため、環境内の残りのインスタンスは古いアプリケーションバージョンを実行した状態になります。つまりローリングデプロイ中は、アプリケーションの古いバージョンでリクエストを処理するインスタンスもあり、新しいバージョンでリクエストを処理するインスタンスも存在します。

デプロイ中に総容量を維持するには、インスタンスがサービス停止になる前に、インスタンスの新しいバッチを起動するよう環境を設定できます。このオプションは、追加バッチのローリングデプロイと呼ばれます。デプロイが完了すると、Elastic Beanstalkがインスタンスの追加バッチを終了します。

[Immutable] デプロイは、変更不可能な更新を実行して、古いバージョンを起動しているインスタンスと並行しながら、別の Auto Scaling グループにあるアプリケーションの新しいバージョンを起動している新しいインスタンスのフルセットを起動します。[Immutable] デプロイは、部分的に完了したローリングデプロイにより発生する問題を防止できます。新しいインスタンスがヘルスチェックをパスしなかった場合、Elastic Beanstalkはそれを終了し、元のインスタンスをそのまま残します。

アプリケーションがすべてのヘルスチェックにパスしないものの、低いヘルスステータスで正しく起動する場合、インスタンスがパスできるヘルスチェックのステータスを、Warning のような低いものに [Healthy threshold] オプションを使って変更し、パスさせることができます。ヘルスチェックをパスできずにデプロイに失敗し、ヘルスステータスに関係なく強制的に更新する必要がある場合は、[Ignore health check] オプションを選択してヘルスチェックを無視します。

ローリング更新のバッチサイズを指定すると、Elastic Beanstalk もまたローリングアプリケーション再起動の際にその値を使用します。ダウンタイムなしに、環境のインスタンスで実行しているプロキシおよびアプリケーション サーバーの再起動が必要な場合は、ローリング再起動を使用します。

アプリケーションデプロイの設定

環境マネジメントコンソールで、バッチ処理されるアプリケーションバージョンのデプロイの有効化や設定を行うには、環境の [Configuration] ページにある [Updates and Deployments] を編集します。

デプロイ (コンソール) を設定する

  1. Elastic Beanstalk コンソール を開きます。

  2. お客様の環境の管理ページに移動します。

  3. [Configuration] を選択します。

  4. [ローリング更新とデプロイ] 設定カテゴリで [変更] を選択します。

  5. [アプリケーションのデプロイ] セクションで、[デプロイメントポリシー]、バッチ設定、ヘルスチェックオプションを選択します。

  6. [Apply] を選択します。

[ローリング更新とデプロイ] ページの [アプリケーションのデプロイ] セクションには、ローリング更新の以下のオプションがあります。

  • [Deployment policy] – 次のデプロイオプションから選択します。

    • [All at once] – 同時にすべてのインスタンスに新しいバージョンをデプロイします。環境内のすべてのインスタンスは、デプロイが実行される間、短時間ですがサービス停止状態になります。

    • [Rolling] – バッチに新しいバージョンをデプロイします。デプロイフェーズ中、バッチはサービス停止状態になり、バッチのインスタンスによる環境容量への負荷を低減します。

    • [Rolling with additional batch] – バッチに新しいバージョンをデプロイしますが、デプロイ中に総容量を維持するため、インスタンスの新しいバッチをまず起動します。

    • [Immutable] – 変更不可能な更新を実行し、新しいバージョンをインスタンスの新しいグループにデプロイします。

  • [バッチサイズ] – 各バッチでデプロイする一連のインスタンスのサイズ。

    Auto Scaling グループ (最大 100%) で EC2 インスタンスの総数の割合を構成するには、[Percentage] を選択するか、[Fixed] を選択して固定数のインスタンスを構成します (環境の Auto Scaling 設定の最大インスタンス数まで)。


        Elastic Beanstalk アプリケーションデプロイの設定ページ

[Deployment preferences] セクションには、ヘルスチェック関連のオプションが含まれています。

  • [Ignore health check] – バッチが [Command timeout] の時間内に正常な状態にならなかった場合に、デプロイがロールバックするのを防ぎます。

  • [Healthy threshold] – ローリングデプロイやローリング更新、変更不可能な更新中に、インスタンスが正常と見なされるしきい値を引き下げます。

  • [Command timeout] – デプロイがキャンセルされるまで、または [Ignore health check] が設定されている場合は次のバッチの処理に移るまで、インスタンスが正常な状態になるために待機する秒数。


        Elastic Beanstalk アプリケーションのデプロイの設定ページ

ローリングデプロイの仕組み

バッチを処理する際、Elastic Beanstalk はバッチ内のすべてのインスタンスをロードバランサーからデタッチし、新しいアプリケーションバージョンをデプロイしてから、再アタッチします。Connection Draining が有効になっていると、Elastic Beanstalk は、デプロイを開始する前に、Amazon EC2 インスタンスから既存の接続をストリーミングします。

バッチ内のインスタンスがロードバランサーに再アタッチされると、Elastic Load Balancing は、これらのインスタンスが最小限の数の Elastic Load Balancing ヘルスチェック ([Healthy check count threshold] の値) に合格するのを待ってから、これらのインスタンスへのトラフィックのルーティングを開始します。ヘルスチェック URL が設定されていなければ、これはすぐに発生する可能性があります。インスタンスが TCP 接続を受け付けるとすぐにヘルスチェックに合格するからです。ヘルスチェック URL が設定されていると、200 OK ステータスコードがヘルスチェック URL への HTTP GET リクエストの応答として返されるまで、ロードバランサーはトラフィックを更新されたインスタンスにルーティングしません。

Elastic Beanstalk は、バッチ内のすべてのインスタンスが正常な状態になるまで待ち、その後に次のバッチを処理します。基本ヘルスレポートでは、インスタンスの状態は Elastic Load Balancing ヘルスチェックステータスに依存しています。バッチ内のすべてのインスタンスが、Elastic Load Balancing によって正常な状態であると見なされるために十分な数のヘルスチェックに合格すると、バッチは正常であると認められます。拡張ヘルスレポートが有効になっていると、Elastic Beanstalk はいくつかの他の要因 (着信リクエストの結果など) も考慮します。ウェブサーバー環境の拡張ヘルスレポートでは、すべてのインスタンスが 2 分間にわたって連続して行われる 12 のヘルスチェック (ワーカー環境の場合は 3 分間にわたって 18 のヘルスチェック) に OK ステータスで合格する必要があります。

インスタンスのバッチがコマンドタイムアウト内に正常にならない場合、デプロイは失敗します。デプロイの失敗後、失敗の原因については、お客様の環境内のインスタンスのヘルスを確認してください。次に、アプリケーションの固定または既知の適切なバージョンを使用して別のデプロイメントを実行して、ロールバックします。

1 つ以上のバッチが正常に完了した後にデプロイが失敗した場合、完了したバッチはアプリケーションの新しいバージョンを実行する一方で、保留中のバッチは古いバージョンを実行し続けます。コンソールの [Health] ページで、お客様の環境内のインスタンスで実行されているバージョンを特定できます。このページには、お客様の環境内の各インスタンスで実行されている最新のデプロイのデプロイ ID が表示されます。失敗したデプロイのインスタンスを終了した場合、Elastic Beanstalk ではそれらのインスタンスが、成功した最新のデプロイのアプリケーションバージョンを実行中のインスタンスに置き換えられます。

aws: elasticbeanstalk: コマンド名前空間

また、aws:elasticbeanstalk:command 名前空間にある 設定オプションを使用して、ローリングデプロイを設定できます。

DeploymentPolicy オプションを使用して、デプロイの種類を設定します。サポートされる値は次のとおりです。

  • AllAtOnce – ローリングデプロイを無効にし、常に同時にすべてのインスタンスにデプロイを実行します。

  • Rolling – 標準的なローリングデプロイを有効にします。

  • RollingWithAdditionalBatch – 総容量を維持するために、デプロイ開始前にインスタンスの追加バッチを起動します。

  • Immutable – すべてのデプロイ時に変更不可能な更新を実行します。

ローリングデプロイを有効にした場合は、BatchSize オプションと BatchSizeType オプションも設定して各バッチサイズを設定します。たとえば、各バッチのすべてのインスタンスの 25 パーセントをデプロイするには、次のオプションと値を指定します。

例 .ebextensions/rolling-updates.config

option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: Rolling BatchSizeType: Percentage BatchSize: 25

実行中のインスタンスの数に関係なく、バッチごとに 5 つのインスタンスにデプロイを実行し、サービス停止状態のすべてのインスタンスをプルする前に、新しいバージョンを実行している 5 つのインスタンスの追加バッチを起動するには、次のオプションを値を指定します。

例 .ebextensions/rolling-additionalbatch.config

option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: RollingWithAdditionalBatch BatchSizeType: Fixed BatchSize: 5

ヘルスチェックしきい値が [Warning] の各デプロイに変更不可能な更新を実行し、バッチのインスタンスが 15 分のタイムアウト時間内にヘルスチェックにパスできなかったとしても、デプロイを実行するには、次のオプションと値を指定します。

例 .ebextensions/immutable-ignorehealth.config

option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: Immutable HealthCheckSuccessThreshold: Warning IgnoreHealthCheck: true Timeout: "900"

EB CLI および Elastic Beanstalk コンソール は、上記のオプションの推奨値を適用します。設定ファイルを使用して同じファイルを設定する場合は、これらの設定を削除する必要があります。詳細については、「推奨値」を参照してください。