JP2009146005A - 情報処理装置および情報処理方法 - Google Patents

Abstract

【課題】クライアント側での特別な処理を必要とせずに、一部のクライアントからのアクセスの集中を減らすことによってサーバが過負荷になることを防止し、全てのクライアント（ユーザ）に一定のサービスレベルでサービス提供可能な情報処理装置および情報処理方法を提供すること。
【解決手段】サーバはクライアントから送信されるリクエストを監視し、リクエストの受信間隔が閾値を超えない場合、エラーとしてビジネスロジックを実行しない。また、エラーレスポンスをクライアントに返信する際に返信タイミングを制御することによって、次回クライアントからリクエストが再送信されるタイミングを制御する。
【選択図】図１０

Description

本発明は、情報処理装置および情報処理方法に関するものである。より詳細には、クライアント／サーバシステムのようにクライアントがサーバの資源を利用する方法において、上記サーバへのアクセスの集中を改善する処理を行う情報処理装置および情報処理方法に関するものである。

近年のインターネットの普及により、インターネット上で様々なＡＳＰ（アプリケーション・サービス・プロバイダ）サービスが提供されている。ＡＳＰサービスとはインターネットを通じてアプリケーションを顧客に提供するサービスである。ＡＳＰサービス提供者は、ＡＳＰサービスを提供するシステムをエンドユーザに共用してもらう形式でサービスを提供している。このことによって、ＡＳＰサービスは、エンドユーザが比較的安価にサービスを利用することができる、エンドユーザ側でのサーバ管理作業が不要であるといったメリットを有する。

ＡＳＰサービスは、インターネット上で提供されるサービスであるので、様々なユーザに利用されている。例えば、ある企業の従業員が業務を行うために利用している場合もあれば、コンシューマが個人の趣味のために利用している場合もある。このように様々な種類のユーザが利用しているということは、「ＡＳＰサービスを利用するそれぞれのユーザがサービスを利用する時間も目的も様々である」、ということが言える。

「ＡＳＰサービスを利用するそれぞれのユーザがサービスを利用する時間も目的も様々である」ということは、ＡＳＰサービスが停止してしまうと、場合によってはユーザの業務が停止してしまい多くのユーザに迷惑をかけてしまう。

また、ある企業Ａでは多くの人が同時にアクセスしてサービスを利用したい時に、他の企業Ｂでは一人の人が重要な業務のためにサービスを利用したいといった場合もある。このような場合に、企業Ａのユーザからのアクセスに対する処理負荷が増加することにより、企業Ｂのユーザからのアクセスに対する処理ができないといった状況が発生してしまうと、企業Ｂのユーザに迷惑をかけてしまう。

上述のような状況を発生させないために、 “サービスとして停止しないこと”と同時に“ある特定のユーザに偏ることなくサービスを提供する”ということがＡＳＰサービスでは重要視される。

しかしながら、ＡＳＰサービスにおいてアクセスの集中や急増といった現象が発生する可能性は常にある。例えば、特定の時間にサーバに対するアクセスが集中する（例えば、月曜の朝一にアクセスが集中する）、といった場合が考えられる。また、何らかの事情により想定を超えてアクセスが急増する（例えば、台風など異常気象時に気象情報や交通情報サイトへのアクセスの急増する）、といった場合も考えられる。これらのアクセスの集中や急増によって、サーバに対する負荷が増大し最悪サーバが停止してしまう可能性もある。

また、近年、Ｗｅｂサービスなどの技術が発達し、インターネット上のサービスのインターフェース（ＡＰＩ）を、任意のクライアントアプリケーションに公開することが行われている。インターフェースを公開するということは、インターネット上のサービスを提供するサーバに対して任意のクライアントアプリケーションが様々な形でアクセス可能になるということである。つまり、一旦、インターネット上のサービスのインターフェースを公開すると、ＡＳＰ事業者が関知しないところで任意の誰かがクライアントアプリケーションを開発してサーバにアクセスすることが可能となる、ということになる。開発したクライアントアプリケーションからのアクセスはＷｅｂブラウザのようにユーザの思考時間がなく、連続的にアクセスされる場合も想定される。そのため、サーバ側にとって、意図的な攻撃ではなく、想定を超えたアクセスが急増する機会が増えつつあるとも考えられる。

このような状況に対して、それぞれのＡＳＰサービス提供者は、サーバに対するアクセスの急増による負荷への対策を行っている。ここで、アクセスの急増とは、クライアントからサーバへ送信されるリクエストが急増することを意味する。サーバへのリクエストが増えると（集中すると）、サーバの処理負荷が高くなる状態を引き起こす。これに対して、ＡＳＰサービスで行っているサーバへのアクセスの急増による負荷への対策は「処理するリクエストを如何に絞り込むか」という観点で行われているものが多い。ＡＳＰサービスで行っているアクセスの急増に対する負荷への一般的な対策として次の３つが挙げられる。
対策１） ユーザ認証などでアクセス可能なユーザ数を絞り込む。
対策２） 図１３のようにサーバの台数を増やし、一台一台のサーバが処理するリクエストを分散させる。
対策３） 一台一台のサーバにおいてセッション数に制限を設け、一度に処理するセッション数を絞り込む。

ＡＳＰサービスでは前述の３つの対策全てを行っている場合が多い。すなわち、対策１でアクセス可能なユーザ数自体を絞り込み、サーバへ送信することが可能なリクエストの絶対量を制限する。次に対策２でサーバの処理能力をある程度確保する。更に、対策３で、対策２で用意したサーバ資源を超えた処理能力が必要な数のリクエストがクライアントから送信されてきた場合の対策としてリクエスト数を更に絞り込む、といった対策を行っている。

図１４と図１５は対策３を説明するための図である。
図１４のように、複数のサーバを用意し、クライアントから送信されるリクエストを一台一台のサーバに振り分けて負荷分散を行う場合を考える。図１４は図１３の負荷分散を行っている状態から更にリクエストが増加した場合を示している。このような場合、負荷分散を行っているにもかかわらず、一台一台のサーバが処理するリクエスト数が結果的に増加してしまい、サーバの処理負荷が増大してしまう。

図１５は個々のサーバの内部処理を示している。図１５では、リクエスト受信手段１３００がクライアントからのリクエストを受信するが、予め設定されているセッション数を超えたリクエストに関しては、リクエスト受信手段１３００はクライアントにエラーを返す。つまり、サービス提供手段１３０１に対してセッション数を越えたリクエストは送信されず、内部的な処理（サービス提供手段での処理）は実行されない。このようにセッション数に制限を設けることにより、サーバ全体としての処理負荷が減少することになる。

以上のようにして、ＡＳＰサービスを提供するサーバはアクセスの急増による負荷に対する対策を行っている。

また、特許文献１には、クライアント／サーバシステムにおいて、サーバへのアクセスの集中を改善する処理技術が提案されている。特許文献１に記載の発明は、クライアントからのサービス開始リクエストをサーバが受信した際に、サーバは整理券を発行しクライアントに返信する。整理券には次回リクエストを送信する際の送信期間が指定されており、クライアントは整理券に指定された期間中に再度リクエストを再送する、といったものである。

特許文献１では、サーバからクライアントにアクセス可能な時間を指定し、クライアントは指定された時間にリクエストを送信する。つまり、サーバがある時間中に処理するリクエスト数を制御することによって、サーバ側へのリクエストの集中を回避する、といったものである。

特開２００２−１８９６５０号公報

しかしながら、上述した対策１〜３を行う従来の技術では、セッションを開始したクライアントからのリクエストについてはサーバ（のサービス提供手段）で処理するように構成している。しかしながら、セッションを開始した１つのクライアントが、その同じセッション中に連続して集中的にリクエストを送信してくると、結果的に、一台一台のサーバにリクエストが集中してサーバの処理負荷が急増してしまう、といった問題は発生してしまう。

