현대 인프라는 컴퓨팅 자원을 프로비저닝(provisioning)하는 데는 매우 뛰어나지만, 아티팩트 전달(artifact delivery)은 여전히 흔한 병목 현상입니다. 수백 또는 수천 개의 노드가 동시에 동일한 이미지, 모델 또는 파일이 필요할 때, 오리진(origin) 시스템은 종종 과부하 상태가 되며, 이는 확장을 컴퓨팅 문제가 아닌 트래픽 문제로 변질시킵니다.

Dragonfly는 이 문제를 해결하기 위해 구축된 CNCF Graduated 프로젝트입니다. Dragonfly는 P2P 기술을 기반으로 효율적이고 안정적이며 안전한 데이터 분산을 제공하며, 파일, 컨테이너 이미지, OCI 아티팩트(artifacts), AI 모델, 캐시(caches), 로그(logs) 및 종속성(dependencies)의 대규모 전달을 지원합니다.

Dragonfly peer-to-peer distribution across a Kubernetes cluster
Dragonfly 아키텍처: Manager, Scheduler, Seed Peer, 그리고 Peer 역할

Dragonfly가 해결하는 인프라 문제

Kubernetes 중심 시스템에서는 배포 급증(deployment bursts)이 동일한 아티팩트에 대한 수많은 동시 요청을 유발할 수 있습니다. 해당 오리진은 레지스트리(registry), 오브젝트 스토어(object store), 내부 아티팩트 서버 또는 퍼블릭 모델 허브(public model hub)일 수 있지만, 장애 모드는 유사합니다. 즉, 너무 많은 노드가 동시에 같은 장소에서 동일한 데이터를 직접 가져오려 한다는 점입니다.

이 문제는 AI 환경에서 훨씬 더 심각해집니다. Dragonfly 유지 관리자들은 현대의 모델 가중치(model weights)가 수백 메가바이트에서 수백 기가바이트 또는 심지어 테라바이트 단위로 성장하고 있다고 설명하며, 이는 모델 분산을 핵심 인프라 과제로 만듭니다.

CNCF Dragonfly의 사례에 따르면, 130 GB 모델을 200개의 GPU 노드에 분산할 경우 일반적인 다운로드 방식으로는 26 TB의 오리진 트래픽이 발생하지만, Dragonfly는 초기 가져오기(fetch) 이후 P2P 분산을 사용하여 이를 약 130 GB로 줄일 수 있습니다.

결론: 컴퓨팅은 아티팩트 전달보다 더 빠르게 확장되었으며, 이러한 격차는 대규모 Kubernetes 또는 AI 워크로드를 실행하는 모든 팀에 피해를 줍니다.

Dragonfly의 작동 방식

Dragonfly는 시스템을 **네 가지 역할 (four roles)**로 나눕니다:

클러스터 내 첫 번째 다운로드

1. 클라이언트가 HTTP/HTTPS 프록시 (proxy) 또는 gRPC를 통해 아티팩트 (artifact)를 요청합니다.
2. 피어 (Peer)가 스케줄러 (Scheduler)에 태스크 (task)를 등록합니다.
3. 스케줄러가 **시드 피어 (Seed Peer)**를 트리거하여 소스 (source)로부터 단 한 번 가져오도록 합니다.
4. 태스크는 조각 (pieces)으로 분할되며, 조각들은 시드 피어(Seed Peer) → 피어 (Peer)로 스트리밍됩니다.
5. 조각의 메타데이터 (metadata)가 향후 스케줄링을 위해 스케줄러 (Scheduler)로 보고됩니다.

후속 다운로드

• 조각이 로컬에 존재하는 경우 → 즉시 조립하여 반환합니다 (스케줄러와 접촉하지 않음).
• 그렇지 않은 경우 → 스케줄러가 해당 조각을 이미 보유하고 있는 다른 피어들을 할당합니다.
• 피어는 여러 부모 (multiple parents)로부터 병렬로 조각을 다운로드하여 파일을 조립합니다.

Dragonfly architecture showing Manager, Scheduler, Seed Peer, and Peer roles
조각 기반 P2P 분산 흐름 (Piece-based P2P distribution flow)

Dragonfly가 지금 중요한 이유

Dragonfly의 타이밍은 매우 중요합니다. CNCF는 이 프로젝트에 대해 다음과 같이 명시합니다:

• 프로덕션 환경에서 **하루 수천만 건의 컨테이너 실행 (container launches)**을 지원합니다.
• 스토리지 대역폭 (storage bandwidth)을 최대 90%까지 절감할 수 있습니다.
• 대규모 환경에서 실행 시간을 분 단위에서 초 단위로 단축할 수 있습니다.

이것만으로도 플랫폼 엔지니어링 (platform engineering) 측면에서 중요하지만, AI 관점은 오늘날 이를 더욱 관련성 있게 만듭니다.

