PV Capacity Forecast
PV Capacity Forecast는 Persistent Volume이 언제 공간 부족에 이를지 예측해, 스토리지 고갈로 인한 데이터 손실과 애플리케이션 장애를 7~60일 전에 미리 경고해 방지합니다.
What is PV Capacity Forecast?
PV Capacity Forecast는 PV 사용 패턴과 증가율을 지속적으로 모니터링해 각 Persistent Volume이 언제 용량 한계에 도달할지 예측합니다. 과거 소비 추이를 분석하고 머신러닝 기반 예측을 적용해 조기 경고를 제공하므로, 치명적인 장애가 발생하기 전에 미리 스토리지를 확장할 수 있습니다.
How It Works
PV Capacity Forecast는 다음과 같은 분석 파이프라인을 따릅니다.
- Metrics Collection: 각 Persistent Volume의 사용 데이터(used bytes, available bytes, capacity)를 조회합니다
- Growth Analysis: PV별로 시간에 따른 소비 추이를 계산합니다 (최소 7일치 과거 데이터 필요)
- ML Forecasting: Wave Intelligence Server를 통해 Seasonal Exponential Smoothing 등 시계열 모델을 적용해 7~60일 뒤의 사용량을 예측합니다
- Forecast Visualization: 과거 데이터(실선)와 예측치(점선)를 차트에 함께 표시해 추이를 한눈에 볼 수 있게 합니다
- Snapshot Predictions: 7일 차와 30일 차의 예상 사용량을 색상으로 구분된 진행률 바로 제공합니다
- Log Storage: 예측 결과를 저장해 이력 추적과 추이 분석에 활용합니다
Technical Implementation
PV Capacity Forecast는 ML 기반 예측을 위해 Wave Intelligence Server와 연동됩니다. 시스템은 멀티 모델 앙상블 방식으로 PV 메트릭을 처리합니다.
- File:
core/services/src/tasks/pv_capacity_forecast/task.rs - Models: SeasonalExponentialSmoothingOptimized 등 시계열 알고리즘
- Forecast Horizon: 7~60일
- Update Frequency: 매일
- Minimum Data: 7일치 과거 메트릭
- Timeout:
WAEnv::get_intelligence_server_forecast_pv_capacity_timeout_secs()로 설정 가능
스토리지 백엔드가 used_bytes를 제공하지 않으면 시스템이 직접 계산해, 스토리지 클래스가 달라도 정확한 예측을 유지합니다.
Prerequisites
최소 데이터 요구사항
PV Capacity Forecast는 예측을 생성하려면 PV 생성 후 최소 7일치 과거 메트릭이 필요합니다. 충분한 과거 데이터가 쌓이기 전까지 신규 PV는 "Insufficient Data" 또는 "N/A"로 표시됩니다.
- Minimum: 7일치 메트릭
- Recommended: 더 정확한 예측을 위해 14일 이상
- Metric Collection: Wave Metrics Agent가 자동으로 수집
Key Features
- 7-60 Day Forecast Window: 용량 계획, 예산 승인, 확장 일정 수립에 충분한 시간을 확보합니다
- Per-PV Analysis: 볼륨별로 개별 예측을 제공해 놓치는 스토리지가 없도록 합니다
- Growth Pattern Recognition: 꾸준한 증가와 계절적 패턴(예: 업무 시간대 로그 볼륨 급증)을 모두 감지합니다
- Auto Expansion Integration: 활성화되어 있으면 PV Auto Expansion을 자동으로 트리거합니다
- Historical Tracking: 예측 이력을 저장해 예측 정확도를 검증하고 모델을 지속적으로 개선합니다
Understanding the Forecast View
PV Usage Rate & Forecast Table
클러스터 내 모든 PV에 대한 집계 메트릭을 표시합니다.
Current Metrics:
- Active PVs: 모니터링 중인 Persistent Volume 수 (pod에 바인딩되어 메트릭이 수집되고 있는 PV)
- Capacity: 클러스터 내 모든 PV의 총 스토리지 용량
- Used: 모든 PV에서 사용 중인 총 스토리지
- Available: 모든 PV의 총 여유 공간
- Current Usage: 사용량/용량 비율을 보여주는 진행률 바
Forecast Snapshots:
- Forecast Usage (7 days): 7일 차 예상 총 사용량을 진행률 바로 표시
- Forecast Usage (30 days): 30일 차 예상 총 사용량을 진행률 바로 표시
진행률 바는 색상으로 임계값을 구분합니다.
- Indigo/Purple: 용량 여유가 충분함 (전체 용량의 80% 미만)
- Yellow/Amber: 용량 한계에 근접함 (전체 용량의 80~89%)
- Red: 용량 제약이 예상됨 (전체 용량의 90% 이상)
PV List & Details
이 화면은 마스터 디테일 레이아웃을 사용합니다. 왼쪽에는 전체 PV 목록이, 오른쪽에는 선택한 PV의 상세 예측 데이터가 표시됩니다.
PV List Table

