Rook-Ceph・Longhorn・OpenEBSで学ぶクラウドネイティブストレージ実践ガイド2026

この記事でわかること

• Kubernetes上の永続ストレージの基本概念（PV/PVC/CSI）とその仕組み
• Rook-Ceph・Longhorn・OpenEBS Mayastorの3大OSSストレージのIOPS・スループット・レイテンシ比較
• 各ストレージソリューションのHelm/Operatorによるデプロイ手順と設定例
• AI/MLワークロード向けストレージアーキテクチャとGPUDirect Storageの役割
• NVMe/TCPやコンピュート・ストレージ分離など2026年の最新トレンド

対象読者

• 想定読者: Kubernetesの基本操作を理解しているMLエンジニア・インフラエンジニア
• 必要な前提知識:
  • kubectl の基本コマンド操作
  • Kubernetes Podの概念（Deployment / StatefulSet）
  • Linuxのファイルシステム・ブロックデバイスの基礎概念
  • Helmチャートの基本的な使い方

結論・成果

クラウドネイティブストレージの選定により、Kubernetes上のステートフルワークロードの運用効率と性能は大きく変わります。ベンチマーク調査によると、OpenEBS Mayastorはランダム読み取りで45,000〜60,000 IOPSを達成し、Rook-Cephの25,000〜35,000 IOPSやLonghornの15,000〜20,000 IOPSと比較して性能面で有利です（onidel.com ベンチマーク記事による測定結果）。一方、運用コストの面ではLonghornが1ノードあたりメモリ200〜400MBと軽量で、Helm一発デプロイの手軽さで中小規模クラスタに適しています。本記事では、これら3つのOSSストレージソリューションをベンチマーク数値・運用負荷・ユースケースの観点で比較し、ワークロードに応じた選定基準を提示します。

Kubernetesストレージの基礎を理解する

クラウドネイティブストレージを選定する前に、Kubernetesがストレージをどう抽象化しているかを理解しておきましょう。ここでは、MLエンジニアの視点から「なぜPodにストレージが必要なのか」を整理します。

PersistentVolume（PV）とPersistentVolumeClaim（PVC）の役割

Kubernetesでは、ストレージリソースをPersistentVolume（PV）として定義し、Podからの要求をPersistentVolumeClaim（PVC）として管理します。Pythonのクラス設計に例えると、PVがストレージの「実装クラス」、PVCがアプリケーション側の「インターフェース」に相当します。

# pvc-example.yaml
# MLモデルの学習データを永続化するためのPVC定義例
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: training-data-pvc
  namespace: ml-workloads
spec:
  accessModes:
    - ReadWriteOnce      # 単一ノードからの読み書き
  storageClassName: rook-ceph-block  # ← ストレージバックエンドを指定
  resources:
    requests:
      storage: 100Gi     # 100GBのストレージを要求

なぜこの設計か:

• PVCを使うことで、アプリケーション側はストレージの実装詳細（Cephなのか、Longhornなのか）を意識しなくてよい
• storageClassName を変更するだけでバックエンドを切り替えられるため、開発環境と本番環境で異なるストレージを使い分けられる

注意: ReadWriteOnce（RWO）は最も一般的なアクセスモードですが、複数Podから同時に読み書きする場合は ReadWriteMany（RWX）が必要です。RWXをサポートするストレージソリューションは限られるため、要件に応じて選定してください。

CSI（Container Storage Interface）の仕組み

CSI（Container Storage Interface）は、Kubernetesとストレージプロバイダを接続する標準インターフェースです。MLフレームワークで例えると、PyTorchのDataLoaderがデータソースの種類を意識せずにデータを供給するのと同様に、CSIドライバがストレージの種類を抽象化してKubernetesにボリュームを供給します。

2025年時点で、60%以上のKubernetesユーザーがCSIドライバを採用しており、2022年の45%から大幅に増加しています（CNCF Annual Surveyによる）。

