파트 6: Hello Config¶

AI 지원 번역 - 자세히 알아보기 및 개선 제안

이 섹션에서는 workflow 코드 자체를 한 줄도 변경하지 않고 동작을 사용자 정의하고, 다른 환경에 적응시키며, 리소스 사용을 최적화할 수 있도록 Nextflow 파이프라인의 구성을 설정하고 관리하는 방법을 탐색합니다.

이를 수행하는 여러 방법이 있으며, 조합하여 사용할 수 있고 여기에 설명된 우선순위에 따라 해석됩니다.

이 파트에서는 파트 5: Hello Containers에서 이미 접한 가장 간단하고 일반적인 구성 파일 메커니즘인 nextflow.config 파일을 보여드릴 것입니다.

Process 지시문, 실행자, 프로필 및 매개변수 파일과 같은 Nextflow 구성의 필수 구성 요소를 살펴볼 것입니다. 이러한 구성 옵션을 효과적으로 활용하는 방법을 배우면 파이프라인의 유연성, 확장성 및 성능을 향상시킬 수 있습니다.

이 섹션부터 시작하는 방법

이 섹션은 Hello Nextflow 과정의 파트 1-5를 완료하고 완전히 작동하는 파이프라인이 있다고 가정합니다.

이 시점부터 과정을 시작하는 경우 solutions에서 modules 디렉토리와 nextflow.config 파일을 복사해야 합니다:

cp -r solutions/5-hello-containers/modules .
cp solutions/5-hello-containers/nextflow.config .

nextflow.config 파일에는 Docker 컨테이너 사용을 활성화하는 docker.enabled = true 줄이 포함되어 있습니다.

Hello 파이프라인에 익숙하지 않거나 상기가 필요하면 이 정보 페이지를 참조하십시오.

0. 워밍업: `hello-config.nf` 실행¶

시작점으로 workflow 스크립트 hello-config.nf를 사용할 것입니다. 이 스크립트는 이 교육 과정의 파트 5를 완료하여 생성된 스크립트와 동일하지만, 출력 대상을 변경했습니다:

hello-config.nf
output {
    first_output {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    uppercased {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    collected {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    batch_report {
        path 'hello_config'
        mode 'copy'
    }
    cowpy_art {
        path 'hello_config'
        mode 'copy'
    }
}

변경을 시작하기 전에 모든 것이 제대로 작동하는지 확인하기 위해 스크립트를 한 번 실행하십시오:

nextflow run hello-config.nf

명령 출력

 N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [nice_escher] DSL2 - revision: d5dfdc9872

executor > local (7)
[6a/bc46a6] sayHello (2) [100%] 3 of 3 ✔
[33/67bc48] convertToUpper (3) [100%] 3 of 3 ✔
[b5/de03ba] collectGreetings [100%] 1 of 1 ✔
[98/c6b57b] cowpy              | 1 of 1 ✔

이전과 마찬가지로 output 블록에 지정된 디렉토리(results/hello_config/)에서 출력 파일을 찾을 수 있습니다.

디렉토리 내용

results/hello_config/
├── cowpy-COLLECTED-batch-output.txt
├── intermediates
│   ├── Bonjour-output.txt
│   ├── COLLECTED-batch-output.txt
│   ├── Hello-output.txt
│   ├── Holà-output.txt
│   ├── UPPER-Bonjour-output.txt
│   ├── UPPER-Hello-output.txt
│   └── UPPER-Holà-output.txt
└── batch-report.txt

최종 ASCII 아트 출력은 results/hello_config/ 디렉토리에 cowpy-COLLECTED-batch-output.txt라는 이름으로 있습니다.

파일 내용

results/hello_config/cowpy-COLLECTED-batch-output.txt

_________
/ HOLà    \
| HELLO   |
\ BONJOUR /
---------
  \                                  ,+*^^*+___+++_
  \                           ,*^^^^              )
    \                       _+*                     ^**+_
    \                    +^       _ _++*+_+++_,         )
              _+^^*+_    (     ,+*^ ^          \+_        )
            {       )  (    ,(    ,_+--+--,      ^)      ^\
            { (\@)    } f   ,(  ,+-^ __*_*_  ^^\_   ^\       )
          {:;-/    (_+*-+^^^^^+*+*<_ _++_)_    )    )      /
          ( /  (    (        ,___    ^*+_+* )   <    <      \
          U _/     )    *--<  ) ^\-----++__)   )    )       )
            (      )  _(^)^^))  )  )\^^^^^))^*+/    /       /
          (      /  (_))_^)) )  )  ))^^^^^))^^^)__/     +^^
        (     ,/    (^))^))  )  ) ))^^^^^^^))^^)       _)
          *+__+*       (_))^)  ) ) ))^^^^^^))^^^^^)____*^
          \             \_)^)_)) ))^^^^^^^^^^))^^^^)
          (_             ^\__^^^^^^^^^^^^))^^^^^^^)
            ^\___            ^\__^^^^^^))^^^^^^^^)\\
                  ^^^^^\uuu/^^\uuu/^^^^\^\^\^\^\^\^\^\
                    ___) >____) >___   ^\_\_\_\_\_\_\)
                    ^^^//\\_^^//\\_^       ^(\_\_\_\)
                      ^^^ ^^ ^^^ ^

이것이 정상적으로 작동했다면 파이프라인을 구성하는 방법을 배울 준비가 되었습니다.

1. Workflow 입력 매개변수 관리¶

지금까지 작업해 온 것의 확장인 구성의 한 측면부터 시작할 것입니다: 입력 매개변수의 관리입니다.

현재 workflow는 명령줄을 통해 여러 매개변수 값을 허용하도록 설정되어 있으며, 기본값은 workflow 스크립트 자체의 params 블록에 설정되어 있습니다. 그러나 명령줄에서 매개변수를 지정하거나 원본 스크립트 파일을 수정하지 않고 해당 기본값을 재정의하고 싶을 수 있습니다.

이를 수행하는 여러 방법이 있습니다; 매우 일반적으로 사용되는 세 가지 기본 방법을 보여드리겠습니다.

1.1. 기본값을 `nextflow.config`로 이동¶

이것은 가장 간단한 접근 방식이지만, 실행할 때마다 편집하고 싶지 않은 기본 nextflow.config 파일이므로 아마도 가장 유연하지 않습니다. 그러나 workflow에서 매개변수를 선언하는 것(확실히 거기에 속함)과 구성 파일에 더 적합한 기본값을 제공하는 것의 관심사를 분리하는 이점이 있습니다.

두 단계로 수행해 봅시다.

1.1.1. 구성 파일에 `params` 블록 생성¶

nextflow.config 파일에서 다음 코드 변경을 수행하십시오:

수정 후수정 전

nextflow.config
docker.enabled = true

/*
* 파이프라인 매개변수
*/
params {
    input = 'data/greetings.csv'
    batch = 'batch'
    character = 'turkey'
}

nextflow.config
docker.enabled = true

workflow에서 구성 파일로 params 블록을 단순히 복사한 것이 아닙니다. 구문이 약간 다릅니다. Workflow 파일에서는 타입이 지정된 선언입니다. 구성에서는 값 할당입니다.

기술적으로 이것만으로도 workflow 파일에 여전히 지정된 기본값을 재정의하기에 충분합니다. 예를 들어 캐릭터를 수정하고 workflow를 실행하여 구성 파일에 설정된 값이 workflow 파일에 설정된 값을 재정의하는지 확인할 수 있습니다.

그러나 구성을 완전히 구성 파일로 이동하는 정신으로, workflow 파일에서 해당 값을 완전히 제거합시다.

1.1.2. Workflow 파일의 `params` 블록에서 값 제거¶

