JP2006209165A - 同時実行多重度調整システム及び方法 - Google Patents

Abstract

【課題】
本発明は、性能とシステム安定稼動を確保するために、システムに対するリクエストの同時実行多重度の設計を支援する多重度調整システムを提供することにある。
【解決手段】
多重度調整エージェント１１０、１１２が監視対象システム構成要素１１３、１１５を含むサブシステム１０８からリクエスト情報１１４を収集する。次に、サブシステム別多重度調整サーバ１０５は、各サブシステム１０８から収集したリクエスト情報を、構成要素とリクエストパス毎に分類・マージする。統合多重度解析サーバ１０４は、そのリクエスト情報に基づいて必要多重度を算出する。
【選択図】 図１

Description

本発明は、複数のサブシステムに分割された分散システム（特にＷｅｂシステム）において、リクエストを同時に実行することができる上限値である同時実行多重度を決めるための同時実行多重度調整システム及び方法に関する。

複数のサブシステムにより機能分割された分散システム（特にＷｅｂシステム）は、システム構成要素が多く複雑な構造となる。システムを利用するユーザからは仮想的に一つに見えるシステムであっても、サーバ側の構成は、業務の種類、開発担当部署やサブネットワーク等の論理的もしくは物理的な境界により分割されており、こうしたサブシステムと呼ばれる構成要素を組み合わせることにより、トータルなシステムを実現している。

このため、性能ボトルネック等の問題となる原因も複雑となり、連携する他システムへの影響も考慮した、適当な多重度の設計を行うことは容易ではない。一方で、システムを安定稼動させ、かつ、性能要件を満たす最適なシステム環境構築することが望ましい。すなわち、性能ボトルネックとシステム安定性の２つに対して、最適なトレードオフを考慮した設定を行うことが望ましい。

特許文献１は、性能ボトルネックを解決するために、ジョブ入力キューから同時実行可能なジョブ数（ジョブ実行多重度）を設定し、測定されたサーバ負荷量に対応してジョブ実行多重度を変更する技術を開示している。また、特許文献２は、負荷状態通知に基づいて負荷状態通知を発生したサービス計算機の中で最軽負荷のサービス計算機を求め、この最軽負荷サービス計算機と接続する技術を開示している。

特開平５−１７３８０７号公報 特開平５−１４３５５９号公報

しかし、上記の特許文献に記載された技術では、システムの状態によっては、システムの安定稼動とリソースの有効利用の両観点を満足させることができない。

例えば、特許文献１においては、ジョブのＣＰＵ利用率が大きくなれば（サーバへの負荷が大きくなれば）、ジョブ実行多重度を小さくする。ここで、Ｗｅｂシステム（などの、複数のサブシステムにより機能分割された分散システム）のようなオンラインシステムでは、ジョブの発生率もしくはジョブの投入数が小さくなる場合（サーバへの負荷が小さくなる場合）においては、ジョブ実行多重度を大きくする。しかしながら、リソース有効利用の観点を考慮すると、実際には、むしろ当該ジョブのジョブ実行多重度を小さくし、他のジョブに当該サーバリソースを割り当てる（他のジョブのジョブ実行多重度を大きくする）ことが望ましい。つまり、サーバの負荷を見ただけでは、システムの安定稼動とリソースの有効利用の両観点を満足させるようなジョブ実行多重度を決めることはできないという問題がある。

また、特許文献２では、リクエストが複数のシステム構成要素を経由する場合に、各構成要素のジョブ実行多重度を決定することができない。また、リソース不足やシステム利用者の増加によるジョブ数増大に対処することができない。

本発明の目的は、システムの安定稼動を確保する同時実行多重度（以下、単に多重度）の設計を支援する同時多重度調整システムを提供ことにある。また、本発明の他の目的は、リソース不足やシステム利用者の増加によりリクエスト発生率（単位時間当たりのリクエストの発生数）が増大した場合に対応できる同時多重度調整システムを提供することにある。

上記目的を達成するために、本発明は、監視対象システムに対するリクエストの多重度を調整する多重度調整システムであって、監視対象システムに含まれる構成要素に対するリクエストをもとに、該構成要素ごとのリクエストの多重度を判断し、前記リクエストの多重度に関する情報を前記多重度調整エージェントから取得して、前記構成要素ごとのリクエスト情報として記憶する。そして、記憶された構成要素ごとのリクエスト情報を取得し、該取得したリクエスト情報をもとに、前記構成要素ごとのリクエストの多重度を解析するとともに、該解析結果に応じて前記構成要素ごとのリクエストの多重度を変更する構成を採用する。

本発明によれば、システムの性能確保とシステム安定稼動とを両立させる最適なシステム構成およびパラメタ値を導き出すシステム設計を支援することができる。また、サーバの安定稼動を確保しつつ、サーバリソースの再配分を行うことができる。

以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。

図１は、本実施例におけるシステム構成の概要を示す。図１に示すように、同時実行多重度調整システム１０３が監視対象システム１０７を監視する構成となっている。

監視対象システム１０７は、複数のサブシステムから構成されている。これらのサブシステムは、ネットワークで接続された監視対象システム利用端末１０６により、利用することができる。図１では、複数のサブシステムのうち、サブシステム１０８の構成を示す。サブシステム１０８は、監視対象システム構成要素１１３、１１５と、監視対象システム構成要素１１３、１１５を個別に監視する複数の多重度調整エージェント１１０、１１２からなる。さらに監視対象システム構成要素１１３、１１５は、多重度を制限するためのキュー１０９、１１１を含む。また、多重度調整エージェント１１０、１１２は、監視対象システム構成要素１１３、１１５から得た情報を格納するリクエスト情報データベース１１４と接続される。

また、同時実行多重度調整システム１０３は、サブシステム別多重度調整サーバ１０５、統合多重度解析サーバ１０４からなる。サブシステム別多重度調整サーバ１０５は、サブシステムごとに設けられ、多重度調整エージェント１１０、１１２を通じて、サブシステム１０８を個別に監視し、リクエスト情報の収集を行う。統合多重度解析サーバ１０４は、複数の多重度調整サーバ１０５を統合する。多重度調整端末１０２は、統合多重度解析サーバ１０４と接続している。監視対象システム１０７の運用者１０１は、多重度調整端末１０２を通じて、統合多重度解析サーバ１０４から多重度の設計支援情報を得ることができる。

以上のように、監視対象システム構成要素１１３、１１５を個別に監視することで、各構成要素の多重度を決定するのに必要な情報を収集することで、システム全体の最適な多重度の設計作業を支援することができる。また、各製品に分散する多重度設定のための定義情報を、一箇所で製品横断的に管理することができる。

図２は、図１に示すシステムにおける処理の流れと各機能モジュールとの関係を示す概略シーケンス図である。図２の左側に示す太線で囲まれた処理が処理の概要であり、それぞれのステップの右側の点線で囲まれた処理が、それぞれの処理の詳細である。また、上段に記載された端末またはサーバ等が行う処理であることを示す。なお、本実施例において、多重度の「修正」と「変更」の定義はそれぞれ以下のとおりである。
「修正」：統合多重度解析サーバ１０４上での仮想的な多重度の設定処理であり、実際にはまだその多重度は設定されていない。
「変更」：監視対象システム１０７の構成要素の多重度を実際に設定する処理である。

図２において、まず、実測値収集処理が実行される（ステップ２０１）。具体的には、多重度調整エージェント１１０、１１２が実測値の収集処理を実行し（２０７）、監視対象システム１０７から、実際のシステム動作により発生したリクエスト関連の実測値を収集し、収集したリクエスト情報の実測値を、サブシステム別多重度調整サーバ１０５に対して送信する。次に、サブシステム別多重度調整サーバ１０５は、実測値と設定値の収集処理を実行し（２０６）、統合多重度解析サーバ１０４に対して実測値と各構成要素の多重度設定値を送信する。ステップ２０１の詳細は、後述する図１２において説明する。

ステップ２０１の次に、監視対象システム１０７のボトルネック解析処理が実行される（ステップ２０２）。具体的には、統合多重度解析サーバ１０４は、ステップ２０１においてサブシステム別多重度調整サーバ１０５から収集した情報に基づいて、ボトルネックの自動解析処理を実行する（２０８）。統合多重度解析サーバ１０４は、その解析結果を多重度調整端末１０２に送信し、多重度調整端末１０２はその解析結果情報を表示する（２０９）。ステップ２０２の詳細は、後述する図１３〜１７において説明する。

ステップ２０２の次に、多重度修正処理が実行される（ステップ２０３）。具体的には、監視対象システム運用者は、前述したボトルネック解析結果情報に基づいて適切な多重度を決定し、端末の多重度修正／変更画面３２０から多重度を修正する。多重度調整端末１０２は、監視対象システム運用者からの入力に基づき、多重度の修正指示を統合多重度解析サーバ１０４に送信する（２１０）。そして、統合多重度解析サーバ１０４は、送信された情報に基づいて、多重度の修正処理を行う（２１１）。ステップ２０３の詳細は、後述する図１８において説明する。

ステップ２０３の次に、影響解析処理が実行される（ステップ２０４）。具体的には、統合多重度解析サーバ１０４は、ステップ２０３で修正された多重度に基づいて、影響の自動解析処理を行い（２１２）、統合多重度解析サーバ１０４は、その影響解析結果を多重度調整端末１０２に送信し、多重度調整端末１０２はその影響解析結果情報を表示する（２０９）。ステップ２０４の詳細は、後述する図１９〜２２において説明する。

ステップ２０４の次に、多重度変更処理が実行される（ステップ２０５）。具体的には、監視対象システム運用者が、ステップ２０４で表示された影響解析結果情報に基づいて、多重度調整端末１０２の多重度修正／変更画面３２０に多重度を入力すると、多重度調整端末１０２は、入力された多重度変更情報を統合多重度解析サーバ１０４に送信する（２１４）。そして、統合多重度解析サーバ１０４が、サブシステム別多重度調整サーバ１０５に対して多重度変更依頼を送信し（２１５）、サブシステム別多重度調整サーバ１０５は、監視対象システム１０７の多重度設定値を引き上げた後、多重度調整エージェント１１０、１１２に多重度の変更を指示する（２１６）。ステップ２０４の詳細は、後述する図２４において説明する。

以上の処理により、各構成要素の多重度を決定するのに必要な情報収集、収集した情報に基づいてボトルネックとなる構成要素の検索（ボトルネック解析処理）、ボトルネックとなる構成要素の多重度を仮修正することにより、他の構成要素への多重度変更の影響を解析（影響解析処理）等を行うことができ、システム全体に最適な多重度の設計支援を行うことができる。また、多重度が決まれば、当該多重度を満たすように、システム構成を自動変更することが可能となる。

なお、上記ステップ２０６及び２０７における実測値や設定値の収集処理は、Ｐｕｓｈ型処理（情報発生元が取得した情報を情報収集先へ送信する処理）であるが、Ｐｕｌｌ型処理（情報収集先が、情報発生元が取得した情報を収集する処理）でもよい。Ｐｕｓｈ型処理は、リアルタイムにリクエスト情報を収集できるので、多重度を動的に最適化することで、サーバリソースを動的に再配分できるという効果がある。一方、Ｐｕｌｌ型処理は、監視対象システム運用・管理者が必要に応じて、必要な期間の多重度設計のための情報を収集して、予め固定化した最適な多重度設定値を決めることができる。このため、多重度の動的な変更によるシステムへのオーバヘッドを軽減することで、システム性能確保ができるという効果がある。

図３は、図１に示すシステム構成を詳細に示した図である。図３内の情報や定義の意味は凡例９９９９に示してある。本実施例では、ネットワークで接続された端末１０２により操作可能な統合多重度解析サーバ１０４が、サブシステム別多重度調整サーバ１０５を通じて、各サブシステム１０８を管理する構成となっている。サブシステム１０８は、ネットワークで接続された監視対象システムの構成要素１１３、１１５と、これら構成要素１１３、１１５を監視する多重度調整エージェント１１０、１１２からなっている。多重度調整エージェント１１０は、送信側の監視対象システム構成要素１１３を監視し、多重度調整エージェント１１２は、受信側の監視対象システム構成要素１１５を監視する。監視対象システムの構成要素１１３、１１５とは、具体的には、スレッド、インスタンス、負荷分散器、ＨＴＴＰデーモン、ＤＢＭＳ等の機能モジュールを指し、多重度調整エージェント１１０、１１２が、直接、多重度制御や負荷分散処理を行うことができるシステム構成要素のことをいう。なお、構成要素１１３、１１５と多重度調整エージェント１１０、１１２の包含関係が図１と図３とでは異なっているが、どちらの構成であっても本実施例の処理に本質的な相違はない。

多重度調整エージェント１１０は、送信多重度制御モジュール３０１および送信リクエスト計測モジュール３０２を含む。送信多重度制御モジュール３０１は、多重度変更処理（図２のステップ２０５）において変更された多重度設定値に基づき、受信側の監視対象システム構成要素１１５への負荷分散処理と多重度制御処理を行う。送信リクエスト計測モジュール３０２は、実測値の収集処理（図２のステップ２０７）を実行し、具体的には、取得する実測値の送信定義３０３に基づいて、送信側の監視対象システム構成要素１１３から、時間帯／リクエストパス毎の未送信リクエスト情報３０４を取得する。ここで、リクエストパスとは、システム構成要素を通過する経路を示すリクエストのパスを示す。リクエストパスを表現するデータ構造の詳細については、後述する図９において、リクエストパス定義９１８として説明する。