CSIドライバは動的プロビジョニングをサポートしており、PVCを作成するだけで自動的にPVが生成されます。管理者が事前にPVを用意する必要がなく、セルフサービスでストレージを利用できます。

3大OSSストレージソリューションを比較する

ここからは、CNCFエコシステムで広く採用されている3つのOSSストレージソリューション——Rook-Ceph、Longhorn、OpenEBS Mayastor——を、性能・運用性・機能の観点から比較していきます。

Rook-Ceph: エンタープライズ級の統合ストレージ

RookはCNCF Graduatedプロジェクトで、分散ストレージシステムCephをKubernetes上で自動運用するためのオーケストレーターです。CNCFのストレージカテゴリでGraduatedステータスを持つ唯一のプロジェクトであり、本番環境での実績が最も豊富です（CNCF Graduated Projects）。

Cephの特徴は、1つのクラスタでブロック（RBD）、ファイルシステム（CephFS）、オブジェクト（S3互換のRGW）の3種類のストレージを統合提供できることです。

# rook-ceph-cluster.yaml
# Rook-Cephクラスタの最小構成例（Helm values）
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: quay.io/ceph/ceph:v19.2  # Squid（2025年LTS）
  dataDirHostPath: /var/lib/rook
  mon:
    count: 3                         # モニタ3台（過半数合意で可用性確保）
    allowMultiplePerNode: false
  storage:
    useAllNodes: true
    useAllDevices: false
    devices:
      - name: "sdb"                  # ← 専用ディスクを指定
  resources:
    osd:
      requests:
        cpu: "500m"
        memory: "2Gi"               # OSD1台あたり2GB推奨

なぜRook-Cephを選ぶか:

• ブロック・ファイル・オブジェクトを1つのプラットフォームで管理できるため、ストレージ基盤の統一が可能
• 10年以上の本番運用実績があり、Red Hatが商用サポートを提供
• ペタバイト級のスケールアウトに対応

注意点:

Rook-CephはOSD・CRUSH MAP・Placement Groupなど、Ceph固有の概念の理解が必要です。ノードあたりのメモリ消費は1〜2GBと他のソリューションより大きく、小規模クラスタ（3ノード未満）ではオーバーヘッドが目立ちます。3ノード以上のクラスタでの使用を推奨します。

Longhorn: シンプルさを追求したブロックストレージ

LonghornはSUSE/Rancher社が開発し、CNCFでIncubatingステータスのブロックストレージです（Longhorn公式サイト）。Helmコマンド1つでデプロイできる手軽さが特徴で、k3sやエッジ環境で広く採用されています。

# Longhornのデプロイ（Helm 3行で完了）
helm repo add longhorn https://charts.longhorn.io
helm repo update
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultReplicaCount=2  # レプリカ数（デフォルト3）

LonghornのWeb UIにアクセスすると、ボリュームの状態・レプリカの配置・バックアップ状況をブラウザから確認できます。

# longhorn-storageclass.yaml
# Longhornのカスタムストレージクラス定義
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-fast
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "2"          # レプリカ2（性能重視時）
  staleReplicaTimeout: "2880"    # 48時間後にstaleレプリカを削除
  fromBackup: ""
  fsType: "ext4"
reclaimPolicy: Delete
volumeBindingMode: Immediate

なぜLonghornを選ぶか:

• Helmワンコマンドでデプロイ完了、GUIで直感的に管理できる
• S3互換ストレージへの増分バックアップを標準サポート
• ARM対応でRaspberry Pi / エッジデバイスでも動作

注意点:

Longhornはブロックストレージのみ提供し、オブジェクトストレージやファイルシステム共有（RWX）は標準ではサポートしていません。NVMe/TCPサポートは開発中ですが、2026年4月時点では本番利用は推奨されていません。IOPSが15,000〜20,000程度のため、高負荷データベースワークロードには性能不足の可能性があります。

