Unused PV Detection

Unused PV Detection은 어떤 Pod에도 연결되지 않은 PersistentVolume을 자동으로 찾아내어, 고아 스토리지를 정리하고 낭비되는 스토리지 비용을 줄이는 데 도움을 줍니다.

Unused PV Detection이란?

Unused PV Detection은 클러스터의 모든 PersistentVolume(PV)을 스캔하여 더 이상 사용되지 않는 PV를 찾아냅니다. 이러한 "미사용" 또는 "고아" PV는 아무 역할도 하지 않으면서 스토리지 예산만 소모합니다. 완전히 바인딩되지 않았거나, 삭제된 PersistentVolumeClaim(PVC)에 바인딩된 상태로 남아 있습니다.

이 Insight는 두 가지 유형의 미사용 PV를 식별합니다:

• Released PV: 이전에 바인딩되었던 PVC가 삭제됨. PV는 데이터를 유지하지만 Retain reclaim policy 때문에 재사용할 수 없습니다
• Available PV: 한 번도 PVC에 바인딩된 적 없음. 생성만 되고 사용되지 않음 (잘못된 프로비저닝이나 배포 실패로 인한 경우가 많음)

미사용 PV가 발생하는 일반적인 원인:

• 애플리케이션은 삭제되었지만 PVC가 남아있는 경우
• 테스트 환경을 스토리지 정리 없이 종료한 경우
• PVC는 생성했지만 실제로 사용하지 않은 배포 실패
• Retain policy로 잘못 설정된 storage class
• 클레임되지 않은 수동 PV 프로비저닝

동작 방식

Unused PV Detection은 다음과 같은 분석 파이프라인을 따릅니다.

1. PV Scanning: 클러스터의 모든 PV를 순회합니다
2. Status Check: Released 및 Available phase PV만 필터링합니다
3. Binding Analysis: PV가 기존 PVC에 바인딩되어 있는지 확인합니다
4. Orphan Detection: PVC가 삭제된 PV를 식별합니다 (바인딩은 되어 있지만 PVC가 존재하지 않음)
5. Log Update: 기존 탐지 로그를 업데이트하거나 새로 생성합니다 (2단계 루프 방식)
6. Safety Period: 정리 대상이 되기까지 7일의 유예 기간을 둡니다
7. Auto-Cleanup: PvCleanupSettings를 통한 선택적 삭제 (활성화된 경우)
8. Resolution Tracking: PV가 다시 바인딩되는지 모니터링합니다 (오탐 해소)

PV 상태와 탐지

Released 상태

의미:

• PV가 이전에 PVC에 바인딩되어 있었음
• PVC가 삭제됨
• PV는 데이터를 유지한 채 Released로 표시됨
• PV를 재사용할 수 없음 (reclaim policy: Retain)

가장 흔한 미사용 PV 상태입니다. 애플리케이션은 삭제되었지만 스토리지가 남아있을 때 발생합니다.

예시:

$ kubectl get pv
NAME       CAPACITY   STATUS     CLAIM                 STORAGECLASS   REASON   AGE
pv-abc123  100Gi      Released   default/database-pvc  gp2                     30d

Detection Reason: "PVC deleted but PV retains data (Reclaim Policy: Retain)"

Available 상태

의미:

• PV가 프로비저닝됨 (수동 또는 동적으로)
• PV가 한 번도 PVC에 바인딩된 적 없음
• 일치하는 PVC가 클레임하기를 기다리는 중

흔하지 않은 경우입니다. 잘못된 프로비저닝이나 배포 워크플로 실패로 인해 발생하는 경우가 많습니다.

예시:

$ kubectl get pv
NAME       CAPACITY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv-xyz789  50Gi       Available   None    gp2                     15d

Detection Reason: "PV provisioned but never claimed"

Bound (PVC는 삭제됨)

의미:

• 상태가 Bound로 표시됨
• 참조하는 PVC가 존재하지 않음 (갑작스럽게 삭제됨)
• 오래된 바인딩 상태 (Kubernetes가 아직 PV 상태를 갱신하지 않음)

드문 경우입니다. PVC가 강제로 삭제되거나 클러스터 장애 중에 발생합니다.

Detection Reason: "PV bound but PVC not found"

주요 기능

