特許 7405241 リソース管理装置、リソース管理方法、および、リソース管理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-18

(45)【発行日】2023-12-26

(54)【発明の名称】リソース管理装置、リソース管理方法、および、リソース管理プログラム

(51)【国際特許分類】

   G06F 8/60 20180101AFI20231219BHJP

   G06F 9/50 20060101ALI20231219BHJP

【ＦＩ】

G06F8/60

G06F9/50 120Z

【請求項の数】 5

(21)【出願番号】P 2022510365

(86)(22)【出願日】2020-03-27

(86)【国際出願番号】 JP2020014208

(87)【国際公開番号】W WO2021192266

(87)【国際公開日】2021-09-30

【審査請求日】2022-07-28

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110001807

【氏名又は名称】弁理士法人磯野国際特許商標事務所

(72)【発明者】

【氏名】青木 大輔

(72)【発明者】

【氏名】長谷部 克幸

(72)【発明者】

【氏名】神崎 誠

(72)【発明者】

【氏名】日下部 優介

【審査官】三坂 敏夫

(56)【参考文献】

【文献】特表２０１７－５３６６０８（ＪＰ，Ａ）

【文献】吉田 浩 他，サービス指向プラットフォーム，ＦＵＪＩＴＳＵ ２０１０－５月号 Vol.61,No.3，富士通株式会社，2010年05月10日，第61巻 第3号，第283頁－第290頁，ISSN:0016-2515

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／００ー ８／３８

Ｇ０６Ｆ ８／６０ー ８／７７

Ｇ０６Ｆ ９／４４－ ９／４５５

(57)【特許請求の範囲】

【請求項1】

サービス提供するためのリソースを管理するリソース管理装置であって、
前記リソース管理装置は、
アプリケーションレイヤに配置されるリソースとしての複数のアプリケーション、仮想レイヤに配置されるリソースとしての複数の仮想リソース、物理レイヤに配置されるリソースとしての複数の物理リソース、のいずれかのリソースのうち、リレーションをもつ２つのリソースの組を示すデータモデルの集合であるデータモデル群を記憶しており、
サービスの提供に必要なアプリケーションを選択し、選択したアプリケーションが利用するデータの送信元のリソースから送信先のリソースまでの経路を示すデータパイプラインを設定し、
選択した前記アプリケーションに対して、前記データモデル群を参照し、前記データパイプラインにおいてデータのやりとりが可能となるように複数のリソースを選択する選択部と、
前記選択されたリソースを用いたシステムを設計するためのブループリントを生成する設計部と、
前記設計したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するオーケストレータ部と、を備えることを特徴とするリソース管理装置。

【請求項2】

前記データモデルは、複数のサービスを組み合わせる際にリファレンスとして活用されるとともに、前記リソースの動的な変化に伴い更新されることを特徴とする請求項１に記載のリソース管理装置。

【請求項3】

サービス提供するためのリソースを管理するリソース管理装置が、
アプリケーションレイヤに配置されるリソースとしての複数のアプリケーション、仮想レイヤに配置されるリソースとしての複数の仮想リソース、物理レイヤに配置されるリソースとしての複数の物理リソース、のいずれかのリソースのうち、リレーションをもつ２つのリソースの組を示すデータモデルの集合であるデータモデル群を記憶しており、
サービスの提供に必要なアプリケーションを選択し、選択したアプリケーションが利用するデータの送信元のリソースから送信先のリソースまでの経路を示すデータパイプラインを設定するステップと、
選択した前記アプリケーションに対して、前記データモデル群を参照し、前記データパイプラインにおいてデータのやりとりが可能となるように複数のリソースを選択するステップと、
前記選択されたリソースを用いたシステムを設計するためのブループリントを生成するステップと、
前記設計したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するステップと、を実行することを特徴とするリソース管理方法。

【請求項4】

前記データモデルは、複数のサービスを組み合わせる際にリファレンスとして活用されるとともに、前記リソースの動的な変化に伴い更新されることを特徴とする請求項３に記載のリソース管理方法。

【請求項5】

