▲

DeepSeek의 분산 파일 시스템 3FS 소개

 (maknee.github.io)
17P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • 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, 메모리, 디스크, 네트워크)
    • 어떤 워크로드에서 성능이 우수한지
    • 기존 시스템과 비교 분석
    • 기존 시스템의 문제 해결 방식과의 차이
    • 직접적인 개선 가능성 검토

추가 자료

▲
softer 8시간전  [-]

와 고민하고 있던 문제였는데 이걸 ..

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 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 드라이브로 이를 복제할 수 있는지에 대한 질문

답변달기