負荷テストの目的 システム開発案件の注意ポイント
アプリケーション開発が必要なプロジェクトでは、ほぼ必ず負荷テストがプロジェクト計画に組み込まれます。
システム案件において、プロジェクト計画の段階で「負荷テスト」が抜けていたら、おそらく公開後に炎上します。
(僕自身、負荷テストをしないことで炎上したプロジェクトがあります。詳細は負荷テストへの想いで触れていますので興味のある方はどうぞ)
また、システムをちょっとかじった上司がプロジェクト計画のレビューに入っていたら「負荷テストをやりなさい」と指摘を受けるでしょう。
システム案件に明るいプロジェクトマネージャー/ディレクターでない場合、負荷テストなんて聞いたことはあるけど具体的に何をしたらいいかわからない。
なんてことになります。
ですが、上司に何をしたらいいかを尋ねても教えてくれることはなく、
自分で調べろ
となります。ググレカスってヤツです。
(まぁ、そういうプロジェクトを経験した人を教えてくれるくらいのことはしてくれるでしょう)
同僚に聞いても、「システム案件に詳しくないからよくわからない」と言われ、どうしたらいいかわからない。
何もできないから、目の前にわかっているできる作業から進めて、負荷テストのことは後回し。
寝てる間にコビトさんがやってくれるわけはないので、負荷テストに関するタスクは何も進展はしない。
結局、誰も何しないまま、日々が過ぎていき、忘れたころに問題発生。
大炎上!っとなってもやること変わらず、徹夜で目の前のタスクをもぐらたたきのように対応して、クライアントに怒られながらなんとか鎮火。
みなさんも経験あるのではないでしょうか。
(なお、教えてくれる先輩がいたとしたらとても優良な企業です。一生その人についていきましょう)
Web屋ってそういうもんです。ハイ。
そんな貴方のために、負荷テストについて説明してみたいと思います。
はじめに
僕自身、負荷テストには思い入れがあります。
負荷テストに対してこだわりをもったせいか、今では負荷テストをしないプロジェクトに関わることがありません。
(嬉しいやら悲しいやら。。。。いや、とてもありがたいことです。)
そこで今回は、
何のために負荷テストを実施するのか
という、目的について説明していきます。
負荷テストの目的
負荷テストの実施目的ですが、一言で言うと
この性能要件を満たしているかどうかを確認し、不十分な場合、対応案を検討し解決を図る
ためです。
ここで言う性能要件とは、Webサイトのパフォーマンスのことになります。
話をわかりやすくするために、具体的な例を挙げて説明していこうと思います。
例えば、リニューアルの案件で以下のような要件があったとします。
- 現在、日次で10万のアクセスがあるので、リニューアル後も同様に処理できること
日時の部分を数字にすると、24時間で10万アクセスを処理できることを保障することになります。
ただし、上記の例では「リニューアル案件」としたので、リニューアル前の実績を目標値と定めることが出来ています。
つまり要件定義の段階で、
どの程度のアクセスを想定しているか
を話していなければ成立しないです。
もちろん、プロジェクトによっては、「新規でサイトを立ち上げる案件で、前任者がサイトの性能に関する要件を握らずに進め、プロジェクト半ばにして音信不通になり、後任としてアサインされた」、なんて状況で引き継がれることもあります。
こんな感じですね。
そんな場合は、要件をヒアリングして、要件に見合った性能を保証するまでチューニングするのも良いですが、
どの程度のアクセスに耐えられるのか、限界を把握し、それで不十分あるならば追加予算・スケジュール延期の交渉をする
ことを、目的として負荷テスト実施してもよいと思います。
また「100万人の会員がいるECサイトにて、新商品を案内するメルマガを5万人づつ1時間おきに配信する」なんてサービスの場合は、長時間にわかってサイトにアクセスが発生する可能性があります。
その場合は、
高負荷状態が20時間続いても問題ないことを確認したい
なんていう「連続(耐久)テスト」というものもあります。
限界値、連続テストについては、その閾値を知ることで、どのタイミングでどういう対応をすればいいかを事前に検討できます。
リスクマネジメントの考えで言うと、問題が発生した場合にどうするかを事前に考えておくということです。
最後に
いかがでしでしょうか。
負荷テストの目的は理解できたかと思います。
次回は、今回触れました負荷テストの種類である、性能・限界・連続(耐久)テストについて紹介をしたいと思います。
コメント一覧
コメントはありません