NVMe(Non-Volatile Memory Express)とNVMe-oF

1. 概要

A. 定義

NVMe(Non-Volatile Memory Express)とは、PCIe(PCI Express)バスに直接接続される不揮発性ストレージ(主にNANDフラッシュ・次世代メモリSSD)の並列性・低遅延特性を最大限に引き出すために設計されたホスト-コントローラインタフェース規格であり命令セット(command set)である。NVMe-oF(NVMe over Fabrics)は、このNVMeの命令・キューモデルをネットワークファブリック(RDMA・Fibre Channel・TCP)上へ拡張し、リモートストレージをあたかもローカルNVMeデバイスのように低遅延で接続できるようにする転送(transport)規格である。

NVMeの本質は、「記憶媒体は変わったのに接続規約はそのままだった」という不整合を解消した点にある。かつてのAHCI/SATAやSASは回転ディスク(HDD)を前提に作られたインタフェースで、単一の命令キューと浅いキュー深度、長い命令処理経路を想定していた。しかしフラッシュSSDは機械的なシーク遅延がなく、内部的に数十個のチャネル・ダイ(die)を並列動作させられるため、HDD用の規約をそのまま使うと媒体の並列性をソフトウェア層がボトルネックとして遮る結果になる。NVMeはこのボトルネックを取り除くため、多重キュー(multi-queue)・低い命令オーバーヘッド・コア別の並列提出を第一級の設計目標とした規格である。

B. 登場背景と必要性

2000年代後半にフラッシュSSDが本格普及すると、ディスク自体のアクセス遅延はミリ秒(ms)から数十マイクロ秒(µs)水準へと2桁以上縮まった。しかしこのSSDを既存のSATA/AHCIで接続すると、AHCIが許すキューが1個、キュー深度が32個にすぎず、媒体がいくら速くても命令を十分に押し込めないという構造的限界に突き当たった。またAHCI命令を1つ処理するのに多数のレジスタアクセス(MMIO)と割り込み処理が必要で、命令あたりのソフトウェアオーバーヘッドが媒体遅延に比べて相対的に大きくなった。すなわち「速い媒体に遅い規約」という構造的不整合が生じたのである。

NVMeはこの不整合を根本的に再設計した。ホストはメモリ上に提出キュー(SQ, Submission Queue)と完了キュー(CQ, Completion Queue)を対にして置き、命令をキューに記録した後、ただ一度のドアベル(doorbell)レジスタ書き込みでコントローラに知らせる。キューは理論上最大64K個(65,535個)まで置け、キューごとに最大64K個の命令を収められるため、マルチコアCPUの各コアがロック競合なしに自分のキューを通じて並列に命令を提出する。命令セットも少数の必須命令に単純化し、命令あたりの処理経路を短くした。結果として、同じSSDでもNVMeで接続すれば数十万〜数百万IOPSと数十µs台の遅延を引き出せるようになった。

さらに、フラッシュが速くなるほど「サーバ1台に挿さったローカルSSD」という物理的制約が新たなボトルネックとなった。クラウド・仮想化環境ではコンピュートとストレージを分離(disaggregation)し、資源を独立して増設・共有する必要があるが、ローカルNVMeの低遅延をネットワーク越しに維持できなければ分離の利点が相殺される。NVMe-oFはまさにこの要求から出発し、NVMeのキュー・命令モデルをネットワーク転送上にほぼそのままカプセル化することで、リモートアクセス時の追加遅延を最小化(RDMA転送基準で一桁µsの追加を目標)した規格である。要するにNVMeは「媒体-規約不整合」を、NVMe-oFは「ローカル依存性」をそれぞれ解消する二つの軸である。

C. 中核的特徴