コンピュータに、請求項３または請求項４に記載のリソース管理方法を実行させるためのリソース管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、リソース管理装置、リソース管理方法、および、リソース管理プログラムに関する。

【背景技術】

【0002】

近年、クラウドサービス等のサービス事業者がサービスをエンドユーザに提供するための技術開発が盛んに行われている。例えば、特許文献１には、「ユーザに通信を提供する端末機からの通信サービス利用のためのオーダ要求に応じて、卸サービス事業者毎に通信サービスＡＰＩで公開される各々異なる１つの通信サービスを１又は複数一括して提供する事業者間一括サービス構築装置であって、通信の卸サービスの仕様が記述されたカタログと、各種の通信サービスの連携を定めた連携ルールとを保持し、前記端末機から複数の通信サービス利用のオーダ要求があった場合に、前記保持された前記カタログ及び前記連携ルールに基づき、当該オーダ要求された複数の通信サービスに対応する前記通信サービスＡＰＩを一括に連携させて連携サービスを構築し、この構築された連携サービスを前記端末機へ提供する一括構築機能部を備えることを特徴とする事業者間一括サービス構築装置」について開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１８－３２８９７号公報（請求項１）

【発明の概要】

【発明が解決しようとする課題】

【0004】

また、近年では、ＰａａＳ（Platform as a Service）やＩａａＳ（Infrastructure as a Service）などの、インターネット経由で利用したり提供したりすることが可能なサービスが数多く存在し、そのような複数種類のサービスを提供するシステムの技術開発が盛んに行われている。複数種類のサービスの各々を扱うベンダは固有のドメインを用意している（マルチドメイン）。つまり、複数種類のドメインが存在しており、ドメイン間で連携可能となるようにシステムの設計が行われる。また、複数種類のサービスの提供のために仮想化技術が用いられている。よって、各ドメイン内のリソースは多層化されており、物理レイヤ、仮想レイヤ、アプリケーションレイヤなどに属している（マルチレイヤ）。リソースは、ＩＣＴ（Information and Communication Technology）リソースとも呼ばれる。そして、複数種類のサービスが連携可能となるようにシステムの設計が行われ、異なるサービスを利用するユーザ同士のやり取りを実現する（マルチサービス）。なお、マルチドメイン、マルチレイヤ、マルチサービスをまとめたものを以下「トリプルマルチ」と呼ぶ場合がある。

【0005】

しかし、一般的には、各リソースの所有者が異なるため、各リソースはドメインごと、レイヤごとで個別に管理される。このため、通常は、あるリソース群から構成されるシステムの運用ノウハウを他のリソース群に適用することはできない。その結果、従来では、トリプルマルチにおけるリソースの制御は極めて複雑であり、トリプルマルチに対応可能なシステムの設計は容易でなかった。

【0006】

このような事情を鑑みて、本発明は、複数種類のサービスを提供するシステムの設計を容易にすることを課題とする。

【課題を解決するための手段】

【0007】

前記した課題を解決するため、本発明のリソース管理装置は、サービス提供するためのリソースを管理するリソース管理装置であって、前記リソース管理装置が、アプリケーションレイヤに配置されるリソースとしての複数のアプリケーション、仮想レイヤに配置されるリソースとしての複数の仮想リソース、物理レイヤに配置されるリソースとしての複数の物理リソース、のいずれかのリソースのうち、リレーションをもつ２つのリソースの組を示すデータモデルの集合であるデータモデル群を記憶しており、サービスの提供に必要なアプリケーションを選択し、選択したアプリケーションが利用するデータの送信元のリソースから送信先のリソースまでの経路を示すデータパイプラインを設定し、選択した前記アプリケーションに対して、前記データモデル群を参照し、前記データパイプラインにおいてデータのやりとりが可能となるように複数のリソースを選択する選択部と、前記選択されたリソースを用いたシステムを設計するためのブループリントを生成する設計部と、前記設計したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するオーケストレータ部と、を備えることを特徴とする。

【発明の効果】

【0008】

