요약 (TL;DR):

Tuhu는 JuiceFS, TiKV, Ceph RADOS를 활용하여 AI 학습 (AI training), AI 추론 (AI inference) 및 분석을 위한 스토리지를 통합하였으며, 1억 개 이상의 파일을 지원하는 동시에 소형 파일 쓰기 속도를 최대 5.5배, 소형 파일 읽기 속도를 최대 3.2배 향상시켰습니다.

Tuhu (9690.HK)는 온·오프라인 통합 자동차 서비스 플랫폼입니다. 2025년 말까지 등록 사용자 수는 1억 6,230만 명으로 성장하였으며, 중국 전역에서 8,008개의 서비스 센터를 운영하고 있습니다. 비즈니스가 지속적으로 확장됨에 따라, 우리의 인프라는 점점 더 다양해지는 데이터 관리 및 컴퓨팅 워크로드 (compute workloads)를 지원해야 했습니다. 지난 수년간 다양한 애플리케이션 요구 사항을 충족하기 위해 NFS, Alluxio, MinIO, SeaweedFS를 포함한 여러 스토리지 시스템이 독립적으로 배포되었습니다. 각 솔루션은 특정 유스케이스 (use case)를 해결했지만, 전체적인 스토리지 아키텍처 (storage architecture)는 파편화되었고, 이로 인해 데이터 이동 비용이 많이 들고 운영이 점점 더 어려워졌습니다.

통합 스토리지 아키텍처를 평가할 때, 우리는 기존의 프라이빗 클라우드 (private cloud) 인프라와 Ceph 배포 환경을 고려하여 **JuiceFS + TiKV + Ceph 오브젝트 스토리지 클러스터 (RADOS)**를 기반으로 한 통합 AI 스토리지 (AI storage) 플랫폼을 구축했습니다.

현재 이 플랫폼은 단일 스토리지 인프라를 통해 AI 학습 (AI training), AI 추론 (AI inference) 및 빅데이터 처리 워크로드를 지원합니다. 현재 1억 개 이상의 파일을 관리하고 있습니다. 저동시성 (low-concurrency) 벤치마크 테스트에서, 이 플랫폼은 소형 파일 순차 쓰기 (small-file sequential write) 성능을 최대 5.5배, 소형 파일 읽기 (small-file read) 성능을 최대 3.2배 향상시켰습니다.

이 글에서는 기존의 Ceph 인프라를 기반으로 통합 AI 스토리지 플랫폼을 어떻게 설계하고 배포했는지 설명하겠습니다. 또한 Ceph RADOS 데이터 경로 (data paths), 이레이저 코딩 풀 (erasure-coded pools), 소형 파일에 대한 쓰기 증폭 (write amplification) 감소, 그리고 컨테이너화된 배포 (containerized deployments)의 안정성 개선을 포함하여 여러 운영 최적화 사례를 공유할 것입니다.

여러 스토리지 시스템에서 통합 스토리지 기반으로

우리 회사의 성장 초기 단계에는 개발 속도를 극대화하고 즉각적인 애플리케이션 요구 사항을 충족하기 위해 서로 다른 애플리케이션을 위한 스토리지 인프라를 독립적으로 구축했습니다. 플랫폼이 진화함에 따라, 이러한 접근 방식은 점차 운영 환경에 여러 스토리지 시스템이 공존하는 결과를 초래했습니다.

클라우드 네이티브 컴퓨팅 (cloud-native computing), 대규모 AI 학습 (large-scale AI training), 그리고 AI 추론 (AI inference)의 급격한 도입은 이러한 아키텍처의 한계를 드러냈습니다. 아키텍처 일관성, 데이터 이동성 (data mobility), 운영 복잡성, 그리고 스토리지 성능과 관련된 문제들이 점점 더 명확해졌습니다.

우리는 네 가지 주요 과제를 식별했습니다.

• 높은 운영 복잡성 (High operational complexity): 운영 환경은 NFS, Alluxio, MinIO, Ceph, SeaweedFS 및 다양한 클라우드 블록 스토리지 (cloud block storage) 서비스를 포함한 수많은 스토리지 솔루션에 의존했습니다. 각 시스템은 고유한 배포 모델, 액세스 프로토콜 (access protocol), 운영 워크플로우 (operational workflow) 및 문제 해결 방법론을 가지고 있었습니다. 스토리지 클러스터가 계속 성장함에 따라 일상적인 유지보수, 용량 계획 (capacity planning) 및 버전 업그레이드가 점점 더 어려워졌습니다.

