(57)【要約】      （修正有）【課題】要件及びＩＳＰ（Infrastructure Service Provider）の異なる複数の個別インフラストラクチャに対応した複数の仮想リソースから構成された仮想システムを迅速かつ効率的に構築する。【解決手段】ＡＳＰ（Application Service Provider）とＩＳＰ間にリソースプール管理システム１００であって、リソースプールは、複数のＩＳＰにより提供される複数の個別インフラストラクチャの各々を実現する一つ以上の機能を含んだ一つ以上の要件を示すデータを仮想リソースとして含む。リソースプール管理システムは、アプリケーションプログラムの実行についてＡＳＰにより要求される二つ以上の条件との差分が許容範囲にある二つ以上の仮想リソースをリソースプールから特定し、当該二つ以上の仮想リソースの論理的接続でありアプリケーションサービスの実行に利用される仮想システムを構築する。【選択図】図１
2020140415.tif 000002
【特許請求の範囲】
【請求項１】
複数のＩＳＰ（Infrastructure Service Provider）により提供される複数の個別インフラストラクチャの各々について当該個別インフラストラクチャを実現する一つ以上の機能を含んだ一つ以上の要件を示すデータを仮想リソースとして含むリソースプールと、
アプリケーションプログラムの実行についてＡＳＰ（Application Service Provider）システムにより要求される二つ以上の条件との差分が許容範囲にある二つ以上の要件を持つ二つ以上の仮想リソースを前記リソースプールから特定し、当該二つ以上の仮想リソースの論理的接続であり前記アプリケーションプログラムの実行に利用されるシステムである仮想システムを構築するシステム構築部と
を備え、
前記システム構築部は、前記仮想システムの構築において、前記二つ以上の仮想リソースの各々について、当該仮想リソースに対応した個別インフラストラクチャを提供するＩＳＰのＩＳＰシステムを特定し、当該ＩＳＰシステムに、当該仮想リソースに対応した個別インフラストラクチャリソースのアクティベーションを指示する、
リソースプール管理システム。
【請求項２】
前記複数の個別インフラストラクチャは、一つ以上のネットワークを含む、
請求項１に記載のリソースプール管理システム。
【請求項３】
前記一つ以上のネットワークについての一つ以上の仮想リソースである一つ以上のネットワーク仮想リソースの各々に関し、
当該ネットワーク仮想リソースとしてのデータは、複数の要件を示し、
当該複数の要件は、機能性要件に属する一つ以上の要件に加えて非機能性要件に属する一つ以上の要件を含む、
請求項２に記載のリソースプール管理システム。
【請求項４】
前記二つ以上の条件は、Ｍの条件であり（Ｍは２以上の整数）、
前記システム構築部は、前記Ｍの条件をＭ次元の要件ベクトルとし、前記Ｍの条件に対応したＮの要件をＮ次元の要件ベクトルとし（Ｎは２以上の整数）、
前記差分は、前記Ｍ次元の要件ベクトルと前記Ｎ次元の要件ベクトルとの差分としてのベクトル差分である、
請求項３に記載のリソースプール管理システム。
【請求項５】
前記システム構築部は、前記Ｍの条件の要求を前記ＡＳＰシステムから受け付けた場合、前記ベクトル差分を算出し、且つ、当該算出されたベクトル差分を前記ＡＳＰシステムに通知し、
前記許容範囲にある差分は、前記ＡＳＰシステムから承認されたベクトル差分である、
請求項４に記載のリソースプール管理システム。
【請求項６】
前記システム構築部は、前記二つ以上の仮想リソースの各々について、当該仮想リソースが持つ要件のうち前記Ｍの条件に対応した要件を個別要件ベクトルとし、
前記Ｎ次元の要件ベクトルは、前記二つ以上の仮想リソースにそれぞれ対応した二つ以上の個別要件ベクトルの合成ベクトルである、
請求項５に記載のリソースプール管理システム。
【請求項７】
前記システム構築部は、利用中の仮想システムの一部の条件を変更する要求を受け付けた場合、
変更後の一部の条件に対応した一つ以上の個別要件ベクトルを用いて変更後の条件の表現としての要件ベクトルを算出し、
算出された要件ベクトルと、当該変更後の条件に対応した要件の表現としての要件ベクトルとの差分が許容範囲であれば、前記利用中の仮想システムのうち前記変更後の条件に関わる仮想リソースを変更する、
請求項６に記載のリソースプール管理システム。
【請求項８】
前記システム構築部は、利用中の仮想システムを構成する二つ以上の仮想リソースのうちの少なくとも一つの仮想リソースに対応した個別インフラストラクチャの障害の通知を受信した場合、
当該障害の影響を受ける一つ以上の仮想リソースの要件に対応した一つ以上の個別要件ベクトルとの差が許容範囲にある個別要件ベクトルに対応した要件を持つ仮想リソースである代替仮想リソースを特定し、
当該代替仮想リソースの要件に対応した個別要件ベクトルを用いて、前記障害の影響を受ける一つ以上の仮想リソースに代えて前記代替仮想リソースが採用された仮想システムの要件ベクトルを算出し、
前記算出された要件ベクトルと、前記Ｍの条件の表現としての要件ベクトルとの差分が許容範囲であれば、前記利用中の仮想システムのうちの前記一つ以上の仮想リソースを前記代替仮想リソースに差し替える、
請求項６に記載のリソースプール管理システム。
【請求項９】
前記システム構築部は、利用中の仮想システムを構成する二つ以上の仮想リソースのうちの少なくとも一つの仮想リソースに対応した個別インフラストラクチャの障害の通知を受信した場合、
当該障害の影響を受ける一つ以上の仮想リソースの当該障害後の要件に対応した一つ以上の個別要件ベクトルを用いて、前記利用中の仮想システムの当該障害後の仮想システム要件の要件ベクトルを算出し、
前記算出された要件ベクトルと、前記Ｍの条件の表現としての要件ベクトルとの差分が許容範囲であれば、前記利用中の仮想システムの利用を継続する、
請求項６に記載のリソースプール管理システム。
【請求項１０】
前記システム構築部は、前記Ｍの条件の要求を前記ＡＳＰシステムから受け付けた場合、前記差分を算出し、且つ、当該算出された差分を前記ＡＳＰシステムに通知し、
前記許容範囲にある差分は、前記ＡＳＰシステムから承認された差分である、
請求項１に記載のリソースプール管理システム。
【請求項１１】
前記システム構築部は、利用中の仮想システムの一部の条件を変更する要求を受け付けた場合、変更後の条件と、当該変更後の条件に対応した要件との差分が許容範囲であれば、前記利用中の仮想システムのうち前記変更後の条件に関わる仮想リソースを変更する、
請求項１に記載のリソースプール管理システム。
【請求項１２】
前記システム構築部は、利用中の仮想システムを構成する二つ以上の仮想リソースのうちの少なくとも一つの仮想リソースに対応した個別インフラストラクチャの障害の通知を受信した場合、
当該障害の影響を受ける一つ以上の仮想リソースの代替仮想リソースを特定し、
前記障害の影響を受ける一つ以上の仮想リソースに代えて前記代替仮想リソースが採用された仮想システムの要件と、前記二つ以上の条件の表現としての要件ベクトルとの差分が許容範囲であれば、前記利用中の仮想システムのうちの前記一つ以上の仮想リソースを前記代替仮想リソースに差し替える、
請求項１に記載のリソースプール管理システム。
【請求項１３】
前記システム構築部は、利用中の仮想システムを構成する二つ以上の仮想リソースのうちの少なくとも一つの仮想リソースに対応した個別インフラストラクチャの障害の通知を受信した場合、
当該障害の影響を受ける一つ以上の仮想リソースの当該障害後の要件を用いて、前記利用中の仮想システムの当該障害後の仮想システム要件を算出し、
前記算出された仮想システム要件と、前記二つ以上の条件との差分が許容範囲であれば、前記利用中の仮想システムの利用を継続する、
請求項１に記載のリソースプール管理システム。
【請求項１４】
前記システム構築部は、それぞれが複数の条件のテンプレートである複数のサービステンプレートのうち前記ＡＳＰシステムの入力に対応したサービステンプレートを前記ＡＳＰシステムに提供し、
前記ＡＳＰシステムにより要求された二つ以上の条件は、前記サービステンプレートを利用して入力された条件である、
請求項１に記載のリソースプール管理システム。
【請求項１５】
複数のＩＳＰ（Infrastructure Service Provider）により提供される複数の個別インフラストラクチャの各々について当該個別インフラストラクチャを実現する一つ以上の機能を含んだ一つ以上の要件を示すデータを仮想リソースとしてリソースプールへの登録を受け付け、
アプリケーションプログラムの実行についてＡＳＰ（Application Service Provider）システムにより要求される二つ以上の条件との差分が許容範囲にある二つ以上の要件を持つ二つ以上の仮想リソースを前記リソースプールから特定し、
当該二つ以上の仮想リソースの論理的接続であり前記アプリケーションプログラムの実行に利用されるシステムである仮想システムを構成し、
当該仮想システムを構成する前記二つ以上の仮想リソースの各々について、当該仮想リソースに対応した個別インフラストラクチャを提供するＩＳＰのＩＳＰシステムを特定し、当該ＩＳＰシステムに、当該仮想リソースに対応した個別インフラストラクチャリソースのアクティベーションを指示する、
リソースプール管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、アプリケーションサービスの提供において利用されるシステムの構築に関する。
【背景技術】
【０００２】
たとえばクラウドサービスに代表される仮想コンピューティング資源提供サービスやプライベート仮想ネットワーク（ＶＰＮ）の進展に伴い、様々な種類の物理装置上の仮想インスタンスが利用可能となっている。このような複数種類の仮想インスタンスを組み合わせて仮想システムを構築し、これを利用した広域でのアプリケーションサービス提供形態が拡がりつつある。このような仮想システムの構築運用にあたっては、限られた数の物理システム上に複数の仮想システムを構築し、それぞれ独立に運用するマルチテナント形態が一般的に想定されている。独立に運用される各仮想システムはそれを利用するアプリケーションサービスの必要とする機能及び性能を持つことが求められる。このような仮想システムの構築についての先行技術として、たとえば特許文献１及び２がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第5944870号
【特許文献２】特許第6170237号
【発明の概要】
【発明が解決しようとする課題】
【０００４】
仮想システムは、情報処理アプリケーションサービスのようなアプリケーションサービスに利用される。たとえば、分散する拠点からの情報処理要求あるいはデータ検索要求等の要求に従う処理が、クラウドに存在する仮想コンピューティングリソース上で実行される。アプリケーションサービスは、アプリケーションプログラムが仮想システムで実行されることにより提供されるサービス、別の言い方をすれば、アプリケーションプログラムと仮想システムとの組み合わせたシステムである。
【０００５】
しかし、アプリケーションサービスへのユーザニーズが多様化するのに対応して情報システムには継続的な高度化が求められ、それを支える仮想システムには様々な異種システムからの仮想リソースを取り込む必要が出てきている。異種システムは、たとえば、モバイルアクセスシステムと、種々のセンサーからの情報を収集し制御するためのセンサーネットである。モバイルアクセスシステム一つに限っても、方式は多様化しており、たとえば、LTE（Long Term Evolution）（登録商標）に代表されるモバイルセッション制御方式や、様々な方式のLow Power Wireless Access（LPWA）や、WiFi等がある。センサーネットに関してもセンサー種別、分野および用途に応じて様々な方式がある。さらには、アプリケーションサービスの実現形態についても、マイクロサービス化やサーバーレス化等の様々なシステム構成における多様化が進行している。
【０００６】
また、仮想システムに前述のような様々な異種システムからの仮想リソースを取り込む場合、それらの仮想リソースは必ずしも単一の管理者によって管理されているわけではない。この場合、ＡＳＰ（Application Service Provider）が、必要な異種システムから仮想リソースを取り込むために、システム毎に、管理者を特定し仮想リソースについて要求を出さなければならない。
【０００７】
このように、多様化するユーザニーズへの対応や様々な産業分野への適用領域拡大に伴って、各アプリケーションサービスが仮想システムに要求する条件（たとえば、機能、性能およびサービスエリアに関する条件）は今後ますます複雑化すると考えられる。
【課題を解決するための手段】
【０００８】
ＡＳＰシステムとＩＳＰ（Infrastructure Service Provider）システム間に介在するリソースプール管理システムが構築される。リソースプールは、複数のＩＳＰにより提供される複数の個別インフラストラクチャの各々について当該個別インフラストラクチャを実現する一つ以上の機能を含んだ一つ以上の要件を示すデータを仮想リソースとして含む。リソースプール管理システムは、アプリケーションプログラムの実行についてＡＳＰシステムにより要求される二つ以上の条件との差分が許容範囲にある二つ以上の要件を持つ二つ以上の仮想リソースをリソースプールから特定し、当該二つ以上の仮想リソースの論理的接続でありアプリケーションサービスの実行に利用される仮想システムを構築する。
【発明の効果】
【０００９】
本発明によれば、要件（たとえば機能）および管理者（ＩＳＰの一例）の異なる複数の個別インフラストラクチャに対応した複数の仮想リソースから構成されＡＳＰにより要求される条件との差分が許容範囲にある要件を持った仮想システムを迅速かつ効率的に構築することが可能となる。
【図面の簡単な説明】
【００１０】
【図１】実施例１に係るリソースプール管理システムを含んだシステム全体の構成を示す。
【図２】リソースプール管理システムの一部の機能を示す。
【図３】テンプレートストアの構成例を示す。
【図４】仮想リソースストアの構成例を示す。
【図５】構成ストアの構成例を示す。
【図６】仮想システム構築処理を含む処理全体のフローを示す。
【図７】仮想システム変更処理のフローを示す。
【図８】障害対応処理のフローを示す。
【図９Ａ】機能性要件に属するｎの個別要件の表現の一例としてのｎ次元要件ベクトルを示す。
【図９Ｂ】機能性要件に属するｎの個別要件に非機能性要件に属する（Ｎ−ｎ）の個別要件を加えたＮの個別要件の表現の一例としてのＮ次元要件ベクトルを示す。
【図１０】個別インフラストラクチャの個別要件ベクトルの一例を示す。
【図１１】ＥｔｏＥの仮想システムが持つ仮想システム要件の要件ベクトルの一例を示す。
【図１２】計算要件の要件ベクトルと要求要件の要件ベクトルとの差分の一例を示す。
【図１３】代替仮想リソースを有する仮想システムが持つ仮想システム要件の要件ベクトルの一例を示す。
【発明を実施するための形態】
【００１１】
以下の説明では、「インターフェース装置」は、一つ以上のインターフェースデバイスでよい。当該一つ以上のインターフェースデバイスは、一つ以上の同種の通信インターフェースデバイス（たとえば一つ以上のＮＩＣ（Network Interface Card））であってもよいし二つ以上の異種の通信インターフェースデバイス（たとえばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。
【００１２】
また、以下の説明では、「メモリ」は、一つ以上のメモリデバイスであり、典型的には主記憶デバイスでよい。メモリにおける少なくとも一つのメモリデバイスは、揮発性メモリデバイスであってもよいし不揮発性メモリデバイスであってもよい。
【００１３】
また、以下の説明では、「永続記憶装置」は、一つ以上の永続記憶デバイスである。永続記憶デバイスは、典型的には、不揮発性の記憶デバイス（たとえば補助記憶デバイス）であり、具体的には、たとえば、ＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）である。
【００１４】
また、以下の説明では、「記憶装置」は、メモリと永続記憶装置の少なくともメモリでよい。
【００１５】
また、以下の説明では、「プロセッサ」は、一つ以上のプロセッサデバイスである。少なくとも一つのプロセッサデバイスは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサデバイスであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサデバイスでもよい。少なくとも一つのプロセッサデバイスは、シングルコアでもよいしマルチコアでもよい。少なくとも一つのプロセッサデバイスは、プロセッサコアでもよい。少なくとも一つのプロセッサデバイスは、処理の一部または全部を行うハードウェア回路（たとえばＦＰＧＡ（Field-Programmable Gate Array）またはＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサデバイスでもよい。
【００１６】
また、以下の説明では、「ｘｘｘストア」といった表現にて、入力に対して出力が得られる情報を説明することがあるが、当該情報は、どのような構造のデータでもよいし、入力に対する出力を発生するニューラルネットワークのような学習モデルでもよい。従って、「ｘｘｘストア」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各ストアの構成は一例であり、一つのストアは、二つ以上のストアに分割されてもよいし、二つ以上のストアの全部または一部が一つのストアであってもよい。
【００１７】
また、以下の説明では、「ｋｋｋ部」の表現にて機能を説明することがあるが、機能は、一つ以上のコンピュータプログラムがプロセッサによって実行されることで実現されてもよいし、一つ以上のハードウェア回路（たとえばＦＰＧＡまたはＡＳＩＣ）によって実現されてもよい。プログラムがプロセッサによって実行されることで機能が実現される場合、定められた処理が、適宜に記憶装置および／またはインターフェース装置等を用いながら行われるため、機能はプロセッサの少なくとも一部とされてもよい。機能を主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、たとえば、プログラム配布計算機または計算機が読み取り可能な記録媒体（たとえば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が一つの機能にまとめられたり、一つの機能が複数の機能に分割されたりしてもよい。
【００１８】
また、以下の説明では、「計算機システム」は、一つ以上の物理的な計算機を含んだシステムである。物理的な計算機は、汎用計算機でも専用計算機でもよい。
【００１９】
また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通部分を使用し、同種の要素を区別する場合は、参照符号を使用することがある。たとえば、ＡＳＰシステムを区別しない場合には、「ＡＳＰシステム３０１」と言い、ＡＳＰシステムを区別する場合には、「ＡＳＰシステム３０１Ａ」、「ＡＳＰシステム３０１Ｂ」のように言うことがある。
【実施例１】
【００２０】
図１は、本発明の実施例１に係るリソースプール管理システムを含んだシステム全体の構成例を示す。
【００２１】
ＡＳＰ（Application Service Provider）レイヤ３００とＩＳＰ（Infrastructure Service Provider）レイヤ２００間にバウンダリレイヤとしてのリソースプール管理システム１００が構築される。リソースプール管理システム１００は、リソースプール１１０と、システム構築部５０とを有する。
【００２２】
ＡＳＰレイヤ３００は、一つ以上のＡＳＰシステム３０１が属するレイヤである。ＡＳＰシステム３０１は、計算機システムで所定のソフトウェアが実行されることにより実現されるシステム、または、ＡＳＰの計算機システム（たとえば、パーソナルコンピュータ）でよい。ＡＳＰシステム３０１は、アプリケーションサービス（アプリケーションプログラムの実行）について要求される複数の条件をリソースプール管理システム１００に指定する。ＡＳＰは、ユーザと言い換えられてもよい。
【００２３】
ＩＳＰレイヤ２００は、複数のＩＳＰシステム２２１が属するレイヤである。ＩＳＰシステム２２１は、計算機システムで所定のソフトウェアが実行されることにより実現されるシステム、または、ＩＳＰの計算機システムでよい。ＩＳＰシステム２２１は、個別インフラストラクチャ２１１を実現する一つ以上の要件（一つ以上の機能を含む）を示すデータを仮想リソースとしてリソースプール１１０に登録したり、システム構築部５０からの指示に従い仮想システム構築のために個別インフラストラクチャ２１１を制御したりする。図１の例では、ＩＳＰとインフラストラクチャは一対一であるが、それに限られないでもよい。たとえば、一つのＩＳＰが複数種類のインフラストラクチャを提供してもよいし、複数のＩＳＰが一つの個別インフラストラクチャを提供してもよい。また、図１の例では、ＩＳＰシステム２２１と個別インフラストラクチャ２１１は一対一であるが、それに限られないでもよい。
【００２４】
リソースプール１１０は、たとえば、仮想リソースストア１１１と、複数の管理部１１２（たとえば１１２Ａ〜１１２Ｅ）とを有する。各管理部１１２は、システム構築部５０に含まれてよく、リソースプール１１０は仮想リソースストア１１１それ自体でもよい。システム構築部５０は、たとえば、ＡＳＰインターフェース部１３０と、マッチング部１２１と、構成制御部１２２と、仮想リソース制御部１１３とを有する。システム構築部５０は、たとえば、リソースプール管理システム１００におけるテンプレートストア１２４および構成ストア１２３を管理してよい。リソースプール管理システム１００は、計算機システム、または、所定のソフトウェアが計算機システムに実行されることにより実現されるシステムでよい。計算機システムは、たとえば、インターフェース装置、記憶装置およびそれらに接続されたプロセッサを有する。仮想リソースストア１１１、テンプレートストア１２４および構成ストア１２３の各々は、たとえば、記憶装置に格納される。管理部１１２およびシステム構築部５０は、たとえば、プロセッサに一つ以上のプログラムが実行されることで実現される。
【００２５】
リソースプール１１０は、複数のＩＳＰシステム２２１により提供される複数の個別インフラストラクチャ２１１の各々について当該個別インフラストラクチャ２１１を実現する一つ以上の機能を含んだ一つ以上の要件を示すデータを仮想リソースとして含む。システム構築部５０は、アプリケーションプログラムの実行についてＡＳＰシステム３０１により要求される仮想システム要件（二つ以上の条件の一例）との差分が許容範囲にある二つ以上の要件を持つ二つ以上の仮想リソースをリソースプール１１０から特定し、当該二つ以上の仮想リソースの論理的接続でありアプリケーションサービスの実行に利用される仮想システムを構築する。システム構築部５０は、仮想システムの構築において、二つ以上の仮想リソースの各々について、当該仮想リソースに対応した個別インフラストラクチャ２１１を提供するＩＳＰシステム２２１を特定し、当該ＩＳＰシステム２２１に、当該仮想リソースに対応した個別インフラストラクチャリソース（個別インフラストラクチャ２１１のうち仮想リソースに対応した部分）のアクティベーションを指示する。
【００２６】
本実施例によれば、要件およびＩＳＰの異なる複数の個別インフラストラクチャ２１１に対応した複数の仮想リソースから構成されＡＳＰにより要求される条件との差分が許容範囲にある要件を持った仮想システムを迅速かつ効率的に構築することが可能となる。
【００２７】
図１についての詳細な説明の一例は、たとえば下記の通りである。
【００２８】
リソースプール管理システム１００は、図１に示すように、ＩＳＰシステム２２１とＡＳＰシステム３０１を仲介することにより、ＡＳＰに対して、個別インフラストラクチャ２１１からの要件（機能）を組み合わせた仮想システムを提供する。個別インフラストラクチャ２１１として、たとえば、センサーネット２１１Ａ、無線アクセス網２１１Ｂ、ＳＤ−ＷＡＮ２１１Ｃ、ＶＰＮ（Virtual Private Network）２１１Ｄ、および、クラウド２２１Ｅがある。これらの個別インフラストラクチャ２１１Ａ〜２１１Ｅにそれぞれ対応するＩＳＰシステム２２１Ａ〜２２１Ｅの各々が、個別インフラストラクチャ２１１の機能性要件（たとえば、物理リソースの通信帯域や始点または終点等の機能および性能）および非機能性要件（たとえば冗長性）を示すデータを、仮想リソースとして、リソースプール管理システム１００の仮想リソースストア１１１に登録する。それぞれの個別インフラストラクチャ２１１の物理リソース同士を接続するリンク機能２３１（たとえば２３１Ａ〜２３１Ｄ）を示すデータも接続情報の一つとして仮想リソースに含まれる。ＩＳＰシステム２２１は、個別インフラストラクチャ２１１の仮想化と管理のうちの少なくとも管理を行ってよい。たとえば、ＩＳＰシステム２２１Ａは、センサーネット２１１Ａ（たとえば、ネットワーク２１１１、複数のセンサー２１１２（たとえば、少なくとも一つの監視カメラを含んでもよい）、および、ゲートウェイ２１１３）を仮想化し、仮想化されたセンサーネット２１１Ａとしての仮想リソースを仮想リソースストア１１１に登録する。また、たとえば、ＩＳＰシステム２２１Ｅは、クラウド２１１Ｅとしての仮想リソースを仮想リソースストア１１１に登録する。
【００２９】
仮想リソースストア１１１に登録された仮想リソース（データ）はその要件（たとえば機能および性能）に応じた管理部１１２（たとえばサーバ）により管理される。たとえば、管理部１１２の一例として、接続情報（たとえば通信帯域や始点または終点等）を管理する接続管理部１１２Ｃ、冗長構成を管理する冗長構成管理部１１２Ａ、ユーザ（ＡＳＰ）を管理するユーザ管理部１１２Ｅ、ユーザ毎のアクセスポリシー等を管理するセキュリティ管理部１１２Ｂ、及び、クラウド２１１Ｅ上のＶＭ（Virtual Machine）を管理するＶＭ管理部１１２Ｄがある。これら管理部種別（サーバ種別）は仮想システムの要件あるいは接続される個別インフラストラクチャ２１１の機能等に応じて構成されるものでよく、例示された種別に限定されるものではない。
【００３０】
また、ユーザ管理部１１２ＥはＡＳＰに対応してアクセスポリシー等を管理する機能であるが、必ずしも両者を一対一で対応付けるものではない。一ユーザが複数のＡＳＰインスタンスを使用する場合もあってよい。
【００３１】
一方、ＡＳＰシステム３０１は、リソースプール管理システム１００に対し、ＡＳＰインターフェース部１３０を介して、必要な条件（たとえば機能および性能等）に対応した要件（たとえば機能および性能等）を持つ仮想システムを要求する。条件の入力には、ＡＳＰシステム３０１は、リソースプール管理システム１００のテンプレートストア１２４に格納されておりＡＳＰインターフェース部１３０を介して提供されるサービステンプレートを利用する。サービステンプレートは、たとえば、ＡＳＰ種別毎に用意されるデータであり、仮想システム要件のテンプレートである。リソースプール管理システム１００とＡＳＰシステム３０１間の通信は、ＡＳＰインターフェース部１３０を介して行われる。
【００３２】
ＡＳＰシステム３０１からの要求に関連付けられている仮想システム要件（二つ以上の条件の一例）は、マッチング部１２１により、整合性が検証され、複数の管理部１１２Ａ〜１１２Ｅに部分要件（一つ以上の条件の一例）として分解され展開される。部分要件が展開された管理部１１２は、展開された部分要件に対応可能な仮想リソースを、仮想リソースストア１１１を検索することにより、マッチングさせる。結果として、部分要件にマッチする要件を持った仮想リソースが特定される。
【００３３】
部分要件にマッチングされた仮想リソースは、マッチング部１２１により、仮想システムの構成要素として決定され、構成制御部１２２に渡される。構成制御部１２２は、マッチングされた仮想リソースを組み合わせて、ＡＳＰシステム３０１からの仮想システム要件に対応する仮想システムを構成し、その構成や、その仮想システムにおける仮想リソース間（言い換えれば、個別インフラストラクチャ２１１間）の論理的接続を示す接続情報等を構成ストア１２３に登録する。仮想リソース制御部１１３は、構成ストア１２３に登録された情報に基づき、仮想システムを構成する二つ以上の仮想リソースに対応した二つ以上の個別インフラストラクチャ２１１の各々について、当該個別インフラストラクチャ２１１を管理するＩＳＰシステム２２１に対して、仮想リソースのアクティベーションを指示する。
【００３４】
それぞれ仮想リソースのアクティベーションを指示された二つ以上のＩＳＰシステム２２１は、当該指示に応答して、当該ＩＳＰシステム２２１が管理する個別インフラストラクチャ２１１の物理リソースを割り当てたりアクティベーションしたりすることにより、仮想システム（たとえば、ＥｔｏＥ（エンド・ツー・エンド）の仮想システム）のデプロイメントが完了する。結果として、仮想システムの構築が完了する。たとえば、図１に例示される構成においては、センサーネット２１１Ａにおけるセンサー２１１２（ネットワーク２１１１に接続されたセンサー２１１２）から出力されたデータがクラウド２１１Ｅ内のＶＭ２１５２に収容される仮想システムが構築される。当該仮想システムが、上述の仮想システム要件を要求したＡＳＰにより利用される。
【００３５】
図２は、リソースプール管理システム１００の一部の機能を示す。
【００３６】
ＩＳＰシステム２２１からリソースプール管理システム１００へ延びた矢印１４１は、仮想リソース登録およびリソース障害通知のいずれかである。
【００３７】
仮想リソース登録とは、仮想リソースの登録である。すなわち、個別インフラストラクチャ２１１のＩＳＰシステム２２１からの仮想リソースがリソースプールに１１０に登録される。図２では、ＩＳＰシステム２２１Ａからの仮想リソース登録のみ符号が示されているが、他のＩＳＰシステム２２１についても同様に仮想リソース登録がされる。また、図２では、同種の個別インフラストラクチャが複数存在する場合が示されている。リソースプール１１０は、仮想リソースをいわゆる使用権として仮想リソースストア１１１上に論理的にリザーブしている。このようなリソース保持においては、個別インフラストラクチャ２１１の物理リソースの提供形態やＡＳＰからの仮想システム需要の変動に対応して、様々な形態があり得る。仮想システム需要の変動を予測してあらかじめ使用権をリソースプール１１０にリザーブするケースや、ＡＳＰからの予約に基づいて必要な時間フレームでリソースプール１１０に仮想リソースを登録する等があり得る。
【００３８】
リソース障害通知とは、個別インフラストラクチャ２１１に対応した仮想リソースの障害の通知である。すなわち、個別インフラストラクチャ２１１の障害に伴い当該個別インフラストラクチャ２１１に対応した仮想リソースの障害がＩＳＰシステム２２１からリソースプール管理システム１００に通知される。
【００３９】
ＡＳＰシステム３０１からサービステンプレート１２４１へ延びた矢印１４２は、仮想システム構築要求および仮想システム変更要求のいずれかである。仮想システム構築要求は、仮想システム要件（仮想システム全体の要件）を有し、仮想システム変更要求は、変更後の仮想システム要件（変更後の仮想システム全体の要件）を有してもよいし、変更箇所に対応した仮想システム要件部分（変更後の要件）を有してもよい。仮想システム要件は、サービステンプレート１２４１とＡＳＰにより指定された条件との組合せでよい。
【００４０】
システム構築部５０のマッチング部１２１が、たとえば、分解部１２１０、機能性変換部１２１１、機能性マッチング部１２１２、非機能性変換部１２１３および非機能性マッチング部１２１４を有する。
【００４１】
分解部１２１０が、仮想システム要件を機能性要件と非機能性要件に分解する。
【００４２】
機能性変換部１２１１が、機能性要件を、対応する機能性仮想リソース要件に変換する。機能性マッチング部１２１２が、リソースプール１１０の仮想リソースストア１１１から、機能性仮想リソース要件に整合する要件を持つ仮想リソースを検索し、抽出された仮想リソースを構成制御部１２２に渡す。
【００４３】
非機能性変換部１２１３が、非機能性要件を、対応する非機能性仮想リソース要件に変換する。非機能性マッチング部１２１４が、リソースプール１１０の仮想リソースストア１１１から、非機能性仮想リソース要件に整合する要件を持つ仮想リソースを検索し、抽出された仮想リソースを構成制御部１２２に渡す。
【００４４】
構成制御部１２２は、渡された仮想リソースを合成する（論理的に接続する）ことにより、仮想システム構築要求または仮想システム変更要求に対応する仮想システム構成情報を構成ストア１２３に登録する。
【００４５】
リソースプール管理システム１００からＩＳＰシステム２２１へ延びた矢印１４４は、アクティベーション指示（たとえば、リソース確保またはリソース変更とアクティベーションとの指示）である。構成ストア１２３内の情報を基に、仮想リソース制御部１１３が、仮想システムの構成要素としての仮想リソースに対応した個別インフラストラクチャ２１１のＩＳＰシステム２２１に、アクティベーション指示をする。
【００４６】
構成制御部１２２からＡＳＰシステム３０１へ延びた矢印１４５は、デプロイメント通知、変更通知または障害通知である。
【００４７】
具体的には、たとえば、仮想システムが新規に構築された場合、構成制御部１２２は、仮想システム構築要求を発行したＡＳＰシステム３０１に対して、仮想システムのデプロイメント通知（仮想システムのデプロイメントが完了したことを示す通知）を発行する。なお、本実施例において、「仮想システムの構築」とは、仮想システムの構成とデプロイメントとを含む。「仮想システムの構成」は、仮想システム要件に対応した二つ以上の仮想リソースを抽出し当該二つ以上の仮想リソースを論理的に接続した仮想システム構成情報を作成することでよい。「仮想システムのデプロイメント」は、仮想システム構成情報を基にＩＳＰシステム２２１にアクティベーション指示をすることによりリソースの確保（または変更）とリンク機能等のアクティベーションにより仮想システムが利用可能な状態になることである。
【００４８】
また、たとえば、仮想システムが変更された場合、構成制御部１２２は、仮想システム変更要求を発行したＡＳＰシステム３０１に対して、仮想システムの変更通知（仮想システムの変更が完了したことを示す通知）を発行する。なお、仮想システムの変更は、仮想システム全体または一部の変更でよく、仮想システムの変更でも、仮想システムのデプロイメントが行われる。
【００４９】
また、たとえば、ＩＳＰシステム２２１からリソース障害通知が発行された場合、仮想リソース制御部１１３が、当該リソース障害通知から特定された情報を構成ストア１２３に登録する。当該登録された情報を構成制御部１２２が構成ストア１２３から特定した場合、構成制御部１２２が、障害のある仮想リソースを含んだ仮想システムを利用するＡＳＰを特定し、当該ＡＳＰのＡＳＰシステム３０１に、障害通知を送信する。
【００５０】
図３は、テンプレートストア１２４の構成例を示す。
【００５１】
テンプレートストア１２４は、ＡＳＰ毎にサービステンプレートを有する。サービステンプレートは、ＡＳＰ毎に代えてまたは加えて、仮想システム種別ごとに存在してもよい。仮想システム種別は、仮想システムの用途といった一つ以上に属性で定義されてよい。
【００５２】
図３の例によれば、各カラムが、当該カラムに対応したＡＳＰについてのサービステンプレートを示す。サービステンプレートは、仮想システム要件のテンプレートである。仮想システム要件は、機能性要件と非機能性要件に分かれる。機能性要件および非機能性要件のいずれについても、個別要件（「サブ要件」または「部分要件」と呼ばれてもよい）が複数存在してよい。個別要件は、機能または性能等を示す。
【００５３】
各サービステンプレートは、当該テンプレートに対応したＡＳＰの要求する仮想システム要件を構成する個別要件を列挙している。たとえば、ＡＳＰ１が要求する仮想システム要件のサービステンプレートによれば、一例として下記の通りである。
・仮想センサーが拠点（Ａ、Ｂ、Ｃ、…、Ｎ）に配置される。
・クラウドに配置されたＶＭのＣＰＵ性能、メモリ量およびストレージ量が規定される。
・通信帯域は、一センサーあたり最大６４kb/sである。
・トラヒック特性は、１時間当たり２５６kbがバースト的に送信される。
・最大同時接続センサー数は、１００００個である。
・モビリティは不要である。
・センサーとＶＭの間は、完全冗長構成である。
・将来的に機能変更を行うことはない。
・障害時にも通常と同等の運用を確保する必要がある。
・大規模災害時には縮退運転が許可されている。
・クラウド障害においては代替ゾーンへの転送が必要である。
・セキュリティ対策は高度である。
【００５４】
このようなサービステンプレートが示す少なくとも一部の個別要件について、ＡＳＰにより設定または変更が可能である。サービステンプレートが示す仮想システム要件それ自体、または、ＡＳＰによる設定または変更とサービステンプレートとの組合せに従う仮想システム要件が、ＡＳＰシステム３０１からの仮想システム構築要求や仮想システム変更要求に関連付けられる仮想システム要件である。
【００５５】
図４は、仮想リソースストア１１１の構成例を示す。
【００５６】
仮想リソースストア１１１は、ＩＳＰ毎に仮想リソースを有する。仮想リソースは、ＩＳＰ毎に代えてまたは加えて、個別インフラストラクチャ種別ごとに存在してもよい。
【００５７】
図４の例によれば、各カラムが、当該カラムに対応したＩＳＰについての仮想リソースを示す。この例では、ＩＳＰ毎（個別インフラストラクチャ毎）に仮想リソースの要件（たとえば機能）が列挙される。図４においては、説明の簡単のために、個別インフラストラクチャにまとめた記述となっているけれども、実際にはリソースプール管理システム１００が操作可能な仮想リソースインスタンスごとに記述されてよい。仮想リソースインスタンスは、たとえば拠点Ａ−Ｂ間のリンクやクラウドのＶＭのようなサービス粒度で記述されることもあれば、広域に広がるセンサー全体あるいは、ＳＤ−ＷＡＮから切り出されたネットワークを仮想リソースインスタンスとして登録することもあり得る。また、図４には示されていないが、要件は、図３同様に、機能性要件あるいは非機能性要件の属性を持つ。
【００５８】
図５は、構成ストア１２３の構成例を示す。
【００５９】
構成ストア１２３は、仮想システム毎に仮想システム構成情報を有する。図５の例によれば、各カラムが、当該カラムに対応した仮想システムについての仮想システム構成情報（接続情報を含んでよい）を示す。各仮想システムについて、仮想システム構成情報は、仮想システムを構成する仮想リソースの列挙でよい。ここで列挙される仮想リソースは実際に当該仮想システムが占有的または統計的に利用できる仮想リソースインスタンスでよい。
【００６０】
図３〜図５が示すストア構成によれば、サービステンプレートが持つ仮想システム要件と、登録された仮想リソースが持つ要件と、構成された仮想システムが持つ仮想システム要件とのいずれも、仮想システム要件を構成し得る全ての個別要件、具体的には、全ての個別要件項目と、各個別要件項目について要件値とを有してよい。たとえば、サービステンプレート、仮想リソース及び仮想システム構成情報のいずれも、共通のＮの個別要件（Ｎは２以上の整数）を持っていてもよい。この場合、機能性要件に属する個別要件の数をｎとした場合、非機能性要件に属する個別要件の数は（Ｎ−ｎ）でよい。
【００６１】
また、ストア１１１、１２４および１２３において、個別要件項目は必ずしも一致してなくてもよい。たとえば、サービステンプレートにおける個別要件項目「エンドシステム仕様」は、仮想リソースや仮想システム構成情報における個別要件項目「エンドシステム機能」と「エンドシステムロケーション」との組合せに対応してよい。
【００６２】
また、複数の仮想システムに同種別の仮想リソースがある場合、下記のうちのいずれが採用されてもよい。
・当該同種別の仮想リソースは、論理的に（たとえば時間的に）区別されることで論理的に異なる複数の仮想リソースとされる。当該複数の仮想リソースの各々は、当該仮想リソースを含む仮想システムの専用リソースである。
・当該同種別の仮想リソースは、複数の仮想システムに共有される一つの仮想リソースとされる。
【００６３】
図６は、仮想システム構築処理を含む処理全体のフローを示す。
【００６４】
＜仮想リソース登録（Ｓ３０１、Ｓ３１１およびＳ３１２）＞
【００６５】
ＩＳＰシステム２２１が、当該ＩＳＰシステム２２１の管理下にある個別インフラストラクチャ２１１に対応した仮想リソースを仮想リソースストア１１１に登録する。一例として、下記の処理が行われる。
【００６６】
ＩＳＰシステム２２１Ａが、センサーネット２１１Ａの物理リソースの仮想化を行い（Ｓ３０１Ａ）、仮想化されたリソース（つまり仮想リソース）をリソースプール１１０に登録することの要求をリソースプール管理システム１００に出す。また、ＩＳＰシステム２２１Ｂが、無線アクセス網２１１Ｂの物理リソースの仮想化を行い（Ｓ３０１Ｂ）、仮想化されたリソース（つまり仮想リソース）をリソースプール１１０に登録することの要求をリソースプール管理システム１００に出す。このような要求を受けたリソースプール管理システム１００では、要求のあった個別インフラストラクチャ毎に、仮想リソースが確保され（Ｓ３１１）、且つ、確保された仮想リソースは仮想リソースストア１１１に登録される（Ｓ３１２）。
【００６７】
＜サービステンプレートの準備（Ｓ３２１）＞
【００６８】
テンプレートストア１２４に、サービステンプレートが登録される（Ｓ３２１）。
【００６９】
＜仮想システム構築処理（Ｓ３３１〜Ｓ３４４）＞
【００７０】
ＡＳＰシステム３０１は、仮想システム要件を生成し（Ｓ３３１）、テンプレートストア１２４から、その要件に適合するサービステンプレートを選択し（Ｓ３３２）、当該サービステンプレートに基づいて仮想システム要件をリソースプール管理システム１００に通知する（Ｓ３３３）。たとえば、Ｓ３３１では、仮想システム要件の一部の個別要件が生成されてよい。Ｓ３３２では、生成された個別要件をキーに見つかったサービステンプレートが選択されてよい。Ｓ３３３で通知された仮想システム要件は、選択されたサービステンプレートが持つ仮想システム要件それ自体、または、サービステンプレートが持つ仮想システム要件とＡＳＰにより生成された個別要件との組合せとしての仮想システム要件でよい。
【００７１】
リソースプール管理システム１００のマッチング部１２１は、要件通知（仮想システム要件の通知）を受け、その要件通知のシンタックスを確認する（Ｓ３３４）。シンタックスに不整合がなければ、マッチング部１２１は、当該要件通知が示す仮想システム要件を、個別インフラストラクチャに対する個別要件へ分割する（Ｓ３３５）。分割された個別要件に基づいて、マッチング部１２１は、個別インフラストラクチャ毎に、個別要件にマッチする要件を持つ仮想リソースがあれば当該仮想リソースを仮想リソースストア１１１から抽出する（Ｓ３３６）。マッチング部１２１は、抽出された仮想リソースを合成する（論理的に接続する）ことにより、抽出された仮想リソースの集合としての仮想システムの仮想システム要件（たとえば機能および性能）を計算し、計算要件（計算された仮想システム要件）と、要求要件（上記要件通知が示す仮想システム要件）との差分を計算する（Ｓ３３７）。マッチング部１２１は、計算された差分を、要件通知の送信元のＡＳＰシステム３０１に通知し、当該ＡＳＰシステム３０１が、差分通知（計算要件と要求要件との差分を示す通知）を受信する（Ｓ３３８）。Ｓ３３７では、たとえば、計算要件も要求要件も共通のＮの個別要件項目を持っていて、Ｎの個別要件項目の各々について、要件値の差分が算出されてよい。算出された差分（差分通知が示す差分）は、Ｎの個別要件項目にそれぞれ対応したＮの要件値差分の集合（たとえばリスト）でよい。
【００７２】
ＡＳＰシステム３０１のユーザ（ＡＳＰ）は、差分通知が示す差分を受け入れ可能か判断する（Ｓ３３９）。受け入れ可能であれば、ＡＳＰシステム３０１が、仮想システム構築要求をリソースプール管理システム１００に対して発行する。受け入れ不可であれば、処理がＳ３３０１に戻る。つまり、要件が変更される。
【００７３】
仮想システム構築要求を受信したリソースプール管理システム１００では、構成制御部１２２が、計算要件（Ｓ３３７で計算された仮想システム要件）を持つ仮想システムの仮想システム構成情報を生成し（Ｓ３４１）、当該仮想システム構成情報を構成ストア１２３に登録する（Ｓ３４２）。
【００７４】
リソースプール管理システム１００では、仮想リソース制御部１１３が、登録された仮想システム構成情報に基づき、計算要件を持つ仮想システムを構成する仮想リソースに対応したＩＳＰシステム２２１毎に、確保されている仮想リソースのアクティベーションを指示する（Ｓ３４３）。
【００７５】
当該指示を受けたＩＳＰシステム２２１が、その指示に応答して、確保されている仮想リソースの全部または一部に対応した物理リソースを割り当てる（Ｓ３４４）。たとえば、ＩＳＰシステム２２１Ａは、センサーネット２１１Ａの物理リソースを割り当てる（Ｓ３４４Ａ）。また、たとえば、ＩＳＰシステム２２１Ｂは、無線アクセス網２１１Ｂの物理リソースを割り当てる（Ｓ３４１Ｂ）。
【００７６】
本実施例によれば、個別インフラストラクチャからリソースプール１１０に登録された仮想リソースを論理的に組み合わせることにより、個別インフラストラクチャを直接操作することなく仮想システム（たとえばＥｔｏＥの仮想システム）を構築することが可能である。さらには、仮想システムを要求するＡＳＰとの間で実現する仮想システムの要件についての調整が可能であるため、各個別インフラストラクチャの物理的リソースの効率的な使用が可能となる。
【００７７】
Ｓ３３８〜Ｓ３４０の少なくとも一部に代えて、下記のうちのいずれかが採用されてもよい。
・少なくとも一つのＡＳＰについて、許容可能な差分に関するポリシーがあらかじめリソースプール管理システム１００に登録されている。当該ＡＳＰについて、Ｓ３３７で算出された差分が、当該ポリシーが示す許容可能な差分に該当すれば、システム構築部５０は、差分通知を出すこと無しに、仮想システム構成情報を生成する。
・少なくとも一つのＡＳＰについて、許容可能な差分に関するポリシーがあらかじめ当該ＡＳＰのＡＳＰシステム３０１に登録されている。当該ＡＳＰについて、Ｓ３３９では、ＡＳＰシステム３０１が、差分通知が示す差分が、当該ポリシーが示す許容可能な差分に該当するか否かを判断する。
【００７８】
Ｓ３１１において、仮想リソースの確保とは、仮想システムの構成要素とされることの予約に相当してよい。確保されている仮想リソースの全部または一部（たとえば、仮想リソースが持つ性能の一部）が仮想システムに割り当てられる。確保されている仮想リソースの一部が割り当てられた場合、当該仮想リソースの残りは、確保されたままである。各仮想リソースについて、確保に関する情報は、たとえば、仮想リソースストア１１１において、仮想リソース毎に登録されてよい。
【００７９】
仮想システムの仮想システム要件の計算において、仮想システムの構成要素となる仮想リソース間の論理的な接続が行われてよい。たとえば、仮想リソースＡおよびＢの論理的な接続とは、仮想リソースＡから仮想リソースＢへの接続のように、仮想リソース間の接続と接続方向を定義することでよい。複数の仮想リソースがカスケード上に論理的に接続されることで、ＥｔｏＥの仮想システムが構成されることになる。
【００８０】
Ｓ３４３〜Ｓ３４０（つまり、仮想システムのデプロイメント）の詳細の一例は、次の通りでよい。一つの仮想システムを例に取る。仮想リソース制御部１１３が、当該仮想システムの仮想システム構成情報から、当該仮想システムを構成する各仮想リソースを特定する。特定された各仮想リソースについて、仮想リソース制御部１１３が、当該仮想リソースに対応したＩＳＰシステム２２１を特定し（たとえば、仮想リソースストア１１１を参照することで、当該仮想リソースに対応したＩＳＰシステム２２１を特定し）、特定したＩＳＰシステム２２１に対して、当該仮想リソースについてのアクティベーションの指示を出す。当該指示は、たとえば、必要とされる要件（たとえば、機能および性能）や、いずれの個別インフラストラクチャとリンク機能を用いて接続するか（たとえば、リンク先の個別インフラストラクチャに対応したＩＳＰシステム２２１のＩＰアドレスや当該ＩＰシステムへの指令内容）といった種々のパラメータが関連付けられている。当該指示に応じて、ＩＳＰシステム２２１が、個別インフラストラクチャのアクティベーションを行う。仮想システムを構成する各仮想リソースについて、当該仮想リソースに対応したＩＳＰシステム２２１が、当該ＩＳＰシステム２２１に対する上述のような指示に応答してアクティべーションを行うことで、仮想システムのデプロイメントが完了する。仮想システムの構成要素としての仮想リソースに、当該仮想リソースに対応した個別インフラストラクチャ部分がマッピングされる。
【００８１】
図７は、仮想システム変更処理のフローを示す。
【００８２】
ＡＳＰシステム３０１は、利用中の仮想システムの仮想システム要件の変更をアクティベーションし（Ｓ４３１）、利用中の仮想システムの構築のために選択したサービステンプレートを選択する（Ｓ４３２）。ＡＳＰシステム３０１は、当該サービステンプレートに基づく仮想システム要件（利用中の仮想システムの仮想システム要件）の変更要求である要件変更要求をリソースプール管理システム１００に発行する（Ｓ４３３）。要件変更要求は、利用中の仮想システムの仮想システム要件のうちの変更箇所（変更後の個別要件）のみを含んでもよいし、変更箇所を含む仮想システム要件全体を含んでもよい。また、仮想システム要件の変更は、サービステンプレートの選択無しに行われてもよい。また、利用中の仮想システムの構築において選択されたサービステンプレートが持つ仮想システム要件は、変更後の仮想システム要件に更新されてもよい。
【００８３】
リソースプール管理システム１００のマッチング部１２１は、要件変更要求を受信すると、要件変更要求が示す変更内容のシンタックスを確認する（Ｓ４３４）。シンタックスに問題がなければ、Ｓ３３５〜Ｓ３４４とそれぞれ同様のＳ４３５〜Ｓ４４４が行われる。
【００８４】
すなわち、マッチング部１２１は、変更内容が示す要件を、変更内容に対応する個別インフラストラクチャへの要件に分割し（Ｓ４３５）、個別インフラストラクチャ毎に、変更する仮想リソースを仮想リソースストア１１１から抽出する（Ｓ４３６）。マッチング部１２１は、抽出した仮想リソースにより合成される仮想システムの仮想システム要件である計算要件と、要件変更要求に対応した仮想システム要件である要求要件との差分を計算し（Ｓ４３７）、要件変更要求の送信元のＡＳＰシステム３０１に対して、計算された差分を示す差分通知を送信する。当該ＡＳＰシステム３０１が、差分通知を受信する（Ｓ４３８）。ＡＳＰが、当該差分通知が示す差分を受け入れ可能か否かを判断する（Ｓ４３９）。受け入れ可能であれば、ＡＳＰシステム３０１が、仮想システム変更要求をリソースプール管理システム１００に対して発行する。受け入れ不可であれば、処理がＳ４３１に戻る。
【００８５】
仮想システム変更要求を受信したリソースプール管理システム１００の構成制御部１２２は、仮想システム構成情報を生成（たとえば変更）し（Ｓ４４１）、当該仮想システム構成情報を構成ストア１２３に登録する（Ｓ４４２）。仮想リソース制御部１１３が、登録された仮想システム構成情報に基づき、変更箇所に対応した個別インフラストラクチャのＩＳＰシステム２２１に、対応する仮想リソースの変更要求を発行する（Ｓ４４３）。
【００８６】
仮想リソース変更要求を受信したＩＳＰシステム２２１は、当該変更要求に基づき物理リソースの割り当てを変更する（Ｓ４４４）。図７の例では、変更対象が無線アクセス網２１１Ｂのため、ＩＳＰシステム２２１Ｂに仮想リソース変更要求が送信される。なお、変更対象の仮想リソースに対応したＩＳＰシステム２２１の特定や、当該ＩＳＰシステム２２１に対する要求（指示）についての詳細は、仮想システム構築処理と同様でよい。たとえば、仮想リソース変更要求は、変更後の要件（たとえば性能）といったパラメータを含み、当該パラメータを基に、ＩＳＰシステム２２１が、物理リソースの割り当てを変更する。
【００８７】
仮想システム変更処理によれば、ＡＳＰシステム３０１からの仮想システム変更要求に対して、リソースプール１１０上に登録された仮想リソースの論理的操作により実現可否および要件調整が可能となり、ＡＳＰシステム３０１は各個別インフラストラクチャと個別に調整する必要がないため、迅速な仮想システム変更が可能となる。
【００８８】
図８は、障害対応処理のフローを示す。
【００８９】
障害が発生した個別インフラストラクチャの一例が、無線アクセス網２１１Ｂであるとする。この場合、ＩＳＰシステム２２１Ｂは、仮想リソース障害通知をリソースプール管理システム１００に対して発行する（Ｓ５０１）。
【００９０】
リソースプール管理システム１００のマッチング部１２１は、当該通知を受信し（Ｓ５０２）、当該通知から特定される仮想リソース（無線アクセス網の仮想リソース）について障害を、たとえば仮想リソースストア１１１に登録する（Ｓ５０３）。マッチング部１２１は、無線アクセス網の障害により影響を受ける仮想システム、仮想リソースおよびＡＳＰ（ユーザ）を、各管理部１１２を用いて抽出する（Ｓ５０４）。抽出される仮想システムの一例は、無線アクセス網に対応した仮想リソースを含んだ仮想システムである。抽出される仮想リソースは、当該仮想システムのうち、無線アクセス網に対応した仮想リソースと論理的に接続されている仮想リソースである。抽出されるＡＳＰの一例は、抽出される仮想システムに対応したＡＳＰ（たとえば、当該仮想システムの構築において選択されたサービステンプレートに対応したＡＳＰ）である。
【００９１】
マッチング部１２１は、Ｓ５０４で抽出されたＡＳＰのＡＳＰシステム３０１と、抽出された仮想システムおよび仮想リソースについての情報を含んだ障害情報とを構成制御部１２２に通知する。構成制御部１２２は、当該ＡＳＰシステム３０１に対して、当該障害情報を含んだ障害通知を発行する（Ｓ５０５）。
【００９２】
障害通知を受けたＡＳＰシステム３０１は、障害通知を受信し（Ｓ５０６）、この障害通知が示す障害情報を表示する。ＡＳＰは、表示された障害情報を基に、障害前後の要件の差分を受け入れ可能か判断する（Ｓ５０７）。受け入れ可能であれば、処理が終了する（たとえば、別の障害通知の待ちとなる）。受け入れ不可であれば、ＡＳＰシステム３０１は、仮想システム要件を変更し（Ｓ５０８）、利用中の仮想システムに対応したサービステンプレートを選択して（Ｓ５０９）、要件変更要求をリソースプール管理システム１００に対して発行する（Ｓ５１０）。Ｓ５０８〜Ｓ５１０は、Ｓ４３１〜Ｓ４３３と同様でよい。また、Ｓ５０２〜Ｓ５０７の少なくとも一部に代えて、下記のうちの少なくとも一つが行われてよい。
・障害前後の要件差分が、許容可能な差分に関するポリシーが示す許容可能な差分に該当すれば、自動的にＳ５０７：Ｙとなり、そうでなければ、自動的にＳ５０７：Ｎでよい。
・Ｓ５０４で、障害が生じた仮想リリースの代替仮想リソースが抽出されてよい。代替仮想リソースは、障害が生じた仮想リリースが持つ要件との差分が一定範囲に収まる要件を持つ仮想リソースである。障害通知が示す障害情報は、障害が生じた仮想リソースを示す情報の他に、代替仮想リソースを示す情報を含む。このため、障害通知が示す障害情報の表示は、代替仮想リソースの提案となる。
【００９３】
要件変更要求が送信された後、Ｓ４３４〜Ｓ４４４とそれぞれ同様のＳ５１１〜Ｓ５２１が行われる。
【００９４】
障害対応処理によれば、リソースプール管理システム１００が各個別インフラストラクチャから登録された仮想リソースを使用している仮想システムを一元的に把握しているため、個別インフラストラクチャ障害の波及範囲や代替仮想リソースの提案を迅速かつ効率的に実現できる。なお、システム構築部５０は、ＩＳＰシステム２２１から障害通知を受けても、下記のうちのいずれかに該当する場合は、障害通知をＡＳＰシステム３０１に出さないでよい（具体的には、たとえば、Ｓ５０３とＳ５０４の間に、障害通知をＡＳＰシステムに出す必要があるか否かを判断し、当該判断の結果が真の場合にＳ５０４を行ってもよい）。
・通知された障害が、障害に影響しないとあらかじめ規定されている要件（たとえば、日機能要件に属する所定の一つ以上の要件）に該当する。
・障害前後の仮想システム要件の差分が、あらかじめ規定された許容範囲にある。
【実施例２】
【００９５】
実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略または簡略する。
【００９６】
本実施例では、要求要件、計算要件、および、仮想リソースが持つ要件のいずれも、ベクトルで表現される。このため、より迅速かつ効率的に仮想システムの構築や変更を行うことが期待される。ベクトルは、あらかじめストア１１１、１２４および１２３のうちの少なくとも一つに登録されていてもよいし、処理の都度に計算されてもよい。
【００９７】
仮想システム要件は複数の個別要件から構成されており（たとえば図３参照）、そのような複数の個別要件の表現としての要件ベクトルは、多次元のベクトルである。各次元の量は要件に応じて計量単位は異なり、また連続的な数値をとることもあれば離散的な特性値をとることもある。図９Ａは、仮想システム要件のうちの機能性要件に属するｎの個別要件の表現の一例としてのｎ次元要件ベクトル８０１を示している。
【００９８】
非機能性要件のような定性的な要件の場合には、所定の手続きによって定性的機能を離散的数値化することも行われる。図９Ｂは、機能性要件に属するｎの個別要件に非機能性要件に属する（Ｎ−ｎ）の個別要件を加えたＮの個別要件で構成された仮想システム要件の表現の一例としてのＮ次元要件ベクトル８０２を示す。図９Ｂによれば、非機能性要件（ここでは二重化の有無）を１または０の離散的な数値により表現し、要件ベクトル８０２の独立な次元とする例を示している。また各機能性および機能性要件の需要や供給における諸条件を考慮した次元間の重みづけを行うこともあり得る。これらはいずれもリソースプール１１０における仮想リソースの登録あるいは合成において論理的に実施されるものであり、各個別インフラストラクチャ２１１についてのリソース仮想化のプロセスに直接影響を与えるものではない。
【００９９】
要求要件（ＡＳＰシステムから要求された仮想システム要件）は、複数の個別インフラストラクチャへの複数の個別要件に分割される。具体的には、たとえば、マッチング部１２１が、要求要件の表現としてのＮ次元要件ベクトルを計算し、当該Ｎ次元要件ベクトルを、複数の個別インフラストラクチャに対応した複数の個別要件ベクトルに分割する。図１０は、ある一つの個別インフラストラクチャ（図１０の説明において「対象個別インフラストラクチャ」）に対応した一つの個別要件ベクトル７０を示す。個別要件ベクトル７０は、合成ベクトルである。図１０の例によれば、以下の通りである。
【０１００】
対象個別インフラストラクチャは、ノードＡ〜ノードＤと、リンク８１１Ａ〜８１１Ｅといった物理リソースを有するとする。これらの物理リソースに対応した仮想リソースがリソースプール１１０に登録されているとする。要求要件によれば、ノードＡからノードＤへの経路に対応した仮想リソースが必要であるとする。ここで、ノードＡからノードＤへの経路の一例として、ノードＡとノードＢ間のリンク８１１Ａに対応した仮想リソースと、ノードＢとノードＤ間のリンク８１１Ｄに対応した仮想リソースが抽出されたとする。リンク８１１Ａに対応した仮想リソースの要件は、ベクトル８２１Ａで表現され、リンク８１１Ｄに対応した仮想リソースの要件は、ベクトル８２１Ｄで表現される。この場合、要求要件のうち対象個別インフラストラクチャについての個別要件ベクトル７０は、ベクトル８２１Ａとベクトル８２１Ｄの合成ベクトルとされる。なお、たとえばノードＢに障害が生じた場合、ノードＡとノードＣ間のリンク８１１ＢとノードＣとノードＤ間のリンク８１１Ｅとに対応したベクトルの合成ベクトルが対象個別インフラストラクチャについての個別要件ベクトル７０とされてよい。
【０１０１】
図１０の例によれば、機能性要件および非機能性要件のいずれも多様な個別要件で定義される仮想システムを、要件ベクトルの合成として統合的に管理操作可能な対象として取り扱うことが可能になる。また、各個別インフラストラクチャについて、当該個別インフラストラクチャ対応した仮想リソース構成を隠ぺいして、当該個別インフラストラクチャに対応した単一の要件ベクトルとして仮想リソースを取り扱うことが可能となる。
【０１０２】
図１０を参照して説明した処理を、各個別インフラストラクチャについて登録された仮想リソースに対してシステム構築部５０が実施することで、図１１に例示するように、個別インフラストラクチャ２１１Ａ〜２１１Ｅについてそれぞれ個別要件ベクトル７０Ａ〜７０Ｅが得られる。システム構築部５０は、個別要件ベクトル７０Ａ〜７０Ｅを合成することで、センサー２１１２からＶＭ２１５２までのＥｔｏＥの仮想システムの要求要件のベクトル８２０を得る。
【０１０３】
しかし、常に要求要件のベクトル８２０と完全に一致するベクトルが得られる計算要件を持った仮想システム（抽出された仮想リソースで構成された仮想システム）が得られるわけではない。図１２の例によれば、システム構築部５０は、個別インフラストラクチャ２１１Ａ〜２１１Ｅについてそれぞれ抽出された仮想リソースの個別要件ベクトル８３１Ａ〜８３１Ｅを合成することで計算要件のベクトル８３０を得る。計算要件のベクトル８３０は要求要件のベクトル８２０とは異なる場合がある。このような場合には、システム構築部５０は、両者のベクトル８２０と８３０の差分８３７を計算する。差分８３７の一例としては、要件ベクトル８３０と要件ベクトル８２０の間のベクトル差分がある。あるいはベクトル８２０および８３０の間の関係を差分の計量として使うことも考えられ、たとえばスカラー積、あるいはベクトル積が採用されてもよい。
【０１０４】
図１２の例によれば、仮想システムの論理的な計量として定義された要件ベクトルの間で種々の演算を行うことにより、要求要件と計算要件（実現仕様）との差を表現することが可能となり、要求された仮想システム要件に対する実現可能な仮想システム要件がＡＳＰに容易に伝達可能となる。
【０１０５】
なお、システム構築部５０は、要求要件のベクトル８２０を分解することで個別インフラストラクチャ毎に個別要件ベクトル７０を取得し、個別要件ベクトル７０をキーに、当該個別要件ベクトル７０との差分が一定範囲内に収まるベクトルとなる要件に対応した仮想リソースを抽出してもよい。
【０１０６】
図１３は、要件ベクトルの合成として実現した仮想システムの内、一部の個別インフラストラクチャによる仮想リソースが利用不可となった場合の例を示す。
【０１０７】
図１３の例によれば、ＶＰＮ２１１Ｄが障害となった場合にインターネット２１１Ｘへ迂回することが、ＶＰＮ２１１Ｄの仮想リソースを含んだ仮想システムを利用しているＡＳＰに提案される。インターネット２１１Ｘも個別インフラストラクチャの一例であり、インターネット２１１Ｘの仮想リソースも仮想リソースストア１１１に登録されているとする。
【０１０８】
図１３の例では、ＶＰＮ２１１Ｄが障害のため個別要件ベクトル８４１Ｄに対応した仮想リソースが利用不可であり、さらに、個別要件ベクトル８４１Ｄの前後の個別要件ベクトル８４１Ｃおよび８４１Ｅにそれぞれ対応した仮想リソース（ＳＤ−ＷＡＮ２１１Ｃ上の仮想リソースとクラウド２１１Ｅ上の仮想リソース）も、ＥｔｏＥの仮想システムで利用不可となっている。
【０１０９】
この場合、システム構築部５０が、個別要件ベクトル８４１Ｃ〜８４１Ｅを一部とする要件ベクトル８４０（利用中の仮想システムの仮想システム要件の表現としての要件ベクトル）の一部分を、代替仮想リソース（インターネット２１１Ｘに対応した仮想リソース）の要件ベクトル８４１Ｘとインターネット２１１Ｘと接続されるクラウド２１１Ｅの仮想リソースの要件ベクトル８４１Ｅ´の合成ベクトルとして構成する。そして、システム構築部５０は、当該合成ベクトルを、前述の要件ベクトル８４１Ｃ〜８４１Ｅの代替し、当該代替後の仮想システムの仮想システム要件の要件ベクトルを算出する。
【０１１０】
図１３の例によれば、個別インフラストラクチャに障害が発生した場合の代替手段を当該個別インフラストラクチャにおける代替要件ベクトル、あるいは当該障害個別インフラストラクチャに接続される個別インフラストラクチャを含めた代替要件ベクトルとして定義できるため、迅速かつ効率的な障害対応が可能となる。
【０１１１】
以上が実施例２の説明である。なお、たとえば、ＥｔｏＥの仮想システムに関し、エンドシステムがｐ個があれば、ｐ本の要件ベクトルが生成されてもよいし、ｐ本の要件ベクトルの合成ベクトルが生成されてもよい。
【０１１２】
以上の実施例１および実施例２を、たとえば下記のように総括することができる。なお、下記の総括は、上述の説明に無い事項を含んでもよい。
【０１１３】
リソースプール１１０は、複数のＩＳＰにより提供される複数の個別インフラストラクチャ２１１の各々について当該個別インフラストラクチャ２１１を実現する一つ以上の要件を示すデータを仮想リソースとして含む。システム構築部５０は、要求要件との差分が許容範囲にある計算要件となる二つ以上の仮想リソースをリソースプール１１０から特定する。要求要件と計算要件（実現要件）が一致すれば、差分はゼロである。システム構築部５０は、当該二つ以上の仮想リソースから成る仮想システムを構成し、当該二つ以上の仮想リソースの各々について、当該仮想リソースに対応した個別インフラストラクチャを提供するＩＳＰのＩＳＰシステム２２１を特定し、当該ＩＳＰシステム２２１に、当該仮想リソースに対応した個別インフラストラクチャリソースのアクティベーションを指示する。
【０１１４】
複数の個別インフラストラクチャ２１１は、一つ以上のネットワーク（たとえば、センサーセット、無線アクセス網等）を含む。一般に、アプリケーションサービスの提供のための二つ以上の個別インフラストラクチャにネットワークが含まれるとＡＳＰにとっての負担が一層高い（特に、アプリケーションサービスの提供のために二つ以上のＩＳＰが提供する二つ以上のネットワークの要件が必要な場合）と考えられるが、ネットワークを含めリソースプールとして管理されるため、ＡＳＰの負担は低減される。たとえば、センサーネット２１１Ａのセンサー２１１２からクラウド２１１ＥのＶＭ２１５２をつなげるために無線アクセス網２１１ＢのＩＳＰとＳＤ−ＷＡＮ２１１ＣのＩＳＰといった複数のＩＳＰの各々に拠点間接続のためのオーダーをＡＳＰが出すといった負担を無くすことができる。
【０１１５】
コネクティビティを提供するサービスは地理的条件に依存するので、このような場合は特にネットワークが大きなボトルネックになる。しかし、ネットワークは、一般に、完成させるまでに時間と費用が大きくかかるいわゆる設備産業であるため、比較的長い期間使用されることが望まれ、また、個別要件が多く使用可能になるまで比較的長い時間がかかる。一方、アプリケーションサービスは、一般に、ネットワークの製品ライフサイクルに比べて製品ライフサイクルが短く、必要とされるときに迅速に提供されることが望まれる。
【０１１６】
上述の実施例１及び２のように、リソースプール１１０に登録される複数の仮想リソースに対応した複数のインフラストラクチャにはネットワークが含まれているので、アプリケーションサービスの提供のための二つ以上の個別インフラストラクチャにネットワークが含まれていてもアプリケーションサービスの迅速な提供が可能である。
【０１１７】
なお、ネットワークは、ストレージやＣＰＵのように要件を明確な機能性要件に定義することが困難である。
【０１１８】
そこで、ネットワークについての仮想リソースであるネットワーク仮想リソースに関し、当該ネットワーク仮想リソースとしてのデータは、複数の要件を示し、当該複数の要件は、機能性要件に属する一つ以上の個別要件に加えて非機能性要件に属する一つ以上の個別要件を含む。
【０１１９】
また、ネットワークは、特に、非機能性要件に属する個別要件の数が多く、ゆえに、要件のスペクトルが大きい。
【０１２０】
そこで、システム構築部５０は、要求要件（Ｍの個別要件で構成）をＭ次元の要件ベクトルとし、計算要件（Ｎの個別要件で構成）をＮ次元の要件ベクトルとする。ＭおよびＮのいずれも２以上の整数である。Ｍ＝ＮでもよいしＭ≠Ｎでもよい。システム構築部５０は、Ｍ次元の要件ベクトルとＮ次元の要件ベクトルとの差分としてのベクトル差分を計算する。ベクトル差分（または、当該ベクトル差分から特定される要件差分リスト（要件項目毎の要件値差分のリスト）が、あらかじめ規定された範囲内にあれば、または、ＡＳＰから承認されれば、上述の許容範囲にある差分に該当する。
【０１２１】
ドメイン（たとえば、ＩＳＰまたは個別インフラストラクチャ）毎に、当該ドメインに関する要件の数に応じた多次元の個別要求ベクトルが生成される。ＥｔｏＥの仮想システムでは、二つ以上の個別要件ベクトルの合成ベクトルが、当該仮想システムの要件ベクトルである。仮想リソースの使用状況によっては要求要件との差分のある計算要件の仮想システムが構成されること（要求要件の要件ベクトルと差分のある要件ベクトルとなる計算要件（実現要件））ができることが多いと考えられるが、その差分が許容範囲内ならば当該差分は許容される。
【０１２２】
システム構築部５０は、利用中の仮想システムの一部の条件を変更する要求を受け付けた場合、変更後の一部の条件に対応した一つ以上の個別要件ベクトルを用いて変更後の条件の表現としての要件ベクトルを算出してよい。システム構築部５０は、当該算出された要件ベクトルと、当該変更後の条件に対応した要件の表現としての要件ベクトルとの差分が許容範囲であれば、利用中の仮想システムのうち変更後の条件に関わる仮想リソースを変更してよい。このように要件ベクトルを用いて仮想システム構成変更を行うことができる。なお、仮想システム構成変更は、要件ベクトルを用いる方法とは別の方法で行われてもよい。
【０１２３】
システム構築部５０は、利用中の仮想システムを構成する二つ以上の仮想リソースのうちの少なくとも一つの仮想リソースに対応した個別インフラストラクチャの障害の通知を受信した場合、当該障害の影響を受ける一つ以上の仮想リソース（たとえば、障害の生じた個別インフラストラクチャに対応した仮想リソース、および、当該仮想リソースに論理的に接続されている仮想リリース）の代替仮想リソースを特定してよい。システム構築部５０は、当該障害の影響を受ける一つ以上の仮想リソースの要件に対応した一つ以上の個別要件ベクトルとの差が許容範囲にある個別要件ベクトルに対応した要件を持つ仮想リソースである代替仮想リソースを特定してよい。システム構築部５０は、当該代替仮想リソースの要件に対応した個別要件ベクトルを用いて、前記障害の影響を受ける一つ以上の仮想リソースに代えて前記代替仮想リソースが採用された仮想システムの要件ベクトルを算出してよい。システム構築部５０は、算出された要件ベクトルと、上記Ｍの条件の表現としての要件ベクトルとの差分が許容範囲であれば、利用中の仮想システムのうちの一つ以上の仮想リソースを代替仮想リソースに差し替えてよい。このように要件ベクトルを用いて代替仮想リソースの特定や仮想リソースの差替を行うことができる。なお、代替仮想リソースの特定や仮想リソースの差替は、要件ベクトルを用いる方法とは別の方法で行われてもよい。
【０１２４】
システム構築部５０は、利用中の仮想システムを構成する二つ以上の仮想リソースのうちの少なくとも一つの仮想リソースに対応した個別インフラストラクチャの障害の通知を受信した場合、当該障害の影響を受ける一つ以上の仮想リソースの当該障害後の要件に対応した一つ以上の個別要件ベクトルを用いて、利用中の仮想システムの当該障害後の仮想システム要件の要件ベクトルを算出してよい。システム構築部５０は、当該算出された要件ベクトルと、上記Ｍの条件の表現としての要件ベクトルとの差分が許容範囲であれば、利用中の仮想システムの利用を継続してよい。このように要件ベクトルを用いて障害前後の仮想システム要件の差分を計算できる。なお、障害前後の仮想システム要件の差分は、要件ベクトルを用いる方法とは別の方法で行われてもよい。
【０１２５】
上述の説明においては、各個別インフラストラクチャ２１１について登録された仮想リソースの個別要件ベクトルの合成として仮想システム要件の要件ベクトルが算出される。しかし、この方法は単一の仮想システムの構築（または変更）だけに限られるものではなく、複数の仮想システムの構築（または変更）を同時に行う場合であっても適用可能である。その場合、複数の要求仮想システム要件ベクトルと実現要件ベクトルとの差分を合成する、あるいは要求仮想システム要件ベクトル自体を合成し、実現要件ベクトルの合成との差分を比較する等のトータルなマッチング計算を行うことが可能である。この方法によれば、複数の仮想システム構築要求（または複数の仮想システム変更要求）に対して対応する実現仮想システム（抽出された仮想リソースから構成される仮想システム）の割当をリソースプール全体にわたる効率的なマッチングとして実行することが可能となる。
【０１２６】
また、上述の説明においてはＡＳＰシステム３０１からの仮想システム構築要求（または仮想システム変更要求）を契機として仮想リソース割当て（仮想システムのデプロイメント）が行われる。しかし、それに代えてまたは加えて、あらかじめＡＳＰからの仮想システム需要を予測してリソースプールに登録された仮想リソースを予約する場合にも同様に適用可能である。このような仮想システム需要予測による仮想リソース予約をリソースプール上で論理的に実現可能であるため、ＡＳＰからの仮想システム構築要求（または仮想システム変更要求）に対して迅速に対応可能、あるいは時間予約型の仮想システム構築要求（または仮想システム変更要求）に対しても対応できる。さらには、ＡＳＰからの仮想システム構築要求（または仮想システム変更要求）のトレンドを見ながら需要予測を行うことも、要件ベクトルという仮想的操作可能な論理インスタンスを対象に演算することで可能となる。このような需要予測は複数の仮想システム構築要求（または仮想システム変更要求）を合成する前述の実施例の手法と組み合わせることでトータルな需要予測の精度を確保できる。
【０１２７】
少なくとも一つの実施例によれば、機能および管理者の異なる複数の個別インフラストラクチャからなる複数種類の仮想システムを、ＡＳＰから要求される仮想システム要件に整合するように迅速かつ効率的に構築することが可能となる。
【０１２８】
また、少なくとも一つの実施例によれば、ＡＳＰが要求する要件（たとえば、機能、性能またはサービスエリア）を持つ仮想システムを、それぞれの個別インフラストラクチャに対応した操作を必要とすることなく（たとえば、個々にＩＳＰにコンタクトする必要無く）、迅速かつ簡単に仮想システムを構築することが可能となる。
【０１２９】
また、多種多様な個別インフラストラクチャの相互接続によるＥｔｏＥの仮想システムの構成および運用にあたって、個別インフラストラクチャを運用するＩＳＰは、個々のＡＳＰからの仮想システム要件を理解しかつすべての構成メンバとの間で相互に要件の整合化を図るという困難な作業から解放され、自らの管理する個別インフラストラクチャの管理に注力可能となる。
【０１３０】
以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。
【符号の説明】
【０１３１】
１００：リソースプール管理システム
【図１】
2020140415.tif 000003
【図２】
2020140415.tif 000004
【図３】
2020140415.tif 000005
【図４】
2020140415.tif 000006
【図５】
2020140415.tif 000007
【図６】
2020140415.tif 000008
【図７】
2020140415.tif 000009
【図８】
2020140415.tif 000010
【図９Ａ】
2020140415.tif 000011
【図９Ｂ】
2020140415.tif 000012
【図１０】
2020140415.tif 000013
【図１１】
2020140415.tif 000014
【図１２】
2020140415.tif 000015
【図１３】
2020140415.tif 000016