분산 학습을 위한 AWS 컴퓨팅 선택 가이드 (3편: 클러스터 구축과 운영)

분산 학습에서는 수십~수백 개 노드가 CUDA, cuDNN, NCCL, aws-ofi-nccl, PyTorch 등 동일한 소프트웨어 스택을 실행해야 한다. 노드 간 버전 차이가 작아도 통신 오류나 학습 실패로 이어질 수 있어, 실행 환경을 컨테이너로 고정하는 방식이 표준으로 자리 잡았다.

전통적인 Slurm HPC 환경에 Docker를 그대로 적용하기는 어렵다. Docker는 root 권한과 상시 실행되는 데몬을 요구하고, Slurm과 자원 할당·제한·어카운팅을 공유하지 않아 GPU·CPU·메모리 관리가 어긋나거나 작업 종료 후 컨테이너가 남을 수 있다.

이를 해결하는 대표적인 조합이 Enroot + Pyxis다.

• Enroot: root 권한과 상시 데몬 없이 컨테이너를 실행하는 NVIDIA 컨테이너 런타임
• Pyxis: Enroot를 Slurm과 연결해 잡 단위로 컨테이너를 실행하는 NVIDIA Slurm 플러그인
• .sqsh 이미지: CUDA, NCCL, PyTorch 등 검증된 실행 환경을 하나의 파일로 고정

Docker 이미지는 Enroot를 통해 .sqsh 파일로 변환할 수 있으며, 실무에서는 이를 노드별로 복사하지 않고 Amazon FSx for Lustre 같은 공유 파일시스템에 저장해 모든 노드가 동일한 이미지를 참조하도록 구성한다. Pyxis를 사용하면 기존 Slurm의 파티션, QOS, sbatch 워크플로를 유지한 채 --container-image 옵션만 추가해 컨테이너 기반 잡을 제출할 수 있다.

AWS 환경에서는 컨테이너 내부의 aws-ofi-nccl 버전도 중요하다. 해당 플러그인이 NCCL 통신을 EFA의 고속 경로로 연결하므로, CUDA·NCCL·aws-ofi-nccl 조합을 이미지 안에서 검증하고 고정해야 GPU 간 AllReduce 성능과 분산 학습 안정성을 확보할 수 있다.

AWS ParallelCluster 기반 아키텍처에서는 Head 노드의 Slurm 컨트롤러가 잡을 받아 컴퓨트 노드에 배치하고, 각 컴퓨트 노드의 Slurm 클라이언트가 Pyxis를 호출해 Enroot 컨테이너를 실행한다. 모든 컨테이너가 같은 .sqsh 이미지를 사용하므로 여러 노드와 GPU에서 CUDA, NCCL, PyTorch 등 핵심 환경이 일치한다.