JP2016186704A - 情報処理装置、情報処理システム及びプログラム - Google Patents

Abstract

【課題】業務システムの動作状態の確認頻度を下げることができる情報処理装置、情報処理システム及びプログラムを提供する。【解決手段】業務システムから取得した業務システムで実行されるタスクの処理状況に基づき、業務システムから業務システムの状態情報を取得する時間を決定する時間決定部と、決定した取得する時間に、状態情報を取得して記憶部に記憶する情報取得部と、業務システムの監視を行う１または複数の監視装置のいずれかから状態情報の取得依頼を受信した場合に、記憶部に記憶した状態情報を返信する情報返信部と、を有する。【選択図】図８

Description

本発明は、情報処理装置、情報処理システム及びプログラムに関する。

利用者に対してサービスを提供する事業者（以下、サービス事業者とも呼ぶ）は、例えば、サービスの提供を実現するために業務システムを構築する。このような業務システムにおいて、サービス事業者は、例えば、業務システムのリソースの状態等を管理する装置（以下、マネージャとも呼ぶ）と、ネットワークを介してマネージャと接続した端末（以下、事業者端末とも呼ぶ）とを用意する。

そして、事業者端末は、マネージャに対して、業務システムによる処理（以下、タスクとも呼ぶ）の実行を依頼するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を送信する。これにより、サービス事業者は、業務システム及びマネージャが遠隔地のデータセンタに構築されている場合であっても、業務システムの動作状態の確認や、業務システムが構築されたハードウエアの設定変更等を行うことが可能になる（例えば、特許文献１乃至３参照）。

特開２００４−０２１５４９号公報 特表２００７−５２０８０６号公報 特開平０７−３０２２４２号公報

上記のような業務システムにおいて、業務システムが実行する処理の内容等によっては、マネージャに接続する必要がある事業者端末が複数存在する場合がある。そして、各事業者端末がマネージャに対して動作状態の確認を頻繁に行う場合、マネージャの処理負担が高まる。

これに対し、各事業者端末は、業務システムの動作状態の確認頻度を下げることにより、マネージャの処理負担を抑制することが可能になる。例えば、各事業者端末は、自装置が業務システムに処理の実行を依頼している場合、その処理の実行完了予測時間になるまで業務システムの動作状態の確認を行わない。これにより、各事業者端末は、自装置が業務システムに処理の実行を依頼する際に、業務システムの動作状態の確認頻度を下げることが可能になる。

しかしながら、複数の事業者端末がマネージャに対して処理の実行を依頼する場合、他の事業者端末が依頼した処理の実行により、業務システムの動作状態は変化する。この場合、先に処理の実行を依頼した事業者端末は、自装置が業務システムに実行を依頼した処理の実行が完了して動作状態の確認を再開するまで、他の事業者端末に起因する業務システムの動作状態の変化を検知することができない。

そこで、一つの実施の形態の目的は、業務システムの動作状態の確認頻度を下げることができる情報処理装置、情報処理システム及びプログラムを提供することにある。

実施の形態の一つの側面によれば、業務システムから取得した該業務システムで実行されるタスクの処理状況に基づき、前記業務システムから該業務システムの状態情報を取得する時間を決定する時間決定部と、
決定した前記取得する時間に、前記状態情報を取得して記憶部に記憶する情報取得部と、
前記業務システムの監視を行う１または複数の監視装置のいずれかから前記状態情報の取得依頼を受信した場合に、前記記憶部に記憶した前記状態情報を返信する情報返信部と、を有する。

一つの側面によれば、業務システムの動作状態の確認頻度を下げることができる。

情報処理システムの全体構成を示す図である。 業務システムの動作状態の確認を説明する図である。 第１の実施の形態における情報管理処理の概略を説明する図である。 情報処理装置のハードウエア構成を示す図である。 事業者端末のハードウエア構成を示す図である。 図４の情報処理装置の機能ブロック図である。 図５の事業者端末の機能ブロック図である。 第１の実施の形態における情報管理処理の概略を示すフローチャート図である。 第１の実施の形態における情報管理処理の概略を示すフローチャート図である。 第１の実施の形態における情報管理処理の詳細を示すフローチャート図である。 第１の実施の形態における情報管理処理の詳細を示すフローチャート図である。 第１の実施の形態における情報管理処理の詳細を示すフローチャート図である。 第１の実施の形態における情報管理処理の詳細を説明する図である。 第１の実施の形態における情報管理処理の詳細を説明する図である。 第１の実施の形態における情報管理処理の詳細を説明する図である。 第１の実施の形態における情報管理処理の詳細を説明する図である。 第１の実施の形態における情報管理処理の詳細を説明する図である。 第１の実施の形態における情報管理処理の詳細を説明する図である。 第１の実施の形態における情報管理処理の詳細を説明する図である。 第１の実施の形態における情報管理処理の詳細を説明する図である。 第１の実施の形態における情報管理処理の詳細を説明する図である。 第１の実施の形態における情報管理処理の詳細を説明する図である。

［情報処理システムの構成］
図１は、情報処理システムの全体構成を示す図である。図１に示す情報処理システム１０は、マネージャ１と、物理マシン２と、事業者端末５（以下、監視装置５とも呼ぶ）とを有する。事業者端末５は、ネットワークＮＷを介して、マネージャ１及び物理マシン２にアクセス可能である１台以上の端末である。

物理マシン２は、図１の例においては複数の物理マシンから構成されている。そして、物理マシン２のリソースは、複数の仮想マシン３に割当てられる。

マネージャ１は、物理マシン２に作成された仮想マシン３とアクセス可能であり、仮想マシン３の管理を行う。具体的に、マネージャ１は、仮想マシン３のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の使用率やメモリの空き容量等の状態（以下、動作状態とも呼ぶ）の管理を行う。マネージャ１は、例えば、物理マシン２に作成された仮想マシン３の一部に作成されるものであってもよい。

仮想マシン３は、例えば、そのインフラをネットワーク経由でサービス事業者に提供するもの（以下、クラウドサービスとも呼ぶ）である。そして、サービス事業者は、例えば、利用者にサービスを提供するための業務システムを仮想マシン３に構築する。

