고성능 NVMe SSD를 위한 SW RAID 선택: xiRAID vs mdadm 성능 검증 결과

안녕하세요, 이스파이스 기술 연구소입니다.

서버의 저장 장치는 이제 SAS/SATA SSD를 넘어, PCIe 인터페이스에 직접 연결되는 고속·저지연의 NVMe SSD가 거의 필수가 되었습니다. 드라이브 하나가 PCIe x4로 연결되어 7GB/s(PCIe G4) 혹은 14GB/s(PCIe G5)급 대역폭과 수십만~백만 IOPS를 냅니다.

그럼 이 장치를 RAID로 쓰려면 어떻게 하는 것이 가장 좋을까요?

1. NVMe에 잘 맞는 RAID?

SATA/SAS급 HDD나 SSD에서는 LSI사의 MegaRAID 제품군이 대표적입니다. 주요 서버 제조사들도 이 제품을 OEM으로 채택하여 탑재하고 있습니다. 그런데, 이 장치는 최대 PCIe x16으로 서버에 연결되어, 최대 PCIe x4의 연결인 NVMe의 경우 대역폭 손실이 생깁니다. PCIe 장치를 하나 더 거치니 지연 속도의 손실도 있지요.

간단히 계산해 볼까요? PCIe G4 NVMe 8개를 합치면 7GB/s × 8 = 56GB/s입니다. 반면 PCIe G4 x16의 이론 대역폭은 약 32GB/s라, 컨트롤러를 거치는 순간 절반 가까이가 묶여 버립니다.

연결 방식	데이터 경로	최대 대역폭 (PCIe G4 NVMe 8개)
HW RAID 컨트롤러	CPU → PCIe x16 → RAID 컨트롤러 → 드라이브	약 32GB/s (x16 한계)
NVMe Direct	CPU → 드라이브마다 PCIe x4	약 56GB/s (x4 × 8)

또 하나는 NVMe 고유의 기능입니다. 한 번은 고객분께 이런 질문을 받았습니다. "NVMe native command를 쓰려고 NVMe Direct 서버를 골랐더니, RAID가 없네요?"

HW RAID 컨트롤러 뒤에 있는 NVMe는 OS에서 컨트롤러가 만든 가상 디스크로 보입니다. 그래서 nvme-cli 같은 도구로 네임스페이스 관리, 펌웨어 업데이트, SMART 조회 같은 NVMe 고유 명령을 쓰기 어렵지요.

결국 NVMe의 성능과 기능을 온전히 쓰려면 드라이브를 CPU의 PCIe 레인에 직접 연결하는 NVMe Direct 구성이 답입니다. 실제로 최신 서버 중에는 NVMe 베이는 많은데 HW RAID 옵션은 아예 없는 모델도 있습니다.

문제는 이렇게 하면 RAID가 빠진다는 겁니다. 데이터 보호를 포기할 수는 없으니 결국 소프트웨어 RAID가 필요한데, 어떤 소프트웨어 RAID라야 NVMe 성능을 살릴 수 있을까요? 이번 글에서는 저희가 직접 측정한 결과로 이 질문에 답해 보려 합니다.

2. 소프트웨어 RAID 두 가지: mdadm과 xiRAID

리눅스에서 소프트웨어 RAID라고 하면 mdadm이 대표적이고 가장 일반적이었습니다. 다만 HDD 시절과 달리 NVMe 시대에는 RAID 5/6의 패리티 연산을 훨씬 빠르게 처리해야 하다 보니, 시스템 부하는 늘고 속도는 기대만큼 나오지 않는다고들 합니다.
그래서 최신 CPU의 기능을 잘 활용하는, NVMe에 특화된 xiRAID를 그 대안으로 함께 테스트해 보았습니다. 두 제품의 주요 차이는 다음과 같습니다.

항목	mdadm	xiRAID
개발 및 공급	오픈소스 (무료)	Xinnor사 상용 솔루션 (유료)
동작 방식	리눅스 커널 표준	커널 모듈 + 관리 도구(xicli)
가속 구조	범용 스택	Lockless 구조,멀티 코어 병렬 처리
기술 지원	커뮤니티와 포럼	제조사 공식 기술 지원 (SLA)

mdadm은 무료이고 어느 리눅스에서나 바로 쓸 수 있다는 게 가장 큰 장점이지요. xiRAID는 유료인 대신 Lockless 구조와 멀티 코어 병렬 처리로 패리티 연산을 빠르게 처리하고, 제조사의 기술 지원을 받을 수 있습니다.

그럼 실제로 얼마나 차이가 나는지 보겠습니다.

3. 테스트 환경

서버는 2-CPU 모델과 1-CPU 모델을 하나씩 준비했고, 두 서버 모두 NVMe Direct 백플레인 구조입니다.

