JP2020154866A - 情報処理システム、情報処理装置およびプログラム - Google Patents

Abstract

【課題】複数のサービスを連携させて提供される連携サービスの品質の低下を抑制しながら、連携サービスの提供に掛かる費用の低減を図る。【解決手段】情報処理システムは、複数のサービスを連携させた連携サービスを提供する提供手段と、連携サービスを構成するサービス毎に、サービスを提供する計算機のリソースの処理時間を特定する特定手段と、特定した処理時間の情報を用いて、サービス毎にリソースの削減を指示する指示手段と、を備える情報処理システムである。【選択図】図１

Description

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

例えば特許文献１には、物理計算機の計算機リソースを仮想計算機に割り当てる仮想化部と、１以上の仮想計算機でサービスを提供する仮想計算機群を制御する管理計算機と、を備えた計算機システムであって、管理計算機は、サービスを提供する仮想計算機群の性能を取得して、取得した前記仮想計算機群の性能と、予め設定された前記サービスの性能条件とを比較し、比較結果に応じて、仮想計算機群で変更する計算機リソースを決定する制御部と、変更の対象となる計算機リソースに応じた仮想計算機でサービスを試行して、仮想計算機の性能を測定する性能測定部と、を有し、制御部は、測定した性能がサービスの性能条件を満たす場合には変更を適用する計算機システムが記載されている。

特開２０１６−１０３１７９号公報

ここで、複数のサービスを連携させた連携サービスを提供するシステムがある。そして、連携サービスを構成する各サービスは、それぞれ計算機のリソースによって提供されている。ここで、リソースの利用に係わる費用を抑えるために、リソースを削減することが考えられる。しかしながら、連携サービスにおけるリソースを単に削減すると、連携サービスの全体としての品質が低下するおそれがある。
本発明は、複数のサービスを連携させて提供される連携サービスの品質の低下を抑制しながら、連携サービスの提供に掛かる費用の低減を図ることを目的とする。

請求項１に記載の発明は、複数のサービスを連携させた連携サービスを提供する提供手段と、前記連携サービスを構成する前記サービス毎に、当該サービスを提供する計算機のリソースの処理時間を特定する特定手段と、特定した前記処理時間の情報を用いて、前記サービス毎に前記リソースの削減を指示する指示手段と、を備える情報処理システムである。
請求項２に記載の発明は、前記指示手段は、前記処理時間が予め定められた設定時間に含まれる範囲内で前記リソースの増減を指示する請求項１に記載の情報処理システムである。
請求項３に記載の発明は、前記指示手段は、前記設定時間よりも処理時間が短い前記サービスの前記リソースの削減を指示する請求項２に記載の情報処理システムである。
請求項４に記載の発明は、前記指示手段は、前記連携サービスのうちの第１のサービスを提供する第１のリソースの処理時間が、当該連携サービスのうちの第２のサービスを提供する第２のリソースの処理時間よりも短い場合に、当該第１のリソースの削減を指示する請求項３に記載の情報処理システムである。
請求項５に記載の発明は、前記連携サービスにおける前記リソースの費用に関する費用情報を取得する費用情報取得手段を備え、前記指示手段は、前記連携サービスの前記リソースの合計費用が予め定められた設定費用に含まれる範囲内で、前記設定時間よりも当該処理時間の長い前記サービスの前記リソースの追加を指示する請求項２に記載の情報処理システムである。
請求項６に記載の発明は、前記指示手段は、前記設定費用を超えて前記リソースの追加が必要となる場合に、システムを管理する管理ユーザに対して予め定められた通知行うことを指示する請求項５に記載の情報処理システムである。
請求項７に記載の発明は、複数のサービスを連携させた連携サービスを提供する提供手段から、当該連携サービスを構成する前記サービス毎に、当該サービスを提供する計算機のリソースの処理時間を取得する取得手段と、前記処理時間に関して各々の前記サービス単位での許容時間の設定をユーザから受け付ける受付手段と、前記許容時間に基づいて削減された前記リソースに関する情報を前記処理時間とともに前記サービス毎に画面に表示する表示手段と、を備える情報処理装置である。
請求項８に記載の発明は、前記受付手段は、前記連携サービスにおける前記リソースの合計費用に関して、ユーザが許容する許容費用の設定を受け付けることを特徴とする請求項７に記載の情報処理装置である。
請求項９に記載の発明は、複数のサービスを連携させた連携サービスを提供する提供手段から、当該連携サービスを構成する当該サービス毎に、当該サービスを提供する計算機のリソースの処理時間を取得する取得手段と、特定した前記処理時間の情報を用いて、前記サービス毎に前記リソースの削減を指示する指示手段と、を備える情報処理装置である。
請求項１０に記載の発明は、コンピュータに、複数のサービスを連携させた連携サービスを提供する提供手段から、当該連携サービスを構成する当該サービス毎に、当該サービスを提供する計算機のリソースの処理時間を取得する機能と、特定した前記処理時間の情報を用いて、前記サービス毎に前記リソースの削減を指示する機能と、を実現させるプログラムである。
請求項１１に記載の発明は、コンピュータに、複数のサービスを連携させた連携サービスを提供する提供手段から、当該連携サービスを構成する当該サービス毎に、当該サービスを提供する計算機のリソースの処理時間を取得する機能と、前記処理時間に関して各々の前記サービス単位での許容時間の設定をユーザから受け付ける機能と、前記許容時間に基づいて削減された前記リソースに関する情報を前記処理時間とともに前記サービス毎に画面に表示させる機能と、を実現させるプログラムである。

請求項１、７、９、１０および１１の発明によれば、複数のサービスを連携させて提供される連携サービスの品質の低下を抑制しながら、連携サービスの提供に掛かる費用の低減を図ることができる。
請求項２の発明によれば、サービスの品質を担保する範囲内で、リソースの設定を動的に行うことができる。
請求項３の発明によれば、設定時間との比較に基づいて、リソースの削除を行うことができる。
請求項４の発明によれば、複数のリソース間の比較に基づいて、リソースの削除を行うことができる。
請求項５の発明によれば、予め定められた費用の範囲内で、リソースの設定を動的に行うことができる。
請求項６の発明によれば、例えばサービスを提供する管理ユーザの確認のうえで、予め定められた費用を超えるリソースの追加を行うことが可能になる。
請求項８の発明によれば、例えばサービスを提供する管理ユーザが許容するリソースの合計費用の設定を画面にて容易に行うことができる。

