特許 6309711 プロセス監視プログラム及びプロセス監視システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6309711

(24)【登録日】2018年3月23日

(45)【発行日】2018年4月11日

(54)【発明の名称】プロセス監視プログラム及びプロセス監視システム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20180402BHJP

   G06F 11/20 20060101ALI20180402BHJP

【ＦＩ】

   G06F11/07 157

   G06F11/20

【請求項の数】6

【全頁数】12

(21)【出願番号】特願2013-53142(P2013-53142)

(22)【出願日】2013年3月15日

(65)【公開番号】特開2014-178947(P2014-178947A)

(43)【公開日】2014年9月25日

【審査請求日】2015年12月4日

【審判番号】不服2017-2660(P2017-2660/J1)

【審判請求日】2017年2月24日

(73)【特許権者】

【識別番号】598049322

【氏名又は名称】株式会社三菱東京ＵＦＪ銀行

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(72)【発明者】

【氏名】山岡 真之

【合議体】

【審判長】 石井 茂和

【審判官】 山崎 慎一

【審判官】 須田 勝巳

(56)【参考文献】

【文献】 特表２００７−５１５７１１号公報

【文献】 特開平８−２９７５８７号公報

【文献】 国際公開第２００８／１０５０３１号

【文献】 竹田 義浩，企業ユーザーの悩みを解決 トラブルに強いネットワーク構築法，日経コミュニケーション，日本，日経ＢＰ社，２００７年１０月１日，第４９５号，ｐ．１２０−１２３，ＩＳＳＮ：０９１０−７２１５

【文献】 特開２００６−３５０６９４号公報

【文献】 特開２０１１−２５３４７５号公報

【文献】 特開２００２−３３０１９１号公報

(58)【調査した分野】（Int.Cl.，ＤＢ名）

G06F11/07,11/16-11/20

(57)【特許請求の範囲】

【請求項1】

監視対象のプロセスに対して、１組のプロセス監視電文の各プロセス監視電文を微小時間差で発信するステップと、
前記１組のプロセス監視電文に対する応答の受信状態に基づき、前記プロセスが故障状態であるか判定するステップと、
をコンピュータに実行させるプロセス監視プログラム。

【請求項2】

前記判定するステップは、前記１組のプロセス監視電文に対する応答が所定の受信時間内に受信されたか判定し、前記１組のプロセス監視電文に対する応答のうち所定数以上の応答が前記所定の受信時間内に受信されなかった場合、前記プロセスが故障状態であると判定する、請求項１記載のプロセス監視プログラム。

【請求項3】

前記判定するステップは、前記１組のプロセス監視電文に対する応答がＮＧ応答であるか判定し、前記１組のプロセス監視電文に対する応答のうち所定数以上の応答がＮＧ応答であった場合、前記プロセスが故障状態であると判定する、請求項１記載のプロセス監視プログラム。

【請求項4】

当該プロセス監視プログラムはさらに、前記プロセスが故障状態であると判定すると、前記プロセスによる処理を停止し、前記プロセスに代替するプロセスによって前記処理を続行させるステップを前記コンピュータに実行させる、請求項１乃至３何れか一項記載のプロセス監視プログラム。

【請求項5】

前記判定するステップは、前記プロセスの特性、テイクオーバに係るコストの１つ以上に基づき設定された前記１組のプロセス監視電文に対する応答の受信状態に基づき、前記プロセスが故障状態であるか判定する、請求項１乃至４何れか一項記載のプロセス監視プログラム。

【請求項6】

監視対象のプロセスに対して、１組のプロセス監視電文の各プロセス監視電文を微小時間差で発信する発信部と、
前記１組のプロセス監視電文に対する応答を受信する受信部と、
前記応答の受信状態に基づき、前記プロセスが故障状態であるか判定する判定部と、を有するプロセス監視システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理システムにおけるプロセス監視に関する。

【背景技術】

