JP2013242751A - 負荷分散システムおよび負荷分散方法 - Google Patents

Abstract

【課題】実処理性能に合わせて適切にキャッシュサーバに対してクエリ要求を振り分けるとともに、リプレイスされたＤＮＳキャッシュサーバ側の処理効率を向上させることを課題とする。
【解決手段】ＤＮＳシステム１００では、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎは、クエリ要求を受け付けた回数に対して、該クエリ要求に対応するレコードがキャッシュされていた回数の割合であるキャッシュヒット率を算出する。そして、ロードバランサ１０は、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎによって算出されたキャッシュヒット率をそれぞれ取得すし、取得された各キャッシュヒット率を比較し、比較された結果、キャッシュヒット率の値が高い各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎほど、クエリ要求の振り分け先として優先的に決定するように制御する。
【選択図】 図１

Description

本発明は、負荷分散システムおよび負荷分散方法に関する。

従来より、インターネット上のホスト名（ドメイン名）とＩＰアドレス（Internet Protocol Address）とを対応させるＤＮＳ（Domain Name System）と呼ばれるシステムがある。かかるＤＮＳシステムは、例えば、ＤＮＳクライアントとＤＮＳ権威サーバとの間に、ロードバランサおよび複数のＤＮＳキャッシュサーバを介して構成される。

ＤＮＳ権威サーバは、ホスト名とＩＰアドレスとを対応付けた変換表（リソースレコードファイル）を管理している。そして、ＤＮＳクライアントからクエリ要求が発信されると、ロードバランサが複数のＤＮＳキャッシュサーバのうちのいずれかのサーバにクエリ要求を振り分けて送信し、このクエリ要求を受信したキャッシュサーバは、該クエリ要求に対応するリソースレコードがキャッシュされている場合には、キャッシュされているリソースレコードを、ロードバランサを介してＤＮＳクライアントに返信する。

また、キャッシュサーバは、クエリ要求に対応するリソースレコードがキャッシュされていない場合には、ＤＮＳ権威サーバに対してクエリ要求を送信する。かかるクエリ要求を受信した権威サーバは、変換表（リソースレコードファイル）から対応するリソースレコードを検索し、検索結果としてのリソースレコードをクエリ応答としてＤＮＳキャッシュサーバに送信する。そして、このクエリ応答を受信したＤＮＳキャッシュサーバは、ロードバランサを介して、クエリ要求を発信したＤＮＳクライアントにクエリ応答を送信する。

上述したように、ロードバランサは、ＤＮＳクライアントからのＤＮＳクエリを受信後、所定のロジックによって複数のＤＮＳキャッシュサーバのうちのいずれかのサーバにクエリ要求を振り分ける。例えば、ロードバランサでは、ラウンドロビンによりキャッシュサーバの振り分けを行う方法が知られている。つまり、ロードバランサは、ラウンドロビンにより、各ＤＮＳキャッシュサーバに対して、順番にクエリ要求を振り分ける。また、ロードバランサでは、ＣＰＵ使用率に基づいて、キャッシュサーバの振り分けを行う方法が知られている。例えば、ＣＰＵ使用率が低いキャッシュサーバを、優先的にＤＮＳクエリの振り分け先として決定する。

"負荷分散入門"、［online］、［平成２４年５月１６日検索］、インターネット＜http://fenics.fujitsu.com/products/ipcom/catalog/data/1/3.html＞

しかしながら、上記した従来の技術では、ラウンドロビンやＣＰＵ使用率に基づいて、各キャッシュサーバに対してクエリ要求の振り分けを行うので、実処理性能に合わせて適切にキャッシュサーバに対してクエリ要求を振り分けることができないという課題があった。すなわち、ＤＮＳキャッシュサーバでは、キャッシュの蓄積具合によってその処理性能が変わるため、ラウンドロビンやＣＰＵ使用率に基づいて、各キャッシュサーバに対してクエリ要求を振り分けた場合には、実処理性能に合わせて適切にキャッシュサーバに対してクエリ要求を振り分けることができない。

また、設備故障などにより、ＤＮＳキャッシュサーバのリプレイス時にサーバ間でのキャッシュ蓄積状態の差に基づく性能差が発生した場合に、ラウンドロビンやＣＰＵ使用率に基づいて、各キャッシュサーバに対してクエリ要求を振り分けると、リプレイスされたサーバ側で処理のロスが発生してしまう。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、実処理性能に合わせて適切にキャッシュサーバに対してクエリ要求を振り分けるとともに、リプレイスされたサーバ側の処理効率を向上させることを目的とする。

