JP2017059250A - 流量制御機能を有するシステム - Google Patents

Abstract

【課題】大量のリクエストが流入した場合であっても円滑なオンラインシステムの使用を確保するための技術を提供すること。【解決手段】本発明の一態様は、複数の処理待ちデータを保持するキューと、前記キューから提供される前記処理待ちデータを同時に処理する複数のスレッドとを有する流量制御システムであって、前記複数のスレッドによる処理結果データの出力先の所定の複数のプログラム毎に、又は前記処理結果データの出力宛先毎に、前記スレッドの個数と前記キューのキュー長とが規定される流量制御システムに関する。【選択図】図１

Description

本発明は、コンピュータシステムにおける流量制御に関する。

現在、インターネットなどのネットワークを介しシステム上で各種サービスが提供されている。これらのサービスは、典型的には、ユーザ装置からのリクエストに応答して、システムが要求されたサービスに対応するデータをネットワークを介し要求元のユーザ装置に返すことによって実現される。

システムが自らの処理能力を上回るリクエストを受信すると、システムは遅延を生じたり、ダウンする可能性もある。このような大量のリクエストの受信は、偶発的に発生することもあるし、ＤｏＳ（Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ）攻撃などにより悪意のある第三者により意図的に行われることもある。

このようなシステムの処理能力を上回るリクエストの受信を回避するため、システムはしばしば、リクエストの受信又は受け入れを制限する流量制御機能を備えている。この流量制御は、典型的には、受信したリクエストをキューなどのバッファ手段に格納し、キューが一杯になった場合には受信を拒絶するなどによって、リクエストの受け入れを制御することによって実現される。

特開２００６−２５９８１２ 特開２００２−１４９６１９

しかしながら、システムが各種サービスを提供可能である場合、流量制御によってこれらすべてのサービスに対するリクエストが、サービス種別に関係なく一律に拒絶され、ユーザが当該システムを十分に利用できなくなる可能性がある。

従って、本発明の課題は、上記問題点に鑑み、大量のリクエストが流入した場合であっても円滑なオンラインシステムの使用を確保するための技術を提供することである。

上記課題を解決するため、本発明の一態様は、複数の処理待ちデータを保持するキューと、前記キューから提供される前記処理待ちデータを同時に処理する複数のスレッドとを有する流量制御システムであって、前記複数のスレッドによる処理結果データの出力先の所定の複数のプログラム毎に、又は前記処理結果データの出力宛先毎に、前記スレッドの個数と前記キューのキュー長とが規定される流量制御システムに関する。

本発明によると、大量のリクエストが流入した場合であっても円滑なオンラインシステムの使用を確保するための技術を提供することができる。

図１は、本発明の一実施例による流量制御機能を備えたシステムの構成を示す。 図２は、本発明の一実施例によるサーバのハードウェア構成を示す。 図３は、本発明の一実施例による流量制御の概略図である。 図４は、本発明の一実施例による特定サービス提供部によるリクエスト受け入れ処理を示すフロー図である。 図５は、本発明の一実施例による特定サービス提供部によるリクエスト処理を示すフロー図である。

以下、図面に基づいて本発明の実施の形態を説明する。

図１を参照して、本発明の一実施例による流量制御機能を備えたシステムを説明する。図１は、本発明の一実施例による流量制御機能を備えたシステムの構成を示す。

図１に示されるように、システム１０は、流量制御機能を備えたサーバ１００と、ネットワーク１５０と、ネットワーク１５０を介しサーバ１００に通信接続される複数のユーザ装置２００とを有する。

サーバ１００は、ネットワーク１５０を介しユーザ装置２００から各種サービスに対するリクエストを受信し、これらのリクエストに応答して、要求されたサービスを要求元のユーザ装置２００に提供する。サーバ１００は、ネットワーク１５０を介し受信するリクエスト数を制御する流量制御機能を備え、サーバ１００の処理能力を超えて受信したリクエストの受け入れを制限する。