上述した対策１〜３を行う従来の技術において、一台一台のサーバにリクエストが集中してサーバの処理負荷が急増してしまう、といった状況が発生する様子を図１６と図１７を用いて説明する。上述した対策１〜３を行ったシステムにおいて、あるクライアントＡから送信されたリクエストがサーバ側で受け付けられたとする。一度、サーバ側でリクエストが受け付けられるとセッションが開始され、セッション終了までクライアントＡから送信されるリクエストは受け付けられ、サーバ側で処理される。したがって、図１６のように一度セッションが開始された複数のクライアントから連続的に集中してリクエストが送信されると、図１７のように一台一台のサーバでは全てのリクエストを処理することになる。

このような場合、対策３のセッション数制限により、サーバはセッションを新たに開始しようとしている他のクライアントアプリケーションからのリクエストに応答することができない、といった状況が発生する場合がある。つまり、インターネット上で広くユーザにサービスを提供しているにも関わらず、全てのユーザに一定のサービスレベルでサービスを提供することができなくなってしまう。例えば、一部のユーザはサービスを全く利用することができなくなってしまうこともありうる。

また、特許文献１に開示された技術を利用してサーバへのリクエスト集中を回避するためには、クライアント側が、配布された整理券を理解するといった特別な機能が必要となる。しかしながら、汎用的なＷｅｂブラウザやＷｅｂサービスを利用するようなクライアントアプリケーションが必ずしも整理券を理解するといった機能を実装するとは限らない。

したがって、ＡＳＰサービスを実現するシステムは次のような課題の対策が望まれている。
課題１） 一度セッションが開始されたクライアントからのリクエストに偏ってしまい、全てのクライアント（ユーザ）に一定のサービスレベルでサービスを提供することができなくなってしまう状況に対処できるようにする。
課題２） 汎用的なＷｅｂブラウザやＷｅｂサービスを利用するクライアント側で特別な処理（例えば特許文献１のような機能）が実装されていなくても対処できるようにする。

本発明は、このような問題を鑑みてなされたものである。その目的とするところは、クライアント側での特別な処理を必要とせずに、サーバが過負荷になることを低減可能な情報処理装置および情報処理方法を提供することにある。

本発明は、このような目的を達成するために、情報処理装置であって、リクエストを受信するリクエスト受信手段と、前記リクエスト受信手段にて受信されたリクエストに関する情報であって、該受信したリクエストを拒否するか否かの判定に用いる情報を、リクエスト記録データベースに格納するリクエスト監視手段と、受信したリクエストを拒否する判定を行う基準値を管理するリクエスト監視設定値管理データベースと、前記リクエスト監視設定値管理データベースと前記リクエスト記録データベースとを参照して、前記リクエスト受信手段にて受信したリクエストを拒否するか否かを判定するリクエスト処理判定手段と、前記リクエスト処理判定手段が前記受信したリクエストを拒否すると判定した場合に、該拒否の判定から一定時間経過した後に、前記リクエストを送信したクライアントに対してエラーレスポンスを返信するエラーレスポンス送信手段とを備えることを特徴とする情報処理装置。

また、本発明は、情報処理方法であって、リクエストを受信するリクエスト受信工程と、前記リクエスト受信手段にて受信されたリクエストに関する情報であって、該受信したリクエストを拒否するか否かの判定に用いる情報を、リクエスト記録データベースに格納するリクエスト監視工程と、受信したリクエストを拒否する判定を行う基準値を管理するリクエスト監視設定値管理データベースと前記リクエスト記録データベースとを参照して、前記リクエスト受信工程にて受信したリクエストを拒否するか否かを判定するリクエスト処理判定工程と、前記リクエスト処理判定工程にて前記受信したリクエストを拒否すると判定した場合に、該拒否の判定から一定時間経過した後に、前記リクエストを送信したクライアントに対してエラーレスポンスを返信するエラーレスポンス送信工程とを有することを特徴とする。

本発明によれば、あるクライアントアプリケーションを利用するユーザだけがサーバの資源を占有してしまう、といった状況を回避しサーバへのアクセスの集中を改善することが可能である。同時に、レスポンスを返信するタイミングをサーバ側で制御することで、クライアントアプリケーションが次にリクエストを送信するまでの時間を制御することができる。このことによって、クライアント側での特別な処理を必要とせずにクライアントアプリケーションの連続的なアクセスを回避することが可能である。

以下、図面を参照して本発明の実施形態を詳細に説明する。なお、以下で説明する図面で、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
（第１の実施形態）
図１は、本実施形態を適用できる、インターネットなどネットワーク経由でサービスを提供するシステムの具体的なシステム構成例を示す図である。図１に示すように、サービスを提供するシステム１００、および複数のＰＣなどのクライアント端末１０２（１）、１０２（２）、…、１０２（Ｍ）がネットワーク１０３を介して接続されている。サービスを提供するシステム１００は、複数のサーバ１０１（１）、１０１（２）、…、１０２（Ｎ）を含んでいる。ネットワーク１０３はインターネット、イントラネットなどのネットワークを想定しているが、他のネットワークシステムであってもかまわない。

ここで、説明を簡略化するために、複数のサーバ１０１（１）、１０１（２）、…、１０１（Ｎ）の中で任意の１つのサーバを示す場合にはサーバ１０１（Ｘ）と記述する。また、複数のクライアント端末１０２（１）、１０２（２）、…、１０２（Ｍ）の中で任意の１つのクライアント端末を示す場合にはクライアント端末１０２（Ｙ）と記述する。

図２は、本実施形態に係る、インターネットなどネットワーク経由でサービスを提供するシステムのサーバの具体的なシステム構成例を示す図である。つまり、図１におけるサービスを提供するシステム１００のシステム構成図である。
サーバ１０１（１）、１０１（２）、…、１０１（Ｎ）はサービスを提供するための処理を実行するサーバ群であって、任意のサーバ１０１（Ｘ）は他の任意のサーバ（Ｘ'）とＬＡＮなどのネットワークで接続されている。

符号２００はファイアウォールであって、インターネットなどのネットワーク１０３との接続口に設置され、後述のロードバランサ２０１とＬＡＮなどのネットワークで接続されている。ファイアウォール２００はネットワーク１０３とロードバランサ２０１間でやり取りされる通信データを補足し、サービスを提供するシステム１００におけるポリシーにしたがって通信データの通過を許可する、禁止するといった制御を行う。このことによって、ネットワーク１０３からサーバ１０１（Ｘ）に対する不正なアクセスを防ぎ、必要なサービスだけをユーザに提供する一方でセキュリティを確保する。

符号２０１はロードバランサであって、ファイアウォール２００と任意のサーバ１０１（Ｘ）とＬＡＮなどのネットワークで接続されている。ファイアウォール２００とロードバランサ２０１とを含むネットワークと、ロードバランサ２０１とサーバ１０１（１）、１０１（２）、…、１０１（Ｍ）とを含むネットワークとは論理的に別なネットワークとして構成される。

クライアント端末１０２（Ｙ）がサービスに対するリクエストを送信しレスポンスを受信するまでのステップは次のようなものである。
Step1) クライアント端末１０２（Ｙ）は、サービスを提供するシステム１００に対してネットワーク１０３を介してリクエストを送信する。
Step2) クライアント端末１０２（Ｙ）からリクエストを受信したファイアウォール２００は、リクエスト通過の可否を判断し、通過可の場合はロードバランサ２０１へリクエストを転送する。
Step3) ファイアウォール２００からリクエストを受信したロードバランサ２０１は、負荷分散アルゴリズムにしたがって処理を依頼するサーバ１０１（Ｘ）を特定し、サーバ１０１（Ｘ）へリクエストを転送する。
Step4) ロードバランサ２０１からリクエストを受信したサーバ１０１（Ｘ）は、リクエストに対する処理を実行し実行結果をレスポンスとして、ロードバランサ２０１へ返信する。
Step5) ロードバランサ２０１は、サーバ１０１（Ｘ）から受信したレスポンスをファイアウォール２００へ転送する。
Step6) ファイアウォール２００は、ネットワーク１０３を介してロードバランサ２０１から転送されたレスポンスをクラアント端末１０２（Ｙ）へ転送する。

