기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
실행 실패 이유
실행이 실패하면 GetRun API 작업을 사용하여 실패 이유를 검색합니다.
실패 이유를 검토하여 실행이 실패한 이유를 해결할 수 있습니다. 다음 표에는 오류에 대한 설명과 함께 각 실패 이유가 나열되어 있습니다.
실패 사유 | 오류 설명 |
---|---|
|
HealthOmics에는 역할을 수임할 권한이 없습니다. 역할에 대한 신뢰 관계에서 HealthOmics 보안 주체를 지정합니다. |
|
워크플로 작업을 시작할 수 없음: |
|
워크플로 작업을 시작할 수 없음: |
ECR_PERMISSION_ERROR |
HealthOmics에는 이미지 URI에 액세스할 수 있는 권한이 없습니다. Amazon ECR 프라이빗 리포지토리가 존재하고 HealthOmics 서비스 보안 주체에 대한 액세스 권한을 부여했는지 확인합니다. |
|
내보내기에 실패했습니다. 출력 버킷이 존재하고 실행 역할에 버킷에 대한 쓰기 권한이 있는지 확인합니다. |
|
파일 시스템에 충분한 공간이 없습니다. 파일 시스템 크기를 늘리고 다시 실행합니다. |
|
이미지 |
|
가져오기에 실패했습니다. 입력 파일이 있고 실행 역할이 입력에 액세스할 수 있는지 확인합니다. |
INACTIVE_OMICS_STORAGE_RESOURCE |
HealthOmics 스토리지 URI가 ACTIVE 상태가 아닙니다. 읽기 세트를 활성화하고 다시 시도하세요. 읽기 세트 활성화에 대한 자세한 내용은 섹션을 참조하세요HealthOmics에서 읽기 세트 활성화. |
INPUT_URI_NOT_FOUND |
제공된 URI가 존재하지 않음: uri . URI 경로가 존재하는지 확인하고 역할이 객체에 액세스할 수 있는지 확인합니다. |
|
워크플로 실행을 완료하기에 인스턴스 용량이 충분하지 않습니다. 기다렸다가 워크플로 실행을 다시 시도합니다. |
INVALID_ECR_IMAGE_URI |
Amazon ECR 이미지 URI 구조가 유효하지 않습니다. 유효한 URI를 입력하고 다시 시도하세요. |
|
요청된 GPU, CPU 또는 메모리가 사용 가능한 컴퓨팅 용량에 비해 너무 높거나 작업 ID 의 최소값인 1보다 작습니다. |
|
URI 구조는 유효한 uri 가 아닙니다. URI 구조를 확인하고 다시 시도하세요. |
MODIFIED_INPUT_RESOURCE |
제공된 URI |
|
워크플로 작업 |
|
작업이 실패하여 실행에 실패했습니다. 작업 실패를 디버깅하려면 GetRunTask API 작업과 Amazon CloudWatch Logs 스트림을 사용합니다. |
|
|
SERVICE_ERROR |
서비스에서 일시적인 오류가 발생했습니다. 워크플로 실행을 다시 시도합니다. |
|
총 입력 크기가 너무 큽니다. 입력 크기를 줄이고 다시 시도하세요. |
|
워크플로 실행에 실패했습니다. CloudWatch Logs 엔진 로그 스트림: |
|
HealthOmics는 요청된 Nextflow 버전: |
|
요청된 인스턴스 유형은 |
응답하지 않는 실행에 대한 지침
새 워크플로를 개발할 때 코드에 문제가 있고 태스크가 프로세스를 제대로 종료하지 못하면 실행 또는 특정 태스크가 "정지" 또는 "중단"될 수 있습니다. 이는 장기간 태스크를 실행하는 것이 정상이므로 문제를 해결하고 포착하기 어려울 수 있습니다. 응답하지 않는 실행을 방지하고 식별하려면 다음 섹션의 권장 모범 사례를 따르세요.
응답하지 않는 실행을 방지하는 모범 사례
-
작업 코드에서 열린 모든 파일을 닫는지 확인합니다. 파일을 너무 많이 열면 워크플로 엔진 내에서 스레드 문제가 발생할 수 있습니다.
-
작업이 종료되면 워크플로 작업에서 생성된 백그라운드 프로세스가 종료되어야 합니다. 그러나 백그라운드 프로세스가 완전히 종료되지 않으면 작업 코드에서 해당 프로세스를 명시적으로 종료해야 합니다.
-
프로세스가 종료하지 않고 반복되지 않는지 확인합니다. 이로 인해 응답하지 않는 실행이 발생할 수 있으며 워크플로 정의 코드를 변경해야 해결할 수 있습니다.
-
작업에 적절한 메모리 및 CPU 할당을 제공합니다. CloudWatch 로그를 분석하거나 워크플로의 성공적으로 완료된 실행분석기 실행에서를 사용하여 최적의 컴퓨팅 할당이 있는지 확인합니다. Run Analyzer
headroom
파라미터를 사용하여 프로세스에 완료할 충분한 리소스가 있는지 확인하는 추가 헤드룸을 포함합니다. 백그라운드 운영 체제 프로세스를 고려하기 위해 할당된 메모리 및 CPU에 최소 5%의 헤드룸을 포함합니다.-
또한 인스턴스에 더 높은 처리량이 필요한 경우 인스턴스 대역폭 크기를 늘립니다. vCPUs(크기 4xl 이하)인 Amazon EC2 인스턴스는 처리량 버스팅이 발생할 수 있습니다. Amazon EC2 인스턴스 처리량에 대한 자세한 내용은 Amazon EC2 사용 가능한 인스턴스 대역폭을 참조하세요.
-
-
실행에 올바른 파일 시스템 크기를 사용하고 있는지 확인합니다. 정적 실행 스토리지를 사용하는 응답하지 않는 실행의 경우 정적 실행 스토리지 할당을 늘려 파일 시스템에서 더 높은 IO 처리량과 스토리지 용량을 활성화하는 것이 좋습니다. 실행 매니페스트를 분석하여 최대 파일 시스템 스토리지를 확인하고, Run Analyzer를 사용하여 파일 시스템 할당을 늘려야 하는지 확인합니다.
응답하지 않는 실행을 포착하기 위한 모범 사례
-
새 워크플로를 개발할 때 최대 실행 시간 제한이 설정된 실행 그룹을 사용하여 런어웨이 코드를 포착합니다. 예를 들어 실행을 완료하는 데 1시간이 걸리는 경우 2~3시간(또는 사용 사례에 따라 다른 기간) 후에 시간이 초과되는 실행 그룹에 실행을 배치하여 런어웨이 작업을 포착합니다. 또한 처리 시간의 차이를 고려하기 위해 버퍼를 적용합니다.
-
최대 런타임 제한이 서로 다른 일련의 실행 그룹을 설정합니다. 예를 들어 몇 시간 후에 실행을 종료하는 실행 그룹에 짧은 실행을 할당하고 예상 워크플로 기간에 따라 며칠 후에 종료되는 긴 실행 그룹을 할당할 수 있습니다.
-
HealthOmics의 기본 최대 실행 기간 서비스 제한은 604,800초 또는 7일로, 할당량 도구의 요청을 통해 조정할 수 있습니다. 1주일에 가까운 실행이 있는 경우에만이 할당량의 서비스 한도 증가를 요청합니다. 단기 실행과 장기 실행이 혼합되어 있고 실행 그룹을 사용하지 않는 경우 최대 실행 기간 서비스 한도가 더 높은 별도의 계정에 장기 실행을 배치하는 것이 좋습니다.
-
응답하지 않을 수 있다고 의심되는 작업이 있는지 CloudWatch 로그를 검사합니다. 작업이 일반적으로 일반 로그 문을 출력하고 장기간 출력하지 않은 경우 작업이 중단되거나 고정될 수 있습니다.
응답하지 않는 실행이 발생할 경우 수행할 작업
-
추가 비용이 발생하지 않도록 실행을 취소합니다.
-
작업 로그를 검사하여 프로세스가 올바르게 종료되지 않았는지 확인합니다.
-
엔진 로그를 검사하여 비정상적인 엔진 동작을 식별합니다.
-
응답하지 않는 실행의 작업 및 엔진 로그와 동일하거나 성공적으로 완료된 실행의 작업 및 엔진 로그를 비교합니다. 이렇게 하면 응답하지 않는 동작을 유발했을 수 있는 차이를 식별하는 데 도움이 될 수 있습니다.
-
근본 원인을 확인할 수 없는 경우 지원 사례를 제기하고 다음을 포함합니다.
-
중단된 실행의 ARN과 성공적으로 완료된 동일한 실행의 ARN입니다.
-
엔진 로그(실행이 취소되거나 실패하면 사용 가능)
-
응답하지 않는 작업에 대한 작업 로그입니다. 워크플로의 모든 작업에 대해 문제 해결을 위해 작업 로그가 필요하지는 않습니다.
-