JP2016170689A - 配備制御方法、配備制御プログラムおよび配備制御装置 - Google Patents

Abstract

【課題】利用者側の情報を用いて、機能の配備時間を推定することを目的とする。【解決手段】配備制御装置は、情報処理システムが利用者システムから出力された配備要求に対応する機能を配備した配備時間と、前記配備要求が出力された時刻とを含む実績情報を前記利用者システムに対応する記憶部から取得する取得部と、前記時刻と前記配備要求とに基づいて、所定時間ごとの配備要求数を算出し、前記配備要求数ごとに集約した前記実績情報の前記配備時間に基づいて、前記所定時間あたりの配備要求数に応じた前記機能の配備にかかる時間を推定する推定部と、を含む。【選択図】図２

Description

本発明は、配備制御方法、配備制御プログラムおよび配備制御装置に関する。

ユーザが使用するコンピュータシステム（以下、利用者システム）からのアプリケーションプログラムの配備要求に応じて、クラウド事業者のコンピュータシステム（以下、事業者システムと称する）が、アプリケーションプログラムを配備する技術がある。以下、アプリケーションプログラムをアプリケーションと称する。

関連する技術として、サービスプロバイダを動的に選択する技術が提案されている（例えば、特許文献１参照）。この技術は、複数のサービスプロバイダを使用可能なサービスコンシューマが、アプリケーションの実行時に呼び出すそれぞれのメソッドについて、要求するサービスレベルを満たすサービスプロバイダを動的に選択している。また、各クラウドサービスプロバイダの資源情報の評価を評価テーブルとしてクラウドサービスディレクトリが提供している。

特開２０１３−８９０３３号公報

利用者システムがアプリケーション（機能）の配備を事業者システムに要求するとき、利用者にとってアプリケーションの配備時間を認識することが望ましい。ただし、クラウド事業者が事業者システムの状況に関する情報を公開していない場合、利用者は、アプリケーションの配備時間を認識することが難しい。

１つの側面として、本発明は、利用者側の情報を用いて、機能の配備時間を推定することを目的とする。

１つの態様では、配備制御方法は、コンピュータが、情報処理システムが利用者システムから出力された配備要求に対応する機能を配備した配備時間と、前記配備要求が出力された時刻とを含む実績情報を前記利用者システムに対応する記憶部から取得する処理、前記時刻と前記配備要求とに基づいて、所定時間ごとの配備要求数を算出する処理、前記配備要求数ごとに集約した前記実績情報の前記配備時間に基づいて、前記所定時間あたりの配備要求数に応じた前記機能の配備にかかる時間を推定する処理、を実行する配備制御方法。

１つの側面によれば、利用者側の情報を用いて、機能の配備時間を推定することができる。

実施形態のシステムの一例を示す図である。 仮想システムマネージャの一例を示す機能ブロック図である。 オーケストレータの一例を示す機能ブロック図である。 リクエスト実績記憶部が記憶する情報の一例を示す図である。 推定配備遅延記憶部が記憶する情報およびグラフの一例を示す図である。 リクエスト数記憶部およびグループ情報記憶部が記憶する情報の一例を示す図である。 性能指数記憶部が記憶する情報の一例を示す図である。 グループ参加処理の一例を示すシーケンスチャートである。 配備遅延推定処理の一例を示すフローチャートである。 配備遅延を推定する例を示すフローチャートである。 近似式により配備遅延を補完する処理の例を示すフローチャートである。 クラウド選択処理の一例を示すフローチャートである。 配備要求処理の一例を示すフローチャートである。 実施形態の具体例を説明する図（その１）である。 実施形態の具体例を説明する図（その２）である。 実施形態の具体例を説明する図（その３）である。 実施形態の具体例を説明する図（その４）である。 実施形態の具体例を説明する図（その５）である。 実施形態の具体例を説明する図（その６）である。 実施形態の具体例を説明する図（その７）である。 実施形態の具体例を説明する図（その８）である。 実施形態の具体例を説明する図（その９）である。 実施形態の具体例を説明する図（その１０）である。 実施形態の具体例を説明する図（その１１）である。 実施形態の具体例を説明する図（その１２）である。 変形例のシステムの一例を示す図である。 変形例の仮想システムマネージャおよび統括仮想システムマネージャの一例を示す機能ブロック図である。 変形例のリクエスト数記憶部およびグループ情報記憶部が記憶する情報の一例を示す図である。 変形例のクラウド選択処理の一例を示すフローチャート（その１）である。 変形例のクラウド選択処理の一例を示すフローチャート（その２）である。 変形例の配備要求処理の一例を示すフローチャートである。 変形例の具体例を説明する図（その１）である。 変形例の具体例を説明する図（その２）である。 変形例の具体例を説明する図（その３）である。 変形例の具体例を説明する図（その４）である。 変形例の具体例を説明する図（その５）である。 変形例の具体例を説明する図（その６）である。 変形例の具体例を説明する図（その７）である。 変形例の具体例を説明する図（その８）である。 仮想システムマネージャのハードウェア構成の一例を示す図である。 統括仮想システムマネージャのハードウェア構成の一例を示す図である。

＜実施形態のシステムの一例＞
以下、図面を参照して、実施形態について説明する。図１は、実施形態のシステム１の一例を示している。システム１は、複数の事業者システム２（２Ａ、２Ｂ、・・・）と複数の利用者システム３（３Ａ、３Ｂ、・・・）とを含む。

実施形態のシステム１では、事業者システム２および利用者システム３は複数の例を示しているが、事業者システム２および利用者システム３は１つであってもよい。

事業者システム２は、利用者システム３に対してクラウドサービスを提供する事業者の情報処理システムである。事業者システム２は、例えば、複数のサーバを含むシステムである。以下、事業者システム２をクラウドと称することもある。

例えば、クラウドＣαは、事業者システム２Ａの情報処理システムである。また、クラウドＣβは、事業者システム２Ｂの情報処理システムである。図１の例は、２つの事業者システム２を示しているが、事業者システム２の数は任意の数であってよい。例えば、クラウドＣγがあってもよい。

利用者システム３は、事業者システム２が提供するクラウドサービスを利用するユーザのシステムである。利用者システム３は１または複数の端末を含むコンピュータシステムである。

実施形態では、利用者システム３は、複数の端末が相互に接続されたプライベートネットワークのシステムであるものとする。また、実施形態では、利用者システム３は、テナント業者に設置されるものとする。以下、テナント業者をテナントと称することがある。

例えば、テナントＴａは利用者システム３Ａを設置しているテナント業者である。また、テナントＴｂは利用者システム３Ｂを設置しているテナント業者である。実施形態では１つのテナント業者に１つの利用者システム３が割り当てられるものとする。

利用者システム３は、テナント業者に設置されるシステムには限定されない。例えば、テナント業者に複数の組織がある場合、利用者システム３は組織ごとに割り当てられるプライベートネットワークのシステムであってもよい。

以下、利用者システム３をテナントと称することがある。例えば、テナントＴａは利用者システム３Ａを設置しているテナント業者である。また、テナントＴｂは利用者システム３Ｂを設置しているテナント業者である。

利用者システム３は、クラウドに対して、機能の配備を要求する。実施形態では、利用者システム３がクラウドに対して配備を要求する機能はアプリケーションプログラム（以下、アプリケーションと称する）であるものとする。機能は、アプリケーションを細分化した機能であってもよい。

例えば、利用者システム３が配備を要求する機能は販売促進アプリケーションシステムであり、このアプリケーションシステムは、Ｗｅｂ機能とアプリケーション機能とデータベース機能とを含むアプリケーションシステムであってもよい。

利用者システム３は、アプリケーションの配備をクラウドに要求する。利用者システム３からのアプリケーションの配備要求に応じて、クラウドは、アプリケーションを配備して、仮想システムを構築する。

仮想システムマネージャ４（４Ａ、４Ｂ、・・・）は、各利用者システム３にそれぞれ対応するコンピュータにより実現される。利用者システム３が１つの場合は、仮想システムマネージャ４も１つになる。仮想システムマネージャ４は、配備制御装置の一例である。

実施形態では、仮想システムマネージャ４は、利用者システム３の一部のコンピュータに搭載されるソフトウェアにより実現されるものとする。ただし、仮想システムマネージャ４は、利用者システム３に接続されるコンピュータにより実現されてもよい。

仮想システムマネージャ４は、利用者システム３からアプリケーションの配備要求を受け付けて、クラウドに配備要求を出力する。仮想システムマネージャ４は、複数のクラウド２Ａ、２Ｂ、・・・のうち何れかのクラウドを選択する。そして、仮想システムマネージャ４は、選択したクラウドに対して、利用者システム３から受け付けた配備要求を出力する。

図１の例に示すように、各仮想システムマネージャ４は、相互に通信を行う。例えば、仮想システムマネージャ４Ａは、仮想システムマネージャ４Ｂを含む他の仮想システムマネージャと通信を行う。

オーケストレータ５は、クラウドに接続される装置である。オーケストレータ５は、クラウドごとに設けられ、仮想システムマネージャ４から入力した配備要求を所定のルールに基づいて変換し、クラウドに対して配備要求を出力する。

