特許 5775925 負荷分散装置、負荷分散方法及び負荷分散プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5775925

(24)【登録日】2015年7月10日

(45)【発行日】2015年9月9日

(54)【発明の名称】負荷分散装置、負荷分散方法及び負荷分散プログラム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20150820BHJP

   G06F 15/00 20060101ALI20150820BHJP

【ＦＩ】

   G06F9/46 465D

   G06F15/00 420B

【請求項の数】5

【全頁数】10

(21)【出願番号】特願2013-263328(P2013-263328)

(22)【出願日】2013年12月20日

(65)【公開番号】特開2015-118659(P2015-118659A)

(43)【公開日】2015年6月25日

【審査請求日】2013年12月27日

(73)【特許権者】

【識別番号】397065480

【氏名又は名称】エヌ・ティ・ティ・コムウェア株式会社

(74)【代理人】

【識別番号】100083806

【弁理士】

【氏名又は名称】三好 秀和

(74)【代理人】

【識別番号】100100712

【弁理士】

【氏名又は名称】岩▲崎▼ 幸邦

(74)【代理人】

【識別番号】100101247

【弁理士】

【氏名又は名称】高橋 俊一

(74)【代理人】

【識別番号】100095500

【弁理士】

【氏名又は名称】伊藤 正和

(72)【発明者】

【氏名】藤兼 寛

(72)【発明者】

【氏名】田中 誠二

(72)【発明者】

【氏名】佐藤 晋太郎

(72)【発明者】

【氏名】伊藤 浩之

(72)【発明者】

【氏名】伊能 和義

(72)【発明者】

【氏名】大森 敏充

(72)【発明者】

【氏名】大西 正嗣

【審査官】 井上 宏一

(56)【参考文献】

【文献】 特開平１１− ９８１６２（ＪＰ，Ａ）

【文献】 特開２０１３−１７５０５２（ＪＰ，Ａ）

【文献】 特開２０１３− ５４５５３（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１２／０２８４７２５（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４６ −９／５４

Ｇ０６Ｆ １５／００

(57)【特許請求の範囲】

【請求項1】

セッション管理時間が異なる複数の記憶手段にセッション情報をそれぞれ記憶させ、各セッション管理時間がそれぞれ経過した後に各記憶手段からそれぞれ削除することにより、リクエスト内のセッション情報を管理する管理手段と、
端末装置からウェブ提供装置へのリクエストを捕捉する受信手段と、
前記複数の記憶手段にそれぞれ記憶されたセッション情報の各総数が、各記憶手段の各セッション管理時間で前記ウェブ提供装置が処理可能な各上限セッション数に到達しているか否かをそれぞれ判定する判定手段と、
前記判定の結果、前記複数の記憶手段のうち少なくとも１つ以上が上限セッション数に到達している場合、前記捕捉リクエストを前記ウェブ提供装置へ転送せず、前記複数の記憶手段のうちいずれも到達していない場合、前記捕捉リクエストを前記ウェブ提供装置へ転送する制御手段と、
を有することを特徴とする負荷分散装置。

【請求項2】

前記判定手段は、
前記複数の記憶手段のうち少なくとも１つ以上が上限セッション数に到達している場合、前記捕捉リクエスト内のセッション情報がセッション管理時間の最も長い記憶手段にあるか否かを判定し、
前記制御手段は、
当該記憶手段にない場合、前記捕捉リクエストを転送することなく前記端末装置へ非転送の結果情報を送信し、当該記憶手段にある場合、前記捕捉リクエストを前記ウェブ提供装置へ転送することを特徴とする請求項１に記載の負荷分散装置。

【請求項3】

