# DeepSeek의 분산 파일 시스템 3FS 소개 > Clean Markdown view of GeekNews topic #20397. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=20397](https://news.hada.io/topic?id=20397) - GeekNews Markdown: [https://news.hada.io/topic/20397.md](https://news.hada.io/topic/20397.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-04-18T09:55:29+09:00 - Updated: 2025-04-18T09:55:29+09:00 - Original source: [maknee.github.io](https://maknee.github.io/blog/2025/3FS-Performance-Journal-1/) - Points: 20 - Comments: 2 ## Summary **3FS**는 DeepSeek가 개발한 **고성능 오픈소스 분산 파일 시스템**으로, 대규모 데이터 처리와 높은 처리량을 지원합니다. **4가지 주요 구성 요소 (Meta, Mgmtd, Storage, Client)**를 통해 메타데이터 관리, 노드 관리, 실제 데이터 저장, 사용자 요청 처리 등을 분리하여 운영합니다. **CRAQ 알고리듬을 통해 강한 일관성과 장애 허용을 달성**하며, 체인 구조로 쓰기 요청을 안전하게 전파합니다. 3FS는 다른 분산 파일 시스템과 비교하여 **실제 적용 가능성과 성능 확장성에서 차별화**됩니다. ## Topic Body - **3FS는 DeepSeek가 개발한 고성능 오픈소스 분산 파일 시스템**으로, 대규모 데이터 처리와 높은 처리량을 지원함 - **일반적인 파일 시스템처럼 동작하지만**, 실제로는 여러 머신에 데이터를 분산 저장하며 사용자는 이를 의식하지 않아도 되는 추상화 구조를 가짐 - **4가지 주요 구성 요소 (Meta, Mgmtd, Storage, Client)** 를 통해 메타데이터, 노드 관리, 실제 데이터 저장, 사용자 요청 처리 등을 분리하여 운영함 - **CRAQ 알고리듬을 통해 강한 일관성과 장애 허용을 달성**하며, 체인 구조로 쓰기 요청을 안전하게 전파함 - **3FS**는 다른 분산 파일 시스템과 비교하여 **실제 적용 가능성**과 **성능 확장성**에서 차별화됨 --- ### 3FS란? - 3FS는 **Fire-Flyer File System**의 약자로, **DeepSeek**에서 공개한 **분산 파일 시스템** - DeepSeek의 오픈소스 공개 주간에 함께 릴리즈됨 - 일반적인 파일 경로처럼 보이지만, 실제로는 여러 머신에 분산 저장된 데이터를 추상화해 제공함 ### 분산 파일 시스템이란? - 사용자에게는 **로컬 파일 시스템처럼 보이지만**, 실제로는 여러 서버에 데이터를 분산 저장함 - 예: `/3fs/stage/notes.txt` 경로가 하나의 파일처럼 보이지만 실제론 여러 서버에 나뉘어 저장됨 - 사용자는 `mkdir`, `cat` 같은 명령어로 일반 파일처럼 사용할 수 있음 ### 왜 분산 파일 시스템을 사용하는가? - **대용량 데이터 (페타바이트 수준)** 와 **높은 처리량**을 지원 - **장애 허용(fault tolerance)** 과 **중복성(redundancy)** 을 통해 안정성 보장 - 실제 사용 예: - **HDFS + Spark** 같은 병렬 처리 프레임워크 - **ML 학습 파이프라인**의 체크포인팅 - Google의 **Colossus** - Meta의 사진 저장소인 **Haystack** - AI용 스토리지 예: **JuiceFS vs CephFS** ### 3FS 구성 요소 - 총 4가지 주요 노드로 구성됨 #### Meta - 파일 경로, 속성, 위치 등의 **메타데이터 관리** - RPC로 클라이언트 요청 처리 (open, stat, close 등) - 메타 정보는 **FoundationDB**에 저장됨 - `Inode`는 파일의 크기, 소유자 등의 정보를 저장 - `DirEntry`는 경로와 inode를 연결함 (심볼릭 링크처럼 하나의 파일에 여러 경로 존재 가능) #### Mgmtd - 클러스터의 **노드 등록 및 상태 확인** 담당 - 노드들은 부팅 시 자신을 등록하고 주기적으로 **하트비트 전송** - **중앙 라우터 역할**을 하며, 노드 간 연결을 직접 유지하지 않아도 됨 - CRAQ 체인 구성을 위한 설정 정보도 관리 #### Storage - 실제 데이터 저장 담당 - **Rust 기반의 ChunkEngine**을 통해 디스크 블록을 관리 - 디스크 블록의 크기, 오프셋, 체크섬, 버전 등을 추적 - 사용자는 직접 블록과 상호작용하지 않고 인터페이스 제공 - 메타 정보는 **LevelDB**에 저장 - 다양한 워커들이 존재 - `AllocateWorker`는 새 블록 할당 - `PunchHoleWorker`는 사용되지 않는 블록 회수 - `AioReadWorker`는 `io_uring` 큐를 통해 비동기 읽기 처리 - 쓰기 작업 시 CRAQ 체인을 따라 **다음 노드로 전달** #### Client - 사용자 요청을 처리하고 다른 노드와 통신 - 작업 흐름: - Mgmtd에 노드 위치 질의 - Meta에 파일 작업 요청 - Storage와 데이터 전송 ### CRAQ 알고리듬 - **Chain Replication with Apportioned Queries**의 약자로 **강한 일관성(linearizability)** 제공 - 쓰기 흐름: - Head → Middle → Tail 순으로 **쓰기 전파** - 중간 단계에서는 데이터를 **dirty**로 표시 (읽기 불가) - Tail에서 커밋 후 backward로 clean 상태 전파 - 읽기 흐름: - clean이면 즉시 반환 - dirty이면 tail에 요청하여 최신 데이터 조회 #### 성능 측면에서 CRAQ - **쓰기 속도는 가장 느린 노드에 의해 제한** - 자주 접근되는 dirty 데이터는 tail로 읽기 요청이 몰려 **읽기 병목 발생 가능** - 예: **Zipfian workload**에서 성능 저하 - 노드가 5개인 클러스터에서는 3개로 복제하여 장애 시 성능 손실 최소화 ### 다른 분산 파일 시스템과의 차이점 - 구조는 유사하지만 **현실 적용성과 구현 방식에서 차별점** 존재 - 비교 요소: - 어떤 워크로드에서 강점을 가지는지 - 성능 조절의 유연성 - 배포의 용이성 - 처리량 확장성 - SLO 내에서의 지연시간 관리 - 신뢰성 - 세부 기술 요소: - 병목 원인과 처리 방식 - 락의 유무 - 사용된 자료구조 - 타겟 하드웨어 - 사용된 **장애 허용 알고리듬** 또는 **에러 정정 방식** ### 블로그 시리즈의 다음 주제 - 실제 성능 분석을 통해 DeepSeek의 주장 검증 예정 - 검토 항목: - **FUSE 병목**에 대한 DeepSeek의 주장 - 성능 그래프 재현 가능성 - 성능 저하 상황 분석 - 병목 요소 (CPU, 메모리, 디스크, 네트워크) - 어떤 워크로드에서 성능이 우수한지 - 기존 시스템과 비교 분석 - 기존 시스템의 문제 해결 방식과의 차이 - 직접적인 개선 가능성 검토 ### 추가 자료 - 공식 [디자인 노트](https://github.com/deepseek-ai/3FS/blob/ee9a5cee0a85c64f4797bf380257350ca1becd36/docs/design_notes.md)에서 구현 방식 참고 가능 - 중국어 문서: - [시작 가이드](https://www.high-flyer.cn/blog/3fs/) - [비동기 IO](https://www.high-flyer.cn/blog/3fs-1/) - [RDMA 읽기](https://www.high-flyer.cn/blog/3fs-3/) - [네트워크 라우팅](https://www.high-flyer.cn/blog/3fs-3/) - [읽기 부하 분산](https://www.high-flyer.cn/blog/3fs-4/) - 논문 자료: [Fire-Flyer AI-HPC 아키텍처](https://arxiv.org/abs/2408.14158) ## Comments ### Comment 37341 - Author: softer - Created: 2025-04-19T18:28:49+09:00 - Points: 1 와 고민하고 있던 문제였는데 이걸 .. ### Comment 37293 - Author: neo - Created: 2025-04-18T09:55:29+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=43716058) - S3FS는 확장 가능한 메타데이터 파일 시스템으로, 다양한 분산 파일 시스템과 비교됨 - Collosus, Tectonic (Meta), ADLSv2 (Microsoft), HopsFS (Hopsworks), PolarFS (Alibaba) 등이 있음 - S3FS는 FoundationDB를 사용하고, Collosus는 BigTable, Tectonic은 KV store, HopsFS는 RonDB를 사용함 - S3FS의 중요한 점은 (1) fuse 클라이언트를 지원하여 사용이 편리하고, (2) NVMe 스토리지를 지원하여 디스크 I/O에 구애받지 않음 - HopsFS는 계층형 스토리지를 추가하여 최근 데이터는 NVMe에, 보관 데이터는 S3에 저장함 - 이 시스템들을 평가할 때 이론적 한계, 효율성, 실질적 한계를 고려해야 함 - 이론적으로는 Lustre와 같은 병렬 분산 파일 시스템이 무한대로 확장 가능함 - 효율성을 평가하기 위해 X TiB 디스크를 가진 노드로 얼마나 많은 저장소와 처리량을 얻을 수 있는지 계산함 - FSx for Lustre와 비교하여 AWS에서 3FS를 12-30% 저렴하게 운영할 수 있음 - 사람들이 원하는 배포 크기로 파일 시스템을 실제로 구성할 수 있는지에 대한 질문이 남아 있음 - DeepSeek가 자체적으로 원하는 속성을 얻기 위해 이러한 시스템을 구축하는 것이 이해됨 - Archil에서 대부분의 사람들이 거대한 클러스터를 관리하지 않고도 사용할 수 있는 더 나은 기본 설정을 찾기를 바람 - SeaweedFS와의 비교에 관심이 있음 - SeaweedFS는 날씨 데이터를 저장하는 데 사용되며, 약 3 PB의 데이터를 ML 훈련에 사용함 - CephFS를 사용하지 않는 이유에 대한 질문 - CephFS는 실세계 시나리오에서 철저히 테스트되었고, 페타바이트 규모에서도 신뢰성을 입증함 - 오픈 소스 솔루션으로, 가장 빠른 NVMe 스토리지에서 실행 가능하며, 10 기가비트 이상의 인터커넥트로 매우 높은 IOPS를 달성함 - JuiceFS와의 비교에 대한 질문 - 개인 홈랩 설정에서 S3 Garage 위에 JuiceFS를 실행할 계획임 - Garage는 복제만 지원하며, 소거 코딩이나 샤딩은 지원하지 않음 - 설정이 간단해 보여서 선택함 - 소규모 사업자 및 홈랩 사용자로서 대규모 분산 파일 시스템을 사용할 일은 없을 것 같음 - 페타바이트 규모의 데이터를 다룰 때 백업과 복구에 대한 궁금증이 있음 - 복잡한 설정이지만, 딥러닝 워크로드에 필수적인 기능은 명확하지 않음 - 필요한 기능은 페타바이트 규모의 저장소, 읽기/쓰기 병렬성, 중복성임 - 일관성을 달성하기 어려우며, 여기서는 필요하지 않음 - DeepSeek의 분산 파일 시스템을 비활성화하는 것이 얼마나 쉬운지에 대한 질문 - 예를 들어, 미국 대학이 연구를 위해 DeepSeek를 사용하도록 승인받았지만, 데이터가 로컬 연구 클러스터 파일 시스템을 벗어나지 않도록 해야 함 - 여러 기기에 분산된 ZFS 드라이브로 이를 복제할 수 있는지에 대한 질문