• Automatic Discovery: 수동 확인 없이 클러스터 전역의 모든 미사용 PV를 찾아냅니다
• Cluster-Wide View: 클러스터, reclaim policy, storage class별로 그룹화합니다
• Capacity Tracking: PV별 총 미사용 스토리지 크기를 추적합니다
• Cost Estimation: PV별 월간 스토리지 비용을 추정합니다 (storage class 요금 기준)
• Safety Period: 삭제 대상으로 표시하기 전 7일을 대기합니다 (성급한 정리를 방지)
• Auto-Cleanup: PV Auto Cleanup 기능을 통한 선택적 자동 삭제
• Opt-Out Support: 어노테이션으로 특정 PV를 제외할 수 있습니다 (백업/아카이브 PV용)
• Resolution Tracking: PV가 다시 바인딩되면 기록합니다 (오탐 탐지)

탐지 화면 이해하기

Insight 접근하기

Wave 웹 콘솔에서 Cost Efficiency > Unused PV Detection으로 이동합니다.

화면 구성

상단 컨트롤:

1. Cluster Selector: 분석할 Kubernetes 클러스터를 하나 또는 여러 개 선택합니다

2. Date Range Selector: 과거 미사용 PV 로그를 조회할 기간을 선택합니다 (기본값: 데이터 보존 기간 기준 최근 90일)

PV Overview

이 overview 테이블은 선택된 모든 클러스터에서 활성(바인딩된) PV에 대한 지표를 제공합니다.

테이블 열:

1. Cluster Tag: 클러스터의 짧은 식별자
2. Cluster Name: 전체 클러스터 이름
3. Active PVs: 현재 Pod에 바인딩되어 있는 PV 수 (툴팁: "Tracks active PVs bound to pods, not detached PVs")
4. Capacity: 모든 활성 PV의 총 스토리지 용량
5. Used: 모든 활성 PV에서 현재 사용 중인 총 스토리지
6. Available: 활성 PV 내에서 사용 가능한(미사용) 총 스토리지
7. Usage: 사용량 대비 용량 비율을 보여주는 진행률 바

미사용 PV 정리를 시작하기 전에, 이 overview를 통해 클러스터 전체의 총 스토리지 용량과 사용률을 먼저 파악하세요.

Cluster Tabs

여러 클러스터를 선택한 후에는 cluster tabs로 클러스터 간을 전환하며 각 클러스터별 상세 미사용 PV 로그를 확인할 수 있습니다.

PV Auto Cleanup으로 이동

"Go to PV Auto Cleanup Tab" 버튼을 클릭하면 PV Auto Cleanup 설정 페이지로 이동합니다. 여기서 미사용 PV의 자동 삭제를 활성화하고 설정할 수 있습니다.

Unused PV Details Table

이 상세 테이블은 선택한 기간 동안 미사용으로 탐지된 모든 PV를 각 탐지 건에 대한 상세 정보와 함께 보여줍니다.

테이블 열:

1. Timestamp: 이 미사용 PV가 탐지되어 기록된 시각 ("2 days ago"처럼 상대 시간 표시)
2. Namespace: 이 PV에 바인딩되었던 PVC의 Kubernetes namespace (해당하는 경우)
3. PVC Name: 이 PV에 바인딩되었던 PersistentVolumeClaim 이름 (해당하는 경우)
4. PV Name: 정확한 PersistentVolume 이름 (왼쪽에 고정되어 쉽게 참고 가능)
5. Storage Class: 이 PV를 프로비저닝한 storage class (예: gp2, standard, ssd)
6. Capacity: PV의 총 스토리지 크기 (KiB/MiB/GiB/TiB 단위)
7. Phase: 현재 PV phase 상태:
   • 🔴 Released (빨강): 이전에 바인딩되어 있었으나 PVC가 삭제됨 (가장 흔한 미사용 상태)
   • 🟡 Available (노랑): 한 번도 PVC에 바인딩된 적 없음
   • 🔵 Bound (파랑): 바인딩된 것으로 표시되지만 PVC가 존재하지 않음 (오래된 바인딩 정보)
8. Reclaim Policy: PVC가 삭제될 때 발생하는 동작:
   • Retain: PVC 삭제 후에도 PV가 데이터를 유지 (수동 정리 필요)
   • Delete: PVC와 함께 PV도 자동 삭제되어야 함 (미사용 상태라면 프로비저닝 문제를 의미)
   • Recycle: 지원 종료된 policy (드묾)
