JP6019995B2 - 分散システム、サーバ計算機、及び障害発生防止方法 - Google Patents

Description

本発明は分散システム、サーバ計算機、分散管理サーバ及び障害発生防止方法に関する。

業務システムにおいて、アプリケーションサーバに実装された業務アプリケーションのプログラムの欠陥を原因とする障害が発生することにより、業務システム全体の障害が引き起こされるケースがしばしば発生する。業務アプリケーションにおける障害は、例えば以下の通りである。

第１に、デッドロックが挙げられる。これは、アプリケーションロジックを実行する複数のスレッド間で、互いの排他制御（ロックの獲得など）が交差することにより、それぞれのスレッドの実行がブロックされたままの状態になることである。この場合、ブラウザなど、アプリケーションの呼び出し元となるクライアントアプリケーションにおいては、リクエストの応答が返らず、画面が更新されないなどの問題を引き起こす。

第２に、過剰なメモリの消費が挙げられる。これは、業務に関するクエリ処理などで大量のデータを扱うアプリケーションロジックにおいて、１回のロジックの実行により、アプリケーションサーバで使用可能なメモリ領域を圧迫する状態に陥ることである。この状況では、同じプロセス上で並行して動作する他のアプリケーションロジックを実行中のスレッドにおいて、処理の遅延が発生したり、処理実行時にメモリ不足によるエラーが発生したりすることがある。そして、最悪の場合、アプリケーションサーバのプロセス自体が異常終了する。

第３に、過剰なＣＰＵ（Central Processing Unit）の消費（過剰なＣＰＵ使用率の高さ）が挙げられる。これは、無限ループの発生や、冗長なアプリケーションロジックにより、必要以上にＣＰＵを使用する状態になることである。この場合、アプリケーションの呼び出し元においては、リクエストの応答が返らず、画面が更新されないなどの問題を引き起こす。また、同じプロセス上で並行して動作する他のアプリケーションロジックを実行中のスレッドにおいて、処理の遅延が発生するなどの弊害を引き起こす。

このような事象の発生時には、大抵の場合、障害が発生したアプリケーションサーバを再起動することにより解消できる。しかし、いずれの場合も、根本解決には対象となるアプリケーションのプログラムの改修が必須である。そのため、改修後のアプリケーションが用意できるまでの間、システム運用者は、上記のような障害の再発を防ぐため、定期的なアプリケーションサーバの再起動や、アプリケーションサーバに対するパラメータのチューニングなどの暫定対応に迫られることがある。

障害処理の技術として、特許文献１においては、障害要因となるコンポーネントを特定する管理装置が開示されている。具体的には、アプリケーションサーバを備えた計算機と管理システムを備えた計算機とがネットワークで接続されているシステムにおいて異常が発生した場合に、管理装置は、アプリケーションサーバと管理システムのいずれにおいて障害が発生したかを特定することができる。

特許文献２においては、障害の予兆や障害発生に適応してエラーを発生させずかつ性能を落とさないコンポーネントソフトウェアの運用基盤が開示されている。具体的には、複数のコンポーネント（ソフトウェア部品）から構成されるコンポーネントソフトウェアを実行している最中に、コンポーネントソフトウェアの運用基盤は、コンポーネントを他のコンポーネントと入れ替える。

特許文献３においては、複数のアプリケーションサーバ計算機と管理サーバ計算機とを備えたアプリケーション管理システムが開示されている。アプリケーションサーバ計算機は、管理サーバ計算機に格納されたアプリケーション動作定義保存ファイルを参照し、実行要求のあったアプリケーションの実行を制御し、管理する。そして実行したアプリケーションに異常が発生した場合には、アプリケーションサーバ計算機は、他のアプリケーションサーバ計算機又は外部計算機にその旨を通知する。

特開２０１０−９１２７号公報 特開２００６−３３８０６９号公報 特開２００５−２０９０２９号公報

ところで、昨今、クラウド・コンピューティング技術を用いたシステム化が普及しつつある。このシステム化は、多数のネットワーク上に分散的に配置された大多数のアプリケーションサーバにより、システムが構成されるというものである。このような環境においては、負荷が分散される構成となるため、１台の（障害発生などに伴う）サーバに発生した異常がシステム全体の障害に発展することにはなりにくい。

しかし、アプリケーション自体のプログラムの問題に起因する障害の場合には、全てのアプリケーションサーバにおいて今後同じ障害が発生するリスクが潜在する。そのため、従来のバージョンにダウングレードするなどの処置を取らない限り、上述したようなシステム運用者による暫定対応は避けられない。さらに対象のサーバ台数が多くなると、それだけそのような障害に遭遇する確率も高くなり、延いては暫定対応のための作業コストが増大することに繋がる。

特許文献１、２においては、クラウド・コンピューティングのように、アプリケーションサーバ等のサーバを複数配置した状況は考慮されていない。

特許文献３にかかるアプリケーション管理システムでは、アプリケーションサーバ計算機において実行したアプリケーションに異常が発生した場合でも、他のアプリケーションサーバ計算機が同様の異常を発生させないようにすることはできない。

本発明は、このような問題点を解決するためになされたものであり、システム運用者への負荷を掛けずにサーバにおける障害発生を防止する分散システム、サーバ計算機、分散管理サーバ及び障害発生防止方法を提供することを目的とする。

本発明の第１の態様は、分散システムを含む。この分散システムは、同じアプリケーションを実行可能な第１のサーバ及び第２のサーバを備える。第１のサーバにおいてアプリケーションの障害が発生した場合に、第１のサーバは、アプリケーションの障害原因を特定する障害情報を生成する。第２のサーバは、障害情報に基づいて決定された、アプリケーションの障害発生を防止するための障害発生防止処理を実行する。

本発明の第２の態様は、サーバ計算機を含む。このサーバ計算機は、分散システムに設けられ、同じアプリケーションを実行可能な他のサーバ計算機と接続されたサーバ計算機である。サーバ計算機は、アプリケーションの障害が発生した場合に、アプリケーションの障害原因を特定する障害情報を生成する。そして、サーバ計算機は、他のサーバがアプリケーションの障害原因を特定する障害情報を生成した場合に、障害情報に基づいて決定された、前記アプリケーションの障害発生を防止するための障害発生防止処理を実行する。

本発明の第３の態様は、分散管理サーバを含む。この分散管理サーバは、同一のアプリケーションを実行可能な第１のサーバ及び第２のサーバを備えた分散システムに設けられている。分散管理サーバは、第１のサーバから、第１のサーバにおけるアプリケーションの障害原因を特定する障害情報を受信した場合に、第２のサーバにおいてアプリケーションの障害発生を防止するための障害発生防止処理を実行するために用いられる情報として、第２のサーバに障害情報を通知する。

本発明の第４の態様は、障害発生防止方法を含む。この障害発生防止方法は、同じアプリケーションを実行可能な第１のサーバ及び第２のサーバを備える分散システムにおいてアプリケーションの障害発生を防止する障害発生防止方法であり、以下のステップ（ａ）及び（ｂ）を含む。
（ａ）前記第１のサーバにおいて前記アプリケーションの障害が発生した場合に、前記第１のサーバは、前記アプリケーションの障害原因を特定する障害情報を生成すること、
（ｂ）前記第２のサーバは、前記障害情報に基づいて決定された、前記アプリケーションの障害発生を防止するための障害発生防止処理を実行すること。

本発明により、システム運用者への負荷を掛けずにサーバにおける障害発生を防止する分散システム、サーバ計算機、分散管理サーバ及び障害発生防止方法を提供することができる。

実施の形態１にかかる分散管理システムの第一の構成例を示すブロック図である。 実施の形態１にかかる分散管理システムの第二の構成例を示すブロック図である。 実施の形態２にかかる分散管理システムの構成例を示すブロック図である。 実施の形態２にかかるアプリケーションサーバにおける処理の一例を示したフローチャートである。 実施の形態２にかかるアプリケーションサーバにおける処理の一例を示したフローチャートである。 実施の形態２にかかる障害候補格納部に格納されるデータのイメージ図である。 実施の形態２にかかる分散管理サーバにおける処理の一例を示したフローチャートである。 実施の形態２にかかる障害情報記憶部に格納されるデータ例のイメージ図である。 実施の形態２にかかるアプリケーションサーバが実行する監視処理の一例を示したフローチャートである。 実施の形態２にかかる、デッドロック障害発生防止のためのリクエスト処理制御例のイメージ図である。 関連技術にかかる、デッドロック障害が発生しうる場合のリクエスト処理制御のイメージ図である。 実施の形態２にかかる、時刻ｔ１における障害情報記憶部１６内のデータ例が示された表である。 実施の形態２にかかる、時刻ｔ２における障害情報記憶部１６内のデータ例が示された表である。 実施の形態２にかかる、時刻ｔ３における障害情報記憶部１６内のデータ例が示された表である。 実施の形態２にかかる、過剰なメモリ消費の障害発生防止のためのリクエスト処理制御例のイメージ図である。 関連技術にかかる、過剰なメモリ消費の障害が発生しうる場合のリクエスト処理制御のイメージ図である。 実施の形態２にかかる、時刻ｔ４における障害情報記憶部１６内のデータ例が示された表である。 実施の形態２にかかる、時刻ｔ５における障害情報記憶部１６内のデータ例が示された表である。 実施の形態２にかかる、時刻ｔ６における障害情報記憶部１６内のデータ例が示された表である。 実施の形態２にかかる、過剰なＣＰＵ消費の障害発生防止のためのリクエスト処理制御例のイメージ図である。 関連技術にかかる、過剰なＣＰＵ消費の障害が発生しうる場合のリクエスト処理制御のイメージ図である。

実施の形態１
以下、図面を参照して本発明の実施の形態１について説明する。図１は、実施の形態１にかかる分散システム１の構成例を示すブロック図である。

分散システム１は、同じアプリケーションを実行可能なサーバ計算機２（第１のサーバ）及びサーバ計算機３（第２のサーバ）を備える分散システムである。分散システム１は、例えばクラウド・コンピューティング等の分散処理システムである。分散システム１が備えるサーバ計算機の数は２個に限られず、３個以上であってもよい。サーバ計算機２、３は、同一のアプリケーションであるアプリケーション４、５をそれぞれ実行可能な状態で格納している。

サーバ計算機２は、自身が実行するアプリケーション４の障害が発生した場合に、そのアプリケーション４の障害原因を特定する障害情報を生成する。ここで障害情報とは、例えばアプリケーション４において障害を生じさせたコンポーネントや、それに付随するインタフェースといったものを示す。

サーバ計算機３は、サーバ計算機２が生成した障害情報に基づいて決定された、アプリケーション５の障害発生を防止するための障害発生防止処理を実行する。

例えば、サーバ計算機２の障害が、サーバ計算機２のクライアントからのリクエストに基づいて発生したものであり、サーバ計算機２がその障害にかかる障害情報を生成したとする。このとき、サーバ計算機３は、その障害情報に基づき、サーバ計算機３のクライアントからのリクエストをモニタリングすることにより、障害発生防止処理を実行する。モニタリングの例として、サーバ計算機３は、サーバ計算機２に障害が発生したときにクライアントからリクエストされたアプリケーションの機能と同じ機能が、自身のクライアントからリクエストされているか否かを判定する。そして、同じ機能が自身のクライアントからリクエストされた場合には、その機能の実行を停止する等して、サーバ計算機２と同じ障害が発生することを防止する。

以上に説明したような処理を分散システム１が実行することにより、分散システム１は、システム運用者が何らかの処理を実行することなく（システム運用者への負荷を掛けずに）、サーバにおける障害発生を防止することができる。

