(57)【要約】【課題】複数の異なる機能を持つサーバを組み合わせることでサービスを提供するマルチサーバシステムの死活監視を行う死活監視装置を提供する。【解決手段】死活監視装置３０は、複数の異なる機能を持つサーバを組み合わせてサービスを提供するマルチサーバシステム１００の死活監視を、当該マルチサーバシステムのサービス要求信号を送信して要求する死活監視要求送信部３１と死活監視部３２とを具備する装置であり、死活監視要求送信部３１は、マルチサーバシステム１００の正常性を監視する死活監視を、当該マルチサーバシステム１００にそのシステムが用いている通常のサービス要求信号を送信して要求し、死活監視部３２は、サービス要求信号に対するレスポンス信号のステータスコードに基づいて死活監視を行う。【選択図】図１
2016148973.tif 000002
【特許請求の範囲】
【請求項１】
異なる機能を持つ複数のサーバを組み合わせてサービスを提供するマルチサーバシステムの死活監視用の信号として、前記マルチサーバシステムが提供するサービスの要求信号を前記複数のサーバの何れかに送信する死活監視要求送信部と、
前記要求信号に対するレスポンス信号を受信し、当該レスポンス信号に含まれる前記要求信号の送信先サーバのステータスと前記送信先サーバと連携する連携先サーバのステータスとを用いて、前記複数のサーバの死活監視を行う死活監視部と
を具備することを特徴とする死活監視装置。
【請求項２】
異なる機能を持つ複数のサーバを組み合わせてサービスを提供するマルチサーバシステムと、死活監視装置とを具備する死活監視システムであって、
前記死活監視装置は、
前記マルチサーバシステムの死活監視用の信号として、前記マルチサーバシステムが提供するサービスの要求信号を前記複数のサーバの何れかに送信する死活監視要求送信部と、
前記要求信号に対するレスポンス信号を受信し、当該レスポンス信号に含まれる前記要求信号の送信先サーバのステータスと前記送信先サーバと連携する連携先サーバのステータと故障情報とを用いて、前記複数のサーバの死活監視を行う死活監視部とを具備し、
前記サーバは、
前記サービスの前記要求信号に対する前記レスポンス信号に前記故障情報を付加する故障情報付加部を具備する
ことを特徴とする死活監視システム。  
【請求項３】
請求項２に記載した死活監視システムにおいて、
前記故障情報には、前記連携先サーバを識別する識別子が含まれることを特徴とする死活監視システム。
【請求項４】
死活監視装置が行う死活監視方法であって、
異なる機能を持つ複数のサーバを組み合わせてサービスを提供するマルチサーバシステムの死活監視用の信号として、前記マルチサーバシステムが提供するサービスの要求信号を前記複数のサーバの何れかに送信する死活監視要求送信ステップと、
前記要求信号に対するレスポンス信号を受信し、当該レスポンス信号に含まれる前記要求信号の送信先サーバのステータスと前記送信先サーバと連携する連携先サーバのステータスとを用いて、前記複数のサーバの死活監視を行う死活監視ステップと
を行うことを特徴とする死活監視方法。
【請求項５】
異なる機能を持つ複数のサーバを組み合わせてサービスを提供するマルチサーバシステムと、死活監視装置とを具備する死活監視システムが行う死活監視方法であって、
前記死活監視装置が、前記マルチサーバシステムの死活監視用の信号として前記サービスの要求信号を送信する死活監視要求送信ステップを行い、
前記サーバが、前記要求信号に対するレスポンス信号に故障情報を付加する故障情報付加ステップを行い、
前記死活監視装置が、前記要求信号に対するレスポンス信号を受信し、当該レスポンス信号に含まれる前記要求信号の送信先サーバのステータスと前記送信先サーバと連携する連携先サーバのステータと故障情報とを用いて、複数の前記サーバの死活監視を行う死活監視ステップとを行う
ことを特徴とする死活監視方法。
【請求項６】
請求項５に記載した死活監視方法において、
前記故障情報には、前記連携先サーバを識別する識別子が含まれることを特徴とする死活監視方法。
【請求項７】
請求項４に記載した死活監視方法を、コンピュータに実行させるための死活監視方法プログラム。
【請求項８】
請求項５又は６に記載した死活監視方法を、コンピュータシステムに実行させるための死活監視方法プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システムを構成する複数のサーバの死活を監視する死活監視装置、死活監視システム、死活監視方法、及び死活監視方法プログラムに関する。
【背景技術】
【０００２】
複数の異なる機能を持つサーバを組み合わせることでサービスを提供しているシステムにおいて、サービスの提供に利用する全てのサーバのパフォーマンスや動作の正常性を管理することは、サービス提供の維持や、ダウンタイムの最小化のために重要である。
【０００３】
アプリケーションサーバ（以降、サーバ）の正常あるいは故障を、他のサーバから信号を送って確認するサーバの死活監視方法が知られている（非特許文献１）。従来の死活監視方法は、ネットワークで接続された外部から死活監視信号を各サーバに送信する。そして死活監視信号を受信したサーバは、自サーバが正しく動作しているかを判断し、その判断結果を返すことでサーバの死活を監視する方法である。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】http://asp.ag-monitor.com/about_watching.php
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来の死活監視方法は、死活活監視信号を受信したサーバが自サーバのアプリケーションの動作のみを診断する方法であり、同等の機能を持つ複数サーバで構成されるシステムに用いられている。その特徴は、自サーバのアプリケーションの動作の正常性のみを判断するものである。
【０００６】
よって、異なる機能のサーバを組み合わせてサービスを提供するシステムに用いることができない。つまり、従来の方法は、死活を監視するサーバに、各サーバが正常であることを判断した結果を応答する方法であり、各サーバが正常であるか故障であるかが分かるだけである。
【０００７】
したがって、複数の異なる機能を持つサーバを組み合わせることでサービスを提供しているマルチサーバシステムのサーバ間の連携動作を含めた正常性については監視することができない課題がある。
【０００８】
この発明は、この課題に鑑みてなされたものであり、複数の異なる機能を持つサーバを組み合わせることでサービスを提供するマルチサーバシステムの死活監視を行う死活監視装置、死活監視システム、死活監視方法、及び死活監視方法プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の死活監視装置は、異なる機能を持つ複数のサーバを組み合わせてサービスを提供するマルチサーバシステムの死活監視用の信号として、前記マルチサーバシステムが提供するサービスの要求信号を前記複数のサーバの何れかに送信する死活監視要求送信部と、前記要求信号に対するレスポンス信号を受信し、当該レスポンス信号に含まれる前記要求信号の送信先サーバのステータスと前記送信先サーバと連携する連携先サーバのステータスとを用いて、複数の前記サーバの死活監視を行う死活監視部とを具備することを要旨とする。
【００１０】
また、本発明の死活監視システムは、異なる機能を持つ複数のサーバを組み合わせてサービスを提供するマルチサーバシステムと、死活監視装置とを具備する死活監視システムであって、前記死活監視装置は、前記マルチサーバシステムの死活監視用の信号として、前記マルチサーバシステムが提供するサービスの要求信号を前記複数のサーバの何れかに送信する死活監視要求送信部と、前記要求信号に対するレスポンス信号を受信し、当該レスポンス信号に含まれる前記要求信号の送信先サーバのステータスと前記送信先サーバと連携する連携先サーバのステータと故障情報とを用いて、複数の前記サーバの死活監視を行う死活監視部とを具備し、前記サーバは、前記サービスの要求信号に対する前記レスポンス信号に前記故障情報を付加する故障情報付加部を具備することを要旨とする。
【００１１】
また、本発明の死活監視方法は、死活監視装置が行う死活監視方法であって、異なる機能を持つ複数のサーバを組み合わせてサービスを提供するマルチサーバシステムの死活監視用の信号として、前記マルチサーバシステムが提供するサービスの要求信号を前記複数のサーバの何れかに送信する死活監視要求送信ステップと、前記要求信号に対するレスポンス信号を受信し、当該レスポンス信号に含まれる前記要求信号の送信先サーバのステータスと前記送信先サーバと連携する連携先サーバのステータスとを用いて、複数の前記サーバの死活監視を行う死活監視ステップとを行うことを要旨とする。
【００１２】
また、本発明の他の死活監視方法は、異なる機能を持つ複数のサーバを組み合わせてサービスを提供するマルチサーバシステムと、死活監視装置とを具備する死活監視システムが行う死活監視方法であって、前記死活監視装置が、前記マルチサーバシステムの死活監視用の信号として前記サービスの要求信号を送信する死活監視要求送信ステップを行い、前記サーバが、前記要求信号に対するレスポンス信号に故障情報を付加する故障情報付加ステップを行い、前記死活監視装置が、前記要求信号に対するレスポンス信号を受信し、当該レスポンス信号に含まれる前記要求信号の送信先サーバのステータスと前記送信先サーバと連携する連携先サーバのステータと故障情報とを用いて、複数の前記サーバの死活監視を行う死活監視ステップとを行うことを要旨とする。
【００１３】
また、本発明の死活監視方法プログラムは、上記の死活監視方法をコンピュータ又はコンピュータシステムに実行させるためのプログラムである。
【発明の効果】
【００１４】
この発明の死活監視装置と死活監視方法によれば、複数の異なる機能を持つサーバを組み合わせることでサービスを提供しているマルチサーバシステムのサーバ間の連携動作の正常性について監視することができる。
【００１５】
また、この発明の死活監視システムによれば、更に、故障しているサーバを特定する等、より詳しく死活監視を行うことができる。また、この発明の死活監視方法プログラムによれば、この発明の死活監視方法を、コンピュータ又はコンピュータシステムに実行させることができる。
【図面の簡単な説明】
【００１６】
【図１】第１実施形態の死活監視システム１の構成例を示す図である。
【図２】死活監視システム１の具体例を示す図である。
【図３】死活監視システム１の動作シーケンスを示す図である。
【図４】死活監視システム１のレスポンス信号の例を示す図である。
【図５】死活監視システム１の音声ＤＢサーバ１０２が故障した場合の動作シーケンスを示す図である。
【図６】音声ＤＢサーバ１０２が故障した場合のレスポンス信号の例を示す図である。
【図７】死活監視システム１のストレージ１０３が故障した場合の動作シーケンスを示す図である。
【図８】死活監視装置３０の動作フローを示す図である。
【図９】第２実施形態の死活監視システム２において音声ＤＢサーバ２１０２が故障した場合の動作シーケンスを示す図である。
【図１０】音声ＤＢサーバ２１０２が故障した場合のレスポンス信号の例を示す図である。
【図１１】死活監視システム２のストレージ２１０３が故障した場合の動作シーケンスを示す図である。
【図１２】死活監視システム２のストレージ２１０３が故障した場合のレスポンス信号の例を示す図である。
【図１３】死活監視装置２３０の動作フローを示す図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施の形態について図面を用いて説明する。複数の図面中同一のものに
は同じ参照符号を付し、説明は繰り返さない。
【００１８】
〔第１実施形態〕
図１に、本発明の第１実施形態の死活監視システム１の構成例を示す。本実施形態の死活監視システム１は、マルチサーバシステム１００と、死活監視装置３０とを具備する。      
【００１９】
マルチサーバシステム１００は、異なる機能を持つ複数のサーバ１０１〜１０ｎを具備する。サーバ１０１〜１０ｎの中には、同じ機能を持つサーバが複数含まれていてもよい。同じ機能を持つサーバが複数ある場合は、各サーバに処理を分散させる目的でロードバランサ２０が設けられる。なお、ロードバランサ２０は必須の構成ではない。
【００２０】
死活監視装置３０は、マルチサーバシステム１００の死活監視を、当該マルチサーバシステム１００が提供するサービスの要求信号を複数のサーバの何れかに送信して要求する装置である。死活監視装置３０は、死活監視要求送信部３１と死活監視部３２とを具備する。
【００２１】
死活監視要求送信部３１は、異なる機能を持つ複数のサーバを組み合わせてサービスを提供するマルチサーバシステム１００の死活監視用の信号として、マルチサーバシステム１００が提供するサービスの要求信号を送信する。この要求信号は、マルチサーバシステム１００が用いている通常のサービスを要求する信号と同じである。以降、要求信号をサービス要求信号と称する。
【００２２】
死活監視部３２は、サービス要求信号に対するレスポンス信号を受信して、当該レスポンス信号に含まれる要求信号の送信先サーバのステータスと送信先サーバと連携する連携先サーバのステータスとを用いて、複数のサーバの死活監視を行う。
【００２３】
レスポンス信号とは、サーバへの処理要求に対する応答信号のことである。例えばWebブラウザとWebサーバの間でHTMLなどのコンテンツの送受信に用いられる通信プロトコル（HTTP）のレスポンス信号は、ヘッダー部分とボディ部分とからなる信号である。そのヘッダー部分とボディ部分とには、サーバの状態を表すステータスコードが含まれる。なお、レスポンス信号とステータス信号について詳しくは後述する。
【００２４】
死活監視システム１の死活監視装置３０によれば、マルチサーバシステム１００が通常用いているサービス要求信号を、死活監視を実行するための要求信号として利用する。そして、サービス要求信号に対するレスポンス信号のステータスコードに基づいてマルチサーバシステム１００を構成する各々のサーバの正常性を監視する。したがって、マルチサーバシステム１００側の構成を一切変更せずに、異なる機能を持つ複数のサーバの連携動作を含めた正常性を監視することができる。
【００２５】
更に具体的に説明する。図２に、本実施形態の死活監視システム１のマルチサーバシステム１００を、安否確認システムとした場合の機能構成例を示す。安否確認システム（以降、マルチサーバシステム１００）は、地震や噴火などの災害の発生により、被災地への安否確認の通信が増加し、通信がつながり難い状況になった場合にサービスを提供するシステムである。
【００２６】
伝言を確認したい利用者が、マルチサーバシステム１００に被災地の電話番号を入力することで、被災者が音声又はテキストで登録した伝言を、音声で取得することができる。なお、本来の安否確認の目的でマルチサーバシステム１００を利用する場合は、マルチサーバシステム１００には図示しないサーバ（メディアサーバ）や、利用者が操作する端末が接続される。
【００２７】
マルチサーバシステム１００は、音声ＡＰサーバ１０１、音声ＤＢサーバ１０２、ストレージ１０３、Ｗｅｂ−ＡＰサーバ１０４、及び音声変換サーバ１０５を具備する。マルチサーバシステム１００を構成する各サーバは、ネットワークを介して接続される。図２において、各サーバを接続するネットワークと、マルチサーバシステム１００と死活監視装置３０とを接続するネットワークの表記は省略している。
【００２８】
音声ＡＰサーバ１０１は、利用者からの伝言確認要求があると音声ＤＢサーバ１０２にデータ取得要求を行う。登録された伝言が音声の場合は音声ＤＢサーバ１０２にデータ取得要求を行う。また、登録された伝言がテキストの場合はＷｅｂ−ＡＰサーバ１０４へデータ取得要求を行う。  
【００２９】
音声ＤＢサーバ１０２は、音声ＡＰサーバ１０１からのデータ取得要求に対してストレージ１０３に蓄積された音声データを検索する。ストレージ１０３は、被災者が登録した音声による伝言データを蓄積する。
【００３０】
Ｗｅｂ−ＡＰサーバ１０４は、被災者が登録したテキストによる伝言データを蓄積する。音声変換サーバ１０５は、音声ＡＰサーバ１０１の要求に従ってテキストによる伝言データを音声に変換する。
【００３１】
マルチサーバシステム１００は、利用者からの伝言取得要求に対応する伝言が音声で登録されている場合、音声ＡＰサーバ１０１、音声ＤＢサーバ１０２、及びストレージ１０３が連携して動作することで伝言を再生する。また、伝言がテキストで登録されている場合は、音声ＡＰサーバ１０１、Ｗｅｂ−ＡＰサーバ１０４、及び音声変換サーバ１０５が連携して動作することで伝言を再生する。
【００３２】
このようにマルチサーバシステム１００は、異なる機能を持つ複数のサーバを組み合わせることでサービスを提供するシステムである。なお、登録される伝言の数が多い場合は、複数の音声ＡＰサーバ１０１を設け、各々の音声ＡＰサーバ１０１に負荷を分散させることがある。複数の音声ＡＰサーバ１０１を具備する場合は、ロードバランサ２０が設けられる。ロードバランサ２０は、利用者からの伝言取得要求を各音声ＡＰサーバ１０１に振り分ける。
【００３３】
本実施形態の死活監視要求送信部３１は、複数の音声ＡＰサーバ１０１の何れか（図２に破線で示す音声ＡＰサーバの何れか）にサービス要求信号を送信する。サービス要求信号は、安否確認システム以外のマルチサーバシステムの死活監視を行うときは、そのマルチサーバシステムが提供するサービスを実現するために最初に処理を開始する何れかのサーバに送信される。
【００３４】
以降、伝言が音声で登録された場合を例に死活監視システム１の動作を説明する。
【００３５】
〔正常時〕
図３を参照して、マルチサーバシステム１００が正常時の死活監視システム１の動作を説明する。死活監視装置３０は、音声ＡＰサーバ１０１に対して死活監視要求を行う（ステップＳ１）。この死活監視要求は、例えば被災地の特定の固定電話番号を入力することで行う。この固定電話番号は、被災地の任意の固定電話番号でよい。このように、マルチサーバシステム１００が提供するサービスのサービス要求信号を用いることで死活監視が行える。
【００３６】
なお、試験信号であることを区別する目的で、試験用の電話番号（例えば、9999999999を入力するようにしてもよい。試験用の電話番号を設定し、試験用の伝言を登録しておけば、他の伝言情報に影響を与えずに死活監視を行うことができる。
【００３７】
音声ＡＰサーバ１０１は、死活監視要求（サービス要求信号）を受信すると、音声ＤＢサーバ１０２に対して音声データ取得要求を送信する（ステップＳ２）。音声ＤＢサーバ１０２は、音声データ取得要求を受信するとストレージ１０３に対して音声データ取得要求を送信する（ステップＳ３）。
【００３８】
音声ＤＢサーバ１０２は、ストレージ１０３から音声データを取得（ステップＳ４）して、音声ＡＰサーバ１０１に音声データを送信する（ステップＳ５）。音声ＡＰサーバ１０１は、受信した音声データをレスポンス信号のボディ部分に格納して死活監視装置３０に送信する（ステップＳ６）。ステップＳ６で音声ＡＰサーバ１０１から死活監視装置３０に送信されるレスポンス信号は、ステップＳ１のサービス要求信号に対するレスポンス信号である。
【００３９】
図４に、レスポンス信号の例を示す。図４の例は、HTTPのレスポンス信号である。レスポンス信号は、ヘッダー部分とボディ部分とから構成される。ヘッダー部分とボディ部分には、ステータスコードが含まれる。
【００４０】
ヘッダー部分の１行目は、HTTPのバージョン情報である「HTTP/1.1」と音声ＡＰサーバ１０１の状態を表すステータスコード「200」が記載されている。ステータスコードの「200」は、ステップＳ１の死活監視要求が音声ＡＰサーバ１０１で正常に処理（OK）されたことを意味している。
【００４１】
ボディ部分の３行目は、音声ＤＢサーバ１０２の状態を表すステータスコードである。この例では正常時であるので「200」が記載されている。
【００４２】
このようにレスポンス信号のヘッダー部分には、死活監視装置３０がサービス要求信号を送信した送信先サーバのステータスコードが記載される。また、ボディ部分には、音声ＡＰサーバ１０１が音声データ取得要求を送信する音声ＤＢサーバ１０２のステータスコードが記載される。つまり、ヘッダー部分にはサービス要求信号を送信した送信先サーバのステータスコード、ボディ部分には送信先サーバと連携する連携先サーバのステータスコードが記載される。
【００４３】
死活監視装置３０は、レスポンス信号のヘッダー部分とボディ部分のステータスコードに基づいてマルチサーバシステム１００の死活監視処理を行う（ステップＳ２０）。
【００４４】
〔故障時〕
図５に、音声ＤＢサーバ１０２が故障している場合の動作シーケンスを示す。音声ＤＢサーバ１０２が故障している場合は、音声ＤＢサーバ１０２からストレージ１０３に対して音声データ取得要求（ステップＳ３）は送信されない。当然、ステップＳ３に対する反応もない（ステップＳ４）。
【００４５】
この場合の音声ＤＢサーバ１０２は、レスポンス信号のボディ部分にサーバーエラーを表すステータスコード、例えば「500」を付加して音声ＡＰサーバ１０１に送信する（ステップＳ７）。図６に、この場合のレスポンス信号の例を示す。ボディ部分の３行目に「500」が記載されている。「500」は、サーバ内部のエラー（Internal Server Error）を意味するステータスコードである。
【００４６】
音声ＤＢサーバ１０２が故障している場合は、音声ＡＰサーバ１０１から例えば図６に示したレスポンス信号が、死活監視装置３０に送信される（ステップＳ８）。死活監視装置３０は、レスポンス信号のヘッダー部分とボディ部分のステータスコードとによってマルチサーバシステム１００を構成する各サーバが正常であるか故障であるかを監視することができる。
【００４７】
サーバーエラーを表すステータスコードには、400番台と500番台とがある。4XXは、処理を要求した側（クライアント）にエラーの原因がある場合に付加されるステータスコードである。また、5XXは、処理を要求された側（サーバ）にエラーの原因がある場合に付加されるステータスコードである。
【００４８】
図７に、ストレージ１０３が故障している場合の動作シーケンスを示す。この場合、ストレージ１０３は、レスポンス信号のボディ部分にサーバーエラーを表すステータスコード、例えば「500」を付加して音声ＤＢサーバ１０２に送信する（ステップＳ７）。そのレスポンス信号は、そのまま死活監視装置３０に送信される（ステップＳ８）。この場合のレスポンス信号は、図６に示した例と同じである。このように音声ＡＰサーバ１０１と連携する音声ＤＢサーバ１０２とストレージ１０３のどちらかが故障している場合に、レスポンス信号のボディ部分にサーバーエラーを表すステータスコードが付加される。
【００４９】
図８に、死活監視部３２が行う死活監視処理（ステップＳ２０）の動作フローを示す。死活監視部３２は、ステータスコードを用いて死活監視を行う。
【００５０】
死活監視部３２は、ヘッダー部分のステータスコードが200番台（2XX）（ステップＳ２１のYES）、ボディ部分のステータスコードが200番台（2XX）（ステップＳ２１のYES）で、マルチサーバシステム１００は正常であると判断して処理を終了する（ステップＳ２５）。200番台のステータスコードは成功を意味する。例えば201は作成完了（Created）、202は受理（Accepted）を意味する。
【００５１】
ヘッダー部分のステータスコードが200番台でない場合は、音声ＡＰサーバ１０１が故障していると判断して処理を終了する（ステップＳ２２）。ヘッダー部分のステータスコードが200番台で、且つ、ボディ部分のステータスコードが200番台でない場合は、音声ＤＰサーバ１０２が故障、又は、ストレージ１０３が故障していると判断して処理を終了する（ステップＳ２４）。
【００５２】
以上説明したように本実施形態の死活監視システム１によれば、複数の異なる機能を持つサーバを組み合わせることでサービスを提供しているマルチサーバシステム１００のサーバ間の連携動作の正常性について監視することができる。
【００５３】
〔第２実施形態〕
次に、故障箇所を特定できるようにした本発明の第２実施形態の死活監視システム２について説明する。本実施形態の死活監視システム２は、死活監視システム１に対してマルチサーバシステム１００を構成する各サーバが、サービス要求信号に対するレスポンス信号に故障情報を付加するようにした点で異なる。
【００５４】
死活監視システム２は、死活監視装置２３０と、音声ＡＰサーバ２１０１と、音声ＤＢサーバ２１０２と、ストレージ２１０３とで構成される。音声ＡＰサーバ２１０１と、音声ＤＢサーバ２１０２と、ストレージ２１０３とでマルチサーバシステム２００を構成する。
【００５５】
音声ＡＰサーバ２１０１と音声ＤＢサーバ２１０２とストレージ２１０３とは、それぞれ故障情報付加部２１１１，２１１２，２１１３を具備する点で、上記（図３）の各サーバと異なる。故障情報付加部２１１１，２１１２，２１１３は、サービス要求信号に対するレスポンス信号のボディ部分に故障情報を付加する。なお、死活監視システム２の機能構成は、死活監視システム１の機能構成と同じであるので、その図示は省略する。
【００５６】
図９に、音声ＤＢサーバ２１０２が故障した場合の死活監視システム２の動作シーケンスを示す。音声ＤＢサーバ２１０２が故障した場合の動作シーケンスは、上記の例（図５）と同じであり、音声ＤＢサーバ２１０２からストレージ２１０３に対する音声データ取得要求（ステップＳ３）は実行されない。当然、ステップＳ３に対する反応もない（ステップＳ４）。
【００５７】
この場合、音声ＤＢサーバ２１０２の故障情報付加部２１１２は、サービス要求信号（ステップＳ１）に対するレスポンス信号のボディ部分に故障情報を付加する（ステップＳ１１）。故障情報が付加されたレスポンス信号は、音声ＡＰサーバ２１０１に送信される（ステップＳ１２）。
【００５８】
図１０に、故障情報を付加したレスポンス信号の例を示す。ボディ部分の１１行目、timestampの後に故障したサーバを識別する故障サーバＩＤ「voice-db-xxx」が付加されている。このレスポンス信号は、音声ＡＰサーバ２１０１からサービス要求信号（ステップＳ１）のレスポンス信号として、死活監視装置２３０に送信される（ステップＳ１３）。
【００５９】
このように、レスポンス信号に故障情報として故障サーバＩＤを含ませる。なお、故障情報としては、サーバを識別する識別子の他に、故障内容を表す情報を含めてもよい。例えば、「メモリが不足」等の故障情報を付加することで、より詳細にマルチサーバシステム１００の状態を監視することが可能になる。
【００６０】
なお、音声ＤＢサーバ２１０２の故障情報は、音声ＡＰサーバ２１０１で付加してもよい。例えば、音声ＡＰサーバ２１０１と音声ＤＢサーバ２１０２との間を接続するネットワークの障害が原因で、音声ＤＢサーバ２１０２からのレスポンス信号が得られない場合がある。その場合は、音声ＡＰサーバ２１０１でタイムアウトを検出し、音声ＡＰサーバ２１０１の故障情報付加部２１１１で、音声ＤＢサーバ２１０２の故障情報を付加するようにしてもよい（ステップＳ１４）。
【００６１】
図１１に、ストレージ２１０３が故障した場合の死活監視システム２の動作シーケンスを示す。この場合、ストレージ２１０３は、音声データ取得要求に対するレスポンス信号のボディ部分に故障情報を付加（ステップＳ１５）して音声ＤＢサーバ２１０２に送信する（ステップＳ１６）。
【００６２】
図１２に、ステップＳ１５で付加した故障情報を含むレスポンス信号の例を示す。ボディ部分の１１行目に故障サーバＩＤ「strage-xxx」が付加されている。このレスポンス信号は、音声ＤＢサーバ２１０２と音声ＡＰサーバ２１０１とを介して、死活監視装置２３０に送信される（ステップＳ１７，Ｓ１８）。ストレージ２１０３の故障情報は、音声ＤＢサーバ２１０２の故障情報と同様に、音声ＤＢサーバ２１０２の故障情報付加部２１１２で付加するようにしてもよい（ステップＳ１８）。故障情報が付加されたレスポンス信号を受信した死活監視装置２３０は、より詳しく死活監視処理（ステップＳ３０）を行うことができる。
【００６３】
図１３を参照してその死活監視処理（ステップＳ３０）を説明する。レスポンス信号のヘッダー部分のステータスコードが200番台（ステップＳ２１のYES）で、ボディ部分のステータスコードが200番台でない場合（ステップＳ２３のNO）の処理が上記の動作フロー（図８）と異なる。
【００６４】
死活監視装置２３０は、レスポンス信号のボディ部分の故障情報を参照する（ステップＳ３１）。故障情報を表す故障サーバＩＤが「voice-db」の場合、死活監視装置２３０は音声ＤＢサーバ２１０２が故障していると判断して処理を終了する（ステップＳ３２）。故障サーバＩＤが「strage」の場合、死活監視装置２３０はストレージ２１０３が故障していると判断して処理を終了する（ステップＳ３３）。
【００６５】
以上説明したように本実施形態の死活監視システム２によれば、マルチサーバシステム１００の故障箇所を特定することができる。なお、本発明は上記の実施形態に限定されない。本実施形態のマルチサーバシステム１００は、安否確認システムを例に説明したが、複数の異なる機能を持つサーバを組み合わせてサービスを提供するものであれば、他のマルチサーバシステムであってもよい。
【００６６】
また、HTTPレスポンス信号を例にして説明したが、他のプロトコルの例えばＳＩＰ（Session Initiation Protocol）に基づく通信に、本発明を適用することも可能である。このように本発明は、上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【００６７】
なお、上記装置（サーバ）をコンピュータによって実現する場合、各装置が有すべき機能の処理内容はプログラムによって記述される。そして、このプログラムをコンピュータで実行することにより、各装置における処理部がコンピュータ上で実現される。
【００６８】
また、このプログラムの流通は、例えば、そのプログラムを記録したＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体を販売、譲渡、貸与等することによって行う。さらに、このプログラムをサーバコンピュータの記録装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することにより、このプログラムを流通させる構成としても良い。
【００６９】
また、各手段は、コンピュータ上で所定のプログラムを実行させることにより構成することにしてもよいし、これらの処理内容の少なくとも一部をハードウェア的に実現することとしても良い。
【符号の説明】
【００７０】
１：死活監視システム
１０１〜１０ｎ：サーバ
２０  ：ロードバランサ
３０  ：死活監視装置
３１  ：死活監視要求送信部
３２  ：死活監視部
１００：マルチサーバシステム
【図１】
2016148973.tif 000003
【図２】
2016148973.tif 000004
【図３】
2016148973.tif 000005
【図４】
2016148973.tif 000006
【図５】
2016148973.tif 000007
【図６】
2016148973.tif 000008
【図７】
2016148973.tif 000009
【図８】
2016148973.tif 000010
【図９】
2016148973.tif 000011
【図１０】
2016148973.tif 000012
【図１１】
2016148973.tif 000013
【図１２】
2016148973.tif 000014
【図１３】
2016148973.tif 000015