概要

負荷試験を理解し、負荷試験を始めることができるようになるためのガイドとなるような内容をまとめます。

負荷試験とは

システムの性能を検証するためのテスト手法である。

「システムが想定しているキャパシティ（性能の許容値）を確保できているか」、「過剰な負荷によりどのようなシステム影響が発生するか」、「性能に関わるボトルネックがどこにあるか」などを明らかにするためのテスト手法となる。

※ この記事では負荷試験とパフォーマンステストを、負荷テストとロードテストはそれぞれ同義として扱う。

手法

負荷試験には大きく分けて4つのテスト手法がある。

定義は色々あるが、概ねこの4つの手法に該当できると思われる。

負荷試験の目的（何をテストしたいか？）に応じてテスト手法を選択する。

ロードテスト（Load Testing）

一定水準のリクエストでテストをする手法である。

「想定している性能を満たしているかどうかを検証すること」が目的となる。

ストレステスト（Stress Testing）

限界を想定したリクエストでテストをする手法である。

「性能限界の水準を明らかにしたり、許容値を超えたときにシステムがどのような障害を発生させるかを検証すること」が目的となる。

ソークテスト（Soak Testing）

一定水準のリクエストを一定期間（長時間）かけてテストする手法である。

「システムのリソース状況に応じてどのような影響は起きるか検証すること」が目的となる。

ソークテストはロングランテストと同義である。

ベースラインテスト

単一のユーザーのリクエストに基づいてテストする手法である。

「性能の基準値を特定したり、他のテスト結果と比較してパフォーマンス低下の度合いを分析したりすること」が目的となる。

※ ベンチマークテストとベースラインテストは同義なように思われるが、違いがあるらしい。

cf. loadview - ベンチマークテストの説明

負荷試験の流れ

計画と実施に分けて負荷試験の流れを説明する。

計画

目的設定

性能劣化がないことをテストしたいのか、限界性能を知りたいのか、要求される非機能要件を満たしたいのか、など何のために負荷試験を実施するのか？という目的を明確化する。

**目的を果たさないとどんなリスクがあるか？**リスクとセットで考えると良い。

ex.

• 既存APIの改修により、APIの性能劣化がないことを確認したい
• 新機能を公開するが、想定トラフィックに耐えうるか検証したい
• APIのスロットリングやクォータを定めるために性能傾向を把握したい

調査

目的に応じて、試験対象とするシステムの構成や機能の仕様、アクセス状況などについて調査する。

• インフラ構成
• 機能の仕様
• システムリソース利用状況
• アクセス状況

など計画に必要な情報を十分に整理しておく。

準備が不足すると試験実施時に場当たり的な対応が増え、試験結果の信憑性に影響を与える。

合わせて試験実施環境についても確認しておくと良い。

性能目標と計測指標の設定

目的の達成基準として性能目標を明確にする。

ex.

• 同時接続1000人以上でトップ画面にリクエストがあるとき、レスポンスタイムが平均800ms以下であること
• 定常時のリクエスト量を営業日を想定した期間継続的に受け付けたとき、CPU使用率が平均20%前後で推移すること

性能目標が具体的であればあるほど、計測指標も想定しやすくなる。

テストシナリオ作成

システムへの負荷をどのようなリクエストで行うかを明確にする。

目的や手法などに依るが、試験対象がユーザーにどのような使われ方をするのかに基づいて考える。

例えば、マイページのレスポンスタイムを検証する負荷試験であれば、

1. ログインページにアクセス
2. ログインボタンを押下
   • 認証情報がcookieにセットされる
   • ユーザー情報取得APIが呼び出される
3. マイページに遷移
   • 認証処理を経て、リダイレクトする
   • ユーザーの設定情報取得APIが呼び出される

などといったフローが想定される。

試験対象について、ユーザーがどのような状態を持ってリクエストするかということを明確にし、エミュレートする必要がある処理を書き起こす。

実施

1.準備

試験実施に向けて以下の準備を行う。

• 実施環境の準備
  • 負荷試験実施を行うインフラ環境や、負荷試験ツールなど準備する
• テストデータの準備
• 関係者への共有
  • 負荷試験の実施による影響を社内外問わず関係者に共有する
    • →事前に影響範囲を見積もっておく
• 監視対象の確認
  • 試験実施で利用する監視対象（ログ、メトリクスなど）を整理しておく
  • 監視ダッシュボードを事前に用意しておくと良い

2. テスト実施

テストを実施する。

3. 結果分析

どこがスパイクしたとか、増加・低下傾向があるとか、見慣れないエラーが頻発しているとか観察し、原因や対策を検討する。

チューニング

分析結果に基づいて必要があればチューニングを行い、再実施する。

まとめ

何はともあれ、目的が大事になる。目的がブレるとその後プロセスが意味を持たなくなってしまう。

参考

• キャパシティプランニング
  • 古い本ですがキャパシティプランニングについて書かれた希少な本
  • クラウド主流の現代においてキャパシティプランニングの意義がなくなったわけではないので持っておいても損はなさそう
• Web APIテスト技法
  • 負荷試験の実施方法についてあれこれ書いている本ってあんまりない印象だが、この本では1章割いて書いてくれている