JP4866429B2 - システム障害を精度良く検出する技術 - Google Patents

Description

本発明は、システム障害を精度良く検出する技術に関する。特に、本発明は、複数のサーバ装置が相互に通信するシステムにおいて、障害を精度良く検出する技術に関する。

近年、大規模なウェブサイトは単一のサーバ装置ではなく複数のサーバ装置を備えたシステムによって実現される。このようなシステムは多層サーバシステムと呼ばれ、たとえば、ＨＴＴＰプロトコルに関する制御を行うサーブレットサーバ、呼び出されたアプリケーションを動作させるアプリケーションサーバ、データベースのトランザクションを行うデータベースサーバなどを備える。このような多層サーバシステムにおいて発生した障害を検出するために、従来、これらのサーバ群とは別体に設けられた監視用サーバが用いられている。

監視用サーバは、システム内の各サーバからその状態を定期的に収集する。たとえば、供給電圧、ＣＰＵの温度、および、ＣＰＵのビジー率などのハードウェアの状態が収集されて、その状態が通常とは異なる場合に、当該システムに異常が発生したと判断される。但し、このような監視用サーバのみによっては、ソフトウェアに生じた異常を判断できない場合がある。このため、各サーバにおいては、当該サーバから他のサーバに要求したトランザクションの所要時間を計測して、その時間の長さが所定の範囲内かどうか判断することで、ソフトウェア由来の障害を検出可能としている。

障害検出に関する参考技術としては以下の特許文献１−２を参照されたい。
特開２００１−２８２７５９号公報 特開２００３−１９６１７８号公報

上述の多層サーバシステムにおいては、第１のサーバが第２のサーバに処理を要求し、要求を受けた第２のサーバが第３のサーバに更に処理を要求することがある。このような場合、第１のサーバに返送される処理応答が遅延しても、第２のサーバおよび第３のサーバの何れに障害が発生しているかどうかは第１のサーバには分からない。このような場合に第２のサーバに障害が発生したものとみなして処理要求の送信経路などを変更してしまえば、不用意に処理効率を低下させるおそれがある。

また、サーバ上で動作するプログラムがＪａｖａ言語（登録商標）で記述されている場合には、Ｊａｖａのミドルウェアがガーベージ・コレクション（ＧＣ）を定期的に行う場合がある。ＧＣとは、プログラムが確保したものの不要となった記憶領域を、そのプログラムの動作とは独立に、たとえば定期的に解放する処理である。この場合には、サーバにおける処理が一時的には遅延するが、ＧＣが終了すればすぐに元の状態に戻る。このような一時的な状態をもってサーバに障害が発生したと判断すれば、システムを効率的に活用する観点から不都合である。

そこで本発明は、上記の課題を解決することのできるシステム、方法およびプログラムを提供することを目的とする。この目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。

上記課題を解決するために、本発明の一側面においては、外部の端末装置から要求された処理を振り分ける複数のディスパッチャ装置と、振り分けられた当該処理を行う複数の第１階層サーバと、第１階層サーバから受けた要求に応じて当該処理の一部を行う少なくとも１つの第２階層サーバとを備えるシステムであって、それぞれのディスパッチャ装置は、それぞれの第２階層サーバの稼動状態を示す状態テーブルを格納するための記憶装置と、要求された処理を振り分けるために、外部の端末装置から受けた処理要求を複数の第１階層サーバの中から選択した一の第１階層サーバに転送する転送部と、それぞれの第２階層サーバの稼動状態を、転送された処理要求に対応する処理応答に含めて受信し、受信した稼動状態に基づいて第２階層サーバ毎の稼動状態を評価して、第２階層サーバ毎の稼動状態を示す状態テーブルを生成して記憶装置に記憶するテーブル生成部と、状態テーブルの生成に応じ、生成した状態テーブルを記憶装置から読み出してそれぞれの第１階層サーバに送信するテーブル送信部と、何れかの第１階層サーバからの状態テーブルの受信に応じて、受信した状態テーブルにより記憶装置に記憶した状態テーブルを更新する第１テーブル更新部とを有し、それぞれの第１階層サーバは、それぞれの第２階層サーバの稼動状態を示す状態テーブルを格納するための記憶装置と、ディスパッチャ装置の転送部から処理要求の転送を受けたことに応じて、要求された処理の一部を第２階層サーバに処理させるために、第２階層サーバに処理要求を送信する要求送信部と、第２階層サーバに送信した処理要求に対する処理応答の状態を、当該第２階層サーバの稼動状態として、ディスパッチャ装置の転送部から転送を受けた処理要求に対する処理応答に含めて当該ディスパッチャ装置に返信する状態返信部と、ディスパッチャ装置のテーブル送信部から状態テーブルを受信したことに応じて、受信した当該状態テーブルに基づき記憶装置に既に格納された状態テーブルを更新する第２テーブル更新部と、状態テーブルの更新に応じて、更新した状態テーブルをそれぞれのディスパッチャ装置に返信するテーブル返信部とを有するシステムを提供する。また、当該システムにより各サーバの状態を管理する方法、および、当該システムとして複数の情報処理装置を機能させるプログラムを提供する。
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、情報システム１０の構成の一例を示す。情報システム１０は、ディスパッチャ装置１００−１〜２と、サーブレットサーバ１１０−１〜４と、ＡＰＰサーバ１２０−１〜３と、ＤＢサーバ１３０と、データベース１３５と、システム監視装置１４０と、情報共有装置１５０とを備える。ディスパッチャ装置１００−１〜２のそれぞれは、サーブレットサーバ１１０−１〜４に直接接続されている。そして、ディスパッチャ装置１００−１〜２は、外部の端末装置から要求された処理をサーブレットサーバ１１０−１〜４に振り分ける。

たとえば、ディスパッチャ装置１００−１〜２のそれぞれは、順次受け取る処理要求をラウンドロビン方式によってサーブレットサーバ１１０−１〜４のそれぞれに転送してもよい。即ち、ディスパッチャ装置１００−１は、１回目に受け取った処理要求をサーブレットサーバ１１０−１に転送し、２回目に受け取った処理要求をサーブレットサーバ１１０−２に転送し、３回目に受け取った処理要求をサーブレットサーバ１１０−３に転送し、４回目に受け取った処理要求をサーブレットサーバ１１０−４に転送する。５回目からは元に戻り、処理要求はサーブレットサーバ１１０−１に転送される。

サーブレットサーバ１１０−１〜４のそれぞれは、本発明に係る第１階層サーバの一例であり、具体的には例えばＨＴＴＰサーバなどである。そして、サーブレットサーバ１１０−１〜４のそれぞれは、ディスパッチャ装置１００−１〜２から振り分けられた処理要求に応じて処理を行う。処理の過程で、所定のアプリケーション・プログラムの呼び出しや、データベースに対するアクセスの必要が生じる場合がある。そのような場合は、サーブレットサーバ１１０−１〜４のそれぞれは、ＡＰＰ（アプリケーション）サーバ１２０−１〜３またはＤＢサーバ１３０に対し更に処理要求を送信して、外部の端末装置から要求された処理の少なくとも一部を処理させる。ＡＰＰサーバ１２０−１〜３のそれぞれは、本発明に係る第２階層サーバの一例であり、外部の端末装置が要求した処理の一部を、サーブレットサーバ１１０−１〜４から受けた要求に応じて処理する。ＤＢサーバ１３０は、処理の過程でデータベース１３５からデータを読み出し、または、データベース１３５を更新してもよい。なお、ＤＢサーバ１３０もまた第２階層サーバの一例である。即ち第２階層サーバには、サーブレットサーバから直接要求を受けるものの他、他のサーバ／装置（ここではＡＰＰサーバ１００−１〜３）を介して間接的に要求を受けて、その要求に応じて要求された処理の一部を処理するものも含まれる。

