Skip to content
Published on

WEKA 고성능 스토리지 완전 가이드 2025: AI/HPC를 위한 병렬 파일시스템

Authors

목차

1. AI/HPC에 고성능 스토리지가 필요한 이유

1.1 GPU 활용률 문제

현대 AI 훈련에서 가장 비싼 자원은 GPU이다. NVIDIA H100 한 장의 가격이 3만 달러를 넘는 상황에서, GPU가 데이터를 기다리며 유휴 상태에 놓이는 것은 막대한 비용 낭비이다.

일반적인 AI 훈련 파이프라인:

[스토리지] --읽기--> [CPU: 전처리] --전송--> [GPU: 훈련]
    ^                    ^                    ^
    |                    |                    |
  병목 1:              병목 2:              실제 연산:
  I/O 대기            데이터 변환           GPU 활용
  (30-50% 시간)       (10-20% 시간)        (30-60% 시간)

현실적인 GPU 활용률:

시나리오GPU 활용률주요 병목
NFS + HDD 스토리지20-30%스토리지 I/O
NFS + SSD 스토리지40-50%네트워크, 메타데이터
Lustre 병렬 파일시스템60-70%소규모 파일 성능
WEKA + NVMe80-95%모델 복잡도에 따라
WEKA + GDS85-98%GPU 컴퓨트 바운드

1.2 AI 스토리지 요구사항

훈련 데이터 특성:

  • 이미지 분류: 수백만 개의 작은 파일 (JPEG, 10-500KB)
  • 자연어 처리: 대용량 토큰화된 데이터셋 (수 TB)
  • 자율주행: 비디오/LiDAR 센서 데이터 (수 PB)
  • 유전체학: 수십억 개의 짧은 시퀀스 리드

스토리지에 요구되는 성능:

요구사항설명목표
처리량 (Throughput)대용량 순차 읽기/쓰기100+ GB/s
IOPS소규모 랜덤 I/O수백만 IOPS
레이턴시첫 바이트 응답 시간200us 미만
메타데이터 성능파일 목록, stat 호출초당 수십만 ops
동시성수천 GPU의 병렬 접근선형 스케일링

1.3 전통적 스토리지의 한계

NFS (Network File System) 한계:
- 단일 서버 병목 (scale-up만 가능)
- 메타데이터 성능 제한
- 소규모 파일 I/O 비효율
- 수백 클라이언트 이상 스케일링 어려움

SAN/블록 스토리지 한계:
- 공유 파일시스템이 아님 (단일 마운트)
- 관리 복잡성
- 비용 높음

일반 분산 스토리지 한계:
- 레이턴시가 높음 (Ceph: 1-5ms)
- AI 워크로드 최적화 부족
- GPU Direct Storage 미지원

2. 병렬 파일시스템 개요

2.1 병렬 파일시스템이란?

병렬 파일시스템은 데이터를 여러 스토리지 노드에 분산(스트라이핑)하여 동시에 읽기/쓰기를 수행하는 파일시스템이다.

일반 NFS:
Client -> [NFS Server] -> [Disk]
                          (단일 경로)

병렬 파일시스템:
Client -> [Node 1] -> [Disk 1]  (동시 접근)
       -> [Node 2] -> [Disk 2]  (동시 접근)
       -> [Node 3] -> [Disk 3]  (동시 접근)
       -> [Node N] -> [Disk N]  (동시 접근)

  처리량 = 노드 수 x 노드당 처리량

2.2 주요 병렬 파일시스템 비교

항목WEKALustreGPFS (Spectrum Scale)BeeGFSCephFS
아키텍처소프트웨어 정의커널 모듈커널 모듈유저스페이스유저스페이스
메타데이터분산MDS 서버분산분산MDS 데몬
NVMe 최적화네이티브 (DPDK)제한적양호제한적제한적
POSIX 호환완전완전완전완전거의 완전
GPU Direct지원 (GDS)미지원제한적미지원미지원
소규모 파일 성능매우 우수보통양호양호보통
클라우드 통합AWS/Azure/GCP제한적제한적제한적양호
자동 티어링S3/Blob/GCSHSM정책 기반BeeOND미지원
설치 난이도쉬움어려움어려움중간중간
인라인 중복제거지원미지원미지원미지원미지원
인라인 압축지원미지원지원미지원지원
라이선스상용오픈소스 (GPL)상용오픈소스오픈소스
주요 사용처AI/HPC/금융HPC/연구소엔터프라이즈/HPCHPC/연구소범용
최대 처리량2+ TB/s1+ TB/s1+ TB/s500+ GB/s200+ GB/s

2.3 WEKA를 선택하는 이유

