JP6131101B2 - 障害検知プログラム、障害検知方法、及び情報処理装置 - Google Patents

Description

本発明は、障害検知に関する。

システム性能は、ＣＰＵ（Central Processing Unit）やメモリやサーバ配置構成等、ハードウェアに依存するところが大きい。このことから、システム性能の監視は、ハードウェアリソースの有効活用を主観点として行われている。より具体的には、例えばアプリケーションの処理性能の監視では、アプリケーションを実行する物理計算機の負荷（ＣＰＵ使用率等）の監視が行われている。物理計算機の負荷を監視することにより物理計算機の負荷増加によるアプリケーションの処理性能低下の検出や抑止が行なわれる。

一方、近年はハードウェアの性能向上や低価格化が進んでいる。また、大規模基幹系オープンシステムにおいては、ＯＳＳ（Open Source Software）や性能面で十分に検証されていないミドルウェア等の適用が増加している。さらに、マルチベンダ化や短納期化による構築者の製品選定を含めたスキルの低下等、ＳＩ（System Integration）環境が変化してきている。

このような状況下において、大規模なシステム等では、ハードウェア的には性能要件を満たしている（ハードウェアリソース的には性能限界まで余裕がある）にもかかわらず、ソフトウェア（例えばミドルウェア）の特性に起因する性能障害が発生している。これは、例えば、ミドルウェアのパラメータの設定値の設計ミスや、システム統廃合によるデータ量・トランザクション量の増加により、本来、処理しなければならないトランザクション量を処理できない場合などである。

このようなソフトウェアの特性に起因する性能障害は、物理計算機の負荷の監視では検出することはできない。

ハードウェアの観点からアプリケーションの処理性能の障害を監視する方法の一例として、以下の方法がある。この方法では、まず、定期的に、ＣＰＵ、メモリ、ディスク等のハードウェアのリソース使用量の測定が行われる。そして、事前に設定してあるリソース使用量の使用限界値（閾値）を、測定した値が任意時間あたりに超過した回数が計測される。次に、計測された回数に基づいて、アプリケーションの処理性能が正常か異常かの判定がなされる。異常と判定された場合は、対処が必要と判断され、チューニングやシステム増強（スケールアウトやスケールアップ）等の対処が実施される。

このようなハードウェアリソースの閾値による判定では、システムの状態が、システムのハードウェアリソース的性能の許容範囲外となったことの判定は可能である。しかしながら、システムの状態がハードウェアリソース的性能の許容範囲内であっても、ソフトウェア的性能限界を超えているかの判定はできない。

さらに、ハードウェアリソースの閾値による判定において、ハードウェアリソースの測定値が閾値を超えた時には、既にソフトウェア的性能劣化が顕著化している状態となっている。この時点では、ソフトウェアの構造上（整合性確保の為の排他制御、多重化されていない部分、非効率な処理論理やデータ構造やプログラム言語やＯＳ（Operating System）コールの使用、オブジェクト生成等の高コスト処理の同時実行等のソフトウェアの内部構造が要因）の理由で、ソフトウェアのチューニングの余地が無い。

よって、ハードウェアの観点から性能障害を監視しても、ソフトウェアの特性に起因する性能障害の検出はできないし、ハードウェアの観点で性能障害を検出したタイミングでは、既にソフトウェアに対して講ずる対応の余地がない。したがって、ソフトウェアの観点からアプリケーションの性能障害を検出することが重要となる。

ソフトウェアの観点からアプリケーションの処理性能の障害を監視する方法の一例として、トランザクションの処理時間に応じて負荷制御を行う技術がある。この技術では、アプリケーションサーバ毎に、当該アプリケーションサーバが受信したトランザクションをアプリケーションプログラムが処理する処理時間を監視する。そして、アプリケーションサーバ毎の処理時間の監視結果に基づいて、処理時間が予め定められた許容範囲内でないアプリケーションサーバがある場合に、当該アプリケーションサーバとデータベースサーバのいずれにボトルネックがあるのかを特定する。

国際公開第２００５／０４１０３８号 特開２００１−１６００４０号公報 特開２００８−７７２６６号公報 特開２００６−２５２１６３号公報

ソフトウェアの特性に起因する処理性能の低下は、物理計算機の負荷増加による性能低下と比較して、急激に処理性能が低下する傾向があり、早期の予兆検出が重要である。

しかしながら、上記技術のようにアプリケーションの応答時間を監視することによる処理性能低下の検出では、応答時間が一定以上長くなった段階での検出となる。そのため、急激に処理性能が低下した場合には、対処が間に合わず、業務に影響を及ぼしてしまうなど、対応の遅れが問題となる。

そこで、１つの側面では、本発明は、ソフトウェアの障害の予兆検知精度を向上することを目的とする。

一態様の障害検知プログラムは、コンピュータに、処理要求に対するソフトウェアの応答時間を平均化して得られる平均化応答時間を、ソフトウェアに対する単位時間当たりの処理要求受信数ごとに蓄積し、第１の処理要求受信数と第２の処理要求受信数との差分に対する第１の平均化応答時間差分と、前記第１の処理要求受信数および第２の処理要求受信数よりそれぞれ大きい第３の処理要求受信数と第４の処理要求受信数との差分に対する第２の平均化応答時間差分と、に基づいて、ソフトウェアの障害の予兆を検知する処理を実行させる。

本実施形態に係る情報処理装置によれば、ソフトウェアの障害の予兆検知精度を向上することができる。

本実施形態にかかる情報処理装置の機能ブロック図の一例である。 本実施形態の情報処理システムの構成の一例を示す。 処理ルート定義の構成の一例を示す図である。 ノード定義の構成の一例を示す図である。 ノード名の採番方法を説明するための図である。 履歴情報の構成の一例を示す図である。 平均レスポンステーブルの構成の一例を示す図である。 複数サーバを跨る性能情報収集と定義変更処理について説明するための図である。 処理要求数の代表値と平均レスポンス時間の一例を示す図である。 性能評価を行う区間の一部にしかデータが計測されない場合の例を示す。 評価区間が狭すぎてレスポンス増分特性を捉えられない場合の例を示す。 評価区間が広すぎて集計対象の性能情報を削減できない場合の例を示す。 複数サーバを跨る多重度の変更値の算出方法を説明するための図である。 仮定した多重度の確定方法を説明するための図である。 性能情報収集部による性能情報収集処理の動作フローを示す。 性能診断部の性能障害の予兆検出処理の動作フローを示す。 定義変更処理部による多重度変更処理の動作フローを示す。 多重度管理表の構成の一例を示す。 管理サーバ及び業務処理サーバのハードウェア構成の一例を示す。

本実施形態では、「単位時間」あたりの「処理要求数」における「レスポンス時間」の増減に基づいて、ソフトウェアの性能障害の予兆を検出する。これにより、ソフトウェアの要因で性能が頭打ちになる事象（以下、性能限界と記す）を早期に検出することができる。性能限界を超えている場合は、少しの処理要求数の増加で、例えばレスポンス時間が急増するので、対処が間に合わず、業務に影響を及ぼしてしまう場合があったが、これを防ぐことができる。また、ソフトウェアの特性としての性能限界を検出する事で、精度の高い予兆監視が可能となり、最適なタイミングでのシステム構成変更や運用警告、適正なリソース配置が可能となる。

性能異常が検出されると、次に、性能異常を解決するための処理が行われる。本実施形態では、ソフトウェアの観点からシステム構成の変更が行われる。すなわち、異常が検出されたソフトウェアの設定の変更がなされる。

性能異常を解決するための対応処理として、具体的には本実施形態では、ソフトウェアの、チューニング項目である多重度の変更を行う。多重度は、要求された処理を平行して処理する為のソフトウェア（アプリケーション及びミドルウェア）の設定項目であり、同時に並行して処理可能な処理（タスク）またはプロセス（スレッド）の最大数である。また、多重度はソフトウェアのパラメータとして設定可能な項目であるため、既存のシステムに対する改造を加えなくてもよい。さらに、多重度は、多くのソフトウェアで共通で利用されているチューニング項目であるため、複数のソフトウェアを跨って統合的な制御がしやすいという面がある。

ソフトウェアの多重度を変更する場合は、変更するソフトウェアの処理に関連する他のソフトウェアの多重度の変更も行う。関連するソフトウェア間の処理の依存関係に基づいて、多重度を変更する順番が制御される。これにより、システム全体の処理におけるボトルネックの発生を回避することができ、システム全体としての処理性能を改善できる。また、一つ一つのソフトウェアについて手作業で設定変更を行うことと比較して、作業負荷を軽減することができる。さらに、システム管理者は、特定サーバの設定変更時に、関連サーバに跨る影響範囲の調査が不要になり、対処漏れを防ぐことができる。

このようなソフトウェアの多重度の変更により、性能異常が解決される場合とそうでない場合がある。ハードウェアリソース的に性能限界まで余裕が有る状態では、多重度を変更する事で、ミドルウェアの処理限界を上げて、トランザクション量を上げることができるので、処理性能の改善につながる。逆に、ハードウェアリソース的に性能限界まで余裕が無い状態では、ミドルウェアの「多重度」関連のパラメータを変更しても、トランザクション量は上がらず、処理性能は改善されない。

言い換えると、多重度を変更することにより性能異常が解決される場合は、性能異常の原因がソフトウェアにあった場合である。しかし、多重度を変更しても性能異常が解決されない場合は、性能異常の原因がハードウェアにある場合である。性能異常の原因がハードウェアにある場合は、ソフトウェアの多重度を変更しても性能異常は解決されないため、本実施形態では、多重度を変更しても性能異常が解決されない場合は、変更した多重度を変更前の状態に戻す。これにより、無駄なソフトウェア資源の消費を防ぐ。多重度を変更（上げる）と、リソース（メモリやスレッド）の管理情報も増え、処理コストも比例して上がる。その為、過度に大きい値を設定し続けることを避けることができる。

本実施形態では、さらに、多重度を変更してシステムを運用した結果、変更した多重度が要求される処理に見合っているか否かを判定する。要求される処理に比べて、多重度が大きく設定されており、システムの資源が無駄になっている場合には、ソフトウェアを退縮させるなどの制御を行う。これにより、ＣＰＵ、メモリなどのリソースを節約することができる。

