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

# でコンピューティング環境を更新する AWS Batch
<a name="updating-compute-environments"></a>

AWS Batch は、コンピューティング環境を更新するための複数の戦略を提供します。各戦略は、特定の更新シナリオと要件に合わせて設計されています。これらのアプローチは、同じ基盤となる更新 API を使用しますが、更新を効果的に管理するためのさまざまな規範的手法を示しています。これらの更新は、 AWS Batch コンソールまたは を使用して管理できます AWS CLI。これらの戦略を理解することで、ワークロードの中断を最小限に抑えつつ、ニーズに最適な方法を選択できます。

このトピックでは、利用可能な更新戦略の概要と、各アプローチを使用するタイミングに関するガイダンスについて説明します。詳細な手順については、各更新戦略の個々のセクションを参照してください。

**重要**  
AWS Batch は、Amazon EC2 起動テンプレート、Amazon EC2 Auto Scaling グループ、Amazon EC2 スポットフリート、Amazon ECS クラスターなど、ユーザーに代わってアカウント内で複数の AWS リソースを作成および管理します。これらのマネージドリソースは、最適な AWS Batch オペレーションを確保するために特別に設定されています。これらの AWS Batchマネージドリソースを手動で変更すると、 AWS Batch ドキュメントに明示的に記載されていない限り、`INVALID`コンピューティング環境、最適ではないインスタンススケーリング動作、ワークロード処理の遅延、予期しないコストなどの予期しない動作が発生する可能性があります。これらの手動変更は、 AWS Batch サービスで決定的にサポートすることはできません。コンピューティング環境を管理するには、常にサポートされている AWS Batch APIsまたは AWS Batch コンソールを使用してください。  
サポートされていない手動変更には、独自の Amazon ECS タスクまたはサービス AWS Batchオンマネージド Amazon ECS クラスターの実行、または追加のプロセス、デーモン、またはサービス AWS Batchオンマネージドインスタンスの直接開始が含まれます。 は、マネージドコンピューティング環境でコンピューティングリソースの完全な制御を AWS Batch 引き受け、インスタンスを終了したり、タスクを停止したり、クラスターをいつでもスケールしたりできます。これらのマネージドリソースで AWS Batch ジョブの送信外で実行するワークロードは、警告なしに中断される可能性があります。ワークロード以外のAWS Batch 管理 AWS Batch対象クラスターやインスタンスを実行すると、 AWS Batch ジョブのスケジュール設定やインスタンスのスケーリングが妨げられる可能性があります。