本発明によれば、複数種類のサービスを提供するシステムの設計を容易にすることができる。

【図面の簡単な説明】

【0009】

【図1】本実施形態におけるリソース管理装置の機能構成図である。

【図2】データモデルの例の説明図である。

【図3】設計処理のフローチャートである。

【図4】システム設計の具体例（１／３）である。

【図5】システム設計の具体例（２／３）である。

【図6】システム設計の具体例（３／３）である。

【図7】本実施形態における処理のプログラムを実行するコンピュータを示す図である。

【発明を実施するための形態】

【0010】

以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）について説明する。本実施形態では、トリプルマルチに対応可能なシステムの設計について説明する。マルチレイヤは、物理レイヤ、仮想レイヤ、アプリケーションレイヤから構成されているとする。物理レイヤの上に仮想レイヤが存在し、仮想レイヤの上にアプリケーションレイヤが存在する。物理レイヤ、仮想レイヤ、アプリケーションレイヤの各々には、複数種類のサービスを提供するためのリソースを配置することができる。アプリケーションレイヤに配置されるリソースを「アプリケーション」と呼ぶ場合がある。説明の便宜上、アプリケーションは、「アプリ」と略記する場合がある。また、物理レイヤに配置されるリソースを「物理リソース」と呼ぶ場合がある。仮想レイヤに配置されるリソースを「仮想リソース」と呼ぶ場合がある。物理リソースおよび仮想リソースを「インフラ」と総称する場合がある。

【0011】

［構成］
本実施形態のリソース管理装置は、複数種類のサービスを提供するためのリソースを管理する装置である。図１に示すように、本実施形態のリソース管理装置１は、取得部１１と、アプリ選択部１２と、インフラ選択部１３と、設計部１４と、オーケストレータ部１５とを備えている。また、リソース管理装置１は、カタログ群ｄ１と、データモデル群ｄ２と、ブループリント群ｄ３とを記憶する。カタログ群ｄ１、データモデル群ｄ２、および、ブループリント群ｄ３を含む各種情報は、リソース管理装置１が備える記憶部（図示略）に記憶される。

【0012】

取得部１１は、外部装置からの要求を取得する。外部装置は、例えば、サービスを利用するユーザが用いる情報端末、ネットワークを管理するオペレータが用いるコンソールなどの装置であるが、これらに限定されない。要求は、例えば、システムの設計、構築、変更を必要とするものであり、例えば、ビジネス上の要望を表現するものであるが、これに限定されない。要求の形式は、例えば、テキスト、音声、または、コマンドとすることができるが、これらに限定されない。また、外部装置は、外部情報源とすることもでき、取得部１１は、外部情報源からの外部情報を取得することができる。外部情報とは、例えば、システムをモニタリングすることによりネットワーク上に発生したアラート、ネットワーク上のシステムのログ、ＳＮＳ（Social Networking Service）に投稿された情報、天候や交通に関する情報があるがこれらに限定されない。要求および外部情報は本実施形態で行う処理のトリガとして同一視できる場合があり、本実施形態では特段の事情がない限り、要求と外部情報との区別をしない。

【0013】

アプリ選択部１２は、取得部１１が取得した要求を満たすためのアプリを選択する。アプリ選択部１２は、要求を解析し、その解析結果に基づいて、カタログ群ｄ１から所定のカタログを抽出することで、アプリを選択することができる。要求を解析する技術自体は周知であり、詳細な説明は省略する。カタログは、サービスの提供に供する工程のひな型であり、当該サービスの提供に必要な１または複数のアプリが指定されている。カタログ自体は周知であり、詳細な説明は省略する。

【0014】

また、アプリ選択部１２は、選択したアプリが利用するデータパイプラインを設定することができる。データパイプラインは、データの送信元（例えば、インフラ）からデータの送信先（例えば、インフラ）までのデータの経路である。アプリ選択部１２は、周知のパイプライン処理によってデータパイプラインを設定することができる。例えば、データパイプラインは、パイプライン処理の１つであるソフトウェアパイプラインによって、データの処理順番に所定の順序性を持たせたものとすることができるが、これに限定されない。