항목	PowerEdge R750	PowerEdge R6715
프로세서	2x Intel Xeon Gold 6354 (18C, 3.0GHz)	1x AMD EPYC 9355P (32C, 3.55GHz)
메모리	512GB DDR4-3200 (32GB x16)	384GB DDR5-5200 (32GB x12)
드라이브 베이	2.5" 8베이 NVMe Direct (CPU당 4개)	2.5" 8베이 NVMe Direct
테스트 드라이브	8x 국내 M사 NVMe SSD 1.92TB (PCIe G4)	8x SK hynix PE8110 1.92TB (PCIe G4)

 

드라이브	구분	순차 읽기	순차 쓰기	랜덤 읽기 (4K, IOPS)	랜덤 쓰기 (4K, IOPS)
국내 M사 NVMe SSD 1.92TB (PCIe G4)	제조사 사양	7.0 GB/s	3.5 GB/s	1.6M	95K
	1개 실측	7.0~7.2 GB/s	5.0 GB/s	1.67~1.72M	748K
SK hynix PE8110 1.92TB (PCIe G4)	제조사 사양	6.5 GB/s	3.3 GB/s	1.0M	140K
	1개 실측	6.1~6.6 GB/s	3.2~3.4 GB/s	1.18~1.28M	805~829K

실측 랜덤 쓰기가 사양보다 크게 높은 건, 드라이브를 TRIM해 비운 직후에 측정했기 때문으로 보입니다.

소프트웨어는 Rocky Linux 9.6(커널 5.14.0-570), xiRAID 4.4.1, mdadm 4.3, fio 3.35이고, 모든 측정은 XFS 파일 시스템 위에서 했습니다.

• RAID: xiRAID와 mdadm 모두 strip(chunk) 128K로 맞추고, 그 외는 기본값
• XFS: RAID 구조에 맞춰 정렬하고 성능 위주의 마운트 옵션 적용
• 측정: Direct I/O 기준, RAID 초기화가 끝난 뒤 측정. 순차 I/O는 Queue Depth 32이며, 나머지 파라미터는 시스템 환경에 맞게 최적값 반영

이 글에서 RAID 구성은 "데이터 드라이브 + 패리티 드라이브" 수로 적습니다. 예를 들어 RAID 6 6+2는 드라이브 8개 중 6개 분량에 데이터를, 2개 분량에 패리티를 담는 구성이고, 4+2는 드라이브 6개짜리 구성입니다. 드라이브 2개까지 동시에 고장 나도 데이터를 잃지 않는 것이 RAID 6의 특징입니다.

4. 결과 1: 정상 상태의 성능

먼저 드라이브 8개로 만든 RAID 6(데이터 6 + 패리티 2)의 결과입니다. (xiRAID / mdadm)

읽기 성능은 다음과 같습니다. (xiRAID / mdadm)

드라이브 + 서버	순차 읽기 (GB/s)	랜덤 읽기 (IOPS)
M사 + R750	56.2 / 56.1	7.90M / 8.04M
M사 + R6715	58.0 / 57.8	10.9M / 8.52M
PE8110 + R750	47.8 / 45.0	7.70M / 8.07M
PE8110 + R6715	48.7 / 44.6	9.51M / 8.56M

• 쓰기: xiRAID가 순차 쓰기는 약 8~15배, 랜덤 쓰기는 약 40~60배 빨랐습니다. mdadm은 드라이브를 바꿔도 순차 쓰기가 2GB/s 안팎에 머물렀습니다.
• 순차 읽기: 둘 다 하드웨어 한계 근처까지 나옵니다.
• 랜덤 읽기: 비슷하거나 xiRAID가 조금 앞섰습니다. (측정 편차 약 ±10%)

패리티 연산이 없는 RAID 10(드라이브 8개)도 같은 형식으로 정리했습니다. (xiRAID / mdadm)

드라이브 + 서버	순차 쓰기 (GB/s)	순차 읽기 (GB/s)	랜덤 읽기 (IOPS)	랜덤 쓰기 (IOPS)
M사 + R750	18.2 / 18.7	56.2 / 56.2	8.29M / 6.39M	2.91M / 1.38M
M사 + R6715	18.9 / 19.1	57.9 / 57.9	10.3M / 6.20M	2.97M / 1.14M
PE8110 + R750	13.5 / 13.0	47.1 / 47.5	7.75M / 6.51M	3.19M / 1.32M
PE8110 + R6715	13.2 / 13.0	48.0 / 47.2	9.02M / 6.20M	3.12M / 1.11M

• 순차 읽기·쓰기: 두 방식이 거의 같았습니다. 패리티 계산이 없으니 둘 다 드라이브 한계까지 나옵니다.
• 랜덤 쓰기: 그래도 xiRAID가 2~3배 높았습니다.
• 랜덤 읽기: RAID 6와 달리 xiRAID가 뚜렷하게 앞섰습니다. 조합에 따라 19~66% 높았습니다.

지연 시간도 짧았습니다. 4K 요청을 하나씩 보냈을 때 읽기 평균 56µs, 쓰기 평균 79µs로, RAID를 거쳐도 NVMe의 짧은 지연이 거의 그대로였습니다. (xiRAID, R750 + M사, RAID 6 4+2)