本実施形態の情報処理システムの全体構成を示す図である。 設定受付部が表示するＵＩ画面の表示例である。 本実施形態の情報処理システムの動作フローの一例である。 （Ａ）および（Ｂ）は、リソースの削除処理が行われる際に表示されるＵＩ画面の一例である。 （Ａ）および（Ｂ）は、リソースの削除処理が行われる際に表示されるＵＩ画面の一例である。 （Ａ）および（Ｂ）は、リソースの追加処理が行われる際に表示されるＵＩ画面の一例である。 （Ａ）および（Ｂ）は、費用再設定処理が行われる際に表示されるＵＩ画面の一例である。 本実施形態のクライアント端末、サービス部およびリソース管理部等を実現するコンピュータのハードウェア構成例を示す図である。

以下、添付図面を参照して、本実施形態について詳細に説明する。
＜情報処理システム１の全体構成＞
図１は、本実施形態の情報処理システム１の全体構成を示す図である。
図１に示すように、本実施形態の情報処理システム１は、サービスを利用するクライアント端末１０と、クライアントが利用するサービスを提供するサービス部２０と、サービス部２０の計算機のリソースを管理するリソース管理部３０と、を備える。そして、本実施形態において、クライアント端末１０は、ネットワークを介して、サービス部２０と接続している。また、サービス部２０は、ネットワークを介して、リソース管理部３０と接続している。

また、本実施形態のネットワークは、情報処理システム１を構成する装置間のデータ通信に用いられる通信ネットワークである。ネットワークは、データの送受信が可能であれば、その種類は特に限定されず、例えばインターネット、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等として良い。データ通信に用いられる通信回線は、有線であっても無線であっても良い。また、各々の装置は、複数のネットワークや通信回線を介して接続されるように構成しても良い。

［クライアント端末１０］
クライアント端末１０は、サービス部２０が提供するサービスを利用するための端末装置である。すなわち、クライアント端末１０は、本実施形態の情報処理システム１を利用する利用者（以下、エンドユーザと呼ぶ）が使用する端末装置である。具体的には、クライアント端末１０は、例えば、パーソナル・コンピュータ、タブレット端末やスマートフォン等の携帯型情報端末、その他、ネットワークを介してサービス部２０に接続し、サービス部２０によって実現されるサービスを利用し得る情報端末である。
なお、以下の説明において、本実施形態の情報処理システム１においてサービスの提供者であって、サービス部２０を管理したり、リソース管理部３０を利用したりするユーザを「管理ユーザ」と呼ぶ。

［サービス部２０］
サービス部２０（提供手段の一例）は、クライアント端末１０とのサービスのやり取りを管理するサービス管理部２１と、複数のサービスが連携する連携サービスを提供する連携サービス部２２と、を有している。

サービス管理部２１は、クライアント端末１０を介して情報処理システム１のエンドユーザから処理の要求を受け取る。そして、サービス管理部２１は、エンドユーザからの要求内容に応じて、連携サービス部２２に対してサービスの処理の依頼を行う。サービス管理部２１は、連携サービス部２２の処理結果をエンドユーザに送ることで、エンドユーザに対してサービスを提供する。
また、本実施形態のサービス管理部２１は、後述するリソース制御部３２からの指示に基づいて、連携サービス部２２における計算機のリソースの追加や削除を実行する。

連携サービス部２２は、エンドユーザを管理するユーザ管理部２２１と、文書ファイルを管理する文書管理部２２２と、業務の流れを管理する業務プロセス管理部２２３と、メールによる通知を行うメール通知部２２４と、を有している。
ここで、本実施形態の説明において、ユーザ管理部２２１、文書管理部２２２、業務プロセス管理部２２３およびメール通知部２２４を、個々に区別しない場合には、各々の構成部のことを「サービス処理部」と呼ぶ。

そして、連携サービス部２２を構成する各々のサービス処理部は、それぞれ個別に処理を実行することで、エンドユーザに対してサービスを提供することが可能である。さらに、本実施形態の連携サービス部２２は、複数のサービス処理部が連携することで一の機能としての連携サービスをエンドユーザに提供することが可能になっている。
なお、本実施形態の連携サービス部２２を構成する複数のサービス処理部の構成は、あくまでも一例であり、それぞれ必須ではない。また、連携サービス部２２を構成するサービス処理部は、本実施形態で示すサービスの他に、他のサービスを行うものが含まれていても構わない。

また、各サービス処理部は、それぞれ計算機のリソースの処理によって実現される。計算機のリソースとは、サービスを提供するための情報処理に費やす資源である。例えば、計算機のリソースは、ＣＰＵ（Central Processing Unit）、メインメモリ、記憶装置などのコンピュータのハードウェアを例示できる。また、計算機のリソースには、物理的な装置に限定されず、ネットワークの帯域幅、メモリ空間、ＣＰＵ時間など仮想的な資源の概念も含まれる。

ここで、計算機のリソースは、例えばＣＰＵの個数が増えるなど物理的なハードウェアの個数や量が多いほど処理能力が高くなる。また、計算機のリソースは、ＣＰＵ性能など、ハードウェアが高性能になるほど処理能力が高くなる。さらに、計算機のリソースは、例えばＣＰＵを利用可能な時間が長いほど処理能力が高くなる。そして、計算機のリソースは、例えば利用可能なメモリ空間が大きいなど、利用可能な仮想的な量が大きいほど処理能力が高くなる。

なお、本実施形態のサービス部２０のように複数のサービスが連携する連携サービスを提供するシステムでは、複数のサービス処理部が並列で処理を実行する。そのため、連携サービスとしての処理時間は、連携サービスを構成する複数のサービス処理部のうち最も処理時間が長いサービス処理部に引っ張られて、そのサービス処理部の処理時間になる場合がある。