OpenEBS Mayastor: SPDKベースの高性能エンジン

OpenEBSはCNCF Sandboxプロジェクトですが、そのデータプレーンエンジンMayastorはSPDK（Storage Performance Development Kit）ベースで設計されており、カーネルバイパスによる高い性能が特徴です（OpenEBS公式サイト）。

# openebs-mayastor-pool.yaml
# Mayastor DiskPoolの定義（NVMe SSD指定）
apiVersion: "openebs.io/v1beta2"
kind: DiskPool
metadata:
  name: pool-node-1
  namespace: mayastor
spec:
  node: worker-node-1
  disks:
    - "uring:///dev/nvme0n1"    # ← NVMe SSDを直接指定（io_uring使用）

# openebs-mayastor-sc.yaml
# Mayastorのストレージクラス定義
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mayastor-nvme
provisioner: io.openebs.csi-mayastor
parameters:
  protocol: "nvmf"              # NVMe-oFプロトコル使用
  ioTimeout: "30"
  repl: "2"                     # レプリカ2
volumeBindingMode: WaitForFirstConsumer

なぜOpenEBS Mayastorを選ぶか:

• SPDKベースのユーザースペースI/Oにより、カーネルのオーバーヘッドを回避
• NVMe SSDの性能を最大限に引き出し、読み取りレイテンシ0.5〜1.5msを実現
• ワークロードごとに異なるエンジン（Jiva/cStor/Mayastor）を選択可能

注意点:

MayastorはHugePagesの有効化（2MBページ × 1024 = 2GBが推奨）と特定のカーネルバージョン（5.15以上）が必要です。エンジン選択の柔軟性がある反面、「どのエンジンをどの場面で使うか」をチーム自身で判断する必要があります。

性能ベンチマーク比較

以下のベンチマーク数値は、onidel.comの測定記事による2025年の比較結果です。

メトリクス	OpenEBS Mayastor	Rook-Ceph	Longhorn
ランダム読み取りIOPS（4Kブロック）	45,000〜60,000	25,000〜35,000	15,000〜20,000
ランダム書き込みIOPS（4Kブロック）	35,000〜50,000	20,000〜30,000	12,000〜16,000
シーケンシャル読み取り（1MBブロック）	2,500〜3,500 MB/s	1,800〜2,800 MB/s	800〜1,200 MB/s
読み取りレイテンシ	0.5〜1.5 ms	1〜3 ms	2〜4 ms
メモリ消費（ノードあたり）	150〜600 MB	1〜2 GB	200〜400 MB
CPU使用率（ノードあたり）	0.05〜0.5コア	0.5〜1.5コア	0.1〜0.3コア

よくある間違い: 最初はIOPS数値だけで選定しがちですが、実際には運用コスト（メモリ・CPU・学習コスト）が長期的なTCOに大きく影響します。3ノードのk3sクラスタにRook-Cephをデプロイした場合、ストレージ基盤だけでノードメモリの25〜30%を消費する可能性があります。

AI/MLワークロード向けストレージアーキテクチャを設計する

MLエンジニアにとって、ストレージは学習データの供給速度がモデル訓練のボトルネックになりうる重要な要素です。ここでは、GPU利用率を最大化するためのストレージ設計を見ていきます。

なぜストレージがAI基盤のボトルネックになるのか

2026年、AI基盤においてストレージは主要なボトルネックの一つとして認識されています。MinIO社の分析によると、50%以上の組織がデータおよびストレージのボトルネックによりAI性能とスケーラビリティが制限されていると報告しています（MinIO AI Storage Architecture 2026）。

従来のスケールアップ型ストレージは、AI/MLの並列アクセスパターンに対応しきれません。GPUクラスタが待機状態になると、Blackwell世代のGPUでは1ノードあたり年間約30,000ドルの資本・電力コストが無駄になるとの試算もあります。

