DBアクセスのトラブルは終盤で発覚しがち……：現場から学ぶWebアプリ開発のトラブルハック（4）（1/2 ページ）

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

[高橋和也，NTTデータ]

今回の概要

本稿では、Webアプリケーションの開発プロジェクトで実際に直面したDBアクセス処理に関するよくあるトラブル事例を題材に、DBアクセス処理に関するTipsを紹介する。

今日は、内線で助けを求められる

　ある穏やかな朝、突然電話が鳴る。今日の相手はパフォーマンステストを実施している社内のプロジェクトのマネージャである。「パフォーマンステストを実施しているが、いくつかの業務処理で、レスポンスが悪過ぎて困っている。リリースも近いので、早急になんとか原因を探ってほしい」

　とはいえ、さすがにこれだけの情報では、問題は解決できないため、直接現場に急行することとなった。

現場に到着し、トラブルの詳細を確認

　現場に到着し、まずは現状分析のため、担当者に簡単にヒアリングを行った。ヒアリングした結果をまとめると、以下のような状況のようだ。

• Javaで開発しているWebシステムで、Web層にはStruts、永続層にはiBATISといったフレームワークを利用している
• いくつかの業務処理は遅いが、それ以外の業務では快適に動作している
• 問題となっている業務処理は単体テスト時には、快適に動作していた
• 問題となっている業務処理は、パフォーマンステストでは1ユーザーでのリクエスト処理でも時間がかかっている

トラブルを切り分ける

　大体大まかな話が聞けたので、Webアプリの問題点を「見える化」する7つ道具を利用し、トラブル切り分けフローに従い、調査を開始した。

図1　トラブル切り分けフロー（連載第1回のものを再掲）

　フローに従い、基本データ分析・GCログ解析・スレッドダンプ解析を確認してみたが、特に問題がなかったため、メソッドプロファイリングを実施することとなった。今回のトラブルでは、1ユーザーからの業務処理でもパフォーマンスにも問題がありそうなので、1リクエスト投げたときのメソッドプロファイリングをまず実施してみることにした。

　測定対象は、実際に問題となっている業務処理の中から、業務上よく利用される、ユーザーを検索し結果を一覧表示する業務処理を選んだ。

メソッドプロファイリングの実施

　メソッドプロファイリングした結果、図2のような結果が測定された（※データは本稿のために作り直しています）。

図2　パフォーマンス改善前のメソッドプロファイリング結果（抜粋）（画像をクリックすると拡大します）

　メソッドプロファイリングした結果を確認してみると、CompanyDaoというDBアクセスクラスのsearchCompany()メソッドが処理時間の大半を占めていた。このメソッドでの処理時間の内訳を見ると、iBATISのAPIにてほとんどの処理時間を占めているため、一見するとフレームワークが悪いようにみえる。

　しかし、呼び出し回数がUserDaoというDBアクセスクラスと比較すると、UserDaoのsearchUser()メソッドは1回に対して、CompanyDaoのsearchCompany()メソッドは大量に呼び出されている。今回のメソッドプロファイリングでは、1回のリクエストに対して実施したため、業務処理の内容から考えて何度もDBを呼び出しているのは不可解である。

　そこで、SQL文の実行の仕方に問題があるとにらみ、実際に該当部分のソースコードを確認してみることにした。