Amazon ECS 작업이 PENDING 상태에서 멈추는 이유는 무엇입니까?

간략한 설명

다음 시나리오에서는 Amazon ECS 작업이 PENDING 상태로 중단됩니다.

• Docker 대몬이 응답하지 않습니다.
• 클러스터에 리소스 제약이 있습니다.
• Docker 이미지가 큽니다.
• Amazon ECS 컨테이너 에이전트가 작업 시작 도중에 Amazon ECS 서비스와의 연결이 끊어졌습니다.
• Amazon ECS 컨테이너 에이전트가 기존 작업을 중지하는 데 시간이 오래 걸립니다.
• Amazon Virtual Private Cloud(Amazon VPC) 라우팅을 올바르게 구성하지 않았습니다.
• 필수 컨테이너가 HEALTHY 상태가 아닌 비필수 컨테이너에 의존합니다.
• Amazon ECS 작업과 연결된 AWS Identity and Access Management(IAM) 역할이 누락되었거나 올바르지 않습니다.
• 선택한 Windows 버전과 이미지 호환 문제가 있습니다.

해결 방법

참고: AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하면 AWS CLI의 오류 해결을 참조하십시오. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.

Docker 대몬이 응답하지 않거나 클러스터에 리소스 제약이 있음

작업 정의에서 작업이 인스턴스가 지원할 수 있는 용량보다 많은 메모리 또는 CPU를 요청하는지 확인합니다. 필요에 따라 컨테이너 인스턴스 리소스를 조정합니다.

CPU 문제의 경우 다음 단계를 완료합니다.

1. Amazon CloudWatch 지표를 사용하여 컨테이너 인스턴스가 최대 CPU 할당량을 초과했는지 여부를 확인합니다.
2. 필요한 경우 컨테이너 인스턴스의 크기를 늘립니다.

메모리 문제의 경우 다음 단계를 완료합니다.

1. free 명령을 실행하여 시스템에서 사용할 수 있는 메모리 용량을 확인합니다.
2. 필요한 경우 컨테이너 인스턴스의 크기를 늘립니다.

I/O 문제의 경우 다음 단계를 완료합니다.

1. iotop 명령을 실행합니다.
2. 초당 입출력 작업량(IOPS)을 가장 많이 사용하는 각 서비스의 작업을 식별합니다.
3. 작업 배치 제약 조건 및 전략을 사용하여 작업을 각기 다른 컨테이너 인스턴스에 분산합니다.
   또는
   CloudWatch를 사용하여 Amazon Elastic Block Store (Amazon EBS) 버스트 밸런스 지표에 경보를 생성합니다. 그런 다음 AWS Lambda 함수 또는 자체 사용자 지정 로직을 사용하여 작업의 균형을 맞춥니다.

Docker 이미지가 큼

이미지가 클수록 다운로드 시간이 더 오래 걸리고 작업이 PENDING 상태인 시간이 증가합니다.

전환 시간을 단축하려면 이미지 캐싱을 사용하도록 ECS_IMAGE_PULL_BEHAVIOR 파라미터를 조정합니다. 예를 들어, /etc/ecs/ecs.config에서ECS_IMAGE_PULL_BEHAVIOR 파라미터를 prefer-cached로 설정합니다. prefer-cached를 사용하는 경우 캐시된 이미지가 없을 때 Amazon ECS가 원격으로 이미지를 가져옵니다. 그렇지 않은 경우 Amazon ECS는 인스턴스의 캐시된 이미지를 사용합니다.

Amazon ECS 컨테이너 에이전트가 실행 도중에 Amazon ECS 서비스와의 연결이 끊어짐

Amazon ECS 컨테이너 에이전트의 상태 및 연결을 확인하려면 Amazon Linux 버전을 기반으로 컨테이너 인스턴스에서 다음 명령을 실행합니다.

Amazon Linux 1:

sudo status ecs
sudo docker ps -f name=ecs-agent

Amazon Linux 2:

sudo systemctl status ecs
sudo docker ps -f name=ecs-agent

