翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# デプロイポリシーと設定
<a name="using-features.rolling-version-deploy"></a>

AWS Elastic Beanstalk には、[デプロイ](using-features.deploy-existing-version.md)ポリシー (*一度にすべて*、*ローリング*、*追加のバッチによるローリング*、*イミュータブ*ル、*トラフィック分割*) や、デプロイ中のバッチサイズとヘルスチェックの動作を設定できるオプションなど、デプロイの処理方法に関するいくつかのオプションが用意されています。デフォルトでは、環境は一括デプロイを使用します。EB CLI で環境を作成し、それがスケーラブルな環境である (`--single` オプションを指定していない) 場合は、ローリングデプロイを使用します。

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

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

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

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

**警告**  
一部のポリシーでは、デプロイ時または更新時にすべてのインスタンスが置き換えられます。これにより、累積したすべての [Amazon EC2 バーストバランス](https://docs.aws.amazon.com/AWSEC2/latest/DeveloperGuide/burstable-performance-instances.html)が失われます。次の場合に発生します。  
インスタンスの置換を有効にしたマネージドプラットフォームの更新
イミュータブルな更新
イミュータブルな更新またはトラフィック分割を有効にしたデプロイ

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

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

## アプリケーションデプロイの設定
<a name="environments-cfg-rollingdeployments-console"></a>

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

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

1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。

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

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

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

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

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

**[Rolling updates and deployments]** (ローリング更新とデプロイ) ページの **[Application deployments]** (アプリケーションのデプロイ) セクションには、アプリケーションのデプロイに関する次のオプションがあります。
+ [**Deployment policy (デプロイポリシー)**] - 以下のデプロイオプションから選択します。
  + [**All at once (一度に)**] - 同時にすべてのインスタンスに新しいバージョンをデプロイします。環境内のすべてのインスタンスは、デプロイが実行される間、短時間ですがサービス停止状態になります。
  + [**Rolling (ローリング)**] - バッチに新しいバージョンをデプロイします。デプロイフェーズ中、バッチはサービス停止状態になり、バッチのインスタンスによる環境容量への負荷を低減します。
  + [**Rolling with additional batch (追加バッチによるローリング)**] - バッチに新しいバージョンをデプロイしますが、デプロイ中に総容量を維持するため、インスタンスの新しいバッチをまず起動します。
  + [**Immutable (イミュータブル)**] - [イミュータブルな更新](environmentmgmt-updates-immutable.md)を実行し、新しいバージョンをインスタンスの新しいグループにデプロイします。
  + [**Traffic splitting (トラフィック分割)**] - アプリケーションの新しいバージョンをインスタンスの新しいグループにデプロイし、受信クライアントトラフィックをアプリケーションの既存のバージョンと新しいバージョンとの間で一時的に分割します。

[**Rolling (ローリング)**] および [**Rolling with additional batch (追加バッチによるローリング)**] デプロイポリシーでは、以下を設定できます。
+ [**Batch size (バッチサイズ)**] - 各バッチでデプロイする一連のインスタンスのサイズ。

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

[**Traffic splitting (トラフィック分割)**] デプロイポリシーでは、以下を設定できます。
+ [**Traffic split (トラフィック分割)**] - デプロイする新しいアプリケーションバージョンを実行している環境インスタンスに Elastic Beanstalk がシフトする受信クライアントトラフィックの初期の割合。
+ [**Traffic splitting evaluation time (トラフィック分割評価時間)**] - 初回のデプロイが正常に完了してから、デプロイする新しいアプリケーションバージョンにすべての受信クライアントトラフィックをシフトするまで、Elastic Beanstalk が待機する時間 (分単位)。

![\[Elastic Beanstalk アプリケーションのデプロイ設定ページ\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/environment-cfg-rollingdeployments.png)


[**Deployment preferences**] セクションには、ヘルスチェック関連のオプションが含まれています。
+ [**Ignore health check (ヘルスチェックの無視)**] - バッチが [**Command timeout (コマンドタイムアウト)**] の時間内に正常な状態にならなかった場合に、デプロイがロールバックするのを防ぎます。
+ [**Healthy threshold (ヘルシーしきい値)**] - ローリングデプロイやローリング更新、イミュータブルな更新中に、インスタンスが正常と見なされるしきい値を引き下げます。
+ [**Command timeout (コマンドタイムアウト)**] - デプロイがキャンセルされるまで、または [**Ignore health check (ヘルスチェックの無視)**] が設定されている場合は次のバッチの処理に移るまで、インスタンスが正常な状態になるために待機する秒数。

![\[Elastic Beanstalk アプリケーションのデプロイ設定ページ\]](http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/images/environment-cfg-healthchecks.png)


## ローリングデプロイの仕組み
<a name="environments-cfg-rollingdeployments-method"></a>

バッチを処理する際、Elastic Beanstalk はバッチ内のすべてのインスタンスをロードバランサーからデタッチし、新しいアプリケーションバージョンをデプロイしてから、再アタッチします。[Connection Draining](environments-cfg-clb.md#using-features.managing.elb.draining) が有効になっていると、Elastic Beanstalk は、デプロイを開始する前に、Amazon EC2 インスタンスから既存の接続をドレインします。

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

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

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

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

## トラフィック分割デプロイの仕組み
<a name="environments-cfg-trafficsplitting-method"></a>

トラフィック分割デプロイでは、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](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_AbortEnvironmentUpdate.html) API または同等の AWS CLI コマンドを呼び出すこともできます。

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

## デプロイオプションの名前空間
<a name="environments-cfg-rollingdeployments-namespace"></a>

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

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

 
+ `AllAtOnce` - ローリングデプロイを無効にし、常に同時にすべてのインスタンスにデプロイを実行します。
+ `Rolling` - 標準的なローリングデプロイを有効にします。
+ `RollingWithAdditionalBatch` - 総容量を維持するために、デプロイ開始前にインスタンスの追加バッチを起動します。
+ `Immutable` - すべてのデプロイ時に[イミュータブルな更新](environmentmgmt-updates-immutable.md)を実行します。
+ `TrafficSplitting` - トラフィック分割デプロイを実行して、アプリケーションのデプロイの Canary テストを実施します。

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

**Example .ebextensions/rolling-updates.config**  

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

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

**Example .ebextensions/rolling-additionalbatch.config**  

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

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

**Example .ebextensions/immutable-ignorehealth.config**  

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

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

**Example .ebextensions/traffic-splitting.config**  

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

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