Elastic Beanstalk 環境設定のローリング更新

設定変更にインスタンスの置き換えが必要な場合、Elastic Beanstalk はバッチ単位で更新を実行することで、変更の適用中のダウンタイムを回避できます。ローリング更新中、容量は 1 バッチのサイズ分だけ減ります。バッチのサイズはお客様が設定できます。Elastic Beanstalk は、停止中のインスタンスのバッチを 1 つ選んで終了させ、新しい設定のバッチを起動します。新しいバッチがリクエストの処理を開始すると、Elastic Beanstalk は次のバッチに進みます。

ローリング設定更新のバッチは、バッチ間に一定の時間間隔を設定して定期的 (時間ベース) に処理することも、状態に基づいて処理することもできます。時間ベースのローリング更新の場合、インスタンスのバッチの起動が完了して、次のバッチに移動するまで Elastic Beanstalk が待機する時間を設定できます。この一時停止の時間によって、アプリケーションはブートスロラップおよびリクエスト処理の開始が可能になります。

正常性に基づくローリング更新では、Elastic Beanstalk は、バッチのインスタンスがヘルスチェックに合格するまで待ってから、次のバッチに移ります。インスタンスの状態は、ヘルスレポートシステム (基本または拡張) によって決定されます。基本ヘルスレポートでは、バッチのすべてのインスタンスが Elastic Load Balancing (ELB) ヘルスチェックに合格し、バッチは正常な状態であると見なされます。

拡張ヘルスレポートでは、Elastic Beanstalk が次のバッチを処理する前に、バッチのすべてのインスタンスが複数の連続的なヘルスチェックにパスする必要があります。インスタンスのみを確認する ELB ヘルスチェックに加え、拡張ヘルスは、アプリケーションログと環境のその他のリソースの状態を監視します。拡張ヘルスを使用するウェブサーバー環境では、すべてのインスタンスが 2 分間にわたって行われる 12 のヘルスチェックに合格する必要があります（ワーカー環境では 3 分間にわたって 18 のチェックが行われます）。いずれかのインスタンスが 1 つでもヘルスチェックで不合格になければ、カウントがリセットされます。

バッチがローリング更新のタイムアウト (デフォルトは 30 分) 以内に正常にならなければ、更新はキャンセルされます。ローリング更新のタイムアウトは、aws:autoscaling:updatepolicy:rollingupdate 名前空間で使用できる設定オプションの 1 つです。アプリケーションがヘルスチェックで Ok ステータスにならなくても、別のレベルで安定する場合は、aws:elasticbeanstalk:healthreporting:system 名前空間で HealthCheckSuccessThreshold オプションを設定して、Elastic Beanstalk でインスタンスが正常と見なされるレベルに変更できます。

ローリング更新プロセスが失敗した場合、Elastic Beanstalk は別のローリング更新を開始して、以前の設定にロールバックします。ローリング更新は、ヘルスチェックに不合格になったことが原因で失敗したり、新しいインスタンスの起動によりアカウントのクォータを超えたことが原因で失敗したりすることがあります。例えば、Amazon EC2 インスタンス数のクォータに達すると、新しいインスタンスのバッチをプロビジョンしようとしたときに、ローリング更新は失敗する可能性があります。この場合、ロールバックも失敗します。

ロールバックが失敗すると、更新プロセスは終了し、環境は異常な状態のままとなります。正常に完了したバッチには新しい設定が反映されますが、未処理のバッチでは依然として古い設定でインスタンスが実行されます。ロールバックに失敗した環境を修復するには、まず更新に失敗した根本的な原因を解決します。次に、あらためて環境の更新を開始します。

代わりの方法として、別の環境にアプリケーションの新しいバージョンをデプロイしてから、CNAME スワップを実行して、ダウンタイムなしでトラフィックをリダイレクトすることがあります。詳細については、「Elastic Beanstalk を使用したブルー/グリーンデプロイ」を参照してください。

ローリング更新とローリングデプロイ

ローリング更新が実行されるのは、設定変更に伴い、新しい Amazon EC2 インスタンスをお客様の環境用にプロビジョンすることが必要になるときです。例えば、Auto Scaling グループの設定 (インスタンスタイプとキーペアの設定など) の変更、VPC の設定の変更です。ローリング更新では、インスタンスの各バッチが終了されてから、新しいバッチが置き換え用にプロビジョニングされます。

ローリングデプロイが実行されるのは、毎回、アプリケーションをデプロイするときです。通常、お客様の環境でインスタンスの置き換えなしで実行できます。Elastic Beanstalk は、各バッチをサービスから外し、新しいアプリケーションバージョンをデプロイしてから、サービスに戻します。

