分散ストレージ 2026 完全ガイド — MinIO・SeaweedFS・Ceph・Garage・JuiceFS・OpenEBS・Longhorn・Rook・R2・S3 Express 徹底解説

プロローグ — 2026 年、「S3 は新しいディスクだ」

2010 年代までストレージの答えは単純だった。ブロックストレージ(SAN、iSCSI)、ファイルストレージ(NFS、SMB)、オブジェクトストレージ(S3、Swift)。 3 つのカテゴリが明確に分かれ、それぞれ別のワークロードを担当していた。

2026 年の風景はまったく違う。

• オブジェクトストレージがディスクになった。 AWS が S3 Express One Zone(単一 AZ、マイクロ秒級レイテンシ)を投入し、S3 Tables が Iceberg を一級市民に押し上げたことで、「S3 の上でデータベースを動かす」が真剣な選択肢になった。Crunchy Bridge for Analytics は Postgres のデータを S3 に置き、DuckDB は parquet on S3 を標準インターフェースとして扱う。
• ブロックストレージは CSI で抽象化された。 Kubernetes で「EBS をマウントする」は実際には「EBS CSI ドライバが PV を作る」を意味し、その場所に OpenEBS・Longhorn・Rook が入ってきた。
• egress 費用が新しいロックインになった。 Cloudflare R2 は egress 0 円を武器に S3 を脅かし、Backblaze B2 と Wasabi も同じカードを使う。AWS は S3 Standard 価格を実質凍結しながら、Express One Zone と Storage Lens で差別化を試みている。

そしてこのすべての流れの中央に MinIO がある。単一バイナリ、S3 API、どこでも同じコード。MinIO は事実上「S3 プロトコルのリファレンス実装」になった。

本稿は 2026 年 5 月時点の分散ストレージスタック全体を整理する — MinIO・SeaweedFS・Ceph・Garage・JuiceFS・OpenEBS・Longhorn・Rook・Portworx・Lightbits・DRBD・GlusterFS・HDFS・R2・B2・Wasabi・Storj・S3 Express・S3 Tables・NHN Cloud・Naver Cloud・KT Cloud・Sakura・IIJ GIO、そしてその下に敷かれる ZFS・btrfs・XFS・ext4・bcachefs・F2FS まで。

1. 分散ストレージの地図 — オブジェクト・ブロック・ファイルの三角構造

ツールを見る前に、どのカテゴリがどこに位置するかを把握する必要がある。

覚えるべき一文: 「オブジェクトストレージが新しいディスクだ。ブロックとファイルは CSI 抽象化の裏に隠れた。」

核心的な洞察はオブジェクトストレージがもう「写真を置く場所」ではないという点だ。2024 年に S3 Express One Zone が single-digit ms レイテンシを約束したことで、データベースエンジンが「WAL を S3 に書き、その上で直接クエリする」というパターンを真剣に検討し始めた。Neon・Crunchy Bridge・DuckLake・Apache Iceberg はすべてこの方向に向かっている。

2. MinIO — 単一バイナリ S3 の標準

MinIO は Go で書かれた単一バイナリのオブジェクトストレージだ。2014 年に始まり、2026 年には事実上「S3 プロトコルのリファレンス実装」になった。Kubernetes 上でも、ベアメタルでも、Raspberry Pi クラスタでも同じコードが動く。

主な特徴は S3 API 100% 互換(クライアントコードを変えずに乗り換え可能)、Erasure Coding 標準搭載(データ 4 + パリティ 2 などの構成)、単一バイナリ(依存ゼロ、30 秒インストール)、AGPL v3 ライセンス(商用は MinIO Enterprise)だ。

最も簡単な docker run から K8s Operator まで見ていこう。

# MinIO コンテナ起動 — 単一ノード、4 ディスク
docker run -d --name minio \
  -p 9000:9000 -p 9001:9001 \
  -e "MINIO_ROOT_USER=admin" \
  -e "MINIO_ROOT_PASSWORD=changeme123" \
  -v /mnt/data1:/data1 -v /mnt/data2:/data2 \
  -v /mnt/data3:/data3 -v /mnt/data4:/data4 \
  quay.io/minio/minio server /data{1...4} --console-address ":9001"

