ストレージテストとは?種類、 Concepts & 例
⚡ スマートサマリー
ストレージテストでは、アプリケーションがデータを正しいディレクトリに書き込み、予期せぬ終了を回避するのに十分なディスク容量があることを検証するとともに、現実的な負荷条件下で基盤となるストレージがどれだけ速く応答するかを測定します。

ストレージテストとは何ですか?
ストレージテスト これは、テスト対象のソフトウェアアプリケーションが関連データを適切なディレクトリに保存しているか、またディスク容量不足による予期せぬ終了を防ぐのに十分な空き容量があるかを検証するために使用されるソフトウェアテストの一種です。 ストレージ性能テスト.
この技術は、この分野の非機能的な側面に位置づけられます。他の形態と同様に、 非機能テストこれは、機能が正しい答えを生成するかどうかについては何も述べておらず、データ量とI/O負荷が増加するにつれてシステムが答えを生成し続けることができるかどうかについてのみ述べている。
なぜストレージテストを行うのか?
ストレージはほとんどのアプリケーションがアクセスする最も遅いレイヤーであるため、そこに弱点があると他のあらゆる箇所に影響が及ぶ。専用のテストサイクルを実施する正当な理由は4つある。
- ストレージの速度が遅いと、応答時間が遅くなり、クエリの実行時間が長くなり、アプリケーションの可用性が低下します。
- ストレージの速度が遅いと、サーバーインフラの維持管理において負担が増える。
- 導入前にシステムの実際のストレージ容量の限界を把握しておくことは有益です。
- ハードウェア機器が交換またはアップグレードされた際に、システムがどのように反応するかを理解しておくことは役立ちます。
下の図は、ストレージテストをそのような文脈で捉えています。アプリケーション、ファイルシステム、物理デバイスはすべて同じパス上にあり、そのパス上のどこかで遅延が発生すると、それがユーザーに影響を与えます。
ストレージテストの種類
3つのアプローチが用いられており、それらは主にワークロードが実際のアプリケーションにどれだけ近いかという点で異なっている。
- アプリケーションのテスト: 本番環境に近い環境で、サンプルクエリを用いたアプリケーションテストを実施する。
- アプリケーションシミュレーション: 対象アプリケーションと同様の動作をする標準ソフトウェアを使用してテストを実施する。
- ベンチマーク: 標準的なベンチマークソフトウェアを使用して、再現可能な合成ワークロードを生成するテストを実施する。
最初の方法は最も現実的な結果をもたらしますが、移植性は最も低くなります。3番目の方法は、デバイスやベンダー間で比較可能な数値を示しますが、アプリケーション自体の動作についてはほとんど何も示しません。
共通テスト Concepts 保管試験中に関与
これら3つのタイプはそれぞれ、以下にまとめたように、異なる一連の活動に対応しています。
| ストレージテストの種類 | 一般的なストレージテストアクティビティの例 |
| アプリケーションテスト | OLTP 応答時間を比較する バッチの実行時間を比較する 継続的なストリーミング速度を比較する |
| アプリケーションシミュレーション | データベースのピーク ストレージ IOPS をテストする データストリーミング環境におけるストレージのピークスループットをテストする メッセージングやその他のシングルスレッドアプリケーションのストレージ遅延をテストする |
| ベンチマーク | データ破損のテスト |
ストレージテストにおける主要指標
保管結果は、少数の数値で示されます。これらの数値は互いに矛盾するため、どれか一つだけを単独で読むと、誤った結論に至ってしまう可能性が非常に高くなります。
| メトリック | 測定対象 | 最も重要な場所 |
| IOPS | サイズに関係なく、1秒あたりに完了した読み取りおよび書き込み操作数 | トランザクションデータベースと小規模なランダム書き込み |
| レイテンシ | 単一のI/O操作の開始から完了までの時間 | メッセージングとシングルスレッドアプリケーションパス |
| スループット | 1秒あたりに転送されるデータ量(通常はMB/s)。 | バッチ実行、バックアップ、ストリーミングワークロード |
| キューの深さ | 同時に発行された未処理のリクエスト数 | 実際の並行処理を反映する必要がある実行 |
キューの深さは特に注意が必要です。一度に1つのリクエストを発行すると、正確な単一リクエストのレイテンシが得られますが、IOPSとスループットの数値は実際よりも低くなってしまいます。そのため、テスト環境ではデバイスの動作が遅く見えても、本番環境では速く見える、あるいはその逆になることがあります。
ストレージテストの実施方法
ストレージテストの信頼性は、実行環境によって左右されます。以下の手順に従うことで、結果の再現性を確保できます。
- ステップ1)目的を定義する。 今回の実行がデータベースの準備状況の検証、スループットの上限値の検出、あるいは2つのデバイスの比較のいずれを目的としているのかを明確にしてください。それぞれの目的によって必要なワークロードは異なり、それらを混在させると、誰も適切な対応ができない数値が生成されます。
- ステップ2)データセットのサイズを現実的なものにする。 キャッシュに収まるほど小さいワーキングセットは、ストレージではなくキャッシュの容量を測定します。本番データの量に合わせるか、少なくともキャッシュサイズを大幅に上回るようにしてください。
- ステップ3)読み書きの組み合わせとパターンを選択します。 同じデバイス上でも、ランダムアクセスとシーケンシャルアクセスは大きく異なる動作をします。70/30の読み書き比率や書き込み専用バーストも同様です。デフォルト設定ではなく、運用環境のモニタリング結果から最適な比率を選択してください。
- ステップ4)キューの深さとスレッド数を設定します。 これらはデバイスに到達する同時処理量を制御するため、すべての結果にこれらの値を記録する必要があります。これらの値を含めずに引用された数値は再現できません。
- ステップ5)キャッシュをクリアしてウォームアップします。 実行の合間にサーバーとデバイスのキャッシュを削除し、最初のインターバルを破棄することで、初回接触時の数値ではなく定常状態の数値を比較できるようにする。
- ステップ6)十分な時間走る。 短時間の実行では、SSDの書き込みバッファが枯渇した際に発生する書き込み限界現象(ライトクリフ)は隠れてしまう。しかし、長時間の実行ではそれが顕在化する。
- ステップ7)スタック全体を監視する。 プロセッサの使用率、メモリ、ネットワークの使用率をストレージカウンタと併せて計測することで、他の箇所で発生しているボトルネックをストレージの制限と誤解しないようにします。
- ステップ8)繰り返して比較する。 同一の構成で複数回実行し、ログを保存してください。ビルド間のパフォーマンスのずれは、保存されたベースラインと比較した場合にのみ確認できます。
同じ規律はあらゆる負荷駆動測定に適用されるため、これらの実行は通常、 性能試験 そして、リリース候補版が確定する前にスケジュールされる。
ストレージテストツール
ツールは大きく2つのグループに分けられ、ほとんどのチームは両方を必要とします。
- 合成入出力ジェネレーター。 などのユーティリティ FIOIometerとsysbenchは、ブロックサイズ、読み書きの比率、キューの深さ、実行時間など、ワークロードを正確に記述して発行するため、別のデバイスで全く同じ実行を再現できます。
- アプリケーションレベルの負荷ツール。 ドライバーなど JMeter アプリケーション自体をテストすることで、ストレージは実際のユーザーが作成するアクセスパターンを認識できるようになります。これには、合成ツールでは再現できないクエリプランやインデックスの動作も含まれます。
Operating-system カウンターが全体像を完成させます。負荷を生成するツールが何であれ、ストレージの数値はプロセッサ、メモリ、ネットワークのカウンターと併せて読み取る必要があります。ストレージ テスト手法には、以下のようなものがあります。 ベンチマークテスト (NAIST) と ボリュームテスト結果を正しく解釈するには、そのフルスタックビューに依存します。
ストレージテスト実施時のミス
ほとんどの無効なストレージ結果 trac回避可能な少数のエラーに戻る。
- 監視対象のサーバーのパフォーマンスが間違っているため、表示される数値はテスト対象ではないマシンのデータを示している。
- サーバーのキャッシュをクリアせずにストレージデバイスを比較すると、ディスクではなくメモリの性能が測定されます。
- テスト中にプロセッサの使用率を監視することを忘れると、ストレージの問題という症状の裏に、プロセッサに起因するボトルネックが隠されてしまう。
- ファイルコピーコマンドを使用してストレージのパフォーマンスをテストします。これらのコマンドはシングルスレッドで、キャッシュアシストを使用し、繰り返し実行できません。

