Webアプリケーションの負荷テストツールが、なぜ普及しつつあるのか？ Part 2

ソフト＆ハード

» 2009/11/17

昨日のブログ

2009/11/16 Webアプリケーションの負荷テストツールが、なぜ普及しつつあるのか？ Part 1

に続き、Part2です。

昨日、利用シーンとして、

サーバ・ネットワークのサイジング時
アプリケーション開発のカットオーバー直前
運用中のバージョンアップリリース毎

という予防的な3点を挙げさせて頂きましたが、それ以外でも、「障害発生後」という後処理的な利用（検証・対策後の効果測定を含む）も、かなり増加してきたように思われます。

新商品のキャンペーン、TV番組やニュースなどのメディアで紹介された直後には、とてつもない（予想をはるかに超えるような）アクセス集中が起きることがあります。

Yahoo!のTOP（ニュース）に掲載された　→　サイトダウン

よくあります。

最近では、久しぶりの台風上陸という朝に、交通機関（鉄道など）や公共機関（学校など）のサイトにアクセスが集中して、サイトダウンまたは表示スピードが大幅に遅くなるといった減少に見舞われたというケースもあったことでしょう。

BIG-IPなどのロードバランサを4・5年以上前など早期に導入したサイトで、不況などによりハードウェアのリプレイスが遅れている場合などでは、既に想定していたアクセスを大幅に超えている状況下で、当時のハードウェアのスループットでは耐えられない状況になっているケースもあるかと思います。

そこで、数百・数千・数万という同時アクセス（過負荷）に対して、どのような対処をするかという検討および実施を迫られることになります。

サーバ、ネットワーク環境などのハードウェアスペックアップおよび多重化
回線のスペックアップ（ネットワーク回線の帯域アップ、冗長化およびCDNの活用など）
ミドルウェアの変更（バージョンアップ、パッチを含む）
アプリケーションの改修（SQLレベルのチューニングを含む）

これらの１つまたは複数を選択して実施することになりますが、

どのレベルのアクセスまで耐えられるようにすべきなのか
真のボトルネックを追求せずに、スペックアップすべきか、追求すべきか

つまり、『どこまでスペックアップすべきなのか』という悩ましい問題です。

障害発生があったということは、本番稼動中＝運用中なので、安易に何度も停止させての環境変更試験を行うわけにもいかないでしょう。

対策予算が無尽蔵にあるサイトも少ないことでしょう。

となると、処理能力などの理論的なスペックで、どーんとリプレイスしていまうか、限られた試験環境であっても、擬似的に過負荷をシミュレーションして、解決策を模索して、オーバースペックにならない（常時スカスカな10人乗りジャンボジェットにならない）ような計画を立てるかということになるかと思います。

CDNの適用に関しては、近年になり、低価なサービスが増加しているので、スグに試すことも可能かもしれませんので、お勧めできますが、しかしながら、自前のインフラを前提としているサイト（セキュリティを含む方針・ルールがある場合）においては、既存の試験環境で、対策を検討することになります。

もしも、テスト用のハードウェアを借りることができると、スペックアップ前後の対比が容易になるかと思いますし、日頃から付き合いのあるメーカやベンダーさんも、リプレイス案件を受注したいので、協力してくれることでしょう。（それでも、環境構築の要員は必要です。）

ミドルウェアやアプリケーションの改変・改修前後でも対比が可能でしょう。
（こちらも構築や開発運用の要員を稼働させる必要がありますが、おそらく必須なワークです。）

但し、これらの前後の状態を掌握するためには、過負荷を発生させる必要があり、そこを負荷テストツールが担うことで、検証・検討を進めることが容易になります。

プロフェッショナルサービスを外部に委託しての実施も可能でしょう。

但し、検証したい組み合わせも多く、また、高額なプロフェッショナルサービスであれば、丸々任せるわけにもいかず（よほどの大規模プロジェクトでない限り『ハードウェアを買ってしまったほうが早い』ということになりかねません）、ある程度は自社内に、これらのノウハウや環境を構築していくことをお勧めしています。（その為のプロフェッショナルサービスは、時間を買うという意味でも、スペシャリティ＝ノウハウを買うという意味でも、非常に有効でしょう。）

そんなときに、無償で使えるApache JMeter（http://jakarta.apache.org/jmeter/）や、廉価の VERISIUM vPerformer（ベリシウムブイパフォーマ）であれば、その後の運用保守での活用を考えても、投資回収は、非常に早いと思われます。

Apache JMeterについては、サポートしてくれる人がいないなどの大変さもあるかもしれませんが、ITメディアさんの＠ITでの特集「JMeterによるWebサーバ性能評価の勘所」（http://www.atmarkit.co.jp/flinux/rensai/apache2_02/apache02a.html）などの多くの記事やサイトの情報を収集して利用することもできるかと思います。

日本語の情報に限定せずに、英語も大丈夫であれば、IBMさんの「Test WebSphere performance with Apache JMeter」（http://www.ibm.com/developerworks/opensource/library/os-jmeter/index.html）という事例なども、より多く見つけることができるかと思います。

昨日も記述しましたが、フリーのツール利用で、1．テスト実施までに時間が短くて、習得に時間が掛りそう、2．社内標準化が難しい（サポートが受けられないことを含む）、3．複数のツールで検証することで、確からしさを図りたい、4．対象のアプリケーションで、うまくテストができなかった、といった状況になると、商用ツールの選択・選定になります。

※次回、各種負荷テストツールに関する情報を掲載する予定です。

◆機能テスト自動化に関する過去ログ

2009/10/05 アプリケーションの機能テスト自動化が、なぜ進んでいないのか？

2009/10/06 アプリケーションの機能テスト自動化が、なぜ進んでいないのか？ Part 2

2009/10/07 アプリケーションの機能テスト自動化が、なぜ進んでいないのか？ Part 3

2009/10/13 アプリケーションの機能テスト自動化が、なぜ進んでいないのか？ Part 4

2009/10/19 アプリケーションの機能テスト自動化が、なぜ進んでいないのか？ Part 5

◆テスト関連全般の過去ログ

2009/06/27 本日（既に昨日）セミナーやりました　with CECさま

2009/09/01 ITmediaさん主催『ソフトウェアテスト・ミーティング 2009』（9月17日@秋葉原）にエントリーしました

2009/09/18 『ソフトウェアテスト・ミーティング 2009』（9月17日@秋葉原UDX by ITmediaさん）に行ってきました

2009/10/08 今日は、あいにくの台風でしたが『IBM Rational Software Conference 2009』（Rationalの日本最大のイベント）大盛況でした！