上述した課題を解決し、目的を達成するため、負荷分散システムは、クライアント装置からのクエリ要求を複数のキャッシュサーバのうちのいずれかのキャッシュサーバに転送する負荷分散装置と、前記クエリ要求に対応するレコードをキャッシュする複数のキャッシュサーバとを備えた負荷分散システムであって、各キャッシュサーバは、前記クエリ要求を受け付けた回数に対して、該クエリ要求に対応するレコードがキャッシュされていた回数の割合であるキャッシュヒット率を算出する算出部を備え、前記負荷分散装置は、各キャッシュサーバによって算出されたキャッシュヒット率をそれぞれ取得する取得部と、前記取得部によって取得された各キャッシュヒット率を比較する比較部と、前記比較部によって比較された結果、キャッシュヒット率の値が高いキャッシュサーバほど、前記クエリ要求の振り分け先として優先的に決定するように制御する振分制御部と、を備えることを特徴とする。

また、負荷分散方法は、クライアント装置からのクエリ要求を複数のキャッシュサーバのうちのいずれかのキャッシュサーバに転送する負荷分散装置で実行される負荷分散方法であって、各キャッシュサーバによって算出されたキャッシュヒット率をそれぞれ取得する取得工程と、前記取得工程によって取得された各キャッシュヒット率を比較する比較工程と、前記比較工程によって比較された結果、キャッシュヒット率の値が高いキャッシュサーバほど、前記クエリ要求の振り分け先として優先的に決定するように制御する振分制御工程と、を含んだことを特徴とする。

本願に開示する負荷分散システムおよび負荷分散方法は、実処理性能に合わせて適切にキャッシュサーバに対してクエリ要求を振り分けるとともに、リプレイスされたサーバ側の処理効率を向上させることができるという効果を奏する。

図１は、第一の実施の形態に係るＤＮＳシステムの全体構成を示すシステム構成図である。 図２は、第一の実施の形態に係るロードバランサの構成を示すブロック図である。 図３は、キャッシュヒット率記憶部に記憶されるテーブルの一例を示す図である。 図４は、第一の実施の形態に係るロードバランサによる振分制御処理を説明する図である。 図５は、第一の実施の形態に係るロードバランサによる振分制御処理の流れを示すフローチャートである。 図６は、第二の実施の形態に係るロードバランサの構成を示すブロック図である。 図７は、第二の実施の形態に係るロードバランサによる振分制御処理の流れを示すフローチャートである。 図８は、第二の実施の形態に係るロードバランサによる振分制御処理の流れを示すフローチャートである。 図９は、負荷分散プログラムを実行するコンピュータを示す図である。

以下に、本願に係る負荷分散システムおよび負荷分散方法の実施形態を図面に基づいて詳細に説明する。なお、この実施形態により本願に係る負荷分散システムおよび負荷分散方法が限定されるものではない。

［第一の実施の形態］
以下の実施の形態では、第一の実施の形態に係るＤＮＳシステムの構成、ロードバランサの構成および処理の流れを順に説明し、最後に第一の実施の形態による効果を説明する。

［第一の実施の形態に係るＤＮＳシステムの構成］
まず、図１を用いて、第一の実施の形態に係るＤＮＳシステムについて説明する。図１は、第一の実施の形態に係るＤＮＳシステムの全体構成を示すシステム構成図である。

図１に示すように、ＤＮＳシステム１００には、ロードバランサ１０、複数のＤＮＳキャッシュサーバ２０Ａ〜２０Ｎ、ＤＮＳクライアント３０、および、ＤＮＳ権威サーバ４０が含まれ、ＤＮＳクライアント３０とＤＮＳ権威サーバ４０との間に、ロードバランサ１０および複数のＤＮＳキャッシュサーバ２０Ａ〜２０Ｎを介して構成される。ここで、ＤＮＳシステム１００とは、インターネット上のホスト名（ドメイン名）とＩＰアドレス（Internet Protocol Address）とを対応させるＤＮＳ（Domain Name System）と呼ばれるシステムである。なお、複数のＤＮＳキャッシュサーバ２０Ａ〜２０Ｎについて、特に区別なく説明する場合には、「ＤＮＳキャッシュサーバ２０」と記載して説明する。

第一の実施の形態に係るロードバランサ１０は、ＤＮＳクライアント３０からＤＮＳクエリを受信すると、キャッシュヒット率に基づいて、ＤＮＳクエリの振り分け先となるＤＮＳキャッシュサーバを、複数のＤＮＳキャッシュサーバ２０Ａ〜２０Ｎから決定し、決定したＤＮＳキャッシュサーバに対してＤＮＳクエリを送信する。なお、ロードバランサ１０の詳しい構成や処理については、後に図２等を用いて説明する。

ＤＮＳキャッシュサーバ２０は、ホスト名とＩＰアドレスとを対応付けた変換表（リソースレコード）がキャッシュされたキャッシュメモリを有する。そして、ＤＮＳキャッシュサーバ２０は、ロードバランサ１０からクエリ要求を受信すると、クエリ要求に対応するリソースレコードがキャッシュされているか否かを判定する。この結果、ＤＮＳキャッシュサーバ２０は、クエリ要求に対応するリソースレコードがキャッシュされている場合には、キャッシュされているリソースレコードをクエリ応答として、ロードバランサ１０を介してＤＮＳクライアント３０に返信する。また、ＤＮＳキャッシュサーバ２０は、クエリ要求に対応するリソースレコードがキャッシュされていない場合には、ＤＮＳ権威サーバ４０に対してクエリ要求を送信する。

