AWS Batch 작업이 RUNNABLE 상태에서 멈추는 이유는 무엇입니까?

최종 업데이트 날짜: 2022년 2월 3일

AWS Batch 작업이 RUNNABLE 상태로 멈췄습니다. 이런 일이 발생하는 이유와 AWS Batch 작업을 재개하려면 어떻게 해야 합니까?

간략한 설명

AWS Batch는 작업에 해결되지 않은 종속성이 없고 호스트에서 실행을 예약할 준비가 되면 작업을 RUNNABLE 상태로 전환합니다. RUNNABLE 작업은 작업 대기열에 매핑된 컴퓨팅 환경 중 하나에서 충분한 리소스를 사용할 수 있는 즉시 시작됩니다.

작업을 실행하기에 리소스가 충분하지 않으면 작업이 무기한으로 RUNNABLE 상태로 남아 있을 수 있습니다. 자세한 내용은 AWS Batch 사용 설명서의 RUNNABLE 상태로 멈춘 작업을 참조하세요.

RUNNABLE 상태로 멈춘 AWS Batch 작업 문제를 해결하려면 다음을 수행합니다.

해결 방법

컴퓨팅 환경에 작업을 실행하기에 충분한 리소스가 있는지 확인

1.    AWS Batch 콘솔을 엽니다.

2.    [대시보드(Dashboard)]를 선택합니다.

3.    [작업 대기열 개요(Job queue overview)] 창의 [RUNNABLE] 열에서 RUNNABLE 상태로 멈춘 작업을 선택합니다. [작업 세부 정보(Job details)] 페이지가 나타납니다.

4.    [작업 세부 정보(Job details)] 페이지의 [환경(Environment)] 섹션에서 [vCPUs] 및 [Memory(메모리)]의 값을 검토합니다. 7-9단계를 완료하려면 이 값이 필요합니다.

5.    왼쪽 탐색 창에서 [컴퓨팅 환경(Compute environments)]을 선택합니다. 그런 다음 [이름(Name)] 열에서 작업을 실행해야 하는 컴퓨팅 환경의 이름을 찾습니다.

6.    컴퓨팅 환경의 [상태(Status)] 열을 검토합니다. [VALID]로 설정되어 있는지 확인합니다.

7.    컴퓨팅 환경의 [상태(State)] 열을 검토합니다. [활성화됨(ENABLED)]으로 설정되어 있는지 확인합니다.

8.    컴퓨팅 환경의 [최대 vCPUs(Max vCPUs)] 열과 [원하는 vCPUs(Desired vCPUs)] 열을 검토합니다. 최대 vCPU(Max vCPUs) 값이 AWS Batch에서 작업 실행을 위해 원하는 vCPU(Desired vCPUs) 수를 늘릴 수 있을 만큼 충분히 높게 설정되었는지 확인합니다.
참고: Fargate 컴퓨팅 환경을 사용하는 경우 컴퓨팅 환경의 네트워크 및 보안 설정 확인 섹션으로 진행하세요.

9.    [원하는 vCPUs(Desired vCPUs)] 값이 작업 실행에 필요한 vCPUs 수보다 크거나 같은지 확인합니다.

10.    [원하는 vCPU(Desired vCPU)]가 0인 경우 해당 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 유형에 사용 가능한 메모리 및 CPU 리소스의 양을 확인합니다.

-또는-

[원하는 vCPU(Desired vCPU)]가 0보다 높거나 작업이 여전히 RUNNABLE 상태인 경우 이 문서의 다음 섹션에 나와 있는 단계를 완료합니다.

중요: 컴퓨팅 환경의 인스턴스 유형 중 하나 이상에 작업에서 지정하는 메모리 용량보다 더 많은 메모리가 있어야 합니다. 또한 작업에 지정된 것 이상의 CPU 리소스가 인스턴스 유형에 있어야 합니다. 하나 이상의 인스턴스 유형에 작업을 실행하기에 충분한 메모리 또는 CPU 리소스가 없는 경우 작업을 취소합니다. 그런 다음 더 적은 CPU 또는 메모리가 필요한 새 작업을 실행하십시오. 또는 작업을 실행하기에 충분한 리소스가 있는 새 컴퓨팅 환경을 생성한 후 작업을 해당 작업 대기열에 할당할 수도 있습니다.