【0002】

近年、クライアント・サーバシステムにおいて、サーバからクライアントに各種サービスが提供されている。これらのサービスを適切に提供するため、サーバ上で実行される各種プロセスは、プロセス監視システムなどにより監視されている。例えば、サーバ上の各プロセスが適切に起動されているか判定するため、プロセス監視システムは、各プロセスに対して定期的に生死判定を実行している。例えば、この生死判定は、プロセス監視システムが監視対象のサーバに定期的にメッセージを送信し、当該メッセージに対する正常応答（ＯＫ応答）がタイムアウト時間内に受信できたかに基づき行われる。生死判定の結果として、プロセスが正常に動作していないことが検出されると（例えば、ＮＧ応答を受信した場合、あるいは、タイムアウト時間内に応答を受信できなかった場合）、プロセス監視システムは、当該プロセスを他のサーバに切り替える（テイクオーバ）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００６−１４６３１９

【特許文献2】特開平１０−１５４０８５

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、クライアント・サーバシステムの複雑化に伴って、誤った生死判定が行われることがある。例えば、サーバ上で正常に動作するプロセスに対する応答がＮＧ応答として返信されたり、あるいは、タイムアウト時間内にプロセス監視システムにＯＫ応答が到達しないなどによって、正常に動作しているプロセスが、正常に動作していないと誤判定されることがある。

【0005】

このような誤判定は、典型的には、各プログラムにおけるバグに起因するものであるため、プログラム提供元によって当該バグは修正される。しかしながら、サーバ上で実行されるミドルウェアが増加するに従って、多数のミドルウェアが混在するシステム環境に依拠したバグなどに起因して、低い生起確率ではあるものの、このような誤判定が偶発的に発生する事象が出現するようになってきている。このタイプのバグは、人為的に再発生させることが困難であり、プログラム提供元による修正は期待することができないかもしれない。このような誤判定に基づきテイクオーバが実行されると、テイクオーバに伴う時間や人手の浪費、テイクオーバ中のサービスの中断など様々な問題が生じる。

【0006】

上記問題点を鑑み、本発明の課題は、偶発的に出現するバグに起因したプロセス生死判定における誤判定を低減するためのプロセス監視技術を提供することである。

【課題を解決するための手段】

【0007】

上記課題を解決するため、本発明の一態様は、監視対象のプロセスに対して、１組のプロセス監視電文の各プロセス監視電文を第１時間内に異なる発信タイミングで発信するステップと、前記１組のプロセス監視電文に対する応答の受信状態に基づき、前記プロセスが故障状態であるか判定するステップとをコンピュータに実行させるプロセス監視プログラムに関する。

【0008】

本発明の他の態様は、監視対象のプロセスに対して、１組のプロセス監視電文の各プロセス監視電文を第１時間内に異なる発信タイミングで発信する発信部と、前記１組のプロセス監視電文に対する応答を受信する受信部と、前記応答の受信状態に基づき、前記プロセスが故障状態であるか判定する判定部とを有するプロセス監視システムに関する。

【発明の効果】

【0009】

本発明によると、偶発的に出現するバグに起因したプロセス生死判定における誤判定を低減すると共に、タイムアウトを待つことなく故障を検知して迅速にテイクオーバを開始することができる。

【図面の簡単な説明】

【0010】

【図1】図１は、本発明の一実施例による情報処理システムを示す概略図である。

【図2】図２は、本発明の一実施例によるプロセス監視システムのハードウェア構成を示すブロック図である。

【図3】図３は、本発明の一実施例によるプロセス監視システムの機能構成を示すブロック図である。

【図4】図４は、本発明の一実施例によるプロセス監視システムにおける処理を示すフロー図である。

【発明を実施するための形態】

【0011】

以下、図面に基づいて本発明の実施の形態を説明する。

【0012】