各オーケストレータ５は、各利用者システム３のそれぞれに対応している。例えば、システム１において、事業者システム２の数がＣ（Ｃは自然数）であり、利用者システム３の数がＵ（Ｕは自然数）である場合、システム１におけるオーケストレータ５の数は「Ｃ×Ｕ」になる。

図１の例では、オーケストレータ５Ａ−Ａは、クラウドＡに接続されるオーケストレータであり、且つ利用者システム３Ａ用のオーケストレータである。また、オーケストレータ５Ｂ−Ａは、クラウドＢに接続されるオーケストレータであり、且つ事業者システム２Ａ用のオーケストレータである。

図１のシステム１において、複数の事業者システム２のうち１つの事業者システム２に複数の利用者システム３からのアプリケーションの配備要求が集中すると、配備要求が集中した事業者システム２の負荷が高くなる。

このため、負荷の高い事業者システム２によるアプリケーションの配備時間が長くなる。そこで、利用者システム３は、負荷の低い事業者システム２を選択して、選択した事業者システム２に配備要求を出力することが好ましい。

ただし、各事業者システム２がクラウドの状況を公開していない場合、利用者システム３は、負荷の低い事業者システム２を選択することが難しい。そこで、利用者システム３は、利用者側の情報を用いて、許容時間内にアプリケーションの配備が完了する事業者システム２を選択する。

＜仮想システムマネージャの一例＞
次に、仮想システムマネージャ４の一例について説明する。図２は、仮想システムマネージャ４の一例を示している。仮想システムマネージャ４は、通信部１１と制御部１２と要求受付部１３と情報取得部１４と第１推定部１５と第２推定部１６と配備先選択部１７と配備要求部１８とグループ管理部１９とを含む。

また、仮想システムマネージャ４は、推定配備遅延記憶部２１と性能指数記憶部２２とリクエスト実績記憶部２３とリクエスト数記憶部２４とグループ情報記憶部２５とを含む。

通信部１１は、他の装置との間で通信を行う。例えば、通信部１１は、他の仮想システムマネージャ４との間、および各クラウドのオーケストレータ５との間で通信を行う。制御部１２は、仮想システムマネージャ４が行う各種の制御を行う。

要求受付部１３は、利用者システム３が出力したアプリケーションの配備要求を受け付ける。情報取得部１４は、自身の仮想システムマネージャ４および他の仮想システムマネージャ４から所定の情報を取得する。情報取得部１４は取得部の一例である。

第１推定部１５は、クラウド（事業者システム２）ごとに、アプリケーションの配備にかかる時間を推定する。第１推定部１５は、推定部の一例である。第１推定部１５は、自身の仮想システムマネージャ４のリクエスト実績および他の仮想システムマネージャ４のリクエスト実績を取得する。

第１推定部１５が取得するリクエスト実績は、仮想システムマネージャ４が配備要求を出力した時間帯と、利用者システム３から出力された配備要求に対応するアプリケーションを配備した配備時間（以下、配備遅延と称することもある）とを含む。

第１推定部１５は、時間帯あたりの配備要求数に応じてアプリケーションの配備にかかる時間を推定する。時間帯は、ある時刻からある時刻までの時間である。各時間帯の幅は同じであるものとする。時間帯は、所定時間の一例である。

第１推定部１５は、複数のクラウドがある場合、クラウドごとに、時間帯あたりの配備要求数に応じたアプリケーションの配備にかかる時間（以下、配備遅延と称することもある）を推定する。第１推定部１５は、推定した配備遅延を推定配備遅延記憶部２１に記憶する。

第２推定部１６は、第１推定部１５が推定した配備遅延と現在の時間帯における各仮想システムマネージャ４から出力される配備要求数とに基づいて、実際にクラウドにアプリケーションを配備するときの配備遅延をクラウドごとに推定する。現在の時間帯は、配備要求部１８が配備要求を出力する時間帯である。

配備先選択部１７は、第２推定部１６が推定したクラウドごとの配備遅延に基づいて、アプリケーションの配備要求を出力する先のクラウドを選択する。配備要求部１８は、配備先選択部１７が選択したクラウドに対して、アプリケーションの配備要求を出力する。

グループ管理部１９は、システム１の各利用者システム３のグループを管理する。１つのグループには、１または複数の利用者システム３が所属する。また、１つのグループには、１つのＩＤおよび通信アドレスが割り当てられる。ＩＤはIdentificationの略称である。

推定配備遅延記憶部２１は、第１推定部１５が推定した推定配備遅延を記憶する。第１推定部１５は、各クラウドについて、配備要求数に応じた推定配備遅延を記憶する。よって、推定配備遅延記憶部２１は、各クラウドについて、配備要求数に応じた推定配備遅延を記憶する。

性能指数記憶部２２は、各クラウドの性能指数を記憶する。実施形態では、性能指数は、クラウドがアプリケーションを配備する処理速度とコストとに基づいて、決定される。リクエスト実績記憶部２３は、自身の仮想システムマネージャ４が出力した配備要求のリクエスト実績を記憶する。

リクエスト実績は、仮想システムマネージャ４が行った過去のアプリケーションの配備要求に関する実績情報である。従って、リクエスト実績記憶部２３は、仮想システムマネージャ４に対応する利用者システム３に対応している。リクエスト実績記憶部２３は、記憶部の一例である。

実施形態では、リクエスト実績は、時刻とアプリケーションと配備先クラウドと配備遅延との情報を含んでいるものとする。このうち、時刻の情報は、時間帯を特定する情報である。

アプリケーションの情報は、仮想システムマネージャ４が配備要求を行ったアプリケーションを特定する情報である。配備先クラウドの情報は、仮想システムマネージャ４が配備要求を出力したクラウドを特定する情報である。

配備遅延の情報は、上記の配備遅延の情報である。実施形態では、配備遅延は、仮想システムマネージャ４が配備要求を出力した時刻から配備先のクラウドがアプリケーションの配備を完了した時刻までの時間であるとする。

実施形態では、仮想システムマネージャ４は、配備要求を出力したクラウドにアクセスして、アプリケーションの配備を完了した時刻を認識するものとする。アプリケーションの配備を完了した時刻は、クラウドから仮想システムマネージャ４に通知してもよい。

リクエスト数記憶部２４は、現在の時間帯において、配備要求部１８が出力した配備要求の数をクラウドごとに記憶する。配備要求部１８は、配備要求をクラウドに出力するごとに、配備要求を出力したクラウドに対応する配備要求数をインクリメントする。

リクエスト数記憶部２４は、現在の時間帯におけるクラウドごとの配備要求数を記憶する。よって、リクエスト数記憶部２４が記憶する情報は、時間帯が変化するごとに、リセットされる。リクエスト数記憶部２４が記憶するリクエスト数は、他の仮想システムマネージャ４に提供される。

グループ情報記憶部２５は、利用者システム３が所属するＩＤと通信アドレスと所属テナントとの情報を記憶する。所属テナントの情報は、同じグループに所属する他の利用者システム３を特定する情報である。

＜オーケストレータの一例＞
次に、図３を参照して、オーケストレータ５の一例について説明する。オーケストレータ５は、通信部３１と構成変換部３２と変換ルール記憶部３３と配備要求制御部３４とを含む。

通信部３１は、各仮想システムマネージャ４と通信を行う。構成変換部３２は、仮想システムマネージャ４から入力した配備要求をクラウドのルールに応じた配備要求に変換する。

仮想システムマネージャ４がオーケストレータ５に出力する配備要求は、クラウドに依存しない汎用的な要求である。変換ルール記憶部３３は、仮想システムマネージャ４が出力した汎用的な配備要求と、オーケストレータ５に対応する事業者システム２に依存したスキームとの対応関係を記憶している。

構成変換部３２は、通信部３１が配備要求を入力したとき、変換ルール記憶部２３が記憶する対応関係に基づいて、入力した配備要求を事業者システム２に依存したスキームに変換する。配備要求制御部３４は、構成変換部３２が変換した配備要求をクラウドに出力する。

＜各種データ構造の一例＞
次に、各種データ構造の一例について説明する。図４は、仮想システムマネージャ４Ａおよび４Ｂのリクエスト実績記憶部２３が記憶するテーブルの一例を示している。各テーブルは、時刻と対象アプリと配備先クラウドと配備遅延との項目を含む。

仮想システムマネージャ４Ａのリクエスト実績記憶部２３のテーブルは、仮想システムマネージャ４Ａが過去に配備要求を出力した実績を示す。仮想システムマネージャ４Ｂのリクエスト実績記憶部２３のテーブルは、仮想システムマネージャ４Ｂが過去に配備要求を出力した実績を示す。

上述したように、時間帯は、ある時刻からある時刻までの時間であり、各時間帯の時間は同じである。図４の例の場合、時刻ｔ１の時間帯は、時刻ｔ１から時刻ｔ２までの時間であり、時刻ｔ２の時間帯は、時刻ｔ２からｔ３までの時間である。

以下、時刻ｔｎ（ｎは２以上の整数）までの時間帯があるものとする。図４の例では、時刻ｔ１の時間帯（時刻ｔ１から時刻ｔ２までの時間）に、仮想システムマネージャ４Ａは３つの配備要求を出力している。また、時刻ｔ１の時間帯に、仮想システムマネージャ４Ｂは２つの配備要求を出力している。