ネットワーク１５０は、インターネットや携帯電話ネットワークなどの１以上のネットワークから構成される。また、ユーザ装置２００は、例えば、パーソナルコンピュータ、携帯電話機、スマートフォンなどの有線及び／又は無線通信機能を備えた情報処理装置である。

本実施例では、サーバ１００が提供可能な各種サービスについて、サービスの種別毎に特定サービス提供部１１０が設けられる。すなわち、サーバ１００は、サービスタイプ１のサービス又はサービス群を提供する特定サービス提供部１１０＿１、サービスタイプ２のサービス又はサービス群を提供する特定サービス提供部１１０＿２、．．．及びサービスタイプｍのサービス又はサービス群を提供する特定サービス提供部１１０＿ｍを有する。例えば、サーバ１００が金融サービスを提供するアプリケーションサーバである場合、口座開設サービスを提供する特定サービス提供部、金融情報を提供する特定サービス提供部、ログイン処理を実行する特定サービス提供部、振込サービスを提供する特定サービス提供部などの各種特定サービス提供部が備えられてもよい。しかしながら、本発明はこれに限定されず、リクエストに応答して複数のタイプのサービスを提供可能な他の何れか適切なサーバに適用可能である。

サーバ１００の複数の特定サービス提供部１１０のそれぞれには、例えば、所定の処理能力を備えたハードウェアリソースが割り当てられる。各特定サービス提供部１１０は、ユーザからのリクエストに応答して、割り当てられたハードウェアリソースを用いて要求されたサービスを処理する。

各特定サービス提供部１１０は、受信したリクエストに関するデータを所定の容量の記憶手段に格納し、記憶手段に空き容量がなくなるとリクエストの受け入れを拒絶することによって、特定サービス提供部１１０毎に流量制御を実行する。

次に、図２を参照して、本発明の一実施例によるサーバ１００のハードウェア構成を説明する。図２は、本発明の一実施例によるサーバのハードウェア構成を示す。

図２に示されるように、サーバ１００は、バスＢを介し相互接続されるドライブ装置１０１、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０４、及びインタフェース装置１０５を有する。

サーバ１００における後述される各種処理を実現するプログラムは、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等の記録媒体１０６によって提供されてもよい。プログラムを記憶した記録媒体１０６がドライブ装置１０１にセットされると、プログラムが記録媒体１０６からドライブ装置１０１を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０６により行う必要はなく、ネットワーク１５０を介して他のサーバからダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムやデータを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムやプログラムを実行するのに必要なパラメータなどの各種データに従って、後述されるようなサーバ１００の各種機能を実行する。インタフェース装置１０５は、ネットワーク１５０に接続するための通信インタフェースとして用いられる。

図１に示されるように、サーバ１００は、各種サービスの種別に対応する複数の特定サービス提供部１１０＿１，１１０＿２，．．．，１１０＿ｎを有する（以降において、特定サービス提供部１１０と総称される）。各特定サービス提供部１１０は、ユーザ装置２００からのリクエストに応答して、特定のタイプのサービス又はサービス群を要求元のユーザ装置２００に提供する。例えば、各特定サービス提供部１１０にはＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）などの宛先が割り当てられ、ユーザ装置２００は、所望するサービスに対応するＵＲＬにリクエストを送信する。当該リクエストを受信すると、要求先の特定サービス提供部１１０は、当該リクエストを処理し、要求されたサービスを要求元のユーザ装置２００に提供する。

ユーザ装置２００から送信されるリクエストは、例えば、要求元のユーザ装置２００の宛先、要求先の特定サービス提供部１１０の宛先、ユーザ装置２００が要求する具体的なサービス、当該サービスを受けるのに必要な各種情報などを含むデータであってもよい。例えば、ユーザ装置２００から送信されるリクエストが口座開設に関するものである場合、当該リクエストは、要求元のユーザ装置２００の宛先、要求先の特定サービス提供部１１０の宛先、ユーザ装置２００が開設を要求する具体的な口座種別（普通預金口座、定期預金口座、外貨預金口座など）、口座開設に必要なユーザの氏名、住所、生年月日などを含むデータであってもよい。

