(57)【要約】【課題】呼出元（クライアント）および呼出先（原本データの保存サーバ）のクラスタ構成を互いに隠蔽したまま、キャッシュデータの情報の更新を通知し合うことを可能にするデータキャッシュシステムを提供する。【解決手段】クラスタを構成する各サーバ１は、キャッシュ対象のデータの保存管理を行うキャッシュマネージャを備える。キャッシュマネージャは、キャッシュ対象のデータについて、参照要求を受信すると、自身の記憶部に当該データを記憶していない場合に、そのデータの原本データを記憶するクラスタに対する要求メッセージを用いてデータの取得要求を送信する。そして、キャッシュマネージャは、データkeyを用いた所定の振り分け手法により特定された、原本データを記憶し、かつ、書き込み権限を持つ他のキャッシュマネージャから、読み出し権限とともに当該データを受信し記憶部に記憶して出力する。【選択図】図１１
2014052928.tif 000002
【特許請求の範囲】
【請求項１】
データをキャッシュデータとして記憶する複数のサーバがクラスタを構成するクライアントクラスタと、前記キャッシュデータの原本の前記データを記憶する複数のサーバがクラスタを構成する原本データクラスタとがネットワークを介して接続されるデータキャッシュシステムであって、
前記クライアントクラスタが備えるサーバである第１のサーバ、および、前記原本データクラスタが備えるサーバである第２のサーバ、それぞれは、
（１）前記データに固有な識別子および当該データの原本データを保存する前記原本データクラスタのアドレスで構成されるデータkeyと、前記データの読み出し処理および書き込み処理を実行するキャッシュマネージャに固有な識別子および当該キャッシュマネージャが属する前記クライアントクラスタまたは前記原本データクラスタを示すクラスタのアドレスで構成されるキャッシュマネージャkeyを用いて、前記データの読み出し権限および書き込み権限を持つキャッシュマネージャが格納されるメタデータと、が付された前記データ、および
（２）前記データkeyと、各クラスタ内のサーバに設定された複数のキャッシュマネージャそれぞれの固有な識別子とを対応付けたキャッシュデータ管理情報、を記憶する記憶部と、
前記データに付されたデータkeyを抽出し、前記キャッシュデータ管理情報を参照して、当該データに対応する前記キャッシュマネージャを決定する振り分け処理部と、
前記キャッシュマネージャと、を備え、
前記第１のサーバのキャッシュマネージャは、
前記データの参照要求を受信した場合に、自身の前記記憶部に当該データを記憶しているか否かを、前記参照要求に付された前記データkeyを用いて探索し、前記データを記憶していない場合に、当該データkeyから前記原本データクラスタのアドレスを抽出し、当該データの前記データkeyおよび当該キャッシュマネージャの前記キャッシュマネージャkeyを付した取得要求を前記原本データクラスタへの第１の要求メッセージに含めて送信し、
前記第２のサーバの振り分け処理部は、受信した前記第１の要求メッセージから前記データkeyを抽出し、前記データに対応する原本データを記憶する前記キャッシュマネージャを、前記キャッシュデータ管理情報を参照して決定し、前記決定したキャッシュマネージャに前記第１の要求メッセージを送信し、
前記第１の要求メッセージを受信した前記第２のサーバのキャッシュマネージャは、前記データの前記メタデータを参照し、自身に書き込み権限がある場合に、前記第１の要求メッセージから前記キャッシュマネージャkeyを抽出し、当該データのメタデータの読み出し権限に前記抽出したキャッシュマネージャkeyを付した上で、当該キャッシュマネージャkeyから前記クライアントクラスタのアドレスを抽出し、前記データを前記第１のサーバのキャッシュマネージャに送信し、
前記第１のサーバのキャッシュマネージャは、前記データを受信して自身の記憶部に記憶し、当該データを出力すること
を特徴とするデータキャッシュシステム。
【請求項２】
前記第１の要求メッセージを受信した前記第２のサーバのキャッシュマネージャは、前記データの前記メタデータを参照し、自身に書き込み権限がない場合に、前記書き込み権限を持つキャッシュマネージャを抽出し、前記抽出した書き込み権限を持つキャッシュマネージャに前記第１の要求メッセージを送信すること
を特徴とする請求項１に記載のデータキャッシュシステム。
【請求項３】
前記第１のサーバのキャッシュマネージャは、
前記データの更新要求を受信した場合に、自身の前記記憶部に当該データを記憶しているか否かを、前記更新要求に付された前記データkeyを用いて探索し、前記データを記憶していないか、記憶していても前記メタデータを参照し自身が書き込み権限を持たないときに、当該データkeyから前記原本データクラスタのアドレスを抽出し、当該データの前記データkeyおよび当該キャッシュマネージャの前記キャッシュマネージャkeyを付した更新要求を前記原本データクラスタへの第２の要求メッセージに含めて送信し、
前記第２のサーバの振り分け処理部は、受信した前記第２の要求メッセージから前記データkeyを抽出し、前記データに対応する原本データを記憶する前記キャッシュマネージャを、前記キャッシュデータ管理情報を参照して決定し、前記決定したキャッシュマネージャに前記第２の要求メッセージを送信し、
前記第２の要求メッセージを受信した前記第２のサーバのキャッシュマネージャは、前記データの前記メタデータを参照し、自身に書き込み権限がある場合に、前記データを更新し、前記第２の要求メッセージから前記キャッシュマネージャkeyを抽出し、前記メタデータの読み出し権限に前記抽出したキャッシュマネージャkeyを付した上で、当該キャッシュマネージャkeyから前記クライアントクラスタのアドレスを抽出し、更新した前記データを前記第１のサーバのキャッシュマネージャに送信し、
前記第１のサーバのキャッシュマネージャは、更新した前記データを受信して自身の記憶部に記憶し、当該データを出力すること
を特徴とする請求項１または請求項２に記載のデータキャッシュシステム。
【請求項４】
前記第２の要求メッセージを受信した前記第２のサーバのキャッシュマネージャは、前記データの前記メタデータを参照し、自身に書き込み権限がない場合に、前記書き込み権限を持つキャッシュマネージャを抽出し、前記抽出した書き込み権限を持つキャッシュマネージャに前記第２の要求メッセージを送信すること
を特徴とする請求項３に記載のデータキャッシュシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＣＰＵ（Central Processing Unit）内のＬ１（level 1）／Ｌ２（level 2）キャッシュや、ＣＰＵ−メモリ間に階層的に設置されるキャッシュ等の所謂キャッシュ一般の技術分野に属し、また、ＮＷ（Network）を介してキャッシュ機構が情報の送受信を実行するため、Ｗｅｂ上のＨＴＴＰ（HyperText Transfer Protocol）データ等のキャッシュ技術の分野にも属する。さらに、キャッシュ機構をクラスタ構成にすることを前提としているため、分散データベースやMapReduce等の分散処理技術の分野にも属する。
【背景技術】
【０００２】
従来からＣＰＵ内のＬ１／Ｌ２キャッシュにおいて、Read/Writeキャッシュ技術が存在していたが、近年Multi-CPUやMulti-Core化が普及するようになったため、複数のキャッシュ主体が存在するようになり、ＭＥＳＩプロトコル（非特許文献１参照）をベースとした様々なアルゴリズムが提案されてきた。
【０００３】
しかし、ＣＰＵ側のキャッシュ機構は、バススヌープ（bus snoop）監視を基にした更新検知を前提としており、ＮＷ環境においてそのままでは適用できない。何処かの特定サーバ等に更新通知を集め、それを監視することも想定されるが、容易にボトルネックとなるため現実的でないという問題があった。
【０００４】
このため、ＮＷ環境におけるキャッシュ機構では、ＤＮＳ（Domain Name System）等のように、ＴＴＬ（Time To Live）値による寿命内はクライアント側で持っている情報をそのまま使用することで、サーバ側の負荷を低減可能とすると同時に応答時間も大幅に短縮可能とする方式、または、ＨＴＭＬ（HyperText Markup Language）データ取得の際のように、データに変更がない場合には、Not Modifiedを受け取り、クライアント側で持っているデータをそのまま使用することで、サーバ側の負荷を低減可能とする方式、が一般的に利用されてきた。
【０００５】
しかしながら、ＴＴＬ値を利用したキャッシュ機構では、クライアント側で持っている情報を、ＴＴＬ値の寿命まで更新しないことは更新反映の契機に制限を加えることになり、一方、ＴＴＬ値の寿命の途中で更新を実行すると、一貫性の維持を犠牲にせざるを得ないという問題があった。また、Not Modified応答に関しては、確かにデータサイズが数十ＭＢ程度の大きなデータの場合は、サーバ負荷を軽減する効果があるが、通信処理のように扱うデータサイズが数ｋＢ程度の小さなデータの場合は効果が小さい上、ＮＷを介して応答自体は返すことになるため、応答時間はほとんど短縮できないという問題があった。
【０００６】
これに対し、JBossCache（非特許文献２参照）の技術では、クライアントのアプリケーションで専用のキャッシュインスタンスを保持し、そのアプリケーションにおいてキャッシュインスタンス経由でデータが更新された際に、このキャッシュインスタンスが他のクライアントのキャッシュインスタンスに自動的に更新通知を実行することで、ＣＰＵでのキャッシュコヒーレンスに近い挙動を実現することが可能となる。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】T.Suh, D.M.Blough, et al.,“Supporting cache coherence in heterogeneous multiprocessor systems”，Design, Automation and Test in Europe Conference and Exhibition 2004, 1530-1591/04，IEEE
【非特許文献２】“JBossCache”，［online］，［平成24年8月24日検索］，インターネット<ＵＲＬ：http://www.jboss.org/jbosscache/>
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、JBossCacheのような機構では、クライアントにデータが固定的に割り当てられている。これに対し、本発明では、クライアント側が複数のサーバからなるクラスタ構成であり、サーバの故障や増設に伴ってデータの割り当て先が変更されるような方式を前提としており、その場合、以下のような問題（１）および（２）がある。
（１）クラスタ自身がＮＡＴ（Network Address Translation）等で内部のサーバを隠蔽していることが多いため、外部からクラスタ内部のサーバへ更新通知を送信しにくい。
この点に関し、キャッシュデータを取得するために接続した際に張ったセッション（穴）を継続しておき、そのセッション（穴）を流用することが想定される。しかしながら、この方式では、クライアント側のクラスタ構成がサーバの故障や増設で変化し、セッションが切断された場合に対応することができない。また、キャッシュデータの呼出先となるクラスタが同様に変化した際のセッション切断の場合も、更新通知のための穴が消失してしまうため、対応することができない。
（２）クラスタ自体の内部で、故障や増設等の原因でサーバの構成が変化してしまうと、参照や更新対象のデータが他のサーバに移動してしまい、移動先の正しい保存先に参照要求や更新通知を送信することが困難になる。
【０００９】
このような背景に鑑みて本発明がなされたのであり、本発明は、呼出元（クライアント）および呼出先（原本データの保存サーバ）のクラスタ構成を互いに隠蔽したまま、キャッシュデータの情報の更新を通知し合うことが可能となるデータキャッシュシステムを提供することを課題とする。
【課題を解決するための手段】
【００１０】
前記した課題を解決するため、請求項１に記載の発明は、データをキャッシュデータとして記憶する複数のサーバがクラスタを構成するクライアントクラスタと、前記キャッシュデータの原本の前記データを記憶する複数のサーバがクラスタを構成する原本データクラスタとがネットワークを介して接続されるデータキャッシュシステムであって、前記クライアントクラスタが備えるサーバである第１のサーバ、および、前記原本データクラスタが備えるサーバである第２のサーバ、それぞれが、（１）前記データに固有な識別子および当該データの原本データを保存する前記原本データクラスタのアドレスで構成されるデータkeyと、前記データの読み出し処理および書き込み処理を実行するキャッシュマネージャに固有な識別子および当該キャッシュマネージャが属する前記クライアントクラスタまたは前記原本データクラスタを示すクラスタのアドレスで構成されるキャッシュマネージャkeyを用いて、前記データの読み出し権限および書き込み権限を持つキャッシュマネージャが格納されるメタデータと、が付された前記データ、および（２）前記データkeyと、各クラスタ内のサーバに設定された複数のキャッシュマネージャそれぞれの固有な識別子とを対応付けたキャッシュデータ管理情報、を記憶する記憶部と、前記データに付されたデータkeyを抽出し、前記キャッシュデータ管理情報を参照して、当該データに対応する前記キャッシュマネージャを決定する振り分け処理部と、前記キャッシュマネージャと、を備え、前記第１のサーバのキャッシュマネージャが、前記データの参照要求を受信した場合に、自身の前記記憶部に当該データを記憶しているか否かを、前記参照要求に付された前記データkeyを用いて探索し、前記データを記憶していない場合に、当該データkeyから前記原本データクラスタのアドレスを抽出し、当該データの前記データkeyおよび当該キャッシュマネージャの前記キャッシュマネージャkeyを付した取得要求を前記原本データクラスタへの第１の要求メッセージに含めて送信し、前記第２のサーバの振り分け処理部は、受信した前記第１の要求メッセージから前記データkeyを抽出し、前記データに対応する原本データを記憶する前記キャッシュマネージャを、前記キャッシュデータ管理情報を参照して決定し、前記決定したキャッシュマネージャに前記第１の要求メッセージを送信し、前記第１の要求メッセージを受信した前記第２のサーバのキャッシュマネージャは、前記データの前記メタデータを参照し、自身に書き込み権限がある場合に、前記第１の要求メッセージから前記キャッシュマネージャkeyを抽出し、当該データのメタデータの読み出し権限に前記抽出したキャッシュマネージャkeyを付した上で、当該キャッシュマネージャkeyから前記クライアントクラスタのアドレスを抽出し、前記データを前記第１のサーバのキャッシュマネージャに送信し、前記第１のサーバのキャッシュマネージャは、前記データを受信して自身の記憶部に記憶し、当該データを出力することを特徴とするデータキャッシュシステムとした。
【００１１】
このようにすることで、クライアントクラスタが備える第１のサーバのキャッシュマネージャが、参照要求を受けたデータを記憶していない場合に、原本データクラスタが備える第２のサーバの、当該データの原本データを記憶し、かつ、書き込み権限を持つキャッシュマネージャから、読み出し権限を得た上でそのデータを受信し、自身の記憶部に記憶することができる。
このとき、クライアントクラスタが備える第１のサーバは、原本データクラスタのアドレス宛に第１の要求メッセージを送信すればよく、原本データクラスタ内の第２のサーバの構成は隠蔽されたままでよい。第１の要求メッセージを受信した第２のサーバの振り分け処理部が、データkeyを用いて原本データを記憶するキャッシュマネージャを決定し、決定したキャッシュマネージャに第１の要求メッセージを送信することにより参照要求の処理を実行することができる。
【００１２】
請求項２に記載の発明は、前記第１の要求メッセージを受信した前記第２のサーバのキャッシュマネージャは、前記データの前記メタデータを参照し、自身に書き込み権限がない場合に、前記書き込み権限を持つキャッシュマネージャを抽出し、前記抽出した書き込み権限を持つキャッシュマネージャに前記第１の要求メッセージを送信することを特徴とする請求項１に記載のデータキャッシュシステムとした。
【００１３】
このようにすることで、原本データを記憶するキャッシュマネージャが書き込み権限を持たない場合に、メタデータを参照し、書き込み権限を持つ他のキャッシュマネージャに第１の要求メッセージを送信し、参照要求の処理を実行させることができる。
【００１４】
請求項３に記載の発明は、前記第１のサーバのキャッシュマネージャが、前記データの更新要求を受信した場合に、自身の前記記憶部に当該データを記憶しているか否かを、前記更新要求に付された前記データkeyを用いて探索し、前記データを記憶していないか、記憶していても前記メタデータを参照し自身が書き込み権限を持たないときに、当該データkeyから前記原本データクラスタのアドレスを抽出し、当該データの前記データkeyおよび当該キャッシュマネージャの前記キャッシュマネージャkeyを付した更新要求を前記原本データクラスタへの第２の要求メッセージに含めて送信し、前記第２のサーバの振り分け処理部は、受信した前記第２の要求メッセージから前記データkeyを抽出し、前記データに対応する原本データを記憶する前記キャッシュマネージャを、前記キャッシュデータ管理情報を参照して決定し、前記決定したキャッシュマネージャに前記第２の要求メッセージを送信し、前記第２の要求メッセージを受信した前記第２のサーバのキャッシュマネージャは、前記データの前記メタデータを参照し、自身に書き込み権限がある場合に、前記データを更新し、前記第２の要求メッセージから前記キャッシュマネージャkeyを抽出し、前記メタデータの読み出し権限に前記抽出したキャッシュマネージャkeyを付した上で、当該キャッシュマネージャkeyから前記クライアントクラスタのアドレスを抽出し、更新した前記データを前記第１のサーバのキャッシュマネージャに送信し、前記第１のサーバのキャッシュマネージャは、更新した前記データを受信して自身の記憶部に記憶し、当該データを出力することを特徴とする請求項１または請求項２に記載のデータキャッシュシステムとした。
【００１５】
このようにすることで、クライアントクラスタが備える第１のサーバのキャッシュマネージャが、更新要求を受けたデータを記憶していない場合に、原本データクラスタが備える第２のサーバの、当該データの原本データを記憶し、かつ、書き込み権限を持つキャッシュマネージャに、更新要求を示す第２の要求メッセージを送信し、データを更新させる。そして、クライアントクラスタが備える第１のサーバのキャッシュマネージャは、読み出し権限を得た上で更新されたデータを受信し、自身の記憶部に記憶することができる。
【００１６】
請求項４に記載の発明は、前記第２の要求メッセージを受信した前記第２のサーバのキャッシュマネージャは、前記データの前記メタデータを参照し、自身に書き込み権限がない場合に、前記書き込み権限を持つキャッシュマネージャを抽出し、前記抽出した書き込み権限を持つキャッシュマネージャに前記第２の要求メッセージを送信することを特徴とする請求項３に記載のデータキャッシュシステムとした。
【００１７】
このようにすることで、原本データを記憶するキャッシュマネージャが書き込み権限を持たない場合に、メタデータを参照し、書き込み権限を持つ他のキャッシュマネージャに第２の要求メッセージを送信し、更新要求の処理を実行させることができる。
【発明の効果】
【００１８】
本発明によれば、呼出元（クライアント）および呼出先（原本データの保存サーバ）のクラスタ構成を互いに隠蔽したまま、キャッシュデータの情報の更新を通知し合うことが可能となるデータキャッシュシステムを提供することができる。
【図面の簡単な説明】
【００１９】
【図１】本実施形態に係るデータキャッシュシステムの構成例を示す図である。
【図２】本実施形態に係る原本データクラスタの構成例を示す図である。
【図３】本実施形態に係るクライアントクラスタ内のサーバが、キャッシュデータの参照要求を処理する例を示す図である。
【図４】本実施形態に係るクライアントクラスタ内のサーバが、キャッシュデータの更新要求を処理する例を示す図である。
【図５】本実施形態に係るサーバの構成例を示す機能ブロック図である。
【図６】本実施形態に係るキャッシュデータ管理情報のデータ構成を示す図である。
【図７】本実施形態に係るクライアントクラスタ内のサーバのキャッシュマネージャが、データの参照要求のリクエストを受信した場合の処理を示すフローチャートである。
【図８】本実施形態に係るクライアントクラスタ内のサーバのキャッシュマネージャが、データの更新要求のリクエストを受信した場合の処理を示すフローチャートである。
【図９】本実施形態に係るクライアントクラスタ内のサーバのキャッシュマネージャが、データの更新要求のリクエストを受信した場合の処理を示すフローチャートである。
【図１０】本実施形態に係るキャッシュマネージャが、受信メソッドを実行する処理の流れを示すフローチャートである。
【図１１】本実施形態に係るクライアントクラスタ内のサーバのキャッシュマネージャが、Read権限付きでデータを取得する例を示す図である。
【図１２】本実施形態に係るクライアントクラスタ内のサーバのキャッシュマネージャが、Write権限付きでデータを取得する例を示す図である。
【図１３】本実施形態に係るクライアントクラスタ内のサーバのキャッシュマネージャが、Write権限を持ち、データを更新する例を示す図である。
【図１４】本実施形態に係るクライアントクラスタ内のサーバのキャッシュマネージャが、データの更新要求を受信した場合に、Write権限を持つ他のキャッシュマネージャに更新を依頼する例を示す図である。
【図１５】本実施形態に係るクライアントクラスタ内のすべてのサーバに、更新通知を送信する例を示す図である。
【発明を実施するための形態】
【００２０】
次に、本発明を実施するための形態（以下、「本実施形態」という。）におけるデータキャッシュシステム１００について説明する。
【００２１】
＜システム構成＞
図１は、本実施形態に係るデータキャッシュシステム１００の構成例を示す図である。
図１に示すように、データキャッシュシステム１００は、複数のサーバ１（１ｙ：第１のサーバ）で構成され原本となるデータ（原本データ）を分散して記憶する原本データクラスタ１０と、クライアントクラスタ２０とが、ネットワークを介して接続される。クライアントクラスタ２０は、複数のサーバ１（１ｘ：第２のサーバ）によりクラスタを構成し、原本データクラスタ１０に対しリクエスト（要求情報）を送信することにより応答情報を取得する。また、クライアントクラスタ２０の各サーバ１（１ｘ）は、原本データクラスタ１０から取得した情報をキャッシュデータとして記憶する。
なお、本実施形態においては、クライアント側が、クライアントクラスタ２０であることを前提して説明するが、図１に示すように、単体サーバであるクライアント端末３０でも、同様に処理を実行することができる。このクライアント端末３０は、クライアントクラスタ２０を構成するサーバ１（１ｘ）と同様に、原本データクラスタ１０に対しリクエスト（要求情報）を送信し、取得した情報をキャッシュデータとして記憶する。
【００２２】
＜クラスタ構成＞
次に、原本データクラスタ１０およびクライアントクラスタ２０の構成例について説明する。原本データクラスタ１０およびクライアントクラスタ２０は共に、以下に示す同様の構成を備えているため、ここでは、原本データクラスタ１０を例に説明する。
【００２３】
図２は、本実施形態に係る原本データクラスタ１０の構成例を示す図である。
図２に示すように、原本データクラスタ１０は、ロードバランサＢ（Balancer：各図において「Ｂ」と表記）と、複数のディスパッチャＤ（Dispatcher：図２において「Ｄ」と表記）と、複数のプロセッサＰ（Processor：図２において「Ｐ」と表記）とを含んで構成される。
【００２４】
ロードバランサＢは、外部端末４０からリクエスト（要求情報）を取得し、それに対する応答情報を外部端末４０に送信する。また、ロードバランサＢは、ラウンドロビン等の単純なアルゴリズムに基づき、取得したリクエストを複数のディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）のいずれかに振り分ける。ここで、外部端末４０は、図１に示した、クライアントクラスタ２０を構成するサーバ１（１ｘ）やクライアント端末３０である。
【００２５】
各ディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）は、複数のプロセッサＰ（Ｐ１，Ｐ２，Ｐ３）と接続されており、ロードバランサＢから取得したリクエストを、プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）のいずれかに振り分ける。このディスパッチャＤは、入力データを解析し、所定のデータ管理アルゴリズム、例えば、コンシステントハッシュ法を適用して、データの格納先であるプロセッサＰを決定し、そのリクエストを送信する。
【００２６】
プロセッサＰは、複数のディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）に接続されており、いずれかのディスパッチャＤからリクエストを受信し、そのリクエストに従い、自身の記憶部（ローカルストレージ）に新規データを保存したり、既存データを更新したり、データの参照（取得）処理をしたりする制御を実行する。なお、このローカルストレージには、データをキャッシュとして保存するローカルキャッシュ（図５のキャッシュデータ記憶部１３１）を含む。また、以下において、特に説明なく「ローカル」と記載する場合は、ローカルキャッシュを含むローカルストレージを意味するものとする。さらに、ここでは、各データが記憶部に、ＸＭＬ（Extensible Markup Language）ファイルで保存されているものとして説明する。
【００２７】
なお、ディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）、プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）それぞれは、図２に図示した３つの装置に限定されず、複数の装置であればよい。また、図２においては、ディスパッチャＤとプロセッサＰとを別装置として記載したが、同一サーバ上で別々の機能として動作させることが可能であり、本実施形態では、ディスパッチャＤとプロセッサＰとを１つのサーバ１（クライアントクラスタ２０側のサーバ１を「サーバ１ｘ」、原本データクラスタ１０側のサーバ１を「サーバ１ｙ」）として、以下において説明する。
【００２８】
＜概要＞
本発明は、前記した問題（１）および（２）に示した技術的課題を解決するため、以下に示す技術的手段とした。
問題（１）のクライアント側のクラスタ自体がＮＡＴ等で内部のサーバ１を隠蔽している点に関しては、外部からクラスタ内のマシン（サーバ１等）にＰｕｓｈで通信可能にする必要がある。ここで、クライアントクラスタ２０は、そもそもデータを保存・管理するためのクラスタ構成をとっていることから、外部からクラスタ内部のサーバ１へリクエスト信号が到達可能な機構を備えている。その機構を流用し、リクエスト信号上でデータの参照要求や更新要求を記述することによって、外部からクラスタ内のサーバ１が、そのデータの参照要求や更新要求を受け付けられるようにする。なお、本実施形態では、後記するように、リクエストとして、ＨＴＴＰのＧＥＴメソッドやＰＵＴメソッドを利用した場合を例に説明する。
【００２９】
問題（２）のクラスタ内部で、データの保存先が移動してしまう点に関しては、クラスタで採用するデータ振り分けの構成変更に追従する必要がある。そこで、クラスタのデータの保存・管理手法を、例えば、ＫＶＳ（Key Value Store）機構とし、その振り分けアルゴリズム（例えば、コンシステントハッシュ法）を流用する。なお、ＫＶＳとは、任意に保存したデータ（値：value）に対し、対応する一意の標識（key）を設定し、keyおよびvalueをペアで保存するデータ保存・管理手法である。このようにすることで、冗長等のためクラスタ内部でデータの保存先が変更等された場合であっても、keyを指定することで、データの保存先となるサーバ１に追従することが可能となる。
【００３０】
次に、本実施形態の詳細を説明するための前提として、クライアントクラスタ２０内のサーバ１（１ｘ）によるキャッシュデータの参照処理と更新処理の主な例を、図３および図４を参照して説明する。なお、データキャッシュシステム１００内における、参照処理および更新処理の詳細な処理の流れについては、他の例も含めて、図１１〜図１５を参照して後記する。
【００３１】
図３は、クライアントクラスタ２０内の１つのサーバ１（１ｘ）が、キャッシュデータの参照要求を処理する例を示している。具体的には、サーバ１（１ｘ）において、アプリケーション（図５に示すアプリケーション処理部１１２：図３において「ＡＰＬ」と表記）から、キャッシュデータを管理するキャッシュマネージャ１１３（図５）が参照要求を受信した場合を示している。ここで、アプリケーション処理部１１２が、データの参照や更新を実行するときには、キャッシュマネージャ１１３を経由して処理が実行されるように設定される。
【００３２】
まず、サーバ１（１ｘ）のキャッシュマネージャ１１３が、アプリケーション処理部１１２からデータの参照要求を受信する（ステップＳ１０）。なお、この参照要求には、当該データを識別するためのkey（データkey）が付されている。
【００３３】
キャッシュマネージャ１１３は、参照要求を受信すると、データkeyに基づき、自身の記憶部１３（図５：ローカルキャッシュ）を探索し、当該データを記憶していれば、そのデータをアプリケーション処理部１１２に返す（ステップＳ１１）。
【００３４】
キャッシュマネージャ１１３は、自身の記憶部１３（ローカルキャッシュ）に当該データを記憶していなければ、Write権限を持つ他のキャッシュマネージャ１１３から、当該データをRead権限付きで取得する（ステップＳ１２）。そして、キャッシュマネージャ１１３は、取得したデータをアプリケーション処理部１１２に返す（ステップＳ１３）。
【００３５】
ここで、Read権限とは、データの読み出し（参照）権限であり、そのデータを参照する権限を意味し、データの書き込み等は行えない。また、Write権限とは、データの書き込み（更新）権限であり、そのデータを更新する権限を意味する。そして、キャッシュマネージャ１１３がWrite権限を備える場合は、Read権限を同時に備えており、他のキャッシュマネージャ１１３に対し、Read権限を付与したり、Write権限を移行したりすることができる。
【００３６】
また、キャッシュデータには、データ（データ値）に、そのデータのデータkeyとメタデータとが付されて記憶されており（例えば、図１１の符号１０００参照）、このメタデータには、Read権限を備えるキャッシュマネージャ１１３の識別子（例えば、「ｐ１」）を含むそのキャッシュマネージャのkey（例えば、「ｐ１＠ＸＸＸ」）と、Write権限を備えるキャッシュマネージャ１１３の識別子（例えば、「ｑ」）を含むそのキャッシュマネージャのkey（例えば、「ｑ＠ＹＹＹ」）とが記載される。なお、「ＸＸＸ」および「ＹＹＹ」は、そのクラスタの入口となるロードバランサＢのアドレス（例えば、ＩＰアドレス）であり、そのキャッシュマネージャ１１３が属するクラスタを示している。そして、Write権限を持つキャッシュマネージャ１１３は、他のキャッシュマネージャに対し、Read権限を付与したり、Write権限を移行したりする際には、このメタデータを更新する。
【００３７】
図４は、クライアントクラスタ２０内の１つのサーバ１（１ｘ）が、キャッシュデータの更新要求を処理する例を示している。具体的には、サーバ１（１ｘ）において、アプリケーション処理部１１２からキャッシュマネージャ１１３が更新要求を受信した場合を示している。
【００３８】
まず、サーバ１（１ｘ）のキャッシュマネージャ１１３が、アプリケーション処理部１１２からデータの更新要求を受信する（ステップＳ２０）。なお、この更新要求には、当該データのkey（データkey）が付されている。
【００３９】
キャッシュマネージャ１１３は、更新要求を受信すると、データkeyに基づき、自身の記憶部１３（ローカルキャッシュ）を探索し、当該データを記憶しており、当該データに付されたメタデータを参照して自身にWrite権限があれば、そのデータを更新する。そして、キャッシュマネージャ１１３は、当該データをキャッシュしている他のアプリケーション処理部１１２に対し、当該データの更新通知を送信する（ステップＳ２１）。
【００４０】
一方、キャッシュマネージャ１１３は、自身の記憶部１３（ローカルキャッシュ）に当該データを記憶していないか、記憶していてもWrite権限がなければ、当該データのWrite権限を持つ他のキャッシュマネージャ１１３に、当該データの更新要求を転送することにより、Write権限を持つ他のキャッシュマネージャ１１３に当該データを更新させる。
また、キャッシュマネージャ１１３は、自身の記憶部１３（ローカルキャッシュ）に当該データを記憶していないか、記憶していてもWrite権限がない場合であり、Write権限を自身が取得した上で当該データを更新したいときは、当該データのWrite権限を持つ他のキャッシュマネージャ１１３から、当該データをWrite権限付きで取得する（ステップＳ２２）。
そして、キャッシュマネージャ１１３は、当該データを更新し、当該データをキャッシュしている他のアプリケーション処理部１１２に対し、当該データの更新通知を送信する（ステップＳ２３）。
【００４１】
このように、Write権限を持つキャッシュマネージャ１１３が、そのデータやそのデータに付されたメタデータが更新されたとき、当該データをキャッシュしている他のアプリケーション処理部１１２に対し、更新通知を送信することとで、クラスタ内のデータのコヒーレンス（一貫性）が保たれる。
【００４２】
本実施形態に係るデータキャッシュシステムで１００では、上記のように、キャッシュ対象となるデータにデータkeyが付されており、そのデータkeyとともに、そのデータのRead権限およびWrite権限を持つキャッシュマネージャ１１３のkey（キャッシュマネージャkey）を示すメタデータが、当該データに付されてキャッシュデータとして記憶される。そして、外部からクラスタ内に参照要求や更新要求を送信する際は、既存のリクエスト信号（例えば、ＨＴＴＰのＧＥＴメソッドやＰＵＴメソッドによるリクエスト）にリクエストオプションを設定することにより、データkey、送信元や送信先のキャッシュマネージャkey、および、処理内容等を付して送信する。リクエスト信号を受信したクラスタ内のノードでは、そのリクエスト信号に付されたデータkeyまたは、キャッシュマネージャkeyに基づき、当該データを担当するノードを特定して、そのリクエスト信号を受信することができる。
【００４３】
＜サーバの構成＞
以下、本実施形態に係るクラスタ（クライアントクラスタ２０および原本データクラスタ１０）を構成するサーバ１（１ｘ，１ｙ）について具体的に説明する。図２に示したように、サーバ１は、ディスパッチャＤの機能とプロセッサＰの機能の両方を備えるものとして説明する。また、ここでは、原本データクラスタ１０を構成するサーバ１（１ｙ）、および、クライアントクラスタ２０を構成するサーバ１（１ｘ）は、同様の機能を備えるため、サーバ１として説明する。
【００４４】
図５は、本実施形態に係るサーバ１の構成例を示す機能ブロック図である。
サーバ１は、図２に示したように、ロードバランサＢと通信可能に接続されると共に、クラスタを構成する自身以外の他のサーバ１とも通信可能に接続される。そして、外部からロードバランサＢを介して、参照要求や更新要求等のリクエストを受信する。
このサーバ１は、図５に示すように、制御部１１と、入出力部１２と、記憶部１３とを含んで構成される。
【００４５】
入出力部１２は、ロードバランサＢや、自身以外の他のサーバ１との間の情報の入出力を行う。また、この入出力部１２は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェースとから構成される。
【００４６】
制御部１１は、サーバ１全体の制御を司り、情報受信部１１１、アプリケーション処理部１１２、キャッシュマネージャ１１３、振り分け処理部１１４、および、情報送信部１１５を含んで構成される。なお、この制御部１１は、例えば、サーバ１の記憶部１３に格納されたプログラムをＣＰＵ（Central Processing Unit）がＲＡＭ（Random Access Memory）等に展開し実行することで実現される。
【００４７】
情報受信部１１１は、入出力部１２を介して、ロードバランサＢやクラスタ内の他のサーバ１からの情報を受信する。
【００４８】
アプリケーション処理部１１２は、クライアントにサービスを提供等するためのアプリケーションの処理を実行する。このアプリケーション処理部１１２は、記憶部１３に記憶されたキャッシュデータを利用する際に、データの参照要求や更新要求等のリクエストをキャッシュマネージャ１１３に出力する。なお、このリクエストには、そのデータを一意に識別するためのkey（データkey）が含まれる。
【００４９】
キャッシュマネージャ１１３は、キャッシュデータに関する処理の全般の制御を実行する。
具体的には、キャッシュマネージャ１１３は、アプリケーション処理部１１２からデータの参照要求を受信した場合において、自身の記憶部１３（キャッシュデータ記憶部１３１）にそのデータを記憶しているときは、当該データをアプリケーション処理部１１２に返す。
一方、キャッシュマネージャ１１３は、自身の記憶部１３（キャッシュデータ記憶部１３１）にそのデータを記憶していないときは、当該データのWrite権限を持つ他のキャッシュマネージャ１１３から、Read権限付きでデータを取得し、記憶部１３（キャッシュデータ記憶部１３１）に記憶した上で、当該データをアプリケーション処理部１１２に返す。なお、この処理の詳細は、図１１を参照して後記する。
【００５０】
また、キャッシュマネージャ１１３は、アプリケーション処理部１１２からデータの更新要求を受信した場合において、自身の記憶部１３（キャッシュデータ記憶部１３１）にそのデータを記憶しており、かつ、そのデータについてWrite権限を持つときには、そのデータを更新要求に基づき新たなデータに更新する。
一方、キャッシュマネージャ１１３は、自身の記憶部１３（キャッシュデータ記憶部１３１）にそのデータを記憶していないとき、または、そのデータを記憶していても（つまり、Read権限を持っていても）、Write権限を持たないときは、Write権限を持つ他のサーバ１のアプリケーション処理部１１２からWrite権限の付与を受けてデータを更新する。このとき、キャッシュマネージャ１１３は、Write権限を持つ他のサーバにデータの更新を依頼することによりそのデータを更新させることもできる。なお、この処理の詳細は、図１３および図１４を参照して後記する。
【００５１】
このキャッシュマネージャ１１３は、自身がそのデータを記憶部１３（キャッシュデータ記憶部１３１）に記憶しているか否かを、受信したリクエストに付されたデータkeyを用いて探索する。また、そのデータのwrite権限を持っているか否かを、そのデータに付されたメタデータを参照して判定する。なお、このキャッシュマネージャ１１３の処理の詳細は、図７〜図１０を参照して後記する。
【００５２】
また、ここで、本実施形態におけるデータkeyは、例えば「Ａ＠ＹＹＹ」のように記述される。ここで「Ａ」は、そのデータに固有な識別子（データ識別子）である。また、「ＹＹＹ」は、そのデータの原本データが保存されるクラスタの入口（外部からの送信先）となるロードバランサＢのアドレスである。このように、データkeyは、データ識別子と原本データクラスタ１０に固有なロードバランサＢのアドレスと組み合わせからなるものとする。よって、データkeyの情報として、ロードバランサＢ（アドレス：「ＹＹＹ」）を含む原本データクラスタ１０を構成する複数のサーバ１（１ｙ）のうちのいずれかのサーバに、そのデータ「Ａ」の原本データが必ず記憶されていることを意味する。
【００５３】
また、キャッシュマネージャ１１３は、自身が属するクラスタ以外の他のクラスタにリクエストを送信するときは、少なくとも、キャッシュマネージャのkey（キャッシュマネージャkey）と、データkeyとを含めたリクエストとして送信する。本実施形態では、ＨＴＴＰのＧＥＴメソッドとＰＵＴメソッドにリクエストオプションを設定した例として、後記において説明するが、同様のリクエストオプションを設定できるものであれば、ＨＴＴＰに限定されるものではない。
【００５４】
振り分け処理部１１４は、外部から情報受信部１１１が、リクエストを受信した際に、そのリクエストに付されたデータkeyに対し、ＫＶＳ機構を用いた所定の振り分けアルゴリズム（ここでは、コンシステントハッシュ法とする。）に基づき、そのデータの保存や管理を担当するサーバ１（具体的には、そのサーバ１のキャッシュマネージャ１１３）を決定する。
【００５５】
なお、ここで各サーバ１のキャッシュマネージャ１１３には、前記したように、そのクラスタ内で固有の識別子が付されており、コンシステントハッシュ法では、データkeyとキャッシュマネージャ１１３の識別子の双方を、ハッシュ関数にかけた値（ハッシュ値）を求める。そして、閉じたハッシュ空間上にキャッシュマネージャ１１３の識別子それぞれをハッシュ関数にかけた値（ハッシュ値）を配置し、リクエストに付されたデータkeyをハッシュ関数にかけた値（ハッシュ値）が、例えばハッシュ空間上で時計まわりに最初に出合ったキャッシュマネージャ１１３が、そのデータを担当するものとする。
【００５６】
具体的には、各サーバ１は、クラスタ内で共通の情報として記憶部１３内に、キャッシュデータ管理情報１３２を備え、振り分け処理部１１４は、このキャッシュデータ管理情報１３２に基づき、そのデータを管理するキャッシュマネージャ１１３を決定したり、そのキャッシュマネージャ１１３を備えるサーバのアドレスを知ることができる。
【００５７】
図６は、本実施形態に係るキャッシュデータ管理情報１３２のデータ構成を示す図である。図６に示すように、キャッシュデータ管理情報１３２は、キャッシュマネージャ１１３の識別子と、その識別子をハッシュ関数にかけた値であるハッシュ値と、当該キャッシュマネージャ１１３が備わるサーバのアドレスとが格納される。
【００５８】
例えば、図６においては、データkeyをハッシュ関数にかけた値（ハッシュ値）が、「０」から「５６」であるデータについては、第１行目が示す、アドレスが「ｘｘ０」のサーバのキャッシュマネージャ１１３（キャッシュマネージャの識別子「ｐ０」）が担当する。同様に、データkeyをハッシュ関数にかけた値（ハッシュ値）が、「５６」に１を加えた「５７」から「１７２」であるデータについては、第２行目が示す、アドレスが「ｘｘ１」のサーバのキャッシュマネージャ１１３（キャッシュマネージャの識別子「ｐ１」）が担当する。
このようにして、このキャッシュデータ管理情報１３２に基づき、データとそのデータを担当するキャッシュマネージャ１１３とが対応付けられる。
なお、本実施形態においては、１つのサーバ１に１つのキャッシュマネージャ１１３が存在するとして説明するが、１つのサーバ１に複数のキャッシュマネージャ１１３が存在するように設定することも可能である。また、この振り分け処理部１１４が備える機能が、図２に示すディスパッチャＤの機能に相当する。
【００５９】
図５に戻り、情報送信部１１５は、キャッシュマネージャ１１３等により生成された情報（参照要求や更新要求等のリクエストやその応答情報）を、自身以外の他のサーバ１やロードバランサＢに、入出力部１２を介して送信する。
【００６０】
記憶部１３は、ＲＡＭや、ハードディスク、フラッシュメモリ等の記憶装置からなり、前記したキャッシュデータ管理情報１３２（図６）等を記憶する。また、記憶部１３内には、ＲＡＭ等にデータをキャッシュデータとして記憶する領域としてキャッシュデータ記憶部１３１（ローカルキャッシュともいう。）が備えられる。
【００６１】
＜データキャッシュシステムの処理の流れ＞
次に、本実施形態に係るデータキャッシュシステム１００の処理の流れについて説明する。
まず、図７〜図１０を参照して、サーバ１のキャッシュマネージャ１１３の処理について詳細に説明し、その後、図１１〜図１５を参照して、データキャッシュシステム１００の全体の処理の流れについて説明する。
【００６２】
≪キャッシュマネージャの処理≫
［キャッシュデータの参照処理］
図７は、本実施形態に係るクライアントクラスタ２０のサーバ１（１ｘ）のキャッシュマネージャ１１３が、アプリケーション処理部１１２からデータの参照要求のリクエストを受信した場合の処理の示すフローチャートである。
【００６３】
まず、キャッシュマネージャ１１３（識別子「ｐ」）は、アプリケーション処理部１１２から、データの参照要求を受信する（ステップＳ１００）。図７に示した、「p.get(key,cachetype)」は、キャッシュマネージャ１１３（キャッシュマネージャの識別子「ｐ」）が、データの「key」（データkey）と、「cachetype」とを引数として、データの参照要求としてgetメソッドを実行することを意味する。なお、「cachetype」には、Read権限（参照権限）を要求する「Read cache」か、更新権限を要求する「Write cache」かが付される。
【００６４】
次に、キャッシュマネージャ１１３は、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）から、key（データkey）、ここでは、例えば「Ａ＠ＹＹＹ」を用いて、データの取得処理を実行する（ステップＳ１０１）。
【００６５】
ここで、キャッシュマネージャ１１３は、キャッシュデータ記憶部１３１（ローカルキャッシュ）に該当データがない、若しくは、該当データが無効化されているかを判定する（ステップＳ１０２）。そして、キャッシュマネージャ１１３は、該当データがない若しくは無効化に該当しない場合（ステップＳ１０２→false）、つまり、該当データが見つかった場合には、そのデータ（ここでは、「ｖ」）を、アプリケーション処理部１１２に返し（ステップＳ１０３）、処理を終える。
一方、キャッシュマネージャ１１３は、該当データがない若しくは無効化に該当する場合には（ステップＳ１０２→true）、次のステップＳ１０４に進む。
【００６６】
ステップＳ１０４において、キャッシュマネージャ１１３は、自サーバがkey（データkey）の本来のサーバか否かを判定する。ここで、本来のサーバとは、データkey(Ａ＠ＹＹＹ)のうち「ＹＹＹ」で示される、クラスタの入口（外部からの送信先）となるロードバランサＢのアドレスを含む原本データクラスタ１０を構成するサーバ１（１ｙ）であることを意味する。そして、キャッシュマネージャ１１３は、keyの本来のサーバである場合には（ステップＳ１０４→true）、データの取得が不可能であることを示す「null」を、アプリケーション処理部１１２に返し（ステップＳ１０５）、処理を終える。
一方、キャッシュマネージャ１１３は、keyの本来のサーバでない場合には（ステップＳ１０４→false）、次のステップＳ１０６に進む。
【００６７】
ステップＳ１０６において、キャッシュマネージャ１１３は、その参照要求のcachetypeを判定する。そして、キャッシュマネージャ１１３は、cachetypeがRead cacheであれば、ステップＳ１０７に進み、cachetypeがWrite cacheであれば、ステップＳ１０８に進む。
【００６８】
ステップＳ１０７において、キャッシュマネージャ１１３は、keyの本来のサーバに、追加でこのサーバ１（自サーバ）がRead権限を持つようにすること（「ADD_R」メソッド）を通知する。つまり、キャッシュマネージャ１１３は、そのデータのメタデータのRead権限に自身のキャッシュマネージャkeyを追加で記載（Read権限を付与）した上で、そのデータを送信するように、keyの本来のサーバに依頼する。
なお、キャッシュマネージャ１１３は、原本データクラスタ１０を構成するサーバ１（１ｙ）に向けてこの通知をするが、宛先は、原本データクラスタ１０のロードバランサＢのアドレス（ＹＹＹ）となる。具体的は、キャッシュマネージャ１１３は、sendメソッドの「v=p.send(ADD_R,key,key.location(),null)」を実行することにより、例えば、ＨＴＴＰのＧＥＴメソッドによるリクエストとして、
http://YYY/A.xml?sourcecachemanager=p@XXX&cachetype=read
を実行する。
なお、このリクエストに示される、「YYY」は、原本データクラスタ１０のロードバランサＢのアドレス（ＹＹＹ）であり、「A」は、データ識別子であり、「?」マーク以後の部分がリクエストオプションとなる。このリクエストオプションの部分に、送信元となるキャッシュマネージャ１１３のキャッシュマネージャkey（「sourcecachemanager=p@XXX」）や、処理内容としてRead権限を要求すること（「cachetype=read」）等が記載される。
【００６９】
一方、ステップＳ１０８において、キャッシュマネージャ１１３は、keyの本来のサーバに、このサーバ１（自サーバ）がWrite権限を持つようにすること（「ADD_W」メソッド）を通知する。つまり、キャッシュマネージャ１１３は、keyの本来のサーバに、そのデータのメタデータのWrite権限を自サーバに書き換えさせた上で（Write権限付きで）、そのデータを送信するように依頼する。
具体的には、キャッシュマネージャ１１３は、sendメソッドの「v=p.send(ADD_W,key,key.location(),null)」を実行することにより、例えば、ＨＴＴＰのＧＥＴメソッドによるリクエストとして、
http://YYY/A.xml?sourcecachemanager=p@XXX&cachetype=write
を実行する。
【００７０】
ステップＳ１０７およびステップＳ１０８の処理を終えると、ステップＳ１０９において、キャッシュマネージャ１１３は、Write権限を持つサーバ１から、該当データを受信する。そして、キャッシュマネージャ１１３は、そのデータを、キャッシュデータ記憶部１３１（ローカルキャッシュ）に記憶する（「p.put_local(key,value=v)」）。
【００７１】
続いて、キャッシュマネージャ１１３は、該当データが見つかったとして、そのデータ（ここでは、「ｖ」）を、アプリケーション処理部１１２に返し（ステップＳ１１０）、処理を終える。
【００７２】
［キャッシュデータの更新処理］
図８および図９は、本実施形態に係るクライアントクラスタ２０のサーバ１（１ｘ）のキャッシュマネージャ１１３が、アプリケーション処理部１１２からデータ（ここではデータ「w」）の更新要求のリクエストを受信した場合の処理を示すフローチャートである。
【００７３】
まず、キャッシュマネージャ１１３（識別子「ｐ」）は、アプリケーション処理部１１２から、データの更新要求を受信する（ステップＳ２００）。この更新要求により、キャッシュマネージャ１１３は、データの「key」（データkey）と、「value」（更新後のデータ）とを引数としてputメソッドを実行する（p.put(key,value)）。
【００７４】
次のステップＳ２０１において、キャッシュマネージャ１１３は、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）から、key（データkey）を用いて、データの取得処理を実行する（w=p.get_local(key)）。
【００７５】
ここで、キャッシュマネージャ１１３は、キャッシュデータ記憶部１３１（ローカルキャッシュ）に該当データがない、若しくは、該当データが無効化されているかを判定する（ステップＳ２０２）。そして、キャッシュマネージャ１１３は、該当データがない若しくは無効化に該当しない場合（ステップＳ２０２→false）、つまり、該当データが見つかった場合には、ステップＳ２０３に進む。
【００７６】
ステップＳ２０３において、キャッシュマネージャ１１３は、該当データに付されたメタデータからWrite権限を持つ記憶場所を取得する。なお、ここで、Write権限を持つ記憶場所とは、例えば、図１１に示すメタデータ（符号１０００参照）においては、<Write cache＞タグのデータ「ｑ＠ＹＹＹ」を意味する。つまり、ロードバランサＢのアドレス「ＹＹＹ」で示されるクラスタ（原本データクラスタ１０）のサーバ１（１ｙ）のうち、キャッシュマネージャの識別子が「ｑ」のキャッシュマネージャ１１３がWrite権限を持つことを示している。なお、前記したように「ｑ＠ＹＹＹ」は、キャッシュマネージャ１１３のkeyとして設定したものである。
【００７７】
次に、自身がWrite権限を持つキャッシュマネージャ１１３か否かを判定する（ステップＳ２０４）。そして、自身がWrite権限を持つキャッシュマネージャ１１３であれば（ステップＳ２０４→true）、次のステップＳ２０８に進む。一方、自身がWrite権限を持つキャッシュマネージャ１１３でなければ（ステップＳ２０４→false）、ステップＳ２０５に進み、Write権限を持つキャッシュマネージャ１１３に更新を依頼する（p.send(PUT,key,q,value)）。
【００７８】
一方、ステップＳ２０２において、キャッシュデータ記憶部１３１（ローカルキャッシュ）において該当データが見つからなかった場合は（ステップＳ２０２→true）、自サーバがkey（データkey）の本来のサーバか否かを判定する（ステップＳ２０６）。そして、キャッシュマネージャ１１３は、keyの本来のサーバでなければ（ステップＳ２０６→false）、ステップＳ２０７において、keyの本来のサーバに、更新を依頼する（p.send(PUT,key,key.location(),value）)。なお、キャッシュマネージャ１１３は、原本データクラスタ１０を構成するサーバ１（１ｙ）に向けてこの依頼をするが、宛先は、原本データクラスタ１０のロードバランサＢのアドレス（ＹＹＹ）となる。
一方、キャッシュマネージャ１１３は、keyの本来のサーバであれば（ステップＳ２０６→true）、ステップＳ２０８に進む。
【００７９】
ステップＳ２０８において、キャッシュマネージャ１１３は、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）に記憶されているデータ（キャッシュデータ）を更新する（p.put_local(key,value)）。なお、このとき、キャッシュマネージャ１１３は、そのデータのメタデータについても変更が必要な場合は更新する。
【００８０】
次に、図９に進む。図９では、図８のステップＳ２０８において、データが更新されたため、キャッシュマネージャ１１３は、他のキャッシュマネージャ１１３が記憶する更新前のデータを無効化する処理と、更新後のデータについてRead権限およびWrite権限を持つ他のキャッシュマネージャ１１３に更新データを送信する処理とを実行する。
【００８１】
まず、ステップＳ２０９において、キャッシュマネージャ１１３は、当該データの更新前のメタデータからRead権限を持つキャッシュマネージャ１１３をすべて取得し、リストを生成する。
【００８２】
続いて、キャッシュマネージャ１１３は、更新前のデータを無効化するための設定を行う（ステップＳ２１０）、つまり、無効通知の生成を行う。
【００８３】
そして、キャッシュマネージャ１１３は、ステップＳ２０９で生成したリストのすべてのキャッシュマネージャ１１３を処理したか否かを判定する（ステップＳ２１１）。ここで、Read権限を持つすべてのキャッシュマネージャ１１３の処理を終えていない場合には（ステップＳ２１１→false）、次のステップＳ２１２に進む。
【００８４】
キャッシュマネージャ１１３は、リストのｉ番目（初期値ｉ＝１）のキャッシュマネージャ１１３の記憶場所ｒ（メタデータの<Read cache>タグのデータ）を設定し（ステップＳ２１２）、ステップＳ２１３において、そのキャッシュマネージャ１１３に無効通知を送信する（p.send(PUT_L,key,r,w)）。そして、キャッシュマネージャ１１３は、ステップＳ２１４において、［ｉ］に１を加えて、ステップＳ２１１に戻る。
【００８５】
キャッシュマネージャ１１３は、Read権限を持つすべてのキャッシュマネージャ１１３の処理を終えた場合は（ステップＳ２１１→true）、ステップＳ２１５に進み、更新後のメタデータからRead権限およびWrite権限を持つキャッシュマネージャ１１３をすべて取得し、リストを生成する。
【００８６】
次に、キャッシュマネージャ１１３は、ステップＳ２１５で生成したリストのすべてのキャッシュマネージャ１１３を処理したか否かを判定し（ステップＳ２１６）、すべてのキャッシュマネージャ１１３の処理を終えていない場合には（ステップＳ２１６→false）、次のステップＳ２１７に進む。
【００８７】
キャッシュマネージャ１１３は、リストのｉ番目（初期値ｉ＝１）のキャッシュマネージャ１１３の記憶場所ｒ（メタデータの<Read cache>タグと<Write cache>タグのデータ）を設定し（ステップＳ２１７）、ステップＳ２１８において、そのキャッシュマネージャ１１３に更新内容であるデータ（更新データ）を送信する（p.send(PUT_L,key,r,value)）。そして、キャッシュマネージャ１１３は、ステップＳ２１９において、［ｉ］に１を加えて、ステップＳ２１６に戻る。
【００８８】
ステップＳ２１６において、ステップＳ２１５で生成したリストのすべてのキャッシュマネージャ１１３の処理を終えた場合には（ステップＳ２１６→true）、処理を終える。
【００８９】
［キャッシュマネージャの受信メソッドの処理］
次に、あるサーバ１のキャッシュマネージャ１１３が、他のキャッシュマネージャ１１３が実行した送信（send）メソッドによる情報を受け取り、受信（receive）メソッドを実行する処理について説明する。
図１０は、本実施形態に係るキャッシュマネージャ１１３が、受信メソッドを実行する処理の流れを示すフローチャートである。
【００９０】
まず、サーバ１のキャッシュマネージャ１１３は、ステップＳ３００において、情報受信部１１１を介して、他のキャッシュマネージャ１１３が送信（send）メソッドを実行することにより送信された情報を受け取り、受信（receive）メソッドを実行する（p.receive(method,key,from,value)）。
【００９１】
次に、キャッシュマネージャ１１３は、受信した情報のメソッド（method）を判定する（ステップＳ３０１）。そして、キャッシュマネージャ１１３は、受信した情報のメソッドが、「PUT」であればステップＳ３０２に進み、「PUT_L」であればステップＳ３０３に進み、「ADD_R」（Read権限の追加）または「ADD_W」（Write権限の移行）であれば、ステップＳ３０４に進む。
【００９２】
ステップＳ３０２において、キャッシュマネージャ１１３は、メソッド（method）が「PUT」であるとして、データの更新要求を受信したと判定し、図８および図９に示した、キャッシュデータの更新処理を実行する（p.put(key,value)）。
【００９３】
ステップＳ３０３において、キャッシュマネージャ１１３は、メソッド（method）が、「PUT_L」であるとして、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）に、記憶されているデータ（キャッシュデータ）を更新する（p.put_local(key,value)）。
【００９４】
また、ステップＳ３０４において、メソッド（method）が「ADD_R」または「ADD_W」である場合、まず、キャッシュマネージャ１１３は、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）から該当データの取得処理を実行する（w=p.get_local(key)）。
【００９５】
次に、キャッシュマネージャ１１３は、ステップＳ３０５において、該当データに付されたメタデータからWrite権限を持つ記憶場所（メタデータの<Write cache>タグのデータ）を取得する（q=w.get_metadata(write_cache)）。
【００９６】
続いて、キャッシュマネージャ１１３は、再び、受信した情報のメソッド（method）を判定する（ステップＳ３０６）。そして、キャッシュマネージャ１１３は、メソッド（method）が、「ADD_R」であればステップＳ３０７に進み、「ADD_W」であればステップＳ３０８に進む。
【００９７】
ステップＳ３０７において、キャッシュマネージャ１１３は、そのデータのメタデータに、Read権限を設定した情報を生成する（w.set_metadata(read_cache,from)）。
【００９８】
また、ステップＳ３０８において、キャッシュマネージャ１１３は、そのデータのメタデータに、Write権限を設定した情報を生成する（w.set_matadata(write_cache,from)）。
【００９９】
ステップＳ３０７およびステップＳ３０８に続いて、キャッシュマネージャ１１３は、自身がWrite権限を持つキャッシュマネージャ１１３か否かを判定する（ステップＳ３０９）。
そして、自身がWrite権限を持つキャッシュマネージャ１１３でなければ（ステップＳ３０９→false）、ステップＳ３１０において、キャッシュマネージャ１１３は、Write権限を持つキャッシュマネージャ１１３に更新を依頼する（p.send(PUT,key,q,w)）。
一方、自身がWrite権限を持つキャッシュマネージャ１１３であれば（ステップＳ３０９→true）、ステップＳ３１１において、キャッシュマネージャ１１３は、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）に記憶されているデータ（キャッシュデータ）を更新する（p.put_local(key,value)）。
【０１００】
そして、ステップＳ３１０およびＳ３１１の処理を終了すると、キャッシュマネージャ１１３は、送信（send）メソッドを送信してきたキャッシュマネージャ１１３に、データ「w」を送信して返す（ステップＳ３１２）。
【０１０１】
≪データキャッシュシステム１００の全体の処理の流れ≫
次に、本実施形態に係るデータキャッシュシステム１００の全体（クライアントクラスタ２０と原本データクラスタ１０との間）での、キャッシュデータの参照処理および更新処理の流れについて、図１１〜図１５を参照して説明する。
【０１０２】
［キャッシュデータの参照処理］
図１１は、クライアントクラスタ２０を構成するサーバ１（１ｘ）のキャッシュマネージャ１１３が、リクエストの該当データを記憶していない状態で参照要求を受信した場合に、Read権限付きでデータを取得する例を示している。
【０１０３】
まず、クライアントクラスタ２０のキャッシュマネージャ１１３（識別子「ｐ１」）が、アプリケーション処理部１１２から、参照要求を受信する（ステップＳ３０）。なお、この参照要求には、参照を要求するデータのkey（データkey）として「Ａ＠ＹＹＹ」が付されているものとする。
【０１０４】
参照要求を受信したキャッシュマネージャ１１３は、ステップＳ３１において、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）を探索し、該当データを記憶していないことから、送信（send）メソッドを実行して（p1.send(ADD_R,A@YYY,YYY,null)）、データの取得要求を原本データクラスタ１０に送信する。例えば、キャッシュマネージャ１１３は、ＨＴＴＰのＧＥＴメソッドを実行し、リクエストオプションを設定してデータの取得要求を送信する（http://YYY/A.xml?sourcecachemanager=p1@XXX&cachetype=read）。
これにより、当該キャッシュマネージャ１１３は、原本データクラスタ１０の入口となるロードバランサＢ（ＩＰ:ＹＹＹ）宛てにリクエストを送信し、ロードバランサＢが、任意のサーバ１（１ｙ）に振り分ける。そして、その振り分けられたサーバ１（１ｙ）の振り分け処理部１１４が、データkey(Ａ＠ＹＹＹ)に基づき、当該データを原本データとして記憶する担当を、キャッシュデータ管理情報１３２を参照して検出し、当該リクエストをそのデータの担当となるサーバ１（１ｙ）（ここでは、識別子「ｑ」のキャッシュマネージャ１１３とする。）に送信する。
【０１０５】
上記の処理により、原本データの担当であるキャッシュマネージャ１１３（識別子「ｑ」）は、リクエストを受信すると（ステップＳ３２）、受信（receive）メソッドを実行する（q.receive(ADD_R,A@YYY,p1@XXX,null)）。
そして、原本データの担当であるキャッシュマネージャ１１３（識別子「ｑ」）は、Write権限を持つ場合に、ステップＳ３３において、そのデータのメタデータのRead権限（<read cache>タグ）に、「ｐ１＠ＸＸＸ」を追記して（図１１の符号１０００参照）、当該データを含むファイルαを、クライアントクラスタ２０に送信する。ここで、キャッシュマネージャ１１３は、例えば、ＨＴＴＰのＰＵＴメソッドを実行し、当該データを送信する（http://XXX/A.xml?destinationcachemanager=p1@XXX&sourcecachemanager=q@YYY）。
なお、図１１の符号１０００の<read cache>タグの記載において、<read cache>p1@XXX</read cache>とすべき終了タグの記載を、</>として省略して記載する。同様に、図１１の<write cache>の終了タグ、さらに、図１２〜図１５においても、同様に終了タグを</>として省略して記載する。
上記の処理により、当該キャッシュマネージャ１１３は、クライアントクラスタ２０の入口となるロードバランサＢ（ＩＰ:ＸＸＸ）宛てにリクエストを送信し、ロードバランサＢが、任意のサーバ１（１ｘ）に振り分ける。そして、その振り分けられたサーバ１（１ｘ）の振り分け処理部１１４が、宛先としてキャッシュマネージャ１１３（キャッシュマネージャ識別子「ｐ１」を抽出し、キャッシュデータ管理情報１３２を参照して、当該リクエストをそのデータの担当となるサーバ１（１ｘ）（識別子「ｐ１」のキャッシュマネージャ１１３）に送信する。
【０１０６】
なお、原本データの担当であるキャッシュマネージャ１１３（識別子「ｑ」）がWrite権限を持たなかった場合は、当該キャッシュマネージャ１１３は、そのデータのメタデータを参照し、Write権限（<write cache>タグ）に記載されたキャッシュマネージャ１１３宛てに、さらにその取得要求のリクエストを送信する。
【０１０７】
上記の処理により、データを受信したクライアントクラスタ２０のキャッシュマネージャ１１３（識別子「ｐ１」）は、そのデータを、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）に記憶し（ステップＳ３４）、当該データを、アプリケーション処理部１１２に返す。
【０１０８】
このようにすることで、クライアントクラスタ２０を構成するサーバ１（１ｘ）のキャッシュマネージャ１１３が、リクエストの該当データを記憶していない状態で参照要求を受信した場合に、Read権限付きでデータを取得することができる。
【０１０９】
［キャッシュデータの参照処理（Write権限付き）］
図１２は、クライアントクラスタ２０を構成するサーバ１（１ｘ）のキャッシュマネージャ１１３が、リクエストの該当データを記憶していない状態で参照要求を受信した場合に、Write権限付きでデータを取得する例を示している。
【０１１０】
まず、クライアントクラスタ２０のキャッシュマネージャ１１３（識別子「ｐ１」）が、アプリケーション処理部１１２から、Write権限を含む参照要求を受信する（ステップＳ４０）。なお、この参照要求には、参照を要求するデータのkey（データkey）として「Ａ＠ＹＹＹ」が付されているものとする。
【０１１１】
Write権限を含む参照要求を受信したキャッシュマネージャ１１３は、ステップＳ４１において、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）を探索し、該当データを記憶していないことから、送信（send）メソッドを実行し（p1.send(ADD_W,A@YYY,YYY,null)）、データの取得要求を原本データクラスタ１０に送信する（http://YYY/A.xml?sourcecachemanager=p1@XXX&cachetype=write）。
【０１１２】
原本データクラスタ１０のロードバランサＢ（ＩＰ：ＹＹＹ）を介して、任意のサーバ１（１ｙ）の振り分け処理部１１４の処理により特定された、原本データの担当であるキャッシュマネージャ１１３（識別子「ｑ」）は、リクエストを受信すると（ステップＳ４２）、受信（receive）メソッドを実行する（q.receive(ADD_W,A@YYY,p1@XXX,null)）。
【０１１３】
次に、Write権限を持つこのキャッシュマネージャ１１３（識別子「ｑ」）は、ステップＳ４３において、そのデータのメタデータのWrite権限（<write cache>タグ）に、「ｐ１＠ＸＸＸ」を記載し、Read権限（<read cache>タグ）に原本データの担当として、自身のキャッシュマネージャkeyである「ｑ＠ＹＹＹ」を追記する（図１２の符号１００１参照）。これは、原本データを管理するキャッシュマネージャ１１３は、Write権限を移行した場合であっても、Read権限は残ることによる。そして、キャッシュマネージャ１１３は、当該データを含むファイルαを、クライアントクラスタ２０に送信する（http://XXX/A.xml?destinationcachemanager=p1@XXX&sourcecachemanager=q@YYY）。
【０１１４】
クライアントクラスタ２０のロードバランサＢ（ＩＰ：ＸＸＸ）を介して、任意のサーバ１（１ｘ）から、Write権限付きのデータを受信したキャッシュマネージャ１１３（識別子「ｐ１」）は、そのデータを、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）に記憶し（ステップＳ４４）、当該データを、アプリケーション処理部１１２に返す。
【０１１５】
このようにすることで、クライアントクラスタ２０を構成するサーバ１（１ｘ）のキャッシュマネージャ１１３が、リクエストの該当データを記憶していない状態で参照要求を受信した場合に、Write権限付きでデータを取得することができる。
なお、クライアントクラスタ２０側のキャッシュマネージャ１１３がWrite権限を持ち自身でキャッシュデータを更新可能とすることで、頻繁に書き換えられるデータに対するキャッシュヒット効果を高めることができる。
【０１１６】
［キャッシュデータの更新処理］
図１３は、クライアントクラスタ２０のキャッシュマネージャ１１３（識別子「ｐ２」）がデータ（データkey「Ａ＠ＹＹＹ」）のWrite権限を持つ状態で、更新要求を受信した場合に、キャッシュマネージャ１１３（識別子「ｐ２」）自身が、このデータを更新する例を示している。
【０１１７】
まず、クライアントクラスタ２０のキャッシュマネージャ１１３（識別子「ｐ２」）が、アプリケーション処理部１１２から、データの更新要求を受信する（ステップＳ５０）。なお、この更新要求には、更新を要求するデータのkey（データkey）として「Ａ＠ＹＹＹ」が付されているものとする。
【０１１８】
キャッシュマネージャ１１３（識別子「ｐ２」）は、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）を探索し、該当データが存在しており、そのデータのメタデータを参照することにより、自身がWrite権限を持つことを確認し、そのデータを更新する（ステップＳ５１）。
【０１１９】
ここで、キャッシュマネージャ１１３（識別子「ｐ２」）は、更新前のメタデータのRead権限を参照し、更新前のRead権限を持つキャッシュマネージャ１１３に対し、無効通知を送信する（ステップＳ５２）。ここでは、符号１００２に示すように、更新前のRead権限を、クライアントクラスタ２０のキャッシュマネージャ１１３（識別子「ｐ１」と、原本データクラスタ１０のキャッシュマネージャ１１３（識別子「ｑ」）とが持つので、この２つのキャッシュマネージャ１１３に対して、データ（「α」）の無効通知を送信する。例えば、原本データクラスタ１０のキャッシュマネージャ１１３（識別子「ｑ」）に向けて、「http://YYY/A.xml?destinationcachemanager=q@YYY&sourcecachemanager=p2@XXX&invalidate=true」が送信される。
【０１２０】
続いて、キャッシュマネージャ１１３（識別子「ｐ２」）は、更新後のメタデータのRead権限を参照し、更新後のRead権限を持つキャッシュマネージャ１１３に対し、更新データを送信する（ステップＳ５３）。ここでは、符号１００３に示すように、更新後のRead権限を、原本データクラスタ１０のキャッシュマネージャ１１３（識別子「ｑ」）が持つので、このキャッシュマネージャ１１３に対して、更新データを送信する。なお、クライアントクラスタ２０のキャッシュマネージャ１１３（識別子「ｐ１」）は、更新後のメタデータにおいて、Read権限を持たないため、更新データは送信されない。
【０１２１】
原本データクラスタ１０のロードバランサＢ（ＩＰ：ＹＹＹ）を介して、任意のサーバ１（１ｙ）から、更新データを受信したキャッシュマネージャ（識別子「ｑ」）は、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）に更新データ（「α’」）を記憶することにより、データを更新する（ステップＳ５４）。
【０１２２】
このようにすることにより、クライアントクラスタ２０のキャッシュマネージャ１１３がデータのWrite権限を持つ状態で、更新要求を受信した場合に、そのキャッシュマネージャ１１３自身が、データを更新することができる。また、更新前のデータを記憶する他のキャッシュマネージャ１１３に対して無効通知を送信し、更新後のデータを、更新後のメタデータに基づき他のキャッシュマネージャ１１３に送信することで、クラスタ内のキャッシュデータのコヒーレンスを保つことができる。
【０１２３】
［キャッシュデータの更新依頼］
図１４は、Write権限を持たないキャッシュマネージャ１１３において、データを更新したい場合に、Write権限を持つキャッシュマネージャ１１３に更新を依頼する例を示している。
【０１２４】
まず、クライアントクラスタ２０のキャッシュマネージャ１１３（識別子「ｐ１」）が、アプリケーション処理部１１２から、データの更新要求を受信する（ステップＳ６０）。なお、この更新要求には、更新を要求するデータのkey（データkey）として「Ａ＠ＹＹＹ」が付されているものとする。
【０１２５】
ここで、キャッシュマネージャ１１３（識別子「ｐ１」）は、ステップＳ６１において、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）を探索し、該当データを記憶していないことから、送信（send）メソッドを実行し（p1.send(PUT,A@YYY,YYY,α')）、データの更新依頼を原本データクラスタ１０のロードバランサＢ（ＩＰ：ＹＹＹ）に送信する（http://YYY/A.xml?sourcecachemanager=p1@XXX）。
【０１２６】
原本データクラスタ１０のロードバランサＢ（ＩＰ：ＹＹＹ）を介して、任意のサーバ１（１ｙ）の振り分け処理部１１４の処理により特定された、原本データの担当であるキャッシュマネージャ１１３（識別子「ｑ」）は、ステップＳ６２において、データの更新依頼を受信し、自身にWrite権限がある場合に、受信（receive）メソッドを実行することにより（q.receive(PUT,A@YYY,p1@XXX,α')）、データを更新する。
なお、ここで、原本データの担当であるキャッシュマネージャ１１３（識別子「ｑ」）にWrite権限がなかった場合は、当該キャッシュマネージャ１１３は、そのデータのメタデータを参照し、Write権限（<write cache>タグ）に記載されたキャッシュマネージャ１１３宛てに、さらに更新依頼を送信する。
【０１２７】
Write権限を持つキャッシュマネージャ１１３（識別子「ｑ」）は、当該データのメタデータのRead権限（<read cache>タグ）にキャッシュマネージャ（識別子「ｐ１」）を追加し（符号１００４参照）、Read権限付きで、更新データを、クライアントクラスタ２０のキャッシュマネージャ１１３（識別子「ｐ１」）に送信する（ステップＳ６３）。なお、このとき、当該データのメタデータのRead権限（<read cache>タグ）に他のキャッシュマネージャ１１３が登録されていた場合は、そのキャッシュマネージャに対しても、更新データが同時に送信される。
【０１２８】
クライアントクラスタ２０のロードバランサＢ（ＩＰ：ＸＸＸ）を介して、任意のサーバ１（１ｘ）から、更新データを受信したキャッシュマネージャ１１３（キャッシュマネージャの識別子「ｐ１」）は、そのデータを、自身のキャッシュデータ記憶部１３１（ローカルキャッシュ）に記憶する（ステップＳ６４）。
【０１２９】
このようにすることで、Write権限を持たないキャッシュマネージャ１１３において、データを更新したい場合に、Write権限を持つキャッシュマネージャ１１３に更新を依頼し、データを更新してもらった上で、自身がRead権限を持つことができる。
【０１３０】
［クラスタのＩＰアドレスのみでの更新通知］
図１５は、メタデータのRead権限（<read cache>タグ）において、キャッシュマネージャ１１３の識別子を省略し、クラスタのアドレス（実際は、クラスタの入口となるロードバランサＢのアドレス）のみが記述されていた場合の更新通知の流れを示している。
【０１３１】
ここでは、原本データクラスタ１０のWrite権限を持つキャッシュマネージャ１１３（識別子「ｑ」）でデータが更新され（ステップＳ７０）、メタデータのRead権限（<readcache>タグ）に、クライアントクラスタ２０のロードバランサＢのＩＰアドレス（ＸＸＸ）だけが記述される（符号１００５参照）。この場合、Write権限を持つキャッシュマネージャ１１３（識別子「ｑ」）は、ステップＳ７１において、クライアントクラスタ２０のすべてのキャッシュマネージャ１１３に向けて、更新通知を送信する（http://XXX/A.xml?destinationcachemanager=p*@XXX&sourcecachemanager=q@YYY）。
【０１３２】
更新通知を受信したクライアントクラスタ２０のロードバランサＢは、ランダムにどこかのサーバ１（１ｘ）にその更新通知を振り分ける（ステップＳ７２）。そして、更新通知が振り分けられたサーバ１（１ｘ）は、クラスタ全体にブロードキャストする機構を利用して、各サーバ１（１ｘ）に更新通知を送信する（ステップＳ７３）。
【０１３３】
このようにすることで、クラスタ内の各サーバ１にRead権限を持たせてデータを記憶させることができる。
【０１３４】
以上説明したように、本実施形態に係るデータキャッシュシステム１００によれば、呼出元（クライアント）および呼出先（原本データの保存サーバ）のクラスタ構成を互いに隠蔽したまま、キャッシュデータの情報の更新を通知し合うことが可能となる。また、クラスタ内部のサーバ１の構成が、故障や増設等で変化した場合であっても、参照対象や更新対象のデータの移動先の正しい保存先に、リクエストを送信し、参照や更新処理を実行した上、クラスタのコヒーレンスを保つことができる。
【符号の説明】
【０１３５】
１，１ｘ，１ｙ  サーバ
１０    原本データクラスタ
１１    制御部
１２    入出力部
１３    記憶部
２０    クライアントクラスタ
３０    クライアント端末
４０    外部端末
１００  データキャッシュシステム
１１１  情報受信部
１１２  アプリケーション処理部
１１３  キャッシュマネージャ
１１４  振り分け処理部
１１５  情報送信部
１３１  キャッシュデータ記憶部（ローカルキャッシュ）
１３２  キャッシュデータ管理情報
Ｂ      ロードバランサ
Ｄ（Ｄ１，Ｄ２，Ｄ３）  ディスパッチャ
Ｐ（Ｐ１，Ｐ２，Ｐ３）  プロセッサ
【図１】
2014052928.tif 000003
【図２】
2014052928.tif 000004
【図３】
2014052928.tif 000005
【図４】
2014052928.tif 000006
【図５】
2014052928.tif 000007
【図６】
2014052928.tif 000008
【図７】
2014052928.tif 000009
【図８】
2014052928.tif 000010
【図９】
2014052928.tif 000011
【図１０】
2014052928.tif 000012
【図１１】
2014052928.tif 000013
【図１２】
2014052928.tif 000014
【図１３】
2014052928.tif 000015
【図１４】
2014052928.tif 000016
【図１５】
2014052928.tif 000017