F26～F29를 다시 보면 — 무엇이 아직 안 고정되었나

F26에서 패키지 의존성을, F27～F29에서 실행 순서를 고정했습니다. 그런데 아직 고정하지 못한 것이 하나 남았습니다 — 운영체제 자체입니다. Pixi.toml이 같아도, 리눅스 커널 버전이나 시스템 라이브러리(glibc 등)가 다르면 미묘하게 다른 결과가 나올 수 있습니다. "내 컴퓨터에서는 됐는데 서버에서는 안 된다"는 익숙한 좌절의 근본 원인입니다. **컨테이너(container)**는 실행 환경 전체를 하나의 봉인된 단위로 묶어 이 문제를 없앱니다.

원리 — 가상머신이 아니라 프로세스 격리로 봉인하기

가상머신과의 결정적 차이

컨테이너를 처음 접하면 가상머신(VM)과 헷갈리기 쉽습니다. VM은 하드웨어 자체를 에뮬레이션해 게스트 OS 전체(커널 포함)를 새로 띄우는 반면, 컨테이너는 호스트 커널을 공유하면서 **네임스페이스(namespace)**와 cgroup이라는 리눅스 커널 기능으로 프로세스·파일시스템·네트워크만 격리합니다.

$\text{VM 부팅 시간} \approx \text{수십 초～수 분} \qquad \text{컨테이너 시작 시간} \approx \text{수백 밀리초～수 초}$

커널을 새로 띄우지 않기 때문에 컨테이너는 VM보다 훨씬 가볍고 빠르게 시작됩니다. 대신 호스트와 커널을 공유하므로 격리 수준은 VM보다 약합니다.

이미지 레이어와 캐싱

Docker 이미지는 여러 개의 읽기 전용 **레이어(layer)**가 쌓인 구조입니다. Dockerfile의 각 명령이 새 레이어를 만들고, 레이어의 내용이 바뀌지 않으면 그 레이어는 캐시되어 재사용됩니다.

# Dockerfile 예시 — bwa+samtools를 봉인한 최소 이미지
FROM condaforge/mambaforge:latest

RUN mamba install -y -c bioconda -c conda-forge \
    bwa=0.7.17 samtools=1.19 \
    && mamba clean -afy

WORKDIR /data
ENTRYPOINT ["bash"]

이 레이어 구조 덕분에, 이미지의 앞부분(예: 베이스 이미지, 자주 안 바뀌는 의존성 설치)은 캐시를 재사용하고 뒷부분(자주 바뀌는 애플리케이션 코드)만 새로 빌드하는 최적화가 가능합니다.

Docker와 Apptainer(구 Singularity) — 왜 HPC는 Docker를 그대로 안 쓰는가

기본적인 Docker(rootful) 설치는 고권한 데몬을 백그라운드에서 상시 실행하는 구조입니다. 다수 사용자가 공유하는 HPC 클러스터에서 각 사용자에게 이런 데몬 실행을 허용하는 것은 보안상 받아들이기 어렵습니다. Docker에는 rootless 모드도 있지만, 기관 정책·기능 제약을 함께 검토해야 합니다. Apptainer(구 Singularity)는 이 문제를 해결하기 위해 나온 HPC 특화 컨테이너 런타임으로, 별도의 상시 데몬 없이 일반 사용자 권한으로 컨테이너를 실행할 수 있도록 설계되었습니다.

$\text{Docker(rootful 기본값)}: \text{고권한 데몬} \qquad \text{Apptainer}: \text{데몬 불필요, 사용자 권한 실행}$

이런 이유로 클라우드·개인 워크스테이션에서는 Docker가, 대학·연구소 공유 HPC 클러스터에서는 Apptainer/Singularity가 흔히 표준으로 쓰입니다. nf-core(F29)가 -profile docker와 -profile singularity를 모두 지원하는 것도 이 두 환경을 함께 커버하기 위해서입니다.

손 계산 예제: 이미지 크기와 전송 시간

베이스 이미지 500MB에 bioconda 패키지 레이어 300MB가 얹힌 이미지가 있다고 합시다. 총 이미지 크기는

$500 + 300 = 800\text{MB}$

