IOPSとは？計算式とスループット・レイテンシの違い、目安とSSD/クラウドの性能設計

IOPS（アイオプス、Input/Output Operations Per Second）は、ストレージが1秒間に処理できる読み書き（I/O）の回数です。回数だけを数える指標なので、1回で運ぶデータの大きさ（ブロックサイズ）を掛けて初めてスループット（MB/s）になり、同時に何件の要求を流しているか（キューデプス）とレイテンシで上限が決まります。この記事では、IOPSの計算式とスループット・レイテンシとの違い、HDD・SSDの目安を整理したうえで、fioでキューデプスを変えながら測った実測値と、AWS EBS（gp3・io2）の2026年10月時点の上限、インスタンス側で頭打ちになる条件までを扱います。

まとめ｜IOPSの読み方と設計で外さない結論

IOPSは「1秒あたりの回数」、スループットは「1秒あたりの転送量」、レイテンシは「1回の応答時間」です。3つは別々の量ではなく、スループット＝IOPS×ブロックサイズと同時に処理中のI/O数＝IOPS×レイテンシ（リトルの法則）の2本の式でつながっています。4KiBのランダム読み込みで10,000 IOPSなら約40MiB/s、レイテンシが0.5ミリ秒なら常時5件の要求が流れている計算です。

目安は桁で覚えます。HDDのランダムIOPSはシークと回転待ちに縛られて1台で百前後にとどまり、SSDは機械的な待ちが無いため、同時に流す要求数に応じて桁が変わります。ただし、カタログの最大IOPSの測定条件は製品ごとに異なります。高い並列度で測った最大値を、1件ずつ処理するアプリの性能として使うことはできません。今回のfio実測でも、同じNVMe SSDがキューデプス1では約2,000 IOPS、並列64では約87,000 IOPSと40倍以上の差になり、並列64ではレイテンシの中央値がキューデプス1の約1.8倍になりました。

クラウドでは、ボリュームに買ったIOPSがそのまま出るとは限りません。AWS EBSのgp3は2026年10月時点で最大80,000 IOPS・2,000MiB/sまで指定できますが、EC2インスタンス側にも上限があり、m7i.largeは常時3,600 IOPS（16KiB換算）です。IOPSを増やす前に、I/Oサイズ・ランダム比率・同時要求数・許容レイテンシを測り、どこで頭打ちになっているかを確かめるのが順番です。

IOPSとは｜読み方と「1回のI/O」が指すもの

IOPSの読み方と定義

IOPSは「アイオプス」と読むのが一般的で、「アイオーピーエス」と1文字ずつ読む人もいます。Input/Output Operations Per Secondの略で、ストレージが1秒間に完了させた入出力操作の回数を表します。ホスト側から見たInputは読み込み、Outputは書き込みにあたり、IOPSの値は読み込みと書き込みを合わせて数える場合と、読み込みIOPS・書き込みIOPSを分けて示す場合があります。製品の仕様書で「ランダムリード○○IOPS」と書かれていれば、読み込みだけを数えた値です。

計算そのものは単純で、完了したI/Oの回数を経過秒数で割ります。60秒間に180,000回の読み書きが完了したなら、180,000÷60＝3,000 IOPSです。

1回のI/Oの大きさ（ブロックサイズ）で値が変わる理由

1回のI/Oで運ぶデータ量は用途で大きく違います。PostgreSQLのページは既定で8KiB、MySQL（InnoDB）は16KiBで、データベースは小さなI/Oを大量に出します。動画の書き出しやバックアップは数百KiB〜数MiBの大きなI/Oを少数出します。同じストレージでも、ブロックサイズを変えるとIOPSとスループットは変化します。ブロックを大きくするとスループットが上がる場合がありますが、転送帯域の上限に達すると頭打ちになります。IOPSの数字を比べるときは、必ず「何KiBのI/Oで、ランダムかシーケンシャルか、読み込みか書き込みか」をそろえる必要があります。仕様書のIOPSの多くは4KiBのランダムI/Oで測られています。HDDとSSDの構造の違いそのものはストレージの種類とHDD/SSDの違いの解説で整理しています。