特定サービス提供部１１０は、ウェブアプリケーションリソース（ＷＡＲ）１２０とキュー１３０とを有する。ＷＡＲ１２０は、サーバ１００のＣＰＵ１０４がメモリ装置１０３に格納されたサービス種別に応じたアプリケーションプログラム群を実行することにより実現される。キュー１３０は、メモリ装置１０３などを用いて実現される。

図１に示されるように、ＷＡＲ１２０は、複数のスレッド１４０を同時に又は並列的に実行することによって、キュー１３０から提供される複数のリクエストを同時に又は並列的に処理する。何れかのスレッド１４０が待機状態になると、ＷＡＲ１２０は、キュー１３０の先頭にあるリクエストを取得し、当該スレッド１４０に取得したリクエストを処理させる。リクエストが処理されると、スレッド１４０は、処理結果データをＷＡＲ１２０及び／又は特定サービス提供部１１０に出力し、特定サービス提供部１１０は、当該リクエストにより要求されたサービスに関する処理結果データを要求元のユーザ装置２００に返信する。

本実施例では、ＷＡＲ１２０に備えられるスレッド１４０の個数は、何れか適切な要因に基づきシステム管理者などによって予め規定される。規定されたスレッド１４０の個数は、当該ＷＡＲ１２０のアプリケーションプログラム群を実行するためのパラメータとしてメモリ装置１０３などに格納され、特定サービス提供部１１０は、メモリ装置１０３に格納されている当該パラメータを参照することによって、規定された個数のスレッド１４０を起動する。

このスレッド１４０の個数は、当該ＷＡＲ１２０によって提供されるサービスに要する計算量、当該サービスに対するリクエストの数量及び／又は頻度、サーバ１００の処理能力などいくつかの要因、又はこれらの要因の何れかの組み合わせに基づき決定されてもよい。

例えば、当該サービスを処理するのに必要とする計算量が大きい場合、１つのリクエストを処理するための時間が大きくなり、リクエストに対する応答の遅延が生じる可能性が高くなる。従って、この場合、スレッド１４０の個数を大きく規定することによって、ユーザが許容できる程度の遅延に抑える。他方、当該サービスを処理するのに必要とする計算量が小さい場合、１つのリクエストを処理するための時間は小さく、リクエストに対する応答の遅延が生じる可能性は低い。従って、この場合、スレッド１４０の個数を小さく規定することによって、サーバ１００のハードウェアリソースを他の特定サービス提供部１１０に配分することが可能となり、システム全体のパフォーマンスを向上させることが可能となる。

また、当該サービスに対するリクエストの数量及び／又は頻度が大きい場合、スレッド１４０の個数を大きく設定することによって、単位時間当たりにより多くのリクエストを処理することが可能となり、また、サービスを提供するまでのユーザの待ち時間をユーザが許容できる程度の遅延に抑える。他方、当該サービスに対するリクエストの数量及び／又は頻度が小さい場合、スレッド１４０の個数を小さく設定することによって、サーバ１００のハードウェアリソースを他の特定サービス提供部１１０に配分することが可能となり、システム全体のパフォーマンスを向上させることが可能となる。

キュー１３０は、ＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ）方式に従ってユーザ装置２００から受信したリクエストを格納し、ＷＡＲ１２０に提供する。すなわち、キュー１３０は、特定サービス提供部１１０が受け入れたリクエストを格納し、ＷＡＲ１２０からの取得要求に応答して、キュー１３０の先頭に格納されているリクエストをＷＡＲ１２０に提供する。