コンピュータにより、
セッション管理時間が異なる複数の記憶手段にセッション情報をそれぞれ記憶させ、各セッション管理時間がそれぞれ経過した後に各記憶手段からそれぞれ削除することにより、リクエスト内のセッション情報を管理する管理ステップと、
端末装置からウェブ提供装置へのリクエストを捕捉する受信ステップと、
前記複数の記憶手段にそれぞれ記憶されたセッション情報の各総数が、各記憶手段の各セッション管理時間で前記ウェブ提供装置が処理可能な各上限セッション数に到達しているか否かをそれぞれ判定する判定ステップと、
前記判定の結果、前記複数の記憶手段のうち少なくとも１つ以上が上限セッション数に到達している場合、前記捕捉リクエストを前記ウェブ提供装置へ転送せず、前記複数の記憶手段のうちいずれも到達していない場合、前記捕捉リクエストを前記ウェブ提供装置へ転送する制御ステップと、
を有することを特徴とする負荷分散方法。

【請求項4】

前記判定ステップにおいて、
前記複数の記憶手段のうち少なくとも１つ以上が上限セッション数に到達している場合、前記捕捉リクエスト内のセッション情報がセッション管理時間の最も長い記憶手段にあるか否かを判定し、
前記制御ステップにおいて、
当該記憶手段にない場合、前記捕捉リクエストを転送することなく前記端末装置へ非転送の結果情報を送信し、当該記憶手段にある場合、前記捕捉リクエストを前記ウェブ提供装置へ転送することを特徴とする請求項３に記載の負荷分散方法。

【請求項5】

請求項３又は４に記載の負荷分散方法をコンピュータに実行させることを特徴とする負荷分散プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サーバの負荷を分散する技術に関する。

【背景技術】

【0002】

リクエストの増加に伴うサービスの低下を防止するため、Ｗｅｂサーバの前段には負荷分散装置が配置されている。負荷分散装置は、クライアント端末からのＨＴＴＰリクエストを一旦受信し、初回のリクエストであれば、複数のＷｅｂサーバのうち任意のＷｅｂサーバへ転送する。一方、２回目以降のリクエストであれば、クライアント端末とＷｅｂサーバ間で矛盾のない通信を保証するため、リクエスト内のセッションＩＤを発行したＷｅｂサーバへ転送する（非特許文献１参照）。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】“負荷分散入門 第６回 セッション維持機能”、富士通株式会社、［online］、［平成25年12月11日検索］、＜URL: http://fenics.fujitsu.com/products/ipcom/catalog/data/1/6.html＞

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、いずれの場合であってもＨＴＴＰリクエストを必ず転送するため、負荷分散装置を介在させたとしてもＷｅｂサーバの負荷を確実に低減することは難しいという課題があった。例えば、災害発生時にクライアント端末から災害伝言ダイヤルへ伝言登録等が行われる場合、東日本や西日本等の一定広域毎に配置された数台レベルの伝言ダイヤル提供サーバでは、数千万台単位のクライアント端末からのＨＴＴＰリクエストを全て受け付けて確実に処理することは極めて困難である。

【0005】

本発明は、上記事情を鑑みてなされたものであり、Ｗｅｂサーバの負荷を改善することを目的とする。

【課題を解決するための手段】

【0006】

請求項１に記載の負荷分散装置は、セッション管理時間が異なる複数の記憶手段にセッション情報をそれぞれ記憶させ、各セッション管理時間がそれぞれ経過した後に各記憶手段からそれぞれ削除することにより、リクエスト内のセッション情報を管理する管理手段と、端末装置からウェブ提供装置へのリクエストを捕捉する受信手段と、前記複数の記憶手段にそれぞれ記憶されたセッション情報の各総数が、各記憶手段の各セッション管理時間で前記ウェブ提供装置が処理可能な各上限セッション数に到達しているか否かをそれぞれ判定する判定手段と、前記判定の結果、前記複数の記憶手段のうち少なくとも１つ以上が上限セッション数に到達している場合、前記捕捉リクエストを前記ウェブ提供装置へ転送せず、前記複数の記憶手段のうちいずれも到達していない場合、前記捕捉リクエストを前記ウェブ提供装置へ転送する制御手段と、を有することを要旨とする。

【0007】

