11. 일상 운영 2: 모니터링, 성능 튜닝, 용량 관리
스토리지 모니터링 핵심 메트릭(Latency/IOPS/Throughput/Queue Depth), 성능 병목 분석 흐름, QoS 설정과 벤더별 차이, 씬 프로비저닝 용량 관리의 위험, 긴급 용량 확보 방법까지. 장애가 터지기 전에 잡는 일상 운영의 기술.
- 11. 스토리지, 왜 어렵고 왜 중요한가
- 22. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
- 33. 병렬 파일 시스템과 분산 스토리지 — Lustre, GPFS, HDFS
- 44. 프로토콜 깊이 파기 — FC / iSCSI / NFS / SMB / S3
- 55. RAID와 데이터 보호 — 전통 RAID부터 이레이저 코딩까지
- 66. 도입 검토 — 요구사항 분석과 벤더 선정
- 77-1. 설계 — 인프라 편 (이중화, 플랫폼, Tier)
- 87-2. 설계 — 데이터 편 (LUN 배치, 스냅샷, DR)
- 98. 구축 — 초기 설정과 호스트 연결
- 109. 인수시험(SAT) — 장비를 내 것으로 만드는 과정
- 1110. 일상 운영 1: 볼륨 할당과 변경 관리
- 1211. 일상 운영 2: 모니터링, 성능 튜닝, 용량 관리
"스토리지가 느린 것 같아요."
이 한마디를 듣고 원인을 찾으려면, 평소에 모니터링을 제대로 하고 있어야 한다. "느린 것 같다"는 체감이지, 숫자가 아니다. 숫자가 없으면 "원래 이 정도입니다"와 "확실히 느려졌네요" 사이를 구분할 수 없다. 인수시험(10편)에서 잡은 Baseline이 여기서 쓰인다.
모니터링은 장애를 예방하고, 성능 문제를 조기에 감지하고, 용량 부족을 미리 대비하기 위한 일상의 활동이다. 화려하지 않지만, 이걸 안 하면 모든 문제가 "갑자기" 터진다.
핵심 모니터링 메트릭 — 뭘 봐야 하는가
스토리지 모니터링에서 반드시 봐야 할 지표들이다.
핵심 메트릭 4가지
1. Latency (응답 시간)
"IO를 요청하고 결과가 돌아올 때까지 걸린 시간"
┌────────────────────────────────────────────┐
│ < 1ms │ 우수 (올플래시 정상) │
│ 1~5ms │ 양호 (대부분 워크로드 OK) │
│ 5~10ms │ 주의 (DB 워크로드에서 체감 시작) │
│ 10~20ms │ 경고 (성능 불만 발생) │
│ > 20ms │ 위험 (서비스 영향 가능) │
└────────────────────────────────────────────┘읽기와 쓰기를 분리해서 봐야 한다. "평균 레이턴시는 괜찮은데 쓰기만 20ms"면 캐시 문제나 복제 오버헤드일 수 있다.
2. IOPS (초당 IO 횟수)
"1초에 몇 번의 읽기/쓰기가 발생하는가"
IOPS 자체보다 "평소 대비 변화"가 중요하다. 평소 5,000 IOPS인 볼륨이 갑자기 50,000이면 비정상 워크로드가 들어온 거다.
3. Throughput (처리량, MB/s)
"1초에 얼마만큼의 데이터가 이동하는가"
백업, 배치 작업 등 순차 IO에서 중요. 백업 윈도우가 밀린다면 처리량을 먼저 확인.
4. Queue Depth (대기 큐 깊이)
"스토리지 앞에서 줄 서 있는 IO의 수"
Queue Depth가 높으면 스토리지가 IO를 제때 처리 못하고 있다는 뜻. Latency와 함께 보면 병목 지점을 찾을 수 있다.
추가로 봐야 할 것들
┌───────────────────┬──────────────────────┬────────────────┐
│ 메트릭 │ 의미 │ 위험 신호 │
├───────────────────┼──────────────────────┼────────────────┤
│ Cache Hit Ratio │ 캐시에서 직접 응답한 │ < 80%이면 │
│ │ IO의 비율 │ 워크로드 패턴 │
│ │ │ 확인 필요 │
├───────────────────┼──────────────────────┼────────────────┤
│ 컨트롤러 CPU │ 스토리지 컨트롤러의 │ > 70% 지속이면 │
│ │ CPU 사용률 │ 병목 가능 │
├───────────────────┼──────────────────────┼────────────────┤
│ 디스크/SSD 사용률 │ 개별 디스크의 바쁜 │ > 80% 지속이면 │
│ │ 정도 │ 핫스팟 │
├───────────────────┼──────────────────────┼────────────────┤
│ 복제 지연 (Lag) │ DR 복제가 밀린 시간 │ RPO 초과 시 │
│ │ │ 즉시 확인 │
└───────────────────┴──────────────────────┴────────────────┘모니터링 인프라 구성
벤더 자체 도구만으로는 부족할 수 있다. 여러 벤더 스토리지를 통합 관리하거나, 호스트-네트워크-스토리지를 연결해서 보려면 별도 모니터링 인프라가 필요하다.
모니터링 인프라 구성 예시
┌────────────┐ SNMP Trap ┌────────────────┐
│ 스토리지A │──────────────────►│ │
│ (NetApp) │──── REST API ────►│ 모니터링 서버 │
└────────────┘ │ │
│ Prometheus │
┌────────────┐ SNMP Trap │ + Grafana │
│ 스토리지B │──────────────────►│ │
│ (Dell) │──── syslog ──────►│ 또는 │
└────────────┘ │ Zabbix │
│ Datadog │
┌────────────┐ SNMP/API │ │
│ FC Switch │──────────────────►│ │──► 알림
│ (Brocade) │ └────────────────┘ (이메일
└────────────┘ Slack
PagerDuty)벤더별 클라우드 모니터링 도구
┌──────────────┬────────────────────┬───────────────────┐
│ 벤더 │ 도구 │ 특징 │
├──────────────┼────────────────────┼───────────────────┤
│ NetApp │ Active IQ │ 예측 분석, 용량 │
│ │ (+ BlueXP) │ 예측, 펌웨어 권고 │
├──────────────┼────────────────────┼───────────────────┤
│ Dell │ CloudIQ │ 이상 탐지, 성능 │
│ │ │ 스코어링 │
├──────────────┼────────────────────┼───────────────────┤
│ Pure Storage │ Pure1 │ 용량 예측(ML), │
│ │ │ 글로벌 벤치마크 │
├──────────────┼────────────────────┼───────────────────┤
│ HPE │ InfoSight │ 크로스스택 분석 │
│ │ │ (서버+스토리지) │
└──────────────┴────────────────────┴───────────────────┘장점: 벤더가 수십만 대의 장비 데이터를 기반으로 분석. "이 펌웨어 버전에 알려진 버그가 있으니 업데이트하세요" 같은 사전 경고가 나온다.
단점: 스토리지 데이터가 벤더 클라우드로 전송된다. 보안 정책상 외부 전송이 불가한 환경에서는 못 쓴다. 온프레미스 환경에서 인터넷 연결이 필요하다. 벤더 종속 — 여러 벤더 장비를 하나의 화면에서 볼 수 없다.
벤더 도구는 자사 장비만 보여준다. 여러 벤더 스토리지를 한 화면에서 보려면 오픈소스 도구를 조합해야 한다.
오픈소스 모니터링 도구
STOR2RRD / XorMon — 스토리지 전용 모니터링
- 지원: Dell, NetApp, HPE, Hitachi, Pure, IBM, Huawei 등 거의 모든 엔터프라이즈 스토리지 + Brocade/Cisco SAN
- 메트릭: IOPS, Latency, Throughput, 캐시, 볼륨/풀 단위
- 라이선스: GPL v3 오픈소스. 무료 에디션은 장비 수 제한.
- 장점: 멀티벤더 스토리지를 한 화면에서 볼 수 있다. 스토리지 전용이라 메트릭이 상세하다. STOR2RRD는 오래 검증됨. XorMon은 후속 제품.
- 단점: STOR2RRD는 신규 개발 중단(버그 수정만). XorMon 무료 에디션은 장비 수 제한이 있다. 대규모 환경이면 엔터프라이즈(유료) 필요.
Prometheus + Grafana — 범용 모니터링
스토리지 모니터링에도 쓸 수 있지만, 벤더별로 지원 수준이 다르다.
NetApp: Harvest (공식 exporter) → 잘 됨
Pure: pure-exporter (공식) → 잘 됨
Dell: 공식 exporter 없음. REST API로 커스텀 구축 필요
HPE: 공식 exporter 없음. SNMP로 기본 메트릭만 가능
FC Switch: SNMP로 포트 상태 정도. 상세 Fabric 분석 불가- 장점: 이미 Prometheus를 쓰고 있으면 통합 관리 가능. Grafana 대시보드를 자유롭게 커스텀할 수 있다. 호스트/네트워크/스토리지를 한 화면에 구성 가능.
- 단점: 벤더별 exporter 유무에 따라 수집 가능 메트릭이 천차만별. Dell/HPE는 직접 만들어야 할 수 있다. SNMP만으로는 볼륨별 상세 성능 데이터가 부족하다.
현실적인 조합:
- 벤더 클라우드 도구(Active IQ, Pure1 등)로 벤더별 상세 분석
- STOR2RRD 또는 Prometheus로 멀티벤더 통합 대시보드
- 알림은 한 곳으로 통합 (SNMP Trap → 통합 모니터링 → Slack/PagerDuty)
성능 병목 분석 — 어디가 느린지 찾는 법
"스토리지가 느려요"라는 신고가 오면, 문제가 정말 스토리지에 있는지부터 확인해야 한다. 스토리지팀 입장에서는 억울한 경우가 절반이다. 호스트 CPU가 100%여서 IO를 못 내보내는 건데 "스토리지가 느리다"고 하는 경우, 네트워크 혼잡인데 스토리지 탓을 하는 경우.
성능 병목 분석 흐름 (위에서 아래로)
① 호스트 레이어
$ iostat -xmt 5
→ await가 높은가? (IO 대기 시간)
→ %util이 100%인가? (로컬 디스크 포화)
$ top / vmstat 1
→ CPU iowait가 높은가?
→ 메모리 부족으로 swap IO가 발생하는가?
여기서 문제가 보이면 스토리지가 아니라 호스트 문제다.② 네트워크/패브릭 레이어 (호스트 정상일 때)
FC: fcinfo / fcns database 확인
→ 경로가 다 살아있는가?
→ CRC 에러, Link Failure가 늘고 있는가?
iSCSI: ping / iperf3 / netstat
→ 패킷 유실이 있는가?
→ MTU 불일치(Jumbo Frame) 문제인가?
멀티패스: multipath -ll
→ 경로 하나가 degraded인가?
→ ALUA 상태가 Non-Optimized 경로로만 가는가?③ 스토리지 컨트롤러 레이어 (네트워크 정상일 때)
벤더 CLI/GUI에서 확인:
→ 컨트롤러 CPU 사용률
→ 캐시 히트율
→ 볼륨별 IOPS/Latency
→ 특정 볼륨이 IO를 독점하고 있는가? (Noisy Neighbor)
벤더별 확인 명령:
NetApp: statistics show -object volume
qos statistics performance show
Dell: PowerStore Manager → Performance 탭
Pure: purecli volume monitor
HPE: CLI 또는 InfoSight 대시보드④ 디스크/SSD 레이어 (컨트롤러 정상일 때)
→ 특정 디스크의 응답 시간이 비정상인가?
→ RAID 리빌드가 진행 중인가?
→ SSD 수명(Wear Level)이 한계에 가까운가?이 순서대로 위에서 아래로 내려가면서 확인한다. 스토리지가 실제로 느린 경우는 ③, ④에서 잡힌다.
QoS — 시끄러운 이웃 잠재우기
하나의 스토리지를 여러 서비스가 공유하면, 한 서비스의 IO 폭주가 다른 서비스에 영향을 준다. 이걸 Noisy Neighbor 문제라고 한다. QoS(Quality of Service)로 제어한다.
QoS 설정 개념
[QoS 없음]
서비스A (배치 작업) ████████████████████ 80% 독점
서비스B (DB) ████ 20%만 남음 ← 느려짐!
[QoS 적용]
서비스A (배치) ██████████ 상한 50%
서비스B (DB) ██████████ 최소 30% 보장
여유 ████ 20%QoS 유형
┌──────────────────────────────────────────────────┐
│ 상한 (Max/Ceiling) │
│ "이 볼륨은 최대 10,000 IOPS까지만" │
│ → 배치 작업, 개발 환경에 적용 │
│ │
│ 하한 (Min/Floor) │
│ "이 볼륨은 최소 5,000 IOPS 보장" │
│ → 미션 크리티컬 DB에 적용 │
│ │
│ 주의: 하한은 물리 성능을 초과할 수 없다. │
│ 모든 볼륨의 하한 합계가 스토리지 전체 IOPS를 │
│ 넘으면 보장이 안 된다. 오버커밋하면 안 된다. │
└──────────────────────────────────────────────────┘벤더별 QoS 구현
┌──────────────┬────────────────────────────────────┐
│ NetApp ONTAP │ Policy Group으로 Max/Min IOPS 설정 │
│ │ Adaptive QoS: 용량 비례 자동 조절 │
│ │ → 가장 세밀한 제어 가능 │
├──────────────┼────────────────────────────────────┤
│ Dell │ Performance Policy로 상한 설정 │
│ PowerStore │ → Min 보장은 제한적 │
├──────────────┼────────────────────────────────────┤
│ Pure Storage │ QoS 상한 (Max Bandwidth, Max IOPS) │
│ │ → 단순함. 하한 보장은 미지원. │
│ │ "성능이 충분하니 QoS가 불필요"가 │
│ │ Pure의 철학이지만, 실제 Noisy │
│ │ Neighbor 발생 시 대응 수단 제한적.│
├──────────────┼────────────────────────────────────┤
│ HPE Alletra │ Performance Policy 기반 │
│ │ → InfoSight와 연동한 자동 분석 │
└──────────────┴────────────────────────────────────┘QoS를 너무 타이트하게 걸면 정상 워크로드도 제한을 받는다. "야간 배치에 IOPS 상한 5,000을 걸었는데, 월말에 데이터가 많아서 배치가 안 끝나요"라는 상황이 올 수 있다. QoS 설정 후에는 반드시 워크로드 패턴을 모니터링하면서 값을 조정해야 한다. 한 번 걸고 잊어버리면 안 된다.
용량 관리 — 부족하면 서비스가 멈춘다
스토리지 용량 부족은 서버 CPU 부족과 차원이 다르다. CPU가 100%면 느려지지만 동작은 한다. 스토리지 용량이 100%면 쓰기가 아예 안 된다. 씬 프로비저닝 환경에서 물리 용량이 바닥나면 볼륨이 오프라인되면서 서비스가 중단된다. 이건 장애가 아니라 운영 실패다.
용량 모니터링 구조 (씬 프로비저닝 환경)
┌──────────────────────────────────────────────────────┐
│ │
│ 논리 할당 용량: 100TB │
│ ████████████████████████████████████████ 100% │
│ (서버에 "100TB 줬다"고 보이는 크기) │
│ │
│ 실제 물리 사용량: 45TB │
│ ██████████████████░░░░░░░░░░░░░░░░░░░░ 45% │
│ (실제로 디스크에 쓰인 데이터) │
│ │
│ 물리 실효 용량: 63TB │
│ █████████████████████████░░░░░░░░░░░░░ 63TB │
│ │
│ 여유: 63TB - 45TB = 18TB (28%) │
│ │
│ ⚠ 논리 100TB > 물리 63TB = 오버프로비저닝 상태 │
│ 실제 사용량이 63TB에 도달하면 쓰기 불가! │
└──────────────────────────────────────────────────────┘모니터링 임계치
┌──────────────────┬─────────────────────────────┐
│ 물리 사용률 70% │ 주의 (Warning) │
│ │ → 용량 트렌드 분석 시작 │
├──────────────────┼─────────────────────────────┤
│ 물리 사용률 80% │ 경고 (Critical) │
│ │ → 증설 계획 수립 또는 │
│ │ 불필요 데이터 정리 │
├──────────────────┼─────────────────────────────┤
│ 물리 사용률 90% │ 긴급 (Emergency) │
│ │ → 즉시 용량 확보 작업 │
│ │ 스냅샷 정리, 고아 볼륨 삭제│
├──────────────────┼─────────────────────────────┤
│ 물리 사용률 95%+ │ 서비스 중단 임박 │
│ │ → 비상 대응 │
└──────────────────┴─────────────────────────────┘용량 부족 긴급 대응
90%를 넘겼다. 증설은 발주부터 입고까지 몇 주가 걸린다. 지금 당장 할 수 있는 것들이 있다.
긴급 용량 확보 방법 (즉시 가능)
1. 스냅샷 정리
- 보관 기간이 지난 오래된 스냅샷 삭제
- 효과: 수GB ~ 수TB 회수 가능
- 리스크: 삭제한 스냅샷 시점으로 복구 불가
2. 고아(Orphan) 볼륨 식별 및 정리
- 호스트에 매핑되어 있지 않은 볼륨
- 마지막 IO가 30일 이상 전인 볼륨
- 리스크: "안 쓰는 줄 알았는데 쓰고 있었다" 가능
- 반드시 서비스팀에 확인 후 정리
3. 데이터 리덕션 활성화
- 중복제거/압축이 꺼져 있는 볼륨에 켜기
- 효과: 워크로드에 따라 20~60% 절약
- 리스크: 컨트롤러 CPU 부하 증가. 성능 영향 가능. 피크 시간대에 켜면 역효과
4. Space Reclamation (UNMAP/TRIM)
- 호스트에서 삭제한 데이터가 스토리지에서는 아직 "사용 중"으로 보이는 경우
- UNMAP을 실행하면 실제 빈 공간이 회수됨
- 리스크: UNMAP 실행 중 IO 성능 일시 저하
5. QoS로 쓰기 속도 제한
- 급격한 데이터 증가를 일시적으로 억제
- 리스크: 서비스 성능 영향. 근본 해결은 아님
주의: 위 방법들은 모두 "시간 벌기"다. 근본적인 해결은 증설 또는 데이터 이전이다.
정기 리포트 — 운영 상태를 기록으로 남긴다
주간/월간 리포트를 만들어 보고하는 것도 스토리지 담당자의 업무다. 귀찮지만 이걸 안 하면 "스토리지 상태가 어떤가요?"라는 질문에 매번 실시간으로 조사해야 한다.
월간 스토리지 운영 리포트 구성
┌──────────────────────────────────────────────────┐
│ 1. 용량 현황 │
│ · 장비별 물리/논리 사용률 │
│ · 전월 대비 증감 │
│ · 3개월 후 예상 사용률 (트렌드 기반) │
│ │
│ 2. 성능 현황 │
│ · 장비별 평균/최대 Latency, IOPS │
│ · 성능 임계치 초과 이벤트 목록 │
│ · Top 5 볼륨 (IO가 가장 많은) │
│ │
│ 3. 이벤트/알람 요약 │
│ · 발생한 알람 건수 (심각도별) │
│ · 해결된 것 / 미해결 목록 │
│ · 디스크 장애 이력 │
│ │
│ 4. 변경 작업 이력 │
│ · 이번 달 수행한 변경 작업 목록 │
│ · 볼륨 할당/확장/삭제 건수 │
│ │
│ 5. 다음 달 계획 │
│ · 예정된 변경 작업 │
│ · 증설 필요 여부 │
│ · EOS/EOL 대응 일정 │
└──────────────────────────────────────────────────┘경영진용 vs 엔지니어용
경영진: 1페이지. 용량 사용률 그래프, 주요 이슈 요약, 비용. "현재 70% 사용, 6개월 뒤 90% 예상, 증설 예산 필요"
엔지니어: 상세 수치 전부. 볼륨별 성능, 알람 상세, CLI 로그.
리포트 자동화도 고려할 만하다. 벤더 REST API로 데이터를 수집하고 Python으로 가공해서 자동 게시하는 구조다. 다만 자동 리포트는 "숫자"만 보여준다. "왜 이런지", "뭘 해야 하는지"는 사람이 넣어야 한다. 자동 수집 + 수동 해석의 하이브리드가 현실적이다.
증설 vs 새 장비 — 어떻게 판단하는가
용량 부족 시 의사결정
현재 장비에 디스크/쉘프 추가 가능?
│
├── Yes ──► 증설
│ 장점: 빠름 (수일 내 가능), 관리 포인트 안 늘어남
│ 단점: 컨트롤러 성능 한계에 걸릴 수 있음
│ 기존 장비가 오래되면 부품 수급 문제
│ 유지보수 비용이 증가할 수 있음
│
└── No ───► 새 장비 도입
장점: 최신 기술, 성능/용량 모두 해결
단점: 시간 (수주~수개월), 비용 큼
데이터 마이그레이션 필요
관리 포인트 증가판단 기준
┌──────────────────────────────────────────────────┐
│ · 장비 잔여 수명 (EOS까지 2년 미만이면 새 장비) │
│ · 컨트롤러 CPU 여유 (증설해도 처리 가능한가) │
│ · 증설 비용 vs 신규 도입 비용 TCO 비교 │
│ · 벤더 할인/Trade-in 프로그램 활용 가능 여부 │
└──────────────────────────────────────────────────┘모니터링과 용량 관리는 매일 하는 일이지만, 이게 제대로 되어야 장애를 예방할 수 있다. "갑자기 터졌다"는 말은 대부분 "조짐이 있었는데 못 봤다"는 뜻이다.
다음 편에서는 데이터 효율화를 다룬다. 중복제거, 압축, 씬 프로비저닝. 용량을 절약하는 기술들의 원리와, 벤더가 말하는 "5
데이터 리덕션"의 실체를 파본다.이 글이 어떠셨나요?
관련 포스트
10. 일상 운영 1: 볼륨 할당과 변경 관리
스토리지 운영의 70%를 차지하는 일상 업무. 볼륨 할당 워크플로우, 벤더별 프로비저닝 CLI, 볼륨 확장/삭제의 주의사항, 변경 관리 위험도 분류, 서비스 카탈로그까지. 실수 한 번이 데이터를 날리는 영역의 안전한 운영법.
2026. 06. 08. PM 10:00Infrastructure9. 인수시험(SAT) — 장비를 내 것으로 만드는 과정
스토리지 인수시험(SAT)의 전체 절차. 하드웨어/라이선스 검증, 스냅샷 복원 테스트, 컨트롤러 페일오버 IO 중단 시간 판정 기준(30초 근거), 경로/전원/디스크 장애 시뮬레이션, fio 레이턴시 프로파일 해석법, 벤더 스펙 대비 실측 비교 방법, 성능 저하 시 5단계 원인 추적, 인수 결과 문서와 조건부 합격의 실무적 의미, 초기 안정화 기간 활용법까지.
2026. 06. 01. PM 10:00Infrastructure8. 구축 — 초기 설정과 호스트 연결
물리 설치 체크리스트, 초기 설정 8단계의 이유와 주의사항, FC/iSCSI/NFS 각각의 호스트 연결 절차와 트러블슈팅, 벤더별 multipath 차이, fio 결과 해석법, As-Built 문서화까지. 설계를 현실로 바꾸는 구축 실무.
2026. 05. 25. PM 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.