5. 결과 2: 드라이브 장애 상태에서의 성능

RAID를 쓰는 이유는 결국 드라이브 장애에 대비하기 위함이지요. 여기서도 큰 차이를 확인할 수 있었습니다. 드라이브 8개로 만든 RAID 6(6+2)에서 드라이브를 강제로 RAID에서 제거하고 측정한 결과입니다. (xiRAID / mdadm)

• xiRAID: 드라이브가 하나에 장애가 나도 순차 읽기는 정상의 약 85%, 랜덤 읽기는 54~58%를 유지했습니다. 쓰기는 거의 그대로였습니다.
• mdadm: 하나만 장애가 나도 순차 읽기가 정상의 약 5%, 랜덤 읽기는 약 1%로 떨어졌습니다. 사실상 서비스가 멈춘 것과 비슷한 수준입니다.

그럼 이 상태가 얼마나 오래 갈까요? 빠진 드라이브를 새로 넣고 재구성(rebuild)에 걸리는 시간을 재 보았습니다.

부하가 없을 때도 9~25배 차이가 납니다. 실제 운영처럼 부하(70/30 랜덤 읽기·쓰기)를 걸면 차이는 더 벌어졌습니다. xiRAID는 12~28분 만에 재구성을 끝냈지만, mdadm은 4시간 동안 15%도 진행하지 못했습니다. 이 속도라면 27시간 넘게 위 그래프의 "1개 장애" 상태가 이어지는 셈입니다.

6. 왜 이런 차이가 날까요?

답은 단순합니다. RAID 5/6은 드라이브가 고장 났을 때 데이터를 되살릴 수 있도록 패리티를 계산해 함께 저장합니다. 이 계산을 전용 하드웨어가 맡는 것이 HW RAID이고, 서버의 CPU가 맡는 것이 SW RAID입니다.

그런데 mdadm의 RAID 5/6은 이 패리티 처리를 커널 스레드 하나가 맡습니다. 그래서 쓰기, 고장 중 읽기, 재구성을 위한 연산이 모두 CPU 코어 하나에 몰립니다. 실제로 재구성 중 mdadm은 코어 하나를 93~98% 쓰면서 400MB/s를 넘지 못했고, xiRAID는 여러 코어에 나눠 3.4~4.9GB/s로 처리했습니다.

HDD 시절에는 드라이브가 느려서 드러나지 않던 이 한계가, 드라이브 하나가 수 GB/s를 내는 NVMe에서는 그대로 병목이 된 셈입니다. mdadm도 파라미터를 조정해 이 부분을 상당히 보완할 수는 있지만, 기본 구조가 CPU 코어 하나에 묶여 있다는 점은 여전히 제약입니다.

7. 튜닝과 운영

테스트하는 동안 strip 크기, 파일 시스템 정렬과 마운트 옵션, 데이터 드라이브 수, 쓰기 병합, RAID를 나눠 구성하는 방식, 2소켓 서버에서의 드라이브 배치 같은 파라미터들이 성능에 영향을 주는 것을 확인했고, 경우에 따라 최대 약 50%까지 개선되기도 했습니다.

다만 이번 수치는 벤치마크 도구(fio)로 잰 것이라, 실제 서비스 워크로드에서는 성향이 달라질 수 있을 것입니다. 파일 크기, I/O 패턴, 파일 시스템을 어떻게 쓰는지를 보고 구성할 때 함께 맞춰 가는 것이 좋겠습니다.

8. 정리

테스트를 마치고 내린 결론은 간단합니다. NVMe SSD와 xiRAID는 궁합이 매우 좋습니다. HW RAID 없이도 최신 프로세서의 멀티 코어를 충분히 활용해 NVMe SSD의 장점을 최대한 살리면서, RAID 6의 쓰기 성능과 드라이브 고장 시의 안정성까지 모두 확보할 수 있었습니다.

xiRAID는 RAID 0/1/10/5/6은 물론, 드라이브 3개 장애까지 견디는 RAID 7.3과 50/60/70 같은 조합 구성도 지원해 대용량 구성에서도 선택지가 넓습니다.

AI 학습 체크포인트나 GPU 서버에 데이터를 공급하는 BeeGFS·NFS 스토리지, 고속 DB와 로그 처리, 가상화, 영상 제작처럼 빠른 디스크 I/O가 필요한 곳이라면 어디든 잘 맞습니다.

다만 최상의 성능을 내려면 구성과 워크로드에 맞는 튜닝이 필요할 수 있습니다. (주)이스파이스는 Xinnor사의 파트너로서 xiRAID를 직접 공급하고, 많은 경험을 바탕으로 구성 컨설팅부터 구축과 튜닝까지 전 과정을 제공해 드립니다. 서버 기반의 NVMe 스토리지 구성을 고민 중이시라면 언제든 문의 주시기 바랍니다.

긴 글 읽어 주셔서 감사합니다.