IOPSの計算式｜スループット換算・HDDの理論値・必要IOPSの見積もり

スループット＝IOPS×ブロックサイズの換算

IOPSとスループットは、ブロックサイズを掛けるだけで相互に換算できます。単位の混同（KB/KiB、MB/MiB）で数%ずれるので、ここではfioやAWSの表記に合わせて2の累乗（1KiB＝1,024バイト）で計算します。

逆算もできます。CrystalDiskMarkのように結果をMB/sで表示するツールなら、4KiBランダムの結果（MB/s）×1,000,000÷4,096でIOPSに直せます。たとえばRND4Kで200MB/sなら約48,800 IOPSです。この換算から分かるのは、小さなI/Oではスループットが小さく見えてもIOPSは高い、ということです。4KiBで40MiB/sしか出ていないディスクを「遅い」と判断するのは早計で、10,000 IOPSを出している可能性があります。

回転数とシーク時間によるHDDのIOPS概算

HDDのランダムIOPSは、1回のI/Oにかかる時間の逆数で概算できます。1回の時間は「平均シーク時間＋平均回転待ち時間＋転送時間」で、平均回転待ちは1回転の半分です。7,200rpmなら1回転が60÷7,200＝約8.33ミリ秒なので回転待ちは約4.17ミリ秒、15,000rpmなら約2ミリ秒になります。

シーク時間は製品ごとに違うので、実際の計算には仕様書の平均シーク時間を入れてください。4KiBの転送時間は0.1ミリ秒以下で、分母のほとんどは機械的な待ち時間です。HDDのIOPSが製品を問わず百前後に収まるのはこのためで、SSDは機械的な待ちが無いので分母がマイクロ秒単位まで縮みます。

必要IOPSの見積もりとRAIDの書き込みペナルティ

システムに必要なIOPSは、アプリが出す読み込みと書き込みの回数から逆算します。RAIDを組む場合は、1回の書き込みに対してディスク側で何回のI/Oが発生するか（書き込みペナルティ）を掛けます。ミラーのRAID1・RAID10は2回、パリティを1つ持つRAID5は旧データと旧パリティの読み込み＋新データと新パリティの書き込みで4回、パリティを2つ持つRAID6は6回です（DellのSCシリーズ資料の表も同じ値です）。

ディスク側に必要なIOPS＝読み込みIOPS＋書き込みIOPS×書き込みペナルティ

表はアプリ側の読み込み2,000 IOPS・書き込み1,000 IOPSについて、小さなランダム書き込みと均等な負荷分散を仮定した理論上の下限台数です。RAID5・6ではread-modify-writeを想定しており、フルストライプ書き込みやキャッシュ、再構築時の負荷、実装上の構成制限は含めていません。書き込みが3分の1あるだけで、RAID6はRAID10の2倍のディスクを要します。書き込みの多いデータベースでRAID10が選ばれるのはこの差のためで、HDDで数千IOPSを組むより、SSD数台で済ませる方が台数・電力の両面で現実的です。RAIDレベルごとの構成と許容故障台数はRAID0/1/5/6/10の違いと構成の解説で、ピーク負荷から台数と余裕率を決める手順はキャパシティプランニングの手順で扱っています。

IOPSとスループット・レイテンシの違い

IOPS・スループット・レイテンシの単位と適した処理

どれを基準に設計するかは、I/Oの大きさで決まります。数KiB〜数十KiBのI/Oが中心ならIOPSが先に上限に達し、数百KiB以上ならスループットが先に上限に達します。AWSのEBSドキュメントも、IOPSとスループットの上限は互いに依存し、I/Oサイズによってどちらか一方に先に達すると説明しています。レイテンシの一般的な意味やレスポンスタイムとの違いはレイテンシーとレスポンスタイムの違いの解説を参照してください。