ＤＮＳクライアント３０は、ロードバランサ１０に対してクエリ要求を送信する。ＤＮＳ権威サーバ４０は、ホスト名とＩＰアドレスとを対応付けた変換表（リソースレコードファイル）を管理している。そして、ＤＮＳ権威サーバ４０は、クエリ要求を受信すると、変換表（リソースレコードファイル）から対応するリソースレコードを検索し、検索結果としてのリソースレコードをクエリ応答としてＤＮＳキャッシュサーバ２０およびロードバランサ１０を介して、ＤＮＳクライアント３０に返信する。

［ロードバランサの構成］
次に、図２を用いて、図１に示したロードバランサ１０の構成を説明する。図２は、第一の実施の形態に係るロードバランサの構成を示すブロック図である。図２に示すように、このロードバランサ１０は、通信処理部１１、制御部１２、記憶部１３を有し、複数のＤＮＳキャッシュサーバ２０Ａ〜２０ＮおよびＤＮＳクライアント３０と接続される。以下にこれらの各部の処理を説明する。

通信処理部１１は、接続される複数のＤＮＳキャッシュサーバ２０Ａ〜２０ＮおよびＤＮＳクライアント３０との間でやり取りする各種情報に関する通信を制御する。例えば、通信処理部１１は、ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎに対してクエリ要求を送信し、また、ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎからクエリ応答を受信する。また、通信処理部１１は、ＤＮＳクライアント３０からクエリ要求を受信し、また、ＤＮＳクライアント３０に対してクエリ応答を送信する。

記憶部１３は、制御部１２による各種処理に必要なデータおよびプログラムを格納するが、特に本発明に密接に関連するものとしては、キャッシュヒット率記憶部１３ａおよび起動時キャッシュヒット率履歴記憶部１３ｂを有する。

キャッシュヒット率記憶部１３ａは、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎのキャッシュヒット率をそれぞれ記憶する。例えば、図３に例示するように、ＤＮＳキャッシュサーバ２０を一意に識別する「キャッシュサーバＩＤ」と、各ＤＮＳキャッシュサーバ２０の「キャッシュヒット率」とが対応付けて記憶されている。

図３の例を用いて説明すると、キャッシュヒット率記憶部１３ａは、キャッシュサーバＩＤ「１」のＤＮＳキャッシュサーバのキャッシュヒット率が「４０％」であり、キャッシュサーバＩＤ「２」のＤＮＳキャッシュサーバのキャッシュヒット率が「３０％」であり、キャッシュサーバＩＤ「３」のＤＮＳキャッシュサーバのキャッシュヒット率が「５０％」であり、キャッシュサーバＩＤ「４」のＤＮＳキャッシュサーバのキャッシュヒット率が「６６％」であり、キャッシュサーバＩＤ「５」のＤＮＳキャッシュサーバのキャッシュヒット率が「７５％」であることを記憶している。図３は、キャッシュヒット率記憶部に記憶されるテーブルの一例を示す図である。

起動時キャッシュヒット率履歴記憶部１３ｂは、過去におけるＤＮＳキャッシュサーバ２０が起動する際のキャッシュヒット率の履歴を記憶する。このキャッシュヒット率の履歴は、後述する振分制御部１２ｃによって参照されるデータである。

制御部１２は、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行するが、特に本発明に密接に関連するものとしては、取得部１２ａ、比較部１２ｂおよび振分制御部１２ｃを有する。

取得部１２ａは、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎによって算出されたキャッシュヒット率をそれぞれ取得する。例えば、取得部１２ａは、所定のタイミングで、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎに対してキャッシュヒット率を送信する旨の指示を送信し、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎからキャッシュヒット率を受信する。

その後、取得部１２ａは、受信したキャッシュヒット率をキャッシュヒット率記憶部１３ａに格納する。なお、ロードバランサ１０から各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎに対してキャッシュヒット率を要求せずに、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎが自動的にロードバランサ１０へキャッシュヒット率を送信するようにしてもよい。

また、各ＤＮＳキャッシュサーバ２０の算出部２１では、クエリ要求を受け付けた回数に対して、該クエリ要求に対応するレコードがキャッシュされていた回数の割合であるキャッシュヒット率を算出する。具体的には、算出部２１は、自装置内でのキャッシュヒット処理におけるキャッシュヒットカウンタと処理トラヒック総量カウンタを利用して、キャッシュヒット率を算出している。

比較部１２ｂは、取得部１２ａによって取得された各キャッシュヒット率を比較する。具体的には、比較部１２ｂは、クエリ要求を受信すると、キャッシュヒット率記憶部１３ａに記憶された各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎのキャッシュヒット率の値を比較する。例えば、図３の例を用いて説明すると、比較部１２ｂは、キャッシュヒット率記憶部１３ａに記憶された各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎのキャッシュヒット率の値を比較し、キャッシュサーバＩＤ「５」、「４」、「３」、「１」、「２」の順に、キャッシュヒット率が高いものと判定する。