続いて、連携サービス部２２を構成する各サービス処理部について詳細に説明する。
ユーザ管理部２２１は、サービスの利用者である複数のエンドユーザを管理する。ユーザ管理部２２１は、図示しないユーザ管理テーブルを用いて、エンドユーザのアカウント情報や、各サービスの利用権限などを管理する。そして、ユーザ管理部２２１は、新たなエンドユーザの登録の要求があった場合には、そのエンドユーザを新規に登録する。また、ユーザ管理部２２１は、登録されているエンドユーザの削除の要求があった場合には、そのエンドユーザのアカウントを削除する。

文書管理部２２２は、サービス部２０における文書ファイル等の管理を行う。文書管理部２２２は、文書ファイルの受信、文書ファイルの記憶および文書ファイルの送信などを行う。また、文書管理部２２２は、取扱う文書ファイルに対するエンドユーザのアクセス権限の設定も行う。

業務プロセス管理部２２３は、例えばエンドユーザが所属する組織の業務のプロセスに係わる情報を管理する。業務プロセスとは、ある業務で活用する情報の作成、参照、更新、削除などを達成するための構造化された一連のタスク群であり、エンドユーザが、いつ、どの情報を使って、どのような順序でタスク作業を進めるかを表現したものである。本実施形態では、業務プロセス管理部２２３は、例えばエンドユーザによる文書ファイルの取扱いを特定することで、エンドユーザによる業務のプロセスを管理している。

メール通知部２２４は、例えばエンドユーザに対して通知したい内容を文章にしたメッセージを作成する。また、メール通知部２２４は、各々のエンドユーザのメールアドレスに関する情報を保持している。そして、メール通知部２２４は、エンドユーザに対して、作成したメッセージをメール送信する。

また、上述のとおり、ユーザ管理部２２１、文書管理部２２２、業務プロセス管理部２２３およびメール通知部２２４は、少なくとも２つのサービス処理部が連携した連携サービスをエンドユーザに提供する。
本実施形態の情報処理システム１において、エンドユーザに提供される連携サービスには、「ユーザ登録」、「ユーザ削除」、および「文書登録機能」を例示することができる。

（ユーザ登録）
ユーザ登録は、サービス部２０を利用するエンドユーザの新規登録を行う機能である。そして、本実施形態のサービス管理部２１は、ユーザ登録をエンドユーザに提供するために、ユーザ管理部２２１およびメール通知部２２４という２つのサービス処理部を連携させる。

例えば、サービス管理部２１は、クライアント端末１０からのユーザ登録の要求に基づいて、ユーザ管理部２２１にユーザ登録の依頼を行う。ユーザ管理部２２１は、エンドユーザの新規登録の処理を行う。また、ユーザ管理部２２１は、エンドユーザの新規登録の完了に関する通知をサービス管理部２１に送る。また、サービス管理部２１は、メール通知部２２４に対して、登録完了メールの作成処理を依頼する。メール通知部２２４は、ユーザ登録の完了に関するメッセージを作成する。そして、本実施形態のサービス管理部２１は、ユーザ管理部２２１によるエンドユーザの新規登録の処理が完了すると、ユーザ登録を要求したエンドユーザに対してメール通知部２２４から登録完了メールを送信させる。

（ユーザ削除）
ユーザ削除は、サービス部２０を利用するエンドユーザの登録の削除を行う機能である。そして、本実施形態のサービス管理部２１は、ユーザ削除をエンドユーザに提供するために、ユーザ管理部２２１、文書管理部２２２、業務プロセス管理部２２３およびメール通知部２２４という４つのサービス処理部を連携させる。

例えば、サービス管理部２１は、クライアント端末１０からのユーザ削除の要求に基づいて、ユーザ管理部２２１に登録の削除の依頼を行う。ユーザ管理部２２１は、削除対象となるエンドユーザの登録を削除する処理を行う。
また、サービス管理部２１は、文書管理部２２２に対して、削除対象となるエンドユーザの文書ファイルに対するアクセス権の削除を依頼する。文書管理部２２２は、アクセス権の削除の完了に関する通知をサービス管理部２１に送る。

さらにまた、サービス管理部２１は、業務プロセス管理部２２３に対して、削除対象となるエンドユーザに係わる業務プロセスの案件の削除を依頼する。業務プロセス管理部２２３は、案件の削除の完了に関する通知をサービス管理部２１に送る。
一方で、サービス管理部２１は、メール通知部２２４に対して、登録の削除完了メールの作成処理を依頼する。

そして、本実施形態のサービス管理部２１は、ユーザ管理部２２１における登録の削除、文書管理部２２２におけるアクセス権の削除、および業務プロセス管理部２２３における案件の削除の処理が完了すると、登録の削除を要求したエンドユーザに対してメール通知部２２４から登録の削除完了メールを送信させる。

（文書登録機能）
文書登録機能は、文書ファイルの登録を行う機能である。そして、本実施形態のサービス管理部２１は、文書登録機能をエンドユーザに提供するために、文書管理部２２２、業務プロセス管理部２２３およびメール通知部２２４という３つのサービス処理部を連携させる。

例えば、サービス管理部２１は、クライアント端末１０からの文書ファイルの登録の要求に基づいて、文書管理部２２２に対して、文書ファイルの登録を依頼する。文書管理部２２２は、対象となる文書ファイルの登録に関する処理を行う。そして、文書管理部２２２は、文書ファイルの登録の完了に関する通知をサービス管理部２１に送る。

また、サービス管理部２１は、業務プロセス管理部２２３に対して、当該文書ファイルを証跡として登録することを依頼する。業務プロセス管理部２２３は、当該文書ファイルの証跡の登録の完了をサービス管理部２１に通知する。
一方で、サービス管理部２１は、メール通知部２２４に対して、文書ファイルの登録完了メールの作成処理を依頼する。

そして、本実施形態のサービス管理部２１は、文書管理部２２２における文書ファイルの登録および業務プロセス管理部２２３における文書ファイルの証跡の登録の処理が完了すると、ユーザ登録を要求したエンドユーザに対してメール通知部２２４から文書ファイルの登録完了メールを送信させる。

［リソース管理部３０］
リソース管理部３０は、サービス処理部のリソースに対する設定を受け付ける設定受付部３１と、サービス処理部のリソースを制御するリソース制御部３２と、リソースに関するリソース情報を記憶するリソース情報ＤＢ（データベース）部３３と、を備えている。
なお、本実施形態では、リソース制御部３２が、「特定手段」、「指示手段」、「費用情報取得手段」および「取得手段」の一例として機能する。また、本実施形態では、設定受付部３１が、「受付手段」および「表示手段」の一例として機能する。

