IOPSとスループット：データベースに適したパフォーマンス指標の選び方

By Mirko Peters · 2026-08-11 · Updated 2026-08-26

アーキテクトやデータベース管理者が、SQL Serverのような重負荷ワークロード向けに高性能なインフラを設計しようとすると、多数の技術用語やストレージ仕様に直面することが少なくありません…

Automatically translated with AI from the original post. Read the English original

アーキテクトやデータベース管理者が、SQL Serverのような重負荷ワークロード向けに高性能なインフラを設計しようとすると、多数の技術用語やストレージ仕様に直面することが少なくありません。その中でも特に重要でありながら誤解されがちな指標が、IOPSとスループットです。ストレージをプロビジョニングする際に誤った指標を選ぶと、クエリの遅延、システムのボトルネック、無駄なコストにつながりかねません。データベースが実際にどのようにデータを読み書きしているかを理解することが、回復力のあるアーキテクチャを構築する第一歩です。

本記事では、IOPSとスループットの根本的な違いを整理し、それらが負荷の高いデータベースのワークロードにどう影響するかを検討します。また、仮想マシンの上限のような一般的なアーキテクチャ上のボトルネックを確認し、共有ストレージモデルが最新のクラウド環境をどのように変えているかも見ていきます。

データベースのパフォーマンス指標の紹介

ストレージのパフォーマンスは、万能の基準で測れるものではありません。クラウドストレージや従来のSANハードウェアを見ると、ベンダーはデータ転送の速さやディスクが処理できる操作数について、印象的な数値を提示します。しかし、データベースエンジンは動画配信サービスや大規模なファイルサーバーとはまったく異なる動き方をします。動画サーバーが大量の連続したデータを一本のパイプで送り続けるのに対し、データベースは特定の行を探したり、トランザクションログを更新したり、ページをメモリにキャッシュしたりすることに時間を費やします。

重圧にも耐えられる環境を設計するには、まずワークロードごとに異なる特性を正しく理解する必要があります。そのためには、ストレージ性能の2つの柱である、1秒あたりの入出力操作数（IOPS）と毎秒メガバイト数（スループット）を深く掘り下げることから始めます。

IOPSの定義：データベースが小さな読み取りと書き込みに依存する理由

IOPSは「Input and Output Operations Per Second」の略で、デバイスが1秒間に処理できる個々のストレージ要求の数を示す指標です。SQL Serverのような本格的なデータベースプラットフォームでは、通常IOPSが最も重要な指標です。

データベースは本質的にトランザクション指向です。ユーザーがアプリケーションにログインしても、データベースが数ギガバイトもの巨大なファイルを一度に読み書きすることは通常ありません。代わりに、無数の小さく的を絞った操作を実行します。たとえば、ユーザープロファイルを取得するために8KBのデータページを読み取ったり、トランザクションログに数百バイトを書き込んだり、インデックスを更新したりします。これらの操作は非常に小さいため、ストレージサブシステムが大量の個別コマンドを処理する能力、つまりIOPSの処理能力が、パフォーマンスを左右する主要因になります。ユーザーのトランザクションに対応するために1万IOPSが必要なのに、ストレージディスクが3,000しか提供できなければ、クエリは待機列に溜まり、ロックが連鎖的に発生し、アプリケーションの応答時間は急落します。

スループットの定義：帯域幅が最も重要になる場面

IOPSが操作の*数*を測るのに対し、スループットは一定期間に移動するデータの*量*を測ります。通常はメガバイト毎秒（MB/s）で表されます。IOPSを高速道路を走る車の台数、スループットをそれらの車が運んでいる荷物の総重量と考えるとわかりやすいでしょう。

IOPSよりもスループットがはるかに重要になるシナリオもあります。夜間のデータベースバックアップ、大規模なデータウェアハウスへのインポート、テーブル内の数百万行をスキャンする分析クエリなどが該当します。これらの処理では、1秒間に何件の個別要求を処理できるかはさほど重要ではありません。重要なのは、大量の連続したデータストリームをどれだけ速く取り込めるか、または書き出せるかです。IOPSは高いもののスループットの上限が低いストレージで大規模なデータ移行を行うと、データのパイプが十分な幅を持たないため、想定よりも数時間も長くかかることになります。

アプリケーションのワークロードとストレージ構成の対応付け