図１は、本実施形態にかかる情報処理装置の機能ブロック図の一例である。
情報処理装置１は、蓄積部２、検知部３、算出部４、決定部５、変更部６、及び再設定部７を含む。

蓄積部２は、処理要求に対するソフトウェアの応答時間を平均化して得られる平均化応答時間を、ソフトウェアに対する単位時間当たりの処理要求受信数ごとに蓄積する。

検知部３は、蓄積部２が蓄積した第１の処理要求受信数と第２の処理要求受信数との差分に対する第１の平均化応答時間差分と、第２の処理要求受信数よりそれぞれ大きい第３の処理要求受信数と第４の処理要求受信数との差分に対する第２の平均化応答時間差分と、に基づいて、ソフトウェアの障害の予兆を検知する。

算出部４は、蓄積部２が蓄積した複数の処理要求受信数と処理要求受信数に対応する平均化応答時間を用いて、第１の処理要求受信数を含む第１の範囲内から、第１の処理要求受信数の代表値である第１の代表処理要求受信数と、第１の代表処理要求受信数に対応する第１の代表応答時間と、第２の処理要求受信数を含む第２の範囲内から、第２の処理要求受信数の代表値である第２の代表処理要求受信数と、第２の代表処理要求受信数に対応する第２の代表応答時間と、第３の処理要求受信数を含む第３の範囲内から、第３の処理要求受信数の代表値である第３の代表処理要求受信数と、第３の代表処理要求受信数に対応する第３の代表応答時間と、第４の処理要求受信数を含む第４の範囲内から、第４の処理要求受信数の代表値である第４の代表処理要求受信数と、第４の代表処理要求受信数に対応する第４の代表応答時間と、を算出する。また、検知部３は、第１の代表処理要求受信数と第２の代表処理要求受信数との差分に対する第１の代表応答時間差分と、第３の代表処理要求受信数と第４の代表処理要求受信数との差分に対する第２の代表応答時間差分と、に基づいて、ソフトウェアの障害の予兆を検知する。

決定部５は、第１の範囲、第２の範囲、第３の範囲、及び第４の範囲の幅を、ソフトウェアにおいて並列して実行可能な処理数を示す多重度に基づいて決定する。

変更部６は、ソフトウェアの障害の予兆が検知された場合、ソフトウェアの多重度を変更する。また、変更部６は、ソフトウェアの障害の予兆が検知された場合、ソフトウェアに対して処理要求を送信または受信する関連ソフトウェアの多重度と、ソフトウェアの多重度との比率に基づいて、関連ソフトウェアの多重度を変更する。さらに、変更部６は、ソフトウェアの障害の予兆が検知された場合、ソフトウェアに対して処理要求を送信または受信する関連ソフトウェアの多重度と、ソフトウェアの多重度との比が変化しない順番で、ソフトウェアと関連ソフトウェアの多重度を変更する。

再設定部７は、ソフトウェアの多重度が変更された後に、検知部３が再び障害の予兆を検知した場合、変更された多重度を変更前の多重度に戻す。

図２は、本実施形態の情報処理システムの構成の一例を示す。
情報処理システム１００、業務処理サーバＡ（１０１）、Ｂ（１０２）、及び管理サーバ１０３を含む。なお、図２では、管理サーバ１０３は業務処理サーバ１０１、１０２と別筐体の例を示しているが、いずれかの業務処理サーバに同居しても良い。

業務処理サーバ１０１は、端末装置１１６、情報処理システム１１１、アプリケーションプログラム１１２等の処理要求元１１５にネットワークまたはバスを介して接続される。また、業務処理サーバ１０１、業務処理サーバ１０２、及び、管理サーバ１０３は、ネットワークまたはバスを介して互いに接続される。

業務処理サーバ１０１、１０２では、アプリケーションＡ、Ｂ（１１３）やミドルウェアＡ、Ｂ（１１４）が稼働する。また、業務処理サーバ１０１は、処理要求元１１５から処理要求を受信する。受信された処理は、業務処理サーバ１０１、１０２で稼働するアプリケーション１１３及びミドルウェア１１４で実行される。処理が完了すると、業務処理サーバ１０１は、完了した処理の結果を処理要求元１１５に返す。

アプリケーション１１３に対し処理要求を行なう処理要求元１１５の一例としては、端末装置１１６や情報処理システム１１１（例えば他部門または他社システムを含む)等がある。または、処理要求元１１５の一例としては、別システムのアプリケーション１１２（例えばＷｅｂブラウザを含むアプリケーションクライアント)等がある。あるいは、処理要求元１１５の一例としては、システムが発行するメッセージ（例えば、イベントログ、Syslog、ネットワークのTrapメッセージ等)がある。尚、処理要求を行う端末装置１１６、情報処理システム１１１、アプリケーション１１２の数は、図２に示す数に限定されない。

管理サーバ１０３は、業務処理サーバ１０１、１０２で稼働するソフトウェア（アプリケーション及びミドルウェア）の処理性能を監視し、処理性能の低下を検出する。また、管理サーバ１０３は、処理性能の低下を検出すると、業務処理サーバ１０２、１０３で稼働するアプリケーション及びミドルウェアの多重度の変更を行う。尚、以下の説明では、業務処理サーバ１０２、１０３で稼働するアプリケーション及びミドルウェアをまとめてソフトウェアと記す場合がある。

管理サーバ１０３では、自動チューニングプログラム１０４が稼働している。自動チューニングプログラム１０４は、アプリケーション及びミドルウェアの処理性能を監視し、多重度の変更を行うプログラムである。自動チューニングプログラム１０４は、性能情報収集部１０５、性能診断部１０６、定義変更処理部１０７を含む。また、管理サーバ１０３は、自動チューニングプログラムにより使用される、処理ルート定義１０８、ノード定義１０９、処理要求数履歴１１０を含む。

性能情報収集部１０５は、蓄積部２、算出部４、及び決定部５の一例として挙げられる。性能診断部１０６は、検知部３の一例として挙げられる。定義変更処理部１０７は、変更部６、及び再設定部７の一例として挙げられる。

性能情報収集部１０５は、管理対象の業務処理サーバ１０２、１０３のアプリケーション及びミドルウェアの性能情報を収集する。性能情報の収集は、各ソフトウェアが提供するコマンド等のインターフェースを利用して行われる。また、性能情報収集部１０５は、処理ルート定義１０８及びノード定義１０９の情報を参照し、各ソフトウェアの性能情報を取得するためのインターフェースの情報を取得する。そして、取得したインターフェースの情報を用いて、性能情報収集部１０５は、各ソフトウェアの性能情報を収集する。そして、性能情報収集部１０５は、収集した各ソフトウェアの性能情報を処理要求数履歴１１０に格納する。性能情報の収集方法の詳細については、後ほど説明する。

性能診断部１０６は、処理ルート定義１０８、ノード定義１０９、及び処理要求数履歴１１０の情報を用いて、ソフトウェアの処理性能の低下を検出する。そして、性能診断部１０６は、処理性能の低下を検出すると、定義変更処理部１０７に、ソフトウェアの多重度を変更するように通知する。処理性能の低下の検出方法の詳細については後ほど説明する。

定義変更処理部１０７は、性能診断部１０６からソフトウェアの多重度の変更指示を受信すると、ソフトウェアの多重度を変更する。定義変更処理部１０７は、ノード定義１０９を参照して、処理ルートの途中で処理待ちが発生しないように、処理性能の低下が検出されたソフトウェアに関連するソフトウェアを特定し、適切な順番で特定したソフトウェアの多重度を変更する。多重度の変更については、定義変更処理部１０７は、処理ルート定義１０８及びノード定義１０９から、多重度の変更を行うためのインターフェースの情報を取得して、取得したインターフェースを用いて多重度の変更を行う。各ソフトウェアの多重度の変更の具体的な方法については、後ほど詳しく説明する。多重度を変更すると、定義変更処理部１０７は、変更の内容をノード定義１０９に反映する。

処理ルート定義１０８は多重度の変更に使用される処理ルートの制御情報が格納される。ここで、処理要求元１１５から要求される特定の処理において呼び出される、一連のアプリケーション及びミドルウェアの情報を処理ルートと記す。すなわち、処理ルートは、ミドルウェア及びアプリケーションが呼び出されるルートであり、処理ルートに含まれるノードは、ルート上のミドルウェア、アプリケーションを表し、ノードの前後関係はノード名の値で表現される。

図３は、処理ルート定義１０８の構成の一例を示す図である。
処理ルート定義１０８は、処理ルート定義名２０１、多重度増分比率２０２、多重度減分比率２０３、性能限界判断比率２０４、及び定義変更実施警戒レベル２０５の項目を含む。

処理ルート定義名２０１は、処理ルートを一意に識別するための識別情報である。多重度増分比率２０２は、処理ルート単位で指定する多重度変更実施時の多重度の増分比率を示す情報である。多重度減分比率２０３は、処理ルート単位で指定する多重度変更実施時の多重度の減分比率を示す情報である。性能限界判断比率２０４は、ソフトウェアの処理性能の低下を判定するために使用されるレスポンス時間の増加比率の閾値を示す情報である。定義変更実施警戒レベル２０５は、処理性能の低下を検出するために使用される情報である警戒レベルを示す情報である。警戒レベルは、例えば、レスポンス悪化の危険度を数値化したデータで0（安全）〜3（危険）の4段階を保持するフラグである。処理ルート定義１０８のそれぞれの情報がどのように使用されるかは、後ほど説明する。

図４は、ノード定義１０９の構成の一例を示す図である。ノード定義１０９は、処理ルートにおけるノード、すなわち、処理ルート上のミドルウェア及びアプリケーションに関する情報が格納される。

ノード定義１０９は、処理ルート定義名３０１、ノード名３０２、コマンド３０３、現多重度３０４、前多重度３０５、及び最大多重度３０６の項目を含む。

処理ルート定義名３０１は、処理ルートを一意に識別するための識別情報である。この処理ルート定義名３０１は、処理ルート定義１０８の処理ルート定義名２０１に対応する。