（設定受付部３１）
設定受付部３１は、連携サービス部２２のリソースの合計費用の上限である設定費用の設定を管理ユーザから受け付ける。なお、合計費用とは、連携サービス部２２を構成する複数のサービス処理部の全てのリソースのリソース利用料の合計である。
設定費用は、管理ユーザが任意に設定するものである。そして、設定費用は、連携サービス部２２のリソースのリソース利用料として、管理ユーザが許容する費用である。例えば、管理ユーザは、サービス部２０を用いてエンドユーザにサービスを提供するという事業を行っている場合、事業の収益性の観点などに基づいて許容される費用を設定費用として設定する。そして、管理ユーザにより設定された設定費用は、設定受付部３１に登録される。

また、設定受付部３１は、各々のサービス処理部による処理時間の下限（以下、設定時間と呼ぶ）の設定を管理ユーザから受け付ける。
ここで、本実施形態における処理時間とは、例えばユーザ管理部２２１がユーザの新規登録を行う処理など、各々のサービス処理部が一のサービスの処理を行うのに要した時間である。本実施形態では、サービス処理部は、計算機のリソースによって実現される。従って、本実施形態において、サービス処理部の処理時間は、当該サービス処理部を実現する計算機のリソースの処理時間に対応する。

設定時間は、管理ユーザが任意に設定するものである。そして、設定時間は、各々のサービス処理部の処理時間に関して、サービス処理部の単位で設定された、管理ユーザが許容する許容時間である。ここで、設定時間は、サービス部２０を用いてエンドユーザに対してサービスを提供するうえで、サービスの品質を定める。サービスの品質は、例えば、サービス部２０における各々のサービス処理部の処理時間が長ければ、エンドユーザにサービスを提供するために要する時間が増加することで低下する。一方で、サービスの品質は、サービス部２０における各々のサービス処理部の処理時間が短ければ、エンドユーザにサービスを提供するために要する時間が減少することで向上する。
そして、管理ユーザは、例えば、実際にサービスが提供されるまでの時間を試すなどして設定時間を定める。そして、管理ユーザにより設定された設定時間は、設定受付部３１に登録される。

そして、本実施形態の設定受付部３１は、例えばリソース管理部３０に設けられた端末装置の表示部に表示するユーザインタフェース（ＵＩ）画面にて、設定費用の登録や設定時間の登録を管理ユーザから受け付ける。なお、本実施形態の設定受付部３１が表示するユーザインタフェース画面については、後に詳しく説明する。

（リソース制御部３２）
リソース制御部３２は、ユーザ管理部２２１、文書管理部２２２、業務プロセス管理部２２３およびメール通知部２２４の各々の処理時間の情報を取得する。すなわち、リソース制御部３２は、連携サービスを構成するサービス処理部毎に、各々のサービス処理部を実現する計算機のリソースの処理時間を特定する。

さらに、リソース制御部３２は、設定費用の情報を設定受付部３１から取得する。また、リソース制御部３２は、設定時間の情報を設定受付部３１から取得する。さらに、リソース制御部３２は、リソース情報ＤＢ部３３から後述するリソース情報を取得する。

そして、リソース制御部３２は、設定費用の情報、設定時間の情報、サービス処理部の処理時間の情報、およびリソース情報に基づいて、各々のサービス処理部に対するリソースの割り当てを制御する。リソース制御部３２は、各々のサービス処理部のリソースの追加または削減の指示をサービス管理部２１に送る。

続いて、リソース制御部３２が実行するリソースの制御に係わる処理について具体的に説明する。本実施形態のリソース制御部３２は、上記の各種情報に基づいて、リソースの制御に係わる（１）リソースの削除処理、（２）リソースの追加処理、および（３）費用再設定処理をそれぞれ行う。

（１）リソースの削除処理
リソース制御部３２は、設定時間と、各サービス処理部の処理時間と、リソース情報とに基づいて、過剰なリソースが割り当てられているサービス処理部のリソースを削除する。
本実施形態のリソース制御部３２は、各々のサービス処理部の処理時間が、設定時間以下であることを確認する。各々のサービス処理部の処理時間が、設定時間よりも長い場合には、リソース制御部３２は、リソースの削除処理よりもリソースの追加処理を実行する必要があるためである。

そして、本実施形態のリソース制御部３２は、設定時間との比較に基づいてリソースの削除処理の対象となるサービス処理部を特定する場合と、複数のリソース処理部の処理時間の相対的な関係に基づいてリソースの削除処理の対象となるサービス処理部を特定する場合とのいずれかを実行する。なお、本実施形態のリソース制御部３２は、これらの場合を両方とも実行しても良い。

まず、本実施形態のリソース制御部３２は、連携サービス部２２のなかで設定時間よりも処理時間が短いサービス処理部を、リソースの削除処理の対象とする。そして、リソース制御部３２は、対象となったサービス処理部に対して、リソースの削除処理を行う。

また、リソース制御部３２は、各々のサービス処理部の処理時間のなかで、処理時間が相対的に短いサービス処理部に対して、リソースの削除処理を行う。本実施形態のリソース制御部３２は、連携サービス部２２のうち、最も処理時間が長いサービス処理部を特定する。そして、リソース制御部３２は、処理時間が最も長いサービス処理部の処理時間を基準とし、その基準よりも処理時間が短いサービス処理部をリソースの削除処理の対象にする。

このように、本実施形態のリソース制御部３２は、連携サービス部２２における一のサービス処理部の処理時間と、他のサービス処理部の処理時間とを比較し、処理時間が比較的短いサービス処理部をリソースの削除処理の対象として選ぶ。そして、本実施形態では、リソース制御部３２がリソースの削除処理を行うことで、複数のサービス処理部の間で処理時間の差が小さくなり、各々の処理時間が平準化される場合がある。また、この相対的な比較によってリソースの削除処理を行う場合、連携サービス部２２を構成する複数のサービス処理部は、例えば設定時間よりも短い処理時間で平準化される。そのため、連携サービス部２２としてのサービスの品質は、サービス処理部の処理時間が設定時間に揃えられる場合と比較して高く維持される。