9. Access Modes: 볼륨을 마운트하는 방식:
   • ReadWriteOnce (RWO), ReadWriteMany (RWX), ReadOnlyMany (ROX)
10. Detected Reason: 이 PV가 미사용으로 표시된 이유에 대한 상세 설명 (목록 형식):
    • "PVC deleted but PV retains data (Reclaim Policy: Retain)"
    • "PV provisioned but never claimed"
    • "PV bound but PVC not found"
11. First Detected: Wave가 이 PV를 미사용으로 처음 탐지한 시각 (상대 시간 표시)
12. Last Detected: 가장 최근 탐지 타임스탬프 (상대 시간 표시)
13. Resolved At: PV가 더 이상 미사용으로 탐지되지 않게 된 시점 (다시 바인딩되었거나 삭제됨)
14. Cleanup Status: 자동 정리 추적 정보 (다음을 통합해 보여주는 열):
    • Is Enabled: 이 PV에 대해 자동 정리가 활성화되어 있는지 여부 (Yes/No 태그)
    • Clean Up Status: 현재 정리 상태 (Pending/InProgress/Completed 태그)
    • Is Deleted: 자동 정리로 PV가 성공적으로 삭제되면 "Yes" 태그 표시
    • Deletion Error: 자동 삭제가 실패하면 오류 사유 툴팁과 함께 "Yes" 태그 표시

정렬 및 필터링:

• 열 헤더를 클릭하면 해당 필드로 정렬됩니다
• namespace 필터로 특정 namespace의 PV만 표시할 수 있습니다
• 기본 정렬: Timestamp 기준 (최근 탐지 순)

데이터 해석하기

최우선 조치 대상 (즉시 조사가 필요합니다):

• 용량이 큰 Released PV: 스토리지 낭비가 큼 (용량 × 스토리지 비용 기준으로 우선순위 결정)
• 7일 이상 미사용인 PV: safety period를 지났으므로 삭제 검토가 안전함
• Reclaim Policy = Retain + Released: 가장 흔한 정리 기회 (PVC는 삭제되었지만 데이터는 유지됨)

주의 깊게 봐야 할 패턴:

• 같은 namespace에서 여러 개의 Released PV: 애플리케이션은 삭제되었지만 스토리지가 남아있음 (정리 기회)
• 한 번도 바인딩되지 않은 Available PV: 프로비저닝 문제 또는 배포 실패 (조사 후 삭제)
• Bound phase이지만 PVC가 없음: 오래된 바인딩 상태 (정리 필요)
• Cleanup Status에 삭제 오류: 자동 정리 실패 (finalizer 또는 권한 문제)

탐지 사유 이해하기:

• "PVC deleted but PV retains data": 애플리케이션은 제거되었지만 Retain policy 때문에 PV가 남음
• "PV provisioned but never claimed": 동적 프로비저닝으로 PV는 생성되었지만 어떤 PVC도 클레임하지 않음
• "PV bound but PVC not found": PVC가 강제로 삭제되어 PV에 오래된 바인딩 정보가 남음

다음 단계:

1. 용량이 큰 PV부터 검토합니다 (가장 큰 비용 절감 가능성)
2. PV가 7일의 safety period를 온전히 채웠는지 확인합니다 (First Detected와 Timestamp 비교)
3. 데이터가 아직 필요한지, 또는 다른 곳에 백업되어 있는지 확인합니다
4. 아래 "미사용 PV가 탐지되면 해야 할 일"의 의사결정 트리를 따릅니다
5. 검증 후에는 PV Auto Cleanup을 활성화해 자동으로 삭제되도록 하는 것도 고려하세요
6. Resolved At과 Cleanup Status 열을 모니터링하여 정리 진행 상황을 추적합니다

활용 사례

스토리지 정리를 통한 비용 절감

고아 스토리지를 삭제해 비용을 절감합니다:

1. 7일 이상 미사용인 PV 목록을 검토합니다
2. 월간 절감액을 계산합니다: (미사용 PV 수) × (GB당 스토리지 비용) × (PV당 용량)
3. 데이터가 더 이상 필요 없는지 (또는 다른 곳에 백업되어 있는지) 확인합니다
4. 미사용 PV를 삭제합니다
5. 즉시 스토리지 비용 절감 효과를 얻습니다

예시: 미사용 100GB PV 20개 × $0.10/GB/월 = 월 $200 절감

테스트 환경의 배포 후 정리