なお、取得する実測値の送信定義３０３は、取得すべき情報を定義した定義情報であり、後述する図９に詳細な構造を示す。時間帯／リクエストパス毎の未送信リクエスト情報３０４は、送信リクエスト計測モジュール３０２が取得した未送信のリクエストを、時間帯毎／リクエストパス毎に分類したものである。

多重度調整エージェント１１２は、受信多重度制御モジュール３０５及び受信リクエスト計測モジュール３０７を含む。受信多重度制御モジュール３０５は、受信側の監視対象システム構成要素１１５への負荷分散処理と多重度制御処理を行い、受信リクエスト計測モジュール３０７は、受信側の監視対象システム構成要素１１５へのリクエストから、時間帯／リクエストパス毎の未処理リクエスト情報３０９と時間帯／リクエストパス毎の処理済リクエスト情報３１０を取得する。

なお、自構成要素のサーバ負荷情報３０６は、受信側の監視対象システム構成要素１１５の負荷状況を示す情報である。取得する実測値の受信定義３０８は、取得すべき情報を定義した定義情報である（図９に詳細な構造を示す）。時間帯／リクエストパス毎の未処理リクエスト情報３０９は、受信リクエスト計測モジュール３０７が取得した未処理のリクエスとを、時間帯／リクエストパス毎に分類したものであり、時間帯／リクエストパス毎の処理済リクエスト情報３１０は、受信リクエスト計測モジュール３０７が取得した処理済のリクエストを、時間帯／リクエストパス毎に分類したものである。自構成要素の多重度定義３１１は、受信側の監視対象システム構成要素１１５の同時実行多重度に関する情報であり、後述する図９に詳細な構造を示す。

ここで、多重度調整エージェント１１０及び１１２の送信多重度制御モジュール、送信リクエスト計測モジュール３０２、受信多重度制御モジュール３０５及び受信リクエスト計測モジュール３０７について、詳細に説明する。

まず、送信多重度制御モジュール３０１について説明する。送信側の監視対象システム構成要素１１３が、受信側の業務ロジックを実行する構成要素１１５に対してリクエストの送信を試みると、送信多重度制御モジュール３０１は、一旦、そのリクエストをトラップする。そして、自構成要素のサーバ負荷情報３０６と自構成要素の多重度定義３１１に基づいて、そのリクエストを送信すべきか否かを判断する。送信すると判断した場合には、クラスタリングされた構成要素１１５のどの構成要素に送信すべきかを判断することで、負荷分散と多重度制御を行う。

次に、送信リクエスト計測モジュール３０２について説明する。送信多重度制御モジュール３０１が、受信したリクエストの送信は不可であると判断した場合には、送信リクエスト計測モジュール３０２は、取得する実測値の送信定義３０３に基づいて、そのリクエストの情報から必要な情報を取得する。そして、当該取得した情報を時間帯・リクエストパス毎の未送信リクエスト情報３０４に格納する。最後に、送信側の監視対象システム構成要素１１３にエラーリターンする。

次に、受信多重度制御モジュール３０５について説明する。送信側の監視対象システム構成要素１１３から、受信側の監視対象システム構成要素１１５へのリクエストが送信されると、受信多重度制御モジュール３０５は、一旦、そのリクエストをトラップする。そして、自構成要素のサーバ負荷情報３０６と自構成要素の多重度定義３１１に基づいて、そのリクエストを処理すべきか否かを判断する。処理すると判断した場合には、クラスタリングされた構成要素１１５のどの構成要素に送信すべきかを判断することで、負荷分散と多重度制御を行う。

最後に、受信リクエスト計測モジュール３０７について説明する。受信多重度制御モジュール３０５が、受信したリクエストの処理は不可と判断した場合には、受信リクエスト計測モジュール３０７は、取得する実測値の受信定義３０８に基づいて、そのリクエストの情報から必要な情報を取得する。そして、当該取得した情報を時間帯・リクエストパス毎の未処理リクエスト情報３０９に格納する。最後に、送信側の監視対象システム構成要素１１３にエラーリターンする。一方、受信多重度制御モジュール３０５が受信したリクエストを処理すべきと判断した場合は、受信リクエスト計測モジュール３０７は、取得する実測値の受信定義３０８に基づいて、そのリクエストの情報から必要な情報を取得する。そして、取得した情報を時間帯・リクエストパス毎の処理済リクエスト情報３１０に格納する。最後に、受信側の監視対象システム構成要素１１５に対して、そのリクエストを送信する。

次に、サブシステム別多重度調整サーバ１０５は、サブシステムごとのリクエスト情報を収集するサブシステム別実測値収集モジュール３１２と、多重度調整エージェント１１０、１１２に対して、多重度の変更指示を行う多重度変更指示モジュール３１５を含む。

サブシステム別実測値収集モジュール３１２は、サブシステム内部構成定義３１６に基づいて、多重度調整エージェント１１０及び１１２から、時間帯・リクエストパス毎の未送信リクエスト情報３０４と時間帯・リクエストパス毎の未処理リクエスト情報３０９を収集し、マージし、構成要素毎に分類して、構成要素・時間帯・リクエストパス毎の未到達リクエスト情報３１３に格納する。さらに、サブシステム別実測値収集モジュール３１２は、多重度調整エージェント１１０、１１２から時間帯・リクエストパス毎の処理済リクエスト情報３１０を収集し、構成要素毎に分類して、構成要素・時間帯・リクエストパス毎の処理済リクエスト情報３１４に格納する。

多重度変更指示モジュール３１５は、統合多重度解析サーバ１０４から多重度変更指示を受け付けると、多重度設定メタ定義３１７に基づいて、多重度変更対象である自構成要素の多重度定義３１１の多重度設定値を変更する。

ここで、サブシステム内部構成定義３１６は、サブシステム内の複数の構成要素間の関係と構造を記録した定義情報であり、後述する図８に詳細な構造を示す。多重度設定メタ定義３１７は、どの定義ファイルのどの項目が多重度パラメタであるのかを示す定義情報であり、後述する図９において、詳細な構造を説明する。

最後に、統合多重度解析サーバ１０４の概要を説明する。統合多重度解析サーバ１０４は、リクエスト情報を収集する実測値収集モジュール３２２、監視対象システムのボトルネック解析を行うボトルネック解析モジュール３２１、多重度を仮修正する多重度修正モジュール３２６、仮修正した多重度が監視対象システム全体におよぼす影響を解析する影響解析モジュール３２４、監視対象システムの実際の多重度設定値を実変更する多重度変更モジュール３２８からなる。

また、多重度調整エージェント１１０及び１１２の多重度制御モジュール３０１、３０５における負荷分散処理は必須ではなく、送信側もしくは受信側のどちらか一方で行うのみでもよい。また、負荷分散処理と多重度制御を行う機能は、既存のアプリケーション基盤製品により提供されることもある。なお、アプリケーション基盤を用いる場合には、多重度制御モジュール３０１、３０５は、プラグインやライブラリといった形式により、監視対象システム構成要素１１３、１１５の内部に配置されることが多い（図１の構成）。一方、新たに多重度制御モジュール３０１、３０５を実装する場合には、監視対象システム構成要素１１３、１１５の外部に配置することで実現可能である（図３の構成）。さらに、送信側での多重度制御の実装が難しければ、受信側のみにて多重度制御を行ってもよい。この場合には、送信側にて未送信リクエストが発生することはないので、送信リクエスト計測モジュール３０２は不要となる。

また、リクエスト情報を収集するタイミングについては、リクエスト計測モジュール３０２、３０７が定期的もしくはリクエストが発生する度に、サブシステム別実測値収集モジュール３１２に送信してもよく、またはサブシステム別実測値収集モジュール３１２が定期的に収集してもよい。リクエスト情報の収集は、既存のプロファイラ製品によっても実現可能である。プロファイラを用いる場合には、リクエスト計測モジュール３０２、３０７は、プラグインやライブラリとして利用、あるいはプログラム変更による埋め込みといった方法により、監視対象システム構成要素１１３、１１５の内部に配置されることが多い（図１の構成）。一方、新たにリクエスト計測モジュール３０２、３０７を実装する場合には、監視対象システム構成要素１１３、１１５の外部に配置することで実現可能である（図３の構成）。

また、自構成要素の多重度定義３１１を多重度制御モジュール３０１、３０５に反映するタイミングについては、多重度制御モジュール３０１、３０５が定期的に多重度設定値をリロードしてもよい。また、多重度変更指示モジュール３１５が多重度設定値を変更する度に、多重度制御モジュール３０１、３０５に当該多重度設定値をリロードするよう指示してもよい。ここで、処理中のリクエストに影響を与えないようにするためには、多重度設定値のリロード処理は、以下の手順で行うことが望ましい。つまり、（１）多重度制御モジュール３０１、３０５へのリクエストの受付を中断（閉塞）する。（２）処理中（仕掛り中）のリクエストの処理が全て終了するまで待機する。（３）処理中のリクエストがなくなった時点において、多重度設定値をリロードする。（４）最後に、閉塞を解除する。

以上のように、多重度制御モジュール３０１、３０５や送信リクエスト計測モジュール３０２の数を変更したり、既存製品を利用したりすることで、システムに求められる可用性や性能と監視対象システム運用・管理者の運用負荷とのバランスを考慮した構成をとることができる。このため、性能確保とシステム安定稼動とを両立させる最適なシステム構成およびパラメタ値を導き出す設計作業を支援することができるという効果がある。さらに、リクエストの収集タイミングの間隔を短くし、多重度設定値を自動更新することにより、リアルタイムにサーバリソースの動的再配分ができるという効果がある。

図４は、監視対象システム１０７の一例である銀行システム４０１の全体構成を示したシステム構成図である。銀行システム４０１などの大規模システムでは、さらに業務別に特化したサブシステムをもっており、図４では、融資システム４０２、営業店システム４０４、金利・相場システム４０３、担保・保証システム４０５が、それぞれ図１のサブシステム１０８に相当する。図４では、銀行システム４０１におけるリクエストの通過パスの一例を示しながら、銀行システム４０１の全体構造を説明していく。

監視対象システム利用端末１０６（ブラウザ）から発行されたリクエストは、融資システム４０２、もしくは営業店システム４０４を通じて、金利・相場システム４０３、もしくは担保・保証システム４０５へと到達する。担保・保証システム４０５に届いたリクエストは、担保・保証用負荷分散器４０６を通じて、担保Ｗｅｂ４０７、保証Ｗｅｂ４１１に振り分けられる。

担保Ｗｅｂ４０７に届いたリクエストは、担保サーバ４０８、担保ＤＢ４０９へと到達する。一方、保証Ｗｅｂ４１１に届いたリクエストは、保証照会スレッド４１６、保証登録スレッド４１９へと振り分けられる。保証照会スレッド４１６に届いたリクエストは、必要に応じて、給与所得者保証インスタンス４１７もしくは保証登録スレッド４１９にアクセスし、給与所得者保証インスタンス４１７はさらに保証ＤＢ４２７にアクセスする。一方、保証登録スレッド４１９に届いたリクエストは、登録ＡＰ４２０による業務処理を実行する前後もしくは最中に、必要に応じて、自営業者保証インスタンス４２３にアクセスする。

自営業者保証インスタンス４２３に届いたリクエストは、自営業者照会ＡＰ４２４もしくは自営業者登録ＡＰ４２６による業務処理を実行する前後もしくは最中に、必要に応じて、保証ＤＢ４２７にアクセスする。

なお、本実施例の銀行システム４０１では、ブラウザ、負荷分散器、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバの接続関係を図４のように記載しているが、実際の接続関係は、全て多対多とすることが可能である。また、図４の銀行システム４０１では、ブラウザからＷｅｂサーバの間をＨＴＴＰで接続する例を記載しているが、ＦＴＰ等の負荷分散器がサポートする他のプロトコルを利用してもよい。また、負荷分散器がないシステム構成も可能である。さらに、ＡＰサーバとプロセスの関係、プロセスとスレッドもしくはインスタンスの関係、スレッドもしくはインスタンスと業務ＡＰの関係も多対多とすることができる。

以上のように、本発明は、以下の図１２から図２４に示す方法を用いることにより、銀行システム４０１がどのような複雑な構成であっても、最適な多重度の設計を支援することができるという効果がある。

なお、本実施例においては、図４におけるシステム構成要素は、全て論理的に異なる要素として記載している。例えば、担保サーバ４０８と保証サーバ４１４は、論理的に異なる業務アプリケーションが稼動しているものとして記載している。したがって、ＡＰサーバのクラスタリング等の可用性向上策により同一種類のＡＰサーバが複数稼動するような物理的に分割された複数の構成要素は、全て同一構成要素とみなして、一つの構成要素として表現している。これは、クラスタリングに代表される可用性向上策は、同時に、スケールアウトによる一種の臨界多重度増加策である。本実施例のように多重度に着目して論理構成を考える（構成要素の境界を考える）ケースでは、同一構成要素としてみなすことができるためである。なお、臨界多重度とは、スループットが飽和し、サーバが安定稼動できなくなる多重度をいう。

