(57)【要約】【課題】クライアント装置から受け付けたリクエストを処理する複数のサーバ装置において、リクエストを処理する機能が停止した時に、情報不足による原因究明が出来なくなることを防止する。  【解決手段】ネットワークを介してクライアント装置２０から受け付けたリクエストを処理する複数のサーバ装置１０が相互に通信可能に構成されており、リクエストを処理する機能が停止した場合に、他のサーバ装置１０に対して各種サーバ動作定義ファイル２４０に従いログ強化などの指示と、ＣＰＵの稼動情報およびＵＲＩの処理情報を通知する。通知を受けたサーバ装置１０は、指示に従い、あるいは同時に送信されたＣＰＵの稼動情報、ＵＲＩの処理情報を参照し、各種サーバ動作定義ファイル２４０に従い、動作変更を行う。  【選択図】  図１
2008305214.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してクライアント装置から受け付けたリクエストを処理する複数のサーバ装置が、相互に通信可能に構成されており、
自身のサーバ装置内のリクエストを処理する機能が停止した場合のサーバ動作定義と、他のサーバ装置のリクエストを処理する機能が停止した場合に、当該サーバ装置から通知を受けた場合のサーバ動作定義と、リクエストの受け付け状況に関する情報とを対応させた情報を記憶する記憶部と、
リクエストを処理する機能の停止を検知すると、リクエストの受け付け状況に関する情報と、リクエストを処理する機能が停止した場合の指示内容を前記サーバ動作定義情報から取得して、取得したリクエストの処理情報および指示内容を他のサーバ装置に通知する監視サーバ処理部とを
備えることを特徴とした
リクエスト情報処理システム。
【請求項２】
通知を受けたサーバ装置は、受け取ったリクエストの処理情報と、通知された指示内容を元に、サーバ装置に含まれるリクエストの受け付けを行う機能と、リクエストを処理する機能に対して指示をすることを特徴としたリクエスト情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント装置から受け付けたリクエストを処理するサーバ装置の機能を制御する技術に関するものである。
【背景技術】
【０００２】
従来、複数のサーバ装置がネットワークを介して接続されたシステムにおいて、サーバ
装置がクライアント装置から受け付けたリクエストの処理を他のサーバ装置に負荷分散す
る技術がある。例えば、サーバ装置が、リクエストの処理を他のサーバ装置に委託した際
の処理時間やデータ転送時間などを履歴情報として保持し、クライアント装置からリクエ
ストを受け付けた場合に、保持している履歴情報に基づいて、このリクエストの処理の実
行に要する時間が短いサーバ装置を負荷分散先のサーバ装置として選出する技術が開示さ
れている（例えば、特許文献１参照）。サーバ装置は、選出したサーバ装置に処理の実行
を委託する。このような技術によれば、リクエストの処理を複数のサーバ装置に分散させ
ることが、可能である。
【０００３】
【特許文献１】特開２００３−２０８４１４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に開示された技術では、例えば、１つのリクエストでメモリ
を大量に消費してしまうような不具合がサーバ装置のプログラムに存在した場合や、サー
バ装置が悪意のあるリクエストを受け付けた場合などに、１つのリクエストを処理する過
程で、サーバ装置によるリクエストを処理する機能が停止してしまう可能性がある。この
ようなリクエストがクライアント装置からサーバ装置に連続的に送信された場合、リクエ
ストの処理を負荷分散させる機能により、サーバ装置が他のサーバ装置にリクエストの処
理を連続的に委託するため、複数のサーバ装置によるリクエストを処理する機能が連続的
に停止してしまう可能性がある。
また、従来の技術では、リクエストを処理する機能が停止した原因となるリクエストの特定や、サーバ装置の稼動状況を特定するための情報が不十分である可能性があり、問題のリクエストや、サーバ装置の稼動状況を絞り込めない状態でリクエストの拒否などを行う可能性がある。また、リクエストを処理する機能が停止した原因を特定するための情報が不十分である可能性があり、原因を特定するために必要な情報を取得するための設定を行い、再度同じ現象を発生させる必要がある可能性がある。
【０００５】
そこで本発明は、クライアント装置から受け付けたリクエストを処理する複数のサーバ
装置において、リクエストを処理する機能が連続的に停止することを防止することを目的
とする。
また、本発明は、クライアント装置から受け付けたリクエストを処理する複数のサーバ装置において、リクエストを処理する機能が停止したときに、停止した情報を他のサーバ装置に通知し、他のサーバ装置でログ情報の取得を強化し、情報を蓄積する、あるいは流量制御をさせることで、現象発生時の原因究明の情報取得を強化すること、あるいはリクエストを処理する機能が連続的に停止することを防止することを目的とする。
【課題を解決するための手段】
【０００６】
前記目的を達成するために、本発明は、ネットワークを介してクライアント装置から受け付けたリクエストを処理する複数のサーバ装置が、相互に通信可能に構成されており、自身のサーバ装置内のリクエストを処理する機能が停止した場合の動作定義と、他のサーバ装置のリクエストを処理する機能が停止した場合に、当該サーバ装置から通知を受けた場合の動作定義と、リクエストの受け付け状況に関する情報とを対応させた情報を記憶する記憶部と、情報を処理する処理部とを備えるものである。処理部は、リクエストを処理する機能の停止を検知すると、リクエストの受け付け状況に関する情報と、リクエストを処理する機能が停止した場合の指示内容を動作定義情報から取得して、取得したリクエストの処理情報および指示内容を他のサーバ装置に通知する。通知を受けたサーバ装置は、受け取ったリクエストの処理情報と、通知された指示内容を元に、サーバ装置に含まれるリクエストの受け付けを行う機能と、リクエストを処理する機能に対して指示をする。
【発明の効果】
【０００７】
本発明によれば、クライアント装置から受け付けたリクエストを処理する複数のサーバ装置において、複数のサーバ装置のリクエストを処理する機能が停止した場合に、原因の究明および流量制御を行うための十分な情報を取得することが可能である。
【発明を実施するための最良の形態】
【０００８】
以下、本発明を実施するための最良の形態（以下「実施形態」という）について、図面を参照して説明する。
【０００９】
図１は、本実施形態におけるサーバ装置が複数接続されたリクエスト処理システムの構成を示す図である。図１に示すように、本実施形態におけるリクエスト処理システム１は、複数のサーバ装置１０を含んで構成される。クライアント装置２０と、サーバ装置１０は、ネットワーク３０を介して相互に通信可能に構成されている。サーバ装置１０Ａおよびサーバ装置１０Ｂは冗長構成（同様の構成）であり、ここではサーバ装置１０が２台示されているが、複数であれば特にその数が限定されるものではない。また、クライアント装置２０は２台示されているが、複数であれば特にその数が限定されるものではない。
【００１０】
クライアント装置２０は、ネットワーク３０を介してサーバ装置１０にリクエストを送信する機能を有するとともに、サーバ装置１０からそのリクエストに対するレスポンスを受け取る機能を有する。
【００１１】
サーバ装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１００と、メモリ２００とを含んで構成される。記憶部としてのメモリ２００は、監視サーバ処理プログラム２１０と、アプリケーションサーバ処理プログラム２２０と、Ｗｅｂサーバ処理プログラム２３０と、各種サーバ動作定義ファイル２４０と、各種稼動情報テーブル２５０と、各種蓄積用情報テーブル２６０を含んで記憶する機能を有する。処理部としてのＣＰＵ１００は、メモリ２００に記憶されているプログラムを実行する機能を有する。
【００１２】
アプリケーションサーバ処理プログラム２２０は、Ｗｅｂサーバ処理プログラム２３０からリクエストが入力されると、そのリクエストの処理を実行し、Ｗｅｂサーバ処理プログラム２３０にその実行結果としてのレスポンスを出力するコードが記述されたプログラムである。
【００１３】
監視サーバ処理プログラム２１０は、リクエストを処理する機能（アプリケーションサーバ処理プログラム２２０がＣＰＵ１００に実行されることによって実現する機能）を監視し、その停止を検知すると、各種稼動情報テーブル２５０および各種サーバ動作定義ファイル２４０を参照し、他のサーバ装置（サーバ装置１０Ａから見た場合のサーバ装置１０Ｂ）の監視サーバ処理プログラム２１０に対して、サーバ装置１０Ｂで行うべき指示内容と、各種蓄積用情報テーブル２６０を通知する。
【００１４】
図２は、本実施形態におけるリクエスト処理システムが２台のサーバ装置を含む場合の処理の流れを示す図である。図２に示すように、ここでは、リクエスト処理システム１が、２台のサーバ装置１０（サーバ装置１０Ａおよびサーバ装置１０Ｂ）を含んで構成される場合を例に挙げて、サーバ装置１０Ａに含まれるリクエスト処理の機能が停止した場合に、サーバ装置１０Ｂへの情報通知と他のサーバ装置１０での動作変更について説明する。また、監視サーバ処理部３１０、アプリケーションサーバ処理部３２０およびＷｅｂサーバ処理部３３０は、それぞれ監視サーバ処理プログラム２１０、アプリケーションサーバ処理プログラム２２０およびＷｅｂサーバ処理プログラムがＣＰＵ１００によって実行されることによって実現されるものである。
【００１５】
クライアント装置２０から送信されたリクエスト（ｈｔｔｐ：／／・・・／ｉｎｄｅｘ．ｊｓｐ）をアプリケーションサーバ処理部３２０Ａで処理をしようとしたが、何らかの要因によりアプリケーションサーバ処理部３２０Ａがダウン（リクエストを処理する機能が停止）したとする。監視サーバ処理部３１０Ａは、アプリケーションサーバ処理部３２０Ａのプロセスが存在するか否かを所定の時間ごとに監視しており、アプリケーションサーバ処理部３２０Ａがダウンしたことを検知すると（ステップＳ１００１）、Ｗｅｂサーバ処理部３３０Ａで処理中のＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｅｒ）の情報を取得（ステップＳ１００２）し、その情報の編集を行い（ステップＳ１００３）、稼動情報および指示内容を監視サーバ処理部３１０Ｂへ通知する（ステップＳ１００４）。
【００１６】
監視サーバ処理部３１０Ｂは、監視サーバ処理部３１０Ａから通知された情報を編集し（ステップＳ１００５）、各種蓄積用情報テーブル２６０（図１参照）に保持する（ステップＳ１００６）。
【００１７】
監視サーバ処理部３１０Ｂは、各種蓄積用情報テーブル２６０の情報および各種定義ファイル２４０（図１参照）を参照し、監視サーバ処理部３１０Ａからの指示内容を変更する（ステップＳ１００６）。
【００１８】
監視サーバ処理部３１０Ｂでは、指示内容を元にログ強化用ＯＳコマンドの実行、アプリケーションサーバ処理部３２０Ｂへのログ強化およびＷＥｂサーバ処理部３３０Ｂへのログ強化（ステップＳ１００７）、Ｗｅｂサーバ処理部３３０Ｂへの流量制御を実施（ステップＳ１００８）する。
【００１９】
図３は、本実施形態において監視サーバが、他のサーバ装置に対して指示をする内容を定義したファイルを示す図であり、各種サーバ動作定義ファイル２４０（図１参照）に含まれる。図３に示すように、監視サーバ指示定義ファイル４００は、条件４０１と、他サーバへの指示４０２とを含んで構成される。監視サーバ指示定義ファイル４００のデータは、リクエスト処理システムの管理者などが登録する。
【００２０】
条件４０１は、リクエスト処理システム１（図１参照）におけるダウン回数の累計である「ダウン回数」と、例えば、アプリケーションサーバ処理部３２０（図２参照）がダウンした場合に、ログ強化を目的とすることを示す「資料採取」や、安定して稼動し続けることを目的とする「安定稼動」などを、各サーバ装置に運用のタイプを定義する。
【００２１】
他サーバへの指示４０２は、稼動中のサーバ装置１０の監視サーバ処理部３１０、アプリケーションサーバ処理部３２０およびＷｅｂサーバ処理部３３０（図１参照）に対する指示内容を示す。ここでは、ログ強化用定義ファイル４７０のログタイプ４７１（図１０）および、流量制御用定義ファイル４８０の流量制御タイプ４８１（図１１）の定義を使用して定義することが出来る。
【００２２】
図４は、本実施形態におけるクライアント装置からのリクエストを受け付けるＷｅｂサーバの処理の統計情報を示す図であり、図１における各種稼動情報テーブル２５０に含まれる。図４に示すように、Ｗｅｂサーバ処理統計情報テーブル４１０は、ＵＲＩ４１１と、リクエスト処理件数４１２と、平均レスポンスタイム４１３とを含んで構成される。Ｗｅｂサーバ処理統計情報テーブル４１０のデータは、ステップ１００２（図２参照）により設定される。
【００２３】
ＵＲＩ４１１は、Ｗｅｂサーバ処理部３３０（図２参照）がクライアント装置２０（図２参照）からのリクエストによって指定されるリソースの識別子である。ここでは、Ｗｅｂサーバ処理部３３０で受け付けたリクエストを、“／”のコンテキストルートから始まるＵＲＩを登録する。  リクエスト処理件数４１２は、Ｗｅｂサーバ処理部３３０（図２参照）が処理した、ＵＲＩ４１１のリクエストの処理件数を示す。
【００２４】
平均レスポンスタイム４１３は、Ｗｅｂサーバ処理部３３０（図２参照）が、ＵＲＩ４１１のリクエストを受け付けてから、レスポンスを送信完了するまでの時間の平均を登録する。初めての識別子であるリクエストに対しては、レスポンスタイムが無いため、“−”を登録する。
【００２５】
図５は、本実施形態におけるサーバ装置のＣＰＵの稼動情報を示す図であり、図１における各種稼動情報テーブル２５０に含まれる。図５に示すように、ＣＰＵ稼動統計情報テーブル４２０は、日時４２１と、Ｓｙｓ４２２と、Ｕｓｅｒ４２３と、Ｉｄｌｅ４２４を含んで構成される。ＣＰＵ稼動統計情報テーブル４２０のデータは、ステップＳ１００３（図２参照）により登録される。
【００２６】
日時４２１は、「年」と「月」と「日」と「時」と「分」と「秒」とを含む。登録されるデータは、ＣＰＵの稼動情報を取得した時の日時である。
Ｓｙｓ４２２は、Ｉ／Ｏ処理など主にＯＳの処理によるＣＰＵの使用率を示す。
Ｕｓｅｒ４２３は、主にユーザプログラムの処理によるＣＰＵの使用率を示す。
Ｉｄｌｅ４２４は、およびＣＰＵが何かの処理によって使用されていない状態の占有率を示す。
【００２７】
図６は、本実施形態におけるサーバ装置の運用形態における役割を示す図であり、図１における各種動作定義ファイル２５０に含まれる。図６に示すように、サーバタイプ定義ファイル４３０は、ホスト４３１と、サーバのタイプ４３２とを含んで構成される。サーバタイプ定義ファイル４３０のデータは、リクエスト処理システムの管理者などにより設定される。
【００２８】
ホスト４３１では、サーバ装置１０が構築されているシステムのホスト名を定義する。
【００２９】
サーバのタイプ４３２では、ホスト４３１で定義したホストの運用形態における役割を示す。例えば、アプリケーションサーバ処理部３２０（図２参照）がダウンするような状況の場合、あるサーバ装置１０（図１参照）では、原因究明のためにログを強化するためのサーバとして「資料採取」を定義し、別のサーバ装置１０では、リクエスト処理システム１全体としてサービスが停止状態にならないようにするために、流量制御を行いダウンさせないようなサーバとして「安定稼動」を定義する。
【００３０】
図７は、本実施形態におけるサーバ装置において、リクエストを処理するプログラムがダウンした回数やサーバ装置の情報を示す図であり、図１における各種蓄積用情報テーブル２６０に含まれる。図７に示すように、ダウン情報管理テーブル４４０は、ダウンカウンタ４４１と、ダウンサーバリスト４４２を含んで構成される。ダウン情報管理テーブル４４０のデータは、ステップＳ１００１（図２参照）によって登録される。
【００３１】
ダウンカウンタ４４１は、リクエスト処理システム１の複数のサーバ装置１０に含まれるアプリケーション処理装置３２０がダウンした回数を登録する。
【００３２】
ダウンサーバリスト４４２は、アプリケーション処理装置３２０がダウンした時のサーバ装置のホスト名を登録する。
【００３３】
図８は、本実施形態におけるサーバ装置において、リクエストを処理するプログラムがダウンした際に、リクエストの受け付けをするＷｅｂサーバと、リクエストの処理をするプログラムで処理中のＵＲＩの情報を示す図であり、図１における蓄積用情報テーブル２６０に含まれる。図８に示すように、蓄積用処理中ＵＲＩ統計情報テーブル４５０は、ＵＲＩ４５１と、平均リクエスト処理件数４５２と、平均レスポンスタイム４５２を含んで構成される。蓄積用処理中ＵＲＩ統計情報テーブル４５０では、複数のサーバ装置１０のアプリケーションサーバ処理部３２０がダウンした場合のアプリケーションサーバ処理部３２０およびＷｅｂサーバ処理部３３０で処理中のリクエストの情報を整理して管理し、ステップＳ１００６（図２参照）によって、登録および情報の更新が行われる。
【００３４】
ＵＲＩ４５１は、クライアント装置２０（図２参照）から送信されたリクエストの識別子を示しており、複数のサーバ装置１０（図２参照）のアプリケーションサーバ処理部３２０（図２参照）がダウンした場合、自サーバ装置１０で保持している蓄積用ＵＲＩ統計情報テーブル４５０（図８参照）と、通知された情報の共通の識別子を抽出し、蓄積用ＵＲＩ統計情報テーブル４５０（図８参照）として登録する。
【００３５】
平均リクエスト処理件数４５２は、通知された複数のＵＲＩ統計情報に含まれるリクエスト処理件数の平均を示す。
【００３６】
平均レスポンスタイム４５３は、通知された複数のＵＲＩ統計情報に含まれる、Ｗｅｂサーバ処理装置３３０（図２参照）がリクエストを受け付けてから、レスポンスを送信完了するまでの時間の平均を示す。
【００３７】
図９は、本実施形態におけるサーバ装置において、ＣＰＵの稼動情報を管理するテーブルを示す図であり、図１における蓄積用情報テーブル２６０に含まれる。図９に示すように、蓄積用ＣＰＵ稼動統計情報テーブル４６０は、平均稼働時間４６１と、Ｓｙｓ４６２と、Ｕｓｅｒ４６３と、Ｉｄｌｅ４６４とを含んで構成される。蓄積用ＣＰＵ稼動統計情報テーブル４６０では、複数のサーバ装置１０のアプリケーションサーバ処理部３２０がダウンした場合の、サーバ装置１０のＣＰＵの稼動情報を整理して管理し、ステップＳ１００６（図２参照）によってデータの登録が行われる。
【００３８】
平均稼動時間４６１は、アプリケーションサーバ処理部３２０（図２参照）の稼働時間を表しており、ＣＰＵ稼動統計情報テーブル４２０の日時４２１（図５参照）の、最新日時と最も古い日時の差分秒数から算出されたものを、複数のアプリケーションサーバ処理部３２０（図２参照）がダウンした場合の平均値を示す。
Ｓｙｓ４６２は、「最小」と「最大」と「平均」を含み、Ｉ／Ｏ処理など主にＯＳの処理によるＣＰＵの使用率を示す。
Ｕｓｅｒ４６３は、「最小」と「最大」と「平均」を含み、主にユーザプログラムの処理によるＣＰＵの使用率を示す。
Ｉｄｌｅ４６４は、「最小」と「最大」と「平均」を含み、およびＣＰＵが何かの処理によって使用されていない状態の占有率を示す。
【００３９】
図１０は、本実施形態におけるサーバ装置において、あるサーバ装置のリクエストを処理するプログラムがダウンした時の、他のサーバ装置で適用されるログ採取レベルの指示内容を示す図であり、図１における各種サーバ動作定義ファイル２４０に含まれる。図１０に示すように、ログ強化用定義ファイル４７０は、ログタイプ４７１と、実施内容４７２を含んで構成される。ログ強化用定義ファイル４７０のデータは、管理者などによって定義されるものである。
【００４０】
ログタイプ４７１は、実施内容４７２に対する識別子を示し、一意な文字列を定義する。
【００４１】
実施内容４７２は、アプリケーションサーバ処理部３２０、Ｗｅｂサーバ処理部３３０（図２参照）に適用するログレベル、およびＯＳが提供するコマンドの実行を定義する。
【００４２】
図１１は、本実施形態におけるサーバ装置において、あるサーバ装置のリクエストを処理するプログラムがダウンした時の、他のサーバ装置で適用される流量制御の指示内容を示す図であり、図１における各種サーバ動作定義ファイル２４０に含まれる。図１１に示すように、流量制御用定義ファイル４８０は、流量制御タイプ４８１と、実施内容４８２とを含んで構成される。流量制御用定義ファイル４８０のデータは、管理者などによって定義されるものである。
【００４３】
流量制御タイプ４８１は、実施内容４８２に対する識別子を示し、一意な文字列を定義する。
【００４４】
実施内容４８２は、Ｗｅｂサーバ処理部３３０（図２参照）に適用する流量制御を定義する。例えば、リクエストの受け付け数を減少させ、さらに特定のＵＲＩのリクエストを拒否することで、サーバ装置１０（図２参照）のダウンを防止する定義をする。
【００４５】
図１２は、本実施形態におけるサーバ装置において、あるサーバ装置のリクエストを処理するプログラムがダウンした時の、他のサーバ装置で適用するアクションを示す図であり、図１における各種サーバ動作定義ファイル２４０に含まれる。図１２に示すように、サーバ指示変更用定義ファイル４９０は、条件４９１と、サーバへの指示変更４９２とを含んで構成される。サーバ指示変更用定義ファイル４９２は、管理者などによって定義されるものである。例えば、処理中のＵＲＩが３以下に絞込みが出来た場合、その全てのＵＲＩの受け付けを拒否するような定義を行う。
【００４６】
条件４９１は、蓄積用処理中ＵＲＩ統計情報テーブル４５０（図８参照）と、蓄積用ＣＰＵ稼動統計情報テーブル４８０（図９参照）とに格納されているデータを元に、条件を定義する。
【００４７】
サーバへの指示変更４９２は、アプリケーションサーバ処理部３２０（図２参照）に適用するログ強化や、Ｗｅｂサーバ処理部３３０（図２参照）に適用するログ強化および流量制御、およびログ強化としてＯＳが提供するコマンドを監視サーバ処理部３１０（図２参照）が実行する内容を定義する。
【００４８】
図１３は、本実施形態におけるサーバ装置によるリクエストを処理する機能が停止した時の処理の流れを示すフローチャートである。図１３を参照して（適宜図２参照）、サーバ装置１０Ａがリクエストを処理する機能の停止を検知する処理、および検知した際に実行する処理の流れを説明する。
監視サーバ処理部３１０Ａは、所定の時間ごとにタイムスタンプおよびＣＰＵ稼動情報を取得し、ＣＰＵ稼動統計情報テーブル４２０の時刻４２１、Ｓｙｓ４２２、Ｕｓｅｒ４２３およびＩｄｌｅ４２４に登録する（ステップＳ１０１）。
【００４９】
監視サーバ処理部３１０Ａは、所定の時間ごとにアプリケーションサーバ処理部のプロセスの生存確認を実施する（ステップＳ１０２）。これは、監視サーバ処理部３１０Ａがアプリケーションサーバ処理部３２０Ａに対して、一定時間ごとにヘルスチェックを送信することで実施する。
【００５０】
監視サーバ処理部３１０Ａがアプリケーションサーバ処理部３２０Ａをダウンと判断していない場合（ステップＳ１０３で「Ｎｏ」）、ステップＳ１０１に戻る。
【００５１】
監視サーバ処理部Ｓ３１０Ａが、アプリケーションサーバ処理部３２０Ａがダウンした（サーバ装置１０Ａのリクエストを処理する機能が停止した）と判定した場合（ステップＳ１０３で「Ｙｅｓ」）、リクエスト処理システム１において、アプリケーションサーバ処理部３２０がダウンした回数を管理するために、ダウン情報管理テーブル４４０のダウンカウンタ４４１（図７参照）に１を加算し、ダウンサーバリスト４４２（図７参照）にダウンしたサーバ装置１０のホスト名を追加する（ステップ１０４）。
【００５２】
次に、Ｗｅｂサーバ処理部３３０からデータを取得し、Ｗｅｂサーバ処理統計情報テーブル４１０のＵＲＩ４１１、リクエスト処理件数４１２および平均レスポンスタイム４１３（図４参照）に格納する（ステップＳ１０５）。
【００５３】
続いて、ダウン情報管理テーブル４４０のダウンカウンタ４４１、サーバタイプ定義ファイル４３０（図７参照）を参照し、監視サーバ指示定義ファイル４００の条件４０１（図３参照）に合うものがあれば、他サーバへの指示４０２（図３参照）を決定する（ステップＳ１０６）。またＣＰＵ稼動統計情報テーブル４２０の日時４２１（図５参照）の最新日時と最も古い日時の差分秒数を算出し、蓄積用ＣＰＵ稼動統計情報テーブル４６０の稼働時間４６１（図９参照）に格納し、ＣＰＵ稼動統計情報テーブル４２０のＳｙｓ４２２、Ｕｓｅｒ４２３およびＩｄｌｅ４２４（図５参照）の最小、最大を抽出、および平均を算出し、蓄積用ＣＰＵ稼動統計情報テーブル４６０のＳｙｓ４６２、Ｕｓｅｒ４６３およびＩｄｌｅ４６４（図９参照）に格納する（ステップＳ１０７）。ステップＳ１０６の他サーバへの指示４０２（図３参照）および蓄積用ＣＰＵ稼動統計情報テーブル４６０（図９参照）を他のサーバへ通知する（ステップＳ１０８）。
【００５４】
アプリケーションサーバ処理部３２０を起動する（ステップＳ１０９）。
【００５５】
図１４は、本実施形態におけるサーバ装置のアプリケーションサーバの処理プロセスがダウンした場合の、アプリケーションサーバの処理プログラムがダウンしていない他のサーバ装置における処理の流れを示すフローチャートである。図１４を参照して（適宜図２を参照）、サーバ装置１０Ｂの監視サーバ処理部３１０Ｂで、サーバ装置１０Ａの監視サーバ処理部３１０Ａからの情報通知を受信した際に実行する処理の流れを説明する。
【００５６】
監視サーバ処理部３１０Ｂでは、サーバ装置１０Ａの監視サーバ処理部３１０Ａからの情報通知待ちを行い（ステップＳ２０１）、サーバ装置１０Ａの監視サーバ処理部３１０Ａからの情報通知が来ない間（ステップＳ２０２の「Ｎｏ」）はステップＳ２０１に戻る。サーバ装置１０Ａの監視サーバ処理部３１０Ａから情報通知が来た場合（ステップＳ２０２の「Ｙｅｓ」）、既に他のサーバ装置１０の監視サーバ処理部３１０から情報が送付されていない（蓄積用処理中ＵＲＬ統計情報テーブル４５０（図８参照）を保持していない）場合（ステップＳ２０３の「Ｎｏ」）、受信情報を蓄積用ＵＲＬ統計情報テーブル４５０（図８参照）および蓄積用ＣＰＵ稼動統計情報４６０（図８参照）として保持する。既に他のサーバ装置１０の監視サーバ処理部４１０から情報が送付されている（蓄積用処理中ＵＲＬ統計情報テーブル４５０（図８参照）を保持している）場合（ステップＳ２０３の「Ｙｅｓ」）、サーバ装置１０Ｂの蓄積用ＵＲＬ統計情報テーブル４５０（図８参照）と、受信した蓄積用ＵＲＬ統計情報テーブル４５０（図８参照）との共通のＵＲＩを抽出し、また統計情報を編集し、新たに蓄積用ＵＲＬ統計情報テーブル４５０（図８参照）として保持する（ステップＳ２０４）。
【００５７】
続いて、サーバ装置１０Ｂ内の蓄積用ＣＰＵ稼動統計情報テーブル４６０（図９参照）と、受信した蓄積用ＣＰＵ稼動統計情報テーブル４６０（図９参照）を編集し、新たに蓄積用ＣＰＵ稼動統計情報テーブル４６０（図９参照）として保持する（ステップＳ２０５）。
【００５８】
編集した蓄積用ＵＲＬ統計情報テーブル４５０（図８参照）、および蓄積用ＣＰＵ稼動統計情報テーブル４６０（図９参照）を参照し、サーバ指示変更用定義ファイル４９０の条件４９１（図１２参照）に一致するものがあれば、サーバへの指示変更４９２（図１２参照）を参照して、必要に応じてログ強化用定義ファイル４７０のログタイプ４７１から実施内容４７２（図１０参照）を決定し、流量制御用定義ファイル４８０の流量制御タイプ４８１から実施内容４８２（図１１参照）を指示内容としてアプリケーションサーバ処理部３２０ＢおよびＷｅｂサーバ処理部４３０Ｂに通知する（ステップＳ２０６）。
【００５９】
Ｗｅｂサーバ処理部３３０Ｂでは、流量制御の指示内容に対して、流量制御の変更の必要があれば（ステップＳ２０７の「Ｙｅｓ」）、アクションに従い定義を変更し（ステップＳ２０８）、流量制御の変更の必要がなければ（ステップＳ２０７の「Ｎｏ」）ステップＳ２０９に進む。
【００６０】
監視サーバ処理部３１０、アプリケーションサーバ処理部３２０およびＷｅｂサーバ処理部３３０では、ログ強化の変更の必要があれば（ステップＳ２０９の「Ｙｅｓ」）アクションに従い定義を変更およびコマンド実行し（ステップＳ２１０）、ログ強化の変更の必要がなければ（ステップＳ２０９の「Ｎｏ」）、ステップＳ２０１に戻る。
【００６１】
図１５は、本実施形態における他のサーバ装置のリクエストを処理するプログラムがダウンした際に、自サーバ装置に通知が来た時に、蓄積用ＵＲＩ統計情報テーブル（図８参照）のデータの変更に着目した処理の流れを示す図である。図１５を参照して、サーバ装置１０Ａのリクエストを処理するプログラムがダウンした際の、サーバ装置１０Ｂでの蓄積用ＵＲＩ統計情報テーブル４５０のデータの更新や、サーバ装置内の各サーバ処理部への指示内容の決定、および指示の実施の流れを示す。
サーバ装置１０Ａのリクエストを処理するプログラムがダウンすると、サーバ装置１０ＡのＷｅｂサーバ処理統計情報テーブル４１０と指示内容がサーバ装置１０Ｂに送信される（ステップＳ２０１）。サーバ装置１０Ｂでは、サーバ装置１０Ｂが持っている蓄積用ＵＲＩ統計情報テーブル４５０Ａと、送信されたＷｅｂサーバ処理統計情報テーブル４１０とを参照し、蓄積用ＵＲＩ統計情報テーブル４５０Ｂに更新する（ステップＳ２０４）。この時の編集方法としては、Ｗｅｂサーバ処理統計情報テーブル４１０のＵＲＩと、蓄積用ＵＲＩ統計情報テーブル４５０の共通ＵＲＩを抽出し（図１５の例では、“／ｔｅｓｔ１？ａａａ＝１”と“／ｔｅｓｔ２／ｂｂｂ＝１”が該当する）、そのＵＲＩに対する平均リクエスト処理件数、および平均レスポンスタイムを算出する。
続いて、サーバ指示変更用定義ファイル４９０に示される条件に一致する場合（図１５の例では、蓄積用ＵＲＩ統計情報テーブル４５０のＵＲＩが２つであるのに対して、サーバ指示変更用定義ファイル４９０の条件にある「処理中ＵＲＩ＜３」が一致する）、それに対応するサーバへの指示変更を行い（ステップＳ２０６）、監視サーバ処理部３１０と、アプリケーションサーバ処理部３２０と、Ｗｅｂサーバ処理部３３０（図２参照）のうちの該当サーバに指示を送る（図１５、図１０、図１１および図の例では、Ｗｅｂサーバ処理部３３０に対して流量制御を行い（ステップＳ２０８）、監視サーバ処理部と、アプリケーションサーバ処理部と、Ｗｅｂサーバ処理部に対してログ強化を行っている（ステップＳ２１０））。
【００６２】
図１６は、本実施形態における他のサーバ装置のリクエストを処理するプログラムがダウンした際の、サーバ装置に通知が来た時に、蓄積用ＣＰＵ統計情報テーブル（図８参照）のデータの変更に着目した処理の流れを示す図である。図１６を参照して、サーバ装置１０Ａのリクエストを処理するプログラムがダウンした際の、サーバ装置１０Ｂでの蓄積用ＣＰＵ処理統計情報テーブル４６０のデータの更新や、サーバ装置内の各サーバ処理部への指示内容の決定、および指示の実施の流れを示す。
サーバ装置１０Ａのリクエストを処理するプログラムがダウンすると、サーバ装置１０Ａの蓄積用ＣＰＵ統計情報テーブル４６０Ａと指示内容がサーバ装置１０Ｂに送信される（ステップＳ２０１）。サーバ装置１０Ｂでは、サーバ装置１０Ｂが持っている蓄積用ＣＰＵ統計情報テーブル４６０Ｂと、送信された蓄積用ＣＰＵ稼動統計情報テーブルとを参照し、蓄積用ＣＰＵ稼動統計情報テーブル４６０Ｃに更新する（ステップＳ２０５）。
続いて、サーバ指示変更用定義ファイル４９０に示される条件に一致する場合（図１６および図１５の蓄積用ＵＲＩ統計情報テーブル４５０Ｂの例では、蓄積用ＵＲＩ統計情報４５０ＢのＵｓｅｒ平均が６７、平均リクエスト処理件数が４００であり、条件に一致する）、それに対応するサーバへの指示変更を行い（ステップＳ２０６）、監視サーバ処理部３１０と、アプリケーションサーバ処理部３２０と、Ｗｅｂサーバ処理部３３０（図２参照）のうちの該当サーバに指示を送る（図１６および図１０に示す例では、監視サーバ処理部３１０で「ｐｓ ｅｆ」コマンドの実行と、アプリケーションサーバ処理部３２０のログレベルをｉｎｆｏに変更と、Ｗｅｂサーバ処理部３３０のログレベルをｉｎｆｏに変更する（ステップＳ２１０））。
【図面の簡単な説明】
【００６３】
【図１】本実施形態におけるサーバ装置が複数接続されたリクエスト処理システムの構成を示す図である。
【図２】本実施形態におけるリクエスト処理システムが２台のサーバ装置を含む場合の処理の流れを示す図である。
【図３】本実施形態における、監視サーバが他の監視サーバへの指示を定義するファイルの構成を示す図である。
【図４】本実施形態におけるＷｅｂサーバ処理部でのリクエスト処理の統計情報テーブルの構成を示す図である。
【図５】本実施形態におけるサーバ装置でのＣＰＵの稼動状況を示す統計情報テーブルの構成を示す図である。
【図６】本実施形態における各サーバ装置でのサーバのタイプを定義するファイルの構成を示す図である。
【図７】本実施形態におけるリクエスト処理システムのリクエストを処理するプログラムが機能停止した情報を管理するテーブルの構成を示す図である。
【図８】本実施形態における複数のサーバ装置のリクエストを処理するプログラムが機能停止したときに管理する処理中ＵＲＩの統計情報テーブルの構成を示す図である。
【図９】本実施形態における複数のサーバ装置のリクエストを処理するプログラムが機能停止したときに管理するＣＰＵの統計情報テーブルの構成を示す図である。
【図１０】本実施形態におけるログ強化用の実施内容を定義するファイルの構成を示す図である。
【図１１】本実施形態における流量制御用の実施内容を定義するファイルの構成を示す図である。
【図１２】本実施形態におけるリクエストを処理するプログラムが機能停止した情報を通知した場合の、状況に応じた設定を適用させるための指示内容を変更するための定義ファイルの構成を示す図である。
【図１３】本実施形態におけるリクエスト処理システムのサーバ装置に含まれる、リクエストを処理するプログラムが機能停止した時の処理の流れを示すフローチャートである。
【図１４】本実施形態におけるリクエスト処理システムのサーバ装置に含まれる、リクエストを処理するプログラムが機能停止した時の、他のサーバ装置における機能停止の通知を受信したサーバ装置における処理の流れを示すフローチャートである。
【図１５】本実施形態における、他のサーバ装置に含まれるリクエストを処理するプログラムが機能停止した時の、処理中のリクエスト情報の通知を受けた場合の、蓄積用の処理中のリクエスト情報を編集し、指示を行うまでの処理の流れを示す図である。
【図１６】本実施形態における、他のサーバ装置に含まれるリクエストを処理するプログラムが機能停止した時の、ＣＰＵの稼動情報の通知を受けた場合の、蓄積用のＣＰＵの情報を編集し、指示を行うまでの処理の流れを示す図である。
【符号の説明】
【００６４】
１      リクエスト処理システム
１０（１０Ａ、１０Ｂ）  サーバ装置
２０    クライアント装置
３０    ネットワーク
１００  ＣＰＵ
２００  メモリ
２１０  監視サーバ処理プログラム
２２０  アプリケーションサーバ処理プログラム
２３０  Ｗｅｂサーバ処理プログラム
２４０  各種サーバ動作定義ファイル
２５０  各種稼動情報テーブル
２６０  各種蓄積用情報テーブル
３１０（３１０Ａ、３１０Ｂ）  監視サーバ処理部
３２０（３２０Ａ、３２０Ｂ）  アプリケーションサーバ処理部
３３０（３３０Ａ、３３０Ｂ）  Ｗｅｂサーバ処理部
４００  監視サーバ指示定義ファイル
４０１  条件
４０２  他サーバへの指示
４１０  Ｗｅｂサーバ処理統計情報テーブル
４１１  ＵＲＩ
４１２  リクエスト処理件数
４１３  平均レスポンスタイム
４２０  ＣＰＵ稼動統計情報テーブル
４２１  日時
４２２  Ｓｙｓ
４２３  Ｕｓｅｒ
４２４  Ｉｄｌｅ
４３０  サーバタイプ定義ファイル
４３１  ホスト
４３２  サーバのタイプ
４４０  ダウン情報管理テーブル
４４１  ダウンカウンタ
４４２  ダウンサーバリスト
４５０  蓄積用処理中ＵＲＩ統計情報テーブル
４５１  ＵＲＩ
４５２  平均リクエスト処理件数
４５３  平均レスポンスタイム
４６０  蓄積用ＣＰＵ稼動統計情報テーブル
４６１  平均稼動時間
４６２  Ｓｙｓ
４６３  Ｕｓｅｒ
４６４  Ｉｄｌｅ
４７０  ログ強化用定義ファイル
４７１  ログタイプ
４７２  実施内容
４８０  流量制御用定義ファイル
４８１  流量制御タイプ
４８２  実施内容
４９０  サーバ指示変更用定義ファイル
４９１  条件
４９２  サーバへの指示変更
【図１】
2008305214.tif 000003
【図２】
2008305214.tif 000004
【図３】
2008305214.tif 000005
【図４】
2008305214.tif 000006
【図５】
2008305214.tif 000007
【図６】
2008305214.tif 000008
【図７】
2008305214.tif 000009
【図８】
2008305214.tif 000010
【図９】
2008305214.tif 000011
【図１０】
2008305214.tif 000012
【図１１】
2008305214.tif 000013
【図１２】
2008305214.tif 000014
【図１３】
2008305214.tif 000015
【図１４】
2008305214.tif 000016
【図１５】
2008305214.tif 000017
【図１６】
2008305214.tif 000018