JP4726067B2 - リクエスト優先受付方法およびシステム - Google Patents

Description

本発明は、ネットワーク経由で受信したリクエストを受け付けて処理し、受け付けられなかったリクエストに所定の優先受付条件を設定し、この優先受付条件を満足する再リクエストを優先的に受け付けるリクエスト優先受付方法およびシステムに関する。

災害発生時の安否確認のためのリクエスト、あるいはTV番組やラジオ番組でヒットチャートを発表した直後に人気曲の配信を要求するリクエストなど、特定のイベントを契機とするリクエストメッセージは短時間に集中する傾向がある。これらの宛先でリクエストを受け付けるサーバでは、リクエスト数が処理能力を超過すると、超過分についてはサービスの提供が不可能となる。このことは、同サービスを利用するユーザの満足度を低下させると共に、たとえばリクエストが有料コンテンツの配信であれば、コンテンツ提供者にとっては販売機会の損失となる。

イベントを契機とするアクセスの集中は通常のアクセス量を遙かに凌駕し、例えば10倍や100倍に達する場合もある。したがって、アクセス集中時のピーク時に合わせてサーバ容量を設計してしまうと、時間的に大半を占める通常時には大幅な過剰設備状態を招いてしまう。しかも、このようなアクセス集中は予測が難しいので、たとえ十分と予測される設備を用意できたとしても、その容量を上回るアクセスが集中する可能性を否定できない。

一方、２００３年１２月に東京・大阪・名古屋で地上デジタル放送が開始され、それ以後、他の地域でも放送が順次開始されると共に、移動体受信端末向けサービスなどが拡充されることになっている。地上デジタル放送で提供される通信放送連携サービスでは、番組内容を契機とした同時大量アクセスの発生が予見されており、上記で指摘した事象が今後ますます顕在化してくることが想定される。

特許文献１、２には、輻輳が生じるとTCPパケットやUDPパケットを破棄してトラヒックを減じることで輻輳を解消する技術が開示されており、この技術を転用すれば、リクエストメッセージが集中した際に、その一部を破棄することでトラヒック量を減じることができる。
特開２００２−３１４５９２号公報 特開２００３−２３４４３号公報

上記した従来技術はいずれも、リクエストのアクセスが集中してシステムに過剰な負荷が加わると、リクエスト（パケット）を破棄することで負荷の緩和が図られる。しかしながら、破棄されたリクエストは再送信されることになるので、これら再送信の集中によって再び過剰な負荷が発生してしまうという技術課題があった。

また、従来技術では最初のリクエストも再リクエストも同様に扱われてしまうので、短時間で受け付けられるリクエストがある一方で、長い保留時間を経ても受け付けられないリクエストが生じるなど、リクエストメッセージの受け付けに不公平感が生じるという技術課題もあった。

本発明の目的は、上記した従来技術の課題を解決し、アクセスの集中による過負荷等が原因で受付拒否されたリクエストメッセージの再アクセスを、新たなアクセス集中を生じさせることなく公平に受け付けて処理できるリクエスト優先受付方法およびシステムを提供することにある。

上記した目的を達成するために、本発明は、リクエストメッセージを受け付けて処理し、受け付けられなかったリクエストメッセージに所定の優先受付条件を設定し、当該優先受付条件を満足する再リクエストを優先的に受け付けるリクエスト優先受付システムにおいて、以下のような手段を講じた点に特徴がある。

(1)リクエストメッセージを受信して受け付けるリクエスト受信手段と、受け付けられたリクエストメッセージを処理するリクエスト処理手段と、前記リクエスト受付および／またはリクエスト処理の負荷を検知する負荷検知手段と、前記検知された負荷が所定の上限値を超えた状態でのリクエストメッセージの受け付けを拒否する受付拒否手段と、前記受付拒否したリクエストメッセージに所定の優先受付条件を設定する優先受付条件設定手段と、前記受付拒否したリクエストメッセージの送信元へ前記優先受付条件を通知する優先受付条件通知手段と、前記優先受付条件を満足するリクエストメッセージを優先的に受け付ける優先受付手段。

