AI 학습용 병렬 스토리지 5종(DDN·Weka·VAST·IBM) PoC: 워크로드에 따라 달라지는 최적 구성

대규모 AI 학습에서 체감 속도를 좌우하는 건 GPU만이 아닙니다. 체크포인트 저장, 학습 데이터 로딩, 멀티모달 자산 처리처럼 워크로드가 다양해지면서 같은 스토리지라도 접근 패턴, 블록 크기, 노드 스케일, 전송 프로토콜(TCP vs RDMA)에 따라 성능이 크게 달라집니다. 단일 지표로 "가장 빠른 스토리지"를 고르기는 점점 어려워지고 있습니다.

엘리스클라우드는 AI/HPC 인프라에 많이 쓰이는 병렬 스토리지 다섯 종을 자체 클라우드 플랫폼 ECI(Elice Cloud Infrastructure)에 직접 연동해, 동일한 기준으로 PoC를 진행했습니다. 대상은 DDN AI400X3i, Weka Server, VAST Data Platform, IBM Storage Scale System 3200, IBM Storage Scale System 6000입니다. 각 플랫폼이 ECI와 원활히 연동되는지 확인하고, 고객 워크로드에 맞는 구성을 제안할 수 있도록 성능 특성을 파악하는 것이 목적이었습니다.

PoC 핵심 요약

첫째, 다섯 종의 스토리지 모두 ECI에 정상 연동되어 AI 학습 워크로드를 문제없이 돌릴 수 있음을 확인했습니다. ECI가 특정 벤더에 묶이지 않고 주요 병렬 스토리지와 두루 연동된다는 의미이기도 합니다.

둘째, 각 스토리지의 강점 영역이 뚜렷하게 갈립니다. 순차 읽기(체크포인트 복구), 순차 쓰기(체크포인트 저장), 4K 랜덤(DataLoader)의 상위권 구성이 매번 달랐고, 읽기와 쓰기를 동시에 잡는 스토리지는 관찰되지 않았습니다. "어느 스토리지가 절대 우위"가 아니라 어떤 워크로드가 지배적인지에 따라 적합 구성이 바뀐다는 결론입니다.

RDMA는 대부분의 구성에서 TCP와 같거나 더 높은 처리량을 제공했고, 일부 구간에서 관찰된 역전은 스토리지 자체의 한계가 아니라 해당 스택의 튜닝이 필요하다는 신호로 해석하는 것이 적절합니다.

다만 주의할 점이 있습니다. 이번 PoC는 소규모 구성에서 수행한 검증이라 관찰 수치는 각 스토리지의 절대 성능이 아니라 PoC 장비 규모 안에서의 값입니다. 운영 스케일에서는 더 높은 처리량이 가능하므로, 뒤에 이어지는 숫자는 "어느 스토리지가 몇 GiB/s를 내는가"보다 워크로드별 성능 특성으로 해석해야 합니다.

엘리스의 해답: ECI, 그리고 AI PMDC

엘리스그룹은 이번 PoC처럼 여러 벤더의 병렬 스토리지를 ECI에 직접 연동하고 운영해본 경험을 바탕으로 ECI에서 병렬 파일 시스템을 이미 정식 서비스로 제공하고 있습니다. 콘솔에서 원하는 용량의 파일 시스템을 만들어 GPU 가상머신에 바로 마운트하면, 별도의 스토리지 인프라를 구축하지 않아도 대규모 AI 학습을 곧바로 시작할 수 있습니다.

퍼블릭 클라우드만으로 풀기 어려운 요건이 있다면, 동일한 ECI 플랫폼을 고객 사이트에 그대로 구축해 프라이빗 또는 하이브리드 클라우드로 운영할 수도 있습니다. 데이터센터 인프라부터 새로 갖춰야 한다면 AI PMDC(Portable Modular Data Center)로 데이터센터까지 함께 구축하며, 이 과정에서 이번 PoC의 관찰을 바탕으로 학습 데이터셋 규모와 체크포인트 패턴, 스케일 계획에 맞는 스토리지 구성을 함께 설계합니다.

상세 기술 리포트

여기부터는 측정 방식과 워크로드별 결과를 세부적으로 정리한 기술 리포트입니다. 각 PoC는 벤더가 제공한 레퍼런스 구성을 기반으로 수행되었고, 검증 목적의 소규모 구성이라 처리량 상한도 PoC 장비 규모에 묶여 있습니다.

PoC에 사용된 병렬 스토리지 하드웨어 구성

