Page ｜ 1 ｜ 2 ｜ 3 ｜ 4 ｜ 5 ｜ 6 ｜
実例で学ぶWebシステムのチューニング手法
|
実践編
では、理論編で「チューニングの進め方」を学んだところで、実践編では文字通りそれらを「実践」してみることにしよう。ここではサンプルアプリケーションを実際にチューニングしてみる。チューニングを行っていく中で、システムのチューニングサイクルにおける具体的なポイントについて触れていきたい。
題材として、簡単な掲示板アプリケーションを取り上げる。このサンプルの稼動に必要なアプリケーション等は本誌付属のCDに収録されている。
サンプルアプリケーション説明
・システム構成
今回チューニングを行ったシステムの構成を図11に示す。
アプリケーションサーバにはBEAシステムズのWebLogic Server6.1、データベースには、WebLogic Serverに付属のcloudscapeデータベースの評価版を使用した。
図11からわかるように、チューニング対象のシステムは、シンプルで典型的なＷＥＢシステムの構成である。負荷テストツールであるApache JMeterからHTTPリクエストをWEBサーバ兼アプリケーションサーバであるWebLogic Serverに送り、JDBCを介して、Cloudscapeデータベースを参照/更新し、レスポンスをクライアントに返す。
一般的な大規模サイトでは、クライアントとアプリケーションサーバ間にApacheなどのWEBサーバを設置する3層構成をとる場合が多い。負荷を分散させるとともに、静的コンテンツ等をWEBサーバに配置することにより、パフォーマンスの向上をはかるのである。今回は、WEBサーバ機能をWebLogic Serverサーバに兼任させたシンプルな構成をとる。
クライアントと、サーバは必ず別マシンにする構成をとることが重要である。JMeterが使用するリソースがサーバの性能を低下させることにより、アプリケーションの性能特性を正確に把握できなくなる為だ。
見落としがちであるが、負荷クライアントが使用するリソースは意外と大きいのだ。負荷テスト中は、サーバ側だけでなく、クライアント側のリソースの使用状況をチェックするのを忘れてはいけない。
・アプリケーションの仕組み
サンプルアプリケーションは、WEB上のどこにでもあるような簡易掲示板である。1点通常の掲示板とは異なるのは、アップデート用のボタンが複数あるという点である。これらのボタンは、それぞれ返ってくる結果は同じであっても途中の処理が異なるのだ。それぞれにおける処理の詳細は後述する。
クラス図とシステム構成を組み合わせたアプリケーションの構成図を図12に示す。
典型的なMVCモデルを取ったWEBアプリケーションである。処理フローは以下の通りだ。
ブラウザからのオペレーションを受けた掲示板のJSPはリクエストをコントローラにあたるサーブレットであるHttpHandlerServletに渡す。
HttpHandlerServletでは、JSPで選択された処理に対応するロジックを呼び出す。それぞれのロジックは、AbstractCommandという抽象クラスを継承している。このクラスには各処理に共通する処理が記述されたテンプレートメソッドを持つ。それぞれのロジックに特化した処理のみがAbstractCommandのサブクラスに記述されている。
掲示板JSPから受け取った、リクエスト（掲示板に投稿された書き込み）はバリューオブジェクトであるBbsを介してデータベースに格納される。参照/更新ともに、実際のデータベースアクセスはEntityMgrが行うことになる。
クライアントへのレスポンスは、再びBbsオブジェクトを返して、掲示板Jspへと返され一連の処理は終了する。
AbstractCommandを継承した3つのサブクラスコマンド間における、処理の違いについて説明する。3つのコマンドは、顕著なパフォーマンスネックが引き起こされるようなロジックが故意に組み込まれている。3つのコマンドはそれぞれ以下の特徴がある。
・AllViewCommand
30件のデータを1回のSQL問い合わせで一括して取得する。
・OnceGetViewCommand
30件のデータを30回のSQL問い合わせで一件ずつそれぞれ取得するが、データベースコネクションの取得は一度だけでそのコネクションを一連の処理の中で使いまわす。
・EachGetViewCommand
30件のデータを30回のSQL問い合わせで、一軒ずつそれぞれ取得し、かつデータベースコネクションもそのつど取得する。
それぞれのコマンドには、掲示板への過去の投稿を取得する参照系の処理の他に、共通の処理として記事を投稿する更新系の処理が組み込まれている。
次章以降で、この単純な掲示板アプリケーションに負荷をかけ、解析を行いWebシステムのチューニングを行っていくことにする。
実際のサンプルアプリケーションの構築方法はコラムを参照していただきたい。
テストツール
今回、サンプルアプリケーションシステムのチューニングを行うために以下のツールやコマンドを用いる。
・負荷テストツール ：Apache JMeter 1.6.0
・アプリケーションプロファイラ：Sitraka JProve Profiler
・Lan Analyzer
・netstatコマンド
・JVMのThread dump
Apache Jmeter
JMeterはJakartaプロジェクトにより提供される負荷テスト用のフリーのツールである。WEBシステムに負荷をかけるための各種設定が可能であるが、LoadRunnerなどの商用の負荷ツールと比較すると、各設定はシンプルであるといえる。しかし、オープンソースの100% pure Javaアプリケーションであるため、必要に応じてカスタマイズをすることが可能である。今回の記事の中では、JMeterの基本機能のみを使ってアプリケーションに負荷をかける。
今回は、現時点でのJMeterの最新版である1.6.0というバージョンを使用した。前バージョン(1.5.0)と比較すると、アーキテクチャが大幅に変更されユーザビリティが大幅に向上している。オペレーション中における設定時と実行時の境界がなくなった。これにより、1つの実行画面で設定とテストの両方の操作が行える。また、それに伴って複数のテスト間における設定の共有などが可能となった。
基本的に設定するのは以下の4点である。
(1)Thread Group
(2)Timer
(3)Controller
(4)Listener
図13がJMeterの基本操作画面である。
(1)Thread Group
Thread Groupには、並行に実行されるスレッド数を定義する。１つのスレッドは1つのブラウザなどのクライアントをエミュレートしたものと考えてよい。
1個のスレッドを100回シーケンシャルに実行することと、100個のスレッドを並行に動かすことは全く意味合いが異なることに注意しなければならない。1つのスレッドを1秒間に100回処理することが出来ても、100個のスレッドを1秒間にそれぞれ1回ずつ処理できるとは限らないのである。
(2)Timer
Timerの設定画面では、テストクライアントとなるThread Groupに、テストを実行する際のアクセスのインターバルを設定する。インターバル間隔の設定は3種類のタイマーの中から選択する。
・Constant Timer
設定された一定の間隔でスレッドを実行する
・Uniform Random Timer
一定時間内にランダムな間隔で設定されたスレッドを実行する
・Gaussian Random Timer
ガウス分布に基づいた分散した間隔で一定時間内に設定されたスレッドを実行する
設定されたインターバル内でスレッドにレスポンスが帰ってこない場合には、次の処理は実行されないということに注意が必要である。実際に並行に動くスレッドの個数はあくまでも、Thread Groupで設定した個数であるため、レスポンスタイムより短く、Delayを設定するのは無意味である。
(3)Controller
実際にシステムにリクエストを送る対象・プロトコル・パラメータを設定する。WEBアプリケーションの負荷テストには、「Web Testing」を選択する。実際には、プロトコル（HTTP,HTTPS）、リクエストパス、ポート、メソッド（GET or POST）、リクエストパラメータなどを設定することになる。
今回のサンプルアプリケーションでは、HTTP上でGETメソッドにいくつかのリクエストパラメータを乗せてリクエストを送るだけの単純なコンフィグレーションでテストを行えるが、JMeterの機能としては、HTTPS・ベーシック認証・Cookieのコントロールをテストに組み込むことも可能である。また、本稿では割愛するが、対象Web Testingのほかに、JDBCやFTPの負荷テストの為のコンフィグレーションも選択可能である。
(4)Listener
実行したテストの結果の出力を設定する。実行されたスレッドのレスポンスをグラフ化したり、返ってくるレスポンスの内容をテキストに打ち出したりすることが出来る。
負荷テストの結果は、ファイルへ結果を出力するFile Reporterや、グラフで視覚的に結果を表示するGraph Resultsを利用して取得するのが有効な場合が多いと思われるが、必要に応じて使い分ければよいであろう。
JMeterでは、コンフィグレーションを、Controller、Timerなどの個別の設定、あるいはThread Group全体の設定をファイルに保存しておくことが出来る。本サンプルで使用したコンフィグレーションファイルは、サンプルアプリケーションとともに収録しておく。
プロファイラ（JProbe Profiler）
JProve ProfilerはSitraka software のアプリケーションプロファイルツールである。アプリケーション実行中のある特定期間のサンプリングを行い、スナップショットを取得し、アプリケーションの内部での実行状態を解析する。
アプリケーション中におけるメモリリークやボトルネックの解析を行うことが出来る。解析したプロファイル情報をグラフィカルなインターフェイスで分析が可能だ。メソッド単位の呼び出し回数・処理時間の統計情報の取得が可能で、ソースコードとのマッピングも可能な強力なツールである。
LANアナライザ
ネットワークのトラフィックの計測にLANアナライザを使用する。代表的なものに、Snifferなどが挙げられる。しかし、ネットワークネックが生じるほどにスループットが出ている場合には、アプリケーションとしてはほとんど問題ない場合が多い。多くの場合は、ネットワークネックに到達する前に、CPUやメモリ、あるいはディスクI/Oネックとなる。
今回は、LANアナライザはネットワークがボトルネックになっていないことを確認するためだけに使用した。しかし、LANアナライザは、CPUもメモリも使用率が上がらないのにスループットが出ないなど、予期せぬ状況が発生した場合に全体のネットワークを再チェックする際などに重宝、システムする場合が多い。実際、ロードバランサーなどのネットワーク機器自体がボトルネックになっている場合も多いのである。
netstatコマンド
netstatはソケットの状態を標準出力に表示するという基本的なOSコマンドである。基本的なコマンドではあるが、Listenしているポートがきちんとコネクションを確立し、Establishの状態になっているかを確認することはシステムの状態をチェックする上で重要なポイントである。
例えば過負荷状態で、ポートがListen状態であるのに、コネクションが確立しない場合などには、OSレベルでのリソース（例えば、Accept_backlogなど）が不足している可能性があるなどの判断材料にもなりうる。また、Establish状態のコネクションの数からサーバに対する負荷のかかり具合を推測することが可能である。
スレッドダンプ
JVMのスレッドダンプは、各スレッドのスタックトレースを表示するものである。この情報からアプリケーションの状態について重要な情報を得られることが多い。
VMのスレッドダンプを出力する方法はOSにより異なる。また、アプリケーションサーバ固有のスレッドダンプ出力処理機能を持つものもある。
(WebLogic Serverにもアプリケーションサーバ固有のスレッドダンプ機能があるが、まだきちんと機能しないようだ)。
JVMのスレッドダンプは以下示すコマンドを、アプリケーション実行中に実行することにより簡単に取得することが出来るので試していただきたい。スレッドダンプ取得方法の代表的なものを示す。
・Windows NT
コンソールで [control]+[break] を押す
・UNIX
kill -3(QUIT) をJVMに送る
実際にはOSのディストリビューションなどにより異なることもあるので注意が必要である。
アプリケーションサーバのコンフィグレーションチューニングやOSレベルでのチューニングを一通り行っても、パフォーマンスがあがらない場合などでは、ロジックに問題がある場合が多い。不必要なsynchronized処理、デッドロックになる処理が組み込まれている場合などがそれに当たる。こういった問題は、前項に紹介したJProveなどのデバッグツールによっても原因の究明を行うことは可能であるが、まず、JVMのスタックとレースを取得することにより、原因の究明・問題の解決が出来ることも多い。JVMのスレッドダンプを出力し、処理が止まっている個所を特定するのである。
CPU・メモリの使用率に関して
CPUとメモリの使用率はWindowsのパフォーマンスメータを用いて確認した。本来、メモリ・CPUの使用率は不可テストの際に正確に記録しておくべきものである。しかし、今回はCPUに関しては、おおよそのCPU使用率を把握し、CPUの使用率が100％に達していないかどうかを監視する程度の計測に、メモリに関しては、メモリの使用率とともに、ページングが頻繁に起こることがないかをチェックする程度に簡略化した。