목차
안녕하세요, 13년차 서버실 지킴이입니다. 🤓
Kubernetes(쿠버네티스) 환경에서 애플리케이션을 운영하다 보면, 영구 스토리지(Persistent Storage)의 중요성을 정말 뼈저리게 느끼게 됩니다. Pod(파드)가 재시작되거나 다른 노드로 옮겨가도 데이터는 안전하게 보존되어야 하니까요. 특히 저처럼 홈랩(Homelab)에서 이것저것 실험하며 삽질을 즐기는 사람이라면, 안정적이고 성능 좋은 스토리지를 찾는 데 꽤 많은 시간을 투자하게 되죠. 저도 그랬거든요! 🤔
오늘은 제가 직접 홈랩에서 Longhorn(롱혼)과 Rook-Ceph(룩-세프) 두 가지 Kubernetes 영구 스토리지 솔루션을 설치하고, FIO(Flexible I/O Tester) 벤치마크 툴로 성능을 비교해본 경험을 공유해드리려고 합니다. 과연 어떤 녀석이 제 환경에 더 적합했을까요? 저의 삽질 여정을 따라오시면서 여러분의 Kubernetes 스토리지 선택에 도움이 되시길 바랍니다!
왜 영구 스토리지가 필요할까요?
Kubernetes는 기본적으로 컨테이너화된 애플리케이션을 배포하고 관리하는 데 최적화되어 있어요. 그런데 컨테이너는 휘발성(ephemeral)이라는 특징을 가지고 있거든요. 즉, 컨테이너가 죽거나 재시작되면 그 안에 저장된 데이터는 사라져 버린다는 뜻이죠. 데이터베이스나 파일 서버처럼 데이터를 영구적으로 보관해야 하는 애플리케이션에는 치명적일 수 있습니다.
이런 문제를 해결하기 위해 Kubernetes에서는 영구 볼륨(Persistent Volume, PV)과 영구 볼륨 클레임(Persistent Volume Claim, PVC)이라는 개념을 도입했어요. 쉽게 말해, 스토리지 시스템으로부터 저장 공간을 할당받아 Pod가 데이터를 안정적으로 쓰고 읽을 수 있게 해주는 기능이라고 보시면 됩니다. 그리고 이런 영구 볼륨을 동적으로 프로비저닝(provisioning)해주는 역할을 하는 것이 바로 CSI(Container Storage Interface) 드라이버를 기반으로 하는 분산 스토리지 솔루션들이죠. 오늘 다룰 Longhorn과 Rook-Ceph가 바로 그런 친구들입니다.
Kubernetes 클러스터에서 영구 스토리지가 어떻게 작동하는지 대략적인 아키텍처를 그려봤어요. Pod가 PVC를 요청하면, CSI 드라이버가 백엔드 스토리지 시스템에 PV를 생성하고 Pod에 연결해주는 방식이죠. 이 과정에서 Longhorn이나 Rook-Ceph 같은 분산 스토리지 솔루션이 그 백엔드 역할을 하는 겁니다.
Longhorn과 Rook-Ceph, 넌 누구니?
본격적인 벤치마크에 앞서, 두 솔루션에 대해 간략하게 알아볼까요? 저도 처음엔 이름만 듣고 뭐가 뭔지 헷갈렸거든요. 😅
Longhorn (롱혼)
- 특징: Rancher Labs에서 개발한 오픈소스 분산 블록 스토리지 솔루션이에요. Kubernetes 위에서 컨테이너 형태로 동작하며, 각 노드의 로컬 스토리지를 모아 분산 볼륨을 생성합니다. CSI 드라이버를 기본으로 제공해서 Kubernetes와 통합이 정말 쉬워요. 제가 직접 써보니, 설치도 비교적 간단하고 웹 UI가 직관적이어서 관리하기 편하더라고요. 홈랩이나 소규모 환경에 많이 추천되는 이유를 알겠더군요.
- 장점: 가벼움, 설치 및 관리 용이, 스냅샷/백업/복원 기능 내장, DR(재해 복구) 지원.
Rook-Ceph (룩-세프)
- 특징: Rook는 Kubernetes 네이티브 스토리지 오케스트레이터이고, Ceph(세프)는 강력하고 성숙한 오픈소스 분산 스토리지 시스템이에요. Rook는 Ceph를 Kubernetes 클러스터 위에 배포하고 관리하는 오퍼레이터(Operator) 역할을 합니다. 오브젝트 스토리지(Object Storage), 블록 스토리지(Block Storage), 파일 스토리지(File Storage)를 모두 지원하는 만능 재주꾼이죠. 다만, Ceph 자체가 워낙 복잡한 시스템이라 Rook를 통해 배포해도 초기 설정과 관리에 공수가 좀 들어가는 편이에요. 대규모 프로덕션 환경에서 많이 사용됩니다.
- 장점: 뛰어난 확장성, 높은 가용성, 다양한 스토리지 타입 지원, 강력한 성능(하드웨어에 따라).
두 솔루션의 주요 특징을 표로 정리해봤어요.
| 구분 | Longhorn | Rook-Ceph |
|---|---|---|
| 개발사/기반 | Rancher Labs / 분산 블록 스토리지 | Rook (오퍼레이터) + Ceph (분산 스토리지) |
| 스토리지 타입 | 블록 스토리지 | 블록, 오브젝트, 파일 스토리지 |
| 설치 난이도 | 쉬움 (Helm) | 중간 ~ 어려움 (kubectl apply) |
| 관리 UI | 직관적인 웹 UI | Ceph Dashboard (별도 설치), Grafana 연동 |
| 확장성 | 중간 (수십 TB 규모) | 매우 높음 (페타바이트 규모) |
| 주요 사용처 | 홈랩, 소규모 개발/테스트, 엣지 컴퓨팅 | 대규모 프로덕션, 클라우드 인프라 |
벤치마크 환경 구축하기
저의 홈랩 환경은 다음과 같았습니다. 실제 벤치마크 결과는 하드웨어 스펙, 네트워크 환경, Kubernetes 설정 등에 따라 크게 달라질 수 있다는 점을 미리 말씀드려요! ⚠️
- Kubernetes Cluster: 3 Node (1 Master, 2 Worker)
- OS: Ubuntu Server 22.04 LTS
- CPU: Intel i5-10400 (각 노드당 6코어 12스레드)
- RAM: 32GB (각 노드당)
- Storage: NVMe SSD 500GB (각 노드당, 스토리지용으로 할당)
- Network: 1Gbps Ethernet
벤치마크 툴로는 FIO (Flexible I/O Tester)를 사용했어요. FIO는 디스크 I/O 성능을 측정하는 데 널리 사용되는 강력한 도구예요. 순차 읽기/쓰기, 랜덤 읽기/쓰기 등 다양한 패턴으로 I/O를 발생시켜 실제 워크로드와 유사한 환경을 만들 수 있거든요.
Longhorn 설치 및 설정
Longhorn은 Helm(헬름) 차트를 이용하면 정말 쉽게 설치할 수 있어요. 저도 처음엔 혹시나 복잡할까 봐 걱정했는데, 생각보다 너무 간단해서 놀랐어요. 🎉
- Helm Repository 추가:
helm repo add longhorn https://charts.longhorn.io helm repo update - Longhorn 설치: (기본 설정으로 설치했습니다)
helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace - Longhorn UI 접속:설치가 완료되면, Longhorn UI에 접속할 수 있도록 Ingress(인그레스, 외부 트래픽 진입점)나 NodePort(노드포트)를 설정해줘요. 저는 간단하게 NodePort로 열어서 접속했어요.
kubectl -n longhorn-system get svc longhorn-frontend # 출력되는 NodePort를 확인하여 접속- StorageClass 확인 및 볼륨 생성:Longhorn이 설치되면 기본적으로
longhorn이라는 StorageClass(스토리지클래스)가 생성돼요. 이걸 이용해서 PVC를 생성하고 Pod에 마운트하면 끝입니다. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: longhorn-pvc spec: accessModes: - ReadWriteOnce storageClassName: longhorn resources: requests: storage: 10Gi
Longhorn 웹 UI에 접속하면 현재 클러스터의 스토리지 상태, 노드별 디스크 사용량, 볼륨 목록 등을 한눈에 확인할 수 있어요. 시각적으로 깔끔하고 직관적이라서 관리하기 정말 편하더라고요. 💡
Longhorn 대시보드 화면이에요. 생성된 볼륨, 노드의 스토리지 상태 등을 쉽게 확인할 수 있어요.
Rook-Ceph 설치 및 설정
Rook-Ceph는 Longhorn보다 설정할 부분이 많아서, 처음엔 "이게 다 뭔가..." 싶었어요. 하지만 공식 문서(Official Documentation)를 차근차근 따라가면 충분히 설치할 수 있어요. 저는 helm 대신 kubectl apply -f 방식으로 진행했습니다.
- Rook Operator 배포:먼저 Rook Operator를 배포해요. 이 오퍼레이터가 Ceph 클러스터를 관리하는 역할을 합니다.
git clone --single-branch --branch v1.11.x https://github.com/rook/rook.git cd rook/deploy/examples kubectl create -f crds.yaml -f common.yaml -f operator.yaml- Ceph Cluster 배포:Ceph 클러스터를 배포해요. 이 과정에서 어떤 디스크를 Ceph 스토리지로 사용할지 지정해줘야 해요. 저는 각 워커 노드의 NVMe SSD를 사용하도록 설정했습니다.
cluster.yaml파일에서storage섹션에useAllNodes: true와useAllDevices: true를 설정하여 모든 노드의 모든 디바이스를 사용하도록 했어요. 실제 운영 환경에서는 특정 디스크만 사용하도록 명시하는 것이 좋습니다. kubectl create -f cluster.yaml- Ceph Block Pool 및 StorageClass 생성:Ceph 클러스터가 안정화되면, 블록 스토리지를 위한 CephBlockPool(세프 블록 풀)과 StorageClass를 생성해요.
storageclass.yaml파일은 다음과 비슷하게 생겼을 겁니다. apiVersion: ceph.rook.io/v1 kind: CephBlockPool metadata: name: replicapool namespace: rook-ceph spec: failureDomain: host replicated: size: 3 # 데이터 복제본 수 --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rook-ceph-block provisioner: rook-ceph.rbd.csi.ceph.com parameters: clusterID: rook-ceph pool: replicapool imageFormat: "2" imageFeatures: "layering" csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph reclaimPolicy: Delete allowVolumeExpansion: true mountOptions: - discardkubectl create -f csi/rbd/storageclass.yaml- PVC 생성:Longhorn과 마찬가지로, 생성된
rook-ceph-blockStorageClass를 이용해 PVC를 생성해요. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: rook-ceph-pvc spec: accessModes: - ReadWriteOnce storageClassName: rook-ceph-block resources: requests: storage: 10Gi
Rook-Ceph 클러스터의 내부 구성도예요. Ceph의 여러 구성요소(MON, OSD, MGR)가 Pod 형태로 Kubernetes 클러스터 위에서 동작하는 것을 볼 수 있어요.
FIO 벤치마크 실행 및 결과 분석
두 스토리지 솔루션의 PVC를 각각 생성한 후, FIO를 실행할 Pod를 띄워 벤치마크를 진행했어요. 저는 주로 랜덤 읽기/쓰기(Random Read/Write)와 순차 읽기/쓰기(Sequential Read/Write) 성능을 중점적으로 살펴봤습니다. 블록 크기(Block Size)는 4KB와 1MB로 다양하게 테스트해봤거든요.
FIO Pod를 위한 YAML 예시예요. 이 Pod가 PVC를 마운트하여 FIO 테스트를 수행합니다.
apiVersion: v1
kind: Pod
metadata:
name: fio-test-pod
spec:
restartPolicy: Never
containers:
- name: fio-container
image: ghcr.io/fio/fio:latest # FIO 이미지를 사용합니다.
command: ["/bin/bash", "-c"]
args:
- |
mkdir -p /mnt/data
fio --name=random-write --ioengine=libaio --iodepth=64 --rw=randwrite --bs=4k --size=1G --numjobs=1 --runtime=60 --group_reporting --filename=/mnt/data/testfile
fio --name=random-read --ioengine=libaio --iodepth=64 --rw=randread --bs=4k --size=1G --numjobs=1 --runtime=60 --group_reporting --filename=/mnt/data/testfile
fio --name=sequential-write --ioengine=libaio --iodepth=16 --rw=write --bs=1M --size=2G --numjobs=1 --runtime=60 --group_reporting --filename=/mnt/data/testfile_seq
fio --name=sequential-read --ioengine=libaio --iodepth=16 --rw=read --bs=1M --size=2G --numjobs=1 --runtime=60 --group_reporting --filename=/mnt/data/testfile_seq
volumeMounts:
- name: test-volume
mountPath: /mnt/data
volumes:
- name: test-volume
persistentVolumeClaim:
claimName: longhorn-pvc # 또는 rook-ceph-pvc
여러 번의 테스트를 통해 제가 관찰한 결과는 대략 이랬어요. (⚠️ 이 수치는 제 특정 홈랩 환경에서 얻은 결과이며, 환경에 따라 크게 달라질 수 있음을 다시 한번 강조합니다!)
| 테스트 항목 (4KB BS) | Longhorn (평균) | Rook-Ceph (평균) | 비고 |
|---|---|---|---|
| 랜덤 쓰기 IOPS | 약 1,500 ~ 2,500 | 약 3,000 ~ 5,000 | Rook-Ceph가 우위 |
| 랜덤 쓰기 대역폭 (MB/s) | 약 6 ~ 10 | 약 12 ~ 20 | Rook-Ceph가 우위 |
| 랜덤 읽기 IOPS | 약 2,000 ~ 3,500 | 약 4,000 ~ 6,500 | Rook-Ceph가 우위 |
| 랜덤 읽기 대역폭 (MB/s) | 약 8 ~ 14 | 약 16 ~ 26 | Rook-Ceph가 우위 |
| 테스트 항목 (1MB BS) | Longhorn (평균) | Rook-Ceph (평균) | 비고 |
| 순차 쓰기 대역폭 (MB/s) | 약 80 ~ 120 | 약 150 ~ 250 | Rook-Ceph가 우위 |
| 순차 읽기 대역폭 (MB/s) | 약 100 ~ 150 | 약 200 ~ 300 | Rook-Ceph가 우위 |
결과를 보면, 제 홈랩 환경에서는 Rook-Ceph가 전반적으로 Longhorn보다 더 높은 IOPS와 대역폭 성능을 보여줬어요. 특히 작은 블록 크기의 랜덤 I/O에서 Ceph의 강점이 두드러지더라고요. Longhorn은 복제본(replica) 수가 늘어날수록 성능 하락이 좀 더 눈에 띄는 경향이 있었고, Ceph는 안정적으로 성능을 유지했습니다.
Longhorn과 Rook-Ceph의 FIO 벤치마크 결과를 시각적으로 비교한 그래프예요. Rook-Ceph가 전반적으로 높은 성능을 보였습니다.
삽질 경험과 트러블슈팅 ⚠️
솔직히 말씀드리면, 순조롭게만 진행된 건 아니었어요. 삽질 좀 했습니다 ㅎㅎ. 몇 가지 기억에 남는 경험을 공유해볼게요.
- Longhorn: 네트워크 대역폭과 복제본 수
처음 Longhorn을 설치하고 테스트했을 때, 생각보다 성능이 안 나와서 당황했어요. 알고 보니, Longhorn은 네트워크를 통해 볼륨 데이터를 복제(replication)하기 때문에, 노드 간 네트워크 대역폭이 정말 중요하더라고요. 제 1Gbps 네트워크 환경에서는 복제본 수를 3개로 설정했을 때 쓰기 성능이 꽤 많이 떨어지는 것을 확인했어요. 복제본 수가 늘어날수록 안정성은 높아지지만, 그만큼 네트워크 오버헤드(overhead)가 커져서 성능에 영향을 미친다는 점! 홈랩에서는 2개로 줄여서 사용하니 훨씬 나아졌습니다. - Rook-Ceph: OSD 인식 문제와 초기 설정
Rook-Ceph는 초기 설정이 Longhorn보다 훨씬 복잡했어요. 특히 OSD(Object Storage Daemon)가 디스크를 제대로 인식하지 못해서 한참을 헤맸거든요. 디스크가 이미 파티셔닝(partitioning)되어 있거나, 이전에 다른 용도로 사용된 흔적이 남아있으면 Rook-Ceph가 제대로 디스크를 잡지 못하는 경우가 있더라고요.ceph-volume lvm zap --destroy /dev/sdX같은 명령어로 디스크를 완전히 초기화해주거나,lsblk -f명령어로 디스크의 파일 시스템(filesystem) 정보를 꼼꼼히 확인해서 해결했어요. Ceph의 CRD(Custom Resource Definition)와 설정 파일에 대한 이해가 필요하다는 것을 다시 한번 깨달았습니다.
결론 및 선택 가이드
제 홈랩 벤치마크 경험을 바탕으로 Longhorn과 Rook-Ceph에 대한 저의 생각을 정리해봤어요.
| 솔루션 | 장점 | 단점 | 추천 시나리오 |
|---|---|---|---|
| Longhorn |
|
|
|
| Rook-Ceph |
|
|
|
제 홈랩에서는 아무래도 설치 및 관리의 용이성 때문에 Longhorn에 손이 더 자주 가더라고요. 하지만 성능 자체만 놓고 본다면 Rook-Ceph가 확실히 우위를 점했어요. 결국 어떤 Kubernetes 스토리지 솔루션을 선택할지는 여러분의 환경과 요구사항에 따라 달라진다는 것이 저의 결론입니다.
여러분도 직접 설치해보시고, 여러분의 워크로드에 맞는 벤치마크를 수행해보시면 좋은 인사이트를 얻으실 수 있을 거예요. 저의 삽질 경험이 여러분의 시행착오를 조금이나마 줄여줄 수 있다면 좋겠습니다! 😊
다음 글에서는 Kubernetes에서 Grafana(그라파나)와 Prometheus(프로메테우스)를 이용해 스토리지 성능을 모니터링하는 방법에 대해 다뤄볼 예정이에요. 기대해주세요!
Longhorn과 Rook-Ceph 중 어떤 솔루션이 당신에게 맞을지 요약한 인포그래픽입니다.
'IT > k8s' 카테고리의 다른 글
| [k8s] 쿠버네티스 RBAC 보안 강화 체크리스트: 최소 권한 원칙 적용 가이드 (0) | 2026.06.22 |
|---|---|
| [k8s] Rancher 2.x에서 차세대로 마이그레이션: 실제 경험과 주요 변경점 (1) | 2026.06.20 |
| [k8s] Argo CD 멀티 클러스터 동기화 문제 해결: 실제 운영 사례와 디버깅 팁 (0) | 2026.06.19 |
| [k8s] Argo CD 멀티 클러스터 GitOps 베스트 프랙티스 체크리스트 (0) | 2026.06.17 |
| [k8s] Argo CD 멀티 클러스터 GitOps 도입 사례: 운영 노하우와 도전 과제 (0) | 2026.06.13 |
| [k8s] Kustomize와 Helm, K8s 설정 관리 도구 실측 성능 비교 (0) | 2026.06.12 |