時刻ｔｎの時間帯が経過すると、時刻ｔ１の時間帯に戻る。時刻ｔ１の時間帯が開始してから時刻ｔｎの時間帯が経過するまでの時間をＴとする。上述したように、各時間帯の時間は全て同じである。よって、各時間帯の時間は、時間Ｔを上記のｎで除算した値になる。

１つのリクエスト実績は、１つの配備要求に対応している。従って、配備要求部１８が配備要求を出力するごとに、配備要求部１８は、リクエスト実績記憶部２３にリクエスト実績を記憶する。

図５は、推定配備遅延記憶部２１が記憶するテーブル（情報）およびグラフの一例を示している。図５のテーブルは、配備先クラウドとリクエスト数と推定配備遅延との項目を含む。

第１推定部１５は、各クラウドについて、時間帯あたりの配備要求数に応じて配備遅延を推定する。推定配備遅延記憶部２１は、第１推定部１５が推定した配備遅延（推定配備遅延）をクラウドごと、且つ配備要求数ごとに記憶する。図５以降、配備要求数をリクエスト数と表記する。

時間帯あたりの配備要求数は、１つの時間帯（＝Ｔ／ｎ）の間に仮想システムマネージャ４が出力した配備要求数である。例えば、時間帯あたりの配備要求数は、単位時間あたりの配備要求数であってもよい。

例えば、図５の例の場合、仮想システムマネージャ４がクラウドＣαに対して、時間帯あたりに要求した配備要求数が１つの場合、推定配備遅延は１．１ｍｉｎであることを示している。

また、図５の例の場合、仮想システムマネージャ４がクラウドＣαに対して、時間帯あたりに要求した配備要求数が１５０の場合、推定配備遅延が６．６ｍｉｎであることを示している。

仮想システムマネージャ４が、クラウドに対して、時間帯あたりに多くの配備要求を出力した場合、クラウドの負荷は高くなる。クラウドの負荷が高くなると、推定配備遅延は長くなる。

図５の例のグラフは、推定配備遅延記憶部２１のテーブルの値に基づいて、推定配備遅延をグラフ化したものである。横軸は、時間帯あたりの配備要求数（リクエスト数）を示している。時間帯あたりの配備要求数は配備要求の頻度と称することもできる。縦軸は、推定配備遅延である。

図６は、現在の時間帯の配備要求数のテーブルおよび所属グループ情報のテーブルの一例を示している。現在の時間帯の配備要求数は、リクエスト数記憶部２４に記憶される。所属グループ情報は、グループ情報記憶部２５に記憶される。

配備要求部１８は、配備先選択部１７が選択したクラウドに対して、アプリケーションの配備要求を出力する。配備要求部１８は、配備要求を出力すると、リクエスト数記憶部２４のクラウドごとの配備要求数をインクリメントする。

図６の例では、現在の時間帯において、配備要求部１８がクラウドＣαに出力した配備要求数は３であり、クラウドＣβに出力した配備要求数は１である。配備要求部１８は、配備要求を出力するごとに、配備先のクラウドに対応する値をインクリメントする。

所属グループ情報は、自身の仮想システムマネージャ４が所属するグループの情報である。所属グループ情報のテーブルは、所属グループＩＤと通信アドレスと所属テナントとを含む。

所属グループＩＤは、仮想システムマネージャ４に対応するテナントが所属しているグループを識別する識別子である。通信アドレスは、グループに割り当てられる通信アドレスを示す。所属テナントは、同じグループに所属するテナントを示す。

通信アドレスは、例えば、Internet Protocol(IP)アドレスであってもよい。テナントの情報は、テナントを特定する情報である。テナントは利用者システム３に対応しているため、テナントの情報は、利用者システム３を特定する情報でもある。

図６の例の場合、グループＸ（ＧｒｐＸ）には、通信アドレスＩｐ_Ｘが割り当てられている。また、グループＸには、テナントＴｂおよびＴｃが所属している。つまり、グループＸには、利用者システム３Ｂおよび３Ｃが所属している。

図７は、性能指数記憶部２２が記憶するテーブルの一例を示している。図７の例に示すように、性能指数記憶部２２のテーブルは、クラウド環境と処理速度とコストと性能指数との項目を有している。

クラウド環境は、クラウドを特定する情報である。各クラウドは、同じタイプの仮想マシンを使用してもよいし、異なるタイプの仮想マシンを使用してもよい。処理速度は、対応するクラウドが１秒あたりに配備要求を処理する数を示している。コストは、例えば、クラウドを利用する料金である。性能指数は、処理速度をコストで除算した値である。

例えば、クラウドＣαは、処理速度が６であり、コストが８０である。よって、性能指数は１３．３となる。性能指数は、その値が低いほど、対応するクラウドの性能が良いことを示す。従って、図７の例の場合、クラウドＣβが最も性能の良いクラウドになる。

＜実施形態の処理の一例＞
次に、実施形態の処理の一例について説明する。図８は、グループ参加処理の一例を示すシーケンスチャートである。仮想システムマネージャ４がシステム１の何れかのグループに所属するとき、グループ管理部１９は、不図示の中継装置に参加通知を出力する制御を行う。通信部１１は、参加通知を中継装置に出力する（ステップＳＣ１）。

中継装置は、例えば、マルチキャストルータであってもよい。中継装置は、参加通知が示すグループの通信アドレスに基づいて、１または複数の仮想システムマネージャ４に対して、参加通知をマルチキャストで出力する（ステップＳＣ２）。

参加通知を入力した各仮想システムマネージャ４のグループ管理部１９は、参加通知を出力した仮想システムマネージャ４の情報をグループ情報記憶部２５に記憶する（ステップＳＣ３）。

その後、参加通知を入力した各仮想システムマネージャ４のグループ管理部１９は、通信部１１を制御して、参加通知を出力した仮想システムマネージャ４に対して、参加認識通知を出力する制御を行う。各通信部１１は、参加認識通知を中継装置に出力する（ステップＳＣ４）。

中継装置は、参加認識通知を中継する（ステップＳＣ５）。参加通知を出力した仮想システムマネージャ４の通信部１１は、参加認識通知を入力する。これにより、参加通知を出力した仮想システムマネージャ４は、同じグループの仮想システムマネージャ４の情報を記憶する（ステップＳＣ６）。

次に、図９のフローチャートを参照して、配備遅延推定処理の一例について説明する。情報取得部１４は、同じグループに所属する各仮想システムマネージャ４のリクエスト実績記憶部２３に記憶されているリクエスト実績を取得する（ステップＳ１）。

情報取得部１４は、同じグループの１または複数の他の仮想システムマネージャ４のリクエスト実績記憶部２３に記憶されているリクエスト実績を取得する。また、情報取得部１４は、自身の仮想システムマネージャ４のリクエスト実績記憶部２３に記憶されているリクエスト実績を取得する。

第１推定部１５は、取得したリクエスト実績をテナントごとに集約する（ステップＳ２）。そして、第１推定部１５は、リクエスト実績を事業者システム２（クラウド）ごとに集約する（ステップＳ３）。

第１推定部１５は、各クラウドに対するリクエスト実績を時間帯ごとに集約する（ステップＳ４）。上述したように、リクエスト実績は時間帯を含む。第１推定部１５は、各クラウドについて、時間帯ごとにリクエスト実績を集約する。

第１推定部１５は、各クラウドについて、時間帯ごとのリクエスト実績の数を算出する（ステップＳ５）。各クラウドに対する時間帯ごとのリクエスト実績の数は、各クラウドに対する時間帯ごとの配備要求数である。このため、第１推定部１５は、時間帯ごとのリクエスト実績の数を算出することで、各クラウドについて時間帯ごとの配備要求数を算出する。

ステップＳ４において、第１推定部１５は、各クラウドについて、リクエスト実績を時間帯ごとに集約している。第１推定部１５は、それぞれのクラウドについて、時間帯ごとに集約されたリクエスト実績を、算出した配備要求数でソートする（ステップＳ６）。

リクエスト実績は、時間帯ごとに集約されている。第１推定部１５は、配備要求数が同じ時間帯のリクエスト実績を集約する（ステップＳ７）。これにより、各クラウドについて、リクエスト実績は１つの時間帯の配備要求数ごとに集約される。

第１推定部１５は、各クラウドについて、配備要求数ごとに集約されたリクエスト実績に基づいて、クラウドごとの配備遅延を推定する（ステップＳ８）。リクエスト実績は、過去の配備遅延の情報を含む。

例えば、第１推定部１５は、配備要求数ごとに集約された過去の配備遅延に対して任意の統計処理を行うことにより、配備要求数ごとの配備遅延を推定してもよい。従って、第１推定部１５は、各クラウドについて、配備要求数ごとの推定配備遅延を得る。

第１推定部１５は、各クラウドについて、配備要求数に応じた推定配備遅延を推定配備遅延記憶部２１に記憶する。これにより、例えば、図５に示したテーブルが推定配備遅延記憶部２１に記憶される。