ノード名３０２は、処理ルートに含まれるノード（ミドルウェアまたはアプリケーション）を一意に識別するための識別情報である。

コマンド３０３は、処理ルート定義名３０１のノード名３０２で示されるノードの情報を収集するためのコマンド、及び、多重度を変更するためのコマンドの情報である。

現多重度３０４は、処理ルート定義名３０１のノード名３０２で示されるノードの現在の多重度を示す情報である。

前多重度３０５は、処理ルート定義名３０１のノード名３０２で示されるノードの、現在の多重度に変更される直前の多重度を示す情報である。

最大多重度３０６は、処理ルート定義名３０１のノード名３０２で示されるノードにおいて設定可能な多重度の最大値を示す情報である。

ここで、ノード名３０２について説明する。ノード名３０２はノードを一意に識別するための識別情報であるとともに、処理ルートにおけるノードの接続関係を示す。ノード名３０２は、処理ルートのノードの接続関係において、前後関係（階層関係）を示す番号と並列関係を示す枝番の情報を含む。尚、以下の説明では、前後関係を示す番号を１次キーと記し、並列関係を示す枝番を２次キーと記す場合がある。

ノード名の採番方法について説明する。図５（Ａ）及び図５（Ｂ）は、ノード名の採番方法を説明するための図である。図５（Ａ）のノード５０〜５５は、１つの処理ルートに含まれるノードを示しており、図５（Ｂ）のノード６０〜６６も、１つの処理ルートに含まれるノードを示している。尚、図５（Ａ）及び図５（Ｂ）では、ノード５２〜５５、ノード６０〜６４のノード名は、「1次キー − 2次キー」の形式で示される。

先ず、処理ルートの先頭ノード（最初の呼び出し元）に１次キー「1」が付与される。図５（Ａ）の例では、処理ルート定義の最初の呼び出し元ノードであるノード５０に対して、１次キー「1」が付与される。そして、呼出先のノードが、呼出元のノードに対し１大きい数となるように番号が振られる。図５（Ａ）の例では、ノード５０から呼び出されるノード５１には、１次キー「2」が付与される。また、呼出元から並列に呼び出される複数のノードが存在する場合は、並列関係を示す枝番（２次キー）が付与される。図５（Ａ）の例では、ノード５１から並列に呼び出されるノード５２とノード５３は、それぞれ２次キー「3-1」、「3-2」が振られる。さらに、呼び出し元が複数ある場合には、最大の１次キーを持つ呼び出し元に対し１大きい数が振られる。図５（Ｂ）の例では、ノード６５は、ノード６０、６２、６３、６４から呼び出されているが、そのうち、最大の１次キーを持つノードであるノード６３、６４より１大きい数である、「3」が付与される。

尚、処理ルートでは、提供するサービスが同じサーバを同じ並列関係となるように定義してもよい。例えば、Ｗｅｂ機能を提供するＷｅｂサーバ群に含まれる複数のサーバ同士を並列関係となるように定義してもよい。同様に、例えば、アプリケーションサーバ群に含まれる複数のサーバ同士を並列関係となるように定義してもよい。

処理要求数履歴１１０は、性能情報収集部１０５により、収集されたソフトウェアに関する性能情報が格納される。処理要求数履歴１１０は、履歴情報４００と平均レスポンステーブル５００を含む。

履歴情報４００は、一定間隔で計測された、単位時間あたりの処理要求数、およびその処理要求数下での平均レスポンス時間の情報である。また、履歴情報４００は、処理ルート単位で管理される。図６は、履歴情報４００の構成の一例を示す図である。

履歴情報４００は、処理ルート定義名４０１、ノード名４０２、履歴番号４０３、取得時刻４０４、処理要求数４０５、及び、レスポンス時間４０６の項目を含む。

処理ルート定義名４０１は、処理ルートを一意に識別するための識別情報である。この処理ルート定義名４０１は、処理ルート定義１０８の処理ルート定義名２０１、及びノード定義１０９の処理ルート定義名３０１と対応する。

ノード名４０２は、処理ルートに含まれるノード（ミドルウェアまたはアプリケーション）を一意に識別するための識別情報である。このノード名は、ノード定義１０９のノード名３０２に対応する。

履歴番号４０３は、変更された処理ルート定義毎に一意に振られた識別番号である。
取得時刻４０４は、性能情報収集部１０５が、レコードに含まれる性能情報を取得した時刻である。

処理要求数４０５は、取得時刻に取得された、単位時間当たりの処理要求の数である。ここで、処理要求数とは、業務処理サーバ１０１、１０２に要求された、あるいは、業務処理サーバ１０１、１０２から要求する単位時間当たりの処理数である。

レスポンス時間４０６は、同一レコードの処理要求数にカウントされた処理要求のレスポンス時間の平均値である。ここで、レスポンス時間４０６の算出は、単純平均による算出に限定されず、種々の平均化手法を用いて算出してもよい。また、平均化手法以外に、種々のデータの端数処理または丸め処理による手法を用いて算出してもよい。

平均レスポンステーブル５００は、性能情報収集部１０５により生成される単位時間当たりの処理要求に対するレスポンス時間の平均値の情報である。平均レスポンステーブル５００の情報は、性能診断部１０６によりソフトウェアの処理性能の低下の検出のために使用される。図７は、平均レスポンステーブルの構成の一例を示す図である。

平均レスポンステーブル５００は、処理ルート定義名５０１、ノード名５０２、区間代表値５０３、平均レスポンス５０４、差分情報５０５、警戒レベル情報５０６、及び定義変更フラグ５０７の項目を含む。

処理ルート定義名５０１は、処理ルートを一意に識別するための識別情報である。この処理ルート定義名５０１は、処理ルート定義１０８、ノード定義１０９、及び履歴情報４００の処理ルート定義名２０１、３０１、４０１と対応する。

ノード名５０２は、処理ルートに含まれるノード（ミドルウェアまたはアプリケーション）を一意に識別するための識別情報である。このノード名５０２は、ノード定義１０９及び履歴情報４００のノード名３０２、４０２に対応する。

区間代表値５０３は、所定の値毎に設定された処理要求数の代表値の情報である。
平均レスポンス５０４は、履歴情報４００のレスポンス時間４０６から算出された、区間代表値５０３に対応するレスポンス時間を平均化した値の情報である。ここで、平均レスポンス５０４の算出は、レスポンス時間の単純平均による算出に限定されず、種々の平均化手法を用いて算出してもよい。また、平均化手法以外に、種々のデータの端数処理または丸め処理による手法を用いて算出してもよい。

差分情報５０５は、同一レコードの区間代表値５０３における平均レスポンス５０４と、１つ前のレコードの区間代表値５０３における平均レスポンス５０４との差分（傾き）の情報である。

警戒レベル情報５０６は、処理ルートの性能悪化危険度を数値化した情報である。警戒レベル情報５０６には、例えば、0（安全）〜3（危険）の4段階が設定される。

定義変更フラグ５０７は、処理ルートが定義変更を実施されたかを示すフラグである。定義変更フラグ５０７には、例えば、0（定義変更なし）〜1（定義情報変更済）の番号が設定される。

次に、複数サーバを跨る性能情報収集と定義変更処理（多重度変更処理）について説明する。図８は、複数サーバを跨る性能情報収集と定義変更処理について説明するための図である。図８の例は、処理ルートが、業務処理サーバＡで稼動するアプリケーションＡ、アプリケーションＢ、ミドルウェアＡ、及び、業務処理サーバＢで稼動するミドルウェアＢを含む例を示している。

業務処理サーバＡは、ミドルウェアＡにおける、アプリケーションＡからの処理要求数とレスポンス時間、アプリケーションＢからの処理要求数とレスポンス時間を定期的に採取する。また、業務処理サーバＢは、ミドルウェアＢにおけるミドルウェアＡからの処理要求数とレスポンス時間を採取する。

そして、図８に示すように、自動チューニングプログラム１０４の性能情報収集部１０５は、業務処理サーバＡ及び業務処理サーバＢに対して、処理要求数とレスポンス情報を送信するよう通知する。業務処理サーバＡ及び業務処理サーバＢは、性能情報収集部１０５から通知を受信すると、定期的に採取していた処理要求数とレスポンス時間を、単位時間当たりの処理要求数と平均レスポンス時間に情報集約したうえで管理サーバ１０３に通知する。

また、定義変更処理部１０７は、業務処理サーバＡに対し、ミドルウェアＡにおける、アプリケーションＡからの処理を受け付けるプロセス（スレッド）の多重度と、アプリケーションＢからの処理を受け付けるプロセス（スレッド）の多重度を変更するよう通知する。また、定義変更処理部１０７は、業務処理サーバＢに対し、ミドルウェアＢにおける、ミドルウェアＡからの処理を受け付けるプロセス（スレッド）の多重度の変更を実施するよう通知する。

性能情報収集と多重度の変更の通知は、いずれも、管理サーバ１０３から業務処理サーバＡ、Ｂに対し、リモート呼び出しでコマンドを発行する方式で実行される。この方式には、例えば、設定値を変更する対象のミドルウェアやアプリケーションが提供するパフォーマンス情報表示や定義変更コマンドのインターフェースを利用した操作、または、ＯＳのコマンドを使用したパフォーマンス情報採取や定義ファイルの編集等がある。また、性能情報収集と多重度の変更の通知で実行するコマンドなどの情報は、ノード定義１０９のコマンド３０３に記憶されている。

本実施形態における性能情報収集と多重度の変更操作は、既存のミドルウェアやアプリケーションが提供するインターフェースを用いる方式のため、既存の業務システムに対する改造を加えることなく導入する事が可能である。

次に、ソフトウェアの処理性能の低下、すなわち性能障害の予兆検出方法について説明する。

図８で説明したように、各業務処理サーバは、各ミドルウェア及びアプリケーション単位に、発生した処理要求とその処理要求に対してかかったレスポンス時間を定期的に採取しておく。

性能情報収集部１０５は、定期的に、各サーバに記録されたソフトウェア毎の、単位時間当たりの処理要求数と平均レスポンス時間を取得する。尚、平均レスポンス時間は、区間毎に最新の所定サイズ分（例えば100回）が保持され、古い情報は破棄される。