삭제된 테스트 환경의 스토리지를 제거합니다:

1. 애플리케이션과 PVC가 포함된 테스트 namespace를 삭제합니다
2. Unused PV Detection이 남아있는 PV(Released 상태)를 식별합니다
3. 테스트 데이터를 안전하게 삭제할 수 있는지 확인합니다
4. 테스트 환경의 모든 Released PV를 정리합니다
5. 테스트 스토리지 비용이 계속 쌓이는 것을 방지합니다

결과: 수동 스토리지 감사 없이도 클러스터를 깨끗하게 유지합니다

스토리지 쿼터를 위한 용량 회수

새 워크로드를 위해 스토리지 쿼터를 확보합니다:

1. storage class 쿼터에 도달해 새 PV를 프로비저닝할 수 없는 상황
2. Unused PV Detection이 500GB의 미사용 스토리지를 보여줌
3. 미사용 PV를 삭제해 쿼터를 확보
4. 새 워크로드가 이제 스토리지를 프로비저닝할 수 있음

결과: 낭비된 스토리지를 회수하여 쿼터 증설 요청을 피할 수 있습니다

컴플라이언스 및 데이터 보존 정책 준수

데이터 보존 정책 준수를 보장합니다:

1. 회사 정책: 90일이 지난 데이터는 삭제
2. Unused PV Detection이 삭제된 애플리케이션의 Released PV를 식별
3. PV 사용 기간과 데이터 보존 요구사항을 확인
4. 보존 기간을 초과한 PV를 삭제 (필요하면 아카이빙 후)
5. 컴플라이언스 감사 추적을 위해 삭제 내역을 기록

결과: 컴플라이언스를 유지하면서 스토리지 비용을 절감합니다

미사용 PV가 탐지되면 해야 할 일

1단계: 미사용 상태 확인

PV 사용 기간 확인:

kubectl get pv <pv-name> -o jsonpath='{.metadata.creationTimestamp}'

• 7일 이상 미사용 상태인가요? (Safety period)

PVC 이력 검토:

kubectl get pv <pv-name> -o jsonpath='{.spec.claimRef}'

• PVC가 왜 삭제되었나요?
• 테스트 환경이었나요, 프로덕션 데이터였나요?

데이터가 더 이상 필요 없는지 확인:

• 데이터를 보존해야 하는지 애플리케이션 팀에 확인합니다
• 나중에 필요할 수 있다면 백업이 존재하는지 확인합니다
• 회사의 데이터 보존 정책을 검토합니다

2단계: 데이터 보존 요구사항 확인

Retain Policy: 데이터를 반드시 보존해야 함

• PVC 삭제 시 데이터 유실을 막기 위해 의도적으로 Retain으로 설정됨
• 조치: 삭제 전 데이터를 백업하거나, 감사/컴플라이언스에 필요하면 PV를 유지

Delete Policy: 데이터를 안전하게 제거 가능

• PVC가 삭제되면 PV도 자동으로 삭제됨 (동적 프로비저닝이 실패하지 않는 한 미사용으로 나타나면 안 됨)
• 조치: Delete policy인데도 PV가 미사용인 이유를 조사

Recycle Policy (지원 종료됨): 재사용을 위해 데이터를 삭제

• 최신 Kubernetes에서는 거의 사용되지 않음
• 조치: Retain과 유사하게 처리 (삭제 전 백업)

3단계: 조치 결정

옵션 A: PV 삭제 (영구적인 데이터 유실)

적용 시점: 데이터가 불필요하다고 확인된 경우

단계:

# WARNING: This permanently deletes data!
kubectl delete pv <pv-name>

검증:

# Confirm PV is gone
kubectl get pv <pv-name>
# Error: "not found" (expected)
 
# (Cloud providers) Verify underlying volume deleted
# AWS: aws ec2 describe-volumes --volume-ids <volume-id>
# GCP: gcloud compute disks describe <disk-name>

결과: 스토리지 삭제, 비용 제거, 데이터는 영구적으로 유실됨

옵션 B: 백업 후 삭제

적용 시점: 향후 참고를 위해 데이터가 필요할 수 있는 경우

단계:

1. 임시 Pod에 PV를 마운트합니다

apiVersion: v1
kind: Pod
metadata:
  name: backup-pod
spec:
  containers:
  - name: backup
    image: busybox
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: temp-pvc-for-backup