より詳細には、ユーザ装置２００が、所望のサービスを提供する特定サービス提供部１１０にリクエストを送信すると、当該リクエストは、ネットワーク１５０を介し要求先の特定サービス提供部１１０によって受信される。当該リクエストを受信すると、要求先の特定サービス提供部１１０は、当該リクエストを格納するための空き容量がキュー１３０にあるか判断する。当該リクエストを格納するための空き容量がキュー１３０にある場合、特定サービス提供部１１０は、受信したリクエストをキュー１３０の最後尾に格納する。他方、当該リクエストを格納するための空き容量がキュー１３０にない場合、特定サービス提供部１１０は、例えば、処理が混雑中であることを示すメッセージなどを要求元のユーザ装置２００に返信するなどによって、当該リクエストを拒絶する。これにより、特定サービス提供部１１０への過剰なリクエストの流入を制限することが可能になる。

上述した実施例では、複数の特定サービス提供部１１０が、単一のサーバ１００に設けられた。しかしながら、本発明はこれに限定されるものでなく、他の何れか適切な構成であってもよい。例えば、他の実施例では、複数の特定サービス提供部１１０は、複数のサーバ１００に分散されてもよい。また、特定サービス提供部１１０のＷＡＲ１２０とキュー１３０とは、単一のサーバ１００でなく、相互に接続される異なるサーバ１００に設けられてもよい。すなわち、本発明による流量制御機能を有するシステム、すなわち、流量制御システムは、上述したような単一のサーバ１００から構成されてもよいし、あるいは、上述した構成要素を含む複数のサーバ１００を有するサーバシステムであってもよい。

また、上述した実施例では、ＷＡＲ１２０は、複数のスレッド１４０を並列的に実行することによって、キュー１３０から取得したリクエストを処理した。しかしながら、本発明はこれに限定されるものでなく、ＷＡＲ１２０は、複数のリクエスト又はデータを並列的に処理可能な他の何れか適切な処理要素を実行するようにしてもよい。例えば、ＷＡＲ１２０は、複数のプログラム、プロセス、ジョブ、タスクなどの処理要素を並列的に実行することによって、リクエストを処理するようにしてもよい。

また、上述した実施例では、サーバ１００は単一のネットワーク１５０に接続されている。しかしながら、本発明はこれに限定されるものでなく、他の何れか適切な構成であってもよい。例えば、他の実施例では、サーバ１００又はサーバシステムは複数の異なるネットワーク１５０に接続されてもよい。この場合、後述されるように、同一タイプのサービス又はサービス群を提供する特定サービス提供部１１０が、複数のネットワーク１５０に対応して複数設けられてもよい。

図示された実施例によると、サービス種別毎に、すなわち、特定のサービスを提供するＷＡＲ毎又は宛先毎に、特定サービス提供部１１０が設けられる。各特定サービス提供部１１０は、当該サービス及び当該サービスに対するリクエストに適した流量制御を実行することが可能になる。これにより、サービス種別に関係なくリクエストを処理する場合に、流量制御によりシステム全体が受信を制限してしまう事態を解消することが可能になる。

次に、図３を参照して、本発明の一実施例によるサーバにおける流量制御を説明する。上述したように、サーバ１００は、サービス種別毎にユーザからのリクエストを処理する特定サービス提供部１１０を有し、特定サービス提供部１１０毎に規定されたキュー長Ｌのキュー１３０を利用して、特定サービス提供部１１０毎に流量制御を実行する。

図３は、本発明の一実施例による流量制御の概略図である。図３に示されるように、図示されるＷＡＲ１２０では、３つのスレッド１４０＿１，１４０＿２，１４０＿３が起動可能であり、キュー１３０はＬ個のリクエストを格納可能である。すなわち、キュー１３０により記憶可能なリクエストの個数を示すキュー長は、Ｌに設定される。

図示される具体例では、各スレッド１４０はリクエストを現在処理しており、当該処理が完了すると、キュー１３０の先頭のリクエスト“１”が次に処理される。ＷＡＲ１２０は特定のタイプのサービス又はサービス群を提供するため、一般に各スレッド１４０による処理も同様のものとなり、同程度の処理時間で処理が完了する。このため、キュー１３０の先頭から３つのリクエストが３つのスレッド１４０に順次配分され、これらのスレッド１４０が３つのリクエストを並列的又は同時に処理する。