벤더별 레퍼런스 구성이 서로 달라, 규모부터 네트워크 세대까지 상당한 차이가 있습니다.

단일 2U 어플라이언스(DDN, IBM SSS 3200)에서부터 12-노드 분리형 클러스터(VAST)까지 구성 규모가 큰 폭으로 다르고, 스토리지측 네트워크도 200GbE부터 400GbE까지 세대 차이가 있습니다. 따라서 이후 관찰 수치는 절대 비교가 아니라 각 레퍼런스 하드웨어에서의 성능 특성으로 읽어야 합니다.

아래 관찰 섹션에서는 특정 제품의 우열 비교로 오해되지 않도록 벤더명을 A, B, C, D, E로 익명화합니다. A–E와 위 제품 간의 매핑은 공개하지 않습니다.

PoC로 성능 특성을 확인해야 하는 이유

AI 학습에서 스토리지가 개입하는 구간은 크게 네 가지이며, 각각 I/O 특성이 다릅니다.

• 학습 데이터 로딩: DataLoader가 수천–수억 개 샘플을 병렬로 읽어오는 구간 — Random Read / Multi-file Random Read

• 체크포인트 저장: 수십 GB 단위 모델 state의 대용량 쓰기 — Sequential Write

• 체크포인트 복구: 저장된 state를 다시 읽어 오는 대용량 읽기 — Sequential Read

• 로그/메트릭 기록: 학습 중 지속되는 소량 쓰기 — Random Write

하나의 구성이 네 구간 모두에서 동일하게 뛰어나기는 어렵습니다. 벤더 자료에서 인용되는 "최대 XX GB/s"는 대부분 순차 읽기 기준이라 실제 체감 처리량을 충실히 대변하지 못합니다. 결국 스토리지 선택은 어떤 워크로드가 지배적인지를 먼저 정의하고, 해당 구간의 성능을 실측으로 확인한 뒤 결정해야 합니다.

테스트 환경과 FIO 프로파일

다섯 스토리지 모두 동일한 FIO 프로파일을 사용해 1 / 8 / 16노드 스케일에서 TCP와 RDMA 두 프로토콜을 각각 측정했습니다. 모든 PoC는 Ethernet 링크 위에서 수행했으며, 본문의 RDMA는 InfiniBand RDMA가 아닌 RoCEv2(RDMA over Converged Ethernet Version 2)를 가리킵니다. 클라이언트는 ECI의 G-NBTHS-1440 인스턴스(NVIDIA B200 GPU × 8)로, 1 / 8 / 16노드는 각각 8 / 64 / 128 GPU 규모에 해당합니다. 구성 A는 30노드(240 GPU) 구간까지 추가 측정 결과를 보유하고 있어 필요한 경우 함께 인용합니다.

공통 설정: ioengine=libaio, direct=1, runtime=180, time_based=1, group_reporting=1

본문의 처리량과 IOPS 수치는 모든 클라이언트 노드에서 동시에 돌린 FIO 결과의 집계 합산(FIO의 All clients 구간)입니다. 예를 들어 16노드 50 GiB/s는 16대가 동시에 낸 처리량의 합이며, 노드당 평균으로 보려면 노드 수로 나누어야 합니다. 평균 지연은 slat + clat(ms)이며, 대표값으로 16노드 결과를 먼저 제시합니다.

관찰 결과

체크포인트 복구 — Sequential Read (1M)

체크포인트 복구나 대용량 학습 데이터의 선형 로딩을 대표하는 구간입니다.

• E와 C가 상위권. 16노드 기준 E(TCP 50 GiB/s, 지연 40 ms)와 C(RDMA 43 GiB/s)가 나란히 선두이며, E와 B는 8노드에서 이미 포화에 근접, C는 16노드까지 꾸준히 상승하는 반면 A는 1노드부터 22 GiB/s대에서 평탄.

• 40 GiB/s 후반대 수렴은 PoC 링크 한계. 400 Gbps 클래스 인터페이스의 실효 대역폭 상한(약 46 GiB/s payload)에 근접한 값이므로, C와 E의 상한은 스토리지 자체의 한계가 아니라 측정 경로 한계. 더 큰 구성에서는 추가 여력이 있음.

• D는 RDMA 이상치. RDMA 전환 시 처리량이 크게 떨어지고 지연이 140 ms까지 증가 — 관찰 6의 이상치 분석에서 다시 다룸.

A 30노드 보유 측정: TCP 23.00 / RDMA 45.90 GiB/s. RDMA가 16→30노드에서 크게 상승하는 이례적 패턴.