振分制御部１２ｃは、比較部１２ｂによって比較された結果、キャッシュヒット率の値が高いＤＮＳキャッシュサーバ２０ほど、ＤＮＳクエリの振り分け先として優先的に決定するように制御する。例えば、図３の例を用いて説明すると、振分制御部１２ｃは、キャッシュサーバＩＤ「５」、「４」、「３」、「１」、「２」のＤＮＳキャッシュサーバ２０の順に、ＤＮＳクエリを優先的に振り分けるように制御する。

ここで、図４の例を用いて、振分制御について説明する。図４は、第一の実施の形態に係るロードバランサによる振分制御処理を説明する図である。図４に例示するように、最初に、ロードバランサ１０は、キャッシュヒット率の情報を取得する。この時点では、キャッシュヒット率が「０％」である。その後、ロードバランサ１０は、ＤＮＳキャッシュサーバ２０に対してクエリ要求を送信する。ＤＮＳキャッシュサーバ２０は、キャッシュヒットしなかったため、ＤＮＳ権威サーバ４０にクエリ要求を転送する。

そして、ＤＮＳキャッシュサーバ２０は、ＤＮＳ権威サーバ４０からクエリ応答を受信し、ロードバランサ１０にクエリ応答を送信する。その後、ロードバランサ１０は、キャッシュヒット率の情報を取得する。この時点では、キャッシュヒット率がまだ「０％」である。続いて、ロードバランサ１０は、ＤＮＳキャッシュサーバ２０に対してクエリ要求を送信する。そして、ＤＮＳキャッシュサーバ２０は、キャッシュヒットしたため、クエリ応答をロードバランサ１０に返信する。その後、ロードバランサ１０は、キャッシュヒット率の情報を取得する。この時点では、２回のうち１回がキャッシュヒットであったので、キャッシュヒット率が「５０％」となる。ここで、キャッシュヒット率が増加したため、ロードバランサ１０は、ＤＮＳキャッシュサーバ２０に対するクエリ要求の送信割合を増加させる。

続いて、ロードバランサ１０は、ＤＮＳキャッシュサーバ２０に対してクエリ要求を送信する。そして、ＤＮＳキャッシュサーバ２０は、キャッシュヒットしたため、クエリ応答をロードバランサ１０に返信する。その後、ロードバランサ１０は、キャッシュヒット率の情報を取得する。この時点では、３回のうち２回がキャッシュヒットであったので、キャッシュヒット率が「６６％」となる。ここで、キャッシュヒット率がさらに増加したため、ロードバランサ１０は、ＤＮＳキャッシュサーバ２０に対するクエリ要求の送信割合を増加させる。

続いて、ロードバランサ１０は、ＤＮＳキャッシュサーバ２０に対してクエリ要求を送信する。そして、ＤＮＳキャッシュサーバ２０は、キャッシュヒットしたため、クエリ応答をロードバランサ１０に返信する。その後、ロードバランサ１０は、キャッシュヒット率の情報を取得する。この時点では、４回のうち３回がキャッシュヒットであったので、キャッシュヒット率が「７５％」となる。ここで、キャッシュヒット率がさらに増加したため、ロードバランサ１０は、ＤＮＳキャッシュサーバ２０に対するクエリ要求の送信割合を増加させる。

このように、キャッシュヒット率の増加に伴い、該当ＤＮＳキャッシュサーバへのクエリ要求の送信割合を増加させるので、実処理性能に合わせて適切にＤＮＳキャッシュサーバに対してクエリ要求を振り分けることが可能である。また、リプレイスされた場合に、リプレイス直後でキャッシュヒット率が低ければ、ＤＮＳキャッシュサーバへのクエリ要求の送信割合を低く抑え、キャッシュヒット率の増加に伴い、該当ＤＮＳキャッシュサーバへのクエリ要求の送信割合を増加させるので、リプレイスされたサーバ側の処理効率を向上させることが可能である。

図２の説明に戻って、振分制御部１２ｃは、ＤＮＳキャッシュサーバ２０が起動された直後の場合には、取得されたキャッシュヒット率に代えて、過去の履歴に基づくキャッシュヒット率を用いて、クエリ要求の振分先を制御する。具体的には、振分制御部１２ｃは、ＤＮＳキャッシュサーバ２０がリプレイスにより起動された直後の場合には、起動時キャッシュヒット率履歴記憶部１３から過去におけるＤＮＳキャッシュサーバ２０が起動する際のキャッシュヒット率の履歴を取得する。振分制御部１２ｃは、この履歴の統計に基づく、想定ヒット率を算出し、取得部１２ａによって取得されたキャッシュヒット率に代えて、想定ヒット率を用いて、クエリ要求の振分先を制御する。