本実施例では、キュー長Ｌは、後述されるキュー長設定方法に従って、システム管理者などによって所定数のリクエストを格納可能な長さに予め設定される。設定されたキュー長Ｌは、サーバ１００のメモリ装置１０３などにパラメータとして格納され、特定サービス提供部１１０は、メモリ装置１０３に格納されている当該パラメータを参照することによって、設定されたキュー長Ｌのキュー１３０をメモリ装置１０３に確保する。

大きなキュー長Ｌが設定される場合、特定サービス提供部１１０は多数のリクエストを受け入れ可能であるが、スレッド１４０による処理を待機する処理実行待ち時間は相対的に長くなり、ユーザに不便なものになる。他方、小さなキュー長Ｌが設定される場合、特定サービス提供部１１０は少数のリクエストしか受け入れられず、例えばバースト的にリクエストを受信すると、これらのリクエストの多くが拒絶される可能性がある。

このため、本実施例では、キュー長Ｌは、キュー１３０の最後尾に格納されている処理待ちリクエストが所定の目標待ち時間ｔａｒｇｅｔ＿Ｒｅｓ以内で処理されるよう、すなわち、特定サービス提供部１１０におけるリクエスト処理時間が目標待ち時間ｔａｒｇｅｔ＿Ｒｅｓ以内となるよう規定される。このようにしてキュー長Ｌが設定されると、特定サービス提供部１１０は、受け入れられたリクエストを目標待ち時間ｔａｒｇｅｔ＿Ｒｅｓ以内に処理することができる。

従って、要求元のユーザ装置２００は、当該目標待ち時間ｔａｒｇｅｔ＿Ｒｅｓに、要求されたデータをサーバ１００からユーザ装置２００に送信するのに要する通信時間を加えた時間内に、要求したサービスに関するデータを受信することが可能になる。例えば、サーバ１００からユーザ装置２００に当該データを送信するため３秒の通信時間を必要とし、リクエストの受信から５秒以内でユーザ装置２００に要求されたサービスを提供するよう設定された場合、目標待ち時間ｔａｒｇｅｔ＿Ｒｅｓは２秒に設定される。すなわち、キュー長Ｌは、キュー１３０の最後尾に格納されている処理待ちリクエストが２秒以内でスレッド１４０によって処理されるよう規定される。

特定サービス提供部１１０におけるリクエスト処理時間は、当該リクエストがキュー１３０において待機している処理実行待ち時間とスレッド１４０における処理時間との合計時間となる。また、この処理実行待ち時間は、ＷＡＲ１２０に備えられるスレッドの個数ｍに依存することは理解されるであろう。すなわち、ＷＡＲ１２０に多数のスレッド１４０が設けられている場合、処理実行待ち時間は相対的に短くなり、ＷＡＲ１２０に少数のスレッド１４０しか設けられていない場合、処理実行待ち時間は相対的に長くなる。

他方、スレッド１４０における処理時間は、過去に実行された処理に要した時間などに基づき推定可能である。例えば、過去のある期間内において実行された処理に要した処理時間の平均値である平均レスポンス時間ａｖｅｒａｇｅ＿Ｒｅｓが、スレッド１４０における処理時間として利用されてもよい。従って、キュー長Ｌは、スレッド１４０の個数ｍと平均レスポンス時間ａｖｅｒａｇｅ＿Ｒｅｓとにより規定されてもよい。

具体的には、キュー長Ｌは、以下の関係式（１）を満たすよう決定されてもよい。

ｔａｒｇｅｔ＿Ｒｅｓ≧（Ｌ＋ｍ）／ｍ×ａｖｅｒａｇｅ＿Ｒｅｓ （１）
すなわち、現在処理中のリクエストとキュー１３０に待機中のリクエストとを実行するためにｍ個のスレッド１４０をパラレルに実行する回数（（Ｌ＋ｍ）／ｍ）と、１回のパラレルな実行に要する平均レスポンス時間（ａｖｅｒａｇｅ＿Ｒｅｓ）とを掛け合わすことによって求められるリクエスト処理時間が、目標待ち時間（ｔａｒｇｅｔ＿Ｒｅｓ）以下になるようキュー長Ｌが決定される。これにより、キュー１３０の最後尾に格納されている処理待ちリクエストが所定の目標待ち時間ｔａｒｇｅｔ＿Ｒｅｓ以内で処理されるようキュー長を設定することが可能になる。好ましくは、キュー長Ｌは、上記関係式（１）を満たす最大の整数に規定されてもよい。