＜変形例１＞
上述のサーバ計算機２は、サーバ計算機３の実行する処理をさらに実行してもよい。すなわち、サーバ計算機２は、アプリケーション４の障害が発生した場合に、アプリケーション４の障害原因を特定する障害情報を生成する。そしてサーバ計算機２は、サーバ計算機３がアプリケーション５の障害原因を特定する障害情報を生成した場合に、その障害情報に基づいて決定された、前記アプリケーションの障害発生を防止するための障害発生防止処理を実行する。サーバ計算機３も、同様にサーバ計算機２の実行する処理を実行してもよい。つまり、サーバ計算機は、自身に障害が発生した場合に他のサーバ計算機が障害発生防止処理を実行するために必要な障害情報を生成するだけでなく、他のサーバ計算機が障害情報を生成した場合にもその障害情報に基づいた障害発生防止処理を実行することができる。このようなサーバ計算機が分散システム１に備わることにより、分散システム１における障害発生防止をより効率的にすることができる。

＜変形例２＞
上述の分散システム１は、サーバ計算機２、３の他に、分散システム１を管理する分散管理サーバ６が設けられていてもよい。図２は、そのような分散システム１の構成例を示すブロック図である。分散管理サーバ６は、分散システム１においてサーバ計算機２、３と接続されている。サーバ計算機２、３の説明については図１と同様である。

分散管理サーバ６は、サーバ計算機２から、サーバ計算機２におけるアプリケーションの障害原因を特定する障害情報を受信する。分散管理サーバ６は、サーバ計算機３においてアプリケーション５の障害発生を防止するための障害発生防止処理を実行するために用いられる情報として、サーバ計算機３に障害情報を通知する。以上の処理を実行することにより、分散管理サーバ６は、サーバ計算機３における障害発生を防止することができる。

ここで、サーバ計算機３が実行する障害発生防止処理は、サーバ計算機３が障害情報に基づいてその処理内容を決定してもよいし、分散管理サーバ６が障害情報に基づいてその処理内容を決定してもよい。

実施の形態２
以下、図面を参照して本発明の実施の形態２について説明する。図３は、実施の形態２にかかる分散管理システム１０の構成例を示すブロック図である。

分散管理システム１０は、アプリケーションサーバ１１Ａ、１１Ｂ、１１Ｃ、分散管理サーバ２７及びクライアントアプリケーション３４Ａ、３４Ｂ、３４Ｃを備える。なお、以下ではアプリケーションサーバ１１Ａ、１１Ｂ、１１Ｃを総称してアプリケーションサーバ１１と記載し、クライアントアプリケーション３４Ａ、３４Ｂ、３４Ｃを総称してクライアントアプリケーション３４と記載する。

アプリケーションサーバ１１は、分散管理システム１０における業務アプリケーションの実行基盤の役割を果たす。アプリケーションサーバ１１は、ＣＰＵ、メモリなどのリソースを備えるサーバ計算機において実行されるソフトウェアである。アプリケーションサーバ１１は、リクエスト受付部１２、リクエスト解析部１３、運用リクエスト受付部１４、障害情報受信部１５、障害情報記憶部１６、記憶装置１７、障害イベント発行部１８及びアプリケーション実行制御部１９を有する。アプリケーションサーバ１１Ａ〜１１Ｃは分散管理システム１０のネットワーク上において分散配置され、それぞれが同じ構成を有する。

リクエスト受付部１２は、クライアントアプリケーション３４を介して送信されたシステム利用者からの要求（リクエスト）を受け付ける。

リクエスト解析部１３は、リクエスト受付部１２が受け付けたリクエストの詳細情報を解析する。

運用リクエスト受付部１４は、分散管理サーバ２７からアプリケーションサーバ１１に対して要求された運用管理のためのリクエストを受け付ける。

障害情報受信部１５は、他のアプリケーションサーバ内で発生した障害情報を分散管理サーバ２７から受信する。

障害情報記憶部１６は、障害情報受信部１５が受信した障害情報を内部のメモリに保持する。記憶装置１７は、障害情報データを非一時的に保持する記憶装置であり、障害情報記憶部１６は障害情報を必要に応じて記憶装置１７に格納する。

障害イベント発行部１８は、アプリケーションサーバ１１が有するアプリケーションで発生した障害情報を、分散管理サーバ２７を介して接続される他のアプリケーションサーバに送信する。

アプリケーション実行制御部１９は、アプリケーションサーバ１１が有するアプリケーションの実行を制御する。アプリケーション実行制御部は、実行管理部２０、障害監視部２１、障害解析部２２、障害分析部２３、障害候補格納部２４、障害情報検索部２５及びコンポーネント（アプリケーションコンポーネント）２６を有する。以下では、コンポーネント２６Ａ、２６Ｂ、２６Ｃを総称してコンポーネント２６と記載する。

実行管理部２０は、アプリケーション実行制御部１９で動作するコンポーネント２６の実行状況を管理する。具体的には、実行管理部２０は、アプリケーションが呼び出し中であることを示す情報や、現に実行されているリクエスト及びそのリクエストを実行しているスレッドの情報を管理している。

障害監視部２１は、アプリケーションサーバ１１が有するアプリケーションの障害を監視する。例えば障害監視部２１は、プロセスのスレッド情報の一覧（スレッドダンプ）や、メモリ使用量、ＣＰＵ使用率などの各種リソース情報を採取する。

障害解析部２２は、障害監視部２１によって検知された障害の内容を解析する。具体的には、障害解析部２２は、障害監視部２１が採取した各種リソース情報から、コンポーネントの識別名（コンポーネント名）及びそのインタフェース名を抽出する。

障害分析部２３は、障害解析部２２が解析により抽出した情報を基に、発生した障害に関する詳細な分析や、障害の予測に関する演算を行う。

障害候補格納部２４は、障害分析部２３で予測された障害に関する情報を格納する。この情報は障害分析部２３により更新される。

障害情報検索部２５は、障害情報記憶部１６を参照し、アプリケーションに対する障害情報の有無を検索する。

コンポーネント２６は、実際にアプリケーションサーバ１１が有するアプリケーション（アプリケーションサーバの計算機が実行可能な状態で格納しているアプリケーション）を構成しており、業務ロジック（ビジネスロジック）が実装されている。コンポーネント２６は、アプリケーション実行制御部１９上で動作する。アプリケーションサーバ１１Ａ〜１１Ｃが備えるアプリケーションは全て同じものであるため、アプリケーションサーバ１１Ａ〜１１Ｃは同じコンポーネント２６Ａ〜２６Ｃを備える。なお、コンポーネント２６Ａ〜２６Ｃは同じアプリケーションを構成していなくともよい。

分散管理サーバ２７は、分散管理システム１０のネットワーク構成上に分散配置された各アプリケーションサーバを統合的に管理する専用のサーバである。システム管理者は、分散管理サーバ２７を用いることにより分散管理システム１０を管理することができる。分散管理サーバ２７は、アプリケーション格納部２８、アプリケーション情報管理部２９、障害イベント受信部３０、運用操作発行部３２及び障害情報発行部３３を有する。

アプリケーション格納部２８は、アプリケーションサーバ１１に備えられたアプリケーションと同一のアプリケーションを保持する。

アプリケーション情報管理部２９は、アプリケーションサーバ１１に備えられたアプリケーションの詳細情報（バージョン情報など）を管理する。

障害イベント受信部３０は、各アプリケーションサーバの障害イベント発行部１８によって発行された障害情報を含むイベントを受信する。障害イベント受信部３０は、受信したイベントに基づいて、アプリケーションサーバ１１内で発生した障害の内容を解析するイベント解析部３１を有する。

運用操作発行部３２は、管理下のアプリケーションサーバ１１に対して任意の運用操作要求を通知する。

障害情報発行部３３は、特定のアプリケーションサーバ１１の障害解析部２２によって抽出された障害情報を、管理下のアプリケーションサーバ１１に通知する。

クライアントアプリケーション３４は、システム利用者（クライアント）がアプリケーションサーバに備えられたアプリケーションの業務ロジックを呼び出す、クライアント側のアプリケーションである。

なお、様々な処理を行う機能ブロックとして図３に記載されたアプリケーションサーバ１及び分散管理サーバ２７の各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他の回路で構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

以下、実施の形態２における分散管理システム１０の動作の実施例について、図面を用いて詳細に説明する。

まず、アプリケーションサーバ１１における基本的な処理の流れについて示す。

アプリケーションサーバ１１は、Ｗｅｂブラウザなどのクライアントアプリケーション３４からのリクエストを、リクエスト受付部１２によって受信する。

リクエスト解析部１３は、リクエスト受付部１２が受信したリクエストを解析して、リクエストによって呼び出す対象のコンポーネント２６及びそのインタフェース（メソッド）情報を抽出する。リクエスト解析部１３は、抽出した結果をパラメータとして、アプリケーション実行制御部１９に転送する。

アプリケーション実行制御部１９は、アプリケーションが呼び出し中であることを示す情報を実行管理部２０に格納後、リクエストの対象となるコンポーネント２６のインタフェースを用いて業務ロジックを実行する。

業務ロジックの実行が終了すると、アプリケーション実行制御部１９は、実行管理部２０に格納した情報を削除する。この一連の処理が、リクエスト単位でアプリケーションサーバ１１を動作するプロセスのスレッドにより実行される。

また、分散管理サーバ２７は、予めシステム運用者の運用作業によって、分散配置されたアプリケーションサーバ１１の基本情報（ホスト名など）や、各アプリケーションサーバ１１に備えられたアプリケーションの構成情報（アプリケーション名、バージョン名など）を適切に管理する。分散管理サーバ２７は、さらに、管理下の全てのアプリケーションサーバ１１に対して、アプリケーション配備・更新や、アプリケーションサーバの設定変更などを指示することができる。

さらに、実施の形態２におけるアプリケーションサーバ１１においては、次のような障害検出に対する設定項目がある。

１．「デッドロック」検出時のリカバリアクション（リカバリ処理）
この項目では、アプリケーションの呼び出し期間でデッドロックが検出された場合のアプリケーションサーバ１１に対するリカバリ操作が指定されている。実施の形態２では、少なくとも「アプリケーションサーバの再起動」、「旧バージョンへのアプリケーションのダウングレード」がリカバリ操作の選択肢にある。

２．「過剰なメモリ消費」と判定するためのメモリ使用率の閾値
この項目では、過剰にメモリが消費されたと判断するためのアプリケーションサーバ１１に対するメモリ使用率が設定されている。実際のアプリケーションサーバ１１のメモリ使用率がこの項目における設定値以上のメモリ使用率に達した場合、アプリケーションサーバ１１は、過剰なメモリ消費が発生したものと判断する。

３．「過剰なメモリ消費」検出時の原因と判断するための発生回数の閾値
この項目では、過剰にメモリが消費された原因と判断するための該当コンポーネント及びインタフェース名のエントリ回数（障害発生回数）が指定されている。指定された回数以上エントリがされた場合、アプリケーションサーバ１１は、そのエントリを過剰なメモリ消費の原因と判断する。

４．「過剰なメモリ消費」検出時のリカバリアクション
この項目は、過剰なメモリ消費が検出された際のアプリケーションサーバに対するリカバリ操作を選択するための項目である。ここでは、少なくとも「強制ＧＣ（Garbage Collection）の実行」、「旧バージョンへのアプリケーションのダウングレード」がリカバリ操作の選択肢にある。

５．「過剰なＣＰＵ消費」と判定するためのＣＰＵ使用率の閾値
この項目は、過剰にＣＰＵが消費されたと判断するためのアプリケーションサーバ１１に対するＣＰＵ使用率が設定された項目である。実際のアプリケーションサーバ１１のＣＰＵ使用率が設定値以上のＣＰＵ使用率に達した場合、アプリケーションサーバ１１は、過剰なＣＰＵ消費が発生したと判断する。

６．「過剰なＣＰＵ消費」検出時の原因と判断するための発生回数の閾値
この項目では、過剰にＣＰＵが消費された原因と判断するための該当アプリケーションコンポーネント及びインタフェース名のエントリ回数が指定されている。指定された回数以上エントリがされた場合、アプリケーションサーバ１１は、それを過剰なＣＰＵ消費の原因と判断する。