つまり、ＤＮＳキャッシュサーバ２０がリプレイスにより起動された直後は、統計データ母数が少なくキャッシュヒット率の変動が激しくなるため、より正確なキャッシュヒット率に基づく振分制御処理を行うために、過去の履歴を利用する。このため、リプレイスされたサーバ側の処理効率をより向上させることが可能である。

［ロードバランサによる処理］
次に、図５を用いて、第一の実施形態に係るロードバランサ１０による処理を説明する。図５は、第一の実施の形態に係るロードバランサによる振分制御処理の流れを示すフローチャートである。

図５に示すように、ロードバランサ１０の取得部１２ａは、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎによって算出されたキャッシュヒット率をそれぞれ取得する（ステップＳ１０１）。例えば、取得部１２ａは、所定のタイミングで、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎに対してキャッシュヒット率を送信する旨の指示を送信し、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎからキャッシュヒット率を受信する。

そして、比較部１２ｂは、取得部１２ａによって取得された各キャッシュヒット率を比較する（ステップＳ１０２）。具体的には、比較部１２ｂは、クエリ要求を受信すると、キャッシュヒット率記憶部１３ａに記憶された各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎのキャッシュヒット率の値を比較する。

そして、振分制御部１２ｃは、比較部１２ｂによって比較された結果、キャッシュヒット率の値が高いＤＮＳキャッシュサーバ２０ほど、ＤＮＳクエリの振分先として優先的に決定するように制御する（ステップＳ１０３）。

[第一の実施の形態の効果]
上述してきたように、ＤＮＳシステム１００では、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎは、クエリ要求を受け付けた回数に対して、該クエリ要求に対応するレコードがキャッシュされていた回数の割合であるキャッシュヒット率を算出する。そして、ロードバランサ１０は、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎによって算出されたキャッシュヒット率をそれぞれ取得し、取得された各キャッシュヒット率を比較し、比較された結果、キャッシュヒット率の値が高い各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎほど、クエリ要求の振り分け先として優先的に決定するように制御する。

このように、キャッシュヒット率が低ければ、ＤＮＳキャッシュサーバへのクエリ要求の送信割合を低く抑え、キャッシュヒット率の増加に伴い、該当ＤＮＳキャッシュサーバへのクエリ要求の送信割合を増加させるので、実処理性能に合わせて適切にキャッシュサーバに対してクエリ要求を振り分けるとともに、リプレイスされたＤＮＳキャッシュサーバ２０側の処理効率を向上させることが可能となる。

また、第一の実施の形態によれば、ＤＮＳシステム１００では、ロードバランサ１０は、キャッシュサーバが起動された直後の場合には、取得したキャッシュヒット率に代えて、過去の履歴に基づくキャッシュヒット率を用いて、クエリ要求の振分先を制御する。つまり、ＤＮＳキャッシュサーバ２０がリプレイスにより起動された直後は、統計データ母数が少なくキャッシュヒット率の変動が激しくなるため、より正確なキャッシュヒット率に基づく振分制御処理を行うために、過去の履歴を利用する。このため、リプレイスされたサーバ側の処理効率をより向上させることが可能である。

［第二の実施の形態］
ところで、上記の第一の実施の形態では、ロードバランサがＤＮＳキャッシュサーバからキャッシュヒット率を取得する場合を説明したが、これに限定されるものではなく、ロードバランサがキャッシュヒット率を算出するようにしてもよい。

そこで、以下の第二の実施の形態では、ロードバランサがキャッシュヒット率を算出する場合として、図６〜図８を用いて、第二の実施の形態におけるロードバランサの概要と特徴、構成および処理について説明する。図６は、第二の実施の形態に係るロードバランサの構成を示すブロック図である。図７は、第二の実施の形態に係るロードバランサによる振分制御処理の流れを示すフローチャートである。図８は、第二の実施の形態に係るロードバランサによる振分制御処理の流れを示すフローチャートである。

まず、図６を用いて、第二の実施の形態に係るロードバランサ１０の構成を説明する。第二の実施の形態に係るロードバランサ１０は、図２に示した第一の実施の形態に係るロードバランサ１０と比較して、取得部１２ａに代えて、算出部１２ｄを新たに備える点が相違する。

算出部１２ｄは、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎについて、ＤＮＳキャッシュサーバのクエリ要求に対する処理に関する情報を用いて、ＤＮＳキャッシュサーバがクエリ要求を受け付けた回数に対して、該クエリ要求に対応するレコードがキャッシュされていた回数の割合であるキャッシュヒット率をそれぞれ算出する。

具体的には、算出部１２ｄは、クエリ要求をキャッシュサーバが受け付けてから該クエリ要求に対する応答を返すまでの処理時間に関する情報（例えば、ＴＡＴ（Turn-Around Time））に基づいて、キャッシュヒット率を算出する。

