

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

# Nextflow 워크플로 정의 세부 정보
<a name="workflow-definition-nextflow"></a>

HealthOmics는 Nextflow DSL1 및 DSL2를 지원합니다. 자세한 내용은 [Nextflow 버전 지원](workflows-lang-versions.md#workflows-lang-versions-nextflow) 섹션을 참조하세요.

Nextflow DSL2는 Groovy 프로그래밍 언어를 기반으로 하므로 파라미터는 동적이며 Groovy와 동일한 규칙을 사용하여 강제 유형을 지정할 수 있습니다. 입력 JSON에서 제공하는 파라미터와 값은 워크플로의 파라미터(`params`) 맵에서 사용할 수 있습니다.

워크플로를 생성하기 전에 Nextflow 정의를 린팅하는 방법에 대한 자세한 내용은 섹션을 참조하세요[로컬에서 워크플로 정의 검증](workflows-validate-local.md).

**Topics**
+ [nf-schema 및 nf-validation 플러그인 사용](#schema-and-validation-plugins-nextflow)
+ [스토리지 URIs 지정](#storage-uris-nextflow)
+ [Nextflow 지시문](#workflow-nexflow-directives)
+ [Nextflow 프로파일 사용](#nextflow-profiles)
+ [워크플로 수준 콘텐츠 내보내기](#exporting-workflow-content-nextflow)
+ [작업 콘텐츠 내보내기](#exporting-task-content-nextflow)
+ [Nextflow 실행 보고서 생성](#nextflow-execution-reports)
+ [Nextflow 구문 버전 지정](#nextflow-syntax-version)
+ [워크플로 생성 중 자동 구문 검증](#nextflow-automatic-validation)
+ [Nextflow에서 스크래치 스토리지를 효율적으로 사용](#nextflow-scratch-storage)

## nf-schema 및 nf-validation 플러그인 사용
<a name="schema-and-validation-plugins-nextflow"></a>

**참고**  
플러그인에 대한 HealthOmics 지원 요약:  
v22.04 - 플러그인을 지원하지 않음
v23.10 - `nf-schema` 및 지원 `nf-validation`
v24.10 - 지원 `nf-schema`
v25.10, v26.04 - `nf-schema`, `nf-core-utils``nf-fgbio`, 및 지원 `nf-prov`

HealthOmics는 Nextflow 플러그인에 대해 다음과 같은 지원을 제공합니다.
+ Nextflow v23.10의 경우 HealthOmics는 nf-validation@1.1.1 플러그인을 사전 설치합니다.
+ Nextflow v23.10 및 v24.10의 경우 HealthOmics는 nf-schema@2.3.0 플러그인을 사전 설치합니다.
+ Nextflow v25.10의 경우 HealthOmics는 nf-schema@2.6.1, , nf-prov@1.7.0 및 nf-fgbio@1.0.1 플러그인nf-core-utils@0.4.0 사전 설치합니다.
+ Nextflow v26.04의 경우 HealthOmics는 nf-schema@2.7.2, , nf-prov@1.7.0 및 nf-fgbio@1.0.1 플러그인nf-core-utils@0.4.0 사전 설치합니다.
+ 워크플로 실행 중에는 추가 플러그인을 검색할 수 없습니다. HealthOmics는 `nextflow.config` 파일에서 지정한 다른 플러그인 버전을 무시합니다.
+ Nextflow v24 이상의 경우 `nf-schema`는 더 이상 사용되지 않는 `nf-validation` 플러그인의 새 버전입니다. 자세한 내용은 Nextflow GitHub [ 리포지토리의 nf-schema](https://github.com/nextflow-io/nf-schema)를 참조하세요.

## 스토리지 URIs 지정
<a name="storage-uris-nextflow"></a>

Amazon S3 또는 HealthOmics URI를 사용하여 Nextflow 파일 또는 경로 객체를 구성하는 경우 읽기 액세스 권한이 부여되는 한 워크플로에서 일치하는 객체를 사용할 수 있습니다. Amazon S3 URIs. 예시는 [Amazon S3 입력 파라미터 형식](workflows-run-inputs.md#s3-run-input-formats) 섹션을 참조하세요.

HealthOmics는 Amazon S3 URIs 또는 HealthOmics 스토리지 URIs에서 glob 패턴 사용을 부분적으로 지원합니다. 워크플로 정의에서 `path` 또는 `file` 채널 생성에 Glob 패턴을 사용합니다. 예상되는 동작과 정확한 사례는 단원을 참조하십시오[Amazon S3 입력에서 Glob 패턴의 Nextflow 처리](workflows-run-inputs.md#wd-nextflow-s3-formats).

## Nextflow 지시문
<a name="workflow-nexflow-directives"></a>

Nextflow 구성 파일 또는 워크플로 정의에서 Nextflow 명령을 구성합니다. 다음 목록은 HealthOmics가 구성 설정을 적용하는 데 사용하는 우선 순위의 순서를 가장 낮은 우선 순위부터 가장 높은 우선 순위까지 보여줍니다.

1. 구성 파일의 전역 구성입니다.

1. 워크플로 정의의 작업 섹션입니다.

1. 구성 파일의 작업별 선택기입니다.

**Topics**
+ [를 사용한 작업 재시도 전략 `errorStrategy`](#workflow-nextflow-errorStrategy)
+ [를 사용하여 작업 재시도 `maxRetries`](#workflow-nexflow-task-retry)
+ [를 사용하여 작업 재시도 옵트아웃 `omicsRetryOn5xx`](#workflow-nextflow-retry-5xx)
+ [를 사용하여 리소스 대체 구성 **omicsResourceFallbackOrder**](#workflow-nextflow-directive-fallback)
+ [`time` 지시문을 사용한 작업 기간](#time-directive-nextflow)

### 를 사용한 작업 재시도 전략 `errorStrategy`
<a name="workflow-nextflow-errorStrategy"></a>

`errorStrategy` 지시문을 사용하여 작업 오류에 대한 전략을 정의합니다. 기본적으로 작업이 오류 표시(종료 상태가 0이 아님)와 함께 반환되면 작업이 중지되고 HealthOmics가 전체 실행을 종료합니다. 를 `errorStrategy`로 설정하면 `retry` HealthOmics는 실패한 작업을 한 번 재시도합니다. 재시도 횟수를 늘리려면 섹션을 참조하세요[를 사용하여 작업 재시도 `maxRetries`](#workflow-nexflow-task-retry).

```
process {
    label 'my_label'
    errorStrategy 'retry'

    script:
    """
    your-command-here
    """
}
```

HealthOmics가 실행 중에 작업 재시도를 처리하는 방법에 대한 자세한 내용은 섹션을 참조하세요[작업 재시도](monitoring-runs.md#run-status-task-retries).

### 를 사용하여 작업 재시도 `maxRetries`
<a name="workflow-nexflow-task-retry"></a>

기본적으로 HealthOmics는 실패한 작업의 재시도를 시도하지 않거나를 구성한 경우 한 번 재시도를 시도합니다`errorStrategy`. 최대 재시도 횟수를 늘리려면를 `retry` `errorStrategy`로 설정하고 `maxRetries` 명령을 사용하여 최대 재시도 횟수를 구성합니다.

다음 예제에서는 글로벌 구성에서 최대 재시도 횟수를 3으로 설정합니다.

```
process {
    errorStrategy = 'retry'
    maxRetries = 3
}
```

다음 예제에서는 워크플로 정의`maxRetries`의 작업 섹션에서를 설정하는 방법을 보여줍니다.

```
process myTask {
    label 'my_label'
    errorStrategy 'retry'
    maxRetries 3
    
    script:
    """
    your-command-here
    """
}
```

다음 예제에서는 이름 또는 레이블 선택기를 기반으로 Nextflow 구성 파일에서 작업별 구성을 지정하는 방법을 보여줍니다.

```
process {
    withLabel: 'my_label' {
        errorStrategy = 'retry'
        maxRetries = 3
    }

    withName: 'myTask' {
        errorStrategy = 'retry'
        maxRetries = 3
    }
}
```

### 를 사용하여 작업 재시도 옵트아웃 `omicsRetryOn5xx`
<a name="workflow-nextflow-retry-5xx"></a>

Nextflow v23 이상의 경우 HealthOmics는 서비스 오류(5XX HTTP 상태 코드)로 인해 작업이 실패한 경우 작업 재시도를 지원합니다. 기본적으로 HealthOmics는 실패한 작업을 최대 2회 재시도합니다.

서비스 오류에 대한 작업 재시도를 옵트아웃`omicsRetryOn5xx`하도록를 구성할 수 있습니다. HealthOmics의 작업 재시도에 대한 자세한 내용은 섹션을 참조하세요[작업 재시도](monitoring-runs.md#run-status-task-retries).

다음 예제에서는 글로벌 구성`omicsRetryOn5xx`에서를 구성하여 작업 재시도를 옵트아웃합니다.

```
process {
    omicsRetryOn5xx = false
}
```

다음 예제에서는 워크플로 정의`omicsRetryOn5xx`의 작업 섹션에서를 구성하는 방법을 보여줍니다.

```
process myTask {
    label 'my_label'
    omicsRetryOn5xx = false
    
    script:
    """
    your-command-here
    """
}
```

다음 예제에서는 이름 또는 레이블 선택기를 기반으로 Nextflow 구성 파일에서 작업별 구성`omicsRetryOn5xx`으로를 설정하는 방법을 보여줍니다.

```
process {
    withLabel: 'my_label' {
        omicsRetryOn5xx = false
    }

    withName: 'myTask' {
        omicsRetryOn5xx = false
    }
}
```

### 를 사용하여 리소스 대체 구성 **omicsResourceFallbackOrder**
<a name="workflow-nextflow-directive-fallback"></a>

HealthOmics는 **omicsResourceFallbackOrder** 프로세스에 대한 액셀러레이터(또는 GPU) 및 CPU 리소스 프로파일의 정렬된 목록을 정의하는 프로세스 명령을 지원합니다. 요청된 액셀러레이터 유형을 사용할 수 없는 경우 HealthOmics는 자동으로 목록의 다음 프로필로 이동합니다. CPU 전용 프로필을 최종 옵션으로 포함할 수 있습니다.

다음 예제에서는 `nvidia-l40s` 먼저를 시도한 다음 `nvidia-l4`를 시도하고 마지막으로 액셀러레이터를 사용할 수 없는 경우 CPU로 돌아갑니다.

```
process ALIGN {
    container 'my-registry/align-multi-arch:latest'

    omicsResourceFallbackOrder([
        [acceleratorType: 'nvidia-l40s', acceleratorCount: 1, cpus: 8, memory: '32 GB', omicsResourceWaitTimeoutInMin: 45],
        [acceleratorType: 'nvidia-l4',   acceleratorCount: 1, cpus: 8, memory: '32 GB'],
        [cpus: 32, memory: '128 GB']
    ])

    script:
    """
    your-command-here
    """
}
```

Nextflow 구성 파일에서 명령을 설정할 수도 있습니다. 구성 파일에서를 사용하여 목록을 할당합니다`=`. 모든 프로세스에 적용되는 `process` 범위의 최상위 수준이나 `withName` 또는 `withLabel` 선택기 내에서 설정할 수 있습니다. 다음 예제에서는 모든 프로세스에 대해 폴백 순서를 설정하고, 레이블이 인 작업에 대해 다른 폴백 순서를 설정하고`my_label`, 작업에 대해 다른 폴백 순서를 설정합니다`myTask`.

```
process {
    omicsResourceFallbackOrder = [
        [acceleratorType: 'nvidia-l4', acceleratorCount: 1, cpus: 8, memory: '32 GB'],
        [cpus: 16, memory: '64 GB']
    ]

    withLabel: 'my_label' {
        omicsResourceFallbackOrder = [
            [acceleratorType: 'nvidia-l40s', acceleratorCount: 1, cpus: 8, memory: '32 GB'],
            [cpus: 32, memory: '128 GB']
        ]
    }

    withName: 'myTask' {
        omicsResourceFallbackOrder = [
            [acceleratorType: 'nvidia-l40s', acceleratorCount: 2, cpus: 16, memory: '64 GB']
        ]
    }
}
```

프로세스가 둘 이상의 위치에서 대체 주문을 받는 경우 HealthOmics는 적용되는 첫 번째 주문을 사용합니다.

1. 프로세스와 일치하는 구성 파일의 `withName` 또는 `withLabel` 선택기입니다.

1. 프로세스 정의의 명령입니다.

1. 구성 파일의 `process` 범위 최상위 수준입니다.

HealthOmics는 작업 컨테이너에서 **AWS\_HEALTHOMICS\_RESOURCE\_TYPE** 환경 변수를 설정합니다. 값은 활성 프로파일의 액셀러레이터 유형(예: `nvidia-l40s`) 또는 CPU 전용 프로파일`cpu`의 경우 입니다. GPU 및 CPU 코드 경로가 다를 때 명령을 분기하는 데 사용합니다.

Nextflow에서 명령을 사용할 때는 다음 사항에 유의하세요.
+ 단위 B, KB, MB, GB 또는 TB 중 **memory** 하나로 작성합니다. 예: `'32 GB'`. GiB, MiB 및 TiB는 허용되지 않습니다.
+ 설정된 경우 프로세스의 **cpus** 또는 **memory** 명령을 생략**cpus**하거나 **memory** 사용하는 프로파일입니다.
+ 프로필이 프로세스**memory**에서 **cpus** 또는를 상속하면 HealthOmics는 값을 프로필에 복사**memory**하기 전에 최대 **cpus** 및를 설정하는 프로세스의 **resourceLimits** 지시문을 적용합니다.
+ `${task.cpus}` 스크립트`${task.memory}`의 및는 실행된 프로파일의 리소스가 아닌 프로세스 수준 값을 표시합니다.

자세한 내용은 섹션을 참조[고급 리소스 구성](advanced-resource-configuration.md)하고 지원되는 액셀러레이터 유형은 섹션을 참조하세요[HealthOmics 워크플로 정의의 태스크 액셀러레이터](task-accelerators.md).

#### 재시도와의 상호 작용
<a name="workflow-nextflow-fallback-retries"></a>

오류 전략( `errorStrategy` 및 `maxRetries` 명령)을 사용하여 재시도를 구성하는 경우 각 재시도에서 사용하는 프로파일은 이전 시도가 실패한 이유에 따라 달라집니다.
+ **용량 부족 장애(ICE).** HealthOmics는 목록의 각 프로파일을 순서대로 시도합니다. 용량을 보호하지 않고 모든 프로파일을 소진한 후 다음 재시도는 명령의 첫 번째 프로파일에서 다시 시작됩니다.
+ **Out-of-memory(OOM) 및 서비스 장애.** 재시도는 첫 번째 프로파일에서 다시 시작하지 않고 이전 시도에서 도달한 것과 동일한 프로파일을 유지합니다.

### `time` 지시문을 사용한 작업 기간
<a name="time-directive-nextflow"></a>

HealthOmics는 실행의 최대 기간을 지정하는 조정 가능한 할당량( 참조[HealthOmics 서비스 할당량](service-quotas.md))을 제공합니다. Nextflow v23 이상 워크플로의 경우 Nextflow `time` 명령을 사용하여 최대 작업 기간을 지정할 수도 있습니다.

새 워크플로 개발 중에 최대 작업 기간을 설정하면 런어웨이 작업과 장기 실행 작업을 포착하는 데 도움이 됩니다.

Nextflow 시간 명령에 대한 자세한 내용은 Nextflow 참조의 [시간 명령을](https://www.nextflow.io/docs/latest/reference/process.html#process-time) 참조하세요.

HealthOmics는 Nextflow 시간 명령에 대해 다음과 같은 지원을 제공합니다.

1. HealthOmics는 시간 명령에 대해 1분 단위를 지원합니다. 60초에서 최대 실행 기간 값 사이의 값을 지정할 수 있습니다.

1. 60 미만의 값을 입력하면 HealthOmics는 값을 60초로 반올림합니다. 60보다 큰 값의 경우 HealthOmics는 가장 가까운 분으로 내림합니다.

1. 워크플로가 작업에 대한 재시도를 지원하는 경우 HealthOmics는 시간 초과 시 작업을 재시도합니다.

1. 작업이 시간 초과(또는 마지막 재시도 시간이 초과)되면 HealthOmics는 작업을 취소합니다. 이 작업의 지속 시간은 1\~2분입니다.

1. 작업 시간 초과 시 HealthOmics는 실행 및 작업 상태를 실패로 설정하고 실행의 다른 작업(시작 중, 보류 중 또는 실행 중 상태의 작업)을 취소합니다. HealthOmics는 제한 시간 전에 완료한 작업의 출력을 지정된 S3 출력 위치로 내보냅니다.

1. 작업이 보류 중 상태로 소요한 시간은 작업 기간에 포함되지 않습니다.

1. 실행이 실행 그룹의 일부이고 실행 그룹이 작업 타이머보다 빨리 시간 초과되면 실행 및 작업이 실패 상태로 전환됩니다.

`ms`, , 또는 단위 중 하나 이상을 사용하여 제한 시간을 지정합니다`s``m``h``d`.

다음 예제에서는 Nextflow 구성 파일에서 전역 구성을 지정하는 방법을 보여줍니다. 전역 제한 시간을 1시간 30분으로 설정합니다.

```
process {
    time = '1h30m'
}
```

다음 예제에서는 워크플로 정의의 작업 섹션에서 시간 지시문을 지정하는 방법을 보여줍니다. 이 예제에서는 제한 시간을 3일, 5시간 및 4분으로 설정합니다. 이 값은 구성 파일의 전역 값보다 우선하지만 구성 `my_label` 파일의에 대한 작업별 시간 명령보다 우선하지는 않습니다.

```
process myTask {
    label 'my_label'
    time '3d5h4m'
        
    script:
    """
    your-command-here
    """
}
```

다음 예제에서는 이름 또는 레이블 선택기를 기반으로 Nextflow 구성 파일에서 작업별 시간 지시문을 지정하는 방법을 보여줍니다. 이 예제에서는 글로벌 작업 제한 시간 값을 30분으로 설정합니다. 작업의 경우 값을 2시간`myTask`으로 설정하고 레이블이 인 작업의 경우 값을 3시간으로 설정합니다`my_label`. 선택기와 일치하는 작업의 경우 이러한 값이 워크플로 정의의 전역 값 및 값보다 우선합니다.

```
process {
    time = '30m'
    
    withLabel: 'my_label' {
        time = '3h'  
    }

    withName: 'myTask' {
        time = '2h'  
    }
}
```

## Nextflow 프로파일 사용
<a name="nextflow-profiles"></a>

Nextflow 프로파일은 런타임 시 선택할 수 있는 명명된 구성 설정 세트입니다. `nextflow.config` 파일 `profiles` 블록에서 프로필을 정의합니다.

```
profiles {
    standard {
        process.cpus = 2
        process.memory = '4 GB'
    }

    production {
        process.cpus = 16
        process.memory = '64 GB'
        params.input = 's3://bucket/production-data.bam'
    }
}
```

실행을 시작할 때 `engineSettings` 파라미터를 사용하여 하나 이상의 프로파일을 지정합니다. HealthOmics는 `-profile` 플래그를 Nextflow 엔진에 전달합니다. 자세한 내용은 [Nextflow 엔진 설정 지정](starting-a-run.md#start-run-api-engine-settings) 섹션을 참조하세요.

```
aws omics start-run \
  --workflow-id {{workflow-id}} \
  --role-arn {{role-arn}} \
  --output-uri s3://{{bucket}}/{{prefix}}/ \
  --engine-settings '{"profile": "production"}'
```

여러 프로파일이 지정되면(예: `"test,docker"`) Nextflow는 명령줄에 지정된 순서대로 프로파일을 적용합니다. 이후 프로파일은 충돌하는 설정에 대해 이전 프로파일을 재정의합니다. 26보다 낮은 Nextflow 버전의 경우 프로파일은 명령줄 순서 대신 구성 파일에 정의된 순서대로 적용됩니다.

다음 사항에 유의하세요.
+ 프로필 지원은 모든 HealthOmics 지원 Nextflow 버전에서 사용할 수 있습니다.
+ 프로필에는 파라미터, 프로세스 지시문, `includeConfig` 문 및 매니페스트 재정의( 포함)가 포함될 수 있습니다`manifest.nextflowVersion`.
+ 명시적 실행 파라미터는 프로파일 정의 파라미터 값보다 우선합니다.
+ 존재하지 않는 프로파일을 지정하면 HealthOmics는 검증 오류를 반환합니다.
+ 프로필은 워크플로 정의 zip 파일에 정의되어야 합니다. HealthOmics는 외부 소스에서 프로필 정의 가져오기를 지원하지 않습니다.
+ 프로파일을 지정하지 않으면 워크플로 정의의 `standard` 프로파일 아래에 프로파일이 정의된 경우 실행에서 해당 프로파일을 사용합니다. 그렇지 않으면 실행은 기본(상위 수준) 구성을 사용합니다.
+ 프로파일을 사용할 때는 실행 간에 일관된 프로파일 애플리케이션 동작을 보장하기 `manifest.nextflowVersion` 위해를 사용하여 워크플로 정의에 Nextflow 버전을 고정시키는 것이 좋습니다.

## 워크플로 수준 콘텐츠 내보내기
<a name="exporting-workflow-content-nextflow"></a>

Nextflow v25.10 이상에서는 산지 보고서 또는 파이프라인 DAGs. 이러한 파일을 내보내려면에 기록합니다`/mnt/workflow/output/`. HealthOmics는이 디렉터리에 배치된 파일을 실행의 Amazon S3 출력 위치의 `output/` 접두사로 내보냅니다.

다음 예제에서는에 산지 보고서를 작성하도록 `nf-prov` 플러그인을 구성하는 방법을 보여줍니다`/mnt/workflow/output/`.

```
prov {
    formats {
        bco {
            file = "/mnt/workflow/output/pipeline_info/manifest.bco.json"
        }
    }
}
```

실행의 입력 JSON에서이 경로를 파라미터로 전달할 수도 있습니다. 이 접근 방식은를 사용하는 nf-core 워크플로에서 일반적입니다`params.outdir`.

```
{
    "outdir": "/mnt/workflow/output/"
}
```

## 작업 콘텐츠 내보내기
<a name="exporting-task-content-nextflow"></a>

Nextflow에 작성된 워크플로의 경우 **publishDir** 명령을 정의하여 작업 콘텐츠를 출력 Amazon S3 버킷으로 내보냅니다. 다음 예제와 같이 **publishDir** 값을 로 설정합니다`/mnt/workflow/pubdir`. Amazon S3로 파일을 내보내려면 파일이이 디렉터리에 있어야 합니다.

```
 nextflow.enable.dsl=2
              
  workflow {
    CramToBamTask(params.ref_fasta, params.ref_fasta_index, params.ref_dict, params.input_cram, params.sample_name)
    ValidateSamFile(CramToBamTask.out.outputBam)
  }
  
  process CramToBamTask {
    container "<account>.dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud"
  
    publishDir "/mnt/workflow/pubdir"
  
    input:
        path ref_fasta
        path ref_fasta_index
        path ref_dict
        path input_cram
        val sample_name
  
    output:
        path "${sample_name}.bam", emit: outputBam
        path "${sample_name}.bai", emit: outputBai
  
    script:
    """
        set -eo pipefail
  
        samtools view -h -T $ref_fasta $input_cram |
        samtools view -b -o ${sample_name}.bam -
        samtools index -b ${sample_name}.bam
        mv ${sample_name}.bam.bai ${sample_name}.bai
    """
  }
  
  process ValidateSamFile {
    container "<account>.dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud"
  
    publishDir "/mnt/workflow/pubdir"
  
    input:
        file input_bam
  
    output:
        path "validation_report"
  
    script:
    """
        java -Xmx3G -jar /usr/gitc/picard.jar \
        ValidateSamFile \
        INPUT=${input_bam} \
        OUTPUT=validation_report \
        MODE=SUMMARY \
        IS_BISULFITE_SEQUENCED=false
    """
  }
```

Nextflow v25.10 이상에서는 워크플로 출력을 사용하여 작업 콘텐츠를 내보낼 `publishDir`수 있습니다. 다음 예제에서는 작업 결과를 Amazon S3로 내보내는 워크플로 `output` 블록을 정의하는 방법을 보여줍니다.

```
process myTask {
    input:
    val data

    output:
    path 'result.txt'

    script:
    """
    echo ${data} > result.txt
    """
}

workflow {
    main:
    output_file = myTask('hello')

    publish:
    results = output_file
}

output {
    results {
        path '.'
    }
}
```

워크플로 출력에 대한 자세한 내용은 Nextflow 설명서의 [워크플로 출력을](https://www.nextflow.io/docs/latest/workflow.html#workflow-output-def) 참조하세요.

## Nextflow 실행 보고서 생성
<a name="nextflow-execution-reports"></a>

Nextflow는 각 실행에 대해 실행 보고서(`report`), 타임라인(`timeline`), 추적 파일(`trace`) 및 워크플로 다이어그램()이라는 네 가지 기본 제공 보고서를 생성할 수 있습니다`dag`. HealthOmics가 이러한 파일을 실행의 Amazon S3 출력 위치로 내보내려면 `nextflow.config` 파일의 `/mnt/workflow/output/` 아래에 출력을 쓰도록 각 파일을 구성합니다.

```
report {
    enabled = true
    file = '/mnt/workflow/output/report.html'
    overwrite = true
}

timeline {
    enabled = true
    file = '/mnt/workflow/output/timeline.html'
    overwrite = true
}

trace {
    enabled = true
    file = '/mnt/workflow/output/trace.txt'
    overwrite = true
}

dag {
    enabled = true
    file = '/mnt/workflow/output/dag.html'
    overwrite = true
}
```

HealthOmics는 아래에 작성된 파일을 실행의 Amazon S3 출력 위치`/mnt/workflow/output/`의 `output/` 접두사로 내보냅니다. 이 내보내기 경로에 대한 자세한 내용은 섹션을 참조하세요[워크플로 수준 콘텐츠 내보내기](#exporting-workflow-content-nextflow). 외부에 작성된 보고서는 실행의 Amazon S3 출력 위치로 내보내`/mnt/workflow/output/`지지 않습니다.

**작업 컨테이너에는 다음이 포함되어야 합니다. `ps`**  
`report`, `timeline`또는 `trace` 보고서가 활성화되면 Nextflow는 각 작업 컨테이너 `ps` 내에서 호출하여 작업당 지표를 수집합니다. `container` 명령으로 지정하는 컨테이너 이미지에는 `ps` 명령이 포함되어야 합니다. 대부분의 Linux 배포판에는 `procps` (Debian/Ubuntu) 또는 `procps-ng` (Amazon Linux, Red Hat, Fedora) 패키지와 함께 설치합니다. 프로세스가 `container` 지시문을 선언하지 않으면 HealthOmics는 이미가 포함된 기본 컨테이너에서 작업을 실행합니다`ps`.

**워크플로 다이어그램 형식**  
`dag` 보고서는의 확장명으로 선택된 여러 출력 형식을 지원합니다`dag.file`. HTML, Mermaid 및 DOT 형식은 Nextflow에서 직접 렌더링되며 추가 도구가 필요하지 않습니다. PDF, PNG 및 SVG 형식에는 HealthOmics의 Nextflow 엔진에 포함되지 않은 Graphviz가 필요합니다. `dag.file`이 PDF, PNG 또는 SVG 경로로 설정된 경우 Nextflow는 경고를 기록하고 워크플로 다이어그램을 `.dot` 소스 파일로 작성합니다. 실행은 여전히 성공적으로 완료됩니다. 경고`dag.file`를 방지하고 요청된 형식을 생성하려면 `.html`를 `.mmd`, 또는 `.dot` 경로로 설정하는 것이 좋습니다.

## Nextflow 구문 버전 지정
<a name="nextflow-syntax-version"></a>

Nextflow v26.04.0은 기본적으로 엄격한 (v2) 구문 구문 분석기를 사용합니다. 이는 Nextflow v25.10.0 이하의 기본값인 레거시(v1) 구문을 사용하여 작성된 워크플로에 대한 주요 변경 사항입니다. v2 구문에 대한 자세한 내용은 Seqera Nextflow 설명서의 [엄격한 구문](https://docs.seqera.io/nextflow/strict-syntax)을 참조하세요.

레거시(v1) 구문 분석기에 대해 작성된 워크플로를 실행하려면 **StartRun** 요청`v1`에서를 `engineSettings.syntaxVersion`로 설정합니다.

```
{
  "engineSettings": {
    "syntaxVersion": "v1"
  }
}
```

Nextflow v25.10.0 이하의 경우 HealthOmics는 v2 구문 분석기를 지원하지 않습니다.

## 워크플로 생성 중 자동 구문 검증
<a name="nextflow-automatic-validation"></a>

HealthOmics는 Nextflow DSL2 워크플로를 생성하거나 업데이트할 때 Nextflow 기본 제공 엄격한 DSL2 린터(nf-lang/v2)를 자동으로 실행합니다. 이 린터는 `CreateWorkflow` 및 중에 실행됩니다`CreateWorkflowVersion`. 지원되는 모든 DSL2 버전(v22.04, v23.10, v24.10, v25.10 및 v26.04)에 적용됩니다. DSL1 워크플로는 린트가 없습니다.

린터는 비차단 모드에서 작동합니다. 린트 조사 결과는 워크플로가 활성 상태가 되는 것을 막지 않습니다. 결과는 `GetWorkflow` 응답의 `statusMessage` 필드에 구조화된 JSON으로 표시됩니다.

**참고**  
내장 린터는 생성 시 워크플로 정의 구문을 검증합니다. 이는 런타임 동작에 의해 제어되고 영향을 미치는 Nextflow v26.04에 사용할 수 있는 엄격한 구문 *구문 분석기*`engineSettings.syntaxVersion`와 구별됩니다. 린터는 워크플로가 런타임에 사용하는 구문 분석기에 관계없이 생성 시 모든 DSL2 버전의 구문을 확인합니다. Nextflow v22.04, v23.10 및 v24.10(레거시 문법)에서는 결과가 권장 사항입니다. Nextflow v25.10 및 v26.04에서 결과는 엄격한 모드 구문 요구 사항을 반영합니다.

lint 출력 형식 및 조사 결과 해결 방법에 대한 자세한 내용은 섹션을 참조하세요[HealthOmics의 워크플로 린터](workflows-linter.md).

## Nextflow에서 스크래치 스토리지를 효율적으로 사용
<a name="nextflow-scratch-storage"></a>

Nextflow의 `scratch` 명령은 프로세스가 임시 작업 파일을 작성하는 위치를 제어합니다. 임시 스토리지가 활성화된 경우(`scratchStorageMode: LOCAL`) `scratch` 명령을 사용하여 스크래치 I/O를의 빠른 로컬 볼륨으로 보냅니다`/tmp`.

다음 표에서는 HealthOmics에서 지원되는 `scratch` 명령 값과 해당 동작을 설명합니다.


| 값 | HealthOmics의 동작 | 권장 사항 | 
| --- | --- | --- | 
| scratch true | $TMPDIR를 사용합니다. 가 scratchStorageMode이면 스크래치 I/O가 로컬 임시 볼륨으로 전달됩니다LOCAL. | 권장 | 
| scratch '/some/path' | 지정된 리터럴 경로를 스크래치 디렉터리로 사용합니다. 임시 스토리지를 사용하려면 경로를 /tmp 또는의 하위 디렉터리로 설정합니다/tmp. 경로는 컨테이너에 존재하고 쓰기 가능해야 합니다. | 경로가 아래에 있을 때 작동합니다. /tmp  | 
| scratch 'ram-disk' | 사용 시도/dev/shm(RAM의 tmpfs). HealthOmics의 로컬 스크래치 스토리지에는 권장되지 않습니다. | 권장되지 않음 | 

권장되는 접근 방식은를 자동으로 `$TMPDIR` 사용하고 경로 구성이 필요하지 않은 프로세스 정의`scratch true`에서를 설정하는 것입니다.

```
process my_process {
    scratch true
    disk '200 GB'
    script:
    """
    my-tool --input ${input} --output ${output}
    """
}
```

임시 스토리지 및 `disk` 명령에 대한 자세한 내용은 섹션을 참조하세요[HealthOmics 워크플로 작업을 위한 임시 스토리지](workflows-ephemeral-storage.md).