"ユーザ端末からの要求を受け付ける要求受付手段と、当該要求に基づいて複数のバックエンドサーバに処理を実行させて、その結果を前記ユーザ端末に提供するインタプリタ型プログラムを実行するプログラム実行手段とを備えるフロントエンドサーバであって、前記要求に基づいて前記バックエンドサーバに実行させる処理のうち、所定の例外処理条件に応じて指定された所定の処理を記述する前記インタプリタ型プログラムの該当部分の文字列を、例外処理を記述する文字列に書き換えるプログラム書換手段、を備え、前記プログラム実行手段は、文字列判定により、前記要求に基づいてバックエンドサーバに実行させる処理が前記プログラム書換手段が書き換えた所定の処理であるか否かを判定し、当該書き換えた所定の処理である場合に、当該処理を実行する当該バックエンドサーバにアクセスすることなく前記プログラム書換手段が書き換えた文字列により記述された例外処理を実行して、当該例外処理の結果を前記ユーザ端末に通知する、フロントエンドサーバ。管理者端末と通信可能に接続され、前記所定の例外処理条件は、前記管理者端末を用いた管理者からの要求に基づいて設定される、請求項1に記載のフロントエンドサーバ。前記バックエンドサーバのネットワークの到達性を監視する監視サーバと通信可能に接続され、前記所定の例外処理条件は、前記監視サーバからの要求に基づいて設定される、請求項1又は2に記載のフロントエンドサーバ。ユーザ端末からの要求に基づいて複数のバックエンドサーバに処理を実行させて、その結果を前記ユーザ端末に提供するフロントエンドサーバに、前記要求に基づいて前記バックエンドサーバに実行させる処理のうち、所定の例外処理条件に応じて指定された所定の処理を記述する該当部分の文字列を、例外処理を記述する文字列に書き換えるプログラム書換ステップと、文字列判定により、前記要求に基づいてバックエンドサーバに実行させる処理が前記プログラム書換ステップで書き換えた例外処理であるか否かを判定し、例外処理である場合に、前記要求に基づく処理を実行する前記バックエンドサーバにアクセスすることなく前記プログラム書換ステップで書き換えた文字列により記述された例外処理を実行して、当該例外処理の結果を前記ユーザ端末に通知する処理実行ステップと、を実行させるインタプリタ型プログラム。ユーザ端末からの要求に基づいて複数のバックエンドサーバに処理を実行させて、その結果を前記ユーザ端末に提供するインタプリタ型プログラムを実行するフロントエンドサーバの実行する方法であって、前記要求に基づいて前記バックエンドサーバに実行させる処理のうち、所定の例外処理条件に応じて指定された所定の処理を記述する該当部分の文字列を、例外処理を記述する文字列に書き換えるプログラム書換ステップと、文字列判定により、前記要求に基づいてバックエンドサーバに実行させる処理が前記プログラム書換ステップで書き換えた例外処理であるか否かを判定し、例外処理である場合に、前記要求に基づく処理を実行する前記バックエンドサーバにアクセスすることなく前記プログラム書換ステップで書き換えた文字列により記述された例外処理を実行して、当該例外処理の結果を前記ユーザ端末に通知する処理実行ステップと、を含む方法。ところで、サーバ障害時やメンテナンス時には、一定のサービスを停止しなければならず、ユーザは、その間当該サービスを受けることができなかった。そのため、サーバ障害時やメンテナンス時にユーザへの影響を軽減することのできるWebサーバシステムの構築が求められている。本発明は、このような要求に応じてなされたものであり、サーバ障害時やメンテナンス時にユーザへの影響を軽減可能なフロントエンドサーバ、インタプリタ型プログラム及び方法を提供することを目的とする。1ユーザ端末からの要求を受け付ける要求受付手段と、当該要求に基づいて複数のバックエンドサーバに処理を実行させて、その結果を前記ユーザ端末に提供するインタプリタ型プログラムを実行するプログラム実行手段とを備えるフロントエンドサーバであって、前記要求に基づいて前記バックエンドサーバに実行させる処理のうち、所定の例外処理条件に応じて指定された所定の処理を記述する前記インタプリタ型プログラムの該当部分の文字列を、例外処理を記述する文字列に書き換えるプログラム書換手段と、を備え、前記プログラム実行手段は、文字列判定により、前記要求に基づいてバックエンドサーバに実行させる処理が前記プログラム書換手段が書き換えた所定の処理であるか否かを判定し、当該書き換えた所定の処理である場合に、当該処理を実行する当該バックエンドサーバにアクセスすることなく前記プログラム書換手段が書き換えた文字列により記述された例外処理を実行して、当該例外処理の結果を前記ユーザ端末に通知するフロントエンドサーバ。1記載のフロントエンドサーバによれば、バックエンドサーバに実行させる処理のうち、例外処理条件に応じて指定された所定の処理は、例外処理に書き換えられる。そして、ユーザ端末から受け付けた要求に基づきバックエンドサーバに実行させる処理がプログラム書換手段により書き換えられた所定の処理であると判定されると、バックエンドサーバにアクセスすることなく、当該例外処理の結果を通知する。これにより、サーバ障害時やメンテナンス時にユーザへの影響を軽減することができる。例えば、ブログの更新及び閲覧を管理するバックエンドサーバにおいて、ブログの更新のみが実行困難例外処理条件である場合には、ブログの更新に関する処理を所定の処理として記述しておくことで、ユーザ端末からブログの更新要求がなされた場合に限り、例外処理を行い、ブログの閲覧要求がなされた場合には、適切な処理を行うことができる。このとき、1記載のフロントエンドサーバでは、文字列判定で例外処理を実行するか否かを判定するため、Webサーバシステムの管理者は、例外処理を行うべき所定の処理を容易に判別することができる。2管理者端末と通信可能に接続され、前記所定の例外処理条件は、前記管理者端末を用いた管理者からの要求に基づいて設定される、1に記載のフロントエンドサーバ。2記載のフロントエンドサーバによれば、Webサーバシステムの管理者は、例外処理条件書換対象処理名バックエンドサーバ名を適切に管理することができる。3前記バックエンドサーバのネットワークの到達性を監視する監視サーバと通信可能に接続され、前記所定の例外処理条件は、前記監視サーバからの要求に基づいて設定される、1又は2に記載のフロントエンドサーバ。3記載のフロントエンドサーバによれば、例外処理条件書換対象処理名バックエンドサーバ名を、監視サーバからの要求に基づいて設定、すなわち、例外処理条件を自動的に設定するため、例外処理条件を適切に管理することができる。4ユーザ端末からの要求に基づいて複数のバックエンドサーバに処理を実行させて、その結果を前記ユーザ端末に提供するフロントエンドサーバに、前記要求に基づいて前記バックエンドサーバに実行させる処理のうち、所定の例外処理条件に応じて指定された所定の処理を記述する該当部分の文字列を、例外処理を記述する文字列に書き換えるプログラム書換ステップと、文字列判定により、前記要求に基づいてバックエンドサーバに実行させる処理が前記プログラム書換ステップで書き換えた例外処理であるか否かを判定し、例外処理である場合に、前記要求に基づく処理を実行する前記バックエンドサーバにアクセスすることなく前記プログラム書換ステップで書き換えた文字列により記述された例外処理を実行して、当該例外処理の結果を前記ユーザ端末に通知する処理実行ステップと、を実行させるインタプリタ型プログラム。5ユーザ端末からの要求に基づいて複数のバックエンドサーバに処理を実行させて、その結果を前記ユーザ端末に提供するインタプリタ型プログラムを実行するフロントエンドサーバの実行する方法であって、前記要求に基づいて前記バックエンドサーバに実行させる処理のうち、所定の例外処理条件に応じて指定された所定の処理を記述する該当部分の文字列を、例外処理を記述する文字列に書き換えるプログラム書換ステップと、文字列判定により、前記要求に基づいてバックエンドサーバに実行させる処理が前記プログラム書換ステップで書き換えた例外処理であるか否かを判定し、例外処理である場合に、前記要求に基づく処理を実行する前記バックエンドサーバにアクセスすることなく前記プログラム書換ステップで書き換えた文字列により記述された例外処理を実行して、当該例外処理の結果を前記ユーザ端末に通知する処理実行ステップと、を含む方法。4記載のインタプリタ型プログラム又は5記載の方法によれば、1記載のフロントエンドサーバと同様の効果を奏する。本発明によれば、サーバ障害時やメンテナンス時にユーザへの影響を軽減することができる。以下、本発明の実施形態について図面を参照して説明する。[Webサーバシステム1]初めに、図1~図3を参照して、本実施形態のWebサーバシステム1について説明する。図1は、Webサーバシステム1の概要を示す図であり、図2は、Webサーバシステム1の機能ブロック図を示す図であり、図3は、本発明の例外処理プログラム23の一例を示す図である。Webサーバシステム1は、所定のネットワークにより互いに通信可能に接続された、フロントエンドサーバ2と、バックエンドサーバ3A3Z以下、区別しない場合はバックエンドサーバ3とすると、監視サーバ4と、管理者端末5と、を含んで構成される。フロントエンドサーバ2は、ユーザ端末8とインターネット回線により接続され、ユーザ端末8からリクエスト要求を受け付ける。フロントエンドサーバ2は、リクエスト要求を受け付けると、リクエスト要求に応じた処理をバックエンドサーバに実行させ、その処理結果をユーザ端末8に対して返信する。すなわち、フロントエンドサーバ2は、リクエスト要求に基づいて、Webページを構成するデータをバックエンドサーバ3から取得し、ユーザ端末8に対して返信する。なお、リクエスト要求には、ユーザ端末8ユーザのWebサーバシステム1に対する指示例えば、更新指示や閲覧指示などと、ユーザ端末8ユーザを識別する情報と、が含まれる。具体的には、リクエスト要求には、Webサーバシステム1に対する指示としての関数と、ユーザ端末8を識別する情報としてのIPアドレスと、が含まれる。バックエンドサーバ3は、Webサーバシステム1が管理するWebサービス内の各種データを管理するDBデータベースサーバであり、フロントエンドサーバ2からの要求に応じた所定の処理を行い、フロントエンドサーバ2に対して当該処理の結果例えば、閲覧要求のWebページを返信する。監視サーバ4は、複数のバックエンドサーバ3の各々について、ネットワークの到達性を監視する。また、監視サーバ4は、複数のバックエンドサーバ3の各々が管理する各種データが最新のものであるか否かを監視、すなわち、バックエンドサーバ3のデータベースがグローバルデータベースと一致するか否かを監視する。管理者端末5は、Webサーバシステム1の管理者により用いられる端末装置であり、障害発生時などに管理者からの操作を受け付けると、所定のメンテナンスを行う。ここで、本実施形態のWebサーバシステム1では、ユーザ端末8から受け付けたリクエスト要求に対応するバックエンドサーバ3に障害が発生している場合には、フロントエンドサーバ2は、当該バックエンドサーバ3にアクセスすることなく、ユーザ端末8に対して、現在メンテナンス中であることを示すメンテナンス画面などを提供する例外処理。このとき、本実施形態では、障害が発生しているか否かを、監視サーバ4による自動的な通知、及び管理者端末5による手動の通知により行うこととし、当該通知を受けたフロントエンドサーバ2が、後述の例外処理プログラム23に従い、ユーザ端末8から受け付けたリクエスト要求と当該通知との文字列判定を行うことで、例外処理を行うこととしている。以下、図2及び図3を用いて、例外処理の実行の詳細について説明する。[フロントエンドサーバ2の構成]図2を参照して、フロントエンドサーバ2は、要求受付手段21と、プログラム実行手段22と、例外処理プログラム23と、を含んで構成される。要求受付手段21は、ユーザ端末8からリクエスト要求を受け付けるとともに、受け付けたリクエスト要求に基づいて、バックエンドサーバ3に対する処理すなわち、バックエンドサーバ3が実行する処理、及び複数のバックエンドサーバ3のうち当該処理を実行するバックエンドサーバ3以下、実行バックエンドサーバとするの種別を受け付ける。要求受付手段21は、リクエスト要求に含まれる関数指示から、バックエンドサーバ3に対する処理を受け付け、リクエスト要求に含まれるIPアドレスユーザ端末8を識別する情報から、実行バックエンドサーバの種別を受け付ける。ここで、図示は省略するが、Webサーバシステム1は、リクエスト要求に含まれるIPアドレスユーザ端末8を識別する情報から、処理を割り振るバックエンドサーバ3を特定する割振サーバを含むこととしてもよく、要求受付手段21は、この割振サーバにより特定されたバックエンドサーバ3に基づいて、実行バックエンドサーバの種別を受け付けることとしてもよい。プログラム実行手段22は、例外処理プログラム23に従い、ユーザ端末8からのリクエスト要求に基づいて、複数のバックエンドサーバに処理を実行させて、その結果をユーザ端末8に提供する。<例外処理プログラム23>例外処理プログラム23は、インタプリタ型のプログラム例えば、PHPであり、実行されることで、フロントエンドサーバ2に要求処理判定手段231、サーバ判定手段232、プログラム書換手段233及び処理実行手段234の機能を実現させるとともに、書換対象処理記述部235と、障害サーバ記述部236と、例外処理記述部237と、を含む。要求処理判定手段231は、要求受付手段21が受け付けたバックエンドサーバ3に対する処理が、予め定められた書換対象の処理であるか否かを判定する。ここで、書換対象処理記述部235は、予め定められた書換対象の処理を記述する。そのため、要求処理判定手段231は、書換対象処理記述部235の記述に基づいて、要求受付手段21が受け付けたバックエンドサーバ3に対する処理が書換対象の処理であるか否かを判定する。このとき、本実施形態では、書換対象処理記述部235は、予め定められた書換対象の処理関数名を文字列で記述し、要求処理判定手段231は、要求受付手段21が受け付けた処理関数が、書換対象の関数名を記述した当該文字列と一致するか否かを文字列判定する。なお、本実施形態における、文字列とは、人間が判別することのできるものをいい、人間が判別不可能なバイナリコードを含まない。サーバ判定手段232は、要求受付手段21が受け付けた実行バックエンドサーバが、少なくとも一部の処理の実行が困難として予め定められたバックエンドサーバ3であるか否かを判定する。ここで、障害サーバ記述部236は、少なくとも一部の処理の実行が困難として予め定められたバックエンドサーバ3以下、障害バックエンドサーバとするの種別を記述する。そのため、サーバ判定手段232は、障害サーバ記述部236の記述に基づいて、要求受付手段21が受け付けた実行バックエンドサーバが、障害バックエンドサーバであるか否かを判定する。このとき、本実施形態では、障害サーバ記述部236は、障害バックエンドサーバサーバ名を文字列で記述し、サーバ判定手段232は、要求受付手段21が受け付けた実行バックエンドサーバサーバ名が、障害バックエンドサーバを記述した当該文字列と一致するか否かを文字列判定する。プログラム書換手段233は、要求受付手段21が受け付けた処理が要求処理判定手段231により書換対象の処理であると判定され、かつ、要求受付手段21が受け付けた実行バックエンドサーバが障害バックエンドサーバであると判定されることを条件に、要求受付手段21が受け付けた処理を予め定められた例外処理に書き換える。すなわち、プログラム書換手段233は、バックエンドサーバに実行させる処理のうち、書換対象処理記述部235に記述された書換対象処理を記述する文字列を、例外処理を記述する文字列に書き換える。このとき書き換えられる例外処理は、フロントエンドサーバ2が実行バックエンドサーバにアクセスすることなく行う処理であり、例えば、現在メンテナンス中であることを示すメンテナンス画面をユーザ端末8に対して提供する処理である。ここで、例外処理記述部237は、プログラム書換手段233が書き換える例外処理関数を記述する。そのため、プログラム書換手段233は、例外処理記述部237の記述に基づいて、要求受付手段21が受け付けた処理を例外処理に書き換える。このとき、本実施形態では、例外処理記述部237は、例外処理関数名を文字列で記述し、プログラム書換手段233は、要求受付手段21が受け付けた処理関数名を、例外処理を記述した当該文字列に書き換える。処理実行手段234は、要求受付手段21が受け付けた処理又はプログラム書換手段233により書き換えられた例外処理、のいずれかを実行し、当該処理の結果をユーザ端末8に対して提供する。要求受付手段21が受け付けた処理を実行する場合、処理実行手段234は、実行バックエンドサーバにアクセスし、ユーザ端末8から受け付けた処理要求を提供するとともに、当該実行バックエンドサーバによる処理結果をユーザ端末8に対して提供する。また、例外処理を実行する場合、処理実行手段234は、実行バックエンドサーバにアクセスすることなく、受け付けた処理要求の実行ができないことをユーザ端末8に提供する。ここで、例外処理プログラム23の一例について、図3に示す。要求処理判定手段231は、ライン98,99に記述されたメソッドチェックにおいて、要求受付手段21が受け付けた処理が、ライン249~313特に、ライン252~304書換対象処理記述部235に記述された処理例えば、ArticleLogic_WriteArticleに含まれるか否かを判定することにより実現される。なお、図3では、書換対象処理記述部235には、書換対象の処理として更新に関する処理UpdateMethodが記述されているが、当該記述を変更することで、他の処理例えば、閲覧や予約受付を書換対象とすることができる。また、サーバ判定手段232は、ライン100,101に記述されたサーバチェックにおいて、要求受付手段21が受け付けた実行バックエンドサーバが、ライン101に記述された障害バックエンドサーバarg_array[]:[]には、図示しない障害サーバ記述部236に記述したサーバ名が戻り値として取得されるに含まれるか否かを判定することにより実現される。なお、図3では、障害サーバ記述部236には、障害バックエンドサーバは記述されていないarg_array[0]が、図示しない障害サーバ記述部236の記述を変更することで、障害バックエンドサーバを適宜追加削除することができる。また、プログラム書換手段233は、ライン103~105に記述されたメンテナンスコマンドに書き換えにおいて、要求受付手段21が受け付けた処理を、ライン105例外処理記述部237に記述された例外処理MaintenanceCommandに書き換えることにより実現される。なお、図3では、例外処理記述部237には、例外処理としてメンテナンス時に行われるメンテナンスコマンドが記述されているが、当該記述を変更することで、例外処理を適宜変更することができる例えば、混雑中であることを返信する処理に変更する。また、図3では、プログラム書換手段233は、障害バックエンドサーバに対する書換対象の処理である場合に、常に、例外処理に書き換えることとしているが、これに限られるものではなく、障害バックエンドサーバに対する書換対象の処理のうち一部の処理についてのみ、例外処理に書き換えることとしてもよい。アクセス集中により通信負荷が増大した障害バックエンドサーバに対しては、全てのアクセスを禁止するのではなく、一部のアクセスを制限することが好ましいためである。このような、一部のアクセスの制限についても、例外処理記述部237の記述を変更することで、実現することができる。ここで、図3では、書換対象処理記述部235、障害サーバ記述部236及び例外処理記述部237の全てを例外処理プログラム23に記述することとしているが、これに限られるものではなく、当該記述部のうち少なくとも1つはディスク装置に記憶しておくこととしてもよい。この場合において、ディスク装置については、フロントエンドサーバ2がアクセス可能であればよく、必ずしもフロントエンドサーバ2自身が有する必要はない。[監視サーバ4]続いて、監視サーバ4について説明する。監視サーバ4は、監視手段41と、書換手段42と、を含んで構成される。監視手段41は、複数のバックエンドサーバ3の各々に対して定期的にアクセスし、ネットワークの到達性や、各々の管理する各種データが最新のものであるか否かを監視する。書換手段42は、監視手段41による監視の結果に基づいて、書換対象処理記述部235の記述書換対象処理及び障害サーバ記述部236の記述障害バックエンドサーバを書き換える自動書換。すなわち、書換手段42は、監視手段41による監視の結果、異常が生じているとされたバックエンドサーバ3の実行する処理を書換対象処理として記述するとともに、当該バックエンドサーバ3を障害バックエンドサーバとして記述する。このとき、書換手段42は、例外処理記述部237の記述例外処理についても書き換えることとしてもよい。すなわち、書換手段42は、監視手段41が発見した異常に基づいて例外処理を書き換えることとしてもよい。また、書換手段42は、例えば、ネットワークの到達性が困難になっているバックエンドサーバ3について、一部のリクエスト要求についてのみ例外処理例えば、只今、混み合っています。と表示する処理を実行し、他のリクエスト要求についてはユーザ端末8から受け付けた処理を実行させるように例外処理記述部237の記述を書き換えることとしてもよい。[管理者端末5]続いて、管理者端末5は、管理者が把握可能なメンテナンス情報、管理者による人間系の監視に伴い発見したバックエンドサーバ3の異常又はユーザからの通報などに基づいて、書換対象処理記述部235の記述書換対象処理、障害サーバ記述部236の記述障害バックエンドサーバ及び例外処理記述部237の記述例外処理を書き換える手動書換。このように、本実施形態のフロントエンドサーバ2は、監視サーバ4による自動書換、又は管理者端末5による手動書換に基づいて、例外処理を実行する。[ハードウェア構成]以上説明したWebサーバシステム1を構成する、フロントエンドサーバ2、バックエンドサーバ3、監視サーバ4及び管理者端末5のハードウェアは、1又は複数の一般的なコンピュータによって構成することができる。一般的なコンピュータは、例えば、制御部として、中央処理装置CPUを備える他、記憶部として、メモリRAM、ROM、ハードディスクHDD及び光ディスクCD、DVDなどを、ネットワーク通信装置として、各種有線及び無線LAN装置を、表示装置として、例えば、液晶ディスプレイ、プラズマディスプレイなどの各種ディスプレイを、入力装置として、例えば、キーボード及びポインティングデバイスマウス、トラッキングボールなどを適宜備え、これらは、バスラインにより接続されている。このような一般的なコンピュータにおいて、CPUは、フロントエンドサーバ2、バックエンドサーバ3、監視サーバ4及び管理者端末5を統括的に制御し、各種プログラムを適宜読み出して実行することにより、上述したハードウェアと協働し、本発明に係る各種機能を実現している。[Webサーバシステム1の処理]続いて、図4を参照して、Webサーバシステム1の処理の流れについて説明する。<例外処理実行>ユーザ端末8からリクエスト要求がなされるとS1、フロントエンドサーバ2の要求受付手段21は、受け付けたリクエスト要求に基づいて、バックエンドサーバ3に対する処理、及び実行バックエンドサーバの種別を受け付けるS11。続いて、フロントエンドサーバ2の要求処理判定手段231は、受け付けた処理が書換対象処理記述部235に記述された書換対象の処理であるか否かを文字列判定するとともにS12、フロントエンドサーバ2のサーバ判定手段232は、受け付けた実行バックエンドサーバの種別が障害サーバ記述部236に記述された障害バックエンドサーバであるか否かを文字列判定する。このとき、書換対象処理記述部235に記述された書換対象の処理であり、かつ、障害サーバ記述部236に記述された障害バックエンドサーバである場合にはS14でYES、フロントエンドサーバ2のプログラム書換手段233は、受け付けた処理を例外処理記述部237に記述された例外処理に書き換えるS15。続いて、フロントエンドサーバ2の処理実行手段234は、実行バックエンドサーバにアクセスすることなく例外処理を実行しS16、当該例外処理の実行結果をユーザ端末8に対して返信し、処理を終了する。他方、書換対象処理記述部235に記述された書換対象の処理、又は障害サーバ記述部236に記述された障害バックエンドサーバでない場合にはS14でNO、フロントエンドサーバ2の処理実行手段234は、ユーザ端末8から受け付けた処理の実行をバックエンドサーバ3に対して要求するS17。このとき、当該要求を受け付けたバックエンドサーバ3はS21、当該要求に対応する所定の処理を実行しS22、その処理結果をフロントエンドサーバ2に対して提供する。そして、処理結果を受け付けたフロントエンドサーバ2は、ユーザ端末8に対して当該処理結果を返信し、処理を終了する。ここで、Webサーバシステム1では、S12の処理判定及びS13のサーバ判定に用いる書換対象処理記述部235及び障害サーバ記述部236の記述と、S15の処理書換に用いる例外処理記述部237の記述と、を適宜書き換えることとしている。<自動書換>すなわち、監視サーバ4の監視手段41は、複数のバックエンドサーバ3の各々に対して定期的にアクセスし、ネットワークの到達性や、各々が管理する各種データが最新のものであるか否かを監視するS31。このとき、障害異常を検知した場合にはS32でYES、監視サーバ4の書換手段42は、書換対象処理記述部235、障害サーバ記述部236及び例外処理記述部237の記述を自動的に書き換えるS33。一方、障害異常を検知しない場合にはS32でNO、処理を終了する。<手動書換>また、管理者端末5の管理者は、適宜Webサーバシステム1内の障害監視を行いS41、障害異常を発見した場合にはS42でYES、書換対象処理記述部235、障害サーバ記述部236及び例外処理記述部237の記述を手動で書き換えるS43。一方、障害異常を発見しない場合にはS42でNO、処理を終了する。[Webサーバシステム1の動作]続いて、本実施形態のWebサーバシステム1における例外処理実行時の動作について、図5及び図6の例示を参照して説明する。図51を参照して、ユーザA及びユーザBからブログの更新についてのリクエスト要求を受け付けている。ここで、ユーザAのブログ更新処理は、バックエンドサーバ3Aに対する処理であり、ユーザBのブログ更新処理は、バックエンドサーバ3Bに対する処理であるとする。このとき、図52を参照して、例外処理プログラム23の書換対象処理記述部235には更新に関する処理が記述され、障害サーバ記述部236にはバックエンドサーバ3Aが記述され、例外処理記述部237には例外処理としてメンテナンス中であることを通知する処理が記述されている。そのため、図53に示すように、ユーザAに対しては、メンテナンス中であることが通知され、ユーザBに対しては、リクエスト要求に応じたブログ更新結果が通知されている。続いて、図61を参照して、ユーザA及びユーザCからチケット予約についてのリクエスト要求を受け付け、ユーザBから予約確認についてのリクエスト要求を受け付けている。ここで、ユーザAのチケット予約処理は、バックエンドサーバ3Lに対する処理であり、ユーザBの予約確認処理は、バックエンドサーバ3Mに対する処理であり、ユーザCのチケット予約処理は、バックエンドサーバ3Lに対する処理であるとする。このとき、図52を参照して、例外処理プログラム23の書換対象処理記述部235にはチケット予約に関する処理が記述され、障害サーバ記述部236にはバックエンドサーバ3Lが記述され、例外処理記述部237には例外処理として50のアクセスを制限する処理が記述されている。ここで、ユーザA及びユーザCのリクエスト要求は、例外処理条件を充足しているが、図52では、ユーザAのリクエスト要求に対してはアクセス制限がかけられ、ユーザCのリクエスト要求に対してはアクセス制限がかけられていない。そのため、図53に示すように、ユーザAに対しては、混み合っておりチケット予約をできないことが通知され、ユーザBに対しては、リクエスト要求に応じた予約確認情報が通知され、ユーザCに対しては、リクエスト要求に応じたチケット予約の完了が通知されている。このように、本実施形態によれば、例外処理条件書換対象処理、かつ、障害バックエンドサーバを充足したリクエスト要求に限り、バックエンドサーバ3にアクセスすることなく例外処理を実行するため、サーバ障害時やメンテナンス時にユーザへの影響を軽減することができる。このとき、例外処理条件を、監視サーバ4による自動書換又は管理者端末5による手動書換により書き換え可能としているため、バックエンドサーバ3の障害に応じて適切に例外処理を実行することができる。また、例外処理条件を充足したリクエスト要求の全てではなく、所定の割合のリクエスト要求に対してのみ例外処理を実行することを可能にしているため、バックエンドサーバ3の通信状況に応じて適切に例外処理を実行することができる。以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施例に記載されたものに限定されるものではない。例えば、本実施形態では、書換対象の処理であるか否かを文字列判定した後に、障害サーバであるか否かを文字列判定することとしているが、これに限られるものではなく、障害サーバであるか否かを文字列判定した後に、書換対象の処理であるか否かを文字列判定することとしてもよい。また、本実施形態では、フロントエンドサーバ2が例外処理プログラム23を記憶することとしているが、これに限られるものではなく、フロントエンドサーバ2が例外処理プログラム23に基づく例外処理条件の判定結果及び当該判定により実行すべき例外処理、を把握可能であればよく、例外処理プログラム23をフロントエンドサーバ2以外に記憶することとしてもよい。"