(57)【要約】【課題】クライアント装置から受け付けたリクエストを処理する複数のサーバ装置において、リクエストを処理する機能が連続的に停止することを防止する。【解決手段】サーバ装置１０は、クライアント装置２０からのリクエストによって指定されるＵＲＩと、リクエストに対する処理の制御が実行されるための条件と、制御の処理内容であるアクションと、リクエストの受け付け状況に関する情報とを対応させた情報をメモリ２００に記憶しており、ＣＰＵ１００は、リクエストを処理する機能の停止を検知すると、リクエストの受け付け状況に関する情報が、対応する条件を満たす場合に、メモリ２００からＵＲＩおよびアクションを取得して他のサーバ装置１０に通知する。【選択図】図１
2008108163.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してクライアント装置からのリクエストを受け付け、当該リクエストを処理する複数のサーバ装置が、相互通信可能に構成されたシステムにおけるサーバ装置であって、
前記クライアント装置からのリクエストによって指定されるリソースの識別子と、前記リクエストに対する処理の制御が実行されるための条件と、前記制御の処理内容であるアクションと、前記リクエストの受け付け状況に関する情報とを対応させた情報を記憶する記憶部と、
前記リクエストを処理する機能の停止を検知すると、前記リクエストの受け付け状況に関する情報が、当該情報に対応する前記条件を満たす場合に、前記記憶部から前記リソースの識別子および前記アクションを取得し、
取得した前記リソースの識別子および前記アクションを他のサーバ装置に通知する処理部と
を備えることを特徴とするサーバ装置。
【請求項２】
ネットワークを介してクライアント装置からのリクエストを受け付け、当該リクエストを処理する複数のサーバ装置が、相互通信可能に構成されたシステムにおけるサーバ装置によるリクエスト処理制御方法であって、
前記クライアント装置からのリクエストによって指定されるリソースの識別子と、前記リクエストに対する処理の制御が実行されるための条件と、前記制御の処理内容であるアクションと、前記リクエストの受け付け状況に関する情報とを対応させた情報を記憶する記憶部と、情報を処理する処理部と
を備え、
前記処理部は、
前記リクエストを処理する機能の停止を検知すると、前記リクエストの受け付け状況に関する情報が、当該情報に対応する前記条件を満たす場合に、前記記憶部から前記リソースの識別子および前記アクションを取得し、
取得した前記リソースの識別子および前記アクションを他のサーバ装置に通知する
ことを特徴とするリクエスト処理制御方法。
【請求項３】
前記処理部は、
前記リクエストの受け付け状況に関する情報を所定の時間ごとに更新し、
前記リクエストの受け付け状況に関する情報は、
単位時間当たりに受け付けたリクエスト数、単位時間当たりに処理を失敗したリクエスト数および平均レスポンスタイムのうち、すくなくとも１つを含む
ことを特徴とする請求項２に記載のリクエスト処理制御方法。
【請求項４】
前記処理部は、
他のサーバ装置から前記リソースの識別子および前記アクションを受信すると、
前記アクションに従って、前記リソースの識別子を指定するリクエストに対する処理の制御を実行する
ことを特徴とする請求項２または請求項３に記載のリクエスト処理制御方法。
【請求項５】
請求項２ないし請求項４のいずれか１項に記載のリクエスト処理制御方法をコンピュータに実行させるためのリクエスト処理制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント装置から受け付けたリクエストを処理するサーバ装置の機能を制御する技術に関するものである。
【背景技術】
【０００２】
従来、複数のサーバ装置がネットワークを介して接続されたシステムにおいて、サーバ装置がクライアント装置から受け付けたリクエストの処理を他のサーバ装置に負荷分散する技術がある。例えば、サーバ装置が、リクエストの処理を他のサーバ装置に委託した際の処理時間やデータ転送時間などを履歴情報として保持し、クライアント装置からリクエストを受け付けた場合に、保持している履歴情報に基づいて、このリクエストの処理の実行に要する時間が短いサーバ装置を負荷分散先のサーバ装置として選出する技術が開示されている（例えば、特許文献１参照）。サーバ装置は、選出したサーバ装置に処理の実行を委託する。このような技術によれば、リクエストの処理を複数のサーバ装置に分散させることが可能である。
【特許文献１】特開２００３−２０８４１４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、特許文献１に開示された技術では、例えば、１つのリクエストでメモリを大量に消費してしまうような不具合がサーバ装置のプログラムに存在した場合や、サーバ装置が悪意のあるリクエストを受け付けた場合などに、１つのリクエストを処理する過程で、サーバ装置によるリクエストを処理する機能が停止してしまう可能性がある。このようなリクエストがクライアント装置からサーバ装置に連続的に送信された場合、リクエストの処理を負荷分散させる機能により、サーバ装置が他のサーバ装置にリクエストの処理を連続的に委託するため、複数のサーバ装置によるリクエストを処理する機能が連続的に停止してしまう可能性がある。
【０００４】
そこで本発明は、クライアント装置から受け付けたリクエストを処理する複数のサーバ装置において、リクエストを処理する機能が連続的に停止することを防止することを目的とする。
【課題を解決するための手段】
【０００５】
前記目的を達成するために、本発明は、ネットワークを介してクライアント装置から受け付けたリクエストを処理する複数のサーバ装置が、相互に通信可能に構成されており、クライアント装置からのリクエストによって指定されるリソースの識別子と、リクエストに対する処理の制御が実行されるための条件と、制御の処理内容であるアクションと、リクエストの受け付け状況に関する情報とを対応させた情報を記憶する記憶部と、情報を処理する処理部とを備えるものである。処理部は、リクエストを処理する機能の停止を検知すると、リクエストの受け付け状況に関する情報が、この情報に対応する条件を満たす場合に、記憶部からリソースの識別子およびアクションを取得して、取得したリソースの識別子およびアクションを他のサーバ装置に通知する。
【発明の効果】
【０００６】
本発明によれば、クライアント装置から受け付けたリクエストを処理する複数のサーバ装置において、リクエストを処理する機能が連続的に停止することを防止することが可能である。
【発明を実施するための最良の形態】
【０００７】
以下、本発明を実施するための最良の形態（以下「実施形態」という）について、図面を参照して説明する。
【０００８】
図１は、本実施形態におけるサーバ装置が複数接続されたリクエスト処理システムの構成を示す図である。図１に示すように、本実施形態におけるリクエスト処理システム１は、クライアント装置２０と、サーバ装置１０Ａと、サーバ装置１０Ｂとを含んで構成されている。クライアント装置２０、サーバ装置１０Ａおよびサーバ装置１０Ｂは、ネットワーク３０を介して相互に通信可能に構成されている。サーバ装置１０Ａおよびサーバ装置１０Ｂは、冗長構成（同様の構成）であり、ここではサーバ装置１０が２台示されているが、複数であれば特にその数が限定されるものではない。また、クライアント装置２０は３台示されているが、複数であれば特にその数が限定されるものではない。
【０００９】
クライアント装置２０は、ネットワーク３０を介してサーバ装置１０にリクエストを送信する機能を有するとともに、サーバ装置１０からそのリクエストに対するレスポンスを受け取る機能を有する。
【００１０】
サーバ装置１０は、ＣＰＵ（Central Processing Unit）１００と、メモリ２００とを含んで構成される。記憶部としてのメモリ２００は、アプリケーションサーバ処理プログラム２１０と、監視サーバ処理プログラム２２０と、モジュールプログラム（リクエスト送出力モジュールプログラム）２３０と、Ｗｅｂサーバ処理プログラム２４０と、監視サーバ定義ファイル２５０と、モジュールカウンタテーブル２６０と、Ｗｅｂサーバリクエスト受付統計情報２７０とを含んで記憶する機能を有する。処理部としてのＣＰＵ１００は、メモリ２００に記憶されているプログラムを実行する機能を有する。
【００１１】
アプリケーションサーバ処理プログラム２１０は、モジュールプログラム２３０からリクエストが入力されると、そのリクエストの処理を実行し、モジュールプログラム２３０にその実行結果としてのレスポンスを出力するコードが記述されたプログラムである。
【００１２】
監視サーバ処理プログラム２２０は、リクエストを処理する機能（アプリケーションサーバ処理プログラム２１０がＣＰＵ１００に実行されることによって実現する機能）を監視し、その停止を検知すると、監視サーバ定義ファイル２５０から取得したリソースの識別子およびアクションを他のサーバ装置１０およびモジュールプログラム２３０に通知するコードが記述されたプログラムである。他のサーバ装置１０は、リソースの識別子およびアクションが通知されることによって、通知されたリソースの識別子を指定するリクエストを受信した場合の処理を制御することが可能になる。つまり、監視サーバ処理プログラム２２０は、他のサーバ装置１０のリクエスト処理を制御するリクエスト処理制御プログラムとしてのプログラムである。ここで、リソースとは、クライアント装置２０がサーバ装置１０を介して取得可能な情報であり、例えば、電子文書や画像などの情報である。リソースの識別子とは、クライアント装置からのリクエストによって指定されるものであり、このリソースの識別子には、例えば、ＵＲＩ（Uniform Resource Identifier）が用いられる。さらに、監視サーバ処理プログラム２２０は、他の装置からリソースの識別子およびアクションを受信すると、受信したリソースの識別子およびアクションをモジュールプログラム２３０に出力するコードが記述されたプログラムである。監視サーバ定義ファイル２５０については後記する。さらに、リソースの識別子およびアクションを監視サーバ定義ファイル２５０から取得する方法についても後記する。
【００１３】
モジュールプログラム２３０は、監視サーバ処理プログラム２２０からリソースの識別子およびアクションが入力されると、モジュールカウンタテーブル２６０にデータを登録するコードが記述されたプログラムである。モジュールカウンタテーブル２６０については後記する。また、モジュールプログラム２３０は、Ｗｅｂサーバ処理プログラム２４０からリクエストが入力されると、モジュールカウンタテーブル２６０に従って、アプリケーションサーバ処理プログラム２１０で処理させるリクエストの制御を行うコードが記述されたプログラムである。さらに、アプリケーションサーバ処理プログラム２１０からレスポンスが入力されると、Ｗｅｂサーバ処理プログラム２４０にレスポンスを出力するコードが記述されたプログラムである。
【００１４】
Ｗｅｂサーバ処理プログラム２４０は、クライアント装置２０からリクエストを受け付けると、モジュールプログラム２３０にリクエストを出力するコードが記述されたプログラムである。また、Ｗｅｂサーバ処理プログラム２４０は、モジュールプログラム２３０からレスポンスが入力されると、クライアント装置２０に送信するコードが記述されたプログラムである。さらに、Ｗｅｂサーバ処理プログラム２４０は、Ｗｅｂサーバリクエスト受付統計情報２７０に含まれるリクエストの受け付け状況に関する情報を所定の時間ごと（例えば、１秒ごと）に更新するコードが記述されたプログラムである。Ｗｅｂサーバリクエスト受付統計情報２７０およびそれに含まれるリクエストの受け付け状況に関する情報については後記する。
【００１５】
図２は、本実施形態におけるリクエスト処理システムが２台のサーバ装置を含む場合の処理の流れを示す図である。図２に示すように、ここでは、リクエスト処理システム１が、クライアント装置２０と、２台のサーバ装置１０（サーバ装置１０Ａおよびサーバ装置１０Ｂ）とを含んで構成される場合を例に挙げて、サーバ装置１０Ａによるリクエスト処理の機能が停止した場合に、サーバ装置１０（サーバ装置１０Ａおよびサーバ装置１０Ｂ）がそのリクエストの受信を拒否する処理について説明する（適宜図１参照）。また、アプリケーションサーバ処理部３１０、監視サーバ処理部３２０、モジュール部３３０およびＷｅｂサーバ処理部３４０は、それぞれアプリケーションサーバ処理プログラム２１０、監視サーバ処理プログラム２２０、モジュールプログラム２３０およびＷｅｂサーバ処理プログラム２４０がＣＰＵ１００によって実行されることによって実現されるものである。また、モジュール部３３０は、Ｗｅｂサーバ処理部３４０のプロセス上で動作するものである。
【００１６】
クライアント装置２０から送信されたリクエスト（http://・・・/hoge.jsp）をアプリケーションサーバ処理部３１０Ａが受け付けて処理を行おうとしたが、問題が発生し（１つのリクエストでメモリを大量に消費してしまうような不具合がサーバ装置１０Ａのアプリケーションサーバ処理プログラム２１０に存在した場合や、サーバ装置１０Ａが悪意のあるリクエストを受け付けた場合など）、アプリケーションサーバ処理部３１０Ａがダウン（リクエストを処理する機能が停止）したとする。監視サーバ処理部３２０Ａは、アプリケーションサーバ処理部３１０Ａのプロセスが存在するか否かを所定の時間ごと（例えば、１秒ごと）に監視しており、アプリケーションサーバ処理部３１０Ａがダウンしたことを検知すると（ステップＳ１００１）、Ｗｅｂサーバ処理部３４０Ａが保持するＷｅｂサーバリクエスト受付統計情報２７０からデータを取得して、解析を行う（ステップＳ１００２）。解析の際には、Ｗｅｂサーバリクエスト受付統計情報２７０から取得したデータと、自己が保持する監視サーバ定義ファイル２５０のデータとを比較する。
【００１７】
監視サーバ処理部３２０Ａは、解析した後にリクエスト（http://・・・/hoge.jsp）を受信拒否すると判定すると、リクエスト（http://・・・/hoge.jsp）を受信拒否する旨の通知を、監視サーバ処理部３２０Ｂおよびモジュール部３３０Ａに行う（ステップＳ１００３）。監視サーバ処理部３２０Ｂは、モジュール部３３０Ｂに対してリクエスト受信拒否の通知を行う（ステップＳ１００４）。モジュール部３３０Ａは、クライアント装置２０から、Ｗｅｂサーバ処理部３４０Ａを介して受け付けたリクエスト（http://・・・/hoge.jsp）がＷｅｂサーバ処理部３４０Ａから入力された場合には、以降の処理でリクエストをアプリケーションサーバ処理部３１０Ａに出力しないようにし、Ｗｅｂサーバ処理部３４０Ａを介してクライアント装置２０にエラーを出力することでリクエスト受信拒否を行う（ステップＳ１００５）。同様に、モジュール部３３０Ｂは、クライアント装置２０から受け付けたリクエスト（http://・・・/hoge.jsp）がＷｅｂサーバ処理部３４０Ｂから入力された場合には、以降の処理でリクエストをアプリケーションサーバ処理部３１０Ｂに出力しないようにし、Ｗｅｂサーバ処理部３４０Ｂを介してクライアント装置２０にエラーを出力することでリクエスト受信拒否を行う（ステップＳ１００６）。
【００１８】
図３は、本実施形態におけるＷｅｂサーバリクエスト受付統計情報の構成を示す図である。図３に示すように、Ｗｅｂサーバリクエスト受付統計情報２７０は、ＵＲＩ（リソースの識別子）２７１と、リクエストの受け付け状況に関する情報２７６とを含んで構成される。ここでは、リクエストの受け付け状況に関する情報２７６として、カウンタ２７３、１秒あたりのリクエスト数２７４、平均レスポンスタイム２７５が示されており、各項目の値は、時間２７２ごとに設定されている。
【００１９】
ＵＲＩ２７１は、クライアント装置２０（図１参照）からのリクエストによって指定されるリソースの識別子である。
【００２０】
カウンタ２７３は、時間２７２あたり（秒・分・時間・日）に成功したリクエスト処理数の累計である「成功」と、時間２７２あたり（秒・分・時間・日）に失敗したリクエスト処理数の累計である「失敗」とを含む。「成功」としては、例えば、ＨＴＴＰ（HyperText Transfer Protocol）ステータスコード：２００番台から３００番台のレスポンス数を用い、「失敗」としては、例えば、ＨＴＴＰステータスコード：５００番台のレスポンス数を用いることができる。また、「成功」にＨＴＴＰステータスコード：１００番台のレスポンス数を加えるようにしてもよいし、「失敗」にＨＴＴＰステータスコード：４００番台のレスポンス数を累計に加えるようにしてもよい。
【００２１】
１秒あたりのリクエスト数２７４は、１秒間にクライアント装置２０（図１参照）から受け付けたリクエスト数を、時間２７２（秒・分・時間・日）単位の平均値として算出した値である。例えば、１秒あたりのリクエスト数２７４（「日」単位の平均値）が9.1リクエスト数／秒で、１秒あたりのリクエスト数２７４（「分」単位の平均値）が12.7リクエスト数／秒の場合には、現在から遡って１分の間は、リクエストの受け付けによる負荷が高い状態（ピーク状態）になっている可能性があると判断できる。また、１秒あたりのリクエスト数２７４の代わりに、他の単位時間あたりのリクエスト数を用いてもよく、例えば、１分あたりのリクエスト数、１時間あたりのリクエスト数などを用いてもよい。
【００２２】
平均レスポンスタイム２７５は、Ｗｅｂサーバ処理部３４０（図２参照）がクライアント装置２０（図２参照）からリクエストを受け付けてからクライアント装置２０（図２参照）にレスポンスを返すまでの処理時間を、時間２７２（秒・分・時間・日）単位の平均値として算出した値である。例えば、平均レスポンスタイム２７５（「日」単位の平均値）が18.5ミリ秒で、平均レスポンスタイム２７５（「分」単位の平均値）が25.6ミリ秒の場合には、現在から遡って１分の間は、リクエストを受け付けてからレスポンスを返すまでに多くの時間を要していることから、リクエストの受け付けによる負荷が高い時間状態（ピーク状態）になっている可能性があると判断できる。
【００２３】
Ｗｅｂサーバリクエスト受付統計情報２７０は、運用上リクエスト処理の状況を確認するために利用されるようにしてもよい。また、Ｗｅｂサーバリクエスト受付統計情報２７０は、Ｗｅｂサーバリクエスト受付統計情報２７０をクリアすることもできる。
【００２４】
図４は、本実施形態における監視サーバ定義ファイルの構成を示す図である。図４に示すように、監視サーバ定義ファイル２５０は、ＵＲＩ２５１と、条件２５２と、アクション２５３とを含んで構成される。この監視サーバ定義ファイル２５０のデータは、例えば、管理者（不図示）などによって定義されるものである。また、メモリ２００（図１参照）は、すくなくともＵＲＩ２５１と、条件２５２と、アクション２５３と、リクエストの受け付け状況に関する情報２７６（図３参照）とを対応させた情報を記憶する。
【００２５】
ＵＲＩ２５１は、クライアント装置２０（図１参照）からのリクエストによって指定されるリソースの識別子である。ここでは、ＵＲＩ２５１として、”/”のコンテキストルートから始まるＵＲＩが定義してある。また、３行目のデータのように、ＵＲＩ２５１の中に“*”をワイルドカードとして使用してもよい。このように、監視サーバ定義ファイル２５０をＵＲＩ２５１別に定義しておくことによって、例えばログイン画面を表示させるリクエストを受信拒否しない（監視サーバ定義ファイル２５０に設定しない）ようにしておけば、クライアント装置２０からログインができなくなることを防止できる。
【００２６】
条件２５２は、リクエストに対する処理の制御が実行されるための条件である。条件２５２としては、Ｗｅｂサーバリクエスト受付統計情報２７０（図３参照）のカウンタ２７３、リクエスト数２７４および平均レスポンスタイム２７５のうち、いずれの項目を用いてもよいし、それらの項目を組み合わせて条件２５２を構成するようにしてもよい。また、条件２５２に、しきい値（例えば、平均レスポンスタイム２７５のしきい値）を設定しておき、サーバ装置１０（図１参照）が、実測値としきい値とに基づいてリクエストに対する処理を実行するようにしてもよい（平均レスポンスタイムの実測値がしきい値よりも大きいと判定した場合に、リクエストに対する処理の制御を実行するなど）。
【００２７】
アクション２５３は、リクエストに対する処理の制御を実行する際の処理内容である。ここでは、アクション２５３にリクエストの「流量制御」「受信拒否」などが定義されている。「流量制御」の「同時処理数」は、アプリケーションサーバ処理部３１０で同時に処理できるリクエスト数の上限値であり、「流量制御」の「キュー」は、リクエスト処理待ちとして、キューに格納できるリクエスト数の上限値を示している。また、「受信拒否」は、「流量制御（同時処理数：０）」と同じ意味であるため、アクション２５３には「受信拒否」の代わりに、「流量制御（同時処理数：０）」を設定してもよい。アクション２５３としては、「同時処理数」および「キュー」のいずれか一方を用いてもよいし、双方を設定してもよい。
【００２８】
図５は、本実施形態におけるモジュールカウンタテーブルの構成を示す図である。モジュールカウンタテーブル２６０は、ＵＲＩ２６１を含み、監視サーバ定義ファイル２５０（図４参照）に「同時処理数」が定義されている場合には、すくなくとも上限値２６２と、リクエストカウンタ２６３とを含んで構成され、監視サーバ定義ファイル２５０（図４参照）に「キュー」が定義されている場合には、すくなくともキューサイズ２６４と、キューカウンタ２６５とを含んで構成されるものである。
【００２９】
ＵＲＩ２６１は、クライアント装置２０（図１参照）からのリクエストによって指定されるリソースの識別子である。
【００３０】
上限値２６２は、アプリケーションサーバ処理部３１０（図２参照）で同時に実行できるリクエストの最大数である。
【００３１】
リクエストカウンタ２６３は、アプリケーションサーバ処理部３１０（図２参照）で実行中のリクエストの数である。
【００３２】
キューサイズ２６４は、モジュール部３３０（図２参照）が保持するキューに格納できるリクエストの最大数である。
【００３３】
キューカウンタ２６５は、モジュール部３３０（図２参照）が保持するキューに格納されているリクエストの数である。
【００３４】
図６は、本実施形態におけるサーバ装置によるリクエスト処理の機能停止時の処理の流れを示すフローチャートである。図６を参照して（適宜図１ないし図５参照）、サーバ装置１０Ａが自己のリクエストを処理する機能の停止を検知する処理および検知した際に実行する処理の流れを説明する。
【００３５】
監視サーバ処理部３２０Ａは、アプリケーションサーバ処理部３１０Ａのプロセスを監視する（ステップＳ１０１）。すなわち、監視サーバ処理部３２０Ａは、所定の時間ごとにアプリケーションサーバ処理部３１０Ａにヘルスチェックの要求を送信し、アプリケーションサーバ処理部３１０Ａが正常なレスポンスを返すか否かで、アプリケーションサーバ処理部３１０Ａがダウンしているか否か（サーバ装置１０Ａのリクエストを処理する機能が停止しているか否か）を確認する。監視サーバ処理部３２０Ａが、アプリケーションサーバ処理部３１０Ａがダウンしていない（サーバ装置１０Ａのリクエストを処理する機能が停止していない）と判定した場合（ステップＳ１０２で「Ｎｏ」）、ステップＳ１０１に戻る。監視サーバ処理部３２０Ａが、アプリケーションサーバ処理部３１０Ａがダウンした（サーバ装置１０Ａのリクエストを処理する機能が停止した）と判定した場合（ステップＳ１０２で「Ｙｅｓ」）、監視サーバ処理部３２０Ａは、アプリケーションサーバ処理部３１０Ａを再起動する（ステップＳ１０３）。
【００３６】
次に、監視サーバ処理部３２０Ａは、監視サーバ定義ファイル２５０とＷｅｂサーバリクエスト受付統計情報２７０とを比較する（ステップＳ１０４）。すなわち、監視サーバ処理部３２０Ａは、監視サーバ定義ファイル２５０の条件２５２で使用される情報（監視サーバ定義ファイル２５０の１行目であればＷｅｂサーバリクエスト受付統計情報２７０の平均レスポンスタイム２７５（秒・分・時間・日））を、監視サーバ定義ファイル２５０のＵＲＩ２５１と同一のＵＲＩ２６１を有するＷｅｂサーバリクエスト受付統計情報２７０のデータから取得し、監視サーバ定義ファイル２５０の条件２５２を満たすＵＲＩ２５１が存在するか否かを解析する。
【００３７】
監視サーバ処理部３２０Ａは、条件に適合する情報が存在しないと判定した場合（ステップＳ１０５で「Ｎｏ」）、ステップＳ１０１に戻る。条件に適合する情報が存在すると判定した場合（ステップＳ１０５で「Ｙｅｓ」）、ステップＳ１０５で条件２５２を満たすと判定したデータのＵＲＩ２５１およびアクション２５３を、他の監視サーバ処理部３２０Ｂに通知する（ステップＳ１０６）。ここでは、他の監視サーバ処理部３２０Ｂは１台であるとしたが、複数であってもよい。
【００３８】
以下のステップＳ１０７〜ステップＳ１０９の処理は、サーバ装置１０Ａが、ステップＳ１０５で条件２５２を満たすと判定したデータのＵＲＩ２５１を指定するリクエストを受信した際にアクション２５３を実行することによって、リクエスト処理を制御するために行う。すなわち、監視サーバ処理部３２０Ａは、ステップＳ１０５で条件２５２を満たすと判定したデータのＵＲＩ２５１およびアクション２５３をモジュール部３３０Ａに出力する（ステップＳ１０７）。モジュール部３３０Ａは、モジュールカウンタテーブル２６０に情報を登録する（ステップＳ１０８）。すなわち、監視サーバ処理部３２０Ａから入力されたＵＲＩ２５１をモジュールカウンタテーブル２６０のＵＲＩ２６１に、監視サーバ処理部３２０Ａから入力されたアクション２５３の「同時処理数」を上限値２６２に、「キュー」をモジュールカウンタテーブル２６０のキューサイズ２６４に登録する。リクエストカウンタ２６３およびキューカウンタ２６５には、例えば「０」を設定しておく。
【００３９】
モジュール部３３０Ａは、Ｗｅｂサーバ処理部３４０Ａを再起動する（ステップＳ１０９）。このステップＳ１０９は、Ｗｅｂサーバ処理部３４０のプロセス上で動作しているモジュール部３３０が保持するモジュールカウンタテーブル２６０の変更を反映させるために行う。Ｗｅｂサーバ処理部３４０の再起動の方法には、処理中のリクエストが終了してから再起動を行い、再起動の間に受け付けたリクエストをＷｅｂサーバ処理部３４０のキューに格納する方法、リクエストの終了を待たずに強制的に再起動を行う方法などがある。その後、ステップＳ１０１に戻る。
【００４０】
図７は、本実施形態におけるリクエスト処理の機能停止の通知を受けたサーバ装置によって実行される処理の流れを示すフローチャートである。図７を参照して（適宜図１ないし図５参照）、サーバ装置１０Ａのリクエストを処理する機能が停止した際に、サーバ装置１０Ｂがサーバ装置１０Ａからその旨の通知を受け付ける処理および受け付けた際に実行する処理の流れを説明する。
【００４１】
監視サーバ処理部３２０Ｂは、監視サーバ処理部３２０Ａからアプリケーションサーバ処理部３１０Ａがダウンした旨の通知（サーバ装置１０Ａのリクエストを処理する機能が停止した旨の通知）として、ＵＲＩ２５１およびアクション２５３を受け付けたか否かを判定する（ステップＳ２０１）。ＵＲＩ２５１およびアクション２５３を受け付けていない場合には（ステップＳ２０１で「Ｎｏ」）、受け付けるまでステップＳ２０１を繰り返す。ＵＲＩ２５１およびアクション２５３を受け付けた場合には（ステップＳ２０１で「Ｙｅｓ」）、監視サーバ処理部３２０Ｂは、監視サーバ処理部３２０Ａから受け付けたＵＲＩ２５１およびアクション２５３をモジュール部３３０Ｂに出力する（ステップＳ２０２）。
【００４２】
モジュール部３３０Ｂは、監視サーバ処理部３２０Ｂから入力されたＵＲＩ２５１およびアクション２５３を、モジュールカウンタテーブル２６０に登録する（ステップＳ２０３）。登録の方法については、ステップＳ１０８（図６参照）と同様である。モジュール部３３０Ｂは、Ｗｅｂサーバ処理部３４０Ｂを再起動する（ステップＳ２０４）。再起動の方法については、ステップＳ１０９と同様である。その後、ステップＳ２０１に戻る。
【００４３】
図８は、本実施形態におけるモジュール部によるリクエスト受信時の処理の流れを示すフローチャートである。図８を参照して（適宜図１ないし図５参照）、サーバ装置１０のモジュール部３３０がＷｅｂサーバ処理部３４０からリクエストを受信する処理および受信した際に実行する処理の流れを説明する。
【００４４】
モジュール部３３０は、Ｗｅｂサーバ処理部３４０からリクエストを受信したか否かを判定する（ステップＳ３０１）。リクエストを受信していない場合には（ステップＳ３０１で「Ｎｏ」）、受信するまでステップＳ３０１を繰り返す。リクエストを受信した場合には（ステップＳ３０１で「Ｙｅｓ」）、アプリケーションサーバ処理部３１０がダウンしているか否かの判定を行う（ステップＳ３０２）。アプリケーション処理部３１０がダウンしている場合には（ステップＳ３０２で「Ｙｅｓ」）、他のアプリケーションサーバ処理部３１０にリクエストを転送して（ステップＳ３０３）、ステップＳ３０１に戻る。この転送は、Ｗｅｂサーバ処理部３４０を介して行われる。また、ここでは、ステップＳ１０３（図６参照）のアプリケーションサーバ処理部３１０の再起動の処理が未完了の場合などに、アプリケーションサーバ処理部３１０がダウンしている可能性がある。
【００４５】
アプリケーション処理部３１０がダウンしていない場合（ステップＳ３０２で「Ｎｏ」）、モジュール部３３０は、受信したリクエストによって指定されるＵＲＩが、モジュールカウンタテーブル２６０に登録されているか否かを判定する（ステップＳ３０４）。登録されていないと判定した場合には（ステップＳ３０４で「Ｎｏ」）、アプリケーションサーバ処理部３１０にリクエストを出力し（ステップＳ３０５）、ステップＳ３０１に戻る。登録されていると判定した場合には（ステップＳ３０４で「Ｙｅｓ」）、モジュールカウンタテーブル２６０の上限値２６２が「０」であるか否かを判定する（ステップＳ３０６）。ここでの上限値２６２は、モジュール部３３０が受信したリクエストによって指定されるＵＲＩでモジュールカウンタテーブル２６０を検索して、該当したものである。
【００４６】
上限値２６２が「０」の場合（ステップＳ３０６で「Ｙｅｓ」）、Ｗｅｂサーバ処理部３４０にエラーを出力し（ステップＳ３０７）、ステップＳ３０１に戻る。上限値が「０」ではなかった場合（ステップＳ３０６で「Ｎｏ」）、上限値２６２がリクエストカウンタ２６３よりも大きいか否かを判定する（ステップＳ３０８）。ここでの上限値２６２およびリクエストカウンタ２６３は、モジュール部３３０が受信したリクエストによって指定されるＵＲＩでモジュールカウンタテーブル２６０を検索して、該当したものである。なお、ステップＳ３０８で使用する上限値２６２およびリクエストカウンタ２６３は、ステップＳ３０６の判定を行う際に取得してもよい。
【００４７】
上限値２６２がリクエストカウンタ２６３以下の場合（上限値２６２がリクエストカウンタ２６３より大きくない場合）（ステップＳ３０８で「Ｎｏ」）、キューサイズ２６４がキューカウンタよりも大きいか否かを判定する（ステップＳ３０９）。ここでのキューサイズ２６４およびキューカウンタ２６５は、モジュール部３３０が受信したリクエストによって指定されるＵＲＩでモジュールカウンタテーブル２６０を検索して、該当したものである。なお、ステップＳ３０９で使用するキューサイズ２６４およびキューカウンタ２６５は、ステップＳ３０６の判定を行う際に取得してもよい。
【００４８】
キューサイズ２６４がキューカウンタ２６５以下の場合（キューサイズ２６４がキューカウンタ２６５より大きくない場合）（ステップＳ３０９で「Ｎｏ」）、Ｗｅｂサーバ処理部３４０にエラーを出力し（ステップＳ３１０）、ステップＳ３０１に戻る。
【００４９】
キューサイズ２６４がキューカウンタ２６５よりも大きい場合（ステップＳ３０９で「Ｙｅｓ」）、キューカウンタ２６５に「１」を加算し（ステップＳ３１１）、リクエスト処理待ちの処理を行い（ステップＳ３１２）、ステップＳ３０１に戻る。ここで「１」が加算されるキューカウンタ２６５は、モジュール部３３０が受信したリクエストによって指定されるＵＲＩでモジュールカウンタテーブル２６０を検索して、該当したものである。リクエスト処理待ちの処理とは、リクエストをキューに格納して、アプリケーションサーバ処理部３１０にリクエストを転送するのを保留することである。また、キューにリクエストを格納するとともに、その格納順番を、「１」を加算した後のキューカウンタ２６５の値とする。
【００５０】
上限値２６２がリクエストカウンタ２６３より大きい場合（ステップＳ３０８で「Ｙｅｓ」）、リクエストカウンタ２６３に「１」を加算し（ステップＳ３１３）、アプリケーションサーバ処理部３１０にリクエストを出力して（ステップＳ３１４）、ステップＳ３０１に戻る。ここで「１」が加算されるリクエストカウンタ２６３は、モジュール部３３０が受信したリクエストによって指定されるＵＲＩでモジュールカウンタテーブル２６０を検索して、該当したものである。
【００５１】
図９は、本実施形態におけるモジュール部によるレスポンス受信時の処理の流れを示すフローチャートである。図９を参照して（適宜図１ないし図５参照）、サーバ装置１０のモジュール部３３０がアプリケーションサーバ処理部３１０からレスポンスを受信する処理および受信した際に実行する処理の流れを説明する。
【００５２】
モジュール部３３０は、アプリケーションサーバ処理部３１０からレスポンスを受信したか否かを判定する（ステップＳ４０１）。レスポンスを受信していない場合には（ステップＳ４０１で「Ｎｏ」）、受信するまでステップＳ４０１を繰り返す。レスポンスを受信した場合には（ステップＳ４０１で「Ｙｅｓ」）、Ｗｅｂサーバ処理部３４０から受信したリクエストによって指定されるＵＲＩが、モジュールカウンタテーブル２６０に登録されているか否かを判定する（ステップＳ４０２）。登録されていないと判定した場合には（ステップＳ４０２で「Ｎｏ」）、Ｗｅｂサーバ処理部３４０にレスポンスを出力し（ステップＳ４０３）、ステップＳ４０１に戻る。登録されていると判定した場合には（ステップＳ４０２で「Ｙｅｓ」）、リクエストカウンタ２６３から「１」を減算し（ステップＳ４０４）、Ｗｅｂサーバ処理部３４０にレスポンスを出力する（ステップＳ４０５）。ここで「１」が減算されるリクエストカウンタ２６３は、モジュール部３３０が受信したリクエストによって指定されるＵＲＩでモジュールカウンタテーブル２６０を検索して、該当したものである。
【００５３】
続いて、モジュール部３３０は、キュー待ちのリクエストが存在するか否かを判定する（ステップＳ４０６）。キュー待ちのリクエストが存在しない場合には（ステップＳ４０６で「Ｎｏ」）、ステップＳ４０１に戻る。キュー待ちのリクエストが存在する場合には（ステップＳ４０６で「Ｙｅｓ」）、格納順番が１（最初）のリクエストをアプリケーションサーバ処理部３１０に出力し（ステップＳ４０７）、キューに格納されている各リクエストの格納順番から「１」を減算し（ステップＳ４０８）、リクエストカウンタ２６３に「１」を加算し（ステップＳ４０９）、キューカウンタ２６５から「１」を減算して（ステップＳ４１０）、ステップＳ４０１に戻る。ここで「１」が加算されるリクエストカウンタ２６３および「１」を減算されるキューカウンタ２６５は、モジュール部３３０が受信したリクエストによって指定されるＵＲＩでモジュールカウンタテーブル２６０を検索して、該当したものである。
【００５４】
以上において説明したように、本実施形態におけるリクエスト処理システム１は、ネットワーク３０を介してクライアント装置２０から受け付けたリクエストを処理する複数のサーバ装置１０が、相互通信可能に構成されている。サーバ装置１０Ａは、クライアント装置２０からのリクエストによって指定されるリソースの識別子（例えば、ＵＲＩ２５１）と、リクエストに対する処理の制御が実行されるための条件２５２と、制御の処理内容であるアクション２５３と、リクエストの受け付け状況に関する情報２７６（例えば、時間２７２、カウンタ２７３、１秒あたりのリクエスト数２７４および平均レスポンスタイム２７５）とを対応させた情報をメモリ２００に記憶している。そして、サーバ装置１０Ａの監視サーバ処理部３２０Ａは、アプリケーションサーバ処理部３１０Ａのプロセスのダウン（自己のリクエストを処理する機能の停止）を検知すると、リクエストの受け付け状況に関する情報２７６が、対応する条件２５２を満たす場合に、メモリ２００からＵＲＩ２５１およびアクション２５３を取得して他のサーバ装置１０Ｂの監視サーバ処理部３２０Ｂに通知する。これによって、クライアント装置２０から受け付けたリクエストを処理する機能がサーバ装置１０Ａで停止しても、ＵＲＩ２５１およびアクション２５３を通知されたサーバ装置１０Ｂにおいて、通知されたＵＲＩ２５１を指定するリクエストに対する処理を、通知されたアクション２５３が示すように制御できるため、リクエストを処理する機能が停止することを防止することができる。つまり、複数のサーバ装置において、リクエストを処理する機能が連続的に停止することを防止することができる。
【図面の簡単な説明】
【００５５】
【図１】本実施形態におけるサーバ装置が複数接続されたリクエスト処理システムの構成を示す図である。
【図２】本実施形態におけるリクエスト処理システムが２台のサーバ装置を含む場合の処理の流れを示す図である。
【図３】本実施形態におけるＷｅｂサーバリクエスト受付統計情報の構成を示す図である。
【図４】本実施形態における監視サーバ定義ファイルの構成を示す図である。
【図５】本実施形態におけるモジュールカウンタテーブルの構成を示す図である。
【図６】本実施形態におけるサーバ装置によるリクエスト処理の機能停止時の処理の流れを示すフローチャートである。
【図７】本実施形態におけるリクエスト処理の機能停止の通知を受けたサーバ装置によって実行される処理の流れを示すフローチャートである。
【図８】本実施形態におけるモジュール部によるリクエスト受信時の処理の流れを示すフローチャートである。
【図９】本実施形態におけるモジュール部によるレスポンス受信時の処理の流れを示すフローチャートである。
【符号の説明】
【００５６】
１      リクエスト処理システム
１０（１０Ａ，１０Ｂ）  サーバ装置
２０    クライアント装置
３０    ネットワーク
１００  ＣＰＵ
２００  メモリ
２１０  アプリケーションサーバ処理プログラム
２２０  監視サーバ処理プログラム
２３０  モジュールプログラム
２４０  Ｗｅｂサーバ処理プログラム
２５０  監視サーバ定義ファイル
２５１  ＵＲＩ（リソースの識別子）
２５２  条件
２５３  アクション
２６０  モジュールカウンタテーブル
２６１  ＵＲＩ
２６２  上限値
２６３  リクエストカウンタ
２６４  キューサイズ
２６５  キューカウンタ
２７０  Ｗｅｂサーバリクエスト受付統計情報
２７１  ＵＲＩ（リソースの識別子）
２７２  時間（リクエストの受け付け状況に関する情報）
２７３  カウンタ（リクエストの受け付け状況に関する情報）
２７４  １秒あたりのリクエスト数（リクエストの受け付け状況に関する情報）
２７５  平均レスポンスタイム（リクエストの受け付け状況に関する情報）
【図１】
2008108163.tif 000003
【図２】
2008108163.tif 000004
【図３】
2008108163.tif 000005
【図４】
2008108163.tif 000006
【図５】
2008108163.tif 000007
【図６】
2008108163.tif 000008
【図７】
2008108163.tif 000009
【図８】
2008108163.tif 000010
【図９】
2008108163.tif 000011