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

» 2007年06月27日 00時00分公開

ソースコードを確認すると……

　業務アプリケーションを開発するうえでは、必ずDBアクセスの処理を記述することになる。Javaでこれらの処理は、JDBCを利用しSQL文を実行することになるが、その際には、業務ロジックからDBアクセス処理部分を分離し、DBアクセスに関する処理を隠ぺい化するDAOパターンが有効である。

　今回のWebアプリケーションのソースコードを確認してみると、iBATISフレームワークを利用し、DAOパターンにてDBアクセスの処理が記述されていた。しかし、該当の個所のソースコードは以下のような設計であった（図3）。

各テーブルに1：1に対応したDAOが作成されている。ここでは、ユーザーテーブル／会社テーブルに対応してUserDaoクラス、CompanyDaoクラスを定義している
まず、ユーザーテーブルよりユーザー情報をいったん取得し、その取得データを基に再度DBにアクセスし、会社テーブルより会社情報を取得している

図3　ソースコード修正前のDBアクセス設計

　このような設計では、検索されたユーザー数が増えるにつれてSQL文の実行回数が大きくなってしまうため、深刻なパフォーマンスの低下を招くことが予想できる。

DBアクセス部分の設計を見直す

　そこで今回は、関連があり同時にDBアクセスされるようなテーブルに対しては、表結合を利用してSQL文の実行回数を最小限に抑えることを目指した。そのため、ユーザーテーブルと会社テーブルをまとめて参照するSQL文に変更し、該当の個所を図4のような設計になるようにソースコードを修正した。

図4　ソースコード修正後のDBアクセス設計

　今回の修正では、表結合の利用によりSQL文の実行回数も1回に抑えることができるため、パフォーマンスが大きく改善されることが予想される。修正の効果を確認すべく、メソッドプロファイリングを再実施した。

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

　メソッドプロファイリングを再実施したところ、図5のような結果が測定された。パフォーマンスは大幅に改善され、またUserDaoのsearchUser()メソッドの呼び出し回数が1回に抑えられていることが確認できた。

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

　この結果を踏まえて、単体テスト時にパフォーマンスの問題として認識されなかったのは、試験実施時にテーブルに投入されていたデータ数が少なかったからと想定し、担当者に確認をしたところ、まさにそのとおりであった。今回の場合、UserDaoで検索されたユーザー情報の数が少なければ、SQLの実行回数は膨大にはならないからである。

　結局、そのプロジェクトで挙がっていたパフォーマンスに関する問題の多くは本件に起因するものであったため、それらに関してすべて見直しを実施し、修正する方向で、今回のトラブル対応は収束に向かうこととなった。

プロジェクト終盤での悲劇を防ぐために

　今回のようにDBアクセス回りのプログラム設計によるパフォーマンス・トラブルは、機能としては問題がないため、プロジェクトの終盤で発覚することが多く、アプリケーション改修作業がプロジェクトにとって大きな負担になりがちである。

　本稿はDBアクセスを題材にしているが、DBアクセスに限らず、XMLの解析処理や通信関連の処理など重い処理が絡む部分に関しては、処理の仕方によってはアプリケーションのパフォーマンスに大きな影響を与える。そのため、後工程での手戻りを防ぐためにも、設計・製造の段階から重要なレビュー観点として念頭に置いてみてはいかがだろうか。

プロフィール

NTTデータ
高橋和也（たかはしかずや）

Web系システムでのJavaフレームワーク開発、業務アプリケーション開発と開発プロセスの策定、トラブルシューティングなどを経て、現在は、開発生産性を向上させるツール開発に従事するかたわらプロジェクトに対する主に設計・製造・試験に関する技術支援を担当している。

開発の理想論と現実論のバランスが取れた実現性のある開発ができればと思い、日々業務に従事している。

「次回」へ

「現場から学ぶWebアプリ開発のトラブルハック」バックナンバー