【0015】

インフラ選択部１３は、アプリ選択部１２が選択したアプリに対してインフラを選択する。インフラ選択部１３は、データモデル群ｄ２を参照して、特定のデータモデルにより、選択されたアプリとリレーションを持つインフラを選択することができる。データモデルの詳細は後記する。

【0016】

設計部１４は、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラを用いたシステムを設計する。具体的には、設計部１４は、ブループリントを生成する。ブループリントは、要求を満たすリソース群からなるシステムの設計情報である。ブループリント自体は周知であり、その詳細な説明は省略する。また、設計部１４は、ブループリントを生成するためのパラメータを設定することができる。パラメータは、例えば、サービスを利用するユーザの数、物理レイヤに配置される物理マシンのＩＰアドレス、仮想レイヤに配置される仮想マシンのＩＰアドレスなどがあるが、これらに限定されない。パラメータ自体は周知であり、詳細な説明は省略する。

【0017】

オーケストレータ部１５は、設計部１４が設計したシステムに対して、設計部１４が生成したブループリントに従い、オーケストレーションを実行する。オーケストレーションは、サービスの配備、設定、管理の自動制御である。オーケストレーションによって、サービスの提供が実現する。また、オーケストレータ部１５は、システムのテストを実行することができる。

【0018】

カタログ群ｄ１は、カタログの集合体である。データモデル群ｄ２は、データモデルの集合体である。ブループリント群ｄ３は、ブループリントの集合体である。設計部１４が生成したブループリントは、ブループリント群ｄ３に蓄積される。

【0019】

＜データモデルの詳細＞
本実施形態におけるデータモデルは、所定のデータをやり取りするリソース間のリレーションを明示したものである。データモデルは、リレーションと、当該リレーションを持つ２つのリソースとの組で表現される。なお、本来のデータモデルは、データまたは構造化データの構造を明示的に決めるものである。しかし、本発明では、データモデルを特異的に使用している。つまり、サービス等で提供される個々のリソースとその間のリレーションを示すものとしてデータモデルを定義し、複数のサービスを組み合わせた複雑系の設計のリファレンスとして活用できるようにしている。よって、複数のサービスの提供に必要なリソース群が特定される。

【0020】

本実施形態では、リソースは、アプリレイヤに配置されるアプリ、仮想レイヤに配置される仮想リソース、および物理レイヤに配置される物理リソースに分類される。よって、図２に示すように、データモデルとして、アプリｒ１と仮想リソースｒ２との間にリレーションが形成されたもの、仮想リソースｒ３と物理リソースｒ４との間にリレーションが形成されたものがある。これら２つのデータモデルは、隣接するレイヤ同士に配置されるリソース間にリレーションが形成された例である。また、図２に示すように、データモデルとして、仮想リソースｒ５，ｒ６との間にリレーションが形成されたもの、物理リソースｒ７，ｒ８との間にリレーションが形成されたものがある。これら２つのデータモデルは、同じレイヤに配置されるリソース間にリレーションが形成された例である。なお、データモデルとして、２つのアプリ間にリレーションが形成されたものがあってもよい。

【0021】

データモデルによって、特定された２つリソースの間で所定のデータをやり取りすることが可能になり、つまり、データフローが形成されることが規定されている。よって、アプリ選択部１２がアプリを選択した場合、インフラ選択部１３は、データモデルに従って、選択されたアプリとの間にリレーションを持つ仮想リソースを選択することができ、データのやり取りがなされる。また、インフラ選択部１３は、データモデルに従って、選択された仮想リソースとの間にリレーションを持つ物理リソースや他の仮想リソースを選択することができ、データのやり取りがなされる。また、インフラ選択部１３は、データモデルに従って、選択された物理リソースとの間にリレーションを持つ他の物理リソースや仮想リソースを選択することができ、データのやり取りがなされる。

【0022】