企業内のすべてのアプリケーションには、固有のストレージ特性があります。環境のアーキテクチャを適切に設計するには、それぞれの読み取りと書き込みのパターンに適したストレージ構成を割り当てることが重要です。たとえば、トランザクション処理（OLTP）データベースは、レイテンシのスパイクを起こさずに同時実行されるユーザー要求を処理するために、高いIOPS性能を必要とします。一方、データレイクやレポートサーバーは、分析クエリを処理するために高いスループットを必要とすることがあります。

環境に、傾向の異なる複数のワークロードが同居すると課題が生じます。SQLデータベースは月末の財務レポート処理時にピークに達し、レポートサーバーは毎朝8:00に急増し、バックアップシステムは夜間にネットワークへ大量のトラフィックを流すかもしれません。従来、管理者はピークごとに個別のディスクを用意していたため、過剰なプロビジョニングとアイドル状態のリソースが大量に生まれていました。

仮想マシンがボトルネックになる: ディスクだけの問題ではない

データベースのIOPSとスループット要件を慎重に計算し、利用可能な最速のディスクをプロビジョニングしたとしても、深刻なパフォーマンスの壁にぶつかることがあります。原因はストレージメディアそのものではなく、そのディスクが接続されている仮想マシンであることが多いのです。

たとえばAzureの仮想マシンには、選択したVMのサイズやティアに応じて、ディスクのIOPSとスループットの合計に厳しい上限があります。小規模なVMサイズにエンタープライズ向けの超高速ディスクを接続することはできますが、VM自体がストレージトラフィックを独自の上限値で制限します。ストレージ側が20,000 IOPSを提供できても、仮想マシンの経路が10,000 IOPSに制限していれば、それが実質的な上限になります。ディスクの仕様とコンピューティングのサイズの両方を必ず確認し、両者の間の経路がピーク時のワークロードを処理できるだけの幅を持っているかを確かめてください。

共有ストレージプールがパフォーマンス計画をどう変えるか

ワークロードごとに過大なサイズの独立したディスクを用意するという悪循環を断ち切るため、最新のクラウドアーキテクチャでは、従来のStorage Area Network（SAN）を彷彿とさせる共有ストレージプールに目を向けています。パフォーマンスを個別の硬直したコンテナに閉じ込めるのではなく、共有モデルでは容量とIOPSをまとめてプール化します。

プール化されたリソースを利用する環境では、パフォーマンス指標は容量に比例して拡張されます。たとえばAzure Elastic SANでは、ベース容量1 TiBごとに、5,000 IOPSと200 MB/秒のスループットといった一定量のパフォーマンスが中央のプールに加算されます。この共有プールにより、異なるボリュームが共通のパフォーマンスの枠を利用できます。財務データベースが繁忙期のレポート処理でIOPSを大量に必要とする一方、倉庫管理システムが静かな時間帯であれば、そのリソースを動的に振り向けて、稼働中のワークロードを支えられます。

つまずきポイントを避ける: ピーク需要と共有の上限のバランス

共有ストレージプールは非常に高い柔軟性とコスト削減をもたらしますが、無制限のパフォーマンスを約束する万能薬ではありません。リソースをプール化するということは、すべてのデータベースが同じミリ秒に絶対的なピーク需要に達することはないという統計的な可能性に賭けることを意味します。

複数の負荷の高いワークロードが同時に急増し、その合計需要が共有プールの上限を超えると、スロットリングが発生します。スロットリングはレイテンシを増大させ、クエリを遅くし、アプリケーションのタイムアウトを連鎖的に引き起こすことがあります。データベース管理者とインフラ計画の担当者は、過去のメトリックを慎重に分析し、同時に発生するピーク時の利用状況を把握したうえで、重なり合うピーク需要を余裕をもって吸収できるよう、共有ストレージプールに十分なヘッドルームを持たせるサイズ設計を行う必要があります。

結論: データベースに適したメトリックを選ぶ

IOPSとスループットのバランスを習得することは、クラウド上で負荷の高いデータベースワークロードを管理するすべての人にとって不可欠です。アプリケーションが小規模で高速な処理に不足しているのか、大容量のデータ帯域に不足しているのかを正確に診断できれば、コストのかかるパフォーマンスのボトルネックを回避できます。さらに、共有プールのような最新のストレージの仕組みを取り入れれば効率が大幅に向上し、インフラがビジネスの成長に合わせて賢くスケールする状態を実現できます。最新のクラウドストレージアーキテクチャがこうしたスケーリングとパフォーマンスの課題をどのように解決するかをさらに深く知りたい方は、関連するポッドキャストのエピソードもぜひご覧ください: Azure Elastic SAN — Simply Explained。