AI Training Storage
AI가 뇌라면 스토리지는 기억 — 능력과 속도는 기억의 크기와 검색 속도에 달려 있다
핵심 개념
AI 컴퓨트 성능은 2년마다 약 3배 성장했지만 스토리지와 인터커넥트 성능 성장은 훨씬 완만했다. 그 격차가 AI 워크로드에서 GPU stall의 주요 원인이 되고, 곧바로 지출과 time-to-market에 반영된다.
AI 스토리지 설계는 두 개의 목표로 수렴한다.
- GPU 활용률 극대화 — I/O 대기로 GPU를 세우지 않기
- 연구 속도(research velocity) 극대화 — 리전 간 데이터 이동에 연구자 시간을 쓰지 않기
왜 pMax 레이턴시인가
수십만 GPU가 배치 단위로 학습하고 일정 step마다 서로 상태를 동기화한다. GPU 하나가 느리면 그 step 전체가, 결국 학습 전체가 느려진다. 데이터로더는 현재 배치를 처리하는 동안 다음 배치를 프리페치하므로, 스토리지 fetch 레이턴시가 예산 안에만 들어오면 stall이 없다. 튀는 순간이 몇 번 생기면 step completion time이 지연된다.
그래서 요구사항이 “평균 레이턴시가 낮다”가 아니라 “pMax까지 예측 가능하고 bounded하다” 가 된다.
AI가 뒤집은 4가지 설계 가정
| 축 | 전통 웹 워크로드 | AI 워크로드 |
|---|---|---|
| 성능/레이턴시 | 요구 완만, 메타데이터 조회 수백 ms도 허용 | pMax까지 bounded, flash 밀리초 접근이 전제 |
| 신뢰성/durability | 리전 장애까지 견디도록 글로벌 복제 기본값 | 매우 높은 가용성은 필요하지만 global-by-default는 더 이상 성립 안 함 |
| 비용 효율 | HDD 기반, byte당 비용 최적화 | IOPS 요구로 flash 필수. 스토리지 컴퓨트 비용은 GPU 대비 무시 가능 |
| 전력 효율 | 제약이 아니었음 | 데이터센터가 공간이 아닌 전력 제약. 스토리지에 쓴 1kW는 GPU에 못 쓴 1kW |
전력 효율은 AI 시대에 새로 생긴 제약이고, 아키텍처 결정(예: 데이터플레인 프록시 제거)을 직접 좌우한다.
레거시 오브젝트 스토리지가 AI-ready가 아니었던 이유
오랜 시간 SOA 방식으로 레이어 위에 레이어를 쌓으면서 각 레이어가 자기 메타데이터 스토어를 가졌다. getObject("/bucket/path") 하나가 namelayer → volumeslayer → containerlayer를 거치며 조회를 반복하고, 일부는 리전을 넘고, 합치면 수백 ms가 된다. 조회 하나만 느려도 끝난다. 글로벌 HDD 시대엔 이게 병목이 아니었지만 flash 밀리초 접근에는 showstopper다.
재설계 3원칙
- 통합 메타데이터 스키마 — 여러 레이어에 흩어진 메타데이터를 하나의 flat 스키마(Meta는 ZippyDB)로 붕괴시켜 경로→스토리지 주소 해석을 O(1) 로. step-function 개선
- 데이터플레인 프록시 제거 — fat client SDK가 스토리지 서버에서 클라이언트로 바이트를 직접 스트리밍. 전력 예산과 처리량/레이턴시를 동시에 잡는다
- 리전 배포 — 스택을 가볍게 만들어 모든 AI 리전에 GPU와 코로케이트해 배포
스파이크와 핫스팟
데이터·체크포인트 로딩 시 수백 GPU가 동시에 접근하고, 모델 가중치 같은 데이터 부분집합은 “hot”하며, GPU 재시작 같은 이벤트가 날카로운 트래픽 스파이크를 만든다.
- 분산 데이터 캐시 — GPU 호스트의 여유 메모리를 자주·동시에 접근되는 데이터의 캐시로 활용(Meta는 Owl 컴포넌트를 클라이언트 SDK에 통합). 평균 hit rate 80%
- readplan 메타데이터 캐시 — 경로→주소 매핑을 memcache 유사 분산 메모리 스토어에 캐시. 1–2ms 접근
이 단순한 메커니즘이 스파이크 흡수, 메타데이터 hot shard 해소, p50/p99 개선을 동시에 한다.
마지막 20% — 프로토콜 최적화
- laggard (느린 노드 하나가 tail latency를 끌어올림) → 클라이언트 측 hedged read
- egress 스파이크 (체크포인트 이벤트 시 혼잡 → 타임아웃 → 재시도 → GPU stall) → 애플리케이션 레벨 혼잡 신호 기반 동적 concurrency 제어로 병렬도 자동 튜닝
연구 속도 — 스토리지를 행성 규모 컴퓨터의 디스크로
GPU는 희소하고 점점 지리적으로 분산되는데 학습은 데이터가 GPU와 코로케이트되기를 요구한다. 그래서 연구자가 리전 간 데이터셋 ingest·이동을 떠안게 된다. 전형적 흐름에서 “리전 선택 → ingestion 잡 제출 → 완료 대기”가 수 시간을 먹는다.
핵심 통찰은 이 데이터셋이 write-once, read-many라는 것. Linux 프로세스가 디스크에서 파일을 읽으면 OS가 페이지 캐시·L2·L1을 거쳐 투명하게 hydrate하듯, 스토리지를 계층형 캐시로 본다.
L1: GPU 호스트 메모리
L2: GPU 호스트 flash
L3: 리전 BLOB 스토리지 (flash)
──────────────────────────────
source of truth: 글로벌 BLOB fabric (HDD)
- 데이터로더 프리페치 — 현재 배치 처리 중 다음 배치를 메모리로
- deep prefetch — 명시적
prefetch()API로 향후 몇 분치 데이터를 백그라운드에서 L3로 hydrate하고 메타데이터 캐시도 프리웜 - 자동 생명주기 — L3의 데이터는 한 학습 사이클의 여러 epoch에서 재사용되도록 일정 기간 유지. TTL/LRU 등 커스텀 eviction 정책, 용량/쿼터 인지
트레이드오프
두 패러다임이 공존한다. 수 주~수개월짜리 대규모 학습 잡은 여전히 사전 스냅샷 복사가 최적 성능을 준다. 하지만 대다수의 작은 잡을 가진 연구자들은 가끔의 성능 저하를 감수하고 반복 속도를 택한다. 프론티어 모델이 몇 주 단위로 나오는 세계에서는 후자가 더 큰 레버다.
연관 개념
- Object Storage Evolution
- Data Engineering FinOps
- Distributed Systems Reliability
- Partition Sizing and Management
- Multimodal Data Processing Engine
- LLM Fine-Tuning