(2)受信したリクエストメッセージが優先対象であるか否かを判定する優先判定手段を含み、前記優先受付手段は、優先対象と判定されたリクエストメッセージのみを優先的に受け付けること。

(3)優先受付条件設定手段は、リクエストメッセージに設定した優先受付条件を当該リクエストメッセージの送信元IDと対応付けてデータベースに登録し、優先判定手段は、受信したリクエストメッセージの送信元IDと対応付けられた優先受付条件が満足されているリクエストメッセージを優先対象と判定することを特徴とする。

(4)リクエストメッセージに設定した優先受付条件に所定の関数計算を実行して確認識別子を生成する確認識別子生成手段をさらに具備し、前記優先受付条件通知手段は、前記確認識別子および優先受付条件をリクエストメッセージの送信元へ通知し、前記優先判定手段は、受信したリクエストメッセージの優先受付条件に前記関数計算を実行して求めた確認識別子と当該リクエストメッセージに登録されている確認識別子とを比較し、両者が一致したリクエストメッセージを優先対象と判定することを特徴とする。

(5)優先条件設定手段は、前記優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯を設定することを特徴とする。

(6)優先条件設定手段は、前記優先受付条件として、リクエストメッセージを優先的に受け付ける他のリクエスト受信手段のアドレスを設定することを特徴とする。

(7)優先条件設定手段は、前記優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯および他のリクエスト受信手段のアドレスを設定することを特徴とする。

本発明によれば、以下のような効果が達成される。
上記した特徴(1)によれば、受付拒否されたリクエストメッセージには優先受付条件が設定され、リクエストメッセージの再送信は前記優先受付条件が満足されるように行われる。したがって、優先受付条件をリクエストメッセージのアクセスが分散されるように設定すれば、再送信されるリクエストメッセージの集中を防止できる。そして、優先受付条件を満足するリクエストメッセージは優先的に受け付けられるので、リクエストメッセージの受付機会を公平化できる。

上記した特徴(2)によれば、受信されたリクエストメッセージが優先対象であるか否かが判定されるので、優先対象外のリクエストメッセージが誤って優先対象とされて優先的に受け付けられることを防止できる。

上記した特徴(3)によれば、リクエストメッセージの送信元IDと優先受付条件とが対応付けられて管理されるので、リクエストメッセージごとに異なる優先受付条件が設定されていても優先判定を容易に行えるようになる。

上記した特徴(4)によれば、リクエストメッセージの送信元IDと優先受付条件との対応関係を管理することなく、リクエストメッセージごとに異なる優先受付条件が設定されていても優先判定を容易に行えるようになる。

上記した特徴(5)によれば、優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯が設定されるので、リクエストメッセージの再送信を時間的に分散できるようになる。

上記した特徴(6)によれば、優先受付条件として、リクエストメッセージを優先的に受け付ける他のリクエスト受信手段のアドレスが設定されるので、リクエストメッセージの再送信を地理的に分散できるようになる。

上記した特徴(7)によれば、優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯および他のリクエスト受信手段のアドレスが設定されるので、リクエストメッセージの再送信を時間的および地理的に分散できるようになる。

以下、図面を参照して本発明の最良の実施の形態について詳細に説明する。 図１は、本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第１実施形態の構成を示した機能ブロック図である。

リクエスト受信部１は、ユーザ端末から送信されたリクエストメッセージを受信する。リクエスト受付部１０１は、受信されたリクエストメッセージを受け付けてリクエスト処理部２へ転送する。受付拒否部１０２は、負荷検知部３によりシステムの過負荷状態が検知されていると、受信されたリクエストメッセージの受け付けを拒否する。優先判定部１０３は、受信されたリクエストメッセージが優先対象であるか否か、さらには優先受付条件を満足しているか否かを判定する。優先受付部１０４は、優先対象であって、かつ優先受付条件を満足すると判定されたリクエストメッセージを、他のリクエストメッセージよりも優先的に受け付けてリクエスト処理部２へ転送する。

