負荷テストの種類　性能・限界・連続（耐久）テストとは

今回は、負荷テストの種類と題してお送りします。

 

負荷テストには、負荷テストの目的で説明したとおり目的に応じて

• 性能テスト
• 限界テスト
• 連続（耐久）テスト

 

の3種類があります。

 

負荷テストの目的の記事の中では、簡単な例とあわせての紹介だったので、まだイメージがぼやっとしている方もいるかと思います。

 

本日は、そんな方のためにイメージを具体化する手助けをしたいと思います。

 

性能テスト

負荷テストの目的では、「日次（24時間）で10万のアクセスがある」という要件を満たしているかどうかを確認するテストだと例を挙げて説明しました。

 

つまり、

 

要件に見合った性能が担保されているかどうか

 

を確認するために実施する旨、お伝えしました。

 

当然、要件が明確でなければ何も保障できないので、指標を定めることになります。

 

「日次（24時間）で10万のアクセスがある」という要件は、説明するために簡単なものにしていますが、実際には以下の項目について指標の定義がなされている必要があります。

1.  一定時間内にサイトに訪れるユーザの最大数
2.  最大同時アクセスユーザ数
3.  主要なページの平均応答時間

 

１，２はシステムの処理能力を測るもので「スループット」と呼ばれ、3はシステムの応答時間を図るもので「レスポンスタイム」と呼ばれたりします。

 

例では、1に該当する「日次（24時間）で10万のアクセスがある」という要件しかありません。

 

2、3については情報が足りていないのでしっかり要件定義する必要があります。

 

仮に、クライアントへのヒアリングの結果、

• メールマガジンを配信した直後が一番アクセスがある。過去、最高10,000アクセスの実績があった。
• 3秒以上かかると40%以上のユーザーは離脱する、という調査結果を基に、社内で品質基準を定めている

 

ということが分かれば1,2,3それぞれ、

1. 24時間で10万アクセスが処理できるか
2. 10,000同時アクセスがあった場合でも処理ができるか
3. ページアクセス後、3秒以内に画面が表示されるか

 

を指標として定めることができます。

 

指標を持つと、何も知らないクライアントから「必ずクリアしなければならないもの」と思われることもあります。

 

コンビニのレジや銀行で使うような稼働率100%を求められるシステムであれば話は別ですが、Webサービスの多くは、サービスを提供する上で最低限必要な項目だけに絞ったり、9割の達成度であれば「良」と判断しているケースが多いです。

 

限界テスト

その名のとおり、

 

システムの限界を把握する

 

ために実施されます。

 

限界テストは、性能テストで定めた指標を弄って実施することが多いです。

 

たとえば、「1時間に10,000アクセスあり、内訳として5000人が平均2ページ回遊する動きをする」というサイトだったとした場合、

• 5000人　→　6000人　→　7000人　・・・・・　10,000人

 

というように、徐々にアクセスする人数を増やしていき、何人で頭打ちになるかを確認します。

 

このテストをすることで、運用の中で問題発生した場合に「いつ」、「何をするか」を決めることが出来ます。

（前提として、「限界に近づくアクセスが発生した場合に、サーバーをスケールアウトする」などの対策案を考えておく必要があります）

 

また、インフラ試算を行いあらかじめ要件を満たせるようなサーバを構築した場合は、その仮説と比較してどうだったかというチェックが出来ます。

 

ただし、あくまでシステム的に処理ができているかどうかの判断になるため、ユーザ側のレスポンス状況は含みません。

 

連続（耐久）テスト

連続（耐久）テストは、限界テスト中に気づかないうちに実施してしまっているケースが多いです。

 

ただ、限界テストとは確認するべき視点が異なります。

 

連続テストは、

 

一定期間、恒常的に限界に近いアクセスが続いた場合、サイトがどのような挙動をするか

 

を確認するテストになります。

 

たとえば、ECサイトであれば、

• ユーザが商品を選択し、購入手続きをしたら、完了画面へ遷移する途中で画面が固まってしまった

 

なんてことがあったらユーザは不安になります。

（特にお金が絡むと信用問題にかかわります）

 

連続テストは、このような問題をあぶりだし、対策を施しておくことをゴールとします。

 

「性能テストで要件を満たしているから良いのでは？」と思われる方もいるかもしれませんが、性能テストはあくまで保証すべき指標に対して、合否の判断をします。

 

しかしながら、たとえ合格したとしても、運用の中でユーザの期待値を100%保障するものではありません。

 

ただし、すべての問題に対して対策を講じることは難しいため、サービスとして最低限保障しなければいけない処理だけに絞って実施することが多いです。

 

テスト実施にあたって

説明したとおり、「負荷テスト」といっても目的に応じて実施するテストが異なります。

 

それだけ聞くと、「別々にやる必要があるのか。。。」と思われがちです。

 

ところが、テストシナリオは、同じような感じになるので計画次第ですが、まとめて実施してしまったほうが効率が良かったりします。

 

そんなわけで次回は、負荷テストの計画について紹介したいと思います。