システム監視装置１４０は、ディスパッチャ装置１００−１〜２、サーブレットサーバ１１０−１〜４、ＡＰＰサーバ１２０−１〜３およびＤＢサーバ１３０のそれぞれにおいて動作しているエージェントソフトウェアなどから、これらそれぞれの装置・サーバの状態を示すデータを受信する。たとえば、それぞれの装置・サーバにおけるＣＰＵの利用率、ハードディスクドライブのアクセス頻度などのハードウェアの稼動状態や、ＣＰＵや筐体の温度などの物理状態を示すデータが受信される。そして、情報共有装置１５０は、システム監視装置１４０が受信したこれらそれぞれのデータに基づいて、情報システム１０が有する何れかの装置・サーバに異常が発生したかどうかを判断し、その判断結果を外部に通知したり、異常が発生した装置・サーバを停止させるなどの処理を行う。

図１に示す情報システム１０によれば、情報システム１０中の各装置・サーバの状態を監視して、情報システム１０に生じた異常を検出することができるとも考えられる。しかしながら、このような情報システム１０の構成によっては、ソフトウェアが主な原因で生じた異常は適切に検出できない場合がある。例えば、ソフトウェアの設計等の不良が原因のデッドロックは、ソフトウェアそれ自体は設計通り正常動作していることから、ＣＰＵの状態等によってはその発生を適切に検出できない。また、本来必要なサーバ・装置に加えてシステム監視装置１４０および情報共有装置１５０が必要なので、他のサーバ・装置が正常でもシステム監視装置１４０および情報共有装置１５０自体の異常が原因で誤って異常を検出してしまう場合がある。
これに対し、以降において説明する情報システム１０によれば、異常検出のための機構を、処理要求や処理応答の送受信の機構に組み込むことで、情報システム１０における本来の動作に悪影響を与えることなく、様々な種類の異常を検出することができる。
以降、具体的に説明する。

図２は、本実施形態に係る情報システム１０の全体構成を示す。情報システム１０は、図１と同様に、ディスパッチャ装置１００−１〜２と、サーブレットサーバ１１０−１〜４と、ＡＰＰサーバ１２０−１〜３と、ＤＢサーバ１３０と、データベース１３５とを備える。但し、図１に示した情報システム１０とは異なり、図２の情報システム１０は、システム監視装置１４０および情報共有装置１５０を備えなくてもよい。ディスパッチャ装置１００−１〜２、サーブレットサーバ１１０−１〜４、ＡＰＰサーバ１２０−１〜３、ＤＢサーバ１３０およびデータベース１３５のそれぞれにおける処理の概要は、図１に示したものと同様である。但し、それぞれのサーバ・装置においては、処理要求および処理応答の送受信に加えて、異常検出のための処理を行う。また、異常検出に用いるために、それぞれのサーバ・装置は、処理要求を他のサーバ・装置に送信してから、その処理応答を受信するまでの所要時間を計測する機構を備えるものとする。

図３は、ディスパッチャ装置１００−１の機能構成を示す。ディスパッチャ装置１００−１は、記憶装置３００と、転送部３１０と、テーブル生成部３２０と、テーブル送信部３３０と、第１テーブル更新部３４０と、停止判断部３５０とを有する。まず、これら各部材とハードウェア資源との関係について簡単に述べる。記憶装置３００は、他の各部材に必要な情報を記憶するものであり、例えば後述のＲＡＭ１０２０またはハードディスクドライブ１０４０により実現される。転送部３１０およびテーブル送信部３３０は、情報の送受信等を行うものであり、後述のＣＰＵ１０００および通信インターフェイス１０３０を、インストールされたプログラムに基づき動作させることにより実現される。テーブル生成部３２０、第１テーブル更新部３４０および停止判断部３５０は、情報の演算・加工および条件判断を行うものであり、後述のＣＰＵ１０００を、インストールされたプログラムに基づき動作させることにより実現される。

記憶装置３００は、各装置・サーバの稼動状態を示す状態テーブルを格納するために設けられている。状態テーブルとは、具体的には、サーブレットサーバ１１０−１〜４、ＡＰＰサーバ１２０−１〜３およびＤＢサーバ１３０のそれぞれの稼動状態を示すものをいう。そして、稼動状態とは、たとえば、正常状態、動作しているが処理に閾値以上の時間を要する高負荷状態、動作していない異常状態、高負荷状態の疑いがある疑高負荷状態、および、異常状態の疑いがある疑異常状態の何れかである。

転送部３１０は、要求された処理を振り分けるために、外部の端末装置から受けた処理要求を、複数のサーブレットサーバ１１０−１〜４の中から選択した一のサーブレットサーバ１１０に転送する。前述のように、サーブレットサーバ１１０の選択はラウンドロビン方式で行われてもよい。テーブル生成部３２０は、それぞれのＡＰＰサーバ１２０−１〜３およびＤＢサーバ１３０の稼動状態を、転送された処理要求に対応する処理応答に含めて受信する。

ここで処理応答に含めて受信する稼動状態とは、好ましくは、その処理要求に応じてサーブレットサーバ１１０−１〜４がＡＰＰサーバ１２０−１〜３に要求した処理の所要時間を示す情報である。つまり、転送部３１０がある処理要求Ａをサーブレットサーバ１１０−１に転送し、それを受信したサーブレットサーバ１１０−１がその要求Ａに応じて処理要求ＢをＡＰＰサーバ１２０−１に送信した場合、その処理要求Ｂに応じた処理の所要時間が、処理要求Ａに対する処理応答Ａに含めて受信される。

各稼動状態の具体例として、例えば、異常状態は、所要時間が５秒超であることを示し、高負荷状態は、所要時間が２秒超５秒以下であることを示し、正常状態は、所要時間が２秒以下であることを示す。テーブル生成部３２０が受信する時点では、稼動状態はこのような所要時間を示す数値そのものであってもよいし、既にその数値に基づき判断された各状態を示すものであってもよい。また、稼動状態は、所要時間のほか、各サーバや装置における処理の状態を示すその他の指標値を示すものであってもよい。

指標値の例としては、処理のスループット、レイテンシなどが挙げられる。また、テーブル生成部３２０は、各処理についての所要時間を稼動状態として受信するのではなく、一定期間に応答を受信した複数処理についての所要時間の平均を稼動状態として受信してもよい。そして、テーブル生成部３２０は、受信した稼動状態に基づいてＡＰＰサーバ１２０−１〜３およびＤＢサーバ１３０のそれぞれについての稼動状態を評価して、評価した各稼動状態を示す状態テーブルを生成して記憶装置３００に記憶する。

稼動状態の評価とは、あるＡＰＰサーバ１２０について受信した稼動状態そのものをそのＡＰＰサーバ１２０の稼動状態として取り扱う処理であってもよいし、同一のＡＰＰサーバ１２０について異なる複数の稼動状態を受信した場合に、それら複数の稼動状態に基づき単一の稼動状態を定める処理であってもよい。さらには、テーブル生成部３２０は、サーブレットサーバ１１０−１〜４のそれぞれに対し処理要求を送信してからその処理要求に対する処理応答を受信するまでの所要時間に基づいて、サーブレットサーバ１１０毎の稼動状態を評価して、状態テーブルに含めて生成してもよい。

テーブル送信部３３０は、状態テーブルの生成に応じ、生成したその状態テーブルを記憶装置３００から読み出して、それぞれのサーブレットサーバ１１０−１〜４に送信する。第１テーブル更新部３４０は、何れかのサーブレットサーバ１１０−１〜４からの状態テーブルの受信に応じて、受信したこの状態テーブルにより、記憶装置３００に既に記憶している状態テーブルを更新する。停止判断部３５０は、記憶装置３００に記憶した状態テーブルにおいて、何れのサーブレットサーバ１１０も、稼動状態が正常状態でないことを条件に、テーブル生成部３２０による稼動状態の受信、および、テーブル送信部３３０による状態テーブルの送信を停止させる。
なお、ディスパッチャ装置１００−２が有する各機能についてはディスパッチャ装置１００−１と略同一であるから説明を省略する。

