DeepSeekの分散ファイルシステム3FSの紹介

(maknee.github.io)

20 ポイント投稿者 GN⁺ 2025-04-18 | 2件のコメント | WhatsAppで共有

3FSはDeepSeekが開発した高性能なオープンソース分散ファイルシステムで、大規模データ処理と高スループットをサポートする
一般的なファイルシステムのように動作するが、実際には複数のマシンにデータを分散保存しており、ユーザーはそれを意識しなくてよい抽象化構造を持つ
4つの主要コンポーネント（Meta、Mgmtd、Storage、Client） により、メタデータ、ノード管理、実データ保存、ユーザー要求処理などを分離して運用する
CRAQアルゴリズムによって強い一貫性と耐障害性を実現し、チェーン構造で書き込み要求を安全に伝播する
3FSは他の分散ファイルシステムと比較して、実運用への適用可能性と性能のスケーラビリティで差別化されている

3FSとは？

3FSはFire-Flyer File Systemの略で、DeepSeekが公開した分散ファイルシステム
DeepSeekのオープンソース公開週間にあわせてリリースされた
一般的なファイルパスのように見えるが、実際には複数マシンに分散保存されたデータを抽象化して提供する

分散ファイルシステムとは？

ユーザーにはローカルファイルシステムのように見えるが、実際には複数のサーバーにデータを分散保存する
例: /3fs/stage/notes.txt というパスは1つのファイルのように見えるが、実際には複数のサーバーに分かれて保存されている
ユーザーはmkdir、catのようなコマンドで通常のファイルのように利用できる

なぜ分散ファイルシステムを使うのか？

大容量データ（ペタバイト級） と 高スループット をサポート
耐障害性（fault tolerance） と 冗長性（redundancy） により安定性を保証
実際の利用例:
- HDFS + Spark のような並列処理フレームワーク
- ML学習パイプラインのチェックポイント
- GoogleのColossus
- Metaの写真ストレージであるHaystack
- AI向けストレージの例: JuiceFS vs CephFS

3FSの構成要素

合計4種類の主要ノードで構成される

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でコミット後、逆方向にclean状態を伝播
読み取りの流れ:
- cleanなら即時返却
- dirtyならtailに要求して最新データを取得

性能面で見たCRAQ

書き込み速度は最も遅いノードに制約される
頻繁にアクセスされるdirtyデータではtailに読み取り要求が集中し、読み取りボトルネックが発生する可能性 がある
例: Zipfian workloadで性能低下
ノード数5のクラスターでは3つにレプリケーションし、障害時の性能損失を最小化する

他の分散ファイルシステムとの違い

構造は似ているが、実運用への適用性と実装方式に差別化要素がある
比較項目:
- どのワークロードで強みを持つか
- 性能調整の柔軟性
- デプロイのしやすさ
- スループットのスケーラビリティ
- SLO内でのレイテンシ管理
- 信頼性
詳細な技術要素:
- ボトルネックの原因と対処方法
- ロックの有無
- 使用されているデータ構造
- 対象ハードウェア
- 使用されている耐障害アルゴリズムまたは誤り訂正方式

ブログシリーズの次のテーマ

実際の性能分析を通じてDeepSeekの主張を検証する予定
検討項目:
- FUSEボトルネックに関するDeepSeekの主張
- 性能グラフの再現可能性
- 性能低下が起きる状況の分析
- ボトルネック要素（CPU、メモリ、ディスク、ネットワーク）
- どのワークロードで性能が優れているか
- 既存システムとの比較分析
- 既存システムの問題解決手法との違い
- 直接的な改善可能性の検討

追加資料

2件のコメント

softer 2025-04-19

自分も悩んでいた問題だったのですが、これを..

GN⁺ 2025-04-18

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ドライブでこれを再現できるかという質問

DeepSeekの分散ファイルシステム3FSの紹介

3FSとは？

分散ファイルシステムとは？

なぜ分散ファイルシステムを使うのか？

3FSの構成要素

Meta

Mgmtd

Storage

Client

CRAQアルゴリズム

性能面で見たCRAQ

他の分散ファイルシステムとの違い

ブログシリーズの次のテーマ

追加資料

関連記事

2件のコメント

Hacker Newsの意見