# CloudWatch アラームが Amazon ECS のデプロイ障害を検出する方法
指定された 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 はアラーム設定を無視します)。この動作により、初期デプロイの失敗を修正するために、新たなデプロイを開始する場合に対応しています。
## 推奨アラーム
次のアラームメトリクスを使用することをお勧めします。
+ 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)」を参照してください。
## ベイク時間
サービスのデプロイにロールバックオプションを使用すると、Amazon ECS はターゲットサービスリビジョンがデプロイされてから CloudWatch アラームを送信するまでの間さらに待機します。これはベイク時間と呼ばれます。この時間は、次のイベントの後に開始されます。
+ ターゲットサービスリビジョンのすべてのタスクが実行中で、正常な状態である
+ ソースサービスリビジョンは 0% にスケールダウンされている
デフォルトのベイク時間は 5 分未満です。サービスデプロイは、ベイク時間が経過すると完了としてマークされます。
ローリングデプロイのベイク時間を設定できます。CloudWatch アラームを使用して障害を検出し、ベイク時間を変更してから Amazon ECS のデフォルトを設定する場合は、ベイク時間を手動で設定する必要があります。