SSD 서버 vs HDD 서버 – 리눅스에서 성능 차이 테스트해보기

Views: 0

왜 SSD 서버와 HDD 서버를 비교해야 할까

트래픽이 늘고 응답 지연이 길어질수록 저장장치의 특성이 서비스 품질을 좌우한다. SSD는 낮은 지연과 높은 IOPS로 알려져 있지만, 모든 워크로드에서 무조건 유리한 것은 아니다. 순차 쓰기가 많은 로그 서버나 대용량 콜드 스토리지라면 HDD가 비용 대비 효율을 보일 수 있다. 리눅스에서 표준화된 방식으로 성능을 측정하고, 실제 워크로드와 맞춰 해석하는 과정이 필요하다.

테스트 전제와 환경 구성

동일한 사양의 두 대 서버(혹은 동일 서버의 두 개 디스크)를 준비한다.

  • OS: 최신 LTS 계열 리눅스(예: Ubuntu Server, RHEL 계열)
  • 커널 I/O 스케줄러: mq-deadline(SSD 권장), bfq(데스크톱/혼합), none(NVMe에서 종종 사용)
  • 파일시스템: ext4 또는 xfs로 동일하게 생성
  • 마운트 옵션: noatime, nodiratime 적용으로 메타데이터 쓰기 최소화
  • 전원/성능 프로파일: CPU 고성능 모드, 터보 허용
  • 백그라운드 작업 최소화: 크론, 로그 롤테이션 일시 중지

파티션과 파일시스템 생성 예시는 다음과 같다:

# 파티션 생성 후
mkfs.ext4 -F /dev/sdx1
mount -o noatime,nodiratime /dev/sdx1 /mnt/test

핵심 벤치마크 도구와 목적

  • fio: 임의/순차 읽기·쓰기, 큐깊이 변화, 블록 크기에 따른 IOPS/대역폭/지연 측정
  • ioping: 저장장치 지연(latency) 감 잡기
  • hdparm: 순차 읽기 속도 대략 측정(HDD에서 차이 확인에 유용)
  • iostat, vmstat, pidstat: 테스트 중 시스템 관측(대기 시간, CPU iowait)
  • 애플리케이션 수준: sysbench fileio, 데이터베이스용 미니 벤치, Nginx 정적 파일 서빙

기본 테스트 시나리오 설계

워크로드를 세 가지 카테고리로 나눈다.

  1. 순차 읽기·쓰기(백업, 미디어 스트리밍, 로그 압축)
  2. 임의 읽기·쓰기(데이터베이스 인덱스, 작은 파일 접근)
  3. 혼합(읽기/쓰기 7:3 또는 5:5, 큐깊이 변화)

각 시나리오는 블록 크기(4K, 16K, 1M), 큐깊이(QD 1, 4, 32), 쓰기 동기화 옵션(direct=1, fsync)을 바꿔가며 수행한다.

fio 예제 1: 4K 임의 읽기(IOPS/지연)

fio --name=randread_4k --filename=/mnt/test/testfile --size=20G \
    --bs=4k --iodepth=32 --rw=randread --ioengine=libaio --direct=1 \
    --runtime=60 --time_based --numjobs=1 --group_reporting

해석 포인트:

  • SSD 서버는 수만~수십만 IOPS, 평균 지연 수백 µs~수 ms
  • HDD 서버는 수백~수천 IOPS, 평균 지연 수 ms~수십 ms
  • clat(completion latency), slat(submission latency)을 함께 본다

fio 예제 2: 1M 순차 쓰기(백업/로그)

fio --name=seqwrite_1m --filename=/mnt/test/testfile --size=20G \
    --bs=1m --iodepth=8 --rw=write --ioengine=libaio --direct=1 \
    --runtime=60 --time_based --numjobs=1 --group_reporting

해석 포인트:

  • SSD는 컨트롤러/캐시에 따라 수백 MB/s~수 GB/s
  • HDD는 디스크 회전 속도와 플래터 밀도에 따라 150~250MB/s 수준
  • 쓰기 증폭, TRIM 여부에 따라 편차 발생

ioping으로 지연 감 파악

ioping -c 20 /mnt/test

평균/최대 지연을 확인해 워크로드의 P95, P99 지연을 추정한다. 트랜잭션 서비스는 꼬리 지연(P99)이 사용자 체감에 더 직접적이다.

hdparm으로 순차 읽기 대략 측정(HDD 비교용)

hdparm -Tt /dev/sdx

-T(캐시)와 -t(디스크) 값을 구분해 본다. 캐시 수치는 과대평가되므로 -t를 주로 참고한다.

관측과 병목 진단

테스트와 동시에 아래 지표를 모니터링한다:

iostat -x 1
vmstat 1
pidstat -dl 1

중요 해석:

  • iostat -x의 await, svctm, %util이 높으면 디스크 대기 병목
  • vmstat의 wa 필드가 높으면 I/O 대기로 CPU가 놀고 있는 상태
  • 프로세스별 지연은 pidstat -d로 확인

애플리케이션 관점 테스트

