負荷テストをやる目的
一般的には、システムが、特定のワークロードの元で、応答性(responsiveness)、安定性(stability)の面で、どの程度動作するかを測定するのが目的。さらに最近だとインフラがスケールするのが前提だったりするのでスケーラビリティやSREの方々が取り組んでいるリライアビリティなんかも負荷テストをやることで割り出すことができたりします。
負荷テストの種類
性能テスト スループット
システムの処理能力に着目したテスト。Webシステムに置いては一定時間あたりにどれくらいのユーザが操作を行うことができるかを割り出すためのテスト
性能テスト 応答時間
通常時や高負荷時にシステムの応答時間に着目したテスト。Webシステムに置いてはユーザがリクエストを投げてからどれくらいの時間サーバ側で処理を行う時間があるのかを割り出すためのテスト
限界テスト
限界テストとは、仮に想定以上の処理限界に近いアクセスが発生した場合に、例え応 答時間遅延や処理能力低下が起きたとしてもシステムが正常に動作出来るのかどうかを確認する目的の試験です。
同時接続数をスケールさせた際にスループット/応答時間がどれくらいで頭打ちになるかを確認する。また、限界性能を超えた場合のシステムの挙動を確認したりもします。(例えばエラーページちゃんと出るよねとか)
耐久テスト
過負荷な状態にして障害を発生させると、どういった症状が発生するかを検証したりする。前職ではロングラン試験なんて呼び方もしてたりした。サービスインしたあとにメモリリークとかトランザクションなんかのデッドロックが発生するシビアなタイミングなんかを割り出すためのテスト。更新系で外部サービスをnetwork越しに呼ぶケースがあるならコネクション状態なんかも一緒に見たい(閉じ忘れてないかとか)
特定エンドポイントへひたすらテストするんじゃなくて以下にアプリケーションコードのケースを多く通すかを気にしたいテスト。あんま使わないようなミドルウェアだったりを導入したサービスなら尚更。
確認項目
テストの種類ごとに「何々を確認して〜」みたいなのをやっても良いが結局分析するってなった必要な情報なので個人的にはどんな試験でも以下の要素はとりあえずコンソールを掴むなりログを収集しておきたい。
- レスポンスタイム(平均, 最大)
- スループット(平均, 最大)
- CPUやメモリ等のコンピューティングリソースの使用率(平均, 最大)
- ディスク容量等のコンピューティングリソースの消費量
- エラーの発生頻度
- その他 (ガベージコレクションの発生頻度等)