메타의 대규모 AI 스토리지 청사진 (새 탭에서 열림)
AI 혁신의 속도와 규모가 커질수록 스토리지는 GPU 활용률과 연구 생산성을 좌우하는 핵심 인프라가 된다. Meta는 기존 BLOB 스토리지의 긴 메타데이터 경로와 글로벌 복제 중심 설계가 AI의 낮고 예측 가능한 지연시간 요구를 충족하지 못한다고 판단했다. 이에 통합 메타데이터, 데이터 프록시 제거, GPU 인접 리전 배포를 중심으로 아키텍처를 재구축해 GPU 유휴 시간을 줄이고 데이터 처리 속도를 높이려 했다. ## AI 워크로드에서 스토리지가 중요한 이유 - AI 모델과 학습 데이터셋의 규모가 빠르게 증가하고, 프런티어 모델 출시 주기도 수개월에서 수주로 단축되고 있다. - GPU 성능은 약 2년마다 세 배 수준으로 향상된 반면, 스토리지와 네트워크 성능 향상은 상대적으로 느렸다. - 스토리지 병목은 다음과 같은 문제를 일으킨다. - GPU가 데이터를 기다리며 유휴 상태가 됨 - 학습 시간과 인프라 비용이 증가함 - 여러 리전에 분산된 GPU로 데이터를 이동·적재하는 데 시간이 걸림 - 연구자가 실험을 반복하는 속도가 느려짐 - Meta는 이러한 문제를 해결하기 위해 BLOB 스토리지를 두 가지 목표에 맞춰 발전시켰다. - GPU 활용률 최대화 - AI 연구 반복 속도, 즉 연구 생산성 최대화 ## Meta의 기존 스토리지 계층 - Meta의 스토리지 서비스는 Facebook, Instagram, Reality Labs, Meta AI, 광고, 데이터 웨어하우스 등 다양한 서비스에 사용된다. - 기반 계층인 **Tectonic**은 수평 확장 가능한 블록 스토리지 패브릭이다. - 소거 코드(erasure coding)를 이용해 높은 내구성과 가용성을 제공한다. - HDD와 플래시 등 여러 미디어 계층을 지원한다. - 핫·웜·콜드 데이터를 적절히 배치해 테넌트 간 I/O 효율을 관리한다. - 그 위의 BLOB 스토리지는 전역적으로 확장 가능한 저장소 인터페이스를 제공하며, 내구성과 가용성 사이의 정책적 선택을 지원한다. - 과거에는 Tectonic 위에 NFS와 유사한 파일 시스템 인터페이스를 제공해 Llama 학습을 수행했지만, 최근 학습 스택은 대규모 데이터 레이크에 대한 통합 접근성과 고성능을 위해 BLOB 인터페이스로 점진적으로 이동하고 있다. ## GPU 학습에서 지연시간이 중요한 이유 - 수십만 개의 GPU가 대규모 데이터셋을 여러 에폭에 걸쳐 반복 처리한다. - 각 GPU 호스트의 데이터로더는 GPU가 현재 배치를 처리하는 동안 다음 배치를 미리 읽어 계산과 I/O를 겹친다. - 대부분의 요청이 빠르더라도 일부 요청의 지연시간이 크게 튀면 GPU가 데이터를 기다리며 멈출 수 있다. - 일정한 학습 스텝마다 GPU들이 상태를 동기화하므로, 단 하나의 느린 GPU도 전체 학습 스텝과 클러스터의 진행을 지연시킨다. - 따라서 평균 지연시간보다 **pMax와 같은 최악 구간의 지연시간을 낮고 예측 가능하게 유지하는 것**이 중요하다. ## 기존 BLOB 아키텍처의 한계 - 기존 BLOB 스토리지는 여러 서비스 계층을 덧붙이는 방식으로 발전했으며, 각 계층이 별도의 상태와 메타데이터 저장소를 보유했다. - `getObject("/bucket/path")` 요청은 다음과 같은 여러 계층을 거쳐야 했다. - API 서버가 요청 수신 - namelayer, volumeslayer, containerlayer 등에서 메타데이터 조회 - 경로를 `(blockId, offset, size)` 목록으로 변환 - Tectonic에서 데이터를 가져온 뒤 API 서버가 클라이언트로 프록시 - 메타데이터 조회가 여러 리전을 넘나들 수 있고, 어느 한 단계라도 느리면 전체 지연시간이 증가했다. - 전통적인 HDD 기반 워크로드에서는 수백 밀리초의 메타데이터 지연이 큰 문제가 아니었지만, 플래시 기반 AI 스토리지에서는 데이터 접근 자체가 밀리초 단위이므로 메타데이터 조회가 주요 병목이 되었다. ## AI 시대에 달라진 설계 요구사항 - **성능과 지연시간** - 기존 서비스는 평균적인 성능이면 충분했지만, AI는 높은 처리량과 pMax까지 예측 가능한 지연시간을 요구한다. - **가용성과 내구성** - 기존에는 리전 장애에도 대응하기 위해 데이터와 메타데이터를 기본적으로 전역 복제했다. - AI는 높은 가용성을 원하지만, 모든 데이터를 전역 복제하는 설계가 항상 필요한 것은 아니다. - **비용 효율** - 기존 스택은 HDD의 바이트당 비용을 최소화하는 데 최적화됐다. - AI는 높은 IOPS 때문에 플래시가 필요하며, 스토리지 계산 비용보다 GPU 계산 비용이 훨씬 커졌다. - **전력 효율** - AI 데이터센터는 공간보다 전력 제약이 커지고 있다. - 스토리지에 사용하는 전력은 GPU에 사용할 수 없는 전력이므로, 프록시와 불필요한 계층을 줄여야 한다. ## 통합 메타데이터와 직접 데이터 스트리밍 Meta는 AI 워크로드에 맞춰 스토리지 기반을 다시 설계했다. - **통합 메타데이터 스키마** - 여러 계층에 분산돼 있던 메타데이터를 하나의 평탄한 스키마로 통합했다. - ZippyDB를 기반으로 경로와 실제 저장 위치의 매핑을 관리한다. - 청크 단위로 경로를 저장 주소로 변환하는 조회를 O(1)에 가깝게 수행할 수 있게 됐다. - **데이터 플레인 프록시 제거** - API 서버가 데이터를 중계하지 않고, 클라이언트 SDK가 스토리지 서버에서 직접 바이트를 스트리밍하도록 변경했다. - 불필요한 데이터 복사와 네트워크 홉을 줄였다. - 전력 사용량을 줄이면서 처리량을 높이고 지연시간을 낮출 수 있다. - **팻 클라이언트 SDK** - SDK에 Tectonic `BlockClient`를 내장했다. - 클라이언트는 먼저 `getReadPlan("/bucket/path")`을 호출해 읽기 계획을 얻는다. - API 서버는 메타데이터를 조회해 `(blockId, offset, size)` 정보를 반환한다. - 이후 SDK가 Tectonic 블록에서 데이터를 직접 읽는다. - **리전 단위 배포** - BLOB 스택을 전역 서비스로만 운영하지 않고, GPU가 위치한 각 AI 리전에 함께 배치한다. - 데이터와 GPU의 물리적 거리를 줄여 리전 간 데이터 이동과 지연시간을 줄인다. - 이 구조는 Tectonic 위에 추가되는 오버헤드를 사실상 제거하고, 데이터 프록시를 없애 전력 예산도 준수하도록 설계됐다. ## 실용적인 결론 AI 학습용 스토리지는 단순히 저장 용량이나 평균 처리량을 늘리는 것만으로 충분하지 않다. 메타데이터 경로를 단순화하고, 데이터 프록시를 제거하며, GPU와 가까운 곳에 스토리지를 배치하고, 최악 지연시간을 관리해야 한다. 특히 플래시 기반 AI 환경에서는 전통적인 글로벌 복제·다계층·중앙 프록시 구조보다 워크로드에 맞춘 지역성, 직접 스트리밍, 예측 가능한 지연시간이 더 중요한 설계 기준이 된다.