**Topics**
+ [コンピューティング環境の更新戦略](#update-strategies)
+ [適切な更新戦略の選択](#choosing-update-strategies)
+ [AMI 更新に関する考慮事項](#ami-update-considerations)
+ [スケーリングの更新を実行する](scaling-updates.md)
+ [インフラストラクチャの更新を実行する](infrastructure-updates.md)
+ [コンピューティング環境のブルー/グリーン更新を実行する](blue-green-updates.md)

## コンピューティング環境の更新戦略
<a name="update-strategies"></a>

スケーリングまたはインフラストラクチャの更新を使用すると、コンピューティング環境が更新されます。ブルー/グリーン更新戦略では、新しいコンピューティング環境 (グリーン) を作成し、ワークロードを古いコンピューティング環境 (ブルー) から新しいコンピューティング環境 (グリーン) に移行します。

AWS Batch には、コンピューティング環境の更新に関する 3 つの異なる戦略があります。

スケーリングの更新  
スケーリングの更新は、既存のインスタンスを置き換えることなくインスタンスを追加または削除することで、コンピューティング環境の容量を調整します。これは最速の更新シナリオであり、ダウンタイムは必要ありません。容量設定 (vCPUs) を変更する必要がある場合は、スケーリングの更新を使用します。これらの更新は通常、数分で完了します。  
Fargate の更新は、スケーリングの更新と同じ手順を使用して実行されます。詳細については、「[スケーリングの更新を実行する](scaling-updates.md)」を参照してください。

インフラストラクチャの更新  
インフラストラクチャの更新は、コンピューティング環境のインスタンスを、設定が更新された新しいインスタンスに置き換えます。これらの更新には、特定のサービスロールと割り当て戦略の設定が必要ですが、ダウンタイムを最小限に抑えることができ、実行中のジョブが中断される可能性があります。インスタンスタイプ、AMI 設定、ネットワーク設定、サービスロール、環境の状態、またはその他のインフラストラクチャコンポーネントを変更する必要がある場合は、インフラストラクチャの更新を使用します。これらの更新は通常、ジョブの完了にもよりますが 10～30 分で完了します。  
詳細については、「[インフラストラクチャの更新を実行する](infrastructure-updates.md)」を参照してください。

ブルー/グリーン更新  
ブルー/グリーン更新により、既存の環境とともに新しいコンピューティング環境が作成され、ダウンタイムなしでワークロードを段階的に移行できます。このアプローチは最も安全な更新パスを提供しますが、2 つの環境を一時的に実行する必要があります。ダウンタイムゼロが必要である場合、完全なデプロイ前に変更をテストする場合、クイックロールバック機能が必要な場合、またはインフラストラクチャの更新でサポートされていない設定を使用している場合は、ブルー/グリーン更新を使用します。完了までの時間はさまざまで、ユーザーが制御します。  
詳細については、「[コンピューティング環境のブルー/グリーン更新を実行する](blue-green-updates.md)」を参照してください。

## 適切な更新戦略の選択
<a name="choosing-update-strategies"></a>

この決定ガイドを使用して、ニーズに最も適した更新戦略を選択します。

### 次の場合は、スケーリングの更新を選択します。
<a name="scaling-updates-when"></a>

コンピューティング容量 (vCPUs) を調整するだけで済む場合は、スケーリング更新戦略を選択します。スケーリングの更新は、ダウンタイムなしの迅速な更新が必要で、インフラストラクチャ設定の変更が不要な場合に最適です。

詳細な手順については、[スケーリングの更新を実行する](scaling-updates.md) を参照してください。

### 次の場合は、インフラストラクチャの更新を選択します。
<a name="infrastructure-updates-when"></a>

インスタンスタイプ、AMI 設定、サービスロール、環境の状態、またはネットワーク設定を変更する必要がある場合は、インフラストラクチャの更新戦略を選択します。環境では、サービスにリンクされたロール *[AWSServiceRoleForBatch]* と、`BEST_FIT_PROGRESSIVE`、`SPOT_CAPACITY_OPTIMIZED`、`SPOT_PRICE_CAPACITY_OPTIMIZED` の割り当て戦略を使用する必要があります。インフラストラクチャの更新は、更新中にジョブの若干の中断が許容され、最新の Amazon ECS 最適化 AMI の自動更新が必要な場合に適しています。

詳細な手順については、[インフラストラクチャの更新を実行する](infrastructure-updates.md) を参照してください。

### 次の場合は、ブルー/グリーン更新を選択します。
<a name="blue-green-updates-when"></a>

ワークロードのダウンタイムがゼロである必要がある場合、または本番ワークロードの移行前に変更をテストする必要がある場合は、ブルー/グリーン更新戦略を選択します。このアプローチは、クイックロールバック機能が重要である場合、環境が `BEST_FIT` 配分戦略を使用する場合、または環境においてサービスにリンクされたロール *[AWSServiceRoleForBatch]* を使用しない場合に不可欠です。ブルー/グリーン更新は、手動更新を必要とするカスタム AMI を使用する場合や、大規模な設定変更を行う必要がある場合にも最適です。

詳細な手順については、[コンピューティング環境のブルー/グリーン更新を実行する](blue-green-updates.md) を参照してください。

## AMI 更新に関する考慮事項
<a name="ami-update-considerations"></a>

AMIs を更新する方法は、コンピューティング環境の設定によって異なります。

### AWS Batch 提供されたデフォルト AMI を最新の に更新する
<a name="automatic-ami-updates"></a>

AWS Batch は、これらの条件がすべて満たされた場合、[インフラストラクチャ](infrastructure-updates.md)の更新中に最新の Amazon ECS 最適化 AMI に更新できます。

**注記**  
インフラストラクチャの更新が完了すると、`updateToLatestImageVersion` が `false` に設定されます。別の更新を開始するには、`updateToLatestImageVersion` を `true` に設定する必要があります。
+ コンピューティング環境は、*AWSServiceRoleForBatch* サービスにリンクされたロールを使用します。
+ 配分戦略は、`BEST_FIT_PROGRESSIVE`、`SPOT_CAPACITY_OPTIMIZED`、または に設定されます`SPOT_PRICE_CAPACITY_OPTIMIZED`。
+ `imageId`、、`imageIdOverride`または 起動テンプレートで AMI ID が明示的に指定されていません。
+ `updateToLatestImageVersion` は `true` に設定されています。

### ブルー/グリーンデプロイを使用した AMI の更新
<a name="manual-ami-updates-blue-green"></a>

以下のシナリオでは、ブルー/グリーンデプロイを使用して AMI を更新する必要があります。
+ Amazon ECS 最適化 AMI の特定のバージョンを使用する場合。
+ AMI ID が次のいずれかで指定されている場合:
  + 起動テンプレート (テンプレートを更新するか、削除する必要があります）。
  + `imageId` パラメータ。
  + EC2 設定の `imageIdOverride`パラメータ。
+ `BEST_FIT` 配分戦略を使用する場合 (インフラストラクチャの更新をサポートしていません）。
+ *AWSServiceRoleForBatch* [サービスにリンクされたロール](using-service-linked-roles-batch-general.md)を使用しない場合。

### カスタム AMI の AMI 更新
<a name="manual-ami-updates-custom-ami"></a>

コンピューティング環境の起動テンプレートでカスタム AMI を指定した場合、EC2 設定の `imageId`パラメータまたは `imageIdOverride`パラメータ AWS Batch は、インフラストラクチャの更新中にカスタム AMI を自動的に更新しません。コンピューティング環境の作成時に最初に使用された パラメータで新しい ID を指定することで、カスタム AMI ID を更新できます。 AWS Batchが提供する AMI の使用に切り替える場合は、コンピューティング環境の更新でカスタム AMI ID を削除することで切り替えることができます。