図３は、サーバ１０１（Ｘ）の具体的な構成例を示す図である。なお、クライアント端末１０２（Ｙ）の具体的な装置構成も図３と同様の構成で実現可能であるので、ここでは説明を省略する。

同図において、符号３０１は、サーバ１０１（Ｘ）といった情報処理装置の演算・制御を司る中央演算装置（以下、ＣＰＵと記述する）である。

符号３０２は、ランダムアクセスメモリ（以下、ＲＡＭと記述する）であり、ＣＰＵ３０１の主メモリとして、実行プログラムの実行エリアならびにデータエリアとして機能する。

符号３０３は、後述する図８、１１等に示す、ＣＰＵ３０１の動作処理手順等（制御プログラム）を記憶しているリードオンリーメモリ（以下、ＲＯＭと記述する）である。ＲＯＭ３０３には情報処理装置の機器制御を行うシステムプログラムである基本ソフト（オペレーション・システム（ＯＳ））を記録したプログラムＲＯＭと、システムを稼動するために必要な情報等が記録されているデータＲＯＭがある。機器によっては、ＲＯＭ３０３の代わりに後述のＨＤＤ３０９を使用する場合もある。

符号３０４は、ネットワークインターフェース（以下、ＮＥＴＩＦと記述する）であり、ネットワークを介して情報処理装置間でデータ転送を行うための制御や接続状況の診断を行う。
符号３０５は、ビデオＲＡＭ（以下、ＶＲＡＭを記述する）であり、後述する情報処理装置の稼動状態を示すＣＲＴ３０６の画面に表示させるための画像を展開し、その表示の制御を行う。
符号３０６は、ディスプレイ等の表示装置（以下、ＣＲＴと記述する）である。

符号３０７は、外部入力装置３０８からの入力信号を制御するためのコントローラ（以下、ＫＢＣと記述する）である。
符号３０８は、ユーザが行う操作を受け付けるための外部入力装置（以下、ＫＢと記述する）であり、例えばキーボードやマウス等のポインティングデバイスが用いられる。

符号３０９は、ハードディスクドライブ（以下、ＨＤＤと記述する）であり、アプリケーションプログラムや各種データ保存用に用いられる。本実施形態におけるアプリケーションプログラムとは、本実施形態における各種処理手段を実行するソフトウェアプログラム等である。

符号３１０は、外部入出力装置（以下、ＦＤＤと記述する）であり、上述したアプリケーションプログラムの媒体からの読み出し等に用いられる。例えばフロッピー（登録商標）ディスクドライブ、ＣＤ−ＲＯＭドライブ等のリムーバブルディスクを入出力するものである。
符号３１３は、ＦＤＤ３１０によって読み出しされる磁気記録媒体、光記録媒体、光磁気記録媒体、半導体記録媒体等の取り外し可能なデータ記録装置（リムーバブル・メディア）である（以下、ＦＤと記述する）。磁気記録媒体としては、例えばフロッピー（登録商標）ディスク（登録商標）や外付けハードディスクが挙げられる。光記録媒体としては、例えばＣＤ−ＲＯＭが挙げられ、光磁気記録媒体としては、例えばＭＯが挙げられ、半導体記録媒体としては、例えばメモリカード等が挙げられる。尚、ＨＤＤ３０９に格納するアプリケーションプログラムやデータをＦＤ３１３に格納して使用することも可能である。

符号３１１は、後述するＰＲＴ３１２への出力信号を制御するためのコントローラ（以下、ＰＲＴＣと記述する）である。
符号３１２は、印刷装置（以下、ＰＲＴと記述する）であり、例えばレーザープリンタ等が用いられる。
符号３００は、上述した各ユニット間を接続するための伝送バス（アドレスバス、データバス、入出力バス、および制御バス）である。

図４は本実施形態におけるサーバ１０１（Ｘ）の機能群および情報を格納するための格納手段を説明するための図（機能ブロック図）である。

符号４００は、リクエスト受信手段であって、クライアント端末１０２（Ｙ）から送信されるリクエストを受信し、該受信したリクエストを後述のリクエスト監視手段４１０に渡す。
符号４０１は、サービス提供手段であって、リクエスト受信手段４００で受信したリクエストに対する処理を実行し、処理結果をレスポンスとしてクライアント端末１０２（Ｙ）へ返信する。つまり、サービス提供手段４０１はエンドユーザにサービスを提供するための処理を実行するための手段である。

符号４１０は、リクエスト監視手段であって、リクエスト受信手段４００が受信したリクエストの受信時刻情報やクライアント端末１０２（Ｙ）との接続情報（リクエストＩＤやセッションＩＤ）を後述のリクエスト記録データベース４１１に格納する。更にリクエスト監視手段は、リクエスト処理判定手段４１２に上記リクエストを渡す。

符号４１１は、リクエスト記録データベースであって、リクエスト監視手段４１０によって受信したリクエストの受信時刻情報と接続情報（リクエストＩＤやセッションＩＤ）とを関連付けて格納するものである。以下、リクエスト記録データベース４１１をリクエスト記録ＤＢ４１１と記述する。

符号４１２は、リクエスト処理判定手段であって、受信したリクエストに対して要求されたサービスを実行するか否か判定（上記リクエストを拒否するか否かの判定）を行う。サービスを実行すると判定した場合、リクエスト処理判定手段４１２はリクエストをサービス提供手段４０１に渡す。サービスを実行しないと判定した場合、リクエスト処理判定手段４１２はリクエストを後述のエラーレスポンス送信手段４１５に渡す。これと共に、リクエスト処理判定手段４１２は、レスポンスの返信予定時刻であるレスポンス予定時刻をエラーレスポンス送信待ちデータベース４１４に渡す。

符号４１３は、リクエスト監視設定値管理データベースであって、受信したリクエストに対して要求されたサービスを実行しレスポンスを返すか否かを判定する際の判定基準値を管理する。以下、リクエスト監視設定値管理データベース４１３をリクエスト監視設定値管理ＤＢ４１３と記述する。

このように、リクエスト記録４１１には、リクエストの受信時刻情報といったリクエスト監視手段が受信したリクエストに関する情報が格納されている。また、リクエスト監視設定値管理ＤＢ４１３には、上記判定基準値といった、受信したリクエストを拒否する判定を行う基準値が格納されている。よって、上記リクエスト処理判定手段４１２は、リクエスト記録ＤＢ４１１とリクエスト監視設定値管理ＤＢ４１３とを参照して、リクエスト監視手段４１０から受信したリクエストを拒否するか否かを判定することができる。

符号４１４は、エラーレスポンス送信待ちデータベースであって、リクエスト処理判定手段４１２でサービスを実行しないと判断されたリクエストに対するエラーレスポンスの返信時刻（レスポンス予定時刻）を管理する。すなわち、エラーレスポンス送信待ちデータベース４１４は、上記エラーレスポンスの返信時刻、実行を拒否されたリクエストに関する、リクエストＩＤおよびセッションＩＤといった、エラーレスポンスに関する情報を管理する。以下、エラーレスポンス返信待ちデータベース４１４はエラーレスポンス返信待ちＤＢ４１４と記述する。

符号４１５は、エラーレスポンス返信手段であって、エラーレスポンス返信待ちＤＢ４１４を参照し、指定された時刻（エラー判定し、一定時間経過した後）にクライアント端末１０２（Ｙ）に対してエラーレスポンスを返信する。

符号４１６は、リクエスト管理設定値管理手段であって、管理者用のクライアント端末１０２（Ｙ）からのリクエストに応じてリクエスト監視設定値管理ＤＢ４１３に対して設定値の所定の処理を行う。この所定の処理は、設定値の、設定、更新、削除の少なくとも１つとすることができ、上記管理者用のクライアント端末１０２（Ｙ）からのリクエストに基づいて設定されるものである。

