[K8s] Longhorn 1년 운영기: 안정성과 성능 정리

목차

• 1. 왜 k8s에서 Longhorn을 고민하게 되는가
• 2. Longhorn 개념, 쉽게 말해 어떻게 동작하나
• 3. 제가 실제로 잡았던 운영 원칙
• 4. 실전 구현: k8s Longhorn 운영 시작할 때 제가 한 순서
• 5. 운영 중 자주 본 이슈와 트러블슈팅
• 5-1. ⚠️ 복제본 재빌드가 길어지면서 성능이 흔들릴 때
• 5-2. ⚠️ 디스크는 남았는데 스케줄링이 꼬이는 경우
• 5-3. ⚠️ 스냅샷이 백업을 대체한다고 착각하기
• 6. 검증 방법: 설치보다 중요한 운영 확인 절차
• 7. 1년 운영 후 느낀 안정성과 성능 평가
• 8. 정리와 다음 단계: 이런 분께 특히 맞습니다
• 9. 자주 묻는 질문 FAQ
• Q1. Longhorn은 모든 워크로드에 무난한가요?
• Q2. 복제본 수는 무조건 많을수록 좋은가요?
• Q3. 스냅샷만 잘 찍어두면 백업은 안 해도 되나요?

[K8s] 프로덕션 Longhorn 1년 운영기: 안정성과 성능 정리

프로덕션에서 k8s longhorn 운영을 1년 정도 해보면, 처음 기대했던 편의성과 실제 운영 난이도 사이의 간격이 꽤 선명하게 보입니다. 저도 처음엔 '쿠버네티스(Kubernetes, 컨테이너 오케스트레이션) 위에서 스토리지까지 한 번에 정리되면 정말 편하겠다' 싶었거든요. 실제로 써보니까 편한 점도 분명했고, 반대로 방심하면 장애를 키우는 포인트도 있었습니다. 이번 글은 제품 소개보다는 longhorn 사례에 가깝습니다. 무엇이 안정적이었고, 어디서 삽질했는지, 그리고 지금 다시 구성한다면 무엇을 다르게 할지 정리해보겠습니다.

특히 상태 저장 워크로드(Stateful Workload, 데이터가 남아야 하는 애플리케이션)를 k8s에서 돌리고 계신 분이라면, 스토리지 선택이 결국 운영 스트레스를 좌우한다는 걸 이미 느끼셨을 겁니다. 혹시 PVC(PersistentVolumeClaim, 영구 볼륨 요청)만 붙이면 끝이라고 생각하셨다면, 여기서 중요한 포인트가 있습니다. 스토리지는 선언형만으로 끝나지 않고 운영 습관까지 같이 설계해야 하더라고요.

프로덕션 클러스터에서 Longhorn이 각 노드 디스크를 묶어 분산 블록 스토리지로 구성되는 전체 흐름을 보여주는 이미지입니다.

1. 왜 k8s에서 Longhorn을 고민하게 되는가

쉽게 말해 Longhorn은 쿠버네티스 친화적인 분산 블록 스토리지(Distributed Block Storage)입니다. 각 노드의 디스크를 활용해서 볼륨을 만들고, 복제본(Replica, 데이터 사본)을 여러 노드에 분산해 두는 방식이죠. 관리 포인트가 늘어나는 건 맞는데, 대신 클러스터 안에서 스토리지를 비교적 일관된 방식으로 다룰 수 있습니다.

제가 Longhorn을 선택했던 이유는 세 가지였습니다.

• 노드 로컬 디스크를 활용할 수 있다는 점
• UI 기반 운영 가시성이 괜찮다는 점
• 백업(Backup)과 스냅샷(Snapshot) 흐름을 잡기 쉬웠다는 점

반대로 처음부터 알았어야 했던 것도 있습니다. Longhorn은 마법이 아닙니다. underlying disk, 네트워크, 워크로드 I/O 패턴이 좋지 않으면 그대로 티가 납니다. 즉 k8s 스토리지 문제를 Longhorn이 가려주지는 않더라고요. 오히려 더 빨리 드러내 줍니다. 이건 단점 같지만, 운영자 입장에선 장점이기도 합니다.

