VPSのNVMeとSSDはどれほど違いますか？

VPS で NVMe は重要ですか？

VPS でソフトウェアが小さな読み取りや書き込みを大量に発行し、それぞれの完了を待つ場合、NVMe は重要です。キャッシュ済みのページを配信するサイトや、ネットワーク待ちに大半の時間を費やすプログラムでは、NVMe による違いはほとんどありません。ストレージの種類は要因の 1 つにすぎません。ディスクの前段にあるハイパーバイザーと、同じホストを共有する他のゲストによって、実際に得られる性能の上限が決まります。

NVMe で変わること、変わらないこと

NVMe（non-volatile memory express）は、フラッシュメモリの種類ではありません。フラッシュメモリにアクセスするためのプロトコルと接続方式です。NVMe デバイスは PCIe（peripheral component interconnect express）レーン上で動作し、NVMe を使用します。SATA（serial ATA）SSD は SATA 接続上で動作し、AHCI（advanced host controller interface）を使用します。データを保持するメモリチップは、どちらも同じ場合があります。

異なる点は 2 つあります。どちらもストレージそのものではなく、コマンドの経路に関する違いです。

キュー。 AHCI では、カーネルが使用できるコマンドキューは 1 つで、32 個のコマンドを保持します。NVMe では数千のキューを使用でき、実際には CPU コアごとに 1 つずつ割り当てられることが多く、各キューの深さも 32 より大きくできます。1 つのプロセスが一度に 1 ブロックだけを読み取る場合、この違いは現れません。64 個の読み取りを同時に発行するデータベースでは違いが現れます。SATA では 33 番目の要求がキューの空きを待つため、デバイスがその要求を認識する前に待機します。一方、NVMe デバイスはすべての要求を受け付け、同時に処理できます。

リンク幅。 SATA III のリンク速度は 6 Gbit/s で、プロトコルのオーバーヘッドを差し引いた実データでは約 550 MB/s です。背後にあるフラッシュメモリの種類に関係なく、これが固定の上限になります。PCIe の 4 レーンでは毎秒数 GB を転送できるため、リンクがボトルネックにならなくなります。

レイテンシーについては、期待と実際が異なることがよくあります。キュー深度 1、つまり処理中の要求が 1 つだけの場合、SATA SSD は 4k の読み取りに約 100 から 150 マイクロ秒で応答します。NVMe は約 80 から 100 マイクロ秒です。どちらも十分に高速であり、1 つの要求だけであれば、実行している処理から違いを認識することはありません。差が現れるのは並行処理時です。キュー深度、つまり同時に処理中となる要求数が、2 つのメディアが似た動作になるか、大きく異なる動作になるかを決めます。

ネットワークブロックストレージは、物理的な特性が異なる 3 番目の分類です。書き込みはネットワークを経由してストレージクラスターに送られ、クラスターがデータを保持して初めて応答が返されます。そのため、レイテンシーはマイクロ秒ではなくミリ秒単位になります。このレイテンシーと引き換えに得られるのは耐久性です。ボリュームは接続先のホストがなくなっても保持され、スナップショットの作成やサイズ変更もできます。

公表値の目安: NVMe、SATA SSD、ネットワークストレージ

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

ローカルの NVMe デバイスは、キュー深度 32 でランダム 4k 読み取りが 184,000 IOPS（1 秒あたりの入出力操作数）とされることが一般的です。同じテストでは、SATA SSD は 90,000 前後とされます。単一の AHCI キューと 6 Gbit/s のリンクが上限になるためです。ネットワークブロックストレージは通常、ハードウェアではなくプロバイダーによって上限が決まり、12,500 が文書化された上限としてよく示されます。

レイテンシーも、ユーザーが体感する単位で同じ傾向を示します。p99 読み取りレイテンシー、つまりリクエストのうち最も遅い 1 パーセントの値は、ローカル NVMe で約 0.4 ms、SATA で 1.2 ms です。経路にネットワークが入ると 6.5 ms になり、NVMe の値の 10 倍を超えます。

