# Amazon ECS 배포 실패 감지
Amazon ECS는 배포 실패를 감지하는 두 가지 방법을 제공합니다.
+ 배포 회로 차단기
+ CloudWatch 경보
두 방법 모두 실패한 배포를 마지막으로 알려진 정상 상태로 자동으로 롤백하도록 구성할 수 있습니다.
다음을 고려하세요.
+ 두 방법 모두 롤링 업데이트 배포 및 블루/그린 배포 유형만 지원합니다.
+ 두 방법을 모두 사용하면 둘 중 하나가 배포 실패를 트리거할 수 있습니다.
+ 롤백 메서드에는 완료 상태의 이전 배포가 필요합니다.
+ 배포 상태 변경 시 EventBridge 이벤트가 생성됩니다.
# Amazon ECS 배포 회로 차단기가 장애를 감지하는 방법
배포 회로 차단기는 작업이 안정 상태에 도달하는지 확인하는 롤링 업데이트 메커니즘입니다. 배포 회로 차단기에는 실패한 배포를 `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단계 - 스케줄러는 작업을 모니터링하여 작업이 실행 중 상태로 전환되는지 확인합니다.
+ 성공 - 실행 중 상태로 전환된 작업이 두 개 이상 있기 때문에 배포가 완료됨 상태로 전환될 가능성이 있습니다. 실패 기준을 건너뛰고 회로 차단기는 2단계로 진행합니다.
+ 실패 - 실행 중 상태로 전환되지 않은 작업이 연속적으로 발생하고 배포가 실패 상태로 전환될 수 있습니다.
+ 2단계 - 실행 중 상태인 작업이 하나 이상 있을 때 배포가 이 단계로 설정됩니다. 회로 차단기는 평가 중인 현재 배포의 작업에 대해 상태 확인을 확인합니다. 검증된 상태 확인은 Elastic Load Balancing, AWS Cloud Map 서비스 상태 확인, 컨테이너 상태 확인입니다.
+ 성공 - 실행 중인 작업 중 상태 확인에 통과된 작업이 하나 이상 있습니다.
+ 실패 - 상태 확인 실패로 인해 교체된 작업이 실패 임계값에 도달했습니다.
서비스에 배포 회로 차단기를 사용할 때 다음 사항을 고려해야 합니다. EventBridge에서 규칙을 생성합니다.
+ `DescribeServices` 응답은 배포 상태인 `rolloutState` 및 `rolloutStateReason`에 대한 인사이트를 제공합니다. 새 배포가 시작되면 롤아웃 상태는 `IN_PROGRESS` 상태에서 시작됩니다. 서비스가 정상 상태에 도달하면 롤아웃 상태가 `COMPLETED`로 전환됩니다. 서비스가 안정 상태에 도달하지 못하고 회로 차단기가 켜지면 배포가 `FAILED` 상태로 전환됩니다. `FAILED` 상태의 배포는 새로운 작업을 시작하지 않습니다.
+ Amazon ECS는 시작되고 완료된 배포에 대해 서비스 배포 상태 변경 이벤트를 전송하는 것 외에도 회로 차단기가 켜진 배포가 실패할 경우 이벤트를 전송합니다. 이러한 이벤트는 배포가 실패한 이유 또는 롤백으로 인해 배포가 시작된 경우에 대한 세부 정보를 제공합니다. 자세한 내용은 [Amazon ECS 서비스 배포 상태 변경 이벤트](ecs_service_deployment_events.md) 섹션을 참조하세요.
+ 이전 배포가 실패하고 롤백이 시작되었기 때문에 새 배포가 시작된 경우 서비스 배포의 `reason` 필드에 롤백으로 인해 배포가 시작되었음이 표시됩니다.
+ 배포 회로 차단기는 롤링 업데이트(`ECS`) 배포 컨트롤러를 사용하는 Amazon ECS 서비스에만 지원됩니다.
+ Amazon ECS 콘솔 또는 AWS CLI(CloudWatch 옵션과 함께 배포 회로 차단기를 사용할 때)를 사용해야 합니다. 자세한 내용은 *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은 롤백하거나 작업을 시작할 수 없습니다.
## 실패 임계값
배포 회로 차단기는 임계값을 계산한 다음 이 값을 사용하여 배포를 `FAILED` 상태로 이동할 시기를 결정합니다.
배포 회로 차단기의 최소 임계값은 3이고 최대 임계값은 200이며 다음 공식의 값을 사용하여 배포 실패를 확인합니다.
```
Minimum threshold <= 0.5 * desired task count => maximum threshold
```
계산 결과가 최솟값 3보다 크지만 최댓값인 200보다 작으면 실패 임계값은 계산된 임계값(반올림)으로 설정됩니다.
**참고**
임계값은 변경할 수 없습니다.
배포 상태 검사에는 두 단계가 있습니다.
1. 배포 회로 차단기는 배포의 일부인 태스크를 모니터링하고 `RUNNING` 상태의 태스크를 확인합니다. 스케줄러는 현재 배포된 태스크가 `RUNNING` 상태일 때 실패 기준을 무시하고 다음 단계로 진행합니다. 태스크가 `RUNNING` 상태에 도달하지 못하면 배포 회로 차단기가 실패 횟수를 하나씩 늘립니다. 실패 횟수가 임계값과 같으면 배포가 `FAILED`로 표시됩니다.
1. `RUNNING` 상태의 작업이 하나 이상 있을 때 이 단계가 시작됩니다. 배포 회로 차단기는 현재 배포의 태스크에 대해 다음 리소스를 대상으로 상태 확인을 수행합니다.
+ Elastic Load Balancing 로드 밸런서
+ AWS Cloud Map 서비스
+ Amazon ECS 컨테이너 상태 확인
태스크에 대한 상태 확인이 실패하면 배포 회로 차단기가 실패 횟수를 하나씩 늘립니다. 실패 횟수가 임계값과 같으면 배포가 `FAILED`로 표시됩니다.
다음 표에 몇 가지 예가 나와 있습니다.
| 원하는 작업 개수 | 계산 | 임계값 |
| --- | --- | --- |
| 1 | 3 <= 0.5 * 1 => 200
| 3(계산된 값이 최솟값보다 작음) |
| 25 | 3 <= 0.5 * 25 => 200
| 13(값이 반올림됨) |
| 400 | 3 <= 0.5 * 400 => 200
| 200 |
| 800 | 3 <= 0.5 * 800 => 200
| 200(계산된 값이 최댓값보다 큼) |
예를 들어, 임계값이 3인 경우 회로 차단기는 실패 횟수가 0으로 설정된 상태에서 시작됩니다. 작업이 `RUNNING` 상태에 도달하지 못하면 배포 회로 차단기가 실패 횟수를 하나씩 늘립니다. 실패 횟수가 3과 같아지면 배포가 `FAILED`로 표시됩니다.
롤백 옵션을 사용하는 방법에 대한 추가 예제는 [Amazon ECS 배포 회로 차단기 발표](https://aws.amazon.com/blogs/containers/announcing-amazon-ecs-deployment-circuit-breaker/)를 참조하세요.
# 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 서비스 할당량에 포함됩니다. `DescribeAlarms`를 호출하는 다른 AWS 서비스가 있는 경우 Amazon ECS에서 경보를 폴링하는 데 영향을 받을 수 있습니다. 예를 들어 다른 서비스가 할당량에 도달할 만큼 충분히 `DescribeAlarms`를 직접 호출하면 해당 서비스는 제한이 발생하고 Amazon ECS 역시 제한이 발생하여 경보를 폴링할 수 없습니다. 제한 기간에 경보가 생성되면 Amazon ECS에서 경보를 놓치고 롤백이 발생하지 않을 수 있습니다. 배포에 다른 영향을 미치지 않습니다. CloudWatch 서비스 할당량에 대한 자세한 내용은 *CloudWatch 사용 설명서*의 [CloudWatch 서비스 할당량](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 기본값을 원하는 경우 베이크 소요 시간을 수동으로 설정해야 합니다.