７．「過剰なＣＰＵ消費」検出時のリカバリアクション
過剰なＣＰＵ消費が検出された際のアプリケーションサーバに対するリカバリ操作を選択する。ここでは、少なくとも「処理優先度の変更」、「旧バージョンへのアプリケーションのダウングレード」がリカバリ操作の選択肢にある。

以上の設定項目は、予めシステム運用者またはアプリケーションサーバ１１の規定により適切な値（基準）が設定されている。そして、上述したアプリケーションに対する障害をアプリケーションサーバ１１は次の方法によって検知する。例えば、アプリケーションサーバ１１自身が、ＯＳ（Operating System）又はプログラムの実行環境が提供するＡＰＩ（Application Programming Interface）を用いて、各種リソースの消費状況や障害の発生状況を一定間隔で監視する。あるいは、そのような障害の発生を内部イベントとして発行する実行環境において、アプリケーションサーバ１１のアプリケーション実行制御部１９が同イベントを受信することにより障害検知を実現する。

図４Ａ、図４Ｂは、アプリケーションサーバ１１における処理の一例を示したフローチャートである。以上の説明を前提事項として、図４Ａ、図４Ｂを用いて、アプリケーションサーバ１１内で障害が発生した場合にアプリケーションサーバ１１が実行する処理について説明する。

上述のような方法により、アプリケーションサーバ１１内での障害が検知されると、アプリケーションサーバ１１の障害監視部２１は、プロセスのスレッド情報の一覧や、メモリ使用量、ＣＰＵ使用率などの各種リソース情報を採取する（ステップＳ１１）。

アプリケーション実行制御部１９は、障害監視部２１が採取した各種リソース情報を障害解析部２２によって解析することにより、発生した障害の種類（障害の原因）を特定する（ステップＳ１２）。

アプリケーション実行制御部１９は、障害解析部２２が特定した障害の種類がデッドロックか、又は処理中のリクエスト処理数が１であるか否かを判定する（ステップＳ１３）。アプリケーション実行制御部１９は、実行管理部２０に格納された、現に実行されているリクエストの情報を参照することにより、処理中のリクエスト処理数が１であるか否かを判定する。

障害解析部２２が特定した障害の種類がデッドロックの場合、又は処理中のリクエスト処理数が１の場合には（ステップＳ１３のＹｅｓ）、アプリケーション実行制御部１９は、業務ロジックが呼び出された対象コンポーネントの識別名（コンポーネント名）及びそのインタフェース名をスレッドのスタック情報から抽出する。そしてアプリケーション実行制御部１９は抽出した情報を基に、次の情報を含めた障害イベントを、障害イベント発行部１８を介して分散管理サーバに対して発行する（ステップＳ１４）。
・コンポーネント名（識別名）
・インタフェース名（メソッド名）
・障害の種類（デッドロック、過剰なＣＰＵ消費、過剰なメモリ消費、など）
・関連コンポーネント名（識別名）
・関連インタフェース名（メソッド名）
・リカバリアクション
なお、関連コンポーネント名及び関連インタフェース名は、業務ロジックが呼び出された対象コンポーネントのコンポーネント及びそのインタフェースに関連して障害を発生させると考えられるコンポーネント及びインタフェースを記載したものである。処理中のリクエスト処理数が１の場合には、業務ロジックが呼び出された対象コンポーネントのコンポーネント及びそのインタフェースのみがコンポーネント名及びインタフェース名に記載され、関連コンポーネント名及び関連インタフェース名には何も記載されない。

障害解析部２２が特定した障害の種類がデッドロックではなく、かつ処理中のリクエスト処理数が複数の場合には（ステップＳ１３のＮｏ）、障害解析部２２は、採取したスレッドのスタック情報を順に解析する。解析においては、障害解析部２２は、スレッドのスタック情報から、コンポーネントの識別名（コンポーネント名）及びそのインタフェース名を抽出する（ステップＳ１５）。障害分析部２３は、障害解析部２２が以上の解析で抽出した情報を基に、障害を分析する（ステップＳ１６）。ここで、障害解析部２２における情報抽出処理（ステップＳ１５）と、障害分析部２３における障害分析処理（ステップＳ１６）は、処理中のリクエスト数分だけループして実行される。

図４Ｂを用いて、障害分析部２３における障害分析処理（ステップＳ１６）の詳細について説明する。障害の分析において、障害分析部２３は、障害候補格納部２４に、障害解析部２２が抽出したコンポーネント名及びインタフェース名の対のデータが、候補データとしてエントリされているか否かをチェックする（ステップＳ１７）。

障害候補格納部２４に当該データが候補データとしてエントリ済みの場合は（ステップＳ１７のＹｅｓ）、障害分析部２３は、そのデータを障害候補格納部から取得する（ステップＳ１８）。

障害候補格納部２４に当該データが候補データとしてエントリされていない場合は（ステップＳ１７のＮｏ）、障害分析部２３は新たな障害要因の候補として、コンポーネントの識別名及びインタフェース名をキーとしてエントリを作成する（ステップＳ１９）。このとき、障害分析部２３は検知した障害の種類に合わせて、上述した障害検出のための設定項目により指定された閾値やリカバリアクションなどのパラメータをエントリに格納する。

障害分析部２３は、ステップＳ１８及びステップＳ１９のいずれの場合においても、障害解析部２２が抽出したコンポーネント名及びインタフェース名における障害発生の発生回数を１加算する（ステップＳ２０）。

図５は、障害候補格納部２４に格納されるデータのイメージ図である。障害候補格納部２４においては、コンポーネント名及びインタフェース名に対応して、障害の種類、発生回数、閾値及びリカバリアクションが格納されている。ここで発生回数とは、当該コンポーネントのインタフェースの呼び出しのときに、障害監視部２１が何らかの障害を検知することによって、障害の要因候補としてエントリされた回数を示す。

図５における閾値とは、上述したように、該当の障害が発生していると判断するための条件である。例えば、アプリケーションの障害の種類がメモリの過剰な消費やＣＰＵ負荷などである場合には、障害分析部２３は、並行して複数動作するアプリケーションスレッドのどのスレッドが直接的な原因であるかを導くことが難しい。この場合には、障害発生となっている原因箇所を判断するために、統計的な値と条件を用いる必要がある。閾値は、原因箇所の判断材料として用いられる。

障害分析部２３は、障害候補格納部２４に格納されたデータを参照して、コンポーネント名及びインタフェース名の各々において、障害発生の発生回数と、対応する閾値とを比較する。そして、障害発生の発生回数が閾値以上であるか否かを判定する（ステップＳ２１）。

障害発生の判断条件となる発生回数が、閾値に達した（又は閾値を超えた）場合には（ステップＳ２１のＹｅｓ）、障害分析部２３は、該当コンポーネントのインタフェースの呼び出しが障害の原因と判断（特定）する。そして障害分析部２３は、その情報を用いて分散管理サーバに障害イベントを発行するための処理を開始する。イベントの内容については、上述した通りである。発行される障害イベントにおけるコンポーネント名及びインタフェース名には、障害分析部２３が障害原因と判断したコンポーネント（第１コンポーネント）及びインタフェース（第１インタフェース）の名前が記載される。

このとき、障害分析部２３は、障害原因として判断された（閾値を超えた）エントリ以外で、そのときに閾値を超えていないが最も発生回数が多かったエントリ（２番目に障害発生回数が多かったエントリ）にかかるコンポーネント（第２コンポーネント）及びインタフェース（第２インタフェース）を併せて障害候補として抽出する（ステップＳ２２）。この障害候補は、スレッド処理を制御する対象となるものである。

ここで、障害の原因として判断されたエントリ以外で、最も発生回数が多かったエントリを障害候補として抽出する理由は、障害の要因となるアプリケーションのコンポーネント間の関係性を導き出すためである。例えば、ＣＰＵの過剰消費が発生する場合、特定のコンポーネントのインタフェースの呼び出しが原因ではなく、複数のコンポーネントのインタフェースの呼び出しが重なることが原因になることがある。呼び出しにより実行される処理が複雑で、ＣＰＵを大量に消費するロジックであっても、単体の呼び出しであれば（一時的に負荷は高くなっても）業務システムが正常に稼働する許容範囲に収まるようなインタフェースが単独で呼び出された場合には、ＣＰＵの過剰消費は発生しない。しかし、そのようなインタフェースの呼び出しが複数重なる場合においては、ＣＰＵの過剰消費が発生してしまう。

ただし、インタフェースの呼び出しが複数重なる場合であっても、アプリケーションの構成やアプリケーションサーバのマシンスペック等によって障害に至るかどうかは異なる。そこで、このような関係性を業務システムの稼働中に導き出すことにより、より精度の高い障害候補の検出とその発生防止が可能になる。これは、ＣＰＵの過剰消費だけでなく、後述するメモリの過剰消費の場合においても同様である。

なお、単体での障害の発生回数が閾値を超えているコンポーネントが複数ある場合も考えられる。このように、特定のコンポーネントにおいて障害発生回数が閾値を超えたことを判定したときに、既に閾値越えが発生しているコンポーネントのインタフェースがある場合は、障害分析部２３は、ステップＳ２２においてそのコンポーネント（第２コンポーネント）及びインタフェース（第２インタフェース）も併せて障害候補として抽出する。このように、障害分析部２３が抽出する障害候補は１つに限らず、複数であってもよい。

さらに、特定のコンポーネント及びインタフェースにおいて、ＣＰＵの過剰消費についての障害発生回数が閾値を超えた場合に、別のコンポーネント及びインタフェースにおいてメモリの過剰消費についての障害発生回数が閾値を超えてしまうことが考えられる。このような場合には、メモリの過剰消費が発生した別のコンポーネント（第２コンポーネント）及びインタフェース（第２インタフェース）をステップＳ２２において障害候補として抽出する。なお、メモリの過剰消費についての障害発生回数が閾値を超えた場合に、別のコンポーネント及びインタフェースにおいてＣＰＵの過剰消費についての障害発生回数が閾値を超えてしまう場合が考えられる。その場合においても、ＣＰＵの過剰消費が発生した別のコンポーネント（第２コンポーネント）及びインタフェース（第２インタフェース）をステップＳ２２において障害候補として抽出する。

なお、ステップＳ２２において、障害候補として抽出するコンポーネント（第２コンポーネント）は、障害分析部２３が障害原因と判断したコンポーネント（第１コンポーネント）と同じものであってもよい。ただし、障害分析部２３が障害原因と判断したインタフェース（第１インタフェース）と、障害候補として抽出するインタフェース（第２インタフェース）とは異なるインタフェースである。

以上、ステップＳ２２において抽出した障害候補を障害イベントにおける関連コンポーネント名、および関連インタフェース名の情報（関連情報）として含め、障害イベント発行部１８は障害イベントを発行する（ステップＳ２３）。障害イベントの発行後、障害分析部２３は、障害候補格納部２４から当該エントリのデータを削除する（ステップＳ２４）。

もし、発生回数が閾値を下回った場合には（ステップＳ２１のＮｏ）、当該エントリが障害の原因と判断するにはデータが不十分とみなして、障害分析部２３は、障害イベントを発行するための処理を開始しない。障害分析部２３は、障害候補格納部２４のエントリデータを最新の情報に更新する（ステップＳ２５）。更新された情報は、障害情報記憶部１６を介して、記憶装置１７に保存される。

以上の処理により、障害候補格納部２４に蓄えられたエントリ情報は、対象のコンポーネント２６が更新又は削除されるまで、各アプリケーションサーバ１１によって継続して保持される。そのため、アプリケーションサーバ１１の起動時には、記憶装置１７に非一時的に格納された障害候補のデータが読み込まれ、再び障害候補格納部２４に格納される。

図６は、分散管理サーバ２７における処理の一例を示したフローチャートである。図６を用いて、これまでの処理によりアプリケーションサーバ１１から分散管理サーバ２７に対して障害イベントが発行されたときに、分散管理サーバ２７が実行する処理について説明する。