AI 워크로드 (AI workloads)는 다음과 같은 이유로 아티팩트 분산 (artifact distribution)을 더 어렵게 만듭니다:

• 모델 (Models)의 크기가 매우 큽니다 (수백 GB에서 TB 단위).
• **시작 지연 시간 (Startup latency)**이 추론 처리량 (inference throughput)과 비용에 직접적인 영향을 미칩니다.
• 동일한 파일이 종종 많은 노드(nodes)에 걸쳐 반복적으로 전달되어야 합니다.
• 외부 허브 (Hugging Face, ModelScope)는 **속도 제한 (rate limits)**과 데이터 송신 비용 (egress costs)을 부과합니다.

Dragonfly는 이제 Hugging Face 및 ModelScope를 위한 네이티브 통합 경로를 포함하여, AI 학습 및 추론 분산 워크플로우 (AI training and inference distribution workflows)를 가속화하는 것을 명시적인 목표로 삼고 있습니다.

두드러지는 기능들

Dragonfly의 핵심 역량은 단순히 순수한 속도에 관한 것이 아니라 **운영 환경에서의 신뢰성(production reliability)**에 관한 것입니다:

최근 개선 사항 (v2.4.0)

최신 프로젝트 발표에서 유지보수자들은 Vortex 전송 프로토콜(TLV 기반)을 도입했으며 다음 내용을 보고했습니다:

• gRPC(TCP Vortex) 대비 대용량 파일 다운로드 시간 약 50% 감소
• gRPC(QUIC Vortex) 대비 약 40% 감소
• 스마트한 사전 예열(preheating), 저장소 전반에 걸친 중복 다운로드를 방지하기 위한 해시 기반 작업 식별.

클라우드 네이티브 AI 스택에서 Dragonfly의 위치

Dragonfly 이야기에서 가장 흥미로운 변화 중 하나는 이것이 단순히 이미지 가속화에 관한 것이 아니라는 점입니다. 이는 실용적인 모델 배포 계층(layer for model delivery), 레지스트리 기반 모델 관리(registry-based model management), 그리고 쿠버네티스 네이티브 추론 워크플로우(Kubernetes-native inference workflows)가 되고 있습니다. 프로젝트 자료에 따르면, 모델 아티팩트가 일회성 다운로드로 처리되는 대신 버전화되고, 저장되며, 사전 예열되고, 추론 컨테이너에 마운트되는 워크플로우를 설명합니다. 이러한 방향은 플랫폼 팀이 AI 인프라를 관리하려는 방식과 잘 일치합니다: 플랫폼 팀은 소프트웨어 아티팩트에 사용되는 것과 동일한 운영 규율을 가지고 재현 가능하고 효율적으로 AI 인프라를 관리하기를 원합니다.

제가 플랫폼 팀들이 관심을 가져야 하는 이유

유지보수자의 관점에서 볼 때, Dragonfly는

• 더 빠른 AI 및 AI 워크로드 (AI workloads)
• 낮은 오리진 부하 (origin load) 및 이그레스 비용 (egress cost)
• 버스트성 (bursty) 멀티 노드 컴퓨팅을 위한 이그레스 비용 감소

KubeCon 청중들에게 전달할 가장 강력한 메시지는 간단합니다:
컴퓨팅은 아티팩트 전달 (artifact delivery)보다 더 빠르게 확장되었으며, Dragonfly는 Kubernetes 시대의 인프라를 위해 구축된 시스템으로 그 격차를 메웁니다. 이것이 바로 이 프로젝트가 단순히 역사적으로 흥미로운 것을 넘어, 지금 이 시점에 새롭게 중요하게 느껴지는 이유입니다.

소스 링크

• Dragonfly 문서: d7y.io/docs/next
• CNCF 프로젝트 페이지: cncf.io/projects/dragonfly
• CNCF 졸업(Graduation) 발표: cncf.io announcement
• Hugging Face 통합 가이드: d7y.io/docs/.../hugging-face/
• P2P AI 모델 배포 블로그: cncf.io blog
• v2.4.0 프로젝트 발표:

시리즈의 다음 내용

GitHub: keda-gpu-scaler | gpu-mcp-server

Pavan Madduri는 W.W. Grainger의 시니어 클라우드 플랫폼 엔지니어(Senior Cloud Platform Engineer)이자, CNCF Golden Kubestronaut이며, CNCF TAG Workloads Foundation의 테크 리드(Tech Lead)입니다. 그는 keda-gpu-scaler 및 gpu-mcp-server를 유지 관리하며, KEDA, Volcano, Dragonfly를 포함한 CNCF 프로젝트에 기여하고 있습니다. GitHub에서 그를 찾을 수 있습니다.