図４は、サーブレットサーバ１１０−１の機能構成を示す。サーブレットサーバ１１０−１は、記憶装置４００と、要求送信部４１０と、状態返信部４２０と、第２テーブル更新部４３０と、テーブル返信部４４０とを有する。ディスパッチャ装置１００−１の場合と同様、まず、ハードウェア資源との関連について述べる。記憶装置４００は、他の各部材に必要な情報を記憶するものであり、例えば後述のＲＡＭ１０２０またはハードディスクドライブ１０４０により実現される。要求送信部４１０およびテーブル返信部４４０は、処理応答等の送受信を行うものであり、後述のＣＰＵ１０００および通信インターフェイス１０３０を、インストールされたプログラムに基づき動作させることにより実現される。状態返信部４２０および第２テーブル更新部４３０は、情報の演算・加工および条件判断を行うものであり、後述のＣＰＵ１０００を、インストールされたプログラムにより動作させることにより実現される。

記憶装置４００は、サーブレットサーバ１１０−１〜４、ＡＰＰサーバ１２０−１〜３およびＤＢサーバ１３０のそれぞれの稼動状態を示す状態テーブルを格納するために設けられている。要求送信部４１０は、ディスパッチャ装置（たとえばディスパッチャ装置１００−１）の記憶装置３００から処理要求の転送を受けたことに応じて、要求された処理の一部をＡＰＰサーバ１２０−１〜３またはＤＢサーバ１３０（以降、ＡＰＰサーバ１２０−１等と呼ぶ）に処理させるために、ＡＰＰサーバ１２０−１等に処理要求を送信する。状態返信部４２０は、要求送信部４１０がＡＰＰサーバ１２０−１等に送信した処理要求に対する処理応答の状態を、そのＡＰＰサーバ１２０−１の稼動状態として、ディスパッチャ装置１００−１の記憶装置３００から転送を受けた処理要求に対する処理応答に含めてそのディスパッチャ装置１００−１に返信する。

ここで、処理応答の状態とは、例えば、処理要求の送信から処理応答の受信までの所要時間をいう。つまり、処理の一例として、要求送信部４１０は、処理要求をＡＰＰサーバ１２０−１に送信したときにタイマーをリセットして、その処理要求に対する処理応答を受信したときにそのタイマーの値を参照して、処理の所要時間を計測する。そしてその所要時間が、その処理応答の状態となる。

第２テーブル更新部４３０は、ディスパッチャ装置（たとえばディスパッチャ装置１００−１）のテーブル送信部３３０から状態テーブルを受信したことに応じて、受信したその状態テーブルに基づき、記憶装置４００に既に格納された状態テーブルを更新する。第２テーブル更新部４３０は、記憶装置４００に何ら格納されていない場合には、受信したその状態テーブルを記憶装置４００に格納してもよい。テーブル返信部４４０は、状態テーブルの更新に応じて、更新したその状態テーブルをそれぞれのディスパッチャ装置に返信する。返信先は、第２テーブル更新部４３０に対する状態テーブルの送信元には限らず、サーブレットサーバ１１０−１に直接接続する全てのディスパッチャ装置１００のそれぞれである。また、返信する状態テーブルは、サーブレットサーバ１１０−１〜４からディスパッチャ装置１００−１〜２に対する処理応答のメッセージに含めて送信されてもよい。

以上、図３および図４を参照して説明したように、情報システム１０においては、ディスパッチャ装置１００およびサーブレットサーバ１１０が状態テーブルを相互に送信してその内容を反映し合う。これにより、ディスパッチャ装置１００−１〜２およびサーブレットサーバ１１０−１〜４の間で各サーバ・装置の稼動状態を適切に共有させることができる。それぞれのサーバ・装置は受信した複数の状態テーブルに基づいて、既に記憶している状態テーブルを更新することで、正常状態だがある処理にのみ偶然に処理時間を要したような場合でも、状態を誤って判断することを防ぐことができる。

図５は、記憶装置３００または記憶装置４００が記憶する状態テーブルのデータ構造の一例を示す。記憶装置３００および記憶装置４００のそれぞれは、状態テーブルとして、サーバＩＤに対応付けて、そのサーバＩＤにより識別されるサーバ・装置の稼動状態を記憶している。また、記憶装置３００および記憶装置４００のそれぞれは、状態テーブルに対応付けて、その状態テーブルの改訂の時期を示すバージョンＩＤを更に記憶する。なお、記憶装置３００および記憶装置４００は、それぞれディスパッチャ装置１００およびサーブレットサーバ１１０において独立して管理される。

具体例として、記憶装置３００は、サーブレットサーバ１１０−１というサーバＩＤに、そのサーバの稼動状態として正常状態を対応付けて記憶する。一方、記憶装置３００は、ＡＰＰサーバ１２０−１というサーバＩＤに、そのサーバの稼動状態として疑高負荷状態を対応付けて記憶する。また、記憶装置３００は、ＤＢサーバ１３０というサーバＩＤに、そのサーバの稼動状態として正常状態を対応付けて記憶する。バージョンＩＤは、改訂の時期や順序を識別可能とするものであり、これによって状態テーブル更新の可否を判断することができる。具体的には以下の通りである。

記憶装置３００におけるバージョンＩＤに関する処理として、テーブル生成部３２０は、新たに状態テーブルを生成する毎に、その状態テーブルに対応付けて、前回に生成した状態テーブルよりも後の改訂により生成されたことを示すバージョンＩＤを生成して記憶装置３００に記憶する。例えばバージョンＩＤが整数値として管理される場合、テーブル生成部３２０は、新たに状態テーブルを生成する毎に、既に記憶しているバージョンＩＤをインクリメントして記憶装置３００に記憶する。状態テーブルを生成する周期は、例えば数分おきや数秒おきなど、ディスパッチャ装置１００−１〜２に共通に定められている。したがって、生成される状態テーブルのＩＤは概ね同期しているが、ディスパッチャ装置１００−１〜２の間で同期を維持するための処理を行ってはいないので、完全に同期しているとは限らない。

また、テーブル送信部３３０は、テーブル生成部３２０により生成されて記憶装置３００に記憶された状態テーブルを、バージョンＩＤに対応付けて記憶装置３００から読み出して、それぞれのサーブレットサーバ１１０−１〜４に送信する。記憶装置４００におけるバージョンＩＤに関する処理として、第２テーブル更新部４３０は、状態テーブルに対応付けて受信したバージョンＩＤが、記憶装置４００に格納されたバージョンＩＤと比較して同時期又は後の時期の改定を示すことを条件に、受信したその状態テーブルに基づき、記憶装置４００に格納された状態テーブルを更新する。そしてその場合は、第２テーブル更新部４３０は、受信したそのバージョンＩＤを更新後の状態テーブルに対応付けて記憶装置４００に格納する。

また、テーブル返信部４４０は、状態テーブルの更新に応じて、更新したその状態テーブルを、更新に用いた状態テーブルに対応するバージョンＩＤに対応付けてそれぞれのディスパッチャ装置１００に返信する。この返信を受けて第１テーブル更新部３４０は、状態テーブルに対応付けて受信したバージョンＩＤが、記憶装置３００に記憶したバージョンＩＤと比較して同時期又は後の時期の改定を示すことを条件に、受信したこの状態テーブルにより、記憶装置３００に記憶した状態テーブルを更新する。
以上のように、状態テーブルがバージョンＩＤに対応付けて管理されることで、通信トラフィックの集中などで一部の状態テーブルが遅延して到着した場合であっても、最新の状態テーブルのみを選択して参照できる。

図６は、ディスパッチャ装置１００−１が処理要求および処理応答を送受信する処理の具体例を示す。ディスパッチャ装置１００−１は、例えば定期的に、又は、何らかの要求・応答を受信する毎に、以下の処理を行う。ディスパッチャ装置１００−１は、外部の端末装置から処理要求を受信すると（Ｓ６００：ＹＥＳ）、その処理要求を、複数のサーブレットサーバ１１０−１〜４の中から選択した一のサーブレットサーバ１１０に転送する（Ｓ６１０）。転送部３１０は、転送した処理要求に対する処理応答を受信すると（Ｓ６２０：ＹＥＳ）、その処理応答を外部の端末装置に対し返信する（Ｓ６３０）。