まず分散管理サーバ２７は、障害イベント受信部３０によってアプリケーションサーバ１１から障害イベントを受信後、それをイベント解析部３１によって解析する（ステップＳ３１）。イベント解析部３１は、受信した障害イベントにおいて、障害に対するリカバリアクションが含まれているか否か（定義されているか否か）を判定する（ステップＳ３２）。

障害イベントにおいて障害に対するリカバリアクションが含まれている場合には（ステップＳ３２のＹｅｓ）、運用操作発行部３２は、障害イベントに含まれているリカバリアクションの内容に基づき、障害が発生したアプリケーションサーバ１１Ａに対してリカバリアクションの要求を発行する（ステップＳ３３）。アプリケーションサーバ１１Ａは発行されたそのリカバリアクションの要求に基づき、リカバリアクションを実行する。これにより、アプリケーションサーバ１１Ａは障害からリカバリすることができる。

分散管理サーバ２７は、障害に対するリカバリアクションが、旧バージョンへのアプリケーションのダウングレードであるか否かを判定する（ステップＳ３４）。

もし、リカバリアクションが旧バージョンへのアプリケーションのダウングレードの場合には（ステップＳ３４のＹｅｓ）、分散管理サーバ２７は、続けてアプリケーション情報管理部２９に格納された配備済みのアプリケーションのバージョン情報を更新する（ステップＳ３５）。これにより、分散管理サーバ２７は、自身のアプリケーションのバージョン情報を、アプリケーションサーバ１１のアプリケーションのバージョン情報と一致させる。

リカバリアクションがダウングレードではない場合には（ステップＳ３４のＮｏ）、分散管理サーバ２７は、イベント解析部３１によって抽出されたアプリケーションのコンポーネント識別名とインタフェース名を基に、それを新たな障害情報として障害情報発行部３３により、全ての管理対象となるアプリケーションサーバ１１に送信する（ステップＳ３６）。送信する情報は以下の通りである。
・コンポーネント名（識別名）
・インタフェース名（メソッド名）
・障害の種類（デッドロック、過剰なメモリ消費、過剰なＣＰＵ消費、など）
・関連コンポーネント名（識別名）
・関連インタフェース名（メソッド名）

なお、障害情報の発行処理（ステップＳ３６）は、管理対象となるアプリケーションサーバ１１の台数分だけループしてなされる。

各アプリケーションサーバ１１の障害情報受信部１５は、障害情報発行部３３が発行した障害情報を受信する。アプリケーションサーバ１１は、受信した障害情報を、障害情報記憶部１６に格納後、記憶装置１７に保存させる。それと共に、アプリケーションサーバ１１は、システム利用者から送信されてくるリクエストの監視を速やかに開始する。

図７は、障害情報記憶部１６に格納されるデータのイメージ図である。図７においては、コンポーネント名及びインタフェース名に対応して、障害の種類、関連するコンポーネント名及びインタフェース名（関連情報）が格納されている。

図８は、受信した障害情報に基づいてアプリケーションサーバ１１が実行する監視処理の一例を示したフローチャートである。以下、図８を用いて、アプリケーションサーバ１１が実行する監視処理について説明する。

監視の開始後、アプリケーションサーバ１１内のアプリケーション実行制御部１９は、リクエスト受付部１２を介して、システム利用者からの要求に対するリクエスト（要求リクエスト）を受け付ける（ステップＳ４１）。

アプリケーション実行制御部１９は、障害情報検索部２５によって、システム利用者からリクエストされたコンポーネントのインタフェースに関する障害情報がコンポーネント名及びインタフェース名として障害情報記憶部１６に格納されているか否かをチェックする（ステップＳ４２）。

障害情報が格納済みの場合は（ステップＳ４２のＹｅｓ）、さらにアプリケーション実行制御部１９は障害情報から、リクエストされたコンポーネントのインタフェースに関連するアプリケーションのインタフェースの情報を参照する（ステップＳ４３）。そして、アプリケーション実行制御部１９は、障害情報において、関連するアプリケーション（関連アプリケーション）のインタフェースの情報が存在するか否かを判定する（ステップＳ４４）。ここで関連アプリケーションとは、障害情報における「関連コンポーネント」が含まれるアプリケーションを意味する。

関連アプリケーションのインタフェースの情報（すなわち、障害情報における「関連インタフェース」の情報）が存在する場合には（ステップＳ４４のＹｅｓ）、アプリケーション実行制御部１９は、それに該当するリクエスト（関連リクエスト）が、要求リクエストを処理するスレッド以外の他のスレッドにより実行中であるか否かを、実行管理部２０が保持する情報によって判定する（ステップＳ４５）。

関連リクエストが他のスレッドにより実行中であることを確認できた場合には（ステップＳ４５のＹｅｓ）、アプリケーション実行制御部１９は、そのスレッドの実行が完了するまで後続のリクエスト（要求リクエスト）の実行を待機する（ステップＳ４７）。そして、アプリケーション実行制御部１９は、所定の時間が経過後、関連リクエストが他のスレッドにより実行中であるか否かを再度判定する（ステップＳ４５）。

関連リクエストが他のスレッドにより実行中でない場合には（ステップＳ４５のＮｏ）、アプリケーション実行制御部１９は、後続のリクエストに対するスレッドの処理を実行する（ステップＳ４９）。すなわち、アプリケーション実行制御部１９はリクエストを実行する。それ以前のステップＳ４７においてアプリケーション実行制御部１９が後続のリクエストの実行を待機する処理を実行した場合には、アプリケーション実行制御部１９は、待機状態のリクエストに対するスレッドの処理を再開したことになる。

ステップＳ４４において、関連コンポーネントのインタフェースの情報が存在しない場合には（ステップＳ４４のＮｏ）、アプリケーション実行制御部１９は以下の処理を実行する。アプリケーション実行制御部１９は、障害対象のコンポーネントのインタフェースに対するリクエスト（同一リクエスト）が要求リクエストを処理するスレッド以外の別のスレッドにより実行中か否かを、実行管理部２０が保持する情報により判定する（ステップＳ４６）。

同一リクエストが別スレッドにて実行中の場合には（ステップＳ４６のＹｅｓ）、アプリケーション実行制御部１９は、当該スレッドの実行が完了するまで後続のリクエストの実行を待機する（ステップＳ４８）。そして、アプリケーション実行制御部１９は、所定の時間が経過後、同一リクエストが別スレッドにより実行中であるか否かを再度判定する（ステップＳ４６）。

同一リクエストが別スレッドにより実行中でない場合には（ステップＳ４６のＮｏ）、アプリケーション実行制御部１９は、同一リクエストに対するスレッドの処理を実行する（ステップＳ４９）。すなわち、アプリケーション実行制御部１９はリクエストを実行する。ステップＳ４８においてアプリケーション実行制御部１９が後続のリクエストの実行を待機する処理を実行した場合には、アプリケーション実行制御部１９は、待機状態のリクエストに対するスレッドの処理を再開したことになる。

なお、ステップＳ４７、Ｓ４８における待機処理では、アプリケーション実行制御部１９は、システム運用者又はアプリケーションサーバ１１により指定されたパラメータを基に、一定期間を経過後、処理がタイムアウトされたと見なして呼び出し元に適切なエラーを返すことにより図８の処理を終了してもよい。

アプリケーションサーバ１１Ａにおいて発生した障害がデッドロックである場合には、アプリケーションサーバ１１Ｂは、ステップＳ４６及びＳ４８の処理を実行しなくてもよい。デッドロックの障害は、リクエストにかかるコンポーネントのインタフェースと、それとは別のコンポーネントのインタフェースとの間で同時に排他制御が実行されることにより発生する。そのため、リクエストにかかるコンポーネントのインタフェースが既に実行されても、デッドロックの障害が起きないと考えられるからである。

上述の監視処理は、対象のアプリケーションが更新されるまで、各アプリケーションサーバ１１によって継続して実施される。従って、それまでの間にアプリケーションサーバ１１の再起動が行われると、障害情報記憶部１６にあるメモリ上の障害情報は失われてしまう。そのため、アプリケーションサーバ１１の起動時には、記憶装置１７から非一時的に格納された障害情報が読み込まれる。その際に読み込まれた障害情報は、アプリケーション実行制御部１９によって再び障害情報記憶部１６に格納される。

以下、上述の図４、図６及び図８の処理について、具体的な状況を想定してさらに説明する。

＜デッドロックが発生した場合＞
ここでは、特定のアプリケーションサーバ１１Ａにおいて、業務システム稼働中に、アプリケーションの欠陥を起因として、複数のリクエストを並行して処理中のスレッド間でデッドロックが発生した場合を考える。ここで、アプリケーションサーバ１１において、デッドロックの対象となったアプリケーションのコンポーネントをそれぞれＡ、Ｂ、呼び出しインタフェースをそれぞれＡｍ、Ｂｍとする。またデッドロック発生時には、リカバリアクションとして当該アプリケーションサーバの再起動が予め定義されている。

アプリケーションサーバ１１Ａ内でデッドロックが発生すると、アプリケーションサーバ１１Ａにおける障害監視部２１は、デッドロックの発生元となったリクエストのスレッドに対するスタック情報（スレッドの呼び出しの流れが記載された情報）を取得する。取得した情報から、アプリケーションサーバ１１は、障害解析部２２によりデッドロックの対象（障害原因）となったアプリケーションのコンポーネント名（Ａ）とインタフェース名（Ａｍ）、それに対応する関連コンポーネント名（Ｂ）と関連インタフェース名（Ｂｍ）について障害の種類を「デッドロック」とした情報と、デッドロックの対象となったアプリケーションのコンポーネント名（Ｂ）とインタフェース名（Ｂｍ）、それに対応する関連コンポーネント名（Ａ）と関連インタフェース名（Ａｍ）について障害の種類を「デッドロック」とした情報とを含む障害イベントを分散管理サーバ２７に発行する。ここで特定されるリカバリアクションは、「サーバ再起動」である。

障害イベントを受け取った分散管理サーバ２７は、障害イベントの内容から、イベント解析部の解析によりコンポーネントＡ、ＢにおけるインタフェースＡｍ、Ｂｍ間でのデッドロックの発生、及びサーバ再起動をリカバリアクションとする障害情報を抽出する。分散管理サーバ２７は、障害が発生したアプリケーションサーバ１１Ａを再起動させた後、管理下の全てのアプリケーションサーバ１１に障害情報を送信する。この障害情報には、コンポーネント名としてコンポーネントＡ、Ｂ、インタフェース名としてインタフェースＡｍ、Ｂｍが含まれている。

障害情報を受け取ったアプリケーションサーバ１１Ｂは、それを障害情報記憶部１６に格納すると共に、速やかにリクエストの監視を開始する。その後、アプリケーションサーバ１１Ｂは、リクエスト受付部１２によって、クライアントアプリケーション３４から出力された、アプリケーションのコンポーネントＡのインタフェースＡｍの呼び出しのためのリクエストを処理する。

リクエスト受付部１２は、リクエストをアプリケーション実行制御部１９に転送する。このとき、アプリケーション実行制御部１９の障害情報検索部２５は、コンポーネントＡのインタフェース情報Ａｍが障害情報記憶部１６に存在することを確認する。確認後、アプリケーション実行制御部１９は、実行管理部２０において既に関連コンポーネントＢの関連インタフェースＢｍの呼び出しが、別のスレッドにより実行中として管理されているかどうかを問い合わせる。

もし、インタフェースＢｍの呼び出しが別のスレッドにより実行中の場合は、アプリケーション実行制御部１９は、そのスレッドによる処理が完了するまで、コンポーネントＡのインタフェースＡｍを呼び出すための処理を待機する。そして、コンポーネントＢのインタフェースＢｍの呼び出し処理が完了した後、アプリケーション実行制御部１９は、コンポーネントＡのインタフェースＡｍの呼び出しに対する待機を解除し、処理を再開する。