# mc(MinIO Client)でバケット作成
mc alias set local http://localhost:9000 admin changeme123
mc mb local/backups
mc cp ./backup.tar.gz local/backups/
mc ls local/backups

Kubernetes 上では MinIO Operator を使う。以下は分散 4 ノード 16 ディスククラスタのマニフェストの核となる部分。

apiVersion: minio.min.io/v2
kind: Tenant
metadata:
  name: storage-prod
  namespace: minio
spec:
  pools:
    - servers: 4
      volumesPerServer: 4
      name: pool-0
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 1Ti
          storageClassName: local-nvme
  mountPath: /export
  requestAutoCert: true
  features:
    bucketDNS: true
    domains:
      console: console.minio.example.com
      minio:
        - s3.minio.example.com

MinIO の真の強みは単純さだ。Ceph のように OSD・MON・MGR・MDS を個別に運用する必要がない。だから 2026 年に新しく S3 バックエンドを立てるときは「とりあえず MinIO」がデフォルトになった。

3. SeaweedFS — Facebook Haystack に着想を得たオブジェクトストレージ

SeaweedFS は Facebook の Haystack 論文に着想を得て作られたオブジェクトストレージだ。MinIO と同じカテゴリだが設計思想が異なる。

• Master/Volume 分離 — 小さなファイルに最適化された Volume Server。
• WebDAV・S3・FUSE ゲートウェイ — POSIX・S3・WebDAV を同時提供。
• 階層型ストレージ — Hot は SSD、Cold は HDD/S3 へ自動移動。
• Erasure Coding + Replication ハイブリッド — ホットは複製、コールドは EC。

# 単一ノード — Master + Volume + Filer + S3 ゲートウェイを一度に
weed server -dir=/data -master.port=9333 -volume.port=8080 \
  -filer -s3 -s3.port=8333

# 別マシンに Volume ノードを追加
weed volume -dir=/mnt/disk1 -mserver=master.example.com:9333 \
  -port=8080 -max=100

# S3 API でアップロード(AWS CLI そのまま)
aws --endpoint-url http://localhost:8333 s3 cp ./video.mp4 s3://media/

# FUSE マウント — POSIX のように見せる
weed mount -filer=filer.example.com:8888 -dir=/mnt/seaweed -filer.path=/

SeaweedFS は「小さなファイルが大量にある」ワークロード(画像サムネイル、ログチャンク)に特に強い。Volume Server がファイルを 1 つの大きなコンテナファイルにパッキングするので、inode 圧迫が起きない。

4. Ceph — いまだエンタープライズオンプレの標準

Ceph は 2007 年に Sage Weil の博士論文として始まり、2026 年でもなおエンタープライズオンプレストレージのデフォルトの答えだ。1 つのシステムでオブジェクト・ブロック・ファイルをすべて担う。

• RGW(Rados Gateway) — S3/Swift API。
• RBD(Rados Block Device) — 分散ブロックデバイス、QEMU/KVM が直接マウント。
• CephFS — POSIX 分散ファイルシステム。
• CRUSH アルゴリズム — 中央メタデータ無しでデータ位置を計算。

核心的真実: Ceph は強力だが運用複雑度が高い。OSD・MON・MGR・MDS・RGW をすべて気にしなければならない。だから 2018 年頃に登場した cephadm が標準となり、K8s 環境では Rook がその座を占めた。

# cephadm でブートストラップ
cephadm bootstrap --mon-ip 10.0.0.10 \
  --initial-dashboard-user admin \
  --initial-dashboard-password changeme123

# OSD 追加 — 各ノードの利用可能ディスクすべて
ceph orch host add node2 10.0.0.11
ceph orch host add node3 10.0.0.12
ceph orch apply osd --all-available-devices

# RGW デプロイ(S3 API)
ceph orch apply rgw default --placement="3 node1 node2 node3"

# プール作成 + ユーザ発行
ceph osd pool create rgw-data 256 256 erasure
radosgw-admin user create --uid=appuser --display-name="App User"

# RBD イメージ作成 + マッピング
rbd create app-disk --size 10G --pool rbd-pool
rbd map app-disk --pool rbd-pool
mkfs.xfs /dev/rbd0

