12. 데이터 효율화 — 중복제거, 압축, 씬 프로비저닝
중복제거 동작 원리와 인라인/포스트프로세스 차이, 압축 알고리즘(LZ4 vs ZSTD) 비교, 컴팩션과 쓰기 증폭(WAF), 씬 프로비저닝의 오버프로비저닝 위험, 벤더별 효율화 구현 차이, "5:1 리덕션"의 진실과 측정 기준의 함정까지. 공짜 점심은 없다.
- 112. 데이터 효율화 — 중복제거, 압축, 씬 프로비저닝
- 21. 스토리지, 왜 어렵고 왜 중요한가
- 32. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
- 43. 병렬 파일 시스템과 분산 스토리지 — Lustre, GPFS, HDFS
- 54. 프로토콜 깊이 파기 — FC / iSCSI / NFS / SMB / S3
- 65. RAID와 데이터 보호 — 전통 RAID부터 이레이저 코딩까지
- 76. 도입 검토 — 요구사항 분석과 벤더 선정
- 87-1. 설계 — 인프라 편 (이중화, 플랫폼, Tier)
- 97-2. 설계 — 데이터 편 (LUN 배치, 스냅샷, DR)
- 108. 구축 — 초기 설정과 호스트 연결
- 119. 인수시험(SAT) — 장비를 내 것으로 만드는 과정
- 1210. 일상 운영 1: 볼륨 할당과 변경 관리
- 1311. 일상 운영 2: 모니터링, 성능 튜닝, 용량 관리
글꼴
"실효 용량 100TB인데 논리 300TB를 쓰고 있다."
이 말이 가능한 건 데이터 효율화 기술 덕분이다. 중복제거, 압축, 씬 프로비저닝. 이 세 가지가 합쳐져서 물리 디스크보다 훨씬 많은 데이터를 저장할 수 있게 해준다. 벤더가 "3
데이터 리덕션"이라고 말할 때, 이 기술들이 합산된 결과다.하지만 공짜 점심은 없다. 중복제거는 CPU를 먹고, 압축은 레이턴시에 영향을 줄 수 있고, 씬 프로비저닝은 물리 용량이 바닥나면 서비스를 멈추게 만든다. "켜면 좋아지는" 마법이 아니라, 트레이드오프를 이해하고 환경에 맞게 적용하는 기술이다.
데이터 효율화의 전체 그림
데이터가 스토리지에 기록되는 과정:
호스트가 쓰기 요청 (4KB 블록)
│
▼
┌─────────────────────────────────────────────┐
│ ① 씬 프로비저닝 │
│ "실제로 쓸 때만 물리 공간을 할당한다" │
│ 1TB 볼륨이지만 10GB만 쓰면 10GB만 차지 │
│ │
│ ② 인라인 중복제거 │
│ "이 블록, 이미 저장된 것과 같은가?" │
│ 같으면 → 포인터만 저장. 물리 쓰기 안 함 │
│ 다르면 → 다음 단계로 │
│ │
│ ③ 인라인 압축 │
│ "이 블록을 더 작게 만들 수 있는가?" │
│ 4KB → 2KB로 압축되면 절반만 디스크에 기록 │
│ │
│ ④ 디스크에 기록 │
└─────────────────────────────────────────────┘
"인라인"이란: 데이터가 디스크에 기록되기 전에 처리한다는 뜻.
"포스트프로세스"란: 일단 기록하고, 나중에 백그라운드로 처리.중복제거(Deduplication) — 같은 데이터를 두 번 저장하지 않는다
중복제거는 동일한 데이터 블록을 하나만 저장하고, 나머지는 포인터로 대체하는 기술이다.
중복제거 동작 원리:
[중복제거 전]
볼륨A: [블록1] [블록2] [블록3]
볼륨B: [블록1] [블록2] [블록4] ← 블록1, 블록2가 동일
물리 저장: 블록1, 블록2, 블록3, 블록1, 블록2, 블록4
총 6개 블록 사용
[중복제거 후]
물리 저장: 블록1, 블록2, 블록3, 블록4
볼륨A: → 블록1, → 블록2, → 블록3
볼륨B: → 블록1, → 블록2, → 블록4 ← 포인터로 참조
총 4개 블록 사용 (33% 절약)
동작 방식:
1. 각 블록의 해시(fingerprint)를 계산 (SHA-256 등)
2. 해시 테이블에서 동일한 해시가 있는지 검색
3. 있으면 → 포인터만 저장 (물리 쓰기 없음)
4. 없으면 → 새 블록으로 저장 + 해시 테이블에 등록인라인 vs 포스트프로세스:
┌──────────────────────────────────────────────────────────┐
│ 인라인 vs 포스트프로세스 중복제거 │
├────────────────┬─────────────────┬────────────────────────┤
│ │ 인라인 │ 포스트프로세스 │
├────────────────┼─────────────────┼────────────────────────┤
│ 처리 시점 │ 쓰기 전에 즉시 │ 쓰기 후 백그라운드 │
├────────────────┼─────────────────┼────────────────────────┤
│ 공간 절약 시점 │ 즉시 │ 나중에 (분~시간 후) │
├────────────────┼─────────────────┼────────────────────────┤
│ 쓰기 성능 │ 약간 영향 │ 영향 적음 │
│ │ (해시 계산 필요)│ (일단 쓰고 나중에 처리)│
├────────────────┼─────────────────┼────────────────────────┤
│ 컨트롤러 CPU │ 쓰기 시 부하 │ 백그라운드 시 부하 │
├────────────────┼─────────────────┼────────────────────────┤
│ 물리 공간 │ 중복 데이터가 │ 처리 전까지 중복 데이터│
│ │ 아예 안 쓰임 │ 가 물리 공간을 차지 │
├────────────────┼─────────────────┼────────────────────────┤
│ 주 사용 벤더 │ NetApp, Pure │ 일부 Dell 환경 │
│ │ (대부분 인라인) │ │
└────────────────┴─────────────────┴────────────────────────┘
현대 올플래시 스토리지는 거의 다 인라인이다.
컨트롤러 CPU 성능이 충분하기 때문에 인라인 오버헤드가 크지 않다.
HDD 시대에는 컨트롤러 CPU가 부족해서 포스트프로세스가 많았다.워크로드별 중복제거 효과:
┌───────────────────────┬──────────────┬──────────────────┐
│ 워크로드 │ 중복제거 효과│ 이유 │
├───────────────────────┼──────────────┼──────────────────┤
│ VDI (가상 데스크톱) │ 매우 높음 │ 동일 OS 이미지가 │
│ │ 3:1 ~ 5:1 │ 수백 개 복제 │
├───────────────────────┼──────────────┼──────────────────┤
│ VMware 가상 서버 │ 높음 │ OS 영역 중복 │
│ │ 2:1 ~ 3:1 │ │
├───────────────────────┼──────────────┼──────────────────┤
│ 개발/테스트 환경 │ 높음 │ 프로덕션 복제본이 │
│ │ 2:1 ~ 4:1 │ 여러 개 │
├───────────────────────┼──────────────┼──────────────────┤
│ 일반 파일 서버 │ 보통 │ 파일 종류에 따라 │
│ │ 1.3:1 ~ 2:1 │ 편차 큼 │
├───────────────────────┼──────────────┼──────────────────┤
│ DB (Oracle, MySQL) │ 낮음~보통 │ DB 내부 데이터는 │
│ │ 1.2:1 ~ 1.8:1│ 중복이 적음 │
├───────────────────────┼──────────────┼──────────────────┤
│ 이미 압축/암호화된 │ 거의 없음 │ 압축/암호화되면 │
│ 데이터 (영상, 이미지) │ 1:1 ~ 1.1:1│ 패턴이 사라져서 │
│ │ │ 중복이 안 잡힘 │
└───────────────────────┴──────────────┴──────────────────┘중복제거의 리스크:
┌──────────────────────────────────────────────────────────┐
│ · 컨트롤러 CPU/메모리 소비가 늘어난다. │
│ 해시 테이블이 메모리에 상주해야 하기 때문이다. │
│ 중복제거 대상 데이터가 많을수록 해시 테이블이 커진다. │
│ 메모리가 부족하면 해시 테이블이 디스크로 넘어가서 │
│ 중복제거 성능이 급격히 떨어진다. │
│ │
│ · 중복제거된 블록 하나가 깨지면 참조하는 모든 볼륨이 │
│ 영향을 받는다. RAID/체크섬이 이걸 보호하지만, │
│ "하나의 물리 블록 = 여러 논리 블록"이라는 구조가 │
│ 장애 영향 범위를 넓힌다는 건 인식해야 한다. │
│ │
│ · 중복제거를 끄는 건 쉽지만, 이미 중복제거된 데이터를 │
│ 원래대로 되돌리는(rehydrate) 건 대량의 IO를 발생시킨다. │
│ 피크 시간에 절대 하면 안 된다. │
└──────────────────────────────────────────────────────────┘압축(Compression) — 데이터를 더 작게 만든다
압축은 데이터 블록 내부의 반복 패턴을 줄여서 물리적으로 더 적은 공간에 저장하는 기술이다. 중복제거가 "같은 블록을 합치는" 거라면, 압축은 "블록 자체를 줄이는" 거다.
압축 동작:
[원본 블록: 4KB]
AAAAAABBBBBBCCCCCC... (반복 패턴 있음)
│ 압축
▼
[압축 후: 1.5KB]
A×6B×6C×6... (반복 횟수로 대체)
4KB → 1.5KB = 약 2.7:1 압축률
[원본 블록: 4KB]
x7f3a9c2b1e8d... (암호화된 데이터, 패턴 없음)
│ 압축 시도
▼
[압축 후: 4KB] ← 줄어들지 않음!
이미 압축되었거나 암호화된 데이터는 압축이 안 된다.압축 알고리즘에 따라 성능과 압축률의 트레이드오프가 있다.
┌──────────────────────────────────────────────────────────┐
│ 압축 알고리즘 비교 │
├────────────────┬─────────────────┬────────────────────────┤
│ │ LZ4 │ ZSTD (Zstandard) │
├────────────────┼─────────────────┼────────────────────────┤
│ 압축 속도 │ 매우 빠름 │ 빠름 (LZ4보다 느림) │
├────────────────┼─────────────────┼────────────────────────┤
│ 압축률 │ 보통 │ 높음 (LZ4보다 ~30% │
│ │ │ 더 압축) │
├────────────────┼─────────────────┼────────────────────────┤
│ CPU 부하 │ 낮음 │ 중간 │
├────────────────┼─────────────────┼────────────────────────┤
│ 해제(읽기) 속도│ 매우 빠름 │ 빠름 │
├────────────────┼─────────────────┼────────────────────────┤
│ 적합한 환경 │ 레이턴시 민감 │ 용량 절약 우선 │
│ │ (OLTP DB 등) │ (아카이브, 백업 등) │
├────────────────┼─────────────────┼────────────────────────┤
│ 사용 벤더 │ NetApp(기본), │ NetApp(선택 가능), │
│ │ Pure │ 일부 Dell 환경 │
└────────────────┴─────────────────┴────────────────────────┘
벤더별 압축 구현:
NetApp ONTAP — Adaptive Compression (블록 크기에 따라 알고리즘 자동 선택)
Pure Storage — 항상 인라인 압축. 사용자가 끌 수 없음. "우리가 알아서 한다."
Dell PowerStore — 인라인 압축 기본. 워크로드에 따라 자동 조절.압축의 장단점:
장점:
· 중복제거와 달리 거의 모든 데이터에 효과가 있다
(이미 압축/암호화된 건 제외)
· 인라인 압축은 디스크에 쓰는 양 자체가 줄어드니
SSD 수명(쓰기 횟수)도 늘어난다
· 올플래시에서는 CPU 오버헤드가 미미하다
단점/리스크:
┌──────────────────────────────────────────────────────┐
│ · 이미 압축된 데이터(JPG, MP4, ZIP, 암호화)에 │
│ 압축을 걸면 효과가 없을 뿐 아니라 CPU만 낭비한다. │
│ 어떤 벤더는 "압축 불가"를 감지하고 자동으로 패스하지│
│ 만, 감지 비용 자체가 오버헤드다. │
│ │
│ · 압축률이 가변이라 용량 예측이 어렵다. │
│ "지금은 2:1인데 내달에 영상 데이터가 들어오면 │
│ 1.1:1로 떨어질 수 있다." 용량 계획 시 │
│ 최악의 압축률(1:1)도 감안해야 한다. │
│ │
│ · 압축된 블록은 크기가 불균일하다. 이로 인해 내부적 │
│ 으로 단편화(fragmentation)가 발생할 수 있고, │
│ 이걸 정리하는 게 컴팩션(아래에서 다룸)이다. │
└──────────────────────────────────────────────────────┘컴팩션(Compaction) — 빈 공간을 정리한다
중복제거와 압축을 하면 블록 크기가 들쭉날쭉해진다. 4KB 블록이 압축되어 1.5KB가 되면 2.5KB가 남는다. 이 자투리 공간들이 쌓이면 실제로는 빈 공간이 있는데 새 블록을 넣을 수 없는 상태가 된다. 컴팩션은 이 자투리들을 모아서 정리하는 과정이다.
컴팩션 전:
[1.5KB][빈2.5KB][2KB][빈2KB][3KB][빈1KB]
사용 낭비 사용 낭비 사용 낭비
컴팩션 후:
[1.5KB][2KB][3KB][빈 연속 공간]
사용 사용 사용 회수됨!
자투리를 모아서 연속 빈 공간을 만든다.컴팩션은 올플래시 환경에서 특히 중요하다. SSD는 "쓰기 전에 지워야 한다"는 특성이 있어서, 단편화가 심하면 쓰기 증폭(Write Amplification)이 발생한다.
쓰기 증폭(Write Amplification):
호스트가 4KB를 쓰려고 했는데,
SSD 내부에서 가비지 컬렉션을 위해 64KB를 읽고 지우고 다시 쓴다.
WAF = 실제 SSD에 쓴 양 / 호스트가 요청한 쓰기 양
WAF 1.0 = 이상적 (호스트 요청만큼만 쓰기)
WAF 3.0 = 호스트가 1GB 쓰면 SSD는 3GB 쓰기 = SSD 수명 3배 소모
컴팩션이 잘 되면 WAF가 낮아진다.
컴팩션이 안 되면 WAF가 올라가고 SSD 수명이 줄고 성능도 떨어진다.
리스크:
· 컴팩션 자체가 IO를 발생시킨다 (읽고 → 재배치하고 → 쓰기)
· 피크 시간에 컴팩션이 돌면 서비스 IO와 경합한다
· 대부분의 벤더는 컴팩션을 유휴 시간에 자동으로 실행하지만,
유휴 시간이 없는 24x7 워크로드에서는 경합이 발생할 수 있다씬 프로비저닝 심화 — 편하지만 위험하다
2편에서 씬 프로비저닝의 개념을 다뤘다. 여기서는 운영 관점에서의 리스크를 깊이 파본다.
씬 vs 씩(Thick) 프로비저닝:
Thick:
┌──────────────────────────────────────────┐
│ 1TB 볼륨 생성 → 물리 1TB 즉시 할당 │
│ 실제 사용 10GB여도 1TB가 예약됨 │
│ │
│ 장점: 용량 부족 걱정 없음. 안전. │
│ 단점: 물리 공간 낭비가 심함. │
└──────────────────────────────────────────┘
Thin:
┌──────────────────────────────────────────┐
│ 1TB 볼륨 생성 → 물리 0GB 할당 (!) │
│ 실제 사용 10GB면 물리 10GB만 차지 │
│ │
│ 장점: 물리 공간 효율 극대화. │
│ 단점: 오버프로비저닝 → 물리 부족 → 장애! │
└──────────────────────────────────────────┘오버프로비저닝의 위험:
오버프로비저닝 시나리오:
물리 실효 용량: 63TB
볼륨A: 논리 50TB (실제 사용 20TB)
볼륨B: 논리 50TB (실제 사용 15TB)
볼륨C: 논리 50TB (실제 사용 10TB)
──────────────────────────────────
논리 합계: 150TB (물리의 2.4배!)
물리 사용: 45TB (아직 여유 있음)
여기서 볼륨A에 대량 데이터 로딩이 시작되면?
물리 사용: 45TB → 55TB → 60TB → 63TB → ???
63TB를 넘는 순간:
┌──────────────────────────────────────────────────────┐
│ · 새 쓰기가 거부된다 (IO Error) │
│ · 볼륨이 오프라인될 수 있다 │
│ · 볼륨A뿐 아니라 같은 풀의 볼륨B, C도 영향받는다! │
│ · → 한 서비스의 데이터 폭증이 다른 서비스를 죽임 │
│ │
│ 이건 디스크 장애가 아니다. RAID로 못 막는다. │
│ 순수한 운영 실패다. │
└──────────────────────────────────────────────────────┘씬 프로비저닝을 안전하게 운영하려면:
┌──────────────────────────────────────────────────────┐
│ 1. 물리 사용률 모니터링 필수 │
│ 논리 용량이 아니라 물리 사용률을 본다. │
│ 70% → 주의, 80% → 경고, 90% → 긴급 (11편 참고) │
│ │
│ 2. Space Reclamation (UNMAP/TRIM) │
│ 호스트에서 삭제한 데이터가 스토리지에서는 │
│ "사용 중"으로 남아있을 수 있다. │
│ UNMAP 명령으로 스토리지에 "이 블록 안 쓴다"를 │
│ 알려야 물리 공간이 회수된다. │
│ │
│ Linux: fstrim /data/erp (또는 discard 마운트 옵션) │
│ VMware: VAAI UNMAP (자동 또는 수동) │
│ │
│ UNMAP의 리스크: │
│ · 대량 UNMAP 실행 시 IO 성능 일시 저하 │
│ · 일부 구형 스토리지에서 UNMAP이 제대로 안 될 수 │
│ 있다. 벤더 호환 매트릭스 확인 필요. │
│ │
│ 3. 오버프로비저닝 비율 관리 │
│ 논리 합계 / 물리 실효 = 오버프로비저닝 비율 │
│ 2:1 이내가 안전. 3:1 이상이면 리스크 높음. │
│ 리덕션 효과를 감안하더라도 보수적으로 잡아야 한다. │
│ │
│ 4. Volume Auto-Grow 설정 시 주의 │
│ 자동 확장을 걸어두면 편하지만, 한 볼륨이 물리 공간을│
│ 독식할 수 있다. 최대 크기 상한을 반드시 설정. │
└──────────────────────────────────────────────────────┘벤더별 데이터 효율화 비교
같은 "데이터 리덕션"이라도 벤더마다 구현과 철학이 다르다.
┌──────────────────────────────────────────────────────────┐
│ 벤더별 데이터 효율화 비교 │
├──────────────┬───────────────────────────────────────────┤
│ NetApp ONTAP │ · 인라인 중복제거 + 인라인 압축 + 컴팩션 │
│ │ · Adaptive Compression (블록별 최적 알고리즘)│
│ │ · Temperature-Sensitive Storage Efficiency │
│ │ (핫 데이터는 압축 약하게, 콜드는 강하게) │
│ │ · 볼륨 단위로 효율화 ON/OFF 가능 │
│ │ │
│ │ 장점: 세밀한 제어 가능. 볼륨마다 다른 정책 │
│ │ 단점: 옵션이 많아서 최적 설정을 찾아야 함 │
├──────────────┼───────────────────────────────────────────┤
│ Dell │ · 인라인 중복제거 + 인라인 압축 │
│ PowerStore │ · Always-On으로 기본 활성화 │
│ │ │
│ │ 장점: 기본 설정 그대로 써도 무난 │
│ │ 단점: 세밀한 알고리즘 선택 불가 │
├──────────────┼───────────────────────────────────────────┤
│ Pure Storage │ · 인라인 중복제거 + 인라인 압축 항상 ON │
│ │ · 사용자가 끌 수 없음. "우리가 알아서" │
│ │ · Evergreen 프로그램에서 리덕션 비율 보장 │
│ │ → 보장 미달 시 디스크 무상 추가 │
│ │ │
│ │ 장점: 신경 쓸 게 없다. 보장까지 해준다. │
│ │ 단점: 제어할 수 없다. 특수 워크로드에서 │
│ │ 효율화를 끄고 싶어도 불가능. │
│ │ 이미 압축된 데이터에도 계속 시도해서 │
│ │ 미세한 CPU 낭비가 있을 수 있다. │
├──────────────┼───────────────────────────────────────────┤
│ HPE Alletra │ · 인라인 중복제거 + 인라인 압축 │
│ │ · InfoSight에서 리덕션 효율 분석 │
│ │ │
│ │ 장점: InfoSight의 예측 분석과 연계 │
│ │ 단점: 알고리즘 세부 제어는 제한적 │
└──────────────┴───────────────────────────────────────────┘"5 데이터 리덕션"의 진실
벤더가 "5
데이터 리덕션"이라고 할 때, 이건 중복제거 + 압축 + 씬 프로비저닝의 합산 효과다. 그리고 대부분 "가장 좋은 조건"에서의 숫자다. 벤더가 말하는 5:1은 이런 조건:
┌──────────────────────────────────────────────────────┐
│ · VDI 워크로드 (중복제거 효과 극대화) │
│ · 텍스트 기반 데이터 (압축 효과 극대화) │
│ · 씬 프로비저닝 포함 (미사용 공간까지 리덕션에 산입) │
│ │
│ 현실: │
│ · 일반 혼합 워크로드에서는 2:1 ~ 3:1이 현실적 │
│ · 영상/이미지 위주면 1.1:1 ~ 1.5:1 │
│ · DB 위주면 1.5:1 ~ 2.5:1 │
└──────────────────────────────────────────────────────┘
리덕션 비율 측정 기준도 벤더마다 다르다:
┌──────────────────────────────────────────────────────┐
│ 벤더 A: 중복제거 + 압축 + 씬(미사용 공간) 합산 │
│ = "5:1" │
│ │
│ 벤더 B: 중복제거 + 압축만 (씬 제외) │
│ = "2.5:1" │
│ │
│ 같은 데이터인데 측정 기준에 따라 숫자가 2배 차이. │
│ 벤더 제안서를 비교할 때 "씬 포함인지 제외인지"를 │
│ 반드시 확인해야 한다. │
└──────────────────────────────────────────────────────┘용량 산정 시 리덕션 비율을 어떻게 반영할 것인가:
┌──────────────────────────────────────────────────────┐
│ 보수적 접근 (권장): │
│ │
│ 벤더가 3:1이라 해도 → 2:1로 계산한다. │
│ 남으면 여유고, 부족하면 장애다. │
│ │
│ 리덕션 비율이 높게 나오는 초기에는 좋아 보이지만, │
│ 시간이 지나면서 데이터 종류가 다양해지면 │
│ 리덕션 비율이 떨어지는 경우가 흔하다. │
│ │
│ "처음에 3:1이었는데 1년 뒤 2:1로 떨어졌어요" │
│ → 이건 정상이다. 데이터 특성이 변한 거다. │
│ 그래서 처음부터 보수적으로 잡아야 한다. │
│ │
│ 리덕션 보장이 있는 벤더(Pure Evergreen 등)를 쓰면 │
│ 이 리스크를 벤더에게 전가할 수 있다. │
│ 단, 보장 조건(워크로드 타입 제한 등)을 확인해야 한다. │
└──────────────────────────────────────────────────────┘데이터 효율화를 켤 것인가 말 것인가
"무조건 켜면 좋은 거 아닌가?" 대부분의 경우 그렇다. 하지만 예외가 있다.
데이터 효율화 적용 가이드:
┌───────────────────────┬────────┬───────┬───────────────┐
│ 워크로드 │중복제거│ 압축 │ 판단 근거 │
├───────────────────────┼────────┼───────┼───────────────┤
│ VDI │ ON │ ON │ 효과 최대 │
├───────────────────────┼────────┼───────┼───────────────┤
│ 가상 서버 (VMware) │ ON │ ON │ OS 중복 많음 │
├───────────────────────┼────────┼───────┼───────────────┤
│ 일반 DB (Oracle, MySQL)│ ON │ ON │ 올플래시에서는│
│ │ │ │ 오버헤드 적음 │
├───────────────────────┼────────┼───────┼───────────────┤
│ 초저지연 DB (HFT 등) │ 검토 │ 검토 │ 마이크로초 │
│ │ 필요 │ 필요 │ 단위 레이턴시 │
│ │ │ │ 에서는 영향 │
│ │ │ │ 있을 수 있음 │
├───────────────────────┼────────┼───────┼───────────────┤
│ 영상/이미지 저장소 │ OFF │ OFF │ 효과 없음. │
│ │ 고려 │ 고려 │ CPU만 낭비. │
├───────────────────────┼────────┼───────┼───────────────┤
│ 암호화된 데이터 │ OFF │ OFF │ 암호화하면 │
│ │ 고려 │ 고려 │ 패턴이 사라져 │
│ │ │ │ 효과 없음 │
├───────────────────────┼────────┼───────┼───────────────┤
│ 백업 타겟 │ ON │ ON │ 반복 데이터 │
│ │ │ │ 많아 효과 큼 │
└───────────────────────┴────────┴───────┴───────────────┘
Pure Storage처럼 사용자가 끌 수 없는 벤더도 있다.
이 경우 "효과 없는 워크로드에도 항상 ON"이라는 점을
수용해야 한다. 실제 성능 영향은 미미한 경우가 대부분이지만.데이터 효율화는 "용량을 늘리는" 마법이 아니라 "물리와 논리 사이의 갭을 관리하는" 기술이다. 그 갭이 커질수록 관리의 복잡도도 올라간다. 특히 씬 프로비저닝과 결합되면 "논리로는 여유가 있는데 물리가 바닥"이라는 위험한 상태가 올 수 있다. 11편에서 다룬 용량 모니터링이 여기서 연결된다.
다음 편에서는 백업과 아카이빙을 다룬다. 스냅샷은 백업이 아니다. 스토리지가 통째로 날아가면 스냅샷도 같이 사라진다. 진짜 백업은 어떻게 해야 하는지, 그리고 데이터를 10년 동안 보관해야 할 때 어떤 선택지가 있는지.
이 글이 어떠셨나요?
관련 포스트
Infrastructure
11. 일상 운영 2: 모니터링, 성능 튜닝, 용량 관리
스토리지 모니터링 핵심 메트릭(Latency/IOPS/Throughput/Queue Depth), 성능 병목 분석 흐름, QoS 설정과 벤더별 차이, 씬 프로비저닝 용량 관리의 위험, 긴급 용량 확보 방법까지. 장애가 터지기 전에 잡는 일상 운영의 기술.
2026. 06. 15. PM 10:00Infrastructure10. 일상 운영 1: 볼륨 할당과 변경 관리
스토리지 운영의 70%를 차지하는 일상 업무. 볼륨 할당 워크플로우, 벤더별 프로비저닝 CLI, 볼륨 확장/삭제의 주의사항, 변경 관리 위험도 분류, 서비스 카탈로그까지. 실수 한 번이 데이터를 날리는 영역의 안전한 운영법.
2026. 06. 08. PM 10:00Infrastructure9. 인수시험(SAT) — 장비를 내 것으로 만드는 과정
스토리지 인수시험(SAT)의 전체 절차. 하드웨어/라이선스 검증, 스냅샷 복원 테스트, 컨트롤러 페일오버 IO 중단 시간 판정 기준(30초 근거), 경로/전원/디스크 장애 시뮬레이션, fio 레이턴시 프로파일 해석법, 벤더 스펙 대비 실측 비교 방법, 성능 저하 시 5단계 원인 추적, 인수 결과 문서와 조건부 합격의 실무적 의미, 초기 안정화 기간 활용법까지.
2026. 06. 01. PM 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.
댓글
댓글을 불러오는 중...