컨테이너 런타임과 학습 데이터 입력 성능
Apptainer, Podman, Enroot에서 ResNet-50 학습의 입력 파이프라인을 따로 떼어 측정한 연구
- 기간
- 2026.03 - 진행 중
- 정리한 곳
- Notion, 지능형데이터처리 연구실
- 분야
- 인프라·연구
연구실에서 컨테이너 런타임별로 딥러닝 학습의 데이터 입력 성능이 어떻게 다른지 측정하고 있습니다.
선행 연구는 Enroot와 Apptainer의 차이를 입력과 GPU 연산이 합쳐진 값으로만 보고했습니다. 그 차이가 데이터를 읽고 디코딩해 GPU로 넘기는 입력 계층에서 오는지 보려고, 단일 노드에서 입력 계층만 따로 쟀습니다.
Apptainer를 뜯어본 것
- 데몬 없음, 컨테이너 안팎이 같은 사용자, SIF 단일 파일, 격리보다 통합이라는 네 가지 특징을 커널 원리(user namespace, uid_map, NoNewPrivs, squashfuse)와 함께 정리
- GPU 연동(--nv), Slurm과 MPI 연동, Docker, Podman, Apptainer, Enroot 비교
- uid_map, 네임스페이스 inode, SIF 안의 squashfs, 서명한 SIF의 변조 탐지를 직접 확인하는 데모
실험
- Ryzen 9 9950X, RTX 5070, Ubuntu 24.04에서 host, Podman, Apptainer, Enroot를 마운트 방식까지 나눈 7개 조건 비교
- GPU 연산을 뺀 공급 처리량, 실제 학습 처리량, 입력 비용을 0으로 둔 수요 처리량을 나눠 측정
- 시나리오 스크립트, 실행기, 보고서 생성기로 된 벤치마크 킷 container-dl-bench를 직접 제작
알게 된 것
- 성능을 가른 건 런타임이 아니라 데이터 경로(커널 경로냐 FUSE냐)였습니다. ext4 대비 fuse-overlayfs의 파일 접근 처리량은 -64.8%였고, 런타임 사이 차이는 재현 오차(약 ±3%) 안이었습니다.
- 비용은 데이터를 옮기는 read가 아니라 openat, newfstatat처럼 경로를 해석하는 단계에 있었습니다.
- /proc을 도는 모니터링 도구가 일부 런타임에만 부담을 줘, 끄자 Apptainer가 5.06% 빨라졌습니다. 재는 도구가 결과를 바꿀 수 있다는 걸 배웠습니다.
- 빈 컨테이너 기동은 Apptainer가 133ms로 가장 빨랐지만 import torch까지 재면 2,392ms로 가장 느렸습니다. 무엇을 기동 완료로 보느냐에 따라 순위가 바뀝니다.
단일 노드, 단일 GPU에서의 결과이고 원인 분석을 이어 가고 있습니다.
다룬 주제
- Apptainer
- Podman
- Enroot
- user namespace
- SIF와 squashfs
- overlayfs와 FUSE
- PyTorch DataLoader
- strace
- 실험 설계