Meta’s AI Storage Blueprint at Scale

Author: Sidharth Bajaj, Venkatraghavan Srinivasan (Meta) | Source: engineering.fb.com | Published: 2026-07-02


한 줄 요약

AI 컴퓨트는 2년마다 3배 빨라졌지만 스토리지는 그러지 못해 GPU stall의 주범이 되었고, Meta는 메타데이터 서브시스템 재작성 + 데이터플레인 프록시 제거 + 계층형 캐시/프리페치로 BLOB 스토리지를 AI-ready하게 다시 지었다.

핵심 주장/내용

  • 두 가지 목표: ① GPU 활용률 극대화 ② 연구 속도(research velocity) 극대화. AI가 뇌라면 스토리지는 기억 — 능력과 속도가 기억의 크기와 검색 속도에 달려 있음
  • 왜 레이턴시인가: 수십만 GPU가 배치 단위로 학습하고 주기적으로 상태를 동기화 → GPU 하나가 느리면 전체 학습이 느려짐. 데이터로더는 현재 배치 처리 중 다음 배치를 프리페치하므로 fetch 레이턴시가 예산 안에 들어와야 stall이 없음
  • 레거시 BLOB 아키텍처가 AI-ready가 아니었던 이유: getObject 하나에 namelayer→volumeslayer→containerlayer 여러 stateful 레이어를 거치며 메타데이터 조회. 일부는 리전을 넘고, 합치면 수백 ms. 조회 하나만 느려도 끝. HDD 시대엔 병목이 아니었지만 flash 밀리초 접근에는 showstopper
  • 뒤집힌 4가지 가정: 성능/레이턴시(pMax까지 bounded 요구), 신뢰성(글로벌 복제 기본값이 더 이상 성립 안 함), 비용 효율(byte당 비용 최적화 HDD → IOPS 요구로 flash, 스토리지 컴퓨트 비용은 GPU 대비 무시 가능), 전력 효율(데이터센터가 공간이 아닌 전력 제약 → 스토리지에 쓴 kW는 GPU에 못 쓴 kW, AI 시대의 새 제약)
  • 3가지 재설계:
    • 통합 메타데이터 스키마: 여러 레이어에 흩어진 메타데이터를 ZippyDB 기반 단일 flat 스키마로 붕괴 → 경로→주소 해석을 O(1) 로
    • 데이터플레인 프록시 제거: fat client SDK가 스토리지 서버에서 클라이언트로 직접 스트리밍(전력 예산 + 처리량/레이턴시)
    • 리전 배포: 모든 AI 리전에 GPU와 코로케이트된 리전 BLOB 스택
  • 스파이크·핫스팟 대응: GPU 호스트의 여유 메모리를 Owl 기반 분산 데이터 캐시로 활용(SDK에 peer 통합), readplan(경로→주소 매핑)을 memcache 유사 분산 메모리 스토어에 캐시
  • 프로토콜 최적화: laggard는 client-side hedged read, 체크포인트 시 egress 스파이크는 애플리케이션 레벨 혼잡 신호 기반 동적 concurrency 제어로 병렬도 자동 튜닝
  • 연구 속도 — OS의 페이지 캐시 발상을 행성 규모로: 리전 경계를 생각하지 않고 “한 번 ingest, 어디서나 접근”. GPU 호스트 메모리=L1, 호스트 flash=L2, 리전 BLOB flash=L3, HDD 기반 글로벌 fabric이 최종 source of truth
    • 데이터로더 프리페치(다음 배치) + 명시적 prefetch() API로 deep prefetch(향후 몇 분치를 백그라운드로 L3에 hydrate + 메타데이터 캐시 프리웜) + TTL/LRU·쿼터 인지 자동 생명주기

주요 수치 / 사실

  • AI 컴퓨트 성능은 2년마다 약 3배, 스토리지·인터커넥트는 훨씬 완만 → 격차가 GPU stall로
  • 분산 데이터 캐시 평균 hit rate 80%, read-plan 캐시는 메타데이터 1–2ms 접근
  • 기존 워크플로에서 리전 선택 → ingestion 잡 제출 → 완료 대기(2~4단계)가 수 시간, 새 패러다임은 분 단위
  • 수백 개 엑사바이트 규모 클러스터, Tectonic(리전 멀티테넌트 블록 레이어, erasure coding, HDD/flash 티어링) 위에 BLOB 레이어
  • 대규모 장기 학습 잡은 여전히 스냅샷 복사가 최적이지만, 대다수의 작은 잡은 가끔의 성능 저하를 감수하고 반복 속도를 택함

관련 위키


Source: 원문 보기