🟡 📦 오픈소스 게시일: · 3 분 읽기 ·

CNCF 백서: 데이터 스토리지가 대규모 클라우드 네이티브 AI의 주요 장벽으로 남다

에디토리얼 일러스트: 클라우드 네이티브 AI 및 Kubernetes 인프라를 위한 데이터 스토리지에 관한 CNCF 백서

CNCF TAG Infrastructure가 클라우드 네이티브 AI 환경의 데이터 스토리지 병목 현상을 매핑하고, 훈련, 추론, 에이전트 AI 단계의 요구 사항을 구분하며, Kubernetes AI/ML 배포를 위한 아키텍처 지침을 제시하는 백서를 발표했다.

🤖

이 기사는 AI가 1차 출처를 기반으로 생성했습니다.

CNCF TAG Infrastructure가 「Data Storage in Cloud Native AI」라는 제목의 백서를 발표했다. 어떤 특정 벤더의 후원도 받지 않은 커뮤니티 저작 문서다. 프로젝트의 내부 작업명은 「Data On Kubernetes – Data Analytics and AI/ML Workloads」였으며, 이는 실질적인 초점을 더 정확하게 설명한다. AI 워크로드가 Kubernetes를 통해 흐를 때 데이터 스토리지는 어떻게 작동하는가?

문서가 제시하는 답은 낙관적이지 않다. 표준 마이크로서비스에 최적화된 기존 스토리지 아키텍처는 대규모 데이터셋을 병렬화된 고성능 GPU 하드웨어 인프라에 공급하는 과제에 직면했을 때 심각한 한계를 드러낸다.

세 가지 핵심 병목 현상은 무엇인가?

문서는 클라우드 네이티브 AI 인프라가 대규모로 기능하기 위해 해결해야 할 세 가지 시스템적 장벽을 식별한다.

소규모 파일 문제가 아마도 가장 까다롭다. 훈련 데이터셋에는 이미지, 오디오 클립, 텍스트 문서 등 수백만 개의 소규모 파일이 포함되는 경우가 많다. 각 파일은 별도의 메타데이터 작업을 필요로 한다. 수백만 건의 이러한 작업이 합산되면 메타데이터 서버에 막대한 부하가 발생하고, GPU 노드가 연산 대신 데이터를 기다리는 결과를 초래한다. GPU 활용률은 떨어지고, 비용은 증가하며, 생산성은 정체된다.

컴퓨팅과 스토리지 분리의 병목이 두 번째 시스템적 과제다. 컴퓨팅과 스토리지 리소스의 분리는 클라우드 네이티브 환경의 기본 아키텍처 원칙이며, 표준 워크로드에서는 일반적으로 잘 작동한다. 그러나 AI 훈련 및 추론의 경우, 원격 데이터에 접근할 때마다 발생하는 API 오버헤드가 눈에 띄는 성능 저하와 고가의 가속기 활용률 감소로 누적된다.

단계별 다양한 요구 사항이 세 번째 병목이며, 이번에는 조직적 성격을 띤다. 훈련, 추론, 에이전트 AI는 근본적으로 다른 스토리지 요구 프로파일을 가지며, 단일한 접근 방식으로는 세 단계 모두를 최적으로 처리할 수 없다.

서로 다른 요구를 가진 AI 라이프사이클의 세 단계

백서는 클라우드 네이티브 AI 스토리지를 별도의 아키텍처 고려가 필요한 세 단계를 중심으로 구조화한다.

훈련 단계는 주로 높은 처리량을 요구한다. 시스템은 GPU 클러스터에 대규모 데이터를 지속적이고 순차적으로 공급할 수 있어야 하며, 중단 후 훈련 재개를 가능하게 하는 체크포인트를 효율적으로 관리해야 한다. Apache Parquet 형식이 컬럼형 읽기와 압축 덕분에 이 단계에서 지배적이다.