シーケンシャル読み取りは差が最も大きい一方で、最も参考になりにくい指標です。値は 3,400 MB/s 対 550 MB/s です。サーバー上で、大きなファイルを最初から最後まで最大速度で読み取る処理はほとんどありません。データベース、メールキュー、パッケージマネージャーが実際に行う処理を示すのは、ランダムアクセスとレイテンシーの値です。

ディスクの影響を受けるワークロード

すべてに当てはまる原則は 1 つです。ワークロードがディスクを待つ場合にだけ、ディスクの影響を受けます。Linux は最近使用したファイルデータを RAM の page cache に保持するため、ファイルの 2 回目の読み取りがストレージに到達することはありません。ワーキングセット、つまり実際に使用中のデータが RAM に収まる場合、最初の読み取り以降はメモリ読み取りになります。書き込みは異なります。アプリケーションが fsync() でフラッシュする書き込みは、アプリケーションが処理を続行する前に、安定したストレージ上に存在していなければなりません。

コミットを確定する処理。 PostgreSQL、MySQL、SQLite はコミット時に fsync() または fdatasync() を呼び出し、各コミットはデバイスの応答を待ちます。そのため、1 接続あたりのコミットレートは帯域幅ではなく書き込みレイテンシーで決まります。0.2 ms でフラッシュするデバイスは、5 ms かかるデバイスよりも 1 秒あたりに多くのコミットを処理できます。スループットをいくら高めても、この差は変わりません。フラッシュが処理に追いつかない場合、MySQL はエラーログにその状況を出力します。

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL はチェックポイントの行でこの状況を報告します。sync= の値が大きい場合、フラッシュ自体に時間がかかったことを示します。

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

多数の小さなファイルにアクセスする処理。 すべてのファイルでは、1 回の大規模なシーケンシャル読み取りにはないメタデータ操作が発生します。npm install、大規模なリポジトリの git clone、コンテナイメージの展開、Maildir のメールストア、大規模なツリーを走査するバックアップは、いずれも小さなランダムアクセスに時間を費やします。VPS 上の restic バックアップジョブ は、まだ読み取っていないすべてのファイルを読み取ってハッシュ化するため、1000000 個のファイルを対象とするバックアップの経過時間は、ランダム読み取りレイテンシーに密接に左右されます。du -sh も同様です。こちらはメタデータだけを読み取ります。

RAM に収まらない規模まで増大したデータベースも、ここに該当します。インデックスが page cache に収まらなくなると、すべての検索がランダム読み取りになり、ディスクが再びクリティカルパスに入ります。

ディスクを意識しなくてよいワークロード

ブログまたは小規模な企業サイト。 ページは小さく、最初のリクエスト後はページキャッシュにすべて収まります。制約になるのは、レンダリングの CPU またはアセットの帯域幅です。低トラフィックのサイトを提供する Ubuntu 24.04 上の LAMP スタックでは、ウォームアップ後のディスク IO はほとんど発生しません。

メディアストリーミング。 40 Mbit/s の 4K ストリーム 1 本では、5 MB/s を読み取ります。10 本でも 50 MB/s であり、ネットワークブロックストレージでも問題なく処理できます。VPS 上の Jellyfin メディアサーバーを制限するのは、ストレージ媒体ではなく、ネットワークの egress 上限と、トランスコード時の CPU です。

ローカルモデル推論。 VPS 上で Ollama を実行して LLM をセルフホストする構成では、モデルファイルを 1 回読み込んだ後は RAM 上で処理します。NVMe を使用すると、20 GB のモデルのロード時間を数分から数秒に短縮できます。ただし、メモリ帯域幅と CPU に左右される tokens per second は変わりません。

外部サービスの応答を待つ処理。 1 ジョブあたり 800 ms を HTTP リクエストに費やすワーカーは、より高速なディスクに変更しても速くなりません。

ハイパーバイザーがストレージ媒体と同じ程度に重要な理由

実際のデバイスに直接アクセスすることはありません。通常は virtio 経由でハイパーバイザーが提示する仮想ディスクにアクセスします。この層でのいくつかの判断は、NVMe と SATA の違いよりも性能に大きく影響します。