5. Rook — Kubernetes 上の Ceph Operator

Rook は Ceph を Kubernetes Operator でラップしたプロジェクトだ。CNCF Graduated。一行要約: 「K8s 上で Ceph を運用する標準的方法」。Rook は CephCluster CR(custom resource)を受け取って OSD DaemonSet を作り、MON・MGR・MDS を配置する。RGW と CephFS も別の CR として定義する。

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: quay.io/ceph/ceph:v19.2.0
  dataDirHostPath: /var/lib/rook
  mon:
    count: 3
    allowMultiplePerNode: false
  mgr:
    count: 2
  dashboard:
    enabled: true
    ssl: true
  storage:
    useAllNodes: true
    useAllDevices: true
    config:
      osdsPerDevice: "1"
---
apiVersion: ceph.rook.io/v1
kind: CephFilesystem
metadata:
  name: cephfs
  namespace: rook-ceph
spec:
  metadataPool:
    replicated:
      size: 3
  dataPools:
    - name: data
      replicated:
        size: 3
  preservePoolsOnDelete: true
  metadataServer:
    activeCount: 2
    activeStandby: true

2026 年に K8s 上で分散ファイルシステムが必要になったとき、最も実績のある選択肢が Rook だ。ただし Ceph 自体の複雑さはそのまま引き継ぐことになる。

6. Garage — Deuxfleurs の軽量 S3

Garage はフランスの Deuxfleurs 協同組合が作った S3 互換オブジェクトストレージだ。「Ceph は重く、MinIO の distributed mode も重いから、もっと軽いものが必要だった」という動機から始まった。

特徴は Rust で書かれている(メモリ安全性、低リソース使用)、3 ノードから動く(家庭用 Raspberry Pi クラスタでも稼働)、S3 互換(ほとんどの S3 SDK がそのまま動く)、CRDT ベースのメタデータ(分割復旧が単純)、AGPL v3 ライセンス。

# 3 ノードクラスタのブートストラップ
garage node id  # ノード ID を表示
garage layout assign -z dc1 -c 1T <node-id-1>
garage layout assign -z dc1 -c 1T <node-id-2>
garage layout assign -z dc2 -c 1T <node-id-3>
garage layout apply --version 1

# S3 キー発行
garage key create app-key
garage bucket create photos
garage bucket allow --read --write photos --key app-key

# aws CLI をそのまま使う
aws --endpoint http://garage.example.com:3900 \
  s3 cp ./photo.jpg s3://photos/

Garage の差別化ポイントは「地理的に分散した小さなクラスタ」に最適化されている点だ。DC1-DC2-DC3 がそれぞれ家庭用回線で繋がっていても動くように設計されている。だから self-hosting コミュニティで急速に採用された。

7. JuiceFS・S3FS・Goofys — オブジェクトストレージ上の POSIX

JuiceFS はオブジェクトストレージ(S3、MinIO、R2 など)の上に POSIX ファイルシステムを載せる。メタデータは Redis・MySQL・TiKV に置き、データは S3 に置く。

JuiceFS は ML 学習データセット共有、メディア編集ワークフロー、バックアップのような「大きなファイル・読み取り中心」のワークロードに特に向く。メタデータを Redis/TiKV に置くため、メタデータ性能がオブジェクトストレージ単体より遥かに速い。

類似カテゴリに s3fs-fuse、goofys、geesefs、rclone mount があるが、POSIX セマンティクス(ハードリンク、atomic rename、fcntl lock)を正しく実装しているのは JuiceFS だけだ。他の選択肢は POSIX セマンティクスが完全でないため、バックアップ・ログ収集・メディアストリーミングのような一方向ワークロードには適するが、DB のデータディレクトリには不向きだ。

# メタデータバックエンド(Redis)+ データバックエンド(S3)でフォーマット
juicefs format \
  --storage s3 \
  --bucket https://my-bucket.s3.us-east-1.amazonaws.com \
  --access-key AKIA... \
  --secret-key SECRET... \
  redis://meta.example.com:6379/1 \
  my-jfs

# マウント
juicefs mount redis://meta.example.com:6379/1 /mnt/jfs