次に、テーブル生成部３２０は、この処理応答のメッセージに基づいて状態テーブルを生成する（Ｓ６４０）。具体的には、テーブル生成部３２０は、この処理応答のメッセージの中から、それぞれのＡＰＰサーバ１２０−１〜３およびＤＢサーバ１３０の稼動状態を取得し、取得したこの稼動状態に基づいて、ＡＰＰサーバ１２０−１〜３およびＤＢサーバ１３０についてのサーバ・装置毎の稼動状態を評価する。また、テーブル生成部３２０は、処理要求を転送してからこの処理応答を受信するまでの所要時間に基づいて、サーブレットサーバ１１０−１〜４の稼動状態を評価する。評価された稼動状態は状態テーブルに含めて生成される。新たに生成した状態テーブルは、既に記憶装置３００に記憶している状態テーブルに代えて記憶装置３００に記憶される。また、バージョンＩＤはインクリメントされる。また、稼動状態の評価は、過去の予め定められた期間内に受信した複数の処理応答に含まれる稼動状態に基づくものであり、同一のサーバ・装置について複数の稼動状態に基づき評価が行われてもよい。詳しくは後述する。なお、テーブル生成部３２０は、新たに生成した状態テーブルと、すでに記憶している状態テーブルを比較して同一である場合には、新たに生成した状態テーブルにより記憶装置３００を更新しなくてよい。この場合は、後に説明するテーブル送信部３３０は、Ｓ６６０において状態テーブルを送信しなくてよい。

次に、停止判断部３５０は、状態テーブルの送受信を停止するべき条件が成立したかどうかを判断する（Ｓ６５０）。停止するべき条件とは、たとえば、サーブレットサーバ１１０−１〜４の何れの稼動状態も正常状態でないことである。このような場合には、ディスパッチャ装置１００−１〜２およびサーブレットサーバ１１０−１〜４間で状態テーブルの相互送信が円滑に行えなくなるからである。停止条件が成立していなければ（Ｓ６５０：ＮＯ）、テーブル送信部３３０は、生成された状態テーブルを記憶装置３００から読み出して、それぞれのサーブレットサーバ１１０に対し送信する（Ｓ６６０）。停止条件が成立していれば（Ｓ６５０：ＹＥＳ）、テーブル送信部３３０は、状態テーブルを送信しないで次の処理に移る。

なお、停止判断部３５０は、停止条件が成立した場合であっても、成立から予め定められた期間が経過したことを条件に、テーブル生成部３２０により稼動状態の受信、および、テーブル送信部３３０による状態テーブルの送信を再開させてもよい。再開しても直ちに停止条件が成立した場合には、停止判断部３５０は、稼動状態の受信および状態テーブルの送信を停止して、上記予め定められた期間よりも長い期間待機する。そして、その期間経過後に停止判断部３５０は、稼動状態の受信および状態テーブルの送信を再開する。このように、障害の回復が遅れるのに従って待機時間を長くすることで、障害発生時の情報システム１０の負荷をできるだけ軽減して、障害からの回復を促すことができる。

また、第１テーブル更新部３４０は、サーブレットサーバ１１０−１〜４から新しい状態テーブルを受信したかどうかを判断する（Ｓ６７０）。即ち、第１テーブル更新部３４０は、何れかのサーブレットサーバ１１０−１〜４からの状態テーブルの受信に応じて、この状態テーブルに対応付けて受信したバージョンＩＤが、既に記憶装置３００に記憶しているバージョンＩＤと比較して同時期又は後の時期の改訂を示すかどうかを判断する。同時期又は後の時期の改訂を示すということは、例えば、受信したバージョンＩＤの番号が、既に記憶しているバージョンＩＤの番号と同じか、それよりも大きいということである。新しい状態テーブルを受信したことを条件に（Ｓ６７０：ＹＥＳ）、第１テーブル更新部３４０は、受信したその状態テーブルにより、記憶装置３００に記憶した状態テーブルを更新する（Ｓ６８０）。

なお、新たな状態テーブルを生成する処理をしている間に、サーブレットサーバ１１０から状態テーブルを受信した場合には、テーブル送信部３３０が新たに生成した状態テーブルを送信してから、第１テーブル更新部３４０が状態テーブルの更新を試みることが望ましい。このように、処理の所要時間等に基づく稼動状態の評価を優先させることで、稼動状態の評価に用いる所要時間等の情報を情報システム１０全体で増加させることができ、ゆえに、稼動状態の評価の精度を高めることができる。

図７は、Ｓ６４０における処理の詳細な例を示す。図７を参照して、転送部３１０が受信した処理応答のメッセージに基づいてテーブル生成部３２０が各装置・サーバの稼動状態を評価する処理の詳細を説明する。テーブル生成部３２０は、転送部３１０がサーブレットサーバ１１０−１〜４から過去の予め定められた時間内に受信した複数の処理応答に含めて、各サーバ・装置の稼動状態を受信して、受信した稼動状態を集計する（Ｓ７００）。具体的処理の一例を以下に述べる。

まず、テーブル生成部３２０は、各処理応答について以下の処理を行う。テーブル生成部３２０は、その処理応答の受信までの、対応する処理要求の送信からの所要時間を算出する。これは、テーブル生成部３２０において処理要求の送信時にタイマーをリセットして、処理応答の受信時にそのタイマーを参照することによって実現される。この時間を時間Ａとする。また、テーブル生成部３２０は、この処理応答のメッセージから、この処理要求に応じてサーブレットサーバ１１０がＡＰＰサーバ１２０に要求した処理の所要時間を取得する。この時間を時間Ｂとする。そして、テーブル生成部３２０は、時間Ａから時間Ｂを差し引くことで、サーブレットサーバ１１０における処理の所要時間を算出する。

この処理要求に伴ってＡＰＰサーバ１２０がＤＢサーバ１３０に対し更に処理を要求していた場合には、テーブル生成部３２０は、その所要時間をメッセージから更に取得する。この時間を時間Ｃとする。その場合には、テーブル生成部３２０は、サーブレットサーバ１１０において計測された所要時間Ｂから、この時間Ｃを差し引くことで、ＡＰＰサーバ１２０における処理の所要時間を算出する。このように、テーブル生成部３２０は、ある１つの処理要求から派生的に順次要求された複数の処理のそれぞれについて、その所要時間を算出する。所要時間は、前述の５秒および２秒を閾値として、稼動状態の情報に変換される。以上の処理を、テーブル生成部３２０は、上述の過去の予め定められた時間内に受信したそれぞれの処理応答について行う。そして、テーブル生成部３２０は、このようにして判断された稼動状態を、サーブレットサーバ１１０−１〜４、ＡＰＰサーバ１２０−１〜３およびＤＢサーバ１３０のそれぞれについて集計する。

次に、テーブル生成部３２０は、それぞれのサーブレットサーバ１１０−１〜４について、当該サーブレットサーバ１１０について集計された稼動状態の何れもが、高負荷状態または異常状態を示すかどうかを判断する（Ｓ７１０）。何れのサーブレットサーバ１１０についても、集計された稼動状態の何れもが高負荷状態又は異常状態を示していることを条件に（Ｓ７１０：ＹＥＳ）、停止判断部３５０は、状態テーブルの送受信を停止するべき条件が成立したと判断して（Ｓ７２０）、本図の処理を終了する。この場合、テーブル生成部３２０は、状態テーブルを生成しなくてもよい。

次に、テーブル生成部３２０は、ＡＰＰサーバ１２０−１〜３およびＤＢサーバ１３０のそれぞれ（以下、処理の対象を当該サーバと呼ぶ）について以下の処理を行う（Ｓ７３０）。テーブル生成部３２０は、当該サーバについて受信した稼動状態のうち、当該サーバが正常であることを示す稼動状態の割合が予め定められた基準値（Ｎ）であることを条件に（Ｓ７４０：ＹＥＳ）、当該サーバが正常状態であると評価する（Ｓ７５０）。この基準値（Ｎ）は、０より大きい極めて小さい値であることが望ましい。これは、サーバに一旦異常が発生すると以降の処理は更に遅延する傾向があり、一時的にであっても状況が改善することは稀だからである。すなわち、正常と判断できる処理が僅かに観測されるときは、異常状態においてたまたま正常に処理が完了されたとは考えにくく、正常状態においてたまたま他の処理に時間がかかっていると考えた方が自然だからである。このため、テーブル生成部３２０は、正常状態を示す稼動状態が１つでも含まれていれば、当該サーバが正常状態であると評価してよい。

