今回は「性能テスト」について「なんでやるの？」「どんなことやるの？」についてまとめます。
世間一般だと「負荷試験」とも呼ばれたりしていますが…まぁ、非機能の確認と思えば一緒のような気もします。
性能テストの必要性
なぜ性能テストを実施するのか
性能問題は往々にしてC/O後に問題が見つかります。 通常行われる機能テストだけで検出できない問題のため、専用のテストを行っていないと性能問題がC/O後に発覚します。 また、C/O後に性能問題が発生すると、以下のような問題が発生します。
- サービス利用している事業者や利用者に対する影響
- 金銭的な損失、
- 機会損失
- 場合によっては人命に関わる問題
- 金銭的な損失、
- 自社に対する影響
- サービス提供先への損害賠償
- 社会的な信用の失墜
- サービス提供先への損害賠償
加えて「発生した問題に対して原因究明が難しい」という問題もあります。
性能テストの目的
何のために性能テストを行うのか
前述の必要性から考えると「想定されるリスクに対して開発したシステムが対応できていることを確認する」と言えるでしょう。 ただ…これは「（可用性、効率性、拡張性に関する）非機能要件が満たされていることを確認する」とも言えます。
想定されるリスクや性能テストに対する要件には以下のようなものが考えられます。
業務視点
- C/O直後の大量登録処理が問題なく行えるか
- 順調に稼働したあと想定している利用者数の主要操作が問題なくさばけるか
（＝数年後を想定したデータを入れた状態でピーク時、通常時どちらも問題なく動作するか） - キャンペーンなど突発的なアクセス集中に耐えられるか
- 24H365Dの無停止運用できるのか
- 想定ユーザー数をさばける構成でできるだけ安くしたい
（＝目標値を満たせる最小構成を明らかにしたい）
システム視点
- バッチなど他システムによるDB操作とのバッティングが起こらないか
- システム再起動直後でキャッシュが揮発していても大丈夫か
- 性能限界はどのあたりにありそうか
- 性能限界を超えたようなときでも問題は起こらないか
- スケールアウトできるか
- スケールアウト/スケールアップするべき箇所はどこか
性能テストの種類
性能テストの種類は名前だけだと大きく３種類に分けられそうです。 ただ…実態は「何のために」に依存するので、このテスト種類はあくまで参考程度な気がします。
- ロードテスト
- ストレステスト
- ロングランテスト
ロードテスト
システムに対して想定されるシナリオをベースに負荷がけして応答性能を確認するテスト。
シナリオは各種ユースケースを想定して作成します。 確認するのは「スループット」を増やしていったときの「レイテンシ」です。 「スループット」と「レイテンシ」が目標範囲内であるかどうかを確認します。 目標に納まっていなければ原因究明して性能改善を行っていくのもロードテストの範囲です。
ストレステスト
性能限界を超えたアクセスがあったときの挙動を確認するテスト。
「目標値」を超えただけだと限界に至っていないことがあります。 ストレステストで確認したいのは「限界を超えたときの挙動」です。
システムに対して想定以上の負荷が加わったとき処理性能の劣化だけでなくデータ不整合などが起きないかを確認します。 想定外の事態が発生したとしてもデータだけは安全であることの確認をします。
ロングランテスト
24H365Dを求められるようなケースでは、長時間稼働させたときの挙動確認も行います。
長時間稼働させた際、ガベージコレクションが適切に動作しているか、そのときシステムが長時間停止しないか、ガベージコレクションが動作した後はメモリがリークせず十分解放されているか…などを確認します。
（おまけ）目標値
ある程度サービスが稼働した数年後をイメージして以下を確認します。
- 想定ユーザー数（累積）
- ユーザービリティの観点から求められる応答時間
- 1日の利用者数（○人/日）
- 1人あたり1日の平均アクセス数（○回/人日）
- 1日の平均アクセス数に対する最大ピーク時倍率
上述の値を確認することで、目標とする「スループット（rps）」と「レイテンシ（msec）」を求めます。 また、前提となるデータ量についても算出します。
今回は「性能テスト」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！
最後に… このブログに興味を持っていただけた方は、 ぜひ 「Facebookページ に いいね！」または 「Twitter の フォロー」 お願いします！！