GPUDirect Storageとカーネルバイパス

GPUDirect Storage（GDS）は、NVIDIAが提供する技術で、ストレージからGPUメモリへのデータ転送をCPUとカーネルを介さずに行います。PyTorchの DataLoader で pin_memory=True を設定するとCPU→GPU転送が高速化されるのと同様に、GDSはストレージ→GPU転送そのものを高速化する技術です。

# gpu_direct_storage_example.py
# GPUDirect Storageを活用したデータ読み込みの概念コード
# ※ cuFile APIはC/C++が主だが、KvikIOでPythonから利用可能

import cupy as cp
import kvikio       # NVIDIA KvikIO: GPUDirect Storage用Pythonバインディング

# GPUDirect Storage経由でファイルを読み込み
# → CPU・カーネルバイパスで直接GPUメモリへ転送
def load_training_data_gds(file_path: str, gpu_id: int = 0) -> cp.ndarray:
    """GPUDirect Storageで学習データを直接GPUメモリに読み込む"""
    with cp.cuda.Device(gpu_id):
        # GPUメモリ上にバッファを確保
        buf = cp.empty(1024 * 1024 * 100, dtype=cp.uint8)  # 100MB

        # KvikIO経由でGDS読み込み（CPUバウンスバッファ不要）
        with kvikio.CuFile(file_path, "r") as f:
            bytes_read = f.read(buf)

        print(f"Read {bytes_read / 1024**2:.1f} MB directly to GPU {gpu_id}")
        return buf[:bytes_read]

# 通常の読み込み（CPU経由）との比較
# 通常: Storage → CPU RAM → GPU VRAM（2回のコピー）
# GDS:  Storage → GPU VRAM（1回のDMAで完了、レイテンシ削減）

GPUDirect Storage 2.0はCUDA 12.3以降で出荷されており、H100/H200 GPUに対応しています。PCIe Gen5 NVMeドライブでは1ドライブあたり14GB/sのスループットが報告されており、サーバあたり400GB/s以上の転送速度が実現可能です（Introl GPU Direct Storage解説）。

制約条件:

GPUDirect Storageは対応するNVMe SSDとNVIDIA GPUの組み合わせが必要です。すべてのストレージバックエンドがGDSに対応しているわけではなく、2026年時点ではローカルNVMeまたは対応する分散ファイルシステム（Lustre、GPFS/Spectrum Scale等）が主な対応環境です。Rook-CephやLonghornとの直接的なGDS統合は現時点では提供されていません。

MinIOによるS3互換オブジェクトストレージの活用

学習データの管理にはS3互換オブジェクトストレージが適しています。MLエンジニアにとって馴染みのあるboto3やAWS CLIがそのまま利用でき、Kubernetes上にMinIOをデプロイすればオンプレミスでもS3互換のデータレイクを構築できます。

# minio-tenant.yaml
# MinIO Operator経由のテナント定義（学習データ用）
apiVersion: minio.min.io/v2
kind: Tenant
metadata:
  name: ml-data-lake
  namespace: minio-tenant
spec:
  image: minio/minio:RELEASE.2026-03-15T00-00-00Z
  pools:
    - servers: 4                 # 4台のMinIOサーバ
      volumesPerServer: 4        # サーバあたり4ボリューム
      volumeClaimTemplate:
        spec:
          storageClassName: mayastor-nvme  # ← OpenEBS Mayastorで高速化
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 500Gi
  requestAutoCert: true          # TLS自動設定

# minio_data_loader.py
# MinIOからPyTorchの学習データを読み込む例
import boto3
from torch.utils.data import Dataset