正常状態と評価されない場合（Ｓ７４０）、次に、テーブル生成部３２０は、当該サーバについて受信した稼動状態のうち、当該サーバが高負荷であることを示す稼動状態の割合が予め定められた基準値（Ｋ）以上であるかどうかを判断する（Ｓ７６０）。基準値（Ｋ）以上であることを条件に（Ｓ７６０：ＹＥＳ）、テーブル生成部３２０は、当該サーバが高負荷状態であると評価する（Ｓ７７０）。この基準値（Ｋ）も、０より大きい極めて小さい値であることが望ましく、テーブル生成部３２０は、高負荷状態を示す稼動状態が１つでも含まれていれば、他の稼動状態が全て異常状態を示していても、当該サーバが高負荷状態であると判断してよい。高負荷であることを示す稼動状態の割合が基準値（Ｋ）未満であることを条件に（Ｓ７６０：ＮＯ）、テーブル生成部３２０は、当該サーバが疑異常状態と判断する（Ｓ７８０）。テーブル生成部３２０は、以上の処理をＡＰＰサーバ１２０−１〜３およびＤＢサーバ１３０のそれぞれについて繰り返す（Ｓ７９０）。

図８は、サーブレットサーバ１１０−１が処理要求および処理応答を送受信する処理の具体例を示す。要求送信部４１０は、ディスパッチャ装置（たとえばディスパッチャ装置１００−１）の記憶装置３００から処理要求の転送を受けたことに応じて（Ｓ８００：ＹＥＳ）、要求された処理の一部をＡＰＰサーバ１２０−１〜３等に処理させるために、ＡＰＰサーバ１２０−１等に処理要求を送信する（Ｓ８１０）。送信先をたとえばＡＰＰサーバ１２０−１とする。要求送信部４１０がＡＰＰサーバ１２０−１に送信した処理要求に対する処理応答を受信すると（Ｓ８２０：ＹＥＳ）、状態返信部４２０は、その処理応答の状態を、そのＡＰＰサーバ１２０−１の稼動状態として取得する（Ｓ８３０）。例えば、処理要求から処理応答までの所要時間がＡＰＰサーバ１２０−１から取得されてもよい。そして、状態返信部４２０は、ＡＰＰサーバ１２０−１の稼動状態を、ディスパッチャ装置１００−１の記憶装置３００から転送を受けた処理要求に対する処理応答に含めてそのディスパッチャ装置１００−１に返信する（Ｓ８４０）。

次に、第２テーブル更新部４３０は、ディスパッチャ装置（たとえばディスパッチャ装置１００−１）から新しい状態テーブルを受信したかどうかを判断する（Ｓ８５０）。即ち、第２テーブル更新部４３０は、ディスパッチャ装置１００−１から状態テーブルを受信したことに応じて、その状態テーブルに対応付けて受信したバージョンＩＤが、記憶装置４００に既に格納されたバージョンＩＤと比較して同時期又は後の時期の改定を示すことを条件に、新しい状態テーブルを受信したと判断する。新しい状態テーブルを受信したことを条件に（Ｓ８５０：ＹＥＳ）、第２テーブル更新部４３０は、受信したその状態テーブルに基づき、記憶装置４００に格納された状態テーブルを更新する（Ｓ８６０）。状態テーブルの更新は、このように、状態テーブルを受信する毎に行われるから、ディスパッチャ装置１００−１〜２の各々から受信した状態テーブルの情報は統合されて記憶装置４００の状態テーブルに反映される。そして、テーブル返信部４４０は、更新したその状態テーブルをディスパッチャ装置１００−１〜２のそれぞれに対し返信する（Ｓ８７０）。

図９は、Ｓ８６０において順次更新される稼動状態の状態遷移図である。第２テーブル更新部４３０は、状態テーブルにおいて管理されたＡＰＰサーバ１２０−１〜３およびＤＢサーバ１３０の各稼動状態を、図９に示す状態遷移図に従って更新する。具体的には、第２テーブル更新部４３０は、処理対象であるサーバの稼動状態が、既に記憶装置４００に記憶されている状態テーブルにおいて正常状態ではなく、かつ、ディスパッチャ装置１００のテーブル送信部３３０から受信した状態テーブルにおいては正常状態であることを条件に、当該サーバの稼動状態を正常状態に更新する。即ち、高負荷、異常、疑高負荷または疑異常の何れの状態も、正常状態を受信したことを条件に正常状態に更新される。

また、第２テーブル更新部４３０は、処理対象であるサーバの稼動状態が、すでに記憶装置４００に記憶されている状態テーブルにおいて正常状態であり、かつ、サーブレットサーバ１１０のテーブル送信部３３０から受信した状態テーブルにおいては異常状態または疑異常状態であることを条件に、当該サーバの稼動状態を疑異常状態に更新する。即ち、第２テーブル更新部４３０においては、異常状態を受信したからといって直ちに異常状態とは判断されない。そして、第２テーブル更新部４３０は、稼動状態を疑異常状態に更新してから正常状態に戻すことなく予め定められた期間が経過したことを条件に、当該稼動状態を異常状態に更新する。

また、第２テーブル更新部４３０は、処理対象であるサーバの稼動状態が、すでに記憶装置４００に記憶されている状態テーブルにおいて正常状態であり、かつ、サーブレットサーバ１１０のテーブル送信部３３０から受信した状態テーブルにおいては高負荷状態であることを条件に、当該サーバの稼動状態を疑高負荷状態に更新する。即ち、第２テーブル更新部４３０においては、高負荷状態を受信したからといって直ちに高負荷状態とは判断されない。そして、第２テーブル更新部４３０は、稼動状態を疑高負荷状態に更新してから正常状態に戻すことなく予め定められた期間が経過したことを条件に、当該稼動状態を高負荷状態に更新する。

図１０は、本実施形態に係る情報システム１０により稼動状態が順次更新される過程を示す。ここでは説明の都合上、情報システム１０は、ディスパッチャ装置１００−１〜２と、サーブレットサーバ１１０−１と、ＡＰＰサーバ１２０−１〜３とを有するものとし、サーブレットサーバ１１０−２およびＤＢサーバ１３０は有しないものとする。また、ＡＰＰサーバ１２０−１〜３を、表の中でそれぞれＡ〜Ｃと表記する。また、バージョンＩＤの初期値を０とする。即ち、全てのサーバ・装置における記憶装置は、バージョンＩＤとして数値の０を記憶している。また、状態テーブルは、ＡＰＰサーバ１２０−１〜３の稼動状態を含み、サーブレットサーバ１１０−１〜２の稼動状態を含まないものとする。

初期状態である時間０の時点において、ディスパッチャ装置１００−１の記憶装置３００は、ＡＰＰサーバ１２０−１〜３のそれぞれの稼動状態を何れも正常状態とする状態テーブルを記憶している。この状態テーブルをＡ，Ｂ，Ｃと表記する。ディスパッチャ装置１００−２の記憶装置３００およびサーブレットサーバ１１０−１の記憶装置４００も同様である。時間０の次の時間１において、テーブル生成部３２０は、ＡＰＰサーバ１２０−３の稼動状態を疑異常状態と判断する。これは、例えばある一定期間内にディスパッチャ装置１００−１からの要求を受けてＡＰＰサーバ１２０−１で実行された処理の何れもが、異常状態と判断されるべき所要時間を要したからである。このときの状態テーブルの状態をＡ，Ｂ，Ｃ（−）と表記する。記号−は異常状態を示し、記号（−）は疑異常状態を示す。この時点でディスパッチャ装置１００−１の記憶装置３００においてバージョンＩＤはインクリメントされて１となる。しかしまだサーブレットサーバ１１０−１においてバージョンＩＤが０のままなので、図中ではバージョンＩＤを０と表記する。