핵심 차별점:

  1. NVMe 퍼스트 설계: 커널 바이패스(DPDK)로 NVMe의 성능을 100% 활용
  2. 소규모 파일 성능: AI 훈련에 필수적인 수백만 개 소규모 파일 처리에 탁월
  3. GPU Direct Storage: CPU 바이패스로 GPU-스토리지 직접 데이터 전송
  4. 자동 티어링: NVMe에서 S3로 자동 데이터 이동 (핫/콜드 분리)
  5. 클라우드 네이티브: AWS, Azure, GCP에서 네이티브 배포 가능
  6. 간편한 관리: GUI/CLI로 쉬운 설치와 운영

3. WEKA 아키텍처 심층 분석

3.1 소프트웨어 정의 아키텍처

WEKA는 범용 x86 서버 위에서 실행되는 소프트웨어 정의 스토리지이다.

+------------------------------------------------------------+
|                    WEKA Cluster                              |
|                                                              |
|  +------------------+  +------------------+                  |
|  | Backend Server 1 |  | Backend Server 2 |  ...            |
|  | +----+ +----+    |  | +----+ +----+    |                 |
|  | |NVMe| |NVMe|    |  | |NVMe| |NVMe|    |                 |
|  | +----+ +----+    |  | +----+ +----+    |                 |
|  | DPDK Networking   |  | DPDK Networking   |                |
|  +------------------+  +------------------+                  |
|                                                              |
|  Distributed Metadata (모든 노드에 분산)                       |
|  Erasure Coding Engine (N+2 or N+4)                          |
|  Inline Dedup + Compression                                  |
|                                                              |
|  +------------------+  +------------------+                  |
|  | Frontend Client 1|  | Frontend Client 2|  ...            |
|  | (Compute Node)   |  | (Compute Node)   |                 |
|  | GPU GPU GPU GPU   |  | GPU GPU GPU GPU   |                |
|  +------------------+  +------------------+                  |
+------------------------------------------------------------+

3.2 WekaFS 핵심 특징

분산 메타데이터:

전통적인 병렬 파일시스템(Lustre, GPFS)은 별도의 메타데이터 서버(MDS)를 사용하지만, WEKA는 메타데이터를 모든 노드에 분산한다. 이는 메타데이터 병목을 제거하고 수백만 파일의 ls나 stat 호출 성능을 극대화한다.

이레이저 코딩:

복제 방식 (3중 복제):
  Data -> Copy1, Copy2, Copy3
  오버헤드: 200% (1TB 데이터 = 3TB 소비)

이레이저 코딩 (N+2):
  Data -> Stripe1, Stripe2, ..., StripeN, Parity1, Parity2
  오버헤드: ~29% (N=7일 때, 7+2=9, 2/7=28.6%)
  최대 2개 노드 동시 장애 허용

이레이저 코딩 (N+4):
  오버헤드: ~57% (N=7일 때, 7+4=11, 4/7=57.1%)
  최대 4개 노드 동시 장애 허용

NVMe 퍼스트 설계 (커널 바이패스):

전통적 스토리지 I/O 경로:
Application -> VFS -> Filesystem -> Block Layer -> Device Driver -> NVMe
  (수많은 커널 컨텍스트 스위칭, 인터럽트, 복사)

WEKA I/O 경로 (DPDK):
Application -> WEKA Client (userspace) -> DPDK -> NVMe
  (커널 바이패스, 폴링 모드, 제로 카피)

인라인 중복제거와 압축:

데이터가 기록되는 시점에 실시간으로 중복 데이터를 제거하고 압축한다. AI 워크로드에서는 유사한 이미지나 데이터셋 간 중복이 많아 20-50%의 공간 절약이 가능하다.

Snap-to-Object (S3 티어링):

+------------------------------------------------------------+
|  Hot Tier (NVMe)        Warm Tier         Cold Tier         |
|  +-----------------+  +-----------+  +------------------+   |
|  | Active Training |  | Recent    |  | S3 / Azure Blob  |   |
|  | Data            |  | Experiments|  | / GCS            |   |
|  | (Fast Access)   |  | (SSD)     |  | (Archived)       |   |
|  +-----------------+  +-----------+  +------------------+   |
|         ^                  ^                   ^            |
|         |                  |                   |            |
|    자동 티어링 정책: 접근 시간, 크기, 나이 기반                |
+------------------------------------------------------------+

4. WEKA 구성요소

4.1 백엔드 서버 (스토리지 노드)

백엔드 서버는 실제 데이터를 저장하는 노드이다.

# 백엔드 서버 상태 확인
weka cluster host
weka status

# 노드 상세 정보
weka cluster host -v

주요 역할:

  • NVMe 디스크 관리
  • 데이터 스트라이핑 및 이레이저 코딩
  • 메타데이터 처리
  • 클라이언트 요청 서비스

