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

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

» 2007年03月22日 00時00分公開

今回の概要
システムが応答しない、パフォーマンスが劣化したなどのトラブルが発生したときに、原因がなかなか掴めず、あたふたすることはないだろうか？本稿では、Java EEトラブルシューティングの現場で役立つ7つ道具を紹介する

ある日、突然電話が鳴る

　用件は、「システムが不定期に停止する。よく分からないけど、どうやらJava EE部分がおかしい」とのこと。このような事態が発生したとき、やみくもに原因を調べ、いつまでたっても問題が解決できず、原因の一片も発見できないことが多々ある。

　トラブルが発生した場合、ツールが充実していない昔は、開発者の経験と勘に頼るところが非常に大きかった。Webシステムが普及するいま、昔とは比べ物にならないほど、システムの数が増え、開発者数が増える一方、システム障害を切り分けられる職人的なエンジニアの人数はシステム数に比例して増えているわけではない。そのため、すべてのシステムに問題の切り分けができる開発者を期待するのは難しくなってきている。

　しかし、現在提供されているさまざまなツールを駆使すれば職人でなくても、それなりにシステム障害を解析できるようになってきている。

　筆者は、弊社の中でもJava EEのトラブルを解決する業務を扱っているが、本稿では筆者が日常利用しているトラブルシューティングの7つ道具と、それらのツールによるパフォーマンスの問題の切り分け方法を紹介する。

　筆者自身がこれらのツールを利用しているのは当然として、支援先でこれらのツールを利用して障害の切り分けができる技術者の育成も同時に行っており、それなりの効果を得ている。パフォーマンスの問題に直面した読者がいれば、ぜひ本稿に目を通していただきたい。

どんな順番で問題点を切り分けるべきか？

　トラブル発生時、迅速に問題を解決するために重要となるのは問題の「見える化」と「切り分け」である。発生している現象に応じて、ツールの特性を意識しうまく使い分けることが重要である。筆者は順序に従い、トラブルシューティング7つ道具を使い問題を切り分けていく。

　筆者がトラブルを切り分けるときの作業と流れを以下の表に示す。

図1　トラブル切り分けフロー

　トラブル切り分けフロー中の手順と本記事で紹介する7つ道具の対応を以下の表に示す。

**表1 トラブル切り分けフローの手順と7つ道具の対応**
	手順	ツール
	0：基本データ分析	HW（ハードウェア）リソースモニタリングツール
	0：基本データ分析	負荷生成ツール
	全体	Microsoft Office Excel
	1：GCログ解析	GC（Garbage Collection）ログ解析ツール
	2：スレッドダンプ解析	スレッドダンプ解析ツール
	3：メソッド／オブジェクトプロファイリング	プロファイラ
	4：プールオブジェクト解析	JMX（Java Management eXtensions）クライアント

　まず、基本となるのは負荷生成ツールとHWリソースモニタリングツールである。負荷生成ツールでシステムへ負荷を掛けながらHWリソースモニタリングツールで、リソース使用状況を調べる。また、取得したデータをExcelによってグラフ化する。その後、各種ツールを利用しながら、問題を切り分けていく。

　図1は、これから紹介するツールを利用してボトルネックを切り分けるフローであるが、7つ道具を紹介した後で、あらためてボトルネックの切り分けフローを紹介する。

　最初に基本的なデータ測定を行うための、負荷生成ツール、HWリソースモニタリングツール、Microsoft Office Excel（以下、Excel）について解説する。

その1：HWリソースモニタリングツール

　HWリソースモニタリングツールとは、CPU使用率やスワップ発生状況などのハードウェアのリソース使用状況をモニタリングするツールである。

　UNIX系OSであればtopやsarといったコマンド、Windowsであればタスクマネージャやパフォーマンスカウンタがこれに該当する。

図2　パフォーマンスカウンタの実行例（クリックすると画像が拡大します）

■使いどころ

　性能劣化やシステムの無応答の問題が発生した場合に、最初に確認するべきなのは、HWリソース使用状況である。トラブルシューティングの基本中の基本であるとともに、オーバーヘッド（システムに与える影響）が小さいため、常時使用する。

■分析方法

　どのサーバがボトルネックとなっているかを把握することが問題解決への第一歩となる。例えば、APサーバにボトルネックがあれば、APサーバの設定や、アプリケーション自身を見直したり、データベースにボトルネックがあれば、SQLの発行状況をトレースしたりする。JavaEEシステムにおいてボトルネックが発生する可能性が高いのは以下の3つである。