GPU가 놀고 있다면? 메타가 AI 스토리지를 처음부터 다시 설계한 이유

AI의 뇌와 기억: 왜 스토리지가 GPU 성능을 결정하는가

AI 모델의 성능이 기하급수적으로 성장하면서, GPU 컴퓨팅 파워도 함께 증가했습니다. 하지만 정작 GPU가 데이터를 기다리는 시간은 여전히 큰 병목으로 남아있죠. 메타의 엔지니어링 블로그에 공개된 내용에 따르면, 이 문제를 해결하기 위해 그들은 BLOB 스토리지 아키텍처를 완전히 재설계했다고 합니다.

쉽게 비유하자면, GPU가 아무리 뛰어난 두뇌라도 기억력(스토리지)이 따라주지 못하면 제 성능을 발휘할 수 없습니다. AI 연산 성능이 2년마다 3배씩 성장하는 동안, 스토리지 성능은 상대적으로 완만하게 증가했습니다. 이로 인해 GPU가 데이터를 기다리며 쉬는 시간이 늘어났고, 이는 곧 비용 증가와 시장 출시 지연으로 이어졌습니다.

메타는 이 문제를 해결하기 위해 두 가지 핵심 목표를 세웠습니다:

1. GPU 활용도 최대화 — 스토리지 지연 시간을 줄여 GPU가 항상 바쁘게 일하게 만들기
2. 연구 속도 최대화 — 연구자들이 데이터를 옮기는 데 시간을 낭비하지 않도록 하기

이 글에서는 메타가 어떻게 이 목표를 달성했는지, 그 과정을 자세히 분석해보겠습니다.

레거시 BLOB 스토리지의 한계: 왜 AI 워크로드에 부적합했나

메타의 기존 BLOB 스토리지 아키텍처는 페이스북, 인스타그램 같은 전통적인 웹 서비스에 최적화되어 있었습니다. 문제는 이 구조가 AI 워크로드의 특성과 정면으로 충돌했다는 점입니다.

AI 워크로드는 다음과 같은 특징을 가집니다:

• 버스트하고 지속적인 높은 처리량 요구
• 예측 가능하고 제한된 지연 시간(pMax) 요구
• 가변적인 I/O 패턴

기존 아키텍처는 getObject() API 호출 시 여러 레이어의 메타데이터 조회를 거쳤습니다. 네임 레이어, 볼륨 레이어, 컨테이너 레이어를 순차적으로 거치면서 경로를 블록 주소로 변환하는 과정에서 수백 밀리초의 지연이 발생할 수 있었죠. 하나의 조회라도 느리면 전체 요청이 지연되는 구조였습니다.

# 레거시 아키텍처의 getObject 요청 흐름 (개념적 표현)

def get_object_legacy(bucket_path):
    # 1. 네임 레이어에서 버킷 정보 조회 (수십 ms)
    volume_info = namelayer.lookup(bucket_path)
    
    # 2. 볼륨 레이어에서 컨테이너 정보 조회 (수십 ms)
    container_info = volumeslayer.lookup(volume_info)
    
    # 3. 컨테이너 레이어에서 블록 주소 조회 (수십 ms)
    block_addresses = containerlayer.lookup(container_info)
    
    # 4. 데이터 플레인 프록시를 통해 데이터 스트리밍
    data = proxy_to_tectonic(block_addresses)
    return data

# 문제: 각 레이어 조회가 수십 ms씩 걸리고, 지역 간 조회 시 수백 ms까지 지연될 수 있음
# GPU는 이 시간 동안 데이터를 기다리며 유휴 상태로 대기

새로운 기반 설계: 통합 메타데이터와 데이터 플레인 제거

메타는 이러한 한계를 극복하기 위해 세 가지 핵심 설계 결정을 내렸습니다.

1. 통합 메타데이터 스키마

여러 레이어에 분산되어 있던 메타데이터를 단일 플랫 스키마로 통합하고 ZippyDB에 저장했습니다. 이를 통해 경로를 스토리지 주소로 변환하는 데 O(1) 조회만으로 가능해졌습니다.

# 새로운 아키텍처의 getObject 요청 흐름 (개념적 표현)

def get_object_new(bucket_path):
    # O(1) 단일 조회로 블록 주소 직접 획득
    read_plan = metadata_store.lookup(bucket_path)
    
    # SDK에 내장된 BlockClient로 직접 데이터 스트리밍
    data = sdk.block_client.stream(read_plan)
    return data

2. 데이터 플레인 프록시 제거

기존에는 API 서버가 데이터를 중계하는 프록시 역할을 했습니다. 이제는 팻 클라이언트 SDK를 만들어 클라이언트가 Tectonic 스토리지 서버에서 직접 데이터를 스트리밍하도록 변경했습니다. 이는 전력 효율성과 처리량을 동시에 개선했습니다.

3. 리전별 배포

BLOB 스토리지 스택을 가볍게 만들어 GPU와 함께 각 AI 리전에 배포할 수 있게 했습니다. 더 이상 글로벌 서비스가 아닌, GPU와 물리적으로 가까운 위치에서 동작하는 구조입니다.

스파이크와 핫스팟 처리: 분산 캐시와 메타데이터 캐시

AI 워크로드는 학습 중 수백 개 GPU가 동시에 데이터에 접근하는 특징이 있습니다. 특히 모델 가중치 같은 일부 데이터는 매우 인기 있는 '핫' 데이터가 되어 트래픽이 급증합니다.

메타는 이 문제를 해결하기 위해 두 가지 접근법을 사용했습니다:

1. 분산 데이터 캐시: GPU 호스트의 남는 메모리를 활용해 자주 접근하는 데이터를 캐시했습니다. 평균 캐시 히트율은 80% 에 달한다고 합니다.
2. Readplan 메타데이터 캐시: 자주 접근하는 BLOB의 경로-주소 매핑을 분산 메모리 저장소에 캐시하여 1-2ms 만에 메타데이터에 접근할 수 있게 했습니다.

프로토콜 최적화: 마지막 20%의 병목 제거

이러한 개선으로 80%의 성과를 얻었지만, 나머지 20%는 스택 전반의 병목을 찾아 해결해야 했습니다.

• 지연 노드(Laggards): 느린 스토리지 노드 하나가 꼬리 지연 시간을 유발하는 문제를 헤지드 리드(Hedged Reads) 로 해결했습니다. 클라이언트가 여러 노드에 동시에 요청을 보내고 가장 먼저 응답하는 결과를 사용하는 방식입니다.
• 이그레스 스파이크: 체크포인트 이벤트 시 발생하는 트래픽 급증을 동적 동시성 제어로 해결했습니다. 클라이언트 SDK가 애플리케이션 수준의 혼잡 신호를 기반으로 병렬 처리를 자동 조절합니다.

연구 속도 최대화: 디스크를 읽는 운영체제처럼 데이터를 다루자

GPU가 지리적으로 분산되고 데이터셋이 커지면서, 연구자들은 학습 작업 전에 데이터를 대상 리전으로 복사하는 데 몇 시간을 소비해야 했습니다. 이 문제를 해결하기 위해 메타는 운영체제의 페이지 캐시 개념을 차용했습니다.

Linux 프로세스가 디스크에서 파일을 읽을 때, 운영체제는 메모리의 페이지 캐시와 CPU 캐시를 자동으로 활용합니다. 이 아이디어를 스토리지에 적용한 것입니다.

• L1 캐시: GPU 호스트의 메모리
• L2 캐시: GPU 호스트의 플래시
• L3 캐시: 플래시 기반 리전별 BLOB 스토리지
• 최종 소스: HDD 기반 글로벌 BLOB 스토리지

이 구조를 통해 연구자들은 데이터를 한 번만 업로드하면 리전에 관계없이 접근할 수 있게 됐습니다. 또한 prefetch() API를 통해 학습에 필요한 데이터를 미리 로컬 캐시로 가져올 수 있습니다.

주의사항: 이 아키텍처의 한계와 적용 시 고려점

메타의 이 설계는 매우 인상적이지만, 모든 환경에 그대로 적용하기는 어렵습니다.

1. 인프라 규모: 이 설계는 수백 개의 엑사바이트급 클러스터를 운영하는 메타의 규모를 전제로 합니다. 일반 기업이 동일한 아키텍처를 그대로 도입하는 것은 현실적으로 어렵습니다.
2. SDK 의존성: 팻 클라이언트 SDK 방식은 클라이언트 측 구현이 복잡해지고, 이식성이 떨어질 수 있습니다.
3. 운영 복잡성: 계층형 캐시의 데이터 생명주기 관리와 이벤션 정책 수립은 상당한 운영 노하우가 필요합니다.

한국 개발 생태계에서의 적용 맥락

국내에서도 대규모 AI 학습 인프라를 구축하는 기업이 늘어나고 있습니다. 특히 네이버, 카카오, LG AI 연구원 같은 곳에서는 GPU 클러스터의 활용도가 핵심 경쟁력이 되고 있습니다.

이 아키텍처에서 국내 기업들이 즉시 적용할 수 있는 부분은 다음과 같습니다:

• 분산 데이터 캐시: GPU 호스트의 남는 메모리를 활용한 캐시는 비교적 적은 비용으로 큰 효과를 볼 수 있습니다.
• 프로토콜 최적화: 클라이언트 SDK의 동적 동시성 제어는 특정 벤더에 종속되지 않고 자체 구현이 가능합니다.

다만, 통합 메타데이터 스키마나 리전별 배포는 인프라 규모가 어느 정도 갖춰진 환경에서 고려해볼 만합니다.

결론: AI 시대의 스토리지는 '기억력'이 아니라 '생각의 속도'를 결정한다

메타가 이번에 공개한 아키텍처의 핵심은 결국 GPU가 데이터를 기다리는 시간을 최소화하는 것입니다. 이는 단순히 스토리지 성능 개선이 아니라, AI 연구의 반복 속도를 높이는 전략적 결정이었습니다.

메타는 이 설계를 통해 데이터 수집 시간을 크게 단축했고, 연구자들이 모델 튜닝에 집중할 수 있는 환경을 만들었습니다. 특히 '디스크를 읽는 운영체제처럼' 데이터를 다루는 접근법은 스토리지 아키텍처 설계에 새로운 관점을 제시합니다.

이 아키텍처의 핵심 교훈은 다음과 같습니다:

1. 스토리지는 AI 성능의 핵심 요소 — GPU만큼 중요한 인프라
2. 레거시 최적화가 아닌 재설계 — AI 워크로드에 맞는 새로운 설계가 필요
3. 계층형 캐시와 프리페칭 — 데이터 접근 패턴을 최적화하는 실용적 방법

메타의 AI 스토리지 설계 철학은 앞으로 AI 인프라를 구축하는 모든 기업에게 중요한 참고자료가 될 것입니다.

다음 단계로는 이 아키텍처를 어떻게 실제로 구현했는지, 특히 Tectonic 레이어의 상세 설계와 데이터 배치 전략을 더 깊이 파보는 것을 추천합니다.

함께 보면 좋은 글

• 메타, AI로 콘크리트 배합을 최적화하다 — BOxCrete 오픈소스 모델 완전 해부
• QR 코드 없이도 된다? 화면 없는 디바이스를 위한 패스키 인증 혁신