4.2 프론트엔드 클라이언트 (컴퓨트 노드)

컴퓨트 노드는 GPU가 장착된 서버로, WEKA 클라이언트를 통해 파일시스템에 접근한다.

# WEKA 클라이언트 마운트
mount -t wekafs backend-host/fs-name /mnt/weka

# 또는 POSIX 마운트
weka local mount fs-name /mnt/weka

# 마운트 상태 확인
weka local status

클라이언트 모드:

모드설명성능사용 사례
DPDK (Stateless)커널 바이패스, 전용 NIC최고AI 훈련, HPC
UDP표준 네트워크 스택양호일반 워크로드
NFS/SMB프로토콜 게이트웨이보통레거시 애플리케이션

4.3 관리 클러스터

# WEKA CLI 기본 명령어
weka status                        # 클러스터 상태
weka cluster host                  # 호스트 목록
weka fs                            # 파일시스템 목록
weka fs group                      # 파일시스템 그룹
weka alerts                        # 알림 확인

# 파일시스템 생성
weka fs create myfs default 10TiB

# 파일시스템 크기 조정
weka fs update myfs --total-capacity 20TiB

# 스냅샷
weka fs snapshot create myfs snap-before-training
weka fs snapshot list myfs
weka fs snapshot restore myfs snap-before-training

4.4 조직(Organization)과 파일시스템 그룹

WEKA는 멀티테넌시를 위해 조직(Organization) 개념을 제공한다.

# 조직 생성
weka org create research-team

# 파일시스템 그룹 (용도별 분류)
weka fs group create ai-training --org research-team
weka fs group create inference --org research-team

# 할당량(Quota) 설정
weka fs quota set myfs --hard-limit 50TiB --path /projects/team-a

5. GPU Direct Storage (GDS) 연동

5.1 NVIDIA Magnum IO 아키텍처

GPU Direct Storage는 NVIDIA Magnum IO 에코시스템의 일부로, GPU 메모리와 스토리지 간 직접 데이터 전송을 가능하게 한다.

기존 I/O 경로:
Storage -> CPU Memory (bounce buffer) -> GPU Memory
           ^^^^^^^^^^^^^^^^^^^^^^^^^
           CPU 개입 필요, 추가 메모리 복사

GDS I/O 경로:
Storage -> GPU Memory (direct DMA)
           ^^^^^^^^^^^^^^^^^^^^^^^^
           CPU 바이패스, 제로 카피

5.2 cuFile API

// GDS를 사용한 파일 읽기 예시 (CUDA C)
#include <cufile.h>

// GPU 메모리 할당
void* gpu_buffer;
cudaMalloc(&gpu_buffer, file_size);

// cuFile 핸들 열기
CUfileDescr_t cf_desc;
CUfileHandle_t cf_handle;
cf_desc.type = CU_FILE_HANDLE_TYPE_OPAQUE_FD;

int fd = open("/mnt/weka/training_data.bin", O_RDONLY | O_DIRECT);
cf_desc.handle.fd = fd;

cuFileHandleRegister(&cf_handle, &cf_desc);

// GPU 버퍼 등록
cuFileBufRegister(gpu_buffer, file_size, 0);

// 스토리지에서 GPU로 직접 읽기
cuFileRead(cf_handle, gpu_buffer, file_size, 0, 0);
// CPU를 거치지 않고 스토리지에서 GPU 메모리로 직접 DMA 전송

5.3 GDS 성능 향상

워크로드기존 (bounce buffer)GDS 적용향상률
대용량 순차 읽기12 GB/s/GPU25 GB/s/GPU2.1x
소규모 랜덤 읽기500K IOPS/GPU1.2M IOPS/GPU2.4x
체크포인트 쓰기8 GB/s/GPU20 GB/s/GPU2.5x
CPU 사용률30-50%5-10%4-6x 절감

5.4 WEKA에서 GDS 설정

# 1. NVIDIA 드라이버 및 CUDA 설치 확인
nvidia-smi
nvcc --version

# 2. GDS 패키지 설치
# NVIDIA GDS와 WEKA 클라이언트가 모두 필요

# 3. WEKA 마운트 시 GDS 활성화
mount -t wekafs -o gds backend-host/fs-name /mnt/weka

# 4. GDS 상태 확인
/usr/local/cuda/gds/tools/gds_stats

# 5. 성능 테스트
/usr/local/cuda/gds/tools/cufile_sample_001

6. AI/ML 워크로드 최적화

6.1 훈련 데이터 파이프라인

PyTorch DataLoader 최적화:

import torch
from torch.utils.data import DataLoader, Dataset