출력 상태가 inactive인 경우 에이전트의 연결이 끊어집니다. 이 문제를 해결하려면 다음 명령을 실행하여 컨테이너 에이전트를 다시 시작합니다.

Amazon Linux 1:

sudo stop ecs
sudo start ecs

Amazon Linux 2:

sudo systemctl stop ecs
sudo systemctl start ecs

다음 예시와 유사한 출력이 표시됩니다.

ecs start/running, process abcd

에이전트 연결을 확인하려면, 해당 기간 동안 다음 로그에서 오류, 경고 또는 에이전트 전환 상태와 같은 키워드를 확인하십시오.

• /var/log/ecs/ecs-agent.log.yyyy-mm-dd-hh에서 Amazon ECS 컨테이너 에이전트 로그를 확인하십시오.
• /var/log/ecs/ecs-init.log에서 Amazon ECS init 로그를 확인하십시오.
• /var/log/docker에서 Docker 로그를 확인하십시오.

로그의 정보를 사용하여 연결 문제의 근본 원인을 식별합니다.

참고: 또한 Amazon ECS 로그 수집기를 사용하여 Amazon ECS의 일반 운영 체제(OS) 로그, Docker 로그 및 컨테이너 에이전트 로그를 수집할 수 있습니다.

컨테이너 인스턴스에서 로컬 실시간 작업 상태를 가져오려면 다음 명령을 실행하여 컨테이너 인스턴스에서 실행 중인 작업의 메타데이터를 확인합니다.

curl http://localhost:51678/v1/metadata

다음 예시와 유사한 출력이 표시됩니다.

{  "Cluster": "CLUSTER_ID",
  "ContainerInstanceArn": "arn:aws:ecs:REGION:ACCOUNT_ID:container-instance/TASK_ID",
  "Version": "Amazon ECS Agent - AGENT "
}

출력에서 작업 환경 변수, CPU, 메모리 및 IAM 역할 구성이 올바른지 확인합니다. 또한 작업에 필요한 비밀이 있는지 확인합니다.

다음 명령을 실행하여 서비스에서 실행 중인 모든 작업에 관한 세부 정보를 확인합니다.

curl http://localhost:51678/v1/tasks

다음 예시와 유사한 출력이 표시됩니다.

{  "Tasks": [
    {
      "Arn": "arn:aws:ecs:REGION:ACCOUNT_ID:task/TASK_ID",
      "DesiredStatus": "RUNNING",
      "KnownStatus": "RUNNING",
      ... ...
    }
  ]
}

위의 명령 출력에서 로컬 에이전트와 Amazon ECS 서비스 간에 차이가 있는지 확인합니다. 이 정보를 사용하여 작업이 중단된 위치와 중단된 이유를 식별합니다.

Amazon ECS 컨테이너 에이전트가 기존 작업을 중지하는 데 시간이 오래 걸림

Amazon ECS가 새 작업을 보내 PENDING 상태에서 RUNNING 상태로 시작할 때 컨테이너 에이전트가 중지해야 할 기존 작업이 있을 수 있습니다. 이러한 경우 에이전트는 기존 작업을 먼저 중지할 때까지 새 작업을 시작하지 않습니다.

컨테이너 인스턴스 레벨에서 컨테이너 중지 및 시작 시간 제한을 제어하려면 /etc/ecs/ecs.config에서 ECS_CONTAINER_STOP_TIMEOUT 및 ECS_CONTAINER_START_TIMEOUT 변수의 환경 변수를 조정합니다. ECS_CONTAINER_STOP_TIMEOUT은 Amazon ECS에서 컨테이너가 자체적으로 종료되지 않을 경우 해당 컨테이너를 강제로 종료하기까지 걸리는 시간을 설정합니다. Linux와 Windows의 기본 중지 시간 제한 값은 30초입니다. ECS_CONTAINER_START_TIMEOUT은 Amazon ECS 컨테이너 에이전트가 더 이상 컨테이너 시작을 시도하지 않을 때까지 경과하는 시간을 설정합니다. 기본 시작 시간 제한 값은 Linux의 경우 3분, Windows의 경우 8분입니다.

