JP2009246892A - サーバ輻輳制御方法およびシステム - Google Patents

Abstract

【課題】各ユーザ端末から受付サーバへの個々の発信を厳密に解析することなく、受付サーバの輻輳を適正に制御できるサーバ輻輳制御方法およびシステムを提供する。
【解決手段】収集サーバ３は、ステップＳ４１で受信したサービス時間TserviceをステップＳ４２で蓄積する。ステップＳ４３で所定の集計期間tが完了したと判定されるとステップＳ４４へ進み、今回の集計期間tのサービス時間Tserviceに基づいてサーバ負荷代表値Tが算出される。ステップＳ４５では、サーバ負荷代表値Tに基づいてサーバ輻輳中であるか否かが判定される。平常時であればステップＳ４６へ進み、今回のサーバ負荷代表値Tを正常時サンプルとしてデータベースが更新される。サーバ輻輳中と判定されればステップＳ４８へ進み、今回のサーバ負荷代表値Tを輻輳時サンプルとしてデータベースが更新される。ステップＳ４７では、前記サーバ輻輳中か否かの判定結果が制御サーバ４へ通知される。
【選択図】図４

Description

本発明は、ユーザ端末から受付サーバへの発信を規制してサーバの輻輳を制御するサーバ輻輳制御方法およびシステムに係り、特に、各ユーザ端末から発信されたサービス要求の処理に受付サーバが要したサービス時間を計測し、このサービス時間をサーバの負荷と見なしてサーバの輻輳を制御するサーバ輻輳制御方法およびシステムに関する。

通信回線としてインターネットが普及し、TV番組やラジオ番組でヒットチャートを発表した直後に人気曲の配信を要求するダウンロードのリクエストや、視聴者参加番組において視聴者が自身のメッセージを投稿するアップロードのリクエストなど、特定のイベントを契機とするリクエストメッセージは短時間に集中する傾向がある。しかしながら、これらの宛先でリクエストを受け付けるサーバでは、リクエスト数が急増すると輻輳負荷状態が急激に悪化し、最悪の場合にはサーバの運用停止に追い込まれてしまう。

このような技術課題に対して、コンテンツ配信や投稿のリクエストを受け付ける本サーバ（受付サーバ）とは別に、リクエストの受付専用にアクセスパスサーバを設け、このアクセスパスサーバが、リクエストに応答して本サーバへのアクセス順序やアクセスタイミングを決定すると共に、これをアクセスパスとして各ユーザ端末へ通知し、各ユーザ端末では、このアクセスパスにしたがって本サーバへアクセスする技術が開示されている。

一方、上記した従来技術では、本サーバの能力限界までリクエストを受け付ければ効率の良い処理が可能になるものの、サーバの余剰能力を正確に見極めることは難しいので、本サーバは能力限界を下回る状態で運用されていた。

このような技術課題に対して、特許文献１には、本サーバの容量を超過するアクセスが集中発生する際、全部または一部のユーザ端末からのアクセスを当該ユーザ端末側で一旦保留し、その後、放送波などを用いてユーザ端末へ制御情報を送信し、アクセスが本サーバの容量以下となるよう保留を解除することにより、本サーバのシステム容量を超過するようなアクセス集中を防ぐ順次受付型の発信規制技術が開示されている。
特開２００７−４８８０８号

上記した従来技術では、受付サーバの負荷が主にユーザ端末から受付サーバへの発信数に基づいて判定され、ユーザ端末からの発信数が増すほどサーバの負荷も増すものとして発信規制が行われる。しかしながら、受付サーバの負荷はユーザ端末からの発信数のみならず、ユーザ端末から発信されたサービス要求の処理に受付サーバが要した時間やデータ転送に要した時間（以下、合わせてサービス時間と表現する）にも依存する。

例えば、ユーザ端末から受付サーバへ発信されたサービス要求がコンテンツのダウンロードであると、コンテンツのデータサイズが大きいほど、受付サーバではダウンロード時間、すなわち処理時間が長くなって負荷が大きくなる。しかしながら、従来技術ではサーバ負荷が発信数に基づいて求められていたので、コンテンツのデータサイズ（ダウンロード時間）を考慮することなくサーバ負荷が見積もられてしまう。

また、コンテンツのデータサイズが同一であっても、これを要求するユーザ端末が光ファイバーによるブロードバンド回線のような高速網に接続されている場合と、携帯電話網のような低速網に接続されている場合とではサーバ負荷が大きく異なる。具体的には、低速網経由の配信では高速網経由の配信よりも配信時間が長くなるので、受付サーバでも、その処理時間が長くなって負荷が大きくなる。したがって、低速網経由の発信については負荷が小さく見積もられてしまう。