第１推定部１５は、全ての推定配備遅延を算出したか否かを判定する（ステップＳ９）。つまり、第１推定部１５は、各クラウドについて、配備要求数に応じた全ての推定配備遅延を算出したか否かを判定する。

第１推定部１５が全ての推定配備遅延を算出していない場合（ステップＳ９でＮＯ）、ステップＳ４からステップＳ８までの処理が行われる。第１推定部１５が全ての推定配備遅延を算出した場合（ステップＳ９でＹＥＳ）、配備遅延推定処理は終了する。

第１推定部１５は、配備遅延推定処理を定期的に行う。第１推定部１５は、配備遅延推定処理を終了した場合、推定配備遅延記憶部２１に記憶されている情報をリセットしてもよい。このとき、第１推定部１５は、推定配備遅延記憶部２１に記憶されている情報を何れかの記憶装置に退避させてもよい。

第１推定部１５は、各クラウドについて、配備要求数ごとに集約されたリクエスト実績の配備遅延に基づいて、各クラウドの配備遅延を推定する。図１０の「統計処理に基づく配備遅延の推定」に示されるように、第１推定部１５は、集約されたリクエスト実績に含まれる配備遅延に対して、統計処理を行ってもよい。そして、第１推定部１５は、統計処理を行った時間を配備遅延と推定してもよい（ステップＳ８−１）。

また、図１０の「平均時間に基づく配備遅延の推定」に示されるように、第１推定部１５は、集約された複数のリクエスト実績の配備遅延の平均値より長い時間を配備遅延と推定してもよい（ステップＳ８−２）。

また、図１０の「最長時間に基づく配備遅延の推定」に示されるように、第１推定部１５は、集約された複数のリクエスト実績の配備遅延のうち最も長い時間を配備遅延と推定してもよい（ステップＳ８−３）。

上述したように、ステップＳ７において、第１推定部１５は、配備要求数が同じ時間帯のリクエスト実績を集約している。このとき、リクエスト実績のない配備要求数が発生する場合がある。例えば、時間帯あたりの配備要求数が４つのリクエスト実績がない場合がある。

この場合、図１１の例に示すように、第１推定部１５は、配備要求数（リクエスト数）に対応するリクエスト実績があるか否かを判定する（ステップＳ８−４）。配備要求数に対応するリクエスト実績がない場合（ステップＳ８−４でＮＯ）、第１推定部１５は、近似式を用いて、補完を行う（ステップＳ８−５）。

つまり、第１推定部１５は、リクエスト実績のある他の配備要求数に応じた推定配備遅延に対して近似式を用いて近似を行い、配備要求数に応じた推定配備遅延を補完する。第１推定部１５は、配備要求数に対応するリクエスト実績がある場合（ステップＳ８−４でＹＥＳ）、ステップＳ８−５の処理は行わない。

次に、図１２のフローチャートを参照して、クラウド選択処理の一例について説明する。要求受付部１３は、利用者システム３から配備要求を受け付けたか否かを判定する（ステップＳ１１）。

要求受付部１３が利用者システム３から配備要求を受け付けていない場合（ステップＳ１１でＮＯ）、処理は次のステップに進まない。要求受付部１３が利用者システム３から配備要求を受け付けた場合（ステップＳ１１でＹＥＳ）、処理は次のステップに進む。

情報取得部１４は、同じグループの全ての仮想システムマネージャ４の現在の時間帯における各クラウドに対する配備要求数を取得する（ステップＳ１２）。各クラウドに対する配備要求数は、リクエスト数記憶部２４に記憶されている。よって、情報取得部１４は、同じグループの全ての仮想システムマネージャ４のリクエスト数記憶部２４の情報を取得する。

第２推定部１６は、取得した配備要求数を合算して、現在の時間帯における各クラウドに対する配備要求総数を算出する（ステップＳ１３）。推定配備遅延記憶部２１には、各クラウドについて、配備要求数に応じた推定配備遅延が記憶されている。

第２推定部１６は、推定配備遅延記憶部２１を参照して、ステップＳ１３で算出した配備要求総数に応じたクラウドごとの配備遅延を推定する（ステップＳ１４）。つまり、第２推定部１６は、推定配備遅延記憶部２１から上記の配備要求総数に対応する配備遅延をクラウドごとに取得する。

アプリケーションの配備先クラウドの候補を配備先候補と称する。実施形態では、配備要求には、利用者システム３がアプリケーションの配備に許容する許容時間が含まれる。配備要求は、許容時間未満でアプリケーションの配備が完了することを要求していることを示す。

配備先選択部１７は、各クラウドの配備遅延のうち、許容時間を超過しているクラウドを配備先候補から除外する（ステップＳ１５）。これにより、配備先候補のクラウドが絞り込まれる。

配備先選択部１７は、配備先候補を絞り込んだクラウドが複数であるか否かを判定する（ステップＳ１６）。配備先候補のクラウドが１つの場合（ステップＳ１６でＮＯ）、配備先選択部１７は、そのクラウドをアプリケーションの配備先に選択する（ステップＳ１７）。

配備先候補のクラウドが複数の場合（ステップＳ１６でＹＥＳ）、配備先選択部１７は、性能指数に基づいて、複数のクラウドのうち何れかのクラウドをアプリケーションの配備先に選択する（ステップＳ１８）。

配備先選択部１７は、性能指数記憶部２２を参照する。性能指数記憶部２２は、クラウドごとに性能指数を記憶している。配備先選択部１７は、配備先候補の複数のクラウドのうち、性能指数が最良のクラウド（実施形態では、性能指数の値が最も低いクラウド）をアプリケーションの配備先に選択してもよい。

上述したように、性能指数は、クラウドの処理速度とコストとに基づいて決定される指数である。従って、配備先選択部１７は、クラウドの処理速度とコストとに基づいて、配備先候補の複数のクラウドのうち１つのクラウドを選択してもよい。

また、配備先選択部１７は、配備先候補の複数のクラウドのうち、処理速度が最も速いクラウドを選択してもよい。これにより、配備先のクラウドは、アプリケーションの配備を最も速く完了する。

次に、図１３のフローチャートを参照して、配備要求処理の一例を説明する。配備要求部１８は、クラウド選択処理で選択されたクラウドに対応するオーケストレータ５に対して、利用者システム３から入力したアプリケーションの配備要求を出力する（ステップＳ２１）。

現在の時間帯において、仮想システムマネージャ４は、選択されたクラウドに対応するオーケストレータ５に対する配備要求の出力を行った。従って、配備要求部１８は、リクエスト数記憶部２４に記憶されているテーブルのうち、選択されたクラウドに対応する配備要求数をインクリメントする（ステップＳ２２）。

制御部１２は、通信部１１を制御して、配備要求を出力したクラウドにアクセスして、アプリケーションの配備の完了を確認し、配備が完了した時刻を認識する（ステップＳ２３）。

制御部１２は、配備要求を出力した時刻、配備するアプリケーションおよび配備先のクラウドを認識している。また、制御部１２は、配備要求を出力した時刻と配備が完了した時刻とに基づいて、配備遅延を認識する。制御部１２は、各情報に基づくリクエスト実績をリクエスト実績記憶部２３に記憶する（ステップＳ２４）。

＜実施形態の具体例＞
次に、実施形態の具体例について説明する。図１４は、具体例におけるシステム１を示している。システム１は、事業者システム２として、クラウドＣαとクラウドＣβとを含む。また、システム１は、複数の利用者システム３（テナントＴａ、Ｔｂ、Ｔｃ、・・・）を含む。

仮想システムマネージャ４Ａは、テナントＴａの仮想システムマネージャ４である。仮想システムマネージャ４Ｂは、テナントＴｂの仮想システムマネージャ４である。仮想システムマネージャ４Ｃは、テナントＴｃの仮想システムマネージャ４である。

図１４以降、仮想システムマネージャ４ＡはＴａ用仮想システムマネージャと表記する。また、仮想システムマネージャ４ＢはＴｂ用仮想システムマネージャと表記する。また、仮想システムマネージャ４ＣはＴｃ用仮想システムマネージャと表記する。

オーケストレータ５は、各クラウドについて、テナントごとに設けられる。図１４の例の場合、例えば、Ｔａ用Ｃα向けオーケストレータは、クラウドＣαについてのオーケストレータ５であり、且つテナントＴａ用のオーケストレータ５である。

図１４の例に示すように、リクエスト実績記憶部２３は、各時間帯の配備要求に基づいて、時間帯ごとに配備要求の対象のアプリケーション、配備先のクラウドおよび配備遅延を記憶している。

また、図１４の例のうち、テナントＴｂおよびテナントＴｃは、グループＸに参加中している。つまり、テナントＴｂおよびテナントＴｃは、グループＸに所属している。一方、テナントＴａは、グループＸに所属していない。

仮想システムマネージャ４ＡがグループＸに参加する場合を想定する。この場合、図１５の例に示すように、仮想システムマネージャ４Ａは、グループＸに所属する他の仮想システムマネージャ４に対して参加通知をマルチキャストで出力する。

参加通知を入力した他の仮想システムマネージャ４は、グループ情報記憶部２５に仮想システムマネージャ４Ａの情報を記憶する。参加通知を入力した他の仮想システムマネージャ４は、参加認識通知を仮想システムマネージャ４Ａに出力する。

