(57)【特許請求の範囲】
【請求項１】
ユーザ端末装置とクラウドネットワーク内のｗｅｂサーバ装置との通信ネットワークにおける故障被疑箇所を推定する故障被疑箇所推定装置であって、
前記通信ネットワークの各部位におけるｗｅｂページ読込に要する時間に関するｗｅｂページ読込時間情報と、前記クラウドネットワーク内の応答性に関する応答性情報と、前記ｗｅｂサーバ装置の性能に関する性能情報と、を収集する収集部と、
収集された前記ｗｅｂページ読込時間情報、前記応答性情報及び前記性能情報に基づいて、前記通信ネットワークにおける前記故障被疑箇所を推定する推定部と、
を備えることを特徴とする故障被疑箇所推定装置。
【請求項２】
前記通信ネットワークは、前記ユーザ端末装置と前記クラウドネットワークとを通信可能に接続するネットワークを含んでおり、
前記収集部は、前記ユーザ端末装置の位置情報を収集し、
前記推定部は、前記ネットワークが前記故障被疑箇所であると推定した場合に、収集された前記位置情報に基づいて、前記ネットワーク内における前記故障被疑箇所を絞り込む
ことを特徴とする請求項１に記載の故障被疑箇所推定装置。
【請求項３】
ユーザ端末装置とクラウドネットワーク内のｗｅｂサーバ装置との通信ネットワークにおける故障被疑箇所を推定する故障被疑箇所推定装置による故障被疑箇所推定方法であって、
前記故障被疑箇所推定装置が、前記通信ネットワークの各部位におけるｗｅｂページ読込に要する時間に関するｗｅｂページ読込時間情報と、前記クラウドネットワーク内の応答性に関する応答性情報と、前記ｗｅｂサーバ装置の性能に関する性能情報と、を収集する収集ステップと、
前記故障被疑箇所推定装置が、収集された前記ｗｅｂページ読込時間情報、前記応答性情報及び前記性能情報に基づいて、前記通信ネットワークにおける前記故障被疑箇所を推定する推定ステップと、
を含むことを特徴とする故障被疑箇所推定方法。
【請求項４】
前記通信ネットワークは、前記ユーザ端末装置と前記クラウドネットワークとを通信可能に接続するネットワークを含んでおり、
前記収集ステップにおいて、前記故障被疑箇所推定装置が、前記ユーザ端末装置の位置情報を収集し、
前記推定ステップにおいて、前記故障被疑箇所推定装置が、前記ネットワークが前記故障被疑箇所であると推定した場合に、収集された前記位置情報に基づいて、前記ネットワーク内における前記故障被疑箇所を絞り込む
ことを特徴とする請求項３に記載の故障被疑箇所推定方法。
【請求項５】
ユーザ端末装置とクラウドネットワーク内のｗｅｂサーバ装置との通信ネットワークにおける故障被疑箇所を推定する故障被疑箇所推定装置としてのコンピュータを、
前記通信ネットワークの各部位におけるｗｅｂページ読込に要する時間に関するｗｅｂページ読込時間情報と、前記クラウドネットワーク内の応答性に関する応答性情報と、前記ｗｅｂサーバ装置の性能に関する性能情報と、を収集する収集部、
収集された前記ｗｅｂページ読込時間情報、前記応答性情報及び前記性能情報に基づいて、前記通信ネットワークにおける前記故障被疑箇所を推定する推定部、
として機能させる故障被疑箇所推定プログラム。
【請求項６】
前記通信ネットワークは、前記ユーザ端末装置と前記クラウドネットワークとを通信可能に接続するネットワークを含んでおり、
前記収集部は、前記ユーザ端末装置の位置情報を収集し、
前記推定部は、前記ネットワークが前記故障被疑箇所であると推定した場合に、収集された前記位置情報に基づいて、前記ネットワーク内における前記故障被疑箇所を絞り込む
ことを特徴とする請求項５に記載の故障被疑箇所推定プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワーク上における故障被疑箇所を推定する技術に関する。
【背景技術】
【０００２】
本願出願人は、通信ネットワーク上で提供されるＥ２Ｅ（End to End）サービスの性能を評価するために、ＭＩＢ（Management Information Base）情報を用いて劣化箇所を特定する技術を提案している（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−３３７１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１に記載の技術は、１事業者内に閉じたＥ２Ｅサービスを想定したものであり、他事業者のＭＩＢ情報を取得することは困難であるため、複数事業者を跨いだＥ２Ｅサービスに対して適用することは困難である。
また、特許文献１に記載の技術は、１事業者内に閉じたＥ２Ｅサービスであっても、サービスが大規模な場合には、経路上の全ての装置からＭＩＢ情報を収集して解析することは困難である。
【０００５】
一方、本願出願人は、複数事業者を跨いだＥ２Ｅサービスにおいて故障被疑箇所を推定する技術を提案している（特願２０１５−１５６６２６、本願出願時未公開）。
かかる技術では、複数のサービス監視情報に基づいて、障害が発生した通信サービスに最も多く含まれるノードが故障被疑箇所であると推定している。
【０００６】
しかし、かかる技術は、Ｅ２Ｅサービス監視の具体的な手法については言及されていない。また、かかる技術は、単一の故障を対象としており、多重故障には迅速に対応することができない。また、かかる技術は、故障被疑箇所を推定するために、一般的には公開されていないＩＳＰ網の構成情報（の推定）を必要とする。
【０００７】
本発明は、前記事情に鑑みて創案されたものであり、複数事業者を跨いだＥ２Ｅサービスや大規模なＥ２Ｅサービスにおいても故障被疑箇所を好適に推定することが可能な故障被疑箇所推定装置、故障被疑箇所推定方法および故障被疑箇所推定プログラムを提供することを課題とする。
【課題を解決するための手段】
【０００８】
前記課題を解決するために、本発明は、ユーザ端末装置とクラウドネットワーク内のｗｅｂサーバ装置との通信ネットワークにおける故障被疑箇所を推定する故障被疑箇所推定装置であって、前記通信ネットワークの各部位におけるｗｅｂページ読込に要する時間に関するｗｅｂページ読込時間情報と、前記クラウドネットワーク内の応答性に関する応答性情報と、前記ｗｅｂサーバ装置の性能に関する性能情報と、を収集する収集部と、収集された前記ｗｅｂページ読込時間情報、前記応答性情報及び前記性能情報に基づいて、前記通信ネットワークにおける前記故障被疑箇所を推定する推定部と、を備えることを特徴とする。
【０００９】
かかる構成によると、複数事業者を跨いだＥ２Ｅサービスや大規模なＥ２Ｅサービスにおいても故障被疑箇所を好適に推定することができる。
【００１０】
前記通信ネットワークは、前記ユーザ端末装置と前記クラウドネットワークとを通信可能に接続するネットワークを含んでおり、前記収集部は、前記ユーザ端末装置の位置情報を収集し、前記推定部は、前記ネットワークが前記故障被疑箇所であると推定した場合に、収集された前記位置情報に基づいて、前記ネットワーク内における前記故障被疑箇所を絞り込む構成であってもよい。
【００１１】
かかる構成によると、ネットワークが故障被疑箇所である場合にユーザ端末装置の位置情報に基づいて故障被疑箇所を絞り込むので、故障被疑箇所をより好適に推定することができる。
【００１２】
また、本発明は、ユーザ端末装置とクラウドネットワーク内のｗｅｂサーバ装置との通信ネットワークにおける故障被疑箇所を推定する故障被疑箇所推定装置による故障被疑箇所推定方法であって、前記故障被疑箇所推定装置が、前記通信ネットワークの各部位におけるｗｅｂページ読込に要する時間に関するｗｅｂページ読込時間情報と、前記クラウドネットワーク内の応答性に関する応答性情報と、前記ｗｅｂサーバ装置の性能に関する性能情報と、を収集する収集ステップと、前記故障被疑箇所推定装置が、収集された前記ｗｅｂページ読込時間情報、前記応答性情報及び前記性能情報に基づいて、前記通信ネットワークにおける前記故障被疑箇所を推定する推定ステップと、を含むことを特徴とする。
【００１３】
前記通信ネットワークは、前記ユーザ端末装置と前記クラウドネットワークとを通信可能に接続するネットワークを含んでおり、前記収集ステップにおいて、前記故障被疑箇所推定装置が、前記ユーザ端末装置の位置情報を収集し、前記推定ステップにおいて、前記故障被疑箇所推定装置が、前記ネットワークが前記故障被疑箇所であると推定した場合に、収集された前記位置情報に基づいて、前記ネットワーク内における前記故障被疑箇所を絞り込む構成であってもよい。
【００１４】
また、本発明は、コンピュータを前記故障被疑箇所推定装置として機能させるＡＰＩ連携プログラムとしても具現化可能である。
【発明の効果】
【００１５】
本発明によると、複数事業者を跨いだＥ２Ｅサービスや大規模なＥ２Ｅサービスにおいても故障被疑箇所を好適に推定することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施形態に係る故障被疑箇所推定装置が適用された通信ネットワークを示す模式図である。
【図２】NavigationTiming APIによって計測されたｗｅｂページ読込時間情報を示す模式図である。
【図３】NavigationTiming APIによる計測値の一覧を示す表である。
【図４】CloudWatch APIによる計測値の一覧を示す表である。
【図５】Geolocation APIによる計測値の一覧を示す表である。
【図６】計測値の閾値を決定する手法を説明するための図であり、（ａ）は、計測値の経時変化の一例を示すグラフ、（ｂ）は、計測値の比率の経時変化の一例を示すグラフである。
【図７】故障被疑箇所推定装置の動作例を説明するためのフローチャートである。
【図８】故障被疑箇所推定装置の動作例を説明するためのフローチャートである。
【発明を実施するための形態】
【００１７】
続いて、本発明の実施形態について図面を参照して説明する。図１に示すように、本発明の実施形態に係る故障被疑箇所推定装置１００は、ユーザ端末装置２とｗｅｂサーバ装置７０とを接続する通信ネットワーク１における故障被疑箇所を推定する装置である。
【００１８】
通信ネットワーク１は、複数のユーザ端末装置２側のネットワーク３として、ユーザ端末装置２と通信可能に接続される複数のアクセス網２０と、アクセス網２０と通信可能に接続される複数のＩＳＰ（Internet Service Provider）網３０と、ＩＳＰ網３０と通信可能に接続されるインターネット網４０と、を備える。
【００１９】
アクセス網２０は、ユーザ端末装置２と最初に接続されるネットワークであり、市町村又は都道府県単位の範囲に敷設されている。ＩＳＰ網３０は、各通信事業者によって管理されているネットワークであり、複数の都道府県に跨る広範囲に敷設されている。ここで、ユーザ端末装置２がｗｅｂサーバ装置７０との通信を行う際にどのＩＳＰ網３０が用いられるかは、通信事業者ごとに異なるルールによって決定されたり変更されたりする。
【００２０】
また、通信ネットワーク１は、ｗｅｂサーバ装置７０側のネットワーク構造すなわちクラウドネットワーク４として、インターネット網４０と通信可能に接続されるロードバランサ（ＥＬＢ：Elastic Load Balancer）５０と、ロードバランサ５０と通信可能に接続されるＤＣ（Data Communication）網６０と、ＤＣ網６０と通信可能に接続される複数のｗｅｂサーバ装置７０と、を備える。
【００２１】
また、通信ネットワーク１は、ＤＮＳ（Domain Name System）サーバ装置８０と、ＩＰ Geolocation ＤＢ（Internet Protocol Geolocation DataBase）装置９０と、を備える。
【００２２】
ＤＮＳサーバ装置８０は、アクセス網２０、ＩＳＰ網３０又はインターネット網４０内に含まれており、ドメイン名とＩＰアドレスとが関連付けられたデータベースを備え、問い合わせに応じてドメイン名又はＩＰアドレスを返信する装置である。
【００２３】
ＩＰ Geolocation ＤＢ装置９０はインターネット網４０内に含まれており、、ＩＰアドレスと当該ＩＰアドレスが付与された装置の名称及び位置情報（緯度、経度等）とが関連付けられたデータベースである。当該データベースにおいて、ＩＰアドレスが付与された装置のホストネーム、当該装置が所属するＩＳＰ網３０のＩＳＰ名、組織名、座標等がＩＰアドレスと関連付けられていてもよい。ＩＰ Geolocation ＤＢ装置９０としては、ＤＢ−ＩＰ、ipinfo.io、MAXMIND等のデータベース装置が利用可能である。
【００２４】
＜故障被疑箇所推定装置＞
故障被疑箇所推定装置１００は、通信ネットワーク１における故障被疑箇所を推定する装置である。故障被疑箇所推定装置１００は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read-Only Memory）、ＲＡＭ（Random Access Memory）、入出力回路等によって構成されており、機能部として、収集部１０１と、推定部１０２と、を備える。
【００２５】
≪収集部≫
収集部１０１は、故障被疑箇所を推定するために以下の情報を収集（取得）し、収集された情報を推定部１０２へ出力する。
１．ユーザ端末装置２がｗｅｂサーバ装置７０にアクセスした際にNavigation Timing API（Application Programming Interface）によって計測したｗｅｂページ読込時間情報
２．ユーザ端末装置２がGeolocation APIによって計測した当該ユーザ端末装置２の位置情報
３．ロードバランサ５０がCloud Watch APIによって計測したクラウドネットワーク４内の応答性情報
４．ｗｅｂサーバ装置７０がCloud Watch APIによって計測したｗｅｂサーバ装置７０の性能情報
５．ＩＰ Geolocation ＤＢ装置９０に記憶されたｗｅｂサーバ装置７０の位置情報、及び、ＩＳＰ情報（例えば、ＩＳＰ網３０の名称すなわちＩＳＰ名）
【００２６】
ここで、ユーザ端末装置２は、例えば以下に示す３つの手法によって各種の情報を自動収集するためのプログラム（Javascript（登録商標））が挿入されている。
１．ｗｅｂサーバ装置７０（ｗｅｂサービス事業者）が予めJavascriptを埋め込んだｗｅｂページを用意する。
２．プロキシ等を用意し、プロキシ等を通過する全てのｗｅｂページにJavascriptを強制的に挿入する。
３．ユーザに依頼し、Javascriptが埋め込まれたｗｅｂページをユーザ端末装置２のブックマークレット等に登録してもらう。
ユーザ端末装置２は、かかるJavascriptの実行によって、ｗｅｂページ読込時間情報、位置情報及びアクセス先のｗｅｂサーバ装置７０のアクセス先ＵＲＬ（Uniform Resource Locater）を収集し、収集された情報をAjax（Asynchronous JavaScript + XML）等を用いて故障被疑箇所推定装置１００へ送信する。
【００２７】
また、収集部１０１は、収集されたアクセス先ＵＲＬを用いてＤＮＳサーバ装置８０を参照する（nslookup）ことによって、アクセス先ＵＲＬに対応するアクセス先ＩＰアドレスを取得する。続いて、収集部１０１は、取得されたアクセス先ＩＰアドレスを用いてＩＰ Geolocation装置を参照することによって、アクセス先ＩＰアドレスに対応するｗｅｂサーバ装置７０の位置情報、及び、ＩＳＰ情報を取得する。
【００２８】
ユーザ端末装置２がGeolocation APIによって当該ユーザ端末装置２の位置情報を収集する手法としては、位置情報を1回だけ取得するgetCurrentPosition、位置情報を定期的に監視して取得するwatchPosition、及び、watchPositionによる位置情報の監視をクリアするclearWatchのいずれか等が用いられる。
【００２９】
なお、ユーザ端末装置２の位置情報に関しては、収集部１０１が、ユーザ端末装置２のＩＰアドレスを用いてＩＰ Geolocation装置を参照することによっても取得可能である。
【００３０】
＜Navigation Timing APIによるｗｅｂページ読込時間情報＞
Navigation Timing APIは、ユーザ端末装置２がブラウザでｗｅｂページを表示する際に、通信ネットワーク１のどこでどれだけの時間がかかっているのかを計測する手法である。図２に示すように、Navigation Timing APIによって計測されるプロセスは、Prompt for unload、redirect、unload、App cache、DNS、TCP、Request、Response、Processing、DOM Content Loaded、loadを含む。
【００３１】
ユーザ端末装置２は、Navigation Timing APIによって、ｗｅｂページ読込時間情報として以下に示す時刻情報を計測し、計測結果を故障被疑箇所推定装置１００へ送信する。
・startTime（navigationStart）：Prompt for unloadの終了時刻
・redirectStart：redirectの開始時刻
・redirectEnd：redirectの終了時刻
・unloadEventStart：unloadの開始時刻
・unloadEventEnd：unloadの終了時刻
・fetchStart：App cacheの開始時刻
・domainLookupStart：ＤＮＳサーバ装置８０におけるdomainLookupの開始時刻
・domainLookupEnd：ＤＮＳサーバ装置８０におけるdomainLookupの終了時刻
・connectStart：ＴＣＰ（Transmission Control Protocol）の接続開始時刻
・secureConnectionStart：ＴＣＰのsecureConnectionの開始時刻
・connectEnd：ＴＣＰの接続終了時刻
・requestStart：Requestの開始時刻
・responseStart：Responseの開始時刻
・responseEnd：Responseの終了時刻
・domLoading：Processingの開始時刻であり、ブラウザが最初に受け取ったＨＴＭＬ（Hyper Text Markup Language）ドキュメントのバイト解析の開始時刻（ＨＴＭＬドキュメント自体の読込開始時刻）
・domInteractive：ブラウザがＨＴＭＬの解析を完了し、ＤＯＭ（Document Object Model）構築を完了した時刻（ＨＴＭＬドキュメントの読込が完了し、非同期に取得することができる画像等のリソースの読込開始時刻）
・domComplete：Processingの終了時刻であり、ｗｅｂページの全てのリソース（画像等）のダウンロードの完了時刻
・domContentLoadedEventStart：DOMContentLoadedの開始時刻
・domContentLoadedEventEnd：DOMContentLoadedの終了時刻
・loadEventStart：loadの開始時刻
・loadEventEnd：loadの終了時刻
【００３２】
収集部１０１は、ユーザ端末装置２によって送信されたｗｅｂページ読込時間情報（時刻情報）を受信し、受信されたｗｅｂページ読込時間情報に基づいて、計測値０１〜１３（ｗｅｂページ読込時間情報）を算出し、算出された計測値０１〜１３を推定部１０２へ出力する。
【００３３】
計測値０１〜１３について、図３を参照して説明する。
計測値０１は、トータルのｗｅｂページ読込時間である。
（計測値０１）＝（loadEventEnd）−（navigationStart）
計測値０１が長い場合には、通信ネットワーク１のどこかに故障が発生しているおそれがある。
計測値０２は、redirectに要する時間である。
（計測値０２）＝（redirectEnd）−（redirectStart）
計測値０２が長い場合には、ユーザ端末装置２に故障が発生しているおそれがある。
計測値０３は、unloadに要する時間である。
（計測値０３）＝（unloadEventEnd）−（unloadEventStart）
計測値０３が長い場合には、ユーザ端末装置２に故障が発生しているおそれがある。
計測値０４は、App cacheに要する時間である。
（計測値０４）＝（domainLookupStart）−（fetchStart）
計測値０４が長い場合には、ユーザ端末装置２に故障が発生しているおそれがある。
計測値０５は、DNS（名前解決）に要する時間である。
（計測値０５）＝（domainLookupEnd）−（domainLookupStart）
計測値０５が長い場合には、ユーザ端末装置２、アクセス網２０、ＩＳＰ網３０及びＤＮＳサーバ装置８０の少なくとも一つに故障が発生しているおそれがある。
【００３４】
計測値０６は、DNS（名前解決）からTCP-SYN送信までの内部処理に要する時間である。
（計測値０６）＝（connectStart）−（domainLookupEnd）
計測値０６が長い場合には、ユーザ端末装置２に故障が発生しているおそれがある。
計測値０７は、TCP接続処理（3-way handshake）に要する時間である。
（計測値０７）＝（connectEnd）−（connectStart）
計測値０７が長い場合には、ユーザ端末装置２、アクセス網２０、ＩＳＰ網３０、インターネット網４０、ＤＣ網６０、ｗｅｂサーバ装置７０、ＶＭ（Vertial Machine）及びｗｅｂＡＰＬ（APpLication）の少なくとも一つに故障が発生しているおそれがある。ここで、ｗｅｂサーバ装置７０は、ハードウェアリソース上に仮想化層として仮想化ソフトウェア（Hypervisor等）が実装されることによって仮想化されており、ＶＭ（Vertial Machine）として、１つの管理用仮想マシンと、複数の仮想マシンと、を備える。また、１つのＶＭにおいて、１つ以上のｗｅｂＡＰＬが作動している。
計測値０８は、TCP接続完了からHTTPリクエスト送信までの内部処理に要する時間である。
（計測値０８）＝（requestStart）−（connectEnd）
計測値０８が長い場合には、ユーザ端末装置２に故障が発生しているおそれがある。
計測値０９は、HTTPリクエスト送信から第一HTTPレスポンス受信までに要する時間である。
（計測値０９）＝（responseStart）−（requestStart）
計測値０９は、ユーザ端末装置２→ｗｅｂＡＰＬ→ユーザ端末装置２の往復通過時間である。
計測値０９が長い場合には、アクセス網２０、ＩＳＰ網３０、インターネット網４０、ＤＣ網６０、ｗｅｂサーバ装置７０、ＶＭ及びｗｅｂＡＰＬの少なくとも一つに故障が発生しているおそれがある。
計測値１０は、HTTPリクエスト受信に要する時間である。
（計測値１０）＝（responseEnd）−（responseStart）
計測値１０は、ｗｅｂＡＰＬ→ユーザ端末装置２の片道通過時間である。
計測値１０が長い場合には、アクセス網２０、ＩＳＰ網３０、インターネット網４０、ＤＣ網６０、ｗｅｂサーバ装置７０、ＶＭ及びｗｅｂＡＰＬの少なくとも一つに故障が発生しているおそれがある。
【００３５】
計測値１１は、HTTPレスポンス受信完了からHTMLドキュメント読込開始までの内部処理に要する時間である。
（計測値１１）＝（domLoading）−（responseEnd）
計測値１１が長い場合には、ユーザ端末装置２に故障が発生しているおそれがある。
計測値１２は、HTMLドキュメント読込に要する時間である。
（計測値１２）＝（domInteractive）−（domLoading）
計測値１２が長い場合には、ユーザ端末装置２に故障が発生しているおそれがある。
計測値１３は、（非同期での）画像等読込に要する時間である。
（計測値１３）＝（domComplete）−（domInteractive）
計測値１３が長い場合には、ユーザ端末装置２に故障が発生しているおそれがある。
【００３６】
＜CloudWatch APIによる応答性情報＞
CloudWatch APIは、クラウドネットワーク４内の応答性に関する応答性情報を計測する手法である。クラウドネットワーク４内のロードバランサ５０は、CloudWatch APIによって、以下に示す応答性情報を計測し、計測結果を故障被疑箇所推定装置１００へ送信する。
・Latency（単位：秒）：ロードバランサ５０がリクエストを送信し、応答を受信するまでの経過時間
【００３７】
＜CloudWatch APIによる性能情報＞
また、CloudWatch APIは、ｗｅｂサーバ装置７０の性能に関する性能情報を計測する手法である。ｗｅｂサーバ装置（ＶＭすなわちＥＣ２）７０は、CloudWatch APIによって、以下に示す性能情報を計測し、計測結果を故障被疑箇所推定装置１００へ送信する。
・CPU Utilization（単位：％）：割り当てられたＥＣ２コンピュートユニットのうち、現在インスタンス上で使用されているものの比率
・NetworkIn（単位：Byte）：指定インスタンスによって受信されたバイト数であり、１インスタンス上の１アプリケーションへのネットワークトラヒック量
・NetworkOut（単位：Byte）：指定インスタンスから送信されたバイト数であり、１インスタンス上の１アプリケーションからのネットワークトラヒック量
本実施形態において、ｗｅｂサーバ装置７０の性能に関する性能情報は、ｗｅｂサーバ装置７０の稼働状態に関する稼働状態情報であるともいえる。
【００３８】
収集部１０１は、ロードバランサ５０によって送信された応答性情報を受信し、受信された応答性情報に基づいて、計測値１４〜１８（応答性情報）を算出し、算出された計測値１４〜１８を推定部１０２へ出力する。
【００３９】
計測値１４〜１８について、図５を参照して説明する。
計測値１４は、ロードバランサ５０とｗｅｂＡＰＬ（ＶＭ）間のＲＴＴ（Round Trip Time）である。
（計測値１４）＝（Latency）
計測値１４が長い場合には、ＤＣ網６０、ｗｅｂサーバ装置７０、ＶＭ及びｗｅｂＡＰＬの少なくとも一つに故障が発生しているおそれがある。
計測値１５は、ｗｅｂＡＰＬのＣＰＵ使用率である。
（計測値１５）＝（CPU Utilization）
計測値１５が大きい場合には、ｗｅｂサーバ装置７０、ＶＭ及びｗｅｂＡＰＬの少なくとも一つに故障が発生しているおそれがある。
計測値１６は、ｗｅｂＡＰＬへのネットワークトラヒック流入量である。
（計測値１６）＝（NetworkIn）
計測値１６が急減した場合には、ユーザ端末装置２、アクセス網２０、ＩＳＰ網３０、インターネット網４０、ＤＣ網６０、ｗｅｂサーバ装置７０及びＶＭの少なくとも一つに故障が発生している、又は、単にトラヒック量が減少しているおそれがある。
計測値１７は、ｗｅｂＡＰＬからのネットワークトラヒック流出量である。
（計測値１７）＝（NetworkOut）
計測値１７が急減した場合には、ユーザ端末装置２、アクセス網２０、ＩＳＰ網３０、インターネット網４０、ＤＣ網６０、ｗｅｂサーバ装置７０、ＶＭ及びｗｅｂＡＰＬの少なくとも一つに故障が発生している、又は、単にトラヒック量が減少しているおそれがある。
計測値１８は、ｗｅｂＡＰＬにおけるトラヒック処理率である。
（計測値１８）＝（NetworkOut）／（NetworkIn）
計測値１８が小さい場合には、ｗｅｂＡＰＬに故障が発生しているおそれがある。
【００４０】
なお、収集部１０１が各計測値０１〜１８を算出する手法に代えて、ユーザ端末装置２及びロードバランサ５０がそれぞれ各計測値０１〜１８を算出して故障被疑箇所推定装置１００へ送信する構成であってもよい。
【００４１】
＜Geolocation APIによる位置情報＞
Geolocation APIは、ユーザ端末装置２の位置情報を計測する手法である。ユーザ端末装置２は、Geolocation APIによって、図５に示す位置情報を計測し、計測結果を故障被疑箇所推定装置１００へ送信する。
・latitude：緯度
・longitude：経度
・altitude：高度
・accuracy：緯度及び経度の誤差
・altitudeAccuracy：高度の誤差
・heading：方角
・speed：速度
【００４２】
≪推定部≫
推定部１０２は、収集部１０１によって収集されて算出された計測値０１〜１８を取得し、取得された計測値０１〜１８に基づいて、故障被疑箇所を推定する。また、推定部１０２は、ネットワーク３が故障被疑箇所であると推定した場合に、収集されたユーザ端末装置２の位置情報に基づいて、ネットワーク３内における故障被疑箇所を絞り込む。かかる故障被疑箇所の推定手法及び絞り込み手法については、以下の動作例で詳細に説明する。
【００４３】
＜動作例＞
続いて、NavigationTiming API及びCloudWatch APIを用いた故障被疑箇所の推定方法（詳細には、計測値の収集後の閾値判定の方法）の一例について、図７及び図８を参照して説明する。なお、推定部１０２は、各計測値０１〜１４を閾値判定することによってＥ２Ｅサービスの品質劣化を検出し、各判定結果の組み合わせによって故障被疑箇所を推定する。推定部１０２は、計測値０１〜１４ごとの閾値を、過去の計測値に基づいて現在の計測値を最尤推定した推定結果に基づいて設定しており、かかる計測値０１〜１４ごとの閾値は、推定部１０２に予め記憶されている。閾値の設定には、各種分布、平均、最頻値（mode）等が利用可能である。すなわち、推定部１０２は、複数のユーザ端末装置２の計測値の計時変化を監視し、図６（ａ）に示すように１つのユーザ端末装置２に関する計測値が急増したり、図６（ｂ）に示すように１つのユーザ端末装置２に関する計測値の他の計測値に対するバランスが崩れたりした場合に、故障被疑箇所があると推定する。なお、以下の動作例では、計測値０７，１７が使用されていないため、これらの計測値０７，１７の収集を省略することも可能である。
【００４４】
図７に示すように、計測値０１が閾値未満である場合（ステップＳ１でＹｅｓ）には、Ｅ２Ｅサービスに遅延は発生していないため、推定部１０２は、サービス正常である（故障被疑箇所なし）と判定する（ステップＳ２）。
【００４５】
一方、計測値０１が閾値以上である場合（ステップＳ１でＮｏ）には、Ｅ２Ｅ（End toEnd）サービスに遅延が発生している。続いて、計測値１４が閾値未満である場合（ステップＳ３でＹｅｓ）には、クラウドネットワーク４内に遅延は発生していないため、推定部１０２は、ユーザ端末装置２及びネットワーク３（アクセス網２０、ＩＳＰ網３０、インターネット網４０及びＤＮＳサーバ装置８０）側に故障被疑箇所があると判定する（ステップＳ４）。
【００４６】
一方、計測値１４が閾値以上である場合（ステップＳ３でＮｏ）には、クラウド（ロードバランサ５０、ＤＣ網６０及びｗｅｂサーバ装置７０）内に遅延が発生しているため、推定部１０２は、クラウド側に故障被疑箇所があると判定する（ステップＳ５）。
【００４７】
ステップＳ５の後、計測値１５が閾値未満である場合（ステップＳ１１でＹｅｓ）には、ｗｅｂサーバ装置７０、ＶＭ（Virtial Machine）及びｗｅｂＡＰＬ（A Programming Language）は正常であるため、推定部１０２は、ＤＣ網６０が故障被疑箇所であると判定する（ステップＳ１２）。
【００４８】
また、計測値１５が閾値以上であり（ステップＳ１１でＮｏ）、計測値１６が閾値未満である場合（ステップＳ１３でＹｅｓ）には、ＣＰＵ使用率が高く、かつ、ｗｅｂＡＰＬへの流入トラヒック量は増加していないため、推定部１０２は、ｗｅｂサーバ装置７０、ＶＭ及びｗｅｂＡＰＬの少なくとも一つが故障被疑箇所であると判定する（ステップＳ１４）。
【００４９】
また、計測値１６が閾値以上であり（ステップＳ１３でＮｏ）、計測値１８が閾値未満である場合（ステップＳ１５でＹｅｓ）には、ｗｅｂＡＰＬへの流入トラヒック量が増加しており、かつ、ｗｅｂＡＰＬの処理率が低下しているため、推定部１０２は、ｗｅｂＡＰＬが故障被疑箇所であると判定する（ステップＳ１６）。
【００５０】
また、計測値１５が閾値以上、計測値１６が閾値以上、かつ、計測値１８が閾値以上である場合（ステップＳ１１，Ｓ１３，Ｓ１５でＮｏ）には、ＣＰＵ使用率が高く、ｗｅｂＡＰＬへの流入トラヒック量が増加し、かつ、ｗｅｂＡＰＬの処理率は正常であるため、推定部１０２は、サービス正常（ユーザ利用が増加した）と判定する（ステップＳ１７）。
【００５１】
なお、ステップＳ１１，Ｓ１３，Ｓ１５における閾値判定は、順序を入れ替えて行われてもよく、並列に行われてもよい。
【００５２】
また、ステップＳ４の後、図８に示すように、計測値０２〜０４，０６，０８，１１〜１３のいずれかがそれぞれの閾値未満である場合（ステップＳ２１でＹｅｓ）には、ユーザ端末装置２内での各処理は正常であるため、推定部１０２は、アクセス網２０、ＩＳＰ網３０、インターネット網４０及びＤＮＳサーバ装置８０の少なくとも一つが故障被疑箇所であると判定する（ステップＳ２２）。
【００５３】
ステップＳ２２の後、計測値０５が閾値未満である場合（ステップＳ２３でＹｅｓ）には、アクセス網２０、ＩＳＰ網３０及びＤＮＳサーバ装置８０は正常であるため、推定部１０２は、インターネット網４０が故障被疑箇所であると判定する（ステップＳ２４）。
【００５４】
また、計測値０５が閾値以上であり（ステップＳ２３でＮｏ）、計測値０９，１０がともにそれぞれの閾値未満である場合（ステップＳ２５でＹｅｓ）には、アクセス網２０及びＩＳＰ網３０は正常であるため、推定部１０２は、ＤＮＳサーバ装置８０が故障被疑箇所であると判定する（ステップＳ２６）。
【００５５】
一方、計測値０５が閾値以上、かつ、計測値０９，１０の閾値のいずれかがそれぞれの閾値以上である場合（ステップＳ２３，Ｓ２５でＮｏ）には、アクセス網２０及びＩＳＰ網３０が異常であるため、推定部１０２は、アクセス網２０、ＩＳＰ網３０及びインターネット網４０の少なくとも一つが故障被疑箇所であると判定する（ステップＳ２７）。
【００５６】
また、計測値０２〜０４，０６，０８，１１〜１３の閾値がともにそれぞれの閾値以上である場合（ステップＳ２１でＮｏ）には、ユーザ端末装置２内での処理のいずれかが異常であるため、推定部１０２は、ユーザ端末装置２が故障被疑箇所であると判定する（ステップＳ２８）。
【００５７】
なお、ステップＳ２３，Ｓ２５における閾値判定は、順序を入れ替えて行われてもよく、並列に行われてもよい。
【００５８】
また、ステップＳ２７の後に、推定部１０２は、アクセス網２０、ＩＳＰ網３０及びインターネット網４０の少なくとも一つが故障被疑箇所であるという判定結果と関連するユーザ端末装置２の位置情報に基づいて、故障被疑箇所を絞り込む（ステップＳ２９）。例えば、推定部１０２は、当該判定結果が得られたユーザ端末装置２の位置情報が、ある地域に集中している場合には、当該地域に対応するアクセス網２０が故障被疑箇所であると推定する。また、推定部１０２は、当該判定結果が得られたユーザ端末装置２の位置情報が広範囲（例えば、複数（２つ，３つ程度）の都道府県に跨る範囲）にわたる場合には、当該広範囲に対応するＩＳＰ網３０が故障被疑箇所であると推定する。また、推定部１０２は、前記以外、すなわち、当該判定結果が得られたユーザ端末装置２の位置情報がさらに広範囲にわたる場合には、インターネット網４０が故障被疑箇所であると推定する。
【００５９】
本発明の実施形態に係る故障被疑箇所推定装置１００及び故障被疑箇所推定方法は、ｗｅｂページ読込時間情報（例えば、NavigationTiming APIによって計測）、応答性情報（例えば、CloudWatch APIによって計測）及び性能情報（例えば、CloudWatch APIによって計測）を用いて通信ネットワーク１における故障被疑箇所を推定するので、複数事業者を跨いだＥ２Ｅサービスや大規模なＥ２Ｅサービスにおいても故障被疑箇所を好適に推定することができる。
また、故障被疑箇所推定装置１００及び故障被疑箇所推定方法は、ｗｅｂサービス以外のサービスに関しても、故障被疑箇所において何らかの影響があると間接的に推定することができる。
【００６０】
また、故障被疑箇所推定装置１００及び故障被疑箇所推定方法は、ネットワーク３が故障被疑箇所である場合にユーザ端末装置２の位置情報に基づいて故障被疑箇所を絞り込むので、故障被疑箇所をより好適に推定することができる。
【００６１】
以上、本発明の実施形態について説明したが、本発明は前記実施形態に限定されず、本発明の要旨を逸脱しない範囲で適宜変更可能である。例えば、ステップＳ１２，Ｓ１４の後にそれぞれステップＳ１３，Ｓ１５へ移行するフローとしたり、ステップＳ２４の後にステップＳ２５へ移行するフローとしたりすることによって、多重の故障被疑箇所をより好適に推定することができる。
また、本発明は、コンピュータを故障被疑箇所推定装置１００として機能させる故障被疑箇所推定プログラムとしても具現化可能である。
【符号の説明】
【００６２】
１      通信ネットワーク
２      ユーザ端末装置
３      ネットワーク
４      クラウドネットワーク
７０    ｗｅｂサーバ装置
１００  故障被疑箇所推定装置
１０１  収集部
１０２  推定部
【図１】
0006471110.tif 000002
【図２】
0006471110.tif 000003
【図３】
0006471110.tif 000004
【図４】
0006471110.tif 000005
【図５】
0006471110.tif 000006
【図６】
0006471110.tif 000007
【図７】
0006471110.tif 000008
【図８】
0006471110.tif 000009