(57)【特許請求の範囲】
【請求項１】
サーバ装置と複数のクライアント装置とを備え、
前記複数のクライアント装置の各々は、
前記サーバ装置の障害を監視する監視手段と、
前記複数のクライアント装置の各々から所定の装置への通知の経路を示す、前記複数のクライアント装置が配置されたツリーに従って、前記サーバ装置の障害が検出されたことを示す障害通知を、当該障害通知が重複しないように送信する通知手段と、
を含む情報処理システム。
【請求項２】
前記通知手段は、前記監視手段によって前記サーバ装置の障害が検出された場合、または、前記ツリーにおける子のクライアント装置から前記障害通知を受信した場合、前記障害通知を送信済みでなければ、前記ツリーにおいて親として指定された前記所定の装置またはクライアント装置に、前記障害通知を送信する、
請求項１に記載の情報処理システム。
【請求項３】
前記通知手段は、前記ツリーにおける親のクライアント装置の障害が検出された場合、前記ツリーにおける当該親のクライアント装置のさらに親として指定された前記所定の装置またはクライアント装置を、新たな親に設定する、
請求項２に記載の情報処理システム。
【請求項４】
前記サーバ装置は、前記クライアント装置からアクセスされたときに、当該クライアント装置を前記ツリーに追加する、ツリー管理手段を備える、
請求項１乃至３のいずれかに記載の情報処理システム。
【請求項５】
前記サーバ装置は、前記所定の装置が前記障害通知を受信した場合、当該サーバ装置におけるログを取得するログ取得手段を含む、
請求項１乃至４のいずれかに記載の情報処理システム。
【請求項６】
前記監視手段は、前記サーバ装置にリクエストを送信してからレスポンスを受信するまでの時間が所定の閾値を超えている場合に、前記サーバ装置に障害が発生していると判定する、
請求項１乃至５のいずれかに記載の情報処理システム。
【請求項７】
前記所定の装置は、前記サーバ装置である、
請求項１乃至６のいずれかに記載の情報処理システム。
【請求項８】
サーバ装置と複数の情報処理装置を含む情報処理システムにおける情報処理装置であって、
前記サーバ装置の障害を監視する監視手段と、
前記複数の情報処理装置の各々から所定の装置への通知の経路を示す、前記複数の情報処理装置が配置されたツリーに従って、前記サーバ装置の障害が検出されたことを示す障害通知を、当該障害通知が重複しないように送信する通知手段と、
を備えた、情報処理装置。
【請求項９】
サーバ装置と複数のクライアント装置を含む情報処理システムにおける情報処理方法であって、
前記複数のクライアント装置の各々において、
前記サーバ装置の障害を監視し、
前記複数のクライアント装置の各々から所定の装置への通知の経路を示す、前記複数のクライアント装置が配置されたツリーに従って、前記サーバ装置の障害が検出されたことを示す障害通知を、当該障害通知が重複しないように送信する、
情報処理方法。
【請求項１０】
サーバ装置と複数のクライアント装置を含む情報処理システムにおけるクライアント装置のプログラムであって、
コンピュータに、
前記サーバ装置の障害を監視する処理と、
前記複数のクライアント装置の各々から所定の装置への通知の経路を示す、前記複数のクライアント装置が配置されたツリーに従って、前記サーバ装置の障害が検出されたことを示す障害通知を、当該障害通知が重複しないように送信する通知処理と、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、情報処理装置、情報処理方法、及び、プログラムに関する。
【背景技術】
【０００２】
サーバ装置がクライアント装置に対してＷｅｂサービスを提供するシステムにおいて、クライアント装置側でサーバ装置の障害を検出する技術が、例えば、特許文献１に開示されている。特許文献１に記載されているクライアント装置は、サーバからのレスポンスタイムをもとに、スローダウンの予兆を検出し、予兆が検出された場合に、その旨を評価装置へ通知する。
【０００３】
なお、関連技術として、特許文献２には、多数のノードにおいて障害が同時に発生した場合に、ネットワーク監視装置において同一内容の障害通知を破棄する技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−２３１３６８号公報
【特許文献２】特開平６−３００１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述の特許文献１の技術では、クライアント装置が多数存在する場合に、同時に多数のクライアント装置から通知が送信される。クライアント装置からの通知を評価装置やサーバ装置が受信する場合、このような多数の通知により、評価装置やサーバ装置は、サービス妨害攻撃（ＤＯＳ（Denial Of Service）攻撃）を受けたときと同様に、ダウンさせられる危険性がある。
【０００６】
本発明の目的は、上述した課題を解決し、サーバ装置の障害をクライアント装置で検出するシステムにおいて、障害通知の数を低減可能な、情報処理システム、情報処理装置、情報処理方法、及び、プログラムを提供することにある。
【課題を解決するための手段】
【０００７】
本発明の情報処理システムは、サーバ装置と複数のクライアント装置とを備え、前記複数のクライアント装置の各々は、前記サーバ装置の障害を監視する監視手段と、前記複数のクライアント装置の各々から所定の装置への通知の経路を示す、前記複数のクライアント装置が配置されたツリーに従って、前記サーバ装置の障害が検出されたことを示す障害通知を、当該障害通知が重複しないように送信する通知手段と、を含む。
【０００８】
本発明の情報処理装置は、サーバ装置と複数の情報処理装置を含む情報処理システムにおける情報処理装置であって、前記サーバ装置の障害を監視する監視手段と、前記複数の情報処理装置の各々から所定の装置への通知の経路を示す、前記複数の情報処理装置が配置されたツリーに従って、前記サーバ装置の障害が検出されたことを示す障害通知を、当該障害通知が重複しないように送信する通知手段と、を含む。
【０００９】
本発明の情報処理方法は、サーバ装置と複数のクライアント装置を含む情報処理システムにおける情報処理方法であって、前記複数のクライアント装置の各々において、前記サーバ装置の障害を監視し、前記複数のクライアント装置の各々から所定の装置への通知の経路を示す、前記複数のクライアント装置が配置されたツリーに従って、前記サーバ装置の障害が検出されたことを示す障害通知を、当該障害通知が重複しないように送信する。
【００１０】
本発明のプログラムは、サーバ装置と複数のクライアント装置を含む情報処理システムにおけるクライアント装置のプログラムであって、コンピュータに、前記サーバ装置の障害を監視する処理と、前記複数のクライアント装置の各々から所定の装置への通知の経路を示す、前記複数のクライアント装置が配置されたツリーに従って、前記サーバ装置の障害が検出されたことを示す障害通知を、当該障害通知が重複しないように送信する通知処理と、を実行させる。
【発明の効果】
【００１１】
本発明の効果は、サーバ装置の障害をクライアント装置で検出するシステムにおいて、障害通知の数を低減できることである。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施の形態の特徴的な構成を示すブロック図である。
【図２】本発明の実施の形態における、サービス提供システム１の構成を示すブロック図である。
【図３】本発明の実施の形態における、コンピュータにより実現されたサーバ装置１００、及び、クライアント装置２００の構成を示すブロック図である。
【図４】本発明の実施の形態における、ツリー更新処理のフローチャートである。
【図５】本発明の実施の形態における、障害検出処理のフローチャートである。
【図６】本発明の実施の形態における、障害転送処理のフローチャートである。
【図７】本発明の実施の形態における、ログ取得処理のフローチャートである。
【図８】本発明の実施の形態における、ツリー情報１４１、仮想ツリー１４２、及び、ツリー情報２６１の例を示す図である。
【図９】本発明の実施の形態における、検出情報２４１の例を示す図である。
【図１０】本発明の実施の形態における、通知情報２５１の例を示す図である。
【図１１】本発明の実施の形態における、ツリー情報１４１、仮想ツリー１４２、及び、ツリー情報２６１の他の例を示す図である。
【図１２】本発明の実施の形態における、ツリー情報１４１、仮想ツリー１４２、及び、ツリー情報２６１のさらに他の例を示す図である。
【図１３】本発明の実施の形態における、障害通知の転送経路の例を示す図である。
【図１４】本発明の実施の形態における、障害通知の他の転送経路の例を示す図である。
【図１５】本発明の実施の形態における、障害通知のさらに他の転送経路の例を示す図である。
【図１６】本発明の実施の形態における、フラグクリア要求の転送経路の例を示す図である。
【発明を実施するための形態】
【００１３】
本発明の実施の形態について説明する。
【００１４】
はじめに、本発明の実施の形態の構成について説明する。
【００１５】
図２は、本発明の実施の形態における、サービス提供システム１の構成を示すブロック図である。サービス提供システム１は、本発明の情報処理システムの一実施形態である。
【００１６】
サービス提供システム１は、クライアント装置２００にＷｅｂサービスを提供するサーバ装置１００、及び、複数のクライアント装置２００を含む。サーバ装置１００とクライアント装置２００とは、ネットワーク等により接続される。
【００１７】
サーバ装置１００は、Ｗｅｂサーバ１１０、リクエスト受付部１２０、ツリー情報管理部１３０、ツリー情報記憶部１４０、レスポンス閾値管理部１５０、レスポンス閾値記憶部１６０、ログ取得部１７０、及び、ログ記憶部１８０を含む。リクエスト受付部１２０、ツリー情報管理部１３０、レスポンス閾値管理部１５０、及び、ログ取得部１７０は、サーバ装置１００上で動作する常駐プログラム１９０により実現されていてもよい。
【００１８】
Ｗｅｂサーバ１１０は、クライアント装置２００から受信したＷｅｂサービスに係るリクエスト（サービスリクエスト）に対して、Ｗｅｂサービスに係る提供データを含むレスポンス（サービスレスポンス）をＷｅｂブラウザ２１０へ送信する。
【００１９】
リクエスト受付部１２０は、クライアント装置２００からサービスリクエストを受け付け、Ｗｅｂサーバ１１０へ転送する。また、リクエスト受付部１２０は、Ｗｅｂサーバ１１０から受信したサービスレスポンスをクライアント装置２００へ転送する。
【００２０】
ツリー情報管理部１３０は、ツリー情報１４１を生成、更新する。ツリー情報１４１は、各クライアント装置２００が、サーバ装置１００へ障害通知を送信するための経路を表す、仮想ツリー１４２を示す。
【００２１】
図８は、本発明の実施の形態における、ツリー情報１４１、仮想ツリー１４２、及び、ツリー情報２６１の例を示す図である。図８の左側のツリー情報１４１、ツリー情報２６１は、右側の仮想ツリー１４２に対応する。
【００２２】
ツリー情報１４１は、図８に示すように、各クライアント装置２００の識別子（クライアントＩＤ（IDentifier））、当該クライアント装置２００の親、及び、１以上の子のクライアントＩＤを含む。ツリー情報１４１は、さらに、前回のアクセス時刻を含んでいてもよい。
【００２３】
本発明の実施の形態では、仮想ツリー１４２上における、各親のクライアント装置２００が持つことができる子のクライアント装置２００の数は３台であると仮定する。子のクライアント装置２００は、親のクライアント装置２００へ障害通知を送信する。また、ルート（根）に登録されたクライアント装置２００は、サーバ装置１００へ障害通知を送信する。
【００２４】
ツリー情報管理部１３０は、クライアント装置２００からの最初のアクセスに対して、当該クライアント装置２００を仮想ツリー１４２に登録し、ツリー情報１４１を更新する。そしてツリー情報管理部１３０は、当該クライアント装置２００に、後述するツリー情報２６１を送信する。
【００２５】
ツリー情報記憶部１４０は、ツリー情報１４１を記憶する。
【００２６】
レスポンス閾値管理部１５０は、レスポンス閾値１６１をクライアント装置２００へ配布する。レスポンス閾値１６１は、サービスリクエストに対するサービスレスポンスを受信するまでの時間の閾値である。レスポンス閾値１６１は、クライアント装置２００の監視部２２０が、サーバ装置１００の障害の有無を判定するために用いられる。例えば、レスポンス閾値１６１が「２分」の場合、クライアント装置２００がサービスリクエストを送信してから、サーバ装置１００からサービスレスポンスを受信するまでの時間が２分を超えた場合、サーバ装置１００の障害が発生していると判定される。
【００２７】
レスポンス閾値記憶部１６０は、レスポンス閾値１６１を記憶する。
【００２８】
ログ取得部１７０は、クライアント装置２００から障害通知を受信した場合に、ログ１８１を取得する。ここで、ログ取得部１７０は、例えば、Ｗｅｂサーバ１１０の動作に係る各種ログや、クライアント装置２００との通信に係る各種ログを取得する。
【００２９】
ログ記憶部１８０は、ログ１８１を記憶する。
【００３０】
クライアント装置２００は、Ｗｅｂブラウザ２１０、監視部２２０、通知部２３０、検出情報記憶部２４０、通知情報記憶部２５０、及び、ツリー情報記憶部２６０を含む。監視部２２０、及び、通知部２３０は、クライアント装置２００上で動作する監視プログラム２７０により実現されていてもよい。
【００３１】
Ｗｅｂブラウザ２１０は、サービスリクエストを、サーバ装置１００のＷｅｂサーバ１１０に送信する。また、Ｗｅｂブラウザ２１０は、サービスレスポンスをＷｅｂサーバ１１０から受信する。
【００３２】
監視部２２０は、サーバ装置１００の障害の有無を監視する。監視部２２０は、上述のレスポンス閾値１６１を用いて、サーバ装置１００の障害が発生しているかどうかを判定する。
【００３３】
通知部２３０は、監視部２２０によりサーバ装置１００の障害が検出された場合、または、他のクライアント装置２００から障害通知を受信した場合に、通知情報２５１を参照して、障害通知を送信するかどうか判定する。通知部２３０は、ツリー情報２６１を参照し、ツリー上の親のクライアント装置２００、または、サーバ装置１００へ障害通知を送信する。
【００３４】
検出情報記憶部２４０は、検出情報２４１（ｄｅｔｅｃｔフラグ）を記憶する。検出情報２４１は、サーバ装置１００の障害の検出有無を示す。
【００３５】
図９は、本発明の実施の形態における、検出情報２４１の例を示す図である。
【００３６】
図９に示すように、検出情報２４１には、自クライアント装置２００において、サーバ装置１００の障害が検出されている場合は「ｔｒｕｅ」が、検出されていない場合は「ｆａｌｓｅ」が設定される。
【００３７】
通知情報記憶部２５０は、通知情報２５１（ｓｅｎｄＲｅｑｕｅｓｔフラグ）を記憶する。通知情報２５１は、自クライアント装置２００または他のクライアント装置２００において検出されたサーバ装置１００の障害に対して、自クライアント装置２００が障害通知を送信済みかどうかを示す。
【００３８】
図１０は、本発明の実施の形態における、通知情報２５１の例を示す図である。
【００３９】
図１０に示すように、通知情報２５１には、自クライアント装置２００が障害通知を送信済みの場合は「ｔｒｕｅ」が、送信済みでない場合は「ｆａｌｓｅ」が設定される。
【００４０】
ツリー情報記憶部２６０は、ツリー情報２６１を記憶する。ツリー情報２６１は、ツリー情報１４１の内、自クライアント装置２００に係るツリーの情報を示す。
【００４１】
図８に示すように、ツリー情報２６１には、ツリー上の自クライアント装置２００のクライアントＩＤに対して、当該クライアント装置２００の親、及び、１以上の子のクライアントＩＤが設定される。さらに、ツリー情報２６１には、ツリー上の自クライアント装置２００からルートまでの各クライアント装置２００のクライアントＩＤに対して、当該クライアント装置２００の親のクライアントＩＤが設定される。
【００４２】
なお、サーバ装置１００、及び、クライアント装置２００は、それぞれ、ＣＰＵ（Central Processing Unit）とプログラムを記憶した記憶媒体を含み、プログラムに基づく制御によって動作するコンピュータであってもよい。
【００４３】
図３は、本発明の実施の形態における、コンピュータにより実現されたサーバ装置１００、及び、クライアント装置２００の構成を示すブロック図である。
【００４４】
サーバ装置１００は、ＣＰＵ１０１、ハードディスクやメモリ等の記憶手段（記憶媒体）１０２、他の装置と通信を行う通信手段１０３、キーボード等の入力手段１０４、及び、ディスプレイ等の出力手段１０５を含む。ＣＰＵ１０１は、Ｗｅｂサーバ１１０を実現するためのプログラム、及び、上述の常駐プログラム１９０を実行する。記憶手段１０２は、ツリー情報記憶部１４０、レスポンス閾値管理部１５０、レスポンス閾値記憶部１６０、及び、ログ記憶部１８０のデータを記憶する。通信手段１０３は、クライアント装置２００との間で、サービスリクエスト／レスポンスの送受信を行う。また、また、通信手段１０３は、クライアント装置２００との間で、障害通知／レスポンスの送受信を行う。入力手段１０４は、例えば、管理者等から、ログ１８１出力の指示を受け付ける。出力手段１０５は、例えば、管理者等へ、ログ１８１を出力する。
【００４５】
同様に、クライアント装置２００は、ＣＰＵ２０１、記憶手段（記憶媒体）２０２、通信手段２０３、入力手段２０４、及び、出力手段２０５を含む。ＣＰＵ２０１は、Ｗｅｂブラウザ２１０を実現するためのプログラム、及び、上述の監視プログラム２７０を実行する。記憶手段２０２は、検出情報記憶部２４０、通知情報記憶部２５０、及び、ツリー情報記憶部２６０のデータを記憶する。通信手段２０３は、サーバ装置１００との間で、サービス／レスポンスの送受信を行う。また、また、通信手段１０３は、サーバ装置１００や他のクライアント装置２００との間で、障害通知／レスポンスの送受信を行う。入力手段２０４は、例えば、利用者等から、サービスリクエストを受け付ける。出力手段２０５は、例えば、利用者等へ、サービスレスポンスを出力する。
【００４６】
次に、本発明の実施の形態の動作について説明する。
【００４７】
ここでは、クライアント装置２００の監視部２２０が、予め、サーバ装置１００のレスポンス閾値管理部１５０に、レスポンス閾値１６１を要求し、取得していると仮定する。
【００４８】
＜ツリー更新処理＞
はじめに、本発明の実施の形態におけるツリー更新処理を説明する。
【００４９】
図４は、本発明の実施の形態における、ツリー更新処理のフローチャートである。
【００５０】
クライアント装置２００のＷｅｂブラウザ２１０は、サービスリクエストを、サーバ装置１００へ送信する（ステップＳ１０１）。
【００５１】
サーバ装置１００のリクエスト受付部１２０は、受信したサービスリクエストが、クライアント装置２００からの最初のサービスリクエストの場合（ステップＳ１５１／Ｙ）、ツリー情報管理部１３０にツリー情報１４１の更新を指示する。ツリー情報管理部１３０は、当該クライアント装置２００を仮想ツリー１４２に登録し、ツリー情報１４１を更新する（ステップＳ１５２）。ここで、ツリー情報管理部１３０は、当該クライアント装置２００を、仮想ツリー１４２におけるルート（根）、または、既に登録されているクライアント装置２００の子として、順番に登録する。
【００５２】
ツリー情報管理部１３０は、仮想ツリー１４２上に登録された（サービスリクエスト送信元の）クライアント装置２００、及び、当該クライアント装置２００の親のクライアント装置２００に、ツリー情報２６１を送信する（ステップＳ１５３）。ここで、ツリー情報管理部１３０は、登録された（サービスリクエスト送信元の）クライアント装置２００には、ツリー情報２６１を、サービスレスポンスとともに送信してもよい。
【００５３】
クライアント装置２００の監視部２２０は、受信したツリー情報２６１をツリー情報記憶部２６０に保存する（ステップＳ１０２）。
【００５４】
次に、ツリー更新処理の具体例を説明する。
【００５５】
図１１、図１２は、本発明の実施の形態における、ツリー情報１４１、仮想ツリー１４２、及び、ツリー情報２６１の他の例を示す図である。
【００５６】
例えば、サーバ装置１００が、識別子「2.1.1.1」のクライアント装置２００（以下、クライアント装置２００「2.1.1.1」と記載する）から、最初のサービスリクエストを受信したと仮定する。サーバ装置１００のツリー情報管理部１３０は、クライアント装置２００「2.1.1.1」を、図１１のように仮想ツリー１４２に登録し、ツリー情報１４１に、クライアント装置２００「2.1.1.1」を追加する。また、ツリー情報管理部１３０は、図１１のような、クライアント装置２００「2.1.1.1」に係るツリー情報２６１を、クライアント装置２００「2.1.1.1」に送信する。クライアント装置２００「2.1.1.1」のツリー情報記憶部２６０は、受信したツリー情報２６１を、ツリー情報記憶部２６０に保存する。
【００５７】
次に、サーバ装置１００が、クライアント装置２００「3.1.1.1」から、最初のサービスリクエストを受信したと仮定する。サーバ装置１００のツリー情報管理部１３０は、クライアント装置２００「3.1.1.1」を、図１２のように仮想ツリー１４２に登録し、ツリー情報１４１に、クライアント装置２００「3.1.1.1」を追加する。ツリー情報管理部１３０は、図１２のような、クライアント装置２００「3.1.1.1」に係るツリー情報２６１を、クライアント装置２００「3.1.1.1」に送信する。クライアント装置２００「3.1.1.1」のツリー情報記憶部２６０は、受信したツリー情報２６１を、ツリー情報記憶部２６０に保存する。さらに、ツリー情報管理部１３０は、図１２のような、クライアント装置２００「2.1.1.1」に係るツリー情報２６１を、クライアント装置２００「2.1.1.1」に送信する。クライアント装置２００「2.1.1.1」のツリー情報記憶部２６０は、受信したツリー情報２６１で、ツリー情報記憶部２６０に保存されているツリー情報２６１を更新する。
【００５８】
＜障害検出処理、障害通知転送処理＞
次に、本発明の実施の形態における障害検出処理を説明する。
【００５９】
図５は、本発明の実施の形態における、障害検出処理のフローチャートである。
【００６０】
はじめに、クライアント装置２００の監視部２２０は、サーバ装置１００の障害の有無を判定する（ステップＳ２０１）。ここで、監視部２２０は、サービスリクエストに対するサービスレスポンスを受信するまでの時間がレスポンス閾値１６１を超えている場合、サーバ装置１００の障害が発生していると判定する。
【００６１】
サーバ装置１００の障害が検出された場合（ステップＳ２０１／Ｙ）、監視部２２０は、検出情報２４１に「ｔｒｕｅ」を設定する（ステップＳ２０２）。
【００６２】
通知部２３０は、通知情報２５１に「ｔｒｕｅ」が設定されているかを判定する（ステップＳ２０３）。
【００６３】
通知情報２５１に「ｔｒｕｅ」が設定されている場合（ステップＳ２０３／Ｙ）、障害通知は送信済みである。通知部２３０は、障害通知が重複してサーバ装置１００に送信されるのを防ぐため、障害通知を送信せず、処理を終了する。
【００６４】
通知情報２５１に「ｆａｌｓｅ」が設定されている場合（ステップＳ２０３／Ｎ）、障害通知は送信されていないため、通知部２３０は、ツリー情報２６１を参照し、自クライアント装置２００の親に、障害通知を送信する（ステップＳ２０４）。
【００６５】
通知部２３０は、親から、所定の時間内に、障害通知に対するレスポンスを受信したかどうかを判定する（ステップＳ２０５）。
【００６６】
障害通知に対するレスポンスを受信しなかった場合（ステップＳ２０５／Ｎ）、親のクライアント装置２００の電源がオフになっている等の理由で、障害通知を送受信できない可能性がある。したがって、通知部２３０は、ツリー情報２６１を更新する（ステップＳ２０６）。ここで、通知部２３０は、自クライアント装置２００の親のクライアント装置２００に対して設定された情報を削除する。また、通知部２３０は、自クライアント装置２００に対して設定された親のクライアントＩＤを、当該親のさらに親のクライアントＩＤで更新する。
【００６７】
そして、通知部２３０は、ステップＳ２０４からの処理を繰り返す。なお、通知部２３０は、ステップＳ２０４において、更新後の親に障害通知を送信するときに、更新前の親のクライアントＩＤを含むツリー情報更新要求を、障害通知とともに送信する。
【００６８】
一方、障害通知に対するレスポンスを受信した場合（ステップＳ２０５／Ｙ）、通知部２３０は、通知情報２５１に「ｔｒｕｅ」を設定し（ステップＳ２０７）、処理を終了する。
【００６９】
次に、本発明の実施の形態における障害転送処理を説明する。
【００７０】
図６は、本発明の実施の形態における、障害転送処理のフローチャートである。
【００７１】
はじめに、クライアント装置２００の通知部２３０は、他のクライアント装置２００から、障害通知を受信したかどうかを判定する（ステップＳ３０１）。
【００７２】
障害通知を受信した場合（ステップＳ３０１／Ｙ）、通知部２３０は、障害通知の送信元のクライアント装置２００に、当該障害通知に対するレスポンスを送信する（ステップＳ３０２）。
【００７３】
通知部２３０は、ツリー情報２６１を参照し、障害通知とともにツリー情報更新要求を受信したかどうかを判定する（ステップＳ３０３）。
【００７４】
ツリー情報更新要求を受信した場合（ステップＳ３０３／Ｙ）、自クライアント装置２００の子の内、ツリー情報更新要求に含まれるクライアントＩＤで示される子は、電源がオフになっている等の理由で、障害通知を送受信できない可能性がある。したがって、通知部２３０は、ツリー情報２６１を更新する（ステップＳ３０４）。ここで、通知部２３０は、自クライアント装置２００に対する子のクライアントＩＤの内、ツリー情報更新要求に含まれるクライアントＩＤを、ツリー情報更新要求の送信元（障害通知の送信元）のクライアント装置２００のクライアントＩＤで更新する。
【００７５】
以降、上述の障害検出処理における、ステップＳ２０３以降の処理が行われる。
【００７６】
次に、障害検出処理、及び、障害通知転送処理の具体例を説明する。
【００７７】
例えば、図８のように仮想ツリー１４２が生成されているときに、クライアント装置２００「3.1.1.1」においてサーバ装置１００の障害が検出されたと仮定する。また、図８のすべてのクライアント装置２００における検出情報２４１、通知情報２５１には、「ｆａｌｓｅ」が設定されていると仮定する。
【００７８】
図１３は、本発明の実施の形態における、障害通知の転送経路の例を示す図である。
【００７９】
クライアント装置２００「3.1.1.1」の監視部２２０は、検出情報２４１に「ｔｒｕｅ」を設定する（図１３、（１））。通知部２３０は、親のクライアント装置２００「2.1.1.1」に障害通知を送信する（図１３、（２））。
【００８０】
クライアント装置２００「2.1.1.1」の通知部２３０は、クライアント装置２００「3.1.1.1」に障害通知に対するレスポンスを送信する（図１３、（３））。
【００８１】
クライアント装置２００「3.1.1.1」の通知部２３０は、通知情報２５１に「ｔｒｕｅ」を設定する（図１３、（４））。
【００８２】
クライアント装置２００「2.1.1.1」の通知部２３０は、親のサーバ装置１００「1.1.1.1」に障害通知を送信する（図１３、（５））。クライアント装置２００「2.1.1.1」の通知部２３０は、通知情報２５１に「ｔｒｕｅ」を設定する（図１３、（６））。
【００８３】
そして、さらに、クライアント装置２００「4.1.1.1」においてサーバ装置１００の障害が検出されたと仮定する。
【００８４】
図１４は、本発明の実施の形態における、障害通知の他の転送経路の例を示す図である。
【００８５】
クライアント装置２００「4.1.1.1」の監視部２２０は、検出情報２４１に「ｔｒｕｅ」を設定する（図１４、（１））。通知部２３０は、親のクライアント装置２００「3.1.1.1」に障害通知を送信する（図１４、（２））。
【００８６】
クライアント装置２００「3.1.1.1」の通知部２３０は、クライアント装置２００「4.1.1.1」に障害通知に対するレスポンスを送信する（図１４、（３））。
【００８７】
クライアント装置２００「4.1.1.1」の通知部２３０は、通知情報２５１に「ｔｒｕｅ」を設定する（図１４、（４））。
【００８８】
クライアント装置２００「3.1.1.1」の通知部２３０は、通知情報２５１に「ｔｒｕｅ」が設定されているため、障害通知を送信しない。
【００８９】
また、例えば、図８のように仮想ツリー１４２が生成されているときに、クライアント装置２００「3.1.1.1」の電源がオフになったと仮定する。そして、クライアント装置２００「4.1.1.1」においてサーバ装置１００の障害が検出されたと仮定する。また、図８のすべてのクライアント装置２００における検出情報２４１、通知情報２５１には、「ｆａｌｓｅ」が設定されていると仮定する。
【００９０】
図１５は、本発明の実施の形態における、障害通知のさらに他の転送経路の例を示す図である。
【００９１】
クライアント装置２００「4.1.1.1」の監視部２２０は、検出情報２４１に「ｔｒｕｅ」を設定する（図１５、（１））。通知部２３０は、親のクライアント装置２００「3.1.1.1」に障害通知を送信する（図１５、（２））。通知部２３０は、クライアント装置２００「3.1.1.1」から、障害通知に対するレスポンスを受信しないため、ツリー情報２６１を更新する（図１５、（３））。ここで、通知部２３０は、クライアント装置２００「3.1.1.1」に対して設定された情報を削除する。また、通知部２３０は、クライアント装置２００「4.1.1.1」に対して設定された親のクライアントＩＤ「3.1.1.1」をさらに親のクライアントＩＤ「2.1.1.1」で更新する。通知部２３０は、更新後の親のクライアント装置２００「2.1.1.1」に障害通知を送信する（図１５、（４））。ここで、通知部２３０は、更新前の親のクライアントＩＤ「3.1.1.1」を含むツリー情報更新要求を、障害通知とともに送信する。
【００９２】
クライアント装置２００「2.1.1.1」の通知部２３０は、クライアント装置２００「4.1.1.1」に障害通知に対するレスポンスを送信する（図１５、（５））。
【００９３】
クライアント装置２００「4.1.1.1」の通知部２３０は、通知情報２５１に「ｔｒｕｅ」を設定する（図１５、（６））。
【００９４】
クライアント装置２００「2.1.1.1」の通知部２３０は、ツリー情報２６１を更新する（図１５、（７））。ここで、通知部２３０は、子のクライアントＩＤ「3.1.1.1」を、障害通知の送信元のクライアントＩＤ「4.1.1.1」で更新する。通知部２３０は、親のサーバ装置１００「1.1.1.1」に障害通知を送信する（図１５、（８））。通知部２３０は、通知情報２５１に「ｔｒｕｅ」を設定する（図１５、（９））。
【００９５】
＜ログ取得処理＞
次に、本発明の実施の形態におけるログ取得処理を説明する。
【００９６】
図７は、本発明の実施の形態における、ログ取得処理のフローチャートである。
【００９７】
はじめに、サーバ装置１００のログ取得部１７０は、クライアント装置２００から、障害通知を受信したかどうかを判定する（ステップＳ４５１）。
【００９８】
障害通知を受信した場合（ステップＳ４５１／Ｙ）、ログ取得部１７０は、ログ１８１を取得する（ステップＳ４５２）。
【００９９】
ログ１８１の取得が完了すると、ログ取得部１７０は、ツリー情報１４１を参照し、子のクライアント装置２００に、フラグクリア要求を送信する（ステップＳ４５３）。
【０１００】
各クライアント装置２００の通知部２３０は、親のサーバ装置１００またはクライアント装置２００から、フラグクリア要求を受信したかどうかを判定する（ステップＳ４０１）。
【０１０１】
フラグクリア要求を受信した場合（ステップＳ４０１／Ｙ）、通知部２３０は、検出情報２４１と通知情報２５１とに「ｆａｌｓｅ」を設定する（ステップＳ４０２）。また、通知部２３０は、ツリー情報２６１を参照し、子のクライアント装置２００に、フラグクリア要求を送信する（ステップＳ４０３）。
【０１０２】
これにより、仮想ツリー１４２に沿って、フラグクリア要求が、すべてのクライアント装置２００に送信され、すべてのクライアント装置２００で、検出情報２４１と通知情報２５１とに「ｆａｌｓｅ」が設定される。そして、各クライアント装置２００は、次の障害検出に備えることができる。
【０１０３】
次に、ログ取得処理の具体例を説明する。
【０１０４】
例えば、図８のように仮想ツリー１４２が生成されているときに、各クライアント装置２００においてサーバ装置１００の障害が検出され、いずれかのクライアント装置２００から送出された障害通知がサーバ装置１００に到達したと仮定する。また、すべてのクライアント装置２００における検出情報２４１、通知情報２５１に、「ｔｒｕｅ」が設定されていると仮定する。
【０１０５】
図１６は、本発明の実施の形態における、フラグクリア要求の転送経路の例を示す図である。
【０１０６】
サーバ装置１００のログ取得部１７０は、障害通知を受信すると（図１６、（１））、ログ１８１を取得する（図１６、（２））。ログ取得部１７０は、子のクライアント装置２００「2.1.1.1」にフラグクリア要求を送信する（図１６、（３））。
【０１０７】
クライアント装置２００「2.1.1.1」の通知部２３０は、検出情報２４１と通知情報２５１に「ｆａｌｓｅ」を設定する（図１６、（４））。通知部２３０は、さらに、子のクライアント装置２００「3.1.1.1」「3.1.1.2」「3.1.1.3」にフラグクリア要求を送信する（図１６、（５））。
【０１０８】
クライアント装置２００「3.1.1.1」「3.1.1.2」「3.1.1.3」の通知部２３０は、検出情報２４１と通知情報２５１に「ｆａｌｓｅ」を設定する（図１６、（６））。クライアント装置２００「3.1.1.1」の通知部２３０は、さらに、子のクライアント装置２００「4.1.1.1」にフラグクリア要求を送信する（図１６、（７））。
【０１０９】
クライアント装置２００「4.1.1.1」の通知部２３０は、検出情報２４１と通知情報２５１に「ｆａｌｓｅ」を設定する（図１６、（８））。
【０１１０】
以上により、本発明の実施の形態の動作が完了する。
【０１１１】
なお、本発明の実施の形態では、クライアント装置２００が、仮想ツリー１４２に従って、障害通知をサーバ装置１００に送信（転送）した。これに限らず、クライアント装置２００は、仮想ツリー１４２に従って、障害通知をサーバ装置１００以外の他の管理装置等に送信（転送）してもよい。この場合、当該管理装置等が、サーバ装置１００のログ取得部１７０に、ログ１８１の取得を指示してもよい。
【０１１２】
次に、本発明の実施の形態の特徴的な構成を説明する。図１は、本発明の実施の形態の特徴的な構成を示すブロック図である。
【０１１３】
図１を参照すると、本発明のサービス提供システム１（情報処理システム）は、サーバ装置１００と複数のクライアント装置２００とを含む。複数のクライアント装置２００の各々は、監視部２２０と通知部２３０とを含む。監視部２２０は、サーバ装置１００の障害を監視する。通知部２３０は、仮想ツリー１４２（ツリー）に従って、サーバ装置１００の障害が検出されたことを示す障害通知を、当該障害通知が重複しないように送信する。仮想ツリー１４２は、複数のクライアント装置２００の各々から所定の装置への通知の経路を示す、複数のクライアント装置２００が配置されたツリーである。
【０１１４】
本発明の実施の形態によれば、サーバ装置の障害をクライアント装置で検出するシステムにおいて、障害通知の数を低減できる。その理由は、複数のクライアント装置２００の各々が、仮想ツリー１４２（ツリー）に従って、サーバ装置１００の障害が検出されたことを示す障害通知を、当該障害通知が重複しないように送信するためである。
【０１１５】
これにより、例えば、仮想ツリー１４２上での各親のクライアント装置２００が持つ子のクライアント装置２００の台数が３台の場合、１０００台規模のクライアント装置２００に係る障害通知の経路が、例えば、７階層の仮想ツリー１４２により表される。そして、１０００台のクライアント装置２００の内のいずれかで障害が検出された場合でも、仮想ツリー１４２上の６回以内の転送で、障害通知をサーバ装置１００へ送信できる。また、１０００台のクライアント装置２００の内の複数で障害が検出された場合でも、サーバ装置１００へは、１つの障害通知だけが、仮想ツリー１４２上のルート（根）のクライアント装置２００から送信される。
【０１１６】
また、本発明の実施の形態によれば、サーバ装置１００がクラウド環境下に構築される場合に、サーバ装置１００の監視コストを抑えることができる。その理由は、各クライアント装置２００が、サーバ装置１００の障害を監視し、障害通知をサーバ装置１００に送信するためである。これにより、例えば、サーバ装置１００と各クライアント装置２００との間の通信の状況を監視、収集するための他の装置や仕組みが不要となり、システムを構築するためのコストや、監視を行うためのコストが低減する。
【０１１７】
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【０１１８】
例えば、本発明の実施の形態では、仮想ツリー１４２上での各親のクライアント装置２００が持つ子のクライアント装置２００の台数を３台としたが、台数は３台以外でもよい。これにより、例えばシステムの規模（クライアント装置２００の数）に応じて、仮想ツリー１４２の階層数を変え、障害通知がクライアント装置２００からサーバ装置１００に届くまでの時間を調整できる。
【０１１９】
また、本発明の実施の形態では、サーバ装置１００に対して１つの仮想ツリー１４２が生成されたが、サーバ装置１００に対して複数の仮想ツリー１４２が生成されてもよい。この場合、各仮想ツリー１４２のルート（根）に登録されたクライアント装置２００が、サーバ装置１００へ障害通知を送信する。
【０１２０】
また、仮想ツリー１４２のルート（根）に、サーバ装置１００が登録されてもよい。この場合、サーバ装置１００は、クライアント装置２００と同様に、ツリー情報２６１を記憶し、クライアント装置２００からツリー情報更新要求を受信した場合に、ツリー情報２６１を更新する。
【０１２１】
また、サーバ装置１００が、クライアント装置２００からの最初のアクセスに対してツリー情報１４１を更新したが、前回のアクセスから所定期間（例えば１日）経過した場合にツリー情報１４１を更新してもよい。この場合、サーバ装置１００は、例えば、仮想ツリー１４２における、当該クライアント装置２００に係る生成済みの親子の関係を削除し、当該クライアント装置２００を、新たな親のクライアント装置２００の子として登録する。そして、更新された親子関係に係るツリー情報２６１を、クライアント装置２００に送信する。
【符号の説明】
【０１２２】
１    サービス提供システム
１００    サーバ装置
１０１    ＣＰＵ
１０２    記憶手段
１０３    通信手段
１０４    入力手段
１０５    出力手段
１１０    Ｗｅｂサーバ
１２０    リクエスト受付部
１３０    ツリー情報管理部
１４０    ツリー情報記憶部
１４１    ツリー情報
１４２    仮想ツリー
１５０    レスポンス閾値管理部
１６０    レスポンス閾値記憶部
１６１    レスポンス閾値
１７０    ログ取得部
１８０    ログ記憶部
１８１    ログ
１９０    常駐プログラム
２００    クライアント装置
２０１    ＣＰＵ
２０２    記憶手段
２０３    通信手段
２０４    入力手段
２０５    出力手段
２１０    Ｗｅｂブラウザ
２２０    監視部
２３０    通知部
２４０    検出情報記憶部
２４１    検出情報
２５０    通知情報記憶部
２５１    通知情報
２６０    ツリー情報記憶部
２６１    ツリー情報
２７０    監視プログラム
【図１】
0006369255.tif 000002
【図２】
0006369255.tif 000003
【図３】
0006369255.tif 000004
【図４】
0006369255.tif 000005
【図５】
0006369255.tif 000006
【図６】
0006369255.tif 000007
【図７】
0006369255.tif 000008
【図８】
0006369255.tif 000009
【図９】
0006369255.tif 000010
【図１０】
0006369255.tif 000011
【図１１】
0006369255.tif 000012
【図１２】
0006369255.tif 000013
【図１３】
0006369255.tif 000014
【図１４】
0006369255.tif 000015
【図１５】
0006369255.tif 000016
【図１６】
0006369255.tif 000017