스토리지 프로비저닝: Thick·Thin·Dynamic 중 무엇을 언제 쓸까

같은 200GB 볼륨이라도 물리 디스크를 미리 통째로 잡아두는 것과, 실제 쓰는 만큼만 논리적으로 내주는 것은 완전히 다른 운영 리스크를 만든다. 클라우드·가상화·컨테이너 환경이 늘면서 애플리케이션 중심으로 스토리지를 할당하고 자동화하는 일이 인프라 운영의 기본기가 됐다. 스토리지 프로비저닝(Storage Provisioning)은 이 할당 방식을 정책·자동화·관측 체계로 표준화해 비용과 성능의 균형을 잡는 절차다.

Thick·Thin·Dynamic 할당 방식

스토리지 프로비저닝은 애플리케이션 요구사항(QoS/용량/가용성/보안)에 맞춰 저장소 리소스를 정책 기반으로 할당·매핑·보호하는 절차다. Thick는 물리 공간을 사전에 예약하고, Thin은 논리적으로 할당한 뒤 물리 배치를 지연시키며, Dynamic/On-demand는 요청이 들어올 때 자동으로 생성한다. 인터페이스는 블록·파일·오브젝트로 나뉜다.

계층 구조로 보면 물리 디스크 → RAID/Erasure Coding → 스토리지 풀/티어 → LUN/볼륨 → 파일시스템/LVM/컨테이너 볼륨 → 호스트/Pod 매핑 순으로 추상화가 쌓인다. 운영 범위는 온프레미스(AFA/HCI/SDS)와 클라우드(EBS/Azure Disk/Persistent Disk, S3/Blob) 전반을 아우른다.

정책·매핑·효율화·성능·관측이 한 세트로 움직인다

정책 기반 할당은 성능(QoS: IOPS/대역폭/지연), 가용성(멀티AZ/복제), 내구성(EC/RAID), 보안(암호화/KMS) 정책을 정의하고 라벨·태그 기반 규칙과 템플릿으로 서비스 클래스를 나눈 뒤 승인·감사 로깅을 붙인다.

논리-물리 매핑 계층은 LUN/볼륨 추상화와 호스트 매핑, 파일시스템/LVM 확장·스냅샷 연계를 담당하며, CSI·플러그인·API를 통해 오케스트레이터(Kubernetes/VM)와 스토리지 시스템을 표준으로 연동한다.

용량 효율화는 Thin 프로비저닝, 중복 제거, 압축, 제로 패턴 오프로드로 실효 용량을 늘리고, 클론·스냅샷의 CoW(Copy-on-Write) 메커니즘으로 신속한 복제와 공간 절약을 만든다.

성능 보장 메커니즘은 QoS 보장·스로틀링, 캐시·티어링, 스트라이프·얼라인먼트 최적화로 구현되고, 워크로드 격리와 노이즈 네이버 억제를 위한 스케줄링이 따라붙는다.

관측·자동화는 용량 임계치·IOPS/지연 같은 텔레메트리를 수집해 수요를 예측하고 오토스케일하며, Terraform/Ansible 같은 IaC 파이프라인과 변경 관리로 재현성을 보장한다.

실제로는 이렇게 쓰인다

Kubernetes 환경에서는 StorageClass로 성능·가용성·암호화 정책을 선언해두면 PVC가 생성될 때 CSI가 자동으로 볼륨을 만든다. 롤링 업데이트·스냅샷·확장 작업은 GitOps로 자동화한다.

데이터베이스 전용 볼륨은 로그·데이터·백업을 분리하고 RAID10이나 저지연 티어를 적용해 예약 IOPS를 보장하며, 애플리케이션 일관 스냅샷(Pre/Post 스크립트)과 PITR을 함께 구성한다.

VDI·가상화 인프라는 골든 이미지를 Thick로 고정해 성능을 확보하고, 풀 볼륨은 Thin+클론으로 부팅 스톰을 흡수한다. QoS로 동시 사용자 피크 시 지연 임계를 관리한다.

데이터 레이크·아카이브는 오브젝트 스토리지를 핫/쿨/아카이브로 계층화하고 수명주기 정책으로 비용을 최적화한다. 대용량 배치 처리는 스루풋을, 메타데이터 워크로드는 지연 최적화를 우선한다.

유형을 나란히 비교하면

