やるならまずこれだけは、というものを
重要度順(高 ... 中の上 ... 中 ... 番外編)に並べている
重要度 高
モニタリングツールの導入
テストする・しないに関わらずモニタリングツールを入れる
- 負荷箇所の検出 - N+1, スロークエリ, 長時間読込など
- アラート常時通知
この二つが把握できないと、テストのしようがない
Web モニタリングツール / Web 監視ツール
のような単語で探し、予算内で導入する。詳細は他の優秀な記事に任せる
限界テスト
目的
「システム限界値」把握の為
実施方法
- 負荷環境へのリクエスト量を段階的に上げる
- 以下の点を検証する
- どの時点で、一部が機能不全になるか
- その一部不全は許容されるのか
- どの時点で、完全に機能不全になるか
- どの時点で、一部が機能不全になるか
重要度 中の上
大規模データテスト(ボリュームテスト)
目的
DBその他ストレージの評価性能・移行計画の為
実施方法
(1) 現状把握
本番DBおよびストレージの「データ増加傾向」を理解する
(2) 予測
- どのテーブル(データオブジェクト)が
- どれだけの倍数増えそうか
(3) データ用意
予測を基に多量データを用意する。以下は例
- 基準数
- 基準数 * 2 倍
- 基準数 * 10 倍
- etc.
(4) テスト
「通常のリクエスト負荷」をかけて、挙動を確認する
(5) 検証
テスト後のデータで、次を検証する
- いつまで現状のストレージ構成を保てるか
- いつからストレージ構成変更が必要か
重要度 中
スパイクテスト
目的
突発的な負荷に短時間耐えられるかを検証する為
実施方法
- 短時間で急激に負荷を上げる
繁忙時間(ホットタイム)や突発的イベントで予測されるリクエスト量を集中させる
負荷環境が、その突発性に耐えられるかを検証する
もし余裕があれば
- スパイクの量はどこまでいけるか
もテストする
耐久性テスト(ロングランテスト)
目的
ミドルウェアの性能低下(メモリリークなど)を検出する為
実施方法
最低 24 時間連続で、通常運用時の80%程度負荷をかける
短時間(スパイク)はOKだが、長時間(ロングラン)だと顕在化する問題を炙り出す
主にリソース枯渇周りに着目したい
番外編 - 負荷テストと同時にやりたい
フェイルオーバーテスト
目的
システムダウン時の挙動テストの為
実施方法
意図的にシステム許容外の負荷量を与え、システムダウンさせる
のち、意図した通りに「元通りになるか」を確認する