# 通常のファイルシステムとして使う
cp -r /home/user/dataset /mnt/jfs/datasets/
ls -la /mnt/jfs/datasets/

# 簡易な代替 — rclone で R2 をマウント
rclone mount r2:my-bucket /mnt/r2 \
  --vfs-cache-mode writes \
  --dir-cache-time 1m \
  --buffer-size 32M

8. OpenEBS — K8s ネイティブなコンテナアタッチドストレージ

OpenEBS は Kubernetes 向けに「Container Attached Storage」を標榜する。ノードローカルストレージを各種エンジンで抽象化し、PV として提供する。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mayastor-3-replicas
provisioner: io.openebs.csi-mayastor
parameters:
  repl: "3"
  protocol: nvmf
  ioTimeout: "30"
  fsType: xfs
allowVolumeExpansion: true
reclaimPolicy: Delete

Mayastor は SPDK(Storage Performance Development Kit)でカーネルバイパス IO を行う。そのため NVMe SSD の生性能の 90% 以上を PV レイヤでも引き出す。弱点は NVMe-oF target/initiator の設定が複雑な点。

9. Longhorn — Rancher の分散ブロックストレージ

Longhorn は Rancher Labs が作り、CNCF Graduated になった K8s ネイティブな分散ブロックストレージだ。SUSE 買収後も活発に開発が続いている。

• iSCSI ベース — 互換性が高い。
• per-volume controller — 各ボリュームに controller pod が立ち、隔離。
• S3/NFS へのバックアップ — スナップショット + 外部バックアップが一級機能。
• DR ボリューム — 別クラスタへの非同期レプリケーション。

apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
  name: app-data
  namespace: longhorn-system
spec:
  size: "10Gi"
  numberOfReplicas: 3
  frontend: blockdev
  staleReplicaTimeout: 30
  dataLocality: best-effort
  accessMode: rwo

運用上は Longhorn のほうが OpenEBS Mayastor より設定が楽だ。ただし生性能は Mayastor に軍配が上がる。だから「DB は Mayastor、一般アプリは Longhorn」のような構成がよくある。

10. Portworx・Lightbits・DRBD・レガシー選択肢

エンタープライズでは次の選択肢が候補に入ってくる。

• Portworx(Pure Storage 買収) — PX-Store が K8s ネイティブなブロック・ファイル、PX-Backup が K8s バックアップを担う。商用だが K8s に親和的な運用モデル。
• Lightbits Labs — NVMe-oF 専用アプライアンス。ベアメタル K8s で EBS 級性能を狙う。
• DRBD(LINBIT) — 1999 年からある「Linux の RAID over network」。2026 年でも stateful ワークロードの HA オプションとして生きている。
• GlusterFS(レガシー) — Red Hat が EOL を宣言したが、一部のレガシー環境では今も稼働中。
• Hadoop HDFS(レガシー) — ビッグデータ時代の標準だったが、オブジェクトストレージ + Iceberg の組み合わせに押されて縮小中。
• LizardFS — MooseFS の fork。POSIX 分散 FS だがコミュニティが小さい。

核心的真実: 2026 年に新規で始めるワークロードでは GlusterFS と HDFS は候補から外れる。「既存システムの保守」の領域だ。

11. AWS S3 — Standard、Express One Zone、S3 Tables

AWS S3 は 2006 年に登場し、2026 年でもオブジェクトストレージの事実上の標準だ。2024〜2026 年の間に 3 つの大きな変化があった。

1. S3 Express One Zone — 単一 AZ、ディレクトリバケット、single-digit ms レイテンシ。価格は Standard の約 7 倍だがレイテンシは 10 分の 1。データベース・ゲーム・リアルタイム分析に入る。
2. S3 Tables — Iceberg テーブルを S3 が直接ホスト。compaction・snapshot expiry を AWS が面倒を見る。Athena・EMR・Redshift Spectrum が直接クエリ。
3. S3 Storage Lens — アカウント全体のストレージ利用パターンをダッシュボードで可視化。コスト最適化の第一候補。

# 通常の Standard バケット
aws s3 mb s3://my-archive-bucket --region us-east-1

