AWS re:Post Knowledge Center Feedback Survey

Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.

Amazon ECS 서비스가 안정적이지 않은 이유는 무엇입니까?

4분 분량

Amazon Elastic Container Service (Amazon ECS) 서비스가 주기적으로 재시작됩니다. Amazon ECS 서비스가 안정적으로 실행되었으면 합니다.

간략한 설명

다음 이유 중 하나로 인해 Amazon ECS 서비스가 안정적이지 않을 수 있습니다.

컨테이너 상태 확인 실패.
Elastic Load Balancing(ELB) 상태 확인 실패.
Amazon ECS 작업이 0이 아닌 종료 코드로 종료됩니다.
컨테이너 인스턴스가 Amazon ECS 작업 요구 사항을 충족하지 않습니다.
컨테이너 인스턴스가 예기치 않게 종료됩니다.
서비스의 Amazon ECS 작업을 시작할 수 없습니다.

해결 방법

Amazon ECS 콘솔에서 Amazon ECS 이벤트를 사용하여 서비스가 안정적이지 않은 이유를 확인할 수 있습니다.

컨테이너 상태 확인 실패

애플리케이션을 Amazon ECS에 배포하기 전에 상태 확인을 사용하여 컨테이너가 예상대로 작동하는지 확인하십시오. Amazon ECS 서비스가 갑자기 컨테이너 상태 확인에 실패한 경우 애플리케이션 로그를 확인하십시오. 애플리케이션에서 awslogs 드라이버를 사용하는 경우 Amazon CloudWatch에서 로그를 확인하십시오.

참고: 컨테이너 정의에 지정한 상태 확인 파라미터는 컨테이너 이미지에 있는 Docker 상태 확인을 재정의합니다.

ELB 상태 확인 실패

로드 밸런서는 정기적으로 각 서버에서 컨테이너 상태 확인을 실행하여 트래픽을 전달하기에 안전한 서버를 확인합니다. ELB 상태 확인으로 인해 Amazon ECS 서비스가 실패하는 경우 로드 밸런서와 서비스 간에 통신 문제가 있을 수 있습니다.

로드 밸런서와 Amazon ECS 서비스를 올바르게 구성했는지 확인하려면 다음 작업을 수행하십시오.

컨테이너 보안 그룹이 로드 밸런서의 트래픽을 허용하는지 확인합니다.
컨테이너 내에서 다음 명령을 실행하여 애플리케이션이 올바른 포트를 수신하는지 확인합니다.
```
netstat -tulpn | grep LISTEN
```
상태 확인 경로가 올바른지 확인합니다.
애플리케이션 로그에서 오류를 확인합니다.
Amazon Elastic Compute Cloud(Amazon EC2) 내에서 curl 명령을 실행하여 상태 확인 경로를 확인합니다. 또는 AWS Fargate에서 ECS Exec을 활성화하고 컨테이너 내에서 curl 명령을 실행하여 상태 확인에 대한 응답 코드를 확인합니다.
CPU 사용률이 높으면 애플리케이션이 응답하지 않고 ELB 상태 확인에 실패할 수 있으므로 서비스의 CPU 및 메모리 지표를 모니터링하십시오.
최소 상태 확인 유예 기간을 애플리케이션이 활성 상태에 도달하는 데 걸리는 시간보다 1.5~2.0배 더 길게 설정합니다.

0이 아닌 종료 코드로 Amazon ECS 작업이 종료됨

컨테이너에 문제가 있는 경우 서비스 내 Amazon ECS 작업이 0이 아닌 종료 코드로 종료됩니다. 모든 작업에는 필수 컨테이너가 하나 이상 있어야 합니다. 필수 컨테이너가 어떤 이유로든 종료되면 전체 작업이 실패하고 Amazon ECS 서비스가 불안정해집니다.

Amazon ECS 작업이 실패할 수 있는 이유는 다음 종료 코드와 같습니다.

애플리케이션 오류가 발생하면 종료 코드 1이 표시됩니다. 오류에 대한 자세한 내용은 애플리케이션 로그를 참조하십시오.
컨테이너의 작업이 강제 종료(SIGKILL)되거나 메모리 부족(OOM) 오류가 발생하면 종료 코드 137이 표시됩니다. OOM 문제가 발생했는지 확인하려면 CloudWatch 지표를 검토하십시오.
세분화 오류가 발생하면 종료 코드 139가 표시됩니다. 이는 일반적으로 애플리케이션이 사용할 수 없는 메모리에 액세스하려고 하거나, 설정되지 않았거나 유효하지 않은 환경 변수가 있을 때 발생합니다.
오류로 인해 컨테이너의 ENTRYPOINT CMD 명령이 실패했을 때 종료 코드 255가 발생합니다. 원인이 이것인지 확인하려면 CloudWatch 지표를 검토하십시오.

참고: DescribeTasks API를 사용하여 중지된 작업의 세부 정보를 볼 수 있습니다. 하지만 중지된 작업의 세부 정보는 결과에 1시간 동안만 표시됩니다.

컨테이너 인스턴스가 Amazon ECS 작업 요구 사항을 충족하지 않음

컨테이너 요구 사항을 해결하는 방법에 대한 자세한 내용은 Amazon ECS에서 “no container instance met all of its requirements” 오류를 해결하려면 어떻게 해야 합니까?를 참조하십시오.

컨테이너 인스턴스가 예기치 않게 종료됨

관리형 종료 없이 Amazon ECS 클러스터에서 용량 공급자를 사용하는 경우, 용량 공급자가 작업을 실행 중인 인스턴스를 종료할 수 있습니다. 이는 스케일 인 작업이 진행 중이고, AWS ECS 서비스가 불안정해질 때 발생합니다. 용량 공급자가 작업이 실행 중인 컨테이너 인스턴스를 종료하지 않도록 관리형 종료 보호를 활성화하십시오.

관리형 종료 보호를 활성화하려면 Auto Scaling 그룹에 대한 인스턴스 스케일 인 보호를 설정해야 합니다.

스케일 인 보호를 설정하려면 다음 단계를 완료하십시오.

Amazon EC2 콘솔을 엽니다.
탐색 창에서 Auto Scaling 그룹을 선택한 다음 Auto Scaling 그룹을 선택합니다.
세부 정보 탭의 고급 구성에서 편집을 선택합니다.
인스턴스 스케일 인 보호에서 인스턴스 스케일 인 보호 활성화를 선택합니다.
업데이트를 선택합니다.

관리형 종료 보호를 활성화하려면 다음 단계를 완료하십시오.

Amazon ECS 콘솔을 엽니다.
탐색 창에서 클러스터를 선택합니다.
클러스터 페이지에서 클러스터를 선택합니다.
클러스터: 이름 페이지에서 인프라를 선택한 다음 업데이트를 선택합니다.
용량 제공자 생성 페이지의 Auto Scaling 그룹에 있는 스케일링 정책에서 다음 옵션을 구성합니다.
관리형 스케일링 설정을 선택합니다.
스케일링 보호 설정을 선택합니다.
업데이트를 선택합니다.

참고: 사용하는 다른 도구가 Auto Scaling 그룹에서 AmazonECSManaged 태그를 제거하지 않도록 하십시오. 도구가 태그를 제거하면 Amazon ECS에서 스케일링을 관리할 수 없습니다.

서비스 내에서 Amazon ECS 작업 시작 실패

서비스를 생성 또는 업데이트할 때 Amazon ECS 작업에서 이미지를 가져올 수 없기 때문에 서비스가 안정적이지 않을 수 있습니다.

이 문제를 해결하려면 다음 AWS Knowledge Service 문서를 참조하십시오.