図９Ａは、以上に示したデッドロック障害発生防止のためのリクエスト処理制御のイメージ図である。アプリケーションサーバ１１Ｂにおいて、コンポーネントＡのインタフェースＡｍに対するリクエストが、コンポーネントＢのインタフェースＢｍに対するリクエストの処理スレッドを実行中に、アプリケーション実行制御部１９に対してなされる。

ここで、コンポーネントＡのインタフェースＡｍに対するリクエストの処理スレッドを実行した場合、コンポーネントＣのインタフェースＣｍ１に対するリクエストがなされる。コンポーネントＢのインタフェースＢｍに対するリクエストの処理スレッドを実行した場合、コンポーネントＣのインタフェースＣｍ２に対するリクエストがなされる。このとき、両方のインタフェース（メソッド）から相互に２つの排他制御がなされると、処理の実行タイミングによっては、インタフェースＣｍ１とインタフェースＣｍ２との間でデッドロックが発生してしまう。

上述の処理では、コンポーネントＢのインタフェースＢｍに対するリクエストが終了するまで、コンポーネントＡのインタフェースＡｍに対するリクエストの実行を待機する。これにより、両方のインタフェースから相互に２つの排他制御がなされず、インタフェースＣｍ２の実行後にインタフェースＣｍ１が実行される。換言すれば、インタフェースＣｍ１とインタフェースＣｍ２とは別々のタイミングで実行される。このため、デッドロックの発生を回避することができる。

図９Ｂは、デッドロック障害が発生しうる場合（従来技術の場合）のリクエスト処理制御のイメージ図である。図９Ｂでは、コンポーネントＡのインタフェースＡｍに対するリクエストの実行が待機されないため、相互に２つの排他制御が伴い、インタフェースＣｍ１とインタフェースＣｍ２との間でデッドロックが発生してしまった場合が示されている。

なお、アプリケーションサーバ１１Ｂだけではなく、障害情報を受け取ったアプリケーションサーバ１１Ｃも、同様の処理を実行する。

上述の状況では、異なるコンポーネントＡ、Ｂのインタフェース間でデッドロックが起こることを説明したが、同一のコンポーネントにおける異なるインタフェース間でデッドロックが発生することも考えられる。例えば、コンポーネントＡのインタフェースＡｍ１に対するリクエストの処理スレッドを実行した場合に、共通コンポーネントＣのインタフェースＣｍ１に対するリクエストがなされ、コンポーネントＡのインタフェースＡｍ２に対するリクエストの処理スレッドを実行した場合に、共通コンポーネントＣのインタフェースＣｍ２に対するリクエストがなされることが考えられる。このとき、両方のインタフェースＡｍ１、Ａｍ２から相互に２つの排他制御がなされる。ここで、処理のタイミングによっては、それらの排他制御が交差する（同時に発生する）ような処理の流れになり、図９Ｂと同様の原理によりデッドロックが発生する。このように、同一のコンポーネントＡの異なるインタフェースＡｍ１、Ａｍ２を各スレッドにおいて処理する過程で、互いに共通コンポーネントＣに対する異なる排他制御が存在することが考えられる。

以上のデッドロックがアプリケーションサーバ１１Ａ内で発生した場合、障害監視部２１の取得した情報から、アプリケーションサーバ１１は、障害解析部２２によりデッドロックの対象（障害原因）となったアプリケーションのコンポーネント名（Ａ）とインタフェース名（Ａｍ１）、それに対応する関連コンポーネント名（Ａ）と関連インタフェース名（Ａｍ２）について障害の種類を「デッドロック」とした情報と、デッドロックの対象となったアプリケーションのコンポーネント名（Ａ）とインタフェース名（Ａｍ２）、それに対応する関連コンポーネント名（Ａ）と関連インタフェース名（Ａｍ１）について障害の種類を「デッドロック」とした情報とを含む障害イベントを分散管理サーバ２７に発行する。

発行された障害イベントに基づき、分散管理サーバ２７が障害情報をアプリケーションサーバ１１Ｂに送信する。アプリケーションサーバ１１Ｂは、図９Ａで説明したものと同様なデッドロック障害発生防止のためのリクエスト処理制御を実行する。例えば、インタフェースＡｍ１の呼び出しのためのリクエストがクライアントアプリケーション３４からあり、既にインタフェースＡｍ２の呼び出しが別のスレッドにおいて実行されている場合に、アプリケーション実行制御部１９はそのスレッドによる処理が完了するまでインタフェースＡｍ１を呼び出すための処理を待機する。そして、インタフェースＡｍ２の呼び出し処理が完了した後、アプリケーション実行制御部１９は、インタフェースＡｍ１の呼び出しに対する待機を解除し、処理を再開する。

＜メモリの過剰消費が発生した場合＞
以下、もう一つの具体例を用いて、上述の図４、図６及び図８の処理についてさらに説明する。ここでは、特定のアプリケーションサーバ１１Ａにおいて、システム稼働中に、アプリケーションの欠陥を起因としてメモリの過剰な消費が発生した場合を考える。なお、アプリケーションサーバ１１において、メモリを過剰に消費するアプリケーションのコンポーネントをＡ、そのインタフェースをＡｍとし、それ以外の（問題を含まない）コンポーネントをＢ〜Ｅ、それらのインタフェースをそれぞれＢｍ〜Ｅｍとする。さらに、障害情報記憶部１６内のデータにおいて、それらが障害発生の原因と判断するための発生回数の閾値が「３」であり、設定されたリカバリアクションが「強制ＧＣ」であると設定される。

いま、時刻ｔ１においてアプリケーションサーバ１１Ａ内でメモリの過剰な消費が発生すると、障害監視部２１は、リクエストを処理中のスレッドに対するスタック情報を取得する。アプリケーション実行制御部１９は、取得した情報から、障害解析部２２によって障害にかかるアプリケーションのコンポーネント名とインタフェース名を特定する。ここでは、次の情報が解析により得られたものとする。
[コンポーネント名：インタフェース名] Ａ：Ａｍ、Ｃ：Ｃｍ、Ｅ：Ｅｍ

このとき、障害分析部２３は、障害情報記憶部１６にそれぞれのエントリ情報を新たに格納する。また、それぞれのエントリの発生回数を１とする。

図１０Ａは、時刻ｔ１における障害情報記憶部１６内のデータが示された表である。障害情報記憶部１６内のデータには、上述の通り、Ａ：Ａｍ、Ｃ：Ｃｍ、Ｅ：Ｅｍにおいて、「過剰なＣＰＵ消費」の障害がそれぞれ１回発生したことが記憶されている。さらに、発生回数の閾値が「３」であり、リカバリアクションが「強制ＧＣ」であることも記憶されている。ここで、Ａ：Ａｍ、Ｃ：Ｃｍ、Ｅ：Ｅｍのエントリの発生回数は、いずれも閾値は超えていない。そのため、障害イベント発行部１８は、障害発生イベントを発行しない。

その後、時刻ｔ２において、アプリケーションサーバ１１Ａ内で再びメモリの過剰な消費が発生する。ここでは、障害解析部２２によって次の情報が解析により得られたものとする。
[コンポーネント名：インタフェース名] Ａ：Ａｍ、Ｂ：Ｂｍ、Ｃ：Ｃｍ（以下、コンポーネント及びそれに対応するインタフェースを同様に表示する。）

このとき、障害分析部２３は、上述と同様の処理を経て、障害情報記憶部１６に格納されたデータに、エントリを追加・更新する。

図１０Ｂは、時刻ｔ２における障害情報記憶部１６内のデータが示された表である。障害情報記憶部１６内のデータには、「過剰なメモリ消費」の障害がＡ：Ａｍにおいて２回、Ｂ：Ｂｍにおいて１回、Ｃ：Ｃｍにおいて２回、Ｅ：Ｅｍにおいて１回発生したことが記憶されている。ここで、Ａ：Ａｍ、Ｃ：Ｃｍの障害発生回数は２となるが、まだ閾値に達していないため、障害イベント発行部１８は障害イベントを発行しない。

その後、時刻ｔ３において、アプリケーションサーバ１１Ａ内で再びメモリの過剰な消費が発生する。ここでは、障害解析部２２によって次の情報が解析により得られたものとする。
[コンポーネント名：インタフェース名] Ａ：Ａｍ、Ｄ：Ｄｍ、Ｅ：Ｅｍ

このとき、障害分析部２３は、上述と同様の処理を経て、障害情報記憶部１６に格納されたデータに、エントリを追加・更新する。

図１０Ｃは、時刻ｔ３における障害情報記憶部１６内のデータが示された表である。障害情報記憶部１６内のデータには、「過剰なメモリ消費」の障害がＡ：Ａｍにおいて３回、Ｂ：Ｂｍにおいて１回、Ｃ：Ｃｍにおいて２回、Ｄ：Ｄｍにおいて１回、Ｅ：Ｅｍにおいて２回発生したことが記憶されている。

ここで、Ａ：Ａｍにおいての障害発生回数は３となり、閾値に達している。そのため、障害分析部２３は、Ａ：Ａｍをメモリの過剰な消費に伴う障害の原因と判断する。そして障害分析部２３は、Ａ：Ａｍの次に発生回数が高かった、Ｃ：Ｃｍ、Ｅ：Ｅｍを、それぞれ障害の原因となるＡ：Ａｍについての関連コンポーネント、関連インタフェース（関連情報）とみなす。そして、障害イベント発行部１８は、障害の原因であるコンポーネント名及びインタフェース名（Ａ：Ａｍ）、関連コンポーネント名及び関連インタフェース名（Ｃ：Ｃｍ及びＥ：Ｅｍ）が示された障害イベントを分散管理サーバ２７に発行する。

その後なされる処理、つまり分散管理サーバ２７におけるリカバリアクションの実行及びアプリケーションサーバ１１への障害情報の発行、ならびに各アプリケーションサーバ１１における障害情報受信後の処理及びリクエスト処理スレッドの実行制御については、上述と同様である。

図１１Ａは、以上に示した過剰なメモリ消費の障害発生防止のためのリクエスト処理制御のイメージ図である。図１１Ａにおいては、アプリケーションサーバ１１Ｂにおいて、コンポーネントＡのインタフェースＡｍに対する複数のリクエストがアプリケーション制御部に対してなされる。

ここで、コンポーネントＡのインタフェースＡｍが過剰にメモリを消費するインタフェースである場合、複数のリクエストによりインタフェースＡｍが呼び出されると、メモリ不足が発生してしまう。

アプリケーションサーバ１１Ｂは、先になされたコンポーネントＡのインタフェースＡｍに対するリクエストが終了するまで、後になされたコンポーネントＡのインタフェースＡｍに対するリクエストの実行を待機する。これにより、アプリケーションサーバ１１Ｂにおいては、複数のリクエストによる呼び出しが行われなくなるため、メモリ不足の発生を回避することができる。つまり、アプリケーションサーバ１１Ｂは、コンポーネントＡが持つインタフェースＡｍの実行を複数のスレッド間で同時に実行しないよう制御する。

なお、障害情報として、コンポーネントＡが持つインタフェースＡｍの次に（２番目に）発生回数が多かった障害候補としてコンポーネントＣのインタフェースＣｍがあり、それが別スレッドで実行中である場合が考えられる。この場合、アプリケーションサーバ１１Ｂは、その処理が完了するまでコンポーネントＡのインタフェースＡｍの実行を待機する。このように制御することで、複数のコンポーネントのインタフェースの呼び出しが原因となる障害の発生を未然に防ぐことが期待できる。障害候補として、既に閾値越えが発生しているコンポーネントのインタフェースが記録されている場合や、ＣＰＵの過剰消費についての障害発生回数が閾値を超えたコンポーネントのインタフェースが記録されている場合でも、同様の制御が実行できる。

