파트 6: Hello Config¶
AI 지원 번역 - 자세히 알아보기 및 개선 제안
전체 재생목록을 Nextflow YouTube 채널에서 확인하세요.
비디오 스크립트는 여기에서 확인할 수 있습니다.
이 섹션에서는 Nextflow 파이프라인의 구성을 설정하고 관리하는 방법을 학습합니다. 이를 통해 워크플로우 코드 자체를 전혀 수정하지 않고도 동작을 사용자 정의하고, 다양한 환경에 적응시키며, 리소스 사용을 최적화할 수 있습니다.
이를 수행하는 방법은 여러 가지가 있으며, 이들을 조합하여 사용할 수 있고 구성 문서에 설명된 우선순위에 따라 해석됩니다.
이 과정의 이 파트에서는 가장 간단하고 일반적인 구성 파일 메커니즘인 nextflow.config 파일을 소개합니다. 이 파일은 파트 5: Hello Containers에서 이미 접했습니다.
프로세스 지시문, 실행자, 프로필, 매개변수 파일과 같은 Nextflow 구성의 필수 구성 요소를 다룰 것입니다. 이러한 구성 옵션을 효과적으로 활용하는 방법을 학습함으로써 파이프라인의 유연성, 확장성 및 성능을 향상시킬 수 있습니다.
이 섹션을 시작하는 방법
이 과정의 이 섹션은 Hello Nextflow 과정의 파트 1-5를 완료하고 완전히 작동하는 파이프라인을 가지고 있다고 가정합니다.
이 지점부터 과정을 시작하는 경우, 솔루션에서 modules 디렉토리와 nextflow.config 파일을 복사해야 합니다:
nextflow.config 파일에는 Docker 컨테이너 사용을 활성화하는 docker.enabled = true 라인이 포함되어 있습니다.
Hello 파이프라인에 익숙하지 않거나 복습이 필요한 경우 이 정보 페이지를 참조하세요.
0. 준비 운동: hello-config.nf 실행¶
시작점으로 워크플로우 스크립트 hello-config.nf를 사용할 것입니다.
이것은 이 교육 과정의 파트 5를 완료하여 생성된 스크립트와 동일하지만, 출력 대상을 변경했습니다:
| hello-config.nf | |
|---|---|
모든 것이 작동하는지 확인하기 위해 변경하기 전에 스크립트를 한 번 실행하세요:
명령 출력
이전과 마찬가지로 output 블록에 지정된 디렉토리(results/hello_config/)에서 출력 파일을 찾을 수 있습니다.
디렉토리 내용
최종 ASCII 아트 출력은 results/hello_config/ 디렉토리에 cowpy-COLLECTED-batch-output.txt라는 이름으로 있습니다.
파일 내용
_________
/ HOLà \
| HELLO |
\ BONJOUR /
---------
\ ,+*^^*+___+++_
\ ,*^^^^ )
\ _+* ^**+_
\ +^ _ _++*+_+++_, )
_+^^*+_ ( ,+*^ ^ \+_ )
{ ) ( ,( ,_+--+--, ^) ^\
{ (\@) } f ,( ,+-^ __*_*_ ^^\_ ^\ )
{:;-/ (_+*-+^^^^^+*+*<_ _++_)_ ) ) /
( / ( ( ,___ ^*+_+* ) < < \
U _/ ) *--< ) ^\-----++__) ) ) )
( ) _(^)^^)) ) )\^^^^^))^*+/ / /
( / (_))_^)) ) ) ))^^^^^))^^^)__/ +^^
( ,/ (^))^)) ) ) ))^^^^^^^))^^) _)
*+__+* (_))^) ) ) ))^^^^^^))^^^^^)____*^
\ \_)^)_)) ))^^^^^^^^^^))^^^^)
(_ ^\__^^^^^^^^^^^^))^^^^^^^)
^\___ ^\__^^^^^^))^^^^^^^^)\\
^^^^^\uuu/^^\uuu/^^^^\^\^\^\^\^\^\^\
___) >____) >___ ^\_\_\_\_\_\_\)
^^^//\\_^^//\\_^ ^(\_\_\_\)
^^^ ^^ ^^^ ^
이것이 작동했다면 파이프라인을 구성하는 방법을 학습할 준비가 된 것입니다.
1. 워크플로우 입력 매개변수 관리¶
지금까지 작업해 온 것의 확장인 구성 측면부터 시작하겠습니다: 입력 매개변수 관리입니다.
현재 워크플로우는 명령줄을 통해 여러 매개변수 값을 받도록 설정되어 있으며, 워크플로우 스크립트 자체의 params 블록에 기본값이 설정되어 있습니다.
그러나 명령줄에서 매개변수를 지정하거나 원본 스크립트 파일을 수정하지 않고도 이러한 기본값을 재정의하고 싶을 수 있습니다.
이를 수행하는 방법은 여러 가지가 있습니다. 매우 일반적으로 사용되는 세 가지 기본 방법을 보여드리겠습니다.
1.1. 기본값을 nextflow.config로 이동¶
이것은 가장 간단한 접근 방식이지만, 메인 nextflow.config 파일은 매 실행마다 편집하고 싶은 것이 아니기 때문에 가장 유연하지 않을 수 있습니다.
그러나 워크플로우에서 매개변수를 선언하는 것(확실히 그곳에 속함)과 기본값을 제공하는 것(구성 파일에 더 적합함)의 관심사를 분리한다는 장점이 있습니다.
이것을 두 단계로 수행하겠습니다.
1.1.1. 구성 파일에 params 블록 생성¶
nextflow.config 파일에서 다음 코드 변경을 수행하세요:
워크플로우에서 구성 파일로 params 블록을 단순히 복사하지 않았다는 점에 유의하세요.
구문이 약간 다릅니다.
워크플로우 파일에서는 타입이 지정된 선언입니다.
구성에서는 값 할당입니다.
기술적으로 이것은 워크플로우 파일에 여전히 지정된 기본값을 재정의하기에 충분합니다. 예를 들어 캐릭터를 수정하고 워크플로우를 실행하여 구성 파일에 설정된 값이 워크플로우 파일에 설정된 값을 재정의하는지 확인할 수 있습니다.
그러나 구성을 구성 파일로 완전히 이동하는 정신으로, 워크플로우 파일에서 해당 값을 완전히 제거하겠습니다.
1.1.2. 워크플로우 파일의 params 블록에서 값 제거¶
hello-config.nf 워크플로우 파일에서 다음 코드 변경을 수행하세요:
이제 워크플로우 파일 자체는 이러한 매개변수에 대한 기본값을 설정하지 않습니다.
1.1.3. 파이프라인 실행¶
올바르게 작동하는지 테스트해 보겠습니다.
명령 출력
이것은 여전히 이전과 동일한 출력을 생성합니다.
최종 ASCII 아트 출력은 이전과 마찬가지로 results/hello_config/ 디렉토리에 cowpy-COLLECTED-batch-output.txt라는 이름으로 있습니다.
파일 내용
_________
/ HOLà \
| HELLO |
\ BONJOUR /
---------
\ ,+*^^*+___+++_
\ ,*^^^^ )
\ _+* ^**+_
\ +^ _ _++*+_+++_, )
_+^^*+_ ( ,+*^ ^ \+_ )
{ ) ( ,( ,_+--+--, ^) ^\
{ (\@) } f ,( ,+-^ __*_*_ ^^\_ ^\ )
{:;-/ (_+*-+^^^^^+*+*<_ _++_)_ ) ) /
( / ( ( ,___ ^*+_+* ) < < \
U _/ ) *--< ) ^\-----++__) ) ) )
( ) _(^)^^)) ) )\^^^^^))^*+/ / /
( / (_))_^)) ) ) ))^^^^^))^^^)__/ +^^
( ,/ (^))^)) ) ) ))^^^^^^^))^^) _)
*+__+* (_))^) ) ) ))^^^^^^))^^^^^)____*^
\ \_)^)_)) ))^^^^^^^^^^))^^^^)
(_ ^\__^^^^^^^^^^^^))^^^^^^^)
^\___ ^\__^^^^^^))^^^^^^^^)\\
^^^^^\uuu/^^\uuu/^^^^\^\^\^\^\^\^\^\
___) >____) >___ ^\_\_\_\_\_\_\)
^^^//\\_^^//\\_^ ^(\_\_\_\)
^^^ ^^ ^^^ ^
기능적으로 이 이동은 아무것도 변경하지 않았지만, 개념적으로는 구성 파일에 기본값을 설정하는 것이 조금 더 깔끔합니다.
1.2. 실행별 구성 파일 사용¶
좋습니다. 하지만 때로는 메인 구성 파일을 건드리지 않고 다른 기본값으로 임시 실험을 실행하고 싶을 수 있습니다.
실험을 위한 작업 디렉토리로 사용할 하위 디렉토리에 새 nextflow.config 파일을 생성하여 이를 수행할 수 있습니다.
1.2.1. 빈 구성으로 작업 디렉토리 생성¶
새 디렉토리를 생성하고 그 안으로 이동하는 것부터 시작하겠습니다:
그런 다음 해당 디렉토리에 빈 구성 파일을 생성합니다:
이것은 빈 파일을 생성합니다.
1.2.2. 실험 구성 설정¶
이제 새 파일을 열고 사용자 정의하려는 매개변수를 추가합니다:
| tux-run/nextflow.config | |
|---|---|
입력 파일의 경로는 디렉토리 구조를 반영해야 한다는 점에 유의하세요.
1.2.3. 파이프라인 실행¶
이제 새 작업 디렉토리 내에서 파이프라인을 실행할 수 있습니다. 경로를 적절히 조정해야 합니다!
명령 출력
이것은 tux-run/work/ 및 tux-run/results/를 포함하여 tux-run/ 아래에 새로운 디렉토리 세트를 생성합니다.
이 실행에서 Nextflow는 현재 디렉토리의 nextflow.config를 파이프라인 루트 디렉토리의 nextflow.config와 결합하여 기본 캐릭터(turkey)를 tux 캐릭터로 재정의합니다.
최종 출력 파일에는 인사말을 말하는 tux 캐릭터가 포함되어야 합니다.
파일 내용
이제 '일반' 구성을 수정하지 않고 실험할 수 있는 공간이 생겼습니다.
이제 매개변수 값을 설정하는 또 다른 유용한 방법을 살펴보겠습니다.
1.3. 매개변수 파일 사용¶
하위 디렉토리 접근 방식은 실험에 적합하지만 약간의 설정이 필요하고 경로를 적절히 조정해야 합니다. 특정 값 세트로 파이프라인을 실행하거나 다른 사람이 최소한의 노력으로 실행할 수 있도록 하려는 경우 더 간단한 접근 방식이 있습니다.
Nextflow를 사용하면 YAML 또는 JSON 형식의 매개변수 파일을 통해 매개변수를 지정할 수 있으므로 예를 들어 대체 기본값 세트와 실행별 매개변수 값을 관리하고 배포하는 것이 매우 편리합니다.
1.3.1. 예제 매개변수 파일 검토¶
이를 시연하기 위해 현재 디렉토리에 test-params.yaml이라는 예제 매개변수 파일을 제공합니다:
이 매개변수 파일에는 지정하려는 각 입력에 대한 키-값 쌍이 포함되어 있습니다.
구성 파일과 구문을 비교하면 등호(=) 대신 콜론(:)을 사용한다는 점에 유의하세요.
구성 파일은 Groovy로 작성되는 반면 매개변수 파일은 YAML로 작성됩니다.
정보
예제로 매개변수 파일의 JSON 버전도 제공하지만 여기서는 실행하지 않을 것입니다. 직접 시도해 보세요.
1.3.2. 파이프라인 실행¶
이 매개변수 파일로 워크플로우를 실행하려면 기본 명령에 -params-file <filename>을 추가하기만 하면 됩니다.
명령 출력
최종 출력 파일에는 인사말을 말하는 stegosaurus 캐릭터가 포함되어야 합니다.
파일 내용
_________
/ HELLO \
| HOLà |
\ BONJOUR /
---------
\ . .
\ / `. .' "
\ .---. < > < > .---.
\ | \ \ - ~ ~ - / / |
_____ ..-~ ~-..-~
| | \~~~\.' `./~~~/
--------- \__/ \__/
.' O \ / / \ "
(_____, `._.' | } \/~~~/
`----. / } | / \__/
`-. | / | / `. ,~~|
~-.__| /_ - ~ ^| /- _ `..-'
| / | / ~-. `-. _ _ _
|_____| |_____| ~ - . _ _ _ _ _>
지정할 매개변수가 몇 개뿐일 때는 매개변수 파일을 사용하는 것이 과도해 보일 수 있지만, 일부 파이프라인은 수십 개의 매개변수를 예상합니다. 이러한 경우 매개변수 파일을 사용하면 워크플로우 스크립트를 수정하지 않고도 대규모 명령줄을 입력하지 않고 런타임에 매개변수 값을 제공할 수 있습니다.
또한 예를 들어 협력자에게 매개변수 세트를 배포하거나 출판물의 보조 정보로 배포하는 것이 더 쉬워집니다. 이를 통해 다른 사람이 작업을 더 재현 가능하게 만듭니다.
핵심 정리¶
워크플로우 입력 관리를 위한 주요 구성 옵션을 활용하는 방법을 알게 되었습니다.
다음 단계¶
워크플로우 출력이 게시되는 위치와 방법을 관리하는 방법을 학습합니다.
2. 워크플로우 출력 관리¶
지금까지 워크플로우 수준 출력 선언에 대한 모든 경로를 하드코딩해 왔으며, 여러 출력을 추가하기 시작하면서 언급했듯이 약간의 반복이 있을 수 있습니다.
이를 더 유연하게 구성할 수 있는 몇 가지 일반적인 방법을 살펴보겠습니다.
2.1. -output-dir로 출력 디렉토리 사용자 정의¶
'게시된' 출력이 구성되는 방식을 제어할 때 두 가지 별개의 우선순위가 있습니다:
- 최상위 출력 디렉토리
- 이 디렉토리 내에서 파일이 구성되는 방식
지금까지 기본 최상위 디렉토리인 results를 사용해 왔습니다.
-output-dir CLI 옵션을 사용하여 이를 사용자 정의하는 것부터 시작하겠습니다.
2.1.1. -output-dir로 파이프라인 실행¶
-output-dir 옵션(약어: -o)은 모든 워크플로우 출력에 대한 기본 출력 디렉토리(results/)를 재정의합니다.
이것은 출력이 게시되는 루트 경로를 제어하는 권장 방법입니다.
명령 출력
이것은 results/ 대신 custom-outdir-cli/에 출력을 게시합니다:
디렉토리 내용
출력 블록의 path 선언에서 여전히 hello_config 하위 디렉토리가 있다는 점에 유의하세요.
이를 정리하겠습니다.
2.1.2. 출력 블록에서 하드코딩된 경로 제거¶
hello_config/ 접두사는 이전 챕터에서 하드코딩되었지만, 이제 출력 경로를 유연하게 구성하는 방법을 학습하고 있으므로 이 하드코딩을 제거할 수 있습니다.
하위 디렉토리가 필요하지 않은 출력의 경우 path 지시문을 빈 문자열로 설정하거나 완전히 제거할 수 있습니다.
워크플로우 파일에서 다음 코드 변경을 수행하세요:
| hello-config.nf | |
|---|---|
| hello-config.nf | |
|---|---|
파이프라인을 다시 실행하세요:
이제 출력이 hello_config 하위 디렉토리 없이 custom-outdir-cli-2/ 바로 아래에 게시됩니다:
디렉토리 내용
팁
-output-dir 옵션은 출력이 어디로 가는지 제어하는 데 사용되는 반면, 출력 블록의 path 지시문은 _하위 디렉토리 구조_를 제어합니다.
2.2. 동적 출력 경로¶
CLI를 통해 출력 디렉토리를 변경하는 것 외에도 outputDir을 사용하여 구성 파일에서 사용자 정의 기본값을 설정할 수도 있습니다.
이를 통해 정적 문자열뿐만 아니라 동적으로 디렉토리 경로를 설정할 수 있습니다.
2.2.1. 구성 파일에서 outputDir 설정¶
nextflow.config 파일에 다음 코드를 추가하세요:
이것은 출력 디렉토리를 custom-outdir-config/에 batch 매개변수의 값을 하위 디렉토리로 추가하여 설정합니다.
이제 --batch 매개변수를 설정하여 출력 위치를 변경할 수 있습니다:
이것은 custom-outdir-config/my_run/에 출력을 게시합니다.
참고
-output-dir CLI 옵션은 outputDir 구성 설정보다 우선합니다.
설정되면 구성 옵션은 완전히 무시됩니다.
2.2.2. 배치 및 프로세스 이름이 있는 하위 디렉토리¶
출력별로 하위 디렉토리 출력 path 선언을 동적으로 설정할 수도 있습니다.
예를 들어 출력 경로 선언에서 <process>.name을 참조하여 프로세스별로 출력을 구성할 수 있습니다:
| hello-config.nf | |
|---|---|
| hello-config.nf | |
|---|---|
더 나아가 더 복잡한 하위 디렉토리 경로를 구성할 수 있습니다.
위의 편집에서 intermediates와 최상위 수준의 최종 출력 간의 구분을 지웠습니다.
이를 다시 추가하고 파일을 params.batch 하위 디렉토리에도 넣겠습니다.
팁
outputDir 구성 대신 출력 블록 path에 params.batch를 포함하면 CLI에서 -output-dir로 덮어쓰지 않습니다.
먼저 구성 파일을 업데이트하여 outputDir에서 ${params.batch}를 제거합니다(경로 선언으로 이동하고 있으므로):
그런 다음 워크플로우 파일에서 다음 변경을 수행하세요:
| hello-config.nf | |
|---|---|
2.2.3. 파이프라인 실행¶
실제로 어떻게 작동하는지 살펴보겠습니다. 명령줄에서 -output-dir(또는 약어 -o)을 custom-outdir-config-2로 설정하고 배치 이름을 rep2로 설정합니다:
명령 출력
이것은 지정된 기본 경로 및 배치 이름 하위 디렉토리 및 프로세스별로 그룹화된 결과와 함께 custom-outdir-config-2/rep2/에 출력을 게시합니다:
디렉토리 내용
custom-outdir-config-2
└── rep2
├── collectGreetings
│ └── rep2-report.txt
├── cowpy
│ └── cowpy-COLLECTED-rep2-output.txt
└── intermediates
├── collectGreetings
│ └── COLLECTED-rep2-output.txt
├── convertToUpper
│ ├── UPPER-Bonjour-output.txt
│ ├── UPPER-Hello-output.txt
│ └── UPPER-Holà-output.txt
└── sayHello
├── Bonjour-output.txt
├── Hello-output.txt
└── Holà-output.txt
2.3. 워크플로우 수준에서 게시 모드 설정¶
마지막으로 반복적인 코드의 양을 줄이는 정신으로 출력별 mode 선언을 구성의 단일 라인으로 대체할 수 있습니다.
2.3.1. 구성 파일에 workflow.output.mode 추가¶
nextflow.config 파일에 다음 코드를 추가하세요:
구성 파일에서 workflow.output.mode를 설정하는 것은 워크플로우 파일에 설정된 것을 재정의하기에 충분하지만, 어쨌든 불필요한 코드를 제거하겠습니다.
2.3.2. 워크플로우 파일에서 출력 모드 제거¶
워크플로우 파일에서 다음 변경을 수행하세요:
더 간결하지 않나요?
2.3.3. 파이프라인 실행¶
올바르게 작동하는지 테스트해 보겠습니다:
명령 출력
이것은 config-output-mode/에 출력을 게시하며, 여전히 모두 심볼릭 링크가 아닌 적절한 복사본입니다.
디렉토리 내용
config-output-mode
└── batch
├── collectGreetings
│ └── batch-report.txt
├── cowpy
│ └── cowpy-COLLECTED-batch-output.txt
└── intermediates
├── collectGreetings
│ └── COLLECTED-batch-output.txt
├── convertToUpper
│ ├── UPPER-Bonjour-output.txt
│ ├── UPPER-Hello-output.txt
│ └── UPPER-Holà-output.txt
└── sayHello
├── Bonjour-output.txt
├── Hello-output.txt
└── Holà-output.txt
출력별 모드 설정 방식을 여전히 사용하고 싶은 주된 이유는 동일한 워크플로우 내에서 혼합하고 일치시키려는 경우, 즉 일부 출력은 복사하고 일부는 심볼릭 링크로 만들려는 경우입니다.
이러한 방식으로 사용자 정의할 수 있는 다른 많은 옵션이 있지만, 이것이 옵션의 범위와 선호도에 맞게 효과적으로 활용하는 방법에 대한 감각을 제공하기를 바랍니다.
핵심 정리¶
출력이 게시되는 디렉토리의 이름 지정 및 구조와 워크플로우 출력 게시 모드를 제어하는 방법을 알게 되었습니다.
다음 단계¶
컴퓨팅 환경에 워크플로우 구성을 적응시키는 방법을 학습합니다. 소프트웨어 패키징 기술부터 시작합니다.
3. 소프트웨어 패키징 기술 선택¶
지금까지 입력이 들어가는 방식과 출력이 나오는 위치를 제어하는 구성 요소를 살펴보았습니다. 이제 컴퓨팅 환경에 워크플로우 구성을 적응시키는 데 더 구체적으로 초점을 맞출 시간입니다.
그 경로의 첫 번째 단계는 각 단계에서 실행될 소프트웨어 패키지가 어디에서 올 것인지 지정하는 것입니다. 로컬 컴퓨팅 환경에 이미 설치되어 있습니까? 컨테이너 시스템을 통해 이미지를 검색하고 실행해야 합니까? 아니면 Conda 패키지를 검색하고 로컬 Conda 환경을 구축해야 합니까?
이 교육 과정의 맨 처음 부분(파트 1-4)에서는 워크플로우에서 로컬에 설치된 소프트웨어만 사용했습니다.
그런 다음 파트 5에서 Docker 컨테이너와 nextflow.config 파일을 소개했으며, 이를 사용하여 Docker 컨테이너 사용을 활성화했습니다.
이제 nextflow.config 파일을 통해 대체 소프트웨어 패키징 옵션을 구성하는 방법을 살펴보겠습니다.
3.1. 구성 파일에서 Docker 비활성화 및 Conda 활성화¶
HPC 클러스터에서 작업하고 있고 관리자가 보안상의 이유로 Docker 사용을 허용하지 않는다고 가정해 보겠습니다. 다행히도 Nextflow는 Singularity(HPC에서 더 널리 사용됨)를 포함한 여러 다른 컨테이너 기술과 Conda와 같은 소프트웨어 패키지 관리자를 지원합니다.
Conda를 Docker 대신 사용하도록 구성 파일을 변경할 수 있습니다.
이를 위해 docker.enabled의 값을 false로 전환하고 Conda 사용을 활성화하는 지시문을 추가하겠습니다:
이를 통해 Nextflow는 Conda 패키지가 지정된 프로세스에 대한 Conda 환경을 생성하고 활용할 수 있습니다.
즉, 이제 cowpy 프로세스에 그 중 하나를 추가해야 합니다!
3.2. 프로세스 정의에서 Conda 패키지 지정¶
cowpy 도구가 포함된 Conda 패키지의 URI를 이미 검색했습니다: conda-forge::cowpy==1.1.5
이제 conda 지시문을 사용하여 cowpy 프로세스 정의에 URI를 추가합니다:
명확히 하자면, docker 지시문을 대체하는 것이 아니라 대체 옵션을 추가하는 것입니다.
팁
주어진 conda 패키지의 URI를 얻는 몇 가지 다른 방법이 있습니다. 컨테이너를 생성할 계획이 없더라도 복사하여 붙여넣을 수 있는 URI를 제공하는 Seqera Containers 검색 쿼리를 사용하는 것이 좋습니다.
3.3. 워크플로우를 실행하여 Conda를 사용할 수 있는지 확인¶
시도해 보겠습니다.
명령 출력
N E X T F L O W ~ version 25.10.2
Launching `hello-config.nf` [friendly_lamport] DSL2 - revision: 024d6361b5
executor > local (8)
[e8/91c116] sayHello (2) [100%] 3 of 3 ✔
[fe/6a70ce] convertToUpper (3) [100%] 3 of 3 ✔
[99/7cc493] collectGreetings [100%] 1 of 1 ✔
[3c/09fb59] cowpy [100%] 1 of 1 ✔
이것은 문제없이 작동하고 custom-outdir-config/conda 아래에 이전과 동일한 출력을 생성해야 합니다.
백그라운드에서 Nextflow는 Conda 패키지를 검색하고 환경을 생성했으며, 이는 일반적으로 약간의 작업이 필요합니다. 따라서 우리가 직접 수행할 필요가 없다는 것이 좋습니다!
참고
cowpy 패키지가 매우 작기 때문에 빠르게 실행되지만, 큰 패키지로 작업하는 경우 처음 사용할 때 평소보다 조금 더 오래 걸릴 수 있으며 콘솔 출력이 완료되기 전에 1분 정도 '멈춰' 있는 것을 볼 수 있습니다.
이것은 정상이며 새 패키지를 처음 사용할 때 Nextflow가 수행하는 추가 작업 때문입니다.
우리 관점에서는 백엔드의 메커니즘이 약간 다르더라도 Docker로 실행하는 것과 정확히 동일하게 작동하는 것처럼 보입니다.
즉, Conda 환경으로 실행할 준비가 되었습니다.
Docker와 Conda 혼합 및 일치
이러한 지시문은 프로세스별로 할당되므로 '혼합 및 일치'가 가능합니다. 즉 예를 들어 사용 중인 컴퓨팅 인프라가 둘 다 지원하는 경우 워크플로우의 일부 프로세스는 Docker로 실행하고 다른 프로세스는 Conda로 실행하도록 구성할 수 있습니다. 이 경우 구성 파일에서 Docker와 Conda를 모두 활성화합니다. 주어진 프로세스에 대해 둘 다 사용 가능한 경우 Nextflow는 컨테이너를 우선시합니다.
그리고 앞서 언급했듯이 Nextflow는 여러 다른 소프트웨어 패키징 및 컨테이너 기술을 지원하므로 이 두 가지로만 제한되지 않습니다.
핵심 정리¶
각 프로세스가 사용해야 하는 소프트웨어 패키지를 구성하는 방법과 기술 간에 전환하는 방법을 알게 되었습니다.
다음 단계¶
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라는 프로세스 지시문으로 설정됩니다.
기본적으로 local로 설정되어 있으므로 다음 구성이 암시됩니다:
다른 백엔드를 대상으로 실행자를 설정하려면 리소스 할당에 대해 위에서 설명한 것과 유사한 구문을 사용하여 원하는 실행자를 지정하기만 하면 됩니다(모든 옵션은 실행자 문서 참조).
경고
HPC에 연결하도록 설정되지 않았기 때문에 교육 환경에서는 실제로 이것을 테스트할 수 없습니다.
4.2. 실행 매개변수에 대한 백엔드별 구문 처리¶
대부분의 고성능 컴퓨팅 플랫폼은 리소스 할당 요청 및 제한(예: CPU 수 및 메모리)과 사용할 작업 큐의 이름과 같은 특정 매개변수를 지정할 수 있도록(때로는 요구하도록) 허용합니다.
불행히도 이러한 각 시스템은 작업을 정의하고 관련 스케줄러에 제출하는 방법을 정의하기 위해 서로 다른 기술, 구문 및 구성을 사용합니다.
예제
예를 들어 8개의 CPU와 4GB의 RAM이 필요하고 "my-science-work" 큐에서 실행되는 동일한 작업은 백엔드에 따라 다음과 같은 다른 방식으로 표현되어야 합니다.
#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
다행히도 Nextflow는 이 모든 것을 단순화합니다.
cpus, memory 및 queue와 같은 관련 속성을 지정할 수 있는 표준화된 구문을 제공합니다(다른 속성은 프로세스 지시문 참조). 한 번만 지정하면 됩니다.
그런 다음 런타임에 Nextflow는 이러한 설정을 사용하여 실행자 설정에 따라 적절한 백엔드별 스크립트를 생성합니다.
다음 섹션에서 해당 표준화된 구문을 다룰 것입니다.
핵심 정리¶
이제 다양한 종류의 컴퓨팅 인프라를 사용하도록 실행자를 변경하는 방법을 알게 되었습니다.
다음 단계¶
Nextflow에서 리소스 할당 및 제한을 평가하고 표현하는 방법을 학습합니다.
5. 컴퓨팅 리소스 할당 제어¶
대부분의 고성능 컴퓨팅 플랫폼은 CPU 수 및 메모리와 같은 특정 리소스 할당 매개변수를 지정할 수 있도록(때로는 요구하도록) 허용합니다.
기본적으로 Nextflow는 각 프로세스에 대해 단일 CPU와 2GB의 메모리를 사용합니다.
해당 프로세스 지시문은 cpus 및 memory라고 하므로 다음 구성이 암시됩니다:
구성 파일에서 추가 프로세스 지시문을 사용하여 모든 프로세스 또는 특정 명명된 프로세스에 대해 이러한 값을 수정할 수 있습니다. Nextflow는 선택한 실행자에 대한 적절한 지침으로 변환합니다.
그러나 어떤 값을 사용해야 하는지 어떻게 알 수 있습니까?
5.1. 워크플로우를 실행하여 리소스 사용률 보고서 생성¶
프로세스가 필요로 할 가능성이 있는 CPU와 메모리의 양을 미리 모르는 경우 일부 리소스 프로파일링을 수행할 수 있습니다. 즉, 일부 기본 할당으로 워크플로우를 실행하고 각 프로세스가 사용한 양을 기록한 다음 거기에서 기본 할당을 조정하는 방법을 추정합니다.
편리하게도 Nextflow에는 이를 수행하기 위한 내장 도구가 포함되어 있으며 요청 시 기꺼이 보고서를 생성합니다.
이를 위해 명령줄에 -with-report <filename>.html을 추가합니다.
보고서는 html 파일이며 다운로드하여 브라우저에서 열 수 있습니다. 왼쪽의 파일 탐색기에서 마우스 오른쪽 버튼을 클릭하고 Show preview를 클릭하여 교육 환경에서 볼 수도 있습니다.
보고서를 살펴보고 리소스 조정 기회를 식별할 수 있는지 확인하는 데 몇 분을 할애하세요. 할당된 것의 백분율로 사용률 결과를 보여주는 탭을 클릭해야 합니다.
사용 가능한 모든 기능에 대한 문서는 보고서를 참조하세요.
5.2. 모든 프로세스에 대한 리소스 할당 설정¶
프로파일링은 교육 워크플로우의 프로세스가 매우 가볍다는 것을 보여주므로 프로세스당 기본 메모리 할당을 1GB로 줄이겠습니다.
파이프라인 매개변수 섹션 앞에 nextflow.config 파일에 다음을 추가하세요:
이것은 소비하는 컴퓨팅 양을 줄이는 데 도움이 됩니다.
5.3. 특정 프로세스에 대한 리소스 할당 설정¶
동시에 cowpy 프로세스가 다른 프로세스보다 더 많은 리소스를 필요로 한다고 가정하겠습니다. 개별 프로세스에 대한 할당을 조정하는 방법을 시연하기 위해서입니다.
이 구성을 사용하면 모든 프로세스가 1GB의 메모리와 단일 CPU(암시된 기본값)를 요청하지만 cowpy 프로세스는 2GB와 2개의 CPU를 요청합니다.
팁
CPU가 적은 머신이 있고 프로세스당 많은 수를 할당하면 프로세스 호출이 서로 뒤에 대기하는 것을 볼 수 있습니다. 이는 Nextflow가 사용 가능한 것보다 더 많은 CPU를 요청하지 않도록 보장하기 때문입니다.
5.4. 업데이트된 구성으로 워크플로우 실행¶
시도해 보겠습니다. 구성 변경 전후의 성능을 비교할 수 있도록 프로파일링 보고서에 다른 파일 이름을 제공합니다.
이것은 매우 작은 워크로드이기 때문에 실제 차이를 느끼지 못할 것입니다. 하지만 이것이 실제 워크플로우의 성능과 리소스 요구 사항을 분석하는 데 사용할 접근 방식입니다.
프로세스의 리소스 요구 사항이 다를 때 매우 유용합니다. 추측이 아닌 실제 데이터를 기반으로 각 프로세스에 대해 설정한 리소스 할당을 적절하게 조정할 수 있습니다.
팁
이것은 리소스 사용을 최적화하기 위해 할 수 있는 것의 작은 맛보기일 뿐입니다. Nextflow 자체에는 리소스 제한으로 인해 실패한 작업을 재시도하는 정말 멋진 동적 재시도 로직이 내장되어 있습니다. 또한 Seqera Platform은 리소스 할당을 자동으로 최적화하기 위한 AI 기반 도구도 제공합니다.
5.5. 리소스 제한 추가¶
사용 중인 컴퓨팅 실행자 및 컴퓨팅 인프라에 따라 할당할 수 있는(또는 해야 하는) 것에 대한 몇 가지 제약이 있을 수 있습니다. 예를 들어 클러스터에서 특정 제한 내에 머물도록 요구할 수 있습니다.
resourceLimits 지시문을 사용하여 관련 제한을 설정할 수 있습니다. 프로세스 블록에 단독으로 있을 때의 구문은 다음과 같습니다:
Nextflow는 지정한 실행자에 따라 이러한 값을 적절한 지침으로 변환합니다.
교육 환경에서 관련 인프라에 액세스할 수 없기 때문에 이것을 실행하지 않을 것입니다.
그러나 이러한 제한을 초과하는 리소스 할당으로 워크플로우를 실행한 다음 .command.run 스크립트 파일에서 sbatch 명령을 조회하려고 하면 실행자에게 실제로 전송되는 요청이 resourceLimits에 지정된 값으로 제한되는 것을 볼 수 있습니다.
기관 참조 구성
nf-core 프로젝트는 광범위한 HPC 및 클라우드 실행자를 다루는 전 세계 다양한 기관에서 공유한 구성 파일 모음을 편집했습니다.
이러한 공유 구성은 그곳에서 일하는 사람들에게 유용하며 따라서 기관의 구성을 즉시 활용할 수 있으며, 자체 인프라에 대한 구성을 개발하려는 사람들을 위한 모델로도 유용합니다.
핵심 정리¶
리소스 사용률을 평가하기 위한 프로파일링 보고서를 생성하는 방법과 모든 프로세스 및/또는 개별 프로세스에 대한 리소스 할당을 수정하는 방법, HPC에서 실행하기 위한 리소스 제한을 설정하는 방법을 알게 되었습니다.
다음 단계¶
사전 설정된 구성 프로필을 설정하고 런타임에 전환하는 방법을 학습합니다.
6. 프로필을 사용하여 사전 설정된 구성 간 전환¶
작업 중인 프로젝트나 사용 중인 컴퓨팅 환경에 따라 파이프라인 구성을 사용자 정의할 수 있는 여러 가지 방법을 보여드렸습니다.
사용 중인 컴퓨팅 인프라에 따라 대체 설정 간에 전환하고 싶을 수 있습니다. 예를 들어 노트북에서 로컬로 소규모 테스트를 개발하고 실행한 다음 HPC 또는 클라우드에서 전체 규모의 워크로드를 실행하고 싶을 수 있습니다.
Nextflow를 사용하면 구성 파일 자체를 수정하지 않고도 명령줄 인수를 사용하여 런타임에 선택할 수 있는 다양한 구성을 설명하는 여러 프로필을 설정할 수 있습니다.
6.1. 로컬 개발과 HPC 실행 간 전환을 위한 프로필 생성¶
두 가지 대체 프로필을 설정하겠습니다. 하나는 Docker 컨테이너를 사용할 일반 컴퓨터에서 소규모 로드를 실행하기 위한 것이고, 다른 하나는 Conda 패키지를 사용할 Slurm 스케줄러가 있는 대학 HPC에서 실행하기 위한 것입니다.
6.1.1. 프로필 설정¶
파이프라인 매개변수 섹션 뒤, 출력 설정 앞에 nextflow.config 파일에 다음을 추가하세요:
대학 HPC의 경우 리소스 제한도 지정하고 있습니다.
6.1.2. 프로필로 워크플로우 실행¶
Nextflow 명령줄에서 프로필을 지정하려면 -profile 인수를 사용합니다.
my_laptop 구성으로 워크플로우를 실행해 보겠습니다.
명령 출력
보시다시피 이를 통해 런타임에 구성 간을 매우 편리하게 전환할 수 있습니다.
경고
Slurm 스케줄러에 액세스할 수 없기 때문에 univ_hpc 프로필은 교육 환경에서 제대로 실행되지 않습니다.
향후 이러한 것과 항상 함께 발생하는 다른 구성 요소를 발견하면 해당 프로필에 간단히 추가할 수 있습니다. 함께 그룹화하려는 다른 구성 요소가 있는 경우 추가 프로필을 생성할 수도 있습니다.
6.2. 테스트 매개변수 프로필 생성¶
프로필은 인프라 구성만을 위한 것이 아닙니다. 워크플로우 매개변수의 기본값을 설정하는 데도 사용할 수 있으므로 다른 사람이 적절한 입력 값을 직접 수집하지 않고도 워크플로우를 더 쉽게 시도할 수 있습니다. 이것을 매개변수 파일을 사용하는 대안으로 간주할 수 있습니다.
6.2.1. 프로필 설정¶
이 컨텍스트에서 기본값을 표현하는 구문은 test라는 이름의 프로필에 대해 다음과 같습니다:
워크플로우에 대한 테스트 프로필을 추가하면 profiles 블록은 다음과 같이 됩니다:
기술 구성 프로필과 마찬가지로 원하는 임의의 이름으로 매개변수를 지정하는 여러 다른 프로필을 설정할 수 있습니다.
6.2.2. 테스트 프로필로 워크플로우를 로컬로 실행¶
편리하게도 프로필은 상호 배타적이지 않으므로 다음 구문 -profile <profile1>,<profile2>(프로필 수에 관계없이)를 사용하여 명령줄에서 여러 프로필을 지정할 수 있습니다.
동일한 구성 요소에 대한 값을 설정하고 동일한 구성 파일에 설명된 프로필을 결합하면 Nextflow는 마지막으로 읽은 값(즉 파일에서 나중에 오는 것)을 사용하여 충돌을 해결합니다. 충돌하는 설정이 다른 구성 소스에 설정된 경우 기본 우선순위가 적용됩니다.
이전 명령에 테스트 프로필을 추가해 보겠습니다:
명령 출력
이것은 가능한 경우 Docker를 사용하고 custom-outdir-config/test 아래에 출력을 생성하며, 이번에는 캐릭터가 코미디 듀오 dragonandcow입니다.
파일 내용
_________
/ HOLà \
| HELLO |
\ BONJOUR /
---------
\ ^ /^
\ / \ // \
\ |\___/| / \// .\
\ /O O \__ / // | \ \ *----*
/ / \/_/ // | \ \ \ |
\@___\@` \/_ // | \ \ \/\ \
0/0/| \/_ // | \ \ \ \
0/0/0/0/| \/// | \ \ | |
0/0/0/0/0/_|_ / ( // | \ _\ | /
0/0/0/0/0/0/`/,_ _ _/ ) ; -. | _ _\.-~ / /
,-} _ *-.|.-~-. .~ ~
\ \__/ `/\ / ~-. _ .-~ /
\____(oo) *. } { /
( (--) .----~-.\ \-` .~
//__\\ \__ Ack! ///.----..< \ _ -~
// \\ ///-._ _ _ _ _ _ _{^ - - - - ~
즉, 워크플로우 코드와 함께 테스트 데이터 파일을 배포하는 한 누구나 명령줄이나 매개변수 파일을 통해 자체 입력을 제공하지 않고도 워크플로우를 빠르게 시도할 수 있습니다.
팁
외부에 저장된 더 큰 파일에 대한 URL을 가리킬 수 있습니다. Nextflow는 열린 연결이 있는 한 자동으로 다운로드합니다.
자세한 내용은 사이드 퀘스트 파일 작업을 참조하세요.
6.3. nextflow config를 사용하여 해결된 구성 확인¶
위에서 언급했듯이 때로는 결합하려는 프로필에서 동일한 매개변수를 다른 값으로 설정할 수 있습니다. 그리고 더 일반적으로 구성 요소를 저장할 수 있는 곳이 많으며 때로는 동일한 속성을 다른 곳에서 다른 값으로 설정할 수 있습니다.
Nextflow는 충돌을 해결하기 위해 설정된 우선순위를 적용하지만 직접 결정하기는 까다로울 수 있습니다. 그리고 충돌하는 것이 없더라도 구성할 수 있는 모든 가능한 장소를 조회하는 것은 지루할 수 있습니다.
다행히도 Nextflow에는 전체 프로세스를 자동화할 수 있는 config라는 편리한 유틸리티 도구가 포함되어 있습니다.
config 도구는 현재 작업 디렉토리의 모든 내용을 탐색하고 구성 파일을 수집하여 Nextflow가 워크플로우를 실행하는 데 사용할 완전히 해결된 구성을 생성합니다.
이를 통해 아무것도 시작하지 않고도 어떤 설정이 사용될지 알아낼 수 있습니다.
6.3.1. 기본 구성 해결¶
기본적으로 적용될 구성을 해결하려면 이 명령을 실행하세요.
명령 출력
이것은 명령줄에서 추가로 지정하지 않으면 얻을 수 있는 기본 구성을 보여줍니다.
6.3.2. 특정 설정이 활성화된 구성 해결¶
명령줄 매개변수를 제공하는 경우, 예를 들어 하나 이상의 프로필을 활성화하거나 매개변수 파일을 로드하는 경우 명령은 추가로 이를 고려합니다.
명령 출력
이것은 여러 구성 계층이 포함된 복잡한 프로젝트에 특히 유용합니다.
핵심 정리¶
최소한의 번거로움으로 런타임에 사전 설정된 구성을 선택하기 위해 프로필을 사용하는 방법을 알게 되었습니다. 더 일반적으로 다양한 컴퓨팅 플랫폼에 맞게 워크플로우 실행을 구성하고 분석의 재현성을 향상시키는 방법을 알게 되었습니다.
다음 단계¶
축하하고 스스로에게 큰 박수를 보내세요! 첫 번째 Nextflow 개발자 과정을 완료했습니다.
학습한 내용을 검토하고 다음 단계를 알아보려면 최종 과정 요약으로 이동하세요.
퀴즈¶
Nextflow가 자동으로 로드하는 구성 파일의 이름은 무엇입니까?
구성 파일과 명령줄 모두에서 동일한 매개변수가 설정된 경우 무엇이 우선합니까?
동일한 구성에서 Docker와 Conda를 모두 활성화할 수 있습니까?
Docker와 Conda가 모두 활성화되어 있고 프로세스에 두 지시문이 모두 있는 경우 어느 것이 우선합니까?
Nextflow 프로세스의 기본 메모리 할당은 무엇입니까?
구성 파일에서 특정 프로세스에 대한 리소스 요구 사항을 설정하는 방법은 무엇입니까?
리소스 사용률 보고서를 생성하는 명령줄 옵션은 무엇입니까?
resourceLimits 지시문은 무엇을 합니까?
Nextflow의 기본 실행자는 무엇입니까?
Nextflow를 실행할 때 매개변수 파일을 지정하는 방법은 무엇입니까?
프로필은 무엇에 사용할 수 있습니까? (해당하는 모든 항목 선택)
단일 명령에서 여러 프로필을 지정하는 방법은 무엇입니까?