リクエスト処理部２は、前記リクエスト受信部１で正規に受け付けられたリクエストメッセージを処理し、例えば当該リクエストメッセージがコンテンツの配信要求であれば、コンテンツサーバ４からコンテンツを読み出して当該リクエストメッセージの送信元へ配信する。負荷検知部３は、前記リクエスト受信部１の負荷L1および／またはリクエスト処理部２の負荷L2を、例えばリクエスト受付部１０１で受付中のリクエスト数、優先受付部１０４で受付中のリクエスト数、あるいはリクエスト処理部２で処理中のリクエスト数等に基づいて検知し、総負荷Lが所定の上限値Lmaxを超えると、システムが過負荷状態にある旨を前記受付拒否部１０２へ通知する。

優先受付条件設定部５は、受付拒否したリクエストメッセージの再リクエストを後に優先的に受け付けるための優先受付条件を設定する。この優先受付条件としては、リクエストメッセージを優先的に受け付ける時間帯や、リクエストメッセージを優先的に受け付ける他のサーバのアドレスなどを設定できる。メッセージ送信部６は、前記優先受付条件の登録された案内メッセージを、前記受付拒否したリクエストメッセージの送信元（ユーザ端末）へ送信する。優先受付条件管理DB（データベース）７には、前記優先受付条件がリクエストメッセージの送信元IDと対応付けられて登録される。

図２は、本実施形態におけるリクエスト優先受付方法を示したフローチャートである。ステップS１において、ユーザ端末から送信されたリクエストメッセージがリクエスト受信部１で受信されると、ステップS２では、優先判定部１０３において、当該リクエストメッセージが優先対象であるか否かが判定される。本実施形態では、受信されたリクエストメッセージの送信元IDが優先受付条件管理DB７に登録されているか否かが判定され、未登録であれば、優先対象外の通常のリクエストメッセージと判定されてステップS３へ進む。

ステップS３では、前記負荷検知部３により検知されている現在の総負荷Lが、過負荷状態の指標となる上限値Lmaxと比較され、総負荷Lが上限値Lmaxを上回っていなければステップS７へ進む。ステップS７では、当該リクエストメッセージがリクエスト受付部１０１で受け付けられる。ステップS８では、受け付けられたリクエストメッセージがリクエスト処理部２へ転送されて適宜に処理される。

一方、前記ステップS３において、負荷Lが上限値Lmaxを上回っており、システムが過負荷の状態にあると判定されると、前記リクエストメッセージの受付が前記受付拒否部１０２で拒否されてステップS４へ進む。ステップS４では、現在の総負荷Lと他のリクエストメッセージに対して既に設定済みの優先受付条件等とに基づいて、当該リクエストメッセージに優先受付条件が設定される。本実施形態では、優先受付条件として再リクエストの優先受付時間帯が設定される。このとき、例えば時刻t1〜t2の時間帯が既に他の多くのリクエストメッセージの優先受付時間帯として割り当て済みであれば、次の時刻t2〜t3が優先受付時間帯として割り当てられる。

ステップS５では、前記設定された優先受付条件が、前記受付拒否されたリクエストメッセージの送信元IDと対応付けて優先受付条件管理DB７に登録される。ステップS６では、前記優先受付条件の登録された案内メッセージが、前記メッセージ送信部６からリクエストメッセージの送信元へ返信される。