なお、コンポーネントＡが持つインタフェースＡｍの次に発生回数が多かった障害候補として、同じコンポーネントＡの異なるインタフェースＡｍ２が記載されていてもよい。この場合、インタフェースＡｍ２が別スレッドで実行中であれば、アプリケーションサーバ１１Ｂは、その処理が完了するまでインタフェースＡｍの実行を待機する。

図１１Ｂは、過剰なメモリ消費の障害が発生しうる場合（従来技術の場合）のリクエスト処理制御のイメージ図である。図１１Ｂでは、コンポーネントＡのインタフェースＡｍに対するリクエストが複数なされることによりインタフェースが呼び出されてしまうため、メモリ不足の障害が発生してしまう。

＜ＣＰＵの過剰消費が発生した場合＞
以下、さらに一つの具体例を用いて、上述の図４、図６及び図８の処理についてさらに説明する。ここでは、特定のアプリケーションサーバ１１Ａにおいて、システム稼働中に、アプリケーションの欠陥を起因としてＣＰＵの過剰な消費が発生した場合を考える。なお、アプリケーションサーバ１１において、ＣＰＵを過剰に消費するアプリケーションのコンポーネントをＡ、そのインタフェースをＡｍとし、それ以外の（問題を含まない）コンポーネントをＢ〜Ｅ、それらのインタフェースをそれぞれＢｍ〜Ｅｍとする。さらに、障害情報記憶部１６内のデータにおいて、それらが障害発生の原因と判断するための発生回数の閾値が「３」であり、設定されたリカバリアクションが「強制ＧＣ」であると設定される。

いま、時刻ｔ４においてアプリケーションサーバ１１Ａ内でＣＰＵの過剰な消費が発生すると、障害監視部２１は、リクエストを処理中のスレッドに対するスタック情報を取得する。アプリケーション実行制御部１９は、取得した情報から、障害解析部２２によって障害にかかるアプリケーションのコンポーネント名とインタフェース名を特定する。ここでは、次の情報が解析により得られたものとする。
[コンポーネント名：インタフェース名] Ａ：Ａｍ、Ｃ：Ｃｍ、Ｅ：Ｅｍ

このとき、障害分析部２３は、障害情報記憶部１６にそれぞれのエントリ情報を新たに格納する。また、それぞれのエントリの発生回数を１とする。

図１２Ａは、時刻ｔ４における障害情報記憶部１６内のデータが示された表である。障害情報記憶部１６内のデータには、上述の通り、Ａ：Ａｍ、Ｃ：Ｃｍ、Ｅ：Ｅｍにおいて、「過剰なＣＰＵ消費」の障害がそれぞれ１回発生したことが記憶されている。さらに、発生回数の閾値が「３」であり、リカバリアクションが「強制ＧＣ」であることも記憶されている。ここで、Ａ：Ａｍ、Ｃ：Ｃｍ、Ｅ：Ｅｍのエントリの発生回数は、いずれも閾値は超えていない。そのため、障害イベント発行部１８は、障害発生イベントを発行しない。

その後、時刻ｔ５において、アプリケーションサーバ１１Ａ内で再びＣＰＵの過剰な消費が発生する。ここでは、障害解析部２２によって次の情報が解析により得られたものとする。
[コンポーネント名：インタフェース名] Ａ：Ａｍ、Ｂ：Ｂｍ、Ｃ：Ｃｍ（以下、コンポーネント及びそれに対応するインタフェースを同様に表示する。）

このとき、障害分析部２３は、上述と同様の処理を経て、障害情報記憶部１６に格納されたデータに、エントリを追加・更新する。

図１２Ｂは、時刻ｔ５における障害情報記憶部１６内のデータが示された表である。障害情報記憶部１６内のデータには、「過剰なＣＰＵ消費」の障害がＡ：Ａｍにおいて２回、Ｂ：Ｂｍにおいて１回、Ｃ：Ｃｍにおいて２回、Ｅ：Ｅｍにおいて１回発生したことが記憶されている。ここで、Ａ：Ａｍ、Ｃ：Ｃｍの障害発生回数は２となるが、まだ閾値に達していないため、障害イベント発行部１８は障害イベントを発行しない。

その後、時刻ｔ６において、アプリケーションサーバ１１Ａ内で再びＣＰＵの過剰な消費が発生する。ここでは、障害解析部２２によって次の情報が解析により得られたものとする。
[コンポーネント名：インタフェース名] Ａ：Ａｍ、Ｄ：Ｄｍ、Ｅ：Ｅｍ

このとき、障害分析部２３は、上述と同様の処理を経て、障害情報記憶部１６に格納されたデータに、エントリを追加・更新する。

図１２Ｃは、時刻ｔ６における障害情報記憶部１６内のデータが示された表である。障害情報記憶部１６内のデータには、「過剰なＣＰＵ消費」の障害がＡ：Ａｍにおいて３回、Ｂ：Ｂｍにおいて１回、Ｃ：Ｃｍにおいて２回、Ｄ：Ｄｍにおいて１回、Ｅ：Ｅｍにおいて２回発生したことが記憶されている。

ここで、Ａ：Ａｍにおいての障害発生回数は３となり、閾値に達している。そのため、障害分析部２３は、Ａ：ＡｍをＣＰＵの過剰な消費に伴う障害の原因と判断する。そして障害分析部２３は、次に発生回数が高かった、Ｃ：Ｃｍ、Ｅ：Ｅｍを、それぞれ障害の原因となるＡ：Ａｍについての関連コンポーネント、関連インタフェースとみなす。そして、障害イベント発行部１８は、障害の原因であるコンポーネント名及びインタフェース名（Ａ：Ａｍ）、関連コンポーネント名及び関連インタフェース名（Ｃ：Ｃｍ及びＥ：Ｅｍ）が示された障害イベントを分散管理サーバ２７に発行する。

その後なされる処理、つまり分散管理サーバ２７におけるリカバリアクションの実行及びアプリケーションサーバ１１への障害情報の発行、ならびに各アプリケーションサーバ１１における障害情報受信後の処理及びリクエスト処理スレッドの実行制御については、上述と同様である。

図１３Ａは、以上に示した過剰なＣＰＵ消費の障害発生防止のためのリクエスト処理制御のイメージ図である。図１３Ａにおいては、アプリケーションサーバ１１Ｂにおいて、コンポーネントＡのインタフェースＡｍに対する複数のリクエストがアプリケーション制御部に対してなされる。

ここで、コンポーネントＡのインタフェースＡｍが過剰にＣＰＵを消費するインタフェースである場合、複数のリクエストによりインタフェースＡｍが呼び出されると、他のリクエストの処理遅延等が発生してしまう。

アプリケーションサーバ１１Ｂは、先になされたコンポーネントＡのインタフェースＡｍに対するリクエストが終了するまで、後になされたコンポーネントＡのインタフェースＡｍに対するリクエストの実行を待機する。これにより、アプリケーションサーバ１１Ｂは、複数のリクエストによる呼び出しが行われなくなるため、他のリクエストの処理遅延等の発生を回避することができる。つまり、アプリケーションサーバ１１Ｂは、コンポーネントＡが持つインタフェースＡｍの実行を複数のスレッド間で同時に実行しないよう制御する。

なお、障害情報として、コンポーネントＡが持つインタフェースＡｍの次に（２番目に）発生回数が多かった障害候補としてコンポーネントＣのインタフェースＣｍがあり、それが別スレッドで実行中である場合が考えられる。この場合、アプリケーションサーバ１１Ｂは、その処理が完了するまでコンポーネントＡのインタフェースＡｍの実行を待機する。このように制御することで、複数のコンポーネントのインタフェースの呼び出しが原因となる障害の発生を未然に防ぐことが期待できる。障害候補として、既に閾値越えが発生しているコンポーネントのインタフェースが記録されている場合や、メモリの過剰消費についての障害発生回数が閾値を超えたコンポーネントのインタフェースが記録されている場合でも、同様の制御が実行できる。

なお、コンポーネントＡが持つインタフェースＡｍの次に発生回数が多かった障害候補として、同じコンポーネントＡの異なるインタフェースＡｍ２が記載されていてもよい。この場合、インタフェースＡｍ２が別スレッドで実行中であれば、アプリケーションサーバ１１Ｂは、その処理が完了するまでインタフェースＡｍの実行を待機する。

図１３Ｂは、過剰なＣＰＵ消費の障害が発生しうる場合（従来技術の場合）のリクエスト処理制御のイメージ図である。図１３Ｂでは、コンポーネントＡのインタフェースＡｍに対するリクエストが複数なされることによりインタフェースが呼び出されてしまうため、他のリクエストの処理遅延等の障害が発生してしまう。

以上に記載した実施の形態２における分散管理システム１０の処理をまとめる。障害が発生したアプリケーションサーバは、メモリやスレッド、ＣＰＵなどのリソース情報を分析して、アプリケーション障害の原因となる対象を、そのコンポーネントやインタフェースレベルで特定、または予測する。これにより、システム全体への影響を及ぼすアプリケーション障害を対処するにあたって、システム運用者が障害原因の特定（又は統計的な予測）をせずに済むため、システム運用者の負荷を軽減することができる。

そして、障害が発生したアプリケーションサーバは、その分析結果を他の同じ構成からなるアプリケーションサーバに発信することにより、障害情報を他のアプリケーションサーバと共有する。さらに、発信情報を受信したアプリケーションサーバは、他のアプリケーションサーバにおいて発生した障害と同様の障害発生を防止するために、受信した障害情報を蓄積する。そして、アプリケーションサーバは、蓄積した障害情報に基づいて、アプリケーションへのリクエストに対する監視を実行するほか、リクエストの実行順序やタイミングを制御する。

実施の形態２にかかる分散管理システム１０の効果は、以下の通りである。第一に、分散配置された複数のアプリケーションサーバから構成されるシステムにおいて、アプリケーションの欠陥に伴いシステム全体に波及する恐れがある障害を、未然に防ぐことができる。その理由は、アプリケーションの欠陥による障害情報を他のアプリケーションサーバに転送することによって、障害情報が転送されたアプリケーションサーバは、同じ障害に遭遇しないようにアプリケーションの実行を制御できるようになるからである。

アプリケーションの欠陥は、デッドロックやメモリの障害のように、その発生条件は特定の処理パターンに基づくことが多い。そのため、そのパターンを分析して、事前にその障害パターンを発生させないようにアプリケーションサーバがアプリケーションの呼び出しを制御することにより、分散管理システム全体を安定的に動作させることができる。換言すれば、アプリケーションサーバは、将来的に発生し得る他のアプリケーションサーバで発生した障害と同様の障害箇所に特化した監視及び処置を実行することができる。この監視及び処置において、アプリケーションサーバは、アプリケーションに対するリクエストの実行順序やタイミングを制御する。

第二の効果は、システム管理者の負担を抑えられる点にある。その理由は、分散管理システム１０により、システム運用者による作業を介入することなく、障害への（例えば暫定的な）対処を自動的に実施できるようになるからである。

一般的に、アプリケーションの欠陥が原因の障害は、根本的な解決にはアプリケーションプログラムの改修が必要である。すなわち、全てのアプリケーションサーバ上で動作中のコンポーネントを更新するまで、障害が再発する可能性がある。ここで、アプリケーションプログラムが改修され、そのテストを経てアプリケーションサーバ上のコンポーネントを更新するまでには、ある程度の期間を要する。

そのため、コンポーネント更新までの間、止むを得ずシステムを稼動し続けなければならない状況において同様の障害が発生した場合には、システム運用者によるアプリケーションサーバの再起動など、何らかの暫定的な対処作業が必要となる。また、この場合には、アプリケーションサーバの台数が増える程当該アプリケーションの欠陥に遭遇する可能性が高くなるため、システム運用者に過度な作業負荷を強いる可能性が高くなる。

しかしながら、実施の形態２にかかる分散管理システム１０は、システム運用者に代わって、アプリケーションサーバ自身が障害の再発を防ぐようにアプリケーションの実行を制御する。このため、このようなシステム運用者による対処作業は、アプリケーションサーバの数に関わらず不要となる。