class WEKAImageDataset(Dataset):
    def __init__(self, root_dir="/mnt/weka/imagenet"):
        self.root_dir = root_dir
        self.file_list = self._build_file_list()

    def _build_file_list(self):
        # WEKA의 빠른 메타데이터 처리로
        # 수백만 파일 목록을 수초 내에 구축
        import os
        files = []
        for root, dirs, fnames in os.walk(self.root_dir):
            for fname in fnames:
                if fname.endswith(('.jpg', '.jpeg', '.png')):
                    files.append(os.path.join(root, fname))
        return files

    def __len__(self):
        return len(self.file_list)

    def __getitem__(self, idx):
        img_path = self.file_list[idx]
        # WEKA의 낮은 레이턴시로 빠른 파일 접근
        image = read_image(img_path)
        return image

# 최적화된 DataLoader 설정
dataloader = DataLoader(
    WEKAImageDataset(),
    batch_size=256,
    num_workers=16,        # WEKA가 높은 동시성 지원
    pin_memory=True,       # GPU 전송 최적화
    prefetch_factor=4,     # 미리 읽기
    persistent_workers=True # 워커 재활용
)

NVIDIA DALI 파이프라인:

from nvidia.dali import pipeline_def
import nvidia.dali.fn as fn
import nvidia.dali.types as types

@pipeline_def(batch_size=256, num_threads=12, device_id=0)
def training_pipeline():
    # WEKA에서 직접 읽기 (GDS 활용 가능)
    jpegs, labels = fn.readers.file(
        file_root="/mnt/weka/imagenet/train",
        random_shuffle=True,
        name="Reader"
    )
    # GPU에서 디코딩 (CPU 바이패스)
    images = fn.decoders.image_random_crop(
        jpegs, device="mixed",
        output_type=types.RGB
    )
    images = fn.resize(images, device="gpu", size=224)
    images = fn.crop_mirror_normalize(
        images, device="gpu",
        dtype=types.FLOAT,
        mean=[0.485 * 255, 0.456 * 255, 0.406 * 255],
        std=[0.229 * 255, 0.224 * 255, 0.225 * 255]
    )
    return images, labels

6.2 체크포인트 스토리지

AI 모델 훈련 중 주기적으로 모델 상태를 저장하는 체크포인팅은 스토리지 성능에 직접적인 영향을 받는다.

import torch

# 체크포인트 저장 (WEKA의 높은 쓰기 처리량 활용)
def save_checkpoint(model, optimizer, epoch, path="/mnt/weka/checkpoints"):
    checkpoint = {
        'epoch': epoch,
        'model_state_dict': model.state_dict(),
        'optimizer_state_dict': optimizer.state_dict(),
    }
    # LLM 모델의 경우 체크포인트 크기: 수 GB ~ 수십 GB
    torch.save(checkpoint, f"{path}/checkpoint_epoch_{epoch}.pt")

# 체크포인트 복원
def load_checkpoint(path, model, optimizer):
    checkpoint = torch.load(path)
    model.load_state_dict(checkpoint['model_state_dict'])
    optimizer.load_state_dict(checkpoint['optimizer_state_dict'])
    return checkpoint['epoch']

체크포인트 성능 비교:

스토리지10GB 체크포인트 저장10GB 체크포인트 로드
NFS (1GbE)80초80초
NFS (10GbE)8초8초
Lustre3초2초
WEKA (NVMe)0.5초0.4초
WEKA + GDS0.3초0.25초

6.3 소규모 파일 성능

이미지 분류 훈련에서는 수백만 개의 작은 JPEG 파일을 읽어야 한다.

ImageNet 데이터셋 예시:
- 총 파일 수:1,400만 개
- 평균 파일 크기: ~100KB
- 에포크당 전체 데이터 읽기 필요

파일 시스템별 ImageNet 에포크 시간 (8x A100):
- NFS:    45 (I/O 바운드)
- Lustre: 15 (메타데이터 병목)
- WEKA:   3  (GPU 바운드)

6.4 멀티 GPU 멀티 노드 훈련

분산 훈련 아키텍처 (NCCL + WEKA):

+----------+  +----------+  +----------+  +----------+
| Node 1   |  | Node 2   |  | Node 3   |  | Node 4   |
| 8x H100  |  | 8x H100  |  | 8x H100  |  | 8x H100  |
+-----+----+  +-----+----+  +-----+----+  +-----+----+
      |              |              |              |
      +-------+------+------+------+------+-------+
              |      NCCL All-Reduce       |
              +----------------------------+
              |
      +-------+-------+
      |  WEKA Cluster  |
      | (공유 데이터)    |
      +----------------+

각 노드가 WEKA에서 독립적으로 데이터를 읽음
NCCL이 그래디언트 동기화 담당
WEKA32개 노드까지 선형 스케일링 제공