そして、性能情報収集部１０５は、取得した単位時間当たりの処理要求数と平均レスポンス時間を用いて、処理要求数の代表値と、その代表値に対応するように補正した平均レスポンス情報を算出する。

ここで、処理要求数の代表値について図９を参照して説明する。図９は、処理要求数の代表値と平均レスポンス時間の一例を示す図である。

図９は、性能情報収集部１０５が取得した単位時間当たりの処理要求数を横軸とし、平均レスポンス時間を縦軸にとったグラフである。図９に示すように、横軸を所定の間隔で分割した処理要求区間を定義する。各処理要求区間の幅は、対象のソフトウェアの多重度を予め定められた区間数で割った値である。例えば、図９の例では、ソフトウェアの多重度が100であり、予め定められた区関数が10とすると、各処理要求区間の幅は100÷10＝10となる。すると、0〜10、10〜20、・・・、50〜60、60〜70要求/秒の処理要求区間が設定される。尚、処理要求区間は、処理要求区間値の幅で、多重度を超えて区間作成が可能である。尚、多重度が変更されると、性能情報収集部１０５により処理要求区間の幅も変更される。

このように、多重度の観点で単位時間当たりの処理要求数の計測区間（刻み幅）を決定するのは、以下の理由による。すなわち、様々な規模（負荷大／小）に適用されるシステムにおいて、固定の刻み幅や導入するミドルウェア（機能）の最大多重度を任意の数で分割する刻み幅では、適用するシステム規模に相応した負荷範囲の区切りとならない場合があるからである。

例えば、図１０に示すように、性能評価を行う区間の一部にしかデータが計測されない場合がある。図１０は、システムの設定値は多重度=50であるが、ミドルウェアが許容する最大同時接続数（250）の固定値をもとに10分割した例である。図１０に示すように、一部の区間にしかデータが計測されない。

また、例えば、図１１に示すように、評価区間が狭すぎてレスポンス増分特性を捉えられない場合がある。図１１は、当初多重度=50のシステムが多重度=250多重に拡張された場合に、当初の区間幅のまま細分された固定値で計測を行う例である。多重度が拡張された後も、当初の区間幅のままであるため、区間幅が狭く、区間にデータが計測されたとしても、マクロ的なレスポンス増分特性を捉えられない。

さらに、例えば、図１２に示すように、評価区間が広すぎて集計対象の性能情報を削減できない例がある。図１２は、多重度=200をもとに4分割の区間幅で計測を行う例である。この場合は、区間幅が広すぎるため、評価区間が全区間に及び集計対象の性能情報を削減できない。

本実施形態では、多重度の観点で単位時間当たりの処理要求数の計測区間を決定しているので、システム規模の拡大または縮小に応じ、適切な処理要求区間の区間幅に自動調整することができる。

これまでの実績から、設定した多重度の10分割程度の刻み幅が好適な計測区間数と判明している。

このように定義された処理要求区間において、処理要求区間毎に代表値が設定される。代表値は、各処理要求区間の中央に設定される。すなわち、図９の例では、区間0〜10の代表値は5、区間10〜20の代表値は15、・・・、区間50〜60の代表値は55、区間60〜70の代表値は65のように設定される。以上が代表値の説明である。尚、代表値は各処理要求区間の中央に限定されず、要求区間のうちの所定の値としてもよい。

性能情報収集部１０５は、先ず、取得した処理要求数が含まれる要求区間の代表値を求める。そして、性能情報収集部１０５は、レスポンス補正値を以下の式により算出する。
レスポンス補正値(秒)＝取得したレスポンス時間(秒)×（代表値÷取得した単位時間当たりの処理要求数）

例えば、図９の例において、取得した処理要求数が54.7［処理要求数/秒］の場合、この値は、処理要求区間50〜60［処理要求数/秒］に含まれるので、区間代表値は55になる。すると、レスポンス補正値は、取得したレスポンス時間に55/54.7を掛けた値となる。尚、性能情報の収集回数が多ければほぼ中央値になるので、誤差が少なくなる。

次に、性能情報収集部１０５は、各処理要求区間の直前の区間からの平均レスポンス時間の増分値（傾き）を求める。尚、以下の説明では、各処理要求区間のうち、最も代表値が小さい区間を初回区間、２番目に代表値が小さい区間を第２区間、最も代表値が大きい区間を最終区間と記す。

図９の例を参照すると、初回区間（処理要求数の代表値が5の区間）から最終区間（処理要求数の代表値が65の区間）までの増分は、それぞれ、0.2、0.1、0.3、0.1、0.2、1秒である。

次に、性能診断部１０６は、各区間の増分値と第２区間の増分値との比率が閾値以上であるか否かを判定する。この閾値は、処理ルート定義１０８の性能限界判断比率２０４の値である。そして、各区間の増分値と第２区間との増分値の比率が、性能限界判断比率以上であると判定した場合は、性能診断部１０６はソフトウェアに性能障害が発生していると判定する。

図９の例を参照すると、15要求/秒に達した時の増分が0.2秒であり、65要求/秒に達した時の増分が1秒であるので、代表値が65の区間の増分比率は5倍である。この増分比率が性能限界判断比率以上である場合、性能診断部１０６はソフトウェアに性能障害が発生していると判定する。

性能診断部１０６は、ソフトウェアに性能障害が発生していると判定すると、定義変更処理部１０７に、ソフトウェアの設定を変更（拡大）するように通知する。尚、設定値の拡大は許容限界値として設定されるＣＰＵ、メモリ等のリソース使用量より相当の余裕があることが前提で行われる。

図９に示すグラフにおいて、平均レスポンス値の傾きが急激に大きくなる特徴点が顕著となる場合もあるが、境界が顕著でない場合もある。いずれの場合も限界値をある程度超えると平均レスポンス値の傾きは増大していくため、初回区間との比較を行う事で、性能限界を確実に捉えることができる。

各区間の増分比率が性能限界判断比率以上となるのは、処理要求数の大きい区間から発生する傾向にある。よって、各区間の増分比率の算出は、最終区間もしくは最終区間に近い区間について行えばよく、それ以外の区間については、増分比率の算出を行わない。これにより、性能以上の予兆検出にかかる計算量を削減することができる。

例えば、図９の例においては、最終区間の増分比率を算出するためには、図９のグラフのすべての代表値及び平均レスポンス時間を算出せずに、最終区間とその直前の区間、第２区間と初回区間の4つの区間の平均レスポンス値を算出すれば十分である。すなわち、性能情報収集部１０５は、最終区間（代表値65）、最終区間の直前の区間（代表値55）、第２区間（代表値15）、初回区間（代表値5）の4つの区間の平均レスポンス値を取得する。そして、最終区間と第２区間の増分値を算出し、算出した値を用いて、最終区間の増分比率を算出する。

また、増分比率の算出を最終区間からどの程度の区間について行うかについては、システムに応じた性能限界検出感度の調節と誤検出防止のために種々の区間数に設定することができる。本実施形態では、警戒レベルのビット処理によって、複数区間（例えば、1〜3個）連続で条件が満たされた場合、性能限界とみなす考慮を行う。すなわち、警戒レベルを上げることにより、平均レスポンス値を取得する、最終区間の直前の複数区間の数を増加させる。

また、性能診断部１０６が単一区間のレスポンス時間拡大が見られた時に障害を検出するか、複数区間のレスポンス時間が拡大した時に障害を検出するかについては、障害の検出判断までの回数（警戒レベル）は調節可能とする。これは、システムのレスポンス保障の許容度のポリシに依存するためである。

性能診断部１０６により性能障害が検出されると、性能障害が検出されたソフトウェアの多重度を変更する処理が行われる。本実施形態では、複数サーバに跨って、変更するソフトウェアの処理に関連するソフトウェアの多重度の変更も行う。また、関連するソフトウェア間の処理の依存関係に基づいて、多重度を変更する順番を制御する。

図１３は、複数サーバを跨る多重度の変更値の算出方法を説明するための図である。図１３に示すように、複数の業務処理サーバＡ、Ｂに跨って、アプリケーションA−ミドルウェアA−ミドルウェアBと、アプリケーションB−ミドルウェアA−ミドルウェアBのルートで呼び出される処理ルートが存在するとする。そして、アプリケーションAに対して処理を受け付けるミドルウェアAの多重度を多重度Aとし、アプリケーションBに対して処理を受け付けるミドルウェアAの多重度を多重度Bとする。また、ミドルウェアAに対して処理を受け付けるミドルウェアBの多重度を多重度Cとする。このとき、各ソフトウェアの多重度は、多重度A＋多重度B≦多重度Cを満たすように設定する。この理由は、処理ルートの途中で処理待ちやボトルネックが発生し、トラブル要因となる場合を排除するためである。

図１３の例において、アプリケーションBに関わる業務処理量が増加したとする。この場合は、多重度を当初の多重度A＋多重度B：多重度Cの比率を維持するように、多重度Cの値も増加させる。例えば、当初の、多重度A、多重度B、多重度Cの値が、それぞれ、10、15、35であるとする。すると、多重度A＋多重度B：多重度Cは、10+15：35、すなわち5：7である。このとき、多重度Bが30に増加したとする。すると、多重度の比率（多重度A＋多重度B：多重度C）が5：7を維持するように、多重度Cの値を56に拡張する。

逆に、アプリケーションBの処理が減少した場合も、当初の多重度A＋多重度B：多重度Cの比率を維持するように、多重度Cの値を減少する。

ここで、多重度を変更する順番にも留意する。図１３の例において、多重度Bを15から30にいきなり変更すると、10(多重度A)＋30(多重度B)＞35(多重度C)となり、大小関係の整合が崩れてしまう。

そこで、処理ルートに存在する変更が必要な多重度のうち、呼出元よりも変更後の値が大きい呼出先から多重度の変更を実施するよう制御する。図１３の例においては、呼出先である多重度Cを先に変更し、次いで多重度Bを変更する。

逆に、多重度を減少させる場合は、変更後の値が小さい呼出元から定義変更を実施する。

尚、処理ルートにおいて位置関係が並列のノードの多重度は、例えば、すべて同じ値に設定されてもよいし、多重度の変更の順番はランダムでよい。

