AI 학습 워크로드가 급성장하면서 스토리지 병목이 GPU 활용률과 연구 속도를 결정하는 핵심 변수로 떠올랐다. Meta는 수백 엑사바이트 규모의 BLOB 스토리지를 운영하며 수백만 GPU의 가동률 극대화와 방대한 데이터셋 위에서 연구자들의 반복 속도 극대화라는 두 가지 원칙 문제를 해결해야 했다. 이를 위해 메타데이터 서브시스템 전면 재작성, 데이터플레인 프록시 제거, 지역 배포(regional deployment) 전략을 조합한 새 아키텍처를 설계했다.
핵심 포인트- 레거시 BLOB 스토리지는 namelayer → volumeslayer → containerlayer 다단계 메타데이터 조회로 응답 지연이 수백 ms에 달해 GPU 스톨(stall)의 주요 원인이 됐다.
- ZippyDB 기반 통합 플랫 스키마로 재설계해 O(1) 조회를 실현, 다중 레이어 순차 조회를 단일 라운드트립으로 줄였다.
- 데이터플레인 프록시를 제거하고 Tectonic BlockClient를 내장한 팻 클라이언트 SDK로 스토리지 서버에서 클라이언트로 직접 스트리밍한다.
- GPU 호스트의 여유 메모리를 Owl 시스템으로 분산 데이터 캐시에 활용, 평균 캐시 히트율 80%.
- 티어드 캐시(L1/L2 GPU 호스트 메모리·플래시, L3 지역 플래시, Source of Truth 전역 HDD)와 딥 프리페치 API로 데이터 이동 대기 시간을 구조적으로 제거한다.
상세 정리- 배경: AI 컴퓨팅 성능이 2년마다 3배 성장하는 반면 스토리지·인터커넥트 성능 증가는 더뎌, 스토리지 병목이 GPU 스톨과 비용 증가의 주원인이 됨.
- 레거시 아키텍처 문제: getObject("/bucket/path") 요청 시 namelayer → volumeslayer → containerlayer 순차 메타데이터 조회 필요, 리전 간 조회 포함 시 수백 ms 지연. 하나의 느린 응답이 전체 요청을 블록킹.
- 신규 메타데이터 서브시스템: ZippyDB 기반 통합 플랫 스키마로 재작성. API 서버가 getReadPlan() 호출로 청크당 O(1) 조회 후 (blockId, offset, size) 매핑 반환.
- 팻 클라이언트 SDK: Tectonic BlockClient 내장. API 서버 프록시 없이 Tectonic에서 클라이언트로 직접 스트리밍. 전력 효율 향상, 처리량 증가, 지연 감소.
- 지역 배포(Regional): BLOB 스토리지 스택을 각 AI 리전에 GPU와 함께 코로케이션 배포해 리전 간 레이턴시 제거.
- 분산 데이터 캐시: GPU 호스트의 여유 메모리를 Owl 서브시스템을 통해 분산 캐시로 활용. 빈번히 동시 접근되는 데이터를 캐시해 평균 히트율 80% 달성.
- ReadPlan 메타데이터 캐시: 경로→스토리지 주소 매핑을 memcache 유사 분산 메모리 스토어에 캐시. 1~2ms 메타데이터 접근 실현.
- 지연 완화: 느린 스토리지 노드 대응을 위한 클라이언트 사이드 헤지드 리드(hedged reads), 애플리케이션 레벨 혼잡 신호 기반 동적 동시성 제어.
- 티어드 캐시 아키텍처: L1/L2(GPU 호스트 메모리·플래시), L3(지역 플래시 기반 BLOB 스토리지), Source of Truth(전역 HDD). OS 티어드 캐싱 개념을 행성 규모 컴퓨터에 적용.
- 딥 프리페치 API: prefetch() 호출로 원격 스토리지에서 로컬 L3 캐시로 사전 하이드레이션 및 메타데이터 캐시 예열. 데이터 인제스트 대기 시간(수 시간) 구조적 제거.
- 데이터 로더 프리페치: GPU가 현재 배치를 처리하는 동안 다음 배치를 메모리로 사전 로드해 컴퓨팅과 I/O를 최대한 오버랩.
- 자동 데이터 수명 주기: TTL 및 LRU 퇴거 정책, 용량·쿼터 인지 메커니즘으로 캐시 계층 자동 관리.
왜 읽나수백만 GPU를 운영하는 Meta가 AI 학습 워크로드를 위해 엑사바이트급 BLOB 스토리지를 어떻게 근본부터 재설계했는지, 메타데이터 아키텍처와 캐시 계층화 전략의 실제 선택과 그 이유를 원 저자 시각으로 확인할 수 있다.
Meta Engineering·
AWS Korea Tech·