デプロイポリシーと設定 - AWS Elastic Beanstalk

デプロイポリシーと設定

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

rolling deployments (ローリングデプロイ) では、Elastic Beanstalk はお客様の環境の Amazon EC2 インスタンスをバッチに分割し、アプリケーションの新しいバージョンを一度に 1 バッチのインスタンスにデプロイします。残りのインスタンスは、お客様の環境でアプリケーションの古いバージョンを実行し続けます。つまりローリングデプロイ中は、アプリケーションの古いバージョンでリクエストを処理するインスタンスもあり、新しいバージョンでリクエストを処理するインスタンスも存在します。詳細については、「ローリングデプロイの仕組み」を参照してください。

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

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

[Traffic-splitting deployments (トラフィック分割デプロイ)] では、アプリケーションのデプロイの一部として Canary テストを実施できます。Elastic Beanstalk は、トラフィック分割デプロイ時に、変更不可のデプロイ時と同様に、新しいインスタンスのフルセットを起動します。次に、指定された評価期間にわたり、指定された割合の受信クライアントトラフィックを新しいアプリケーションバージョンに転送します。新しいインスタンスが正常である限り、Elastic Beanstalk はすべてのトラフィックを新しいインスタンスに転送し、古いインスタンスを終了します。新しいインスタンスがヘルスチェックに合格しなかったり、デプロイの中止が選択されたりすると、Elastic Beanstalk はトラフィックを古いインスタンスに戻し、新しいインスタンスを終了します。サービスが中断されることはありません。詳細については、「トラフィック分割デプロイの仕組み」を参照してください。

警告

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

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

  • イミュータブルな更新

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

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

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

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

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

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

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

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

    注記

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

  3. ナビゲーションペインで、[設定] を選択します。

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

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

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

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

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

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

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

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

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

    • [Traffic splitting (トラフィック分割)] – アプリケーションの新しいバージョンをインスタンスの新しいグループにデプロイし、受信クライアントトラフィックをアプリケーションの既存のバージョンと新しいバージョンとの間で一時的に分割します。

[Rolling (ローリング)] および [Rolling with additional batch (追加バッチによるローリング)] デプロイポリシーでは、以下を設定できます。

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

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

[Traffic splitting (トラフィック分割)] デプロイポリシーでは、以下を設定できます。

  • [Traffic split (トラフィック分割)] – デプロイする新しいアプリケーションバージョンを実行している環境インスタンスに Elastic Beanstalk がシフトする受信クライアントトラフィックの初期の割合。

  • [Traffic splitting evaluation time (トラフィック分割評価時間)] – 初回のデプロイが正常に完了してから、デプロイする新しいアプリケーションバージョンにすべての受信クライアントトラフィックをシフトするまで、Elastic Beanstalk が待機する時間 (分単位)。


        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 ではそれらのインスタンスが、成功した最新のデプロイのアプリケーションバージョンを実行中のインスタンスに置き換えられます。

トラフィック分割デプロイの仕組み

トラフィック分割デプロイでは、Canary テストを実施できます。一部の受信クライアントトラフィックを新しいアプリケーションバージョンに転送して、そのアプリケーションの状態を確認してから、その新しいバージョンにコミットし、すべてのトラフィックを転送します。

トラフィック分割デプロイ中に、Elastic Beanstalk は別の一時的な Auto Scaling グループに新しいインスタンスのセットを作成します。続いて、Elastic Beanstalk は環境の受信トラフィックの特定の割合を新しいインスタンスに転送するようにロードバランサーに指示します。その後、設定された期間、Elastic Beanstalk はインスタンスの新しいセットのヘルスを追跡します。ここまで問題がなければ、Elastic Beanstalk は残りのトラフィックを新しいインスタンスにシフトし、それらのインスタンスを環境の元の Auto Scaling グループにアタッチして、古いインスタンスを置き換えます。次に、Elastic Beanstalk が古いインスタンスをクリーンアップ (終了) し、一時的な Auto Scaling グループを削除します。

注記

環境の容量は、トラフィック分割デプロイ中に変化しません。Elastic Beanstalk は、デプロイの開始時に元の Auto Scaling グループにあるインスタンスと同数のインスタンスを Auto Scaling グループに起動します。その後、デプロイ期間中、両方の Auto Scaling グループのインスタンスが一定数に保たれます。環境のトラフィック分割評価時間を設定するときは、以下のことを考慮してください。

以前のアプリケーションバージョンへのデプロイのロールバックは迅速であり、クライアントトラフィックへのサービスには影響しません。新しいインスタンスがヘルスチェックに合格しなかったり、デプロイの中止が選択されたりすると、Elastic Beanstalk はトラフィックを古いインスタンスに戻し、新しいインスタンスを終了します。Elastic Beanstalk コンソールの環境概要ページを使用し、[Environment actions (環境のアクション)] で [Abort current operation (現在のオペレーションを中止)] を選択することで、デプロイを中止できます。AbortEnvironmentUpdate API または同等の AWS CLI コマンドを呼び出すこともできます。

トラフィック分割デプロイには Application Load Balancer が必要です。Elastic Beanstalk では、Elastic Beanstalk コンソールまたは EB CLI を使用して環境を作成するときに、デフォルトでこのロードバランサータイプが使用されます。

デプロイオプションの名前空間

aws:elasticbeanstalk:command 名前空間にある設定オプションを使用して、デプロイを設定できます。トラフィック分割ポリシーを選択した場合、このポリシーの追加のオプションが aws:elasticbeanstalk:trafficsplitting 名前空間で使用できます。

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

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

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

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

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

  • TrafficSplitting – トラフィック分割デプロイを実行して、アプリケーションのデプロイの Canary テストを実施します。

ローリングデプロイを有効にした場合は、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"

トラフィック分割デプロイを実行し、クライアントトラフィックの 15% を新しいアプリケーションバージョンに転送して、10 分間にわたってヘルスを評価するには、以下のオプションと値を指定します。

例 .ebextensions/traffic-splitting.config

option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: TrafficSplitting aws:elasticbeanstalk:trafficsplitting: NewVersionPercent: "15" EvaluationTime: "10"

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