図１３の例は、業務処理サーバＡ、Ｂ内に、1つのミドルウェアが配置された構成であるが、業務処理サーバ内に複数のミドルウェアやアプリケーションが配置されてもよい。また、１つのミドルウェアやアプリケーション内に複数の多重度設定パラメータが存在する構成としてもよい。また、呼出先が複数に分岐する構成においても、処理ルートの呼出元または呼出先で大小関係が維持されていれば良い。

このように、複数サーバを跨って影響あるパラメータ変更を順序整合を維持し自動実施する事で、設定変更の影響範囲の調査が不要となり、構築者が退出する運用フェーズにおいても、変更漏れを防止し安全にシステムを維持する事ができる。

なお、ミドルウェアやアプリケーションよっては、起動中に多重度を変更する活性変更ができない場合がある。この場合は、図８を参照して説明したリモート呼び出しによるコマンド発行方式により、業務抑止、製品の設定値変更前後の停止または起動も同時に実施する。

次に、変更した多重度の確定について説明する。図１４は、仮定した多重度の確定方法を説明するための図である。

図９の例において多重度を増加させた結果、図１４の（１）のように、最終区間のレスポンス時間の増分値が減少したとする。この場合、最終区間の平均レスポンス時間の増分比率は閾値以下となっており、変更後の多重度は適切であると判定され、変更後の多重度の値が確定する。この場合は、性能障害の予兆が検出され、多重度が変更されることによって、性能障害を回避することができる場合である。

一方、図９の例において多重度を増加させた結果、図１４の（２）のように、最終区間のレスポンス時間の変化がほとんどなかったとする。この場合は、最終区間の平均レスポンス時間の増分比率は閾値以上のままであり、変更後の多重度は不適切であると判定される。

この場合は、定義変更処理部１０７は、関連して変更したソフトウェアの多重度を含めて変更した多重度を変更前の設定値に戻す。

多重度を変更しても効果がみられない場合は、ソフトウェアの設定に起因する性能障害ではなく、ハードウェアに起因する性能障害である可能性がある。すなわち、多重度を変更しても性能が改善しない場合は、スケールアップ、スケールアウトといったハード増強が必要と判断される。そのため、定義変更処理部１０７は、システム増強が必要である旨メッセージを出力してシステム管理者に通知する。効果のない多重度の設定を変更前の状態に戻すことによって、メモリやＣＰＵの過剰な消費を抑制する。

尚、多重度の変更後の、最終区間の増分比率を算出する方法は、図９を用いて説明したものと同様である。例えば、多重度を増加させた結果、最終区間のレスポンス時間が、(2)に示す値となった場合を説明すると、この場合は、初回区間のレスポンス増分が0.2秒であり、(2)の増分0.8秒である。よって、性能診断部１０６は、0.8/0.2を計算し、最終区間の平均レスポンス時間の増分比率が4であると算出する。

変更した多重度が適切であるか否かの判定結果に応じて、多重度を変更前の状態に戻す処理を行うため、多重度の確定前は、変更前の処理要求数とレスポンス時間の代表値、及び変更前の多重度は保持しておき判定後破棄する。確定後は新たな多重度を基準にして図８に示した方式に従って新たに性能情報を蓄積していく。

多重度を変更しても効果がみられない場合であって、負荷分散機能を導入している場合には、定義変更処理部１０７は、性能障害が検出されたノードに対する同時処理要求数を、現在の多重度未満に制限する。負荷分散の論理に、本条件を上限値として追加することで、性能障害予兆が検出されたサーバ以外に処理を振り分ける。不可分散の論理とは、例えば、例えば、ラウンドロビン、静的な重み付きラウンドロビン、最小コネクション数、最小クライアント数、最小データ通信量、最小応答時間、最小サーバ負荷に基づくものである。これによって、特定サーバでレスポンス時間が急増し業務に影響を与えるような性能障害を回避する事ができる。

また、多重度を変更した結果、性能診断部１０６は、変更した多重度の妥当性の検証を行う。すなわち、性能診断部１０６は、規定時間以上の時間、単位時間当たりの処理要求数が最終区間代表値の所定の閾値未満である場合は多重度を減少させる。これにより、多重度が大きく設定されすぎているために使用されないリソースを節約することができる。

例えば、図９の例において、一ヶ月以上、処理要求数が32.5/秒未満であった場合は多重度の値を減少させ、使用メモリやＣＰＵを少なくすることができる。

次に、性能情報収集部１０５による性能情報収集処理の手順について説明する。性能情報収集部１０５は、定期的に、各処理ルート単位の処理要求数と処理要求数あたりの平均レスポンス時間を収集し記録する処理を行う。性能情報収集処理は外部のタイマなどにより定期的に実行される処理である。

図１５は、性能情報収集部１０５による性能情報収集処理の動作フローを示す。尚、図１５のフローは、処理ルート毎に呼び出される（Ｓ６０１）ものとし、以下の図１５の説明においては、処理対象となる処理ルートを対象処理ルートと記す。

先ず、性能情報収集部１０５は、ノード定義１０９を参照して、対象の処理ルートに含まれるノードを読み込む（Ｓ６０２）。具体的には、性能情報収集部１０５は、ノード定義１０９において、対象処理ルートに対応する処理ルート定義名３０１のレコードのうちの一つのレコードを順次読み込み、そのレコードのノード名３０２及びコマンド３０３の情報を取得する。尚、Ｓ６０２〜Ｓ６０６、またはＳ６０２〜Ｓ６１１は処理ループとなっているが、１度のループで読み込まれるのは一つのレコードであり、次のループでは、未だ読み込まれていないレコードのうちの一つが読み込まれる。

Ｓ６０２において、性能情報収集部１０５は、対象処理ルートに対応する処理ルート定義名のレコードのうち、未だ読み込まれていないレコードが存在するか否かを判定する（Ｓ６０３）。未だ読み込まれていないレコードが存在しない場合（Ｓ６０３でＮｏ）、処理は、性能診断部１０６による性能診断処理に移行する（Ｓ６０４）。

Ｓ６０３において、未だ読み込まれていないレコードが存在すると判定した場合Ｓ６０３でＹｅｓ）、性能情報収集部１０５は、Ｓ６０２で取得したノード名のノードが稼動するサーバに対して、処理要求数とレスポンス情報の取得依頼を行う（Ｓ６０５）。具体的には、性能情報収集部１０５は、Ｓ６０２で取得した性能情報収集コマンドを発行することにより、処理要求数とレスポンス情報の取得依頼を行う。

サーバは、処理要求数とレスポンス情報の測定依頼を受けた場合、単位時間当たりの処理要求数と平均レスポンス時間を、測定の結果を性能情報収集部１０５に返す。そして、性能情報収集部１０５は、サーバで測定された単位時間あたりの処理要求数、及び平均レスポンス時間を受信する（Ｓ６０６）。

次に、性能情報収集部１０５は、Ｓ６０６で受信した単位時間当たりの処理要求数が、初回区間〜第２区間、もしくは、最終区間前の所定の区間〜最終区間の間にあるか否かを判定する（Ｓ６０７）。ここで、最終区間前の所定の区間は、最終区間を第N（Nは任意の整数）区間とすると、第（N−（警戒レベル＋1））の区間であらわされる区間のことである。この警戒レベルは、平均レスポンステーブル５００の警戒レベル情報５０６の値である。尚、警戒レベルの値は0以上の整数とする。

Ｓ６０６で受信した処理要求数が、初回区間〜第２区間、及び、最終区間前の所定の区間〜最終区間の間にないと判定された場合は（Ｓ６０７でＮｏ）、処理はＳ６０２に遷移する。初回区間〜第２区間、及び、最終区間前の所定の区間〜最終区間の間にない場合は、Ｓ６０８〜Ｓ６１１の処理を行わないことで、処理コストを削減できる。尚、性能情報収集部１０５は、Ｓ６０５における性能情報の取得依頼の際、処理要求数が、初回区間〜第２区間、及び、最終区間前の所定の区間〜最終区間の間にない場合は、性能情報を性能情報収集部１０５へ返信しないように指示してもよい。

Ｓ６０７において、Ｓ６０６で受信した処理要求数が、初回区間〜第２区間、もしくは、最終区間前の所定の区間〜最終区間にあると判定された場合は（Ｓ６０７でＹｅｓ）、性能情報収集部１０５は、Ｓ６０６で受信した平均レスポンス時間を補正する（Ｓ６０８）。すなわち、性能情報収集部１０５は、Ｓ６０６で受信した処理要求数が含まれる処理要求区間の区間代表値を算出し、その区間代表値に応じて、Ｓ６０６で受信した平均レスポンス時間を補正する。尚、以下の説明では、Ｓ６０６で受信した処理要求数が含まれる処理要求区間の区間代表値を対象区間代表値と記し、補正した平均レスポンス時間を補正レスポンス情報と記す場合がある。

次に、性能情報収集部１０５は、対象区間代表値に対応する過去に測定されたレスポンス情報と、補正レスポンス情報を用いて、対象区間代表値の平均レスポンス情報を算出する（Ｓ６０９）。具体的には、性能情報収集部１０５は、平均レスポンステーブル５００から、処理ルート定義名５０１が対象処理ルートであり、ノード名５０２がＳ６０２で取得したノード名であるレコードのうち、区間代表値５０３が対象区間代表値に等しいレコードを抽出する。そして、性能情報収集部１０５は、抽出したレコードの平均レスポンス５０４と、補正レスポンス情報を用いて、補正レスポンス情報を平均値の算出の際に加えた、新たな平均レスポンス情報を算出する。尚、平均レスポンス情報は、最大で、処理要求数履歴情報において、処理ルート定義、ノード名、区間代表値の組み合わせにおいて、保持することが可能なレコード数の平均値となる。

次に、性能情報収集部１０５は、補正レスポンス情報と、対象区間代表値の前後の平均レスポンス情報との間の差分（傾き）を算出する（Ｓ６１０）。具体的には、差分は以下の式により算出される。
差分（傾き）＝｜（対象区間代表値の前（または後）の区間代表値の平均レスポンス値(秒)−補正レスポンス値(秒)）｜／処理要求区間の幅

