インフラ

IOPSとは?計算式とスループット・レイテンシの違い、SSD/クラウドの性能設計を実装目線で解説【2026年版】

IOPS(アイオプス)とは、ストレージが1秒間に処理できる入出力(I/O)操作の回数を表す性能指標です。この記事では、IOPSとスループット・レイテンシがどう違い、なぜ「IOPS×ブロックサイズ=スループット」で結びつくのかを整理したうえで、ランダムアクセスとシーケンシャルアクセスでIOPSが桁違いに変わる理由、HDDとSSDのIOPS差、RAIDレベルによる書き込みペナルティ、キューデプスを上げるとどこまで伸びてどこで頭打ちになるかまで、インフラ実装の目線で踏み込みます。さらに、AWSのEBS(gp3/io2)で使うプロビジョンドIOPSの考え方と、fioでの測定手順、そして「IOPSを増やせば速くなる」という思い込みに、条件付きで答えを出すのが本記事の狙いです。

目次

まとめ|IOPSの読み方とスループット・レイテンシとの役割分担の結論

IOPSは、ストレージへの読み書き要求を1秒間に何回さばけるかを示す数値で、単体で「速さ」を決めるものではありません。ストレージの性能は、1秒あたりの操作回数を表すIOPS、1秒あたりの転送量を表すスループット、1回の応答にかかる時間を表すレイテンシ、この3つの組み合わせで決まります。3者は「IOPS×1回あたりの転送サイズ(ブロックサイズ)=スループット」という式で結びつき、レイテンシはその裏側で、応答の待ち時間として効いてくる関係です。小さなデータを大量にさばくデータベースはIOPSが効き、大きなファイルをまとめて流す動画配信やバックアップはスループットが効く、という具合に、用途によって見るべき指標が変わります。

実務での判断はおおむね決まっています。ランダムで小さいI/Oが多いシステムはIOPSを基準に設計し、ここではSSD、とくにNVMeが桁違いに有利です。大容量を順番に流す用途はスループットを基準にし、HDDでも束ねれば足りる場面があります。そしてもう1つの結論は明快で、IOPSは大きければ良いという指標ではありません。キューデプス(同時に投げる要求数)を上げればIOPSの数字は伸びますが、その裏でレイテンシも伸び、応答が遅くなります。IOPSを増やす前に、ブロックサイズ・ランダム/シーケンシャルの比率・許容レイテンシを確認しないと、費用をかけてプロビジョンドIOPSを買っても体感が変わらない、という失敗につながります。IOPSは「どんなI/Oを、どれだけの応答時間で、いくつさばきたいか」という要件とセットで初めて意味を持つ数値です。

IOPSとは|ストレージが1秒間に処理する入出力(I/O)回数の指標

まず、IOPSが何を数えている値なのか、そしてどうやってスループットへ換算されるのかを押さえます。ここを取り違えると、以降のHDD/SSD比較やクラウドのIOPS設計がすべてずれます。

IOPSの定義と読み書き(Input/Output)が指す意味

IOPSは「Input/Output Per Second」の頭文字で、ストレージが1秒間に処理できる入出力操作の回数を指します。Iはインプット、つまりデータの書き込み、Oはアウトプット、つまりデータの読み込みを表し、この読み書き要求を1件ずつ数えたものがIOPSです。ここでいう1操作とは、アプリケーションやOSがストレージへ出す1回のI/O要求で、たとえば「4KBのブロックを1つ読む」が1操作にあたります。同じ1操作でも、扱うデータの大きさ(ブロックサイズ)は用途で変わり、データベースは4KB〜16KB程度の小さなブロックを大量に、ファイル転送は数百KB〜数MBの大きなブロックを少数、という傾向があります。IOPSはこの「操作の回数」だけを見る指標なので、1回でどれだけのデータを運んだかは含みません。だからこそ、次に説明するブロックサイズを掛け合わせて初めて、実際のデータ転送量であるスループットに換算できます。IOPSを測る対象となるHDD・SSDそのものの違いや容量の考え方はストレージの種類とHDD/SSDの違いの解説で整理しています。

