Random IOPSとSequential IOPSの違いと、ベンチマーク結果の読み方

この文書の適用条件

そのまま実行できるコマンド

# 対象: Linux + fio 3.x
# 権限: 対象ファイルへの読み取り権限（デバイス直接指定なら root）
# 変更作業: なし（読み取りのみ）だが実行中は他処理の I/O 性能に影響する
# Production 実行: 非推奨。検証環境で実行すること
fio --name=rand_read_4k \
    --filename=/mnt/testdir/fio_testfile \
    --size=64G \
    --rw=randread \
    --bs=4k \
    --ioengine=libaio \
    --direct=1 \
    --iodepth=32 \
    --numjobs=4 \
    --runtime=300 \
    --time_based \
    --ramp_time=30 \
    --group_reporting

# 対象: Linux + fio 3.x
# 権限: 対象ファイルへの読み取り権限
# 変更作業: なし（読み取りのみ）だが I/O 帯域を占有する
# Production 実行: 非推奨。検証環境で実行すること
fio --name=seq_read_1m \
    --filename=/mnt/testdir/fio_testfile \
    --size=64G \
    --rw=read \
    --bs=1M \
    --ioengine=libaio \
    --direct=1 \
    --iodepth=8 \
    --numjobs=1 \
    --runtime=300 \
    --time_based \
    --group_reporting

# 対象: Linux + fio 3.x
# 権限: 対象ファイルへの読み書き権限
# 変更作業: あり（テストファイルに書き込む。既存データを指定しないこと）
# Production 実行: 不可。専用の検証領域でのみ実行すること
fio --name=rand_rw_70_30 \
    --filename=/mnt/testdir/fio_testfile \
    --size=64G \
    --rw=randrw \
    --rwmixread=70 \
    --bs=8k \
    --ioengine=libaio \
    --direct=1 \
    --iodepth=32 \
    --numjobs=4 \
    --runtime=600 \
    --time_based \
    --ramp_time=60 \
    --group_reporting

# 対象: Linux（sysstat / nvme-cli）
# 権限: 一般ユーザー（nvme list は root が必要な場合がある）
# 変更作業: なし（参照のみ）
# Production 実行: 可能
lsblk -o NAME,SIZE,TYPE,ROTA,MOUNTPOINT,MODEL
sudo nvme list
iostat -x 1 10

結果の読み方

こういう状況で使います

• 製品カタログのIOPS値と、自分で測った値が大きく違う
• 同じストレージなのに、測る人によって数値が何倍も変わる
• ベンチマークでは速いのに、データベースの処理が期待ほど速くならない
• SATA SSDからNVMe SSDに替えたが、体感が変わらない
• NVMeを多数搭載した構成にしたのに、本数に比例して性能が伸びない
• シーケンシャルの数値とランダムの数値のどちらを見るべきか分からない

考えられる原因（可能性の高い順）

1. 01

   IOPSという数値が単独では定義されていない

   IOPSは「1秒あたりのI/O回数」でしかなく、1回のI/Oのサイズ、同時に発行しているI/Oの数（キュー深度）、読み書きの比率、キャッシュを迂回しているかどうかが決まって初めて意味を持ちます。この4つが揃っていない数値同士は比較できません。

2. 02

   HDDでは物理動作がランダムアクセスを支配する

   回転メディアでは、1回のランダムI/Oごとにヘッドの移動（シーク）とセクタが回ってくるまでの待ち（回転待ち）が発生します。シーケンシャルアクセスではこれがほぼ発生しないため、同じデバイスでもランダムとシーケンシャルで桁違いの差が出ます。

3. 03

   SSD/NVMeでも差はゼロにならない

   機械動作が無いためランダムとシーケンシャルの差はHDDより大幅に小さくなりますが、フラッシュのページ／ブロック構造、ライトアンプリフィケーション、ガベージコレクション、マッピングテーブルの参照コストがあるため差は残ります。特に書き込みでは、空き領域が減った定常状態と、初期状態とで数値が変わります。

