負荷テストの計画 目的達成のために考えなければならないこと

負荷テストは、その名のとおり「テスト」になります。

 

テストと聞くと、以下の画像のようなテスト項目書を作成しその項目に対して、合否を判定するようなものをイメージされるかたも多いと思います。

 

ところが負荷テストの場合、一般的なテスト項目書のように体系化されたフォーマットは存在しないため、目的に応じてテスト内容を策定する必要があります。

 

そのため、負荷テストを実施するためにはいつ・どこで・誰が・何を・いくらかけてやるのか、つまりテスト計画をを考えないといけません。

(実際、負荷テストはプロジェクト全体のサブプロジェクトに位置づけられます)

 

そんなわけで、計画するにあたり何を考えたらいいかについて説明したいと思います。

 

はじめに

Web屋で実施される負荷テストプロジェクトは、一般的に以下の要素で構成されていると思います。

• 目的・目標
• 作業範囲
• テストシナリオ
• 実施方法
• 調達
• コスト
• 体制・スケジュール

 

よくあるWebサイトのプロジェクト計画とほぼ同じですね。

 

１点「テストシナリオ」という項目がありますが負荷テストを成功させる上での重要な要素になるので、ここはいつも時間をかけて考えています。

 

それでは、それぞれについて説明していきます。

 

目的・指標

「要件に見合った性能が担保されているかどうか」を確認するために、

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

 

これらの項目に目標を定めます。

 

こちらは、負荷テストの種類にて触れていますので、詳しくはそちらをご覧ください。

 

作業範囲（作業スコープ）

Webサービスは範囲が多岐に渡るので、影響範囲すべてに対して実施するとなるとかなりの時間と労力がかかります。

 

そのため、プロジェクト内容や負荷テストの目標に応じて範囲を定義します。

 

具体例を挙げて説明しますと、サービスの主要な画面フローが性能を満たばOKとするのであれば、その部分だけのテストシナリオを組んで実施すればよいですし、また他社のクレジット決済システムを利用している場合、他社サーバの処理性能については、こちらではどうすることも出来ないため、スコープ外とするほかありません。

 

後者の場合は、限界値を把握するため負荷テストはするが、他社サーバはチューニングの対象外にするなどして範囲を限定したりします。

 

テストシナリオ

目標を達成するために、Webサイトでどのような挙動をすればよいかを定義します。

 

会員サイトを例に挙げると、

 

「会員100万人が一度にログインしても問題ないこと」という目標を定めた場合、

 

トップページ　→　ログイントップ　→　ログイン処理　→　マイページトップ

 

といった画面フローが考えられます。

 

このような一連の流れを1シナリオとして定義し、必要な分だけテストシナリオを策定します。

 

テストシナリオが洗練されていると、効率よく負荷テストを実施することが出来ます。

 

実施方法

目標によりますが、「1時間に10,000アクセス」するテストを実施する場合に、10,000人、10,000端末を用意するのは現実的ではありません。

 

そのため、負荷ツールを利用する、自社でテストプログラムを開発する、など高負荷状態を生み出すツールを利用することになります。

 

有料・無料がありますが、有名なものとして、

• Apache JMeter
• Apache Bench
• Load Impact
• HP LoadRunner

 

などがあります。

 

どれも一長一短ありますが、僕はApache JMeterの実績が一番多いです。

 

Apache JMeterを利用した負荷テストに興味がありましたら、準備から紹介していますので是非ご覧ください。

 

コスト

徹底したテストを行いたいところではありますが、クライアントから費用をいただくので、ROI（投資対効果）を鑑みて提案することになると思います。

 

いくら「予算がない」と言われても「負荷テストをしない」という選択肢はないので、必要最低限に絞って実施することもあります。

（理由は負荷テストへの想い参照）

 

体制・スケジュール

誰がいつ何をやるかですね。

 

ディレクション、プロジェクトマネジメント、テストシナリオ策定、テスト実施、結果分析、パフォーマンス改善、その他調整、などの作業をする人が必要になります。

 

Web屋の場合、負荷テストに限らず、いくつか兼務して少数精鋭で体制を作ることが多いです。

 

また、スケジュールはプロジェクト全体のスケジュールとか別に負荷テスト内だけに絞って詳細スケジュールを引きます。

 

これは、負荷テストの時だけアサインするという人もいるため、負荷テスト実施メンバーだけで顔合わせして簡単なキックオフをしたりするためメンバーに周知するために負荷テストだけに切り出して準備しておくと都合が良かったりします。

 

調達・調整

普段から、システム案件に従事していれば問題ないと思いますが、配慮しなければならないことが結構多いです。

 

ツールを使うとなれば、負荷を生み出すのに十分なスペックの端末の手配が必要です。

 

また、高負荷状態になるのは端末・サーバだけではなくネットワークにも負荷はかかります。

会社で実施するとしたら、利用しているネットワーク機器がボトルネックにならないかを確認したり、また契約しているプロバイダに問題ないかを確認することも必要です。

 

さらに、別で運用中のサービスが同一サーバで稼働中の場合、負荷をかけると他サービスに影響が及ぶため、作業時間を調整したり同一のサーバ環境を新たに構築するなど、手配が必要になります。

 

さらにさらに、従量課金のサーバをレンタルしている場合には、テスト後に多額の請求がくる可能性もあります。

 

テスト計画を十分に検討し、事前準備をしっかり整えましょう。

（なお、僕の負荷テスト失敗談も記事にしていますので気になる方はコチラからどうぞ）

 

最後に

僕の経験では、負荷テストはいつもインフラ担当者と二人三脚でやることが多いです。

 

それは、僕自身インフラタスクに弱いこともありますが、それ以上に「知っているかどうか」の問題が大きいからです。

 

なので、インフラに強い担当者と仲良くしておくことをオススメします（笑）

 

たまたまかもしれませんが、僕がかかわったインフラ担当者の人は全員良い人でした。

 

僕自身負荷テストにこだわりをもって仕事が出来るのも、こういった方たちとつながりが背景にあるのかもしれません。