ただし例外は、設定の変更に伴い、新しいアプリケーションバージョンをデプロイすると同時にインスタンスを置き換えることが必要になる場合です。たとえば、ソースバンドルにあるキー名設定 (設定ファイル内) を変更し、お客様の環境にデプロイする場合は、ローリング更新がトリガーされます。既存のインスタンスの各バッチに新しいアプリケーションバージョンがデプロイされる代わりに、インスタンスの新しいバッチが新しい設定でプロビジョニングされます。この場合、個別のデプロイは行われません。新しいインスタンスが新しいアプリケーションバージョンで起動されるためです。

新しいインスタンスが環境更新の一部としてプロビジョニングされる場合、アプリケーションのソースコードが新しいインスタンスと、インスタンスが適用されるオペレーティングシステムやソフトウェアを変更するすべての設定にデプロイされるデプロイフェーズがあります。デプロイのヘルスチェック設定 ([Ignore health check] と [Healthy threshold]、[Command timeout]) もデプロイフェーズでローリング更新および変更不可能な更新に基づき、適用されます。

ローリング更新の設定

Elastic Beanstalk コンソールでローリング更新を有効にして設定できます。

ローリング更新を有効にするには

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

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

   注記

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

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

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

5. [Configuration updates (設定の更新)] セクションの [ローリング更新のタイプ] で、いずれかの [ローリング] オプションを選択します。

   

6. [バッチサイズ]、[最小キャパシティー]、[停止時間] の順に選択します。

7. ページの最下部で [適用] を選択し変更を保存します。

[Rolling updates and deployments] (ローリング更新とデプロイ) ページの [Configuration updates] (設定の更新) セクションには、ローリング更新に関する次のオプションがあります。

• Rolling update type – Elastic Beanstalk が、インスタンスのバッチの更新を終え、次のバッチに進むまで待機し、その間インスタンスがブートストラップを終了して、トラフィック処理を開始できるようになります。次のオプションから選択します。

  • Rolling based on Health – 現在のバッチのインスタンスが正常な状態になるまで待ってから、インスタンスを実行状態にし、次のバッチを処理します。

  • Rolling based on Time – 新しいインスタンスを開始して実行状態にし、次のバッチを処理するまでの待機時間を指定します。

  • Immutable – 変更不可能な更新を実行することで、設定変更をインスタンスの新しいグループに適用します。

• Batch size – 各バッチで置き換えるインスタンスの数です。1 ～ 10000 のいずれかの値を指定できます。デフォルトでは、この値は Auto Scaling グループの最小サイズの 1/3 を整数に切り上げた値になります。

• Minimum capacity – 他のインスタンスの更新中に実行され続けるインスタンスの最小数。0 ～ 9999 のいずれかの値を指定できます。デフォルト値は Auto Scaling グループの最小サイズ、または Auto Scaling グループの最大サイズ未満の値のいずれかの低い数値になります。

• Pause time (時間ベースのみ) - バッチが更新されてから次のバッチに移るまでに待つ時間。その間に、アプリケーションがトラフィックの受信を開始できるようになります。0 秒～1 時間のいずれかの値を指定できます。

aws:autoscaling:updatepolicy:rollingupdate 名前空間

また、aws:autoscaling:updatepolicy:rollingupdate 名前空間にある設定オプションを利用してローリング更新を設定できます。

RollingUpdateEnabled オプションを使用してローリング更新を有効にし、更新タイプの選択に RollingUpdateType を使用します。次の値は、RollingUpdateType をサポートします。

• [Health] – 現在のバッチのインスタンスが正常な状態になるまで待ってから、インスタンスを実行状態にし、次のバッチを処理します。

• Time – 新しいインスタンスを起動して、サービス実行状態にし、次のバッチを開始するまでの待機時間を指定します。

• Immutable – 変更不可能な更新を実行することで、設定変更をインスタンスの新しいグループに適用します。

ローリング更新を有効にした場合は、MaxBatchSize オプションと MinInstancesInService オプションも設定してバッチのサイズを設定します。時間ベースと正常性ベースのローリング更新の場合、それぞれ PauseTime および Timeout をそれぞれ設定できます。

たとえば、一度に最大 5 つのインスタンスを起動する場合、少なくとも 2 つのインスタンスを実行状態に維持したままバッチごとに 5 分 30 秒間待機し、次のオプションと値を指定します。

例 .ebextensions/timebased.config

option_settings:
  aws:autoscaling:updatepolicy:rollingupdate:
    RollingUpdateEnabled: true
    MaxBatchSize: 5
    MinInstancesInService: 2
    RollingUpdateType: Time
    PauseTime: PT5M30S

正常性に基づくローリング更新を有効にするには、各バッチにつき 45 分間のタイムアウトで次のオプションと値を指定します。

例 .ebextensions/healthbased.config

option_settings:
  aws:autoscaling:updatepolicy:rollingupdate:
    RollingUpdateEnabled: true
    MaxBatchSize: 5
    MinInstancesInService: 2
    RollingUpdateType: Health
    Timeout: PT45M

[Timeout] と [PauseTime] の値は、ISO8601 duration: PT#H#M#S で指定する必要があります。ここで、各 # はそれぞれ時間、分、秒を指します。

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