本発明によれば、セッション管理時間が異なる複数の記憶手段を用いてリクエスト内のセッション情報を管理し、その複数の記憶手段にそれぞれ記憶されたセッション情報の各総数が、各記憶手段の各セッション管理時間でウェブ提供装置が処理可能な各上限セッション数に到達しているか否かをそれぞれ判定し、その判定の結果に基づき端末装置からのリクエストをウェブ提供装置へ転送又は非転送するため、ウェブ提供装置の負荷を低減することができる。

【0008】

請求項２に記載の負荷分散装置は、請求項１に記載の負荷分散装置において、前記判定手段は、前記複数の記憶手段のうち少なくとも１つ以上が上限セッション数に到達している場合、前記捕捉リクエスト内のセッション情報がセッション管理時間の最も長い記憶手段にあるか否かを判定し、前記制御手段は、当該記憶手段にない場合、前記捕捉リクエストを転送することなく前記端末装置へ非転送の結果情報を送信し、当該記憶手段にある場合、前記捕捉リクエストを前記ウェブ提供装置へ転送することを要旨とする。

【0009】

本発明によれば、複数の記憶手段のいずれかが上限セッション数に到達している場合、捕捉したリクエスト内のセッション情報がセッション管理時間の最も長い記憶手段にあるか否かを判定し、その記憶手段にない場合には当該リクエストを転送しないため、ウェブ提供装置の負荷をより確実に低減することができる。

【0010】

請求項３に記載の負荷分散方法は、コンピュータにより、セッション管理時間が異なる複数の記憶手段にセッション情報をそれぞれ記憶させ、各セッション管理時間がそれぞれ経過した後に各記憶手段からそれぞれ削除することにより、リクエスト内のセッション情報を管理する管理ステップと、端末装置からウェブ提供装置へのリクエストを捕捉する受信ステップと、前記複数の記憶手段にそれぞれ記憶されたセッション情報の各総数が、各記憶手段の各セッション管理時間で前記ウェブ提供装置が処理可能な各上限セッション数に到達しているか否かをそれぞれ判定する判定ステップと、前記判定の結果、前記複数の記憶手段のうち少なくとも１つ以上が上限セッション数に到達している場合、前記捕捉リクエストを前記ウェブ提供装置へ転送せず、前記複数の記憶手段のうちいずれも到達していない場合、前記捕捉リクエストを前記ウェブ提供装置へ転送する制御ステップと、を有することを要旨とする。

【0011】

請求項４に記載の負荷分散方法は、請求項３に記載の負荷分散方法において、前記判定ステップでは、前記複数の記憶手段のうち少なくとも１つ以上が上限セッション数に到達している場合、前記捕捉リクエスト内のセッション情報がセッション管理時間の最も長い記憶手段にあるか否かを判定し、前記制御ステップでは、当該記憶手段にない場合、前記捕捉リクエストを転送することなく前記端末装置へ非転送の結果情報を送信し、当該記憶手段にある場合、前記捕捉リクエストを前記ウェブ提供装置へ転送することを要旨とする。

【0012】

請求項５に記載の負荷分散プログラムは、請求項３又は４に記載の負荷分散方法をコンピュータに実行させることを要旨とする。

【発明の効果】

【0013】

本発明によれば、Ｗｅｂサーバの負荷を低減することができる。

【図面の簡単な説明】

【0014】

【図1】負荷分散装置の機能ブロック構成を示す図である。

【図2】負荷分散装置の処理フローを示す図である。

【図3】処理パターンＡのシーケンスを示す図である。

【図4】処理パターンＢのシーケンスを示す図である。

【図5】処理パターンＣのシーケンスを示す図である。

【図6】処理パターンＤのシーケンスを示す図である。

【図7】処理パターンＥのシーケンスを示す図である。

【発明を実施するための形態】

【0015】

