# Amazon ECS でコンテナをスケジュールする
<a name="scheduling_tasks"></a>

Amazon Elastic Container Service (Amazon ECS) は、コンテナ化されたワークロードに柔軟なスケジューリング機能を提供する共有状態のオプティミスティックな並列システムです。Amazon ECSスケジューラはAmazon ECS API と同じクラスターの状態情報を利用して、適切な配置を決定します。

Amazon ECS は、長時間実行されるタスクおよびアプリケーションにサービススケジューラを提供します。バッチジョブまたは単一実行タスクに対してスタンドアロンタスクまたはスケジュールされたタスクを手動で実行することもできます。ニーズに最適なタスクを実行するためのタスク配置戦略や制約を指定できます。例えば、タスクを複数のアベイラビリティーゾーンにまたがって実行するか、単一のアベイラビリティーゾーン内で実行するかを指定できます。さらに、オプションとして、独自のカスタムまたはサードパーティーのスケジューラでタスクを統合することもできます。


| オプション | どのようなときに使うか | 詳細情報 | 
| --- | --- | --- | 
| サービス | サービススケジューラは、長期実行するステートレスサービスやアプリケーションに適しています。サービススケジューラはオプションで、タスクがElastic Load Balancingロードバランサーに登録されていることも確認します。サービススケジューラで維持されているサービスを更新できます。これには、新しいタスク定義のデプロイや、実行中のタスクの必要数の変更が含まれる場合があります。デフォルトでは、サービススケジューラによってタスクは複数のアベイラビリティーゾーン間で分散されます。ただし、タスク配置戦略と制約を使用すると、タスク配置の決定をカスタマイズできます。 | [Amazon ECS サービス](ecs_services.md) | 
| スタンドアロンのタスク | スタンドアロンタスクは、作業を実行してから停止するバッチジョブなどのプロセスに適しています。例えば、キューに作業が入ったときに RunTask を呼び出す処理を入れることができます。タスクはキューから作業を引き出し、作業を実行して、その後終了します。RunTaskを使用すると、デフォルトのタスク配置戦略でクラスター全体にタスクをランダムに分散させることができます。これにより、単一のインスタンスが不均衡な数のタスクを取得する可能性を最小限に抑えることができます。 | [Amazon ECS スタンドアロンタスク](standalone-tasks.md) | 
| スケジュールされたタスク | スケジュールされたタスクは、クラスター内で設定された間隔で実行するタスクがある場合に適しており、EventBridge Scheduler を使用してスケジュールを作成できます。バックアップオペレーションまたはログスキャンのタスクを実行できます。作成する EventBridge Scheduler のスケジュールは、指定した時間にクラスター内の 1 つ以上のタスクを実行できます。スケジュールされたイベントは、特定の間隔 (N 分、時間または日ごとに実行されます) に設定できます。それ以外の場合、より複雑なスケジューリングには、cron 表現を使用できます。 | [Amazon EventBridge スケジューラを使用して Amazon ECS タスクをスケジュールする](tasks-scheduled-eventbridge-scheduler.md) | 

## コンピューティングオプション
<a name="compute-option"></a>

Amazon ECS では、タスクまたはサービスを実行するインフラストラクチャを指定できます。キャパシティープロバイダー戦略または起動タイプを使用できます。

Fargate の場合、キャパシティープロバイダーは Fargate と Fargate Spot です。EC2 の場合、キャパシティープロバイダーは登録されたコンテナインスタンスを持つ Auto Scaling グループです。

キャパシティープロバイダー戦略は、クラスターに関連付けられたキャパシティープロバイダー全体にタスクを分散します。

キャパシティプロバイダー戦略では、クラスターに既に関連付けられており、`ACTIVE` または `UPDATING` ステータスを持つキャパシティプロバイダーのみを使用できます。クラスターの作成時に、キャパシティプロバイダーをクラスターに関連付けることができます。

キャパシティプロバイダー戦略では、オプションの*ベース*値は、指定されたキャパシティプロバイダーで実行されるタスクの最小限の数を指定します。キャパシティープロバイダー戦略では、ベースを定義できるキャパシティープロバイダーは 1 つだけです。

*ウェイト*値は、指定したキャパシティプロバイダーを使用する起動済みタスクの総数に対する相対的な割合を決定します。次の例を考えます。2 つのキャパシティプロバイダーを含む戦略があり、両方の重みが `1` であるとします。ベースの割合が達すると、タスクは 2 つのキャパシティプロバイダー間で均等に分割されます。同じロジックを使用して、*capacityProviderA* に `1` の重みを指定し、*capacityProviderB* に `4` の重みを指定するとします。そして、*capacityProviderA* を使うタスクが 1 つ実行されるごとに、*capacityProviderB* を使うタスクが 4 つ実行されることになります。

コンピューティングオプションでは、Fargate またはクラスターに手動で登録した Amazon EC2 インスタンスでタスクを直接起動します。

# Amazon ECS タスクライフサイクル
<a name="task-lifecycle-explanation"></a>

タスクが手動またはサービスの一部として開始されると、自己終了するか手動で停止されるまでに、複数の状態を経由します。バッチジョブとして実行され、`PENDING` から `RUNNING`、その後 `STOPPED` と自然に進行するタスクもあります。他のタスクの場合は、サービスの一部であることもありますが、無制限に実行され続けるか、必要に応じてスケールアップまたはスケールダウンします。

タスクの停止や、スケールアップまたはスケールダウンのためのサービスの必要数の更新など、タスクのステータスの変更がリクエストされた場合、Amazon ECS コンテナエージェントはこれらの変更をタスクの最後の既知のステータス (`lastStatus`) およびタスクの目的のステータス (`desiredStatus`) として追跡します。タスクの最後の既知のステータスと目的のステータスの両方が、コンソールでまたは API あるいは AWS CLI でタスクを記述することにより、表示できます。

以下のフローチャートは、タスクのライフサイクルのフローを示しています。

![\[タスクのライフサイクル状態の説明図。状態には、PROVISIONING、PENDING、ACTIVATING、RUNNING、DEACTIVATING、STOPPING があります。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/task-lifecycle.png)


## ライフサイクル状態
<a name="lifecycle-states"></a>

それぞれのタスクのライフサイクル状態の説明は、以下のとおりです。

PROVISIONING  
Amazon ECS は、タスクを起動する前に追加のステップを実行する必要があります。例えば、`awsvpc` ネットワークモードを使用するタスクの場合、Elastic Network Interface をプロビジョニングする必要があります。

保留中  
これは、Amazon ECS が他の操作を実行するためにコンテナエージェントで待機している遷移状態です。タスクは、そのタスクに利用可能なリソースがあるまで保留状態のままです。

アクティブ化中  
これは、タスクが起動された後で、タスクが `RUNNING` 状態に移行する前に、Amazon ECS が追加の手順を実行する必要がある移行状態です。これは、Amazon ECS がコンテナイメージをプルし、コンテナを作成し、タスクネットワークを設定し、ロードバランサーのターゲットグループを登録し、サービス検出を設定する状態です。

RUNNING  
タスクを正常に実行中です。

非アクティブ化中  
これは、タスクを停止する前に Amazon ECS が追加のステップを実行する必要がある移行状態です。例えば、Elastic Load Balancings ターゲットグループを使用するように設定されたサービスの一部であるタスクの場合、この状態でターゲットグループの登録解除が行われます。

停止中  
これは、Amazon ECS が他の操作を実行するためにコンテナエージェントで待機している遷移状態です。  
Linux コンテナの場合、コンテナエージェントはコンテナイメージで定義された停止シグナルを送信して、`STOPSIGNAL` の指示を使用してアプリケーションを終了およびシャットダウンする必要があることを通知します。デフォルトでは、`SIGTERM` です。次に、タスク定義で設定された `StopTimeout` 期間待機してから `SIGKILL` を送信します。

プロビジョン解除中  
Amazon ECS は、タスクが停止された後で、タスクが `STOPPED` 状態に移行する前に、追加の手順を実行する必要があります。例えば、`awsvpc` ネットワークモードを使用するタスクの場合、Elastic Network Interface をデタッチして削除する必要があります。

停止  
タスクは正常に停止しました。  
エラーが原因でタスクが停止した場合は、「[Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md)」を参照してください。

DELETED  
これは、タスクが停止したときの移行状態です。この状態はコンソールには表示されませんが、`describe-tasks` に表示されます。

# Amazon ECS がタスクをコンテナインスタンスに配置する方法
<a name="task-placement"></a>

タスク配置を使用して、アベイラビリティーゾーンやインスタンスタイプなど、特定の基準を満たすコンテナインスタンスにタスクを配置するように Amazon ECS を設定できます。

以下はタスク配置のコンポーネントです。
+ タスク配置戦略 - タスク配置またはタスクの終了でコンテナインスタンスを選択するためのアルゴリズムです。例えば、Amazon ECS でランダムにコンテナインスタンスを選択することも、インスタンスのグループ間に均等に分散されているタスクを持つコンテナインスタンスを選択することもできます。
+ タスクグループ - データベースタスクなどの関連タスクのグループ。
+ タスク配置制約事項 - コンテナインスタンスにタスクを配置するために満たす必要があるルールです。この制約が満たされない場合、タスクは配置されず、`PENDING` 状態のままになります。たとえば、制約を使用して、特定のインスタンスタイプにのみタスクを割り当てることができます。

Amazon ECS には、容量オプションごとに異なるアルゴリズムがあります。

## Amazon ECS マネージドインスタンス
<a name="managed-instances-launch-type"></a>

Amazon ECS マネージドインスタンスで実行されるタスクの場合、Amazon ECS はタスクを配置する場所と、タスク数をスケールダウンするときに終了するタスクを決定する必要があります。Amazon ECS は、キャパシティプロバイダーの起動テンプレートで指定されたインスタンス要件、CPU やメモリなどのタスク定義で指定された要件、およびタスクの配置に関する制約に基づいて、この決定を行います。

**注記**  
Amazon ECS マネージドインスタンスはタスク配置戦略をサポートしていません。Amazon ECS は、アクセス可能なアベイラビリティーゾーンにタスクを分散するよう最善を尽くします。

Amazon ECSがタスクを配置する際は、以下のプロセスでコンテナインスタンスを選択します。

1. タスク定義の CPU、GPU、メモリ、ポートの要件を満たすコンテナインスタンスを識別します。

1. タスク配置の制約事項を満たすコンテナインスタンスを識別します。

1. キャパシティプロバイダーの起動テンプレートで指定されたインスタンスの要件を満たしているコンテナインスタンスを特定します。

1. タスクを配置するコンテナインスタンスを選択します。

## EC2
<a name="ec2-launch-type"></a>

EC2 起動タイプを使用するタスクには、Amazon ECS ではタスク定義で指定されている CPU やメモリなどの要件に基づいてタスクを配置する場所を決定する必要があります。同様に、タスク数を減らすときも、Amazon ECS でどのタスクを終了させるか決定する必要があります。タスク配置の戦略と制約を適用することで、Amazon ECS がタスクを配置および終了する方法をカスタマイズできます。

デフォルトのタスク配置戦略は、タスクを手動 (スタンドアロンタスク) で実行するのか、それともサービス内で実行するのかによって異なります。Amazon ECS サービスの一部として実行されるタスクの場合、タスク配置戦略は `attribute:ecs.availability-zone` を使用した `spread` です。サービス内にないタスクには、デフォルトのタスク配置の制約はありません。詳細については、「[Amazon ECS でコンテナをスケジュールする](scheduling_tasks.md)」を参照してください。

**注記**  
タスク配置戦略はベストエフォートです。Amazon ECSは、最適な配置オプションが利用できない場合でも、タスクの配置を試みます。ただし、タスク配置の制約が有効な場合、タスクを配置できないことがあります。

タスク配置戦略と制約は併用できます。例えば、タスク配置戦略とタスク配置制約を使用して、アベイラビリティーゾーン間でタスクを分散し、各アベイラビリティーゾーン内のメモリに基づいてビンパックタスクを分散できます。ただし、G2 インスタンスのみです。

Amazon ECSがタスクを配置する際は、以下のプロセスでコンテナインスタンスを選択します。

1. タスク定義の CPU、GPU、メモリ、ポートの要件を満たすコンテナインスタンスを識別します。

1. タスク配置の制約事項を満たすコンテナインスタンスを識別します。

1. タスク配置戦略を満たすコンテナインスタンスを識別します。

1. タスクを配置するコンテナインスタンスを選択します。

## Fargate
<a name="fargate-launch-type"></a>

タスクの配置戦略および制約事項は、Fargate を使用しているタスクをサポートしていません。Fargate は、アクセス可能なアベイラビリティーゾーンにタスクを分散するよう最善を尽くします。キャパシティープロバイダーに Fargate と Fargate Spot の両方が含まれている場合、スプレッドの動作はキャパシティープロバイダーごとに異なります。

# Amazon ECS マネージドインスタンスの自動スケーリングとタスク配置
<a name="managed-instance-auto-scaling"></a>

Amazon ECS マネージドインスタンスは、インテリジェントなアルゴリズムを使用してクラスターの容量を自動的にスケーリングし、インフラストラクチャ全体にタスクを効率的に配置します。これらのアルゴリズムの仕組みを理解することで、サービス設定を最適化し、配置動作をトラブルシューティングできます。

## タスク配置アルゴリズム
<a name="managed-instance-task-placement-algorithm"></a>

Amazon ECS マネージドインスタンスは、タスクのスケジュールを設定する際に可用性、リソース使用率、ネットワーク要件のバランスを確保する高度な配置アルゴリズムを使用します。

### 分散アベイラビリティーゾーン
<a name="managed-instance-az-spread-behavior"></a>

デフォルトでは、Amazon ECS マネージドインスタンスは複数のアベイラビリティーゾーンにタスクを分散することで可用性を優先します。
+ 複数のタスクが配置されているサービスの場合、Amazon ECS マネージドインスタンスは、可能であれば異なるアベイラビリティーゾーンの少なくとも 3 つのインスタンスに分散します。
+ この動作は耐障害性を実現しますが、インスタンスあたりのリソース使用率が低下する可能性があります。
+ 拡散アベイラビリティーゾーンは、ビンのパッキングの最適化よりも優先されます

### ビンのパッキング動作
<a name="managed-instance-bin-packing"></a>

Amazon ECS マネージドインスタンスは、リソース使用率を最大化するためにビンパッキングを実行できますが、この動作はネットワーク設定の影響を受けます。
+ ビンのパッキングを実現するには、単一のサブネットを使用するようにサービスを設定します。
+ マルチサブネット設定では、リソース密度よりもアベイラビリティーゾーンの分散が優先されます。
+ ビンのパッキングは、スケーリングイベント中よりも初回サービス起動時に実施される可能性が高くなります。

### ENI の密度に関する考慮事項
<a name="managed-instance-eni-density"></a>

`awsvpc` ネットワークモードを使用するサービスの場合、Amazon ECS マネージドインスタンスは配置を決定する際に Elastic Network Interface (ENI) の密度を考慮します。
+ `awsvpc` モードの各タスクには専用の ENI が必要です
+ インスタンスタイプには、タスク密度に影響するさまざまな ENI 制限があります
+ Amazon ECS マネージドインスタンスは、ターゲットインスタンスを選択するときに ENI の可用性を考慮します

**注記**  
ENI 密度の計算は、配置の決定を最適化するために継続的に改善されています。

## キャパシティプロバイダーの決定ロジック
<a name="managed-instance-capacity-provider-decisions"></a>

Amazon ECS マネージドインスタンスのキャパシティプロバイダーは、次の複数の要因に基づいてスケーリングと配置を決定します。

リソースの要件  
保留中のタスクの CPU、メモリ、ネットワークに関する要件

インスタンスの可用性  
既存のインスタンス全体の現在の容量と使用率

ネットワーキングの制約  
サブネット設定と ENI の可用性

アベイラビリティーゾーンの分散  
複数のアベイラビリティーゾーンにわたる耐障害性の維持

## 設定オプション
<a name="managed-instance-configuration-options"></a>

### サブネットの選択戦略
<a name="managed-instance-subnet-strategy"></a>

サブネット設定は、タスク配置の動作に大きな影響を与えます。

複数のサブネット (デフォルト)  
高可用性を実現するためにアベイラビリティーゾーンの拡散を優先する  
インスタンスあたりのリソース使用率が低下する可能性があります  
耐障害性を必要とする本番稼働用ワークロードに推奨

単一サブネット  
ビンパッキングを有効にしてリソース使用率を高める  
タスクを 1 つのアベイラビリティーゾーンに集約することで耐障害性を低減する  
開発またはコスト最適化ワークロードに適しています

### ネットワークモードに関する考慮事項
<a name="managed-instance-network-mode-considerations"></a>

選択したネットワークモードは、配置の決定に影響します。
+ `awsvpc` モード – 各タスクには専用の ENI が必要であり、インスタンスあたりのタスク密度が制限されます。
+ `host` モード – タスクはホストのネットワークを直接使用し、配置は主にリソースの可用性によって決定されます。

### CPU アーキテクチャに関する考慮事項
<a name="managed-instance-cpu-architecture-considerations"></a>

タスク定義で指定した `cpuArchitecture` は、特定のアーキテクチャにタスクを配置するために使用されます。`cpuArchitecture` を指定しない場合、Amazon ECS はキャパシティプロバイダーの設定に基づいて、使用可能な CPU アーキテクチャにタスクを配置しようとします。`X86_64` または `ARM64` のどちらかを指定できます。

## タスク配置のトラブルシューティング
<a name="managed-instance-troubleshooting-placement"></a>

### 一般的な配置パターン
<a name="managed-instance-common-placement-patterns"></a>

予想される配置パターンを理解すると、通常の動作と潜在的な問題を区別できるようになります。

分散ディストリビューション  
部分的な使用率で複数のインスタンスに分散されたタスク  
複数のサブネットを使用する場合の通常の動作  
リソース効率よりも可用性が優先されることを示します

集約された配置  
使用率の高い少数のインスタンスに配置された複数のタスク  
単一サブネット設定を使用する場合に想定されます  
最初のサービス起動中に発生する可能性があります

不均等な分散  
一部のインスタンスの使用率が非常に高い一方で、他のインスタンスについては使用率が低い状態が継続します。  
ENI の制限またはリソースの制約を示している場合があります  
インスタンスタイプとネットワーク設定の確認を検討する

### 配置動作の最適化
<a name="managed-instance-placement-optimization"></a>

特定の要件に合わせてタスク配置を最適化するには:

1. コスト最適化のニーズと照らし合わせて可用性要件を評価する

1. 優先順位に基づいて適切なサブネット設定を選択する

1. ネットワークモードに適した ENI 容量を持つインスタンスタイプを選択する

1. 配置パターンをモニタリングし、必要に応じて設定を調整する

## ベストプラクティス
<a name="managed-instance-best-practices"></a>
+ **本稼働ワークロードの場合** – 異なるアベイラビリティーゾーン間で複数のサブネットを使用して高可用性を確保し、リソース使用率のトレードオフを受け入れます。
+ **開発またはテストの場合** – リソース使用率を最大化し、コストを削減するために単一サブネット設定を検討する
+ **`awsvpc` モードの場合** – 配置の制約に抵触することを回避するために、十分な ENI 容量を持つインスタンスタイプを選択する
+ **コスト最適化の場合** – 使用率パターンをモニタリングし、可用性と効率性のバランスを取るようにサービス設定を調整する
+ **トラブルシューティングの場合** — 予期しない配置パターンを調査するときに、サブネット設定とネットワークモードを確認する

# 戦略を使用して Amazon ECS タスク配置を定義する
<a name="task-placement-strategies"></a>

EC2 起動タイプを使用するタスクには、Amazon ECS ではタスク定義で指定されている CPU やメモリなどの要件に基づいてタスクを配置する場所を決定する必要があります。同様に、タスク数を減らすときも、Amazon ECS でどのタスクを終了させるか決定する必要があります。タスク配置の戦略と制約を適用することで、Amazon ECS がタスクを配置および終了する方法をカスタマイズできます。

デフォルトのタスク配置戦略は、タスクを手動 (スタンドアロンタスク) で実行するのか、それともサービス内で実行するのかによって異なります。Amazon ECS サービスの一部として実行されるタスクの場合、タスク配置戦略は `attribute:ecs.availability-zone` を使用した `spread` です。サービス内にないタスクには、デフォルトのタスク配置の制約はありません。詳細については、「[Amazon ECS でコンテナをスケジュールする](scheduling_tasks.md)」を参照してください。

**注記**  
タスク配置戦略はベストエフォートです。Amazon ECSは、最適な配置オプションが利用できない場合でも、タスクの配置を試みます。ただし、タスク配置の制約が有効な場合、タスクを配置できないことがあります。

タスク配置戦略と制約は併用できます。例えば、タスク配置戦略とタスク配置制約を使用して、アベイラビリティーゾーン間でタスクを分散し、各アベイラビリティーゾーン内のメモリに基づいてビンパックタスクを分散できます。ただし、G2 インスタンスのみです。

Amazon ECSがタスクを配置する際は、以下のプロセスでコンテナインスタンスを選択します。

1. タスク定義の CPU、GPU、メモリ、ポートの要件を満たすコンテナインスタンスを識別します。

1. タスク配置の制約事項を満たすコンテナインスタンスを識別します。

1. タスク配置戦略を満たすコンテナインスタンスを識別します。

1. タスクを配置するコンテナインスタンスを選択します。

タスク配置戦略は、サービス定義または `placementStrategy` パラメータを使用したタスク定義で指定できます。

```
"placementStrategy": [
    {
        "field": "The field to apply the placement strategy against",
        "type": "The placement strategy to use"
    }
]
```

タスクを実行するとき ([RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html))、新しいサービスを作成するとき ([CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html))、または既存のサービスを更新するとき ([UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)) に戦略を指定できます。

次の表は利用可能なタイプとフィールドを説明しています。


| 型 | 有効なフィールド値 | 
| --- | --- | 
| binpack タスクはコンテナインスタンスに配置され、未使用の CPU またはメモリを最小にします。この戦略は、使用中のコンテナインスタンスの数を最小限に抑えます。 この戦略が使用されてスケールインアクションが実行されると、Amazon ECS はタスクを終了します。タスクが終了した後にコンテナインスタンスに残されたリソース量に基づいてこれが実行されます。タスクの終了後に利用可能なリソースが最も多く残るコンテナインスタンスが、そのタスクを終了されます。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 
| random タスクはランダムに配置されます。 | 使用されていない | 
| spreadタスクは指定された値に基づいて均等に配置されます。 サービスタスクはそのサービスからのタスクに基づいて分散されます。スタンドアロンタスクは、同じタスクグループからのタスクに基づいて分散されます。タスクグループの詳細については、「[Amazon ECS タスクをグループ化する](task-groups.md)」を参照してください。`spread` 戦略が使用されてスケールインアクションが実行されると、Amazon ECS は、アベイラビリティーゾーン間のバランスを維持するタスクを選択して終了します。アベイラビリティーゾーン内では、タスクはランダムに選択されます。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 

タスク配置の戦略は、既存のサービスに対しても更新できます。詳細については、「[Amazon ECS がタスクをコンテナインスタンスに配置する方法](task-placement.md)」を参照してください。

実行する順序で戦略の配列を作成することで、複数の戦略を使用するタスク配置戦略を作成できます。例えば、複数のアベイラビリティーゾーンにタスクを分散し、各アベイラビリティーゾーン内のメモリに基づいてタスクをビンパックする場合、アベイラビリティーゾーン戦略を指定し、その後にメモリ戦略を指定します。戦略の例については、「[Amazon ECS タスク配置戦略の例](strategy-examples.md)」を参照してください。

# Amazon ECS タスク配置戦略の例
<a name="strategy-examples"></a>

次のアクションを使用してタスク配置戦略を指定できます。[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)、[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)、および [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)。

**Topics**
+ [複数のアベイラビリティーゾーンでタスクを均等に分散する](#even-az)
+ [すべてのインスタンスでタスクを均等に分散する](#even-instance)
+ [メモリに基づいてタスクをビンパックする](#binpack)
+ [タスクをランダムに配置します。](#random)
+ [複数のアベイラビリティーゾーンでタスクを均等に分散し、各アベイラビリティーゾーン内で複数のインスタンスでタスクを均等に分散する](#az-instance)
+ [複数のアベイラビリティーゾーンでタスクを均等に分散し、各アベイラビリティーゾーン内でメモリに基づいてタスクをビンパックする](#az-memory)
+ [複数のインスタンスでタスクを均等に分散し、メモリに基づいてタスクをビンパックする](#instance-memory)

## 複数のアベイラビリティーゾーンでタスクを均等に分散する
<a name="even-az"></a>

次の戦略は、アベイラビリティーゾーン間でタスクを均等に分散します。

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    }
]
```

## すべてのインスタンスでタスクを均等に分散する
<a name="even-instance"></a>

次の戦略は、すべてのインスタンス間でタスクを均等に分散します。

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## メモリに基づいてタスクをビンパックする
<a name="binpack"></a>

次の戦略はメモリに基づいてタスクをビンパックします。

```
"placementStrategy": [
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## タスクをランダムに配置します。
<a name="random"></a>

次の戦略はタスクをランダムに配置します。

```
"placementStrategy": [
    {
        "type": "random"
    }
]
```

## 複数のアベイラビリティーゾーンでタスクを均等に分散し、各アベイラビリティーゾーン内で複数のインスタンスでタスクを均等に分散する
<a name="az-instance"></a>

次の戦略は、アベイラビリティーゾーン間でタスクを均等に分散し、次に各アベイラビリティーゾーン内でインスタンスを均等に分散します。

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## 複数のアベイラビリティーゾーンでタスクを均等に分散し、各アベイラビリティーゾーン内でメモリに基づいてタスクをビンパックする
<a name="az-memory"></a>

次の戦略は、アベイラビリティーゾーン間でタスクを均等に分散し、次に各アベイラビリティーゾーン内でメモリに基づいてタスクをビンパックします。

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## 複数のインスタンスでタスクを均等に分散し、メモリに基づいてタスクをビンパックする
<a name="instance-memory"></a>

次の戦略は、すべてのインスタンスでタスクを均等に分散し、各インスタンス内のメモリに基づいてタスクをビンパックします。

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

# Amazon ECS タスクをグループ化する
<a name="task-groups"></a>

一連の関連するタスクを識別してタスクグループで配置できます。同じタスクグループ名のすべてのタスクは、`spread`タスクの配置戦略の使用時に、セットとして見なされます。例えば、データベースおよびウェブサーバーなど、1 つのクラスターで異なるアプリケーションを実行していることを想定します。データベースを確実にアベイラビリティーゾーン間に均等に分散するには、それらのデータベースを`databases`という名前のタスクグループに追加し、`spread`タスク配置戦略を使用します。詳細については、「[戦略を使用して Amazon ECS タスク配置を定義する](task-placement-strategies.md)」を参照してください。

タスクグループはタスク配置の制約にも使用できます。`memberOf` 制約でタスクグループを指定したとき、タスクは指定されたタスクグループ内のコンテナインスタンスにのみ送信されます。例については、[Amazon ECS タスク配置の制約事項の例](constraint-examples.md)を参照してください。

デフォルトでは、カスタムタスクグループ名が指定されていない場合、スタンドアロンタスクはタスク定義ファミリ名 (例えば `family:my-task-definition`) をタスクグループ名として使用します。サービスの一部として起動されたタスクは、サービス名をタスクグループ名として使用し、変更することはできません。

タスクグループには次の要件が適用されます。
+ タスクグループ名は 255 文字以下である必要があります。
+ 各タスクを 1 つのグループと同一にできます。
+ タスクを起動後、タスクグループを変更することはできません。

# Amazon ECS がタスクに使用するコンテナインスタンスを定義する
<a name="task-placement-constraints"></a>

タスク配置の制約事項は、Amazon ECS がインスタンス上でタスクを実行できるかどうかを判断するために使用するコンテナインスタンスに関するルールです。少なくとも 1 つのコンテナインスタンスが制約に一致する必要があります。制約に一致するインスタンスがない場合、タスクは `PENDING` 状態のままになります。新しいサービスを作成するか、既存のサービスを更新するときに、サービスのタスク用にタスク配置制約を指定できます。

`placementConstraint` パラメータを使用して、サービス定義、タスク定義、またはタスクでタスク配置制約事項を指定できます。

```
"placementConstraints": [
    {
        "expression": "The expression that defines the task placement constraints",
        "type": "The placement constraint type to use"
    }
]
```

次の表は、パラメータの使用法の説明です。


| [Constraint type (制約タイプ)] | 次の場合に指定できます。 | 
| --- | --- | 
| distinctInstanceそれぞれのアクティブタスクを別々のコンテナインスタンスに配置します。Amazon ECS は、タスク配置におけるタスクの目的のステータスを確認します。例えば、既存のタスクの目的のステータスが `STOPPED` の場合 (ただし、最後のステータスが目的のステータスではない場合)、`distinctInstance` 配置の制約事項にもかかわらず、新しい受信タスクを同じインスタンスに配置することができます。したがって、同じインスタンスで最後のステータスが `RUNNING` のタスクが 2 つ表示される場合があります。 タスクの強力な分離を求めているお客様には、Fargate を使用することをお勧めします。Fargate はハードウェア仮想化環境で各タスクを実行します。これにより、これらのコンテナ化されたワークロードがネットワークインターフェイス、Fargate の一時ストレージ、CPU、またはメモリを他のタスクと共有しないことが保証されます。詳細については、「[AWS Fargate のセキュリティの概要](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf)」をご参照ください。 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-placement-constraints.html)  | 
| memberOf式を満たすコンテナインスタンスにタスクを配置します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-placement-constraints.html) | 

`memberOf` 制約事項タイプを使用すると、Amazon ECS がタスクを配置できるコンテナインスタンスを定義するクラスタークエリ言語を使用して式を作成できます。この式は、コンテナインスタンスを属性別にグループ化する方法です。この式は、`placementConstraint` の `expression ` パラメータに含まれます。

## Amazon ECS コンテナインスタンス属性
<a name="attributes"></a>

コンテナインスタンスに*属性*と呼ばれるカスタムメタデータを追加できます。各属性には名前とオプションの文字列値があります。Amazon ECSが提供する組み込み属性を使用することも、カスタム属性を定義することもできます。

次のセクションでは、組み込み型、オプション型、カスタム型属性のサンプルが含まれています。

### 組み込み属性
<a name="ecs-automatic-attributes"></a>

Amazon ECSは次の属性を自動的にコンテナインスタンスに適用します。

`ecs.ami-id`  
インスタンスの起動に使用される AMI の ID。この属性の値の例は「`ami-1234abcd`」です。

`ecs.availability-zone`  
インスタンスのアベイラビリティーゾーン。この属性の値の例は「`us-east-1a`」です。

`ecs.instance-type`  
インスタンスのインスタンスタイプ。この属性の値の例は「`g2.2xlarge`」です。

`ecs.os-type`  
インスタンスのオペレーティングシステム。この属性に指定できる値は `linux` と `windows` です。

`ecs.os-family`  
インスタンスのオペレーティングシステムのバージョン。  
Linux インスタンスの場合、有効な値は `LINUX` です。Windows インスタンスの場合、ECS は値を `WINDOWS_SERVER_<OS_Release>_<FULL or CORE>` 形式で設定します。有効な値は、`WINDOWS_SERVER_2022_FULL`、`WINDOWS_SERVER_2022_CORE`、`WINDOWS_SERVER_20H2_CORE`、`WINDOWS_SERVER_2019_FULL`、`WINDOWS_SERVER_2019_CORE`、および `WINDOWS_SERVER_2016_FULL` です。  
これは、Windows コンテナおよび Windows containers on AWS Fargate にとって重要です。なぜなら、すべての Windows コンテナの OS バージョンがホストのそれと一致する必要があるからです。コンテナイメージの Windows バージョンがホストと異なる場合、コンテナは起動しません。詳細については、マイクロソフトのドキュメント Web サイトの「[Windows コンテナバージョンの互換性](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11)」を参照してください。  
クラスターが複数の Windows バージョンを実行している場合、次の配置制約を使用して、同じバージョンで実行されている EC2 インスタンスにタスクが配置されるようにすることができます: `memberOf(attribute:ecs.os-family == WINDOWS_SERVER_<OS_Release>_<FULL or CORE>)`。詳細については、「[Amazon ECS に最適化された Windows AMI メタデータを取得する](retrieve-ecs-optimized_windows_AMI.md)」を参照してください。

`ecs.cpu-architecture`  
インスタンスの CPU アーキテクチャ。この属性の値の例は`x86_64` と `arm64` です。

`ecs.vpc-id`  
インスタンスが起動された VPC。この属性の値の例は「`vpc-1234abcd`」です。

`ecs.subnet-id`  
インスタンスが使用しているサブネット。この属性の値の例は「`subnet-1234abcd`」です。

**注記**  
Amazon ECS マネージドインスタンスは、次の属性のサブセットをサポートしています。  
`ecs.subnet-id`
`ecs.availability-zone`
`ecs.instance-type`
`ecs.cpu-architecture`

### オプションの属性
<a name="ecs-optional-attributes"></a>

Amazon ECS では、コンテナインスタンスに次の属性を追加することができます。

`ecs.awsvpc-trunk-id`  
この属性が存在する場合、インスタンスにトランクネットワークインターフェイスがあります。詳細については、「[Amazon ECS Linux コンテナインスタンスのネットワークインターフェイスを増やす](container-instance-eni.md)」を参照してください。

`ecs.outpost-arn`  
この属性が存在する場合は、Outpost の Amazon Resource Name (ARN) が含まれます。詳細については、「[AWS OutpostsのAmazon Elastic Container Service](using-outposts.md)」を参照してください。

`ecs.capability.external`  
この属性が存在する場合、インスタンスは外部インスタンスとして識別されます。詳細については、「[外部インスタンスの Amazon ECS クラスター](ecs-anywhere.md)」を参照してください。

### カスタム属性
<a name="ecs-custom-attributes"></a>

コンテナインスタンスに、カスタム属性を適用できます。例えば、「stack」という名前で「prod」という値の属性を定義できます。

カスタム属性を指定するとき、次の点を考慮する必要があります。
+ `name` は、1～128 文字で指定する必要があります。文字 (大文字と小文字)、数字、ハイフン、アンダースコア、スラッシュ、バックスラッシュ、ピリオドを使用できます。
+ `value` は、1 ～ 128 文字で指定する必要があります。文字 (大文字と小文字)、数字、ハイフン、アンダースコア、ピリオド、アットマーク (@)、スラッシュ、バックスラッシュ、コロン、またはスペースを使用できます。値の先頭または末尾にホワイトスペースを含めることはできません。

# Amazon ECS タスク用のコンテナインスタンスを定義する式を作成する
<a name="cluster-query-language"></a>

クラスタークエリは、オブジェクトをグループ化できる式です。例えば、アベイラビリティーゾーン、インスタンスタイプ、カスタムメタデータなどの属性でコンテナインスタンスをグループ化できます。詳細については、「[Amazon ECS コンテナインスタンス属性](task-placement-constraints.md#attributes)」を参照してください。

コンテナインスタンスのグループを定義した後、グループに基づいてコンテナインスタンスのタスクを配置するように Amazon ECS をカスタマイズできます。詳細については「[Amazon ECS タスクとしてのアプリケーションの実行](standalone-task-create.md)」および「[Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)」を参照してください。また、コンテナインスタンスをリスト表示する際にグループフィルタを適用できます。

## 式の構文
<a name="expression-syntax"></a>

式の構文は次のとおりです。

```
subject operator [argument]
```

**件名**  
評価する属性またはフィールド。

`agentConnected`  
Amazon ECS コンテナエージェント接続ステータスでコンテナインスタンスを選択します。このフィルタを使用して、切断されたコンテナエージェントでインスタンスを検索します。  
有効な演算子: equals (==)、not\$1equals (\$1=)、in、not\$1in (\$1in)、matches (=\$1)、not\$1matches (\$1\$1)

`agentVersion`  
Amazon ECS コンテナエージェントバージョンでコンテナインスタンスを選択します。このフィルタを使用して、Amazon ECS コンテナエージェントの古くなったバージョンを実行しているインスタンスを検索します。  
有効な演算子: equals (==)、not\$1equals (\$1=)、greater\$1than (>)、greater\$1than\$1equal (>=)、less\$1than (<)、less\$1than\$1equal (<=)

`attribute:attribute-name`  
属性でコンテナインスタンスを選択します。詳細については、「[Amazon ECS コンテナインスタンス属性](task-placement-constraints.md#attributes)」を参照してください。

`ec2InstanceId`  
Amazon EC2 インスタンス ID で、コンテナインスタンスを選択します。  
有効な演算子: equals (==)、not\$1equals (\$1=)、in、not\$1in (\$1in)、matches (=\$1)、not\$1matches (\$1\$1)

`registeredAt`  
コンテナインスタンス登録日で、コンテナインスタンスを選択します。このフィルタを使用して、新しく登録されたインスタンスまたは古いインスタンスを検索します。  
有効な演算子: equals (==)、not\$1equals (\$1=)、greater\$1than (>)、greater\$1than\$1equal (>=)、less\$1than (<)、less\$1than\$1equal (<=)  
有効な日付形式: 2018-06-18T22:28:28\$100:00、2018-06-18T22:28:28Z、2018-06-18T22:28:28、2018-06-18

`runningTasksCount`  
実行中のタスクの数でコンテナインスタンスを選択します。このフィルタを使用して、空またはほぼ空 (実行中のタスクがほぼない) のインスタンスを検索します。  
有効な演算子: equals (==)、not\$1equals (\$1=)、greater\$1than (>)、greater\$1than\$1equal (>=)、less\$1than (<)、less\$1than\$1equal (<=)

`task:group`  
コンテナインスタンスをタスクグループで選択します。詳細については、「[Amazon ECS タスクをグループ化する](task-groups.md)」を参照してください。

**オペレーター**  
比較演算子。以下の演算子がサポートされています。


|  演算子  |  説明  | 
| --- | --- | 
|  ==, が  |  文字列が等価  | 
|  \$1=、not\$1equals  |  文字列が不等価  | 
|  >、greater\$1than  |  以上  | 
|  >=、greater\$1than\$1equal  |  以上  | 
|  <、less\$1than  |  未満  | 
|  <=、less\$1than\$1equal  |  以下  | 
|  exists  |  対象が存在  | 
|  \$1exists、not\$1exists  |  サブジェクトが存在しません  | 
|  情報  |  引数リストの値  | 
|  \$1in、not\$1in  |  引数リストにない値  | 
|  =\$1、matches  |  パターンが一致  | 
|  \$1\$1、not\$1matches  |  パターンが不一致  | 

**注記**  
1 つの式に括弧を含めることはできません。ただし、複合式で優先順位を指定するために括弧を使用できます。

**引数**  
多くの演算子は、引数がリテラル値です。

`in` および `not_in` 演算子は、引数として引数リストを想定しています。次のように引数リストを指定します。

```
[argument1, argument2, ..., argumentN]
```

matches と not\$1matches 演算子は、Java の正規表現構文に準拠する引数を想定しています。詳細については、[java.util.regex.Pattern](http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html) を参照してください。

**複合式**

次のブール演算子を使用して式を結合できます。
+ &&, および
+ \$1\$1, または
+ \$1, 先頭の文字に

括弧を使用して、優先度を指定できます。

```
(expression1 or expression2) and expression3
```

## 式の例
<a name="expression-examples"></a>

以下に式の例を示します。

**例: 文字列が等価**  
次の式は指定されたインスタンスタイプのインスタンスを選択します。

```
attribute:ecs.instance-type == t2.small
```

**例: 引数リスト**  
次の式は、アベイラビリティーゾーンが us-east-1a または us-east-1b のインスタンスを選択します。

```
attribute:ecs.availability-zone in [us-east-1a, us-east-1b]
```

**例: 複合式**  
次の表現は、us-east-1d アベイラビリティーゾーンにはない G2 インスタンスを選択します。

```
attribute:ecs.instance-type =~ g2.* and attribute:ecs.availability-zone != us-east-1d
```

**例: タスクのアフィニティ**  
次の式は、`service:production` グループのタスクをホストするインスタンスを選択します。

```
task:group == service:production
```

**例: タスクのアンチアフィニティ**  
次の表現は、データベースグループでタスクをホストしないインスタンスを選択します。

```
not(task:group == database)
```

**例: 実行中のタスクの数**  
次の式は、1 つのタスクのみを実行しているインスタンスを選択します。

```
runningTasksCount == 1
```

**Amazon ECS コンテナエージェントバージョン**  
次の式は、コンテナエージェントバージョン 1.14.5 より前のバージョンを実行しているインスタンスを選択します。

```
agentVersion < 1.14.5
```

**例: インスタンス登録時**  
次の式は、2018 年 2 月 13 日以前に登録されているインスタンスを選択します。

```
registeredAt < 2018-02-13
```

**例: Amazon EC2 インスタンス ID**  
次の式は、以下の Amazon EC2 インスタンス ID のインスタンスを選択します。

```
ec2InstanceId in ['i-abcd1234', 'i-wxyx7890']
```

# Amazon ECS タスク配置の制約事項の例
<a name="constraint-examples"></a>

以下はタスク配置の制約事項の例です。

この例では、`memberOf` 制約を使用して T2 インスタンスにタスクを配置します。次のアクションを使用して指定できます。[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)、[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)、[RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html)、および [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)。

```
"placementConstraints": [
    {
        "expression": "attribute:ecs.instance-type =~ t2.*",
        "type": "memberOf"
    }
]
```

この例では、`memberOf` 制約を使用して、指定されたタスク配置方法に従って、`daemon-service` タスクグループ内のデーモンサービスタスクを持つインスタンスに、レプリカタスクを配置します。この制約により、デーモンサービスタスクはレプリカサービスタスクよりも前に EC2 インスタンスに配置されます。

`daemon-service` を デーモンサービスの名前に置き換えます。

```
"placementConstraints": [
    {
        "expression": "task:group == service:daemon-service",
        "type": "memberOf"
    }
]
```

この例では、`memberOf` 制約を使用して、指定されたタスク配置方法に従って、`databases` タスクグループ内の他のタスクとともにインスタンスにタスクを配置します。タスクグループの詳細については、「[Amazon ECS タスクをグループ化する](task-groups.md)」を参照してください。次のアクションを使用して指定できます。[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)、[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)、[RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html)、および [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)。

```
"placementConstraints": [
    {
        "expression": "task:group == databases",
        "type": "memberOf"
    }
]
```

`distinctInstance` 制約は、グループ内の各タスクを別のインスタンスに配置します。次のアクションを使用して指定できます。[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)、[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)、および [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)。

Amazon ECS は、タスク配置におけるタスクの目的のステータスを確認します。例えば、既存のタスクの目的のステータスが `STOPPED` の場合 (ただし、最後のステータスが目的のステータスではない場合)、`distinctInstance` 配置の制約事項にもかかわらず、新しい受信タスクを同じインスタンスに配置することができます。したがって、同じインスタンスで最後のステータスが `RUNNING` のタスクが 2 つ表示される場合があります。

```
"placementConstraints": [
    {
        "type": "distinctInstance"
    }
]
```

# Amazon ECS スタンドアロンタスク
<a name="standalone-tasks"></a>

バッチプロセスなど、何らかの処理を実行した後に停止するアプリケーションがある場合、アプリケーションをタスクとして実行できます。タスクを 1 回実行する場合は、コンソール、AWS CLI、API または SDK を使用できます。

レートベース、cron ベース、または 1 回限りのスケジュールでアプリケーションを実行する必要がある場合は、EventBridge Scheduler を使用してスケジュールを作成できます。

## タスクワークフロー
<a name="task-workflow"></a>

Amazon ECS タスク (スタンドアロンタスクまたは Amazon ECS サービス) を起動すると、タスクが作成され、最初に `PROVISIONING` 状態に移行されます。タスクが `PROVISIONING` 状態になると、Amazon ECS はタスクを配置するためのコンピューティング能力を見つける必要があるため、タスクもコンテナも存在しません。

Amazon ECS は、起動タイプまたはキャパシティプロバイダーの設定に基づいて、タスクに適したコンピューティング性能を選択します。キャパシティプロバイダーとキャパシティプロバイダー戦略は、Fargate と EC2 の両方で使用できます。Fargate を使用すると、クラスター容量のプロビジョニング、設定、スケーリングについて心配する必要はありません。Fargate は、お客様のタスクに必要なすべてのインフラストラクチャ管理を行います。EC2 の場合、Amazon EC2 インスタンスをクラスターに登録してクラスター容量を管理するか、クラスターの自動スケーリングを使用してコンピューティングキャパシティ管理を簡素化することができます。クラスター自動スケーリングは、クラスター容量を動的にスケーリングするため、ユーザーは実行中のタスクに集中できます。Amazon ECS は、タスク定義で指定した要件 (CPU やメモリなど)、および配置の制約事項と戦略に基づいて、タスクを配置する場所を決定します。詳細については、「[Amazon ECS がタスクをコンテナインスタンスに配置する方法](task-placement.md)」を参照してください。

マネージドスケーリングが有効になっているキャパシティープロバイダーを使用すると、コンピューティングキャパシティーの不足が原因で開始できないタスクは、すぐに失敗するのではなく、`PROVISIONING` 状態に移行されます。タスクを配置する容量が決まったら、Amazon ECS は必要なアタッチメント (`awsvpc` モード内のタスク用の Elastic Network Interface (ENI) など) をプロビジョニングします。Amazon ECS コンテナエージェントを使用してコンテナイメージをプルし、コンテナを起動します。プロビジョニングが完了し、関連するコンテナが起動すると、Amazon ECS はタスクを `RUNNING` 状態に移行します。タスクの状態の詳細については、「[Amazon ECS タスクライフサイクル](task-lifecycle-explanation.md)」を参照してください。

# Amazon ECS タスクとしてのアプリケーションの実行
<a name="standalone-task-create"></a>

1 回限りのプロセス用のタスクは AWS マネジメントコンソール を使用して作成できます。

**スタンドアロンタスクを作成するには (AWS マネジメントコンソール)**

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. Amazon ECS コンソールでは、クラスターの詳細ページまたはタスク定義リビジョンリストからスタンドアロンタスクを作成できます。選択したリソースページに応じて、次の手順を使用してスタンドアロンタスクを作成します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/standalone-task-create.html)

1. **[既存のクラスター]** で、クラスターを選択します。

   **[クラスターの作成]** を選択して、新しいクラスターでタスクを実行します。

1. クラスターのインフラストラクチャ全体にタスクを分散する方法を選択します。[**コンピューティング設定**] で、オプションを選択します。キャパシティプロバイダー戦略を使用するには、キャパシティプロバイダーをクラスターレベルで設定する必要があります。

   キャパシティプロバイダーを使用するようにクラスターを構成していない場合は、代わりに起動タイプを使用してください。

   Amazon ECS マネージドインスタンスでワークロードを実行する場合は、キャパシティプロバイダーの戦略オプションを使用する必要があります。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/standalone-task-create.html)

1. **[デプロイメント設定]** で、次の操作を行います。

   1. **[タスク定義]**に、タスク定義を入力します。
**重要**  
コンソールは、選択を検証し、選択したタスク定義ファミリーおよびリビジョンが、定義されたコンピューティング設定と互換性があることを確認します。

   1. **[Desired tasks]** (必要なタスク) で、起動するタスクの数を入力します。

   1. **[タスクグループ]**に、タスクグループの名前を入力します。

1. タスク定義で `awsvpc` ネットワークモードを使用している場合、**[Networking]** (ネットワーク) を展開します。カスタム設定を指定するには、次のステップを実行します。

   1. **VPC** の場合、使用する VPC を選択します。

   1. **[Subnets]** (サブネット) で、タスクスケジューラがタスクを配置するときに考慮する VPC 内のサブネットを 1 つ以上選択します。

   1. **[セキュリティグループ]** で、既存のセキュリティグループを選択することも、新しいセキュリティグループを作成することもできます。既存のセキュリティグループを使用するには、セキュリティグループを選択し、次のステップに進みます。新しいセキュリティグループを作成するには、[**Create a new security group (新しいセキュリティグループの作成)**] を選択します。セキュリティグループの名前、説明を指定してから、セキュリティグループのインバウンドルールを 1 つ以上追加する必要があります。

   1. **[Public IP]** (パブリック IP) では、タスクの Elastic Network Interface (ENI) にパブリック IP アドレスを自動的に割り当てるかどうかを選択します。

      AWS Fargate タスクをパブリックサブネットで実行するときに、そのタスクにパブリック IP アドレスを割り当てて、インターネットへのルートを持つようにすることができます。このフィールドを使用して EC2 タスクにパブリック IP を割り当てることはできません。詳細については、「[Fargate の Amazon ECS タスクのネットワーキングオプション](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html)」および「[Amazon ECS タスクにネットワークインターフェイスを割り当てる](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html)」を参照してください。

1. デプロイ時の設定と互換性のあるデータボリュームをタスクで使用する場合は、**[ボリューム]** を拡張してボリュームを設定できます。

   ボリューム名とボリュームタイプはタスク定義リビジョンの作成時に設定され、スタンドアロンタスクの実行時には変更できません。ボリューム名とタイプを更新するには、新しいタスク定義リビジョンを作成し、その新しいリビジョンを使用してタスクを実行する必要があります。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/standalone-task-create.html)

1. (オプション) デフォルト以外のタスク配置戦略を使用するには、**[Task Placement]** (タスクの配置) を展開し、以下のオプションから選択します。

    詳細については、「[Amazon ECS がタスクをコンテナインスタンスに配置する方法](task-placement.md)」を参照してください。
   + **[AZ バランススプレッド]** - アベイラビリティーゾーン間およびアベイラビリティーゾーン内のコンテナインスタンス間でタスクを分散します。
   + **[AZ Balanced BinPack]** - 利用可能な最小メモリでアベイラビリティーゾーン間およびコンテナインスタンス間でタスクを分散します。
   + **[ビンパック]** - CPU またはメモリの最小利用可能量に基づいてタスクを配置します。
   + **[ホストごとに 1 つのタスク]** - 各コンテナインスタンスのサービスから最大 1 タスクを配置します。
   + **[カスタム]** - 独自のタスク配置戦略を定義します。

   **[Custom]** (カスタム) を選択した場合、タスクを配置するアルゴリズムと、タスク配置時に考慮されるルールを定義します。
   + **[Strategy]** (方針) にとって **[Type]** (タイプ) そして **[Field]** (フィールド) で、アルゴリズムとアルゴリズムに使用するエンティティを選択します。

     最大 5 個の戦略を入力できます。
   + **[制約]** の **[タイプ]** および **[式]** で、制約のルールと属性を選択します。

     例えば、T2 インスタンスにタスクを配置する制約を設定するには、**[Expression]** (表現) で、**[attribute:ecs.instance-type =\$1 t2.\$1]** と入力します。

     最大 10 個の制約を入力できます。

1. (オプション) タスク IAM ロール、またはタスク定義で定義されているタスク実行ロールをオーバーライドするには、**[Task overrides]** (タスクのの上書き) を展開し、以下のステップを実行します。

   1. **[タスクロール]** で、このタスクの IAM ロールを選択します。詳細については、「[Amazon ECS タスクの IAM ロール](task-iam-roles.md)」を参照してください。

      `ecs-tasks.amazonaws.com`信頼関係を持つロールのみが表示されます。タスクの IAM ロールを作成する方法については、「[タスクの IAM ロールを作成する](task-iam-roles.md#create_task_iam_policy_and_role)」を参照してください。

   1. **[タスク実行ロール]** で、タスク実行ロールを選択します。詳細については、「[Amazon ECS タスク実行IAM ロール](task_execution_IAM_role.md)」を参照してください。

1. (オプション) コンテナコマンドと環境変数をオーバーライドするには、**[Container Overrides]** (コンテナの上書き) を展開し、コンテナを展開します。
   +  タスク定義コマンド以外のコンテナにコマンドを送信するには、**[コマンドの上書き]** で Docker コマンドを入力します。
   + **[Add Environment Variable]** (環境変数の追加) で、環境変数を追加します。**Key**に、環境変数の名前を入力します。**Value**(値) で、(文字列を囲む二重引用符 (`" "`) なしで) 環境値の文字列値を入力します。

     AWS は文字列を二重引用符 (" ") で囲み、次の形式で文字列をコンテナに渡します。

     ```
     MY_ENV_VAR="This variable contains a string."
     ```

1. (オプション) タスクを識別しやすくするには、**[Tags]** (タグ) セクションを展開し、タグを設定します。

   Amazon ECS で、新しく起動されたすべてのタスクに、クラスター名とタスク定義のタグで自動でタグ付けするには、**[Turn on Amazon ECS managed tags]** (Amazon ECS で管理されたタグを有効にする) を選択し、**[Task definition]** (タスク定義) を選択します。

   タグを追加または削除します。
   + [タグを追加] **[Add tag]** (タグを追加) を選択し、以下を実行します。
     + [**キー**] にはキー名を入力します。
     + [**値**] にキー値を入力します。
   + [タグの削除] タグの横にある [**タグの削除**] を選択します。

1. **[作成]** を選択します。

# Amazon EventBridge スケジューラを使用して Amazon ECS タスクをスケジュールする
<a name="tasks-scheduled-eventbridge-scheduler"></a>

EventBridge スケジューラーはサーバーレススケジューラであり、一元化されたマネージドサービスからタスクを作成、実行、管理できます。イベントバスやルールに依存しない、1 回限りの定期的なスケジューリング機能を提供します。EventBridge スケジューラは高度にカスタマイズ可能で、EventBridge のスケジュールルールよりもスケーラビリティが高く、ターゲット API 操作と AWS サービスの範囲が広がります。EventBridge スケジューラには、EventBridge スケジューラコンソールでタスクに設定できる以下のスケジュールが用意されています。
+ レートベース 
+ cron ベース

  cron ベースのスケジュールはどのタイムゾーンでも設定できます。
+ 1 回限りのスケジュール

  1 回限りのスケジュールはどのタイムゾーンでも設定できます。

Amazon ECS は Amazon EventBridge スケジューラを使用してスケジュールできます。

Amazon ECS コンソールでスケジュールされたタスクを作成できますが、現在、EventBridge Scheduler コンソールではさらに多くの機能を提供しています。

タスクをスケジュールする前に、次のステップを完了します。

1. タスクが実行されるサブネット ID とサブネットのセキュリティグループ ID を取得するには、VPC コンソールを使用します。詳細については、「[VPC のサブネット](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html)」と「*Amazon VPC ユーザーガイド*」の「[セキュリティグループを使用して AWS リソースへのトラフィックを制御する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)」を参照してください。

1. EventBridge スケジューラの実行ロールを設定します。詳細については、「*Amazon EventBridge スケジューラユーザーガイド*」の「[実行ロールを設定する](https://docs.aws.amazon.com/scheduler/latest/UserGuide/setting-up.html#setting-up-execution-role)」を参照してください。

1. キャパシティープロバイダー戦略を使用してタスクを実行するには、キャパシティープロバイダーをクラスターに関連付ける必要があります。

**コンソールを使用して新しいスケジュールを作成するには**

1. Amazon EventBridge スケジューラコンソール ([https://console.aws.amazon.com/scheduler/home](https://console.aws.amazon.com/scheduler/home/)) を開きます。

1.  **[スケジュール]** ページで、**[スケジュールを作成]** を選択します。

1.  **[スケジュールの詳細を指定]** ページの **[スケジュールの名前と説明]** セクションで、次を実行します。

   1. **[スケジュール名]** で、スケジュールの名前を入力します。例えば、**MyTestSchedule**。

   1. (オプション) **[説明]** で、スケジュールの説明を入力します。例えば、**TestSchedule**。

   1. **[スケジュールグループ]** で、スケジュールグループを選択します。グループがない場合は、**[デフォルト]** を選択します。スケジュールグループを作成するには、**[独自のスケジュールを作成]** を選択します。

      スケジュールグループを使用して、スケジュールのグループにタグを追加します。

1. スケジュールオプションを選択します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

1. (オプション) 前のステップで **[定期的なスケジュール]** を選択した場合は、**[時間枠]** セクションで次を実行します。

   1. **[タイムゾーン]** で、タイムゾーンを選択します。

   1. **[開始日時]** で、有効な日付を `YYYY/MM/DD` 形式で入力してから、タイムスタンプを 24 時間 (`hh:mm`) 形式で指定します。

   1. **[終了日時]** で、有効な日付を `YYYY/MM/DD` 形式で入力してから、タイムスタンプを 24 時間 (`hh:mm`) 形式で指定します。

1. [**次へ**] を選択します。

1. **[ターゲットを選択]** ページで、次の操作を行います。

   1. **[すべての API]** を選択し、検索ボックスで **ECS** と入力します。

   1. **[Amazon ECS]** を選択します。

   1. 検索ボックスで **RunTask** と入力し、**[RunTask]** を選択します。

   1. **[ECS クラスター]** で、クラスターを選択します。

   1. **[ECS タスク]** で、タスクに使用するタスク定義を選択します。

   1. クラスターのインフラストラクチャ全体にタスクを分散する方法を選択します。**コンピューティングオプション** を展開し、次のいずれかのオプションを選択します    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

   1. **[サブネット]** で、タスクを実行するサブネット ID を入力します。

   1. **[セキュリティグループ]** で、サブネットのセキュリティグループ ID を入力します。

   1. (オプション) デフォルト以外のタスク配置戦略を使用するには、**[配置制約]** を展開し、制約を入力します。

       詳細については、「[Amazon ECS がタスクをコンテナインスタンスに配置する方法](task-placement.md)」を参照してください。

   1. (オプション) タスクを識別しやすくするために、**[タグ]** でタグを設定します。

      新しく起動されたすべてのタスクに対して、Amazon ECS がタスク定義タグを自動的にタグ付けするようにするには、**[Amazon ECS マネージドタグを有効にする]** を選択します。

1. [**次へ**] を選択します。

1. **[Settings]** (設定) ページで、以下の操作を行います。

   1. スケジュールをオンにするには、**[スケジュールの状態]** で **[スケジュールを有効にする]** をオンに切り替えます。

   1. スケジュールの再試行ポリシーを設定するには、**[再試行ポリシーとデッドレターキュー (DLQ)]** で次を実行します。
      + **[再試行]** を切り替えてオンにします。
      + **[イベントの最大保持時間]** で、EventBridge スケジューラが未処理のイベントを保持しなければならない最大の **[時間]** と **[分]** を入力します。
      + 最大 24 時間です。
      + **[最大再試行回数]** で、ターゲットがエラーを返した場合に EventBridge スケジューラがスケジュールを再試行する最大回数を入力します。

         再試行の最大値は 185 です。

      再試行ポリシーを使用すると、スケジュールがそのターゲットの呼び出しに失敗した場合、EventBridge スケジューラはスケジュールを再実行します。設定されている場合は、スケジュールの最大保持時間と再試行を設定する必要があります。

   1. EventBridge スケジューラが未配信のイベントを保存する場所を選択します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

   1. カスタマーマネージドキーを使用してターゲットの入力を暗号化するには、**[暗号化]** で **[暗号化設定をカスタマイズする (高度)]** を選択します。

      このオプションを選択した場合は、既存の KMS キー ARN を入力するか、**[AWS KMS key を作成]** を選択して AWS KMS コンソールに移動します。EventBridge スケジューラが保管中のデータを暗号化する方法の詳細については、「*Amazon EventBridge スケジューラユーザーガイド*」の「[保管中の暗号化](https://docs.aws.amazon.com/scheduler/latest/UserGuide/encryption-rest.html)」を参照してください。

   1. **[許可]** で、**[既存のロールを使用]** を選択してから、ロールを選択します。

      EventBridge スケジューラに新しい実行ロールを作成させるには、**[このスケジュールの新しいロールを作成]** を選択します。その後、**[ロール名]** で名前を入力します。このオプションを選択すると、EventBridge スケジューラは、テンプレート化されたターゲットに必要な許可をロールにアタッチします。

1. [**次へ**] を選択します。

1.  **[スケジュールの確認と作成]** ページで、スケジュールの詳細を確認します。各セクションで、そのステップに戻って詳細を編集するには、**[編集]** を選択します。

1. **[スケジュールを作成]** を選択します。

   **[スケジュール]** ページで、新規および既存のスケジュールのリストを表示できます。**[ステータス]** 列で、新しいスケジュールが **[有効]** になっていることを確認します。

## 次のステップ
<a name="eventbridge-scheduler-next-steps"></a>

EventBridge スケジューラコンソールまたは AWS CLI を使用し、スケジュールを管理できます。詳細については、「*Amazon EventBridge スケジューラユーザーガイド*」の「[スケジュールの管理](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule.html)」を参照してください。

# Amazon ECS タスクの停止
<a name="standalone-task-stop"></a>

スタンドアロンタスクを実行し続ける必要がなくなった場合は、タスクを停止できます。Amazon ECS コンソールでは、1 つ以上のタスクを簡単に停止できます。

スタンドアロンの停止したタスクは、再起動できません。

サービスを停止したい場合は、「[コンソールを使用して Amazon ECS サービスの削除](delete-service-v2.md)」を参照してください。

**スタンドアロンタスクを停止するには (AWS マネジメントコンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[クラスター]** ページで、クラスターを選択してクラスターの詳細ページに移動します。

1. クラスターの詳細ページで、**[タスク]** タブを選択します。

1. **[起動タイプのフィルター]** リストを使用して、起動タイプごとにタスクをフィルターできます。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/standalone-task-stop.html)

# Amazon ECS サービス
<a name="ecs_services"></a>

Amazon ECS サービスを使用すると、Amazon ECS クラスター内で、タスク定義の指定した数のインスタンスを同時に実行して維持できます。タスクの 1 つが失敗または停止した場合、Amazon ECS サービススケジューラはタスク定義の別のインスタンスを起動してそれを置き換えます。これは、サービスで必要な数のタスクを維持するのに役立ちます。

オプションで、ロードバランサーの背後でサービスを実行することもできます。ロードバランサーは、サービスに関連付けられたタスク間でトラフィックを分散させます。

長時間実行されるステートレスサービスおよびアプリケーションには、サービススケジューラを使用することをお勧めします。サービススケジューラにより、指定したスケジューリング戦略が順守され、タスクが失敗したときに タスクが再スケジュールされます。例えば、基盤となるインフラストラクチャに障害が発生した場合、サービススケジューラはタスクを再スケジュールします。タスク配置の戦略と制約を使用して、スケジューラがタスクを配置および終了する方法をカスタマイズできます。サービス内のタスクが停止すると、スケジューラはタスクを置き換えるために新しいタスクを起動します。このプロセスは、サービスが使用するスケジュール戦略に基づいて、サービスがタスクの必要数に達するまで続行されます。

また、コンテナのヘルスチェックまたはロードバランサーのターゲットグループのヘルスチェックが失敗すると、サービススケジューラーによって、異常であると判断されたタスクが置き換えられます。この置き換え動作は、`maximumPercent` および `desiredCount` のサービス定義パラメータによって異なります。タスクが異常とマークされた場合、サービススケジューラーによってまず置き換えタスクが開始されます。次に以下が発生します。
+ 置き換えタスクのヘルスステータスが `HEALTHY` になると、サービススケジューラーが異常のあるタスクを停止します。
+ 置き換えタスクのヘルスステータスが `UNHEALTHY` の場合、スケジューラーは異常のある置き換えタスクまたは既存の異常タスクのいずれかを停止して、タスク総数が `desiredCount` と等しくなるようにします。

`maximumPercent` パラメーターによって、置き換えタスクを先に開始できないようにスケジューラーが制限されている場合、スケジューラーは異常のあるタスクをランダムに 1 つずつ停止して容量を解放してから置き換えタスクを開始します。異常のあるタスクがすべて正常なタスクに置き換えられるまで、起動と停止のプロセスが続きます。異常なタスクがすべて置き換えられ、正常なタスクだけが実行中になると、合計タスク数が `desiredCount` を超える場合、タスク数が `desiredCount` になるまで、正常なタスクが無作為に停止されます。`maximumPercent` および `desiredCount` の詳細については、「[サービス定義パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html)」を参照してください。

サービススケジューラには、タスクが繰り返し起動に失敗した場合にタスクを再起動する頻度を調整するロジックが含まれています。`RUNNING` 状態にならずにタスクが停止すると、サービススケジューラは起動の試行の速度を遅くし始め、サービスイベントメッセージを送信します。この動作により、問題を解決する前に、失敗したタスクに不要なリソースが使用されるのを防ぐことができます。サービスが更新されると、サービススケジューラは正常なスケジューリング動作を再開します。詳細については、「[Amazon ECS サービスのスロットルロジック](service-throttle-logic.md)」および「[Amazon ECS のサービスイベントメッセージを表示する](service-event-messages.md)」を参照してください。

## インフラストラクチャコンピューティングオプション
<a name="service-conmpute-options"></a>

タスクを分散するコンピューティングオプションが 2 つあります。
+ [capacity provider strategy] (キャパシティープロバイダー戦略) により、Amazon ECS がタスクを 1 つまたは複数のキャパシティプロバイダーに分散させます。

  Amazon ECS マネージドインスタンスでワークロードを実行する場合は、キャパシティプロバイダーの戦略オプションを使用する必要があります。

  **[capacity provider strategy]** (キャパシティープロバイダー戦略) では、コンソールはデフォルトでコンピューティングオプションを選択します。次に、コンソールがデフォルトを選択するときに使用する順序について説明します。
  + クラスターにデフォルトのキャパシティープロバイダー戦略が定義されている場合は、その戦略が選択されます。
  + クラスターにデフォルトのキャパシティープロバイダー戦略が定義されていないが、Fargate キャパシティープロバイダーをクラスターに追加している場合は、キャパシティープロバイダーを使用するカスタム `FARGATE` キャパシティープロバイダー戦略が選択されます。
  + クラスターにデフォルトのキャパシティープロバイダー戦略が定義されていないが、クラスターに 1 つ以上の Auto Scaling グループキャパシティープロバイダーが追加されている場合は、**[Use custom (アドバンスト)]** オプションが選択され、戦略を手動で定義する必要があります。
  + クラスターにデフォルトのキャパシティープロバイダー戦略が定義されておらず、クラスターにキャパシティープロバイダーが追加されていない場合は、Fargate起動タイプが選択されます。
+ [起動タイプ] により、Amazon ECS は Fargate またはクラスターに登録された EC2 インスタンスのいずれかでタスクを直接起動します。

  Amazon ECS マネージドインスタンスでワークロードを実行する場合は、キャパシティプロバイダーの戦略オプションを使用する必要があります。

  デフォルトでは、サービスはクラスター VPC のサブネットで開始されます。

## サービスのオートスケーリング
<a name="service-auto-scaling-options"></a>

サービスの自動スケーリングは、Amazon ECS サービスで必要なタスク数を自動的に増減する機能です。Amazon ECS は アプリケーション Auto Scaling サービスを活用してこの機能を提供します。

詳細については、「[Amazon ECS サービスを自動的にスケールする](service-auto-scaling.md)」を参照してください。

## サービスの負荷分散
<a name="service-load-balancing-options"></a>

AWS Fargate でホストされている Amazon ECS サービスでは、Application Load Balancer、Network Load Balancer、および Gateway Load Balancer がサポートされています。次の表を使用して、使用するロードバランサーのタイプを確認してください。


| ロードバランサーのタイプ | 以下の場合に使用 | 
| --- | --- | 
|  Application Load Balancer  | HTTP/HTTPS (またはレイヤー 7) トラフィックをルーティングします。Amazon Load Balancer は Amazon ECS サービスでの使用に便利な複数の機能を提供しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs_services.html) | 
| Network Load Balancer | TCP または UDP (またはレイヤー 4) トラフィックをルーティングします。 | 
| Gateway Load Balancer | TCP または UDP (またはレイヤー 4) トラフィックをルーティングします。 ファイアウォール、侵入検知および防止システム、ディープパケットインスペクションシステムなどの仮想アプライアンスを使用します。 | 

詳細については、「[ロードバランサーを使用して Amazon ECS サービストラフィックを分散する](service-load-balancing.md)」を参照してください。

## 相互接続サービス
<a name="service-connecting-options"></a>

Amazon ECS サービスとして実行される他のアプリケーションにアプリケーションを接続する必要がある場合、Amazon ECS ではロードバランサーを使用せずに、次の方法で実行できます。
+ Service Connect – 短い名前と標準ポートを使用した自動検出によるサービス間の通信を実現します。
+ サービス検出 – サービス検出では、Route 53 を使用してサービスの名前空間を作成し、DNS を介して検出できるようにします。
+ Amazon VPC Lattice – VPC Lattice は、複数のアカウントおよび VPC 間でサービスを接続、保護、モニタリングするフルマネージドのアプリケーションネットワーキングサービスです。関連するコストが発生します。

詳細については、「[Amazon ECS サービスを相互接続する](interconnecting-services.md)」を参照してください。

# Amazon ECS サービスデプロイコントローラーと戦略
<a name="ecs_service-options"></a>

サービスをデプロイする前に、デプロイするためのオプションとサービスが使用する機能を確認してください。

## スケジュール戦略
<a name="service-strategy"></a>

利用できる 2 つのサービススケジューラ戦略があります。
+ `REPLICA` - レプリカスケジュール戦略では、クラスター全体で必要数のタスクを配置して維持します。デフォルトでは、サービススケジューラによってタスクはアベイラビリティーゾーン間に分散されます。タスク配置の戦略と制約を使用すると、タスク配置の決定をカスタマイズできます。詳細については、「[レプリカスケジューリング戦略](#service_scheduler_replica)」を参照してください。
+ `DAEMON` - デーモンのスケジュール戦略では、指定したすべてのタスク配置制約を満たすクラスター内のアクティブなコンテナインスタンスごとに、1 つのタスクのみをデプロイします。この戦略を使用する場合、タスクの必要数や配置戦略、サービスの自動スケーリングポリシーを指定する必要はありません。詳細については、「[デーモンスケジューリング戦略](#service_scheduler_daemon)」を参照してください。
**注記**  
Fargate タスクは `DAEMON` スケジュール戦略をサポートしていません。

### レプリカスケジューリング戦略
<a name="service_scheduler_replica"></a>

*レプリカ*スケジュール戦略では、クラスターに必要数のタスクを配置して維持します。

Fargate でタスクを実行するサービスについては、サービススケジューラは、新しいタスクの起動時や実行中タスクの停止時に、アベイラビリティーゾーン間の負荷バランスを維持するよう最大限試みます。タスク置き換え戦略や制約を指定する必要はありません。

EC2 インスタンスでタスクを実行するサービスを作成する場合、オプションでタスク配置戦略と制約を指定して、タスク配置に関する決定をカスタマイズできます。タスク配置戦略または制約が指定されていない場合、デフォルトでは、サービススケジューラはタスクをアベイラビリティーゾーン全体に分散します。サービススケジューラは、次のロジックを使用します。
+ クラスター内のどのコンテナインスタンスがサービスのタスク定義をサポートできるか (必要な CPU、メモリ、ポート、コンテナインスタンス属性がなど) を判断します。
+ サービスに定義された配置の制約を満たすコンテナインスタンスを特定します。
+ デーモンサービスに依存するレプリカサービス (たとえば、タスクがログを使用する前に実行する必要があるデーモンログルータスクなど) がある場合は、デーモンサービスタスクがレプリカサービスタスクよりも前に EC2 インスタンスに配置されるようにするタスク置き換え制約を作成します。詳細については、「[Amazon ECS タスク配置の制約事項の例](constraint-examples.md)」を参照してください。
+ 配置戦略が定義されている場合は、その戦略を使用して残りの候補からインスタンスを選択します。
+ 定義された配置戦略がない場合は、次のロジックを使用してクラスター内のアベイラビリティーゾーン全体にタスクが配分されます。
  + 有効なコンテナインスタンスをソートします。それぞれのアベイラビリティーゾーンで、このサービスの実行中のタスクの数が最も少ないインスタンスを優先します。例えば、ゾーン A に実行中のサービスタスクが 1 つあり、ゾーン B と C に実行中のサービスタスクがない場合、ゾーン B または C のいずれかの有効なコンテナインスタンスが配置に最適と見なされます。
  + 前のステップに基づいて、新しいサービスタスクを最適なアベイラビリティーゾーン内の有効なコンテナインスタンスに配置します。このサービスで実行中のタスク数が最も少ないコンテナインスタンスを優先します。

サービスで高い利用可能性を確保できるようになるため、サービス再調整機能は `REPLICA` 戦略を使用する際に使用することをお勧めします。

### デーモンスケジューリング戦略
<a name="service_scheduler_daemon"></a>

*デーモン*のスケジュール戦略では、指定したすべてのタスク配置制約を満たすクラスター内のアクティブなコンテナインスタンスごとに、1 つのタスクのみをデプロイします。サービススケジューラは、実行中のタスクのタスク配置の制約事項を評価し、配置制約を満たさないタスクを停止します。この戦略を使用する場合、タスクの必要数や配置戦略を指定したり、サービス自動スケーリングポリシーを使用したりする必要はありません。

Amazon ECS は、CPU、メモリ、およびネットワークインターフェイスを含むコンテナインスタンスのコンピューティングリソースをデーモンタスク用に予約します。他のレプリカサービスを使用してクラスターでデーモンサービスを起動すると、Amazon ECS はデーモンタスクを優先します。これは、デーモンタスクがインスタンス上で起動する最初のタスクであり、すべてのレプリカタスクが停止した後に停止する最後のタスクであることを意味します。この戦略により、保留中のレプリカ・タスクでリソースが使用されず、デーモンタスクでリソースを使用できるようになります。

デーモンサービススケジューラは `DRAINING` ステータスのインスタンスにはタスクを配置しません。コンテナインスタンスが `DRAINING` ステータスに移行すると、そのインスタンス上のデーモンタスクは停止します。サービススケジューラはまた、新しいコンテナインスタンスがいつクラスターに追加されるかをモニタリングし、追加されたらそれらのインスタンスにデーモンタスクを追加します。

デプロイメント設定を指定する場合、`maximumPercent` パラメータの値は `100` (パーセンテージとして指定) である必要があります。これは、設定されていない場合に使用されるデフォルト値です。`minimumHealthyPercent` パラメータのデフォルト値は `0` (パーセンテージで指定) です。

デーモンサービスの配置制約を変更するには、サービスを再起動する必要があります。Amazon ECS は、デーモンタスクの対象となるインスタンスに予約されているリソースを動的に更新します。既存のインスタンスの場合、スケジューラはインスタンスにタスクを配置しようとします。

タスク定義でタスクサイズまたはコンテナリソースの予約が変更されると、新しいデプロイが開始されます。新しいデプロイは、サービスを更新したり、タスク定義の異なるリビジョンを設定したりするときにも開始されます。Amazon ECS は、デーモンの更新された CPU およびメモリ予約をピックアップし、デーモンのタスクでその容量をブロックします。

上記のいずれかの場合に十分なリソースがない場合、次のことが起こります。
+ タスクの配置が失敗します。
+ CloudWatch イベントが生成されます。
+ Amazon ECS は、リソースが使用可能になるのを待って、インスタンスでタスクのスケジュールを試行します。
+ Amazon ECS は、配置制約基準を満たさなくなったリザーブドインスタンスを解放し、対応するデーモンタスクを停止します。

デーモンのスケジューリング戦略は、次の場合に使用できます。
+ アプリケーションコンテナの実行
+ ログ記録、モニタリング、トレースタスク用のサポートコンテナの実行

Fargate 起動タイプ、`CODE_DEPLOY` または `EXTERNAL` のデプロイメントコントローラータイプを使用するタスクは、デーモンスケジューリング戦略をサポートしません。

サービススケジューラがタスクの実行を停止する場合、アベイラビリティーゾーン間のクラスターの負荷バランスを維持します。スケジューラは、次のロジックを使用します。
+ 配置戦略が定義されている場合、その戦略を使用して終了するタスクを選択します。例えば、サービスにアベイラビリティーゾーンの spread 戦略が定義されている場合、1 つのタスクが選択され、残りのタスクは最適に分散されたまま残ります。
+ 配置戦略が定義されていない場合は、次のロジックを使用してクラスター内のアベイラビリティーゾーン全体への配分を維持します。
  + 有効なコンテナインスタンスをソートします。それぞれのアベイラビリティーゾーンで、このサービスの実行中のタスクの数が最も多いインスタンスを優先します。例えば、実行中のサービスタスクがゾーン A には 1 つ、ゾーン B とゾーン C にはそれぞれ 2 つずつある場合、ゾーン B またはゾーン C のいずれかのコンテナインスタンスが終了に最適と見なされます。
  + 前のステップに基づいて、最適なアベイラビリティーゾーン内のコンテナインスタンスで、タスクを停止します。このサービスで実行中のタスク数が最も多いコンテナインスタンスを優先します。

## デプロイコントローラー
<a name="service_deployment-controllers"></a>

デプロイコントローラーは、サービスにタスクがデプロイされる方法を決定するメカニズムです。有効なオプションは次のとおりです。
+ ECS

  `ECS` デプロイコントローラーを使用するサービスを作成する際、次のデプロイ戦略から選択できます。
  + `ROLLING`: *ローリング更新* (`ROLLING`) デプロイ戦略を使用するサービスを作成すると、Amazon ECS サービススケジューラによって現在実行中のタスクが新しいタスクに置き換えられます。ローリング更新中にサービスに対して Amazon ECS が追加または削除するタスク数は、サービスデプロイ設定により制御されます。

    ローリング更新のデプロイは、次のシナリオに最適です。
    + サービスの段階的な更新: サービス全体を一度にオフラインにせず、サービスを段階的に更新する必要がある場合。
    + 制限のあるリソース要件: 2 つの完全な環境を同時に実行することで生じる追加のリソースコストを回避したい場合 (ブルー/グリーンデプロイで必要)。
    + 許容されるデプロイ時間: ローリング更新はタスクを 1 つずつ置き換えるため、アプリケーションがより長いデプロイプロセスを許容できる場合。
    + インスタントロールバックが不要: サービスで数秒ではなく数分かかるロールバックプロセスを許容できる場合。
    + シンプルなデプロイプロセス: 複数の環境、ターゲットグループ、リスナーを管理する複雑さのないシンプルなデプロイアプローチを求める場合。
    + ロードバランサーの要件なし: サービスにロードバランサー、Application Load Balancer、Network Load Balancer、Service Connect (ブルー/グリーンデプロイに必要) を使用しない場合または必要としない場合。
    + ステートフルアプリケーション: アプリケーションで、2 つの並列環境の実行を困難にする状態が維持される場合。
    + コストに敏感: デプロイ中に重複する環境を実行しないことで、デプロイコストを最小限に抑えたい場合。

    ローリング更新はサービスのデフォルトのデプロイ戦略であり、多くの一般的なアプリケーションシナリオでデプロイの安全性とリソース効率のバランスを実現します。
  + `BLUE_GREEN`: *ブルー/グリーン*デプロイ戦略 (`BLUE_GREEN`) はブルーおよびグリーンという 2 つの同一の本番環境を実行することで、ダウンタイムおよびリスクを軽減するリリース方法です。Amazon ECS ブルー/グリーンデプロイを使用すると、本番トラフィックをルーティングする前に、新しいサービスリビジョンを検証できます。このアプローチによって変更をデプロイするより安全な方法が実現され、必要に応じてすばやくロールバックできます。

    Amazon ECS ブルー/グリーンデプロイは次のシナリオに最適です。
    + サービス検証: 本番トラフィックをルーティングする前に、新しいサービスリビジョンを検証する必要がある場合
    + ダウンタイムなし: サービスにダウンタイムのないデプロイが必要な場合
    + インスタントロールバック: 問題が検出された場合、すばやくロールバックする機能が必要な場合
    + ロードバランサーの要件: サービスが Application Load Balancer、Network Load Balancer、Service Connect を使用する場合
  + `LINEAR`: *リニア*デプロイ戦略 (`LINEAR`) は、トラフィックを現在の本番稼働環境から新しい環境に、指定した期間にわたって同じ割合で徐々に移行します。Amazon ECS リニアデプロイでは、トラフィックの移行のペースを制御し、本番稼働トラフィックの量が増えるにつれて新しいサービスリビジョンを検証できます。

    Amazon ECS リニアデプロイは次のシナリオに最適です。
    + 段階的な検証: トラフィックの増加に伴って新しいサービスバージョンを段階的に検証する必要がある場合
    + パフォーマンスモニタリング: デプロイ中にメトリクスとパフォーマンスをモニタリングするための時間が必要な場合
    + リスクの最小化: 新しいバージョンを本番稼働トラフィックに段階的に公開してリスクを最小限に抑える必要がある場合
    + ロードバランサーの要件: サービスが Application Load Balancer、Network Load Balancer、Service Connect を使用する場合
  + `CANARY`: *カナリア*デプロイ戦略 (`CANARY`) では、まずトラフィックのごく一部を新しいサービスリビジョンに移行し、指定した期間が経過した後に残りのトラフィックをすべて一度に移行します。これにより、完全なデプロイを実施する前にユーザーのサブセットで新しいバージョンをテストできます。

    Amazon ECS カナリアデプロイは次のシナリオに最適です。
    + 機能テスト: 完全なロールアウト前に少数のユーザーサブセットで新機能をテストする必要がある場合
    + 本番稼働用検証: 実際の本番稼働トラフィックでパフォーマンスと機能を検証する必要がある場合
    + ブラスト半径制御: 新しいバージョンで問題が見つかった場合にブラスト半径を最小限に抑える必要がある場合
    + ロードバランサーの要件: サービスが Application Load Balancer、Network Load Balancer、Service Connect を使用する場合
+ 外部

  サードパーティーのデプロイコントローラーを使用します。
+ ブルー/グリーンデプロイ (AWS CodeDeploy を搭載)

  CodeDeploy によってアプリケーションの更新されたバージョンが新しい置き換えタスクセットとしてインストールされ、本番トラフィックが元のアプリケーションタスクセットから置き換えタスクセットに再ルーティングされます。デプロイが正常に完了すると、元のタスクセットは終了します。本番トラフィックをルーティングする前に、サービスの新しいデプロイを検証するためにこのデプロイコントローラーを使用します。

# Amazon ECS デプロイの失敗検出
<a name="deployment-failure-detection"></a>

Amazon ECS には、デプロイの失敗を検出する 2 つの方法があります。
+ デプロイサーキットブレーカー
+ CloudWatch アラーム

どちらの方法も、失敗したデプロイを既知の最後の正常な状態に自動的にロールバックするように設定できます。

以下の点を考慮してください。
+ どちらの方法も、ローリング更新デプロイおよびブルー/グリーンデプロイのタイプのみをサポートしています。
+ 両方の方法を使用すると、いずれかによってデプロイの失敗がトリガーされる可能性があります。
+ ロールバック方法には、COMPLETED 状態の前のデプロイが必要です。
+ EventBridge イベントは、デプロイ状態の変更に対して生成されます。

# Amazon ECS デプロイサーキットブレーカーが障害を検出する方法
<a name="deployment-circuit-breaker"></a>

デプロイサーキットブレーカーは、タスクが定常状態に到達したかどうかを判断する、ローリング更新メカニズムです。デプロイサーキットブレーカーには、デプロイが失敗した場合に、 `COMPLETED` 状態のデプロイに自動的にロールバックするオプションがあります。

サービスデプロイの状態が変わったとき、Amazon ECS はサービスデプロイ状態変更イベントを EventBridge に送信します。これにより、サービスデプロイの状態を監視するためのプログラムによる方法がもたらされます。詳細については、「[Amazon ECS サービスデプロイ状態変更イベント](ecs_service_deployment_events.md)」を参照してください。デプロイを開始するための手動アクションを実行できるように、`eventName` が `SERVICE_DEPLOYMENT_FAILED` の EventBridge ルールをを使用して作成および監視することをお勧めします。詳細については、「*Amazon EventBridge ユーザーガイド*」の「[EventBridge の開始方法](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html)」を参照してください。

デプロイサーキットブレーカーは、デプロイが失敗したと判断すると、`COMPLETED` 状態にある最新のデプロイを探します。このデプロイをロールバックデプロイとして使用します。ロールバックが開始されると、デプロイは `COMPLETED` から `IN_PROGRESS` に変わります。つまり、デプロイは `COMPLETED` 状態になるまで次のロールバックの対象にはなりません。デプロイサーキットブレーカーが `COMPLETED` 状態のデプロイを見つけられない場合、サーキットブレーカーは新しいタスクを起動せず、デプロイは停止します。

サービスを作成すると、スケジューラーは起動に失敗したタスクを 2 段階で追跡します。
+ ステージ 1 - スケジューラーはタスクが RUNNING 状態に移行するかどうかを監視します。
  + 成功 - RUNNING 状態に移行したタスクが複数あるため、デプロイメントが COMPLETED 状態に移行する可能性があります。障害基準はスキップされ、サーキットブレーカーはステージ 2 に移行します。
  + 失敗 - RUNNING 状態に移行しなかったタスクが連続して発生し、デプロイが FAILED 状態に移行する可能性があります。
+ ステージ 2 - RUNNING 状態のタスクが 1 つ以上あると、デプロイメントはこの段階に入ります。サーキットブレーカーは、評価対象の現在のデプロイのタスクのヘルスチェックをチェックします。検証済みのヘルスチェックは、Elastic Load Balancing、AWS Cloud Map サービスヘルスチェック、コンテナヘルスチェックです。
  + 成功 - ヘルスチェックに合格した実行状態のタスクが少なくとも 1 つあります。
  + 失敗 - ヘルスチェックに失敗したために置き換えられたタスクが失敗のしきい値に達しました。

サービスでデプロイサーキットブレーカーメソッドを使用する際には、以下を考慮してください。EventBridge がルールを生成します。
+ この `DescribeServices` レスポンスは、デプロイの状態、`rolloutState` および `rolloutStateReason` についての洞察を提供します。新しいデプロイが開始されると、ロールアウトの状態は `IN_PROGRESS` 状態から始まります。サービスが定常状態になると、ロールアウトの状態は `COMPLETED` に移行します。サービスが定常状態にならず、サーキットブレーカーがオンになっている場合、デプロイは `FAILED` 状態に移行します。`FAILED` 状態のデプロイでは、新しいタスクは起動されません。
+ 開始および完了したデプロイに対して送信されるサービスデプロイの状態変更イベントに加えて、Amazon ECS はサーキットブレーカーがオンになったデプロイが失敗した場合にもイベントを送信します。これらのイベントは、デプロイが失敗した理由やロールバックのためにデプロイが開始されたかどうかについての詳細情報を提供します。詳細については、「[Amazon ECS サービスデプロイ状態変更イベント](ecs_service_deployment_events.md)」を参照してください。
+ 以前のデプロイが失敗し、ロールバックが発生したために新しいデプロイが開始された場合、サービスデプロイ状態変更イベントの `reason` フィールドには、ロールバックのためにデプロイが開始されたことが示されます。
+ デプロイサーキットブレーカーは、ローリング更新 (`ECS`) デプロイコントローラーを使用する Amazon ECS サービスでのみサポートされています。
+ Amazon ECS コンソールを使用するか、CloudWatch オプションと共にデプロイサーキットブレーカーを使用する場合は AWS CLI を使用する必要があります。詳細については、「*AWS Command Line Interfaceリファレンス*」の「[定義済みのパラメータを使用したサービスの作成](create-service-console-v2.md#create-custom-service)」および「[create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)」を参照してください。

以下の `create-service` AWS CLI の例は、デプロイサーキットブレーカーと共にロールバックオプションが使用されている場合の Linux サービスの作成方法を示しています。

```
aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
```

例:

デプロイ 1 は `COMPLETED` 状態にあります。

デプロイ 2 は起動できないため、サーキットブレーカーはデプロイ 1 にロールバックされます。デプロイ 1 は `IN_PROGRESS` 状態に移行します。

デプロイ 3 が開始され、`COMPLETED` 状態のデプロイがないため、デプロイ 3 はロールバックやタスクの起動ができません。

## 失敗しきい値
<a name="failure-threshold"></a>

デプロイサーキットブレーカはしきい値を計算し、その値を使用してデプロイを `FAILED` 状態に移行するタイミングを判断します。

デプロイサーキットブレーカの最小しきい値は 3 であり、最大しきい値は 200 です。値を次の式に使用してデプロイの失敗を判断します。

```
Minimum threshold <= 0.5 * desired task count => maximum threshold
```

計算結果が最低値の 3 より大きく、最大値の 200 より小さい場合、障害のしきい値は計算されたしきい値 (切り上げ) に設定されます。

**注記**  
しきい値のどちらも変更できません。

デプロイステータスチェックには 2 つの段階があります。

1. デプロイサーキットブレーカは、デプロイの一部であるタスクを監視して `RUNNING` 状態のタスクを確認します。スケジューラは、現在のデプロイのタスクが `RUNNING` 状態のときに失敗条件を無視して次のステージに進みます。タスク `RUNNING` 状態に到達できなかった場合、デプロイサーキットブレーカは故障数を 1 つ増やします。障害カウントがしきい値に等しい場合、デプロイは `FAILED` としてマークされます。

1. `RUNNING` 状態のタスクが 1 つ以上ある場合、このステージが開始されます。デプロイサーキットブレーカは、現在のデプロイのタスクの次のリソースにヘルスチェックを実行します。
   + Elastic Load Balancing ロードバランサー
   + AWS Cloud Map サービス
   + Amazon ECS コンテナヘルスチェック

   タスクのヘルスチェックが失敗した場合、デプロイサーキットブレーカーは障害数を 1 つ増やします。障害カウントがしきい値に等しい場合、デプロイは `FAILED` としてマークされます。

例をいくつか、次のテーブルに示します。


| 希望タスク数 | 計算 | Threshold | 
| --- | --- | --- | 
|  1  |  <pre>3 <= 0.5 * 1 => 200</pre>  | 3 (計算値は最小値より小さい) | 
|  25  |  <pre>3 <= 0.5 * 25 => 200</pre>  | 13 (値は切り上げられます) | 
|  400  |  <pre>3 <= 0.5 * 400 => 200</pre>  | 200 | 
|  800  |  <pre>3 <= 0.5 * 800 => 200</pre>  | 200 (計算値は最大値を超えています) | 

たとえば、しきい値が 3 の場合、サーキットブレーカーは故障回数が 0 に設定された状態で起動します。タスクが `RUNNING` 状態に到達できなかった場合、デプロイサーキットブレーカは故障数を 1 つ増やします。障害カウントが 3 である場合、デプロイは `FAILED` としてマークされます。

ロールバックオプションの使用方法に関するその他の例については、「[Amazon ECS デプロイサーキットブレーカーのお知らせ](https://aws.amazon.com/blogs/containers/announcing-amazon-ecs-deployment-circuit-breaker/)」を参照してください。

# CloudWatch アラームが Amazon ECS のデプロイ障害を検出する方法
<a name="deployment-alarm-failure"></a>

指定された CloudWatch アラームが `ALARM` 状態になったことを検出したとき、デプロイが失敗に設定されるように Amazon ECS を設定できます。

オプションとして、失敗したデプロイを最後に完了したデプロイにロールバックするように設定できます。

以下の `create-service` AWS CLI の例は、デプロイアラームと共にロールバックオプションが使用されている場合の Linux サービスの作成方法を示しています。

```
aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
```

サービスで Amazon CloudWatch アラームメソッドを使用する場合は、以下を考慮してください。
+ 本番トラフィックが移行した後に、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。Amazon ECS は、デプロイに関連するアラーム設定に基づいてこの期間を計算します。この値は設定できません。
+ `deploymentConfiguration` リクエストパラメータには `alarms` のデータ型が含まれるようになっています。アラーム名、メソッド使用の有無、アラームがデプロイの失敗を示したときのロールバック開始の有無について指定できます。詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)」を参照してください。
+ この `DescribeServices` レスポンスは、デプロイの状態、`rolloutState` および `rolloutStateReason` についての洞察を提供します。新しいデプロイが開始されると、ロールアウトの状態は `IN_PROGRESS` 状態から始まります。サービスが定常状態になりベイク時間が完了すると、ロールアウトの状態は `COMPLETED` に移行します。サービスが定常状態にならず、アラームが `ALARM` 状態になった場合、デプロイは `FAILED` 状態に移行します。`FAILED` 状態のデプロイでは、新しいタスクは起動されません。
+ 開始および完了したデプロイに対して Amazon ECS から送信されるサービスデプロイの状態変更イベントに加えて、Amazon ECS はアラームを使用するデプロイが失敗した場合にもイベントを送信します。これらのイベントは、デプロイが失敗した理由やロールバックのためにデプロイが開始されたかどうかについての詳細情報を提供します。詳細については、「[Amazon ECS サービスデプロイ状態変更イベント](ecs_service_deployment_events.md)」を参照してください。
+ 以前のデプロイが失敗し、ロールバックがオンになったために新しいデプロイが開始された場合、サービスデプロイ状態変更イベントの `reason` フィールドには、ロールバックのためにデプロイが開始されたことが示されます。
+ 障害検出にデプロイサーキットブレーカーと Amazon CloudWatch アラームを使用する場合、どちらかのメソッドの基準が満たされ次第、どちらかがデプロイの失敗を開始します。デプロイの失敗を開始したメソッドでロールバックオプションが使用されている場合は、ロールバックが発生します。
+ Amazon CloudWatch アラームは、ローリング更新 (`ECS`) デプロイコントローラーを使用する Amazon ECS サービスでのみサポートされています。
+ このオプションは、Amazon ECS コンソールまたは AWS CLI を使用して設定できます。詳細については、「*AWS Command Line Interfaceリファレンス*」の「[定義済みのパラメータを使用したサービスの作成](create-service-console-v2.md#create-custom-service)」および「[create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)」を参照してください。
+ デプロイステータスが長時間 `IN_PROGRESS` のままになっていると気付くことがあるかもしれません。これは、アクティブなデプロイを削除し終えるまで Amazon ECS のステータスは変化せず、また、ベイク時間が過ぎるまでは、このステータスが変更されることがないためです。アラームの設定によっては、デプロイにアラームを使用しない場合よりも数分長くかかるように思える場合もあります (新しいプライマリタスクセットがスケールアップされ、古いデプロイがスケールダウンされる場合であってもです)。CloudFormation タイムアウトを使用する場合は、タイムアウトを増やすことを検討してください。詳細については、「AWS CloudFormation ユーザーガイド」の「[テンプレートでの待機条件の作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html)」を参照してください。
+ Amazon ECS は `DescribeAlarms` を呼び出してアラームをポーリングします。`DescribeAlarms` の呼び出しはアカウントに関連付けられた CloudWatch の Service Quotas にカウントされます。`DescribeAlarms` を呼び出す AWS サービスが他にもある場合は、アラームをポーリングする際に Amazon ECS に影響が及ぶ可能性があります。例えば、別のサービスがクォータに達するだけの `DescribeAlarms` 呼び出しを行うと、そのサービスがスロットリングされると共に Amazon ECS もスロットリングされ、アラームをポーリングできなくなります。スロットリング期間中にアラームが生成されると、Amazon ECS はアラームを見逃してロールバックが行われない可能性があります。デプロイに他の影響はありません。CloudWatch の Service Quotas の詳細については、「*CloudWatch ユーザーガイド*」の「[CloudWatch Service Quotas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm)」を参照してください。
+ デプロイの開始時にアラームの状態が `ALARM` である場合、Amazon ECS はそのデプロイ中はアラームの監視を行いません (Amazon ECS はアラーム設定を無視します)。この動作により、初期デプロイの失敗を修正するために、新たなデプロイを開始する場合に対応しています。

## 推奨アラーム
<a name="ecs-deployment-alarms"></a>

次のアラームメトリクスを使用することをお勧めします。
+ Application Load Balancer を使用する場合は、`HTTPCode_ELB_5XX_Count` および `HTTPCode_ELB_4XX_Count` の Application Load Balancer メトリクスを使用します。これらのメトリクスは HTTP スパイクをチェックします。Application Load Balancer メトリクスの詳細については、「*Application Load Balancer のユーザーガイド*」の「[Application Load Balancer の CloudWatch メトリクス](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)」を参照してください。
+ 既存のアプリケーションがある場合は、`CPUUtilization` および `MemoryUtilization` のメトリクスを使用します。これらのメトリクスは、クラスターまたはサービスが使用する CPU とメモリの割合をチェックします。詳細については、「[考慮事項](cloudwatch-metrics.md#enable_cloudwatch)」を参照してください。
+ タスクで Amazon Simple Queue Service キューを使用する場合は、`ApproximateNumberOfMessagesNotVisible` Amazon SQS メトリクスを使用します。このメトリクスは、遅延の発生によりすぐに読み取ることのできない、キュー内のメッセージ数をチェックします。Amazon SQS メトリクスの詳細については、「*Amazon Simple Queue Service デベロッパーガイド*」の「[Amazon SQS で使用できる CloudWatch メトリクス](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html)」を参照してください。

## ベイク時間
<a name="deployment-bake-time"></a>

サービスのデプロイにロールバックオプションを使用すると、Amazon ECS はターゲットサービスリビジョンがデプロイされてから CloudWatch アラームを送信するまでの間さらに待機します。これはベイク時間と呼ばれます。この時間は、次のイベントの後に開始されます。
+ ターゲットサービスリビジョンのすべてのタスクが実行中で、正常な状態である
+ ソースサービスリビジョンは 0% にスケールダウンされている

デフォルトのベイク時間は 5 分未満です。サービスデプロイは、ベイク時間が経過すると完了としてマークされます。

ローリングデプロイのベイク時間を設定できます。CloudWatch アラームを使用して障害を検出し、ベイク時間を変更してから Amazon ECS のデフォルトを設定する場合は、ベイク時間を手動で設定する必要があります。

# Amazon ECS サービスデプロイのライフサイクルフック
<a name="deployment-lifecycle-hooks"></a>

デプロイが開始されると、ライフサイクルステージが実行されます。これらのステージは「IN\$1PROGRESS」や「正常」などの状態の場合があります。指定されたライフサイクルステージで Amazon ECS がユーザーに代わって実行する Lambda 関数のライフサイクルフックを使用できます。関数は次のいずれかになります。
+ 15 分以内にヘルスチェックを検証する非同期 API。
+ ライフサイクルフックの完了を評価する別の非同期プロセスを開始するポーリング API。

関数の実行が完了したら、デプロイを続行するために `hookStatus` を返す必要があります。`hookStatus` が返されないか、関数が失敗した場合、デプロイはロールバックされます。以下は `hookStatus` の値です。
+ `SUCCEEDED` – デプロイは次のライフサイクルステージへと進みます。
+ `FAILED` – デプロイは最後に正常に処理されたデプロイにロールバックされます。
+ `IN_PROGRESS` – Amazon ECS により、短期間の後に関数が再度実行されます。デフォルトではこれは 30 秒間隔ですが、この値は `callBackDelay` とともに `hookStatus` を返すことでカスタマイズできます。

次の例では、カスタムコールバックの遅延を使用して `hookStatus` を返す方法が示されます。この例では、Amazon ECS によってこのフックはデフォルトの 30 秒ではなく、60 秒で再試行されます。

```
{
    "hookStatus": "IN_PROGRESS",
    "callBackDelay": 60
}
```

ロールバックが発生すると、Amazon ECS によって次のライフサイクルステージのライフサイクルフックが実行されます。
+ PRODUCTION\$1TRAFFIC\$1SHIFT
+ TEST\$1TRAFFIC\$1SHIFT

## ライフサイクルペイロード
<a name="service-deployment-lifecycle-payloads"></a>

 ECS サービスデプロイにライフサイクルフックを設定すると、Amazon ECS によってデプロイプロセスの特定段階でこれらのフックが呼び出されます。各ライフサイクルステージでは、デプロイの現在の状態に関する情報を含む JSON ペイロードが提供されます。このドキュメントでは、各ライフサイクルステージのペイロード構造について説明します。

### 一般的なペイロード構造
<a name="common-payload-structure"></a>

 すべてのライフサイクルステージのペイロードには、次の共通フィールドが含まれます。
+  `serviceArn` – サービスの Amazon リソースネーム (ARN)。
+  `targetServiceRevisionArn` – デプロイされるターゲットサービスリビジョンの ARN。
+  `testTrafficWeights` – サービスリビジョン ARN が対応するテストトラフィックの重みの割合を示すマップ。
+  `productionTrafficWeights` – サービスリビジョン ARN が対応する本番トラフィックの重みの割合を示すマップ。

### ライフサイクルステージペイロード
<a name="lifecycle-stage-payloads"></a>

#### RECONCILE\$1SERVICE
<a name="reconcile-service"></a>

 このステージは、サービスの調整中にデプロイプロセスの開始時に発生します。以下は、このライフサイクルステージのペイロードの一例を示しています。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  },
  "productionTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  }
}
```

 **この段階での想定:** 
+ プライマリタスクセットは 0% スケール

#### PRE\$1SCALE\$1UP
<a name="pre-scale-up"></a>

 このステージは、新しいタスクがスケールアップされる前に発生します。以下は、このライフサイクルステージのペイロードの一例を示しています。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **この段階での想定:** 
+ グリーンサービスのリビジョンタスクは 0% スケール

#### POST\$1SCALE\$1UP
<a name="post-scale-up"></a>

 このステージは、新しいタスクがスケールアップされた後で正常であるときに発生します。以下は、このライフサイクルステージのペイロードの一例を示しています。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **この段階での想定:** 
+ グリーンサービスのリビジョンタスクは 100% スケール
+ グリーンサービスのリビジョンのタスクは正常

#### TEST\$1TRAFFIC\$1SHIFT
<a name="test-traffic-shift"></a>

 このステージは、テストトラフィックがグリーンサービスのリビジョンタスクに移行されるときに発生します。

以下は、このライフサイクルステージのペイロードの一例を示しています。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  },
  "productionTrafficWeights": {}
}
```

 **この段階での想定:** 
+ テストトラフィックは、グリーンサービスのリビジョンタスクに移行中。

#### POST\$1TEST\$1TRAFFIC\$1SHIFT
<a name="post-test-traffic-shift"></a>

 このステージは、テストトラフィックが新しいタスクに完全に移行された後に発生します。

以下は、このライフサイクルステージのペイロードの一例を示しています。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **この段階での想定:** 
+ テストトラフィックの 100% をグリーンサービスのリビジョンタスクに移行済み。

#### PRODUCTION\$1TRAFFIC\$1SHIFT
<a name="production-traffic-shift"></a>

 このステージは、本番トラフィックがグリーンサービスのリビジョンタスクに移行されるときに発生します。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  }
}
```

 **この段階での想定:** 
+ 本番トラフィックは、グリーンサービスのリビジョンに移行中。

#### POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT
<a name="post-production-traffic-shift"></a>

 このステージは、本番トラフィックがグリーンサービスのリビジョンタスクに完全に移行された後に発生します。

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **この段階での想定:** 
+ 本番トラフィックの 100% をグリーンサービスのリビジョンタスクに移行済み。

### ライフサイクルステージのカテゴリ
<a name="lifecycle-stage-categories"></a>

 ライフサイクルステージは 2 つのカテゴリに分類されます。

1.  **1 回の呼び出しステージ** – これらのステージは、サービスのデプロイ中に 1 回のみ呼び出されます。
   + PRE\$1SCALE\$1UP
   + POST\$1SCALE\$1UP
   + POST\$1TEST\$1TRAFFIC\$1SHIFT
   + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT

1.  **定期的な呼び出しステージ** – ロールバックオペレーションが発生したときなどに、これらのステージはサービスのデプロイ中に複数回呼び出される場合があります。
   + TEST\$1TRAFFIC\$1SHIFT
   + PRODUCTION\$1TRAFFIC\$1SHIFT

### ライフサイクルフック中のデプロイステータス
<a name="deployment-status-during-lifecycle-hooks"></a>

 ライフサイクルフックの実行中に、デプロイステータスはすべてのライフサイクルステージで `IN_PROGRESS` になります。


| Lifecycle Stage | デプロイのステータス | 
| --- | --- | 
| RECONCILE\$1SERVICE | IN\$1PROGRESS | 
| PRE\$1SCALE\$1UP | IN\$1PROGRESS | 
| POST\$1SCALE\$1UP | IN\$1PROGRESS | 
| TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 

# Amazon ECS サービスデプロイの停止
<a name="stop-service-deployment"></a>

デプロイが失敗してサーキットブレーカーまたは CloudWatch アラームによって検出されなかった場合に、デプロイを手動で停止することができます。次の停止タイプを使用できます。
+ ロールバック – このオプションは、サービスデプロイを一つ前のサービスリビジョンにロールバックします。

  このオプションは、サービスデプロイにロールバックオプションを設定していなかった場合でも使用できます。

次のいずれかの状態のデプロイを停止できます。サービスデプロイ状態の詳細については、「[Amazon ECS サービスデプロイを使用してサービス履歴を表示する](service-deployment.md)」を参照してください。
+ PENDING (保留中) – サービスデプロイが ROLLBACK\$1REQUESTED 状態に移行した後、ロールバックオペレーションが開始されます。
+ IN\$1PROGRESS (進行中) – サービスデプロイが ROLLBACK\$1REQUESTED 状態に移行した後、ロールバックオペレーションが開始します。
+ STOP\$1REQUESTED (停止リクエスト済み) – サービスデプロイの停止処理が継続します。
+ ROLLBACK\$1REQUESTED (ロールバックのリクエスト済み) – サービスデプロイはロールバックオペレーションを続行します。
+ ROLLBACK\$1IN\$1PROGRESS (ロールバックの進行中) – サービスデプロイはロールバックオペレーションを続行します。

## 手順
<a name="stop-service-deployment-procedure"></a>

開始する前に、サービスデプロイを表示するために必要なアクセス許可を設定します。詳細については、「[Amazon ECS サービスデプロイを表示するために必要なアクセス許可](service-deployment-permissions.md)」を参照してください。

------
#### [ Amazon ECS Console ]

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。

   [サービスの詳細] ページが表示されます。

1. [サービスの詳細] ページで、**[デプロイ]** を選択します。

   デプロイページが表示されます。

1. **[進行中のデプロイ]** で、**[ロールバック]** を選択します。次に、確認ウィンドウで、**[ロールバック]** を選択します。

------
#### [ AWS CLI ]

1. `list-service-deployments` を実行して、サービスデプロイ ARN を取得します。

   *user-input* を独自の値に置き換えます。

   ```
   aws ecs list-service-deployments --cluster cluster-name --service service-name
   ```

   停止するデプロイの `serviceDeploymentArn` に注意してください。

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/cluster-name/service-name",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/cluster-name",
               "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/cluster-name/service-name/4980306466373577095",
               "status": "SUCCESSFUL"
           }
       ]
   }
   ```

1. `stop-service-deployments` を実行します。`list-service-deployments` から返された `serviceDeploymentArn` を使用します。

   *user-input* を独自の値に置き換えます。

   ```
   aws ecs stop-service-deployment --service-deployment-arn arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 --stop-type ROLLBACK
   ```

------

## 次のステップ
<a name="stop-service-deployment-next-step"></a>

サービスにどのような変更を加える必要があるかを確認し、サービスを更新します。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。

# タスクを置き換えて Amazon ECS サービスをデプロイする
<a name="deployment-type-ecs"></a>

*ローリング更新* (`ECS`) デプロイタイプを使用するサービスを作成すると、Amazon ECS サービススケジューラは現在実行中のタスクを新しいタスクに置き換えます。ローリング更新中にサービスに対して Amazon ECS が追加または削除するタスク数は、サービスデプロイ設定により制御されます。

Amazon ECS は、次のパラメータを使用してタスク数を決定します。
+ `minimumHealthyPercent` は、ローリングデプロイメント中またはコンテナインスタンスがドレインしているときに、サービスに対して実行され正常な状態であることが必要なタスク数の下限を、サービスに必要なタスク数の割合 (%) として表します。この値は切り上げられます。例えば、最小正常率が `50` で、必要なタスク数が 4 の場合、スケジューラは 2 つの新しいタスクを開始する前に既存のタスクを 2 つ停止できます。同様に、最小正常率が 75% で、必要なタスク数が 2 の場合、結果の値も 2 であるため、スケジューラはタスクを停止できません。
+ `maximumPercent` は、ローリングデプロイメント中またはコンテナインスタンスがドレインしているときに、サービスに対して実行する必要があるタスク数の上限を、サービスに必要なタスク数の割合 (%) として表します。この値は切り捨てられます。例えば、最大パーセンテージが `200` で、目的のタスク数が 4 の場合、スケジューラは既存のタスクを 4 つ停止する前に 4 つの新しいタスクを開始できます。同様に、最大比率が `125` で、必要なタスク数が 3 の場合、結果の値も 3 であるため、スケジューラはタスクを開始できません。

ローリングデプロイ中にタスクが異常な状態になると、Amazon ECS はそれらを置き換えてサービスの `minimumHealthyPercent` を維持し、可用性を保護します。異常な状態のタスクは、それらが属するのと同じサービスリビジョンを使用して置き換えられます。これにより、ソースリビジョンの異常な状態のタスクの置換は、ターゲットリビジョンのタスクの失敗とは無関係になります。`maximumPercent` 設定で許可されている場合、スケジューラは異常な状態のタスクを停止する前に代替タスクを起動します。`maximumPercent` パラメータによって、代替タスクを先に開始できないようにスケジューラが制限されている場合、スケジューラは異常なタスクを 1 つずつ停止して容量を解放してから代替タスクを開始します。

**重要**  
最小正常率または最大正常率を設定するときは、デプロイが開始されたときにスケジューラが 1 つ以上のタスクを停止または開始できることを確認する必要があります。無効なデプロイメント構成が原因でサービスのデプロイメントが停止している場合、サービスイベントメッセージが送信されます。詳細については、「[サービス (*service-name*) は、サービスデプロイメント構成のため、デプロイメント中にタスクを停止または開始できませんでした。minimumHealthyPercent または maximumPercent の値を更新してから、もう一度試してください。](service-event-messages-list.md#service-event-messages-7)」を参照してください。

ローリングデプロイには 2 つの方法があり、サービスデプロイが失敗したタイミングをすばやく特定できます。
+ [Amazon ECS デプロイサーキットブレーカーが障害を検出する方法](deployment-circuit-breaker.md)
+ [CloudWatch アラームが Amazon ECS のデプロイ障害を検出する方法](deployment-alarm-failure.md)

これらの方法は個別に使用することも、一緒に使用することもできます。両方の方法を使用する場合、失敗に対するいずれかの方法の失敗の基準が満たされ次第、デプロイは失敗に設定されます。

使用するメソッドを決定する際は、以下のガイドラインを参考にします。
+ サーキットブレーカー - タスクが開始できないときにデプロイを停止する場合は、このメソッドを使用します。
+ CloudWatch アラーム - アプリケーションメトリクスに基づきデプロイを停止する場合は、このメソッドを使用します。

どちらの方法も、以前のサービスリビジョンへのロールバックをサポートしています。

## コンテナイメージの解決
<a name="deployment-container-image-stability"></a>

デフォルトでは、Amazon ECS はタスク定義で指定されたコンテナイメージタグをコンテナイメージダイジェストに解決します。単一のタスクを実行および維持するサービスを作成すると、そのタスクはタスク内のコンテナイメージダイジェストを確立するために使用されます。複数のタスクを実行および維持するサービスを作成すると、デプロイ中にサービススケジューラによって開始された最初のタスクを使用して、タスク内のコンテナイメージダイジェストを確立します。

コンテナイメージダイジェストの確立を 3 回以上試行しても失敗した場合、デプロイはイメージダイジェストの解決なしで続行されます。デプロイサーキットブレーカーが有効になっている場合、デプロイも失敗し、ロールバックされます。

コンテナイメージダイジェストが確立されると、Amazon ECS はこのダイジェストを、他の対象タスクの開始や、その後のサービスの更新に使用します。この結果、サービス内のすべてのタスクで常に同じコンテナイメージが実行され、ソフトウェアのバージョン整合性が得られます。

この動作は、コンテナ定義の `versionConsistency` パラメータを使用して、タスク内のコンテナごとに設定できます。詳細については、「[versionConsistency](task_definition_parameters.md#ContainerDefinition-versionconsistency)」を参照してください。

**注記**  
`1.31.0` より前のバージョンの Amazon ECS エージェントは、イメージダイジェストの解決をサポートしていません。エージェントバージョン `1.31.0`～`1.69.0` では、Amazon ECR リポジトリにプッシュされたイメージに対してのみイメージダイジェストの解決がサポートされています。エージェントバージョン `1.70.0` 以降では、すべてのイメージに対してイメージダイジェストの解決がサポートされています。
イメージダイジェスト解決に対応した Fargate Linux プラットフォームの最低バージョンは `1.3.0` です。イメージダイジェスト解決に対応した Fargate Windows プラットフォームの最低バージョンは `1.0.0` です。
Amazon ECS は、Amazon GuardDuty セキュリティエージェントや Service Connect プロキシなど、Amazon ECS によって管理されるサイドカーコンテナのダイジェストをキャプチャしません。
複数のタスクがあるサービスでコンテナイメージの解決に関連する潜在的なレイテンシーを減らすには、EC2 コンテナインスタンスで Amazon ECS エージェントバージョン `1.83.0` 以降を実行してください。潜在的なレイテンシーを回避するには、タスク定義でコンテナイメージダイジェストを指定します。
タスク数が 0 のサービスを作成した場合、タスク数が 0 よりも大きいサービスの別のデプロイをトリガーするまで Amazon ECS はコンテナダイジェストを確立できません。
更新されたイメージダイジェストを確立するために、新しいデプロイを強制できます。更新されたダイジェストは新しいタスクの開始に使用され、既に実行中のタスクには影響しません。新しいデプロイの強制の詳細については、「*Amazon ECS API リファレンス*」の「[forceNewDeployment](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-forceNewDeployment)」を参照してください。
EC2 キャパシティプロバイダーを使用すると、最初のデプロイ中にタスクを開始するキャパシティーが不十分な場合、ソフトウェアバージョンの整合性が失敗する可能性があります。容量が制限されていてもバージョンの整合性を維持するには、デフォルトの動作に依存するのではなく、タスク定義のコンテナ設定で `versionConsistency: "enabled"` を明示的に設定してください。これは、デプロイに進む前に、キャパシティが利用可能になるまで Amazon ECS が待機する原因になります。

# Amazon ECS サービスパラメータのベストプラクティス
<a name="service-options"></a>

アプリケーションのダウンタイムを発生させないためのデプロイプロセスは次のとおりです。

1. 既存のコンテナを実行したまま、新しいアプリケーションコンテナを起動します。

1. 新しいコンテナが正常であることを確認します。

1. 古いコンテナを停止します。

 デプロイメント構成とクラスター内の予約されていない空きスペースの量によっては、すべての古いタスクを新しいタスクに置き換えるまでに、これを複数回行う必要がある場合があります。

数を変更するのに使用できるサービス設定オプションは 2 つあります。
+ `minimumHealthyPercent`: 100% (デフォルト)

  デプロイ中にサービスが `RUNNING` 状態を維持する必要があるタスクの数の下限を入力します。これは、最も近い整数に切り上げられた `desiredCount` のパーセンテージです。このパラメータにより、追加のクラスターキャパシティーを使用せずにデプロイできます。
+ `maximumPercent`: 200% (デフォルト)

   デプロイ中に `RUNNING` または `PENDING` 状態で許可されるサービスのタスク数の上限。これは、最も近い整数に切り捨てられた `desiredCount` のパーセンテージ (%) です。

**例: デフォルト設定オプション**

タスクが 6 つある次のサービスが、合計 8 つのタスクを処理できるクラスターにデプロイされているとします。デフォルトのサービス設定オプションでは、デプロイは 6 つの対象タスクの 100% を下回ることはありません。

デプロイの手順は次のとおりです。

1. 目標は 6 つのタスクを置き換えることです。

1. デフォルト設定では実行中のタスクが 6 つ必要なため、スケジューラは新しいタスクを 2 つ開始します。

   現在、既存のタスクが 6 つあり、新しいタスクが 2 つあります。

1. スケジューラは既存のタスクのうちの 2 つを停止します。

   現在、既存のタスクが 4 つあり、新しいタスクが 2 つあります。

1. スケジューラはさらに新しいタスクを 2 つ開始します。

   現在、既存のタスクが 4 つあり、新しいタスクが 4 つあります。

1. スケジューラは既存のタスクのうちの 2 つをシャットダウンします。

   現在、既存のタスクが 2 つあり、新しいタスクが 4 つあります。

1. スケジューラはさらに新しいタスクを 2 つ開始します。

   現在、既存のタスクが 2 つあり、新しいタスクが 6 つあります。

1. スケジューラは最後の 2 つの既存のタスクをシャットダウンします。

   現在、新しいタスクが 6 つあります。

上記の例では、オプションにデフォルト値を使用すると、新しいタスクが開始されるたびに 2.5 分待たされます。さらに、ロードバランサーは古いタスクが停止するまで 5 分間待たなければならない場合があります。

**例: `minimumHealthyPercent` の変更**

`minimumHealthyPercent` 値を 50% に設定すると、デプロイをスピードアップできます。

タスクが 6 つある次のサービスが、合計 8 つのタスクを処理できるクラスターにデプロイされているとします。デプロイの手順は次のとおりです。

1. 目標は 6 つのタスクを置き換えることです。

1. スケジューラは既存のタスクのうちの 3 つを停止します。

   `minimumHealthyPercent` 値を満たす既存のタスクがまだ 3 つ実行されています。

1. スケジューラは新しいタスクを 5 つ開始します。

   既存のタスクが 3 つあり、新しいタスクが 5 つあります。

1. スケジューラは残りの 3 つの既存のタスクを停止します。

   新しいタスクが 5 つあります。

1. スケジューラは最後の新しいタスクを開始します。

   新しいタスクが 6 つあります。

**例: クラスターの空き容量を変更する**

追加のタスクを実行できるように、空き容量を増やすこともできます。

タスクが 6 つある次のサービスが、合計 10 個のタスクを処理できるクラスターにデプロイされているとします。デプロイの手順は次のとおりです。

1. 目標は既存のタスクを置き換えることです。

1. スケジューラは既存のタスクのうちの 3 つを停止します。

   既存のタスクが 3 つあります。

1. スケジューラは新しいタスクを 6 つ開始します。

   既存のタスクと 6 つの新しいタスクがあります。

1. スケジューラは既存のタスク 3 つを停止します。

   新しいタスクが 6 つあります。

**推奨事項**

タスクがしばらくアイドル状態で、使用率が高くない場合は、サービス設定オプションで次の値を使用してください。
+ `minimumHealthyPercent`: 50%
+ `maximumPercent`: 200% 

# Amazon ECS のローリング更新デプロイの作成
<a name="create-service-console-v2"></a>

タスク定義の指定された数のインスタンスをクラスター内で同時に実行して維持するサービスを作成します。タスクの 1 つが失敗または停止した場合、Amazon ECS サービススケジューラはタスク定義の別のインスタンスを起動してそれを置き換えます。これは、サービスで必要な数のタスクを維持するのに役立ちます。

サービスを作成する前に、次の設定パラメータを決定します。
+ タスクを分散するコンピューティングオプションが 2 つあります。
  + **[capacity provider strategy]** (キャパシティープロバイダー戦略) により、Amazon ECS がタスクを 1 つまたは複数のキャパシティプロバイダーに分散させます。

    Amazon ECS マネージドインスタンスでワークロードを実行する場合は、キャパシティプロバイダーの戦略オプションを使用する必要があります。
  + **[起動タイプ]** により、Amazon ECS は Fargate またはクラスターに登録された EC2 インスタンスのいずれかでタスクを直接起動します。

    Amazon ECS マネージドインスタンスでワークロードを実行する場合は、キャパシティプロバイダーの戦略オプションを使用する必要があります。
+ `awsvpc` ネットワークモードを使用するタスク定義、またはロードバランサーを使用するように設定されたサービスには、ネットワーク設定が必要です。デフォルトでは、コンソールは、デフォルトAmazon VPC 内のすべてのサブネットおよびデフォルトセキュリティグループとともにデフォルトのAmazon VPC を選択します。
+ 配置戦略、デフォルトのタスク配置戦略は、アベイラビリティーゾーン間でタスクを均等に分散します。

  サービスの高可用性を確保するために、アベイラビリティーゾーンの再調整を使用することをお勧めします。詳細については、「[アベイラビリティーゾーン間での Amazon ECS サービスの調整](service-rebalancing.md)」を参照してください。
+ サービスデプロイに **[Launch Type]** (起動タイプ) を使用するバージョン、デフォルトではクラスター VPC のサブネットでサービスが開始されます。
+ **[capacity provider strategy]** (キャパシティープロバイダー戦略) では、コンソールはデフォルトでコンピューティングオプションを選択します。次に、コンソールがデフォルトを選択するときに使用する順序について説明します。
  + クラスターにデフォルトのキャパシティープロバイダー戦略が定義されている場合は、その戦略が選択されます。
  + クラスターにデフォルトのキャパシティープロバイダー戦略が定義されていないが、Fargate キャパシティープロバイダーをクラスターに追加している場合は、キャパシティープロバイダーを使用するカスタム `FARGATE` キャパシティープロバイダー戦略が選択されます。
  + クラスターにデフォルトのキャパシティープロバイダー戦略が定義されていないが、クラスターに 1 つ以上の Auto Scaling グループキャパシティープロバイダーが追加されている場合は、**[Use custom (アドバンスト)]** オプションが選択され、戦略を手動で定義する必要があります。
  + クラスターにデフォルトのキャパシティープロバイダー戦略が定義されておらず、クラスターにキャパシティープロバイダーが追加されていない場合は、Fargate起動タイプが選択されます。
+ デプロイの失敗が検出された場合のデフォルトのオプションでは、**[Amazon ECS デプロイサーキットブレーカー]** オプションと **[失敗時のロールバック]** オプションを使用します。

  詳細については、「[Amazon ECS デプロイサーキットブレーカーが障害を検出する方法](deployment-circuit-breaker.md)」を参照してください。
+ Amazon ECS でサービス内の必要なタスク数を自動的に増減するかどうかを決定します。詳細については、「[Amazon ECS サービスを自動的にスケールする](service-auto-scaling.md)」を参照してください。
+ Amazon ECS 内で実行される他のアプリケーションにアプリケーションを接続する必要がある場合、アーキテクチャに適したオプションを決定してください。詳細については、「[Amazon ECS サービスを相互接続する](interconnecting-services.md)」を参照してください。
+ Amazon ECS サーキットブレーカーを使用するサービスを作成すると、Amazon ECS はサービスデプロイとサービスリビジョンを作成します。これらのリソースを使用すると、サービス履歴に関する詳細情報を表示できます。詳細については、「[Amazon ECS サービスデプロイを使用してサービス履歴を表示する](service-deployment.md)」を参照してください。

  AWS CLI を使用してサービスを作成する方法については、「*AWS Command Line Interfaceリファレンス*」の「[https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)」を参照してください。

  AWS CloudFormation を使用してサービスを作成する方法については、「*AWS CloudFormation ユーザーガイド*」の「[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html)」を参照してください。

## デフォルトのオプションを使用してサービスを作成する
<a name="create-default-service"></a>

コンソールを使用すると、サービスをすばやく作成してデプロイできます。サービスには次の設定があります。
+ クラスターに関連する VPC およびサブネットにデプロイします
+ タスクを 1 つ展開します
+ ローリングデプロイを使用します
+ デフォルトのキャパシティプロバイダーでキャパシティプロバイダー戦略を使用します
+ デプロイサーキットブレーカーを使用して障害を検出し、障害時にデプロイを自動的にロールバックするオプションを設定します。

デフォルトパラメータを使用してサービスをデプロイするには、次の手順に従います。

**サービスを作成するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションページで、**[クラスター]** を選択します。

1. **[クラスター]** ページで、サービスを作成するクラスターを選択します。

1. **[Services]** (サービス) タブから、**[Create]** (作成) を選択します。

   **[サービスの作成]** ページが表示されます。

1. **[サービスの詳細]** で、次の操作を行います。

   1. **[タスク定義]** に、使用するタスク定義ファミリーとリビジョンを入力します。

   1. **[Service name]** (サービス名) でサービスの名前を入力します。

1. ECS Exec を使用してサービスをデバッグするには、**[設定のトラブルシューティング]** で **[ECS Exec をオンにする]** を選択します。

1. **[デプロイメント設定]** で、次の操作を行います。

   1. **[Desired tasks]** (必要なタスク) で、サービス内で起動および維持するタスクの数を入力します。

1. （オプション）サービスとタスクを識別しやすくするには、**[Tags]** (タグ) セクションを展開し、タグを設定します。

   Amazon ECS で、新しく起動されたすべてのタスクに、クラスター名とタスク定義のタグで自動でタグ付けするには、**[Turn on Amazon ECS managed tags]** (Amazon ECS で管理されたタグを有効にする) を選択し、**[Task definition]** (タスク定義) を選択します。

   Amazon ECS で、新しく起動されたすべてのタスクに、クラスター名とサービスタグを自動でタグ付けするには、**[Turn on Amazon ECS managed tags]** (Amazon ECS で管理されたタグを有効にする) を選択し、**[Service]** (サービス) を選択します。

   タグを追加または削除します。
   + [タグを追加] **[Add tag]** (タグを追加) を選択し、以下を実行します。
     + [**キー**] にはキー名を入力します。
     + [**値**] にキー値を入力します。
   + [タグの削除] タグの横にある [**タグの削除**] を選択します。

## 定義済みのパラメータを使用したサービスの作成
<a name="create-custom-service"></a>

定義済みのパラメータを使用してサービスを作成するには、次の手順に従います。

**サービスを作成するには (Amazon ECS コンソール)**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. サービスを起動するリソースを決定します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-service-console-v2.html)

   **[サービスの作成]** ページが表示されます。

1. [サービスの詳細] で、次の操作を行います。

   1. **[タスク定義]**に、使用するタスク定義を入力します。次に、**[リビジョン]** で、使用するリビジョンを選択します。

   1. **[Service name]** (サービス名) でサービスの名前を入力します。

1. **[既存のクラスター]** で、クラスターを選択します。

   **[クラスターの作成]** を選択して、新しいクラスターでタスクを実行します。

1. クラスターのインフラストラクチャ全体にタスクを分散する方法を選択します。**[コンピュート設定]** で、オプションを選択します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. ECS Exec を使用してサービスをデバッグするには、**[設定のトラブルシューティング]** で **[ECS Exec をオンにする]** を選択します。

1. **[デプロイメント設定]** で、次の操作を行います。

   1. **[Service type]** (サービスタイプ) で、サービススケジューリング戦略を選択します。
      + タスク配置の制約をすべて満たすアクティブなコンテナインスタンスに、スケジューラが正確に 1 つのタスクをデプロイするには、**[Daemon]** (デーモン) を選択します。
      + スケジューラがクラスターに必要数のタスクを配置して維持するためには、**[Replica]** (レプリカ) を選択します。

   1. **[Replica]** (レプリカ) を使用した場合、**[Desired tasks]** (必要なタスク) に、サービス内で起動および維持するタスクの数を入力します。

   1. **[レプリカ]** を選択した場合、Amazon ECS がアベイラビリティーゾーン間のタスクの分散をモニタリングし、不均衡が発生したときにタスクを再分散させるには、**[アベイラビリティーゾーンのサービス再調整] **で、**[アベイラビリティーゾーンのサービス再調整]** を選択します。

   1. **[ヘルスチェックの猶予期間]**に、サービススケジューラがタスクの初回起動後に異常な Elastic Load Balancing、VPC Lattice、およびコンテナヘルスチェックを無視する時間 (秒単位) を入力します。ヘルスチェックの猶予期間値を指定しない場合、デフォルト値 0 が使用されます。

   1. サービスのデプロイタイプを決定してください。**[デプロイオプション]** を展開し、次のパラメータを指定します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-service-console-v2.html)

   1. Amazon ECS がデプロイの障害を検出して処理する方法を設定するには、**[Deployment failure detection]** (デプロイ障害検出) を展開し、オプションを選択します。

      1. タスクを開始できない場合にデプロイを停止するには、**[Use the Amazon ECS deployment circuit breaker]** (Amazon ECS デプロイサーキットブレーカーを使用する) を選択します。

         デプロイサーキットブレーカーによってデプロイが失敗状態に設定されたときに、ソフトウェアがデプロイを最後に完了したデプロイ状態に自動的にロールバックするようにするには、**[失敗時のロールバック]** を選択します。

      1. アプリケーションメトリクスに基づいてデプロイを停止するには、**[CloudWatch アラームを使用する]** を選択します。次に、**[CloudWatch アラーム名]** からアラームを選択します。新しいアラームを作成するには、CloudWatch コンソールに移動します。

         CloudWatch アラームによってデプロイが失敗状態に設定されたときに、ソフトウェアがデプロイを最後に完了したデプロイ状態に自動的にロールバックするようにするには、**[失敗時のロールバック]** を選択します。

1. タスク定義で `awsvpc` ネットワークモードを使用している場合は、カスタムネットワーク設定を指定できます。これを行うには、**[ネットワーキング]** を展開して次の操作を実行します。

   1. **VPC** の場合、使用する VPC を選択します。

   1. **[Subnets]** (サブネット) で、タスクスケジューラがタスクを配置するときに考慮する VPC 内のサブネットを 1 つ以上選択します。

   1. **[Security groups]** (セキュリティグループ) で、既存のセキュリティグループを選択することも、新しいセキュリティグループを作成することもできます。既存のセキュリティグループを使用するには、セキュリティグループを選択し、次のステップに進みます。新しいセキュリティグループを作成するには、[**Create a new security group (新しいセキュリティグループの作成)**] を選択します。セキュリティグループの名前、説明を指定してから、セキュリティグループのインバウンドルールを 1 つ以上追加する必要があります。

   1. **[Public IP]** (パブリック IP) では、タスクの Elastic Network Interface (ENI) にパブリック IP アドレスを自動的に割り当てるかどうかを選択します。

      AWS Fargate タスクをパブリックサブネットで実行するときに、そのタスクにパブリック IP アドレスを割り当てて、インターネットへのルートを持つようにすることができます。このフィールドを使用して EC2 タスクにパブリック IP を割り当てることはできません。詳細については、「[Fargate の Amazon ECS タスクのネットワーキングオプション](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html)」および「[Amazon ECS タスクにネットワークインターフェイスを割り当てる](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html)」を参照してください。

1. (オプション) Service Connect を使用してサービスを相互接続するには、**[Service Connect]** を展開して以下を指定します。

   1.  **[Service Connect をオンにする]** を選択します。

   1. **[Service Connect configuration]** (Service Connect 設定) で、クライアントモードを指定します。
      + サービスが名前空間内の他のサービスへの接続のみを必要とするネットワーククライアントアプリケーションを実行している場合は、**[クライアント側のみ]** を選択します。
      + サービスがネットワークまたは Web サービスアプリケーションを実行していて、このサービスにエンドポイントを提供し、名前空間内の他のサービスに接続する必要がある場合は、**[Client and server]** (クライアントとサーバー) を選択します。

   1. デフォルトのクラスター名前空間ではない名前空間を使用するには、**[Namespace]** (名前空間) でサービス名前空間を選択します。この場合、AWS アカウントの同じ AWS リージョンで個別に作成された名前空間、またはAWS Resource Access Manager (AWS RAM) を使用してアカウントと共有されている同じリージョンの名前空間のいずれかを選択できます。共有 AWS Cloud Map 名前空間の詳細については、「*AWS Cloud Map デベロッパーガイド*」の「[クロスアカウント AWS Cloud Map 名前空間の共有](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)」を参照してください。

   1. （オプション) ログ設定を指定します。**[ログコレクションを使用]** を選択します。デフォルトのオプションでは、コンテナログを CloudWatch Logs に送信します。その他のログドライバオプションは、AWS FireLens を使用して構成されます。詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。

      以下では、各コンテナログの送信先について詳しく説明します。
      + **Amazon CloudWatch** — コンテナログを CloudWatch Logs に送信するようにタスクを設定します。デフォルトのログドライバーオプションが提供され、ユーザーに代わり CloudWatch ロググループを作成します。別のロググループ名を指定するには、ドライバーオプションの値を変更します。
      + **[Amazon Data Firehose]** — Firehose にコンテナログを送信するようタスクを設定します。Firehose 配信ストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別の配信ストリーム名を指定するには、ドライバーオプションの値を変更します。
      + **Amazon Kinesis Data Streams** — Kinesis Data Streams にコンテナログを送信するようタスクを設定します。Kinesis Data Streams のストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別のストリーム名を指定するには、ドライバーオプションの値を変更します。
      + **Amazon OpenSearch Service** — コンテナログを OpenSearch Service ドメインに送信するようタスクを設定します。ログドライバーオプションを提供する必要があります。
      + **Amazon S3** — Amazon S3 バケットにコンテナログを送信するようタスクを設定します。デフォルトのログドライバーオプションが提供されていますが、有効な Amazon S3 バケット名を指定する必要があります。

   1. (オプション) アクセスログを有効にするには、次の手順に従います。

      1. **[アクセスログ設定]** を展開します。**[形式]** で、**[JSON]** または [`TEXT`] を選択します。

      1. アクセスログにクエリパラメータが含まれるようにするには、**[クエリパラメータを含める]** を選択します。

1. (オプション) サービス検出を使用してサービスを相互接続するには、**[サービス検出]** を展開して次の操作を行います。

   1. **[サービス検出を使用]** を選択します。

   1. 新しい名前空間を使用するには、**[名前空間の設定]** で **[新しい名前空間の作成]** を選択し、名前空間の名前と説明を入力します。既存の名前空間を使用するには、**[既存の名前空間を選択]** を選択し、使用する名前空間を選択します。

   1. サービスの名前や説明などのサービス検出サービス情報を入力します。

   1. Amazon ECS にコンテナレベルのヘルスチェックを定期的に実行させるには、**[Amazon ECS タスク状態の伝達の有効化]** を選択します。

   1. [**DNS record type (DNS レコード型)**] で、サービスに作成する DNS レコード型を選択します。Amazon ECS サービス検出は、タスク定義で指定されたネットワークモードに応じて、**[A]** レコードおよび **[SRV]** レコードのみをサポートします。これらのレコードタイプの詳細については、*Amazon Route 53 デベロッパーガイド*の[サポートされているDNSレコードタイプ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html)を参照してください。
      + サービスタスクで指定されたタスク定義が `bridge` または `host` ネットワークモードを使用する場合、**SRV** タイプのレコードのみがサポートされます。レコードに関連付けるコンテナ名とポートの組み合わせを選択します。
      + サービスタスクで指定されたタスク定義が `awsvpc` ネットワークモードを使用する場合、**A** または **SRV** レコードタイプのいずれかを選択します。**[A]** を選択した場合は、次の手順をスキップします。[**SRV**] を選択する場合は、サービスを検出できるポートまたはレコードに関連付けるコンテナ名とポートの組み合わせを指定します。

      **TTL** には、レコードセットが DNS リゾルバーおよびウェブブラウザによってキャッシュされる時間を秒単位で入力します。

1. (オプション) VPC Lattice を使用してサービスを相互接続するには、**[VPC Lattice]** を展開して次の操作を行います。

   1. **[VPC Lattice をオンにする]** を選択します。

   1. **インフラストラクチャロール** については、インフラストラクチャロールを選択します。

      ロールを作成していない場合は、**[インフラストラクチャロールの作成]** を選択します。

   1. **[ターゲットグループ]** で、1 つまたは複数のターゲットグループを選択します。少なくとも 1 つのターゲットグループを選択する必要があります。最大 5 つのターゲットグループを選択できます。追加のターゲットグループを追加するには、**[ターゲットグループの追加]** を選択します。選択した各ターゲットグループの **[ポート名]**、**[プロトコル]**、および **[ポート]** を選択します。

      ターゲットグループを削除するには、**[削除]** を選択します。
**注記**  
既存のターゲットグループを追加する場合は、AWS CLI を使用する必要があります。AWS CLI を使用してターゲットグループを追加する方法については、「*AWS Command Line Interface リファレンス*」の「[register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html)」を参照してください。
VPC Lattice サービスは複数のターゲットグループを持つことができますが、各ターゲットグループは 1 つのサービスにのみ追加できます。

   1. VPC Lattice 設定を完了するには、リスナーのデフォルトアクションに新しいターゲットグループを含めるか、VPC Lattice コンソール内の既存の VPC Lattice サービスのルールに新しいターゲットグループを含めます。詳細については、「[Listener rules for your VPC Lattice service](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html)」を参照してください。

1. (オプション) サービスのロードバランサーを設定するには、**[Load Balancing]** (負荷分散) セクションを展開します。

   ロードバランサーを選択します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. (オプション) サービスの自動スケーリングを設定するには、**[サービスの自動スケーリング]** を展開し、次のパラメータを指定します。トラフィックフローからの過去のロードデータを調べる予測自動スケーリングを使用するには、サービスを作成した後にそれを設定します。詳細については、「[履歴パターンを使用して予測スケーリングで Amazon ECS サービスをスケールする](predictive-auto-scaling.md)」を参照してください。

   1. サービスの自動スケーリングを使用するには、**[Service auto scaling]** (サービスの自動スケーリング) を選択します。

   1. **[タスクの最小数]** に、サービスの自動スケーリングで使用するタスクの下限数を入力します。必要な数がこの数を下回ることはありません。

   1. **[タスクの最大数]** に、サービスの自動スケーリングで使用するタスクの上限数を入力します。必要な数がこの数を超えることはありません。

   1. ポリシータイプを選択します。**[スケーリングポリシータイプ]** で、次のいずれかのオプションを選択します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. (オプション) デフォルト以外のタスク配置戦略を使用するには、**[Task Placement]** (タスクの配置) を展開し、以下のオプションから選択します。

    詳細については、「[Amazon ECS がタスクをコンテナインスタンスに配置する方法](task-placement.md)」を参照してください。
   + **[AZ バランススプレッド]** - アベイラビリティーゾーン間およびアベイラビリティーゾーン内のコンテナインスタンス間でタスクを分散します。
   + **[AZ Balanced BinPack]** - 利用可能な最小メモリでアベイラビリティーゾーン間およびコンテナインスタンス間でタスクを分散します。
   + **[ビンパック]** - CPU またはメモリの最小利用可能量に基づいてタスクを配置します。
   + **[ホストごとに 1 つのタスク]** - 各コンテナインスタンスのサービスから最大 1 タスクを配置します。
   + **[カスタム]** - 独自のタスク配置戦略を定義します。

   **[Custom]** (カスタム) を選択した場合、タスクを配置するアルゴリズムと、タスク配置時に考慮されるルールを定義します。
   + **[Strategy]** (方針) にとって **[Type]** (タイプ) そして **[Field]** (フィールド) で、アルゴリズムとアルゴリズムに使用するエンティティを選択します。

     最大 5 個の戦略を入力できます。
   + **[制約]** の **[タイプ]** および **[式]** で、制約のルールと属性を選択します。

     例えば、T2 インスタンスにタスクを配置する制約を設定するには、**[Expression]** (表現) で、**[attribute:ecs.instance-type =\$1 t2.\$1]** と入力します。

     最大 10 個の制約を入力できます。

1. デプロイ時の設定と互換性のあるデータボリュームをタスクで使用する場合は、**[ボリューム]** を拡張してボリュームを設定できます。

   ボリューム名とボリュームタイプはタスク定義リビジョンを作成するときに設定され、サービスの作成時には変更できません。ボリューム名とタイプを更新するには、新しいタスク定義リビジョンを作成し、その新しいリビジョンを使用してサービスを作成する必要があります。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. ECS Exec を使用してサービスをデバッグするには、**[設定のトラブルシューティング]** で **[ECS Exec をオンにする]** を選択します。

1. （オプション）サービスとタスクを識別しやすくするには、**[Tags]** (タグ) セクションを展開し、タグを設定します。

   新しく起動したすべてのタスクに対して、Amazon ECS がクラスター名とタスク定義タグで自動的にタグ付けするようにするには、**[Amazon ECS マネージドタグを有効にする]** を選択し、**[タグの伝播元]** で **[タスク定義]** を選択します。

   新しく起動したすべてのタスクに対して、Amazon ECS がクラスター名とサービスタグで自動的にタグ付けするようにするには、**[Amazon ECS マネージドタグを有効にする]** を選択し、**[タグの伝播元]** で **[サービス]** を選択します。

   タグを追加または削除します。
   + [タグを追加] **[Add tag]** (タグを追加) を選択し、以下を実行します。
     + [**キー**] にはキー名を入力します。
     + [**値**] にキー値を入力します。
   + [タグの削除] タグの横にある [**タグの削除**] を選択します。

1. **[作成]** を選択します。

## 次のステップ
<a name="create-service-next-steps"></a>

以下は、サービスを作成した後の追加アクションです。
+ トラフィックフローからの過去のロードデータを調べる予測自動スケーリングを設定します。詳細については、「[履歴パターンを使用して予測スケーリングで Amazon ECS サービスをスケールする](predictive-auto-scaling.md)」を参照してください。
+ Amazon ECS サーキットブレーカーのサービスのデプロイを追跡し、サービス履歴を表示します。詳細については、「[Amazon ECS サービスデプロイを使用してサービス履歴を表示する](service-deployment.md)」を参照してください。

# Amazon ECS ブルー/グリーンデプロイ
<a name="deployment-type-blue-green"></a>

ブルー/グリーンデプロイは、ブルーおよびグリーンという 2 つの同一の本番環境を実行することで、ダウンタイムおよびリスクを軽減するリリース方法です。Amazon ECS ブルー/グリーンデプロイを使用すると、本番トラフィックをルーティングする前に、新しいサービスリビジョンを検証できます。このアプローチによって変更をデプロイするより安全な方法が実現され、必要に応じてすばやくロールバックできます。

## 利点
<a name="blue-green-deployment-benefits"></a>

ブルー/グリーンデプロイの使用には、次のメリットがあります。
+ 本番トラフィックでテストしてから本番に切り替えることで、リスクを軽減します。本番トラフィックをルーティングする前に、テストトラフィックを使用して新しいデプロイを検証できます。
+ ダウンタイムのないデプロイ。本番環境はデプロイプロセス全体で引き続き利用でき、サービスの継続的な利用可能性を実現します。
+ 問題が検出された場合、簡単にロールバックできます。グリーンデプロイで問題が発生した場合、サービス中断が継続されることなく、ブルーデプロイにすばやく戻ることができます。
+ 管理されたテスト環境。完全にデプロイする前に実際のトラフィックパターンで新機能をテストするため、グリーン環境では隔離されたスペースが提供されます。
+ 予測可能なデプロイプロセス。定義されたライフサイクルステージによる構造化されたアプローチにより、デプロイの整合性および信頼性が向上します。
+ ライフサイクルフックによる自動検証。デプロイのさまざまな段階で自動テストを実装し、機能性を検証できます。

## 用語
<a name="blue-green-deployment-terms"></a>

Amazon ECS ブルー/グリーンデプロイの条件は次のとおりです。
+ ベイク時間 – 本番トラフィックが移行した後に、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。
+ ブルーデプロイ – 置き換える予定の、現在の本番サービスリビジョン。
+ グリーンデプロイ – デプロイする新しいサービスリビジョン。
+ ライフサイクルステージ – 「本番トラフィックの移行後」など、デプロイオペレーションの一連のイベント。
+ ライフサイクルフック – 特定のライフサイクルステージでデプロイを検証する Lambda 関数。
+ リスナー – 設定したプロトコルおよびポートを使用し、接続リクエストを確認する Elastic Load Balancing リソース。リスナーに対して定義したルールにより、Amazon ECS が登録済みターゲットにリクエストをルーティングする方法が決定します。
+ ルール – リスナーに関連付けられた Elastic Load Balancing リソース。ルールはリクエストのルーティング方法を定義し、アクション、条件、優先度で構成されます。
+ ターゲットグループ – リクエストを 1 つ以上の登録済みターゲットにルーティングするために使用される Elastic Load Balancing リソース (EC2 インスタンスなど)。リスナーを作成するときは、デフォルトアクションのターゲットグループを指定します。トラフィックは、リスナー規則で指定されたターゲットグループに転送されます。
+ トラフィック移行 – Amazon ECS がブルーデプロイからグリーンデプロイにトラフィックを移行するために使用するプロセス。Amazon ECS ブルー/グリーンデプロイの場合、すべてのトラフィックが一度にブルーサービスからグリーンサービスに移行されます。

## 考慮事項
<a name="blue-green-deployment-considerations"></a>

デプロイタイプを選択する際、次の内容を考慮してください。
+ リソースの使用量: ブルー/グリーンデプロイではブルーおよびグリーンのサービスリビジョンの両方が一時的に実行されるため、デプロイ中にリソースの使用量が 2 倍になる場合があります。
+ デプロイモニタリング: ブルー/グリーンデプロイではデプロイステータスの詳細な情報が提供されるため、デプロイプロセスの各ステージをモニタリングできます。
+ ロールバック: ブルーリビジョンがベイク時間が終了するまで実行が継続されるため、問題が検出された場合、ブルー/グリーンデプロイでは前のバージョンへのロールバックが容易になります。
+ Network Load Balancer ライフサイクルフック: ブルー/グリーンデプロイに Network Load Balancer を使用する場合は、TEST\$1TRAFFIC\$1SHIFT および PRODUCTION\$1TRAFFIC\$1SHIFT ライフサイクルステージにさらに 10 分を要します。これは、Amazon ECS がトラフィックを移行しても安全であることを確認するためです。

# Amazon ECS ブルー/グリーンサービスのデプロイワークフロー
<a name="blue-green-deployment-how-it-works"></a>

Amazon ECS ブルー/グリーンデプロイプロセスは構造化されたアプローチに従っており、安全かつ信頼性の高いアプリケーション更新を実現する 6 つの異なるフェーズで構成されます。各フェーズは、アプリケーションを現在のバージョン (ブルー) から新しいバージョン (グリーン) に検証および移行するためにそれ特有の目的を果たします。

1. **準備フェーズ**: 既存のブルー環境と一緒にグリーン環境を作成します。新しいサービスリビジョンのプロビジョニングやターゲットグループの準備が含まれます。

1. **デプロイフェーズ**: 新しいサービスリビジョンをグリーン環境にデプロイします。Amazon ECS は更新されたサービスリビジョンを使用して新しいタスクを起動し、ブルー環境は引き続き本番トラフィックを処理します。

1. **テストフェーズ**: テストトラフィックルーティングを使用してグリーン環境を検証します。Application Load Balancer によってテストリクエストがグリーン環境に送信され、本番トラフィックはブルー環境の状態にとどまります。

1. **トラフィック移行のフェーズ**: 設定されたデプロイ戦略に基づき、本番トラフィックをブルーからグリーンに移行します。このフェーズには、モニタリングおよび検証チェックポイントが含まれます。

1. **モニタリングフェーズ**: ベイク期間中のアプリケーションの正常性、パフォーマンスメトリクス、アラーム状態がモニタリングされます。ロールバックオペレーションは問題が検出されると開始されます。

1. **完了フェーズ**: 設定に応じて、ブルー環境を終了するか、潜在的なロールバックシナリオに合わせて維持することで、デプロイを確定します。

## ワークフロー
<a name="blue-green-deployment-workflow"></a>

次の図は、包括的なブルー/グリーンデプロイのワークフローであり、Amazon ECS および Application Load Balancer 間の相互作用を示しています。

![\[詳細なコンポーネント相互作用、トラフィック移行フェーズ、モニタリングチェックポイントなど、Amazon ECS のブルー/グリーンデプロイプロセスを示す包括的な図\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/blue-green.png)


拡張デプロイワークフローには、次の詳細なステップが含まれます。

1. **初期状態**: ブルーサービス (現在の本番用) は本番トラフィックの 100% を処理します。Application Load Balancer には、正常なブルータスクを含むブルーターゲットグループにすべてのリクエストをルーティングするルールを含む 1 つのリスナーがあります。

1. **グリーン環境プロビジョニング**: Amazon ECS により、更新されたタスク定義を使用して新しいタスクが作成されます。これらのタスクは新しいグリーンターゲットグループに登録されますが、最初はトラフィックを受信しません。

1. **ヘルスチェックの検証**: Application Load Balancer がグリーンタスクにヘルスチェックを実行します。グリーンタスクがヘルスチェックに合格した場合にのみ、デプロイは次のフェーズに進行します。

1. **テストトラフィックのルーティング**: 設定された場合、Application Load Balancer のリスナールールは特定のトラフィックパターン (テストヘッダーを持つリクエストなど) が検証のためにグリーン環境にルーティングされ、本番トラフィックはブルー環境の状態にとどまります。これは本番トラフィックを処理するリスナーによって制御され、リクエスト属性に基づく異なるルールを使用します。

1. **本番トラフィック移行**: デプロイ設定に基づき、トラフィックはブルーからグリーンに移行します。ECS ブルー/グリーンデプロイは、トラフィックの 100% がブルー環境からグリーン環境に移動する即時 (すべてを一度に) 移行です。Application Load Balancer により、重みに基づいてブルーおよびグリーンのターゲットグループ間のトラフィック分散を制御するリスナールールを持つ 1 つのリスナーが使用されます。

1. **モニタリングと検証**: トラフィック移行中の全過程において、Amazon ECS は CloudWatch メトリクス、アラーム状態、デプロイの正常性をモニタリングします。問題が検出された場合、自動ロールバックトリガーが発動します。

1. **ベイク期間**: 本番トラフィックが移行した後、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。

1. **ブルー環境の終了**: トラフィックの移行および検証が正常に処理されたら、ブルー環境が終了してクラスターリソースが解放されるか、迅速にロールバックできるように維持されます。

1. **最終状態**: グリーン環境が新しい本番環境になり、トラフィックの 100% を処理します。デプロイは正常処理としてマークされます。

## デプロイのライフサイクルステージ
<a name="blue-green-deployment-stages"></a>

ブルー/グリーンデプロイプロセスは、個別のライフサイクルステージ (「本番トラフィックの移行後」など、デプロイオペレーションの一連のイベント) を経て進行していき、それぞれのステージに特定の役割および検証チェックポイントがあります。これらのステージを理解すると、デプロイの進行状況をモニタリングして問題を効果的にトラブルシューティングできます。

 各ライフサイクルステージは最大 24 時間継続できます。値を 24 時間未満にとどめることをお勧めします。非同期プロセスがフックをトリガーするために時間が必要になるからです。システムがタイムアウトしてデプロイに失敗し、ステージが 24 時間に達した後にロールバックが開始されます。CloudFormation デプロイには追加のタイムアウト制限があります。24 時間のステージ制限は有効性が維持されますが、CloudFormation によってデプロイ全体に 36 時間の制限が実施されます。CloudFormation によってデプロイが失敗し、36 時間以内にプロセスが完了しない場合はロールバックが開始されます。


| ライフサイクルのステージ | 説明 | ライフサイクルフックにこのステージを使用しますか? | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | このステージは、複数のサービスリビジョンが ACTIVE 状態で新しいサービスのデプロイを開始した場合にのみ発生します。 | はい | 
| PRE\$1SCALE\$1UP | グリーンサービスリビジョンは開始されていません。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されています。テストトラフィックがありません。 | はい | 
| SCALE\$1UP | グリーンサービスリビジョンが 100% までにスケールアップし、新しいタスクを起動する時間。現時点では、グリーンサービスリビジョンはトラフィックを処理していません。 | いいえ | 
| POST\$1SCALE\$1UP | グリーンサービスリビジョンが開始されました。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されています。テストトラフィックがありません。 | はい | 
| TEST\$1TRAFFIC\$1SHIFT | ブルーおよびグリーンのサービスリビジョンが実行されています。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されます。グリーンサービスリビジョンは、テストトラフィックの 0% から 100% に移行しています。 | はい | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | テストトラフィックの移行が完了しました。グリーンサービスリビジョンにより、テストトラフィックの 100% が処理されます。 | はい | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | 本番トラフィックがグリーンサービスリビジョンに移行しています。グリーンサービスリビジョンは、本番トラフィックの 0% から 100% に移行しています。 | はい | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 本番トラフィックの移行が完了しました。 | はい | 
| BAKE\$1TIME | ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。 | いいえ | 
| CLEAN\$1UP | ブルーサービスリビジョンにより、実行中のタスク 0 へと完全にスケールダウンされました。グリーンサービスリビジョンは、このステージの後に本番サービスリビジョンになります。 | いいえ | 

各ライフサイクルステージには、次のステージに進む前に合格する必要があるビルトインの検証チェックポイントが含まれています。検証が失敗した場合、サービスの可用性および信頼性を維持するため、デプロイを自動的にロールバックできます。

Lambda 関数を使用する場合、関数は作業を完了するか、15 分以内に IN\$1PROGRESS を返す必要があります。`callBackDelaySeconds` を使用して、Lambda への呼び出しを遅らせることができます。詳細については、GitHub の sample-amazon-ecs-blue-green-deployment-patterns の [app.py 関数](https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns/blob/main/ecs-bluegreen-lifecycle-hooks/src/approvalFunction/app.py#L20-L25)を参照してください。

# Amazon ECS ブルー/グリーンデプロイに必要なリソース
<a name="blue-green-deployment-implementation"></a>

マネージドトラフィック移行を持ったブルー/グリーンデプロイを使用するには、サービスは次のいずれかの機能を使用する必要があります。
+ Elastic Load Balancing
+ Service Connect

Service Discovery、Service Connect、VPC Lattice、Elastic Load Balancing を使用しないサービスでもブルー/グリーンデプロイを使用できますが、マネージドトラフィック移行のメリットがありません。

次のリストは、Amazon ECS ブルー/グリーンデプロイに設定する必要があるものに対する大まかな概要を示しています。
+ サービスは Application Load Balancer、Network Load Balancer、Service Connect を使用します。適切なリソースを設定します。
  + Application Load Balancer – 詳細については、「[ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Application Load Balancer リソース](alb-resources-for-blue-green.md)」を参照してください。
  + Network Load Balancer – 詳細については、「[Amazon ECS ブルー/グリーン、リニアおよびカナリアデプロイの Network Load Balancer リソース](nlb-resources-for-blue-green.md)」を参照してください。
  + Service Connect – 詳細については、「[Amazon ECS ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Service Connect リソース](service-connect-blue-green.md)」を参照してください。
+ サービスのデプロイコントローラーを `ECS` に設定します。
+ サービス定義でデプロイ戦略を `blue/green` として設定します。
+ 必要に応じて、次のように追加のパラメータを設定します。
  + 新しいデプロイのベイク時間
  + 自動ロールバックの CloudWatch アラーム
  + テスト用のデプロイライフサイクルフック (指定されたデプロイステージで実行される Lambda 関数)

## ベストプラクティス
<a name="blue-green-deployment-best-practices"></a>

Amazon ECS ブルー/グリーンデプロイを正常に処理するには、次のベストプラクティスに従ってください。
+ アプリケーションの正常性を正確に反映する、適切なヘルスチェックを設定します。
+ グリーンデプロイの十分なテストを可能にするベイク時間を設定します。
+ CloudWatch アラームを実装し、問題を自動的に検出してロールバックをトリガーします。
+ ライフサイクルフックを使用し、各デプロイステージで自動テストを実行します。
+ アプリケーションが同時に実行されているブルーおよびグリーンのサービスリビジョンの両方を処理できることを確認します。
+ デプロイ中に両方のサービスリビジョンを処理するため、十分なクラスターキャパシティの確保を計画します。
+ ロールバック手順は、本番環境での実装前にテストします。

# ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Application Load Balancer リソース
<a name="alb-resources-for-blue-green"></a>

Amazon ECS ブルー/グリーンデプロイに Application Load Balancer を使用するには、ブルーおよびグリーンのサービスリビジョン間のトラフィックルーティングを可能にする特定のリソースを設定する必要があります。

## ターゲットグループ
<a name="alb-target-groups"></a>

Elastic Load Balancing を使用したブルー/グリーンデプロイには、2 つのターゲットグループを作成する必要があります。
+ ブルーサービスリビジョンのプライマリターゲットグループ (現在の本番トラフィック)
+ グリーンサービスリビジョンの代替ターゲットグループ (新しいバージョン)

両方のターゲットグループは、次の設定で構成する必要があります。
+ ターゲットタイプ: `IP` (`awsvpc`ネットワークモードの Fargate または EC2 の場合)
+ プロトコル: `HTTP` (またはアプリケーションが使用するプロトコル)
+ ポート: アプリケーションがリッスンするポート (通常、HTTP は `80`)
+ VPC: Amazon ECS タスクと同じ VPC
+ ヘルスチェック設定: アプリケーションの正常性を適切にチェックするように設定されています

ブルー/グリーンデプロイ中、デプロイステージに基づき、Amazon ECS によって適切なターゲットグループにタスクが自動的に登録されます。

**Example Application Load Balancer 用ターゲットグループの作成**  
次の CLI コマンドでは、ブルー/グリーンデプロイの Application Load Balancer で使用する 2 つのターゲットグループが作成されます。  

```
aws elbv2 create-target-group \
    --name blue-target-group \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-path / \
    --health-check-protocol HTTP \
    --health-check-interval-seconds 30 \
    --health-check-timeout-seconds 5 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 2

aws elbv2 create-target-group \
    --name green-target-group \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-path / \
    --health-check-protocol HTTP \
    --health-check-interval-seconds 30 \
    --health-check-timeout-seconds 5 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 2
```

## Application Load Balancer
<a name="alb-load-balancer"></a>

次の設定で Application Load Balancer を作成する必要があります。
+ スキーム: 要件に応じて、インターネット向きまたは内部仕様
+ IP アドレスタイプ: IPv4
+ VPC: Amazon ECS タスクと同じ VPC
+ サブネット: 異なるアベイラビリティーゾーンに少なくとも 2 つのサブネット
+ セキュリティグループ: リスナーポートでトラフィックを許可するセキュリティグループ

Application Load Balancer にアタッチされたセキュリティグループには、Amazon ECS タスクにアタッチされたセキュリティグループへのトラフィックを可能にするアウトバウンドルールが必要です。

**Example Application Load Balancer の作成**  
次の CLI コマンドでは、ブルー/グリーンデプロイに使用する Application Load Balancer が作成されます。  

```
aws elbv2 create-load-balancer \
    --name my-application-load-balancer \
    --type application \
    --security-groups sg-abcd1234 \
    --subnets subnet-12345678 subnet-87654321
```

## リスナーとルール
<a name="alb-listeners"></a>

ブルー/グリーンデプロイの場合、Application Load Balancer にリスナーを設定する必要があります。
+ 本番リスナー: 本番トラフィック (通常はポート 80 または 443) が処理されます
  + トラフィックは、最初にプライマリターゲットグループに転送されます (ブルーサービスリビジョン)
  + デプロイ後、トラフィックが代替ターゲットグループに転送されます (グリーンサービスリビジョン)
+ テストリスナー (オプション): 本番トラフィックを移行する前にテストトラフィックが処理され、グリーンサービスリビジョンが検証されます
  + 別のポート (例えば、8080 や 8443) で設定できます。
  + テスト中にトラフィックが代替ターゲットグループ (グリーンサービスリビジョン) に転送されます

ブルー/グリーンデプロイ中に Amazon ECS によってリスナールールが自動的に更新され、デプロイステージに基づいてトラフィックが適切なターゲットグループにルーティングされます。

**Example 本番リスナーの作成**  
次の CLI コマンドでは、プライマリ (ブルー) ターゲットグループにトラフィックを転送する本番リスナーをポート 80 で作成します。  

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/abcdef123456
```

**Example テストリスナーの作成**  
次の CLI コマンドでは、代替 (グリーン) ターゲットグループにトラフィックを転送するテストリスナーをポート 8080 で作成します。  

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \
    --protocol HTTP \
    --port 8080 \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

**Example パスベースのルーティング用にリスナールールを作成する**  
次の CLI コマンドでは、テスト用に特定のパスのトラフィックをグリーンターゲットグループに転送するルールを作成します。  

```
aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \
    --priority 10 \
    --conditions Field=path-pattern,Values='/test/*' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

**Example ヘッダーベースのルーティング用にリスナールールを作成する**  
次の CLI コマンドでは、テスト用に特定のヘッダーを持つトラフィックをグリーンターゲットグループに転送するルールを作成します。  

```
aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \
    --priority 20 \
    --conditions Field=http-header,HttpHeaderConfig='{Name=X-Environment,Values=[test]}' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

## サービス設定
<a name="alb-service-configuration"></a>

Amazon ECS がユーザーに代わってクラスター内のロードバランサーリソースを管理するには、アクセス許可が必要です。詳細については、「[ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)」を参照してください。

Elastic Load Balancing を使用したブルー/グリーンデプロイ用に Amazon ECS サービスを作成または更新する際には、次の設定を指定する必要があります。

*user-input* を独自の値に置き換えます。

この設定の主なコンポーネントは次のとおりです。
+ `targetGroupArn`: プライマリターゲットグループの ARN (ブルーサービスリビジョン)。
+ `alternateTargetGroupArn`: 代替ターゲットグループの ARN (グリーンサービスリビジョン)。
+ `productionListenerRule`: 本番トラフィックのリスナールールの ARN。
+ `roleArn`: Amazon ECS が Elastic Load Balancing リソースを管理できるようにするためのロールの ARN。
+ `strategy`: `BLUE_GREEN` に設定してブルー/グリーンデプロイを有効にします。
+ `bakeTimeInMinutes`: 本番トラフィックが移行した後に、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。
+ `TestListenerRule`: テストトラフィックのリスナールールの ARN。このパラメータはオプションです。

```
{
    "loadBalancers": [
        {
            "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/primary-target-group/abcdef123456",
            "containerName": "container-name",
            "containerPort": 80,
            "advancedConfiguration": {
                "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/alternate-target-group/ghijkl789012",
                "productionListenerRule": "arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/load-balancer-name/abcdef123456/listener/ghijkl789012/rule/mnopqr345678",
                "roleArn": "arn:aws:iam::123456789012:role/ecs-elb-role"
            }
        }
    ],
    "deploymentConfiguration": {
        "strategy": "BLUE_GREEN",
        "maximumPercent": 200,
        "minimumHealthyPercent": 100,
        "bakeTimeInMinutes": 5
    }
}
```

## デプロイ中のトラフィックフロー
<a name="alb-traffic-flow"></a>

Elastic Load Balancing を使用したブルー/グリーンデプロイ中、トラフィックは次のようにシステムを通過します。

1. *初期状態*: すべての本番トラフィックはプライマリターゲットグループ (ブルーサービスリビジョン) にルーティングされます。

1. *グリーンサービスリビジョンのデプロイ*: Amazon ECS は新しいタスクをデプロイしたら、代替ターゲットグループに登録します。

1. *テストトラフィック*: テストリスナーが設定されている場合、テストトラフィックは代替ターゲットグループにルーティングされ、グリーンサービスリビジョンが検証されます。

1. *本番トラフィック移行*: Amazon ECS によって本番リスナールールが更新され、トラフィックが代替ターゲットグループ (グリーンサービスリビジョン) にルーティングされます。

1. *ベイク時間*: 本番トラフィックが移行された後、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。

1. *完了*: デプロイが正常に処理されると、ブルーサービスリビジョンは終了します。

デプロイ中に問題が検出された場合、Amazon ECS はトラフィックをプライマリターゲットグループ (ブルーサービスリビジョン) に戻すことで、自動的にロールバックできます。

# Amazon ECS ブルー/グリーン、リニアおよびカナリアデプロイの Network Load Balancer リソース
<a name="nlb-resources-for-blue-green"></a>

Amazon ECS ブルー/グリーンデプロイに Network Load Balancer を使用するには、ブルーおよびグリーンのサービスリビジョン間のトラフィックルーティングを有効にする特定のリソースを設定する必要があります。このセクションでは、必要なコンポーネントとその設定について説明します。

設定に Network Load Balancer が含まれている場合、Amazon ECS によって次のライフサイクルステージに 10 分の遅延が追加されます。
+ TEST\$1TRAFFIC\$1SHIFT
+ PRODUCTION\$1TRAFFIC\$1SHIFT

この遅延は、設定されたトラフィックの重みおよびデータプレーンにある実際のトラフィックルーティングの間に不一致を引き起こす可能性がある Network Load Balancer のタイミング問題を考慮しています。

## ターゲットグループ
<a name="nlb-target-groups"></a>

Network Load Balancer を使用したブルー/グリーンデプロイの場合、2 つのターゲットグループを作成する必要があります。
+ ブルーサービスリビジョンのプライマリターゲットグループ (現在の本番トラフィック)
+ グリーンサービスリビジョン (新しいサービスリビジョン) の代替ターゲットグループ

両方のターゲットグループは、次の設定で構成する必要があります。
+ ターゲットタイプ: `ip` (`awsvpc`ネットワークモードの Fargate または EC2 の場合)
+ プロトコル: `TCP` (またはアプリケーションが使用するプロトコル)
+ ポート: アプリケーションがリッスンするポート (通常、HTTP は `80`)
+ VPC: Amazon ECS タスクと同じ VPC
+ ヘルスチェック設定: アプリケーションの正常性を適切にチェックするように設定されています

  TCP ヘルスチェックの場合、Network Load Balancer はターゲットと TCP 接続を確立します。接続が正常に処理された場合、ターゲットは正常と見なされます。

  HTTP/HTTPS ヘルスチェックの場合、Network Load Balancer によって HTTP/HTTPS リクエストがターゲットに送信され、レスポンスが検証されます。

ブルー/グリーンデプロイ中、デプロイステージに基づき、Amazon ECS によって適切なターゲットグループにタスクが自動的に登録されます。

**Example Network Load Balancer 用にターゲットグループの作成**  
次の AWS CLI コマンドでは、ブルー/グリーンデプロイで Network Load Balancer に使用する 2 つのターゲットグループを作成します。  

```
aws elbv2 create-target-group \
    --name blue-target-group \
    --protocol TCP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-protocol TCP

aws elbv2 create-target-group \
    --name green-target-group \
    --protocol TCP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-protocol TCP
```

## Network Load Balancer
<a name="nlb-load-balancer"></a>

次の設定で Network Load Balancer を作成する必要があります。
+ スキーム: 要件に応じて、インターネット向きまたは内部仕様
+ IP アドレスタイプ: IPv4
+ VPC: Amazon ECS タスクと同じ VPC
+ サブネット: 異なるアベイラビリティーゾーンに少なくとも 2 つのサブネット

Application Load Balancer とは違って、Network Load Balancer はトランスポートレイヤー (レイヤー 4) で動作し、セキュリティグループは使用しません。代わりに、Amazon ECS タスクに関連付けられたセキュリティグループが、リスナーポートの Network Load Balancer からのトラフィックを許可することを確認する必要があります。

**Example Network Load Balancer を作成する**  
次の AWS CLI コマンドでは、ブルー/グリーンデプロイで使用する Network Load Balancer を作成します。  

```
aws elbv2 create-load-balancer \
    --name my-network-load-balancer \
    --type network \
    --subnets subnet-12345678 subnet-87654321
```

## ブルー/グリーンデプロイで NLB を使用する際の考慮事項
<a name="nlb-considerations"></a>

ブルー/グリーンデプロイに Network Load Balancer を使用する場合、次の内容を考慮してください。
+ **レイヤー 4 オペレーション**: Network Load Balancer はトランスポートレイヤー (レイヤー 4) で動作し、アプリケーションレイヤー (レイヤー 7) のコンテンツは検査しません。つまり、ルーティングの決定に HTTP ヘッダーまたはパスを使用することはできません。
+ **ヘルスチェック**: Network Load Balancer のヘルスチェックは、TCP、HTTP、HTTPS プロトコルに制限されています。TCP ヘルスチェックの場合、Network Load Balancer は接続を確立できるかどうかのみが検証されます。
+ **接続の保存**: Network Load Balancer はクライアントのソース IP アドレスを保存します。これはセキュリティおよびログ記録目的で役立ちます。
+ **静的 IP アドレス**: Network Load Balancer は、各サブネットに静的 IP アドレスを提供します。ホワイトリストの登録や、クライアントが固定 IP アドレスに接続する必要がある場合に役立ちます。
+ **テストトラフィック**: Network Load Balancer はコンテンツベースのルーティングをサポートしていないため、テストトラフィックは本番トラフィックとは異なるポートに送信する必要があります。

## リスナーとルール
<a name="nlb-listeners"></a>

Network Load Balancer を使用したブルー/グリーンデプロイの場合、リスナーを設定する必要があります。
+ 本番リスナー: 本番トラフィック (通常はポート 80 または 443) が処理されます
  + トラフィックは、最初にプライマリターゲットグループに転送されます (ブルーサービスリビジョン)
  + デプロイ後、トラフィックが代替ターゲットグループに転送されます (グリーンサービスリビジョン)
+ テストリスナー (オプション): 本番トラフィックを移行する前にテストトラフィックが処理され、グリーンサービスリビジョンが検証されます
  + 別のポート (8080 や 8443 など) で設定できます
  + テスト中にトラフィックが代替ターゲットグループ (グリーンサービスリビジョン) に転送されます

Application Load Balancer とは違って、Network Load Balancer はコンテンツベースのルーティングルールをサポートしていません。代わりに、トラフィックはリスナーポートおよびプロトコルに基づいてルーティングされます。

次の AWS CLI コマンドでは、Network Load Balancer の本番リスナーおよびテストリスナーを作成します。

*user-input* を独自の値に置き換えます。

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \
    --protocol TCP \
    --port 80 \
    --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456

aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \
    --protocol TCP \
    --port 8080 \
    --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456
```

## サービス設定
<a name="nlb-service-configuration"></a>

Amazon ECS がユーザーに代わってクラスター内のロードバランサーリソースを管理するには、アクセス許可が必要です。詳細については、「[ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)」を参照してください。

Network Load Balancer を使用したブルー/グリーンデプロイ用の Amazon ECS サービスを作成または更新する場合、次の設定を指定する必要があります。

*user-input* を独自の値に置き換えます。

この設定の主なコンポーネントは次のとおりです。
+ `targetGroupArn`: プライマリターゲットグループの ARN (ブルーサービスリビジョン)
+ `alternateTargetGroupArn`: 代替ターゲットグループの ARN (グリーンサービスリビジョン)
+ `productionListenerRule`: 本番トラフィック用リスナーの ARN
+ `testListenerRule`: (オプション) テストトラフィック用リスナーの ARN
+ `roleArn`: Amazon ECS に Network Load Balancer リソースの管理を可能にするロールの ARN
+ `strategy`: `BLUE_GREEN` に設定してブルー/グリーンデプロイを有効にします
+ `bakeTimeInMinutes`: 本番トラフィックが移行した後に、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間

```
{
    "loadBalancers": [
        {
            "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456",
            "containerName": "container-name",
            "containerPort": 80,
            "advancedConfiguration": {
                "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456",
                "productionListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/1234567890123456",
                "testListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/2345678901234567",
                "roleArn": "arn:aws:iam::123456789012:role/ecs-nlb-role"
            }
        }
    ],
    "deploymentConfiguration": {
        "strategy": "BLUE_GREEN",
        "maximumPercent": 200,
        "minimumHealthyPercent": 100,
        "bakeTimeInMinutes": 5
    }
}
```

## デプロイ中のトラフィックフロー
<a name="nlb-traffic-flow"></a>

Network Load Balancer を使用したブルー/グリーンデプロイ中、トラフィックは次のようにシステムを通過します。

1. *初期状態*: すべての本番トラフィックはプライマリターゲットグループ (ブルーサービスリビジョン) にルーティングされます。

1. *グリーンサービスリビジョンのデプロイ*: Amazon ECS は新しいタスクをデプロイしたら、代替ターゲットグループに登録します。

1. *テストトラフィック*: テストリスナーが設定されている場合、テストトラフィックは代替ターゲットグループにルーティングされ、グリーンサービスリビジョンが検証されます。

1. *本番トラフィック移行*: Amazon ECS によって本番リスナーが更新され、トラフィックは代替ターゲットグループ (グリーンサービスリビジョン) にルーティングされます。

1. *ベイク時間*: 本番トラフィックが移行された後、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。

1. *完了*: デプロイが正常に処理されると、ブルーサービスリビジョンは終了します。

デプロイ中に問題が検出された場合、Amazon ECS はトラフィックをプライマリターゲットグループ (ブルーサービスリビジョン) に戻すことで、自動的にロールバックできます。

# Amazon ECS ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Service Connect リソース
<a name="service-connect-blue-green"></a>

ブルー/グリーンデプロイで Service Connect を使用すると、ブルーおよびグリーンのサービスリビジョン間に適切なトラフィックルーティングを有効にするため、特定のコンポーネントを設定する必要があります。このセクションでは、必要なコンポーネントとその設定について説明します。

## アーキテクチャの概要
<a name="service-connect-blue-green-architecture"></a>

Service Connect により、Amazon ECS タスクに自動的に挿入されたマネージドサイドカープロキシを介して、サービス検出およびサービスメッシュ機能の両方が構築されます。これらのプロキシはルーティングの決定、再試行、メトリクス収集を処理し、AWS Cloud Map はサービスレジストリのバックエンドを提供します。Service Connect を有効にしてサービスをデプロイするとサービス自体が AWS Cloud Map で登録され、クライアントサービスは名前空間を介してサービスを検出します。

標準の Service Connect 実装では、クライアントサービスは論理サービス名に接続し、サイドカープロキシは実際のサービスインスタンスへのルーティングを処理します。ブルー/グリーンデプロイを使用すると、このモデルが拡張されて `testTrafficRules` 設定を介したテストトラフィックのルーティングが含まれます。

ブルー/グリーンデプロイ中は、次の主要コンポーネントが連携します。
+ **Service Connect Proxy**: サービス間のすべてのトラフィックは Service Connect プロキシを通過し、設定に基づいてルーティングを決定します。
+ **AWS Cloud Map 登録**: ブルーデプロイおよびグリーンデプロイの両方が AWS Cloud Map に登録されますが、グリーンデプロイは最初は「テスト」エンドポイントとして登録されます。
+ **テストトラフィックのルーティング**: Service Connect 設定の `testTrafficRules` は、テストトラフィックを識別してグリーンデプロイにルーティングする方法を決定します。リクエストの特定の HTTP ヘッダーがトラフィックをテストリビジョンに転送する**ヘッダーベースのルーティング**によって実現されます。デフォルトでは、カスタムルールが指定されていない場合、Service Connect は HTTP ベースプロトコルの `x-amzn-ecs-blue-green-test` ヘッダーを認識します。
+ **クライアント設定**: 名前空間内のすべてのクライアントは、本番ルートおよびテストルートの両方を自動的に受けますが、テストルールに一致するリクエストのみがグリーンデプロイに移行されます。

このアプローチが強力なのは、移行中のサービス検出の複雑さを処理するからです。トラフィックがブルーデプロイからグリーンデプロイに移行すると、すべての接続および検出メカニズムが自動的に更新されます。サービスメッシュがすべてを処理するため、DNS レコードを更新したり、ロードバランサーを再設定したり、個別にサービス検出の変更をデプロイしたりする必要はありません。

## トラフィックのルーティングとテスト
<a name="service-connect-blue-green-traffic-routing"></a>

Service Connect はブルー/グリーンデプロイ用の高度なトラフィックルーティング機能を提供します (テストシナリオ用のヘッダーベースのルーティングやクライアントエイリアス設定など)。

### テストトラフィックヘッダーのルール
<a name="service-connect-test-traffic-header-rules"></a>

ブルー/グリーンデプロイ中に、テスト目的のために特定のリクエストをグリーン (新規) サービスリビジョンにルーティングするため、テストトラフィックヘッダーのルールを設定できます。デプロイを完了する前に、トラフィックが制御された新しいバージョンを検証できます。

Service Connect は**ヘッダーベースのルーティング**を使用し、テストトラフィックを識別します。デフォルトでは、カスタムルールが指定されていない場合、Service Connect は HTTP ベースプロトコルの `x-amzn-ecs-blue-green-test` ヘッダーを認識します。このヘッダーがリクエストに存在すると、Service Connect プロキシによってテストのためにリクエストがグリーンデプロイへと自動的にルーティングされます。

テストトラフィックヘッダーのルールを使用すると、以下を実行できます。
+ 特定のヘッダーを持つリクエストをグリーンサービスリビジョンにルーティングする
+ トラフィックのサブセットで新機能をテストする
+ フルトラフィックのカットオーバー前に、サービス動作を検証する
+ Canary テスト戦略を実装する
+ 本番のような環境で統合テストを実行する

ヘッダーベースのルーティングメカニズムは、既存のアプリケーションアーキテクチャとシームレスに連携します。クライアントサービスがブルー/グリーンデプロイプロセスを認識する必要はありません。テストリクエストを送信するときに適切なヘッダーを含めるだけで、Service Connect プロキシはルーティングロジックを自動的に処理します。

テストトラフィックヘッダーのルール設定の詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[ServiceConnectTestTrafficHeaderRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderRules.html)」を参照してください。

### ヘッダーマッチングルール
<a name="service-connect-header-match-rules"></a>

ヘッダーマッチングルールは、ブルー/グリーンデプロイ中にテストトラフィックをルーティングする際の基準を定義します。グリーンサービスリビジョンにルーティングされるリクエストを正確に制御するために、複数の一致条件を設定できます。

ヘッダーマッチングは以下の内容をサポートします。
+ ヘッダー値の完全一致
+ ヘッダープレゼンスチェック
+ パターンベースのマッチング
+ 複数ヘッダーの組み合わせ

ユースケース例では、特定のユーザーエージェント文字列、API バージョン、機能フラグのあるリクエストをテストするためにグリーンサービスにルーティングします。

ヘッダーマッチング設定の詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[ServiceConnectTestTrafficHeaderMatchRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderMatchRules.html)」を参照してください。

### ブルー/グリーンデプロイのクライアントエイリアス
<a name="service-connect-client-alias-blue-green"></a>

クライアントエイリアスは、ブルー/グリーンデプロイ中にサービスに安定した DNS エンドポイントを提供します。クライアントアプリケーションが接続エンドポイントを変更する必要がなく、ブルーおよびグリーンのサービスリビジョン間にシームレスなトラフィックルーティングを実現します。

ブルー/グリーンデプロイ中、クライアントエイリアスは以下を実行します。
+ クライアント接続に一貫した DNS 名を維持する
+ サービスリビジョン間で自動トラフィック切り替えを有効にする
+ 段階的なトラフィック移行戦略をサポートする
+ トラフィックをブルーリビジョンにリダイレクトし、ロールバック機能を提供する

異なるポートまたはプロトコルに複数のクライアントエイリアスを設定でき、複雑なサービスアーキテクチャがデプロイ中に接続を維持できるようにします。

クライアントエイリアスグ設定の詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[ServiceConnectClientAlias](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectClientAlias.html)」を参照してください。

### トラフィックルーティングのベストプラクティス
<a name="service-connect-blue-green-best-practices"></a>

Service Connect を使用したブルー/グリーンデプロイ用にトラフィックルーティングを実装する際は、次のベストプラクティスを考慮してください。
+ **ヘッダーベースのテストから開始**: テストトラフィックヘッダーのルールを使用して、すべてのトラフィックを切り替える前に、制御されたトラフィックでグリーンサービスを検証します。
+ **ヘルスチェックの設定**: 異常なインスタンスにトラフィックをルーティングしないように、ブルーサービスおよびグリーンサービスの両方に適切なヘルスチェックが設定されていることを確認します。
+ **サービスメトリクスのモニタリング**: デプロイ中に両方のサービスリビジョンの主要なパフォーマンス指標を追跡し、問題を早期に特定します。
+ **ロールバック戦略の計画**: クライアントエイリアスおよびルーティングルールを設定すると、問題が検出されたときにブルーサービスへと迅速にロールバックできます。
+ **ヘッダー一致ロジックのテスト**: 本番以外の環境でヘッダー一致ルールを検証してから、本番デプロイに適用します。

## Service Connect ブルー/グリーンデプロイのワークフロー
<a name="service-connect-blue-green-workflow"></a>

Service Connect がブルー/グリーンデプロイプロセスを管理するしくみを理解すると、デプロイを効果的に実装してトラブルシューティングできます。次のワークフローは、デプロイの各フェーズ中にでさまざまなコンポーネントが相互作用する様子を示しています。

### デプロイフェーズ
<a name="service-connect-deployment-phases"></a>

Service Connect のブルー/グリーンデプロイはいくつかの異なるフェーズを通ります。

1. **初期状態**: ブルーサービスが本番トラフィックの 100% を処理します。名前空間内のすべてのクライアントサービスは、Service Connect で設定された論理サービス名を介してブルーサービスに接続されます。

1. **グリーンサービス登録**: グリーンデプロイが開始されると、「テスト」エンドポイントとして AWS Cloud Map に登録されます。クライアントサービスの Service Connect プロキシは、本番およびテスト用のルート設定の両方を自動的に提供します。

1. **テストトラフィックのルーティング**: テストトラフィックヘッダー (`x-amzn-ecs-blue-green-test` など) を含むリクエストは、Service Connect プロキシによってグリーンサービスに自動的にルーティングされます。本番トラフィックは引き続きブルーサービスに流れます。

1. **トラフィック移行の準備**: テストが正常に処理されると、デプロイプロセスは本番トラフィック移行に備えます。ブルーサービスおよびグリーンサービスの両方ともで、登録状態および正常性が維持されます。

1. **本番トラフィック移行**: Service Connect 設定は、本番トラフィックをグリーンサービスにルーティングするために更新されます。クライアントサービスの更新や DNS の変更を必要とせず、自動的に行われます。

1. **ベイク期間**: 本番トラフィックが移行した後、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。

1. **ブルーサービスの登録解除**: トラフィック移行および検証が正常に処理されたら、ブルーサービスは AWS Cloud Map から登録解除されて終了し、デプロイを完了します。

### Service Connect プロキシの動作
<a name="service-connect-proxy-behavior"></a>

Service Connect プロキシは、ブルー/グリーンデプロイ中のトラフィックを管理するうえで重要な役割を果たします。動作を理解することで、効果的なテストおよびデプロイ戦略を設計できます。

ブルー/グリーンデプロイ中の主要なプロキシ動作
+ **自動ルート検出**: アプリケーションの再起動や設定の変更を必要とせず、プロキシは AWS Cloud Map から本番およびテストのルートの両方を自動的に検出します。
+ **ヘッダーベースのルーティング**: プロキシは受信リクエストヘッダーを検査し、設定されたテストトラフィックのルールに基づいてトラフィックを適切なサービスリビジョンにルーティングします。
+ **ヘルスチェックの統合**: プロキシはトラフィックを正常なサービスインスタンスにのみルーティングし、ルーティングプールから異常なタスクを自動的に除外します。
+ **再試行とサーキットブレーク**: プロキシはビルトインの再試行ロジックおよびサーキットブレーク機能を提供し、デプロイ中の耐障害性を向上させます。
+ **メトリクス収集**: プロキシはブルーサービスおよびグリーンサービスの両方向けに詳細なメトリクスを収集し、デプロイ中の包括的なモニタリングを可能にします。

### サービス検出の更新
<a name="service-connect-service-discovery-updates"></a>

ブルー/グリーンデプロイに Service Connect を使用する主な利点の 1 つは、サービス検出の更新を自動的に処理することです。従来のブルー/グリーンデプロイには、多くの場合は複雑な DNS 更新またはロードバランサーの再設定が必要ですが、Service Connect によってこれらの変更が明確に管理されます。

デプロイ中、Service Connect は以下のものを処理します。
+ **名前空間の更新**: Service Connect 名前空間には、適切なルーティングルールが適用されて、ブルーおよびグリーンのサービスエンドポイントの両方が自動的に含まれます。
+ **クライアント設定**: 名前空間内のすべてのクライアントサービスは再起動や再デプロイを必要とせず、更新されたルーティング情報を自動的に受けとります。
+ **段階的な移行**: サービス検出の更新は段階的かつ安全に行われ、進行中のリクエストが中断されることはありません。
+ **ロールバックサポート**: ロールバックが必要な場合、Service Connect はサービス検出の設定を迅速に戻して、トラフィックをブルーサービスに戻すことができます。

# Amazon ECS ブルー/グリーンデプロイの作成
<a name="deploy-blue-green-service"></a>

 Amazon ECS ブルー/グリーンデプロイを使用すると、本番環境に実装する前にサービスを変更してテストできます。

## 前提条件
<a name="deploy-blue-green-service-prerequisites"></a>

ブルー/グリーンデプロイを開始する前に、次の操作を実行します。

1. 適切なアクセス許可を設定します。
   + Elastic Load Balancing のアクセス許可の詳細については、「[ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)」を参照してください。
   + Lambda のアクセス許可の詳細については、「[Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可](blue-green-permissions.md)」を参照してください。

1. Amazon ECS ブルー/グリーンデプロイでは、サービスで次のいずれかの機能を使用する必要があります。適切なリソースを設定してください。
   + Application Load Balancer – 詳細については、「[ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Application Load Balancer リソース](alb-resources-for-blue-green.md)」を参照してください。
   + Network Load Balancer – 詳細については、「[Amazon ECS ブルー/グリーン、リニアおよびカナリアデプロイの Network Load Balancer リソース](nlb-resources-for-blue-green.md)」を参照してください。
   + Service Connect – 詳細については、「[Amazon ECS ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Service Connect リソース](service-connect-blue-green.md)」を参照してください。

1. ライフサイクルステージに Lambda 関数を実行するかどうかを決定します。
   + PRE\$1SCALE\$1UP
   + POST\$1SCALE\$1UP
   + TEST\$1TRAFFIC\$1SHIFT
   + POST\$1TEST\$1TRAFFIC\$1SHIFT
   + PRODUCTION\$1TRAFFIC\$1SHIFT
   + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT

   詳細については、「*AWS Lambda デベロッパーガイド*」の「[コンソールで Lambda 関数の作成](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function)」を参照してください。

## 手順
<a name="deploy-blue-green-service-procedure"></a>

コンソールまたは AWS CLI を使用して、Amazon ECS ブルー/グリーンサービスを作成できます。

------
#### [ Console ]

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. サービスを起動するリソースを決定します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

   **[サービスの作成]** ページが表示されます。

1. **[サービスの詳細]** で、次の操作を行います。

   1. **[タスク定義ファミリー]** では、使用するタスク定義を選択します。次に **[タスク定義リビジョン]** には、使用するリビジョンを入力します。

   1. **[Service name]** (サービス名) でサービスの名前を入力します。

1. 既存のクラスターでサービスを実行するには、**[既存のクラスター]** にクラスターを選択します。新しいクラスターでサービスを実行するには、**[クラスターの作成]** を選択します。

1. クラスターのインフラストラクチャ全体にタスクを分散する方法を選択します。**[コンピュート設定]** で、オプションを選択します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

1. **[デプロイメント設定]** で、次の操作を行います。

   1. **[サービスタイプ]** では、**[レプリカ]** を選択します。

   1. **[Desired tasks]** (必要なタスク) で、サービス内で起動および維持するタスクの数を入力します。

   1. Amazon ECS がアベイラビリティーゾーン間のタスクの分散をモニタリングし、不均衡が発生したときにタスクを再分散するには、**[アベイラビリティーゾーンのサービス再調整]** で **[アベイラビリティーゾーンのサービス再調整]** を選択します。

   1. **[ヘルスチェックの猶予期間]** には、タスクの初回起動後にサービススケジューラが異常な Elastic Load Balancing、VPC Lattice、コンテナヘルスチェックを無視する時間 (秒単位) を入力します。ヘルスチェックの猶予期間値を指定しない場合、デフォルト値 0 が使用されます。

1. 

   1. **ベイク時間**には、ブルーリビジョンが終了する前に、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される分数を入力します。これにより、検証およびテストの時間を確保できます。

   1. (オプション) Lambda 関数を実行し、デプロイの特定段階で実行します。**[デプロイライフサイクルフック]** で、ライフサイクルフックを実行するステージを選択します。

      ライフサイクルフックを追加する方法

      1. **[Add]** (追加) を選択します。

      1. **[Lambda 関数]** には、ARN の関数名を入力します。

      1. **[ロール]** では、Lambda 関数を呼び出すアクセス許可を持つ IAM ロールを選択します。

      1. **[ライフサイクルステージ]** では、Lambda 関数を実行するステージを選択します。

1. Amazon ECS がデプロイの障害を検出して処理する方法を設定するには、**[Deployment failure detection]** (デプロイ障害検出) を展開し、オプションを選択します。

   1. タスクを開始できない場合にデプロイを停止するには、**[Use the Amazon ECS deployment circuit breaker]** (Amazon ECS デプロイサーキットブレーカーを使用する) を選択します。

      デプロイサーキットブレーカーによってデプロイが失敗状態に設定されたときに、ソフトウェアがデプロイを最後に完了したデプロイ状態に自動的にロールバックするようにするには、**[失敗時のロールバック]** を選択します。

   1. アプリケーションメトリクスに基づいてデプロイを停止するには、**[CloudWatch アラームを使用する]** を選択します。次に、**[CloudWatch アラーム名]** からアラームを選択します。新しいアラームを作成するには、CloudWatch コンソールに移動します。

      CloudWatch アラームによってデプロイが失敗状態に設定されたときに、ソフトウェアがデプロイを最後に完了したデプロイ状態に自動的にロールバックするようにするには、**[失敗時のロールバック]** を選択します。

1. (オプション) Service Connect を使用してサービスを相互接続するには、**[Service Connect]** を展開して以下を指定します。

   1.  **[Service Connect をオンにする]** を選択します。

   1. **[Service Connect configuration]** (Service Connect 設定) で、クライアントモードを指定します。
      + サービスが名前空間内の他のサービスへの接続のみを必要とするネットワーククライアントアプリケーションを実行している場合は、**[クライアント側のみ]** を選択します。
      + サービスがネットワークまたは Web サービスアプリケーションを実行していて、このサービスにエンドポイントを提供し、名前空間内の他のサービスに接続する必要がある場合は、**[Client and server]** (クライアントとサーバー) を選択します。

   1. デフォルトのクラスター名前空間ではない名前空間を使用するには、**[Namespace]** (名前空間) でサービス名前空間を選択します。この場合、AWS アカウントの同じ AWS リージョンで個別に作成された名前空間、またはAWS Resource Access Manager (AWS RAM) を使用してアカウントと共有されている同じリージョンの名前空間のいずれかを選択できます。共有 AWS Cloud Map 名前空間の詳細については、「*AWS Cloud Map デベロッパーガイド*」の「[クロスアカウント AWS Cloud Map 名前空間の共有](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)」を参照してください。

   1. (オプション) ブルー/グリーンデプロイのテストトラフィックヘッダーのルールを設定します。**[テストトラフィックのルーティング]** では、以下を指定します。

      1. **[テストトラフィックヘッダーのルールの有効化]** を選択し、テスト中に特定のリクエストをグリーンサービスリビジョンにルーティングします。

      1. **[ヘッダー一致ルール]** では、テストトラフィックをルーティングする条件を設定します。
         + **[ヘッダー名]**: 一致する HTTP ヘッダーの名前を入力します (例えば、`X-Test-Version` または `User-Agent`)。
         + **[一致タイプ]**: 一致する条件を選択します。
           + **[完全一致]**: ヘッダー値が指定された値と完全に一致するリクエストをルーティングする
           + **[ヘッダーが存在する]**: 値に関係なく、指定されたヘッダーを含むリクエストをルーティングする
           + **[パターン一致]**: ヘッダー値が指定されたパターンと一致するリクエストをルーティングする
         + **[ヘッダー値]** (完全一致またはパターン一致を使用する場合): 照合する値またはパターンを入力します。

         複数のヘッダー一致ルールを追加し、複雑なルーティングロジックを作成できます。設定されたルールに一致するリクエストは、テストのためにグリーンサービスリビジョンにルーティングされます。

      1. **[ヘッダールールの追加]** を選択し、追加のヘッダー一致条件を設定します。
**注記**  
テストトラフィックヘッダーのルールにより、完全なデプロイを完了する前に、制御されたトラフィックで新機能を検証できます。これにより、ブルーサービスリビジョンへの通常のトラフィックフローを維持しながら、特定のリクエスト (内部テストツールやベータユーザーなどによるもの) でグリーンサービスリビジョンをテストできます。

   1. （オプション) ログ設定を指定します。**[ログコレクションを使用]** を選択します。デフォルトのオプションでは、コンテナログを CloudWatch Logs に送信します。その他のログドライバオプションは、AWS FireLens を使用して構成されます。詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。

      以下では、各コンテナログの送信先について詳しく説明します。
      + **Amazon CloudWatch** — コンテナログを CloudWatch Logs に送信するようにタスクを設定します。デフォルトのログドライバーオプションが提供され、ユーザーに代わり CloudWatch ロググループを作成します。別のロググループ名を指定するには、ドライバーオプションの値を変更します。
      + **[Amazon Data Firehose]** — Firehose にコンテナログを送信するようタスクを設定します。Firehose 配信ストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別の配信ストリーム名を指定するには、ドライバーオプションの値を変更します。
      + **Amazon Kinesis Data Streams** — Kinesis Data Streams にコンテナログを送信するようタスクを設定します。Kinesis Data Streams のストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別のストリーム名を指定するには、ドライバーオプションの値を変更します。
      + **Amazon OpenSearch Service** — コンテナログを OpenSearch Service ドメインに送信するようタスクを設定します。ログドライバーオプションを提供する必要があります。
      + **Amazon S3** — Amazon S3 バケットにコンテナログを送信するようタスクを設定します。デフォルトのログドライバーオプションが提供されていますが、有効な Amazon S3 バケット名を指定する必要があります。

1. (オプション) ブルー/グリーンデプロイ用に **[ロードバランシング]** を設定します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

1. （オプション）サービスとタスクを識別しやすくするには、**[Tags]** (タグ) セクションを展開し、タグを設定します。

   新しく起動したすべてのタスクに対して、Amazon ECS がクラスター名とタスク定義タグで自動的にタグ付けするようにするには、**[Amazon ECS マネージドタグを有効にする]** を選択し、**[タグの伝播元]** で **[タスク定義]** を選択します。

   新しく起動したすべてのタスクに対して、Amazon ECS がクラスター名とサービスタグで自動的にタグ付けするようにするには、**[Amazon ECS マネージドタグを有効にする]** を選択し、**[タグの伝播元]** で **[サービス]** を選択します。

   タグを追加または削除します。
   + [タグを追加] **[Add tag]** (タグを追加) を選択し、以下を実行します。
     + [**キー**] にはキー名を入力します。
     + [**値**] にキー値を入力します。
   + [タグの削除] タグの横にある [**タグの削除**] を選択します。

1. **[作成]** を選択します。

------
#### [ AWS CLI ]

1. `service-definition.json` という名前のファイルを作成し、次の内容を記述します。

   *user-input* を独自の値に置き換えます。

   ```
   {
     "serviceName": "myBlueGreenService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "BLUE_GREEN",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "bakeTimeInMinutes": 2,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       },
       "lifecycleHooks": [
         {
           "hookTargetArn": "arn:aws:lambda:us-west-2:7123456789012:function:checkExample",
           "roleArn": "arn:aws:iam::123456789012:role/ECSLifecycleHookInvoke",
           "lifecycleStages": [
             "PRE_SCALE_UP"
           ]
         }
       ]
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-blue-green-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. `create-service` を実行します。

   *user-input* を独自の値に置き換えます。

   ```
   aws ecs create-service --cli-input-json file://service-definition.json
   ```

   または、次の例を使用して、ロードバランサー設定を持つ ブルー/グリーンデプロイサービスを作成することもできます。

   ```
   aws ecs create-service \
      --cluster "arn:aws:ecs:us-west-2:123456789012:cluster/MyCluster" \
      --service-name "blue-green-example-service" \
      --task-definition "nginxServer:1" \
      --launch-type "FARGATE" \
      --network-configuration "awsvpcConfiguration={subnets=[subnet-12345,subnet-67890,subnet-abcdef,subnet-fedcba],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \
      --desired-count 3 \
      --deployment-controller "type=ECS" \
      --deployment-configuration "strategy=BLUE_GREEN,maximumPercent=200,minimumHealthyPercent=100,bakeTimeInMinutes=0" \
      --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg1/abcdef1234567890,containerName=nginx,containerPort=80,advancedConfiguration={alternateTargetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg2/0987654321fedcba,productionListenerRule=arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/MyLB/1234567890abcdef/1234567890abcdef,roleArn=arn:aws:iam::123456789012:role/ELBManagementRole}"
   ```

------

## 次のステップ
<a name="deploy-blue-green-service-next-steps"></a>
+ サービスを更新してデプロイを開始します。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。
+ デプロイプロセスをモニタリングし、ブルー/グリーンのパターンに従っていることを確認します。
  + グリーンサービスリビジョンが作成され、スケールアップされる
  + テストトラフィックがグリーンリビジョンにルーティングされている (設定されている場合)
  + 本番トラフィックがグリーンリビジョンに移行されている
  + ベイク時間が過ぎたら、ブルーリビジョンが終了する

# Amazon ECS ブルー/グリーンデプロイのトラブルシューティング
<a name="troubleshooting-blue-green"></a>

以下は、Amazon ECS でブルー/グリーンデプロイを使用する際に発生する可能性がある一般的な問題の解決策です。ブルー/グリーンデプロイエラーは、次のフェーズで発生する可能性があります。
+ *同期パス*: `CreateService` または `UpdateService` API コールに応答してすぐに表示されるエラー。
+ *非同期パス*: `DescribeServiceDeployments` の `statusReason` フィールドに表示され、デプロイのロールバックを引き起こすエラー

**ヒント**  
[Amazon ECS MCP サーバー](ecs-mcp-introduction.md) と AI アシスタントを使用して、デプロイのモニタリングとデプロイ問題のトラブルシューティングを自然言語で実行できます。

## ロードバランサー設定の問題
<a name="troubleshooting-blue-green-load-balancer"></a>

ロードバランサーの設定は、Amazon ECS でのブルー/グリーンデプロイの重要なコンポーネントです。リスナールール、ターゲットグループ、ロードバランサータイプの適切な設定は、デプロイを成功させるために不可欠です。このセクションでは、ブルー/グリーンデプロイが失敗する原因となる一般的なロードバランサー設定の問題について説明します。

ロードバランサーの問題をトラブルシューティングするときは、リスナールールとターゲットグループの関係を理解することが重要です。ブルー/グリーンデプロイでは:
+ 本番リスナールールは、現在アクティブな (ブルー) サービスリビジョンにトラフィックをルーティングします
+ テストリスナールールを使用して、本番トラフィックに移行する前に新しい (グリーン) サービスリビジョンを検証できます
+ ターゲットグループを使用して、各サービスリビジョンからのコンテナインスタンスが登録されます
+ デプロイ中、リスナールールでターゲットグループの重みを調整することで、トラフィックはブルーサービスリビジョンからグリーンサービスリビジョンに徐々に移行されます

### リスナールール設定エラー
<a name="troubleshooting-blue-green-listener-rules"></a>

以下の問題は、ブルー/グリーンデプロイのリスナールールの誤った設定に関連しています。

リスナールール ARN の代わりに Application Load Balancer リスナー ARN を使用する  
*エラーメッセージ*: `productionListenerRule has an invalid ARN format. Must be RuleArn for ALB or ListenerArn for NLB. Got: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456`  
*解決策*: Application Load Balancer を使用する場合は、リスナー ARN ではなく、`productionListenerRule` と `testListenerRule` のリスナールール ARN を指定する必要があります。Network Load Balancer の場合は、リスナー ARN を使用する必要があります。  
 リスナー ARN を確認する方法については、「*Application Load Balancer ユーザーガイド*」の「[Application Load Balancer のリスナー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)」を参照してください。ルールの ARN の形式は `arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/...` です。

本番リスナーとテストリスナーの両方に同じルールを使用する  
*エラーメッセージ*: `The following rules cannot be used as both production and test listener rules: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789`  
*解決策*: 本番トラフィックとテストトラフィックには異なるリスナールールを使用する必要があります。テストターゲットグループにルーティングするテストトラフィック用に別のリスナールールを作成します。

ターゲットグループがリスナールールに関連付けられていない  
*エラーメッセージ*: `Service deployment rolled back because of invalid networking configuration: Target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myAlternateTG/abc123 is not associated with either productionListenerRule or testListenerRule.`  
*解決策*: プライマリターゲットグループと代替ターゲットグループの両方を、本番リスナールールまたはテストリスナールールに関連付ける必要があります。ロードバランサー設定を更新して、両方のターゲットグループがリスナールールに適切に関連付けられるようにします。

Application Load Balancer のテストリスナールールがない  
*エラーメッセージ*: `For Application LoadBalancer, testListenerRule is required when productionListenerRule is not associated with both targetGroup and alternateTargetGroup`  
*解決策*: Application Load Balancer を使用する場合、両方のターゲットグループが本番リスナールールに関連付けられているのでなければ、テストリスナールールを指定する必要があります。設定に `testListenerRule` を追加し、両方のターゲットグループが本番リスナールールまたはテストリスナールールに関連付けられるようにします。詳細については、「*Application Load Balancer ユーザーガイド*」の「[Application Load Balancer のリスナー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)」を参照してください。

### ターゲットグループ設定のエラー
<a name="troubleshooting-blue-green-target-groups"></a>

以下の問題は、ブルー/グリーンデプロイのターゲットグループ設定が正しくないことに関連しています。

リスナールールに、トラフィックがある複数のターゲットグループがある  
*エラーメッセージ*: `Service deployment rolled back because of invalid networking configuration. productionListenerRule arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789 should have exactly one target group serving traffic but found 2 target groups which are serving traffic`  
*解決策*: ブルー/グリーンデプロイを開始する前に、リスナールールでトラフィックを受信している (重みがゼロ以外の) ターゲットグループが 1 つだけであることを確認します。リスナールール設定を更新して、トラフィックを受信すべきでないターゲットグループの重みをゼロに設定します。

ロードバランサーエントリ間でターゲットグループが重複している  
*エラーメッセージ*: `Duplicate targetGroupArn found: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myecs-targetgroup/abc123`  
*解決策*: 各ターゲットグループ ARN は、サービス定義のすべてのロードバランサーエントリで一意である必要があります。設定を確認し、ロードバランサーエントリごとに異なるターゲットグループを使用するようにします。

本番リスナールールに想定されないターゲットグループがある  
*エラーメッセージ*: `Service deployment rolled back because of invalid networking configuration. Production listener rule is forwarding traffic to unexpected target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/random-nlb-tg/abc123. Expected traffic to be forwarded to either targetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-targetgroup/def456 or alternateTargetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-tg-alternate/ghi789`  
*解決策*: 本番リスナールールは、サービス定義で指定されていないターゲットグループにトラフィックを転送しています。サービス定義で指定されたターゲットグループにのみトラフィックを転送するようにリスナールールを設定するようにします。  
詳細については、「*Application Load Balancer のユーザーガイド*」の「[転送アクション](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#forward-actions)」を参照してください。

### ロードバランサータイプの設定エラー
<a name="troubleshooting-blue-green-load-balancer-types"></a>

以下の問題は、ブルー/グリーンデプロイのロードバランサータイプの設定が正しくないことに関連しています。

Classic Load Balancer 設定と、Application Load Balancer または Network Load Balancer 設定が混在している  
*エラーメッセージ*: `All loadBalancers must be strictly either ELBv1 (defining loadBalancerName) or ELBv2 (defining targetGroupArn)`  
Classic Load Balancer は、Elastic Load Balancing の前世代のロードバランサーです。現行世代のロードバランサーに移行することをお勧めします。詳細については、「[Classic Load Balancer の移行](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-classic-load-balancer.html)」を参照してください。
*解決策*: すべて Classic Load Balancer を使用するか、すべて Application Load Balancer または Network Load Balancer を使用します。  
Application Load Balancer と Network Load Balancer では、`targetGroupArn` フィールドのみを指定します。

Classic Load Balancer で高度な設定が使用されている  
*エラーメッセージ*: `advancedConfiguration field is not allowed with ELBv1 loadBalancers`  
*解決策*: ブルー/グリーンデプロイの高度な設定は、Application Load Balancer と Network Load Balancer でのみサポートされます。Classic Load Balancer を使用 (`loadBalancerName` で指定) する場合は、`advancedConfiguration` フィールドを使用できません。Application Load Balancer に切り替えるか、`advancedConfiguration` フィールドを削除します。

ロードバランサー間で高度な設定に一貫性がない  
*エラーメッセージ*: `Either all or none of the provided loadBalancers must have advancedConfiguration defined`  
*解決策*: 複数のロードバランサーを使用している場合は、`advancedConfiguration` をすべてのロードバランサーに定義するか、いずれのロードバランサーにも定義しないようにする必要があります。設定を更新して、すべてのロードバランサーエントリ間で整合性を確保します。

ブルー/グリーンデプロイの高度な設定がない  
*エラーメッセージ*: `advancedConfiguration field is required for all loadBalancers when using a non-ROLLING deployment strategy`  
*解決策*: Application Load Balancer でブルー/グリーンデプロイ戦略を使用する場合は、すべてのロードバランサーエントリの `advancedConfiguration` フィールドを指定する必要があります。必要な `advancedConfiguration` をロードバランサー設定に追加します。

## アクセス許可の問題
<a name="troubleshooting-blue-green-permissions"></a>

以下の問題は、ブルー/グリーンデプロイのアクセス許可が不十分であることに関連しています。

インフラストラクチャロールに信頼ポリシーがない  
*エラーメッセージ*: `Service deployment rolled back because of invalid networking configuration. ECS was unable to manage the ELB resources due to missing permissions on ECS Infrastructure Role 'arn:aws:iam::123456789012:role/Admin'.`  
*解決策*: ロードバランサーリソースの管理に指定された IAM ロールに正しい信頼ポリシーがありません。ロールの信頼ポリシーを更新して、サービスにロールの引き受けを許可します。信頼ポリシーには以下を含める必要があります。    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

ロードバランサーロールに読み取りアクセス許可がない  
*エラーメッセージ*: `service myService failed to describe target health on target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:DescribeTargetHealth because no identity-based policy allows the elasticloadbalancing:DescribeTargetHealth action)`  
*解決策*: ロードバランサーリソースの管理に使用される IAM ロールに、ターゲットのヘルス情報を読み取るアクセス許可がありません。`elasticloadbalancing:DescribeTargetHealth` アクセス許可をロールのポリシーに追加します。Elastic Load Balancing のアクセス許可の詳細については、「[ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)」を参照してください。

ロードバランサーロールに書き込みアクセス許可がない  
*エラーメッセージ*: `service myService failed to register targets in target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:RegisterTargets on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myTargetGroup/abc123 because no identity-based policy allows the elasticloadbalancing:RegisterTargets action)`  
*解決策*: ロードバランサーリソースの管理に使用される IAM ロールに、ターゲットを登録するアクセス許可がありません。`elasticloadbalancing:RegisterTargets` アクセス許可をロールのポリシーに追加します。Elastic Load Balancing のアクセス許可の詳細については、「[ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)」を参照してください。

リスナールールを変更するアクセス許可がありません  
*エラーメッセージ*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. User: arn:aws:sts::123456789012:assumed-role/myELBRole/ECSNetworkingWithELB is not authorized to perform: elasticloadbalancing:ModifyListener on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456 because no identity-based policy allows the elasticloadbalancing:ModifyListener action`  
*解決策*: ロードバランサーリソースの管理に使用される IAM ロールに、リスナーを変更するアクセス許可がありません。`elasticloadbalancing:ModifyListener` アクセス許可をロールのポリシーに追加します。Elastic Load Balancing のアクセス許可の詳細については、「[ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)」を参照してください。

ブルー/グリーンデプロイでは、`AmazonECS-ServiceLinkedRolePolicy` マネージドポリシーをインフラストラクチャロールにアタッチすることをお勧めします。これには、ロードバランサーリソースを管理するために必要なすべてのアクセス許可が含まれます。

## ライフサイクルフックの問題
<a name="troubleshooting-blue-green-lifecycle-hooks"></a>

以下の問題は、ブルー/グリーンデプロイのライフサイクルフックに関連しています。

Lambda フックロールの信頼ポリシーが正しくない  
*エラーメッセージ*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to assume role arn:aws:iam::123456789012:role/Admin`  
*解決策*: Lambda ライフサイクルフックに指定された IAM ロールに正しい信頼ポリシーがありません。ロールの信頼ポリシーを更新して、サービスにロールの引き受けを許可します。信頼ポリシーには以下を含める必要があります。    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

Lambda フックが FAILED ステータスを返す  
*エラーメッセージ*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. Lifecycle hook target arn:aws:lambda:us-west-2:123456789012:function:myHook returned FAILED status.`  
*解決策*: ライフサイクルフックとして指定された Lambda 関数が FAILED ステータスを返しました。Amazon CloudWatch Logs の Lambda 関数ログをチェックして失敗の理由を確認し、デプロイイベントを正しく処理するように関数を更新します。

Lambda 関数を呼び出すアクセス許可がない  
*エラーメッセージ*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to invoke hook target arn:aws:lambda:us-west-2:123456789012:function:myHook due to User: arn:aws:sts::123456789012:assumed-role/myLambdaRole/ECS-Lambda-Execution is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-west-2:123456789012:function:myHook because no identity-based policy allows the lambda:InvokeFunction action`  
*解決策*: Lambda ライフサイクルフックに使用される IAM ロールに、Lambda 関数を呼び出すアクセス許可がありません。特定の Lambda 関数 ARN のロールのポリシーに `lambda:InvokeFunction` アクセス許可を追加します。Lambda のアクセス許可の詳細については、「[Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可](blue-green-permissions.md)」を参照してください。

Lambda 関数のタイムアウトまたは無効なレスポンス  
*エラーメッセージ*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to parse the response from arn:aws:lambda:us-west-2:123456789012:function:myHook due to HookStatus must not be null`  
*解決策*: Lambda 関数がタイムアウトしたか、無効なレスポンスを返しました。`hookStatus` フィールドを `SUCCEEDED` または `FAILED` のいずれかに設定して、Lambda 関数が有効なレスポンスを返すようにします。また、Lambda 関数のタイムアウトが検証ロジックに対して適切に設定されていることも確認します。詳細については、「[Amazon ECS サービスデプロイのライフサイクルフック](deployment-lifecycle-hooks.md)」を参照してください。  
有効な Lambda レスポンスの例:  

```
{
  "hookStatus": "SUCCEEDED",
  "reason": "Validation passed"
}
```

# Amazon ECS リニアデプロイ
<a name="deployment-type-linear"></a>

リニアデプロイでは、時間の経過とともに古いサービスリビジョンから新しいサービスリビジョンにトラフィックが同じ割合ずつ徐々に移行されるため、次のステップに進む前に各ステップをモニタリングできます。Amazon ECS リニアデプロイでは、トラフィックの移行速度を制御し、本番稼働トラフィックの量が増加している新しいサービスリビジョンを検証します。このアプローチにより、各増分でパフォーマンスをモニタリングできる制御された方法で変更をデプロイできます。

## リニアデプロイに関連するリソース
<a name="linear-deployment-resources"></a>

Amazon ECS リニアデプロイに関連するリソースは次のとおりです。
+ トラフィックの移行 – Amazon ECS が本番稼働トラフィックを移行するために使用するプロセス。Amazon ECS リニアデプロイの場合、トラフィックは同じ割合の増分で移行され、各増分間の待機時間を設定できます。
+ ステップパーセント – リニアデプロイ中に各増分で移行するトラフィックの割合。このフィールドの値は 2 倍で、有効な値は 3.0～100.0 です。
+ ステップベイク時間 – リニアデプロイ中における各トラフィック移行の増分間の待機時間。有効な値は 0～1,440 分です。
+ デプロイベイク時間 – すべての本番稼働トラフィックを新しいサービスリビジョンに移行した後、古いサービスリビジョンを終了するまでに Amazon ECS が待機する時間 (分単位)。これは本番トラフィックが移行した後に、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間です。
+ ライフサイクルステージ – 「本番トラフィックの移行後」など、デプロイオペレーションの一連のイベント。
+ ライフサイクルフック – 特定のライフサイクルステージで実行される Lambda 関数。デプロイを検証する関数を作成できます。PRODUCTION\$1TRAFFIC\$1SHIFT 用に設定された Lambda 関数またはライフサイクルフックは、本番トラフィックの移行ステップごとに呼び出されます。
+ ターゲットグループ – リクエストを 1 つ以上の登録済みターゲットにルーティングするために使用される Elastic Load Balancing リソース (EC2 インスタンスなど)。リスナーを作成するときは、デフォルトアクションのターゲットグループを指定します。トラフィックは、リスナー規則で指定されたターゲットグループに転送されます。
+ リスナー – 設定したプロトコルおよびポートを使用し、接続リクエストを確認する Elastic Load Balancing リソース。リスナーに対して定義したルールにより、Amazon ECS が登録済みターゲットにリクエストをルーティングする方法が決定します。
+ ルール – リスナーに関連付けられた Elastic Load Balancing リソース。ルールはリクエストのルーティング方法を定義し、アクション、条件、優先度で構成されます。

## 考慮事項
<a name="linear-deployment-considerations"></a>

デプロイタイプを選択する際、次の内容を考慮してください。
+ リソースの使用量: リニアデプロイではブルーおよびグリーンのサービスリビジョンの両方が一時的に実行されるため、デプロイ中にリソースの使用量が 2 倍になる場合があります。
+ デプロイモニタリング: リニアデプロイではデプロイステータスの詳細な情報が提示されるため、デプロイプロセスの各ステージとトラフィック移行の増分をモニタリングできます。
+ ロールバック: ブルーリビジョンがベイク時間が終了するまで実行が継続されるため、問題が検出された場合、リニアデプロイでは前のバージョンへのロールバックが容易になります。
+ 段階的な検証: リニアデプロイでは、本番稼働トラフィックの量を増やして新しいリビジョンを検証できるため、デプロイの信頼性が向上します。
+ デプロイ期間: ステップ間のトラフィック移行の増分と待機時間のため、リニアデプロイは一括デプロイよりも完了に時間を要します。

## リニアデプロイの仕組み
<a name="linear-deployment-how-works"></a>

Amazon ECS リニアデプロイプロセスは構造化されたアプローチに従っており、安全かつ信頼性の高いアプリケーション更新を実現する 6 つの異なるフェーズで構成されます。各フェーズは、アプリケーションを現在のバージョン (ブルー) から新しいバージョン (グリーン) に検証および移行するためにそれ特有の目的を果たします。

1. 準備フェーズ: 既存のブルー環境と一緒にグリーン環境を作成します。

1. デプロイフェーズ: 新しいサービスリビジョンをグリーン環境にデプロイします。Amazon ECS は更新されたサービスリビジョンを使用して新しいタスクを起動し、ブルー環境は引き続き本番トラフィックを処理します。

1. テストフェーズ: テストトラフィックルーティングを使用してグリーン環境を検証します。Application Load Balancer によってテストリクエストがグリーン環境に送信され、本番トラフィックはブルー環境の状態にとどまります。

1. リニアトラフィック移行のフェーズ: 設定されたデプロイ戦略に基づき、本番稼働トラフィックをブルーからグリーンに一定割合で移行します。

1. モニタリングフェーズ: ベイク期間中のアプリケーションの正常性、パフォーマンスメトリクス、アラーム状態がモニタリングされます。ロールバックオペレーションは問題が検出されると開始されます。

1. 完了フェーズ: ブルー環境を終了してデプロイを確定します。

リニアトラフィック移行フェーズは、以下のステップに従います。
+ 初期 – デプロイは、トラフィックが 100% ブルー (現在の) サービスリビジョンにルーティングされた状態で開始されます。グリーン (新しい) サービスリビジョンはテストトラフィックを受信しますが、初期段階では本番トラフィックを受信しません。
+ 増分トラフィック移行 – トラフィックは、同じ割合の増分でブルーからグリーンに徐々に移行されます。例えば、ステップ設定が 10.0% の場合、トラフィックの移行は次のように行われます。
  + ステップ 1: 10.0% がグリーンに、90.0% がブルーに
  + ステップ 2: 20.0% がグリーンに、80.0% がブルーに
  + ステップ 3: 30.0% がグリーンに、70.0% がブルーに
  + 100% がグリーンになるまで続きます。
+ ステップベイク時間 – 各トラフィック移行の増分間で、デプロイは設定可能な期間 (ステップベイク時間) 待機し、トラフィック負荷の増加に伴う新しいリビジョンのパフォーマンスのモニタリングと検証を可能にします。トラフィックが 100.0% 移行されると、最後のステップのベイク時間はスキップされることに注意してください。
+ ライフサイクルフック – オプションの Lambda 関数は、デプロイ中のさまざまなライフサイクル段階で実行して、自動検証、モニタリング、またはカスタムロジックを実行できます。PRODUCTION\$1TRAFFIC\$1SHIFT 用に設定された Lambda 関数またはライフサイクルフックは、本番トラフィックの移行ステップごとに呼び出されます。

## デプロイのライフサイクルステージ
<a name="linear-deployment-lifecycle-stages"></a>

リニアデプロイプロセスは、個別のライフサイクル段階を経て進行し、それぞれに特定の責任と検証チェックポイントがあります。これらのステージを理解すると、デプロイの進行状況をモニタリングして問題を効果的にトラブルシューティングできます。

各ライフサイクルステージは最大 24 時間、さらに PRODUCTION\$1TRAFFIC\$1SHIFT の各トラフィック移行ステップは最大 24 時間継続できます。値を 24 時間未満にとどめることをお勧めします。非同期プロセスがフックをトリガーするために時間が必要になるからです。システムがタイムアウトしてデプロイに失敗し、ステージが 24 時間に達した後にロールバックが開始されます。

CloudFormation デプロイには追加のタイムアウト制限があります。24 時間のステージ制限は有効性が維持されますが、CloudFormation によってデプロイ全体に 36 時間の制限が実施されます。CloudFormation によってデプロイが失敗し、36 時間以内にプロセスが完了しない場合はロールバックが開始されます。


| ライフサイクルのステージ | 説明 | ライフサイクルフックのサポート | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | このステージは、複数のサービスリビジョンが ACTIVE 状態で新しいサービスのデプロイを開始した場合にのみ発生します。 | はい | 
| PRE\$1SCALE\$1UP | グリーンサービスリビジョンは開始されていません。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されています。テストトラフィックがありません。 | はい | 
| SCALE\$1UP | グリーンサービスリビジョンが 100% までにスケールアップし、新しいタスクを起動する時間。現時点では、グリーンサービスリビジョンはトラフィックを処理していません。 | いいえ | 
| POST\$1SCALE\$1UP | グリーンサービスリビジョンが開始されました。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されています。テストトラフィックがありません。 | はい | 
| TEST\$1TRAFFIC\$1SHIFT | ブルーおよびグリーンのサービスリビジョンが実行されています。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されます。グリーンサービスリビジョンは、テストトラフィックの 0% から 100% に移行しています。 | はい | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | テストトラフィックの移行が完了しました。グリーンサービスリビジョンにより、テストトラフィックの 100% が処理されます。 | はい | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | トラフィックは、グリーンがトラフィックの 100% を受信するまで、同じ割合でブルーからグリーンに徐々に移行されます。各トラフィック移行は、24 時間のタイムアウトでライフサイクルフックを呼び出します。 | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 本番トラフィックの移行が完了しました。 | はい | 
| BAKE\$1TIME | ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。 | いいえ | 
| CLEAN\$1UP | ブルーサービスリビジョンにより、実行中のタスク 0 へと完全にスケールダウンされました。グリーンサービスリビジョンは、このステージの後に本番サービスリビジョンになります。 | いいえ | 

# Amazon ECS リニアデプロイに必要なリソース
<a name="linear-deployment-implementation"></a>

マネージドトラフィック移行が実施されるリニアデプロイを使用するには、サービスが次のいずれかの機能を使用する必要があります。
+ Elastic Load Balancing
+ Service Connect

次のリストは、Amazon ECS リニアデプロイに設定する必要がある内容について概要を示しています。
+ サービスは Application Load Balancer、Network Load Balancer、Service Connect を使用します。適切なリソースを設定します。
  + Application Load Balancer – 詳細については、「[ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Application Load Balancer リソース](alb-resources-for-blue-green.md)」を参照してください。
  + Network Load Balancer – 詳細については、「[Amazon ECS ブルー/グリーン、リニアおよびカナリアデプロイの Network Load Balancer リソース](nlb-resources-for-blue-green.md)」を参照してください。
  + Service Connect – 詳細については、「[Amazon ECS ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Service Connect リソース](service-connect-blue-green.md)」を参照してください。
+ サービスのデプロイコントローラーを `ECS` に設定します。
+ サービス定義でデプロイ戦略を `linear` として設定します。
+ 必要に応じて、次のように追加のパラメータを設定します。
  + 新しいデプロイのベイク時間
  + 各増分で移行するトラフィックのパーセンテージ。
  + 各トラフィック移行の増分間の待機時間を分単位で表します。
  + 自動ロールバックの CloudWatch アラーム
  + デプロイライフサイクルフック (BEFORE\$1INSTALL、PRODUCTION\$1TRAFFIC\$1SHIFT、POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT などの指定されたデプロイステージで実行される Lambda 関数)

## ベストプラクティス
<a name="linear-deployment-best-practices"></a>

Amazon ECS リニアデプロイを正常に処理するには、次のベストプラクティスに従ってください。
+ **アプリケーションが同時に実行されている両方のサービスリビジョンを処理できることを確認します。**
+ **デプロイ中に両方のサービスリビジョンを処理するため、十分なクラスターキャパシティの確保を計画します。**
+ **ロールバック手順は、本番環境での実装前にテストします。**
+ アプリケーションの正常性を正確に反映する、適切なヘルスチェックを設定します。
+ 新しいサービスリビジョンを十分にテストできるベイク時間を設定します。
+ CloudWatch アラームを実装し、問題を自動的に検出してロールバックをトリガーします。
+ デプロイ速度と検証ニーズのバランスを取るためのステップの割合とベイク時間を選択します。
+ リスクの露出を最小限に抑えるために、重要なアプリケーションには小さなステップの割合 (5～10%) を使用します。
+ ウォームアップや安定に時間がかかるアプリケーションには、長いステップベイク時間を設定します。
+ CloudWatch アラームを実装し、問題を自動的に検出して任意のトラフィック増分でロールバックをトリガーします。
+ 各トラフィック移行中にアプリケーションメトリクスを注意深くモニタリングし、パフォーマンスの低下を早期に検出します。
+ アプリケーションが同時に実行されている両方のサービスリビジョンを処理できることを確認します。
+ ロールバック手順を本番環境に実装する前に異なるトラフィックの割合でテストします。

# Amazon ECS リニアデプロイの作成
<a name="deploy-linear-service"></a>

Amazon ECS リニアデプロイを使用すると、指定した時間間隔でトラフィックを均等に徐々に移行できます。これにより、デプロイプロセスの各ステップで実施する検証を制御できます。

## 前提条件
<a name="deploy-linear-service-prerequisites"></a>

リニアデプロイを開始する前に、次の操作を行います。

1. 適切なアクセス許可を設定します。
   + Elastic Load Balancing のアクセス許可の詳細については、「[ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)」を参照してください。
   + Lambda のアクセス許可の詳細については、「[Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可](blue-green-permissions.md)」を参照してください。

1. Amazon ECS リニアデプロイでは、サービスが次のいずれかの機能を使用する必要があります。適切なリソースを設定してください。
   + Application Load Balancer – 詳細については、「[ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Application Load Balancer リソース](alb-resources-for-blue-green.md)」を参照してください。
   + Network Load Balancer – 詳細については、「[Amazon ECS ブルー/グリーン、リニアおよびカナリアデプロイの Network Load Balancer リソース](nlb-resources-for-blue-green.md)」を参照してください。
   + Service Connect – 詳細については、「[Amazon ECS ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Service Connect リソース](service-connect-blue-green.md)」を参照してください。

## 手順
<a name="deploy-linear-service-procedure"></a>

コンソールまたは AWS CLI を使用して、Amazon ECS リニアデプロイサービスを作成できます。

------
#### [ Console ]

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. サービスを起動するリソースを決定します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deploy-linear-service.html)

   **[サービスの作成]** ページが表示されます。

1. **[サービスの詳細]** で、次の操作を行います。

   1. **[タスク定義ファミリー]** では、使用するタスク定義を選択します。次に **[タスク定義リビジョン]** には、使用するリビジョンを入力します。

   1. **[Service name]** (サービス名) でサービスの名前を入力します。

1. 既存のクラスターでサービスを実行するには、**[既存のクラスター]** にクラスターを選択します。新しいクラスターでサービスを実行するには、**[クラスターの作成]** を選択します。

1. クラスターのインフラストラクチャ全体にタスクを分散する方法を選択します。**[コンピュート設定]** で、オプションを選択します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deploy-linear-service.html)

1. **[デプロイメント設定]** で、次の操作を行います。

   1. **[サービスタイプ]** では、**[レプリカ]** を選択します。

   1. **[Desired tasks]** (必要なタスク) で、サービス内で起動および維持するタスクの数を入力します。

   1. Amazon ECS がアベイラビリティーゾーン間のタスクの分散をモニタリングし、不均衡が発生したときにタスクを再分散するには、**[アベイラビリティーゾーンのサービス再調整]** で **[アベイラビリティーゾーンのサービス再調整]** を選択します。

   1. **[ヘルスチェックの猶予期間]** には、タスクの初回起動後にサービススケジューラが異常な Elastic Load Balancing、VPC Lattice、コンテナヘルスチェックを無視する時間 (秒単位) を入力します。ヘルスチェックの猶予期間値を指定しない場合、デフォルト値 0 が使用されます。

1. **[デプロイ設定]** で、リニアデプロイ設定を構成します。

   1. **[デプロイ戦略]** で、**[リニア]** を選択します。

   1. **[トラフィック増分の割合]** には、各増分で移行するトラフィックの割合を入力します (例えば、10% 単位でトラフィックを移行するには 10%)。

   1. **[増分間隔]**には、各トラフィック移行増分間の待機時間を分単位で入力します。

   1. **[ベイク時間]** には、ブルーリビジョンが終了する前に、トラフィックの最終移行後にブルーおよびグリーンのサービスリビジョンの両方が同時に実行される時間 (分) を入力します。

   1. (オプション) Lambda 関数を実行し、デプロイの特定段階で実行します。**[デプロイライフサイクルフック]** で、ライフサイクルフックを実行するステージを選択します。

      ライフサイクルフックを追加する方法

      1. **[Add]** (追加) を選択します。

      1. **[Lambda 関数]** には、ARN の関数名を入力します。

      1. **[ロール]** では、Lambda 関数を呼び出すアクセス許可を持つ IAM ロールを選択します。

      1. **[ライフサイクルステージ]** では、Lambda 関数を実行するステージを選択します。

1. Amazon ECS がデプロイの障害を検出して処理する方法を設定するには、**[Deployment failure detection]** (デプロイ障害検出) を展開し、オプションを選択します。

   1. タスクを開始できない場合にデプロイを停止するには、**[Use the Amazon ECS deployment circuit breaker]** (Amazon ECS デプロイサーキットブレーカーを使用する) を選択します。

      デプロイサーキットブレーカーによってデプロイが失敗状態に設定されたときに、ソフトウェアがデプロイを最後に完了したデプロイ状態に自動的にロールバックするようにするには、**[失敗時のロールバック]** を選択します。

   1. アプリケーションメトリクスに基づいてデプロイを停止するには、**[CloudWatch アラームを使用する]** を選択します。次に、**[CloudWatch アラーム名]** からアラームを選択します。新しいアラームを作成するには、CloudWatch コンソールに移動します。

      CloudWatch アラームによってデプロイが失敗状態に設定されたときに、ソフトウェアがデプロイを最後に完了したデプロイ状態に自動的にロールバックするようにするには、**[失敗時のロールバック]** を選択します。

1. (オプション) Service Connect を使用してサービスを相互接続するには、**[Service Connect]** を展開して以下を指定します。

   1.  **[Service Connect をオンにする]** を選択します。

   1. **[Service Connect configuration]** (Service Connect 設定) で、クライアントモードを指定します。
      + サービスが名前空間内の他のサービスへの接続のみを必要とするネットワーククライアントアプリケーションを実行している場合は、**[クライアント側のみ]** を選択します。
      + サービスがネットワークまたは Web サービスアプリケーションを実行していて、このサービスにエンドポイントを提供し、名前空間内の他のサービスに接続する必要がある場合は、**[Client and server]** (クライアントとサーバー) を選択します。

   1. デフォルトのクラスター名前空間ではない名前空間を使用するには、**[Namespace]** (名前空間) でサービス名前空間を選択します。この場合、AWS アカウントの同じ AWS リージョンで個別に作成された名前空間、またはAWS Resource Access Manager (AWS RAM) を使用してアカウントと共有されている同じリージョンの名前空間のいずれかを選択できます。共有 AWS Cloud Map 名前空間の詳細については、「*AWS Cloud Map デベロッパーガイド*」の「[クロスアカウント AWS Cloud Map 名前空間の共有](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)」を参照してください。

   1. (オプション) リニアデプロイのテストトラフィックヘッダーのルールを設定します。**[テストトラフィックのルーティング]** では、以下を指定します。

      1. **[テストトラフィックヘッダーのルールの有効化]** を選択し、テスト中に特定のリクエストをグリーンサービスリビジョンにルーティングします。

      1. **[ヘッダー一致ルール]** では、テストトラフィックをルーティングする条件を設定します。
         + **[ヘッダー名]**: 一致する HTTP ヘッダーの名前を入力します (例えば、`X-Test-Version` または `User-Agent`)。
         + **[一致タイプ]**: 一致する条件を選択します。
           + **[完全一致]**: ヘッダー値が指定された値と完全に一致するリクエストをルーティングする
           + **[ヘッダーが存在する]**: 値に関係なく、指定されたヘッダーを含むリクエストをルーティングする
           + **[パターン一致]**: ヘッダー値が指定されたパターンと一致するリクエストをルーティングする
         + **[ヘッダー値]** (完全一致またはパターン一致を使用する場合): 照合する値またはパターンを入力します。

         複数のヘッダー一致ルールを追加し、複雑なルーティングロジックを作成できます。設定されたルールに一致するリクエストは、テストのためにグリーンサービスリビジョンにルーティングされます。

      1. **[ヘッダールールの追加]** を選択し、追加のヘッダー一致条件を設定します。
**注記**  
テストトラフィックヘッダーのルールにより、完全なデプロイを完了する前に、制御されたトラフィックで新機能を検証できます。これにより、ブルーサービスリビジョンへの通常のトラフィックフローを維持しながら、特定のリクエスト (内部テストツールやベータユーザーなどによるもの) でグリーンサービスリビジョンをテストできます。

   1. （オプション) ログ設定を指定します。**[ログコレクションを使用]** を選択します。デフォルトのオプションでは、コンテナログを CloudWatch Logs に送信します。その他のログドライバオプションは、AWS FireLens を使用して構成されます。詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。

      以下では、各コンテナログの送信先について詳しく説明します。
      + **Amazon CloudWatch** — コンテナログを CloudWatch Logs に送信するようにタスクを設定します。デフォルトのログドライバーオプションが提供され、ユーザーに代わり CloudWatch ロググループを作成します。別のロググループ名を指定するには、ドライバーオプションの値を変更します。
      + **[Amazon Data Firehose]** — Firehose にコンテナログを送信するようタスクを設定します。Firehose 配信ストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別の配信ストリーム名を指定するには、ドライバーオプションの値を変更します。
      + **Amazon Kinesis Data Streams** — Kinesis Data Streams にコンテナログを送信するようタスクを設定します。Kinesis Data Streams のストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別のストリーム名を指定するには、ドライバーオプションの値を変更します。
      + **Amazon OpenSearch Service** — コンテナログを OpenSearch Service ドメインに送信するようタスクを設定します。ログドライバーオプションを提供する必要があります。
      + **Amazon S3** — Amazon S3 バケットにコンテナログを送信するようタスクを設定します。デフォルトのログドライバーオプションが提供されていますが、有効な Amazon S3 バケット名を指定する必要があります。

1. (オプション) リニアデプロイ用に **[ロードバランシング]** を設定します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deploy-linear-service.html)

1. （オプション）サービスとタスクを識別しやすくするには、**[Tags]** (タグ) セクションを展開し、タグを設定します。

   新しく起動したすべてのタスクに対して、Amazon ECS がクラスター名とタスク定義タグで自動的にタグ付けするようにするには、**[Amazon ECS マネージドタグを有効にする]** を選択し、**[タグの伝播元]** で **[タスク定義]** を選択します。

   新しく起動したすべてのタスクに対して、Amazon ECS がクラスター名とサービスタグで自動的にタグ付けするようにするには、**[Amazon ECS マネージドタグを有効にする]** を選択し、**[タグの伝播元]** で **[サービス]** を選択します。

   タグを追加または削除します。
   + [タグを追加] **[Add tag]** (タグを追加) を選択し、以下を実行します。
     + [**キー**] にはキー名を入力します。
     + [**値**] にキー値を入力します。
   + [タグの削除] タグの横にある [**タグの削除**] を選択します。

1. **[作成]** を選択します。

------
#### [ AWS CLI ]

1. `linear-service-definition.json` という名前のファイルを作成し、次の内容を記述します。

   *user-input* を独自の値に置き換えます。

   ```
   {
     "serviceName": "myLinearService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "LINEAR",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "linearConfiguration": {
         "stepPercentage": 10.0,
         "stepBakeTimeInMinutes":6
       },
       "bakeTimeInMinutes": 10,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       }
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-linear-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. `create-service` を実行します。

   ```
   aws ecs create-service --cli-input-json file://linear-service-definition.json
   ```

------

## 次のステップ
<a name="deploy-linear-service-next-steps"></a>
+ サービスを更新してデプロイを開始します。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。
+ デプロイプロセスをモニタリングし、リニアパターンに従っていることを確認します。
  + グリーンサービスリビジョンが作成され、スケールアップされる
  + トラフィックは指定された間隔で段階的に移行されます。
  + 各増分は、次の移行の前に指定された間隔を待機します。
  + すべてのトラフィックが移行されると、ベイク時間が開始されます。
  + ベイク時間が過ぎたら、ブルーリビジョンが終了する

# Amazon ECS カナリアデプロイ
<a name="canary-deployment"></a>

Canary デプロイでは、まず初期テストのためにトラフィックのごく一部を新しいリビジョンにルーティングし、Canary フェーズが正常に完了したら、残りのすべてのトラフィックを一度に移行します。Amazon ECS カナリアデプロイでは、リスクの露出を最小限に抑えながら、実際のユーザートラフィックで新しいサービスリビジョンを検証します。このアプローチでは、パフォーマンスをモニタリングし、問題が検出された場合には迅速にロールバックしながら変更をデプロイできます。

## カナリアデプロイに関連するリソース
<a name="canary-deployment-resources"></a>

Amazon ECS カナリアデプロイに関連するリソースは次のとおりです。
+ トラフィックの移行 – Amazon ECS が本番稼働トラフィックを移行するために使用するプロセス。Amazon ECS カナリアデプロイの場合、トラフィックは 2 つのフェーズで移行されます。最初に Canary の割合に応じて移行され、次にデプロイを完了するために移行されます。
+ Canary の割合 – 評価期間中に新しいバージョンにルーティングされたトラフィックの割合。
+ Canary ベイク時間 – フルデプロイに進む前に Canary バージョンをモニタリングする期間。
+ デプロイベイク時間 – すべての本番稼働トラフィックを新しいサービスリビジョンに移行した後、古いサービスリビジョンを終了するまでに Amazon ECS が待機する時間 (分単位)。これは本番トラフィックが移行した後に、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間です。
+ ライフサイクルステージ – 「本番トラフィックの移行後」など、デプロイオペレーションの一連のイベント。
+ ライフサイクルフック – 特定のライフサイクルステージで実行される Lambda 関数。デプロイを検証する関数を作成できます。
+ ターゲットグループ – リクエストを 1 つ以上の登録済みターゲットにルーティングするために使用される Elastic Load Balancing リソース (EC2 インスタンスなど)。リスナーを作成するときは、デフォルトアクションのターゲットグループを指定します。トラフィックは、リスナー規則で指定されたターゲットグループに転送されます。
+ リスナー – 設定したプロトコルおよびポートを使用し、接続リクエストを確認する Elastic Load Balancing リソース。リスナーに対して定義したルールにより、Amazon ECS が登録済みターゲットにリクエストをルーティングする方法が決定します。
+ ルール – リスナーに関連付けられた Elastic Load Balancing リソース。ルールはリクエストのルーティング方法を定義し、アクション、条件、優先度で構成されます。

## 考慮事項
<a name="canary-deployment-considerations"></a>

デプロイタイプを選択する際、次の内容を考慮してください。
+ リソースの使用状況: カナリアデプロイでは、評価期間中に元のタスクセットと Canary タスクセットの両方が同時に実行され、リソースの使用量が増加します。
+ トラフィック量: Canary の割合が、新しいバージョンの有意な検証に十分なトラフィックを生成していることを確認します。
+ 複雑さのモニタリング: Canary デプロイでは、2 つの異なるバージョン間でメトリクスを同時にモニタリングおよび比較する必要があります。
+ ロールバック速度: カナリアデプロイでは、トラフィックを元のタスクセットに戻すことで、クイックロールバックが可能になります。
+ リスク軽減: カナリアデプロイでは、少数のユーザーへの露出を制限することで、優れたリスクを軽減できます。
+ デプロイ期間: カナリアデプロイには、全体的なデプロイ時間を延長するものの、検証の機会が設けられている評価期間が含まれます。

## カナリアデプロイの仕組み
<a name="canary-how-it-works"></a>

Amazon ECS カナリアデプロイプロセスは構造化されたアプローチに従っており、安全かつ信頼性の高いアプリケーション更新を実現する 6 つの異なるフェーズで構成されます。各フェーズは、アプリケーションを現在のバージョン (ブルー) から新しいバージョン (グリーン) に検証および移行するためにそれ特有の目的を果たします。

1. 準備フェーズ: 既存のブルー環境と一緒にグリーン環境を作成します。

1. デプロイフェーズ: 新しいサービスリビジョンをグリーン環境にデプロイします。Amazon ECS は更新されたサービスリビジョンを使用して新しいタスクを起動し、ブルー環境は引き続き本番トラフィックを処理します。

1. テストフェーズ: テストトラフィックルーティングを使用してグリーン環境を検証します。Application Load Balancer によってテストリクエストがグリーン環境に送信され、本番トラフィックはブルー環境の状態にとどまります。

1. Canary トラフィック移行フェーズ: Canary フェーズ中に設定されたトラフィックの割合を新しいグリーンサービスリビジョンに移行し、次にトラフィックの 100.0% をグリーンサービスリビジョンに移行します。

1. モニタリングフェーズ: ベイク期間中のアプリケーションの正常性、パフォーマンスメトリクス、アラーム状態がモニタリングされます。ロールバックオペレーションは問題が検出されると開始されます。

1. 完了フェーズ: ブルー環境を終了してデプロイを確定します。

Canary トラフィックの移行フェーズは、次のステップに従います。
+ 初期 – デプロイは、トラフィックが 100% ブルー (現在の) サービスリビジョンにルーティングされた状態で開始されます。グリーン (新しい) サービスリビジョンはテストトラフィックを受信しますが、初期段階では本番トラフィックを受信しません。
+ Canary トラフィックの移行 – これは 2 ステップのトラフィック移行戦略です。
  + ステップ 1: 10.0% がグリーンに、90.0% がブルーに
  + ステップ 2: 100.0% がグリーンに、0.0% がブルーに
+ Canary ベイク時間 – Canary トラフィックの移行後に設定可能な時間 (Canary ベイク時間) 待機し、トラフィック負荷の増加に伴う新しいリビジョンのパフォーマンスのモニタリングと検証を可能にします。
+ ライフサイクルフック – オプションの Lambda 関数は、デプロイ中のさまざまなライフサイクル段階で実行して、自動検証、モニタリング、またはカスタムロジックを実行できます。PRODUCTION\$1TRAFFIC\$1SHIFT 用に設定された Lambda 関数またはライフサイクルフックは、本番トラフィックの移行ステップごとに呼び出されます。

### デプロイのライフサイクルステージ
<a name="canary-deployment-lifecycle-stages"></a>

カナリアデプロイプロセスは、個別のライフサイクルステージを経て進行し、それぞれのステージに特定の責任と検証チェックポイントがあります。これらのステージを理解すると、デプロイの進行状況をモニタリングして問題を効果的にトラブルシューティングできます。

各ライフサイクルステージは最大 24 時間、さらに PRODUCTION\$1TRAFFIC\$1SHIFT の各トラフィック移行ステップは最大 24 時間継続できます。値を 24 時間未満にとどめることをお勧めします。非同期プロセスがフックをトリガーするために時間が必要になるからです。システムがタイムアウトしてデプロイに失敗し、ステージが 24 時間に達した後にロールバックが開始されます。

CloudFormation デプロイには追加のタイムアウト制限があります。24 時間のステージ制限は有効性が維持されますが、CloudFormation によってデプロイ全体に 36 時間の制限が実施されます。CloudFormation によってデプロイが失敗し、36 時間以内にプロセスが完了しない場合はロールバックが開始されます。


**ライフサイクルのステージ**  

| ライフサイクルのステージ | 説明 | ライフサイクルフックのサポート | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | このステージは、複数のサービスリビジョンが ACTIVE 状態で新しいサービスのデプロイを開始した場合にのみ発生します。 | はい | 
| PRE\$1SCALE\$1UP | グリーンサービスリビジョンは開始されていません。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されています。テストトラフィックがありません。 | はい | 
| SCALE\$1UP | グリーンサービスリビジョンが 100% までにスケールアップし、新しいタスクを起動する時間。現時点では、グリーンサービスリビジョンはトラフィックを処理していません。 | いいえ | 
| POST\$1SCALE\$1UP | グリーンサービスリビジョンが開始されました。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されています。テストトラフィックがありません。 | はい | 
| TEST\$1TRAFFIC\$1SHIFT | ブルーおよびグリーンのサービスリビジョンが実行されています。ブルーサービスリビジョンにより、本番トラフィックの 100% が処理されます。グリーンサービスリビジョンは、テストトラフィックの 0% から 100% に移行しています。 | はい | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | テストトラフィックの移行が完了しました。グリーンサービスリビジョンにより、テストトラフィックの 100% が処理されます。 | はい | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | Canary 本番稼働トラフィックはグリーンリビジョンにルーティングされ、ライフサイクルフックは 24 時間のタイムアウトで呼び出されます。2 番目のステップでは、残りの本番稼働トラフィックをグリーンリビジョンに移行します。 | はい | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 本番トラフィックの移行が完了しました。 | はい | 
| BAKE\$1TIME | ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される期間。 | いいえ | 
| CLEAN\$1UP | ブルーサービスリビジョンにより、実行中のタスク 0 へと完全にスケールダウンされました。グリーンサービスリビジョンは、このステージの後に本番サービスリビジョンになります。 | いいえ | 

### 設定パラメータ
<a name="canary-configuration-parameters"></a>

カナリアデプロイデプロイには、次の設定パラメータが必要です。
+ Canary の割合 – Canary フェーズ中に新しいサービスリビジョンにルーティングするトラフィックの割合。これにより、本番稼働トラフィックの制御されたサブセットによるテストが可能になります。
+ Canary ベイク時間 – Canary フェーズ中に残りのトラフィックを新しいサービスリビジョンに移行するまで待機する時間。これにより、新しいバージョンをモニタリングして検証する時間を確保できます。

### トラフィック管理
<a name="canary-traffic-management"></a>

カナリアデプロイでは、ロードバランサーのターゲットグループを使用してトラフィックの分散を管理します。
+ 元のターゲットグループ – 現在の安定バージョンのタスクが含まれ、トラフィックの大部分を受信します。
+ Canary ターゲットグループ – 新しいバージョンのタスクが含まれ、テスト用のトラフィックのごく一部を受信します。
+ 加重ルーティング – ロードバランサーは加重ルーティングルールを使用して、設定された Canary の割合に基づいてターゲットグループ間でトラフィックを分散します。

### モニタリングと評価
<a name="canary-monitoring-validation"></a>

効果的なカナリアデプロイは、包括的なモニタリングに基づきます。
+ ヘルスチェック – 両方のタスクセットは、トラフィックを受信する前にヘルスチェックに合格する必要があります。
+ メトリクスの比較 – 応答時間、エラー率、スループットなど、元のバージョンと Canary バージョン間で主要なパフォーマンス指標を比較します。
+ 自動ロールバック – Canary バージョンのパフォーマンスが低下した場合に自動的にロールバックをトリガーするように CloudWatch アラームを設定します。
+ 手動検証 – 評価期間を使用して、続行する前にログ、メトリクス、ユーザーフィードバックを手動で確認します。

### カナリアデプロイのベストプラクティス
<a name="canary-best-practices"></a>

サービスを使用したカナリアデプロイを成功させるには、以下のベストプラクティスに従ってください。

#### 適切なトラフィックの割合を選択する
<a name="canary-traffic-percentage"></a>

Canary トラフィックの割合を選択するときは、次の要因を考慮してください。
+ 小規模から開始する – 問題が発生した場合の影響を最小限に抑えるために、トラフィックの 5～10% から開始します。
+ アプリケーションの重要度を検討する – ミッションクリティカルなアプリケーションにはより小さな割合を使用し、重要度の低いサービスにはより大きな割合を使用します。
+ トラフィック量を考慮する – Canary の割合が有意な検証のために十分なトラフィックを生成していることを確認します。

#### 適切な評価期間を設定する
<a name="canary-evaluation-time"></a>

以下の考慮事項に基づいて評価期間を設定します。
+ 十分な時間 – 有意なパフォーマンスデータをキャプチャするのに十分な評価期間を設定します。通常は 10～30 分です。
+ トラフィックパターンを検討する – アプリケーションのトラフィックパターンとピーク使用時間を考慮します。
+ 速度と安全性のバランス – 評価期間が長いほどデータが増加しますが、デプロイ速度は低下します。

#### 包括的なモニタリングを実装する
<a name="canary-monitoring-setup"></a>

カナリアデプロイのパフォーマンスを追跡するようにモニタリングを設定します。
+ 主要メトリクス – 両方のタスクセットの応答時間、エラー率、スループット、リソース使用率をモニタリングします。
+ アラームベースのロールバック – メトリクスがしきい値を超えたときにロールバックを自動的にトリガーするように CloudWatch アラームを設定します。
+ 比較分析 – ダッシュボードを設定して、元のバージョンと Canary バージョン間のメトリクスを並べて比較します。
+ ビジネスメトリクス – 変換率やユーザーエンゲージメントなどのビジネス固有のメトリクスを技術メトリクスとともに設定します。

#### ロールバック戦略を計画する
<a name="canary-rollback-strategy"></a>

以下の戦略を使用して、潜在的なロールバックシナリオに備えます。
+ 自動ロールバック – ヘルスチェックとパフォーマンスメトリクスに基づいて自動ロールバックトリガーを設定します。
+ 手動ロールバック手順 – 自動トリガーがすべての問題をキャプチャしない場合の手動ロールバックの明確な手順を文書化します。
+ ロールバックのテスト実施 – ロールバック手順を定期的にテストして、必要に応じて正しく動作することを確認します。

#### デプロイ前に徹底的に検証する
<a name="canary-testing-validation"></a>

カナリアデプロイを続行する前に、徹底的な検証を実施するようにしてください。
+ デプロイ前のテスト実施 – カナリアデプロイ前にステージング環境の変更を徹底的にテストします。
+ ヘルスチェック設定 – ヘルスチェックがアプリケーションの準備状況と機能を正確に反映していることを確認します。
+ 依存関係の検証 – 新しいバージョンにダウンストリームおよびアップストリームサービスとの互換性があることを確認します。
+ データ整合性 – データベーススキーマの変更とデータ移行に下位互換性があることを確認します。

#### チームの関与を調整する
<a name="canary-team-coordination"></a>

カナリアデプロイ中に効率的なチームの調整を実施します。
+ デプロイウィンドウ – チームがモニタリングして対応できる営業時間内にカナリアデプロイをスケジュールします。
+ コミュニケーションチャネル – デプロイステータスと問題のエスカレーションに関する明確なコミュニケーションチャネルを確立します。
+ ロールの割り当て – モニタリング、意思決定、ロールバック実行の役割と責任を定義します。

# Amazon ECS カナリアデプロイに必要なリソース
<a name="canary-deployment-implementation"></a>

マネージドトラフィック移行が実施されるカナリアデプロイを使用するには、サービスが次のいずれかの機能を使用する必要があります。
+ Elastic Load Balancing
+ Service Connect

次のリストは、Amazon ECS カナリアデプロイに設定する必要がある内容について概要を示しています。
+ サービスは Application Load Balancer、Network Load Balancer、Service Connect を使用します。適切なリソースを設定します。
  + Application Load Balancer – 詳細については、「[ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Application Load Balancer リソース](alb-resources-for-blue-green.md)」を参照してください。
  + Network Load Balancer – 詳細については、「[Amazon ECS ブルー/グリーン、リニアおよびカナリアデプロイの Network Load Balancer リソース](nlb-resources-for-blue-green.md)」を参照してください。
  + Service Connect – 詳細については、「[Amazon ECS ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Service Connect リソース](service-connect-blue-green.md)」を参照してください。
+ サービスのデプロイコントローラーを `ECS` に設定します。
+ サービス定義でデプロイ戦略を `canary` として設定します。
+ 必要に応じて、次のように追加のパラメータを設定します。
  + 新しいデプロイのベイク時間
  + Canary フェーズ中に新しいサービスリビジョンにルーティングするトラフィックの割合。
  + Canary フェーズ中に残りのトラフィックを新しいサービスリビジョンに移行するまで待機する期間。
  + 自動ロールバックの CloudWatch アラーム
  + デプロイのライフサイクルフック (指定されたデプロイステージで実行される Lambda 関数)

## ベストプラクティス
<a name="canary-deployment-best-practices"></a>

Amazon ECS カナリアデプロイを正常に処理するには、次のベストプラクティスに従ってください。
+ **アプリケーションが同時に実行されている両方のサービスリビジョンを処理できることを確認します。**
+ **デプロイ中に両方のサービスリビジョンを処理するため、十分なクラスターキャパシティの確保を計画します。**
+ **ロールバック手順は、本番環境での実装前にテストします。**
+ アプリケーションの正常性を正確に反映する、適切なヘルスチェックを設定します。
+ グリーンデプロイの十分なテストを可能にするベイク時間を設定します。
+ CloudWatch アラームを実装し、問題を自動的に検出してロールバックをトリガーします。
+ ライフサイクルフックを使用し、各デプロイステージで自動テストを実行します。
+ 小さな Canary の割合 (5～10%) から始めて、問題が発生した場合の影響を最小限に抑えます。
+ 有意義なパフォーマンスデータ収集のための十分な時間を確保できる適切な評価期間を設定します。
+ 自動ロールバックトリガーの CloudWatch アラームを使用して包括的なモニタリングを実装します。
+ アプリケーションの準備状況と機能を正確に反映するヘルスチェックを設定します。
+ 評価中に、技術的メトリクス (応答時間、エラー率) とビジネスメトリクスの両方をモニタリングします。
+ アプリケーションがセッションや状態に関する問題が発生しない状態でトラフィックの分割を処理できることを確認します。
+ ロールバック手順を計画し、定期的にテストして、必要に応じて機能することを確認します。
+ チームがモニタリングして対応できる営業時間内にカナリアデプロイをスケジュール設定します。
+ カナリアデプロイを実施する前に、ステージング環境で変更を詳細に検証します。
+ 手動介入とロールバックの決定に関する明確な手順を文書化します。

# Amazon ECS カナリアデプロイの作成
<a name="deploy-canary-service"></a>

Amazon ECS カナリアデプロイを使用すると、トラフィックのごく一部を新しいサービスリビジョン (「Canary」) に移行できます。デプロイを検証し、指定した間隔で残りのトラフィックをすべて一度に移行します。このアプローチでは、フルデプロイの前に最小限のリスクで新機能をテストできます。

## 前提条件
<a name="deploy-canary-service-prerequisites"></a>

カナリアデプロイを開始する前に、次の操作を実行します。

1. 適切なアクセス許可を設定します。
   + Elastic Load Balancing のアクセス許可の詳細については、「[ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)」を参照してください。
   + Lambda のアクセス許可の詳細については、「[Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可](blue-green-permissions.md)」を参照してください。

1. Amazon ECS カナリアデプロイでは、サービスが次のいずれかの機能を使用する必要があります。適切なリソースを設定してください。
   + Application Load Balancer – 詳細については、「[ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Application Load Balancer リソース](alb-resources-for-blue-green.md)」を参照してください。
   + Network Load Balancer – 詳細については、「[Amazon ECS ブルー/グリーン、リニアおよびカナリアデプロイの Network Load Balancer リソース](nlb-resources-for-blue-green.md)」を参照してください。
   + Service Connect – 詳細については、「[Amazon ECS ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Service Connect リソース](service-connect-blue-green.md)」を参照してください。

## 手順
<a name="deploy-canary-service-procedure"></a>

コンソールまたは AWS CLI を使用して、Amazon ECS カナリアデプロイサービスを作成できます。

------
#### [ Console ]

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. サービスを起動するリソースを決定します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deploy-canary-service.html)

   **[サービスの作成]** ページが表示されます。

1. **[サービスの詳細]** で、次の操作を行います。

   1. **[タスク定義ファミリー]** では、使用するタスク定義を選択します。次に **[タスク定義リビジョン]** には、使用するリビジョンを入力します。

   1. **[Service name]** (サービス名) でサービスの名前を入力します。

1. 既存のクラスターでサービスを実行するには、**[既存のクラスター]** にクラスターを選択します。新しいクラスターでサービスを実行するには、**[クラスターの作成]** を選択します。

1. クラスターのインフラストラクチャ全体にタスクを分散する方法を選択します。**[コンピュート設定]** で、オプションを選択します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deploy-canary-service.html)

1. **[デプロイメント設定]** で、次の操作を行います。

   1. **[サービスタイプ]** では、**[レプリカ]** を選択します。

   1. **[Desired tasks]** (必要なタスク) で、サービス内で起動および維持するタスクの数を入力します。

   1. Amazon ECS がアベイラビリティーゾーン間のタスクの分散をモニタリングし、不均衡が発生したときにタスクを再分散するには、**[アベイラビリティーゾーンのサービス再調整]** で **[アベイラビリティーゾーンのサービス再調整]** を選択します。

   1. **[ヘルスチェックの猶予期間]** には、タスクの初回起動後にサービススケジューラが異常な Elastic Load Balancing、VPC Lattice、コンテナヘルスチェックを無視する時間 (秒単位) を入力します。ヘルスチェックの猶予期間値を指定しない場合、デフォルト値 0 が使用されます。

1. **[デプロイ設定]** で、カナリアデプロイ設定を構成します。

   1. **[デプロイ戦略]** で、**[Canary]** を選択します。

   1. **[Canary の割合]** には、最初のステージでグリーンサービスリビジョンに移行するトラフィックの割合を入力します (例えば、最初の Canary トラフィックの場合は 10%)。

   1. **[Canary ベイク時間]** には、残りのトラフィックをグリーンサービスリビジョンに移行するまでに待機する時間を分単位で入力します。

   1. **[ベイク時間]** には、ブルーリビジョンが終了する前に、トラフィックの最終移行後にブルーおよびグリーンのサービスリビジョンの両方が同時に実行される時間 (分) を入力します。

   1. (オプション) Lambda 関数を実行し、デプロイの特定段階で実行します。**[デプロイライフサイクルフック]** で、ライフサイクルフックを実行するステージを選択します。

      ライフサイクルフックを追加する方法

      1. **[Add]** (追加) を選択します。

      1. **[Lambda 関数]** には、ARN の関数名を入力します。

      1. **[ロール]** では、Lambda 関数を呼び出すアクセス許可を持つ IAM ロールを選択します。

      1. **[ライフサイクルステージ]** では、Lambda 関数を実行するステージを選択します。

1. Amazon ECS がデプロイの障害を検出して処理する方法を設定するには、**[Deployment failure detection]** (デプロイ障害検出) を展開し、オプションを選択します。

   1. タスクを開始できない場合にデプロイを停止するには、**[Use the Amazon ECS deployment circuit breaker]** (Amazon ECS デプロイサーキットブレーカーを使用する) を選択します。

      デプロイサーキットブレーカーによってデプロイが失敗状態に設定されたときに、ソフトウェアがデプロイを最後に完了したデプロイ状態に自動的にロールバックするようにするには、**[失敗時のロールバック]** を選択します。

   1. アプリケーションメトリクスに基づいてデプロイを停止するには、**[CloudWatch アラームを使用する]** を選択します。次に、**[CloudWatch アラーム名]** からアラームを選択します。新しいアラームを作成するには、CloudWatch コンソールに移動します。

      CloudWatch アラームによってデプロイが失敗状態に設定されたときに、ソフトウェアがデプロイを最後に完了したデプロイ状態に自動的にロールバックするようにするには、**[失敗時のロールバック]** を選択します。

1. (オプション) Service Connect を使用してサービスを相互接続するには、**[Service Connect]** を展開して以下を指定します。

   1.  **[Service Connect をオンにする]** を選択します。

   1. **[Service Connect configuration]** (Service Connect 設定) で、クライアントモードを指定します。
      + サービスが名前空間内の他のサービスへの接続のみを必要とするネットワーククライアントアプリケーションを実行している場合は、**[クライアント側のみ]** を選択します。
      + サービスがネットワークまたは Web サービスアプリケーションを実行していて、このサービスにエンドポイントを提供し、名前空間内の他のサービスに接続する必要がある場合は、**[Client and server]** (クライアントとサーバー) を選択します。

   1. デフォルトのクラスター名前空間ではない名前空間を使用するには、**[Namespace]** (名前空間) でサービス名前空間を選択します。この場合、AWS アカウントの同じ AWS リージョンで個別に作成された名前空間、またはAWS Resource Access Manager (AWS RAM) を使用してアカウントと共有されている同じリージョンの名前空間のいずれかを選択できます。共有 AWS Cloud Map 名前空間の詳細については、「*AWS Cloud Map デベロッパーガイド*」の「[クロスアカウント AWS Cloud Map 名前空間の共有](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)」を参照してください。

   1. (オプション) カナリアデプロイのテストトラフィックヘッダーのルールを設定します。**[テストトラフィックのルーティング]** では、以下を指定します。

      1. **[テストトラフィックヘッダーのルールの有効化]** を選択し、テスト中に特定のリクエストをグリーンサービスリビジョンにルーティングします。

      1. **[ヘッダー一致ルール]** では、テストトラフィックをルーティングする条件を設定します。
         + **[ヘッダー名]**: 一致する HTTP ヘッダーの名前を入力します (例えば、`X-Test-Version` または `User-Agent`)。
         + **[一致タイプ]**: 一致する条件を選択します。
           + **[完全一致]**: ヘッダー値が指定された値と完全に一致するリクエストをルーティングする
           + **[ヘッダーが存在する]**: 値に関係なく、指定されたヘッダーを含むリクエストをルーティングする
           + **[パターン一致]**: ヘッダー値が指定されたパターンと一致するリクエストをルーティングする
         + **[ヘッダー値]** (完全一致またはパターン一致を使用する場合): 照合する値またはパターンを入力します。

         複数のヘッダー一致ルールを追加し、複雑なルーティングロジックを作成できます。設定されたルールに一致するリクエストは、テストのためにグリーンサービスリビジョンにルーティングされます。

      1. **[ヘッダールールの追加]** を選択し、追加のヘッダー一致条件を設定します。
**注記**  
テストトラフィックヘッダーのルールにより、完全なデプロイを完了する前に、制御されたトラフィックで新機能を検証できます。これにより、ブルーサービスリビジョンへの通常のトラフィックフローを維持しながら、特定のリクエスト (内部テストツールやベータユーザーなどによるもの) でグリーンサービスリビジョンをテストできます。

   1. （オプション) ログ設定を指定します。**[ログコレクションを使用]** を選択します。デフォルトのオプションでは、コンテナログを CloudWatch Logs に送信します。その他のログドライバオプションは、AWS FireLens を使用して構成されます。詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。

      以下では、各コンテナログの送信先について詳しく説明します。
      + **Amazon CloudWatch** — コンテナログを CloudWatch Logs に送信するようにタスクを設定します。デフォルトのログドライバーオプションが提供され、ユーザーに代わり CloudWatch ロググループを作成します。別のロググループ名を指定するには、ドライバーオプションの値を変更します。
      + **[Amazon Data Firehose]** — Firehose にコンテナログを送信するようタスクを設定します。Firehose 配信ストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別の配信ストリーム名を指定するには、ドライバーオプションの値を変更します。
      + **Amazon Kinesis Data Streams** — Kinesis Data Streams にコンテナログを送信するようタスクを設定します。Kinesis Data Streams のストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別のストリーム名を指定するには、ドライバーオプションの値を変更します。
      + **Amazon OpenSearch Service** — コンテナログを OpenSearch Service ドメインに送信するようタスクを設定します。ログドライバーオプションを提供する必要があります。
      + **Amazon S3** — Amazon S3 バケットにコンテナログを送信するようタスクを設定します。デフォルトのログドライバーオプションが提供されていますが、有効な Amazon S3 バケット名を指定する必要があります。

1. (オプション) カナリアデプロイ用に **[ロードバランシング]** を設定します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deploy-canary-service.html)

1. （オプション）サービスとタスクを識別しやすくするには、**[Tags]** (タグ) セクションを展開し、タグを設定します。

   新しく起動したすべてのタスクに対して、Amazon ECS がクラスター名とタスク定義タグで自動的にタグ付けするようにするには、**[Amazon ECS マネージドタグを有効にする]** を選択し、**[タグの伝播元]** で **[タスク定義]** を選択します。

   新しく起動したすべてのタスクに対して、Amazon ECS がクラスター名とサービスタグで自動的にタグ付けするようにするには、**[Amazon ECS マネージドタグを有効にする]** を選択し、**[タグの伝播元]** で **[サービス]** を選択します。

   タグを追加または削除します。
   + [タグを追加] **[Add tag]** (タグを追加) を選択し、以下を実行します。
     + [**キー**] にはキー名を入力します。
     + [**値**] にキー値を入力します。
   + [タグの削除] タグの横にある [**タグの削除**] を選択します。

1. **[作成]** を選択します。

------
#### [ AWS CLI ]

1. `canary-service-definition.json` という名前のファイルを作成し、次の内容を記述します。

   *user-input* を独自の値に置き換えます。

   ```
   {
     "serviceName": "myCanaryService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "CANARY",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "canaryConfiguration" : {
           "canaryPercent" : 5.0,
           "canaryBakeTime" : 10
       },
       "bakeTimeInMinutes": 10,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       }
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-canary-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. `create-service` を実行します。

   ```
   aws ecs create-service --cli-input-json file://canary-service-definition.json
   ```

------

## 次のステップ
<a name="deploy-canary-service-next-steps"></a>

カナリアデプロイを設定したら、以下の手順を実行します。
+ サービスを更新してデプロイを開始します。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。
+ デプロイプロセスをモニタリングし、Canary のパターンに従っていることを確認します。
  + グリーンサービスリビジョンが作成され、スケールアップされる
  + トラフィック (Canary) のごく一部がグリーンリビジョンに移行されます
  + システムは Canary に対して指定された間隔の時間待機します
  + 残りのトラフィックはすべて一度にグリーンリビジョンに移行されます
  + ベイク時間が過ぎたら、ブルーリビジョンが終了する

## デプロイに関する用語
<a name="deployment-terminology"></a>

Amazon ECS デプロイドキュメント全般で、以下の用語が使用されています。

ブルー/グリーンデプロイ  
既存の環境 (ブルー) とともに新しい環境 (グリーン) を作成し、検証後にトラフィックをブルーからグリーンに切り替えるデプロイ戦略。

Canary デプロイ  
トラフィックのごく一部を新しいバージョンにルーティングしながら、大部分のトラフィックを検証するために安定したバージョンに保持するデプロイ戦略。

リニアデプロイ  
時間の経過とともにトラフィックを古いバージョンから新しいバージョンに同じ割合ずつ段階的に移行するデプロイ戦略。

ローリングデプロイ  
古いバージョンのインスタンスを新しいバージョンのインスタンスに一度に 1 つずつ置き換えるデプロイ戦略。

タスクセット  
デプロイ中にサービス内で同じタスク定義を実行するタスクのコレクション。

ターゲットグループ  
デプロイ中にロードバランサーからトラフィックを受信するターゲットの論理グループ。

デプロイコントローラー  
Amazon ECS、CodeDeploy、外部コントローラーなど、サービスの新しいバージョンをデプロイするために使用される方法。

ロールバック  
デプロイ中に問題が検出されたときに、アプリケーションの以前のバージョンに戻すプロセス。

# サードパーティーのコントローラーを使用して Amazon ECS サービスをデプロイする
<a name="deployment-type-external"></a>

この*外部*デプロイタイプでは、Amazon ECS サービスのデプロイプロセスを完全に制御するために、すべてのサードパーティーのデプロイコントローラーを使用できます。サービスの詳細はサービス管理 API アクション (`CreateService`、`UpdateService`、`DeleteService`) または タスク設定管理 API アクション (`CreateTaskSet`、`UpdateTaskSet`、`UpdateServicePrimaryTaskSet`、`DeleteTaskSet`) のいずれかにより管理されます。各 API アクションは、サービス定義パラメータのサブセットを管理します。

`UpdateService` API アクションは、サービスの必要数およびヘルスチェック猶予期間パラメータを更新します。コンピューティングオプション、プラットフォームバージョン、ロードバランサーの詳細、ネットワーク構成、またはタスク定義を更新する必要がある場合、新しいタスクセットを作成する必要があります。

`UpdateTaskSet` API アクションは、タスクセットのスケールパラメータのみを更新します。

`UpdateServicePrimaryTaskSet` API アクションは、サービス内のどのタスクセットをプライマリタスクセットであるかを変更します。`DescribeServices` API アクションを呼び出すと、プライマリタスクセットに指定されたすべてのフィールドが返されます。サービスのプライマリタスクセットが更新されると、サービスの新しいプライマリタスクセットに存在し、古いプライマリタスクセットとは異なるタスクセットのパラメータ値はどれでも、新しいプライマリタスクセットが定義されるときに新しい値に更新されます。サービスにプライマリタスクセットが定義されていない場合にサービスを定義するとき、タスクセットフィールドは null になります。

## 外部デプロイに関する考慮事項
<a name="deployment-type-external-considerations"></a>

外部デプロイタイプを使用するときは、以下の点を考慮します。
+ サポートされているロードバランサーのタイプは、Application Load Balancer または Network Load Balancer です。
+ Fargate または `EXTERNAL` のデプロイコントローラータイプは、`DAEMON` スケジューリング戦略をサポートしません。
+ Application AutoScaling と Amazon ECS を統合した場合、Amazon ECS サービスのみをターゲットとしてサポートします。Amazon ECS でサポートされているスケーラブルなディメンションは `ecs:service:DesiredCount` であり、これは Amazon ECS サービスのタスク数です。Application AutoScaling および Amazon ECS タスクセットの間には直接的な統合はありません。Amazon ECS タスクセットにより、Amazon ECS サービスの `DesiredCount` に基づいて `ComputedDesiredCount` が計算されます。

## 外部デプロイワークフロー
<a name="deployment-type-external-workflow"></a>

以下に示しているのは、Amazon ECS で外部デプロイを管理する基本的なワークフローです。

**外部デプロイコントローラーを使用して Amazon ECS サービスを管理するには**

1. Amazon ECS サービスを作成する 必須のパラメータは、サービス名のみです。サービスを作成するときに、外部デプロイコントローラーを使用して以下のパラメータを指定できます。その他すべてのサービスパラメータは、サービス内でタスクセットが作成されるときに指定されます。  
`serviceName`  
タイプ: 文字列  
必須: はい  
サービスの名前。最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコアを使用できます。サービス名は同じクラスター内で一意になるようにしてください。ただし、リージョン内の複数のクラスター間や複数のリージョンにまたがるクラスター間では、同様の名前のサービスがあっても構いません。  
`desiredCount`  
指定したタスクセットのタスク定義のインスタンスをサービス内で実行状態に保つ数を設定します。  
`deploymentConfiguration`  
デプロイ時に実行されるタスクの数と、タスクの停止および開始の順序を制御するオプションのデプロイパラメータ。  
`tags`  
タイプ: オブジェクトの配列  
必須: いいえ  
サービスに適用し、サービスの分類と整理に役立つメタデータ。各タグはキーとオプションの値で構成され、どちらもお客様側が定義します。サービスが削除されると、タグも削除されます。サービスには最大 50 個のタグを適用できます。詳細については、「[Amazon ECS リソースにタグ付けする](ecs-using-tags.md)」を参照してください。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。    
`key`  
タイプ: 文字列  
長さの制限: 最小長は 1 です。最大長は 128 です。  
必須: いいえ  
タグを構成するキーと値のペアの一部。キーは、より具体的なタグ値のカテゴリのように動作する、一般的なラベルです。  
`value`  
タイプ: 文字列  
長さの制約: 最小長は 0 です。最大長は 256 です。  
必須: いいえ  
タグを構成するキーと値のペアのオプションの一部。値はタグカテゴリ (キー) の記述子として機能します。  
`enableECSManagedTags`  
サービス内のタスクに Amazon ECS マネージドタグを使用するか否かを指定します。詳細については、「[請求にタグを使用する](ecs-using-tags.md#tag-resources-for-billing)」を参照してください。  
`propagateTags`  
タイプ: 文字列  
有効な値: `TASK_DEFINITION` \$1 `SERVICE`  
必須: いいえ  
タグをタスク定義またはサービスからサービスのタスクへコピーするかどうかを指定します。値を指定しない場合、タグはコピーされません。タグは、サービス作成中のサービス内のタスクにのみコピーすることができます。タグをサービス作成後またはタスク作成後のタスクに追加するには、`TagResource` API アクションを使用します。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。  
`schedulingStrategy`  
使用するスケジュール戦略。外部デプロイコントローラーを使用するサービスは、`REPLICA` スケジューリング戦略のみをサポートします。  
`placementConstraints`  
サービスのタスクに使用する、配置制約オブジェクトの配列。タスクごとに最大 10 個の制約を指定できます (この制限数には、タスク定義内の制約と、実行時に指定される制約が含まれます)。Fargate を使用している場合、タスク配置の制約事項はサポートされません。  
`placementStrategy`  
サービスのタスクで使用する配置戦略オブジェクト。サービスごとに最大 4 つの戦略ルールを指定できます。

   次の例は、外部デプロイコントローラーを使用するサービスを作成するためのサービス定義です。

   ```
   {
       "cluster": "",
       "serviceName": "",
       "desiredCount": 0,
       "role": "",
       "deploymentConfiguration": {
           "maximumPercent": 0,
           "minimumHealthyPercent": 0
       },
       "placementConstraints": [
           {
               "type": "distinctInstance",
               "expression": ""
           }
       ],
       "placementStrategy": [
           {
               "type": "binpack",
               "field": ""
           }
       ],
       "schedulingStrategy": "REPLICA",
       "deploymentController": {
           "type": "EXTERNAL"
       },
       "tags": [
           {
               "key": "",
               "value": ""
           }
       ],
       "enableECSManagedTags": true,
       "propagateTags": "TASK_DEFINITION"
   }
   ```

1. 最初のタスクセットを作成します。タスクセットには、サービスに関する次の詳細が含まれています。  
`taskDefinition`  
使用するタスクセットのタスクのタスク定義。  
`launchType`  
タイプ: 文字列  
有効な値: `EC2` \$1 `FARGATE` \$1 `EXTERNAL`  
必須: いいえ  
サービスを実行する起動タイプ。起動タイプを指定しない場合は、デフォルトで `capacityProviderStrategy` が使用されます。  
サービスを更新すると、このパラメータは新しいサービスのデプロイをトリガーします。  
`launchType` を指定した場合、`capacityProviderStrategy` パラメータを省略する必要があります。  
`platformVersion`  
タイプ: 文字列  
必須: いいえ  
サービス内のタスクが実行されているプラットフォームのバージョン。プラットフォームのバージョンは、Fargate 起動タイプを使用するタスクに対してのみ指定されています。指定されない場合、デフォルトで最新バージョン (`LATEST`) が使用されます。  
サービスを更新すると、このパラメータは新しいサービスのデプロイをトリガーします。  
AWS Fargate プラットフォームのバージョンを使って、Fargate タスクインフラストラクチャの特定のランタイム環境を参照できます。プラットフォームのバージョンに `LATEST` を指定してタスクを実行またはサービスを作成すると、プラットフォームの最新バージョンをタスクで利用できるようになります。サービスをスケールアップする場合は、これらのタスクには、サービスの最新のデプロイで指定されたプラットフォームのバージョンが提供されます。詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。  
プラットフォームのバージョンは、EC2 起動タイプを使用するタスクには指定されません。  
`loadBalancers`  
サービスで使用するロードバランサーを表すロードバランサーオブジェクト。外部デプロイコントローラーを使用する場合、Application Load Balancer と Network Load Balancer のみがサポートされます。Application Load Balancer を使用している場合、タスクセットあたり 1 つの Application Load Balancer ターゲットグループのみが許可されます。  
次のスニペットは、使用する `loadBalancer` オブジェクトの例を示しています。  

   ```
   "loadBalancers": [
           {
               "targetGroupArn": "",
               "containerName": "",
               "containerPort": 0
           }
   ]
   ```
`loadBalancer` オブジェクトを指定する場合は、`targetGroupArn` を指定し、`loadBalancerName` パラメータを省略する必要があります。  
`networkConfiguration`  
サービスのネットワーク構成。このパラメータは `awsvpc` ネットワークモードを使用して独自の Elastic Network Interface を受け取るタスク定義の場合に必要です。その他のネットワークモードではサポートされていません。Fargate のネットワーク設定の詳細については、「[Fargate における Amazon ECS タスクのネットワークオプション](fargate-task-networking.md)」を参照してください。  
`serviceRegistries`  
このサービスに割り当てるサービス検出レジストリの詳細。詳細については、「[サービス検出を使用して Amazon ECS サービスを DNS 名で接続する](service-discovery.md)」を参照してください。  
`scale`  
タスクセットに配置して実行し続けるために必要なタスク数の浮動小数点パーセンテージ。この値は、サービスの `desiredCount` の割合 (%) の合計として指定されます。許容値は 0 から 100 までの数字です。

   外部デプロイコントローラー用のタスクセットを作成するための JSON の例を次に示します。

   ```
   {
       "service": "",
       "cluster": "",
       "externalId": "",
       "taskDefinition": "",
       "networkConfiguration": {
           "awsvpcConfiguration": {
               "subnets": [
                   ""
               ],
               "securityGroups": [
                   ""
               ],
               "assignPublicIp": "DISABLED"
           }
       },
       "loadBalancers": [
           {
               "targetGroupArn": "",
               "containerName": "",
               "containerPort": 0
           }
       ],
       "serviceRegistries": [
           {
               "registryArn": "",
               "port": 0,
               "containerName": "",
               "containerPort": 0
           }
       ],
       "launchType": "EC2",
       "capacityProviderStrategy": [
           {
               "capacityProvider": "",
               "weight": 0,
               "base": 0
           }
       ],
       "platformVersion": "",
       "scale": {
           "value": null,
           "unit": "PERCENT"
       },
       "clientToken": ""
   }
   ```

1. サービスの変更が必要な場合、更新するパラメータに応じて `UpdateService`、`UpdateTaskSet`、または `CreateTaskSet` のいずれかの API アクションを使用します。タスクセットを作成した場合は、サービスの各タスクセットに `scale` パラメータを使用して、サービス内で継続して実行するタスクの数を決定します。例えば、`tasksetA` を含むサービスがあり `tasksetB` を作成した場合、本番トラフィックを移行する前に `tasksetB` の有効性をテストする場合があります。両方のタスクの `scale` を `100` に設定し、すべての本番トラフィックを `tasksetB` に移行する準備が整ったときに、`tasksetA` の `scale` を `0` に更新して、スケールダウンすることもできます。

# Amazon ECS 用の CodeDeploy ブルー/グリーンデプロイ
<a name="deployment-type-bluegreen"></a>

Amazon ECS ブルー/グリーンデプロイを使用することをお勧めします。詳細については、「[Amazon ECS ブルー/グリーンデプロイの作成](deploy-blue-green-service.md)」を参照してください。

*ブルー/グリーンデプロイ*タイプでは、CodeDeploy によって制御される ブルー/グリーンデプロイモデルを使用します。このデプロイタイプは、本番稼働用トラフィックを送信する前にサービスの新しいデプロイを検証するために使用します。詳細については、「*AWS CodeDeploy ユーザーガイド*」の「[What Is CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)」を参照してください。デプロイ前に Amazon ECS サービスの状態を検証します。

ブルー/グリーンデプロイ中にトラフィックを移行するには、次の 3 つの方法があります。
+ **Canary** - トラフィックは 2 つの増分で移行されます。事前定義された複数の Canary オプションから選択し、最初の増分および間隔でトラフィックを更新済みタスクセットに移行する割合 (%) を分単位で指定できます。次に 2 回目の増分で残りのトラフィックを移行します。
+ **Linear** - トラフィックは等しい増分で移行され、増分間の間隔 (分) も同じです。事前定義された複数の線形オプションから選択し、増分ごとに移行するトラフィックの割合 (%) と増分間の間隔 (分) を指定できます。
+ **一括** - すべてのトラフィックを元のタスクセットから更新済みタスクセットに同時に移行します。

以下に示しているのは、サービスが Blue/Green デプロイタイプを使用するときに Amazon ECS が使用する CodeDeploy のコンポーネントです。

**CodeDeploy アプリケーション**  
CodeDeploy リソースのコレクションです。これは 1 つ以上のデプロイグループで構成されます。

**CodeDeploy デプロイグループ**  
デプロイ設定。これには以下の構成要素があります。  
+ Amazon ECS クラスターとサービス
+ ロードバランサーのターゲットグループとリスナー情報
+ デプロイメントロールバック戦略
+ トラフィックルーティング設定
+ 元のリビジョンの終了設定
+ デプロイ設定
+ デプロイメントを停止するために設定できる CloudWatch アラームの設定
+ 通知用の SNS または CloudWatch Eventsの設定
詳細については、*AWS CodeDeployユーザーガイド*の[「デプロイグループの操作」](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)を参照してください。

**CodeDeploy デプロイ構成**  
デプロイメント中に本番トラフィックを置換タスクに CodeDeploy がルーティングする方法を指定します。次の事前定義された線形および Canary デプロイ設定を使用できます。また、カスタム定義の線形および Canary デプロイを作成することもできます。詳細については、*AWS CodeDeploy ユーザーガイド*の「[デプロイ構成の操作](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)」を参照してください。  
+ [**CodeDeployDefault.ECSAllAtOnce**]: すべてのトラフィックを同時に更新済みの Amazon ECS コンテナに移行します。
+ **CodeDeployDefault.ECSLinear10PercentEvery1Minutes**: すべてのトラフィックがシフトされるまで、1 分ごとにトラフィックの 10 パーセントをシフトします。
+ **CodeDeployDefault.ECSLinear10PercentEvery3Minutes**: すべてのトラフィックがシフトされるまで、3 分ごとにトラフィックの 10 パーセントをシフトします。
+ **[CodeDeployDefault.ECSCanary10Percent5Minutes]**: 最初の増分で 10 パーセントのトラフィックをシフトします。残りの 90 パーセントは 5 分後にデプロイされます。
+ **[CodeDeployDefault.ECSCanary10percent15Minutes]**: 最初の増分で 10 パーセントのトラフィックをシフトします。残りの 90 パーセントは 15 分後にデプロイされます。

**リビジョン**  
リビジョンは、CodeDeploy アプリケーション仕様ファイル (AppSpec ファイル) です。AppSpec ファイルでは、タスク定義の完全な ARN と置換タスクセットのコンテナとポートを指定し、新しいデプロイが作成時にトラフィックがルーティングされるようにします。コンテナ名は、タスク定義内で参照されているコンテナ名のいずれかに設定する必要があります。ネットワーク設定またはプラットフォームのバージョンがサービス定義で更新された場合は、AppSpec ファイルでその詳細についても指定する必要があります。また、デプロイメントライフサイクルイベント中に実行する Lambda 関数も指定できます。Lambda 関数を使用することで、デプロイメント中にテストを実行し、メトリクスを返すことができます。詳細については、*AWS CodeDeployユーザーガイド*で[「AppSpec ファイルリファレンス」](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html)を参照してください。

## 考慮事項
<a name="deployment-type-bluegreen-considerations"></a>

ブルー/グリーンデプロイタイプを使用するときは、以下の点を考慮します。
+ Blue/Green デプロイタイプを使用して、Amazon ECS サービスが最初に作成されたとき、Amazon ECS タスクセットが作成されます。
+ Application Load Balancer または Network Load Balancer の使用にサービスを設定する必要があります。ロードバランサーの要件は以下のとおりです。
  + 本番稼働用リスナーをロードバランサーに追加する必要があります。これは本番トラフィックをルーティングするために使用されます。
  + オプションテストリスナーをロードバランサーに追加することができます。これはテストトラフィックをルーティングするために使用されます。テストリスナーを指定する場合、CodeDeploy はデプロイメント中にテストトラフィックを置換タスクセットにルーティングします。
  + 本番稼働用とテストリスナーの両方が同じロードバランサーに属している必要があります。
  + ロードバランサーに対してターゲットグループを定義する必要があります。ターゲットグループは本番稼働用リスナーを通じてトラフィックをサービスの元のタスクセットにルーティングします。
  + Network Load Balancer を使用する場合、`CodeDeployDefault.ECSAllAtOnce` デプロイメント構成のみがサポートされます。
+ サービスの自動スケーリングと ブルー/グリーンデプロイタイプを使用するように設定されたサービスでは、自動スケーリングはデプロイ中にブロックされませんが、状況によってはデプロイが失敗する場合があります。以下では、この動作について詳しく説明します。
  + サービスがスケーリング中の状態でデプロイが開始されると、グリーンタスクセットが作成され、CodeDeploy は Green タスクセットが定常状態になるまで最大 1 時間待機し、完了するまでトラフィックをシフトしません。
  + サービスが ブルー/グリーンデプロイのプロセス中で、スケーリングイベントが発生した場合、トラフィックは 5 分間シフトし続けます。サービスが 5 分以内に定常状態にならない場合、CodeDeploy はデプロイを停止し、失敗としてマークします。
+ Fargate または `CODE_DEPLOY` のデプロイコントローラータイプを使用するタスクは、`DAEMON` スケジューリング戦略をサポートしません。
+ 最初に CodeDeploy アプリケーションおよびデプロイグループを作成する際に、以下を指定する必要があります。
  + ロードバランサーに対して 2 つのターゲットグループを定義する必要があります。1 つのターゲットグループは、Amazon ECS サービスの作成時に、ロードバランサーに対して定義された最初のターゲットグループです。2 番目のターゲットグループの唯一の要件は、サービスが使用するものとは別のロードバランサーに関連付けることはできないということです。
+ Amazon ECS サービスに対して CodeDeploy デプロイを作成すると、CodeDeploy は*置換タスクセット* (または *Green タスクセット*) をデプロイで作成します。テストリスナーをロードバランサーに追加した場合、CodeDeploy はテストトラフィックを置換タスクセットにルーティングします。この時点で検証テストを実行できます。次に、CodeDeploy は本番稼働用トラフィックを元のタスクセットから置換タスクセットに再ルーティングします。このときデプロイグループへのトラフィックの再ルーティング設定に従います。

## 必要な IAM 許可
<a name="deployment-type-bluegreen-IAM"></a>

ブルー/グリーンデプロイは、Amazon ECS と CodeDeploy API の組み合わせによって実現されています。ユーザーは、Amazon ECS ブルー/グリーンデプロイを使用するためには、これらのサービスに対する適切なアクセス権限が必要です。AWS マネジメントコンソールまたは AWS CLI または SDK を使用します。

サービスの作成や更新に使用するデフォルトの IAM アクセス権限に加えて、Amazon ECS には次のアクセス権限が必要です。`AmazonECS_FullAccess` IAM ポリシーには、次の許可が追加されています。詳細については、「[AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess)」を参照してください。
+ `codedeploy:CreateApplication`
+ `codedeploy:CreateDeployment`
+ `codedeploy:CreateDeploymentGroup`
+ `codedeploy:GetApplication`
+ `codedeploy:GetDeployment`
+ `codedeploy:GetDeploymentGroup`
+ `codedeploy:ListApplications`
+ `codedeploy:ListDeploymentGroups`
+ `codedeploy:ListDeployments`
+ `codedeploy:StopDeployment`
+ `codedeploy:GetDeploymentTarget`
+ `codedeploy:ListDeploymentTargets`
+ `codedeploy:GetDeploymentConfig`
+ `codedeploy:GetApplicationRevision`
+ `codedeploy:RegisterApplicationRevision`
+ `codedeploy:BatchGetApplicationRevisions`
+ `codedeploy:BatchGetDeploymentGroups`
+ `codedeploy:BatchGetDeployments`
+ `codedeploy:BatchGetApplications`
+ `codedeploy:ListApplicationRevisions`
+ `codedeploy:ListDeploymentConfigs`
+ `codedeploy:ContinueDeployment`
+ `sns:ListTopics`
+ `cloudwatch:DescribeAlarms`
+ `lambda:ListFunctions`

**注記**  
タスクおよびサービスを実行するために必要な標準の Amazon ECS アクセス権限を付与するだけでなく、ユーザーにはタスクの IAM ロールを使用する `iam:PassRole` アクセス権限も必要です。

CodeDeploy には、Amazon ECS API の呼び出し、Elastic Load Balancing の変更、Lambda 関数の起動、CloudWatch アラームの記述のアクセス権限が必要です。また、ユーザーの代わりにサービスの必要数を変更するためのアクセス許可も必要です。Blue/Green デプロイタイプを使用する Amazon ECS サービスを作成する前に、IAM ロール (`ecsCodeDeployRole`) を作成する必要があります。詳細については、「[Amazon ECS CodeDeploy IAM ロール](codedeploy_IAM_role.md)」を参照してください。

# CodeDeploy ブルー/グリーンデプロイを Amazon ECS ブルー/グリーンデプロイに移行
<a name="migrate-codedeploy-to-ecs-bluegreen"></a>

CodeDeploy ブルー/グリーンデプロイと Amazon ECS ブルー/グリーンデプロイの機能は類似していますが、設定および管理方法が異なります。

## CodeDeploy ブルー/グリーンデプロイの概要
<a name="codedeploy-bluegreen-overview"></a>

CodeDeploy を使用して Amazon ECS サービスを作成すると、以下を実行できます。

1. 本番リスナーおよび (必要に応じて) テストリスナーを使用してロードバランサーを作成します。各リスナーは、すべてのトラフィックを単一のターゲットグループ (プライマリターゲットグループ) にルーティングする 1 つの (デフォルト) ルールで設定されます。

1. `deploymentController` タイプが `CODE_DEPLOY` に設定された状態で、リスナーおよびターゲットグループを使用するように設定された Amazon ECS サービスを作成します。サービスを作成すると、指定されたターゲットグループに登録された (ブルー) タスクセットが作成されます。

1. CodeDeploy のデプロイグループ (CodeDeploy アプリケーションの一部として) を作成し、デプロイ動作を制御する Amazon ECS クラスター、サービス名、ロードバランサーリスナー、2 つのターゲットグループ (本番のリスナールールで使用されるプライマリターゲットグループ、ならびに代替タスクに使用されるセカンダリターゲットグループ)、サービスロール (Amazon ECS および Elastic Load Balancing リソースを操作するアクセス許可を CodeDeploy に付与するため)、およびさまざまなパラメータの詳細を使って設定します。

CodeDeploy を使用すると、`CreateDeployment()` を使用してサービスの新しいバージョンがデプロイされ、CodeDeploy のアプリケーション名、デプロイグループ名、新しいリビジョンおよびオプションのライフサイクルフックの詳細を提供する AppSpec ファイルが指定されます。CodeDeploy デプロイでは代替 (緑) タスクセットが作成され、タスクがセカンダリターゲットグループに登録されます。正常になると、テスト (オプション) および本番で利用できます。どちらの場合も、グリーンタスクセットに関連付けられたセカンダリターゲットグループを指すようにリスナールールを変更することで、再ルーティングが実現します。ロールバックは、本番のリスナールールをプライマリターゲットグループに戻すことで実現します。

## Amazon ECS ブルー/グリーンデプロイの概要
<a name="ecs-bluegreen-overview"></a>

Amazon ECS ブルー/グリーンデプロイを使用すると、デプロイ設定が Amazon ECS サービス自体の一部になります。

1. 重みが 1 および 0 で構成される 2 つのターゲットグループを含むルールで、ロードバランサーの本番リスナーを事前設定する必要があります。

1. 次のリソースを指定するか、サービスリソースを更新する必要があります。
   + このリスナールールの ARN 
   + 2 つのターゲットグループ
   + Elastic Load Balancing API を呼び出すアクセス許可を Amazon ECS に付与する IAM ロール
   + Lambda 関数を実行する IAM ロール (オプション)
   + `deploymentController` タイプを `ECS` に設定し、`deploymentConfiguration.strategy` を `BLUE_GREEN` に設定します。タスクがプライマリターゲットグループに登録されている (ブルー) サービスデプロイが作成されます。

Amazon ECS ブルー/グリーンを使用すると、Amazon ECS `UpdateService()` を呼び出すことで新しいサービスリビジョンが作成され、新しいリビジョンの詳細が渡されます。サービスデプロイによって新しい (グリーン) サービスリビジョンタスクが作成され、セカンダリターゲットグループに登録されます。Amazon ECS はリスナールールの重みを切り替えることで、再ルーティングおよびロールバックオペレーションを処理します。

## 主要な実装上の相違点
<a name="implementation-differences"></a>

どちらのアプローチによってもタスクの初期セットが作成されますが、基盤となる実装は異なります。
+ CodeDeploy ではタスクセットが使用されますが、Amazon ECS ではサービスリビジョンが使用されます。Amazon ECS のタスクセットは、Amazon ECS サービスリビジョンおよびデプロイに置き換えられた古いコンストラクトです。後者はデプロイプロセス、サービスデプロイ、サービスリビジョン履歴をさらに詳細に可視化します。
+ CodeDeploy を使用すると、ライフサイクルフックは `CreateDeployment()` に提供される AppSpec ファイルの一部として指定されます。つまり、フックは 1 つのデプロイから次のデプロイに変更できます。Amazon ECS ブルー/グリーンを使用すると、フックはサービス設定の一部として指定され、更新には `UpdateService()` の呼び出しが必要になります。
+ CodeDeploy および Amazon ECS ブルー/グリーンは両方ともフック実装に Lambda を使用しますが、予想される入力および出力は異なります。

  CodeDeploy を使用すると、関数は `PutLifecycleEventHookExecutionStatus()` を呼び出してフックステータスを返す必要があり、フックステータスは `SUCCEEDED` または `FAILED` になります。Amazon ECS を使用すると、Lambda レスポンスが使用されてフックステータスが示されます。
+ CodeDeploy は各フックを 1 回限りの呼び出しとして呼び出し、最終的な実行ステータスは通常 1 時間以内に返されます。Amazon ECS フックは、`IN_PROGRESS` インジケータを返すことができるという点でより柔軟です。このインジケータにより、フックが `SUCCEEDED` または `FAILED` になるまで繰り返し呼び出される必要があることが示されます。詳細については、「[Amazon ECS サービスデプロイのライフサイクルフック](deployment-lifecycle-hooks.md)」を参照してください。

## 移行アプローチ
<a name="migration-paths"></a>

CodeDeploy ブルー/グリーンデプロイから Amazon ECS ブルー/グリーンデプロイに移行するアプローチには主に 3 つあります。各アプローチには、複雑さ、リスク、ロールバック機能、潜在的なダウンタイムの点で特性が異なります。

### CodeDeploy に使用される Elastic Load Balancing リソースと同じものを再利用します
<a name="inplace-update"></a>

CodeDeploy デプロイコントローラーの代わりに、ブルー/グリーンデプロイ戦略で Amazon ECS デプロイコントローラーを使用するように、既存の Amazon ECS サービスを更新します。このアプローチを使用する場合は、次の点を考慮してください。
+ 既存の Amazon ECS サービスデプロイコントローラーおよびデプロイ戦略を更新するため、移行手順がよりシンプルになります。
+ 正しく設定および移行されている場合、ダウンタイムはありません。
+ ロールバックには、サービスリビジョンを元に戻す必要があります。
+ ブルー/グリーン設定が並行していないため、リスクが高くなります。

CodeDeploy に使用されるロードバランサーリスナーおよびターゲットグループと同じものを使用します。CloudFormation を使用している場合は、「[CloudFormation CodeDeploy ブルー/グリーンデプロイのテンプレートを Amazon ECS ブルー/グリーン CloudFormation テンプレートへの移行](migrate-codedeploy-to-ecs-bluegreen-cloudformation-template.md)」を参照してください。

1. 本番/テストのリスナーのデフォルトルールを変更して代替ターゲットグループを含め、プライマリターゲットグループの重みを 1 に設定し、代替ターゲットグループの重みを 0 に設定します。

   CodeDeploy の場合、サービスにアタッチされたロードバランサーのリスナーは、すべてのトラフィックを単一のターゲットグループにルーティングする、1 つの (デフォルト) ルールで設定されます。Amazon ECS ブルー/グリーンの場合、ロードバランサーリスナーは重みを持つ 2 つのターゲットグループが含まれるルールで事前設定する必要があります。プライマリターゲットグループは 1 に重み付けされ、代替ターゲットグループは 0 に重み付けされる必要があります。

1. `UpdateService` API を呼び出して `deploymentController` パラメータを `ECS` に設定し、`deploymentStrategy` パラメータを `BLUE_GREEN` に設定することで、既存の Amazon ECS サービスを更新します。ターゲットグループの ARN、代替ターゲットグループ、本番リスナー、オプションのテストリスナーを指定します。

1. サービスが期待どおりに動作することを確認します。

1. 現在は Amazon ECS ブルー/グリーンを使用しているため、この Amazon ECS サービスの CodeDeploy 設定を削除します。

### 既存のロードバランサーを含む新しいサービス
<a name="new-service-existing-lb"></a>

このアプローチでは、移行にブルー/グリーン戦略を使用します。

このアプローチを使用する場合は、次の点を考慮してください。
+ 中断は最小限に抑えられます。Elastic Load Balancing のポートスワップ中にのみ発生します。
+ ロールバックには、Elastic Load Balancing のポートスワップを元に戻す必要があります。
+ 並列設定があるため、リスクが低くなります。したがって、トラフィックが移行する前にテストできます。

1. 必要に応じてこの設定に簡単にロールバックできるように、CodeDeploy 設定のリスナー、ターゲットグループ、Amazon ECS サービスはそのままにします。

1. 既存のロードバランサーの下で、新しいターゲットグループおよび新しいリスナー (元のリスナーとは異なるポートを所有) を作成します。次に、既存の Amazon ECS サービスに一致する新しい Amazon ECS サービスを作成しますが、`ECS` をデプロイコントローラー、`BLUE_GREEN` をデプロイ戦略として使用し、新しいターゲットグループおよび新しいリスナールールの ARN を渡します。

1. サービスに HTTP トラフィックを手動で送信し、新しい設定を確認します。問題がなければ、元のリスナーと新しいリスナーのポートをスワップし、トラフィックを新しい設定にルーティングします。

1. 新しい設定を確認します。依然として期待どおりにすべてが動作する場合は、CodeDeploy 設定を削除します。

### 新しいロードバランサーを持った新しいサービス
<a name="new-service-new-lb"></a>

前のアプローチと同様に、このアプローチでは移行にブルー/グリーン戦略を使用します。主な違いは、CodeDeploy 設定から Amazon ECS ブルー/グリーンの設定への切り替えが、ロードバランサーの上にあるリバースプロキシレイヤーで行われることです。リバースプロキシレイヤーのサンプル実装は、Route 53 および CloudFront です。

このアプローチはこのリバースプロキシレイヤーを既に持っているお客様に適しており、サービスとのすべての通信がこのリバースプロキシレイヤーを通じて行われている場合にも適しています (例えば、ロードバランサーレベルで直接通信がない場合など)。

このアプローチを使用する場合は、次の点を考慮してください。
+ リバースプロキシレイヤーが必要です。
+ 既存の Amazon ECS サービスデプロイコントローラーおよびデプロイ戦略を更新する必要があるため、移行手順がより複雑になります。
+ 中断は最小限に抑えられます。Elastic Load Balancing のポートスワップ中にのみ発生します。
+ ロールバックには、プロキシ設定の変更を元に戻す必要があります。
+ 並列設定があるため、リスクが低くなります。したがって、トラフィックが移行する前にテストできます。

1. 既存の CodeDeploy 設定を変更しないでください (ロードバランサー、リスナー、ターゲットグループ、Amazon ECS サービス、CodeDeploy デプロイグループ)。

1. Amazon ECS ブルー/グリーンデプロイ用に設定された新しいロードバランサー、ターゲットグループ、リスナーを作成します。

   適切なリソースを設定します。
   + Application Load Balancer – 詳細については、「[ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Application Load Balancer リソース](alb-resources-for-blue-green.md)」を参照してください。
   + Network Load Balancer – 詳細については、「[Amazon ECS ブルー/グリーン、リニアおよびカナリアデプロイの Network Load Balancer リソース](nlb-resources-for-blue-green.md)」を参照してください。

1. `ECS` および `BLUE_GREEN` をそれぞれデプロイコントローラーおよびデプロイ戦略とし、新しいロードバランサーリソースを指す新しいサービスを作成します。

1. 新しいロードバランサーを通じてテストすることで、新しいセットアップを確認します。

1. リバースプロキシ設定を更新し、トラフィックを新しいロードバランサーにルーティングします。

1. 新しいサービスリビジョンに従って、期待どおりにすべてが動作し続けた場合、CodeDeploy 設定を削除します。

## 次のステップ
<a name="post-migration-considerations"></a>

Amazon ECS ブルー/グリーンデプロイに移行した後
+ CodeDeploy `UpdateService` API の代わりに、Amazon ECS `CreateDeployment` API を使用するように、デプロイスクリプトと CI/CD パイプラインを更新します。
+ CodeDeploy デプロイの代わりに、Amazon ECS サービスのデプロイを追跡するように、モニタリングおよびアラートを更新します。
+ 期待どおりに機能することを確認するため、新しいデプロイプロセスの自動テストを実装することを検討してください。

# CodeDeploy ブルー/グリーンから Amazon ECS ブルー/グリーンサービスデプロイへの移行
<a name="migrate-code-deploy-to-ecs-blue-green"></a>

 Amazon ECS ブルー/グリーンデプロイを使用すると、本番環境に実装する前にサービスを変更してテストできます。

Amazon ECS ブルー/グリーンデプロイ用に新しいライフサイクルフックを作成する必要があります。

## 前提条件
<a name="migrate-code-deploy-to-ecs-blue-green-prerequisites"></a>

ブルー/グリーンデプロイを開始する前に、次の操作を実行します。

1. Amazon ECS CodeDeploy IAM ロールを次のアクセス許可に置き換えてください。
   + Elastic Load Balancing のアクセス許可の詳細については、「[ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)」を参照してください。
   + Lambda のアクセス許可の詳細については、「[Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可](blue-green-permissions.md)」を参照してください。

1. CodeDeploy オートメーションをオフにします。詳細については、「*CodeDeploy ユーザーガイド*」の「[Working with deployment groups in CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)」を参照してください。

1. CodeDeploy ブルー/グリーンデプロイに次の情報があることを確認してください。この情報は Amazon ECS ブルー/グリーンデプロイに再利用できます。
   + 本番ターゲットグループ
   + 本番リスナー
   + 本番ルール
   + テストターゲットグループ

     これはグリーンサービスリビジョンのターゲットグループです。

1. Application Load Balancer ターゲットグループがリスナールールに適切に関連付けられていることを確認してください。
   + テストリスナーを使用していない場合、両方のターゲットグループ (本番およびテスト) を本番のリスナールールに関連付ける必要があります。
   + テストリスナーを使用している場合、1 つのターゲットグループを本番のリスナールールにリンクし、もう 1 つのターゲットグループをテストのリスナールールにリンクする必要があります。

   この要件が満たされない場合、サービスのデプロイは失敗し、次のエラーが表示されます。`Service deployment rolled back because of invalid networking configuration. Both targetGroup and alternateTargetGroup must be associated with the productionListenerRule or testListenerRule.`

1. サービスに継続中のサービスデプロイがないことを確認します。詳細については、「[Amazon ECS サービスデプロイを使用してサービス履歴を表示する](service-deployment.md)」を参照してください。

1. Amazon ECS ブルー/グリーンデプロイでは、サービスが次のいずれかの機能を使用する必要があります。適切なリソースを設定してください。
   + Application Load Balancer – 詳細については、「[ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Application Load Balancer リソース](alb-resources-for-blue-green.md)」を参照してください。
   + Network Load Balancer – 詳細については、「[Amazon ECS ブルー/グリーン、リニアおよびカナリアデプロイの Network Load Balancer リソース](nlb-resources-for-blue-green.md)」を参照してください。
   + Service Connect – 詳細については、「[Amazon ECS ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Service Connect リソース](service-connect-blue-green.md)」を参照してください。

1. Amazon ECS ブルー/グリーンデプロイのステージのライフサイクルステージに Lambda 関数を実行するかどうかを決定します。
   + スケールアップ前
   + スケールアップ後
   + テストトラフィックの移行
   + テストトラフィックの移行後
   + 本番トラフィックの移行
   + 本番トラフィックの移行後

   ライフサイクルステージごとに Lambda 関数を作成します。詳細については、「*AWS Lambda デベロッパーガイド*」の「[コンソールで Lambda 関数の作成](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function)」を参照してください。

サービスのデプロイコントローラーの更新の詳細については、「[Amazon ECS サービスのパラメータの更新](update-service-parameters.md)」を参照してください。

## 手順
<a name="migrate-code-deploy-to-ecs-procedure"></a>

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

   クラスター詳細のページが表示されます。

1. **[サービス]** タブでサービスを選択します。

   [サービスの詳細] ページが表示されます。

1. バナーで **[デプロイコントローラータイプの更新]** を選択します。

   **[デプロイコントローラータイプの移行]** ページが表示されます。

1. **[新規]** を展開し、次のパラメータを指定します。

   1. **[デプロイコントローラータイプ]** では **[ECS]** を選択します。

   1. **[デプロイ戦略]** では、**[ブルー/グリーン]** を選択します。

   1. **[ベイク時間]** には、ブルーおよびグリーンのサービスリビジョンの両方が実行される時間を入力します。

   1. ライフサイクルステージに Lambda 関数を実行するには、**[デプロイライフサイクルフック]** で一意の Lambda 関数ごとに次の操作を行います。

      1. **[Add]** (追加) を選択します。

         実行する一意の関数ごとにこの操作を繰り返します。

      1. **[Lambda 関数]** には、関数名を入力します。

      1. **[ロール]** には、ブルー/グリーンのアクセス許可を持つ前提条件で作成したロールを選択します。

         詳細については、「[Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可](blue-green-permissions.md)」を参照してください。

      1. **[ライフサイクルステージ]** には、Lambda 関数が実行されるステージを選択します。

      1.  (オプション) **[フックの詳細]** には、フックに関する情報を提供するキーおよび値のペアを入力します。

1. **[ロードバランシング]** を展開し、次の内容を設定します。

   1. **[ロール]** には、ブルー/グリーンのアクセス許可を持つ前提条件で作成したロールを選択します。

      詳細については、「[Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可](blue-green-permissions.md)」を参照してください。

   1. **[リスナー]** には、CodeDeploy ブルー/グリーンデプロイから本番リスナーを選択します。

   1. **[本番ルール]** には、CodeDeploy ブルー/グリーンデプロイから本番ルールを選択します。

   1. **[テストルール]** には、CodeDeploy ブルー/グリーンデプロイからテストルールを選択します。

   1. **[ターゲットグループ]** には、CodeDeploy ブルー/グリーンデプロイから本番ターゲットグループを選択します。

   1. **[代替ターゲットグループ]** には、CodeDeploy ブルー/グリーンデプロイからテストターゲットグループを選択します。

1. **[更新]** を選択します。

## 次のステップ
<a name="migrate-code-deploy-to-ecs-blue-green-next-steps"></a>
+ サービスを更新してデプロイを開始します。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。
+ デプロイプロセスをモニタリングし、ブルー/グリーンのパターンに従っていることを確認します。
  + グリーンサービスリビジョンが作成され、スケールアップされる
  + テストトラフィックがグリーンリビジョンにルーティングされている (設定されている場合)
  + 本番トラフィックがグリーンリビジョンに移行されている
  + ベイク時間が過ぎたら、ブルーリビジョンが終了する

# CloudFormation CodeDeploy ブルー/グリーンデプロイのテンプレートを Amazon ECS ブルー/グリーン CloudFormation テンプレートへの移行
<a name="migrate-codedeploy-to-ecs-bluegreen-cloudformation-template"></a>

Amazon ECS サービスの CodeDeploy ブルー/グリーンデプロイを使用する CloudFormation テンプレートを、ネイティブの Amazon ECS ブルー/グリーンデプロイ戦略を使用するテンプレートに移行します。移行は、「CodeDeploy に使用した Elastic Load Balancing リソースと同じものを再利用する」アプローチに従います。詳細については、「[CodeDeploy ブルー/グリーンデプロイを Amazon ECS ブルー/グリーンデプロイに移行](migrate-codedeploy-to-ecs-bluegreen.md)」を参照してください。

## ソーステンプレート
<a name="source-template"></a>

このテンプレートは `AWS::CodeDeployBlueGreen` 変換および `AWS::CodeDeploy::BlueGreen` フックを使用し、Amazon ECS サービスにブルー/グリーンデプロイを実装します。

### ソース
<a name="code-deploy-source"></a>

これは CodeDeploy ブルー/グリーンデプロイを使用する完全な CloudFormation テンプレートです。詳細については、「*AWS CloudFormation ユーザーガイド*」の「[ブルー/グリーンデプロイテンプレートの例](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green-template-example.html#blue-green-template-example.json)」を参照してください。

```
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "Vpc": {
      "Type": "AWS::EC2::VPC::Id"
    },
    "Subnet1": {
      "Type": "AWS::EC2::Subnet::Id"
    },
    "Subnet2": {
      "Type": "AWS::EC2::Subnet::Id"
    }
  },
  "Transform": [
    "AWS::CodeDeployBlueGreen"
  ],
  "Hooks": {
    "CodeDeployBlueGreenHook": {
      "Type": "AWS::CodeDeploy::BlueGreen",
      "Properties": {
        "TrafficRoutingConfig": {
          "Type": "TimeBasedCanary",
          "TimeBasedCanary": {
            "StepPercentage": 15,
            "BakeTimeMins": 5
          }
        },
        "Applications": [
          {
            "Target": {
              "Type": "AWS::ECS::Service",
              "LogicalID": "ECSDemoService"
            },
            "ECSAttributes": {
              "TaskDefinitions": [
                "BlueTaskDefinition",
                "GreenTaskDefinition"
              ],
              "TaskSets": [
                "BlueTaskSet",
                "GreenTaskSet"
              ],
              "TrafficRouting": {
                "ProdTrafficRoute": {
                  "Type": "AWS::ElasticLoadBalancingV2::Listener",
                  "LogicalID": "ALBListenerProdTraffic"
                },
                "TargetGroups": [
                  "ALBTargetGroupBlue",
                  "ALBTargetGroupGreen"
                ]
              }
            }
          }
        ]
      }
    }
  },
  "Resources": {
    "ExampleSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "Security group for ec2 access",
        "VpcId": {"Ref": "Vpc"},
        "SecurityGroupIngress": [
          {
            "IpProtocol": "tcp",
            "FromPort": 80,
            "ToPort": 80,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 8080,
            "ToPort": 8080,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "CidrIp": "0.0.0.0/0"
          }
        ]
      }
    },
    "ALBTargetGroupBlue": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ALBTargetGroupGreen": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ExampleALB": {
      "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
      "Properties": {
        "Scheme": "internet-facing",
        "SecurityGroups": [
          {"Ref": "ExampleSecurityGroup"}
        ],
        "Subnets": [
          {"Ref": "Subnet1"},
          {"Ref": "Subnet2"}
        ],
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "Type": "application",
        "IpAddressType": "ipv4"
      }
    },
    "ALBListenerProdTraffic": {
      "Type": "AWS::ElasticLoadBalancingV2::Listener",
      "Properties": {
        "DefaultActions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                }
              ]
            }
          }
        ],
        "LoadBalancerArn": {"Ref": "ExampleALB"},
        "Port": 80,
        "Protocol": "HTTP"
      }
    },
    "ALBListenerProdRule": {
      "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
      "Properties": {
        "Actions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                }
              ]
            }
          }
        ],
        "Conditions": [
          {
            "Field": "http-header",
            "HttpHeaderConfig": {
              "HttpHeaderName": "User-Agent",
              "Values": [
                "Mozilla"
              ]
            }
          }
        ],
        "ListenerArn": {"Ref": "ALBListenerProdTraffic"},
        "Priority": 1
      }
    },
    "ECSTaskExecutionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
        ]
      }
    },
    "BlueTaskDefinition": {
      "Type": "AWS::ECS::TaskDefinition",
      "Properties": {
        "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]},
        "ContainerDefinitions": [
          {
            "Name": "DemoApp",
            "Image": "nginxdemos/hello:latest",
            "Essential": true,
            "PortMappings": [
              {
                "HostPort": 80,
                "Protocol": "tcp",
                "ContainerPort": 80
              }
            ]
          }
        ],
        "RequiresCompatibilities": [
          "FARGATE"
        ],
        "NetworkMode": "awsvpc",
        "Cpu": "256",
        "Memory": "512",
        "Family": "ecs-demo"
      }
    },
    "ECSDemoCluster": {
      "Type": "AWS::ECS::Cluster",
      "Properties": {}
    },
    "ECSDemoService": {
      "Type": "AWS::ECS::Service",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "DesiredCount": 1,
        "DeploymentController": {
          "Type": "EXTERNAL"
        }
      }
    },
    "BlueTaskSet": {
      "Type": "AWS::ECS::TaskSet",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "LaunchType": "FARGATE",
        "NetworkConfiguration": {
          "AwsVpcConfiguration": {
            "AssignPublicIp": "ENABLED",
            "SecurityGroups": [
              {"Ref": "ExampleSecurityGroup"}
            ],
            "Subnets": [
              {"Ref": "Subnet1"},
              {"Ref": "Subnet2"}
            ]
          }
        },
        "PlatformVersion": "1.4.0",
        "Scale": {
          "Unit": "PERCENT",
          "Value": 100
        },
        "Service": {"Ref": "ECSDemoService"},
        "TaskDefinition": {"Ref": "BlueTaskDefinition"},
        "LoadBalancers": [
          {
            "ContainerName": "DemoApp",
            "ContainerPort": 80,
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}
          }
        ]
      }
    },
    "PrimaryTaskSet": {
      "Type": "AWS::ECS::PrimaryTaskSet",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "Service": {"Ref": "ECSDemoService"},
        "TaskSetId": {"Fn::GetAtt": ["BlueTaskSet", "Id"]}
      }
    }
  }
}
```

## 移行手順
<a name="migration-steps"></a>

### CodeDeploy 固有のリソースを削除する
<a name="remove-codedeploy-resources"></a>

次のプロパティが不要になりました。
+ `AWS::CodeDeployBlueGreen` 変換
+ `CodeDeployBlueGreenHook` フック
+ `GreenTaskDefinition` および `GreenTaskSet` リソース (Amazon ECS によって管理される)
+ `PrimaryTaskSet` リソース (Amazon ECS によって内部でタスクセットが管理される)

### ロードバランサーリスナーを再設定する
<a name="reconfigure-load-balancer"></a>

`ALBListenerProdTraffic` リソースを変更して、2 つのターゲットグループを持つ転送アクションを使用します。

```
{
  "DefaultActions": [
    {
      "Type": "forward",
      "ForwardConfig": {
        "TargetGroups": [
          {
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
            "Weight": 1
          },
          {
            "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
            "Weight": 0
          }
        ]
      }
    }
  ]
}
```

### デプロイプロパティを更新します
<a name="update-ecs-service"></a>

次の内容を更新して追加します。
+ `DeploymentController` プロパティを `EXTERNAL` から `ECS` に更新します。
+ `Strategy` プロパティを追加して、BLUE\$1GREEN に設定します。
+ `BakeTimeInMinutes` プロパティを追加します。

  ```
  {
    "DeploymentConfiguration": {
      "MaximumPercent": 200,
      "MinimumHealthyPercent": 100,
      "DeploymentCircuitBreaker": {
        "Enable": true,
        "Rollback": true
      },
      "BakeTimeInMinutes": 5,
      "Strategy": "BLUE_GREEN"
    }
  }
  ```
+ ロードバランサー設定をサービスに追加します。

  ```
  {
    "LoadBalancers": [
      {
        "ContainerName": "DemoApp",
        "ContainerPort": 80,
        "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
        "AdvancedConfiguration": {
          "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
          "ProductionListenerRule": {"Ref": "ALBListenerProdRule"},
          "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]}
        }
      }
    ]
  }
  ```
+ サービスにタスク定義リファレンスを追加します。

  ```
  {
    "TaskDefinition": {"Ref": "BlueTaskDefinition"}
  }
  ```

### AmazonECSInfrastructureRolePolicyForLoadBalancers ロールを作成します
<a name="create-ecs-service-role"></a>

Amazon ECS にロードバランサーリソースの管理を可能にする新しい IAM ロールを追加します。詳細については、[ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)を参照してください。

## レコメンデーションのテスト
<a name="testing-recommendations"></a>

1. 移行したテンプレートを非本番環境にデプロイします。

1. サービスが初期設定で正しくデプロイされることを確認してください。

1. タスク定義を更新してブルー/グリーンデプロイプロセスを観察することで、デプロイをテストします。

1. ブルーおよびグリーンのデプロイの間でトラフィックが正しく移行されることを確認してください。

1. デプロイの失敗を強制し、ロールバック機能をテストします。

## 移行後のテンプレート
<a name="migrated-template"></a>

### 最終テンプレート
<a name="ecs-bluegreen-template"></a>

これは、Amazon ECS ブルー/グリーンデプロイを使用する完全な CloudFormation テンプレートです。

```
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "Vpc": {
      "Type": "AWS::EC2::VPC::Id"
    },
    "Subnet1": {
      "Type": "AWS::EC2::Subnet::Id"
    },
    "Subnet2": {
      "Type": "AWS::EC2::Subnet::Id"
    }
  },
  "Resources": {
    "ExampleSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "Security group for ec2 access",
        "VpcId": {"Ref": "Vpc"},
        "SecurityGroupIngress": [
          {
            "IpProtocol": "tcp",
            "FromPort": 80,
            "ToPort": 80,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 8080,
            "ToPort": 8080,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "CidrIp": "0.0.0.0/0"
          }
        ]
      }
    },
    "ALBTargetGroupBlue": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ALBTargetGroupGreen": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ExampleALB": {
      "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
      "Properties": {
        "Scheme": "internet-facing",
        "SecurityGroups": [
          {"Ref": "ExampleSecurityGroup"}
        ],
        "Subnets": [
          {"Ref": "Subnet1"},
          {"Ref": "Subnet2"}
        ],
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "Type": "application",
        "IpAddressType": "ipv4"
      }
    },
    "ALBListenerProdTraffic": {
      "Type": "AWS::ElasticLoadBalancingV2::Listener",
      "Properties": {
        "DefaultActions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                },
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
                  "Weight": 0
                }
              ]
            }
          }
        ],
        "LoadBalancerArn": {"Ref": "ExampleALB"},
        "Port": 80,
        "Protocol": "HTTP"
      }
    },
    "ALBListenerProdRule": {
      "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
      "Properties": {
        "Actions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                },
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
                  "Weight": 0
                }
              ]
            }
          }
        ],
        "Conditions": [
          {
            "Field": "http-header",
            "HttpHeaderConfig": {
              "HttpHeaderName": "User-Agent",
              "Values": [
                "Mozilla"
              ]
            }
          }
        ],
        "ListenerArn": {"Ref": "ALBListenerProdTraffic"},
        "Priority": 1
      }
    },
    "ECSTaskExecutionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
        ]
      }
    },
    "ECSInfrastructureRoleForLoadBalancers": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "AllowAccessToECSForInfrastructureManagement",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/AmazonECSInfrastructureRolePolicyForLoadBalancers"
        ]
      }
    },
    "BlueTaskDefinition": {
      "Type": "AWS::ECS::TaskDefinition",
      "Properties": {
        "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]},
        "ContainerDefinitions": [
          {
            "Name": "DemoApp",
            "Image": "nginxdemos/hello:latest",
            "Essential": true,
            "PortMappings": [
              {
                "HostPort": 80,
                "Protocol": "tcp",
                "ContainerPort": 80
              }
            ]
          }
        ],
        "RequiresCompatibilities": [
          "FARGATE"
        ],
        "NetworkMode": "awsvpc",
        "Cpu": "256",
        "Memory": "512",
        "Family": "ecs-demo"
      }
    },
    "ECSDemoCluster": {
      "Type": "AWS::ECS::Cluster",
      "Properties": {}
    },
    "ECSDemoService": {
      "Type": "AWS::ECS::Service",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "DesiredCount": 1,
        "DeploymentController": {
          "Type": "ECS"
        },
        "DeploymentConfiguration": {
          "MaximumPercent": 200,
          "MinimumHealthyPercent": 100,
          "DeploymentCircuitBreaker": {
            "Enable": true,
            "Rollback": true
          },
          "BakeTimeInMinutes": 5,
          "Strategy": "BLUE_GREEN"
        },
        "NetworkConfiguration": {
          "AwsvpcConfiguration": {
            "AssignPublicIp": "ENABLED",
            "SecurityGroups": [
              {"Ref": "ExampleSecurityGroup"}
            ],
            "Subnets": [
              {"Ref": "Subnet1"},
              {"Ref": "Subnet2"}
            ]
          }
        },
        "LaunchType": "FARGATE",
        "PlatformVersion": "1.4.0",
        "TaskDefinition": {"Ref": "BlueTaskDefinition"},
        "LoadBalancers": [
          {
            "ContainerName": "DemoApp",
            "ContainerPort": 80,
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
            "AdvancedConfiguration": {
              "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
              "ProductionListenerRule": {"Ref": "ALBListenerProdRule"},
              "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]}
            }
          }
        ]
      }
    }
  }
}
```

# CodeDeploy ブルー/グリーンから Amazon ECS ローリング更新サービスのデプロイへの移行
<a name="migrate-code-deploy-to-ecs-rolling"></a>

 サービスデプロイを CodeDeploy ブルー/グリーンデプロイから Amazon ECS ローリング更新デプロイに移行できます。CodeDeploy の依存関係から統合デプロイの使用に移行します。

Amazon ECS サービススケジューラは、現在実行中のタスクを新しいタスクに置き換えます。ローリング更新中にサービスに対して Amazon ECS が追加または削除するタスク数は、サービスデプロイ設定により制御されます。

## 前提条件
<a name="migrate-code-deploy-to-ecs-rolling-prerequisites"></a>

ブルー/グリーンデプロイを開始する前に、次の操作を実行します。

1. Amazon ECS CodeDeploy IAM ロールが不要になりました。

1. CodeDeploy オートメーションをオフにします。詳細については、「*CodeDeploy ユーザーガイド*」の「[Working with deployment groups in CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)」を参照してください。

1. サービスに継続中のサービスデプロイがないことを確認します。詳細については、「[Amazon ECS サービスデプロイを使用してサービス履歴を表示する](service-deployment.md)」を参照してください。

サービスのデプロイコントローラーの更新の詳細については、「[Amazon ECS サービスのパラメータの更新](update-service-parameters.md)」を参照してください。

## 手順
<a name="migrate-code-deploy-to-ecs-rolling-procedure"></a>

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

   クラスター詳細のページが表示されます。

1. **[サービス]** タブでサービスを選択します。

   [サービスの詳細] ページが表示されます。

1. バナーで **[移行]** を選択します。

   **[デプロイ設定の更新]** ページが表示されます。

1. **[デプロイオプション]** を展開し、次のパラメータを指定します。

   1. **[デプロイコントローラータイプ]** では **[ECS]** を選択します。

   1. **[デプロイ戦略]** には、**[ローリング更新]** を選択します。

   1. **[Min running tasks]** (実行中のタスクの最小化) の場合、デプロイ時に `RUNNING` の状態に保つ必要のあるサービス内のタスクの下限数をタスクの必要数のパーセント値 (最も近い整数に切り上げ) で入力します。詳細については、[[Deployment configuration]](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration) (デプロイ設定) を参照してください。

   1. **[Max running tasks]** (実行中のタスクの最大化)) には、デプロイ時に `RUNNING` または `PENDING` 状態にできるサービスのタスクの上限数を必要数のタスクのパーセント値 (最も近い整数に切り下げ) で入力します。

1. **[ロードバランシング]** を展開し、次の内容で設定します。

   1. **[ロール]** には、ブルー/グリーンのアクセス許可を持つ前提条件で作成したロールを選択します。

      詳細については、「[Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可](blue-green-permissions.md)」を参照してください。

   1. **[リスナー]** には、CodeDeploy ブルー/グリーンデプロイから本番リスナーを選択します。

   1. **[ターゲットグループ]** には、CodeDeploy ブルー/グリーンデプロイから本番ターゲットグループを選択します。

1. **[更新]** を選択します。

## 次のステップ
<a name="migrate-code-deploy-to-ecs-rolling-next-steps"></a>

変更を有効にするには、サービスを更新する必要があります。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。

# Amazon ECS デプロイ戦略を更新します
<a name="migrate-deployment-strategies"></a>

Amazon ECS は、サービスを更新するために複数のデプロイ戦略をサポートします。アプリケーションの要件に基づいて、これらの戦略の間で移行できます。このトピックでは、ローリングデプロイおよびブルー/グリーンデプロイの間で移行する方法について説明します。

## Amazon ECS デプロイ戦略の概要
<a name="deployment-strategies-overview"></a>

デプロイ戦略の間で移行する前に、各戦略の仕組みおよび主な違いを理解することが重要です。

**ローリングデプロイ**  
ローリングデプロイでは、Amazon ECS は現在実行中のアプリケーションのバージョンを新しいバージョンに置き換えます。サービススケジューラは最小および最大の正常率パラメータを使用し、デプロイ戦略を判断します。  
ローリングデプロイはセットアップがより簡単ですが、デプロイプロセスおよびトラフィックルーティングの制御性は低下します。

**Blue/Green デプロイ**  
ブルー/グリーンデプロイでは、既存のバージョン (ブルー) とともに、Amazon ECS はサービスの新しいバージョン (グリーン) を作成します。新しいバージョンに本番トラフィックをルーティングする前に、検証できるようになります。  
ブルー/グリーンデプロイでは、デプロイプロセスを詳細に制御できます (トラフィックの移行、テスト、ロールバック機能など)。

## ベストプラクティス
<a name="migration-best-practices"></a>

デプロイ戦略の間で移行する際、次のベストプラクティスに従ってください。
+ **非本番環境でテスト**: 本番サービスに変更を適用する前に、常に非本番環境で更新をテストしてください。
+ **ロールバックの計画**: 更新が期待どおりに機能しない場合に備えて、ロールバック計画を立てます。
+ **移行中のモニタリング**: 移行中および移行後にサービスを注意深くモニタリングし、正しく動作し続けることを確認します。
+ **ドキュメントの更新**: デプロイドキュメントを更新して、新しいデプロイ戦略を反映します。
+ **トラフィックへの影響の考慮**: 更新がサービスへのトラフィックに与える影響を理解し、影響内容に応じて計画します。

# ローリング更新から Amazon ECS ブルー/グリーンへのデプロイ戦略の更新
<a name="update-rolling-to-bluegreen"></a>

本番環境で実装する前にサービスを変更してテストする際、ローリング更新デプロイから Amazon ECS ブルー/グリーンデプロイに移行できます。

## 前提条件
<a name="update-rolling-to-bluegreen-prerequisites"></a>

サービスをローリングデプロイからブルー/グリーンデプロイに移行する前に、次の内容があることを確認してください。
+  現在のデプロイがすべて完了するまで待ちます。
+ ローリングデプロイ戦略を使用する既存の Amazon ECS サービス。
+ トラフィックを処理する複数のサービスリビジョンがある場合、Amazon ECS は移行中にトラフィックを 1 つのリビジョンに統合しようとします。これが失敗した場合、移行前に 1 つのリビジョンを使用するように、手動でサービスの更新が必要な場合があります。
+ 適切なアクセス許可を設定します。
  + Elastic Load Balancing のアクセス許可の詳細については、「[ロードバランサー用の Amazon ECS インフラストラクチャの IAM ロール](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)」を参照してください。
  + Lambda のアクセス許可の詳細については、「[Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可](blue-green-permissions.md)」を参照してください。
+ 設定内容に応じて、次のいずれかを実行する必要があります。
  + サービスが Elastic Load Balancing を使用している場合、サービスを新しい「advancedConfiguration」で更新してローリングデプロイを開始します。
  + サービスが Service Connect を使用している場合、サービスを更新してローリングデプロイを開始します。
  + サービスが Elastic Load Balancing および Service Connect の両方を使用している場合、上記の両方のステップを実行します (1 つの UpdateService リクエストを使用できます)。
  + サービスが上記のいずれかを使用していない場合、追加のオペレーションは不要です。
+ Amazon ECS ブルー/グリーンデプロイでは、サービスが次のいずれかの機能を使用することが必須です。適切なリソースを設定します。
  + Application Load Balancer – 詳細については、「[ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Application Load Balancer リソース](alb-resources-for-blue-green.md)」を参照してください。
  + Network Load Balancer – 詳細については、「[Amazon ECS ブルー/グリーン、リニアおよびカナリアデプロイの Network Load Balancer リソース](nlb-resources-for-blue-green.md)」を参照してください。
  + Service Connect – 詳細については、「[Amazon ECS ブルー/グリーンデプロイ、リニアデプロイおよびカナリアデプロイ用の Service Connect リソース](service-connect-blue-green.md)」を参照してください。

## 手順
<a name="update-rolling-to-bluegreen-procedure"></a>

1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2) で Amazon ECS コンソールを開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[クラスター]** ページで、移行するサービスを含むクラスターを選択します。

   クラスター詳細のページが表示されます。

1. **[クラスターの詳細]** ページで、**[サービス]** タブを選択します。

1. サービスを選択したら、**[更新]** を選択します。

   更新のサービスページが表示されます

1. **[デプロイオプション]** を展開し、次の操作を行います。

1. **[デプロイ戦略]** では、**[ブルー/グリーン]** を選択します。

1. ブルー/グリーンデプロイ設定を構成します。

   1. **ベイク時間**には、ブルーリビジョンが終了する前に、ブルーおよびグリーンのサービスリビジョンの両方が同時に実行される分数を入力します。

      これにより、検証およびテストの時間を確保できます。

   1. (オプション) デプロイの特定段階で実行されるように、Lambda 関数を設定します。**[デプロイライフサイクルフック]** で、次のステージのために Lambda 関数を設定します。
      + **スケールアップ前**: グリーンサービスリビジョンをスケールアップする前に実行されます
      + **スケールアップ後**: グリーンサービスリビジョンをスケールアップした後に実行されます
      + **テストトラフィックの移行**: グリーンサービスリビジョンへのテストトラフィックのルーティング中に実行されます
      + **テストトラフィック後の移行**: テストトラフィックがグリーンサービスリビジョンにルーティングされた後に実行されます
      + **本番トラフィックの移行**: グリーンサービスリビジョンへの本番トラフィックルーティング中に実行されます
      + **本番トラフィック後の移行**: 本番トラフィックがグリーンサービスリビジョンにルーティングされた後に実行されます

      ライフサイクルフックを追加する方法

      1. **[Add]** (追加) を選択します。

      1. **[Lambda 関数]** には、ARN の関数名を入力します。

      1. **[ロール]** には、Lambda 関数を呼び出すアクセス許可を持つ IAM ロールを選択します。

      1. **[ライフサイクルステージ]** では、Lambda 関数を実行するステージを選択します。

      1. オプション: **[フックの詳細]** には、キーおよび値のペアを入力してフックに追加情報を提示します。

1. ロードバランサーを設定します。

   1. **[ロードバランシング]** で、サービスがロードバランサーを使用するように設定されていることを確認します。

   1. **[ターゲットグループ]** では、本番 (青) 環境のプライマリターゲットグループを選択します。

   1. **[代替ターゲットグループ]** では、テスト (緑) 環境のターゲットグループを選択します。

   1. **本番のリスナールール**では、本番トラフィックをルーティングするリスナールールを選択します。

   1. オプション: **[テストのリスナールール]**では、テストトラフィックをグリーン環境にルーティングするリスナールールを選択します。

   1. **[ロール]** では、Amazon ECS にロードバランサーの管理を可能にする IAM ロールを選択します。

1. 変更内容を確認し、**[更新]** を選択します。

## 次のステップ
<a name="update-rolling-to-bluegreen-next-steps"></a>
+ サービスを更新してデプロイを開始します。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。
+ デプロイプロセスをモニタリングし、ブルー/グリーンのパターンに従っていることを確認します。
  + グリーンサービスリビジョンが作成され、スケールアップされる
  + テストトラフィックがグリーンリビジョンにルーティングされている (設定されている場合)
  + 本番トラフィックがグリーンリビジョンに移行されている
  + ベイク時間が過ぎたら、ブルーリビジョンが終了する

# デプロイ戦略を Amazon ECS ブルー/グリーンからローリング更新への更新
<a name="update-bluegreen-to-rolling"></a>

ブルー/グリーンデプロイをローリング更新デプロイに移行できます。

ローリングデプロイに移行する際には、次の点を考慮してください。
+ **トラフィック処理**: ローリングデプロイを使用すると、新しいタスクがヘルスチェックに合格したら、すぐにトラフィックの受信が開始されます。ブルー/グリーンデプロイと同様に、個別のテストフェーズはありません。
+ **リソース効率**: 通常、ローリングデプロイはブルー/グリーンデプロイよりも少ないリソースを使用します。これは、ローリングデプロイは完全に重複する環境を作成するのではなく、タスクを段階的に置き換えるからです。
+ **ロールバックの複雑さ**: ローリングデプロイでは、ブルー/グリーンデプロイと比較してロールバックが複雑になります。ロールバックする必要がある場合、前のタスク定義で新しいデプロイを開始する必要があります。
+ **デプロイの速度**: 特にタスクが多いサービスの場合、ローリングデプロイはブルー/グリーンデプロイよりも完了に時間がかかることがあります。
+ **ロードバランサー設定**: 既存のロードバランサー設定はローリングデプロイでも引き続き機能しますが、トラフィックの移行動作は異なります。

## 前提条件
<a name="update-bluegreen-to-rolling-prerequisites"></a>

ブルー/グリーンからローリングデプロイにサービスを移行する前に、以下があることを確認してください。
+ ブルー/グリーンデプロイ戦略を使用する既存の Amazon ECS サービス
+ 継続中のサービスのデプロイがないこと (現在のデプロイが完了するまで待つ)
+ ローリングデプロイでサービスが動作する方法を明確に理解する

**注記**  
デプロイが進行中の場合、サービスをローリングデプロイに移行することはできません。続行する前に、現在のデプロイが完了するまで待ちます。

## 移行手順
<a name="update-bluegreen-to-rolling-procedure"></a>

Amazon ECS サービスをブルー/グリーンからローリングデプロイに移行するには、次の手順に従います。

1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2) で Amazon ECS コンソールを開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. **[クラスター]** ページで、移行するサービスを含むクラスターを選択します。

1. **[クラスターの詳細]** ページで、**[サービス]** タブを選択します。

1. 移行するサービスを選択したら、**[更新]** を選択します。

1. **[サービスの更新]** ページで、**[デプロイオプション]** セクションに移動し、必要に応じて展開します。

1. **[デプロイ戦略]** には、**[ローリング更新]** を選択します。

1. ローリングデプロイ設定を構成します。

   1. **[最小正常率]** には、デプロイ中に `RUNNING` 状態を維持する必要があるタスクの最小パーセント値を入力します。この値は、サービスに望ましいタスク数に対するパーセンテージとして指定されます。

   1. **[最大パーセント]** には、デプロイ中に `RUNNING` または `PENDING` の状態で許可されるタスクの最大パーセント値を入力します。この値は、サービスに望ましいタスク数に対するパーセンテージとして指定されます。

1. オプション: **[デプロイ失敗の検出]** で、Amazon ECS がデプロイ失敗を検出して処理する方法を設定します。

   1. 展開サーキットブレーカーを有効にするには、**[展開サーキットブレーカー]** を選択します。

   1. 失敗したデプロイを自動的にロールバックするには、**[失敗時にロールバック]** を選択します。

1. 設定の変更を確認したら、**[更新]** を選択して変更を保存し、サービスをローリングデプロイに移行します。

Amazon ECS はサービス設定を更新し、ローリングデプロイ戦略を使用します。次回サービスを更新すると、ローリングデプロイプロセスが使用されます。

**注記**  
ブルー/グリーンからローリングデプロイに移行すると、Amazon ECS は次の方法で移行を処理します。  
トラフィックを処理している現在のアクティブなサービスリビジョンを特定します。
既存のロードバランサー設定を維持しながら、新しいデプロイを処理する方法を変更します。
将来のローリングデプロイに備えてサービスを準備します。

## 次のステップ
<a name="update-bluegreen-to-rolling-next-steps"></a>
+ サービスを更新してデプロイを開始します。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。

# Amazon ECS デプロイ戦略の更新に関するトラブルシューティング
<a name="troubleshooting-deployment-controller-migration"></a>

このセクションでは、デプロイ戦略の移行時に発生する可能性のあるよくある問題に対する解決策を紹介します。

## 複数のサービスリビジョンまたはタスクセット
<a name="troubleshooting-multiple-task-sets"></a>

次の問題は、デプロイに複数のサービスリビジョンを持つことに関連しています。

ECS デプロイコントローラーを更新するときに複数のタスクセットがある  
*エラーメッセージ*: `Updating the deployment controller is not supported when there are multiple tasksets in the service. Please ensure your service has only one taskset and try again.`  
*解決策*: このエラーは、複数のアクティブなタスクセットを持つサービスのデプロイコントローラータイプを変更しようとすると発生します。`CODE_DEPLOY` または `EXTERNAL` デプロイコントローラーでこの問題を解決する方法:  

1. 現在のタスクセットを確認します。

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets"
   ```

1. 進行中のデプロイが完了するまで待ちます。

1. 新しいデプロイがタスクセットをクリーンアップするように強制します。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --force-new-deployment
   ```

1. 必要に応じて、他のタスクセットを手動で削除します。

   ```
   aws ecs delete-task-set --cluster your-cluster-name --service your-service-name --task-set task-set-id
   ```

1. 残るタスクセットが 1 つだけになったら、デプロイコントローラーの更新を再試行してください。
詳細については、「[Amazon ECS サービスデプロイコントローラーと戦略](ecs_service-options.md)」を参照してください。

`ECS` デプロイコントローラーの更新時にプライマリタスクセットが不足している  
*エラーメッセージ*: `Updating the deployment controller requires a primary taskset in the service. Please ensure your service has a primary taskset and try again.`  
*解決策*: このエラーは、プライマリタスクが設定されていないサービスのデプロイコントローラータイプを変更しようとすると発生します。この問題を解決するには。  

1. サービスのステータスとタスクセットを確認します。)。サービスにタスクセットが存在する場は、`ACTIVE` とマークする必要があります。

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets[*].[status,id]
   ```

   `ACTIVE` 状態のタスクセットがない場合、デプロイを移行します。詳細については、「[移行の方法](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/migrate-codedeploy-to-ecs-bluegreen.html#migration-paths)」を参照してください。

1. サービスに実行中のタスクがない場合、サービスを更新して少なくとも 1 つのタスクをデプロイしてください。

   ```
   aws ecs update-service-primary-task-set --cluster your-cluster-name --service your-service-name --primary-task-set your-taskset-id
   ```

   サービス内の (以前は `ACTIVE`) タスクセットが `PRIMARY` ステータスとしてマークされます。

1. タスクが安定した実行状態になるまで待ちます。ステータスは次の方法で確認できます。

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deployments"
   ```

1. 実行中のタスクがサービスのプライマリタスクに設定されたら、デプロイコントローラーの更新を再試行してください。
詳細については、「[Amazon ECS サービスデプロイコントローラーと戦略](ecs_service-options.md)」を参照してください。

## デプロイ障害の検出タイプおよびデプロイコントローラーの不一致
<a name="troubleshooting-failure-detection"></a>

次の問題は、デプロイ障害の検出タイプおよびデプロイコントローラーの不一致に関連しています。

非 ECS コントローラーを持ったデプロイサーキットブレーカー  
*エラーメッセージ*: `Deployment circuit breaker feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.`  
*解決策*: このエラーは、`ECS` デプロイコントローラーを使用していないサービスに対して、デプロイサーキットブレーカー機能を有効にしようとすると発生します。デプロイサーキットブレーカーは、`ECS` デプロイコントローラーとのみ互換性があります。  

1. サービスの現在のデプロイコントローラーを確認してください。

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. `ECS` デプロイコントローラーを使用するように、サービスを更新します。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. サービスが `ECS` デプロイコントローラーを使用したら、デプロイサーキットブレーカーを有効にします。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}"
   ```
詳細については、「[Amazon ECS デプロイサーキットブレーカーが障害を検出する方法](deployment-circuit-breaker.md)」を参照してください。

非 ECS コントローラーのアラームベースのロールバック  
*エラーメッセージ*: `Alarm based rollback feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.`  
*解決策*: このエラーは、`ECS` デプロイコントローラーを使用していないサービスでアラームベースのロールバックを設定しようとすると発生します。アラームベースのロールバック機能は、`ECS` デプロイコントローラーとのみ互換性があります。  

1. サービスの現在のデプロイコントローラーを確認してください。

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. `ECS` デプロイコントローラーを使用するように、サービスを更新します。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. サービスが `ECS` デプロイコントローラーを使用したら、アラームベースのロールバックを設定してください。

   ```
   aws ecs update-service --cluster your-cluster-name --services your-service-name --deployment-configuration "alarms={alarmNames=[your-alarm-name],enable=true,rollback=true}"
   ```
詳細については、「[CloudWatch アラームが Amazon ECS のデプロイ障害を検出する方法](deployment-alarm-failure.md)」を参照してください。

## Service Connect およびデプロイコントローラーの不一致
<a name="troubleshooting-service-connect-mismatch"></a>

次の問題は、Service Connect およびデプロイコントローラーの不一致に関連しています。

Service Connect を使用した `EXTERNAL` コントローラー  
*エラーメッセージ*: `The EXTERNAL deployment controller type is not supported for services using Service Connect.`  
*解決策*: このエラーは、Service Connect が有効になっているサービスで `EXTERNAL` デプロイコントローラーを使用しようとすると発生します。`EXTERNAL` コントローラーは Service Connect と互換性がありません。  

1. サービスで Service Connect が有効になっているかどうかを確認してください。

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].serviceConnectConfiguration"
   ```

1. `EXTERNAL` デプロイコントローラーを使用する必要がある場合、サービスを更新して Service Connect を無効にします。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "{}"
   ```

1. または、Service Connect を使用する必要がある場合は、代わりに `ECS` デプロイコントローラーを使用します。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
詳細については、「[Amazon ECS サービスデプロイコントローラーと戦略](ecs_service-options.md)」を参照してください。

非 ECS コントローラーを使用した Service Connect  
*エラーメッセージ*: `Service Connect feature is only supported with ECS (rolling update) deployment controller. Update to ECS deployment controller and try again.`  
*解決策*: このエラーは、`ECS` デプロイコントローラーを使用していない Service Connect を有効にしようとすると発生します。Service Connect 機能は、`ECS` デプロイコントローラーとのみ互換性があります。  

1. サービスの現在のデプロイコントローラーを確認してください。

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. ECS デプロイコントローラーを使用するように、サービスを更新してください。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. サービスが ECS デプロイコントローラーを使用したら、Service Connect を有効にしてください。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "enabled=true,namespace=your-namespace"
   ```
詳細については、「[Amazon ECS サービスデプロイコントローラーと戦略](ecs_service-options.md)」を参照してください。

## コントローラータイプおよびスケジューリング戦略の不一致
<a name="troubleshooting-controller-type-scheduling"></a>

次の問題は、コントローラータイプおよびスケジューリング戦略の不一致に関連しています。

`DAEMON` スケジューリング戦略を使用する `CODE_DEPLOY` コントローラー  
*エラーメッセージ*: `The CODE_DEPLOY deployment controller type is not supported for services using the DAEMON scheduling strategy.`  
*解決策*: このエラーは、`DAEMON` スケジューリング戦略を使用するサービスで CODE\$1DEPLOY デプロイコントローラーを使用しようとすると発生します。`CODE_DEPLOY` コントローラーは、`REPLICA` スケジューリング戦略とのみ互換性があります。  

1. サービスの現在のスケジューリング戦略を確認してください。

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy"
   ```

1. ブルー/グリーンデプロイが必要な場合、`REPLICA` スケジューリング戦略を使用するようにサービスを変更します。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA
   ```

1. または、`DAEMON` スケジューリング戦略を使用する必要がある場合は、代わりに `ECS` デプロイコントローラーを使用します。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
詳細については、「[Amazon ECS サービスデプロイコントローラーと戦略](ecs_service-options.md)」を参照してください。

デーモンスケジューリング戦略を使用した EXTERNAL コントローラー  
*エラーメッセージ*: `The EXTERNAL deployment controller type is not supported for services using the DAEMON scheduling strategy.`  
*解決策*: このエラーは、デーモンスケジュール戦略を使用する ECS サービスで EXTERNAL デプロイコントローラーを使用しようとすると発生します。EXTERNAL コントローラーは、REPLICA スケジューリング戦略とのみ互換性があります。  

1. サービスの現在のスケジューリング戦略を確認してください。

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy"
   ```

1. `EXTERNAL` デプロイコントローラーを使用する必要がある場合は、`REPLICA` スケジューリング戦略を使用するようにサービスを変更します。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA
   ```

1. または、`DAEMON` スケジューリング戦略を使用する必要がある場合は、代わりに `ECS` デプロイコントローラーを使用します。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
詳細については、「[Amazon ECS サービスデプロイコントローラーと戦略](ecs_service-options.md)」を参照してください。

外部起動タイプを使用したサービスレジストリ  
*エラーメッセージ*: `Service registries are not supported for external launch type.`  
*解決策*: このエラーは、`EXTERNAL` 起動タイプを使用するサービスにサービス検出 (サービスレジストリ) を設定しようとすると発生します。サービス検出は、`EXTERNAL` 起動タイプと互換性がありません。  

1. サービスの現在の起動タイプを確認してください。

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].launchType"
   ```

1. サービス検出が必要な場合は、`EC2` または `FARGATE` の起動タイプのいずれかを使用するようにサービスを変更します。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --launch-type FARGATE
   ```

1. または、`EXTERNAL` 起動タイプを使用する必要がある場合は、サービスレジストリ設定を削除します。

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-registries "[]"
   ```
詳細については、「[Amazon ECS サービスデプロイコントローラーと戦略](ecs_service-options.md)」を参照してください。

## デプロイコントローラーの更新を元に戻します
<a name="troubleshooting-revert"></a>

前のデプロイコントローラーに戻す場合、次のいずれかを実行できます。
+ CloudFormation を使用した場合、前のテンプレートを使用して新しいスタックを作成できます。詳細については、「*CloudFormation ユーザーガイド*」の「[スタック作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。
+ Amazon ECS コンソールまたは AWS CLI を使用した場合、サービスを更新できます。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。

  update-service コマンドを使用する場合、`--deployment-controller` オプションを使用して前のデプロイコントローラーに設定します。

# Amazon ECS サービスデプロイを使用してサービス履歴を表示する
<a name="service-deployment"></a>

サービスデプロイは、デプロイの包括的なビューを提供します。サービスデプロイでは、サービスに関する次の情報が提供されます。
+ 現在デプロイされているワークロード設定 (ソースサービスリビジョン)
+ デプロイ中のワークロード設定 (ターゲットサービスリビジョン)
+ デプロイステータス
+ サーキットブレークが検出された失敗したタスク数
+ アラーム状態になっている CloudWatch アラーム
+ サービスデプロイが開始および完了した日時
+ ロールバックの詳細 (発生した場合)

サービスデプロイプロパティの詳細については、「[Amazon ECS サービスデプロイに含まれるプロパティ](service-deployment-property.md)」を参照してください。

サービスデプロイは読み取り専用で、それぞれに一意の ID があります。

サービスデプロイには 3 つのステージがあります。


| ステージ | 定義 | 関連付けられた状態 | 
| --- | --- | --- | 
| 保留中 | サービスデプロイが作成されたが、開始されていない | 保留中 | 
| 継続的 | サービスデプロイが進行中 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-deployment.html)  | 
| 完了  | サービスデプロイが完了 (成功または失敗) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-deployment.html)  | 

サービスのライフサイクルを理解し、実行が必要なアクションがあるかどうかを判断するため、サービスデプロイを使用します。例えば、ロールバックが発生した場合は、サービスデプロイを調査し、サービスイベントを確認する必要がある場合があります。

コンソール、API、および AWS CLI を使用して、2024 年 10 月 25 日以降に作成されたデプロイの最新の 90 日間の履歴を表示できます。

完了していないデプロイを停止できます。詳細については、「[Amazon ECS サービスデプロイの停止](stop-service-deployment.md)」を参照してください。

## サービスデプロイのライフサイクル
<a name="service-deployments-lifecycle"></a>

Amazon ECS は、次のいずれかのアクションが発生すると、新しいサービスデプロイを自動的に作成します。
+ ユーザーがサービスを作成した。
+ ユーザーがサービスを更新し、[新しいデプロイの強制] オプションを使用した。
+ ユーザーが、デプロイを必要とする 1 つ以上のサービスプロパティを更新した。

Amazon ECS は、デプロイの実行時にサービスデプロイの進行状況を反映するために次のサービスデプロイプロパティを更新します。
+ ステータス
+ 実行中のタスク数

  サービスリビジョンに示されている実行中のタスク数が、実際に実行されているタスク数と等しくない場合があります。この数は、デプロイが完了したときに実行されているタスク数を表します。例えば、サービスデプロイとは関係なくタスクを起動した場合、それらのタスクはサービスリビジョンの実行タスク数に含まれません。
+ サーキットブレーカーの障害検出:
  + 開始に失敗したタスク数
+ CloudWatch アラームの障害検出
  + アクティブなアラーム
+ ロールバック情報:
  + 開始時刻
  + ロールバックの理由
  + ロールバックに使用されるサービスリビジョンの ARN
+ ステータスの理由

サービスを削除すると、Amazon ECS はサービスデプロイを削除します。

## サービスデプロイの状態
<a name="service-deployments-states"></a>

サービスデプロイは `PENDING` 状態で開始されます。

次の図は、`PENDING` 状態の後に発生する可能性のあるサービスデプロイの状態を示します: `IN_PROGRESS`、`ROLLBACK_REQUESTED`、`SUCCESSFUL`、`STOP_REQUESTED`、`ROLLBACK_IN_PROGRESSS`、`ROLLBACK_FAILED`、`ROLLBACK_SUCCESSFUL`、`STOPPED`。

![\[IN_PROGRESS 状態の後に発生する可能性のあるサービスデプロイ STOP_REQUESTED、SUCCESSFUL、および ROLLBACK_IN_PROGRESS 状態。\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/service-deployment-states.png)


以下の情報は、サービスデプロイの状態に関する詳細を提供します。
+ `PENDING` - サービスデプロイは作成されましたが、開始されていません。

  状態は、そこから `IN_PROGRESS`、`ROLLBACK_REQUESTED`、`STOP_REQUESTED`、`STOPPED` のいずれかに移行します。
+ `IN_PROGRESS` - サービスデプロイが進行中です。

  状態は、そこから `SUCCESSFUL`、`STOP_REQUESTED`、`ROLLBACK_REQUESTED`、`ROLLBACK_IN_PROGRESS`、`STOPPED` のいずれかに移行します。
+ `STOP_REQUESTED` - 次のいずれかが発生すると、サービスデプロイの状態は `STOP_REQUESTED` に移行します。
  + ユーザーが新しいサービスデプロイを開始した。
  + ロールバックオプションが障害検出メカニズム (サーキットブレーカーまたはアラームベース) に使用されていないため、サービスが `SUCCESSFUL` 状態に達しない。

  状態は `STOPPED` に移行します。
+  `ROLLBACK_REQUESTED` – ユーザーがコンソール、API、または CLI を介してロールバックをリクエストすると、サービスのデプロイ状態は `ROLLBACK_REQUESTED` に移行します。

  状態は、そこから `SUCCESSFUL`、`ROLLBACK_IN_PROGRESS`、`STOPPED` のいずれかに移行します。
+ `SUCCESSFUL` - サービスデプロイが正常に完了すると、サービスデプロイの状態は `SUCCESSFUL` に移行します。
+  `ROLLBACK_IN_PROGRESS` - ロールバックオプションが障害検出メカニズム (サーキットブレーカーまたはアラームベース) に使用されていて、サービスが失敗すると、サービスデプロイの状態は `ROLLBACK_IN_PROGRESS` に移行します。

   状態は `ROLLBACK_SUCCESSFUL` または `ROLLBACK_FAILED` に移行します。

# Amazon ECS サービスデプロイに含まれるプロパティ
<a name="service-deployment-property"></a>

サービスデプロイには、次のプロパティが含まれます。


| プロパティ | 説明 | 
| --- | --- | 
|  サービスデプロイ ARN  |  サービスデプロイの ARN。  | 
| サービス ARN |  このサービスデプロイのサービスの ARN。  | 
|  クラスター ARN  |  サービスをホストするクラスターの ARN。  | 
| サービスデプロイの作成時刻 | サービスデプロイが作成された時刻。 | 
| サービスデプロイの開始時刻 | サービスデプロイが開始された時刻。 | 
|  サービスデプロイの終了時刻  | サービスデプロイが終了した時刻。 | 
| サービスデプロイの停止時刻 | サービスデプロイが停止した時刻。 | 
| サービスデプロイの更新時刻 | サービスデプロイが最後に更新された時刻。 | 
| ソースサービスリビジョン |  現在実行中のサービスリビジョン。 含まれるプロパティについては、「[Amazon ECS サービスリビジョンに含まれるプロパティ](service-revision-property.md)」を参照してください。  | 
| デプロイ設定 | サーキットブレーカー設定、決定するアラームを含むデプロイパラメータ。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-deployment-property.html) | 
| ターゲットサービスリビジョン | デプロイするサービスリビジョン。デプロイが正常に完了すると、ターゲットサービスリビジョンは実行中のサービスリビジョンになります。 | 
| サービスデプロイの状態 | サービスデプロイの状態。有効な値は、PENDING、SUCCESSFUL、STOPPED、STOP\$1REQUESTED、STOP\$1IN\$1PROGRESS、IN\$1PROGRESS、ROLLBACK\$1IN\$1PROGRESS、ROLLBACK\$1SUCCESSFUL、および ROLLBACK\$1FAILED です。 | 
| サービスデプロイ状態の情報 | サービスデプロイが現在の状態である理由に関する情報。例えば、サーキットブレーカーが障害を検出したなど。 | 
|  ロールバック情報 | デプロイが失敗したときにサービスデプロイが使用するロールバックオプション。 | 
| サービスデプロイサーキットブレーカーオプション | サービスデプロイが失敗したと判断するサーキットブレーカー。 | 
| サービスデプロイの CloudWatch アラーム | サービスデプロイがいつ失敗したかを判断する CloudWatch アラーム。 | 

# Amazon ECS サービスデプロイを表示するために必要なアクセス許可
<a name="service-deployment-permissions"></a>

 最小権限のベストプラクティスに従うと、コンソールでサービスデプロイを表示するには、アクセス許可を追加する必要があります。

次のアクションへのアクセスが必要です。
+ ListServiceDeployments
+ DescribeServiceDeployments
+ DescribeServiceRevisions

次のリソースへのアクセスが必要です。
+ サービス
+ サービスデプロイ
+ サービスリビジョン

次のポリシー例には必要なアクセス許可が含まれており、アクションは指定されたサービスに限定されます。

`account`、`cluster-name`、および `service-name` を独自の値に置き換えます。

------
#### [ JSON ]

****  

```
{
"Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "ecs:ListServiceDeployments",
            "ecs:DescribeServiceDeployments",
            "ecs:DescribeServiceRevisions"
        ],
        "Resource": [
            "arn:aws:ecs:us-east-1:123456789012:service/cluster-name/service-name",
            "arn:aws:ecs:us-east-1:123456789012:service-deployment/cluster-name/service-name/*",
            "arn:aws:ecs:us-east-1:123456789012:service-revision/cluster-name/service-name/*"
            ]
        }
   ]
}
```

------

# Amazon ECS サービスデプロイの表示
<a name="view-service-deployment"></a>

2024 年 10 月 25 日以降に作成されたデプロイの最新の 90 日間の履歴を確認できます。サービスデプロイは、次のいずれかの状態になります。
+ 進行中 
+ 保留中
+ 完了

 この情報を使用して、サービスのデプロイ方法やサービスリビジョンを更新する必要があるかどうかを判断できます。含まれるプロパティについては、「[Amazon ECS サービスデプロイに含まれるプロパティ](service-deployment-property.md)」を参照してください。

開始する前に、サービスデプロイを表示するために必要なアクセス許可を設定します。詳細については、「[Amazon ECS サービスデプロイを表示するために必要なアクセス許可](service-deployment-permissions.md)」を参照してください。

------
#### [ Amazon ECS Console ]

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。

   [サービスの詳細] ページが表示されます。

1. [サービスの詳細] ページで、**[デプロイ]** を選択します。

1. 表示するサービスデプロイを選択します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/view-service-deployment.html)

   [サービスデプロイの詳細] ページが表示されます。

1. (オプション) サービスリビジョンを比較して、相違点を確認します。

   **[サービスリビジョン]** で、**[リビジョンの比較]** を選択し、比較するリビジョンを 2 つ選択します。

   サービスリビジョンは並行して表示され、相違点が強調表示されます。

------
#### [ AWS CLI ]

1. `list-service-deployments` を実行して、サービスデプロイ ARN を取得します。

   変数を実際の値に置き換えます。

   ```
   aws ecs list-service-deployments --cluster cluster-name --service service-name
   ```

   表示するデプロイの serviceDeploymentArn を書き留めます。

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example",
               "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095",
               "status": "SUCCESSFUL"
           }
       ]
   }
   ```

1. `describe-service-deployments` を実行します。`list-service-deployments` から返された `serviceDeploymentArn` を使用します。

   変数を実際の値に置き換えます。

   ```
   aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5
   ```

------

## 次のステップ
<a name="view-service-deployment-next-step"></a>

デプロイのサービスリビジョンの詳細を表示できます。詳細については、[Amazon ECS サービスリビジョンの詳細の表示](view-service-revision.md)を参照してください。

# Amazon ECS サービスリビジョン
<a name="service-revision"></a>

サービスリビジョンには、Amazon ECS がデプロイしようとしているワークロード設定のレコードが含まれています。サービスを作成またはデプロイするたびに、Amazon ECS はサービスリビジョンでデプロイしようとしている設定を自動的に作成してキャプチャします。

 サービスリビジョンは読み取り専用で、一意の識別子があります。含まれるプロパティについては、「[Amazon ECS サービスリビジョンに含まれるプロパティ](service-revision-property.md)」を参照してください。

 サービスリビジョンには次の利点があります。
+ サービスデプロイ中に、現在デプロイされているサービスリビジョン (ソース) とデプロイ中のサービスリビジョン (ターゲット) を比較できます。
+ サービスデプロイにロールバックオプションを使用すると、Amazon ECS はサービスデプロイを最後に正常にデプロイされたサービスリビジョンに自動的にロールバックします。
+ サービスリビジョンには、1 つのリソースにおけるワークロード設定のレコードが含まれます。

## サービスリビジョンのライフサイクル
<a name="service-revisions-lifecycle"></a>

Amazon ECS は、サービスの作成時、またはデプロイを開始するサービスプロパティの更新時に、新しいサービスリビジョンを自動的に作成します。

 Amazon ECS は、ロールバックオペレーションの新しいサービスリビジョンを作成しません。Amazon ECS は、最後に成功したサービスリビジョンをロールバックに使用します。

サービスリビジョンはイミュータブルです。

サービスを削除すると、Amazon ECS はサービスリビジョンを削除します。

2024 年 10 月 25 日以降に作成されたサービスリビジョンは、コンソール、API、および CLI を使用して表示できます。

# Amazon ECS サービスリビジョンに含まれるプロパティ
<a name="service-revision-property"></a>

サービスリビジョンには、次のプロパティが含まれます。


| リソース | 説明 | 
| --- | --- | 
|  サービス ARN  |  クライアントを識別する ARN。  | 
|  クラスター ARN  |  サービスをホストするクラスターの ARN。  | 
|  タスク定義 ARN  |  サービスタスクに使用されるタスク定義の ARN。  | 
|  サービスレジストリ  |  サービス検出に使用されるサービスレジストリの詳細。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| キャパシティープロバイダー |  キャパシティプロバイダー戦略の詳細。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| コンテナイメージ |  コンテナイメージに関する詳細。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| ネットワーク |  サービスのネットワーク構成。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| 起動タイプ | サービスに使用されるコンピューティングオプション。 | 
| Fargate 固有のプロパティ |  Fargate を使用する場合について、これは Fargate バージョンに関する情報です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| デプロイ時に設定される Amazon EBS ボリューム |  起動時に設定されるボリュームとしてタスク定義で指定されたボリュームの設定。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-revision-property.html)  | 
|  Service Connect |  Service Connect の設定。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| サービスロードバランサー |  サービストラフィックをルーティングするロードバランサー。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Runtime Monitoring | Runtime Monitoring がオンになっているかどうかを示します。 | 
| 作成日 |  サービスリビジョンが作成された日付。  | 
| VPC Lattice |  サービスリビジョンの VPC Lattice 設定。  | 

# Amazon ECS サービスリビジョンの詳細の表示
<a name="view-service-revision"></a>

2024 年 10 月 25 日以降に作成された以下のサービスリビジョンタイプに関する情報を表示できます。
+ ソース - 現在デプロイされているワークロード設定
+ ターゲット - デプロイ中のワークロード設定

------
#### [ Amazon ECS Console ]

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。

   [サービスの詳細] ページが表示されます。

1. [サービスの詳細] ページで、**[デプロイ]** を選択します。

1. 表示するサービスリビジョンを選択します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/view-service-revision.html)

------
#### [ AWS CLI ]

1. `describe-service-deployments` を実行して、サービスリビジョン ARN を取得します。

   変数を実際の値に置き換えます。

   ```
   aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:account-id:service/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5
   ```

   `sourceServiceRevisions` または `targetServiceRevisions` の `arn` を書き留めます。

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example",
               "updatedAt": "2024-09-10T16:49:35.572000+00:00",
               "sourceServiceRevision": {
                   "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373578954",
                   "requestedTaskCount": 0,
                   "runningTaskCount": 0,
                   "pendingTaskCount": 0
               },
               "targetServiceRevision": {
                   "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095",
                   "requestedTaskCount": 0,
                   "runningTaskCount": 0,
                   "pendingTaskCount": 0
               },
               "status": "IN_PROGRESS",
               "deploymentConfiguration": {
                   "deploymentCircuitBreaker": {
                       "enable": false,
                       "rollback": false
                   },
                   "maximumPercent": 200,
                   "minimumHealthyPercent": 100
               }
           }
       ],
       "failures": []
   }
   ```

1. `describe-service-revisions` を実行します。`describe-service-deployments` から返された `arn` を使用します。

   変数を実際の値に置き換えます。

   ```
   aws ecs describe-service-revisions --service-revision-arns arn:aws:ecs:region:123456789012:service-revision/cluster-name/service-name/4980306466373577095
   ```

------

# アベイラビリティーゾーン間での Amazon ECS サービスの調整
<a name="service-rebalancing"></a>

2025 年 9 月 5 日以降、Amazon ECS は、この機能の対象となるすべてのサービスについてアベイラビリティーゾーンの再調整を有効にします。アベイラビリティーゾーンの分散が第一優先のタスク配置戦略である場合、または配置戦略がない場合、サービスは対象になります。

アプリケーションの高可用性を実現するために、マルチタスクサービスを複数のアベイラビリティーゾーンで実行するように設定することをお勧めします。最初の配置戦略をアベイラビリティーゾーンに分散するように指定するサービスの場合、AWS は可能な限り、使用可能なアベイラビリティーゾーン間でサービスタスクを均等に分散します。

ただし、アベイラビリティーゾーンの中断後など、あるアベイラビリティーゾーンで実行されているタスク数が、他のアベイラビリティーゾーンで実行されているタスク数と同じではない場合があります。このタスクの不均衡に対処するには、アベイラビリティーゾーンの再調整機能を有効にします。

アベイラビリティーゾーンの再調整により、Amazon ECS は各サービスのアベイラビリティーゾーン間のタスクの分散を継続的にモニタリングします。Amazon ECS は、不均等なタスク分散を検出すると、アベイラビリティーゾーン間でワークロードを再調整するアクションを自動的に実行します。これには、タスクが最も少ないアベイラビリティーゾーンで新しいタスクを起動し、オーバーロードされたアベイラビリティーゾーンでタスクを終了することが含まれます。

この再分散により、単一のアベイラビリティーゾーンが障害点になることがなくなり、コンテナ化されたアプリケーションの全体的な可用性を維持できます。自動再調整プロセスにより、手動による介入が不要になり、イベント後の復旧までの時間が短縮されます。

アベイラビリティーゾーンの再調整プロセスの概要を次に示します。

1. Amazon ECS は、サービスが定常状態に達した後にモニタリングを開始し、各アベイラビリティーゾーンで実行されているタスク数を調べます。

1. Amazon ECS は、各アベイラビリティーゾーンで実行されているタスク数の不均衡を検出すると、次のオペレーションを実行します。
   + アベイラビリティーゾーンの再調整が開始されていることを示すサービスイベントを送信します。
   + 実行中のタスク数が最も少ないアベイラビリティーゾーンのタスクを開始します
   + 実行中のタスク数が最も多いアベイラビリティーゾーンのタスクを停止します。
   + スケジューラは、新しく開始されたタスクが `HEALTHY` および `RUNNING` になるのを待ってから、オーバースケーリングされたアベイラビリティーゾーンのタスクを停止します。
   + アベイラビリティーゾーンの再調整結果を含むサービスイベントを送信します。

## 不均等なタスク分散を Amazon ECS が検出する方法
<a name="service-rebalancing-imbalance"></a>

サービスの必要なタスク数を設定されたアベイラビリティーゾーンの数で割ることで、Amazon ECS は各アベイラビリティーゾーンで実行されているタスク数の不均衡を判断します。必要なタスク数を割り切れない場合、Amazon ECS は残りのタスクを設定されたアベイラビリティーゾーン間に均等に分散します。各アベイラビリティーゾーンには、少なくとも 1 つのタスクが必要です。

例えば、2 つのアベイラビリティーゾーンに対して設定されたタスクの必要数が 2 つの Amazon ECS サービスを考えてみましょう。このシナリオでは、必要なタスクの数が均等に分割されます。均等な分散では、アベイラビリティーゾーンあたり 1 つのタスクになります。アベイラビリティーゾーン 1 に 2 つのタスクがあり、アベイラビリティーゾーン 2 に 0 のタスクがある場合、Amazon ECS はアベイラビリティーゾーン 1 でタスクを停止する前に、アベイラビリティーゾーン 2 でタスクを開始して再調整を開始します。

ここで、2 つのアベイラビリティーゾーンに対して設定されたタスクの必要数が 3 つの Amazon ECS サービスを考えてみましょう。このシナリオでは、必要なタスクの数は均等に分割されません。各アベイラビリティーゾーンに少なくとも 1 つのタスクがあり、残りのタスクはアベイラビリティーゾーン 2 に配置されているため、アベイラビリティーゾーン 1 で 1 つのタスク、アベイラビリティーゾーン 2 で 2 つのタスクがバランスが取れた分散です。

3 つのアベイラビリティーゾーンに対して設定されたタスクの必要数が 5 つの Amazon ECS サービスを考えてみましょう。このシナリオでは、必要なタスクの数は均等に分割されません。バランスが取れた分散は、アベイラビリティーゾーン 1 で 1 つのタスク、アベイラビリティーゾーン 2 と 3 でそれぞれ 2 つのタスクになります。各アベイラビリティーゾーンに 1 つのタスクがあることを考慮した後、残り 2 つのタスクはアベイラビリティーゾーン全体に均等に分散されます。

## アベイラビリティーゾーンの再調整の設定に関する考慮事項
<a name="service-rebalancing-configurations"></a>

アベイラビリティーゾーンの再調整を設定したい場合は、次の点を考慮してください。
+ アベイラビリティーゾーンの再調整は、Fargate および EC2 のキャパシティプロバイダーをサポートし、Amazon ECS マネージドインスタンスでサポートされています。Fargate の場合、Amazon ECS はバランスを維持するために、使用可能なアベイラビリティーゾーン間でタスクを自動的に再分散します。EC2 キャパシティプロバイダーの場合、Amazon ECS は、定義された配置に関する戦略と制約を考慮して、ベストエフォートベースで既存のコンテナインスタンス間でタスクを再調整します。ただし、Amazon ECS は再調整プロセスの一環として使用率の低いアベイラビリティーゾーンで新しいインスタンスを起動することができないため、再調整は既存のコンテナインスタンスに制限されます。
+ アベイラビリティーゾーンの再調整は、次の設定で機能します。
  + `Replica` 戦略を使用するサービス
  + アベイラビリティーゾーン分散を最初のタスク配置戦略として指定するサービス、または配置戦略を指定しないサービス。
+ アベイラビリティーゾーンの再調整は、次のいずれかの条件を満たすサービスでは使用できません。
  + `Daemon` 戦略を使用する
  + `EXTERNAL` 起動タイプ (ECS Anywhere) を使用する
  + `maximumPercent` 値に 100% を使用する
  + Classic Load Balancer を使用する
  + `attribute:ecs.availability-zone` をタスク配置の制約として使用する

## アベイラビリティーゾーンの再調整による配置戦略と配置制約
<a name="service-rebalancing-placement-constraints"></a>

配置戦略により、Amazon ECS がタスク配置を終了するためのコンテナインスタンスとアベイラビリティーゾーンを選択する方法が決まります。タスク配置の制約は、タスクを特定のコンテナインスタンスで実行できるかどうかを決定するルールです。

EC2 では、アベイラビリティーゾーンの再調整と組み合わせて配置戦略と配置制約を使用できます。ただし、アベイラビリティーゾーンの再調整が機能するには、アベイラビリティーゾーン分散配置戦略が最初に指定される戦略である必要があります。

アベイラビリティーゾーンの再調整は、さまざまな配置戦略の組み合わせと互換性があります。例えば、最初にタスクをアベイラビリティーゾーン間で均等に分散し、次に各アベイラビリティーゾーン内のメモリに基づいてタスクをビンパックする戦略を作成できます。この場合、アベイラビリティーゾーンの分散戦略が最初に指定されているため、アベイラビリティーゾーンの再調整は機能します。

配置戦略配列の最初の戦略がアベイラビリティーゾーン分散コンポーネントではない場合、アベイラビリティーゾーンの再調整は機能しないことに注意してください。この要件により、タスク分散の主な焦点は、高可用性にとって重要なアベイラビリティーゾーン間のバランスを維持することです。

タスク配置の戦略と制約の詳細については、「[Amazon ECS がタスクをコンテナインスタンスに配置する方法](task-placement.md)」を参照してください。

タスクの配置戦略および制約事項は、Fargate を使用しているタスクをサポートしていません。Fargate は、アクセス可能なアベイラビリティーゾーンにタスクを分散するよう最善を尽くします。キャパシティープロバイダーに Fargate と Fargate Spot の両方が含まれている場合、スプレッドの動作はキャパシティープロバイダーごとに異なります。

次の戦略例は、アベイラビリティーゾーン間でタスクを均等に分散し、次に各アベイラビリティーゾーン内でメモリに基づいてタスクをビンパックします。`spread` 戦略が最初に行われるため、アベイラビリティーゾーンの再調整はサービスと互換性があります。

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## アベイラビリティーゾーンの再調整を有効にする
<a name="service-rebalancing-use"></a>

新規および既存のサービスに対してアベイラビリティーゾーンの再調整を有効にする必要があります。

コンソール、API、AWS CLI、および CloudFormation を使用して、アベイラビリティーゾーンの再調整を有効または無効にできます。

`AvailabilityZoneRebalancing` のデフォルトの動作は、作成リクエストと更新リクエストで異なります。
+ サービスリクエスト作成の場合、`AvailabilityZoneRebalancing` に値が指定されていない場合、Amazon ECS はデフォルトで値を `ENABLED` に設定します。
+ サービスリクエスト更新の場合、`AvailabilityZoneRebalancing` に値が指定されていない場合、Amazon ECS はデフォルトでサービスのこれまでの `AvailabilityZoneRebalancing` の値に設定します。サービスに `AvailabilityZoneRebalancing` 値が設定されたことがない場合、Amazon ECS はこれを `DISABLED` として扱います。


| サービスタイプ | API | コンソール | CLI | 
| --- | --- | --- | --- | 
| 既存 | [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) |  [Amazon ECS サービスを更新する](update-service-console-v2.md)  | [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) | 
| 新 | [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) |  [Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)  | [サービスの作成](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) | 

次の例は、新しいサービスの作成時にサービスの再調整を有効にする方法を示しています。

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-definition:1 \
    --desired-count 6 \
    --availability-zone-rebalancing ENABLED
```

# Amazon ECS アベイラビリティーゾーンの再調整を追跡する
<a name="track-service-rebalancing"></a>

アベイラビリティーゾーンの再調整がサービスに対して有効になっているかどうかは、コンソールで確認するか、`describe-services` を呼び出して確認できます。次の例を使用して、CLI でステータスを確認できます。

レスポンスは `ENABLED` または `DISABLED` のいずれかになります。

```
aws ecs describe-services \
    --services service-name \
    --cluster cluster-name \
    --query services[0].availabilityZoneRebalancing
```

## サービスイベント
<a name="service-info-events"></a>

Amazon ECS は、アベイラビリティーゾーンの再調整ライフサイクルを理解するのに役立つサービスアクションイベントを送信します。


| イベント | シナリオ | タイプ | 詳細情報 | 
| --- | --- | --- | --- | 
| SERVICE\$1REBALANCING\$1STARTED | Amazon ECS がアベイラビリティーゾーンの再調整オペレーションを開始 | 情報 | [サービス (*service-name*) は、*Availability Zone 1* の *number-tasks* タスク、*Availability Zone 2* の *number-tasks* タスク、*Availability Zone 3* の *number-tasks* タスクで AZ が調整されていません。AZ の再調整は進行中です。](service-rebalancing-event-messages-list.md#service-rebalancing-started) | 
| SERVICE\$1REBALANCING\$1COMPLETED | アベイラビリティーゾーンの再調整オペレーションが完了 |  情報 | [サービス (*service-name*) は、*Availability Zone 1* の *number-tasks* タスク、*Availability Zone 2* の *number-tasks* タスク、*Availability Zone 3* の *number-tasks* タスクで AZ が調整されています。](service-rebalancing-event-messages-list.md#service-rebalancing-completed) | 
| TASKS\$1STARTED | Amazon ECS がアベイラビリティーゾーンの再調整オペレーションの一環としてタスクを正常に開始する | 情報 | [*service-name* は、AZ の再調整のために *Availability Zone* の *number-tasks* タスクを開始しました: *task-ids*。](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-started) | 
| TASKS\$1STOPPED | Amazon ECS がアベイラビリティーゾーンの再調整オペレーションの一環としてタスクを正常に停止 | 情報 | [*service-name* は、AZ の再調整のために *Availability Zone* の実行中の *number-tasks* タスクを停止しました: *task-ids*。](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-stopped) | 
| SERVICE\$1TASK\$1PLACEMENT\$1FAILURE | Amazon ECS がアベイラビリティーゾーンの再調整オペレーションの一環としてタスクを開始することに失敗 | エラー | EC2 については、「[サービス (*service-name*) で、すべての要件を満たしたコンテナインスタンスがないため、*Availability Zone* にタスクを配置できません。](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure-instance)」を参照してください。Fargate については、「[サービス (*service-name*) で、*Availability Zone* にタスクを配置できません。](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure)」を参照してください。 | 
| TASKSET\$1SCALE\$1IN\$1FAILURE\$1BY\$1TASK\$1PROTECTION | タスク保護が使用されているため、アベイラビリティーゾーンの再調整オペレーションはブロックされます。 | 情報 | [サービス (*service-name*) で、*task-set-name* が *reason* によりスケールインできなかったため、AZ を再調整できませんでした。](service-rebalancing-event-messages-list.md#service-rebalancing-task-protection-failure) | 
| SERVICE\$1REBALANCING\$1STOPPED | アベイラビリティーゾーンの再調整オペレーションが停止。Amazon ECS は、詳細情報を提供する追加のイベントを送信します。 | 情報 | [サービス (*service-name*) が AZ の再調整を停止しました。](service-rebalancing-event-messages-list.md#service-rebalancing-operation-stopped) | 

## タスク状態変更イベント
<a name="task-state-change-events"></a>

Amazon ECS により、再調整プロセスの一環として開始されるタスクごとに、タスク状態の変更イベント (`START`) が送信されます。

Amazon ECS は、再調整プロセスの一環として停止するタスクごとに、タスク状態変更イベント (`STOPPED`) イベントを送信します。理由は `Availability-zone rebalancing initiated by (deployment ecs-svc/deployment-id)` に設定されています。

イベントの詳細については、「[Amazon ECS タスク状態変更イベント](ecs_task_events.md)」を参照してください。

## サービス再調整のトラブルシューティング
<a name="service-rebalancing-troubleshooting"></a>

サービス再調整で問題が発生した場合、次のトラブルシューティングステップを検討してください。

再調整が開始されない  
以下を確認してください。  
+ サービスにサービス再調整が有効になっている
+ サービスでサポートされている設定が使用される (「[アベイラビリティーゾーンの再調整の設定に関する考慮事項](#service-rebalancing-configurations)」を参照)
+ サービスが定常状態になった

再調整中のタスク配置の失敗  
`SERVICE_TASK_PLACEMENT_FAILURE` イベントが表示された場合  
+ EC2 の場合: ターゲットのアベイラビリティーゾーンで利用可能なコンテナインスタンスがあるかどうかを確認します。
+ Fargate の場合: タスク配置を制限するリソース制約または Service Quotas があるかどうかを確認します。
+ タスク配置の制約を確認し、適切なタスク分散が妨げられていないことを確認します。

予期せずに再調整が停止する  
`SERVICE_REBALANCING_STOPPED` イベントが表示された場合  
+ オペレーションをブロックしている可能性のあるタスク保護を確認します
+ 再調整を中断する可能性のある同時サービスデプロイを探します
+ 再調整が停止した原因に関する追加情報については、サービスイベントを確認してください。

## サービス再調整のベストプラクティス
<a name="service-rebalancing-best-practices"></a>

サービス再調整を最大限に活用するには、次のベストプラクティスに従ってください。
+ **再調整オペレーションのモニタリング** – 問題を迅速に特定するため、CloudWatch アラームを設定して、再調整に関連するサービスイベントをモニタリングします。
+ **パフォーマンスへの影響の考慮** – 古いタスクが停止される前に新しいタスクが開始されると、再調整オペレーションによって一時的にリソース使用量が増加する可能性があるので注意してください。
+ **タスク保護の戦略的な使用** – 再調整中に終了すべきではない重要なタスクがある場合は、タスク保護の使用を検討してください。
+ **EC2 キャパシティの計画** – EC2 の場合は、効果的な再調整をサポートするため、すべてのアベイラビリティーゾーン間に十分なコンテナインスタンスがあることを確認します。
+ **再調整動作のテスト** – 本番で再調整に依存する前に、非本番環境で再調整オペレーション中にサービスがどのように動作するかをテストします。

# ロードバランサーを使用して Amazon ECS サービストラフィックを分散する
<a name="service-load-balancing"></a>

サービスは、オプションで Elastic Load Balancing を使用して、サービスのタスク間でトラフィックを均等に分散するように設定できます。

**注記**  
タスクセットを使用するとき、セット内のすべてのタスクが Elastic Load Balancing を使用するように設定、または Elastic Load Balancing を使用しないように設定する必要があります。

AWS Fargate でホストされている Amazon ECS サービスでは、Application Load Balancer、Network Load Balancer、および Gateway Load Balancer がサポートされています。次の表を使用して、使用するロードバランサーのタイプを確認してください。


| ロードバランサーのタイプ | 以下の場合に使用 | 
| --- | --- | 
|  Application Load Balancer  | HTTP/HTTPS (またはレイヤー 7) トラフィックをルーティングします。Amazon Load Balancer は Amazon ECS サービスでの使用に便利な複数の機能を提供しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-load-balancing.html) | 
| Network Load Balancer | TCP または UDP (またはレイヤー 4) トラフィックをルーティングします。 | 
| Gateway Load Balancer | TCP または UDP (またはレイヤー 4) トラフィックをルーティングします。 ファイアウォール、侵入検知および防止システム、ディープパケットインスペクションシステムなどの仮想アプライアンスを使用します。 | 

サービスで Network Load Balancer または Gateway Load Balancer でのみ使用できる機能が必要な場合を除き、最新の機能を利用できるように、Amazon ECS サービスで Application Load Balancer を使用することをお勧めします。これらのロードバランサーの違いについては、「[Elastic Load Balancing ユーザーガイド](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/)」の「Elastic Load Balancing とは」を参照してください。

ロードバランサーについては、お客様が利用された分のみのお支払いとなります。詳細については、[Elastic Load Balancing の料金表](https://aws.amazon.com/elasticloadbalancing/pricing/)を参照してください。

# Amazon ECS のロードバランサーのヘルスチェックパラメータを最適化する
<a name="load-balancer-healthcheck"></a>

ロードバランサーは、ロードバランサーに対して有効になっているアベイラビリティーゾーンの正常なターゲットにのみ、リクエストをルーティングします。各ターゲットはターゲットグループに登録されます。ロードバランサーは、ターゲットグループのヘルスチェック設定を使用して、各ターゲットの状態を確認します。ターゲットは、登録後に正常と見なされるためには、1 つのヘルスチェックに合格する必要があります。Amazon ECS はロードバランサーをモニタリングします。ロードバランサーは Amazon ECS コンテナに定期的にヘルスチェックを送信します。Amazon ECS エージェントはモニタリングし、ロードバランサーがコンテナの状態を報告するのを待ちます。この処理は、コンテナが正常状態にあると見なされる前に行われます。

Elastic Load Balancing の次の 2 つのヘルスチェックパラメータがデプロイ速度に影響します。
+ ヘルスチェック間隔: 個々のコンテナのヘルスチェック間のおおよその時間を秒単位で決定します。デフォルトでは、ロードバランサーは 30 秒ごとにチェックします。

  このパラメータは以下の名前です。
  + Elastic Load Balancing API の `HealthCheckIntervalSeconds`
  + Amazon EC2 コンソールでの **[インターバル]**
+ 正常性しきい値: 異常なコンテナが正常であると判断されるまでに必要なヘルスチェックの連続成功回数を決定します。デフォルトでは、ロードバランサーはターゲットコンテナが正常であると報告する前に 5 回のヘルスチェックに合格する必要があります。

  このパラメータは以下の名前です。
  + Elastic Load Balancing API の `HealthyThresholdCount`
  + Amazon EC2 コンソールの **[正常なしきい値]**

**重要:** 新しく登録されたターゲットの場合、正常なしきい値数の設定に関係なく、ターゲットを正常とみなすために必要なヘルスチェックは 1 回だけです。正常なしきい値数は、ターゲットが異常な状態から正常な状態に戻っている場合にのみ適用されます。

デフォルト設定では、ターゲットが異常な状態になった後回復した場合、コンテナの状態を判断するための合計時間は 2 分 30 秒 (`30 seconds * 5 = 150 seconds`) です。

サービスが 10 秒以内に起動して安定すれば、ヘルスチェックプロセスをスピードアップできます。プロセスを高速にするには、ヘルスチェックの間隔と正常なしきい値の数を減らします。
+ `HealthCheckIntervalSeconds` (Elastic Load Balancing API 名) または **[インターバル]** (Amazon EC2 コンソール名): 5
+ `HealthyThresholdCount` (Elastic Load Balancing API 名) または **[正常なしきい値]** (Amazon EC2 コンソール名): 2

この設定では、ヘルスチェックの処理にデフォルトの 2 分 30 秒かかるのに対し、10 秒かかります。

Elastic Load Balancing ヘルスチェックパラメータの詳細については、「*Elastic Load Balancing ユーザーガイド*」の「[ターゲットグループのヘルスチェック](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)」を参照してください。

# Amazon ECS のロードバランサー Connection Draining パラメータを最適化する
<a name="load-balancer-connection-draining"></a>

最適化を可能にするために、クライアントはコンテナサービスへのキープアライブ接続を維持します。これにより、そのクライアントからの後続のリクエストが既存の接続を再利用できるようにします。コンテナへのトラフィックを停止したいときは、ロードバランサーに通知します。ロードバランサーはクライアントがキープアライブ接続を閉じたかどうかを定期的に確認します。Amazon ECS はロードバランサーをモニタリングし、キープアライブ接続が閉じられた (ターゲットが `UNUSED` の状態にある) ことをロードバランサーが報告するのを待ちます。

ロードバランサーがターゲットを `UNUSED` 状態へと移行するまで待機する時間の長さが登録解除の遅延です。以下のロードバランサーパラメータを設定して、デプロイをスピードアップできます。
+ `deregistration_delay.timeout_seconds`: 300 (デフォルト)

レスポンス時間が 1 秒未満のサービスの場合は、パラメータを次の値に設定して、クライアントとバックエンドサービスとの間の接続を切断するまでロードバランサーが 5 秒だけ待機するようにします。
+ `deregistration_delay.timeout_seconds`: 5 

**注記**  
ファイルのアップロードやストリーミング接続が遅いなど、リクエストの有効期間が長いサービスの場合は、この値を 5 秒に設定しないでください。

## SIGTERM 応答性
<a name="sigterm"></a>

Amazon ECS は、まず停止シグナルをタスクに送信し、アプリケーションを終了してシャットダウンする必要があることを通知します。このシグナルは、STOPSIGNAL 命令を使用してコンテナイメージで定義でき、デフォルトで SIGTERM になります。次に、Amazon ECS は SIGKILL メッセージを送信します。アプリケーションが SIGTERM を無視する場合、Amazon ECS サービスはプロセスを終了する SIGKILL シグナルの送信を待つ必要があります。

Amazon ECS が SIGKILL メッセージの送信を待つ時間は、次の Amazon ECS エージェントオプションによって決まります。
+ `ECS_CONTAINER_STOP_TIMEOUT`: 30 (デフォルト)

  コンテナエージェントパラメータの詳細については、GitHub の「[Amazon ECS コンテナエージェント](https://github.com/aws/amazon-ecs-agent/blob/master/README.md)」を参照してください。

待機時間を短縮するには、Amazon ECS エージェントパラメータを次の値に設定します。
+ `ECS_CONTAINER_STOP_TIMEOUT`: 2

  アプリケーションに 1 秒以上かかる場合は、値に 2 を掛けて、その数値を値として使用します。

この場合、Amazon ECS はコンテナがシャットダウンされるまで 2 秒間待機し、アプリケーションが停止しなかったときに Amazon ECS は SIGKILL メッセージを送信します。

SIGTERM シグナルをトラップして反応するようにアプリケーションコードを変更することもできます。JavaScript の例を次に示します。

```
process.on('SIGTERM', function() { 
  server.close(); 
})
```

このコードにより、HTTP サーバーは新しいリクエストのリッスンを停止し、処理中のリクエストへの応答を終了します。イベントループは何も行わないため Node.js プロセスが終了します。これを考慮すると、プロセスが実行中のリクエストを完了するのに 500 ミリ秒しかかからない場合、プロセスは停止タイムアウトを待って SIGKILL を送信する必要がなく、早期に終了します。

# Amazon ECS 用の Application Load Balancer を使用する
<a name="alb"></a>

Application Load Balancer では、アプリケーションレイヤー (HTTP/HTTPS) でルーティング決定を行い、パスベースのルーティングをサポートします。また、クラスター内の各コンテナインスタンスの 1 つまたは複数のポートにリクエストをルーティングできます。Application Load Balancer では、動的ホストポートマッピングをサポートしています。たとえば、タスクコンテナ定義で NGINX コンテナポートのポート 80、ホストポートのポート 0 を指定した場合、ホストポートはコンテナインスタンスの一時ポート範囲から動的に選択されます (最新の Amazon ECS に最適化された AMI の 32768～61000 など)。タスクの起動時に、NGINX コンテナは、インスタンス ID およびポートの組み合わせとして Application Load Balancer で登録されます。トラフィックは、コンテナに対応するインスタンス ID およびポートに分散されます。この動的なマッピングにより、同じコンテナインスタンスの単一のサービスから複数のタスクを持つことができます。詳細については、[「Application Load Balancer ユーザーガイド」を参照してください](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/)。

デプロイを高速化するためのパラメータ設定のベストプラクティスについては、以下を参照してください。
+ [Amazon ECS のロードバランサーのヘルスチェックパラメータを最適化する](load-balancer-healthcheck.md)
+ [Amazon ECS のロードバランサー Connection Draining パラメータを最適化する](load-balancer-connection-draining.md)

Amazon ECS で Application Load Balancer を使用する場合は、次の点を考慮してください。
+ Amazon ECS には、タスクの作成時および停止時に、ロードバランサーへのターゲットの登録および登録解除に必要なアクセス許可を提供するサービスリンク IAM ロールが必要です。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
+ IPv6 専用設定のサービスの場合は、Application Load Balancer のターゲットグループの IP アドレスタイプを `dualstack` または `dualstack-without-public-ipv4` に設定する必要があります。
+ `awsvpc` ネットワークモードを使用するタスクを含むサービスの場合、サービスのターゲットグループを作成するときに、`instance` ではなく、`ip` をターゲットタイプとして選択する必要があります 。これは、`awsvpc` ネットワークモードを使用するタスクは、Amazon EC2 インスタンスではなく、Elastic Network Interface に関連付けられているためです。
+ サービスが HTTP/HTTPS サービスのポート 80 やポート 443 など、複数の負荷分散されたポートにアクセスする必要がある場合は、2 つのリスナーを設定できます。1 つのリスナーは、リクエストをサービスに転送する HTTPS を担当し、別のリスナーは HTTP リクエストを適切な HTTPS ポートへのリダイレクトを担当します。詳細については、[Application Load Balancer ユーザーガイド](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-listener.html)の*「Application Load Balancer のアクセスログ」を参照してください*。
+ ロードバランサーのサブネット設定には、コンテナインスタンスが存在するアベイラビリティーゾーンすべてを含める必要があります。
+ サービスの作成後にロードバランサーの設定を AWS マネジメントコンソール から変更することはできません。AWS Copilot、AWS CloudFormation、AWS CLI、SDK のいずれかを使用して、AWS CodeDeploy ブルー/グリーンまたは外部ではなく、`ECS` ローリングデプロイコントローラのみのロードバランサー設定を変更できます。ロードバランサー設定を追加、更新、削除すると、Amazon ECS は、更新された Elastic Load Balancing 設定で新しいデプロイを開始します。これにより、タスクがロードバランサーに登録およびロードバランサーから登録解除されます。Elastic Load Balancing 設定を更新する前に、テスト環境でこれを検証することをお勧めします。設定の変更方法については、「*Amazon Elastic Containers Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」を参照してください。
+ サービスタスクがロードバランサーのヘルスチェック条件を満たさない場合、タスクは停止され、再起動されます。このプロセスは、サービスが実行中のタスクの必要数に達するまで続行されます。
+ ロードバランサーで有効にされているサービスに問題がある場合は、「[Amazon ECS のサービスロードバランサーのトラブルシューティング](troubleshoot-service-load-balancers.md)」を参照してください。
+ `instance` ターゲットタイプを使用する場合、タスクおよびロードバランサーは同じ VPC 内にある必要があります。`ip` ターゲットタイプを使用する場合、クロス VPC 接続がサポートされます。
+ 各サービスに固有のターゲットグループを使用します。

  複数のサービスに同じターゲットグループを使用すると、サービスのデプロイ時に問題が発生する可能性があります。
+ Application Load Balancer に関連付けられているターゲットグループを指定する必要があります。

Application Load Balancer の作成方法については、「*Application Load Balancer*」の「[Application Load Balancer の作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html)」を参照してください。

# Amazon ECS 用の Network Load Balancer を使用する
<a name="nlb"></a>

[Network Load Balancer] により、トランスポートレイヤー (TCP/SSL) でルーティングの決定が行われます。毎秒数百万のリクエストを処理できます。ロードバランサーは、接続を受信すると、フローハッシュルーティングアルゴリズムを使用してデフォルトルールのターゲットグループからターゲットを選択します。リスナー構成で指定されたポート上の選択したターゲットへの TCP 接続を開こうとします。ヘッダーを変更せずにリクエストを転送します。Network Load Balancer では、動的ホストポートマッピングをサポートしています。たとえば、タスクコンテナ定義で NGINX コンテナポートのポート 80、ホストポートのポート 0 を指定した場合、ホストポートはコンテナインスタンスの一時ポート範囲から動的に選択されます (最新の Amazon ECS に最適化された AMI の 32768～61000 など)。タスクの起動時に、NGINX コンテナは、インスタンス ID およびポートの組み合わせとして Network Load Balancer で登録されます。トラフィックは、コンテナに対応するインスタンス ID およびポートに分散されます。この動的なマッピングにより、同じコンテナインスタンスの単一のサービスから複数のタスクを持つことができます。Network Load Balancer の詳細については、「[https://docs.aws.amazon.com/elasticloadbalancing/latest/network/](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/) のユーザーガイド」を参照してください。

デプロイを高速化するためのパラメータ設定のベストプラクティスについては、以下を参照してください。
+ [Amazon ECS のロードバランサーのヘルスチェックパラメータを最適化する](load-balancer-healthcheck.md)
+ [Amazon ECS のロードバランサー Connection Draining パラメータを最適化する](load-balancer-connection-draining.md)

Amazon ECS で Network Load Balancer を使用する場合は、次の点を考慮してください。
+ Amazon ECS には、タスクの作成時および停止時に、ロードバランサーへのターゲットの登録および登録解除に必要なアクセス許可を提供するサービスリンク IAM ロールが必要です。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
+ 1 つのサービスに 5 つ以上のターゲットグループをアタッチすることはできません。
+ IPv6 専用設定のサービスの場合は、Network Load Balancer のターゲットグループの IP アドレスタイプを `dualstack` に設定する必要があります。
+ `awsvpc` ネットワークモードを使用するタスクを含むサービスの場合、サービスのターゲットグループを作成するときに、`instance` ではなく、`ip` をターゲットタイプとして選択する必要があります 。これは、`awsvpc` ネットワークモードを使用するタスクは、Amazon EC2インスタンスではなく、Elastic Network Interface に関連付けられているためです。
+ ロードバランサーのサブネット設定には、コンテナインスタンスが存在するアベイラビリティーゾーンすべてを含める必要があります。
+ サービスの作成後にロードバランサーの設定を AWS マネジメントコンソール から変更することはできません。AWS Copilot、AWS CloudFormation、AWS CLI、SDK のいずれかを使用して、AWS CodeDeploy ブルー/グリーンまたは外部ではなく、`ECS` ローリングデプロイコントローラのみのロードバランサー設定を変更できます。ロードバランサー設定を追加、更新、削除すると、Amazon ECS は、更新された Elastic Load Balancing 設定で新しいデプロイを開始します。これにより、タスクがロードバランサーに登録およびロードバランサーから登録解除されます。Elastic Load Balancing 設定を更新する前に、テスト環境でこれを検証することをお勧めします。設定の変更方法については、「*Amazon Elastic Containers Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」を参照してください。
+ サービスタスクがロードバランサーのヘルスチェック条件を満たさない場合、タスクは停止され、再起動されます。このプロセスは、サービスが実行中のタスクの必要数に達するまで続行されます。
+ IP アドレスをターゲットとして設定し、クライアント IP の保持をオフにした Gateway Load Balancer を使用する場合、リクエストは Gateway Load Balancer のプライベート IP アドレスから送信されたと見なされます。これは、ターゲットのセキュリティグループで受信リクエストとヘルスチェックを許可するとすぐに、Gateway Load Balancer の背後にあるサービスが世界中からアクセス可能になることを意味します。
+ Fargate タスクでは、プラットフォームバージョン `1.4.0` (Linux) または `1.0.0` (Windows) を使用する必要があります。
+ ロードバランサーで有効にされているサービスに問題がある場合は、「[Amazon ECS のサービスロードバランサーのトラブルシューティング](troubleshoot-service-load-balancers.md)」を参照してください。
+ `instance` ターゲットタイプを使用する場合、タスクおよびロードバランサーは同じ VPC 内にある必要があります。`ip` ターゲットタイプを使用する場合、クロス VPC 接続がサポートされます。
+ Network Load Balancer のクライアント IP アドレスの保存は Fargate ターゲットと互換性があります。
+ 各サービスに固有のターゲットグループを使用します。

  複数のサービスに同じターゲットグループを使用すると、サービスのデプロイ時に問題が発生する可能性があります。
+ Network Load Balancer に関連付けられているターゲットグループを指定する必要があります。

Network Load Balancer を作成する方法については、「*Network Load Balancers*」の「[Network Load Balancer の作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)」を参照してください。

**重要**  
サービスのタスク定義で、`awsvpc` ネットワークモード (Fargate の場合に必要) が使用されている場合は、`instance` ではなく、`ip` をターゲットタイプとして選択する必要があります。これは、`awsvpc` ネットワークモードを使用するタスクは、Amazon EC2インスタンスではなく、Elastic Network Interface に関連付けられているためです。  
インスタンス ID が C1、CC1、CC2、CG1、CG2、CR1、G1、G2、HI1、HS1、M1、M2、M3、および T1 のインスタンス ID でインスタンスを登録することはできません。IP アドレスで、これらの種類のインスタンスを登録することができます。

# Amazon ECS 用の Gateway Load Balancer を使用する
<a name="glb"></a>

ゲートウェイロードバランサーは、開放型システム間相互接続 (OSI) モデルの第 3 層（ネットワークレイヤー）で機能します。すべてのポートですべての IP パケットをリッスンし、リスナールールで指定されたターゲットグループにトラフィックを転送します。5 タプル（TCP/UDP フローの場合）または 3 タプル（非 TCP/UDP フローの場合）を使用して、特定のターゲットアプライアンスへのフローのスティッキ状態を維持します。たとえば、タスクコンテナ定義で NGINX コンテナポートのポート 80、ホストポートのポート 0 を指定した場合、ホストポートはコンテナインスタンスの一時ポート範囲から動的に選択されます (最新の Amazon ECS に最適化された AMI の 32768～61000 など)。タスクの起動時に、NGINX コンテナは、インスタンス ID およびポートの組み合わせとして Gateway Load Balancer で登録されます。トラフィックは、コンテナに対応するインスタンス ID およびポートに分散されます。この動的なマッピングにより、同じコンテナインスタンスの単一のサービスから複数のタスクを持つことができます。詳細については、「*Gateway Load Balancers*」の「[What is a Gateway Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html)」を参照してください。

デプロイを高速化するためのパラメータ設定のベストプラクティスについては、以下を参照してください。
+ [Amazon ECS のロードバランサーのヘルスチェックパラメータを最適化する](load-balancer-healthcheck.md)
+ [Amazon ECS のロードバランサー Connection Draining パラメータを最適化する](load-balancer-connection-draining.md)

Amazon ECS で Gateway Load Balancer を使用する場合は、次の点を考慮してください。
+ Amazon ECS には、タスクの作成時および停止時に、ロードバランサーへのターゲットの登録および登録解除に必要なアクセス許可を提供するサービスリンク IAM ロールが必要です。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
+ IPv6 専用設定のサービスの場合は、Gateway Load Balancer のターゲットグループの IP アドレスタイプを `dualstack` に設定する必要があります。
+ `awsvpc` 以外のネットワークモードを使用するタスクがあるサービスの場合、Gateway Load Balancer はサポートされません。
+ ロードバランサーのサブネット設定には、コンテナインスタンスが存在するアベイラビリティーゾーンすべてを含める必要があります。
+ サービスの作成後にロードバランサーの設定を AWS マネジメントコンソール から変更することはできません。AWS Copilot、AWS CloudFormation、AWS CLI、SDK のいずれかを使用して、AWS CodeDeploy ブルー/グリーンまたは外部ではなく、`ECS` ローリングデプロイコントローラのみのロードバランサー設定を変更できます。ロードバランサー設定を追加、更新、削除すると、Amazon ECS は、更新された Elastic Load Balancing 設定で新しいデプロイを開始します。これにより、タスクがロードバランサーに登録およびロードバランサーから登録解除されます。Elastic Load Balancing 設定を更新する前に、テスト環境でこれを検証することをお勧めします。設定の変更方法については、「*Amazon Elastic Containers Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」を参照してください。
+ サービスタスクがロードバランサーのヘルスチェック条件を満たさない場合、タスクは停止され、再起動されます。このプロセスは、サービスが実行中のタスクの必要数に達するまで続行されます。
+ IP アドレスをターゲットとして設定した Gateway Load Balancer を使用する場合、リクエストは Gateway Load Balancer のプライベート IP アドレスから送信されたと見なされます。これは、ターゲットのセキュリティグループで受信リクエストとヘルスチェックを許可するとすぐに、Gateway Load Balancer の背後にあるサービスが世界中からアクセス可能になることを意味します。
+ Fargate タスクでは、プラットフォームバージョン `1.4.0` (Linux) または `1.0.0` (Windows) を使用する必要があります。
+ ロードバランサーで有効にされているサービスに問題がある場合は、「[Amazon ECS のサービスロードバランサーのトラブルシューティング](troubleshoot-service-load-balancers.md)」を参照してください。
+ `instance` ターゲットタイプを使用する場合、タスクおよびロードバランサーは同じ VPC 内にある必要があります。`ip` ターゲットタイプを使用する場合、クロス VPC 接続がサポートされます。
+ 各サービスに固有のターゲットグループを使用します。

  複数のサービスに同じターゲットグループを使用すると、サービスのデプロイ時に問題が発生する可能性があります。
+ Gateway Load Balancer に関連付けられているターゲットグループを指定する必要があります。

Gateway Load Balancer を作成する方法については、「*Gateway Load Balancers*」の「[Gateway Load Balancer の開始方法](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html)」を参照してください。

**重要**  
サービスのタスク定義で、`awsvpc` ネットワークモード (Fargate の場合に必要) が使用されている場合は、`instance` ではなく、`ip` をターゲットタイプとして選択する必要があります。これは、`awsvpc` ネットワークモードを使用するタスクは、Amazon EC2インスタンスではなく、Elastic Network Interface に関連付けられているためです。  
インスタンス ID が C1、CC1、CC2、CG1、CG2、CR1、G1、G2、HI1、HS1、M1、M2、M3、および T1 のインスタンス ID でインスタンスを登録することはできません。IP アドレスで、これらの種類のインスタンスを登録することができます。

# Amazon ECS サービスに複数のターゲットグループを登録する
<a name="register-multiple-targetgroups"></a>

サービス定義で複数のターゲットグループを指定すると、Amazon ECS サービスは複数のロードバランサーからのトラフィックを送信し、複数のロードバランサーポートを公開できます。

複数のターゲットグループを指定してサービスを作成するには、Amazon ECS API、SDK、AWS CLI、または CloudFormation テンプレートを使用してサービスを作成する必要があります。サービスの作成後、AWS マネジメントコンソール に登録されているサービスとターゲットグループを表示できます。既存サービスのロードバランサー設定を変更するには、`[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)` を使用する必要があります。

次の形式を使用して、複数のターゲットグループをサービス定義で指定できます。サービス定義の完全な構文については、「[サービス定義テンプレート](sd-template.md)」を参照してください。

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"container_name",
      "containerPort":container_port
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"container_name",
      "containerPort":container_port
   }
]
```

## 考慮事項
<a name="multiple-targetgroups-considerations"></a>

サービス定義で複数のターゲットグループを指定する際には、次の点を考慮する必要があります。
+ Application Load Balancer または Network Load Balancer を使用するサービスの場合、6 個以上のターゲットグループはアタッチできません。
+ サービス定義での複数のターゲットグループの指定は、次の条件でのみサポートされます。
  + サービスでは、Application Load Balancer またはNetwork Load Balancer を使用する必要があります。
  + サービスで (`ECS`) デプロイコントローラタイプを使用する必要があります。これは、Amazon ECS ネイティブ/ブルーグリーンデプロイ、またはローリング更新デプロイのいずれかです。
+ Fargate と EC2 の両方の起動タイプを使用するタスクを含むサービスでは、複数のターゲットグループの指定がサポートされます。
+ 複数のターゲットグループを指定するサービスを作成するときは、Amazon ECS サービスにリンクされたロールを作成する必要があります。ロールは、API リクエストの `role` パラメータを省略するか、CloudFormation の `Role` プロパティを省略することによって作成されます。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。

## サービス定義の例
<a name="multiple-targetgroups-examples"></a>

次に、サービス定義で複数のターゲットグループを指定するいくつかのユースケースの例を示します。サービス定義の完全な構文については、「[サービス定義テンプレート](sd-template.md)」を参照してください。

### 内部トラフィックと外部トラフィックに別々のロードバランサーを使用する
<a name="multiple-targetgroups-example1"></a>

次のユースケースでは、サービスは 2 つの別個のロードバランサーを使用します。1 つは内部トラフィック用、もう 1 つはインターネット向けトラフィック用で、同じコンテナとポートに対して使用します。

```
"loadBalancers":[
   //Internal ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"nginx",
      "containerPort":8080
   },
   //Internet-facing ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"nginx",
      "containerPort":8080
   }
]
```

### 同じコンテナの複数のポートを公開する
<a name="multiple-targetgroups-example1"></a>

次のユースケースでは、サービスは 1 つのロードバランサーを使用しますが、同じコンテナから複数のポートを公開します。例えば、Jenkins コンテナは、Jenkins ウェブインターフェイス用にポート 8080 を、API 用にポート 50000 を公開する場合があります。

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"jenkins",
      "containerPort":8080
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"jenkins",
      "containerPort":50000
   }
]
```

### 複数のコンテナのポートを公開する
<a name="multiple-targetgroups-example3"></a>

次のユースケースでは、サービスは 1 つのロードバランサーと 2 つのターゲットグループを使用して、個別のコンテナからポートを公開します。

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"webserver",
      "containerPort":80
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"database",
      "containerPort":3306
   }
]
```

# Amazon ECS サービスを自動的にスケールする
<a name="service-auto-scaling"></a>

*オートスケーリング* は、Amazon ECS サービスで必要なタスク数を自動的に増減する機能です。Amazon ECS は アプリケーション Auto Scaling サービスを活用してこの機能を提供します。詳細については、 [ユーザーガイドの Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html) リファレンスを参照してください。

Amazon ECS はご使用のサービスの CPU とメモリの平均使用量を含む CloudWatch メトリクスを発行します。詳細については、「[Amazon ECS サービスの使用率メトリクス](service_utilization.md)」を参照してください。これらおよびその他の CloudWatch メトリクスを使用して、ピーク時に高需要に対処するためにサービスをスケールアウトし (実行するタスクを増やし)、使用率の低い期間にコストを削減するためにサービスをスケールインする (実行するタスクを減らす) ことができます。

Amazon ECS Service Auto Scaling は、以下のタイプの自動スケーリングをサポートします。
+ [ターゲットメトリクスを使用して Amazon ECS サービスをスケールする](service-autoscaling-targettracking.md) - 特定のメトリクスのターゲット値に基づいて、サービスが実行するタスク数を増減させます。これはサーモスタットが家の温度を維持する方法に似ています。温度を選択すれば、後はサーモスタットがすべてを実行します。
+ [CloudWatch アラームに基づく定義済みの増分を使用して Amazon ECS サービスをスケールする](service-autoscaling-stepscaling.md) - アラーム超過のサイズに応じて変動する一連のスケーリング調整値 (ステップ調整値) に基づいて、サービスが実行するタスク数を増減させます。
+ [スケジュールされたアクションを使用して Amazon ECS サービスをスケールする](service-autoscaling-schedulescaling.md) - 日付と時刻に基づいてサービスが実行するタスクの数を増減させます。
+ [履歴パターンを使用して予測スケーリングで Amazon ECS サービスをスケールする](predictive-auto-scaling.md) — トラフィックフローの日次または週次のパターンを検出するための過去の負荷データ分析に基づいて、サービスが実行するタスク数を増減します。

   

## 考慮事項
<a name="auto-scaling-concepts"></a>

スケーリングポリシーを使用する場合は、次の考慮事項に注意してください。
+ Amazon ECSは、CloudWatch に 1 分間隔でメトリクスを送信します。クラスターとサービスが CloudWatch にメトリクスを送信するまで、メトリクスは使用できません。また、存在しないメトリクスに対して CloudWatch アラームを作成することはできません。
+ スケーリングポリシーは、クールダウン期間をサポートします。これは、以前のスケーリングアクティビティが有効になるまで待機する秒数です。
  + スケールアウトイベントでは、スケールアウトが継続的に (ただし過剰になることなく) 行われます。スケーリングポリシーを使用してサービスの自動スケーリングが正常にスケールアウトすると、クールダウン時間の計算が開始されます。スケーリングポリシーは、より大きなスケールアウトが開始されるか、クールダウン期間が終了しない限り、必要な容量を再度増加させません。このスケールアウトクールダウン期間が有効な間は、スケールアウトアクティビティを開始することで追加された容量は、次のスケールアウトアクティビティに予定される容量の一部として繰り入れられます。
  + スケールインイベントでは、アプリケーションの可用性を保護するために控えめにスケールインされます。そのため、スケールインアクティビティはクールダウン期間が終了するまでブロックされます。ただし、スケールインクールダウン期間中に別のアラームがスケールアウトアクティビティを開始した場合、アプリケーションの自動スケーリングスケールによってターゲットが即座にスケールアウトされます。この場合、スケールインクールダウン期間は停止し、完了しません。
+ サービススケジューラは常に必要数を優先しますが、サービスにアクティブなスケーリングポリシーとアラームがある限り、サービスの自動スケーリングはユーザーが手動で設定した必要数を変更できます。
+ サービスの必要タスク数が容量最小値より小さく設定された状態で、アラームがスケールアウトアクティビティを開始したとき、サービスの自動スケーリングが必要タスク数を容量最小値までスケールアップします。その後もアラームに関連付けられたスケーリングポリシーに基づいて、必要に応じてスケーリングし続けます。ただし、必要数はすでにキャパシティーの最小値より小さいため、スケールインアクティビティでは調整されません。
+ サービスの必要タスク数が容量最大値より大きく設定された状態で、アラームがスケールインアクティビティを開始したとき、Service Auto Scaling が必要タスク数を容量最大値までスケールアウトします。その後もアラームに関連付けられたスケーリングポリシーに基づいて、必要に応じてスケーリングし続けます。ただし、必要タスク数はすでに容量最大値より大きいため、スケールアウトアクティビティでは調整されません。
+ スケーリングアクティビティ中、サービスで実際に実行されているタスクの数は、必要数ではなく、サービスの自動スケーリングが開始点として使用する値です。これが想定される処理能力です。これにより、例えば、追加タスクを配置するために十分なコンテナインスタンスリソースがない場合に、満たすことができない過剰な (ランナウェイ) スケーリングを防ぐことができます。後でコンテナインスタンスのキャパシティーを使用できるようになった場合、保留中の規模の拡大や縮小が続行され、クールダウン期間後にさらに規模の拡大や縮小を続行できることができます。
+ 実行する作業がないときにタスク数をゼロにスケーリングするには、キャパシティーの最小値を 0 に設定します。ターゲット追跡スケーリングポリシーでは、実際の容量が 0 で、メトリクスがワークロードの需要があることを示している場合、サービスの自動スケーリングは 1 つのデータポイントの送信を待ってからスケールアウトします。この場合、開始点として可能な最小量だけスケールアウトしてから、実際の実行中のタスク数に基づいてスケーリングを再開します。
+ Application Auto Scaling は、Amazon ECS デプロイの進行中にスケールインプロセスをオフにします。ただし、スケールアウトプロセスは、中断しない限り、デプロイ中に引き続き発生します。この動作は、外部デプロイコントローラーを使用した Amazon ECS サービスには適用されません。詳細については、「[サービスの自動スケーリングとデプロイ](#service-auto-scaling-deployments)」を参照してください。
+ Amazon ECS タスクには、いくつかの Application Auto Scaling オプションがあります。ターゲットトラッキングは最も使いやすいモードです。これにより、CPU 平均使用率などのメトリクスの目標値を設定するだけです。次に、オートスケーラーは、その値を達成するために必要なタスクの数を自動的に管理します。ステップスケーリングを使用すると、スケーリングメトリクスの特定のしきい値と、しきい値を超えたときに追加または削除するタスクの数を定義できるため、需要の変化に迅速に対応できます。さらに重要なことは、しきい値アラームが超過する時間を最小限に抑えることで、需要の変化に非常に迅速に対応できることです。

サービスの自動スケーリングにおけるベストプラクティスの詳細については、「[Amazon ECS サービスの自動スケーリングの最適化](capacity-autoscaling-best-practice.md)」を参照してください。

## サービスの自動スケーリングとデプロイ
<a name="service-auto-scaling-deployments"></a>

Application Auto Scaling は、Amazon ECS デプロイの進行中にスケールインプロセスをオフにします。ただし、スケールアウトプロセスは、中断しない限り、デプロイ中に引き続き発生します。この動作は、外部デプロイコントローラーを使用した Amazon ECS サービスには適用されません。デプロイの進行中にスケールアウトプロセスを中断する場合は、次の手順を実行します。

1. Application Auto Scaling のスケーラブルなターゲットに関連付けられたサービスのリソース ID (例: `service/default/sample-webapp`) を指定して [describe-scalable-targets](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scalable-targets.html) コマンドを呼び出します。出力を記録します。これは、次のコマンドを呼び出すときに必要になります。

1. リソース ID、名前空間、およびスケーラブルなディメンションを指定して [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) コマンドを呼び出します。`DynamicScalingInSuspended` と`DynamicScalingOutSuspended` の両方に `true` を指定します。

1. デプロイが完了したら、[register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) コマンドを呼び出してスケーリングを再開できます。

詳細については、「[Application Auto Scaling のスケーリングの中断と再開](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html)」を参照してください。

# ターゲットメトリクスを使用して Amazon ECS サービスをスケールする
<a name="service-autoscaling-targettracking"></a>

ターゲット追跡スケーリングポリシーで、メトリクスを選択してターゲット値を設定します。Amazon ECS サービス自動スケーリングは、スケーリングポリシーを制御する CloudWatch アラームを作成および管理し、メトリクスとターゲット値に基づいてスケーリング調整値を計算します。スケーリングポリシーは、指定されたターゲット値、またはそれに近い値にメトリクスを維持するため、必要に応じてサービスタスクを追加または削除します。ターゲットの追跡スケーリングポリシーは、メトリクスをターゲット値近くに維持することに加えて、負荷パターンの変動によるメトリクスの変動に合わせて調整し、サービスで実行されているタスク数の急速な変動を最小化します。

ターゲット追跡ポリシーにより、CloudWatch アラームとスケーリング調整を手動で定義する必要がなくなります。Amazon ECS は、設定したターゲットに基づいてこれを自動的に処理します。

ターゲット追跡ポリシーを使用する際は、以下について検討します。
+ ターゲットの追跡スケーリングポリシーでは、指定されたメトリクスがターゲット値を超えている場合、スケールアウトする必要があると見なされます。指定されたメトリクスがターゲット値を下回っている場合、ターゲットの追跡スケーリングポリシーを使用してスケールアウトすることはできません。
+ 指定されたメトリクスに十分なデータがない場合、ターゲットの追跡スケーリングポリシーによってスケールされません。不十分なデータは低い使用率として解釈されないため、スケールインされません。
+ ターゲット値と実際のメトリクスデータポイント間にギャップが発生する場合があります。これは、Service Auto Scaling が追加または削除する容量を判断するときに、その数を切り上げまたは切り捨てることによって、常に控えめに動作するためです。これにより、不十分な容量を追加したり、必要以上に容量を削除することを防ぎます。
+ アプリケーションの可用性を高めるために、サービスのスケールアウトはメトリクスに比例して可能な限り高速に行われますが、スケールインはより緩やかです。
+ Application Auto Scaling は、Amazon ECS デプロイの進行中にスケールインプロセスをオフにします。ただし、スケールアウトプロセスは、中断しない限り、デプロイ中に引き続き発生します。この動作は、外部デプロイコントローラーを使用した Amazon ECS サービスには適用されません。詳細については、「[サービスの自動スケーリングとデプロイ](service-auto-scaling.md#service-auto-scaling-deployments)」を参照してください。
+ Amazon ECS サービスに対して複数のターゲット追跡スケーリングポリシーを設定できます。ただし、各ポリシーがそれぞれ異なるメトリクスを使用している必要があります。サービスの自動スケーリングの目的は常に可用性を優先することであるため、その動作は、スケールアウトまたはスケールインに対するターゲット追跡ポリシーの準備が整っているかどうかに応じて異なります。ターゲット追跡ポリシーのいずれかでスケールアウトする準備ができると、サービスがスケールアウトされますが、すべてのターゲット追跡ポリシー (スケールイン部分がオン) でスケールインする準備ができている場合にのみスケールインされます。
+ ターゲット追跡スケーリングポリシーのためにサービスの自動スケーリングが管理する CloudWatch アラームを編集または削除しないでください。スケーリングポリシーを削除するときに、サービスの自動スケーリングはアラームを自動的に削除します。
+ ブルー/グリーンデプロイタイプでは、ターゲット追跡スケーリングポリシーの `ALBRequestCountPerTarget` メトリクスはサポートされません。

ターゲット追跡スケーリングポリシーの詳細については、「Application Auto Scaling ユーザーガイド」の「[ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)」を参照してください。

# Amazon ECS サービスの自動スケーリングのターゲット追跡スケーリングポリシーを作成する
<a name="target-tracking-create-policy"></a>

ターゲット追跡スケーリングポリシーを作成して、Amazon ECS がサービスで必要なタスク数を自動的に増減するようにします。ターゲット追跡は、ターゲットメトリクス値に基づいて機能します。

## コンソール
<a name="target-tracking-create-policy-aws-console"></a>

1. サービスの作成や更新に使用する標準の IAM アクセス権限に加えて、追加のアクセス権限が必要です。詳細については、「[Amazon ECS のサービス自動スケーリングに必要な IAM アクセス許可](auto-scaling-IAM.md)」を参照してください。

1. ポリシーに使用するメトリクスを決定します。以下のメトリクスが利用可能です。
   +  **[ECSServiceAverageCPUUtilization]** — サービスが使用する平均 CPU 使用率。
   + **[ECSServiceAverageMemoryUtilization]** — サービスが使用する平均メモリ使用率。
   + **[ALBRequestCountPerTarget]** – タスクが受信する 1 分あたりの理想的な平均リクエスト数。

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。

   [サービス詳細] ページが表示されます。

1. **[タスク数を設定する]** を選択します。

1. **[Amazon ECS サービスのタスク数]** で、**[自動スケーリングを使用する]** を選択します。

   **[タスク数セクション]** が表示されます。

   1. **[タスクの最小数]** に、サービスの自動スケーリングで使用するタスクの下限数を入力します。必要な数がこの数を下回ることはありません。

   1. **[最大]** に、サービスの自動スケーリングで使用するタスクの上限数を入力します。必要な数がこの数を超えることはありません。

   1. **[保存]** を選択します。

      [ポリシー] ページが表示されます。

1. **[スケーリングポリシーを作成する]** を選択します。

   **[ポリシーを作成する]** ページが表示されます。

1. [**スケーリングポリシータイプ**] で [**ターゲットの追跡**] を選択します。

1. **[Policy Name]** (ポリシー名) にこのポリシーの名前を入力します。

1. **[メトリクスのタイプ]** で、オプションのリストからメトリクスを選択します。

1. **[ターゲット使用率]** には、Amazon ECS が維持するタスクの割合のターゲット値を入力します。サービスの自動スケーリングは、平均使用率が目標使用率になるまで、または指定した最大タスク数に達するまで、キャパシティをスケールアウトします。

1. **[追加設定]** で、以下を実行します。

   1. **[スケールインのクールダウン期間]** に、スケールインアクティビティが完了してから別のスケールインアクティビティが開始されるまでの時間を秒単位で入力します。

   1. **[スケールアウトのクールダウン期間]** には、前回のスケールアウトアクティビティが有効になるまで待機する時間を秒単位で入力します。

   1. スケールアウトポリシーのみを作成するには、**[スケールインを無効にする]** を選択します。

1. **[スケーリングポリシーを作成する]** を選択します。

## AWS CLI
<a name="target-tracking-create-policy-aws-cli"></a>

1. [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) コマンドを使用して、スケーラブルなターゲットとして Amazon ECS サービスを登録します。

1. [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) コマンドを使用して、スケーリングポリシーを作成します。

# CloudWatch アラームに基づく定義済みの増分を使用して Amazon ECS サービスをスケールする
<a name="service-autoscaling-stepscaling"></a>

ステップスケーリングポリシーを使用して、スケーリングプロセスを呼び出す CloudWatch アラームを作成および管理します。アラームに違反すると、Amazon ECS はそのアラームに関連付けられたスケーリングポリシーを開始します。ステップスケーリングポリシーは、ステップ調整と呼ばれる一連の調整を使用してタスクをスケールします。調整値の規模は、アラーム違反の大きさに応じて異なります。
+ 違反が最初のしきい値を超えた場合、Amazon ECS は最初のステップの調整を適用します。
+ 違反が 2 番目のしきい値を超えた場合、Amazon ECS は 2 番目のステップの調整を適用するというように続きます。

ターゲット追跡スケーリング ポリシーを使用して、ターゲットごとの平均 CPU 使用率や平均リクエスト数などのメトリクスに基づいてスケールすることを強くお勧めします。キャパシティーが増加すると減少し、キャパシティーが減少すると増加するメトリクスを使用すると、ターゲット追跡を使用してインスタンス数を比例的にスケールアウトしたり、タスク数を増やすことができます。これにより、Amazon ECS がアプリケーションの需要曲線に厳密に従うことが保証されます。

# Amazon ECS サービスの自動スケーリングのステップスケーリングポリシーを作成する
<a name="step-scaling-create-policy"></a>

ステップスケーリングポリシーを作成して、Amazon ECS がサービスで必要なタスク数を自動的に増減させます。ステップスケーリングは、ステップ調整と呼ばれる、超過アラームのサイズによって異なる一連のスケーリング調整値に基づいて実行されます。

## コンソール
<a name="step-scaling-create-policy-aws-console"></a>

1. サービスの作成や更新に使用する標準の IAM アクセス権限に加えて、追加のアクセス権限が必要です。詳細については、「[Amazon ECS のサービス自動スケーリングに必要な IAM アクセス許可](auto-scaling-IAM.md)」を参照してください。

1. ポリシーに使用するメトリクスを決定します。以下のメトリクスが利用可能です。
   +  **[ECSServiceAverageCPUUtilization]** — サービスが使用する平均 CPU 使用率。
   + **[ECSServiceAverageMemoryUtilization]** — サービスが使用する平均メモリ使用率。
   + **[ALBRequestCountPerTarget]** – タスクが受信する 1 分あたりの理想的な平均リクエスト数。

1. メトリクスの CloudWatch アラームを作成します。詳細については、*Amazon CloudWatch ユーザーガイド*の「[静的しきい値に基づいて CloudWatch アラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)」を参照してください。

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。

   [サービス詳細] ページが表示されます。

1. **[タスク数を設定する]** を選択します。

1. **[Amazon ECS サービスのタスク数]** で、**[自動スケーリングを使用する]** を選択します。

   **[タスク数セクション]** が表示されます。

   1. **[タスクの最小数]** に、サービスの自動スケーリングで使用するタスクの下限数を入力します。必要な数がこの数を下回ることはありません。

   1. **[最大]** に、サービスの自動スケーリングで使用するタスクの上限数を入力します。必要な数がこの数を超えることはありません。

   1. **[保存]** を選択します。

      [ポリシー] ページが表示されます。

1. **[スケーリングポリシーを作成する]** を選択します。

   **[ポリシーを作成する]** ページが表示されます。

1. **[スケーリングポリシータイプ]** で **[ステップスケーリング]** を選択します。

1. スケールアウトプロパティを設定します。**[タスクを追加するステップ]** で、次を実行します。

   1. **[Policy Name]** (ポリシー名) にこのポリシーの名前を入力します。

   1. **[CloudWatch アラーム名]** で、CloudWatch アラームを選択します。

   1. **[メトリクスの集計タイプ]** で、選択したメトリクスを定義されたしきい値と比較する方法を選択します。

   1. **[調整タイプ]** で、調整がタスク数の変化に基づくか、タスクの割合の変化に基づくかを選択します。

   1. **[実行するアクション]** で、実行するアクションの値を入力します。

      **[ステップを追加]** を選択して、追加のアクションを追加します。

1. スケールインプロパティを設定します。**[タスクを削除するステップ]** で、次を実行します。

   1. **[Policy Name]** (ポリシー名) にこのポリシーの名前を入力します。

   1. **[CloudWatch アラーム名]** で、CloudWatch アラームを選択します。

   1. **[メトリクスの集計タイプ]** で、選択したメトリクスを定義されたしきい値と比較する方法を選択します。

   1. **[調整タイプ]** で、調整がタスク数の変化に基づくか、タスクの割合の変化に基づくかを選択します。

   1. **[実行するアクション]** で、実行するアクションの値を入力します。

      **[ステップを追加]** を選択して、追加のアクションを追加します。

1. **[クールダウン期間]** には、前回のスケーリングアクティビティが有効になるまで待機する時間を秒単位で入力します。追加ポリシーの場合、スケールアウトアクティビティの終了後、スケーリングポリシーによってスケールインアクティビティがブロックされ、一度にスケールアウトできるタスクの数が制限されます。削除ポリシーの場合、これはスケールインアクティビティの後、別のスケールインアクティビティが開始されるまでに経過する必要がある時間です。

1. **[スケーリングポリシーを作成する]** を選択します。

## AWS CLI
<a name="step-scaling-create-policy-aws-cli"></a>

1. [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) コマンドを使用して、スケーラブルなターゲットとして Amazon ECS サービスを登録します。

1. [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) コマンドを使用して、スケーリングポリシーを作成します。

# スケジュールされたアクションを使用して Amazon ECS サービスをスケールする
<a name="service-autoscaling-schedulescaling"></a>

スケジュールされたスケーリングでは、特定の時間にタスク数を増減するスケジュールアクションを作成することで、予測可能な負荷の変化に基づいてアプリケーションの自動スケーリングを設定できます。これにより、予測可能な負荷の変化に合わせてアプリケーションを事前対応的にスケーリングできます。

これらのスケジュールされたスケーリングアクションにより、コストとパフォーマンスを最適化できます。アプリケーションには、週半ばのトラフィックのピークを処理するのに十分な数のタスクがありますが、それ以外の時間帯にタスクを過剰にプロビジョニングすることはありません。

スケジュールされたスケーリングとスケーリングポリシーを併用して、スケーリングに事前対応型アプローチと即応型アプローチの両方のメリットを得ることができます。スケジュールされたスケーリングアクションの実行後、スケーリングポリシーはタスクをさらにスケールするかどうかの判断を引き続き行うことができます。これは、アプリケーションの負荷を処理するために十分なタスク数を確保する上で役立ちます。アプリケーションは需要に合わせてスケールしますが、現行のキャパシティは、スケジュールされたアクションによって設定された最小タスク数と最大タスク数の範囲内に収まる必要があります。

スケジュールスケーリングは AWS CLI を使用して設定できます。スケジュールに基づくスケーリングの詳細については、「*Application Auto Scaling ユーザーガイド*」の「[スケジュールに基づくスケーリング](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)」を参照してください。

# Amazon ECS サービスの自動スケーリングのスケジュールされたアクションを作成する
<a name="scheduled-action-create-policy"></a>

スケジュールされたアクションを作成して、Amazon ECS でサービスが実行するタスク数を日付と時刻に基づいて増減させます。

## コンソール
<a name="scheduled-action-policy-aws-console"></a>

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。

   [サービス詳細] ページが表示されます。

1. **[サービスの自動スケーリング]** を選択します。

   [サービスの自動スケーリング] ページが表示されます。

1. [サービスの自動スケーリング] を設定していない場合は、**[タスク数の設定]** を選択します。

   **Amazon ECS サービスタスク数** のセクションが表示されます。

   **Amazon ECS サービスタスク数** で、**[サービスの自動スケーリングを使用してサービスの必要なタスク数を調整する]** を選択します。

   **[タスク数セクション]** が表示されます。

   1. **[タスクの最小数]** に、サービスの自動スケーリングで使用するタスクの下限数を入力します。必要な数がこの数を下回ることはありません。

   1. **[最大]** に、サービスの自動スケーリングで使用するタスクの上限数を入力します。必要な数がこの数を超えることはありません。

   1. **[保存]** を選択します。

      [ポリシー] ページが表示されます。

1. **[スケジュールされたアクション]** を選択し、**[作成]** を選択します。

   **[スケジュールされたアクションを作成]** ページが表示されます。

1. **バケット名**に、一意の名前を入力します。

1. [**Time zone (タイムゾーン)**] でタイムゾーンを選択。

   リストされているすべてのタイムゾーンは、IANA タイムゾーンデータベースから取得されます。詳細については、「[List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)」を参照してください。

1. **[開始時刻]** で、アクションが開始される **[日付]** と **[時刻]** を入力します。

   定期的なスケジュールを選択した場合、開始時間によって、定期的なシリーズの最初のスケジュールされたアクションが実行されるタイミングが定義されます。

1. [**Recurrence (反復)**] で、使用可能なオプションの 1 つを選択します。
   + 反復スケジュールに基づいてスケールするには、Amazon ECS がスケジュールされたアクションを実行する頻度を選択します。
     + **[レート]** で始まるオプションを選択した場合、cron 式が作成されます。
     + [**Cron**] を選択した場合は、いつアクションを実行するかを Cron 式を入力します。
   + 1 回だけスケールするには、**[1 回]** を選択します。

1. **[タスク調整]** で、次の操作を行います。
   + **[最小]** で、サービスが実行する最小タスク数を入力します。
   + **[最大]** で、サービスが実行する最大タスク数を入力します。

1. **[スケジュールされたアクションの作成]** を選択してください。

## CLI
<a name="scheduled-action-aws-cli"></a>

次のように AWS CLI を使用して、サービスのスケジュールされたスケーリングポリシーを設定します。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。

**例: 1 回のみスケールするには**  
次の [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html) コマンドを、`--start-time "YYYY-MM-DDThh:mm:ssZ"` と `--MinCapacity` および `--MaxCapacity` オプションのいずれかまたは両方と併用します。

```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scheduled-action-name my-one-time-schedule \
  --start-time 2021-01-30T12:00:00 \
  --scalable-target-action MinCapacity=3,MaxCapacity=10
```

**例: 定期的なスケーリングをスケジュールするには**  
次の [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html) コマンドを使用します。*user-input* を独自の値に置き換えます。

```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scheduled-action-name my-recurring-action \
  --schedule "rate(5 hours)" \
  --start-time 2021-01-30T12:00:00 \
  --end-time 2021-01-31T22:00:00 \
  --scalable-target-action MinCapacity=3,MaxCapacity=10
```

指定された繰り返しスケジュールは、UTC タイムゾーンに基づいて実行されます。別のタイムゾーンを指定するには、次の例のように、`--time-zone` オプションと IANA タイムゾーンの名前を含めます。

```
--time-zone "America/New_York"
```

詳細については、「[List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)」を参照してください。

# 履歴パターンを使用して予測スケーリングで Amazon ECS サービスをスケールする
<a name="predictive-auto-scaling"></a>

予測スケーリングは、トラフィックフローからの過去の負荷データを調べて、日次または週次のパターンを分析します。次に、この分析を使用して将来のニーズを予測し、必要に応じてサービスのタスクをプロアクティブに増やします。

予測自動スケーリングは、以下の状況で最も役立ちます。
+ 周期的なトラフィック - 通常の営業時間にリソースの使用が増加し、夜間や週末にはリソースの使用が減少する。
+ オンとオフを繰り返すワークロードパターン - バッチ処理、テスト、定期的なデータ分析など。
+ 初期化に時間がかかるアプリケーション - スケールアウトイベント中のアプリケーションのパフォーマンスに影響を及ぼし、顕著なレイテンシーを引き起こす可能性がある。

アプリケーションの初期化に時間がかかり、トラフィックが規則的なパターンで増加する場合は、予測スケーリングの使用を検討する必要があります。ターゲット追跡やステップスケーリングなどの動的スケーリングポリシーを単独で使用するのではなく、予測される負荷に応じてタスク数を事前に増やすことで、より迅速にスケールできます。予測スケーリングにより、タスク数が過剰にプロビジョニングされる可能性を回避できるため、コストを削減できる場合もあります。

例えば、営業時間中の使用率が高く、夜間の使用量が少ないアプリケーションを考えてみましょう。各営業日の開始時に、予測スケーリングにより、トラフィックが最初に流入する前にタスクをスケールアウトできます。これにより、使用率の低い期間から高い使用率の期間に移行するときに、アプリケーションの高可用性とパフォーマンスを維持するのに役立ちます。トラフィックの変化に動的スケーリングが反応するのを待つ必要はありません。また、アプリケーションの負荷パターンを確認し、スケジュールされたスケーリングを使用して適切な量のタスクをスケジュールするために時間を費やす必要もありません。

予測スケーリングは、基盤となるコンピューティングキャパシティ (EC2 や Fargate など) のスケーリングとは別にサービスのタスクをスケーリングするサービスレベルの機能です。Fargate の場合、AWS はタスク要件に基づいて基盤となる容量を管理して動的にスケーリングします。EC2 キャパシティーの場合、Auto Scaling グループキャパシティープロバイダーを使用して、タスクのスケーリング要件に基づいて基盤となる EC2 インスタンスを自動的にスケーリングできます。

**Topics**
+ [予測スケーリングの概要](#predictive-auto-scaling-overview)
+ [予測スケーリングポリシーを作成する](predictive-scaling-create-policy.md)
+ [予測スケーリングポリシーの評価](predictive-scaling-graphs.md)
+ [予測を上書きする](predictive-scaling-overriding-forecast-capacity.md)
+ [カスタムメトリクスを使用する](predictive-scaling-custom-metrics.md)

## Amazon ECS における予測スケーリングの仕組み
<a name="predictive-auto-scaling-overview"></a>

ここでは、予測スケーリングの使用に関する考慮事項、その仕組み、制限事項について説明します。

### 予測スケーリングを使用する際の考慮事項
<a name="predictive-auto-scaling-considerations"></a>
+ 予測スケーリングがワークロードに適していることを確認する必要があります。これを確認するには、**予測専用**モードでスケーリングポリシーを設定し、コンソールが推奨する内容を確認します。予測スケーリングの使用を開始する前に、予測とレコメンデーションを評価する必要があります。
+ 予測スケーリングが予測を開始するには、少なくとも 24 時間以上の履歴データが必要です。使用可能な履歴データが多いほど、予測がより効果的になり、2 週間分の履歴データがあると理想的です。また、Amazon ECS サービスを削除して新しいサービスを作成する場合、予測スケーリングによって新しい予測が生成されるまで 24 時間待つ必要があります。これを高速化する 1 つの方法は、カスタムメトリクスを使用して、古い Amazon ECS サービスと新しい Amazon ECS サービス全体のメトリクスを集約することです。
+ アプリケーションのすべての負荷を正確に表し、スケーリングが最も重要なアプリケーションの側面である負荷メトリクスを選択します。
+ 予測スケーリングを使用した動的スケーリングにより、アプリケーションの需要に迅速に対応でき、需要が少ないときにはスケールインし、予期しないトラフィックの増加時にはスケールアウトすることができます。複数のスケーリングポリシーがアクティブな場合、各ポリシーによって希望するタスク数が個別に決定され、希望するタスク数はそれらの最大値に設定されます。
+ ターゲット追跡やステップスケーリングなどの動的スケーリングポリシーと共に予測スケーリングを使用すると、リアルタイムパターンと履歴パターンの両方に基づいてアプリケーションをスケーリングできます。それ自体では、予測スケーリングはタスクをスケールインしません。
+ `register-scalable-target` API を呼び出すときにカスタムロールを使用すると、予測スケーリングポリシーが SLR を有効にした場合にのみ機能することを示すエラーが表示されることがあります。この場合、role-arn なしで再度 `register-scalable-target` を呼び出す必要があります。スケーラブルターゲットを登録する際に SLR を使用し、`put-scaling-policy` API を呼び出します。

### 予測スケーリングの仕組み
<a name="predictive-auto-scaling-details"></a>

予測スケーリングを使用するには、モニタリングおよび分析する CloudWatch メトリクスを指定する予測スケーリングポリシーを作成します。予測スケーリングが将来の値の予測を開始するには、このメトリクスに 24 時間以上のデータが必要です。

ポリシーを作成すると、予測スケーリングは最長過去 14 日間のメトリクスデータの分析を開始し、パターンを特定します。この分析は、今後 48 時間の必要量の時間ごとの予測を生成するために使用されます。最新の CloudWatch データを使用して、6 時間ごとに予測が更新されます。新しいデータを取得すると、予測スケーリングは将来の予測の正確性を継続的に向上させます。

最初に予測スケーリングを有効にしたときは、*予測のみ*モードで実行されます。このモードでは予測を生成しますが、それらの予測に基づいて Amazon ECS サービスをスケールすることはありません。これにより、予測の正確性と適合性を評価できます。`GetPredictiveScalingForecast` API オペレーションまたは AWS マネジメントコンソールを使用して、予測データを表示します。

予測スケーリングの使用を開始する場合は、スケーリングポリシーを*予測とスケーリング*モードに切り替えます。このモードでは、次のことが発生します。

Amazon ECS サービスは、デフォルトでは、その時間の予測に基づいて各時間の開始時にスケールされます。`PutScalingPolicy` API オペレーションで `SchedulingBufferTime` プロパティを使用して、早く開始することを選択できます。これにより、新しいタスクは予測される需要よりも早く起動し、トラフィックを処理する準備が整うまでの時間を確保できます。

### 最大タスク制限
<a name="predictive-scaling-maximum-tasks-limit"></a>

スケーリングのために Amazon ECS サービスを登録する場合、サービスごとに起動できる最大タスク数を定義します。デフォルトでは、スケーリングポリシーが設定されている場合、タスク数をその最大制限を超えて増やすことはできません。

ただし、予測が Amazon ECS サービスの最大タスク数に近づいた場合、または超えた場合に、サービスの最大タスク数を自動的に増やすことを許可できます。

**警告**  
最大タスク数を自動的に増やす場合は注意してください。これにより、増加した最大タスク数がモニタリングおよび管理されていない場合、意図したよりも多くのタスクが起動される可能性があります。増加した最大タスク数は、手動で更新するまで Amazon ECS サービスの新しい通常の最大タスク数になります。最大タスク数は、自動的に元の最大タスク数まで減少しません。

### サポート対象のリージョン
<a name="predictive-auto-scaling-supported-regions"></a>
+ 米国東部 (バージニア北部)
+ 米国東部 (オハイオ)
+ 米国西部 (北カリフォルニア)
+ 米国西部 (オレゴン)
+ アフリカ (ケープタウン)
+ アジアパシフィック (香港)
+ アジアパシフィック (ジャカルタ)
+ アジアパシフィック (ムンバイ)
+ アジアパシフィック (大阪)
+ アジアパシフィック (ソウル)
+ アジアパシフィック (シンガポール)
+ アジアパシフィック (シドニー)
+ アジアパシフィック (東京)
+ カナダ (中部)
+ 中国 (北京)
+ 中国 (寧夏)
+ 欧州 (フランクフルト)
+ 欧州 (アイルランド)
+ 欧州 (ロンドン)
+ 欧州 (ミラノ)
+ ヨーロッパ (パリ)
+ ヨーロッパ (ストックホルム)
+ 中東 (バーレーン)
+ 南米 (サンパウロ)
+ AWS GovCloud (米国東部)
+ AWS GovCloud (米国西部)

# Amazon ECS サービスの自動スケーリングの予測スケーリングポリシーを作成する
<a name="predictive-scaling-create-policy"></a>

予測スケーリングポリシーを作成して、Amazon ECS でサービスが実行するタスク数を履歴データに基づいて増減させます。

**注記**  
新しいサービスは、予測を生成する前に 24 時間以上のデータを提供する必要があります。

## コンソール
<a name="predictive-scaling-policy-aws-console"></a>

1. サービスの作成や更新に使用する標準の IAM アクセス権限に加えて、追加のアクセス権限が必要です。詳細については、「[Amazon ECS のサービス自動スケーリングに必要な IAM アクセス許可](auto-scaling-IAM.md)」を参照してください。

1. ポリシーに使用するメトリクスを決定します。以下のメトリクスが利用可能です。
   +  **[ECSServiceAverageCPUUtilization]** — サービスが使用する平均 CPU 使用率。
   + **[ECSServiceAverageMemoryUtilization]** — サービスが使用する平均メモリ使用率。
   + **[ALBRequestCountPerTarget]** – タスクが受信する 1 分あたりの理想的な平均リクエスト数。

   または、カスタムメトリクスを使用することもできます。次の値を定義する必要があります。
   + 負荷 - アプリケーションのすべての負荷を正確に表し、スケーリングが最も重要なアプリケーションの側面であるメトリクス。
   + スケーリングメトリクス - アプリケーションにとって理想的な使用率を予測するために最適な予測子。

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。

   [サービス詳細] ページが表示されます。

1. **[サービスの自動スケーリング]** を選択し、**[タスクの数を設定]** を選択します。

1. **[Amazon ECS サービスのタスク数]** で、**[自動スケーリングを使用する]** を選択します。

   **[タスク数セクション]** が表示されます。

   1. **[タスクの最小数]** に、サービスの自動スケーリングで使用するタスクの下限数を入力します。必要な数がこの数を下回ることはありません。

   1. **[最大]** に、サービスの自動スケーリングで使用するタスクの上限数を入力します。必要な数がこの数を超えることはありません。

   1. **[保存]** を選択します。

      [ポリシー] ページが表示されます。

1. **[スケーリングポリシーを作成する]** を選択します。

   **[ポリシーを作成する]** ページが表示されます。

1. **[スケーリングポリシータイプ]** で **[予測スケーリング]** を選択します。

1. **[Policy Name]** (ポリシー名) にこのポリシーの名前を入力します。

1. **[メトリクスペア]** で、オプションのリストからメトリクスを選択します。

   **[Application Load Balancer request count per target]** (ターゲットあたりの Application Load Balancer リクエスト数) を選択した場合、**[Target group]** (ターゲットグループ) のターゲットグループを選択します。**[ターゲットあたりの Application Load Balancer リクエスト数]** は、Application Load Balancer ターゲットグループをサービスにアタッチしている場合にのみサポートされます。

   **[カスタムメトリクスペア]** を選択した場合、**[負荷のメトリクス]** と **[スケーリングのメトリクス]** のリストから個々のメトリクスを選択します。

1. **[ターゲット使用率]** には、Amazon ECS が維持するタスクの割合のターゲット値を入力します。サービスの自動スケーリングは、平均使用率が目標使用率になるまで、または指定した最大タスク数に達するまで、キャパシティをスケールアウトします。

1. **[スケーリングポリシーを作成する]** を選択します。

## AWS CLI
<a name="predictive-scaling-policy-aws-cli"></a>

次のように AWS CLI を使用して、Amazon ECS サービスの予測スケーリングポリシーを設定します。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。

指定できる CloudWatch メトリクスの詳細については、「*Amazon EC2 Auto Scaling API リファレンス*」の「[PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)」を参照してください。

### 例 1: メモリが事前定義された予測スケーリングポリシー。
<a name="predictive-scaling-cli-example-one"></a>

以下は、メモリ設定が事前定義されたポリシーの例です。

```
cat policy.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 40,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ECSServiceMemoryUtilization"
            }
        }
    ],
    "SchedulingBufferTime": 3600,
    "MaxCapacityBreachBehavior": "HonorMaxCapacity",
    "Mode": "ForecastOnly"
}
```

以下の例は、設定ファイルを指定し [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) コマンドを実行して、ポリシーを作成する方法を示しています。

```
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```

成功した場合、このコマンドはポリシーの ARN を返します。

```
{
    "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
    "Alarms": []
}
```

### 例 2: CPU が事前定義された予測スケーリングポリシー。
<a name="predictive-scaling-cli-example-two"></a>

以下は、CPU 設定が事前定義されたポリシーの例です。

```
cat policy.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 0.00000004,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ECSServiceCPUUtilization"
            }
        }
    ],
    "SchedulingBufferTime": 3600,
    "MaxCapacityBreachBehavior": "HonorMaxCapacity",
    "Mode": "ForecastOnly"
}
```

以下の例は、設定ファイルを指定し [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) コマンドを実行して、ポリシーを作成する方法を示しています。

```
aws aas put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```

成功した場合、このコマンドはポリシーの ARN を返します。

```
{
    "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
    "Alarms": []
}
```

# Amazon ECS の予測スケーリングポリシーの評価
<a name="predictive-scaling-graphs"></a>

予測スケーリングポリシーを使用してサービスをスケールする前に、Amazon ECS コンソールでポリシーの推奨事項とその他のデータを確認します。予測が正確であることがわかるまで、予測スケーリングポリシーが実際のキャパシティをスケーリングすることが好ましくないため、これは重要です。

サービスが新しい場合は、最初の予測の作成に 24 時間かかります。

AWS が予測を作成するとき、履歴データを使用します。サービスに最新の履歴データがまだ十分にない場合、予測スケーリングは現在使用可能な履歴集計から作成された集計で予測を一時的にバックフィルすることがあります。予測は、ポリシーの作成日より最大 2 週間前にバックフィルされます。

## 予測スケーリングの推奨事項の表示
<a name="view-predictive-scaling-recommendations"></a>

分析を効果的に行うには、サービスの自動スケーリングに比較対象となる予測スケーリングポリシーが少なくとも 2 つ必要です。(ただし、単一ポリシーの結果を確認することはできます) 複数のポリシーを作成するとき、1 つのメトリクスを使用するポリシーを異なるメトリクスを使用するポリシーと比較して評価できます。異なる目標値およびメトリクスの組み合わせによる影響を評価することもできます。予測スケーリングポリシーが作成された後、Amazon ECS は、どのポリシーがグループのスケーリングに適しているかについて、すぐに評価を開始します。

**Amazon ECS コンソールで推奨事項を表示するには**

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。

   [サービス詳細] ページが表示されます。

1. **[サービスの自動スケーリング]** を選択します。

1. 予測スケーリングポリシーを選択し、**[アクション]**、**[予測スケーリング]**、**[レコメンデーションの表示]** を選択します。

   ポリシーの詳細と推奨事項を表示できます。推奨事項は、予測スケーリングポリシーを使用しない場合よりも優れた性能を発揮するかどうかについて説明します。

   予測スケーリングポリシーがグループに適切かどうかが不明な場合、**[可用性への影響]** 列および **[コストへの影響]** 列を確認し、適切なポリシーを選択してください。各列の情報は、ポリシーの影響について説明します。
   + **[可用性への影響]**: ポリシーを使用しない場合と比較し、ワークロードを処理するために十分なタスクをプロビジョニングすることにより、ポリシーが可用性への悪影響を回避できるかどうかについて説明します。
   + **[コストへの影響]**: ポリシーを使用しない場合と比較し、タスクを過剰にプロビジョニングしないことにより、ポリシーがコストへの悪影響を回避できるかどうかについて説明します。過剰にプロビジョニングしすぎると、サービスが十分に活用されない、またはアイドル状態になり、コストへの影響が増す一方です。

   複数のポリシーがある場合、より低コストで最も可用性のメリットが高いポリシーの名前の横に **[最良予測]** タグが表示されます。可用性への影響がより重視されます。

1. (オプション) 推奨結果の必要な期間を選択するには、**[評価期間]** のドロップダウンから **[2 日]**、**[1 週間]**、または **[2 週間]** のいずれか希望する値を選択します。デフォルトでは、評価期間は過去の 2 週間です。評価期間が長いほど、推奨結果のデータポイントが増えます。ただし、需要が非常に高い時期の後など、負荷パターンが変化した場合、データポイントを追加しても結果が改善されない可能性があります。この場合、最新のデータを見ることでより焦点を絞った推奨事項を得ることができます。

**注記**  
推奨事項は **[予測のみ]** モードのポリシーに対してのみ生成されます。推奨機能は、評価期間中にポリシーが **[予測のみ]** モードのときにより効果的に機能します。ポリシーを **[予測とスケーリング]** モードで開始し、後で **[予測のみ]** モードに切り替える場合、そのポリシーの結果に偏りが生じる可能性があります。これは、ポリシーが既に実際のキャパシティに関与しているためです。

## 予測スケーリングのモニタリンググラフの確認
<a name="review-predictive-scaling-monitoring-graphs"></a>

コンソールでは、以前の日、週間、月の予測を確認し、時間の経過と共にポリシーがどの程度機能しているか視覚化できます。また、ポリシーが実際のタスク数をスケールするかどうかを決定するとき、この情報を使用して予測の精度を評価できます。

**Amazon ECS コンソールで予測スケーリングのモニタリンググラフを表示するには**

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。

   [サービス詳細] ページが表示されます。

1. **[サービスの自動スケーリング]** を選択します。

1. 予測スケーリングポリシーを選択し、**[アクション]**、**[予測スケーリング]**、**[グラフの表示]** を選択します。

1. **[モニタリング]** セクションでは、ポリシーの負荷およびキャパシティに関する過去および今後の予測を実際の値と比較できます。**[負荷]** グラフには、選択した負荷メトリクスの負荷予測および実際の値が表示されます。**[キャパシティ]** グラフには、ポリシーによって予測されたタスク数が表示されます。実際に起動されたタスク数も含まれます。縦線は履歴の値と今後の予測を区切っています。これらのグラフは、ポリシーの作成後にすぐ利用できます。

1. (オプション) グラフに表示される履歴データの量を変更するには、ページ上部の **[評価期間]** のドロップダウンから希望する値を選択します。評価期間はこのページのデータをはいかなる方法で変換することはありません。表示される履歴データの量のみを変更します。

****[負荷]** グラフのデータを比較**  
各水平線は、1 時間間隔で報告される異なる一連のデータポイントを表しています。

1. **[実際に観測された負荷]** は、選択した負荷メトリクスの SUM 統計を使用し、過去の 1 時間ごとの合計負荷を表示します。

1. **[ポリシーによって予測される負荷]** は、1 時間ごとの負荷予測を表示します。この予測は過去 2 週間分の実際の負荷観測に基づいています。

****[キャパシティ]** グラフのデータの比較**  
各水平線は、1 時間間隔で報告される異なる一連のデータポイントを表しています。

1. **[実際に観測されたタスク数]** には、Amazon ECS サービスの過去の実際のキャパシティが表示されます。これは、他のスケーリングポリシーや、選択した期間に有効な最小グループサイズによって異なります。

1. **[ポリシーによって予測されるキャパシティ]** には、ポリシーが **[予測とスケーリング]** モードになっているときに各時間の開始時に予想されるベースラインキャパシティが表示されます。

1. **[推定される必要タスク数]** には、スケーリングメトリクスを選択したターゲット値に維持するためのサービス内の理想的なタスク数が表示されます。

1. **[最小タスク数]** には、サービス内の最小タスク数が表示されます。

1. **[最大キャパシティ]** には、サービス内の最大タスク数が表示されます。

推定される必要キャパシティを計算するため、最初は各タスクが指定された目標値で均等に使用されていると仮定します。実際には、タスク数は均等に使用されません。ただし、使用率がタスク間で均等に分散されていると仮定することにより、必要なキャパシティの量を推定できます。次に、タスク数の要件は、予測スケーリングポリシーに使用したスケーリングメトリクスに反比例するように計算されます。つまり、タスク数が増加するにつれ、スケーリングメトリクスは同じ割合で減少します。例えば、タスク数が 2 倍になった場合、スケーリングメトリクスは半減します。

推定された必要キャパシティの計算式は、次のとおりです。

 `sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)`

例えば、特定の時間の `actualServiceUnits` (`10`) および `scalingMetricValue` (`30`) を算出します。その後、予測スケーリングポリシー (`60`) で指定した `targetUtilization` を使用し、同じ時間に推定される必要キャパシティを計算します。これは `5` の値を返します。これは、スケーリングメトリクスの目標値とは正反比例し、キャパシティを維持するために必要なキャパシティの推定量は 5 であることを意味します。

**注記**  
コスト削減およびアプリケーションの可用性を調整および改善するため、さまざまな手段が用意されています。  
ベースラインキャパシティに予測スケーリングを使用し、追加のキャパシティに動的スケーリングを使用します。動的スケーリングは予測スケーリングとは独立して動作し、現在の使用率に基づいてスケールインおよびスケールアウトを行います。まず、Amazon ECS は、スケジュールされていないスケーリングポリシーごとに推奨されるタスク数を計算します。次に、最も多くのタスクを提供するポリシーに基づいてスケーリングします。
負荷が減少したときにスケールインできるようにするには、サービスに、スケールイン部分を有効にした動的スケーリングポリシーが常に少なくとも 1 つ必要です。
最小キャパシティおよび最大キャパシティを制限しすぎないようにすることにより、スケーリングパフォーマンスを向上させることができます。推奨されるタスク数が最小キャパシティおよび最大キャパシティの範囲に収まらないポリシーは、スケールインおよびスケールアウトができなくなります。

# CloudWatch による Amazon ECS の予測スケーリングメトリクスをモニタリングする
<a name="predictive-scaling-monitoring"></a>

Amazon CloudWatch を使用して、予測スケーリング用にデータをモニタリングできます。予測スケーリングポリシーは、今後の負荷を予測するために使用されるデータを収集します。収集されたデータは、定期的に CloudWatch に自動的に保存され、ポリシーが時間の経過と共にどの程度機能しているかを視覚化するために使用できます。また、CloudWatch アラームを作成して、パフォーマンス指標が定義した制限を超えて変化したときに通知させることもできます。

## 履歴予測データの視覚化
<a name="visualize-historical-forecast-data"></a>

予測スケーリングポリシーの負荷予測データは CloudWatch で表示でき、他の CloudWatch メトリクスに対する予測を 1 つのグラフで視覚化する場合に役立ちます。また、より広い時間範囲を表示することで、時間の経過に伴う傾向を確認することもできます。最大 15 か月間の履歴メトリクスにアクセスして、ポリシーの動作をより的確に把握できます。

**CloudWatch コンソールを使用して履歴予測データを表示する方法**

1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。

1. ナビゲーションペインで、**[Metrics]** (メトリクス)、**[All metrics]** (すべてのメトリクス) の順に選択します。

1. **[アプリケーションの自動スケーリング]** メトリクス名前空間を選択します。

1. **[予測スケーリングの負荷予測]** を選択します。

1. 検索フィールドに、予測スケーリングポリシー名または Amazon ECS サービスグループ名を入力し、Enter キーを押して結果をフィルタリングします。

1. メトリクスをグラフ表示するには、メトリクスの横にあるチェックボックスを選択します。グラフの名前を変更するには、鉛筆アイコンを選択します。時間範囲を変更するには、事前定義済みの値を選択するか、[**custom**] を選択します。詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[メトリクスをグラフ化する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html)」を参照してください。

1. 統計を変更するには、[**Graphed metrics**] タブを選択します。列見出しまたは個々の値を選択し、続いて各種統計を選択します。各メトリクスの任意の統計を選択できますが、すべての統計が **[PredictiveScalingLoadForecast]** メトリクスに有用なわけではありません。例えば、**平均**、**最小**、**最大**の各統計は有用ですが、**合計**の統計は有用ではありません。

1. グラフに別のメトリクスを追加するには、**[Browse]** (参照) で **[All]** (すべて) を選択し、追加したいメトリクスを見つけて、その横にあるチェックボックスをオンにします。最大 10 個のメトリクスを追加できます。

1. (オプション) このグラフを CloudWatch ダッシュボードに追加するには、**[Actions]** (アクション)、**[Add to dashboard]** (ダッシュボードに追加) の順に選択します。

## Metric Math を使用して精度メトリクスを作成する
<a name="create-accuracy-metrics"></a>

Metric Math により、複数の CloudWatch メトリクスをクエリし、数式を使用して、これらのメトリクスに基づく新しい時系列を作成できます。作成された時系列を CloudWatch コンソールで可視化でき、ダッシュボードに追加できます。メトリクス演算の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch メトリクスでの数式の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)」を参照してください。

Metric Math を使用して、サービス自動スケーリングが予測スケーリングのために生成するデータを各種の方法でグラフ化できます。これにより、ポリシーのパフォーマンスを経時的にモニタリングし、メトリクスの組み合わせを改善できるかどうかを把握することができます。

例えば、Metric Math 式を使用して、[平均絶対パーセント誤差](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error) (MAPE) をモニタリングできます。MAPE メトリクスは、予測値と、特定の予測期間中に観測された実際の値の差をモニタリングするのに役立ちます。MAPE の値の変化は、アプリケーションの性質が変化するにつれて、ポリシーのパフォーマンスが経時的に低下しているかどうかを示します。MAPE の増加は、予測値と実際の値の差が大きいことを示します。

**例: Metric Math 式**

このタイプのグラフを使用するには、次の例に示すような Metric Math 式を作成します。



単一のメトリクスではなく、`MetricDataQueries` 用のメトリクスデータクエリ構造の配列があります。`MetricDataQueries` の各項目は、メトリクスを取得するか、数式を実行します。最初の項目は、数式である `e1` です。指定された式は、`ReturnData` パラメータを `true` に設定し、最終的に単一の時系列を生成します。他のすべてのメトリクスで、`ReturnData` 値は `false` です。

この例では、指定された式は実際の値と予測値を入力値として使用し、新しいメトリクス (MAPE) を返します。`m1` は、実際の負荷値を含む CloudWatch メトリクスです (CPU 使用率が、`my-predictive-scaling-policy` という名前のポリシーに対して最初に指定された負荷メトリクスであると仮定)。`m2` は、予測負荷値を含む CloudWatch メトリクスです。MAPE メトリクスの計算構文は次のとおりです。

(絶対値 ((実際の値 - 予測値)/(実際の値))) の平均

### 精度メトリクスを視覚化してアラームを設定する
<a name="visualize-accuracy-metrics-set-alarms"></a>

精度メトリクスデータを視覚化するには、CloudWatch コンソールの **[Metrics]** (メトリクス) タブをクリックします。そこからデータをグラフ化できます。詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch グラフに数式を追加する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console)」を参照してください。

**[Metrics]** (メトリクス) セクションから、モニタリングしているメトリクスにアラームを設定することもできます。**[Graphed metrics]** (グラフ化したメトリクス) タブで、**[Actions]** (アクション) 列にある **[Create alarm]** (アラームを作成) アイコンをクリックします。**[Create alarm]** (アラームを作成) アイコンは小さなベルです。詳細および通知オプションについては、「*Amazon CloudWatch ユーザーガイド*」の「[メトリクス数式に基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html)」と「[アラームの変更をユーザーに通知する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html)」を参照してください。

[GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) および [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) を使用して、Metric Math によって計算し、その出力に基づいてアラームを作成することもできます。

# スケジュールされたアクションを使用して Amazon ECS の予測値を上書きする
<a name="predictive-scaling-overriding-forecast-capacity"></a>

予測計算では考慮できない将来のアプリケーション要件に関する追加情報がある場合があります。例えば、予測の計算では、今後のマーケティングイベントに必要なタスクが過小評価される可能性があります。スケジュールされたアクションを使用して、将来の期間中の予測を一時的に上書きできます。スケジュールされたアクションは、繰り返し実行することも、1 回限りの需要変動がある特定の日時に実行することもできます。

例えば、予測される数よりも多いタスク数でスケジュールされたアクションを作成できます。実行時に、Amazon ECS はサービス内の最小タスク数を更新します。予測スケーリングはタスクの数に合わせて最適化するので、予測値を超える最小タスクの数でスケジュールされたアクションが尊重されます。これにより、タスクの数が予想を下回らないようになります。予測の上書きを停止するには、2 番目にスケジュールされたアクションを使用して、最小タスク数を元の設定に戻します。

次の手順では、将来の期間中の予測を上書きするステップを示します。

**Topics**
+ [ステップ 1: (オプション) 時系列データを分析する](#analyzing-time-series-data)
+ [ステップ 2: 2 つのスケジュールされたアクションを作成する](#scheduling-capacity)

**重要**  
このトピックでは、予測を上書きして、予測よりも大きなキャパシティにスケールしようとしていることを前提としています。予測スケーリングポリシーの干渉なしに一時的にタスク数を減らす必要がある場合は、代わりに *予測のみ* モードを使用します。予測のみモードでは、予測スケーリングは予測を生成し続けますが、自動的にタスク数を増やすことはありません。その後、リソース使用率をモニタリングし、必要に応じてタスク数を手動で減らすことができます。

## ステップ 1: (オプション) 時系列データを分析する
<a name="analyzing-time-series-data"></a>

まず、予測時系列データを分析します。これはオプションのステップですが、予測の詳細を理解したい場合に役立ちます。

1. **予測を取得する**

   予測が作成されたら、予測の特定の期間をクエリできます。このクエリの目的は、特定の期間の時系列データの完全なビューを取得することです。

   クエリには、将来の予測データを最大 2 日間含めることができます。予測スケーリングをしばらく使用している場合は、過去の予測データにアクセスすることもできます。ただし、開始時刻と終了時刻の間の最大期間は 30 日間です。

   [get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI コマンドを使用して予測を取得するには、コマンドに次のパラメータを指定します。
   + `resource-id` パラメータにクラスター名を入力します。
   + ポリシーの名前を `--policy-name` パラメータに入力します。
   + 開始時刻を `--start-time` パラメータに入力して、指定した時刻以降の予測データのみが返されるようにします。
   + 終了時刻を `--end-time` パラメータに入力して、指定された時刻より前の予測データのみが返されるようにします。

   ```
   aws application-autoscaling get-predictive-scaling-forecast \
       --service-namespace ecs \
       --resource-id service/MyCluster/test \
       --policy-name cpu40-predictive-scaling-policy \
       --scalable-dimension ecs:service:DesiredCount \
       --start-time "2021-05-19T17:00:00Z" \
       --end-time "2021-05-19T23:00:00Z"
   ```

   成功すると、コマンドは次の例のようなデータを返します。

   ```
   {
       "LoadForecast": [
           {
               "Timestamps": [
                   "2021-05-19T17:00:00+00:00",
                   "2021-05-19T18:00:00+00:00",
                   "2021-05-19T19:00:00+00:00",
                   "2021-05-19T20:00:00+00:00",
                   "2021-05-19T21:00:00+00:00",
                   "2021-05-19T22:00:00+00:00",
                   "2021-05-19T23:00:00+00:00"
               ],
               "Values": [
                   153.0655799339254,
                   128.8288551285919,
                   107.1179447150675,
                   197.3601844551528,
                   626.4039934516954,
                   596.9441277518481,
                   677.9675713779869
               ],
               "MetricSpecification": {
                   "TargetValue": 40.0,
                   "PredefinedMetricPairSpecification": {
                       "PredefinedMetricType": "ASGCPUUtilization"
                   }
               }
           }
       ],
       "CapacityForecast": {
           "Timestamps": [
               "2021-05-19T17:00:00+00:00",
               "2021-05-19T18:00:00+00:00",
               "2021-05-19T19:00:00+00:00",
               "2021-05-19T20:00:00+00:00",
               "2021-05-19T21:00:00+00:00",
               "2021-05-19T22:00:00+00:00",
               "2021-05-19T23:00:00+00:00"
           ],
           "Values": [
               2.0,
               2.0,
               2.0,
               2.0,
               4.0,
               4.0,
               4.0
           ]
       },
       "UpdateTime": "2021-05-19T01:52:50.118000+00:00"
   }
   ```

   応答には `LoadForecast` と `CapacityForecast` の 2 つの予測が含まれています。`LoadForecast` は、時間ごとの負荷予測を示します。`CapacityForecast` は、40.0 の `TargetValue` (平均 CPU 使用率 40%) を維持しながら予測された負荷を処理するために時間単位で必要なキャパシティーの予測値を示します。

1. **ターゲット期間を特定する**

   1 回限りの需要変動が発生する時間または時間範囲を特定します。予測に表示される日付と時刻は UTC であることに注意してください。

## ステップ 2: 2 つのスケジュールされたアクションを作成する
<a name="scheduling-capacity"></a>

次に、アプリケーションの負荷が予測を上回る特定の期間に、2 つのスケジュールされたアクションを作成します。例えば､マーケティングイベントで一時的にトラフィックがサイトに流入する場合は、1 回限りのアクションをスケジュールして、開始時に最小キャパシティーを更新できます。次に、イベント終了時に最小キャパシティーを元の設定に戻す別のアクションをスケジュールします。

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。

   [サービス詳細] ページが表示されます。

1. **[サービスの自動スケーリング]** を選択します。

   [ポリシー] ページが表示されます。

1. **[スケジュールされたアクション]** を選択し、**[作成]** を選択します。

   **[スケジュールアクションの作成]** ページが表示されます。

1. **バケット名**に、一意の名前を入力します。

1. [**Time zone (タイムゾーン)**] でタイムゾーンを選択。

   リストされているすべてのタイムゾーンは、IANA タイムゾーンデータベースから取得されます。詳細については、「[List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)」を参照してください。

1. **[開始時刻]** で、アクションが開始される **[日付]** と **[時刻]** を入力します。

1. [繰り返し] で、[1 回] を選択してください。********

1. **[タスク調整]** の [最小] には、タスクの最大数以下の値を入力します。

1. **[スケジュールされたアクションの作成]** を選択してください。

   [ポリシー] ページが表示されます。

1. イベントの終了時に、最小タスク数を元の設定に戻すように、2 番目にスケジュールされたアクションを設定します。予測スケーリングでは、**[最小]** に設定した値が予測値未満の場合のみ、タスク数をスケーリングできます。

**1 回限りのイベントに対して 2 つのスケジュールされたアクションを作成するには (AWS CLI)**  
AWS CLI を使用してスケジュールされたアクションを作成するには、[put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) コマンドを使用します。

例えば、5 月 19 日の午後 5 時から 8 時間、最小キャパシティーを 3 インスタンスに維持するスケジュールを定義しましょう。以下のコマンドは、このシナリオを実装する方法を示しています。

最初の [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) コマンドは、2021 年 5 月 19 日の午後 5 時 (UTC) に指定された Auto Scaling グループの最小キャパシティーを更新するように Amazon EC2 Auto Scaling に指示します。

```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \
  --auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3
```

2 番目のコマンドは、2021 年 5 月 20 日の午前 1 時 (UTC) にグループの最小キャパシティーを 1 に設定するように Amazon EC2 Auto Scaling に指示します。

```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \
  --auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1
```

これらのスケジュールされたアクションを Auto Scaling グループに追加すると、Amazon EC2 Auto Scaling は次の処理を実行します。
+ 2021 年 5 月 19 日の午後 5 時 (UTC) に、最初にスケジュールされたアクションが実行されます。グループのインスタンスが 3 未満である場合、グループは 3 インスタンスにスケールアウトされます。この時刻以降の 8 時間の間、予測キャパシティーが実際のキャパシティーよりも大きい場合、または動的スケーリングポリシーが有効な場合、Amazon EC2 Auto Scaling は引き続きスケールアウトできます。
+ 2021 年 5 月 20 日の午前 1 時 (UTC) に、2 番目のスケジュールされたアクションが実行されます。これにより、イベントの終了時に最小キャパシティーが元の設定に戻ります。

### 繰り返し起こるスケジュールに基づくスケーリング
<a name="scheduling-recurring-actions"></a>

毎週同じ期間の予測を上書きするには、2 つのスケジュールされたアクションを作成し、cron 式を使用して日時のロジックを指定します。

この cron 式のフォーマットは、スペースで区切られた 5 つのフィールド ([分] [時間] [日] [月] [曜日]) で構成されます。フィールドには、特殊文字を含む任意の許容される値を含めることができます。

例えば、次の cron 式は、毎週火曜日の午前 6:30 にアクションを実行します。アスタリスクは、フィールドのすべての値を照合するワイルドカードとして使用されます。

```
30 6 * * 2
```

### 関連情報
<a name="scheduling-scaling-see-also"></a>

スケジュールされたアクションを管理する方法の詳細については、「[スケジュールされたアクションを使用して Amazon ECS サービスをスケールする](service-autoscaling-schedulescaling.md)」を参照してください。

# Amazon ECS のカスタムメトリクスを使用した高度な予測スケーリングポリシー
<a name="predictive-scaling-custom-metrics"></a>

予測スケーリングポリシーで、事前定義されたメトリクスまたはカスタムメトリクスを使用できます。カスタムメトリクスは、CPU、メモリなどの事前定義されたメトリクスが、アプリケーションの負荷を十分に記述するには不十分である場合に有用です。

カスタムメトリクスを使用して予測スケーリングポリシーを作成するときは、AWS が提供するその他の CloudWatch メトリクスを指定できます。または、自分で定義して公開するメトリクスを指定することもできます。メトリクス計算を使用して既存のメトリクスを集計し、AWS が自動的に追跡しない新しい時系列に変換することもできます。例としては、新しい合計や平均を計算してデータ内の値を結合すること (*集計*と呼ばれます) が挙げられます。結果のデータは*集計*と言います。

以下のセクションには、ポリシー用の JSON 構造を構築する方法のベストプラクティスと例が記載されています。

## 前提条件
<a name="predictive-scaling-custom-metrics-prerequisites"></a>

予測スケーリングポリシーにカスタムメトリクスを追加するには、`cloudwatch:GetMetricData` 許可が必要です。

AWS が提供するメトリクスの代わりに独自のメトリクスを指定するには、まずそのメトリクスを CloudWatch に発行する必要があります。詳細については、「Amazon CloudWatch ユーザーガイド」の「[カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)」を参照してください。

独自のメトリクスを発行するときは、少なくとも 5 分間隔の頻度でデータポイントを発行するようにしてください。データポイントは、必要な期間の長さに基づいて CloudWatch から取得されます。例えば、負荷メトリクスの指定では、時間単位のメトリクスを使用してアプリケーションの負荷を測定します。CloudWatch は、発行されたメトリクスデータを使用して、各 1 時間の期間内にタイムスタンプがあるすべてのデータポイントを集計することにより、各 1 時間の期間に対して単一のデータ値を提供します。

## ベストプラクティス
<a name="predictive-scaling-custom-metrics-best-practices"></a>

次のベストプラクティスは、カスタムメトリクスをより効果的に使用するのに役立ちます。
+ 負荷メトリクス仕様で最も有用なメトリクスは、Auto Scaling グループ全体の負荷を表すメトリクスです。
+ スケーリングメトリクス仕様のスケールに最も有用なメトリクスは、タスクメトリクスごとの平均スループットまたは使用率です。
+ ターゲット使用率は、スケーリングメトリクスのタイプと一致する必要があります。例えば、CPU 使用率を使用するポリシー設定の場合、これはパーセンテージのターゲットです。
+ これらの推奨事項に従わない場合、予測される将来の時系列の値は、多くの場合、誤りになります。データが正しいことを確認するために、コンソールで予測値を表示できます。または、予測スケーリングポリシーを作成した後、[GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html) API を呼び出して返された `LoadForecast` オブジェクトを検査します。
+ 予測スケーリングがアクティブスケーリングを開始する前に予測を評価できるように、予測のみモードで予測スケーリングを設定することを強くお勧めします。

## 制限事項
<a name="predicitve-scaling-custom-metrics-limitations"></a>
+ 1 つのメトリクス指定で最大 10 個のメトリクスのデータポイントをクエリできます。
+ この制限に関しては、1 つの式は 1 つのメトリクスとしてカウントされます。

## カスタムメトリクスを使用した予測スケーリングポリシーのトラブルシューティング
<a name="predictive-scaling-custom-metrics-troubleshooting"></a>

カスタムメトリクスの使用中に問題が発生した場合は、次の操作を実行することをお勧めします。
+ 検索式の使用中にブルー/グリーンデプロイで問題が発生した場合は、完全一致ではなく部分一致を検索する検索式を作成してください。また、クエリが特定のアプリケーションで実行されている Auto Scaling グループのみを検索していることも確認する必要があります。検索式の構文の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch 検索式の構文](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html)」を参照してください。
+ [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) コマンドは、スケーリングポリシーの作成時に式を検証します。ただし、このコマンドでは、検出されたエラーの正確な原因を特定できない可能性があります。問題を解決するには、[get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) コマンドへのリクエストからの応答で受け取ったエラーをトラブルシューティングします。CloudWatch コンソールから式をトラブルシューティングすることもできます。
+ `MetricDataQueries` で SUM() のような数学関数を使用せずに、独自の SEARCH() 関数を指定する場合、`ReturnData` に `false` を指定する必要があります。これは、検索式が複数の時系列を返す可能性がある一方、数式に基づくメトリクス指定は 1 つの時系列しか返すことができないためです。
+ 検索式に含まれるすべてのメトリクスは、同じ解像度である必要があります。

# Amazon ECS を使用した予測スケーリングカスタムメトリクス用の JSON の構築
<a name="predictive-scaling-custom-metrics-example"></a>

以下のセクションには、CloudWatch からのデータをクエリするための予測スケーリングを設定する方法の例が記載されています。このオプションの設定には 2 つの異なる手法あり、予測スケーリングポリシーの JSON を構築するために使用する形式は、選択される手法の影響を受けます。メトリクス計算を使用する場合は、実行されるメトリクス計算に基づいて JSON の形式がさらに多様化します。

1. AWS が提供するその他の CloudWatch メトリクス、またはユーザーが CloudWatch に発行するメトリクスから直接データを取得するポリシーを作成するには、「[AWS CLI を使用したカスタム負荷メトリクスとスケーリングメトリクスを用いた予測スケーリングポリシーの例](#predictive-scaling-custom-metrics-example1)」を参照してください。

## AWS CLI を使用したカスタム負荷メトリクスとスケーリングメトリクスを用いた予測スケーリングポリシーの例
<a name="predictive-scaling-custom-metrics-example1"></a>

AWS CLI でカスタムロードメトリクスとスケーリングメトリクスを使用する予測スケーリングポリシーを作成するには、`config.json` という名前の JSON ファイルに `--predictive-scaling-configuration` の引数を保存します。

カスタムメトリクスの追加は、以下の例にある置き換え可能な値を独自のメトリクスとターゲット使用率に置き換えることによって開始します。

```
{
  "MetricSpecifications": [
    {
      "TargetValue": 50,
      "CustomizedScalingMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "scaling_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "MyUtilizationMetric",
                "Namespace": "MyNameSpace",
                "Dimensions": [
                  {
                    "Name": "MyOptionalMetricDimensionName",
                    "Value": "MyOptionalMetricDimensionValue"
                  }
                ]
              },
              "Stat": "Average"
            }
          }
        ]
      },
      "CustomizedLoadMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "load_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "MyLoadMetric",
                "Namespace": "MyNameSpace",
                "Dimensions": [
                  {
                    "Name": "MyOptionalMetricDimensionName",
                    "Value": "MyOptionalMetricDimensionValue"
                  }
                ]
              },
              "Stat": "Sum"
            }
          }
        ]
      }
    }
  ]
}
```

詳細については、「*Amazon EC2 Auto Scaling API Reference*」の「[MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)」を参照してください。

**注記**  
以下は、CloudWatch メトリクスのメトリクス名、名前空間、ディメンション、および統計を見つけるために役立つ追加のリソースです。  
AWS のサービスで使用可能なメトリクスの詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch メトリクスを発行する AWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html)」を参照してください。
CloudWatch メトリクスの正確なメトリクス名、名前空間、ディメンション (該当する場合) を AWS CLI で取得するには、「[list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html)」を参照してください。

このポリシーを作成するには、以下の例にあるように、JSON ファイルを入力として使用して [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) コマンドを実行します。

```
aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \
  --auto-scaling-group-name my-asg --policy-type PredictiveScaling \
  --predictive-scaling-configuration file://config.json
```

成功した場合、このコマンドはポリシーの Amazon リソースネーム (ARN) を返します。

```
{
  "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy",
  "Alarms": []
}
```

# Metric Math 式を使用する
<a name="predictive-scaling-math-expression"></a>

以下のセクションでは、ポリシー内の予測スケーリングポリシーで Metric Math を使用する方法について説明します。

## Metric Math について
<a name="predictive-scaling-custom-metrics-math"></a>

既存のメトリクスデータの集計だけを行いたい場合は、CloudWatch Metric Math により、別のメトリクスを CloudWatch に発行する手間とコストを節約できます。AWS が提供するメトリクスはすべて使用できます。また、アプリケーションの一部として定義したメトリクスを使用することもできます。

詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[Amazon CloudWatch メトリクス数学の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)」を参照してください。

予測スケーリングポリシーで Metric Math の数式を使用する場合は、次の点を考慮してください。
+ Metric Math 演算では、メトリクスのメトリクス名、名前空間、ディメンションのキーと値のペアの一意の組み合わせのデータポイントを使用します。
+ 任意の算術演算子 (\$1 - \$1 / ^)、統計関数 (AVG や SUM など)、または CloudWatch がサポートするその他の関数を使用できます。
+ 数式の関係式では、メトリクスと他の数式の結果の両方を使用できます。
+ Metric Math の数式は、さまざまな集計で構成できます。ただし、最終的な集計結果として、`Average` をスケーリングメトリクスに使用し、`Sum` を負荷メトリクスに使用するのがベストプラクティスです。
+ メトリクスの指定で使用される数式はすべて、最終的に単一の時系列を返す必要があります。

Metric Math を使用するには、次の操作を実行します。
+ 1 つまたは複数の CloudWatch メトリクスを選択します。次に、数式を作成します。詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[Amazon CloudWatch メトリクス数学の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)」を参照してください。
+ CloudWatch コンソールまたは CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API を使用して、Metric Math の数式が有効であることを確認します。

## メトリクス計算を使用してメトリクスを組み合わせる予測スケーリングポリシーの例 (AWS CLI)
<a name="custom-metrics-ex2"></a>

場合によっては、メトリクスを直接指定するのではなく、まず何らかの方法でそのデータを処理する必要がある場合があります。例えば、Amazon SQS キューから作業を取り出すアプリケーションがあり、キュー内の項目数を予測スケーリングの基準として使用したいとします。キューにあるメッセージの数だけでは、必要なインスタンスの数は定義されません。インスタンスごとのバックログを計算するために使用できるメトリクスを作成するには、さらに多くの作業が必要です。

このシナリオの予測スケーリングポリシー例を次に示します。Amazon SQS `ApproximateNumberOfMessagesVisible` メトリクス (キューから取得可能なメッセージの数) に基づくスケーリングメトリクスおよび負荷メトリクスを指定します。Amazon EC2 Auto Scaling `GroupInServiceInstances` メトリクスと、スケーリングメトリクスのインスタンスごとのバックログを計算するための数式も使用します。

```
aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \
  --policy-type PredictiveScaling \
  --predictive-scaling-configuration file://config.json
  --service-namespace ecs \
  --resource-id service/MyCluster/test \
  "MetricSpecifications": [
    {
      "TargetValue": 100,
      "CustomizedScalingMetricSpecification": {
        "MetricDataQueries": [
          {
            "Label": "Get the queue size (the number of messages waiting to be processed)",
            "Id": "queue_size",
            "MetricStat": {
              "Metric": {
                "MetricName": "ApproximateNumberOfMessagesVisible",
                "Namespace": "AWS/SQS",
                "Dimensions": [
                  {
                    "Name": "QueueName",
                    "Value": "my-queue"
                  }
                ]
              },
              "Stat": "Sum"
            },
            "ReturnData": false
          },
          {
            "Label": "Get the group size (the number of running instances)",
            "Id": "running_capacity",
            "MetricStat": {
              "Metric": {
                "MetricName": "GroupInServiceInstances",
                "Namespace": "AWS/AutoScaling",
                "Dimensions": [
                  {
                    "Name": "AutoScalingGroupName",
                    "Value": "my-asg"
                  }
                ]
              },
              "Stat": "Sum"
            },
            "ReturnData": false
          },
          {
            "Label": "Calculate the backlog per instance",
            "Id": "scaling_metric",
            "Expression": "queue_size / running_capacity",
            "ReturnData": true
          }
        ]
      },
      "CustomizedLoadMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "load_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "ApproximateNumberOfMessagesVisible",
                "Namespace": "AWS/SQS",
                "Dimensions": [
                  {
                    "Name": "QueueName",
                    "Value": "my-queue"
                  }
                ],
              },
              "Stat": "Sum"
            },
            "ReturnData": true
          }
        ]
      }
    }
  ]
}
```

この例では、ポリシーの ARN が返されます。

```
{
  "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy",
  "Alarms": []
}
```

# Amazon ECS サービスを相互接続する
<a name="interconnecting-services"></a>

Amazon ECS タスク内で実行されるアプリケーションは、多くの場合はインターネットからの接続を受信するか、Amazon ECS サービス内で実行される他のアプリケーションに接続する必要があります。インターネットからの外部接続が必要な場合は、Elastic Load Balancing の使用をお勧めします。統合負荷分散の詳細については、「[ロードバランサーを使用して Amazon ECS サービストラフィックを分散する](service-load-balancing.md)」を参照してください。

Amazon ECS サービス内で実行される他のアプリケーションにアプリケーションを接続する必要がある場合、Amazon ECS にはロードバランサーを使用せずに、次の方法で行うことができます。
+ *Amazon ECS Service Connect*

  サービス検出、接続、トラフィックモニタリング用の Amazon ECS 設定を提供する Service Connect をお勧めします。Service Connect を使用すると、アプリケーションは短縮名と標準ポートを使用して、同じクラスターや他のクラスター (同じ AWS リージョン の VPC を含む) 内の Amazon ECS サービスに接続できます。

  Service Connect を使用すると、Amazon ECS がサービス検出のすべての部分を管理します。つまり、検出可能な名前の作成、タスクの開始と終了時に各タスクのエントリを動的に管理すること、名前を検出するように設定された各タスクでのエージェントの実行などです。アプリケーションは DNS 名の標準機能を使用して接続することで名前を検索できます。アプリケーションがすでにこれを実行している場合、Service Connect を使用する際に、アプリケーションを変更する必要はありません。

  各サービスとタスク定義内で完全な設定を行います。Amazon ECS は、デプロイ内のすべてのタスクが同じように動作するように、サービスデプロイごとにこの設定の変更を管理します。たとえば、サービス検出の DNS でよくある問題は、移行の制御です。新しい IP アドレスを指すように DNS 名を変更すると、すべてのクライアントが新しいサービスの使用を開始するまでに最大 TTL 時間がかかることがあります。Service Connect では、クライアントデプロイメントがクライアントタスクを置き換えて設定を更新します。他のデプロイと同様に、Service Connect の変更に影響するように、デプロイサーキットブレーカーやその他のデプロイ設定を設定できます。

  詳細については、「[Service Connect を使用して Amazon ECS サービスを短縮名で接続する](service-connect.md)」を参照してください。
+ Amazon ECS サービス検出

  サービス間の通信のもう 1 つのアプローチは、サービス検出を使用する直接的な通信です。このアプローチでは、Amazon ECS との AWS Cloud Map サービス検出の統合を使用できます。Amazon ECS はサービス検出を使用して、起動されたタスクのリストを AWS Cloud Map に同期します。このホスト名は特定のサービスの 1 つ以上のタスクの内部 IP アドレスに解決される DNS ホスト名を保持します。Amazon VPC の他のサービスは、この DNS ホスト名を使用して、内部 IP アドレスを使用してトラフィックを別のコンテナに直接送信できます。

  このサービス間通信のアプローチでは、レイテンシが低くなります。コンテナ間には余分なコンポーネントはありません。トラフィックは 1 つのコンテナから別のコンテナに直接移動します。

  この方法は、各タスクに固有の IP アドレスが割り当てられる `awsvpc` ネットワークモードを使用する場合に適しています。ほとんどのソフトウェアは、IP アドレスに直接変換される DNS `A` レコードの使用のみをサポートしています。`awsvpc` ネットワークモードを使用する場合、各タスクの IP アドレスは `A` レコードになります。ただし、`bridge` ネットワークモードを使用している場合は、複数のコンテナが同じ IP アドレスを共有している可能性があります。さらに、動的ポートマッピングでは、その 1 つの IP アドレスのポート番号がコンテナにランダムに割り当てられます。この時点では、`A` レコードだけではサービス検出には不十分です。`SRV` レコードも使用する必要があります。このタイプのレコードは IP アドレスとポート番号の両方を記録できますが、アプリケーションを適切に設定する必要があります。使用するビルド済みアプリケーションの中には、`SRV` レコードをサポートしていないものもあります。

  `awsvpc` ネットワークモードのもう 1 つの利点は、サービスごとに固有のセキュリティグループがあることです。このセキュリティ グループを設定して、そのサービスと通信する必要がある特定のアップストリームサービスからの受信接続のみを許可することができます。

  サービス検出を使用するサービス間直接的な通信の主な欠点は、再試行や接続障害に対処するためのロジックを追加する必要があることです。DNS レコードには、キャッシュされる時間を制御する有効期限 (TTL) があります。DNS レコードが更新されてキャッシュが期限切れになり、アプリケーションが最新バージョンの DNS レコードを取得できるようになるまでには、ある程度の時間がかかります。そのため、アプリケーションが DNS レコードを解決して、もう存在しない別のコンテナを指すようになってしまう可能性があります。アプリケーションには再試行を処理し、不正なバックエンドを無視するロジックが必要です。

  詳細については、[サービス検出を使用して Amazon ECS サービスを DNS 名で接続する](service-discovery.md)を参照してください。
+ *Amazon VPC Lattice*

  Amazon VPC Lattice は、Amazon ECS のお客様がコードを変更することなく、AWS コンピューティングサービス、VPC、アカウント全体で構築されたアプリケーションを観察、保護、モニタリングするために使用するマネージドアプリケーションネットワーキングサービスです。

  VPC Lattice は、コンピューティングリソースのコレクションであるターゲットグループを使用します。これらのターゲットは、アプリケーションまたはサービスを実行するものであり、Amazon EC2 インスタンス、IP アドレス、Lambda 関数、Application Load Balancer を含みます。Amazon ECS サービスを VPC Lattice ターゲットグループに関連付けることで、お客様は Amazon ECS タスクを VPC Lattice の IP ターゲットとして有効にできるようになりました。Amazon ECS は、登録されたサービスのタスクが起動されると、VPC Lattice ターゲットグループにタスクを自動的に登録します。

  詳細については、「[Amazon VPC Lattice を使用して Amazon ECS サービスを接続、監視、保護する](ecs-vpc-lattice.md)」を参照してください。

## ネットワークモード互換表
<a name="interconnect-network-mode-compatibility-table"></a>

次の表は、これらのオプションとタスクネットワークモードの互換性を示すものです。この表の「クライアント」とは、Amazon ECS タスク内から接続を行うアプリケーションを指します。


****  

| 相互接続オプション | ブリッジ | `awsvpc` | ホスト | 
| --- | --- | --- | --- | 
| サービス検出 | はい。ただし、クライアントは hostPort を使用せず DNS の SRV レコードを認識する必要があります。 | はい | はい。ただし、クライアントは hostPort を使用せず DNS の SRV レコードを認識する必要があります。 | 
| Service Connect | はい | はい | なし | 
| VPC Lattice | はい | はい | はい | 

# Service Connect を使用して Amazon ECS サービスを短縮名で接続する
<a name="service-connect"></a>

Amazon ECS Service Connect では、Amazon ECS 設定としてサービス間通信を管理できます。Amazon ECS でサービス検出とサービスメッシュの両方を構築します。これにより、サービスのデプロイごとに管理する各サービス内の完全な設定、VPC DNS 設定に依存しない名前空間内のサービスを参照する統一された方法、すべてのアプリケーションを監視するための標準化されたメトリクスとログが提供されます。Service Connect は、サービスのみを相互接続します。

次の図は、VPC に 2 つのサブネットと 2 つのサービスを含む Service Connect ネットワークの例を示しています。各サブネットにつき 1 つのタスクで WordPress を実行するクライアントサービス。各サブネットに 1 つのタスクで MySQL を実行するサーバーサービス。どちらのサービスも、2 つのサブネットに分散された複数のタスクを実行するため、可用性が高く、タスクやアベイラビリティーゾーンの問題に対する耐性があります。実線の矢印は、WordPress から MySQL への接続を示しています。例えば、IP アドレス `172.31.16.1` が設定されたタスク内の WordPress コンテナ内から実行される `mysql --host=mysql` CLI コマンドなどです。このコマンドは、MySQL のデフォルトポートの短縮名 `mysql` を使用します。この名前とポートは、同じタスク内で Service Connect プロキシに接続します。WordPress タスクのプロキシは、ラウンドロビン負荷分散と異常値検出に対する以前の障害情報を使用して、接続する MySQL タスクを選択します。図の実線の矢印で示されているように、プロキシは IP アドレス `172.31.16.2` を使用して MySQL タスクの 2 番目のプロキシに接続します。2 番目のプロキシは、同じタスクでローカル MySQL サーバーに接続します。どちらのプロキシも接続パフォーマンスをレポートし、Amazon ECS と Amazon CloudWatch コンソールのグラフに表示されるため、あらゆる種類のアプリケーションのパフォーマンスメトリクスを同じ方法で取得できます。

![\[最小限の HA サービスを示す Service Connect ネットワークの例\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/images/serviceconnect.png)


Service Connect では次の用語が使用されます。

**ポート名**  
特定のポートマッピングに名前を割り当てる Amazon ECS タスク定義設定です。この設定は Amazon ECS Service Connect でのみ使用されます。

**クライアントエイリアス**  
エンドポイントで使用されるポート番号を割り当てる Amazon ECS サービス設定です。さらに、クライアントエイリアスはエンドポイントの DNS 名を割り当て、検出名を上書きすることができます。Amazon ECS サービスで検出名が提供されていない場合、クライアントエイリアス名がエンドポイント名としてポート名に上書きされます。エンドポイントの例については、*エンドポイント*の定義を参照してください。1 つの Amazon ECS サービスに複数のクライアントエイリアスを割り当てることができます。この設定は Amazon ECS Service Connect でのみ使用されます。

**検出名**  
タスク定義から指定されたポートにオプションとして作成できる中間名。この名前は AWS Cloud Map サービスの作成に使用されます。この名前が指定されていない場合は、タスク定義からのポート名が使用されます。特定のポートおよび Amazon ECS サービスに複数の検出名を割り当てることができます。この設定は Amazon ECS Service Connect でのみ使用されます。  
AWS Cloud Map サービス名は、名前空間内で一意である必要があります。この制限により、各名前空間の特定のタスク定義に対し、検出名のない Service Connect 設定は 1 つしか使用できません。

**エンドポイント**  
API またはウェブサイトに接続するための URL です。URL にはプロトコル、DNS 名、ポートが含まれます。エンドポイント全般の詳細については、「Amazon Web Services 全般のリファレンス」の「*AWS 用語集*」の「[エンドポイント](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#endpoint)」を参照してください。  
Service Connect は、Amazon ECS サービスに接続するエンドポイントを作成すると共に、Amazon ECS サービスのタスクがエンドポイントに接続するための設定を行います。URL にはプロトコル、DNS 名、ポートが含まれます。ポートはコンテナイメージ内のアプリケーションと一致する必要があるため、プロトコルとポート名はタスク定義で選択します。サービス内では、各ポートを名前で選択し、DNS 名を割り当てることができます。Amazon ECS サービス設定で DNS 名を指定しない場合、デフォルトではタスク定義からのポート名が使用されます。例えば、Service Connect エンドポイントは `http://blog:80`、`grpc://checkout:8080`、`http://_db.production.internal:99` のいずれかになります。

**Service Connect サービス**  
Amazon ECS サービス内の 1 つのエンドポイントの設定です。これは Service Connect 設定の一部で、コンソールの **[Service Connect and discovery name configuration]** (Service Connect および検出名の設定) の中の 1 行、または Amazon ECS サービスにおける JSON 設定の `services` リストの中の 1 つのオブジェクトで構成されます。この設定は Amazon ECS Service Connect でのみ使用されます。  
詳細については、「Amazon Elastic Container Service API リファレンス」の「[ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)」を参照してください。

**名前空間**  
Service Connect で使用する AWS Cloud Map 名前空間の短縮名または完全な Amazon リソースネーム (ARN)。名前空間は、Amazon ECS サービスおよびクラスターと同じ AWS リージョンにある必要があります。AWS Cloud Map 内の名前空間のタイプは Service Connect に影響しません。名前空間は、AWS RAM で使用できる AWS リージョンの AWS Resource Access Manager (AWS RAM) を使用して AWS アカウントと共有できます。共有名前空間の詳細については、「*AWS Cloud Map デベロッパーガイド*」の「[クロスアカウント AWS Cloud Map 名前空間共有](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)」を参照してください。  
Service Connect は、相互に対話する Amazon ECS タスクの論理グループとして AWS Cloud Map 名前空間を使用します。各 Amazon ECS サービスは 1 つの名前空間のみに属することができます。名前空間内のサービスは、同じ AWS リージョン内の異なる Amazon ECS クラスターに分散できます。名前空間が共有名前空間である場合、サービスは名前空間所有者と名前空間コンシューマー AWS アカウントに分散できます。サービスは、任意の基準で自由に整理できます。

**クライアントサービス**  
ネットワーククライアントアプリケーションを実行するサービスです。このサービスには名前空間が設定されている必要があります。サービス内の各タスクは、Service Connect プロキシコンテナを介して、名前空間のすべてのエンドポイントを検出して接続できます。  
タスク内のいずれかのコンテナが名前空間内のサービスからエンドポイントに接続する必要がある場合は、クライアントサービスを選択します。フロントエンド、リバースプロキシ、またはロードバランサーアプリケーションが、例えば Elastic Load Balancing からなど、他の方法で外部トラフィックを受信する場合は、このタイプの Service Connect 設定を使用できます。

**クライアント/サーバーサービス**  
ネットワークまたはウェブサービスアプリケーションを実行する Amazon ECS サービスです。このサービスには、名前空間と少なくとも 1 つのエンドポイントが設定されている必要があります。サービス内の各タスクには、エンドポイントを使用してアクセスできます。Service Connect プロキシコンテナは、エンドポイント名とポートをリッスンして、タスク内のアプリケーションコンテナにトラフィックを誘導します。  
いずれかのコンテナが公開してポート上でネットワークトラフィックをリッスンする場合は、クライアント/サーバーサービスを選択してください。これらのアプリケーションは、同じ名前空間内の他のクライアント/サーバーサービスに接続する必要はありませんが、クライアント設定が必要です。バックエンド、ミドルウェア、ビジネス層、またはほとんどのマイクロサービスはこのタイプの Service Connect 設定を使用できます。フロントエンド、リバースプロキシ、またはロードバランサーアプリケーションに、同じ名前空間の Service Connect を使用して設定した他のサービスからのトラフィックを受信させる場合、これらのサービスはこのタイプの Service Connect 設定を使用する必要があります。

Service Connect 機能は関連サービスの仮想ネットワークを作成します。同じサービス設定を複数の異なる名前空間で使用することで、独立していても同一のアプリケーションセットを実行できます。Service Connect は Amazon ECS サービスのプロキシコンテナを定義します。これにより、同じタスク定義を使用して、Service Connect 設定が異なるさまざまな名前空間で同一のアプリケーションを実行できます。サービスが作成する各タスクは、タスク内のプロキシコンテナを実行します。

Service Connect は同じ名前空間内の Amazon ECS サービス間の接続に適しています。次のアプリケーションで Service Connect で設定された Amazon ECS サービスに接続するためには、追加の相互接続方法を使用する必要があります。
+ 他の名前空間で設定されているタスク
+ Service Connect 用に設定されていないタスク
+ Amazon ECS の外部にあるその他のアプリケーション

これらのアプリケーションは Service Connect プロキシ経由で接続できますが、Service Connect エンドポイント名を解決することはできません。

これらのアプリケーションで Amazon ECS タスクの IP アドレスを解決するには、別の相互接続方法を使用する必要があります。

**Topics**
+ [料金](#service-connect-pricing)
+ [Amazon ECS Service Connect コンポーネント](service-connect-concepts-deploy.md)
+ [Amazon ECS Service Connect 設定の概要](service-connect-concepts.md)
+ [共有 AWS Cloud Map 名前空間を使用した Amazon ECS Service Connect](service-connect-shared-namespaces.md)
+ [Amazon ECS Service Connect アクセスログ](service-connect-envoy-access-logs.md)
+ [Amazon ECS Service Connect トラフィックを暗号化する](service-connect-tls.md)
+ [AWS CLI を使用した Amazon ECS Service Connect の設定](create-service-connect.md)

## 料金
<a name="service-connect-pricing"></a>
+ Amazon ECS Service Connect の料金は、コンテナ化されたワークロードをホストするために AWS Fargate または Amazon EC2 インフラストラクチャを使用するかどうかによって異なります。AWS Outposts で Amazon ECS を使用する場合、料金は Amazon EC2 を直接使用する場合に使われる同じモデルに従います。詳細については、[Amazon ECS 料金表](https://aws.amazon.com/ecs/pricing)を参照してください。
+ Amazon ECS Service Connect の使用には追加料金はかかりません。
+ Service Connect で使用する場合に AWS Cloud Map の使用に追加料金は発生しません。
+ お客様は、vCPU やメモリなど、Amazon ECS Service Connect で使用されるコンピューティングリソースに対して料金を支払います。Amazon ECS Service Connect エージェントはお客様のタスク内で実行されるため、実行に追加料金はかかりません。タスクリソースは、お客様のワークロードと Amazon ECS Service Connect エージェント間で共有されます。
+ AWS Private CA で Amazon ECS Service Connect トラフィック暗号化機能を使用する場合、お客様は作成するプライベート認証機関と発行される TLS 証明書ごとに料金を支払います。詳細については、「[AWS Private Certificate Authority の料金](https://aws.amazon.com/private-ca/pricing/)」を参照してください。TLS 証明書の月額コストを見積もるには、TLS が有効になっている Amazon ECS サービスの数を把握し、それに証明書のコストを掛けて、さらに 6 を掛ける必要があります。Amazon ECS Service Connect は TLS 証明書を 5 日ごとに自動的にローテーションするため、平均して 1 か月あたり Amazon ECS サービスごとに 6 つの証明書が発行されます。

# Amazon ECS Service Connect コンポーネント
<a name="service-connect-concepts-deploy"></a>

Amazon ECS Service Connect を使用する場合、ネットワークリクエストを受け取るサーバーアプリケーション (クライアント/サーバーサービス) を実行するか、リクエストを行うクライアントアプリケーション (クライアントサービス) を実行するように各 Amazon ECS サービスを設定します。

Service Connect の使用を開始する準備が整ったら、クライアント/サーバーサービスから始めます。新しいサービスまたは既存のサービスに Service Connect 設定を追加できます。Amazon ECS は、名前空間に Service Connect エンドポイントを作成します。さらに、Amazon ECS は現在実行中のタスクを置き換える新しいデプロイをサービス内に作成します。

既存のタスクやその他のアプリケーションは、既存のエンドポイントや外部アプリケーションに引き続き接続できます。クライアント/サーバーサービスがスケールアウトによってタスクを追加すると、クライアントからの新しい接続はすべてのタスク間で分散されます。クライアント/サーバーサービスが更新されると、クライアントからの新しい接続は新バージョンのタスク間で分散されます。

既存のタスクを解決して新しいエンドポイントに接続することはできません。このエンドポイントを解決して接続できるのは、同じ名前空間に Service Connect 設定があり、このデプロイ後に実行を開始した新しいタスクだけです。

つまり、クライアントアプリケーションのオペレーターがアプリの設定が変更されるタイミングを決定しますが、サーバーアプリケーションのオペレーターはいつでも設定を変更できます。名前空間のエンドポイントのリストは、名前空間のサービスがデプロイされるたびに変更される可能性があります。既存のタスクと置換タスクは、最新のデプロイ後も同じように動作し続けます。

次に挙げるサンプルを参考にしてください。

まず、パブリックインターネット上で利用可能なアプリケーションを 1 つの AWS CloudFormation テンプレートと 1 つの CloudFormation スタックで作成していると仮定します。CloudFormation がパブリック検出と到達可能性を作成するのは、フロントエンドクライアントサービスを含めて、最後にする必要があります。フロントエンドクライアントサービスが実行されていて一般に公開されているのに、バックエンドは公開されていないという期間の発生を避けるために、サービスの作成はこの順序で行う必要があります。これにより、その期間中にエラーメッセージが一般に送信されるのを防ぐことができます。AWS CloudFormation では `dependsOn` を使用して、複数の Amazon ECS サービスを並列または同時に作成できないことを CloudFormation に示す必要があります。クライアントタスクが接続するバックエンドクライアント/サーバーサービスごとに、フロントエンドクライアントサービスに `dependsOn` を追加する必要があります。

次に、フロントエンドサービスが Service Connect 設定なしで存在すると仮定します。タスクは既存のバックエンドサービスに接続しています。まず、フロントエンドが使用する **DNS** または `clientAlias` と同じ名前を使用して、バックエンドサービスにクライアント/サーバー Service Connect 設定を追加します。これにより、新しいデプロイが作成されると共に、すべてのデプロイのロールバック検出や、AWS マネジメントコンソール、AWS CLI、AWS SDK などの、バックエンドサービスをロールバックして以前のデプロイと設定に戻す方法が作成されます。バックエンドサービスのパフォーマンスと動作に問題がなければ、クライアントまたはクライアント/サーバー Service Connect 設定をフロントエンドサービスに追加します。それらの新しいタスクに追加された Service Connect プロキシを使用するのは、新しいデプロイのタスクのみです。この設定に問題がある場合は、デプロイロールバック検出または AWS マネジメントコンソール、AWS CLI、AWS SDK などのバックエンドサービスをロールバックして以前のデプロイと設定に戻す方法を使用することで、ロールバックして以前の設定に戻すことができます。Service Connect ではなく DNS に基づく別のサービス検出システムを使用する場合、フロントエンドまたはクライアントアプリケーションは、ローカル DNS キャッシュの有効期限が切れてから新しいエンドポイントと変更されたエンドポイント設定の使用を開始しますが、これには通常数時間かかります。

## ネットワーク
<a name="service-connect-concepts-network"></a>

デフォルトでは、Service Connect プロキシは、タスク定義ポートマッピングから `containerPort` をリッスンします。セキュリティグループルールでは、クライアントが実行されるサブネットからこのポートへの受信 (イングレス) トラフィックを許可する必要があります。

Service Connect サービス設定でポート番号を設定した場合であっても、Service Connect プロキシがリッスンするクライアント/サーバーサービスのポートは変更されません。このポート番号を設定すると、Amazon ECS はそれらのタスク内の Service Connect プロキシ上で、クライアントサービスが接続するエンドポイントのポートを変更します。クライアントサービスのプロキシは、`containerPort` を使用してクライアント/サーバーサービスのプロキシに接続します。

Service Connect プロキシがリッスンするポートを変更する場合は、クライアント/サーバーサービスの Service Connect 設定で `ingressPortOverride` を変更してください。このポート番号を変更する場合は、このサービスへのトラフィックが使用するこのポートのインバウンドトラフィックを許可する必要があります。

Service Connect 用に設定された Amazon ECS サービスにアプリケーションが送信するトラフィックは、Amazon VPC およびサブネットにおいて、ルートテーブルルールおよびネットワーク ACL ルールにより、使用している `containerPort` と `ingressPortOverride` のポート番号が許可されている必要があります。

 Service Connect を使用して VPC 間でトラフィックを送信できます。ルートテーブルルール、ネットワーク ACL、セキュリティグループに対する同じ要件が両方の VPC に適用されます。

例えば、2 つのクラスターは異なる VPC でタスクを作成します。各クラスターのサービスは、同じ名前空間を使用するように設定されています。これら 2 つのサービスのアプリケーションは、VPC DNS 設定なしで名前空間のすべてのエンドポイントを解決できます。ただし、VPC ピアリング、VPC またはサブネットのルートテーブル、そして VPC ネットワーク ACL により、`containerPort` と `ingressPortOverride` のポート番号のトラフィックが許可されない限り、プロキシは接続できません。

`bridge` ネットワークモードを使用するタスクでは、動的ポートの上限範囲でのトラフィックを許可するインバウンドルールを含むセキュリティグループを作成する必要があります。次に、Service Connect クラスター内のすべての EC2 インスタンスにセキュリティグループを割り当てます。

## Service Connect プロキシ
<a name="service-connect-concepts-proxy"></a>

Service Connect 設定を使用してサービスを作成または更新した場合、新しいタスクが開始されるたびに、Amazon ECS はタスクに新しいコンテナを追加します。別のコンテナを使用するこのパターンは、`sidecar` と呼ばれます。このコンテナはタスク定義には存在せず、設定できません。Amazon ECS は、サービス内のコンテナ設定を管理します。これにより、Service Connect を使用せずに、複数のサービス、名前空間、タスク間で同じタスク定義を再利用できます。

**プロキシリソース**
+ タスク定義では、CPU パラメータとメモリパラメータを設定する必要があります。

  Service Connect プロキシコンテナの処理能力を向上させるために、お客様のタスク CPU とメモリに、256 CPU ユニットと 64 MiB 以上のメモリを追加することをお勧めします。AWS Fargate では、ユーザーが設定できる最小のメモリ容量は 512 MiB です。Amazon EC2 では、タスク定義メモリが必要です。
+ サービスでは、Service Connect 設定でログ設定を設定します。
+ このサービスのタスクがピーク負荷時に 1 秒あたり 500 を超えるリクエストを受信すると予想される場合は、Service Connect プロキシコンテナのこのタスク定義で、タスク CPU に 512 CPU ユニットを追加することをお勧めします。
+ 名前空間内に 100 個以上の Service Connect サービス、または名前空間内のすべての Amazon ECS サービスに合計で 2000 個以上のタスクを作成する場合、Service Connect プロキシコンテナのタスクに対して 128 MiB のメモリを追加することをお勧めします。これは、名前空間内のすべての Amazon ECS サービスで使用されるすべてのタスク定義で行う必要があります。

**プロキシ設定**  
アプリケーションは、アプリケーションと同じタスクでサイドカーコンテナ内のプロキシに接続します。Amazon ECS は、アプリケーションが同じ名前空間のエンドポイント名に接続されている場合にのみアプリケーションがプロキシに接続するように、タスクとコンテナを設定します。その他のすべてのトラフィックはプロキシを使用しません。他のトラフィックには、同じ VPC 内の IP アドレス、AWS サービス エンドポイント、外部トラフィックが含まれます。

**負荷分散**  
Service Connect は、Service Connect エンドポイントのタスク間の負荷分散にラウンドロビン方式を使用するようにプロキシを設定します。接続元のタスクにあるローカルプロキシは、エンドポイントを提供するクライアントサーバーサービス内のタスクの 1 つを選択します。  
例えば、「*local*」という名前空間の*クライアントサービス*として設定されたサービスで WordPress を実行するタスクについて考えてみます。MySQL データベースを実行する 2 つのタスクを持つ、他のサービスがあります。このサービスは、同じ名前空間内の Service Connect を通じて `mysql` と呼ばれるエンドポイントを提供するように構成されています。WordPress タスクでは、WordPress アプリケーションはエンドポイント名を使用してデータベースに接続します。この名前への接続は、同じタスクのサイドカーコンテナで実行されるプロキシに送られます。その後、プロキシはラウンドロビン方式を使用してどちらの MySQL タスクにも接続できます。  
負荷分散戦略: ラウンドロビン

**外れ値の検知**  
この機能では、以前に失敗した接続についてプロキシが保持しているデータを使用して、失敗した接続があったホストに新しい接続を送信しないようにします。Service Connect は、プロキシの外れ値検出機能を設定して、パッシブなヘルスチェックを提供します。  
前の例を使用すると、プロキシはいすれかの MySQL タスクに接続できます。プロキシが特定の MySQL タスクに複数の接続を行い、直近 30 秒間以内に 5 つ以上の接続が失敗した場合、プロキシはその MySQL タスクを 30 ～ 300 秒間回避します。

**再試行**  
Service Connect は、プロキシを通過して失敗した接続を再試行するようにプロキシを設定し、2 回目の試行では、前の接続のホストを使用しません。これにより、Service Connect を介した各接続が 1 回限りの理由で失敗することがなくなります。  
再試行回数: 2

**タイムアウト**  
Service Connect は、クライアント/サーバーアプリケーションが応答するまで最大時間待機するようにプロキシを構成します。デフォルトのタイムアウト値は 15 秒ですが、更新できます。  
任意指定のパラメータ:  
**idleTimeout** - アイドル時に接続がアクティブな状態を維持する時間 (秒)。`0` の値は、`idleTimeout` を無効にします。  
`HTTP`/`HTTP2`/`GRPC` の `idleTimeout` デフォルトは 5 分です。  
`TCP` に対する `idleTimeout` デフォルトは 1 時間です。  
**perRequestTimeout** - リクエストごとにアップストリームが完全なレスポンスで応答するまで待機する時間。`0` の値は `perRequestTimeout` をオフにします。これは、アプリケーションコンテナの `appProtocol` が `HTTP`/`HTTP2`/`GRPC` の場合にのみ設定できます。デフォルト値は 15 秒です。  
`idleTimeout` を `perRequestTimeout` より短い時間に設定すると、`perRequestTimeout` ではなく `idleTimeout` が到達した時点で接続は終了します。

## 考慮事項
<a name="service-connect-considerations"></a>

Service Connect を使用する場合は、次の点を考慮してください。
+ Fargate で実行されるタスクが Service Connect を使用するには、Fargate Linux プラットフォームバージョン `1.4.0` 以上を使用する必要があります。
+ コンテナインスタンスの Amazon ECS エージェントバージョンには `1.67.2` 以降が必要です。
+ コンテナインスタンスが Service Connect を使用するには、Amazon ECS 最適化 Amazon Linux 2023 AMI バージョン `20230428` 以降、または Amazon ECS 最適化 Amazon Linux 2 AMI バージョン `2.0.20221115` を実行する必要があります。これらのバージョンには、Amazon ECS コンテナエージェントに加えて Service Connect エージェントがあります。Service Connect エージェントの詳細については、GitHub の「[Amazon ECS Service Connect エージェント](https://github.com/aws/amazon-ecs-service-connect-agent)」を参照してください。
+ コンテナインスタンスには、リソース `arn:aws:ecs:region:0123456789012:task-set/cluster/*` に対する `ecs:Poll` のアクセス許可が必要です。`ecsInstanceRole` を使用している場合は、アクセス許可を追加する必要はありません。`AmazonEC2ContainerServiceforEC2Role` 管理ポリシーには、必要なアクセス許可があります。詳細については、「[Amazon ECS コンテナインスタンスの IAM ロール](instance_IAM_role.md)」を参照してください。
+ `bridge` ネットワークモードを使用し、Service Connect を使用するタスクは、`hostname` コンテナ定義パラメータをサポートしません。
+ Service Connect を使用するには、タスク定義でタスクメモリ制限を設定する必要があります。詳細については、「[Service Connect プロキシ](#service-connect-concepts-proxy)」を参照してください。
+ コンテナのメモリ制限を設定するタスク定義はサポートされていません。

  コンテナにはコンテナメモリ制限を設定できますが、タスクメモリ制限はコンテナメモリ制限の合計よりも大きい数値に設定する必要があります。タスク制限内の追加の CPU とメモリで、コンテナ制限に割り当てられていないものは、Service Connect プロキシコンテナや、コンテナ制限を設定していない他のコンテナによって使用されます。詳細については、「[Service Connect プロキシ](#service-connect-concepts-proxy)」を参照してください。
+ 同じ AWS アカウントに存在する、または AWS Resource Access Manager を使用して AWS アカウントと共有されている同じリージョンに存在する任意の AWS Cloud Map 名前空間を使用するように Service Connect を設定できます。共有名前空間の使用について詳しくは、「[共有 AWS Cloud Map 名前空間を使用した Amazon ECS Service Connect](service-connect-shared-namespaces.md)」を参照してください。
+ 各サービスは 1 つの名前空間のみに属することができます。
+ サービスが作成したタスクのみがサポートされます。
+ すべてのエンドポイントは、名前空間内で一意である必要があります。
+ すべての検出名は、名前空間内で一意である必要があります。
+ アプリケーションが新しいエンドポイントを解決できるようにするには、既存のサービスを再デプロイする必要があります。最新のデプロイ後に名前空間に追加された新しいエンドポイントは、タスク構成には追加されません。詳細については、「[Amazon ECS Service Connect コンポーネント](#service-connect-concepts-deploy)」を参照してください。
+ Service Connect は、クラスターが削除されても名前空間を削除しません。AWS Cloud Map で名前空間を削除する必要があります。
+ Application Load Balancer のトラフィックは、デフォルトで `awsvpc` ネットワークモードの Service Connect エージェントを経由してルーティングされます。サービス以外のトラフィックを Service Connect エージェントをバイパスさせたい場合は、Service Connect サービス設定の `[ingressPortOverride](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)` パラメータを使用してください。
+ Service Connect with TLS は `bridge` ネットワークモードをサポートしていません。`awsvpc` ネットワークモードのみサポートされています。
+ `awsvpc` モードでは、Service Connect プロキシは IPv4 専用およびデュアルスタック設定のサービスの IPv4 localhost `127.0.0.1` にトラフィックを転送します。IPv6 専用設定のサービスの場合、プロキシはトラフィックを IPv6 localhost `::1` に転送します。サービスが IPv4 専用またはデュアルスタック設定から IPv6 専用に更新されたときに、両方の localhost をリッスンするようにアプリケーションを設定することをお勧めします。詳細については、「[EC2 の Amazon ECS タスクネットワークオプション](task-networking.md)」および「[Fargate における Amazon ECS タスクのネットワークオプション](fargate-task-networking.md)」を参照してください。

**Service Connect では、次に示すの機能はサポートされていません。**
+ Windows コンテナ
+ HTTP 1.0
+ スタンドアロンのタスク
+ CodeDeploy および外部デプロイタイプを搭載したブルー/グリーン使用するサービス
+ Amazon ECS Anywhere の `External` コンテナインスタンスは、Service Connect ではサポートされていません。
+ PPv2
+ FIPS モード

# Amazon ECS Service Connect 設定の概要
<a name="service-connect-concepts"></a>

Service Connect を使用する場合、リソースで設定する必要があるパラメータがあります。

Amazon ECS リソースの設定パラメータを以下の表に示します。


| パラメータの場所 | アプリケーションタイプ | 説明 | 必須 | 
| --- | --- | --- | --- | 
| タスク定義 | クライアント | クライアントタスク定義には、Service Connect が利用できる変更はありません。 | 該当なし | 
| タスク定義 | クライアント/サーバー | サーバーは、コンテナの portMappings のポートに name フィールドを追加する必要があります。詳細については、[portMappings](task_definition_parameters.md#ContainerDefinition-portMappings)を参照してください。 | はい | 
| タスク定義 | クライアント/サーバー | サーバーは、オプションでアプリケーションプロトコル (HTTP など) を提供して、サーバーアプリケーションのプロトコル固有のメトリクス (HTTP 5xx など) を受け取ることができます。 | いいえ | 
| サービスの定義 | クライアント | クライアントサービスは、名前空間の結合を設定するには serviceConnectConfiguration を追加する必要があります。この名前空間には、このサービスが検出する必要のあるすべてのサーバーサービスが含まれていなければなりません。詳細については、「[serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration)」を参照してください。 | はい | 
| サービスの定義 | クライアント/サーバー | サーバーサービスは、サービスが利用できる DNS 名、ポート番号、名前空間を設定するために serviceConnectConfiguration を追加する必要があります。詳細については、「[serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration)」を参照してください。 | はい | 
| クラスター | クライアント | クラスターはデフォルトの Service Connect 名前空間を追加できます。クラスター内の新しいサービスは、サービスで Service Connect が設定されている場合は名前空間を継承します。 | いいえ | 
| クラスター | クライアント/サーバー | サーバーサービスに適用されるクラスターには、Service Connect が利用できる変更はありません。サーバーのタスク定義とサービスは、それぞれの設定を行う必要があります。 | 該当なし | 

**Service Connect の設定手順の概要**  
次の手順では、Service Connect の設定方法の概要を示します。

**重要**  
 Service Connect がお客様のアカウントに AWS Cloud Map サービスを作成します。手動でのインスタンスの登録/登録解除、インスタンス属性の変更、サービスの削除を行ってこれらの AWS Cloud Map リソースを変更すると、アプリケーショントラフィックまたは以降のデプロイで予期しない動作が発生することがあります。
 Service Connect は、タスク定義内のリンクをサポートしていません。

1. タスク定義のポートマッピングにポート名を追加します。さらに、アプリケーションのレイヤー 7 プロトコルを識別して、追加のメトリクスを取得できます。

1. AWS Cloud Map 名前空間を使用してクラスターを作成するか、共有名前空間を使用する、または名前空間を個別に作成します。単純に構成できるように、名前空間に必要な名前でクラスターを作成し、名前空間に同名を指定します。この場合、Amazon ECS は必要な設定で新しい HTTP 名前空間を作成します。Service Connect は Amazon Route 53 では DNS ホストゾーンを使用または作成しません。

1. サービスを設定して、名前空間内に Service Connect エンドポイントを作成します。

1. サービスをデプロイしてエンドポイントを作成します。Amazon ECS は各タスクに Service Connect プロキシコンテナを追加し、AWS Cloud Map に Service Connect エンドポイントを作成します。このコンテナはタスク定義では設定されていないため、タスク定義を変更せずに再利用して、同じ名前空間または複数の名前空間に複数のサービスを作成できます。

1. クライアントアプリをサービスとしてデプロイしてエンドポイントに接続します。Amazon ECS は Service Connect エンドポイントへの接続を各タスクの Service Connect プロキシ経由で行います。

   アプリケーションは Service Connect エンドポイントへの接続にのみプロキシを使用します。プロキシを使用するための追加の構成はありません。プロキシは、ラウンドロビン負荷分散、外れ値検出、再試行を実行します。プロキシの詳細については、「[Service Connect プロキシ](service-connect-concepts-deploy.md#service-connect-concepts-proxy)」を参照してください。

1. Amazon CloudWatch の Service Connect プロキシ経由のトラフィックを監視します。

## クラスターの設定
<a name="service-connect-concepts-cluster-defaults"></a>

クラスターの作成時または更新時に、Service Connect のデフォルトの名前空間を設定できます。デフォルトとして指定する名前空間名は、同じ AWS リージョンとアカウントに存在するか、同じ AWS リージョンに存在し、AWS Resource Access Manager を使用して別の AWS アカウントと共有するようにできます。

クラスターを作成してデフォルトの Service Connect 名前空間を指定した場合、Amazon ECS が名前空間を作成する間、そのクラスターは `PROVISIONING` ステータスで待機します。クラスターのステータスには、名前空間のステータスを示す `attachment` が表示されます。アタッチメントは、デフォルトでは AWS CLI に表示されません。表示するには、`--include ATTACHMENTS` を追加する必要があります。

AWS RAM を使用して AWS アカウントと共有されている名前空間を使用する場合は、クラスター設定で名前空間の Amazon リソースネーム (ARN) を指定します。共有 AWS Cloud Map 名前空間の詳細については、「[共有 AWS Cloud Map 名前空間を使用した Amazon ECS Service Connect](service-connect-shared-namespaces.md)」を参照してください。

## サービス設定
<a name="service-connect-concepts-config"></a>

Service Connect は、必要最小限の設定で済むように設計されています。タスク定義で、Service Connect で使用する各ポートマッピングの名前を設定する必要があります。サービスでクライアントサービスを作成するには、Service Connect をオンにして AWS アカウントの名前空間または共有名前空間を選択する必要があります。クライアント/サーバーサービスを作成するには、いずれかのポートマッピングの名前と一致する単一の Service Connect サービス設定を追加する必要があります。Amazon ECS はタスク定義からポート番号とポート名を再利用して、Service Connect サービスとエンドポイントを定義します。これらの値を上書きするには、コンソールで他のパラメータ **[Discovery]** (検出)、**[DNS]**、**[Port]** (ポート) を使用するか、`discoveryName`、`clientAliases` それぞれを Amazon ECS API で使用します。

## 初期ヘルスチェックの設定
<a name="service-connect-concepts-health-check"></a>

Service Connect は、トラフィックをルーティングする前にタスクが正常であることを確認します。タスクが起動すると (デプロイ、スケーリング、または置き換え中)、Service Connect はタスクの状態をモニタリングして、トラフィックを受け入れる準備ができていることを確認します。この動作を有効にするには、タスク定義で必須コンテナのヘルスチェックを定義する必要があります。

初期ヘルスチェックの動作は、タスクがトラフィックを受け入れる準備ができた状態に達するまでの潜在的な遅延を考慮します。
+ タスクが `HEALTHY` の場合は、トラフィックに対して直ちに使用できます。
+ タスクのヘルスが `UNKNOWN` の場合、Service Connect はタスクの必須コンテナのコンテナヘルスチェック設定 (「[ヘルスチェック](task_definition_parameters.md#container_definition_healthcheck)」を参照) に従って、最大 `8 minutes` のタイムアウトを計算してから、`UNKNOWN` のままであってもトラフィックで利用できるようにします。
+ タスクが `UNHEALTHY` になっているときは、Amazon ECS が代替タスクを起動する場合があります。正常なタスクが利用できない場合は、サービスの設定に基づいてデプロイがロールバックされる可能性があります。

進行中のすべてのトラフィックについて、Service Connect は外れ値検出に基づくパッシブヘルスチェックを使用してトラフィックを効率的にルーティングします。

# 共有 AWS Cloud Map 名前空間を使用した Amazon ECS Service Connect
<a name="service-connect-shared-namespaces"></a>

Amazon ECS Service Connect は、同じ AWS リージョン内の複数の AWS アカウントで共有 AWS Cloud Map 名前空間を使用することをサポートしています。この機能を使用すると、異なる AWS アカウントで実行されているサービスが Service Connect を介して相互に検出して通信することが可能な分散アプリケーションを作成できます。共有名前空間は、安全なクロスアカウントリソース共有を可能にする AWS Resource Access Manager (AWS RAM) を使用して管理されます。共有名前空間の詳細については、「*AWS Cloud Map デベロッパーガイド*」の「[クロスアカウント AWS Cloud Map 名前空間共有](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)」を参照してください。

**重要**  
Service Connect が名前空間で適切に動作するには、`AWSRAMPermissionCloudMapECSFullPermission` マネージドアクセス許可を使用して名前空間を共有する必要があります。

Service Connect で共有 AWS Cloud Map 名前空間を使用する場合は、複数の AWS アカウントのサービスが同じサービス名前空間に参加できます。これは、複数の AWS アカウントが存在する組織で、セキュリティと分離を維持しながら、アカウントの境界を越えてサービス間通信を維持する必要がある場合に特に有効です。

**注記**  
異なる VPC にあるサービスと通信するには、VPC 間接続を設定する必要があります。これは、VPC ピアリング接続を使用して実現できます。詳細については、「*Amazon Virtual Private Cloud ピアリングガイド*」の「[VPC ピアリング接続の作成または削除](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html)」を参照してください。

# Amazon ECS Service Connect での共有 AWS Cloud Map 名前空間の使用
<a name="service-connect-shared-namespaces-setup"></a>

Service Connect の共有 AWS Cloud Map 名前空間の設定には、名前空間所有者による名前空間の作成、AWS Resource Access Manager (AWS RAM) を介した所有者による共有、リソース共有を受け入れるコンシューマー、共有名前空間を使用するように Service Connect を設定するコンシューマーのステップが含まれます。

## ステップ 1: AWS Cloud Map 名前空間を作成する
<a name="service-connect-shared-namespaces-create"></a>

名前空間所有者は、他のアカウントと共有される AWS Cloud Map 名前空間を作成します。

**AWS マネジメントコンソールを使用して共有するための名前空間を作成するには**

1. [https://console.aws.amazon.com/cloudmap/](https://console.aws.amazon.com/cloudmap/) で AWS Cloud Map コンソールを開きます。

1. [**名前空間の作成**] を選択します。

1. **名前空間名**を入力します。この名前は、すべての参加アカウントのサービスによって使用されます。

1. **[名前空間タイプ]** で、ユースケースに適したタイプを選択します。
   + **API コール** – DNS 機能のないサービス検出用の HTTP 名前空間。
   + **VPC での API コールと DNS クエリ** – VPC 内のプライベート DNS クエリを使用したサービス検出用のプライベート DNS 名前空間。
   + **API コールとパブリック DNS クエリ** – パブリック DNS クエリによるサービス検出用のパブリック DNS 名前空間。

1.  [**名前空間の作成**] を選択します。

## ステップ 2: AWS RAM を使用して名前空間を共有する
<a name="service-connect-shared-namespaces-share"></a>

名前空間の所有者は、AWS RAM を使用して名前空間を他の AWS アカウントと共有します。

**AWS RAM コンソールを使用して名前空間を共有するには**

1. AWS RAM コンソール ([https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/)) を開きます。

1. **[リソースの共有の作成]** を選択します。

1. **[Name]** (名前) に、リソース共有のわかりやすい名前を入力します。

1. **[リソース]** セクションで、次の操作を行います。

   1. **[リソースタイプ]**で、**クラウドマップ名前空間**を選択します。

   1. 前のステップで作成した名前空間を選択します。

1. **[マネージドアクセス許可]** セクションで、**[AWSRAMPermissionCloudMapECSFullPermission]** を指定します。
**重要**  
Service Connect が名前空間で適切に動作するには、`AWSRAMPermissionCloudMapECSFullPermission` マネージドアクセス許可を使用して名前空間を共有する必要があります。

1. **[プリンシパル]** セクションで、名前空間を共有する AWS アカウントを指定します。アカウント ID または組織単位 ID を入力できます。

1. **[リソースの共有の作成]** を選択します。

## ステップ 3: リソース共有を受け入れる
<a name="service-connect-shared-namespaces-accept"></a>

名前空間コンシューマーアカウントが共有名前空間を使用するには、リソース共有の招待を受け入れる必要があります。

**AWS RAM コンソールを使用してリソース共有の招待を承諾するには**

1. コンシューマーアカウントで、AWS RAM コンソール ([https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/)) を開きます。

1. ナビゲーションペインで **[Shared with me]** (自分と共有)、**[リソース共有]** の順に選択します。

1. リソース共有の招待を選択し、**[リソースの共有を承認]** を選択します。

1. 同意したら、リソースの詳細から共有名前空間 ARN を書き留めます。この ARN は、Service Connect サービスを設定する際に使用します。

## ステップ 4: 共有名前空間を使用して Amazon ECS サービスを設定する
<a name="service-connect-shared-namespaces-configure"></a>

共有名前空間を受け入れると、名前空間コンシューマーは、共有名前空間を使用するように Amazon ECS サービスを設定できます。設定は通常の名前空間の使用と類似していますが、名前の代わりに名前空間 ARN を指定する必要があります。サービス作成手順の詳細については、「[Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)」を参照してください。

**AWS マネジメントコンソールを使用して共有名前空間でサービスを作成するには**

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、サービスを作成するクラスターを選択します。

1. **[サービス]** で **[作成]** を選択します。

1. ワークロードに応じて他の詳細情報を入力したら、**[Service Connect]** セクションで **[Service Connect を使う]** を選択します。

1. **[名前空間]** には、共有名前空間の完全な ARN を入力します。

   ARN 形式は `arn:aws:servicediscovery:region:account-id:namespace/namespace-id` です。

1. 必要に応じて、サービスタイプ (クライアントまたはクライアントサーバー) の残りの Service Connect 設定を構成します。

1. サービスの作成プロセスを完了します。

AWS CLI または AWS SDK を使用してサービスを設定するには、`serviceConnectConfiguration` の `namespace` パラメータで共有名前空間 ARN を指定します。

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-def \
    --service-connect-configuration '{
        "enabled": true,
        "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890",
        "services": [{
            "portName": "web",
            "discoveryName": "my-service",
            "clientAliases": [{
                "port": 80,
                "dnsName": "my-service"
            }]
        }]
    }'
```

## 考慮事項
<a name="service-connect-shared-namespaces-considerations"></a>

Service Connect で共有 AWS Cloud Map 名前空間を使用する場合は、次の点を考慮してください。
+ AWS RAM は、共有名前空間を使用する AWS リージョンで利用できる必要があります。
+ 共有名前空間は、Amazon ECS のサービスおよびクラスターと同じ AWS リージョンに存在する必要があります。
+ 共有名前空間で Service Connect を設定する場合は、ID ではなく名前空間 ARN を使用する必要があります。
+ HTTP、プライベート DNS、パブリック DNS 名前空間のすべての名前空間タイプがサポートされています。
+ 共有名前空間へのアクセスが取り消されると、名前空間とのやり取りを必要とする Amazon ECS オペレーション (`CreateService`、`UpdateService`、`ListServicesByNamespace` など) は失敗します。共有名前空間のアクセス許可に関する問題のトラブルシューティングの詳細については、「[共有 AWS Cloud Map 名前空間を使用した Amazon ECS Service Connect のトラブルシューティング](service-connect-shared-namespaces-troubleshooting.md)」を参照してください。
+ 共有プライベート DNS 名前空間で DNS クエリを使用するサービス検出の場合:
  + 名前空間所有者は、名前空間に関連付けられたプライベートホストゾーンの ID とコンシューマーの VPC を使用して `create-vpc-association-authorization` を呼び出す必要があります。

    ```
    aws route53 create-vpc-association-authorization --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678
    ```
  + 名前空間コンシューマーは、プライベートホストゾーンの ID を使用して `associate-vpc-with-hosted-zone` を呼び出す必要があります。

    ```
    aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678
    ```
+ リソース共有を管理できるのは、名前空間所有者のみです。
+ 名前空間コンシューマーは、共有名前空間内でサービスを作成および管理できますが、名前空間自体を変更することはできません。
+ 検出名は、サービスを作成するアカウントを問わず、共有名前空間内で一意であることが必要です。
+ 共有名前空間内のサービスは、名前空間にアクセスできる他の AWS アカウントのサービスを検出して接続できます。
+ Service Connect で TLS を有効にし、共有名前空間を使用する場合、AWS Private CA 認証局 (CA) は名前空間に限定されます。共有名前空間へのアクセスが取り消されると、CA へのアクセスは停止します。
+ 共有名前空間を使用する場合、名前空間の所有者とコンシューマーはデフォルトでクロスアカウントの Amazon CloudWatch メトリクスにアクセスできません。ターゲットメトリクスは、クライアントサービスを所有するアカウントにのみ発行されます。クライアントサービスを所有するアカウントは、クライアント/サーバーサービスを所有するアカウントが受信したメトリクスにアクセスできません。その逆も同様です。メトリクスへのクロスアカウントアクセスを許可するには、CloudWatch クロスアカウントオブザーバビリティを設定します。クロスアカウントオブザーバビリティの設定の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch のクロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)」を参照してください。Service Connect の CloudWatch メトリクスの詳細については、「[Amazon ECS CloudWatch メトリクス](available-metrics.md)」を参照してください。

# 共有 AWS Cloud Map 名前空間を使用した Amazon ECS Service Connect のトラブルシューティング
<a name="service-connect-shared-namespaces-troubleshooting"></a>

次の情報を使用して、共有 AWS Cloud Map 名前空間と Service Connect の問題をトラブルシューティングします。エラーメッセージの検索の詳細については、「[Amazon ECS のトラブルシューティング](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html)」を参照してください。

アクセス許可の問題に関連するエラーメッセージは、アクセス許可が欠落していることが原因で、または名前空間へのアクセスが取り消された場合に表示されます。

**重要**  
Service Connect が名前空間で適切に動作するには、`AWSRAMPermissionCloudMapECSFullPermission` マネージドアクセス許可を使用して名前空間を共有する必要があります。

エラーメッセージは、次のいずれかの形式で表示されます。

<OperationName> オペレーションを呼び出すときにエラー (ClientException) が発生しました: ユーザー: arn:aws:iam::<account-id>:user/<user-name> にはリソース: <ResourceArn> に対して <ActionName> を実行するための権限が付与されていません: これは、リソースベースのポリシーで <ActionName> アクションが許可されていないためです

この形式のエラーメッセージは、次のシナリオにおいて生成される可能性があります。

**クラスターの作成または更新の失敗**  
これらの問題は、`CreateCluster` や `UpdateCluster` などの Amazon ECS オペレーションが AWS Cloud Map アクセス許可が欠落しているために失敗した場合に発生します。このオペレーションには、次の AWS Cloud Map アクションに対するアクセス許可が必要です。  
+ `servicediscovery:GetNamespace`
リソース共有の招待がコンシューマーアカウントで承諾され、Service Connect 設定で正しい名前空間 ARN が使用されていることを確認します。

**サービスの作成または更新の失敗**  
これらの問題は、`CreateService` や `UpdateService` などの Amazon ECS オペレーションが AWS Cloud Map アクセス許可が欠落しているために失敗した場合に発生します。このオペレーションには、次の AWS Cloud Map アクションに対するアクセス許可が必要です。  
+ `servicediscovery:CreateService`
+ `servicediscovery:GetNamespace`
+ `servicediscovery:GetOperation` (新しい AWS Cloud Map サービスを作成する場合)
+ `servicediscovery:GetService` (AWS Cloud Map サービスが既に存在する場合)
リソース共有の招待がコンシューマーアカウントで承諾され、Service Connect 設定で正しい名前空間 ARN が使用されていることを確認します。

**`ListServicesByNamespace` オペレーションが失敗する**  
この問題は、Amazon ECS `ListServicesByNamespace` オペレーションが失敗した場合に発生します。このオペレーションには、次の AWS Cloud Map アクションに対するアクセス許可が必要です。  
+ `servicediscovery:GetNamespace`
この問題を解決するには。  
+ コンシューマーアカウントに `servicediscovery:GetNamespace` アクセス許可が付与されていることを確認します。
+ 名前ではなく API を呼び出す場合は、名前空間 ARN を使用します。
+ リソース共有がアクティブであり、招待が承諾されていることを確認します。

ユーザー: <iam-user> は、ID ベースのポリシーで明示的に拒否されたリソース: <ResourceArn> に対して <ActionName> を実行することを承認されていません。

この形式のエラーメッセージは、次のシナリオにおいて生成される可能性があります。

**サービスの削除が失敗し、`DRAINING` 状態のままになる**  
この問題は、名前空間へのアクセスが取り消されたことで `servicediscovery:DeleteService` アクセス許可がなくなり、それが原因で Amazon ECS `DeleteService` オペレーションが失敗する場合に発生します。サービスは最初は正常に削除されたように見えますが、`DRAINING` 状態でスタックします。このエラーメッセージは Amazon ECS サービスイベントとして表示されます。  
この問題を解決するには、名前空間所有者が名前空間をコンシューマーアカウントと共有して、サービスの削除を完了できるようにする必要があります。

**サービスのタスクが実行に失敗する**  
この問題は、アクセス許可が欠落しているためにタスクが開始されない場合に発生します。このエラーメッセージは、停止したタスクエラーとして表示されます。詳細については、「[Amazon ECS の停止したタスクのエラーを解決する](resolve-stopped-errors.md)」を参照してください。  
タスクを実行するには、次の AWS Cloud Map アクションが必要です。  
+ `servicediscovery:GetOperation`
+ `servicediscovery:RegisterInstance`
コンシューマーアカウントに必要なアクセス許可が付与されており、共有名前空間にアクセスできることを確認します。

**タスクがクリーンに停止しないか、`DEACTIVATING` または `DEPROVISIONING` の状態のままになる**  
この問題は、アクセス許可が欠落しているためにシャットダウン中にタスクが AWS Cloud Map サービスから登録解除できなかったことが原因で発生します。エラーは、`DescribeTasks` API を使用して取得できるタスクアタッチメントに `statusReason` として表示されます。詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html)」を参照してください。  
タスクを停止するには、次の AWS Cloud Map アクションが必要です。  
+ `servicediscovery:DeregisterInstance`
+ `servicediscovery:GetOperation`
共有名前空間へのアクセスが取り消された場合、名前空間へのアクセスが復元されるまでタスクは `DEACTIVATING` または `DEPROVISIONING` の状態のままになる可能性があります。名前空間所有者に名前空間へのアクセスの復元をリクエストします。

# Amazon ECS Service Connect アクセスログ
<a name="service-connect-envoy-access-logs"></a>

Amazon ECS Service Connect は、Service Connect プロキシによって処理された個別のリクエストに関する詳細なテレメトリを提示するアクセスログをサポートします。アクセスログは、HTTP メソッド、パス、レスポンスコード、フラグ、タイミング情報などのリクエストごとのトラフィックメタデータをキャプチャすることで、既存のアプリケーションログを補完します。これにより、リクエストレベルのトラフィックパターンとサービスインタラクションをより詳細に観察できるため、効果的なトラブルシューティングとモニタリングが可能になります。

アクセスログを有効にするには、`serviceConnectConfiguration` オブジェクトで `logConfiguration` オブジェクトと `accessLogConfiguration` オブジェクトの両方を指定します。ログの形式と、ログについて `accessLogConfiguration` にクエリパラメータが含まれるかどうかを設定できます。ログは、`logConfiguration` で指定されたログドライバーによって送信先ロググループに配信されます。

```
{
    "serviceConnectConfiguration": {
        "enabled": true,
        "namespace": "myapp.namespace",
        "services": [
            ...
        ],
        "logConfiguration": {
            "logDriver": "awslogs",
            "options": {
                "awslogs-group": "my-envoy-log-group",
                "awslogs-region": "us-west-2",
                "awslogs-stream-prefix": "myapp-envoy-logs"
            }
        },
         "accessLogConfiguration": {
            "format": "TEXT",
            "includeQueryParameters": "ENABLED" 
        }
    }
}
```

## 考慮事項
<a name="service-connect-envoy-access-logs-considerations"></a>

アクセスログへのアクセスを有効にする場合は、次の点を考慮してください。
+ アクセスログとアプリケーションログはどちらも `/dev/stdout` に書き込まれます。アクセスログをアプリケーションログから分離するには、カスタムの Fluent Bit または Fluentd の設定で `awsfirelens` ログドライバーを使用することをお勧めします。
+  `awslogs` ログドライバーを使用して、アプリケーションとアクセスログを同じ CloudWatch の宛先に送信することをお勧めします。
+ アクセスログは、プラットフォームバージョン `1.4.0` 以降を使用する Fargate サービスでサポートされています。
+ リクエスト ID やトークンなどのクエリパラメータは、デフォルトでアクセスログから除外されます。アクセスログにクエリパラメータが含まれるようにするには、`includeQueryParameters` を `"ENABLED"` に設定します。

## アクセスログの形式
<a name="service-connect-envoy-access-logs-formats"></a>

アクセスログは、JSON 形式のディクショナリまたはテキスト形式の文字列のいずれかでフォーマットできますが、異なるタイプのアクセスログでサポートされているコマンド演算子は異なります。

### HTTP アクセスログ
<a name="service-connect-envoy-access-logs-formats-http"></a>

HTTP ログには、デフォルトで次のコマンド演算子が含まれています。

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration_ms": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%"
}
```

------

### HTTP2 アクセスログ
<a name="service-connect-envoy-access-logs-formats-http2"></a>

HTTP ログに含まれるコマンド演算子に加えて、HTTP2 ログにはデフォルトで `%STREAM_ID%` 演算子が含まれます。

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%STREAM_ID%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%",
  "stream_id": "%STREAM_ID%"
}
```

------

### gRPC アクセスログ
<a name="service-connect-envoy-access-logs-formats-grpc"></a>

HTTP ログに含まれるコマンド演算子に加えて、gRPC アクセスログにはデフォルトで `%STREAM_ID%` および `%GRPC_STATUS()%` の演算子が含まれます。

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %GRPC_STATUS()% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%STREAM_ID%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "grpc_status": "%GRPC_STATUS()%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%",
  "stream_id": "%STREAM_ID%"
}
```

------

### TCP アクセスログ
<a name="service-connect-envoy-access-logs-formats-tcp"></a>

次のコマンド演算子は、デフォルトで TCP アクセスログに含まれています。

------
#### [ Text ]

```
[%START_TIME%] %DOWNSTREAM_REMOTE_ADDRESS% %DOWNSTREAM_REMOTE_PORT% 
%BYTES_RECEIVED% %BYTES_SENT% %DURATION%  
%CONNECTION_TERMINATION_DETAILS% %CONNECTION_ID%\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%",
  "downstream_remote_port": "%DOWNSTREAM_REMOTE_PORT%",s
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "connection_termination_details": "%CONNECTION_TERMINATION_DETAILS%",
  "connection_id": %CONNECTION_ID%
}
```

------

これらのコマンド演算子の詳細については、Envoy ドキュメントの「[コマンド演算子](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators)」を参照してください。

# Amazon ECS Service Connect のアクセスログの有効化
<a name="service-connect-access-logs-configuration"></a>

Service Connect を使用する Amazon ECS サービスでは、アクセスログはデフォルトでは有効になっていません。以下の方法でアクセスログを有効にできます。

## AWS CLI を使用してアクセスログを有効にする
<a name="service-connect-access-logs-configure-cli"></a>

次のコマンドは、サービスの作成時に `accessLogConfiguration` を指定することで AWS CLI を使用して、Amazon ECS サービスのアクセスログを有効にする方法を示しています。

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-def \
    --service-connect-configuration '{
        "enabled": true,
        "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890",
        "services": [{
            "portName": "web",
            "discoveryName": "my-service",
            "clientAliases": [{
                "port": 80,
                "dnsName": "my-service"
            }]
        }],
        "logConfiguration": {
            "logDriver": "awslogs",
            "options": {
                "awslogs-group": "my-envoy-log-group",
                "awslogs-region": "us-west-2",
                "awslogs-stream-prefix": "myapp-envoy-logs"
            }
        },
         "accessLogConfiguration": {
            "format": "TEXT",
            "includeQueryParameters": "ENABLED" 
        }
    }'
```

## コンソールを使用してアクセスログを有効にする
<a name="service-connect-access-logs-configure-console"></a>

サービス作成手順の詳細については、「[Amazon ECS のローリング更新デプロイの作成](create-service-console-v2.md)」を参照してください。

**AWS マネジメントコンソールを使用して共有名前空間でサービスを作成するには**

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、サービスを作成するクラスターを選択します。

1. **[サービス]** で **[作成]** を選択します。

1. ワークロードに応じて他の詳細情報を入力したら、**[Service Connect]** セクションで **[Service Connect を使う]** を選択します。

1. 必要に応じて、サービスタイプ (クライアントまたはクライアントサーバー) の Service Connect 設定を構成します。

1. **[アクセスログ設定]** を展開します。**[形式]** で、**[JSON]** または [`TEXT`] を選択します。

1. アクセスログにクエリパラメータが含まれるようにするには、**[クエリパラメータを含める]** を選択します。

1. サービスの作成プロセスを完了します。

# Amazon ECS Service Connect トラフィックを暗号化する
<a name="service-connect-tls"></a>

Amazon ECS Service Connect は、Amazon ECS サービスの Transport Layer Security (TLS) 証明書による自動トラフィック暗号化をサポートしています。Amazon ECS サービスを [AWS Private Certificate Authority(AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) に向けると、Amazon ECS Service Connect 間のトラフィックを暗号化するための TLS 証明書が Amazon ECS によって自動的にプロビジョニングされます。Amazon ECS は、トラフィックの暗号化に使用される TLS 証明書を生成、ローテーション、および配布します。

Service Connect による自動トラフィック暗号化は、業界をリードする暗号化機能を使用してサービス間の通信を保護し、セキュリティ要件を満たすのに役立ちます。`256-bit ECDSA` および `2048-bit RSA` 暗号化で AWS Private Certificate Authority TLS 証明書と暗号化をサポートしています。また、プライベート証明書と署名キーを完全に制御できるため、コンプライアンス要件を満たすのに役立ちます。デフォルトでは、TLS 1.3 はサポートされていますが、TLS 1.0 ～ 1.2 はサポートされていません。Service Connect は、次の暗号を使用して TLS 1.3 をサポートしています。
+ `TLS_AES_128_GCM_SHA256`
+ `TLS_AES_256_GCM_SHA384`
+ `TLS_CHACHA20_POLY1305_SHA256`

**注記**  
TLS 1.3 を使用するには、ターゲットのリスナーでも有効にする必要があります。  
Amazon ECS エージェントを通過するインバウンドトラフィックとアウトバウンドトラフィックのみが暗号化されます。

## Service Connect と Application Load Balancer ヘルスチェック
<a name="service-connect-tls-alb-healthchecks"></a>

Service Connect は、Application Load Balancer のヘルスチェックと TLS 1.3 暗号化を使って使用できます。

### Application Load Balancer の設定
<a name="service-connect-tls-alb-config"></a>

Application Load Balancer を次の設定に従って設定します。
+ TLS 1.3 セキュリティポリシー (「ELBSecurityPolicy-TLS13-1-2-2021-06」など) を使用して TLS リスナーを設定します。詳細については、「[Application Load Balancer のセキュリティポリシー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html)」を参照してください。
+ 次の設定でターゲットグループを作成します。
  + プロトコルを HTTPS に設定します。
  + ターゲットグループを TLS リスナーにアタッチします。
  + Service Connect サービスのコンテナポートと一致するようにヘルスチェックポートを設定します。

### Service Connect の設定
<a name="service-connect-tls-sc-config"></a>

以下の設定を使用してサービスを設定します。
+ `bridge` ネットワークモードはサポートされていないため、`awsvpc` ネットワークモードを使用するようにサービスを設定します。
+ サービスの Service Connect を有効にします。
+ 次の設定を使用してロードバランサー設定をセットアップします。
  + Application Load Balancer 用に設定したターゲットグループを指定します。
  + Service Connect TLS サービスのコンテナポートと一致するようにコンテナポートを設定します。
+ サービスに `ingressPortOverride` を設定しないでください。詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)」を参照してください。

### 考慮事項
<a name="service-connect-tls-alb-considerations"></a>

Application Load Balancer、TLS、および Service Connect を使用する場合は、次の点を考慮してください。
+ Service Connect を TLS 暗号化で使用するときは、HTTPS ヘルスチェックに `bridge` ネットワークモードの代わりに `awsvpc` ネットワークモードを使用します。HTTP ヘルスチェックは引き続き `bridge` モードで動作します。
+ デフォルトの HTTPS ポート (443) ではなく、Service Connect サービスのコンテナポートと一致するようにターゲットグループのヘルスチェックポートを設定します。

## AWS Private Certificate Authority 証明書および Service Connect
<a name="service-connect-tls-certificates"></a>

インフラストラクチャ IAM ロールが必要です。このロールの詳細については、「[Amazon ECS インフラストラクチャの IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/infrastructure_IAM_role.html                     )」を参照してください。

**Service Connect 用の AWS Private Certificate Authority モード**

AWS Private Certificate Authority は汎用モードと短時間有効モードの 2 つのモードで実行できます。
+ 汎用 — 任意の有効期限を設定できる証明書を発行します。
+ 短い有効期間 — 最大有効期間が 7 日間の証明書。

Amazon ECS は両方のモードをサポートしていますが、有効期間の短い証明書を使用することをお勧めします。デフォルトでは、証明書は 5 日ごとにローテーションされ、短期モードで実行すると一般的な用途に比べてコストを大幅に節約できます。

Service Connect は証明書の失効をサポートしておらず、代わりに証明書を頻繁にローテーションする短い有効期間の証明書を利用します。[Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) の[マネージドローテーション](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_managed.html)を使用してローテーション頻度を変更したり、シークレットを無効化または削除したりする権限がありますが、これを行うと次のような結果が生じる可能性があります。
+ ローテーション頻度の短縮 - ローテーション頻度を短くすると、AWS Private CA、AWS KMS および Secrets Manager、Auto Scaling のローテーションのワークロードが増加するため、コストが高くなります。
+ ローテーション頻度が長い - ローテーション頻度が **7** 日を超えると、アプリケーションの通信は失敗します。
+ シークレットの削除 - シークレットを削除するとローテーションが失敗し、お客様のアプリケーション通信に影響があります。

シークレットローテーションに失敗すると、[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) で `RotationFailed` イベントがに公開されます。`RotationFailed` 用の [CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)を設定することもできます。

**重要**  
シークレットにレプリカリージョンを追加しないでください。これにより、Amazon ECS にはリージョンをレプリケーションから削除するアクセス許可がないため、Amazon ECS はシークレットを削除できなくなります。レプリケーションを既に追加している場合は、次のコマンドを実行します。  

```
aws secretsmanager remove-regions-from-replication \
 --secret-id SecretId \
 --remove-replica-regions region-name
```

**下位認証機関**  
AWS Private CA、ルートまたは下位を Service Connect TLS に導入して、サービスのエンドエンティティ証明書を発行できます。提供された発行者は、あらゆる場所で署名者および信頼の根源として扱われます。エンドエンティティ証明書は、アプリケーションのさまざまな部分について、さまざまな下位 CA から発行できます。AWS CLI を使用する際に、信頼チェーンを確立する CA の Amazon リソースネーム (ARN) を指定します。

**オンプレミス認証機関**  
オンプレミス CA を使用するには、AWS Private Certificate Authority で下位 CA を作成して設定します。これにより、Amazon ECS ワークロード用に発行されたすべての TLS 証明書が、オンプレミスで実行するワークロードとトラストチェーンを共有し、安全に接続できるようになります。

**重要**  
AWS Private CA に**必要な**タグ `AmazonECSManaged : true` を自分に追加してください。

**Infrastructure as Code**  
Infrastructure as Code (IaC) ツールで Service Connect TLS を使用する場合は、サービスがドレイン状態のままになるという問題を避けるため、依存関係を正しく設定することが重要です。AWS KMS キーが提供されている場合は、Amazon ECS サービスを終了した後、IAM ロールと AWS Private CA 依存関係を削除する必要があります。

Service Connect に使用される名前空間が共有名前空間である場合は、共有 AWS Private CA リソースを使用することを選択できます。詳細については、「*AWS Private Certificate Authority ユーザーガイド*」の「[クロスアカウントアクセス許可をアタッチする](https://docs.aws.amazon.com/privateca/latest/userguide/pca-ram.html)」を参照してください。

## Service Connect と Secrets Manager
<a name="service-connect-asm"></a>

**Amazon ECS Service Connect を TLS 暗号化で使用する場合、サービスは次の方法で Secrets Manager とやり取りします。**  
Service Connect は、提供されたインフラストラクチャロールを使用して Secrets Manager 内にシークレットを作成します。これらのシークレットは、Service Connect サービス間のトラフィックを暗号化するための TLS 証明書の関連するプライベートキーを保存するために使用されます。

**警告**  
Service Connect によるこれらのシークレットの自動作成と管理により、サービスに TLS 暗号化を実装するプロセスが合理化されます。ただし、潜在的なセキュリティへの影響に注意することが重要です。Secrets Manager への読み取りアクセス権を持つ他の IAM ロールは、自動的に作成されたシークレットにアクセスできる場合があります。これにより、アクセスコントロールが適切に設定されていない場合、機密性の高い暗号化マテリアルが権限のない当事者に公開される可能性があります。  
このリスクを軽減するには、次のベストプラクティスに従ってください。  
特に Service Connect によって作成されたシークレットについては、Secrets Manager へのアクセスを慎重に管理および制限します。
IAM ロールとそのアクセス許可を定期的に監査して、最小特権の原則が維持されていることを確認します。

Secrets Manager に読み取りアクセスを許可する場合は、Service Connect によって作成された TLS プライベートキーを除外することを検討してください。これを行うには、IAM ポリシーの条件を使用して、パターンに一致する ARN を持つシークレットを除外します。

```
"arn:aws:secretsmanager:::secret:ecs-sc!"
```

`ecs-sc!` プレフィックスを持つすべてのシークレットに対する `GetSecretValue` アクションを拒否する IAM ポリシーの例:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:*:*:secret:ecs-sc!*"
        }
    ]
}
```

------

**注記**  
これは一般的な例であり、特定のユースケースと AWS アカウント設定に基づいて調整する必要がある場合があります。IAM ポリシーは、セキュリティを維持しながら意図したアクセスを提供するように、常に徹底的なテストを行ってください。

Service Connect が Secrets Manager とやり取りする方法を理解することで、自動 TLS 暗号化の利点を活用しながら、Amazon ECS サービスのセキュリティをより適切に管理できます。

## Service Connect および AWS Key Management Service
<a name="service-connect-kms"></a>

[AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) を使用して、Service Connect リソースを暗号化および復号化できます。AWS KMS は、AWS によってデータを保護する暗号キーを作成および管理できるサービスです。

Service Connect で AWS KMS を使用する場合は、AWS が管理する AWS 所有キーを使用するか、既存の AWS KMS キーを選択できます。[新しい AWS KMS キーを作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)して使用することもできます。

**独自の暗号化キーを提供する**  
独自のキーマテリアルを提供することも、AWS Key Management Service を通じて外部キーストアを使用して独自のキーを AWS KMS へインポートし、Amazon ECS Service Connect でそのキーの Amazon リソースネーム (ARN) を指定することもできます。

AWS KMS ポリシーの例を次に示します。すべての *[ユーザー入力]* を独自の値に置き換えます。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "id",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/role-name"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyPair"
      ],
      "Resource": "*"
    }
  ]
}
```

------

キーポリシーの詳細については、「*AWS Key Management Service デベロッパーガイド*」の「[キーポリシーを作成する](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html)」を参照してください。

**注記**  
Service Connect は対称暗号化 AWS KMS キーのみをサポートします。他のタイプの AWS KMS キーを使用して Service Connect リソースを暗号化することはできません。AWS KMS キーが対称暗号化キーかどうかを判別するには、「[非対称 KMS キーを識別する](https://docs.aws.amazon.com/kms/latest/developerguide/identify-key-types.html#identify-asymm-keys)」を参照してください。

AWS Key Management Service 対称暗号化キーの詳細については、「*AWS Key Management Service デベロッパーガイド*」の「[対称暗号化 AWS KMS キー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks)」を参照してください。

# Amazon ECS Service Connect の TLS の有効化
<a name="enable-service-connect-tls"></a>

Service Connect サービスを作成または更新するとき、トラフィック暗号化を有効にします。

**AWS マネジメントコンソール を使用して既存のネームスペース内のサービスのトラフィック暗号化を有効にするには**

1. インフラストラクチャ IAM ロールが必要です。このロールの詳細については、「[Amazon ECS インフラストラクチャの IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/infrastructure_IAM_role.html                     )」を参照してください。

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. ナビゲーションペインで [**名前空間**] を選択します。

1. トラフィックの暗号化を有効にする **[サービス]** のある **[名前空間]** を選択します。

1. トラフィック暗号化を有効にする **[サービス]** を選択します。

1. 右上隅の **[サービスの更新]** を選択し、[Service Connect] セクションまでスクロールします。

1. サービス情報の下にある **[トラフィック暗号化を有効にする]** を選択して TLS を有効にします。

1. **[Service Connect TLS ロール]** では、既存のインフラストラクチャ IAM ロールを選択するか、新しいロールを作成します。

1. **[署名者認証機関]** では、既存の認証機関を選択するか、新しい認証機関を作成します。

   詳細については、「[AWS Private Certificate Authority 証明書および Service Connect](service-connect-tls.md#service-connect-tls-certificates)」を参照してください。

1. **AWS KMS key を選択** では、AWS を所有済みのマネージドキーを選択するか、別のキーを選択できます。新しいものを作成することもできます。

AWS CLI を使用してサービスの TLS を設定する例については、「[AWS CLI を使用した Amazon ECS Service Connect の設定](create-service-connect.md)」を参照してください。

# Amazon ECS Service Connect で TLS が有効になっていることを確認する
<a name="verify-tls-enabled"></a>

Service Connect は、Service Connect エージェントで TLS を開始し、宛先エージェントで TLS を終了します。その結果、アプリケーションコードが TLS のやりとりを認識することはありません。次の手順を使用して、TLS が有効になっていることを確認します。

1. アプリケーションイメージに `openssl` CLI を含めます。

1. SSM 経由でタスクに接続するには、サービスで [ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html) を有効にします。代わりに、サービスと同じ Amazon VPC で Amazon EC2 インスタンスを起動することもできます。

1. 検証したいサービスからタスクの IP とポートを取得します。タスクの IP アドレスは AWS Cloud Map コンソールで取得できます。この情報は、名前空間のサービス詳細ページに記載されています。

1. 次の例のように `execute-command` を使用して、タスクのいずれかにログオンします。または、**ステップ 2** で作成した Amazon EC2 インスタンスにログオンします。

   ```
   $ aws ecs execute-command --cluster cluster-name \
       --task task-id  \
       --container container-name \
       --interactive \
       --command "/bin/sh"
   ```
**注記**  
DNS 名を直接呼び出しても証明書は公開されません。

1. 接続したシェルで、`openssl` CLI を使用してタスクに添付されている証明書を確認および表示します。

   例:

   ```
   openssl s_client -connect 10.0.147.43:6379 < /dev/null 2> /dev/null \ 
   | openssl x509 -noout -text
   ```

   レスポンスの例:

   ```
   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number:
               <serial-number>
           Signature Algorithm: ecdsa-with-SHA256
           Issuer: <issuer>
           Validity
               Not Before: Jan 23 21:38:12 2024 GMT
               Not After : Jan 30 22:38:12 2024 GMT
           Subject: <subject>
           Subject Public Key Info:
               Public Key Algorithm: id-ecPublicKey
                   Public-Key: (256 bit)
                   pub:
                       <pub>
                   ASN1 OID: prime256v1
                   NIST CURVE: P-256
           X509v3 extensions:
               X509v3 Subject Alternative Name:
                   DNS:redis.yelb-cftc
               X509v3 Basic Constraints:
                   CA:FALSE
               X509v3 Authority Key Identifier:
                   keyid:<key-id>
   
               X509v3 Subject Key Identifier:
                   1D:<id>
               X509v3 Key Usage: critical
                   Digital Signature, Key Encipherment
               X509v3 Extended Key Usage:
                   TLS Web Server Authentication, TLS Web Client Authentication
       Signature Algorithm: ecdsa-with-SHA256
           <hash>
   ```

# AWS CLI を使用した Amazon ECS Service Connect の設定
<a name="create-service-connect"></a>

AWS CLI で Service Connect を使用する Fargate タスクで Amazon ECS サービスを作成できます。

**注記**  
デュアルスタックサービスエンドポイントを使用することで、IPv4 と IPv6 の両方を介して AWS CLI、SDK、および Amazon ECS API から Amazon ECS とやり取りできます。詳細については、「[Amazon ECS デュアルスタックエンドポイントの使用](dual-stack-endpoint.md)」を参照してください。

## 前提条件
<a name="create-service-connect-prereqs"></a>

Service Connect の前提条件は次のとおりです。
+ AWS CLI の最新バージョンがインストールされ、設定されていることを確認します。詳細については、「[AWS CLIの最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
+ IAM ユーザーに [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM ポリシー例で指定されている必要なアクセス権限があること。
+ VPC、サブネット、ルートテーブルおよびセキュリティグループが使用できるように作成されています。詳細については、「[仮想プライベートクラウドを作成する](get-set-up-for-amazon-ecs.md#create-a-vpc)」を参照してください。
+ `ecsTaskExecutionRole` という名前のタスク実行ロールがあり、`AmazonECSTaskExecutionRolePolicy` 管理ポリシーがそのロールにアタッチされています。このロールにより、Fargate は NGINX アプリケーションログと Service Connect プロキシログを Amazon CloudWatch Logs に書き込むことができます。詳細については、「[タスク実行 ロールの作成](task_execution_IAM_role.md#create-task-execution-role)」を参照してください。

## ステップ 1: クラスターを作成する
<a name="create-service-connect-cluster"></a>

次の手順に従って Amazon ECS クラスターと名前空間を作成します。

**Amazon ECS クラスターと AWS Cloud Map 名前空間を作成するには**

1. `tutorial` という名前の Amazon ECS クラスターを作成して使用します。パラメータ `--service-connect-defaults` は、クラスターのデフォルト名前空間を設定します。この出力の例では、`service-connect` という名前の AWS Cloud Map 名前空間はこのアカウントおよび AWS リージョンには存在しないため、名前空間は Amazon ECS によって作成されています。名前空間はアカウント内の AWS Cloud Map で作成され、他のすべての名前空間でも表示されるため、目的を示す名前を使用します。

   ```
   aws ecs create-cluster --cluster-name tutorial --service-connect-defaults namespace=service-connect
   ```

   出力:

   ```
   {
       "cluster": {
           "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
           "clusterName": "tutorial",
           "serviceConnectDefaults": {
               "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
           },
           "status": "PROVISIONING",
           "registeredContainerInstancesCount": 0,
           "runningTasksCount": 0,
           "pendingTasksCount": 0,
           "activeServicesCount": 0,
           "statistics": [],
           "tags": [],
           "settings": [
               {
                   "name": "containerInsights",
                   "value": "disabled"
               }
           ],
           "capacityProviders": [],
           "defaultCapacityProviderStrategy": [],
           "attachments": [
               {
                   "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
                   "type": "sc",
                   "status": "ATTACHING",
                   "details": []
               }
           ],
           "attachmentsStatus": "UPDATE_IN_PROGRESS"
       }
   }
   }
   ```

1. クラスターが作成されていることを確認します。

   ```
   aws ecs describe-clusters --clusters tutorial
   ```

   出力:

   ```
   {
       "clusters": [
           {
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
               "clusterName": "tutorial",
               "serviceConnectDefaults": {
                   "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
               },
               "status": "ACTIVE",
               "registeredContainerInstancesCount": 0,
               "runningTasksCount": 0,
               "pendingTasksCount": 0,
               "activeServicesCount": 0,
               "statistics": [],
               "tags": [],
               "settings": [],
               "capacityProviders": [],
               "defaultCapacityProviderStrategy": []
           }
       ],
       "failures": []
   }
   ```

1. (オプション) 名前空間が AWS Cloud Map で作成されていることを確認します。これは AWS Cloud Map で作成されているため、AWS マネジメントコンソールまたは通常の AWS CLI 構成を使用できます。

   例えば、以下の AWS CLI を使用します。

   ```
   aws servicediscovery get-namespace --id ns-EXAMPLE
   ```

   出力:

   ```
   {
       "Namespace": {
           "Id": "ns-EXAMPLE",
           "Arn": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE",
           "Name": "service-connect",
           "Type": "HTTP",
           "Properties": {
               "DnsProperties": {
                   "SOA": {}
               },
               "HttpProperties": {
                   "HttpName": "service-connect"
               }
           },
           "CreateDate": 1661749852.422,
           "CreatorRequestId": "service-connect"
       }
   }
   ```

## ステップ 2: サーバー用のサービスを作成する
<a name="create-service-connect-nginx-server"></a>

Service Connect 機能は、Amazon ECS 上の複数のアプリケーションを相互接続することを目的としています。これらのアプリケーションの少なくとも 1 つは、接続するウェブサービスを提供する必要があります。このステップでは、以下を作成します。
+ 未修正の公式 NGINX コンテナイメージを使用し、Service Connect 設定を含むタスク定義。
+ このサービスへのトラフィック用にサービス検出とサービスメッシュプロキシを提供するために Service Connect を設定する Amazon ECS サービス定義。この構成では、クラスター構成からデフォルトの名前空間を再利用することで、各サービスに対して行うサービス構成の量を減らします。
+ Amazon ECS サービス。タスク定義を使用して 1 つのタスクを実行し、Service Connect プロキシ用の追加コンテナを挿入します。プロキシは、タスク定義のコンテナポートマッピングからポートをリッスンします。Amazon ECS で実行されているクライアントアプリケーションで、クライアントタスクのプロキシは、タスク定義ポート名、サービス検出名またはサービスクライアントエイリアス名、およびクライアントエイリアスからのポート番号へのアウトバウンド接続をリッスンします。

**Service Connect を使用してウェブサービスを作成するには**

1. Fargate と互換性があり、`awsvpc` ネットワークモードを使用するタスク定義を登録します。以下の手順に従ってください。

   1. 次のタスク定義の内容で、`service-connect-nginx.json` というファイルを作成します。

      このタスク定義は、ポートマッピングに `name` および `appProtocol` パラメータを追加することによって Service Connect を構成します。複数のポートが使用されている場合、ポート名によりサービス構成でこのポートをより識別しやすくなります。また、ポート名は、名前空間内の他のアプリケーションが使用する検出可能な名前としてもデフォルトで使用されています。

      サービスでは ECS Exec が有効になっているため、タスク定義にはタスク IAM ロールが含まれています。
**重要**  
このタスク定義では、`logConfiguration` を使用して `stdout` および `stderr` から Amazon CloudWatch Logs に nginx 出力を送信します。このタスク実行ロールには、CloudWatch Logs ロググループを作成するために必要な追加の権限はありません。AWS マネジメントコンソールまたは AWS CLI を使用して、CloudWatch Logs にロググループを作成します。nginx ログを CloudWatch Logs に送信したくない場合、`logConfiguration` を削除できます。  
タスク実行ロールの AWS アカウント ID を AWS アカウント ID に置き換えます。

      ```
      {
          "family": "service-connect-nginx",
          "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
          "taskRoleArn": "arn:aws:iam::123456789012:role/ecsTaskRole",
          "networkMode": "awsvpc",
          "containerDefinitions": [
              {
              "name": "webserver",
              "image": "public.ecr.aws/docker/library/nginx:latest",
              "cpu": 100,
              "portMappings": [
                  {
                      "name": "nginx",
                      "containerPort": 80,
                      "protocol": "tcp", 
                      "appProtocol": "http"
                  }
              ],
              "essential": true,
              "logConfiguration": {
                  "logDriver": "awslogs",
                  "options": {
                      "awslogs-group": "/ecs/service-connect-nginx",
                      "awslogs-region": "region", 
                      "awslogs-stream-prefix": "nginx"
                  }
              }
              }
          ],
          "cpu": "256",
          "memory": "512"
      }
      ```

   1. 次の `service-connect-nginx.json` ファイルを使用して、タスク定義を登録します。

      ```
      aws ecs register-task-definition --cli-input-json file://service-connect-nginx.json
      ```

1. サービスを作成します。

   1. 作成する Amazon ECS サービスの内容で、`service-connect-nginx-service.json` という名前のファイルを作成します。この例では、前のステップで作成したタスク定義を使用します。このタスク定義の例では `awsvpc` ネットワークモードを使用しているため、`awsvpcConfiguration` が必要となります。

      ECS サービスを作成する際に、Fargate と、Service Connect をサポートする `LATEST` プラットフォームバージョンを指定します。`securityGroups` および `subnets` は、Amazon ECS を使用するための要件を満たしている VPC に属している必要があります。Amazon VPC コンソールからセキュリティグループとサブネット ID を取得できます。

      このサービスは、`serviceConnectConfiguration` パラメータを追加して Service Connect を設定します。クラスターにはデフォルトの名前空間が設定されているため、名前空間は必要ありません。名前空間内の ECS で実行されているクライアントアプリケーションは、`portName` および `clientAliases` のポートを使用してこのサービスに接続します。例えば、nginx はルートロケーション `/` にウェルカムページを提供しているため、`http://nginx:80/` を使用してこのサービスにアクセスできます。Amazon ECS で実行されていない、または同じ名前空間にない外部アプリケーションは、タスクの IP アドレスとタスク定義のポート番号を使用して、Service Connect プロキシ経由でこのアプリケーションにアクセスできます。ご使用の `tls` 設定に合わせて、`awsPcaAuthorityArn`、`kmsKey` および IAM ロールの `roleArn` に対する証明書 `arn` を追加します。

      このサービスは、`logConfiguration` を使用して `stdout` および `stderr` から Amazon CloudWatch Logs にサービス接続プロキシの出力を送信します。このタスク実行ロールには、CloudWatch Logs ロググループを作成するために必要な追加の権限はありません。AWS マネジメントコンソールまたは AWS CLI を使用して、CloudWatch Logs にロググループを作成します。このロググループを作成し、CloudWatch Logs にプロキシログを保存することをお勧めします。プロキシログを CloudWatch Logs に送信したくない場合、`logConfiguration` を削除できます。

      ```
      {
          "cluster": "tutorial",
          "deploymentConfiguration": {
              "maximumPercent": 200,
              "minimumHealthyPercent": 0
          },
          "deploymentController": {
              "type": "ECS"
          },
          "desiredCount": 1,
          "enableECSManagedTags": true,
          "enableExecuteCommand": true,
          "launchType": "FARGATE",
          "networkConfiguration": {
              "awsvpcConfiguration": {
                  "assignPublicIp": "ENABLED",
                  "securityGroups": [
                      "sg-EXAMPLE"
                  ],
                  "subnets": [
                      "subnet-EXAMPLE",
                      "subnet-EXAMPLE",
                      "subnet-EXAMPLE"
                  ]
                 }
          },
          "platformVersion": "LATEST",
          "propagateTags": "SERVICE",
          "serviceName": "service-connect-nginx-service",
          "serviceConnectConfiguration": {
              "enabled": true,
              "services": [
                  {
                      "portName": "nginx",
                      "clientAliases": [
                          {
                              "port": 80
                          }
                      ],
                      "tls": {
                         "issuerCertificateAuthority": {
                            "awsPcaAuthorityArn": "certificateArn"
                         }, 
                         "kmsKey": "kmsKey", 
                         "roleArn": "iamRoleArn"
                      }
                  }
              ],
              "logConfiguration": {
                  "logDriver": "awslogs",
                  "options": {
                      "awslogs-group": "/ecs/service-connect-proxy",
                      "awslogs-region": "region",
                      "awslogs-stream-prefix": "service-connect-proxy"
                  }
              }
          },
          "taskDefinition": "service-connect-nginx"
      }
      ```

   1. 次の `service-connect-nginx-service.json` のファイルを使用して、サービスを作成します。

      ```
      aws ecs create-service --cluster tutorial --cli-input-json file://service-connect-nginx-service.json
      ```

      出力:

      ```
      {
          "service": {
              "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/tutorial/service-connect-nginx-service",
              "serviceName": "service-connect-nginx-service",
              "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
              "loadBalancers": [],
              "serviceRegistries": [],
              "status": "ACTIVE",
              "desiredCount": 1,
              "runningCount": 0,
              "pendingCount": 0,
              "launchType": "FARGATE",
              "platformVersion": "LATEST",
              "platformFamily": "Linux",
              "taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
              "deploymentConfiguration": {
                  "deploymentCircuitBreaker": {
                      "enable": false,
                      "rollback": false
                  },
                  "maximumPercent": 200,
                  "minimumHealthyPercent": 0
              },
              "deployments": [
                  {
                      "id": "ecs-svc/3763308422771520962",
                      "status": "PRIMARY",
                      "taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
                      "desiredCount": 1,
                      "pendingCount": 0,
                      "runningCount": 0,
                      "failedTasks": 0,
                      "createdAt": 1661210032.602,
                      "updatedAt": 1661210032.602,
                      "launchType": "FARGATE",
                      "platformVersion": "1.4.0",
                      "platformFamily": "Linux",
                      "networkConfiguration": {
                          "awsvpcConfiguration": {
                              "assignPublicIp": "ENABLED",
                              "securityGroups": [
                                  "sg-EXAMPLE"
                              ],
                              "subnets": [
                                  "subnet-EXAMPLEf",
                                  "subnet-EXAMPLE",
                                  "subnet-EXAMPLE"
                              ]
                          }
                      },
                      "rolloutState": "IN_PROGRESS",
                      "rolloutStateReason": "ECS deployment ecs-svc/3763308422771520962 in progress.",
                      "failedLaunchTaskCount": 0,
                      "replacedTaskCount": 0,
                      "serviceConnectConfiguration": {
                          "enabled": true,
                          "namespace": "service-connect",
                          "services": [
                              {
                                  "portName": "nginx",
                                  "clientAliases": [
                                      {
                                          "port": 80
                                      }
                                  ]
                              }
                          ],
                          "logConfiguration": {
                              "logDriver": "awslogs",
                              "options": {
                                  "awslogs-group": "/ecs/service-connect-proxy",
                                  "awslogs-region": "us-west-2",
                                  "awslogs-stream-prefix": "service-connect-proxy"
                              },
                              "secretOptions": []
                          }
                      },
                      "serviceConnectResources": [
                          {
                              "discoveryName": "nginx",
                              "discoveryArn": "arn:aws:servicediscovery:us-west-2:123456789012:service/srv-EXAMPLE"
                          }
                      ]
                  }
              ],
              "roleArn": "arn:aws:iam::123456789012:role/aws-service-role/ecs.amazonaws.com/AWSServiceRoleForECS",
              "version": 0,
              "events": [],
              "createdAt": 1661210032.602,
              "placementConstraints": [],
              "placementStrategy": [],
              "networkConfiguration": {
                  "awsvpcConfiguration": {
                      "assignPublicIp": "ENABLED",
                      "securityGroups": [
                          "sg-EXAMPLE"
                      ],
                      "subnets": [
                          "subnet-EXAMPLE",
                          "subnet-EXAMPLE",
                          "subnet-EXAMPLE"
                      ]
                  }
              },
              "schedulingStrategy": "REPLICA",
              "enableECSManagedTags": true,
              "propagateTags": "SERVICE",
              "enableExecuteCommand": true
          }
      }
      ```

      指定した `serviceConnectConfiguration` は、出力の最初の*デプロイ*内に表示されます。タスクに変更を加える必要がある方法で ECS サービスを変更すると、Amazon ECS によって新しいデプロイが作成されます。

## ステップ 3: 接続できることを確認する
<a name="create-service-connect-verify"></a>

Service Connect が設定され動作していることを確認するには、次の手順に従って外部アプリケーションからウェブサービスに接続します。次に、Service Connect プロキシが作成した CloudWatch にある追加のメトリクスを確認します。

**外部アプリケーションからウェブサービスに接続するには**
+ タスク IP アドレスを使用して、タスク IP アドレスとコンテナポートに接続する

  AWS CLI を使用して `aws ecs list-tasks --cluster tutorial` を使用したタスク ID を取得します。

  サブネットとセキュリティグループがタスク定義のポート上のパブリックインターネットからのトラフィックを許可している場合、コンピュータからパブリック IP に接続できます。ただし、パブリック IP は「describe-tasks」からは利用できないため、手順として、Amazon EC2 AWS マネジメントコンソールまたは AWS CLI に移動して Elastic Network Interface の詳細を取得する必要があります。

  この例では、同じ VPC 内の Amazon EC2 インスタンスはタスクのプライベート IP を使用します。アプリケーションは nginx ですが、`server: envoy` ヘッダーには Service Connect プロキシが使用されていることが表示されます。Service Connect プロキシはタスク定義のコンテナポートをリッスンしています。

  ```
  $ curl -v 10.0.19.50:80/
  *   Trying 10.0.19.50:80...
  * Connected to 10.0.19.50 (10.0.19.50) port 80 (#0)
  > GET / HTTP/1.1
  > Host: 10.0.19.50
  > User-Agent: curl/7.79.1
  > Accept: */*
  >
  * Mark bundle as not supporting multiuse
  < HTTP/1.1 200 OK
  < server: envoy
  < date: Tue, 23 Aug 2022 03:53:06 GMT
  < content-type: text/html
  < content-length: 612
  < last-modified: Tue, 16 Apr 2019 13:08:19 GMT
  < etag: "5cb5d3c3-264"
  < accept-ranges: bytes
  < x-envoy-upstream-service-time: 0
  <
  <!DOCTYPE html>
  <html>
  <head>
  <title>Welcome to nginx!</title>
  <style>
      body {
          width: 35em;
          margin: 0 auto;
          font-family: Tahoma, Verdana, Arial, sans-serif;
      }
  </style>
  </head>
  <body>
  <h1>Welcome to nginx!</h1>
  <p>If you see this page, the nginx web server is successfully installed and
  working. Further configuration is required.</p>
  
  <p>For online documentation and support please refer to
  <a href="http://nginx.org/">nginx.org</a>.<br/>
  Commercial support is available at
  <a href="http://nginx.com/">nginx.com</a>.</p>
  
  <p><em>Thank you for using nginx.</em></p>
  </body>
  </html>
  ```

**Service Connect メトリクスを表示するには**  
Service Connect プロキシは、アプリケーション (HTTP、HTTP2、gRPC、または TCP 接続) メトリクスを CloudWatch メトリクス内に作成します。CloudWatch コンソールを使用する場合、Amazon ECS 名前空間にある **[DiscoveryName]**、(**[DiscoveryName, ServiceName, ClusterName]**)、**[TargetDiscoveryName]**、および (**[TargetDiscoveryName, ServiceName, ClusterName]**) という追加のメトリクスディメンションを確認します。これらのメトリクスおよびディメンションの詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「[利用可能なメトリクスを表示する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html)」を参照してください。

# サービス検出を使用して Amazon ECS サービスを DNS 名で接続する
<a name="service-discovery"></a>

Amazon ECS サービスはオプションで Amazon ECS サービス検出を使用するように設定できます。サービス検出では、AWS Cloud MapAmazon ECS サービスの HTTP および DNS 名前空間を管理する API アクション。詳細については、『[AWS Cloud Map 開発者ガイド](https://docs.aws.amazon.com/cloud-map/latest/dg/Welcome.html)』の「*AWS Cloud Map とは*」を参照してください。

サービスの検出はリ以下のAWSージョンで使用できます。


| リージョン名 | リージョン | 
| --- | --- | 
|  米国東部 (バージニア北部)  |  us-east-1  | 
|  米国東部 (オハイオ)  |  us-east-2  | 
|  米国西部 (北カリフォルニア)  |  us-west-1  | 
|  米国西部 (オレゴン)  |  us-west-2  | 
|  アフリカ (ケープタウン)  |  af-south-1  | 
|  アジアパシフィック (香港)  |  ap-east-1  | 
|  アジアパシフィック (台北)  |  ap-east-2  | 
|  アジアパシフィック (ムンバイ)  |  ap-south-1  | 
|  アジアパシフィック (ハイデラバード)  |  ap-south-2  | 
|  アジアパシフィック (東京)  |  ap-northeast-1  | 
|  アジアパシフィック (ソウル)  |  ap-northeast-2  | 
|  アジアパシフィック (大阪)  |  ap-northeast-3  | 
|  アジアパシフィック (シンガポール)  |  ap-southeast-1  | 
|  アジアパシフィック (シドニー)  |  ap-southeast-2  | 
|  アジアパシフィック (ジャカルタ)  |  ap-southeast-3  | 
|  アジアパシフィック (メルボルン)  |  ap-southeast-4  | 
|  アジアパシフィック (マレーシア)  |  ap-southeast-5  | 
|  アジアパシフィック (ニュージーランド)  |  ap-southeast-6  | 
|  アジアパシフィック (タイ)  |  ap-southeast-7  | 
|  カナダ (中部)  |  ca-central-1  | 
|  カナダ西部 (カルガリー)  |  ca-west-1  | 
|  中国 (北京)  |  cn-north-1  | 
|  中国 (寧夏)  |  cn-northwest-1  | 
|  欧州 (フランクフルト)  |  eu-central-1  | 
|  欧州 (チューリッヒ)  |  eu-central-2  | 
|  欧州 (アイルランド)  |  eu-west-1  | 
|  欧州 (ロンドン)  |  eu-west-2  | 
|  欧州 (パリ)  |  eu-west-3  | 
|  欧州 (ミラノ)  |  eu-south-1  | 
|  欧州 (ストックホルム)  |  eu-north-1  | 
|  イスラエル (テルアビブ)  |  il-central-1  | 
|  欧州 (スペイン)  |  eu-south-2  | 
|  中東 (アラブ首長国連邦)  |  me-central-1  | 
|  メキシコ (中部)  |  mx-central-1  | 
|  中東 (バーレーン)  |  me-south-1  | 
|  南米 (サンパウロ）  |  sa-east-1  | 
|  AWS GovCloud (米国東部)  |  us-gov-east-1  | 
|  AWS GovCloud (米国西部)  |  us-gov-west-1  | 

## サービス検出の概念
<a name="service-discovery-concepts"></a>

サービス検出は次のコンポーネントで構成されます。
+ **サービス検出名前空間**: 同じドメイン名 (`example.com` など) を共有するサービス検出サービスの論理グループです。ここにトラフィックをルーティングします。`aws servicediscovery create-private-dns-namespace` コマンドを呼び出しまたは Amazon ECS のコンソールを使用して名前空間を作成できます。`aws servicediscovery list-namespaces` コマンドを使用して、現在のアカウントで作成された名前空間に関するサマリー情報を確認できます。サービス検出コマンドの詳細については、「AWS Cloud Map (サービス検出) AWS CLI Reference Guide」の「`[create-private-dns-namespace](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/create-private-dns-namespace.html)`」および「`[list-namespaces](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/list-namespaces.html)`」を参照してください。
+ **サービス検出サービス**: サービス検出名前空間にあり、名前空間のサービス名および DNS 設定から構成されます。これは、次の主要なコンポーネントを提供します。
  + **サービスレジストリ**: DNS あるいは AWS Cloud Map API アクションを介してサービスを検索し、サービスに接続するために使用できる 1 つ以上の利用可能なエンドポイントを返すことができます。
+ **サービスディスカバリインスタンス**: サービスディスカバリサービスにあり、サービスディレクトリ内の各 Amazon ECS サービスに関連付けられた属性で構成されます。
  + **インスタンスの属性**: 次のメタデータは、サービスディスカバリ を使用するように設定された各 Amazon ECS サービスのカスタム属性として追加されます。
    + **`AWS_INSTANCE_IPV4`** –`A` レコードの場合、インスタンスの詳細が検出されると、Route 53 など、DNS クエリへの応答として AWS Cloud Map が返す IPv4 アドレスおよび `192.0.2.44` が返されます。
    + **`AWS_INSTANCE_IPV6`** –`AAAA` レコードの場合は、インスタンスの詳細が検出されると、Route 53 など、DNS クエリへの応答として AWS Cloud Map が返す IPv6 アドレスおよび ` 2001:0db8:85a3:0000:0000:abcd:0001:2345` が返されます。`AWS_INSTANCE_IPv4` と `AWS_INSTANCE_IPv6` の両方が Amazon ECS デュアルスタックサービスに追加されます。Amazon ECS IPv6 専用サービスにのみ `AWS_INSTANCE_IPv6` が追加されます。
    + **`AWS_INSTANCE_PORT`** – サービスディスカバリサービスに関連付けられたポート値。
    + **`AVAILABILITY_ZONE`** – タスクが起動したアベイラビリティーゾーン。EC2 を使用するタスクの場合、これはコンテナインスタンスが存在するアベイラビリティーゾーンです。Fargate を使用するタスクの場合、これは Elastic Network Interface が存在するアベイラビリティーゾーンです。
    + **`REGION`** タスクが存在するリージョン。
    + **`ECS_SERVICE_NAME`** – タスクが属している Amazon ECS サービスの名前。
    + **`ECS_CLUSTER_NAME`** – タスクが属している Amazon ECS クラスターの名前。
    + **`EC2_INSTANCE_ID`** タスクが配置されていたコンテナインスタンスの ID。タスクが Fargate を使用している場合、このカスタム属性は追加されません。
    + **`ECS_TASK_DEFINITION_FAMILY`** タスクが使用しているタスク定義ファミリー。
    + **`ECS_TASK_SET_EXTERNAL_ID`** タスクセットが外部デプロイ用に作成され、サービス検出レジストリに関連付けられている場合、`ECS_TASK_SET_EXTERNAL_ID` 属性にはタスクセットの外部 ID が含まれます。
+ **Amazon ECS ヘルスチェック**: Amazon ECS はコンテナレベルのヘルスチェックを定期的に実行します。エンドポイントがヘルスチェックに失敗した場合、このエンドポイントは DNS ルーチングから削除され、異常とマークされます。

## サービスの検出に関する考慮事項
<a name="service-discovery-considerations"></a>

サービス検出を使用する際には、以下の点を考慮する必要があります。
+ プラットフォームバージョンが v1.1.0 以降を使用する場合、サービスの検出は Fargate タスクでサポートされます。詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。
+ サービス検出を使用するように構成されたサービスには、サービスごとに 1,000 タスクに制限があります。これは、Route 53 サービスクォータによるものです。
+ Amazon ECS コンソールでのサービスの作成ワークフローでは、プライベート DNS 名前空間へのサービスの登録のみがサポートされます。AWS Cloud Map プライベート DNS 名前空間が作成されると、Route 53 プライベートホストゾーンが自動的に作成されます。
+ DNS 解決を成功させるには、VPC DNS 属性を設定する必要があります。属性の設定方法については、を参照してください。[VPC の DNS サポート](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support)の*Amazon VPC User Guide*。
+ Amazon ECS は、共有 AWS Cloud Map 名前空間へのサービスの登録をサポートしていません。
+ パブリック名前空間が使用されている場合でも、 サービス用に作成された DNS レコードは、パブリック IP アドレスではなく、タスクのプライベート IP アドレスに常に登録されます。
+ &service-discovery-first; では、`awsvpc`、`bridge`、`host` のいずれかのネットワークモードをタスクで指定する必要があります (`none` はサポートされていません)。
+ サービスタスク定義が `awsvpc` ネットワークモードを使用する場合、各サービスタスクに `A` または `SRV` のレコードを自由に組み合わせて作成できます。`SRV` レコードを使用する場合は、ポートが必要です。サービスがデュアルスタックサブネットを使用している場合は、さらに `AAAA` レコードを作成できます。サービスが IPv6 専用サブネットを使用している場合、`A` レコードを作成することはできません。
+ サービスタスク定義が `bridge` または `host` ネットワークモードを使用する場合、SRV レコードのみがサポートされる DNS レコードタイプです。各サービスタスクの SRV レコードを作成します。SRV レコードのコンテナ名とコンテナポートの組み合わせをタスク定義から指定する必要があります。
+ サービスの検出サービスの DNS レコードは、VPC 内でクエリを実行できます。これは、次の形式を使用します: `<service-discovery-service-name>.<service-discovery-namespace>`。
+ サービス名で DNS クエリを実行すると、`A` と `AAAA` のレコードはタスクに対応する IP アドレスのセットを返します。`SRV` は、各タスクの IP アドレスとポートのセットを返します。
+ 8 つ以下の正常なレコードがある場合、Route 53 はすべての DNS クエリに正常なすべてのレコードを返します。
+ すべてのレコードが異常である場合、Route 53 は DNS クエリに最大 8 つの異常なレコードを返します。
+ サービス検出はロードバランサーの背後にあるサービスに設定できますが、サービス検出トラフィックは必ずタスクにルーティングされ、ロードバランサーにはルーティングされません。
+ サービス検出は Classic Load Balancer の使用をサポートしていません。
+ Amazon ECS サービスのサービス検出により管理されるコンテナレベルのヘルスチェックを使用することをお勧めします。
  + **HealthCheckCustomConfig**—Amazon ECS; はユーザーに代わってヘルスチェックを管理します。Amazon ECS は、コンテナとヘルスチェックの情報、およびタスクの状態を使用して、ヘルスを AWS Cloud Map で更新します。これは、`--health-check-custom-config`パラメータを使用してサービス検出サービスの作成時に指定します。詳細については、*AWS Cloud MapAPI リファレンス*の「[HealthCheckCustomConfig](https://docs.aws.amazon.com/cloud-map/latest/api/API_HealthCheckCustomConfig.html)」を参照してください。
+ サービス検出を使用するときに作成される AWS Cloud Map リソースは、手動でクリーンアップする必要があります。
+ タスクとインスタンスはコンテナのヘルスチェックが値を返すまで `UNHEALTHY` として登録されます。ヘルスチェックが成功した場合、ステータスは `HEALTHY` に更新されます。コンテナのヘルスチェックに失敗すると、サービス検出インスタンスは登録解除されます。

## サービス検出の料金
<a name="service-discovery-pricing"></a>

Amazon ECS サービスディスカバリを使用しているお客様には、Route 53 リソースおよび AWS Cloud Map 検出 API オペレーションの料金が発生します。これには、Route 53 ホストゾーンの作成とサービスレジストリへのクエリのコストが含まれます。詳細については、*AWS Cloud Mapデベロッパーガイド*のの概念および[AWS Cloud Mapの料金](https://docs.aws.amazon.com/cloud-map/latest/dg/cloud-map-pricing.html)を参照してください。

Amazon ECS は、コンテナレベルのヘルスチェックを実行し、この結果を AWS Cloud Map カスタムヘルスチェック API オペレーションに公開します。現在のところ、これは追加コストなしでお客様に提供されています。パブリックに公開されているタスクにネットワークヘルスチェックを設定する場合、このヘルスチェックに対しては課金されます。

# サービス検出を使用する新しい Amazon ECS サービスの作成
<a name="create-service-discovery"></a>

AWS CLI でサービス検出を使用する Fargate タスクを含むサービスを作成する方法について説明します。

サービス検出をサポートする AWS リージョン のリストについては、「[サービス検出を使用して Amazon ECS サービスを DNS 名で接続する](service-discovery.md)」を参照してください。

Fargate をサポートするリージョンの情報については、「[AWS Fargate で使用する Amazon ECS でサポートされているリージョン](AWS_Fargate-Regions.md)」 を参照してください。

**注記**  
デュアルスタックサービスエンドポイントを使用することで、IPv4 と IPv6 の両方を介して AWS CLI、SDK、および Amazon ECS API から Amazon ECS とやり取りできます。詳細については、「[Amazon ECS デュアルスタックエンドポイントの使用](dual-stack-endpoint.md)」を参照してください。

## 前提条件
<a name="create-service-discovery-prereqs"></a>

個のチュートリアルを開始する前に、次の前提条件を満たしていることを確認します。
+ AWS CLI の最新バージョンがインストールされ、設定されていること。詳細については、「[AWS CLIの最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
+ 「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」で説明されているステップが完了しました。
+ IAM ユーザーに [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM ポリシー例で指定されている必要なアクセス権限があること。
+ 少なくとも 1 つの VPC と 1 つのセキュリティグループを作成している。詳細については、「[仮想プライベートクラウドを作成する](get-set-up-for-amazon-ecs.md#create-a-vpc)」を参照してください。

## ステップ 1: AWS Cloud Map でサービス検出リソースを作成する
<a name="create-service-discovery-namespace"></a>

サービス検出の名前空間およびサービス検出サービスを作成するには、次のステップに従います。

1. プライベート Cloud Map サービス検出の名前空間を作成します。この例では、`tutorial` と呼ばれる名前空間を作成します。*vpc-abcd1234* を、既存のいずれかの VPC の ID に置き換えます。

   ```
   aws servicediscovery create-private-dns-namespace \
         --name tutorial \
         --vpc vpc-abcd1234
   ```

   このコマンドの出力は次のとおりです。

   ```
   {
       "OperationId": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e"
   }
   ```

1. 前のステップの出力の `OperationId` を使用して、プライベート名前空間が正常に作成されたことを確認します。名前空間 ID は後続のコマンドで使用するため、書き留めておきます。

   ```
   aws servicediscovery get-operation \
         --operation-id h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e
   ```

   出力は次のとおりです。

   ```
   {
       "Operation": {
           "Id": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e",
           "Type": "CREATE_NAMESPACE",
           "Status": "SUCCESS",
           "CreateDate": 1519777852.502,
           "UpdateDate": 1519777856.086,
           "Targets": {
              "NAMESPACE": "ns-uejictsjen2i4eeg"
           }
       }
   }
   ```

1. 前のステップの出力からの `NAMESPACE` ID を使用して、サービス検出サービスを作成します。この例では、`myapplication` という名前のサービスが作成されます。サービス ID と ARN は後続のコマンドで使用するため、書き留めておきます。

   ```
   aws servicediscovery create-service \
         --name myapplication \
         --dns-config "NamespaceId="ns-uejictsjen2i4eeg",DnsRecords=[{Type="A",TTL="300"}]" \
         --health-check-custom-config FailureThreshold=1
   ```

   出力は次のとおりです。

   ```
   {
       "Service": {
          "Id": "srv-utcrh6wavdkggqtk",
           "Arn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk",
           "Name": "myapplication",
           "DnsConfig": {
               "NamespaceId": "ns-uejictsjen2i4eeg",
               "DnsRecords": [
                   {
                       "Type": "A",
                       "TTL": 300
                   }
               ]
           },
           "HealthCheckCustomConfig": {
               "FailureThreshold": 1
           },
           "CreatorRequestId": "e49a8797-b735-481b-a657-b74d1d6734eb"
       }
   }
   ```

## ステップ 2: Amazon ECS リソースを作成する
<a name="create-service-discovery-cluster"></a>

Amazon ECS クラスター、タスク定義、サービスを作成するには、次のステップに従います。

1. Amazon ECS クラスターを作成します。この例では、`tutorial` という名前のクラスターを作成します。

   ```
   aws ecs create-cluster \
         --cluster-name tutorial
   ```

1. Fargate と互換性があり、`awsvpc` ネットワークモードを使用するタスク定義を登録します。以下の手順に従ってください。

   1. 次のタスク定義の内容で、`fargate-task.json` というファイルを作成します。

      ```
      {
          "family": "tutorial-task-def",
              "networkMode": "awsvpc",
              "containerDefinitions": [
                  {
                      "name": "sample-app",
                      "image": "public.ecr.aws/docker/library/httpd:2.4",
                      "portMappings": [
                          {
                              "containerPort": 80,
                              "hostPort": 80,
                              "protocol": "tcp"
                          }
                      ],
                      "essential": true,
                      "entryPoint": [
                          "sh",
                          "-c"
                      ],
                      "command": [
                          "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
                      ]
                  }
              ],
              "requiresCompatibilities": [
                  "FARGATE"
              ],
              "cpu": "256",
              "memory": "512"
      }
      ```

   1. `fargate-task.json` を使用してタスク定義を登録します。

      ```
      aws ecs register-task-definition \
            --cli-input-json file://fargate-task.json
      ```

1. 次のステップに従って、ECS サービスを作成します。

   1. 作成する ECS サービスの内容で、`ecs-service-discovery.json` という名前のファイルを作成します。この例では、前のステップで作成したタスク定義を使用します。このタスク定義の例では `awsvpc` ネットワークモードを使用しているため、`awsvpcConfiguration` が必要となります。

      ECS サービスを作成する際に、Fargate と、サービス検出をサポートする `LATEST` プラットフォームバージョンを指定します。AWS Cloud Map でサービス検出サービスが作成される場合、`registryArn` は返される ARN です。`securityGroups` および `subnets` は、Cloud Map 名前空間の作成に使用される VPC に属している必要があります。Amazon VPC コンソールからセキュリティグループとサブネット ID を取得できます。

      ```
      {
          "cluster": "tutorial",
          "serviceName": "ecs-service-discovery",
          "taskDefinition": "tutorial-task-def",
          "serviceRegistries": [
             {
                "registryArn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk"
             }
          ],
          "launchType": "FARGATE",
          "platformVersion": "LATEST",
          "networkConfiguration": {
             "awsvpcConfiguration": {
                "assignPublicIp": "ENABLED",
                "securityGroups": [ "sg-abcd1234" ],
                "subnets": [ "subnet-abcd1234" ]
             }
          },
          "desiredCount": 1
      }
      ```

   1. `ecs-service-discovery.json` を使用して ECS サービスを作成します。

      ```
      aws ecs create-service \
            --cli-input-json file://ecs-service-discovery.json
      ```

## ステップ 3: AWS Cloud Map でサービス検出を検証する
<a name="create-service-discovery-verify"></a>

サービス検出情報をクエリして、すべてが正常に作成されたことを確認します。サービス検出を設定した後、AWS Cloud Map API オペレーションを使用するか、VPC 内のインスタンスから `dig` を呼び出すことができます。以下の手順に従ってください。

1. サービス検出サービス ID を使用して、サービス検出インスタンスを一覧表示します。リソースクリーンアップのインスタンス ID (太字でマーク) を書き留めます。

   ```
    aws servicediscovery list-instances \
          --service-id srv-utcrh6wavdkggqtk
   ```

   出力は次のとおりです。

   ```
   {
       "Instances": [
           {
               "Id": "16becc26-8558-4af1-9fbd-f81be062a266",
               "Attributes": {
                   "AWS_INSTANCE_IPV4": "172.31.87.2"
                   "AWS_INSTANCE_PORT": "80", 
                   "AVAILABILITY_ZONE": "us-east-1a", 
                   "REGION": "us-east-1", 
                   "ECS_SERVICE_NAME": "ecs-service-discovery", 
                   "ECS_CLUSTER_NAME": "tutorial", 
                   "ECS_TASK_DEFINITION_FAMILY": "tutorial-task-def"
               }
           }
       ]
   }
   ```

1. サービス検出の名前空間、サービス、および ECS クラスター名などの追加パラメータを使用して、サービス検出インスタンスに関する詳細をクエリします。

   ```
   aws servicediscovery discover-instances \
         --namespace-name tutorial \
         --service-name myapplication \
         --query-parameters ECS_CLUSTER_NAME=tutorial
   ```

1. サービス検出サービス用に Route 53 ホストゾーンに作成された DNS レコードは、次の AWS CLI コマンドでクエリを実行できます。

   1. 名前空間 ID を使用して、名前空間に関する情報を取得しますが、これには Route 53 ホストゾーン ID が含まれます。

      ```
      aws servicediscovery \
            get-namespace --id ns-uejictsjen2i4eeg
      ```

      出力は次のとおりです。

      ```
      {
          "Namespace": {
              "Id": "ns-uejictsjen2i4eeg",
              "Arn": "arn:aws:servicediscovery:region:aws_account_id:namespace/ns-uejictsjen2i4eeg",
              "Name": "tutorial",
              "Type": "DNS_PRIVATE",
              "Properties": {
                   "DnsProperties": {
                      "HostedZoneId": "Z35JQ4ZFDRYPLV"
                  }
              },
              "CreateDate": 1519777852.502,
              "CreatorRequestId": "9049a1d5-25e4-4115-8625-96dbda9a6093"
          }
      }
      ```

   1. 前のステップの Route 53 ホストゾーン ID (太字のテキストを参照) を使用して、ホストゾーンのリソースレコードセットを取得します。

      ```
      aws route53 list-resource-record-sets \
            --hosted-zone-id Z35JQ4ZFDRYPLV
      ```

1. `dig` を使用して、VPC 内のインスタンスから DNS をクエリすることもできます。

   ```
   dig +short myapplication.tutorial
   ```

## ステップ 4: クリーンアップする
<a name="create-service-discovery-cleanup"></a>

このチュートリアルが終了したら、未使用のリソースに対する料金が発生しないように、それに関連付けられたリソースをクリーンアップします。以下の手順に従ってください。

1. 前に書き留めたサービス ID とインスタンス ID を使用して、サービス検出サービスインスタンスの登録を解除します。

   ```
   aws servicediscovery deregister-instance \
         --service-id srv-utcrh6wavdkggqtk \
         --instance-id 16becc26-8558-4af1-9fbd-f81be062a266
   ```

   出力は次のとおりです。

   ```
   {
       "OperationId": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv"
   }
   ```

1. 前のステップの出力の `OperationId` を使用して、サービス検出インスタンスが正常に登録解除されたことを確認します。

   ```
   aws servicediscovery get-operation \ 
         --operation-id xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv
   ```

   ```
   {
     "Operation": {
           "Id": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv",
           "Type": "DEREGISTER_INSTANCE",
           "Status": "SUCCESS",
           "CreateDate": 1525984073.707,
           "UpdateDate": 1525984076.426,
           "Targets": {
               "INSTANCE": "16becc26-8558-4af1-9fbd-f81be062a266",
               "ROUTE_53_CHANGE_ID": "C5NSRG1J4I1FH",
               "SERVICE": "srv-utcrh6wavdkggqtk"
           }
       }
   }
   ```

1. サービス ID を使用してサービス検出のサービスを削除します。

   ```
   aws servicediscovery delete-service \ 
         --id srv-utcrh6wavdkggqtk
   ```

1. 名前空間 ID を使用してサービス検出の名前空間を削除します。

   ```
   aws servicediscovery delete-namespace \ 
         --id ns-uejictsjen2i4eeg
   ```

   出力は次のとおりです。

   ```
   {
       "OperationId": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj"
   }
   ```

1. 前のステップの出力の `OperationId` を使用して、サービス検出名前空間が正常に削除されたことを確認します。

   ```
   aws servicediscovery get-operation \ 
         --operation-id c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj
   ```

   出力は次のとおりです。

   ```
   {
       "Operation": {
           "Id": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj",
           "Type": "DELETE_NAMESPACE",
           "Status": "SUCCESS",
           "CreateDate": 1525984602.211,
           "UpdateDate": 1525984602.558,
           "Targets": {
               "NAMESPACE": "ns-rymlehshst7hhukh",
               "ROUTE_53_CHANGE_ID": "CJP2A2M86XW3O"
           }
       }
   }
   ```

1. Amazon ECS サービスに必要な数を更新して `0` にします。次のステップでサービスを削除するには、これを実行する必要があります。

   ```
   aws ecs update-service \
         --cluster tutorial \
         --service ecs-service-discovery \
         --desired-count 0
   ```

1. Amazon ECS サービスを削除します。

   ```
   aws ecs delete-service \
         --cluster tutorial \
         --service ecs-service-discovery
   ```

1. Amazon ECS クラスターを削除します。

   ```
   aws ecs delete-cluster \
         --cluster tutorial
   ```

# Amazon VPC Lattice を使用して Amazon ECS サービスを接続、監視、保護する
<a name="ecs-vpc-lattice"></a>

Amazon VPC Lattice は、コードを変更することなく、Amazon ECS のお客様が AWS コンピューティングサービス、VPC、アカウント全体に 構築されたアプリケーションを観察、保護、モニタリングできるようにする完全マネージド型アプリケーションネットワーキングサービスです。

VPC Lattice は、コンピューティングリソースのコレクションであるターゲットグループを使用します。これらのターゲットは、アプリケーションまたはサービスを実行するものであり、Amazon EC2 インスタンス、IP アドレス、Lambda 関数、Application Load Balancer を含みます。Amazon ECS サービスを VPC Lattice ターゲットグループに関連付けることで、お客様は Amazon ECS タスクを VPC Lattice の IP ターゲットとして有効にできるようになりました。Amazon ECS は、登録されたサービスのタスクが起動されると、VPC Lattice ターゲットグループにタスクを自動的に登録します。

**注記**  
5 つの VPC Lattice 設定を使用する場合、より少ない設定を使用する場合よりも、デプロイ時間がわずかに長くなることがあります。

リスナールールは、条件が満たされたときに、指定されたターゲットグループにトラフィックを転送するために使用されます。リスナーは、設定したポート上のプロトコルを使用して接続リクエストをチェックします。サービスは、リスナーの設定時に定義したルールに基づいて、登録済みターゲットにリクエストをルーティングします。

また、Amazon ECS は、VPC Lattice ヘルスチェックに基づいてタスクが異常と判断された場合、タスクを自動的に置き換えます。VPC Lattice に関連付けると、Amazon ECS のお客様は、AWS Resource Access Manager を使用したクラスター、VPC、アカウント間のサービスへの接続、認可と認証のための IAM 統合、高度なトラフィック管理機能など、VPC Lattice の他の多くのクロスコンピューティング接続、セキュリティ、オブザーバビリティ機能を利用することもできます。

Amazon ECS のお客様は、以下の方法で VPC Lattice の恩恵を受けることができます。
+ デベロッパーの生産性の向上 - VPC Lattice は、ネットワーク、セキュリティ、オブザーバビリティの課題をすべてのコンピューティングプラットフォームにおいて統一された方法で処理することで、機能の構築に集中できるようにし、デベロッパーの生産性を向上させます。
+ セキュリティ体制の向上 - VPC Lattice を使用すると、デベロッパーはアプリケーションとコンピューティングプラットフォーム間の通信を簡単に認証および保護し、転送中の暗号化を適用して、VPC Lattice Auth ポリシーを用いたきめ細かなアクセス制御を適用できます。これにより、業界をリードする規制およびコンプライアンス要件を満たす、より強力なセキュリティ体制を採用できます。
+ アプリケーションのスケーラビリティと耐障害性の向上 - VPC Lattice では、パス、ヘッダー、メソッドベースのルーティング、認証、認可、モニタリングなどの機能を持つデプロイされたアプリケーションのネットワークを作成できます。これらの利点は、ワークロードのリソースオーバーヘッドなしで提供され、大幅なレイテンシーを発生させることなく、1 秒あたり数百万のリクエストを生成するマルチクラスターデプロイをサポートできます。
+ 異種インフラストラクチャによるデプロイの柔軟性 - VPC Lattice は、Amazon ECS、Fargate、Amazon EC2、Amazon EKS、Lambda などのすべてのコンピューティングサービスで一貫した機能を提供し、組織が各アプリケーションに適したインフラストラクチャを柔軟に選択できるようにします。

## VPC Lattice が他の Amazon ECS サービスと連携する仕組み
<a name="ecs-lattice-compatibility"></a>

Amazon ECS で VPC Lattice を使用すると、他の Amazon ECS サービスの使用方法が変わる可能性がありますが、他は変わりません。

**アプリケーション ロード バランサー**  
VPC Lattice の Application Load Balancer ターゲットグループタイプで使用するための、Amazon ECS サービスにリンクする特定の Application Load Balancer を作成する必要がなくなりました。代わりに VPC Lattice ターゲットグループを使用して Amazon ECS サービスを設定するだけで済みます。同時に、Amazon ECS で Application Load Balancer を引き続き使用することを選択することもできます。

**Amazon ECS ローリングデプロイ**  
VPC Lattice では Amazon ECS ローリングデプロイのみが使用可能であり、Amazon ECS はデプロイ中にタスクをサービスに安全に追加および削除します。コードデプロイとブルー/グリーンデプロイはサポートされていません。

VPC Lattice の詳細については、「[Amazon VPC Lattice ユーザーガイド](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html)」を参照してください。

# VPC Lattice を使用するサービスを作成する
<a name="ecs-vpc-lattice-create-service"></a>

AWS マネジメントコンソールまたは AWS CLI のいずれかを使用して、VPC Lattice でサービスを作成できます。

## 前提条件
<a name="create-ecs-vpc-lattice-prereqs"></a>

個のチュートリアルを開始する前に、次の前提条件を満たしていることを確認します。
+ AWS CLI の最新バージョンがインストールされ、設定されていること。詳細については、「[AWS Command Line Interface のインストール](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)」を参照してください。
**注記**  
デュアルスタックサービスエンドポイントを使用することで、IPv4 と IPv6 の両方を介して AWS CLI、SDK、および Amazon ECS API から Amazon ECS とやり取りできます。詳細については、「[Amazon ECS デュアルスタックエンドポイントの使用](dual-stack-endpoint.md)」を参照してください。
+ 「[Amazon ECS を使用するようにセットアップする](get-set-up-for-amazon-ecs.md)」で説明されているステップが完了しました。
+ IAM ユーザーに [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM ポリシー例で指定されている必要なアクセス権限があること。

## AWS マネジメントコンソールで VPC Lattice を使用するサービスを作成する
<a name="ecs-lattice-create-console"></a>

AWS マネジメントコンソールを使用して VPC Lattice でサービスを作成するには、次のステップに従います。

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションページで、**[クラスター]** を選択します。

1. **[クラスター]** ページで、サービスを作成するクラスターを選択します。

1. **[Services]** (サービス) タブから、**[Create]** (作成) を選択します。

   以前にサービスを作成したことがない場合は、「[コンソールを使用した Amazon ECS サービスの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-console-v2.html)」のステップに従い、VPC Lattice セクションまで進んだら、これらのステップを続行します。

1. ボタンをオンにして **[VPC Lattice を有効にする]** ことを選択します。

1. 既存のロールを使用するには、**[Amazon ECS の ECS インフラストラクチャロール]** で、VPC Lattice ターゲットグループの作成時に使用する作成済みのロールを選択します。新しいロールを作成するには、**[ECS インフラストラクチャロールの作成]** を選択します。

1. **VPC** を選択します。

   **[VPC]** は、タスク定義を登録したときに選択したネットワークモードによって異なります。EC2 起動タイプで `host` または `network` のモードを使用する場合は、VPC を選択します。

   `awsvpc` モードでは、VPC は **[ネットワーク]** で選択した VPC に基づいて自動的に選択され、変更することはできません。

1. **[ターゲットグループ]** で、1 つまたは複数のターゲットグループを選択します。少なくとも 1 つのターゲットグループを選択する必要があります。最大 5 つのターゲットグループを選択できます。追加のターゲットグループを追加するには、**[ターゲットグループの追加]** を選択します。選択した各ターゲットグループの **[ポート名]**、**[プロトコル]**、および **[ポート]** を選択します。ターゲットグループを削除するには、**[削除]** を選択します。
**注記**  
既存のターゲットグループを追加する場合は、AWS CLI を使用する必要があります。AWS CLI を使用してターゲットグループを追加する方法については、「*AWS Command Line Interface リファレンス*」の「[register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html)」を参照してください。
VPC Lattice サービスは複数のターゲットグループを持つことができますが、各ターゲットグループは 1 つのサービスにのみ追加できます。
IPv6 専用設定でサービスを作成するには、IP アドレスタイプが `IPv6` のターゲットグループを選択します。

1. この時点で、VPC Lattice コンソールに移動してセットアップを続行します。ここでは、リスナーのデフォルトアクションまたは既存の VPC Lattice サービスのルールに新しいターゲットグループを含めます。

   詳細については、「[Listener rules for your VPC Lattice service](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html)」を参照してください。

**重要**  
セキュリティグループにインバウンドルール `vpc-lattice` プレフィックスを許可しないと、タスクやヘルスチェックが失敗する可能性があります。

## AWS CLIで VPC Lattice を使用するサービスを作成する
<a name="ecs-lattice-create-cli"></a>

AWS CLI を使用して、VPC Lattice でサービスを作成します。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。

1. ターゲットグループ設定ファイルを作成します。以下の例は `tg-config.json` という名前です

   ```
   {
       "ipAddressType": "IPV4",
       "port": 443,
       "protocol": "HTTPS",
       "protocolVersion": "HTTP1",
       "vpcIdentifier": "vpc-f1663d9868EXAMPLE"
   }
   ```

1. 以下のコマンドを使用して、VPC Lattice ターゲットグループを作成します。

   ```
   aws vpc-lattice create-target-group \
       --name my-lattice-target-group-ip \
       --type IP \
       --config file://tg-config.json
   ```
**注記**  
IPv6 専用設定でサービスを作成するには、IP アドレスタイプが `IPv6` のターゲットグループを作成します。詳細については、「*AWS CLI コマンドリファレンス*」の「[create-log-group](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/create-target-group.html)」を参照してください。

   出力例:

   ```
   {
       "arn": "arn:aws:vpc-lattice:us-east-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
       "config": {
           "healthCheck": {
               "enabled": true,
               "healthCheckIntervalSeconds": 30,
               "healthCheckTimeoutSeconds": 5,
               "healthyThresholdCount": 5,
               "matcher": {
                   "httpCode": "200"
               },
               "path": "/",
               "protocol": "HTTPS",
               "protocolVersion": "HTTP1",
               "unhealthyThresholdCount": 2
           },
           "ipAddressType": "IPV4",
           "port": 443,
           "protocol": "HTTPS",
           "protocolVersion": "HTTP1",
           "vpcIdentifier": "vpc-f1663d9868EXAMPLE"
       },
       "id": "tg-0eaa4b9ab4EXAMPLE",
       "name": "my-lattice-target-group-ip",
       "status": "CREATE_IN_PROGRESS",
       "type": "IP"
   }
   ```

1. 以下の *ecs-service-vpc-lattice.json* という名前の JSON ファイルは、VPC Lattice ターゲットグループに Amazon ECS サービスをアタッチするために使用される例です。以下の例の `portName` は、タスク定義の `portMappings` プロパティの `name` フィールドで定義したものと同じです。

   ```
   {
       "serviceName": "ecs-service-vpc-lattice",
       "taskDefinition": "ecs-task-def",
           "vpcLatticeConfigurations": [
           {
               "targetGroupArn": "arn:aws:vpc-lattice:us-west-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
               "portName": "testvpclattice",
               "roleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRoleVpcLattice"
           }
       ],
       "desiredCount": 5,
       "role": "ecsServiceRole"
   }
   ```

   以下のコマンドを使用して Amazon ECS サービスを作成し、上記の json 例を使用して VPC Lattice ターゲットグループにアタッチします。

   ```
   aws ecs create-service \
       --cluster clusterName \
       --serviceName ecs-service-vpc-lattice \
       --cli-input-json file://ecs-service-vpc-lattice.json
   ```

**注記**  
VPC Lattice は、Amazon ECS Anywhere ではサポートされていません。

# Amazon ECS タスクがスケールインイベントによって終了するのを防ぐ
<a name="task-scale-in-protection"></a>

Amazon ECS タスクスケールイン保護を使用すると、サービスの自動スケーリングまたはデプロイからのスケールインイベントによってタスクが終了されるのを防ぐことができます。

特定のアプリケーションでは、使用率が低いときやサービスのデプロイ中に、ミッションクリティカルなタスクがスケールインイベントによって終了されるのを防ぐメカニズムが必要です。例えば、次のようになります。
+ ビデオトランスコーディングジョブなどのキュー処理型の非同期アプリケーションでは、サービスの累積使用率が低い場合でも、一部のタスクは何時間も実行する必要があります。
+ あるゲームアプリケーションでは、ゲームサーバーは Amazon ECS タスクとして実行されますが、サーバー再起動時の起動待ち時間を短縮するため、すべてのユーザーがログアウトした場合でも実行を続ける必要があります。
+ 新しいコードバージョンをデプロイする場合、再処理にはコストがかかるため、タスクは実行し続ける必要があります。

サービスに属するタスクがスケールインイベントで終了されることを防ぐには、`ProtectionEnabled` 属性を `true` に設定します。`ProtectionEnabled` を true に設定すると、タスクはデフォルトで 2 時間保護されます。その後、保護期間は、`ExpiresInMinutes` 属性を使用してカスタマイズできます。タスクの保護期間は最短で 1 分間、最長で 2,880 分 (48 時間) です。AWS CLI を使用している場合は、`--protection-enabled` オプションを指定できます。

タスクが必要な作業を完了した後は、`ProtectionEnabled` 属性を `false` に設定して、以降のスケールインイベントによってタスクが終了されるようにできます。AWS CLI を使用している場合は、`--no-protection-enabled` オプションを指定できます。

## タスクスケールイン保護メカニズム
<a name="task-scale-in-protection-mechanisms"></a>

Amazon ECS コンテナエージェントエンドポイントまたは Amazon ECS API を使用して、タスクスケールイン保護を設定および取得できます。
+ **Amazon ECS コンテナエージェントエンドポイント**

  保護の必要性を自己判断できるタスクには、Amazon ECS コンテナエージェントエンドポイントを使用することをお勧めします。このアプローチは、キューベースのワークロードまたはジョブ処理ワークロードに使用します。

  コンテナが、例えば SQS メッセージを使用するなどして処理を開始すると、コンテナ内からタスクスケールイン保護のエンドポイントパス「`ProtectionEnabled`」を使用して `$ECS_AGENT_URI/task-protection/v1/state` 属性を設定できます。スケールインイベントの際、Amazon ECS はこのタスクを終了しません。タスクの処理が完了した後は、同じエンドポイントを使用して `ProtectionEnabled` 属性をクリアし、以降のスケールインイベントでタスクが終了されるようにできます。

  Amazon ECS コンテナエージェントエンドポイントの詳細については、「[Amazon ECS タスクスケールイン保護のエンドポイント](task-scale-in-protection-endpoint.md)」を参照してください。
+ **Amazon ECS API**

  アプリケーションにアクティブなタスクの状態を追跡するコンポーネントがある場合は、Amazon ECS API を使用してタスクスケールイン保護を設定および取得できます。`UpdateTaskProtection` を使用して、1 つ以上のタスクを保護対象としてマークします。`GetTaskProtection` を使用して保護ステータスを取得します。

  このアプローチの例としては、アプリケーションがゲームサーバーセッションを Amazon ECS タスクとしてホストしている場合が挙げられます。ユーザーがサーバー上のセッション (タスク) にログインすると、そのタスクを保護対象としてマークできます。ユーザーがログアウトした後は、サーバーのアイドル状態を維持することの要件に応じて、このタスク限定でクリアすることも、アクティブなセッションがなくなった同様のタスクについて定期的に保護をクリアすることもできます。

  詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[UpdateTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateTaskProtection.html)」と「[GetTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_GetTaskProtection.html)」を参照してください。

両方のアプローチを組み合わせることができます。例えば、Amazon ECS エージェントエンドポイントを使用してコンテナ内からタスク保護を設定し、Amazon ECS API を使用して外部コントローラーサービスからタスク保護を削除するなどです。

## 考慮事項
<a name="task-scale-in-protection-considerations"></a>

タスクスケールイン保護を使用する前に、次の点を考慮してください。
+ タスクのスケールイン保護は、サービスからデプロイされたタスクでのみサポートされます。
+ タスクのスケールイン保護は、Amazon ECS マネージドインスタンスで実行されているサービスからデプロイされたタスクでサポートされます。
+ Amazon ECS エージェントには再試行メカニズムが組み込まれており、そのインターフェイスはよりシンプルであるため、Amazon ECS コンテナエージェントエンドポイントを使用することをお勧めします。
+ 既に保護がオンになっているタスクのために `UpdateTaskProtection` を呼び出すことで、タスクのスケールイン保護の有効期間をリセットできます。
+ タスクが必要な作業を完了するのに必要な時間を判断し、それに応じて `expiresInMinutes` プロパティを設定してください。保護の有効期限を必要以上に長く設定すると、コストが発生すると共に、新しいタスクのデプロイが遅れることになります。
+ Amazon ECS コンテナエージェント `1.65.0` 以降ではタスクのスケールイン保護がサポートされています。エージェントを最新バージョンに更新することで、古いバージョンのAmazon ECS コンテナエージェントを使用する Amazon EC2 インスタンスでこの機能のサポートを追加できます。詳細については、「[Amazon ECS コンテナエージェントをアップデートする](ecs-agent-update.md)」を参照してください。
+ デプロイに関する考慮事項:
  + サービスがローリングアップデートを使用する場合、新しいタスクは作成できますが、古いバージョンを実行しているタスクは、`protectionEnabled` がクリアされるか、または失効するまで終了しません。デプロイ設定の `maximumPercentage` パラメータは、古いタスクが保護されている場合でも新しいタスクを作成できるように値を調整できます。
  + ブルー/グリーン更新が適用されている場合、タスクに `protectionEnabled` があれば、保護されたタスクを含むブルーデプロイは削除されません。トラフィックは新しいタスクに振り分けられ、古いタスクは `protectionEnabled` がクリアされるか期限切れになったときのみ削除されます。CodeDeploy または CloudFormation の更新のタイムアウトによっては、デプロイがタイムアウトして、古いブルータスクが残っている場合があります。
  + CloudFormation を使用する場合、更新スタックのタイムアウトは 3 時間です。そのため、タスク保護を 3 時間以上設定すると、CloudFormation のデプロイで障害が発生してロールバックが発生する可能性があります。

    古いタスクが保護されている間、CloudFormation スタックは `UPDATE_IN_PROGRESS` を表示します。タスクのスケールイン保護が削除されるか、または 3 時間のウィンドウ内に失効する場合、デプロイは成功し、`UPDATE_COMPLETE` ステータスに移行します。デプロイが `UPDATE_IN_PROGRESS` のまま 3 時間以上滞っていると、デプロイは失敗して `UPDATE_FAILED` 状態が表示され、古いタスクセットにロールバックされてしまいます。
  + 保護されたタスクが原因でデプロイ (ローリングまたはブルー/グリーン) が定常状態に到達できない場合、Amazon ECS はサービスイベントを送信し、これによりユーザーは是正措置を講じることができます。タスクの保護ステータスを更新しようとする際に `DEPLOYMENT_BLOCKED` エラーメッセージが表示される場合、サービスの要求されるタスク数よりも多くの保護されたタスクがあることを意味します。この問題を解決するには、次のいずれかの操作を実行します。
    + 現在のタスク保護の有効期限が切れるのを待ちます。次に、タスク保護を設定します。
    + どのタスクを停止できるかを決定します。その後、これらのタスクについて `protectionEnabled` オプションを `false` に設定して `UpdateTaskProtection` を使用します。
    + サービスの必要なタスク数を増やして、保護されているタスクの数よりも多くします。

## タスクスケールイン保護に必要な IAM アクセス許可
<a name="task-scale-in-protection-iam"></a>

タスクには、以下のアクセス許可を持つ Amazon ECS タスクロールが必要です。
+ `ecs:GetTaskProtection`: Amazon ECS コンテナエージェントが `GetTaskProtection` を呼び出すことを許可します。
+ `ecs:UpdateTaskProtection`: Amazon ECS コンテナエージェントが `UpdateTaskProtection` を呼び出すことを許可します。

# Amazon ECS タスクスケールイン保護のエンドポイント
<a name="task-scale-in-protection-endpoint"></a>

Amazon ECS コンテナエージェントは、`ECS_AGENT_URI` 環境変数を Amazon ECS タスクのコンテナに自動的に挿入して、コンテナエージェント API エンドポイントとやり取りする方法を提供します。

保護の必要性を自己判断できるタスクには、Amazon ECS コンテナエージェントエンドポイントを使用することをお勧めします。

コンテナが処理を開始すると、コンテナ内からタスクスケールイン保護のエンドポイントパス「`protectionEnabled`」を使用して `$ECS_AGENT_URI/task-protection/v1/state` 属性を設定できます。

コンテナ内からこの URI への PUT リクエストを使用すると、タスクのスケールイン保護が設定されます。この URI への GET リクエストは、タスクの現在の保護ステータスを返します。

## タスクスケールイン保護のリクエストパラメータ
<a name="task-scale-in-protection-request"></a>

次のリクエストパラメータで、`${ECS_AGENT_URI}/task-protection/v1/state` エンドポイントを使用してタスクスケールインプロテクションを設定できます。

`ProtectionEnabled`  
`true` を指定して、タスクを保護できるようにマークします。`false` を指定して保護を解除し、タスクを終了できるようにします。  
タイプ: ブール値  
必須: はい

`ExpiresInMinutes`  
タスクが保護されている時間 (分)。最小 1 分から最大 2,880 分 (48 時間) まで指定できます。この期間中、自動スケーリングサービスまたはデプロイからのスケールインイベントによってタスクが終了することはありません。この時間が経過すると、`protectionEnabled` パラメータは `false` に設定されます。  
時間を指定しない場合、タスクは自動的に 120 分 (2 時間) 保護されます。  
タイプ: 整数  
必須: いいえ

次の例は、異なる継続時間を持つタスク保護を設定する方法を示します。

**デフォルトの期間を使用してタスクを保護する方法の例**

この例は、デフォルトの期間が 2 時間に設定されているタスクを保護する方法を示しています。

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true}'
```

**タスクを 60 分間保護する方法の例**

この例は、`expiresInMinutes` パラメータを使用してタスクを 60 分間保護する方法を示しています。

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":60}'      
```

**タスクを 24 時間保護する方法の例**

この例は、`expiresInMinutes` パラメータを使用してタスクを 24 時間保護する方法を示しています。

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}'      
```

**Windows コンテナの例**

Windows コンテナの場合、curl の代わりに PowerShell の `Invoke-RestMethod` コマンドレットを使用できます。次の例は、前の curl コマンドに相当する PowerShell コマンドを示しています。

**デフォルト期間を持つ Windows コンテナタスクを保護する方法の例**

この例では、PowerShell を使用して 2 時間のデフォルト期間を持つタスクを保護する方法を示しています。

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true}' -ContentType 'application/json'
```

**Windows コンテナタスクを 60 分間保護する方法の例**

この例では、PowerShell で `expiresInMinutes` パラメータを使用してタスクを 60 分間保護する方法を示しています。

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true,"ExpiresInMinutes":60}' -ContentType 'application/json'
```

**Windows コンテナタスクを 24 時間保護する方法の例**

この例では、`expiresInMinutes` パラメータを使用してタスクを 24 時間保護する方法を示しています。

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}' -ContentType 'application/json'
```

PUT リクエストは次のレスポンスを返します。

```
{
  "protection": {
    "ExpirationDate": "2023-12-20T21:57:44.837Z",
    "ProtectionEnabled": true,
    "TaskArn": "arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
  }
}
```

## タスクスケールイン保護のレスポンスパラメータ
<a name="task-scale-in-protection-response"></a>

次の情報が、JSON レスポンスタスクのスケールインプロテクションエンドポイント `${ECS_AGENT_URI}/task-protection/v1/state` から返されます。

`ExpirationDate`  
タスクの保護が期限切れになるエポックタイム。タスクが保護されていない場合、この値は NULL です。

`ProtectionEnabled`  
タスクのプロテクションステータス。タスクのスケールインプロテクションが有効になっている場合、値は `true` です。それ以外の場合は、`false` です。

`TaskArn`  
コンテナが属しているタスクの完全な Amazon リソースネーム (ARN)。

次の例は、保護されたタスクについて返される詳細を示しています。

```
curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
```

Windows コンテナの場合、次の PowerShell コマンドを使用して保護ステータスを取得します。

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Get
```

```
{
    "protection":{
        "ExpirationDate":"2023-12-20T21:57:44Z",
        "ProtectionEnabled":true,
        "TaskArn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
    }
}
```

障害が発生すると、次の情報が返されます。

`Arn`  
タスクの完全な Amazon リソースネーム (ARN)。

`Detail`  
障害に関する詳細。

`Reason`  
失敗の理由。

次の例は、保護されていないタスクについて返される詳細を示しています。

```
{
    "failure":{
        "Arn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0",
        "Detail":null,
        "Reason":"TASK_NOT_VALID"
    }
}
```

例外が発生すると、次の情報が返されます。

`requestID`  
例外が発生する Amazon ECS API 呼び出しの AWS リクエスト ID。

`Arn`  
タスクまたはサービスの完全な Amazon リソースネーム (ARN)。

`Code`  
エラーコードです。

`Message`  
エラーメッセージです。  
`RequestError` または `RequestTimeout` エラーが表示される場合は、ネットワークに問題がある可能性があります。Amazon ECS の VPC エンドポイントを使用してみてください。

次の例は、エラーが発生したときに返される詳細を示したものです。

```
{
    "requestID":"12345-abc-6789-0123-abc",
    "error":{
        "Arn":"arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
        "Code":"AccessDeniedException",
        "Message":"User: arn:aws:sts::444455556666:assumed-role/my-ecs-task-role/1234567890abcdef0 is not authorized to perform: ecs:GetTaskProtection on resource: arn:aws:ecs:us-west-2:555555555555:task/test/1234567890abcdef0 because no identity-based policy allows the ecs:GetTaskProtection action"
    }    
}
```

ネットワークの問題や Amazon ECS コントロールプレーンがダウンしているなどの理由で Amazon ECS エージェントが Amazon ECS エンドポイントから応答を得られない場合、次のエラーが表示されます。

```
{
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "RequestCanceled",
    "Message": "Timed out calling Amazon ECS Task Protection API"
  }
}
```

Amazon ECS エージェントが Amazon ECS からスロットリング例外を受け取ると、次のエラーが表示されます。

```
{
  "requestID": "12345-abc-6789-0123-abc",
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "ThrottlingException",
    "Message": "Rate exceeded"
  }
}
```

# Amazon ECS および Fargate ワークロードでフォールトインジェクションを使用する
<a name="fault-injection"></a>

お客様は、Amazon EC2 と Fargate の両方で Amazon ECS によるフォールトインジェクションを利用して、特定の障害シナリオに対するアプリケーションの反応をテストできます。これらのテストは、アプリケーションのパフォーマンスと回復力の最適化に使用できる情報を提供します。

フォールトインジェクションが有効になっている場合、Amazon ECS コンテナエージェントはタスクに新しいフォールトインジェクションエンドポイントへのアクセスを許可します。フォールトインジェクションを使用するには、`enableFaultInjection` タスク定義パラメータの値を `true` に設定してオプトインする必要があります。デフォルト値は `false` です。

```
{
    ...
   "enableFaultInjection": true
}
```

**注記**  
フォールトインジェクションは、`awsvpc` または `host` ネットワークモードを使用するタスクでのみ機能します。  
フォールトインジェクションは、Windows では使用できません。

AWS マネジメントコンソールでフォールトインジェクションを有効にする方法については、「[コンソールを使用して Amazon ECS タスク定義の作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html)」を参照してください。

AWS Fault Injection Service でテストするには、この機能を有効にする必要があります。詳細については、「[AWS FIS aws:ecs:タスクアクションを使用します](https://docs.aws.amazon.com/fis/latest/userguide/ecs-task-actions.html)」を参照してください。

**注記**  
Amazon ECS に最適化された新しい AMI を使用しない場合、またはカスタム AMI がある場合は、次の依存関係をインストールします。  
`tc`
`sch_netem` カーネルモジュール

# Amazon ECS フォールトインジェクションエンドポイント
<a name="fault-injection-endpoints"></a>

Amazon ECS コンテナエージェントは、`ECS_AGENT_URI` 環境変数を Amazon ECS タスクのコンテナに自動的に挿入して、コンテナエージェント API エンドポイントとやり取りする方法を提供します。各エンドポイントには、`/start`、`/stop`、および `/status` エンドポイントが含まれます。エンドポイントは、フォールトインジェクションを有効にしたタスクからのリクエストのみを受け入れ、各エンドポイントにはコンテナあたり **5** 秒間に **1** リクエストというレート制限があります。この制限を超えるとエラーが発生します。

**注記**  
フォールトインジェクションエンドポイントを使用するには、Amazon ECS エージェント `version 1.88.0+` が必要です。

フォールトインジェクションで使用する 3 つのエンドポイントは以下のとおりです。
+ [ネットワークブラックホールポートエンドポイント](#fis-endpoint-blackhole-ports)
+ [ネットワークパケット損失エンドポイント](#fis-endpoint-packet-loss)
+ [ネットワークレイテンシーエンドポイント](#fis-endpoint-latency)

リクエストが成功すると、`/start` エンドポイントを呼び出す場合 `running` のメッセージが記載された `200` 応答コードとなり、`/stop` エンドポイントの場合は `stopped`、`/status` エンドポイントの場合は `running` または `not-running` となります。

```
{
    "Status": <string>
}
```

リクエストが成功しなかった場合は、以下のいずれかのエラーコードを返します。
+ `400` – Bad request・
+ `409` – フォールトインジェクションリクエストが別の実行中の障害と競合する
+ `429` – リクエストがスロットリングされました
+ `500` – サーバーに予期しないエラーが発生しました

```
{
	"Error":  <string message> 
}
```

**注記**  
1 回に挿入できるのは、1 つのネットワークレイテンシー障害、または 1 つのネットワークパケット損失障害のいずれかです。複数の結果を挿入しようとすると、リクエストは拒否されます。

## ネットワークブラックホールポートエンドポイント
<a name="fis-endpoint-blackhole-ports"></a>

`{ECS_AGENT_URI}/fault/v1/network-blackhole-port` エンドポイントは、タスクのネットワーク名前空間内の特定のポートとプロトコルの受信トラフィックまたは送信トラフィックをドロップし、次の 2 つのモードと互換性があります。
+ **awsvpc** — 変更がタスクネットワーク名前空間に適用されます
+ **ホスト** — 変更はデフォルトのネットワーク名前空間コンテナインスタンスに適用されます

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/start
<a name="fis-endpoint-blackhole-ports-start"></a>

このエンドポイントは、ネットワークブラックホールポートのフォールトインジェクションを開始し、次のパラメータがあります。

**ポート**  
ブラックホールポートのフォールトインジェクションに使用する指定されたポート。

タイプ: 整数

必須: はい

**プロトコル**  
ブラックホールポートのフォールトインジェクションに使用するプロトコル。

型: 文字列

有効な値: `tcp | udp`

必須: はい

**TrafficType**  
フォールトインジェクションで使用されるトラフィックタイプ。

型: 文字列

有効な値: `ingress | egress`

必須: はい

**SourcesToFilter**  
障害から保護されている IPv4 アドレスまたは IPv6 アドレス、あるいは CIDR ブロックの JSON 配列。

型: 文字列の配列

必須: いいえ

以下は `start` エンドポイントを使用するためのリクエストの例です (*赤色* の値を独自の値に置き換えてください)。

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/start

Http method:POST

Request payload: 
{
    "Port": 1234,
    "Protocol": "tcp|udp",
    "TrafficType": "ingress|egress"
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/stop
<a name="fis-endpoint-blackhole-ports-stop"></a>

このエンドポイントは、リクエストで指定された障害を停止します。このエンドポイントには以下のパラメータがあります。

**ポート**  
停止する必要がある障害の影響を受けたポート。

タイプ: 整数

必須: はい

**プロトコル**  
障害を停止するために使用するプロトコル。

型: 文字列

有効な値: `tcp | udp`

必須: はい

**TrafficType**  
フォールトインジェクションで使用されるトラフィックタイプ。

型: 文字列

有効な値: `ingress | egress`

必須: はい

以下は `stop` エンドポイントを使用するためのリクエストの例です (*赤色* の値を独自の値に置き換えてください)。

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/stop

Http method: POST

Request payload: 
{
    "Port": 1234,
    "Protocol": "tcp|udp",
    "TrafficType": "ingress|egress", 
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/status
<a name="fis-endpoint-blackhole-ports-status"></a>

このエンドポイントは、フォールトインジェクションのステータスを確認するために使用されます。このエンドポイントには以下のパラメータがあります。

**ポート**  
障害のステータスを確認するために影響を受けるポート。

タイプ: 整数

必須: はい

**プロトコル**  
障害のステータスを確認する際に使用するプロトコル。

型: 文字列

有効な値: `tcp | udp`

必須: はい

**TrafficType**  
フォールトインジェクションで使用されるトラフィックタイプ。

型: 文字列

有効な値: `ingress | egress`

必須: はい

以下は `status` エンドポイントを使用するためのリクエストの例です (*赤色* の値を独自の値に置き換えてください)。

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/status

Http method: POST

Request payload: 
{
   "Port": 1234,
   "Protocol": "tcp|udp",
   "TrafficType": "ingress|egress",
}
```

## ネットワークレイテンシーエンドポイント
<a name="fis-endpoint-latency"></a>

`{ECS_AGENT_URI}/fault/v1/network-latency` エンドポイントは、特定のソースへのトラフィックに対してタスクのネットワークインターフェイスに遅延とジッターを追加します。このエンドポイントは 2 つのモードと互換性があります。
+ **awsvpc** — 変更がタスクネットワークインターフェイスに適用されます
+ **ホスト** — 変更はデフォルトのネットワークインターフェイスに適用されます

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-latency/start
<a name="fis-endpoint-latency-start"></a>

この`/start` エンドポイントは、ネットワークレイテンシーのフォールトインジェクションを開始し、以下のパラメータがあります。

**DelayMilliseconds**  
フォールトインジェクションに使用するネットワークインターフェイスに追加する遅延のミリ秒数。

タイプ: 整数

必須: はい

**JitterMilliseconds**  
フォールトインジェクションに使用するネットワークインターフェイスに追加するジッターのミリ秒数。

タイプ: 整数

必須: はい

**[Sources] (出典)**  
フォールトインジェクションで使用する宛先である IPv4 アドレスまたは IPv6 アドレス、あるいは CIDR ブロックの JSON 配列。

型: 文字列の配列

必須: はい

**SourcesToFilter**  
障害から保護されている IPv4 アドレスまたは IPv6 アドレス、あるいは CIDR ブロックの JSON 配列。`SourcesToFilter` は `Sources` よりも優先されます。

型: 文字列の配列

必須: いいえ

以下は `/start` エンドポイントを使用するためのリクエストの例です (*赤色* の値を独自の値に置き換えてください)。

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/start

Http method: POST

Request payload: 
{
    "DelayMilliseconds": 123,
    "JitterMilliseconds": 123,
    "Sources": ["${IP1}", "${IP2}", ...],
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-latency/stop and /status
<a name="fis-endpoint-latency-stop-status"></a>

`{ECS_AGENT_URI}/fault/v1/network-latency/stop` エンドポイントは障害を停止し、`{ECS_AGENT_URI}/fault/v1/network-latency/status` は障害のステータスを確認します。

以下は、 `/stop` と `/status` のエンドポイントを使用する際の 2 つのリクエストの例です。どちらも `POST HTTP` メソッドを使用します。

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/stop
```

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/status
```

## ネットワークパケット損失エンドポイント
<a name="fis-endpoint-packet-loss"></a>

`{ECS_AGENT_URI}/fault/v1/network-packet-loss` エンドポイントは、指定されたネットワークインターフェイスへのパケット損失を追加します。このエンドポイントは、次の 2 つのモードと互換性があります。
+ **awsvpc** — 変更がタスクネットワークインターフェイスに適用されます
+ **ホスト** — 変更はデフォルトのネットワークインターフェイスに適用されます

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-packet-loss/start
<a name="fis-endpoint-packet-loss-start"></a>

この `/start` エンドポイントは、ネットワークパケット損失フォールトインジェクションを開始し、以下のパラメータがあります。

**LossPercent**  
パケット損失の割合

タイプ: 整数

必須: はい

**[Sources] (出典)**  
フォールトインジェクションテストに使用する IPv4 アドレスまたは IPv6 アドレス、あるいは CIDR ブロックの JSON 配列。

型: 文字列の配列

必須: はい

**SourcesToFilter**  
障害から保護されている IPv4 アドレスまたは IPv6 アドレス、あるいは CIDR ブロックの JSON 配列。`SourcesToFilter` は `Sources` よりも優先されます。

型: 文字列の配列

必須: いいえ

以下は `start` エンドポイントを使用するためのリクエストの例です (*赤色* の値を独自の値に置き換えてください)。

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-packet-loss/start

Http method: POST

{
    "LossPercent": 6,  
    "Sources": ["${IP1}", "${IP2}", ...],
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-packet-loss/stop and /status
<a name="fis-endpoint-packet-loss-stop-status"></a>

`{ECS_AGENT_URI}/fault/v1/network-packet-loss/stop` エンドポイントは障害を停止し、`{ECS_AGENT_URI}/fault/v1/network-packet-loss/status` は障害のステータスを確認します。1 回でサポートされる障害のタイプは 1 つだけです。

以下は、`/stop` と `/status` のエンドポイントを使用する際の 2 つのリクエストの例です。どちらも `POST HTTP` メソッドを使用します。

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-packet-loss/stop
```

```
Endpoint: ${{ECS_AGENT_URI}/fault/v1/network-packet-loss/status
```

# Amazon ECS サービスのパラメータの更新
<a name="update-service-parameters"></a>

サービスを作成した後、タスクの数など、サービスパラメータを更新する必要がある場合があります。

サービススケジューラが新しいタスクを起動するとき、次のロジックを使用してクラスター内のタスク配置を決定します。
+ クラスター内のどのコンテナインスタンスがサービスのタスク定義をサポートできるか判断します。例えば、必要な CPU、メモリ、ポート、コンテナインスタンス属性があります。
+ デフォルトで、サービススケジューラは、別の配置戦略を選択できる場合でも、この方法でアベイラビリティーゾーン間でタスクのバランスをとるように試みます。
  + 有効なコンテナインスタンスを、インスタンスと同じアベイラビリティーゾーンでサービスの実行中タスクが少ない順にソートします。例えば、ゾーン A に実行中のサービスタスクが 1 つあり、ゾーン B と C に実行中のサービスタスクがない場合、ゾーン B または C のいずれかの有効なコンテナインスタンスが配置に最適と見なされます。
  + 新しいサービスタスクを最適なアベイラビリティーゾーン内の有効なコンテナインスタンスに配置し (前の手順に基づいて)、実行中のサービスタスクの数が最小のコンテナインスタンスを優先させます。

サービススケジューラがタスクの実行を停止する場合、次のロジックを使用してアベイラビリティーゾーン間のクラスターの負荷バランスを維持します。
+ コンテナインスタンスを、インスタンスと同じアベイラビリティーゾーンでサービスの実行中タスクが多い順にソートします。たとえば、実行中のサービスタスクがゾーン A には 1 つ、ゾーン B とゾーン C にはそれぞれ 2 つずつある場合、ゾーン B またはゾーン C のいずれかのコンテナインスタンスが終了に最適と見なされます。
+ 実行中のサービスタスクの数が多いコンテナインスタンスの順に従って、最適なアベイラビリティーゾーン内のコンテナインスタンスで (前述の手順に基づいて) タスクを停止します。

リストを使用して、サービスパラメータを変更できるかどうかを判断してください。

**アベイラビリティーゾーンの再調整**  
サービスにアベイラビリティーゾーンの再調整を使用するかどうか示します。  
このパラメータはローリングデプロイで変更できます。

**キャパシティプロバイダー戦略**  
キャパシティプロバイダー戦略の詳細。クラスターの作成、タスクの実行、またはサービスの更新時に、キャパシティプロバイダーを設定できます。  
Fargate を使用する場合、キャパシティプロバイダーは `FARGATE` または `FARGATE_SPOT` です。  
Amazon EC2 を使用する場合、キャパシティプロバイダーは Auto Scaling グループです。  
ローリングデプロイとブルー/グリーンデプロイのキャパシティプロバイダーは変更できます。  
次のリストは、有効な移行を表示しています。  
+ Fargate を Auto Scaling グループキャパシティプロバイダーに更新します。
+ EC2 を Fargate キャパシティプロバイダーに更新します。
+ Fargate キャパシティプロバイダーを Auto Scaling グループキャパシティプロバイダーに更新します。
+ Amazon EC2 キャパシティプロバイダーを Fargate キャパシティプロバイダーに更新します。
+ Auto Scaling グループまたは Fargate キャパシティプロバイダーを更新して起動タイプに戻します。CLI または API を使用する場合は、`capacityProviderStrategy` パラメータに空のリストを渡します。

**クラスター**  
クラスターの名前を変更することはできません。

**Deployment configuration**  
デプロイ設定には、CloudWatch アラーム、障害の検出に使用されるサーキットブレーカー、必要な設定が含まれます。  
デプロイサーキットブレーカーは、サービスが定常状態に到達できなかった場合にサービスのデプロイを失敗させるかどうかを決定します。デプロイサーキットブレーカーを使用すると、サービスデプロイは失敗状態に移行し、新しいタスクの起動を停止します。ロールバックオプションを使用すると、サービスのデプロイに失敗すると、サービスは、前回正常に完了したデプロイへとロールバックされます。  
Amazon ECS サーキットブレーカーを使用するサービスを更新すると、Amazon ECS はサービスデプロイとサービスリビジョンを作成します。これらのリソースを使用すると、サービス履歴に関する詳細情報を表示できます。詳細については、「[Amazon ECS サービスデプロイを使用してサービス履歴を表示する](service-deployment.md)」を参照してください。  
サービススケジューラは、最小ヘルス率と最大ヘルス率のパラメータ (サービスのデプロイ設定) を使用して、デプロイ戦略を判断します。  
サービスでローリング更新 (`ECS`) のデプロイタイプが使用されている場合、**最小ヘルス率**は、デプロイ時に `RUNNING` 状態に保つ必要のあるサービスのタスクの下限数をサービスのタスクの必要数のパーセント値 (最も近い整数に切り上げ) で表します。サービスに EC2 を使用するタスクが含まれている場合、`DRAINING` 状態のコンテナインスタンスがある間は、パラメータも適用されます。追加のクラスターキャパシティーを使用しないデプロイのために、このパラメータを使用します。例えば、サービスで必要数が 4 タスク、最小ヘルス率が 50% とすると、スケジューラは 2 つの新しいタスクを開始する前に、2 つの既存のタスクを停止してクラスターのキャパシティーを解放できます。ロードバランサーを使用しないサービスのタスクは、`RUNNING` 状態にある場合正常な状態とサービスからみなされます。ロードバランサーを使用するサービスのタスクは、`RUNNING` 状態にあり、ロードバランサーによって正常と報告された場合に、サービスから正常であるとみなされます。最小ヘルス率のデフォルト値は 100% です。  
サービスでローリング更新 (`ECS`) のデプロイタイプが使用されている場合、**maximum percent** パラメータは、デプロイ時に `PENDING`、`RUNNING`、または `STOPPING` 状態で使用できるサービスのタスクの上限数をそれらのタスク数の適切なパーセント値 (最も近い整数に切り下げ) として表します。サービスに EC2 を使用するタスクが含まれている場合、`DRAINING` 状態のコンテナインスタンスがある間は、パラメータも適用されます。このパラメータは、デプロイのバッチサイズを定義するために使用します。例えば、サービスで必要数が 4 タスク、最大ヘルス率の値が 200% とすると、スケジューラは 4 つの古いタスクを停止する前に、4 つの新しいタスクを開始できます。そのために必要なクラスターリソースを使用できることが前提です。最大ヘルス率のデフォルト値は 200% です。  
更新中にサービススケジューラがタスクを置き換えるとき、サービスはまずロードバランサーからタスクを削除し (使用されている場合)、接続のドレインが完了するのを待ちます。その後、タスクで実行されているコンテナに **docker stop** と同等のコマンドが発行されます。この結果、`SIGTERM` 信号と 30 秒のタイムアウトが発生し、その後に `SIGKILL` が送信され、コンテナが強制的に停止されます。コンテナが `SIGTERM` 信号を正常に処理し、その受信時から 30 秒以内に終了する場合、`SIGKILL` 信号は送信されません。サービススケジューラは、最小ヘルス率と最大ヘルス率の設定で定義されているとおりに、タスクを開始および停止します。  
また、コンテナのヘルスチェックまたはロードバランサーのターゲットグループのヘルスチェックが失敗すると、サービススケジューラーによって、異常であると判断されたタスクが置き換えられます。この置き換え動作は、`maximumPercent` および `desiredCount` のサービス定義パラメータによって異なります。タスクが異常とマークされた場合、サービススケジューラーによってまず置き換えタスクが開始されます。次に以下が発生します。  
+ 置き換えタスクのヘルスステータスが `HEALTHY` になると、サービススケジューラーが異常のあるタスクを停止します。
+ 置き換えタスクのヘルスステータスが `UNHEALTHY` の場合、スケジューラーは異常のある置き換えタスクまたは既存の異常タスクのいずれかを停止して、タスク総数が `desiredCount` と等しくなるようにします。
`maximumPercent` パラメーターによって、置き換えタスクを先に開始できないようにスケジューラーが制限されている場合、スケジューラーは異常のあるタスクをランダムに 1 つずつ停止して容量を解放してから置き換えタスクを開始します。異常のあるタスクがすべて正常なタスクに置き換えられるまで、起動と停止のプロセスが続きます。異常なタスクがすべて置き換えられ、正常なタスクだけが実行中になると、合計タスク数が `desiredCount` を超える場合、タスク数が `desiredCount` になるまで、正常なタスクが無作為に停止されます。`maximumPercent` および `desiredCount` の詳細については、「[サービス定義パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html)」を参照してください。

**デプロイコントローラー**  
サービスで使用するデプロイコントローラータイプ。次の 3 つのデプロイコントローラータイプを使用できます。  
+ `ECS`
+ `EXTERNAL`
+ `CODE_DEPLOY`
サービスを更新すると、使用されるデプロイコントローラーを更新できます。次のリストは、有効な移行を表示しています。  
+ CodeDeploy ブルー/グリーンデプロイ (`CODE_DEPLOY`) から ECS ローリングデプロイまたはブルー/グリーンデプロイ (`ECS`) に更新します。
+ CodeDeploy ブルー/グリーンデプロイ (`CODE_DEPLOY`) から外部デプロイ (`EXTERNAL`) に更新します。
+ ECS ローリングまたはブルー/グリーンデプロイ (`ECS`) から外部デプロイ (`EXTERNAL`) に更新します。
+ 外部デプロイ (`EXTERNAL`) から ECS ローリングデプロイまたはブルー/グリーンデプロイ (`ECS`) に更新します。
サービスのデプロイコントローラーを更新する際には、次の点を考慮してください。  
+ VPC Lattice または Amazon ECS Service Connect を使用している場合、サービスのデプロイコントローラーを `ECS` デプロイコントローラーから他のコントローラーに更新することはできません。
+ サービスのデプロイ中に、サービスのデプロイコントローラーを更新することはできません。
+ サービスにロードバランサーがない場合、サービスのデプロイコントローラーを `CODE_DEPLOY` に更新することはできません。
+ `deploymentConfiguration` にアラーム、デプロイサーキットブレーカー、`BLUE_GREEN` デプロイ戦略が含まれている場合、サービスのデプロイコントローラーを `ECS` から他のコントローラーに更新することはできません。詳細については、「[Amazon ECS サービスデプロイコントローラーと戦略](ecs_service-options.md)」を参照してください。
+ サービスのデプロイコントローラーを `ECS` から他のコントローラーに更新した場合、コンテナ定義で `versionConsistency` に指定した値は Amazon ECS で使用されません。
+ サービスのデプロイコントローラーを `ECS` から他のコントローラーに更新しても、`UpdateService` および `DescribeService` API レスポンスは依然として `taskSets` ではなく、`deployments` を返します。`UpdateService` および `CreateService` の詳細については、「*Amazon ECS API Reference*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html)」および「[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html)」を参照してください。
+ サービスがローリング更新のデプロイ戦略を使用している場合、デプロイコントローラーを `ECS` から他のコントローラーに更新すると、`deploymentConfiguration` の `maximumPercent` 値の使用方法が変更されます。ローリング更新デプロイで合計タスクの上限として使用されるだけではなく、`maximumPercent` は異常なタスクを置き換えるために使用されます。スケジューラが異常なタスクを置き換える方法の詳細については、「[Amazon ECS サービス](ecs_services.md)」を参照してください。
+ サービスのデプロイコントローラーを `ECS` から他のデプロイコントローラーに更新した場合、ロードバランサー設定で指定した `advancedConfiguration` は無視されます。詳細については、「*Amazon ECS API リファレンス*」の「[LoadBalancer](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LoadBalancer.html)」および「[AdvancedConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AdvancedConfiguration.html)」を参照してください。
CloudFormation を使用してサービスのデプロイコントローラーを更新する際には、実行する移行のタイプに応じて次の点を考慮してください。  
+ `EXTERNAL` デプロイコントローラー情報に加え、`TaskSet` および `PrimaryTaskSet`リソースを含む CloudFormation テンプレートがあって、`EXTERNAL` から `ECS` に更新するときにテンプレートからタスクセットのリソースを削除する場合、デプロイコントローラーが `ECS` に更新されると、`DescribeTaskSet` および `DeleteTaskSet` API コールは 400 エラーを返します。CloudFormation スタックを `UPDATE_COMPLETE` ステータスに移行しても、タスクセットのリソースで CloudFormation の削除が失敗します。詳細については、「AWS CloudFormation ユーザーガイド」の「[リソースはスタックから削除されましたが、削除されない](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted)」を参照してください。この問題を解決するには、Amazon ECS `DeleteTaskSet` API を使用してタスクセットを直接削除します。タスクセットを削除する方法の詳細については、「*Amazon Elastic Container Service* *API リファレンス*」の「[DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html)」を参照してください。
+ 新しいタスク定義で `CODE_DEPLOY` から `ECS` に移行して、CloudFormation でロールバックオペレーションを実行すると、Amazon ECS `UpdateService` リクエストは次のエラーで失敗します。

  ```
  Resource handler returned message: "Invalid request provided: Unable to update 
  task definition on services with a CODE_DEPLOY deployment controller. Use AWS 
  CodeDeploy to trigger a new deployment. (Service: Ecs, Status Code: 400, 
  Request ID: 0abda1e2-f7b3-4e96-b6e9-c8bc585181ac) (SDK Attempt Count: 1)" 
  (RequestToken: ba8767eb-c99e-efed-6ec8-25011d9473f0, HandlerErrorCode: InvalidRequest)
  ```
+ `ECS` から `EXTERNAL` デプロイコントローラーへの移行が正常に完了した後には、Amazon ECS がデプロイを管理しなくなるため、`ACTIVE` タスクセットを手動で削除する必要があります。タスクセットを削除する方法の詳細については、「Amazon Elastic Container Service *API リファレンス*」の「[DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html)」を参照してください。

**希望タスク数**  
タスクのインスタンスをサービス内に配置し、実行し続ける数です。  
サービスを一時的に停止したい場合は、この値を 0 に設定します。次に、サービスを開始する準備ができたら、サービスを元の値で更新します。  
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。

**マネージドタグの有効化**  
サービス内のタスクに Amazon ECS マネージドタグをオンにするか否かを決定します。  
更新後に起動されたタスクのみに更新が反映されます。すべてのタスクのタグを更新する場合、強制デプロイオプションを使用します。  
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。

**ECS Exec の有効化**  
Amazon ECS Exec を使用するかどうかを決定します。  
サービスの作成時に設定された値を上書きしたくない場合は、このアクションを実行するときにこれを null に設定できます。  
このパラメータはローリングデプロイで変更できます。

**ヘルスチェックの猶予期間**  
Amazon ECS サービススケジューラが、タスクが最初に開始された後で異常な Elastic Load Balancing、VPC Lattice、コンテナのヘルスチェックを無視する期間 (秒単位)。ヘルスチェックの猶予期間値を指定しない場合、デフォルト値 `0` が使用されます。ヘルスチェックを使用しない場合、`healthCheckGracePeriodSeconds` は使用されません。  
サービスのタスクが開始してヘルスチェックに応答するまでに時間がかかる場合は、ヘルスチェックの猶予期間として最大 2,147,483,647 秒 (約 69 年) まで指定できます。この間は、Amazon ECS サービススケジューラはヘルスチェックのステータスを無視します。この猶予期間により、サービススケジューラがタスクを異常とマークして時間より前に停止することがなくなります。  
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。

**ロードバランサー**  
ロードバランサーを更新するとき、サービスにリンクされたロールを使用する必要があります。  
Elastic Load Balancing ロードバランサーオブジェクトのリストです。これには、ロードバランサー名、コンテナ名、ロードバランサーからアクセスするコンテナポートが含まれます。コンテナ名は、コンテナの定義に表示されるものです。  
Amazon ECS は、Elastic Load Balancing ロードバランサーまたは Amazon ECS コンテナインスタンスに関連付けられたセキュリティグループを自動的には更新しません。  
ロードバランサー設定を追加、更新、削除すると、Amazon ECS は、更新された Elastic Load Balancing 設定で新しいタスクを開始し、その後新しいタスクを実行中に古いタスクを停止します。  
ローリング更新を使用するサービスの場合、Elastic Load Balancing ターゲットグループを追加、更新、削除できます。1 つのターゲットグループから複数のターゲットグループに、および複数のターゲットグループから 1 つのターゲットグループに更新できます。  
ブルー/グリーンデプロイを使用するサービスの場合、CodeDeploy を介して `[CreateDeployment](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_CreateDeployment.html)` を使用し、Elastic Load Balancing ターゲットグループを更新できます。ブルー/グリーンデプロイでは、複数のターゲットグループがサポートされていないことに注意してください。詳細については、「[Amazon ECS サービスに複数のターゲットグループを登録する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html)」を参照してください。  
外部デプロイコントローラーを使用するサービスの場合、[CreateTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateTaskSet.html) を使用してロードバランサーを追加、更新、削除できます。外部デプロイでは、複数のターゲットグループがサポートされていないことに注意してください。詳細については、「[Amazon ECS サービスに複数のターゲットグループを登録する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html)」を参照してください。  
空のリストを渡してロードバランサーを削除します。  
このパラメータはローリングデプロイで変更できます。

**ネットワーク構成**  
サービスのネットワーク構成です。  
このパラメータはローリングデプロイで変更できます。

**配置の制約事項**  
使用するサービスを更新するための、タスク配置制約オブジェクトの配列です。値を指定しないと、サービスの既存の配置制約は変更されません。この値を指定すると、サービスに定義されているすべての既存の配置制約が上書きされます。既存の配置制約をすべて削除するには、空の配列を指定します。  
タスクごとに最大 10 個の制約を指定できます。この制限数には、タスク定義内の制約と、実行時に指定される制約が含まれます。  
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。

**配置戦略**  
使用するサービスを更新するためのタスク配置戦略オブジェクトです。値を指定しないと、サービスの既存の配置戦略は変更されません。この値を指定すると、サービスに定義されているすべての既存の配置戦略が上書きされます。既存の配置戦略を削除するには、空のオブジェクトを指定します。  
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。

**プラットフォームバージョン**  
サービスが実行される Fargate プラットフォームバージョンです。  
Linux プラットフォームのバージョンを使用するサービスは、Windows プラットフォームのバージョンを更新できません。その逆も同様です。  
このパラメータはローリングデプロイで変更できます。

**タグの伝播**  
タグをタスク定義またはサービスからタスクへ伝播するかどうかを決定します。値を指定しない場合、タグは伝播されません。  
更新後に起動されたタスクのみに更新が反映されます。すべてのタスクのタグを更新するには、`forceNewDeployment` を `true` に設定して、Amazon ECS が更新されたタグで新しいタスクを開始するようにします。  
このパラメータは、ローリングデプロイとブルー/グリーンデプロイの場合変更できます。

**Service Connect の設定**  
Amazon ECS Service Connect の設定です。このパラメータは、サービスがどのようにアプリケーション内の他のサービスに接続するかを決定します。  
このパラメータはローリングデプロイで変更できます。

**サービスレジストリ**  
サービスレジストリを更新するとき、サービスにリンクされたロールを使用する必要があります。  
このサービスに割り当てるサービス検出レジストリの詳細。詳細については、「[サービス検出](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html)」を参照してください。  
サービスレジストリ設定を追加、更新、削除すると、Amazon ECS は更新されたサービスレジストリ設定で新しいタスクを開始し、その後新しいタスクの実行時に古いタスクを停止します。  
空のリストを渡して、サービスレジストリを削除します。  
このパラメータはローリングデプロイで変更できます。

**タスク定義**  
サービス内のタスクに使用するタスクの定義とリビジョンです。  
タスク定義でコンテナが使用するポートを変更する場合は、更新後のポートを使用するようにコンテナインスタンスのセキュリティグループを更新する必要がある場合があります。  
サービスのタスク定義を更新する場合は、ロードバランサー設定で指定されたコンテナ名とコンテナポートはタスク定義のままにしておく必要があります。  
コンテナイメージのプル動作は、コンピューティングオプションによって異なります。詳細については、以下のいずれかを参照してください。  
+ [Amazon ECS の AWS Fargate 用のアーキテクト](AWS_Fargate.md)
+ [Amazon ECS 用の EC2 キャパシティのアーキテクト](launch-type-ec2.md)
+ [Amazon ECS の外部インスタンス (Amazon ECS Anywhere)](launch-type-external.md)
このパラメータはローリングデプロイで変更できます。

**ボリューム設定**  
`configuredAtLaunch` だったボリュームの詳細です。タスク定義で `configuredAtLaunch`が `true` に設定されていると、デプロイ中に作成およびアタッチされるサービス内のタスクごとに、このサービスパラメータによって 1 つの Amazon EBS ボリュームが設定されます。[ServiceManagedEBSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceManagedEBSVolumeConfiguration.html) では、サイズ、volumeType、IOPS、スループット、スナップショット、暗号化を設定できます。ボリュームの `name` は、タスク定義の `name` と一致する必要があります。null に設定すると、新しいデプロイがトリガーされません。それ以外では、この設定が既存の設定と異なると、新しいデプロイがトリガーされます。  
このパラメータはローリングデプロイで変更できます。

**VPC Lattice の設定**  
サービスの VPC Lattice 設定です。サービス間の通信のためにサービスと VPC Lattice を統合する方法を定義します。  
このパラメータはローリングデプロイで変更できます。

## AWS CDK に関する考慮事項
<a name="cdk-considerations"></a>

AWS CDK はリソースの状態を追跡しません。サービスを作成しているのか、更新しているかはわかりません。お客様は、エスケープハッチを使用して ecs `Service` L1 コンストラクトに直接アクセスする必要があります。

エスケープハッチの詳細については、「*AWS Cloud Development Kit (AWS CDK) v2 デベロッパーガイド*」の「[AWS コンストラクトライブラリからコンストラクトをカスタマイズする](https://docs.aws.amazon.com/cdk/v2/guide/cfn-layer.html#develop-customize-escape)」を参照してください。

既存のサービスを `ecs.Service` コンストラクトに移行するには、次を実行します。

1. エスケープハッチを使用して、`Service` L1 コンストラクトにアクセスします。

1. `Service` L1 コンストラクトで次のプロパティを手動で設定します。

   サービスが Amazon EC2 容量を使用している場合:
   + `daemon?`
   + `placementConstraints?`
   + `placementStrategies?`
   + `awsvpc` ネットワークモードを使用する場合は、`vpcSubnets?` および `securityGroups?` コンストラクトを設定する必要があります。

   サービスが Fargate を使用している場合:
   + `FargatePlatformVersion`
   + `vpcSubnets?` と `securityGroups?` コンストラクト。

1. `launchType` を次のように設定します。

   ```
   const cfnEcsService = service.node.findChild('Service') as ecs.CfnService;
   cfnEcsService.launchType = "FARGATE";
   ```

起動タイプからキャパシティプロバイダーに移行するには、次を実行します。

1. エスケープハッチを使用して、`Service` L1 コンストラクトにアクセスします。

1. `capacityProviderStrategies?` コンストラクトを追加します。

1. サービスをデプロイします。

# Amazon ECS サービスを更新する
<a name="update-service-console-v2"></a>

サービスを作成した後、タスクの数など、サービスパラメータを更新する必要がある場合があります。

Amazon ECS サーキットブレーカーを使用するサービスを更新すると、Amazon ECS はサービスデプロイとサービスリビジョンを作成します。これらのリソースを使用すると、サービス履歴に関する詳細情報を表示できます。詳細については、「[Amazon ECS サービスデプロイを使用してサービス履歴を表示する](service-deployment.md)」を参照してください。

## 前提条件
<a name="update-service-prerequisites"></a>

サービスを更新する前に、デプロイタイプで変更可能なサービスパラメータを確認してください。変更可能なパラメータの詳細なリストについては、「[Amazon ECS サービスのパラメータの更新](update-service-parameters.md)」を参照してください。

## 手順
<a name="update-service-procedure"></a>

------
#### [ Console ]

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. クラスターの詳細ページの **[サービス]** セクションで、サービスの横にあるチェックボックスを選択し、**[更新]** を選択します。

1. サービスで新しいデプロイを開始するには、**[新しいデプロイの強制]** を選択します。

1. **[タスク定義]** の場合、タスク定義ファミリーとリビジョンを選択します。
**重要**  
コンソールは、選択したタスク定義ファミリーおよびリビジョンが、定義されたコンピューティング設定と互換性があることを確認します。警告が表示された場合は、タスク定義の互換性と、選択したコンピューティング設定の両方を確認します。

1. **[Replica]** (レプリカ) を使用した場合、**[Desired tasks]** (必要なタスク) に、サービス内で起動および維持するタスクの数を入力します。

1. **[レプリカ]** を選択した場合、Amazon ECS がアベイラビリティーゾーン間のタスクの分散をモニタリングし、不均衡が発生したときにタスクを再分散させるには、**[アベイラビリティーゾーンのサービス再調整] **で、**[アベイラビリティーゾーンのサービス再調整]** を選択します。

1. **[Min running tasks]** (実行中のタスクの最小化) の場合、デプロイ時に `RUNNING` の状態に保つ必要のあるサービス内のタスクの下限数をタスクの必要数のパーセント値 (最も近い整数に切り上げ) で入力します。詳細については、[[Deployment configuration]](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration) (デプロイ設定) を参照してください。

1. **[Max running tasks]** (実行中のタスクの最大化)) には、デプロイ時に `RUNNING` または `PENDING` 状態にできるサービスのタスクの上限数を必要数のタスクのパーセント値 (最も近い整数に切り下げ) で入力します。

1. サービスにタスクがデプロイされる方法を設定するには、**[デプロイオプション]** を展開してオプションを設定します。

   1. **[デプロイコントローラータイプ]** には、サービスデプロイのコントローラーを指定します。Amazon ECS コンソールは、`ECS` コントローラータイプをサポートします。

   1. **[デプロイ戦略]** には、Amazon ECS がサービスの新しいバージョンをデプロイするために使用される戦略を選択します。

   1. **[デプロイ戦略]** の選択に応じて、次の操作を行います。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/update-service-console-v2.html)

   1. ライフサイクルステージに Lambda 関数を実行するには、**[デプロイライフサイクルフック]** で一意の Lambda 関数ごとに次の操作を行います。

      1. **[Add]** (追加) を選択します。

         実行する一意の関数ごとにこの操作を繰り返します。

      1. **[Lambda 関数]** には、関数名を入力します。

      1. **[ロール]** には、ブルー/グリーンのアクセス許可を持つ前提条件で作成したロールを選択します。

         詳細については、「[Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可](blue-green-permissions.md)」を参照してください。

      1. **[ライフサイクルステージ]** には、Lambda 関数が実行されるステージを選択します。

      1.  (オプション) **[フックの詳細]** には、フックに関する情報を提供するキーおよび値のペアを入力します。

1. Amazon ECS がデプロイの障害を検出して処理する方法を設定するには、**[Deployment failure detection]** (デプロイ障害検出) を展開し、オプションを選択します。

   1. タスクを開始できない場合にデプロイを停止するには、**[Use the Amazon ECS deployment circuit breaker]** (Amazon ECS デプロイサーキットブレーカーを使用する) を選択します。

      デプロイサーキットブレーカーによってデプロイが失敗状態に設定されたときに、ソフトウェアがデプロイを最後に完了したデプロイ状態に自動的にロールバックするようにするには、**[失敗時のロールバック]** を選択します。

   1. アプリケーションメトリクスに基づいてデプロイを停止するには、**[CloudWatch アラームを使用する]** を選択します。次に、**[CloudWatch アラーム名]** からアラームを選択します。新しいアラームを作成するには、CloudWatch コンソールに移動します。

      CloudWatch アラームによってデプロイが失敗状態に設定されたときに、ソフトウェアがデプロイを最後に完了したデプロイ状態に自動的にロールバックするようにするには、**[失敗時のロールバック]** を選択します。

1. 計算オプションを変更するには、**[コンピュート構成]** を展開してから以下の操作を実行します。

   1. AWS Fargate のサービスにとって、**[Platform version]** (プラットフォームのバージョン) で、新しいバージョンを選択します。

   1. キャパシティプロバイダー戦略を使用するサービスの場合、**[キャパシティプロバイダー戦略]** で、次を実行します。
      + キャパシティプロバイダーをさらに追加するには、**[さらに追加]** を選択します。その後、**[キャパシティプロバイダー]** で、キャパシティプロバイダーを選択します。
      + キャパシティプロバイダーを削除するには、キャパシティプロバイダーの右側にある **[削除]** を選択します。

      Auto Scaling グループキャパシティープロバイダーを使用するサービスは、Fargate キャパシティープロバイダーを使用するように更新することはできません。Fargate キャパシティプロバイダーを使用するサービスは、Auto Scaling グループキャパシティプロバイダーを使用するように更新できません。

1. (オプション) サービスの自動スケーリングを設定するには、**[サービスの自動スケーリング]** を展開し、次のパラメータを指定します。トラフィックフローからの過去のロードデータを調べる予測自動スケーリングを使用するには、サービスを作成した後にそれを設定します。詳細については、「[履歴パターンを使用して予測スケーリングで Amazon ECS サービスをスケールする](predictive-auto-scaling.md)」を参照してください。

   1. サービスの自動スケーリングを使用するには、**[Service auto scaling]** (サービスの自動スケーリング) を選択します。

   1. **[タスクの最小数]** に、サービスの自動スケーリングで使用するタスクの下限数を入力します。必要な数がこの数を下回ることはありません。

   1. **[タスクの最大数]** に、サービスの自動スケーリングで使用するタスクの上限数を入力します。必要な数がこの数を超えることはありません。

   1. ポリシータイプを選択します。**[スケーリングポリシータイプ]** で、次のいずれかのオプションを選択します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/update-service-console-v2.html)

1. (オプション) Service Connect を使用するには、**[Turn on Service Connect]** (Service Connect をオンにする) を選択し、以下を指定します。

   1. **[Service Connect configuration]** (Service Connect 設定) で、クライアントモードを指定します。
      + サービスが名前空間内の他のサービスへの接続のみを必要とするネットワーククライアントアプリケーションを実行している場合は、**[クライアント側のみ]** を選択します。
      + サービスがネットワークまたは Web サービスアプリケーションを実行していて、このサービスにエンドポイントを提供し、名前空間内の他のサービスに接続する必要がある場合は、**[Client and server]** (クライアントとサーバー) を選択します。

   1. デフォルトのクラスター名前空間ではない名前空間を使用するには、**[Namespace]** (名前空間) でサービス名前空間を選択します。この場合、AWS アカウントの同じ AWS リージョンで個別に作成された名前空間、またはAWS Resource Access Manager (AWS RAM) を使用してアカウントと共有されている同じリージョンの名前空間のいずれかを選択できます。共有 AWS Cloud Map 名前空間の詳細については、「*AWS Cloud Map デベロッパーガイド*」の「[クロスアカウント AWS Cloud Map 名前空間の共有](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)」を参照してください。

   1. （オプション) ログ設定を指定します。**[ログコレクションを使用]** を選択します。デフォルトのオプションでは、コンテナログを CloudWatch Logs に送信します。その他のログドライバオプションは、AWS FireLens を使用して構成されます。詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。

      以下では、各コンテナログの送信先について詳しく説明します。
      + **Amazon CloudWatch** — コンテナログを CloudWatch Logs に送信するようにタスクを設定します。デフォルトのログドライバーオプションが提供され、ユーザーに代わり CloudWatch ロググループを作成します。別のロググループ名を指定するには、ドライバーオプションの値を変更します。
      + **[Amazon Data Firehose]** — Firehose にコンテナログを送信するようタスクを設定します。Firehose 配信ストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別の配信ストリーム名を指定するには、ドライバーオプションの値を変更します。
      + **Amazon Kinesis Data Streams** — Kinesis Data Streams にコンテナログを送信するようタスクを設定します。Kinesis Data Streams のストリームにログを送信するデフォルトのログドライバーオプションが提供されています。別のストリーム名を指定するには、ドライバーオプションの値を変更します。
      + **Amazon OpenSearch Service** — コンテナログを OpenSearch Service ドメインに送信するようタスクを設定します。ログドライバーオプションを提供する必要があります。
      + **Amazon S3** — Amazon S3 バケットにコンテナログを送信するようタスクを設定します。デフォルトのログドライバーオプションが提供されていますが、有効な Amazon S3 バケット名を指定する必要があります。

   1. アクセスログを有効にするには、次の手順に従います。

      1. **[アクセスログ設定]** を展開します。**[形式]** で、**[JSON]** または [`TEXT`] を選択します。

      1. アクセスログにクエリパラメータが含まれるようにするには、**[クエリパラメータを含める]** を選択します。
**注記**  
アクセスログを無効にするには、**[フォーマット]** で **[なし]** を選択します。

1. デプロイ時の設定と互換性のあるデータボリュームをタスクで使用する場合は、**[ボリューム]** を拡張してボリュームを設定できます。

   ボリューム名とボリュームタイプはタスク定義リビジョンを作成するときに設定され、サービスの更新時には変更できません。ボリューム名とタイプを更新するには、新しいタスク定義リビジョンを作成し、新しいリビジョンを使用してサービスを更新する必要があります。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/update-service-console-v2.html)

1. (オプション) サービスを識別しやすくするには、**[Tags]** (タグ) セクションを展開し、タグを設定します。
   + [タグの追加] **[タグの追加]** を選択して、以下を実行します。
     + [**キー**] にはキー名を入力します。
     + [**値**] にキー値を入力します。
   + [タグの削除] タグの横にある [**タグの削除**] を選択します。

1. **[更新]** を選択します。

------
#### [ AWS CLI ]
+ `update-service` を実行します。コマンドの実行の詳細ついては、「AWS Command Line Interfaceリファレンス」の「[update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)」を参照してください。

  次の `update-service` の例では、`my-http-service` サービスのタスクの数を 2 に更新します。

  *user-input* を独自の値に置き換えます。

  ```
  aws ecs update-service \
      --cluster MyCluster \
      --service my-http-service \
      --desired-count 2
  ```

------

## 次のステップ
<a name="update-service-next-steps"></a>

Amazon ECS サーキットブレーカーのサービスのデプロイを追跡し、サービス履歴を表示します。詳細については、「[Amazon ECS サービスデプロイを使用してサービス履歴を表示する](service-deployment.md)」を参照してください。

# キャパシティプロバイダーを使用するように Amazon ECS サービスを更新する
<a name="update-service-managed-instances"></a>

Amazon EC2 または Fargate 起動タイプを使用する既存のサービスがあり、Amazon ECS マネージドインスタンスを使用する必要がある場合は、Amazon ECS マネージドインスタンスキャパシティプロバイダーを使用するようにサービスを更新する必要があります。

## 前提条件
<a name="update-service-managed-instances-prerequisites"></a>

Amazon ECS マネージドインスタンスのキャパシティプロバイダーを作成します。詳細については、「[Amazon ECS マネージドインスタンスのキャパシティプロバイダーを作成する](create-capacity-provider-managed-instances.md)」を参照してください。

## 手順
<a name="update-service-managed-instances-procedure"></a>

------
#### [ Console ]

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. クラスターの詳細ページの **[サービス]** セクションで、サービスの横にあるチェックボックスを選択し、**[更新]** を選択します。

1. **[新しいデプロイを強制する]** を選択します。

1. **[コンピューティングオプション]** で、[キャパシティプロバイダー戦略] を選択します。続いて、次のいずれかを選択します。
   + Amazon ECS マネージドインスタンスキャパシティプロバイダーがデフォルトのキャパシティプロバイダーである場合は、**[クラスターのデフォルトを使用する]** を選択します。
   + Amazon ECS マネージドインスタンスキャパシティプロバイダーがデフォルトのキャパシティプロバイダーでない場合は、**[カスタム (アドバンスト) を使用]** を選択します。Amazon ECS マネージドインスタンスのキャパシティプロバイダーを選択し、**[重み]** で [1] を選択します。

1. **[更新]** を選択します。

------
#### [ AWS CLI ]
+ `update-service` を実行します。コマンドの実行の詳細ついては、「AWS Command Line Interfaceリファレンス」の「[update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)」を参照してください。

  *user-input* を独自の値に置き換えます。

  ```
  aws ecs update-service \
      --cluster my-cluster \
      --service my-service \
      --capacity-provider-strategy capacityProvider=my-managed-instance-capacity-provider,weight=1 \
      --force-new-deployment
  ```

------

# コンソールを使用して Amazon ECS サービスの削除
<a name="delete-service-v2"></a>

サービスを削除する理由としては、次のようなものがあります。
+ アプリケーションが不要になった
+ サービスを新しい環境に移行する
+ アプリケーションがアクティブに使用されていない
+ アプリケーションが必要以上のリソースを使用しているため、コストを最適化しようとしている

削除する前に、このサービスは自動的に 0 までスケールダウンされます。サービスに関連付けられているロードバランサーリソース、またはサービス検出リソースは、サービスの削除による影響を受けません。Elastic Load Balancing リソースを削除するには、ロードバランサーのタイプに応じて、次のいずれかのトピックを参照してください。「[Application Load Balancer の削除](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-delete.html)」または「[Network Load Balancer の削除](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-delete.html)」。

サービスを削除すると、Amazon ECS はそのサービスのすべてのサービスデプロイとサービスリビジョンを削除します。

サービスを削除するときに、クリーンアップが必要なタスクがまだ実行中の場合、サービスは `ACTIVE` から `DRAINING` ステータスに移行し、そのサービスステータスはコンソールまたは `ListServices` API オペレーションで表示されなくなります。すべてのタスクが `STOPPING` または `STOPPED` ステータスに以降されたら、サービスステータスは `DRAINING` から `INACTIVE` になります。`DRAINING` または `INACTIVE` ステータスのサービスは、`DescribeServices` API オペレーションで引き続き表示できます。

**重要**  
`ACTIVE` または `DRAINING` ステータスの既存のサービスと同じ名前で新しいサービスを作成しようとすると、エラーが表示されます。

**手順**

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. **[Clusters]** (クラスター) ページで、サービスに使用するクラスターを選択します。

1. **[Clusters]** (クラスター) ページで、クラスターを選択します。

1. **[Cluster: *name*]** (クラスター: 名前) ページで、**[Services]** (サービス) タブを選択します。

1. サービスを選択して、**[Delete]** (削除) を選択します。

1. タスクがゼロになっていなくてもサービスを削除するには、**[Force delete service]** (サービスの強制削除) を選択します。

1. 確認プロンプトで、**delete** と入力し、**[削除]** を選択します。

# Amazon ECS の短いサービス ARN を長い ARN に移行する
<a name="service-arn-migration"></a>

Amazon ECS は、各サービスに一意の Amazon リソースネーム (ARN) を割り当てます。2021 年以前に作成されたサービスは、短いARN 形式を使用しています。

 `arn:aws:ecs:region:aws_account_id:service/service-name`

Amazon ECS では、クラスター名を含めるように ARN 形式を変更しました。これは長い ARN 形式です。

`arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

サービスにタグを付けるには、長いARN形式を使用する必要があります。

サービスを再作成する必要なく、短い ARN 形式のサービスを長い ARN 形式のサービスへと移行できます。API、CLI、またはコンソールを使用できます。移行オペレーションを元に戻すことはできません。

移行プロセスはシームレスで、サービスのダウンタイムゼロを確保できます。移行中の詳細
+ **サービスの可用性**: トラフィックや機能を中断することなく、サービスを正常に実行し続けます。
+ **タスクの実行**: 既存のタスクは中断されることなく、実行し続けます。`taskLongArnFormat` アカウント設定が有効になっている場合、移行後に起動される新しいタスクには長い ARN 形式が使用されます。
+ **コンテナインスタンス**: コンテナインスタンスはサービス ARN の移行の影響を受けることはなく、正常に動作し続けます。
+ **サービス設定**: すべてのサービス設定が変更されません (タスク定義、ネットワーク、ロードバランサー設定など)。

CloudFormation を使用して短い ARN 形式でサービスにタグ付けする場合は、API、CLI、またはコンソールを使用してサービスを移行する必要があります。移行が完了したら、 CloudFormation を使用してサービスにタグを付けることができます。

Terraform を使用して短い ARN 形式でサービスにタグ付けする場合は、API、CLI、またはコンソールを使用してサービスを移行する必要があります。移行が完了したら、Terraform を使用してサービスにタグを付けることができます。

移行が完了すると、サービスには次の変更が行われます。
+ 長い ARN 形式

  `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`
+ コンソールを使用して移行する場合、Amazon ECS はキーを「ecs:serviceArnMigratedAt」に設定し、値を移行タイムスタンプ (UTC 形式) に設定して、サービスにタグを追加します。

  このタグは、タグクォータにカウントされます。
+ CloudFormation スタック内の `PhysicalResourceId` がサービス ARN を表す場合、値は変更されず、引き続き短いサービス ARN になります。

## 前提条件
<a name="migrate-service-arn-prerequisite"></a>

サービス ARN を移行する前に、次のオペレーションを実行します。

1. 短い ARN 形式 があるかどうかを確認するには、Amazon ECS コンソールでサービスの詳細を表示するか (サービスが短い ARN 形式である場合は警告が表示されます)、または `describe-services` の `serviceARN` 戻りパラメータを表示します。ARN にクラスター名が含まれていない場合、短い ARN になります。短い ARN の形式は次のとおりです。

    `arn:aws:ecs:region:aws_account_id:service/service-name`

1. 作成日をメモします。

1.  短い ARN 形式を使用する IAM ポリシーがある場合は、長い ARN 形式に更新します。

   各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。

    `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

   詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[Editing IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」(IAM ポリシーの編集) を参照してください。

1.  短い ARN 形式を使用するツールがある場合は、長い ARN 形式に更新してください。

   各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。

    `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

1. サービスの長い ARN 形式を有効にします。`serviceLongArnFormat` オプションを `enabled` に設定して `put-account-setting` を実行します。詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)」を参照してください。

   サービスの `createdAt` 日付が不明な場合は、ルートユーザーとしてコマンドを実行します。

   ```
   aws ecs put-account-setting --name serviceLongArnFormat --value enabled
   ```

    出力の例

   ```
   {
       "setting": {
           "name": "serviceLongArnFormat",
           "value": "enabled",
           "principalArn": "arn:aws:iam::123456789012:role/your-role",
           "type": user
       }
   }
   ```

1. タスクの長い ARN 形式を有効にします。このアカウント設定により、サービス移行の完了後に起動される新しいタスクの ARN 形式が制御されます。`taskLongArnFormat` オプションを `enabled` に設定して `put-account-setting` を実行します。詳細については、「*Amazon Elastic Container Service API リファレンス*」の「[put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)」を参照してください。

   サービスの `createdAt` 日付が不明な場合は、ルートユーザーとしてコマンドを実行します。

   ```
   aws ecs put-account-setting --name taskLongArnFormat --value enabled
   ```

    出力の例

   ```
   {
       "setting": {
           "name": "taskLongArnFormat",
           "value": "enabled",
           "principalArn": "arn:aws:iam::123456789012:role/your-role",
           "type": user
       }
   }
   ```
**注記**  
`taskLongArnFormat` 設定では、既存のタスクは直接移行されません。設定が有効になった後に作成される新しいタスクの ARN 形式のみに影響を与えます。通常のサービスオペレーション (デプロイやスケーリングアクティビティなど) によって置き換えられるまで、既存の実行中のタスクは現在の ARN 形式を保持します。

## 手順
<a name="migrate-service-arn-procedure"></a>

サービス ARN を移行するには、以下を使用します。

### コンソール
<a name="migrate-service-arn-procedure-console"></a>

1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。

1. **[クラスター]** ページで、クラスターを選択します。

1. **[サービス]** セクションで、ARN 列に警告があるサービスを選択します。

   [サービス詳細] ページが表示されます。

1. **[長い ARN に移行する]** を選択します。

   サービス移行ダイアログボックスが表示されます。

1. **移行** を選択します。

### CLI
<a name="migrate-service-arn-procedure-cli"></a>

前提条件を完了したら、サービスにタグを付けることができます。次のコマンドを実行します。

Amazon ECS は、短いARNを持つサービスに対する `tag-resource` APIリクエストで長い ARN 形式を渡すことを、そのサービスを長い ARN 形式を使用するよう移行するシグナルとみなします。

```
aws ecs tag-resource \
    --resource-arn arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name
    --tags key=key1,value=value1
```

次の例では、キーが「TestService」に設定され、値が「WebServers」に設定されたタグで MyService にタグを付けます。

```
aws ecs tag-resource \
    --resource-arn arn:aws:ecs:us-east-1:123456789012:service/MyCluster/MyService
    --tags key=TestService1,value=WebServers
```

### Terraform
<a name="migrate-service-arn-procedure-terraform"></a>

前提条件を完了したら、サービスにタグを付けることができます。`aws_ecs_service` リソースを作成し、`tags` リファレンスを設定します。詳細については、Terraform ドキュメントの「[Resource: aws\$1ecs\$1service](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_service)」を参照してください。

```
resource "aws_ecs_service" "MyService" {
  name    = "example"
  cluster = aws_ecs_cluster.MyService.id

 tags = {
 "Name"  =  "MyService"
 "Environment"  =  "Production"
 "Department"  =  "QualityAssurance"
  }
}
```

### 次のステップ
<a name="tag-next-steps"></a>

サービスにタグを追加できます。詳細については、「[Amazon ECS リソースにタグを追加する](tag-resources-console.md)」を参照してください。

Amazon ECS でタスク定義またはサービスからタスクにタグを伝達する場合は、`propagateTags` パラメータを指定して `update-service` を実行します。詳細については、「* AWS Command Line Interface リファレンス*」の「[create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)」を参照してください。

## トラブルシューティング
<a name="troubleshooting-arn-migration"></a>

 一部のユーザーの場合、短い ARN 形式から長い ARN 形式に移行すると以下のエラーが発生することがあります。

`There was an error while migrating the ARN of service service-name. The specified account does not have serviceLongArnFormat or taskLongArnFormat account settings enabled. Add account settings in order to enable tagging.` 

 `serviceLongArnFormat` アカウント設定を既に有効にしていてもこのエラーが発生する場合は、長い ARN 形式のアカウント設定が、最初にサービスを作成した特定の IAM プリンシパルに対して有効になっていない可能性があります。

1.  サービスを作成したプリンシパルを特定します。

   1. コンソールでは、Amazon ECS コンソールのサービスの詳細ページの **[設定とネットワーク]** タブの **[作成者]** フィールドで情報を確認できます。

   1. AWS CLI の場合、次のコマンドを実行します。

      *user-input* を独自の値に置き換えます。

      ```
      aws ecs describe-services --cluster cluster-name --services service-name --query 'services[0].{createdBy: createdBy}'
      ```

1. その特定のプリンシパルに必要なアカウント設定を有効にします。これは、次のいずれかの方法で行うことができます。

   1.  そのプリンシパルの IAM ユーザーまたはロールを引き受けます。次に、`put-account-setting` を実行します。

   1.  `principal-arn` で作成プリンシパルを指定しながら、ルートユーザーを使用してコマンドを実行します。

      例。

      *[principal-arn]* をステップ 1 で確認した値に置き換えます。

      ```
      aws ecs put-account-setting --name serviceLongArnFormat --value enabled --principal-arn arn:aws:iam::123456789012:role/jdoe
      ```

 どちらの方法でも、サービスを作成したプリンシパルに必要な `serviceLongArnFormat` アカウント設定が有効になり、ARN 移行を続行できます。

# Amazon ECS サービスのスロットルロジック
<a name="service-throttle-logic"></a>

Amazon ECS サービススケジューラには、タスクが繰り返し起動に失敗した場合にタスク起動をスロットリングする保護ロジックが含まれています。これにより、不要なリソースの消費が防止され、コストを削減できるようになります。

サービス内のタスクが `PENDING` 状態から `RUNNING` 状態への移行に失敗し、代わりに `STOPPED` へと直接移行すると、スケジューラは次のようになります。
+ 再起動の試行間隔を段階的に増やす
+ 試行間隔の遅延を最大 27 分まで増加し続ける
+ 問題を通知するサービスイベントメッセージを生成する

**注記**  
最大遅延時間の 27 分は、今後の更新で変更される場合があります。

スロットリングがアクティブ化されると、次のサービスイベントメッセージが表示されます。

```
(service service-name) is unable to consistently start tasks successfully.
```

スロットリングロジックの重要な特性
+ サービスによって再試行が無期限に継続される
+ 唯一の変更は、再起動間の時間が増加されること
+ ユーザーが設定可能なパラメータがない

## スロットリング問題の解決
<a name="resolving-throttling"></a>

スロットリングを解決するには、次の操作を行います。
+ 新しいタスク定義を使用するようにサービスを更新すると、サービスは即時に通常のスロットリングされていないオペレーションに戻ります。詳細については、「[Amazon ECS サービスを更新する](update-service-console-v2.md)」を参照してください。
+ タスク失敗の根本的な原因に対処します。

スロットリングをトリガーするタスク障害によくある原因は、次のとおりです。
+ 不十分なクラスターリソース (ポート、メモリ、CPU)
  + [リソースサービスのイベントメッセージが不十分](service-event-messages-list.md#service-event-messages-1)と表示されます
+ コンテナイメージのプル失敗
  + 無効なイメージ名、タグ、不十分なアクセス許可が原因で発生する可能性があります
  + [Amazon ECS の停止したタスクのエラーを表示する](stopped-task-errors.md) の `CannotPullContainerError` が発生する
+ ディスク容量の不足
  + [タスク停止エラー](stopped-task-errors.md)の `CannotCreateContainerError` が発生する
  + 解決手順については、「[Amazon ECS の Docker `API error (500): devmapper` のトラブルシューティング](CannotCreateContainerError.md)」を参照してください。

**重要**  
次のシナリオでは、スロットルロジックはトリガーされません。  
`RUNNING` 状態に達した後に停止するタスク
Elastic Load Balancing のヘルスチェックの失敗により、タスクが停止しました
`RUNNING` 状態に達した後に、コンテナコマンドがゼロ以外のコードで終了するタスク

# Amazon ECS サービス定義パラメータ
<a name="service_definition_parameters"></a>

サービス定義は、Amazon ECS サービスの実行方法を定義します。サービス定義では、次のパラメータを指定できます。

## 起動タイプ
<a name="sd-launchtype"></a>

`launchType`  
タイプ: 文字列  
有効な値: `EC2` \$1 `FARGATE` \$1 `EXTERNAL`  
必須: いいえ  
サービスを実行する起動タイプ。起動タイプを指定しない場合は、デフォルトで `capacityProviderStrategy` が使用されます。  
サービスを更新すると、このパラメータは新しいサービスのデプロイをトリガーします。  
`launchType` を指定した場合、`capacityProviderStrategy` パラメータを省略する必要があります。

## キャパシティプロバイダー戦略
<a name="sd-capacityproviderstrategy"></a>

`capacityProviderStrategy`  
タイプ: オブジェクトの配列  
必須: いいえ  
サービスに使用するキャパシティープロバイダー戦略。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。  
キャパシティープロバイダー戦略は、1 つ以上のキャパシティープロバイダーと、それらに割り当てる `base` と `weight` で構成されます。キャパシティープロバイダーは、キャパシティープロバイダー戦略で使用するクラスターに関連付ける必要があります。PutClusterCapacityProviders API は、キャパシティープロバイダーをクラスターに関連付けるために使用されます。`ACTIVE` または `UPDATING` ステータスのキャパシティープロバイダーのみを使用できます。  
`capacityProviderStrategy` を指定した場合、`launchType` パラメータを省略する必要があります。`capacityProviderStrategy` または `launchType` を指定しない場合は、クラスターの `defaultCapacityProviderStrategy` が使用されます。  
Auto Scaling グループを使用するキャパシティープロバイダーを指定する場合は、キャパシティープロバイダーが既に作成されている必要があります。新しいキャパシティープロバイダーは、CreateCapacityProvider API オペレーションで作成できます。  
AWS Fargate キャパシティープロバイダーを使用するには、`FARGATE` または `FARGATE_SPOT` キャパシティープロバイダーを指定します。AWS Fargate キャパシティープロバイダーはすべてのアカウントで使用でき、クラスターに関連付けるだけで使用できるようになります。  
PutClusterCapacityProviders API オペレーションは、クラスターの作成後にクラスターで使用可能なキャパシティープロバイダーのリストを更新するために使用されます。    
`capacityProvider`  <a name="capacityProvider"></a>
タイプ: 文字列  
必須: はい  
キャパシティープロバイダーの短縮名または完全な Amazon リソースネーム (ARN)。  
`weight`  <a name="weight"></a>
タイプ: 整数  
有効な範囲: 0～1,000 の整数。  
必須: いいえ  
ウエイト値は、指定したキャパシティープロバイダーを使用する起動済みタスクの総数に対する相対的な割合を示します。  
例えば、2 つのキャパシティープロバイダーを含む戦略があり、両方の重みが 1 であるとします。ベースが満たされると、タスクは 2 つのキャパシティープロバイダー間で均等に分割されます。同じロジックを使用して、*capacityProviderA* に 1 の重みを指定し、*capacityProviderB* に 4 の重みを指定するとします。その後、*capacityProviderA* を使用して実行される 1 つのタスクごとに、4 つのタスクが *capacityProviderB* を使用します。  
`base`  <a name="base"></a>
タイプ: 整数  
有効な範囲: 0～100,000 の整数。  
必須: いいえ  
ベース値は、指定されたキャパシティープロバイダーで実行するタスクの最小限の数を指定します。キャパシティープロバイダー戦略では、ベースを定義できるキャパシティープロバイダーは 1 つだけです。

## タスク定義
<a name="sd-taskdefinition"></a>

`taskDefinition`  
タイプ: 文字列  
必須: いいえ  
`family` と `revision` (`family:revision`)、またはサービスで実行されるタスク定義の完全な Amazon リソースネーム（ARN）。`revision` を指定しない場合、指定したファミリーの最新の `ACTIVE` リビジョンが使用されます。  
サービスを更新すると、このパラメータは新しいサービスのデプロイをトリガーします。  
ローリングアップデート (`ECS`) デプロイメントコントローラーを使用する場合は、タスク定義を指定する必要があります。

## プラットフォームオペレーティングシステム
<a name="platform-os"></a>

`platformFamily`  
タイプ: 文字列  
必須: 条件による  
デフォルト: Linux  
このパラメータは Fargate でホストされている Amazon ECS サービスに必要です。  
このパラメータは、Amazon EC2 でホストされている Amazon ECS サービスでは無視されます。  
サービスを実行するコンテナ上のオペレーティングシステム。有効な値は、`LINUX`、`WINDOWS_SERVER_2019_FULL`、`WINDOWS_SERVER_2019_CORE`、`WINDOWS_SERVER_2022_FULL`、および `WINDOWS_SERVER_2022_CORE` です。  
サービスに指定するすべてのタスクの `platformFamily` 値は、サービス `platformFamily` 値と一致する必要があります。例えば、`platformFamily` を `WINDOWS_SERVER_2019_FULL` に設定すると、すべてのタスクの `platformFamily` 値は `WINDOWS_SERVER_2019_FULL` でなければなりません。

## プラットフォームバージョン
<a name="sd-platformversion"></a>

`platformVersion`  
タイプ: 文字列  
必須: いいえ  
サービス内のタスクが実行されているプラットフォームのバージョン。プラットフォームのバージョンは、Fargate 起動タイプを使用するタスクに対してのみ指定されています。指定されない場合、デフォルトで最新バージョン (`LATEST`) が使用されます。  
サービスを更新すると、このパラメータは新しいサービスのデプロイをトリガーします。  
AWS Fargate プラットフォームのバージョンを使って、Fargate タスクインフラストラクチャの特定のランタイム環境を参照できます。プラットフォームのバージョンに `LATEST` を指定してタスクを実行またはサービスを作成すると、プラットフォームの最新バージョンをタスクで利用できるようになります。サービスをスケールアップする場合は、これらのタスクには、サービスの最新のデプロイで指定されたプラットフォームのバージョンが提供されます。詳細については、「[Amazon ECS 向け Fargate プラットフォームバージョン](platform-fargate.md)」を参照してください。  
プラットフォームのバージョンは、EC2 起動タイプを使用するタスクには指定されません。

## クラスター
<a name="sd-cluster"></a>

`cluster`  
タイプ: 文字列  
必須: いいえ  
サービスを実行するクラスターの短い名前または完全な Amazon リソースネーム (ARN)。クラスターを指定しない場合は、`default` クラスターが使用されます。

## サービス名
<a name="sd-servicename"></a>

`serviceName`  
タイプ: 文字列  
必須: はい  
サービスの名前。最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコアを使用できます。サービス名は同じクラスター内で一意になるようにしてください。ただし、リージョン内の複数のクラスター間や複数のリージョンにまたがるクラスター間では、同様の名前のサービスがあっても構いません。

## スケジュール戦略
<a name="sd-schedulingstrategy"></a>

`schedulingStrategy`  
タイプ: 文字列  
有効な値: `REPLICA` \$1 `DAEMON`  
必須: いいえ  
使用するスケジュール戦略。スケジュール戦略が指定されていない場合は、`REPLICA` 戦略が使用されます。詳細については、「[Amazon ECS サービス](ecs_services.md)」を参照してください。  
利用できる 2 つのサービススケジューラ戦略があります。  
+ `REPLICA` - レプリカスケジュール戦略では、クラスター全体で必要数のタスクを配置して維持します。デフォルトでは、サービススケジューラによってタスクはアベイラビリティーゾーン間に分散されます。タスク配置の戦略と制約を使用すると、タスク配置の決定をカスタマイズできます。詳細については、「[レプリカスケジューリング戦略](ecs_service-options.md#service_scheduler_replica)」を参照してください。
+ `DAEMON` - デーモンのスケジュール戦略では、指定したすべてのタスク配置制約を満たすクラスター内のアクティブなコンテナインスタンスごとに、1 つのタスクのみをデプロイします。この戦略を使用する場合、タスクの必要数や配置戦略、サービスの自動スケーリングポリシーを指定する必要はありません。詳細については、「[デーモンスケジューリング戦略](ecs_service-options.md#service_scheduler_daemon)」を参照してください。
**注記**  
Fargate タスクは `DAEMON` スケジュール戦略をサポートしていません。

## 必要数
<a name="sd-desiredcount"></a>

`desiredCount`  
タイプ: 整数  
必須: いいえ  
指定されたタスク定義のインスタンスをサービス内に配置し、実行し続ける数です。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。  
このパラメータは、`REPLICA` スケジュール戦略を使用する場合に必要です。サービスが `DAEMON` スケジュール戦略を使用する場合、このパラメータはオプションです。  
サービスの自動スケーリングを使用する場合、現在実行中のサービスを、現在実行中のタスク数よりも少ない `desiredCount` で更新すると、サービスは指定された `desiredCount` までスケールダウンされます 

## デプロイ設定
<a name="sd-deploymentconfiguration"></a>

`deploymentConfiguration`  
タイプ: オブジェクト  
必須: いいえ  
デプロイ時に実行されるタスクの数と、タスクの停止および開始の順序を制御するオプションのデプロイパラメータ。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。    
`maximumPercent`  <a name="maximumPercent"></a>
タイプ: 整数  
必須: いいえ  
サービスでローリング更新 (`ECS`) のデプロイタイプが使用されている場合、`maximumPercent` パラメータは、デプロイ時に `RUNNING`、`STOPPING`、または `PENDING` 状態で許可されるサービスのタスクの上限数を表します。これは、最も近い整数に切り捨てられた `desiredCount` のパーセンテージ (%) として表されます。このパラメータを使用して、デプロイのバッチサイズを定義できます。例えば、サービスで `REPLICA` サービススケジューラを使用して、`desiredCount` が 4 タスク、`maximumPercent` の値が 200% とすると、スケジューラは 4 つの古いタスクを停止する前に、4 つの新しいタスクを開始します。そのために必要なクラスターリソースを使用できることが前提です。`REPLICA` サービススケジューラを使用するサービスのデフォルトの `maximumPercent` 値は 200% です。  
Amazon ECS スケジューラはこのパラメータを使用して、置き換えタスクを開始するためのクラスターリソースが使用可能である限り、最初に置き換えタスクを開始してから、異常なタスクを停止することで、異常なタスクを置き換えます。スケジューラが異常なタスクを置き換える仕組みの詳細については、「[Amazon ECS サービス](ecs_services.md)」を参照してください。  
サービスで `DAEMON` サービススケジューラタイプを使用している場合、`maximumPercent` は 100% のままにする必要があります。これは、デフォルト値です。  
デプロイ時のタスクの最大数は、`desiredCount` に `maximumPercent`/100 を乗算したもので、最も近い整数値に切り下げられます。  
サービスで Blue/Green (`CODE_DEPLOY`) または `EXTERNAL` のいずれかのデプロイタイプと EC2 起動タイプを使用するタスクが使用されている場合、**最大パーセント**の値はデフォルト値に設定されます。この値は、コンテナインスタンスが `DRAINING` 状態にある間、サービス内で `RUNNING` 状態を保つタスクの数の上限を定義する目的で使用されます。  
ブルー/グリーン (`CODE_DEPLOY`) または `EXTERNAL` デプロイタイプのいずれかを使用し、EC2 を使用するタスクがあるサービスのカスタム `maximumPercent` 値を指定することはできません。
サービスがブルー/グリーン (`CODE_DEPLOY`) または `EXTERNAL` デプロイタイプのいずれかを使用し、サービス内のタスクが Fargate を使用する場合、最大パーセント値は使用されません。サービスを説明する際にも、この値は返されます。  
`minimumHealthyPercent`  <a name="minimumHealthyPercent"></a>
タイプ: 整数  
必須: いいえ  
サービスでローリング更新 (`ECS`) のデプロイタイプが使用されている場合、`minimumHealthyPercent` は、デプロイ時に `RUNNING` 状態に留まる必要があるサービスのタスクの下限数を表します。これは、最も近い整数に切り上げられた `desiredCount` のパーセンテージ (%) として表されます。このパラメータを使用して、追加のクラスターキャパシティーを使用せずにデプロイできます。  
例えば、サービスで `desiredCount` が 4 タスク、`minimumHealthyPercent` が 50%、`maximumPercent` が 100% とすると、サービススケジューラは 2 つの新しいタスクを開始する前に、2 つの既存のタスクを停止してクラスターのキャパシティを解放できます。  
 いずれかのタスクに異常があり、`maximumPercent` が Amazon ECS スケジューラによる置き換えタスクの開始を許可しない場合、スケジューラは `minimumHealthyPercent` を制約として使用して、置き換えタスクを起動するためのキャパシティを解放するために、異常なタスクを 1 つずつ停止します。スケジューラが異常なタスクを置き換える仕組みの詳細については、「[Amazon ECS サービス](ecs_services.md)」を参照してください。  
ロードバランサーを使用*しない*サービスの場合は、次のことを考慮してください。  
+ サービスのタスク内のすべての必須コンテナがヘルスチェックに合格すると、サービスは正常と見なされます。
+ タスクにヘルスチェックが定義された必須コンテナがない場合、サービススケジューラは、タスクが `RUNNING` 状態に達した後 40 秒間待ってから、正常性の最小割合の合計にカウントします。
+ タスクに、ヘルスチェックが定義された必須コンテナが 1 つ以上ある場合、サービススケジューラは、タスクが正常ステータスに達するのを待ってから、正常性の最小割合の合計にカウントします。タスク内のすべての必須コンテナがヘルスチェックに合格すると、タスクは正常と見なされます。サービススケジューラが待つことができる時間は、コンテナのヘルスチェックの設定によって決まります。詳細については、「[ヘルスチェック](task_definition_parameters.md#container_definition_healthcheck)」を参照してください。
ロードバランサーを使用*する*サービスについては、次のことを考慮してください。  
+ タスクにヘルスチェックが定義されている必須コンテナがない場合、サービススケジューラは、ロードバランサーターゲットグループのヘルスチェックが正常ステータスを返すのを待ってから、正常性の最小割合の合計にカウントします。
+ タスクにヘルスチェックが定義されている必須コンテナがある場合、サービススケジューラは、タスクが正常なステータスになり、ロードバランサーターゲットグループのヘルスチェックが正常ステータスを返すのを待ってから、タスクを正常性の最小割の合計にカウントします。
レプリカサービスの `minimumHealthyPercent` のデフォルト値は 100% です。`DAEMON` サービススケジュールを使用しているデフォルトの `minimumHealthyPercent` 値は、AWS CLI、AWS SDK、API では 0%、AWS マネジメントコンソール では 50% です。  
デプロイ時の正常なタスクの最小数は、`desiredCount` に `minimumHealthyPercent`/100 を乗算したもので、最も近い整数値に切り上げられます。  
サービスでブルー/グリーン (`CODE_DEPLOY`) または `EXTERNAL` のデプロイタイプが使用されており、EC2 を使用するタスクが実行されている場合、**最小ヘルス率**の値はデフォルト値に設定されます。この値は、コンテナインスタンスが `DRAINING` 状態にある間、サービス内で `RUNNING` 状態を保つタスクの数の下限を定義する目的で使用されます。  
ブルー/グリーン (`CODE_DEPLOY`) または `EXTERNAL` デプロイタイプのいずれかを使用し、EC2 を使用するタスクがあるサービスのカスタム `maximumPercent` 値を指定することはできません。
サービスがブルー/グリーン (`CODE_DEPLOY`) または `EXTERNAL` デプロイタイプのいずれかを使用しており、Fargate を使用するタスクを実行している場合、最小ヘルス率の値は使用されませんが、サービスについて説明する際に値が返されます。

## デプロイコントローラー
<a name="sd-deploymentcontroller"></a>

`deploymentController`  
タイプ: オブジェクト  
必須: いいえ  
サービスで使用するデプロイコントローラータイプ。デプロイメントコントローラーが指定されていない場合は、`ECS` コントローラーが使用されます。詳細については、「[Amazon ECS サービス](ecs_services.md)」を参照してください。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。    
`type`  
タイプ: 文字列  
有効な値: `ECS` \$1 `CODE_DEPLOY` \$1 `EXTERNAL`  
必須: はい  
使用するデプロイコントローラータイプ。次の 3 つのデプロイコントローラータイプを使用できます。    
`ECS`  
Amazon ECS デプロイコントローラーは、ローリング更新、ブルー/グリーン、リニア、Canary の複数のデプロイ戦略をサポートしています。ローリング更新デプロイタイプでは、コンテナの現在実行されているバージョンが最新バージョンに置き換えられます。ブルー/グリーンデプロイでは、新しい環境が作成され、トラフィックがすべて一度に移行されます。リニアデプロイでは、トラフィックを同じ割合で徐々に移行します。カナリアデプロイでは、最初にトラフィックのごく一部を移行してから、残りのトラフィックを移行します。ローリング更新中に Amazon ECS がサービスに追加または削除するコンテナの数は、[deploymentConfiguration](#deploymentConfiguration) で指定されるように、サービスのデプロイ中に許可される正常なタスクの最小数と最大数を調整することで制御されます。  
`CODE_DEPLOY`  
Blue/Green (`CODE_DEPLOY`) デプロイタイプは、CodeDeploy による ブルー/グリーンデプロイモデルを使用することにより、本稼働トラフィックを送信する前に、サービスの新しいデプロイを確認できます。  
`EXTERNAL`  
サードパーティーのデプロイコントローラーを使用して Amazon ECS サービスのデプロイプロセスを完全に制御することが必要な場合は、外部デプロイタイプを使用します。

## タスクの配置
<a name="sd-taskplacement"></a>

`placementConstraints`  
タイプ: オブジェクトの配列  
必須: いいえ  
サービスのタスクに使用する、配置制約オブジェクトの配列。タスクごとに最大 10 個の制約を指定できます。この制限数には、タスク定義内の制約と、実行時に指定される制約が含まれます。Fargate を使用している場合、タスク配置の制約事項はサポートされません。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。    
`type`  
タイプ: 文字列  
必須: いいえ  
制約のタイプ。特定のグループの各タスクが確実に別のコンテナインスタンスで実行されるようにするには、`distinctInstance` を使用します。選択対象を有効な候補グループに制約するには、`memberOf` を使用します。値 `distinctInstance` はタスク定義ではサポートされていません。  
`expression`  
タイプ: 文字列  
必須: いいえ  
制約に適用されるクラスタークエリ言語表現。制約タイプが `distinctInstance` である場合は、式を指定できません。詳細については、「[Amazon ECS タスク用のコンテナインスタンスを定義する式を作成する](cluster-query-language.md)」を参照してください。

`placementStrategy`  
タイプ: オブジェクトの配列  
必須: いいえ  
サービスのタスクで使用する配置戦略オブジェクト。サービスごとに最大 4 つの戦略ルールを指定できます。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。    
`type`  
タイプ: 文字列  
有効な値: `random` \$1 `spread` \$1 `binpack`  
必須: いいえ  
配置戦略のタイプ。`random` 配置戦略は、タスクを利用可能な候補にランダムに配置します。`spread` 配置戦略は、`field` パラメータに基づいて、利用可能候補間で均等にタスクを分散して配置します。`binpack` 戦略は、`field` パラメータで指定したリソースの利用可能量が最も少ない利用可能候補にタスクを配置します。例えば、メモリの binpack 戦略を使用する場合、タスクは残りのメモリの量は最も少ないがタスクを実行するのに十分なインスタンスに配置されます。  
`field`  
タイプ: 文字列  
必須: いいえ  
配置戦略を適用するフィールド。`spread` 配置戦略では、有効な値は `instanceId` (または同じ効果を持つ `host`)、または `attribute:ecs.availability-zone` などのコンテナインスタンスに適用される任意のプラットフォームまたはカスタム属性です。`binpack` 配置戦略では、有効な値は `cpu` および `memory` です。`random` 配置戦略では、このフィールドは使用されません。

## タグ
<a name="sd-tags"></a>

`tags`  
タイプ: オブジェクトの配列  
必須: いいえ  
サービスに適用し、サービスの分類と整理に役立つメタデータ。各タグはキーとオプションの値で構成され、どちらもお客様側が定義します。サービスが削除されると、タグも削除されます。サービスには最大 50 個のタグを適用できます。詳細については、「[Amazon ECS リソースにタグ付けする](ecs-using-tags.md)」を参照してください。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。    
`key`  
タイプ: 文字列  
長さの制限: 最小長は 1 です。最大長は 128 です。  
必須: いいえ  
タグを構成するキーと値のペアの一部。キーは、より具体的なタグ値のカテゴリのように動作する、一般的なラベルです。  
`value`  
タイプ: 文字列  
長さの制約: 最小長は 0 です。最大長は 256 です。  
必須: いいえ  
タグを構成するキーと値のペアのオプションの一部。値はタグカテゴリ (キー) の記述子として機能します。

`enableECSManagedTags`  
タイプ: ブール値  
有効な値: `true` \$1 `false`  
必須: いいえ  
サービスのタスクに Amazon ECS マネージドタグを使用するか否かを指定します。値を指定しない場合、デフォルトは `false` になります。詳細については、「[請求にタグを使用する](ecs-using-tags.md#tag-resources-for-billing)」を参照してください。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。

`propagateTags`  
タイプ: 文字列  
有効な値: `TASK_DEFINITION` \$1 `SERVICE`  
必須: いいえ  
タグをタスク定義またはサービスからサービスのタスクへコピーするかどうかを指定します。値を指定しない場合、タグはコピーされません。タグは、サービス作成中のサービス内のタスクにのみコピーすることができます。タグをサービス作成後またはタスク作成後のタスクに追加するには、`TagResource` API アクションを使用します。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。

## ネットワーク構成
<a name="sd-networkconfiguration"></a>

`networkConfiguration`  
タイプ: オブジェクト  
必須: いいえ  
サービスのネットワーク構成。このパラメータは `awsvpc` ネットワークモードを使用して独自の Elastic Network Interface を受け取るタスク定義の場合に必要です。その他のネットワークモードではサポートされていません。Fargate を使用している場合は、`awsvpc` ネットワークモードが必要です。EC2 のネットワークの詳細については、「[EC2 の Amazon ECS タスクネットワークオプション](task-networking.md)」を参照してください。Fargate のネットワークの詳細については、「[Fargate の Amazon ECS タスクのネットワークオプション](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html)」を参照してください。  
サービスを更新すると、このパラメータは新しいサービスのデプロイをトリガーします。    
`awsvpcConfiguration`  
タイプ: オブジェクト  
必須: いいえ  
タスクまたはサービスのサブネットとセキュリティグループを表すオブジェクト。    
`subnets`  
型: 文字列の配列  
必須: はい  
タスクまたはサービスに関連付けられたサブネット。`awsvpcConfiguration` に従って指定できるサブネットは 16 個に制限されています。  
`securityGroups`  
型: 文字列の配列  
必須: いいえ  
タスクまたはサービスに関連付けられたセキュリティグループ。セキュリティグループを指定しないと、VPC のデフォルトのセキュリティグループが使用されます。`awsvpcConfiguration` に基づいて指定できるセキュリティグループは 5 つに制限されています。  
`assignPublicIP`  
タイプ: 文字列  
有効な値: `ENABLED` \$1 `DISABLED`  
必須: いいえ  
タスクの Elastic Network Interface がパブリック IP アドレスを受け取るかどうかを示します。値を指定しない場合、デフォルト値の `DISABLED` が使用されます。

`healthCheckGracePeriodSeconds`  
タイプ: 整数  
必須: いいえ  
Amazon ECS サービススケジューラが、タスクが最初に開始された後で異常な Elastic Load Balancing、VPC Lattice、コンテナのヘルスチェックを無視する期間 (秒単位)。ヘルスチェックの猶予期間値を指定しない場合、デフォルト値 0 が使用されます。ヘルスチェックを使用しない場合、`healthCheckGracePeriodSeconds` は使用されません。  
サービスのタスクが開始して応答するまでに時間がかかる場合は、ヘルスチェックの猶予期間として最大 2,147,483,647 秒 (約 69 年) まで指定できます。この間は、Amazon ECS サービススケジューラはヘルスチェックのステータスを無視します。この猶予期間により、サービススケジューラがタスクを異常とマークして時間より前に停止することがなくなります。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。

`loadBalancers`  
タイプ: オブジェクトの配列  
必須: いいえ  
サービスで使用するロードバランサーを表すロードバランサーオブジェクト。Application Load Balancer または Network Load Balancer を使,用するサービスの場合、6 個以上のターゲットグループはアタッチできません。  
サービスを更新すると、このパラメータは新しいサービスのデプロイをトリガーします。  
サービスの作成後にロードバランサーの設定を AWS マネジメントコンソール から変更することはできません。AWS Copilot、AWS CloudFormation、AWS CLI、SDK のいずれかを使用して、AWS CodeDeploy ブルー/グリーンまたは外部ではなく、`ECS` ローリングデプロイコントローラのみのロードバランサー設定を変更できます。ロードバランサー設定を追加、更新、削除すると、Amazon ECS は、更新された Elastic Load Balancing 設定で新しいデプロイを開始します。これにより、タスクがロードバランサーに登録およびロードバランサーから登録解除されます。Elastic Load Balancing 設定を更新する前に、テスト環境でこれを検証することをお勧めします。設定の変更方法については、「*Amazon Elastic Containers Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」を参照してください。  
Application Load Balancer および Network Load Balancers では、このオブジェクトには、ロードバランサーターゲットグループ ARN、コンテナ名 (コンテナの定義に表示)、ロードバランサーからアクセスされるコンテナポートが含まれている必要があります。このサービスのタスクがコンテナインスタンスに配置されると、コンテナインスタンスとポートの組み合わせは、指定したターゲットグループのターゲットとして登録されます。    
`targetGroupArn`  
タイプ: 文字列  
必須: いいえ  
サービスに関連付ける Elastic Load Balancing ターゲットグループの完全な Amazon リソースネーム (ARN)。  
ターゲットグループ ARN は、Application Load Balancer または Network Load Balancer を使用する場合にのみ指定します。  
`loadBalancerName`  
タイプ: 文字列  
必須: いいえ  
サービスに関連付けるロードバランサーの名前。  
Application Load Balancer または Network Load Balancer を使用している場合は、ロードバランサーの名前パラメータを省略します。  
`containerName`  
タイプ: 文字列  
必須: いいえ  
ロードバランサーに関連付けるコンテナの名前 (コンテナ定義に表示)。  
`containerPort`  
タイプ: 整数  
必須: いいえ  
ロードバランサーに関連付けるコンテナのポート。このポートは、サービスのタスクが使用しているタスク定義の `containerPort` に対応する必要があります。EC2 を使用するタスクの場合、コンテナインスタンスは、ポートマッピングの `hostPort` でインバウンドトラフィックを許可する必要があります。

`role`  
タイプ: 文字列  
必須: いいえ  
Amazon ECS によるロードバランサーの呼び出しを許可する IAM ロールの短縮名または完全な ARN。このパラメーターは、サービスの単一のターゲットグループでロードバランサーを使用していて、タスク定義が`awsvpc`ネットワークモードを使用していない場合にのみ許可されます。`role` パラメータを指定する場合、`loadBalancers` パラメータでロードバランサーのオブジェクトも指定する必要があります。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。  
指定したロールに `/` 以外のパスがある場合は、完全なロール ARN を指定するか (推奨)、ロール名の前にパスを付ける必要があります。例えば、ロールの名前が `bar` で、パスが `/foo/` の場合、ロール名として `/foo/bar` を指定します。詳細については、*IAM ユーザーガイド*の「[わかりやすい名前とパス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names)」を参照してください。  
アカウントが既に Amazon ECS サービスリンクロールを作成している場合は、ここでロールを指定しない限り、そのロールがサービスにデフォルトで使用されます。タスク定義で awsvpc ネットワークモードを使用している場合はサービスにリンクされたロールが必要です。詳細については、「[Amazon ECS のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。

`serviceConnectConfiguration`  
タイプ: オブジェクト  
必須: いいえ  
このサービスがサービスを検出して接続し、名前空間内の他のサービスによって検出され接続されるための設定。  
サービスを更新すると、このパラメータは新しいサービスのデプロイをトリガーします。  
詳細については、「[Service Connect を使用して Amazon ECS サービスを短縮名で接続する](service-connect.md)」を参照してください。    
`enabled`  
タイプ: ブール値  
必須: はい  
このサービスで Service Connect を使用するかどうかを指定します。  
`namespace`  
タイプ: 文字列  
必須: いいえ  
Service Connect で使用する AWS Cloud Map 名前空間の短縮名または完全な Amazon リソースネーム (ARN)。名前空間は、Amazon ECS サービスおよびクラスターと同じ AWS リージョンにある必要があります。名前空間のタイプは Service Connect に影響しません。AWS Cloud Map の詳細については、「*AWS Cloud Map デベロッパーガイド*」の「[サービスの使用](https://docs.aws.amazon.com/cloud-map/latest/dg/working-with-services.html)」を参照してください。  
`services`  
タイプ: オブジェクトの配列  
必須: いいえ  
Service Connect サービスオブジェクトの配列。これらは、他の Amazon ECS サービスがこのサービスに接続するために使用する名前とエイリアスです (エンドポイントとも呼ばれます)。  
名前空間のメンバーである「クライアント」 Amazon ECS サービスが名前空間内の他のサービスに接続するだけであれば、このフィールドは必要ありません。その一例が、サービスに接続されているロードバランサーまたは他の方法で受信リクエストを受け入れるフロントエンドアプリケーションです。  
オブジェクトは、タスク定義からポートを選択し、AWS Cloud Map サービスの名前や、クライアントアプリケーションがこのサービスを参照するためのエイリアス (エンドポイントとも呼ばれます) とポートの配列を割り当てます。    
`portName`  
タイプ: 文字列  
必須: はい  
`portName` は、この Amazon ECS サービスのタスク定義内のすべてのコンテナからの、`portMappings` のいずれかの `name` と一致する必要があります。  
`discoveryName`  
タイプ: 文字列  
必須: いいえ  
`discoveryName` は、この Amazon ECS サービス用に Amazon ECS が作成する新しい AWS Cloud Map サービスの名前です。これは AWS Cloud Map 名前空間内で一意である必要があります。  
このフィールドを指定しない場合、`portName` が使用されます。  
`clientAliases`  
タイプ: オブジェクトの配列  
必須: いいえ  
このサービス接続サービスのクライアントエイリアスのリストです。これらを使用して、クライアントアプリケーションで使用できる名前を割り当てます。このリストで使用できるクライアントエイリアスの最大数は 1 です。  
各エイリアス (「エンドポイント」) は、他の Amazon ECS サービス (「クライアント」) がこのサービスに接続するために使用できる DNS 名とポート番号です。  
名前とポートの組み合わせは、名前空間内で一意である必要があります。  
これらの名前は、クライアントサービスの各タスク内で設定され、AWS Cloud Map では設定されません。これらの名前を解決するための DNS リクエストはタスクから離れることはなく、Elastic Network Interface ごとの 1 秒あたりの DNS リクエストの割り当てにもカウントされません。    
`port`  
タイプ: 整数  
必須: はい  
サービス接続プロキシのリスニングポート番号です。このポートは、同じ名前空間内のすべてのタスク内で使用できます。  
クライアント Amazon ECS サービスのアプリケーションが変更されないようにするには、クライアントアプリケーションがデフォルトで使用するのと同じポートを設定します。  
`dnsName`  
タイプ: 文字列  
必須: いいえ  
`dnsName` は、このサービスに接続するためにクライアントタスクのアプリケーションで使用する名前です。この名前は有効な DNS ラベルでなければなりません。  
このフィールドが指定されない場合、デフォルト値は `discoveryName.namespace` になります。`discoveryName` が指定されない場合、タスク定義から `portName` が使用されます。  
クライアント Amazon ECS サービスのアプリケーションが変更されないようにするには、クライアントアプリケーションがデフォルトで使用するのと同じ名前を設定します。例えば、一般的な名前として `database` や `db`、または `mysql` や `redis` などのデータベース名の小文字表記が挙げられます。  
`ingressPortOverride`  
タイプ: 整数  
必須: いいえ  
(オプション) Service Connect プロキシがリッスンするポート番号です。  
このフィールドの値を使用して、このアプリケーションのタスク定義で `portMapping` という名称で指定されているポート番号のトラフィックに対してプロキシをバイパスしてから、Amazon VPC セキュリティグループでそのポート番号を使用して、この Amazon ECS サービスのプロキシへのトラフィックを許可します。  
`awsvpc` モードでは、このアプリケーションのタスク定義で `portMapping` という名称で指定されているコンテナポート番号がデフォルト値になります。`bridge` モードでは、Service Connect プロキシの動的エフェメラルポートがデフォルト値になります。  
`logConfiguration`  
タイプ: [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) オブジェクト  
必須: いいえ  
これにより、Service Connect プロキシログの公開場所が定義されます。このログは、予期しないイベント発生時のデバッグに使用します。この設定は、この Amazon ECS サービスの各タスクの Service Connect プロキシコンテナに `logConfiguration` パラメータを設定します。タスク定義でプロキシコンテナが指定されていません。  
この Amazon ECS サービスのタスク定義のアプリケーションコンテナと同じログ設定を使用することをお勧めします。FireLens では、これはアプリケーションコンテナのログ設定です。`fluent-bit` または `fluentd ` コンテナイメージを使用するのは FireLens ログルーターコンテナではありません。  
`accessLogConfiguration`  
タイプ: [ServiceConnectAccessLogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html) オブジェクト  
必須: いいえ  
ログ形式やログにクエリ文字列を配置するかどうかなどの、Service Connect アクセスログ記録の設定。アクセスログは、リクエストパターン、レスポンスコード、タイミングデータなど、サービスに対して行われたリクエストに関する詳細情報をキャプチャします。アクセスログを有効にするには、`serviceConnectConfiguration` で `logConfiguration` も指定する必要があります。

`serviceRegistries`  
タイプ: オブジェクトの配列  
必須: いいえ  
サービスのサービス検出設定の詳細。詳細については、「[サービス検出を使用して Amazon ECS サービスを DNS 名で接続する](service-discovery.md)」を参照してください。  
サービスを更新すると、このパラメータは新しいサービスのデプロイをトリガーします。    
`registryArn`  
タイプ: 文字列  
必須: いいえ  
サービスレジストリの Amazon リソースネーム (ARN)。現在サポートされているサービスレジストリは AWS Cloud Map です。詳細については、*AWS Cloud Map デベロッパーガイド*の「[サービスの使用](https://docs.aws.amazon.com/cloud-map/latest/dg/working-with-services.html)」を参照してください。  
`port`  
タイプ: 整数  
必須: いいえ  
サービス検出サービスが SRV レコードを指定した場合に使用されるポート値。このフィールドは、`awsvpc` ネットワークモードと SRV レコードの両方が使用されている場合に必要です。  
`containerName`  
タイプ: 文字列  
必須: いいえ  
サービス検出サービスに使用されるコンテナ名の値。この値は、タスク定義で指定されます。サービスタスクが指定するタスク定義に `bridge` または `host` ネットワークモードが使用されている場合は、タスク定義からの `containerName` と `containerPort` の組み合わせを指定する必要があります。サービスタスクが指定するタスク定義に `awsvpc`ネットワークモードが使用され、SRV DNS タイプのレコードが使用されている場合は、`containerName` と `containerPort` の組み合わせを指定するか、`port` 値を指定する必要があります (両方は指定しないでください)。  
`containerPort`  
タイプ: 整数  
必須: いいえ  
サービス検出サービスに使用されるポートの値。この値は、タスク定義で指定されます。サービスタスクが指定するタスク定義に `bridge` または `host` ネットワークモードが使用されている場合は、タスク定義からの `containerName` と `containerPort` の組み合わせを指定する必要があります。サービスタスクが指定するタスク定義に `awsvpc` ネットワークモードが使用され、SRV DNS タイプのレコードが使用されている場合は、`containerName` と `containerPort` の組み合わせを指定するか、`port` 値を指定する必要があります (両方は指定しないでください)。

## クライアントトークン
<a name="sd-clienttoken"></a>

`clientToken`  
タイプ: 文字列  
必須: いいえ  
リクエストのべき等のために割り当てる一意の識別子 (大文字と小文字を区別)。最大 32 文字の ASCII 文字を使用できます。

## アベイラビリティーゾーンの再調整
<a name="sd-availability-zone-rebalancing"></a>

`availabilityZoneRebalancing`  
タイプ: 文字列  
必須: いいえ  
サービスがアベイラビリティーゾーンの再調整を使用するかどうか示します。有効な値は `ENABLED` および `DISABLED` です。  
サービスを更新しても、このパラメータは新しいサービスのデプロイをトリガーしません。  
デフォルトの動作  
+ 新しいサービスの場合: 値が指定されていない場合、デフォルトは `DISABLED` です。
+ 既存のサービスの場合: 値が指定されていない場合、Amazon ECS はデフォルトで既存の値を使用します。以前に値が設定されていない場合、Amazon ECS は値を `DISABLED` に設定します。
アベイラビリティーゾーンのリバランスの詳細については、「[アベイラビリティーゾーン間での Amazon ECS サービスの調整](service-rebalancing.md)」を参照してください。

## ボリューム設定
<a name="sd-volumeConfigurations"></a>

`volumeConfigurations`  
タイプ: オブジェクト  
必須: いいえ  
サービスによって管理されるタスク用のボリュームを作成するのに使用される設定。このオブジェクトを使用して設定できるのは、タスク定義で「`configuredAtLaunch`」とマークされているボリュームだけです。  
サービスを更新すると、このパラメータは新しいサービスのデプロイをトリガーします。  
このオブジェクトは、サービスによって管理されるタスクに Amazon EBS ボリュームをアタッチするのに必要です。詳細については、「[Amazon ECS での Amazon EBS ボリュームの使用](ebs-volumes.md)」を参照してください。    
`name`  
型: 文字列  
必須: はい  
サービスを作成または更新するときに設定されるボリュームの名前。最大 255 文字の英字 (大文字と小文字)、数字、アンダースコア (`_`)、ハイフン (`-`) が可能です。この値は、タスク定義で指定されたボリューム名と一致する必要があります。  
`managedEBSVolume`  
タイプ: オブジェクト  
必須: いいえ  
サービスの作成または更新時にそのサービスによって管理されるタスクにアタッチする Amazon EBS ボリュームを作成するためのボリューム設定。1 つのタスクごとに 1 つのボリュームがアタッチされます。    
`encrypted`  
タイプ: ブール値  
必須: いいえ  
有効な値: `true`\$1`false`  
それぞれのAmazon EBS ボリュームを暗号化するかどうかを指定します。AWS アカウント の特定の AWS リージョン に対してデフォルトで Amazon EBS 暗号化を有効にし、同時にこのパラメータを `false` に設定すると、このパラメータはオーバーライドされ、ボリュームはデフォルトで暗号化用に指定された KMS キーにより暗号化されます。デフォルトでの Amazon EBS 暗号化の詳細については、「*Amazon EBS ユーザーガイド*」の「[Amazon EBS 暗号化をデフォルトで有効にする](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html)」を参照してください。Amazon ECS タスクにアタッチされた Amazon EBS ボリュームの暗号化の詳細については、「[Amazon ECS タスクにアタッチされた Amazon EBS ボリュームに保存されているデータの暗号化](ebs-kms-encryption.md)」を参照してください。  
`kmsKeyId`  
タイプ: 文字列  
必須: いいえ  
Amazon EBS 暗号化に使用する AWS Key Management Service (AWS KMS) キーの識別子。`kmsKeyId` を指定する場合、暗号化された状態は `true` である必要があります。  
 このパラメータを使用して指定されたキーは、指定した Amazon ECS マネージドストレージ暗号化の Amazon EBS デフォルトまたはクラスターレベルの KMS キーをオーバーライドします。詳細については、「[Amazon ECS タスクにアタッチされた Amazon EBS ボリュームに保存されているデータの暗号化](ebs-kms-encryption.md)」を参照してください。  
以下のいずれかを使用して KMS キーを指定できます。  
+ **キー ID** – `1234abcd-12ab-34cd-56ef-1234567890ab` など。
+ **キーエイリアス** – `alias/ExampleAlias` など。
+ **キー ARN** – `arn:aws:kms:us-east-1:012345678910:key/1234abcd-12ab-34cd-56ef-1234567890ab` など。
+ **エイリアス ARN** – `arn:aws:kms:us-east-1:012345678910:alias/ExampleAlias` など。
AWS では、KMS キーを非同期で認証します。したがって、無効な ID、エイリアス、または ARN を指定すると、アクションは正常に行われているように見える場合がありますが、最終的には失敗します。詳細については、「[Troubleshooting Amazon EBS volume attachment issues](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshoot-ebs-volumes.html)」を参照してください。  
`volumeType`  
タイプ: 文字列  
必須: いいえ  
有効な値: `gp2`\$1`gp3`\$1`io1`\$1`io2`\$1`sc1`\$1`st1`\$1`standard`  
Amazon EBS ボリュームの種類。ボリュームタイプの詳細については、「*Amazon EBS ユーザーガイド*」の「[Amazon EBS ボリュームタイプ](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)」を参照してください。デフォルトのボリュームタイプは `gp3` です。  
`standard` ボリュームタイプは Fargate タスクではサポートされていません。  
`sizeInGiB`  
タイプ: 整数  
必須: いいえ  
有効な範囲: 1～16,384 の整数。  
EBS ボリュームのギビバイト (GiB) でのサイズ。アタッチするボリュームを設定するスナップショット ID を指定しない場合は、サイズ値を指定する必要があります。スナップショットを使用してボリュームをアタッチするように設定した場合、デフォルト値はスナップショットサイズです。スナップショットサイズ以上のサイズを指定できます。  
`gp2` および `gp3` ボリュームタイプでは、有効範囲は 1～16,384 です。  
`io1` および `io2` ボリュームタイプでは、有効範囲は 4～16,384 です。  
`st1` および `sc1` ボリュームタイプでは、有効範囲は 125～16,384 です。  
`standard` ボリュームタイプでは、有効範囲は 1～1,024 です。  
`snapshotId`  
タイプ: 文字列  
必須: いいえ  
Amazon ECS がアタッチメント用の新しいボリュームの作成に使用する既存の Amazon EBS ボリュームのスナップショットの ID。`snapshotId` または `sizeInGiB` のどちらかを指定する必要があります。  
`volumeInitializationRate`  
タイプ: 整数  
必須: いいえ  
既存の Amazon EBS ボリュームのスナップショットからデータを取得してアタッチメント用の新しいボリュームを作成する際の MiB/秒単位のデータ読込みレート。このプロパティは、`snapshotId` を指定する場合にのみ指定できます。サポートされている初期化レートの範囲など、このボリューム初期化レートの詳細については、「*Amazon EBS ユーザーガイド*」の「[Amazon EBS ボリュームの初期化](https://docs.aws.amazon.com/ebs/latest/userguide/initalize-volume.html)」を参照してください。  
`iops`  
タイプ: 整数  
必須: いいえ  
1 秒あたりの I/O 操作の数 (IOPS)。`gp3`、`io1`、`io2` ボリュームの場合、これはボリュームでプロビジョニングされている IOPS の数を表します。`gp2` ボリュームの場合、この値はボリュームのベースラインパフォーマンスと、バースト用の I/O クレジットがこのボリュームに蓄積されるレートを表します。このパラメータは、`io1` と `io2` のボリュームに必須です。このパラメータは、`gp2`、`st1`、`sc1`、`standard` ボリュームではサポートされていません。  
`gp3` ボリュームでは、値の有効範囲は 3,000～16,000 です。  
`io1` ボリュームでは、値の有効範囲は 100～64,000 です。  
`io2` ボリュームでは、値の有効範囲は 100～64,000 です。  
`throughput`  
タイプ: 整数  
必須: いいえ  
サービスで維持されるタスクにアタッチされたボリュームにプロビジョニングするためのスループット。  
このパラメータは、`gp3` ボリュームのみでサポートされています。  
`roleArn`  
タイプ: 文字列  
必須: はい  
タスク用の Amazon EBS リソースを管理するための Amazon ECS アクセス許可を提供するインフラストラクチャ AWS Identity and Access Management (IAM) ロールの Amazon リソース ARN (ARN)。詳細については、「[Amazon ECS インフラストラクチャ IAM ロール](infrastructure_IAM_role.md)」を参照してください。  
`tagSpecifications`  
タイプ: オブジェクト  
必須: いいえ  
各 Amazon EBS ボリュームに適用されるタグの指定。    
`resourceType`  
タイプ: 文字列  
必須: はい  
有効な値: `volume`  
作成時にタグ付けするリソースのタイプ。  
`tags`  
タイプ: オブジェクトの配列  
必須: いいえ  
分類と整理に役立つようにボリュームに適用するメタデータ。タグはそれぞれ、1 つのキーとオプションの 1 つの値で構成されており、どちらもユーザーが定義します。`AmazonECSCreated` と `AmazonECSManaged` は Amazon ECS がユーザーに代わって追加する予約済みのタグなので、独自のタグを最大 48 個指定できます。ボリュームが削除されると、タグも削除されます。詳細については、「[Amazon ECS リソースにタグ付けする](ecs-using-tags.md)」を参照してください。    
`key`  
タイプ: 文字列  
長さの制限: 最小長は 1 です。最大長は 128 です。  
必須: いいえ  
タグを構成するキーと値のペアの一部。キーは、より具体的なタグ値のカテゴリのように動作する、一般的なラベルです。  
`value`  
タイプ: 文字列  
長さの制約: 最小長は 0 です。最大長は 256 です。  
必須: いいえ  
タグを構成するキーと値のペアのオプションの一部。値はタグカテゴリ (キー) の記述子として機能します。  
`propagateTags`  
タイプ: 文字列  
有効な値: `TASK_DEFINITION` \$1 `SERVICE` \$1 `NONE`  
必須: いいえ  
タグをタスク定義またはサービスからボリュームにコピーするかどうかを指定します。`NONE` を指定した場合、または値を指定しない場合、タグはコピーされません。  
`fileSystemType`  
タイプ: 文字列  
必須: いいえ  
有効な値: `xfs`\$1`ext3`\$1`ext4`\$1`NTFS`  
ボリューム上のファイルシステムのタイプ。ボリュームのファイルシステムタイプによって、ボリューム内でのデータの格納方法と取得方法が決まります。スナップショットから作成されたボリュームでは、スナップショットの作成時にボリュームが使用していたのと同じファイルシステムタイプを指定する必要があります。ファイルシステムのタイプが一致しない場合、タスクは開始できません。  
Linux の有効な値は `xfs`、ext3`, and ext4` です。Linux タスクにアタッチされているボリュームのデフォルトは `XFS` です。  
Windows の有効な値は `NTFS` です。TWindows タスクにアタッチされるボリュームのデフォルトは `NTFS` です。

# サービス定義テンプレート
<a name="sd-template"></a>

以下に、Amazon ECS サービス定義の JSON 表現を示します。

EC2

```
{
    "cluster": "", 
    "serviceName": "", 
    "taskDefinition": "", 
    "loadBalancers": [
        {
            "targetGroupArn": "", 
            "loadBalancerName": "", 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "serviceRegistries": [
        {
            "registryArn": "", 
            "port": 0, 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "desiredCount": 0, 
    "clientToken": "", 
    "launchType": "EC2", 
    "capacityProviderStrategy": [
        {
            "capacityProvider": "", 
            "weight": 0, 
            "base": 0
        }
    ], 
    "platformVersion": "", 
    "role": "", 
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true, 
            "rollback": true
        }, 
        "maximumPercent": 0, 
        "minimumHealthyPercent": 0, 
        "alarms": {
            "alarmNames": [
                ""
            ], 
            "enable": true, 
            "rollback": true
        }
    }, 
    "placementConstraints": [
        {
            "type": "distinctInstance", 
            "expression": ""
        }
    ], 
    "placementStrategy": [
        {
            "type": "binpack", 
            "field": ""
        }
    ], 
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "subnets": [
                ""
            ], 
            "securityGroups": [
                ""
            ], 
            "assignPublicIp": "DISABLED"
        }
    }, 
    "healthCheckGracePeriodSeconds": 0, 
    "schedulingStrategy": "REPLICA", 
    "deploymentController": {
        "type": "EXTERNAL"
    }, 
    "tags": [
        {
            "key": "", 
            "value": ""
        }
    ], 
    "enableECSManagedTags": true, 
    "propagateTags": "TASK_DEFINITION", 
    "enableExecuteCommand": true, 
    "availabilityZoneRebalancing": "ENABLED",
    "serviceConnectConfiguration": {
        "enabled": true, 
        "namespace": "", 
        "services": [
            {
                "portName": "", 
                "discoveryName": "", 
                "clientAliases": [
                    {
                        "port": 0, 
                        "dnsName": ""
                    }
                ], 
                "ingressPortOverride": 0
            }
        ], 
        "logConfiguration": {
            "logDriver": "journald", 
            "options": {
                "KeyName": ""
            }, 
            "secretOptions": [
                {
                    "name": "", 
                    "valueFrom": ""
                }
            ]
        }
    }, 
    "volumeConfigurations": [
        {
            "name": "", 
            "managedEBSVolume": {
                "encrypted": true, 
                "kmsKeyId": "", 
                "volumeType": "", 
                "sizeInGiB": 0, 
                "snapshotId": "", 
                "volumeInitializationRate": 0,
                "iops": 0, 
                "throughput": 0, 
                "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "", 
                                "value": ""
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ], 
                "roleArn": "", 
                "filesystemType": ""
            }
        }
    ]
}
```

Fargate

```
{
    "cluster": "", 
    "serviceName": "", 
    "taskDefinition": "", 
    "loadBalancers": [
        {
            "targetGroupArn": "", 
            "loadBalancerName": "", 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "serviceRegistries": [
        {
            "registryArn": "", 
            "port": 0, 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "desiredCount": 0, 
    "clientToken": "", 
    "launchType": "FARGATE", 
    "capacityProviderStrategy": [
        {
            "capacityProvider": "", 
            "weight": 0, 
            "base": 0
        }
    ], 
    "platformVersion": "", 
    "platformFamily": "",
    "role": "", 
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true, 
            "rollback": true
        }, 
        "maximumPercent": 0, 
        "minimumHealthyPercent": 0, 
        "alarms": {
            "alarmNames": [
                ""
            ], 
            "enable": true, 
            "rollback": true
        }
    }, 
    "placementStrategy": [
        {
            "type": "binpack", 
            "field": ""
        }
    ], 
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "subnets": [
                ""
            ], 
            "securityGroups": [
                ""
            ], 
            "assignPublicIp": "DISABLED"
        }
    }, 
    "healthCheckGracePeriodSeconds": 0, 
    "schedulingStrategy": "REPLICA", 
    "deploymentController": {
        "type": "EXTERNAL"
    }, 
    "tags": [
        {
            "key": "", 
            "value": ""
        }
    ], 
    "enableECSManagedTags": true, 
    "propagateTags": "TASK_DEFINITION", 
    "enableExecuteCommand": true, 
    "availabilityZoneRebalancing": "ENABLED",
    "serviceConnectConfiguration": {
        "enabled": true, 
        "namespace": "", 
        "services": [
            {
                "portName": "", 
                "discoveryName": "", 
                "clientAliases": [
                    {
                        "port": 0, 
                        "dnsName": ""
                    }
                ], 
                "ingressPortOverride": 0   
            }
        ], 
        "logConfiguration": {
            "logDriver": "journald", 
            "options": {
                "KeyName": ""
            }, 
            "secretOptions": [
                {
                    "name": "", 
                    "valueFrom": ""
                }
            ]
        }
    }, 
    "volumeConfigurations": [
        {
            "name": "", 
            "managedEBSVolume": {
                "encrypted": true, 
                "kmsKeyId": "", 
                "volumeType": "", 
                "sizeInGiB": 0, 
                "snapshotId": "", 
                "volumeInitializationRate": 0, 
                "iops": 0, 
                "throughput": 0, 
                "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "", 
                                "value": ""
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ], 
                "roleArn": "", 
                "filesystemType": ""
            }
        }
    ]
}
```

このサービス定義テンプレートは、次の AWS CLI コマンドを使用して作成できます。

```
aws ecs create-service --generate-cli-skeleton
```