IOPSの計算式とブロックサイズ・スループットへの換算の関係

IOPSとスループットは、ブロックサイズを介して換算できます。関係式は単純で、「スループット(バイト/秒)=IOPS×ブロックサイズ」です。たとえば4KBのブロックを毎秒5,000回処理できるなら、スループットは 5,000×4KB=約20MB/s になります。逆に、1MBの大きなブロックを毎秒200回処理すれば、IOPSは200と小さくても、スループットは 200×1MB=約200MB/s に達します。この関係が示すのは、IOPSとスループットは同じ現象を別の角度から見た値だということです。小さなブロックを大量にさばく用途ではIOPSが上限になり、大きなブロックをまとめて流す用途ではスループットが上限になります。単体HDDの理論IOPSは、1回のI/Oにかかる時間の逆数で概算でき、「IOPS≒1÷(平均シーク時間+平均回転待ち時間+転送時間)」で求めます。回転や物理移動を伴うHDDでは、この時間が数ミリ秒単位でかかり、IOPSは物理構造で頭打ちです。SSDは機械的な待ち時間がほぼ無いため、この式の分母が桁違いに小さくなり、IOPSが跳ね上がる、という関係になります。

IOPSとスループット・レイテンシの違いと3つの性能指標の使い分け

ストレージ性能を語るとき、IOPS・スループット・レイテンシは混同されがちです。3つは別々のものを測っており、用途によって効く指標が入れ替わります。まず違いを整理し、次にIOPSが状況で大きく変わる理由を押さえます。

IOPS・スループット・レイテンシの3指標の違いを整理した比較表

3つの指標は、測っている対象がそれぞれ異なります。IOPSは「1秒間に何回さばけるか(回数)」、スループットは「1秒間にどれだけ運べるか(転送量)」、レイテンシは「1回の要求に何ミリ秒で応えるか(待ち時間)」を表します。高速道路にたとえると、IOPSは1秒間に通過する車の台数、スループットは運んだ荷物の総量、レイテンシは1台が入口から出口まで走る時間です。台数が多くても1台の到着が遅ければ、応答を待つ処理は遅く感じます。

指標 測るもの 主な単位 効きやすい用途 相性の良いデバイス
IOPS 1秒あたりの操作回数 回/秒 DB・OLTP・仮想化基盤 SSD・NVMe
スループット 1秒あたりの転送量 MB/s・GB/s 動画配信・バックアップ・ETL HDD束ね・SSD
レイテンシ 1回の応答時間 ミリ秒・マイクロ秒 対話的処理・オンライン取引 NVMe・キャッシュ

読み方の勘所は、この3つがトレードオフの関係にある点です。同時に処理する要求を増やせばIOPSとスループットは伸びますが、順番待ちが発生してレイテンシは悪化します。小さなI/Oを速い応答でさばきたいトランザクション処理はIOPSとレイテンシを、大きなデータをまとめて流すバッチ処理はスループットを、というように、まず用途から効く指標を1つ決め、その指標で設計するのが外さない進め方です。

ランダムアクセスとシーケンシャルアクセスでIOPSが変わる理由

同じストレージでも、アクセスパターンによってIOPSは大きく変わります。シーケンシャルアクセスは、連続した領域を順番に読み書きする方式で、ディスク上の次の位置がすぐ隣にあるため、待ち時間がほとんど生じません。ランダムアクセスは、離れた位置をばらばらに読み書きする方式で、HDDでは毎回ヘッドを移動させ、ディスクの回転を待つため、1操作ごとに数ミリ秒の待ち時間が積み上がります。この差はHDDで顕著に出ます。シーケンシャルなら数百MB/sを出せるHDDでも、4KBのランダムアクセスになるとIOPSは百数十回程度まで落ち込み、実効スループットは1MB/sにも届きません。データベースはインデックス参照やレコード更新で細かくランダムアクセスするため、この「ランダム時のIOPS」が実際の性能を決めます。ベンチマークで「シーケンシャルリード何MB/s」という数字だけを見ると、DB用途の実力を大きく見誤る結果になりがちです。性能設計では、カタログ値ではなく、用途に近いブロックサイズ・ランダム比率での実測値を基準にします。

