(57)【要約】      （修正有）【課題】間接的に利用するサービスが存在する場合でもサービスの依存関係を明確にする情報処理装置、サービスシステム及びプログラムを提供する。【解決手段】サービス監視サーバ１０は、ネットワーク上のサービスサーバ間で送受信されるメッセージを検出し、そのメッセージの送信元となるサービスと送信先となるメッセージの組をメッセージの種類毎に種別毎サービス利用関係テーブルに登録することで所定時間内にあるサービスが他のサービスの利用回数を得るメッセージ解析部１１と、種別毎サービス利用関係テーブルを集約することで、サービスの提供に際しどのサービスがどのサービスを利用するのか、そのサービスの依存関係を示す依存関係情報を生成する依存関係情報生成部１２と、依存関係情報を管理者端末に表示させる情報提示部１３と、を有する。【選択図】図３
2018041251.tif 000002
【特許請求の範囲】
【請求項１】
サービスを提供するサーバ間で送受信されるメッセージを検出し、検出したメッセージから当該メッセージの送信元となるサービスと当該メッセージの送信先となるサービスとを抽出する抽出手段と、
前記抽出手段により抽出されたメッセージの送信元と送信先の組を集約することで各サービスの依存関係を示す依存関係情報を生成する依存関係情報生成手段と、
前記依存関係情報の表示の制御を行う表示制御示手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記抽出手段により抽出されたメッセージの送信元と送信先の組を、同一の送信元及び送信先毎に集計してサービス利用関係情報を生成するサービス利用関係情報生成手段を有し、
前記依存関係情報生成手段は、サービス利用関係情報に基づいて依存関係情報を生成することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記サービス利用関係情報生成手段は、検出したメッセージを種類毎に分類してサービス利用関係情報を生成することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記サービス利用関係情報生成手段は、１又は複数のサービスを利用する業務の業務フロー情報を解析することで同一業務において利用される一のサービスを送信元、他のサービスを送信先としてサービス利用関係情報を生成することを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記依存関係情報生成手段は、前記サービス利用関係情報に基づいて他のサービスの提供に影響を与える影響度をサービス毎に算出して依存関係情報に含めることを特徴とする請求項２に記載の情報処理装置。
【請求項６】
いずれかのサービスの提供が停止した場合、前記依存関係情報を参照することにより、停止したサービスに依存するサービスの管理者に対して当該停止したサービスの停止を通知する通知手段を有することを特徴とする請求項１に記載の情報処理装置。
【請求項７】
前記依存関係情報を参照することにより、各サービスの品質を示す指標値を自動修正する修正手段を有することを特徴とする請求項１に記載の情報処理装置。
【請求項８】
前記依存関係情報を参照することにより、サービスを起動させる順番を定義する起動順番情報を自動生成する起動順番情報生成手段を有することを特徴とする請求項１に記載の情報処理装置。
【請求項９】
サービスを提供する複数のサーバと、
情報処理装置と、
表示装置と、
を有し、
前記情報処理装置は、
前記サーバ間で送受信されるメッセージを検出し、検出したメッセージから当該メッセージの送信元となるサービスと当該メッセージの送信先となるサービスとを抽出する抽出手段と、
前記抽出手段により抽出されたメッセージの送信元と送信先の組を集約することで各サービスの依存関係を示す依存関係情報を生成する依存関係情報生成手段と、
要求に応じて前記依存関係情報を前記表示装置へ送信する送信手段と、
を有することを特徴とするサービスシステム。
【請求項１０】
コンピュータを、
サービスを提供するサーバ間で送受信されるメッセージを検出し、検出したメッセージから当該メッセージの送信元となるサービスと当該メッセージの送信先となるサービスとを抽出する抽出手段、
前記抽出手段により抽出されたメッセージの送信元と送信先の組を集約することで各サービスの依存関係を示す依存関係情報を生成する依存関係情報生成手段、
前記依存関係情報の表示の制御を行う表示制御示手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、サービスシステム及びプログラムに関する。
【背景技術】
【０００２】
サービスを新規に構築、運用する際、ユーザ認証サービスや顧客管理システム等様々な既存サービスを利用する場合がある。また、利用される既存サービスも他の既存サービスを利用する場合がある。つまり、サービスを提供するに際し利用関係にあるのは、直接利用するサービスだけでなく間接的に利用するサービスも存在しうる。従って、サービスを問題なく提供できるかどうかは、直接及び間接的に利用する他のサービスの状態に依存することになる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１１−０３９７４０号公報
【特許文献２】特開２００１−２１７２８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
前述したように、サービスを提供するに際し、当該サービスと依存関係にあるサービスが停止した場合、当該サービスは通常通りに提供できなくなる。当該サービスがどのサービスを直接利用しているのかは把握できるため、その直接利用するサービスが停止した場合でも、そのサービスの停止には比較的容易に対処可能である。
【０００５】
しかしながら、従来においては、全てのサービスの依存関係については把握しきれないため、当該サービスが間接的に利用しているサービスが停止した場合、当該サービスの提供に影響を及ぼしてしまう可能性があった。
【０００６】
本発明は、間接的に利用するサービスが存在する場合でもサービスの依存関係を明確にすることを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係る情報処理装置は、サービスを提供するサーバ間で送受信されるメッセージを検出し、検出したメッセージから当該メッセージの送信元となるサービスと当該メッセージの送信先となるサービスとを抽出する抽出手段と、前記抽出手段により抽出されたメッセージの送信元と送信先の組を集約することで各サービスの依存関係を示す依存関係情報を生成する依存関係情報生成手段と、前記依存関係情報の表示の制御を行う表示制御示手段と、を有することを特徴とする。
【０００８】
また、前記抽出手段により抽出されたメッセージの送信元と送信先の組を、同一の送信元及び送信先毎に集計してサービス利用関係情報を生成するサービス利用関係情報生成手段を有し、前記依存関係情報生成手段は、サービス利用関係情報に基づいて依存関係情報を生成することを特徴とする。
【０００９】
また、前記サービス利用関係情報生成手段は、検出したメッセージを種類毎に分類してサービス利用関係情報を生成することを特徴とする。
【００１０】
また、前記サービス利用関係情報生成手段は、１又は複数のサービスを利用する業務の業務フロー情報を解析することで同一業務において利用される一のサービスを送信元、他のサービスを送信先としてサービス利用関係情報を生成することを特徴とする。
【００１１】
また、前記依存関係情報生成手段は、前記サービス利用関係情報に基づいて他のサービスの提供に影響を与える影響度をサービス毎に算出して依存関係情報に含めることを特徴とする。
【００１２】
また、いずれかのサービスの提供が停止した場合、前記依存関係情報を参照することにより、停止したサービスに依存するサービスの管理者に対して当該停止したサービスの停止を通知する通知手段を有することを特徴とする。
【００１３】
また、前記依存関係情報を参照することにより、各サービスの品質を示す指標値を自動修正する修正手段を有することを特徴とする。
【００１４】
また、前記依存関係情報を参照することにより、サービスを起動させる順番を定義する起動順番情報を自動生成する起動順番情報生成手段を有することを特徴とする。
【００１５】
本発明に係るサービスシステムは、サービスを提供する複数のサーバと、情報処理装置と、表示装置と、を有し、前記情報処理装置は、前記サーバ間で送受信されるメッセージを検出し、検出したメッセージから当該メッセージの送信元となるサービスと当該メッセージの送信先となるサービスとを抽出する抽出手段と、前記抽出手段により抽出されたメッセージの送信元と送信先の組を集約することで各サービスの依存関係を示す依存関係情報を生成する依存関係情報生成手段と、要求に応じて前記依存関係情報を前記表示装置へ送信する送信手段と、を有することを特徴とする。
【００１６】
本発明に係るプログラムは、コンピュータを、サービスを提供するサーバ間で送受信されるメッセージを検出し、検出したメッセージから当該メッセージの送信元となるサービスと当該メッセージの送信先となるサービスとを抽出する抽出手段、前記抽出手段により抽出されたメッセージの送信元と送信先の組を集約することで各サービスの依存関係を示す依存関係情報を生成する依存関係情報生成手段、前記依存関係情報の表示の制御を行う表示制御示手段、として機能させる。
【発明の効果】
【００１７】
請求項１に記載の発明によれば、間接的に利用するサービスが存在する場合でもサービスの依存関係を明確にすることができる。
【００１８】
請求項２に記載の発明によれば、あるサービスの他のサービスの利用回数を把握することができる。
【００１９】
請求項３に記載の発明によれば、メッセージの種類毎に利用回数を把握することができる。
【００２０】
請求項４に記載の発明によれば、定型業務におけるサービスの利用を考慮してサービスの依存関係を明確にすることができる。
【００２１】
請求項５に記載の発明によれば、あるサービスが停止したときに当該サービスが他のサービスに与える影響度を知ることができる。
【００２２】
請求項６に記載の発明によれば、あるサービスが停止したときに当該サービスと依存関係のあるサービスの管理者に、サービスが停止した旨を通知することができる。
【００２３】
請求項７に記載の発明によれば、あるサービスと依存関係にあるサービスの品質を示す指標値を参照にして、当該サービスの品質を示す指標値を修正することができる。
【００２４】
請求項８に記載の発明によれば、サービスの依存関係を参照にして依存関係のあるサービスの中で起動順を決定し、その起動順に従って各サービスを起動させることができる。
【００２５】
請求項９に記載の発明によれば、間接的に利用するサービスが存在する場合でもサービスの依存関係を明確にすることができる。
【００２６】
請求項１０に記載の発明によれば、間接的に利用するサービスが存在する場合でもサービスの依存関係を明確にすることができる。
【図面の簡単な説明】
【００２７】
【図１】本実施の形態におけるサービスシステムの全体構成図である。
【図２】本実施の形態におけるサービス監視サーバを形成するサーバコンピュータのハードウェア構成図である。
【図３】本実施の形態におけるサービス監視サーバのブロック構成図である。
【図４】本実施の形態における業務フロー情報記憶部に設定登録されている業務フロー情報を概念的に示した模式図である。
【図５】本実施の形態における依存関係情報生成処理を示したフローチャートである。
【図６】本実施の形態においてＡＰＩ呼出に分類されたメッセージに基づく種別毎サービス利用関係テーブルの設定例を示した図である。
【図７】本実施の形態において業務の種別毎サービス利用関係テーブルの設定例を示した図である。
【図８】本実施の形態における依存関係情報記憶部に登録される依存関係テーブルの設定例を示した図である。
【図９】本実施の形態におけるサービス一覧情報画面の画面表示例を示した図である。
【図１０】本実施の形態におけるアラートメール処理を示したフローチャートである。
【図１１】本実施の形態において各サービスのＳＬＡ指標値と、各サービスの利用関係を模式的に示した概念図である。
【図１２】本実施の形態において各サービスの利用関係を模式的に示した概念図である。
【発明を実施するための形態】
【００２８】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【００２９】
図１は、本実施の形態におけるサービスシステムの全体構成図である。図１には、サービスサーバ１、業務サーバ２、管理者端末３及びサービス監視サーバ１０がネットワーク４に接続された構成が示されている。サービスサーバ１は、通常、ユーザからの要求に応じてサービスを提供する。サービスサーバ１に該当するサーバ１ａ，１ｂ，１ｃは、それぞれ異なるサービスＡ、サービスＢ、サービスＣを提供する。本実施の形態では、各サービスを区別することなく共通した機能を説明する際、サーバ１ａ，１ｂ，１ｃを総称してサービスサーバ１と称する。図１には、便宜上、３台のサーバ１ａ，１ｂ，１ｃを図示したが、台数はこれに限るものではない。１つのサービス（例えば、サービスＡ）は、複数のサーバが連携動作することで提供される場合もあり得るが、本実施の形態では、説明の便宜上、１台のサービスサーバ１（例えば、サーバ１ａ）によって提供されるものとする。なお、後述するように、サーバ１ａがサービスＡを提供するに際し、サーバ１ｂが提供するサービスＢを利用する場合もあり得るが、これは、複数のサービスサーバ１を利用することに該当しない。
【００３０】
業務サーバ２は、１又は複数のサービスを利用する定型業務を実行するサーバコンピュータである。管理者端末３は、システム管理者が使用する端末であり、パーソナルコンピュータ（ＰＣ）等の汎用的なコンピュータで実現してよい。本実施の形態では、表示装置として利用するのでディスプレイ等の表示手段を有している必要がある。サービス監視サーバ１０は、本発明に係る情報処理装置の一実施の形態であり、プロキシサーバの機能を有している。
【００３１】
図２は、本実施の形態におけるサービス監視サーバ１０を形成するサーバコンピュータのハードウェア構成図である。本実施の形態においてサービス監視サーバ１０を形成するサーバコンピュータは、従前から存在する汎用的なハードウェア構成で実現できる。すなわち、サービス監視サーバ１０は、図２に示したようにＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、ハードディスクドライブ（ＨＤＤ）３４、入力手段として設けられたマウス３５とキーボード３６、及び表示装置として設けられたディスプレイ３７をそれぞれ接続する入出力コントローラ３８、通信手段として設けられたネットワークコントローラ３９を内部バス４０に接続して構成される。サービスサーバ1及び業務サーバ２、更に管理者端末３も同じコンピュータであることから、それぞれのハードウェア構成も図３と同様に図示できる。
【００３２】
図３は、本実施の形態におけるサービス監視サーバ１０のブロック構成図である。本実施の形態におけるサービス監視サーバ１０は、メッセージ解析部１１、依存関係情報生成部１２、情報提示部１３、自動警告部１４、ＳＬＡ情報修正部１５、スクリプト生成部１６、業務フロー情報記憶部２１、サービス利用関係情報記憶部２２、依存関係情報記憶部２３及びサービス関連情報記憶部２４を有している。なお、本実施の形態の説明に用いない構成要素については図から省略している。
【００３３】
メッセージ解析部１１は、ネットワーク４を介してサービスサーバ１間で送受信されるメッセージを検出し、検出したメッセージから当該メッセージの送信元となるサービスと当該メッセージの送信先となるサービスとを抽出する抽出手段として機能する。更に、メッセージ解析部１１は、抽出したメッセージの送信元と送信先の組を、同一の送信元及び送信先毎に集計してサービス利用関係情報を生成してサービス利用関係情報記憶部２２に登録するサービス利用関係情報生成手段として機能する。なお、厳密には、メッセージは、サービスサーバ１間で送受信されるので、送信元及び送信先となるのはサービスサーバ１かもしれないが、アプリケーションレベルではサービス間でメッセージ交換されるので、説明の便宜上、「送信元となるサービス」また「送信先となるサービス」というように、サービスサーバ１とサービスとを区別なく用いる場合もある。また、メッセージ解析部１１は、メッセージとは別に業務フロー情報記憶部２１に設定登録されている業務フローを解析してサービス利用関係情報を生成してサービス利用関係情報記憶部２２に登録する。
【００３４】
依存関係情報生成部１２は、サービス利用関係情報記憶部２２に蓄積されたサービス利用関係情報を集約することで各サービスの依存関係を示す依存関係情報を生成して依存関係情報記憶部２３に登録する。情報提示部１３は、依存関係情報記憶部２３に記憶されている依存関係情報及びサービス関連情報記憶部２４から取り出した必要な情報に基づいて依存関係情報を表示するための情報を生成し、送信することによって管理者端末３への表示制御を行う表示制御手段として機能する。
【００３５】
自動警告部１４は、いずれかのサービスの提供が停止した場合、依存関係情報記憶部２３に記憶されている依存関係情報及びサービス関連情報記憶部２４の連絡先情報を参照することにより、停止したサービスに依存するサービスの管理者に対して当該停止したサービスの停止を通知する通知手段として機能する。ＳＬＡ情報修正部１５は、依存関係情報記憶部２３に記憶されている依存関係情報及びサービス関連情報記憶部２４のＳＬＡ情報を参照することにより、現在のＳＬＡ情報を自動修正する修正手段として機能する。ＳＬＡ（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ）は、サービスを提供する事業者が契約者に対して、どの程度まで品質を保証できるかというサービスレベルに関する合意書と言われている。ＳＬＡ情報には、サービスレベルを示す具体的な指標値として、最大許容停止時間（ＭＴＰＤ：Ｍａｘｉｍｕｍ  Ｔｏｌｅｒａｂｌｅ  Ｐｅｒｉｏｄ  ｏｆ  Ｄｉｓｒｕｐｔｉｏｎ）、目標復旧時間（ＲＴＯ：Ｒｅｃｏｖｅｒｙ  Ｔｉｍｅ  Ｏｂｊｅｃｔｉｖｅ）及び目標復旧レベル（ＲＬＯ：Ｒｅｃｏｖｅｒｙ  Ｌｅｖｅｌ  Ｏｂｊｅｃｔｉｖｅ）などが設定される。スクリプト生成部１６は、依存関係情報記憶部２３に記憶されている依存関係情報を参照することにより、サービスサーバ１を起動させる順番を定義する起動順番情報としてスクリプトを自動生成する起動順番情報生成手段として機能する。
【００３６】
図４は、本実施の形態における業務フロー情報記憶部２１に設定登録されている業務フロー情報を概念的に示した模式図である。図４には、業務Ｘ，Ｙが例示されている。業務Ｘは、業務フローＸ−１〜Ｘ−４で構成され、このうちＸ−３はサービスＡを利用し、Ｘ−４はサービスＦを利用することが示されている。また、業務Ｙは、業務フローＹ−１〜Ｙ−４で構成され、このうちＹ−２はサービスＡを、Ｙ−３はサービスＢを、Ｙ−４はサービスＦを、それぞれ利用することが示されている。
【００３７】
サービス関連情報記憶部２４には、サービス詳細情報、サーバ構成情報、連絡先情報及びＳＬＡ情報が登録されている。サービス詳細情報には、本システムが提供するサービスに関する情報が設定される。具体的には、各サービスに対し、当該サービスの名称、当該サービスの管理者に関する情報として、管理者の氏名、所属、連絡先（電話番号、メールアドレス）等が設定される。サーバ構成情報には、各サービスに対し、当該サービスアプリケーションを実行するサービスサーバ１のホスト名及びＩＰアドレスが設定される。本実施の形態では、１つのサービスの提供を１台のサービスサーバ１で実現することを前提としているが、仮に複数台のサービスサーバ１を連携させて実現する場合、当該サービスに対し、複数のサービスサーバ１の情報を関連付けて設定すればよい。連絡先情報には、各サービスに対し、当該サービスの連絡先としてサービスの管理者のメールアドレスが設定される。サービス詳細情報にも同じ情報が重複して設定されているので省略してもよいが、連絡先情報は、自動警告部１４が利用するために用意される。従って、サービス詳細情報と連絡先情報それぞれに設定するメールアドレスを必ずしも一致させる必要はない。ＳＬＡ情報には、ＳＬＡを示す指標値（ＭＴＰＤ、ＲＴＯ、ＲＬＯ）等が設定される。なお、サービス利用関係情報記憶部２２及び依存関係情報記憶部２３に登録される各情報については動作の説明と合わせて説明する。
【００３８】
サービス監視サーバ１０における各構成要素１１〜１６は、サービス監視サーバ１０を形成するコンピュータと、コンピュータに搭載されたＣＰＵ３１で動作するプログラムとの協調動作により実現される。また、各記憶部２１〜２４は、サービス監視サーバ１０に搭載されたＨＤＤ３４にて実現される。あるいは、ＲＡＭ３３又は外部にある記憶手段をネットワーク経由で利用してもよい。
【００３９】
また、本実施の形態で用いるプログラムは、通信手段により提供することはもちろん、ＣＤ−ＲＯＭやＵＳＢメモリ等のコンピュータ読み取り可能な記録媒体に格納して提供することも可能である。通信手段や記録媒体から提供されたプログラムはコンピュータにインストールされ、コンピュータのＣＰＵがプログラムを順次実行することで各種処理が実現される。
【００４０】
ところで、サービスの中には、サービスを単独で提供しうるサービスもあれば、他のサービスを利用してサービスを提供するサービスもある。本実施の形態において、「サービスＸがサービスＹに依存する」というのは、サービスシステムがサービスＸを提供する際にサービスＸがサービスＹの提供を受けることをいう。同様に、「サービスＹがサービスＺに依存する」というのは、サービスシステムがサービスＹを提供する際にサービスＹがサービスＺの提供を受けることをいう。この場合、サービスＸは、サービスＹを直接、そしてサービスＺを間接的に利用することになるので、サービスＹ，Ｚと依存関係にある。このように、他のサービスと何らかの利用関係にあれば、依存関係があることになる。「サービスＸがサービスＹに依存する」場合、サービスＸは「依存サービス」、サービスＹ，Ｚは「被依存サービス」という立場にある。上記例に基づくと、本実施の形態は、サービスＸに対し、直接利用するサービスＹはもちろんのこと、間接的に利用するサービスＺの存在ももれなく抽出することを特徴としている。
【００４１】
次に、本実施の形態における依存関係情報生成処理について図５に示したフローチャートを用いて説明する。この処理は、サービスシステムが稼働している間、サービス監視サーバ１０により常時実行される。なお、サービスサーバ１が所定のサービス機能を実現するアプリケーションを実行することで、要求されたサービスを提供することになるが、本実施の形態では、説明の簡略化のために、サービスサーバ１は、サービスを実行又は提供するものとして記載する。
【００４２】
図示しないインターネット等のネットワークを介してユーザからサービスの実行要求が送られてくると、その要求に対応したサービスサーバ１は、要求されたサービスを当該ユーザに提供する。
【００４３】
ここで、要求されたサービスの提供に際し、当該サービスが他のサービスを利用する場合、当該サービス（利用元となるサービス）を実行するサービスサーバ１から、他のサービス（利用先となるサービス）を実行するサービスサーバ１へネットワーク４を介してリクエスト等のメッセージが送信される。ネットワーク４には、様々な種類のメッセージが流れるが、サービス監視サーバ１０は、プロキシサーバとして機能するため、全てのメッセージはサービス監視サーバ１０を通過する。従って、メッセージ解析部１１は、ネットワーク４上のメッセージを常時傍受し、サービスサーバ１間で送受信されるメッセージを検出する（ステップ１０１）。そして、メッセージ解析部１１は、そのメッセージのメッセージヘッダあるいはメッセージの内容を解析し、サーバ構成情報を参照することによりそのメッセージの送信元となるサービスと当該メッセージの送信先となるサービスとを抽出する（ステップ１０２）。
【００４４】
メッセージの送信元及び送信先を特定すると、メッセージ解析部１１は、サービス利用関係情報記憶部２２にメッセージの送信元及び送信先の組を登録する。本実施の形態では、後述する付加機能を提供するために、メッセージの種類毎にメッセージを分類して該当する種別毎サービス利用関係テーブルに登録する（ステップ１０３）。このため、メッセージ解析部１１は、メッセージの内容まで踏み込んで解析することになる。本実施の形態では、サービスサーバ１間で授受されるメッセージを、ＡＰＩ呼出、バッチ処理及びリンク参照に分類し、更に業務フロー情報から業務という種類に属するサービス利用関係情報を生成、登録する。
【００４５】
ＡＰＩ呼出には、サービスサーバ１間で交換されるＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）やＲＥＳＴ（ＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ）等のＨＴＴＰプロトコルに従って送受信されるＡＰＩの呼び出しが分類される。メッセージボディに“ＳＯＡＰ”や“ＧＥＴ”， “ＰＯＳＴ”， “ＰＵＴ”， “ＤＥＬＥＴＥ”などを含むメッセージパターンを検出することでＡＰＩ呼出であることが認識できる。なお、本実施の形態では、どのサービスがどのサービスを利用しているのかを抽出するのが目的なので、リクエストに対するレスポンスは抽出しないようにする。他の種別においても同様である。バッチ処理には、サービスサーバ１間でのバッチファイル転送に用いられるＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）に従って記述されたメッセージのパケットが分類される。リンク参照には、メッセージがＨＴＭＬなどで記載されたＷｅｂページである場合に分類される。
【００４６】
以上の処理を所定時間経過するまで繰り返し実行し（ステップ１０４でＮ）、所定時間が経過することで（ステップ１０４でＹ）、ＡＰＩ呼出、バッチ処理及びリンク参照の各種別毎サービス利用関係テーブルへの設定が終了する。
【００４７】
図６は、ＡＰＩ呼出に分類されたメッセージに基づく種別毎サービス利用関係テーブルの設定例を示した図である。図６の設定例によると、サービスＡは、所定期間内にサービスＢを３０回利用し、サービスＤを１５回利用したことがわかる。また、サービスＢは、所定期間内にサービスＣを５０回利用している。このように、メッセージから抽出されたメッセージの送信元と送信先は、同一の送信元及び送信先毎に集計される。なお、１つのサービスでもユーザに提供する機能によって利用されるサービスが異なってくる。例えば、ユーザ認証サービスはサービスの提供の度に利用されるかもしれないが、ヘルプ画面表示サービスは毎回利用されるとは限らない。従って、同じ送信元でも送信先の利用回数には差が生じてくる。バッチ処理及びリンク参照においても同様に検出されたメッセージによって種別毎サービス利用関係テーブルに利用回数が設定される。
【００４８】
続いて、メッセージ解析部１１は、業務についても種別毎サービス利用関係テーブルを生成してサービス利用関係情報記憶部２２に登録する（ステップ１０５）。業務は、上記の種別とは異質であり、メッセージ解析部１１により検出されたメッセージを解析するのではなく、業務フロー情報記憶部２１に設定されている業務フロー情報を解析することによって種別毎サービス利用関係テーブルに設定する。
【００４９】
図７は、業務の種別毎サービス利用関係テーブルの設定例を示した図である。業務に関しては、メッセージの送受信にかかわらずサービスの利用関係を把握するようにするので、厳密には送信元／送信先という概念はないが、上記種類との整合性を取るために同じ形式のテーブルにてサービスの利用関係を把握するようにしている。
【００５０】
業務Ｘは、ワークフローが実行されるとサービスＡとサービスＦが実行される。従って、サービスＡを送信元、サービスＦを送信先とすると同時に、サービスＦを送信元、サービスＡを送信先として種別毎サービス利用関係テーブルに設定する。業務Ｙにおいても同様に処理する。業務Ｘは、ワークフローが実行されるとサービスＡ，Ｂ，Ｆが実行される。従って、サービスＡを送信元、サービスＢを送信先とすると同時に、サービスＢを送信元、サービスＡを送信先として種別毎サービス利用関係テーブルに設定する。また、サービスＢを送信元、サービスＦを送信先とすると同時に、サービスＦを送信元、サービスＢを送信先として種別毎サービス利用関係テーブルに設定する。更に、サービスＡを送信元、サービスＦを送信先とすると同時に、サービスＦを送信元、サービスＡを送信先として種別毎サービス利用関係テーブルに設定する。なお、サービスＡとサービスＦは、業務Ｘと業務Ｙの双方に含まれているので、種別毎サービス利用関係テーブルには“２”と設定される。
【００５１】
以上のようにして、メッセージ解析部１１により各種類の種別毎サービス利用関係テーブルがサービス利用関係情報記憶部２２に登録されると、依存関係情報生成部１２は、その登録内容に基づき依存関係情報を次のようにして生成する。
【００５２】
図８は、本実施の形態における依存関係情報記憶部２３に登録される依存関係テーブルの設定例を示した図である。種類の種別毎サービス利用関係テーブルは同じ形式なので、依存関係情報生成部１２は、種別毎サービス利用関係テーブルの同じカラムの集計値を合算して依存関係テーブルに設定する（ステップ１０６）。つまり、複数の種別毎サービス利用関係テーブルを１つの依存関係テーブルに集約することになる。続いて、依存関係情報生成部１２は、各合算値を送信先毎に集計することで各サービスの影響度を算出する（ステップ１０７）。依存関係情報生成部１２は、以上のようにして生成した依存関係テーブルの設定内容を依存関係情報として依存関係情報記憶部２３に登録する（ステップ１０８）。
【００５３】
サービスの依存関係は、通常有るか無いかで表すことができるが、依存関係にある場合でも、他のサービスから相対的に数多く利用されるということは、それだけサービスシステムにおいて重要な位置付けにあるサービスである。従って、そのサービスが仮に停止したときには数多くのサービスに影響を与えてしまうということになる。そこで、本実施の形態では、送信先として指定された数を合算して当該サービスの影響度を算出するようにした。
【００５４】
なお、本実施の形態では、各種類の値を同等に取り扱ったが、各種類に重み付けをして影響度を求めるようにしてもよい。例えば、ＡＰＩ呼出、バッチ処理、リンク参照及び業務の利用関係を示す値がそれぞれ３０，２０，１０，５の場合において、前述したように重み付けをしない場合の影響度は３０＋２０＋１０＋５＝６５と算出できる。仮に、ＡＰＩ呼出、バッチ処理、リンク参照及び業務に対し、１．０：０．８：０．６：０．４と重み付けがされていた場合、３０×１．０＋２０×０．８＋１０×０．６＋５×０．４＝４８と算出できる。
【００５５】
以上のようにして、依存関係情報を所定時間毎に生成、登録する。図５では、依存関係情報生成処理を終了させているが、依存関係情報生成処理は、前述したように上記処理を繰り返し実行する。なお、依存関係情報は、所定時間経過毎に新たに生成されることになるが、これらを統合するようにしてもよい。この場合、影響度の値は増加していくことになるので、統合数によって平均値を求めるようにしてもよい。また、アプリケーションの更新によって利用するサービスが変更する場合を考慮して統合しないようにしてもよい。また、本実施の形態では、依存関係情報を所定時間毎に生成するようにしたが、所定量のメッセージの送受信を検出する度に生成するようにしてもよい。
【００５６】
依存関係情報が生成されると、その後、情報提示部１３は、管理者端末３からの要求に応じて依存関係情報に基づきサービスの依存関係に関する情報を表示するためのサービス一覧情報画面を生成し、管理者端末３に送信する。
【００５７】
図９は、本実施の形態において、管理者端末３で表示されるサービス一覧情報画面の表示例を示した図である。サービス一覧情報画面には、影響度の高い順に並べてサービス名を表示するための表示領域９１と、当該サービスの影響度が表示される表示領域９２と、選択されたサービスと依存関係にあるサービスをリスト表示する表示領域９３と、が含まれている。なお、図９では、サービスＰが選択された場合を示している。そして、図９には、サービス一覧情報画面に重ねて情報表示メニュー画面９４が表示されている例が示されている。情報表示メニュー画面９４の表示位置はこの表示例に限る必要はなく、所望の位置に表示してよい。
【００５８】
管理者は、影響度の大きい順にリスト表示されているサービスの中から参照したいサービスを選択する。図９に例示したように、サービスＰが選択された場合、情報提示部１３は、依存関係情報を参照することによってサービスＰと依存関係にあるサービスを抽出し、そのうちサービスＰ（依存サービス）が依存する被依存サービスを表示領域９３に表示する。本実施の形態では、サービス利用関係情報をも参照することで種類毎に分類して表示する。なお、本実施の形態では、被依存サービスをリスト表示するようにしたが、サービスＰを被依存サービスとする依存サービスを切替可能に表示するようにしてもよいし、双方を判別可能に表示するようにしてもよい。
【００５９】
また、サービスの表示領域９１にサービスを一覧表示する際、影響度が所定の閾値以上のサービスは閾値未満のサービスと異なる表示形態にて表示するようにしてもよい。異なる表示形態というのは、表示色、表示サイズ、文字装飾等の表示属性を異ならせて表示することをいう。
【００６０】
情報表示メニュー画面９４には、サービス詳細、構成サーバ一覧及び関係連絡先の各種情報の選択肢が表示される。管理者が情報表示メニュー画面９４の中からサービス詳細を選択すると、情報提示部１３は、選択されているサービス（上記例でいうサービスＰ）のサービス詳細情報をサービス関連情報記憶部２４から取り出して当該サービスの名称や管理者情報等を表示するためのサブ画面を生成し、管理者端末３へ送信することで表示させる。管理者が構成サーバ一覧を選択すると、情報提示部１３は、選択されているサービスのサーバ構成情報をサービス関連情報記憶部２４から取り出して、当該サービスを実行するサービスサーバ１のホスト名及びＩＰアドレスをリスト表示するためのサブ画面を生成し、管理者端末３へ送信することで表示させる。管理者が関係連絡先を選択すると、情報提示部１３は、選択されているサービスと依存関係にあるサービスの連絡先情報をサービス関連情報記憶部２４から取り出して依存関係にあるサービスの名称及び当該各サービスの管理者のメールアドレスをリスト表示するためのサブ画面を生成し、管理者端末３へ送信することで表示させる。なお、関係連絡先の場合、サブ画面に表示された連絡先全員あるいは管理者により選択された連絡先に対してメールを送信できるようにサブ画面を構成してもよい。
【００６１】
本実施の形態では、以上のようにしてサービスの影響度及び選択されたサービスと依存関係にあるサービス、更に、情報表示メニュー画面９４からの情報項目の選択に応じて、選択されたサービスに関連する情報を管理者に提示する。
【００６２】
ところで、いずれかのサービスが停止した場合、停止したサービスは当然のこと、更にその停止したサービスを被依存サービスとする依存サービスも提供することができなくなる。そこで、本実施の形態においては、このような状況であることを依存サービスの管理者に対して被依存サービスの停止を通知することで警告できるようにした。以下、自動警告部１４がメールにて警告を出すアラートメール処理について図１０に示したフローチャートを用いて説明する。
【００６３】
いずれかのサービスが停止し、その後、一定時間停止していることを検知すると（ステップ１１１でＹ）、自動警告部１４は、依存関係テーブルを参照して、停止したサービスと依存関係にあるサービスを抽出する（ステップ１１２）。続いて、自動警告部１４は、連絡先情報を参照して、抽出したサービスの連絡先を抽出する（ステップ１１３）。そして、被依存サービスが一定時間停止している旨のアラートメールを生成し、抽出した連絡先のメールアドレスを当該メールの宛先に指定してアラートメールを送信する（ステップ１１４）。
【００６４】
例えばサービスＡが停止したとする。この場合、図８の設定例に従うとサービスＡを送信先（被依存サーバ）とするサービスＢ，Ｆが抽出される。更に、サービスＢを送信先とするサービスＡ，Ｃ，Ｆが抽出される。なお、サービスＡは停止したサービスであるため対象外となる。また、サービスＦは既に抽出済みである。また、サービスＦを送信先とするサービスＡ，Ｂ，Ｅが抽出される。なお、上記の通り、サービスＡは対象外であり、サービスＢは抽出済みである。続いて、サービスＥを送信先とするサービスＦが抽出されるが、サービスＦは抽出済みである。
【００６５】
このように、自動警告部１４は、依存関係テーブルを参照することによって停止したサービスを直接利用するサービスのみならず間接的に利用するサービスまでも抽出することが可能になる。自動警告部１４は、以上のようにして網羅したサービスの停止の影響を受けるサービスの管理者に自動的に警告を発することができる。
【００６６】
ところで、依存関係情報が生成されサービス間の依存関係が明確に把握できるようになると、ＳＬＡの設定の整合性も容易にチェックできるようになる。そして、不整合が発見されたときには修正も自動的に行うことが可能になる。ＳＬＡ情報修正部１５は、このＳＬＡの設定内容の整合性チェック及び設定内容の修正を行う。
【００６７】
図１１は、本実施の形態において、いくつかのサービスの利用関係を模式的に示した概念図である。また、図１１には、各サービスのＭＴＰＤ及びＲＬＯの各ＳＬＡ指標値が示されている。図１１では、各サービスの利用関係を矢印で示しているが、例えば、サービスＤはサービスＣを利用し、サービスＣはサービスＡを利用する依存関係にある。この場合、サービスＤのＭＴＰＤは６時間と設定されているので、サービスの停止は最大６時間まで許容することを意味している。同様に、サービスＣの停止時間は最大７時間まで、サービスＡの停止時間は最大５時間まで、それぞれ許容することを意味している。
【００６８】
ここで、サービスＡが停止したとする。その間、サービスＣは、サービスＡを利用できない。ただ、サービスＡは、５時間以内には復旧するはずなので、サービスＣのＭＴＰＤ（最大７時間）に反しない。これに対し、サービスＣが停止したとすると、サービスＤは、サービスＣを利用できない。そして、サービスＣのＭＴＰＤは７時間なので、サービスＤのＭＴＰＤ（最大６時間）を超えてサービスＣが復旧される可能性がある。この場合、サービスＤではＳＬＡを遵守できなくなり不都合である。
【００６９】
そこで、本実施の形態では、依存関係にあるサービスのＭＴＰＤを考慮してサービスのＭＴＰＤを設定するよう提案又は修正できるようにする。この例の場合、サービスＤのＭＴＰＤはサービスＣのＭＴＰＤを反映して７時間に修正する。
【００７０】
以上の処理は、ＭＴＰＤのチェック対象のサービス（この例ではサービスＤ）と依存関係にあるサービスＣ、サービスＣと依存関係にあるサービスＡと、サービスＤからの利用関係をたどっていき、そしてサービスＤ及びサービスＤと直接又は間接的に依存関係にある全てのサービス（この例ではサービスＡ，Ｃ，Ｄ）の中で最大値（この例ではサービスＣの７時間）のＭＴＰＤをサービスＤのＭＴＰＤに設定する。一方、他方の依存関係のサービスＡ，Ｂの中ではサービスＢのＭＴＰＤが最大値なので修正不要である。
【００７１】
ＲＬＯに関しても同様に処理するが、ＲＬＯの場合は依存関係にある全てのサービス（例えばサービスＡ，Ｃ，Ｄ）の中で最小値が設定される。従って、サービスＡ，Ｃ，Ｄの中で最小値は２日なので、サービスＤのＲＬＯは修正不要である。他方の依存関係のサービスＡ，Ｂにおいても同様で、サービスＢのＲＬＯは最小値なので修正不要である。
【００７２】
なお、ＳＬＡは、契約者に対するサービスの品質保証に関することなので、サービス利用関係を導出した４つの種類のうち業務のサービス利用関係情報を除いた依存関係情報に基づきＳＬＡの整合性をチェックするようにしてもよい。
【００７３】
ところで、依存関係情報が生成されサービス間の依存関係が明確に把握できるようになると、複雑に絡み合ったサービスサーバ１の起動順を適正化することも可能になる。スクリプト生成部１６は、依存関係情報を参照してサービスを起動させる順番を定義するスクリプトを自動生成する。
【００７４】
例えば、サービスＸの提供に際しサービスＹを利用すると仮定する。この場合、サービスＹを起動してからサービスＸを起動するのが好適である。サービスＸを先に起動してもサービスＹが起動されていなければサービスＸを提供できないからである。
【００７５】
図１２は、本実施の形態において各サービスの利用関係を模式的に示した概念図である。図１２には、図１１と同様のサービスの利用関係が示されている。上記サービスＸ，Ｙの説明に従うと、サービスＤを提供するためにはサービスＣが先に起動されていなければならない。同様にサービスＣを提供するためにはサービスＡが先に起動されていなければならない。つまり、起動対象のサービスＤを起動するには、サービスＡ，Ｃ，Ｄの順に起動する必要がある。
【００７６】
以上の処理は、起動対象のサービス（この例ではサービスＤ）と利用関係にあるサービスＣ、サービスＣと利用関係にあるサービスＡと、サービスＤからの依存関係をたどっていき、そしてサービスＤ及びサービスＤと直接又は間接的に依存関係にある全てのサービス（この例ではサービスＤ，Ｃ，Ａ）を抽出し、抽出した逆の順番（この例ではサービスＡ，Ｃ，Ｄ）に起動するためのスクリプトを生成する。
【００７７】
一方、起動対象のサービスＢに関しても同様に、サービスＢと依存関係にあるサービスＡと、サービスＢからの依存関係をたどっていき、サービスＡ，Ｂという順番のスクリプトを生成する。
【００７８】
スクリプト生成部１６は、この２つのスクリプトを統合し、最初にサービスＡを起動し、サービスＡが起動されると続いてサービスＢ，Ｃ，そして最後にサービスＤを起動するスクリプトを生成する。このスクリプトに従えば、それぞれのサービスが起動されたときには、当該サービスを即座に提供することが可能になる。
【００７９】
以上説明したように、本実施の形態においては、サービスシステムに含まれるサービスサーバ１全体の依存関係を網羅することができる。ただ、依存関係を求める対象とするサービスサーバ１を事前に絞り込むようにしてもよい。これは、対象外のサービスサーバ１を非対象リストに事前に設定しておき、検出したメッセージの送信元及び送信先（ＩＰアドレス）を、非対象リストと照合するようにすることで可能である。
【符号の説明】
【００８０】
１  サービスサーバ、１ａ，１ｂ，１ｃ  サーバ、２  業務サーバ、３  管理者端末、４  ネットワーク、１０  サービス監視サーバ、１１  メッセージ解析部、１２  依存関係情報生成部、１３  情報提示部、１４  自動警告部、１５  ＳＬＡ情報修正部、１６  スクリプト生成部、２１  業務フロー情報記憶部、２２  サービス利用関係情報記憶部、２３  依存関係情報記憶部、２４  サービス関連情報記憶部、３１  ＣＰＵ、３２  ＲＯＭ、３３  ＲＡＭ、３４  ハードディスクドライブ（ＨＤＤ）、３５  マウス、３６  キーボード、３７  ディスプレイ、３８  入出力コントローラ、３９  ネットワークコントローラ、４０  内部バス。
【図１】
2018041251.tif 000003
【図２】
2018041251.tif 000004
【図３】
2018041251.tif 000005
【図４】
2018041251.tif 000006
【図５】
2018041251.tif 000007
【図６】
2018041251.tif 000008
【図７】
2018041251.tif 000009
【図８】
2018041251.tif 000010
【図９】
2018041251.tif 000011
【図１０】
2018041251.tif 000012
【図１１】
2018041251.tif 000013
【図１２】
2018041251.tif 000014