図５から図７にかけては、ボトルネック解析後、および影響解析後に表示される結果情報の画面イメージを示す。

図５は、リクエスト発生率・多重度表示／設定画面５０１を示す。なお、リクエスト発生率とは、単位時間当たりのリクエストの発生数をいう。リクエスト発生率・多重度表示／設定画面５０１は、主に、（１）各種操作を行うツールバー５０３、（２）システム間構成定義３２９（図３）とサブシステム内部構成定義群３３０（図３）に基づいて、システムの構成要素を上位レベルから下位レベルへの階層別ツリーとして表示するシステム構成ツリー表示画面５０２、（３）システム構成ツリー表示画面５０２で選択した構成要素（＝親構成要素）の名称を表示する構成要素名称表示エリア５０８及び親構成要素の階層レベルの名称を表示する階層レベル名称表示エリア５０９、（４）同じ階層のシステムの構成要素がどのように連携しているのかを表示する連携表示画面５１３、（５）ボトルネック解析結果情報３１８（図３）もしくは影響解析結果３１９（図３）を表示する解析結果表示画面５１４、（６）多重度を修正／変更する多重度修正／変更画面５３１の各部分から構成される。以下に、それぞれの部分について詳細に説明する。

（１）ツールバー５０３は、実測値収集処理（図２のステップ２０１）を行う際に押下する実測値収集ボタン５０４、ボトルネック解析処理（図２のステップ２０２）を行う際に押下するボトルネック解析ボタン５０５、影響解析処理（図２のステップ２０４）を行う際に押下する影響解析ボタン５０６、影響解析処理（図２のステップ２０４）を特定の構成要素内の影響だけを解析する場合に押下する要素毎影響解析ボタン５０７（図５の例では、特定の構成要素として担保・保証システム６７０８が選択されている。）、どの時間帯に関する結果情報を表示したり、また表示時間帯を変更したりする場合に押下する時間帯リストボックス５１０から構成される。

なお、システム全体の影響解析処理２０４の処理時間が長い場合には、要素毎影響解析ボタン５０７を利用することにより、短い時間で、局所的な影響を把握することができ、その後、影響解析ボタン５０６を利用して、システム全体の影響を把握することで、多重度の設計作業時間を短縮する、すなわち、多重度によるシステムチューニングのためのトライ＆エラーの試行回数を少なくできるという効果がある。
（２）システム構成ツリー表示画面５０２は、システム構成要素を様々なレベル（システム、サブシステム、ノード（サーバ）、プロセス、コンポーネント（スレッドやインスタンス）、業務ＡＰ）に分類し、各構成要素間の包含関係をツリーとして表現したものである。この画面５０２内の各四角形の枠は、システムの構成要素を表現しており、上位レベルから下位レベルへと、階層が深くなるように構成要素を表示している。各枠内には、構成要素名称を表示している。この画面５０２の構成要素は、図４に示す銀行システムを例として表示している。

システム構成ツリー表示画面５０２により、監視対象システム運用・管理者は、システムの全体構造を視覚的に把握することができ、システム構造の理解を早めることで、設計作業を支援することができる。

また、システム構成ツリー表示画面５０２において、担保・保証システムアイコン６７０８は太枠線で囲まれているが、これは、担保・保証システム４０５を構成するノードレベルの構成要素（担保・保証システムの下のレベルの子構成要素）の連携状況を連携表示画面５１３に表示していることを示す。このように、連携表示画面５１３に表示されている構成要素をシステム構成ツリー表示画面５０２中で太枠線等により強調表示することで、当該構成要素のシステム全体における位置づけを視覚的に把握することができる。結果として、多重度を最適化すべき範囲を理解し易くすることで、設計作業を支援することができる。さらに、＋ボタンを押下すると、当該システム構成要素の下のレベルの子構成要素の一覧が展開され表示され、−ボタンを押下すると、当該システム構成要素の配下の子構成要素の一覧が閉じる。
（３）図５において、構成要素名称表示エリア５０８には、システム構成ツリー表示画面５０２において選択された親構成要素の名称である“担保・保証システム”が表示され、階層レベル名称表示エリア５０９には、その親構成要素の階層レベルの名称である“サブシステム”と表示されている。
（４）連携表示画面５１３は、システム構成ツリー表示画面５０２において選択された構成要素（図５の場合は、担保・保証システム６７０８）の内部構造を示す。連携表示画面５１３に表示された各構成要素にマウスのポインタを移動することで、当該構成要素の簡易情報がポップアップヒントとして表示される。例えば、保証サーバアイコン６７１４のポップアップヒント７０１には、影響解析後の保証サーバ情報が表示されている。なお、このポップアップヒント７０１の表示内容の詳細については、図６と図７において説明する。また、保証ＤＢアイコン６７２１が太枠線になっているのは、当該構成要素に関する詳細な解析結果が解析結果表示画面５１４に表示されていることを示す。

連携表示画面５１３により、多重度変更の影響が及ぶ可能性のある範囲を視覚的に把握することができる。結果として、多重度を最適化すべき範囲を理解し易くすることで、設計作業を支援することができる。また、このように、解析結果表示画面５１４に表示されている構成要素を連携表示画面５１３中で太枠線等により強調表示することで、当該構成要素の親構成要素中における位置づけを視覚的に把握することができる。結果として、多重度を最適化すべき範囲を理解し易くすることで、設計作業を支援することができる。
（５）解析結果表示画面５１４には、連携表示画面５１３にて選択された保証ＤＢアイコン６７２１に該当する保証ＤＢ４２７（図４）の解析結果を示す。ボトルネック解析結果画面５１５には、ボトルネック解析処理（図２のステップ２０２）を行った結果が表示され、影響解析結果画面５２０には、影響解析処理（図２のステップ２０４）を行った結果が表示される。また、解析結果の解説画面５２７には、ボトルネック解析処理２０２もしくは影響解析処理２０４を行った結果の詳細な説明と結果に対する対応方法が表示される。以下に、各項目の説明を行う。なお、各項目に表示されている具体的な数値の意味、各数字間の関係については、後述する図６と図７にて説明する。また、各項目の数字の算出方法については、後述する図１２〜図２４の処理フローにおいて説明する。
（５−１）ボトルネック解析結果画面５１５は、ボトルネック解析前に多重度調整エージェントに設定されていた多重度である「元の多重度設定値」５１６、元の多重度設定値５１６から算出したリクエスト発生率である「元の上限リクエスト発生率」５１７、実測値を用いたボトルネック解析後に得られたリクエスト発生率である実リクエスト発生率５１９、及び実リクエスト発生率５１９から算出した必要多重度である実必要多重度５１８で構成される。
（５−２）影響解析結果画面５２０は、ボトルネック解析後に修正した多重度である「修正後の多重度設定値」５２１（後述する多重度修正方法５３４で“自動”が選択されている場合には自動的に修正値が設定され、“手動”、または“強制”が選択されている場合には、ユーザが修正値を入力する。）、修正後の多重度設定値５２１から算出したリクエスト発生率である「修正後の上限リクエスト発生率」５２２、多重度修正により新規流入するリクエストを考慮した影響解析の結果得られた、現在のリクエスト発生率である「再算出後の現在の想定リクエスト発生率」５２４（詳細は、後述する図２１で説明する。）、再算出後の現在の想定リクエスト発生率５２４から算出した必要多重度である「再算出後の現在の必要多重度」５２３、多重度修正により将来流入するリクエストを考慮して影響解析後に得られた値であり、将来増加し、当該値に達する可能性のあると予測されるリクエスト発生率である「再算出後の将来の想定リクエスト発生率」５２６（詳細は、後述する図２１で説明する。）、再算出後の将来の想定リクエスト発生率５２６から算出した必要多重度である「再算出後の将来の必要多重度」５２５から構成される。
（５−３）解析結果の解説画面５２７は、多重度設定値がリクエストを処理できる値であるか否かを示す「状況」５２８、多重度設定値が不足しているか、または不足すると予測される場合の対応方法を示す「指針」５２９、状況５２８や指針５２９を決定するに至った理由を示す「理由」５３０から構成される。状況５２８に表示される文言には、「現在、多重度が十分足りていることを示す文言」、「現在、多重度が不足していることを示す文言」、「将来、多重度が不足する可能性があることを示す文言」の３パターンが考えられる。指針５２９に表示される文言には、「多重度設定値を増やすよう促す文言」、「スケールアウトするよう促す文言」、「スケールアップするよう促す文言」の３パターンが考えられる。

図５に示す例では、保証ＤＢの影響解析の結果、多重度は現在のところ足りているが、将来は不足する可能性があるという結果が出たので、解析結果の解説画面５２７には、その旨が表示されている。また、解析結果表示画面５１４の最上段には、通知レベルが「ＷＡＲＩＮＧ」と表示されている。もし、多重度が現在も不足していれば、通知レベルが「ＥＲＲＯＲ」、多重度が将来も足りていれば、通知レベルが「ＯＫ」と表示される。

以上のように、解析結果表示画面５１４により、各構成要素の多重度設定値、必要多重度、リクエスト発生率に関する現状と理想を比較することができ、多重度設計の参考情報として利用することができる。結果として、最適なパラメタ値を導き出す設計作業を支援することができるという効果がある。さらに、リソース拡充のコストと性能確保とのトレードオフにより、導き出されたパラメタ値を採用するのか否かを決めることができる。
（６）多重度修正／変更画面５３１は、多重度修正処理（図２のステップ２０３）を実行する際に押下する多重度修正ボタン５３２、多重度変更処理（図２のステップ２０５）を実行する際に押下する多重度変更ボタン５３３、多重度修正処理の処理方法を、自動、手動、または強制から選択するラジオボタン５３４、多重度変更処理の処理方法を、自動または手動から選択するラジオボタン５３５から構成される。

なお、多重度修正方法ラジオボタン５３４において、「自動」を選択すれば、テキストエリア５２１に実必要多重度５１８が自動的に入力されるので、構成要素毎に多重度の修正値をテキストエリア５２１に入力する手間を省くことができる。また、実際には、新たなサーバの導入コストやシステム構築期間が大きいために、ボトルネックの構成要素の多重度を必要多重度以上の値に変更することができない場合がある。この場合には、多重度修正方法ラジオボタン５３４で“強制”を選択し、テキストエリア５２１に、必要多重度より小さな多重度設定値を入力することにより、当該多重度を設定した構成要素を影響解析の対象外とすることもできる。

多重度修正／変更画面５３１により、構成要素毎に多重度の修正／変更方法を選択することができ、監視対象システム運用・管理者の設計作業負担を軽減すると共に、リアルタイムにサーバリソースを動的に再配分することができる。さらに、リソース拡充のコストと性能確保とのトレードオフにより、導き出されたパラメタ値を採用するのか否かを決めることができる。また、最適なパラメタ値が導出されない場合に、手動でパラメタ値を決定することができる。

図６は、ボトルネック解析処理（図２のステップ２０２）を行った後の連携表示画面５１３（図５）を示す。ここでは、図４に示す銀行システムにおいて、自営業者保証インスタンス４２３がボトルネックになっている場合の、連携表示画面５１３の詳細を示す。

まず、連携表示画面５１３は、最上位レベルであるシステムレベルの連携表示画面である銀行システム画面６７０１を表示する。銀行システム画面６７０１では、融資システムアイコン６７０５と営業店システムアイコン６７０７から担保・保証システムアイコン６７０８へ延びる連携矢印が太線表示されており、担保・保証システムアイコン６７０８が二重線になっている。これは担保・保証システム４０５がボトルネックとなっていることを示す。

次に、担保・保証システム４０５内のどの構成要素がボトルネックとなっているのかを調べるために、担保・保証システムアイコン６７０８を選択すると（マウスでダブルクリック等）、担保・保証システム連携表示画面６７０２に遷移する。担保・保証システム連携表示画面６７０２は、銀行システムのサブシステムレベルの連携表示画面である（図５の連携表示画面５１３も、このサブシステムレベルを示している。）。担保・保証システムでは、保証サーバアイコン６７１４が二重線になっているので、保証サーバ４１４（図４）がボトルネックとなっていることを示す。

保証サーバアイコン６７１４のポップアップヒント６０１が含む情報は、元の上限リクエスト発生率が「２５０」（個／秒）、元の多重度設定値が「１３」、実リクエスト発生率が「３２０」（個／秒）、実必要多重度が「１６」という情報である（この解析結果は、図５のボトルネック解析結果５１５にも表示される）。ここで、元の多重度設定値＜実必要多重度（１３＜１６）であることから、保証サーバ４１４がリクエストを処理しきれていないことが分かる。また、保証ＤＢ４２７の状況については、ポップアップヒント６０２が表示されている場合は、元の多重度設定値＞実必要多重度（１７＞１３）であることから、保証ＤＢ４２７は、十分にリクエストを処理できていることが分かる。また、ポップアップヒント６０３が表示されている場合は、元の多重度設定値＞実必要多重度（１５＞１３）であることから、保証ＤＢ４２７は、同様に十分にリクエストを処理できていることが分かる。ここで例示した２つのケースの相違については、後述する図７において説明する。