アプリや仮想リソースは、例えば、所定のサービスを提供するために利用されるリソースの種別の変化や、当該リソースの使い方（ユーザの利用態様）の変化などに応じて適宜バージョンアップがなされる。また、物理リソースは、例えば、適宜新しい規格へ追随した機器として提供される。具体的には、サーバによる管理からサーバを構成する処理装置やメモリによる管理への切替のような管理単位の粒度の小規模化、使い古した機器からより性能が強化された新しい機器への交換、データ構造を変更した機器への交換、などがなされる。このように、リソースは、動的に変化するものである。よって、データモデルも動的に変化する（更新する）。このような変化に伴い、データモデル群ｄ２は適宜更新される。

【0023】

なお、図２に示すように、データモデルは、２つのリソースがリレーションを持つデータモデルとして用意されるが、リレーションを持つ２つのリソースのうちの片方が共通し、もう片方が異なるデータモデルが複数存在していてもよい。この場合、データモデルにより、アプリ選択部１２が選択したアプリとリレーションを持つインフラは複数存在する場合がある。インフラ選択部１３は、所定の優先順位（例：ＳＬＡ（Service Level Agreement）、リンクコスト、その他ポリシー）を用いて１つのインフラを選択することができる。

【0024】

また、リソースの各々に対して、当該リソースを保有する所有者が存在する。リソース管理装置１は、リソースと、当該リソースの所有者とを関連付けてリソースを管理することができる。また、リソース管理装置１が管理するリソースの各々に対して、当該リソースの利用権限を有するユーザが決められている。リソース管理装置１は、リソースと、当該リソースの利用権限を有するユーザとを関連付けてリソースを管理することができる。

【0025】

また、サービスが提供されるネットワークに関しては、特定のユーザ群（例：１顧客、１企業）に提供される仮想ネットワーク単位としてテナントが用意されている。１つのテナントは、１または複数種類のサービスごとに用意することができる。よって、所定のルールに従った複数のリソースに対して１つのテナントを割り当てることができる。結果的には、リソース管理装置１は、リソースと、当該リソースが属するテナントとを関連付けてリソースを管理することができる。

【0026】

データモデルを用いることにより、インフラ選択部１３は、リソース（アプリ、インフラ）間のリレーションを参照するのみで、データのやり取り（データフロー）が可能なインフラ群を選択することができる。つまり、データフローを担当するリソースがマルチレイヤのいずれのレイヤに属しているかを問わずに、選択されたアプリに対してインフラ群を選択することができる。また、データフローを担当するリソースがマルチサービスのいずれのサービスを提供するためのリソースであるかを問わずに、選択されたアプリに対してインフラ群を選択することができる。

【0027】

また、トリプルマルチに対応可能なシステムの設計におけるドメインは、上述した、リソースの所有者およびテナントに関係している。つまり、ドメインに従って、ドメイン内のリソースの所有者が特定されたり、ドメインと同一視可能なテナントを用意したりすることができる。しかし、上述したように、データモデルを用いることで特定のアプリに対するインフラ群が選択されるので、データフローを担当するリソースがマルチドメインのいずれのドメインに属しているかを問わずに、選択されたアプリに対してインフラ群を選択することができる。

【0028】

このように、データモデルは、各ドメイン間の差異、各レイヤ間の差異、各サービス間の差異を抽象化して、汎用的なデータ構造をとることができ、要求に対して選択されるリソースを最適化する上で有用な手段である。

【0029】

［処理］
リソース管理装置１が複数種類のサービスを提供するシステムを設計するための設計処理を、図３を参照して説明する。

【0030】

まず、取得部１１が外部装置から要求を取得する（ステップＳ１）。次に、アプリ選択部１２が、取得した要求を解析し、要求を満たすためのアプリを選択する（ステップＳ２）。次に、インフラ選択部１３が、データモデルに従い、選択されたアプリとリレーションを持つインフラや、選択したインフラとリレーションを持つインフラを選択する（ステップＳ３）。次に、設計部１４が、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラに対して、パラメータを設定する（ステップＳ４）。次に、設計部１４が、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラ、および、設定したパラメータを用いて、システムを設計するためのブループリントを生成する（ステップＳ５）。最後に、オーケストレータ部１５が、システムに対して、生成されたブループリントに従い、オーケストレーションを実行する（ステップＳ６）。