以上のとおり、本実施形態のリソース制御部３２は、予め定められた設定時間内に、複数のサービス処理部の各々の処理時間が含まれる範囲内で、リソースを削除させるリソースの削除処理を実行する。

また、本実施形態のリソース制御部３２は、上述のとおり、リソースの削除処理を行った場合には、リソースの削除処理が行われた後の連携サービス部２２のリソースの合計費用の情報を、リソース情報ＤＢ部３３に送る。そして、リソース情報ＤＢ部３３では、リソースの合計費用の情報の更新が行われる。
なお、本実施形態では、リソースの削除処理が行われると、連携サービス部２２におけるリソースの合計費用は、リソースの削除処理が行われる前よりも低くなる。

（２）リソースの追加処理
リソース制御部３２は、設定時間と、各サービス処理部の処理時間と、リソース情報とに基づいて、リソースが不足しているサービス処理部のリソースを追加する。
本実施形態のリソース制御部３２は、連携サービス部２２の中から、処理時間が設定時間を超えているサービス処理部を特定する。そして、リソース制御部３２は、処理時間が設定時間を超えているサービス処理部に対してリソースを追加する。

ここで、本実施形態のリソース制御部３２は、個々のサービス処理部に、どのようなリソースを割り当てると、処理時間がどの程度になるかという詳細な情報は有していない。サービス部２０おける処理の負荷は、例えばサービス部２０を利用するエンドユーザの数などの条件に応じて大きく変化する。そのため、サービス処理部の処理時間は、サービス部２０にて実際にサービスを提供せずに事前に予測することは難しい。

これに対して、本実施形態のリソース制御部３２は、処理時間が設定時間以下になるまで、処理能力に応じた段階的なリソースの追加を試みる。そして、リソース制御部３２は、処理時間が設定時間以下になった場合に、リソースの追加処理を終了する。
以上のとおり、本実施形態のリソース制御部３２は、予め定められた設定時間内に、連携サービス部２２における各々のサービス処理部の処理時間が含まれる範囲内で、リソースを追加するリソースの追加処理を実行する。

また、本実施形態のリソース制御部３２は、リソースの追加処理を行う際に、連携サービス部２２のリソースの合計費用と、設定費用との比較を行う。そして、リソース制御部３２は、連携サービス部２２のリソースの合計費用が設定費用以下になるように、リソースの追加処理を行う。

具体的には、リソース制御部３２は、現時点における連携サービス部２２のリソースの合計費用の情報を、リソース情報ＤＢ部３３から取得する。そして、リソース制御部３２は、現時点のリソースの合計費用にリソースの追加処理に伴う増加費用を加えた費用が、設定費用以下になる場合には、リソースの追加処理を実行する。しかしながら、本実施形態のリソース制御部３２は、現時点のリソースの合計費用に増加費用を加えた費用が、設定費用よりも高くなる場合には、リソースの追加処理は実行しない。

そして、リソース制御部３２は、上述のとおり、リソースの追加処理を行った場合には、リソースの追加処理が行われた後の連携サービス部２２のリソースの合計費用の情報をリソース情報ＤＢ部３３に送る。なお、リソース情報ＤＢ部３３では、リソースの合計費用の情報の更新が行われる。

（３）費用再設定処理
リソース制御部３２は、上述したリソースの追加処理において、処理時間と設定時間との関係でリソースの追加が必要である場合に、設定費用に対してリソースの費用が高くなってしまう場合に、費用再設定処理を実行する。
具体的には、リソース制御部３２は、費用再設定処理として、システム管理者に、現在の設定費用では、設定時間を満足するリソースの処理時間を実現できないことを通知させる。そして、本実施形態のリソース制御部３２は、費用再設定処理として、システム管理者に対して設定費用の費用を増額させることを促す。

なお、通知は、例えばシステム管理者が利用するリソース管理部３０の端末装置の表示画面にメッセージを表示したり、システム管理者に対してメールを送信したりすることで行われる。さらに、本実施形態では、リソース管理部３０の端末装置の表示画面における通知は、設定受付部３１によって行われる。

そして、本実施形態では、通知が行われた後、管理ユーザが設定費用を増額する場合には、リソース制御部３２は、リソースの追加処理を実行する。一方で、通知が行われた後、管理ユーザが設定費用を増額しない場合には、リソース制御部３２は、リソースの追加処理を実行しない。

以上のとおり、リソース制御部３２は、設定費用を超えてリソースの追加が必要となる場合に、システムの管理者に対して予め定められた通知を行うという費用再設定処理を実行する。

（リソース情報ＤＢ部３３）
リソース情報ＤＢ部３３は、複数のリソースに関するリソース種類と、各々のリソースのリソース利用料との情報を含むリソース情報を記憶している。本実施形態のリソース情報ＤＢ部３３は、リソース情報として、「低リソース」、「中リソース」および「高リソース」の３種類のリソースの情報を記憶している。
例えば、「高リソース」は、最も処理能力が高いリソースである。また、「低リソース」は、最も処理能力が低いリソースである。そして、「中リソース」は、「高リソース」と「低リソース」との間の処理能力を有するリソースである。
なお、本実施形態における処理能力は、同様な計算内容の処理を実行させた場合における処理の完了までに要する処理時間を例示できる。

ここで、本実施形態において、リソースの追加は、例えば、「低リソース」から「中リソース」や「高リソース」に変更するなど、処理能力が比較的低いリソースから比較的高いリソースに変更することである。逆に、本実施形態において、リソースの削除は、例えば、「高リソース」から「中リソース」や「低リソース」に変えるなど、処理能力が比較的高いリソースから比較的低いリソースに変更することである。

さらに、リソース情報ＤＢ部３３は、リソース情報として、「低リソース」、「中リソース」および「高リソース」のリソース利用料の情報を記憶している。例えば、リソース情報ＤＢ部３３は、「低リソース」のリソース利用料が「￥１００，０００」であり、「中リソース」のリソース利用料用が「￥２００，０００」であり、「高リソース」のリソース利用料が「￥４００，０００」であることを記憶している。このように、本実施形態においては、リソースの処理能力が高いほど、リソース利用料が高価になる。

そして、リソース情報ＤＢ部３３は、リソース制御部３２によって連携サービス部２２におけるサービス処理部の構成に変更があった場合には、変更後の連携サービス部２２のリソースの合計費用の情報をリソース制御部３２から取得する。

