새벽 3시에 오토스케일러가 노드 50대를 한꺼번에 올렸는데, 전부 ImagePullBackOff로 Pending 상태. 레지스트리가 대역폭 한도에 걸려서 throttling 먹은 거다. 이 경험 한 번이라도 해봤으면 CNCF가 올해 1월에 졸업시킨 Dragonfly라는 프로젝트가 왜 필요한지 바로 감이 올 거다.
레지스트리는 구조적으로 병목이다
컨테이너 이미지 배포의 기본 모델은 중앙집중형이다. 모든 노드가 하나의 레지스트리(또는 미러)에서 이미지를 당긴다. 노드 10대면 문제없다. 100대도 어찌저찌 버틴다. 근데 500대가 동시에 같은 이미지를 요청하면? 네트워크 대역폭이 천장을 찍는다.
클러스터가 커질수록, 이미지가 무거워질수록 상황은 악화된다. 요즘 ML 워크로드 이미지는 수 GB가 기본이고, CUDA 런타임에 모델 가중치에 의존성까지 넣으면 10GB를 넘기기도 한다. 이걸 노드마다 처음부터 끝까지 중앙 저장소에서 받는다는 건 솔직히 구조적 한계다.
"미러 늘리면 되지 않냐"는 질문이 나올 수 있는데, 미러도 결국 같은 중앙집중 모델의 복제본이다. 소스가 2개로 늘었을 뿐 근본적인 해결은 아니다.
P2P가 바꾸는 것
Dragonfly의 핵심 아이디어는 단순하다. 이미지를 조각(piece)으로 쪼개고, pull을 끝낸 노드가 다른 노드에게 조각을 나눠준다. BitTorrent 써봤으면 바로 이해될 원리다.
아키텍처 구성은 세 가지 컴포넌트로 나뉜다:
Scheduler — 어떤 peer가 어떤 piece를 가졌는지 추적하고, 최적의 다운로드 경로를 계산한다
Seed Peer — 원본 레지스트리에서 이미지를 최초로 받아서 나머지 peer에게 제공하는 초기 시드 역할
Peer (dfdaemon) — 각 노드에서 돌아가는 데몬. containerd의 프록시 미러로 설정되어 pull 요청을 가로챈다
여기서 결정적인 차이가 나온다. 노드가 많아질수록 오히려 빨라진다. 1대가 pull을 완료하면 그 노드 자체가 시드가 되어 뒤따르는 노드들에게 데이터를 전파한다. 500대가 동시에 시작해도, 앞서 받은 노드들이 뒤쪽 노드들한테 조각을 뿌려주니까 레지스트리에는 소수의 요청만 도달한다. 중앙집중형과 정반대의 스케일링 특성이다.
Alibaba 내부에서는 하루 수천만 개의 컨테이너 실행을 Dragonfly로 지원하고 있고, CNCF 공식 발표 기준으로 레지스트리 대역폭 최대 90% 절감, pull 시간은 분 단위에서 초 단위로 줄었다고 한다. 130개 이상의 조직에서 기여할 만큼 커뮤니티도 두텁다.
Nydus — 컨테이너 시작에 안 쓰는 레이어까지 왜 다 받나
Dragonfly의 서브 프로젝트인 Nydus는 한 단계 더 간다. 기존 OCI 이미지의 근본적인 한계 — 전체 레이어를 다 받아야 컨테이너를 시작할 수 있다는 구조 — 를 건드린다.
Nydus는 이미지를 lazy loading 가능한 포맷으로 변환한다. 컨테이너 기동에 당장 필요한 파일만 우선 받고, 나머지는 실제 파일 접근이 일어날 때 그때그때 fetch한다. Datadog의 사례가 인상적인데, 노드의 daemonset 기동 시간이 5분에서 수 초로 줄었다. 전체 이미지를 다 안 받아도 프로세스가 먼저 뜨니까 가능한 일이다.
containerd의 nydus-snapshotter를 통해 통합되고, nerdctl 0.22 이상에서도 쓸 수 있다. 기존 OCI 이미지를 nydus 포맷으로 변환하는 nydusify라는 CLI 도구도 있어서 마이그레이션 부담이 크지 않다.
AI 모델 배포에서 진짜 빛난다
여기서 요즘 가장 흥미로운 쓰임새가 나온다. LLM 가중치 파일 배포다.
70B 파라미터 모델의 가중치는 수십 GB다. GPU 노드 클러스터 전체에 이걸 뿌려야 하는데, 레지스트리 기반으로는 완전히 무너진다. Dragonfly는 OCI 아티팩트뿐 아니라 임의의 대용량 파일도 P2P로 배포할 수 있어서 모델 가중치 전달에 바로 쓸 수 있다.
CNCF가 졸업을 결정한 배경에도 이 AI 인프라 수요가 깔려 있다. 클라우드 네이티브 생태계가 마이크로서비스를 넘어 ML 워크로드까지 품으면서, "대용량 바이너리를 수백 대에 빠르게 깔아야 한다"는 오래된 문제가 다시 전면에 나온 셈이다.
붙여볼 생각이면 알아둘 것
Helm 차트 하나면 설치는 끝난다:
helm repo add dragonfly https://dragonflyoss.github.io/helm-charts/
helm install dragonfly dragonfly/dragonfly \
--namespace dragonfly-system --create-namespace설치 후 containerd config에서 registry mirror를 dfdaemon 주소로 잡아주면 된다. Dockerfile이나 이미지 빌드 파이프라인은 손댈 게 없다. 완전히 투명하게 동작한다.
Prometheus metrics 기본 제공에 OpenTelemetry 연동도 지원하고, 공식 Grafana 대시보드 템플릿까지 있다. 이미 모니터링 스택이 갖춰져 있으면 붙이기 수월하다.
다만 함정 하나 — Scheduler와 Seed Peer는 stateful 컴포넌트라 PV가 필요하다. 스토리지 프로비저닝이 제대로 안 되어 있으면 설치 단계에서부터 삐걱거린다. 멀티 클러스터를 쓰고 있다면 클러스터 간 네트워크 정책도 미리 확인해야 peer끼리 통신이 된다.
노드 50대 이상을 운영하면서 배포 때마다 이미지 pull에 시간 쏟고 있는 팀이라면, CNCF 졸업 프로젝트라는 검증 위에서 시작할 수 있다는 것만으로도 도입 허들이 한참 낮아졌다.