次に、性能情報収集部１０５は、Ｓ６０６で受信した情報を履歴情報４００に格納し、Ｓ６０９で算出した補正レスポンス情報と、Ｓ６１０で算出した差分情報を平均レスポンステーブル５００に格納する（Ｓ６１１）。具体的には、性能情報収集部１０５は、履歴情報４００に新たなレコードを作成し、そのレコードの各項目に対応する情報を格納する。すなわち、性能情報収集部１０５は、処理ルート定義名４０１に対象処理ルートの識別情報を、ノード名４０２にＳ６０２で取得したノード名を、履歴番号４０３に初期値（例えば1等）を格納する。また、性能情報収集部１０５は、取得時刻４０４、処理要求数４０５、レスポンス時間４０６に、それぞれ、Ｓ６０６で情報を受信した時刻、Ｓ６０６で受信した単位時間当たりの処理要求数、Ｓ６０６で受信した平均レスポンス時間を格納する。また、性能情報収集部１０５は、平均レスポンステーブル５００において、処理ルート定義名５０１が対象処理ルートであり、ノード名５０２がＳ６０２で取得したノード名であり、区間代表値５０３が対象区間代表値に等しいレコードを抽出する。そして、性能情報収集部１０５は、抽出したレコードの平均レスポンス５０４にＳ６０９で算出した補正レスポンス情報を格納し、差分情報５０５に、Ｓ６１０で算出した差分情報を格納する。

そして、処理は、Ｓ６０２に遷移する。
次に、性能診断部１０６の性能障害の予兆検出処理手順について説明する。

性能診断部１０６は、性能情報収集部１０５から呼び出されると、収集した性能情報を元に、性能障害の予兆を検出する。予兆を検出すると、性能診断部１０６は、定義変更処理部１０７に、多重度を変更するための対象の処理ルート定義番号と処理を渡す。

処理要求数の増加に伴い、最終区間の位置が変化した場合は、新しい最終区間の情報を書き込む際に、収集対象区間外となった履歴情報や平均レスポンステーブルの格納情報は破棄する。

図１６は、性能診断部１０６の性能障害の予兆検出処理の動作フローを示す。
図１６のＳ６０４において、性能情報収集部１０５から通知を受けると（Ｓ７０１）、先ず、性能診断部１０６は、平均レスポンステーブル５００から、対象処理ルートの区間代表値毎の差分情報５０５を順番に読み込む（Ｓ７０２）。ここで読み込んだ差分情報５０５に対応する区間代表値５０３の区間を、以下の説明では対象区間と記す。尚、Ｓ７０２〜Ｓ７１３は処理ループとなっているが、１度のループで読み込まれるのは一つの対象処理ルートの区間代表値毎の差分情報あり、次のループでは、未だ読み込まれていない対象処理ルートの区間代表値毎の差分情報のうちの一つが読み込まれる。

Ｓ７０２において、読み込み対象の差分情報５０５が存在したか否かを、性能診断部１０６は判定する（Ｓ７０３）。読み込み対象の差分情報５０５が存在しなかった場合（Ｓ７０３でＮｏ）、処理は終了する（Ｓ７０４）。尚、読み込み対象の差分情報５０５が存在しなかった場合とは、言い換えると、対象処理ルートにおいて記録されたすべての差分情報５０５の読み込みが終了した場合である。

読み込み対象の差分情報５０５が存在した場合（Ｓ７０３でＹｅｓ）、性能診断部１０６は、対象区間のレスポンス増分比率を算出し、算出した増分比率が所定の閾値である性能限界判断比率以上であるか否かを判定する（Ｓ７０５）。対象区間の増分比率の算出は、Ｓ７０２で読み込んだ差分情報を第２区間の差分情報で割ることにより算出される。尚、閾値として使用される性能限界判断比率は、処理ルート定義１０８において、処理ルート定義名２０１が対象処理ルートであるレコードの性能限界判断比率２０４の値である。

対象区間の増分比率が性能限界判断比率以上である場合（Ｓ７０５でＹｅｓ）、性能診断部１０６は、警戒レベルを引き上げる（1加算する）（Ｓ７０６）。すなわち、性能診断部１０６は、平均レスポンステーブル５００において、処理ルート定義名５０１が対象処理ルートであるレコードの警戒レベル情報５０６の値を取得し、取得した値に1加算する。そして、処理はＳ７０８に遷移する。

対象区間の増分比率が性能限界判断比率未満である場合（Ｓ７０５でＮｏ）、性能診断部１０６は、警戒レベルを0に初期化する（Ｓ７０７）。すなわち、性能診断部１０６は、平均レスポンステーブル５００において、処理ルート定義名５０１が対象処理ルートであるレコードの警戒レベル情報５０６の値を0に更新する。この警戒レベルの初期化は、警戒レベル設定時の異常レスポンスは一時的なものであり今後の業務性能に影響を与えない可能性があることを考慮して行うものである。

次に、性能診断部１０６は、平均レスポンステーブル５００の対象処理ルートの対象ノードの警戒レベル情報５０６を、Ｓ７０６またはＳ７０７で変更した値に更新する（Ｓ７０８）。

次に、性能診断部１０６は、Ｓ７０６またはＳ７０７で変更した警戒レベルが定義変更実施警戒レベル以下か否かを判定する（Ｓ７０９）。定義変更対象警戒レベルは、対象処理ルートに対応する処理ルート定義１０８の定義変更実施警戒レベル２０５の情報である。

変更した警戒レベルが定義変更実施警戒レベル以下である場合（Ｓ７０９でＹｅｓ）、処理はＳ７０２に遷移する。

変更した警戒レベルが定義変更実施警戒レベルより大きい場合（Ｓ７０９でＮｏ）、性能診断部１０６は、対象処理ルートの定義変更フラグ５０７の値が1であるか否かを判定する（Ｓ７１０）。

対象処理ルートの定義変更フラグ５０７の値が1である場合（Ｓ７１０でＹｅｓ）、性能診断部１０６は、定義変更処理による性能改善の効果がないと判断し、性能頭打ちである旨の通知処理を行う（Ｓ７１１）。尚、定義変更フラグ５０７の値が1であることは、既に一度多重度の変更が行われていることを示している。そして、処理は終了する（Ｓ７１４）。

対象処理ルートの定義変更フラグ５０７の値が1でない場合（Ｓ７１０でＮｏ）、性能診断部１０６は、定義変更処理部１０７に対して、ノードで性能障害の予兆が検出されたことを通知する。すなわち、性能診断部１０６は、定義変更処理部１０７に対して、Ｓ７０２で読み込んだレコードの処理ルート定義名５０１のノード名５０２のノードで性能障害の予兆が検出されたとして多重度の変更をするように通知する（Ｓ７１２）。具体的には、性能診断部１０６は、対象処理ルートの処理ルート定義名と多重度の増分比率を引数にして定義変更処理部１０７を呼び出す。ここで、多重度の増分比率は、処理ルート定義１０８において処理ルート定義名２０１が対象処理ルートであるレコードの多重度増分比率２０２の値である。

次に、性能診断部１０６は、処理ルート定義１０８における、平均レスポンステーブル５００の定義変更フラグ５０７を1に変更する（Ｓ７１３）。さらに、性能診断部１０６は、Ｓ７０２で読み込んだレコードの平均レスポンス５０４の値をクリアする。これは多重度変更後のレスポンス観察を行うためであり、全ての処理要求区間の平均レスポンス５０４をクリアしないのは、多重度変更前との差分を監察するためである。そして、処理はＳ７０２に遷移する。

尚、Ｓ７１１において、一度定義変更処理が行われた後で、その定義変更処理に効果があるか否かを確認するための処理が行われる場合は、変更した多重度を変更前の多重度に戻すように、性能診断部１０６は定義変更処理部１０７に通知してもよい。

次に、定義変更処理部１０７による多重度変更処理について説明する。図１７は、定義変更処理部１０７による多重度変更処理の動作フローを示す。

定義変更処理部１０７は、性能診断部１０６からの性能障害が発生していると判断された処理ルート定義名、多重度増減比率の通知（Ｓ７１２）をトリガに処理を開始する（Ｓ８０１）。多重度増減比率は性能診断部１０６から通知される値であり、増加の場合は1.2、減少の場合は0.7といった、処理ルート毎に予め定義された調整可能な値を元に設定される。

定義変更処理部１０７は、通知された処理ルート定義名、多重度増減比率を元に、処理ルート定義から、対象処理ルートに含まれるノードの関係（呼出元と呼出先）を把握し、各ノードの変更後の多重度を算出する（Ｓ８０２）。変更後の多重度は、現多重度にＳ７１２で通知された多重度増減比率を掛けることにより算出する。

そして、定義変更処理部１０７は、算出した各ノードの多重度を多重度管理表として管理する。多重度管理表は、図１７における多重度変更処理において用いられる作業用の情報である。図１８は、多重度管理表の構成の一例を示す。説明のために多重度管理表を用いるとしたが、これに限定されない。

多重度管理表９００は、処理ルート定義名９０１、ノード名９０２、多重度変更のコマンド９０３、現多重度９０４、及び変更後多重度９０５を含む。処理ルート定義名９０１、ノード名９０２、及び現多重度９０４は、それぞれ、ノード定義１０９における、処理ルート定義名３０１、ノード名３０２、現多重度３０４と同様である。また、多重度変更のコマンド９０３は、ノード定義１０９におけるコマンド３０３に含まれる多重度変更コマンドと同様である。変更後多重度９０５は、処理ルート定義名９０１のノード名９０２で示されるノードの変更後の多重度を示す情報である。処理ルート定義名９０１、ノード名９０２、多重度変更のコマンド９０３、及び現多重度９０４は、ノード定義１０９から対象処理ルートのレコードの対応する情報が格納される。変更後多重度９０５は、Ｓ８０２で算出した変更後の多重度が格納される。

次に、定義変更処理部１０７は、Ｓ８０１で通知された多重度増減比率が１より大きいか否かを判定する（Ｓ８０３）。多重度増減比率が１より大きい場合（Ｓ８０３でＹｅｓ）、定義変更処理部１０７は、多重度管理表９００のレコードに対して、ノード名の１次キーの降順にレコードを並べ替える（Ｓ８０４）。その後、処理はＳ８０６に遷移する。