リトルの法則によるIOPSと平均レイテンシの関係

IOPSとレイテンシの関係は、待ち行列理論のリトルの法則で表せます。

平均未完了I/O数（平均キューデプス）＝平均IOPS×平均レイテンシ（秒）。各値は同じ観測範囲・期間にそろえます。

キューデプス1、つまり1件の応答を待ってから次を出す処理では、IOPSはレイテンシの逆数が上限です。レイテンシ0.5ミリ秒なら2,000 IOPS、1ミリ秒なら1,000 IOPSにしかなりません。逆に、16,000 IOPSを1ミリ秒で出すには、常に16件の要求が流れている必要があります。AWSもEBSの性能を安定させる目安として、プロビジョンドIOPS 1,000ごとに平均キュー長1を保つよう案内しており、3,000 IOPSのボリュームなら平均キュー長3です。これはレイテンシ1ミリ秒でリトルの法則を当てた値と一致します。

この式は、性能が出ない原因の切り分けにも使えます。ストレージに余力があるのにIOPSが伸びないなら、アプリ側の並列度が足りないか、どこかで同時要求数が制限されています。次の章の実測では、まさにこの式で「指定したキューデプスがOSで削られていた」ことが分かりました。

ランダムアクセスとシーケンシャルアクセスの差

シーケンシャルアクセスは連続した領域を順に読み書きし、ランダムアクセスは離れた位置を飛び飛びに読み書きします。HDDではランダムのたびにシークと回転待ちが入るため、シーケンシャルで200MB/s前後を出すディスクでも、4KiBランダムでは百前後のIOPS、つまり1MB/s未満に落ちます。SSDでも差はあり、AWSのEBSは物理的に連続した小さなI/Oをまとめて1回と数える（SSD系は最大256KiB）ため、同じデータ量でもシーケンシャルの方が消費IOPSが少なく済みます。データベースのインデックス参照や行の更新はランダムI/Oなので、シーケンシャルの数値だけで用途の実力を判断すると大きく外れます。

fioでIOPSを実測する｜キューデプス別の結果と落とし穴

仕様書やカタログのIOPSは、測定条件をそろえないと比べられません。ここでは、Linux・macOS・Windowsで動くベンチマークツールfioを使い、同じSSDでキューデプスと並列数を変えて測りました。

測定環境とfioのコマンド

測定はIntel Core i9-9880H搭載のMac（内蔵NVMe SSD APPLE SSD AP1024N、macOS 26.6.2）で、fio 3.43（2026年9月23日リリース）を使いました。4GiBのテストファイルに対して、ページキャッシュを通さない設定（direct=1）で各15秒測っています。macOSにはLinuxのlibaio・io_uringが無いので、I/OエンジンはPOSIX AIO（posixaio）です。測定中も別の処理が動いていたため、99パーセンタイル値には揺らぎがあります。

mkdir -p /tmp/fio14683
fio --name=rr_qd32 --filename=/tmp/fio14683/testfile --size=4g \
    --rw=randread --bs=4k --ioengine=posixaio --iodepth=32 --numjobs=1 \
    --direct=1 --runtime=15 --time_based --group_reporting

主なオプションは、rw（randread・randwrite・randrwなどのアクセスパターン）、bs（ブロックサイズ）、iodepth（1ジョブあたりの同時要求数）、numjobs（並列に走らせるジョブ数）、direct=1（キャッシュを通さない）です。Linuxで測るときはioengine=libaioかio_uringに置き換えます。データベースを想定するなら、bsを8kや16kにし、rw=randrwとrwmixreadで読み書きの比率を本番に合わせます。

キューデプスと並列数を変えた4KiBランダム読み込みの結果