このように、受付サーバの負荷は、ユーザ端末が接続されている網や送受信データのサイズ、さらにはサーバアクセスが与える処理負荷やアクセス回線の速度等にも依存する。しかしながら、上記した従来技術では、受付サーバへの発信数のみに基づいてサーバ輻輳が判定されていたので、受付サーバの輻輳を正確に検知することが難しかった。

一方、上記した技術課題は、各ユーザ端末から受付サーバへの発信を全てタップして厳密に解析し、各ユーザ端末の接続網の速度、送受信するデータサイズ、アクセス回線の速度等を見極めれば解決できるものの、全ての発信やアクセス回線の詳細を厳密に解析することは実質的に不可能である。

本発明の目的は、上記した従来技術の課題を解決し、各ユーザ端末から受付サーバへの個々の発信を厳密に解析することなく、受付サーバの輻輳を適正に制御できるサーバ輻輳制御方法およびシステムを提供することにある。

上記した目的を達成するために、本発明は、ユーザ端末から受付サーバへの発信を規制して当該受付サーバの輻輳を制御するサーバ輻輳制御システムにおいて、以下のような手段を講じた点に特徴がある。

(1)各ユーザ端末から発信されたサービス要求の処理に前記受付サーバが要したサービス時間を計測する手段と、所定の期間内に計測されたサービス時間を集計して、当該期間内のサーバ負荷を代表するサーバ負荷代表値を算出する手段と、前記サーバ負荷代表値を、前記受付サーバが輻輳していない平常時におけるサーバ負荷と比較して当該受付サーバが輻輳中であるか否かを判定する手段と、前記受付サーバが輻輳中と判定されると、各ユーザ端末から受付サーバへの発信を規制する手段とを含むことを特徴とする。

(2)受付サーバが輻輳中ではないと判定された際のサーバ負荷代表値を平常時におけるサーバ負荷に反映させて当該平常時におけるサーバ負荷を更新する手段を含む。

本発明によれば、以下のような効果が達成される。
(1)各ユーザ端末から受付サーバへの個々の発信を厳密に解析することなく、各ユーザ端末から発信されたサービス要求の処理に受付サーバが要したサービス時間を計測するだけで、受付サーバの輻輳状態を正確に判定できるようになり、その結果、受付サーバに輻輳を生じさせることなく、かつ受付サーバの能力を最大限に生かした発信規制が可能になる。
(2)受付サーバが輻輳していないと判定された際のサーバ負荷代表値に基づいて、平常時におけるサーバ負荷の指標が更新されるようにしたので、受付サーバが輻輳中であるか否かを常に正確に判定できるようになる。

以下、図面を参照して本発明の最良の実施形態について説明する。図１は、本発明に係るサーバ輻輳制御方法が適用されるネットワークの構成を示したブロック図である。

ユーザ端末１は、投稿などのアップロードあるいはコンテンツ配信などのダウンロードを要求するメッセージ（要求メッセージ）を受付サーバ２へ発信し、受付サーバ２が当該要求の処理に要する時間（サービス時間）を計測する。収集サーバ３は、各ユーザ端末１で計測されたサービス時間を集計すると共に、この集計結果に基づいて受付サーバ２の輻輳状態を判定し、この判定結果を制御サーバ４へ通知する。

制御サーバ４は、収集サーバ３から通知された輻輳判定結果を参照し、受付サーバ２が輻輳中であれば各ユーザ端末１の発信を一時的に規制し、その後、受付サーバ２が輻輳しないように、各ユーザ端末１の発信規制を発生順に解除する。受付サーバ２は、ユーザ端末１からアップロードされたメッセージやファイルを自身のデータベースに蓄積し、あるいはダウンロードするコンテンツをデータベースから取り込んで要求元のユーザ端末１へ配信する。

図２は、前記制御サーバ４による発信規制の実行方法および解除方法の概念を模式的に表現した図であり、ここでは、ユーザ端末１からの総発信数Nが、受付サーバ２において輻輳が生じていると判断できる上限値Nmaxを超えないように、各ユーザ端末１からの発信を規制する場合について説明する。

単位期間T1に発生した発信数N1は上限値Nmax以下なので、当該N1回の発信については、直ぐに発信規制を解除されて次の単位期間T2で発信される。これに対して、単位期間T2では上限値Nmaxを上回るN2回の発信が発生しているので、そのうちN2(1)回分の発信については、次の単位期間T3で規制解除されて発信されるものの、残りのN2(2)回分の発信については、単位期間T4まで発信を規制され続ける。