このように、ボトルネックが生じている構成要素の上位レベルに位置する親構成要素を強調表示することにより、本システムは、より巨視的な観点から問題（ボトルネック）が発生している箇所を把握し、設計作業を支援することができる。

次に、保証サーバ４１４内のどの構成要素がボトルネックとなっているのかを調べるために、保証サーバアイコン６７１４を選択すると（マウスでダブルクリックなど）、保証サーバの下のレベルである保証プロセス４１５（図４）の連携表示画面５１３が表示され（図６では図示せず）、さらにその画面保証プロセス４１５を選択すると、保証プロセス画面６７０３に遷移する。

保証プロセス画面６７０３では、保証照会スレッドアイコン６７１５と保証登録スレッドアイコン６７１７の両スレッドから自営業者保証インスタンスアイコン６７１８へ延びる連携矢印が太線表示され、自営業者保証インスタンスアイコン６７１８が二重線になっている。これは自営業者保証インスタンス４２３（図４）がボトルネックとなっていることを示す。図６には図示していないが、自営業者保証インスタンス４２３の解析結果表示画面５１４（図５）には、例えば、元の多重度設定値５１６が「５」、実必要多重度５１８が「９」と表示された場合、元の多重度設定値５１６＜実必要多重度５１８であることから、自営業者保証インスタンス４２３がリクエストを処理しきれていない状態であることがわかる。

また、ポップアップヒント６０４の状況「ボトルネック発生！」の文言より、自営業者保証インスタンス４２３がボトルネック発生の根本原因となる構成要素であることが分かる。さらに、指針「多重度を上げてください」の文言と、理由「ＣＰＵ・メモリとも余裕あり」の文言より、自営業者保証インスタンス４２３の多重度設定値を増やすことで、保証サーバ４１４への負荷やメモリ使用量を安定に保った状態で（臨界多重度の範囲内で）、ボトルネックを解消することができることが分かる。

このように、ボトルネック解析結果を画面上に表示し、問題点（ボトルネック）の詳細な状況を理解し易くすることで、設計作業を支援することができるという効果がある。

なお、メモリ使用量については、後述する図１７で説明するサーバの負荷解析処理の流れと同様の方法で解析することができる。また、ＣＰＵ利用率やメモリ使用量に限らず、これらと同様のモデルを持つ他のパラメタ（ＩＯ回数等）にも、図１７に示す方法と同様の方法で解析することができる。

最後に、自営業者保証インスタンス４２３内のどの構成要素がボトルネックとなっているのかを調べるために、自営業者保証インスタンスアイコン６７１８をマウス等でダブルクリックすると、自営業者保証インスタンス連携表示画面６７０４に遷移する。自営業者保証インスタンス連携表示画面６７０４では、自営業者登録ＡＰアイコン６７２０が二重線になっており、これは自営業者登録ＡＰ４２６（図４）がボトルネックとなっていることを示す。ただし、業務ＡＰレベルの構成要素に、直接、多重度を設定することはできない。従って、実際には、自営業者登録ＡＰ４２６の親構成要素である自営業者保証インスタンス４２３の設定多重度を調整することで、ボトルネックを解消する。

以上のように、最上位レベルの連携表示画面５１３である銀行システム画面６７０１から順に、担保・保証システム画面６７０２、保証プロセス画面６７０３、自営業者保証画面６７０４へと下位レベルのシステムの構成要素とその状況を連携表示画面５１３（図５）に表示していくことで、システム運用管理者は、マクロな視点からミクロな視点へと序々にブレークダウンしながら解析結果を見ることができる。このため、広い視野に立って、効率よくシステム全体の性能対策を行い、多重度によるシステムチューニングのためのトライ＆エラーの試行回数を少なくできるという効果がある。

図７は、影響解析処理（図２のステップ２０４）を行った後の連携表示画面５１３を示す。図７では、ボトルネック解析により明らかになった、自営業者保証インスタンス４２３の多重度不足（図６の画面例）を、多重度設定値を増やすことで解決し、その後影響解析を行った結果、今度は、保証ＤＢ４２７に多重度不足が発生するというケースを想定して、図６の各連携表示画面（６７０１−６７０４）がどのように変化するかを詳細に説明する。

まず、保証プロセス連携表示画面６７０３は、図６でボトルネックとなっていると判断された自営業者保証インスタンス４２３（図６の例では、図５の解析結果表示画面５１４において、元の多重度設定値５１６が「５」、実必要多重度５１８が「９」であった。）の元の多重度設定値「５」を「１０」に修正し、影響解析処理（図２のステップ２０４）を行った後の状態を図示する。これにより、多重度修正後の自営業者保証インスタンス４２３の影響解析結果表示画面５２０には、修正後の多重度設定値５２１が「１０」、再算出後の現在の必要多重度５２３が「９」と表示され、修正後の多重度設定値＞再算出後の現在の必要多重度となることから、自営業者保証インスタンス４２３は、十分にリクエストを処理できるようになったことが分かる。また、ポップアップヒント７０４の状況「ボトルネック解消！」の文言より、自営業者保証インスタンス４２３が原因で発生したボトルネックが解消したことが分かる。また、自営業者保証インスタンスアイコン６７１８の二重線もなくなっている。さらに、影響解析処理後の自営業者保証インスタンス画面６７０４でも、ボトルネックを示す自営業者登録ＡＰアイコン６７２０の二重線が消えている。従って、十分にリクエストを処理できる状態になったことが分かる。

このように、影響解析結果を画面上に表示することにより、問題点（ボトルネック）の解消状況を理解し易くすることで、設計作業を支援することができるという効果がある。

次に、担保・保証システム連携表示画面６７０２は、保証プロセス連携表示画面６７０３で影響解析処理を行った後の担保・保証システムの状態を示し、ここでは、ボトルネックを示す保証サーバアイコン６７１４の二重線が消えている。また、保証サーバアイコン６７１４のポップアップヒント７０１より、修正後の多重度設定値＞再算出後の現在の必要多重度（１８＞１６）であることから、保証サーバ４１４は、十分にリクエストを処理できる状態になったことが分かる。

一方、保証ＤＢ４２７の状況については、ポップアップヒント７０２と７０３に示すように、２つのケースがある。いずれのケースであっても、保証ＤＢアイコン６７２１は二重線にされており、新たなボトルネックの可能性を示している。なお、ポップアップヒント７０２は、図６におけるポップアップヒント６０２のケースに相当し、ポップアップヒント７０３は、図６におけるポップアップヒント６０３のケースに相当する。
（１）ポップアップヒント７０２のケースでは、図示していないが、ポップアップヒント７０１とポップアップヒント６０２に含まれる数値から、保証ＤＢ４２７の解析結果表示画面５１４には、元の多重度設定値５１６は「１７」、再算出後の現在の必要多重度５２３は「１６」と表示される。ここで、元の多重度設定値＞再算出後の現在の必要多重度となることから、保証ＤＢ４２７は、現在のところ、十分にリクエストを処理できる状態であることが分かる。しかしながら、元の多重度設定値（５１６）は「１７」、再算出後の将来の実必要多重度５２５は「１８」と表示されることから、元の多重度設定値＜再算出後の将来の実必要多重度となり、保証ＤＢ４２７は、将来、リクエストを処理しきれなくなる可能性があることが分かる。

また、ポップアップヒント７０２の通知レベルが「ＷＡＲＮＩＮＧ」は、保証ＤＢ４２７は、現在はリクエストを処理できるが、将来は処理できなくなる可能性があることを意味する。また、状況「将来コネクション不足となる可能性があります！」の文言から、保証ＤＢ４２７が新たなボトルネック発生の原因構成要素となる可能性があることが分かる。さらに、指針「ＤＢサーバのノード数を増やしてください。」及び、理由「ＣＰＵに余裕がありません。」の文言より、保証ＤＢ４２７のノード数（サーバ台数）を増やさなければ、将来、保証ＤＢ４２７への負荷を安定に保った状態で（つまり、臨界多重度の範囲内で）、ボトルネックを解消することはできないことが分かる。
（２）ポップアップヒント７０３のケースでは、図示していないが、ポップアップヒント７０１とポップアップヒント６０３に含まれる数値から、保証ＤＢ４２７の解析結果表示画面５１４には、元の多重度設定値５１６は「１５」、再算出後の現在の必要多重度５２３は「１６」と表示される。ここで、元の多重度設定値＜再算出後の現在の必要多重度５２３となることから、（ボトルネック解析処理により明らかになった）自営業者保証インスタンス４２３の多重度不足という状態に対して、自営業者保証インスタンス４２３の多重度設定値を増やすと、保証ＤＢ４２７がリクエストを処理きれなくなる状態になることが分かる。

また、ポップアップヒント７０３の通知レベルが「ＥＲＲＯＲ」となっているのは、このまま何の対策もしないで自営業者保証インスタンス４２３の多重度設定値を増やすと、保証ＤＢ４２７はリクエストを処理しきれなくなることを意味する。また、状況「コネクション不足です！」は、保証ＤＢ４２７が新たなボトルネック発生の原因構成要素となる可能性があることを意味する。さらに、指針「ＤＢサーバのノード数を増やしてください。」、及び理由「ＣＰＵに余裕がありません。」の文言より、保証ＤＢ４２７のノード数（サーバ台数）を増やさなければ、保証ＤＢ４２７への負荷を安定に保つことはできないことが分かる。

このように、影響解析結果を画面上に表示することにより、新たに発生した問題点（ボトルネック）の詳細な状況を理解し易くすることで、設計作業を支援することができる。

最後に、銀行システム連携表示画面６７０１は、影響解析処理後の銀行システムの状態を示す。担保・保証システムアイコン６７０８は二重線のままであり、依然としてボトルネックが存在することが分かる。これは、上述したように、自営業者保証インスタンス４２３の多重度修正後の影響解析により、今度は、担保・保証システム４０５内の保証ＤＢ４２７が、リクエストを捌ききれなくなる可能性があることが判明したためである。

図８は、監視対象システム１０７（具体的には、銀行システム４０１）のシステム構造を表現したデータ構造図であり、システム間構成定義３２９とサブシステム内部構成定義３１６（ともに図３に示されている）から構成される。

システム間構成定義３２９は、システムの構成情報（図４においては、銀行システム４０１）を格納するテーブルであるシステム構成定義８０１、及びシステム構成定義８０１からサブシステム構成定義８０３（サブシステム内部構成定義３１６に含まれる）への関係を示すテーブルであるサブシステム関係８０２を含む。

サブシステム内部定義３１６は、５種類の構成定義テーブルと４種類の関係テーブルで構成される。

５種類の構成定義テーブルとは、（１）サブシステム（図４においては、融資システム４０２、金利・相場システム４０３、営業店システム４０４、担保・保証システム４０５）の構成情報を格納するテーブルであるサブシステム構成定義８０３、（２）サーバ（図４においては、担保・保証用負荷分散器４０６、担保Ｗｅｂ４０７、担保サーバ４０８、担保ＤＢ４０９、保証Ｗｅｂ４１１、保証サーバ４１４、保証ＤＢ４２７）の構成情報を格納するテーブルであるサーバ構成定義８０５、（３）プロセス（図４においては、保証ＨＴＴＰデーモン４１２、保証プロセス４１５、保証ＤＢＭＳ４２８）の構成情報を格納するテーブルであるプロセス構成定義８０７、（４）コンポーネント（図４においては、保証照会スレッド４１６、保証登録スレッド４１９、給与所得者保証インスタンス４１７、自営業者保証インスタンス４２３）の構成情報を格納するテーブルであるコンポーネント構成定義８０９（なお、コンポーネントとは、スレッドやインスタンス等のプロセスよりも小さな実行単位の概念の総称である。）、（５）業務ＡＰ（図４においては、登録ＡＰ４２０、自営業者照会ＡＰ４２４、自営業者登録ＡＰ４２６）の構成情報を格納するテーブルである業務ＡＰ構成定義８１１である。

また、４種類の関係テーブルとは、（１）サブシステム構成定義８０３とサーバ構成定義８０５との関係テーブルを示すサーバ関係８０４、（２）サーバ構成定義８０５とプロセス構成定義８０７との関係テーブルを示すプロセス関係８０６、（３）プロセス構成定義８０７とコンポーネント構成定義８０９との関係テーブルを示すコンポーネント関係３０８、（４）コンポーネント構成定義８０９と業務ＡＰ定義８１１との関係テーブルを示す業務ＡＰ関係８１０である。

例えば、プロセス構成定義８０７に格納されている構成要素の１つである保証プロセス４１５（図４において、子コンポーネントは、保証照会スレッド４１６、保証登録スレッド４１９、給与所得者保証インスタンス４１７、自営業者保証インスタンス４２３の４つ）について、プロセス構成定義８０７からコンポーネント構成定義８０９へのコンポーネント関係８０８を具体的に示すと、コンポーネント名（ＩＤ）が「保証照会スレッド４１６」の場合、連携元コンポーネントリストは「保証ＨＴＴＰデーモン４１２」、連携先コンポーネントリストは、「給与所得者保証インスタンス４１７」及び「保証登録スレッド４１９」である。ここで、連携元コンポーネントとは、図４において、コンポーネント名で指定されたコンポーネントに対して矢印を向けているコンポーネントであり、連携先コンポーネントとは、図４において、コンポーネント名で指定されたコンポーネントが矢印を向けているコンポーネントを意味する。なお、連携元にコンポーネントレベルの定義情報が存在しない場合には、上位レベルのプロセス情報を持つ。

