'StatefulSet' 배포 시 각 노드의 데이터 볼륨 영속성 확보 전략?

'StatefulSet' 배포 시 각 노드의 데이터 볼륨 영속성 확보 전략?

엔터프라이즈 환경에서 쿠버네티스(Kubernetes)를 도입할 때, 상태가 없는(Stateless) 웹 서버나 API 서버를 배포하는 것은 상대적으로 매우 간단합니다. 하지만 메시지 브로커(ActiveMQ Artemis, Kafka 등)나 관계형 데이터베이스(RDBMS)처럼 자체적인 식별자를 가져야 하고, 디스크에 기록된 데이터의 영속성(Persistence)이 시스템의 생명과 직결되는 유상태(Stateful) 애플리케이션을 컨테이너 환경에 올리는 것은 완전히 다른 차원의 인프라 공학을 요구합니다.

파드(Pod)는 언제든 죽고 다른 워커 노드에서 다시 태어날 수 있는 소모품입니다. 하지만 파드가 죽었다고 해서 그 파드가 들고 있던 큐(Queue)의 메시지나 트랜잭션 로그가 함께 증발해서는 안 됩니다. 파드가 재시작되더라도 자신이 원래 쓰던 바로 그 디스크를 다시 찾아가서 마운트해야 합니다.

이러한 완벽한 데이터 영속성과 고정된 식별자를 보장하기 위해 쿠버네티스에서 제공하는 핵심 워크로드 컨트롤러가 바로 'StatefulSet(스테이트풀셋)'입니다. 본 가이드에서는 StatefulSet이 각 노드별로 데이터 볼륨의 영속성을 어떻게 확보하는지 그 내부 아키텍처를 해부하고, 프로덕션 환경에서 반드시 적용해야 할 스토리지 튜닝 전략을 상세히 분석합니다.

---

1. 일반 Deployment 방식의 한계와 데이터 오염

StatefulSet의 필요성을 이해하려면 먼저 기존 Deployment 방식의 스토리지 한계를 알아야 합니다.

Deployment 컨트롤러로 3대의 브로커 파드를 띄우고, 데이터 저장을 위해 하나의 PVC(Persistent Volume Claim)를 연결했다고 가정해 봅시다. 쿠버네티스는 3대의 파드 모두에게 이 동일한 PVC를 마운트하려 시도할 것입니다.
하지만 대부분의 클라우드 블록 스토리지(AWS EBS 등)는 ReadWriteOnce(RWO) 모드만 지원하므로, 오직 한 대의 파드만 디스크를 점유하고 나머지 두 대는 볼륨 마운트 에러를 뿜으며 기동에 실패합니다.
설령 ReadWriteMany(RWX)를 지원하는 NFS(네트워크 파일 시스템)를 마운트했다 하더라도, 3대의 독립적인 브로커 엔진이 동일한 디렉토리와 저널 파일에 동시에 쓰기(Write) 연산을 시도하게 되므로 데이터 인덱스가 완벽하게 오염(Corruption)되고 시스템은 즉각 붕괴합니다.

각 노드는 반드시 '자신만의 격리된 전용 디스크'를 가져야 합니다.

---

2. 영속성의 핵심 메커니즘: 'VolumeClaimTemplates'

StatefulSet이 이러한 스토리지 격리 문제를 우아하게 해결하는 마법의 지팡이가 바로 volumeClaimTemplates (볼륨 청구 템플릿)입니다.

StatefulSet의 설정 파일(YAML) 작성 시, 개별 PVC를 지정하는 것이 아니라 이 템플릿을 정의해 둡니다.
StatefulSet이 broker-0, broker-1, broker-2라는 고정된 이름의 파드를 순차적으로 생성할 때, 쿠버네티스 컨트롤 플레인은 파드 하나를 만들 때마다 volumeClaimTemplates를 거푸집처럼 사용하여 해당 파드 이름이 꼬리표처럼 붙은 완벽히 독립적인 PVC를 자동으로 동적 프로비저닝(Dynamic Provisioning)합니다.

• 파드 broker-0 생성 ➜ PVC data-broker-0 자동 생성 및 바인딩
• 파드 broker-1 생성 ➜ PVC data-broker-1 자동 생성 및 바인딩

이 메커니즘 덕분에 인프라 엔지니어가 수십 개의 PVC를 일일이 수동으로 생성할 필요 없이, 파드의 스케일 아웃(Scale-out)에 발맞춰 독립적인 스토리지 공간이 무한히 자동 확장됩니다.

---

3. 고정 식별자(Sticky Identity)와 완벽한 재결합

데이터 볼륨이 생성되었다면, 파드가 죽고 다른 워커 노드에서 되살아날 때의 동작이 가장 중요합니다.

