3. 병렬 파일 시스템과 분산 스토리지 — Lustre, GPFS, HDFS
Lustre, GPFS, BeeGFS, HDFS, Ceph, MinIO까지. HPC와 AI 학습 환경에서 병렬 파일 시스템과 분산 스토리지가 왜 필요한지, 각각의 아키텍처와 포지셔닝을 현장 관점에서 비교한다.
"스토리지 레이턴시가 1ms인데, GPU 1000장이 동시에 읽으면 어떻게 될까?"
단순 산수다. 아무리 빠른 올플래시 SAN이라도 수백, 수천 개의 노드가 동시에 같은 데이터를 읽으려고 덤비면 컨트롤러가 버티질 못한다. 전통적인 SAN/NAS는 컨트롤러가 1~2개다. 아무리 성능이 좋아도 병목은 결국 거기서 생긴다.
HPC(고성능 컴퓨팅), 빅데이터, AI 학습. 이런 워크로드에서는 스토리지의 접근 방식 자체가 달라야 한다. 데이터를 여러 서버에 쪼개서 저장하고, 여러 경로로 동시에 읽는다. 이게 병렬 파일 시스템과 분산 스토리지의 핵심 아이디어다.
전통 NAS vs 병렬 파일 시스템
차이를 한 장으로 보면 이렇다.
[ 전통 NAS ] [ 병렬 파일 시스템 ]
클라이언트A ─┐ 클라이언트A ──┬──► 데이터서버1
클라이언트B ─┼──► NAS 헤드 1대 클라이언트B ──┼──► 데이터서버2
클라이언트C ─┤ (병목!) 클라이언트C ──┼──► 데이터서버3
클라이언트D ─┘ 클라이언트D ──┴──► 데이터서버4
모든 IO가 한 곳을 통과 파일이 여러 서버에 분산,
→ 클라이언트가 늘면 느려짐 클라이언트가 직접 접근
→ 서버를 추가하면 성능도 증가병렬 파일 시스템의 핵심은 두 가지다. 하나는 데이터를 여러 서버에 스트라이핑한다는 것. 하나의 파일을 조각내서 여러 데이터 서버에 분산 저장한다. 클라이언트는 이 조각들을 동시에 읽으니 처리량이 서버 수에 비례해서 올라간다.
다른 하나는 메타데이터와 데이터의 분리다. "이 파일이 어디에 있는가"라는 정보(메타데이터)를 관리하는 서버와, 실제 데이터를 저장하는 서버가 따로 있다. 클라이언트는 먼저 메타데이터 서버에 물어보고("이 파일 어디 있어?"), 그 다음 데이터 서버에 직접 접근한다.
Lustre — HPC의 사실상 표준
전 세계 Top500 슈퍼컴퓨터의 상당수가 Lustre를 쓴다. 국가급 HPC 환경에서 사실상 표준이다.
┌─────────────┐ ┌─────────────┐
│ MDS │ │ MDS │ ← 메타데이터 서버
│ (MDT) │ │ (MDT) │ 파일 위치 정보 관리
└──────┬──────┘ └──────┬──────┘
│ │
─────┴───────────────────┴─────── Lustre 네트워크 (LNet)
│ │ │
┌──────┴──┐ ┌────┴────┐ ┌─┴───────┐
│ OSS │ │ OSS │ │ OSS │ ← 오브젝트 스토리지 서버
│┌──────┐ │ │┌──────┐ │ │┌──────┐ │ 실제 데이터 저장
││ OST │ │ ││ OST │ │ ││ OST │ │
││ OST │ │ ││ OST │ │ ││ OST │ │ ← OST: 실제 디스크 그룹
│└──────┘ │ │└──────┘ │ │└──────┘ │
└─────────┘ └─────────┘ └─────────┘
MDS: Metadata Server (+ MDT: Metadata Target)
OSS: Object Storage Server (+ OST: Object Storage Target)
파일 하나가 여러 OST에 스트라이핑된다.
클라이언트는 MDS에서 위치를 확인 후, OSS에 직접 접근한다.Lustre의 강점은 처리량이다. OSS를 추가하면 처리량이 선형으로 증가한다. 수백 GB/s의 순차 읽기/쓰기가 가능하다. 기상 시뮬레이션이나 유전체 분석처럼 거대한 파일을 빠르게 읽고 써야 하는 워크로드에 최적화되어 있다.
약점은 메타데이터 성능이다. 작은 파일 수백만 개를 다루면 MDS가 병목이 된다. ls -la를 수백만 개 파일이 있는 디렉토리에서 치면 한참 걸린다. DNE(Distributed Namespace)로 MDS를 여러 대로 분산하는 기능이 추가됐지만, 전통 NAS의 메타데이터 처리 성숙도에는 아직 미치지 못한다.
운영 관점에서 Lustre는 쉽지 않다. 설치부터 복잡하고, OST 밸런싱(데이터가 특정 OST에 몰리는 문제), failover 설정, 커널 모듈 의존성 관리까지 신경 쓸 게 많다. "돌아가면 빠르지만, 돌아가게 만드는 게 일"이라는 게 현장의 솔직한 평가다.
GPFS / IBM Spectrum Scale — 엔터프라이즈의 선택
IBM의 GPFS(General Parallel File System)는 Lustre와 다른 철학으로 만들어졌다. 현재는 Spectrum Scale이라는 이름으로 불린다.
┌──────────────────────────────────────────────┐
│ GPFS / IBM Spectrum Scale │
│ │
│ 노드A ◄────► 노드B ◄────► 노드C │
│ │ │ │ │
│ 디스크 디스크 디스크 │
│ │
│ 모든 노드가 메타데이터 + 데이터에 접근 가능 │
│ 토큰 기반 분산 락으로 일관성 유지 │
└──────────────────────────────────────────────┘
Lustre: MDS와 OSS가 역할 분리 (비대칭)
GPFS: 모든 노드가 동등 (대칭형)Lustre가 MDS와 OSS를 분리하는 비대칭 구조라면, GPFS는 대칭형이다. 모든 노드가 메타데이터와 데이터 모두에 접근할 수 있다. 토큰 기반 분산 락 매니저가 동시 접근의 일관성을 보장한다.
GPFS의 강점은 안정성과 엔터프라이즈 기능이다. 정책 엔진으로 자동 티어링(ILM)을 걸 수 있고, 스냅샷, 복제, 암호화 같은 엔터프라이즈 기능이 기본 내장이다. 금융권 HPC나 엔터프라이즈 AI 인프라에서 Lustre 대신 GPFS를 선택하는 이유가 이거다.
단점은 비용이다. 상용 라이선스가 필요하고, IBM 생태계 의존도가 높다. 같은 규모의 Lustre보다 최대 처리량은 낮을 수 있지만, 안정성과 관리 편의성에서 보상받는 구조다.
BeeGFS — 가볍게 시작하는 병렬 파일 시스템
Lustre는 무겁고 GPFS는 비싸다. BeeGFS는 그 사이를 노린다.
ThinkParQ(원래 Fraunhofer 연구소)에서 만든 병렬 파일 시스템으로, 설치가 간단하고 학습 곡선이 낮다. 중소 규모 HPC 클러스터에서 "빠르게 구축하고 바로 쓰고 싶다"면 BeeGFS가 선택지다.
커뮤니티 에디션은 무료고, 엔터프라이즈 에디션에서 HA, 미러링 같은 기능이 추가된다. 대학교 연구실이나 중소 규모 AI 클러스터에서 많이 보인다.
단점은 엔터프라이즈 기능의 부족이다. 커뮤니티 에디션에는 HA(고가용성)가 없다. 메타데이터 서버가 죽으면 파일시스템 전체가 멈춘다. 엔터프라이즈 에디션에서 HA를 지원하지만, Lustre나 GPFS 대비 검증 이력이 짧다. 벤더(ThinkParQ)의 규모도 IBM이나 오픈소스 커뮤니티에 비해 작아서, 장기적인 기술 지원 연속성이 리스크로 작용할 수 있다. 스냅샷, 쿼터 같은 운영 편의 기능도 Lustre/GPFS 대비 제한적이다.
Hadoop HDFS — 빅데이터 시대의 분산 스토리지
HDFS는 병렬 파일 시스템과는 설계 철학이 다르다. 같은 "분산 저장"이지만 접근 방식이 근본적으로 다르다.
┌─────────────────────────────────────────────┐
│ HDFS 아키텍처 │
│ │
│ ┌───────────────┐ │
│ │ NameNode │ ← 메타데이터 │
│ │ (파일→블록 │ (어떤 파일이 │
│ │ 매핑 정보) │ 어디 있는지) │
│ └───────┬───────┘ │
│ │ │
│ ┌────────────┼────────────┐ │
│ ▼ ▼ ▼ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │DataNode│ │DataNode│ │DataNode│ │
│ │ blk_01 │ │ blk_01 │ │ blk_02 │ │
│ │ blk_02 │ │ blk_03 │ │ blk_01 │ │
│ │ blk_03 │ │ blk_02 │ │ blk_03 │ │
│ └────────┘ └────────┘ └────────┘ │
│ │
│ 기본 3-replica: 각 블록이 3개의 DataNode에 │
│ 복제된다. 하나가 죽어도 데이터는 살아있다. │
└─────────────────────────────────────────────┘HDFS의 핵심 특징을 정리하면 이렇다.
┌─────────────────────────────────────────────────────────┐
│ HDFS vs 병렬 파일 시스템 차이 │
├────────────────┬──────────────────┬─────────────────────┤
│ │ HDFS │ Lustre/GPFS │
├────────────────┼──────────────────┼─────────────────────┤
│ POSIX 호환 │ X (자체 API) │ O (마운트 가능) │
│ 쓰기 모델 │ Write-Once │ 수정 가능 │
│ │ (append만 가능) │ │
│ 블록 크기 │ 128MB (기본) │ 1~4MB (보통) │
│ 데이터 보호 │ 3-replica 기본 │ RAID + 복제 │
│ 설계 목적 │ 배치 처리 최적화│ 범용 고성능 IO │
│ 데이터 로컬리티│ 핵심 (연산을 │ 해당 없음 │
│ │ 데이터 곁으로) │ │
└────────────────┴──────────────────┴─────────────────────┘HDFS가 POSIX 호환이 아니라는 건 중요한 차이다. 일반적인 ls, cat, cp 명령으로 접근할 수 없고, hdfs dfs -ls, hdfs dfs -cat 같은 전용 명령을 써야 한다. 기존 애플리케이션을 그대로 올릴 수 없다는 뜻이다.
블록 크기가 128MB인 것도 특이하다. 일반 파일시스템의 블록이 4KB인 걸 생각하면 엄청나게 크다. 이건 HDFS가 "소수의 큰 파일을 순차적으로 읽는" 배치 처리에 최적화되어 있기 때문이다. 작은 파일 수만 개를 저장하면 NameNode 메모리가 터진다. HDFS에서 작은 파일 문제(Small File Problem)는 유명한 골치거리다.
HDFS의 현재 위상은 솔직히 내리막이다. 클라우드 환경에서는 S3가 HDFS를 대체하는 추세다. Spark도 S3에서 직접 읽을 수 있고, 데이터 로컬리티 없이도 네트워크 속도가 충분히 빨라졌다. 온프레미스에서 Hadoop을 신규 구축하는 곳은 점점 줄어들고 있다.
Ceph와 MinIO — 분산 스토리지의 다른 얼굴
같은 "분산"이라도 Ceph와 MinIO는 HDFS나 Lustre와 목적이 다르다.
┌──────────────────────────────────────────────────────┐
│ 분산 스토리지 포지셔닝 │
│ │
│ ← HPC/AI 처리량 최적화 범용 분산 → │
│ │
│ Lustre GPFS BeeGFS Ceph MinIO │
│ ├─────────┤ │ ├─────┤ ├───┤ │
│ 병렬 파일 시스템 블록+파일 S3 호환 │
│ (POSIX, 고성능 IO) +오브젝트 오브젝트 │
│ 통합 전문 │
│ │
│ HDFS │
│ ├────┤ │
│ Hadoop 에코시스템 전용 │
└──────────────────────────────────────────────────────┘Ceph는 CRUSH 알고리즘으로 데이터 배치를 결정한다. 중앙 메타데이터 서버 없이 알고리즘으로 "이 데이터는 어디에 저장해야 하는지"를 계산한다. 블록(RBD), 파일(CephFS), 오브젝트(RGW)를 하나의 클러스터에서 다 제공한다. OpenStack, Kubernetes 환경에서 많이 쓰인다. 하지만 운영 난이도가 높다. 클러스터 확장/축소 시 데이터 리밸런싱이 발생하면서 성능이 급락할 수 있고, 성능 튜닝에 필요한 파라미터가 수백 개에 달한다. 소규모(노드 3~5대)에서는 오버헤드 대비 효율이 떨어지고, 최소 10대 이상의 노드에서 진가를 발휘한다. 장애 시 자가 복구(self-healing)가 장점이지만, 복구 중 IO 성능 저하가 심할 수 있다.
MinIO는 S3 호환에 올인한 경량 오브젝트 스토리지다. 설치가 간단하고(바이너리 하나), Go로 만들어져서 가볍다. 온프레미스에서 S3 API가 필요하면 MinIO가 가장 빠른 선택지다. 단점은 오브젝트 스토리지만 된다는 거다. 블록이나 POSIX 파일 접근이 필요한 워크로드에는 쓸 수 없다. 대규모 환경에서 메타데이터 성능 한계가 보고되기도 하고, 엔터프라이즈 기능(스냅샷, 복제, 티어링)은 상용 라이선스에서만 제공된다.
GPU 클러스터 시대의 스토리지
AI 학습 워크로드에서 병렬 파일 시스템이 다시 주목받고 있다. 이유는 단순하다.
GPU 서버 1 ──┐ ┌── 학습 데이터셋
GPU 서버 2 ──┤ │ (수TB ~ 수PB)
GPU 서버 3 ──┼── 동시에 읽음 ────►│
... │ │ 이미지 수억 장
GPU 서버 N ──┘ │ 텍스트 수TB
(수백~수천 GPU) └── 전부 빠르게 읽어야 함
NAS 한 대로는 감당 불가.
병렬 파일 시스템이 필요한 이유다.NVIDIA GPUDirect Storage는 GPU 메모리와 스토리지 사이의 데이터 전송에서 CPU를 우회한다. 이걸 지원하는 병렬 파일 시스템(Lustre, GPFS, WekaFS)을 쓰면 데이터 로딩 병목을 크게 줄일 수 있다.
WekaFS는 비교적 최근에 등장한 AI 특화 파일 시스템이다. NVMe 위에서 동작하도록 설계됐고, 메타데이터 성능이 Lustre보다 좋다. AI 학습에서 "랜덤한 작은 파일(이미지)을 대량으로 빠르게 읽는" 패턴에 강하다. 다만 아직 Lustre/GPFS만큼 검증된 역사는 없다.
┌─────────────────────────────────────────────────────────┐
│ 병렬/분산 파일 시스템 종합 비교 │
├────────────┬────────┬──────────┬────────┬───────┬───────┤
│ │ Lustre │ GPFS │ BeeGFS │ HDFS │ Ceph │
├────────────┼────────┼──────────┼────────┼───────┼───────┤
│ 설계 목적 │ HPC │ 엔터프 │ 경량 │ 빅 │ 범용 │
│ │ 처리량 │ 라이즈 │ HPC │ 데이터│ 분산 │
├────────────┼────────┼──────────┼────────┼───────┼───────┤
│ POSIX │ O │ O │ O │ X │ O │
│ 호환 │ │ │ │ │(CephFS)│
├────────────┼────────┼──────────┼────────┼───────┼───────┤
│ 메타데이터 │ MDS │ 분산 │ 분리 │ Name │ CRUSH │
│ 관리 │ 분리 │ (대칭) │ (경량) │ Node │ 알고리│
├────────────┼────────┼──────────┼────────┼───────┼───────┤
│ 라이선스 │ 오픈 │ 상용 │ 커뮤/ │ 오픈 │ 오픈 │
│ │ 소스 │ │ 상용 │ 소스 │ 소스 │
├────────────┼────────┼──────────┼────────┼───────┼───────┤
│ 운영 난이도│ 높음 │ 중간 │ 낮음 │ 중간 │ 높음 │
├────────────┼────────┼──────────┼────────┼───────┼───────┤
│ AI/GPU │ O │ O │ △ │ X │ △ │
│ 워크로드 │(GPUDi- │(GPUDi- │ │ │ │
│ 적합성 │ rect) │ rect) │ │ │ │
└────────────┴────────┴──────────┴────────┴───────┴───────┘대부분의 시스템 엔지니어가 일상적으로 다루는 건 2편에서 다룬 SAN/NAS다. 하지만 AI 인프라가 확산되면서 병렬 파일 시스템을 알아야 하는 상황이 늘어나고 있다. "GPU 서버 앞에 스토리지를 뭘로 붙이지?"라는 질문에 답하려면, 이 영역을 최소한 개념 수준에서는 알아야 한다.
다음 편에서는 프로토콜을 깊이 파본다. FC, iSCSI, NFS, SMB, S3. 이름만 아는 것과 동작 원리를 아는 건 장애가 터졌을 때 차이가 크다.
이 글이 어떠셨나요?
관련 포스트
2. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
DAS, NAS, SAN, Object Storage의 구조와 차이를 아스키 도표와 함께 정리한다. 어떤 워크로드에 어떤 방식을 선택하는가의 판단 기준과 벤더별 제품 포지셔닝까지.
2026. 04. 06. 오후 10:00Infrastructure1. 스토리지, 왜 어렵고 왜 중요한가
서버는 죽어도 살리면 되지만 스토리지는 잃으면 끝이다. 10년차 시스템 엔지니어가 스토리지가 어렵고 중요한 이유, 스토리지 담당자의 실제 업무, 기술의 진화 흐름을 현장 경험 기반으로 풀어본다.
2026. 03. 30. 오후 10:00Infrastructure시스템 엔지니어를 위한 NVIDIA 서버 GPU 세대별 가이드 — Tesla에서 Rubin까지, 꼭 알아야 할 개념들
NVIDIA 서버 GPU의 역사를 세대별로 따라가며, 각 세대에서 등장한 핵심 개념(CUDA, Tensor Core, NVLink, MIG, Transformer Engine, HBM)이 왜 중요하고 시스템 엔지니어에게 어떤 의미가 있는지를 정리한 글.
2026. 04. 04. 오후 01:20뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.