(57)【要約】      （修正有）【課題】異なるクラウドベンダのサーバセンタ内に構築されたサービスシステムを有するサービスシステムに発生したインシデントの原因サービスシステムを推定する。【解決手段】サービスシステムのユーザ端末装置３４、または第１のクラウドサービスの運用者端末装置３０から新規インシデントについての報告または分析依頼があると、インシデント分析装置１３は、そのインシデントに関連するリクエストを抽出して新規インシデント関連リクエストデータベースを生成し、過去のインシデント関連リクエストデータベースを参照して、新規インシデントの原因と推定される原因サービスシステムを特定する。【選択図】図２
2018060332.tif 000002
【特許請求の範囲】
【請求項１】
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理と、
前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理と、
をコンピュータに実行させるインシデント分析プログラム。
【請求項２】
さらに、
前記複数の第１のサービスシステムを発行元とし、前記複数の第２のサービスシステムを発行先とする複数のリクエストを所定のタイミングで発行し、前記発行したリクエストの前記リクエストデータを前記リクエスト管理データベースに追加する処理を有する、請求項１に記載のインシデント分析プログラム。
【請求項３】
前記過去のインシデント関連リクエストデータベースを抽出する処理は、
過去のインシデントについて、インシデント発生元識別情報と、インシデントの現象情報と、インシデントの原因と推定される原因第２サービスシステムとを関連付けたインシデントデータベースから、新規インシデントと同じ発生元第１サービスシステムと、新規インシデントと類似する現象とを有する過去のインシデントを抽出し、
前記抽出した過去のインシデントに対応する前記複数の過去のインシデント関連リクエストデータベースから、前記相関性を有する前記過去のインシデント関連リクエストデータベースを抽出する処理を有する、請求項１に記載のインシデント分析プログラム。
【請求項４】
前記新規インシデント関連リクエストデータベースを生成する処理は、
前記新規インシデントの発生元の第１のサービスシステムを発行元とする第１のリクエストと、前記第１のリクエストの発行先第２サービスシステムを発行先とし前記第１のリクエストを除いた第２のリクエストのリクエストデータであり、且つ前記新規インシデントが発生した時のリクエストデータを、前記リクエスト管理データベースから抽出する処理を有する、請求項１に記載のインシデント分析プログラム。
【請求項５】
前記レスポンス時間の推移傾向は、発行元と発行先が同じ一対のリクエストのレスポンス時間の単位時間に対する変化量を示すレスポンス時間の変化率である、請求項１に記載のインシデント分析プログラム。
【請求項６】
前記相関性は、インシデント発生前と発生後の前記レスポンス時間の変化率の相関性である、請求項５に記載のインシデント分析プログラム。
【請求項７】
前記過去のインシデント関連リクエストデータベースを抽出する処理の前に、
新規インシデント関連リクエストデータベース内の各リクエストデータのレスポンス時間が平均値より閾値以内の場合に正常と、前記平均値より閾値を超える場合に異常と判定し、
正常のリクエストデータと異常のリクエストデータの境界の時刻の前後所定時間内のリクエストデータについて、前記レスポンス時間の変化率を算出する処理を有する、請求項１に記載のインシデント分析プログラム。
【請求項８】
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理と、
前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理と、
を有するインシデント分析方法。
【請求項９】
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理部と、
過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理部と、
前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理部と、
を有するインシデント分析を行う情報処理装置。
【請求項１０】
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とする複数のリクエストを所定のタイミングで発行し、前記発行したリクエストに前記リクエストのレスポンス時間と前記リクエストの時刻とを関連付けたリクエストデータをリクエスト管理データベースに追加する処理と、
前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、前記リクエスト管理データベースから抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
前記新規インシデント関連リクエストデータベースに含まれるリクエストデータのレスポンス時間に基づいて、前記新規インシデントの原因となる第２のサービスシステムを推定する処理と、
をコンピュータに実行させるインシデント分析プログラム。
【請求項１１】
サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得し、
サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得し、
サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定し、
特定した前記原因サービスの識別情報を出力する、
処理をコンピュータに実行させることを特徴とするサービス特定プログラム。
【請求項１２】
サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得し、
サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得し、
サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定し、
特定した前記原因サービスの識別情報を出力する、
サービス特定方法。
【請求項１３】
サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得する第１の取得部と、
サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得する第２の取得部と、
サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定する特定部と、
特定した前記原因サービスの識別情報を出力する出力部とを有するサービス特定装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，インシデント分析プログラム、インシデント分析方法、情報処理装置、サービス特定プログラム、サービス特定方法及びサービス特定装置に関する。
【背景技術】
【０００２】
サービスシステムは、サーバ（または物理マシン）、ストレージ、オペレーティングシステム（OS：Operating System）、アプリケーションの組み合わせで構築される。従来のサービスシステムは、自社内のハードウエア資源を使用して構築されるので、サービスシステムにインシデントが発生した場合、サービスシステム内に発生した全てのメッセージ、エラー内容を解析し、インシデントの発生原因を特定する。
【０００３】
以下の特許文献は、インシデントの検出について開示する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開第２０１４／０３３８９４号
【特許文献２】国際公開第２０１４／０２０９０８号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
クラウドコンピューティングサービス（以下クラウドサービスと称する）の普及に伴い、サービスシステムがクラウドサービスを提供するクラウドサービスベンダ（以下クラウドベンダと称する）のサーバセンタのハードウエア、OS、ミドルウエア等により構築されようになった。特に、サービスシステムが、複数のクラウドベンダのサーバセンタ内に構築した複数のサービスシステムをネットワークで接続して構築されると、発生したインシデントの原因を解析することが困難になる。
【０００６】
例えば、第１のクラウドベンダの第１のサーバセンタ内のサービスシステムでインシデントが発生した場合、第１のクラウドベンダの運用者は、第１のサーバセンタ内のエラー内容を把握できるが、第１のクラウドベンダとは異なる第２のクラウドベンダの第２のサーバセンタ内のエラー内容を把握することは困難である。そのため、インシデントの原因が第２のサーバセンタ内のどのサービスシステムにあるのかを判定することができない。
【０００７】
そこで、一つの側面では、本発明は、異なるクラウドベンダのサーバセンタ内に構築されたサービスシステムを有するサービスシステムに発生したインシデントの原因サービスシステムを推定するインシデント分析プログラム、その方法、およびそれを実行する情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
１つの態様では、第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理と、
前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理と、をコンピュータに実行させるインシデント分析プログラムである。
【発明の効果】
【０００９】
上記の１つの側面によれば、異なるクラウドベンダのサーバセンタ内に構築されたサービスシステムを有するサービスシステムに発生したインシデントの原因サービスシステムを推定することができる。
【図面の簡単な説明】
【００１０】
【図１】異なるクラウドサービスベンダのサーバセンタ内に構築されたサービスシステムの構成例を示す図である。
【図２】第１の実施の形態におけるサービスシステムの構成例を示す図である。
【図３】管理サーバ１０の構成例を示す図である。
【図４】インシデント分析プログラムと各データベースの関係を示す図である。
【図５】本実施の形態におけるインシデント分析プログラムの概略処理を示すフローチャート図である。
【図６】リクエスト発行プログラム２２１によるダミーリクエストについて説明する図である。
【図７】インシデント原因推定プログラムにおける上記の工程S4, S5, S8の詳細なフローチャートを示す図である。
【図８】工程S9の詳細フローチャートを示す図である。
【図９】工程S10の詳細フローチャートを示す図である。
【図１０】工程S11,S12の詳細フローチャートを示す図である。
【図１１】リクエスト管理データベース２４の例を示す図である。
【図１２】インシデントデータベース２６の一例を示す図である。
【図１３】新規インシデント関連リクエストデータベースの例を示す図である。
【図１４】過去のインシデント関連リクエストデータベース２５の一例を示す図である。
【図１５】レスポンス時間の変化率の２つの波形間の相関性を説明する図である。
【図１６】第２の実施の形態におけるインシデント分析プログラムのフローチャート図である。
【図１７】第２の実施の形態における新規インシデント関連リクエストデータベース２５の一例を示す図である。
【発明を実施するための形態】
【００１１】
図１は、異なるクラウドサービスベンダのサーバセンタ内に構築されたサービスシステムの構成例を示す図である。図１には、第1のクラウドサービスベンダのクラウドサービスCS_1のセンタ（サーバセンタ）と、第1のクラウドサービスベンダとは異なる第２のクラウドサービスベンダのクラウドサービスCS_2のセンタ（サーバセンタ）とが示されている。また、図１において、クラウドサービスを利用するクラウドユーザが、クラウドサービスCS_1のサーバセンタ内の物理マシン（物理コンピュータ）PM_0−PM_2に生成した仮想マシンVM0-VM5により構築した３つの第１のサービスシステムS_A,S_B,S_Cと、クラウドサービスCS_2のサーバセンタ内に構築した３つの第２のサービスシステムS_1,S_2,S_3とを、ネットワークNWを介して通信可能に接続してサービスシステムを構築している。また、クラウドサービスCS_1のサーバセンタには、物理マシンや仮想マシンを管理する管理サーバ１０が設けられ、管理サーバ１０は、クラウドサービス管理装置１１やクラウドポータルサイト１２などを提供する。
【００１２】
一例として、クラウドサービスCS_1のサーバセンタ側のサービスシステムS_Aが電子商取引サイトのウエブサービスを提供し、サービスシステムS_Bが電子商取引サイトの顧客管理サイトのウエブサービスを提供し、サービスシステムS_Cが電子商取引サイトの繁忙度管理サイトのウエブサービスを提供する。一方、クラウドサービスCS_2のサーバセンタ側のサービスシステムS_1が電子商取引サイトのためのデータベースサービスを提供し、サービスシステムS_2がロードバランサのサービスを提供し、サービスシステムS_3がサービスシステムS_B,S_Cの監視サービスを提供する。
【００１３】
このようなサービスシステムにおいて、サービスシステムのユーザ端末装置３４は、ネットワークNWを介して、第１のサービスシステムS_A,S_B,S_Cにそれぞれアクセスし、それぞれのサービスを利用する。サービスシステムのユーザ端末装置３４からのアクセスに応答して、各第１のサービスシステムS_A,S_B,S_Cは、第２のサービスシステムであるデータベースシステムS_1、ロードバランサS_2、繁忙度管理サービスS_3などに適宜リクエストを発行し、リクエストの応答に基づいてそれぞれのサービスに必要な処理を実行する。したがって、各第１のサービスシステムS_A,S_B,S_Cが発行するリクエストのレスポンスが遅くなると、各第１のサービスシステムS_A,S_B,S_Cによるサービスシステムのユーザ端末装置３４に対するレスポンスも遅くなる場合がある。
【００１４】
一方、第１のクラウドサービスのユーザ端末３２は、ネットワークNWを介して、クラウドポータルサイト１２にアクセスし、仮想マシンVM0-VM5の生成と起動をクラウドサービス管理装置１１に依頼して、第１のサービスシステムS_A,S_B,S_Cの構築と起動を行う。さらに、第１のクラウドサービスCS_1の運用者端末３０は、ネットワークNWを介してクラウドサービス管理装置１１にアクセスし、第１のサービスシステムS_A,S_B,S_Cの運用管理を行う。運用管理には、サービスシステムS_A,S_B,S_Cで発生したインシデントを分析することなどが含まれる。
【００１５】
一般に、異なるベンダによる２つのクラウドサービスのセンタ間では、互いのクラウドサービスのセンタで生じたエラー情報は互いに公開されず秘密に保たれる。そのため、第１のクラウドサービスCS_1の運用者が、第１のサービスシステムS_A,S_B,S_Cで発生したインシデントを分析する場合、第１のクラウドサービスCS_1のサーバセンタ内の第１のサービスシステムS_A,S_B,S_Cで発生したエラー情報については全て把握することはできるが、第２のクラウドサービスCS_2のサーバセンタ内の第２のサービスシステムS_1,S_2,S_3で発生したエラー情報については把握することはできない。その結果、インシデントの原因となっているサービスシステムを特定することは工数を要するか、または困難もしくは不可能である。
【００１６】
［第１の実施の形態］
図２は、第１の実施の形態におけるサービスシステムの構成例を示す図である。図２の構成例において、図１と異なる構成は、管理サーバ１０がインシデント分析装置１３を有することである。サービスシステムのユーザ端末装置３４から第１のサービスシステムS_A,S_B,S_Cに発生したインシデントについての報告があると、インシデント分析装置１３は、そのインシデントの原因と推定される原因サービスシステムを特定する。第１のクラウドサービスの運用者端末装置３０は、インシデントの報告があると、インシデント分析装置１３にアクセスし、インシデントの分析を依頼する。この分析依頼に応じて、インシデント分析装置１３は、インシデントの原因と推定される原因サービスシステムを特定し、運用者端末装置３０に原因サービスシステムを返信する。
【００１７】
図３は、管理サーバ１０の構成例を示す図である。管理サーバ１０は、プロセッサであるCPU１４と、メインメモリであるRAM１５と、ネットワークNWとのインターフェースデバイス１６と、大容量の補助記憶装置群２０−２６とを有し、それらはバス２８を介して接続される。
【００１８】
補助記憶装置群には、クラウドサービス管理プログラム２０と、インシデント分析プログラム２２と、リクエスト管理データベース２４と、インシデント関連リクエストデータベース２５と、インシデントデータベース２６とを記憶する。クラウドサービス管理プログラム２０と、インシデント分析プログラム２２は、メインメモリ１５に展開されプロセッサ１４により実行される。プロセッサ１４がクラウドサービス管理プログラム２０を実行することで、図２のクラウドサービス管理装置１１が構築される。また、プロセッサがインシデント分析プログラム２２を実行することで、図２のインシデント分析装置１３が構築される。
【００１９】
プロセッサ１４はクラウドサービス管理プログラム２０を実行し、例えば、クラウドサービスのユーザ端末装置３２からの第１のサービスシステムSC_A-SC_Cの起動依頼に応答して、物理マシンPM_0-PM_2のハイパバイザHV_1-HV_2に各サービスシステムを構成する仮想マシンVM0-VM5の起動を実行させる。また、クラウドサービスの運用者端末装置３０からの第１のサービスシステムSC_A-SC_Cの監視依頼に応答して、端末装置３０による各サービスシステムのエラーメッセージの監視を可能にする。
【００２０】
プロセッサ１４はインシデント分析プログラム２２を実行し、例えば、サービスシステムのユーザ端末装置３４からのインシデント報告に応答して、インシデントデータベース２６に新たに発生したインシデントのデータを追加する。また、所定の時間間隔で第１のサービスシステムを発行元とし第２のサービスシステムを発行先とする複数種類のダミーのリクエストを発行し、そのダミーのリクエストに対するレスポンス時間や応答メッセージなどを有するリクエストデータを、リクエスト管理データベース２４に追加する。さらに、クラウドサービスの運用者端末装置３０からのインシデントの原因分析依頼に応答して、インシデント関連リクエストデータベース２５を生成し、新規のインシデントに関連するリクエストの振る舞い（レスポンス時間やメッセージ）に基づいて、原因と推定される第２のサービスシステムを特定する。
【００２１】
図４は、インシデント分析プログラムと各データベースの関係を示す図である。インシデント分析プログラム２２は、クラウドサービスの運用者端末装置３０に対するインシデント管理サイトのインターフェースを提供するインシデント管理インターフェース２２０を有する。このインターフェース２２０は、運用者端末装置３０からのインシデント管理サイトへのアクセスに応答して、インシデント管理画面を提供する。運用者端末装置３０は、このインシデント管理画面において、サービスシステムのユーザ端末装置３４から報告された新規インシデントについての詳細情報を表示する。また、インターフェース２２０は、運用者端末装置３０からの新規インシデント分析依頼に応答して、インシデント原因推定プログラム２２３を呼び出す。
【００２２】
インシデント分析プログラム２２は、リクエスト発行プログラム２２１を有する。プロセッサはリクエスト発行プログラム２２１を実行して、第１のサービスシステムS_A-S_Cを発行元とし第２のサービスシステムS_1-S_3を発行先とするダミーのリクエストを所定時間毎に順次発行する。リクエスト発行プログラム２２１は、順次発行したダミーのリクエストのレスポンス時間を計測し、応答メッセージを取得する。
【００２３】
インシデント分析プログラム２２は、リクエストデータ収集プログラム２２２を有する。プロセッサはリクエストデータ収集プログラム２２２を実行して、ダミーのリクエストを、リクエストの発行元サービスシステム（S_S）と発行先サービスシステム（D_S）と、リクエスト発行時刻(time)と、レスポンス時間（RT)とを関連付けたリクエストデータを収集し、リクエスト管理データベース２４に加える。リクエストデータにはリクエストに対する応答メッセージ（MES）が含まれても良い。
【００２４】
プロセッサはインシデント原因推定プログラム２２３を実行して、リクエスト管理データベース２４から、新規インシデント発生時のリクエストデータを抽出してインシデント関連リクエストデータベース２５を生成する。抽出するリクエストデータは、新規インシデントの発生元サービスシステムの動作に影響を与える可能性のあるものである。動作に影響を与える可能性のあるリクエストデータについては後述する。したがって、インシデント関連リクエストデータベース２５は、新規インシデント発生時のインシデント関連リクエスト群と、過去のインシデント発生時のインシデント関連リクエスト群とを有する。
【００２５】
また、プロセッサはインシデント原因推定プログラムを実行して、新規インシデントが発生すると、そのインシデントの発生時刻(time)と、インシデントの発生元第１サービスシステム（S_S）と、インシデントの現象（PH）とを関連付けたインシデントデータを、インシデントデータベース２６に追加する。このインシデントデータベース２６の各インシデントには、インシデント関連リクエストデータベース２５が対応付けられる。また、インシデントデータベース２６には、過去のインシデントについてはインシデントの原因と推定された原因サービスシステム（CoI）の情報が含まれ、新規のインシデントについては、インシデント原因推定プログラムにより推定された原因サービスシステムの情報が追加される。
【００２６】
図５は、本実施の形態におけるインシデント分析プログラムの概略処理を示すフローチャート図である。図５には、インシデント分析プログラム２２に加えて、サービスシステムのユーザ端末装置３４、クラウド運用者端末装置３０における処理も示されている。
【００２７】
［リクエストデータの収集］
まず、管理サーバ１０のプロセッサは、リクエスト発行プログラム２２１とリクエストデータ収集プログラム２２２を常時実行し、一定時間間隔でダミーのリクエストを発行し（S1）、ダミーリクエストのレスポンス時間と応答メッセージを有するログを出力する（S2）。そして、ダミーリクエストと、その発行元第１のサービスシステムと発行先第２のサービスシステムと、発行時刻と、そのレスポンス時間と、応答メッセージとを関連付けたリクエストデータを収集し、リクエスト管理データベース２４に追加する（S3）。
【００２８】
図６は、リクエスト発行プログラム２２１によるダミーリクエストについて説明する図である。図６においても、図２と同様に第1のクラウドサービスCS_1のサーバセンタには３つの第1のサービスシステムS_A,S_B,S_Cが生成され、第２のクラウドサービスCS_2のサーバセンタには３つの第２のサービスシステムS_1,S_2,S_3が生成され、第１のサービスシステムと第２のサービスシステム間で通信接続される。
【００２９】
また、図６の例では、第１のクラウドサービスCS_1は例えばPaaS（Platform as a Service）であり、第２のクラウドサービスCS_2は例えばIaaS(Infrastructure as a Service)である。但し、第１のクラウドサービスのベンダーと第２のクラウドサービスのベンダーとが異なる場合に、第１のクラウドサービスのベンダーが、第１のサービスシステムで発生したインシデントの原因が、第２のサービスシステムのいずれであるかの推定を行うことが目的であるので、第１、第２のクラウドサービスがPaaSまたはIaaSのいずれでもよい。但し、異なるクラウドサービスベンダが提供するサービスである。
【００３０】
図６の例では、第１のクラウドサービスCS_1で構築された第１のサービスシステムS_Aが、第２のクラウドサービスCS_2で構築された２つの第２のサービスシステムS_1,S_2にリクエストR_A1, R_A2を発行している。また、第１のサービスシステムS_Bが、３つの第２のサービスシステムS_1, S_2, S_3にリクエストR_B1, R_B2, R_B3を発行し、第１のサービスシステムS_Cが１つの第２のサービスシステムS_3にリクエストR_C3を発行している場合を想定する。この場合、３つの第１のサービスシステムが第２のサービスシステムのいずれかに発行しているリクエストが６種類存在する。
【００３１】
そこで、第１のクラウドサービス内のインシデント分析装置１３のインシデント分析プログラム２２は、リクエスト発行プログラム２２１とリクエストデータ収集プログラム２２２とを有する。リクエスト発行プログラム２２１が実行されると、５分毎など一定時間毎に、上記と同じ６種類のダミーリクエストDRを第２のサービスシステムに発行し、各リクエストのレスポンス（応答メッセージとレスポンス時間）のログを出力する。また、リクエストデータ収集プログラム２２２が実行されると、６種類のダミーリクエストの時刻（発行時刻または測定時刻）、発行元サービスシステム、発行先サービスシステム、応答メッセージ、レスポンス時間を関連付けたリクエストデータを収集し、リクエスト管理データベース２４に追加する。
【００３２】
図１１は、リクエスト管理データベース２４の例を示す図である。リクエスト管理データベース２４は、６種類のダミーリクエストの時刻（発行時刻または測定時刻）、発行元サービスシステム名、発行先サービスシステム名、応答メッセージ、レスポンス時間を関連付けたリクエストデータの集合である。図１１の例では、２０１６年５月１２日１０：００に、上記の６種類のダミーリクエストが発行され、その５分後の２０１６年５月１２日１０：０５に、同様の６種類のダミーリクエスト（図１１にはそのうち４種類が示される）が発行されている。そして、時刻１０：００に発行された６種類のダミーリクエストは、応答メッセージが全て成功（Success）であり、レスポンス時間がそれぞれ３，３，２，２，３，４秒と比較的短い。それに対して、５分後の時刻１０：０５に発行された６種類のダミーリクエストは、発行元がサービスシステムS_A、発行先がサービスシステムS_1とS_2の２つのダミーリクエストは応答メッセージが不良リクエスト（Bad Request）で、レスポンス時間が６０秒と比較的長く、発行元がS_B、発行先がS_1,S_2の２つのダミーリクエストは応答メッセージは成功だが、レスポンス時間が１０秒と比較的長くなっている。残りの２つのダミーリクエストの記録は、図１１中省略されている。
【００３３】
このように、リクエスト管理データベースは、発行元サービスシステムと発行先サービスシステムの組み合わせ別に、ダミーのリクエストのリクエストデータを収集する。また、リクエスト発行プログラム２２１とリクエストデータ収集プログラム２２２により、クラウドサービスのユーザシステムによるリクエストの発行とは別に、ダミーのリクエストを定期的に発行することで、ユーザシステムの動作への影響を最小限にとどめながら、第２のクラウドサービスのサーバセンタのサービスシステムの状態をダミーのリクエストの応答情報により収集することができる。
【００３４】
［インシデントデータの収集］
図５に戻り、インシデントの発生が報告されると、インシデント分析プログラム２２のインシデント原因推定プログラム２２３がプロセッサにより実行される。例えば、図５に示される通り、サービスシステムのユーザ端末装置３４から第１のサービスシステムのいずれかでインシデントが発生していることが通知される（S4）。この通知に応答して、プロセッサがインシデント原因推定プログラム２２３を実行し、発生したインシデントに、インシデントの発生時刻と、インシデント発生元サービスシステムと、インシデントの現象とを関連付けたインシデントデータを、インシデントデータベース２６に追加する（S5）。インシデントの現象とは、例えばサービスシステムの動作が遅くなりアクセスに対するレスポンスが遅くなった、アクセスに対して正しくない応答がでる、アクセスに対してエラーが発生するなどである。
【００３５】
［インシデントの原因推定］
一方、クラウドサービスの運用者端末装置３０には、過去のインシデントと新規発生したインシデントのリストが表示される（S6）。運用者端末装置において、運用者が新規発生したインシデントを指定して分析依頼を発行すると（S7）、プロセッサはインシデント原因推定プログラムを実行して、以下の処理を行う。以下の処理は、必ずしも新規のインシデントが発生したときに行う必要はなく、新規のインシデント発生後の所定のタイミングで行われる。但し、新規インシデントが発生した直後に行うことで、その後に発生するインシデントの原因推定に役立てることができるので、発生直後に行うのが好ましい。
【００３６】
［インシデント関連リクエストデータの抽出］
まず、プロセッサはインシデント原因推定プログラムを実行して、リクエスト管理データベース２４から、新規インシデントの発生元の第１のサービスシステムに関連するリクエストデータであり且つ新規インシデントが発生した時（発生した時間帯）のリクエストデータを抽出し、インシデント関連リクエストデータベース２５を生成する（S8）。
【００３７】
図７は、インシデント原因推定プログラムにおける上記の工程S4, S5, S8の詳細なフローチャートを示す図である。前述のとおり、新規インシデントが発生すると（S4）、プロセッサはインシデント原因推定プログラムの実行により、発生後の所定のタイミングで、新規インシデントのデータをインシデントデータベース２６に追加する（S5）。
【００３８】
図１２は、インシデントデータベース２６の一例を示す図である。図１２の例は、インシデント番号が００００１が新規インシデントのデータであり、インシデント番号００００２，０００００３が過去のインシデントのデータである。各インシデントデータは、その発生日時と、インシデントの発生元サービス名と、インシデントの現象とが関連付けられる。インシデントの原因と推定される原因サービスは、過去のインシデントでは推定されるサービス名が記録されているが、新規のインシデント（００００１）には未分析であるので未記録である。また、各インシデントに関連するリクエストデータベースが、リクエストデータベース内のリクエストデータの時間帯情報により各インシデントに関連付けられている。
【００３９】
図１２の例は、全てのインシデントデータが、発生元サービス名がS_Aであり、現象が「S_Aのレスポンスが悪化しました。」である。つまり、サービスシステムの利用者がサービスシステムS_Aを利用中にアクセスに対するレスポンスが悪化した現象を見出し、「S_Aのレスポンスが悪化した」という現象のインシデントを報告した例である。また、過去のインシデント（００００２）で推定された原因サービスがS_1であり、過去のインシデント（００００３）で推定された原因サービスがS_1、S_2である。
【００４０】
図７に戻り、プロセッサはインシデント原因推定プログラムの実行により、リクエスト管理データベースから、新規インシデントが発生した時間帯（発生時の前後約１時間）のリクエストデータであり、新規インシデントの発生元のPaaS側サービスシステムと関連するIaaS側サービスシステムを抽出する（S8_1）。つまり、新規インシデントの発生元サービスシステムを発行元とするリクエストの発行先サービスシステムの情報を抽出する。図１２の例では、新規インシデントの発生元PaaS側サービスシステムはS_Aであるので、図１１の例では、サービスシステムS_Aを発行元とするリクエストの発行先サービスシステムS_1, S_2が抽出される。
【００４１】
さらに、プロセッサは、リクエスト管理データベースから、上記抽出したIaaS側サービスシステム（S_1）と関連するPaaS側サービスシステムを抽出する（S8_2）。つまり、抽出したサービスシステムを発行先とするリクエストの発行元サービスシステムS_A,S_Bを抽出する。図１１の例では、サービスシステムS_1, S_2を発行先とするリクエストの発行元サービスシステムS_A, S_Bが抽出される。
【００４２】
そして、プロセッサは、リクエスト管理データベース２４から、インシデントの発生元のPaaS側サービス（S_A）と、抽出したPaaS側サービス（S_A,S_B）及びIaaS側サービス（S_1,S_2）に関連するリクエストデータを抽出して、新規インシデント関連リクエストデータベース２５を生成する（S8_3）。
【００４３】
上記の抽出されたリクエストデータについて説明すると、図６の例において、新規インシデントが発生したサービスシステムS_Aを発行元とするリクエストはリクエストR_A1,R_A2の２種類である。この２種類のリクエストのレスポンスは、新規インシデントの直接の原因になる可能性がある。そして、これら２種類のリクエストの発行先サービスシステムS_1, S_2を発行先とするリクエストはリクエストR_B1, R_B2の２種類である。この２種類のリクエストは、それぞれサービスシステムS_1,S_2の動作に影響を与える可能性があり、新規インシデントの原因となるIaaS側のサービスシステムの分析に必要なリクエストである。
【００４４】
そして、仮にリクエストR_A1とR_B1のレスポンスに問題が生じていて、リクエストR_A2とR_B2のレスポンスに問題が生じていなければ、IaaS側のサービスシステムS_1に原因があると推定することができる。または、仮にリクエストR_A1とR_A2のレスポンスに問題が生じていて、リクエストR_B1とR_B2のレスポンスに問題が生じていないと、PaaS側のサービスシステムS_Aに何らかの原因があると推定することができる。このように、プロセッサは、新規インシデントの原因と推定されるサービスシステムを絞り込むに必要なダミーリクエストのリクエストデータを、新規インシデントの時間帯に絞ってリクエスト管理データベース２４から抽出して、新規インシデント関連リクエストデータベース２５を生成する。
【００４５】
図１３は、新規インシデント関連リクエストデータベースの例を示す図である。前述のとおり、新規インシデントの発生元がPaaS側のサービスシステムS_Aであったので、新規インシデントが発生した時間２０１６年５月１２日１０：０５前後約１時間内の４種類のリクエストR_A1, R_A2, R_B1, R_B2のリクエストデータが、リクエスト管理データベース２４（図１１）から抽出され、新規インシデント関連リクエストデータベース２５（図１３）が生成される。
【００４６】
図１３の新規インシデント関連リクエストデータベース２５には、レスポンス変化率と異常判断の欄（コラム）があるが、これらの欄の情報は、新規インシデント関連リクエストデータベース２５を生成した後に、適宜計算または判断されて記憶される。したがって、新規インシデント関連リクエストデータベースを生成した工程S8では、これらの欄の情報は未だ記憶されていない。
【００４７】
［各リクエストデータの正常、異常判定］
図５に戻り、プロセッサはインシデント原因推定プログラムの実行により、新規インシデント関連リクエストデータベースの各リクエストデータのレスポンス時間が、新規インシデント発生時前後（約１時間）で収集している同じ発行元発行先リクエストのレスポンス時間の平均値より所定閾値を超える場合は異常状態、平均値より所定閾値内の場合は正常状態と判定する（S9）。前記のレスポンス時間の平均値は、同じ発行元発行先のリクエスト毎に算出される。また、レスポンス時間の平均値は、直前の正常時に収集したレスポンス時間の平均値でもよい。
【００４８】
図８は、工程S9の詳細フローチャートを示す図である。プロセッサはインシデント原因推定プログラムの実行により、図１３の新規インシデント関連リクエストデータベース２５内の全てのリクエストデータに対して、次の処理を実行する。すなわち、各レスポンス時間が、常時収集している同じ発行先発行元リクエストのレスポンス時間の平均値より所定閾値超えているか、またはレスポンスメッセージが不良（Bad）か否かを判定する（S9_1）。いずれかがYESであれば、そのリクエストデータは異常と判定し（S9_2）、いずれもNOであれば、そのリクエストデータは正常と判定する（S9_3）。そして、判定した正常または異常を、図１３に示す通り、リクエストDB２５の異常判定の欄に記録する（S9_4）。
【００４９】
図１３には、時刻２０１６／５／１２、１０：００以前のリクエストデータは正常、１０：０５以降のリクエストデータは異常と記録されている。この判定から、インシデントの発生時刻が１０：００〜１０：０５の間であると推定できる。この推定されたインシデント発生時刻に基づいて、後述する新規インシデントと過去のインシデントのインシデント関連レスポンスDBにおける各リクエスト毎に（同じ発行元発行先リクエスト毎に）、レスポンス時間の推移傾向、例えばレスポンス時間の変化率の相関性が判定される。
【００５０】
［レスポンス変化率の算出］
図５に戻り、プロセッサはインシデント原因推定プログラムの実行により、新規インシデント関連リクエストデータベース２５の発行元と発行先が同じリクエストのレスポンス時間の変化率を算出する（S10）。
【００５１】
図９は、工程S10の詳細フローチャートを示す図である。プロセッサは、新規インシデント関連リクエストデータベース２５（図１３）内の、インシデント発生推定時刻前後の所定時間（約１０分：例えば２セットのリクエストデータ）のリクエストデータに対して、以下の処理を行ってレスポンス時間の変化率を算出する。まず、プロセッサは、同じリクエスト発行元サービスシステムとリクエスト発行先サービスシステムのリクエストのペアで、時間的に隣接するペアを検出する（S10_1）。図１３の例では、例えば、発行元サービスシステムS_B、発行先サービスシステムS_1のリクエストで、時刻１０：００と１０：０５のリクエストのペアを検出する。
【００５２】
そして、プロセッサは、検出したペアのリクエストのレスポンス時間の変化率を算出する（S10_2）。レスポンス時間の変化率は、ペアのリクエストのレスポンス時間の差分を時間差で除算して求める。図１３中○を記した２つのレスポンス時間の場合は、レスポンス時間の変化率は、
変化率＝（１０−２）／（１０：０５−１０：００）＝１．６s/min
である。したがって、変化後のリクエストデータのレスポンス変化率の欄に、算出した１．６が記録される（S10_3）。図１３のレスポンス変化率の欄の値は、上記と同様に算出された値である。例えば、時刻１０：００の４つのリクエストデータのレスポンス変化率は、図示されていない時刻９：５５の４つのリクエストデータのレスポンス時間からの変化率である。一方、時刻１０：０５の４つのリクエストデータのレスポンス変化率の値は、時刻１０：００の４つのリクエストデータのレスポンス時間からの変化率である。
【００５３】
［類似する過去のインシデントの検出］
図５に戻り、プロセッサはインシデント原因推定プログラムの実行により、新規インシデントと同じ発生元サービスシステムで、同じ現象を有する過去のインシデントを、インシデントデータベース２６から抽出する（S11）。さらに、プロセッサは、抽出した過去のインシデントのうち、新規インシデントのレスポンス時間の変化率が相関性を有する（例えば類似する）過去のインシデントを検出する（S12）。この相関性は、同じ発行元発行先のリクエストの相関性であり、インシデント発生時刻を基準にして新規インシデントと過去のインシデントのリクエスト間を対応付けて算出される相関性である。
【００５４】
図１０は、工程S11,S12の詳細フローチャートを示す図である。プロセッサはインシデント原因推定プログラムの実行により、インシデントデータベース２６から、新規インシデントと同じ発生元サービスシステムで、同じまたは類似する現象を有する過去のインシデントを抽出する（S11_1）。このとき、類似する現象を有する過去のインシデントがあれば（S11_2のYES）、プロセッサは、新規インシデントと過去のインシデントのレスポンス変化率（レスポンス時間の変化率）の相関を計算する（S12_1）。
【００５５】
図１４は、過去のインシデント関連リクエストデータベース２５の一例を示す図である。この例は、時刻２０１６年５月１０日９：００〜９：０５の時間帯のリクエストデータベースである。前述のとおり、インシデントデータベースからインシデント発生元のサービスシステムが同じ過去のインシデントを抽出しているので、過去のインシデントに関連付けられたインシデント関連リクエストデータベースには、新規インシデント関連リクエストデータベース（図１３）と同じ４種類のリクエストのデータが記憶されている。
【００５６】
次に、新規インシデントと過去のインシデントのレスポンス変化率（レスポンス時間の変化率）の相関の計算は、例えば、以下のような相関係数の計算である。
相関係数＝［｛Σ（F(k)-F'）(G(k)-G')｝/n］÷[√｛Σ（F(k)-F'）2/n｝√｛Σ（G(k)-G'）2/n｝]
ここで、除数の２つのルート（√）はそれぞれ｛Σ（F(k)-F'）2/n｝、｛Σ（G(k)-G'）2/n｝の平方根である。また、ｎはサンプル数、Σはｎ個のサンプルの累積、F'、G'は平均値である。
【００５７】
具体的に説明すると、図１３の新規インシデント関連リクエストデータベースの発行元S_B、発行先S_1のリクエストの隣接時間のペアのレスポンス変化率は「０．４」と「１．６」であり、図１４の過去のインシデント関連リクエストデータベースの同じ発行元S_B、発行先S_1のリクエストの隣接時間のペアのレスポンス変化率も「０．４」と「１．６」である。この場合、上記相関係数の式によって算出される相関係数は「１．０」になり、相関係数は非常に高くなる。
【００５８】
上記の相関係数は、２つの波形の各サンプル点での値について算出して２つの波形の相関性を求めるものであり、一般に、相関係数が０．４−０．７であれば高い相関があり、０．７−１．０であればかなり高い相関があるとされている。
【００５９】
図１５は、レスポンス時間の変化率の２つの波形間の相関性を説明する図である。例えば、実線が新規のインシデントのある発行元・発行先リクエストのレスポンス時間の変化率の波形を示し、破線が過去のインシデントの同じ発行元・発行先リクエストのレスポンス時間の変化率の波形を示す。各サンプル点で変化率が変動している。
【００６０】
そして、前述の判定工程S9で正常と判定された最後のサンプル点SPL1と異常と判定された最初のサンプル点SPL2の間がインシデントの推定発生時刻と見なして、推定発生時刻を基準にして対応付けた前後複数のサンプル点での変化率について、上記の相関係数の式により両波形の相関性を求める。
【００６１】
例えば、インシデントの類似性に最も影響を与えると考えられるサンプル点SPL1とSPL2のレスポンス時間の変化率が一致または類似すれば、２つのインシデントの波形は相関性が高いと判定する。さらに、サンプル点SPL1以前の正常時のレスポンス時間の変化率の波形や、サンプル点SPL2以降の異常時のレスポンス時間の変化率の波形が一致または類似するか否かを判定することで、類似する過去にインシデントの抽出精度をより高くすることができる。
【００６２】
このようにインシデント発生時刻を基準にして２つのインシデントの対応するリクエスト間でそのレスポンス時間の変化率の時間に対する波形（パターン）が類似するか否かを、相関値が高いか否かで判定する。
【００６３】
ここで、図１３の新規インシデント関連リクエストDBと図１４の過去のインシデント関連リクエストDBのレスポンス時間とレスポンス時間の変化率について説明する。
【００６４】
図１３の新規インシデント関連リクエストDBでは、各リクエストデータのレスポンス時間は、「３，３，２，２，６０，６０，１０，１０」となっている。これに対して、図１４の過去のインシデント関連リクエストDBでは、「６，６，４，４，６３，６３，１２，１２」である。この例では、たとえば、過去のインシデントが発生した時間帯２０１６年５月１０日９：００−９：０５での各リクエストのレスポンス時間は長かったが、その後、ロードバランサがIaaS側のサービスシステムS_1,S_2に対してスケールアウトを実行し、各サービスシステムの仮想マシン数を増大した結果、新規インシデント発生時間帯の２０１６年5月１２日１０：００−１０：０５でのレスポンス時間は短くなっている。
【００６５】
しかし、両インシデントの発生元のサービスシステムは同じであり現象も同じである一方、レスポンス時間は異なるが、レスポンス時間の変化率の波形は類似している。このような場合、本実施の形態では、両インシデントは同じ原因サービスシステムに起因して発生した類似のインシデントと判定する。このように、クラウドサービスにおいて構築されたサービスシステムの一つの特徴として、ロードバランサが適宜スケールアウトを実施してレスポンス時間を短くしたり、スケールイン（仮想マシン数を減少させる）を実施してレスポンス時間を長くしたりする。したがって、両インシデントの相関性をチェックする際、レスポンス時間そのものの相関性よりもレスポンス時間の変化率の相関性をチェックすることが、ロードバランサの制御による影響を薄めることができ、好ましい。
【００６６】
また、相関性の計算において、新規インシデントと過去のインシデントとで４種類のダミーリクエストのレスポンス時間の変化率それぞれについて相関性を算出して、類似する過去のインシデントを検出するようにしてもよい。
【００６７】
図５に戻り、プロセッサがインシデント原因推定プログラムを実行することで、新規インシデントのレスポンス時間の変化率が相関する過去のインシデントを検出すると（S12）、インシデントDBを参照し、検出した過去のインシデントに対して特定されている原因サービスシステムの情報を抽出し、インシデント管理インターフェースが、その原因サービスシステムを新規インシデントの推定される原因サービスシステムとして表示し、運用者に分析依頼の回答を行う（S13）。
【００６８】
図１２、図１３、図１４の例によれば、図１２のインシデントデータベースのインシデント番号００００２が、新規インシデント００００１とレスポンス時間の変化率について相関性があると判定され、インシデント番号００００２の過去のインシデントの原因サービスシステムS_1が、新規インシデントの原因として推定される。そして、インシデントデータベース２６内の新規インシデント００００１に対し推定された原因サービスシステムの情報が記憶される。
【００６９】
以上、第１の実施の形態によれば、管理サーバのインシデント分析装置が、第１のクラウドサービスの第１のサービスシステムから第２のクラウドサービスの第２のサービスシステム宛てのダミーリクエストを所定時間毎に発行し、ダミーリクエストに発行元と発行先情報及びその応答メッセージやレスポンス時間、発行時刻を関連付けたリクエストデータをリクエスト管理DBに追加する。そして、インシデントが発生すると、インシデント発生時間帯のインシデント発生元のサービスシステムに関連するリクエストデータをリクエスト管理DBから抽出して、新規インシデント関連リクエストDBを生成する。そして、過去のインシデントのうち、新規インシデントのダミーリクエストのレスポンス時間の変化率が相関する過去のインシデントを検出し、その過去のインシデントの原因サービスシステムを新規インシデントの原因と推定する。
【００７０】
クラウドサービスの一つの特徴として各サービスシステムの構成が時間の経過と共に変化する。本実施の形態では、そのようなサービスシステムの構成変更によるレスポンス時間の変動を考慮して、レスポンス時間の変化率の相関性により、インシデント間の相関性をチェックする。
【００７１】
［第１の実施の形態の変形例］
第１の実施の形態の変形例として、新規インシデントと類似する過去のインシデントの特定処理において、それぞれのインシデント関連リクエストデータ内の同じ発行元発行先リクエスト間で、レスポンス時間の変化率の相関性が高いことに加えて、応答メッセージが同じ、正常・異常の判定結果が同じであることも判定基準に加えても良い。さらに、複数の発行元発行先リクエストそれぞれについて、上記の判定基準で相関性を有するか否かを判定しても良い。
【００７２】
［第２の実施の形態］
図１６は、第２の実施の形態におけるインシデント分析プログラムのフローチャート図である。第２の実施の形態では、プロセッサがインシデント分析プログラムを実行して、第１のクラウドサービスCS_1の第１のサービスシステムS_A, S_B, S_Cから第２のクラウドサービスCS_2の第２のサービスシステムS_1,S_2,S_3宛てのダミーリクエストを所定時間毎に発行し(S1)、ダミーリクエストに発行元と発行先情報及びその応答メッセージやレスポンス時間、発行時刻を関連付けたリクエストデータをリクエスト管理DBに追加する(S3)。この点は、第１の実施の形態と同様である。
【００７３】
そして、新規インシデントの発生が報告されると（S4）、プロセッサはインシデントデータベース２６に新規インシデントのデータを追加する（S5）。さらに、クラウドサービスの運用者端末装置３０がインシデントリストの表示画面（S6）から新規インシデントを指定してそのインシデントの分析依頼を受信すると（S7）、プロセッサはインシデント原因推定プログラムを実行して、新規インシデントについてインシデント関連リクエストデータベース２５を生成する（S8）。新規インシデント関連リクエストデータベースの生成は、第１の実施の形態と同様である。
【００７４】
さらに、プロセッサは、新規インシデント関連リクエストデータベースの各リクエストのレスポンス時間が、平均値より閾値を超えている場合は異常、閾値以内であれば正常と判定し、判定結果をデータベースに追加する（S9）。この処理も第１の実施の形態の処理と同様である。
【００７５】
最後に、プロセッサは、新規インシデント関連リクエストデータベースの各リクエストのレスポンス時間、応答メッセージ、正常・異常判定結果に基づいて、インシデントの原因となっている第２のサービスシステムを推定する（S20）。そして、インシデント管理インターフェースにより推定された原因サービスを表示する（S13）。
【００７６】
図１７は、第２の実施の形態における新規インシデント関連リクエストデータベース２５の一例を示す図である。この例によれば、時刻１０：０５以降のリクエストにレスポンスメッセージが「Bad Request」になったり、レスポンス時間が平均値より閾値を超えるほど異なり異常判定が異常になったりしたものが存在する。具体的にはリクエスト発行元と発行先のサービスシステムの組み合わせが、S_AとS_１、S_BとS_1は異常である。一方、リクエスト発行元と発行先の組み合わせが、S_AとS_2、S_BとS_2は正常である。
【００７７】
このような場合、インシデント原因推定プログラムを実行するプロセッサは、サービスシステムS_1に何らかの問題が発生し、新規インシデントの原因サービスシステムであると推定する。
【００７８】
同様に、応答メッセージが「Bad Request」のリクエストの発行元と発行先に基づいて、上記と同様の解析をして、新規インシデントの原因サービスシステムを推定してもよい。
【００７９】
以上の通り、第２の実施の形態では、他人の第２のクラウドサービスで構築された第２のサービスシステムのエラー情報や動作情報を入手できなくても、自分の第１のクラウドサービスのインシデント分析装置が発行元を第１のサービスシステムとし発行先を第２のサービスシステムとするダミーのリクエストを所定時間毎に発行し、その応答情報を含むリクエストデータをリクエスト管理データベースに蓄積する。そして、インシデントが発生した場合、インシデント発生元のサービスシステムに影響を与えるリクエストデータを抽出し、分析することで、インシデントの原因と推定される第２のサービスシステムを特定する。
【００８０】
上記のインシデント分析プログラム、同方法、同装置は、いずれも原因となるインシデントを特定するプログラム、同方法、同装置に対応する。
【００８１】
以上の実施の形態をまとめると，次の付記のとおりである。
【００８２】
（付記１）
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理と、
前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理と、
をコンピュータに実行させるインシデント分析プログラム。
【００８３】
（付記２）
さらに、
前記複数の第１のサービスシステムを発行元とし、前記複数の第２のサービスシステムを発行先とする複数のリクエストを所定のタイミングで発行し、前記発行したリクエストの前記リクエストデータを前記リクエスト管理データベースに追加する処理を有する、付記１に記載のインシデント分析プログラム。
【００８４】
（付記３）
前記過去のインシデント関連リクエストデータベースを抽出する処理は、
過去のインシデントについて、インシデント発生元識別情報と、インシデントの現象情報と、インシデントの原因と推定される原因第２サービスシステムとを関連付けたインシデントデータベースから、新規インシデントと同じ発生元第１サービスシステムと、新規インシデントと類似する現象とを有する過去のインシデントを抽出し、
前記抽出した過去のインシデントに対応する前記複数の過去のインシデント関連リクエストデータベースから、前記相関性を有する前記過去のインシデント関連リクエストデータベースを抽出する処理を有する、付記１に記載のインシデント分析プログラム。
【００８５】
（付記４）
前記新規インシデント関連リクエストデータベースを生成する処理は、
前記新規インシデントの発生元の第１のサービスシステムを発行元とする第１のリクエストと、前記第１のリクエストの発行先第２サービスシステムを発行先とし前記第１のリクエストを除いた第２のリクエストのリクエストデータであり、且つ前記新規インシデントが発生した時のリクエストデータを、前記リクエスト管理データベースから抽出する処理を有する、付記１に記載のインシデント分析プログラム。
【００８６】
（付記５）
前記レスポンス時間の推移傾向は、発行元と発行先が同じ一対のリクエストのレスポンス時間の単位時間に対する変化量を示すレスポンス時間の変化率である、付記１に記載のインシデント分析プログラム。
【００８７】
（付記６）
前記相関性は、インシデント発生前と発生後の前記レスポンス時間の変化率の相関性である、付記５に記載のインシデント分析プログラム。
【００８８】
（付記７）
前記過去のインシデント関連リクエストデータベースを抽出する処理の前に、
新規インシデント関連リクエストデータベース内の各リクエストデータのレスポンス時間が平均値より閾値以内の場合に正常と、前記平均値より閾値を超える場合に異常と判定し、
正常のリクエストデータと異常のリクエストデータの境界の時刻の前後所定時間内のリクエストデータについて、前記レスポンス時間の変化率を算出する処理を有する、付記１に記載のインシデント分析プログラム。
【００８９】
（付記８）
前記過去のインシデント関連リクエストデータベースを抽出する処理は、
前記境界の時刻の前後所定時間内の複数のリクエストデータの前記レスポンス変化率の時間に対するパターンが類似する場合、所定の相関性を有すると判定する処理を有する、付記６に記載のインシデント分析プログラム。
【００９０】
（付記９）
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理と、
前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理と、
を有するインシデント分析方法。
【００９１】
（付記１０）
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理部と、
過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理部と、
前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理部と、
を有するインシデント分析を行う情報処理装置。
【００９２】
（付記１１）
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とする複数のリクエストを所定のタイミングで発行し、前記発行したリクエストに前記リクエストのレスポンス時間と前記リクエストの時刻とを関連付けたリクエストデータをリクエスト管理データベースに追加する処理と、
前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、前記リクエスト管理データベースから抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
前記新規インシデント関連リクエストデータベースに含まれるリクエストデータのレスポンス時間に基づいて、前記新規インシデントの原因となる第２のサービスシステムを推定する処理と、
をコンピュータに実行させるインシデント分析プログラム。
【００９３】
（付記１２）
前記新規インシデント関連リクエストデータベースを生成する処理は、
前記新規インシデントの発生元の第１のサービスシステムを発行元とする第１のリクエストと、前記第１のリクエストの発行先第２サービスシステムを発行先とし前記第１のリクエストを除いた第２のリクエストとを有し、さらに前記新規インシデントが発生した時のリクエストデータを、前記リクエスト管理データベースから抽出する処理を有する、付記１１に記載のインシデント分析プログラム。
【００９４】
（付記１３）
サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得し、
サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得し、
サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定し、
特定した前記原因サービスの識別情報を出力する、
処理をコンピュータに実行させることを特徴とするサービス特定プログラム。
【００９５】
（付記１４）
サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得し、
サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得し、
サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定し、
特定した前記原因サービスの識別情報を出力する、
サービス特定方法。
【００９６】
（付記１５）
サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得する第１の取得部と、
サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得する第２の取得部と、
サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定する特定部と、
特定した前記原因サービスの識別情報を出力する出力部とを有するサービス特定装置。
【００９７】
上記付記１３，１４，１５の「サービス」はサービスシステムに、「要求」はリクエストにそれぞれ対応する。また、「サービスが発行した要求に対する応答時間に関するインシデント」とは、サービスシステムが発行したリクエストの応答時間が長くなったインシデントに対応する。そして、「サービスの識別情報」及び「出力された前記サービスの識別情報」は、要求を発行したサービスの識別情報に対応する。
【符号の説明】
【００９８】
CS_1：第１のクラウドサービス（第１のサーバセンタ）
CS_2：第２のクラウドサービス（第２のサーバセンタ）
１０：管理サーバ
１１：クラウドサービス管理装置
１２：クラウドポータルサイト
１３：インシデント分析装置
３０：クラウドサービスCS_1の運用者端末装置
３２：クラウドサービスCS_1のユーザ端末装置
３４：サービスシステムのユーザ端末
ＮＷ：ネットワークシステム
２０：クラウドサービス管理プログラム
２２：インシデント分析プログラム
２２０：インシデント管理インターフェース
２２１：リクエスト発行プログラム
２２２：リクエストデータ収集プログラム
２２３：インシデント原因推定プログラム
２４：リクエスト管理データベース（DB）
２５：インシデント関連リクエストデータベース（DB）
２６：インシデントデータベース（DB）
R_A1：リクエスト
DR：ダミーリクエスト
【図１】
2018060332.tif 000003
【図２】
2018060332.tif 000004
【図３】
2018060332.tif 000005
【図４】
2018060332.tif 000006
【図５】
2018060332.tif 000007
【図６】
2018060332.tif 000008
【図７】
2018060332.tif 000009
【図８】
2018060332.tif 000010
【図９】
2018060332.tif 000011
【図１０】
2018060332.tif 000012
【図１１】
2018060332.tif 000013
【図１２】
2018060332.tif 000014
【図１３】
2018060332.tif 000015
【図１４】
2018060332.tif 000016
【図１５】
2018060332.tif 000017
【図１６】
2018060332.tif 000018
【図１７】
2018060332.tif 000019