오늘 디스크 구성 검토를 하면서 가장 크게 배운 점은 하나였다.
디스크는 “몇 TB냐”보다 “얼마나 빠르게 읽고 쓸 수 있느냐”가 먼저다.
처음에는 디스크 용량, RAID 구성, 보관 기간을 중심으로 생각하기 쉬웠다.
하지만 Splunk처럼 로그를 계속 수집하고, 동시에 검색까지 수행하는 시스템에서는
단순 저장공간보다 IOPS, RAID write penalty, 디스크 확장성, Hot/Warm/Cold 데이터 배치가 훨씬 중요하다.
Splunk 공식 문서에서도 인덱싱은 I/O 집약적인 작업이며,
인덱서가 데이터를 효율적으로 수집·파싱하고 검색 요청에 응답하려면 충분한 디스크 I/O가 필요하다고 설명한다.
또한 Splunk Enterprise 참고 하드웨어 문서에서는 HDD 기반 스토리지의 sustained IOPS 기준을 명시하고 있다.
1. 디스크 용량만 보면 위험하다
디스크 설계에서 흔히 먼저 보는 값은 다음과 같다.
- 일 수집량
- 보관 기간
- 원본 대비 인덱스 압축률
- RF/SF 구성
- RAID 이후 유효 용량
물론 이것도 중요하다. 하지만 이것만 보면 “데이터를 저장할 수 있느냐”만 판단하게 된다.
Splunk 운영에서는 질문이 하나 더 필요하다.
“저장할 수 있는가?”가 아니라 “저장하면서 검색까지 버틸 수 있는가?”
예를 들어 용량은 충분해도 IOPS가 부족하면 다음과 같은 문제가 생길 수 있다.
- 인덱싱 지연
- 검색 속도 저하
- 디스크 대기 증가
- iowait 상승
- 검색 작업 지연 또는 타임아웃
- 클러스터 복제/검색 성능 저하
그래서 디스크 검토 시에는 용량 산정과 함께 반드시 IOPS 산정을 같이 해야 한다.
2. IOPS는 디스크 성능의 핵심 지표다
IOPS는 Input/Output Operations Per Second의 약자로, 디스크가 1초에 처리할 수 있는 읽기/쓰기 작업 수를 의미한다.
로그 시스템에서는 대량의 작은 파일·블록을 계속 쓰고 읽는 일이 많기 때문에, 단순 처리량보다 IOPS가 체감 성능에 더 직접적으로 영향을 줄 수 있다.
특히 HDD는 SSD보다 랜덤 I/O 성능이 낮다.
오늘 검토한 기준처럼 SAS HDD 1개를 약 200 IOPS 수준으로 가정하면,
디스크 개수와 RAID 방식에 따라 실제 사용할 수 있는 IOPS가 크게 달라진다.
간단한 산식은 다음과 같다.
Raw IOPS = 단일 디스크 IOPS × 디스크 개수
실효 Write IOPS = Raw IOPS ÷ RAID Write Penalty
예를 들어 SAS HDD 4개, 디스크당 200 IOPS라고 가정하면 Raw IOPS는 다음과 같다.
200 IOPS × 4개 = 800 IOPS
하지만 RAID 구성에 따라 실제 쓰기 성능은 달라진다.
RAID 10 Write IOPS ≈ 800 ÷ 2 = 400 IOPS
RAID 5 Write IOPS ≈ 800 ÷ 4 = 200 IOPS
RAID 5는 패리티 계산 때문에 쓰기 작업 시 기존 데이터 읽기, 기존 패리티 읽기, 새 데이터 쓰기, 새 패리티 쓰기 과정이 발생한다. 이 때문에 일반적으로 RAID 5는 write penalty가 4로 계산된다.
즉, 같은 디스크 4개를 쓰더라도 RAID 10과 RAID 5의 쓰기 성능은 크게 달라질 수 있다.
3. RAID 5는 용량 효율은 좋지만 쓰기 성능에 불리하다
RAID 5의 장점은 유효 용량이 비교적 많이 나온다는 점이다.
하지만 Splunk 관점에서는 주의해야 한다. Splunk 인덱서는 계속 데이터를 쓰고, 동시에 검색도 처리한다.
따라서 쓰기 성능이 떨어지는 RAID 구성은 Hot/Warm 영역에는 부담이 될 수 있다.
정리하면 다음과 같다.
| RAID 구성 | 장점 | 단점 | Splunk 관점 |
| RAID 10 | 성능 좋음, 장애 대응 안정적 | 유효 용량 50% 수준 | Hot/Warm에 적합 |
| RAID 5 | 유효 용량 좋음 | 쓰기 페널티 큼 | 성능 민감 영역에는 부적합 |
| RAID 50 | RAID 5보다 확장성과 성능 개선 가능 | 여전히 패리티 기반 | Cold 영역 중심 검토 가능 |
오늘 배운 핵심은 이것이다.
RAID 5 또는 RAID 50은 “용량을 확보하기 위한 구성”이지, “고성능 쓰기 처리를 위한 구성”은 아니다.
따라서 RAID 5는 Hot/Warm보다 Cold 영역처럼 상대적으로 오래된 데이터를 보관하는 영역에 사용하는 것이 더 안전하다.
4. Splunk의 Hot/Warm/Cold 구조를 알아야 디스크 배치를 이해할 수 있다
Splunk는 인덱스 데이터를 bucket 단위로 관리한다.
기본적으로 데이터는 Hot, Warm, Cold, Frozen 단계로 이동한다.
Splunk 문서에 따르면 인덱스 디렉터리 아래에는 bucket 상태에 따라 hot/warm, cold, thawed 등의 하위 디렉터리가 구성되며, Hot/Warm과 Cold 경로는 별도로 설정할 수 있다.
또한 검색은 Hot, Warm, Cold bucket을 대상으로 수행될 수 있다.
간단히 정리하면 다음과 같다.
| 구분 | 특징 | 요구사항 |
| Hot | 현재 쓰기 중인 최신 데이터 | 가장 빠른 디스크 필요 |
| Warm | 쓰기는 끝났지만 최근 검색 가능성이 높은 데이터 | 빠른 디스크 권장 |
| Cold | 오래된 데이터, 검색 빈도 낮음 | 상대적으로 저렴한 디스크 가능 |
| Frozen | 검색 대상에서 제외되거나 아카이브/삭제 | 별도 보관 정책 필요 |
즉, 모든 데이터를 같은 성능의 디스크에 둘 필요는 없다.
하지만 Hot/Warm은 성능이 중요하고, Cold는 용량 효율이 더 중요하다. 그래서 RAID 10은 Hot/Warm에, RAID 5/50은 Cold에 검토하는 방식이 실무적으로 더 자연스럽다.
5. 내부 디스크 구성은 확장성이 제한적이다
오늘 헷갈렸던 부분 중 하나가 “서버 내부 디스크로 구성하면 나중에 증설이 어렵다”는 말이었다.
이 말은 서버 안에 직접 장착한 로컬 디스크를 기준으로 저장공간을 구성하면,
나중에 디스크 베이, RAID 컨트롤러, 서버 슬롯, 장애 작업 등의 제약을 받는다는 뜻이다.
예를 들어 서버에 디스크를 6개 꽂고 RAID를 구성했다면, 이후 용량이나 IOPS가 부족할 때 선택지가 많지 않다.
- 디스크 베이가 남아 있어야 추가 가능
- RAID 재구성 작업이 필요할 수 있음
- 작업 중 장애 리스크가 있음
- 경우에 따라 서버 추가가 필요함
- 데이터 이전이나 재배치가 필요할 수 있음
그래서 대규모 또는 장기 운영 시스템에서는 SAN 같은 외부 스토리지 구성이 더 유연할 수 있다.
6. SAN과 iSCSI는 같은 개념이 아니다
오늘 가장 중요한 개념 정리 중 하나는 SAN과 iSCSI의 차이다.
SAN은 구조이고, iSCSI는 그 구조에서 사용할 수 있는 연결 프로토콜이다.
SAN, 즉 Storage Area Network는 서버와 스토리지를 연결하는 전용 스토리지 네트워크 구조다.
IBM은 SAN을 서버, 스토리지 시스템, 네트워크 스위치, 소프트웨어 및 서비스를 결합한 전용 네트워크라고 설명한다.
반면 iSCSI는 TCP/IP 네트워크를 통해 SCSI 스토리지 명령을 전달하는 방식이다.
Red Hat 문서에서도 iSCSI initiator가 iSCSI target에 연결해 스토리지 장치에 접근하는 구조를 설명한다.
쉽게 말하면 다음과 같다.
SAN = 스토리지 전용 네트워크 구조
iSCSI = SAN을 구현할 때 사용할 수 있는 프로토콜 중 하나
그래서 “iSCSI 기반으로 Cold 영역을 구성한다”는 말은,
외부 스토리지를 네트워크 기반 블록 스토리지로 연결해 Splunk Cold 데이터를 저장하겠다는 의미로 이해할 수 있다.
7. AWS SSD에서 IDC SAS HDD로 이동하면 성능 차이를 확인해야 한다
현재 AWS 환경에서 SSD 기반 스토리지를 사용하고 있다면,
IDC 이관 후 SAS HDD 기반 스토리지로 바뀔 때 성능 차이를 반드시 확인해야 한다.
AWS EBS는 볼륨 유형별로 IOPS와 처리량 특성이 다르며,
SSD 기반 볼륨은 IOPS와 throughput을 기준으로 성능을 제공한다.
따라서 단순히 “IDC에 디스크 용량이 충분하다”만으로는 부족하다.
확인해야 할 것은 다음이다.
현재 AWS SSD IOPS
↓
이관 후 IDC SAS HDD RAID 구성 기준 IOPS
↓
감소 비율
↓
Splunk 수집/검색 성능 영향
예를 들어 현재 AWS SSD 기반에서 충분한 IOPS를 사용하고 있었는데,
IDC에서 SAS HDD RAID 5로 구성하면 IOPS가 크게 떨어질 수 있다.
이 경우 고객에게 설명해야 할 포인트는 명확하다.
“용량은 충족하더라도, IOPS가 부족하면 Splunk 성능 저하가 발생할 수 있습니다.”
8. 실무 체크리스트
디스크 구성 검토 시 앞으로는 아래 순서로 확인해야 한다.
1) 용량 산정
일 수집량 × 보관 기간 × 복제 계수 × 압축/인덱스 비율
확인 항목은 다음과 같다.
- 일 수집량
- 보관 기간
- 인덱서 수
- RF/SF
- Hot/Warm/Cold 분리 여부
- RAID 이후 유효 용량
2) IOPS 산정
단일 디스크 IOPS × 디스크 수 ÷ RAID write penalty
확인 항목은 다음과 같다.
- 디스크 종류: SSD, SAS HDD, SATA HDD
- 디스크 개수
- RAID 구성
- 컨트롤러 캐시 여부
- Read/Write 비율
- Random/Sequential I/O 특성
3) Splunk 데이터 영역별 배치
Hot/Warm = 성능 중심
Cold = 용량 중심
Frozen = 보관 정책 중심
확인 항목은 다음과 같다.
- Hot/Warm은 빠른 디스크 사용 여부
- Cold는 별도 경로 구성 여부
- Cold 영역 검색 빈도
- iSCSI/SAN 사용 시 네트워크 병목 여부
- 장애 시 복구 방식
4) 확장성 검토
확인 항목은 다음과 같다.
- 내부 디스크 증설 가능 여부
- 디스크 베이 여유
- RAID 재구성 가능 여부
- 서버 추가 필요 여부
- SAN/iSCSI 확장 가능 여부
- 장기 보관 데이터 증가 대응 방안
9. 오늘의 결론
오늘 DISK 관련해서 배운 핵심은 다음과 같다.
첫째, 디스크는 용량보다 IOPS를 먼저 봐야 한다.
둘째, RAID 5는 유효 용량은 좋지만 쓰기 성능이 떨어질 수 있다.
셋째, Splunk Hot/Warm 영역은 성능 중심으로, Cold 영역은 용량 중심으로 설계해야 한다.
넷째, 내부 디스크는 확장성이 제한적이고, SAN/iSCSI는 더 유연한 확장 구조를 제공할 수 있다.
다섯째, AWS SSD에서 IDC SAS HDD로 이동할 경우 성능이 얼마나 떨어지는지 IOPS 기준으로 비교해야 한다.
결국 Splunk 디스크 설계에서 중요한 질문은 이것이다.
“이 디스크가 데이터를 저장할 수 있는가?”가 아니라,
“이 디스크가 Splunk의 수집과 검색 부하를 지속적으로 버틸 수 있는가?”
앞으로 디스크 구성 검토 시에는 용량 산정표만 만들 것이 아니라, IOPS 산정표와 RAID별 성능 리스크까지 함께 제시해야겠다.