また、他の実施例では、キュー長Ｌは、
ｔａｒｇｅｔ＿Ｒｅｓ＝（Ｌ＋ｍ）／ｍ×ａｖｅｒａｇｅ＿Ｒｅｓ （２）
を満たすよう規定されてもよい。

図示された実施例によると、流量制御機能を実行しながら、受け入れたリクエストに関するサービスを所定のユーザ待ち時間内で要求元のユーザ装置２００に提供することが可能になる。

次に、図４〜５を参照して、本発明の一実施例による特定サービス提供部による処理を説明する。

図４は、本発明の一実施例による特定サービス提供部によるリクエスト受け入れ処理を示すフロー図である。図４に示されるように、特定サービス提供部１１０が起動されると、特定サービス提供部１１０は、メモリ装置１０３などに格納されているパラメータを読み、規定されたキュー長Ｌに対応する記憶領域をキュー１３０のためのメモリ装置１０３に確保することによって、リクエスト受け入れ処理を開始する。

ステップＳ１０１において、特定サービス提供部１１０は、ネットワーク１５０を介し当該特定サービス提供部１１０を宛先とするリクエストをユーザ装置２００から受信する。

ステップＳ１０２において、特定サービス提供部１１０は、キュー１３０の空き容量を確認し、受信したリクエストをキュー１３０に格納可能か判断する。すなわち、キュー１３０がＬ個未満のリクエストしか有していない場合、特定サービス提供部１１０は、キュー１３０に空き容量があると判断する。他方、キュー１３０がＬ個のリクエストを有している場合、特定サービス提供部１１０は、キュー１３０に空き容量がないと判断する。

特定サービス提供部１１０がキュー１３０に空き容量があると判断すると（Ｓ１０２：Ｙ）、ステップＳ１０３において、特定サービス提供部１１０は、受信したリクエストを受け入れ、キュー１３０の最後尾に格納する。他方、特定サービス提供部１１０がキュー１３０に空き容量がないと判断すると（Ｓ１０２：Ｎ）、特定サービス提供部１１０は、受信したリクエストを拒絶する。受信したリクエストを拒絶する場合、特定サービス提供部１１０は、例えば、当該リクエストの送信元のユーザ装置２００に処理が混雑中であるなどのメッセージを返信するようにしてもよい。

ステップＳ１０３におけるキュー１３０への格納後、ステップＳ１０１に戻り、特定サービス提供部１１０は、ユーザ装置２００からの次のリクエストの受信を待機する。

図５は、本発明の一実施例による特定サービス提供部によるリクエスト処理を示すフロー図である。図５に示されるように、特定サービス提供部１１０が起動されると、特定サービス提供部１１０は、メモリ装置１０３などに格納されているアプリケーションプログラム群及びパラメータを読み、規定されたスレッド数に対応するスレッド１４０をＷＡＲ１２０において起動する。

ステップＳ２０１において、特定サービス提供部１１０は、ＷＡＲ１２０において待機状態のスレッド１４０があるか確認する。

待機状態のスレッド１４０がＷＡＲ１２０にある場合（Ｓ２０１：Ｙ）、ステップＳ２０２において、特定サービス提供部１１０は、キュー１３０に処理待ちのリクエストがあるか判断する。他方、待機状態のスレッド１４０がＷＡＲ１２０にない場合（Ｓ２０１：Ｎ）、特定サービス提供部１１０は、待機状態になるスレッド１４０が検出されるまでステップＳ２０１を繰り返す。