仮想システムマネージャ４Ａは、グループＸに所属する他の仮想システムマネージャ４の情報をグループ情報記憶部２５に記憶する。仮想システムマネージャ４Ａは、仮想システムマネージャ４Ｂおよび４Ｃを認識し、仮想システムマネージャ４Ｂおよび４Ｃは、仮想システムマネージャ４Ａを認識する。従って、仮想システムマネージャ４Ａは、グループＸに所属する。

仮想システムマネージャ４Ａが利用者システム３Ａ（テナントＴａ）からアプリケーションの配備要求を受け付けたとする。図９のステップＳ１において、情報取得部１４は、グループＸに所属する他の仮想システムマネージャ４のリクエスト実績記憶部２３に記憶されているリクエスト実績を取得する。

そして、ステップＳ２において、仮想システムマネージャ４Ａの第１推定部１５は、情報取得部１４が取得したリクエスト実績をテナントごとに集約する。その後、ステップＳ３において、第１推定部１５は、リクエスト実績をクラウドごとに集約する。

図１６は、第１推定部１５が、各クラウドについて、リクエスト実績をテナントごとに集約した例を示している。クラウドＣαのリクエスト実績は、グループＸの各テナントがクラウドＣαに配備要求を出力した実績を示している。

図１６の例に示すように、クラウドＣαのリクエスト実績の中で、リクエスト実績は、テナントごとに集約されている。また、クラウドＣβのリクエスト実績の中で、リクエスト実績はテナントごとに集約されている。

第１推定部１５は、ステップＳ４で、各クラウドについて、リクエスト実績を時間帯ごとに集約する。例えば、図１６の例の場合、時刻ｔ１の時間帯において、テナントＴａに対応する仮想システムマネージャ４Ａは２つの配備要求を出力している。

同じ時間帯において、テナントＴｂに対応する仮想システムマネージャ４Ｂは１つの配備要求を出力している。同じ時間帯において、テナントＴｃに対応する仮想システムマネージャ４Ｃは２つの配備要求を出力している。

図１７は、各クラウドについて、時間帯ごとに集約したリクエスト実績の一例を示している。第１推定部１５は、ステップＳ５において、各クラウドに対する時間帯ごとの配備要求数を算出する。

例えば、図１７の例の場合、時刻ｔ１の時間帯において、５つの配備要求がクラウドＣαに対して出力されている。第１推定部１５は、各クラウドについて、時間帯ごとに配備要求数を算出する。

第１推定部１５は、ステップＳ６において、各時間帯のリクエスト実績を配備要求数でソートする。そして、第１推定部１５は、リクエスト数が同じ時間帯のリクエスト実績を集約する。

例えば、時刻ｔ１の時間帯における配備要求数は５つであり、時刻ｔ５の時間帯における配備要求数も５つである。よって、第１推定部１５は、時刻ｔ１の時間帯のリクエスト実績と時刻ｔ５の時間帯のリクエスト実績とを集約する。

これにより、図１８の例に示されるように、各クラウドについて、配備要求数ごとのリクエスト実績が得られる。図１８の例の配備要求数（リクエスト数）は、時間帯あたりの配備要求数である。

リクエスト実績は、配備遅延の情報を含む。第１推定部１５は、各クラウドについて、配備要求数ごとに集約されたリクエスト実績の配備遅延に基づいて、配備要求数ごとの配備遅延を推定する。

配備要求数に対応するリクエスト実績が１つの場合、第１推定部１５は、そのリクエスト実績の配備遅延を推定配備遅延とする。配備要求数に対応するリクエスト実績が複数の場合、第１推定部１５は、複数のリクエスト実績の配備遅延に基づいて、推定配備遅延を得る。

実施形態では、第１推定部１５は、複数の配備遅延に対して、統計処理を行うことにより、配備要求数ごとの推定配備遅延を得る。例えば、図１８の例の場合、配備要求数が５の場合に対応するリクエスト実績の数は１０である。

第１推定部１５は、１０個の配備遅延の平均値を推定配備遅延としてもよい。ただし、推定配備遅延は、リクエスト実績に含まれる配備遅延の平均値よりも長い値とすることが好ましい。

上述したように、第１推定部１５は、推定配備遅延が許容時間を超過しているクラウドを選択の対象から除外している。従って、推定配備遅延の値が短いと、第１推定部１５がクラウドを選択するときの対象の幅が狭くなる。

このため、第１推定部１５は、推定配備遅延を、リクエスト実績に含まれる配備遅延の平均値よりも長い値とする。実施形態では、配備要求数ごとの複数のリクエスト実績の配備遅延の９５パーセンタイル値を推定配備遅延とする。

上述したように、第１推定部１５は、配備要求数ごとの複数のリクエスト実績の配備遅延のうち最も長い配備遅延を推定配備遅延としてもよい。この場合、第１推定部１５がクラウドを選択するときの対象の幅が最も広くなる。

図１９は、第１推定部１５が９５パーセンタイル値を用いて、各クラウドについて、配備要求数ごとの推定配備遅延を算出した例を示している。ここで、図１８の例では、クラウドＣαおよびクラウドＣβの何れにも、配備要求数が４つの場合に対応する推定配備遅延がない。

これは、グループＸに所属する各仮想システムマネージャ４の何れも、４つの配備要求を出力した時間帯がないためである。配備要求数ごとのリクエスト実績は、各仮想システムマネージャ４が過去に配備要求を出力した実績に基づいている。従って、配備要求数に対応するリクエスト実績がない場合もある。

そこで、第１推定部１５は、配備要求数に対応する推定配備遅延を補完する。実施形態では、第１推定部１５は、近似式を用いて、配備要求数に対応する推定配備遅延を補完する。

図２０は、配備要求数が４つの場合に対応する推定配備遅延を、第１推定部１５が近似式で補完した例を示している。これにより、第１推定部１５は、各クラウドについて、各配備要求数に応じた推定配備遅延を推定配備遅延記憶部２１に記憶させる。図２０のグラフは、リクエスト数と推定配備遅延との関係を示している。

以上により、第１推定部１５は、時間帯あたりの配備要求数に応じた配備遅延を推定する。情報取得部１４は、同じグループに所属する各仮想システムマネージャ４のリクエスト実績記憶部２３からリクエスト実績を取得し、第１推定部１５は取得されたリクエスト実績に基づいて、各クラウドについて、配備要求数に応じた配備遅延を推定する。

従って、仮想システムマネージャ４は、クラウド（事業者システム２）の状況に関する情報を取得することなく、各クラウドについて、配備要求数に応じた配備遅延を推定することができる。

このため、クラウド（事業者システム２）が情報を公開していない場合であっても、仮想システムマネージャ４は、複数の仮想システムマネージャ４から取得した実績の情報に基づいて、配備遅延を推定することができる。

ここで、事業者システム２が１つであり、利用者システム３が１つの場合を想定する。この場合、仮想システムマネージャ４は、自身が記憶している実績情報に基づいて、上述した各処理を行うことで、事業者システム２のアプリケーションの配備遅延を推定することができる。

従って、事業者システム２および利用者システム３が１つの場合でも、仮想システムマネージャ４は、事業者システム２の状況に関する情報を取得することなく、事業者システム２のアプリケーションの配備遅延を推定することができる。

また、システム１は、事業者システム２が１つであり、利用者システム３が複数であってもよい。仮想システムマネージャ４は、自身が記憶している実績情報および他の仮想システムマネージャ４が記憶している実績情報に基づいて、上述した各処理を行うことで、事業者システム２のアプリケーションの配備遅延を推定することができる。

この場合、仮想システムマネージャ４は、自身の実績情報だけでなく、他の仮想システムマネージャ４の実績情報も使用して、アプリケーションの配備遅延を推定する。このため、多くの実績情報に基づいて、アプリケーションの配備遅延を推定できるため、推定精度が向上する。

次に、仮想システムマネージャ４Ａが利用者システム３Ａからアプリケーションの配備要求を受け付けた場合に、仮想システムマネージャ４Ａが何れかのクラウドにアプリケーションを配備する例について説明する。

テナントＴａの利用者システム３Ａは、時刻ｔｎにおいて、仮想システムマネージャ４Ａに配備要求を出力したとする。配備要求は、アプリケーションＡｐｐ１を配備する要求であり、許容時間は６．０ｍｉｎ未満である。

図２１の例に示すように、仮想システムマネージャ４Ａの要求受付部１３は、配備要求を受け付ける。情報取得部１４は、図１２のステップＳ１２において、同じグループの全ての仮想システムマネージャ４のリクエスト数記憶部２４から、現在の時間帯における配備要求数を取得する。図２２は、配備要求数の取得の一例を示している。

配備先選択部１７は、ステップＳ１３において、取得した配備要求数からクラウドごとの現在の時間帯における配備要求総数を算出する。図２３の例の場合、現在の時間帯におけるクラウドＣαに対する配備要求総数は６（＝２＋３＋１）である。また、現在の時間帯におけるクラウドＣβに対する配備要求総数は２（＝１＋１＋０）である。