なお、各構成定義テーブルに格納された多重度修正方法８１４等に含まれる情報は、多重度修正処理（図２のステップ２０３）において参照される。具体的には、後述する図１８のステップ１８０１において、多重度修正方法１８０４として参照される。同様に、各構成定義テーブルに格納された多重度変更方法８１５等に含まれる情報は、多重度変更処理（図２のステップ２０５）において参照される。具体的には、後述する図２４のステップ２３０１において、多重度修正方法２３０６として参照される。従って、監視対象システム運用・管理者の作業負担を軽減し、性能確保とシステム安定稼動とを両立させる最適なシステム構成およびパラメタ値を導き出す設計作業を支援することができる。

また、コンポーネント構成定義８０９からは、エージェント情報９０８へのリンクが張られており、これにより、多重度調整エージェント１１０、１１２（図１）を特定することができ、サーバリソースを動的に再配分することができるという効果がある。

図９は、履歴および定義情報を詳細に示したデータ構造図である。このデータ構造図は、リクエストがサブシステム内をどのように通過するのかを定義したリクエストパス定義９１８、リクエスト計測モジュール３０２、３０７（図３）がどのようなリクエスト情報を取得する必要があるのかについて定義した取得する実測値の送信／受信定義３０３、３０８（図３）、多重度設定値とキュー長設定値を格納した自構成要素の多重度定義３１１、自構成要素の多重度定義３１１のどの項目が多重度設定値とキュー長設定値に相当するのかを定義した多重度設定メタ定義３１７から構成される。

リクエストパス定義９１８は、リクエストパスを特定する情報を格納するテーブルであるリクエストパス特定定義９０１、リクエストがコンポーネントを通過する際の情報（順序、回数、分岐条件等）を格納するテーブルである連携先構成要素情報９０３、リクエストパス毎の性能情報（臨界多重度、平均レスポンス、臨界ＣＰＵ利用率（臨界多重度における各サーバのＣＰＵ利用率）等）を格納するテーブルであるリクエストパス性能情報９０４、定義９０３から定義９０４への関係テーブルである構成要素関係９０２の４つのテーブルで構成される。なお、図９に示すように、各テーブルには、サブシステム内部構成定義３１６（図８）内の各テーブルへのリンクが張られている。ここで、臨界ＣＰＵ利用率とは、をいう。

また、連携先構成要素情報テーブル９０３は、連携順序９１１と連携条件９１２を属性として含む。これにより、リクエストパス毎のリクエストがどのような順序でどのコンポーネントを何回通過するのか、また、条件分岐する場合には、どのような条件や割合でその条件分岐が発生するのかが分かり、最適なパラメタ値を導き出す設計作業を支援することができる。さらに、リクエストパス性能情報テーブル９０４は、臨界多重度１７０７、平均レスポンス１４１４、および臨界ＣＰＵ利用率１７０８等の臨界パラメタ（臨界メモリ使用量、臨界ＩＯ発生率等を含む。なおこれらのパラメタの定義及び利用方法については、図１７を参照）を属性として持っている。これにより、リクエスト発生率が分かるとともに、サーバ負荷解析処理１３０４（図１３）やサーバの負荷解析の再実行処理１９０４（図１９）において最適なパラメタ値を導き出すことができる。

次に、取得する実測値の送信／受信定義３０３、３０８は、どの多重度調整エージェント１１０、１１２（図１）で取得した実測値であるのかを特定する情報を取得するよう指定した定義したテーブルである実測値９０５、リクエストパスを特定するための情報を取得するよう指定した定義テーブルであるリクエスト情報９０６、リクエスト情報を一意に特定するための情報を取得するよう指定した定義テーブルである電文情報９０７の３つのテーブルで構成される。図３に示す送信／受信リクエスト計測モジュール３０２、３０７や、サブシステム別実測値収集モジュール３１２、実測値収集モジュール３２２は、この定義情報テーブル３０３、３０８に格納された情報に基づき実測値を計測、収集、仕分け、マージ作業を行う。

なお、図９に示すように、実測値テーブル９０５は、当該実測値を計測した多重度調整エージェント１１０、１１２を特定するエージェント名（ＩＤ）９１３を含む。リクエスト情報テーブル９０６は、リクエストのリクエストパスを特定するリクエストパス名（ＩＤ）９１４を含む。電文情報テーブル９０７は、複数の構成要素で別々に計測されたリクエスト情報を１つにつなぎ合わせる識別子である取引識別子（ＩＤ）９１５、取得時間帯毎に仕分ける項目である時間帯９１６、未送信、未処理、処理済を区別する項目である電文種別９１７を含む。以上の項目により、最適なパラメタ値を導き出す設計作業を支援することができる。

次に、自構成要素の多重度定義３１１は、多重度調整エージェント１１０、１１２を特定する情報を格納するテーブルであるエージェント情報９０８、同時実行多重度制御および負荷分散処理を行うのに必要な情報を格納するテーブルである多重度情報９０９の２つのテーブルから構成される。多重度情報テーブル９０９は、多重度制御モジュール３０１、３０５が同時実行多重度制御および負荷分散処理を行うために利用する情報を含む。これらの情報に基づいて、自動的かつサーバ安定稼動を確保したまま、リアルタイムにサーバリソースを再配分することができる。

最後に、多重度設定メタ定義３１７は、多重度調整エージェント１１０、１１２を特定する情報を格納するテーブルであるエージェント情報９０８、各種設定パラメタの項目を特定するための情報を格納するテーブルである多重度設定項目情報９１０の２つのテーブルから構成される。多重度変更指示モジュール３１５（図３）は、多重度設定メタ定義３１７に含まれる情報に基づいて、多重度設定値の変更指示処理を行う（後述する図２４のステップ２３０５）。

図１０は、リクエスト発生率とシステム構成要素の関係を示した説明図である。あるリクエストパスを持つリクエストの必要多重度１０１０は、図１０に示す算出式１００９「リクエスト発生率１０１１×平均レスポンス１０１２」で表現できる。ここで、必要多重度１０１０は、構成要素にて制御可能なパラメタであり、リクエスト発生率１０１１及び平均レスポンス１０１２は、構成要素にて計測可能なパラメタである。従って、各構成要素のリクエスト発生率１０１１と平均レスポンス１０１２を計測することによって、必要多重度１０１０を決定し、このパラメタ１０１０を用いて、各構成要素の同時実行多重度を制御することができる。なお、平均レスポンス１０１２は、各構成要素におけるリクエストの平均内部保留時間のことであり、各構成要素での内部保留時間を計測することで算出可能である。

あるリクエストパスを持つリクエストが、図１０に示すように、監視対象システム利用端末１０６（ブラウザ）→担保・保証用負荷分散器４０６→保証ＨＴＴＰデーモン４１２→保証照会スレッド４１６→保証登録スレッド４１９→自営業者保証インスタンス４２３内の自営業者照会ＡＰ４２４及び自営業者登録ＡＰ４２６を順に通過するというパス特性を持っているとする。そして、リクエストの電文内容が正常であり、通過パスの途中でエラーリターンすることがない場合には、リクエスト発生率１０１１は、図１０における各構成要素のリクエスト計測点１００２〜１００５、１００７〜１００８のどこで計測しでも同じ値である。

また、計測点１００６のように、１回のリクエスト処理において２度同じ構成要素（自営業者保証インスタンス４２３）を通過する場合には、他の計測点にて計測したリクエスト発生率１０１１を２倍した値と、計測点１００６にて計測したリクエスト発生率１０１１は同じになる。逆に、計測点１００６にて計測したリクエスト発生率１０１１を２で割った値と、他の計測点にて計測したリクエスト発生率１０１１は同じになる。このように、１回のリクエスト処理において、同一構成要素を複数回通過する場合には、その構成要素におけるリクエスト発生率を、各構成要素の通過回数で乗じたり除したりすることによって、互いの構成要素のリクエスト発生率と相互に変換可能となる。つまり、リクエスト発生率１０１１は、各構成要素間で共通に用いることが可能なパラメタとすることができる。

従って、リクエストパスの途中で多重度制御調整エージェント１１０、１１２の多重度制御モジュール３０１、３０５の多重度制御機能によってエラーリターンしたリクエストについて、そのリクエストが（エラーリターンしないで）正常に処理されたと仮定した場合における、各構成要素で本来処理すべきリクエストの数（つまりリクエスト発生率１０１１）を算出することができる。そして、算出したリクエスト発生率１０１１と平均レスポンス１０１２から、必要多重度の算出式１００９を用いることによって、各構成要素の必要多重度１０１０を算出することができる。

さらに、リクエストパスの途中で何らかの業務エラーによって、あるリクエストがリターンする場合や、条件分岐によって通過するパスが複数パターン存在する場合には、エラーリターンや条件分岐の割合を過去の履歴や事前の予想値から算出することで、各構成要素でのリクエスト発生率を算出することができる。例えば、「そのリクエストがある構成要素で計測されるリクエスト発生率」＝「そのリクエストが発生元で計測されるリクエスト発生率」×「そのリクエストがその構成要素を通過する割合」となる。

図１１は、効率的な必要多重度の導出方法の一例を示す図である。図１１は、横軸に時間軸ｔ、縦軸に必要多重度軸をとり、自営業者照会ＡＰ４２４（図４）の必要多重度ａ（ｔ）１１０３と自営業者登録ＡＰ４２６（図４）の必要多重度ｂ（ｔ）１１０４の時間変化を示す。

もし、照会ＡＰ４２４、登録ＡＰ４２６のリクエスト発生率の時間変化を考慮しない場合は、単純にそれぞれの業務ＡＰに必要な多重度の最大値１１０５、１１０６の合計である必要多重度１１０７が、自営業者保証インスタンス４２３の必要多重度となる。しかし、図１１に示すように、実際には、どの時刻においても必要多重度１１０７ほど大きな多重度は必要ではない。よって、必要多重度１１０７は、システムリソースを効率よく利用するような必要多重度ではない。そこで、照会ＡＰ４２４、登録ＡＰ４２６の必要多重度の時間による変化を考慮し、時間間隔Δｔ毎に必要多重度を時間変化させる。つまり、「あるΔｔにおけるａ（ｔ）の最大値」＋「そのΔｔにおけるｂ（ｔ）の最大値」を必要多重度とする。ここで、Δｔを図１１のように取ることにより、自営業者保証インスタンス４２３の必要多重度は１１１０に示すグラフとなり、Δｔ→０にすると、必要多重度は１１０９に示すグラフとなる。

このように、時間帯毎のリクエスト発生率を計測し、必要多重度の算出式１００９、条件分岐時のリクエスト発生率を算出したり、および時間帯毎の必要多重度を算出したりすることで、業務ミックス環境下におけるリソース有効利用ができる。

図１２から図２４は、図２に示す実測値収集処理（ステップ２０１）、ボトルネック解析処理（ステップ２０２）、多重度修正処理（ステップ２０３）、影響解析処理（ステップ２０４）、および多重度変更処理（ステップ２０５）の各ステップの詳細な処理フローを示す。なお、以降において「最下位レベルのシステム構成要素」とは、図３における構成要素のうち、スレッド、インスタンス、負荷分散器、ＨＴＴＰデーモン、ＤＢＭＳ等をいう。これに対し「上位レベルのシステム構成要素」とは、最下位レベルのシステム構成要素の多重度設定値やリクエスト発生率を合算することで、間接的に多重度制御や負荷分散処理を行うことができるシステム構成要素（具体的には、システム、サブシステム、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバ、プロセス等）をいう。さらに、ある構成要素へ直接リクエストを送信する他の構成要素を「上流の構成要素」、ある構成要素から直接リクエストを受信する他の構成要素を「下流の構成要素」という。

図１２は、実測値収集処理（図２のステップ２０１）の詳細なフローチャートを示す。なお、図１２の各ステップにおいて、図３に図示された定義情報やリクエスト情報を適宜参照する。

まず、多重度調整エージェント１１０の送信リクエスト計測モジュール３０２は、送信側リクエスト情報を取得する（ステップ１２０１）。具体的には、送信リクエスト計測モジュール３０２は、取得する実測値の送信定義３０３に基づき、未送信リクエスト情報を取得し、取得した情報を時間帯・リクエストパス毎に仕分け、時間帯・リクエストパス毎の未送信リクエスト情報３０４に格納する。

次に、多重度調整エージェント１１２の受信リクエスト計測モジュール３０７は、受信側リクエスト情報を取得する（ステップ１２０２）。具体的には、受信リクエスト計測モジュール３０７は、取得する実測値の受信定義３０８に基づき、未処理リクエスト情報を取得し、取得した情報を時間帯・リクエストパス毎に仕分け、時間帯・リクエストパス毎の未処理リクエスト情報３０９に格納する。また、受信リクエスト計測モジュール３０７は、取得する実測値の受信定義３０８に基づき、処理済リクエスト情報を取得し、当該情報を時間帯・リクエストパス毎に仕分け、時間帯・リクエストパス毎の処理済リクエスト情報３１０に格納する。

