CubeFS

メタデータとデータを分離し、ボリュームごとにレプリカ複製とイレイジャーコーディングを選べる分散ファイル/オブジェクトストレージ。

カテゴリ: Storage & Database
CNCF 成熟度: Graduated
言語: Go
ライセンス: Apache-2.0
リポジトリ: cubefs/cubefs
ドキュメント基準コミット: 6b2e792 (master, 2026-06-22)

何をするものか

CubeFS は、同じデータを POSIX (FUSE)・S3・HDFS 互換インタフェースで公開する分散ストレージシステムです。責務を小さなロールに分割します。inode やディレクトリエントリといったメタデータは MetaNode のメモリ上に置き、ファイルの実データは DataNode 上の extent に置き、クラスタ構成は別のリソース管理ノード (Master) が追跡します。単一の cfs-server バイナリが、config の role キーに応じてこれらのいずれかのロールになります (cmd/cmd.go:184, cmd/cmd.go:206-239)。

設計上の狙いはコンテナ基盤での compute と storage の分離です。原典の SIGMOD 2019 論文は、CubeFS (当時 ChubaoFS) を JD.com の大規模コンテナ環境のバックエンドストレージとして説明しています。compute Pod はステートレスを保ち、耐久性のある状態はファイルシステム側に置きます (S7)。

ボリュームは 2 つのストレージエンジンのいずれかを選びます。multi-replica ボリュームは DataNode 間で強整合な chain 複製を使います。erasure-coded ボリュームはデータを BlobStore (blobstore/) に通し、超大規模で低コストにします。両エンジンは同じメタデータプレーンを共有します。

いつ使うか

同じデータを POSIX・S3・HDFS インタフェースで提供する 1 つのシステムが欲しいとき。
Kubernetes 上のステートフルワークロードで、ストレージを compute Pod から切り離したいとき。
メタデータ負荷が高い (小ファイルが大量、stat や list が頻繁) ワークロードで、メタデータを RAM に保持できるとき。
ホットデータにはレプリカ複製、コールドで容量重視のデータにはイレイジャーコーディングを、同一クラスタ内で使い分けたいとき。

向かないのは、小さな単一ノードで済ませたいとき、メタデータ総量が MetaNode の RAM を超えるとき、あるいはアプリが厳格な POSIX 整合性に依存するときです。CubeFS は性能のため POSIX セマンティクスを緩めています (S2)。

このディープダイブの構成

歴史: 起源・マイルストーン・存在理由。
アーキテクチャ: コンポーネントとリクエストの流れ。
採用事例・エコシステム: 誰が動かし、周囲に何があるか。
内部実装: ソースから読んだ重要なコードパス。
はじめに: インストールと最初の動く構成。

CubeFS ​

何をするものか ​

いつ使うか ​

このディープダイブの構成 ​

出典 ​

CubeFS

何をするものか

いつ使うか

このディープダイブの構成

出典