クラウドサービスは、コンピュータシステムを構築し稼働させるための基盤、即ち、仮想マシン３やネットワーク等のインフラストラクチャそのものを、ネットワーク経由で提供するサービスである。具体的に、サービス事業者は、例えば、事業者端末５からクラウドサービスポータルサイトにアクセスして、仮想マシンに必要な仕様を選択し、それらについてクラウド利用契約を締結する。この仮想マシンの仕様は、例えば、ＣＰＵのクロック周波数、メモリの容量（ＧＢ）、ハードディスクの容量（ＭＢ／ｓｅｃ、ＩＯＰＳ）、及びネットワークの通信帯域幅（Ｇｂｐｓ）である。

また、仮想マシン３は、物理マシン２のリソースが割当てられることに加えて、例えば、ＯＳ（Ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）、ミドルウエア、アプリケーション及びデータベース等を有するイメージファイルをハードディスク内に有する。そして、仮想マシン３は、例えば、起動時にイメージファイルをハードディスクからメモリに書き込み、所望のサービスに対応する動作を行う。

事業者端末５は、例えば、サービス事業者のシステム管理者（以下、単にシステム管理者とも呼ぶ）が使用可能な端末である。そのため、事業者端末５は、例えば、サービス事業者の事業所に設置されているものであってよい。

そして、事業者端末５は、例えば、システム管理者による入力に応じて、マネージャ１に対して、業務システムによるタスクの実行を依頼するためのＡＰＩを送信する。これにより、システム管理者は、物理マシン２やマネージャ１が遠隔地に設置されている場合であっても、業務システムに対して、仮想マシン３の動作状態を確認や、仮想マシンに対する操作（例えば、仮想マシンの作成及び削除）を行うことが可能になる。

仮想化ソフトウエア４は、マネージャ１からの指示に応じて、物理マシン２のリソース（例えば、ＣＰＵ、メモリ、ハードディスク及びネットワークのリソース）を割当てることにより、仮想マシン３を動作させる基盤ソフトウエアである。仮想化ソフトウエア４は、例えば、物理マシン２で動作する。

［業務システムの動作状態の確認］
図２は、業務システムの動作状態の確認を説明する図である。図２に示す例において、事業者端末５ａ、５ｂ及び５ｃは、マネージャ１にＡＰＩを送信することにより、仮想マシン３に構築された業務システムの動作状態の確認を行う。

図２の例に示すように、複数の事業者端末５がそれぞれ定期的（例えば、２０（ｓ）間隔）にマネージャ１に対してＡＰＩの送信を行った場合、マネージャ１は、多くのＡＰＩに基づく処理を実行する必要があるため、処理負担が高まる。

これに対し、事業者端末５がマネージャ１に対して、処理の実行（新たな仮想マシン３の生成等の実行）を依頼するためのＡＰＩを送信する場合、依頼した処理の実行が終了する時間の予測が可能である場合がある。具体的に、各事業者端末５が過去にマネージャ１に対して依頼した処理の実行に要する時間（以下、実行時間とも呼ぶ）を記憶している場合がこれに該当する。この場合、事業者端末は、過去に依頼した処理の実行時間を参照することにより、新たにマネージャ１に依頼する処理の実行時間を予測することが可能になる。

そして、この場合、事業者端末５は、マネージャ１に対して処理の実行を依頼するためのＡＰＩを送信した後、依頼した処理について予測した実行時間が経過するまで、業務システムの動作確認を行うためのＡＰＩの送信を待機する。これにより、事業者端末５は、マネージャ１に送信されるＡＰＩを抑えることが可能になり、処理負担を軽減することが可能になる。

しかしながら、図２の例に示すように、複数の事業者端末５がマネージャ１にＡＰＩを送信する場合、他の事業者端末５が送信したＡＰＩに基づく処理の実行により、業務システムの動作状態が変化する場合がある。そのため、先にＡＰＩを送信した事業者端末５は、次のＡＰＩの送信を行うまでの間に発生した業務システムの動作状態の変化を、次のＡＰＩを送信するまで把握することができない。したがって、この場合、先にＡＰＩを送信した事業者端末５は、業務システムの動作状態の変化をリアルタイムに把握することができない。

そこで、本実施の形態では、図３に示すように、事業者端末５ａ、５ｂ及び５ｃとマネージャ１との間に情報処理装置６を設ける。この情報処理装置６は、例えば、図１に示す仮想マシン３の一部であってよい。

そして、情報処理装置６は、図３に示すように、例えば、マネージャ１の記憶部１ａにアクセスし、業務システムで動作するタスクの処理状況を示す情報（以下、タスク情報とも呼ぶ）を取得する。その後、情報処理装置６は、取得したタスク情報に基づいて決定した時間に、マネージャ１にＡＰＩを送信し、業務システムの動作状態の確認を行うための情報（以下、状態情報とも呼ぶ）を取得する。一方、情報処理装置６は、事業者端末５ａ、５ｂ及び５ｃから業務システムの状態情報の取得依頼（ＡＰＩ）を受信した場合、マネージャ１から取得した状態情報に基づいて返信を行う。

これにより、事業者端末５ａ、５ｂ及び５ｃは、業務システムの状態情報の取得を行う際に、マネージャ１に対してＡＰＩを送信する必要がなくなる。そのため、情報処理装置６は、マネージャ１が処理すべきＡＰＩの発生頻度を抑えることが可能になり、マネージャ１の処理負担を抑えることが可能になる。

［情報処理システムのハードウエア構成］
次に、情報処理システム１０の構成について説明する。図４は、情報処理装置のハードウエア構成を示す図である。情報処理装置６は、プロセッサであるＣＰＵ６０１と、メモリ６０２と、外部インターフェース（Ｉ／Ｏユニット）６０３と、記憶媒体６０４とを有する。各部は、バス６０５を介して互いに接続される。

記憶媒体６０４は、例えば、記憶媒体６０４内のプログラム格納領域（図示しない）に、業務システムの状態情報を管理するための処理（以下、情報管理処理とも呼ぶ）等を行うためのプログラム６１０を記憶する。