2. cold storage(S3, GCS, Azure Blob)로 데이터를 복사합니다
3. 백업 무결성을 검증합니다
4. PV를 삭제합니다

결과: cold storage에 데이터가 보존되고, hot storage 비용은 제거됩니다

옵션 C: PV 유지 (Opt-Out)

적용 시점: PV는 미사용이지만 반드시 유지해야 하는 경우

단계:

# Apply opt-out annotation
kubectl annotate pv <pv-name> waveautoscale.io/pv-cleanup="false"

Opt-Out을 해야 하는 이유:

• 백업 PV: 재해 복구를 위해 유지
• 아카이브 스토리지: 컴플라이언스를 위해 보존 (예: 금융 기록을 7년간 보관)
• 스냅샷 소스: 스냅샷 생성에 사용되는 PV (실제로 마운트되지는 않음)
• Blue-Green 데이터: 배포 전환을 위한 대기 PV

결과: 이후 미사용 탐지 리포트에서 해당 PV가 제외됩니다

옵션 D: Auto-Cleanup 활성화

적용 시점: Wave가 자동으로 삭제를 처리하기를 원하는 경우

단계:

1. PV Auto Cleanup 설정으로 이동합니다
2. 미사용 PV에 대한 auto-cleanup을 활성화합니다
3. safety period를 설정합니다 (기본값: 7일)
4. 실수로 대량 정리되는 것을 막기 위해 최대 삭제 비율을 설정합니다
5. 절대 삭제되면 안 되는 PV에는 opt-out 어노테이션을 적용합니다

결과: 수동 개입 없이 safety period가 지나면 미사용 PV가 자동으로 삭제됩니다

Auto-Cleanup 연동

Unused PV Detection과 PV Auto Cleanup은 함께 동작합니다:

Detection: Unused PV Detection이 정리 후보를 식별합니다

Eligibility Check: Auto Cleanup이 7일의 safety period가 지났는지 확인합니다

Opt-Out Respect: waveautoscale.io/pv-cleanup="false" 어노테이션이 있는 PV는 건너뜁니다

Deletion: Auto Cleanup이 대상 PV를 자동으로 삭제합니다

Logging: 모든 삭제 내역이 감사 추적을 위해 기록됩니다

설정에 대한 자세한 내용은 PV Auto Cleanup 문서를 참고하세요.

오탐 시나리오 (정당한 미사용 PV)

재해 복구용 백업 PV

• 목적: cold backup으로 유지되는 PV (실제로 마운트되지는 않음)
• 해결책: opt-out 어노테이션 적용
• 예시: PV로 저장되는 주간 데이터베이스 스냅샷

컴플라이언스를 위한 아카이브 스토리지

• 목적: 감사/법적 요구사항을 위한 데이터 보존 (금융 기록은 7년)
• 해결책: opt-out 어노테이션 적용, 보존 사유 문서화
• 예시: SEC 감사에 필요한 2020년 거래 로그

스냅샷 소스 PV

• 목적: VolumeSnapshot 생성에 사용되는 PV (마운트되지는 않지만 여전히 필요함)
• 해결책: opt-out 어노테이션 적용
• 예시: 새 환경 복제를 위한 base image PV

Blue-Green 배포 대기 데이터

• 목적: blue-green 전환을 위해 준비된 PV (아직 활성 배포에 연결되지 않음)
• 해결책: 배포 기간 동안 opt-out 어노테이션을 적용하거나 임시 opt-out을 사용
• 예시: 신규 버전 롤아웃을 위해 미리 채워둔 데이터베이스 PV

다른 Insight와의 연동

PV Capacity Forecast: PV Capacity Forecast는 활발히 커지고 있는(사용 중인) PV를 보여줍니다. Unused PV Detection은 고아가 된 PV를 보여줍니다. 두 기능을 함께 사용하면 스토리지 전체를 온전히 파악할 수 있습니다.

PV Auto Cleanup: Unused PV Detection이 후보를 식별하면, PV Auto Cleanup이 (활성화된 경우) 자동으로 삭제를 실행합니다.

Cost Efficiency Strategy: Smart Sizing Analysis, Idle Node Detection와 함께 사용하면 컴퓨트, 스토리지, 용량 전반에 걸쳐 포괄적인 비용 최적화를 달성할 수 있습니다.

모범 사례

