ストレージテストとは?種類、 Concepts & 例

⚡ スマートサマリー

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

  • 💾 とも呼ばれている: ストレージのパフォーマンステストは重要です。なぜなら、速度は適切な配置と同じくらい重要だからです。
  • ⚠️ なぜ重要なのか: ストレージの速度が遅いと、応答時間が遅くなり、クエリの実行時間が長くなり、アプリケーションの可用性が低下します。
  • 🧩 XNUMXつのタイプ: アプリケーションテスト、アプリケーションシミュレーション、ベンチマークは、それぞれ独自の活動内容を持つ。
  • ☃ コアメトリクス: IOPS、レイテンシ、スループット、キュー深度は、個別にではなく常にまとめて読み取るべきです。
  • 🧪 実行方法: 目的を定義し、データセットのサイズを決め、現実的な読み書き比率を選択し、その後負荷を段階的に増加させる。
  • 🛠️ ツーリング: 合成I/Oジェネレーターは、ファイルコピーコマンドでは決して得られない、再現性のある数値を生成する。
  • 🚫 よくある間違い: 監視しているサーバーが間違っています。スキップします。ping キャッシュをクリアし、プロセッサの使用率を無視する。

ストレージテストのチュートリアル(種類、概念、よくある間違いを解説)

ストレージテストとは何ですか?

ストレージテスト これは、テスト対象のソフトウェアアプリケーションが関連データを適切なディレクトリに保存しているか、またディスク容量不足による予期せぬ終了を防ぐのに十分な空き容量があるかを検証するために使用されるソフトウェアテストの一種です。 ストレージ性能テスト.

この技術は、この分野の非機能的な側面に位置づけられます。他の形態と同様に、 非機能テストこれは、機能が正しい答えを生成するかどうかについては何も述べておらず、データ量と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回避可能な少数のエラーに戻る。

  • 監視対象のサーバーのパフォーマンスが間違っているため、表示される数値はテスト対象ではないマシンのデータを示している。
  • サーバーのキャッシュをクリアせずにストレージデバイスを比較すると、ディスクではなくメモリの性能が測定されます。
  • テスト中にプロセッサの使用率を監視することを忘れると、ストレージの問題という症状の裏に、プロセッサに起因するボトルネックが隠されてしまう。
  • ファイルコピーコマンドを使用してストレージのパフォーマンスをテストします。これらのコマンドはシングルスレッドで、キャッシュアシストを使用し、繰り返し実行できません。

よくあるご質問

ボリュームテスト アプリケーションが保持するデータ量を増やし、その動作の劣化を観察します。ストレージテストは、その下位にあるデバイス層を対象とし、データの書き込みと読み出しの速度を測定します。

アプリケーションが書き込むすべての場所(データディレクトリ、ログフォルダ、一時フォルダ、アップロード先、アーカイブパスなど)について、ファイルが正しい場所に保存されていること、および空き容量が正しく報告されていることを確認する必要があります。

指標自体は変わりませんが、プロビジョニングされたIOPS制限、バーストクレジット、およびノイジーネイバーが追加されます。バーストクレジットが使い果たされるまで十分な時間実行してください。そうしないと、測定値は定常状態ではなく一時的な許容値を反映することになります。

機械学習モデルは、通常のIOPSとレイテンシの曲線を基準として、しきい値を超える前に逸脱した実行を検知します。同じモデルは容量増加を予測するため、ディスクの枯渇は本番環境で発見されるのではなく、事前に予測されます。

GitHubコパイロット ジョブファイル、キャッシュクリアラッパー、結果解析スクリプトを迅速に作成します。ブロックサイズ、キューの深さ、実行時間は、テンプレートではなく本番環境の監視データから取得されるため、テスターが引き続き提供します。

これは有効なテストケースであり、事故ではありません。アプリケーションは終了するのではなく、警告を発し、段階的にパフォーマンスを低下させ、状態をログに記録する必要があります。ディスクがいっぱいの状態からの復旧は、 回復テスト.

通常、キャッシュの状態、キューの深さ、実行長などが両者で異なっていた。デバイスの状態も重要で、フォーマットしたばかりのSSDは、何度も書き込みを繰り返して容量がいっぱいになったSSDよりも書き込み速度が速い。

通常、パフォーマンス・テスターがテストを実行し、インフラストラクチャ管理者またはデータベース管理者がデバイス構成と本番環境へのアクセスパターンを提供する。テスト結果が正当化されるのは、双方ともワークロードが現実的であったことに同意した場合に限られる。