時間２において、サーブレットサーバ１１０−１の第２テーブル更新部４３０は、ディスパッチャ装置１００−１のテーブル送信部３３０から状態テーブルを受信する。記憶装置３００に既に記憶されている状態テーブルにおいて、ＡＰＰサーバ１２０−３は正常状態だが、受信した状態テーブルにおいてＡＰＰサーバ１２０−３は疑異常状態である。このため、サーブレットサーバ１１０−１の第２テーブル更新部４３０は、稼動状態を疑異常状態に更新する。したがって、サーブレットサーバ１１０−１においても状態テーブルはＡ，Ｂ，Ｃ（−）となる。

また、同じ時間２において、ディスパッチャ装置１００−２のテーブル生成部３２０は、ディスパッチャ装置１００−１と比べてやや遅れて、ディスパッチャ装置１００−１とは独立に状態テーブルを生成する。このとき、テーブル生成部３２０は、ＡＰＰサーバ１２０−２の稼動状態を疑異常状態と判断する。これは、例えばある一定期間内にディスパッチャ装置１００−２からの要求を受けてＡＰＰサーバ１２０−２で実行された処理の何れもが、異常状態と判断されるべき所要時間を要したからである。この結果生成される状態テーブルは、Ａ，Ｂ（−），Ｃである。この時点で、ディスパッチャ装置１００−１〜２およびサーブレットサーバ１１０−１の全てでバージョンＩＤが１となる。

時間３において、サーブレットサーバ１１０−１のテーブル返信部４４０は、状態テーブルをディスパッチャ装置１００−１およびディスパッチャ装置１００−２に対し送信する。ディスパッチャ装置１００−１において、記憶している状態テーブルと受信した状態テーブルは同一であるから何らの処理は行われない。ディスパッチャ装置１００−２において、記憶している状態テーブルおよび受信した状態テーブルはバージョンＩＤが共に１であって同一なので、第１テーブル更新部３４０は、受信した状態テーブルにより、記憶している状態テーブルを更新する。例えば、記憶している状態テーブルは、受信した状態テーブルにより置換される。この結果、ディスパッチャ装置１００−２の記憶装置３００において、状態テーブルはＡ，Ｂ，Ｃ（−）となる。

時間４において、ディスパッチャ装置１００−２のテーブル生成部３２０は、ＡＰＰサーバ１２０−２の稼動状態を疑異常状態と再度判断する。これは、次の一定期間内においても、ディスパッチャ装置１００−２からの要求を受けてＡＰＰサーバ１２０−２で実行された処理の何れもが、異常状態と判断されるべき所要時間を要したからである。この結果生成される状態テーブルは、Ａ，Ｂ（−），Ｃである。また、生成されるバージョンＩＤは２である。そして、次の時間５において、ディスパッチャ装置１００−２のテーブル送信部３３０は、生成したこの状態テーブルをサーブレットサーバ１１０−１に送信する。

サーブレットサーバ１１０−１の第２テーブル更新部４３０は、受信したバージョンＩＤである２が、記憶しているバージョンＩＤである１より大きいので、受信したこの状態テーブルにより、記憶している状態テーブルを更新する。ＡＰＰサーバ１２０−２について、記憶している稼動状態は正常状態であり、受信した稼動状態は疑異常状態なので、第２テーブル更新部４３０は、ＡＰＰサーバ１２０−２の稼動状態を疑異常状態に更新する。ＡＰＰサーバ１２０−３について、記憶している稼動状態は疑異常状態であり、受信した稼動状態は正常状態なので、第２テーブル更新部４３０は、ＡＰＰサーバ１２０−３の稼動状態を正常状態に更新する。この結果、状態テーブルはＡ，Ｂ（−），Ｃとなる。

次の時間６において、サーブレットサーバ１１０−１のテーブル返信部４４０は、更新した状態テーブルをディスパッチャ装置１００−１〜２のそれぞれに返信する。ディスパッチャ装置１００−２において、既に記憶している状態テーブルおよび受信した状態テーブルは同じなので、第１テーブル更新部３４０は何ら処理を行わない。一方、サーブレットサーバ１１０−１は、記憶しているものとは異なる状態テーブルＡ，Ｂ（−），Ｃを受信し、かつ、バージョンＩＤも同時期の改定を示すことから、受信したこの状態テーブルにより、記憶している状態テーブルを置換する。この結果、状態テーブルはＡ，Ｂ（−），Ｃとなる。

次の時間７および８において、ディスパッチャ装置１００−１〜２のテーブル生成部３２０は、ＡＰＰサーバ１２０−１〜３の稼動状態を評価するが、評価前と同一状態であるから図１０中の表記は変化しない。同様に、サーブレットサーバ１１０−１の第２テーブル更新部４３０は状態テーブルをディスパッチャ装置１００−１〜２から受信するが、既に記憶している状態テーブルと同一であるから図１０中の表記は変化しない。

時間９において、サーブレットサーバ１１０−１の第２テーブル更新部４３０は、ＡＰＰサーバ１２０−２の稼動状態を疑異常状態に更新してから予め定められた時間が経過したので、ＡＰＰサーバ１２０−２の稼動状態を異常状態に更新する。更新された稼動状態は状態テーブルに含めてディスパッチャ装置１００−１〜２に返信される。この結果、状態テーブルはＡ，Ｂ−，Ｃとなる。時間１０において、ディスパッチャ装置１００−１〜２の第１テーブル更新部３４０は、受信した状態テーブルによって、既に記憶している状態テーブルを更新する。この結果、状態テーブルはＡ，Ｂ−，Ｃとなる。

図１１は、ディスパッチャ装置１００−１またはサーブレットサーバ１１０−１として機能する情報処理装置５００のハードウェア構成の一例を示す。情報処理装置５００は、ホストコントローラ１０８２により相互に接続されるＣＰＵ１０００、ＲＡＭ１０２０、及びグラフィックコントローラ１０７５を有するＣＰＵ周辺部と、入出力コントローラ１０８４によりホストコントローラ１０８２に接続される通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を有する入出力部と、入出力コントローラ１０８４に接続されるＲＯＭ１０１０、フレキシブルディスクドライブ１０５０、及び入出力チップ１０７０を有するレガシー入出力部とを備える。

ホストコントローラ１０８２は、ＲＡＭ１０２０と、高い転送レートでＲＡＭ１０２０をアクセスするＣＰＵ１０００及びグラフィックコントローラ１０７５とを接続する。ＣＰＵ１０００は、ＲＯＭ１０１０及びＲＡＭ１０２０に格納されたプログラムに基づいて動作し、各部の制御を行う。グラフィックコントローラ１０７５は、ＣＰＵ１０００等がＲＡＭ１０２０内に設けたフレームバッファ上に生成する画像データを取得し、表示装置１０８０上に表示させる。これに代えて、グラフィックコントローラ１０７５は、ＣＰＵ１０００等が生成する画像データを格納するフレームバッファを、内部に含んでもよい。

入出力コントローラ１０８４は、ホストコントローラ１０８２と、比較的高速な入出力装置である通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を接続する。通信インターフェイス１０３０は、ネットワークを介して外部の装置と通信する。ハードディスクドライブ１０４０は、情報処理装置５００が使用するプログラム及びデータを格納する。ＣＤ−ＲＯＭドライブ１０６０は、ＣＤ−ＲＯＭ１０９５からプログラム又はデータを読み取り、ＲＡＭ１０２０又はハードディスクドライブ１０４０に提供する。

また、入出力コントローラ１０８４には、ＲＯＭ１０１０と、フレキシブルディスクドライブ１０５０や入出力チップ１０７０等の比較的低速な入出力装置とが接続される。ＲＯＭ１０１０は、情報処理装置５００の起動時にＣＰＵ１０００が実行するブートプログラムや、情報処理装置５００のハードウェアに依存するプログラム等を格納する。フレキシブルディスクドライブ１０５０は、フレキシブルディスク１０９０からプログラム又はデータを読み取り、入出力チップ１０７０を介してＲＡＭ１０２０またはハードディスクドライブ１０４０に提供する。入出力チップ１０７０は、フレキシブルディスク１０９０や、例えばパラレルポート、シリアルポート、キーボードポート、マウスポート等を介して各種の入出力装置を接続する。