例えば、算出部１２ｄは、ＤＮＳクエリの応答ＴＡＴが所定の閾値よりも長い場合には、キャッシュミスと判断し、ＤＮＳクエリの応答ＴＡＴが所定の閾値よりも短い場合には、キャッシュヒットと判断する。そして、算出部１２ｄは、全体のクエリ応答を受け付けた回数に対して、キャッシュヒットと判断された回数の割合をキャッシュヒット率として算出する。つまり、通常、キャッシュヒットした場合には、応答ＴＡＴが短く、キャッシュミスの場合には、ＤＮＳ権威サーバ４０にクエリ要求を転送するので、応答ＴＡＴが長くなるため、応答ＴＡＴからキャッシュヒットまたはキャッシュミスを推測することが可能である。

また、算出部１２ｄは、応答ＴＡＴなどの処理時間ではなく、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎについて、ＤＮＳキャッシュサーバが受け付けたクエリ要求に対する応答に含まれるキャッシュの有効期限に関する情報（例えば、ＴＴＬ値）に基づいて、キャッシュヒット率を算出してもよい。

例えば、算出部１２ｄは、ＴＴＬ値が所定の閾値よりも短い場合には、キャッシュミスと判断し、ＴＴＬ値が所定の閾値よりも長い場合には、キャッシュヒットと判断する。そして、算出部１２ｄは、全体のクエリ応答を受け付けた回数に対して、キャッシュヒットと判断された回数の割合をキャッシュヒット率として算出する。つまり、ＴＴＬ値が短い場合には、もうすぐキャッシュが消されることが分かっており、消された後はキャッシュミスとなるため、ここではキャッシュミスと判断してキャッシュヒット率を算出する。

その後、算出部１２ｄは、キャッシュヒット率を算出した後、キャッシュヒット率をキャッシュヒット率記憶部１３ａに格納する。

比較部１２ｂは、算出部１２ｄによって算出された各キャッシュヒット率を比較する。振分制御部１２ｃは、第一の実施の形態と同様に、比較部１２ｂによって比較された結果、キャッシュヒット率の値が高いＤＮＳキャッシュサーバ２０ほど、クエリ要求の振り分け先として優先的に決定する。また、振分制御部１２ｃは、キャッシュサーバが起動された直後の場合には、算出部１２ｄによって算出されたキャッシュヒット率に代えて、過去の履歴に基づくキャッシュヒット率を用いて、クエリ要求の振分先を制御する。

次に、図７および図８を用いて、第二の実施の形態に係るロードバランサ１０の処理を説明する。図７に示すように、第二の実施の形態に係るロードバランサ１０の算出部１２ｄは、ＤＮＳクエリの応答ＴＡＴが所定の閾値より長いか否かを判定する（ステップＳ２０１）。この結果、算出部１２ｄは、ＤＮＳクエリの応答ＴＡＴが所定の閾値よりも長い場合には（ステップＳ２０１肯定）、キャッシュミスと判別し（ステップＳ２０２）、ＤＮＳクエリの応答ＴＡＴが所定の閾値よりも短い場合には（ステップＳ２０１否定）、キャッシュヒットと判別する（ステップＳ２０３）。

そして、算出部１２ｄは、全体のクエリ応答を受け付けた回数に対して、キャッシュヒットと判断された回数の割合をキャッシュヒット率として算出する（ステップＳ２０４）。

そして、比較部１２ｂは、算出部１２ｄによって算出された各キャッシュヒット率を比較する（ステップＳ２０５）。具体的には、比較部１２ｂは、クエリ要求を受信すると、キャッシュヒット率記憶部１３ａに記憶された各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎのキャッシュヒット率の値を比較する。

そして、振分制御部１２ｃは、比較部１２ｂによって比較された結果、キャッシュヒット率の値が高いＤＮＳキャッシュサーバ２０ほど、ＤＮＳクエリの振り分け先として優先的に決定するように制御する（ステップＳ２０６）。

また、図８に示すように、第二の実施の形態に係るロードバランサ１０の算出部１２ｄは、ＴＴＬ値が比較値よりも短いか否かを判定する（ステップＳ３０１）。この結果、算出部１２ｄは、ＴＴＬ値が所定の閾値よりも短い場合には（ステップＳ３０１肯定）、キャッシュミスと判別し（ステップＳ３０２）、ＴＴＬ値が所定の閾値よりも長い場合には（ステップＳ３０１否定）、キャッシュヒットと判別する（ステップＳ３０３）。

そして、算出部１２ｄは、全体のクエリ応答を受け付けた回数に対して、キャッシュヒットと判断された回数の割合をキャッシュヒット率として算出する（ステップＳ３０４）。

そして、比較部１２ｂは、算出部１２ｄによって算出された各キャッシュヒット率を比較する（ステップＳ３０５）。具体的には、比較部１２ｂは、クエリ要求を受信すると、キャッシュヒット率記憶部１３ａに記憶された各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎのキャッシュヒット率の値を比較する。

そして、振分制御部１２ｃは、比較部１２ｂによって比較された結果、キャッシュヒット率の値が高いＤＮＳキャッシュサーバ２０ほど、ＤＮＳクエリの振り分け先として優先的に決定するように制御する（ステップＳ３０６）。