後述される実施例では、偶発的に出現するバグに起因したプロセス生死判定における誤判定を低減するためのプロセス監視システムが開示される。プロセス監視システムは、サーバ上で実行される監視対象のプロセスに対して、１組のプロセス監視電文の各プロセス監視電文を第１時間内に異なる発信タイミングで発信する。一実施例では、サーバ上の各プロセスに対して２つのプロセス監視電文が微小時間差（例えば、数百ミリ秒の時間差など）で発信される。当該プロセス監視電文を受信すると、各プロセスは、正常動作している場合には正常応答（ＯＫ応答）をプロセス監視システムに返し、他方、正常動作していない場合にはＮＧ応答をプロセス監視システムに返すか、あるいは、タイムアウト時間内に応答自体を返さない。このように、送信した１組のプロセス監視電文に対する応答の受信状態に基づき、プロセス監視システムは、当該プロセスが故障状態であるか判定し、判定結果に応じて他のサーバにテイクオーバする。

【0013】

このように複数個のプロセス監視電文を異なる送信タイミングで送信し、これらの応答結果に基づき生死判定を行うことによって、低い確率で偶発的に発生するようなバグに起因した誤判定を回避することが可能になる。このようなバグは、様々な要因があるタイミングで偶然に一致したことにより発生することが多く、それ以外のタイミングでは誤判定が発生する可能性は極めて低いためである。これにより、誤った生死判定に基づくテイクオーバ、これに伴うネットワークの瞬断やサービスの停止などを回避することが可能になると共に、プロセスが故障状態であるときには、タイムアウトを待つことなく故障を検知して迅速にテイクオーバを開始することができる。

【0014】

まず、図１を参照して、本発明の一実施例による情報処理システムを説明する。情報処理システムは、例えば、クライアント・サーバシステムであり、クライアントからの要求に応答して、サーバが各種サービスを提供する。本実施例では、情報処理システムは、高い可用性（ａｖａｉｌａｂｉｌｉｔｙ）が要求されるシステムに好適であり、稼働中のサーバにおける障害の発生に応答した予備のサーバへの切り替え（テイクオーバ又はフェイルオーバ）やサービスの中断を最小限に抑えると共に、障害が発生している場合には迅速にテイクオーバを開始するよう設計される。

【0015】

図１は、本発明の一実施例による情報処理システムを示す概略図である。図１に示されるように、情報処理システム１０は、プロセス監視システム１００、サーバ２０１，２０２、データベース（ＤＢ）２５０及び端末装置３００を有する。図示される実施例では、サーバ２０１が稼働中のサーバであり、サーバ２０２が、サーバ２０１の予備のサーバである。

【0016】

プロセス監視システム１００は、稼働中のサーバ２０１において実行されている各プロセスを監視する。以下で詳細に説明されるように、プロセス監視システム１００は、サーバ２０１において実行されている各プロセスに複数の生死監視メッセージを異なる送信タイミングで発信し、当該生死監視メッセージに対する各プロセスからの応答の受信結果に基づき、当該プロセスが正常に作動しているか、又は障害が発生しているか判定する。障害が発生していると判定すると、プロセス監視システム１００は、当該プロセスに対して稼働中のサーバ２０１を予備のサーバ２０２に切り替える（テイクオーバ又はフェイルオーバ）。

【0017】

サーバ２０１は、稼働中のサーバであり、クライアントである端末装置３００に各種サービスを提供する。一実施例では、端末装置３００から処理要求を受信すると、サーバ２０１は、当該処理に関連するデータをデータベース２５０から取得し、取得したデータに対して要求された処理を実行し、処理結果を端末装置３００に返す。これらの処理を実行するため、サーバ２０１内ではオペレーティングシステム（ＯＳ）、ミドルウェア、アプリケーションなどの各種プログラムが起動され、これらのプログラムに関して各種プロセスが実行されている。各プロセスは、プロセス監視システム１００から送信される生死監視メッセージに対して、当該プロセスが正常に動作している場合には正常応答（ＯＫ応答）を返し、当該プロセスが正常に動作していない場合にはＮＧ応答を返すか、あるいは、故障のため応答自体を返さない。