컴퓨팅 환경에 인스턴스가 있고 해당 인스턴스를 작업 실행에 사용할 수 있는지 확인

1.    Amazon Elastic Container Service(Amazon ECS) 콘솔을 엽니다.

2.    왼쪽 탐색 창에서 [클러스터(Clusters)]를 선택합니다. 그런 다음 작업이 포함된 클러스터를 선택합니다.

참고: 클러스터의 이름은 컴퓨팅 환경의 이름으로 시작하며 그 뒤에 _Batch_와 숫자 및 문자의 랜덤 해시가 붙습니다.

3.    [ECS 인스턴스(ECS Instances)] 보기를 선택합니다. 그런 다음 컨테이너 인스턴스를 사용하여 작업을 실행할 수 있는지 확인합니다.

4.    클러스터에 작업을 실행하는 데 사용 가능한 컨테이너 인스턴스가 있는 경우 Docker 데몬 및 Amazon ECS 컨테이너 에이전트의 상태를 확인합니다. 자세한 내용은 Amazon Linux 2 AMI가 있는 Amazon ECS 컨테이너 인스턴스가 연결 해제된 이유는 무엇입니까?를 참조하세요.

Amazon ECS 클러스터에 인스턴스가 없는 경우 컴퓨팅 환경에서 인스턴스를 생성할 수 있는지 확인합니다. 인스턴스를 생성할 수 있는지 확인하려면 컴퓨팅 환경에 따라 다음 중 하나를 수행합니다.

온디맨드 컴퓨팅 환경에서 인스턴스를 생성할 수 있는지 확인하려면

1.    Amazon EC2 콘솔을 엽니다.

2.    왼쪽 탐색 창에서 [Auto Scaling 그룹(Auto Scaling Groups)]을 선택합니다.

3.    [필터]에 컴퓨팅 환경의 이름을 입력합니다.

참고: Amazon EC2는 동일한 컴퓨팅 환경에 두 개 이상의 Auto Scaling 그룹을 생성할 수 있습니다.

4.    각 Auto Scaling 그룹에 대해 [활동 기록(Activity History)] 보기를 선택합니다. 그런 다음 차단 문제를 찾습니다. 인스턴스 실행을 차단하는 문제가 있는 경우 [상태(Status)] 열에 [실패(Unsuccessful)]로 표시됩니다. 예를 들어 계정이 최대 인스턴스 수에 도달하면 Amazon EC2에서 다음과 유사한 메시지가 반환될 수 있습니다.

Launching a new EC2 instance. Status Reason: Your quota allows for 0 more running instance(s). You requested at least 1. Launching EC2 instance failed.

이벤트에는 작업을 제출한 시점의 UTC 기준 타임스탬프가 포함됩니다. 예를 들어 다음과 같습니다.

At 2018-09-03T05:54:30Z a user request update of AutoScalingGroup constraints to min: 0, max: 1, desired: 1 changing the desired capacity from 0 to 1.
At 2018-09-03T05:54:52Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 1.

참고: AWS Batch는 사용자를 대신해 인스턴스를 요청합니다. Auto Scaling 그룹을 수동으로 수정하면 컴퓨팅 환경이 INVALID 상태가 될 수 있습니다. 인스턴스 제한 및 제한을 늘리도록 요청하는 방법에 대한 자세한 내용은 Amazon EC2 서비스 할당량을 참조하세요.

5. Auto Scaling 그룹의 최근 이벤트에 성공적인 이벤트만 표시되면 다음 섹션의 단계를 완료합니다.