その後、当該案内メッセージを受信したユーザが、指定された優先受付時間帯にリクエストメッセージを再送信し、これがステップS１で受信されると、ステップS２では、その送信元IDが優先受付条件管理サーバ７に既登録と判定されるのでステップS９へ進む。ステップS９では、送信元IDと対応付けられた優先受付時間帯が検知される。そして、現在時刻が当該優先受付時間帯でなければ、優先対象外と判定されてステップS１２へ進み、当該リクエストメッセージが破棄される。これに対して、現在時刻が当該優先受付時間帯であれば、優先受付条件を満足するリクエストメッセージと判定されてステップS１０へ進む。ステップS１０では、前記優先受付部１０４においてリクエストメッセージが優先的に受け付けられる。ステップS１１では、受け付けられたリクエストメッセージがリクエスト処理部２へ転送されて適宜に処理される。

本実施形態によれば、受付拒否されたリクエストメッセージには優先受付条件が設定され、この優先受付条件を満足するリクエストメッセージは優先的に受け付けられるので、再リクエストの集中による輻輳を防止できるのみならず、リクエストメッセージの受付機会を公平化できる。さらに、本実施形態では優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯が設定されるので、リクエストメッセージの再送信を時間的に分散できるようになる。

図３は、本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第２実施形態の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。

本実施形態では、上記した第１実施形態と較べて、優先受付条件管理DB７に代えて確認識別子生成部１０を設けた点に特徴がある。この確認識別子生成部１０は、受付拒否した各リクエストメッセージに対して前記優先受付条件部５で設定された優先受付条件（本実施形態では、優先受付時間帯）と、当該リクエストメッセージの送信元IDとをパラメータとする関数計算（例えば、ハッシュ計算）を実行し、その値（ハッシュ値）を優先受付条件の確認識別子として求める。メッセージ送信部６は、前記優先受付条件および確認識別子を含む案内メッセージを送信する。

図４は、本実施形態におけるリクエスト優先受付方法を示したフローチャートである。ステップS１において、ユーザ端末から送信されたリクエストメッセージがリクエスト受信部１で受信されると、ステップS２では、優先判定部１０３において、当該リクエストメッセージが優先対象であるか否かが判定される。本実施形態では、受信されたリクエストメッセージに前記確認識別子が登録されているか否かが判定され、未登録であれば、優先対象外の通常のリクエストメッセージと判定されてステップS３へ進む。

ステップS３では、前記負荷検知部３により検知されている現在の総負荷Lが上限値Lmaxと比較され、総負荷Lが上限値Lmaxを上回っていなければステップS７へ進む。ステップS７では、当該リクエストメッセージがリクエスト受付部１０１で受け付けられる。ステップS８では、受け付けられたリクエストメッセージがリクエスト処理部２へ転送される。

一方、前記ステップS３において、負荷Lが上限値Lmaxを上回っており、システムが過負荷の状態にあると判定されると、前記リクエストメッセージの受け付けが受付拒否部１０２で拒否されてステップS４へ進む。ステップS４では、優先受付条件として第１実施形態と同様に再リクエストの優先受付時間帯が設定される。ステップS５ａでは、受付拒否されたリクエストメッセージの送信元IDと前記設定された優先受付時間帯とをパラメータとするハッシュ計算が、前記確認識別子生成部１０で実行され、その計算結果（ハッシュ値）が優先受付条件の確認識別子として求められる。ステップS６では、前記優先受付条件および確認識別子の登録された案内メッセージが、前記メッセージ送信部６からリクエストメッセージの送信元へ返信される。

その後、当該案内メッセージを受信したユーザが、指定された優先受付時間帯に前記確認識別子を含むリクエストメッセージを再送信し、これがステップS１で受信されると、ステップS２では、確認識別子が既登録と判定されるのでステップS９ａへ進む。ステップＳ９ａでは、優先判定部１０３において、受信したリクエストメッセージの送信元IDと受信時間帯とをパラメータとする関数計算が同様に実行される。ステップS９ｂでは、この計算結果が前記リクエストメッセージに既登録の確認識別子と比較される。両者が一致すれば当該リクエストメッセージが優先対象と判定されるので、ステップS１０以降へ進んで優先的に受け付けられる。