체크포인트 저장 — Sequential Write (1M)

체크포인트 저장 구간을 반영합니다.

• A가 단독 선두. TCP 46 GiB/s대에서 8노드부터 포화한 뒤 30노드까지 평탄 유지. B는 RDMA 기준으로 A에 근접하지만 TCP에서는 크게 밀림.

• 읽기와 쓰기 동시 상위권 구성은 없음. 읽기에서 1위였던 E가 쓰기에서는 11 GiB/s대로 내려오고, D는 5–7 GiB/s에서 지연이 300 ms를 넘음. 체크포인트 저장과 복구가 모두 빈번한 환경이라면 두 구간을 따로 평가해야 함.

• A의 RDMA는 TCP 대비 -17%. 같은 구성의 읽기 구간은 정상이어서 쓰기 경로에 국한된 이상치로 보임 — 관찰 6에서 재분석.

A 30노드 보유 측정: TCP 46.00 / RDMA 35.40 GiB/s. TCP는 평탄, RDMA는 소폭 하락.

DataLoader — Random Read (4K)

AI DataLoader의 작은 무작위 I/O를 대표합니다. 이번 PoC에서 구성 간 격차가 가장 크게 벌어진 구간이기도 합니다.

• C가 압도적. 8노드에서 이미 3M IOPS대에 진입하고 16노드 지연도 1.3 ms로, 처리량과 지연이 동시에 상위권.

• D는 RDMA 이득이 가장 큼 (+160%, 2.6배). 노드가 늘수록 RDMA 효과가 꾸준히 커지므로, Random Read가 지배적인 워크로드라면 D에서는 RDMA를 반드시 활성화해야 함.

• E는 프로토콜 선택에 무관. TCP와 RDMA가 사실상 동일해 전환 이득이 없음.

DataLoader가 수십만 개 작은 파일을 무작위로 읽어 오는 대규모 샘플 기반 학습에서는 이 구간의 IOPS 상한이 체감 처리량에 그대로 반영됩니다.

A 30노드 보유 측정: TCP 1,336 / RDMA 1,265 k IOPS.

로그·메트릭 — Random Write (4K)

로그, 메트릭 기록, 중간 산출물 저장 구간의 특성입니다.

• C가 다시 선두. 8노드부터 700k IOPS대를 유지하며 지연도 5 ms 수준으로 가장 낮음.

• 블록 크기에 따라 순위가 뒤집힘. 순차 쓰기에서 하위권이었던 E가 4K 랜덤 쓰기에서는 370k로 중상위권으로 올라섬.

• 노드 늘린다고 항상 좋아지지 않음. A와 D는 노드 확장 시 오히려 IOPS가 감소하는 구간이 있어(A 8→16→30노드에서 192→174→147 k, D 8→16노드에서 288→210 k) 랜덤 쓰기 비중이 크면 스케일 검증 필요.

A 30노드 보유 측정: TCP 147 / RDMA 152 k IOPS.

실제 DataLoader 패턴 — Multi-file Random Read (128K)

AI DataLoader의 실제 접근 패턴과 가장 가까운 중간 크기 청크 병렬 읽기입니다.

• 상위 네 구성이 비슷한 수준에 수렴. 16노드 RDMA 기준 C, B, E, A 모두 41–49 GiB/s 범위. 체크포인트 복구 구간과 마찬가지로 링크 한계 영향이 큼.

• RDMA 이득이 가장 큰 구간. B는 TCP 대비 RDMA에서 +77%, A는 +48% 상승 — Multi-file 랜덤 읽기는 RDMA 전환 효과가 가장 뚜렷한 워크로드.

• D는 스케일 역전 이상치. 8노드 40 GiB/s에서 16노드 19 GiB/s로 절반 이하로 하락, 지연도 4배 이상 증가. 순차 읽기에서 본 양상과 같은 방향으로, 관찰 6에서 함께 분석.

A 30노드 보유 측정: TCP 23.00 / RDMA 53.40 GiB/s. RDMA가 30노드 구간에서 한 차례 더 상승.

RDMA 결과와 이상치 분석

RDMA는 CPU 개입과 복사 오버헤드를 줄이므로, 동일 링크 위에서 TCP 대비 같거나 더 높은 처리량이 기대 방향입니다. 16노드 기준 TCP 대비 RDMA 변화율은 다음과 같습니다.