hello-config.nf workflow 파일에서 다음 코드 변경을 수행하십시오:

수정 후수정 전

hello-config.nf
/*
* 파이프라인 매개변수
*/
params {
    input: Path
    batch: String
    character: String
}

hello-config.nf
/*
* 파이프라인 매개변수
*/
params {
    input: Path = 'data/greetings.csv'
    batch: String = 'batch'
    character: String = 'turkey'
}

이제 workflow 파일 자체는 이러한 매개변수에 대한 기본값을 설정하지 않습니다.

1.1.3. 파이프라인 실행¶

올바르게 작동하는지 테스트해 봅시다.

nextflow run hello-config.nf

명령 출력

N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [disturbed_einstein] DSL2 - revision: ede9037d02

executor >  local (8)
[f0/35723c] sayHello (2)       | 3 of 3 ✔
[40/3efd1a] convertToUpper (3) | 3 of 3 ✔
[17/e97d32] collectGreetings   | 1 of 1 ✔
[98/c6b57b] cowpy              | 1 of 1 ✔

이것은 이전과 동일한 출력을 생성합니다.

최종 ASCII 아트 출력은 이전과 마찬가지로 results/hello_config/ 디렉토리에 cowpy-COLLECTED-batch-output.txt라는 이름으로 있습니다.

파일 내용

results/hello_config/cowpy-COLLECTED-batch-output.txt

_________
/ HOLà    \
| HELLO   |
\ BONJOUR /
---------
  \                                  ,+*^^*+___+++_
  \                           ,*^^^^              )
    \                       _+*                     ^**+_
    \                    +^       _ _++*+_+++_,         )
              _+^^*+_    (     ,+*^ ^          \+_        )
            {       )  (    ,(    ,_+--+--,      ^)      ^\
            { (\@)    } f   ,(  ,+-^ __*_*_  ^^\_   ^\       )
          {:;-/    (_+*-+^^^^^+*+*<_ _++_)_    )    )      /
          ( /  (    (        ,___    ^*+_+* )   <    <      \
          U _/     )    *--<  ) ^\-----++__)   )    )       )
            (      )  _(^)^^))  )  )\^^^^^))^*+/    /       /
          (      /  (_))_^)) )  )  ))^^^^^))^^^)__/     +^^
        (     ,/    (^))^))  )  ) ))^^^^^^^))^^)       _)
          *+__+*       (_))^)  ) ) ))^^^^^^))^^^^^)____*^
          \             \_)^)_)) ))^^^^^^^^^^))^^^^)
          (_             ^\__^^^^^^^^^^^^))^^^^^^^)
            ^\___            ^\__^^^^^^))^^^^^^^^)\\
                  ^^^^^\uuu/^^\uuu/^^^^\^\^\^\^\^\^\^\
                    ___) >____) >___   ^\_\_\_\_\_\_\)
                    ^^^//\\_^^//\\_^       ^(\_\_\_\)
                      ^^^ ^^ ^^^ ^

기능적으로 이 이동은 아무것도 변경하지 않았지만, 개념적으로 구성 파일에 기본값을 설정하는 것이 약간 더 깔끔합니다.

1.2. 실행별 구성 파일 사용¶

좋습니다만, 때때로 메인 구성 파일을 건드리지 않고 다른 기본값으로 일부 임시 실험을 실행하고 싶을 수 있습니다. 실험을 위한 작업 디렉토리로 사용할 하위 디렉토리에 새 nextflow.config 파일을 생성하여 이를 수행할 수 있습니다.

1.2.1. 빈 구성으로 작업 디렉토리 생성¶

새 디렉토리를 생성하고 그곳으로 이동하는 것으로 시작합시다:

mkdir -p tux-run
cd tux-run

그런 다음 해당 디렉토리에 빈 구성 파일을 생성합니다:

touch nextflow.config

이렇게 하면 빈 파일이 생성됩니다.

1.2.2. 실험 구성 설정¶

이제 새 파일을 열고 사용자 정의하려는 매개변수를 추가하십시오:

tux-run/nextflow.config
params {
    input = '../data/greetings.csv'
    batch = 'experiment'
    character = 'tux'
}

입력 파일 경로는 디렉토리 구조를 반영해야 합니다.

1.2.3. 파이프라인 실행¶

이제 새 작업 디렉토리 내에서 파이프라인을 실행할 수 있습니다. 경로를 적절하게 조정해야 합니다!

nextflow run ../hello-config.nf

명령 출력

N E X T F L O W   ~  version 25.10.2

Launching `../hello-config.nf` [trusting_escher] DSL2 - revision: 356df0818d

executor >  local (8)
[59/b66913] sayHello (2)       [100%] 3 of 3 ✔
[ad/f06364] convertToUpper (3) [100%] 3 of 3 ✔
[10/714895] collectGreetings   [100%] 1 of 1 ✔
[88/3ece98] cowpy              [100%] 1 of 1 ✔

이렇게 하면 tux-run/work/ 및 tux-run/results/를 포함하여 tux-run/ 아래에 새 디렉토리 세트가 생성됩니다.

이 실행에서 Nextflow는 현재 디렉토리의 nextflow.config를 파이프라인 루트 디렉토리의 nextflow.config와 결합하여 기본 캐릭터(칠면조)를 tux 캐릭터로 재정의합니다.

최종 출력 파일에는 인사말을 말하는 tux 캐릭터가 포함되어야 합니다.

파일 내용

tux-run/results/hello_config/cowpy-COLLECTED-experiment-output.txt

_________
/ HELLO   \
| BONJOUR |
\ HOLà    /
---------
  \
    \
        .--.
      |o_o |
      |:_/ |
      //   \ \
    (|     | )
    /'\_   _/`\
    \___)=(___/

이제 '정상적인' 구성을 수정하지 않고 실험할 공간이 생겼습니다.

경고

다음 섹션으로 이동하기 전에 이전 디렉토리로 다시 변경해야 합니다!

cd ..

이제 매개변수 값을 설정하는 또 다른 유용한 방법을 살펴봅시다.

1.3. 매개변수 파일 사용¶

하위 디렉토리 접근 방식은 실험에 적합하지만, 약간의 설정이 필요하고 그에 따라 경로를 조정해야 합니다. 특정 값 세트로 파이프라인을 실행하거나 다른 사람이 최소한의 노력으로 실행할 수 있도록 하려는 경우 더 간단한 접근 방식이 있습니다.

Nextflow를 사용하면 YAML 또는 JSON 형식의 매개변수 파일을 통해 매개변수를 지정할 수 있으므로, 예를 들어 대체 기본값 세트와 실행별 매개변수 값을 관리하고 배포하는 것이 매우 편리합니다.

1.3.1. 예제 매개변수 파일 검사¶

이를 시연하기 위해 현재 디렉토리에 test-params.yaml이라는 예제 매개변수 파일을 제공합니다:

test-params.yaml
{
  input: "greetings.csv"
  batch: "yaml"
  character: "stegosaurus"
}

이 매개변수 파일에는 지정하려는 각 입력에 대한 키-값 쌍이 포함되어 있습니다. 구문을 구성 파일과 비교하면 등호(=) 대신 콜론(:)을 사용합니다. 구성 파일은 Groovy로 작성되고, 매개변수 파일은 YAML로 작성됩니다.

정보

예제로 매개변수 파일의 JSON 버전도 제공하지만 여기서는 실행하지 않을 것입니다. 직접 시도해 보십시오.

1.3.2. 파이프라인 실행¶

이 매개변수 파일로 workflow를 실행하려면 기본 명령에 -params-file <filename>을 추가하기만 하면 됩니다.