【0018】

サーバ２０２は、稼働中のサーバ２０１の予備のサーバであり、サーバ２０１に障害が発生すると、プロセス監視システム１００からのテイクオーバ指示に応答して、サーバ２０１の代わりに対応するプロセスを起動する。典型的には、このテイクオーバには、１０〜１５分などの時間を要することもあり、テイクオーバ実行中は端末装置３００へのサービスの提供が一時的に中断されることもある。このため、特に高い可用性が要求される情報処理システム１０では、テイクオーバの実行は最小限に抑えられるべきである。

【0019】

データベース２５０は、端末装置３００からの各種処理要求を実行するのに必要な各種データを格納する。例えば、これらのデータは、サーバ２０１，２０２において起動されるデータベースミドルウェアを介し取得及び操作される。

【0020】

端末装置３００は、情報処理システム１０におけるクライアント装置であり、典型的には、デスクトップコンピュータ、ノートブックコンピュータなどの情報端末により実現される。端末装置３００は、稼働中のサーバ２０１に各種処理要求を送信し、サーバ２０１による処理結果を受信する。サーバ２０１のプロセスに障害が検出され、サーバ２０２へのテイクオーバが実行されると、端末装置３００は、サーバ２０２とのやりとりを開始する。

【0021】

次に、図２〜３を参照して、本発明の一実施例によるプロセス監視システムを説明する。プロセス監視システム１００は、上述したように、サーバ２０１上で実行される監視対象のプロセスに対して、１組のプロセス監視電文の各プロセス監視電文を所定の送信時間内に異なる発信タイミングで発信し、送信した１組のプロセス監視電文に対する応答の受信状態（例えば、所定の受信時間内に応答を受信したか否か、受信した応答がＯＫ応答であるか否かなど）に基づき、当該プロセスが故障状態であるか判定する。プロセス監視システム１００は、当該判定結果に応じて、当該プロセスに対するサーバ２０２へのテイクオーバを実行する。

【0022】

図２は、本発明の一実施例によるプロセス監視システムのハードウェア構成を示すブロック図である。図２に示されるように、プロセス監視システム１００は、バスＢを介し相互接続されるドライブ装置１０１、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０４、インタフェース装置１０５及びタイマ１０６を有する。

【0023】

プロセス監視システム１００における後述される各種機能及び処理を実現するプロセス監視プログラムを含む各種プログラムは、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）などの記録媒体１０７によって提供されてもよい。プログラムを記憶した記録媒体１０７がドライブ装置１０１にセットされると、プログラムが記録媒体１０７からドライブ装置１０１を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０７により行う必要はなく、ネットワーク（図示せず）を介し何れかの外部装置からダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータなどを格納する。

【0024】

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムやデータを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムやプログラムを実行するのに必要なパラメータなどの各種データに従って、後述されるようなプロセス監視システム１００の各種機能及び処理を実行する。インタフェース装置１０５は、ネットワーク又は外部装置に接続するための通信インタフェースとして用いられる。タイマ１０６は、計時手段として備えられる。

【0025】

しかしながら、プロセス監視システム１００は、上述したハードウェア構成に限定されるものでなく、例えば、サーバ、パーソナルコンピュータ、モバイル装置などの何れか適切な情報処理装置により実現されてもよい。

【0026】

図３は、本発明の一実施例によるプロセス監視システムの機能構成を示すブロック図である。図３に示されるように、プロセス監視システム１００は、発信部１１０、受信部１２０、判定部１３０及び移行指示部１４０を有する。

【0027】