ＣＰＵ６０１は、図４に示すように、プログラム６１０の実行時に、プログラム６１０を記憶媒体６０４からメモリ６０２にロードし、プログラム６１０と協働して情報管理処理等を行う。

また、記憶媒体６０４は、例えば、情報管理処理等を行う際に用いられる情報を記憶する情報格納領域６３０（以下、記憶部６３０とも呼ぶ）を有する。

そして、図５は、事業者端末のハードウエア構成を示す図である。事業者端末５は、プロセッサであるＣＰＵ５０１と、メモリ５０２と、外部インターフェース（Ｉ／Ｏユニット）５０３と、記憶媒体５０４とを有する。各部は、バス５０５を介して互いに接続される。

記憶媒体５０４は、例えば、記憶媒体５０４内のプログラム格納領域（図示しない）に、業務システムの状態情報を取得するための処理（以下、情報取得処理とも呼ぶ）等を行うためのプログラム５１０を記憶する。

ＣＰＵ５０１は、図５に示すように、プログラム５１０の実行時に、プログラム５１０を記憶媒体５０４からメモリ５０２にロードし、プログラム５１０と協働して情報取得処理等を行う。

また、記憶媒体５０４は、例えば、情報取得処理等を行う際に用いられる情報を記憶する情報格納領域５３０（以下、記憶部５３０とも呼ぶ）を有する。

[情報処理装置のソフトウエア構成]
次に、情報処理装置６のソフトウエア構成について説明する。図６は、図４の情報処理装置の機能ブロック図である。ＣＰＵ６０１は、プログラム６１０と協働することにより、タスク情報取得部６１１と、時間決定部６１２と、状態情報取得部６１３と、取得依頼受信部６１４と、状態情報送信部６１５（以下、情報返信部６１５とも呼ぶ）として動作する。また、情報格納領域６３０には、タスク情報６３１と、状態情報６３２と、時間情報６３３とが記憶されている。

タスク情報取得部６１１は、例えば、マネージャ１の記憶部１ａにアクセスし、業務システムのタスク情報６３１を取得する。タスク情報６３１は、業務システムで実行しているタスクの進捗情報を含む情報である。

なお、図３に示す例において、タスク情報６３１は、マネージャ１の記憶部１ａに格納されているが、図６に示すように、情報処理装置６の情報格納領域６３０に格納されるものであってもよい。すなわち、タスク情報６３１は、情報処理装置６が取得することができる場所であれば、記憶部１ａ以外の場所（情報格納領域６３０）に格納されるものであってもよい。

時間決定部６１２は、タスク情報取得部６１１が取得したタスク情報６３１に基づき、マネージャ１から業務システムの状態情報６３２を取得すべき時間（以下、時間情報６３３とも呼ぶ）を決定する。状態情報６３２は、業務システムにおけるハードウエアスペックや、ディスクの現在の使用量等に含む情報である。時間決定部６１２が時間情報６３３を決定する際の具体例については後述する。

状態情報取得部６１３は、時間決定部６１２が決定した時間情報６３３が示す時間に、マネージャ１から業務システムの状態情報６３２を取得する。そして、状態情報取得部６１３は、マネージャ１から取得した状態情報６３２を情報格納領域６３０に記憶する。

取得依頼受信部６１４は、事業者端末５から、業務システムの状態情報６３２を取得するための取得依頼を受信する。事業者端末５は、状態情報６３２を取得することにより、例えば、システム管理者に対して、現在の業務システムの状態に関する情報を出力する。

状態情報送信部６１５は、事業者端末５から取得依頼を受信した場合に、情報格納領域６３０に記憶した状態情報６３２を事業者端末５に返信する。

[事業者端末のソフトウエア構成]
次に、事業者端末５のソフトウエア構成について説明する。図７は、図５の事業者端末の機能ブロック図である。ＣＰＵ５０１は、プログラム５１０と協働することにより、取得依頼送信部５１１と、状態情報受信部５１２として動作する。また、情報格納領域５３０には、状態情報５３１が記憶されている。

取得依頼送信部５１１は、例えば、所定時間間隔（例えば、２０（ｓ）毎）に、業務システムの状態情報６３２を取得するための取得依頼を、マネージャ１に対して送信する。

状態情報受信部５１２は、情報処理装置６が送信した状態情報６３２を受信する。そして、状態情報受信部５１２は、情報処理装置６から状態情報６３２を受信した場合、受信した状態情報６３２に基づき、情報格納領域５３０に記憶されている状態情報５３１の内容を更新する。

［第１の実施の形態の概略］
次に、第１の実施の形態の概略について説明する。図８及び図９は、第１の実施の形態における情報管理処理の概略を示すフローチャート図である。

［情報処理装置における処理］
初めに、情報処理装置６における処理について説明する。情報処理装置６は、図８に示すように、時間情報６３３を決定するタイミング（以下、時間決定タイミングとも呼ぶ）まで待機する（Ｓ１のＮＯ）。この時間決定タイミングは、例えば、定期的な間隔（例えば、５分間隔）であってよい。また、この時間決定タイミングは、例えば、後述するＳ４の処理が行われた直後であってよい。

そして、時間決定タイミングになった場合（Ｓ１のＹＥＳ）、情報処理装置６は、業務システムのタスクの処理状況に基づき、業務システムの状態情報６３２を取得する時間を決定する（Ｓ２）。具体的に、情報処理装置６は、例えば、マネージャ１から取得したタスク情報６３１を参照し、現在実行中であるタスクが存在するか否かを確認する。そして、現在実行中のタスクが存在した場合、情報処理装置６は、現在実行中のタスクが終了すると予測される時間を算出し、算出した時間を時間情報６３３として決定する。時間情報６３３を算出する際の具体例については後述する。

すなわち、本実施の形態における情報処理装置６は、業務システムにおいて実行中のタスクが存在することを確認した場合、そのタスクの実行が終了したことに応じて状態情報６３２の内容が更新される可能性が高いものと予測する。そして、情報処理装置６は、状態情報６３２が更新されるものと予測したタイミングを、時間情報６３３とすべき時間として決定する。これにより、情報処理装置６は、状態情報６３２の内容が更新された可能性が高いと予測される場合にのみマネージャ１にアクセスし、業務システムの状態情報６３２を取得することが可能になる。そのため、情報処理装置６は、状態情報６３２の取得依頼を受信することによるマネージャ１の処理負担を抑えることが可能になる。