6.5 추론 모델 서빙

추론 워크로드 특성:
- 모델 로딩: 큰 파일 1읽기 (GB ~ 수십 GB)
- 추론 입력: 작은 파일 반복 읽기 (이미지, 텍스트)
- 레이턴시 민감: 실시간 응답 필요 (수 ms)

WEKA가 추론에 적합한 이유:
- 모델 파일의 빠른 로딩 (NVMe 캐싱)
- 낮은 첫 바이트 레이턴시 (200us 미만)
- 여러 추론 서버의 동시 모델 접근
- 모델 버전 관리 (스냅샷 활용)

7. 계층형 스토리지 아키텍처

7.1 3계층 아키텍처

+------------------------------------------------------------+
|              WEKA Tiered Storage                             |
|                                                              |
|  Tier 1: Hot (NVMe)                                         |
|  +------------------------------------------------------+   |
|  | 활성 훈련 데이터, 현재 실험 데이터셋                        |   |
|  | 레이턴시: 0.1ms 미만                                     |   |
|  | 처리량: 100+ GB/s                                       |   |
|  +------------------------------------------------------+   |
|                      |                                       |
|           자동 티어링 (접근 패턴 기반)                          |
|                      |                                       |
|  Tier 2: Warm (SSD, optional)                                |
|  +------------------------------------------------------+   |
|  | 최근 실험 데이터, 자주 접근하는 아카이브                      |   |
|  | 레이턴시: 0.5ms 미만                                     |   |
|  +------------------------------------------------------+   |
|                      |                                       |
|           Snap-to-Object 티어링                               |
|                      |                                       |
|  Tier 3: Cold (Object Storage)                               |
|  +------------------------------------------------------+   |
|  | S3 / Azure Blob / GCS                                   |   |
|  | 아카이브된 데이터셋, 오래된 체크포인트                        |   |
|  | 레이턴시: 수십 ms                                        |   |
|  | 비용: NVMe 대비 1/10 ~ 1/50                             |   |
|  +------------------------------------------------------+   |
+------------------------------------------------------------+

7.2 자동 티어링 정책

# 티어링 정책 설정
weka fs tier s3 add myfs \
  --obs-name my-s3-bucket \
  --obs-type s3 \
  --hostname s3.amazonaws.com \
  --port 443 \
  --bucket weka-tier-data \
  --access-key-id AKIAIOSFODNN7EXAMPLE \
  --secret-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# 티어링 정책: 7일 미접근 데이터를 S3로 이동
weka fs tier s3 update myfs --tiering-cue 7d

# 수동 티어링 (특정 경로)
weka fs tier fetch myfs /datasets/imagenet  # S3에서 NVMe로 복원
weka fs tier release myfs /datasets/old_experiment  # NVMe에서 S3로 이동

7.3 비용 최적화

스토리지 티어비용 (GB/월, 대략)1PB 월 비용
NVMe (로컬)약 0.15 달러약 15만 달러
SSD (로컬)약 0.08 달러약 8만 달러
S3 Standard약 0.023 달러약 2.3만 달러
S3 Glacier약 0.004 달러약 4천 달러

자동 티어링으로 80% 비용 절감 사례:

전체 데이터: 5PB
- Hot (NVMe): 500TB (활성 훈련) =7.5만 달러/- Cold (S3):  4.5PB (아카이브)  =10.3만 달러/- 합계:17.8만 달러/
전부 NVMe에 보관 시:75만 달러/절감률:76%

8. 클라우드 배포

8.1 WEKA on AWS

AWS 배포 아키텍처:

+------------------------------------------------------------+
|  VPC                                                        |
|  +------------------+  +------------------+                  |
|  | WEKA Backend     |  | WEKA Backend     |  ...            |
|  | i3en.24xlarge    |  | i3en.24xlarge    |                  |
|  | (8x 7.5TB NVMe) |  | (8x 7.5TB NVMe) |                  |
|  | 100 Gbps ENA     |  | 100 Gbps ENA     |                  |
|  +------------------+  +------------------+                  |
|                                                              |
|  +------------------+  +------------------+                  |
|  | Compute Client   |  | Compute Client   |  ...            |
|  | p5.48xlarge      |  | p5.48xlarge      |                  |
|  | (8x H100 GPU)    |  | (8x H100 GPU)    |                  |
|  | 3200 Gbps EFA    |  | 3200 Gbps EFA    |                  |
|  +------------------+  +------------------+                  |
|                                                              |
|  S3 Bucket (Cold Tier)                                       |
+------------------------------------------------------------+
# AWS CloudFormation으로 WEKA 배포
aws cloudformation create-stack \
  --stack-name weka-cluster \
  --template-url https://weka-deploy-templates.s3.amazonaws.com/weka-latest.yaml \
  --parameters \
    ParameterKey=ClusterSize,ParameterValue=6 \
    ParameterKey=InstanceType,ParameterValue=i3en.24xlarge \
    ParameterKey=VpcId,ParameterValue=vpc-xxxxx