ステップＳ２０２においてキュー１３０に処理待ちのリクエストがある場合（Ｓ２０２：Ｙ）、ステップＳ２０３において、特定サービス提供部１１０は、キュー１３０の先頭にあるリクエストを取得する。他方、ステップＳ２０２においてキュー１３０に処理待ちのリクエストがない場合（Ｓ２０２：Ｎ）、特定サービス提供部１１０は、キュー１３０に新たなリクエストが格納されるまでステップＳ２０２を繰り返す。

ステップＳ２０４におけるリクエストの取得後、特定サービス提供部１１０は、取得したリクエストをスレッド１４０に割り当て、当該スレッド１４０にリクエストを処理させる。

次に、サーバ１００が複数のネットワーク１５０に接続される変形例について説明する。リクエストの受信から所定のユーザ待ち時間（５秒など）以内にユーザ装置２００に要求されたサービスを提供すると設定されたとき、このユーザ待ち時間は、サーバ１００におけるリクエスト処理時間と、サーバ１００からユーザ装置２００に要求されたデータを送信するための通信時間（３秒など）との合計時間となる。このため、ネットワーク１５０の通信状態が良好及び／又は安定的であり、相対的に小さい通信時間が設定可能である場合、目標待ち時間ｔａｒｇｅｔ＿Ｒｅｓをより長く設定することが可能である。他方、ネットワーク１５０の通信状態が不良及び／又は不安定であり、相対的に大きい通信時間が設定される必要がある場合、目標待ち時間ｔａｒｇｅｔ＿Ｒｅｓをより小さく設定しなければならない。すなわち、ネットワークの通信品質に応じて、異なる目標待ち時間が設定されるようにしてもよい。

例えば、サーバ１００が複数のネットワーク１５０に接続される場合、同一のタイプのサービス又はサービス群を提供する特定サービス提供部１１０が、複数のネットワーク１５０のそれぞれに対して設けられるようにしてもよい。例えば、同一のタイプのサービス又はサービス群を提供する特定サービス提供部１１０について、インターネットに接続される特定サービス提供部１１０と携帯電話キャリアのネットワークに接続される特定サービス提供部１１０とが別々に設けられてもよい。このとき、これら２つの特定サービス提供部１１０は同一タイプのサービス又はサービス群を提供するが、接続されるネットワーク１５０の通信品質に応じて異なるキュー長Ｌが設定可能になる。すなわち、特定サービス提供部１１０が、携帯電話キャリアにより運営されるネットワークなどの比較的良好な通信品質を有するネットワーク１５０を介しユーザ装置２００からリクエストを受信する場合、目標待ち時間ｔａｒｇｅｔ＿Ｒｅｓは相対的に大きな値に設定可能であり、より大きなキュー長Ｌを有するキュー１３０を設定することが可能である。他方、特定サービス提供部１１０が、ユーザ装置２００からインターネットなど通信品質が比較的安定しないネットワーク１５０を介しリクエストを受信する場合、目標待ち時間ｔａｒｇｅｔ＿Ｒｅｓは相対的に小さな値に設定される必要があり、より小さなキュー長Ｌを有するキュー１３０を設定する必要がある。

本変形例によると、ネットワークの種別に応じて異なる特定サービス提供部１１０が設けられ、各特定サービス提供部１１０はネットワークの通信品質に適した流量制御が可能になる。

以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ システム
１００ サーバ
１１０ 特定サービス提供部
１２０ ウェブアプリケーションリソース（ＷＡＲ）
１３０ キュー
１４０ スレッド
１５０ ネットワーク
２００ ユーザ装置

Claims (2)

1. サービスに対する複数の処理待ちデータを保持するキューと、
   前記キューから提供される前記処理待ちデータを処理するスレッドと、
   を有する流量制御システムであって、
   前記キューのキュー長は、ネットワークの通信品質に応じて規定される流量制御システム。
2. 前記キュー長は、前記キューの最後尾に格納されている処理待ちデータが前記ネットワークの通信品質に応じて設定される目標待ち時間以内で処理されるよう規定される、請求項１記載の流量制御システム。

Images