• 데이터 사일로 (Data silos): 서로 다른 스토리지 시스템은 서로 다른 인터페이스를 노출하며 통합된 데이터 액세스 계층 (unified data access layer)이 부족했습니다. AI 학습 파이프라인 (AI training pipelines)은 일반적으로 POSIX 준수 파일 시맨틱 (POSIX-compliant file semantics)을 요구하는 반면, 데이터 처리, 모델 관리, 백업 및 아카이빙을 위한 주변 도구들은 종종 오브젝트 스토리지 (object storage) API에 의존합니다. 이러한 스토리지 시스템들은 자연스럽게 동일한 데이터를 공유할 수 없었기 때문에, 데이터셋을 플랫폼 간에 빈번하게 복사하거나 동기화해야 했습니다. 이는 운영 오버헤드 (operational overhead), 스토리지 소비 및 워크플로우 복잡성을 증가시켰습니다.

• 상승하는 스토리지 비용 (Rising storage costs): 비즈니스가 계속 성장함에 따라 파일 수와 총 스토리지 용량이 모두 급격히 증가했습니다. 동시에 하드웨어 조달, 데이터 센터 리소스 및 스토리지 운영을 포함한 인프라 비용도 계속해서 상승했습니다. 성능과 신뢰성을 유지하면서 스토리지 활용도를 높이는 것이 인프라 팀의 핵심 목표가 되었습니다.

• AI 워크로드의 높아지는 성능 요구사항 (Higher performance requirements from AI workloads): AI 학습 (AI training), AI 추론 (AI inference), 분리된 스토리지 및 컴퓨팅 (disaggregated storage and compute), 그리고 빅데이터 분석 (big data analytics)은 기반 스토리지 시스템의 동시성 (concurrency), 처리량 (throughput), 액세스 지연 시간 (access latency) 및 안정성에 대해 더 높은 요구사항을 제기했습니다. 특히 대규모 소형 파일 액세스 (large-scale small-file access), 멀티 노드 동시 읽기 (multi-node concurrent reads), 모델 파일 로딩 및 온라인 추론 서비스는 스토리지 시스템이 안정적인 용량 지원을 제공할 뿐만 아니라, 높은 동시성 조건에서도 예측 가능한 성능을 전달할 것을 요구했습니다.

그 결과, 여러 개의 독립적인 스토리지 시스템에 기반한 기존 아키텍처는 더 이상 장기적인 애플리케이션 성장을 지원할 수 없었습니다. 우리는 파편화된 스토리지 리소스를 통합된 스토리지 기반(storage foundation)으로 통합하여, 운영을 단순화하는 동시에 서로 다른 컴퓨팅 환경 간의 원활한 데이터 공유를 가능하게 하기로 결정했습니다.

새로운 스토리지 플랫폼은 두 가지 주요 기능 영역을 중심으로 설계되었습니다:

• 인프라 및 가상화 워크로드(workloads)를 위한 블록 스토리지 (Block storage): 이 기능은 가상 머신(virtual machine) 이미지, 클라우드 디스크 및 전통적인 인프라 서비스를 위해 신뢰할 수 있는 고성능 스토리지를 제공했습니다.

• cloud-native 워크로드를 위한 통합 데이터 액세스 (Unified data access): 여기에는 Kubernetes 애플리케이션, 전통적인 마이크로서비스 (microservices), 빅데이터 분석 (big data analytics), AI 학습 (AI training), AI 추론 (AI inference), 그리고 벡터 데이터베이스 (vector databases)와 같은 신흥 미들웨어 (middleware)가 포함됩니다. 이 중 AI 학습 및 추론은 파일 시맨틱 (file semantics), 오브젝트 인터페이스 (object interfaces), 데이터 처리량 (data throughput), 소형 파일 성능 (small-file performance), 그리고 다중 노드 동시 액세스 (multi-node concurrent access) 측면에서 더욱 집중적인 과제를 제기했습니다.

따라서 통합 클라우드 스토리지 기반을 구축하는 것은 가상화 환경을 위한 블록 스토리지 기능과 AI 및 cloud-native 워크로드를 위한 데이터 액세스 기능을 모두 포함했습니다. 다음 섹션에서는 후자에 초점을 맞추어, JuiceFS를 기반으로 AI 학습, AI 추론 및 빅데이터 처리를 지원하는 통합 데이터 액세스 기반을 구축하는 방법을 다룹니다.