2. Longhorn 개념, 쉽게 말해 어떻게 동작하나

처음엔 이게 뭔가 싶었는데, 구조를 한 번 그림으로 이해하면 꽤 단순합니다.

1. 파드(Pod, 컨테이너 실행 단위)가 PVC를 요청합니다.
2. 스토리지클래스(StorageClass, 동적 볼륨 정책)에 따라 Longhorn 볼륨이 생성됩니다.
3. Longhorn이 여러 노드에 복제본을 배치합니다.
4. 특정 노드에서 파드가 볼륨을 마운트(Mount, 연결)해서 사용합니다.
5. 노드 하나가 내려가도 복제본이 남아 있으면 복구 여지가 생깁니다.

여기서 핵심은 두 가지입니다. 첫째, 복제본 수는 안정성과 비용의 균형입니다. 둘째, 성능은 결국 네트워크와 디스크 특성의 영향을 크게 받습니다. 그래서 Longhorn을 볼 때는 단순히 설치 성공 여부보다, 복제 전략과 워크로드 특성을 먼저 맞춰보는 게 중요합니다.

항목	Longhorn에서 보는 포인트	운영 시 체감
안정성	복제본 분산, 노드 장애 대응	단일 노드 장애에는 강한 편
성능	디스크 IOPS, 네트워크 지연	랜덤 I/O 많은 DB는 민감함
운영 편의	UI, 볼륨 관리, 스냅샷	초기 러닝커브 이후 꽤 편함
주의점	디스크 여유 공간, 재빌드 트래픽	장애 후 재동기화 시 부담 큼

3. 제가 실제로 잡았던 운영 원칙

longhorn 안정성은 제품 자체보다 운영 원칙에서 많이 갈렸습니다. 제가 1년 돌리면서 끝까지 가져간 기준은 아래와 같았습니다.

• 컨트롤 플레인(Control Plane, 제어 영역)과 스토리지 부담을 가능한 분리
• 복제본은 최소한 장애 도메인(Failure Domain, 함께 망가질 수 있는 범위)을 고려해서 배치
• 디스크 사용률 임계치(Threshold, 경계값)를 보수적으로 설정
• 스냅샷은 남발하지 않고 백업 정책과 구분
• DB처럼 I/O 민감한 워크로드는 사전 검증 후 배치

이 중에서 가장 중요했던 건 디스크 여유 공간입니다. 처음엔 여유가 좀 있으니 괜찮겠지 했었는데, 재빌드(Rebuild, 복제본 재생성)가 걸리는 순간 생각보다 빠르게 압박이 오더라고요. 스토리지 시스템은 평상시보다 장애 직후가 더 무겁습니다. 이건 꼭 기억하셔야 합니다.

4. 실전 구현: k8s Longhorn 운영 시작할 때 제가 한 순서

설치는 환경마다 조금씩 다르지만, 흐름은 크게 다르지 않습니다. 아래는 제가 홈랩과 실서비스 검증 환경에서 자주 쓰는 형태입니다.

1. 노드 디스크 상태와 마운트 경로를 먼저 확인합니다.
2. Longhorn 시스템용 네임스페이스(namespace)를 분리합니다.
3. 기본 StorageClass를 만들되, 복제본 수를 환경에 맞게 조정합니다.
4. 테스트용 PVC와 파드를 붙여 실제 쓰기/읽기를 확인합니다.
5. 운영 전 스냅샷과 백업 경로를 반드시 따로 검증합니다.

kubectl create namespace longhorn-system
kubectl get nodes -o wide
kubectl get sc
kubectl get pods -n longhorn-system

스토리지클래스는 아래처럼 시작하면 이해가 쉽습니다. 값 자체는 환경마다 다르게 잡으셔야 합니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-replicated
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "30"
  fsType: "ext4"

그리고 바로 PVC를 붙여봅니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-replicated
  resources:
    requests:
      storage: 20Gi
---

apiVersion: v1
kind: Pod
metadata:
  name: demo-writer