ゲスト内からストレージ媒体を確認することはできません。 lsblk -d -o NAME,ROTA,SIZE,MODEL は、モデル名が空の状態で vda を表示します。これは、virtio がドライブの識別情報を引き渡さないためです。cat /sys/block/vda/queue/rotational はハイパーバイザーが公開している情報を報告するため、値が 0 でもフラッシュストレージの証明にはなりません。nvme-cli パッケージに含まれる nvme list は、ホストに NVMe ドライブが多数搭載されていても、ほとんどの VPS では何も表示しません。ゲストのディスクは NVMe デバイスではなく、virtio デバイスだからです。NVMe と記載されたプランは、通常、ホストに搭載されているストレージを説明しています。実際のボリュームはネットワーク接続の場合もあります。

ホストのキャッシュモードは、ストレージ媒体よりも測定値を大きく変えます。 ホストで writeback キャッシュが有効な場合、ゲストの fsync() は、ホストがデータを自身の RAM に保持した時点で完了を返せます。そのため、物理デバイスでは実現できないベンチマーク結果が出ます。また、ホストがクラッシュすると、データベースが安全に書き込まれたと判断したデータも失われる可能性があります。キャッシュモード none では、測定値は低くなりますが、実際の性能を正しく反映します。

上限とバーストクレジット。 多くのプロバイダーは、ボリューム単位またはプラン単位で IOPS に上限を設けています。また、多くのネットワークボリュームではバースト利用枠が設定されています。バースト利用枠はクレジットのプールです。クレジットが残っている間はボリュームが高速で動作し、その後は大幅に低い基準性能まで低下します。症状は簡単に判別できます。インポートやリストアが数分間は高速に実行された後、設定を変更していないのに急激に遅くなり、その状態が続きます。クレジットを使い切ったためです。

他の利用者の影響。 共有ホストでは、他のゲストが実行している処理によってディスクのレイテンシーが変化します。そのため、1 回だけでなく複数回測定する必要があります。同じテストを朝と夕方に実行し、結果のばらつきを比較してください。負荷の高いホストでは、同じボリュームで 2 回実行した結果の差が、公開されている 2 種類のストレージ媒体の性能差より大きくなることもあります。

VPS に実際に割り当てられているディスク容量を測定する方法

標準的な I/O ベンチマークである fio をインストールして測定します。最初に3点注意してください。テストではファイルを作成するため、ディスク容量を使用します。また、課金対象の IOPS 上限にも算入されます。実行時間は短くしてください。実際のトラフィックを処理しているボリュームに対して、最大のキュー深度で実行しないでください。自分のアプリケーションとディスク I/O を奪い合うことになるためです。

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

ベンダーが公表するキュー深度である、キュー深度32のランダム読み取りです。

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

重要なのは read: で始まる行です。

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1 はゲストのページキャッシュをバイパスするため、結果は RAM ではなくデバイスの性能を示します。これを省略するとメモリを測定することになり、ディスクでは到達できない値が返ります。空き容量がある場合は --size=4G 以上を使用してください。1G のファイルはホストのキャッシュ内に完全に収まり、結果が実際より良く見えることがあるためです。

キュー深度1では、シングルスレッドのプロセスが体感する値である、未加工のレイテンシを確認できます。

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

コミットテストでは、データベースの動作を予測できます。4k を書き込むたびに fdatasync() を呼び出すため、表示される速度にはフラッシュ処理が含まれます。

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

この実行で得られる IOPS 値は、1つのデータベース接続がコミットできる小規模トランザクションの1秒あたりの最大数に近い値です。コミットでは同じフラッシュ処理の完了を待つためです。

fio を使わずに簡単に測定する場合は、次のようにします。

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

平均偏差を示す mdev の値は、平均値と同じくらい重要です。アイドル状態のサーバーで偏差が大きい場合、ストレージバックエンドが他の利用者と共有され、混雑していることを示します。

結果の読み方

2026 年 7 月時点では、小規模な VPS について、次のような値が妥当です。キュー深度 32 で数万 IOPS の 4k ランダム読み取りが発生し、キュー深度 1 のレイテンシが約 0.3 ms 未満であれば、ローカルのフラッシュストレージと整合します。キュー深度 1 のレイテンシが数 ms ある場合は、プラン名に関係なく、ネットワーク経路上にストレージがあることを示します。シーケンシャル読み取りが 550 MB/s 付近で止まる場合は、SATA リンクの典型的な挙動です。単一のデバイスで実現できる値を大幅に上回る場合は、経路上でキャッシュが動作しています。ほとんどの場合、ホスト側のキャッシュです。