어느 날 워커 노드 A의 하드웨어 장애로 인해 그 위에서 돌고 있던 broker-0 파드가 돌연사했습니다. 쿠버네티스는 정상적인 워커 노드 B에서 broker-0 파드를 다시 스케줄링하여 살려냅니다.
이때 StatefulSet의 진가가 발휘됩니다. 쿠버네티스는 새롭게 태어난 파드의 이름이 broker-0인 것을 확인하고, 과거에 생성해 두었던 data-broker-0 PVC를 정확히 찾아냅니다. 그리고 클라우드 벤더(AWS, GCP 등)의 API를 호출하여, 기존 노드 A에 붙어있던 물리적 디스크(EBS 볼륨)를 떼어내어(Detach), 새로운 노드 B에 강력하게 다시 갖다 붙입니다(Attach).

파드는 비록 노드를 옮겨 다시 태어났지만, 부팅되자마자 자신이 과거에 쓰던 큐 데이터와 설정 파일이 그대로 남아있는 디스크를 완벽하게 재마운트하게 됩니다. 애플리케이션 입장에서는 단 1바이트의 데이터 유실도 없이 완벽한 자가 치유(Self-healing)가 이루어진 것입니다.

---

4. 프로덕션 스토리지 아키텍처 최적화 (Best Practices)

단순히 volumeClaimTemplates를 선언하는 것만으로는 프로덕션의 혹독한 환경을 버틸 수 없습니다. 클라우드 환경에서 StatefulSet을 운영할 때는 다음의 StorageClass 전략을 반드시 병행해야 합니다.

A. 지연 바인딩: 'WaitForFirstConsumer'의 필수 적용
AWS EBS와 같은 블록 스토리지는 가용 영역(AZ: Availability Zone)에 강하게 종속됩니다. AZ-A에 생성된 디스크는 AZ-B에 있는 워커 노드에 마운트할 수 없습니다.
만약 볼륨이 파드가 스케줄링되기도 전에 먼저 랜덤한 AZ에 생성되어버리면(Immediate 바인딩), 정작 파드가 다른 AZ에 배포되었을 때 디스크를 연결할 수 없어 파드가 영원히 Pending 상태에 빠지게 됩니다.
이를 완벽하게 방어하기 위해 StorageClass 설정에 반드시 volumeBindingMode: WaitForFirstConsumer를 선언해야 합니다. 이는 쿠버네티스가 파드가 어느 워커 노드(어느 AZ)에 배치될지 확실히 결정할 때까지 디스크 생성을 뒤로 미루게 만들어, 파드와 디스크가 항상 동일한 가용 영역에 존재하도록 강제하는 핵심 튜닝 포인트입니다.

B. 생명주기 분리와 고아(Orphaned) PVC의 관리
StatefulSet을 실수로 삭제(kubectl delete statefulset)하더라도, 쿠버네티스는 데이터 보호를 위해 파드만 삭제하고 연결되어 있던 PVC와 물리 디스크는 절대로 자동 삭제하지 않습니다.
이는 장애로부터 데이터를 지켜주는 든든한 안전망이지만, 반대로 스토리지 비용 폭탄의 주범이 되기도 합니다. 인프라를 완전히 철거하거나 재구축할 때는 남겨진 고아 PVC 목록을 직접 확인하고 수동으로 삭제해야 클라우드 인프라 스토리지 과금을 막을 수 있습니다. (쿠버네티스 1.23 버전 이후부터는 StatefulSet의 persistentVolumeClaimRetentionPolicy를 통해 삭제 동작을 제어할 수도 있습니다.)

C. 고성능 IOPS 프로비저닝 (I/O 병목 차단)
메시지 브로커나 DB는 본질적으로 디스크 동기화(fsync) 트래픽이 엄청납니다. 기본 제공되는 범용 SSD(예: AWS gp2)로는 버스트 밸런스(Burst Balance)가 고갈되어 인프라가 마비될 확률이 높습니다. 반드시 StorageClass 단에서 기본 성능이 보장되는 최신 볼륨 타입(예: AWS gp3)을 지정하고, 애플리케이션의 TPS를 감당할 수 있는 충분한 IOPS(초당 입출력 횟수) 대역폭을 템플릿에 명시하여 병목 없는 데이터 파이프라인을 구축해야 합니다.

결론적으로 쿠버네티스 환경에서 StatefulSet의 스토리지 영속성은 단순한 파드와 디스크의 결합을 넘어, 고정된 식별자 라우팅, 클라우드 API를 통한 동적 볼륨 어태치먼트, 그리고 스케줄러의 토폴로지 인지 능력이 총망라된 클라우드 네이티브 아키텍처의 결정체입니다. 볼륨 청구 템플릿의 강력함과 StorageClass의 세밀한 제어를 결합하여 어떠한 물리적 노드 장애 앞에서도 데이터를 절대 잃어버리지 않는 무결점의 분산 환경을 설계하시기 바랍니다.