「システムが遅い！」その時どう取り組むか：J2EEパフォーマンスチューニング（1）（2/2 ページ）
「アプリケーション・サーバを使いJ2EEべースのWebアプリケーションを構築できたのはいいが、どうも本来のパフォーマンスが出ていない」とは、よく聞く話である。本連載では、そういった事態に遭遇した場合に、具体的にどのように対処してパフォーマンスを向上させるかについて解説していく。第１回は、「パフォーマンスが出ない！」という場面で、具体的な対処の前に、どのような事前準備と活動を行うべきかを解説する。（編集局）
（2）改善への取組み
改善計画を立案する―綿密な計画を行い解決までの道筋を立てる―
ここから、いよいよ実際の改善活動に入っていくことになる。最初の心構えの「綿密な計画なしに着手しないこと」を思い出していただきたい。ここで立てる計画の良しあしが、性能改善の目標と期限を達成できるかを左右するといっても過言ではない。従って、計画は綿密に立案し十分なレビューを行う必要がある。
●計画のフロー
以下に、一般的な計画のフローの大項目を示す。実際には個々の事例ごとにバリエーションは存在するし、計画の詳細についてはそれぞれ皆違ってくる。しかしながら、大まかな流れとしては、以下のフローで進めていただいてよいと思う。
(1)推定原因の検討
(2)測定
(3)解析
(4)改善施策立案
(5)改善施策の実施
(6)効果測定
(7)判定
※判定で目標値に到達していない場合はフローを繰り返す
●推定原因の検討の必要性
有効な具体的改善施策を立案するためには、裏付けとなるデータが必要になる。現状の改善すべき対象の実データ(検索レスポンスタイムなど)を実際に取得し、リファレンスとする。それとともに、ボトルネックとなるリソースのデータも併せて取得しておく必要がある。
ただし、このデータを取得するための、測定、解析の作業は体力仕事のため、計画全体の工数に占める割合が大きくなるケースが多い。従って、やみくもにデータの測定、解析を行うのでなく、推定原因をきちんと検討して、可能性が高そうな原因にある程度絞り込んでから、その原因に関連があるデータの取得を行うべきである。
●推定原因の検討の際の注意点
この推定原因を検討する際には、思い込みなどをなるべく排除して検討しないと、的を外した推定定原因を真の原因である可能性が高いと判断する可能性が高くなり、あらぬ方向の作業をしてしまって、工数と時間を無駄にすることになってしまう。
最初の心構えの、「先入観念を持たないこと」「あらゆる可能性を考えてみること」を念頭に置いて、ゼロベース思考で検討することが重要である。
●推定原因の検討の際に考慮すべきポイントとなる主要項目
突き詰めていうと、パフォーマンスチューニングとはボトルネックの発見とそれの解消による最適化であるといってよい。
推定原因として、ボトルネックになり得る可能性がある主要項目を、一通り列挙しておくので、参考にしていただきたい。
| リソース | CPU メモリ（スワップ） ディスク ネットワーク |
|---|---|
| OS資源 （カーネルパラメータなど） |
ミドルウェア資源（各種設定パラメータなど） アプリケーション資源 |
| アプリケーションの実装 | ロック待ち 排他処理 処理方式 etc. |
| データベース | データベースに関しては、参考書籍などを参照していただきたい。 |
| 付帯装置 | ファイアウォール 負荷分散装置 etc. |
| そのほか | ソフトウェアバグ （OS、ミドルウェア、 ライブラリ） etc. |
●計画立案上の考慮点
フローの項目のほかに以下の点を、計画には盛り込んでおく。
●スケジュール
●必要機材の確保
●解析ツールの選定、入手
●人的リソースの確保
●必要工数と費用の見積もり
最後に、ここまで述べてきた内容を、「実施計画書」としてドキュメント化し、承認を得る。
改善活動の実施―計画にのっとって改善活動のサイクルを回す―
計画が完成したので、後はそれにのっとって実際の作業を進めていけばよい。以降に、工程ごとのちょっとしたポイントについて、記述しておく。
●推定原因の検討
前章と同様であるので、参照していただきたい。
●測定
最初に、目標を達成するためのリファレンスとなる、改善対象の現状の計測値を取得しておく。それとともに、推定原因が正しいことを証明するための、各種データも取得する。
この測定のフェーズが、機材の確保と準備、OS、ミドルウェア、アプリケーションソフトウェアのインストールと設定、測定用ツールなどの準備、測定用プログラムなどの作成など、工数が大変かかるところである。計画立案時に十分検討しておかないと、スケジュール遅延や工数オーバーによる費用超過を招いてしまうので、注意が必要である。
●解析
取得したデータを基に、原因分析を行う。推定原因を裏付ける測定結果になっているか、また、予想外の原因につながると思われるデータが取れていないかなども十分考慮して、解析を行う。普段から、有効な解析ツールの使い方に慣れておくと、効率の良い解析が行える。
●改善施策立案
解析した結果を基に、具体的な改善施策を立案する。アプリケーションのあるモジュールの処理方式に問題がありそうならばその方式と実装方法を、CPUリソースが問題であればCPU能力の増強を、といった具合に、それぞれの原因に対する改善策を具体的に考えて計画を作成する。
この際に、対処案を施した場合に、どの程度まで目標値に近づくことができるのか、最終的に目標値をクリアできるのかを、机上レベルで予測したうえで、対処方法の有効性を考え、必要に応じて優先順位付けを行って、計画を立案することが重要である。
また、さまざまな技術的検討も行うことになるので、関連する技術の知識と経験が豊富なエキスパートに参加してもらうか、レビューを行ってもらうのがよい。
●改善施策の実施
改善施策の計画に基づいて実施する。具体的には、アプリケーションプログラムの処理方式の変更であったり、各種リソースのボトルネックの解消であったり、アプリケーションサーバなどのミドルウェアのチューニングであったりといった内容である。
この際に、新しい事象に遭遇したり、当初想定していない事柄を発見したりすることが、よくある。具体的には、想定外のプログラムバグ、ミドルウェアなどのマイナーバージョンの差、テスト中のワーニングメッセージなどである。ここで、当初の目的を見失って、新事象の解析など、横道へそれてしまうと、時間を浪費してしまうことにつながる。最初の心構えの「目的を見失わないこと」を念頭に置いて作業をしていただきたいと思う。この時点で発生した新たな事象などについては、いったん決定した改善施策が実行できないといったようなクリティカルな問題や、今回の性能改善に直接つながる可能性の高い問題でない限りは、その段階で新たな題の対処を計画するのでなく、事象を記録に残してリストにしておき、改善施策の結果の判定後に、新たな題の扱いをどうするかをあらためて検討することにしておけばよい。
●効果測定
改善施策後の効果を測定する。環境、測定方法など、最初の測定時と合わせておき、改善施策以外の要因が影響しないように配慮しておく。
●判定
効果測定で得られたデータを判定する。目標を達成したのか、達成していないとすれば、施した施策それぞれが、どれだけ改善に寄与したのかを、定量的に分析を行う。
目標を達成したならば、活動フェーズは終了し、次のステップへと進む。達成していないならば、得られた分析結果から、次のアクションを決め、フローの上流へ戻り、達成するまでそのサイクルを繰り返す。
●報告（結果のまとめ）
ようやく目標を達成することができた。依頼者からも感謝され、喜びもひとしおである。 「苦労も多かっただけに、ここはひとつ関係者を集めて打ち上げでも……」といきたいところであるが、もう少し我慢してほしい。最後の仕上げ、結果をまとめ、報告書をしたため、報告をきちんとしてから完了としよう。
報告書に関しては、いままでの活動のサマリーと得られた成果を簡潔にまとめる。途中段階で判明した、別な事象などがあれば、併せて記載しておく。また、今後の課題や提案なども記述しておくとよい。
報告書が完成したら、関係者で最終報告会を実施して、今回達成した成果をもって活動は終了とする旨、責任者に合意をもらっておくことが望ましい。最後の、報告書提出や最終合意をあいまいにしたまま、すべての作業を終了してしまうと、後々面倒な事態になる場合がある。
例えば、しばらくたってから前提条件が変更になったために、いったん達成したはずの性能が出なくなり、今回の活動の成果が出ていないのではと誤認されて、再改善を求められるなどというケースが生じ得る。従って、この締めくくりの報告フェーズを、きちんと実施しておくことをお勧めする。
以上で、改善活動もようやく終わりを迎えることができた。苦労を分かち合った仲間と打ち上げでもして、ぜひ労をねぎらっていただきたい。
パフォーマンスチューニングは面白い
今回では、パフォーマンスチューニングにおいて、技術的な実践法を解説する前に、改善活動における考え方と、手順に対する原則を説明した。いかがだったであろうか。基本的な進め方に関しては、極めて一般的な手順であることがお分かりいただけたと思う。パフォーマンスチューニングを実施するときには、いろいろと厳しい状況下に置かれている場合が多いので、つい基本的な手順をおろそかにしがちである。状況が厳しければ厳しいほど、冷静になって、今回の原則論を思い出していただければと思う。ぜひ、実践に活用していただいて、目標達成のお役に立てればと思う。
ここで、今回詳細に触れなかった観点についても若干触れておく。今回は主に性能問題が顕在化してから、どう改善して最適化していくかという、いわゆる「パフォーマンスチューニング」について解説している。しかしながら、システムの性能を実現するうえでの、もう一つ重要なポイントとして、「性能設計」、つまりシステムやアプリケーションの設計段階で、どのようにして所要の性能を実現するかという検討が挙げられる。設計段階で、システムの性能が考慮された設計がされており、それに基づいてシステムの構築が行われていれば、後が楽である。本来こちらの方が正しい姿であるといえよう。
最後にパフォーマンスチューニングの面白さについて、一言述べさせていただいて、記事を終わりにしたい。パフォーマンスチューニングは面白い。筆者は本当にそう思う。それは、人間の知恵を使って、シビアな状況の中（本当にしびれるような状況が結構ある）で、困難な目標をクリアすることの達成感にあるのだと思っている。
ちょっとした改善のアイデアで、いきなり性能が数倍にもなったりすることもある。こういったときは大変気分がいいものである。また、ボトルネック探しとボトルネックつぶしをこつこつと地道にやって、やっと達成という場合もある。これはこれで苦労した分充実感が味わえる。また、いろいろな情報から仮定を導き出し、それを検証する方法を考え実行するという、極めて知的好奇心を満足させてくれる作業でもある。
また、ビジネスインパクトの大きいシステムを改善した場合は、関係者みんなが本当に感謝してくれるという喜びも味わえ、エンジニアみょうりに尽きる。私事ではあるが、マネージャ業務が大半になったいまでも、部下がパフォーマンスチューニングの仕事をしていると、ついつい首を突っ込んでしまっている（首を突っ込まれる方は迷惑なことかもしれないが）。
これを機会に、1人でも多くのエンジニアが、パフォーマンスチューニングワールドの魅力にはまり、その能力とスキルと経験を増やしていくことを願う次第である。
さて、第2回からはいよいよ実践編である。筆者の所属する会社とも付き合いの深い、日本BEAの方にバトンタッチし、連載は続くことになるのでご期待いただきたい。
それでは、Let's enjoy performance tuning！
Copyright © ITmedia, Inc. All Rights Reserved.