本発明は、（１）セッション管理時間が異なる複数の管理テーブルを用いてＨＴＴＰリクエスト内のセッションＩＤを管理し、（２）その複数の管理テーブルにそれぞれ記憶されたセッションＩＤの各総数が、各管理テーブルの各セッション管理時間でＷｅｂサーバが処理可能な各上限セッション数に到達しているか否かをそれぞれ判定し、（３）いずれかの管理テーブルが上限セッション数に到達している場合には、捕捉したＨＴＴＰリクエスト内のセッションＩＤがセッション管理時間の最も長い管理テーブルにあるか否かを判定し、（４）その管理テーブルにない場合には、そのＨＴＴＰリクエストを転送することなくクライアント端末へ非転送の結果情報を送信することにより、Ｗｅｂサーバの負荷を低減するようにしている。以下、本発明を実施する一実施の形態について図面を用いて説明する。

【0016】

図１は、本実施の形態に係る負荷分散装置１の機能ブロック構成を示す図である。本負荷分散装置１は、セッション管理部１１と、リクエスト受信部１２と、第１のセッション判定部１３と、第２のセッション判定部１４と、リクエスト制御部１５とを備えて構成される。

【0017】

セッション管理部１１は、セッション管理時間が異なる複数の管理テーブル（記憶手段）を用いてこれまでに受信したＨＴＴＰリクエスト内のセッションＩＤを管理する機能部である。受信したＨＴＴＰリクエスト内にセッションＩＤがある場合には全ての管理テーブルにそれぞれ登録し、その一方で各管理テーブルでのセッション管理時間が経過した後に順次削除する。なお、セッションＩＤと共にＨＴＴＰリクエストの受信時刻を関連付けて登録してもよい。

【0018】

リクエスト受信部１２は、クライアント端末２からＷｅｂサーバ３へ送信されるＨＴＴＰリクエストを受信（捕捉）する機能部である。

【0019】

第１のセッション判定部１３は、受信したＨＴＴＰリクエストにセッションＩＤが含まれているか否かを判定する機能部である。通常、同一のクライアント端末２からのＨＴＴＰリクエストが２回目以降であればセッションＩＤが含まれている。

【0020】

第２のセッション判定部１４は、各管理テーブルにそれぞれ登録されているセッションＩＤの各総数が、各管理テーブルの各セッション管理時間内でＷｅｂサーバ３が処理可能な上限セッション数に到達しているか否かをそれぞれ判定する機能部である。

【0021】

リクエスト制御部１５は、第１のセッション判定部１３及び第２のセッション判定部１４によって行われた各判定結果に基づき、リクエスト受信部１２で受信したＨＴＴＰリクエストを転送又は非転送する機能部である。

【0022】

以上が負荷分散装置１の備える機能である。なお、負荷分散装置１は、クライアント端末２とＷｅｂサーバ３との間に配置され、それらに通信可能に接続されている。

【0023】

次に、本実施の形態に係る負荷分散装置１の動作について説明する。図２は、負荷分散装置１の処理フローを示す図である。なお、セッション管理部１１は、セッション管理時間が３０分である３０分用テーブル及びＩＰテーブルと、同管理時間が１０秒である１０秒用テーブルとを管理しているものとする。３０分用テーブルとは、１０秒用テーブルについても同様に、ＨＴＴＰリクエストを受信した後、３０分を経過していないセッションＩＤを管理するためのものである。一方、ＩＰテーブルとは、その受信後に３０分を経過していないクライアント端末毎のセッションＩＤを管理するためのものである。

【0024】

まず、ステップＳ１において、リクエスト受信部１２は、クライアント端末２からＷｅｂサーバ３へ送信されるＨＴＴＰリクエストを受信（捕捉）する。

【0025】

次に、ステップＳ２において、第１のセッション判定部１３は、受信したＨＴＴＰリクエストにセッションＩＤが含まれているかを判定する。その判定の結果、セッションＩＤが含まれていない場合には、クライアント端末２からのＨＴＴＰリクエストが初回であるため、ステップＳ３へ進む。

【0026】