なお、ステップ１２０１とステップ１２０２は並行して行うことができる処理であり、同時に実行しても、順不同で順に実行してもよい。

次に、サブシステム別多重度調整サーバ１０５のサブシステム別実測値収集モジュール３１２は、サブシステム毎の実測値を収集する（ステップ１２０３）。具体的には、サブシステム別実測値収集モジュール３１２は、サブシステム内部構成定義３１６に基づき、時間帯・リクエストパス毎の未送信リクエスト情報３０４及び時間帯・リクエストパス毎の未処理リクエスト情報３０９を、各構成要素の多重度調整エージェント１１０及び１１２から収集し、収集した情報を各構成要素毎に仕分け、マージし、構成要素・時間帯・リクエストパス毎の未到達リクエスト情報３１３に格納する。また、サブシステム別実測値収集モジュール３１２は、サブシステム内部構成定義３１６に基づき、時間帯・リクエストパス毎の処理済リクエスト情報３１０を各構成要素の多重度調整エージェント１１２から収集し、当該収集した情報を各構成要素毎に仕分け、構成要素・時間帯・リクエストパス毎の処理済リクエスト情報３１４に格納する。

最後に、統合多重度解析サーバ１０４の実測値収集モジュール３２２は、システム全体の実測値を収集する（ステップ１２０４）。具体的には、実測値収集モジュール３２２は、サブシステム内部構成定義群３３０とシステム間構成定義３２９に基づいて、構成要素・時間帯・リクエストパス毎の未到達リクエスト情報３１３と構成要素・時間帯・リクエストパス毎の処理済リクエスト情報３１４を各サブシステムのサブシステム別多重度調整サーバ１０５から収集し、統合多重度解析サーバ１０４内の構成要素・時間帯・リクエストパス毎のリクエスト情報３３２に格納する。

図１３は、ボトルネック解析処理（図２のステップ２０２）の概要を示すフローチャートである。ボトルネック解析処理は、統合多重度解析サーバ１０４のボトルネック解析モジュール３２１（図３）が行う。

まず、各構成要素およびその上流の構成要素のリクエスト情報に基づき、最下位レベルの各構成要素・各時間帯の必要多重度を算出する（ステップ１３０１）。詳細は後述する図１４で説明する。次に、多重度設定値と、ステップ１３０１で算出した最下位レベルの構成要素の必要多重度に基づいて、上位レベルの各構成要素・各時間帯の多重度設定値と必要多重度を階層別に算出する（ステップ１３０２）。詳細は後述する図１５で説明する。次に、多重度設定値と必要多重度を比較し、各構成要素・各時間帯にて不足している多重度を算出する（ステップ１３０３）。詳細は後述する図１６で説明する。次に、必要多重度と臨界多重度から、各サーバ・各時間帯の負荷状態を算出し、パワー不足のサーバ・時間帯を解析する（ステップ１３０４）。詳細は後述する図１７で説明する。次に、サブシステム内部構成定義群３３０とシステム間構成定義３２９、およびボトルネック解析結果から、各階層・各時間帯のボトルネック解析結果情報を作成する（ステップ１３０５）。最後に、ボトルネック解析結果情報を端末に表示する（ステップ１３０６）。

図１４は、図１３のステップ１３０１（最下位レベルの構成要素の必要多重度算出処理）の詳細を示すフローチャートである。ステップ１３０１では、サブシステム内部構成定義群３３０とシステム間構成定義３２９（図３）を以下のサブステップおいて利用する。図１４では、ステップ１４０１からステップ１４０７までを時間帯（時間の分割）の数だけ繰り返す。つまり、ステップ１４０１では、ある時間を選択し、ステップ１４０７では、（選択していない）他の時間帯があるか否かを判断する（繰り返し判定）。また、ステップ１４０２からステップ１４０６までを上流の構成要素から下流の構成要素に向かって、構成要素の数だけ繰り返す。つまり、ステップ１４０２では、未処理の構成要素の中で上位（最上位）の構成要素を選択し、ステップ１４０６では、未処理の構成要素があるか否かを判断する（繰り返し判定）。

まず、ボトルネック解析モジュール３２１は、上流からの未到達リクエスト発生率を算出する（ステップ１４０３）。具体的には、（１）上流の各構成要素の未到達リクエスト情報１４０８（図１２のステップ１２０４においてリクエスト情報データベース３３２に格納される情報）に基づき、処理対象のリクエストの送信先構成要素を特定し、リクエストパス毎の未処理リクエスト数を算出する（送信先を特定できない場合には、予測値や過去の履歴から、各送信先構成要素への振り分け割合を算出し、この割合を重み付け値としてリクエストパス毎の未送信リクエストの数を算出する。）。そして、算出したリクエスト数と各リクエストの発生時刻から、リクエストパス毎のリクエスト発生率（未送信リクエスト発生率）を算出する。（２）次に、リクエストパス毎の構成要素での未処理リクエストの数を算出し、算出した未処理リクエスト数と各リクエストの発生時刻から、リクエストパス毎のリクエスト発生率（未処理リクエスト発生率）を算出する。（３）未送信リクエスト発生率と未処理リクエスト発生率を合計して、上流からの未到達リクエスト発生率を算出する。そして、その算出情報を未到達リクエスト発生率１４１２に格納する。

次に、構成要素で処理されたリクエスト発生率を算出する（ステップ１４０４）。具体的には、計算対象の構成要素の処理済リクエスト情報１４０９（図１２のステップ１２０４においてリクエスト情報データベース３３２に格納される情報）に基づき、当該構成要素にて処理されたリクエスト発生率をリクエストパス毎に算出する。そして、その算出結果を処理済リクエスト発生率１４１３に格納する。

最後に、ステップ１４０３と１４０４で算出されたリクエスト発生率１４１２及び１４１３と、予め測定しておいた平均レスポンス１４１４から、計算対象の構成要素のリクエストパス毎の全リクエスト発生率とそれを処理するのに必要な多重度を算出する（ステップ１４０５）。具体的には、リクエスト発生率１４１２及び１４１３を合計して、リクエストパス毎の全リクエスト発生率を算出する。また、ある構成要素のリクエストパス毎に、図１０の算出式１００９により必要多重度を算出し、その構成要素に関する全てのリクエストパスの必要多重度を合計して、必要多重度を算出する。

これにより、構成要素の必要多重度をより正確に求めることができ、また異なるリクエストパスにおいて個別に算出された必要多重度を、ある構成要素のパラメタである多重度設定値と同様の値（多重度設定値として利用できる値）に変換することができ、最適なパラメタ値を導き出す設計作業を支援することができる。

図１５は、図１３のステップ１３０２（上位レベルのシステム構成要素の多重度設定値と必要多重度の算出処理）の詳細を示すフローチャートである。ステップ１３０２では、サブシステム内部の構成定義群３３０とシステム間構成定義３２９を以下のサブステップおいて利用する。ステップ１３０２も、図１４のステップ１３０１と同様に、ステップ１５０１からステップ１５０７までを時間帯（時間の分割）の数だけ繰り返すとともに、ステップ１５０３からステップ１５０５までを上流の構成要素から下流の構成要素に向かって、構成要素の数だけ繰り返す処理を行う。さらに、ステップ１５０２からステップ１５０６までを下位レベルの構成要素から上位レベルの構成要素に向かって、階層の数だけ繰り返す。つまり、ステップ１５０２では、ある時間帯における下位レベル（最下位レベル）の階層を選択し、ステップ１５０６では、未処理の階層があるか否かを判断する（繰り返し判定）。

ステップ１５０４は、多重度設定値、必要多重度及び合計リクエスト発生率を算出する。ステップ１５０４では、全リクエスト発生率１４１１のうち、計算対象の構成要素（親構成要素）を構成する子構成要素へのリクエストであって、その親構成要素の外部から流入するリクエストのみを計算対象とする。ボトルネック解析モジュール３２１は、子構成要素の多重度設定値１５０９（図１４で求めた最下位レベルの必要多重度１４１０）、予め測定しておいた平均レスポンス１４１４、および子構成要素の全リクエスト発生率１５１０（図１４で求めた全リクエスト発生率１４１１）に基づき、計算対象の構成要素に含まれる子構成要素の多重度設定値１５０９を合計して、その構成要素の多重度設定値１５０８を算出する。また、子構成要素のリクエストパス毎の全リクエスト発生率を合計して、その構成要素のリクエストパス毎の全リクエスト発生率１４１１を算出する。また、図１０に示した算出式１００９から、リクエストパス毎の必要多重度１４１０を算出する。

ステップ１５０４において、ある階層について算出された多重度設定値１５０８は、上位レベルの階層におけるステップ１５０４の入力データである「子構成要素の多重度設定値１５０９」として用いられる。同様に、ある階層について算出された全リクエスト発生率１４１１は、上位レベルの階層におけるステップ処理１５０４の入力データである「子構成要素の全リクエスト発生率１５１０」として用いられる。

ステップ１５０４の処理により、解析結果表示画面５１４に必要な上位レベルのリクエスト発生率を導き出すことができ、多重度によるシステムチューニングのためのトライ＆エラーの試行回数を少なくできる。

図１６は、図１３のステップ１３０３（不足する多重度の算出処理）の詳細を示すフローチャートである。ステップ１３０３でも、サブシステム内部の構成定義群３３０とシステム間構成定義３２９を以下のサブステップにおいて利用する。ステップ１３０３も、図１５に示すステップ１３０２と同様に、ステップ１６０１からステップ１６０７までを時間帯（時間の分割）の数だけ繰り返すとともに、ステップ１６０２からステップ１６０６までを下位レベルの構成要素から上位レベルの構成要素に向かって、階層の数だけ繰り返す処理を行う。また、ステップ１６０３からステップ１６０５までを上流の構成要素から下流の構成要素に向かって、構成要素の数だけ繰り返す処理を行う。

ステップ１６０４は、図１５（ステップ１５０４）の出力結果である多重度設定値１５０８と必要多重度１４１０を比較する。具体的には、必要多重度≦多重度設定値であれば正常と判断し、必要多重度＞多重度設定値であれば、ボトルネックが発生していると判断する。そして、比較結果を多重度の解析結果１６０８として格納する。

ステップ１６０４の処理により、解析結果表示画面５１４に必要な上位レベルの必要多重度を導き出すことができ、多重度によるシステムチューニングのためのトライ＆エラーの試行回数を少なくできるという効果がある。

図１７は、図１３のステップ１３０４（サーバの負荷解析処理）の詳細を示すフローチャートである。ステップ１３０４でも、サブシステム内部構成定義群３３０とシステム間構成定義３２９を以下のサブステップにおいて利用する。ステップ１３０４でも、ステップ１７０１からステップ１７０６までを時間帯（時間の分割）の数だけ繰り返す。また、ステップ１７０２からステップ１７０５までをサーバ（ノード）の数だけ繰り返す。ステップ１７０２では、ある計算対象サーバを選択し、ステップ１７０５では、（負荷解析処理が行われていない）他のサーバがあるか否かを判断する（繰り返し判定）。

まず、サーバの負荷割合を算出する（ステップ１７０３）。具体的には、予め測定されたリクエストパス毎の臨界多重度１７０７及び臨界ＣＰＵ利用率１７０８、および計算対象のサーバに対応するリクエストパス毎の必要多重度１４１０（図１５の出力結果）に基づき、（必要多重度１４１０）／（臨界多重度１７０７）×臨界ＣＰＵ利用率１７０８という算出式によって、リクエストパス毎のサーバの負荷割合を算出し、全リクエストパスの算出結果を合計して、あるサーバの負荷割合１７０９を算出する。そして、その算出結果を、サーバの負荷割合１７０９として格納する。

次に、サーバの負荷割合１７０９を比較する（ステップ１７０４）。具体的には、サーバ負荷割合≦１００％であれば正常と判断し、サーバ負荷割合＞１００％であればボトルネックが発生していると判断する。そして、この比較結果を、多重度に関するサーバ負荷の解析結果１７１０として格納する。

ステップ１３０４により、解析結果表示画面５１４の状況５２８、指針５２９、理由５３０の表示に必要な情報を導き出すことができ、性能確保とシステム安定稼動とを両立させる最適なシステム構成およびパラメタ値を導き出す設計作業を支援することができる。なお、ステップ１７０３（サーバの負荷割合の解析処理）においては、多重度と臨界ＣＰＵ利用率との関係を用いたが、臨界ＣＰＵ利用率の代わりに、臨界メモリ使用率（臨界多重度におけるメモリ使用量／サーバに搭載している実メモリの全容量）や、臨界ＩＯ率（臨界多重度における単位時間当たりのＩＯ発生回数／ＩＯ発行のみのプログラムを実行した際に発行可能な単位時間当たりのＩＯ発行回数）を用いてもよい。そして、その解析結果が「ボトルネック発生」となった場合は、指針５２９には「メモリ増強」または「サーバのスケールアウト」等が表示される。