NVMe系の性格は四つに要約される。第一に深く広い並列性 — 多数のキューと深いキュー深度により、媒体の内部並列性をソフトウェアが覆い隠さない。第二に低い規約オーバーヘッド — ドアベルベースの提出とMSI-X割り込み、単純化された命令セットで命令あたりのCPUコストを最小化する。第三に拡張可能な階層構造 — 名前空間(namespace)で一つのコントローラを論理的に分割し、転送層を抽象化してPCIe・ファブリックを同じ命令モデルで扱う。第四に転送独立性(transport abstraction) — NVMe-oFではRDMA・FC・TCPのいずれの転送を使っても上位命令の意味は同一である。これらの特徴は、後で扱う「ローカルか分離型か、どの転送を選ぶか」の判断根拠となる。

2. NVMeアーキテクチャと動作原理

A. 全体構造と中核構成要素

NVMeの全体構造はホスト(ドライバ)・転送(PCIe)・コントローラ・名前空間の四層に分けられる。ホスト側NVMeドライバはOSブロック層とデバイスの間でキューを生成・管理し、コントローラはキューに積まれた命令を取り出して内部のフラッシュ変換層(FTL)を経て媒体に反映する。名前空間は一つの物理SSDを論理的に分割した単位で、SCSIのLUNに対応し、仮想マシン・テナント別に隔離されたストレージ空間を提供する。

flowchart TB
  subgraph HOST["ホスト(Host)"]
    APP["アプリケーション / ファイルシステム"]
    DRV["NVMeドライバ<br/>(キュー生成·ドアベル管理)"]
    AQ["管理キュー(Admin SQ/CQ)"]
    IQ["I/Oキュー対(コア別SQ/CQ多数)"]
  end
  subgraph BUS["転送(PCIe)"]
    DB["ドアベルレジスタ(MMIO)"]
  end
  subgraph CTRL["NVMeコントローラ"]
    ARB["命令仲裁(Arbitration)"]
    FTL["FTL / マッピング·GC·ウェアレベリング"]
    NS1["名前空間 NS1"]
    NS2["名前空間 NS2"]
  end
  APP --> DRV --> AQ
  DRV --> IQ
  IQ --> DB --> ARB
  AQ --> DB
  ARB --> FTL --> NS1
  FTL --> NS2
  ARB -. "MSI-X割り込み(完了通知)" .-> DRV

主要な構成要素を整理すると次のとおりである。

管理キュー(Admin Queue): コントローラ識別、I/Oキュー生成・削除、名前空間管理などの制御命令を処理する単一のキュー対である。
I/Oキュー対(SQ/CQ): 実際の読み取り・書き込み命令が行き交うキューで、コアごとに一つ以上置いて並列提出を可能にする。
ドアベルレジスタ: ホストがキューに命令を入れた後に尾部(tail)位置をコントローラへ知らせ、完了処理後に頭部(head)位置を更新するMMIOの窓口である。
名前空間(Namespace): コントローラが露出する論理ブロック集合で、フォーマット・暗号化・隔離の単位となる。
FTL(Flash Translation Layer): 論理-物理アドレスマッピング、ガベージコレクション、ウェアレベリングを行うコントローラ内部のファームウェア層である。

B. 命令処理の流れとキューモデル

NVMeの命令処理は「キューに入れて → ドアベルで知らせて → 完了を割り込みで受け取る」という単純な生産者-消費者モデルに従う。下のシーケンス図は、一つの読み取り命令が提出され完了するまでの経路を示す。要点は、命令提出がレジスタ書き込み一度で終わり、完了通知もキュー単位でまとめて処理(interrupt coalescing)できるため、命令あたりのCPUコストが非常に低いことである。

sequenceDiagram
  participant H as ホストドライバ
  participant SQ as 提出キュー(SQ)
  participant DB as ドアベル
  participant C as コントローラ
  participant CQ as 完了キュー(CQ)
  H->>SQ: 命令ディスクリプタ記録(tail++)
  H->>DB: SQ Tailドアベル書き込み(1回)
  DB->>C: 「処理すべき命令あり」通知
  C->>C: 命令引き出し·DMAでデータ転送
  C->>CQ: 完了項目記録(状態·結果)
  C-->>H: MSI-X割り込み(完了)
  H->>DB: CQ Headドアベル書き込み(処理完了を反映)