HDDとSSD・RAID・キューデプスがIOPSに与える影響

IOPSは、デバイスの種類・RAID構成・並列度という3つの要因で決まります。どこがボトルネックになるかを見極めることが、費用をかけるべき場所を定める前提です。順に、物理デバイスの限界、RAIDによる増減、そしてキューデプスの効き方を見ます。

HDDとSSDのランダムIOPS差と物理構造で決まる性能限界

ランダムアクセスのIOPSは、デバイスの物理構造でほぼ決まります。HDDは、磁気ヘッドの移動(シーク)とディスクの回転待ちという機械動作が1操作ごとに必要で、これが数ミリ秒かかるため、ランダムIOPSは回転数で頭打ちになります。7,200rpmクラスで概ね毎秒75〜150回、15,000rpmのSAS HDDでも毎秒175〜210回程度が実力の目安です。SSDは機械的な可動部を持たず、電気的にデータへアクセスするため、待ち時間がマイクロ秒単位に縮みます。結果として、SATA接続のSSDのランダム読み込みは数万IOPS、NVMe接続のSSDでは数十万から製品によっては100万IOPS超に達する帯域です。桁が3つも4つも違うため、細かいランダムI/Oが多いデータベースや仮想化基盤では、HDDをどれだけ束ねてもSSD1台に及ばない場面が普通に起こります。IOPSがボトルネックの用途では、まずデバイスをSSD/NVMeにすることが、他のどの手当てよりも効きます。

RAIDレベルと書き込みペナルティがIOPSを左右する仕組み

複数ディスクを束ねるRAIDは、読み込みIOPSを台数ぶん増やす一方、書き込みではRAIDレベルによって「書き込みペナルティ」という目減りが発生します。書き込みペナルティとは、アプリからの1回の書き込みを完了するために、ストレージ側で実際に何回のI/Oが必要になるかの倍率です。ミラーのRAID1とRAID10は、同じデータを2台へ書くだけなのでペナルティは2。パリティを使うRAID5は、更新のたびに古いデータと古いパリティを読み、新しいデータと新しいパリティを書くため、1回の書き込みに4回のI/Oがかかりペナルティは4。二重パリティのRAID6はさらに増えてペナルティは6になります。このため、同じディスクを使っても、実効の書き込みIOPSは「ディスク全体のIOPS×書き込み比率÷ペナルティ」で目減りします。書き込みが多いデータベースでRAID10が選ばれ、RAID5/6が避けられる理由の1つが、このペナルティの小ささです。RAIDレベルごとの構成や許容故障台数と合わせた選び分けはRAID0/1/5/6/10の違いと構成の解説で整理しており、IOPS設計はこの書き込みペナルティを織り込んで見積もります。

キューデプスと並列度で実効IOPSが伸びる/頭打ちになる境界

IOPSの実測値は、同時にいくつのI/O要求を投げるか、つまりキューデプスに強く依存します。キューデプスが1、つまり1つの要求を投げて応答を待ってから次を投げる場合、IOPSはレイテンシの逆数でしか出ません。レイテンシが1ミリ秒なら、単純計算で毎秒1,000回が上限です。SSDやNVMeは内部に多数の並列チャネルを持つため、キューデプスを16、32と上げて要求を同時に流し込むと、内部で並列処理されIOPSが大きく伸びます。ここで効くのがリトルの法則で、「同時実行数=IOPS×レイテンシ」という関係です。つまりキューデプスを上げるとIOPSは増えますが、内部が飽和した時点から先は、IOPSが頭打ちになる一方でレイテンシだけが悪化していきます。ベンチマークで最大IOPSを狙ってキューデプスを極端に上げた数字は、実運用のレイテンシ要件を無視した「出せる最大値」にすぎません。実際の設計では、許容できるレイテンシ(たとえば1ミリ秒以内)を満たす範囲での持続IOPSを見ます。数字が大きいキューデプスの結果を鵜呑みにしないことが、IOPS設計での定番の注意点です。