図１８は、多重度修正モジュール３２６が行う多重度修正処理（図２のステップ２０３）の詳細に示すフローチャートである。

まず、処理対象の構成要素の多重度を手動修正するのか自動修正するのかを判断する（ステップ１８０１）。具体的には、構成要素毎に多重度を手動修正するのか自動修正するのかを定義した多重度修正方法１８０４（図８に示す多重度修正方法８１４、８１６等に相当）、および構成要素の子構成要素をどの範囲まで自動修正するのかを定義した多重度修正適用ポリシー３２５（図３）に基づいて判断する。

ステップ１８０１において手動修正すると判断された場合は、サブシステム内部構成定義３１６およびシステム間構成定義３２９に基づいて検索された、処理対象の構成要素の多重度設定値に、端末から入力された多重度の値１８０５を設定する（ステップ１８０２）。

ステップ１８０１において自動修正すると判断した場合は、サブシステム内部構成定義３１６およびシステム間構成定義３２９に基づいて探索された、処理対象の構成要素の多重度設定値１５０８に、ボトルネック解析処理２０２または影響解析処理２０４において算出された必要多重度１４１０を設定する。

図１９は、影響解析モジュール３２４が行う影響解析処理（図２のステップ２０４）の概要を示すフローチャートである。

まず、最下位レベルの必要多重度を再算出する（ステップ１９０１）。ステップ１９０１では、ある構成要素の多重度を修正したことにより影響を受ける他の最下位レベルの各構成要素・各時間帯の多重度を再算出する。ステップ１９０１の処理の詳細は、後述する図２０−２２で説明する。次に、最下位レベルの構成要素の多重度設定値と、ステップ１９０１において再算出された必要多重度に基づいて、上位レベルの各構成要素・各時間帯の多重度設定値と必要多重度を階層別に再算出する（ステップ１９０２）。次にステップ１９０１もしくはステップ１９０２において再算出した多重度設定値と必要多重度を比較し、各構成要素・各時間帯において不足している多重度を再算出する（ステップ１９０３）。次に、臨界多重度と、ステップ１９０２により算出した必要多重度をもとに、各サーバ・各時間帯の負荷状態を算出し、パワー不足のサーバ・時間帯を再解析する（ステップ１９０４）。次に、サブシステム内部構成定義群３３０とシステム間構成定義３２９、およびステップ１９０１−１９０４の影響解析結果から、各階層・各時間帯の影響解析結果情報を作成する（ステップ１９０５）。最後に、ステップ１９０５で作成された影響解析結果情報を端末に表示する（ステップ１９０６）。

以上の処理のうち、ステップ１９０２−１９０４は、ステップ１９０１で再算出した多重度設定値と必要多重度を入力として用いる以外は、図１３に示すボトルネック解析処理のステップ１３０２−１３０４と同様の処理を行う。また、ステップ１９０５−１９０６は、表示画面図５（特に影響解析結果５２０）に表示する項目の違い以外は、図１３のステップ１３０５−１３０６と同様の処理を行う。従って、ステップ１９０２の詳細は図１５に、ステップ１９０３の詳細は図１６に、ステップ１９０４の詳細は図１７にそれぞれ図示されている。

図２０は、図１９のステップ１９０１（最下位レベルの必要多重度の再算出処理）の詳細を示すフローチャートである。ステップ１９０１では、サブシステム内部構成定義群３３０とシステム間構成定義３２９を以下のサブステップにて利用する。また、ステップ１９０１では、図１４と同様に、ステップ２００１からステップ２００７までを時間帯（時間の分割）の数だけ繰り返し、また同様にステップ２００２からステップ２００６までを上流の構成要素から下流の構成要素に向かって、構成要素の数だけ繰り返す。

まず、上流から流入する追加リクエスト発生率を算出する（ステップ２００３）。具体的には、上流の各構成要素からの追加リクエスト発生率２００８（後述するステップ２００５にて説明する）に基づいて、上流の構成要素から計算対象の構成要素に追加流入すると予測される追加リクエスト発生率２０１２をリクエストパス毎に算出し、その算出結果を、構成要素・時間帯・リクエストパス毎のリクエスト発生率３２３（図３）に格納する。ステップ２００３の処理の詳細は、後述する図２１で説明する。（（（図２５？？？）
次に、合計リクエスト発生率と必要多重度を再算出する（ステップ２００４）。具体的には、未到達リクエスト発生率１４１２、処理済リクエスト発生率１４１３、平均レスポンス１４１４（いずれも、図１５のステップ１４０５で用いるものと同様）、およびステップ２００３で算出した追加リクエスト発生率２０１２をもとに、計算対象の構成要素のリクエストパス毎の全リクエスト発生率と、全リクエストを処理するのに必要な多重度を再算出し、それぞれ再算出後の全リクエスト発生率２０１０と再算出後の必要多重度２００９に格納する。

次に、下流へ流出する追加リクエスト発生率を算出する（ステップ２００５）。具体的には、ステップ２００４で再算出された算出後の全リクエスト発生率２０１０、修正後の多重度３２７（図１８の多重度修正処理により修正された必要多重度）、多重度設定値１５０８、および元の全リクエスト発生率１４１１に基づいて、計算対象の構成要素の多重度設定値を修正したことにより、下流の構成要素に追加流入すると予測される追加リクエスト発生率を算出し、下流への追加リクエスト発生率２０１１として格納する。そして、この算出結果である下流への追加リクエスト発生率２０１１は、その構成要素より下流の構成要素に対するステップ２００３の処理において、情流からの追加リクエスト発生率２００８として利用される。

図２１及び図２２は、図２０のステップ２００３（上流の構成要素から流入する追加リクエスト発生率の算出処理）における追加リクエスト発生率の算出方法を詳細に示した説明図である。図２１は、修正後の多重度が依然として必要多重度に達していない場合を示し、図２２は、修正後の多重度が必要多重度を上回っている場合を示す。

図２１では、ある前方ティア（上流）の多重度変更前の状態２１０１において、元の全リクエスト発生率２１０４と、多重度設定値から算出した上限リクエスト発生率２１０５が図のような関係である場合、その差が未到達リクエスト発生率２１０３となる。多重度設定値の変更後の状態２１１３において、上限リクエスト発生率２１０９が図のように増加したとすると、元の上限リクエスト発生率２１０５との差が、後方ティア（下流）に流出する追加リクエスト発生率２１０７となる。また、元の全リクエスト発生率２１０８（＝２１０４）と修正後の上限リクエスト発生率２１０９の差が再算出後の未到達リクエスト発生率２１０６となる。

この状況において、後方ティア（下流）の元の全リクエスト発生率２１１１が図のような値であるとすると、前方ティアの多重度を変更したことにより（状態２１１３）、追加リクエスト発生率２１０７が、後方ティアに新たに流入する追加リクエスト発生率２１１０となる。また、将来、前方ティアの多重度をさらに増加させた場合、前方ティアの再算出後の未到達リクエスト発生率２１０６も、さらに後方ティアに流入する可能性がある。これらのリクエスト発生率２１０７と２１０６を合算したものが、将来後方ティアに流入する可能性がある追加リクエスト発生率２１１２である。

図２２では、ある前方ティア（上流）の多重度変更前の状態２１０２において、元の全リクエスト発生率２１１５と、多重度設定値から算出した上限リクエスト発生率２１１６が図のような関係である場合、その差が未到達リクエスト発生率２１１４となる。多重度設定値の変更後の状態２１２４において、上限リクエスト発生率２１２０が図のように増加したとすると、元の上限リクエスト発生率２１１６との差が、後方ティア（下流）に流出する追加リクエスト発生率２１１７となる。また、元の全リクエスト発生率２１１８（＝２１１５）＜上限リクエスト発生率２１２０となるので、再算出後は、未到達リクエスト発生率は存在しない（この点が、図２１と異なる）。

この状況において、後方ティア（下流）の元の全リクエスト発生率２１２２が図のような値であるとすると、前方ティアの多重度を変更したことにより（状態２１２４）、追加リクエスト発生率２１１７が、後方ティアに新たに流入する追加リクエスト発生率２１２１となる。また、将来、前方ティアに流入するリクエストが増加した場合、前方ティアの多重度変更後（多重度再算出後）の上限リクエスト発生率２１２０と、元の全リクエスト発生率２１１８（＝２１１５）との差分２１１９も、さらに後方ティアに追加流入する可能性がある。従って、これらのリクエスト発生率２１１７と２１１９を合算したものが、将来後方ティアに流入する可能性がある追加リクエスト発生率２１２３である。

なお、前方ティアの多重度を変更することにより新たに流入するリクエスト発生率を示す「現在の想定追加リクエスト発生率」や、前方ティアの多重度を変更することにより将来流入する可能性のあるリクエスト発生率を示す「将来の想定追加リクエスト発生率」は、０やマイナスになることがある。これらの数値が「０」である場合は、「追加リクエストが発生しない」ことを意味し、これらの数値が「マイナス」である場合は、「元の全リクエスト発生率と負の追加リクエスト発生率との合計分だけ、リクエスト発生率が減少する」ことを意味する。

ここで、図２０のステップ２００５に示す、多重度修正後の、リクエストパス毎の下流に流出する追加リクエスト発生率の算出方法の一例を示す。なお、あるリクエストパスｋの多重度変更後の上限リクエスト発生率Ｒｋａは、全リクエスト発生率に対するｋの全リクエスト発生率の占める割合に比例すると仮定する。または、上限リクエスト発生率Ｒｋａは、処理済全リクエスト発生率に対するｋの処理済全リクエスト発生率に占める割合に比例する、もしくは、未到達全リクエスト発生率に対するｋの未到達全リクエスト発生率に占める割合に比例すると考えても良い。つまり、あるリクエストパスｋの多重度変更後の上限リクエスト発生率Ｒｋａは、
Ｒｋａ＝α（Ｒｋｔ／Ｒｔ）…式１
と表せる。ここで、αは比例定数（全てのリクエストパスで共通と仮定する。）、Ｒｋｔはリクエストパスｋの全リクエスト発生率、Ｒｔは全リクエスト発生率である。従って、多重度変更後にリクエストパスｋのリクエスト処理に利用される多重度ｍｋａは、リクエストパスｋの平均レスポンスをＴｋとして、
ｍｋａ＝Ｒｋａ・Ｔｋ＝α（Ｒｋｔ／Ｒｔ）Ｔｋ…式２
と表せる（図１０の式１００９、およびＲｋａに式１を代入）。一方、リクエストパスがｎ種類ある場合、トータルの変更後の多重度（実際に設定するパラメタ）をＭｔａとすると、

となる。ここで、式３に式２を代入すると、

となる。式１に式４を代入することにより、リクエストパスｋの多重度修正後の追加リクエストＲｋｅは、リクエストパスｋの処理済リクエスト発生率Ｒｋｒ（多重度変更前の実際に流入していたリクエスト発生率）とすると、

と表せる。

図２３は、図２０のステップ２００３および２００５で算出される追加リクエスト発生率が、下流の構成要素や上位レベルの構成要素に伝わる様子を示した説明図である。図２３におけるシステム構成は、図４と同様に、ＤＢサーバはＤＢＭＳからなり、スレッドとインスタンスには業務ＡＰが存在し、プロセスはスレッドとインスタンスからなり、ＡＰサーバはプロセスとＨＴＴＰデーモンからなり、サブシステムは、負荷分散器、ＡＰサーバ、ＤＢサーバからなる。そしてリクエストは、最下位レベルのシステム構成要素を、負荷分散器→ＨＴＴＰデーモン→スレッド→インスタンス→ＤＢＭＳの順に伝わると仮定する。

フローチャート２２０１は、各構成要素で算出される追加リクエスト発生率が、下流の構成要素に伝わる様子を示したものである（図１０のステップ１９０１に相当し、詳細は２０参照）。フローチャート２２０１の各ステップは、影響解析モジュール（図３）が処理を行う。

まず、負荷分散器の上流の構成要素における未到達・処理済リクエスト発生率２２０３に基づいて、負荷分散器の再算出後の全リクエスト発生率２２０５と、下流（ＨＴＴＰデーモン）への追加リクエスト発生率２２０６を算出する（ステップ２２０４）。次に、負荷分散器からの追加リクエスト発生率２２０６と、負荷分散器における未到達・処理済リクエスト発生率２２０７に基づいて、ＨＴＴＰデーモンの再算出後の全リクエスト発生率２２０９と、下流（スレッド）への追加リクエスト発生率２２１０を算出する（ステップ２２０８）。次に、ＨＴＴＰデーモンからの追加リクエスト発生率２２１０と、ＨＴＴＰにおける未到達・処理済リクエスト発生率２２１１に基づいて、スレッドの再算出後の全リクエスト発生率２２１３と下流への追加リクエスト発生率２２１４を算出する（ステップ２２１２）。