表の平均レイテンシはfioのlat、中央値はclatの50パーセンタイルです。実効並列度は、測ったIOPSと平均レイテンシからリトルの法則で逆算した値です。キューデプス1の2,002 IOPSは、平均レイテンシ492μsの逆数（約2,030）とほぼ一致します。同じSSDでも、1件ずつ処理する使い方では2,000 IOPSしか出ず、並列64で約87,000 IOPSまで伸びました。その代わり並列64では中央値が264μsから457μsへ、99パーセンタイルは3.3ミリ秒から16.9ミリ秒へ悪化しています。今回の4ジョブから8ジョブへの比較では、IOPSの増加とともに中央値・99パーセンタイルが悪化しました。ただし、各15秒の測定で他の処理も動いていたため、並列度だけの影響を判断するには反復測定が必要です。

参考として、同じ環境で4KiBランダム書き込み（iodepth=32）は9,445 IOPS・平均1.66ミリ秒、1MiBのシーケンシャル読み込み（iodepth=8）は1,733 IOPS・1,732.6MiB/sでした。シーケンシャルではIOPSが小さくても、スループットは4KiBランダムの10倍に達します。

指定したiodepthと実効並列度の差：OS側の上限

表のiodepth=16・32・64は、IOPSも実効並列度もほとんど変わりません。キューデプスを32や64に指定しても、実際に同時に流れていたI/Oは約15件でした。fioの出力にある「IO depths」の分布でも、iodepth=32の測定は8件台が69.1%、16件台が30.1%で、32件に達したI/Oは0%です。原因はmacOSのカーネル設定で、sysctlで確認したkern.aioprocmax（1プロセスあたりの非同期I/O要求数の上限）が16でした。fioは既定でジョブごとに別プロセスを起動するため、ジョブを4本・8本に分けると上限を回避でき、実効並列度は31.3、62.5まで上がりました。

fioの公式ドキュメントも、iodepthについて「非同期エンジンでもOSの制約で指定した深さに届かないことがある」「LinuxでlibaioをDirect I/Oなしで使うとバッファードI/Oは非同期にならない」と注意し、出力のI/O深さ分布で実際の深さを確認するよう求めています。ベンチマークで「キューデプスを上げてもIOPSが伸びない」ときは、ストレージの限界と決めつける前に、IO depthsの分布とリトルの法則で実効並列度を確かめてください。同じことは本番のアプリにも当てはまり、接続プールやスレッド数で同時要求数が絞られていれば、ストレージに余力があってもIOPSは上がりません。

IOPS測定の誤差要因：キャッシュ・並列度・測定時間

• direct=1を付けずに測り、OSのページキャッシュの速さをディスクの性能と取り違える（ファイルサイズを搭載メモリより大きくするのも有効です）
• キューデプス32の最大値だけを見て、キューデプス1〜4で動くアプリの性能を見積もる
• SSDを空の状態で短時間だけ測り、書き込みを続けたときの持続性能を見ない
• シーケンシャル1MiBのMB/sだけを見て、データベースのランダムI/Oの実力を判断する

Windowsのローカル確認にはCrystalDiskMarkが手軽ですが、RND4K Q32T1（キューデプス32・1スレッド）とRND4K Q1T1の差は上の表と同じ構造です。アプリの実際の同時要求数に近いのはQ1T1側であることが多く、こちらを基準にした方が体感とずれません。キャッシュがI/O性能に与える影響はディスクキャッシュの仕組みの解説で扱っています。

IOPSの目安｜HDD・SSD・NVMeの桁とクラウドの上限

デバイス別のランダムIOPSの目安

SSDの仕様書に載る最大IOPSは、製品ごとに指定されたキューデプス・スレッド数で測った値です。測定条件を確かめ、アプリが同じ並列度でI/Oを出すかを照合してから使います。同じSSDでも、上の2行のように並列度だけで40倍以上の差が出ます。データベースの必要IOPSは、ピーク時の実測IOPS、読み書き比率、キャッシュヒット率、許容レイテンシから見積もります。Webアプリかどうかだけで数千・数万という設計値は決められません。

