Dragonfly 경량 배포 모델: 데이터베이스 없이 P2P 배포 구성하기
Dragonfly는 P2P 기술을 활용해 파일과 컨테이너 이미지 배포를 가속화하는 CNCF 프로젝트다. 대규모 레지스트리 트래픽을 분산시켜 Pull 병목을 해소하는 데 강점이 있지만, 표준 설치 방식은 상당한 인프라 부담을 수반한다. Scheduler, Seed Client, Client 외에도 Manager 컴포넌트가 필요하고, 이를 뒷받침하기 위해 MySQL과 Redis까지 운영해야 한다. 멀티 클러스터 환경에서는 이 구조가 합리적이지만, 단일 클러스터에서 레지스트리 과부하 해소만을 목적으로 한다면 지나치게 무거운 구성이다.
Manager가 하는 일과 제거 가능한 이유
Manager는 Dragonfly의 컨트롤 플레인 역할을 담당한다. 웹 콘솔 제공, 레지스트리 트리거 기반 사전 워밍(preheating) API 노출, 복수 P2P 클러스터 간 관계 관리, Scheduler와 Client에 대한 동적 설정 배포가 주요 기능이다. 상태 저장에는 MySQL, 캐싱 및 비동기 작업 분산에는 Redis를 사용한다.
그러나 단일 클러스터 환경에서 실질적으로 필요한 Manager의 핵심 기능은 동적 설정 배포 하나다. 이 설정은 스케줄링 제한, 블록리스트, Client가 Scheduler를 탐색하기 위한 엔드포인트 정보 등을 담은 YAML로 구성된다. Manager 주소가 설정되지 않으면 Scheduler와 Client는 Manager 없이 자율적으로 동작할 수 있도록 설계되어 있다. 즉, 데이터베이스 백엔드 없이도 P2P 배포의 핵심 기능은 온전히 유지된다.
경량 모델의 구성 방식
경량 배포 모델은 Manager 컨트롤 플레인을 Kubernetes 네이티브 프리미티브로 대체한다. Manager, MySQL, Redis를 제거하고 Scheduler만을 유일한 조정 컴포넌트로 사용하는 구조다. 동적 설정은 Kubernetes의 ConfigMap을 통해 주입되며, Scheduler 탐색은 Service나 DNS를 통해 처리된다.
# 경량 배포 예시: Manager 없이 Scheduler만 활성화
scheduler:
enable: true
manager:
enable: false
mysql:
enable: false
redis:
enable: false
이 구성은 단일 Helm 명령으로 전체 스택을 설치할 수 있다는 점에서 운영 진입 장벽을 크게 낮춘다. kind 클러스터와 같은 로컬 환경에서도 빠르게 검증이 가능하며, CI/CD 파이프라인에 통합하거나 개발 환경에서 Dragonfly의 P2P 동작을 실험하는 데 적합하다.
실무 적용 시 고려 사항
경량 모델은 다음과 같은 상황에서 특히 유용하다.
- 단일 클러스터 환경: 멀티 클러스터 간 설정 동기화가 필요 없는 경우
- 레지스트리 과부하 해소: 대규모 배포 이벤트 시 이미지 Pull 병목을 P2P로 분산하려는 경우
- 인프라 최소화: 별도의 DB 운영 부담 없이 Dragonfly 이점을 누리고 싶은 경우
- PoC 및 파일럿: 도입 타당성을 검토하는 초기 단계
반면 레지스트리 트리거 기반 사전 워밍, 웹 콘솔을 통한 운영 가시성, 멀티 클러스터 통합 관리가 필요하다면 Manager를 포함한 풀스택 구성이 여전히 필요하다. 경량 모델은 "기능의 축소"가 아니라 "필요한 기능만 선택적으로 운영하는 구성"으로 이해하는 것이 적절하다.
정리
- Manager, MySQL, Redis를 제거한 경량 Dragonfly 배포는 Scheduler만으로 단일 클러스터 P2P 배포를 구성할 수 있다
- 동적 설정은 Kubernetes ConfigMap과 네이티브 Service 탐색으로 대체되어 데이터베이스 의존성이 사라진다
- 레지스트리 과부하 해소나 도입 초기 단계에 적합하며, 멀티 클러스터·웹 콘솔·사전 워밍이 필요한 경우 풀스택 구성을 선택해야 한다