プロセスにおける異常の種類によっては、異常検出のための閾値それ自体を決定することができない場合がある。この場合には、異常検出のための閾値を用いてプロセスが異常終了する可能性を検出することはできない。
例えば、HTTP(Hypertext Transfer Protocol)において、ステータスコード200(OK)が、クライアントからの「リクエストは成功した」ことを示すコードとして規定されている。ステータスコードが「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は、図3(A)に示す業務プロセス管理情報71を生成し、生成した業務プロセス管理情報71を振分けプロセス2に送信する。実際には、業務プロセス管理情報71は、業務プロセス3の起動完了の通知に付加される。監視プロセス7は、例えば、全ての起動した業務プロセス3から起動完了の通知を受信すると、業務プロセス3の起動完了の通知を振分けプロセス2に送信する。
業務プロセス管理情報71は、図3(A)に示すように、実際に業務を実行する業務プロセス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から図3(B)に示す業務プロセス情報31が収集され、業務プロセス#2から図3(C)に示す業務プロセス情報32が収集される。なお、図2に示すように、業務プロセス#1から収集される情報を業務プロセス情報#1とも言い、業務プロセス#2から収集される情報を業務プロセス情報#2とも言う。
業務プロセス情報31は、図3(B)に示すように、業務プロセス#1の特性を表す特性情報である。業務プロセス情報31は、業務プロセス#1により生成され、逐次更新される。
業務プロセス情報31は、プロセスIDと、メモリ使用量と、レスポンス時間と、「200以外の回数」とを含む。プロセスIDは、自己のプロセスID、換言すれば、業務プロセス#1のプロセスIDである。メモリ使用量は、その時点で業務プロセス#1が使用しているメモリの量である。レスポンス時間は、業務プロセス#1が自己に振分けられた業務リクエストを受信してから、当該業務リクエストに対するレスポンスを返信するまでの時間である。「200以外の回数」は、業務プロセス#1において、HTTPにおけるステータスコード「200」以外のステータスコードが発生した回数である。HTTPは、複数の業務プロセス3が例えばクライアント8又は振分けプロセス2との間で通信を行う場合のプロトコルである。
業務プロセス情報32は、図3(C)に示すように、業務プロセス#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であり、図3(B)の業務プロセス情報#1が第1の業務プロセス3の特性情報であるとする。また、業務プロセス#2が第2の業務プロセス3であり、図3(C)の業務プロセス情報#2が第2の業務プロセス3の特性情報であるとする。更に、業務プロセス#2と同一の業務プロセス情報を持つ業務プロセス3が、複数存在するものとする。従って、第2の業務プロセス3の特性情報の集合は、図3(C)の業務プロセス情報#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は、図3(D)に示す代替プロセス管理情報72を生成し、生成した代替プロセス管理情報72を振分けプロセス2に送信する。実際には、代替プロセス管理情報72は、代替プロセス5の起動完了の通知に付加される。監視プロセス7は、例えば、全ての起動した代替プロセス5から起動完了の通知を受信すると、代替プロセス5の起動完了の通知を振分けプロセス2に送信する。
代替プロセス管理情報72は、図3(D)に示すように、実際に業務を実行する代替プロセス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の起動完了の通知には、図3(A)に示す業務プロセス管理情報71が付加される。
振分けプロセス2は、監視プロセス7から業務プロセス3の起動完了の通知を受信すると、クライアント8からの業務リクエストの受付けを開始し、受け付けた業務リクエストを均等に業務プロセス#1及び業務プロセス#2へ振分ける(ステップS7)。この後、業務プロセス#1及び業務プロセス#2により、業務アプリケーション4が実行される。
業務リクエストを振分けられた業務プロセス#1は、業務リクエストにおいて依頼された業務を、業務アプリケーションにより実行する(ステップS8)。また、業務リクエストを振分けられた業務プロセス#2は、業務リクエストにおいて依頼された業務を、業務アプリケーションにより実行する(ステップS9)。
一方、監視プロセス7の収集部73は、ステップS6において業務プロセス3の起動完了の通知を振分けプロセス2に送信した後、予め定められた周期で定期的に、全ての業務プロセス#1及び業務プロセス#2から業務プロセス情報を収集する(ステップS10)。例えば、業務プロセス#1から図3(B)に示す業務プロセス情報31が収集され、業務プロセス#2から図3(C)に示す業務プロセス情報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の起動完了の通知には、図3(D)に示す代替プロセス管理情報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を調査することができる。