Ｓ８０３において、多重度増減比率が１以下である場合（Ｓ８０３でＮｏ）、定義変更処理部１０７は、多重度管理表９００のレコードに対して、ノード名の１次キーの昇順にレコードを並べ替える（Ｓ８０５）。

次に、定義変更処理部１０７は、多重度管理表９００のレコードを１次キーの順に読み出す（Ｓ８０６）。尚、Ｓ８０６〜Ｓ８１１は、ループ処理となっているが、Ｓ８０６では、１度のループにおいて、数字が同じ１次キーのレコードが読み出される。

次に、Ｓ８０６で読み出したレコードのうち、定義変更処理部１０７は、多重度管理表９００の２次キーを指定してレコードを読み出す（Ｓ８０７）。尚、Ｓ８０７〜Ｓ８０９は、ループ処理となっているが、１度のループにおいて、Ｓ８０７では、２次キーが異なるレコードが１つずつ読み出される。

次に、定義変更処理部１０７は、Ｓ８０７で読み込んだレコードのノード名のノードに対して、多重度の変更処理を行う（Ｓ８０８）。具体的には、定義変更処理部１０７は、多重度管理表９００の多重度変更のコマンド９０３を参照し、そのコマンドを用いて、ノード名９０２のノードの多重度を変更後多重度９０５の多重度に変更する処理を行う。

そして、定義変更処理部１０７は、Ｓ８０６で読み出したレコードのうち、次の２次キーのレコード（未読の２次キーのレコード）が存在するか否かを判定する（Ｓ８０９）。次の２次キーのレコードが存在すると判定された場合（Ｓ８０９でＹｅｓ）、処理はＳ８０７に遷移する。次の２次キーのレコードが存在しないと判定した場合（Ｓ８０９でＮｏ）、定義変更処理部１０７は、Ｓ８０８で発行した全てのコマンドが完了するまで待機する（Ｓ８１０）。

次に、定義変更処理部１０７は、次の１次キーのレコード（未読の１次キーのレコード）が存在するか否かを判定する（Ｓ８１１）。次の１次キーのレコードが存在すると判定された場合（Ｓ８１１でＹｅｓ）、処理はＳ８０６に遷移する。次の１次キーのレコードが存在しないと判定した場合（Ｓ８１１でＮｏ）、定義変更処理部１０７は、ノード定義１０９の対象処理ルートの各ノードの現多重度３０４と前多重度３０５の値を更新する（Ｓ８１２）。

そして、処理は性能診断部１０６の呼び出しステップ（Ｓ７１２）に復帰する（Ｓ８１３）。

復帰後は、性能診断部１０６にて変更した多重度が処理性能に対して有効であるか否かの検証が行われる。性能診断部１０６にて定義変更の効果が無いと判断された場合の定義を元に戻す場合も、同様の処理である。この場合、Ｓ７１１において、変更した多重度を変更前の多重度に戻すように、性能診断部１０６は、定義変更処理部１０７に通知する。但し、Ｓ８０２において、変更前の多重度に戻すところが異なる。尚、変更前の多重度は、ノード定義１０９の前多重度３０５の値として保存されている。定義変更の効果があったと判断された場合は、性能診断部１０６にて、仮定した多重度を正式値として処理ルート定義を更新し仮定値は破棄する。これら多重度の確定時には、処理要求区間の幅はリセットされ、履歴情報４００及び平均レスポンステーブル５００は破棄され、定義変更フラグ５０７も0に戻される。

尚、Ｓ８０２において、変更後の多重度がノード定義１０９の最大多重度３０６を超える場合は、変更後の多重度は最大多重度とする。その場合、最大多重度に到達した旨を通知する処理をおこなってもよい。

図１９は、本実施形態に係る管理サーバ１０３、及び業務処理サーバ１０１、１０２のハードウェア構成の一例を示す。管理サーバ１０３、業務処理サーバ１０１、１０２は、図１９に示すように、ＣＰＵ１００１、メモリ１００２、記憶装置１００３、読取部１００４、通信インターフェース１００６を含む。なお、ＣＰＵ１００１、メモリ１００２、記憶装置１００３、読取部１００４、通信インターフェース１００６は、例えば、バス１００７を介して互いに接続されている。

ＣＰＵ１００１は、メモリ１００２を利用して上述のフローチャートの手順を記述したプログラム、及び、自動チューニングプログラム１０４を実行する。ＣＰＵ１００１は、管理サーバ１０３においては、性能情報収集部１０５、性能診断部１０６、定義変更処理部１０７の機能の一部または全部を提供する。業務処理サーバ１０１、１０２においては、ＣＰＵ１００１は、性能情報を定期的に採取し、記憶装置１００３に保存する。

メモリ１００２は、例えば半導体メモリであり、ＲＡＭ（Random Access Memory）領域およびＲＯＭ（Read Only Memory）領域を含んで構成される。

記憶装置１００３は、例えばハードディスクであり、管理サーバ１０３においては、処理ルート定義１０８、ノード定義１０９、処理要求数履歴１１０の情報が格納される。なお、記憶装置１００３は、フラッシュメモリ等の半導体メモリであってもよい。また、記憶装置１００３は、外部記録装置であってもよい。また、業務処理サーバ１０１、１０２においては、記憶装置１００３は、定期的に採取する性能情報を保存する領域として使用される。

読取部１００４は、ＣＰＵ１００１の指示に従って着脱可能記録媒体１００５にアクセスする。着脱可能記録媒体１００５は、たとえば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。

通信インターフェース１００６は、ＣＰＵ１００１の指示に従ってネットワークを介してデータを送受信する。通信インターフェース１００６は管理サーバ１０３においては、業務処理サーバ１０１、１０２と接続するインターフェースに対応する。業務処理サーバ１０１、１０２においては、通信インターフェース１００６は、処理要求元１１５と接続するインターフェース、及び、管理サーバ１０３と接続するインターフェースに対応する。

実施形態を実現するための自動チューニングプログラム１０４は、例えば、下記の形態で管理サーバ１０３に提供される。
（１）記憶装置１００３に予めインストールされている。
（２）着脱可能記憶媒体１００５により提供される。
（３）ネットワークを介して提供される。

尚、ＣＰＵ１００１は、例えば、ＡＳＩＣ等の回路であってもよい。
尚、本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

尚、本実施形態では例えばテスト工程において、業務で発生する処理要求数が分かるのであれば、予め性能シミュレーションを稼働前に実施して、システムが最も性能を発揮できる設定値を事前に求めたり、ハードウェア規模の妥当性を評価することも可能である。

