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 はデプロイに関連するアラームを監視し続けます。Amazon ECS は、デプロイに関連するアラーム設定に基づいてこの期間を計算します。
deploymentConfiguration リクエストパラメータには alarms のデータ型が含まれるようになっています。アラーム名、メソッド使用の有無、アラームがデプロイの失敗を示したときのロールバック開始の有無について指定できます。詳細については、「Amazon Elastic Container Service API リファレンス」の「CreateService」を参照してください。
この DescribeServices レスポンスは、デプロイの状態、rolloutState および rolloutStateReason についての洞察を提供します。新しいデプロイが開始されると、ロールアウトの状態は IN_PROGRESS 状態から始まります。サービスが定常状態になりベイク時間が完了すると、ロールアウトの状態は COMPLETED に移行します。サービスが定常状態にならず、アラームが ALARM 状態になった場合、デプロイは FAILED 状態に移行します。FAILED 状態のデプロイでは、新しいタスクは起動されません。
開始および完了したデプロイに対して Amazon ECS から送信されるサービスデプロイの状態変更イベントに加えて、Amazon ECS はアラームを使用するデプロイが失敗した場合にもイベントを送信します。これらのイベントは、デプロイが失敗した理由やロールバックのためにデプロイが開始されたかどうかについての詳細情報を提供します。詳細については、「Amazon ECS サービスデプロイ状態変更イベント」を参照してください。
以前のデプロイが失敗し、ロールバックがオンになったために新しいデプロイが開始された場合、サービスデプロイ状態変更イベントの reason フィールドには、ロールバックのためにデプロイが開始されたことが示されます。
障害検出にデプロイサーキットブレーカーと Amazon CloudWatch アラームを使用する場合、どちらかのメソッドの基準が満たされ次第、どちらかがデプロイの失敗を開始します。デプロイの失敗を開始したメソッドでロールバックオプションが使用されている場合は、ロールバックが発生します。
Amazon CloudWatch アラームは、ローリング更新 (ECS) デプロイコントローラーを使用する Amazon ECS サービスでのみサポートされています。
このオプションは、Amazon ECS コンソールまたは AWS CLI を使用して設定できます。詳細については、「AWS Command Line Interface リファレンス」の「定義済みのパラメータを使用したサービスの作成」および「create-service」を参照してください。
デプロイステータスが長時間 IN_PROGRESS のままになっていると気付くことがあるかもしれません。これは、アクティブなデプロイを削除し終えるまで Amazon ECS のステータスは変化せず、また、ベイク時間が過ぎるまでは、このステータスが変更されることがないためです。アラームの設定によっては、デプロイにアラームを使用しない場合よりも数分長くかかるように思える場合もあります (新しいプライマリタスクセットがスケールアップされ、古いデプロイがスケールダウンされる場合であってもです)。CloudFormation タイムアウトを使用する場合は、タイムアウトを増やすことを検討してください。詳細については、「AWS CloudFormation ユーザーガイド」の「テンプレートでの待機条件の作成」を参照してください。
Amazon ECS は DescribeAlarms を呼び出してアラームをポーリングします。DescribeAlarms の呼び出しはアカウントに関連付けられた CloudWatch の Service Quotas にカウントされます。DescribeAlarms を呼び出す AWS サービスが他にもある場合は、アラームをポーリングする際に Amazon ECS に影響が及ぶ可能性があります。例えば、別のサービスがクォータに達するだけの DescribeAlarms 呼び出しを行うと、そのサービスがスロットリングされると共に Amazon ECS もスロットリングされ、アラームをポーリングできなくなります。スロットリング期間中にアラームが生成されると、Amazon ECS はアラームを見逃してロールバックが行われない可能性があります。デプロイに他の影響はありません。CloudWatch の Service Quotas の詳細については、「CloudWatch ユーザーガイド」の「CloudWatch Service Quotas」を参照してください。
デプロイの開始時にアラームの状態が 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 メトリクス」を参照してください。
既存のアプリケーションがある場合は、CPUUtilization および MemoryUtilization のメトリクスを使用します。これらのメトリクスは、クラスターまたはサービスが使用する CPU とメモリの割合をチェックします。詳細については、「考慮事項」を参照してください。
タスクで Amazon Simple Queue Service キューを使用する場合は、ApproximateNumberOfMessagesNotVisible Amazon SQS メトリクスを使用します。このメトリクスは、遅延の発生によりすぐに読み取ることのできない、キュー内のメッセージ数をチェックします。Amazon SQS メトリクスの詳細については、「Amazon Simple Queue Service デベロッパーガイド」の「Amazon SQS で使用できる CloudWatch メトリクス」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

デプロイサーキットブレーカーが障害を検出する方法

サービスパラメータのベストプラクティス