추론 단계는 지연 시간을 중시한다. 요청은 급증하는 형태로 들어오며 트래픽이 균일하지 않고, 모델은 빠르게 사용 가능해야 한다. KV 캐싱과 빠른 모델 로딩이 크리티컬해진다. 테이블 형식으로서의 Apache Iceberg는 모델 버전 관리에 유용한 타임 트래블과 스키마 진화를 제공한다.

에이전트 AI는 가장 복잡한 요구 사항을 나타낸다. 반복적 추론 루프를 실행하는 에이전트는 세션 내 활성 컨텍스트를 위한 단기 메모리와 세션 간 지속되는 지식을 위한 장기 메모리의 조합이 필요하다. 또한 중간 결과, 참조, 계획된 단계 등의 아티팩트를 생성하며 이를 저장하고 검색할 수 있어야 한다. 이 단계에서 벡터 데이터베이스가 두각을 나타내며, Milvus가 대규모에서 효율적인 벡터 검색을 위한 오픈소스 솔루션으로 특별한 주목을 받는다.

핵심 기술과 CNCF 프로젝트

문서는 식별된 병목 현상을 해결하는 기술 생태계를 매핑한다. CSI(Container Storage Interface)와 COSI(Container Object Storage Interface)는 특정 벤더에 독립적으로 Kubernetes 워크로드에서 스토리지 접근을 표준화한다.

활성 CNCF 프로젝트인 Fluid는 데이터를 컴퓨팅 노드에 더 가깝게 유지하는 분산 캐싱 레이어를 구현한다. 이는 컴퓨팅과 스토리지 리소스 분리의 오버헤드를 직접 해결한다. 데이터는 적극적으로 사용하는 노드에 로컬로 캐싱된다. 스트리밍 및 이벤트 기반 파이프라인 아키텍처에는 Apache Kafka가 참조 구현으로 남아 있다.

플랫폼 엔지니어에게 왜 관련이 있는가

백서는 학술 문서가 아니다. AI 워크로드를 위한 Kubernetes 클러스터 아키텍처를 오늘 결정해야 하는 팀을 위한 실용적인 참고 자료다. 지침은 구체적이고 적용 가능하다. 어떤 usecase에 어떤 데이터 형식을 선택할지, 캐싱 레이어를 어떻게 구성할지, 어떤 CNCF 프로젝트를 통합할지.

벤더 후원 없는 커뮤니티 저작 방식은 마케팅 백서에는 없는 신뢰성을 문서에 부여한다. CNCF TAG Infrastructure는 커뮤니티에 PDF 검토, TAG Infrastructure 헌장 토론 기여, #tag-infrastructure Slack 채널 참여 등 지속적인 발전에 동참하도록 초청한다.

자주 묻는 질문

소규모 파일 문제란 무엇이며 왜 AI 훈련에 치명적인가?
훈련 데이터셋에는 수백만 개의 소규모 파일이 포함되는 경우가 많아 스토리지 메타데이터 서버에 막대한 부하를 준다. 이로 인해 프로세서가 연산 대신 데이터를 기다리는 상황이 발생하여 GPU 활용률이 급격히 떨어진다.
에이전트 AI는 왜 기존 훈련과 다른 스토리지 요구 사항을 가지는가?
에이전트 AI는 세션 내 활성 컨텍스트를 위한 단기 메모리와 세션 간 지식을 위한 장기 메모리를 결합한 복잡한 메모리 아키텍처가 필요하며, 반복적 추론 루프에서 생성된 아티팩트도 저장해야 한다. 이는 훈련의 순차적 읽기와는 근본적으로 다른 접근 패턴이다.
AI 데이터의 분산 캐싱 문제를 해결하는 CNCF 프로젝트는 무엇인가?
Fluid는 분산 캐싱 레이어를 구현하여 데이터를 컴퓨팅 노드에 더 가깝게 유지하는 CNCF 프로젝트다. Kubernetes 클러스터에서 컴퓨팅과 스토리지 리소스 분리로 인해 발생하는 지연 시간과 API 오버헤드를 줄여준다.