クラウド・実務でのIOPS設計|EBSのプロビジョンドIOPSと測定

ここは他社の解説が踏み込まない、IOPSを実際にどう設計し測るかを言い切る章です。原則は2つ、「IOPSは用途のアクセスパターンから逆算して要件を決める」ことと、「IOPSを増やす前にレイテンシ・ブロックサイズ・キューデプスを確認する」ことです。この2点を外すと、クラウドで高いIOPSを買っても体感が変わらない、という費用のむだにつながります。

AWS EBS(gp3/io2)のプロビジョンドIOPSと課金の考え方

クラウドでは、IOPSを容量とは別に指定して買う「プロビジョンドIOPS」という考え方が中心になります。AWSのブロックストレージEBSでは、汎用SSDのgp3が、容量とは切り離してベースライン3,000 IOPS・125MB/sを提供し、追加料金でIOPSとスループットを個別に引き上げられます(2026年時点の一般提供仕様で、上限はボリュームあたり概ね16,000 IOPS程度)。より高い性能が要るワークロード向けには、プロビジョンドIOPSのio2/io2 Block Expressがあり、ボリュームあたり数万から最大25万IOPS超まで指定できます(同じく2026年時点の系。詳細な上限値は公式ドキュメントで実測確認する前提です)。旧世代のgp2は容量に比例してIOPSが決まる方式で、容量を増やさないとIOPSが上がらない制約がありました。gp3以降は容量とIOPSを分けて指定できるため、必要なぶんだけIOPSを買う設計に変わっています。ここで見落としやすいのが、EC2インスタンス側にもEBSへの帯域上限があり、ボリュームのIOPSをいくら上げてもインスタンスの上限で頭打ちになる点です。ブロックストレージのIOPSと、内部で多重複製されるオブジェクトストレージの性能特性はまったく別物で、この意味づけの違いはオブジェクトストレージの仕組みとブロックとの違いの解説で扱っています。

fio・CrystalDiskMarkでのIOPS測定と評価の落とし穴

IOPSは、用途に近い条件で実測して初めて設計の根拠になります。Linux環境の定番はfioで、ブロックサイズ・読み書き比率・ランダム/シーケンシャル・キューデプスを細かく指定して測れます。データベース用途なら、4KBのランダム・読み書き混在・キューデプスを実運用に近い値に設定して測るのが基本です。Windowsのローカル確認にはCrystalDiskMarkが手軽で、ランダム4Kの値がIOPS相当の実力を表します。測定でよくある落とし穴は3つあります。1つ目は、シーケンシャルの大きなブロックだけを測ってIOPSが高いと誤認すること。2つ目は、キューデプスを極端に上げた最大IOPSだけを見て、レイテンシの悪化を見ないこと。3つ目は、キャッシュに載った状態を測って、実ディスクの持続IOPSと取り違えることです。評価では、用途に近いブロックサイズ・ランダム比率で、キャッシュを外した持続状態の、レイテンシ要件を満たす範囲のIOPSを見ます。カタログのピーク値ではなく、この実効値を設計の基準にします。

IOPSを増やす前に確認すべき3つの点とインフラ設計への相談