本実施形態によれば、リクエストメッセージの送信元IDと優先受付条件とを対応付ける優先受付条件管理DB７が不要になるので、システムの構成を簡素化できる。

図５は、本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第３実施形態の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。

本実施形態では、前記リクエスト受信部１とアドレスの異なる第２のリクエスト受信部８および第２のリクエスト処理部９を設け、前記リクエスト受信部１に設けられていた優先判定部１０３および優先受付部１０４を第２のリクエスト受信部８に移設した点に特徴がある。

図６，７は、本実施形態におけるリクエスト優先受付方法を示したフローチャートであり、図６はリクエスト受信部１側の動作を示し、図７はリクエスト受信部８側の動作を示している。

図６のステップS１において、ユーザ端末から送信されたリクエストメッセージがリクエスト受信部１で受信されると、ステップS３では、前記負荷検知部３により検知されている総負荷Lが過負荷状態の指標となる上限値Lmaxと比較され、総負荷Lが上限値Lmaxを上回っていなければステップS７へ進む。ステップS７では、当該リクエストメッセージがリクエスト受付部１０１で受け付けられる。ステップS８では、受け付けられたリクエストメッセージがリクエスト処理部２へ転送される。

一方、前記ステップS３において、総負荷Lが上限値Lmaxを上回っており、システムが過負荷の状態にあると判定されるとステップS４へ進む。ステップS４では、優先受付条件としてリクエスト受信部８のアドレスが設定される。ステップS５では、リクエストメッセージの送信元IDが優先受付条件管理DB７に登録される。ステップS６では、前記優先受付条件（リクエスト受信部８のアドレス）の登録された案内メッセージが、メッセージ送信部６から前記リクエストメッセージの送信元へ返信される。

その後、当該案内メッセージを受信したユーザが、通知されたリクエスト受信部８の宛先にリクエストメッセージを再送信すると、図７のステップS３１において、このリクエストメッセージがリクエスト受信部８で受信される。ステップS３２では、優先判定部１０３において、受信されたリクエストメッセージの送信元IDが優先受付条件管理DB７に登録されているか否かに基づいて、当該リクエストメッセージが優先対象であるか否かが判定される。

未登録であれば優先対象外と判定されてステップS３５へ進み、当該リクエストメッセージが破棄される。これに対して、既登録であれば優先対象と判定されてステップS３３へ進み、前記優先受付部１０４においてリクエストメッセージが受け付けられる。ステップS３４では、当該リクエストメッセージがリクエスト処理部２へ転送されて適宜に処理される。

本実施形態によれば、優先受付条件として、リクエストメッセージを優先的に受け付ける他のリクエスト受信手段のアドレスが設定されるので、リクエストメッセージの再送信を地理的に分散できるようになる。

なお、優先受付用のリクエスト受信部８は１つに限定されるものではなく、図８に一例を示した第４実施形態のように、２つあるいはそれ以上設け、例えばシステムの過負荷状態が検知された当初はリクエスト受信部８(a)のアドレスを優先受付先とし、このリクエスト受信部８(a)での優先受付数が上限に達した以降はリクエスト受信部８(b)のアドレスを優先受付先とするようにしても良い。

さらに、上記した第３，第４実施形態では、優先受付条件としてリクエスト受信部８のアドレスを設定するものとして説明したが、本発明はこれのみに限定されるものではなく、第１実施形態をさらに適用し、リクエスト受信部８のアドレスと優先受付時間帯との組み合わせを優先受付条件として設定するようにしても良い。このようにすれば、リクエストメッセージの再送信を時間的および地理的に分散できるようになる。

本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第１実施形態の構成を示した機能ブロック図である。 第１実施形態におけるリクエスト受付方法を示したフローチャートである。 本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第２実施形態の構成を示した機能ブロック図である。 第２実施形態におけるリクエスト受付方法を示したフローチャートである。 本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第３実施形態の構成を示した機能ブロック図である。 第３実施形態におけるリクエスト受付方法（その１）を示したフローチャートである。 第３実施形態におけるリクエスト受付方法（その２）を示したフローチャートである。 本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第４実施形態の構成を示した機能ブロック図である。