class MinIODataset(Dataset):
    """S3互換MinIOからデータを読み込むPyTorch Dataset"""

    def __init__(self, bucket: str, prefix: str, endpoint: str):
        # MinIOのエンドポイントを指定するだけでboto3がそのまま使える
        self.s3 = boto3.client(
            "s3",
            endpoint_url=endpoint,        # 例: "https://minio.ml-data-lake.svc:443"
            aws_access_key_id="minioadmin",
            aws_secret_access_key="minioadmin",
        )
        # ファイル一覧を取得
        response = self.s3.list_objects_v2(Bucket=bucket, Prefix=prefix)
        self.keys = [obj["Key"] for obj in response.get("Contents", [])]

    def __len__(self):
        return len(self.keys)

    def __getitem__(self, idx):
        obj = self.s3.get_object(Bucket="training-data", Key=self.keys[idx])
        data = obj["Body"].read()
        # ここでデシリアライズ（例: np.frombuffer, pickle.loads 等）
        return data

なぜMinIOを選ぶか:

• 全S3互換ツール（boto3、rclone、AWS CLI）がエンドポイントURL変更だけで動作
• Kubernetes Operator経由でテナント分離・TLS・暗号化を自動管理
• イレイジャーコーディングにより、レプリケーションより少ないディスク容量で冗長性を確保

ハマりポイント: MinIOは2025年10月以降、Docker HubおよびQuayの公式イメージ更新を停止しています。本番環境ではChainguardのMinIOイメージや、MinIO公式サイトからの直接取得を検討してください（InfoQ - MinIO GitHub Repository in Maintenance Mode）。

2026年の注目トレンドを把握する

クラウドネイティブストレージの領域は急速に進化しています。ここでは、2026年時点での重要な技術トレンドを整理します。

NVMe/TCPがiSCSIを置き換える

NVMe/TCP（NVMe over TCP）は、標準的なTCPネットワーク上でNVMeプロトコルを使用する技術です。従来のiSCSIと比較して、IOPSが最大50%向上し、レイテンシも大幅に低減されます（Lightbits Labs NVMe/TCP解説）。

項目	iSCSI	NVMe/TCP
プロトコルオーバーヘッド	SCSI変換レイヤあり	ネイティブNVMeコマンド
I/Oキューの並列度	1キュー（通常）	最大65,535キュー
カーネル統合	追加ドライバ必要なケースあり	Linux/Windowsカーネル組み込み
IOPS改善	ベースライン	+50%以上（ベンダー測定値）

LonghornはNVMe/TCPサポートを開発中ですが、2026年4月時点では実験的段階です。OpenEBS Mayastorは既にNVMe-oFプロトコルをサポートしており、NVMe/TCPの恩恵を受けやすい構成になっています。

コンピュート・ストレージ分離アーキテクチャ

クラウドネイティブデータベースの世界では、コンピュートとストレージの分離がスタンダードになりつつあります（hacomono TECH BLOG 解説記事）。この設計思想は、Kubernetesのストレージ設計にも影響を与えています。

従来型のアーキテクチャでは、コンピュートノードにローカルディスクを紐づけて使用していました。分離アーキテクチャでは、コンピュート層（ステートレス）とストレージ層（ステートフル）を独立してスケーリングできます。

具体的な実装例:

• Amazon Aurora: 3つのAZに6つのレプリカを配置し、クォーラムベースで書き込み確認。コンピュートノード追加時にデータコピー不要（数秒で起動）
• TiDB: ステートレスなSQLフロントエンド（TiDBサーバ）とRaftベースの分散KVS（TiKV）を分離
• Neon: Amazon S3を永続化層として使用し、Scale to Zeroで未使用時のコスト最適化

トレードオフ:

コンピュート・ストレージ分離は、ネットワーク越しのI/Oと分散合意のオーバーヘッドが発生します。広告配信やHFT（高頻度取引）など、サブミリ秒のレイテンシが要求される用途では、ローカルSSD直結のモノリシック設計が適切な場合があります。

CNCFストレージプロジェクトの成熟度

CNCFエコシステムのストレージプロジェクトの成熟度を整理しておきましょう（CNCF Projects、Cloud Native Now CNCF Storage解説）。