• 대부분 기대 범위 안. B는 모든 테스트에서 +3 ~ +77%의 이득을 일관되게 보였고, E는 ±5% 이내로 두 프로토콜이 사실상 동등. C도 ±5% 노이즈 범위를 크게 벗어나지 않음.

• 눈에 띄는 음수 둘을 이상치로 분류. D와 A 일부 구간인데, 스토리지 자체의 성능 한계라기보다 특정 구성과 스케일 조합의 튜닝 이슈로 해석하는 것이 자연스러움.

이상치로 분류한 구간은 다음과 같습니다.

• D — Seq Read -64%, Seq Write -26%, Multi-file RR -42%. 8노드까지는 정상이다가 16노드에서만 급락. 16노드 지연도 Seq Read 140 ms, Multi-file RR 52 ms로 크게 증가. 다중 클라이언트 동시 접근에서 RDMA 큐와 혼잡 제어가 병목이 될 가능성이 높아 대규모 확장 전 스택 튜닝 필요.

• A — Seq Write -17%. 같은 구성의 다른 테스트는 정상이므로 전반적 RDMA 경로 문제가 아니라 쓰기 커밋과 캐시 경로에 국한된 현상으로 보임.

나머지 소폭 음수(A Random Write -8%, C Seq Write -6%, E의 -5% 이하)는 측정 노이즈로 보고 이상치로 잡지 않았습니다.

정리하면 RDMA는 대부분의 구성에서 기대대로 동작했고, 일부 구성과 스케일에서만 튜닝성 역전이 관찰되었습니다. 이상치는 성능 한계로 받아들이기보다 RDMA 스택과 스케일 파라미터를 점검하라는 신호로 읽는 것이 맞습니다.

구성별 특성 요약

• A — Sequential Write TCP가 30노드까지 45 GiB/s대를 평탄하게 유지해 순차 쓰기 구간에서 가장 강함. Multi-file Random Read의 RDMA 이득도 뚜렷. 단 Seq Write RDMA에서는 -17% 이상치가 있어 쓰기 경로 점검이 필요하고, Random Write는 노드가 늘수록 IOPS가 완만히 감소하는 경향.

• B — TCP → RDMA 이득이 전 테스트에서 가장 일관적(+3 ~ +77%). RDMA를 적극 활용하는 환경에서 가장 큰 효과를 보이는 구성.

• C — 순차, 랜덤, 혼합 패턴 전반에서 균형. 4K 랜덤 읽기와 쓰기에서 높은 IOPS와 낮은 지연을 동시에 확보.

• D — Random Read RDMA에서 +160% 이득이 크게 나지만, 16노드 Sequential Read와 Multi-file Random Read에서 RDMA 처리량 역전(이상치) 관찰. 대규모 확장 전 RDMA 스택 튜닝 필요.

• E — Sequential Read에서 PoC 링크 한계 근처(16노드 50 GiB/s)까지 도달하며 TCP/RDMA 차이도 거의 없음. 프로토콜 선택 자유도가 큰 구성. 8노드 이후 포화는 스토리지 자체의 한계가 아닌 링크 한계이므로, 더 큰 구성에서의 추가 여력은 별도 검증이 필요.

  
  

워크로드별로 확인할 지표

위 관찰을 실제 인프라 설계에 적용할 때 참고할 만한 체크 포인트입니다.

• 대규모 DataLoader 중심 학습 (이미지, 멀티모달, 수천–수억 샘플 기반): 4K 랜덤 읽기와 128K 혼합 읽기의 IOPS 상한과 지연

• 대용량 LLM 사전학습 (수십 GB 단위 체크포인트가 잦음): Sequential Write 처리량의 스케일 평탄성

• 복구와 리로드 중심 운영 환경 (학습 재개, 장애 복구가 잦음): Sequential Read 처리량과 지연

• RDMA 도입 전환: 실제 워크로드에 근접한 FIO 프로파일로 사전 검증 필수

이번 PoC에서 확인한 건 스토리지 선택은 "가장 빠른 제품"을 고르는 것이 아니라 우리 워크로드에서 어떤 구간이 지배적인지를 먼저 정의해야 한다는 점입니다.

엘리스는 이번 PoC에서 쌓은 관찰을 바탕으로 학습 데이터셋 규모와 체크포인트 패턴, 스케일 계획에 맞는 스토리지 구성을 함께 설계합니다. ECI 병렬 파일 시스템으로 바로 시작하는 구성부터, AI PMDC 기반 온프레미스·하이브리드 구축까지 AI 학습 인프라가 고민이라면 언제든 문의해 주세요.