(57)【要約】      （修正有）【課題】バックエンドサーバの通信障害時にリソースの低下を抑制することの可能なアプリケーションサーバ及びその方法を提供する。【解決手段】アプリケーションサーバ１の通信遮断手段は監視ＤＢに記憶されるバックエンドサーバ３の所定時間内における通信エラー数が予め定めた閾値を超える場合、当該バックエンドサーバ３を通信遮断状態とする。アプリケーションサーバ１のリクエスト処理装置は、クライアント端末２からリクエスト要求を受けた場合であっても、通信遮断状態となったバックエンドサーバ３にはアクセスすることなく、リクエスト要求に応じたコンテンツを提供する。【選択図】図１
2011070631.tif 000002
【特許請求の範囲】
【請求項１】
リクエスト要求に応じて複数のバックエンドサーバのコンテンツを取得し、クライアント端末に提供するリクエスト処理装置を備えるアプリケーションサーバであって、
前記バックエンドサーバへの通信の可否を示す通信状況を監視するバックエンドサーバ監視装置と、前記バックエンドサーバ毎に前記通信状況を記憶する監視ＤＢと、を備え、
前記バックエンドサーバ監視装置は、
前記監視ＤＢに記憶される通信状況に応じて、対応するバックエンドサーバについて当該バックエンドサーバと通信を行わない通信遮断状態とする通信遮断手段と、
前記通信遮断状態とされたバックエンドサーバに対し定期的にアクセスし通信状況を取得するとともに、当該通信状況が通信可能である場合には前記通信遮断状態を解除する通信復帰手段と、を備え、
前記リクエスト処理装置は、
前記クライアント端末からリクエスト要求を受け付けると、当該リクエスト要求に対応するコンテンツを管理する複数のバックエンドサーバのうち前記通信遮断状態ではないバックエンドサーバからコンテンツを取得するコンテンツ取得手段と、
前記コンテンツ取得手段により取得された前記コンテンツを前記クライアント端末に提供するコンテンツ提供手段と、
を備えるアプリケーションサーバ。
【請求項２】
前記コンテンツ提供手段は、前記通信遮断状態であるバックエンドサーバが提供するコンテンツに代えて代用コンテンツを前記クライアント端末に提供する請求項１に記載のアプリケーションサーバ。
【請求項３】
前記通信遮断手段は、前記複数のバックエンドサーバ毎に予め定められた閾値に基づいて前記通信遮断状態とするか否か判断する請求項１又は２に記載のアプリケーションサーバ。
【請求項４】
前記閾値は、前記複数のバックエンドサーバ毎にそれぞれ変更可能である請求項３に記載のアプリケーションサーバ。
【請求項５】
前記バックエンドサーバ監視装置は、
前記通信遮断手段により前記通信遮断状態とされたバックエンドサーバの管理者に、前記通信遮断状態であることを通知するアラート通知手段、を更に備える請求項１から４のいずれか記載のアプリケーションサーバ。
【請求項６】
リクエスト要求に応じて複数のバックエンドサーバのコンテンツを取得し、クライアント端末に提供するリクエスト処理装置を備えるアプリケーションサーバであって、
前記バックエンドサーバへの通信の可否を示す通信状況を監視するバックエンドサーバ監視装置と、前記バックエンドサーバ毎に前記通信状況を記憶する監視ＤＢと、を備え、
前記バックエンドサーバ監視装置は、前記監視ＤＢに記憶される通信状況に応じて、対応するバックエンドサーバについて当該バックエンドサーバに対する通信を制限する度合いを段階的に更新する遮断レベル更新手段を備え、
前記リクエスト処理装置は、
前記クライアント端末からリクエスト要求を受け付けると、前記遮断レベル更新手段により更新された前記度合いに基づいて、当該リクエスト要求に基づく前記バックエンドサーバへの通信を制限するか否かを制御する通信制御手段と、
前記通信制御手段により通信が制限されないことを条件に、前記リクエスト要求に対応するコンテンツを管理するバックエンドサーバからコンテンツを取得するコンテンツ取得手段と、
前記コンテンツ取得手段により取得された前記コンテンツを前記クライアント端末に提供するコンテンツ提供手段と、
を備えるアプリケーションサーバ。
【請求項７】
前記バックエンドサーバ監視装置は、前記監視ＤＢから前記通信状況を定期的に取得し、所定時間内における通信できなかった回数が第１の閾値を超えるか否かを判定する通信状況確認手段を備え、
前記遮断レベル更新手段は、前記通信状況確認手段により前記第１の閾値を超えると判定されるたびに、前記度合いを段階的に上げる請求項６に記載のアプリケーションサーバ。
【請求項８】
前記通信状況確認手段は、所定時間内における通信できなかった回数が第２の閾値を超えないか否かを判定し、
前記遮断レベル更新手段は、前記通信状況確認手段により前記第２の閾値を超えないと判定されるたびに、前記度合いを段階的に下げる請求項７に記載のアプリケーションサーバ。
【請求項９】
前記第１の閾値及び前記第２の閾値は、前記複数のバックエンドサーバ毎にそれぞれ変更可能である請求項８に記載のアプリケーションサーバ。
【請求項１０】
前記コンテンツ提供手段は、前記通信制御手段により通信が制御されたバックエンドサーバが提供するコンテンツに代えて代用コンテンツを前記クライアント端末に提供する請求項６から９のいずれか記載のアプリケーションサーバ。
【請求項１１】
前記バックエンドサーバ監視装置は、
前記遮断レベル更新手段が、前記バックエンドサーバに対する通信を１００％制限することを条件に、当該バックエンドサーバの管理者に、通信が１００％制限されていることを通知するアラート通知手段、を更に備える請求項６から１０のいずれか記載のアプリケーションサーバ。
【請求項１２】
リクエスト要求に応じて複数のバックエンドサーバのコンテンツを取得し、クライアント端末に提供するアプリケーションサーバが、前記バックエンドサーバへの通信の可否を示す通信状況を前記バックエンドサーバ毎に監視する方法であって、
前記アプリケーションサーバは、前記バックエンドサーバの通信状況を記憶する監視ＤＢを備え、
前記アプリケーションサーバが、
前記クライアント端末からリクエスト要求を受け付けると、当該リクエスト要求に対応するコンテンツを管理する複数のバックエンドサーバの通信状況を取得して前記監視ＤＢに記憶させるステップと、
前記監視ＤＢに記憶される通信状況に応じて、対応するバックエンドサーバについて当該バックエンドサーバと通信を行わない通信遮断状態とするステップと、
前記通信遮断状態とされたバックエンドサーバに対し定期的にアクセスし通信状況を取得するとともに、当該通信状況が通信可能である場合には前記通信遮断状態を解除するステップと、
前記クライアント端末からリクエスト要求を受け付けると、当該リクエスト要求に対応するコンテンツを管理する複数のバックエンドサーバのうち前記通信遮断状態ではないバックエンドサーバからコンテンツを取得するステップと、
取得された前記コンテンツを前記クライアント端末に提供するステップと、
を含む方法。
【請求項１３】
リクエスト要求に応じて複数のバックエンドサーバのコンテンツを取得し、クライアント端末に提供するアプリケーションサーバが、前記バックエンドサーバへの通信の可否を示す通信状況を前記バックエンドサーバ毎に監視する方法であって、
前記アプリケーションサーバは、前記バックエンドサーバの通信状況を記憶する監視ＤＢを備え、
前記アプリケーションサーバが、
前記クライアント端末からリクエスト要求を受け付けると、当該リクエスト要求に対応するコンテンツを管理する複数のバックエンドサーバの通信状況を取得して前記監視ＤＢに記憶させるステップと、
前記監視ＤＢに記憶される通信状況に応じて、対応するバックエンドサーバについて当該バックエンドサーバに対する通信を制限する度合いを段階的に更新するステップと、
前記クライアント端末からリクエスト要求を受け付けると、前記ステップにより更新された前記度合いに基づいて、当該リクエスト要求に基づく前記バックエンドサーバへの通信を制限するか否かを制御するステップと、
前記ステップにより通信が制御されないことを条件に、前記リクエスト要求に対応するコンテンツを管理するバックエンドサーバからコンテンツを取得するステップと、
取得された前記コンテンツを前記クライアント端末に提供するステップと、
を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント端末からのリクエスト要求に応じてコンテンツを提供するアプリケーションサーバにおいて、コンテンツを管理する複数のバックエンドサーバの通信状況を監視するアプリケーションサーバ及びその方法に関する。
【背景技術】
【０００２】
近年、リクエスト要求に応じた１のＷｅｂページには、複数のコンテンツ（例えば、１のＷｅｂページにニュース・ブログ・株価・占い）が含まれ、この複数のコンテンツはそれぞれ個別のバックエンドサーバにより管理されている。そのため、クライアント端末からリクエスト要求を受けたアプリケーションサーバは、リクエスト要求に応じたＷｅｂページを提供するにあたり複数のバックエンドサーバにアクセスする必要がある。
【０００３】
ここで、バックエンドサーバに通信障害が生じていた場合には、アプリケーションサーバはバックエンドサーバにアクセスできないところ、通信障害が生じているか否か検知する手段として、例えば特許文献１に記載の技術が知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−９４５０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、特許文献１では、バックエンドサーバの通信障害を検知することができるものの、検知した通信障害に対処することはできなかった。ここで、バックエンドサーバの通信障害に対処できない場合の問題点について、図８を参照して説明する。
【０００６】
図８において、クライアント端末２からアプリケーションサーバ１へリクエスト要求がなされている。このリクエスト要求に対応するＷｅｂページは、ニュースコンテンツ、ブログコンテンツ、株価コンテンツ、占いコンテンツを含んで構成される。なお、ニュースコンテンツはバックエンドサーバ３Ａにより管理され、ブログコンテンツはバックエンドサーバ３Ｂにより管理され、株価コンテンツは図示しないバックエンドサーバ３Ｃにより管理され、占いコンテンツは図示しないバックエンドサーバ３Ｄにより管理される。また、図８において、バックエンドサーバ３Ｂは通信障害が生じており、通信不可能な状態である。
【０００７】
アプリケーションサーバ１はリクエスト要求に応じて、バックエンドサーバ３Ａ〜３Ｄにアクセスし、対応するコンテンツを取得するところ、バックエンドサーバ３Ａ，３Ｃ，３Ｄは通信障害が生じておらず通信可能であるため、対応するコンテンツを取得することができる。一方、バックエンドサーバ３Ｂは通信不可能であるため、対応するコンテンツを取得することができない。このとき、バックエンドサーバ３Ｂの通信障害に対処できないと、アプリケーションサーバ１はバックエンドサーバ３Ｂに対し繰り返しアクセスを行い、アプリケーションサーバ１のリソースを無駄に消費してしまう。
【０００８】
その結果、アプリケーションサーバ１のリソースが足りなくなり、通信不可能なバックエンドサーバ３Ｂだけでなく、通信可能なバックエンドサーバ３Ａ，３Ｃ，３Ｄとの通信にも障害（遅延）が生じてしまう。そのため、クライアント端末２の表示部には、例えば、即時表示可能な株価コンテンツ２０１Ｃや占いコンテンツ２０１Ｄまで長時間表示されず、クライアント端末２のユーザに対して不快感を与えてしまう。
【０００９】
そこで、本発明は、アプリケーションサーバのリソース低下によるユーザの不快感を抑制するものであり、バックエンドサーバの通信障害時にリソースの低下を抑制することの可能なアプリケーションサーバ及びその方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
（１）  リクエスト要求に応じて複数のバックエンドサーバのコンテンツを取得し、クライアント端末に提供するリクエスト処理装置を備えるアプリケーションサーバであって、前記バックエンドサーバへの通信の可否を示す通信状況を監視するバックエンドサーバ監視装置と、前記バックエンドサーバ毎に前記通信状況を記憶する監視ＤＢと、を備え、前記バックエンドサーバ監視装置は、前記監視ＤＢに記憶される通信状況に応じて、対応するバックエンドサーバについて当該バックエンドサーバと通信を行わない通信遮断状態とする通信遮断手段と、前記通信遮断状態とされたバックエンドサーバに対し定期的にアクセスし通信状況を取得するとともに、当該通信状況が通信可能である場合には前記通信遮断状態を解除する通信復帰手段と、を備え、前記リクエスト処理装置は、前記クライアント端末からリクエスト要求を受け付けると、当該リクエスト要求に対応するコンテンツを管理する複数のバックエンドサーバのうち前記通信遮断状態ではないバックエンドサーバからコンテンツを取得するコンテンツ取得手段と、前記コンテンツ取得手段により取得された前記コンテンツを前記クライアント端末に提供するコンテンツ提供手段と、を備えるアプリケーションサーバ。
【００１１】
（１）のアプリケーションサーバによれば、通信遮断手段は、バックエンドサーバへの通信の可否を示す通信状況に応じて（例えば、所定時間内におけるエラー数が予め定めた閾値を超える場合）、対応するバックエンドサーバを通信遮断状態とする。そして、コンテンツ取得手段は、クライアント端末からリクエスト要求がなされた場合、リクエスト要求に応じたコンテンツを管理する複数のバックエンドサーバのうち、通信遮断状態でないバックエンドサーバからコンテンツを取得し、通信遮断状態であるバックエンドサーバからはコンテンツを取得しない。そのため、通信遮断状態であるバックエンドサーバに対し繰り返しアクセスすることがなく、バックエンドサーバの通信障害時にアプリケーションサーバのリソースの低下を抑制できる。
この場合において、通信復帰手段は、通信遮断状態とされたバックエンドサーバについて通信障害が解消された場合には、自動的に通信遮断状態を解除する。そのため、通信の遮断・復帰を自動的に管理することができ、運用コストを削減することができる。
【００１２】
（２）  前記コンテンツ提供手段は、前記通信遮断状態であるバックエンドサーバが提供するコンテンツに代えて代用コンテンツを前記クライアント端末に提供する（１）に記載のアプリケーションサーバ。
【００１３】
（２）のアプリケーションサーバによれば、通信遮断状態のバックエンドサーバの管理するコンテンツを提供しない場合に比べて、ユーザフレンドリーなアプリケーションサーバを提供することができる。
【００１４】
（３）  前記通信遮断手段は、前記複数のバックエンドサーバ毎に予め定められた閾値に基づいて前記通信遮断状態とするか否か判断する（１）又は（２）に記載のアプリケーションサーバ。
【００１５】
（３）のアプリケーションサーバによれば、バックエンドサーバ毎のスペックに応じて、通信遮断状態とするか判断することができる。
【００１６】
（４）  前記閾値は、前記複数のバックエンドサーバ毎にそれぞれ変更可能である（３）に記載のアプリケーションサーバ。
【００１７】
（４）のアプリケーションサーバによれば、閾値は任意に設定可能であるため、バックエンドサーバに通信障害が生じているか否かの判断をより適確に行うことができる。
【００１８】
（５）  前記バックエンドサーバ監視装置は、前記通信遮断手段により前記通信遮断状態とされたバックエンドサーバの管理者に、前記通信遮断状態であることを通知するアラート通知手段、を更に備える（１）から（４）のいずれか記載のアプリケーションサーバ。
【００１９】
（５）のアプリケーションサーバによれば、通信障害が生じた場合にバックエンドサーバの管理者は早期に対応できるので、運用効率が向上する。
【００２０】
（６）  リクエスト要求に応じて複数のバックエンドサーバのコンテンツを取得し、クライアント端末に提供するリクエスト処理装置を備えるアプリケーションサーバであって、前記バックエンドサーバへの通信の可否を示す通信状況を監視するバックエンドサーバ監視装置と、前記バックエンドサーバ毎に前記通信状況を記憶する監視ＤＢと、を備え、前記バックエンドサーバ監視装置は、前記監視ＤＢに記憶される通信状況に応じて、対応するバックエンドサーバについて当該バックエンドサーバに対する通信を制限する度合いを段階的に更新する遮断レベル更新手段を備え、前記リクエスト処理装置は、前記クライアント端末からリクエスト要求を受け付けると、前記遮断レベル更新手段により更新された前記度合いに基づいて、当該リクエスト要求に基づく前記バックエンドサーバへの通信を制限するか否かを制御する通信制御手段と、前記通信制御手段により通信が制限されないことを条件に、前記リクエスト要求に対応するコンテンツを管理するバックエンドサーバからコンテンツを取得するコンテンツ取得手段と、前記コンテンツ取得手段により取得された前記コンテンツを前記クライアント端末に提供するコンテンツ提供手段と、を備えるアプリケーションサーバ。
【００２１】
（６）のアプリケーションサーバによれば、バックエンドサーバへの通信を直ちに遮断することなく、段階的に制限するため、バックエンドサーバとの通信を適切に制御することができる。その結果、アプリケーションサーバのリソースの低下を抑制することができ、また、段階的に通信を制限するため、クライアント端末への影響を軽微なものとすることができる。
【００２２】
（７）  前記バックエンドサーバ監視装置は、前記監視ＤＢから前記通信状況を定期的に取得し、所定時間内における通信できなかった回数が第１の閾値を超えるか否かを判定する通信状況確認手段を備え、前記遮断レベル更新手段は、前記通信状況確認手段により前記第１の閾値を超えると判定されるたびに、前記度合いを段階的に上げる（６）に記載のアプリケーションサーバ。
【００２３】
（７）のアプリケーションサーバによれば、バックエンドサーバが通信できなかった回数により、段階的に当該バックエンドサーバへの通信を制限するため、バックエンドサーバの通信が負荷増などにより遅延状態である場合に、バックエンドサーバとの通信を適切に制御することができる。
【００２４】
（８）  前記通信状況確認手段は、所定時間内における通信できなかった回数が第２の閾値を超えないか否かを判定し、前記遮断レベル更新手段は、前記通信状況確認手段により前記第２の閾値を超えないと判定されるたびに、前記度合いを段階的に下げる（７）に記載のアプリケーションサーバ。
【００２５】
（８）のアプリケーションサーバによれば、バックエンドサーバが通信できなかった回数が減ると、当該バックエンドサーバへの通信制限を段階的に解除するため、バックエンドサーバの通信状況の回復にあわせて、バックエンドサーバとの通信を適切に制御することができる。
【００２６】
（９）  前記第１の閾値及び前記第２の閾値は、前記複数のバックエンドサーバ毎にそれぞれ変更可能である（８）に記載のアプリケーションサーバ。
【００２７】
（９）のアプリケーションサーバによれば、閾値は任意に設定可能であるため、バックエンドサーバの通信が遅延しているか否かの判断をより適確に行うことができる。
【００２８】
（１０）  前記コンテンツ提供手段は、前記通信制御手段により通信が制御されたバックエンドサーバが提供するコンテンツに代えて代用コンテンツを前記クライアント端末に提供する（６）から（９）のいずれか記載のアプリケーションサーバ。
【００２９】
（１０）のアプリケーションサーバによれば、通信が制限されたバックエンドサーバの管理するコンテンツを提供しない場合に比べて、ユーザフレンドリーなアプリケーションサーバを提供することができる。
【００３０】
（１１）  前記バックエンドサーバ監視装置は、前記遮断レベル更新手段が、前記バックエンドサーバに対する通信を１００％制限することを条件に、当該バックエンドサーバの管理者に、通信が１００％制限されていることを通知するアラート通知手段、を更に備える（６）から（１０）のいずれか記載のアプリケーションサーバ。
【００３１】
（１１）のアプリケーションサーバによれば、通信遮断（１００％制限）となったバックエンドサーバの管理者は、早期に対応できるので運用効率が向上する。
【００３２】
（１２）  リクエスト要求に応じて複数のバックエンドサーバのコンテンツを取得し、クライアント端末に提供するアプリケーションサーバが、前記バックエンドサーバへの通信の可否を示す通信状況を前記バックエンドサーバ毎に監視する方法であって、前記アプリケーションサーバは、前記バックエンドサーバの通信状況を記憶する監視ＤＢを備え、前記アプリケーションサーバが、前記クライアント端末からリクエスト要求を受け付けると、当該リクエスト要求に対応するコンテンツを管理する複数のバックエンドサーバの通信状況を取得して前記監視ＤＢに記憶させるステップと、前記監視ＤＢに記憶される通信状況に応じて、対応するバックエンドサーバについて当該バックエンドサーバと通信を行わない通信遮断状態とするステップと、前記通信遮断状態とされたバックエンドサーバに対し定期的にアクセスし通信状況を取得するとともに、当該通信状況が通信可能である場合には前記通信遮断状態を解除するステップと、前記クライアント端末からリクエスト要求を受け付けると、当該リクエスト要求に対応するコンテンツを管理する複数のバックエンドサーバのうち前記通信遮断状態ではないバックエンドサーバからコンテンツを取得するステップと、取得された前記コンテンツを前記クライアント端末に提供するステップと、を含む方法。
【００３３】
（１３）  リクエスト要求に応じて複数のバックエンドサーバのコンテンツを取得し、クライアント端末に提供するアプリケーションサーバが、前記バックエンドサーバへの通信の可否を示す通信状況を前記バックエンドサーバ毎に監視する方法であって、前記アプリケーションサーバは、前記バックエンドサーバの通信状況を記憶する監視ＤＢを備え、前記アプリケーションサーバが、前記クライアント端末からリクエスト要求を受け付けると、当該リクエスト要求に対応するコンテンツを管理する複数のバックエンドサーバの通信状況を取得して前記監視ＤＢに記憶させるステップと、前記監視ＤＢに記憶される通信状況に応じて、対応するバックエンドサーバについて当該バックエンドサーバに対する通信を制限する度合いを段階的に更新するステップと、前記クライアント端末からリクエスト要求を受け付けると、前記ステップにより更新された前記度合いに基づいて、当該リクエスト要求に基づく前記バックエンドサーバへの通信を制限するか否かを制御するステップと、前記ステップにより通信が制御されないことを条件に、前記リクエスト要求に対応するコンテンツを管理するバックエンドサーバからコンテンツを取得するステップと、取得された前記コンテンツを前記クライアント端末に提供するステップと、を含む方法。
【００３４】
（１２）の方法によれば、（１）のアプリケーションサーバと同様の効果を期待でき、（１３）の方法によれば、（６）のアプリケーションサーバと同様の効果を期待できる。
【発明の効果】
【００３５】
本発明によれば、バックエンドサーバの通信障害時にリソースの低下を抑制することの可能なアプリケーションサーバ及びその方法を提供することができる。
【図面の簡単な説明】
【００３６】
【図１】第１実施形態に係るアプリケーションサーバの概略を示す図である。
【図２】第１実施形態に係るアプリケーションサーバの構成を示すブロック図である。
【図３】第１実施形態に係るアプリケーションサーバの監視ＤＢの一例を示す図である。
【図４】第１実施形態に係るアプリケーションサーバのＷｅｂページデータ提供処理の流れを示すフローである。
【図５】第１実施形態に係るアプリケーションサーバの通信遮断処理の流れを示すフローである。
【図６】第１実施形態に係るアプリケーションサーバの通信復帰処理の流れを示すフローである。
【図７】第１実施形態に係るアプリケーションサーバの動作を示す図である。
【図８】従来のアプリケーションサーバの動作を示す図である。
【図９】第２実施形態に係るアプリケーションサーバの概略を示す図である。
【図１０】第２実施形態に係るアプリケーションサーバの構成を示すブロック図である。
【図１１】第２実施形態に係るアプリケーションサーバの監視ＤＢの一例を示す図である。
【図１２】第２実施形態に係るアプリケーションサーバのＷｅｂページデータ提供処理の流れを示すフローである。
【図１３】第２実施形態に係るアプリケーションサーバの遮断レベル更新処理の流れを示すフローである。
【発明を実施するための形態】
【００３７】
以下、本発明の実施形態について図を参照しながら説明する。
【００３８】
本実施形態は、コンピュータ及びその周辺装置に適用される。本実施形態における各手段は、コンピュータ及びその周辺装置が備えるハードウェア並びに該ハードウェアを制御するソフトウェアによって構成される。
【００３９】
上記ハードウェアには、制御部としてのＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）の他、記憶装置、通信装置、表示装置及び入力装置が含まれる。記憶装置としては、例えば、メモリ（ＲＡＭ：Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ、ＲＯＭ：Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙなど）、ハードディスクドライブ（ＨＤＤ：Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）及び光ディスク（ＣＤ：Ｃｏｍｐａｃｔ  Ｄｉｓｋ、ＤＶＤ：Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋなど）ドライブが挙げられる。通信装置としては、例えば、各種有線及び無線インターフェース装置が挙げられる。表示装置としては、例えば、液晶ディスプレイ、プラズマディスプレイなどの各種ディスプレイが挙げられる。入力装置としては、例えば、キーボード及びポインティング・デバイス（マウス、トラッキングボールなど）が挙げられる。
【００４０】
上記ソフトウェアには、上記ハードウェアを制御するコンピュータ・プログラムやデータが含まれる。コンピュータ・プログラムやデータは、記憶装置により記憶され、制御部により適宜実行、参照される。また、コンピュータ・プログラムやデータは、通信回線を介して配布されることも可能であり、ＣＤ−ＲＯＭなどのコンピュータ可読媒体に記録して配布されることも可能である。
【００４１】
［第１実施形態］
図１〜図７を参照して、第１実施形態に係るアプリケーションサーバ１について説明する。
【００４２】
［アプリケーションサーバの概略］
図１は、第１実施形態に係るアプリケーションサーバ１の概略を示す図である。アプリケーションサーバ１は、リクエスト要求毎に設けられ、クライアント端末２Ａ，２Ｂ，２Ｃ・・・（以下、区別しない場合は「クライアント端末２」とする）からリクエスト要求を受けるとともに、リクエスト要求に応じた複数のコンテンツを含むＷｅｂページを構成するデータ（Ｗｅｂページデータ）をクライアント端末２に返信する。
【００４３】
なお、「リクエスト要求」とは、クライアント端末２（ユーザ）が所望するコンテンツを指定するための情報であり、例えば、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）が該当する。
【００４４】
アプリケーションサーバ１は、リクエスト要求を受けると、対応するＷｅｂページを構成するコンテンツを管理する複数のバックエンドサーバ３Ａ，３Ｂ・・・（以下、区別しない場合は「バックエンドサーバ３」とする）にアクセスし、それぞれからコンテンツを取得する。
【００４５】
ここで、図１において、クライアント端末２からのリクエスト要求に対応するＷｅｂページは、バックエンドサーバ３Ａが管理するコンテンツ及びバックエンドサーバ３Ｂが管理するコンテンツを含んで構成される。また、バックエンドサーバ３Ａは通信可能な状態であり、バックエンドサーバ３Ｂは通信障害が生じ通信不可能な状態である。このとき、第１実施形態に係るアプリケーションサーバ１は、バックエンドサーバ３Ａにはアクセスするものの、バックエンドサーバ３Ｂにはアクセスしない。その結果、通信不可能なバックエンドサーバ３Ｂに対し繰り返しアクセスすることがなく、アプリケーションサーバ１のリソースの低下を抑制することができる。
【００４６】
以下、第１実施形態に係るアプリケーションサーバ１の具体的構成について、説明する。
【００４７】
［アプリケーションサーバ１の構成］
図２は、アプリケーションサーバ１の構成を示すブロック図である。アプリケーションサーバ１は、クライアント端末２からのリクエスト要求に応じてＷｅｂページデータを提供するリクエスト処理装置１１と、当該Ｗｅｂページデータにより構成されるＷｅｂページに含まれるコンテンツを管理するバックエンドサーバ３の通信状況を監視するバックエンドサーバ監視装置１２と、バックエンドサーバ３の通信状況を記憶する監視ＤＢ１３と、から構成される。
【００４８】
リクエスト処理装置１１は、リクエスト受付手段１１１と、遮断情報確認手段１１２と、通信状況取得手段１１３と、コンテンツ取得手段１１４と、コンテンツ提供手段１１５と、から構成される。
【００４９】
リクエスト受付手段１１１は、クライアント端末２からリクエスト要求を受け付ける。
【００５０】
遮断情報確認手段１１２は、監視ＤＢ１３を参照し、リクエスト要求に応じたＷｅｂページを構成するコンテンツを管理するバックエンドサーバ３が通信遮断状態であるか確認する。具体的には、図３（２）において後述する監視ＤＢ１３の監視テーブルを参照し、リクエスト要求に応じてアクセスすべきバックエンドサーバ３の遮断フラグを確認することで、対応するバックエンドサーバ３が通信遮断状態であるか確認する。なお、遮断フラグは、後述の通信遮断手段１２２により「１（通信遮断）」に更新され、後述の通信復帰手段１２４により「０（通信可能）」に更新される。よって、遮断情報確認手段１１２は、対応するバックエンドサーバ３の遮断フラグが「１」である場合には通信遮断状態であると判断し、「０」である場合には通信可能状態であると判断する。
【００５１】
通信状況取得手段１１３は、リクエスト要求に応じたコンテンツを管理するバックエンドサーバ３のうち、遮断情報確認手段１１２により通信可能状態と確認されたバックエンドサーバ３の通信状況（通信ステータス）を取得する。例えば、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）の“ｅｃｈｏ  ｒｅｑｕｅｓｔ”をバックエンドサーバ３に投げかけ、バックエンドサーバ３から“ｅｃｈｏ  ｒｅｐｌｙ”を受け取る「ｐｉｎｇ」を実行することで通信状況を取得する。ここで、通信状況取得手段１１３は、所定の間隔（例えば、１秒）で複数回通信状況の取得を行う。このとき、バックエンドサーバ３から“ｅｃｈｏ  ｒｅｐｌｙ”を受け取らない場合には、監視ＤＢ１３のステータステーブルに、対応するバックエンドサーバ３の通信状況がエラーであることを記憶させる（後述の図３（１）参照）。
【００５２】
コンテンツ取得手段１１４は、リクエスト要求に応じたコンテンツを管理するバックエンドサーバ３のうち、遮断情報確認手段１１２により通信遮断状態でないと確認されたバックエンドサーバ３にアクセスし、コンテンツを取得する。
【００５３】
コンテンツ提供手段１１５は、取得した複数のコンテンツからＷｅｂページデータを生成し、クライアント端末２に提供する。なお、通信遮断状態のバックエンドサーバ３がある場合には、当該バックエンドサーバ３の管理するコンテンツに代えて代用コンテンツ（例えば、「現在利用できません」などの案内コンテンツ）を含むＷｅｂページデータを生成し、提供することとしてもよい。
【００５４】
続いて、バックエンドサーバ監視装置１２は、通信状況確認手段１２１と、通信遮断手段１２２と、アラート通知手段１２３と、通信復帰手段１２４と、から構成される。
【００５５】
通信状況確認手段１２１は、図３（１）において後述する監視ＤＢ１３のステータステーブルを参照して、所定時間内におけるエラー数が予め定めた閾値を超えるか否かをバックエンドサーバ３毎に確認する。なお、この閾値は、バックエンドサーバ３毎に異なることとしてもよい。また、閾値はアプリケーションサーバ１又はバックエンドサーバ３の管理者により任意に変更可能としてもよい。
【００５６】
通信遮断手段１２２は、所定時間内におけるエラー数が閾値を超える場合に、当該バックエンドサーバ３を通信遮断状態とする。具体的には、図３（２）において後述する監視ＤＢ１３の監視テーブルにおいて、対応するバックエンドサーバ３の遮断フラグを「１」に更新する。
【００５７】
アラート通知手段１２３は、バックエンドサーバ３の管理者端末４に、管理するバックエンドサーバ３が通信遮断状態であることを通知する。これにより、管理者はバックエンドサーバ３に通信障害があることを早期に認識することができ、この通信障害を早期に解決することができる。
【００５８】
通信復帰手段１２４は、通信遮断状態（遮断フラグが「１」）とされたバックエンドサーバ３に対し定期的に（通信状況取得手段１１３に比べて長い間隔で（例えば、１分））アクセスし通信状況を取得し、通信可能か否かを判断する。そして、通信可能である場合には監視ＤＢ１３の監視テーブル（図３（２））の遮断フラグを「０」に更新することで通信遮断状態を解除する。
【００５９】
ここで、第１実施形態では、通信状況取得手段１１３が“ｅｃｈｏ  ｒｅｐｌｙ”を受け取らなかった時点ではなく（監視ＤＢ１３のステータステーブルに、対応するバックエンドサーバ３の通信状況がエラーとなった時点ではなく）、「所定時間内における」エラー数が閾値を超える場合に、このバックエンドサーバ３の通信状況を通信遮断状態としている。これはトラフィックの増加により一時的にバックエンドサーバ３と通信できない場合にまで通信遮断状態とすることを防止するためである。
【００６０】
続いて、監視ＤＢ１３は、ステータステーブル及び監視テーブルから構成され、バックエンドサーバ３の通信状況を記憶する。ステータステーブルは、図３（１）に示すように、通信状況取得手段１１３が取得したバックエンドサーバ３の通信状況が記憶される。例えば、図３（１）を参照すると、６月２１日１８時２０分０１秒にバックエンドサーバ３Ａと通信可能であったことが記憶され、６月２１日１８時２０分１１秒にバックエンドサーバ３Ｂと通信できなかったことが記憶される。
【００６１】
また、監視テーブルは、図３（２）に示すようにバックエンドサーバ３の種別毎に遮断フラグの情報を記憶している。遮断フラグが「０」である場合は通信可能状態であることを意味し、遮断フラグが「１」である場合は通信遮断状態（リクエスト要求がなされても当該バックエンドサーバ３にはアクセスしない）であることを意味する。遮断フラグは、該当するバックエンドサーバ３について、所定時間内におけるステータステーブルのエラー数が閾値を超える場合に通信遮断手段１２２により「０」から「１」に更新される。また、遮断フラグは、通信復帰手段１２４により通信可能と判断されると、「１」から「０」に更新される。
【００６２】
［アプリケーションサーバ１の処理］
次に、図４〜図６を参照して、アプリケーションサーバ１の動作の流れについて説明する。
【００６３】
［Ｗｅｂページデータ提供処理］
図４は、クライアント端末２から受け付けたリクエスト要求に応じてＷｅｂページデータを提供する際のＷｅｂページデータ提供処理の流れを示すフローチャートである。
【００６４】
Ｓ１：リクエスト受付手段１１１は、クライアント端末２からユーザが所望するＷｅｂページを特定するリクエスト要求を受け付ける。
【００６５】
Ｓ２：続いて、遮断情報確認手段１１２は、リクエスト要求に応じたＷｅｂページに含まれるコンテンツを管理するバックエンドサーバ３を特定し、該当するバックエンドサーバ３の通信情報を確認する。すなわち、遮断情報確認手段１１２は、監視ＤＢ１３の監視テーブルを参照して、バックエンドサーバ３の遮断フラグを確認する。
【００６６】
Ｓ３：このとき通信遮断状態でないバックエンドサーバ３については、通信状況取得手段１１３は、所定の間隔（例えば、１秒）で複数回アクセスし、通信状況を取得する。
【００６７】
Ｓ４：続いて、コンテンツ取得手段１１４は、通信状況が確認され、通信可能なバックエンドサーバ３からコンテンツを取得する。
【００６８】
Ｓ５：他方、遮断情報確認手段１１２により通信遮断状態であると確認されたバックエンドサーバ３に対しては、通信状況取得手段１１３及びコンテンツ取得手段１１４は何らアクセスすることなく、コンテンツ取得手段１１４はアプリケーションサーバ１の記憶装置（他のサーバの記憶装置であってもよい）に記憶される代用コンテンツを取得する。
なお、通信遮断状態であるバックエンドサーバ３だけでなく、通信遮断状態ではないが（通信フラグが「０」）、通信状況取得手段１１３により通信可能の確認ができないバックエンドサーバ３についても、代用コンテンツを取得することとしてもよい。
【００６９】
Ｓ６：続いて、コンテンツ提供手段１１５は、取得したコンテンツ及び代用コンテンツからリクエスト要求に応じたＷｅｂページデータを生成し、クライアント端末２に提供する。
【００７０】
［通信遮断処理］
次に、図５を参照して、バックエンドサーバ３との通信を遮断する通信遮断処理について説明する。
【００７１】
Ｓ１１：通信状況確認手段１２１は、監視ＤＢ１３のステータステーブルを参照し、バックエンドサーバ３の通信状況を確認する。例えば、通信状況確認手段１２１は、所定時間内におけるエラー数が、該当するバックエンドサーバ３毎に予め定められた閾値を超えるか否かを確認する。
【００７２】
Ｓ１２：続いて、通信遮断手段１２２は、所定時間内におけるエラー数が予め定めた閾値を超えるバックエンドサーバ３について、通信遮断状態とする。すなわち、監視ＤＢ１３の監視テーブルにおいて、当該バックエンドサーバ３の遮断フラグを「１」に更新する。その結果、図４のＳ２において遮断情報確認手段１１２により通信遮断状態であると確認されることとなり、クライアント端末２からリクエスト要求がなされても、当該バックエンドサーバ３にアクセスされなくなる。
【００７３】
Ｓ１３：次に、アラート通知手段１２３は、通信遮断状態とされたバックエンドサーバ３を管理する管理者の管理者端末４にメールを送信するなどして、管理するバックエンドサーバ３が通信遮断状態であることを通知する。この通知によりバックエンドサーバ３の管理者は、バックエンドサーバ３に通信障害が生じていることを早期に認識することができ、通信障害が早期に解決されることを期待できる。
【００７４】
［通信復帰処理］
次に、図６を参照して、バックエンドサーバ３の通信遮断状態を解除する通信復帰処理について説明する。
【００７５】
Ｓ２１：通信復帰手段１２４は、監視ＤＢ１３の監視テーブルから遮断フラグを取得し、遮断フラグが「１」であるバックエンドサーバ３を特定する。すなわち、通信復帰手段１２４は、通信遮断状態であるバックエンドサーバ３を特定する。
【００７６】
Ｓ２２：続いて、通信復帰手段１２４は、通信遮断状態であるバックエンドサーバ３に対し定期的にアクセスし、通信状況を取得する。
【００７７】
Ｓ２３：このとき、通信遮断状態であるバックエンドサーバ３との接続を確認できた場合には、通信復帰手段１２４は、監視ＤＢ１３の監視テーブルにおいて、当該バックエンドサーバ３の遮断フラグを「１」から「０」に更新する。他方、接続を確認できない場合には、通信復帰手段１２４は、当該バックエンドサーバ３の遮断フラグを「１」のまま維持する。その結果、通信遮断状態であるバックエンドサーバ３との接続を確認できた場合には、通信遮断状態が解除され、その後はクライアント端末２からのリクエスト要求に応じて、当該バックエンドサーバ３にアクセスすることとなる。
【００７８】
このように、第１実施形態に係るアプリケーションサーバ１によれば、通信遮断状態と確認されたバックエンドサーバ３にはコンテンツの取得時に繰り返しアクセスすることがないため、通信障害が生じているバックエンドサーバ３に対し繰り返しアクセスすることによるアプリケーションサーバ１のリソースの低下を抑制することができる。
【００７９】
また、この場合において、第１実施形態に係るアプリケーションサーバ１によれば、通信障害の生じているバックエンドサーバ３を自動的に通信遮断状態とすることができるとともに、バックエンドサーバ３の管理者により通信障害が解消された場合には、その後、通信復帰手段１２４により通信遮断状態を自動的に解除することができる。そのため、バックエンドサーバ３の通信遮断状態の制御を自動的に行うことができ、運用コストを削減することができる。
【００８０】
更に、通信遮断状態であるバックエンドサーバ３の管理者にはアラートが通知されるため、管理者は通信障害に対し早期に対応でき、運用効率を上げることができる。
【００８１】
［アプリケーションサーバ１の動作例］
次に、図７を参照して、第１実施形態に係るアプリケーションサーバ１の動作例について説明する。
【００８２】
クライアント端末２からアプリケーションサーバ１へリクエスト要求がなされると、アプリケーションサーバ１は、リクエスト要求に応じたＷｅｂページを構成するコンテンツを管理する複数のバックエンドサーバ３からコンテンツを取得する。ここで、図７において、リクエスト要求に対応するＷｅｂページは、ニュースコンテンツ、ブログコンテンツ、株価コンテンツ、占いコンテンツを含んで構成される。また、ニュースコンテンツはバックエンドサーバ３Ａにより管理され、ブログコンテンツはバックエンドサーバ３Ｂにより管理され、株価コンテンツは図示しないバックエンドサーバ３Ｃにより管理され、占いコンテンツは図示しないバックエンドサーバ３Ｄにより管理される。また、図７において、バックエンドサーバ３Ｂは通信障害が生じ通信不可能な状態であるため、遮断フラグが「１」に更新されている。
【００８３】
アプリケーションサーバ１はリクエスト要求に応じて、バックエンドサーバ３Ａ〜３Ｄにアクセスし、対応するコンテンツを取得するところ、バックエンドサーバ３Ａ，３Ｃ，３Ｄは通信可能であるため、対応するコンテンツを取得することができる。一方、バックエンドサーバ３Ｂは通信遮断状態であるため、リクエスト要求がされてもアクセスすることがない。
【００８４】
その結果、通信障害が生じているバックエンドサーバ３に繰り返しアクセスすることがないため、アプリケーションサーバ１のリソースの低下を抑制することができ、通信可能なバックエンドサーバ３Ａ，３Ｃ，３Ｄとの通信に影響を与えずにすむ。これにより、クライアント端末２の表示部には、通信可能なバックエンドサーバ３Ａ，３Ｃ，３Ｄの管理するニュースコンテンツ２０１Ａ、株価コンテンツ２０１Ｃ、占いコンテンツ２０１Ｄを含むＷｅｂページが適切に表示される。また、このとき、通信遮断状態であるバックエンドサーバ３Ｂの管理するブログコンテンツに代わり、代用コンテンツ２０１Ｂを表示させることとすれば、クライアント端末２のユーザがバックエンドサーバ３Ｂの状況を理解することができ、クライアント端末２のユーザに不快感を与えることがない。
【００８５】
［第２実施形態］
次に、図９〜図１３を参照して、第２実施形態のアプリケーションサーバ１Ａについて説明する。なお、第２実施形態において、第１実施形態と同一の構成については、同一の符号を付し、詳細な説明を省略する。
【００８６】
第１実施形態のアプリケーションサーバ１は、監視ＤＢ１３のステータステーブルに記憶されたバックエンドサーバ３の通信状況に応じて（所定時間内におけるエラー数が予め定めた閾値を超えた場合に）直ちに通信遮断状態としている。これに対して、第２実施形態のアプリケーションサーバ１Ａでは、バックエンドサーバ３の通信状況に応じて段階的に通信を制限する。例えば、バックエンドサーバ３の通信状況が負荷増などにより遅延状態である場合に好適である。
【００８７】
図９を参照して、バックエンドサーバ３Ａは、通信可能なバックエンドサーバ３であり、バックエンドサーバ３Ｂは、通信を３分の１制限しているバックエンドサーバ３である。クライアント端末２Ａ，２Ｂ，２Ｃからリクエスト要求がなされるとアプリケーションサーバ１Ａは、通信可能なバックエンドサーバ３Ａからコンテンツを取得し、取得したコンテンツをクライアント端末２Ａ，２Ｂ，２Ｃに提供する。一方、バックエンドサーバ３Ｂは通信を３分の１制限しているため、アプリケーションサーバ１Ａは、クライアント端末２Ｂ，２Ｃからのリクエスト要求に基づくコンテンツ要求は行うものの、クライアント端末２Ａからのリクエスト要求に基づくコンテンツ要求は制限し行わない。その結果、クライアント端末２Ｂ，２Ｃには、バックエンドサーバ３Ｂが管理するコンテンツが提供され、クライアント端末２Ａには、バックエンドサーバ３Ｂが管理するコンテンツが提供されない。なお、アプリケーションサーバ１Ａは、通信が制限されたクライアント端末２Ａに対しては、アプリケーションサーバ１と同様に、バックエンドサーバ３Ｂの管理するコンテンツの代わりに代用コンテンツを提供することとしてもよい。
【００８８】
このように、アプリケーションサーバ１Ａでは、通信状況が遅延状態であるバックエンドサーバ３Ｂに対する通信を段階的に制限するので、アプリケーションサーバ１Ａのリソースの低下を抑制することができ、通信可能なバックエンドサーバ３との通信に影響を与えずにすむ。また、アプリケーションサーバ１Ａでは、直ちに通信遮断とせず、段階的に通信を制限するため、クライアント端末２への影響を軽微なものとすることができる。
【００８９】
以下、第２実施形態に係るアプリケーションサーバ１Ａの具体的構成について、説明する。
【００９０】
［アプリケーションサーバ１Ａの構成］
図１０は、アプリケーションサーバ１Ａの構成を示すブロック図である。
アプリケーションサーバ１Ａは、クライアント端末２からのリクエスト要求に応じてＷｅｂページデータを提供するリクエスト処理装置１１Ａと、当該Ｗｅｂページデータにより構成されるＷｅｂページに含まれるコンテンツを管理するバックエンドサーバ３の通信状況を監視するバックエンドサーバ監視装置１２Ａと、バックエンドサーバ３の通信状況を記憶する監視ＤＢ１３Ａと、から構成される。
【００９１】
リクエスト処理装置１１Ａは、リクエスト受付手段１１１と、通信制御手段１１２Ａと、通信状況取得手段１１３と、コンテンツ取得手段１１４と、コンテンツ提供手段１１５と、から構成される。
【００９２】
通信制御手段１１２Ａは、監視ＤＢ１３Ａを参照し、リクエスト受付手段１１１が受け付けたリクエスト要求に応じたＷｅｂページを構成するコンテンツを管理するバックエンドサーバ３の通信制限状態を確認する。具体的には、通信制御手段１１２Ａは、図１１において後述する監視ＤＢ１３Ａの監視テーブルを参照し、リクエスト要求に応じてアクセスすべきバックエンドサーバ３の遮断レベルを確認することで、対応するバックエンドサーバ３の通信制限状態を確認する。なお、遮断レベルは、「０」が例えば通信制限がない状態、「１」が例えば１０％の通信を制限する状態、「２」が例えば２０％の通信を制限する状態、同様に「３」〜「９」が例えば３０％〜９０％の通信を制限する状態、「１０」が例えば１００％の通信を制限する状態（すなわち、通信遮断状態）をいう。もちろん、通信制限状態はこれに限られるものではなく、任意に設定可能である。このような遮断レベルの更新は、遮断レベル更新手段１２２Ａにより行われる。
通信制御手段１１２Ａは、確認した遮断レベルに基づいて、バックエンドサーバ３への通信（通信状況取得手段１１３、コンテンツ取得手段１１４による通信）を制限する。例えば、通信制御手段１１２Ａは、遮断レベルが「１」である場合には、１０％の通信を制限する。１０％の通信を制限する方法の一例としては、乱数を生成し、クライアント端末２からのリクエスト要求のうち当該乱数を１０で割った剰余が「１」であるリクエスト要求に基づく通信を制限し、剰余が「１」以外であるリクエスト要求に基づく通信を制限しないことが考えられる（もちろん、他の方法で実現することもできる）。
【００９３】
通信状況取得手段１１３及びコンテンツ取得手段１１４は、通信が制限されないリクエスト要求に基づいて、バックエンドサーバ３と所定の通信を行う。コンテンツ提供手段１１５は、コンテンツ取得手段１１４が取得したコンテンツをクライアント端末２に提供する。
なお、コンテンツ取得手段１１４は、通信が制限されたリクエスト要求に対しては、通信制限されたバックエンドサーバ３の管理するコンテンツに代えて代用コンテンツ（例えば、「現在利用できません」などの案内コンテンツ）を含むＷｅｂページデータを生成し、コンテンツ提供手段は、当該代用コンテンツをクライアント端末２に提供することとしてもよい。
【００９４】
続いて、バックエンドサーバ監視装置１２Ａは、通信状況確認手段１２１Ａと、遮断レベル更新手段１２２Ａと、アラート通知手段１２３と、から構成される。
【００９５】
通信状況確認手段１２１Ａは、監視ＤＢ１３Ａのステータステーブル（図３（１）に示す第１実施形態のステータステーブルと同じ）を定期的に（例えば１分）確認し、所定時間内におけるエラー数が予め定めた第１の閾値を超えるか否かをバックエンドサーバ３毎に確認する。
また、通信状況確認手段１２１Ａは、監視ＤＢ１３Ａのステータステーブルを定期的に確認し、所定時間内におけるエラー数が予め定めた第２の閾値を超えないか否かを遮断レベルが「１」〜「９」であるバックエンドサーバ３毎に確認する。
また、通信状況確認手段１２１Ａは、遮断レベルが「１０」であるバックエンドサーバ３に対し定期的に（例えば、１分）アクセスし通信状況を取得し、通信可能か否かを判断する。すなわち、通信遮断されているバックエンドサーバ３に対しては、通信可能であるか否かを直接確認する。
【００９６】
なお、第１の閾値及び第２の閾値は、所定時間内におけるエラー数であってもよく、所定時間内における全通信に対するエラー数の割合であってもよい。また、第１の閾値及び第２の閾値は、バックエンドサーバ３毎に異なることとしてもよい。また、第１の閾値及び第２の閾値は、アプリケーションサーバ１Ａ又はバックエンドサーバ３の管理者により任意に変更可能としてもよい。また、第２の閾値は、第１の閾値と同じ、又は第１の閾値よりも小さい値であることが好ましい。
また、「超える・超えない」については、「以上・未満」としてもよく、「より大きい・以下」としてもよく、「以上・以下」としてもよく、「より大きい・未満」としてもよい。但し、第１の閾値と第２の閾値とを同じ値とする場合には、「以上・未満」又は「より大きい・以下」とすることが好ましい。
【００９７】
遮断レベル更新手段１２２Ａは、監視ＤＢ１３Ａの監視テーブルの遮断レベルを更新する。具体的には、通信状況確認手段１２１Ａにより、所定時間内におけるエラー数が第１の閾値を超えると判断された場合には、遮断レベル更新手段１２２Ａは、対応するバックエンドサーバ３の遮断レベルを「１」上げる。他方、通信状況確認手段１２１Ａにより、所定時間内におけるエラー数が第２の閾値を超えないと判断された場合には、遮断レベル更新手段１２２Ａは、対応するバックエンドサーバ３の遮断レベルを「１」下げる。このように、遮断レベル更新手段１２２Ａは、エラー数に基づいて遮断レベルを段階的に更新することで、バックエンドサーバ３への通信を段階的に制限する。
また、遮断レベルが「１０」であるバックエンドサーバ３に関して、通信状況確認手段１２１Ａにより通信可能であると判断された場合には、遮断レベル更新手段１２２Ａは、対応するバックエンドサーバ３の遮断レベルを「１０」から「９」に更新する。
【００９８】
アラート通知手段１２３は、遮断レベル更新手段１２２Ａが遮断レベルを「９」から「１０」に更新（すなわち、通信遮断状態に更新）した場合に、当該バックエンドサーバ３の管理者端末４に、管理するバックエンドサーバ３が通信遮断状態であることを通知する。
【００９９】
続いて、監視ＤＢ１３Ａは、ステータステーブル及び監視テーブルから構成され、バックエンドサーバ３の通信状況を記憶する。ステータステーブルは、第１実施形態と同一であり、図３（１）に示すように、通信状況取得手段１１３が取得したバックエンドサーバ３の通信状況が記憶される。
また、監視テーブルは、図１１に示すように、バックエンドサーバ３の種別毎に遮断レベルの情報を記憶している。
【０１００】
［アプリケーションサーバ１の処理］
次に、図１２及び図１３を参照して、アプリケーションサーバ１Ａの動作の流れについて説明する。
【０１０１】
［Ｗｅｂページデータ提供処理］
図１２は、クライアント端末２から受け付けたリクエスト要求に応じてＷｅｂページデータを提供する際のＷｅｂページデータ提供処理の流れを示すフローチャートである。第２実施形態のＷｅｂページデータ提供処理は、第１実施形態のＷｅｂページデータ提供処理と基本的に同じであるが、ステップＳ１０２の処理が異なる。
【０１０２】
Ｓ１０１：リクエスト受付手段１１１は、クライアント端末２からユーザが所望するＷｅｂページを特定するリクエスト要求を受信する。
【０１０３】
Ｓ１０２：続いて、通信制御手段１１２Ａは、リクエスト要求に応じたＷｅｂページに含まれるコンテンツを管理するバックエンドサーバ３を特定し、該当するバックエンドサーバ３の遮断レベルに基づいて、通信を制限する。具体的には、通信制御手段１１２Ａは、遮断レベルが「１」である場合には、１０％の通信を制限する。
【０１０４】
Ｓ１０３：通信の制限を受けない場合には、通信状況取得手段１１３は、バックエンドサーバ３に対して所定の間隔（例えば、１秒）で複数回アクセスし、通信状況を取得する。
【０１０５】
Ｓ１０４：続いて、コンテンツ取得手段１１４は、通信状況が確認され、通信可能なバックエンドサーバ３からコンテンツを取得する。
【０１０６】
Ｓ１０５：他方、通信制御手段１１２Ａにより通信が制限された場合には、通信状況取得手段１１３及びコンテンツ取得手段１１４はバックエンドサーバ３にアクセスすることなく、コンテンツ取得手段１１４はアプリケーションサーバ１Ａの記憶装置（他のサーバの記憶装置であってもよい）に記憶される代用コンテンツを取得する。
なお、通信が制限された場合だけでなく、通信状況取得手段１１３により通信可能の確認ができない場合についても、コンテンツ取得手段１１４は、代用コンテンツを取得することとしてもよい。
【０１０７】
Ｓ１０６：続いて、コンテンツ提供手段１１５は、取得したコンテンツ及び代用コンテンツからリクエスト要求に応じたＷｅｂページデータを生成し、クライアント端末２に提供する。
【０１０８】
［遮断レベル更新処理］
次に、図１３を参照して、バックエンドサーバ３の遮断レベルを更新する遮断レベル更新処理について説明する。なお、図１３中、Ｓ１１１〜Ｓ１１５は、遮断レベル「１０」から「９」に更新する際の処理の流れを示し、Ｓ１１６〜Ｓ１２０は、遮断レベルを段階的に上げる際の処理の流れを示し、Ｓ１１６〜Ｓ１２３は、遮断レベルを段階的に下げる際の処理の流れを示す。
【０１０９】
Ｓ１１１：通信状況確認手段１２１Ａは、監視ＤＢ１３Ａの監視テーブルから対象とするバックエンドサーバ３の遮断レベルを取得する。
【０１１０】
Ｓ１１２：通信状況確認手段１２１Ａは、取得した遮断レベルが「１０」であるか否か、すなわち、バックエンドサーバ３が通信遮断状態であるか否かを判定する。
【０１１１】
Ｓ１１３、Ｓ１１４：このとき、通信遮断状態である場合には、通信状況確認手段１２１Ａは、当該バックエンドサーバ３に対し定期的に（例えば、１分）アクセスし通信状況を取得し、通信可能か否かを判断する。
【０１１２】
Ｓ１１５：このとき、通信可能である場合には、遮断レベル更新手段１２２Ａは、遮断レベルを「１０」から「９」に下げ、処理を終了する。他方、通信不可能である場合には、遮断レベル更新手段１２２Ａは、処理を終了する。
【０１１３】
Ｓ１１６：また、遮断レベルが「１０」でない場合には、通信状況確認手段１２１Ａは、監視ＤＢ１３Ａのステータステーブルを参照し、バックエンドサーバ３の通信状況を取得する。
【０１１４】
Ｓ１１７：続いて、通信状況確認手段１２１Ａは、所定時間内におけるエラー数が、第１の閾値を超えるか否かを判断する。
Ｓ１１８：このとき、第１の閾値を超える場合には、遮断レベル更新手段１２２Ａは、対象のバックエンドサーバ３の遮断レベルを「１」上げる。
【０１１５】
Ｓ１１９：続いて、遮断レベル更新手段１２２Ａは、遮断レベルが「１０」に更新されたか否かを判定する。
Ｓ１２０：このとき、遮断レベルが「１０」に更新された場合には、アラート通知手段１２３は、通信遮断状態とされたバックエンドサーバ３を管理する管理者の管理者端末４にメールを送信するなどして、管理するバックエンドサーバ３が通信遮断状態であることを通知し、処理を終了する。他方、遮断レベルが「１０」でない場合には、アラート通知手段１２３は、処理を終了する。
【０１１６】
Ｓ１２１：また、所定時間内におけるエラー数が、第１の閾値を超えない場合、通信状況確認手段１２１Ａは、当該エラー数が第２の閾値を超えないか否かを判定する。
Ｓ１２２：このとき、第２の閾値を超えない場合には、遮断レベル更新手段１２２Ａは、対象のバックエンドサーバ３の遮断レベルが「０」であるか否かを判定する。他方、第２の閾値を超える場合には、遮断レベル更新手段１２２Ａは、処理を終了する。
Ｓ１２３：続いて、遮断レベルが「０」でない場合（すなわち、通信制限がかせられている場合）には、遮断レベル更新手段１２２Ａは、対象のバックエンドサーバ３の遮断レベルを「１」下げ、処理を終了する。他方、遮断レベルが「０」である場合には、遮断レベル更新手段１２２Ａは、処理を終了する。
【０１１７】
以上、第２実施形態のアプリケーションサーバ１Ａについて説明した。
アプリケーションサーバ１Ａによれば、バックエンドサーバ３への通信が負荷増などにより遅延状態である場合に、その遅延状況にあわせてバックエンドサーバ３への通信を段階的に制限することができる。その結果、アプリケーションサーバ１Ａは、自身のリソースの低下を抑制することができ、通信可能なバックエンドサーバ３との通信に影響を与えずにすむ。また、アプリケーションサーバ１Ａは、直ちに通信遮断とせず、段階的に通信を制限するため、クライアント端末２への影響を軽微なものとすることができる。
【０１１８】
以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施例に記載されたものに限定されるものではない。
【０１１９】
第２実施形態に係るアプリケーションサーバ１Ａでは、アラート通知手段１２３は、遮断レベルが「９」から「１０」に更新された場合に（すなわち、通信遮断となった場合に）、管理者端末４に所定の通知を行うこととしているが、これに限られるものではない。例えば、遮断レベルが更新されるたびに管理者端末４に所定の通知を行うこととしてもよく、特に、遮断レベルが「１」上がった場合に（すなわち、通信制限がかけられた場合に）、管理者端末４に所定の通知を行うこととしてもよい。
【符号の説明】
【０１２０】
１  アプリケーションサーバ
１１  リクエスト処理装置
１２  バックエンドサーバ監視装置
１３  監視ＤＢ
１１１  リクエスト受付手段
１１２  遮断情報確認手段
１１３  通信状況取得手段
１１４  コンテンツ取得手段
１１５  コンテンツ提供手段
１２１  通信状況確認手段
１２２  通信遮断手段
１２３  アラート通知手段
１２４  通信復帰手段
【図１】
2011070631.tif 000003
【図２】
2011070631.tif 000004
【図３】
2011070631.tif 000005
【図４】
2011070631.tif 000006
【図５】
2011070631.tif 000007
【図６】
2011070631.tif 000008
【図７】
2011070631.tif 000009
【図８】
2011070631.tif 000010
【図９】
2011070631.tif 000011
【図１０】
2011070631.tif 000012
【図１１】
2011070631.tif 000013
【図１２】
2011070631.tif 000014
【図１３】
2011070631.tif 000015