4. 04

   SATA（AHCI）とNVMeではキュー構造が違う

   AHCIは基本的に単一のコマンドキューを持つ設計で、同時に発行できるコマンド数が限られます。NVMeは多数の深いキューをCPUコアごとに持てる設計です。この差が効くのは高並列時であり、キュー深度1の逐次アクセスでは差は小さくなります。「NVMeにしたのに速くならない」場合、測定条件が低並列である可能性があります。

5. 05

   ベンチマークがキャッシュを測っている

   `direct=1` の指定が無い、テストサイズがRAMより小さい、実行時間が短くウォームアップだけで終わっている、といった条件では、測っているのはページキャッシュやコントローラのライトバックキャッシュです。

6. 06

   データベースのアクセスパターンと測定条件が合っていない

   データベースのデータファイルへのアクセスは一般にランダム寄り、トランザクションログへの書き込みはシーケンシャルかつ同期的です。ログ書き込みはIOPSやスループットではなく書き込みレイテンシが効きます。シーケンシャルリードの数値が良くても、この2つの性能は保証されません。

確認手順

1. 1

   実ワークロードのI/O特性を先に測る

   参照のみ

   `iostat -x` で `rareq-sz`・`wareq-sz`（平均I/Oサイズ）、`r/s`・`w/s`、`aqu-sz`（キュー長）を取得します。ベンチマークの条件はこれに合わせます。

2. 2

   デバイス構成を確認する

   参照のみ

   `lsblk -o ...,ROTA,MODEL` と `nvme list` で、測定対象が何なのか（HDDかSSDか、ローカルかネットワーク接続か）を確定します。

3. 3

   測定条件を明記した状態でfioを流す

   低

   `--bs`・`--iodepth`・`--numjobs`・`--rw`・`--direct=1` を明示し、条件をそのまま記録します。条件の記録がないベンチ結果は後から解釈できません。

4. 4

   キュー深度を変えた複数点で測る

   低

   iodepthを変えながらIOPSとレイテンシの両方を記録します。IOPSが頭打ちになった後もレイテンシだけが伸びる点が、実用上の上限です。

5. 5

   書き込みは定常状態まで走らせる

   中

   SSDでは短時間の測定だと初期状態の値しか出ません。`--runtime` を長く取り、`--ramp_time` で立ち上がりを除外します。

6. 6

   多数デバイス構成では層ごとに切り分ける

   低

   単体デバイス、RAID/ボリューム層、ファイルシステム層、アプリケーション層の順に測り、どこで頭打ちになるかを特定します。

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• CPUが飽和していないか確認する

  高IOPSの測定では割り込み処理とI/O発行でCPUを使い切ることがあります。`iostat`と併せて`mpstat`でCPU使用率を確認してください。

• I/Oスケジューラの設定を確認する

  NVMeでは`none`が適切な場合が多く、回転メディア向けスケジューラのままだと不要な並べ替えが入ります。

• ファイルシステムのアライメントを確認する

  パーティションやストライプの境界がずれていると、1回の論理I/Oが複数の物理I/Oに分割されます。

• アプリケーションの同時実行数を確認する

  ストレージが上限に達していないのに遅いなら、律速はアプリケーション側の並列度かロック競合です。

• 比較対象の測定条件を入手する

  他所の数値と比べる場合、その測定のbs・iodepth・numjobs・rw・direct指定が公開されているかを確認します。公開されていない数値とは比較できません。

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• SATA SSDとNVMe SSDのRandom Read IOPSの違い
• 24本のNVMe SSD構成でボトルネックになる箇所
• ベンチマークのIOPS値が製品カタログと違う理由
• データベースはランダムI/Oとシーケンシャルのどちらが重要か

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

ここまでの内容は、測定条件さえ揃えれば誰でも再現できます。実運用で難しいのは、正しく測ることではなく、測った条件を記録して次の測定と比較できる状態を維持することです。GIIPではAWSとAzure上の複数データベースおよび約30のWebサービスについて、I/Oサイズ・キュー長・待ち時間をAIエージェントが同一条件で継続収集し、過去の分布と比べて外れた時点で人間の専門家が原因を切り分けています。単発のベンチマーク値ではなく、同じ条件で取り続けた時系列を判断材料にするための仕組みです。

関連サービス

• データベース性能チューニング
• 構成と測定条件について相談する