「システムが遅い！」その時どう取り組むか：J2EEパフォーマンスチューニング（1）（1/2 ページ）

（1）問題の把握

システムの性能問題が直面している背景

　この記事をご覧になっている方なら、だれでも一度はこのような話を耳にしたことがあるだろう。IT業界に携わる人ならば、企業の情報システム部門、SIベンダの開発部門などの各自の所属部門や役割や直接的、間接的を問わず、何らかの形で、システムのいわゆる「性能問題」「パフォーマンスチューニング」にかかわりを持っているはずである。

　昔はパフォーマンスチューニングといえば、経験豊富な一部のエンジニアにのみ関係のある、いわゆるエキスパートの仕事であったが、最近ではそうではなくなってきている。そのようなエキスパートエンジニアは大勢いるわけでなく、いてもたいていは引く手あまたで、重要プロジェクトなどにどっぷりとはまっていて、ほかの案件まで手の回る状態ではない。

　また、自分は開発プログラマーなので、あまり直接は関係なさそうだなと思っていたところ、ある日突然上司もしくは顧客に呼ばれ、システムの性能改善を命ぜられて途方に暮れている方もいらっしゃるのではないだろうか。これからは、私たち各自がよりシステムの性能を意識した仕事の仕方をしなければいけないことと、システムの性能最適化のスキルを身に付けていく必要性が増している時代になっていることは事実のようである。

性能問題解決の重要性

　インターネットの急速な普及に伴い、急拡大するITビジネスとITインフラ投資の増大。ECサイトやiモードインフラなどに代表される、「ミッションクリティカル」な業務システムへのオープンシステムの適用の増加。最近のオープンシステムは企業の経営のみならず、社会的基盤の根幹をなすような位置を占めてきている。

　このような背景の中で増大するトラフィックをいかにさばき、サービスレベルを維持するか、またシステム投資に見合う処理能力を出せるのか、といったシステムのいわゆる「性能問題」解決の重要性はますます高くなってきている。

性能問題解決の困難さ

　一方で、システムの性能に要求される条件は、ますます厳しいものになってきている。 例を挙げると、

といったような、トラフィックの予測が困難なシステムが増えている。また、以下に示すようにシステムそのものも複雑化し、課題が増えている。

　このように、考慮すべき要素が多くあり、解決までの道のりを困難なものにしている。まとめると、システムの性能問題の解決には、社会的な重要性がますます増しているとともに、難しさもまたそれに比例するかのように増している状況であるといえる。

解決に向けての基本的な考え方と手順を理解する

　さて、そのような大変でかつ複雑な問題を解決しなければならないのが、われわれIT業界で仕事をしているものに課せられている使命でもある。しかしながら、どんなに困難な問題でも、そこには必ず解決策が存在するし、方法に関して王道は存在しないまでも、このとおりやれば効率的に進められるという、基本的なやり方はある。

　性能を改善しようとする場合、ややもすると、すぐに技術的な解析やアクションに入りがちである。しかしながら、基本的な考え方と手順を理解することなしに、いわゆるパフォーマンスチューニングに突入してしまうと、モグラたたきのような対策や手戻りなどのリワークの発生により、おびただしい非効率な作業が生じてしまう。その結果として、解決までの期間が長期化してしまうことになりかねない。

　そして何よりもエンジニアを含め、携わっている人たちが疲弊してしまい、それによってさらに問題が長期化するという、悪循環に陥ってしまうので注意が必要である。

　今回は、性能問題を解決する際の、実際の解析やチューニングに着手する前に必要な、問題の整理と改善計画の立案方法、およびチューニングのちょっとした勘所に関して述べる。筆者がこの業界での経験により身に付けた経験則を整理して記述することにしたい。また、ありがちな事例なども記載しておく。本記事に従えば、必ず解決できるといったたぐいのマニュアルではないが、この記事が性能問題に直面して困っているIT技術者の方々の、お役に少しでも立てば幸いである。

最初の心構え―心に留めておくべき事柄―

　ここでは、性能改善活動を行っていくに当たって留意しておくべきキーワードを挙げる。以下に6項目を挙げておいた。基本的な事柄であるが、役に立つのでぜひ覚えておいていただきたい。このうちポイントとなる項目については、次章以降で詳しく述べることにする。

(1)綿密な計画なしに着手しないこと

何事も準備や計画が肝要である。稼働しているシステムの、システムトラブルが性能問題に起因しているような場合、事は緊急を要していて、時間的にも精神的にも余裕がないことが多い。そのような場合にこそ、慌ててシステムをいじくりまわしたりせずに、冷静に解決に向けての計画を立てることが重要である。行き当たりばったりや、ヤマ勘でアクションを起こしてはいけない。ただ、そうはいってもクリティカルなトラブルの場合は、なかなか思うように行動できないことも多いので、普段から心掛けていて、ちょっとしたチューニングの機会にでも、きちんと計画を立ててからアクションを起こすように、実践しておくことが必要である。

(2)先入観念を持たないこと
(3)あらゆる可能性を考えてみること

　この2項目に共通することであるが、計画段階で推定原因を挙げる際など、ついつい思い込みで、原因を推定しがちである。