プロジェクト	成熟度	主な用途
Rook	Graduated	Cephのオーケストレーション（ブロック/ファイル/オブジェクト）
Longhorn	Incubating	軽量ブロックストレージ（k3s/エッジ向け）
CubeFS	Incubating	分散ファイルシステム（マルチテナント・ML向け）
OpenEBS	Sandbox	コンテナアタッチトストレージ（Mayastor高性能エンジン）
Piraeus Datastore	Sandbox	DRBD/LINSTORベースのブロックストレージ
Vineyard	Sandbox	インメモリデータ共有（ゼロコピー・ML向け）

注目: CubeFSはIncubatingステータスで、Cephの3倍の性能を報告しています。マルチテナントアクセスとMLモデル管理に特化しており、今後の動向を注視する価値があります。

よくある問題と解決方法

クラウドネイティブストレージの運用で遭遇しやすい問題と対処法を整理します。

問題	原因	解決方法
PVCがPending状態のまま	StorageClassが存在しない、またはプロビジョナが起動していない	kubectl get sc でStorageClass確認、kubectl get pods -n <storage-ns> でプロビジョナのPod状態を確認
ボリュームのI/Oが遅い	レプリカ数過多、またはストレージノードのリソース不足	レプリカ数を3→2に削減、ストレージノードのCPU/メモリ増強を検討
Ceph OSDがcrashloop	ディスクのパーティションテーブルが残存	sgdisk --zap-all /dev/sdX でディスクを完全消去してから再デプロイ
Longhornのレプリカ再構築が遅い	ネットワーク帯域が不足	longhorn-settings で guaranteed-instance-manager-cpu を調整、10Gbps以上のネットワーク推奨
Mayastorが起動しない	HugePagesが未設定	echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages でHugePages有効化
マルチアタッチエラー	RWOボリュームを複数Podでマウント	RWXが必要な場合はCephFSまたはNFSに切り替え

まとめと次のステップ

まとめ:

• Rook-CephはCNCF唯一のGraduatedストレージで、ブロック・ファイル・オブジェクトの統合提供が強み。大規模クラスタ（10ノード以上）向け
• LonghornはHelmワンコマンドデプロイと軽量さが特徴。k3s・エッジ・中小規模クラスタに適する
• OpenEBS MayastorはSPDKベースで最大60,000 IOPSを達成。NVMe SSDを活用したい高性能ワークロード向け
• AI/MLワークロードではストレージがGPU利用率のボトルネックになりうる。S3互換オブジェクトストレージ（MinIO等）とGPUDirect Storageの組み合わせが有効
• NVMe/TCPの台頭とコンピュート・ストレージ分離が2026年のトレンド

次にやるべきこと:

• 自身のワークロードの要件（IOPS・容量・アクセスパターン）を明確にし、上記の選定フローチャートで候補を絞る
• 候補のストレージをdev/staging環境にデプロイし、fio（Flexible I/O Tester）で実ワークロードに近いベンチマークを実施
• 障害テスト（ノード停止・ディスク障害）を実施し、復旧時間とデータ整合性を確認

参考

• Longhorn vs OpenEBS vs Rook-Ceph on k3s in 2025
• Kubernetes Storage Showdown: Ceph Rook vs. Portworx
• Top Kubernetes Storage Solutions in 2026
• 8 CNCF Projects for Cloud-Native Persistent Storage
• AI Storage Architecture: Overcoming the Bottleneck Limiting AI Scale in 2026
• NVMe/TCP Storage for Kubernetes
• クラウドネイティブなデータベースはなぜコンピュートとストレージを分離するのか - hacomono TECH BLOG
• CNCF Graduated and Incubating Projects
• Longhorn公式サイト
• MinIO公式サイト
• Object Storage for AI: GPU Direct Storage
• InfoQ - MinIO GitHub Repository in Maintenance Mode

---

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。