# Express One Zone ディレクトリバケット(名前が .s3express-az1--x-s3 で終わる)
aws s3api create-bucket \
  --bucket fast-bucket--use1-az4--x-s3 \
  --region us-east-1 \
  --create-bucket-configuration '{"Location":{"Type":"AvailabilityZone","Name":"use1-az4"},"Bucket":{"Type":"Directory","DataRedundancy":"SingleAvailabilityZone"}}'

# S3 Tables(Iceberg)
aws s3tables create-namespace --table-bucket-arn arn:aws:s3tables:... --namespace analytics
aws s3tables create-table --namespace analytics --name events --format ICEBERG

# Object Lock で不変バックアップを有効化
aws s3api create-bucket --bucket immutable-backups \
  --object-lock-enabled-for-bucket
aws s3api put-object-retention \
  --bucket immutable-backups \
  --key backup-2026-05-19.tar \
  --retention 'Mode=COMPLIANCE,RetainUntilDate=2026-08-19T00:00:00Z'

S3 が「ディスク」になる決定的変化は Express One Zone + S3 Tables の組み合わせだ。Crunchy Bridge for Analytics は Postgres の WAL を S3 に置き、DuckDB は parquet on S3 を一級インターフェースとして扱い、Apache Iceberg + S3 Tables はデータレイクの新標準になった。

12. Cloudflare R2 — egress 0 円時代

Cloudflare R2 は 2022 年に GA されてオブジェクトストレージ市場に単純なナイフを刺した — egress 0 円。S3 API 互換で、データを取り出すコストが GB あたり 0 ドルだ。

R2 の核心的価値は egress コストだ。動画ホスティング、写真ギャラリー、ML モデル配布のような「ダウンロードが多い」ワークロードでは S3 比 70-90% のコスト削減がよく見られる。R2 の制限はマルチリージョン一貫性と一部の S3 機能(Object Lock の一部モード、Versioning のセマンティクスの一部)だ。2025-2026 年に徐々に縮まっている。

# wrangler で R2 バケットを作成
wrangler r2 bucket create my-bucket

# S3 API エンドポイント経由で通常の S3 クライアントからアクセス
aws --endpoint https://<account-id>.r2.cloudflarestorage.com \
  s3 cp ./video.mp4 s3://my-bucket/

# rclone で S3 -> R2 同期
rclone sync s3:my-bucket r2:my-bucket \
  --transfers 32 --checkers 64 --fast-list

13. Backblaze B2・Wasabi・Storj・Filebase・Tigris

R2 が道を切り拓いたが、似たモデルのオブジェクトストレージはそれ以前にもいくつも存在した。

• Backblaze B2 — 2015 年から GB あたり 0.005 ドル台。egress は Cloudflare 経由なら 0 円(Bandwidth Alliance)。B2 Live Read で大容量メディア配信にも強い。
• Wasabi Hot Storage — egress 0 円、API 呼び出し 0 円。ただし 90 日 minimum storage の縛りあり。
• Storj DCS — 分散型ストレージ。データを 80 ノードに erasure-coded チャンクで散らす。
• Filebase — IPFS・Sia のような分散ストレージを S3 API の裏で抽象化。
• Tigris Data — DynamoDB 互換のサーバーレスオブジェクト + グローバル分散。

選び方ガイド: ほとんどダウンロードしないバックアップなら B2 が最安。ダウンロードが多いなら R2。圧縮データセットなら Storj が分散特性で適する。「S3 API 互換」が絶対要件なら Wasabi が最も忠実。

14. GCP Cloud Storage・Azure Blob — ハイパースケーラーの答え

GCP Cloud Storage と Azure Blob も S3 と同じカテゴリだが、設計が少し異なる。

GCP Cloud Storage:

• 単一のグローバルネームスペース(region/dual-region/multi-region がすべて同じ URL パターン)。
• Standard / Nearline / Coldline / Archive の 4 段階ティア。
• XML API(S3 互換)と JSON API の両方を提供。
• Lifecycle ルールで自動ティア移動。

Azure Blob:

• Hot / Cool / Cold / Archive の 4 段階ティア。
• Block Blob / Append Blob / Page Blob の 3 種類。
• ADLS Gen2(Hierarchical Namespace)で HDFS セマンティクスを提供。
• AzCopy で大規模移行。