発信部１１０は、サーバ２０１の監視対象のプロセスに対して、１組のプロセス監視電文の各プロセス監視電文を所定の送信時間内に異なる発信タイミングで発信する。一実施例では、発信部１１０は、各プロセスに対して２個のプロセス監視電文を微小時間差（例えば、数百ミリ秒など）で二重化又は重複化して送信する。当該所定の送信時間は、これに限定されるものでないが、少なくともタイムアウト時間より短い時間に設定される。なお、プロセス監視電文の各組毎の送信は、典型的には、当該送信時間より長い間隔で定期的に行われる。

【0028】

受信部１２０は、発信部１１０により発信された１組のプロセス監視電文に対する応答を受信する。プロセス監視電文の対象となるプロセスが正常に動作している場合、正常応答（ＯＫ応答）が受信部１２０に返される。他方、プロセス監視電文の対象となるプロセスが正常に動作していない場合、ＮＧ応答が受信部１２０に返される。あるいは、プロセス監視電文の対象となるプロセスが正常に動作していない場合、応答自体が受信部１２０に返されない可能性もある。

【0029】

判定部１３０は、１組のプロセス監視電文の各プロセス監視電文に対する応答の受信状態に基づき、監視対象のプロセスが故障状態であるか判定する。監視対象のプロセスが故障状態であると判定すると、判定部１３０は、当該プロセスが故障状態であることを移行指示部１４０に通知する。

【0030】

一実施例では、判定部１３０は、送信した１組のプロセス監視電文に対する応答が所定の受信時間（例えば、タイムアウト時間など）内に受信されたか判定し、これらの応答のうち所定数以上の応答が所定の受信時間内に受信されなかった場合、当該プロセスが故障状態であると判定する。一例として、当該受信時間は、各プロセス監視電文の発信時刻から受信時刻までの時間と対比されてもよい。すなわち、送信した複数個のプロセス監視電文のうち所定数以上のプロセス監視電文の発信時刻から受信時刻までの時間が、タイムアウト値などの所定の受信時間を超過した場合、判定部１３０は、当該プロセスが故障状態であると判定する。典型的には、当該所定の受信時間は、タイムアウト値に設定され、上述した所定の送信時間（微小時間）より長く設定される。

【0031】

一例として、発信部１１０が１組のプロセス監視電文として２個のプロセス監視電文を異なる送信タイミングで発信した場合、判定部１３０は、これら２個のプロセス監視電文に対する２個の応答の双方が所定の受信時間（タイムアウト時間）内に受信されなかった場合、当該プロセスが故障状態であると判定してもよい。すなわち、第１プロセス監視電文に対する応答が第１プロセス監視電文の発信時刻から所定の受信時間内に受信されず、かつ、第２プロセス監視電文に対する応答が第２プロセス監視電文の発信時刻から所定の受信時間内に受信されなかった場合、当該プロセスが故障状態であると判定してもよい。

【0032】

他の例として、発信部１１０が１組のプロセス監視電文として２個のプロセス監視電文を異なる送信タイミングで発信した場合、判定部１３０は、これら２個のプロセス監視電文に対する２個の応答の何れか一方が所定の受信時間内に受信されなかった場合、当該プロセスが故障状態であると判定してもよい。すなわち、第１プロセス監視電文に対する応答が第１プロセス監視電文の発信時刻から所定の受信時間内に受信されなかったか、又は、第２プロセス監視電文に対する応答が第２プロセス監視電文の発信時刻から所定の受信時間内に受信されなかった場合、当該プロセスが故障状態であると判定してもよい。

【0033】

何れの判定基準を使用するかは、情報処理システム１０の実施形態に応じて決定されてもよい。一実施例では、判定基準は、当該プロセスの特性、テイクオーバに係るコスト、誤判定を生じさせるバグの発生頻度の１以上などに基づき決定されてもよい。

【0034】