そして、リソース情報ＤＢ部３３は、要求に応じて、リソース情報を設定受付部３１やリソース制御部３２に送る。また、リソース情報ＤＢ部３３は、要求に応じて、現時点の連携サービス部２２のリソースの合計費用の情報を、設定受付部３１やリソース制御部３２に送る。

続いて、本実施形態の設定受付部３１が表示するユーザインタフェース（ＵＩ）画面について具体的に説明する。
図２は、設定受付部３１が表示するユーザインタフェース（ＵＩ）画面１００の表示例である。

図２に示すように、ＵＩ画面１００は、設定費用に関する設定費用欄１１０と、現在のリソースの合計費用に関する合計費用欄１２０と、設定時間に関する設定時間欄１３０と、連携サービス部２２を構成するサービス処理部の一覧を示すサービス一覧１４０と、管理ユーザに通知するための通知欄１５０との表示欄をそれぞれ表示する。

設定費用欄１１０には、管理ユーザが既に設定済みの設定費用１１１が表示される。また、設定費用欄１１０には、設定費用の設定を管理ユーザから受け付けるための編集ボタン１１２が設けられている。管理ユーザが編集ボタン１１２を押下すると、例えば設定費用の金額を入力する画面が表示され、数値を入力することで、設定費用１１１が変更される。
合計費用欄１２０には、連携サービス部２２のリソースの現時点での合計費用を示す合計費用１２１が表示される。合計費用１２１は、サービス一覧１４０に表示されている各々のサービス処理部のリソース利用料の合計に対応する。

設定時間欄１３０には、管理ユーザが既に設定済みの設定時間１３１が表示される。また、設定時間欄１３０には、設定時間の設定を管理ユーザから受け付けるための編集ボタン１３２が設けられる。管理ユーザが編集ボタン１３２を押下すると、例えば時間を入力する画面が表示され、数値を入力することで、設定時間１３１が変更される。

サービス一覧１４０の表示欄には、本実施形態の例では、ユーザ管理部２２１が提供するサービスを示す「ユーザ管理」、文書管理部２２２が提供するサービスを示す「文書管理」、業務プロセス管理部２２３が提供するサービスを示す「業務プロセス管理」、およびメール通知部２２４が提供するサービスを示す「メール通知」のサービス名称が並べて表示される。
さらに、サービス一覧１４０には、各々のサービス処理部のリソース利用料１４１の項目と、各々のサービス処理部のリソース種類１４２の項目と、各々のサービス処理部の処理時間１４３の項目と、が設けられている。

通知欄１５０は、管理ユーザに対して通知するメッセージを表示する欄である。本実施形態の通知欄１５０には、費用再設定処理によって、管理ユーザに対して、現在の設定時間に基づく品質を保証できないことを知らせたり、設定費用の変更を促したりするメッセージを表示する。

続いて、本実施形態の情報処理システム１の動作について具体的に説明する。
図３は、本実施形態の情報処理システム１の動作フローの一例である。

図３に示すように、リソース制御部３２は、各々のサービス処理部の処理時間の情報を取得する（Ｓ１０１）。そして、リソース制御部３２は、設定時間と、各々のサービス処理部の処理時間とを比較する（Ｓ１０２）。
そして、各々のサービス処理部の処理時間が、それぞれ設定時間と同じである場合（Ｓ１０２にて「同じ」）には、処理を終了する。

一方、設定時間に対して処理時間が短いサービス処理部があった場合（Ｓ１０２にて「短い」）、リソース制御部３２は、設定時間に対して処理時間が短いサービス処理部のリソースを削除させるリソースの削除処理を実行する（Ｓ１０３）。
このように、本実施形態の情報処理システム１では、各々のサービス処理部のリソースの処理時間が、予め定められた設定時間の範囲内であれば、例えば管理ユーザが管理ユーザ自身の判断により各サービス処理部に対するリソースの削減をしなくても、リソース管理部３０によって連携サービス部２２を構成するサービス処理部毎にリソースの削減が行われる。

また、設定時間に対して処理時間が長いサービス処理部があった場合（Ｓ１０２にて「長い」）、リソース制御部３２は、現在の連携サービス部２２のリソースの合計費用の情報を取得する（Ｓ１０４）。さらに、リソース制御部３２は、設定費用に基づいて、設定時間よりも処理時間が長いサービス処理部のリソースの追加が可能であるか否かを判断する（Ｓ１０５）。

そして、設定費用に基づいて、設定時間よりも処理時間が長いサービス処理部のリソースの追加が可能であると判断した場合（Ｓ１０５でＹｅｓ）、リソース制御部３２は、当該サービス処理部に対してリソースを追加するリソースの追加処理を実行する（Ｓ１０６）。
一方で、設定費用に基づいて、設定時間に対して処理時間が長いサービス処理部のリソースの追加ができない判断した場合（Ｓ１０５でＮｏ）、リソース制御部３２は、当該サービス処理部に対するリソースの追加ができない旨を管理ユーザに通知する費用再設定処理を実行する（Ｓ１０７）。なお、本実施形態の情報処理システム１では、管理ユーザに対する通知は、管理ユーザが利用するリソース管理部３０の端末装置の表示部に表示されるＵＩ画面１００（図２参照）にて行う。

このように、本実施形態の情報処理システム１では、連携サービス部２２のリソースの合計費用が、予め定められた設定費用の範囲内であれば、例えば管理ユーザが管理ユーザの判断により各サービス処理部に対するリソースの追加をしなくても、リソース管理部３０によって連携サービス部２２を構成するサービス処理部毎にリソースの追加が行われる。そして、設定時間とリソースの処理時間との関係で、リソースの合計費用が、予め定められた設定費用を超えるようなリソースの追加が必要になる場合には、管理ユーザに通知を行うようにしている。その結果、管理ユーザによって設定費用が増額されることで、連携サービス部２２におけるリソースの追加が行われる。

そして、ステップ１０３にてリソースの削除が行われた場合、または、ステップ１０６にてリソースの追加が行われた場合、リソース制御部３２は、リソース情報ＤＢ部３３に対して、リソースの変更が行われた連携サービス部２２のリソースの合計費用の情報を送る。そして、リソース情報ＤＢ部３３は、取得した連携サービス部２２のリソースの合計費用の情報を更新する（Ｓ１０８）。

