性能負荷テストの進め方 ～計画編～

概要

以前性能テスト（負荷テスト、パフォーマンステスト）の推進を行った際に学んだことや考えていたことを備忘がてらまとめていこうと思います。少し長くなりそうなので、3回ぐらいに分けて書いていこうと思います。今回は計画についてです。
※ロングランテストの話は今回は省きます。

性能テストって何？

名前の通りシステムの性能が要件を満たしているか確認するテストです。負荷をかけた状態で要件通りの性能が出るかをテストします。負荷テストやパフォーマンステストとも呼ばれるようです。私の周りでは性能テストと呼ぶ人が多いので、ここでは性能テストと呼ぶことにします。

テスト対象を選定する

本来的には全機能で実施すべきですが、決められたコストや納期の中ですべての機能に対して性能テストするのは現実的に厳しいです。そのため、性能問題が起きやすい機能に絞って性能検証を行う必要があります。例えば以下に該当するような機能を抽出し、スケジュールと相談しながら対象機能を選定していきます。

性能問題が発生しやすい機能

• 大量のデータを処理する機能
  • バッチ機能
• 大量データのDBアクセスが生じる機能
  • 一括登録/更新機能
  • 検索機能
• ディスクI/Oのある機能
  • ファイル出力機能
  • ファイルをインプットとする機能
• 通信負荷が発生する機能
  • 外部APIを実行する機能
  • ファイルのアップロード、ダウンロードが発生する機能
• ユーザから大量に実行される機能
  • ログイン機能
  • TOP画面表示
• その他特殊な処理を行う機能
  • マルチスレッド処理
  • トランザクション分割
  • CPUを多く使用する機能（ex.圧縮処理)

想定負荷を考える

負荷をかけずに性能テストを実施してしまうと、実運用でアクセス負荷が上がった際に十分な性能が出ることを担保できません。そのため、性能テストでは実運用時に想定される負荷をかけながらテストを行います。どんな負荷をかけるのか、どうやって負荷をかけるのか、事前に決めておく必要があります。例として以下を決めていくことになります。

• 何年後かの想定ユーザ数やデータ数
• ピーク時の想定TPS
• テスト実施時片系なのか両系なのか （冗長構成をとる場合）
• どのテストでどこに負荷をかけるか
  例）・システム内テストではネットワーク負荷はかけない
  　　・オンライン処理とバッチ処理を並行実施するかどうか（運用面）
  　　・流量制限の単位（機能単位or全体）を考慮する
• アプリサーバへの負荷のかけ方
  計測対象機能が載っているサーバに対する負荷
  例）・計測対象のサーバで計測対象と同一の機能を実行する
  　　・計測対象のサーバで計測対象とは別の機能を実行する
• インターネット負荷のかけ方
  実際に発生しうる通信負荷をかける
  例）・外部APIの実行
  　　　自システムへの想定負荷から外部APIの実行TPSを決定する。
  　　・ファイル授受
  　　　送信に時間のかかる巨大ファイル送受信やファイルの繰り返し転送により、テストシナリオの実施中常に負荷をかけるようにする。
• DB負荷
  計測対象の機能が載っていないサーバでDBアクセスのある機能を実行する。
  • オンライン機能の計測中にバッチを実行する。
  • バッチの計測中にオンライン機能を実行する。

合格条件を決める

性能テストの合格条件は指標値が定められた目標値を満たすことです。この指標値と目標値も事前に決める必要があります。

• 各指標値の定義
  • サーバリソース
  • レスポンスタイム
  • 負荷
• 各指標値をどうやって測定するか
  • サーバリソース
    • vmstat等の監視コマンド
    • 他システムについてもテストする場合は、テスト実施中の対抗先サーバリソースに異常がないか確認が必要。
  • レスポンスタイム(Web機能)
    • クライアントに対するレスポンスタイムで定義するならば、例えばJMeterの「Latency」「ElapsedTime」等を使用する
    • 外部APIの実行時間は差し引いて計算する
      ⇒外部APIの実行時間や、それを含めたシステム全体でのレスポンスタイムについてはシステム間テストで別枠としてテストを行う
  • レスポンスタイム(バッチ機能)
    • 基本的には処理完了までの時間を指標値とすることが多い
    • 外部APIの実行時間は差し引いて計算する
  • システム間のネットワーク帯域等、誰が測るのか、どうやって測るのか、明確に責任を分解しづらい範囲は会社間で問題となる可能性があるので注意

テストで利用する環境を決める

性能テストを実施する環境についても検討が必要です。いつ、どこの環境を使用するのか調整するほか、以下についても注意が必要です。

• テスト中占有できるのかどうか。できない場合はスケジュールを調整する。
• 本番環境と可能な限り同一の構成、スペックの環境を用意する。
  ⇒開発やステージング環境で実施する場合、クラウド環境で運用するシステムであれば開発環境のスペックを一時的に増強する等の対応を行う
• 対抗先の利用環境は本番かテスト用の環境か確認する。
• 外部APIを使用する機能の場合、使用するAPI側とテスト時にかける負荷について対向先と合意を取っておく
  • 何TPSの通信が可能か
  • 連続して実行しても問題ないか（問題がある場合は実行間隔をあけるなどの対処が必要）
  • 実行してよい時間帯はいつか

テスト計画書を作成する

ここまでで決定した事項をテスト計画書としてまとめます。

参考

性能要件を決める際はIPAの非機能要求グレードを用いるのが良いかと思います。

• システム構築の上流工程強化（非機能要求グレード）：https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html

続きの記事

次は準備・実施について書こうと思います。鋭意作成中です。