클라우드 네이티브 환경에서 AI/ML 워크로드의 데이터 병목, 왜 발생하는가
AI/ML 워크로드를 쿠버네티스 기반 클라우드 네이티브 인프라에 올리는 것은 이제 선택이 아닌 흐름이다. 하지만 기존 마이크로서비스 중심으로 설계된 스토리지 아키텍처는 GPU 같은 고성능 가속 하드웨어에 대규모 데이터셋을 지속적으로 공급하는 구조에 최적화되어 있지 않다. CNCF TAG Infrastructure가 발행한 이번 백서는 이 간극을 정면으로 다룬다.
백서는 AI/ML 인프라 팀이 데이터 라이프사이클 전반에서 마주치는 세 가지 핵심 병목을 명시한다.
- 소파일 트랩(Small-File Trap): 수백만 개의 소용량 파일로 구성된 학습 데이터셋은 스토리지 메타데이터 서버에 극심한 부하를 유발한다.
- 분리형 아키텍처의 오버헤드: 컴퓨트-스토리지 분리(disaggregation)는 확장성에서 유리하지만, API 호출 오버헤드 증가와 GPU 활용률 저하를 야기한다.
- 워크로드 프로파일 불일치: 배치 학습은 지속적인 고처리량 데이터 이동이 필요한 반면, 인퍼런스는 낮은 지연과 폭발적 요청 패턴을 요구한다. 같은 인프라로 두 패턴을 동시에 수용하는 것은 구조적 과제다.
백서가 제시하는 기술 레이어 구조
CNCF 백서는 클라우드 네이티브 AI 데이터 에코시스템을 몇 가지 핵심 구조 레이어로 분류한다.
데이터 레이크하우스와 벡터 데이터베이스가 첫 번째 축이다. Apache Parquet, Apache Iceberg 같은 오픈 포맷 기반의 하이브리드 데이터 레이크하우스가 중앙화된 데이터 관리의 현실적 대안으로 부상하고 있다. 여기에 고차원 임베딩 벡터의 유사도 검색을 담당하는 Milvus 같은 벡터 데이터베이스가 결합되어 RAG(Retrieval-Augmented Generation) 파이프라인을 뒷받침한다.
캐싱과 데이터 로컬리티 전략도 핵심으로 다뤄진다. 원격 오브젝트 스토리지에서 학습 노드로 데이터를 반복 전송하는 비효율을 줄이기 위해, CNCF 프로젝트인 Fluid를 활용한 쿠버네티스 내 분산 캐싱 오케스트레이션이 소개된다. 학습 잡이 동일 데이터를 반복 접근하는 패턴에서 캐시 히트율을 높이면 GPU 대기 시간을 실질적으로 단축할 수 있다.
# Fluid Dataset 예시 - S3 데이터를 쿠버네티스 노드에 캐싱
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
name: training-data
spec:
mounts:
- mountPoint: s3://my-bucket/train
name: train
이런 구조는 Java 기반 데이터 파이프라인 서버가 학습 데이터를 전처리하거나 피처를 제공하는 역할을 맡을 때도 동일하게 적용된다. 스토리지 레이어의 지연이 줄면 파이프라인 전체 처리량이 개선된다.
백엔드 엔지니어가 주목해야 할 실무 관점
AI 워크로드를 직접 개발하지 않더라도, 데이터 서빙 API나 피처 스토어, 배치 처리 서비스를 운영하는 Java 백엔드 개발자라면 이 백서의 내용은 직결된 문제다. 특히 쿠버네티스 위에서 상태 기반(stateful) 서비스를 운영할 때 퍼시스턴트 볼륨 설계나 오브젝트 스토리지 접근 패턴은 애플리케이션 성능에 직접 영향을 준다.
컴퓨트와 스토리지를 분리하는 현대적 클라우드 아키텍처에서는 네트워크 I/O가 새로운 병목으로 등장한다. 이를 인지하고 로컬 캐싱 레이어를 적절히 배치하거나, 소파일 문제를 회피하기 위해 데이터 포맷을 Parquet 같은 열 지향 포맷으로 통합하는 전략은 순수 인프라 팀만의 과제가 아니다.
정리
- AI/ML 워크로드의 데이터 병목은 소파일 문제, 컴퓨트-스토리지 분리 오버헤드, 워크로드 프로파일 불일치 세 가지에서 주로 발생한다.
- Fluid 기반 분산 캐싱, Parquet/Iceberg 오픈 포맷, 벡터 데이터베이스 통합이 클라우드 네이티브 AI 데이터 아키텍처의 핵심 기술 축이다.
- 데이터 파이프라인이나 API 서버를 운영하는 백엔드 개발자도 스토리지 레이어 설계를 인프라 팀 전용 문제로 위임하지 않고 함께 이해해야 한다.