JuiceFS를 활용한 통합 AI 스토리지 플랫폼 구축

통합 스토리지 플랫폼을 설계할 때, 우리는 기존의 프라이빗 클라우드 (private cloud) 인프라, 스토리지 투자 및 워크로드 특성을 바탕으로 여러 아키텍처 접근 방식을 평가했습니다.

우리의 주요 목표는 대규모 데이터 액세스를 지원하고, 스토리지와 컴퓨팅의 분리 (disaggregated storage and compute)를 가능하게 하며, 다양한 액세스 프로토콜을 제공하고, 불필요한 운영 복잡성을 도입하지 않으면서 높은 신뢰성을 전달하는 것이었습니다.

새로운 분산 스토리지 시스템을 처음부터 구축하는 대신, 우리는 JuiceFS, TiKV, 그리고 Ceph RADOS를 기반으로 한 모듈형 아키텍처 (modular architecture)를 선택했습니다. 이 접근 방식은 기존의 Ceph 인프라를 활용하는 동시에, 단일 스토리지 플랫폼을 통해 AI 학습 (AI training), 추론 (inference), 그리고 빅데이터 처리 (big data processing) 워크로드를 제공할 수 있는 통합 파일 시스템 (unified file system)을 도입할 수 있게 해주었습니다.

이 아키텍처의 핵심 설계 원칙은 메타데이터 (metadata)와 사용자 데이터 (user data)의 분리입니다.

JuiceFS는 통합 파일 시스템 계층을 제공하며, 메타데이터 엔진 (metadata engine)과 Ceph RADOS는 메타데이터 관리와 데이터 저장을 독립적으로 처리합니다. 스토리지 계층 (storage layer)에서 Ceph는 CRUSH 알고리즘을 사용하여 데이터를 분산하고 장애 도메인 (failure domains)을 관리함으로써, 분산화되고 신뢰성이 높은 스토리지 백엔드 (storage backend)를 제공합니다.

또한 이 아키텍처는 경량 클라이언트 (lightweight client) 모델을 채택하고 있습니다.

JuiceFS 클라이언트는 파일 시스템 시맨틱 (file system semantics), 메타데이터 작업 (metadata operations), 캐시 관리 (cache management), 그리고 요청 스케줄링 (request scheduling)을 담당합니다. 데이터가 Ceph RADOS에 기록되면, 복제 (replication) 또는 이레이저 코딩 (erasure coding)을 통해 구현되는 데이터 내구성 (data durability)은 스토리지 클러스터 (storage cluster)에 의해 완전히 처리됩니다.

이러한 책임 분할은 컴퓨팅 노드 (compute nodes)를 경량으로 유지하고, AI 학습 워크로드에 대한 간섭을 최소화하며, 기존 Ceph 배포 환경이 이미 제공하고 있는 신뢰성과 확장성 (scalability)을 최대한 활용할 수 있게 합니다.

우리의 프라이빗 클라우드 (private cloud) 환경에서 이러한 모듈형 접근 방식은 통합된 분산 스토리지 시스템을 개발하고 유지 관리하는 것에 비해 엔지니어링 및 운영 오버헤드 (operational overhead)를 크게 줄여주었습니다. 동시에, 공통 스토리지 플랫폼을 통해 AI 학습, AI 추론, 그리고 빅데이터 워크로드에 대한 통합된 액세스를 제공합니다.

통합 AI 스토리지 아키텍처

우리의 통합 AI 스토리지 플랫폼은 네 개의 논리적 계층 (logical layers)으로 구성됩니다.

워크로드 계층 (Workload layer)

최상단에는 가상 머신 (virtual machines), Kubernetes 기반 컨테이너화된 애플리케이션 (containerized applications), 전통적인 마이크로서비스 (microservices), AI 학습, AI 추론, 그리고 Apache Spark 작업 (jobs)을 포함한 애플리케이션 워크로드가 있습니다.

캐시 계층 (Cache layer)

캐시 계층 (Cache layer)은 다음 두 가지 구성 요소로 이루어집니다:

• DataCache Pool: 훈련 데이터셋, 모델 파일 및 기타 핫 데이터 (hot data)에 대한 반복적인 액세스를 가속화하여 스토리지 백엔드 (storage backend)의 부하를 줄입니다.