例えば、当該プロセスに代替的な他のプロセスが正常に動作している場合、判定部１３０は、２個の応答の双方が所定の受信時間内に受信されなかったことに応答して、当該プロセスが故障状態であると判定してもよい。他方、当該プロセスに代替的な他のプロセスがない場合、判定部１３０は、２個の応答の何れか一方が所定の受信時間内に受信されなかったことに応答して、当該プロセスが故障状態であると判定してもよい。これは、当該プロセスがかなりの精度で故障状態である場合でも、代替プロセスが当該プロセスを代替して処理を実行するため、即座にテイクオーバする必要がないためである。

【0035】

また、テイクオーバに係るコスト（例えば、テイクオーバに要する時間、サーバ２０１の可用性など）が大きい場合、判定部１３０は、２個の応答の双方が所定の受信時間内に受信されなかったことに応答して、当該プロセスが故障状態であると判定してもよい。他方、テイクオーバに係るコストがそれほど大きくない場合、判定部１３０は、２個の応答の何れか一方が所定の受信時間内に受信されなかったことに応答して、当該プロセスが故障状態であると判定してもよい。テイクオーバに係るコストを勘案して、テイクオーバの要否を決定することが可能になる。

【0036】

また、誤判定を生じさせるバグの発生頻度が高いと推定される場合、判定部１３０は、２個の応答の双方が所定の受信時間内に受信されなかったことに応答して、当該プロセスが故障状態であると判定してもよい。他方、誤判定を生じさせるバグの発生頻度が低いと推定される場合、判定部１３０は、２個の応答の何れか一方が所定の受信時間内に受信されなかったことに応答して、当該プロセスが故障状態であると判定してもよい。これにより、誤判定によるテイクオーバの実行を低減することが可能になる。

【0037】

なお、発信部１１０が１組のプロセス監視電文として２個のプロセス監視電文を異なる送信タイミングで発信した場合、判定部１３０は、これら２個のプロセス監視電文に対する２個の応答の何れか一方が所定の受信時間内に受信されなかったことに応答して、当該プロセスが故障状態であると判定する前に、発信部１１０にリトライさせるようにしてもよい。例えば、判定部１３０は、当該プロセスに対して２個のプロセス監視電文を異なる発信タイミングで再送するよう発信部１１０に指示してもよい。

【0038】

他の実施例では、判定部１３０は、送信した１組のプロセス監視電文に対する応答がＮＧ応答であるか判定し、当該応答のうち所定数以上の応答がＮＧ応答であった場合、当該プロセスが故障状態であると判定してもよい。

【0039】

一例として、発信部１１０が１組のプロセス監視電文として２個のプロセス監視電文を異なる送信タイミングで発信した場合、判定部１３０は、これら２個のプロセス監視電文に対する２個の応答の双方がＮＧ応答である場合、当該プロセスが故障状態であると判定してもよい。他の例として、発信部１１０が１組のプロセス監視電文として２個のプロセス監視電文を異なる送信タイミングで発信した場合、判定部１３０は、これら２個のプロセス監視電文に対する２個の応答の何れか一方がＮＧ応答である場合、当該プロセスが故障状態であると判定してもよい。

【0040】

何れの判定基準を使用するかは、情報処理システム１０の実施形態や故障の推定精度に応じて決定されてもよい。一実施例では、判定基準は、当該プロセスの特性、テイクオーバに係るコスト、誤判定を生じさせるバグの発生頻度の１以上などに基づき決定されてもよい。

【0041】