差別化要点: GCS はグローバルネームスペースが強み、Azure Blob は ADLS Gen2 が HDFS 代替として光る。Synapse・Databricks が ADLS Gen2 を一級インターフェースとして扱う。

15. 韓国・日本のクラウドオブジェクトストレージ

地域クラウドも無視できない。

韓国:

• NHN Cloud Object Storage — S3 互換、広域マルチリージョン、ゲーム・メディアワークロードに強い。
• Naver Cloud Object Storage — S3 互換、韓国国内のデータ主権要件のある環境に適合。
• KT Cloud Object Storage — S3 互換、公共クラウド認証あり。

日本:

• Sakura Internet Object Storage — S3 互換、東京・石狩リージョン。
• IIJ GIO Object Storage — エンタープライズ SLA、日本国内データセンター。
• NTT Communications、Fujitsu Cloud — 通信系クラウド。

データ主権要件(韓国の個人情報保護法、日本の APPI)がある場合は地域クラウドが第一候補になる。S3 API 互換性のおかげでクライアントコードは endpoint を変えるだけで移行可能だ。

16. ローカルファイルシステム — ZFS、btrfs、XFS、ext4、bcachefs、F2FS

分散ストレージを敷く前に、その下に敷かれるローカルファイルシステムも重要だ。2026 年 5 月時点の候補。

ZFS の強みはスナップショットがほぼ無料な点。2024 年に bcachefs が Linux メインラインに入った。ZFS の機能(スナップショット・チェックサム・圧縮・階層キャッシュ)を GPL コードで実装。2026 年時点ではまだ「early production」だが、今後 5 年で btrfs の地位を脅かす可能性が高い。

# ZFS プール作成(mirrored)+ スナップショット + リモート送信
zpool create tank mirror /dev/sdb /dev/sdc
zfs set compression=zstd tank
zfs snapshot tank@daily-$(date +%F)
zfs send -i tank@yesterday tank@today | ssh backup-host zfs receive tank/replica

# ZFS の special vdev でメタデータを NVMe に
zpool add tank special mirror /dev/nvme0n1 /dev/nvme1n1
zfs set dedup=on tank/backups

17. CSI — Kubernetes がストレージと対話する仕組み

K8s のすべてのストレージ統合は CSI(Container Storage Interface) の上で動く。2017 年に標準化され、2026 年には事実上 K8s ストレージの唯一のインターフェースだ。

CSI ドライバは通常、以下のコンテナで構成される。

• csi-provisioner — PVC を受け取り PV を作成。
• csi-attacher — VolumeAttachment を処理。
• csi-resizer — オンラインボリューム拡張。
• csi-snapshotter — スナップショット・復元。
• node-driver-registrar — ノード登録。
• driver — 実際のストレージプロバイダごとのロジック(例: ebs.csi.aws.com、rbd.csi.ceph.com)。

ほとんどの K8s クラスタは一次的にクラウドプロバイダの CSI を使い、二次的に OpenEBS・Longhorn・Rook のいずれかを入れてベアメタルノードのローカルディスクも PV にする。

18. Object Lock・WORM・不変バックアップパラダイム

2020 年代中盤からランサムウェア攻撃が急増し、バックアップのデフォルトが「不変(immutable)」に移った。Object Lock と WORM(Write Once Read Many)モードが中核。

• AWS S3 Object Lock — Governance モードと Compliance モード。Compliance は root ユーザでも削除できない。
• MinIO Object Lock — S3 互換。
• Ceph RGW Object Lock — Reef リリース以降サポート。
• R2 Object Lock — 2024 年 GA。

このパラダイムを活用するバックアップベンダが Veeam・Rubrik・Cohesity・Druva だ。彼らの標準ワークフローはすべて「MinIO または S3 に immutable backup を書く」だ。アクティブデータは hot(NVMe)、コールドは HDD/Tape へ自動階層化するパターンもセットで標準化された。

19. データ階層化・Dedup・ライフサイクル・マルチクラウド複製

保存コストを下げてデータの耐久性を上げる自動化パターン。