このモデルで性能を左右する要素は、キューの個数・深度・仲裁(arbitration)方針である。キューがコア数だけあればコア間のロック競合が消え、キュー深度が深ければ媒体の内部並列チャネルを満たせる。コントローラは複数のSQから命令を取り出す際、ラウンドロビンまたは加重ラウンドロビン(WRR)・優先度ベースの仲裁を適用し、たとえば遅延に敏感なトランザクションキューをバッチ(batch)キューより優先処理するようQoSを与えられる。実際、データベースのような遅延敏感ワークロードとバックアップのようなスループット重視ワークロードが一つの装置を共有するとき、キュー・仲裁設計がサービス品質を分ける中核変数となる。

C. AHCI/SATAに対する構造的差異

NVMeとAHCIの差は単なる性能数値ではなく設計哲学の差に由来する。AHCIは単一キュー・浅い深度を前提にHDDの順次処理に合わせた一方、NVMeは多重キュー・深い深度でフラッシュの並列性を前提とする。下の表は中核的差異を要約するが、各項目が「なぜ」重要なのかは表の後の段落で説明する。

区分	AHCI / SATA	NVMe
キュー個数	1個	最大約64K個
キュー深度	32	キューあたり最大約64K
命令提出	多数のレジスタアクセス	ドアベル1回書き込み
割り込み	単一	MSI-X(キュー別多重)
転送	SATA 6Gbpsなど	PCIeレーン(世代別に数GB/s↑)
典型遅延	数十〜百µs台	数〜数十µs台

表の数値自体より重要なのはその含意である。キューが1個だけならマルチコアサーバで全コアが一つのキューを巡ってロック競合を起こし、コアを増やしてもIOPSが線形に伸びない。NVMeはコア別キューでこの競合を除去し、コア数に比例する拡張性を確保する。またAHCIは命令ごとに複数回のレジスタアクセスが必要で、命令あたり数µsのソフトウェアオーバーヘッドが付くが、媒体遅延が数十µsに短くなったフラッシュではこの比重は無視できない。NVMeのドアベル1回書き込みと割り込み併合はまさにこの比重を引き下げる。たとえば同じTLCベースのSSDでも、SATAモデルはおおむね数万〜10万IOPS台にとどまる一方、PCIe 4.0のNVMeモデルは数十万〜100万IOPS以上を出す事例が一般的であり、この差の相当部分は媒体ではなくインタフェース設計に由来する。

3. NVMe over Fabrics(NVMe-oF)アーキテクチャ

A. 設計目標と転送層の抽象化

NVMe-oFは「ローカルNVMeの低遅延をネットワーク越しでも維持する」という目標で、NVMeのキュー・命令カプセル(capsule)をネットワーク転送上に載せて運ぶ。中核設計は命令層と転送層の分離である。上位のNVMe命令の意味はローカルでもリモートでも同一に保ち、その命令をどの媒体で運ぶかは転送バインディング(RDMA・FC・TCP)が担う。この抽象化のおかげで、アプリケーションとドライバ上位層は転送種別をほとんど意識しない。

flowchart LR
  subgraph INIT["イニシエータ(Initiator, ホスト)"]
    FE["NVMeコア(キュー·命令カプセル)"]
    T1["RDMA転送"]
    T2["TCP転送"]
    T3["FC転送"]
  end
  subgraph NET["ネットワークファブリック"]
    ROCE["RoCE/iWARP/InfiniBand"]
    ETH["Ethernet(TCP/IP)"]
    FCN["Fibre Channel"]
  end
  subgraph TGT["ターゲット(Target, ストレージ)"]
    TT["転送終端"]
    TC["NVMeコントローラ"]
    NS["名前空間(リモートブロック)"]
  end
  FE --> T1 --> ROCE --> TT
  FE --> T2 --> ETH --> TT
  FE --> T3 --> FCN --> TT
  TT --> TC --> NS

B. 転送別の特性と選択基準

NVMe-oFが支援する転送は性格が明確に異なり、選択は遅延・費用・既存インフラに左右される。下の表は代表的な転送を比較するが、実際の選択の根拠は続く段落で説明する。