次に、ステップＳ３において、第２のセッション判定部１４は、３０分用テーブルに現在登録されているセッションＩＤの数をカウントし、Ｗｅｂサーバ３において３０分間で処理可能な上限セッション数に到達しているかを判定する。同様に、１０秒用テーブル内のセッションＩＤの数が１０秒間で処理可能な上限セッション数に到達しているかを判定し、更に、ＩＰテーブル内のセッションＩＤの数が３０分間で処理可能なクライアント端末毎の上限セッション数に到達しているかも判定する。

【0027】

そして、それら各判定の結果、３種類の管理テーブルのうちいずれかが上限セッション数に到達している場合には、現時点でのＷｅｂサーバ３は高負荷状態であるため、ステップＳ４において、リクエスト制御部１５は、受信中のＨＴＴＰリクエストをＷｅｂサーバ３へ転送することなく、送信元であるクライアント端末２の画面に「Ｓｏｒｒｙ Ｐａｇｅ」（非転送の結果情報）を表示する。このときの処理パターンＡを図３に示す。

【0028】

一方、３種類の管理テーブルのいずれも上限セッション数に到達していない場合やいずれかに空きがある場合には、現時点でのＷｅｂサーバ３は高負荷状態でないため、ステップＳ５において、リクエスト制御部１５は、受信中のＨＴＴＰリクエストをＷｅｂサーバ３へ転送する。なお、ステップＳ６に示すように、ＨＴＴＰリクエストを転送するもののセッションＩＤがないため、セッション管理部１１によってセッションＩＤが各管理テーブルに追加登録されることはない。

【0029】

このときの処理パターンＢを図４に示す。Ｗｅｂサーバ３は、ＨＴＴＰリクエストを受信した後、そのリクエストに対する内部処理が成功すればセッション開始用ＳＤＲ（Subscriber Detail Record：ユーザ単位に作成するアクセスレコード）やセッションＩＤを発行し、要求元のクライアント端末２へ送信する。なお、負荷分散装置１によるＨＴＴＰリクエストの転送処理が成功したとしても、Ｗｅｂサーバ３の状態により内部処理が失敗した場合には、Ｗｅｂサーバ３からクライアント端末２へその旨が通知されることになる。

【0030】

ここまでのステップＳ３〜ステップＳ６が初回リクエスト時における負荷分散装置１の動作であり、その処理後は本動作を終了する。その一方、ステップＳ２の判定の結果、セッションＩＤが受信中のＨＴＴＰリクエストに含まれている場合は、２回目以降のリクエストであるため、ステップＳ７へ進み、第２のセッション判定部１４は、ここでもステップＳ３と同様の処理を実行する。

【0031】

そして、ステップＳ７での各判定の結果、３種類の管理テーブルのうちいずれかが上限セッション数に到達している場合には、ステップＳ８において、第２のセッション判定部１４は、続いて、ＨＴＴＰリクエスト内のセッションＩＤが、セッション管理時間の最も長い３０分用テーブルに登録されているかを判定する。

【0032】

そして、その判定の結果、そのセッションＩＤが３０分用テーブルにない場合には、最も長いセッション管理時間を経過した後のリクエストであるため、ステップＳ９において、リクエスト制御部１５は、受信中のＨＴＴＰリクエストをＷｅｂサーバ３へ転送することなく、送信元であるクライアント端末２の画面に「Ｓｏｒｒｙ Ｐａｇｅ」を表示する。その後、ステップＳ１１へ進み、セッション管理部１１は、そのセッションＩＤを全ての管理テーブルへ上書き（空きがあれば追記）する。このときの処理パターンＣを図５に示す。

【0033】

一方、ステップＳ８での判定の結果、セッションＩＤが３０分用テーブルにある場合には、３種類の管理テーブルのうちいずれかが上限セッション数に到達していてもセッション管理時間内での再度のリクエストであるため、ステップＳ１０において、リクエスト制御部１５は、受信中のＨＴＴＰリクエストをＷｅｂサーバ３へ転送する。その後、ステップＳ１１へ進み、セッション管理部１１は、そのセッションＩＤを全ての管理テーブルへ上書きする。このときの処理パターンＤを図６に示す。