• 미사용 PV를 매월 검토하세요 (매주 하면 알림 피로가 쌓이니 주의)
• 삭제 전 항상 7일의 미사용 기간을 확인하세요 (안전이 최우선)
• 확신이 없다면 삭제 전 데이터를 백업하세요 (S3 Glacier 같은 cold storage 활용)
• 중요하지 않은 데이터에는 reclaim policy "Delete"를 사용하세요 (PVC 삭제 시 자동 정리)
• 중요한 데이터에는 reclaim policy "Retain"을 사용하세요 (명시적 승인을 거치는 수동 정리 프로세스)
• 팀을 위해 보존 정책을 문서화하세요 (데이터 유형별 보관 기간)
• 탐지 정확도를 검증한 후에만 auto-cleanup을 활성화하세요 (먼저 스테이징에서 테스트)
• 프로덕션에서 auto-cleanup을 활성화하기 전에 스테이징에서 테스트하세요
• 프로덕션 PV 삭제에는 승인 프로세스를 마련하세요 (예: 2인 승인 필수)
• 정리 효과를 측정하기 위해 미사용 PV 수의 추이를 추적하세요
• 올바른 PVC 삭제 방법을 팀에 교육하세요 (고아 PV를 남기지 않도록)
• 무제한 PV 프로비저닝을 막기 위해 namespace 쿼터를 사용하세요

트러블슈팅

PV가 미사용으로 표시되었지만 여전히 필요한 경우:

• auto-cleanup을 막기 위해 즉시 opt-out 어노테이션을 적용하세요
• PV가 실제로 활성 PVC에 바인딩되어 있는지 확인하세요: kubectl get pv <pv-name> -o jsonpath='{.status.phase}'
• 오탐 사례를 Wave 지원팀에 알려주세요

미사용 상태인데 표시되지 않는 경우:

• PV가 미사용된 지 7일이 안 되었는지 확인하세요 (safety period)
• PV phase를 확인하세요: kubectl get pv <pv-name> (Released/Available로 표시되어야 함)
• opt-out 어노테이션이 적용되어 있지 않은지 확인하세요

Auto-Cleanup이 중요한 PV를 삭제하는 경우:

• 즉시 auto-cleanup 기능을 비활성화하세요
• 모든 중요한 PV에 opt-out 어노테이션을 적용하세요
• auto-cleanup 설정과 safety period 설정을 검토하세요
• 데이터가 유실되었다면 백업에서 복원하세요

미사용 PV 수가 줄어들지 않는 경우:

• opt-out 어노테이션이 너무 광범위하게 적용되어 있지 않은지 확인하세요
• (원한다면) auto-cleanup이 활성화되어 있는지 확인하세요
• (auto-cleanup이 비활성화되어 있다면) 팀이 PV를 수동으로 삭제하고 있는지 확인하세요
• PV 프로비저닝 관행을 검토하세요 (정리 속도보다 새로운 미사용 PV가 더 빠르게 생기고 있지 않나요?)

수동 삭제를 시도했는데도 Released PV가 남아있는 경우:

• finalizer가 삭제를 막고 있을 수 있습니다
• finalizer를 확인하세요: kubectl get pv <pv-name> -o jsonpath='{.metadata.finalizers}'
• finalizer를 제거하세요: kubectl patch pv <pv-name> -p '{"metadata":{"finalizers":null}}' (주의해서 사용하세요!)
• 하위 클라우드 볼륨이 여전히 존재할 수 있습니다 (클라우드 프로바이더 콘솔 확인)

요약

Unused PV Detection은 클러스터 전역의 고아 스토리지를 자동으로 찾아내어 체계적인 정리를 통한 비용 절감을 가능하게 합니다. Released 및 Available PV를 식별함으로써 삭제된 애플리케이션, 테스트 환경, 실패한 배포에서 발생한 낭비를 드러냅니다.

PV Auto Cleanup과 결합하면 손댈 필요 없는 스토리지 최적화를 제공합니다. PV Capacity Forecast와 결합하면 포괄적인 스토리지 라이프사이클 관리를 제공합니다.

매월 미사용 PV를 검토하고, 데이터가 백업되어 있거나 불필요한지 확인한 뒤, 안전하게 삭제하여 스토리지 예산을 회수하는 것부터 시작하세요. 이러한 체계적인 접근 방식을 꾸준히 적용하면 스토리지 낭비를 없애고 인프라를 적정 규모로 유지할 수 있습니다.