なお、上述の動作例では、例えばＳ１０２にて、設定時間との比較に基づいてリソースの削除処理の対象となるサービス処理部を特定しているが、Ｓ１０２にて、複数のリソース処理部の処理時間の相対的な関係に基づいてリソースの削除処理の対象となるサービス処理部を特定しても良い。

続いて、本実施形態のリソース管理部３０が実行する（１）リソースの削除処理、（２）リソースの追加処理、および（３）費用再設定処理について、ＵＩ画面１００の表示例を用いて具体的に説明する。

図４は、リソースの削除処理が行われる際に表示されるＵＩ画面１００の一例である。
図４（Ａ）に示すように、リソースの削除処理が行われる前のＵＩ画面１００には、設定費用が「￥１，０００，０００」に設定され、設定時間が「３秒」に設定されていることが表示される。また、現時点での合計費用は、「￥８００，０００」であることが表示されている。そして、サービス一覧１４０には、「ユーザ管理」および「文書管理」の処理時間はそれぞれ３秒であり、「業務プロセス管理」の処理時間が２秒であり、「メール通知」の処理時間が１秒であることが表示されている。

ここで、「業務プロセス管理」および「メール通知」の処理時間は、それぞれ設定時間よりも短いことが特定される。従って、図４（Ａ）に示す例では、業務プロセス管理部２２３およびメール通知部２２４に対してリソースの削除処理が実行される。

そして、図４（Ｂ）に示すように、リソースの削除処理が行われた後のＵＩ画面１００には、「業務プロセス管理」および「メール通知」のリソースが変更されたことが表示される。そして、管理ユーザは、ＵＩ画面１００画面にて、「業務プロセス管理」および「メール通知」が、それぞれ「中リソース」から「低リソース」になるリソースの削減が行われたことを確認できる。

また、リソースの削除処理が行われた後のＵＩ画面１００には、「業務プロセス管理」および「メール通知」の処理時間がそれぞれ長くなったことが表示される。さらに、ＵＩ画面１００には、リソースの合計費用が「￥６００，０００」となり、リソースの削除処理が行われる前よりも費用が抑制されたことが表示される。

なお、本実施形態のＵＩ画面１００では、リソースの削除処理やリソースの追加処理に伴って変更された情報をハイライトしたり、文字色を変えたりすることで、変更されなかった情報と表示態様を異ならせて表示する。

また、リソースの削除処理について他の具体例を説明する。
図５は、リソースの削除処理が行われる際に表示されるＵＩ画面１００の一例である。
図５（Ａ）に示すように、リソースの削除処理が行われる前のＵＩ画面１００には、設定費用が「￥１，０００，０００」に設定され、設定時間が「３秒」に設定されていることが表示される。また、現時点での合計費用は、「￥８００，０００」であることが表示されている。そして、サービス一覧１４０には、「ユーザ管理」、「文書管理」および「業務プロセス管理」の処理時間がそれぞれ２秒であり、「メール通知」の処理時間が１秒であることが表示されている。

ここで、サービス一覧１４０における全てのサービス処理部の処理時間は、設定時間よりも短くなっている。そして、図５（Ａ）に示す例では、サービス処理部のうち最も処理時間が長いものを特定し、特定した最も長い処理時間に対して処理時間が短いサービス処理部のリソースを削除する。すなわち、図５（Ａ）に示す例では、複数のサービス処理部の間での比較によってリソースの削除を行う対象を特定する。

図５（Ａ）に示すように、「ユーザ管理」、「文書管理」および「業務プロセス管理」は、設定時間をそれぞれ下回るものの、相対的には、処理時間が最も長い。そこで、この例では、最も処理時間が長いサービス処理部を基準とする。そして、この例では、基準よりも処理時間が短いサービス処理部として、メール通知部２２４をリソースの削除処理の対象にする。

そして、図５（Ｂ）に示すように、リソースの削除処理が行われた後のＵＩ画面１００には、「メール通知」のリソースが変更されたことが表示される。そして、管理ユーザは、ＵＩ画面１００にて、「メール通知」が、「中リソース」から「低リソース」になるリソースの削減が行われたことを確認できる。
また、リソースの削除処理が行われた後のＵＩ画面１００には、「メール通知」の処理時間が長くなったことが表示される。さらに、ＵＩ画面１００には、リソースの合計費用が「￥７００，０００」となり、リソースの削除処理が行われる前よりも費用が抑制されたことが表示される。

次に、リソースの追加処理の具体例を説明する。
図６は、リソースの追加処理が行われる際に表示されるＵＩ画面１００の一例である。
図６（Ａ）に示すように、リソースの追加処理が行われる前のＵＩ画面１００には、設定費用が「￥１，０００，０００」に設定され、設定時間が「３秒」に設定されていることが表示される。また、現時点での合計費用は「￥７００，０００」であることが表示されている。そして、サービス一覧１４０には、「ユーザ管理」、「業務プロセス管理」および、「メール通知」の処理時間はそれぞれ３秒であり、「文書管理」の処理時間が５秒であることが表示されている。

ここで、「文書管理」の処理時間は、設定時間よりも長いことが特定される。従って、図６（Ａ）に示す例では、文書管理部２２２に対してリソースの追加処理が実行される。

図６（Ｂ）に示すように、リソースの追加処理が行われた後のＵＩ画面１００には、「文書管理」のリソースが変更されたことが表示される。そして、管理ユーザは、ＵＩ画面１００にて、「文書管理」が、「中リソース」から「高リソース」になるリソースの追加が行われたことを確認できる。

また、リソースの追加処理が行われた後のＵＩ画面１００には、「文書管理」の処理時間が短くなったことが表示されている。さらに、ＵＩ画面１００には、リソースの合計費用が「￥９００，０００」となるものの、設定費用よりは低い金額であることが表示される。