実際のワークロードがディスクに与えている影響を確認するには、次を実行します。

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

iostat -x の出力では、要求が待機した平均時間（ms）である r_await と w_await、および平均キュー長である aqu-sz を確認します。仮想ディスクでは %util を無視してください。これは、1 つ以上の要求が未完了だった時間の割合を示すだけです。多数の要求を同時に処理できるデバイスの飽和状態は示しません。そのため、%util が 100 で、r_await が 0.2 ms であれば、ディスクは正常に高負荷で動作しています。vmstat では、wa 列が IO 待機に費やした CPU 時間の割合です。カーネルに /proc/pressure/io が存在する場合、その some avg10= の値は、直近 10 秒間のうち少なくとも 1 つのタスクが IO で停止していた時間の割合です。ストレージがボトルネックかどうかを判断するうえで、最も直接的な指標です。

ディスク待ちの VPS で見られる状態

CPU がアイドル状態なのに load average が高く、wa の vmstat が大きい場合、プロセスがディスク処理の完了を待ってキューに入っています。カーネルが示す最も明確な兆候は、dmesg -T に出力される次のメッセージです。

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

この行は、カーネルスレッドがストレージからの応答を 2 分以上待機したため、hung task watchdog が記録したものです。jbd2 は ext4 のジャーナルスレッドです。つまり、1 つの問題のあるプログラムではなく、ファイルシステム全体が待機していました。VPS では通常、ストレージバックエンドの性能低下、または IOPS の上限到達が原因です。

アプリケーションにも同じ傾向が現れます。ディスクアクセスが発生したリクエストだけが影響を受けるため、中央値の応答時間は許容範囲に収まっていても、最も遅いリクエストの遅延は長い裾を形成します。apt upgrade は、dpkg が書き込み時に flush するため、Unpacking の段階で数分間停止します。大規模なリポジトリで git status を実行すると、完了まで数秒かかります。これらはメタデータ処理と flush のコストなので、帯域幅を増やしても改善しません。

ディスクがボトルネックになった場合の対処

IOPS を増やす前に RAM を増設してください。 ワーキングセットがページキャッシュに収まれば、読み取りがディスクに到達しなくなります。メモリを倍増する方が高速なストレージクラスへ移行するより効果的なことが多く、通常はコストも低くなります。

可能なデータでは、flush の回数を減らしてください。 PostgreSQL では、synchronous_commit = off により、書き込みがディスクに反映される前に commit を返せます。サーバーが停止すると、直前の数分の1秒分のトランザクションを失う可能性があります。write-ahead log は順序どおりに書き込まれるため、データベースが破損することはありません。このトレードオフは分析用コピーには適していますが、決済処理には適していません。MySQL の innodb_flush_log_at_trx_commit = 2 も同じトレードオフです。

小さなファイルをまとめてください。 100 万個の小さなファイルを転送またはバックアップすると、ファイルごとの処理コストが大部分を占めます。そのため、最初にアーカイブして 1 つのストリームとして転送すると、ファイルを 1 つずつコピーするよりも高レイテンシのストレージで高速になります。

thin volume で discard を機能させてください。 thin provisioned storage では、ファイルシステムが空きブロックを通知するまで、バックエンドはそのブロックが空いたことを認識できません。trim を一度も実行しない volume では、書き込み性能が徐々に低下します。Ubuntu には、次の weekly timer が用意されています。

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av は、各 mount point で trim されたバイト数を出力します。discard operation がサポートされていないというメッセージは、virtual disk が discard を host へ透過していないことを示します。この場合、対処する必要はありません。

IO scheduler の調整は省略してください。 virtio disk では、cat /sys/block/vda/queue/scheduler を実行すると通常はすでに none が表示されます。実際のスケジューリングは、アクセスできない host 側で行われます。noatime も省略してください。Ubuntu はデフォルトで relatime を使用して mount するため、ほぼすべての atime 書き込みをすでに回避できます。