次に、情報処理装置６は、Ｓ２で決定した時間情報６３３が示す時間になるまで待機する（Ｓ３のＮＯ）。そして、Ｓ２で決定した時間になった場合（Ｓ３のＹＥＳ）、情報処理装置６は、マネージャ１から業務システムの状態情報６３２を取得し、情報格納領域６３０に記憶する（Ｓ４）。具体的に、情報処理装置６は、マネージャ１に対してＡＰＩを送信することにより、業務システムの状態情報６３２の取得を行う。その後、情報処理装置６は、再度、時間決定タイミングになるまで待機する（Ｓ１）。

［事業者端末における処理］
次に、事業者端末５における処理について説明する。情報処理装置６は、図９に示すように、事業者端末５から状態情報６３２の取得依頼（ＡＰＩ）を受信するまで待機する（Ｓ１１のＮＯ）。そして、事業者端末５から状態情報６３２の取得依頼を受信した場合（Ｓ１１のＹＥＳ）、情報処理装置６は、情報格納領域６３０に記憶した状態情報６３２を、状態情報６３２の取得依頼を送信した事業者端末５に返信する（Ｓ１２）。

すなわち、情報処理装置６は、事業者端末５から状態情報６３２を取得するためのＡＰＩを受信した場合、マネージャ１に対して、状態情報６３２の取得を行うためのＡＰＩの送信を行わない。そして、情報処理装置６は、この場合、Ｓ４においてマネージャ１から取得した状態情報６３２を、状態情報６３２の取得依頼を送信した事業者端末５に返信する。これにより、本実施の形態における情報処理装置６は、マネージャ１が状態情報６３２の取得依頼を受信する頻度を抑えることが可能になり、マネージャ１の処理負担を抑えることが可能になる。

このように、第１の実施の形態によれば、情報処理装置６は、業務システムで実行されるタスクの処理状況に基づき、業務システムの状態情報６３２を取得する時間を決定する。そして、情報処理装置６は、決定した時間に、業務システムの状態情報を取得して記憶部６３０に記憶する。その後、事業者端末５から状態情報６３２の取得依頼を受信した場合に、情報処理装置６は、記憶部６３０に記憶した状態情報６３２を返信する。これにより、情報処理装置６は、マネージャ１が状態情報６３２の取得依頼を受信する頻度を抑えることが可能になり、マネージャ１の処理負担を抑えることが可能になる。

[第１の実施の形態の詳細]
次に、第１の実施の形態の詳細について説明する。図１０及び図１１は、第１の実施の形態における情報管理処理の詳細を説明するフローチャート図である。また、図１２は、第１の実施の形態における情報取得処理の詳細を説明するフローチャート図である。また、図１３から図２２は、第１の実施の形態における情報管理処理及び情報取得処理の詳細を説明する図である。図８、図９及び図１３から図２２を参照しながら、図１０から図１２の情報管理処理及び情報取得処理の詳細を説明する。

[第１の実施の形態における情報管理処理の詳細]
初めに、第１の実施の形態における情報管理処理の詳細について説明する。情報処理装置６のタスク情報取得部６１１は、タスク情報６３１の取得タイミングになるまで待機する（Ｓ２１のＮＯ、図８のＳ３のＮＯ）。タスク情報６３１の取得タイミングは、タスク情報取得部６１１がタスク情報６３１を前回取得した時間から、時間情報６３３に設定された時間が経過したタイミングであってよい。また、タスク情報６３１の取得タイミングは、情報処理装置６が事業者端末５から業務システムに対するタスクの実行依頼（ＡＰＩ）を受信し、受信した実行依頼をマネージャ１に送信した場合（業務システムにおいてタスクの実行が開始された場合）であってもよい。以下、時間情報６３３の具体例について説明する。

図１３は、時間情報６３３の具体例を説明する図である。図１３に示す時間情報６３３は、初期値を示す「初期値」と、次回適用すべき情報を示す「次回設定値」とを項目として有する。なお、「初期値」及び「次回設定値」に設定された値の単位は、例えば、「秒」である。そして、「次回設定値」に値が設定されている場合、タスク情報取得部６１１は、「次回設定値」に設定された値を参照する。一方、「次回設定値」に値が設定されていない場合（ブランクである場合）、タスク情報取得部６１１は、「初期値」に設定された値を参照する。

具体的に、図１３に示す時間情報６３３において、「初期値」には、「３０」が設定され、「次回設定値」はブランクになっている。そのため、この場合、タスク情報取得部６１１は、「初期値」に設定された値である「３０」を参照する。すなわち、図１３に示す例において、タスク情報取得部６３１は、情報管理処理の実行が前回完了した後、３０秒後にタスク情報６３１の取得を行う。

図１０に戻り、タスク情報６３１の取得タイミングになった場合（Ｓ２１のＹＥＳ）、タスク情報取得部６１１は、例えば、マネージャ１にアクセスし、タスク情報６３１を取得する（Ｓ２２、図８のＳ４）。以下、タスク情報６３１の具体例について説明する。

図１４は、タスク情報６３１の具体例である。図１４に示すタスク情報６３１は、各情報を識別する「ＩＤ」と、業務システムで実行中のタスクまたは実行が完了しているタスクの種別を示す「タスク種別」とを項目として有する。

図１４に示すタスク情報６３１において、「タスク種別」には、例えば、仮想マシンを作成するためのタスクの種別を示す「マシン作成」と、仮想マシンを停止するためのタスクの種別を示す「マシン停止」とが設定される。また、「タスク種別」には、例えば、複数の仮想マシン間を接続する仮想的なネットワークを削除するためのタスクの種別を示す「ネットワーク削除」が設定される。また、「タスク種別」には、例えば、仮想マシンが利用可能なディスク装置の数を追加するためのタスクの種別を示す「ディスク追加」と、仮想マシンが利用可能なディスク容量を拡張するためのタスクの種別を示す「ディスク拡張」とが設定される。