AWS EBS gp3・io2のIOPSとスループットの上限（2026年10月時点）

gp3は容量と切り離して、追加料金なしでベースライン3,000 IOPS・125MiB/sを持ち、追加料金で80,000 IOPSまで引き上げられます（AWSのgp3ドキュメント）。ベースラインの3,000 IOPSを超える設定には容量1GiBあたり500 IOPSの上限が適用されるため、80,000 IOPSには160GiB以上、2,000MiB/sには8,000 IOPS以上の指定が必要です。gp3の上限はかつて容量16TiB・16,000 IOPS・1,000MiB/sで、2025年9月26日の発表で現在の値に引き上げられました。古い解説記事には16,000 IOPSの値が残っていますが、2026年10月時点でこの上限が残るのはAWS Outposts上のgp3だけです。io2は2025年4月30日以降すべてBlock Expressになり、256,000 IOPSを使えるのはNitroベースのインスタンスです（AWSのio2ドキュメント）。

容量とIOPSを別々に買う方式は他のクラウドも同じです。AzureのPremium SSD v2は容量・IOPS・スループットを個別に設定でき、最大80,000 IOPS（160GiB以上）・2,000MB/sです（Azureのディスクの種類）。Google CloudのHyperdisk Balancedは1ボリュームで最大160,000 IOPS（320GiB以上）・2,400MiB/sで、使用中にも性能設定を変更できます（Hyperdisk Balancedのドキュメント）。

EBSのI/Oサイズ別の分割・結合とIOPSの数え方

EBSでは、SSD系のボリュームは1回のI/Oを最大256KiB、HDD系（st1・sc1）は最大1,024KiBとして数えます。アプリが1MiBのI/Oを1回出すと、SSD系では256KiB×4回に分割され4 IOPSを消費します。逆に、物理的に連続した32KiBのI/Oが8回続けば、まとめて256KiBの1回として数えられます（EBSのI/O特性のドキュメント）。gp3の「80,000 IOPS」と「2,000MiB/s」を同時に満たすI/Oサイズは2,000MiB÷80,000＝25.6KiBで、これより大きいI/Oではスループットの上限に、小さいI/OではIOPSの上限に先に当たります。

EC2インスタンス側のEBS性能上限とバースト条件

EC2から見たEBSの性能は、インスタンスタイプの上限と、接続したボリュームの合計性能のうち小さい方で決まります。ボリュームのIOPSを上げても、インスタンスがEBSへ出せるIOPS・帯域の上限は超えられません。EBS最適化インスタンスの一覧では、m7i.largeのEBS性能はベースラインが3,600 IOPS（16KiB I/O）・81.25MB/s（128KiB I/O）、最大が40,000 IOPS・1,250MB/sです。最大値は24時間に少なくとも1回、30分間持続できる値で、その後はベースラインに戻ります。m7i.largeに16,000 IOPSのgp3を付けると、短時間のバーストを過ぎた後は3,600 IOPS付近で頭打ちになり、追加で買ったIOPSの大半は使われません。m7i.4xlargeはベースラインが20,000 IOPS・625MB/sなので、例えば16KiB I/Oで16,000 IOPSを継続する構成はインスタンス側の両上限内に収まります。ただし、gp3側にも必要なスループットを設定し、アプリが十分なI/Oを発行する必要があります。インスタンスタイプの命名規則と選び方はAWSのインスタンスタイプの選び方で整理しています。

IOPSを増やす前に確認すること｜失敗パターンと判断基準

「遅いからIOPSを増やす」は、条件がそろわないと費用だけが増えます。次の順で確かめれば、どこに手を入れるべきかが決まります。