• 先日OSにパッチを当てたのでそれが原因のはずだ
• 通信モジュールを入れ替えてからおかしくなった、すぐ直さねば
• キャンペーン広告をうってから遅くなった。システムの負荷が上がったのが原因だ。CPUを増設しなければ

など、割と目先の事象にとらわれて推定しがちである。それ以外にも、原因となるものはないか、ほかの事象と合わせて本当につじつまが合うのか、などゼロベースで思考することが重要である。例としては、

• 社内の人間の不正利用による負荷の増大
• システムパラメータの設定ミスなど人間系の原因

などが挙げられる。

(4)事実と推測をきちんと分けて考えること

　解析が進み、原因を絞り込もうとしている段階などで起こりがちなのが、確認された事実と、未確認な推測をごっちゃにして、あたかも両方が事実となり、アクションプランを立ててしまうことがある。特に、複数の人間で共同で解析を進めている場合に発生しやすいので注意が必要である。間違った事実を基に対策を立案して実行してしまうと、リワークの発生につながる。

(5)目的を見失わないこと

　解析の途中で、いったい何が目的だったのかを見失ってしまうことがある。業務アプリケーションのレスポンス時間を短縮しようとしているつもりが、処理能力を上げようとしていた。DBアクセスモジュールを解析していてバグを発見し、本来性能改善とは関係ないバグを一生懸命デバッグしていた、などということもある。常に、何のためにいまこの作業しているのかを、念頭に置きながら進める必要がある。

(6)だれの問題かを意識して行動すること

　「性能」は客観であり定量的に定義できるが、「問題」は主観である。とは筆者の会社のチームメンバーの1人がいった言葉である。主観であるが故に、定義することとそれを共通の認識とすることが必要になってくる。「性能問題」というからには、問題だと思っている人がいるわけである。だれの問題を解決すればよいのかは重要な観点になる。それによって、同じ事象を解決するにしても、取るべきアクションが違ってくる。この点については、後ほど詳細を記述する。

まずは問題の整理と定義から―課題を明確にするために問題を整理し定義する―

　さて、心構えができたところで、いよいよ改善活動のスタートである。まずは問題や課題の整理と定義から入ろう。このフェーズが性能改善活動を行ううえでの最初のステップとなる。最初が肝心なので、例を挙げて詳しく説明することにする。

　最初のきっかけとして、だれからどういう形で、いわゆる「性能問題」は提起されるのであろうか。提起する人は、経営者、エンドユーザー、情報システム担当、開発SE、試験担当SE、などさまざまである。人によっていい方、表現のレベルもさまざまであろう。以下に具体例を思いつくままに列挙してみる。

　いかがであろうか。もちろん実際には、依頼者とやりとりをするので、もう少し具体的な表現になると思うが、このように「性能問題」といっても人によって、とらえ方や定義がさまざまであることが分かる。

　これが、「性能」は客観であり定量的に定義できるが、「問題」は主観であり、主観であるが故に、定義することとそれを共通の認識とすることが必要である。ということのゆえんである。

性能とは何だろうか？

　ここで、性能とは何かという言葉の定義をしておく。一般的に、システムの性能といった場合には、ユーザー応答時間（レスポンスタイム）といったスピードの点と、データの処理能力（スループット）、いわゆるトランザクション処理能力の点を指している場合が多い。しかしながら、性能という範囲には、品質、運用性、操作性、安全性なども含めて話をする場合もあり、この場合は広義の意味での性能の定義といえる。

　このように、性能と一言でいっても、その定義の範囲に幅があるので、きちんと定義をして、関係者の間で意識を合わせておくことが重要なのである。

　この記事では、主に前者の「応答時間」と「処理能力」といった、狭義の意味の性能を改善していくアプローチの手法について説明する。もちろん、その手法については、広義の意味の性能改善にも、適用可能なものがあるのはいうまでもない。

実際に改善すべき問題は何かを定義する

　問題が提起され、解決すべき課題として認識された。その後は、問題解決の依頼者および関係者からのヒアリングや、その時点で観察されたシステムの事象やデータなどを基に、問題の定義を行う。定義するためのキーワードとしては、以下を参考にしてまとめるとよい。

(1)だれの問題か

　要するに、だれにとっての問題を解決すればよいのかということである。顧客なのか、端末のオペレータなのか、会社の経営陣なのか。システムの性能問題は、だれか単独の人だけに影響していることは少なく、たいていは複数の関係者に影響を及ぼしている。しかしながら、まずだれの問題を解決するかにより、優先順位と解決方法が異なってくる。例えば、経営陣にとって業務処理を規定期日までに完了させることが、最優先事項と判断されたならば、端末のレスポンスタイムのチューニングよりも、処理能力向上のためのチューニングを優先しなければならないといった具合になる。

(2)何が（どのような）問題か

　その人にとって何が問題なのかを、具体的に記述する。例えば、ヘルプデスクのオペレータにとっての問題であれば、

「過去事例検索アプリに検索キーワードを入れて、検索ボタンを押してから検索結果が表示されるまでに、3分以上もかかってしまう。電話でお客さまをお待たせしてしまう」