「動作が遅い=IOPSを増やせば直る」という発想は、しばしば費用のむだを生みます。IOPSを増やす前に確認すべき順番は、次のとおりです。まず、そのシステムのI/Oが本当にIOPS律速なのか、それともスループット律速なのかを切り分けます。大きなファイルを流す処理なら、IOPSを増やしてもスループットの上限で変わりません。次に、ブロックサイズとランダム比率を実測し、遅さの原因がストレージ層なのか、それともCPU・メモリ・アプリのロック待ちなのかを見極めます。データベースの遅延は、インデックス設計やクエリの問題であってストレージのIOPSは足りている、というケースが珍しくありません。そのうえでストレージがボトルネックだと判明したら、デバイスをNVMeに替える、RAIDの書き込みペナルティを減らす、クラウドならプロビジョンドIOPSを要件ぶんだけ引き上げる、という手当てに進みます。この性能設計は、ストレージ単体ではなく、可用性目標やコスト制約と一体で決めるものです。IOPS性能が可用性目標にどう組み込まれるかは稼働率と高可用性の設計の解説を参照してください。ワークロードに見合ったストレージ性能を設計したい、あるいはオンプレミスからクラウドへの移行でIOPS要件を見直したい場合は、要件整理から構成設計・実装までを一貫して支援できる開発会社に相談すると、過剰なプロビジョンドIOPS投資も、性能不足による障害も避けられます。一創ではAWS/GCP/Azureでのストレージ性能設計を含むインフラ構築として、用途に見合ったIOPS設計から運用まで対応しています。

IOPSに関するよくある質問|計算・SSD・クラウドについての疑問

これからストレージ性能を設計する担当者や、既存システムの遅延調査を任された技術者から寄せられやすい質問に答えます。

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

用途のアクセスパターンから逆算します。まず、そのシステムが1秒間に何回のI/Oを出すかを実測し、書き込み比率とRAIDの書き込みペナルティを掛けて必要IOPSを見積もります。たとえば書き込みが多いRAID10のデータベースなら、ピーク時のI/O回数に少し余裕を足した値が目安です。汎用的なWebアプリのDBなら数千IOPSで足りることが多く、大規模なトランザクション基盤では数万IOPSが要る場合もあります。カタログのピーク値ではなく、用途に近い実測値を基準に見積もるのが確実です。

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

扱うデータの大きさで決まります。データベースや仮想化基盤のように、小さなブロックをランダムに大量へさばく用途はIOPSを見ます。動画配信・バックアップ・大規模なデータ処理のように、大きなデータをまとめて順番に流す用途で見るのはスループットです。両者は「IOPS×ブロックサイズ=スループット」で結びついているため、どちらが上限になるかは1回あたりの転送サイズで変わります。まず用途のブロックサイズを把握し、効く指標を1つ決めてから設計します。

SSDにすればIOPSの問題は解決しますか?

ランダムI/Oがボトルネックなら大きく改善します。SSDやNVMeは、HDDに比べてランダムIOPSが数千倍のオーダーで高いため、細かいランダムアクセスが多いデータベースや仮想化では効果が明確です。ただし、遅さの原因がストレージではなくCPU・メモリ・アプリのロック待ち・ネットワークにある場合、SSDに替えても体感は変わりません。まずボトルネックがストレージのIOPSにあるかを実測で切り分け、そのうえでSSD化を判断します。

クラウドのプロビジョンドIOPSは高く設定するほど良いですか?

要件ぶんに絞るのが適正です。AWSのio2などプロビジョンドIOPSは指定した値に応じて課金されるため、必要以上に高く設定すると費用だけがかさみます。また、ボリュームのIOPSを上げても、EC2インスタンス側のEBS帯域上限やアプリの並列度で頭打ちになり、投資が性能へ反映されない場合があるのです。実測で必要IOPSを見積もり、インスタンスの上限とも突き合わせたうえで、要件に見合う値を指定します。

IOPSとレイテンシはどう関係しますか?

トレードオフの関係にあります。同時に投げる要求数(キューデプス)を増やせばIOPSは伸びますが、内部が飽和した先ではレイテンシだけが悪化します。「同時実行数=IOPS×レイテンシ」というリトルの法則が示すとおり、IOPSとレイテンシは独立ではありません。対話的な処理やオンライン取引のように応答時間が重い用途では、最大IOPSではなく、許容レイテンシを満たす範囲での持続IOPSを設計の基準にします。

関連記事

資料請求

RELATED POSTS 関連記事