翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 設定変更
[環境マネジメントコンソール](environments-console.md)の設定セクションで**設定**オプション設定を変更すると、 は影響を受けるすべてのリソースに変更を AWS Elastic Beanstalk 伝達します。これらのリソースには、お客様のアプリケーションを実行する Amazon EC2 インスタンス、それらのインスタンスを管理する Auto Scaling グループ、EC2 インスタンス自体にトラフィックを分散するロードバランサーが含まれます。
設定変更の多くが、既存のインスタンスを置き換えることなく実行環境に適用できます。たとえば、[ヘルスチェック URL](environments-cfg-clb.md#using-features.managing.elb.healthchecks) を設定すると、環境が更新されロードバランサーの設定が変更されますが、このときダウンタイムは発生しません。これは、アプリケーションを実行しているインスタンスが更新適用中も引き続きリクエストを処理するためです。
[起動設定](command-options-general.md#command-options-general-autoscalinglaunchconfiguration)または [VPC 設定](command-options-general.md#command-options-general-ec2vpc)を変更する設定の変更では、環境内のすべてのインスタンスを終了し置き換える必要があります。たとえば、環境のインスタンスタイプまたは SSH キー設定を変更する場合、EC2 インスタンスを終了し置き換える必要があります。Elastic Beanstalk には、この置き換え方法を決定するいくつかのポリシーが用意されています。
+ **ローリング更新** – このプロセスでダウンタイムが発生しないように、Elastic Beanstalk はこのような設定の変更をバッチで適用し、常に最低限必要なインスタンスを実行してトラフィックを処理します。この方法により、更新プロセス中のダウンタイムを回避できます。詳細については、「[ローリング更新](using-features.rollingupdates.md)」を参照してください。
+ **イミュータブルな更新** – Elastic Beanstalk により一時的な Auto Scaling グループが、新しい設定で実行されている別のインスタンスセットで環境外に起動されます。その後、Elastic Beanstalk により、これらのインスタンスが環境のロードバランサーの背後に配置されます。新しいインスタンスがヘルスチェックにパスするまでは、古いインスタンスと新しいインスタンスのいずれもがトラフィックを処理します。この時点で Elastic Beanstalk により、新しいインスタンスが環境の Auto Scaling グループに移動され、一時グループと古いインスタンスが終了します。詳細については、「[イミュータブルな更新](environmentmgmt-updates-immutable.md)」を参照してください。
+ **無効** – Elastic Beanstalk では、ダウンタイムを回避する対策が行われません。この場合は、環境にある既存のインスタンスが終了し、新しい設定で実行されている新しいインスタンスに置き換えられます。
**警告**
一部のポリシーでは、デプロイ時または更新時にすべてのインスタンスが置き換えられます。これにより、累積したすべての [Amazon EC2 バーストバランス](https://docs.aws.amazon.com/AWSEC2/latest/DeveloperGuide/burstable-performance-instances.html)が失われます。次の場合に発生します。
インスタンスの置換を有効にしたマネージドプラットフォームの更新
イミュータブルな更新
イミュータブルな更新またはトラフィック分割を有効にしたデプロイ
**サポートされる更新タイプ**
| ローリング更新の設定 | 負荷分散された環境 | 単一インスタンス環境 | レガシー Windows サーバー環境 |
| --- | --- | --- | --- |
| Disabled | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-yes.png) はい | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-yes.png) はい | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-yes.png) はい |
| ヘルスにもとづくローリング | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-yes.png) はい | ![\[No\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-no.png) ☓いいえ | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-yes.png) はい |
| 時間にもとづくローリング | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-yes.png) はい | ![\[No\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-no.png) ☓いいえ | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-yes.png) はい |
| Immutable | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-yes.png) はい | ![\[Yes\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-yes.png) はい | ![\[No\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/icon-no.png) ☓いいえ |
† このテーブルの*レガシー Windows Server 環境*は、IIS 8.5 より前の IIS バージョンを使用する [Windows Server プラットフォーム設定](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net)に基づいています。
**Topics**
+ [Elastic Beanstalk 環境設定のローリング更新](using-features.rollingupdates.md)
+ [変更不可能な環境の更新](environmentmgmt-updates-immutable.md)
# Elastic Beanstalk 環境設定のローリング更新
[設定変更にインスタンスの置き換えが必要](environments-updating.md)な場合、Elastic Beanstalk はバッチ単位で更新を実行することで、変更の適用中のダウンタイムを回避できます。ローリング更新中、容量は 1 バッチのサイズ分だけ減ります。バッチのサイズはお客様が設定できます。Elastic Beanstalk は、停止中のインスタンスのバッチを 1 つ選んで終了させ、新しい設定のバッチを起動します。新しいバッチがリクエストの処理を開始すると、Elastic Beanstalk は次のバッチに進みます。
ローリング設定更新のバッチは、バッチ間に一定の時間間隔を設定して定期的 (時間ベース) に処理することも、状態に基づいて処理することもできます。時間ベースのローリング更新の場合、インスタンスのバッチの起動が完了して、次のバッチに移動するまで Elastic Beanstalk が待機する時間を設定できます。この一時停止の時間によって、アプリケーションはブートスロラップおよびリクエスト処理の開始が可能になります。
正常性に基づくローリング更新では、Elastic Beanstalk は、バッチのインスタンスがヘルスチェックに合格するまで待ってから、次のバッチに移ります。インスタンスの状態は、ヘルスレポートシステム (基本または拡張) によって決定されます。[基本ヘルス](using-features.healthstatus.md)レポートでは、バッチのすべてのインスタンスが Elastic Load Balancing (ELB) ヘルスチェックに合格し、バッチは正常な状態であると見なされます。
[拡張ヘルスレポート](health-enhanced.md)では、Elastic Beanstalk が次のバッチを処理する前に、バッチのすべてのインスタンスが複数の連続的なヘルスチェックにパスする必要があります。インスタンスのみを確認する ELB ヘルスチェックに加え、拡張ヘルスは、アプリケーションログと環境のその他のリソースの状態を監視します。拡張ヘルスを使用するウェブサーバー環境では、すべてのインスタンスが 2 分間にわたって行われる 12 のヘルスチェックに合格する必要があります（ワーカー環境では 3 分間にわたって 18 のチェックが行われます）。いずれかのインスタンスが 1 つでもヘルスチェックで不合格になければ、カウントがリセットされます。
バッチがローリング更新のタイムアウト (デフォルトは 30 分) 以内に正常にならなければ、更新はキャンセルされます。ローリング更新のタイムアウトは、`aws:autoscaling:updatepolicy:rollingupdate` 名前空間で使用できる[設定オプション](command-options.md)の 1 つです。アプリケーションがヘルスチェックで `Ok` ステータスにならなくても、別のレベルで安定する場合は、[`aws:elasticbeanstalk:healthreporting:system`](command-options-general.md#command-options-general-elasticbeanstalkhealthreporting) 名前空間で `HealthCheckSuccessThreshold` オプションを設定して、Elastic Beanstalk でインスタンスが正常と見なされるレベルに変更できます。
ローリング更新プロセスが失敗した場合、Elastic Beanstalk は別のローリング更新を開始して、以前の設定にロールバックします。ローリング更新は、ヘルスチェックに不合格になったことが原因で失敗したり、新しいインスタンスの起動によりアカウントのクォータを超えたことが原因で失敗したりすることがあります。例えば、Amazon EC2 インスタンス数のクォータに達すると、新しいインスタンスのバッチをプロビジョンしようとしたときに、ローリング更新は失敗する可能性があります。この場合、ロールバックも失敗します。
ロールバックが失敗すると、更新プロセスは終了し、環境は異常な状態のままとなります。正常に完了したバッチには新しい設定が反映されますが、未処理のバッチでは依然として古い設定でインスタンスが実行されます。ロールバックに失敗した環境を修復するには、まず更新に失敗した根本的な原因を解決します。次に、あらためて環境の更新を開始します。
代わりの方法として、別の環境にアプリケーションの新しいバージョンをデプロイしてから、CNAME スワップを実行して、ダウンタイムなしでトラフィックをリダイレクトすることがあります。詳細については「[Elastic Beanstalk を使用したブルー/グリーンデプロイ](using-features.CNAMESwap.md)」を参照してください。
## ローリング更新とローリングデプロイ
ローリング更新が実行されるのは、設定変更に伴い、新しい Amazon EC2 インスタンスをお客様の環境用にプロビジョンすることが必要になるときです。例えば、Auto Scaling グループの設定 (インスタンスタイプとキーペアの設定など) の変更、VPC の設定の変更です。ローリング更新では、インスタンスの各バッチが終了されてから、新しいバッチが置き換え用にプロビジョニングされます。
[ローリングデプロイ](using-features.rolling-version-deploy.md)が実行されるのは、毎回、アプリケーションをデプロイするときです。通常、お客様の環境でインスタンスの置き換えなしで実行できます。Elastic Beanstalk は、各バッチをサービスから外し、新しいアプリケーションバージョンをデプロイしてから、サービスに戻します。
ただし例外は、設定の変更に伴い、新しいアプリケーションバージョンをデプロイすると同時にインスタンスを置き換えることが必要になる場合です。たとえば、ソースバンドルにある[キー名](command-options-general.md#command-options-general-autoscalinglaunchconfiguration)設定 ([設定ファイル](ebextensions.md)内) を変更し、お客様の環境にデプロイする場合は、ローリング更新がトリガーされます。既存のインスタンスの各バッチに新しいアプリケーションバージョンがデプロイされる代わりに、インスタンスの新しいバッチが新しい設定でプロビジョニングされます。この場合、個別のデプロイは行われません。新しいインスタンスが新しいアプリケーションバージョンで起動されるためです。
新しいインスタンスが環境更新の一部としてプロビジョニングされる場合、アプリケーションのソースコードが新しいインスタンスと、インスタンスが適用されるオペレーティングシステムやソフトウェアを変更するすべての設定にデプロイされるデプロイフェーズがあります。[デプロイのヘルスチェック設定](using-features.rolling-version-deploy.md#environments-cfg-rollingdeployments-console) ([**Ignore health check**] と [**Healthy threshold**]、[**Command timeout**]) もデプロイフェーズでローリング更新および変更不可能な更新に基づき、適用されます。
## ローリング更新の設定
Elastic Beanstalk コンソールでローリング更新を有効にして設定できます。
**ローリング更新を有効にするには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで、[**設定**] を選択します。
1. [**Rolling updates and deployments (ローリング更新とデプロイ)**] 設定カテゴリで [**Edit (編集)**] を選択します。
1. [**Configuration updates (設定の更新)**] セクションの [**ローリング更新のタイプ**] で、いずれかの [**ローリング**] オプションを選択します。
![\[[Modify rolling updates and deployments configuration] ページの [Configuration updates] セクション\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/aeb-config-rolling-updates-health.png)
1. [**バッチサイズ**]、[**最小キャパシティー**]、[**停止時間**] の順に選択します。
1. ページの最下部で **[適用]** を選択し変更を保存します。
**[Rolling updates and deployments]** (ローリング更新とデプロイ) ページの **[Configuration updates]** (設定の更新) セクションには、ローリング更新に関する次のオプションがあります。
+ **Rolling update type** – Elastic Beanstalk が、インスタンスのバッチの更新を終え、次のバッチに進むまで待機し、その間インスタンスがブートストラップを終了して、トラフィック処理を開始できるようになります。次のオプションから選択します。
+ **Rolling based on Health** – 現在のバッチのインスタンスが正常な状態になるまで待ってから、インスタンスを実行状態にし、次のバッチを処理します。
+ **Rolling based on Time** – 新しいインスタンスを開始して実行状態にし、次のバッチを処理するまでの待機時間を指定します。
+ **Immutable** – [変更不可能な更新](environmentmgmt-updates-immutable.md)を実行することで、設定変更をインスタンスの新しいグループに適用します。
+ **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` 名前空間にある[設定オプション](command-options.md)を利用してローリング更新を設定できます。
`RollingUpdateEnabled` オプションを使用してローリング更新を有効にし、更新タイプの選択に `RollingUpdateType` を使用します。次の値は、`RollingUpdateType` をサポートします。
+ [`Health`] – 現在のバッチのインスタンスが正常な状態になるまで待ってから、インスタンスを実行状態にし、次のバッチを処理します。
+ `Time` – 新しいインスタンスを起動して、サービス実行状態にし、次のバッチを開始するまでの待機時間を指定します。
+ `Immutable` – [変更不可能な更新](environmentmgmt-updates-immutable.md)を実行することで、設定変更をインスタンスの新しいグループに適用します。
ローリング更新を有効にした場合は、`MaxBatchSize` オプションと `MinInstancesInService` オプションも設定してバッチのサイズを設定します。時間ベースと正常性ベースのローリング更新の場合、それぞれ `PauseTime` および `Timeout` をそれぞれ設定できます。
たとえば、一度に最大 5 つのインスタンスを起動する場合、少なくとも 2 つのインスタンスを実行状態に維持したままバッチごとに 5 分 30 秒間待機し、次のオプションと値を指定します。
**Example .ebextensions/timebased.config**
```
option_settings:
aws:autoscaling:updatepolicy:rollingupdate:
RollingUpdateEnabled: true
MaxBatchSize: 5
MinInstancesInService: 2
RollingUpdateType: Time
PauseTime: PT5M30S
```
正常性に基づくローリング更新を有効にするには、各バッチにつき 45 分間のタイムアウトで次のオプションと値を指定します。
**Example .ebextensions/healthbased.config**
```
option_settings:
aws:autoscaling:updatepolicy:rollingupdate:
RollingUpdateEnabled: true
MaxBatchSize: 5
MinInstancesInService: 2
RollingUpdateType: Health
Timeout: PT45M
```
[`Timeout`] と [`PauseTime`] の値は、[ISO8601 duration](http://en.wikipedia.org/wiki/ISO_8601#Durations): `PT#H#M#S` で指定する必要があります。ここで、各 \$1 はそれぞれ時間、分、秒を指します。
EB CLI および Elastic Beanstalk コンソールでは、上記のオプションに推奨値が適用されます。設定ファイルを使用して同じファイルを設定する場合は、これらの設定を削除する必要があります。詳細については、「[推奨値](command-options.md#configuration-options-recommendedvalues)」を参照してください。
# 変更不可能な環境の更新
変更不可能な更新は[ローリング更新](using-features.rollingupdates.md)の代替手段です。変更不可能な環境の更新により、インスタンスの置換を必要とする構成変更が効率的かつ安全に適用されます。変更不可能な環境の更新に失敗した場合のロールバックプロセスは、Auto Scaling グループの終了のみです。しかし、ローリーング更新に失敗した場合は、追加のローリング更新を実行して変更を元に戻さなければなりません。
変更不可能な環境の更新を実行するために、Elastic Beanstalk は環境のロードバランサーの背後に 2 つ目の (一時的な) Auto Scaling グループを作成し、新しいインスタンスを作成します。これにより、Elastic Beanstalk は新しいグループ内の新規設定で単一のインスタンスを起動します。このインスタンスは、以前の設定を実行している元の Auto Scaling グループの全インスタンスと共にトラフィックを処理します。
最初のインスタンスがヘルスチェックに合格すると、Elastic Beanstalk は元の Auto Scaling グループで実行しているインスタンスの数に一致する新しい設定で、追加のインスタンスを起動します。新しいインスタンスがすべてヘルスチェックに合格した場合、Elastic Beanstalk はこれらのインスタンスを元の Auto Scaling グループに転送し、一時 Auto Scaling グループと古いインスタンスを終了します。
**注記**
変更不可能な環境の更新中、新しい Auto Scaling グループ内のインスタンスがリクエスト処理を開始してから、元の Auto Scaling グループのインスタンスが終了するまでの短い間、環境の容量が倍増します。環境内に多くのインスタンスがある場合、あるいは[オンデマンドインスタンスクォータ](https://aws.amazon.com/ec2/faqs/#How_many_instances_can_I_run_in_Amazon_EC2)が低い場合は、変更不可能な環境の更新を実行する上で必要な容量が十分あることを確認してください。クォータの下限に近い場合は、代わりにローリング更新を行うことをお勧めします。
変更不可能な更新では、更新中に環境の状態を評価する[拡張ヘルスレポート](health-enhanced.md)が必要となります。拡張ヘルスレポートは、ロードバランサーの標準ヘルスチェックと組み合わせることで、新しい設定を実行しているインスタンスが[リクエスト処理を正しく実行している](health-enhanced.md#health-enhanced-factors)ことを確認します。
また、ローリングデプロイを実行する代わりに、変更不可能な更新で新しいアプリケーションのバージョンをデプロイすることも可能です。[変更不可能な更新でアプリケーションのデプロイを実行するよう Elastic Beanstalk を設定すると](using-features.rolling-version-deploy.md)、新しいアプリケーションのバージョンをデプロイするたびに環境内にあるすべてのインスタンスが置き換えられます。変更不可能なアプリケーションのデプロイが失敗した場合、Elastic Beanstalk は新しい Auto Scaling グループを終了して直ちに変更を元に戻します。これは、部分的なフリートのデプロイを防止するためです。部分的なフリートのデプロイは、一部のバッチしか終了していない状態でローリングデプロイに失敗すると発生します。
**警告**
一部のポリシーでは、デプロイ時または更新時にすべてのインスタンスが置き換えられます。これにより、累積したすべての [Amazon EC2 バーストバランス](https://docs.aws.amazon.com/AWSEC2/latest/DeveloperGuide/burstable-performance-instances.html)が失われます。次の場合に発生します。
インスタンスの置換を有効にしたマネージドプラットフォームの更新
イミュータブルな更新
イミュータブルな更新またはトラフィック分割を有効にしたデプロイ
変更不可能な更新に失敗した場合、Elastic Beanstalk がインスタンスを削除する前に、新しいインスタンスにより[バンドルログ](using-features.logging.md)が Amazon S3 にアップロードされます。Elastic Beanstalk では、失敗した更新のログを Amazon S3に 1 時間保管してから削除します(バンドルログやログ末尾の場合は標準の 15 分)。
**注記**
変更不可能な更新で設定を適用せずにアプリケーションバージョンをデプロイした場合、ローリング更新をトリガーする設定の変更（インスタンスタイプの変更設定など）を含むアプリケーションバージョンをデプロイしようとするとエラーが生じる可能性があります。こうしたエラーを防ぐには、別の更新で設定を変更するか、デプロイと設定変更の両方に対して変更不可能な更新を設定します。
変更不可能な更新は、リソースの設定変更と共に実行することはできません。たとえば、他の設定を更新している間は[インスタンス置換を必要とする設定](environments-updating.md)を変更したり、設定やソースコード内の追加リソースを変更する設定ファイルと共に変更不可能なデプロイを実行することはできません。リソース設定 (ロードバランサーの設定など) を変更し、変更不可能な更新を同時に実行すると、Elastic Beanstalk によりエラーが返されます。
ソースコードやインスタンス設定の変更に依存しないリソース設定の変更については、2 回に分けて更新します。依存する場合は、[青/緑のデプロイ](using-features.CNAMESwap.md)を実行してください。
## 変更不可能な更新を設定する
Elastic Beanstalk コンソールで変更不可能な更新を有効にして設定できます。
**変更不可能な更新を有効にする（コンソール）**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで、[**設定**] を選択します。
1. [**Rolling updates and deployments (ローリング更新とデプロイ)**] 設定カテゴリで [**Edit (編集)**] を選択します。
1. [**設定の更新**] セクションで [**ローリング更新のタイプ**] を [**Immutable (変更不可)**] に設定します。
![\[[Modify rolling updates and deployments configuration] ページの [Configuration updates] セクション\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/environments-mgmt-updates-immutable.png)
1. ページの最下部で **[適用]** を選択し変更を保存します。
## aws:autoscaling:updatepolicy:rollingupdate 名前空間
`aws:autoscaling:updatepolicy:rollingupdate`名前空間にあるオプションを使用して変更不可能な更新を設定することも可能です。次の[設定ファイル](ebextensions.md)は、設定変更に対する変更不可能な更新を有効にします。
**Example .ebextensions/immutable-updates.config**
```
option_settings:
aws:autoscaling:updatepolicy:rollingupdate:
RollingUpdateType: Immutable
```
次の例は、設定変更とデプロイの両方に対する変更不可能な更新を有効にします。
**Example .ebextensions/immutable-all.config**
```
option_settings:
aws:autoscaling:updatepolicy:rollingupdate:
RollingUpdateType: Immutable
aws:elasticbeanstalk:command:
DeploymentPolicy: Immutable
```
EB CLI および Elastic Beanstalk コンソールでは、上記のオプションに推奨値が適用されます。設定ファイルを使用して同じファイルを設定する場合は、これらの設定を削除する必要があります。詳細については、「[推奨値](command-options.md#configuration-options-recommendedvalues)」を参照してください。