続いて、費用再設定処理の具体例を説明する。
図７は、費用再設定処理が行われる際に表示されるＵＩ画面１００の一例である。
図７（Ａ）に示すように、リソースの追加処理が行われる前のＵＩ画面１００には、設定費用が「￥１，０００，０００」に設定され、設定時間が「３秒」に設定されていることが表示される。また、現時点での合計費用は、「￥１，０００，０００」であることが表示されている。そして、サービス一覧１４０において、「ユーザ管理」、「業務プロセス管理」および「メール通知」の処理時間は、それぞれ３秒であり、「文書管理」の処理時間は、５秒であることが表示されている。

ここで、「文書管理」の処理時間は、設定時間よりも長いことが特定される。従って、図７（Ａ）に示す例では、文書管理部２２２に対してリソースの追加が必要であると判断する。しかしながら、現時点でのリソースの合計費用は、既に設定費用に達している。

この場合、図７（Ｂ）に示すように、ＵＩ画面１００の通知欄１５０に、管理ユーザに対して、現在の設定時間に基づくサービスの提供品質を保証できないという内容と、設定費用の変更を促す内容のメッセージを表示する。図７（Ｂ）の例では、通知欄１５０には、「サービス「文書管理」が性能要件未達です。設定費用の変更を実施してください。」という内容のテキストメッセージが表示される。

＜各装置のハードウェア構成＞
図８は、本実施形態のクライアント端末１０、サービス部２０およびリソース管理部３０等を実現するコンピュータ４００のハードウェア構成例を示す図である。

図８に示すコンピュータ４００は、演算手段であるＣＰＵ（Central Processing Unit）４０１と、記憶手段である主記憶装置（すなわち、メインメモリ）４０２および外部記憶装置４０３を備える。ＣＰＵ４０１は、外部記憶装置４０３に格納されたプログラムを主記憶装置４０２に読み込んで実行する。主記憶装置４０２としては、例えばＲＡＭ（Random Access Memory）が用いられる。外部記憶装置４０３としては、例えば磁気ディスク装置やＳＳＤ（Solid State Drive）等が用いられる。また、コンピュータ４００は、画像を表示するディスプレイである表示部４０４と、コンピュータ４００の操作者による入力操作が行われる入力デバイス４０５とを備える。入力デバイス４０５としては、例えばキーボードやマウス等が用いられる。また、コンピュータ４００は、ネットワークに接続するためのネットワーク・インターフェイス４０６を備える。

なお、本実施形態の情報処理システム１における一連の機能を、クライアント端末１０、サービス部２０およびリソース管理部３０にてそれぞれ実現させるプログラムは、例えば通信手段により提供することはもちろん、各種の記録媒体に格納して提供しても良い。

以上、本発明の実施形態について説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の技術思想の範囲から逸脱しない様々な変更や構成の代替は、本発明に含まれる。

１…情報処理システム、２０…サービス部、２１…サービス管理部、２２…連携サービス部、２２１…ユーザ管理部、２２２…文書管理部、２２３…業務プロセス管理部、２２４…メール通知部、３０…リソース管理部、３１…設定受付部、３２…リソース制御部、３３…リソース情報ＤＢ部

Claims (11)

1. 複数のサービスを連携させた連携サービスを提供する提供手段と、
   前記連携サービスを構成する前記サービス毎に、当該サービスを提供する計算機のリソースの処理時間を特定する特定手段と、
   特定した前記処理時間の情報を用いて、前記サービス毎に前記リソースの削減を指示する指示手段と、
   を備える情報処理システム。
2. 前記指示手段は、前記処理時間が予め定められた設定時間に含まれる範囲内で前記リソースの増減を指示する請求項１に記載の情報処理システム。
3. 前記指示手段は、前記設定時間よりも処理時間が短い前記サービスの前記リソースの削減を指示する請求項２に記載の情報処理システム。
4. 前記指示手段は、前記連携サービスのうちの第１のサービスを提供する第１のリソースの処理時間が、当該連携サービスのうちの第２のサービスを提供する第２のリソースの処理時間よりも短い場合に、当該第１のリソースの削減を指示する請求項３に記載の情報処理システム。
5. 前記連携サービスにおける前記リソースの費用に関する費用情報を取得する費用情報取得手段を備え、
   前記指示手段は、前記連携サービスの前記リソースの合計費用が予め定められた設定費用に含まれる範囲内で、前記設定時間よりも当該処理時間の長い前記サービスの前記リソースの追加を指示する請求項２に記載の情報処理システム。
6. 前記指示手段は、前記設定費用を超えて前記リソースの追加が必要となる場合に、システムを管理する管理ユーザに対して予め定められた通知行うことを指示する請求項５に記載の情報処理システム。
7. 複数のサービスを連携させた連携サービスを提供する提供手段から、当該連携サービスを構成する前記サービス毎に、当該サービスを提供する計算機のリソースの処理時間を取得する取得手段と、
   前記処理時間に関して各々の前記サービス単位での許容時間の設定をユーザから受け付ける受付手段と、
   前記許容時間に基づいて削減された前記リソースに関する情報を前記処理時間とともに前記サービス毎に画面に表示する表示手段と、
   を備える情報処理装置。
8. 前記受付手段は、前記連携サービスにおける前記リソースの合計費用に関して、ユーザが許容する許容費用の設定を受け付けることを特徴とする請求項７に記載の情報処理装置。
9. 複数のサービスを連携させた連携サービスを提供する提供手段から、当該連携サービスを構成する当該サービス毎に、当該サービスを提供する計算機のリソースの処理時間を取得する取得手段と、
   特定した前記処理時間の情報を用いて、前記サービス毎に前記リソースの削減を指示する指示手段と、
   を備える情報処理装置。
10. コンピュータに、
    複数のサービスを連携させた連携サービスを提供する提供手段から、当該連携サービスを構成する当該サービス毎に、当該サービスを提供する計算機のリソースの処理時間を取得する機能と、
    特定した前記処理時間の情報を用いて、前記サービス毎に前記リソースの削減を指示する機能と、
    を実現させるプログラム。
11. コンピュータに、
    複数のサービスを連携させた連携サービスを提供する提供手段から、当該連携サービスを構成する当該サービス毎に、当該サービスを提供する計算機のリソースの処理時間を取得する機能と、
    前記処理時間に関して各々の前記サービス単位での許容時間の設定をユーザから受け付ける機能と、
    前記許容時間に基づいて削減された前記リソースに関する情報を前記処理時間とともに前記サービス毎に画面に表示させる機能と、
    を実現させるプログラム。