nextflow run hello-config.nf -params-file test-params.yaml

명령 출력

N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [disturbed_sammet] DSL2 - revision: ede9037d02

executor >  local (8)
[f0/35723c] sayHello (2)       | 3 of 3 ✔
[40/3efd1a] convertToUpper (3) | 3 of 3 ✔
[17/e97d32] collectGreetings   | 1 of 1 ✔
[98/c6b57b] cowpy              | 1 of 1 ✔

최종 출력 파일에는 인사말을 말하는 스테고사우루스 캐릭터가 포함되어야 합니다.

파일 내용

results/hello_config/cowpy-COLLECTED-yaml-output.txt

_________
/ HELLO   \
| HOLà    |
\ BONJOUR /
---------
\                             .       .
\                           / `.   .' "
  \                  .---.  <    > <    >  .---.
  \                 |    \  \ - ~ ~ - /  /    |
        _____          ..-~             ~-..-~
        |     |   \~~~\.'                    `./~~~/
      ---------   \__/                        \__/
      .'  O    \     /               /       \  "
    (_____,    `._.'               |         }  \/~~~/
      `----.          /       }     |        /    \__/
            `-.      |       /      |       /      `. ,~~|
                ~-.__|      /_ - ~ ^|      /- _      `..-'
                    |     /        |     /     ~-.     `-. _  _  _
                    |_____|        |_____|         ~ - . _ _ _ _ _>

몇 개의 매개변수만 지정해야 할 때 매개변수 파일을 사용하는 것은 과도해 보일 수 있지만, 일부 파이프라인은 수십 개의 매개변수를 예상합니다. 그런 경우 매개변수 파일을 사용하면 방대한 명령줄을 입력하거나 workflow 스크립트를 수정하지 않고도 런타임에 매개변수 값을 제공할 수 있습니다.

또한 예를 들어 공동 작업자에게 매개변수 세트를 배포하거나 출판물의 보충 정보로 제공하는 것이 더 쉬워집니다. 이렇게 하면 다른 사람들이 작업을 더 재현할 수 있습니다.

핵심 내용¶

Workflow 입력 관리를 위한 주요 구성 옵션을 활용하는 방법을 알게 되었습니다.

다음 단계¶

Workflow 출력이 게시되는 위치와 방법을 관리하는 방법을 배웁니다.

2. Workflow 출력 관리¶

지금까지 workflow 수준 출력 선언에 대한 모든 경로를 하드코딩해 왔으며, 여러 출력을 추가하기 시작할 때 언급했듯이 약간의 반복이 있을 수 있습니다.

이를 더 유연하게 구성할 수 있는 몇 가지 일반적인 방법을 살펴봅시다.

2.1. `outputDir` 디렉토리 이름 사용자 정의¶

이 과정의 각 장에서 출력 정의에 하드코딩된 다른 하위 디렉토리에 출력을 게시해 왔습니다.

사용자 구성 가능한 매개변수를 사용하도록 변경합시다. 이를 위해 완전히 새로운 매개변수를 만들 수 있지만, 바로 거기에 있으므로 batch 매개변수를 사용합시다.

2.1.1. 구성 파일에서 `outputDir` 값 설정¶

Nextflow가 출력을 게시하는 데 사용하는 경로는 outputDir 옵션으로 제어됩니다. 모든 출력의 경로를 변경하려면 nextflow.config 구성 파일에서 이 옵션에 대한 값을 설정할 수 있습니다.

nextflow.config 파일에 다음 코드를 추가하십시오:

수정 후수정 전

nextflow.config
/*
* 파이프라인 매개변수
*/
params {
    input = 'data/greetings.csv'
    batch = 'batch'
    character = 'turkey'
}

/*
* 출력 설정
*/
outputDir = "results/${params.batch}"

nextflow.config
/*
* 파이프라인 매개변수
*/
params {
    input = 'data/greetings.csv'
    batch = 'batch'
    character = 'turkey'
}

이렇게 하면 내장 기본 경로인 results/가 results/ 더하기 하위 디렉토리로서 batch 매개변수 값으로 대체됩니다. 원한다면 results 부분도 변경할 수 있습니다.

임시 변경의 경우 명령에서 -output-dir 매개변수를 사용하여 명령줄에서 이 옵션을 설정할 수 있습니다(하지만 그러면 batch 매개변수 값을 사용할 수 없습니다).

2.1.2. 하드코딩된 경로의 반복되는 부분 제거¶

출력 옵션에 여전히 하드코딩된 하위 디렉토리가 있으므로 이제 제거합시다.

workflow 파일에서 다음 코드 변경을 수행하십시오:

수정 후수정 전

hello-config.nf
output {
    first_output {
        path 'intermediates'
        mode 'copy'
    }
    uppercased {
        path 'intermediates'
        mode 'copy'
    }
    collected {
        path 'intermediates'
        mode 'copy'
    }
    batch_report {
        path ''
        mode 'copy'
    }
    cowpy_art {
        path ''
        mode 'copy'
    }
}