선택한 클러스터의 모든 Persistent Volume을 보여줍니다.
- Namespace: PVC가 속한 Kubernetes namespace
- PVC Name: PersistentVolumeClaim 이름
- Usage: 현재 사용량/용량 비율을 보여주는 진행률 바
Interaction: PV 행을 클릭하면 오른쪽에 상세 예측이 표시됩니다. 선택한 행은 파란색 배경으로 강조됩니다.
Sorting: 용량에 근접한 PV를 빠르게 파악할 수 있도록 기본적으로 사용률이 높은 순으로 정렬됩니다.
Use Cases
Prevent Database Crashes
데이터베이스는 스토리지 고갈에 특히 취약합니다. 디스크 공간이 부족해지면 다음과 같은 문제가 발생합니다.
- 쓰기 작업이 실패해 애플리케이션 오류가 발생합니다
- 데이터베이스가 읽기 전용으로 전환되어 쓰기 기능이 멈춥니다
- 트랜잭션이 롤백되어 사용자 데이터가 유실됩니다
- 복구하려면 수동 개입과 다운타임이 필요합니다
PV Capacity Forecast는 쓰기 실패가 발생하기 전에 미리 스토리지를 확장해 이런 장애를 막습니다.
Manage Log Storage Growth
애플리케이션 로그, 시스템 로그, 감사 로그는 계속 늘어납니다. 예측 없이는 다음과 같은 문제가 생깁니다.
- 버퍼가 가득 차면 로그 파이프라인이 멈춥니다
- 최근 로그가 없으면 디버깅이 불가능해집니다
- 감사 로그가 유실되면 컴플라이언스 요건을 위반하게 됩니다
- 로그 로테이션만으로는 증가 문제를 근본적으로 해결할 수 없습니다
PV Capacity Forecast는 로그 볼륨 증가가 언제 스토리지를 고갈시킬지 파악해, 미리 확장하거나 아카이빙할 수 있게 해줍니다.
Plan Storage Budget
증가 추이를 파악하지 못하면 스토리지 비용이 재무팀에게 예상치 못한 부담이 될 수 있습니다.
- 과거 증가 추이를 바탕으로 분기별 스토리지 지출을 예측합니다
- 데이터 기반 예측으로 예산 증액에 설득력 있는 근거를 댈 수 있습니다
- 예산을 흔드는 긴급 확장을 피할 수 있습니다
- 증가 패턴에 따라 스토리지 티어(hot/warm/cold)를 최적화할 수 있습니다
Support Data-Intensive Workloads
AI/ML 학습, 데이터 분석, 미디어 처리 워크로드는 스토리지를 빠르게 소비합니다.
- 모델 학습은 체크포인트와 아티팩트를 생성해 볼륨을 빠르게 채웁니다
- 분석 작업은 중간 결과를 계속 쌓아 나갑니다
- 미디어 처리는 정리되지 않은 임시 파일을 만들어냅니다
- PV Capacity Forecast는 이런 워크로드가 작업 도중 공간 부족을 겪지 않도록 보장합니다
What to Do When Forecast Shows Storage Risk
PV Capacity Forecast가 스토리지 고갈을 예측하면 다음 옵션을 고려하세요.
Option 1: Enable PV Auto Expansion (Automatic Solution)
Best for: 다운타임 없는 확장이 필요한 프로덕션 워크로드
Steps:
- PV Auto Expansion 설정으로 이동합니다
- 대상 PVC/StatefulSet에 auto-expansion을 활성화합니다
- 확장 임계값을 설정합니다 (권장: 용량의 70~80%)
- 무한정 확장을 막기 위해 최대 크기 한도를 설정합니다
- 임계값에 도달하면 확장이 자동으로 트리거되는지 확인합니다
Pros: 완전 자동화, 다운타임 없음, 긴급 상황 방지 Cons: 온라인 확장을 위해 Kubernetes 1.27 이상이 필요합니다
자세한 설정 방법은 PV Auto Expansion 문서를 참고하세요.
Option 2: Manually Expand PVC Size
Best for: 일회성 확장이 필요하거나 auto-expansion을 지원하지 않는 클러스터
Steps:
- 스토리지 클래스가 volume expansion을 지원하는지 확인합니다 (
allowVolumeExpansion: true) - PVC spec을 수정해
resources.requests.storage를 늘립니다 - 스토리지 백엔드가 확장을 완료할 때까지 기다립니다
- PV Capacity Forecast에 새 용량이 반영되었는지 확인합니다
Example:
kubectl patch pvc database-pvc -p '{"spec":{"resources":{"requests":{"storage":"200Gi"}}}}'Pros: 일회성 요청에 간단하고, 이전 버전 Kubernetes에서도 동작합니다 Cons: 수동 개입이 필요하며, 스토리지 백엔드에 따라 다운타임이 발생할 수 있습니다
Option 3: Clean Up Old Data or Logs
Best for: 임시 데이터나 아카이빙 데이터가 쌓인 볼륨
Steps:
- 안전하게 삭제 가능한 파일을 식별합니다 (오래된 로그, 임시 파일, 만료된 데이터)
- 오래된 로그를 자동으로 정리하는 로그 로테이션 정책을 적용합니다
- 삭제하기 전에 데이터를 콜드 스토리지(S3, GCS, Azure Blob)로 아카이빙합니다
- 재축적을 막기 위해 주기적인 정리 작업을 예약합니다
Pros: 스토리지 비용을 줄이고, 확장 없이도 용량을 확보할 수 있습니다 Cons: 데이터 라이프사이클에 대한 이해가 필요하고, 아카이빙하지 않으면 과거 데이터가 유실될 수 있습니다
Option 4: Archive Data to Cold Storage
Best for: hot storage 비용 없이 장기 데이터를 보존해야 하는 경우
Steps:
- 콜드 스토리지 버킷을 준비합니다 (S3 Glacier, GCS Archive, Azure Archive)
- 보존 기준(예: 90일)보다 오래된 데이터를 식별합니다
- 백업 도구(Velero, 커스텀 스크립트)로 데이터를 콜드 스토리지에 복사합니다
- 공간을 확보하기 위해 PV에서 아카이빙된 데이터를 삭제합니다
- 필요 시 복구할 수 있도록 아카이빙 절차를 문서화합니다
Pros: 스토리지 비용을 줄이면서도 컴플라이언스를 유지할 수 있습니다 Cons: 아카이빙된 데이터는 조회 속도가 느리고, 아카이빙 인프라가 필요합니다
Integration with PV Auto Expansion
PV Capacity Forecast와 PV Auto Expansion은 매끄럽게 함께 동작합니다.
Forecast Detection: PV Capacity Forecast가 스토리지 고갈 시점을 예측합니다
Threshold Trigger: 실제 사용률이 (PV Auto Expansion에서 설정한) 확장 임계값에 도달하면 자동 확장이 트리거됩니다
Pre-emptive Expansion: 용량에 도달하기 전에 미리 확장이 일어나 쓰기 실패를 막습니다
Continuous Monitoring: 확장 후에는 예측이 새 용량 기준으로 재조정되어 모니터링을 계속합니다
Example Flow:
- PV Capacity Forecast가 14일 뒤 PV가 100%에 도달할 것으로 예측합니다
- PV Auto Expansion이 80% 임계값으로 설정되어 있습니다
- 실제 사용률이 80%에 도달하면 auto-expansion이 PV 크기를 30% 늘립니다
- 예측이 새로운 130% 용량을 기준으로 재계산됩니다
- 애플리케이션 다운타임이나 쓰기 실패가 발생하지 않습니다
자세한 설정 방법은 PV Auto Expansion 문서를 참고하세요.
Best Practices
- 확장 임계값은 용량의 70~80%로 설정하세요. 확장이 완료될 때까지의 여유 시간을 확보할 수 있습니다
- 핵심 데이터베이스에는 auto-expansion을 활성화하세요. 쓰기 실패와 다운타임을 막을 수 있습니다
- 중요도가 낮은 스토리지는 주 단위로 예측을 검토하세요. 유지보수 시간대에 수동 확장을 계획할 수 있습니다
- 정리 정책과 함께 사용하세요. 필요할 때 확장하고 불필요한 데이터는 정리해 비용을 관리하세요
- 예측 정확도를 검증하세요. 매월 예상 고갈 시점과 실제 시점을 비교하세요
- 스토리지 증가 패턴을 문서화하세요. 용량 계획과 예산 예측에 참고할 수 있습니다
- 알림을 설정하세요. 30일 이내 고갈이 예상되는 경우 수동 개입을 위한 알림을 받으세요
- 오래된 데이터는 확장에만 의존하지 말고 미리 아카이빙하세요.
- 클라우드 프로바이더의 확장 비용을 모니터링하세요. 무제한 auto-expansion으로 인한 예상치 못한 비용 지출을 막을 수 있습니다
- 스테이징에서 먼저 확장을 테스트하세요. 프로덕션 볼륨에 auto-expansion을 활성화하기 전에 확인하세요
Storage Class Requirements
PV Auto Expansion을 사용하려면 스토리지 클래스에 allowVolumeExpansion: true가 설정되어 있어야 합니다. 스토리지 클래스가 동적 확장을 지원하는지 확인하세요.
kubectl get storageclass -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.allowVolumeExpansion}{"\n"}{end}'스토리지 클래스가 확장을 지원하지 않는다면, 더 큰 볼륨을 수동으로 프로비저닝하고 데이터를 마이그레이션해야 합니다.
Troubleshooting
"Insufficient Data"가 표시되는 경우:
- PV 생성 후 7일간 메트릭이 수집되기를 기다리세요
- Metrics Agent가 PV 사용 데이터를 수집하고 있는지 확인하세요
예측이 부정확해 보이는 경우:
- 워크로드 동작이 최근에 바뀌었는지 확인하세요 (새로운 트래픽 패턴, 데이터 파이프라인 변경 등)
- 모델이 새 패턴에 적응하려면 7~14일이 필요합니다
- 변동성이 큰 워크로드는 신뢰 구간이 더 넓게 표시될 수 있습니다
Auto Expansion이 트리거되지 않는 경우:
- PV Auto Expansion 설정에서 확장이 활성화되어 있는지 확인하세요
- 임계값이 적절하게 설정되어 있는지 확인하세요 (너무 높지 않은지)
- 스토리지 클래스가
allowVolumeExpansion을 지원하는지 확인하세요 - 오류가 있는지 PV Auto Expansion 로그를 확인하세요