[第二の実施の形態の効果]
上述してきたように、第二の実施の形態に係るロードバランサ１０では、各ＤＮＳキャッシュサーバ２０Ａ〜２０Ｎについて、ＤＮＳキャッシュサーバ２０のクエリ要求に対する処理に関する情報を用いて、ＤＮＳキャッシュサーバ２０がクエリ要求を受け付けた回数に対して、該クエリ要求に対応するレコードがキャッシュされていた回数の割合であるキャッシュヒット率をそれぞれ算出する。そして、ロードバランサ１０は、算出された各キャッシュヒット率を比較し、比較された結果、キャッシュヒット率の値が高いＤＮＳキャッシュサーバ２０ほど、クエリ要求の振り分け先として優先的に決定するように制御する。

このように、キャッシュヒット率が低ければ、ＤＮＳキャッシュサーバ２０へのクエリ要求の送信割合を低く抑え、キャッシュヒット率の増加に伴い、該当ＤＮＳキャッシュサーバへのクエリ要求の送信割合を増加させるので、実処理性能に合わせて適切にキャッシュサーバに対してクエリ要求を振り分けるとともに、リプレイスされたＤＮＳキャッシュサーバ２０側の処理効率を向上させることが可能となる。また、ＤＮＳキャッシュサーバ２０にキャッシュヒット率を算出させることなく、ロードバランサ１０側でヒット率を算出することが可能となる。

また、第二の実施の形態に係るロードバランサ１０では、各ＤＮＳキャッシュサーバ２０について、クエリ要求をＤＮＳキャッシュサーバ２０が受け付けてから該クエリ要求に対する応答を返すまでの処理時間に基づいて、キャッシュヒット率を算出する。このため、ＤＮＳキャッシュサーバ２０にキャッシュヒット率を算出させることなく、ロードバランサ１０が取得可能な情報を用いて、ロードバランサ１０側でヒット率を算出することが可能となる。

また、第二の実施の形態に係るロードバランサ１０では、各ＤＮＳキャッシュサーバ２０について、ＤＮＳキャッシュサーバ２０が受け付けたクエリ要求に対する応答に含まれるキャッシュの有効期限に関する情報に基づいて、キャッシュヒット率を算出する。このため、ＤＮＳキャッシュサーバ２０にキャッシュヒット率を算出させることなく、ロードバランサ１０が取得可能な情報を用いて、ロードバランサ１０側でヒット率を算出することが可能となる。

また、第二の実施の形態に係るロードバランサ１０では、ＤＮＳキャッシュサーバ２０が起動された直後の場合には、算出されたキャッシュヒット率に代えて、過去の履歴に基づくキャッシュヒット率を用いて、クエリ要求の振分先を制御する。このため、リプレイスされたサーバ側の処理効率をより向上させることが可能である。

［第三の実施の形態］
さて、これまで本発明の実施の形態について説明したが、本発明は上述した実施の形態以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では第三の実施の形態として本発明に含まれる他の第三の実施の形態を説明する。

（１）最大ＴＴＬ値
第三の実施の形態では、各ドメインの過去のキャッシュデータにおける最大ＴＴＬ値を保持し、ヒット率算出時の比較データとして用いて、クエリ応答に含まれるＴＴＬ値が最大ＴＴＬ値と同一値と判定するようにしてもよい。

例えば、各ドメインの過去のキャッシュデータにおける最大ＴＴＬ値を保持し、ヒット率算出時の比較データとして用いて、クエリ応答に含まれるＴＴＬ値が最大ＴＴＬ値と同一値だった場合に、キャッシュヒットしなかったと判定してキャッシュヒット率を算出する。つまり、最大ＴＴＬと同一値である場合には、今回のクエリ要求キャッシュによりキャッシュがなされたものと判定し、キャッシュヒットしなかったものと判定する。

これにより、ＤＮＳキャッシュサーバにキャッシュヒット率を算出させることなく、ロードバランサ１０が取得可能な情報を用いて、ロードバランサ側でヒット率を算出するので、ＤＮＳキャッシュサーバの負担を軽減することが可能となる。

（２）システム構成等
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、取得部１２ａと比較部１２ｂを統合してもよい。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

（３）プログラム
また、上記実施形態において説明したロードバランサ１０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、第一の実施形態に係るロードバランサ１０が実行する処理をコンピュータが実行可能な言語で記述した負荷分散プログラムを作成することもできる。この場合、コンピュータが負荷分散プログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかる負荷分散プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録され負荷分散プログラムをコンピュータに読み込ませて実行することにより上記第一の実施形態と同様の処理を実現してもよい。以下に、図２に示したロードバランサ１０と同様の機能を実現する負荷分散プログラムを実行するコンピュータの一例を説明する。

図９は、負荷分散プログラムを実行するコンピュータ１０００を示す図である。図９に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、図９に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図９に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図９に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース１０５０は、図９に例示するように、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、図９に例示するように、例えばディスプレイ１０６１に接続される。