8.2 하이브리드 클라우드

온프레미스 + 클라우드 하이브리드:

[온프레미스 WEKA 클러스터]
  - 상시 운영 워크로드
  - 민감한 데이터
  - NVMe Hot Tier
         |
    S3 티어링 (자동)
         |
[AWS S3]
         |
    클라우드 버스트 (필요 시)
         |
[AWS WEKA 클러스터 (임시)]
  - 대규모 훈련 작업
  - 온디맨드 GPU (p5 인스턴스)
  - 작업 완료 후 클러스터 해제

8.3 클라우드 버스트 워크플로우

# 1. 온프레미스에서 데이터셋을 S3로 티어링
weka fs tier release myfs /datasets/large-training-set

# 2. AWS에서 임시 WEKA 클러스터 생성
# (CloudFormation/Terraform)

# 3. S3 데이터를 AWS WEKA로 페치
weka fs tier fetch myfs /datasets/large-training-set

# 4. 훈련 실행
# (분산 훈련 작업)

# 5. 결과를 S3로 저장
weka fs tier release myfs /results/experiment-42

# 6. AWS 클러스터 해제 (비용 절감)

9. 설치 및 구성

9.1 하드웨어 요구사항

백엔드 서버 (최소 6대 권장):
  CPU: 최소 19코어 (WEKA 전용 16코어 + OS 3코어)
  RAM: 최소 72GB (WEKA 전용 31GB + OS)
  NVMe: 최소 1 (권장 4-8, 각 1TB+)
  네트워크: 25GbE 이상 (권장 100GbE)

프론트엔드 클라이언트:
  CPU: 최소 2코어 (WEKA 클라이언트용)
  RAM: 최소 4GB (WEKA 클라이언트용)
  네트워크: 25GbE 이상

네트워크 요구사항:
  - 전용 DPDK NIC (Mellanox ConnectX-5/6 권장)
  - Jumbo Frame (MTU 9000)
  - 로스리스 네트워크 (RoCE v2 또는 InfiniBand)

9.2 네트워크 구성

# DPDK NIC 설정 확인
dpdk-devbind.py --status

# Mellanox NIC 설정
mlnx_tune -p THROUGHPUT

# MTU 설정
ip link set dev enp3s0f0 mtu 9000

9.3 클러스터 설치

# 1. WEKA 패키지 다운로드 및 설치
curl -o weka.tar https://get.weka.io/dist/v4.3/weka-4.3.tar
tar xf weka.tar
cd weka-4.3
./install.sh

# 2. 클러스터 생성
weka cluster create backend1 backend2 backend3 backend4 backend5 backend6

# 3. 드라이브 추가
weka cluster drive add --host backend1 /dev/nvme0n1 /dev/nvme1n1

# 4. 클러스터 시작
weka cluster start

# 5. 파일시스템 생성
weka fs create training-data default 100TiB

# 6. 클라이언트 마운트
mount -t wekafs backend1/training-data /mnt/weka

10. 성능 벤치마킹

10.1 FIO 벤치마크

# 순차 읽기 테스트
fio --name=seq-read \
  --directory=/mnt/weka/fio-test \
  --rw=read \
  --bs=1M \
  --numjobs=16 \
  --iodepth=32 \
  --size=10G \
  --direct=1

# 랜덤 읽기 IOPS 테스트
fio --name=rand-read \
  --directory=/mnt/weka/fio-test \
  --rw=randread \
  --bs=4K \
  --numjobs=32 \
  --iodepth=64 \
  --size=1G \
  --direct=1

# 혼합 워크로드 (70% 읽기 / 30% 쓰기)
fio --name=mixed \
  --directory=/mnt/weka/fio-test \
  --rw=randrw \
  --rwmixread=70 \
  --bs=64K \
  --numjobs=16 \
  --iodepth=32 \
  --size=5G \
  --direct=1

10.2 벤치마크 결과 (예시: 6노드 클러스터)

테스트WEKA (6노드)NFS (단일)Lustre (6노드)
순차 읽기80 GB/s1.2 GB/s30 GB/s
순차 쓰기50 GB/s1.0 GB/s20 GB/s
4K 랜덤 읽기6M IOPS50K IOPS800K IOPS
4K 랜덤 쓰기3M IOPS30K IOPS400K IOPS
메타데이터 ops2M ops/s20K ops/s100K ops/s
레이턴시 (4K read)0.15ms2ms0.5ms

10.3 MLPerf Storage 벤치마크