중요: 암호화된 Amazon Elastic Block Store(Amazon EBS) 볼륨 및 고객 관리형 AWS Key Management Service(AWS KMS) 키가 있는 사용자 지정 Amazon Machine Image(AMI)의 경우, 서비스에 연결된 AWS Identity and Access Management(IAM) 역할 AWSServiceRoleForAutoScaling에는 최소한 고객 관리형 AWS KMS 키에 대한 사용자 액세스 권한이 있어야 합니다. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 예시 1: 고객 관리형 키에 대한 액세스를 허용하는 키 정책 섹션을 참조하세요.

스팟 컴퓨팅 환경에서 인스턴스를 생성할 수 있는지 확인하려면

1.    Amazon EC2 콘솔을 엽니다.

2.    왼쪽 탐색 창에서 [인스턴스(Instances)]를 선택합니다. 그런 다음 [스팟 요청(Spot Requests)]을 선택합니다.

3.    필터의 [Request type]에서 [fleet]을 선택합니다.

4.    [Status]에서 [active]를 선택합니다.

5.    [설명(Description)]을 선택합니다. 그런 다음 [총 목표 용량(Total target capacity)] 값을 검토하여 스팟 인스턴스 요청이 이행되었는지 확인합니다. 인스턴스가 생성되지 않으면 [기록(History)] 보기에서 이유를 설명하는 메시지를 확인합니다. 예를 들어 요청이 입찰가에 도달하지 않은 경우 다음과 유사한 메시지가 반환됩니다.

m4.large, ami-aff65ad2, Linux/UNIX (Amazon VPC), us-east-1a, Spot bid price is less than Spot market price $0.0324

6.    컴퓨팅 환경에 적합한 입찰 비율을 선택합니다. 또한 입찰 가격을 변경하는 경우 새 컴퓨팅 환경을 만들어야 합니다. 자세한 내용은 스팟 인스턴스 요금 기록을 참조하세요.

참고: AWS Batch가 자동으로 스팟 플릿 요청을 생성합니다. 스팟 플릿 요청을 수동으로 수정하지 마세요. 그러면 컴퓨팅 환경이 [INVALID] 상태가 될 수 있습니다.

7.    Auto Scaling 그룹의 최근 이벤트에 성공적인 이벤트만 표시되면 다음 섹션의 단계를 완료합니다.

컨테이너 인스턴스 IAM 역할 확인

1.    AWS Batch 콘솔을 엽니다.

2.    탐색 창에서 [컴퓨팅 환경(Compute environments)]을 선택합니다. 그런 다음 컴퓨팅 환경을 선택합니다.

3.    [컴퓨팅 환경 세부 정보(Compute environment details)] 섹션에서 [인스턴스 역할(Instance role)] 이름을 복사합니다.

4.    IAM 콘솔을 엽니다.

5.    검색 상자에 [인스턴스 역할(Instance role)] 이름을 입력합니다. 그런 다음 결과에서 인스턴스 역할을 선택합니다.

6.    [권한(Permissions)] 보기를 선택합니다. 그런 다음 AmazonEC2ContainerServiceforEC2Role 관리형 정책이 역할에 연결되어 있는지 확인합니다. 정책이 연결되면 인스턴스 역할이 올바르게 구성된 것이므로 11단계로 건너뛰어도 됩니다.

7.    [정책 연결(Attach Policies)]을 선택합니다.

8.    검색 상자에 AmazonEC2ContainerServiceforEC2Role을 입력합니다.

9.    AmazonEC2ContainerServiceforEC2Role 정책의 경우 확인란을 선택합니다. 그런 다음 [정책 연결(Attach Policy)]을 선택합니다.

10.    [신뢰 관계(Trust Relationships)] 보기를 선택합니다. 그런 다음 [신뢰 관계 편집(Edit trust relationship)]을 선택합니다.

11.    신뢰 관계에 다음 정책이 포함되어 있는지 확인합니다.

