ブロック・ファイル・オブジェクトストレージのデータアクセス方式
1. 概要
A. 定義
データを格納・アクセスする最小単位（Unit of Access）とインタフェースに応じて、ストレージをブロック（Block）・ファイル（File）・オブジェクト（Object）に区分する。それぞれアクセス方式・拡張性・用途が異なる。
三方式の本質的な違いは「誰がデータをどの単位で扱うか」にある。ブロックは、ファイルシステムという構造をストレージ側が提供せず、生（raw）のブロックのみを公開し、上位のOSが直接構造を載せる。ファイルは、ストレージがすでにファイルシステムを持ち、パス・階層を提供する。オブジェクトは階層構造そのものを捨て、固有IDとメタデータでオブジェクトを丸ごと扱う。この「抽象化レベルの違い」が、性能・拡張性・共有性の違いを生む。
B. 登場背景および必要性
当初はサーバに直接接続するブロックストレージ（DAS）しかなかったが、複数ユーザがファイルを共有する要求が高まるにつれてファイルストレージ（NAS）が、続いてWeb規模の非構造化データ（写真・ログ・バックアップ）を事実上無限に保存する要求が高まるにつれてオブジェクトストレージが登場した。すなわち三方式は優劣の関係ではなく、ワークロード特性（性能・共有・拡張・コスト）に合わせて選択する対象である。データベースのように低遅延が生命線のワークロード、チームで文書を共同編集するワークロード、ペタバイト級のメディアを安価に蓄積するワークロードは、それぞれ異なるアクセス単位を必要とする。
2. アクセス方式の比較
flowchart TB
B[ブロックストレージ<br/>ブロック単位・SAN]
F[ファイルストレージ<br/>ファイル/ディレクトリ・NAS]
O[オブジェクトストレージ<br/>オブジェクト+メタデータ・HTTP]
アクセス単位が大きくなるほど（ブロック→ファイル→オブジェクト）、個々のリクエストが持つ文脈は豊かになるが、その分オーバーヘッドが大きくなって遅延が増える。逆に構造的な結合が緩やかになり、水平拡張は容易になる。下表の性能・拡張性の違いは、すべてこの原理から派生する。
| 区分 | ブロック | ファイル | オブジェクト |
|---|---|---|---|
| アクセス単位 | 固定サイズブロック（LBA） | ファイル（パス/階層） | オブジェクト（固有ID+メタデータ） |
| インタフェース | iSCSI・FC（SAN） | NFS・SMB（NAS） | REST API（HTTP） |
| 構造 | 論理ボリューム | 階層型ディレクトリ | フラット（Flat）な名前空間 |
| 性能 | 最高（低遅延） | 中間 | 相対的に低い（高遅延） |
| 拡張性 | 限定的 | 中間 | 非常に高い（無限拡張） |
| 用途 | DB・VM・トランザクション | ファイル共有・コラボレーション | バックアップ・アーカイブ・メディア・ビッグデータ |
3. 類型別特徴の詳細
A. ブロックストレージ
ブロックストレージは、ディスクをLBA（Logical Block Address）で指定される固定サイズブロックの配列としてのみ提供する。ファイルという概念もディレクトリもストレージ層には存在せず、それをどう使うかは全面的に上位OSのファイルシステム（ext4・NTFSなど）やDBMSが決定する。このようにストレージが最小限の仕事しかしないため、付加処理が少なく遅延が最も低く、任意位置の読み書き（ランダムI/O）に強い。その代わり、一つのブロックボリュームは原則として一台のホストにマウントされるため、同時共有が難しい。iSCSI・FCベースのSANで接続し、データベースのデータファイルや仮想マシンのブートディスクのように、低遅延とトランザクション整合性が必要な用途に使う。
B. ファイルストレージ
ファイルストレージは、ストレージ装置自体がファイルシステムを持ち、パス（例: /home/user/report.docx）とディレクトリ階層を通じてアクセスさせる。NFS・SMBプロトコルでネットワークに公開（NAS）するため、複数のクライアントが同じファイルシステムを同時にマウントして共有・協働でき、POSIXのファイル権限・ロックをそのまま活用できる。階層構造を探索するオーバーヘッドとネットワークファイルプロトコルの処理のため、ブロックより遅延が大きく、ディレクトリが深くファイル数が数億に増えるとメタデータ管理の負担で拡張に限界が生じる。部署の共有フォルダ、開発ソースの共有、メディア編集の協働などに適している。
C. オブジェクトストレージ
オブジェクトストレージは階層構造を捨て、データを固有識別子（キー）でアクセスするオブジェクト単位で扱う。各オブジェクトはデータ本体＋ユーザ定義のメタデータ＋固有IDで構成され、フラット（flat）な名前空間に格納される。ディレクトリツリーを維持・探索する必要がないため水平拡張が事実上無限であり、ノードを増やすだけでペタバイト級まで拡張できる。アクセスはHTTPベースのREST API（GET/PUT）で行い、ファイルの一部だけを修正するのではなくオブジェクト単位で丸ごと書き込む。リクエストごとにHTTP・メタデータ処理のオーバーヘッドがあるため遅延は最も大きいが、大容量・非構造化・読み取り中心のデータ（バックアップ、ログ、画像・動画、データレイク）には、低コスト・高耐久性の点で最適である。AWS S3が代表例であり、複数のデータセンターに自動複製して99.999999999%（11 nines）級の耐久性を提供する。
4. 選択基準
アクセス単位の原理を理解すれば、選択は自然に導かれる。低遅延・ランダムI/Oが必要ならブロック、同時共有・POSIXセマンティクスが必要ならファイル、大規模・非構造化・低コストな拡張が必要ならオブジェクトである。
| 要求 | 適合 | 理由 |
|---|---|---|
| 高性能トランザクション（DB・VM） | ブロック | 最小オーバーヘッド・低遅延・ランダムI/O |
| マルチユーザのファイル共有 | ファイル | ファイルシステム・POSIX共有を標準提供 |
| 大規模非構造化・アーカイブ | オブジェクト | 無限拡張・メタデータ・低コスト |
5. 考慮事項および示唆点
クラウドはこの三方式をそれぞれEBS（ブロック）・EFS（ファイル）・S3（オブジェクト）として提供しており、実務では一つだけを使うよりも、ワークロードごとに混在（ハイブリッド）させるのが一般的である。例えば、アプリケーションサーバのDBはブロック、チームの共有資料はファイル、ユーザのアップロード・バックアップはオブジェクトに置く。オブジェクトストレージは、オブジェクトの不変性（WORM）・バージョン管理・ライフサイクルポリシー（Lifecycle）により古いデータを低コスト階層（コールド/アーカイブ）へ自動移動させ、コストを最適化できるという点が技術士の観点からの核心である。ただしオブジェクトは部分修正や強いトランザクション一貫性に弱いため、「安く大量に蓄積するが、頻繁には書き換えない」データに限定して適用すべきである。
一言まとめ: ブロックはブロック単位（SAN）で高性能なDB・VM、ファイルはファイル単位（NAS）で共有、オブジェクトはオブジェクト+メタデータ（HTTP）で大規模アーカイブに適しており、アクセス単位が大きくなるほど遅延は増え拡張性は向上するというトレードオフが、インタフェース・用途の違いを生む。