기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 실행 실패 이유
<a name="workflows-run-errors"></a>

실행이 실패하면 [GetRun](https://docs.aws.amazon.com/omics/latest/api/API_GetRun.html) API 작업을 사용하여 실패 이유를 검색합니다.

실패 이유를 검토하여 실행이 실패한 이유를 해결할 수 있습니다. 다음 표에는 오류에 대한 설명과 함께 각 실패 이유가 나열되어 있습니다.


| 실패 이유 | 오류 설명 | 
| --- | --- | 
|  ASSUME\$1ROLE\$1FAILED  |  HealthOmics에는 역할을 수임할 권한이 없습니다. 역할에 대한 신뢰 관계에서 HealthOmics 보안 주체를 지정합니다.  | 
|  CANNOT\$1START\$1CONTAINER\$1ERROR  |  워크플로 작업을 시작할 수 없음: *이름*, ID: 이미지를 사용하는 *ID* 컨테이너: *이미지 이름*. 이미지가 유효한지 확인하고 다시 시도하세요.  | 
|  CANNOT\$1START\$1CONTAINER\$1SIZE\$1ERROR  |  워크플로 작업을 시작할 수 없음: *이름*, ID: 이미지를 사용하는 *ID* 컨테이너: *이미지 이름*. 이미지 크기가 45GiB(GPU 인스턴스의 경우 95GiB) 미만인지 확인하고 다시 시도하세요.  | 
| ECR\$1PERMISSION\$1ERROR | HealthOmics에는 이미지 URI에 액세스할 수 있는 권한이 없습니다.Amazon ECR 프라이빗 리포지토리가 존재하고 HealthOmics 서비스 보안 주체에 대한 액세스 권한을 부여했는지 확인합니다. | 
|  내보내기\$1실패  |  내보내기에 실패했습니다. 출력 버킷이 존재하고 실행 역할에 버킷에 대한 쓰기 권한이 있는지 확인합니다.  | 
|  FILE\$1SYSTEM\$1OUT\$1OF\$1SPACE  | 파일 시스템에 충분한 공간이 없습니다. 파일 시스템 크기를 늘리고 다시 실행합니다. | 
|  이미지\$1검증\$1실패  |  이미지 *이미지 이름을* 확인할 수 없습니다. 문제를 해결하려면 이미지를 가져온 다음 ECR 리포지토리로 다시 푸시합니다.  | 
|  가져오기\$1실패  |  가져오기에 실패했습니다. 입력 파일이 존재하고 실행 역할이 입력에 액세스할 수 있는지 확인합니다.  | 
| INACTIVE\$1OMICS\$1스토리지\$1리소스  |  HealthOmics 스토리지 URI가 ACTIVE 상태가 아닙니다. 읽기 세트를 활성화하고 다시 시도하세요. 읽기 세트 활성화에 대한 자세한 내용은 섹션을 참조하세요[HealthOmics에서 읽기 세트 활성화](activating-read-sets.md).  | 
| INPUT\$1URI\$1NOT\$1FOUND | 제공된 URI가 존재하지 않습니다. uri. URI 경로가 존재하는지 확인하고 역할이 객체에 액세스할 수 있는지 확인합니다. | 
|  인스턴스\$1예약\$1실패  |  워크플로 실행을 완료하기에 인스턴스 용량이 충분하지 않습니다. 기다렸다가 워크플로 실행을 다시 시도합니다.  | 
| INVALID\$1ECR\$1IMAGE\$1URI |  Amazon ECR 이미지 URI 구조가 유효하지 않습니다. 유효한 URI를 입력하고 다시 시도하세요.  | 
|  INVALID\$1TASK\$1RESOURCE\$1VALUE  | 요청된 GPU, CPU 또는 메모리가 사용 가능한 컴퓨팅 용량에 비해 너무 높거나 작업 ID의 최소값인 1보다 작습니다. | 
|  INVALID\$1URI\$1INPUT  | URI 구조는 유효한 uri가 아닙니다. URI 구조를 확인하고 다시 시도하세요. | 
|  MODIFIED\$1INPUT\$1RESOURCE  |  제공된 URI *uri*는 실행이 시작된 후 수정되었습니다. 실행을 다시 시도합니다.  | 
|  OUT\$1OF\$1MEMORY\$1ERROR  |  워크플로 작업 *ID*에 메모리가 부족합니다. 워크플로 정의의 메모리 값을 늘리고 실행을 다시 시도합니다.  | 
|  RUN\$1TASK\$1FAILED  |  작업이 실패하여 실행에 실패했습니다. 작업 실패를 디버깅하려면 **GetRunTask** API 작업과 Amazon CloudWatch Logs 스트림을 사용합니다.  | 
|  RUN\$1TIMED\$1OUT  |  *수* 분 후 실행 제한 시간입니다.  | 
|  SERVICE\$1ERROR  | 서비스에서 일시적인 오류가 발생했습니다. 워크플로 실행을 다시 시도합니다. | 
| TASK\$1TIMED\$1OUT | 수 초 후에 작업 ID가 시간 초과되었습니다. | 
|  UNSUPPORTED\$1INPUT\$1SIZE  |  총 입력 크기가 너무 큽니다. 입력 크기를 줄이고 다시 시도하세요.  | 
|  WORKFLOW\$1RUN\$1FAILED  |  워크플로 실행에 실패했습니다. CloudWatch Logs 엔진 로그 스트림: *ID*를 검토하여 실패를 디버깅합니다.  | 
|  워크플로\$1VER\$1검증\$1실패  |  HealthOmics는 요청된 Nextflow 버전: *버전* --를 지원하지 않습니다. 지원되는 최신 버전은 *버전*입니다. Nextflow 버전을 지원되는 버전으로 수정하고 다시 시도하세요.  | 
|  지원되지 않는\$1GPU\$1INSTANCE\$1TYPE  |  요청된 인스턴스 유형은 *리전*에서 지원되지 않습니다. 이 리전에서 지원되는 GPU 인스턴스 유형으로 실행을 재시도합니다. 사용 가능한 인스턴스 유형은 *GPU 인스턴스 유형*입니다.  | 

## 응답하지 않는 실행에 대한 지침
<a name="workflows-guidance-unresponsive-runs"></a>

새 워크플로를 개발할 때 코드에 문제가 있고 태스크가 프로세스를 제대로 종료하지 못하면 실행 또는 특정 태스크가 "정지" 또는 "중단"될 수 있습니다. 이는 장기간 태스크를 실행하는 것이 정상이므로 문제를 해결하고 포착하기 어려울 수 있습니다. 응답하지 않는 실행을 방지하고 식별하려면 다음 섹션의 권장 모범 사례를 따르세요.

**응답하지 않는 실행을 방지하기 위한 모범 사례**
+ 작업 코드에서 열린 모든 파일을 닫는지 확인합니다. 파일을 너무 많이 열면 워크플로 엔진 내에서 스레드 문제가 발생할 수 있습니다.
+ 작업이 종료되면 워크플로 작업에서 생성된 백그라운드 프로세스가 종료되어야 합니다. 그러나 백그라운드 프로세스가 완전히 종료되지 않으면 작업 코드에서 해당 프로세스를 명시적으로 종료해야 합니다.
+ 프로세스가 종료하지 않고 반복되지 않는지 확인합니다. 이로 인해 응답하지 않는 실행이 발생할 수 있으며 워크플로 정의 코드를 변경해야 해결할 수 있습니다.
+ 작업에 적절한 메모리 및 CPU 할당을 제공합니다. [CloudWatch 로그](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html)를 분석하거나 워크플로의 성공적으로 완료된 실행[분석기 실행](workflows-run-optimize.md#workflows-run-analyzer)에서를 사용하여 최적의 컴퓨팅 할당이 있는지 확인합니다. Run Analyzer `headroom` 파라미터를 사용하여 추가 헤드룸을 포함하여 프로세스에 완료할 충분한 리소스가 있는지 확인합니다. 백그라운드 운영 체제 프로세스를 고려하기 위해 할당된 메모리 및 CPU에 최소 5%의 헤드룸을 포함합니다.
  + 또한 인스턴스에 더 높은 처리량이 필요한 경우 인스턴스 대역폭 크기를 늘립니다. vCPUs(크기 4xl 이하)인 Amazon EC2 인스턴스는 처리량 버스팅이 발생할 수 있습니다. Amazon EC2 인스턴스 처리량에 대한 자세한 내용은 [Amazon EC2 사용 가능한 인스턴스 대역폭](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html#available-instance-bandwidth)을 참조하세요.
+ 실행에 올바른 파일 시스템 크기를 사용하고 있는지 확인합니다. 정적 실행 스토리지를 사용하는 응답하지 않는 실행의 경우 정적 실행 스토리지 할당을 늘려 파일 시스템에서 더 높은 IO 처리량 및 스토리지 용량을 활성화하는 것이 좋습니다. 실행 매니페스트를 분석하여 최대 파일 시스템 스토리지를 확인하고, Run Analyzer를 사용하여 파일 시스템 할당을 늘려야 하는지 확인합니다.

**응답하지 않는 실행을 포착하는 모범 사례**
+ 새 워크플로를 개발할 때 최대 실행 시간 제한이 설정된 실행 그룹을 사용하여 런어웨이 코드를 포착합니다. 예를 들어 실행을 완료하는 데 1시간이 걸리는 경우 2\$13시간(또는 사용 사례에 따라 다른 기간) 후에 시간이 초과되는 실행 그룹에 실행을 배치하여 런어웨이 작업을 포착합니다. 또한 처리 시간의 차이를 고려하기 위해 버퍼를 적용합니다.
+ 최대 런타임 제한이 서로 다른 일련의 실행 그룹을 설정합니다. 예를 들어 몇 시간 후에 실행을 종료하는 실행 그룹에 짧은 실행을 할당하고 예상 워크플로 기간에 따라 며칠 후에 종료되는 긴 실행 그룹을 할당할 수 있습니다.
+ HealthOmics의 기본 최대 실행 기간 서비스 제한은 604,800초 또는 7일로, 할당량 도구의 요청을 통해 조정할 수 있습니다. 1주일에 가까운 실행이 있는 경우에만이 할당량의 서비스 한도 증가를 요청합니다. 단기 실행과 장기 실행이 혼합되어 있고 실행 그룹을 사용하지 않는 경우 최대 실행 기간 서비스 한도가 더 높은 별도의 계정에 장기 실행을 배치하는 것이 좋습니다.
+ 응답하지 않을 수 있다고 의심되는 작업이 있는지 [CloudWatch 로그](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html)를 검사합니다. 태스크가 일반적으로 일반 로그 문을 출력하고 장기간 출력하지 않은 경우 태스크가 중단되거나 고정될 수 있습니다.

**응답하지 않는 실행이 발생할 경우 수행할 작업**
+ 추가 비용이 발생하지 않도록 실행을 취소합니다.
+ [작업 로그](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html#cloudwatch-logs)를 검사하여 프로세스가 올바르게 종료되지 않았는지 확인합니다.
+ [엔진 로그](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html#cloudwatch-logs)를 검사하여 비정상적인 엔진 동작을 식별합니다.
+ 응답하지 않는 실행의 작업 및 엔진 로그를 성공적으로 완료된 동일한 실행의 작업 및 엔진 로그와 비교합니다. 이렇게 하면 응답하지 않는 동작을 일으켰을 수 있는 차이를 식별하는 데 도움이 될 수 있습니다.
+ 근본 원인을 확인할 수 없는 경우 [지원 사례를](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html#creating-a-support-case) 제기하고 다음을 포함합니다.
  + 중단된 실행의 ARN과 성공적으로 완료된 동일한 실행의 ARN입니다.
  + 엔진 로그(실행이 취소되거나 실패하면 사용 가능)
  + 응답하지 않는 작업에 대한 작업 로그입니다. 문제를 해결하기 위해 워크플로의 모든 작업에 작업 로그가 필요하지는 않습니다.