- 2022年6月13日
稼働しているWEBシステムとそのサーバの負荷検証を行う機会があったので、これをきっかけにシステム負荷に関わるテストについて整理していこうと思います。
性能テスト（パフォーマンステスト）
負荷テストという言葉はよく耳にしますが、この類の○○テストは総じて「性能テスト（パフォーマンステスト）」として呼ばれることが多いようです。そのため負荷テストも性能テストの一部という認識です。
ただし、他のテスト（単体テスト、結合テストの範囲など）もそうですが、特に性能テストのテストアプローチについては人によって解釈が大きく異なるので（性能テストも総称ではなく横並びだったり、検証内容が重複していたり）組織やチームで事前に言葉の定義と認識の共有をしておくのが良さそうです。
性能テストのアプローチの種類
色々と調べていくと「負荷のかけ方」と、それに対して「何に着目するのか」で分類できそうだったので、自分なりの解釈も入れつつ定義してみました。
| テストアプローチ | 負荷のかけ方 ／度合 | チェックするポイント |
|---|---|---|
| ロード(負荷)テスト | 利用想定の上限に限りなく近い負荷 | 負荷が高い状態でも定義した要件通りに動作するか |
| ストレス(限界)テスト | 利用想定以上の負荷 | 処理速度は低下しても動作はするか、タイムアウト時など正しくエラー処理が行われるか、データの不整合が生じないか |
| 耐久テスト | 長期的なシステムリソースの限界に近い負荷 | SLAやSLOで定義されたパフォーマンス要求の達成を目的とし、長期間連続運用しても十分なスループットとパフォーマンスが維持できるか。またメモリリークが発生していないか |
| スパイクテスト | 瞬間的なシステムリソースの限界以上の負荷 | 他のアプローチでは徐々に負荷をあげながら検証を行うが、対してこちらは短い時間で負荷を与えることにより、同期不良、競合の発生がないかを検証する （クラウド等の場合はオートスケールの挙動も確認） |
| (拡張性テスト) | システムリソースの限界に近い負荷 | 現状の処理が可能なデータ量やアクセス数を把握し、将来的に処理量が増加した場合を想定して、しきい値の設定／超過時の通知、その後の対応方針・対応方法の事前準備を実施 |
こうして見ると、ロード／ストレステストはソフトウェア寄り、拡張性テストはハードウェア寄り、耐久／スパイクテストはソフト・ハード両方といった印象です。ただし、拡張性テストに関しては”テスト”というよりかは”先を見据えた下準備”という感じですね。
非機能要件の定義とそのテストケースを考える際、上記の分類自体は特に重要ではなく、その観点を持って検討がなされているかどうか。が分かりやすく判断できるようになるのではないでしょうか。
ただし分類ごとにテストケースが分かれている必要はなく、またプロジェクトの性質によっても実施すべき内容は変わります。極端な例だと、スタンドアロン環境で同時に１人でしか利用されず、毎日定時でシャットダウンされるようなシステムでは、耐久テストやスパイクテストまでは不要だと思われます。逆に 24H365D 稼働するシステムであれば、耐久テストは必須となるでしょう。
性能テストにおける評価指標（性能要件）
性能テストの実施時、定量的に評価する指標について大きく「ハードウェアリソース」と「Webシステム」に分けて比較的よく目にするものをまとめてみました。
■ ハードウェアリソース
| 評価対象 | 評価内容 | 備考 |
|---|---|---|
| CPU | 使用率 | ■ ユーザーモード 純粋なアプリケーションプログラム中のルーチンでの消費 ⇒ コードやアルゴリズムを見直しを図る |
| ■ システム（カーネル）モード システムコール以下のレベルでカーネル処理やI/O等を消費 ⇒ I/Oの高速化、リソース使用の効率化を図る |
||
| 処理待ち数（ロードアベレージ） | １プロセッサ（コア）あたりの瞬間の処理要求数の平均 ⇒ プロセッサ（コア）数を超えていないか |
|
| メモリ | 物理メモリの空き容量 | キャッシュ／バッファ量もチェック |
| スワップ／ページング頻度 | 秒間あたり平均で約「４」件以下か | |
| キャッシュ効率 | ★ 一定期間サンプリング | |
| ディスクビジー率 | 「30」 以下か | |
| 処理待ち行列 | 「2」 以下か | |
| ストレージ | 読み書き速度 | ★ 一定期間サンプリング |
| ネットワーク | 送受信トラフィック量 | ★ 一定期間サンプリング |
★ ・・・ 平均値と比べて著しい変化がないか（運用監視型のアプローチ）
■ WEBシステム
| 評価内容 | 備考 |
|---|---|
| 同時接続ユーザー数 (仮想ユーザー数) | システムに対して接続状態になっているユーザーコネクション数 |
| 秒間のリクエスト数 (スループット) | 1秒間に処理を行うHTTPリクエストの数 |
| 秒間のエラー数 | |
| 1実行あたりの性能 (レスポンスタイム) | リクエストからレスポンスまでどれだけかかったか |
非機能要件を定義する際や、テストケースの成否の判断、運用監視時のアラートのしきい値として、各項目の基準を予め設けておくのが良さそうです。
ただし、利用想定からこれらの基準を導き出すことは非常に難しいことだと思います。
後述の参考リンクにも記載していますが、見積もり手法なども活用しつつ、上流工程の中で確りと検討することが必要となります。
まとめ
システム導入において、Q（品質）C（費用）D（納期）そして昨今では特に重要視される”S”eucure（安全／セキュリティ）がトレードオフの関係です。
（ちなみに余談ですが、「安全／セキュリティ」と「利便性」もトレードオフの関係となり、Sに力を入れすぎると利便性がめっちゃ下がります、、、）
残念ながら、この中で真っ先に犠牲になるのは Q（品質）だと感じています。
なぜなら品質は、導入検討 ～ 運用開始フェーズにおいては評価の優先度が低いからです…。（そして後からシワ寄せが・・・）
品質を担保するためには導入後、運用を開始してからでは遅く、前述のように事前の上流工程から検討に含める必要があります。
システムは導入してからが本番なのに、稼働してからまともに運用できないようでは本末転倒です。
しかしながら、品質を優先して他の比重を下げることもできません。
そこで、費用を抑えつつ、品質の担保を図るために、OSSの活用を検討します。
次回は性能テストやシステム監視に役立つOSSの紹介をしたいと思います。