# 分散ファイルシステムとオブジェクトストア ## 定義 分散ファイルシステム(DFS)とオブジェクトストアは、バッチ処理の入出力を保持するストレージ層である。DFSはファイルをブロック単位に分割し複数マシン(データノード)へ分散配置する点で、単一マシンのファイルシステム(ext4・XFS等)と同じ設計を踏襲するが、ブロックサイズがはるかに大きい(ext4の4,096バイトに対し、HDFSは128MB、JuiceFSや多くのオブジェクトストアは4MB)。大きなブロックはペタバイト級データセットでのメタデータ管理コストとシーク時のオーバーヘッドを下げる。オブジェクトストア(Amazon S3、Google Cloud Storage、Azure Blob Storage等)はDFSの代替として普及しており、両者の境界は曖昧になりつつある。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]] "Distributed Filesystems", "Object Stores") ## 分散ファイルシステムの構成要素 - **データノード**: 各マシンで稼働するデーモンで、リモートプロセスからのブロック読み書き要求を受け付ける(HDFSはDataNode、GlusterFSはglusterfsdと呼ぶ)。 - **分散ページキャッシュ**: DFSブロックはデータノードのローカルファイルとして保存されるため、各データノードのOSページキャッシュを通じて頻繁に読まれるブロックがメモリ上に保持される。JuiceFSのようにクライアント側・ローカルディスクキャッシュを追加実装するものもある。 - **メタデータサービス**: ファイル配置・権限等を追跡する(HadoopのNameNode、DeepSeekの3FSはFoundationDBのようなKVSにメタデータを永続化)。 - **プロトコル層**: OSのVFSに相当する層で、DFSがブロック処理系を抽象化してバッチ処理システムへ公開する。S3のAPIはMinIO・Cloudflare R2・Tigris・Backblaze B2など多数のストレージ製品に採用され、事実上の標準プロトコルになっている。POSIX準拠のDFSはFUSEやNFSでVFSへ統合される。 - **レプリケーションと耐障害性**: コモディティハードウェアの高い故障率に対応するため、ファイルブロックは複数マシンへ複製されるか、Reed–Solomon符号のようなイレイジャーコーディングで低ストレージオーバーヘッドの冗長性を持つ。単一マシン内のRAIDと似た手法だが、特殊ハードウェアなしにデータセンターネットワーク越しに行われる点が異なる。 (Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]] "Distributed Filesystems") ## オブジェクトストアの特性 オブジェクトはバケット名とキー(例: `s3://my-photo-bucket/2025/04/01/birthday.png`)で一意に識別され、`get`/`put`で読み書きする。書き込み後は不変で、更新には全体書き換えが必要(Azure Blob StorageとS3 Express One Zoneはアペンドをサポート)。ディレクトリの概念がなく、パス構造はキーの一部にすぎないため、ディレクトリ一覧はプレフィックス検索で近似される。空ディレクトリを表現できない、リンク・ロックが未対応、リネームが非アトミック(コピー後に削除)という制約がDFSとの主な差である。オブジェクトストアは計算とストレージを分離する設計を取ることが多く、DFS(HDFS等)がタスクをデータを保持するマシン上で実行してネットワーク帯域を節約できるのに対し、オブジェクトストアはCPU/メモリをストレージと独立にスケールできる利点と引き換えにネットワーク帯域を要する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]] "Object Stores") ## 横断的知見 - **タブレット指向の構造化分散ストレージ(Bigtable系)とブロック指向の分散ファイルストレージ(DFS/オブジェクトストア)は、同じ「コモディティサーバへのデータ分散」という課題を異なるデータ単位で解く姉妹関係にある**: [[分散ストレージ]]が扱うBigtableは多次元疎マップをタブレット単位で分割・配置するのに対し、本概念が扱うDFS/オブジェクトストアはファイルを固定サイズブロック(HDFS 128MB等)またはキー付きオブジェクト単位で分散配置する。いずれもメタデータサービスによる位置管理(BigtableのChubby+階層的位置特定、HDFSのNameNode、3FSのFoundationDB)とレプリケーションによる耐障害性という共通の設計要素を持ちながら、Bigtableが構造化データへのランダムアクセス(単一行ACID)を志向するのに対し、DFS/オブジェクトストアはバッチ処理向けの大きな逐次読み書き(メガバイト〜ギガバイト単位)に最適化される。両者は「分散ストレージ」という同じ問題領域に対する、アクセスパターンの異なる2つの解と位置づけられる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]], [[分散ストレージ]]) ## 未解決の問い - HDFSのようなDFSが提供する「タスクをデータの近くで実行する」局所性最適化は、オブジェクトストアが主流になった現在どの程度重要であり続けているか。本章は「現代のデータセンターネットワークは十分高速なのでオブジェクトストアの帯域コストは許容範囲」と述べるにとどまる。 - イレイジャーコーディングとフルレプリケーションのストレージオーバーヘッド・読み取りレイテンシのトレードオフは、具体的にどの条件でどちらが有利になるか(本章は概念のみ紹介し定量比較は示さない)。 - JuiceFSやCephのようにDFS/オブジェクトストア両方のAPIを提供する実装で、一貫性保証や性能特性がAPIによってどう異なるか(本章は「注意が必要」と述べるにとどまり詳細は示さない)。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]] - 概念: [[分散ストレージ]](構造化データ向けの姉妹概念) / [[MapReduce]](DFS/オブジェクトストアを入出力に使う代表的ワークロード) / [[RAID]](単一マシン内の類似冗長化技術) - 書籍: [[Designing Data-Intensive Applications 2nd Edition]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]]("Distributed Filesystems"・"Object Stores" 節)