1. ライフサイクルルール — N 日後にコールドティアへ、M 日後にアーカイブへ、K 日後に削除。S3 Lifecycle、GCS Lifecycle、Azure Blob Management Policy はすべて同じパターン。
2. データ階層化 — アクティブデータは hot(NVMe)、コールドは HDD/Tape。ZFS の special vdev、OpenZFS の ARC/L2ARC、SeaweedFS の階層型ストレージがこのパターン。
3. データ重複排除(Dedup) — ZFS dedup、Veeam 標準の dedup、NetApp ONTAP ボリューム dedup。バックアップワークロードでは 5-30 倍の削減がよくある。
4. マルチクラウド複製 — MinIO Mirror Mode、rclone sync、AWS S3 Replication(Cross-Region、Cross-Account)、GCS Object Replication、R2 to S3 via Workers。

核心的真実: 2026 年の節約は「どうやってコールドデータを自動でコールドティアに移すか」の自動化から生まれる。S3 Standard にすべて置けば高く、すべて Glacier に置けば復旧が遅い。さらに cross-region replication はデータ転送費用が高いため、コストの罠に注意する必要がある。

20. 「S3 は新しいディスクだ」 — Iceberg・DuckDB・Postgres on S3

2024-2026 年の最大のパラダイム転換。データベースが S3 の上で直接動く時代。

• Apache Iceberg + S3 Tables — トランザクション付きのテーブルフォーマットが S3 に直接住む。Athena・EMR・Trino・Spark・Snowflake が直接クエリ。
• DuckDB + parquet on S3 — read_parquet('s3://...') が一級市民。ローカル分析が S3 データをそのまま見る。
• Crunchy Bridge for Analytics — Postgres データを S3 に置き、FDW(Foreign Data Wrapper)でクエリ。
• Neon、DuckLake — WAL/checkpoint を S3 に置き「stateless DB」を実装。
• MotherDuck — DuckDB の SaaS 版、ローカル・クラウドハイブリッド。

DuckDB では INSTALL httpfs; LOAD httpfs; の後に SET s3_region='us-east-1' とアクセスキーを設定すれば、read_parquet('s3://bucket/events/year=2026/*.parquet') のようなクエリが一級市民として動く。ETL なしに S3 上の parquet をそのまま分析する。

このパターンの結果: 「伝統的 DBMS のストレージレイヤ」と「オブジェクトストレージ」の境界が消えつつある。NVMe Flash Array(Pure Storage、NetApp ONTAP、Dell PowerStore)ベンダは「我々の NVMe アレイの前段に S3 オブジェクトインターフェースを置く」という答えで対応中だ。

21. NVMe Flash Array ベンダ — Pure・NetApp・Dell PowerStore

エンタープライズハードウェア側の 2026 年の答えは NVMe Flash Array だ。

• Pure Storage FlashArray //X・//XL — 全 NVMe、インライン dedup・圧縮。Portworx 買収で K8s ストレージまで統合。
• NetApp ONTAP AFF(All-Flash FAS) — ONTAP 9.14 以降は S3 オブジェクトインターフェースを一級機能として提供。SnapMirror・SnapVault は依然として差別化要因。
• Dell PowerStore — Dell の NVMe-oF アレイ。Container Storage Module で K8s CSI を提供。
• HPE Alletra — HPE Nimble Storage の後継。AI ベースの予測分析。
• VAST Data — DASE(Disaggregated Shared-Everything)アーキテクチャ。AI 学習データセットに強み。

核心的真実: 2026 年のエンタープライズストレージは「Pure/NetApp/Dell/HPE のいずれか」+「K8s CSI ドライバ」+「S3 オブジェクトインターフェース」の 3 つをすべて揃えてはじめて採用候補に入る。

22. 運用チェックリスト — 分散ストレージを敷く前に

新規に敷く際にチェックすべき項目。