spec:
  containers:
    - name: writer
      image: busybox
      command: ["sh", "-c", "while true; do date >> /data/out.log; sleep 5; done"]
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: demo-pvc

처음엔 단순한 쓰기 테스트가 무슨 의미가 있나 싶었는데, 여기서 마운트 지연이나 attach 문제를 초기에 꽤 많이 잡았습니다. 운영 들어가고 나서 알면 늦거든요.

StorageClass 생성부터 PVC 연결, 파드 마운트까지 이어지는 실제 구성 흐름을 설명하는 이미지입니다.

5. 운영 중 자주 본 이슈와 트러블슈팅

이 섹션이 사실 제일 중요합니다. 예쁜 소개보다, 실제로 어디서 무너지는지를 아는 게 훨씬 도움이 되거든요.

5-1. ⚠️ 복제본 재빌드가 길어지면서 성능이 흔들릴 때

노드 하나를 점검하느라 내렸다가 다시 올리면, 복제본 재동기화가 시작됩니다. 이때 네트워크와 디스크에 동시에 부담이 옵니다. longhorn 성능이 평소엔 괜찮다가도 이 구간에서 갑자기 느려질 수 있습니다.

제가 했던 대응은 단순했습니다.

• 업무 시간 중 대규모 재스케줄링을 피했습니다.
• 용량이 큰 볼륨은 변경 작업 전에 백업 상태를 먼저 확인했습니다.
• 재빌드가 오래 걸리는 볼륨은 워크로드 I/O 패턴을 따로 봤습니다.

5-2. ⚠️ 디스크는 남았는데 스케줄링이 꼬이는 경우

이건 꽤 헷갈립니다. df로 보면 공간이 남아 있는데, Longhorn 쪽에서는 새 복제본 배치를 보수적으로 판단하는 경우가 있습니다. 저도 처음엔 버그인가 싶었는데, 실제론 예약 공간과 최소 여유 공간 정책을 같이 봐야 하더라고요.

이럴 때는 아래처럼 확인했습니다.

kubectl get pvc
kubectl describe pvc demo-pvc
kubectl get volumes.longhorn.io -n longhorn-system
kubectl get replicas.longhorn.io -n longhorn-system

5-3. ⚠️ 스냅샷이 백업을 대체한다고 착각하기

이건 정말 많이 나오는 실수입니다. 스냅샷(Snapshot, 시점 복사본)은 같은 스토리지 계층 안에 남는 경우가 많아서, 근본적인 백업 전략과는 다릅니다. 저도 초반엔 스냅샷이 있으니 어느 정도 안심했었는데, 사고 시나리오를 따져보면 그걸로는 부족했습니다. 스냅샷은 운영 편의 기능이고, 백업은 재해 복구 전략입니다. 완전히 다릅니다.

6. 검증 방법: 설치보다 중요한 운영 확인 절차

프로덕션에선 '붙었다'보다 '망가졌을 때 어떻게 보이는가'를 확인해야 합니다. 저는 최소한 아래는 반복해서 체크했습니다.

1. 파드 재시작 후 볼륨 재연결이 정상인지 확인
2. 노드 drain 이후 워크로드 복구 흐름 확인
3. 스냅샷 생성 및 삭제 후 공간 회수 패턴 확인
4. 백업 저장소 접근 실패 시 경고 동작 확인
5. 복제본 손실 상황에서 재생성 시간이 과하게 길지 않은지 확인

실제로 써보니까 UI에서 상태가 보여주는 정보가 꽤 유용했습니다. 다만 UI만 믿고 있으면 늦습니다. 이벤트(Event), PVC 상태, 파드 재시작 로그를 같이 봐야 원인이 보입니다.

복제본 상태, 볼륨 attach 여부, 재빌드 진행 상황을 한눈에 확인하는 운영 관점의 대시보드 이미지입니다.

7. 1년 운영 후 느낀 안정성과 성능 평가

결론부터 말하면, Longhorn은 잘 설계된 환경에서는 충분히 실전적인 선택지였습니다. 특히 여러 팀이 PVC를 빠르게 써야 하고, 외부 스토리지 어플라이언스에 강하게 의존하고 싶지 않을 때 장점이 컸습니다. 제가 본 longhorn 사례 기준으로는 다음과 같이 정리할 수 있었습니다.