転送	追加遅延	要求インフラ	特徴
RDMA(RoCE v2/iWARP/IB)	最も低い(µs一桁目標)	RDMA NIC·無損失Ethernet(PFC/ECN)	最高性能、構成·運用難度が高い
Fibre Channel(FC-NVMe)	低い	FC HBA·SANスイッチ	既存FC-SAN資産の再活用、安定的
TCP(NVMe/TCP)	相対的に高い	標準Ethernet·NIC	汎用性·低費用、大規模拡張が容易

RDMAベースの転送はカーネル・CPUを迂回してリモートメモリに直接データを出し入れする(zero-copy)ため追加遅延が最も低いが、RoCE v2を使うには無損失Ethernet(PFC·ECN·輻輳制御)を構成せねばならず、ネットワーク運用難度が高い。FC-NVMeは金融・基幹系のようにすでにFC-SANを運用する組織が既存のHBA・スイッチ資産を再活用しつつ、ブロック規約だけをSCSIからNVMeへ転換するときに有利である。NVMe/TCPは特別なNICなしに標準Ethernet上で動作し、汎用性と費用効率が最も優れるため、ハイパースケール・クラウドが大規模にストレージを分離構成するとき事実上の既定の選択肢として定着しつつある。すなわち「最低遅延ならRDMA、既存FC資産ならFC-NVMe、汎用・大規模ならTCP」が一次の判断基準である。

4. 比較と適用事例

A. iSCSIに対するNVMe/TCP

リモートブロックストレージの伝統的標準であったiSCSIはSCSI命令をTCP/IPに載せて運ぶが、基礎となるSCSIモデル自体が単一キュー指向なので、マルチコア並列性と低遅延に限界があった。NVMe/TCPは同じ標準Ethernetを使いながらもNVMeの多重キューモデルをそのまま転送するため、同じネットワークでより高いIOPSとより低い遅延を得る場合が多い。ただしNVMe/TCPもTCPスタックを経る分、RDMAより遅延が大きく、輻輳制御・再送の影響を受けるため、ネットワーク品質が性能に直結する。実務では既存のiSCSI SANをNVMe/TCPへ漸進転換しつつ、遅延が特に敏感な一部ワークロードのみRDMAファブリックに別途配置するハイブリッド構成がよく見られる。

B. 産業適用事例

第一に、クラウドブロックストレージでハイパースケーラはコンピュートノードとストレージノードを分離し、その間をNVMe-oF(主にTCP)で接続して、VMがローカルディスクのように見えるリモートボリュームを低遅延で使えるようにする。これによりストレージ容量とコンピュートを独立して増設し、障害ノードのボリュームを別ノードへ迅速に再付着(re-attach)できる。第二に、AI学習インフラでは数百GB/sのデータセット読み込みがGPUを飢えさせないよう、GPUDirect Storageと結合したNVMe-oF(RDMA)でストレージからGPUメモリへデータを直接押し込む。第三に、金融基幹系では既存のFC-SAN上にFC-NVMeを導入し、検証済みFCインフラの安定性を保ちながら取引システムのストレージ遅延を数十%水準下げた事例が報告される。三つの事例いずれも「媒体は同じでもインタフェース・転送選択が全体性能と運用モデルを左右する」という共通の教訓を示す。

5. 深化 — NVMe 2.0と次世代拡張

NVMeエコシステムの近年の流れは、仕様のモジュール化と媒体特性に合わせたデータ配置に要約される。2021年に公開されたNVMe 2.0は単一の巨大仕様を基盤仕様(base) + 命令セット仕様(NVM·ZNS·Key-Value) + 転送仕様(PCIe·RDMA·TCP·FC) + 管理インタフェース(NVMe-MI)に分離した。このモジュール化は、新たな命令セットや転送を追加するとき仕様全体を揺るがさずに独立して拡張できるようにし、エコシステムの進化速度を高めた。