近年、クラウド・コンピューティング技術を用いたシステムモデルの構築が増加している。このようなシステムは、多数のネットワーク上に分散的に配置された大多数のサーバマシンから構成されていることが多い。また、サーバマシンを構成するアプリケーションサーバは、互いに同じ構成を有することが多い。このようなシステムは、大抵が負荷分散構成であるため、一台の（障害発生などに伴う）サーバの異常がシステム全体に影響を及ぼす（すなわちシステム全体の障害に発展する）ことにはなりにくい。

しかし、その上で動作する業務アプリケーションそのものに欠陥が含まれる場合に、それを起因とする障害が一台で発生すると、近いうちに他のアプリケーションサーバにおいても同様の障害が立て続けに発生する可能性がある。そうなると、障害が、システム全体としてのパフォーマンスの低下や、非稼働時間に影響する可能性がある。ひいては、障害がシステムのＳＬＡ（Service Level Agreement）などへの品質問題に発展する恐れがある。この場合、欠陥のアプリケーションを従来のバージョンにダウングレードするなどの処置を取らない限り、上述のシステム運用者による暫定対応は避けられない。かつ、対象のサーバ台数が多くなると、それだけそのような障害に遭遇する確率も高くなり、ひいては暫定対応のための作業コストが増大することに繋がる。

ただし、アプリケーションの欠陥は、上述の通り、その発生条件が特定の処理パターンに基づくことが多い。そのため、そのパターンを分析して、事前にその障害パターンを発生させないようにアプリケーションの呼び出しをアプリケーションサーバが制御することによって、システムを安定して稼動できる可能性が高い。一方で、アプリケーションの欠陥を修復するまでには、たいていの場合、類似問題を発生させないよう、十分な評価期間と作業コストを要する。

以上より、このような状況においては、できるだけシステム運用者への負荷を掛けない状態で、欠陥を含んだ状態のアプリケーションのままで、システムを可能な限り安定して稼動できるように制御する仕組みを構築する必要があると考えられる。この場合、処理性能が多少劣化しても、システムを可能な限り安定して稼動できる方が重要であると考えられる。このようにすることによって、障害に対する根本解決までの作業コストの増大及びシステムの非稼動に伴う経済的な損失を阻止するという重要な目的が達成できるためである。

上述の通り、特許文献１、２においては、クラウド・コンピューティングのように、アプリケーションサーバ等のサーバを複数配置した状況は考慮されていない。

具体的には、特許文献１にかかるシステムでは、独自の判断条件に基づいて障害情報を蓄積し、それに基づいて検出した障害情報を専用の管理者端末に転送している。しかしながら、アプリケーションサーバ等が分散配置された環境については考慮していない。一方、実施の形態２にかかる分散管理システムは、分散配置された環境に障害情報を転送し、さらにその障害情報を基に障害の発生を防止する仕組みを有している。

また、特許文献２にかかるシステムでは、独自の判断条件に基づいて障害情報を予測又は検知すると、コンポーネントを入れ替えることによってシステム全体の障害の発生を防止している。しかし、この処理は動作する代替コンポーネントが存在することが前提である。言い換えれば、そのようなコンポーネントが存在しなければ、システム全体の障害の発生を防止するという効果の恩恵は受けられない。一方、実施の形態２にかかる分散管理システム１０では、コンポーネントの置換については考慮不要である。例えアプリケーションの欠陥を含んだままのコンポーネントであっても、分散管理システムはその欠陥部分に特定してアプリケーションの動作を制御した上で、コンポーネントをシステム障害が発生しないように最大限活用することができる。

なお、実施の形態２に記載された分散管理システムは、以下の効果も奏する。アプリケーションサーバ１１Ａは、アプリケーションの障害が発生した場合に、アプリケーションサーバ１１Ａにおける障害のリカバリに必要なリカバリアクション（リカバリ処理）を特定する情報を含む障害イベント（障害情報）を生成する。分散管理サーバ２７は、アプリケーションサーバ１１Ａが発行した障害イベントからリカバリアクションを特定する情報を抽出してアプリケーションサーバ１１Ａに送信する。アプリケーションサーバ１１Ａは、分散管理サーバ２７から送信されたリカバリアクションを特定する情報に基づいて、障害のリカバリアクションを実行する。これにより、障害が発生したときにアプリケーションサーバ１１Ａが自身で障害のリカバリアクションを実行できないときでも、分散管理サーバ２７の要求に基づいた処理を実行することにより、障害リカバリアクションを実行できる。さらに、障害が発生したときでも、各アプリケーションサーバ１１においてリカバリアクションの制御をシステム管理者が判断する必要がなく、分散管理サーバ２７においてリカバリアクションの制御を扱うことができる。そのため、システム管理者の負担を軽減することができる。

アプリケーションサーバ１１Ａにおけるアプリケーションの障害は、自身のクライアントからのリクエストに基づいて発生したものであり、アプリケーションサーバ１１Ｂは、アプリケーションサーバ１１Ａが生成した障害イベントに基づいて、自身のクライアントからのリクエストをモニタリングする。これにより、分散管理システム１０は、クライアントからのリクエストによって生ずる障害の発生を防止することができる。

アプリケーションサーバ１１Ａにおいて、あるコンポーネントのインタフェース（第１のインタフェース）において閾値以上の障害が発生した場合に、アプリケーションサーバ１１Ａは、その第１のインタフェースを前記障害の原因として特定する。さらにアプリケーションサーバ１１Ａは、第１のインタフェースの次に多く障害が発生した別のコンポーネントのインタフェース（第２のインタフェース）を、障害の関連情報として含む障害イベントを出力する。アプリケーションサーバ１１Ｂは、障害イベントに基づき、第１のインタフェースがクライアントからリクエストされた場合に第２のインタフェースがスレッドにおいて実行中であるか否かを判定し、実行中である場合に前記リクエストの処理を実行させないようにする。これにより、障害原因に関連すると推測される処理を実行しないようにするため、分散管理システム１０の障害発生をより精度よく防止することができる。

アプリケーションサーバ１１Ａにおいて、あるコンポーネントのインタフェース（第１のインタフェース）において閾値以上の障害が発生した場合に、アプリケーションサーバ１１Ａは、その第１のインタフェースを前記障害の原因として特定する。さらにアプリケーションサーバ１１Ａは、その他に閾値以上の障害が発生した別のコンポーネントのインタフェース（第３のインタフェース）を、障害の関連情報として含む障害イベントを出力する。アプリケーションサーバ１１Ｂは、障害イベントに基づき、第１のインタフェースがクライアントからリクエストされた場合に第３のインタフェースがスレッドにおいて実行中であるか否かを判定し、実行中である場合にリクエストの処理を実行させないようにする。これにより、障害原因に関連すると推測される処理を実行しないようにするため、分散管理システム１０の障害発生をより精度よく防止することができる。

アプリケーションサーバ１１Ａにおいて、あるコンポーネントのインタフェース（第１のインタフェース）において閾値以上の障害が発生した場合に、アプリケーションサーバ１１Ａは、その第１のインタフェースを前記障害の原因として特定する。さらにアプリケーションサーバ１１Ａは、その他に障害が発生した別のコンポーネントのインタフェース（第２のインタフェース）を、障害の関連情報として含む障害イベントを出力する。アプリケーションサーバ１１Ｂは、障害イベントに基づき、第１のインタフェースがクライアントからリクエストされた場合に、第２のインタフェースがスレッドにおいて実行中であるか否かを判定し、実行中である場合にリクエストの処理を実行させないようにする。これにより、障害原因に関連すると推測される処理を実行しないようにするため、分散管理システム１０の障害発生をより精度よく防止することができる。

なお、上述の場合において、アプリケーションサーバ１１Ｂは、障害イベントに基づき、第１のインタフェースがクライアントからリクエストされた場合に、第１のインタフェースがスレッドにおいて実行中であるか否かをさらに判定する。第１のインタフェースが実行中である場合に、アプリケーションサーバ１１Ｂは、リクエストの処理を実行させないようにする。これにより、障害原因と特定された処理を一度に実行するスレッドの数をより少なくできるため、分散管理システム１０の障害発生をより精度よく防止することができる。

上述の第１のインタフェースにおける障害、第２のインタフェースにおける障害は、それぞれメモリの使用率が基準を超えること又はＣＰＵの使用率が基準を超えることのいずれかである。これにより、分散管理システム１０におけるアプリケーション起因の障害において頻発する障害を的確に防止することができる。さらに、第１のインタフェースにおける障害をメモリの使用率が基準を超えることとし、第２のインタフェースにおける障害をＣＰＵの使用率が基準を超えることとしてもよい。このように、アプリケーションサーバは、異なる種類であっても、処理に時間がかかってしまうという共通した性質を有する障害同士について、その原因となったコンポーネント及びインタフェースの情報を、障害を特定する情報及び障害関連情報として障害イベントに含み、発行する。これにより、類似の性質を有する障害の原因となる処理を一度に実行するスレッドの数をより少なくできるため、分散管理システム１０の障害発生をより精度よく防止することができる。

アプリケーションサーバ１１Ａにおいて、あるコンポーネントのインタフェース（第１のインタフェース）と別のコンポーネントのインタフェース（第２のインタフェース）間におけるデッドロックが障害として発生した場合に、アプリケーションサーバ１１Ａは、第１のインタフェースと第２のインタフェースとを障害の原因として特定する障害イベントを出力する。アプリケーションサーバ１１Ｂは、障害イベントに基づき、第１のインタフェースがクライアントからリクエストされた場合に第２のインタフェースがスレッドにおいて実行中であるか否かを判定し、実行中である場合にリクエストの処理を実行させないようにする。これにより、分散管理システム１０のアプリケーションサーバ１１において、デッドロックを確実に防止することができる。

実施の形態２に記載された分散管理システムは、例えばＷｅｂアプリケーションサーバやコンピュータ管理アプリケーションなどのミドルウェアにおいて適用することができる。これにより、アプリケーションの欠陥に伴うシステム停止（またはその期間）を抑えることができ、また、障害発生への対処に伴うシステム運用者への負荷を軽減することが期待できる。

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

例えば、実施の形態２に記載した分散管理システム１０におけるアプリケーションコンポーネントを、Ｗｅｂアプリケーションサーバなどを構成するモジュールやシステムコンポーネントに置き換えた上で、分散管理システムの構成及び処理を図１から図１１と同様の構成としてもよい。このようにしても、分散配置されたアプリケーションサーバの運用操作におけるデッドロックやメモリ不足などの障害を未然に防ぐことができる。

実施の形態２では、デッドロック、ＣＰＵ又はメモリの過剰消費を例示したが、障害の種類はこれにとどまらない。

