Webアプリの問題点を「見える化」する7つ道具：現場から学ぶWebアプリ開発のトラブルハック（1）（2/3 ページ）

本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部）

[佐藤聖規, 岡本隆史，NTTデータ]

その2：負荷生成ツール

　負荷生成ツールは、Webサーバなどに対して複数のユーザーからの同時アクセスによる負荷を疑似的に発生させるツールである。

■使いどころ

　パフォーマンスに問題がないかどうか確認したり、性能劣化などの現象が発生した場合、その現象を再現させるために利用する。Webシステムのトラブルやパフォーマンスの問題は、クライアントからのリクエストを大量に処理しているときに起こるものが多い。

　例えば、10秒以内にユーザーが50人程度ログインしたときにシステムが無応答になる現象が発生している場合、再現を行うために人手でブラウザを操作するのは非現実的である。負荷ツールを利用すれば、何十、何百人分の負荷を簡単に発生させられる。

■分析方法

　負荷生成ツールの基本的な使い方は、負荷量を徐々に上げていき、システムの挙動を確認することである。Java EEシステムでは、負荷量に応じて予想しないエラーが発生することが多い。

　負荷生成ツールはオープンソースのApache JMeter（以下、JMeter）を使うことが多い。

図3　JMeter実行例（クリックすると画像が拡大します）

　図3はJMeterで生成したリクエストのレスポンスタイムとスループットをグラフ表示する機能の画面である。黒の点がリクエストごとのレスポンスタイム、青がこれまでの平均レスポンスタイム、赤がレスポンスタイムの標準偏差、緑がシステムのスループットである。

編集部注：JMeterについて詳しく知りたい読者は、「O/Rマッピングの導入効果を測る」の中のJMeterに関する説明をご参照ください。

　また、負荷生成ツールは、無償のツールよりもHTTP以外の多くのプロトコルに対応し、負荷生成ツールからハードウェアリソースをモニタリングできるMercury LoadRunnerなどの有償製品を用いることも検討する。

その3：Excel

　「えっ！ 本当に？」と意外に思われる読者も多いかもしれないが、トラブルシューティングで「見える化」を行うのに、Excelは大変有効である。

■使いどころ

　sarコマンドのテキストログや負荷生成ツールで徐々に負荷量を上げていったときレスポンスタイム平均などを「見える化」するときに利用する。

　また、トラブル解決までの道のりは「Try and Error」である。現状を分析し、仮定を立てる。その仮定を証明するために、再現を行う。仮説が外れた場合、再度、再度原因に対する仮説を立て直す。こういった状況下で、Excelにアプリケーションの変更点やJavaヒープサイズなどのパラメータを記録しておくことで、最終的にどの仮定がトラブルを解決したか、一目瞭然となる。

■分析方法

　「見える化」することでさまざまなことが判明する。

図4　Excel使用例

　図4は筆者がExcelで作成するグラフである。X軸に同時ログイン数、Y1軸にスループット、Y2軸にレスポンスタイムをプロットし負荷量に対するスループットとレスポンスタイムの変化を「見える化」している。

　このグラフから1200同時ログインユーザーを超えた負荷が発生したあたりから急激にシステムのパフォーマンスが低下することが分かる。

その4：GCログ解析ツール

　基本データが取得できたところで、問題の「切り分け」に入る。図1のフローに沿って、切り分けを行うツールと手順を紹介する。

　JVMには、GC発生状況をテキストログとして出力する機能が備わっている。GCログを加工せずに分析を行うのは困難なためGCログ解析ツールを使って、「見える化」と統計分析を行う。

■使いどころ

　サーバ起動時間の経過とともに、システムがスローダウンした場合や、一定時間無応答になり、その後復帰する場合、GCが原因である可能性が高い。そのとき、JVM起動オプションに「-Xloggc:<file>」などのオプションを設定し、GCログを取得し分析を行う。

編集部注：JVM起動オプションについて詳しく知りたい読者は、Java Solution FAQの「javaコマンドを使いこなす」をご参照ください

■分析方法

　筆者は数あるGCログ解析ツールでもGCViewerを愛用している。GCViewerは多くのベンダのJVMや出力形式に対応し、さらにGC実行時間や回数などを統計分析し表示する。

図5　GCViewer（クリックすると画像が拡大します）

　図5はGCViewerの画面キャプチャである。左側のグラフで赤く表示されている部分が現在の最大ヒープサイズ、青い部分が使用中のヒープサイズ、緑の線がGCの停止時間である。右側のタブにGC発生状況を分析した結果が表示される。

　特に注目したいのが、赤く囲まれたThroughputの欄である。ThroughputはJVM実行時間中、GC停止時間を除いたJVM実行時間の割合である。

　GC発生状況がボトルネックとなっているかの判断は、一般的に以下である。

• Throughputが85％を下回る
• ヒープ使用量が経過時間とともに増加し続ける。Throughputが85％を下回る場合、ヒープサイズをチューニングする。一方、ヒープ使用量が経過時間とともに増加していく場合、オブジェクトがリークしている可能性が高い。その場合、ヒーププロファイリングを行い、リークしているオブジェクトを特定する

編集部注：GCログ取得方法とヒープサイズのチューニングに関しては、連載：事例に学ぶWebシステム開発のワンポイントの第6回「APサーバからの応答がなくなった、なぜ？ ―GCをチューニングしよう―」をご参照ください。

その5：スレッドダンプ解析ツール

　Javaのスレッドダンプとは、JVM上に生成されている全スレッドの状態とそのスタックトレースを出力することである。スレッドダンプもGCログと同じようにテキスト形式で出力されるため、そのままでは解析が難しい。そこで、GUIを提供する解析ツールを使い解析を行う。

■使いどころ

　GC発生状況に問題がないにもかかわらず、システムが無応答になる場合や、ハードウェアリソース使用状況に余裕があるにもかかわらず、パフォーマンスが悪い場合は、アプリケーションのマルチスレッド処理に問題がある場合が高い。そのような状況でスレッドダンプを取得することで、JVM中の実行スレッドがどのような状態になっているか把握できる。

■分析方法

　筆者はスレッドダンプ解析を行う際、Samuraiを利用している。

図6　Samuraiスレッドダンプ解析例

　図6はSamuraiでスレッドダンプを解析した画面である。左側にスレッドダンプで取得できた全スレッドが表示されている。右側は各スレッドの状態がどのように変化しているかを示しており、赤色がブロック状態、緑色が動作中、灰色がアイドル中、「<」（記号）は前回の状態と同じステータスであることを示している。なお、JVMが検出するデッドロックが発生している場合「ドクロ」マークが表示される。

　ここでチェックするポイントは以下の点である。

• デッドロックが発生していない
• 多くのスレッドが同じメソッドで停止している
• 多くのスレッドが同じオブジェクトを待っている
• 時系列で分析を行い、スレッドの状態が前回のスレッドダンプと同じ状況である

　上記のような現象が発生している場合、オブジェクトロック長の問題や、オブジェクトの開放漏れなどによりマルチスレッドの実行が効率的に行えていない。

　なお、スレッドダンプの取得方法については「侍ズム - Java - スレッドダンプの取り方」を参考にしてほしい。