에이전트 버전이 1.26.0 이상인 경우, 각 작업에서 중지 및 시작 시간 제한 파라미터를 정의할 수 있습니다. 매개변수를 변경하면 작업이 STOPPED 상태로 변경될 수 있습니다. 예를 들어, 컨테이너 인스턴스 A는 COMPLETE, SUCCESS 또는 HEALTHY 상태에 도달한 컨테이너 인스턴스 B에 종속됩니다. 컨테이너 인스턴스 B에 startTimeout 값을 지정하지 않았습니다. 컨테이너 인스턴스 B가 시간 제한 내에 필요한 상태에 도달하지 않으면 컨테이너 인스턴스 A가 시작되지 않습니다.

컨테이너 종속성의 예시는 GitHub 웹사이트에서 Example: Container dependency를 참조하십시오.

Amazon VPC 라우팅을 올바르게 구성하지 않았음

Amazon ECS 또는 Fargate 작업이 실행되는 VPC 서브넷의 구성을 확인합니다. 서브넷은 Amazon ECS 또는 Amazon Elastic Container Registry(Amazon ECR)에 액세스할 수 있어야 합니다. 이 문제를 해결하려면 서브넷의 라우팅 테이블에 인터넷 게이트웨이 또는 NAT 게이트웨이가 있어야 합니다. 인터넷으로 연결되는 아웃바운드 경로가 없는 서브넷에서 작업을 시작하는 경우 AWS PrivateLink를 사용합니다. 이 구성을 통해 프라이빗 IP 주소로 Amazon ECS API에 액세스할 수 있습니다.

또한 보안 그룹 규칙이 구성의 필수 포트를 통한 인바운드 및 아웃바운드 통신을 허용하는지 확인합니다.

필수 컨테이너 인스턴스가 HEALTY 상태가 아닌 비필수 컨테이너 인스턴스에 종속됨

필수 컨테이너 인스턴스가 의존하는 비필수 컨테이너 인스턴스가 HEALTHY 상태가 되지 않으면 작업이 PENDING 상태에서 멈춥니다. "stoppedReason":"Service ABCXYZ: task last status remained in PENDING too long" 메시지가 표시됩니다.

이 문제를 해결하려면 비필수 컨테이너 인스턴스가 제대로 작동하는지 확인합니다. 기본 문제를 해결할 수 없는 경우 컨테이너 인스턴스의 작업 정의를 업데이트하고 essential 파라미터를 true로 설정합니다. 작업이 여전히 중지된 경우 중지된 이유를 확인하십시오. 추가 문제 해결 단계는 Amazon ECS 작업이 중지되는 이유는 무엇입니까?를 참조하십시오.

IAM 역할이 누락되거나 잘못 구성됨

작업이 필요한 권한이 없는 컨테이너 인스턴스에 있는 경우 다음 예시와 비슷한 오류가 발생합니다.

"(service test) failed to launch a task with (error ECS was unable to assume the role 'arn:aws:iam::111111111111:role/test-fTa-T3J4hVnyL53E' that was provided for this task. Please verify that the role being passed has the proper trust relationship and permissions and that your IAM user has permissions to pass this role.)"

이 문제를 해결하려면 컨테이너 인스턴스에 필요한 권한이 있어야 합니다.

또한 컨테이너 인스턴스에 Amazon ECS 최적화 Amazon Machine Image(AMI)를 사용하지 않는 경우 Amazon ECS 에이전트 구성을 확인하십시오.

선택한 Windows 버전과의 이미지 호환 문제가 있음

Windows Fargate 작업에서 사용하는 이미지가 플랫폼과 호환되지 않으면 작업이 실패합니다. 이미지가 Windows 서버 호스트와 호환되는지 확인하려면 Microsoft 웹사이트에서 Windows 컨테이너 버전 호환성을 참조하십시오. 이후 Windows 작업 실행 전제 조건을 확인하십시오.

또한 정의한 이미지 URL이 정확해야 합니다.

관련 정보

컨테이너 종속성

GitHub 웹사이트의 amazon-ecs-agent