図５はサーバ１０１（Ｘ）におけるリクエスト記録ＤＢ４１１の具体的なデータ構造例を示す図である。
符号５００は、リクエストＩＤであって、クライアント端末１０２（Ｙ）から受信したリクエストを識別するための識別子である。
符号５０１は、セッションＩＤであって、複数のリクエストとレスポンスの組を一連のシーケンスとして識別するための識別子である。
符号５０２は、受信時刻であって、サーバ１０１（Ｘ）がリクエストを受信した時刻を示すものである。

図６はサーバ１０１（Ｘ）におけるリクエスト監視設定値管理ＤＢ４１３の具体的なデータ構造例を示す図である。
符号６００は、設定項目であって、リクエスト処理判定手段４１２によって参照される。本実施形態では、リクエスト処理判定手段４１２における判定基準としてリクエスト間隔閾値を採用するが、ある期間内に送信されたリクエスト数などを判定基準としてもよい。設定項目６００には判定基準となるリクエスト間隔閾値や、期間内に送信されたリクエスト数を判断するためのリクエストカウント期間、期間内リクエスト数上限などが設定される。また、設定項目６００には、サービスを提供しない場合のエラーレスポンス返信時刻を決定するためのレスポンス送信待ち時間も設定される。
符号６０１は、設定項目に対する設定値である。 図７はサーバ１０１（Ｘ）におけるエラーレスポンス送信待ちＤＢ４１４の具体的なデータ構造例を示す図である。
符号７００は、リクエストＩＤであって、リクエスト記録ＤＢ４１１におけるリクエストＩＤ５００と対応付けられるものである。
符号７０１は、セッションＩＤであって、リクエスト記録ＤＢ４１１におけるセッションＩＤ５０１と対応付けられるものである。
符号７０２は、レスポンス予定時刻であって、クライアント端末１０２（Ｙ）にリクエストＩＤ７００に対応するレスポンスをエラーレスポンスとして返信する予定時刻である。

図８は、本実施形態における、サーバ１０１（Ｘ）が実行する処理例のフローチャートを示す図である。図８を用いて、サーバ１０１（Ｘ）における全体的な処理の流れを説明する。サーバ１０１（Ｘ）における全体的な処理は次のステップＳ８００からＳ８０８で実行される。なお、本実施形態ではリクエスト間隔閾値を１０秒、エラーレスポンス待ち時間を１２秒と設定されているものと仮定する。

Ｓ８００） 処理開始
Ｓ８０１） リクエスト受信
リクエスト受信手段４００は、クライアント端末１０２（Ｙ）からリクエストを受信する。そして、リクエスト監視手段４１０は、受信したリクエストに対してリクエストＩＤを発行する。受信したリクエスト内にセッションＩＤが情報として存在しなければセッションＩＤも発行する。発行したセッションＩＤはＨＴＴＰ通信におけるＣｏｏｋｉｅなどの技術を利用して、クライアント端末１０２（Ｙ）が次回送信するリクエストにセットされるようにする。

次にリクエスト監視手段４１０は、リクエストＩＤ、セッションＩＤ、リクエストを受信した受信時刻（現在時刻）をリクエスト記録ＤＢ４１１のリクエストＩＤ５００、セッションＩＤ５０１、受信時刻５０２にそれぞれ格納する。そして、リクエスト監視手段４１０は当該リクエストをリクエスト処理判定手段４１２に渡す。

Ｓ８０２） 前回受信したリクエスト取得
リクエスト処理判定手段４１２は、リクエスト記録ＤＢ４１１から、受信したリクエストと同一セッションＩＤを持つリクエストの中で最新の２つのリクエスト（今回受信したリクエストと前回受信したリクエスト）の受信した時刻を取得する。すなわち、同一セッションにおける、前回リクエスト受信時刻と今回リクエスト受信時刻とを取得する。

Ｓ８０３） リクエスト処理判定
更に、リクエスト処理判定手段４１２は、リクエスト監視設定値管理ＤＢ４１３から、受信したリクエストに対して要求されたサービスを実行するか否か判定を行うための判定基準であるリクエスト間隔閾値（１０秒）を取得する。
Ｓ８０２で取得した今回受信リクエストと前回受信リクエストの受信時刻の差分が上記リクエスト間隔閾値（１０秒）を超えているかどうか確認する。
受信リクエストと前回受信リクエストの受信時刻の差分が前記リクエスト間隔閾値（１０秒）を超えている場合、Ｓ８０４へ進む。
受信リクエストと前回受信リクエストの受信時刻の差分が前記リクエスト間隔閾値（１０秒）を超えていない場合、Ｓ８０５へ進む。
すなわち、上記受信時刻の差分が予め設定された閾値であるリクエスト間隔閾値（１０秒）を超えるか否かを基準として、Ｓ８０１にて受信したリクエストを拒否するか否かを判定する。
尚、本実施形態では判定基準としてリクエスト間隔閾値を採用するが、前述のように期間内に送信されたリクエスト数などを判定基準としてもよい。すなわち、同一セッションにおける一定期間内に受信したリクエスト数が予め設定された閾値である期間内リクエスト数上限を超えるか否かを基準として、Ｓ８０１にて受信したリクエストを拒否するか否かを判定するようにしても良い。すなわち期間内リクエスト数の上限を超える場合はステップＳ８０５へ進む。

Ｓ８０４） サービス提供
サービス提供手段４０１は、Ｓ８０１にて受信したリクエストによって要求されたサービスに対する処理を実行し、処理結果をクライアント端末１０２（Ｙ）にレスポンスとして返信する。

Ｓ８０５） エラーレスポンス待ち時間判定
リクエスト処理判定手段４１２は、エラーレスポンス待ち時間の設定が０より大きく設定されているか否かを判定する。例えば、リクエスト監視設定値管理ＤＢ４１３から、エラーレスポンスを送信するまでの時刻を決定するためのエラーレスポンス待ち時間（１２秒）を取得する。
上記エラーレスポンス待ち時間が０秒であった場合、Ｓ８０７へ進む。前記エラーレスポンス待ち時間が０秒より大きい場合、次のような処理を行う。現在時刻に上記エラーレスポンス待ち時間を加算した時刻をレスポンス予定時刻７０２として、リクエストＩＤ７００、セッションＩＤとともにエラーレスポンス送信待ちＤＢ４１４へ格納し、Ｓ８０６へ進む。

本実施形態ではエラーレスポンス待ち時間が１２秒であるため、レスポンス予定時刻７０２を現在時刻に１２秒加算した時刻とする。

Ｓ８０６） レスポンス送信待ち
エラーレスポンス送信手段４１５は、エラーレスポンス送信待ちＤＢ４１４を参照し、Ｓ８０１にて受信したリクエストとリクエストＩＤ７００、セッションＩＤ７０１が同一のレスポンス予定時刻７０２を取得する。
上記取得したレスポンス予定時刻７０２まで待機する。待機後、Ｓ８０７へ進む。

Ｓ８０７） エラーレスポンス送信
エラーレスポンス送信手段４１５は、レスポンス予定時刻に達したエラーレスポンスをクライアント端末１０２（Ｙ）へ送信する。

Ｓ８０８） 処理終了
図９は本実施形態におけるサーバ１０１（Ｘ）とクライアント端末１０２（Ｙ）間での処理シーケンス例を示す図である。図９を用いて、サーバ１０１（Ｘ）が図８で説明した処理を行った際のサーバ１０１（Ｘ）とクライアント端末１０２（Ｙ）とのリクエストとレスポンスのシーケンスを説明する。