구분	좋았던 점	아쉬웠던 점
안정성	노드 단위 장애 대응이 비교적 명확함	디스크/네트워크 품질이 낮으면 불안정성이 바로 드러남
성능	일반적인 앱 데이터, 로그성 워크로드는 무난	고성능 DB, 지연 민감 워크로드는 사전 검증 필수
운영	가시성과 자동화 포인트가 좋음	재빌드와 용량 계획은 생각보다 더 보수적으로 해야 함

드디어 됐다 싶었던 순간도 많았습니다. 예전엔 스토리지 붙이는 작업 자체가 팀 내 병목이었는데, Longhorn 이후엔 표준화가 쉬워졌거든요. 반대로 '이거 진짜 편하더라고요'라고 말할 수 있으려면, 초반 설계와 검증을 꽤 꼼꼼하게 해야 합니다. 그냥 설치만 해놓고 운영에 들어가면 언젠가 비용을 치릅니다.

8. 정리와 다음 단계: 이런 분께 특히 맞습니다

k8s longhorn 운영을 1년 해보면서 제가 내린 판단은 이렇습니다.

• 온프레미스(On-premise, 자체 인프라)나 홈랩에서 쿠버네티스 스토리지를 일관되게 운영하고 싶은 분
• 외부 스토리지 장비보다 클러스터 내부 표준화를 우선하는 팀
• 운영자가 디스크, 네트워크, 장애 복구 흐름을 직접 이해하고 관리할 준비가 된 환경

반대로, 아주 빡빡한 성능 요구가 있는 데이터베이스를 바로 얹을 계획이라면 먼저 작은 범위에서 검증해보시는 걸 권합니다. 저도 처음엔 자신 있게 올렸다가, I/O 패턴 때문에 조정 많이 했습니다. 결국 중요한 건 제품 이름보다 워크로드 적합성입니다.

다음 글에서는 백업 저장소(Backup Target) 설계나, 스냅샷 정리 정책을 어떻게 가져가면 운영이 덜 꼬이는지 다뤄볼 예정입니다. 이전 글에서 다뤘던 Ingress(인그레스, 외부 트래픽 진입점)와 모니터링 구성과도 연결되는 부분이 많아서, 같이 보시면 흐름이 더 잘 잡히실 겁니다.

안정성, 성능, 운영 난이도, 추천 환경을 한 장으로 요약한 비교형 인포그래픽 이미지입니다.

9. 자주 묻는 질문 FAQ

Q1. Longhorn은 모든 워크로드에 무난한가요?

아닙니다. 일반적인 상태 저장 앱에는 잘 맞을 수 있지만, 초저지연이 중요한 워크로드는 별도 검증이 필요합니다.

Q2. 복제본 수는 무조건 많을수록 좋은가요?

그렇지 않습니다. 안정성은 좋아질 수 있지만, 용량과 재빌드 비용도 같이 늘어납니다. 장애 도메인 기준으로 잡는 게 현실적입니다.

Q3. 스냅샷만 잘 찍어두면 백업은 안 해도 되나요?

안 됩니다. 스냅샷과 백업은 역할이 다릅니다. 이건 꼭 분리해서 생각하셔야 합니다.

정리하면, longhorn 안정성은 꽤 인상적이었고, longhorn 성능은 환경과 워크로드 영향을 솔직하게 받았습니다. 그래서 더 좋았습니다. 숨기지 않거든요. 문제를 빨리 보여주는 시스템은, 운영자가 준비만 되어 있으면 꽤 믿을 만합니다. k8s 스토리지 때문에 계속 고민 중이셨다면, 작은 클러스터에서부터 검증해보세요. 그 과정에서 배우는 게 정말 많습니다.

📚 함께 읽으면 좋은 글

• Ingress Controller 비용 분석: 효율적인 선택 가이드
• Helm Argo CD 마이그레이션: GitOps 전환 전략과 실제 사례
• OpenTelemetry K8s 마이그레이션: Prometheus 공존 전략과 함정