파일시스템 수준을 넘어 실제 서비스 패턴으로 검증한다.

sysbench fileio

sysbench fileio --file-total-size=20G prepare
sysbench fileio --file-total-size=20G --file-test-mode=rndrw \
  --time=60 --max-requests=0 run
sysbench fileio cleanup

데이터베이스 소형 워크로드 예

MySQL/InnoDB에서 데이터 디렉토리를 각각의 디스크에 두고 innodb_flush_log_at_trx_commit(1,2,0), sync_binlog(1,0)을 바꿔 TPS/지연을 기록한다. SSD는 동기 쓰기 비용이 낮아 커밋 지연이 크게 줄어든다.

결과가 보여주는 결론(경향)

  • 임의 I/O 중심 서비스: SSD 서버가 압도적 우위. HDD는 헤드 시킹 때문에 IOPS가 급격히 낮다.
  • 순차 I/O 중심 서비스: HDD도 일정 수준 성능을 보이지만, SSD는 높은 대역폭과 더 안정적인 지연 분포로 여전히 유리하다.
  • 지연의 안정성: SSD는 P95, P99 지연이 타이트하게 붙는 경향. HDD는 부하가 몰리면 긴 꼬리 지연이 빈번하다.
  • 다중 큐/높은 동시성: SSD는 큐깊이를 올릴수록 더 높은 IOPS를 낸다. HDD는 큐를 올려도 지연만 늘어나기 쉽다.

리눅스 튜닝 체크리스트

  • I/O 스케줄러: NVMe/SSD는 mq-deadline 또는 none으로 비교 시험
cat /sys/block/nvme0n1/queue/scheduler
echo mq-deadline > /sys/block/nvme0n1/queue/scheduler
  • 파일시스템 마운트: noatime으로 불필요한 메타데이터 쓰기 최소화
  • TRIM: 주기적 fstrim 또는 마운트 옵션 discard(실시간은 성능 저하 가능, 주기적 fstrim 권장)
fstrim -v /
  • 스왑: SSD 사용 시 스왑 접근 지연이 낮지만, 과도한 스왑 의존은 지양. vm.swappiness 조절
sysctl vm.swappiness=10
  • RAID 고려: SSD는 RAID1/10에서 읽기/쓰기 확장 이점이 크고, HDD는 RAID 설정과 캐시 정책에 민감
  • 전원 보호: SSD는 전원 장애 시 데이터 보호 기능(PLP) 유무를 확인

비용·용량·내구성 관점

  • 비용/GB: HDD 우위. 대용량 콜드 데이터와 백업 레이어로 적합
  • 성능/와트: SSD 우위. 트랜잭션·검색·로그 분석 등 지연 민감 워크로드에 적합
  • 내구성(TBW/DWPD): 엔터프라이즈 SSD는 쓰기 내구성 스펙이 명확해 운영 계획 수립이 쉽다
  • 수명 예측: smartctl로 마모도, 재할당, 오류 카운터를 정기 점검
smartctl -a /dev/sdx

벤치마크 리포트 템플릿(바로 적용 가능)

아래 표 형식을 그대로 사용해 결과를 담으면 비교가 쉽다.

  • 환경 요약: CPU/메모리/커널/파일시스템/스케줄러/마운트 옵션
  • 워크로드: randread 4K QD1/4/32, randrw 70/30 4K, seqread 1M, seqwrite 1M
  • 메트릭: IOPS, BW(MB/s), 평균 지연(ms), P95/P99(ms), CPU iowait(%)
  • 관측: iostat/vmstat 주요 값, 특이 이벤트
  • 결론: 워크로드별 적합 스토리지와 권장 설정

실전 적용 팁

  1. 서비스를 멈추지 않고 측정하려면, 운영 디스크와 별도 파티션/마운트를 테스트 용도로 분리한다.
  2. 테스트 파일 크기는 장치 캐시보다 충분히 크게 설정한다(최소 수 GB).
  3. 단일 측정 값에 의존하지 말고, QD·블록 크기·읽기/쓰기 비율을 바꾸며 반복 측정한다.
  4. 지연의 꼬리(P99)를 반드시 보고 SLO에 맞는지 점검한다.
  5. 결과를 운영 로그·메트릭과 합쳐 인과관계를 확인한다.

결론

리눅스에서 동일 조건으로 SSD 서버와 HDD 서버를 테스트해 보면 임의 I/O와 지연 안정성에서 SSD가 확실한 이점을 보인다. 반면 순차적이고 대용량 중심의 워크로드, 아카이빙이나 백업 계층에서는 HDD가 여전히 비용 효율적일 수 있다. 핵심은 서비스의 접근 패턴을 정확히 파악하고, fio와 관측 도구를 통해 수치로 증명한 뒤, 파일시스템·I/O 스케줄러·마운트 옵션을 맞추는 것이다. 이 글의 절차와 커맨드를 그대로 적용해 자신만의 워크로드를 검증하면, 예산과 성능 사이에서 가장 합리적인 선택을 빠르게 도출할 수 있다.

정보 추천글 더보기