【0031】

図３の設計処理によれば、設計したシステムによるサービスの提供を実現することができる。なお、オーケストレータ部１５は、設計したシステムのテストを実行してもよい。
なお、選択されたアプリやインフラ次第では、パラメータの設定なしでブループリントを生成することができる場合があり、パラメータは必須ではない。よって、ステップＳ４の処理は任意である。

【0032】

また、設計部１４は、生成されたブループリントを、ブループリント群ｄ３に蓄積することができる。また、設計部１４は、設計したシステムに用いられたアプリおよびインフラに対しては、新たなリレーションを形成することができ、新たなデータモデルを生成することができる。設計部１４は、新たに生成されたデータモデルを、データモデル群ｄ２に蓄積することができる。

【0033】

［具体例］
具体例として、「インターネット経由で入力される映像から不審者を検知したい」という要求があった場合のシステムの設計について説明する。図４に示すように、取得部１１が要求を取得した後、アプリ選択部１２は、要求を解析して、データ受信ａ１、映像解析ａ２、および、データ保存ａ３というアプリを選択することができる（図３のステップＳ２参照）。データ受信ａ１、映像解析ａ２、および、データ保存ａ３は、アプリレイヤに配置される。

【0034】

次に、図５に示すように、アプリ選択部１２は、選択したアプリ（データ受信ａ１、映像解析ａ２、および、データ保存ａ３）が利用するデータパイプライン（矢印付き太線）を設定する。データパイプラインは、アプリ選択部１２が選択したアプリに依存するため、データパイプラインの設定は、例えば、アプリ選択部１２の処理とすることができるが、これに限定されない。例えば、データパイプラインの設定は、例えば、設計部１４の処理としてもよい。なお、選択したアプリに対して複数種類のデータパイプラインが設定可能である場合、インフラ選択部１３によるインフラの選択に応じて１つのデータパイプラインを設定することができる。

【0035】

本具体例では、要求の内容に基づいて、インフラ選択部１３は、データの送信元として監視カメラｐ１を選択することができる。また、要求の内容およびアプリ選択結果に基づいて、インフラ選択部１３は、監視カメラｐ１がデータを送信するためのネットワークとしてインターネットｐ２を選択することができる。また、要求の内容およびアプリ選択結果に基づいて、インフラ選択部１３は、データの送信先としてストレージｖ１を選択することができる。監視カメラｐ１およびインターネットｐ２は、物理レイヤに配置されるリソースである。ストレージｖ１は、仮想レイヤに配置されるリソースである。アプリ選択部１２は、選択したアプリ（データ受信ａ１、映像解析ａ２、および、データ保存ａ３）を経由した、監視カメラｐ１からストレージｖ１までのデータパイプラインを設定することができる。なお、データパイプラインを設定する場合、アプリ間のベストプラクティスを保持することが好ましい。

【0036】

次に、図６に示すように、インフラ選択部１３は、インフラを選択する（図３のステップＳ３参照）。インフラ選択部１３は、データパイプラインおよびデータモデルに従い、データセンタｐ３、仮想ネットワークｖ２、ＧＷ（GateWay）ｖ３、ＶＭ（Virtual Machine）ｖ４～ｖ６を選択することができる。データセンタｐ３は、物理レイヤに配置されるリソースである。仮想ネットワークｖ２、ＧＷ（GateWay）ｖ３、ＶＭ（Virtual Machine）ｖ４～ｖ６は、仮想レイヤに配置されるリソースである。結果的に、図６に示すように、選択したインフラを経由するデータパイプラインが設定される（矢印付き太線）。

【0037】