プランの選択

データベース、メールサーバー、CI runner、またはパッケージの多いビルド環境をサーバー上で運用する場合は、NVMe に料金をかける価値があります。キャッシュ済みの Web サイトや、処理時間の大半を外部呼び出しに費やすアプリケーションに、割増料金を払う必要はありません。判断に迷う場合、ボトルネックはおそらくディスクではありません。小規模な VPS のワークロードでは、通常、先に RAM または帯域幅を使い切るためです。

新しい VPS で最初の 10 分間に行う作業を進めながら、初日に測定し、結果をファイルに保存してください。ベースラインがあれば、後から遅くなった原因がホストではなくコードにあることを検証できます。ストレージの種類と IOPS の上限を明記しているプロバイダーを選んでください。プランに NVMe と記載されていても、queue depth 1 の読み取りに 4 ms かかるなら、NVMe を搭載したホスト上のネットワークストレージです。これは販売する側にとっては適切な表現ですが、購入する側にとっては別の構成です。

FAQ

NVMe は VPS で常に SATA SSD より高速ですか？

いいえ。キュー深度 1 では両者に大きな差はなく、4k 読み取りはおよそ 80〜150 マイクロ秒です。シングルスレッドのプログラムでは違いを判別できません。多数のリクエストが同時に処理中になると、NVMe が優位になります。AHCI は深さ 32 のキューを 1 つ提供するのに対し、NVMe はより深いキューを数千個提供するためです。共有ホストでは、他のゲストからの負荷によって、ストレージ媒体の違いよりもレイテンシーが大きく変動することがあります。そのため、プラン名ではなく fio で自分のボリュームを測定してください。

VPS が実際に NVMe を使用しているかどうかを確認するにはどうすればよいですか？

virtio が物理デバイスを隠すため、直接確認することはできません。lsblk はモデル文字列なしで vda を表示し、nvme list は何も返さず、/sys/block/vda/queue/rotational はハイパーバイザーが通知する情報だけを報告します。代わりに、動作を測定してください。キュー深度 1 のランダム 4k 読み取りが約 0.3 ms 未満なら、ローカルフラッシュである可能性があります。数ミリ秒かかる場合は、ネットワーク経由の処理が経路に含まれています。シーケンシャル読み取りが 550 MB/s 付近で止まる場合は、SATA リンクを示しています。

NVMe にすると Web サイトの読み込みは速くなりますか？

通常は速くなりません。最初のリクエストの後、Linux はファイルを RAM のページキャッシュから提供するため、ディスクはアイドル状態になります。小規模な VPS のページ速度は、通常、アプリケーションの CPU 処理時間と帯域幅によって決まります。サイトがリクエストごとに書き込みを行う場合は、ディスクが再びクリティカルパスになります。たとえば、データベースを使用するカートが頻繁にコミットすると、各コミットの完了には flush の完了を待つ必要があるためです。

VPS では、どのような fio の結果が良好ですか？

2026 年 7 月時点では、ローカルフラッシュ上の小規模な VPS であれば、キュー深度 32 のランダム 4k 読み取りで通常は数万 IOPS、キュー深度 1 のレイテンシーで 0.3 ms 未満を返します。ネットワークブロックストレージでは、通常、数千 IOPS、数ミリ秒のレイテンシーになります。異なる時間帯に 3 回テストを実行してください。測定結果の平均値よりも、実行ごとのばらつきの大きさが重要です。ばらつきが大きい場合、ホスト上の他のゲストから受ける影響が大きいことが分かるためです。

データベースをネットワークブロックストレージに配置すべきですか？

配置できます。多くのマネージドサービスもこの構成を使用していますが、コミット処理にはその影響があります。すべての flush がネットワークを経由するため、1 つの接続で処理できる小規模トランザクションの 1 秒あたりの数は、ローカルフラッシュより少なくなります。その代わり、ホスト障害後も維持される耐久性を得られます。書き込み負荷の高いデータベースでネットワークストレージを選ぶ場合は、より大きなトランザクションに処理をまとめてください。少ない flush で、より多くの行を処理できるためです。