以下、本発明の各種形態を付記する。
（付記１）
同じアプリケーションを実行可能な第１のサーバ及び第２のサーバを備える分散システムであって、
前記第１のサーバにおいて前記アプリケーションの障害が発生した場合に、前記第１のサーバは、前記アプリケーションの障害原因を特定する障害情報を生成し、
前記第２のサーバは、前記障害情報に基づいて決定された、前記アプリケーションの障害発生を防止するための障害発生防止処理を実行する、
分散システム。
（付記２）
前記分散システムは、前記第１のサーバ及び前記第２のサーバを管理する分散管理サーバをさらに備え、
前記アプリケーションの障害が発生した場合に、前記第１のサーバは、前記第１のサーバにおける障害のリカバリに必要なリカバリ処理を特定する情報を含む前記障害情報を生成し、
前記分散管理サーバは、前記障害情報から前記リカバリ処理を特定する情報を抽出して前記第１のサーバに送信し、
前記第１のサーバは、前記分散管理サーバから送信された前記リカバリ処理を特定する情報に基づいて、前記障害のリカバリ処理を実行する、
付記１に記載の分散システム。
（付記３）
前記第１のサーバにおける前記アプリケーションの障害は、前記第１のサーバのクライアントからのリクエストに基づいて発生したものであり、
前記第２のサーバは、前記障害情報に基づき、前記第２のサーバのクライアントからのリクエストをモニタリングする、
付記１又は２に記載の分散システム。
（付記４）
前記第１のサーバ及び前記第２のサーバは、前記アプリケーションにかかる複数のコンポーネントを有し、
前記第１のサーバにおいて、第１のコンポーネントの第１のインタフェースにおいて閾値以上の障害が発生した場合に、前記第１のサーバは、前記第１のインタフェースを前記障害の原因として特定し、かつ、前記複数のコンポーネントのインタフェースにおいて前記第１のインタフェースの次に多く障害が発生した第２のコンポーネントの第２のインタフェースを前記障害の関連情報として含む前記障害情報を出力し、
前記第２のサーバは、前記障害情報に基づき、前記第１のインタフェースが前記第２のサーバのクライアントからリクエストされた場合に、前記第２のインタフェースがスレッドにおいて実行中であるか否かを判定し、実行中である場合に前記リクエストの処理を実行させないようにする、
付記３に記載の分散システム。
（付記５）
前記第１のサーバ及び前記第２のサーバは、前記アプリケーションにかかる複数のコンポーネントを有し、
前記第１のサーバにおいて、第１のコンポーネントの第１のインタフェースにおいて閾値以上の障害が発生するとともに、前記第１のインタフェースの他に閾値以上の障害が発生した第２のコンポーネントの第２のインタフェースがある場合には、前記第１のサーバは、前記第１のインタフェースを前記障害の原因として特定し、かつ、前記第２のインタフェースを前記障害の関連情報として含む前記障害情報を出力し、
前記第２のサーバは、前記障害情報に基づき、前記第１のインタフェースが前記第２のサーバのクライアントからリクエストされた場合に、前記第２のインタフェースがスレッドにおいて実行中であるか否かを判定し、実行中である場合に前記リクエストの処理を実行させないようにする、
付記３又は４に記載の分散システム。
（付記６）
前記第２のサーバは、前記障害情報に基づき、前記第１のインタフェースが前記第２のサーバのクライアントからリクエストされた場合に、前記第１のインタフェースが既にスレッドにおいて実行中であるか否かをさらに判定し、実行中である場合に前記リクエストの処理を実行させないようにする、
付記４又は５に記載の分散システム。
（付記７）
前記第１のサーバ及び前記第２のサーバは、前記アプリケーションにかかる複数のコンポーネントを有し、
前記第１のサーバにおいて、第１のコンポーネントの第１のインタフェースと第２のコンポーネントの第２のインタフェース間におけるデッドロックが前記障害として発生した場合に、前記第１のサーバは、前記第１のインタフェースと前記第２のインタフェースとを前記障害の原因として特定する前記障害情報を出力し、
前記第２のサーバは、前記障害情報に基づき、前記第１のインタフェースが前記第２のサーバのクライアントからリクエストされた場合に、前記第２のインタフェースがスレッドにおいて実行中であるか否かを判定し、実行中である場合に前記リクエストの処理を実行させないようにする、
付記３ないし５のいずれか一項に記載の分散システム。
（付記８）
分散システムに設けられ、同じアプリケーションを実行可能な他のサーバ計算機と接続されたサーバ計算機であって、
前記アプリケーションの障害が発生した場合に、前記アプリケーションの障害原因を特定する障害情報を生成し、
前記他のサーバが前記アプリケーションの障害原因を特定する障害情報を生成した場合に、前記障害情報に基づいて決定された、前記アプリケーションの障害発生を防止するための障害発生防止処理を実行する、
サーバ計算機。
（付記９）
同一のアプリケーションを実行可能な第１のサーバ及び第２のサーバを備えた分散システムに設けられた分散管理サーバであって、
前記第１のサーバから、前記第１のサーバにおけるアプリケーションの障害原因を特定する障害情報を受信した場合に、前記第２のサーバにおいて前記アプリケーションの障害発生を防止するための障害発生防止処理を実行するために用いられる情報として、前記第２のサーバに前記障害情報を通知する分散管理サーバ。
（付記１０）
同じアプリケーションを実行可能な第１のサーバ及び第２のサーバを備える分散システムにおいてアプリケーションの障害発生を防止する障害発生防止方法であって、
前記第１のサーバにおいて前記アプリケーションの障害が発生した場合に、前記第１のサーバは、前記アプリケーションの障害原因を特定する障害情報を生成するステップと、
前記第２のサーバは、前記障害情報に基づいて決定された、前記アプリケーションの障害発生を防止するための障害発生防止処理を実行するステップと、を備える
障害発生防止方法。
（付記１１）
前記第１のインタフェースにおける障害、前記第２のインタフェースにおける障害は、それぞれメモリの使用率が基準を超えること又はＣＰＵの使用率が基準を超えることのいずれかである、
付記４ないし６のいずれか一項に記載の分散システム。
（付記１２）
前記第１のインタフェースにおける障害は、メモリの使用率が基準を超えること又はＣＰＵの使用率が基準を超えることの一方であり、前記第２のインタフェースにおける障害は、メモリの使用率が基準を超えること又はＣＰＵの使用率が基準を超えることの他方である、
付記１１に記載の分散システム。

１ 分散システム
２、３ サーバ計算機
４、５ アプリケーション
６ 分散管理サーバ
１０ 分散管理システム
１１ アプリケーションサーバ
１２ リクエスト受付部
１３ リクエスト解析部
１４ 運用リクエスト受付部
１５ 障害情報受信部
１６ 障害情報記憶部
１７ 記憶装置
１８ 障害イベント発行部
１９ アプリケーション実行制御部
２０ 実行管理部
２１ 障害監視部
２２ 障害解析部
２３ 障害分析部
２４ 障害候補格納部
２５ 障害情報検索部
２６ コンポーネント
２７ 分散管理サーバ
２８ アプリケーション格納部
２９ アプリケーション情報管理部
３０ 障害イベント受信部
３１ イベント解析部
３２ 運用操作発行部
３３ 障害情報発行部
３４ クライアントアプリケーション

Claims (9)

1. 同じアプリケーションを実行可能な第１のサーバ及び第２のサーバを備える分散システムであって、
   前記第１のサーバにおいて前記アプリケーションの障害が発生した場合に、前記第１のサーバは、前記アプリケーションの障害原因を特定する障害情報であって、前記アプリケーションにおいて障害を生じさせたコンポーネント、又は前記コンポーネントに関するインタフェースを示す障害情報を生成し、
   前記第２のサーバは、前記障害情報に基づいて決定された、前記アプリケーションの障害発生を防止するための障害発生防止処理を実行し、
   前記第１のサーバ及び前記第２のサーバは、それぞれ前記アプリケーションに関する複数の前記コンポーネントを有し、
   前記障害が第１のコンポーネントの第１のインタフェース及び第２のコンポーネントの第２のインタフェースに発生する場合に、前記第１のサーバは、前記第１のインタフェース及び前記第２のインタフェースを示す前記障害情報を出力し、
   前記第１のインタフェースが前記第２のサーバのクライアントからリクエストされた場合に、前記第２のサーバは、前記障害情報に基づいて、前記第２のインタフェースが実行中であるか否かを判定し、実行中である場合に前記リクエストの処理を実行させないようにする、
   分散システム。
2. 前記第１のコンポーネントの前記第１のインタフェースにおいて閾値以上の障害が発生した場合に、前記第１のサーバは、前記第１のインタフェース及び前記複数のコンポーネントのインタフェースにおいて前記第１のインタフェースの次に多く障害が発生した第２のコンポーネントの前記第２のインタフェースを示す前記障害情報を出力する、
   請求項１記載の分散システム。
3. 前記第１のコンポーネントの前記第１のインタフェースにおいて閾値以上の障害が発生するとともに、前記第１のインタフェースの他に閾値以上の障害が発生した前記第２のコンポーネントの前記第２のインタフェースがある場合には、前記第１のサーバは、前記第１のインタフェース及び前記第２のインタフェースを示す前記障害情報を出力する、
   請求項１又は２に記載の分散システム。
4. 前記第２のサーバは、前記障害情報に基づき、前記第１のインタフェースが前記第２のサーバのクライアントからリクエストされた場合に、前記第１のインタフェースが既に実行中であるか否かをさらに判定し、実行中である場合に前記リクエストの処理を実行させないようにする、
   請求項１乃至３のいずれか１項に記載の分散システム。
5. 前記第１のサーバ及び前記第２のサーバは、前記アプリケーションにかかる複数のコンポーネントを有し、
   前記第１のサーバにおいて、第１のコンポーネントの第１のインタフェースと第２のコンポーネントの第２のインタフェース間におけるデッドロックが前記障害として発生した場合に、前記第１のサーバは、前記第１のインタフェースと前記第２のインタフェースとを前記障害の原因として特定する前記障害情報を出力する、
   請求項１乃至４のいずれか一項に記載の分散システム。
6. 前記第１のインタフェースにおける障害及び前記第２のインタフェースにおける障害は、それぞれメモリの使用率が基準を超えること又はＣＰＵの使用率が基準を超えることのいずれかである、
   請求項１乃至４のいずれか一項に記載の分散システム。
7. 前記第１のインタフェースにおける障害は、メモリの使用率が基準を超えること又はＣＰＵの使用率が基準を超えることの一方であり、前記第２のインタフェースにおける障害は、メモリの使用率が基準を超えること又はＣＰＵの使用率が基準を超えることの他方である、
   請求項６に記載の分散システム。
8. 分散システムに設けられ、同じアプリケーションを実行可能な他のサーバ計算機と接続されたサーバ計算機であって、
   前記アプリケーションの障害が発生した場合に、前記アプリケーションの障害原因を特定する障害情報であって、前記アプリケーションにおいて障害を生じさせたコンポーネント、又は前記コンポーネントに関するインタフェースを示す障害情報を生成し、
   前記他のサーバが前記アプリケーションの障害原因を特定する障害情報を生成した場合に、前記障害情報に基づいて決定された、前記アプリケーションの障害発生を防止するための障害発生防止処理を実行し、
   前記サーバ計算機は、前記アプリケーションに関する複数の前記コンポーネントを有し、
   前記障害が第１のコンポーネントの第１のインタフェース及び第２のコンポーネントの第２のインタフェースに発生する場合に、前記サーバ計算機は、前記第１のインタフェース及び前記第２のインタフェースを示す前記障害情報を出力し、
   前記第１のインタフェースが前記サーバ計算機のクライアントからリクエストされた場合に、前記出力された障害情報を受信する前記サーバ計算機は、前記障害情報に基づいて、前記第２のインタフェースが実行中であるか否かを判定し、実行中である場合に前記リクエストの処理を実行させないようにする、
   サーバ計算機。
9. 同じアプリケーションを実行可能な第１のサーバ及び第２のサーバを備える分散システムにおいてアプリケーションの障害発生を防止する障害発生防止方法であって、
   前記第１のサーバにおいて前記アプリケーションの障害が発生した場合に、前記第１のサーバは、前記アプリケーションの障害原因を特定する障害情報であって、前記アプリケーションにおいて障害を生じさせたコンポーネント、又は前記コンポーネントに関するインタフェースを示す障害情報を生成するステップと、
   前記第２のサーバは、前記障害情報に基づいて決定された、前記アプリケーションの障害発生を防止するための障害発生防止処理を実行するステップと、
   前記障害が第１のコンポーネントの第１のインタフェース及び第２のコンポーネントの第２のインタフェースに発生する場合に、前記第１のサーバは、前記第１のインタフェース及び前記第２のインタフェースを示す前記障害情報を出力するステップと、
   前記第１のインタフェースが前記第２のサーバのクライアントからリクエストされた場合に、前記第２のサーバは、前記障害情報に基づいて、前記第２のインタフェースが実行中であるか否かを判定し、実行中である場合に前記リクエストの処理を実行させないようにするステップと、を備える
   障害発生防止方法。

Images