配備先選択部１７は、ステップＳ１４において、配備要求総数と推定配備遅延とに基づいて、クラウドごとの配備遅延を推定する。配備先選択部１７は、推定配備遅延記憶部２１に記憶されているクラウドＣαについて、配備要求数が６のときの推定配備遅延を参照する。

図２３の例に示すように、配備先選択部１７は、推定配備遅延記憶部２１に基づいて、クラウドＣαについて、配備要求数が６のときの推定配備遅延は８．４であることを認識する。この場合、推定配備遅延（８．４）は、許容時間（６．０）を超過している。従って、配備先選択部１７は、ステップＳ１５において、クラウドＣαを配備先候補から除外する。

配備先選択部１７は、推定配備遅延記憶部２１に基づいて、クラウドＣβについて、配備要求数が２のときの推定配備遅延は２．８であることを認識する。この場合、推定配備遅延（２．８）は、許容時間（６．０）未満である。従って、配備先選択部１７は、ステップＳ１５において、クラウドＣβを配備先候補から除外しない。

図２４は、配備先選択部１７がクラウドＣαを配備先候補から除外し、クラウドＣβを除外していない例を示している。クラウドＣαが配備先候補から除外されたため、配備先選択部１７は、ステップＳ１６において、配備先候補は複数でないと判定する。

配備先選択部１７は、ステップＳ１７において、配備先候補であるクラウドＣβを選択する。図２５は、配備要求部１８がクラウドＣβに配備要求を出力したときの一例を示している。

配備要求部１８は、図１３のステップＳ２１において、配備先選択部１７が選択した配備先のクラウドＣβにアプリケーションＡｐｐ１の配備要求をクラウドＣαのオーケストレータ５（Ｔａ用Ｃβ向けオーケストレータ）に出力する。

そして、配備要求部１８は、ステップＳ２２において、現在の時間帯におけるクラウドＣβに対する配備要求数をインクリメントする。このため、リクエスト数記憶部２４のクラウドＣβに対応する配備要求数は２になる。

Ｔａ用Ｃβ向けオーケストレータ５の構成変換部３２は、変換ルール記憶部３３が記憶する変換ルールに基づいて、入力した配備要求を変換する。配備要求制御部３４は、クラウドＣβに対して、変換後の配備要求に基づいて、アプリケーションＡｐｐ１を配備する要求を行う。クラウドＣβは、アプリケーションＡｐｐ１を配備する。

ステップＳ２３において、仮想システムマネージャ４ＡがクラウドＣβにアクセスして、アプリケーションＡｐｐ１の配備が完了したことを認識した時刻をｔｎ＋２とする。ステップＳ２４において、配備要求部１８は、時刻ｔｎ＋２から時刻ｔｎを減算した値を配備遅延（２＝ｔｎ＋２−ｔｎ）として、リクエスト実績記憶部２３に記憶する。

以上により、仮想システムマネージャ４Ａは、利用者システム３Ａが出力した配備要求をクラウドＣβに出力する。クラウドＣβは、配備要求に基づいて、アプリケーションＡｐｐ１を配備する。

従って、仮想システムマネージャ４Ａは、利用者システム３Ａが設定した許容時間未満にアプリケーションＡｐｐ１を配備可能なクラウドＣβを選択して、配備要求をクラウドＣβに出力している。これにより、クラウドＣβは、許容時間未満の配備遅延でアプリケーションＡｐｐ１を配備することができる。

このとき、仮想システムマネージャ４Ａは、各クラウドから状況に関する情報を取得することなく、許容時間未満でアプリケーションの配備が可能なクラウドを選択することができる。

＜変形例＞
次に、変形例について説明する。図２６は、変形例におけるシステム１の一例を示している。変形例では、上述した実施形態における図１のシステム１に新たに統括仮想システムマネージャ６が追加されている。変形例において、統括仮想システムマネージャ６は、第１コンピュータの一例であり、各仮想システムマネージャ４は第２コンピュータの一例である。

また、各利用者システム３に対応する仮想システムマネージャ４は、統括仮想システムマネージャ６に接続されている。統括仮想システムマネージャ６は、実施形態の各仮想システムマネージャ４の機能の一部を統合したコンピュータである。

図２７は、仮想システムマネージャ４および統括仮想システムマネージャ６の一例を示している。変形例の仮想システムマネージャ４は、実施形態における図２の仮想システムマネージャ４のうち、第１推定部１５、推定配備遅延記憶部２１、リクエスト数記憶部２４およびグループ情報記憶部２５を有していない。

統括仮想システムマネージャ６は、通信部５１と第１推定部５２とグループ統括管理部５３と推定配備遅延記憶部５４と全リクエスト数記憶部５５とグループ情報記憶部５６とを含む。通信部５１は、各仮想システムマネージャ４と通信を行う。

第１推定部５２は、実施形態の各仮想システムマネージャ４の第１推定部１５に相当する。グループ統括管理部５３は、各仮想システムマネージャ４が所属する１以上のグループに関する情報を統括的に管理する。

推定配備遅延記憶部５４は、実施形態の各仮想システムマネージャ４の推定配備遅延記憶部２１に相当する。全リクエスト数記憶部５５は、現在の時間帯における各仮想システムマネージャ４が出力した配備要求数をクラウドごとに記憶する。グループ情報記憶部５６は、実施形態の仮想システムマネージャ４のグループ情報記憶部２５に相当する。

図２８は、変形例におけるテーブルの一例を示している。図２８は、全リクエスト数記憶部５５が記憶するテーブルおよびグループ情報記憶部５６が記憶するテーブルの一例を示している。

全リクエスト数記憶部５５は、現在の時間帯における各仮想システムマネージャ４が出力した配備要求総数をクラウドごとに記憶する。上述した実施形態と同様に、全リクエスト数記憶部５５が記憶する情報は、時間帯が変化するごとにリセットされる。

グループ情報記憶部５６は、１以上のグループについて、所属グループＩＤと通信アドレスと所属テナントとを記憶する。図２８は、グループＸにテナントＴｂおよびＴｃが所属し、グループＹにテナントＴｅが所属している例を示している。グループＸには通信アドレスＩｐ_Ｘが割り当てられ、グループＹには通信アドレスＩｐ_Ｘが割り当てられている。

次に、変形例の処理について説明する。変形例におけるグループ参加処理は、図８のフローチャートの各処理と同じである。また、変形例における配備遅延推定処理は、図９のフローチャートの各処理と同じである。ただし、変形例における配備遅延推定処理は、統括仮想システムマネージャ６が行う。

図２９および図３０を参照して、変形例のクラウド選択処理について説明する。図２９は、変形例のクラウド選択処理のうち統括仮想システムマネージャ４が行う処理の一例である。

統括仮想システムマネージャ６は、各グループの全仮想システムマネージャ４から現在の時間帯の配備要求数を取得する（ステップＳ１２−１）。また、統括仮想システムマネージャ６は、取得した配備要求数から各クラウドに対する配備要求総数を算出する（ステップＳ１３−１）。そして、統括仮想システムマネージャ６は、全リクエスト数記憶部５５に算出した配備要求数をクラウドごとに記憶する。

図３０は、変形例のクラウド選択処理のうち仮想システムマネージャ４が行う処理の一例を示している。図３０の各処理のうち、ステップＳ１３−２、Ｓ１４−１およびＳ１４−２以外の各処理は、図１２の各処理と同じである。

仮想システムマネージャ４の情報取得部１４は、統括仮想システムマネージャ６の全リクエスト数記憶部５５から現在の時間帯における配備要求総数を取得する（ステップＳ１３−２）。また、仮想システムマネージャ４の情報取得部１４は、推定配備遅延記憶部５４に記憶されている推定配備遅延を取得する（ステップＳ１４−１）。

そして、仮想システムマネージャ４の第２推定部１６は、ステップＳ１３で算出した配備要求総数とステップＳ１４−１で取得した推定配備遅延とに基づいて、クラウドごとの配備遅延を推定する（ステップＳ１４−２）。

図３１を参照して、変形例における配備要求処理について説明する。変形例の配備要求処理は、図１２に示した配備要求処理のステップＳ２２の処理が異なる。仮想システムマネージャ４の配備要求部１８は、ステップＳ２１において、オーケストレータ５に配備要求を出力する。

その後、配備要求部１８は、統括仮想システムマネージャ６に対して、配備先クラウドの現在の時間帯のリクエスト数をインクリメントする通知を出力する（ステップＳ２２−１）。統括仮想システムマネージャ６は、入力した通知に基づいて、全リクエスト数記憶部５５の情報を更新する。

図３２乃至図３８を参照して、変形例の具体例について説明する。図３２は、テナントＴａ、ＴｂおよびＴｃのそれぞれの仮想システムマネージャ４および統括仮想システムマネージャ６を含むシステム１の例を示す。

各仮想システムマネージャ４は、統括仮想システムマネージャ６に接続されている。図３２の例では、統括仮想システムマネージャ６のグループ情報記憶部５６は、グループＸにＴｂ用仮想システムマネージャ４およびＴｃ用仮想システムマネージャ４が所属していることを記憶している。

また、全リクエスト数記憶部５５は、現在の時間帯において、クラウドＣαに対して出力された配備要求が１つ、クラウドＣβに対して出力された配備要求が１つであることを示している。また、推定配備遅延記憶部５４は、配備要求数に応じた推定配備遅延を記憶している。