1. I/Oの大きさとランダム比率を測る。Linuxならiostat -xの読み書き回数・平均I/Oサイズ・待ち時間、AWSならCloudWatchでVolumeReadOpsとVolumeWriteOpsのSumを期間の秒数で割ってIOPSを求め、VolumeReadBytes・VolumeWriteBytesから平均I/Oサイズ、VolumeQueueLengthから平均キュー長を確認する
2. IOPSとスループットのどちらが上限に当たっているかを判定する。平均I/Oサイズ×IOPSが上限スループットに近いならスループット律速
3. 平均IOPS×平均レイテンシ（秒）から実効並列度を求め、平均キュー長と照合する。ストレージの上限より手前でIOPSが止まり、キュー長が1前後なら、アプリ側の並列度制限や要求数そのものの少なさを確認する
4. インスタンス側のEBS上限、RAIDの書き込みペナルティ、OS・ドライバの上限を確認する
5. ここまで確認してストレージ自体が上限なら、NVMe化・RAIDレベルの変更・プロビジョンドIOPSの引き上げに進む

IOPSを増やしても効かないのは、遅さの原因がストレージに無いケースです。データベースならインデックスの欠落による全件走査、ロック待ち、メモリ不足でキャッシュに載らないことが原因で、I/O回数そのものを減らす方が効きます。HDDのRAID5で書き込み待ちが支配的だと確認できた場合は、SSD化やRAID10への変更を比較します。変更前に不要なI/Oの削減効果も測り、容量・冗長性・費用の条件を満たす構成を選びます。

ワークロードに見合うストレージ性能の設計や、オンプレミスからクラウドへの移行に伴うIOPS要件の見直しは、性能測定と構成設計をまとめて進めると過剰投資を避けられます。一創ではAWS・Google Cloud・Azureのインフラ構築として、ストレージ性能の要件整理から構成設計・運用まで支援しています。

IOPSに関するよくある質問

IOPSは何と読みますか？

「アイオプス」と読むのが一般的です。Input/Output Operations Per Secondの頭文字で、「アイオーピーエス」と読まれることもあります。

IOPSはどのくらいあれば足りますか？

用途の実測値から逆算します。ピーク時の読み込み・書き込み回数を測り、RAIDなら書き込みペナルティ（RAID10は2、RAID5は4、RAID6は6）を掛け、余裕を足した値が目安です。必要IOPSは、ピーク時の要求数、読み書き比率、キャッシュヒット率、許容レイテンシによって変わるため、用途名だけでは決められません。

IOPSからスループットはどう計算しますか？

スループット＝IOPS×ブロックサイズです。4KiBで10,000 IOPSなら約39MiB/s、1MiBで2,000 IOPSなら2,000MiB/sになります。逆にMB/sからIOPSを出すときは、ブロックサイズで割ります。

IOPSとスループットはどちらを見ればよいですか？

I/Oの大きさで決まります。数KiB〜数十KiBのランダムI/Oが中心のデータベースや仮想化ではIOPS、数百KiB以上の連続I/Oが中心のバックアップや動画処理ではスループットを見ます。AWSのgp3を80,000 IOPS・2,000MiB/sに設定した場合は25.6KiBが分かれ目です。設定値が異なる場合は、スループット上限をIOPS上限で割って求めます。

SSDのIOPSは仕様書どおりに出ますか？

測定条件によって異なります。仕様書の最大IOPSは製品ごとに指定されたキュー深度・スレッド数で測った値で、本記事の実測でもNVMe SSDがキューデプス1では約2,000 IOPS、並列64では約87,000 IOPSでした。アプリが出す同時要求数に近い条件で測った値を設計に使います。

関連記事

• ストレージとは？種類・HDDとSSDの違い・企業のクラウド選定まで解説【2026年】
• RAIDとは？RAID0/1/5/6/10の違いと構成・企業のディスク冗長化設計を実装目線で解説【2026年版】
• キャパシティプランニングとは？ピーク負荷から必要台数と余裕率を見積もる手順
• レイテンシーとは？レスポンスタイムとの違い・原因・目安と改善方法
• オブジェクトストレージとは？仕組み・S3互換APIの範囲とブロックとの違いを実装手順つきで解説