(57)【要約】【課題】複数のプロキシサーバから成るアクセス中継装置において、アクセスログの管理オーバヘッドと、障害によるログ消失の危険性を低減し、更に、特定Ｗｅｂサーバへのアクセス集中によるサービス性能低下を防ぐ。【解決手段】複数のプロキシサーバ２３と、統計処理を行う管理サーバ２４と、これらからアクセス可能な共有ディスク２５から成り、各プロキシサーバは共有ディスク上にアクセスログを出力し、管理サーバは共有ディスクからアクセスログを読み出して統計処理を行う。また、その統計結果から特定Ｗｅｂサーバへのアクセス上限値を決定し、これを各プロキシサーバに通知してＷｅｂサーバへのアクセス数を制御する。【選択図】  図１
2004192170.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末から受信したコンテンツ取得要求に応じてサービスサーバにアクセスし、サービスサーバから取得したコンテンツを前記クライアント端末に送信するアクセス中継装置であって、
前記コンテンツ取得要求への応答機能を備えた複数のプロキシサーバと、
前記複数のプロキシサーバに接続された共有ディスク装置と、
前記複数のプロキシサーバの動作状態を監視する管理サーバと、からなり、
前記複数のプロキシサーバは、前記共有ディスク装置に対して、前記コンテンツ取得要求への応答に関わるアクセスログを出力し、
前記管理サーバは、前記共有ディスク装置に記録された、前記複数のプロキシサーバのアクセスログを読み込み、前記アクセスの統計処理を行うことを特徴とするアクセス中継装置。
【請求項２】
請求項１のアクセス中継装置において、
各々の前記プロキシサーバは、キャッシュメモリを備え、
前記管理サーバは、前記プロキシサーバが前記クライアントからのアクセス要求に応答する内容を前記キャッシュメモリに記憶していなかった場合の前記アクセスログについて、前記アクセスの統計処理を行うことを特徴とするアクセス中継装置。
【請求項３】
請求項２のアクセス中継装置において、
前記管理サーバは、複数の前記プロキシサーバ各々が出力する前記アクセスログのファイル名と、各々の前記アクセスログファイル内の、処理済アクセスログの数とを管理し、
記録された前記アクセスログファイルから、処理済アクセスログ数から判別できる未処理アクセスログを読み出し、前記アクセスの統計処理を行うことを特徴とするアクセス中継装置。
【請求項４】
請求項３のアクセス中継装置において、
前記管理サーバが行った前記アクセスの統計処理の結果に基づき、アクセス上限値を決定して、決定した前記アクセス上限値を各々の前記プロキシサーバに通知し、
各々の前記プロキシサーバは、アクセス数を、前記管理サーバから通知された前記アクセス上限値以下に制限することを特徴とするアクセス中継装置。
【請求項５】
請求項４のアクセス中継装置において、
前記管理サーバは、前記アクセス上限値は、前記サービスサーバの平均応答時間が所定の時間以下になるように、決定することを特徴とするアクセス中継装置。
【請求項６】
請求項５のアクセス中継装置において、
各々の前記プロキシサーバは、前記クライアント端末から、前記アクセス上限値を超えるアクセス要求があった場合に、前記クライアント端末にエラーを応答することを特徴とするアクセス中継装置。
【請求項７】
請求項６のアクセス中継装置において、
前記管理サーバは、前記アクセスの送信先となる前記サービスサーバと、前記アクセスの送信先となるＵＲＬとの各々について、前記アクセスの統計処理を行うことを特徴とするアクセス中継装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、サービス提供サーバへのアクセス中継装置に関し、更に詳しくは、アクセス中継装置が出力するアクセスログの管理方法に関する。
【０００２】
【従来の技術】
インターネットが急速に普及し、従来営業窓口で行われていたサービスがインターネットを介して提供され、また、映画などの動画サービスも提供されるようになってきている。通信技術も進歩し、家庭やオフィスからだけではなく、携帯電話などからも同サービスを享受できる環境が整ってきている。
【０００３】
クライアント端末からインターネットを経由したサービス提供サーバ（以下、Ｗｅｂサーバという）へのアクセスには、通信業者のプロキシサーバと呼ばれるアクセス中継装置を介して行うのが一般的である。アクセス中継装置では、クライアント端末からＷｅｂサーバへのアクセス数や嗜好調査ために、上記アクセスの内容を記録したアクセスログを収集しているのが普通である。
【０００４】
このような、複数のサービス提供サーバを備える環境におけるアクセスログの収集に関する技術は、例えば、非特許文献１に記載されている。
【０００５】
一方、通信業者のプロキシサーバでは、通常多数のユーザとＷｅｂサーバの通信を中継するため、１台のプロキシサーバではアクセスを処理しきれない。このため、例えば、１つのアクセス中継装置を負荷分散装置に接続された複数のプロキシサーバで構成し、利用者からのアクセス要求を複数のプロキシサーバに分散することにより、オーバフローを解消する方法が知られている。
【０００６】
【非特許文献１】
米国特許第６３１７７８７号明細書
【０００７】
【発明が解決しようとする課題】
上記非特許文献１に記載されている従来の負荷分散型のアクセス中継装置では、サーバそれぞれが、自らが備えるローカルディスク上にアクセスログを出力している。このため、アクセスログのバックアップや、アクセスログを使ってアクセスの統計処理を実施する場合、各プロキシサーバからアクセスログを個々に回収する必要があり、そのオーバヘッドが大きく、アクセスログの有効利用が難しい。
【０００８】
また、アクセスログを保存しているローカルディスクに障害が発生した場合に、アクセスログが消失してしまうという問題がある。
【０００９】
更に、一般的にプロキシサーバと統計処理を行うサーバの間に連携機能がなく、統計処理で得られた結果の有効利用がなされていない。
【００１０】
したがって、より改善されたアクセスログの管理方法や、活用方法が望まれている。
【００１１】
【課題を解決するための手段】
本発明は、複数のプロキシサーバからなるアクセス中継装置において、アクセスログの管理オーバヘッドを低減する技術、また、アクセスログの統計処理から得られる情報をプロキシサーバのアクセス制御に利用し、Ｗｅｂサーバへのアクセス集中によるサービス性能低下を防ぐ技術を提供する。
【００１２】
本発明のアクセス中継装置は、複数のプロキシサーバ各々がアクセスログを出力する共有のディスク装置を備える。したがって、共有ディスク装置のバックアップを行えば、全てのプロキシサーバが出力するアクセスログのバックアップが可能であり、バックアップのオーバヘッドを軽減できる。
【００１３】
更に、上記ディスク装置を共有する複数のプロキシサーバからなるプロキシクラスタを管理する管理サーバを備え、管理サーバがアクセスログの統計処理を行う。管理サーバは、共有ディスク装置上の各プロキシサーバのアクセスログを読み込むことができるため、各プロキシサーバからアクセスログを転送するオーバヘッドがなくなる。
【００１４】
更に、管理サーバが、統計処理から得られるＷｅｂサーバの応答時間に基づいて、Ｗｅｂサーバへのアクセス上限値を決定し、これをプロキシサーバに通知する。プロキシサーバはこの通知されたアクセス上限値に従って、単位時間あたりのアクセス数を制御することにより、Ｗｅｂサーバへのアクセス集中によるサービス性能低下を防ぐことができる。
【００１５】
更に、上述の通り、アクセスログの転送オーバヘッドが小さいので、上記統計処理とその結果のフィードバックを頻繁に行うことが出来るので、より適切なアクセス制御が可能になる。
【００１６】
【発明の実施の形態】
以下、本発明の実施例について図面を参照して説明する。
【００１７】
図１は、本実施例によるアクセス中継装置２を含む通信ネットワークシステムの構成を示している。
【００１８】
アクセス中継装置２は、ＬＡＮ又はインターネットなどの通信網１１を介して複数のクライアント端末１（１−１〜１−Ｌ）に接続され、インターネットなどのネットワーク（以下、インターネットという）１２を介してＷｅｂサーバ３（３−１〜３−Ｊ）に接続されている。
【００１９】
アクセス中継装置２は、通信網１１及びインターネット１２に接続されたパケット中継装置（ルータ）２１と、該パケット中継装置２１に接続された負荷分散装置２２と、該負荷分散装置２２に接続された複数のプロキシ（Ｐｒｏｘｙ）サーバ２３―ｎ（１≦ｎ≦Ｎ）と、該複数のプロキシサーバ２３との通信機能を持つ管理サーバ２４と、該複数のプロキシサーバ２３が出力するアクセスログを蓄積するために共有するディスク装置２５と、プロキシサーバ２３及び管理サーバ２４とディスク装置２５とを接続するＳＡＮ（Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ、高速ディスク通信網）２６とから成る。ディスク装置２５には、管理サーバ２４が生成する統計データも格納する。共有ディスク装置２５の詳細については、後述する。
【００２０】
クライアント端末１から送信されたコンテンツの取得要求は、パケット中継装置２１によって受信され、負荷分散装置２２に転送される。負荷分散装置２２は、パケット中継装置２１から受け取ったコンテンツ取得要求を所定の負荷分散アルゴリズムに従って上記プロキシサーバ２３−ｎに次々と振り分ける。
【００２１】
プロキシサーバ２３−ｎは、クライアント端末１から取得要求されたコンテンツが、プロキシサーバ２３−ｎ上のキャッシュメモリ中にあれば（ヒットすれば）、キャッシュしているコンテンツをクライアント端末１に送信する。キャッシュメモリ中に無かった場合は（ヒットしなければ）、プロキシサーバ２３−ｎは、振り分けられたコンテンツ取得要求を、コンテンツを提供する任意のＷｅｂサーバ３−Ｊに送信する。Ｗｅｂサーバ３−Ｊは、要求されたコンテンツを含む応答メッセージを生成し、該コンテンツ取得要求を中継したプロキシサーバ２３−ｎに送信する。該応答メッセージを受信したプロキシサーバ２３−ｎは、受信した応答メッセージをコンテンツ取得要求の発信元であるクライアント端末１に送信する。プロキシサーバ２３―ｎは、振り分けられたコンテンツ取得要求に対して、内部または外部に記憶しているキャッシュメモリの内容で応答できる場合は、その内容をコンテンツ取得要求の発信元であるクライアント端末１に送信する。
【００２２】
その後、プロキシサーバ２３−ｎは、通信記録であるアクセスログをディスク装置２５に出力する。
【００２３】
また、クライアント端末１−１〜１−Ｌから送信され、キャッシュメモリ中の内容で応答できないコンテンツの取得要求の数が、Ｗｅｂサーバ３への単位時間あたりのアクセス上限値を超えた場合のリクエストの流れは次のとおりとなる。
【００２４】
クライアント端末１から送信されたコンテンツの取得要求は、パケット中継装置２１、負荷分散装置２２を経てプロキシサーバ２３−ｎが受信する。プロキシサーバ２３−ｎは、処理中のコンテンツ取得要求の数がアクセス上限値を超えていた場合、受信したコンテンツ取得要求に対してエラーメッセージを作成し、これをコンテンツ取得要求の発信元であるクライアント端末１に送信する（プロキシサーバ２３−ｎは、コンテンツ取得要求をＷｅｂサーバ３−Ｊには送信しない）。
【００２５】
図２は、プロキシサーバ２３−ｎの構成を示す図である。
【００２６】
プロキシサーバ２３−ｎは、プロセッサ２３１と、負荷分散装置２２及び管理サーバ２４に接続するための通信インタフェース２３２と、ディスク装置２５に接続するためのディスク入出力インタフェース２３３と、プログラム格納用のメモリ２３４と、データ格納用のメモリ２３５から成り、これらの要素はバス等の内部通信線（以下、バスという）２３６によって相互に接続されている。メモリ２３４には、プロセッサ２３１が実行する制御用のソフトウェアとして、通信インタフェース２３２を介して他の装置と送信されるパケット（メッセージ）の送受信を制御するためのパケット転送制御モジュール４０と、要求処理モジュール４１と、その他の制御モジュール４２が格納されている。
【００２７】
図３は、管理サーバ２４の構成を示す図である。
【００２８】
管理サーバ２４は、プロキシサーバ２３−ｎと同様の構成により実現することが出来る。通信インタフェース２３２は、負荷分散装置２２とプロキシサーバ２３−ｎに接続するために使用される。メモリ２３４には、プロセッサ２３１が実行する制御用のソフトウェアとして、ディスク装置２５に格納されているアクセスログを読み出し、統計処理を行うアクセス統計処理モジュール４５と、統計処理結果からＷｅｂサーバ３−ｊへのアクセス上限値を決定するアクセス制限処理モジュール４６と、その他の制御モジュール４７が格納されている。
【００２９】
図４は、複数のプロキシサーバが共有するディスク装置２５上に蓄積されるアクセスログを格納するファイルのデータ構造を示す図である。
【００３０】
アクセスログを格納するアクセスログファイル５０は、該アクセスログファイル５０に関する情報を格納するアクセスログファイルヘッダ６０と、プロキシサーバ２３から出力されるアクセスログの実体であるアクセスログレコード６１−ｋ（１≦ｋ≦Ｋ）から成る。
【００３１】
アクセスログファイルヘッダ６０には、そのファイルに最初にアクセスログが書き込まれた日時を示すログ出力開始時刻６０１と、そのファイルにアクセスログが最後に書き込まれた日時を示すログ出力終了時刻６０２と、プロキシサーバがアクセスログの出力先を別のファイルに切り替えた場合に切り替え先を示す次のアクセスログファイル名６０３と、そのファイル内に格納されているアクセスログの数を示すアクセスログレコード数６０４とから成る。
【００３２】
このアクセスログファイル５０は、プロキシサーバ１台に付き１個のファイルが割り当てられる。したがって、プロキシサーバ２３−ｎに対して、ディスク装置２５上にはＮ個のアクセスログファイル５０−ｎ（１≦ｎ≦Ｎ）が存在する。
【００３３】
図５は、アクセスログの実体であり、セッション単位に作成されるアクセスログレコード６１−ｋの１つのレコードのデータ形式を示す図である。
【００３４】
アクセスログレコード６１−ｋには、そのレコードを出力したプロキシサーバを特定するためのプロキシサーバ番号６１０と、該プロキシサーバ上が受信したコンテンツ取得要求の受付番号であるセッション番号６１１と、Ｗｅｂサーバからの応答メッセージに付されているエラー状態を示すＨＴＴＰ応答コード６１２と、プロキシサーバ２３がクライアント端末１に応答するエラーコードを示すエラー番号６１３と、受信したコンテンツ取得要求の発信元を特定するためのクライアント端末アドレス６１４と、コンテンツ取得要求の送信先を示すリクエスト転送先（Ｗｅｂサーバ）アドレス６１５と、コンテンツ取得要求に記されているコンテンツ取得先を示すリクエストＵＲＬ６１６と、コンテンツ取得要求を発信したクライアント端末１に関する情報を示すクライアント端末情報６１７と、プロキシサーバ２３−ｎがクライアント端末１からのコンテンツ取得要求を受信した時刻を示すリクエスト受信時刻６１８と、プロキシサーバ２３−ｎがクライアント端末１に応答メッセージを送信し終わった時刻を示す応答メッセージ送信完了時刻６１９と、プロキシサーバ２３−ｎ内で処理に要した時間を示すプロキシサーバ処理時間６２０と、Ｗｅｂサーバ３−ｊにコンテンツ取得要求を送信してから該Ｗｅｂサーバ３−ｊから応答メッセージを受け取るまでの待ち時間を示すＷｅｂサーバ応答待ち時間６２１と、クライアント端末１から受信したコンテンツ取得要求のヘッダサイズ６２２と、クライアント端末１への応答メッセージのヘッダサイズ６２３と、クライアント端末１から受信したコンテンツ取得要求のデータサイズ６２４と、クライアント端末１への応答メッセージのデータサイズ６２５と、Ｗｅｂサーバ３−ｊに送信したコンテンツ取得要求のヘッダサイズ６２６と、Ｗｅｂサーバ３−ｊから受信した応答メッセージのヘッダサイズ６２７と、Ｗｅｂサーバ３−ｊに送信したコンテンツ取得要求のデータサイズ６２８と、Ｗｅｂサーバ３−ｊから受信した応答メッセージのデータサイズ６２９と、キャッシュ利用の有無を示すキャッシュフラグ６３０とから成る。
【００３５】
なお、本実施形態におけるセッションとは、アクセス元（本実施形態では、アクセス中継装置）が何らかのリクエストを発行し、アクセス先（本実施形態では、サービス提供サーバ）がそれに対して応答するまでの一回のやりとりを指す。
【００３６】
図６にプロキシサーバ２３−ｎのコンテンツ取得要求処理のフローチャートを示す。
【００３７】
プロキシサーバ２３−ｎがクライアント端末１からのコンテンツ取得要求を受信すると（Ｓ１００１）、該コンテンツ取得要求に誤りがないかチェックを行う（Ｓ１００２）。もし誤りがある場合は、クライアント端末１にエラーメッセージを送信する（Ｓ１０１０）。コンテンツ取得要求が正しい場合は、要求に対応する応答メッセージがプロキシサーバ２３−ｎ上のキャッシュに存在するかをチェックする（Ｓ１０１１）。キャッシュが存在する場合（キャッシュにヒット）は、これを取り出して応答メッセージを作成し（Ｓ１０１２）、クライアント端末１に送信する。キャッシュが存在しなかった場合は、クライアント端末からのコンテンツ取得要求を、コンテンツを提供するＷｅｂサーバ３−ｊに送信し（Ｓ１００３）、Ｗｅｂサーバ３−ｊから応答メッセージが返されるのを待つ（Ｓ１００４）。もし、Ｗｅｂサーバ３−ｊから応答メッセージが返されずにタイムアウトした場合（Ｓ１００９）、クライアント端末１にエラーメッセージを送信する（Ｓ１０１０）。Ｗｅｂサーバ３−ｊから応答メッセージを受信すると（１００４）、該応答メッセージに誤りがないかチェックを行う（Ｓ１００５）。もし誤りがある場合は、クライアント端末１にエラーメッセージを送信する（Ｓ１０１０）。応答メッセージが正しい場合は、これをクライアント端末１に送信する（Ｓ１００６）。クライアント端末に正常に応答メッセージを返した場合、エラーメッセージを返した場合に関わらず、プロキシサーバ２３−ｎは、その処理結果に応じて図５に示したアクセスログレコードを作成し（Ｓ１００７）、これをディスク装置２５内のアクセスログファイル５０に出力する（Ｓ１００８）。更に、アクセスログファイルヘッダ６０内にあるアクセスログレコード数６０４の値を更新する（Ｓ１００９）。
【００３８】
アクセスログの出力先であるディスク装置２５としては、例えば図１に示すように、２台のディスク２５２−１〜２５２−２と、ディスク制御装置２５１と、バックアップ装置２５３と、キャッシュメモリ２５４から成るものを使えばよい。図１に示す構成を備えたディスク制御装置２５１は外部からデータ入力があると、同一のそのデータをディスク２５２−１と２５２−２に、更にキャッシュメモリに書き込む。ディスク装置２５を図１のような構成にすることにより、１台のディスクに障害が発生しても、他方のディスクに同一内容のデータが保存されているため、アクセスログが消失することがない。ディスク装置２５１の構成は、図１に示す以外の構成を備えた装置であってもよい。
【００３９】
上記のように、プロキシサーバ２３−ｎが収集するアクセスログをディスク装置２５に蓄積することにより、プロキシサーバ２３−ｎの障害によるアクセスログ消失を防止すると同時にバックアップ収集が容易となる。また、プロキシサーバ２３−ｎにディスクを搭載する必要がなく、プロキシサーバ２３−ｎを小型に構成することが可能となり、省スペースでアクセス中継装置２を構成することが可能となる。
【００４０】
次に、管理サーバ２４の処理について説明する。
【００４１】
図７は、管理サーバ２４が生成するテーブルの一構成例である。
【００４２】
統計データテーブル７０は、アクセスログから得られる統計データを格納するテーブルである。該テーブル７０は、クライアント端末１−１〜１−Ｌが発信したコンテンツ取得要求の宛先を示すリクエストＵＲＬ７００と、該リクエストＵＲＬへの総アクセス数７０１と、該リクエストＵＲＬへアクセスした際のＷｅｂサーバ３−ｊからの応答時間の総計７０２と、平均応答時間７０３と、該リクエストＵＲＬへ送信した総リクエストデータサイズ７０４と、平均リクエストデータサイズ７０５と、Ｗｅｂサーバ３−ｊからの応答メッセージの総応答メッセージデータサイズ７０６と、平均応答メッセージデータサイズ７０７とから成る。
【００４３】
上記統計データテーブル７０は、ディスク装置２５上に格納されている。
【００４４】
また、アクセスログファイルテーブル７１は、アクセスログファイル５０―ｎを示すＮ個のエントリからなるテーブルであり、各エントリは参照対象であるアクセスログファイル名７１０と、該アクセスログファイル内において、管理サーバ２４が既に処理を終わったアクセスログの数を示す読込み済アクセスログ数７１１から成る。
【００４５】
アクセスログファイルテーブル７１にエントリするアクセスログファイル名の設定方法は、管理サーバ２４の初期設定ファイルに予め登録しておき、管理サーバ２４の初期化の際に、その初期設定ファイルの内容を読み込んで設定する方法でもよいし、プロキシサーバ２３−ｎが管理サーバ２４に通知する方法でもよい。
【００４６】
図８は、管理サーバ２４の統計処理の概要を示すフローチャートである。
【００４７】
例えば、管理サーバ２４は、まず、アクセスログファイルテーブル７１の最初にエントリされているアクセスログファイル名７１０を、参照先アクセスログファイル名とする（Ｓ１１０１）。次に、管理サーバ２４は、ディスク装置２５上にある参照先アクセスログファイル５０のアクセスログファイルヘッダ６０を読み込み（Ｓ１１０２）、次のアクセスログファイル６０３が設定されているか否かをチェックする（Ｓ１１０３）。次のアクセスログファイル６０３が設定されている場合に、アクセスログファイルテーブル７１上の現在参照しているエントリについて、アクセスログファイル名７１０をそのファイル名で置き換え、読込み済アクセスログ数７１１を０（ゼロ）に初期化する（Ｓ１１０４）。Ｓ１１０２〜Ｓ１１０４の操作により、参照先アクセスログファイルが切り替わる。
【００４８】
次に、読み込んだアクセスログファイルヘッダ６０内のアクセスログレコード数６０４とアクセスログファイルテーブル７１内の読込み済アクセスログ数７１１を比較する（Ｓ１１０５）。値が同一である場合は、当該参照先アクセスログファイルに含まれるＫ個のログファイルを全て処理したことになるので、参照先アクセスログファイルを切り替える処理（Ｓ１１１３）に移動する。読込み済アクセスログ数７１１よりアクセスログレコード数６０４の方が大きい場合は、アクセスログファイル５０内から読込み済アクセスログ数以降のまだ読み込んでいないアクセスログレコード６１−ｋ〜６１−Ｋを読み込み、たとえばデータメモリ２３５に記憶する（Ｓ１１０６）。
【００４９】
管理サーバ２４は、読み込んだアクセスログレコード全てについて、キャッシュフラグ６３０をチェックし、その内容がキャッシュ利用無しであった場合（Ｓ１１０７）、それぞれのアクセスログレコードについてＳ１１０８〜Ｓ１１１２までの処理を行う。
【００５０】
管理サーバ２４は、アクセスログレコード６１−ｋのリクエストＵＲＬ６１６を検索キーとして、統計データテーブル７０内のエントリを検索する（Ｓ１１０８）。その結果、アクセスログレコード６１−ｋ内のリクエストＵＲＬ６１６と統計データテーブル７０内のリクエストＵＲＬ７００とが一部（ＵＲＬ先頭文字から規定の範囲まで）、又は、全部が一致するエントリを発見した場合（Ｓ１１０９）は、統計データテーブル７０内の一致したエントリの内容をアクセスレコード６１−ｋの内容に基づいて変更する（Ｓ１１１０）。上記規定の範囲の設定や、一部または全部のどちらの方法で一致をチェックするかは、システム起動時のオプションで設定できるようにし、データメモリ２３５上に記憶すればよい。
【００５１】
具体的には、総アクセス数７０１に１を加え、応答メッセージ送信完了時刻６１９からリクエスト受信時刻６１８を引いた値を総応答時間７０２に加え、変更後の総応等時間７０２を変更後の総アクセス数７０１で割った値を平均応答時間７０３に設定し、Ｗｅｂサーバへのリクエストヘッダサイズ６２６とＷｅｂサーバへのリクエストデータサイズ６２８を総リクエストデータサイズ７０４に加え、変更後の総リクエストデータサイズ７０４を総アクセス数７０１で割った値を平均リクエストデータサイズ７０５に設定し、クライアント端末への応答ヘッダサイズ６２３とクライアント端末への応答データサイズ６２５を総応答メッセージデータサイズ７０６に加え、変更後の総応答メッセージデータサイズ７０６を総アクセス数７０１で割った値を平均応答メッセージサイズ７０７に設定する。
【００５２】
上記データサイズは、本実施例のアクセス抑制には直接使用しないが、管理サーバ２４の運用者が、サービスサーバへのトラフィックを監視して、たとえば、設備増強の目安とするために使用することが可能である。
【００５３】
Ｓ１１０９において一致するエントリが見つからなかった場合は、アクセスレコード６１−ｋの内容で統計データテーブル７０に新しいエントリを追加する（Ｓ１１１１）。具体的には、リクエストＵＲＬ６１６をリクエストＵＲＬ７００に設定し、総アクセス数に１を設定し、応答メッセージ送信完了時刻６１９からリクエスト受信時刻６１８を引いた値を総応答時間７０２に設定し、変更後の総応等時間７０２を変更後の総アクセス数７０１で割った値を平均応答時間７０３に設定し、Ｗｅｂサーバへのリクエストヘッダサイズ６２６とＷｅｂサーバへのリクエストデータサイズ６２８の合計値を総リクエストデータサイズ７０４に設定し、変更後の総リクエストデータサイズ７０４を総アクセス数７０１で割った値を平均リクエストデータサイズ７０５に設定し、クライアント端末への応答ヘッダサイズ６２３とクライアント端末への応答データサイズ６２５の合計値を総応答メッセージデータサイズ７０６に設定し、変更後の総応答メッセージデータサイズ７０６を総アクセス数７０１で割った値を平均応答メッセージサイズ７０７に設定する。
【００５４】
上記Ｓ１１１０、Ｓ１１１１の処理の後、読込み済アクセスログ数７１１の値をアクセスログレコード数６０４で置き換える（Ｓ１１１２）。
【００５５】
次に管理サーバ２４は、参照先アクセスログファイルの切り替えを行う。
【００５６】
管理サーバ２４は、現在参照しているアクセスログファイルがアクセスログファイルテーブル７１にエントリされている最後のファイルである場合は（Ｓ１１１３）、参照先アクセスログファイルをアクセスログファイルテーブル７１の最初にエントリされているアクセスログファイルに戻す（Ｓ１１１４）。そうでない場合は、アクセスログファイルテーブル７１内の現在参照しているエントリの次のエントリに記載されているアクセスログファイルに切り替える（Ｓ１１１５）。
【００５７】
この後、管理サーバ２４は、アクセスログファイルヘッダ６０を読み込む処理（Ｓ１１０２）に戻り、上記で説明した処理を繰り返す。
【００５８】
上記ステップで集計した結果に基づく処理については後述する。
【００５９】
上記実施例によれば、プロキシサーバ２３−ｎは管理サーバ２４からのアクセスログ読み込みに対して応える必要が無いので処理負荷を軽減できる。さらに、管理サーバ２４は、プロキシサーバ２３−ｎに処理負荷をかけないので短い間隔で（例えば、秒オーダ間隔で）、かつ定期的に、上記動作を繰り返すことが可能となる。これにより、アクセス中継装置２が中継するアクセスの統計処理を頻繁に行うことができるので、統計処理結果のフィードバックがより有効になる。
【００６０】
さらに、プロキシサーバ２３−ｎがアクセスログを書きこんでから短時間の間に管理サーバ２４がアクセスログを参照できるため、ディスク装置２５１キャッシュメモリに書きこまれたアクセスログのキャッシュヒット率が高くなり、管理サーバ２４は短時間でアクセスログを読み出すことができる。更に、バックアップ装置２５３によりディスク２５２−１又は２５２−２のバックアップを収集することにより、全てのアクセスログのバックアップを収集することが可能である。
【００６１】
プロキシサーバ２３−ｎと管理サーバ２４が連携することにより、クライアント端末１−１〜１−ＬからＷｅｂサーバ３−Ｊへのアクセスを制限することができる。以下、この機能について説明する。
【００６２】
図９は、プロキシサーバ２３−ｎが持つアクセス管理テーブルのデータ構成を示す図である。図９を見れば明らかなように、Ｗｅｂサーバ３−Ｊへのアクセス数は、Ｗｅｂサーバへのアクセス制限と、リクエストＵＲＬでのアクセス制限の２種類のアクセス制限を行うことができる。
【００６３】
Ｗｅｂサーバアクセス管理テーブル８０は、クライアント端末１−１〜１−Ｌからのコンテンツ取得要求の送信先Ｗｅｂサーバを示すＷｅｂサーバアドレス８００と、該Ｗｅｂサーバへ現在送信しているコンテンツ取得要求の数を示すアクセス数８０１と、該Ｗｅｂサーバへの同時コンテンツ取得要求送信上限値を示す単位時間あたりのアクセス上限値８０２とから成る。
【００６４】
同様に、リクエストＵＲＬアクセス管理テーブル８１は、クライアント端末１−１〜１−Ｌからのコンテンツ取得要求の送信先ＵＲＬを示すリクエストＵＲＬ８１０と、該リクエストＵＲＬへ現在送信しているコンテンツ取得要求の数を示すアクセス数８１１と、該リクエストＵＲＬへの同時コンテンツ取得要求送信上限値を示す単位時間あたりのアクセス上限値８１２とから成る。
【００６５】
図１０は、管理サーバ２４が持つアクセス制限値管理テーブルのデータ構成を示す図である。プロキシサーバ２３−ｎと同様に、Ｗｅｂサーバに対するアクセス制限値管理テーブルと、リクエストＵＲＬに対するアクセス制限値管理テーブルが存在する。
【００６６】
Ｗｅｂサーバアクセス制限値管理テーブル９０は、クライアント端末１−１〜１−Ｌからのコンテンツ取得要求の送信先Ｗｅｂサーバを示すＷｅｂサーバアドレス９００と、アクセス制限をかける基準となるアクセス制限規定値９０１と、図７の統計データテーブル７０から得られる該Ｗｅｂサーバにコンテンツ取得要求を送信した場合の平均応答時間９０２と、該Ｗｅｂサーバへの同時コンテンツ取得要求送信上限値を示す単位時間あたりのアクセス上限値９０３とから成る。
【００６７】
同様に、リクエストＵＲＬアクセス制限値管理テーブル９１は、クライアント端末１−１〜１−Ｌからのコンテンツ取得要求の送信先ＵＲＬを示すリクエストＵＲＬ９１０と、アクセス制限をかける基準となるアクセス制限規定値９１１と、図７の統計データテーブル７０から得られる該リクエストＵＲＬにコンテンツ取得要求を送信した場合の平均応答時間９１２と、該リクエストＵＲＬへの同時コンテンツ取得要求送信上限値を示す単位時間あたりのアクセス上限値９１３とから成る。
【００６８】
上記２種類のテーブルを備えることにより、特定のＷｅｂサーバに対する要求全てを対象としてアクセス制限をする場合と、特定のＵＲＬ（すなわち、サービス）に対してアクセス制限をすることが可能になる。
【００６９】
図１１は、管理サーバ２４とプロキシサーバ２３−ｎの間でのアクセス上限値の更新方法を示すフローチャートである。この処理フローの開始は、たとえば、統計データテーブル７０の更新をきっかけとすればよい。
【００７０】
管理サーバ２４は、図８に示したアクセスログ統計処理Ｓ１１００の統計データテーブル更新Ｓ１１０９またはＳ１１１０を行う際、同時に、統計データテーブル７０の平均応答時間７０３の値を、Ｗｅｂサーバアクセス制限値管理テーブル９０中の平均応答時間９０２と、リクエストＵＲＬアクセス制限値管理テーブル９１中の平均応答時間９１２に設定する（Ｓ１３０１）。
その後、Ｗｅｂサーバアクセス制限値管理テーブル９０中の平均応答時間９０２とアクセス制限規定値９０１を比較する（Ｓ１３０２）。平均応答時間９０２が規定値を超えている場合は、アクセス上限値９０３を規定数（１〜１０程度、アクセス中継装置２の通信規模により決める）だけ減らし、アクセス上限値９０３を更新する（Ｓ１３０３）。同様に、リクエストＵＲＬアクセス制限値管理テーブル９１中の平均応答時間９１２とアクセス制限規定値９１１を比較し（Ｓ１３０４）、平均応答時間９１２が規定値を超えている場合は、アクセス上限値９１３を規定数だけ減らし、アクセス上限値９１３を更新する（Ｓ１３０５）。最後に変更されたＷｅｂサーバアドレス９００とアクセス上限値９０３の組み合わせ、及び、リクエストＵＲＬ９１０とアクセス上限値９１３の組み合わせの情報をプロキシサーバ２３−ｎに通知する（Ｓ１３０６）。通知は、ＳＡＮ２６経由でも良いし、負荷分散装置２２とプロキシサーバ２３−ｎとを接続するネットワーク経由でもよい。
【００７１】
一方、プロキシサーバ２３−ｎは、管理サーバ２４からアクセス上限値９０３、９１３の情報を受信すると（Ｓ１４０１）、該アクセス上限値９０３の対象エントリがＷｅｂサーバアクセス管理テーブル８０内に存在するかをチェックする（Ｓ１４０２）。もし存在した場合は、そのエントリのアクセス上限値８０２の値を、通知されたアクセス上限値９０３の値に置き換える（Ｓ１４０３）。存在しなかった場合は、通知されたＷｅｂサーバアドレス９００、アクセス上限値９０３の値を用いて、Ｗｅｂサーバアクセス管理テーブル８０に新しいエントリを追加する（Ｓ１４０４）。同様に、該アクセス上限値９１３の対象エントリがリクエストＵＲＬアクセス管理テーブル８１内に存在するかをチェックする（Ｓ１４０５）。もし存在する場合は、そのエントリのアクセス上限値８１２の値を、通知されたアクセス上限値９１３の値に置き換える（Ｓ１４０６）。存在しない場合は、通知されたリクエストＵＲＬ９１０、アクセス上限値９１３の値を用いて、リクエストＵＲＬアクセス管理テーブル８１に新しいエントリを追加する（Ｓ１４０７）。
【００７２】
また、プロキシサーバ２３−ｎは、上記処理と平行して行うコンテンツ取得処理において、コンテンツ取得要求数がアクセス上限値を超えていた場合、受信したコンテンツ取得要求に対してエラーメッセージを作成し、これをコンテンツ取得要求の発信元であるクライアント端末１に送信する。
【００７３】
以上説明したように、管理サーバ２４と連携することにより、プロキシサーバ２３−ｎは、アクセス中継装置２を介して行われる全てのアクセス状態を短時間のうちにＷｅｂサーバへのアクセス制限に反映することができる。
【００７４】
さらに、複数のプロキシサーバ２３−ｎによるアクセス状況を総合した統計処理を行うことが出来るので、より正確なアクセス制御が可能になる。
【００７５】
上記実施例によれば、通信記録であるアクセスログを共有ディスク装置上に蓄積するため、プロキシサーバの障害によるアクセスログ消失からアクセスログを保護できるだけでなく、アクセスログのバックアップが容易になる。
【００７６】
また、他のサーバがアクセスログを用いて統計処理を行う場合に、共有ディスク装置からアクセスログを読み出すだけで済むため、統計処理に伴うアクセスログ回収のオーバヘッドを削減できる。
【００７７】
また、プロキシサーバと統計処理を行うサーバが連携することにより、統計処理結果から得られるＷｅｂサーバへのアクセス状態を短時間のうちにプロキシサーバのアクセス制御に反映することができ、特定のＷｅｂサーバへのアクセス集中によるサービス品質低下からＷｅｂサーバを保護することができる。
【００７８】
更に、プロキシサーバ２３−ｎからディスク装置２５へのアクセスログの転送オーバヘッドが小さいので、上記統計処理とその結果のフィードバックを頻繁に行うことが出来るので、より適切なアクセス制御が可能になる。
【００７９】
【発明の効果】
本発明によれば、より改善されたアクセスログの管理方法や、活用方法を提供することが出来る。
【図面の簡単な説明】
【図１】実施例におけるアクセス中継装置２を含む通信ネットワークシステムの構成図。
【図２】アクセス中継装置２を構成しているプロキシサーバ２３−ｎの構成図。
【図３】アクセス中継装置２を構成している管理サーバ２４の構成図。
【図４】ディスク装置２５上に蓄積されるアクセスログファイル５０のデータ構造の１実施例を示す図。
【図５】アクセスログの実体であるアクセスログレコード６１−１〜６０−Ｋのデータ構造の１例を示す図。
【図６】プロキシサーバ２３−ｎのコンテンツ取得要求処理の１実施例を示すフローチャート。
【図７】統計データテーブル７０及びアクセスログファイルテーブル７１のデータ構造の構成例を示す図。
【図８】管理サーバ２４が行うアクセスログ統計処理の一実施例を示すフローチャート。
【図９】２３−ｎＷｅｂサーバアクセス管理テーブル８０、及び、リクエストＵＲＬアクセス管理テーブル８１のデータ構造の構成例を示す図。
【図１０】Ｗｅｂサーバアクセス制限値管理テーブル９０、及び、リクエストＵＲＬアクセス制限値管理テーブル９１のデータ構造の構成例を示す図。
【図１１】管理サーバ２４におけるアクセス上限値９０２、９１２の更新、並びに、２３−ｎＷｅｂサーバアクセス管理テーブル８０のアクセス上限値８０２、及び、リクエストＵＲＬアクセス管理テーブル８１のアクセス上限値８１２を更新する処理の一実施例を示すフローチャート。
【符号の説明】
１：クライアント端末、２：アクセス中継装置、３：Ｗｅｂサーバ、２１：パケット中継装置、２２：負荷分散装置、２３：プロキシサーバ、２４：管理サーバ、２５：ディスク装置、２６：ＳＡＮ、５０：アクセスログファイル、６０：アクセスログファイルヘッダ、６１：アクセスログレコード、７０：統計データテーブル、８０：Ｗｅｂサーバアクセス管理テーブル、８１：リクエストＵＲＬアクセス管理テーブル、９０：Ｗｅｂサーバアクセス数制限値管理テーブル、９１：リクエストＵＲＬアクセス数制限値管理テーブル。
【図１】
2004192170.tif 000003
【図２】
2004192170.tif 000004
【図３】
2004192170.tif 000005
【図４】
2004192170.tif 000006
【図５】
2004192170.tif 000007
【図６】
2004192170.tif 000008
【図７】
2004192170.tif 000009
【図８】
2004192170.tif 000010
【図９】
2004192170.tif 000011
【図１０】
2004192170.tif 000012
【図１１】
2004192170.tif 000013