図３３の例に示すように、テナントＴａ、ＴｂおよびＴｃの各仮想システムマネージャ４のリクエスト実績記憶部２３は、それぞれリクエスト実績を記憶している。仮想システムマネージャ４が配備要求をオーケストレータ５に出力するごとに、リクエスト実績がリクエスト実績記憶部２３に記憶される。

ここで、図３４の例に示すように、Ｔａ用仮想システムマネージャがグループＸに参加する通知を統括仮想システムマネージャ６に出力したとする。統括仮想システムマネージャ６のグループ統括管理部５３は、Ｔａ用仮想システムマネージャがグループＸに所属する情報をグループ情報記憶部５６に記憶する。これにより、Ｔａ用仮想システムマネージャはグループＸに所属する。

次に、図３５の例に示すように、テナントＴａの利用者システム３ＡがアプリケーションＡｐｐ１を配備する配備要求をＴａ用仮想システムマネージャに出力したとする。許容時間は、６．０ｍｉｎ未満であるとする。

Ｔａ用仮想システムマネージャが配備要求を出力する時間帯において、クラウドＣαに対して６つの配備要求が出力されており、クラウドＣβに対して２つの配備要求が出力されているとする。全リクエスト数記憶部５５は、この情報を記憶している。

図３６の例に示すように、Ｔａ用仮想システムマネージャの情報取得部１４は、統括仮想システムマネージャ６の全リクエスト数記憶部５５に記憶されている情報を取得する。これにより、Ｔａ用仮想システムマネージャは、クラウドＣαに対して６つの配備要求が出力されており、クラウドＣβに対して２つの配備要求が出力されていることを認識する。

図３７の例に示すように、Ｔａ用仮想システムマネージャは、統括仮想システムマネージャ６に対して、推定配備遅延の問い合わせを行っている。統括仮想システムマネージャ６の第１推定部５２は、配備要求数に応じて配備遅延を各クラウドについて推定し、推定した結果を推定配備遅延として推定配備遅延記憶部５４に記憶している。

従って、統括仮想システムマネージャ６は、Ｔａ用仮想システムマネージャからの問い合わせに応じて、推定配備遅延記憶部５４から推定配備遅延を読み出して、Ｔａ用仮想システムマネージャ４に出力する。

Ｔａ用仮想システムマネージャの配備先選択部１７は、テナントＴａの利用者システム３Ａから入力した配備要求の許容時間が６．０ｍｉｎ未満であるため、図３８の例に示すように、クラウドＣαを配備先候補から除外する。

配備先選択部１７が配備先候補を除外した後の配備先候補はクラウドＣβの１つであるとする。配備先選択部１７は、テナントＴａの利用者システム３Ａから受け付けた配備要求に基づいて、アプリケーションＡｐｐ１の配備先をクラウドＣβに選択する。

図３９の例に示すように、Ｔａ用仮想システムマネージャの配備要求部１８は、時刻ｔｎにおいて、アプリケーションＡｐｐ１を配備する配備要求をクラウドＣβに出力する。クラウドＣβは、アプリケーションＡｐｐ１を配備する。

Ｔａ用仮想システムマネージャは、クラウドＣβがアプリケーションＡｐｐ１の配備を完了した時刻を確認する。クラウドＣβがアプリケーションＡｐｐ１の配備を完了した時刻をｔｎ＋２とする。

Ｔａ用仮想システムマネージャの制御部１２は、配備の完了を確認した時刻ｔｎ＋２から配備要求を出力した時刻ｔｎを減算する。制御部１２は、減算した時間（２＝ｔｎ＋２−ｔｎ）を配備遅延として、リクエスト実績記憶部２３に記憶する。

また、現在の時間帯（時刻ｔｎの時間帯）において、Ｔａ用仮想システムマネージャは、クラウドＣβに対して配備要求を出力している。よって、制御部１２は、現在の時間帯におけるクラウドＣβに対する配備要求数が１つ増えた通知を統括仮想システムマネージャ６に出力する。

統括仮想システムマネージャ６は、入力した通知に基づいて、全リクエスト数記憶部５５に記憶されている現在の時間帯のクラウドＣβの配備要求総数をインクリメントする。

変形例では、上述した実施形態の各仮想システムマネージャ４のうち一部の機能を統括仮想システムマネージャ６が行う。このため、変形例では、各仮想システムマネージャ４は、上記の一部の機能を省略することができる。

一方、変形例のシステム１では、各仮想システムマネージャ４以外に統括仮想システムマネージャ６が設けられる。このため、上述した実施形態のシステム１に比べて、別途のコンピュータを設けなくてもよい。

＜仮想システムマネージャのハードウェア構成の一例＞
次に、図４０の例を参照して、仮想システムマネージャ４のハードウェア構成の一例を説明する。図４０の例に示すように、バス１００に対して、プロセッサ１１１とＲＡＭ１１２とＲＯＭ１１３と補助記憶装置１１４と媒体接続部１１５と通信インタフェース１１６とが接続されている。

プロセッサ１１１は任意の処理回路である。プロセッサ１１１はＲＡＭ１１２に展開されたプログラムを実行する。実行されるプログラムとしては、実施形態の処理を行うプログラムを適用してもよい。ＲＯＭ１１３はＲＡＭ１１２に展開されるプログラムを記憶する不揮発性の記憶装置である。

補助記憶装置１１４は、種々の情報を記憶する記憶装置であり、例えばハードディスクドライブや半導体メモリ等を補助記憶装置１１４に適用してもよい。媒体接続部１１５は、可搬型記録媒体１１８と接続可能に設けられている。

可搬型記録媒体１１８としては、可搬型のメモリや光学式ディスク（例えば、Compact Disc(CD)やDigital Versatile Disc(DVD)、半導体メモリ等）を適用してもよい。この可搬型記録媒体１１８に実施形態の処理を行うプログラムが記録されていてもよい。

仮想システムマネージャ４の通信部１１は、通信インタフェース１１６により実現されてもよい。各記憶部は、ＲＡＭ１１２や補助記憶装置１１４等により実現されてもよい。その他の各部は、プロセッサ１１１により実現されてもよい。

ＲＡＭ１１２、ＲＯＭ１１３、補助記憶装置１１４および可搬型記録媒体１１８は、何れもコンピュータ読み取り可能な有形の記憶媒体の一例である。これらの有形な記憶媒体は、信号搬送波のような一時的な媒体ではない。

＜統括仮想システムマネージャのハードウェア構成の一例＞
次に、図４１の例を参照して、統括仮想システムマネージャ６のハードウェア構成の一例を説明する。図４１の例に示すように、バス２００に対して、プロセッサ２１１とＲＡＭ２１２とＲＯＭ２１３と補助記憶装置２１４と媒体接続部２１５と通信インタフェース２１６とが接続されている。

図４１の例の各部は、図４０の例の各部と同様である。通信部５１は、通信インタフェース２１６により実現されてもよい。各記憶部は、ＲＡＭ２１２や補助記憶装置２１４等により実現されてもよい。第１推定部５２は、プロセッサ２１１により実現されてもよい。

ＲＡＭ２１２、ＲＯＭ２１３、補助記憶装置２１４および可搬型記録媒体２１８は、何れもコンピュータ読み取り可能な有形の記憶媒体の一例である。これらの有形な記憶媒体は、信号搬送波のような一時的な媒体ではない。