ここで、図９に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の負荷分散プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０３１に記憶される。

また、上記実施形態で説明した各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、取得手順、比較手順、振分制御手順を実行する。

なお、負荷分散プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、負荷分散プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１０ ロードバランサ
１１ 通信処理部
１２ 制御部
１２ａ 取得部
１２ｂ 比較部
１２ｃ 振分制御部
１２ｄ 算出部
１３ 記憶部
１３ａ キャッシュヒット率記憶部
１３ｂ 起動時キャッシュ率履歴記憶部
２０，２０Ａ〜２０Ｎ ＤＮＳキャッシュサーバ
２１ 算出部
３０ ＤＮＳクライアント
４０ ＤＮＳ権威サーバ

Claims (7)

1. クライアント装置からのクエリ要求を複数のキャッシュサーバのうちのいずれかのキャッシュサーバに転送する負荷分散装置と、前記クエリ要求に対応するレコードをキャッシュする複数のキャッシュサーバとを備えた負荷分散システムであって、
   各キャッシュサーバは、
   前記クエリ要求を受け付けた回数に対して、該クエリ要求に対応するレコードがキャッシュされていた回数の割合であるキャッシュヒット率を算出する算出部を備え、
   前記負荷分散装置は、
   各キャッシュサーバによって算出されたキャッシュヒット率をそれぞれ取得する取得部と、
   前記取得部によって取得された各キャッシュヒット率を比較する比較部と、
   前記比較部によって比較された結果、キャッシュヒット率の値が高いキャッシュサーバほど、前記クエリ要求の振り分け先として優先的に決定するように制御する振分制御部と、
   を備えることを特徴とする負荷分散システム。
2. クライアント装置からのクエリ要求を複数のキャッシュサーバのうちのいずれかのキャッシュサーバに転送する負荷分散装置と、前記クエリ要求に対応するレコードをキャッシュする複数のキャッシュサーバとを備えた負荷分散システムであって、
   前記負荷分散装置は、
   各キャッシュサーバについて、キャッシュサーバのクエリ要求に対する処理に関する情報を用いて、キャッシュサーバがクエリ要求を受け付けた回数に対して、該クエリ要求に対応するレコードがキャッシュされていた回数の割合であるキャッシュヒット率をそれぞれ算出する算出部と、
   前記算出部によって算出された各キャッシュヒット率を比較する比較部と、
   前記比較部によって比較された結果、キャッシュヒット率の値が高いキャッシュサーバほど、前記クエリ要求の振り分け先として優先的に決定するように制御する振分制御部と、
   を備えることを特徴とする負荷分散システム。
3. 前記算出部は、各キャッシュサーバについて、前記クエリ要求をキャッシュサーバが受け付けてから該クエリ要求に対する応答を返すまでの処理時間に基づいて、前記キャッシュヒット率を算出することを特徴とする請求項２に記載の負荷分散システム。
4. 前記算出部は、各キャッシュサーバについて、キャッシュサーバが受け付けたクエリ要求に対する応答に含まれるキャッシュの有効期限に関する情報に基づいて、前記キャッシュヒット率を算出することを特徴とする請求項２に記載の負荷分散システム。
5. 前記振分制御部は、前記キャッシュサーバが起動された直後の場合には、前記算出部によって算出されたキャッシュヒット率に代えて、過去の履歴に基づくキャッシュヒット率を用いて、前記クエリ要求の振分先を制御することを特徴とする請求項２〜４のいずれか一つに記載の負荷分散システム。
6. クライアント装置からのクエリ要求を複数のキャッシュサーバのうちのいずれかのキャッシュサーバに転送する負荷分散装置で実行される負荷分散方法であって、
   各キャッシュサーバによって算出されたキャッシュヒット率をそれぞれ取得する取得工程と、
   前記取得工程によって取得された各キャッシュヒット率を比較する比較工程と、
   前記比較工程によって比較された結果、キャッシュヒット率の値が高いキャッシュサーバほど、前記クエリ要求の振り分け先として優先的に決定するように制御する振分制御工程と、
   を含んだことを特徴とする負荷分散方法。
7. クライアント装置からのクエリ要求を複数のキャッシュサーバのうちのいずれかのキャッシュサーバに転送する負荷分散装置で実行される負荷分散方法であって、
   各キャッシュサーバについて、キャッシュサーバのクエリ要求に対する処理に関する情報を用いて、キャッシュサーバがクエリ要求を受け付けた回数に対して、該クエリ要求に対応するレコードがキャッシュされていた回数の割合であるキャッシュヒット率を算出する算出工程と、
   前記算出工程によって算出された各キャッシュヒット率を比較する比較工程と、
   前記比較工程によって比較された結果、キャッシュヒット率の値が高いキャッシュサーバほど、前記クエリ要求の振り分け先として優先的に決定するように制御する振分制御工程と、
   を含んだことを特徴とする負荷分散方法。

Images