100Mbps(약 12.5MB/s) 네트워크로 클러스터 노드 10대에 각각 이 이미지를 처음 내려받는다면

$\frac{800\text{MB}}{12.5\text{MB/s}} \approx 64\text{초/노드}$

베이스 이미지 레이어가 이미 각 노드에 캐시되어 있다면(레이어 재사용), 실제로 새로 받아야 할 데이터는 300MB뿐이므로

$\frac{300\text{MB}}{12.5\text{MB/s}} = 24\text{초/노드}$

레이어 캐싱이 실제 배포 시간에 미치는 영향을 이렇게 어림잡아볼 수 있습니다.

실습: Biocontainers 이미지로 즉시 도구 실행하기

# SageMaker Studio Lab 또는 Docker가 설치된 환경.
# Biocontainers는 Bioconda 패키지마다 자동 생성되는 공식 컨테이너 이미지 저장소입니다.

# 직접 이미지를 빌드하지 않고도, samtools가 이미 봉인된 이미지를 바로 받아 씁니다.
docker pull quay.io/biocontainers/samtools:1.19--h50ea8bc_1

docker run --rm -v $(pwd):/data quay.io/biocontainers/samtools:1.19--h50ea8bc_1 \
  samtools view -h /data/sample.bam | head -5

# Apptainer로 동일 이미지 실행 (HPC 환경, 데몬 없이 사용자 권한으로)
apptainer exec docker://quay.io/biocontainers/samtools:1.19--h50ea8bc_1 \
  samtools view -h sample.bam | head -5

-v $(pwd):/data는 호스트의 현재 디렉터리를 컨테이너 안 /data 경로에 마운트하는 옵션입니다. 컨테이너 자체는 격리되어 있지만, 이렇게 명시적으로 마운트한 경로를 통해서만 호스트와 파일을 주고받는다는 점이 컨테이너 격리의 핵심입니다.

CS 매핑

• OS 수준 가상화(OS-level virtualization): 네임스페이스·cgroup으로 프로세스를 격리하는 컨테이너 기술은 운영체제 수업에서 다루는 프로세스 격리·자원 제한 메커니즘의 실무적 응용입니다.
• 레이어 캐싱과 콘텐츠 주소화: Docker 이미지 레이어가 해시로 식별되고 캐시되는 방식은, F28에서 다룬 Nextflow -resume의 콘텐츠 해시 캐싱과 같은 설계 원리를 공유합니다.
• 불변 인프라(immutable infrastructure): 컨테이너 이미지를 한 번 빌드하면 실행 중 변경하지 않고 새 버전은 새 이미지로 교체하는 관행은, 클라우드 인프라 관리의 불변 인프라 패턴과 동일한 철학입니다.

자주 만나는 결함

• Docker 이미지를 특권(privileged) 모드로 HPC에 그대로 요청: 대부분의 HPC 관리자는 보안상 이유로 Docker 데몬 실행을 허용하지 않습니다. 클러스터 환경이면 처음부터 Apptainer 호환성을 염두에 두고 이미지를 설계해야 합니다.
• 컨테이너 안에서 대용량 결과 파일 생성 후 마운트 누락: 볼륨 마운트가 없으면 결과는 컨테이너의 쓰기 레이어에만 남아 회수·관리하기 어렵고, --rm으로 실행했다면 컨테이너 삭제와 함께 사라집니다. 결과물이 저장되어야 할 경로는 반드시 호스트와 마운트되어 있는지 확인해야 합니다.

더 깊게 파고 싶다면

본문은 BPD 연구진이 직접 재구성한 서술입니다. 원 논문과 공식 자료로 심화해봅시다.

• Biocontainers 원 논문: da Veiga Leprevost et al. (2017), BioContainers: an open-source and community-driven framework for software standardization, Bioinformatics 33(16).
• Apptainer(Singularity) 원 논문: Kurtzer et al. (2017), Singularity: Scientific containers for mobility of compute, PLOS ONE 12(5).
• Broad Institute — 컨테이너 실무 가이드: GATK4 공식 컨테이너 활용 문서.

다음 편(F31)에서는 이렇게 봉인한 컨테이너를 실제 HPC 클러스터의 Slurm 스케줄러 위에서 대규모로 돌리는 방법과 I/O 병목을 다룹니다.