＜その他＞
本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
コンピュータが、
情報処理システムが利用者システムから出力された配備要求に対応する機能を配備した配備時間と、前記配備要求が出力された時刻とを含む実績情報を前記利用者システムに対応する記憶部から取得する処理、
前記時刻と前記配備要求とに基づいて、所定時間ごとの配備要求数を算出する処理、
前記配備要求数ごとに集約した前記実績情報の前記配備時間に基づいて、前記所定時間あたりの配備要求数に応じた前記機能の配備にかかる時間を推定する処理、
を実行する配備制御方法。
（付記２）
前記コンピュータが、
前記推定する処理において、前記集約した実績情報の配備時間に対して統計処理を行い、該統計処理を行った値を前記機能の配備にかかる時間と推定する、
処理を実行する付記１記載の配備制御方法。
（付記３）
前記コンピュータが、
前記推定する処理において、前記集約した実績情報の配備時間の平均時間より長い時間を前記機能の配備にかかる時間と推定する、
処理を実行する付記１記載の配備制御方法。
（付記４）
前記コンピュータが、
前記推定する処理において、前記集約した実績情報の配備時間のうち最も長い時間を前記機能の配備にかかる時間と推定する、
処理を実行する付記１記載の配備制御方法。
（付記５）
前記コンピュータが、
前記配備要求数に対応する実績情報がない場合、推定した他の配備要求数に応じた前記機能の配備にかかる時間に基づいて、前記実績情報がない配備要求数に応じた前記機能の配備にかかる時間を補完する、
処理を実行する付記１記載の配備制御方法。
（付記６）
前記コンピュータが、
前記取得する処理において、複数の前記利用者システムのそれぞれに対応する記憶部から前記実績情報を取得する、
処理を実行する付記１記載の配備制御方法。
（付記７）
前記実績情報は、複数の前記情報処理システムに対する配備要求の前記配備時間と前記時刻とを含み、
前記コンピュータが、
前記算出する処理において、前記複数の情報処理システムのそれぞれについて、前記所定時間ごとの配備要求数を算出し、
前記推定する処理において、前記複数の情報処理システムのそれぞれについて、前記機能の配備にかかる時間を推定する、
処理を実行する付記１記載の配備制御方法。
（付記８）
前記コンピュータが、
前記配備要求を受け付けた時刻に対応する時間帯における複数の前記利用者システムの前記配備要求数を取得し、
前記配備要求数を合算した配備要求総数と、推定した前記機能の配備にかかる時間とに基づいて、前記複数の情報処理システムのうち、前記配備要求に応じた情報処理システムを選択し、
選択した前記情報処理システムに前記配備要求を出力する、
処理を実行する付記７記載の配備制御方法。
（付記９）
前記コンピュータが、
前記配備要求が許容時間を含んでいるとき、推定した前記機能の配備にかかる時間が前記許容時間を超過している情報処理システムを選択対象から除外する、
処理を実行する付記８記載の配備制御方法。
（付記１０）
前記コンピュータが、
前記選択対象に複数の情報処理システムが含まれる場合、前記機能の配備の処理速度が最も速い情報処理システムを選択する、
処理を実行する付記９記載の配備制御方法。
（付記１１）
前記コンピュータが、
前記選択対象に複数の情報処理システムが含まれる場合、前記機能の配備の処理速度と各情報処理システムのコストとに基づいて、前記配備要求に応じた情報処理システムを選択する、
処理を実行する付記９記載の配備制御方法。
（付記１２）
第１コンピュータが、
複数の情報処理システムが複数の利用者システムのそれぞれから出力された配備要求に対応する機能を配備した配備時間と、前記配備要求が出力された時刻とを含む実績情報を前記利用者システムに対応する記憶部から取得する処理、
前記時刻と前記配備要求とに基づいて、前記複数の情報処理システムのそれぞれについて、所定時間ごとの配備要求数を算出する処理、
前記配備要求数ごとに集約した前記実績情報の前記配備時間に基づいて、前記所定時間あたりの配備要求数に応じた前記機能の配備にかかる時間を前記複数の情報処理システムのそれぞれについて推定する処理、
前記配備要求を受け付けた時刻に対応する時間帯における前記複数の利用者システムの前記配備要求数を取得する処理、
を実行し、
第２コンピュータが、
前記配備要求数を合算した配備要求総数と、推定された前記機能の配備にかかる時間とに基づいて、前記複数の情報処理システムのうち、前記配備要求に応じた情報処理システムを選択する処理、
選択した前記情報処理システムに前記配備要求を出力する処理、
を実行する配備制御方法。
（付記１３）
情報処理システムが利用者システムから出力された配備要求に対応する機能を配備した配備時間と、前記配備要求が出力された時刻とを含む実績情報を前記利用者システムに対応する記憶部から取得する処理、
前記時刻と前記配備要求とに基づいて、所定時間ごとの配備要求数を算出する処理、
前記配備要求数ごとに集約した前記実績情報の前記配備時間に基づいて、前記所定時間あたりの配備要求数に応じた前記機能の配備にかかる時間を推定する処理、
をコンピュータに実行させるための配備制御プログラム。
（付記１４）
情報処理システムが利用者システムから出力された配備要求に対応する機能を配備した配備時間と、前記配備要求が出力された時刻とを含む実績情報を前記利用者システムに対応する記憶部から取得する取得部と、
前記時刻と前記配備要求とに基づいて、所定時間ごとの配備要求数を算出し、前記配備要求数ごとに集約した前記実績情報の前記配備時間に基づいて、前記所定時間あたりの配備要求数に応じた前記機能の配備にかかる時間を推定する推定部と、
を備える配備制御装置。

１ システム
２ 事業者システム
３ 利用者システム
４ 仮想システムマネージャ
５ オーケストレータ
６ 統括仮想システムマネージャ
１４ 情報取得部
１５ 第１推定部
１６ 第２推定部
１７ 配備先選択部
１８ 配備要求部
２１ 推定配備遅延記憶部
２３ リクエスト実績記憶部
２４ リクエスト数記憶部
５２ 第１推定部
５４ 推定配備遅延記憶部
５５ 全リクエスト数記憶部
１１１ プロセッサ
１１２ ＲＡＭ
１１３ ＲＯＭ

Claims (10)

1. コンピュータが、
   情報処理システムが利用者システムから出力された配備要求に対応する機能を配備した配備時間と、前記配備要求が出力された時刻とを含む実績情報を前記利用者システムに対応する記憶部から取得する処理、
   前記時刻と前記配備要求とに基づいて、所定時間ごとの配備要求数を算出する処理、
   前記配備要求数ごとに集約した前記実績情報の前記配備時間に基づいて、前記所定時間あたりの配備要求数に応じた前記機能の配備にかかる時間を推定する処理、
   を実行する配備制御方法。
2. 前記コンピュータが、
   前記推定する処理において、前記集約した実績情報の配備時間の平均時間より長い時間を前記機能の配備にかかる時間と推定する、
   処理を実行する請求項１記載の配備制御方法。
3. 前記コンピュータが、
   前記配備要求数に対応する実績情報がない場合、推定した他の配備要求数に応じた前記機能の配備にかかる時間に基づいて、前記実績情報がない配備要求数に応じた前記機能の配備にかかる時間を補完する、
   処理を実行する請求項１または２記載の配備制御方法。
4. 前記コンピュータが、
   複数の前記情報処理システムのそれぞれについて、前記機能の配備にかかる時間を推定する、
   処理を実行する請求項１乃至３のうち何れか１項に記載の配備制御方法。
5. 前記実績情報は、複数の前記情報処理システムに対する配備要求の前記配備時間と前記時刻とを含み、
   前記コンピュータが、
   前記算出する処理において、前記複数の情報処理システムのそれぞれについて、前記所定時間ごとの配備要求数を算出し、
   前記推定する処理において、前記複数の情報処理システムのそれぞれについて、前記機能の配備にかかる時間を推定する、
   処理を実行する請求項１乃至４のうち何れか１項に記載の配備制御方法。
6. 前記コンピュータが、
   前記配備要求を受け付けた時刻に対応する時間帯における複数の前記利用者システムの前記配備要求数を取得し、
   前記配備要求数を合算した配備要求総数と、推定した前記機能の配備にかかる時間とに基づいて、前記複数の情報処理システムのうち、前記配備要求に応じた情報処理システムを選択し、
   選択した前記情報処理システムに前記配備要求を出力する、
   処理を実行する請求項５記載の配備制御方法。
7. 前記コンピュータが、
   前記配備要求が許容時間を含んでいるとき、推定した前記機能の配備にかかる時間が前記許容時間を超過している情報処理システムを選択対象から除外する、
   処理を実行する請求項６記載の配備制御方法。
8. 第１コンピュータが、
   複数の利用者システムが出力した配備要求に応じて複数の情報処理システムが機能を配備した配備時間と、前記配備要求を出力した時刻とを含む実績情報を前記複数の利用者システムのそれぞれに対応する記憶部から取得する処理、
   前記時刻と前記配備要求とに基づいて、前記複数の情報処理システムのそれぞれについて、所定時間ごとの配備要求数を算出する処理、
   前記配備要求数ごとに集約した前記実績情報の前記配備時間に基づいて、前記所定時間あたりの配備要求数に応じた前記機能の配備にかかる時間を前記複数の情報処理システムのそれぞれについて推定する処理、
   前記配備要求を受け付けた時刻に対応する時間帯における前記複数の利用者システムの前記配備要求数を取得する処理、
   を実行し、
   第２コンピュータが、
   前記配備要求数を合算した配備要求総数と、推定された前記機能の配備にかかる時間とに基づいて、前記複数の情報処理システムのうち、前記配備要求に応じた情報処理システムを選択する処理、
   選択した前記情報処理システムに前記配備要求を出力する処理、
   を実行する配備制御方法。
9. 情報処理システムが利用者システムから出力された配備要求に対応する機能を配備した配備時間と、前記配備要求が出力された時刻とを含む実績情報を前記利用者システムに対応する記憶部から取得する処理、
   前記時刻と前記配備要求とに基づいて、所定時間ごとの配備要求数を算出する処理、
   前記配備要求数ごとに集約した前記実績情報の前記配備時間に基づいて、前記所定時間あたりの配備要求数に応じた前記機能の配備にかかる時間を推定する処理、
   をコンピュータに実行させるための配備制御プログラム。
10. 情報処理システムが利用者システムから出力された配備要求に対応する機能を配備した配備時間と、前記配備要求が出力された時刻とを含む実績情報を前記利用者システムに対応する記憶部から取得する取得部と、
    前記時刻と前記配備要求とに基づいて、所定時間ごとの配備要求数を算出し、前記配備要求数ごとに集約した前記実績情報の前記配備時間に基づいて、前記所定時間あたりの配備要求数に応じた前記機能の配備にかかる時間を推定する推定部と、
    を備える配備制御装置。

Images