さらに、図１４に示すタスク情報６３１は、各タスクの実行の開始時間である「開始時間」と、各タスクの実行の終了時間である「終了時間」と、各タスクの進捗状況を示す「進捗状況」とを項目として有する。

具体的に、図１４に示すタスク情報６３１において、「ＩＤ」が「１」である情報には、「タスク種別」として「マシン作成」が設定されており、「開始時間」として「２０１４−０１−０１ ００：００：００」が設定されている。また、「ＩＤ」が「１」である情報には、「終了時間」として「２０１４−０１−０１ ００：１０：０３」が設定されており、「進捗状況」として「１００％」が設定されている。なお、図１４のタスク情報６３１に含まれる「進捗情報」は、全て「１００％」である。そのため、図１４に示すタスク情報６３１は、現在実行中であるタスクが存在しないことを示している。図１４の他の情報については説明を省略する。

図１０に戻り、情報処理装置６の状態情報取得部６１３は、Ｓ２２で取得したタスク情報６３１を参照し、例えば、タスク情報取得部６３１が前回取得したタスク情報６３１（情報格納領域６３０に記憶されているタスク情報６３１）と比較を行う。そして、状態情報取得部６１３は、新たに実行が終了しているタスクが存在するか否かを判定する（Ｓ２３のＮＯ）。

具体的に、状態情報取得部６１３は、情報格納領域６３０に記憶されているタスク情報６３１には含まれていないが、新たに取得したタスク情報６３１には含まれている情報であって、「進捗状況」に「１００％」が設定されているタスクが存在するか否かを判定する。そして、この条件に当てはまるタスクが存在する場合、状態情報取得部６１３は、新たに実行が終了しているタスクが存在すると判定する。

その結果、新たに実行が終了しているタスクが存在すると判定した場合（Ｓ２３のＹＥＳ）、状態情報取得部６１３は、マネージャ１から状態情報６３２の取得を行う（Ｓ２４）。一方、新たに実行が終了しているタスクが存在しない場合（Ｓ２３のＹＥＳ）、状態情報取得部６１３は、状態情報６３２の取得を行わない。

すなわち、状態情報取得部６１３は、新たに実行が終了しているタスクが存在すると判定した場合（Ｓ２３のＹＥＳ）、前回状態情報６３２を取得したときから、業務システムの状態情報６３２の内容が更新されている可能性が高いと判定する。そのため、状態情報取得部６１３は、この場合、マネージャ１にアクセスして状態情報６３２の取得を行う。一方、新たに実行が終了しているタスクが存在しないと判定した場合（Ｓ２３のＮＯ）、状態情報取得部６１３は、前回状態情報６３２を取得したときから、業務システムの状態情報６３２の内容が更新されている可能性が低いと判定する。そのため、状態情報取得部６１３は、この場合、状態情報６３２の取得を行わない。

これにより、状態情報取得部６１３は、マネージャ１に対して状態情報６３２の取得依頼を送信する頻度を抑えることが可能になる。そのため、状態情報取得部６１３は、マネージャ１の処理負担をより抑えることが可能になる。以下、Ｓ２３の処理の具体例を説明する。

図１５は、図１４に示す状態の後に取得したタスク情報６３１の具体例である。図１５に示すタスク情報６３１は、図１４に示すタスク情報６３１と比較して、「ＩＤ」が「１１」である情報のみが追加されている（図１５の下線部分）。そして、「ＩＤ」が「１１」である情報には、「進捗状況」として「１００％」が設定されている。すなわち、「ＩＤ」が「１１」である情報に対応するタスクは、図１４に示すタスク情報６３１が取得された後であって、図１５に示すタスク情報６３１が取得される前に、実行が開始して終了したタスクである。したがって、図１５に示す例において、状態情報取得部６１３は、前回タスク情報６３１を取得してから状態情報６３２が更新された可能性が高いと判定し、状態情報６３２の取得を行う（Ｓ２３のＹＥＳ、Ｓ２４）。図１５の他の情報については説明を省略する。

次に、状態情報６３２の具体例について説明する。図１６は、状態情報６３２の具体例を説明する図である。なお、図１６に示す状態情報６３２においては、業務システムが、２台の仮想マシン（マシンＡ、マシンＢ）と、２つのネットワーク（ネットワークＡ、ネットワークＢ）と、１台のストレージ（ストレージＡ）とから構成される場合について説明を行う。

図１６に示す状態情報６３２は、各情報を識別する「ＩＤ」と、各情報のカテゴリを示す「カテゴリ」と、各情報に対応するマシン等の名称を示す「名称」と、各情報の項目名を示す「項目名」と、各情報の現在の状態を示す「現在の情報」とを項目として有する。

具体的に、図１６に示す状態情報６３２において、「ＩＤ」が「１」から「４」である情報は、「カテゴリ」が「マシン」であり、「名称」が「マシンＡ」である仮想マシンに関する情報である。そして、「ＩＤ」が「１」である情報には、「ＣＰＵ数」として「８」が設定され、「ＩＤ」が「２」である情報には、「ＣＰＵ周波数」として「３．０（ＧＨｚ）」が設定されている。また、「ＩＤ」が「３」である情報には、「メモリ容量」として「１６（ＧＢ）」が設定され、「ＩＤ」が「４」である情報には、「ディスク容量」として「３２０（ＧＢ）」が設定されている。

そして、例えば、「名称」が「マシンＡ」である仮想マシンにおいて、「タスク種別」が「ディスク追加」であるタスクが実行された場合、ディスク容量が増加することになる。そのため、この場合、図１７に示すように、「名称」が「マシンＡ」である情報の「ディスク容量」に設定される値は増加する。具体的に、図１７に示す例において、「名称」が「マシンＡ」である情報の「ディスク容量」は、「４８０（ＧＢ）」に更新されている（図１７の下線部分）。

さらに、例えば、「名称」が「マシンＢ」である仮想マシンにおいて、「タスク種別」が「マシン作成」であるタスクが実行された場合、ストレージのディスクが使用されることになる。そのため、この場合、図１８に示すように、「名称」が「ストレージＡ」である情報の「使用容量」に設定される値は増加する。具体的に、図１８に示す例において、「名称」が「ストレージＡ」である情報の「使用容量」は、「１１５０（ＧＢ）」に更新されている（図１８の下線部分）。