情報処理装置５００に提供されるプログラムは、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５、又はＩＣカード等の記録媒体に格納されて利用者によって提供される。プログラムは、入出力チップ１０７０及び/又は入出力コントローラ１０８４を介して
、記録媒体から読み出され情報処理装置５００にインストールされて実行される。プログラムが情報処理装置５００等に働きかけて行わせる動作は、図１から図１０において説明したディスパッチャ装置１００−１およびサーブレットサーバ１１０−１における動作と同一であるから、説明を省略する。なお、ディスパッチャ装置１００−２およびサーブレットサーバ１１０−２〜４の動作・ハードウェア構成についても、図１１に示す情報処理装置５００と略同一であるから説明を省略する。

以上に示したプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としては、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５の他に、ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、テープ媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、専用通信ネットワークやインターネットに接続されたサーバシステムに設けたハードディスク又はＲＡＭ等の記憶装置を記録媒体として使用し、ネットワークを介してプログラムを情報処理装置５００に提供してもよい。

以上、本実施形態に係る情報システム１０によれば、処理要求・処理応答などのメッセージに含めて稼動状態を送受信させることができるので、本来必要な装置・サーバの他に追加の装置を必要とせず、なおかつ、ソフトウェア由来の障害を含めた幅広い種類の障害を検出することができる。また、あるサーバＡが他のサーバＢに処理を要求し、サーバＢがサーバＣに更に処理を要求するというように、呼び出し関係が階層的な場合においても障害発生箇所を精度良く判断できる。さらに、ディスパッチャ装置１００およびサーブレットサーバ１１０間で稼動状態の評価結果を交換することで、誤った評価や一時的な評価の誤りを訂正できる。たとえば、Ｊａｖａ（登録商標）のＧＣなどによって一時的に遅延した処理を障害として誤って判断することを避け、稼動状態評価の精度を高めることができる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

図１は、情報システム１０の構成の一例を示す。 図２は、本実施形態に係る情報システム１０の全体構成を示す。 図３は、ディスパッチャ装置１００−１の機能構成を示す。 図４は、サーブレットサーバ１１０−１の機能構成を示す。 図５は、記憶装置３００または記憶装置４００が記憶する状態テーブルのデータ構造の一例を示す。 図６は、ディスパッチャ装置１００−１が処理要求および処理応答を送受信する処理の具体例を示す。 図７は、Ｓ６４０における処理の詳細な例を示す。 図８は、サーブレットサーバ１１０−１が処理要求および処理応答を送受信する処理の具体例を示す。 図９は、Ｓ８６０において順次更新される稼動状態の状態遷移図である。 図１０は、本実施形態に係る情報システム１０により稼動状態が順次更新される過程を示す。 図１１は、ディスパッチャ装置１００−１またはサーブレットサーバ１１０−１として機能する情報処理装置５００のハードウェア構成の一例を示す。

符号の説明

１０ 情報システム
１００ ディスパッチャ装置
１１０ サーブレットサーバ
１２０ ＡＰＰサーバ
１３０ ＤＢサーバ
１３５ データベース
１４０ システム監視装置
１５０ 情報共有装置
３００ 記憶装置
３１０ 転送部
３２０ テーブル生成部
３３０ テーブル送信部
３４０ 第１テーブル更新部
３５０ 停止判断部
４００ 記憶装置
４１０ 要求送信部
４２０ 状態返信部
４３０ 第２テーブル更新部
４４０ テーブル返信部
５００ 情報処理装置

Claims (11)

1. 外部の端末装置から要求された処理を振り分ける複数のディスパッチャ装置と、振り分けられた当該処理を行う複数の第１階層サーバと、第１階層サーバから受けた要求に応じて当該処理の一部を行う少なくとも１つの第２階層サーバとを備えるシステムであって、 それぞれの前記ディスパッチャ装置は、
   それぞれの第２階層サーバの稼動状態を示す状態テーブルを格納するための記憶装置と、
   要求された処理を振り分けるために、外部の端末装置から受けた処理要求を前記複数の第１階層サーバの中から選択した一の第１階層サーバに転送する転送部と、
   それぞれの前記第２階層サーバの稼動状態を、転送された前記処理要求に対応する処理応答に含めて受信し、受信した稼動状態に基づいて第２階層サーバ毎の稼動状態を評価して、第２階層サーバ毎の稼動状態を示す状態テーブルを生成して記憶装置に記憶するテーブル生成部と、
   前記状態テーブルの生成に応じ、生成した前記状態テーブルを記憶装置から読み出してそれぞれの前記第１階層サーバに送信するテーブル送信部と、
   何れかの第１階層サーバからの状態テーブルの受信に応じて、受信した前記状態テーブルにより記憶装置に記憶した前記状態テーブルを更新する第１テーブル更新部と
   を有し、
   それぞれの前記第１階層サーバは、
   それぞれの第２階層サーバの稼動状態を示す状態テーブルを格納するための記憶装置と、
   ディスパッチャ装置の転送部から処理要求の転送を受けたことに応じて、要求された処理の一部を第２階層サーバに処理させるために、第２階層サーバに処理要求を送信する要求送信部と、
   第２階層サーバに送信した前記処理要求に対する処理応答の状態を、当該第２階層サーバの稼動状態として、ディスパッチャ装置の転送部から転送を受けた処理要求に対する処理応答に含めて当該ディスパッチャ装置に返信する状態返信部と、
   ディスパッチャ装置のテーブル送信部から状態テーブルを受信したことに応じて、受信した当該状態テーブルに基づき記憶装置に既に格納された状態テーブルを更新する第２テーブル更新部と、
   状態テーブルの更新に応じて、更新した前記状態テーブルをそれぞれの前記ディスパッチャ装置に返信するテーブル返信部と
   を有するシステム。
2. ディスパッチャ装置および第１階層サーバのそれぞれにおける記憶装置は、状態テーブルに対応付けて当該状態テーブルの改訂の時期を示すバージョンＩＤを更に記憶し、
   前記テーブル生成部は、新たに状態テーブルを生成する毎に、当該状態テーブルに対応付けて、前回に生成した状態テーブルよりも後の改訂により生成されたことを示すバージョンＩＤを生成して記憶装置に記憶し、
   前記テーブル送信部は、生成した状態テーブルをバージョンＩＤに対応付けて記憶装置から読み出してそれぞれの前記第１階層サーバに送信し、
   前記第２テーブル更新部は、状態テーブルに対応付けて受信したバージョンＩＤが、記憶装置に格納されたバージョンＩＤと比較して同時期又は後の時期の改定を示すことを条件に、受信した当該状態テーブルに基づき記憶装置に格納された前記状態テーブルを更新し、さらに、受信した当該バージョンＩＤを更新後の当該状態テーブルに対応付けて記憶装置に格納し、
   前記テーブル返信部は、状態テーブルの更新に応じて、更新した当該状態テーブルを、更新に用いた状態テーブルに対応するバージョンＩＤに対応付けてそれぞれのディスパッチャ装置に返信し、
   前記第１テーブル更新部は、状態テーブルに対応付けて受信したバージョンＩＤが、記憶装置に記憶したバージョンＩＤと比較して同時期又は後の時期の改定を示すことを条件に、受信した当該状態テーブルにより記憶装置に記憶した前記状態テーブルを更新する
   請求項１に記載のシステム。
3. 前記状態返信部は、ディスパッチャ装置の転送部から転送を受けた処理要求に対する処理応答に、前記稼動状態として、当該処理要求に応じて第２階層サーバに要求した処理の所要時間を示す情報を含めて当該ディスパッチャ装置に返信し、
   前記テーブル生成部は、前記一の第１階層サーバから、当該一の第１階層サーバに対して転送した前記処理要求に応じた処理の所要時間を、前記稼動状態として、当該処理要求に対する処理応答に含めて受信する
   請求項１に記載のシステム。