最初に、クライアント端末１０２（Ｙ）からサービスに対するリクエストＲ９００がサーバ１０１（Ｘ）に送信される。リクエストＲ９００はクライアント端末１０２（Ｙ）から送信された最初のリクエストと仮定する。リクエストＲ９００を受信したサーバ１０１（Ｘ）はセッションＩＤを発行し、セッションを開始する。サーバ１０１（Ｘ）はリクエストＲ９００に対する処理を実行し、上記セッションＩＤをレスポンスＲ９０１に埋め込んでレスポンスＲ９０１を返信する。

次に、クライアント端末１０２（Ｙ）はリクエストＲ９００の次のリクエストＲ９０２をサーバ１０１（Ｘ）に送信する。クライアント端末１０２（Ｙ）はリクエストＲ９０２送信時、レスポンスＲ９０１に埋め込まれている上記セッションＩＤをそのままリクエストＲ９０２に埋め込んで送信する。なお、クライアント端末１０２（Ｙ）がリクエストＲ９０２をサーバ１０１（Ｘ）に送信するタイミングは、ユーザ操作もしくはクライアントアプリケーションに依存する。

リクエストＲ９０２を受信したサーバ１０１（Ｘ）はリクエストＲ９００を受信してからリクエストＲ９０２を受信するまでの時間を算出する。算出結果がリクエスト監視設定値管理ＤＢ４１３から取得されるリクエスト間隔閾値を超えていれば、サーバ１０１（Ｘ）はリクエストＲ９０２に対する処理を実行し、レスポンスＲ９０３を返信する。

ここで、上記リクエスト間隔閾値を超えない程度の時間間隔でクライアント端末１０２（Ｙ）がサービスに対するリクエストＲ９０４を送信したと仮定する。このとき、リクエストＲ９０４を受信したサーバ１０１（Ｘ）はリクエストＲ９０２を受信してからリクエストＲ９０４を受信するまでの時間を算出する。算出結果がリクエスト監視設定値管理ＤＢ４１３から取得されるリクエスト間隔閾値を超えないため、サーバ１０１（Ｘ）はリクエストＲ９０４に対する処理結果として、エラーレスポンスＲ９０５を返信する。エラーレスポンスＲ９０５を返信する際、サーバ１０１（Ｘ）はすぐに返信せず、リクエスト監視設定値管理ＤＢ４１３から取得されるエラーレスポンス送信待ち時間経過後にエラーレスポンスを送信する。

通常、インターネットなどネットワーク経由でサービスを提供するシステムではサーバ１０１（Ｘ）とクライアント端末１０２（Ｙ）間での通信はＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を利用する場合が多い。このような場合、クライアント端末１０２（Ｙ）はリクエスト送信後、サーバ１０１（Ｘ）からのレスポンスが返信されてくるまで処理待ちの状態になることが多い。したがって、上記エラーレスポンス送信待ち時間によってエラーレスポンスの送信タイミングを変えることによって、クライアント端末１０２（Ｙ）のリトライ処理を実行するタイミングをある程度制御することが可能となる。その結果、クライアント端末１０２（Ｙ）からの連続的なリクエストの送信も減少させることができる。

すなわち、クライアント端末１０２（Ｙ）からサーバ１０１（Ｘ）へのリクエストＲ９０１とＲ９０２との間の時間がリクエスト間隔閾値以上であれば、サーバ１０１（Ｘ）への過負担はほとんど無い。よって、この場合は、サーバ１０（Ｘ）１は、クライアント１０２（Ｙ）からのリクエストを処理した後、その処理結果のレスポンスＲ９０１を送信することができる。一方、リクエストＲ９０２とＲ９０４との間のように、上記時間がリクエスト間隔閾値未満となると、ある処理が終了する前に次の処理のリクエストが来たり、特定のクライアントからのリクエストばかりを処理してしまったりする状況になる可能性がある。よって、サーバ１０１（Ｘ）のパフォーマンスが低下する恐れがあり、サーバ１０１（Ｘ）が過負担状態に陥る可能性がある。特定のクライアントからのリクエストばかりが処理されてしまい、他のクライアントからのリクエストがなかなか処理されなくなってしまう可能性もある。

これに対して本実施形態では、上記サーバ１０１（Ｘ）が過負担状態となる可能性がある、上記時間がリクエスト間隔閾値未満の場合（エラーと判定した場合）に、エラーレスポンスＲ９０５の送信を一定時間経過した後に行うようにしている。更に、エラーレスポンスをすぐに送信すると、クライアントからすぐにリクエストが再送されてきてしまう可能性があるため、一定時間経過後にエラーレスポンスを送るようにしている。従って、この一定時間の間にはサーバ１０１（Ｘ）からクライアント端末１０２（Ｙ）へのレスポンスの送信は存在しないので、クライアント端末１０２（Ｙ）からサーバ１０１（Ｘ）へのリクエストの送信を一旦停止することができる。よって、サーバ１０１（Ｘ）が過負担状態に陥るようなリクエストの連続送信を抑制することができる。

図１０は本実施形態におけるサーバ１０１（Ｘ）で実行する処理の中で各機能が行う処理例を説明するための図である。
前提として、システム管理者がリクエスト監視設定値管理ＤＢ４１３に設定項目を設定しているものとする。ここで設定項目とは上記リクエスト間隔閾値および上記エラーレスポンス送信待ち時間である。上記リクエスト間隔閾値の代わりに「ある期間中のリクエスト数をカウントするためのリクエストカウント期間、期間内リクエスト数上限」であってもかまわない。
システム管理者によるリクエスト監視設定値管理ＤＢ４１３に設定項目を設定するまでの処理は次のようなものである。

Step1) 管理者用クライアント端末を操作することによってリクエスト監視設定値管理手段４１６に設定のためのリクエストを送信する（Ｓ１０００）。
ここで、管理者用クライアント端末はサーバ１０１（Ｘ）と同じシステム内のネットワークに接続されていてもよいし、クライアント端末１０２（Ｙ）のようにシステム外のネットワークに接続されていてもよい。

Step2) 上記設定のためのリクエストを受信したリクエスト監視設定値管理手段４１６は、リクエスト監視設定値管理ＤＢ４１３に上記設定のためのリクエストに含まれる設定項目に対する値を設定する（Ｓ１００１）。

次に、クライアント端末１０２（Ｙ）がリクエストを送信してからレスポンスを受信するまでのサーバ１０１（Ｘ）において各機能が行う処理を説明する。

最初にクライアント端末１０２（Ｙ）は、サーバ１０１（Ｘ）にリクエストを送信する。サーバ（Ｘ）ではリクエスト受信手段４００がリクエストを受信し、該受信したリクエストをリクエスト監視手段４１０に渡す（Ｓ１００２）。

リクエスト監視手段４１０は、上記受信したリクエストに対するリクエストＩＤを発行し、該リクエストに含まれるセッションＩＤを取得する。セッションＩＤがリクエストに含まれない場合、リクエスト監視手段４１０はセッションＩＤを発行する。次にリクエスト監視手段４１０は、発行したリクエストＩＤと、取得もしくは発行したセッションＩＤと、リクエストを受信した時刻（受信時刻）とをリクエスト記録ＤＢ４１１に格納する（Ｓ１００３）。

すなわち、リクエスト監視手段４１０は、リクエスト受信手段４００にて受信されたリクエストに基づいて、受信したリクエストに関する情報であって、該受信したリクエストを拒否するか否かの判定に用いる情報である受信時刻を取得している。本実施形態では、該受信時刻を、各リクエストと関連付けてリクエスト記録ＤＢ４１１に記憶し管理できるようにしているので、リクエスト監視手段４１０とリクエスト処理判定手段４１２は、リクエストの受信間隔を監視していることになる。

そして、リクエスト監視手段４１０は、上記受信したリクエストをリクエスト処理判定手段４１２に渡す（Ｓ１００４）。

リクエスト処理判定手段４１２は、リクエスト記録ＤＢ４１１からリクエストと同じセッションＩＤをもつリクエストで、かつ、最新のリクエスト２つを取得する（Ｓ１００５）。つまり、同じセッションＩＤを持つ前回受信したリクエストと、今回処理をしようとしているリクエストを取得する。