といった具合にまとめる。

(3)なぜ（どうして）問題か

　先ほどのヘルプデスクのオペレータの例でいえば、

「お客さまに、回答が遅いとクレームをいわれることが多々あり困っている」

となる。これを、経営陣としての問題ととらえると、

「ヘルプデスクを利用した顧客の自社に対しての顧客満足度が下がり、製品の売り上げに影響するので困る」

といった内容になる。

(4)いつから問題になったのか

　この後の、改善計画の立案時の推定原因を挙げる際に、有効な情報となり得る場合があるので、この時点で整理をしておく。先ほどのオペレータの例では、

「確か、今年の8月ごろから急に遅くなった」

といった具合。このシステムを開発した情報システム担当のSEであれば、

「データベースを新しいバージョンにアップデートしてから」

というようにだ。ただし、注意すべきはあくまでも状況証拠であることを理解しておくことと、裏が取れている確実な事実か、裏が取れていない推測かをきちんと分けて記録しておくことである。この点は、「最初の心構え」に記述したポイントでもある。

(5)その問題の影響度は

　問題解決の優先順位と、いつまでに解決すべきかを決定する際に必要な情報である。影響度が判断しづらい場合は、その問題を放置したらどうなるか。など極論に振って考えてみればよい。この際に、定量的な記述ができるとなおよい。先ほどの例では、どう考えても顧客のクレームは増えそうだし、それに伴って顧客離れが起こって、売り上げも落ちそうなので、

「影響度：大」

としておく。しかしながら、先ほどの例で顧客からのクレームはまったくなく、顧客も満足しており、困っているのはオペレータが少しいらいらするだけ、といった問題ならば、

「影響度：小」

であろう。

(6)対象となるシステムは

　最後に、どのシステムでその問題が発生しているのかも、具体的にきちんと整理しておく。オペレータは運用システム上での問題をいっていたが、開発SE側は開発システム上の問題と認識していた、などのようにならないためにも必要である。この例では、

「ヘルプデスク事例検索システムの運用1号機で」

としておく。

以上、いままでの例を簡単に整理しておく。

　以上で、問題の定義は完了である。少し本筋から外れてしまうが、このステップの作業を行っている過程で、思いもかけない事実が判明することがある。例えば、

などが挙げられる。新しい事実が判明したら、確実に記録をしておこう。次のステップは、定義された問題を解決するための課題の設定である。

課題の設定―何をどう改善すべきかの課題を明確にする―

　問題の定義ができたら、次に解決すべき課題を具体的に定義する。問題は明確になっているので、課題の定義は比較的容易に行える。なるべく簡潔で分かりやすく記述することが重要である。今回の例では、

「ヘルプデスク事例検索システムの、検索結果が返ってくるまでのレスポンスタイムを短縮し、ユーザークレームを減らすこと」

としておく。オペレータ側の視点での問題と、経営陣の側の視点での問題の両方を解決することが、今回の「性能改善」のゴールであることが分かる。次のステップでは、この課題を基に具体的な目標設定を行う。

目標と期限を明確にする―課題を具体的な目標値にし、スケジューリングする―

　改善すべき問題の定義と課題が明確になった。次にそれをどのような状態にすれば、解決した、改善されたとするのかを具体的な目標として明確にする。それとともに、いつまでにその目標を達成しなければいけないか、という期限も設定しておく。

　目標はなるべく、定量的な目標値にすることが望ましい。定量的に記述できない場合は、定性的に記述する。また、その目標値を達成する場合の前提条件についても記述しておく。今回の例では次の表のようにしておく。

　ここで決めた目標値が、性能改善活動の具体的なゴールとなる。この目標を達成しても問題が解決しなかった場合は、目標値を見直すか、問題の定義を再度行い、改善のサイクルを回すことになる。また、期限内で目標を達成できるようなスケジュールで、計画を立てることになる。

　実は、この目標値を実際にいくつにするのかは、案外悩ましい問題である。妥当性の判断が難しいからである。ユーザー要件などにより、トップダウンで決められている場合もあるし、経験値（過去の事例など）から設定する場合、ある前提条件から設定する場合（コマースサイトの8秒ルールなど）など、対象となるシステムによりさまざまであり、こうすべきということは一概にいえない。関係者間で十分議論したうえで、合意しておくことが重要である。

ここまでのまとめ

　ここまでの段階で、

●問題の定義
●課題の設定
●目標と期限の明確化

までが終了した。この定義した、問題、課題、目標、期限の4点を、ステートメント化して、関係者間で合意を取っておくことが大変重要である。この段階で、意識の大きな違いを残したまま、具体的な解析作業などへと進んでしまうと、後で悲惨なことになりがちである。

　上記3つのフェーズは改善活動を効率良く進めるために、大変重要なフェーズである。よくあるケースとして、このフェーズをあいまいにしたまま、解析、アクションへと突入してしまい、結果として、その後のフェーズでリワークの発生など非効率のわなに陥ってしまう場合がある。

　このフェーズをきちんとやっておくことが、この後具体的な改善作業をスムーズに進めるために不可欠である。