有用なストレージテストは、操作サイズ、アクセスパターン、同時実行数、耐久性要件をアプリケーションに適合させる。テスト条件とレイテンシ分布を記録し、その結果をアプリケーションの測定で確認する。
スコアではなく、ストレージの問いから始める
ベンチマークを実行する前に、何を知る必要があるかを決める。遅いデータベースコミット、ファイル配信のスループット、多数の小さなファイルを生成するビルドプロセスを調査しているかもしれない。これらのワークロードはディスクに同じことを求めていない。大規模なシーケンシャルコピーは印象的に見えても、小さなランダム読み取りを行うサービスが経験する遅延についてはほとんど語らない。
NVMeは不揮発性メディアと効率的な並列I/Oのために設計されたが、そのプロトコル名はホスト型ストレージ経路のすべての部分を説明するものではない。仮想化、ファイルシステム、リソース競合、アプリケーションも依然として重要である。サーバー全体が高速であることを証明する数値を出そうとするのではなく、ストレージのレイテンシが特定の操作を遅くしているかどうかといったテスト仮説を書く。
ワークロードを再現可能な形で記述する
操作サイズ、シーケンシャルかランダムかのパターン、読み取りと書き込みの比率、ジョブ数、キューの深さを記録する。データセットサイズとテスト時間も含める。fioのドキュメントでは、これらのワークロード制御と利用可能なI/Oエンジンについて説明している。意図した深さがすべてのエンジンや設定で達成されるとは限らないため、要求した構成だけでなく報告された動作も確認する。
テストの説明のコピーを結果のそばに保管する。オペレーティングシステム、ファイルシステム、マウントオプション、サービスの活動、利用可能な容量を記録する。構成を比較する場合は、関連する条件を一度に1つだけ変更する。異なるアクセスパターンや同時実行数のテストを、ストレージ媒体だけが変わったかのように提示するのは公平ではない。
| アプリケーションのパターン | 記述するテストの次元 | 確認する結果 |
|---|---|---|
| 大容量ファイル配信 | シーケンシャル読み取りと同時クライアント | 持続的なスループットとCPUの使用 |
| レコード検索 | 小さなランダム読み取りと代表的な同時実行数 | レイテンシ分布と完了した操作 |
| 耐久性のあるトランザクション | 書き込みと同期の要件 | バッファリングされた書き込み速度だけでなく、コミットに関連する遅延 |
| ビルドまたは展開 | 小さなファイルの混在操作 | エンドツーエンドのジョブ時間とI/O待ち |
キャッシュを重要でないふりをせずに制御する
メモリに収まるデータセットは、最初のパス以降は主にキャッシュの動作を測定している可能性がある。アプリケーションが通常同じキャッシュの恩恵を受けるなら有用だが、生のデバイス性能としてラベル付けすべきではない。テストがウォームなアプリケーション経路、よりコールドなデータセット、オペレーティングシステムのバッファリング効果を減らすことを意図したI/Oモードのどれを調べるかを意図的に選ぶ。
ダイレクトI/Oのサポートとアラインメントはプラットフォームとエンジンに依存する。また、アプリケーションの耐久性要件を自動的に表現したり、スタック内のすべてのキャッシュを排除したりするものでもない。選択したモードを明確に述べ、バッファリングされたテストとバッファリングされていないテストを同じ作業を表すかのように比較しない。解釈に役立つ場合は、ウォームアップと測定区間を分けておく。
スループットと併せてレイテンシの裾を確認する
平均レイテンシは、実際のリクエストに影響する遅い操作を隠すことがある。報告されたパーセンタイルとその背後にあるサンプル数を確認する。高いパーセンタイルは、そのテスト中に観測された操作のうち記載された割合が下回った境界を表すものであり、恒久的なサービス保証ではない。短い、または代表性のない実行は、混雑した本番期間について限られた証拠しか与えない。
キューの深さを増やすと、完了スループットが向上する一方で待ち時間が増えることがある。このトレードオフはバッチ処理に適し、対話型サービスには害になる可能性がある。アプリケーションに似た同時実行数で結果を比較し、同時にCPUとI/Oプレッシャーを監視する。環境を共有する別のワークロードに不必要な混乱をテストが生み出す前に停止する。
テストを許可された範囲で非破壊的に行う
専用のテストディレクトリまたは準備された使い捨てボリュームを使用し、十分な空き容量と明示的なクリーンアップ計画を用意する。書き込みベンチマークを検証されていない生のデバイスや本番データセットに向けてはならない。開始前にツールの対象と書き込み動作を確認し、限定的な実行から始める。合成I/Oは、有用なファイルを上書きしなくても、容量を消費しサービスに干渉することがある。
本番に近い評価では、メンテナンスウィンドウを合意し、アプリケーションの監視を維持する。可能な場合は架空のデータを使用する。速度テストからストレージの信頼性を推測してはならない。整合性チェック、バックアップ、復元は別の作業である。ベンチマークを完了したデバイスでも、削除、ソフトウェアのミス、マシンの喪失に対する復旧戦略が必要である。
アプリケーションの証拠でループを閉じる
レポートサービスが時間の多くをランダム読み取りの待機に費やしているとする。チームは代表的な読み取りパターンをテストし、その後、同等のデータに対して実際のレポートを繰り返す。レポートが改善し、他の作業が安定していれば、その結果はストレージ仮説を支持する。そうでなければ、より広範な合成テストを繰り返すのではなく、クエリ設計、メモリ、その他の依存関係を調査する。
Pulse NVMeと選択された専用構成は、SwissOctetカタログにNVMeストレージを掲載している。それらのラベルは仕様であり、公開されたアプリケーションベンチマークではない。制御された方法で提供環境を評価し、条件を所見とともに保存する。ストレージ測定とユーザーに見える結果が同じ問いに答えるとき、意思決定はより強固になる。
実践チェックリスト。
- まずアプリケーションの問いを定義する。
- パターン、ブロックサイズ、同時実行数、時間を記録する。
- キャッシュとI/Oモードの前提を明記する。
- スループットと併せてレイテンシのパーセンタイルを確認する。
- 検証済みの使い捨て対象と限定的な初期負荷を使用する。
- アプリケーションテストで所見を確認する。
重要な詳細。
シーケンシャルコピーだけでデータベースストレージを比較するのに十分か？+
通常は不十分である。データベースアクセスには、小さなランダム読み取り、書き込み、同期が含まれることがある。関連するパターンをモデル化し、実際のアプリケーションで確認する。
ダイレクトI/Oは耐久性のある書き込みを証明するか？+
いいえ。バッファリングと耐久性は別の関心事である。アプリケーションが必要とする同期動作に合わせる。
1つのテストを保証されたプラン速度として公開できるか？+
いいえ。その条件と範囲を公開する。1回の実行から得られた測定結果は、サービスレベルや将来の性能を保証するものではない。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- fio：柔軟なI/Oテスターのドキュメント fio.readthedocs.io
- NVM Express：仕様の概要とFAQ nvmexpress.org
- Linuxカーネル：Pressure Stall Information docs.kernel.org
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。