AWSでのクラウド負荷試験　その２

前回の記事では、AWS上から行う負荷試験について説明いたしました。

今回は、実際にAWS上にいくつか環境を用意して、実際に負荷試験を行い結果をまとめてみたいと思います。

試験内容として、Webサーバ上で動作するWordpressに対してミドルウェアの組み合わせと設定の組み合わせで、どのように変化していくか確認しようと思います。

【試験環境概要図】

jmeter_cloud04

負荷実行環境に関しては、オリジナルAMIを利用して実行します。

負荷試験対象のサーバは、すべて以下の環境で構築しました。

Test Server 3
Wordpress 3.5-ja
nginx 1.3.9　+　FastCGI　+　MySQL 5.5.28
※リバースプロキシを利用

尚、今回の負荷試験はAWSのインスタンスからAWSのインスタンスに対して実施しています。

通常の負荷試験であればAWSへの申請は必要ありません。

ただし、t1.micro や m1.small などの小さいインスタンスタイプに対しての負荷試験はＮＧとなります。

また、脆弱性試験に近い項目（DDoS などと誤解される程のアクセスや、脆弱性を利用したアクセスなど）が含まれる場合には、以下のフォームから試験の申請を行う必要があります。

試験の目的として、Apache　+　PHP　と　nginx　+　FastCGIでのレスポンスの違いとWordpressの高速化に非常に効果的と言われているnginxでのリバースプロキシを利用した際のレスポンスの違いを検証するために負荷テスト行い確認します。

また、今回はApache、nginx、MySQLに特別なチューニングはせずデフォルトの状態で負荷試験を行うものとします。

JMeterを起動し、『テスト計画』に『スレッドグループ』を追加し、本来はテスト対象のサーバに対する同時アクセス数や想定スループットなどを基に計画を立てていきますが、今回はスループットの上限値がどの程度異なるかを確認したいので、以下の計画を立てました。

HTTP リクエスト
リクエストページ　:　Wordpressのデフォルト記事ページ
オプションタスク　:　すべてのイメージとアプレットを繰り返しダウンロードする(HTMLファイルのみ)
この設定を入れるとHTMLに記述されている画像ファイルやJS、CSSファイルも取得する。

Test Server 1
AWSのMediumでチューニングしない思ったよりも数値が伸びないようです。
とはいえWordpressのデフォルトの状態では、すべて動的にページ生成処理がされることから妥当といえば妥当な値です。

Test Server 2
nginx　+　FastCGIの組み合わせは、期待していたのですが明らかにPHPの処理がボトルネックになってApache　+　phpの組み合わせと大差のない結果となりました。

Test Server 3
3サーバともすべて同一のスペックでありながらTest Server3だけが桁違いのリクエストをさばいています。
リバースプロキシを利用することで動的ページをキャッシュし静的ページとして戻しているので当たり前といえば当たり前ではありますがWordpressのように動的に生成するがコンテンツ内容自体は静的コンテンツであれば非常に高速化に有効になるようです。また、この状態でTOPコマンドにてCPUの利用率を確認していましたが5%も使っていませんでした。
そこでJMeterのスレーブを5台から10台に変えてみましたがCPUの使用率に関しては20%程度しか行かない状態でした。