4. 前記テーブル生成部は、さらに、それぞれの前記第１階層サーバに対し処理要求を送信してから当該処理要求に対する処理応答を受信するまでの所要時間に基づいて、第１階層サーバ毎の稼動状態を評価して、前記状態テーブルに含めて生成し、
   前記ディスパッチャ装置は、生成した前記状態テーブルにおいて、何れの前記第１階層サーバも、稼動状態が正常状態でないことを条件に、前記テーブル生成部による稼動状態の受信、および、前記テーブル送信部による状態テーブルの送信を停止させる停止判断部を更に有する
   請求項１に記載のシステム。
5. 第２階層サーバの稼動状態は、正常状態、動作しているが処理に閾値以上の時間を要する高負荷状態、および、動作していない異常状態の何れかであり、
   前記テーブル生成部は、同一の第２階層サーバについて複数の前記稼動状態を受信して、第２階層サーバ毎に、当該第２階層サーバについて受信した前記稼動状態のうち、当該第２階層サーバが正常であることを示す稼動状態の割合が予め定められた基準値以上であることを条件に、当該第２階層サーバが正常状態であると評価する
   請求項１に記載のシステム。
6. 前記テーブル生成部は、正常状態であると評価しなかった第２階層サーバのそれぞれについて、当該第２階層サーバについて受信した前記稼動状態のうち、当該第２サーバが高負荷であることを示す稼動状態の割合が予め定められた基準値以上であることを条件に、当該第２階層サーバが高負荷状態であると評価する
   請求項５に記載のシステム。
7. 第２階層サーバの稼動状態は、正常状態、動作しているが処理に閾値以上の時間を要する高負荷状態、動作していない異常状態、高負荷状態の疑いがある疑高負荷状態、および、異常状態の疑いがある疑異常状態の何れかであり、
   前記第２テーブル更新部は、第２階層サーバ毎に、当該第２階層サーバの稼動状態が、既に記憶装置に記憶されている状態テーブルにおいて正常状態ではなく、かつ、ディスパッチャ装置のテーブル送信部から受信した状態テーブルにおいては正常状態であることを条件に、当該第２階層サーバの稼動状態を正常状態に更新する
   請求項１に記載のシステム。
8. 前記第２テーブル更新部は、第２階層サーバ毎に、当該第２階層サーバの稼動状態が、既に記憶装置に記憶されている状態テーブルにおいて正常状態であり、かつ、ディスパッチャ装置のテーブル送信部から受信した状態テーブルにおいては異常状態または疑異常状態であることを条件に、当該第２階層サーバの稼動状態を疑異常状態に更新し、さらに、 稼動状態を疑異常状態に更新してから正常状態に戻すことなく予め定められた期間が経過したことを条件に、当該稼動状態を異常状態に更新する
   請求項７に記載のシステム。
9. 前記第２テーブル更新部は、第２階層サーバ毎に、当該第２階層サーバの稼動状態が、既に記憶装置に記憶されている状態テーブルにおいて正常状態であり、かつ、ディスパッチャ装置のテーブル送信部から受信した状態テーブルにおいては高負荷状態であることを条件に、当該第２階層サーバの稼動状態を疑高負荷状態に更新し、さらに、
   稼動状態を疑高負荷状態に更新してから正常状態に戻すことなく予め定められた期間が経過したことを条件に、当該稼動状態を高負荷状態に更新する
   請求項７に記載のシステム。
10. 外部の端末装置から要求された処理を振り分ける複数のディスパッチャ装置と、振り分けられた当該処理を行う複数の第１階層サーバと、第１階層サーバから受けた要求に応じて当該処理の一部を行う少なくとも１つの第２階層サーバとを備えるシステムにおいて、稼動状態を管理する方法であって、
    それぞれの前記ディスパッチャ装置は、
    それぞれの第２階層サーバの稼動状態を示す状態テーブルを格納するための記憶装置を有し、
    ディスパッチャ装置として機能するそれぞれのコンピュータにおいて、
    要求された処理を振り分けるために、外部の端末装置から受けた処理要求を前記複数の第１階層サーバの中から選択した一の第１階層サーバに対し転送部により転送することと、
    それぞれの前記第２階層サーバの稼動状態を、転送された前記処理要求に対応する処理応答に含めて受信し、受信した稼動状態に基づいて第２階層サーバ毎の稼動状態を評価して、第２階層サーバ毎の稼動状態を示す状態テーブルを生成してテーブル生成部により記憶装置に記憶することと、
    前記状態テーブルの生成に応じ、生成した前記状態テーブルを記憶装置から読み出してそれぞれの前記第１階層サーバに対しテーブル送信部により送信することと、
    何れかの第１階層サーバからの状態テーブルの受信に応じて、受信した前記状態テーブルにより記憶装置に記憶した前記状態テーブルを第１テーブル更新部により更新することと
    を有し、
    それぞれの第１階層サーバは、
    それぞれの第２階層サーバの稼動状態を示す状態テーブルを格納するための記憶装置を有し、
    第１階層サーバとして機能するそれぞれのコンピュータにおいて、
    ディスパッチャ装置の転送部から処理要求の転送を受けたことに応じて、要求された処理の一部を第２階層サーバに処理させるために、第２階層サーバに処理要求を要求送信部により送信することと、
    第２階層サーバに送信した前記処理要求に対する処理応答の状態を、当該第２階層サーバの稼動状態として、ディスパッチャ装置の転送部から転送を受けた処理要求に対する処理応答に含めて当該ディスパッチャ装置に状態返信部により返信することと、
    ディスパッチャ装置のテーブル送信部から状態テーブルを受信したことに応じて、受信した当該状態テーブルに基づき記憶装置に既に格納された状態テーブルを第２テーブル更新部により更新することと、
    状態テーブルの更新に応じて、更新した前記状態テーブルをそれぞれの前記ディスパッチャ装置に対しテーブル返信部により返信することと
    を有する方法。
11. 外部の端末装置から要求された処理を振り分ける複数のディスパッチャ装置と、振り分けられた当該処理を行う複数の第１階層サーバと、第１階層サーバから受けた要求に応じて当該処理の一部を行う少なくとも１つの第２階層サーバとを備えるシステムとして、複数の情報処理装置を機能させるプログラムであって、
    それぞれの情報処理装置を、
    それぞれの第２階層サーバの稼動状態を示す状態テーブルを格納するための記憶装置と、
    要求された処理を振り分けるために、外部の端末装置から受けた処理要求を前記複数の第１階層サーバの中から選択した一の第１階層サーバに転送する転送部と、
    それぞれの前記第２階層サーバの稼動状態を、転送された前記処理要求に対応する処理応答に含めて受信し、受信した稼動状態に基づいて第２階層サーバ毎の稼動状態を評価して、第２階層サーバ毎の稼動状態を示す状態テーブルを生成して記憶装置に記憶するテーブル生成部と、
    前記状態テーブルの生成に応じ、生成した前記状態テーブルを記憶装置から読み出してそれぞれの前記第１階層サーバに送信するテーブル送信部と、
    何れかの第１階層サーバからの状態テーブルの受信に応じて、受信した前記状態テーブルにより記憶装置に記憶した前記状態テーブルを更新する第１テーブル更新部と
    を有するディスパッチャ装置として機能させ、
    他のそれぞれの情報処理装置を、
    それぞれの第２階層サーバの稼動状態を示す状態テーブルを格納するための記憶装置と、
    ディスパッチャ装置の転送部から処理要求の転送を受けたことに応じて、要求された処理の一部を第２階層サーバに処理させるために、第２階層サーバに処理要求を送信する要求送信部と、
    第２階層サーバに送信した前記処理要求に対する処理応答の状態を、当該第２階層サーバの稼動状態として、ディスパッチャ装置の転送部から転送を受けた処理要求に対する処理応答に含めて当該ディスパッチャ装置に返信する状態返信部と、
    ディスパッチャ装置のテーブル送信部から状態テーブルを受信したことに応じて、受信した当該状態テーブルに基づき記憶装置に既に格納された状態テーブルを更新する第２テーブル更新部と、
    状態テーブルの更新に応じて、更新した前記状態テーブルをそれぞれの前記ディスパッチャ装置に返信するテーブル返信部と
    を有する第１階層サーバとして機能させるプログラム。

Images