選択したアプリ（データ受信ａ１、映像解析ａ２、および、データ保存ａ３）に所定の稼働条件が存在する場合、インフラ選択部１３は、当該稼働条件を充足することができるインフラを選択することが好ましい。「所定の稼働条件」は、例えば、インフラのリソース量が十分足りていることとすることができる（リソースチェック）が、これに限定されない。リソース量が不足するインフラが存在する場合、リソース管理装置１は、当該インフラの所有者にリソース量が不足する旨を通知することができる。データモデルによりアプリとリレーションを持つリソースは当該アプリの稼働条件を充足することができるリソースといえる。インフラを選択する場合、インフラおよびアプリからなるリソース群のベストプラクティスを保持することが好ましい。

【0038】

その後、設計部１４がパラメータの設定、ブループリントの生成をし（図３のステップＳ４～ステップＳ５参照）、オーケストレータ部１５がオーケストレーションの実行をする（図３のステップＳ６参照）。よって、選択したリソース群からなるシステムとして、監視カメラｐ１が不審者を撮影可能なシステムを設計し、要求を満たすサービスを実現することができる。

【0039】

（プログラム）
また、上記実施形態に係るリソース管理装置１の機能をプログラムにより、コンピュータに実行させることができる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、リソース管理装置１と同様の機能を実現するリソース管理プログラムを実行するコンピュータの一例を説明する。

【0040】

図７は、リソース管理プログラムを実行するコンピュータを示す図である。図７に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。

【0041】

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１およびＲＡＭ（Random Access Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。メモリ１０１０、ハードディスクドライブ１０９０、ディスクドライブ１１００、および、ディスクドライブ１１００に挿入される記憶媒体は、リソース管理装置１が備える記憶部の具体的なハードウェア資源となる。

【0042】

ここで、図７に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各テーブルは、例えばハードディスクドライブ１０９０やメモリ１０１０に記憶される。

【0043】

また、リソース管理プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、ハードディスクドライブ１０９０に記憶される。具体的には、上記実施形態で説明したリソース管理装置１が実行する各処理が記述されたプログラムモジュールが、ハードディスクドライブ１０９０に記憶される。

【0044】

また、リソース管理プログラムによる情報処理に用いられるデータは、プログラムデータとして、例えば、ハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。

【0045】

なお、リソース管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、リソース管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

【0046】

［効果］
上述してきたように、本実施形態は、マルチレイヤの各レイヤに配置されるリソース間のリレーションを明示したデータモデルに従い、データのやり取りが可能な複数のリソースを選択する選択部（アプリ選択部１２、インフラ選択部１３）と、前記選択されたリソースを用いたシステムを設計するためのブループリントを生成する設計部１４と、前記設計したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するオーケストレータ部１５と、を備えることを特徴とするリソース管理装置である。

【0047】

また、本実施形態は、リソース管理装置１が、マルチレイヤの各レイヤに配置されるリソース間のリレーションを明示したデータモデルに従い、データのやり取りが可能な複数のリソースを選択するステップと、前記選択されたリソースを用いたシステムを設計するためのブループリントを生成するステップと、前記設計したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するステップと、を実行することを特徴とするリソース管理方法である。

【0048】

これらにより、複数種類のサービスを提供するためのデータパイプラインを設定することができる。したがって、複数種類のサービスを提供するシステムの設計を容易にすることができる。

【0049】

また、前記複数のリソースは、要求を満たすためのアプリ、および、前記アプリとの間にリレーションを持つインフラを含むことを特徴とする。

【0050】

これにより、要求に応じて選択したアプリに起因するデータパイプラインを設定することができる。

【0051】

前記データモデルは、複数のサービスを組み合わせる際にリファレンスとして活用されるとともに、前記リソースの動的な変化に伴い更新されることを特徴とする。

【0052】

これにより、複数サービスを組み合わせたサービスにおいて動的に変化するシステムの設計を容易にすることができる。

【0053】

［変形例］
本実施形態で説明した各種技術を適宜組み合わせることができる。

【符号の説明】

【0054】

１ リソース管理装置
１１ 取得部
１２ アプリ選択部（選択部）
１３ インフラ選択部（選択部）
１４ 設計部
１５ オーケストレータ部
ｄ１ カタログ群
ｄ２ データモデル群
ｄ３ ブループリント群

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】