次に、リクエスト処理判定手段４１２は、リクエスト監視設定値管理ＤＢ４１３からリクエスト間隔閾値（１０秒）とエラーレスポンス送信待ち時間（１２秒）を取得する（Ｓ１００６）。次に、リクエスト処理判定手段４１２は、上記取得した２リクエストの受信時刻の差分を算出する。次に、リクエスト処理判定手段４１２は、上記２リクエストの受信時刻の差分と上記リクエスト間隔閾値（１０秒）を比較し、リクエストに対する処理を実行するか否か（受信したリクエストを拒否するか否か）を判定する。

上記２リクエストの受信時刻の差分が前記リクエスト間隔閾値（１０秒）を超えていれば、リクエスト処理判定手段４１２はサービス提供手段４０１にリクエストを渡す（Ｓ１００７）。すなわち、この場合は、同一セッションにおいて、前回のリクエストと今回のリクエストとを受信した時間が、サーバ１０１（Ｘ）を過負担状態にするほどではないと判断し、受信したリクエストに基づいた処理を行うのである。

上記２リクエストの受信時刻の差分がリクエスト間隔閾値を超えていなければ、リクエスト処理判定手段４１２は、上記エラーレスポンス送信待ち時間（１２秒）を現在時刻に加算することでエラーレスポンス送信予定時刻（レスポンス予定時刻）を算出する。すなわち、上記差分がリクエスト間隔閾値未満である場合は、同一セッションにおいて、サーバ１０１（Ｘ）が過負担状態に陥る可能性がある状態の時に次のリクエストを受信したことを意味している。よって、エラーレスポンス送信待ち時間だけ送信を遅らせるようにエラーレスポンス送信予定時刻を設定することにより、クライアント端末（Ｙ）からの次のリクエストの送信を遅らせることができ、サーバ１０１（Ｘ）への負担を減少することができる。

なお、ここでエラーレスポンス送信予定時刻を算出する際に、サーバ１０１（Ｘ）の処理状況を参照し、処理状況に応じてエラーレスポンス送信予定時刻を算出してもよい。例えば、サーバ１０１（Ｘ）のＣＰＵ使用率（単位：％）を参照し、次式のようにＣＰＵ使用率（単位：％）に応じてエラーレスポンス予定時刻を動的に算出してもよい。

上記式によれば、ＣＰＵ使用率８０％のとき、１２秒×１．８＝２１．６秒を現在時刻に加算した時刻がエラーレスポンス送信予定時刻となる。このようにエラーレスポンス送信予定時刻は固定値によって算出するのではなく、状況に応じて算出してもよい。

リクエスト処理判定手段４１２は、エラーレスポンス送信待ちＤＢ４１４にリクエストＩＤ７００、セッションＩＤ７０１、レスポンス予定時刻７０２を格納し（Ｓ１００９）、エラーレスポンス送信待ち手段４１５にリクエストを渡す（Ｓ１０１０）。

ここでリクエスト監視設定値管理ＤＢ４１３に前記リクエスト間隔閾値の変わりに上記リクエストカウント期間、上記期間内リクエスト数上限が設定された場合、リクエスト処理判定手段４１２は次のように処理判定する。

上記リクエストカウント期間に送信されたリクエストをリクエスト記録ＤＢ４１１から取得し、そのリクエスト数を算出する。該算出したリクエスト数が上記期間内リクエスト数上限に達していなければ、サービス提供手段４０１にリクエストを渡す。一方、上記算出したリクエスト数が上記期間内リクエスト数上限を超えていれば、エラーレスポンス送信手段４１５にリクエストを渡す。

サービス提供手段４０１は、リクエストに含まれる要求に応じた処理を実行し、処理結果をクライアント端末１０２（Ｙ）に返信する（Ｓ１００８）。

エラーレスポンス送信手段４１５は、エラーレスポンス送信待ちＤＢ４１４を参照し、リクエストに対するリクエストＩＤ７００、セッションＩＤ７０１からレスポンス予定時刻７０２を取得する。エラーレスポンス送信手段４１５は、上記レスポンス予定時刻７０２になるまで待ち、レスポンス予定時刻７０２になったらエラーレスポンスをクライアント端末１０２（Ｙ）に返信する（Ｓ１０１３）。

以上説明したように、本実施形態によって、サーバ１０１（Ｘ）においてセッション毎のリクエストの受信間隔を監視し、実際の処理を実行するか否か判断することができる。このことによって、連続的に送信されるリクエストに対する処理数を少なくすることができ、サーバ１０１（Ｘ）の処理負荷を軽減することができる。加えて、本実施形態によって、処理実行しないと判断したリクエストに対するレスポンスを返信するタイミングを制御することができる。このことによって、クライアントがレスポンスを待っている間、クライアントから連続的にリクエストを送信するといったことを減少させることができる。

本実施形態では、サーバ１０１（Ｘ）においてリクエストの受信間隔を監視する単位をセッション単位としていたが、ユーザ認証後のリクエストを利用してリクエストを送信したユーザ単位でリクエストの受信間隔を監視してもよい。その場合、セッションＩＤとして管理していた項目がユーザＩＤで管理されることになる。すなわち、同一ユーザＩＤに対して、上述した本実施形態に係る処理を行う。

（第２の実施形態）
第１の実施形態では、サーバ１０１（Ｘ）が前回受信したリクエストの受信時刻と今回受信したリクエストの受信時刻の差分が閾値を越えないリクエスト全てに対してエラーレスポンスを返信する形態について説明した。

通常、クライアント端末１０２（Ｙ）は前回リクエストに対するサーバ１０１（Ｘ）からのレスポンスが返信されない限り、次のリクエストをサーバ１０１（Ｘ）へ送信しない。しかしながら、必ずしもクライアント端末１０２（Ｙ）がレスポンスを受信してから次のリクエストを送信するとは限らない。

例えば、Ｗｅｂサービスなどを利用する場合、任意の開発者がクライアントアプリケーションを開発可能である。クライアント端末１０２（Ｙ）がレスポンスを受信してから次のリクエストを送信するという動作はクライアントアプリケーションの作りに依存する部分もある。そのため、クライアントアプリケーションの作りによってはエラーレスポンス送信待ちの間にクライアント端末１０２（Ｙ）からリクエストが送信するといった場合も考えられる。

サーバ１０１（Ｘ）における処理負荷を軽減するといった観点からも、エラーレスポンス送信待ち中に同一クライアントからリクエストを受信した場合、そのリクエストを破棄することが有効であると考えられる。

図１１は本実施形態におけるサーバ１０１（Ｘ）が実行する処理例のフローチャートを示す図である。図１１を用いて、サーバ１０１（Ｘ）における全体的な処理の流れを説明する。サーバ１０１（Ｘ）における全体的な処理は次のステップＳ１１００からＳ１１１０で実行される。なお、本実施形態ではリクエスト間隔閾値を１０秒、エラーレスポンス待ち時間を１２秒と設定されているものと仮定する。

Ｓ１１００） 処理開始
Ｓ１１０１） リクエスト受信
クライアント端末１０２（Ｙ）からリクエストを受信する。受信したリクエストに対してリクエストＩＤを発行する。リクエスト内にセッションＩＤが情報として存在しなければセッションＩＤも発行する。
次にリクエストＩＤ、セッションＩＤ、リクエストを受信した受信時刻（現在時刻）をリクエスト記録ＤＢ４１１のリクエストＩＤ７００、セッションＩＤ７０１、受信時刻７０２にそれぞれ格納する。