MLPerf Storage는 AI 훈련 워크로드에 특화된 스토리지 벤치마크이다.

# MLPerf Storage 벤치마크 실행
git clone https://github.com/mlcommons/storage_benchmark.git
cd storage_benchmark

# 구성 파일 설정
cat benchmark_config.yaml
# benchmark_config.yaml
benchmark:
  model: resnet50
  accelerator: h100
  num_accelerators: 8
  dataset_path: /mnt/weka/mlperf/imagenet
  results_dir: /mnt/weka/mlperf/results

11. 운영 및 모니터링

11.1 WEKA GUI 대시보드

WEKA는 웹 기반 GUI를 제공하여 클러스터 상태를 모니터링한다.

주요 대시보드 항목:
- 클러스터 건강 상태 (녹색/황색/적색)
- 용량 사용률 및 추세
- 처리량/IOPS 실시간 그래프
- 노드별 성능 분포
- 티어링 상태 (NVMe vs S3 사용량)
- 알림 히스토리

11.2 알림 및 상태 모니터링

# 알림 확인
weka alerts
weka alerts --severity critical

# 클러스터 상태
weka status
weka cluster host -v

# 성능 통계
weka stats --category ops
weka stats --category throughput
weka stats --category latency

# 용량 정보
weka fs --name training-data -v

11.3 용량 계획

# 현재 용량 사용량
weka fs --name training-data
# Total: 100 TiB, Used: 67 TiB, Available: 33 TiB

# 일별 증가량 추적
weka events --category capacity --start-time "7 days ago"

# 예상 고갈 시점 계산 (수동)
# 일평균 증가: 500GB
# 남은 용량: 33TB
# 예상 고갈: 약 66일

11.4 업그레이드 프로세스

# 롤링 업그레이드 (무중단)
# 1. 새 버전 다운로드
weka cluster update download --url https://get.weka.io/dist/v4.4/weka-4.4.tar

# 2. 업그레이드 시작 (노드별 순차 진행)
weka cluster update start

# 3. 진행 상태 확인
weka cluster update status

# 4. 완료 확인
weka status

11.5 일반적인 트러블슈팅

증상원인해결
마운트 실패네트워크 연결 문제DPDK NIC 상태 확인, MTU 확인
성능 저하디스크 장애 또는 네트워크 혼잡weka diags로 진단 실행
용량 부족티어링 미설정 또는 데이터 증가S3 티어링 설정 또는 디스크 추가
노드 다운하드웨어 장애이레이저 코딩으로 자동 복구, 노드 교체
높은 레이턴시클라이언트 과부하클라이언트 수 또는 I/O 깊이 조정

12. 사용 사례

12.1 LLM 훈련

대규모 언어 모델(LLM) 훈련은 수 PB의 텍스트 데이터를 수천 개의 GPU로 처리한다.

GPT-4 규모 훈련 예시:
- 훈련 데이터:13TB (토큰화된 텍스트)
- 체크포인트: 각 약 2TB (수천 개)
- GPU 클러스터: 10,000+ H100
- 스토리지 요구: 200+ GB/s 읽기 처리량

WEKA 구성:
- 12노드 x 8 NVMe = 약 600TB Hot Tier
- S3에 체크포인트 자동 아카이브
- GDSGPU 활용률 95% 이상 유지

12.2 자율주행

자율주행 데이터 규모:
- 차량당 일일 데이터:20TB (카메라, LiDAR, 레이더)
- 전체 데이터셋:PB ~ 수십 PB
- 훈련 주기: 지속적 (새 데이터 수집 + 재훈련)

WEKA의 역할:
- 수집된 센서 데이터의 고속 수집
- 라벨링/전처리 파이프라인 지원
- 모델 훈련 데이터 제공
- 시뮬레이션 결과 저장

12.3 생명과학

유전체학 워크로드:
- WGS (Whole Genome Sequencing): 샘플당 약 100GB
- 대규모 코호트: 수만 샘플 =PB
- 분석 파이프라인: 소규모 파일 수백만 개 생성

약물 발견:
- 분자 시뮬레이션: 높은 I/O 처리량 필요
- AI 기반 약물 스크리닝: GPU 집약적
- 데이터 공유: 여러 연구팀 동시 접근

12.4 금융 서비스

리스크 모델링:
- 대규모 몬테카를로 시뮬레이션
- 밀리초 단위 레이턴시 요구
- 장내/장외 거래 데이터 분석

WEKA 장점:
- 초저 레이턴시 (0.1ms 미만)
- 결정적 성능 (지터 최소)
- 규제 요건에 맞는 데이터 보존

12.5 미디어 및 엔터테인먼트