符号の説明

１…リクエスト受信部，２…リクエスト処理部，３…負荷検知部，４…コンテンツサーバ，５…優先受付条件設定部，６…メッセージ送信部，７…優先受付条件管理DB，１０１…リクエスト受付部，１０２…受付拒否部，１０３…優先判定部，１０４…優先受付部

Claims (4)

1. 受信したリクエストメッセージを受け付けて処理し、受け付けられなかったリクエストメッセージに所定の優先受付条件を設定し、当該優先受付条件を満足する再リクエストを優先的に受け付けるリクエスト優先受付システムにおいて、
   リクエストメッセージを受信して受け付けるリクエスト受信手段と、
   受け付けられたリクエストメッセージを処理するリクエスト処理手段と、
   前記リクエスト受付および／またはリクエスト処理の負荷を検知する負荷検知手段と、
   前記検知された負荷が所定の上限値を超えた状態でのリクエストメッセージの受け付けを拒否する受付拒否手段と、
   前記受付拒否したリクエストメッセージに所定の優先受付条件を設定する優先受付条件設定手段と、
   前記優先受付条件およびリクエストメッセージの送信元IDをパラメータとする所定の関数計算を実行して確認識別子を生成する確認識別子生成手段と、
   前記受付拒否したリクエストメッセージの送信元へ前記優先受付条件および確認識別子を通知する優先受付条件通知手段と、
   受信したリクエストメッセージの優先受付条件およびその送信元IDをパラメータとする前記関数計算を実行して求めた確認識別子と当該リクエストメッセージに登録されている確認識別子とを比較し、両者が一致したリクエストメッセージを優先対象と判定する優先判定手段と、
   前記優先対象と判定されたリクエストメッセージを優先的に受け付ける優先受付手段とを含むことを特徴とするリクエスト優先受付システム。
2. 前記優先受付条件設定手段は、リクエストメッセージに設定した優先受付条件を当該リクエストメッセージの送信元IDと対応付けてデータベースに登録し、
   前記優先判定手段は、受信したリクエストメッセージの送信元IDと対応付けられた優先受付条件が満足されているリクエストメッセージを優先対象と判定することを特徴とする請求項１に記載のリクエスト優先受付システム。
3. 前記優先条件設定手段は、前記優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯を設定することを特徴とする請求項１または２に記載のリクエスト優先受付システム。
4. 受信したリクエストメッセージを受け付けて処理し、受け付けられなかったリクエストメッセージに所定の優先受付条件を設定し、当該優先受付条件を満足する再リクエストを優先的に受け付けるリクエスト優先受付方法において、
   リクエストメッセージを受信して受け付ける手順と、
   受け付けられたリクエストメッセージを処理する手順と、
   前記リクエスト受付および／またはリクエスト処理の負荷を検知する手順と、
   前記検知された負荷が所定の上限値を超えた状態でのリクエストメッセージの受け付けを拒否する手順と、
   前記受付拒否したリクエストメッセージに所定の優先受付条件を設定する手順と、
   前記優先受付条件およびリクエストメッセージの送信元IDをパラメータとする所定の関数計算を実行して確認識別子を生成する手順と、
   前記受付拒否したリクエストメッセージの送信元へ前記優先受付条件および確認識別子を通知する手順と、
   受信したリクエストメッセージの優先受付条件およびその送信元IDをパラメータとする前記関数計算を実行して求めた確認識別子と当該リクエストメッセージに登録されている確認識別子とを比較し、両者が一致したリクエストメッセージを優先対象と判定する手順と、
   優先対象と判定されたリクエストメッセージのみを優先的に受け付ける手順とを含むことを特徴とするリクエスト優先受付方法。

Images