hello-config.nf
output {
    first_output {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    uppercased {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    collected {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    batch_report {
        path 'hello_config'
        mode 'copy'
    }
    cowpy_art {
        path 'hello_config'
        mode 'copy'
    }
}

outputDir 기본값을 수정하는 대신 각 경로에 ${params.batch}를 추가할 수도 있었지만 이것이 더 간결합니다.

2.1.3. 파이프라인 실행¶

올바르게 작동하는지 테스트해 봅시다. 명령줄에서 배치 이름을 outdir로 설정합니다.

nextflow run hello-config.nf --batch outdir

명령 출력

N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [disturbed_einstein] DSL2 - revision: ede9037d02

executor >  local (8)
[f0/35723c] sayHello (2)       | 3 of 3 ✔
[40/3efd1a] convertToUpper (3) | 3 of 3 ✔
[17/e97d32] collectGreetings   | 1 of 1 ✔
[98/c6b57b] cowpy              | 1 of 1 ✔

이것은 이전과 동일한 출력을 생성하지만, 이번에는 results/outdir/ 아래에서 출력을 찾습니다.

디렉토리 내용

results/outdir/
├── cowpy-COLLECTED-outdir-output.txt
├── intermediates
│   ├── Bonjour-output.txt
│   ├── COLLECTED-outdir-output.txt
│   ├── Hello-output.txt
│   ├── Holà-output.txt
│   ├── UPPER-Bonjour-output.txt
│   ├── UPPER-Hello-output.txt
│   └── UPPER-Holà-output.txt
└── outdir-report.txt

이 접근 방식을 사용자 정의 경로 정의와 결합하여 원하는 디렉토리 계층을 구성할 수 있습니다.

2.2. Process별로 출력 구성¶

출력을 추가로 구성하는 인기 있는 방법 중 하나는 process별로 수행하는 것입니다. 즉, 파이프라인에서 실행되는 각 process에 대해 하위 디렉토리를 만드는 것입니다.

2.2.1. 출력 경로를 process 이름에 대한 참조로 교체¶

출력 경로 선언에서 process 이름을 <task>.name으로 참조하기만 하면 됩니다.

workflow 파일에서 다음 변경을 수행하십시오:

수정 후수정 전

hello-config.nf
output {
    first_output {
        path { sayHello.name }
        mode 'copy'
    }
    uppercased {
        path { convertToUpper.name }
        mode 'copy'
    }
    collected {
        path { collectGreetings.name }
        mode 'copy'
    }
    batch_report {
        path { collectGreetings.name }
        mode 'copy'
    }
    cowpy_art {
        path { cowpy.name }
        mode 'copy'
    }
}

hello-config.nf
output {
    first_output {
        path 'intermediates'
        mode 'copy'
    }
    uppercased {
        path 'intermediates'
        mode 'copy'
    }
    collected {
        path 'intermediates'
        mode 'copy'
    }
    batch_report {
        path ''
        mode 'copy'
    }
    cowpy_art {
        path ''
        mode 'copy'
    }
}

이렇게 하면 출력 경로 구성에서 남은 하드코딩된 요소가 제거됩니다.

2.2.2. 파이프라인 실행¶

올바르게 작동하는지 테스트해 봅시다. 명령줄에서 배치 이름을 pnames로 설정합니다.

nextflow run hello-config.nf --batch pnames

명령 출력

N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [jovial_mcclintock] DSL2 - revision: ede9037d02

executor >  local (8)
[f0/35723c] sayHello (2)       | 3 of 3 ✔
[40/3efd1a] convertToUpper (3) | 3 of 3 ✔
[17/e97d32] collectGreetings   | 1 of 1 ✔
[98/c6b57b] cowpy              | 1 of 1 ✔

이것은 이전과 동일한 출력을 생성하지만, 이번에는 results/pnames/ 아래에서 출력을 찾고 process별로 그룹화되어 있습니다.

디렉토리 내용

results/pnames/
├── collectGreetings
│   ├── COLLECTED-pnames-output.txt
│   └── pnames-report.txt
├── convertToUpper
│   ├── UPPER-Bonjour-output.txt
│   ├── UPPER-Hello-output.txt
│   └── UPPER-Holà-output.txt
├── cowpy
│   └── cowpy-COLLECTED-pnames-output.txt
└── sayHello
    ├── Bonjour-output.txt
    ├── Hello-output.txt
    └── Holà-output.txt

여기서 intermediates와 최상위 수준의 최종 출력 간의 구분이 지워졌습니다. 물론 이러한 접근 방식을 혼합하여 예를 들어 첫 번째 출력의 경로를 intermediates/${sayHello.process}로 설정할 수 있습니다.

2.3. Workflow 수준에서 게시 모드 설정¶

마지막으로, 반복적인 코드의 양을 줄이는 정신으로 출력별 mode 선언을 구성의 단일 줄로 대체할 수 있습니다.

2.3.1. 구성 파일에 `workflow.output.mode` 추가¶

nextflow.config 파일에 다음 코드를 추가하십시오:

수정 후수정 전

nextflow.config
/*
* 출력 설정
*/
outputDir = "results/${params.batch}"
workflow.output.mode = 'copy'

nextflow.config
/*
* 출력 설정
*/
outputDir = "results/${params.batch}"

outputDir 옵션과 마찬가지로, 구성 파일에서 workflow.output.mode에 값을 지정하면 workflow 파일에 설정된 것을 재정의하기에 충분하지만, 불필요한 코드를 어쨌든 제거합시다.

2.3.2. Workflow 파일에서 출력 모드 제거¶

workflow 파일에서 다음 변경을 수행하십시오:

수정 후수정 전

hello-config.nf
output {
    first_output {
        path { sayHello.process }
    }
    uppercased {
        path { convertToUpper.process }
    }
    collected {
        path { collectGreetings.process }
    }
    batch_report {
        path { collectGreetings.process }
    }
    cowpy_art {
        path { cowpy.process }
    }
}

hello-config.nf
output {
    first_output {
        path { sayHello.process }
        mode 'copy'
    }
    uppercased {
        path { convertToUpper.process }
        mode 'copy'
    }
    collected {
        path { collectGreetings.process }
        mode 'copy'
    }
    batch_report {
        path { collectGreetings.process }
        mode 'copy'
    }
    cowpy_art {
        path { cowpy.process }
        mode 'copy'
    }
}

더 간결하지 않습니까?

2.3.3. 파이프라인 실행¶

올바르게 작동하는지 테스트해 봅시다. 명령줄에서 배치 이름을 outmode로 설정합니다.

nextflow run hello-config.nf --batch outmode

명령 출력

N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [rowdy_sagan] DSL2 - revision: ede9037d02

executor >  local (8)
[f0/35723c] sayHello (2)       | 3 of 3 ✔
[40/3efd1a] convertToUpper (3) | 3 of 3 ✔
[17/e97d32] collectGreetings   | 1 of 1 ✔
[98/c6b57b] cowpy              | 1 of 1 ✔

이것은 이전과 동일한 출력을 생성하지만, 이번에는 results/outmode/ 아래에서 출력을 찾습니다. 여전히 심볼릭 링크가 아닌 적절한 복사본입니다.

디렉토리 내용

results/outmode/
├── collectGreetings
│   ├── COLLECTED-outmode-output.txt
│   └── outmode-report.txt
├── convertToUpper
│   ├── UPPER-Bonjour-output.txt
│   ├── UPPER-Hello-output.txt
│   └── UPPER-Holà-output.txt
├── cowpy
│   └── cowpy-COLLECTED-outmode-output.txt
└── sayHello
    ├── Bonjour-output.txt
    ├── Hello-output.txt
    └── Holà-output.txt

출력별 모드 설정 방식을 여전히 사용하려는 주된 이유는 동일한 workflow 내에서 혼합하고 싶은 경우입니다. 즉, 일부 출력은 복사하고 일부는 심볼릭 링크로 설정합니다.

이 방식으로 사용자 정의할 수 있는 다른 옵션도 많이 있지만, 이를 통해 옵션의 범위와 선호도에 맞게 효과적으로 활용하는 방법에 대한 감각을 얻을 수 있기를 바랍니다.

핵심 내용¶

출력이 게시되는 디렉토리의 이름 지정 및 구조와 workflow 출력 게시 모드를 제어하는 방법을 알게 되었습니다.

다음 단계¶

소프트웨어 패키징 기술부터 시작하여 컴퓨팅 환경에 workflow 구성을 적응시키는 방법을 배웁니다.

3. 소프트웨어 패키징 기술 선택¶

지금까지 입력이 어떻게 들어가고 출력이 어디에서 나오는지를 제어하는 구성 요소를 살펴보았습니다. 이제 컴퓨팅 환경에 workflow 구성을 적응시키는 데 더 구체적으로 집중할 때입니다.

그 경로의 첫 번째 단계는 각 단계에서 실행될 소프트웨어 패키지가 어디에서 오는지 지정하는 것입니다. 로컬 컴퓨팅 환경에 이미 설치되어 있습니까? 이미지를 검색하고 컨테이너 시스템을 통해 실행해야 합니까? 아니면 Conda 패키지를 검색하고 로컬 Conda 환경을 빌드해야 합니까?

이 교육 과정의 첫 번째 부분(파트 1-4)에서는 workflow에서 로컬로 설치된 소프트웨어만 사용했습니다. 그런 다음 파트 5에서 Docker 컨테이너와 nextflow.config 파일을 도입하여 Docker 컨테이너 사용을 활성화했습니다.

이제 nextflow.config 파일을 통해 대체 소프트웨어 패키징 옵션을 구성하는 방법을 살펴봅시다.

3.1. 구성 파일에서 Docker 비활성화 및 Conda 활성화¶

보안상의 이유로 관리자가 Docker 사용을 허용하지 않는 HPC 클러스터에서 작업한다고 가정해 봅시다. 다행히도 Nextflow는 Singularity(HPC에서 더 널리 사용됨)를 포함한 여러 다른 컨테이너 기술과 Conda와 같은 소프트웨어 패키지 관리자를 지원합니다.

Docker 대신 Conda를 사용하도록 구성 파일을 변경할 수 있습니다. 그렇게 하려면 docker.enabled 값을 false로 전환하고 Conda 사용을 활성화하는 지시문을 추가합시다:

수정 후수정 전

nextflow.config
docker.enabled = false
conda.enabled = true

nextflow.config
docker.enabled = true

이렇게 하면 Nextflow가 Conda 패키지가 지정된 process에 대해 Conda 환경을 생성하고 활용할 수 있습니다. 즉, 이제 cowpy process에 그 중 하나를 추가해야 합니다!

3.2. Process 정의에서 Conda 패키지 지정¶

cowpy 도구가 포함된 Conda 패키지의 URI를 이미 검색했습니다: conda-forge::cowpy==1.1.5

이제 conda 지시문을 사용하여 cowpy process 정의에 URI를 추가합니다:

수정 후수정 전

modules/cowpy.nf
process cowpy {

    container 'community.wave.seqera.io/library/cowpy:1.1.5--3db457ae1977a273'
    conda 'conda-forge::cowpy==1.1.5'

    input:

modules/cowpy.nf
process cowpy {

    container 'community.wave.seqera.io/library/cowpy:1.1.5--3db457ae1977a273'

    input:

명확히 하자면, docker 지시문을 교체하는 것이 아니라 대체 옵션을 추가하는 것입니다.

팁

주어진 conda 패키지에 대한 URI를 얻는 몇 가지 다른 방법이 있습니다. 컨테이너를 생성할 계획이 없더라도 복사하여 붙여넣을 수 있는 URI를 제공하는 Seqera Containers 검색 쿼리를 사용하는 것이 좋습니다.

3.3. Workflow를 실행하여 Conda를 사용할 수 있는지 확인¶

시도해 봅시다.

nextflow run hello-config.nf --batch conda

명령 출력

출력

N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [trusting_lovelace] DSL2 - revision: 028a841db1

executor >  local (8)
[ee/4ca1f2] sayHello (3)       | 3 of 3 ✔
[20/2596a7] convertToUpper (1) | 3 of 3 ✔
[b3/e15de5] collectGreetings   | 1 of 1 ✔
[c5/af5f88] cowpy              | 1 of 1 ✔

이것은 문제 없이 작동하고 results/conda 아래에 이전과 동일한 출력을 생성해야 합니다.

백그라운드에서 Nextflow는 Conda 패키지를 검색하고 환경을 생성했으며, 이는 일반적으로 약간의 작업이 필요합니다; 그래서 우리가 직접 그 작업을 하지 않아도 되니 좋습니다!

참고

cowpy 패키지가 상당히 작기 때문에 빠르게 실행되지만, 큰 패키지로 작업하는 경우 처음에는 평소보다 약간 더 오래 걸릴 수 있으며, 콘솔 출력이 완료되기 전에 1분 정도 '멈춰' 있는 것처럼 보일 수 있습니다. 이것은 정상이며 새 패키지를 처음 사용할 때 Nextflow가 수행하는 추가 작업 때문입니다.

우리 관점에서 보면 백엔드의 메커니즘이 약간 다르더라도 Docker로 실행하는 것과 정확히 동일하게 작동하는 것 같습니다.

이것은 필요한 경우 Conda 환경으로 실행할 준비가 되었음을 의미합니다.

Docker와 Conda 혼합 사용

이러한 지시문은 process별로 할당되므로 '혼합 사용'이 가능합니다. 즉, 사용 중인 컴퓨팅 인프라가 둘 다 지원하는 경우 예를 들어 workflow의 일부 process는 Docker로 실행하고 다른 process는 Conda로 실행하도록 구성할 수 있습니다. 이 경우 구성 파일에서 Docker와 Conda를 모두 활성화합니다. 주어진 process에 대해 둘 다 사용 가능한 경우 Nextflow는 컨테이너를 우선시합니다.

앞서 언급했듯이 Nextflow는 여러 다른 소프트웨어 패키징 및 컨테이너 기술을 지원하므로 이 두 가지에만 국한되지 않습니다.

핵심 내용¶

각 process가 사용해야 하는 소프트웨어 패키지를 구성하는 방법과 기술 간 전환 방법을 알게 되었습니다.

다음 단계¶

Nextflow가 실제로 작업을 수행하는 데 사용하는 실행 플랫폼을 변경하는 방법을 배웁니다.

4. 실행 플랫폼 선택¶

지금까지 로컬 실행자로 파이프라인을 실행해 왔습니다. 이것은 Nextflow가 실행 중인 머신에서 각 작업을 실행합니다. Nextflow가 시작되면 사용 가능한 CPU와 메모리를 확인합니다. 실행할 준비가 된 작업의 리소스가 사용 가능한 리소스를 초과하면 Nextflow는 하나 이상의 이전 작업이 완료되어 필요한 리소스가 확보될 때까지 마지막 작업을 실행에서 보류합니다.

로컬 실행자는 편리하고 효율적이지만 해당 단일 머신으로 제한됩니다. 매우 큰 워크로드의 경우 사용 가능한 것보다 더 많은 리소스가 필요한 단일 작업이 있거나 단일 머신에서 실행하기를 기다리는 데 너무 오래 걸릴 정도로 많은 작업이 있어 로컬 머신이 병목 현상을 일으키는 것을 발견할 수 있습니다.

Nextflow는 HPC 스케줄러(Slurm, LSF, SGE, PBS, Moab, OAR, Bridge, HTCondor 등)뿐만 아니라 클라우드 실행 백엔드(AWS Batch, Google Cloud Batch, Azure Batch, Kubernetes 등)를 포함한 많은 다른 실행 백엔드를 지원합니다.

4.1. 다른 백엔드 대상 지정¶

실행자 선택은 executor라는 process 지시문으로 설정됩니다. 기본적으로 local로 설정되어 있으므로 다음 구성이 암시됩니다:

내장 구성

process {
    executor = 'local'
}

다른 백엔드를 대상으로 하도록 실행자를 설정하려면 리소스 할당에 대해 위에서 설명한 것과 유사한 구문을 사용하여 원하는 실행자를 지정하기만 하면 됩니다(모든 옵션에 대해서는 문서 참조).

nextflow.config

process {
    executor = 'slurm'
}

경고

HPC에 연결하도록 설정되지 않았기 때문에 교육 환경에서 이것을 실제로 테스트할 수 없습니다.

4.2. 실행 매개변수에 대한 백엔드별 구문 처리¶

대부분의 고성능 컴퓨팅 플랫폼은 리소스 할당 요청 및 제한(예: CPU 수 및 메모리) 및 사용할 작업 큐의 이름과 같은 특정 매개변수를 지정할 수 있도록 허용하고 때로는 요구합니다.

불행히도 이러한 각 시스템은 작업이 정의되고 관련 스케줄러에 제출되는 방법을 정의하는 데 다른 기술, 구문 및 구성을 사용합니다.

예제

예를 들어, "my-science-work" 큐에서 8개의 CPU와 4GB의 RAM이 필요한 동일한 작업은 백엔드에 따라 다른 방식으로 표현해야 합니다.

SLURM 구성 / sbatch를 사용하여 제출

#SBATCH -o /path/to/my/task/directory/my-task-1.log
#SBATCH --no-requeue
#SBATCH -c 8
#SBATCH --mem 4096M
#SBATCH -p my-science-work

PBS 구성 / qsub을 사용하여 제출

#PBS -o /path/to/my/task/directory/my-task-1.log
#PBS -j oe
#PBS -q my-science-work
#PBS -l nodes=1:ppn=5
#PBS -l mem=4gb

SGE 구성 / qsub을 사용하여 제출

#$ -o /path/to/my/task/directory/my-task-1.log
#$ -j y
#$ -terse
#$ -notify
#$ -q my-science-work
#$ -l slots=5
#$ -l h_rss=4096M,mem_free=4096M

다행히도 Nextflow는 이 모든 것을 단순화합니다. cpus, memory 및 queue(다른 속성은 문서 참조)와 같은 관련 속성을 한 번만 지정할 수 있도록 표준화된 구문을 제공합니다. 그런 다음 런타임에 Nextflow는 해당 설정을 사용하여 실행자 설정에 따라 적절한 백엔드별 스크립트를 생성합니다.

다음 섹션에서 해당 표준화된 구문을 다룰 것입니다.

핵심 내용¶

이제 다른 종류의 컴퓨팅 인프라를 사용하도록 실행자를 변경하는 방법을 알게 되었습니다.

다음 단계¶

Nextflow에서 리소스 할당 및 제한을 평가하고 표현하는 방법을 배웁니다.

5. 컴퓨팅 리소스 할당 제어¶

대부분의 고성능 컴퓨팅 플랫폼은 CPU 수 및 메모리와 같은 특정 리소스 할당 매개변수를 지정할 수 있도록 허용하고 때로는 요구합니다.

기본적으로 Nextflow는 각 process에 대해 단일 CPU와 2GB의 메모리를 사용합니다. 해당 process 지시문은 cpus 및 memory라고 하므로 다음 구성이 암시됩니다:

내장 구성
process {
    cpus = 1
    memory = 2.GB
}

구성 파일에서 추가 process 지시문을 사용하여 모든 process 또는 특정 명명된 process에 대해 이러한 값을 수정할 수 있습니다. Nextflow는 선택한 실행자에 적합한 명령으로 변환합니다.

그러나 어떤 값을 사용해야 하는지 어떻게 알 수 있습니까?

5.1. 리소스 활용 보고서를 생성하기 위해 workflow 실행¶

Process에 얼마나 많은 CPU와 메모리가 필요한지 미리 알지 못하는 경우 리소스 프로파일링을 수행할 수 있습니다. 즉, 일부 기본 할당으로 workflow를 실행하고, 각 process가 사용한 양을 기록하고, 거기서 기본 할당을 조정하는 방법을 추정합니다.

편리하게도 Nextflow에는 이를 수행하기 위한 내장 도구가 포함되어 있으며 요청 시 보고서를 기꺼이 생성합니다.

그렇게 하려면 명령줄에 -with-report <filename>.html을 추가하십시오.

nextflow run hello-config.nf -with-report report-config-1.html

보고서는 html 파일이며 다운로드하여 브라우저에서 열 수 있습니다. 왼쪽의 파일 탐색기에서 마우스 오른쪽 버튼으로 클릭하고 미리 보기 표시를 클릭하여 교육 환경에서 볼 수도 있습니다.

보고서를 살펴보고 리소스를 조정할 수 있는 기회를 식별할 수 있는지 확인하는 데 몇 분을 투자하십시오. 할당된 것에 대한 백분율로 활용 결과를 보여주는 탭을 클릭해야 합니다. 사용 가능한 모든 기능을 설명하는 문서가 있습니다.

5.2. 모든 process에 대한 리소스 할당 설정¶

프로파일링은 교육 workflow의 process가 매우 가볍다는 것을 보여주므로 process당 기본 메모리 할당을 1GB로 줄입시다.

파이프라인 매개변수 섹션 앞에 nextflow.config 파일에 다음을 추가하십시오:

nextflow.config
/*
* Process 설정
*/
process {
    memory = 1.GB
}

이렇게 하면 소비하는 컴퓨팅 양을 줄이는 데 도움이 됩니다.

5.3. 특정 process에 대한 리소스 할당 설정¶

동시에 cowpy process가 다른 process보다 더 많은 리소스를 필요로 한다고 가정하여 개별 process에 대한 할당을 조정하는 방법을 시연하겠습니다.

수정 후수정 전

nextflow.config
/*
* Process 설정
*/
process {
    memory = 1.GB
    withName: 'cowpy' {
        memory = 2.GB
        cpus = 2
    }
}

nextflow.config
/*
* Process 설정
*/
process {
    memory = 1.GB
}

이 구성으로 모든 process는 1GB의 메모리와 단일 CPU(암시된 기본값)를 요청하지만, cowpy process는 2GB와 2개의 CPU를 요청합니다.

팁

CPU가 적은 머신이 있고 process당 많은 수를 할당하면 process 호출이 서로 뒤에 대기열에 있는 것을 볼 수 있습니다. 이것은 Nextflow가 사용 가능한 것보다 더 많은 CPU를 요청하지 않도록 보장하기 때문입니다.

5.4. 업데이트된 구성으로 workflow 실행¶

시도해 봅시다. 구성 변경 전후의 성능을 비교할 수 있도록 프로파일링 보고서에 대해 다른 파일 이름을 제공합니다.

nextflow run hello-config.nf -with-report report-config-2.html

워크로드가 너무 작기 때문에 실제 차이를 느끼지 못할 수 있지만, 이것은 실제 workflow의 성능 및 리소스 요구 사항을 분석하는 데 사용할 접근 방식입니다.

Process에 다른 리소스 요구 사항이 있는 경우 매우 유용합니다. 추측이 아닌 실제 데이터를 기반으로 각 process에 대해 설정하는 리소스 할당을 적절한 크기로 조정할 수 있습니다.

팁

이것은 리소스 사용을 최적화하기 위해 할 수 있는 것의 아주 작은 맛보기에 불과합니다. Nextflow 자체에는 리소스 제한으로 인해 실패한 작업을 재시도하는 정말 멋진 동적 재시도 로직이 내장되어 있습니다. 또한 Seqera Platform은 리소스 할당을 자동으로 최적화하기 위한 AI 기반 도구도 제공합니다.

5.5. 리소스 제한 추가¶

사용 중인 컴퓨팅 실행자와 컴퓨팅 인프라에 따라 할당할 수 있는(또는 해야 하는) 것에 대한 제약이 있을 수 있습니다. 예를 들어, 클러스터에서 특정 제한 내에 있어야 할 수 있습니다.

resourceLimits 지시문을 사용하여 관련 제한을 설정할 수 있습니다. process 블록에 단독으로 있을 때 구문은 다음과 같습니다:

구문 예제

process {
    resourceLimits = [
        memory: 750.GB,
        cpus: 200,
        time: 30.d
    ]
}

Nextflow는 지정한 실행자에 따라 이러한 값을 적절한 명령으로 변환합니다.

교육 환경에서 관련 인프라에 액세스할 수 없으므로 이것을 실행하지 않을 것입니다. 그러나 이러한 제한을 초과하는 리소스 할당으로 workflow를 실행한 다음 .command.run 스크립트 파일에서 sbatch 명령을 조회하면 실행자에게 실제로 전송되는 요청이 resourceLimits에서 지정한 값으로 제한되어 있는 것을 볼 수 있습니다.

기관 참조 구성

nf-core 프로젝트는 전 세계 다양한 기관에서 공유하는 구성 파일 모음을 컴파일하여 광범위한 HPC 및 클라우드 실행자를 다룹니다.

이러한 공유 구성은 해당 기관에서 일하는 사람들이 자신의 기관 구성을 바로 활용할 수 있다는 점과 자체 인프라에 대한 구성을 개발하려는 사람들을 위한 모델로서 모두 가치가 있습니다.

핵심 내용¶

리소스 활용을 평가하기 위한 프로파일링 보고서를 생성하는 방법과 모든 process 및/또는 개별 process에 대한 리소스 할당을 수정하는 방법, HPC에서 실행하기 위한 리소스 제한을 설정하는 방법을 알게 되었습니다.

다음 단계¶

사전 설정 구성 프로필을 설정하고 런타임에 전환하는 방법을 배웁니다.

6. 프로필을 사용하여 사전 설정 구성 간 전환¶

작업 중인 프로젝트나 사용 중인 컴퓨팅 환경에 따라 파이프라인 구성을 사용자 정의할 수 있는 여러 방법을 보여드렸습니다.

사용 중인 컴퓨팅 인프라에 따라 대체 설정 간에 전환하고 싶을 수 있습니다. 예를 들어, 노트북에서 로컬로 개발하고 소규모 테스트를 실행한 다음 HPC 또는 클라우드에서 전체 규모 워크로드를 실행하고 싶을 수 있습니다.

Nextflow를 사용하면 다양한 구성을 설명하는 여러 프로필을 설정할 수 있으며, 구성 파일 자체를 수정하지 않고 명령줄 인수를 사용하여 런타임에 선택할 수 있습니다.

6.1. 로컬 개발과 HPC에서 실행 간 전환을 위한 프로필 생성¶

두 가지 대체 프로필을 설정합시다; 하나는 Docker 컨테이너를 사용하는 일반 컴퓨터에서 소규모 로드를 실행하고, 하나는 Conda 패키지를 사용하는 Slurm 스케줄러가 있는 대학 HPC에서 실행하기 위한 것입니다.

6.1.1. 프로필 설정¶

파이프라인 매개변수 섹션 뒤에 그리고 출력 설정 앞에 nextflow.config 파일에 다음을 추가하십시오:

nextflow.config
/*
* Profiles
*/
profiles {
    my_laptop {
        process.executor = 'local'
        docker.enabled = true
    }
    univ_hpc {
        process.executor = 'slurm'
        conda.enabled = true
        process.resourceLimits = [
            memory: 750.GB,
            cpus: 200,
            time: 30.d
        ]
    }
}

대학 HPC의 경우 리소스 제한도 지정하고 있습니다.

6.1.2. 프로필로 workflow 실행¶

Nextflow 명령줄에서 프로필을 지정하려면 -profile 인수를 사용합니다.

my_laptop 구성으로 workflow를 실행해 봅시다.

nextflow run hello-config.nf -profile my_laptop

명령 출력

N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [gigantic_brazil] DSL2 - revision: ede9037d02

executor >  local (8)
[58/da9437] sayHello (3)       | 3 of 3 ✔
[35/9cbe77] convertToUpper (2) | 3 of 3 ✔
[67/857d05] collectGreetings   | 1 of 1 ✔
[37/7b51b5] cowpy              | 1 of 1 ✔

보시다시피 런타임에 매우 편리하게 구성 간에 전환할 수 있습니다.

경고

Slurm 스케줄러에 액세스할 수 없으므로 교육 환경에서 univ_hpc 프로필은 제대로 실행되지 않습니다.

앞으로 이러한 프로필과 항상 함께 발생하는 다른 구성 요소를 찾으면 해당 프로필에 간단히 추가할 수 있습니다. 함께 그룹화하려는 다른 구성 요소가 있는 경우 추가 프로필을 만들 수도 있습니다.

6.2. 테스트 매개변수 프로필 생성¶

프로필은 인프라 구성만을 위한 것이 아닙니다. 다른 사람들이 적절한 입력 값을 직접 수집하지 않고도 workflow를 쉽게 시험해 볼 수 있도록 workflow 매개변수의 기본값을 설정하는 데도 사용할 수 있습니다. 이것을 매개변수 파일 사용의 대안으로 고려할 수 있습니다.

6.2.1. 프로필 설정¶

이 컨텍스트에서 기본값을 표현하는 구문은 test라고 이름 지은 프로필에 대해 다음과 같습니다:

구문 예제

    test {
        params.<parameter1>
        params.<parameter2>
        ...
    }

workflow에 대한 테스트 프로필을 추가하면 profiles 블록은 다음과 같이 됩니다:

nextflow.config
/*
* Profiles
*/
profiles {
    my_laptop {
        process.executor = 'local'
        docker.enabled = true
    }
    univ_hpc {
        process.executor = 'slurm'
        conda.enabled = true
        process.resourceLimits = [
            memory: 750.GB,
            cpus: 200,
            time: 30.d
        ]
    }
    test {
        params.greeting = 'greetings.csv'
        params.batch = 'test'
        params.character = 'dragonandcow'
    }
}

기술 구성 프로필과 마찬가지로 원하는 임의의 이름으로 매개변수를 지정하는 여러 다른 프로필을 설정할 수 있습니다.

6.2.2. 테스트 프로필로 로컬에서 workflow 실행¶

편리하게도 프로필은 상호 배타적이지 않으므로 다음 구문 -profile <profile1>,<profile2>를 사용하여 명령줄에서 여러 프로필을 지정할 수 있습니다(프로필 수에 관계없이).

동일한 구성 파일에 설명되어 있고 동일한 구성 요소에 대해 값을 설정하는 프로필을 결합하면 Nextflow는 마지막으로 읽은 값을 사용하여 충돌을 해결합니다(즉, 파일에서 나중에 나오는 것). 충돌하는 설정이 다른 구성 소스에 설정된 경우 기본 우선순위가 적용됩니다.

이전 명령에 테스트 프로필을 추가해 봅시다:

nextflow run hello-config.nf -profile my_laptop,test

명령 출력

N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [jovial_coulomb] DSL2 - revision: 46a6763141

executor >  local (8)
[9b/687cdc] sayHello (2)       | 3 of 3 ✔
[ca/552187] convertToUpper (3) | 3 of 3 ✔
[e8/83e306] collectGreetings   | 1 of 1 ✔
[fd/e84fa9] cowpy              | 1 of 1 ✔

이것은 가능한 경우 Docker를 사용하고 results/test 아래에 출력을 생성하며, 이번에 캐릭터는 코믹 듀오 dragonandcow입니다.

파일 내용

results/test/

 _________
/ HOLà    \
| HELLO   |
\ BONJOUR /
---------
            \                    ^    /^
              \                  / \  // \
              \   |\___/|      /   \//  .\
                \  /O  O  \__  /    //  | \ \           *----*
                  /     /  \/_/    //   |  \  \          \   |
                  \@___\@`    \/_   //    |   \   \         \/\ \
                0/0/|       \/_ //     |    \    \         \ \
            0/0/0/0/|        \///      |     \     \       | |
          0/0/0/0/0/_|_ /   (  //       |      \     _\     |  /
      0/0/0/0/0/0/`/,_ _ _/  ) ; -.    |    _ _\.-~       /   /
                  ,-}        _      *-.|.-~-.           .~    ~
  \     \__/        `/\      /                 ~-. _ .-~      /
  \____(oo)           *.   }            {                   /
  (    (--)          .----~-.\        \-`                 .~
  //__\\  \__ Ack!   ///.----..<        \             _ -~
  //    \\               ///-._ _ _ _ _ _ _{^ - - - - ~

이것은 workflow 코드와 함께 테스트 데이터 파일을 배포하는 한, 누구나 명령줄이나 매개변수 파일을 통해 자신의 입력을 제공하지 않고도 workflow를 빠르게 시험해 볼 수 있음을 의미합니다.

팁

외부에 저장된 더 큰 파일에 대한 URL을 가리킬 수 있습니다. 열린 연결이 있는 한 Nextflow가 자동으로 다운로드합니다.

자세한 내용은 사이드 퀘스트 파일 작업을 참조하십시오.

6.3. `nextflow config`를 사용하여 해결된 구성 확인¶

위에서 언급했듯이 때때로 동일한 매개변수가 결합하려는 프로필에서 다른 값으로 설정될 수 있습니다. 그리고 더 일반적으로, 구성 요소가 저장될 수 있는 수많은 장소가 있으며, 때때로 동일한 속성이 다른 장소에서 다른 값으로 설정될 수 있습니다.

Nextflow는 충돌을 해결하기 위해 설정된 우선순위를 적용하지만 직접 결정하기 어려울 수 있습니다. 그리고 충돌이 없더라도 구성할 수 있는 모든 가능한 장소를 조회하는 것은 지루할 수 있습니다.

다행히도 Nextflow에는 전체 프로세스를 자동화할 수 있는 config라는 편리한 유틸리티 도구가 포함되어 있습니다.

config 도구는 현재 작업 디렉토리의 모든 내용을 탐색하고, 모든 구성 파일을 수집하고, Nextflow가 workflow를 실행하는 데 사용할 완전히 해결된 구성을 생성합니다. 이렇게 하면 아무것도 시작하지 않고도 어떤 설정이 사용될지 알 수 있습니다.

6.3.1. 기본 구성 해결¶

기본적으로 적용될 구성을 해결하려면 이 명령을 실행하십시오.

nextflow config

명령 출력

docker {
  enabled = false
}

conda {
  enabled = true
}

process {
  memory = '1 GB'
  withName:cowpy {
      memory = '2 GB'
      cpus = 2
  }
}

params {
  input = 'greetings.csv'
  batch = 'batch'
  character = 'turkey'
}

이것은 명령줄에서 추가 항목을 지정하지 않으면 얻는 기본 구성을 보여줍니다.

6.3.2. 특정 설정이 활성화된 구성 해결¶

명령줄 매개변수(예: 하나 이상의 프로필 활성화 또는 매개변수 파일 로드)를 제공하면 명령이 이를 추가로 고려합니다.

nextflow config -profile my_laptop,test

명령 출력

docker {
  enabled = true
}

conda {
  enabled = true
}

process {
  memory = '1 GB'
  withName:cowpy {
      memory = '2 GB'
      cpus = 2
  }
  executor = 'local'
}

params {
  input = 'greetings.csv'
  batch = 'test'
  character = 'dragonandcow'
}

이것은 여러 계층의 구성을 포함하는 복잡한 프로젝트에 특히 유용합니다.

핵심 내용¶

프로필을 사용하여 최소한의 번거로움으로 런타임에 사전 설정 구성을 선택하는 방법을 알게 되었습니다. 더 일반적으로, 다른 컴퓨팅 플랫폼에 맞게 workflow 실행을 구성하고 분석의 재현성을 향상시키는 방법을 알게 되었습니다.

다음 단계¶

축하하고 자신에게 큰 칭찬을 해주십시오! 첫 번째 Nextflow 개발자 과정을 완료했습니다.

배운 내용을 검토하고 다음에 무엇이 올지 알아보려면 최종 과정 요약으로 이동하십시오.

퀴즈¶

#

Nextflow가 자동으로 로드하는 구성 파일의 이름은 무엇입니까?

#

동일한 매개변수가 구성 파일과 명령줄 모두에 설정된 경우 어떤 것이 우선합니까?

#

동일한 구성에서 Docker와 Conda를 모두 활성화할 수 있습니까?

#

Docker와 Conda가 모두 활성화되어 있고 process에 두 지시문이 모두 있는 경우 어떤 것이 우선합니까?

#

Nextflow process의 기본 메모리 할당은 얼마입니까?

#

구성 파일에서 특정 process에 대한 리소스 요구 사항을 어떻게 설정합니까?

#

리소스 활용 보고서를 생성하는 명령줄 옵션은 무엇입니까?

#

resourceLimits 지시문은 무엇을 합니까?

#

Nextflow의 기본 실행자는 무엇입니까?

#

Nextflow를 실행할 때 매개변수 파일을 어떻게 지정합니까?

#

프로필은 무엇에 사용할 수 있습니까? (해당되는 것 모두 선택)

#

단일 명령에서 여러 프로필을 어떻게 지정합니까?

파트 6: Hello Config¶

0. 워밍업: hello-config.nf 실행¶

1. Workflow 입력 매개변수 관리¶

1.1. 기본값을 nextflow.config로 이동¶

1.1.1. 구성 파일에 params 블록 생성¶

1.1.2. Workflow 파일의 params 블록에서 값 제거¶

1.1.3. 파이프라인 실행¶

1.2. 실행별 구성 파일 사용¶

1.2.1. 빈 구성으로 작업 디렉토리 생성¶

1.2.2. 실험 구성 설정¶

1.2.3. 파이프라인 실행¶

1.3. 매개변수 파일 사용¶

1.3.1. 예제 매개변수 파일 검사¶

1.3.2. 파이프라인 실행¶

핵심 내용¶

다음 단계¶

2. Workflow 출력 관리¶

2.1. outputDir 디렉토리 이름 사용자 정의¶

2.1.1. 구성 파일에서 outputDir 값 설정¶

2.1.2. 하드코딩된 경로의 반복되는 부분 제거¶

2.1.3. 파이프라인 실행¶

2.2. Process별로 출력 구성¶

2.2.1. 출력 경로를 process 이름에 대한 참조로 교체¶

2.2.2. 파이프라인 실행¶

2.3. Workflow 수준에서 게시 모드 설정¶

2.3.1. 구성 파일에 workflow.output.mode 추가¶

2.3.2. Workflow 파일에서 출력 모드 제거¶

2.3.3. 파이프라인 실행¶

핵심 내용¶

다음 단계¶

3. 소프트웨어 패키징 기술 선택¶

3.1. 구성 파일에서 Docker 비활성화 및 Conda 활성화¶

3.2. Process 정의에서 Conda 패키지 지정¶

3.3. Workflow를 실행하여 Conda를 사용할 수 있는지 확인¶

핵심 내용¶

다음 단계¶

4. 실행 플랫폼 선택¶

4.1. 다른 백엔드 대상 지정¶

4.2. 실행 매개변수에 대한 백엔드별 구문 처리¶

핵심 내용¶

다음 단계¶

5. 컴퓨팅 리소스 할당 제어¶

5.1. 리소스 활용 보고서를 생성하기 위해 workflow 실행¶

5.2. 모든 process에 대한 리소스 할당 설정¶

5.3. 특정 process에 대한 리소스 할당 설정¶

5.4. 업데이트된 구성으로 workflow 실행¶

5.5. 리소스 제한 추가¶

핵심 내용¶

다음 단계¶

6. 프로필을 사용하여 사전 설정 구성 간 전환¶

6.1. 로컬 개발과 HPC에서 실행 간 전환을 위한 프로필 생성¶

6.1.1. 프로필 설정¶

6.1.2. 프로필로 workflow 실행¶

6.2. 테스트 매개변수 프로필 생성¶

6.2.1. 프로필 설정¶

6.2.2. 테스트 프로필로 로컬에서 workflow 실행¶

6.3. nextflow config를 사용하여 해결된 구성 확인¶

6.3.1. 기본 구성 해결¶

6.3.2. 특정 설정이 활성화된 구성 해결¶

핵심 내용¶

다음 단계¶

퀴즈¶

0. 워밍업: `hello-config.nf` 실행¶

1.1. 기본값을 `nextflow.config`로 이동¶

1.1.1. 구성 파일에 `params` 블록 생성¶

1.1.2. Workflow 파일의 `params` 블록에서 값 제거¶

2.1. `outputDir` 디렉토리 이름 사용자 정의¶

2.1.1. 구성 파일에서 `outputDir` 값 설정¶

2.3.1. 구성 파일에 `workflow.output.mode` 추가¶

6.3. `nextflow config`를 사용하여 해결된 구성 확인¶