サイジングとチューニングの必要性
アプリケーションチューニングの糸口
システムやアプリケーションのパフォーマンスが出ない場合には、遅延の原因＝ボトルネックを探るために調査とチューニングを行います。一口にパフォーマンスが悪いと言っても、パフォーマンス問題が発生する箇所はいくつか存在します。実際にチューニングを行う際には、事前に以下の作業を繰り返し行うことになるでしょう。
- 問題となっている現象を正確にキャッチアップ
- 問題を再現できるかを検証する
- 問題となっている箇所を特定する
- 設定や実装で改善できるかを検討する
また、その問題が発生するフェーズとしては、大きく以下の３つに分けられます。
- プロトタイプ構築中
- 結合テスト中
- 本番リリース後
アプリケーションのチューニングはこれらの構築フェーズごとに必ず存在します。小中規模のアプリケーションでは省略されてしまうケースもあるのですが、実際には必要な作業になります。
| 項目 | 概要 |
|---|---|
| プロトタイプ構築中 | フレームワークやライブラリ利用時の制限や問題点を洗い出す。アプリケーション内で特に負荷のかかる機能や画面、技術的に難しい機能を洗い出して問題点を絞り込み、改修を行う。 |
| 結合テスト中 | プロトタイプ構築時に出なかった問題点が出るので、アプリケーション設定やサーバーの設定の見直しを行う。プロトタイプ構築時に見えてこなかったアーキテクチャの問題見直しもここで行える。 |
| 本番リリース後 | システム全体でまれに遅延する、特定の機能のみ遅延する、止まっている（ように見える）など、問題の再現性や発生理由があいまいになりやすいため、問題を特定しにくい。まずは大まかに問題点を特定するためシステムの監視を行い、対応策を絞る。 |
| 表2：アプリケーションの構築フェーズとチューニング | |
特に結合テストや本番リリース後に出てくるパフォーマンスの問題は、単にアプリケーションの実装の問題で遅延することもありますが、その原因がアーキテクチャの問題であったり、システム構成的な問題の場合もあります。アプリケーションのパフォーマンス問題を検出する方法としては、一番簡単なところではアプリケーションのアクセスログ監視やJMeterなどを利用した負荷テストをかける方法があります。
一番簡単な方法としては、アプリケーションの遅延を検出するために監視用のログをコードに挿し込むことになりますが、主に以下の箇所に差し込んで、アプリケーションの稼働状況を監視して、まずはアプリケーションの問題点はどこにあるのかを絞り込みます。
- アプリケーション単体の開始地点と終了地点
- データベースの呼び出しから終了までの地点
- ファイルI/Oを伴う処理の開始点と終了点
- 外部システムとのI/Oを伴う処理の開始点と終了点
- タグライブラリ、JSTL＊1やテンプレートエンジン＊2の出力ログ
|
|
| 図4：アプリケーションのボトルネックとなる箇所（クリックで拡大） |
- [*1]JSTL：JSPの汎用タグ拡張機能をまとめたライブラリ。JSPの実行速度を上げるものではなく、実装のコストや実装コード量を軽減するために利用され、JSPの可読性を向上させる。
- [*2]テンプレートエンジン：JSPの代替として動的HTMLレスポンスを出力するライブラリの総称。現存するものとしてVelocityやFreeMarkerがあり、一般にJSPやJSTLよりも軽量であったり、高速に動作するのが特徴。一長一短あり。
他にもJavaアプリケーション内で遅延する原因として挙げられるものは
- ガベージコレクションの発生
- レスポンス生成時のリソース取得が多いため、ブラウザのレンダリングが遅れる
などがあります。
ガベージコレクションと呼ばれる、Javaのメモリ管理によるメモリ解放時の遅延ですが、これに関しては今後の記事の中でご紹介します。
ログ調査などでアプリケーションのパフォーマンス問題を特定することができたならば、後はアプリケーションの修正で対応できるのか、設定で対応するところなのかを判断し、順次対応方法を検討した上で、管理台帳を作成しておくと、今後問題が発生した場合や、システム運用時での軽微な問題があった場合に、システム保守や拡張に役立てることができるでしょう。
次回はアプリケーション改修のタイミングで発生したメモリリークについて解説していきます。
