複数のアプリケーションプログラムに基づき処理を実行する複数のプロセスのそれぞれについて、プロセスの特性を表す特性情報を収集する収集部と、前記複数のプロセスのうちのあるプロセスに関する特性情報が、前記複数のプロセスのうち、前記あるプロセスを除いたプロセスのいずれの特性情報とも特性が異なる場合に、前記あるプロセスについて異常が発生したと判断する判断部とを含むことを特徴とする情報処理装置。前記情報処理装置が、更に、クライアントからのリクエストを前記複数のプロセスに振分ける振分け部を含み、前記判断部が、前記1又は複数のプロセスについて異常が発生したと判断する場合に、前記複数のプロセスと同じ数の代替プロセスを起動して、前記リクエストを前記代替プロセスに振分けるように前記振分け部に通知することを特徴とする請求項1に記載の情報処理装置。前記情報処理装置が、更に、前記判断部が前記リクエストを前記代替プロセスに振分けるように前記振分け部に通知した後に、前記複数のプロセスをチェックするチェック部を含むことを特徴とする請求項1に記載の情報処理装置。前記特性情報は、プロセスが実行した処理の結果が所定の処理結果であった回数を示す情報又はプロセスが使用する所定の資源の使用量についての情報であることを特徴とする請求項1に記載の情報処理装置。前記特性情報は、前記複数のプロセスが通信を行う場合のプロトコルであるHTTPにおけるステータスコード200以外のステータスコードが発生した回数であることを特徴とする請求項4に記載の情報処理装置。監視プロセスが、複数のアプリケーションプログラムに基づき処理を実行する複数のプロセスのそれぞれについて、プロセスの特性を表す特性情報を収集し、前記監視プロセスが、前記複数のプロセスのうちのあるプロセスに関する特性情報が、前記複数のプロセスのうち、前記あるプロセスを除いたプロセスのいずれの特性情報とも特性が異なる場合に、前記あるプロセスについて異常が発生したと判断することを特徴とするプロセス監視方法。プロセスを監視するプロセス監視プログラムであって、前記プログラムは、コンピュータに、複数のアプリケーションプログラムに基づき処理を実行する複数のプロセスのそれぞれについて、プロセスの特性を表す特性情報を収集する処理と、前記複数のプロセスのうちのあるプロセスに関する特性情報が、前記複数のプロセスのうち、前記あるプロセスを除いたプロセスのいずれの特性情報とも特性が異なる場合に、前記あるプロセスについて異常が発生したと判断する処理とを、実行させることを特徴とするプロセス監視プログラム。プロセスを監視するプロセス監視プログラムを記録する記録媒体であって、前記プロセス監視プログラムは、コンピュータに、複数のアプリケーションプログラムに基づき処理を実行する複数のプロセスのそれぞれについて、プロセスの特性を表す特性情報を収集する処理と、前記複数のプロセスのうちのあるプロセスに関する特性情報が、前記複数のプロセスのうち、前記あるプロセスを除いたプロセスのいずれの特性情報とも特性が異なる場合に、前記あるプロセスについて異常が発生したと判断する処理とを、実行させることを特徴とする記録媒体。例えば、アプリケーションの障害等の何らかの異常が発生しているプロセスが存在する場合において、異常が発生しているプロセスのヒープ領域の使用量が、閾値を超えない可能性がある。この場合には、ヒープ領域の使用量の閾値を用いても、プロセスが異常終了する可能性を検出することはできない。また、コンピュータのハードウェア情報を監視し比較して異常を検出する場合には、コンピュータ単位でハードウェア情報が比較される。このため、業務アプリケーションに固有の異常は、検出することができない。本発明の一側面によれば、アプリケーションに起因してプロセスが異常終了する可能性を検出することを目的とする。開示される情報処理装置は、複数のアプリケーションプログラムに基づき処理を実行する複数のプロセスのそれぞれについて、プロセスの特性を表す特性情報を収集する収集部と、複数のプロセスのうちのあるプロセスに関する特性情報が、複数のプロセスのうち、あるプロセスを除いたプロセスのいずれの特性情報とも特性が異なる場合に、あるプロセスについて異常が発生したと判断する判断部とを含む。開示される情報処理装置の一側面によれば、アプリケーションに起因してプロセスが異常終了する可能性を検出することができる。プロセスにおける異常の種類によっては、異常検出のための閾値それ自体を決定することができない場合がある。この場合には、異常検出のための閾値を用いてプロセスが異常終了する可能性を検出することはできない。例えば、HTTPHypertextTransferProtocolにおいて、ステータスコード200OKが、クライアントからのリクエストは成功したことを示すコードとして規定されている。ステータスコードが200である場合は、クライアントからのリクエストに対するレスポンスと共にリクエストに応じた情報が返信される場合であり、正常復帰の場合である。しかし、実際には、200以外のステータスコードが発生する場合がある。換言すれば、正常復帰ではない場合が発生することがある。そこで、200以外のステータスコードが発生した場合には、異常が発生したコンピュータを情報処理システムから切り離すことが考えられる。しかし、この場合には、コンピュータそれ自体には異常がないにも拘らず、コンピュータの切離しが頻繁に発生する結果、実際の業務の実行に支障を生じる。従って、200以外のステータスコードが発生しても、コンピュータに異常が発生したと判断することは適切ではない。一方、200以外のステータスコードが多く発生する傾向がある場合、コンピュータの異常ではなく、業務アプリケーションのデータが破壊された等の異常が発生している可能性がある。しかし、200以外のステータスコードが発生する頻度は、通常、業務アプリケーション毎に異なり、個々の業務アプリケーションに特有の値をとる。換言すれば、種々の業務アプリケーションに共通の値として、200以外のステータスコードが発生する頻度を算出することができない。従って、種々の業務アプリケーションにおいて、共通に、200以外のステータスコードがある回数だけ発生したら異常であるという判断をすることができない。このため、200以外のステータスコードを用いて、異常検出のための妥当な閾値を定めることはできない。また、プロセスにおける異常の種類によっては、異常検出のための閾値を設定したとしても、プロセスが異常終了する可能性を検出することができない。例えば、複数の業務プロセスにリクエストが均等に振分けられ、かつ、リクエストに依存して使用する資源量が大きく変動しない場合、複数の業務プロセスは、各々、同じ資源量を消費するはずである。そこで、この場合には、資源の消費量を用いて、異常検出のための閾値を設定することが考えられる。しかし、アプリケーションの障害等の何らかの異常が発生した結果、特定の業務プロセスだけが大きく資源を消費する場合がある。そして、特定の業務プロセスだけが大きく資源を消費してはいるが、資源の消費量が異常検出のための閾値を超えない場合がある。この場合、異常検出のための閾値を設定しても、異常を検出することができない。なお、前述したように、異常が発生したコンピュータを情報処理システムから切り離す場合には、例えば、クラスタシステムのように、業務を実行するコンピュータとは別に代替のコンピュータが用意される。この場合、異常が発生した業務アプリケーションを実行していたコンピュータを停止して、代替のコンピュータによる業務アプリケーションの実行を開始する。これにより、業務アプリケーションの実行は継続される。しかし、異常が発生したコンピュータが停止されるため、異常が発生していた時のプロセス又は業務アプリケーションの状態を維持することができず、異常の原因が解明できない。開示される情報処理装置は、閾値を用いることなく、アプリケーションに起因してプロセスが異常終了する可能性を検出する。図1は、情報処理システムの一例を示す図である。情報処理システムは、例えばサーバクライアントシステムであり、アプリケーションサーバ1と、クライアント8と、ネットワーク9とを含む。アプリケーションサーバ1は、業務アプリケーション4を実行する、換言すれば、業務処理を実行するサーバ装置である。ネットワーク9は、例えばインターネットのようなネットワークである。クライアント8は、アプリケーションサーバ1に業務リクエストを送信して、業務アプリケーション4の実行を要求するクライアント装置である。例えば、アプリケーションサーバ1は、ネットワーク9を介して、クライアント8から業務リクエストを受信する。そして、アプリケーションサーバ1は、受信した業務リクエストにおいて指示された業務アプリケーション4を実行する。その後、アプリケーションサーバ1は、クライアント8からの業務リクエストに対するレスポンス及び業務リクエストに応じた情報、換言すれば、業務アプリケーション4の実行結果を、ネットワーク9を介して、クライアント8に送信する。アプリケーションサーバ1は、振分けプロセス2と、複数の業務プロセス3と、業務アプリケーション4と、複数の代替プロセス5と、業務アプリケーション6と、監視プロセス7とを含む。振分けプロセス2は、振分け処理を実行する振分け部であり、クライアント8からの業務リクエストを複数の業務プロセス3に振分ける。換言すれば、振分けプロセス2は、業務リクエストを業務プロセス3に送信して、当該業務リクエストの実行を業務プロセス3へ依頼する。具体的には、振分けプロセス2は、監視プロセス7から業務プロセス3の起動完了の通知を受信した場合に、クライアント8からの業務リクエストを受信する、換言すれば、受付ける。そして、振分けプロセス2は、受け付けた業務リクエストを複数の業務プロセス3の中のいずれの業務プロセス3へ振分けるかを判断する。この後、振分けプロセス2は、前記判断に基づいて、業務リクエストを業務プロセス3に振分ける、換言すれば、業務リクエストの実行を業務プロセス3に依頼する。業務リクエストは、例えば複数の業務プロセス3の各々へ、均等に振分けられる。また、振分けプロセス2は、監視プロセス7から代替プロセス5の起動完了の通知を受信した場合に、クライアント8から受け付けた業務リクエストを、代替プロセス5へ振分ける。換言すれば、振分けプロセス2は、監視プロセス7から代替プロセス5の起動完了の通知を受信した場合に、クライアント8から受け付けた業務リクエストを、その時点まで業務リクエストを振分けていた業務プロセス3へは振分けないようにする。これにより、業務プロセス3は、代替プロセス5に切り替えられる。振分けプロセス2は、例えば、業務の開始に先立って、予め定められた振分けプロセス2の起動コマンドを実行することにより起動される。具体的には、例えば、アプリケーションサーバ1の管理者が、アプリケーションサーバ1の入力装置から振分けプロセス2の起動コマンドを入力することにより、アプリケーションサーバ1に振分けプロセス2の起動コマンドを実行させる。業務プロセス3は、実際に業務の処理を実行する業務処理実行部であり、振分けプロセス2により振分けられたクライアント8からの業務リクエストを実行する。換言すれば、業務プロセス3は、受信した業務リクエストにおいて指示された処理を実行する。具体的には、業務プロセス3は、振分けプロセス2から業務リクエストを受信すると、受信した業務リクエストを実行する業務アプリケーション4を呼び出して、呼び出した業務アプリケーション4に業務リクエストにおいて指示された処理を実行させる。換言すれば、業務プロセス3は、業務アプリケーション4に基づき処理を実行する。業務プロセス3は、複数の業務リクエストを振分けられた場合、振分けられた業務リクエスト毎に、業務アプリケーション4に当該業務リクエストを処理させる。これにより、業務プロセス3は、クライアント8から依頼された処理を実行する。業務アプリケーション4は、業務プロセス3において実行されるアプリケーションプログラムである。業務プロセス3は、例えば、監視プロセス7が予め定められた業務プロセス3の起動コマンドを実行することにより起動される。監視プロセス7は、例えば、監視プロセス7が起動されると、業務プロセス3の起動コマンドを実行する。この時、複数の業務プロセス3が起動され、並列して稼動させられる。これにより、負荷を分散し、アプリケーションサーバ1を安定的に稼動させることができる。代替プロセス5は、業務プロセス3に異常が発生した場合、業務プロセス3に代わって処理を実行するプロセスである。従って、代替プロセス5は、業務プロセス3と同一の機能を有する。代替プロセス5は、実際に業務の処理を実行する業務処理実行部であり、振分けプロセス2により振分けられたクライアント8からの業務リクエストを実行する。具体的には、代替プロセス5は、振分けプロセス2から業務リクエストを受信すると、受信した業務リクエストを実行する業務アプリケーション6を呼び出して、呼び出した業務アプリケーション6に業務リクエストにおいて指示された処理を実行させる。代替プロセス5は、複数の業務リクエストを振分けられた場合、振分けられた業務リクエスト毎に、業務アプリケーション6に当該業務リクエストを処理させる。これにより、代替プロセス5は、クライアント8から依頼された処理を実行する。業務アプリケーション6は、代替プロセス5において実行されるアプリケーションプログラムである。業務アプリケーション6は、実際には、業務アプリケーション4と同様のアプリケーションプログラムである。代替プロセス5は、例えば、監視プロセス7が予め定められた代替プロセス5の起動コマンドを実行することにより起動される。監視プロセス7は、例えば、業務プロセス3に異常が発生した場合に、代替プロセス5の起動コマンドを実行する。なお、監視プロセス7が、例えば、監視プロセス7が起動されると直ちに代替プロセス5の起動コマンドを実行するようにしても良い。起動される代替プロセス5の数は、例えば、起動された業務プロセス3の数と同じ数とされる。これにより、業務プロセス3に異常が発生した場合に、異常が発生した業務プロセス3のみでなく、全ての業務プロセス3を代替プロセス5に切替えることができる。なお、起動される代替プロセス5の数は、起動された業務プロセス3の数より少ない数であっても良い。監視プロセス7は、プロセスを起動する起動部であり、業務プロセス3及び代替プロセス5を起動する。前述したように、監視プロセス7は、監視プロセス7の起動コマンドにより起動されると、業務プロセス3の起動コマンドを複数回実行することにより、複数の業務プロセス3を起動する。また、監視プロセス7は、業務プロセス3に異常が発生した場合に、代替プロセス5の起動コマンドを複数回実行することにより、複数の代替プロセス5を起動する。監視プロセス7は、監視処理を実行する監視部であり、全ての自己が起動したプロセス、換言すれば、業務プロセス3及び代替プロセス5を監視するプロセスである。監視プロセス7は、業務を実行する業務プロセス3及び代替プロセス5を監視し、業務プロセス3について異常が発生したか否かを判断することにより、業務の実行を監視する。業務プロセス3が代替プロセス5に切り替えられた場合には、監視プロセス7は、新たな業務プロセスである代替プロセス5について異常が発生したか否かを判断することにより、業務の実行を監視する。監視プロセス7については、図2を参照して後述する。監視プロセス7は、例えば、業務の開始に先立って、予め定められた監視プロセス7の起動コマンドを実行することにより起動される。具体的には、例えば、アプリケーションサーバ1の管理者が、アプリケーションサーバ1の入力装置から監視プロセス7の起動コマンドを入力することにより、アプリケーションサーバ1に監視プロセス7の起動コマンドを実行させる。図2は、情報処理装置の一例を示す図である。図3は、プロセス監視処理の説明図である。なお、図2において、代替プロセス5の図示を省略している。監視プロセス7は、複数の業務プロセス3、例えば、業務プロセス1及び業務プロセス2を起動する。起動される業務プロセス3の数は、2個には限られない。また、監視プロセス7は、複数の代替プロセス5、例えば、代替プロセス1及び代替プロセス2を起動する。起動される代替プロセス5の数は、前述したように、起動された業務プロセス3の数と同数とされる。この後、監視プロセス7は、図3Aに示す業務プロセス管理情報71を生成し、生成した業務プロセス管理情報71を振分けプロセス2に送信する。実際には、業務プロセス管理情報71は、業務プロセス3の起動完了の通知に付加される。監視プロセス7は、例えば、全ての起動した業務プロセス3から起動完了の通知を受信すると、業務プロセス3の起動完了の通知を振分けプロセス2に送信する。業務プロセス管理情報71は、図3Aに示すように、実際に業務を実行する業務プロセス3を表す情報である。換言すれば、業務プロセス3は、振分けプロセス2から業務リクエストを振分けられることが可能なプロセスである。業務プロセス管理情報71は、業務プロセス3の起動の都度に、監視プロセス7により生成される。業務プロセス管理情報71は、プロセス番号毎に、プロセスIDと、ポート番号とを含む。プロセス番号は、起動されているプロセスの中で、業務リクエストを振分けられて実際に業務を実行するプロセス、換言すれば、業務プロセス3を一意に定める識別情報である。プロセスIDは、起動されているプロセスを一意に定める識別情報である。起動されているプロセスには、業務プロセス3、代替プロセス5、及び、その他の全てのプロセスが含まれる。ポート番号は、対応するプロセスIDのプロセスがプロセス間通信において使用するポート、例えば論理的なポートを一意に定める識別情報である。振分けプロセス2は、監視プロセス7から業務プロセス3の起動完了の通知と業務プロセス管理情報71とを受信すると、業務プロセス管理情報71に基づいて、クライアント8から受け付けた業務リクエストを業務プロセス3へ振分ける。これに応じて、業務リクエストを振分けられた業務プロセス3は、業務リクエストにおいて依頼された業務を、業務アプリケーションにより実行する。一方、監視プロセス7は、業務プロセス3の起動完了の通知を振分けプロセス2に送信した後、業務プロセス3を監視する。具体的には、監視プロセス7は、予め定められた周期で定期的に、全ての業務プロセス3から業務プロセス情報を収集する。業務プロセス情報の収集は、収集部73によって実行される。業務プロセス情報は、各々の業務プロセス3の特性を表す特性情報である。収集部73は、複数の業務プロセス3の各々から、換言すれば、複数の業務プロセス3の各々について、特性情報を収集する。例えば、業務プロセス1から図3Bに示す業務プロセス情報31が収集され、業務プロセス2から図3Cに示す業務プロセス情報32が収集される。なお、図2に示すように、業務プロセス1から収集される情報を業務プロセス情報1とも言い、業務プロセス2から収集される情報を業務プロセス情報2とも言う。業務プロセス情報31は、図3Bに示すように、業務プロセス1の特性を表す特性情報である。業務プロセス情報31は、業務プロセス1により生成され、逐次更新される。業務プロセス情報31は、プロセスIDと、メモリ使用量と、レスポンス時間と、200以外の回数とを含む。プロセスIDは、自己のプロセスID、換言すれば、業務プロセス1のプロセスIDである。メモリ使用量は、その時点で業務プロセス1が使用しているメモリの量である。レスポンス時間は、業務プロセス1が自己に振分けられた業務リクエストを受信してから、当該業務リクエストに対するレスポンスを返信するまでの時間である。200以外の回数は、業務プロセス1において、HTTPにおけるステータスコード200以外のステータスコードが発生した回数である。HTTPは、複数の業務プロセス3が例えばクライアント8又は振分けプロセス2との間で通信を行う場合のプロトコルである。業務プロセス情報32は、図3Cに示すように、業務プロセス2の特性を表す特性情報である。業務プロセス情報32は、業務プロセス2により生成され、逐次更新される。業務プロセス情報32は、プロセスIDと、メモリ使用量と、レスポンス時間と、200以外の回数とを含む。プロセスIDは、自己のプロセスID、換言すれば、業務プロセス2のプロセスIDである。メモリ使用量は、その時点で業務プロセス2が使用しているメモリの量である。レスポンス時間は、業務プロセス2が自己に振分けられた業務リクエストを受信してから、当該業務リクエストに対するレスポンスを返信するまでの時間である。200以外の回数は、業務プロセス2において、200以外のステータスコードが発生した回数である。業務プロセス情報31及び32において、メモリ使用量、レスポンス時間、200以外の回数が、各々、特性情報である。業務プロセス情報31及び32には、各々、複数の種類の特性情報が含まれる。特性情報は、予め定められた特定の処理についての情報、又は、予め定められた特定の資源についての情報である。具体的には、特性情報は、プロセスが実行した処理の結果が所定の処理結果であった回数を示す情報、又は、プロセスが使用する所定の資源の使用量についての情報である。メモリ使用量には、例えば、Java仮想マシンにおけるヒープ領域、Cヒープ領域、Permanent世代領域等が含まれる。レスポンス時間としては、業務プロセス3毎のレスポンス時間の他に、業務アプリケーション4毎のレスポンス時間、業務リクエスト毎のレスポンス時間を用いるようにしても良い。200以外の回数として、業務プロセス1において、200番代のステータスコード以外のステータスコードが発生した回数を用いるようにしても良く、また、300番代及び400番代のステータスコードが発生した回数を用いるようにしても良い。特性情報は、メモリ使用量、レスポンス時間、200以外の回数のような、業務プロセス3が使用している資源に関連するデータに限られない。例えば、業務アプリケーション4の固有情報、データベースのコネクション、スレッドプール、トランザクション情報、ファイルディスクリプタ、ハンドル、CPU使用率等を、特性情報として用いるようにしても良い。特性情報として用いられる業務アプリケーション4の固有情報は、例えば、業務アプリケーション4の禁止されている状態である。特性情報として用いられるデータベースのコネクションは、例えば、業務アプリケーション4がデータベースにアクセスする場合におけるソケットの数である。特性情報として用いられるスレッドプールは、例えば、業務プロセス3がプールしているスレッドの数である。特性情報として用いられるトランザクション情報は、例えば、業務プロセス3におけるトランザクションの数や時間である。特性情報として用いられるファイルディスクリプタやハンドルは、業務プロセス3が有する数である。特性情報として用いられるCPU使用率は、例えば、業務プロセス3がCPUを使用している割合である。例えば、監視プロセス7の収集部73は、複数の業務プロセス3の各々に対して特性情報の送信を要求する。これに応じて、複数の業務プロセス3の各々が、特性情報を監視プロセス7の収集部73に送信する。これにより、特性情報が収集される。特性情報は、業務プロセス3が共有メモリ等の記憶装置に書き込んだ特性情報を、監視プロセス7の収集部73が参照することにより、収集するようにしても良い。監視プロセス7は、全ての業務プロセス3から業務プロセス情報を収集すると、収集した業務プロセス情報を比較する。業務プロセス情報の比較は、比較部74によって実行され、全ての業務プロセス3からの業務プロセス情報の収集の都度に実行される。例えば、比較部74は、複数の業務プロセス3の各々から収集された業務プロセス情報を、第1の業務プロセス3と、第1の業務プロセス3以外の業務プロセスである第2の業務プロセス3の集合とに分ける。そして、比較部74は、第1の業務プロセス3の特性情報と、第2の業務プロセス3の特性情報の集合が示す特性とを比較する。第1の業務プロセス3は、ある1個の業務プロセス3である。第1の業務プロセス3は、業務プロセス情報を収集した複数の業務プロセス3から、1個の業務プロセス3を順次取り出すことにより取得される。監視プロセス7は、比較部74における比較の結果、第1の業務プロセス3の特性情報と、第2の業務プロセス3の特性情報の集合が示す特性とが異なる場合、第1の業務プロセス3に異常が発生したと判断する。異常が発生したか否かの判断は、判断部75によって実行され、業務プロセス情報の比較の都度に実行される。監視プロセス7、換言すれば、判断部75は、複数の業務プロセス3のうちのある業務プロセス3に関する特性情報が、複数の業務プロセス3のうち、前記ある業務プロセス3を除いた残りの業務プロセス3のいずれの特性情報とも特性が異なる場合に、前記ある業務プロセス3について異常が発生したと判断する。第1の業務プロセス3の特性情報と第2の業務プロセス3の特性情報の集合が示す特性とが異なるか否かの判断基準は、特性情報の種類毎に、経験的に定められる。例えば、業務プロセス1が第1の業務プロセス3であり、図3Bの業務プロセス情報1が第1の業務プロセス3の特性情報であるとする。また、業務プロセス2が第2の業務プロセス3であり、図3Cの業務プロセス情報2が第2の業務プロセス3の特性情報であるとする。更に、業務プロセス2と同一の業務プロセス情報を持つ業務プロセス3が、複数存在するものとする。従って、第2の業務プロセス3の特性情報の集合は、図3Cの業務プロセス情報2の集合である。この場合、第1の業務プロセス3である業務プロセス1の特性情報は、200以外の回数に着目すると、5である。これに対して、第2の業務プロセス3である複数の業務プロセス2の特性情報の集合が示す特性は、200以外の回数に着目すると、1である。従って、第1の業務プロセス3である業務プロセス1の特性情報のみが、他の業務プロセス3の特性情報と異なる値を持つ。この結果、第1の業務プロセス3である業務プロセス1の特性情報が、第2の業務プロセス3である複数の業務プロセス2の特性情報の集合が示す特性と異なることになる。そこで、第1の業務プロセス3である業務プロセス1に異常が発生したと判断される。異常が発生したと判断される業務プロセス3の数は、1個に限られない。また、例えば、メモリ使用量について、例えば、第1の業務プロセス3の特性情報のみが増加傾向にあり、第2の業務プロセス3の特性情報の集合が示す特性が増加傾向に無い、換言すれば、減少又はほぼ一定の値を維持する場合に、第1の業務プロセス3に異常が発生したと判断するようにしても良い。逆に、第1の業務プロセス3の特性情報のみが減少傾向にあり、第2の業務プロセス3の特性情報の集合が示す特性が減少傾向に無い、換言すれば、増加又はほぼ一定の値を維持する場合に、第1の業務プロセス3に異常が発生したと判断するようにしても良い。この場合にも、異常が発生したと判断される業務プロセス3の数は、1個に限られない。また、例えば、レスポンス時間について、例えば、メモリ使用量と同様にして判断するようにしても良い。また、前述したように、業務プロセス情報31及び32には、各々、複数の種類の特性情報が含まれる。そこで、1種類の特性情報について、第1の業務プロセス3の特性情報と第2の業務プロセス3の特性情報の集合が示す特性とが異なる場合には、第1の業務プロセス3の特性情報と第2の業務プロセス3の特性情報の集合が示す特性とが異なると判断するようにしても良い。逆に、複数の種類の特性情報の各々について、第1の業務プロセス3の特性情報と第2の業務プロセス3の特性情報の集合が示す特性とが異なるか否かを判断して、その多数決により、第1の業務プロセス3の特性情報と第2の業務プロセス3の特性情報の集合が示す特性とが異なるか否かを判断するようにしても良い。以上により、異常検出のための閾値を用いることなく、業務プロセス3における異常の発生、実際には、異常の発生の予兆を検出することができる。また、異常検出のための妥当な閾値を設定することができないアプリケーションの異常を検出することができる。この結果、業務プロセス3が異常終了して業務が停止することを回避することができる。監視プロセス7は、業務プロセス3に異常が発生したと判断した場合、例えば、アプリケーションサーバ1の管理者へ、ログへのメッセージの出力や表示装置への表示等により、業務プロセス3に異常が発生したことを警告する。なお、アプリケーションサーバ1の管理者へ、警告と共に、又は、警告とは別に、異常が発生したと判断された業務プロセス3を通知するようにしても良い。監視プロセス7は、業務プロセス3に異常が発生したと判断した場合、複数の代替プロセス5、例えば、代替プロセス1及び代替プロセス2を起動する。起動される代替プロセス5の数は、前述したように、起動された業務プロセス3の数と同数とされる。従って、起動される代替プロセス5の数は、2個には限られない。この後、監視プロセス7は、図3Dに示す代替プロセス管理情報72を生成し、生成した代替プロセス管理情報72を振分けプロセス2に送信する。実際には、代替プロセス管理情報72は、代替プロセス5の起動完了の通知に付加される。監視プロセス7は、例えば、全ての起動した代替プロセス5から起動完了の通知を受信すると、代替プロセス5の起動完了の通知を振分けプロセス2に送信する。代替プロセス管理情報72は、図3Dに示すように、実際に業務を実行する代替プロセス5を表す情報である。代替プロセス管理情報72は、代替プロセス5の起動の都度に、監視プロセス7により生成される。代替プロセス管理情報72は、プロセス番号毎に、プロセスIDと、ポート番号とを含む。プロセス番号は、起動されているプロセスの中で、業務リクエストを振分けられて実際に業務を実行するプロセス、換言すれば、業務プロセス3を置換する代替プロセス5を一意に定める識別情報である。なお、判断部75が、業務プロセス3について異常が発生した場合に、複数の業務プロセス3と同じ数の代替プロセス5を起動するようにしても良い。また、判断部75が、業務リクエストを代替プロセス5に振分けるように振分けプロセス2に通知するようにしても良い。業務プロセス3は、既に振分けられた業務の実行を終了するまで処理を継続する。業務プロセス3は、異常が発生したと判断された業務プロセス3を含むが、異常終了するまでには到っていない。従って、業務プロセス3は、既に振分けられた業務の実行を継続し、終了することができる。振分けプロセス2は、監視プロセス7から代替プロセス5の起動完了の通知と代替プロセス管理情報72とを受信すると、代替プロセス管理情報72に基づいて、クライアント8から受け付けた業務リクエストを代替プロセス5へ振分ける。これに応じて、業務リクエストを振分けられた代替プロセス5は、業務リクエストにおいて依頼された業務を業務アプリケーション6により実行する。この結果、クライアント8からの業務リクエストの振分け先が変更され、異常が発生した業務プロセス3のみでなく、全ての業務プロセス3が代替プロセス5に切替えられる。これにより、異常が発生した業務プロセス3のみでなく、異常が発生した時点における全ての業務プロセス3の解析が可能となるので、より正確に異常の原因等を知ることができる。この後、代替プロセス5により、業務アプリケーション6の実行が継続される。一方、監視プロセス7は、代替プロセス5の起動完了の通知を振分けプロセス2に送信した後、複数の業務プロセス3をチェックする。業務プロセス3のチェックは、チェック部76によって実行される。チェック部76は、複数の業務プロセス3の各々をチェックする。具体的には、チェック部76は、代替プロセス5を起動した場合、プロセス監視処理と並行して、全ての業務プロセス3の異常調査を行う。具体的には、監視プロセス7のチェック部76は、複数の業務プロセス3の各々に対して全ての情報の送信を要求する。これに応じて、業務プロセス3は、その時点での業務プロセス情報を含む業務プロセス3についての全ての情報を、監視プロセス7のチェック部76へ送信する。これにより、具体的には、監視プロセス7は、全ての業務プロセス3から業務プロセス情報を含む業務プロセス3についての全ての情報を収集する。なお、チェック部76が、判断部75が業務リクエストを代替プロセス5に振分けるように振分け部に通知した後に、複数の業務プロセス3をチェックするようにしても良い。また、チェック部76が、業務プロセス情報を含む業務プロセス3についての全ての情報に代えて、予め定められた範囲の情報を収集するようにしても良い。また、業務プロセス3に異常が発生した場合、チェック部76が、異常が発生した業務プロセス3のみについて、異常調査を行うようにしても良い。この後、アプリケーションサーバ1の管理者が、収集された情報を解析する。これにより、全ての業務プロセス1及び業務プロセス2が生存した状態aliveで、他の業務の実行に影響を与えることなく、全ての業務プロセス1及び業務プロセス2を調査することができる。従って、異常が発生していた時の業務プロセス3の状態を維持することができるので、異常の原因を正しく解明することができる。図4は、アプリケーションサーバ1のハードウェアの構成の一例を示す図である。CPU101は、ROM102に格納された制御プログラムに従って、アプリケーションサーバ1を制御する。CPU101は、例えば主メモリであるRAM103上のプログラムを実行する。これにより、振分けプロセス2、業務プロセス3、業務アプリケーション4、代替プロセス5、業務アプリケーション6、監視プロセス7が実現される。プログラムは、例えば、CD-ROMやDVD等の記録媒体109に格納され、記録媒体109からCD-ROMドライブやDVDドライブ等を介してハードディスク106に入力され、ハードディスク106からRAM103にロードされる。業務プロセス管理情報71、代替プロセス管理情報72、業務プロセス情報31及び32は、データ格納部に格納される。データ格納部は、例えばRAM103又はハードディスク106に設けられる。換言すれば、データは、例えばRAM103又はハードディスク106に格納される。入力装置104は、例えばキーボードであり、マウス等を含んでも良い。出力装置105は、例えばディスプレイであり、プリンタ等の出力装置を含んでも良い。CPU101、ROM102、RAM103、入力装置104、出力装置105、及び、ハードディスク106、ネットワーク接続部107は、バス108を介して、相互に接続される。ネットワーク接続部107は、例えば、送受信装置であり、ネットワーク9に接続され、ネットワーク9を介して他のコンピュータ、例えばクライアント8に接続される。これにより、アプリケーションサーバ1は、クライアント8との間で通信を行う。なお、クライアント8も、例えば、図4に示すハードウェアの構成を有するコンピュータである。図5及び図6は、プロセス監視処理フローであり、一体となってプロセス監視処理フローを表す。アプリケーションサーバ1において監視プロセス7の起動コマンドが実行されることにより、監視プロセス7が起動されるステップS1。更に、アプリケーションサーバ1において、振分けプロセス2の起動コマンドが実行されることにより、振分けプロセス2が起動されるステップS2。起動された振分けプロセス2は、監視プロセス7からの業務プロセス3の起動完了の通知待ちの状態となる。監視プロセス7の起動及び振分けプロセス2の起動のいずれを先に実行するようにしても良い。起動された監視プロセス7は、業務プロセス3の起動コマンドを実行することにより、複数の業務プロセス3を起動するステップS3。これにより、例えば、業務プロセス1が起動されステップS4、業務プロセス2が起動されるステップS5。起動された業務プロセス1は自己の起動完了の通知を監視プロセス7に送信し、起動された業務プロセス2は自己の起動完了の通知を監視プロセス7に送信する。監視プロセス7は、全ての起動した業務プロセス1及び業務プロセス2から起動完了の通知を受信すると、業務プロセス3の起動完了の通知を振分けプロセス2に送信するステップS6。ステップS6における振分けプロセス2への業務プロセス3の起動完了の通知には、図3Aに示す業務プロセス管理情報71が付加される。振分けプロセス2は、監視プロセス7から業務プロセス3の起動完了の通知を受信すると、クライアント8からの業務リクエストの受付けを開始し、受け付けた業務リクエストを均等に業務プロセス1及び業務プロセス2へ振分けるステップS7。この後、業務プロセス1及び業務プロセス2により、業務アプリケーション4が実行される。業務リクエストを振分けられた業務プロセス1は、業務リクエストにおいて依頼された業務を、業務アプリケーションにより実行するステップS8。また、業務リクエストを振分けられた業務プロセス2は、業務リクエストにおいて依頼された業務を、業務アプリケーションにより実行するステップS9。一方、監視プロセス7の収集部73は、ステップS6において業務プロセス3の起動完了の通知を振分けプロセス2に送信した後、予め定められた周期で定期的に、全ての業務プロセス1及び業務プロセス2から業務プロセス情報を収集するステップS10。例えば、業務プロセス1から図3Bに示す業務プロセス情報31が収集され、業務プロセス2から図3Cに示す業務プロセス情報32が収集される。次に、監視プロセス7の比較部74は、全ての業務プロセス1及び業務プロセス2から業務プロセス情報を収集すると、収集した業務プロセス情報を比較するステップS11。次に、監視プロセス7の判断部75は、ステップS11における比較の結果、第1の業務プロセス3の特性情報が、第2の業務プロセス3の特性情報の集合が示す特性と異なる場合、第1の業務プロセス3に異常が発生したと判断するステップS12。次に、監視プロセス7は、業務プロセス3に異常が発生したと判断した場合、例えば、アプリケーションサーバ1の管理者へ、業務プロセス3に異常が発生したことを警告するステップS13。次に、監視プロセス7は、業務プロセス3の数と同数の代替プロセス5を起動するステップS14。これにより、例えば、業務プロセス1に対応する代替プロセス1が起動されステップS15、業務プロセス2に対応する代替プロセス2が起動されるステップS16。換言すれば、業務プロセス3に異常が発生したと判断された場合、異常が発生した業務プロセス3のみでなく、全ての業務プロセス3が、後述するように、代替プロセス5に切り替えられる。起動された代替プロセス1は自己の起動完了の通知を監視プロセス7に送信し、起動された代替プロセス2は自己の起動完了の通知を監視プロセス7に送信する。なお、代替プロセス5の起動を、種々のタイミングで実行するようにしても良い。異常の発生前に、例えば、ステップS3において代替プロセス5を起動するようにしても良い。また、ステップS12の実行の後にステップS14を実行し、その後、ステップS13を実行するようにしても良い。また、業務プロセス3に異常が発生したと判断された場合、異常が発生した業務プロセス3のみを、代替プロセス5に切り替えるようにしても良い。監視プロセス7は、全ての起動した代替プロセス1及び代替プロセス2から起動完了の通知を受信すると、振分け先の変更の通知を振分けプロセス2に送信するステップS17。ステップS17における振分けプロセス2への振分け先の変更の通知、換言すれば、代替プロセス5の起動完了の通知には、図3Dに示す代替プロセス管理情報72が付加される。振分けプロセス2は、監視プロセス7から代替プロセス5の起動完了の通知を受信すると、クライアント8からの業務リクエストの振分け先を業務プロセス3から代替プロセス5に変更し、クライアント8から受け付けた業務リクエストを、均等に代替プロセス1及び代替プロセス2へ振分けるステップS18。これにより、全ての業務プロセス3が代替プロセス5に切替えられる。この後、代替プロセス1及び代替プロセス2により、業務アプリケーション6の実行が継続される。図7は、プロセス調査処理フローである。監視プロセス7のチェック部76は、代替プロセス5を起動した場合、プロセス監視処理と並行して、全ての業務プロセス3の異常調査を行うステップS21。これにより、代替プロセス1及び代替プロセス2の起動の原因となった業務プロセス1及び業務プロセス2も異常調査される。具体的には、監視プロセス7のチェック部76は、業務プロセス1に対して業務プロセス1についての全ての情報の送信を要求し、業務プロセス2に対して業務プロセス2についての全ての情報の送信を要求する。これに応じて、業務プロセス1は、その時点での業務プロセス情報を含む業務プロセス1についての全ての情報を、監視プロセス7のチェック部76へ送信するステップS22。また、業務プロセス2は、その時点での業務プロセス情報を含む業務プロセス2についての全ての情報を、監視プロセス7のチェック部76へ送信するステップS23。この後、アプリケーションサーバ1の管理者が、収集された情報を解析することにより、全ての業務プロセス1及び業務プロセス2が生存した状態で、全ての業務プロセス1及び業務プロセス2を調査することができる。