Xiaomi의 JuiceFS 도입: AI, 빅데이터 및 클라우드 네이티브 워크로드를 위한 통합 스토리지

Xiaomi는 세계적인 선도 스마트폰 기업 중 하나입니다. 2021년부터 Xiaomi의 스토리지 팀은 JuiceFS를 기반으로 한 파일 스토리지 플랫폼을 구축해 왔으며, 초기에는 클라우드 네이티브 (Cloud-native) 및 일부 애플리케이션 시나리오를 위한 파일 스토리지 기능을 제공했습니다. 2024년 Xiaomi가 포괄적인 AI 전략을 발표한 이후, 기술 선택, 데이터 흐름, 개발 및 운영(DevOps) 등의 영역에서 기존의 이기종 스토리지 시스템(Heterogeneous storage system)이 가진 문제점들이 더욱 명확해졌습니다. 이에 팀은 멀티 프로토콜 액세스 (Multi-protocol access), 탄력적 확장성 (Elastic scalability), 멀티 클라우드 적응성 (Multi-cloud adaptability) 및 고성능을 활용하여, 빅데이터, 클라우드 네이티브 및 AI 워크로드를 지원하기 위해 JuiceFS를 중심으로 한 통합 파일 스토리지 기반을 구축하기로 결정했습니다.

이 목표를 달성하기 위해 플랫폼은 용량 계층 (Capacity layer), 성능 계층 (Performance layer), 캐시 계층 (Cache layer)을 포함한 핵심 역량을 추가로 개발했습니다. 이를 통해 대규모 스토리지와 고성능 액세스 사이의 균형을 맞추면서, 멀티 시스템 액세스 및 데이터 이동의 복잡성을 줄였습니다. 지난 2년 동안 생성형 AI (Generative AI)와 자율 주행 (Autonomous driving)의 급격한 성장과 함께, 이 플랫폼은 대규모 모델 학습 (Large-model training), 자율 주행 학습, 추론 가속화 (Inference acceleration) 및 빅데이터 클라우드 마이그레이션과 같은 전형적인 시나리오를 지원해 왔습니다. 오늘날 이 플랫폼은 수천억 개의 파일과 EB(Exabyte) 규모의 스토리지를 처리할 수 있으며, 원천 데이터(Raw data)와 학습 데이터부터 모델 파일 배포에 이르기까지 AI 스토리지 체인 전체를 아우르고 있습니다.

AI 전략 하에서의 스토리지 아키텍처 과제

2023년 이전의 Xiaomi는 대부분의 기업과 마찬가지로 서로 다른 애플리케이션 시나리오를 위해 여러 스토리지 시스템을 구축해 왔습니다. 빅데이터 (Big data) 영역에서는 데이터 플랫폼이 주로 HDFS를 기반으로 했습니다. 대규모 언어 모델 (Large language models)이 부상하기 전의 AI 워크로드는 병렬 파일 시스템 (Parallel File System, PFS) 및 네트워크 결합 스토리지 (Network Attached Storage, NAS)와 같은 클라우드 상의 고성능 파일 스토리지 서비스에 주로 의존했습니다.

이 기간 동안 우리는 JuiceFS를 도입하기 시작했으며, JuiceFS CSI Driver와 같은 구성 요소를 사용하여 클라우드 네이티브 (Cloud-native) 및 일부 애플리케이션 시나리오에 파일 스토리지를 제공하는 자체 개발 파일 스토리지 서비스 (File Storage Service, FDS)를 구축했습니다. 애플리케이션의 요구사항이 진화함에 따라 이러한 스토리지 시스템들은 독립적으로 성장했습니다. 이는 복잡한 이기종 스토리지 환경 (Heterogeneous storage landscape)으로 이어졌습니다.

2024년, Xiaomi가 포괄적인 AI 전략을 발표한 이후, 이전 스토리지 시스템의 단점들이 기술 선택, 액세스 (Access), 데이터 흐름 (Data flow), 그리고 개발/운영 (DevOps) 등의 영역에서 더욱 두드러지게 나타났습니다.

이러한 과제들은 다음과 같았습니다:

높은 선택 및 액세스 비용: 수많은 스토리지 시스템과 일관되지 않은 기능들로 인해, 애플리케이션 팀은 각 시스템을 이해하고 적응해야 했으며, 이는 진입 장벽을 높였습니다.
낮은 데이터 흐름 효율성: 시스템 전반에 걸친 통합된 액세스 방법의 부재로 인해 빈번한 시스템 간 데이터 복사가 발생했습니다. 이는 개발 효율성을 저해했습니다.
분산된 개발 및 운영 노력: 여러 시스템이 독립적으로 유지 관리되고 발전하면서, AI 전략에 필요한 미션 크리티컬 (Mission-critical) 인프라에 자원을 집중하기가 어려워졌습니다.

이러한 문제를 해결하기 위해 우리는 2024년에 심도 있는 내부 논의와 아키텍처 조정을 진행했으며, AI, 빅데이터, 그리고 클라우드 네이티브 (Cloud-native) 시나리오를 위한 통합 스토리지 아키텍처를 재설계하기 시작했습니다.

JuiceFS를 통한 통합 파일 기반 구축

선정 이유: 멀티 프로토콜 지원, 탄력성, 멀티 클라우드, 고성능

JuiceFS는 멀티 프로토콜 액세스, 탄력적 확장 (Elastic scaling), 그리고 고성능 읽기/쓰기를 네이티브로 지원하는 분산 파일 시스템 (Distributed file system)입니다. 이는 네이티브 AI 및 빅데이터 스토리지 요구사항 모두에 완벽하게 부합합니다.

클라우드 네이티브 (Cloud-native) 분야에서 우리는 2021년부터 JuiceFS를 사용해 왔으며, 지속적으로 내부 개발과 반복적인 최적화를 진행해 왔습니다. 동시에 JuiceFS 오픈 소스 커뮤니티와 긴밀한 협력을 유지하며 기술 진화와 실제 도입을 공동으로 추진하고 있습니다.

AI 시나리오에서 모델 학습 (Model training) 및 추론 (Inference)은 POSIX 시맨틱스 (Semantics)에 크게 의존하며, 이는 JuiceFS의 기능과 자연스럽게 일치합니다. 한편, 빅데이터 영역에서는 클라우드 마이그레이션 과정에서 이미 HDFS 교체를 추진하고 있었으며, 이는 이미 업계에서 많은 성숙한 사례가 있는 관행이었기에 HDFS 프로토콜을 적응시키는 것 또한 가능했습니다.

다중 프로토콜 지원, 탄력적 확장성 (Elastic scalability), 멀티 클라우드 (Multi-cloud) 적응성, 그리고 고성능 읽기/쓰기를 고려하여, 우리는 최종적으로 JuiceFS를 통합 파일 스토리지 기반의 핵심 구성 요소로 선택했습니다. 이를 통해 여러 플랫폼과 애플리케이션 유닛에 걸쳐 서로 다른 파일 시스템을 사용함으로써 발생했던 복잡한 데이터 흐름, 높은 액세스 비용, 분산된 운영 문제를 해결했습니다.

스토리지 계층 역량 구축

우리의 핵심 목표는 JuiceFS 위에 통합 파일 스토리지 계층을 구축하여, 대용량, 고성능 및 표준화된 액세스 인터페이스를 제공함으로써 빅데이터, 클라우드 네이티브, AI라는 세 가지 핵심 애플리케이션 시나리오를 균일하게 지원하는 것입니다.

클라이언트 측에서는 JuiceFS의 멀티 프로토콜 (multi-protocol) 역량을 최대한 활용하여 POSIX, Hadoop SDK, Python SDK 및 S3 Gateway를 포함한 액세스 방식을 제공합니다. 이 방식들은 모두 이미 내부적으로 사용되고 있습니다.

데이터 평면 (data plane)에서 아키텍처는 세 가지 계층으로 구성됩니다:

용량 계층 (Capacity layer): 퍼블릭 클라우드 (public cloud) 오브젝트 스토리지(object storage)를 기반으로 구축되었으며, EB(Exabyte) 규모의 스토리지를 위해 설계되었습니다. 서로 다른 전략적 데이터 센터 및 여러 클라우드 제공업체에 걸친 멀티 클라우드 (multi-cloud) 배포를 지원합니다.
성능 계층 (Performance layer): Ceph 및 올플래시 (all-flash) 노드를 기반으로 한 대규모 튜닝을 통해, 높은 처리량(throughput)과 낮은 지연 시간(latency) 요구 사항이 있는 AI 학습 및 기타 시나리오를 위해 설계되었습니다.
캐시 계층 (Cache layer): AI 학습 데이터셋의 “한 번 쓰고, 여러 번 읽으며, 수정은 거의 하지 않는” 특성을 고려하여, 반복적인 읽기 비용을 줄이고 학습 데이터 액세스 효율성을 높이기 위해 NVMe 및 RDMA 기반의 고성능 분산 캐시 시스템을 개발했습니다.

제어 평면 (control plane)에서는 커뮤니티 에디션 (Community Edition)에 맞춤형 개선을 수행했습니다:

메타데이터 (metadata)의 경우, 내부 인프라 시스템과 통합하고 멀티 시스템 액세스를 지원하며 신뢰성과 확장성을 향상시키기 위해 Raft 프로토콜 기반의 분산 메타데이터 서비스를 구축했습니다.
백엔드 관리의 경우, 데이터 수명 주기 관리 (lifecycle management), 계층형 스토리지 (tiered storage), 가비지 컬렉션 (garbage collection), 그리고 용량 계층에서 성능 또는 캐시 계층으로의 핫 데이터 (hot data) 웜업 (warm-up)을 담당하는 통합 관리 서비스를 구축했습니다.

이러한 노력을 통해 JuiceFS는 Xiaomi의 통합 파일 스토리지 기반으로 점진적으로 자리 잡았으며, 대규모 용량 스토리지와 AI 학습을 위한 고성능 액세스를 모두 지원하고 있습니다. 현재 이 아키텍처는 프로덕션(production) 환경에서 운영 중이며, 대규모 모델 학습에 필요한 높은 처리량(throughput)을 제공합니다.

우리의 사례 (Our practices)

통합 파일 스토리지 기반을 구축하는 동안, JuiceFS는 빅데이터, 클라우드 네이티브(cloud-native), AI를 포함한 Xiaomi의 미션 크리티컬(mission-critical) 애플리케이션 시나리오를 점진적으로 커버해 왔습니다.

규모 측면에서, 이 솔루션은 EB(Exabyte)급 스토리지와 수천억 개의 파일을 지원할 수 있습니다.
기능 측면에서, 용량(capacity), 성능(performance), 캐시(cache) 계층의 조화로운 설계는 대규모 스토리지와 고성능 사이의 균형을 맞춥니다.

아래에서는 두 가지 전형적인 시나리오인 빅데이터 클라우드 마이그레이션(migration)과 AI 스토리지 파이프라인(pipeline)에 대해 설명합니다.

빅데이터 클라우드 마이그레이션 및 통합 레이크하우스(lakehouse) 스토리지

초기 단계에서 우리의 빅데이터 시스템은 주로 Hadoop 생태계를 기반으로 구축되었으며, 여기서 HDFS는 이전 세대의 결합된(coupled) 아키텍처를 사용했습니다. 시간이 흐르면서 이 아키텍처는 성능 변동, 운영 복잡성, 높은 총 비용(TCO)과 같은 문제점을 드러냈습니다. 반면, 클라우드 스토리지(cloud storage)는 탄력적 확장(elastic scaling), 리소스 활용도, 비용 제어 측면에서 상당한 이점을 제공합니다. 따라서 2021년부터 우리는 빅데이터를 클라우드로 체계적으로 마이그레이션하기 시작했습니다.

콜드 데이터(cold data)에서 레이크하우스 계층으로

우리의 빅데이터 클라우드 마이그레이션은 세 단계를 거쳤습니다:

콜드 데이터 마이그레이션: 먼저 HDFS에서 클라우드 스토리지로 콜드 데이터를 마이그레이션했으며, 이 과정은 2년 이상 소요되었습니다.
레이크하우스 계층 마이그레이션: 스토리지와 컴퓨팅의 결합된(coupled) 구조에서 분리된(decoupled) 구조로의 진화를 촉진하기 위해 통합 레이크하우스 파일 시스템을 자체 개발했습니다.
JuiceFS 기반의 통합 스토리지 기반 구축: JuiceFS를 선택한 후, 레이크하우스 계층 전체를 JuiceFS로 마이그레이션했습니다.

레이크하우스(Lakehouse) 구축은 객체 스토리지 (Object storage) 액세스(OSS 또는 S3와 같은)에 대한 Iceberg의 네이티브 지원을 활용할 수 있습니다. 하지만 우리의 애플리케이션은 여러 클라우드 벤더를 사용하여 전 세계적으로 여러 리전에 걸쳐 있습니다. 각 벤더에 개별적으로 적응하는 것은 높은 액세스 및 유지 관리 비용을 초래할 것입니다.

따라서 우리는 서로 다른 클라우드 스토리지를 균일하게 액세스하기 위해 JuiceFS를 선택했습니다. 상위 계층 서비스는 SDK를 통해 백엔드 스토리지 주소를 단순히 전환함으로써 서로 다른 클라우드 환경의 액세스에 적응할 수 있으며, 이를 통해 멀티 클라우드(Multi-cloud)의 복잡성을 크게 줄였습니다.

데이터 마이그레이션의 경우, 우리가 자체 개발한 데이터 팩토리(Data-factory) 플랫폼은 테이블의 기반 스토리지를 새로운 아키텍처로 투명하게 전환하고, 애플리케이션에 거의 또는 전혀 영향을 주지 않으면서 기존 데이터를 백그라운드에서 클라우드로 점진적으로 마이그레이션하는 것을 지원합니다. 또한, JuiceFS는 멀티 클라우드 및 온프레미스(On-premises) 배포를 지원합니다. 향후 비용이나 전략적 고려 사항으로 인해 자체 구축 스토리지로 전환해야 하는 경우, JuiceFS를 통해 데이터를 다시 원활하게 마이그레이션할 수 있습니다. 이는 아키텍처의 유연성을 보존합니다.

컴퓨팅 효율성을 위한 핫 테이블(Hot table) 캐시 가속화

데이터가 클라우드에 배치된 후, 우리는 레이크하우스 계층의 액세스 패턴을 추가로 분석했습니다. 일일 보고 및 분석 작업의 경우, 연산은 보통 일 단위 또는 주 단위의 핫 데이터(Hot data)에 집중되며, 빈번한 전체 스캔(Full scan)을 필요로 하지 않습니다. 따라서 레이크하우스 계층의 성능 초점은 단순히 전체 스캔 처리량을 개선하는 것이 아니라, 핫 데이터 액세스 효율성과 작업 실행 안정성을 높이는 것이었습니다.

이를 바탕으로 우리는 레이크하우스 계층과 협력하여 핫 테이블 웜업(Warm-up) 기능을 구축했습니다. 시스템은 일일 액세스 통계를 기반으로 핫 테이블과 해당 핫 파티션(Hot partition)을 식별하고, 웜업 인터페이스를 통해 작업 실행 전에 관련 데이터를 캐시 계층으로 프리로드(Preload)합니다. 오전 8시까지 완료되어야 하는 정기 보고 작업의 경우, 연산 전에 핫 데이터를 웜업합니다. 이를 통해 원격 읽기(Remote reads)와 반복적인 액세스를 줄일 수 있습니다.

오프라인 및 온라인 테스트를 통해, 핫 테이블 캐싱 (hot table caching) 이후 연산 효율이 약 10-20% 향상되었으며, 연산 시간과 리소스 소비가 모두 감소했습니다. 캐시 크기는 PB 레벨에 도달했으며, 평균 처리량 (throughput)은 약 200 GB/s입니다. 또한 캐시 계층은 크로스 클라우드 (cross-cloud) 대역폭 압박과 클라우드 스토리지 API 호출 비용을 줄여줍니다. 즉, 핫 데이터 적중률 (hit rate)을 높임으로써 반복적인 크로스 클라우드 읽기를 줄일 수 있고, 이를 통해 대역폭 소비와 액세스 비용을 낮출 수 있습니다.