すなわち、情報処理装置６は、業務システムで実行されるタスクの終了に応じて状態情報６３２の取得を行うことにより、更新が行われた後の状態情報６３２を効率的に取得することが可能になる。そのため、情報処理装置６は、状態情報６３２を受信することによるマネージャ１の処理負担の抑えることが可能になる。図１６から図１８の他の情報については説明を省略する。

図１０に戻り、情報処理装置６の時間決定部６１２は、Ｓ２２で取得したタスク情報６３１を参照し、現在実行中であるタスクが存在するか否かを判定する（Ｓ２５）。具体的に、時間決定部６１２は、「進捗状況」に「１００％」が設定されていないタスクが存在するか否かを判定する。そして、この条件に合致するタスクが存在する場合、状態情報取得部６１３は、新たに実行が終了しているタスクが存在すると判定する。

その結果、現在実行中であるタスクが存在する場合（Ｓ２５のＹＥＳ）、時間決定部６１２は、現在実行中のタスクの実行予測時間を算出（予測）する（Ｓ２６、図８のＳ１及びＳ２）。

図１９は、図１５の後に取得したタスク情報６３１の具体例である。図１９に示すタスク情報６３１は、図１５に示すタスク情報６３１と比較して、「ＩＤ」が「１２」及び「１３」である情報が追加されている（図１９の下線部分）。そして、「ＩＤ」が「１２」である情報には、「進捗状況」として「１００％」が設定されている。すなわち、「ＩＤ」が「１２」である情報に対応するタスクは、図１５に示すタスク情報６３１が取得された後であって、図１９に示すタスク情報６３１が取得される前に、実行が開始して終了したタスクである（Ｓ２３のＹＥＳ、Ｓ２４）。

一方、「ＩＤ」が「１３」である情報には、「進捗状況」として「２５％」が設定されている。さらに、「ＩＤ」が「１３」である情報には、「終了時間」が設定されていない。そのため、「ＩＤ」が「１３」である情報に対応するタスクは、図１５に示すタスク情報６３１が取得された後であって、図１９に示すタスク情報６３１が取得される前に実行が開始したタスクである。そして、「ＩＤ」が「１３」である情報に対応するタスクは、現在も実行中であるタスクである。したがって、図１９に示す例において、時間決定部６１２は、「ＩＤ」が「１３」である情報に対応するタスクを現在実行中のタスクとして判定し、実行予測時間の算出を行う（Ｓ２５のＹＥＳ、Ｓ２６）。

[タスクの実行予測時間算出の具体例]
次に、現在実行中のタスクの実行予測時間を算出する際の具体例を説明する。

時間決定部６１２は、例えば、各タスクが過去に実行された際の実行時間の平均値を求めることにより、現在実行中のタスクの実行予測時間を算出する。具体的に、図１９に示す例において、「タスク種別」が「マシン作成」である情報は、「ＩＤ」が「１」、「６」及び「１０」である情報である。そして、「ＩＤ」が「１」である情報の「開始時間」は、「２０１４−０１−０１ ００：００：００」であり、「終了時間」は、「２０１４−０１−０１ ００：１０：０３」である。そのため、「ＩＤ」が「１」である情報に対応するタスクは、実行完了するまでに１０分３秒を要したことになる。また、「ＩＤ」が「６」である情報の「開始時間」は、「２０１４−０１−０４ ００：０２：００」であり、「終了時間」は、「２０１４−０１−０４ ００：１２：１０」である。そのため、「ＩＤ」が「６」である情報に対応するタスクは、実行完了するまでに１０分１０秒を要したことになる（以下、この時間を実行所要時間とも呼ぶ）。さらに、「ＩＤ」が「１０」である情報の「開始時間」は、「２０１４−０１−０５ １０：２３：００」であり、「終了時間」は、「２０１４−０１−０５ １０：３２：５９」である。そのため、「ＩＤ」が「１０」である情報に対応するタスクは、実行完了するまでに９分５９秒を要したことになる。

したがって、時間決定部６１２は、例えば、「タスク種別」が「マシン作成」であるタスクの実行予測時間として、１０分３秒と、１０分１０秒と、９分５９秒との平均である１０分４秒を算出する。これにより、時間決定部６１２は、「タスク種別」が「マシン作成」であるタスクが今後発生した場合、そのタスクの実行予測時間は１０分４秒であると予測することが可能になる。

図１０に戻り、時間決定部６１２は、Ｓ２６で算出した実行予測時間に基づき、時間情報６３３の更新を行う（Ｓ２７）。時間決定部６１２は、例えば、Ｓ２６で算出した実行予測時間と、現在実行中のタスクの「進捗状況」とから、時間情報６３３の「次回設定値」に設定すべき値の算出を行う。

具体的に、図１９のタスク情報６３１の「ＩＤ」が「１３」である情報において、「進捗状況」として「２５％」が設定されている。また、「タスク種別」が「マシン作成」であるタスクの実行予測時間は、上記の例においては、１０分４秒である。そのため、時間決定部６１２は、この場合、１０分４秒（６０４秒）に「２５％」を乗算した結果である２分３１秒（１５１秒）を、「ＩＤ」が「１３」であるタスクの実行が開始された時間（以下、実行開始時間とも呼ぶ）から経過した時間として算出する。さらに、時間決定部６１２は、１０分４秒（６０４秒）から２分３１秒（１５１秒）を減算した結果である７分３３秒（４５３秒）を、「ＩＤ」が「１３」であるタスクの実行が終了するまでにさらに要する時間として算出する。そして、時間決定部６１２は、図２０に示すように、時間情報６３３の「次回設定値」に、「４５３」を設定する。

すなわち、この場合、タスク情報取得部６３１は、時間決定部６１２が時間情報６３３の「次回設定値」の更新を行ってから４５３秒後に、再びタスク情報６３１の取得を行う（Ｓ２１のＹＥＳ、Ｓ２２）。