【0034】

最後に、ステップＳ７での判定の結果、３種類の管理テーブルのいずれも上限セッション数に到達していない場合には、現時点でのＷｅｂサーバ３は高負荷状態でないため、ステップＳ８を経由することなくステップＳ１０へ進み、リクエスト制御部１５は、受信中のＨＴＴＰリクエストをＷｅｂサーバ３へ転送する。その後、ステップＳ１１へ進み、セッション管理部１１は、そのＨＴＴＰリクエスト内のセッションＩＤを全ての管理テーブルへ上書きする。このときの処理パターンＥを図７に示す。

【0035】

以上が負荷分散装置１の処理フローの例である。なお、本処理フローは、各処理パターンＡ〜Ｅの動作を容易に理解するための一例にすぎず、例えば、共通動作であるステップＳ３，Ｓ７を１回のステップに纏め、ステップＳ１とステップＳ２との間で実行するようにしてもよい。また、ステップＳ２，Ｓ３，Ｓ７の各判定処理を１つのセッション判定部で行うようにしてもよい。

【0036】

以上より、本実施の形態によれば、セッション管理部１１が、セッション管理時間が異なる複数の管理テーブルを用いてＨＴＴＰリクエスト内のセッションＩＤを管理し、第２のセッション判定部１４が、複数の管理テーブルにそれぞれ記憶されたセッションＩＤの各総数が、各管理テーブルの各セッション管理時間でＷｅｂサーバ３が処理可能な各上限セッション数に到達しているか否かをそれぞれ判定し、リクエスト制御部１５が、その判定の結果に基づきクライアント端末２からＷｅｂサーバ３へのＨＴＴＰリクエストをＷｅｂサーバ３へ転送又は非転送するので、Ｗｅｂサーバ３の負荷を低減することができる。

【0037】

また、第２のセッション判定部１４は、複数の管理テーブルのいずれかが上限セッション数に到達している場合、捕捉したＨＴＴＰリクエスト内のセッションＩＤがセッション管理時間の最も長い管理テーブルにあるか否かを判定し、リクエスト制御部１５は、その管理テーブルにない場合には当該ＨＴＴＰリクエストを転送しないので、Ｗｅｂサーバ３の負荷をより確実に低減することができる。

【0038】

本実施の形態に係る負荷分散装置１を用いて行った過負荷試験結果、Ｗｅｂサーバでの処理成功率は４５％以上であった。本試験では、クライアント端末からのＨＴＴＰリクエスト数が秒間ピーク時の２倍としていたため、秒間ピーク時であったとしても９０％以上が成功することになる。すなわち、本実施の形態で説明した負荷分散装置１を用いることにより、概ね全てのリクエストを処理可能となることから、Ｗｅｂサーバの負荷が適切に改善されたという効果が実証される。

【0039】

なお、本実施の形態では、セッション管理時間が異なる３つの管理テーブルを用いてセッションＩＤを管理する場合を例に説明したが、それらの管理テーブルを１つの管理テーブルに含めて管理するようにしてもよい。

【0040】

最後に、本実施の形態で説明した負荷分散装置１は、メモリやＣＰＵを備えたコンピュータで実現できる。また、その処理は、プログラムによって実行される。更に、負荷分散装置１の各動作をプログラムとして構築し、コンピュータにインストールして実行させることや、通信ネットワークを介して流通させることも可能である。

【符号の説明】

【0041】

１…負荷分散装置
１１…セッション管理部（管理手段）
１２…リクエスト受信部（受信手段）
１３…第１のセッション判定部
１４…第２のセッション判定部（判定手段）
１５…リクエスト制御部（制御手段）
２…クライアント端末（端末装置）
３…Ｗｅｂサーバ（ウェブ提供装置）
Ａ〜Ｅ…処理パターン
Ｓ１〜Ｓ１１…ステップ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】