Ｓ１１０２） 送信待ちエラーレスポンス存在判定
エラーレスポンス送信待ちＤＢ４１４を参照し、セッションＩＤ７０１が、ステップＳ１１０１にて受信した現在のリクエストと同じセッションＩＤを持つレコードが存在するか否か確認する。
レコードが存在する場合、Ｓ１１０３へ進む。レコードが存在しない場合、Ｓ１１０４へ進む。
ここでは、後述する、受信したリクエストを拒否するか否かを判定する前に、今回受信したリクエストと同一のクライアント端末１０２（Ｙ）から送信されたリクエストについてすでにエラーレスポンス送信待ちのものがあるか否かを判定する。すなわち、エラーレスポンス送信待ちＤＢ４１４を参照して、上記受信したリクエストを送信したクライアント端末１０２（Ｙ）から以前に送信されたリクエストの中でエラーレスポンス送信待ちのリクエストの有無を確認する。該確認によって、該当するリクエストがある場合は、今回受信したリクエストを破棄する処理（Ｓ１１０３）に進むのである。

Ｓ１１０３） リクエスト破棄
Ｓ１１０１にて今回受信したリクエストを破棄する。

Ｓ１１０４） 前回受信したリクエスト取得
リクエスト記録ＤＢ４１１から受信したリクエストと同一セッションＩＤを持つリクエストの中で最新の２つのリクエスト（受信リクエストと前回受信リクエスト）の受信した時刻を取得する。

Ｓ１１０５） リクエスト処理判定
リクエスト監視設定値管理ＤＢ４１３から、受信したリクエストに対して要求されたサービスを実行するか否か判定を行うための判定基準であるリクエスト間隔閾値（１０秒）を取得する。
Ｓ１１０４で取得した受信リクエストと前回受信リクエストの受信時刻の差分が上記リクエスト間隔閾値（１０秒）を超えているかどうか確認する。
受信リクエストと前回受信リクエストの受信時刻の差分が上記リクエスト間隔閾値（１０秒）を超えている場合、Ｓ１１０６へ進む。
受信リクエストと前回受信リクエストの受信時刻の差分が上記リクエスト間隔閾値（１０秒）を超えていない場合、Ｓ１１０７へ進む。
尚、本実施形態では判定基準としてリクエスト間隔閾値を採用するが、前述のように期間内に送信されたリクエスト数などを判定基準としてもよい。

Ｓ１１０６） サービス提供
受信したリクエストによって要求されたサービスに対する処理を実行し、処理結果をクライアント端末１０２（Ｙ）にレスポンスとして返信する。

Ｓ１１０７） レスポンス待ち時間判定
リクエスト監視設定値管理ＤＢ４１３から、エラーレスポンスを送信するまでの時刻を決定するためのエラーレスポンス待ち時間（１２秒）を取得する。
上記エラーレスポンス待ち時間が０秒であった場合、Ｓ１１０９へ進む。上記エラーレスポンス待ち時間が０秒より大きい場合、次のような処理を行う。現在時刻に上記エラーレスポンス待ち時間（１２秒）を加算した時刻をレスポンス予定時刻７０２として、リクエストＩＤ７００、セッションＩＤ７０１とともにエラーレスポンス送信待ちＤＢ４１４へ格納し、Ｓ１１０８へ進む。

Ｓ１１０８） レスポンス送信待ち
エラーレスポンス送信待ちＤＢ４１４を参照し、受信したリクエストとリクエストＩＤ７００、セッションＩＤ７０１が同一のレスポンス予定時刻７０２を取得する。
次に、上記取得したレスポンス予定時刻７０２まで待機する。待機後、Ｓ１１０９へ進む。

Ｓ１１０９） エラーレスポンス送信
エラーレスポンスをクライアント端末１０２（Ｙ）へ送信する。

Ｓ１１１９） 処理終了
図１２は本実施形態におけるサーバ１０１（Ｘ）とクライアント端末１０２（Ｙ）間での処理シーケンス例を示す図である。図１２を用いて、サーバ１０１（Ｘ）が図１１で説明した処理を行った際のサーバ１０１（Ｘ）とクライアント端末１０２（Ｙ）とのリクエストとレスポンスのシーケンスを説明する。

図１２におけるリクエストＲ９００、Ｒ９０２、Ｒ９０４とレスポンスＲ９０１、Ｒ９０３、Ｒ９０５は図９で説明した第１の実施形態のリクエスト、レスポンスと同様のものである。

ここで、リクエストＲ９０４に対するエラーレスポンスＲ９０５を送信待ちの状態のときに、クライアント端末１０２（Ｙ）からリクエストＲ１２００がサーバ１０１（Ｘ）に送信された場合を考える。
リクエストＲ１２００を受信したサーバ１０１（Ｘ）はリクエストＲ１２００を破棄する。

本実施形態におけるサーバ１０１（Ｘ）で実行する処理の中で各機能が行う処理は基本的には第１の実施形態と同じである。第１の実施形態との違いはリクエスト処理判定手段４１２における処理とエラーレスポンス送信手段４１５における処理が異なる点にある。

第１の実施形態では、リクエスト処理判定手段４１２は、前回受信したリクエストと今回受信したリクエストの受信時刻の比較処理を行っていたが、本実施形態におけるリクエスト処理判定手段４１２はその前に次のような処理を行う。

リクエスト処理判定手段４１２は、エラーレスポンス送信待ちＤＢ４１４を参照し、セッションＩＤ７０１がリクエストと同じセッションＩＤを持つレコードが存在するか否か確認する。レコードが存在する場合はリクエストを破棄し、処理しないようにする。レコードが存在する場合は第１の実施形態と同様に前回受信したリクエストと今回受信したリクエストの受信時刻の比較処理を行い、処理を進めていく。

また、第１の実施形態では、エラーレスポンス送信手段４１５はエラーレスポンス送信後、エラーレスポンス送信待ちＤＢ４１４に存在するレコードを明示的に削除していなかった。本実施形態におけるエラーレスポンス送信手段４１５は、エラーレスポンス送信後、エラーレスポンス送信待ちＤＢ４１４に存在するレコードでリクエストＩＤとセッションＩＤが一致するレコードを明示的に削除する。

以上説明したように、本実施形態によって、第１の実施形態においてエラーレスポンス送信待ち状態のときに同一クライアント端末１０２（Ｙ）からリクエストを受信しても、レスポンスを破棄することができる。このことによって、同一クライアント端末１０２（Ｙ）からのリクエストによってサーバ１０１（Ｘ）が占有される可能性を低くすることができる。

（その他の実施形態）
本発明は、複数の機器（例えばコンピュータ、インターフェース機器、リーダ、プリンタなど）から構成されるシステムに適用することも、１つの機器からなる装置（複合機、プリンタ、ファクシミリ装置など）に適用することも可能である。

前述した実施形態の機能を実現するように前述した実施形態の構成を動作させるプログラムを記憶媒体に記憶させ、該記憶媒体に記憶されたプログラムをコードとして読み出し、コンピュータにおいて実行する処理方法も上述の実施形態の範疇に含まれる。即ちコンピュータ読み取り可能な記憶媒体も実施例の範囲に含まれる。また、前述のコンピュータプログラムが記憶された記憶媒体はもちろんそのコンピュータプログラム自体も上述の実施形態に含まれる。

かかる記憶媒体としてはたとえばフロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ―ＲＯＭ、磁気テープ、不揮発性メモリカード、ＲＯＭを用いることができる。

また前述の記憶媒体に記憶されたプログラム単体で処理を実行しているものに限らず、他のソフトウエア、拡張ボードの機能と共同して、ＯＳ上で動作し前述の実施形態の動作を実行するものも前述した実施形態の範疇に含まれる。