VFX 렌더링:
- 프레임당 수 GB의 텍스처/에셋
- 수백 대의 렌더 노드 동시 접근
- 높은 순차 읽기 처리량 필요

8K/16K 비디오 편집:
- 실시간 스트리밍: 프레임 드롭 없이 재생
- 다수의 편집자 동시 접근
- 대용량 프로젝트 파일 관리

13. 퀴즈

Q1. WEKA가 NVMe의 성능을 최대한 활용하기 위해 사용하는 핵심 기술은?

정답: DPDK (Data Plane Development Kit)를 이용한 커널 바이패스

WEKA는 DPDK를 사용하여 리눅스 커널의 I/O 스택을 완전히 우회한다. 전통적인 스토리지는 VFS에서 파일시스템, 블록 레이어, 디바이스 드라이버를 거치면서 컨텍스트 스위칭과 메모리 복사 오버헤드가 발생한다. DPDK는 유저 스페이스에서 NVMe를 직접 제어하여(폴링 모드, 제로 카피) NVMe의 마이크로초 단위 레이턴시를 실현한다.

Q2. GPU Direct Storage(GDS)가 해결하는 핵심 문제는?

정답: CPU를 거치는 불필요한 데이터 복사(bounce buffer)를 제거하여 GPU-스토리지 간 직접 DMA 전송을 실현

기존 방식에서는 스토리지의 데이터가 CPU 메모리에 먼저 복사(bounce buffer)된 후 GPU 메모리로 재복사되었다. GDS는 이 과정을 제거하고 스토리지에서 GPU 메모리로 직접 DMA 전송을 수행한다. 이로 인해 처리량이 2-3배 향상되고 CPU 사용률이 4-6배 절감된다.

Q3. WEKA의 이레이저 코딩(N+2)이 3중 복제 대비 가지는 장점은?

정답: 동일한 내결함성(2개 노드 장애 허용)을 제공하면서 스토리지 오버헤드를 약 200%에서 약 29%로 대폭 절감

3중 복제는 데이터 1카피 + 복제본 2카피로 200%의 오버헤드가 발생한다. N+2 이레이저 코딩(예: 7+2)은 7개의 데이터 스트라이프와 2개의 패리티 스트라이프를 사용하여 약 29%의 오버헤드만으로 동일하게 2개 노드 동시 장애를 허용한다.

Q4. WEKA의 Snap-to-Object 기능이 AI 팀에게 주는 가장 큰 이점은?

정답: 비용 최적화 - 자주 접근하지 않는 데이터를 자동으로 저비용 오브젝트 스토리지(S3)로 이동하여 NVMe 비용 대비 최대 90% 이상 절감

AI 팀은 활성 훈련에 사용하는 데이터(전체의 10-20%)만 고성능 NVMe 티어에 유지하고, 과거 실험 데이터나 아카이브 데이터셋은 S3로 자동 이동한다. 필요 시 다시 NVMe로 복원이 가능하므로 데이터 접근성은 유지하면서 비용을 크게 절감할 수 있다.

Q5. WEKA와 Lustre의 가장 큰 아키텍처 차이점은?

정답: 메타데이터 분산 방식 - WEKA는 모든 노드에 메타데이터를 분산하고, Lustre는 별도의 MDS(Metadata Server)를 사용

Lustre는 전용 MDS 서버에 메타데이터를 집중하므로, 수백만 개의 소규모 파일을 처리할 때 MDS가 병목이 된다. WEKA는 메타데이터를 모든 백엔드 노드에 분산하여 메타데이터 연산이 선형적으로 스케일링된다. 이 차이가 AI 워크로드(수백만 이미지 파일)에서 WEKA가 월등한 성능을 보이는 핵심 이유이다.


14. 참고 자료

  1. WEKA 공식 문서 - docs.weka.io
  2. WEKA 아키텍처 백서 - weka.io/resources/white-papers
  3. NVIDIA GPU Direct Storage - developer.nvidia.com/gpudirect-storage
  4. NVIDIA Magnum IO - developer.nvidia.com/magnum-io
  5. MLPerf Storage Benchmark - mlcommons.org/benchmarks/storage
  6. Lustre 공식 문서 - lustre.org/documentation
  7. IBM Spectrum Scale (GPFS) - ibm.com/docs/en/spectrum-scale
  8. BeeGFS 공식 문서 - beegfs.io/docs
  9. Ceph 공식 문서 - docs.ceph.com
  10. DPDK 문서 - doc.dpdk.org
  11. NVIDIA DALI - docs.nvidia.com/deeplearning/dali
  12. PyTorch DataLoader - pytorch.org/docs/stable/data.html
  13. WEKA on AWS - aws.amazon.com/marketplace/pp/prodview-weka
  14. FIO Benchmark - fio.readthedocs.io