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