次に、スレッドからの追加リクエスト発生率２２１４と、スレッドにおける未到達・処理済リクエスト発生率２２１５に基づいて、インスタンスの再算出後の全リクエスト発生率２２１７と、下流（インスタンス）への追加リクエスト発生率２２１８を算出する（ステップ２２１６）。最後に、インスタンスからの追加リクエスト発生率２２１８と、インスタンスからの未到達・処理済リクエスト発生率２２１９に基づいて、ＤＢＭＳの再算出後の全リクエスト発生率２２２１を算出する（ステップ２２２０）。

なお、フローチャート２２０１において、未到達・処理済リクエスト発生率２２０３、２２０７等は、図２０における未到着リクエスト発生率１４１２及び処理済リクエスト発生率１４１３に相当し、再算出後の全リクエスト発生率２２０５、２２０９等は、図２０における再算出後の全リクエスト発生率２０１０に相当し、下流への追加リクエスト発生率２２０６、２２１０等は、図２０における下流への追加リクエスト発生率２０１１に相当する。

フローチャート２２０２は、上位レベルの構成要素の全リクエスト発生率が、再算出により変化していく様子を示したフローチャート（図１９のステップ１９０２に相当し、詳細は図１５参照）である。フローチャート２２０２の各ステップは、影響解析モジュール３２４（図３）が処理を行う。

まず、サーバ外部からＤＢサーバへ流入する全リクエスト発生率２２２１に基づいて、ＤＢサーバの再算出後の全リクエスト発生率２２２３を算出する（ステップ２２２２）。次に、業務ＡＰ外部から業務ＡＰへ流入する全リクエスト発生率２２１３もしくは２２１７に基づいて、業務ＡＰの再算出後の全リクエスト発生率２２２５を算出する（ステップ２２２４）。ここで、全リクエスト発生率２２１３を利用する場合は、スレッド内の業務ＡＰについて計算することを意味し、全リクエスト発生率２２１７を利用する場合は、インスタンス内の業務ＡＰについて計算することを意味する。

次に、プロセス外部からプロセスへ流入する全リクエスト発生率２２１３と２２１７に基づいて、プロセスの再算出後の全リクエスト発生率２２２７を算出する（ステップ２２２６）。次に、サーバ外部からＡＰサーバへ流入する全リクエスト発生率２２０９と、全リクエスト発生率２２２７（ステップ２２２６で算出されたもの）に基づいて、ＡＰサーバの再算出後の全リクエスト発生率２２２９を算出する（ステップ２２２８）。最後に、サブシステム外部からサブシステムへ流入する全リクエスト発生率２２０５と、全リクエスト発生率２２２９（ステップ２２２８で算出されたもの）に基づいて、サブシステムの再算出後の全リクエスト発生率２２３１を算出する（ステップ２２３０）。

図２４は、図２のステップ２０５（多重度変更処理）の詳細を示すフローチャートである。

まず、多重度変更モジュール３２８は、変更対象の構成要素の多重度変更が手動変更であるか自動変更であるかを判断する（ステップ２３０１）。具体的には、多重度変更モジュール３２８は、構成要素毎に多重度を手動変更するのか自動変更するのかを定義した多重度変更方法２３０６（図８の多重度変更方法８１５、８１７等に相当）、および構成要素の子構成要素をどの範囲まで自動変更するのかを定義した多重度変更適用ポリシー３３１（図３）に基づいて判断する。

ステップ２３０１で自動変更であると判断した場合は、多重度変更モジュール３２８は、多重度変更を行う（ステップ２３０３）。具体的には、多重度修正処理（図２のステップ２０３）及び影響解析処理（図２のステップ２０４）により修正された修正後の多重度３２７を、サブシステム内部構成定義３１６およびシステム間構成定義３２９に基づいて検索された、処理対象の構成要素の多重度設定値１５０８に変更するように、多重度変更モジュール３２８は、サブシステム別多重度調整サーバ１０５の多重度変更指示モジュール３１５に対して、多重度変更を指示する情報を送信する。

多重度変更モジュール３２８から多重度変更指示情報を受信した多重度変更指示モジュール３１５は、対象の構成要素に対して多重度設定値の変更指示を行う（ステップ２３０５）。具体的には、受信した多重度変更指示情報、サブシステム内部構成定義３１６および多重度設定メタ定義３１７に基づいて、構成要素毎の多重度定義３１１を変更し、多重度調整エージェント１１０、１１２に多重度定義３１１の再ロードを指示する。

ステップ２３０１で手動変更であると判断した場合には、多重度変更モジュール３２８は、監視対象システム運用・管理者からの変更後の多重度の入力を受付け、変更された多重度に関する情報を多重度変更指示モジュール３１５に送信する（ステップ２３０２）。そして、多重度変更指示モジュール３１５は、上述したステップ２３０５の処理を行う。

図２４に示す処理により、手動・自動いずれの場合も、各製品に分散する多重度設定のための定義情報を、一箇所で、製品横断的に管理することができるため、個別製品の定義ファイルの詳細な仕様を理解する手間を省くことができる。

なお、受信多重度制御モジュール３０５（図３：多重度調整エージェント１１２）が、負荷分散方式として入力キュー方式を採用した場合の、必要なキュー長の算出方法の例として（１）履歴を積分するか、または履歴を合算する。（２）キュー長を実測し、標準偏差から求める。（３）キュー長を既存の確率関数にてモデル化し、正規化標準偏差から求める。（４）確率を先に決め、検定によって求める、等が考えられる。

実施例１によれば、あるシステム構成要素の多重度を変更したことにより、他のシステム構成要素のリクエスト発生率がどのように変化し、それにより必要多重度（システム構成要素にて処理することを期待されているリクエストを全て処理するのに必要な多重度）がどのように変化するのかを算出し、結果をシステム利用者に提示するため、新規に追加するリクエストパスや多重度の変更がシステム全体に与える負荷等の影響を調査することができるという効果がある。

特に、インターネットを用いたビジネスにおいては、企業の成長やサービスの拡大と共に、サービスの利用者（顧客）が増大するのが常である。このようにビジネスの規模にしたがってシステムのキャパシティ（多重度）を増やす際の設計ノウハウに対するニーズは高く、本発明はそれに対するソリューションを提供できるという効果がある。

図２５は、本発明をグリッドコンピューティングへ応用した例を示したシステム構成図である。なお、グリッドコンピューティングとは、ネットワークを介して複数のコンピュータを結ぶことで仮想的に高性能コンピュータをつくり、利用者はそこから必要な処理能力や記憶容量を取り出して使うシステムであり、複数のコンピュータに並列処理を行わせることで、高速に大量の処理を実行できるシステムである。

図２５では、科学技術計算依頼端末２４０１からのリクエストを、グリッドスケジューラ２４０２が受け付け、サーバプール２４０６内の複数の計算ホスト２４０３、計算ＰＣ２４０４、計算サーバ２４０５に対して、適切に負荷分散しながらリクエストを中継するという構成となっている。多重度調整エージェントを各計算機２４０３、２４０４、２４０５に配置し、統合多重度解析サーバ相当の機能をグリッドスケジューラ２４０２に配置することで、リソースの有効利用とサーバの安定稼動を両立するような、負荷分散処理を行うことが可能となる。なお、対象システムが異なる以外は、実施例１で述べた構造、処理と同様である。

本実施例に示すように、本発明はグリッドコンピューティングにも応用可能であり、この例のようにビジネスの規模にしたがってシステムのキャパシティ（多重度）が増えるようなシステム設計のソリューションを提供できるという効果がある。

本発明の一実施例である多重度調整システムの全体構成図を示す。 本発明の処理概要を示したシーケンス図である。 図１の多重度調整システムの詳細な構成を示したシステム構成図である。 監視対象システムの具体例である銀行システムのシステム構成図である。 リクエスト発生率・多重度表示／設定画面を示す画面図である。 ボトルネック解析後の連携表示画面を詳細に示す画面図である。 影響解析後の連携表示画面を詳細に示す画面図である。 システム間構成定義とサブシステム内部構成定義の構造を示したデータ構造図である。 履歴および定義情報の構造を示したデータ構造図である。 リクエスト発生率とシステム構成要素の関係を示す図である。 アプリケーションの必要多重度の時間変化を示す図である。 実測値収集処理の流れを詳細に示すフローチャートである。 ボトルネック解析処理の概要を示すフローチャートである。 最下位レベルの必要多重度の算出処理を詳細に示すフローチャートである。 上位レベルの必要多重度の算出処理を詳細に示すフローチャートである。 不足する多重度の算出処理を詳細に示すフローチャートである。 サーバの負荷解析処理を詳細に示すフローチャートである。 多重度修正処理を詳細に示すフローチャートである。 影響解析処理の概要を示すフローチャートである。 最下位レベルの必要多重度の再算出処理を詳細に示すフローチャートである。 上流から追加流入するリクエスト発生率の関係の一例を示す図である。 上流から追加流入するリクエスト発生率の関係の他の例を示す図である。 追加リクエスト発生率が下流の構成要素や上位レベルの構成要素に伝わる様子を示す図である。 多重度変更処理を詳細に示すフローチャートである。 本発明をグリッドコンピューティングへ応用した場合のシステム構成図である。

符号の説明

１０２：多重度調整端末、１０３：同時実行多重度調整システム、１０５：サブシステム別多重度調整サーバ、１０４：統合多重度解析サーバ、１０６：監視対象システム利用端末、１０７：監視対象システム、１０８：サブシステム、１１０：多重度調整エージェント（送信側）、１１２：多重度調整エージェント（受信側）、１１３：監視対象システム構成要素（送信側）、１１５：監視対象システム構成要素（受信側）、１１４：リクエスト情報

Claims (8)

1. 監視対象システムに対するリクエストの多重度を調整する多重度調整システムにおいて、
   前記監視対象システムに含まれる構成要素に対するリクエストをもとに、該構成要素ごとのリクエストの多重度を判断する多重度調整エージェントと、
   前記リクエストの多重度に関する情報を前記多重度調整エージェントから取得して、前記構成要素ごとのリクエスト情報として記憶する多重度調整サーバと、
   該多重度調整サーバから、前記記憶された構成要素ごとのリクエスト情報を取得し、該取得したリクエスト情報をもとに、前記構成要素ごとのリクエストの多重度を解析するとともに、該解析結果に応じて前記構成要素ごとのリクエストの多重度を変更する統合多重度解析サーバとを備えることを特徴とする多重度調整システム。
2. 前記統合多重度解析サーバは、前記変更された多重度に関する情報を前記多重度調整サーバに送信し、
   前記多重度調整サーバは、前記統合多重度解析サーバから受信した情報をもとに、前記多重度調整エージェントに対して、前記多重度の変更指示を行うことを特徴とする請求項１記載の多重度調整システム。
3. 前記リクエストの多重度に関する情報は、該リクエストが行われる時間帯ごと、及び前記リクエストが前記監視対象に含まれるどの構成要素を通過するかを示すリクエストパスごとに定義される情報であることを特徴とする請求項１記載の多重度調整システム。
4. 前記多重度調整エージェントは、前記監視対象システムに含まれる構成要素に対するリクエストを、未送信リクエスト情報、未処理リクエスト情報及び処理済リクエスト情報に分類して記憶することを特徴とする請求項１記載の多重度調整システム。
5. 監視対象システムにおけるリクエストの多重度を修正するサーバにおいて、
   該リクエストが対象とする構成要素、該リクエストの時間帯、該リクエストが通過する構成要素を示すリクエストパスに関する情報に基づいて、該リクエストの多重度の実測値を収集するリクエスト実測値収集部と、
   該収集された実測値を解析して、前記監視対象システムに含まれる構成要素のうち、リクエスト処理のボトルネックになっている構成要素を解析するボトルネック解析部と、
   該解析結果をもとに、該ボトルネックを解消するよう多重度を修正する多重度修正部と、
   該修正された多重度に基づいてリクエスト処理が行われた場合の影響を解析する影響解析部と、
   該影響解析結果に基づいて、前記リクエストに関する多重度を変更する多重度変更部とを備えることを特徴とするサーバ。
6. 前記サーバは、
   監視対象システムに含まれるサブシステム間の関係を定義するシステム間構成定義、及び前記サブシステムそれぞれに含まれる構成要素を定義するサブシステム内部構成定義に基づいて、前記多重度の変更を行うことを特徴とする請求項５記載のサーバ。
7. 前記サーバは、
   前記ボトルネック解析結果、前記多重度修正結果、および前記影響解析結果を表示する表示情報を作成することを特徴とする請求項５記載のサーバ。
8. 監視対象システムに対するリクエストの多重度を調整する多重度調整システムにおける多重度調整方法において、
   前記多重度調整システムの多重度調整エージェントは、前記監視対象システムに含まれる構成要素に対するリクエストをもとに、該構成要素ごとのリクエストの多重度を判断し、
   前記多重度調整システムの多重度調整サーバは、前記リクエストの多重度に関する情報を前記多重度調整エージェントから取得して、前記構成要素ごとのリクエスト情報として記憶し、
   前記多重度調整システムの統合多重度解析サーバは、前記多重度調整サーバから前記記憶された構成要素ごとのリクエスト情報を取得し、該取得したリクエスト情報をもとに、前記構成要素ごとのリクエストの多重度を解析するとともに、該解析結果に応じて前記構成要素ごとのリクエストの多重度を変更することを備えることを特徴とする多重度調整方法。
   

Images