• RPO/RTO の定義 — データ損失の許容時間(RPO)、復旧時間(RTO)を先に合意。
• 3-2-1 バックアップルール — データを 3 コピー、2 種の異なるメディア、1 つはオフサイト。
• Object Lock の有効化 — バックアップバケットは必ず immutable に。
• 暗号化 — 保管時(SSE-S3/SSE-KMS)と通信時(TLS)の両方。
• モニタリング — Prometheus + Grafana で IOPS・スループット・レイテンシ・エラーレート。
• バックアップ復旧リハーサル — 四半期に 1 回。バックアップがあることではなく、復旧できることを確認する。
• コストアラート — 突然の egress コスト急増は通常セキュリティ事故のサイン。
• CSI ドライバのバージョン管理 — K8s マイナーバージョンアップグレード時の互換性確認。
• メタデータバックアップを別途 — JuiceFS・Ceph のメタデータはデータと別にバックアップ。

核心的教訓: 分散ストレージの障害は通常、ディスク故障ではなく「メタデータバックアップが無かった」「復旧を一度も試したことがなかった」から起きる。

23. 意思決定マトリックス — いつ何を使うか

24. 2026 年以降を見通す

• オブジェクトストレージのディスク化の加速 — Iceberg・DuckLake・Neon が標準化されれば「DB はすなわち S3 クライアント」がデフォルトのメンタルモデルになる。
• egress 戦争の決着 — Cloudflare R2 が S3 からシェアを奪う流れは止まらず、AWS は結局何らかの形で egress 値下げカードを切ることになる。
• K8s ストレージの統合 — OpenEBS・Longhorn・Rook のうち 2 つが合併するか、1 つの標準に収束する可能性がある。
• NVMe-oF の一般化 — Mayastor・Lightbits が牽引する NVMe-oF が「K8s で RDMA 級性能」の標準的な答えになる。
• bcachefs の台頭 — メインライン入り後の 5 年で btrfs を脅かす。ZFS はライセンス問題で依然 copyleft 外で強い。
• AI ワークロードのストレージ要件 — 学習データセット共有(JuiceFS・Alluxio)、チェックポイント保存(S3 Express)、モデル配布(R2)が別カテゴリとして浮上する。

2026 年に分散ストレージを選ぶときに最も重要な問いは、もはや「どのバックエンドを使うか」ではない。「どの API 互換性を保ちながら、どのコスト曲線を描くか」 だ。そしてその答えのほとんどは S3 API と CSI に行き着く。

References

• MinIO 公式ドキュメント — https://min.io/docs
• SeaweedFS — https://seaweedfs.github.io
• Ceph — https://docs.ceph.com, https://ceph.io
• Garage by Deuxfleurs — https://garagehq.deuxfleurs.fr
• JuiceFS — https://juicefs.com, https://github.com/juicedata/juicefs
• OpenEBS — https://openebs.io, https://github.com/openebs/openebs
• Longhorn — https://longhorn.io
• Rook — https://rook.io, https://github.com/rook/rook
• Portworx (Pure Storage) — https://portworx.com
• Lightbits Labs — https://www.lightbitslabs.com
• DRBD (LINBIT) — https://linbit.com/drbd
• Cloudflare R2 — https://www.cloudflare.com/products/r2
• Backblaze B2 — https://www.backblaze.com/cloud-storage
• Wasabi Hot Cloud Storage — https://wasabi.com
• Storj DCS — https://www.storj.io
• Filebase — https://filebase.com
• Tigris Data — https://www.tigrisdata.com
• AWS S3 — https://aws.amazon.com/s3, S3 Express One Zone, S3 Tables
• GCP Cloud Storage — https://cloud.google.com/storage
• Azure Blob Storage — https://learn.microsoft.com/azure/storage/blobs
• NHN Cloud Object Storage — https://www.nhncloud.com/kr/service/storage/object-storage
• Naver Cloud Object Storage — https://www.ncloud.com
• KT Cloud Object Storage — https://cloud.kt.com
• Sakura Internet Object Storage — https://manual.sakura.ad.jp/cloud/objectstorage
• IIJ GIO Object Storage — https://www.iij.ad.jp/biz/gio
• OpenZFS — https://openzfs.github.io
• bcachefs — https://bcachefs.org
• Kubernetes CSI — https://kubernetes-csi.github.io/docs
• Apache Iceberg — https://iceberg.apache.org
• DuckDB — https://duckdb.org
• Veeam — https://www.veeam.com, Rubrik — https://www.rubrik.com, Cohesity — https://www.cohesity.com, Druva — https://www.druva.com