キャッシュシステム及びキャッシュアクセス方法
【課題】多重化されたキャッシュ装置を用いて恒常的に継続したデータ提供を可能とする。
【解決手段】ロードバランサ２ａ，２ｂは、定期的にヘルスチェック信号を送信し、両系のキャッシュサーバ１の参照部及び転送部はそれぞれ、自機能部の自系内状態監視結果に応じて応答を返送する。ロードバランサ２ａは、アプリケーション装置４からデータアクセス要求を受信すると、ヘルスチェック信号の応答状態に応じて判断した運用系のキャッシュサーバ１の参照部にデータアクセス要求を振り分ける。また、両系のキャッシュサーバ１の転送部は、定期的に系状態識別信号を送信し、ロードバランサ２ｂは同様に運用系と判断したキャッシュサーバ１の転送部へ送信する。自系が送信した系状態識別信号を受信したキャッシュサーバ１の転送部は、原本データ管理装置３とのデータ同期を行い、他系のキャッシュサーバ１との系間データ同期を行なう。
【解決手段】ロードバランサ２ａ，２ｂは、定期的にヘルスチェック信号を送信し、両系のキャッシュサーバ１の参照部及び転送部はそれぞれ、自機能部の自系内状態監視結果に応じて応答を返送する。ロードバランサ２ａは、アプリケーション装置４からデータアクセス要求を受信すると、ヘルスチェック信号の応答状態に応じて判断した運用系のキャッシュサーバ１の参照部にデータアクセス要求を振り分ける。また、両系のキャッシュサーバ１の転送部は、定期的に系状態識別信号を送信し、ロードバランサ２ｂは同様に運用系と判断したキャッシュサーバ１の転送部へ送信する。自系が送信した系状態識別信号を受信したキャッシュサーバ１の転送部は、原本データ管理装置３とのデータ同期を行い、他系のキャッシュサーバ１との系間データ同期を行なう。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、キャッシュシステム及びキャッシュアクセス方法に関する。
【背景技術】
【０００２】
従来、ユーザの端末から、ネットワークを介して接続されるサーバにアクセスし、このサーバから提供されるウェブ画面を用いて、ネットワーク上のデータベース（以下、「データベース」を「ＤＢ」と記載）に対して、データ参照等のデータアクセスを行なうシステムが実現されている。
【０００３】
図２５（ａ）は、このような既存システムの一例であるサービスオーダシステムの構成を示す図である。同図に示すサービスオーダシステムにおいて、ウェブサービスオーダ装置は、ネットワークを介して接続される端末へ、サービスオーダ管理装置が管理対象としている顧客ＤＢ内のデータへのアクセスを行なうためのウェブ画面を提供する。ユーザが、このウェブ画面を利用してデータ参照要求を端末に入力すると、ウェブサービスオーダ装置は、端末に入力されたデータ参照要求を受信し、受信したデータ参照要求をコマンド等に形式変換してサービスオーダ管理装置に送信する。受信したコマンドに従ってサービスオーダ管理装置が顧客ＤＢから読み出したデータは、ウェブサービスオーダシステムを介して端末へ通知される。
【０００４】
図２５（ａ）に示すようなサービスオーダシステムでは、サービスオーダ管理装置がメンテナンス等により停止している間、ユーザの端末は、顧客ＤＢ内のデータを取得することはできない。そこで、図２５（ｂ）に示すように、ウェブサービスオーダ装置と、サービスオーダ管理装置の間に、顧客ＤＢと同期してデータを記憶するキャッシュシステムを設けることが考えられる。これにより、サービスオーダ管理装置が停止している間も、ウェブサービスオーダ装置は参照が要求されたデータをキャッシュシステムから読み出して端末に提供することができる。
【０００５】
しかし、上記のように、キャッシュシステムを設けた場合であっても、キャッシュシステム自体が停止してしまった場合には、端末へデータを提供できなくなってしまう。そのため、キャッシュシステムのリダンダンシを確保することが必要である。
【０００６】
リダンダンシを確保する場合、装置を多重化することが一般的である。図２６に、キャッシュサーバを多重化してリダンダンシを確保した従来のシステム構成を示す。
図２６（ａ）は、クラスタを利用し、待機系のキャッシュサーバをコールドスタンバイ（Cold.SBY）とした構成を示す。同図に示す構成のシステムでは、アクト（ACT）系とスタンバイ系のキャッシュサーバにおいてＤＢをＳＡＮ（Storage Area Network）により共有し、クラスタリングソフトウェアを利用して系切り替えを行なう。
図２６（ｂ）は、クラスタを利用し、待機系のキャッシュサーバをホットスタンバイ（Hot.SBY）とした構成を示す。同図に示す構成のシステムも同様に、アクト系とスタンバイ系のキャッシュサーバにおいてＤＢをＳＡＮにより共有し、クラスタリングソフトウェアを利用して系切り替えを行なう。
図２６（ｃ）は、各系のキャッシュサーバにＤＡＳ（Direct Attached Storage）のＤＢを配備し、待機系のキャッシュサーバをコールドスタンバイとした構成を示す。図２６（ｃ）においては、クォーラムサーバが各系の状態を保持し、系切り替えを行なう。
【０００７】
また、データアクセスを無停止で提供することを目的とする技術が特許文献１、２に開示されている。特許文献１には、同じデータが割り当てられている複数のノードがロードバランサを介して外部と接続されており、ロードバランサは、ノードの状態を監視して最適なノードを選ぶことが記載されている。また、特許文献２には、主系、従系として動作する冗長構成のコンピュータそれぞれが、自身の状態をチェックした結果であるヘルシーチェック情報を相互に交換し、主系、従系の切り替えを行なうことが記載されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−３０２０４号公報
【特許文献２】特開２００８−２２６１５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上述したリダンダンシを確保するための既存の技術には、以下のような問題がある。
すなわち、図２６（ａ）の構成において系切り替えを行なう場合、待機系はコールドスタンバイ起動となるため、系切り替えに数十分を要する場合があり、この間はデータを提供できない。また、ＳＡＮのファームアップ中は、ＳＡＮにアクセスするＤＢＭＳ（DataBase Management System）を数十分間停止させる必要があり、やはり、この間は、データの提供できない。加えて、ＤＢの共有ディスクがＳＰＯＦ（Single Point of Failure）となってしまい、共有ディスク故障時には、全体が障害に陥ってしまう。
【００１０】
また、図２６（ｂ）の構成において系切り替えを行なう場合、図２６（ａ）と同様に、ＳＡＮのファームアップ中は、ＳＡＮにアクセスするＤＢＭＳを数十分間停止する必要があるとともに、共有ディスクがＳＰＯＦとなる。また、冗長構成を拡張する場合は各系の関係を解除する必要がある。つまり、両系のＤＢＭＳや、クラスタリングソフトウェアを停止し、設定変更の作業を行うため、その間はデータアクセスサービスが提供できない。
このように、上記の図２６（ａ）、（ｂ）のように、系間でＤＢを共有する形態では、恒常的に継続してデータを提供することは困難である。
【００１１】
また、図２６（ｃ）の構成においては系切り替えを行なう場合、待機系はコールドスタンバイ起動となるため、系切り替えに数十分を要する場合があり、この間はデータアクセスサービスが提供できないことに加え、各系の状態を保持し、系切り替えを行なうクォーラムサーバがＳＰＯＦとなってしまう。
【００１２】
特許文献１の技術は、ロードバランサが、外部から受信したリクエストを二重化されたノードコンピュータの両方に送信し、リクエストに対する仮実行結果を早く返送したノードコンピュータに対して本実行を行なうよう指示し、他方のノードコンピュータには無効を指示するものであり、ノードコンピュータにリクエストを受信する都度、仮実行を行わせその結果を破棄するという処理を実装しなければならない。また、特許文献２の技術は、冗長構成のコンピュータにおいて主系、従系の切り替えを行なうものであり、冗長構成のコンピュータが常に他方のコンピュータの状態を意識しなければならない。
【００１３】
本発明は、このような事情を考慮してなされたもので、その目的は、多重化されたキャッシュ装置を用い、キャッシュ装置に系切り替えのための負荷をかけることなく、恒常的に継続してデータ提供を可能とするキャッシュシステム及びキャッシュアクセス方法を提供することにある。
【課題を解決するための手段】
【００１４】
本発明は、上記の課題を解決すべくなされたもので、原本データをキャッシュする複数のキャッシュ装置と、受信信号を複数の前記キャッシュ装置のいずれに振り分けるかを管理するアクセス振分装置とを備えるキャッシュシステムであって、複数の前記キャッシュ装置それぞれは、前記アクセス振分装置から振り分けられたデータアクセス要求を受信し、受信したデータアクセス要求に応じて自キャッシュ装置がキャッシュしている原本データへのアクセス処理を行う参照部と、原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する転送部とを備え、前記アクセス振分装置は、アクト状態の複数の前記キャッシュ装置の前記参照部及び前記転送部それぞれの運用状態を取得するサービスチェック部と、前記サービスチェック部が取得した複数の前記キャッシュ装置の前記参照部及び前記転送部の運用状態に基づいて、複数の前記キャッシュ装置の中から受信信号の振分先となる前記キャッシュ装置を判定する運用系判断処理部とを備える、ことを特徴とするキャッシュシステムである。
上記発明によれば、それぞれが１台のサーバ（筐体）によって実現される複数のキャッシュ装置を、上位アプリケーションからのデータアクセス要求に応じて自身がキャッシュしている原本データへのアクセス処理を行う参照部と、原本データ管理装置が保持している原本データにより自身がキャッシュしている原本データを更新する転送部とに分離した構成とし、振分装置は、各キャッシュ装置内の参照部及び転送部が両方とも正常であるか、いずれかあるいは両方に障害が発生しているかなどの状況に従って信号の振分先、すなわち、運用系のキャッシュ装置を判断する。
これによって、振分装置は、上位アプリケーションからのデータアクセス要求を受信した場合、まずは参照部が正常に動作しているキャッシュ装置を選択し、選択したキャッシュ装置が１台であればその選択したキャッシュ装置を振り分け先とし、選択したキャッシュ装置が複数であれば、選択した中でも同一筐体内の転送部が正常であるキャッシュ装置の中から振り分け先を選択したり、選択したキャッシュ装置の転送部がいずれも障害である場合には、選択した中から任意に振り分け先を選択したりすることができる。従って、複数のキャッシュシステム装置の中から、恒常的に継続して原本データへのアクセスを提供すること可能となるとともに、できるだけ最新の原本データを提供することが可能となる。
また、参照部と転送部を分離しているため、将来的に参照部と転送部をそれぞれ別の筐体に実装した構成に移行することが容易となる。参照部のトラフィックは、上位サービスアプリケーションを使用するユーザの増加や、上位サービスアプリケーションの種類の増加に伴って増加する一方、転送部のトラフィックは、上位サービスアプリケーションから参照されるデータ項目が追加されたときに増加することを勘案すると、将来的には、参照部を実行するサーバをｎ台構成の全運用方式へ、転送部を実行するサーバを１＋１台構成の運用待機方式へと移行することが望ましく、その縮退した構成として本発明のキャッシュシステムを用いることが可能となる。
なお、ｎ台構成とは、同一のシステム、機能部を複数台用意し、全て運用系とする冗長化構成であり、１＋１台構成とは、同一のシステム、機能部を２台用意し、一方は運用系、もう一方は待機系とする冗長化構成であり、運用待機方式とは、ある機能部を複数台のサーバに分散配置した際、機能部を運用系と待機系に分けて稼動する方式である。
【００１５】
また本発明は、上述するキャッシュシステムであって、前記運用系判断処理部は、前記参照部の運用状態に基づいて複数の前記参照部が正常であると判断した場合、正常な前記参照部を備える複数の前記キャッシュ装置の中から、前記転送部の運用状態に基づいて正常であると判断される前記転送部を備える前記キャッシュ装置を振分先と判定する、ことを特徴とする。
上記発明によれば、振分装置は、参照部が正常に動作しているということだけではなく、原本データの同期を行なう転送部が正常に動作しているかも判断して運用系のキャッシュ装置を選択する。
転送部が正常に動作していれば、そのキャッシュ装置にキャッシュされている原本データは正しく同期されているため、参照部が正常に動作しているキャッシュ装置の中から、転送部も正常に動作しているキャッシュ装置を振り分け先として選択することにより、データアクセスが可能な原本データの中から常に最新の原本データを上位アプリケーションに提供することができる。
【００１６】
また本発明は、上述するキャッシュシステムであって、複数の前記キャッシュ装置それぞれの転送部は、前記振分装置に系状態識別信号を送信する系状態識別部と、前記振分装置から自身が送信した前記系状態識別信号を受信した場合に、原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する情報転送処理部と、他のキャッシュ装置がキャッシュしている原本データを前記情報転送処理部が読み出した前記原本データにより更新する系間転送処理部とをさらに備え、前記アクセス振分装置の前記運用系判断処理部は、振分先として判定した前記キャッシュ装置へ受信した前記系状態識別信号を送信する、ことを特徴とする。
上記発明によれば、各キャッシュ装置の転送部は系状態識別信号を送信し、送信された系状態識別信号は、振分装置が運用系と判断したキャッシュ装置へ振り分けられる。自身が送信した系状態識別信号を受信した転送部は自系が運用系であると判断し、原本データ管理装置が保持している原本データによって自系がキャッシュしている原本データを更新し、さらに他のキャッシュ装置がキャッシュしている原本データも更新する。
振分装置は、信号の種類や宛先ではなく、各キャッシュ装置内の参照部及び転送部の運用状態によって信号の振分先を判断するため、上位アプリケーションからのデータアクセス要求と同じ振分先に系状態識別信号も振り分けられる。そこで、自身の送信した系状態識別信号を受信した、すなわち、データアクセス要求を処理するキャッシュ装置の転送部がまず、原本データ管理装置が保持している原本データとの同期を行なうことで、常に最新の原本データを上位アプリケーションに提供することが可能となる。例えば、待機系のキャッシュ装置の転送部が原本データ管理装置と同期を行い、続いて、運用系のキャッシュ装置との系間同期を行なうような同期手順と比較すると、運用系のキャッシュ装置がキャッシュしている原本データが更新されるタイミングが早く、また、系間同期中の障害等によって、運用系のキャッシュ装置がキャッシュしている原本データの更新が行なえずに、古い原本データへのアクセスを提供してしまうようなこともない。また、原本データ管理装置との同期の後、他系のキャッシュ装置とも系間同期を行なうため、キャッシュ装置間での原本データの不整合も発生しない。
【００１７】
また本発明は、上述するキャッシュシステムであって、前記情報転送処理部は、自身が送信した前記系状態識別信号を受信した場合に、前記原本データ管理装置から、自キャッシュ装置がキャッシュしている前記原本データよりも、前記原本データ管理装置における更新日時が新しい原本データを読み出し、自キャッシュ装置がキャッシュしている前記原本データを更新し、前記系間転送処理部は、自キャッシュ装置がキャッシュしている前記原本データのうち、前記他のキャッシュ装置がキャッシュしている前記原本データよりも前記原本データ管理装置における更新日時が新しい原本データにより、前記他のキャッシュ装置がキャッシュしている原本データを更新する、ことを特徴とする。
上記発明によれば、運用系のキャッシュ装置の転送部は、原本データ管理装置における更新日時に基づいて、自身がキャッシュしている原本データの更新と、他のキャッシュ装置がキャッシュしている原本データの更新を行なう。
これにより、運用系のキャッシュ装置が切り替わり、新たにデータアクセス要求の振分先となったキッシュ装置において原本データ管理装置と同期を行なう際や、他系の原本データとの同期を行なう際にも更新もれが発生することがない。よって、一元性を確保しながら、最新の原本データを提供することが可能となる。
【００１８】
また本発明は、上述するキャッシュシステムであって、前記転送部は、自キャッシュ装置がキャッシュしている前記原本データを記憶する転送データ記憶部をさらに備え、前記情報転送処理部は、前記原本データ管理装置から読み出した前記原本データを前記転送データ記憶部に書き込み、前記参照部は、自キャッシュ装置がキャッシュしている前記原本データを記憶する参照データ記憶部と、前記転送データ記憶部から読み出した前記原本データを前記参照データ記憶部に書き込む系内同期処理部と、受信した前記データアクセス要求に応じて前記参照データ記憶部に記憶している前記原本データへのアクセス処理を行う参照データアクセス部とを備える、ことを特徴とする。
上記発明によれば、参照部及び転送部それぞれにキャッシュした原本データを記憶する記憶部を備えておき、転送部は、自身の備える記憶部に原本データ管理装置から読み出した原本データを書き込んでキャッシュし、参照部は自身の備える記憶部にキャッシュしている原本データを、転送部の記憶部にキャッシュしている原本データによって更新する。
上記構成により、参照部と転送部を完全に分離することが可能となるため、将来的に、参照部を実行するサーバをｎ台構成の全運用方式へ、転送部を実行するサーバを１＋１台構成の運用待機方式へと移行することが容易になる。
【００１９】
また本発明は、原本データをキャッシュする複数のキャッシュ装置と、受信信号を複数の前記キャッシュ装置のいずれに振り分けるかを管理するアクセス振分装置とを備えるキャッシュシステムに用いられるキャッシュアクセス方法であって、複数の前記キャッシュ装置それぞれは、前記アクセス振分装置から振り分けられたデータアクセス要求を受信し、受信したデータアクセス要求に応じて自キャッシュ装置がキャッシュしている原本データへのアクセス処理を行う参照部と、原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する転送部とを備えており、前記アクセス振分装置において、サービスチェック部が、アクト状態の複数の前記キャッシュ装置の前記参照部及び前記転送部それぞれの運用状態を取得する状態取得過程と、運用系判断処理部が、前記状態取得過程において取得した複数の前記キャッシュ装置の前記参照部及び前記転送部の運用状態に基づいて、複数の前記キャッシュ装置の中から受信信号の振分先となる前記キャッシュ装置を判定する運用系判断処理過程と、を有することを特徴とするキャッシュアクセス方法である。
【発明の効果】
【００２０】
本発明によれば、振分装置は、各キャッシュ装置内の参照部及び転送部が両方とも正常であるか、いずれかあるいは両方に障害が発生しているかなどの状況に従って信号の振分先、すなわち、運用系のキャッシュ装置を判断するため、恒常的に継続して原本データへのアクセスを提供することが可能となるとともに、できるだけ最新の原本データを提供することが可能となる。
また、本発明によれば、参照部が正常に動作しているキャッシュ装置の中から、転送部も正常に動作しているキャッシュ装置を振り分け先として選択するため、アクセス可能な原本データの中から常に最新の原本データを上位アプリケーションに提供することが可能となる。
また、本発明によれば、データアクセス要求を処理する参照系と同じキャッシュ装置の転送部がまず、原本データ管理装置が保持している原本データとの同期を行なうため、常に最新の原本データを上位アプリケーションに提供することが可能となり、原本データ管理装置との同期後、他系との同期を行なうため、キャッシュ装置間での原本データの不整合も発生しない。
また、本発明によれば、データアクセス要求の振分先となるキャッシュ装置は、原本データ管理装置における更新日時に基づいて、自身がキャッシュしている原本データの更新と、他のキャッシュ装置がキャッシュしている原本データとの同期を行なうため、一元性を確保した、最新の原本データを提供することが可能となる。
また、本発明によれば、参照部と転送部を分離しているため、将来的に参照部と転送部をそれぞれ別の筐体に実装した構成に移行することが容易となり、参照部及び転送部にそれぞれ記憶部を有することによって、さらに、この分離が容易となる。従って、参照部を実行するサーバをｎ台構成の全運用方式に、転送部を実行するサーバを１＋１台構成の運用待機方式へと移行する場合の縮退構成として本発明のキャッシュシステムを用いることが可能となる。
【図面の簡単な説明】
【００２１】
【図１】本発明の一実施形態によるキャッシュシステムの接続構成を示す図である。
【図２】同実施形態によるキャッシュシステムの動作概要を示す図である。
【図３】同実施形態による各装置の内部構成を示すブロック図である。
【図４】同実施形態によるキャッシュシステムの系状態確認シーケンスを示す図である。
【図５】同実施形態による系状態確認における各装置の機能部間の処理の流れを示す図である。
【図６】同実施形態による両系のキャッシュサーバ１の参照部１１及び転送部１５における自系内状態監視処理フローを示す図である。
【図７】同実施形態による両系のキャッシュサーバ１の参照部１１及び転送部１５における自系内状態監視結果返却処理フローを示す図である。
【図８】同実施形態によるロードバランサ２のヘルスチェック処理フローを示す図である。
【図９】同実施形態によるデータ参照要求受信時の振分処理シーケンスを示す図である。
【図１０】同実施形態による系状態識別信号受信時の振分処理シーケンスを示す図である。
【図１１】同実施形態によるロードバランサ２ａにおける振分処理フローを示す図である。
【図１２】同実施形態による振分け状態表を示す図である。
【図１３】同実施形態によるロードバランサ２ｂにおける振分処理の処理フローを示す図である。
【図１４】同実施形態への適用を検討した原本データ同期方法を示す図である。
【図１５】同実施形態への適用を検討した系間同期方法を示す図である。
【図１６】同実施形態によるキャッシュシステムのデータ同期シーケンスを示す図である。
【図１７】同実施形態によるデータ同期処理に用いられる各装置のデータ例を示す図である。
【図１８】同実施形態による原本データ同期処理におけるデータ更新の流れを示す図である。
【図１９】同実施形態による系間データ同期処理におけるデータ更新の流れを示す図である。
【図２０】同実施形態による両系のキャッシュサーバ１の転送部１５における系状態識別処理フローを示す図である。
【図２１】同実施形態による両系のキャッシュサーバ１の転送部１５における原本データとの同期処理フローを示す図である。
【図２２】同実施形態による運用系のキャッシュサーバ１の転送部１５における系間データ同期処理フローを示す図である。
【図２３】同実施形態による汎用インタフェースを用いた動作概要を示す図である。
【図２４】同実施形態によるキャッシュサーバ１の汎用インタフェース処理フローを示す図である。
【図２５】従来のデータアクセスシステムを示す図である。
【図２６】二重化によりリダンダンシを確保した従来のシステム構成を示す図である。
【発明を実施するための形態】
【００２２】
以下、図面を参照しながら本発明の実施形態を詳細に説明する。
【００２３】
［１． 構成］
図１は、本発明の一実施形態によるキャッシュシステムの接続構成を示す図である。同図において、キャッシュシステムは、キャッシュサーバ１により多重化されたキャッシュインタフェース装置と、キャッシュサーバ１それぞれに接続されるロードバランサ２ａ、２ｂとからなる。ロードバランサ２ａはさらに、原本データを使用して上位サービスアプリケーションを実行するアプリケーション装置４と接続され、ロードバランサ２ｂはさらに、上位サービスアプリケーションが参照する原本データを記憶する原本データ管理装置３と接続される。同図においては、アプリケーション装置４を１台のみ示しているが、複数台が接続されうる。
【００２４】
キャッシュサーバ１は、原本データ管理装置３が記憶する原本データのうち、上位サービスアプリケーションに必要な情報を内部にキャッシュする。キャッシュサーバ１は、上位サービスアプリケーションの実行に伴ってアプリケーション装置４から送信されたデータ参照要求に対して、原本データ管理装置３から読み出してキャッシュした原本データを検索し、その結果を返却する。キャッシュサーバ１は多重化構成の形態をとっているため、上位サービスアプリケーションに対して、サービスの恒常的継続が可能である。
【００２５】
以下、キャッシュサーバ１のうち一方を０系、他方を１系とし、０系のキャッシュサーバ１をキャッシュサーバ１−０、１系のキャッシュサーバ１をキャッシュサーバ１−１と記載し、０系と１系をあわせて「両系」と記載する。また、ロードバランサ２ａ、２ｂを総称してロードバランサ２と記載する。なお、ロードバランサ２は二重化されており、障害等が発生した場合でも短い時間での系切り替えが可能である。
【００２６】
図２は、図１に示すキャッシュシステムの動作概要を示す図である。
本実施形態において、両系のキャッシュサーバ１は、アクト系、スタンバイ系という系状態を持たず、キャッシュサーバ１−０、１−１ともアクト系として動作しており、ネットワーク装置としてのロードバランサ２が、受信した信号をキャッシュサーバ１−０、１−１のいずれに振り分けるかを判断する。ここでは、ロードバランサ２が信号を振り分ける側のキャッシュサーバ１を運用系、運用系ではない側のキャッシュサーバ１を待機系と記載する。
【００２７】
各キャッシュサーバ１は、参照部１１及び転送部１５を備えた１台のサーバである。すなわち、同じ筐体において参照部１１及び転送部１５が動作する。参照部１１は、該参照部１１が備えるデータベース（以下、「ＤＢ」と記載）にキャッシュされている原本データを用い、上位サービスアプリケーションの実行によりアプリケーション装置４から送信されたデータ参照要求に対応して応答する。転送部１５は、ロードバランサ２から自系が運用系と判断されているかを識別し、運用系であると判断されている場合は、該転送部１５が備えるＤＢにキャッシュされている原本データと、原本データ管理装置３に記憶されている原本データとのデータ同期を行い、さらに、他系の転送部１５のＤＢにキャッシュされている原本データとの同期を行なう。参照部１１は、定期的に転送部１５のＤＢから同期が行われた原本データを読み出し、該参照部１１が備えるＤＢを更新することにより、転送部１５のＤＢとデータ同期を行なっている。
【００２８】
ロードバランサ２は、定期的にキャッシュサーバ１にヘルスチェック信号を送信して各系の参照部１１及び転送部１５の状態を監視するヘルスチェックを行っており、その監視結果に基づいて運用系と待機系を決定する。
ロードバランサ２ａは、アプリケーション装置４側の仮想ＩＰアドレスＡを持つとともに、キャッシュサーバ１−０の物理ＩＰアドレスＣ０、キャッシュサーバ１−１の物理ＩＰアドレスＣ１を記憶しており、仮想ＩＰアドレスＡを宛先とした信号を受信すると、運用側のキャッシュサーバ１の物理ＩＰアドレスＣ０またはＣ１を宛先として受信した信号を送出する。このとき、物理ＩＰアドレスには、参照部１１に対応したポート番号が付加される。キャッシュサーバ１−０、１−１の参照部１１それぞれのポート番号をＰＳ０、ＰＳ１とする。
同様に、ロードバランサ２ｂは、原本データ管理装置３側の仮想ＩＰアドレスＢを持つとともに、キャッシュサーバ１−０の物理ＩＰアドレスＣ０、キャッシュサーバ１−１の物理ＩＰアドレスＣ１を記憶しており、仮想ＩＰアドレスＢを宛先とした信号を受信すると、運用側のキャッシュサーバ１の物理ＩＰアドレスＣ０またはＣ１を宛先として受信した信号を送出する。このとき、物理ＩＰアドレスには、転送部１５に対応したポート番号が付加される。キャッシュサーバ１−０、１−１の転送部１５それぞれのポート番号をＰＴ０、ＰＴ１とする。
【００２９】
なお、同じキャッシュサーバ１内において参照部１１、転送部１５が異なる物理ＩＰアドレスを用いるようにすることもできる。この場合、ロードバランサ２ａは、仮想ＩＰアドレスＡを宛先とした信号を受信すると、運用側のキャッシュサーバ１の参照部１１に対応した物理ＩＰアドレスを宛先として受信した信号を送出する。同様に、ロードバランサ２ｂは、仮想ＩＰアドレスＢを宛先とした信号を受信すると、運用側のキャッシュサーバ１の転送部１５に対応した物理ＩＰアドレスを宛先として受信した信号を送出する。
【００３０】
上記により、ロードバランサ２ａは、運用系と判断しているキャッシュサーバ１の参照部１１にアプリケーション装置４から受信したデータ参照要求を送信する。そのため、キャッシュサーバ１は、系を意識せずとも、データ参照要求を受信したときに、自身の参照部１１が備えるＤＡＳ（Direct Attached Storage）のＤＢに記憶されているデータを読み出して応答すればよい。ロードバランサ２ａに待機系と判断されているキャッシュサーバ１も、運用系と判断されているキャッシュサーバ１と同じ状態で動作しているため、ロードバランサ２ａによって運用系の切り替え判断がなされた場合にもそれを意識する必要はなく、受信したデータ参照要求に応答すればよい。このように、独立した２つのキャッシュサーバ１が外部からはあたかも１つの装置のように見え、サービスルートの決定はロードバランサ２に制御をゆだねている。
【００３１】
ただし、本実施の形態のキャッシュシステムにおいて、原本データ管理装置３が記憶する原本データとの同期や、待機系のキャッシュサーバ１とのデータ同期は、運用系のキャッシュサーバ１の転送部１５から起動する。そのため、キャッシュサーバ１の転送部１５は、ロードバランサ２ｂに自系の系状態を問い合わせる系状態識別処理を行なう。系状態識別処理では、ロードバランサ２が仮想ＩＰアドレスを宛先とした信号を、運用系のキャッシュサーバ１に振り分けることを利用する。つまり、キャッシュサーバ１の転送部１５は、仮想ＩＰアドレスＢ宛に系状態識別信号を送信し、ロードバランサ２ｂからその信号を受信した場合には運用系であると判断する。
【００３２】
ロードバランサ２は、ヘルスチェックによる各系の参照部１１及び転送部１５の状態の監視結果に基づいて運用系と待機系を決定しているが、両系のキャッシュサーバ１の参照部１１とも運用可能（障害が発生していない）である場合、同じ筐体に備えられている転送部１５が運用可能であるキャッシュサーバ１を運用系と判断する。
【００３３】
例えば、ある機能部を複数台のサーバに分散配置した際に、ロードバランスにより全サーバ上の該当機能部を全て運用系として稼動する全運用方式のように、転送部１５の運用状態に関わらず、参照部１１が運用可能であれば、上位サービスアプリケーションからキャッシュサーバ１にアクセス可能としたとする。この場合、転送部１５の運用状態が待機系のキャッシュサーバ１では、原本データ管理装置３から取得される原本データとの同期が遅れてしまったり（系間同期の遅れ）、キャッシュされている原本データが更新されなかったりする（系間同期故障）可能性がある。このときに、転送部１５が待機系であるキャッシュサーバ１に、データ参照要求が振り分けられてしまうと、古いデータを返却するという不具合が生じてしまう。
そこで、ロードバランサ２aは、両系のキャッシュサーバ１の参照部１１が運用可能かどうかを確認し、同時に、両系のキャッシュサーバ１の転送部１５が運用可能かどうかを確認する。そして、両系のキャッシュサーバ１の参照部１１とも運用可能である場合、同じ筐体に備えられている転送部１５が正常に動作している参照部１１にアプリケーション装置４から受信したデータ参照要求を振り分ける。
【００３４】
ロードバランサ２ａが上記のように振り分け先を決定することにより、例えば、キャッシュサーバ１−０の参照部１１及び転送部１５が運用状態であり、キャッシュサーバ１−１の参照部１１が運用状態、転送部１５が待機状態である場合、アプリケーション装置４からのデータ参照要求はキャッシュサーバ１−０の参照部１１に振り分けられる。このとき、キャッシュサーバ１−０の参照部１１においてアプリケーション障害、ＤＢ障害、ロードバランサとの間のネットワーク障害等の障害が発生した場合、系切替が行なわれる。従来方式を適用した場合、キャッシュサーバ１は、参照部１１の運用状態に関わらず、転送部１５が運用状態であればデータの同期を行なうことが考えられる。しかし、データ参照要求の振分先がキャッシュサーバ１−１の参照部１１となっても、キャッシュサーバ１−０の転送部１５については運用状態のまま系切替が行なわれないと、正常時と比較して、原本ＤＢから取得された原本データとの同期が遅れてしまったり（系間同期の遅れ）、キャッシュされている原本データが更新されなかったりする（系間同期故障）可能性があり、サービス提供レベルが下がってしまう。
【００３５】
そこで、本実施の形態では、キャッシュサーバ１の転送部１５は、原本データ管理装置３との間の原本データ同期処理の開始時に、データ参照要求の振分先が同一筐体内の参照部１１であるかを確認する。そのため、キャッシュサーバ１の転送部１５は、系状態識別信号を送信し、ロードバランサ２ｂは、ロードバランサ２ａと同様に振り分け先を決定する。自身が送信した系状態識別信号をロードバランサ２ｂから受信した、すなわち、データ参照要求の振分先のキャッシュサーバ１と同一の筐体内の転送部１５は、原本データ管理装置３から原本データを取得し、同期を行う。このようにして、運用状態の転送部１５は、同一筐体内の参照部１１が振り分け先の場合は原本データ同期処理を実施し、別筐体内の参照部１１が振り分け先の場合は、転送部１５の系切替を実施する。
【００３６】
図３は、キャッシュサーバ１、ロードバランサ２及び原本データ管理装置３の内部構成を示すブロック図である。
参照部１１は、ロードバランサ２との間でヘルスチェックを実行するとともに、上位サービスアプリケーションからのデータ参照要求に応答し、同一系内、つまり、同一のキャッシュサーバ１が備える転送部１５との間でデータ同期を行なう。参照部１１は、タイマ１１１、監視処理部１１２、監視結果通知処理部１１３、参照データ管理部１１４、情報参照処理部１１５、及び、系内同期処理部１１６を備える。
【００３７】
監視処理部１１２は、タイマ１１１により定期的に起動され、自系の参照部１１内の各プロセスの生起確認、参照データ管理部１１４が備えるＤＢの死活確認など、自系の参照部１１についての系内状態監視を実施し、その結果を内部に備える監視結果記憶部１２１に保持する。監視結果通知処理部１１３は、ロードバランサ２から定期的にヘルスチェック信号を受信し、監視結果記憶部１２１に保持されている自参照部１１の系内状態監視結果に応じて応答を送信する。
【００３８】
参照データ管理部１１４は、参照データアクセス部１２２と、参照データ記憶部１２３を備える。参照データアクセス部１２２は、既存のＤＢＭＳ（DataBase Management System）ソフトウェアにより実現することができ、ＤＢとしての参照データ記憶部１２３に記憶されているキャッシュデータの読み出しや書き込みを行なう。
系内同期処理部１１６は、参照データ記憶部１２３に記憶されている原本データと、転送部１５のＤＢに記憶されている原本データとのデータ同期を行なう。
【００３９】
情報参照処理部１１５は、アプリケーション装置４が送信したデータ参照要求を受信して参照データ管理部１１４に出力し、参照データ管理部１１４がデータ参照要求に基づいて読み出したデータを返送する。
【００４０】
転送部１５は、ロードバランサ２との間でヘルスチェックを実行するとともに、自系が運用系かどうかを確認し、運用系であれば原本データ管理装置３との間でデータ同期を実施する。さらに、転送部１５は、同一系内、つまり、同一のキャッシュサーバ１内の転送部１５との間でデータ同期を行なう。転送部１５は、タイマ１５１、監視処理部１５２、監視結果通知処理部１５３、転送データ管理部１５４、系状態識別部１５５、同期情報記憶部１５６、情報転送処理部１５７、系間転送処理部１５８、及び、系内同期処理部１５９を備える。
【００４１】
監視処理部１５２は、タイマ１５１により定期的に起動され、自系の転送部１５内の各プロセスの生起確認、転送データ管理部１５４が備えるＤＢの死活確認など、自系の転送部１５についての系内状態監視を実施し、その結果を内部に備える監視結果記憶部１６１に保持する。監視結果通知処理部１５３は、ロードバランサ２から定期的にヘルスチェック信号を受信し、監視結果記憶部１６１に保持されている自転送部１５内の系内状態監視結果に応じて応答を送信する。
【００４２】
転送データ管理部１５４は、転送データアクセス部１６２と、転送データ記憶部１６３を備える。転送データアクセス部１６２は、既存のＤＢＭＳソフトウェアにより実現することができ、ＤＢとしての転送データ記憶部１６３に記憶されているキャッシュデータの読み出しや書き込みを行なう。
系内同期処理部１５９は、転送データ記憶部１６３に記憶されているデータと、参照部１１が保持するデータとの原本データ同期を行なう。
【００４３】
同期情報記憶部１５６は、原本データ管理装置３から読み出した原本のデータのうち、転送データ記憶部１６３には書き込んだが、まだ他のキャッシュサーバ１との同期更新を行なっていないデータと、そのデータが原本データ管理装置３において更新された日時の情報とを対応づけた更新情報テーブル（以下、テーブルを「ＴＢＬ」と記載）を記憶する。さらに、同期情報記憶部１５６は、転送データ記憶部１６３への書き込みが終了した原本データの原本データ管理装置３における更新日時のうち、最新の更新日時であるラストルックを示す最終更新情報ＴＢＬを記憶する。
【００４４】
系状態識別部１５５は、ロードバランサ２が自系を運用系として認識しているか、待機系と判断しているかを問い合わせる。情報転送処理部１５７は、自系が運用系と認識されている場合、同期情報記憶部１５６内の最終更新情報ＴＢＬに設定されているラストルック以降が更新日時である原本データを原本データ管理装置３から読み出し、読み出した原本データを同期情報記憶部１５６内の更新情報ＴＢＬに書き込むとともに、読み出した原本データを書き込んで転送データ記憶部１６３を更新するよう転送データ管理部１５４に指示する。系間転送処理部１５８は、同期情報記憶部１５６内の更新情報ＴＢＬに記憶されている原本データのうち、他系のキャッシュサーバ１の最終更新情報ＴＢＬに設定されているラストルック以降が更新日時である原本のデータを他系のキャッシュサーバ１の転送データ記憶部１６３に書き込むとともに、書き込みが成功した場合、書き込みが成功した原本データの原本データ管理装置３における更新日時のうち最新の更新日時をラストルックとして他系のキャッシュサーバ１の最終更新情報ＴＢＬに書き込む。
【００４５】
以下、キャッシュサーバ１−０が備えるキャッシュサーバ１の各部には符号に「−０」を付加して記載し、キャッシュサーバ１−１が備えるキャッシュサーバ１の各部には符号に「−１」を付加して記載する。また、各部が０系のキャッシュサーバ１−０に備えられている旨を単に「０系の」、１系のキャッシュサーバ１−１に備えられている旨を単に「１系の」とも記載する。例えば、キャッシュサーバ１−０の備える監視処理部１１２は、「監視処理部１１２−０」、または、「０系の監視処理部１１２−０」と記載し、キャッシュサーバ１−１の備える監視処理部１１２は、「監視処理部１１２−１」、または、「１系の監視処理部１１２−１」と記載する。
【００４６】
同図において、ロードバランサ２は、タイマ２１、サービスチェック部２２、及び、運用系判断処理部２３を含んで構成される。
サービスチェック部２２は、タイマ２１により定期的に起動され、両系のキャッシュサーバ１の物理ＩＰアドレス及び参照部１１のポート番号、両系のキャッシュサーバ１の物理ＩＰアドレス及び転送部１５のポート番号を宛先に用いてヘルスチェック信号を送信し、両系のキャッシュサーバ１の参照部１１及び転送部１５から応答が返送されたか否かの結果を内部に備える記憶部２２１に書き込む。応答が返送されたか否かによって、正常か異常かの状態が識別できる。
【００４７】
運用系判断処理部２３は、自ロードバランサ２の仮想ＩＰアドレスを宛先とした信号を受信した場合に、記憶部２２１に記憶されている両系のキャッシュサーバ１の参照部１１及び転送部１５のヘルスチェックの応答受信状態、つまり、正常か異常かの状態に基づいて運用系のキャッシュサーバ１を判断する。運用系判断処理部２３は、運用系と判断したキャッシュサーバ１の物理ＩＰアドレスを宛先として受信信号を送信することにより、運用系のキャッシュサーバ１の参照部１１または転送部１５へ振り分ける。
【００４８】
以下、ロードバランサ２ａが備えるロードバランサ２の各部には符号に「ａ」を付加して記載し、ロードバランサ２ｂが備えるロードバランサ２の各部には符号に「ｂ」を付加して記載する。例えば、ロードバランサ２ａが備えるサービスチェック部２２はサービスチェック部２２ａ、ロードバランサ２ｂが備えるサービスチェック部２２はサービスチェック部２２ｂと記載する。
なお、ロードバランサ２ａとロードバランサ２ｂは異なるネットワーク装置によって実現してもよく、同一のネットワーク装置によって実現してもよい。
【００４９】
同図において、原本データ管理装置３は、データ管理部３１、更新履歴記憶部３２、及び、原本データ記憶部３３を含んで構成される。データ管理部３１は、原本データ記憶部３３に記憶されている原本データの読み書きを行ない、原本データの更新を行なったときには、更新した原本データと、その原本データの更新日時の情報とを対応付けた更新履歴を更新履歴記憶部３２に書き込む。
【００５０】
［２． 系状態確認処理］
本実施形態のキャッシュシステムにおける系状態確認処理の動作について説明する。
【００５１】
［２．１ 系状態確認シーケンス］
図４は、キャッシュシステムの系状態確認シーケンスを示す図である。同図において、キャッシュサーバ１−０、１−１の参照部１１及び転送部１５は、定期的に自機能部の自系内状態監視処理を行っている（ステップＳ１０５−１〜Ｓ１０５−４）。なお、参照部１１−０、１１−１、転送部１５−０、１５−１の間でタイミングを同期させる必要はない。
【００５２】
一方、ロードバランサ２は、定期的にヘルスチェックを起動する。つまり、ロードバランサ２は、キャッシュサーバ１−０の物理ＩＰアドレスＣ０及び参照部１１−０のポート番号ＰＳ０、キャッシュサーバ１−０の物理ＩＰアドレスＣ０及び転送部１５−０のポート番号ＰＴ０、キャッシュサーバ１−１の物理ＩＰアドレスＣ１及び参照部１１−１のポート番号ＰＳ１、キャッシュサーバ１−１の物理ＩＰアドレスＣ１及び転送部１５−１のポート番号ＰＴ１を宛先としてヘルスチェック信号を送信する（ステップＳ１１０、Ｓ１１５−１〜Ｓ１１５−４）。
【００５３】
０系の参照部１１−０は、系内状態監視結果返却処理を実行し（ステップＳ１２０−１）、ステップＳ１０５−１により確認した自系の参照部１１−０についての系内状態監視結果に応じてロードバランサ２へ応答を返送する（ステップＳ１２５−１）。０系の転送部１５−０は、系内状態監視結果返却処理を実行し（ステップＳ１２０−２）、ステップＳ１０５−２により確認した自系の転送部１５−０についての系内状態監視結果に応じてロードバランサ２へ応答を返送する（ステップＳ１２５−２）。同様に、１系の参照部１１−１は、系内状態監視結果返却処理を実行し（ステップＳ１２０−３）、ステップＳ１０５−３により確認した自系の参照部１１−１についての系内状態監視結果に応じてロードバランサ２へ応答を返送する（ステップＳ１２５−３）。また、１系の転送部１５−１は、系内状態監視結果返却処理を実行し（ステップＳ１２０−４）、ステップＳ１０５−４により確認した自系の転送部１５−１についての系内状態監視結果に応じてロードバランサ２へ応答を返送する（ステップＳ１２５−４）。
ロードバランサ２は、両系のキャッシュサーバ１の参照部１１及び転送部１５それぞれからのヘルスチェック信号への応答状態を確認し、その確認結果を保持する（ステップＳ１３０）。
【００５４】
その後も、キャッシュサーバ１−０、１−１の参照部１１、転送部１５は、ステップＳ１０５−１〜Ｓ１０５−４と同様に各機能部の自系内状態監視処理を定期的に起動する（ステップＳ１３５−１〜Ｓ１３５−４、Ｓ１４０−１〜Ｓ１４０−４）。また、ロードバランサ２は、ステップＳ１１０、Ｓ１１５−１〜Ｓ１１５−４の処理と同様に、キャッシュサーバ１−０、１−１の参照部１１及び転送部１５にヘルスチェック信号を定期的に送信する（ステップＳ１４５、Ｓ１５０−１〜Ｓ１５０−４）。これにより、ステップＳ１２０−１〜Ｓ１２０−４、Ｓ１２５−１〜Ｓ１２５−４、Ｓ１３０と同様の処理が行なわれる（ステップＳ１５５−１〜Ｓ１５５−４、Ｓ１６０−１〜Ｓ１６０−４、Ｓ１６５）。
【００５５】
上述したロードバランサ２の処理は、ロードバランサ２ａ、２ｂそれぞれについて行なわれる。
【００５６】
［２．２ 系状態確認処理における各装置の機能部間の処理の流れ］
図５は、系状態確認処理における各装置の機能部間の処理の流れを示す図である。
両系のキャッシュサーバ１の参照部１１において、監視処理部１１２は、各プロセスの生起を確認してその結果を監視結果記憶部１２１に保持し（ステップＳ３０５−１）、続いて、ダミーのＳＱＬを発行して参照データ管理部１１４の動作確認を行い、確認結果を監視結果記憶部１２１に保持する（ステップＳ３１０−１）。同様に、両系のキャッシュサーバ１の転送部１５において、監視処理部１５２は、各プロセスの生起を確認してその結果を監視結果記憶部１６１に保持し（ステップＳ３０５−２）、続いて、ダミーのＳＱＬを発行して転送データ管理部１５４の動作確認を行い、確認結果を監視結果記憶部１６１に保持する（ステップＳ３１０−２）。
【００５７】
ロードバランサ２のサービスチェック部２２は、両系のキャッシュサーバ１の参照部１１及び転送部１５それぞれにヘルスチェック信号を送信する（ステップＳ３１５−１、Ｓ３１５−２）。両系のキャッシュサーバ１の監視結果通知処理部１１３は、ヘルスチェック信号を受信すると、監視処理部１１２から監視結果記憶部１２１に保持されている系状態の監視結果を取得し（ステップＳ３２０−１）、取得した監視結果が「正常」である場合は応答を返送する（ステップＳ３２５−１）。同様に、両系のキャッシュサーバ１の監視結果通知処理部１５３は、ヘルスチェック信号を受信すると、監視処理部１５２から監視結果記憶部１６１に保持されている系状態の監視結果を取得し（ステップＳ３２０−２）、取得した監視結果が「正常」である場合は応答を返送する（ステップＳ３２５−２）。ロードバランサ２のサービスチェック部２２は、両系のキャッシュサーバ１の参照部１１及び転送部１５からの応答の有無を記憶部２２１に保持する。
【００５８】
［２．３ キャッシュサーバ１における自系内状態監視処理］
図６は、図４のステップＳ１０５−１〜Ｓ１０５−４、Ｓ１３５−１〜Ｓ１３５−４、Ｓ１４０−１〜Ｓ１４０−４において、両系のキャッシュサーバ１の参照部１１及び転送部１５が実行する自系内状態監視処理フローを示す図である。
【００５９】
まず、参照部１１における自系内状態監視処理フローを説明する。同図において、キャッシュサーバ１のタイマ１１１は、所定の時間毎に監視処理部１１２を起動する（ステップＳ４０５）。これにより、監視処理部１１２は、自系内の参照部１１の各プロセスの生起を確認する（ステップＳ４１０）。各プロセスが生起されている場合（ステップＳ４１５：正常）、正常であると判断し、続いて、ＤＢの死活状態を確認するためダミーのＳＱＬを参照データ管理部１１４に発行する（ステップＳ４２０）。参照データ管理部１１４の参照データアクセス部１２２は、ダミーのＳＱＬに基づいて参照データ記憶部１２３に記憶されているデータに対するデータ操作を行なった結果を監視処理部１１２に返送する。参照データ管理部１１４から正常にダミーＳＱＬの応答を受信した場合（ステップＳ４２５：正常）、監視処理部１１２は、監視結果「正常」を自系の備える監視結果記憶部１２１に書き込む（ステップＳ４３０）。
【００６０】
一方、プロセスが生起されていない場合（ステップＳ４１５：異常）、あるいは、参照データ管理部１１４から正常にダミーＳＱＬの応答を受信しなかった場合（ステップＳ４２５：異常）、監視処理部１１２は、監視結果「異常」を自系の備える監視結果記憶部１２１に書き込む（ステップＳ４３５）。
【００６１】
転送部１５における自系内状態監視処理フローの場合、参照部１１を転送部１５に、タイマ１１１をタイマ１５１に、監視処理部１１２を監視処理部１５２に、参照データ管理部１１４を転送データ管理部１５４に、監視結果記憶部１２１を監視結果記憶部１６１に、参照データアクセス部１２２を転送データアクセス部１６２に、参照データ記憶部１２３を転送データ記憶部１６３に読み替え、上記と同様の処理を行なう。
【００６２】
［２．４ キャッシュサーバ１における自系内状態監視結果返却処理］
図７は、図４のステップＳ１２０−１〜１２０−４、１５５−１〜１５５−４において、両系のキャッシュサーバ１の参照部１１及び転送部１５が実行する自系内状態監視結果返却処理フローを示す図である。
【００６３】
まず、参照部１１における自系内状態監視結果返却処理フローを説明する。同図において、キャッシュサーバ１の監視結果通知処理部１１３は、ロードバランサ２からヘルスチェック信号を受信する（ステップＳ５０５）。監視結果通知処理部１１３は、監視処理部１１２から監視結果記憶部１２１に記憶されている系内状態の監視結果を取得する（ステップＳ５１０）。監視結果通知処理部１１３は、取得した系内状態監視結果が「正常」である場合は（ステップＳ５１５：正常）、ヘルスチェック信号送信元のロードバランサ２に正常を設定した応答を返送し（ステップＳ５２０）、系内状態監視結果が「異常」である場合は（ステップＳ５１５：異常）、受信したヘルスチェック信号を廃棄し、応答を返送しない（ステップＳ５２５）。
【００６４】
転送部１５における自系内状態監視結果返却処理フローの場合、監視処理部１１２を監視処理部１５２に、監視結果通知処理部１１３を監視結果通知処理部１５３に、監視結果記憶部１２１を監視結果記憶部１６１に読み替え、上記と同様の処理を行なう。
【００６５】
［２．５ ロードバランサ２におけるヘルスチェック］
図８は、図４のステップＳ１１０及びＳ１３０、Ｓ１４５及びＳ１５５において実行される、ロードバランサ２のヘルスチェック処理フローを示す図である。
同図において、ロードバランサ２のタイマ２１は、所定の時間毎にサービスチェック部２２を起動する（ステップＳ６０５）。まず、０系の参照部１１についてのヘルスチェックが起動された場合について説明する。サービスチェック部２２は、キャッシュサーバ１−０の物理ＩＰアドレスＣ０、参照部１１−０のポート番号ＰＳ０を宛先としてヘルスチェック信号を送信する（ステップＳ６１０）。
【００６６】
サービスチェック部２２は、ステップＳ６１０において送信したヘルスチェック信号に対して、図７のステップＳ５２０においてキャッシュサーバ１の監視結果通知処理部１１３が送信した応答を受信した場合（ステップＳ６１５：応答あり）、参照部１１−０の識別情報と対応付けて「応答あり」を記憶部２２１に書き込む（ステップＳ６２０）。
一方、ステップＳ６１０において送信したヘルスチェック信号に対して所定時間内に応答を受信しなかった場合（ステップＳ６１５：応答なし）、参照部１１−０の識別情報と対応付けて「応答なし」を記憶部２２１に書き込む（ステップＳ６２５）。
【００６７】
ステップＳ６０５において、０系の転送部１５−０についてのヘルスチェックが起動された場合、ステップＳ６１０において、サービスチェック部２２は、キャッシュサーバ１−０の物理ＩＰアドレスＣ０、転送部１５−０のポート番号ＰＴ０を宛先としてヘルスチェック信号を送信する。そして、ステップＳ６２０においては、転送部１５−０の識別情報と対応付けて「応答あり」を、ステップＳ６２５においては、転送部１５−０の識別情報と対応付けて「応答なし」を記憶部２２１に書き込む。
【００６８】
同様に、ステップＳ６０５において、１系の参照部１１−１についてのヘルスチェックが起動された場合、ステップＳ６１０において、サービスチェック部２２は、キャッシュサーバ１−１の物理ＩＰアドレスＣ１、参照部１１−１のポート番号ＰＳ１を宛先としてヘルスチェック信号を送信する。そして、ステップＳ６２０においては、参照部１１−１の識別情報と対応付けて「応答あり」を、ステップＳ６２５においては、参照部１１−１の識別情報と対応付けて「応答なし」を記憶部２２１に書き込む。
【００６９】
また、ステップＳ６０５において、１系の転送部１５−１についてのヘルスチェックが起動された場合、ステップＳ６１０において、サービスチェック部２２は、キャッシュサーバ１−１の物理ＩＰアドレスＣ１、転送部１５−１のポート番号ＰＴ１を宛先としてヘルスチェック信号を送信する。そして、ステップＳ６２０においては、転送部１５−１の識別情報と対応付けて「応答あり」を、ステップＳ６２５においては、転送部１５−１の識別情報と対応付けて「応答なし」を記憶部２２１に書き込む。
【００７０】
［３． 振分処理］
ロードバランサ２ａ、２ｂは、上述したヘルスチェックにより、キャッシュサーバ１−０、１−１の参照部１１及び転送部１５それぞれが正常であるか異常であるかを判定するためのヘルスチェック結果を保持する。つまり、応答が返送された場合は運用状態が正常、応答が返送されなかった場合は異常であると判断することができる。そして、ロードバランサ２ａは、アプリケーション装置４からのデータ参照要求を受信するたびに、ヘルスチェック結果を利用して運用系のキャッシュサーバ１を決定し、データ参照要求の振分処理を行なう。また、ロードバランサ２ｂは、キャッシュサーバ１から系状態識別信号を受信するたびに、同様の振分処理を行う。以下、振分処理の動作について説明する。
【００７１】
［３．１ 振分処理シーケンス］
図９は、アプリケーション装置４からのデータ参照要求受信時の振分処理シーケンスを示す図である。
同図において、ロードバランサ２ａは、アプリケーション装置４から、ロードバランサ２ａの仮想ＩＰアドレスＡを宛先としたデータ参照要求を受信する（ステップＳ７０５）。ロードバランサ２は、ヘルスチェック処理結果を参照して、運用系のキャッシュサーバ１を判断する（ステップＳ７１０）。ここでは、キャッシュサーバ１−０が運用系であると判断したと仮定する。ロードバランサ２は、データ参照要求の宛先を、運用系であるキャッシュサーバ１−０の物理ＩＰアドレスＣ０及び参照部１１−０のポート番号ＰＳ０として送信する（ステップＳ７１５）。０系の参照部１１−０は、受信したデータ参照要求に対する応答を返送すると（ステップＳ７２０）、ロードバランサ２ａは、データ参照要求の送信元であるアプリケーション装置４へ応答を送信する（ステップＳ７２５）。
【００７２】
ロードバランサ２ａは、アプリケーション装置４から、ロードバランサ２ａの仮想ＩＰアドレスＡを宛先としたデータ参照要求を受信するたびに、ヘルスチェック処理結果を参照して、運用系のキャッシュサーバ１を判断する。つまり、同図に示すように、ロードバランサ２ａは、再びアプリケーション装置４からデータ参照要求を受信すると（ステップＳ７３０）、ヘルスチェック処理結果を参照して、運用系のキャッシュサーバ１を判断する（ステップＳ７３５）。以降のステップＳ７４５〜Ｓ７５０の処理は、ステップＳ７１５〜Ｓ７２０の処理と同様である。
【００７３】
なお、振分処理において、ロードバランサ２ａが、運用系はキャッシュサーバ１−１であると判断した場合、アプリケーション装置４から受信したデータ参照要求の宛先を、運用系であるキャッシュサーバ１−１の物理ＩＰアドレスＣ１及び参照部１１−１のポート番号ＰＳ１として送信する。そして、１系の参照部１１−１がデータ参照要求に対する応答を返送すると、ロードバランサ２ａは、データ参照要求の送信元であるアプリケーション装置４へ応答を送信する。
【００７４】
図１０は、キャッシュサーバ１からの系状態識別信号受信時の振分処理シーケンスを示す図である。
同図において、ロードバランサ２ｂは、０系の転送部１５−０からロードバランサ２ｂの仮想ＩＰアドレスＢを宛先とした系状態識別信号を受信する（ステップＳ８０５）。ロードバランサ２ｂは、ヘルスチェック処理結果を参照して、運用系のキャッシュサーバ１を判断する（ステップＳ８１０）。ここでは、キャッシュサーバ１−０が運用系であると判断したと仮定する。ロードバランサ２ｂは、系状態識別信号の宛先を、運用系であるキャッシュサーバ１−０の物理ＩＰアドレスＣ０及び転送部１５−０のポート番号ＰＴ０として送信する（ステップＳ８１５）。０系の転送部１５−０は、自系が送信した系状態識別信号を受信するため、運用系であることを認識する。
【００７５】
同様に、ロードバランサ２ｂは、１系の転送部１５−１からロードバランサ２ｂの仮想ＩＰアドレスＢを宛先とした系状態識別信号を受信する（ステップＳ８２０）。ロードバランサ２ｂは、ヘルスチェック処理結果を参照し、キャッシュサーバ１−０が運用系であると判断したと仮定する（ステップＳ８２５）。ロードバランサ２ｂは、系状態識別信号の宛先を、運用系であるキャッシュサーバ１−０の物理ＩＰアドレスＣ０及びポート番号ＰＴ０として送信する（ステップＳ８３０）。１系の転送部１５−１は、自系が送信した系状態識別信号を受信できないため、待機系であることを認識する。
【００７６】
なお、振分処理において、ロードバランサ２ｂが、運用系はキャッシュサーバ１−１であると判断した場合、キャッシュサーバ１−０、１−１から受信した系状態識別信号の宛先を、運用系であるキャッシュサーバ１−１の物理ＩＰアドレスＣ１及び転送部１５−１のポート番号ＰＴ１として送信する。これにより、１系の転送部１５−１は、自系が送信した系状態識別信号を受信するため、運用系であることを認識し、０系の転送部１５−０は、自系が送信した系状態識別信号を受信できないため、待機系であることを認識する。
【００７７】
［３．２ ロードバランサ２における振分処理］
図１１は、ロードバランサ２ａにおける振分処理フローを示す図である。
同図においてロードバランサ２ａは、ロードバランサ２ａの仮想ＩＰアドレスＡを宛先としたデータ参照要求をアプリケーション装置４から受信したことを契機に、運用系判断処理部２３ａを起動する（ステップＳ９０５）。運用系判断処理部２３ａは、サービスチェック部２２ａの記憶部２２１ａから、０系の参照部１１−０及び転送部１５−０、１系の参照部１１−１及び転送部１５−１それぞれからのヘルスチェック信号の応答ありなしの結果を読み出すとともに（ステップＳ９１０）、運用フラグを読み出し、保持する（ステップＳ９１５）。なお、運用フラグとは、０系及び１系の参照部１１の応答状態が同じであり、かつ、０系及び１系の転送部１５の応答状態が同じである場合など、応答の状態からは運用系を決定することができない場合に参照するフラグであり、０系を振分先とする場合は「０」、１系を振分先とする場合は「１」、０系及び１系とも振分不可である場合は「３」の値をとる。通常は、システム開始時に初期値として「０」か「１」を設定する。
【００７８】
続いて、運用系判断処理部２３ａは、図１２に示す振分け状態表に従い、振分け状態を判断する（ステップＳ９２０）。
すなわち、運用系判断処理部２３ａは、０系及び１系の参照部１１の両方から応答があり、かつ、０系及び１系の転送部１５の応答有無の状態が同じであった場合は振分状態「２」とする。また、０系の参照部１１−０から応答があり、１系の参照部１１−１から応答がなかった場合、あるいは、０系及び１系の参照部１１、ならびに、０系の転送部１５−０から応答があり、１系の転送部１５−１から応答がなかった場合は振分状態「０」とする。また、０系の参照部１１−０から応答がなく、１系の参照部１１−１から応答があった場合、あるいは、０系及び１系の参照部１１、ならびに、１系の転送部１５−１から応答があり、０系の転送部１５−０から応答がなかった場合は振分状態「１」とする。また、０系及び１系の参照部１１の両方から応答がなかった場合は振分け状態「３」と判断する。
【００７９】
振分け状態が「０」であると判断した場合（ステップＳ９２０：振分け状態０）、運用系判断処理部２３ａは、ステップＳ９０５において受信したデータ参照要求の宛先をキャッシュサーバ１−０の物理ＩＰアドレスＣ０及び参照部１１−０のポート番号ＰＳ０として送信し（ステップＳ９２５）、記憶部２２１ａに記憶されている運用フラグに振分け状態の値を設定する（ステップＳ９３０）。これにより、運用フラグには「０」が設定される。
【００８０】
振分け状態が「１」であると判断した場合（ステップＳ９２０：振分け状態１）、運用系判断処理部２３ａは、ステップＳ９０５において受信したデータ参照要求の宛先をキャッシュサーバ１−１の物理ＩＰアドレスＣ１及び参照部１１−１のポート番号ＰＳ１として送信し（ステップＳ９３５）、記憶部２２１ａに記憶されている運用フラグに振分け状態の値を設定する（ステップＳ９３０）。これにより、運用フラグには「１」が設定される。
【００８１】
振分け状態が「２」であると判断した場合（ステップＳ９２０：振分け状態２）、０系１系とも正常に動作しているため、応答の状態からはどちらのキャッシュサーバ１を運用系、待機系とするかを判断することはできない。そこで、運用系判断処理部２３ａは、さらに、ステップＳ９１５にお保持していた運用フラグを取得し（ステップＳ９４０）、値が「０」または「１」であるかを判断する（ステップＳ９４５）。
運用フラグが「０」または「１」である場合（ステップＳ９４５：真）、運用系判断処理部２３ａは、運用フラグにおいて示される系のキャッシュサーバ１にステップＳ９０５において受信したデータ参照要求を送信する（ステップＳ９５０）。つまり、運用フラグが「０」である場合は、データ参照要求の宛先アドレスをキャッシュサーバ１−０の物理ＩＰアドレスＣ０及び参照部１１−０のポート番号ＰＳ０に変換して送信し、運用フラグが「１」である場合は、データ参照要求の宛先アドレスをキャッシュサーバ１−１の物理ＩＰアドレスＣ１及び参照部１１−１のポート番号ＰＳ１に変換して送信する。これにより、０系１系の両方が正常に動作している間は同じ系が振分先となる。
【００８２】
一方、運用フラグが「０」でも「１」でもない場合（ステップＳ９４５：偽）、運用系判断処理部２３ａは、０系を振分先とする。運用系判断処理部２３ａは、ステップＳ９０５において受信したデータ参照要求の宛先アドレスをキャッシュサーバ１−０の物理ＩＰアドレスＣ０及び参照部１１−０のポート番号ＰＳ０に変換して送信し（ステップＳ９５５）、運用フラグへ「０」を設定する（ステップＳ９６０）。従って、０系及び１系の両方に異常が発生した後、同時に正常に戻った場合には、０系を振分先とする。
【００８３】
振分け状態「３」であると判断した場合（ステップＳ９２０：振分け状態３）、０系、１系ともに異常が発生しているため、運用系判断処理部２３ａは、ステップＳ９０５において受信したデータ参照要求に対するエラー応答をアプリケーション装置４へ返送し（ステップＳ９６５）、運用フラグへ「３」を設定する（ステップＳ９７０）。
【００８４】
図１３は、ロードバランサ２ｂにおける振分処理の処理フローを示す図である。
同図においてロードバランサ２ｂは、ロードバランサ２ｂの仮想ＩＰアドレスＢを宛先とした系状態識別信号をキャッシュサーバ１から受信したことを契機に、運用系判断処理部２３ｂを起動する（ステップＳ１００５）。
ステップＳ１０１０以降の処理は、図１１に示すステップＳ９１０以降の処理と同様であり、振分け状態表も同じ設定内容である。ただし、運用系判断処理部２３ａ、記憶部２２１ａ、参照部１１−０のポート番号ＰＳ０、参照部１１−１のポート番号ＰＳ１はそれぞれ、運用系判断処理部２３ｂ、記憶部２２１ｂ、転送部１５−０のポート番号ＰＴ０、転送部１５−１のポート番号ＰＴ１と読み替え、ステップＳ９０５においてアプリケーション装置４から受信したデータ参照要求は、ステップＳ１００５においてキャッシュサーバ１から受信した系状態識別信号と読み替える。よって、ステップＳ１０６５においてはエラー応答を系状態識別信号の送信元のキャッシュサーバ１の転送部１５に返送することになる。
【００８５】
［４． データ同期処理］
キャッシュシステムでは、原本データ管理装置３が記憶する実データとの同期をとりつつ、キャッシュサーバ１−０、１−１間でデータの同期をとる必要がある。以下では、本実施形態のデータ同期方法を採用した理由について説明した後、本実施の形態によるキャッシュシステムにおける同期処理の動作について説明する。
【００８６】
［４．１ データ同期方法の検討過程］
図１４は、本実施の形態によるキャッシュシステムへの適用を検討した原本データ同期方法を示す図である。
図１４（ａ）は、原本データ管理装置３から両系のキャッシュサーバ１それぞれに対して実データを反映させる方法である。この方法では、両系のキャッシュサーバ１間でデータの同期を行なう必要がない。しかし、原本データ管理装置３に負荷がかかるとともに、同期のための機能を追加しなければならず、また、原本データ管理装置３からの実データの転送時にミスが発生した場合、キャッシュサーバ１では実データとの差分を反映できないままとなるという問題がある。加えて、両系のキャッシュサーバ１が記憶するデータの整合性が担保できず、系切り替え時にデータの同期がとれなくなってしまうおそれがあり、リダンダンシそのものが実現できないという問題もある。
【００８７】
図１４（ｂ）は、原本データ管理装置３から一方のキャッシュサーバ１のみ対して実データを反映させ、その後、キャッシュサーバ１の系間でデータの同期をとる方法である。この方法では、原本データ管理装置３に原本データ書き込みのための機能を追加しなければならず、また、原本データ管理装置３からの実データの転送時に時にミスが発生した場合、キャッシュサーバ１では実データとの差分を反映できないままとなるという問題がある。さらには、原本データ管理装置３において、キャッシュサーバ１に系切替えが発生している場合についての動作を考慮しなければならず、系切り替え時データの同期がとれなくなってしまうおそれがあり、リダンダンシそのものが実現できないという問題もある。
【００８８】
図１４（ｃ）は、一方のキャッシュサーバ１が定期的に原本データ管理装置３から原本データを読み出し、系間でデータの同期をとる方法である。この方法の場合、考慮すべき点はあるものの、系切り替えに伴うデータロストの最小化といったリダンダンシの根幹に係る条件をクリアしている。
そこで、本実施形態では、図１４（ｃ）の方法をベースとして、運用系、待機系を認識せずに動作しているキャッシュサーバ１のどちらが原本データとの同期を行なうかを決定する処理を追加するとともに、系間においてデータ同期がどこまで行なわれたかを管理可能な系間同期方法を追加した。
【００８９】
独立した２つのキャッシュサーバ１のどちらが原本データとの同期を行なうかについては、図１０等においても説明したように、各々のキャッシュサーバ１がロードバランサ２ｂの仮想ＩＰアドレス宛てにダミーリクエスト、つまり、系状態識別信号を送信し、そのリクエストの応答返却をもって同期を行なう側であることを認識し、データ同期処理を起動する。
【００９０】
図１５は、本実施の形態によるキャッシュシステムへの適用を検討した系間の同期方法を示す図である。
図１５（ａ）は、既存のＤＢＭＳが持つデータ同期機能を用いる方法を示す図である。本実施の形態においては、両系のキャッシュサーバ１は自系の状態、他系の系状態とも意識せず、外部のネットワーク装置であるロードバランサ２によって系が切り替えられる。つまり、ロードバランサ２による切り替えは、既存のＤＢＭＳのリンク機能が持つ系間同期の状態とは無関係に行なわれることになる。よって、既存のＤＢＭＳのリンク機能自体は系が切り替えを行なわれたことを認識できず、正しくデータ同期を行なうことはできない。また、既存のＤＢＳＭでは、障害時のデータ紛失を回復する機能が適用されておらず、ＤＢインスタンスの再起動が必要となることがあり、適切ではない。
【００９１】
図１５（ｂ）は、原本データとは同期しない系のキャッシュサーバ１が、原本データと同期する側のキャッシュサーバ１から更新されたデータを吸い上げる方法である。この方法の場合、原本データとの同期の処理、系間の同期の処理が両系に分散しているため、系切り替え時にデータの不整合が発生する可能性があるとともに、系障害時、旧サービスルート側に残ったデータの消去ができないという問題がある。また、両系のキャッシュサーバ１において系の状態を意識しなくてはならず、本実施形態にはそぐわない。
【００９２】
図１５（ｃ）は、原本データと同期する系のキャッシュサーバ１が、原本データと同期しない側のキャッシュサーバ１へ更新されたデータを書き込む方法である。この方法の場合、原本データとの同期を行なう系のキャッシュサーバ１において、系間の同期の処理も行なうためにデータ同期処理が片方の系に集約され、系切り替え時にデータの不整合が発生することを防ぐことができる。
そこで、図１５（ｃ）の方法を系間の同期方法として採用し、以下のようにデータ同期がどこまで行なわれたかの管理方法を追加した。
【００９３】
つまり、図１５（ｃ）の方法では、系間でデータの転送中に系切り替えが発生するなどして、新しく原本データと同期する側になった系は、どの時点から原本データとの同期を行なえばよいかを把握することができない。そこで、データ同期がどこまで行なわれたかを、原本データ管理装置３において原本データが更新されたときに付与されたタイムスタンプを利用して管理する。具体的には、原本データと同期する系のキャッシュサーバ１は、原本データ管理装置３から更新された原本データを読み出すときは、その各原本データの更新日時とともに読み出し、その中で最新の更新日時を同期日時として保持する。そして、原本データと同期しない側のキャッシュサーバ１へ更新された原本データを書き込むときには、同期日時も同時に通知する。これにより、次に同期を行なうタイミングのときに、原本データと同期する系のキャッシュサーバ１は、自系が保持している同期日時以降が更新日時である原本データを原本データ管理装置３から読み出せばよい。
【００９４】
［４．２ データ同期シーケンス］
図１６は、キャッシュシステムのデータ同期シーケンスを示す図である。
同図は、キャッシュサーバ１−０が運用系、キャッシュサーバ１−１が待機系であるとロードバランサ２ｂに判断されている場合の例を示す。
両系のキャッシュサーバ１の転送部１５は、定期的に系状態識別処理を起動し、系状態識別信号をロードバランサ２ｂに送信している。同図において、０系の転送部１５−０が、ロードバランサ２ｂに対して系状態識別信号を送信すると、図１０のステップＳ８０５〜Ｓ８１５の処理が行なわれる（ステップＳ１１０５）。
【００９５】
ロードバランサ２ｂが、キャッシュサーバ１−０を運用系と判断しているため、０系の転送部１５−０は自系の送信した系状態識別信号を受信する。これにより、転送部１５−０は、自系が運用系であると判断し、処理を継続することを決定して（ステップＳ１１１０）、原本データとの同期処理を起動する（ステップＳ１１１５）。転送部１５−０は、原本データ管理装置３に原本データ取得を送信し（ステップＳ１１２０）、原本データ管理装置３のデータ管理部３１は、原本データ記憶部３３から原本データを読み出して（ステップＳ１１２５）、転送部１５−０に返送する（ステップＳ１１３０）。転送部１５−０は、受信した原本データにより、転送データ記憶部１６３−０に記憶されているデータを更新した後（ステップＳ１１３５）、系間同期処理を行なう（ステップＳ１１４０）。すなわち０系の転送部１５−０は、１系の転送部１５−１に更新対象の原本データを送信し（ステップＳ１１４５）、転送部１５−１は、受信した原本データにより転送データ記憶部１６３−１に記憶されているデータを更新する（ステップＳ１１５０）。更新が正常に終了した場合、１系の転送部１５−１は、０系の転送部１５−０に正常応答を返送する（ステップＳ１１５５）。
【００９６】
一方、１系の転送部１５−１も、ロードバランサ２ｂに対して系状態識別信号を送信している。これにより、同様に、図１０のステップＳ８２０〜Ｓ８３０の処理が行なわれる（ステップＳ１１６０）。上述したように、ロードバランサ２ｂはキャッシュサーバ１−０を運用系と判断しているため、系状態識別信号は０系の転送部１５−０へ送信される。転送部１５−１は自系が送信した系状態識別信号を受信できないため、自系が待機系であると判断して処理を終了する（ステップＳ１１６５）。
【００９７】
両系のキャッシュサーバ１の転送部１５はステップＳ１１０５、Ｓ１１６０の処理を定期的に起動し、運用系と待機系の入れ替えがない間は、上述したステップＳ１１０５〜Ｓ１１６５の処理を繰り返す。系状態が入れ替わり、キャッシュサーバ１−１が運用系となったときには、上記処理における０系の転送部１５−０と１系の転送部１５−１の動作が入れ替わる。
【００９８】
［４．３ データ同期処理に用いられるデータ］
図１７は、データ同期処理に用いられる各装置のデータ例を示す図である。ここでは、キャッシュサーバ１−０が運用系、キャッシュサーバ１−１が待機系であるとロードバランサ２ｂに判断されている場合の例を示す。
【００９９】
原本データ管理装置３は、原本データ記憶部３３に、アプリケーション装置４が利用する各種情報の原本データである「情報１」、「情報２」、「情報３」、「情報４」、・・・を記憶している。また、更新履歴記憶部３２には、更新された原本データである「情報１」、「情報２」、「情報３」、「情報４」と、それらの更新日時「００：００：０１」、「００：００：０２」、「００：００：０３」、「００：００：０４」とを対応付けた更新履歴ＴＢＬを記憶している。なお、原本データ管理装置３のデータ管理部３１は、原本データ記憶部３３に記憶されている原本データが更新されると、随時、更新履歴記憶部３２内の更新履歴ＴＢＬに更新された原本データとその更新日時とを対応付けて書き込んでいる。
【０１００】
運用系であるとみなされている０系の転送部１５−０が備える転送データ記憶部１６３−０には、原本データ管理装置３から読み出された原本データのコピー（キャッシュデータ）である「情報１」、「情報２」が記憶されている。また、同期情報記憶部１５６−０の更新情報ＴＢＬには、転送データ記憶部１６３−０には書き込んだが、まだキャッシュサーバ１−１との同期更新を行なっていない原本データ「情報２」とその更新日時「００：００：０２」とが対応付けて設定されている。さらに、同期情報記憶部１５６−０が記憶する最終更新情報ＴＢＬには、転送データ記憶部１６３−０に書き込みが終了した原本データの更新日時のうち、最新の更新日時であるラストルック「００：００：０２」が設定されている。
【０１０１】
待機系であるとみなされている１系の転送部１５−１が備える転送データ記憶部１６３−１には、原本データ管理装置３から読み出された原本データのコピー（キャッシュデータ）である「情報１」が記憶されている。また、同期情報記憶部１５６−１が記憶する最終更新情報ＴＢＬには、転送データ記憶部１６３−１に書き込みが終了した原本データの更新日時のうち、最新の更新日時であるラストルック「００：００：０１」が設定されている。待機系の場合、原本データ管理装置３から直接原本データを読み出さないため、通常、同期情報記憶部１５６−１の更新情報ＴＢＬは空である。
【０１０２】
［４．４ データ更新の流れ］
図１８は、原本データ同期処理におけるデータ更新の流れを示す図であり、図１７の状態から更新を行なう例を示す。
同図において、自系が運用系であることを認識した０系の転送部１５−０は、最終更新情報ＴＢＬに設定されているラストルックを取得し、この取得したラストルックと原本データ取得要求とを原本データ管理装置３に送信する（ステップＳ１２０５）。原本データ管理装置３のデータ管理部３１は、更新履歴記憶部３２内の更新履歴ＴＢＬを検索してラストルック以降が更新日時である原本データを特定し、特定した原本データとその更新日時をキャッシュサーバ１−０へ返送する。同図においては、原本データ管理装置３は、キャッシュサーバ１−０からラストルック「００：００：０２」を受信し、原本データ「情報３」とその更新日時「００：００：０３」、原本データ「情報４」とその更新日時「００：００：０４」を返送している。
【０１０３】
０系の転送部１５−０は、原本データ管理装置３から受信した原本データ「情報３」及び「情報４」を転送データ記憶部１６３−０に書き込むと（ステップＳ１２１０）、更新したこれらの原本データの更新日時のうち、最新の更新日時「００：００：０４」により最終更新情報ＴＢＬのラストルックを上書きする（ステップＳ１２１５）。
【０１０４】
なお、上記においては、０系の転送部１５−０は、最終更新情報ＴＢＬに設定されているラストルックを原本データ取得要求とともに原本データ管理装置３に送信しているが、ラストルックから所定の時間だけ遡った日時を送信してもよい。原本データ管理装置３のデータ管理部３１は、更新履歴ＴＢＬを検索して受信した日時以降が更新日時である原本データを特定し、特定した原本データとその更新日時を返送する。
【０１０５】
図１９は、系間データ同期処理におけるデータ更新の流れを示す図であり、図１８に示す処理に続いて実行する場合の例を示す。
図１８のステップＳ１２１５の処理の前または後、０系の転送部１５−０は、更新情報ＴＢＬに、ステップＳ１２１０において受信した原本データ「情報３」とその更新日時「００：００：０３」、原本データ「情報４」とその更新日時「００：００：０４」を追加して書き込む（ステップＳ１３０５）。
【０１０６】
０系の転送部１５−０は、１系の転送部１５−１が保持する最終更新情報ＴＢＬからラストルック「００：００：０１」を読み出すと、自系が保持する更新情報ＴＢＬに設定されている更新日時と比較する（ステップＳ１３１０）。０系の転送部１５−０は、１系の転送部１５−１から読み出したラストルック以降が更新日時である更新情報ＴＢＬ内の原本データを特定し、特定した原本データにより１系の転送部１５−１が備える転送データ記憶部１６３−１に記憶されている情報を更新する。これにより、キャッシュサーバ１−１の転送データ記憶部１６３−１に、「情報２」、「情報３」、「情報４」が書き込まれる（ステップＳ１３１５）。
【０１０７】
０系の転送部１５−０は、ステップＳ１３１５において１系の転送データ記憶部１６３−１に書き込んだ原本データの更新日時のうち、最新の更新日時「００：００：０４」をラストルックとして１系の転送部１５−１が記憶している最終更新情報ＴＢＬに書き込む（ステップＳ１３２０）。０系の転送部１５−０は、１系の転送部１５−１に書き込んだ原本データである「情報２」、「情報３」、「情報４」を更新情報ＴＢＬから削除する。
【０１０８】
［４．５ キャッシュサーバ１における更新処理］
図２０は、図１６のステップＳ１１０５、Ｓ１１６０において、両系のキャッシュサーバ１の転送部１５が実行する系状態識別処理フローを示す。
同図において、キャッシュサーバ１のタイマ１５１は、所定の時間毎に系状態識別処理を起動し、これにより、系状態識別部１５５は、ロードバランサ２ｂの仮想ＩＰアドレスＢ宛に系状態識別信号を送信する（ステップＳ１４０５）。ロードバランサ２ｂは、図１３に示す振分処理を行い、受信した系状態識別信号を運用系と判断しているキャッシュサーバ１に送信する。
【０１０９】
ステップＳ１４０５において系状態識別信号を送信した後、自系が送信したこの系状態識別信号を受信できなかった場合（ステップＳ１４１０：到達しない）、系状態識別部１５５は、自系が現在待機系であると判断し、その系状態を保持する（ステップＳ１４１５）。
【０１１０】
ステップＳ１４０５において系状態識別信号を送信した後、自系が送信したこの系状態識別信号を受信した場合（ステップＳ１４１０：到達した）、系状態識別部１５５は、自系が現在運用系であると判断してその系状態を保持する（ステップＳ１４２０）。なお、自系が送信した系状態識別信号を受信したかについては、受信した系状態識別信号に設定されている送信元ＩＰアドレスが自系の物理ＩＰアドレスであるかにより判断することができる。
【０１１１】
図２１は、図１６のステップＳ１１１０〜Ｓ１１３５、Ｓ１１６５において、両系のキャッシュサーバ１の転送部１５が実行する原本データとの同期処理フローを示す。
両系のキャッシュサーバ１の転送部１５は、図２０に示す系状態識別処理が終了すると、原本データとの同期処理を起動する。これにより、情報転送処理部１５７は、系状態識別部１５５が保持している自系の系状態を判断する（ステップＳ１５０５）。自系の系状態が待機系である場合（ステップＳ１５０５：待機系）、情報転送処理部１５７は処理を終了する。
【０１１２】
自系の系状態が運用系である場合（ステップＳ１５０５：運用系）、情報転送処理部１５７は、自系の同期情報記憶部１５６に記憶されている最終更新情報ＴＢＬからラストルックを読み出す（ステップＳ１５１０）。続いて、情報転送処理部１５７は、取得したラストルックと、原本データ取得要求を原本データ管理装置３に送信することにより、原本データ管理装置３からラストルック以降が更新日時である原本データとその更新日時の情報を取得する（ステップＳ１５１５）。情報転送処理部１５７が、ステップＳ１５１５において取得した原本データの書き込みを自系の転送データ管理部１５４に指示すると、転送データアクセス部１６２は、転送データ記憶部１６３に取得した原本データを書き込む（ステップＳ１５２０）。情報転送処理部１５７は、書き込みが終了した原本データと、原本データ管理装置３から受信したその原本データの更新日時とを対応づけて、自系の同期情報記憶部１５６が記憶している更新情報ＴＢＬに登録する（ステップＳ１５２５）。情報転送処理部１５７は、ステップＳ１５２５において登録した情報に対応した更新日時のうち最も新しい更新日時をラストルックとして、自系の同期情報記憶部１５６が記憶している最終更新情報ＴＢＬに書き込む（ステップＳ１５３０）。
【０１１３】
図２２は、図１６のステップＳ１１４０において、運用系のキャッシュサーバ１の転送部１５が実行する系間データ同期処理フローを示す。
図２１のステップＳ１５０５において自系の系状態が運用系であると判断したキャッシュサーバ１の転送部１５は、図２１に示す原本データとの同期処理が終了すると、続いて系間データ同期処理を起動する。これにより、運用系のキャッシュサーバ１の系間転送処理部１５８は、自系の同期情報記憶部１５６に記憶されている更新情報ＴＢＬから原本データとその更新日時とを取得する（ステップＳ１６０５）。さらに、系間転送処理部１５８は、他系、つまり、現在待機系であるキャッシュサーバ１の同期情報記憶部１５６に記憶されている最終更新情報ＴＢＬからラストルックを読み出す（ステップＳ１６１０）。
【０１１４】
ステップＳ１６０５において取得した、転送データ記憶部１６３に反映済みの原本データの更新日時が、ステップＳ１６１０において取得した待機系のラストルックよりも新しい場合（ステップＳ１６１５：運用系のほうが新しい）、運用系の系間転送処理部１５８は、待機系のキャッシュサーバ１の転送データ管理部１５４に、ステップＳ１６０５において取得した原本データの書き込みを指示する（ステップＳ１６２０）。これにより、待機系のキャッシュサーバ１の転送データアクセス部１６２は、自系の転送データ記憶部１６３に指示された原本データを書き込む。
【０１１５】
続いて運用系のキャッシュサーバ１の系間転送処理部１５８は、ステップＳ１６２０で待機系のキャッシュサーバ１に書き込んだ原本データに対応した原本データ管理装置３における更新日時のうち、最新の更新日時をラストルックとして待機系のキャッシュサーバ１の同期情報記憶部１５６が記憶する最終更新情報ＴＢＬに書き込む（ステップＳ１６２５）。運用系のキャッシュサーバ１の系間転送処理部１５８は、ステップＳ１６２０において、待機系のキャッシュサーバ１の転送データ記憶部１６３に書き込んだ原本データ及びその更新日時を、自系の転送データ記憶部１６３に記憶されている更新情報ＴＢＬから削除する（ステップＳ１６３０）。
【０１１６】
なお、ステップＳ１６１０において取得した待機系のラストルックが、ステップＳ１６０５において取得した、自系の転送データ記憶部１６３に反映済みの原本データの更新日時よりも新しい場合（ステップＳ１６１５：待機系のほうが新しい）、処理を終了する。
【０１１７】
両系のキャッシュサーバ１は、以下のように定期的に系内データ同期処理を行う。
キャッシュサーバ１の参照部１１において、タイマ１１１により系内同期処理部１１６が定期的に起動される。起動された系内同期処理部１１６は、転送部１５へ系内データ同期を要求する。転送部１５の系内同期処理部１５９は、参照部１１の系内同期処理部１１６から系内データ同期を受信すると、転送データアクセス部１６２が転送データ記憶部１６３から読み出した原本データを返送する。参照部１１の系内同期処理部１１６は、転送部１５の系内同期処理部１５９から受信した原本データの書き込みを参照データアクセス部１２２へ指示し、参照データアクセス部１２２は、系内同期処理部１１６が受信した原本データを参照データ記憶部１２３へ書き込む。
【０１１８】
［５．汎用インタフェース］
本実施の形態のキャッシュシステムは、複数のアプリケーション装置４からデータ参照要求を受信する。しかし、アプリケーション装置４において実行されている上位サービスアプリケーションそれぞれに対して独自のインタフェース（以下、ＩＦと記載）を定義すると、上位サービスアプリケーションの追加のたびにＩＦの実装が必要となってしまう。そこで、汎用的なＩＦ定義によりデータアクセスを行なう機能を実装し、上位サービスアプリケーションの追加に伴う開発を不要にする。
【０１１９】
汎用ＩＦ定義では、１つのＩＦ定義によって、複数の上位サービスアプリケーションが用いる複数パターンのデータ参照要求及びその応答、すなわち、ＩＮパラメータ及びＯＵＴパラメータに対応する。従って、新たなデータ参照要求及び応答のパターンが発生した場合でも設定ファイルの変更を行なうのみでよく、ＩＦ開発は不要である。
【０１２０】
図２３は、汎用ＩＦの動作概要を示す図である。同図において、アプリケーション装置４は、データ参照要求を送信する。データ参照要求は、汎用インタフェースを用いて記述したＩＮ電文であり、変換ルールを特定する識別子と、検索キーとして用いられるＩＮ項目とが設定され、ＨＴＴＰ（Hypertext Transfer Protocol）−ＳＯＡＰ（Simple Object Access Protocol）により送信される。ロードバランサ２ａによってデータ参照要求が運用系のキャッシュサーバ１に振り分けられ、運用系のキャッシュサーバ１の情報参照処理部１１５は、データ参照要求に設定されている識別子により特定される変換ルールを、情報参照処理部１１５が備えるルール記憶部１２４から取得する（ステップＳ１７０５）。
【０１２１】
ルール記憶部１２４は、識別子毎に変換ルールを記憶しており、変換ルールには、正常性チェック用データ、ＤＢアクセス文変換ルール、ＯＵＴ電文生成ルールが含まれる。
正常性チェック用データは、ＩＮ電文の正常性をチェックするための条件を示す。正常性チェック用データは、例えば、ＸＭＬ（extensible markup language）スキーマにより記述され、ＩＮ項目のパラメータのデータ型や長さ、設定値などについての正常性をチェックするための条件を記述したＸＳＤファイルである。
ＤＢアクセス文変換ルールは、汎用インタフェースのＩＮ項目をパラメータとしたＤＢアクセス文を生成するための変換ルールを示す。ＤＢアクセス文変換ルールは、例えば、ＸＳＬＴ（XML Stylesheet Language Transformations）により記述され、ＩＮ項目を検索キーとしたＳＱＬ文を生成するための変換ルールを記述したＳＱＬ導出用ＸＳＬＴファイルである。
ＯＵＴ電文生成ルールは、参照データ管理部１１４から読み出されたデータをＯＵＴ項目として設定した汎用インタフェースのＯＵＴ電文を生成するための変換ルールを示す。ＯＵＴ電文生成ルールは、例えば、ＸＳＬＴにより記述され、読み出されたデータをＯＵＴ項目としてＸＭＬ形式に整形するための変換ルールを記述したＯＵＴ電文生成用ＸＳＬＴファイルである。
【０１２２】
情報参照処理部１１５は、読み出した変換ルールを用いて、データ参照要求に設定されているＩＮ項目の正常性をチェックした後、ＩＮ項目をキーとして原本データの検索を行うＤＢアクセス文を生成し、転送データ管理部１５４へ出力する（ステップＳ１７１０）。情報参照処理部１１５は、読み出した汎用ＩＦ定義を用いて、参照データ管理部１２３からＤＢアクセス文によって読み出された原本データをＯＵＴ項目に設定したＸＭＬのＯＵＴ電文を生成し、アプリケーション装置４へ返送する（ステップＳ１７１５）。
【０１２３】
上記によって、データアクセス要求及び応答の追加時には、変換ルールを追加するのみでよく、上位サービスアプリケーションに追加に伴うＩＦ開発が不要となる。
【０１２４】
図２４は、情報参照処理部１１５における汎用インタフェース処理フローを示す図である。同図において情報参照処理部１１５は、アプリケーション装置４から送信されたデータ参照要求であるＩＮ電文から識別子を抽出する。情報参照処理部１１５は、読み出した識別子によってルール記憶部１２４に記憶されている変換ルール、すなわち、適用すべき電文正常性確認用ＸＳＤファイル、ＳＱＬ導出用ＸＳＬＴファイル、ＯＵＴ電文生成用ＸＳＬＴファイルを特定する（ステップＳ１８０５）。情報参照処理部１１５は、ステップＳ１８０５において特定した電文正常性確認用ＸＳＤファイルを適用し、ＩＮ電文に設定されているパラメータであるＩＮ項目の正常性を確認する（ステップＳ１８１０）。情報参照処理部１１５は、ステップＳ１８０５において特定したＳＱＬ導出用ＸＳＬＴファイルを用いて、ＯＵＴ項目として必要な要素となる原本データを読み出すためのＳＱＬを生成する（ステップＳ１８１５）。
【０１２５】
情報参照処理部１１５は、参照データ管理部１１４へステップＳ１８１５において生成したＳＱＬ文を出力する。参照データ管理部１１４の参照データアクセス部１２２は、受信したＳＱＬ文に従って参照データ記憶部１２３から原本データを読み出し、情報参照処理部１１５へ出力する（ステップＳ１８２０）。情報参照処理部１１５は、ステップＳ１８２０において取得した原本データに対して、ステップＳ１８０５において特定したＯＵＴ電文生成用ＸＳＬＴファイルを適用し、ＯＵＴ電文を作成する（ステップＳ１８２５）。情報参照処理部１１５は、ステップＳ１８２５において生成したＯＵＴ電文をアプリケーション装置４へ返送する。
【０１２６】
［６． 効果］
上述した本実施形態のキャッシュシステムによれば、原本データ管理装置３が故障したり、計画停止等を行なったりする場合であっても、アプリケーション装置４に最新、かつ、一元性を確保した原本データを継続して提供することができる。
【０１２７】
本実施形態のキャッシュシステムでは、両系のキャッシュサーバ１は、自系が運用系か待機系かを意識することなく、独立に非同期で動作しており、外部のネットワーク装置であるロードバランサ２に系切り替えを委ねている。そのため、キャッシュサーバ１は、データアクセス要求を受信したときに、自系の備える参照データ記憶部１２３に記憶しているキャッシュデータへのアクセスを提供すればよい。従って、従来技術のように共有ディスクを使用した場合の単一障害点の問題を解決することができ、さらには、ロードバランサ２において系切り替えの必要性を判断した場合に、迅速に系切り替えを行なうことができる。
【０１２８】
また、キャッシュサーバ１は、ロードバランサ２が有する系切り替えの機能を利用して、自系が同期を行なう系か否かを問合せることができ、問合せの結果に応じて原本データ管理装置３とのデータ同期、及び、他系のキャッシュサーバ１との系間データ同期を起動する。よって、独立した系間でもデータの整合性を保った同期を実現することができる。
また、原本データ管理装置において付与された原本データの更新日時を利用することにより、系切り替えが行なわれた場合や、系間においてデータ転送中にエラーが発生した場合であっても、原本データ管理装置とのデータの同期もれや、系間の同期もれを防ぐことが可能になる。
【０１２９】
キャッシュシステムは、上位サービスアプリケーションを実行するアプリケーション装置４と、原本データを保持する原本データ管理装置３との中間層に位置するシステムである。そのため、参照部１１と転送部１５とでは、トラフィックの増加要因やタイミングが必ずしも一致しない。例えば、参照部１１のトラフィックは、上位サービスアプリケーションを使用するユーザの増加や、上位サービスアプリケーションの種類の増加に伴って増加する。一方、転送部１５のトラフィックは、上位サービスアプリケーションから参照されるデータ項目が追加されたときに増加する。本実施の形態では、１台の筐体（サーバ）において参照部１１と転送部１５が分離されているため、将来的に、参照部１１を実行するサーバと、転送部１５を実行するサーバとに分離し、それぞれをトラフィックに応じた台数とする構成に移行することが容易となる。一般的には、上位サービスアプリケーションからのトラフィックの増加の割合のほうが高いと考えられることから、例えば、参照部１１の性能拡張及びスケールアウトによる負荷分散を可能とするために、参照部１１を実行するサーバをｎ台構成の全運用方式に、転送部１５を実行するサーバを１＋１台構成の運用待機方式へと移行するようなことも容易である。
【０１３０】
［７． その他］
上記実施形態においては、キャッシュインタフェース装置を２台のキャッシュサーバ１により多重化しているが、３台以上により多重化してもよい。キャッシュインタフェース装置を３台以上のキャッシュサーバ１により多重化する場合、そのうち少なくとも２台以上がアクト系として動作しているものとし、ロードバランサ２は、アクト系のキャッシュサーバ１について上述した処理を行ない、アクト系のキャッシュサーバ１の中の１台を運用系として判断する。
また、キャッシュサーバ１として動作する１台の筐体（サーバ）に、複数の参照部１１を備える構成としてもよい。
【０１３１】
なお、上述のキャッシュサーバ１、ロードバランサ２、原本データ管理装置３、アプリケーション装置４は、内部にコンピュータシステムを有している。そして、キャッシュサーバ１の監視処理部１１２、監視結果通知処理部１１３、参照データ管理部１１４、情報参照処理部１１５、系内同期処理部１１６、監視処理部１５２、監視結果通知処理部１５３、転送データ管理部１５４、系状態識別部１５５、情報転送処理部１５７、系間転送処理部１５８及び系内同期処理部１５９、ロードバランサ２のサービスチェック部２２及び運用系判断処理部２３、原本データ管理装置３のデータ管理部３１、ならびに、アプリケーション装置４の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、ＣＰＵ及び各種メモリやＯＳ、周辺機器等のハードウェアを含むものである。
【０１３２】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【符号の説明】
【０１３３】
１、１−０、１−１…キャッシュサーバ
１１、１１−０、１１−１…参照部
１１１、１５１…タイマ
１１２、１５２…監視処理部
１１３、１５３…監視結果通知処理部
１１４…参照データ管理部
１１５…情報参照処理部
１１６、１５９…系内同期処理部
１２１、１６１…監視結果記憶部
１２２…参照データアクセス部
１２３…参照データ記憶部
１５、１５−０、１５−１…転送部
１５４…転送データ管理部
１５５…系状態識別部
１５６…同期情報記憶部
１５７…情報転送処理部
１５８…系間転送処理部
１６２…転送データアクセス部
１６３…転送データ記憶部
２、２ａ、２ｂ…ロードバランサ
２１…タイマ
２２…サービスチェック部
２２１…記憶部
２３…運用系判断処理部
３…原本データ管理装置
３１…データ管理部
３２…更新履歴記憶部
３３…原本データ記憶部
４…アプリケーション装置
【技術分野】
【０００１】
本発明は、キャッシュシステム及びキャッシュアクセス方法に関する。
【背景技術】
【０００２】
従来、ユーザの端末から、ネットワークを介して接続されるサーバにアクセスし、このサーバから提供されるウェブ画面を用いて、ネットワーク上のデータベース（以下、「データベース」を「ＤＢ」と記載）に対して、データ参照等のデータアクセスを行なうシステムが実現されている。
【０００３】
図２５（ａ）は、このような既存システムの一例であるサービスオーダシステムの構成を示す図である。同図に示すサービスオーダシステムにおいて、ウェブサービスオーダ装置は、ネットワークを介して接続される端末へ、サービスオーダ管理装置が管理対象としている顧客ＤＢ内のデータへのアクセスを行なうためのウェブ画面を提供する。ユーザが、このウェブ画面を利用してデータ参照要求を端末に入力すると、ウェブサービスオーダ装置は、端末に入力されたデータ参照要求を受信し、受信したデータ参照要求をコマンド等に形式変換してサービスオーダ管理装置に送信する。受信したコマンドに従ってサービスオーダ管理装置が顧客ＤＢから読み出したデータは、ウェブサービスオーダシステムを介して端末へ通知される。
【０００４】
図２５（ａ）に示すようなサービスオーダシステムでは、サービスオーダ管理装置がメンテナンス等により停止している間、ユーザの端末は、顧客ＤＢ内のデータを取得することはできない。そこで、図２５（ｂ）に示すように、ウェブサービスオーダ装置と、サービスオーダ管理装置の間に、顧客ＤＢと同期してデータを記憶するキャッシュシステムを設けることが考えられる。これにより、サービスオーダ管理装置が停止している間も、ウェブサービスオーダ装置は参照が要求されたデータをキャッシュシステムから読み出して端末に提供することができる。
【０００５】
しかし、上記のように、キャッシュシステムを設けた場合であっても、キャッシュシステム自体が停止してしまった場合には、端末へデータを提供できなくなってしまう。そのため、キャッシュシステムのリダンダンシを確保することが必要である。
【０００６】
リダンダンシを確保する場合、装置を多重化することが一般的である。図２６に、キャッシュサーバを多重化してリダンダンシを確保した従来のシステム構成を示す。
図２６（ａ）は、クラスタを利用し、待機系のキャッシュサーバをコールドスタンバイ（Cold.SBY）とした構成を示す。同図に示す構成のシステムでは、アクト（ACT）系とスタンバイ系のキャッシュサーバにおいてＤＢをＳＡＮ（Storage Area Network）により共有し、クラスタリングソフトウェアを利用して系切り替えを行なう。
図２６（ｂ）は、クラスタを利用し、待機系のキャッシュサーバをホットスタンバイ（Hot.SBY）とした構成を示す。同図に示す構成のシステムも同様に、アクト系とスタンバイ系のキャッシュサーバにおいてＤＢをＳＡＮにより共有し、クラスタリングソフトウェアを利用して系切り替えを行なう。
図２６（ｃ）は、各系のキャッシュサーバにＤＡＳ（Direct Attached Storage）のＤＢを配備し、待機系のキャッシュサーバをコールドスタンバイとした構成を示す。図２６（ｃ）においては、クォーラムサーバが各系の状態を保持し、系切り替えを行なう。
【０００７】
また、データアクセスを無停止で提供することを目的とする技術が特許文献１、２に開示されている。特許文献１には、同じデータが割り当てられている複数のノードがロードバランサを介して外部と接続されており、ロードバランサは、ノードの状態を監視して最適なノードを選ぶことが記載されている。また、特許文献２には、主系、従系として動作する冗長構成のコンピュータそれぞれが、自身の状態をチェックした結果であるヘルシーチェック情報を相互に交換し、主系、従系の切り替えを行なうことが記載されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−３０２０４号公報
【特許文献２】特開２００８−２２６１５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上述したリダンダンシを確保するための既存の技術には、以下のような問題がある。
すなわち、図２６（ａ）の構成において系切り替えを行なう場合、待機系はコールドスタンバイ起動となるため、系切り替えに数十分を要する場合があり、この間はデータを提供できない。また、ＳＡＮのファームアップ中は、ＳＡＮにアクセスするＤＢＭＳ（DataBase Management System）を数十分間停止させる必要があり、やはり、この間は、データの提供できない。加えて、ＤＢの共有ディスクがＳＰＯＦ（Single Point of Failure）となってしまい、共有ディスク故障時には、全体が障害に陥ってしまう。
【００１０】
また、図２６（ｂ）の構成において系切り替えを行なう場合、図２６（ａ）と同様に、ＳＡＮのファームアップ中は、ＳＡＮにアクセスするＤＢＭＳを数十分間停止する必要があるとともに、共有ディスクがＳＰＯＦとなる。また、冗長構成を拡張する場合は各系の関係を解除する必要がある。つまり、両系のＤＢＭＳや、クラスタリングソフトウェアを停止し、設定変更の作業を行うため、その間はデータアクセスサービスが提供できない。
このように、上記の図２６（ａ）、（ｂ）のように、系間でＤＢを共有する形態では、恒常的に継続してデータを提供することは困難である。
【００１１】
また、図２６（ｃ）の構成においては系切り替えを行なう場合、待機系はコールドスタンバイ起動となるため、系切り替えに数十分を要する場合があり、この間はデータアクセスサービスが提供できないことに加え、各系の状態を保持し、系切り替えを行なうクォーラムサーバがＳＰＯＦとなってしまう。
【００１２】
特許文献１の技術は、ロードバランサが、外部から受信したリクエストを二重化されたノードコンピュータの両方に送信し、リクエストに対する仮実行結果を早く返送したノードコンピュータに対して本実行を行なうよう指示し、他方のノードコンピュータには無効を指示するものであり、ノードコンピュータにリクエストを受信する都度、仮実行を行わせその結果を破棄するという処理を実装しなければならない。また、特許文献２の技術は、冗長構成のコンピュータにおいて主系、従系の切り替えを行なうものであり、冗長構成のコンピュータが常に他方のコンピュータの状態を意識しなければならない。
【００１３】
本発明は、このような事情を考慮してなされたもので、その目的は、多重化されたキャッシュ装置を用い、キャッシュ装置に系切り替えのための負荷をかけることなく、恒常的に継続してデータ提供を可能とするキャッシュシステム及びキャッシュアクセス方法を提供することにある。
【課題を解決するための手段】
【００１４】
本発明は、上記の課題を解決すべくなされたもので、原本データをキャッシュする複数のキャッシュ装置と、受信信号を複数の前記キャッシュ装置のいずれに振り分けるかを管理するアクセス振分装置とを備えるキャッシュシステムであって、複数の前記キャッシュ装置それぞれは、前記アクセス振分装置から振り分けられたデータアクセス要求を受信し、受信したデータアクセス要求に応じて自キャッシュ装置がキャッシュしている原本データへのアクセス処理を行う参照部と、原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する転送部とを備え、前記アクセス振分装置は、アクト状態の複数の前記キャッシュ装置の前記参照部及び前記転送部それぞれの運用状態を取得するサービスチェック部と、前記サービスチェック部が取得した複数の前記キャッシュ装置の前記参照部及び前記転送部の運用状態に基づいて、複数の前記キャッシュ装置の中から受信信号の振分先となる前記キャッシュ装置を判定する運用系判断処理部とを備える、ことを特徴とするキャッシュシステムである。
上記発明によれば、それぞれが１台のサーバ（筐体）によって実現される複数のキャッシュ装置を、上位アプリケーションからのデータアクセス要求に応じて自身がキャッシュしている原本データへのアクセス処理を行う参照部と、原本データ管理装置が保持している原本データにより自身がキャッシュしている原本データを更新する転送部とに分離した構成とし、振分装置は、各キャッシュ装置内の参照部及び転送部が両方とも正常であるか、いずれかあるいは両方に障害が発生しているかなどの状況に従って信号の振分先、すなわち、運用系のキャッシュ装置を判断する。
これによって、振分装置は、上位アプリケーションからのデータアクセス要求を受信した場合、まずは参照部が正常に動作しているキャッシュ装置を選択し、選択したキャッシュ装置が１台であればその選択したキャッシュ装置を振り分け先とし、選択したキャッシュ装置が複数であれば、選択した中でも同一筐体内の転送部が正常であるキャッシュ装置の中から振り分け先を選択したり、選択したキャッシュ装置の転送部がいずれも障害である場合には、選択した中から任意に振り分け先を選択したりすることができる。従って、複数のキャッシュシステム装置の中から、恒常的に継続して原本データへのアクセスを提供すること可能となるとともに、できるだけ最新の原本データを提供することが可能となる。
また、参照部と転送部を分離しているため、将来的に参照部と転送部をそれぞれ別の筐体に実装した構成に移行することが容易となる。参照部のトラフィックは、上位サービスアプリケーションを使用するユーザの増加や、上位サービスアプリケーションの種類の増加に伴って増加する一方、転送部のトラフィックは、上位サービスアプリケーションから参照されるデータ項目が追加されたときに増加することを勘案すると、将来的には、参照部を実行するサーバをｎ台構成の全運用方式へ、転送部を実行するサーバを１＋１台構成の運用待機方式へと移行することが望ましく、その縮退した構成として本発明のキャッシュシステムを用いることが可能となる。
なお、ｎ台構成とは、同一のシステム、機能部を複数台用意し、全て運用系とする冗長化構成であり、１＋１台構成とは、同一のシステム、機能部を２台用意し、一方は運用系、もう一方は待機系とする冗長化構成であり、運用待機方式とは、ある機能部を複数台のサーバに分散配置した際、機能部を運用系と待機系に分けて稼動する方式である。
【００１５】
また本発明は、上述するキャッシュシステムであって、前記運用系判断処理部は、前記参照部の運用状態に基づいて複数の前記参照部が正常であると判断した場合、正常な前記参照部を備える複数の前記キャッシュ装置の中から、前記転送部の運用状態に基づいて正常であると判断される前記転送部を備える前記キャッシュ装置を振分先と判定する、ことを特徴とする。
上記発明によれば、振分装置は、参照部が正常に動作しているということだけではなく、原本データの同期を行なう転送部が正常に動作しているかも判断して運用系のキャッシュ装置を選択する。
転送部が正常に動作していれば、そのキャッシュ装置にキャッシュされている原本データは正しく同期されているため、参照部が正常に動作しているキャッシュ装置の中から、転送部も正常に動作しているキャッシュ装置を振り分け先として選択することにより、データアクセスが可能な原本データの中から常に最新の原本データを上位アプリケーションに提供することができる。
【００１６】
また本発明は、上述するキャッシュシステムであって、複数の前記キャッシュ装置それぞれの転送部は、前記振分装置に系状態識別信号を送信する系状態識別部と、前記振分装置から自身が送信した前記系状態識別信号を受信した場合に、原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する情報転送処理部と、他のキャッシュ装置がキャッシュしている原本データを前記情報転送処理部が読み出した前記原本データにより更新する系間転送処理部とをさらに備え、前記アクセス振分装置の前記運用系判断処理部は、振分先として判定した前記キャッシュ装置へ受信した前記系状態識別信号を送信する、ことを特徴とする。
上記発明によれば、各キャッシュ装置の転送部は系状態識別信号を送信し、送信された系状態識別信号は、振分装置が運用系と判断したキャッシュ装置へ振り分けられる。自身が送信した系状態識別信号を受信した転送部は自系が運用系であると判断し、原本データ管理装置が保持している原本データによって自系がキャッシュしている原本データを更新し、さらに他のキャッシュ装置がキャッシュしている原本データも更新する。
振分装置は、信号の種類や宛先ではなく、各キャッシュ装置内の参照部及び転送部の運用状態によって信号の振分先を判断するため、上位アプリケーションからのデータアクセス要求と同じ振分先に系状態識別信号も振り分けられる。そこで、自身の送信した系状態識別信号を受信した、すなわち、データアクセス要求を処理するキャッシュ装置の転送部がまず、原本データ管理装置が保持している原本データとの同期を行なうことで、常に最新の原本データを上位アプリケーションに提供することが可能となる。例えば、待機系のキャッシュ装置の転送部が原本データ管理装置と同期を行い、続いて、運用系のキャッシュ装置との系間同期を行なうような同期手順と比較すると、運用系のキャッシュ装置がキャッシュしている原本データが更新されるタイミングが早く、また、系間同期中の障害等によって、運用系のキャッシュ装置がキャッシュしている原本データの更新が行なえずに、古い原本データへのアクセスを提供してしまうようなこともない。また、原本データ管理装置との同期の後、他系のキャッシュ装置とも系間同期を行なうため、キャッシュ装置間での原本データの不整合も発生しない。
【００１７】
また本発明は、上述するキャッシュシステムであって、前記情報転送処理部は、自身が送信した前記系状態識別信号を受信した場合に、前記原本データ管理装置から、自キャッシュ装置がキャッシュしている前記原本データよりも、前記原本データ管理装置における更新日時が新しい原本データを読み出し、自キャッシュ装置がキャッシュしている前記原本データを更新し、前記系間転送処理部は、自キャッシュ装置がキャッシュしている前記原本データのうち、前記他のキャッシュ装置がキャッシュしている前記原本データよりも前記原本データ管理装置における更新日時が新しい原本データにより、前記他のキャッシュ装置がキャッシュしている原本データを更新する、ことを特徴とする。
上記発明によれば、運用系のキャッシュ装置の転送部は、原本データ管理装置における更新日時に基づいて、自身がキャッシュしている原本データの更新と、他のキャッシュ装置がキャッシュしている原本データの更新を行なう。
これにより、運用系のキャッシュ装置が切り替わり、新たにデータアクセス要求の振分先となったキッシュ装置において原本データ管理装置と同期を行なう際や、他系の原本データとの同期を行なう際にも更新もれが発生することがない。よって、一元性を確保しながら、最新の原本データを提供することが可能となる。
【００１８】
また本発明は、上述するキャッシュシステムであって、前記転送部は、自キャッシュ装置がキャッシュしている前記原本データを記憶する転送データ記憶部をさらに備え、前記情報転送処理部は、前記原本データ管理装置から読み出した前記原本データを前記転送データ記憶部に書き込み、前記参照部は、自キャッシュ装置がキャッシュしている前記原本データを記憶する参照データ記憶部と、前記転送データ記憶部から読み出した前記原本データを前記参照データ記憶部に書き込む系内同期処理部と、受信した前記データアクセス要求に応じて前記参照データ記憶部に記憶している前記原本データへのアクセス処理を行う参照データアクセス部とを備える、ことを特徴とする。
上記発明によれば、参照部及び転送部それぞれにキャッシュした原本データを記憶する記憶部を備えておき、転送部は、自身の備える記憶部に原本データ管理装置から読み出した原本データを書き込んでキャッシュし、参照部は自身の備える記憶部にキャッシュしている原本データを、転送部の記憶部にキャッシュしている原本データによって更新する。
上記構成により、参照部と転送部を完全に分離することが可能となるため、将来的に、参照部を実行するサーバをｎ台構成の全運用方式へ、転送部を実行するサーバを１＋１台構成の運用待機方式へと移行することが容易になる。
【００１９】
また本発明は、原本データをキャッシュする複数のキャッシュ装置と、受信信号を複数の前記キャッシュ装置のいずれに振り分けるかを管理するアクセス振分装置とを備えるキャッシュシステムに用いられるキャッシュアクセス方法であって、複数の前記キャッシュ装置それぞれは、前記アクセス振分装置から振り分けられたデータアクセス要求を受信し、受信したデータアクセス要求に応じて自キャッシュ装置がキャッシュしている原本データへのアクセス処理を行う参照部と、原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する転送部とを備えており、前記アクセス振分装置において、サービスチェック部が、アクト状態の複数の前記キャッシュ装置の前記参照部及び前記転送部それぞれの運用状態を取得する状態取得過程と、運用系判断処理部が、前記状態取得過程において取得した複数の前記キャッシュ装置の前記参照部及び前記転送部の運用状態に基づいて、複数の前記キャッシュ装置の中から受信信号の振分先となる前記キャッシュ装置を判定する運用系判断処理過程と、を有することを特徴とするキャッシュアクセス方法である。
【発明の効果】
【００２０】
本発明によれば、振分装置は、各キャッシュ装置内の参照部及び転送部が両方とも正常であるか、いずれかあるいは両方に障害が発生しているかなどの状況に従って信号の振分先、すなわち、運用系のキャッシュ装置を判断するため、恒常的に継続して原本データへのアクセスを提供することが可能となるとともに、できるだけ最新の原本データを提供することが可能となる。
また、本発明によれば、参照部が正常に動作しているキャッシュ装置の中から、転送部も正常に動作しているキャッシュ装置を振り分け先として選択するため、アクセス可能な原本データの中から常に最新の原本データを上位アプリケーションに提供することが可能となる。
また、本発明によれば、データアクセス要求を処理する参照系と同じキャッシュ装置の転送部がまず、原本データ管理装置が保持している原本データとの同期を行なうため、常に最新の原本データを上位アプリケーションに提供することが可能となり、原本データ管理装置との同期後、他系との同期を行なうため、キャッシュ装置間での原本データの不整合も発生しない。
また、本発明によれば、データアクセス要求の振分先となるキャッシュ装置は、原本データ管理装置における更新日時に基づいて、自身がキャッシュしている原本データの更新と、他のキャッシュ装置がキャッシュしている原本データとの同期を行なうため、一元性を確保した、最新の原本データを提供することが可能となる。
また、本発明によれば、参照部と転送部を分離しているため、将来的に参照部と転送部をそれぞれ別の筐体に実装した構成に移行することが容易となり、参照部及び転送部にそれぞれ記憶部を有することによって、さらに、この分離が容易となる。従って、参照部を実行するサーバをｎ台構成の全運用方式に、転送部を実行するサーバを１＋１台構成の運用待機方式へと移行する場合の縮退構成として本発明のキャッシュシステムを用いることが可能となる。
【図面の簡単な説明】
【００２１】
【図１】本発明の一実施形態によるキャッシュシステムの接続構成を示す図である。
【図２】同実施形態によるキャッシュシステムの動作概要を示す図である。
【図３】同実施形態による各装置の内部構成を示すブロック図である。
【図４】同実施形態によるキャッシュシステムの系状態確認シーケンスを示す図である。
【図５】同実施形態による系状態確認における各装置の機能部間の処理の流れを示す図である。
【図６】同実施形態による両系のキャッシュサーバ１の参照部１１及び転送部１５における自系内状態監視処理フローを示す図である。
【図７】同実施形態による両系のキャッシュサーバ１の参照部１１及び転送部１５における自系内状態監視結果返却処理フローを示す図である。
【図８】同実施形態によるロードバランサ２のヘルスチェック処理フローを示す図である。
【図９】同実施形態によるデータ参照要求受信時の振分処理シーケンスを示す図である。
【図１０】同実施形態による系状態識別信号受信時の振分処理シーケンスを示す図である。
【図１１】同実施形態によるロードバランサ２ａにおける振分処理フローを示す図である。
【図１２】同実施形態による振分け状態表を示す図である。
【図１３】同実施形態によるロードバランサ２ｂにおける振分処理の処理フローを示す図である。
【図１４】同実施形態への適用を検討した原本データ同期方法を示す図である。
【図１５】同実施形態への適用を検討した系間同期方法を示す図である。
【図１６】同実施形態によるキャッシュシステムのデータ同期シーケンスを示す図である。
【図１７】同実施形態によるデータ同期処理に用いられる各装置のデータ例を示す図である。
【図１８】同実施形態による原本データ同期処理におけるデータ更新の流れを示す図である。
【図１９】同実施形態による系間データ同期処理におけるデータ更新の流れを示す図である。
【図２０】同実施形態による両系のキャッシュサーバ１の転送部１５における系状態識別処理フローを示す図である。
【図２１】同実施形態による両系のキャッシュサーバ１の転送部１５における原本データとの同期処理フローを示す図である。
【図２２】同実施形態による運用系のキャッシュサーバ１の転送部１５における系間データ同期処理フローを示す図である。
【図２３】同実施形態による汎用インタフェースを用いた動作概要を示す図である。
【図２４】同実施形態によるキャッシュサーバ１の汎用インタフェース処理フローを示す図である。
【図２５】従来のデータアクセスシステムを示す図である。
【図２６】二重化によりリダンダンシを確保した従来のシステム構成を示す図である。
【発明を実施するための形態】
【００２２】
以下、図面を参照しながら本発明の実施形態を詳細に説明する。
【００２３】
［１． 構成］
図１は、本発明の一実施形態によるキャッシュシステムの接続構成を示す図である。同図において、キャッシュシステムは、キャッシュサーバ１により多重化されたキャッシュインタフェース装置と、キャッシュサーバ１それぞれに接続されるロードバランサ２ａ、２ｂとからなる。ロードバランサ２ａはさらに、原本データを使用して上位サービスアプリケーションを実行するアプリケーション装置４と接続され、ロードバランサ２ｂはさらに、上位サービスアプリケーションが参照する原本データを記憶する原本データ管理装置３と接続される。同図においては、アプリケーション装置４を１台のみ示しているが、複数台が接続されうる。
【００２４】
キャッシュサーバ１は、原本データ管理装置３が記憶する原本データのうち、上位サービスアプリケーションに必要な情報を内部にキャッシュする。キャッシュサーバ１は、上位サービスアプリケーションの実行に伴ってアプリケーション装置４から送信されたデータ参照要求に対して、原本データ管理装置３から読み出してキャッシュした原本データを検索し、その結果を返却する。キャッシュサーバ１は多重化構成の形態をとっているため、上位サービスアプリケーションに対して、サービスの恒常的継続が可能である。
【００２５】
以下、キャッシュサーバ１のうち一方を０系、他方を１系とし、０系のキャッシュサーバ１をキャッシュサーバ１−０、１系のキャッシュサーバ１をキャッシュサーバ１−１と記載し、０系と１系をあわせて「両系」と記載する。また、ロードバランサ２ａ、２ｂを総称してロードバランサ２と記載する。なお、ロードバランサ２は二重化されており、障害等が発生した場合でも短い時間での系切り替えが可能である。
【００２６】
図２は、図１に示すキャッシュシステムの動作概要を示す図である。
本実施形態において、両系のキャッシュサーバ１は、アクト系、スタンバイ系という系状態を持たず、キャッシュサーバ１−０、１−１ともアクト系として動作しており、ネットワーク装置としてのロードバランサ２が、受信した信号をキャッシュサーバ１−０、１−１のいずれに振り分けるかを判断する。ここでは、ロードバランサ２が信号を振り分ける側のキャッシュサーバ１を運用系、運用系ではない側のキャッシュサーバ１を待機系と記載する。
【００２７】
各キャッシュサーバ１は、参照部１１及び転送部１５を備えた１台のサーバである。すなわち、同じ筐体において参照部１１及び転送部１５が動作する。参照部１１は、該参照部１１が備えるデータベース（以下、「ＤＢ」と記載）にキャッシュされている原本データを用い、上位サービスアプリケーションの実行によりアプリケーション装置４から送信されたデータ参照要求に対応して応答する。転送部１５は、ロードバランサ２から自系が運用系と判断されているかを識別し、運用系であると判断されている場合は、該転送部１５が備えるＤＢにキャッシュされている原本データと、原本データ管理装置３に記憶されている原本データとのデータ同期を行い、さらに、他系の転送部１５のＤＢにキャッシュされている原本データとの同期を行なう。参照部１１は、定期的に転送部１５のＤＢから同期が行われた原本データを読み出し、該参照部１１が備えるＤＢを更新することにより、転送部１５のＤＢとデータ同期を行なっている。
【００２８】
ロードバランサ２は、定期的にキャッシュサーバ１にヘルスチェック信号を送信して各系の参照部１１及び転送部１５の状態を監視するヘルスチェックを行っており、その監視結果に基づいて運用系と待機系を決定する。
ロードバランサ２ａは、アプリケーション装置４側の仮想ＩＰアドレスＡを持つとともに、キャッシュサーバ１−０の物理ＩＰアドレスＣ０、キャッシュサーバ１−１の物理ＩＰアドレスＣ１を記憶しており、仮想ＩＰアドレスＡを宛先とした信号を受信すると、運用側のキャッシュサーバ１の物理ＩＰアドレスＣ０またはＣ１を宛先として受信した信号を送出する。このとき、物理ＩＰアドレスには、参照部１１に対応したポート番号が付加される。キャッシュサーバ１−０、１−１の参照部１１それぞれのポート番号をＰＳ０、ＰＳ１とする。
同様に、ロードバランサ２ｂは、原本データ管理装置３側の仮想ＩＰアドレスＢを持つとともに、キャッシュサーバ１−０の物理ＩＰアドレスＣ０、キャッシュサーバ１−１の物理ＩＰアドレスＣ１を記憶しており、仮想ＩＰアドレスＢを宛先とした信号を受信すると、運用側のキャッシュサーバ１の物理ＩＰアドレスＣ０またはＣ１を宛先として受信した信号を送出する。このとき、物理ＩＰアドレスには、転送部１５に対応したポート番号が付加される。キャッシュサーバ１−０、１−１の転送部１５それぞれのポート番号をＰＴ０、ＰＴ１とする。
【００２９】
なお、同じキャッシュサーバ１内において参照部１１、転送部１５が異なる物理ＩＰアドレスを用いるようにすることもできる。この場合、ロードバランサ２ａは、仮想ＩＰアドレスＡを宛先とした信号を受信すると、運用側のキャッシュサーバ１の参照部１１に対応した物理ＩＰアドレスを宛先として受信した信号を送出する。同様に、ロードバランサ２ｂは、仮想ＩＰアドレスＢを宛先とした信号を受信すると、運用側のキャッシュサーバ１の転送部１５に対応した物理ＩＰアドレスを宛先として受信した信号を送出する。
【００３０】
上記により、ロードバランサ２ａは、運用系と判断しているキャッシュサーバ１の参照部１１にアプリケーション装置４から受信したデータ参照要求を送信する。そのため、キャッシュサーバ１は、系を意識せずとも、データ参照要求を受信したときに、自身の参照部１１が備えるＤＡＳ（Direct Attached Storage）のＤＢに記憶されているデータを読み出して応答すればよい。ロードバランサ２ａに待機系と判断されているキャッシュサーバ１も、運用系と判断されているキャッシュサーバ１と同じ状態で動作しているため、ロードバランサ２ａによって運用系の切り替え判断がなされた場合にもそれを意識する必要はなく、受信したデータ参照要求に応答すればよい。このように、独立した２つのキャッシュサーバ１が外部からはあたかも１つの装置のように見え、サービスルートの決定はロードバランサ２に制御をゆだねている。
【００３１】
ただし、本実施の形態のキャッシュシステムにおいて、原本データ管理装置３が記憶する原本データとの同期や、待機系のキャッシュサーバ１とのデータ同期は、運用系のキャッシュサーバ１の転送部１５から起動する。そのため、キャッシュサーバ１の転送部１５は、ロードバランサ２ｂに自系の系状態を問い合わせる系状態識別処理を行なう。系状態識別処理では、ロードバランサ２が仮想ＩＰアドレスを宛先とした信号を、運用系のキャッシュサーバ１に振り分けることを利用する。つまり、キャッシュサーバ１の転送部１５は、仮想ＩＰアドレスＢ宛に系状態識別信号を送信し、ロードバランサ２ｂからその信号を受信した場合には運用系であると判断する。
【００３２】
ロードバランサ２は、ヘルスチェックによる各系の参照部１１及び転送部１５の状態の監視結果に基づいて運用系と待機系を決定しているが、両系のキャッシュサーバ１の参照部１１とも運用可能（障害が発生していない）である場合、同じ筐体に備えられている転送部１５が運用可能であるキャッシュサーバ１を運用系と判断する。
【００３３】
例えば、ある機能部を複数台のサーバに分散配置した際に、ロードバランスにより全サーバ上の該当機能部を全て運用系として稼動する全運用方式のように、転送部１５の運用状態に関わらず、参照部１１が運用可能であれば、上位サービスアプリケーションからキャッシュサーバ１にアクセス可能としたとする。この場合、転送部１５の運用状態が待機系のキャッシュサーバ１では、原本データ管理装置３から取得される原本データとの同期が遅れてしまったり（系間同期の遅れ）、キャッシュされている原本データが更新されなかったりする（系間同期故障）可能性がある。このときに、転送部１５が待機系であるキャッシュサーバ１に、データ参照要求が振り分けられてしまうと、古いデータを返却するという不具合が生じてしまう。
そこで、ロードバランサ２aは、両系のキャッシュサーバ１の参照部１１が運用可能かどうかを確認し、同時に、両系のキャッシュサーバ１の転送部１５が運用可能かどうかを確認する。そして、両系のキャッシュサーバ１の参照部１１とも運用可能である場合、同じ筐体に備えられている転送部１５が正常に動作している参照部１１にアプリケーション装置４から受信したデータ参照要求を振り分ける。
【００３４】
ロードバランサ２ａが上記のように振り分け先を決定することにより、例えば、キャッシュサーバ１−０の参照部１１及び転送部１５が運用状態であり、キャッシュサーバ１−１の参照部１１が運用状態、転送部１５が待機状態である場合、アプリケーション装置４からのデータ参照要求はキャッシュサーバ１−０の参照部１１に振り分けられる。このとき、キャッシュサーバ１−０の参照部１１においてアプリケーション障害、ＤＢ障害、ロードバランサとの間のネットワーク障害等の障害が発生した場合、系切替が行なわれる。従来方式を適用した場合、キャッシュサーバ１は、参照部１１の運用状態に関わらず、転送部１５が運用状態であればデータの同期を行なうことが考えられる。しかし、データ参照要求の振分先がキャッシュサーバ１−１の参照部１１となっても、キャッシュサーバ１−０の転送部１５については運用状態のまま系切替が行なわれないと、正常時と比較して、原本ＤＢから取得された原本データとの同期が遅れてしまったり（系間同期の遅れ）、キャッシュされている原本データが更新されなかったりする（系間同期故障）可能性があり、サービス提供レベルが下がってしまう。
【００３５】
そこで、本実施の形態では、キャッシュサーバ１の転送部１５は、原本データ管理装置３との間の原本データ同期処理の開始時に、データ参照要求の振分先が同一筐体内の参照部１１であるかを確認する。そのため、キャッシュサーバ１の転送部１５は、系状態識別信号を送信し、ロードバランサ２ｂは、ロードバランサ２ａと同様に振り分け先を決定する。自身が送信した系状態識別信号をロードバランサ２ｂから受信した、すなわち、データ参照要求の振分先のキャッシュサーバ１と同一の筐体内の転送部１５は、原本データ管理装置３から原本データを取得し、同期を行う。このようにして、運用状態の転送部１５は、同一筐体内の参照部１１が振り分け先の場合は原本データ同期処理を実施し、別筐体内の参照部１１が振り分け先の場合は、転送部１５の系切替を実施する。
【００３６】
図３は、キャッシュサーバ１、ロードバランサ２及び原本データ管理装置３の内部構成を示すブロック図である。
参照部１１は、ロードバランサ２との間でヘルスチェックを実行するとともに、上位サービスアプリケーションからのデータ参照要求に応答し、同一系内、つまり、同一のキャッシュサーバ１が備える転送部１５との間でデータ同期を行なう。参照部１１は、タイマ１１１、監視処理部１１２、監視結果通知処理部１１３、参照データ管理部１１４、情報参照処理部１１５、及び、系内同期処理部１１６を備える。
【００３７】
監視処理部１１２は、タイマ１１１により定期的に起動され、自系の参照部１１内の各プロセスの生起確認、参照データ管理部１１４が備えるＤＢの死活確認など、自系の参照部１１についての系内状態監視を実施し、その結果を内部に備える監視結果記憶部１２１に保持する。監視結果通知処理部１１３は、ロードバランサ２から定期的にヘルスチェック信号を受信し、監視結果記憶部１２１に保持されている自参照部１１の系内状態監視結果に応じて応答を送信する。
【００３８】
参照データ管理部１１４は、参照データアクセス部１２２と、参照データ記憶部１２３を備える。参照データアクセス部１２２は、既存のＤＢＭＳ（DataBase Management System）ソフトウェアにより実現することができ、ＤＢとしての参照データ記憶部１２３に記憶されているキャッシュデータの読み出しや書き込みを行なう。
系内同期処理部１１６は、参照データ記憶部１２３に記憶されている原本データと、転送部１５のＤＢに記憶されている原本データとのデータ同期を行なう。
【００３９】
情報参照処理部１１５は、アプリケーション装置４が送信したデータ参照要求を受信して参照データ管理部１１４に出力し、参照データ管理部１１４がデータ参照要求に基づいて読み出したデータを返送する。
【００４０】
転送部１５は、ロードバランサ２との間でヘルスチェックを実行するとともに、自系が運用系かどうかを確認し、運用系であれば原本データ管理装置３との間でデータ同期を実施する。さらに、転送部１５は、同一系内、つまり、同一のキャッシュサーバ１内の転送部１５との間でデータ同期を行なう。転送部１５は、タイマ１５１、監視処理部１５２、監視結果通知処理部１５３、転送データ管理部１５４、系状態識別部１５５、同期情報記憶部１５６、情報転送処理部１５７、系間転送処理部１５８、及び、系内同期処理部１５９を備える。
【００４１】
監視処理部１５２は、タイマ１５１により定期的に起動され、自系の転送部１５内の各プロセスの生起確認、転送データ管理部１５４が備えるＤＢの死活確認など、自系の転送部１５についての系内状態監視を実施し、その結果を内部に備える監視結果記憶部１６１に保持する。監視結果通知処理部１５３は、ロードバランサ２から定期的にヘルスチェック信号を受信し、監視結果記憶部１６１に保持されている自転送部１５内の系内状態監視結果に応じて応答を送信する。
【００４２】
転送データ管理部１５４は、転送データアクセス部１６２と、転送データ記憶部１６３を備える。転送データアクセス部１６２は、既存のＤＢＭＳソフトウェアにより実現することができ、ＤＢとしての転送データ記憶部１６３に記憶されているキャッシュデータの読み出しや書き込みを行なう。
系内同期処理部１５９は、転送データ記憶部１６３に記憶されているデータと、参照部１１が保持するデータとの原本データ同期を行なう。
【００４３】
同期情報記憶部１５６は、原本データ管理装置３から読み出した原本のデータのうち、転送データ記憶部１６３には書き込んだが、まだ他のキャッシュサーバ１との同期更新を行なっていないデータと、そのデータが原本データ管理装置３において更新された日時の情報とを対応づけた更新情報テーブル（以下、テーブルを「ＴＢＬ」と記載）を記憶する。さらに、同期情報記憶部１５６は、転送データ記憶部１６３への書き込みが終了した原本データの原本データ管理装置３における更新日時のうち、最新の更新日時であるラストルックを示す最終更新情報ＴＢＬを記憶する。
【００４４】
系状態識別部１５５は、ロードバランサ２が自系を運用系として認識しているか、待機系と判断しているかを問い合わせる。情報転送処理部１５７は、自系が運用系と認識されている場合、同期情報記憶部１５６内の最終更新情報ＴＢＬに設定されているラストルック以降が更新日時である原本データを原本データ管理装置３から読み出し、読み出した原本データを同期情報記憶部１５６内の更新情報ＴＢＬに書き込むとともに、読み出した原本データを書き込んで転送データ記憶部１６３を更新するよう転送データ管理部１５４に指示する。系間転送処理部１５８は、同期情報記憶部１５６内の更新情報ＴＢＬに記憶されている原本データのうち、他系のキャッシュサーバ１の最終更新情報ＴＢＬに設定されているラストルック以降が更新日時である原本のデータを他系のキャッシュサーバ１の転送データ記憶部１６３に書き込むとともに、書き込みが成功した場合、書き込みが成功した原本データの原本データ管理装置３における更新日時のうち最新の更新日時をラストルックとして他系のキャッシュサーバ１の最終更新情報ＴＢＬに書き込む。
【００４５】
以下、キャッシュサーバ１−０が備えるキャッシュサーバ１の各部には符号に「−０」を付加して記載し、キャッシュサーバ１−１が備えるキャッシュサーバ１の各部には符号に「−１」を付加して記載する。また、各部が０系のキャッシュサーバ１−０に備えられている旨を単に「０系の」、１系のキャッシュサーバ１−１に備えられている旨を単に「１系の」とも記載する。例えば、キャッシュサーバ１−０の備える監視処理部１１２は、「監視処理部１１２−０」、または、「０系の監視処理部１１２−０」と記載し、キャッシュサーバ１−１の備える監視処理部１１２は、「監視処理部１１２−１」、または、「１系の監視処理部１１２−１」と記載する。
【００４６】
同図において、ロードバランサ２は、タイマ２１、サービスチェック部２２、及び、運用系判断処理部２３を含んで構成される。
サービスチェック部２２は、タイマ２１により定期的に起動され、両系のキャッシュサーバ１の物理ＩＰアドレス及び参照部１１のポート番号、両系のキャッシュサーバ１の物理ＩＰアドレス及び転送部１５のポート番号を宛先に用いてヘルスチェック信号を送信し、両系のキャッシュサーバ１の参照部１１及び転送部１５から応答が返送されたか否かの結果を内部に備える記憶部２２１に書き込む。応答が返送されたか否かによって、正常か異常かの状態が識別できる。
【００４７】
運用系判断処理部２３は、自ロードバランサ２の仮想ＩＰアドレスを宛先とした信号を受信した場合に、記憶部２２１に記憶されている両系のキャッシュサーバ１の参照部１１及び転送部１５のヘルスチェックの応答受信状態、つまり、正常か異常かの状態に基づいて運用系のキャッシュサーバ１を判断する。運用系判断処理部２３は、運用系と判断したキャッシュサーバ１の物理ＩＰアドレスを宛先として受信信号を送信することにより、運用系のキャッシュサーバ１の参照部１１または転送部１５へ振り分ける。
【００４８】
以下、ロードバランサ２ａが備えるロードバランサ２の各部には符号に「ａ」を付加して記載し、ロードバランサ２ｂが備えるロードバランサ２の各部には符号に「ｂ」を付加して記載する。例えば、ロードバランサ２ａが備えるサービスチェック部２２はサービスチェック部２２ａ、ロードバランサ２ｂが備えるサービスチェック部２２はサービスチェック部２２ｂと記載する。
なお、ロードバランサ２ａとロードバランサ２ｂは異なるネットワーク装置によって実現してもよく、同一のネットワーク装置によって実現してもよい。
【００４９】
同図において、原本データ管理装置３は、データ管理部３１、更新履歴記憶部３２、及び、原本データ記憶部３３を含んで構成される。データ管理部３１は、原本データ記憶部３３に記憶されている原本データの読み書きを行ない、原本データの更新を行なったときには、更新した原本データと、その原本データの更新日時の情報とを対応付けた更新履歴を更新履歴記憶部３２に書き込む。
【００５０】
［２． 系状態確認処理］
本実施形態のキャッシュシステムにおける系状態確認処理の動作について説明する。
【００５１】
［２．１ 系状態確認シーケンス］
図４は、キャッシュシステムの系状態確認シーケンスを示す図である。同図において、キャッシュサーバ１−０、１−１の参照部１１及び転送部１５は、定期的に自機能部の自系内状態監視処理を行っている（ステップＳ１０５−１〜Ｓ１０５−４）。なお、参照部１１−０、１１−１、転送部１５−０、１５−１の間でタイミングを同期させる必要はない。
【００５２】
一方、ロードバランサ２は、定期的にヘルスチェックを起動する。つまり、ロードバランサ２は、キャッシュサーバ１−０の物理ＩＰアドレスＣ０及び参照部１１−０のポート番号ＰＳ０、キャッシュサーバ１−０の物理ＩＰアドレスＣ０及び転送部１５−０のポート番号ＰＴ０、キャッシュサーバ１−１の物理ＩＰアドレスＣ１及び参照部１１−１のポート番号ＰＳ１、キャッシュサーバ１−１の物理ＩＰアドレスＣ１及び転送部１５−１のポート番号ＰＴ１を宛先としてヘルスチェック信号を送信する（ステップＳ１１０、Ｓ１１５−１〜Ｓ１１５−４）。
【００５３】
０系の参照部１１−０は、系内状態監視結果返却処理を実行し（ステップＳ１２０−１）、ステップＳ１０５−１により確認した自系の参照部１１−０についての系内状態監視結果に応じてロードバランサ２へ応答を返送する（ステップＳ１２５−１）。０系の転送部１５−０は、系内状態監視結果返却処理を実行し（ステップＳ１２０−２）、ステップＳ１０５−２により確認した自系の転送部１５−０についての系内状態監視結果に応じてロードバランサ２へ応答を返送する（ステップＳ１２５−２）。同様に、１系の参照部１１−１は、系内状態監視結果返却処理を実行し（ステップＳ１２０−３）、ステップＳ１０５−３により確認した自系の参照部１１−１についての系内状態監視結果に応じてロードバランサ２へ応答を返送する（ステップＳ１２５−３）。また、１系の転送部１５−１は、系内状態監視結果返却処理を実行し（ステップＳ１２０−４）、ステップＳ１０５−４により確認した自系の転送部１５−１についての系内状態監視結果に応じてロードバランサ２へ応答を返送する（ステップＳ１２５−４）。
ロードバランサ２は、両系のキャッシュサーバ１の参照部１１及び転送部１５それぞれからのヘルスチェック信号への応答状態を確認し、その確認結果を保持する（ステップＳ１３０）。
【００５４】
その後も、キャッシュサーバ１−０、１−１の参照部１１、転送部１５は、ステップＳ１０５−１〜Ｓ１０５−４と同様に各機能部の自系内状態監視処理を定期的に起動する（ステップＳ１３５−１〜Ｓ１３５−４、Ｓ１４０−１〜Ｓ１４０−４）。また、ロードバランサ２は、ステップＳ１１０、Ｓ１１５−１〜Ｓ１１５−４の処理と同様に、キャッシュサーバ１−０、１−１の参照部１１及び転送部１５にヘルスチェック信号を定期的に送信する（ステップＳ１４５、Ｓ１５０−１〜Ｓ１５０−４）。これにより、ステップＳ１２０−１〜Ｓ１２０−４、Ｓ１２５−１〜Ｓ１２５−４、Ｓ１３０と同様の処理が行なわれる（ステップＳ１５５−１〜Ｓ１５５−４、Ｓ１６０−１〜Ｓ１６０−４、Ｓ１６５）。
【００５５】
上述したロードバランサ２の処理は、ロードバランサ２ａ、２ｂそれぞれについて行なわれる。
【００５６】
［２．２ 系状態確認処理における各装置の機能部間の処理の流れ］
図５は、系状態確認処理における各装置の機能部間の処理の流れを示す図である。
両系のキャッシュサーバ１の参照部１１において、監視処理部１１２は、各プロセスの生起を確認してその結果を監視結果記憶部１２１に保持し（ステップＳ３０５−１）、続いて、ダミーのＳＱＬを発行して参照データ管理部１１４の動作確認を行い、確認結果を監視結果記憶部１２１に保持する（ステップＳ３１０−１）。同様に、両系のキャッシュサーバ１の転送部１５において、監視処理部１５２は、各プロセスの生起を確認してその結果を監視結果記憶部１６１に保持し（ステップＳ３０５−２）、続いて、ダミーのＳＱＬを発行して転送データ管理部１５４の動作確認を行い、確認結果を監視結果記憶部１６１に保持する（ステップＳ３１０−２）。
【００５７】
ロードバランサ２のサービスチェック部２２は、両系のキャッシュサーバ１の参照部１１及び転送部１５それぞれにヘルスチェック信号を送信する（ステップＳ３１５−１、Ｓ３１５−２）。両系のキャッシュサーバ１の監視結果通知処理部１１３は、ヘルスチェック信号を受信すると、監視処理部１１２から監視結果記憶部１２１に保持されている系状態の監視結果を取得し（ステップＳ３２０−１）、取得した監視結果が「正常」である場合は応答を返送する（ステップＳ３２５−１）。同様に、両系のキャッシュサーバ１の監視結果通知処理部１５３は、ヘルスチェック信号を受信すると、監視処理部１５２から監視結果記憶部１６１に保持されている系状態の監視結果を取得し（ステップＳ３２０−２）、取得した監視結果が「正常」である場合は応答を返送する（ステップＳ３２５−２）。ロードバランサ２のサービスチェック部２２は、両系のキャッシュサーバ１の参照部１１及び転送部１５からの応答の有無を記憶部２２１に保持する。
【００５８】
［２．３ キャッシュサーバ１における自系内状態監視処理］
図６は、図４のステップＳ１０５−１〜Ｓ１０５−４、Ｓ１３５−１〜Ｓ１３５−４、Ｓ１４０−１〜Ｓ１４０−４において、両系のキャッシュサーバ１の参照部１１及び転送部１５が実行する自系内状態監視処理フローを示す図である。
【００５９】
まず、参照部１１における自系内状態監視処理フローを説明する。同図において、キャッシュサーバ１のタイマ１１１は、所定の時間毎に監視処理部１１２を起動する（ステップＳ４０５）。これにより、監視処理部１１２は、自系内の参照部１１の各プロセスの生起を確認する（ステップＳ４１０）。各プロセスが生起されている場合（ステップＳ４１５：正常）、正常であると判断し、続いて、ＤＢの死活状態を確認するためダミーのＳＱＬを参照データ管理部１１４に発行する（ステップＳ４２０）。参照データ管理部１１４の参照データアクセス部１２２は、ダミーのＳＱＬに基づいて参照データ記憶部１２３に記憶されているデータに対するデータ操作を行なった結果を監視処理部１１２に返送する。参照データ管理部１１４から正常にダミーＳＱＬの応答を受信した場合（ステップＳ４２５：正常）、監視処理部１１２は、監視結果「正常」を自系の備える監視結果記憶部１２１に書き込む（ステップＳ４３０）。
【００６０】
一方、プロセスが生起されていない場合（ステップＳ４１５：異常）、あるいは、参照データ管理部１１４から正常にダミーＳＱＬの応答を受信しなかった場合（ステップＳ４２５：異常）、監視処理部１１２は、監視結果「異常」を自系の備える監視結果記憶部１２１に書き込む（ステップＳ４３５）。
【００６１】
転送部１５における自系内状態監視処理フローの場合、参照部１１を転送部１５に、タイマ１１１をタイマ１５１に、監視処理部１１２を監視処理部１５２に、参照データ管理部１１４を転送データ管理部１５４に、監視結果記憶部１２１を監視結果記憶部１６１に、参照データアクセス部１２２を転送データアクセス部１６２に、参照データ記憶部１２３を転送データ記憶部１６３に読み替え、上記と同様の処理を行なう。
【００６２】
［２．４ キャッシュサーバ１における自系内状態監視結果返却処理］
図７は、図４のステップＳ１２０−１〜１２０−４、１５５−１〜１５５−４において、両系のキャッシュサーバ１の参照部１１及び転送部１５が実行する自系内状態監視結果返却処理フローを示す図である。
【００６３】
まず、参照部１１における自系内状態監視結果返却処理フローを説明する。同図において、キャッシュサーバ１の監視結果通知処理部１１３は、ロードバランサ２からヘルスチェック信号を受信する（ステップＳ５０５）。監視結果通知処理部１１３は、監視処理部１１２から監視結果記憶部１２１に記憶されている系内状態の監視結果を取得する（ステップＳ５１０）。監視結果通知処理部１１３は、取得した系内状態監視結果が「正常」である場合は（ステップＳ５１５：正常）、ヘルスチェック信号送信元のロードバランサ２に正常を設定した応答を返送し（ステップＳ５２０）、系内状態監視結果が「異常」である場合は（ステップＳ５１５：異常）、受信したヘルスチェック信号を廃棄し、応答を返送しない（ステップＳ５２５）。
【００６４】
転送部１５における自系内状態監視結果返却処理フローの場合、監視処理部１１２を監視処理部１５２に、監視結果通知処理部１１３を監視結果通知処理部１５３に、監視結果記憶部１２１を監視結果記憶部１６１に読み替え、上記と同様の処理を行なう。
【００６５】
［２．５ ロードバランサ２におけるヘルスチェック］
図８は、図４のステップＳ１１０及びＳ１３０、Ｓ１４５及びＳ１５５において実行される、ロードバランサ２のヘルスチェック処理フローを示す図である。
同図において、ロードバランサ２のタイマ２１は、所定の時間毎にサービスチェック部２２を起動する（ステップＳ６０５）。まず、０系の参照部１１についてのヘルスチェックが起動された場合について説明する。サービスチェック部２２は、キャッシュサーバ１−０の物理ＩＰアドレスＣ０、参照部１１−０のポート番号ＰＳ０を宛先としてヘルスチェック信号を送信する（ステップＳ６１０）。
【００６６】
サービスチェック部２２は、ステップＳ６１０において送信したヘルスチェック信号に対して、図７のステップＳ５２０においてキャッシュサーバ１の監視結果通知処理部１１３が送信した応答を受信した場合（ステップＳ６１５：応答あり）、参照部１１−０の識別情報と対応付けて「応答あり」を記憶部２２１に書き込む（ステップＳ６２０）。
一方、ステップＳ６１０において送信したヘルスチェック信号に対して所定時間内に応答を受信しなかった場合（ステップＳ６１５：応答なし）、参照部１１−０の識別情報と対応付けて「応答なし」を記憶部２２１に書き込む（ステップＳ６２５）。
【００６７】
ステップＳ６０５において、０系の転送部１５−０についてのヘルスチェックが起動された場合、ステップＳ６１０において、サービスチェック部２２は、キャッシュサーバ１−０の物理ＩＰアドレスＣ０、転送部１５−０のポート番号ＰＴ０を宛先としてヘルスチェック信号を送信する。そして、ステップＳ６２０においては、転送部１５−０の識別情報と対応付けて「応答あり」を、ステップＳ６２５においては、転送部１５−０の識別情報と対応付けて「応答なし」を記憶部２２１に書き込む。
【００６８】
同様に、ステップＳ６０５において、１系の参照部１１−１についてのヘルスチェックが起動された場合、ステップＳ６１０において、サービスチェック部２２は、キャッシュサーバ１−１の物理ＩＰアドレスＣ１、参照部１１−１のポート番号ＰＳ１を宛先としてヘルスチェック信号を送信する。そして、ステップＳ６２０においては、参照部１１−１の識別情報と対応付けて「応答あり」を、ステップＳ６２５においては、参照部１１−１の識別情報と対応付けて「応答なし」を記憶部２２１に書き込む。
【００６９】
また、ステップＳ６０５において、１系の転送部１５−１についてのヘルスチェックが起動された場合、ステップＳ６１０において、サービスチェック部２２は、キャッシュサーバ１−１の物理ＩＰアドレスＣ１、転送部１５−１のポート番号ＰＴ１を宛先としてヘルスチェック信号を送信する。そして、ステップＳ６２０においては、転送部１５−１の識別情報と対応付けて「応答あり」を、ステップＳ６２５においては、転送部１５−１の識別情報と対応付けて「応答なし」を記憶部２２１に書き込む。
【００７０】
［３． 振分処理］
ロードバランサ２ａ、２ｂは、上述したヘルスチェックにより、キャッシュサーバ１−０、１−１の参照部１１及び転送部１５それぞれが正常であるか異常であるかを判定するためのヘルスチェック結果を保持する。つまり、応答が返送された場合は運用状態が正常、応答が返送されなかった場合は異常であると判断することができる。そして、ロードバランサ２ａは、アプリケーション装置４からのデータ参照要求を受信するたびに、ヘルスチェック結果を利用して運用系のキャッシュサーバ１を決定し、データ参照要求の振分処理を行なう。また、ロードバランサ２ｂは、キャッシュサーバ１から系状態識別信号を受信するたびに、同様の振分処理を行う。以下、振分処理の動作について説明する。
【００７１】
［３．１ 振分処理シーケンス］
図９は、アプリケーション装置４からのデータ参照要求受信時の振分処理シーケンスを示す図である。
同図において、ロードバランサ２ａは、アプリケーション装置４から、ロードバランサ２ａの仮想ＩＰアドレスＡを宛先としたデータ参照要求を受信する（ステップＳ７０５）。ロードバランサ２は、ヘルスチェック処理結果を参照して、運用系のキャッシュサーバ１を判断する（ステップＳ７１０）。ここでは、キャッシュサーバ１−０が運用系であると判断したと仮定する。ロードバランサ２は、データ参照要求の宛先を、運用系であるキャッシュサーバ１−０の物理ＩＰアドレスＣ０及び参照部１１−０のポート番号ＰＳ０として送信する（ステップＳ７１５）。０系の参照部１１−０は、受信したデータ参照要求に対する応答を返送すると（ステップＳ７２０）、ロードバランサ２ａは、データ参照要求の送信元であるアプリケーション装置４へ応答を送信する（ステップＳ７２５）。
【００７２】
ロードバランサ２ａは、アプリケーション装置４から、ロードバランサ２ａの仮想ＩＰアドレスＡを宛先としたデータ参照要求を受信するたびに、ヘルスチェック処理結果を参照して、運用系のキャッシュサーバ１を判断する。つまり、同図に示すように、ロードバランサ２ａは、再びアプリケーション装置４からデータ参照要求を受信すると（ステップＳ７３０）、ヘルスチェック処理結果を参照して、運用系のキャッシュサーバ１を判断する（ステップＳ７３５）。以降のステップＳ７４５〜Ｓ７５０の処理は、ステップＳ７１５〜Ｓ７２０の処理と同様である。
【００７３】
なお、振分処理において、ロードバランサ２ａが、運用系はキャッシュサーバ１−１であると判断した場合、アプリケーション装置４から受信したデータ参照要求の宛先を、運用系であるキャッシュサーバ１−１の物理ＩＰアドレスＣ１及び参照部１１−１のポート番号ＰＳ１として送信する。そして、１系の参照部１１−１がデータ参照要求に対する応答を返送すると、ロードバランサ２ａは、データ参照要求の送信元であるアプリケーション装置４へ応答を送信する。
【００７４】
図１０は、キャッシュサーバ１からの系状態識別信号受信時の振分処理シーケンスを示す図である。
同図において、ロードバランサ２ｂは、０系の転送部１５−０からロードバランサ２ｂの仮想ＩＰアドレスＢを宛先とした系状態識別信号を受信する（ステップＳ８０５）。ロードバランサ２ｂは、ヘルスチェック処理結果を参照して、運用系のキャッシュサーバ１を判断する（ステップＳ８１０）。ここでは、キャッシュサーバ１−０が運用系であると判断したと仮定する。ロードバランサ２ｂは、系状態識別信号の宛先を、運用系であるキャッシュサーバ１−０の物理ＩＰアドレスＣ０及び転送部１５−０のポート番号ＰＴ０として送信する（ステップＳ８１５）。０系の転送部１５−０は、自系が送信した系状態識別信号を受信するため、運用系であることを認識する。
【００７５】
同様に、ロードバランサ２ｂは、１系の転送部１５−１からロードバランサ２ｂの仮想ＩＰアドレスＢを宛先とした系状態識別信号を受信する（ステップＳ８２０）。ロードバランサ２ｂは、ヘルスチェック処理結果を参照し、キャッシュサーバ１−０が運用系であると判断したと仮定する（ステップＳ８２５）。ロードバランサ２ｂは、系状態識別信号の宛先を、運用系であるキャッシュサーバ１−０の物理ＩＰアドレスＣ０及びポート番号ＰＴ０として送信する（ステップＳ８３０）。１系の転送部１５−１は、自系が送信した系状態識別信号を受信できないため、待機系であることを認識する。
【００７６】
なお、振分処理において、ロードバランサ２ｂが、運用系はキャッシュサーバ１−１であると判断した場合、キャッシュサーバ１−０、１−１から受信した系状態識別信号の宛先を、運用系であるキャッシュサーバ１−１の物理ＩＰアドレスＣ１及び転送部１５−１のポート番号ＰＴ１として送信する。これにより、１系の転送部１５−１は、自系が送信した系状態識別信号を受信するため、運用系であることを認識し、０系の転送部１５−０は、自系が送信した系状態識別信号を受信できないため、待機系であることを認識する。
【００７７】
［３．２ ロードバランサ２における振分処理］
図１１は、ロードバランサ２ａにおける振分処理フローを示す図である。
同図においてロードバランサ２ａは、ロードバランサ２ａの仮想ＩＰアドレスＡを宛先としたデータ参照要求をアプリケーション装置４から受信したことを契機に、運用系判断処理部２３ａを起動する（ステップＳ９０５）。運用系判断処理部２３ａは、サービスチェック部２２ａの記憶部２２１ａから、０系の参照部１１−０及び転送部１５−０、１系の参照部１１−１及び転送部１５−１それぞれからのヘルスチェック信号の応答ありなしの結果を読み出すとともに（ステップＳ９１０）、運用フラグを読み出し、保持する（ステップＳ９１５）。なお、運用フラグとは、０系及び１系の参照部１１の応答状態が同じであり、かつ、０系及び１系の転送部１５の応答状態が同じである場合など、応答の状態からは運用系を決定することができない場合に参照するフラグであり、０系を振分先とする場合は「０」、１系を振分先とする場合は「１」、０系及び１系とも振分不可である場合は「３」の値をとる。通常は、システム開始時に初期値として「０」か「１」を設定する。
【００７８】
続いて、運用系判断処理部２３ａは、図１２に示す振分け状態表に従い、振分け状態を判断する（ステップＳ９２０）。
すなわち、運用系判断処理部２３ａは、０系及び１系の参照部１１の両方から応答があり、かつ、０系及び１系の転送部１５の応答有無の状態が同じであった場合は振分状態「２」とする。また、０系の参照部１１−０から応答があり、１系の参照部１１−１から応答がなかった場合、あるいは、０系及び１系の参照部１１、ならびに、０系の転送部１５−０から応答があり、１系の転送部１５−１から応答がなかった場合は振分状態「０」とする。また、０系の参照部１１−０から応答がなく、１系の参照部１１−１から応答があった場合、あるいは、０系及び１系の参照部１１、ならびに、１系の転送部１５−１から応答があり、０系の転送部１５−０から応答がなかった場合は振分状態「１」とする。また、０系及び１系の参照部１１の両方から応答がなかった場合は振分け状態「３」と判断する。
【００７９】
振分け状態が「０」であると判断した場合（ステップＳ９２０：振分け状態０）、運用系判断処理部２３ａは、ステップＳ９０５において受信したデータ参照要求の宛先をキャッシュサーバ１−０の物理ＩＰアドレスＣ０及び参照部１１−０のポート番号ＰＳ０として送信し（ステップＳ９２５）、記憶部２２１ａに記憶されている運用フラグに振分け状態の値を設定する（ステップＳ９３０）。これにより、運用フラグには「０」が設定される。
【００８０】
振分け状態が「１」であると判断した場合（ステップＳ９２０：振分け状態１）、運用系判断処理部２３ａは、ステップＳ９０５において受信したデータ参照要求の宛先をキャッシュサーバ１−１の物理ＩＰアドレスＣ１及び参照部１１−１のポート番号ＰＳ１として送信し（ステップＳ９３５）、記憶部２２１ａに記憶されている運用フラグに振分け状態の値を設定する（ステップＳ９３０）。これにより、運用フラグには「１」が設定される。
【００８１】
振分け状態が「２」であると判断した場合（ステップＳ９２０：振分け状態２）、０系１系とも正常に動作しているため、応答の状態からはどちらのキャッシュサーバ１を運用系、待機系とするかを判断することはできない。そこで、運用系判断処理部２３ａは、さらに、ステップＳ９１５にお保持していた運用フラグを取得し（ステップＳ９４０）、値が「０」または「１」であるかを判断する（ステップＳ９４５）。
運用フラグが「０」または「１」である場合（ステップＳ９４５：真）、運用系判断処理部２３ａは、運用フラグにおいて示される系のキャッシュサーバ１にステップＳ９０５において受信したデータ参照要求を送信する（ステップＳ９５０）。つまり、運用フラグが「０」である場合は、データ参照要求の宛先アドレスをキャッシュサーバ１−０の物理ＩＰアドレスＣ０及び参照部１１−０のポート番号ＰＳ０に変換して送信し、運用フラグが「１」である場合は、データ参照要求の宛先アドレスをキャッシュサーバ１−１の物理ＩＰアドレスＣ１及び参照部１１−１のポート番号ＰＳ１に変換して送信する。これにより、０系１系の両方が正常に動作している間は同じ系が振分先となる。
【００８２】
一方、運用フラグが「０」でも「１」でもない場合（ステップＳ９４５：偽）、運用系判断処理部２３ａは、０系を振分先とする。運用系判断処理部２３ａは、ステップＳ９０５において受信したデータ参照要求の宛先アドレスをキャッシュサーバ１−０の物理ＩＰアドレスＣ０及び参照部１１−０のポート番号ＰＳ０に変換して送信し（ステップＳ９５５）、運用フラグへ「０」を設定する（ステップＳ９６０）。従って、０系及び１系の両方に異常が発生した後、同時に正常に戻った場合には、０系を振分先とする。
【００８３】
振分け状態「３」であると判断した場合（ステップＳ９２０：振分け状態３）、０系、１系ともに異常が発生しているため、運用系判断処理部２３ａは、ステップＳ９０５において受信したデータ参照要求に対するエラー応答をアプリケーション装置４へ返送し（ステップＳ９６５）、運用フラグへ「３」を設定する（ステップＳ９７０）。
【００８４】
図１３は、ロードバランサ２ｂにおける振分処理の処理フローを示す図である。
同図においてロードバランサ２ｂは、ロードバランサ２ｂの仮想ＩＰアドレスＢを宛先とした系状態識別信号をキャッシュサーバ１から受信したことを契機に、運用系判断処理部２３ｂを起動する（ステップＳ１００５）。
ステップＳ１０１０以降の処理は、図１１に示すステップＳ９１０以降の処理と同様であり、振分け状態表も同じ設定内容である。ただし、運用系判断処理部２３ａ、記憶部２２１ａ、参照部１１−０のポート番号ＰＳ０、参照部１１−１のポート番号ＰＳ１はそれぞれ、運用系判断処理部２３ｂ、記憶部２２１ｂ、転送部１５−０のポート番号ＰＴ０、転送部１５−１のポート番号ＰＴ１と読み替え、ステップＳ９０５においてアプリケーション装置４から受信したデータ参照要求は、ステップＳ１００５においてキャッシュサーバ１から受信した系状態識別信号と読み替える。よって、ステップＳ１０６５においてはエラー応答を系状態識別信号の送信元のキャッシュサーバ１の転送部１５に返送することになる。
【００８５】
［４． データ同期処理］
キャッシュシステムでは、原本データ管理装置３が記憶する実データとの同期をとりつつ、キャッシュサーバ１−０、１−１間でデータの同期をとる必要がある。以下では、本実施形態のデータ同期方法を採用した理由について説明した後、本実施の形態によるキャッシュシステムにおける同期処理の動作について説明する。
【００８６】
［４．１ データ同期方法の検討過程］
図１４は、本実施の形態によるキャッシュシステムへの適用を検討した原本データ同期方法を示す図である。
図１４（ａ）は、原本データ管理装置３から両系のキャッシュサーバ１それぞれに対して実データを反映させる方法である。この方法では、両系のキャッシュサーバ１間でデータの同期を行なう必要がない。しかし、原本データ管理装置３に負荷がかかるとともに、同期のための機能を追加しなければならず、また、原本データ管理装置３からの実データの転送時にミスが発生した場合、キャッシュサーバ１では実データとの差分を反映できないままとなるという問題がある。加えて、両系のキャッシュサーバ１が記憶するデータの整合性が担保できず、系切り替え時にデータの同期がとれなくなってしまうおそれがあり、リダンダンシそのものが実現できないという問題もある。
【００８７】
図１４（ｂ）は、原本データ管理装置３から一方のキャッシュサーバ１のみ対して実データを反映させ、その後、キャッシュサーバ１の系間でデータの同期をとる方法である。この方法では、原本データ管理装置３に原本データ書き込みのための機能を追加しなければならず、また、原本データ管理装置３からの実データの転送時に時にミスが発生した場合、キャッシュサーバ１では実データとの差分を反映できないままとなるという問題がある。さらには、原本データ管理装置３において、キャッシュサーバ１に系切替えが発生している場合についての動作を考慮しなければならず、系切り替え時データの同期がとれなくなってしまうおそれがあり、リダンダンシそのものが実現できないという問題もある。
【００８８】
図１４（ｃ）は、一方のキャッシュサーバ１が定期的に原本データ管理装置３から原本データを読み出し、系間でデータの同期をとる方法である。この方法の場合、考慮すべき点はあるものの、系切り替えに伴うデータロストの最小化といったリダンダンシの根幹に係る条件をクリアしている。
そこで、本実施形態では、図１４（ｃ）の方法をベースとして、運用系、待機系を認識せずに動作しているキャッシュサーバ１のどちらが原本データとの同期を行なうかを決定する処理を追加するとともに、系間においてデータ同期がどこまで行なわれたかを管理可能な系間同期方法を追加した。
【００８９】
独立した２つのキャッシュサーバ１のどちらが原本データとの同期を行なうかについては、図１０等においても説明したように、各々のキャッシュサーバ１がロードバランサ２ｂの仮想ＩＰアドレス宛てにダミーリクエスト、つまり、系状態識別信号を送信し、そのリクエストの応答返却をもって同期を行なう側であることを認識し、データ同期処理を起動する。
【００９０】
図１５は、本実施の形態によるキャッシュシステムへの適用を検討した系間の同期方法を示す図である。
図１５（ａ）は、既存のＤＢＭＳが持つデータ同期機能を用いる方法を示す図である。本実施の形態においては、両系のキャッシュサーバ１は自系の状態、他系の系状態とも意識せず、外部のネットワーク装置であるロードバランサ２によって系が切り替えられる。つまり、ロードバランサ２による切り替えは、既存のＤＢＭＳのリンク機能が持つ系間同期の状態とは無関係に行なわれることになる。よって、既存のＤＢＭＳのリンク機能自体は系が切り替えを行なわれたことを認識できず、正しくデータ同期を行なうことはできない。また、既存のＤＢＳＭでは、障害時のデータ紛失を回復する機能が適用されておらず、ＤＢインスタンスの再起動が必要となることがあり、適切ではない。
【００９１】
図１５（ｂ）は、原本データとは同期しない系のキャッシュサーバ１が、原本データと同期する側のキャッシュサーバ１から更新されたデータを吸い上げる方法である。この方法の場合、原本データとの同期の処理、系間の同期の処理が両系に分散しているため、系切り替え時にデータの不整合が発生する可能性があるとともに、系障害時、旧サービスルート側に残ったデータの消去ができないという問題がある。また、両系のキャッシュサーバ１において系の状態を意識しなくてはならず、本実施形態にはそぐわない。
【００９２】
図１５（ｃ）は、原本データと同期する系のキャッシュサーバ１が、原本データと同期しない側のキャッシュサーバ１へ更新されたデータを書き込む方法である。この方法の場合、原本データとの同期を行なう系のキャッシュサーバ１において、系間の同期の処理も行なうためにデータ同期処理が片方の系に集約され、系切り替え時にデータの不整合が発生することを防ぐことができる。
そこで、図１５（ｃ）の方法を系間の同期方法として採用し、以下のようにデータ同期がどこまで行なわれたかの管理方法を追加した。
【００９３】
つまり、図１５（ｃ）の方法では、系間でデータの転送中に系切り替えが発生するなどして、新しく原本データと同期する側になった系は、どの時点から原本データとの同期を行なえばよいかを把握することができない。そこで、データ同期がどこまで行なわれたかを、原本データ管理装置３において原本データが更新されたときに付与されたタイムスタンプを利用して管理する。具体的には、原本データと同期する系のキャッシュサーバ１は、原本データ管理装置３から更新された原本データを読み出すときは、その各原本データの更新日時とともに読み出し、その中で最新の更新日時を同期日時として保持する。そして、原本データと同期しない側のキャッシュサーバ１へ更新された原本データを書き込むときには、同期日時も同時に通知する。これにより、次に同期を行なうタイミングのときに、原本データと同期する系のキャッシュサーバ１は、自系が保持している同期日時以降が更新日時である原本データを原本データ管理装置３から読み出せばよい。
【００９４】
［４．２ データ同期シーケンス］
図１６は、キャッシュシステムのデータ同期シーケンスを示す図である。
同図は、キャッシュサーバ１−０が運用系、キャッシュサーバ１−１が待機系であるとロードバランサ２ｂに判断されている場合の例を示す。
両系のキャッシュサーバ１の転送部１５は、定期的に系状態識別処理を起動し、系状態識別信号をロードバランサ２ｂに送信している。同図において、０系の転送部１５−０が、ロードバランサ２ｂに対して系状態識別信号を送信すると、図１０のステップＳ８０５〜Ｓ８１５の処理が行なわれる（ステップＳ１１０５）。
【００９５】
ロードバランサ２ｂが、キャッシュサーバ１−０を運用系と判断しているため、０系の転送部１５−０は自系の送信した系状態識別信号を受信する。これにより、転送部１５−０は、自系が運用系であると判断し、処理を継続することを決定して（ステップＳ１１１０）、原本データとの同期処理を起動する（ステップＳ１１１５）。転送部１５−０は、原本データ管理装置３に原本データ取得を送信し（ステップＳ１１２０）、原本データ管理装置３のデータ管理部３１は、原本データ記憶部３３から原本データを読み出して（ステップＳ１１２５）、転送部１５−０に返送する（ステップＳ１１３０）。転送部１５−０は、受信した原本データにより、転送データ記憶部１６３−０に記憶されているデータを更新した後（ステップＳ１１３５）、系間同期処理を行なう（ステップＳ１１４０）。すなわち０系の転送部１５−０は、１系の転送部１５−１に更新対象の原本データを送信し（ステップＳ１１４５）、転送部１５−１は、受信した原本データにより転送データ記憶部１６３−１に記憶されているデータを更新する（ステップＳ１１５０）。更新が正常に終了した場合、１系の転送部１５−１は、０系の転送部１５−０に正常応答を返送する（ステップＳ１１５５）。
【００９６】
一方、１系の転送部１５−１も、ロードバランサ２ｂに対して系状態識別信号を送信している。これにより、同様に、図１０のステップＳ８２０〜Ｓ８３０の処理が行なわれる（ステップＳ１１６０）。上述したように、ロードバランサ２ｂはキャッシュサーバ１−０を運用系と判断しているため、系状態識別信号は０系の転送部１５−０へ送信される。転送部１５−１は自系が送信した系状態識別信号を受信できないため、自系が待機系であると判断して処理を終了する（ステップＳ１１６５）。
【００９７】
両系のキャッシュサーバ１の転送部１５はステップＳ１１０５、Ｓ１１６０の処理を定期的に起動し、運用系と待機系の入れ替えがない間は、上述したステップＳ１１０５〜Ｓ１１６５の処理を繰り返す。系状態が入れ替わり、キャッシュサーバ１−１が運用系となったときには、上記処理における０系の転送部１５−０と１系の転送部１５−１の動作が入れ替わる。
【００９８】
［４．３ データ同期処理に用いられるデータ］
図１７は、データ同期処理に用いられる各装置のデータ例を示す図である。ここでは、キャッシュサーバ１−０が運用系、キャッシュサーバ１−１が待機系であるとロードバランサ２ｂに判断されている場合の例を示す。
【００９９】
原本データ管理装置３は、原本データ記憶部３３に、アプリケーション装置４が利用する各種情報の原本データである「情報１」、「情報２」、「情報３」、「情報４」、・・・を記憶している。また、更新履歴記憶部３２には、更新された原本データである「情報１」、「情報２」、「情報３」、「情報４」と、それらの更新日時「００：００：０１」、「００：００：０２」、「００：００：０３」、「００：００：０４」とを対応付けた更新履歴ＴＢＬを記憶している。なお、原本データ管理装置３のデータ管理部３１は、原本データ記憶部３３に記憶されている原本データが更新されると、随時、更新履歴記憶部３２内の更新履歴ＴＢＬに更新された原本データとその更新日時とを対応付けて書き込んでいる。
【０１００】
運用系であるとみなされている０系の転送部１５−０が備える転送データ記憶部１６３−０には、原本データ管理装置３から読み出された原本データのコピー（キャッシュデータ）である「情報１」、「情報２」が記憶されている。また、同期情報記憶部１５６−０の更新情報ＴＢＬには、転送データ記憶部１６３−０には書き込んだが、まだキャッシュサーバ１−１との同期更新を行なっていない原本データ「情報２」とその更新日時「００：００：０２」とが対応付けて設定されている。さらに、同期情報記憶部１５６−０が記憶する最終更新情報ＴＢＬには、転送データ記憶部１６３−０に書き込みが終了した原本データの更新日時のうち、最新の更新日時であるラストルック「００：００：０２」が設定されている。
【０１０１】
待機系であるとみなされている１系の転送部１５−１が備える転送データ記憶部１６３−１には、原本データ管理装置３から読み出された原本データのコピー（キャッシュデータ）である「情報１」が記憶されている。また、同期情報記憶部１５６−１が記憶する最終更新情報ＴＢＬには、転送データ記憶部１６３−１に書き込みが終了した原本データの更新日時のうち、最新の更新日時であるラストルック「００：００：０１」が設定されている。待機系の場合、原本データ管理装置３から直接原本データを読み出さないため、通常、同期情報記憶部１５６−１の更新情報ＴＢＬは空である。
【０１０２】
［４．４ データ更新の流れ］
図１８は、原本データ同期処理におけるデータ更新の流れを示す図であり、図１７の状態から更新を行なう例を示す。
同図において、自系が運用系であることを認識した０系の転送部１５−０は、最終更新情報ＴＢＬに設定されているラストルックを取得し、この取得したラストルックと原本データ取得要求とを原本データ管理装置３に送信する（ステップＳ１２０５）。原本データ管理装置３のデータ管理部３１は、更新履歴記憶部３２内の更新履歴ＴＢＬを検索してラストルック以降が更新日時である原本データを特定し、特定した原本データとその更新日時をキャッシュサーバ１−０へ返送する。同図においては、原本データ管理装置３は、キャッシュサーバ１−０からラストルック「００：００：０２」を受信し、原本データ「情報３」とその更新日時「００：００：０３」、原本データ「情報４」とその更新日時「００：００：０４」を返送している。
【０１０３】
０系の転送部１５−０は、原本データ管理装置３から受信した原本データ「情報３」及び「情報４」を転送データ記憶部１６３−０に書き込むと（ステップＳ１２１０）、更新したこれらの原本データの更新日時のうち、最新の更新日時「００：００：０４」により最終更新情報ＴＢＬのラストルックを上書きする（ステップＳ１２１５）。
【０１０４】
なお、上記においては、０系の転送部１５−０は、最終更新情報ＴＢＬに設定されているラストルックを原本データ取得要求とともに原本データ管理装置３に送信しているが、ラストルックから所定の時間だけ遡った日時を送信してもよい。原本データ管理装置３のデータ管理部３１は、更新履歴ＴＢＬを検索して受信した日時以降が更新日時である原本データを特定し、特定した原本データとその更新日時を返送する。
【０１０５】
図１９は、系間データ同期処理におけるデータ更新の流れを示す図であり、図１８に示す処理に続いて実行する場合の例を示す。
図１８のステップＳ１２１５の処理の前または後、０系の転送部１５−０は、更新情報ＴＢＬに、ステップＳ１２１０において受信した原本データ「情報３」とその更新日時「００：００：０３」、原本データ「情報４」とその更新日時「００：００：０４」を追加して書き込む（ステップＳ１３０５）。
【０１０６】
０系の転送部１５−０は、１系の転送部１５−１が保持する最終更新情報ＴＢＬからラストルック「００：００：０１」を読み出すと、自系が保持する更新情報ＴＢＬに設定されている更新日時と比較する（ステップＳ１３１０）。０系の転送部１５−０は、１系の転送部１５−１から読み出したラストルック以降が更新日時である更新情報ＴＢＬ内の原本データを特定し、特定した原本データにより１系の転送部１５−１が備える転送データ記憶部１６３−１に記憶されている情報を更新する。これにより、キャッシュサーバ１−１の転送データ記憶部１６３−１に、「情報２」、「情報３」、「情報４」が書き込まれる（ステップＳ１３１５）。
【０１０７】
０系の転送部１５−０は、ステップＳ１３１５において１系の転送データ記憶部１６３−１に書き込んだ原本データの更新日時のうち、最新の更新日時「００：００：０４」をラストルックとして１系の転送部１５−１が記憶している最終更新情報ＴＢＬに書き込む（ステップＳ１３２０）。０系の転送部１５−０は、１系の転送部１５−１に書き込んだ原本データである「情報２」、「情報３」、「情報４」を更新情報ＴＢＬから削除する。
【０１０８】
［４．５ キャッシュサーバ１における更新処理］
図２０は、図１６のステップＳ１１０５、Ｓ１１６０において、両系のキャッシュサーバ１の転送部１５が実行する系状態識別処理フローを示す。
同図において、キャッシュサーバ１のタイマ１５１は、所定の時間毎に系状態識別処理を起動し、これにより、系状態識別部１５５は、ロードバランサ２ｂの仮想ＩＰアドレスＢ宛に系状態識別信号を送信する（ステップＳ１４０５）。ロードバランサ２ｂは、図１３に示す振分処理を行い、受信した系状態識別信号を運用系と判断しているキャッシュサーバ１に送信する。
【０１０９】
ステップＳ１４０５において系状態識別信号を送信した後、自系が送信したこの系状態識別信号を受信できなかった場合（ステップＳ１４１０：到達しない）、系状態識別部１５５は、自系が現在待機系であると判断し、その系状態を保持する（ステップＳ１４１５）。
【０１１０】
ステップＳ１４０５において系状態識別信号を送信した後、自系が送信したこの系状態識別信号を受信した場合（ステップＳ１４１０：到達した）、系状態識別部１５５は、自系が現在運用系であると判断してその系状態を保持する（ステップＳ１４２０）。なお、自系が送信した系状態識別信号を受信したかについては、受信した系状態識別信号に設定されている送信元ＩＰアドレスが自系の物理ＩＰアドレスであるかにより判断することができる。
【０１１１】
図２１は、図１６のステップＳ１１１０〜Ｓ１１３５、Ｓ１１６５において、両系のキャッシュサーバ１の転送部１５が実行する原本データとの同期処理フローを示す。
両系のキャッシュサーバ１の転送部１５は、図２０に示す系状態識別処理が終了すると、原本データとの同期処理を起動する。これにより、情報転送処理部１５７は、系状態識別部１５５が保持している自系の系状態を判断する（ステップＳ１５０５）。自系の系状態が待機系である場合（ステップＳ１５０５：待機系）、情報転送処理部１５７は処理を終了する。
【０１１２】
自系の系状態が運用系である場合（ステップＳ１５０５：運用系）、情報転送処理部１５７は、自系の同期情報記憶部１５６に記憶されている最終更新情報ＴＢＬからラストルックを読み出す（ステップＳ１５１０）。続いて、情報転送処理部１５７は、取得したラストルックと、原本データ取得要求を原本データ管理装置３に送信することにより、原本データ管理装置３からラストルック以降が更新日時である原本データとその更新日時の情報を取得する（ステップＳ１５１５）。情報転送処理部１５７が、ステップＳ１５１５において取得した原本データの書き込みを自系の転送データ管理部１５４に指示すると、転送データアクセス部１６２は、転送データ記憶部１６３に取得した原本データを書き込む（ステップＳ１５２０）。情報転送処理部１５７は、書き込みが終了した原本データと、原本データ管理装置３から受信したその原本データの更新日時とを対応づけて、自系の同期情報記憶部１５６が記憶している更新情報ＴＢＬに登録する（ステップＳ１５２５）。情報転送処理部１５７は、ステップＳ１５２５において登録した情報に対応した更新日時のうち最も新しい更新日時をラストルックとして、自系の同期情報記憶部１５６が記憶している最終更新情報ＴＢＬに書き込む（ステップＳ１５３０）。
【０１１３】
図２２は、図１６のステップＳ１１４０において、運用系のキャッシュサーバ１の転送部１５が実行する系間データ同期処理フローを示す。
図２１のステップＳ１５０５において自系の系状態が運用系であると判断したキャッシュサーバ１の転送部１５は、図２１に示す原本データとの同期処理が終了すると、続いて系間データ同期処理を起動する。これにより、運用系のキャッシュサーバ１の系間転送処理部１５８は、自系の同期情報記憶部１５６に記憶されている更新情報ＴＢＬから原本データとその更新日時とを取得する（ステップＳ１６０５）。さらに、系間転送処理部１５８は、他系、つまり、現在待機系であるキャッシュサーバ１の同期情報記憶部１５６に記憶されている最終更新情報ＴＢＬからラストルックを読み出す（ステップＳ１６１０）。
【０１１４】
ステップＳ１６０５において取得した、転送データ記憶部１６３に反映済みの原本データの更新日時が、ステップＳ１６１０において取得した待機系のラストルックよりも新しい場合（ステップＳ１６１５：運用系のほうが新しい）、運用系の系間転送処理部１５８は、待機系のキャッシュサーバ１の転送データ管理部１５４に、ステップＳ１６０５において取得した原本データの書き込みを指示する（ステップＳ１６２０）。これにより、待機系のキャッシュサーバ１の転送データアクセス部１６２は、自系の転送データ記憶部１６３に指示された原本データを書き込む。
【０１１５】
続いて運用系のキャッシュサーバ１の系間転送処理部１５８は、ステップＳ１６２０で待機系のキャッシュサーバ１に書き込んだ原本データに対応した原本データ管理装置３における更新日時のうち、最新の更新日時をラストルックとして待機系のキャッシュサーバ１の同期情報記憶部１５６が記憶する最終更新情報ＴＢＬに書き込む（ステップＳ１６２５）。運用系のキャッシュサーバ１の系間転送処理部１５８は、ステップＳ１６２０において、待機系のキャッシュサーバ１の転送データ記憶部１６３に書き込んだ原本データ及びその更新日時を、自系の転送データ記憶部１６３に記憶されている更新情報ＴＢＬから削除する（ステップＳ１６３０）。
【０１１６】
なお、ステップＳ１６１０において取得した待機系のラストルックが、ステップＳ１６０５において取得した、自系の転送データ記憶部１６３に反映済みの原本データの更新日時よりも新しい場合（ステップＳ１６１５：待機系のほうが新しい）、処理を終了する。
【０１１７】
両系のキャッシュサーバ１は、以下のように定期的に系内データ同期処理を行う。
キャッシュサーバ１の参照部１１において、タイマ１１１により系内同期処理部１１６が定期的に起動される。起動された系内同期処理部１１６は、転送部１５へ系内データ同期を要求する。転送部１５の系内同期処理部１５９は、参照部１１の系内同期処理部１１６から系内データ同期を受信すると、転送データアクセス部１６２が転送データ記憶部１６３から読み出した原本データを返送する。参照部１１の系内同期処理部１１６は、転送部１５の系内同期処理部１５９から受信した原本データの書き込みを参照データアクセス部１２２へ指示し、参照データアクセス部１２２は、系内同期処理部１１６が受信した原本データを参照データ記憶部１２３へ書き込む。
【０１１８】
［５．汎用インタフェース］
本実施の形態のキャッシュシステムは、複数のアプリケーション装置４からデータ参照要求を受信する。しかし、アプリケーション装置４において実行されている上位サービスアプリケーションそれぞれに対して独自のインタフェース（以下、ＩＦと記載）を定義すると、上位サービスアプリケーションの追加のたびにＩＦの実装が必要となってしまう。そこで、汎用的なＩＦ定義によりデータアクセスを行なう機能を実装し、上位サービスアプリケーションの追加に伴う開発を不要にする。
【０１１９】
汎用ＩＦ定義では、１つのＩＦ定義によって、複数の上位サービスアプリケーションが用いる複数パターンのデータ参照要求及びその応答、すなわち、ＩＮパラメータ及びＯＵＴパラメータに対応する。従って、新たなデータ参照要求及び応答のパターンが発生した場合でも設定ファイルの変更を行なうのみでよく、ＩＦ開発は不要である。
【０１２０】
図２３は、汎用ＩＦの動作概要を示す図である。同図において、アプリケーション装置４は、データ参照要求を送信する。データ参照要求は、汎用インタフェースを用いて記述したＩＮ電文であり、変換ルールを特定する識別子と、検索キーとして用いられるＩＮ項目とが設定され、ＨＴＴＰ（Hypertext Transfer Protocol）−ＳＯＡＰ（Simple Object Access Protocol）により送信される。ロードバランサ２ａによってデータ参照要求が運用系のキャッシュサーバ１に振り分けられ、運用系のキャッシュサーバ１の情報参照処理部１１５は、データ参照要求に設定されている識別子により特定される変換ルールを、情報参照処理部１１５が備えるルール記憶部１２４から取得する（ステップＳ１７０５）。
【０１２１】
ルール記憶部１２４は、識別子毎に変換ルールを記憶しており、変換ルールには、正常性チェック用データ、ＤＢアクセス文変換ルール、ＯＵＴ電文生成ルールが含まれる。
正常性チェック用データは、ＩＮ電文の正常性をチェックするための条件を示す。正常性チェック用データは、例えば、ＸＭＬ（extensible markup language）スキーマにより記述され、ＩＮ項目のパラメータのデータ型や長さ、設定値などについての正常性をチェックするための条件を記述したＸＳＤファイルである。
ＤＢアクセス文変換ルールは、汎用インタフェースのＩＮ項目をパラメータとしたＤＢアクセス文を生成するための変換ルールを示す。ＤＢアクセス文変換ルールは、例えば、ＸＳＬＴ（XML Stylesheet Language Transformations）により記述され、ＩＮ項目を検索キーとしたＳＱＬ文を生成するための変換ルールを記述したＳＱＬ導出用ＸＳＬＴファイルである。
ＯＵＴ電文生成ルールは、参照データ管理部１１４から読み出されたデータをＯＵＴ項目として設定した汎用インタフェースのＯＵＴ電文を生成するための変換ルールを示す。ＯＵＴ電文生成ルールは、例えば、ＸＳＬＴにより記述され、読み出されたデータをＯＵＴ項目としてＸＭＬ形式に整形するための変換ルールを記述したＯＵＴ電文生成用ＸＳＬＴファイルである。
【０１２２】
情報参照処理部１１５は、読み出した変換ルールを用いて、データ参照要求に設定されているＩＮ項目の正常性をチェックした後、ＩＮ項目をキーとして原本データの検索を行うＤＢアクセス文を生成し、転送データ管理部１５４へ出力する（ステップＳ１７１０）。情報参照処理部１１５は、読み出した汎用ＩＦ定義を用いて、参照データ管理部１２３からＤＢアクセス文によって読み出された原本データをＯＵＴ項目に設定したＸＭＬのＯＵＴ電文を生成し、アプリケーション装置４へ返送する（ステップＳ１７１５）。
【０１２３】
上記によって、データアクセス要求及び応答の追加時には、変換ルールを追加するのみでよく、上位サービスアプリケーションに追加に伴うＩＦ開発が不要となる。
【０１２４】
図２４は、情報参照処理部１１５における汎用インタフェース処理フローを示す図である。同図において情報参照処理部１１５は、アプリケーション装置４から送信されたデータ参照要求であるＩＮ電文から識別子を抽出する。情報参照処理部１１５は、読み出した識別子によってルール記憶部１２４に記憶されている変換ルール、すなわち、適用すべき電文正常性確認用ＸＳＤファイル、ＳＱＬ導出用ＸＳＬＴファイル、ＯＵＴ電文生成用ＸＳＬＴファイルを特定する（ステップＳ１８０５）。情報参照処理部１１５は、ステップＳ１８０５において特定した電文正常性確認用ＸＳＤファイルを適用し、ＩＮ電文に設定されているパラメータであるＩＮ項目の正常性を確認する（ステップＳ１８１０）。情報参照処理部１１５は、ステップＳ１８０５において特定したＳＱＬ導出用ＸＳＬＴファイルを用いて、ＯＵＴ項目として必要な要素となる原本データを読み出すためのＳＱＬを生成する（ステップＳ１８１５）。
【０１２５】
情報参照処理部１１５は、参照データ管理部１１４へステップＳ１８１５において生成したＳＱＬ文を出力する。参照データ管理部１１４の参照データアクセス部１２２は、受信したＳＱＬ文に従って参照データ記憶部１２３から原本データを読み出し、情報参照処理部１１５へ出力する（ステップＳ１８２０）。情報参照処理部１１５は、ステップＳ１８２０において取得した原本データに対して、ステップＳ１８０５において特定したＯＵＴ電文生成用ＸＳＬＴファイルを適用し、ＯＵＴ電文を作成する（ステップＳ１８２５）。情報参照処理部１１５は、ステップＳ１８２５において生成したＯＵＴ電文をアプリケーション装置４へ返送する。
【０１２６】
［６． 効果］
上述した本実施形態のキャッシュシステムによれば、原本データ管理装置３が故障したり、計画停止等を行なったりする場合であっても、アプリケーション装置４に最新、かつ、一元性を確保した原本データを継続して提供することができる。
【０１２７】
本実施形態のキャッシュシステムでは、両系のキャッシュサーバ１は、自系が運用系か待機系かを意識することなく、独立に非同期で動作しており、外部のネットワーク装置であるロードバランサ２に系切り替えを委ねている。そのため、キャッシュサーバ１は、データアクセス要求を受信したときに、自系の備える参照データ記憶部１２３に記憶しているキャッシュデータへのアクセスを提供すればよい。従って、従来技術のように共有ディスクを使用した場合の単一障害点の問題を解決することができ、さらには、ロードバランサ２において系切り替えの必要性を判断した場合に、迅速に系切り替えを行なうことができる。
【０１２８】
また、キャッシュサーバ１は、ロードバランサ２が有する系切り替えの機能を利用して、自系が同期を行なう系か否かを問合せることができ、問合せの結果に応じて原本データ管理装置３とのデータ同期、及び、他系のキャッシュサーバ１との系間データ同期を起動する。よって、独立した系間でもデータの整合性を保った同期を実現することができる。
また、原本データ管理装置において付与された原本データの更新日時を利用することにより、系切り替えが行なわれた場合や、系間においてデータ転送中にエラーが発生した場合であっても、原本データ管理装置とのデータの同期もれや、系間の同期もれを防ぐことが可能になる。
【０１２９】
キャッシュシステムは、上位サービスアプリケーションを実行するアプリケーション装置４と、原本データを保持する原本データ管理装置３との中間層に位置するシステムである。そのため、参照部１１と転送部１５とでは、トラフィックの増加要因やタイミングが必ずしも一致しない。例えば、参照部１１のトラフィックは、上位サービスアプリケーションを使用するユーザの増加や、上位サービスアプリケーションの種類の増加に伴って増加する。一方、転送部１５のトラフィックは、上位サービスアプリケーションから参照されるデータ項目が追加されたときに増加する。本実施の形態では、１台の筐体（サーバ）において参照部１１と転送部１５が分離されているため、将来的に、参照部１１を実行するサーバと、転送部１５を実行するサーバとに分離し、それぞれをトラフィックに応じた台数とする構成に移行することが容易となる。一般的には、上位サービスアプリケーションからのトラフィックの増加の割合のほうが高いと考えられることから、例えば、参照部１１の性能拡張及びスケールアウトによる負荷分散を可能とするために、参照部１１を実行するサーバをｎ台構成の全運用方式に、転送部１５を実行するサーバを１＋１台構成の運用待機方式へと移行するようなことも容易である。
【０１３０】
［７． その他］
上記実施形態においては、キャッシュインタフェース装置を２台のキャッシュサーバ１により多重化しているが、３台以上により多重化してもよい。キャッシュインタフェース装置を３台以上のキャッシュサーバ１により多重化する場合、そのうち少なくとも２台以上がアクト系として動作しているものとし、ロードバランサ２は、アクト系のキャッシュサーバ１について上述した処理を行ない、アクト系のキャッシュサーバ１の中の１台を運用系として判断する。
また、キャッシュサーバ１として動作する１台の筐体（サーバ）に、複数の参照部１１を備える構成としてもよい。
【０１３１】
なお、上述のキャッシュサーバ１、ロードバランサ２、原本データ管理装置３、アプリケーション装置４は、内部にコンピュータシステムを有している。そして、キャッシュサーバ１の監視処理部１１２、監視結果通知処理部１１３、参照データ管理部１１４、情報参照処理部１１５、系内同期処理部１１６、監視処理部１５２、監視結果通知処理部１５３、転送データ管理部１５４、系状態識別部１５５、情報転送処理部１５７、系間転送処理部１５８及び系内同期処理部１５９、ロードバランサ２のサービスチェック部２２及び運用系判断処理部２３、原本データ管理装置３のデータ管理部３１、ならびに、アプリケーション装置４の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、ＣＰＵ及び各種メモリやＯＳ、周辺機器等のハードウェアを含むものである。
【０１３２】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【符号の説明】
【０１３３】
１、１−０、１−１…キャッシュサーバ
１１、１１−０、１１−１…参照部
１１１、１５１…タイマ
１１２、１５２…監視処理部
１１３、１５３…監視結果通知処理部
１１４…参照データ管理部
１１５…情報参照処理部
１１６、１５９…系内同期処理部
１２１、１６１…監視結果記憶部
１２２…参照データアクセス部
１２３…参照データ記憶部
１５、１５−０、１５−１…転送部
１５４…転送データ管理部
１５５…系状態識別部
１５６…同期情報記憶部
１５７…情報転送処理部
１５８…系間転送処理部
１６２…転送データアクセス部
１６３…転送データ記憶部
２、２ａ、２ｂ…ロードバランサ
２１…タイマ
２２…サービスチェック部
２２１…記憶部
２３…運用系判断処理部
３…原本データ管理装置
３１…データ管理部
３２…更新履歴記憶部
３３…原本データ記憶部
４…アプリケーション装置
【特許請求の範囲】
【請求項１】
原本データをキャッシュする複数のキャッシュ装置と、受信信号を複数の前記キャッシュ装置のいずれに振り分けるかを管理するアクセス振分装置とを備えるキャッシュシステムであって、
複数の前記キャッシュ装置それぞれは、
前記アクセス振分装置から振り分けられたデータアクセス要求を受信し、受信したデータアクセス要求に応じて自キャッシュ装置がキャッシュしている原本データへのアクセス処理を行う参照部と、
原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する転送部とを備え、
前記アクセス振分装置は、
アクト状態の複数の前記キャッシュ装置の前記参照部及び前記転送部それぞれの運用状態を取得するサービスチェック部と、
前記サービスチェック部が取得した複数の前記キャッシュ装置の前記参照部及び前記転送部の運用状態に基づいて、複数の前記キャッシュ装置の中から受信信号の振分先となる前記キャッシュ装置を判定する運用系判断処理部とを備える、
ことを特徴とするキャッシュシステム。
【請求項２】
前記運用系判断処理部は、前記参照部の運用状態に基づいて複数の前記参照部が正常であると判断した場合、正常な前記参照部を備える複数の前記キャッシュ装置の中から、前記転送部の運用状態に基づいて正常であると判断される前記転送部を備える前記キャッシュ装置を振分先と判定する、
ことを特徴とする請求項１に記載のキャッシュシステム。
【請求項３】
複数の前記キャッシュ装置それぞれの転送部は、
前記振分装置に系状態識別信号を送信する系状態識別部と、
前記振分装置から自身が送信した前記系状態識別信号を受信した場合に、原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する情報転送処理部と、
他のキャッシュ装置がキャッシュしている原本データを前記情報転送処理部が読み出した前記原本データにより更新する系間転送処理部とをさらに備え、
前記アクセス振分装置の前記運用系判断処理部は、振分先として判定した前記キャッシュ装置へ受信した前記系状態識別信号を送信する、
ことを特徴とする請求項１または請求項２に記載のキャッシュシステム。
【請求項４】
前記情報転送処理部は、自身が送信した前記系状態識別信号を受信した場合に、前記原本データ管理装置から、自キャッシュ装置がキャッシュしている前記原本データよりも、前記原本データ管理装置における更新日時が新しい原本データを読み出し、自キャッシュ装置がキャッシュしている前記原本データを更新し、
前記系間転送処理部は、自キャッシュ装置がキャッシュしている前記原本データのうち、前記他のキャッシュ装置がキャッシュしている前記原本データよりも前記原本データ管理装置における更新日時が新しい原本データにより、前記他のキャッシュ装置がキャッシュしている原本データを更新する、
ことを特徴とする請求項３に記載のキャッシュシステム。
【請求項５】
前記転送部は、自キャッシュ装置がキャッシュしている前記原本データを記憶する転送データ記憶部をさらに備え、
前記情報転送処理部は、前記原本データ管理装置から読み出した前記原本データを前記転送データ記憶部に書き込み、
前記参照部は、
自キャッシュ装置がキャッシュしている前記原本データを記憶する参照データ記憶部と、
前記転送データ記憶部から読み出した前記原本データを前記参照データ記憶部に書き込む系内同期処理部と、
受信した前記データアクセス要求に応じて前記参照データ記憶部に記憶している前記原本データへのアクセス処理を行う参照データアクセス部とを備える、
ことを特徴とする請求項１から請求項４のいずれかの項に記載のキャッシュシステム。
【請求項６】
原本データをキャッシュする複数のキャッシュ装置と、受信信号を複数の前記キャッシュ装置のいずれに振り分けるかを管理するアクセス振分装置とを備えるキャッシュシステムに用いられるキャッシュアクセス方法であって、
複数の前記キャッシュ装置それぞれは、
前記アクセス振分装置から振り分けられたデータアクセス要求を受信し、受信したデータアクセス要求に応じて自キャッシュ装置がキャッシュしている原本データへのアクセス処理を行う参照部と、
原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する転送部とを備えており、
前記アクセス振分装置において、
サービスチェック部が、アクト状態の複数の前記キャッシュ装置の前記参照部及び前記転送部それぞれの運用状態を取得する状態取得過程と、
運用系判断処理部が、前記状態取得過程において取得した複数の前記キャッシュ装置の前記参照部及び前記転送部の運用状態に基づいて、複数の前記キャッシュ装置の中から受信信号の振分先となる前記キャッシュ装置を判定する運用系判断処理過程と、
を有することを特徴とするキャッシュアクセス方法。
【請求項１】
原本データをキャッシュする複数のキャッシュ装置と、受信信号を複数の前記キャッシュ装置のいずれに振り分けるかを管理するアクセス振分装置とを備えるキャッシュシステムであって、
複数の前記キャッシュ装置それぞれは、
前記アクセス振分装置から振り分けられたデータアクセス要求を受信し、受信したデータアクセス要求に応じて自キャッシュ装置がキャッシュしている原本データへのアクセス処理を行う参照部と、
原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する転送部とを備え、
前記アクセス振分装置は、
アクト状態の複数の前記キャッシュ装置の前記参照部及び前記転送部それぞれの運用状態を取得するサービスチェック部と、
前記サービスチェック部が取得した複数の前記キャッシュ装置の前記参照部及び前記転送部の運用状態に基づいて、複数の前記キャッシュ装置の中から受信信号の振分先となる前記キャッシュ装置を判定する運用系判断処理部とを備える、
ことを特徴とするキャッシュシステム。
【請求項２】
前記運用系判断処理部は、前記参照部の運用状態に基づいて複数の前記参照部が正常であると判断した場合、正常な前記参照部を備える複数の前記キャッシュ装置の中から、前記転送部の運用状態に基づいて正常であると判断される前記転送部を備える前記キャッシュ装置を振分先と判定する、
ことを特徴とする請求項１に記載のキャッシュシステム。
【請求項３】
複数の前記キャッシュ装置それぞれの転送部は、
前記振分装置に系状態識別信号を送信する系状態識別部と、
前記振分装置から自身が送信した前記系状態識別信号を受信した場合に、原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する情報転送処理部と、
他のキャッシュ装置がキャッシュしている原本データを前記情報転送処理部が読み出した前記原本データにより更新する系間転送処理部とをさらに備え、
前記アクセス振分装置の前記運用系判断処理部は、振分先として判定した前記キャッシュ装置へ受信した前記系状態識別信号を送信する、
ことを特徴とする請求項１または請求項２に記載のキャッシュシステム。
【請求項４】
前記情報転送処理部は、自身が送信した前記系状態識別信号を受信した場合に、前記原本データ管理装置から、自キャッシュ装置がキャッシュしている前記原本データよりも、前記原本データ管理装置における更新日時が新しい原本データを読み出し、自キャッシュ装置がキャッシュしている前記原本データを更新し、
前記系間転送処理部は、自キャッシュ装置がキャッシュしている前記原本データのうち、前記他のキャッシュ装置がキャッシュしている前記原本データよりも前記原本データ管理装置における更新日時が新しい原本データにより、前記他のキャッシュ装置がキャッシュしている原本データを更新する、
ことを特徴とする請求項３に記載のキャッシュシステム。
【請求項５】
前記転送部は、自キャッシュ装置がキャッシュしている前記原本データを記憶する転送データ記憶部をさらに備え、
前記情報転送処理部は、前記原本データ管理装置から読み出した前記原本データを前記転送データ記憶部に書き込み、
前記参照部は、
自キャッシュ装置がキャッシュしている前記原本データを記憶する参照データ記憶部と、
前記転送データ記憶部から読み出した前記原本データを前記参照データ記憶部に書き込む系内同期処理部と、
受信した前記データアクセス要求に応じて前記参照データ記憶部に記憶している前記原本データへのアクセス処理を行う参照データアクセス部とを備える、
ことを特徴とする請求項１から請求項４のいずれかの項に記載のキャッシュシステム。
【請求項６】
原本データをキャッシュする複数のキャッシュ装置と、受信信号を複数の前記キャッシュ装置のいずれに振り分けるかを管理するアクセス振分装置とを備えるキャッシュシステムに用いられるキャッシュアクセス方法であって、
複数の前記キャッシュ装置それぞれは、
前記アクセス振分装置から振り分けられたデータアクセス要求を受信し、受信したデータアクセス要求に応じて自キャッシュ装置がキャッシュしている原本データへのアクセス処理を行う参照部と、
原本データ管理装置から原本データを読み出して自キャッシュ装置がキャッシュしている前記原本データを更新する転送部とを備えており、
前記アクセス振分装置において、
サービスチェック部が、アクト状態の複数の前記キャッシュ装置の前記参照部及び前記転送部それぞれの運用状態を取得する状態取得過程と、
運用系判断処理部が、前記状態取得過程において取得した複数の前記キャッシュ装置の前記参照部及び前記転送部の運用状態に基づいて、複数の前記キャッシュ装置の中から受信信号の振分先となる前記キャッシュ装置を判定する運用系判断処理過程と、
を有することを特徴とするキャッシュアクセス方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【公開番号】特開２０１１−１６４９１９（Ｐ２０１１−１６４９１９Ａ）
【公開日】平成２３年８月２５日（２０１１．８．２５）
【国際特許分類】
【出願番号】特願２０１０−２６７５９（Ｐ２０１０−２６７５９）
【出願日】平成２２年２月９日（２０１０．２．９）
【出願人】（３９７０６５４８０）エヌ・ティ・ティ・コムウェア株式会社 (187)
【Ｆターム（参考）】
【公開日】平成２３年８月２５日（２０１１．８．２５）
【国際特許分類】
【出願日】平成２２年２月９日（２０１０．２．９）
【出願人】（３９７０６５４８０）エヌ・ティ・ティ・コムウェア株式会社 (187)
【Ｆターム（参考）】
[ Back to top ]