例えば、当該プロセスに代替的な他のプロセスが正常に動作している場合、判定部１３０は、２個の応答の双方がＮＧ応答であったことに応答して、当該プロセスが故障状態であると判定してもよい。他方、当該プロセスに代替的な他のプロセスがない場合、判定部１３０は、２個の応答の何れか一方がＮＧ応答であったことに応答して、当該プロセスが故障状態であると判定してもよい。また、テイクオーバに係るコスト（例えば、テイクオーバに要する時間、サーバ２０１の可用性など）が大きい場合、判定部１３０は、２個の応答の双方がＮＧ応答であったことに応答して、当該プロセスが故障状態であると判定してもよい。他方、テイクオーバに係るコストがそれほど大きくない場合、判定部１３０は、２個の応答の何れか一方がＮＧ応答であったことに応答して、当該プロセスが故障状態であると判定してもよい。また、誤判定を生じさせるバグの発生頻度が高いと推定される場合、判定部１３０は、２個の応答の双方がＮＧ応答であったことに応答して、当該プロセスが故障状態であると判定してもよい。他方、誤判定を生じさせるバグの発生頻度が低いと推定される場合、判定部１３０は、２個の応答の何れか一方がＮＧ応答であったことに応答して、当該プロセスが故障状態であると判定してもよい。

【0042】

なお、発信部１１０が１組のプロセス監視電文として２個のプロセス監視電文を異なる送信タイミングで発信した場合、判定部１３０は、これら２個のプロセス監視電文に対する２個の応答の何れか一方がＮＧ応答であったことに応答して、当該プロセスが故障状態であると判定する前に、発信部１１０にリトライさせるようにしてもよい。例えば、判定部１３０は、当該プロセスに対して２個のプロセス監視電文を異なる送信タイミングで再送するよう発信部１１０に指示してもよい。

【0043】

さらなる他の実施例では、上述した実施例を組み合わせ、判定部１３０は、送信した１組のプロセス監視電文に対する応答が所定の受信時間（例えば、タイムアウト時間など）内に受信されたか判定すると共に、送信した１組のプロセス監視電文に対する応答がＮＧ応答であるか判定し、これらの応答のうち所定数以上の応答が所定の受信時間内に受信されなかった場合及び／又は当該応答のうち所定数以上の応答がＮＧ応答であった場合、当該プロセスが故障状態であると判定してもよい。

【0044】

また、さらなる他の実施例では、判定部１３０は、送信した１組のプロセス監視電文を送信するのに要した時間と、当該プロセス監視電文に対する応答を受信するのに要した時間とを対比し、送信に要した時間より受信に要した時間が所定の閾値以上である場合、当該プロセスが故障状態であると判定してもよい。一般に、１組のプロセス監視電文を送信するのに要した時間、すなわち、最初のプロセス監視電文を送信してから最後のプロセス監視電文を送信するまでの時間は、送信したプロセス監視電文に対する最初の応答を受信してから最後の応答を受信するまでの時間に概ね等しくなると考えられる。従って、プロセス監視電文に対する最初の応答を受信してから最後の応答を受信するまでの時間が、最初のプロセス監視電文を送信してから最後のプロセス監視電文を送信するまでの時間を大きく超過した場合、すなわち、最初のプロセス監視電文を送信してから最後のプロセス監視電文を送信するまでの時間を所定の閾値以上超過した場合、判定部１３０は、当該プロセスが故障状態であると判定してもよい。ここで、タイムアウト時間内に応答を受信できなかったプロセス監視電文がある場合、受信できた応答のみを考慮してプロセス監視電文に対する応答を受信するのに要した時間を算出し、当該プロセスが故障状態であるか判定してもよい。また、タイムアウト時間内に受信できなかったプロセス監視電文の個数を計数し、その個数が所定数以上である場合、プロセス監視電文に対する応答を受信するのに要した時間に関係なく、当該プロセスが故障状態であると判定してもよい。

【0045】

移行指示部１４０は、監視対象のプロセスが故障状態であると判定されると、当該プロセスによる処理を停止し、当該プロセスに代替するプロセスによって処理を続行させる。一実施例では、移行指示部１４０は、故障状態であると判定されたサーバ２０１のプロセスを、予備のサーバ２０２の代替プロセスに切り替え（テイクオーバ）、当該代替プロセスにより当該処理を続行させる。

【0046】

次に、図４を参照して、本発明の一実施例によるプロセス監視システムにおける処理を説明する。図４は、本発明の一実施例によるプロセス監視システムにおける処理を示すフロー図である。

