VM パフォーマンス Day4 – ストレージ I/O 最適化と virtio / raw / qcow2 / io_uring の考え方

VM のストレージ I/O は、ゲスト OS から見るとディスクアクセスですが、実際には仮想デバイス、QEMU、ホスト OS、ファイルシステム、物理ストレージを通る多段の経路です。

そのため、ストレージ I/O 最適化では単に高速な SSD を使うだけでは不十分です。どの仮想ディスク方式を使うか、どのイメージ形式にするか、ホスト I/O スタックをどこまで通すか、管理機能をどこまで残すかを設計する必要があります。

Day4 では、virtio-blk / virtio-scsi、raw / qcow2、io_uring、NVMe passthrough を、性能と運用性の交換として整理します。

ストレージ I/O の経路を分けて見る

一般的な VM のストレージ I/O は、ゲスト OS から仮想デバイスへ送られ、QEMU とホスト OS の I/O スタックを経由して物理ストレージへ届きます。

レイヤ	見る内容	主なボトルネック
ゲスト OS	ファイルシステム、I/O パターン、キュー深度	同期 I/O、細かいランダム I/O
仮想デバイス	virtio-blk / virtio-scsi	仮想キュー処理、デバイス選択
QEMU	I/O thread、キャッシュ、非同期 I/O	ユーザー空間処理、設定不整合
ホスト OS	ファイルシステム、I/O スケジューラ、io_uring	ホスト側待ち、キュー詰まり
物理ストレージ	NVMe / SSD / 共有ストレージ	デバイス性能、レイテンシ、帯域

性能問題を調べるときは、VM 内のディスク使用率だけでなく、ホスト側の I/O 待ち、キュー深度、レイテンシ、ストレージバックエンドの状態も合わせて見る必要があります。

virtio-blk と virtio-scsi の違い

KVM 環境では、仮想ディスクのデバイスとして virtio-blk と virtio-scsi がよく使われます。どちらが絶対に速いというより、構成の単純さと運用機能のどちらを重視するかで選びます。

方式	特徴	向く用途
virtio-blk	構造が単純でオーバーヘッドが少ない	単純な VM、少数ディスク、性能重視
virtio-scsi	複数ディスク、ホットプラグ、SCSI 機能を扱いやすい	多数ディスク、運用柔軟性重視

単純な VM であれば virtio-blk は扱いやすい選択肢です。一方、ディスク数が多い VM やホットプラグ、運用機能を重視する場合は virtio-scsi が向きます。

raw と qcow2 は性能と機能の交換である

仮想ディスクの形式では、raw と qcow2 の選択がよく問題になります。raw はシンプルで性能面の見通しがよく、qcow2 はスナップショットや thin provisioning などの機能を持ちます。

形式	利点	注意点
raw	構造が単純で性能特性を読みやすい	単体ではスナップショットなどの機能が少ない
qcow2	スナップショット、容量効率、検証用途に便利	メタデータ処理が入り、性能特性が複雑になる

本番の高性能 VM では raw を選び、バックアップやスナップショットはストレージ基盤側で持つ設計が分かりやすい場合があります。検証環境や柔軟性を重視する環境では qcow2 が便利です。

キャッシュ設定は性能だけで決めない

ストレージ I/O では、キャッシュ設定も重要です。ただし、キャッシュは速くするためだけの設定ではありません。障害時の整合性、書き込み保証、ホスト側キャッシュ、ストレージ側キャッシュの関係を考える必要があります。

• 性能だけを見るとキャッシュを使いたくなる
• 書き込み保証を重視するとキャッシュ設定は慎重になる
• ホスト側とストレージ側でキャッシュが重なる場合がある
• DB や重要データでは整合性を優先する
• ベンチマークと実運用の書き込みパターンを分けて考える

io_uring は I/O 経路を効率化する選択肢

新しい Linux 環境では、io_uring による非同期 I/O が選択肢になります。io_uring は、従来の I/O 処理よりも効率的に非同期 I/O を扱うための仕組みです。

ただし、io_uring の効果は QEMU、カーネル、ストレージバックエンド、VM の I/O パターンに依存します。設定しただけで常に速くなるものではなく、対象ワークロードで測定して判断する必要があります。

• 非同期 I/O の効率化に向く
• QEMU やカーネルの対応状況に依存する
• ストレージバックエンドとの組み合わせで効果が変わる
• ランダム I/O、キュー深度、レイテンシを分けて測る

NVMe passthrough は最短経路だが制約も大きい

NVMe passthrough は、物理 NVMe デバイスを VM に直接割り当てる方式です。仮想ディスクや QEMU の経路を大きく迂回できるため、性能面では強力です。

一方で、ホスト側での柔軟な管理、ライブマイグレーション、スナップショット、共有ストレージとの組み合わせは難しくなります。これは SR-IOV や PCI Passthrough と同じく、高速化と運用自由度の交換です。

方式	得られるもの	失うもの
通常の virtio ディスク	管理性、移動性、柔軟性	一部の性能
raw + virtio	性能と管理性のバランス	高度なディスク機能
NVMe passthrough	短い I/O 経路と高性能	ライブマイグレーション、柔軟な管理

ストレージ最適化で確認すること

ストレージ I/O の最適化では、方式を選ぶ前に何を改善したいのかを明確にします。スループットなのか、レイテンシなのか、IOPS なのか、安定性なのかで選ぶ技術は変わります。

• 遅いのは VM 内か、ホスト側か、ストレージ基盤側か
• 問題は throughput、IOPS、latency のどれか
• raw / qcow2 の機能差を理解しているか
• virtio-blk と virtio-scsi の運用差を理解しているか
• キャッシュ設定が障害時の整合性に与える影響を理解しているか
• NVMe passthrough による移動性低下を許容できるか

まとめ

VM のストレージ I/O 最適化は、単に高速なストレージを使うことではありません。ゲスト OS、virtio、QEMU、ホスト OS、物理ストレージのどこで待ちが発生しているかを分けて見る必要があります。

virtio-blk / virtio-scsi、raw / qcow2、io_uring、NVMe passthrough は、それぞれ性能、管理性、機能、移動性のバランスが違います。

ストレージ I/O では、最短経路を選ぶほど性能は上がりやすくなりますが、ホスト側での管理機能や運用自由度は下がります。Day5 では、同じ I/O でもネットワーク側に進み、virtio-net と仮想 NIC の構造を整理します。

VM パフォーマンスシリーズ

• VM パフォーマンス最適化 – NUMA / CPU / I/O / ネットワークの設計ハブ
• VM パフォーマンス Day1 – VM の性能ボトルネックとは何か
• VM パフォーマンス Day2 – CPU 最適化と NUMA / CPU ピニングの考え方
• VM パフォーマンス Day3 – メモリ最適化と HugePages / TLB / NUMA の考え方
• VM パフォーマンス Day5 – virtio-net の構造と仮想 NIC の性能特性
• VM パフォーマンス Day6 – vhost-net / vhost-user と kernel bypass の考え方
• VM パフォーマンス Day7 – SR-IOV / PCI Passthrough による仮想化の迂回
• VM パフォーマンス Day8 – DPDK による高速 dataplane と NFV の基本

関連記事

• CPU ピニングを外した瞬間、それはもう別のサービスである
• VyOS VPP 導入検討 – 実運用ルーターに VPP をそのまま適用する難しさ
• Ubuntu 22.04 OVS-DPDK 構築失敗