{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

12.    신뢰 관계가 위 예제의 정책과 일치할 경우 [취소(Cancel)]를 선택합니다.

또는

신뢰 관계가 위 예시의 정책과 일치하지 않으면 정책 문서 콘솔에 정책을 복사합니다. 그런 다음 [신뢰 정책 업데이트(Update Trust Policy)]를 선택합니다.

인스턴스가 여전히 ECS 클러스터에 조인되지 않으면 다음 섹션의 단계를 완료합니다.

컴퓨팅 환경의 네트워크 및 보안 설정 확인

1.    AWS Batch 콘솔을 엽니다.

2.    왼쪽 탐색 창에서 [컴퓨팅 환경(Compute environments)]을 선택합니다. 그런 다음 컴퓨팅 환경을 선택합니다.

3.    [컴퓨팅 리소스(Compute resources)] 섹션에서 [서브넷(Subnets)] 및 [보안 그룹(Security groups)] 값을 복사합니다.

4.    Amazon Virtual Private Cloud(Amazon VPC) 콘솔을 엽니다.

5.    왼쪽 탐색 창에서 [서브넷(Subnets)]을 선택합니다.

6.    컴퓨팅 환경의 각 서브넷에 대해 [설명(Description)]을 선택합니다. 그런 다음 [퍼블릭 IPv4 주소 자동 할당(Auto-assign public IPv4 address)] 값을 검토합니다.

퍼블릭 IPv4 주소 자동 할당 값이 ‘Yes’인 경우

서브넷에서 시작된 인스턴스는 다음과 같습니다.

  • 퍼블릭 IPv4 주소
  • 경로 대상이 0.0.0.0/0인 라우팅 테이블
  • 대상으로 설정된 인터넷 게이트웨이(예: igw-1a2b3c4d)

퍼블릭 IPv4 주소 자동 할당 값이 ‘No’인 경우

서브넷에서 시작된 인스턴스는 다음과 같습니다.

  • 프라이빗 IPv4 주소
  • 경로 대상이 0.0.0.0/0인 라우팅 테이블
  • 타겟으로 설정된 NAT 게이트웨이(예: nat-12345678901234567).

참고: 자세한 정보는 라우팅을 참조하세요.

7.    왼쪽 탐색 창에서 [보안 그룹(Security Groups)]을 선택합니다.

8.    컴퓨팅 환경에 지정된 각 보안 그룹에 대해 [아웃바운드 규칙(Outbound Rules)] 보기를 선택합니다. 그리고 다음 설정이 있는 규칙이 있는지 확인합니다.
[유형(Type)]에서 [모든 트래픽(ALL Traffic)]을 선택합니다.
[프로토콜]에서 [모두]를 선택합니다.
[포트 범위]에서 [모두]를 선택합니다.
[대상(Destination)]에서 [0.0.0.0/0]을 선택합니다.

중요: 규칙이 없으면 [편집(Edit)]을 선택합니다. 그런 다음 규칙을 만듭니다. 아웃바운드 트래픽에 대해 보다 제한적인 규칙을 생성하려는 경우 [HTTPS (443)]를 [유형(Type)]으로 선택하고 [0.0.0.0/0]을 [대상(Destination)]으로 선택합니다.

9.    왼쪽 탐색 창에서 [네트워크 ACL(Network ACL)]을 선택합니다.

10.    VPC의 액세스 제어 목록(ACL)을 선택합니다.

11.    기본 네트워크 ACL이 연결된 서브넷의 내부와 외부로의 모든 트래픽 흐름을 허용하도록 구성되었는지 확인합니다.

중요: ACL을 수정한 경우 서브넷에서 인터넷으로의 아웃바운드 IPv4 HTTPS 트래픽을 허용하는 규칙을 추가합니다. 자세한 내용은 보안 그룹으로 EC2 인스턴스에 대한 트래픽 제어네트워크 ACL로 서브넷에 대한 트래픽 제어를 참조하세요. VPC, 서브넷 또는 보안 그룹을 변경하려면 새 컴퓨팅 환경을 생성합니다.

인스턴스가 여전히 ECS 클러스터에 조인되지 않는 경우 인스턴스에 연결합니다. 그건 다음 Docker 데몬 및 Amazon ECS 컨테이너 에이전트의 상태를 확인합니다.


이 문서가 도움이 되었나요?


결제 또는 기술 지원이 필요하세요?