【0047】

図４に示されるように、ステップＳ１０１において、プロセス監視システム１００は、１組のプロセス監視電文の各プロセス監視電文を所定の送信時間内に異なる送信タイミングで発信する。例えば、各プロセス監視電文は、所定の時間差（例えば、数百ミリ秒など）で発信されてもよい。なお、プロセス監視電文の各組は、所定の間隔で定期的に送信される。

【0048】

ステップＳ１０２において、プロセス監視システム１００は、テイクオーバの要否判定を実行する。すなわち、プロセス監視システム１００は、ステップＳ１０１において送信した複数個のプロセス監視電文の各応答の受信状態に基づき、所定の判定基準に従って当該プロセスが故障状態であるか否かを判定するテイクオーバ要否判定を実行する。一実施例では、テイクオーバ要否判定は、ステップＳ１０１において送信した複数個のプロセス監視電文に対する各応答が所定の受信時間（例えば、タイムアウト時間など）内に受信されたか判定することであってもよい。他の実施例では、テイクオーバ要否判定は、ステップＳ１０１において送信した複数個のプロセス監視電文に対する各応答がＮＧ応答であるか判定することであってもよい。さらなる他の実施例では、テイクオーバ要否判定は、ステップＳ１０１において送信した複数個のプロセス監視電文に対する各応答が所定の受信時間（例えば、タイムアウト時間など）内に受信されたか判定すると共に、当該受信したプロセス監視電文に対する各応答がＮＧ応答であるか判定することであってもよい。

【0049】

ステップＳ１０３において、プロセス監視システム１００は、テイクオーバが必要であるか判定する。ステップＳ１０２において実行されたテイクオーバ要否判定に対応して、テイクオーバが必要であるか判定する。例えば、テイクオーバ要否判定が複数個のプロセス監視電文に対する各応答が所定の受信時間（例えば、タイムアウト時間など）内に受信されたか判定することである場合、プロセス監視システム１００は、当該プロセス監視電文に対する応答のうち所定数以上の応答が所定の時間内に受信されなかったことに応答して、テイクオーバを実行する必要があると判定してもよい。また、テイクオーバ要否判定が複数個のプロセス監視電文に対する各応答がＮＧ応答であるか判定することである場合、プロセス監視システム１００は、当該プロセス監視電文に対する応答のうち所定数以上の応答がＮＧ応答であったことに応答して、テイクオーバを実行する必要があると判定してもよい。さらに、テイクオーバ要否判定が複数個のプロセス監視電文に対する各応答が所定の受信時間内に受信されたか判定すると共に、当該受信したプロセス監視電文に対する各応答がＮＧ応答であるか判定することである場合、プロセス監視システム１００は、当該プロセス監視電文に対する応答のうち所定数以上の応答が所定の受信時間内に受信されず、また、当該受信したプロセス監視電文に対する応答のうち所定数以上の応答がＮＧ応答であったことに応答して、テイクオーバを実行する必要があると判定してもよい。

【0050】

テイクオーバが必要であると判定されると（ステップＳ１０３：Ｙ）、ステップＳ１０４において、プロセス監視システム１００は、サーバ２０１における当該プロセスに対してテイクオーバを実行し、サーバ２０２の代替プロセスを起動することによって、当該プロセスに係る処理を続行する。他方、テイクオーバが必要でないと判定されると（ステップＳ１０３：Ｎ）、プロセス監視システム１００は、所定の間隔の経過後にステップＳ１０１を再開する。

【0051】

以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【符号の説明】

【0052】

１０ 情報処理システム
１００ プロセス監視システム
１１０ 発信部
１２０ 受信部
１３０ 判定部
１４０ 移行指示部
２０１，２０２ サーバ
２５０ データベース
３００ 端末装置

【図1】

【図2】

【図3】

【図4】