さらに、単位期間T3でも上限値Nmaxを上回るN3回の発信が発生しているので、そのうち上限値Nmax−N2(2)回分に相当するN3(1)回の発信は単位期間T4で規制解除されて発信されるものの、残りのN3(2)回分の発信は単位期間T5を待って規制解除される。なお、このような発信規制方法は、本発明の発明者等による特許出願（特願２００７−４８８０８号）に開示されている。

次いで、フローチャートを参照して本発明のサーバ輻輳制御方法について詳細に説明する。図３は、前記ユーザ端末１の動作を示したフローチャートであり、図４は、前記収集サーバ３の動作を示したフローチャートであり、図５は、前記制御サーバ４の動作を示したフローチャートである。ここでは、ユーザ端末１が受付サーバ２に発信してコンテンツをダウンロードする場合を例にして説明する。

ユーザ端末１では、図３のステップＳ１において、ユーザによるコンテンツのダウンロード(DL)要求が検知されると、ステップＳ２では、自端末が発信規制中であるか否かが判定される。発信規制中でなければステップＳ５へ進み、受付サーバ２への発信が直ちに行われる。

これに対して、前記ステップＳ２で発信規制中と判定されると、発信を一時保留してステップＳ３へ進み、制御サーバ４からの制御情報の受信に備えて待機する。その後、規制解除の制御情報が受信されるとステップＳ４へ進み、現在保留中の発信が規制解除対象であるか否かが判定される。規制解除の対象であればステップＳ５へ進み、前記受付サーバ２への発信が行われる。

ステップＳ６では、受付サーバ２へダウンロード要求のメッセージが送信され、これと同時に、ステップＳ７では、受付サーバ２が当該要求の処理に要する時間を計測するタイマがスタートする。ステップＳ８では、受付サーバ２からの応答を待ってダウンロードが開始される。ステップＳ９では、ダウンロードが完了したか否かが判定され、完了するとステップＳ１０へ進む。ステップＳ１０では、前記タイマの計測値が、ダウンロード時間を含む今回のサービス時間Tserviceとして求められる。ステップＳ１１では、前記サービス時間Tserviceが、受付サーバ２の現在の負荷を代表する定量値として収集サーバ３へ通知される。ステップＳ１２では、所定の終了処理が実行される。

収集サーバ３では、図４のステップＳ４１において、前記サービス時間Tserviceの通知を収集サーバ３から受信すると、ステップＳ４２でこれを一時的に蓄積する。ステップＳ４３では、所定の集計期間（タイムウインドウ）tが完了したか否かが判定され、完了していなければステップＳ４１へ戻り、他のユーザ端末１から通知されるサービス時間Tserviceの収集および蓄積が継続される。

集計期間tが完了するとステップＳ４４へ進み、今回の集計期間tのサービス時間Tserviceに基づいて、当該期間t内の受付サーバ２の負荷を代表するサーバ負荷代表値Tが算出される。本実施形態では、当該集計期間t内に収集された全てのサービス時間Tserviceの平均値がサーバ負荷代表値Tとされる。ステップＳ４５では、当該サーバ負荷代表値Tに基づいて、前記受付サーバ２が輻輳中であるか否かが判定される。

すなわち、前記サービス時間Tserviceは、ユーザ端末１からの個々の要求を処理するため受付サーバ２が要した時間なので、前記サーバ負荷代表値Tは、集計期間t内に受付サーバ２にアクセスした各ユーザ端末からの個々の要求を処理するために受付サーバ２が要した平均時間となる。

ここで、受付サーバ２へのアクセス数が増加したり、あるいは各要求の処理に要する時間が長くなれば、受付サーバ２の処理負荷が増加して各ユーザ端末１へのサービス時間Tserviceが長くなる。また、集計期間t内に受付サーバ２へアクセスするユーザ端末数が十分に多ければ、大数の法則により、各要求の内容（例えば、ダウンロードするコンテンツのサイズ）や通信網の速度にかかわらず、前記サーバ負荷代表値Tで受付サーバ２の負荷を代表できる。

