VPSではNVMeとSSDの違いは重要ですか？

VPSではNVMeが重要ですか？

ソフトウェアが多数の小さな読み取りと書き込みを発行し、それぞれの完了を待つ場合、VPSでは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は、32個のコマンドを保持するコマンドキューをカーネルに1つ提供します。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 で 184,000 のランダム 4k 読み取り 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回目の読み取りはストレージに到達しません。実際に使用中のデータを意味するworking setがRAMに収まる場合、最初の読み取り以降はメモリ読み取りになります。書き込みは異なります。アプリケーションがfsync()でフラッシュする書き込みは、アプリケーションが処理を続行する前に、stable storageへ保存されていなければなりません。

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

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

PostgreSQLはcheckpointの行でこの状況を報告します。大きなsync=値は、フラッシュ自体が遅かったことを示します。

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

多数の小さなファイルにアクセスする処理。 1回の大きなシーケンシャル読み取りとは異なり、各ファイルではメタデータ操作が発生します。npm install、大規模repositoryのgit clone、container imageの展開、Maildir mail store、大規模なツリーを走査するバックアップは、いずれも小さなランダムアクセスに時間を費やします。VPS上のresticバックアップジョブは、まだ読み取っていない各ファイルを読み取り、ハッシュを計算します。そのため、100万ファイルを対象とするバックアップの経過時間は、ランダム読み取りレイテンシに大きく左右されます。メタデータだけを読み取るdu -shも同様です。

RAMを超えるデータベースもここに含まれます。インデックスがpage cacheに収まらなくなると、各検索がランダム読み取りになります。その結果、ディスクが再びクリティカルパスに入ります。

ディスク性能の影響を受けないワークロード

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

メディアストリーミング。 4K ストリーム 1 本は 40 Mbit/s、つまり 5 MB/s を読み取ります。10 本では 50 MB/s ですが、これはネットワークブロックストレージでも問題なく処理できます。VPS 上の Jellyfin メディアサーバーでは、制限要因はストレージ媒体ではなく、ネットワークの送信データ許容量と、トランスコード時の 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 に上限を設定しています。また、多くのネットワークボリュームはバースト許容量を使用します。バースト許容量はクレジットのプールです。クレジットが残っている間はボリュームが高速に動作し、その後は大幅に低い基準性能まで低下します。症状は簡単に判別できます。インポートやリストアが数分間は高速に実行され、その後、設定を変更していないのに急激に遅くなり、遅い状態が続きます。クレジットを使い切ったということです。

近隣のゲスト。 共有ホストでは、他のゲストの処理内容によってディスクレイテンシーが変化します。このため、複数回測定する必要があります。同じテストを朝に実行し、夕方にも再度実行して、ばらつきを比較してください。負荷の高いホストでは、同じボリュームでの 2 回の実行結果の差が、公開されている 2 種類のメディア間の差より大きくなることがよくあります。

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

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

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で4kのランダム読み取りが数万IOPSに達し、キュー深度1のレイテンシが約0.3 ms未満なら、ローカルのフラッシュストレージと整合します。キュー深度1のレイテンシが数msなら、プランの名称に関係なく、ネットワーク経路を使用しています。シーケンシャル読み取りが550 MB/s付近で止まる場合は、SATAリンクの特徴です。単一のデバイスでは実現できないほど大きな値が出る場合は、経路上でキャッシュされています。ほとんどの場合、キャッシュはホスト上にあります。

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

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

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

ディスクI/OがボトルネックになっているVPSの状態

CPUがアイドル状態で、ロードアベレージが高く、vmstat の大きな wa がある場合、プロセスはディスクI/Oの完了待ちでキューに入っています。最も明確なカーネルの兆候は、dmesg -T に記録される次のメッセージです。

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

この行は、カーネルスレッドがストレージの応答を2分以上待ったために表示されます。hung task watchdogがこの状態を記録しています。jbd2 はext4のジャーナルスレッドです。つまり、動作不良のプログラム1つではなく、ファイルシステム全体が待機していました。VPSでは通常、ストレージバックエンドの性能、またはIOPSの許容量を使い切ったことを示します。

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

ディスクが制約になる場合の対処

IOPS を購入する前に RAM を購入します。 ワーキングセットがページキャッシュに収まる場合、読み取りがディスクに到達しなくなります。メモリを倍増するほうが、高速なストレージクラスへ移行するより効果的なことが多く、通常は費用も低くなります。

データが許容する場合は、フラッシュ回数を減らします。 PostgreSQL では、synchronous_commit = off により、書き込みがディスク上に存在する前にコミットを返せます。サーバーが停止すると、直前の一部のトランザクションが失われる可能性があります。write-ahead log は順序どおりに書き込まれるため、データベースは破損しません。このトレードオフは分析用コピーには適していますが、決済処理には適していません。MySQL の innodb_flush_log_at_trx_commit = 2 も同じトレードオフです。

小さなファイルをまとめます。 100万個の小さなファイルの転送やバックアップでは、ファイルごとの処理コストが大部分を占めます。そのため、先にアーカイブして1つのストリームとして移動するほうが、遅延の大きいストレージ上でツリーをファイル単位でコピーするより高速です。

シンボリュームで discard が機能する状態を維持します。 シンプロビジョニングされたストレージでは、ファイルシステムが通知するまで、バックエンドはブロックが空いたことを認識できません。trim を一度も実行しないボリュームでは、書き込み性能が徐々に低下します。Ubuntu には、これを実行する週次タイマーが用意されています。

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av は、マウントポイントごとに trim されたバイト数を出力します。discard 操作がサポートされていないというメッセージは、仮想ディスクが discard をホストに転送していないことを示します。この場合、修正する必要はありません。

IO スケジューラのチューニングは省略します。 virtio ディスクでは、cat /sys/block/vda/queue/scheduler によって通常すでに none が表示されます。実際のスケジューリングはアクセスできないホスト上で行われます。noatime も省略します。Ubuntu はデフォルトで relatime を使用してマウントするため、ほぼすべての atime 書き込みをすでに回避できます。

プランの選択

データベース、メールサーバー、CI runner、またはパッケージを大量に使用するビルドをサーバー上で実行する場合は、NVMe に料金を支払う価値があります。キャッシュされた Web サイトや、処理時間の大半を外部呼び出しに費やすアプリケーションに、割増料金を支払う必要はありません。判断に迷う場合、ディスクがボトルネックである可能性は低いです。ほとんどの小規模な VPS ワークロードでは、まず RAM または帯域幅が不足します。

新しい VPS で最初の 10 分間に行う作業を進めながら、初日に測定し、結果をファイルに保存してください。ベースラインがあれば、後からホストの速度が低下したのか、それともコードに問題があるのかを確認できます。ストレージクラスと IOPS の上限を明記しているプロバイダーを選んでください。プランに NVMe と記載されていて、queue depth 1 の読み取りに 4 ms かかる場合、そのホストには NVMe が搭載されていますが、ストレージはネットワークストレージです。これは販売方法としては妥当ですが、購入するものとしては別物です。

FAQ

VPSではNVMeは常に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処理時間と帯域幅によって決まります。サイトがリクエストごとに書き込む場合、ディスクが再びクリティカルパスになります。たとえば、データベースを使用するカートが頻繁にコミットすると、各コミットはフラッシュの完了を待つ必要があります。

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

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

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

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