なお、時間決定部６１２は、図２１に示すように、実行中のタスクの「開始時間」に設定された時間に、実行予測時間を加算した時間（以下、実行終了時間とも呼ぶ）を、時間情報６３３の「次回設定値」に設定するものであってもよい。この場合、タスク情報取得部６３１は、現在の時間が時間情報６３３の「次回設定部」に設定された時間になったときに、再びタスク情報６３１の取得を行う（Ｓ２１のＹＥＳ、Ｓ２２）。

具体的に、図１９のタスク情報６３１の「ＩＤ」が「１３」である情報において、「開始時間」には、「２０１４−０１−０６ ０８：５７：００」が設定されている。また、「タスク種別」が「マシン作成」であるタスクの実行予測時間は、上記の例においては、１０分４秒である。そのため、時間決定部６１２は、この場合、「開始時間」に設定された時間の１０分４秒後の時間である２０１４年１月６日９時７分４秒を、実行終了時間として算出する。そして、時間決定部６１２は、図２１に示すように、時間情報６３３の「次回設定値」に、「２０１４−０１−０６ ０９：０７：０４」を設定する。

一方、図１０に示すように、現在実行中であるタスクが存在しない場合（Ｓ２５のＮＯ）、時間決定部６１２は、現在実行中のタスクの実行終了時間の算出及び時間情報６３３の更新を行わない。

図２２は、図１９の後に取得したタスク情報６３１の具体例である。図２２に示すタスク情報６３１は、図１９に示すタスク情報６３１と比較して、「ＩＤ」が「１３」である情報の「終了時間」に「２０１４−０１−０６ ０９：５７：０４」が設定され、「進捗状況」が「１００％」に設定されている。すなわち、図２２に示すタスク情報６３１では、図１９に示すタスク情報６３１において実行中であった「ＩＤ」が「１３」であるタスクの実行が完了している（Ｓ２３のＹＥＳ）。したがって、この場合、状態情報取得部６１３は、次回タスク情報６３１の取得が行われた後に、業務システムの状態情報６３２の取得を行う（Ｓ２２、Ｓ２３のＹＥＳ、Ｓ２４）。

このように、情報処理装置６は、業務システムで動作するタスクの実行が終了したことに応じて状態情報６３２の取得を行うことにより、前回取得した状態情報６３２から更新されている可能性が高い状態情報６３２を取得することが可能になる。そのため、情報処理装置６は、マネージャ１に状態情報６３２の取得依頼を送信する回数を抑制しながら、効率的に状態情報６３２の取得を行うことが可能になる。

[第１の実施の形態における情報取得処理の詳細]
次に、第１の実施の形態における情報管理処理の詳細について説明する。図１１は、情報処理装置６における処理を説明するフローチャート図である。

情報処理装置６の取得依頼受信部６１４は、事業者端末５から業務システムの状態情報６３２の取得依頼（ＡＰＩ）を受信するまで待機する（Ｓ３１のＮＯ、図９のＳ１１のＮＯ）。そして、状態情報６３２の取得依頼を受信した場合（Ｓ３１のＹＥＳ、図９のＳ１１のＮＯ）、情報処理装置６の状態情報送信部６１５は、情報格納領域６３０に記憶した状態情報６３２を、状態情報６３２の取得依頼を送信した事業者端末５に送信する（Ｓ３２、図９のＳ１２）。

すなわち、情報処理装置６は、業務システムの状態情報６３２の取得依頼を事業者端末５から取得した場合、その取得依頼をマネージャ１に送信せず、図１０のＳ２４において予め取得しておいた状態情報６３２を事業者端末５に送信する。

これにより、多数の事業者端末５が、定期的に業務システムに対する状態情報６３２の取得依頼を送信する場合であっても、情報処理装置６は、状態情報６３２の取得依頼を受信した際に、送信された取得依頼をマネージャ１に送信する必要がない。そのため、情報処理装置６は、マネージャ１の処理負担を抑えることが可能になる。

一方、図１２は、事業者端末５における情報取得処理を説明するフローチャート図である。事業者端末５の取得依頼送信部５１１は、状態情報６３２の取得タイミングまで待機する（Ｓ４１のＮＯ）。この状態情報６３２の取得タイミングは、例えば、事業者端末５の表示装置（図示しない）における表示内容の更新頻度毎（例えば、２０（ｓ）毎）であってよい。そして、状態情報６３２の取得タイミングになった場合（Ｓ４１のＹＥＳ）、取得依頼送信部５１１は、情報処理装置６に状態情報６３２の取得依頼を送信する（Ｓ４２）。

すなわち、情報処理装置６は、上記のように、事業者端末５から受信した業務システムの状態情報６３２の取得依頼をマネージャ１に送信しない。そのため、事業者端末５は、マネージャ１の負荷を考慮することなく、必要なタイミングで状態情報６３２の取得依頼の送信を行うことが可能になる。

その後、事業者端末５の状態情報受信部５１２は、情報処理装置６から状態情報６３２を取得するまで待機する（Ｓ４３のＮＯ）。そして、状態情報６３２を取得した場合（Ｓ４３のＹＥＳ）、状態情報受信部５１２は、受信した状態情報６３２を、状態情報５３１として情報格納領域５３０に記憶する。これにより、事業者端末５は、記憶した状態情報５３１に基づいて、表示装置の表示内容の更新を行うことが可能になる。

上記のように、第１の実施の形態によれば、情報処理装置６は、業務システムで実行されるタスクの処理状況に基づき、業務システムの状態情報６３２を取得する時間を決定する。そして、情報処理装置６は、決定した時間に、業務システムの状態情報を取得して記憶部６３０に記憶する。その後、事業者端末５から状態情報６３２の取得依頼を受信した場合に、情報処理装置６は、記憶部６３０に記憶した状態情報６３２を返信する。

すなわち、複数の事業者端末５がそれぞれマネージャ１に対してＡＰＩを送信する場合、各事業者端末５は、他の事業者端末５によるＡＰＩの送信を検知することができない。そのため、各事業者端末５は、他の事業者端末５によるＡＰＩの送信に伴って状態情報６３２の更新があった場合、更新後の状態情報６３２を迅速に取得するために、マネージャ１に対して頻繁に状態情報６３２を取得するためのＡＰＩを送信する必要がある。その結果、受信したＡＰＩに対する処理の実行によって、マネージャ１の処理負担は増加する。