上記実施形態に関し、更に以下の付記を開示する。
（付記１）
コンピュータに、
処理要求に対するソフトウェアの応答時間を平均化して得られる平均化応答時間を、前記ソフトウェアに対する単位時間当たりの処理要求受信数ごとに蓄積し、
第１の処理要求受信数と第２の処理要求受信数との差分に対する第１の平均化応答時間差分と、前記第２の処理要求受信数よりそれぞれ大きい第３の処理要求受信数と第４の処理要求受信数との差分に対する第２の平均化応答時間差分と、に基づいて、前記ソフトウェアの障害の予兆を検知する
処理を実行させることを特徴とする障害検知プログラム。
（付記２）
コンピュータに、
複数の前記蓄積した処理要求受信数と該処理要求受信数に対応する前記平均化応答時間を用いて、前記第１の処理要求受信数を含む第１の範囲内から、該第１の処理要求受信数の代表値である第１の代表処理要求受信数と、該第１の代表処理要求受信数に対応する第１の代表応答時間と、前記第２の処理要求受信数を含む第２の範囲内から、該第２の処理要求受信数の代表値である第２の代表処理要求受信数と、該第２の代表処理要求受信数に対応する第２の代表応答時間と、前記第３の処理要求受信数を含む第３の範囲内から、該第３の処理要求受信数の代表値である第３の代表処理要求受信数と、該第３の代表処理要求受信数に対応する第３の代表応答時間と、前記第４の処理要求受信数を含む第４の範囲内から、該第４の処理要求受信数の代表値である第４の代表処理要求受信数と、該第４の代表処理要求受信数に対応する第４の代表応答時間と、を算出し、
前記第１の代表処理要求受信数と前記第２の代表処理要求受信数との差分に対する第１の代表応答時間差分と、前記第３の代表処理要求受信数と前記第４の代表処理要求受信数との差分に対する第２の代表応答時間差分と、に基づいて、前記ソフトウェアの障害の予兆を検知する
処理を実行させることを特徴とする付記１に記載の障害検知プログラム。
（付記３）
コンピュータに、
前記第１の範囲、前記第２の範囲、前記第３の範囲、及び前記第４の範囲の幅を、前記ソフトウェアにおいて並列して実行可能な処理数を示す多重度に基づいて決定する
処理を実行させることを特徴とする付記２に記載の障害検知プログラム。
（付記４）
コンピュータに、
前記ソフトウェアの障害の予兆を検知した場合、前記ソフトウェアの多重度を変更する
処理を実行させることを特徴とする付記１〜３のうちいずれか１項に記載の障害検知プログラム。
（付記５）
コンピュータに、
前記ソフトウェアの障害の予兆を検知した場合、前記ソフトウェアに対して処理要求を送信または受信する関連ソフトウェアの多重度と、前記ソフトウェアの多重度との比率に基づいて、前記関連ソフトウェアの多重度を変更する
処理を実行させることを特徴とする付記１〜４のうちいずれか１項に記載の障害検知プログラム。
（付記６）
コンピュータに、
前記ソフトウェアの多重度を変更した後に、再び前記障害の予兆を検知した場合、前記変更した多重度を変更前の多重度に戻す
処理を実行させることを特徴とする付記４または５に記載の障害検知プログラム。
（付記７）
コンピュータに、
前記ソフトウェアの障害の予兆を検知した場合、前記ソフトウェアに対して処理要求を送信または受信する関連ソフトウェアの多重度と、前記ソフトウェアの多重度との比率が変化しない順番で、前記ソフトウェアと前記関連ソフトウェアの多重度を変更する
処理を実行させることを特徴とする付記５に記載の障害検知プログラム。
（付記８）
処理要求に対するソフトウェアの応答時間を平均化して得られる平均化応答時間を、前記ソフトウェアに対する単位時間当たりの処理要求受信数ごとに蓄積し、
第１の処理要求受信数と第２の処理要求受信数との差分に対する第１の平均化応答時間差分と、前記第２の処理要求受信数よりそれぞれ大きい第３の処理要求受信数と第４の処理要求受信数との差分に対する第２の平均化応答時間差分と、に基づいて、前記ソフトウェアの障害の予兆を検知する
ことを特徴とする障害検知方法。
（付記９）
複数の前記蓄積した処理要求受信数と該処理要求受信数に対応する前記平均化応答時間を用いて、前記第１の処理要求受信数を含む第１の範囲内から、該第１の処理要求受信数の代表値である第１の代表処理要求受信数と、該第１の代表処理要求受信数に対応する第１の代表応答時間と、前記第２の処理要求受信数を含む第２の範囲内から、該第２の処理要求受信数の代表値である第２の代表処理要求受信数と、該第２の代表処理要求受信数に対応する第２の代表応答時間と、前記第３の処理要求受信数を含む第３の範囲内から、該第３の処理要求受信数の代表値である第３の代表処理要求受信数と、該第３の代表処理要求受信数に対応する第３の代表応答時間と、前記第４の処理要求受信数を含む第４の範囲内から、該第４の処理要求受信数の代表値である第４の代表処理要求受信数と、該第４の代表処理要求受信数に対応する第４の代表応答時間と、を算出し、
前記第１の代表処理要求受信数と前記第２の代表処理要求受信数との差分に対する第１の代表応答時間差分と、前記第３の代表処理要求受信数と前記第４の代表処理要求受信数との差分に対する第２の代表応答時間差分と、に基づいて、前記ソフトウェアの障害の予兆を検知する
ことを特徴とする付記８に記載の障害検知方法。
（付記１０）
前記第１の範囲、前記第２の範囲、前記第３の範囲、及び前記第４の範囲の幅を、前記ソフトウェアにおいて並列して実行可能な処理数を示す多重度に基づいて決定する
ことを特徴とする付記９に記載の障害検知方法。
（付記１１）
前記ソフトウェアの障害の予兆を検知した場合、前記ソフトウェアの多重度を変更する
ことを特徴とする付記８〜１０のうちいずれか１項に記載の障害検知方法。
（付記１２）
処理要求に対するソフトウェアの応答時間を平均化して得られる平均化応答時間を、前記ソフトウェアに対する単位時間当たりの処理要求受信数ごとに蓄積する蓄積部と、
第１の処理要求受信数と第２の処理要求受信数との差分に対する第１の平均化応答時間差分と、前記第２の処理要求受信数よりそれぞれ大きい第３の処理要求受信数と第４の処理要求受信数との差分に対する第２の平均化応答時間差分と、に基づいて、前記ソフトウェアの障害の予兆を検知する検知部と、
を備えることを特徴とする情報処理装置。
（付記１３）
前記情報処理装置は、さらに、
複数の前記蓄積された処理要求受信数と該処理要求受信数に対応する前記平均化応答時間を用いて、前記第１の処理要求受信数を含む第１の範囲内から、該第１の処理要求受信数の代表値である第１の代表処理要求受信数と、該第１の代表処理要求受信数に対応する第１の代表応答時間と、前記第２の処理要求受信数を含む第２の範囲内から、該第２の処理要求受信数の代表値である第２の代表処理要求受信数と、該第２の代表処理要求受信数に対応する第２の代表応答時間と、前記第３の処理要求受信数を含む第３の範囲内から、該第３の処理要求受信数の代表値である第３の代表処理要求受信数と、該第３の代表処理要求受信数に対応する第３の代表応答時間と、前記第４の処理要求受信数を含む第４の範囲内から、該第４の処理要求受信数の代表値である第４の代表処理要求受信数と、該第４の代表処理要求受信数に対応する第４の代表応答時間と、を算出する算出部と、
を備え、
前記検知部は、前記第１の代表処理要求受信数と前記第２の代表処理要求受信数との差分に対する第１の代表応答時間差分と、前記第３の代表処理要求受信数と前記第４の代表処理要求受信数との差分に対する第２の代表応答時間差分と、に基づいて、前記ソフトウェアの障害の予兆を検知する
ことを特徴とする付記１２に記載の情報処理装置。
（付記１４）
前記情報処理装置は、さらに、
前記第１の範囲、前記第２の範囲、前記第３の範囲、及び前記第４の範囲の幅を、前記ソフトウェアにおいて並列して実行可能な処理数を示す多重度に基づいて決定する決定部
を備えることを特徴とする付記１３に記載の情報処理装置。
（付記１５）
前記情報処理装置は、さらに、
前記ソフトウェアの障害の予兆が検知された場合、前記ソフトウェアの多重度を変更する変更部
を備えることを特徴とする付記１２〜１４のうちいずれか１項に記載の情報処理装置。

１００ 情報処理システム
１０１、１０２ 業務処理サーバ
１０３ 管理サーバ
１０４ 自動チューニングプログラム
１０５ 性能情報収集部
１０６ 性能診断部
１０７ 定義変更処理部
１０８ 処理ルート定義
１０９ ノード定義
１１０ 処理要求数履歴
１１１ 情報処理システム
１１２ アプリケーションプログラム
１１３ アプリケーション
１１４ ミドルウェア
１１５ 処理要求元
１１６ 端末装置

Claims (9)

1. コンピュータに、
   処理要求に対するソフトウェアの応答時間を平均化して得られる平均化応答時間を、前記ソフトウェアに対する単位時間当たりの処理要求受信数ごとに蓄積し、
   第１の処理要求受信数と第２の処理要求受信数との差分に対する第１の平均化応答時間差分と、前記第１の処理要求受信数および前記第２の処理要求受信数よりそれぞれ大きい第３の処理要求受信数と第４の処理要求受信数との差分に対する第２の平均化応答時間差分と、に基づいて、前記ソフトウェアの障害の予兆を検知する
   処理を実行させることを特徴とする障害検知プログラム。
2. コンピュータに、
   複数の前記蓄積した処理要求受信数と該処理要求受信数に対応する前記平均化応答時間を用いて、前記第１の処理要求受信数を含む第１の範囲内から、該第１の処理要求受信数の代表値である第１の代表処理要求受信数と、該第１の代表処理要求受信数に対応する第１の代表応答時間と、前記第２の処理要求受信数を含む第２の範囲内から、該第２の処理要求受信数の代表値である第２の代表処理要求受信数と、該第２の代表処理要求受信数に対応する第２の代表応答時間と、前記第３の処理要求受信数を含む第３の範囲内から、該第３の処理要求受信数の代表値である第３の代表処理要求受信数と、該第３の代表処理要求受信数に対応する第３の代表応答時間と、前記第４の処理要求受信数を含む第４の範囲内から、該第４の処理要求受信数の代表値である第４の代表処理要求受信数と、該第４の代表処理要求受信数に対応する第４の代表応答時間と、を算出し、
   前記第１の代表処理要求受信数と前記第２の代表処理要求受信数との差分に対する第１の代表応答時間差分と、前記第３の代表処理要求受信数と前記第４の代表処理要求受信数との差分に対する第２の代表応答時間差分と、に基づいて、前記ソフトウェアの障害の予兆を検知する
   処理を実行させることを特徴とする請求項１に記載の障害検知プログラム。
3. コンピュータに、
   前記第１の範囲、前記第２の範囲、前記第３の範囲、及び前記第４の範囲の幅を、前記ソフトウェアにおいて並列して実行可能な処理数を示す多重度に基づいて決定する
   処理を実行させることを特徴とする請求項２に記載の障害検知プログラム。
4. コンピュータに、
   前記ソフトウェアの障害の予兆を検知した場合、前記ソフトウェアの多重度を変更する
   処理を実行させることを特徴とする請求項１〜３のうちいずれか１項に記載の障害検知プログラム。
5. コンピュータに、
   前記ソフトウェアの障害の予兆を検知した場合、前記ソフトウェアに対して処理要求を送信または受信する関連ソフトウェアの多重度と、前記ソフトウェアの多重度との比率に基づいて、前記関連ソフトウェアの多重度を変更する
   処理を実行させることを特徴とする請求項１〜４のうちいずれか１項に記載の障害検知プログラム。
6. コンピュータに、
   前記ソフトウェアの多重度を変更した後に、再び前記障害の予兆を検知した場合、前記変更した多重度を変更前の多重度に戻す
   処理を実行させることを特徴とする請求項４または５に記載の障害検知プログラム。
7. コンピュータに、
   前記ソフトウェアの障害の予兆を検知した場合、前記ソフトウェアに対して処理要求を送信または受信する関連ソフトウェアの多重度と、前記ソフトウェアの多重度との大小関係が変化しない順番で、前記ソフトウェアと前記関連ソフトウェアの多重度を変更する
   処理を実行させることを特徴とする請求項５に記載の障害検知プログラム。
8. 処理要求に対するソフトウェアの応答時間を平均化して得られる平均化応答時間を、前記ソフトウェアに対する単位時間当たりの処理要求受信数ごとに蓄積し、
   第１の処理要求受信数と第２の処理要求受信数との差分に対する第１の平均化応答時間差分と、前記第１の処理要求受信数および前記第２の処理要求受信数よりそれぞれ大きい第３の処理要求受信数と第４の処理要求受信数との差分に対する第２の平均化応答時間差分と、に基づいて、前記ソフトウェアの障害の予兆を検知する
   ことを特徴とする障害検知方法。
9. 処理要求に対するソフトウェアの応答時間を平均化して得られる平均化応答時間を、前記ソフトウェアに対する単位時間当たりの処理要求受信数ごとに蓄積する蓄積部と、
   第１の処理要求受信数と第２の処理要求受信数との差分に対する第１の平均化応答時間差分と、前記第１の処理要求受信数および前記第２の処理要求受信数よりそれぞれ大きい第３の処理要求受信数と第４の処理要求受信数との差分に対する第２の平均化応答時間差分と、に基づいて、前記ソフトウェアの障害の予兆を検知する検知部と、
   を備えることを特徴とする情報処理装置。

Images