本実施形態では、図７に一例を示したように、サーバ負荷代表値Tが平常時のサービス時間Tserviceの平均値Taveのn倍値（n・Tave）と比較され、期間t2のようにT≦n・Taveであれば、平常時と判定されてステップＳ４６へ進む。ステップＳ４６では、今回のサーバ負荷代表値T（または、通知された全てのサービス時間Tservice）を正常時サンプルとしてデータベースが更新され、次回以降の平均値Taveの算出に用いられる。本実施形態では、当該集計期間t2内に収集された全てのサービス時間Tservice、あるいはサーバ負荷代表値Tを用いて、平常時のサービス時間の平均値Taveが算術平均値または移動平均値として更新される。

これに対して、期間t1のようにT＞n・Taveであれば、サーバ輻輳中と判定されてステップＳ４８へ進む。ステップＳ４８では、今回のサーバ負荷代表値T（または、通知された全てのサービス時間Tservice）を輻輳時サンプルとしてデータベースが更新される。このデータベースの更新方法は前記正常時と同様である。ステップＳ４７では、前記サーバ輻輳中か否かの判定結果が制御サーバ４へ通知される。

なお、サーバ負荷代表値Tに基づいてサーバ輻輳中であるか否かを判定する方法は上記に限定されず、図８に一例を示したように、平常時のサービス時間Tの標準偏差σのk倍値（k・σ）を求め、期間t2のようにサーバ負荷代表値TがTave＋k・σ以内であれば平常時と判定するようにしても良いし、あるいは図９に一例を示したように、予め閾値Trefを固定的に設定しておき、期間t2のようにサーバ負荷代表値Tが閾値Tref以下であれば平常時と判定するようにしても良い。

また、上記した実施形態では、集計期間t内のサーバ負荷代表値TやTaveが平均値として求められるものとして説明したが、本発明はこれのみに限定されるものではなく、単純移動平均値や指数平滑化移動平均値として求められるようにしても良い。さらに、サービス時間Tが輻輳と正常との境界部分にあるときに判定結果が頻繁に反転するのを防止するためにヒステリシスを設定しても良い。

制御サーバ４では、図５のステップＳ５１で前記輻輳判定結果の通知が受信されるとステップＳ５２へ進み、この通知結果に基づいて、受付サーバ２が輻輳中であるか否かが判定される。輻輳中と判定されればステップＳ５３へ進み、図６に一例を示したように、前記上限値Nmaxが下方修正される。

すなわち、当該期間中のアクセスに対するサービス時間Tが平常時のサービス時間よりも長いと言うことは、受付サーバ２が輻輳しているということであり、受付サーバ２の過負荷によりサービス時間Tが増大している可能性があるので、上限値Nmaxを引き下げて受付サーバ２へ到着するアクセス数を減じることで受付サーバ２の輻輳を回避する。

これに対して、正常時と判定されればステップＳ５４へ進み、より多くの発信を受け付けられるようにすべく、上限値Nmaxがその標準値Nmax(0)を限度に引き上げられる。すなわち、当該期間中のアクセスのサービス時間Tが平常時の平均値とほぼ同じであれば、受付サーバ２が正常に動作しており、過負荷によるサービス時間の増加などが発生していないと想定できるので、より多くのアクセスを処理できるように上限値Nmaxが引き上げられる。

なお、上記した実施形態では、ユーザ端末１がサービス時間Tserviceを自身で測定し、この測定結果を収集サーバ３へ報告するものとして説明したが、本発明はこれのみに限定されるものではなく、収集サーバ３がネットワーク上で同一コネクションのパケットを監視し、ユーザ端末１から受付サーバ２へ送信されたTCP SYNパケットが検知され、その後、受付サーバ２からユーザ端末１へ送信されるTCP FINパケットが検知されるまでの時間に基づいてサービス時間Tserviceを算出するようにしても良い。

あるいは、アプリケーションデータ部に明示的に記述されている内容（例えば、startおよびend）を収集サーバ３が監視し、「start」の記述されたデータが送信されてから「end」の記述されたデータが送信されるまでの時間に基づいてサービス時間Tserviceを算出するようにしても良い。

なお、ユーザ端末１のサービス時間を測定する方法としては、全てのユーザ端末のサービス時間を測定する必要はなく、事前に設定・通知した比率に基づきランダムに決定した一部のユーザ端末のサービス時間のみを測定することも可能である。これにより、データ収集による収集負荷を抑えられるようになる。サービス時間Tをユーザ端末１が通知する場合も同様に、一部のユーザ端末のみを測定対象とすることが可能になる。

さらに、上記した実施形態では、サービス時間Tserviceに基づいて受付サーバ２の輻輳状態が判定されるものとして説明したが、本発明はこれのみに限定されるものではなく、ユーザ端末１から受付サーバ２へ適宜のメッセージやコマンドを送信し、これに対して受付サーバ２から返信される応答メッセージや応答コマンドが受信されるまでの応答時間を計測し、この応答時間が前記サービス時間Tserviceと同様に平常時の範囲内であるか否かに基づいて受付サーバ２の輻輳状態を判定するようにしても良い。

