IVP Internet Value Provider IVP Co. Ltd.IVP Internet Value Provider IVP Co. Ltd.

  • タイトル

パフォーマンス診断 (自社製品ERS_V6.5) 第1回 ECサイトの負荷試験の診断結果と診断方法

 | 

IVPでは、自社で制作したWEBサイトがどの程度のアクセスに応えられるかを把握する為に負荷試験を行っています。
今回はIVPの主力製品であるERS V6.5 ECサイト の負荷試験の診断結果と診断方法をご紹介したいと思います。

負荷試験を行う理由

アクセス数が多いサイトでは、一番多い時間帯やピーク時のアクセスに対応する必要があります。
本番環境でどのくらいのアクセスに耐えれるかを予測しておくこと。
どうすればアクセス数に耐えれるようになるか手段を講じることが非常に難しいので、予め負荷試験をすることによりどの位のアクセス数に耐えれるサイトであるかを予測しておき、更にボトルネックになる箇所を想定して、ボトルネックを解決するための対策を考えておきます。

別の記事で実例を上げる予定のアクセス解析の回でも言及したいのですが一言で一日あたりのPVなどがわかっていてもピーク時のアクセス数の予測が困難である点と予算などの都合でいくらでもリソースが追加できないというのが現実なのでボトルネックを予め確認しておき、想定以上のアクセス数やDBのサイズ、コンテンツの量があった場合に適切にリソースを追加出来るようにしておくためにも負荷試験を実施します。

なお、負荷試験の頻度はERSのバージョンアップ やOSのバージョンアップハードウェアの構成が大きくかわったり、高負荷が予測されるサイトなどで別途対策をしておきたい場合などに実施するのが理想だと思っています。

これは、ボトルネックになる箇所が載っているアプリケーションやOSが変わったり
DBのサイズやコンテンツのサイズ、ハードウェアの構成で変わってしまうからです。

アクセス数の多いサイトの場合SQLが少し複雑であると後でわかったり、OSやアプリケーションのバージョン全文検索ソフトの重さCPU、メモリ、HDDなどかなり多い要素があるので、
想像していた箇所がボトルネックになると予測しきれません。
頭で考えても、結果と乖離してしまうため、負荷をかけるアプリケーションで実際に消費されているリソースもツールなどで把握していくという手段を取っています。

まとめ

予測が難しいので実際に負荷試験して耐えれるアクセス数とボトルネックを予測しておく。
想定よりアクセス数があるなど問題が発生したら適切に対応出来るようにしておく

負荷試験の前提条件

今回はERSバージョンアップに伴う負荷試験なので、ERSの開発環境で負荷試験を実施します。
なお開発環境でのテストとなるためコンテンツのサイズは、DBのサイズ 9.7G
開発環境のほぼデフォルトでのテストを実施します。

負荷試験の対象となるサーバスペックは下記のとおりです。
ハイスペック型:CPU:Xeon 3.5GHz メモリ:DDR3-1333 16GB HDD 500G*2 (Raid1 でミラーリング)
OS : DBサーバ CentOS5.8, WEBサーバ Windwos2008R2 SP1

 

・DBサーバについて補足
DBサーバは弊社で運用実績のあるCentOS5とPostgres9を使用することにしました。
Postgresの設定は過去の実績に基づき、パフォーマンスが発揮できるよう予めチューニングを施しておきます。
試験時のバージョン:CentOS5.8 PostgreSQL9.0.13

下記のように簡単にチューニングしました。
max_connection 512
shared_buffer 4GB
effective_cache_size 1GB
またオートバキュームが有効だと数値が変動するためオフにします。

 

・WEBサーバについて補足
ERSはWindows環境で動作する為、弊社で運用実績のあるOS:Windows2008R2 SP1とIIS7.5を使用します。

 

・ネットワークについて補足
WEBサーバーのWAN側ネットワークのリンク速度は実際の環境に近づける為にサービス提供速度である100Mbps/全二重
WEB、DBのプライベート側も一般的に使われている1Gbpsに設定することにしました。
試験で使用するスイッチについては転送処理に十分な余裕のある24ポート/スループット48Gbpsのものを使用しました。

負荷試験の有効性の有無

なるべく負荷試験と本番環境に乖離が無いようにするために下記のような手段を取ります。

・ページ毎の処理による違いによる試験と実サイトの乖離を防ぐ手段
例えば、アクセス数の分だけトップページだけが耐えれるというような想定をしてしまうと、検索ページなど、特にDBが一方的に負荷がかかりやすいページにアクセスが集中してしまうと結果が乖離してしまいたとえ、ユーザーがトップページを閲覧できても検索ができず、負荷に耐え切れないサイトになってしまいます。
そのような結果にならないよう3つのケースに分けて負荷試験を実施します。

 

1.トップページ 2.商品検索 3.購入処理
こう分けたのはそれぞれのページが下記のような特徴があるためです。
トップページは画像数が多いため、基本的にディスクアクセスやグローバルのネットワーク
に負担がかかりやすいと想定される。
商品検索はSELECT文が頻繁に走り、DBに負担がかかりやすいと想定される。
購入処理は INSERT文が頻繁に走り、DBに負担がかかり、商品検索とは別の処理が走るので商品検索とは負荷のかかり方が違うと想定される。

上記のように違う処理が走るページを分けて負荷試験と本番環境の乖離が発生しないようにします。
乖離を抑えられないような極端に検索DBが大きいサイト、商品購入方法が複雑なサイト、トップページで画像数が多かったり大きいサイトでは
今回の結果は適用できないとも判断できます。

 

・ツールを利用することによる負荷試験と本番環境の乖離を防ぐ手段
負荷試験に使用している Jmeter には負荷試験の結果を出す機能がありますが
負荷試験側だけでは本当にアクセスがきちんと出来たと言い切れません。
ですので Jmeterのアサーションという結果の文言を確認する機能があるのでそちらも追加で確認するようにします。
画像も下記のような設定を施してJmeter が毎回ダウンロードするように設定をします。
また、IISのログでシステム部分と画像が正常に200番を返していることも確認して試験と結果の乖離を防ぎます。
ただ、試験環境にない、twitter などの外部サイトがある場合は結果が乖離すると想定できます。

○ Jmeter に画像をダウンロードさせる
HTTPリクエストで、 全てのイメージとアプレットを繰り返しダウンロードするにチェック

○ Jmeter に文言が取れているか確認させる
アサーションを追加。必ず出てくる文言をテストパターンとして登録する。