왜 CSI 스냅샷이 필요한가
스테이트풀 워크로드를 운영하다 보면 PVC 데이터를 순간적으로 고정하고 복제해야 하는 순간이 온다. 스키마 마이그레이션 직전, 배포 롤백 대비, 장애 조사용 데이터 확보 같은 경우다. 클라우드 콘솔에서 디스크 스냅샷을 수동으로 찍을 수도 있지만, 그러면 쿠버네티스 오브젝트와 스토리지 상태가 어긋난다. CSI 스냅샷은 이 작업을 쿠버네티스 API 안으로 끌어들여 선언적으로 관리하게 해준다. PVC를 잘라내고, 그 스냅샷에서 새 PVC를 만들어 붙이는 전 과정을 매니페스트로 재현할 수 있다.
구성 요소와 사전 조건
스냅샷 기능은 코어에 내장돼 있지 않다. 별도 CRD와 컨트롤러가 필요하다. 세 가지 오브젝트를 이해해야 한다.
| 오브젝트 | 역할 | 비유 |
|---|---|---|
| VolumeSnapshotClass | 스냅샷 드라이버·삭제 정책 정의 | StorageClass |
| VolumeSnapshot | 사용자가 요청하는 스냅샷 | PVC |
| VolumeSnapshotContent | 실제 스토리지의 스냅샷 실체 | PV |
snapshot-controller와 각 CSI 드라이버의 csi-snapshotter 사이드카가 떠 있어야 하며, CRD가 클러스터에 설치돼 있어야 한다.
VolumeSnapshotClass와 스냅샷 생성
먼저 클래스를 만들고, 대상 PVC를 가리키는 스냅샷을 찍는다. deletionPolicy: Retain은 VolumeSnapshot을 지워도 스토리지 쪽 실체를 남긴다. 복구 소스로 오래 보관할 스냅샷이라면 Retain을 권장한다.
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: csi-snapclass
driver: ebs.csi.aws.com
deletionPolicy: Retain
---
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: pgdata-2026-09-15
spec:
volumeSnapshotClassName: csi-snapclass
source:
persistentVolumeClaimName: pgdata
생성 후 readyToUse: true가 될 때까지 기다려야 실제 복구에 쓸 수 있다.
스냅샷에서 복구하기
복구는 스냅샷을 dataSource로 지정한 새 PVC를 만드는 방식이다. 기존 PVC를 덮어쓰는 게 아니라 별도 볼륨을 새로 프로비저닝한다는 점이 핵심이다.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pgdata-restored
spec:
storageClassName: gp3
dataSource:
name: pgdata-2026-09-15
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 50Gi복구 PVC의 요청 용량은 원본 스냅샷 크기 이상이어야 한다. 작게 잡으면 프로비저닝 자체가 실패한다.
앱 정합성이 진짜 함정이다
가장 흔한 오해는 스냅샷이 데이터를 완벽히 보존한다는 믿음이다. CSI 스냅샷은 블록 레벨 시점 복사일 뿐, 애플리케이션 관점의 정합성은 보장하지 않는다. DB가 커밋되지 않은 트랜잭션과 더티 페이지를 메모리에 들고 있으면 스냅샷은 크래시 복구가 필요한 상태로 찍힌다. PostgreSQL은 대체로 크래시 리커버리로 살아나지만, 확실히 하려면 스냅샷 직전 체크포인트나 파일시스템 프리즈를 거는 것이 안전하다.
# 스냅샷 직전 정합성 확보
kubectl exec -it pg-0 -- psql -c "CHECKPOINT;"
# 파일시스템 레벨 프리즈(가능한 드라이버 한정)
kubectl exec -it pg-0 -- fsfreeze --freeze /var/lib/postgresql/data
kubectl apply -f snapshot.yaml
kubectl exec -it pg-0 -- fsfreeze --unfreeze /var/lib/postgresql/data운영 시 주의점
- 드라이버 종속성: 스냅샷은 같은 스토리지 백엔드 안에서만 유효하다. AZ나 리전을 넘는 복구는 별도 복제가 필요하다.
- 증분 스냅샷의 사슬: 대부분 드라이버는 증분 방식이다. 오래된 베이스 스냅샷을 함부로 지우면 뒤따르는 복구가 깨질 수 있어
deletionPolicy와 삭제 순서를 신중히 다뤄야 한다. - 복구는 새 볼륨: 복구 PVC는 새 오브젝트다. 스테이트풀셋에 붙이려면 파드 재바인딩이나 볼륨 교체 절차가 따로 필요하다.
- 비용: Retain 정책으로 방치된 고아 스냅샷이 조용히 쌓인다. 만료 라벨과 정리 잡을 반드시 운영하라.
정리
CSI 스냅샷은 볼륨 백업·복구를 쿠버네티스 선언 모델 안으로 통합해주는 강력한 도구지만, 블록 레벨이라는 본질 때문에 앱 정합성은 별도로 책임져야 한다. 스냅샷 생성 자동화만큼 복구 리허설을 정기적으로 돌려, 실제 장애 상황에서 dataSource PVC가 정상 기동하는지 검증해두는 것이 핵심이다.