유형	성능	확장성	일관성	안정성	운영 편의
Thick	예측 가능, 고정 대역폭 유리	물리 예비 용량 선점 한계	공간/성능 변동 적음	과할당 리스크 낮음	계획·구성 명확하나 유연성 낮음
Thin	평균부하 최적, 피크 시 스로틀 가능	논리 확장 용이, 과할당 가능	백그라운드 GC/할당 지연 영향	과할당·단편화 리스크 존재	자동화 우수, 모니터링 필수
Dynamic/Auto-tier	워크로드 기반 적응 성능	티어 추가로 수평 확장	티어 이동 시 성능 변동 가능	정책 오류 시 성능 요동 가능	자가 최적화 강점, 정책 튜닝 필요

요청부터 모니터링까지의 절차

프로비저닝은 PVC·티켓·TF 변수 같은 요청 정의와 SLO/QoS/보안 요구사항 명세를 입력으로 받아, 정책 매칭 → 승인/거부 → 볼륨 생성(트랜잭션) → 매핑/포맷 → QoS 적용 → 모니터링 순으로 처리된다. 트랜잭션은 LUN ID 예약 락을 건 뒤 메타데이터를 커밋하고, 실패하면 롤백과 가비지 컬렉션이 뒤따른다. 과할당 임계 초과, 성능 SLA 미달, 암호화 키 회전 실패가 발생하면 격리·복구 플로우가 개입한다.

⤢✕

운영에서는 계획·성능·가용성·보안을 함께 본다

용량 계획은 Thin+중복 제거+압축 조합으로 30~~60% 절감을 가정하고 과할당 비율 상한을 설정하는 것이 권장된다. 성장률(월간 95퍼센타일)과 스냅샷 보관 정책을 반영해 20~~30%의 버퍼를 확보해둔다.

성능 보장은 워크로드 클래스(OLTP/OLAP/로그)별로 IOPS/Throughput/Latency SLO를 분리하고, 노이즈 네이버를 완화하기 위해 QoS 하한과 상한을 동시에 쓴다.

가용성·복구는 멀티AZ/랙 분산과 동기·비동기 복제로 RPO/RTO를 계약화하고, 애플리케이션 일관 스냅샷과 주기적 복구 연습을 병행한다.

보안은 저장 데이터 암호화(KMS/KMIP)와 키 수명주기·회전 절차를 문서화하고, RBAC·네임스페이스·네트워크 정책으로 멀티테넌트를 격리한다.

트레이드오프도 분명하다. Thin은 비용 효율이 좋지만 피크 지연과 단편화 리스크가 있고, Thick는 성능이 예측 가능한 대신 미사용 공간 비용이 늘어난다. Auto-tier는 평균 성능에서 유리하지만 정책을 잘못 설계하면 성능이 요동칠 수 있다.

Kubernetes StorageClass/PVC로 실행해보기

전제조건은 Kubernetes v1.27+, CSI 스토리지 드라이버 설치(예: AWS EBS CSI), 클러스터 RBAC 권한이다. IOPS·Throughput을 지정하고 확장을 허용하는 gp3 StorageClass와 200Gi를 요청하는 PVC는 다음과 같다.

# StorageClass: gp3 예시 (IOPS/Throughput 지정, 확장 허용)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "6000"
  throughput: "250" # MiB/s
  encrypted: "true"
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
---
# PVC: 200Gi 요청, Filesystem 모드
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-data
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: gp3
  resources:
    requests:
      storage: 200Gi
  volumeMode: Filesystem

적용은 kubectl apply -f sc-pvc.yaml로 하고, 확장은 pvc.spec.resources.requests.storage 값을 올린 뒤 다시 apply하면 된다. 다만 파일시스템 온라인 확장 도구(xfs_growfs 등)가 지원되는지는 별도로 확인해야 한다.

자동화가 곧 비용과 리드타임을 결정한다

Thin·압축·중복 제거를 조합하면 유효 용량을 30~~60% 절감할 수 있고, 티어링을 더하면 GB-월 비용이 20~~40% 추가로 줄어든다. QoS를 적용하면 피크 지연이 20~50% 감소하고 노이즈 네이버 영향도 완화된다. 동적 프로비저닝과 IaC를 쓰면 리드타임이 일 단위에서 분 단위로 줄고 변경 실패율도 낮아진다. 정책·감사·롤백 체계를 갖추면 장애 격리와 MTTR 단축까지 이어진다.

결국 스토리지 프로비저닝의 표준화는 워크로드 클래스별 성능·가용성·보안 요구를 명시하고, Thin/Thick/Auto-tier를 조합해 QoS·관측 체계로 비용과 성능의 균형을 잡는 일이다. IaC·CSI 기반 구현과 주기적인 복구 연습을 반복하면서 운영 성숙도를 높여가는 것이 현실적인 경로다.