本発明の一実施形態に係る、インターネットなどネットワーク経由でサービスを提供するシステムの具体的なシステム構成例を示す図である。 本発明の一実施形態に係る、インターネットなどネットワーク経由でサービスを提供するシステムのサーバの具体的なシステム構成例を示す図である。 本発明の一実施形態に係る、サーバ１０１（Ｘ）およびクライアント端末１０２（Ｙ）の具体的な構成例を示す図である。 本発明の一実施形態に係るサーバの機能ブロック図である。 本発明の一実施形態に係る、サーバ１０１（Ｘ）におけるリクエスト記録ＤＢ４１１の具体的なデータ構造例を示す図である。 本発明の一実施形態に係る、サーバ１０１（Ｘ）におけるリクエスト監視設定値管理ＤＢ４１３の具体的なデータ構造例を示す図である。 本発明の一実施形態に係る、サーバ１０１（Ｘ）におけるエラーレスポンス送信待ちＤＢ４１４の具体的なデータ構造例を示す図である。 本発明の一実施形態におけるサーバ１０１（Ｘ）が実行する処理例のフローチャートを示す図である。 本発明の一実施形態におけるサーバ１０１（Ｘ）とクライアント端末１０２（Ｙ）間での処理シーケンス例を示す図である。 本発明の一実施形態におけるサーバ１０１（Ｘ）で実行する処理の中で各機能が行う処理例を説明するための図である。 本発明の一実施形態におけるサーバ１０１（Ｘ）が実行する処理例のフローチャートを示す図である。 本発明の一実施形態におけるサーバ１０１（Ｘ）とクライアント端末１０２（Ｙ）間での処理シーケンス例を示す図である。 従来のサーバ・端末（クライアント）間におけるリクエスト集中時の負荷分散を説明するための図である。 従来のサーバ・端末（クライアント）間におけるリクエスト集中時のセッション数でのリクエストの絞り込みを説明するための図である。 従来のサーバ・端末（クライアント）間におけるリクエスト集中時のサーバ内での処理（セッション数でのリクエストの絞り込み）を説明するためのシーケンス図である。 従来のサーバ・端末（クライアント）間において、ある１つのクライアントが集中的にリクエストを送信した場合の状況を説明するための図である。 従来のサーバ・端末（クライアント）間において、ある１つのクライアントが集中的にリクエストを送信した場合のサーバ内の処理状況を説明するための図である。

符号の説明

１００ サービスを提供するシステム
１０１（１） サーバ（１）
１０１（２） サーバ（２）
１０１（Ｎ） サーバ（Ｎ）
１０２（１） クライアント端末（１）
１０２（２） クライアント端末（２）
１０２（Ｍ） クライアント端末（Ｍ）
１０３ ネットワーク
２００ ファイアウォール
２０１ ロードバランサ
４００ リクエスト受信手段
４０１ サービス提供手段
４１０ リクエスト監視手段
４１１ リクエスト記録データベース（リクエスト記録ＤＢ）
４１２ リクエスト処理判定手段
４１３ リクエスト監視設定値管理データベース（リクエスト監視設定値管理ＤＢ）
４１４ エラーレスポンス送信待ちデータベース（エラーレスポンス送信待ちＤＢ）
４１５ エラーレスポンス送信手段
４１６ リクエスト管理設定値管理手段

Claims (12)

1. リクエストを受信するリクエスト受信手段と、
   前記リクエスト受信手段にて受信されたリクエストに関する情報であって、該受信したリクエストを拒否するか否かの判定に用いる情報を、リクエスト記録データベースに格納するリクエスト監視手段と、
   受信したリクエストを拒否する判定を行う基準値を管理するリクエスト監視設定値管理データベースと、
   前記リクエスト監視設定値管理データベースと前記リクエスト記録データベースとを参照して、前記リクエスト受信手段にて受信したリクエストを拒否するか否かを判定するリクエスト処理判定手段と、
   前記リクエスト処理判定手段が前記受信したリクエストを拒否すると判定した場合に、該拒否の判定から一定時間経過した後に、前記リクエストを送信したクライアントに対してエラーレスポンスを返信するエラーレスポンス送信手段と
   を備えることを特徴とする情報処理装置。
2. 前記エラーレスポンスに関する情報を管理するエラーレスポンス送信待ちデータベースをさらに備え、
   前記エラーレスポンス送信手段は、前記エラーレスポンス送信待ちデータベースで管理されている前記エラーレスポンスに関する情報に基づいて、前記一定時間経過した後に前記エラーレスポンスを返信することを特徴とする請求項１に記載の情報処理装置。
3. 前記リクエスト処理判定手段は、前記受信したリクエストを拒否するか否かを判定する前に前記エラーレスポンス送信待ちデータベースを参照し、前記リクエストを送信したクライアントから以前に送信されたリクエストに対応するエラーレスポンスが前記エラーレスポンス送信待ちデータベースで管理されていると判断した場合は、当該受信したリクエストを破棄することを特徴とする請求項２に記載の情報処理装置。
4. 前記リクエスト処理判定手段は、同一セッションにおける前回リクエスト受信時刻と当該リクエスト受信時刻の差分が予め設定された閾値を超えるか否かを基準として、前記受信したリクエストを拒否するか否かを判定することを特徴とする請求項１乃至３のいずれかに記載の情報処理装置。
5. 前記リクエスト処理判定手段は、同一セッションにおける一定期間内に受信したリクエスト数が予め設定された閾値を超えるか否かを基準として、前記受信したリクエストを拒否するか否かを判定することを特徴とする請求項１乃至３のいずれかに記載の情報処理装置。
6. 前記リクエスト処理判定手段は、同一ユーザＩＤによって送信されたリクエストの中で前回リクエスト受信時刻と当該リクエスト受信時刻の差分が予め設定された閾値を超えるか否かを基準として、前記受信したリクエストを拒否するか否かを判定することを特徴とする請求項１乃至３のいずれかに記載の情報処理装置。
7. 前記リクエスト処理判定手段は、同一ユーザＩＤによって送信されたリクエストの中で一定期間内に受信したリクエスト数が予め設定された閾値を超えるか否かを基準として、前記受信したリクエストを拒否するか否かを判定することを特徴とする請求項１乃至３のいずれかに記載の情報処理装置。
8. 前記リクエスト監視設定値管理データベースにおいて管理される設定値に対して所定の処理を行うリクエスト監視設定値管理手段をさらに備えることを特徴とする請求項１乃至７のいずれかに記載の情報処理装置。
9. 前記リクエスト処理判定手段が前記受信したリクエストを拒否しないと判定した場合に、当該リクエストに対応する処理を実行するサービス提供手段を、更に備えることを特徴とする請求項１乃至８のいずれかに記載の情報処理装置。
10. リクエストを受信するリクエスト受信工程と、
    前記リクエスト受信手段にて受信されたリクエストに関する情報であって、該受信したリクエストを拒否するか否かの判定に用いる情報を、リクエスト記録データベースに格納するリクエスト監視工程と、
    受信したリクエストを拒否する判定を行う基準値を管理するリクエスト監視設定値管理データベースと前記リクエスト記録データベースとを参照して、前記リクエスト受信工程にて受信したリクエストを拒否するか否かを判定するリクエスト処理判定工程と、
    前記リクエスト処理判定工程にて前記受信したリクエストを拒否すると判定した場合に、該拒否の判定から一定時間経過した後に、前記リクエストを送信したクライアントに対してエラーレスポンスを返信するエラーレスポンス送信工程と
    を有することを特徴とする情報処理方法。
11. コンピュータを、
    受信したリクエストに関する情報であって、該受信したリクエストを拒否するか否かの判定に用いる情報を、リクエスト記録データベースに格納するリクエスト監視手段、
    受信したリクエストを拒否する判定を行う基準値を管理するリクエスト監視設定値管理データベースと前記リクエスト記録データベースとを参照して、前記受信したリクエストを拒否するか否かを判定するリクエスト処理判定手段、
    前記リクエスト処理判定手段が前記受信したリクエストを拒否すると判定した場合に、該拒否の判定から一定時間経過した後に、前記リクエストを送信したクライアントに対してエラーレスポンスを返信するエラーレスポンス送信手段
    として機能させるための、コンピュータプログラム。
12. 請求項１１に記載のコンピュータプログラムを格納した、コンピュータ読み取り可能な記憶媒体。

Images