最も注目される拡張はZNS(Zoned Namespaces)である。ZNSは名前空間を多数のゾーン(zone)に分け、各ゾーンを順次書き込み(sequential write)のみ許可するよう制約する。こうすればSSD内部のガベージコレクションとそれによる書き込み増幅(write amplification)を大きく減らし、オーバープロビジョニングとDRAM要求量を下げられる。特にセルあたりのビット数が多く耐久性が弱いQLCフラッシュにおいて、ZNSは寿命と費用効率を同時に改善する手段と評価される。ホストがデータの寿命(lifetime)に応じてゾーンを配置すれば、ともに消去されるデータが同じ物理領域に集まり、消去効率が上がる原理である。より柔軟な接近として比較的最近標準化されたFDP(Flexible Data Placement)があり、ZNSのように順次書き込み制約を強制せずとも、ホストがデータ配置についてのヒントを与えて書き込み増幅を減らせるようにする。

またCXL(Compute Express Link)との関係も深化論点である。NVMeがブロック単位・キューベースのストレージ接続を代表するなら、CXLはバイト単位・キャッシュ一貫性(cache-coherent)のメモリ接続を志向する。両技術は競争ではなく階層を分けて補完する関係で、熱いデータはCXLメモリ階層に、持続・大容量データはNVMe階層に置くメモリ-ストレージ階層化が次世代サーバアーキテクチャの方向として論じられる。このほかCMB(Controller Memory Buffer)·PMR(Persistent Memory Region)のような機能はホストメモリを経ないpeer-to-peer DMAや持続性バッファを提供し、ストレージと加速器・ネットワーク間のデータ移動経路をより短くする。

6. 考慮事項および示唆点

技術士の観点でNVMe·NVMe-oF導入は、単なる装置交換ではなくアーキテクチャ・運用・経済性の総合設計として接近すべきである。

転送選択のトレードオフ: RDMAは最低遅延を与えるが無損失Ethernet構成と運用専門性を要求し、TCPは汎用・低費用だが相対的に遅延が大きい。組織のネットワーク成熟度・ワークロード遅延敏感度・既存資産(FC-SANの有無)をともに評価し、全面統一よりワークロード別の転送混合を設計するほうが現実的である。
ボトルネック移動に対する展望: 媒体のボトルネックをNVMeが取り除くと、ボトルネックはCPU·ネットワーク·ソフトウェアスタックへ移っていく。したがってポーリング(polling)ベースのI/O(SPDKなどユーザ空間ドライバ)、割り込み併合、DPUへのストレージデータパスのオフロードなど上位層の最適化を併行してこそ、NVMeの性能を実際に体感できる。
セキュリティとマルチテナンシー: 名前空間隔離だけでは十分でなく、リモートアクセス時には転送暗号化(FC-NVMe·NVMe/TCPのセキュアチャネル)、認証・アクセス制御、自己暗号化ドライブ(SED)·TCG Opalベースの媒体暗号化を併せて考慮せねばならない。特にクラウドで一つの物理SSDを複数テナントが共有するとき、QoS隔離とデータ消去(secure erase)保証が規制・監査要件に直結する。
適用戦略と連携技術: コンピュート-ストレージ分離(disaggregation)、ソフトウェア定義ストレージ(SDS)、KubernetesのCSIドライバを通じた動的ボリュームプロビジョニングと結合するとき、NVMe-oFの価値が極大化する。さらにZNS·FDPを活用したQLCベースの大容量低価格階層、CXLメモリ階層とのティアリング、消失訂正符号・スナップショットのようなデータ保護技法との組み合わせを通じて、性能·耐久性·費用の均衡点をアーキテクチャ水準で設計せねばならない。

参考資料

NVM Express, "NVM Express Base Specification 2.0" — https://nvmexpress.org/specifications/
NVM Express, "NVMe over Fabrics" overview — https://nvmexpress.org/
SNIA, "NVMe and NVMe-oF educational materials" — https://www.snia.org/

一言まとめ: NVMeはフラッシュの並列性を多重キュー・低遅延の命令モデルで引き出すPCIeストレージインタフェースであり、NVMe-oFはこのモデルをRDMA·FC·TCPファブリックへ拡張してコンピュート-ストレージ分離を可能にするリモート転送規格である。