• KVCache Pool: 대규모 언어 모델 (LLM) 추론을 위해 설계되었습니다. 여러 스토리지 계층에 걸쳐 컨텍스트 데이터 (context data)를 캐싱하여, 지연 시간 (latency)을 줄이고 온라인 추론 서비스의 응답성을 향상시킵니다.

스토리지 프로토콜 계층 (Storage protocol layer)

JuiceFS는 여기서 통합된 데이터 액세스 진입점 (entry point)을 제공합니다. AI 훈련 작업 (training jobs)은 POSIX FUSE 또는 CSI 드라이버 (CSI Driver)를 통해 데이터에 액세스하고, 빅데이터 Spark 작업은 JuiceFS Hadoop Java SDK를 통해 데이터에 액세스하며, 오브젝트 스토리지 (object storage) 툴체인은 JuiceFS S3 게이트웨이 (S3 Gateway)를 통해 동일한 데이터에 액세스합니다. 이러한 접근 방식은 파일 스토리지, 오브젝트 스토리지, 빅데이터 액세스 인터페이스를 단일한 기반 데이터셋 (underlying data set) 주위로 통합하여, 시스템 간의 데이터 이동과 중복 스토리지를 줄여줍니다.

VM 클라우드 디스크와 같은 블록 스토리지 (block storage) 시나리오는 전체 클라우드 스토리지 시스템의 블록 스토리지 기능의 일부인 Ceph RBD에 의해 주로 처리된다는 점에 유의해야 합니다. 이 글의 초점은 JuiceFS를 기반으로 구축된 파일, 오브젝트 및 빅데이터 액세스 기반에 있습니다. 두 방식 모두 기반이 되는 Ceph 스토리지 리소스를 공유하지만, 액세스 의미론 (access semantics)과 서비스 대상은 서로 다릅니다.

스토리지 엔진 계층 (Storage engine layer)

JuiceFS는 메타데이터-데이터 분리 아키텍처 (metadata-data decoupled architecture)를 사용합니다. 수억 개의 파일을 가진 파일 시스템의 경우, 메타데이터 성능은 경로 해석 (path resolution), 디렉토리 순회 (directory traversal), 파일 속성 쿼리 (file attribute queries), 소형 파일 액세스 (small-file access) 및 동시 작업 시작 성능에 직접적인 영향을 미칩니다. TiKV는 분산 트랜잭션 (distributed transactions), 강력한 일관성 (strong consistency), 고가용성 (high availability) 및 수평적 확장성 (horizontal scalability)을 제공하여 대규모 파일 시스템을 위한 안정적인 메타데이터 지원을 제공합니다. 저희는 메타데이터 계층을 위해 5개 노드로 구성된 TiKV 클러스터를 구축했습니다.

데이터 계층 (data layer)의 경우, JuiceFS의 기반 데이터 스토리지 엔진으로 Ceph RADOS를 사용합니다. Ceph RADOS는 기존의 프라이빗 클라우드 스토리지 자원을 재사용하여 중복적인 인프라 비용을 절감합니다. 또한, 물리적 데이터 저장을 위해 이레이저 코딩 (erasure-coded) 풀을 생성함으로써 신뢰성을 유지하면서도 물리 디스크 용량 활용도를 높여, 데이터 증가에 따른 비용 압박을 완화합니다.

이 아키텍처에서 데이터 통신은 두 가지 경로를 따릅니다:

• 클라이언트와 TiKV 사이의 메타데이터 경로 (metadata path): 경로 조회 (path lookups), 디렉토리 구조, 파일 속성 및 상태 정보를 처리합니다.

• 클라이언트와 Ceph RADOS 사이의 데이터 읽기/쓰기 경로 (data read/write path): 실제 데이터 블록 액세스를 처리합니다.

JuiceFS는 librados를 통해 기반이 되는 Ceph RADOS와 직접 상호작용합니다. 전통적인 게이트웨이 기반 스토리지 아키텍처와 비교했을 때, 이는 다층 포워딩 오버헤드 (multi-layer forwarding overhead)를 줄여주어, 클라이언트가 메타데이터 상호작용 후 스토리지 클러스터에 더 직접적으로 액세스할 수 있게 하고 데이터 액세스 경로를 단축시킵니다.