(57)【要約】【課題】  サーバに過負荷や異常が発生した場合に、サーバ業務の継続を、サーバ側からアクションを起こすことなく、かつ簡単な構成で実現する。【解決手段】  顧客端末１０からの処理要求を処理する受付業務サーバ２０の状態を監視サーバ４０で監視し判定する。監視サーバ４０は処理要求を顧客端末１０から受信して記憶部に格納する。監視サーバ４０は、受付業務サーバ２０が正常であると判定した場合は処理要求を受付業務サーバ２０へ送信し、過負荷であるか障害の兆候があると判定した場合は処理要求の一部を共同サーバ３０へ委託し、障害が発生していると判定した場合は処理要求を共同サーバ３０へ委託する。【選択図】      図１
2005234755.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して相互に接続された、顧客端末と、前記顧客端末からの処理要求を処理する受付業務サーバと、共同サーバと、監視サーバとを備え、
前記監視サーバは、前記受付業務サーバの状態を判定する状態監視部と、前記処理要求を前記顧客端末から受信して格納する記憶部と、前記状態監視部が判定した前記受付業務サーバの状態に対応して前記処理要求を前記記憶部から読み出して振り分けるアクセス振り分け部とを有し、
前記アクセス振り分け部は、前記状態監視部が前記受付業務サーバが正常であると判定した場合は前記処理要求を前記受付業務サーバへ送信し、正常でないと判定した場合は前記処理要求の少なくとも一部を前記共同サーバへ委託することを特徴とするサーバ業務継続システム。
【請求項２】
ネットワークを介して相互に接続された、顧客端末と、前記顧客端末からの処理要求を処理する受付業務サーバと、共同サーバと、監視サーバとを備え、
前記監視サーバは、前記受付業務サーバの状態を判定する状態監視部と、前記処理要求を前記顧客端末から受信して格納する記憶部と、前記状態監視部が判定した前記受付業務サーバの状態に対応して前記処理要求を前記記憶部から読み出して振り分けるアクセス振り分け部とを有し、
前記アクセス振り分け部は、前記状態監視部が前記受付業務サーバが正常であると判定した場合は前記処理要求を前記受付業務サーバへ送信し、過負荷であるか障害の兆候があると判定した場合は前記処理要求の少なくとも一部を前記共同サーバへ委託し、障害が発生していると判定したときは前記処理要求を前記共同サーバへ委託することを特徴とするサーバ業務継続システム。
【請求項３】
前記状態監視部は、前記受付業務サーバのＣＰＵ、メモリ、ネットワークのいずれかが一定のしきい値を超えた場合は、前記受付業務サーバが過負荷であるか障害の兆候があると判定することを特徴とする請求項２記載のサーバ業務継続システム。
【請求項４】
前記記憶部は、前記処理要求に対する前記受付業務サーバの処理結果を前記受付業務サーバから受信して格納し、
前記状態監視部は、前記処理要求に対応する前記処理結果が前記処理要求格納後一定時間経過しても格納されない場合は、前記受付業務サーバが過負荷であるか障害の兆候があると判定することを特徴とする請求項２または３記載のサーバ業務継続システム。
【請求項５】
前記状態監視部が前記受付業務サーバに障害が発生していると判定したときに、前記アクセス振り分け部は前記記憶部を参照して前記受付業務サーバへ送信した前記処理要求のうち対応する前記処理結果が格納されていない前記処理要求を抽出し、抽出した前記処理要求を前記共同サーバへ委託することを特徴とする請求項２、３または４記載のサーバ業務継続システム。
【請求項６】
顧客端末からの処理要求を処理する受付業務サーバの状態を判定するステップと、前記処理要求を前記顧客端末から受信して記憶部に格納するステップと、前記受付業務サーバが正常であると判定した場合は前記処理要求を前記記憶部から読み出して前記受付業務サーバへ送信するステップと、正常でないと判定した場合は前記処理要求の少なくとも一部を前記記憶部から読み出して前記共同サーバへ委託するステップとを備えたことを特徴とするサーバ業務継続方法。
【請求項７】
顧客端末からの処理要求を処理する受付業務サーバの状態を判定するステップと、前記処理要求を前記顧客端末から受信して記憶部に格納するステップと、前記受付業務サーバが正常であると判定した場合は前記処理要求を前記記憶部から読み出して前記受付業務サーバへ送信するステップと、過負荷であるか障害の兆候があると判定した場合は前記処理要求の少なくとも一部を前記記憶部から読み出して前記共同サーバへ委託するステップと、障害が発生していると判定した場合は前記処理要求を前記記憶部から読み出して前記共同サーバへ委託するステップとを備えたことを特徴とするサーバ業務継続方法。
【請求項８】
前記受付業務サーバのＣＰＵ、メモリ、ネットワークのいずれかが一定のしきい値を超えた場合は、場合は前記受付業務サーバが過負荷であるか障害の兆候があると判定するステップを備えたことを特徴とする請求項７記載のサーバ業務継続方法。
【請求項９】
前記処理要求に対する前記受付業務サーバの処理結果を前記受付業務サーバから受信して前記記憶部に格納するステップと、前記処理要求に対応する前記処理結果が前記処理要求格納後一定時間経過しても格納されない場合は前記受付業務サーバが過負荷であるか障害の兆候があると判定するステップとを備えたことを特徴とする請求項７または８記載のサーバ業務継続方法。
【請求項１０】
前記受付業務サーバに障害が発生していると判定したときに前記記憶部を参照して前記受付業務サーバへ送信した前記処理要求のうち対応する前記処理結果が格納されていない前記処理要求を抽出するステップと、抽出した前記処理要求を前記共同サーバへ委託するステップとを備えたことを特徴とする請求項７、８または９記載のサーバ業務継続方法。
【請求項１１】
顧客端末と、前記顧客端末からの処理要求を処理する受付業務サーバと、共同サーバとにネットワークを介して接続された監視サーバであって、
前記受付業務サーバの状態を判定する状態監視部と、前記処理要求を前記顧客端末から受信して格納する記憶部と、前記状態監視部が判定した前記受付業務サーバの状態に対応して前記処理要求を前記記憶部から読み出して振り分けるアクセス振り分け部とを有し、
前記アクセス振り分け部は、前記状態監視部が前記受付業務サーバが正常であると判定した場合は前記処理要求を前記受付業務サーバへ送信し、正常でないと判定した場合は前記処理要求の少なくとも一部を前記共同サーバへ委託することを特徴とする監視サーバ。
【請求項１２】
顧客端末と、前記顧客端末からの処理要求を処理する受付業務サーバと、共同サーバとにネットワークを介して接続された監視サーバであって、
前記受付業務サーバの状態を判定する状態監視部と、前記処理要求を前記顧客端末から受信して格納する記憶部と、前記状態監視部が判定した前記受付業務サーバの状態に対応して前記処理要求を前記記憶部から読み出して振り分けるアクセス振り分け部とを有し、
前記アクセス振り分け部は、前記状態監視部が前記受付業務サーバが正常であると判定した場合は前記処理要求を前記受付業務サーバへ送信し、過負荷であるか障害の兆候があると判定した場合は前記処理要求の少なくとも一部を前記共同サーバへ委託し、障害が発生していると判定したときは前記処理要求を前記共同サーバへ委託することを特徴とする監視サーバ。
【請求項１３】
前記状態監視部は、前記受付業務サーバのＣＰＵ、メモリ、ネットワークのいずれかが一定のしきい値を超えた場合は、前記受付業務サーバが過負荷であるか障害の兆候があると判定することを特徴とする請求項１２記載の監視サーバ。
【請求項１４】
前記記憶部は、前記処理要求に対する前記受付業務サーバの処理結果を前記受付業務サーバから受信して格納し、
前記状態監視部は、前記処理要求に対応する前記処理結果が前記処理要求格納後一定時間経過しても格納されない場合は、前記受付業務サーバが過負荷であるか障害の兆候があると判定することを特徴とする請求項１２または１３記載の監視サーバ。
【請求項１５】
前記状態監視部が前記受付業務サーバに障害が発生していると判定したときに、前記アクセス振り分け部は前記記憶部を参照して前記受付業務サーバへ送信した前記処理要求のうち対応する前記処理結果が格納されていない前記処理要求を抽出し、抽出した前記処理要求を前記共同サーバへ委託することを特徴とする請求項１２、１３または１４記載の監視サーバ。
【請求項１６】
顧客端末からの処理要求を処理する受付業務サーバの状態を判定する処理と、前記処理要求を前記顧客端末から受信して記憶部に格納する処理と、前記受付業務サーバが正常であると判定した場合は前記処理要求を前記記憶部から読み出して前記受付業務サーバへ送信する処理と、正常でないと判定した場合は前記処理要求の少なくとも一部を前記記憶部から読み出して前記共同サーバへ委託する処理とをコンピュータに実行させるためのプログラム。
【請求項１７】
顧客端末からの処理要求を処理する受付業務サーバの状態を判定する処理と、前記処理要求を前記顧客端末から受信して記憶部に格納する処理と、前記受付業務サーバが正常であると判定した場合は前記処理要求を前記記憶部から読み出して前記受付業務サーバへ送信する処理と、過負荷であるか障害の兆候があると判定した場合は前記処理要求の少なくとも一部を前記記憶部から読み出して前記共同サーバへ委託する処理と、障害が発生していると判定した場合は前記処理要求を前記記憶部から読み出して前記共同サーバへ委託する処理とをコンピュータに実行させるためのプログラム。
【請求項１８】
、前記受付業務サーバのＣＰＵ、メモリ、ネットワークのいずれかが一定のしきい値を超えた場合は前記受付業務サーバが過負荷であるか障害の兆候があると判定する処理をコンピュータに実行させるための請求項１７記載のプログラム。
【請求項１９】
前記処理要求に対する前記受付業務サーバの処理結果を前記受付業務サーバから受信して前記記憶部に格納する処理と、前記処理要求に対応する前記処理結果が前記処理要求格納後一定時間経過しても格納されない場合は前記受付業務サーバが過負荷であるか障害の兆候があると判定する処理とをコンピュータに実行させるための請求項１７または１８記載のプログラム。
【請求項２０】
前記受付業務サーバに障害が発生していると判定したときに前記記憶部を参照して前記受付業務サーバへ送信した前記処理要求のうち対応する前記処理結果が格納されていない前記処理要求を抽出する処理と、抽出した前記処理要求を前記共同サーバへ委託する処理とをコンピュータに実行させるための請求項１７、１８または１９記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はサーバ業務継続システム、サーバ業務継続方法、監視サーバおよびプログラムに関し、特に、サーバ業務継続システム、サーバ業務継続方法、監視サーバおよびプログラムに関する。
【背景技術】
【０００２】
通常、インターネットショッピングにおいて顧客端末はある販売店のサイトにアクセスを行い、商品の注文を行っている。だが、販売店側の受け付け処理を行うサーバに予想以上のアクセス数により大きな負荷がかかり、受け付け処理がスムーズに行えず顧客はアクセスのやり直しを強いられることがある。あるいは、障害の予兆が発生した場合にはサーバがダウンしてしまう等の現象が起こってしまい、顧客は時間をおいた後に再度アクセスするなどしなければならなくなる。顧客は快適にインターネットショッピングを行えているとはまだいえないのが実情である。このようなミッションクリティカルなシステムでは業務の継続性は顧客満足上大きな鍵を握るものである。
【０００３】
サーバの障害時にバックアップする方式が特許文献１に開示されている。特許文献１によれば、各営業店サーバの持つ制御情報と紹介データを非障害時にセンタ側サーバに集約しておき、さらに営業店サーバの業務を代替する専用の業務代行サーバを別に通信網上に配置しておく。さらに、営業店サーバの障害時に制御情報のみを上記業務代替サーバへロードすることにより、バックアップ・システム起動までの切り替え時間の短縮を図る。
【０００４】
【特許文献１】特開２０００−８２０４０号公報（第４−７頁、図１、図２）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上述したように、従来のサーバシステムは、過負荷や障害により顧客に不便を強いることがあった。この問題点は、インターネットショッピングに限らず、たとえば病院の診察受付処理、映像配信、音楽配信、インターネットバンキング等のサーバにおいても同じである。
【０００６】
特許文献１に開示された方式の場合も、サーバに異常が発生した場合にサーバ側でアクションを起こす必要があるという問題点がある。
【０００７】
本発明の目的は、サーバに過負荷や異常が発生した場合に、サーバ業務の継続を、サーバ側からアクションを起こすことなく、かつ簡単な構成で実現する、サーバ業務継続システム、サーバ業務継続方法、監視サーバおよびプログラムを提供することにある。
【課題を解決するための手段】
【０００８】
本発明のサーバ業務継続システムは、ネットワークを介して相互に接続された、顧客端末と、前記顧客端末からの処理要求を処理する受付業務サーバと、共同サーバと、監視サーバとを備え、
前記監視サーバは、前記受付業務サーバの状態を判定する状態監視部と、前記処理要求を前記顧客端末から受信して格納する記憶部と、前記状態監視部が判定した前記受付業務サーバの状態に対応して前記処理要求を前記記憶部から読み出して振り分けるアクセス振り分け部とを有し、
前記アクセス振り分け部は、前記状態監視部が前記受付業務サーバが正常であると判定した場合は前記処理要求を前記受付業務サーバへ送信し、正常でないと判定した場合は前記処理要求の少なくとも一部を前記共同サーバへ委託することを特徴とする。
【０００９】
本発明のサーバ業務継続システムは、ネットワークを介して相互に接続された、顧客端末と、前記顧客端末からの処理要求を処理する受付業務サーバと、共同サーバと、監視サーバとを備え、
前記監視サーバは、前記受付業務サーバの状態を判定する状態監視部と、前記処理要求を前記顧客端末から受信して格納する記憶部と、前記状態監視部が判定した前記受付業務サーバの状態に対応して前記処理要求を前記記憶部から読み出して振り分けるアクセス振り分け部とを有し、
前記アクセス振り分け部は、前記状態監視部が前記受付業務サーバが正常であると判定した場合は前記処理要求を前記受付業務サーバへ送信し、過負荷であるか障害の兆候があると判定した場合は前記処理要求の少なくとも一部を前記共同サーバへ委託し、障害が発生していると判定したときは前記処理要求を前記共同サーバへ委託することを特徴としてもよい。
【００１０】
本発明のサーバ業務継続システムは、前記状態監視部は、前記受付業務サーバのＣＰＵ、メモリ、ネットワークのいずれかが一定のしきい値を超えた場合は、前記受付業務サーバが過負荷であるか障害の兆候があると判定することを特徴としてもよい。
【００１１】
本発明のサーバ業務継続システムは、前記記憶部は、前記処理要求に対する前記受付業務サーバの処理結果を前記受付業務サーバから受信して格納し、
前記状態監視部は、前記処理要求に対応する前記処理結果が前記処理要求格納後一定時間経過しても格納されない場合は、前記受付業務サーバが過負荷であるか障害の兆候があると判定することを特徴としてもよい。
【００１２】
本発明のサーバ業務継続システムは、前記状態監視部が前記受付業務サーバに障害が発生していると判定したときに、前記アクセス振り分け部は前記記憶部を参照して前記受付業務サーバへ送信した前記処理要求のうち対応する前記処理結果が格納されていない前記処理要求を抽出し、抽出した前記処理要求を前記共同サーバへ委託することを特徴としてもよい。
【００１３】
本発明のサーバ業務継続方法は、顧客端末からの処理要求を処理する受付業務サーバの状態を判定するステップと、前記処理要求を前記顧客端末から受信して記憶部に格納するステップと、前記受付業務サーバが正常であると判定した場合は前記処理要求を前記記憶部から読み出して前記受付業務サーバへ送信するステップと、正常でないと判定した場合は前記処理要求の少なくとも一部を前記記憶部から読み出して前記共同サーバへ委託するステップとを備えたことを特徴とする。
【００１４】
本発明のサーバ業務継続方法は、顧客端末からの処理要求を処理する受付業務サーバの状態を判定するステップと、前記処理要求を前記顧客端末から受信して記憶部に格納するステップと、前記受付業務サーバが正常であると判定した場合は前記処理要求を前記記憶部から読み出して前記受付業務サーバへ送信するステップと、過負荷であるか障害の兆候があると判定した場合は前記処理要求の少なくとも一部を前記記憶部から読み出して前記共同サーバへ委託するステップと、障害が発生していると判定した場合は前記処理要求を前記記憶部から読み出して前記共同サーバへ委託するステップとを備えたことを特徴としてもよい。
【００１５】
本発明のサーバ業務継続方法は、前記受付業務サーバのＣＰＵ、メモリ、ネットワークのいずれかが一定のしきい値を超えた場合は、場合は前記受付業務サーバが過負荷であるか障害の兆候があると判定するステップを備えたことを特徴としてもよい。
【００１６】
本発明のサーバ業務継続方法は、前記処理要求に対する前記受付業務サーバの処理結果を前記受付業務サーバから受信して前記記憶部に格納するステップと、前記処理要求に対応する前記処理結果が前記処理要求格納後一定時間経過しても格納されない場合は前記受付業務サーバが過負荷であるか障害の兆候があると判定するステップとを備えたことを特徴としてもよい。
【００１７】
本発明のサーバ業務継続方法は、前記受付業務サーバに障害が発生していると判定したときに前記記憶部を参照して前記受付業務サーバへ送信した前記処理要求のうち対応する前記処理結果が格納されていない前記処理要求を抽出するステップと、抽出した前記処理要求を前記共同サーバへ委託するステップとを備えたことを特徴としてもよい。
【００１８】
本発明の監視サーバは、顧客端末と、前記顧客端末からの処理要求を処理する受付業務サーバと、共同サーバとにネットワークを介して接続された監視サーバであって、
前記受付業務サーバの状態を判定する状態監視部と、前記処理要求を前記顧客端末から受信して格納する記憶部と、前記状態監視部が判定した前記受付業務サーバの状態に対応して前記処理要求を前記記憶部から読み出して振り分けるアクセス振り分け部とを有し、
前記アクセス振り分け部は、前記状態監視部が前記受付業務サーバが正常であると判定した場合は前記処理要求を前記受付業務サーバへ送信し、正常でないと判定した場合は前記処理要求の少なくとも一部を前記共同サーバへ委託することを特徴とする。
【００１９】
本発明の監視サーバは、顧客端末と、前記顧客端末からの処理要求を処理する受付業務サーバと、共同サーバとにネットワークを介して接続された監視サーバであって、
前記受付業務サーバの状態を判定する状態監視部と、前記処理要求を前記顧客端末から受信して格納する記憶部と、前記状態監視部が判定した前記受付業務サーバの状態に対応して前記処理要求を前記記憶部から読み出して振り分けるアクセス振り分け部とを有し、
前記アクセス振り分け部は、前記状態監視部が前記受付業務サーバが正常であると判定した場合は前記処理要求を前記受付業務サーバへ送信し、過負荷であるか障害の兆候があると判定した場合は前記処理要求の少なくとも一部を前記共同サーバへ委託し、障害が発生していると判定したときは前記処理要求を前記共同サーバへ委託することを特徴としてもよい。
【００２０】
本発明の監視サーバは、前記状態監視部は、前記受付業務サーバのＣＰＵ、メモリ、ネットワークのいずれかが一定のしきい値を超えた場合は、前記受付業務サーバが過負荷であるか障害の兆候があると判定することを特徴としてもよい。
【００２１】
本発明の監視サーバは、前記記憶部は、前記処理要求に対する前記受付業務サーバの処理結果を前記受付業務サーバから受信して格納し、
前記状態監視部は、前記処理要求に対応する前記処理結果が前記処理要求格納後一定時間経過しても格納されない場合は、前記受付業務サーバが過負荷であるか障害の兆候があると判定することを特徴としてもよい。
【００２２】
本発明の監視サーバは、前記状態監視部が前記受付業務サーバに障害が発生していると判定したときに、前記アクセス振り分け部は前記記憶部を参照して前記受付業務サーバへ送信した前記処理要求のうち対応する前記処理結果が格納されていない前記処理要求を抽出し、抽出した前記処理要求を前記共同サーバへ委託することを特徴としてもよい。
【００２３】
本発明のプログラムは、顧客端末からの処理要求を処理する受付業務サーバの状態を判定する処理と、前記処理要求を前記顧客端末から受信して記憶部に格納する処理と、前記受付業務サーバが正常であると判定した場合は前記処理要求を前記記憶部から読み出して前記受付業務サーバへ送信する処理と、正常でないと判定した場合は前記処理要求の少なくとも一部を前記記憶部から読み出して前記共同サーバへ委託する処理とをコンピュータに実行させる。
【００２４】
本発明のプログラムは、顧客端末からの処理要求を処理する受付業務サーバの状態を判定する処理と、前記処理要求を前記顧客端末から受信して記憶部に格納する処理と、前記受付業務サーバが正常であると判定した場合は前記処理要求を前記記憶部から読み出して前記受付業務サーバへ送信する処理と、過負荷であるか障害の兆候があると判定した場合は前記処理要求の少なくとも一部を前記記憶部から読み出して前記共同サーバへ委託する処理と、障害が発生していると判定した場合は前記処理要求を前記記憶部から読み出して前記共同サーバへ委託する処理とをコンピュータに実行させるようにしてもよい。。
【００２５】
本発明のプログラムは、前記受付業務サーバのＣＰＵ、メモリ、ネットワークのいずれかが一定のしきい値を超えた場合は前記受付業務サーバが過負荷であるか障害の兆候があると判定する処理をコンピュータに実行させるようにしてもよい。
【００２６】
本発明のプログラムは、前記処理要求に対する前記受付業務サーバの処理結果を前記受付業務サーバから受信して前記記憶部に格納する処理と、前記処理要求に対応する前記処理結果が前記処理要求格納後一定時間経過しても格納されない場合は前記受付業務サーバが過負荷であるか障害の兆候があると判定する処理とをコンピュータに実行させるようにしてもよい。
【００２７】
本発明のプログラムは、前記受付業務サーバに障害が発生していると判定したときに前記記憶部を参照して前記受付業務サーバへ送信した前記処理要求のうち対応する前記処理結果が格納されていない前記処理要求を抽出する処理と、抽出した前記処理要求を前記共同サーバへ委託する処理とをコンピュータに実行させるようにしてもよい。
【発明の効果】
【００２８】
本発明によれば以下の効果が期待できる。
【００２９】
受付業務サーバが過負荷になったり障害を発生した場合にも、受付業務サーバを管理する販売店サイトからアクションを起こすことなく業務を継続することが可能になる。顧客端末から再度アクセスをかけなくとも自動的にアクセスパスが切り替わり１度中断された処理要求が再開されるので顧客は待たされることなくインターネットショッピング等を続けることができる。
【発明を実施するための最良の形態】
【００３０】
本発明を実施するための最良の形態について図面を参照して詳細に説明する。図１は本発明の実施の形態の構成を示すブロック図である。顧客端末１０、受付業務サーバ２０、共同サーバ３０、監視サーバ４０がネットワークを介して接続されている。ネットワークはインターネット１００であるとして説明する。一般的な形態としては、顧客端末１０と受付業務サーバ２０と共同サーバ３０はそれぞれ複数台である。
【００３１】
顧客端末１０は、パーソナルコンピュータや携帯電話等の情報処理装置である。図示しないが、データを入力するための入力部とデータを画面表示するための表示部とデータを一時格納するための記憶部とを有する。顧客１は顧客端末１０を使用して各々の販売店サイト２の受付業務サーバ２０にアクセスし、品物の注文等をする際に端末情報・顧客情報・希望商品情報等を受付業務サーバ２０に送信し、処理の依頼を行う。
【００３２】
受付業務サーバ２０は、インターネット１００上で販売店サイト２を運営する業者が使用する情報処理装置であり、顧客端末１０からの品物の受注を受け付ける処理を行う。受付業務サーバ２０は、図示しないが、必要に応じて、データを入力するための入力部とデータを画面表示するための表示部とデータを一時格納するための記憶部とを有する。
【００３３】
共同サーバ３０は、受付業務サーバ２０の負荷が高くなったり、または受付業務サーバ２０に障害が発生した場合に、受付業務サーバ２０の品物の受注を受け付ける業務を一部または全て引き受ける。共同サーバ３０には各販売店サイト２の注文受付システムが入っておりどの販売店サイト２にある受付業務サーバ２０に異常が発生した場合でも業務を共同サーバ３０に委託することが可能である。
【００３４】
監視サーバ４０は、各々の販売店サイト２内の受付業務サーバ２０の状態を監視する。状態とは負荷、障害予兆等である。図２は監視サーバ４０の構成を示すブロック図である。監視サーバ４０は、状態監視部４１、記憶部４２、アクセス振り分け部４３を有する。
【００３５】
状態監視部４１は受付業務サーバ２０のＣＰＵ（central processing unit）、メモリ、ネットワーク等のパフォーマンスの監視を常時行い、受付業務サーバ２０の状態の判定を行う。
【００３６】
記憶部４２は、アクセスログデータベース４５を格納する。図３はアクセスログデータベース４５の一例を示す図である。アクセスログデータベース４５は、処理要求データベース４６と処理結果データベース４７を含む。処理要求データベース４６は、顧客１が品物を注文した際に顧客端末１０から送信される注文情報を含む。処理要求データベース４６は、フラグ部４６１、顧客情報４６２、端末情報４６３、要求された処理４６４、処理要求先４６５を含む。顧客情報４６２は、たとえば顧客１の氏名、住所、電子メールアドレスである。端末情報は、たとえば顧客端末１０のＩＰ（internet protocol）アドレスである。要求された処理４６４は、たとえば顧客１が注文した商品の商品コード、個数である。処理結果データベース４７は、受付業務サーバ２０で処理された注文受付業務の処理結果の情報を記録する。処理結果データベース４７は、顧客情報４７１、端末情報４７２、処理した要求４７３を含む。
【００３７】
アクセス振り分け部４３は、状態監視部４１から出力された受付業務サーバ２０の状態判定の結果により、顧客端末１０から依頼された注文受付業務を受付業務サーバ２０もしくは共同サーバ３０に振り分ける。またアクセス振り分け部４３は、アクセスログデータベース４５内の処理要求データベース４６内の「要求された処理」と処理結果データベース４７内の「処理した要求」を比較し、注文受付の処理が完了した「要求された処理」にフラグを立てる。
【００３８】
次に、動作について説明する。図４は通常時の動作を示すフローチャートである。
【００３９】
監視サーバ４０の状態監視部４１は、インターネット１００上に接続され、自サーバが監視対象とする受付業務サーバ２０のＣＰＵ・メモリ・ネットワーク等のパフォーマンスの監視を常時行っている（ステップＡ１）。
【００４０】
顧客１は顧客端末１０から販売店サイト２の受付業務サーバ２０にアクセスし、欲しい品物をインターネット１００経由で注文する（ステップＡ２）。このとき、顧客端末１０は受付業務サーバ２０に直接アクセスするのではなく、まず監視サーバ４０がその窓口となっている。監視サーバ４０は、顧客端末１０から送られてくる端末情報・顧客情報・購入を希望する商品の情報などをアクセスログデータベース４５の処理要求データベース４６に一旦書き込みを行ってから（ステップＡ３）、処理要求対象先の受付業務サーバ２０に対してアクセス要求や処理要求を出す。
【００４１】
監視サーバ４０の状態監視部４１は、受付業務サーバ２０の状態を判定し（ステップＡ４）、その結果により状態を以下のように決定し保持する。図５は状態監視部４１が受付業務サーバ２０の状態を判定する動作を示すフローチャートである。
【００４２】
状態監視部４１は、受付業務サーバ２０が障害を起こしているかを判定する（ステップＢ１）。ステップＢ１でＹｅｓの場合は状態監視部４１は、受付業務サーバ２０の状態をｓｔａｔ３（受付業務サーバ２０は障害を起こしている）と決定し、保持する。
【００４３】
ステップＢ１でＮｏの場合、状態監視部４１は、受付業務サーバ２０がＣＰＵ、メモリ、ネットワーク等である一定のしきい値を超えるような異常を見せているかを判定する（ステップＢ２）。ステップＢ２でＹｅｓの場合は状態監視部４１は受付業務サーバ２０の状態をｓｔａｔ２（過負荷がかかっているか、障害の兆候があるため、負荷分散）と決定し、保持する。
【００４４】
ステップＢ２でＮｏの場合、状態監視部４１は、フラグが一定時間以上経過してもたたないかを判断する（ステップＢ３）。ステップＢ３でＹｅｓの場合は状態監視部４１は受付業務サーバ２０の状態をｓｔａｔ２（過負荷がかかっているか、障害の兆候があるため、負荷分散）と決定し、保持する。
【００４５】
ステップＢ３でＮｏの場合、状態監視部４１は受付業務サーバ２０の状態をｓｔａｔ３（受付業務サーバ２０の状態は正常である）と決定し、保持する。
【００４６】
一度ｓｔａｔ２、ｓｔａｔ３に保持された場合でも、受付業務サーバ２０の負荷が少なくなる、または受付業務サーバ２０の保守を行うなどしてパフォーマンスが改善された場合には、状態監視部４１は再度ｓｔａｔ１に戻す。
【００４７】
処理要求先の受付業務サーバ２０の状態がｓｔａｔ１と判断されている場合は、アクセス振り分け部４３は顧客端末１０からのアクセス要求や処理要求を処理要求先の受付業務サーバ２０に送る（ステップＡ５）。受付業務サーバ２０はその処理を行う。
【００４８】
受付業務サーバ２０はジョブの処理が完了すると（ステップＡ６）、処理結果を監視サーバ４０に回答する（ステップＡ７）。
【００４９】
顧客端末１０からのアクセスが多くなるなどして受付業務サーバ２０の状態に異常がみられると、状態監視部４１はｓｔａｔ２またはｓｔａｔ３の状態と判断する。ｓｔａｔ２またはｓｔａｔ３の場合、アクセス振り分け部４３は顧客端末１０からのアクセス要求や処理要求のパスを受付業務サーバ２０からインターネット１００上にある共同サーバ３０に変更する（ステップＡ８）。ｓｔａｔ２の場合は、アクセス振り分け部４３は処理要求の全てではなく一部を共同サーバ３０に振り分けて負荷分散を図るようにしてもよい。共同サーバ３０は振り分けられた処理要求の処理を行う。
【００５０】
共同サーバ３０はジョブの処理が完了すると（ステップＡ９）、処理結果を監視サーバ４０に回答する（ステップＡ１０）。
【００５１】
監視サーバ４０は、受付業務サーバ２０または共同サーバ３０から送信された処理結果をアクセスログデータベース４５の処理結果データベース４７に書き込む（ステップＡ１１）。
【００５２】
アクセス振り分け部４３は、処理結果データベース４７に書き込まれた「処理した要求」を処理要求データベース４６内にある対応する「要求された処理」と比較する。アクセス振り分け部４３は、受け付けた処理要求の完了が確認できたらその処理要求のフラグ部（図３の４６１）にフラグを立てる（ステップＡ１２）。フラグ部（図３の４６１）は「１：処理完了」、「０：処理未完了」を示す。
【００５３】
その後、監視サーバ４０は処理結果を顧客端末１０に返す（ステップＡ１３）。
【００５４】
図６は、監視サーバ４０が受付業務サーバ２０に注文受付業務の処理要求を出した後に、監視サーバ４０が障害を検出した場合の動作を示すフローチャートである。ステップＣ１からＣ５までは、図４のステップＡ１からＡ５までと同じである。
【００５５】
受付業務サーバ２０に障害が発生した場合は（ステップＣ６）、状態監視部４１が障害と判定する（ステップＣ７）。
【００５６】
この判定に基づいて、アクセス振り分け部４３が処理要求のパスを受付業務サーバ２０から任意の共同サーバ３０に変更する。同時にアクセス振り分け部４３はアクセスログデータベース４５を検索して、障害を起こした受付業務サーバ２０に対応する処理要求の内、フラグの立てられていない処理要求を読み出す。読み出した処理要求を変更先の共同サーバ３０に出す（ステップＣ８）。
【００５７】
その後のステップＣ９からステップＣ１３までは、図４のステップＡ９からＡ１３までと同じである。
【００５８】
受付業務サーバ２０の障害発生時でも監視サーバ４０側にアクセスログがあるので、処理要求を停止せず継続することができる。これにより、顧客１が受付業務サーバ２０の障害を認識することなく継続して処理が行われることになる。
【００５９】
本発明の実施の形態の状態監視部４１、アクセス振り分け部４３の動作はコンピュータ・プログラム処理により行わせることが可能である。すなわち、記録媒体に記録したプログラムを監視サーバ４０に読み込ませるか、あるいは、ネットワークからプログラムを監視サーバ４０に読み込ませて、実施の形態で説明した動作を実行させる。
【００６０】
上述した実施の形態ではインターネットショッピングの例を説明したが、本発明はこれに限定されるものではない。本発明は、たとえば病院の診察受付処理、映像配信、音楽配信、インターネットバンキング等、受付業務を行う場合に適用できる。
【図面の簡単な説明】
【００６１】
【図１】本発明の実施の形態の構成を示すブロック図である。
【図２】監視サーバの構成を示すブロック図である。
【図３】アクセスログデータベース
【図４】通常時の動作を示すフローチャートである。
【図５】状態監視部が受付業務サーバの状態を判定する動作を示すフローチャートである。
【図６】処理要求後に障害を検出した場合の動作を示すフローチャートである。
【符号の説明】
【００６２】
２    販売店サイト
１０    顧客端末
２０    受付業務サーバ
３０    共同サーバ
４０    監視サーバ
４１    状態監視部
４２    記憶部
４３    アクセス振り分け部
４５    アクセスログデータベース
４６    処理要求データベース
４７    処理結果データベース
【図１】
2005234755.tif 000003
【図２】
2005234755.tif 000004
【図３】
2005234755.tif 000005
【図４】
2005234755.tif 000006
【図５】
2005234755.tif 000007
【図６】
2005234755.tif 000008