これに対し、本実施の形態における情報処理装置６は、マネージャ１に代わって事業者端末５からのＡＰＩの受信を行う。さらに、情報処理装置６は、タスク情報６３１に基づき、必要最低限の回数のみマネージャ１に対して状態情報６３２の取得依頼を送信する。これにより、マネージャ１は、状態情報６３２の取得依頼の受信に伴う処理負担の増加を抑えることが可能になる。

以上の実施の形態をまとめると、以下の付記のとおりである。

（付記１）
業務システムから取得した該業務システムで実行されるタスクの処理状況に基づき、前記業務システムから該業務システムの状態情報を取得する時間を決定する時間決定部と、
決定した前記取得する時間に、前記状態情報を取得して記憶部に記憶する情報取得部と、
前記業務システムの監視を行う１または複数の監視装置のいずれかから前記状態情報の取得依頼を受信した場合に、前記記憶部に記憶した前記状態情報を返信する情報返信部と、を有する、
情報処理装置。

（付記２）
付記１において、
前記情報取得部は、前記状態情報の取得を前回行った際に前記業務システムにおいて実行中であったタスクのうち、実行が終了したタスクが存在する場合に、前記状態情報の取得を行う、
情報処理装置。

（付記３）
付記１において、
前記タスクの処理状況は、前記業務システムにおいて実行中のタスクが存在するか否かを示す情報であり、
前記時間決定部は、前記実行中のタスクが存在する場合、前記実行中のタスクの実行開始時間から前記実行中のタスクの実行予測時間が経過した時間である実行終了時間を、前記状態情報を取得する時間として決定する、
情報処理装置。

（付記４）
付記３において、
前記実行予測時間は、前記業務システムにおいて実行される各タスクが、過去に実行された際の実行所要時間の平均である、
情報処理装置。

（付記５）
付記１において、
前記時間決定部は、所定の時間間毎に、前記状態情報を取得する時間を決定する、
情報処理装置。

（付記６）
付記１において、
前記時間決定部は、前記業務システムにおいてタスクの実行が開始された場合に、前記状態情報を取得する時間を決定する、
情報処理装置。

（付記７）
付記１において、
前記タスクは、前記監視装置が前記業務システムに対して実行を依頼したタスクである、
情報処理装置。

（付記８）
付記１において、
前記監視装置は、前記業務システムに対して前記取得依頼を定期的に送信する、
情報処理装置。

（付記９）
業務システムから取得した該業務システムで実行されるタスクの処理状況に基づき、前記業務システムから該業務システムの状態情報を取得する時間を決定し、
決定した前記時間に、前記状態情報を取得して記憶部に記憶し、
前記業務システムの監視装置から前記状態情報の取得依頼を受信した場合に、前記記憶部に記憶した前記状態情報を返信する、
処理をコンピュータに実行させるプログラム。

（付記１０）
情報処理装置と、
該情報処理装置と通信可能な監視装置とを有し、
前記情報処理装置は、業務システムから取得した該業務システムで実行されるタスクの処理状況に基づき、前記業務システムから該業務システムの状態情報を取得する時間を決定し、
前記情報処理装置は、決定した前記時間に、前記状態情報を取得して記憶部に記憶し、
前記監視装置は、前記情報処理装置に対して前記状態情報の取得依頼を送信し、
前記情報処理装置は、前記監視装置から前記状態情報の取得依頼を受信した場合に、前記記憶部に記憶した前記状態情報を返信する、
情報処理システム。

１：マネージャ ２：物理マシン
３：仮想マシン ４：仮想化ソフトウエア
５：事業者端末 １０：情報処理システム

Claims (6)

1. 業務システムから取得した該業務システムで実行されるタスクの処理状況に基づき、前記業務システムから該業務システムの状態情報を取得する時間を決定する時間決定部と、
   決定した前記取得する時間に、前記状態情報を取得して記憶部に記憶する情報取得部と、
   前記業務システムの監視を行う１または複数の監視装置のいずれかから前記状態情報の取得依頼を受信した場合に、前記記憶部に記憶した前記状態情報を返信する情報返信部と、を有する、
   情報処理装置。
2. 請求項１において、
   前記情報取得部は、前記状態情報の取得を前回行った際に前記業務システムにおいて実行中であったタスクのうち、実行が終了したタスクが存在する場合に、前記状態情報の取得を行う、
   情報処理装置。
3. 請求項１において、
   前記タスクの処理状況は、前記業務システムにおいて実行中のタスクが存在するか否かを示す情報であり、
   前記時間決定部は、前記実行中のタスクが存在する場合、前記実行中のタスクの実行開始時間から前記実行中のタスクの実行予測時間が経過した時間である実行終了時間を、前記状態情報を取得する時間として決定する、
   情報処理装置。
4. 請求項３において、
   前記実行予測時間は、前記業務システムにおいて実行される各タスクが、過去に実行された際の実行所要時間の平均である、
   情報処理装置。
5. 業務システムから取得した該業務システムで実行されるタスクの処理状況に基づき、前記業務システムから該業務システムの状態情報を取得する時間を決定し、
   決定した前記時間に、前記状態情報を取得して記憶部に記憶し、
   前記業務システムの監視装置から前記状態情報の取得依頼を受信した場合に、前記記憶部に記憶した前記状態情報を返信する、
   処理をコンピュータに実行させるプログラム。
6. 情報処理装置と、
   該情報処理装置と通信可能な監視装置とを有し、
   前記情報処理装置は、業務システムから取得した該業務システムで実行されるタスクの処理状況に基づき、前記業務システムから該業務システムの状態情報を取得する時間を決定し、
   前記情報処理装置は、決定した前記時間に、前記状態情報を取得して記憶部に記憶し、
   前記監視装置は、前記情報処理装置に対して前記状態情報の取得依頼を送信し、
   前記情報処理装置は、前記監視装置から前記状態情報の取得依頼を受信した場合に、前記記憶部に記憶した前記状態情報を返信する、
   情報処理システム。

Images