(57)【要約】【課題】サーバ混雑時において、重要なリクエストを優先的にアプリケーション上で処理させる。【解決手段】サーバのアプリケーション層でリクエストの種別に応じた優先制御を行う。サーバがＴＣＰ／ＩＰを介してリクエストを受信すると、次に、Ｗｅｂアプリケーションでリクエストを処理させる前に、リクエストを解析する。そして、重要だと判定されたリクエストから、優先的にＷｅｂアプリケーションで処理させる。また、サーバが混雑し全てのリクエストを処理しきれなくなった場合は、重要度の低いリクエストから拒絶する。さらに、サーバの過負荷を検知すると、クライアント単位でＴＣＰ／ＩＰ層を制御しパケット受信を規制する。このとき、リクエスト分析結果をもとに、クライアントが今後送信するリクエストの優先度が高いか否かを予測する。【選択図】図２
2008059040.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからリクエストを受信し、レスポンスを返送するサーバに用いる負荷制御システムにおいて、
複数のリクエストを要する処理の進行に基づき、リクエストの送信元クライアントのＩＰアドレス毎に優先度を設定する手段と、
サーバ負荷が閾値を超えたか否かを判定する手段と、
閾値を超えた場合に、低い優先度に設定されたＩＰアドレスからのＩＰパケット受信を制限する手段と
を備えたことを特徴とする負荷制御システム。
【請求項２】
クライアントからリクエストを受信し、レスポンスを返送するサーバに用いる負荷制御システムにおいて、
リクエストに格納されたユーザ識別情報に基づき、リクエストの送信元クライアントのＩＰアドレス毎に優先度を設定する手段と、
サーバ負荷が閾値を超えたか否かを判定する手段と、
閾値を超えた場合に、低い優先度に設定されたＩＰアドレスからのＩＰパケット受信を制限する手段と
を備えたことを特徴とする負荷制御システム。
【請求項３】
ＴＣＰ／ＩＰプロトコルを用いて、ＩＰパケットのうち、ＴＣＰ／ＳＹＮパケットのレートを制限することでＩＰパケット受信を制限する請求項１または２記載の負荷制御システム。
【請求項４】
ＴＣＰ／ＩＰプロトコルを用いて、サーバシステムから送信されるＴＣＰ−ＡＣＫパケットにあるＴＣＰヘッダのＷｉｎｄｏｗサイズを減じることによりＩＰパケット受信を制限する請求項１または２記載の負荷制御システム。
【請求項５】
ＴＣＰ／ＩＰプロトコルを用いて、ＴＣＰコネクションを切断することによりＩＰパケット受信を制限する請求項１または２記載の負荷制御システム。
【請求項６】
サーバ負荷が閾値を超えた場合に前記ＩＰパケット受信の制限を段階的に強め、サーバ負荷が閾値以下となった場合に前記ＩＰパケット受信の制限を段階的に弱める請求項１ないし５のいずれかに記載の負荷制御システム。
【請求項７】
クライアントからリクエストを受信し、レスポンスを返送するサーバに用いる負荷制御方法において、
複数のリクエストを要する処理の進行に基づき、リクエストの送信元クライアントのＩＰアドレス毎に優先度を設定し、
サーバ負荷が閾値を超えたか否かを判定し、閾値を超えた場合に、低い優先度に設定されたＩＰアドレスからのＩＰパケット受信を制限する
ことを特徴とする負荷制御方法。
【請求項８】
クライアントからリクエストを受信し、レスポンスを返送するサーバに用いる負荷制御方法において、
リクエストに格納されたユーザ識別情報に基づき、リクエストの送信元クライアントのＩＰアドレス毎に優先度を設定し、
サーバ負荷が閾値を超えたか否かを判定し、閾値を超えた場合に、低い優先度に設定されたＩＰアドレスからのＩＰパケット受信を制限する
ことを特徴とする負荷制御方法。
【請求項９】
ＴＣＰ／ＩＰプロトコルを用いて、ＩＰパケットのうち、ＴＣＰ／ＳＹＮパケットのレートを制限することでＩＰパケット受信を制限する請求項７または８記載の負荷制御方法。
【請求項１０】
ＴＣＰ／ＩＰプロトコルを用いて、サーバシステムから送信されるＴＣＰ−ＡＣＫパケットにあるＴＣＰヘッダのＷｉｎｄｏｗサイズを減じることによりＩＰパケット受信を制限する請求項７または８記載の負荷制御方法。
【請求項１１】
ＴＣＰ／ＩＰプロトコルを用いて、ＴＣＰコネクションを切断することによりＩＰパケット受信を制限する請求項７または８記載の負荷制御方法。
【請求項１２】
サーバ負荷が閾値を超えた場合に前記ＩＰパケット受信の制限を段階的に強め、サーバ負荷が閾値以下となった場合に前記ＩＰパケット受信の制限を段階的に弱める請求項７ないし１１のいずれかに記載の負荷制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントからリクエストを受信し、レスポンスを返送するサーバが過負荷となった場合のパケット制御技術に関する。特に、リクエストの優先度予測に基づき、クライアント単位で優先制御を行うパケット制御技術に関する。なお、本明細書では、Ｗｅｂサーバに着目して説明するが、必ずしも他のサーバへの本発明の適用を制限するものではない。
【背景技術】
【０００２】
インターネットの普及に伴い、ネットワークを介して様々なサービスを利用できるようになっている。メール、ホームページの閲覧、検索、オンライン取引、ＩＰ電話、ビデオオンデマンドなどは、その一例である。これらのネットワークサービスは様々な形態で提供し得るが、近年、クライアントとのインタフェースとして、Ｗｅｂサーバの利用が主流となっている。
【０００３】
Ｗｅｂサーバを用いたサービス（Ｗｅｂサービス）の基本的な仕組みは以下のとおりである。まず、クライアントがＷｅｂサーバに対して、取得したいコンテンツを識別するＵＲＬ(Uniform Resource Locator)を付与したリクエストを送信する。Ｗｅｂサーバがリクエストを受け取ると、リクエスト中のＵＲＬに対するコンテンツをレスポンスとしてクライアントに送り返す。Ｗｅｂサービスは、このリクエスト−レスポンスの繰り返しによって提供される。
【０００４】
本明細書では、Ｗｅｂサービスを行うサーバシステム全体をＷｅｂサーバ、また、Ｗｅｂサーバ上でリクエストに応じたコンテンツを生成する機能をＷｅｂアプリケーションと呼ぶ。また、Ｗｅｂサービスでは、リクエスト・レスポンスを送受信するためのトランスポート層／ネットワーク層プロトコルとしてＴＣＰ／ＩＰが用いられている。
【０００５】
Ｗｅｂサービスの課題として、リクエストが集中した場合の、サーバの負荷制御が挙げられる。特に、Ｗｅｂサービスでは、リクエストの内容に応じて、その重要度が異なる。故に、サーバが混雑時には重要なリクエストから優先的に処理することが必要である。
【０００６】
例えば、Ｗｅｂサービスでは、クライアントのブラウザ上に一つのページを表示するために、多数のリクエストが必要になる場合がある。１つのページを表示するためのリクエストの繰り返しを、本明細書ではページ処理と呼ぶ。このとき、サーバが混雑時には、最初のページ取得要求を非優先化することが望ましく、既に開始されたページ処理は保護する必要がある。
【０００７】
ページ処理の基本的な進行手順は以下のとおりである。まず、クライアントはブラウザに対して取得したいページのルートとなるリソース（以下、ページルートリソース）のＵＲＬを入力する。次に、ブラウザは、入力されたＵＲＬに基づき、Ｗｅｂサーバに対してリクエストを送信し、ページルートリソースを取得する。このとき、ページルートリソースにはページ表示に必要となる他のリソースのＵＲＬが指し示される。次に、ブラウザは、指し示されるＵＲＬに対して自動的にリクエストを発行する。以上を、ページ表示に必要な全リソースを取得するまで再帰的に繰り返す。
【０００８】
多数のクライアントからページ処理を要求されると、サーバ上のリソース競合によってページ処理中のリクエストが失敗し、いずれのクライアントにおいてもページが完全に表示されなくなる、という状況が引き起こされる。この問題を解決するためには、新規のページ処理要求を非優先化させ、既に開始されたページ処理を保護することが必要となる。
【０００９】
また、Ｗｅｂサービスでは、複数のページに跨がって、閲覧および情報入力をすることで、初めて１つのサービスが完了する場合がある。例えば、オンラインショッピングでは、購入すべき商品の選択、クライアント情報の入力などをし、最後に購入内容の確認をすることで、初めて購入手続きが完了する。
【００１０】
本明細書では、完了までに複数ページを要するサービスにおいて、クライアントが先頭ページを取得してから最後のページを取得完了するまでをセッションと呼ぶ。セッションは、金品の取引や、個人情報の更新など、重要な処理を行う場合に用いられる。
【００１１】
【特許文献１】特開２００２−１６６３３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
上述したセッション処理においては、サーバが混雑すると、セッション処理がほとんど完了しなくなる、という問題が生じる。この問題は、サーバ上で並列処理されるセッションの数が増加すると、セッション間でサーバリソースが競合し、途中失敗するセッションが増加することによって引き起こされる。故に、新規のセッション処理要求を非優先化させ、既に開始済みのセッション処理を保護することが必要である。
【００１３】
サーバ混雑を解決することを目的に、既に、ＣＰＵ使用率などに応じて送信元ＩＰアドレス単位でパケットを廃棄する手法が提案されている（例えば、特許文献１参照）。しかしながら、この手法では、Ｗｅｂアプリケーションにおける優先度を考慮しないため、前述したページ処理やセッション処理を保護することはできない。
【００１４】
本発明は、サーバ混雑時において、重要なリクエストを優先的にアプリケーション上で処理させることを目的とする。
【課題を解決するための手段】
【００１５】
本発明では、まず、リクエスト優先制御手段において、サーバのアプリケーション層でリクエストの種別に応じた優先制御を行う。サーバがＴＣＰ／ＩＰを介してリクエストを受信すると、次に、Ｗｅｂアプリケーションでリクエストを処理させる前に、リクエストを解析する。そして、重要だと判定されたリクエスト、例えば、継続中のページ・セッション処理に属するリクエストから、優先的にＷｅｂアプリケーションで処理させる。また、サーバが混雑し全てのリクエストを処理しきれなくなった場合は、重要度の低いリクエストから拒絶する。
【００１６】
さらに本発明では、リクエスト優先制御手段自体が過負荷とならないように、リクエストの優先度予測を用いてＴＣＰ／ＩＰを制御する。すなわち、リクエスト優先制御手段によるリクエストの解析および重要度判定に要する計算コストが大きく、また、リクエスト受信時にはＴＣＰ／ＩＰ処理といったリクエスト受信処理を伴うため、サーバが混雑するほど、アプリケーション層によるリクエスト優先制御が過負荷となり、重要なリクエストの取りこぼしが生じるようになる。そこで本発明では、サーバの過負荷を検知すると、クライアント単位でＴＣＰ／ＩＰ層を制御しパケット受信を規制することで、リクエスト優先制御手段の負荷を軽減する。
【００１７】
このとき、優先度予測手段において、リクエスト優先制御手段におけるリクエスト分析結果をもとに、クライアントが今後送信するリクエストの優先度が高いか否かを予測する。そして、予測された優先度をＴＣＰ／ＩＰ層における優先制御に反映させている。これにより、アプリケーション層で優先化される可能性が高いリクエストは、ＴＣＰ／ＩＰ層で規制されることなく、Ｗｅｂアプリケーションで処理させることができる。
【００１８】
ＴＣＰ／ＩＰ層ではＩＰアドレスに基づき優先制御を行う。このため、ＴＣＰ／ＩＰ層の優先制御では、アプリケーション層でのリクエスト単位での優先制御を正確に反映できない場合がある。しかし、リクエスト優先制御の負荷軽減による重要リクエストの保護、という目的を阻害するものではない。例えば、異なるクライアントが同じプロキシを経由してリクエストが転送されている場合は、サーバが受け取るパケットの送信元ＩＰアドレスは、全てプロキシのＩＰアドレスとなる。したがって、複数のクライアントがプロキシを介して接続している場合には、個々のクライアント毎に優先制御を行うことができない。しかしながら、サーバ混雑時には、同プロキシ以外の送信元ＩＰアドレスも多く存在すると予測できる。故に、他の送信元ＩＰアドレスからのトラヒック規制によって、十分な負荷軽減効果が得られる。プロキシに接続された全てのクライアントが非優先化された場合に、初めてプロキシからのリクエストを非優先化すればよい。
【００１９】
すなわち、本発明は、クライアントからリクエストを受信し、レスポンスを返送するサーバに用いる負荷制御システムであって、本発明の特徴とするところは、前記リクエスト優先制御手段に、複数のリクエストを要する処理の進行に基づき、リクエストの送信元クライアントのＩＰアドレス毎に優先度を設定する手段と、サーバ負荷が閾値を超えたか否かを判定する手段と、閾値を超えた場合に、低い優先度に設定されたＩＰアドレスからのＩＰパケット受信を制限する手段とを備えたところにある。
【００２０】
あるいは、前記リクエスト優先制御手段に、リクエストに格納されたユーザ識別情報に基づき、リクエストの送信元クライアントのＩＰアドレス毎に優先度を設定する手段を備えることもできる。
【００２１】
前記ＩＰパケット受信を制限する手段は、例えば、ＴＣＰ／ＩＰプロトコルを用いて、ＩＰパケットのうち、ＴＣＰ／ＳＹＮパケットのレートを制限することでＩＰパケット受信を制限する。あるいは、ＴＣＰ／ＩＰプロトコルを用いて、サーバシステムから送信されるＴＣＰ−ＡＣＫパケットにあるＴＣＰヘッダのＷｉｎｄｏｗサイズを減じることによりＩＰパケット受信を制限する。あるいは、ＴＣＰ／ＩＰプロトコルを用いて、ＴＣＰコネクションを切断することによりＩＰパケット受信を制限する。
【００２２】
また、サーバ負荷が閾値を超えた場合に前記ＩＰパケット受信の制限を段階的に強め、サーバ負荷が閾値以下となった場合に前記ＩＰパケット受信の制限を段階的に弱めることができる。
【００２３】
また、本発明を負荷制御方法の観点から観ると、本発明は、クライアントからリクエストを受信し、レスポンスを返送するサーバに用いる負荷制御方法であって、本発明の特徴とするところは、複数のリクエストを要する処理の進行に基づき、リクエストの送信元クライアントのＩＰアドレス毎に優先度を設定し、サーバ負荷が閾値を超えたか否かを判定し、閾値を超えた場合に、低い優先度に設定されたＩＰアドレスからのＩＰパケット受信を制限するところにある。
【００２４】
あるいは、リクエストに格納されたユーザ識別情報に基づき、リクエストの送信元クライアントのＩＰアドレス毎に優先度を設定してもよい。
【００２５】
前記ＩＰパケット受信を制限する際には、例えば、ＴＣＰ／ＩＰプロトコルを用いて、ＩＰパケットのうち、ＴＣＰ／ＳＹＮパケットのレートを制限することでＩＰパケット受信を制限する。あるいは、ＴＣＰ／ＩＰプロトコルを用いて、サーバシステムから送信されるＴＣＰ−ＡＣＫパケットにあるＴＣＰヘッダのＷｉｎｄｏｗサイズを減じることによりＩＰパケット受信を制限する。あるいは、ＴＣＰ／ＩＰプロトコルを用いて、ＴＣＰコネクションを切断することによりＩＰパケット受信を制限する。
【００２６】
また、サーバ負荷が閾値を超えた場合に前記ＩＰパケット受信の制限を段階的に強め、サーバ負荷が閾値以下となった場合に前記ＩＰパケット受信の制限を段階的に弱めることができる。
【発明の効果】
【００２７】
本発明に基づくことにより、サーバ過負荷時におけるリクエスト優先制御に要する負荷を軽減できる。
【発明を実施するための最良の形態】
【００２８】
（第一〜第三実施例に共通の事項）
本実施例の負荷制御システムのブロック構成を図１に示す。本実施例は、クライアント１−１〜１−ｎと負荷制御機能付サーバ３とから構成される。以下、単にサーバと呼ぶ場合は、この負荷制御機能付サーバ３を指すものとする。サーバは、ネットワークを介して１つ以上のクライアント１−１〜１−ｎ（以下では符号１−１〜１−ｎを省略する）と接続される。サーバがリクエストを受信すると、適切なコンテンツをレスポンスとして返送する。サーバは、リクエストを自身で処理することも、バックエンドのサーバに対して処理を依頼するプロキシとして動作することもできる。
【００２９】
リクエストを処理し終わると、サーバは結果をレスポンスとしてクライアントに返送する。なお、サーバとクライアントとの間でリクエスト／レスポンスを送受信するためのプロトコルとして、ＴＣＰ／ＩＰが用いられるものとする。
【００３０】
本実施例のサーバは、サーバの負荷に応じてＴＣＰ／ＩＰ処理を適切に制御する。ここで、サーバ負荷の測定対象として、以下のリソースを想定する。このとき、以下のリソースのいずれかのみを測定しても、全リソースを測定しても、また、複数のリソースを選択的に測定してもよい。
・ＣＰＵ使用率（Ｕ）：サーバ全体で単位時間あたりに使用したＣＰＵ時間の割合
・メモリ使用量（Ｍ）：サーバが使用中のメモリ量
・同時接続ＴＣＰコネクション数（Ｃ）：クライアントとサーバとの間で接続されるＴＣＰコネクションの数
さらに、各リソースに閾値を定める。ＣＰＵ使用率Ｕ、メモリ使用量Ｍ、同時接続ＴＣＰコネクション数Ｃに対する閾値をそれぞれ、ＬＵ、ＬＭ、ＬＣと表記する。本発明では、測定対象とする、各リソースがその閾値を超える場合に、サーバが過負荷である、と表現する。本実施例では、各リソースが閾値以下となるように、ＴＣＰ／ＩＰ処理の制御を試みる。
【００３１】
本実施例のサーバの構成を図２に示す。本実施例のサーバは、以下によって構成される。
・アプリケーション部１０
・リクエスト優先制御部１１
・負荷制御機能付ＴＣＰ／ＩＰ処理部１２
・優先度予測部１３
アプリケーション部１０では、リクエストに指定されるＵＲＬに基づきコンテンツを作成し、レスポンスとして返送する。アプリケーション部１０にリクエストを処理させても、アプリケーション部１０をリバースＰｒｏｘｙとして動作させ、バックエンドのサーバにリクエストを処理させてもよい。
【００３２】
リクエスト優先制御部１１では、サーバのアプリケーション層でリクエストの種別に応じた優先制御をする。サーバがＴＣＰ／ＩＰを介してリクエストを受信すると、次に、Ｗｅｂアプリケーションでリクエストを処理させる前に、リクエストを解析する。そして、重要だと判定されたリクエスト、例えば、継続中のページ・セッション処理に属するリクエストから、優先的にＷｅｂアプリケーションで処理させる。また、サーバが混雑し全てのリクエストを処理しきれなくなった場合は、重要度の低いリクエストから拒絶する。
【００３３】
優先度予測部１３は、リクエスト優先制御部１１におけるリクエスト分析結果を元に、同じ送信元ＩＰアドレスから送信される後続リクエストの優先度を予測する。ここで、説明を簡単化するため、リクエストの優先度として、高優先と低優先との２段階のみを用いる。優先度予測部１３では、後続リクエストが高優先であると判定されたクライアントの送信元ＩＰアドレスを高優先アドレス表に登録する。
【００３４】
本実施例のＴＣＰ／ＩＰ処理では、この高優先アドレス表を参照することで、負荷を制御する。図３に高優先アドレス表を示す。高優先アドレス表には、高優先なリクエストを送信すると予測される送信元のＩＰアドレスと、当該エントリの有効期限とが登録される。有効期限としては、２００６年５月２１日１３時４５分３０秒のように絶対時刻で設定することも、残り何秒、というように相対時間で設定することもできる。
【００３５】
高優先コネクション表への登録時に、既に同じアドレスが登録されていた場合は、該当するエントリの有効期限のみを更新すればよい。なお、本明細書では、高優先アドレス表にＩＰアドレスが登録されているクライアントを高優先クライアント、登録されていないクライアントを低優先クライアントと呼ぶ。また、高優先クライアントと接続されるコネクションを高優先コネクション、低優先クライアントと接続されるコネクションを低優先コネクションと呼ぶこととする。
【００３６】
本実施例における優先度予測方法を示す。以下で示す方法の全てを用いても、いずれかのみを用いてもよい。
・複数のリクエストが必要な処理の進行に基づく予測：前述したように、一つの処理を完了するために、複数のリクエストの実行を要する処理として、ページ処理、セッション処理がある。本実施例では、ページ処理またはセッション処理の進行に基づき、今後送られてくるリクエストの優先度をＩＰアドレス単位で予測する。
【００３７】
・ページ処理の進行に基づく優先度予測：ページ処理保護の観点から、処理中のページ処理に属するリクエストを優先化する場合がある。故に、ページルートリソースへのリクエストの処理が完了した時点で、そのリクエストのクライアントのアドレスを優先アドレス表に登録する。ページルートリソースであるか否かは、例えば、ページルートリソースとそれ以外のリソースとを異なるディレクトリに格納しておくことで、リクエストのＵＲＬから判定できる。高優先アドレス表の有効期限としてページ処理の完了に十分な値を設定する。一般的に、ページ処理は通常、数秒で完了する。
【００３８】
・セッション処理の進行に基づく優先度予測：セッション処理保護の観点から、処理中のページ処理に属するリクエストは優先化する場合がある。故に、セッション開始がアプリケーションに承認されたクライアントのアドレスを優先アドレス表に登録する。セッション処理が承認されたか否かの判定法として、例えば、以下の方法がある。
【００３９】
Ｗｅｂサーバでは一般的に、セッション処理の開始時にセッション識別番号を発行する。そして、セッション識別番号を、ＨＴＴＰのＣｏｏｋｉｅなどを用いてレスポンスに付与し、クライアントに通知する。クライアントは、その後のリクエストにＷｅｂサーバから通知されたセッション識別番号を付与することで、Ｗｅｂサーバはリクエストが属するセッションを識別する。
【００４０】
したがって、優先度予測部１３では、レスポンスにセッション識別番号が付与されている場合に、そのクライアントがセッション処理を開始したとみなす。そして、レスポンスの返却先であるクライアントのＩＰアドレスを、高優先アドレス表に格納する。有効期限はセッション処理を完了するのに十分な値を設定する。セッション処理は一般的に数分〜数十分を要するため、ページ処理の有効期限より長く設定すべきである。
・ユーザ識別番号（ユーザＩＤ）に基づく優先度予測：リクエスト中に格納されるユーザＩＤに基づきリクエストを優先制御する場合がある。ユーザＩＤは一般的に、ＣｏｏｋｉｅやＵＲＬのクエリに格納される。故に、リクエストを受信した際に、リクエストのＣｏｏｋｉｅやＵＲＬを検査し、ユーザＩＤが含まれるか否かを判定する。
【００４１】
ユーザＩＤが含まれる場合は、次に、そのユーザＩＤが優先化されるべきＩＤか否かを判定する。高優先とすべきユーザＩＤである場合は、そのリクエストを送信したクライアントが今後もそのユーザＩＤをリクエストに含める可能性が高いと判定し、そのアドレスを高優先アドレス表に登録する。ユーザＩＤとアドレスとの関係は頻繁に変化しないと考えられるため、有効期限としてページ処理、セッション処理の場合より長く設定することができる。
【００４２】
（第一実施例）
第一実施例として、負荷制御機能付ＴＣＰ／ＩＰ処理部１２の実行手順を説明する。負荷制御機能付ＴＣＰ／ＩＰ処理部１２とは、本発明に基づく負荷制御が可能なように拡張されたＴＣＰ／ＩＰである。すなわち、サーバ過負荷時には、優先度予測部１３の予測結果に基づき、クライアントからのパケット受信を規制する。処理内容の多くは通常のＩＰ処理と同じであるため、ここでは、通常のＴＣＰ／ＩＰ処理と異なる箇所にのみ注目して説明する。
【００４３】
まず、本ＴＣＰ／ＩＰ処理の開始時に、サーバ負荷に応じて、ＩＰパケットの受信可否を制御する。ここでは特にＴＣＰコネクションの接続レートの制御を行う。過負荷時には、ＩＰパケットのうち、ＴＣＰコネクションの接続要求、すなわちＴＣＰ／ＳＹＮパケットレートを制限することで、既存のコネクションを保護しつつ、新たなコネクションからのリクエストの転送を抑制する。
【００４４】
ここで接続要求レートの上限をＦ(pps: packet per second)で表す。このとき本実施例では、サーバ負荷が閾値を超えている場合は、接続要求レートの上限Ｆを減少させる。そして上限Ｆを超えるＴＣＰ／ＳＹＮパケットを受信した場合は、その超過分を廃棄する。
【００４５】
一方で、サーバ負荷が閾値を超えていないにも関わらずＴＣＰ／ＳＹＮパケットが廃棄されている場合は、その接続要求レートの上限Ｆを上昇させる。さらに本実施例では、接続要求レート制限において、アプリケーション層で予測された優先度を用いた優先制御を行う。なお、本明細書では、リクエストを送信するＬ４プロトコルとしてＴＣＰの利用を想定しているが、ＵＤＰを用いる場合は、ＴＣＰ／ＳＹＮパケットをＵＤＰパケットと読み替えてもよい。
【００４６】
説明を単純化するために、高優先クライアントからのＴＣＰ／ＳＹＮパケットは常にその受信を許可するものとする。一方で、低優先クライアントからのＴＣＰ／ＳＹＮパケットをレート制御の対象とする。また、パケットのレート制御のアルゴリズム例として、トークンバケット方式を用いて説明する。
【００４７】
トークンバケット方式では、パケット処理の実行に必要なトークンを一定容量のバケツに一定速度で追加していく。トークン数がバケツの容量を超える場合は、トークンの追加を見合わせる。ＩＰパケット受信時において、バケツの中にトークンが残っているならば、そのトークンを消費し、パケットの処理を起動する。一方で、バケツの中にトークンが空である場合は、当該パケットを廃棄する。トークンの追加速度とバケツの容量とを調整することにより、適切にパケットのレートを制限できる。
【００４８】
図４は、本発明に基づきレート制限する場合の実行手順を示している。図４は、本サーバがＩＰパケットをネットワークから受信した際の、ＴＣＰ／ＩＰ処理の前処理として実行される。まず、ＩＰパケットを受け取ると、当該パケットがＴＣＰ／ＳＹＮパケットであるか否かを検査する。ＴＣＰ／ＳＹＮパケットである場合は、そのままＴＣＰ／ＩＰ処理を継続する。
【００４９】
次に、当該ＩＰパケットの送信元ＩＰアドレスが、優先アドレス表に登録されているか否かを判定する。優先アドレス表に登録されている場合は、そのままＴＣＰ／ＩＰ処理を継続する。
【００５０】
次に、当該ＩＰパケットを処理するためのトークンが残っているか否かを判定する。残りトークンがある場合は、トークンを一つ消費し、そのままＴＣＰ／ＩＰ処理を継続する。一方で、残っているトークンがない場合は、ＴＣＰ／ＳＹＮパケットのレートがＦを上回っているとみなし、廃棄フラグをセットさせた後、当該ＩＰパケットを廃棄する。
【００５１】
次に、バケツに対しトークンの追加を行う処理部（トークン追加処理部）の実行手順を図５に示す。トークン追加処理部は、当該サーバが起動されると同時に起動され、サーバの動作終了までトークン追加処理を繰り返す。トークンの追加処理は時間Ｄ毎に実施すると仮定し、時間Ｄが経過するまで、実行待ち合わせる。次に、Ｆの更新が必要か否かを判定する。Ｆは一定時間間隔毎に更新してもよく、また受信したパケットが一定数を超えるたびにＦを更新してもよい。
【００５２】
Ｆの更新が必要な場合は、まず、サーバが過負荷であるか否かを判定する。すなわち、ＣＰＵ負荷Ｕ、メモリ使用量Ｍ、ＴＣＰコネクション数Ｃのうち測定対象とするリソースにおいて、それぞれの閾値ＬＵ、ＬＭ、ＬＣを超えているか判定する。次に、閾値を超えている場合は、サーバ負荷を軽減するため、ＦをΔＦ減少させる。一方で、閾値を超えていない場合は、次に、現在のＦによる制限が強過ぎないか否かを判定する。
【００５３】
すなわち、過負荷でないにもかかわらずＴＣＰ／ＳＹＮパケットの廃棄が行われている場合は、レート制限が強過ぎることを意味している。したがって、廃棄フラグが真である場合は、ＦをΔＦ上昇させ、レート制限を緩和させる。最後に廃棄フラグをリセットする。
【００５４】
Ｆの更新が必要ない場合、またはＦの更新が完了すると、次にトークンをバケツに追加する。このときの追加されるトークン数はＦ×Ｄである。このとき、トークン数がバケツの容量を超えないようにする。
【００５５】
なお、ＴＣＰ／ＳＹＮパケットのレート制御は、サーバではなくサーバ前段に接続されたネットワーク装置（ルータ、Ｌ２スイッチ、Ｆｉｒｅｗａｌｌ、負荷分散装置）などで実施してもよい。この場合は、優先すべきＩＰアドレスと、サーバのＣＰＵ負荷をネットワーク装置に送信する。そしてネットワーク装置にて、図４および図５の実行手順に基づきＴＣＰ／ＳＹＮパケットのレート制御を行う。
【００５６】
（第二実施例）
第一実施例では、過負荷時に新規確立されるＴＣＰコネクションのレートを制限することで、サーバの負荷の低減を図っていた。しかし、過負荷時に個々のＴＣＰコネクションのリクエストレートを制御することで、サーバの負荷を減少させることができる。
【００５７】
ＴＣＰの受信側のバッファ溢れを回避するための機能として、Ｗｉｎｄｏｗサイズに基づくフロー制御がある。フロー制御では、応答メッセージであるＡＣＫを返送する際に、受信用バッファの残りバイト数をＷｉｎｄｏｗサイズとして、送信側に通知する。送信側では、通知されたＷｉｎｄｏｗサイズより大きいデータを送信しないようにする。したがって、サーバのＷｉｎｄｏｗサイズが小さくなればなるほど、クライアントから送信されるデータ量（すなわち、リクエスト量）が小さくなる。
【００５８】
本実施例では、過負荷時にＷｉｎｄｏｗサイズがより小さくなるように制御する。このとき、低優先クライアントと接続されたコネクションを優先的に規制してもよい。本明細書では説明の単純化のため、高優先クライアントと接続されたコネクションのＷｉｎｄｏｗサイズ制御は行わないとする。ＴＣＰ処理におけるＷｉｎｄｏｗサイズをｗとする。これに係数ｋ（０≦ｋ≦１）を用いると、ＡＣＫパケットによってクライアントに通知されるＷｉｎｄｏｗサイズｗは、以下の式によって表されるとする。
【００５９】
Ｗ＝ｗ    …高優先クライアントと接続されたコネクション
Ｗ＝ｋｗ  …低優先クライアントと接続されたコネクション
ここで、ｋは図６に示される実行手順に基づき、定期的に更新される。まず、所定時間の間、更新を待ち合わせる。次に過負荷が生じているか否かを判定する。すなわち、ＣＰＵ負荷Ｕ、メモリ使用量Ｍ、ＴＣＰコネクション数Ｃのうち測定対象とするリソースにおいて、それぞれの閾値ＬＵ、ＬＭ、ＬＣを超えているか判定する。過負荷が生じている場合は、ｋの値をΔｋ減少させ、より小さなＷｉｎｄｏｗサイズがクライアントに通知されるようにする。
【００６０】
このとき、ｋの値が小さくなり過ぎると、サイズが小さいパケットによってデータが送信されるようになり、サーバの効率が低下する。故に、ｋの下限ＫMINを下回った場合はｋを０とし、優先度が低いクライアントからサーバにリクエストが流れないようにする。
【００６１】
一方で、過負荷が生じていない場合は、ｋの値をΔｋ増加させ、より多くのリクエストが送信されるようにする。まずｋの値が０であるかを確認する。ｋが０の場合は、クライアントからサーバへのリクエスト送信が停止している状態である。故に、Ｗｉｎｄｏｗサイズが回復したことを示すＡＣＫメッセージを、優先度が低いクライアントに送信する。次に、ｋの値を増加させる。このときｋが１を超えないようにする。
【００６２】
図６では、低優先コネクションのＷｉｎｄｏｗサイズを一律で小さくしていた。しかしながら、コネクション毎にｋを設定できるようにし、非優先コネクションの一部のリクエスト送信を停止させることもできる。図７にその実行手順を示す。まず、所定時間の間、更新を待ち合わせる。次に過負荷が生じているか否か判定する。すなわち、ＣＰＵ負荷Ｕ、メモリ使用量Ｍ、ＴＣＰコネクション数Ｃのうち測定対象とするリソースにおいて、それぞれの閾値ＬＵ、ＬＭ、ＬＣを超えているか判定する。
【００６３】
過負荷が生じている場合は、ｋ＞０である低優先コネクションから、リクエスト送信を停止させるコネクションを選択する。ここで、選択されるコネクション数は複数であってもよい。また、コネクションは、ランダムに選んでもよく、また、リクエスト・レスポンスの送受信に使用されていない期間が最も長いコネクション、または、最も新しく接続されたコネクション、などから選んでもよい。次に選択したコネクションのｋを０とする。これにより、選択されたコネクションからのリクエスト送信を停止させ、サーバの負荷を測る。
【００６４】
一方で、過負荷が生じていない場合は、リクエスト送信を停止させていたコネクション、すなわちｋ＝０のコネクションから、リクエスト送信を再開するコネクションを選択する。ここで、一度に選択されるコネクション数は複数であってもよい。また、コネクションは、ランダムに選んでもよく、また、最も長くリクエスト送信が停止されていたコネクション、などを選んでもよい。次に、選択したコネクションのｋを１とし、Ｗｉｎｄｏｗサイズが回復したことを示すＡＣＫメッセージを、クライアントに送信する。
【００６５】
なお、ＴＣＰ／ＳＹＮレート制御と、Ｗｉｎｄｏｗサイズ制御とを併用することもできる。この場合は、例えば、まずＴＣＰ／ＳＹＮレート制御を実施する。そして、Ｆの値が十分小さくなっても、過負荷が解消されない場合は、Ｗｉｎｄｏｗサイズ制御を用いて、すでに確立されているコネクションのリクエストレートを減少させる、といった手法がとれる。
【００６６】
図７では、Ｗｉｎｄｏｗサイズの変更によってパケット受信を停止させているが、選択したコネクションを切断することによって、パケット受信を停止させてもよい。この場合は、サーバが過負荷となっていない場合の処理は不要である。
【００６７】
（第三実施例）
第三実施例として、同時接続ＴＣＰコネクション数Ｃに注目した、過負荷回避方法について述べる。本実施例では、同時接続ＴＣＰコネクション数Ｃが過負荷となっている場合には、ＴＣＰコネクションの接続確立処理（例えばＣ言語におけるａｃｃｅｐｔ（））において、優先アドレス表に登録されているクライアントからのコネクションを優先的に確立する。
【００６８】
図８に本実施例によるＴＣＰコネクション接続処理の実行手順を示す。本処理は新規ＴＣＰコネクションを確立された際に呼び出されるものとする。まず、新規ＴＣＰコネクションの確立によって、同時接続ＴＣＰコネクション数Ｃがその閾値ＬＣを超えるか否かを判定する。閾値を超えていない場合は、当該処理を終了させる。閾値を超えている場合は、次に新しく確立したＴＣＰコネクションの送信元のクライアントのＩＰアドレスが、優先アドレス表に登録されているか否かを検査する。優先アドレス表に登録されていない場合は、新規確立されたＴＣＰコネクションを切断し、当該処理を終了する。
【００６９】
優先アドレス表に登録されている場合は、新規に確立されたＴＣＰコネクションは優先して維持すべきであることを意味する。故に、まず優先アドレス表に登録されていないクライアントと接続されたＴＣＰコネクションが存在するか否かを検査する。存在する場合は、優先アドレス表に登録されていないクライアントと接続されたＴＣＰコネクションの中から一つのコネクションを選択して切断する。切断するコネクションはランダムに選んでもよく、また、リクエスト・レスポンスの送受信に使用されていない期間が最も長いコネクション、最も新しく接続されたコネクション、などを選んでもよい。一方で、存在しない場合は、新規コネクションを切断する。
【産業上の利用可能性】
【００７０】
本発明に基づくことにより、サービスの途中でリクエストが廃棄され中断されることがなくなり、サーバの処理能力を向上させることができる。
【図面の簡単な説明】
【００７１】
【図１】本実施例の負荷制御システムのブロック構成図。
【図２】本実施例のサーバのブロック構成図。
【図３】本実施例の高優先アドレス表の一例を示す図。
【図４】本実施例のＩＰパケットの受信処理手順を示すフローチャート。
【図５】本実施例のトークン追加処理の実行手順を示すフローチャート。
【図６】本実施例のＷｉｎｄｏｗサイズ制御の実施例（一律規制）を示すフローチャート。
【図７】本実施例のＷｉｎｄｏｗサイズ制御の実施例（選択規制）を示すフローチャート。
【図８】本実施例の新規ＴＣＰコネクション確立時のコネクション選択処理手順を示すフローチャート。
【符号の説明】
【００７２】
１−１〜１−ｎ  クライアント
２  ネットワーク
３  負荷制御機能付サーバ
１０  アプリケーション部
１１  リクエスト優先制御部
１２  負荷制御機能付ＴＣＰ／ＩＰ処理部
１３  優先度予測部
【図１】
2008059040.tif 000003
【図２】
2008059040.tif 000004
【図３】
2008059040.tif 000005
【図４】
2008059040.tif 000006
【図５】
2008059040.tif 000007
【図６】
2008059040.tif 000008
【図７】
2008059040.tif 000009
【図８】
2008059040.tif 000010