さらに、上記した実施形態では、受付サーバ２からユーザ端末１へのダウンロード時のサービス時間Tに基づいて受付サーバ２の輻輳状態が判定されるものとして説明したが、ユーザ端末１から受付サーバ２へのアップロード時のサービス時間Tに基づいて受付サーバ２の輻輳状態が判定されるようにしても良い。

本発明に係るサーバ輻輳制御方法が適用されるネットワークのブロック図である。 発信規制の実行方法および解除方法の概念を模式的に表現した図である。 ユーザ端末の動作を示したフローチャートである。 収集サーバの動作を示したフローチャートである。 制御サーバの動作を示したフローチャートである。 受付サーバが受付可能な発信数の上限値Nmaxの制御方法を示した図である。 サービス時間に基づいてサーバ輻輳中か否かを判定する方法（その１）を示した図である。 サービス時間に基づいてサーバ輻輳中か否かを判定する方法（その２）を示した図である。 サービス時間に基づいてサーバ輻輳中か否かを判定する方法（その３）を示した図である。

符号の説明

１…ユーザ端末，２…受付サーバ，３…収集サーバ，４…制御サーバ

Claims (9)

1. ユーザ端末から受付サーバへの発信を規制して当該受付サーバの輻輳を制御するサーバ輻輳制御システムにおいて、
   各ユーザ端末から発信されたサービス要求の処理に前記受付サーバが要したサービス時間を計測する手段と、
   所定の期間内に計測されたサービス時間を集計して、当該期間内のサーバ負荷を代表するサーバ負荷代表値を算出する手段と、
   前記サーバ負荷代表値を、前記受付サーバが輻輳していない平常時におけるサーバ負荷と比較して当該受付サーバが輻輳中であるか否かを判定する手段と、
   前記受付サーバが輻輳中と判定されると、各ユーザ端末から受付サーバへの発信を規制する手段とを含むことを特徴とするサーバ輻輳制御システム。
2. 前記受付サーバが輻輳中ではないと判定された際のサーバ負荷代表値を前記平常時におけるサーバ負荷に反映させて当該平常時におけるサーバ負荷を更新する手段を含むことを特徴とする請求項１に記載のサーバ輻輳制御システム。
3. 前記サービス要求がダウンロード要求であり、
   前記計測手段は、サービス要求からダウンロード完了までをサービス時間として計測することを特徴とする請求項１または２に記載のサーバ輻輳制御システム。
4. 前記サービス要求がアップロード要求であり、
   前記計測手段は、サービス要求からアップロード完了までをサービス時間として計測することを特徴とする請求項１または２に記載のサーバ輻輳制御システム。
5. 前記サービス時間を計測する手段が、前記ユーザ端末に設けられたことを特徴とする請求項１ないし４のいずれかに記載のサーバ輻輳制御システム。
6. 前記サービス時間を計測する手段を備えた収集サーバを含むことを特徴とする請求項１ないし４のいずれかに記載のサーバ輻輳制御システム。
7. 前記サービス時間を計測する手段は、一部のユーザ端末から発信されたサービス要求の処理に前記受付サーバが要したサービス時間を計測することを特徴とする請求項１ないし６のいずれかに記載のサーバ輻輳制御システム。
8. 前記発信を規制する手段は、全ユーザ端末の少なくとも一部について、その発信を保留させ、前記受付サーバが輻輳しないように、前記保留させた発信を当該発信順で順次に解除することを特徴とする請求項１ないし７のいずれかに記載のサーバ輻輳制御システム。
9. ユーザ端末から受付サーバへの発信を規制して当該受付サーバの輻輳を制御するサーバ輻輳制御方法において、
   各ユーザ端末から発信されたサービス要求の処理に前記受付サーバが要したサービス時間を計測する手順と、
   所定の期間内に計測されたサービス時間を集計して、当該期間内のサーバ負荷を代表するサーバ負荷代表値を算出する手順と、
   前記サーバ負荷代表値を、前記受付サーバが輻輳していない平常時におけるサーバ負荷と比較して当該受付サーバが輻輳中であるか否かを判定する手順と、
   前記受付サーバが輻輳中と判定されると、各ユーザ端末から受付サーバへの発信を規制する手順とを含むことを特徴とするサーバ輻輳制御方法。

Images