JP7405242B2 - リソース管理装置、リソース管理方法、および、リソース管理プログラム - Google Patents

Description

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

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

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

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

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

また、システムの設計の契機となる要求が抽象的である場合があり、設計したシステムが実際に最適である保証がない。また、外部環境が変化したために、最適を目指して設計したシステムが最適のままである保証がない。また、設計したシステムを運用した場合にさまざまな知見が得られ、最適化の余地が残されていることがわかる場合がある。よって、システムの設計の変更が求められるが、従来では、システムの設計変更は、多大な労力と時間を要するため容易でなかった。

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

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

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

本実施形態におけるリソース管理装置の機能構成図である。 データモデルの例の説明図である。 設計変更処理のフローチャートである。 システム設計変更の具体例（１／５）である。 システム設計変更の具体例（２／５）である。 システム設計変更の具体例（３／５）である。 システム設計変更の具体例（４／５）である。 システム設計変更の具体例（５／５）である。 本実施形態における処理のプログラムを実行するコンピュータを示す図である。

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

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

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

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

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

特に、アプリ選択部１２は、ベストプラクティスのアプリを選択することができる。アプリ選択部１２は、要求を満たすためのアプリを含むベストプラクティスをベストプラクティス群ｄ４から選択することで、アプリを選択することができる。ベストプラクティスは、所定のサービスの提供に関して所定以上の性能が発揮されるように最適化されていることが確認済みのリソース群である。ベストプラクティスの詳細は後記する。アプリ選択部１２が選択したアプリは、ベストプラクティスのアプリでもよいし、ベストプラクティスでないアプリであってもよいが、アプリ選択部１２は、ベストプラクティスのインフラを優先的に選択する。

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

特に、インフラ選択部１３は、ベストプラクティスのインフラを選択することができる。インフラ選択部１３は、ベストプラクティス群ｄ４を参照して、アプリ選択部１２が選択したアプリとデータのやり取りが可能なインフラ、または、インフラ選択部１３が選択したインフラとデータのやり取りが可能なインフラを選択することができる。インフラ選択部１３が選択したインフラは、ベストプラクティスのインフラでも良いし、ベストプラクティスでないインフラであってもよいが、インフラ選択部１３は、ベストプラクティスのインフラを優先的に選択する。

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

また、設計部１４は、判定部１６の判定結果に従い、運用中のシステムの設計を変更することができる。具体的には、アプリ選択部１２が再選択したアプリ、および、インフラ選択部１３が再選択したインフラを用いたシステムを設計する。また、設計部１４は、システムを設計変更するためのブループリントを生成する。

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

また、オーケストレータ部１５は、設計部１４が設計変更したシステムに対して、設計部１４が生成したブループリントに従い、オーケストレーションを実行することができる。また、オーケストレータ部１５は、設計変更したシステムのテストを実行することができる。

判定部１６は、外部情報に基づいて、システムの設計を変更するか否かを判定する。判定対象のシステムは、オーケストレーションおよびテストが完了し、運用を開始したシステムとすることができるが、これに限定されない。例えば、設計後運用前のシステムであってもよい。本実施形態では、判定対象のシステムを、運用を開始したシステムとして説明を続ける。

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

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

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

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

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

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

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

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

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

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

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

＜ベストプラクティスの詳細＞
先述した通り、ベストプラクティスは、所定のサービスの提供に関して所定以上の性能が発揮されるように最適化されていることが確認済みのリソース群である。所定以上の性能とは、例えば、ベストプラクティスを構成するリソース間でのデータのやり取りのスループットが所定値以上であるとすることができるが、これに限定されない。

ベストプラクティスを構成するリソース群には、異なるレイヤに配置されるリソースを含むリソース群がある。つまり、アプリと仮想リソースを含むもの、仮想リソースと物理リソースを含むもの、アプリと仮想リソースと物理リソースを含むものである。また、ベストプラクティスを構成するリソース群には、同じレイヤに配置されるリソースを含むリソース群がある。つまり、２以上のアプリを含むもの、２以上の仮想リソースを含むもの、２以上の物理リソースを含むものである。

ベストプラクティスを構成するリソース群は、データモデルによるリレーションを持つリソース群であってもよいし、データモデルによるリレーションを持たないリソース群であってもよいし、データモデルによるリレーションを持つリソース部分群とデータモデルによるリレーションを持たないリソース部分群とを合わせたリソース群であってもよい。ベストプラクティスを構成するリソース群の間のリレーションの有無に関わらず、過去の知見（実績）により、ベストプラクティスを構成するリソース間でのデータのやり取りについては、所定以上の性能が発揮されることが確認済みである。

ベストプラクティスは、所定のサービスを提供するためのシステム全体を構成するリソース群の部分集合となり得る。つまり、ベストプラクティスは、システム全体に対して部分的な（局所的な）最適解を提供することができる。よって、データフローが連続するように複数のベストプラクティスを寄せ集めることで、システム全体が最適化されるようにシステム全体を設計することができる。つまり、ベストプラクティスは、システム全体に対して部分的な最適解を提供する複数の部分的なベストプラクティスの集合であり、選択部（１２，１３）は、システム全体に対する複数の部分的なベストプラクティスのリソースを選択し、設計部１４は、選択された複数の部分的なベストプラクティスのリソースを用いてシステム全体を設計するためのブループリントを生成する。

ベストプラクティスを構成するリソースは、すでにサービスの提供のために運用済みであるため、当該リソースに対して、設計部１４が設定するパラメータが設定済みである場合がある。この場合、アプリ選択部１２またはインフラ選択部１３が当該リソースを選択した場合、設計部１４によるパラメータ設定は省略してもよい。本実施形態では省略することとして説明を続ける。ただし、設計部１４が異なるパラメータを設定し直してもよい。また、ベストプラクティスを構成するリソースにパラメータが設定されていない場合、設計部１４が当該リソースにパラメータを設定することができる。

＜システムの設計変更の詳細＞
例えば、判定部１６は、取得部１１が取得した外部情報を解析して、１または複数の設計変更案を導出することができる。例えば、システムのモニタリングにより、規定範囲を超える異常値が検出された場合に、判定部１６は設計変更案を導出することができるが、この場合に限定されない。判定部１６は、例えば、ベストプラクティス群ｄ４に蓄積されているベストプラクティスを参照して、設計変更案を導出することができる。つまり、過去の実績に照らし合わせて設計変更案が導出されるため、設計変更案の信頼性を向上させることができる。

また、判定部１６は、例えば、システムの性能値を指標とした周知のスコアリングによって、導出した設計変更案を評価することができる。その結果、判定部１６は、スコアが最大の設計変更案を決定することができる。判定部１６は、決定した設計変更案を、システムの設計を変更するための要求とすることができる。

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

＜設計処理＞
前段階として、リソース管理装置１は、設計変更前のシステムに対して、設計処理を実行済みである。設計処理は、以下の手順で実行される。すなわち、まず、取得部１１が外部装置から要求を取得する。次に、アプリ選択部１２が、取得した要求を解析し、要求を満たすためのアプリを選択する。次に、インフラ選択部１３が、データモデルに従い、選択されたアプリとリレーションを持つインフラや、選択したインフラとリレーションを持つインフラを選択する。次に、設計部１４が、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラに対して、パラメータを設定する。次に、設計部１４が、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラ、および、設定したパラメータを用いて、システムを設計するためのブループリントを生成する。最後に、オーケストレータ部１５が、システムに対して、生成されたブループリントに従い、オーケストレーションを実行する。

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

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

＜設計変更処理＞
リソース管理装置１は、上記設計処理によってオーケストレーションおよびテストが完了し、運用を開始したシステムに対して図３の設計変更処理を実行する。まず、取得部１１が外部装置から外部情報を取得する（ステップＳ１）。次に、判定部１６が、外部情報を解析して、１または複数の設計変更案を導出する（ステップＳ２）。次に、判定部１６が、外部情報に基づいて、システムを設計変更するか否かを判定する（ステップＳ３）。具体的には、判定部１６は、導出した設計変更案のうち最大のスコアとなる設計変更案を採用するか否か判定する。例えば、最大のスコアが所定値以上であれば採用するとしてもよいが、これに限定されない。

設計変更しない場合（ステップＳ３でＮｏ）、設計変更処理を終了する。一方、設計変更する場合（ステップＳ３でＹｅｓ）、アプリ選択部１２が、採用した設計変更案が示す要求を解析し、要求を満たすためのアプリを選択する（ステップＳ４）。次に、インフラ選択部１３が、データモデルに従い、選択されたアプリとリレーションを持つインフラや、選択したインフラとリレーションを持つインフラを選択する（ステップＳ５）。次に、設計部１４が、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラに対して、パラメータを設定する（ステップＳ６）。次に、設計部１４が、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラ、および、設定したパラメータを用いて、システムを設計変更するためのブループリントを生成する（ステップＳ７）。最後に、オーケストレータ部１５が、設計変更したシステムに対して、生成されたブループリントに従い、オーケストレーションを実行する（ステップＳ８）。以上で、設計変更処理を終了する。

図３の設計変更処理によれば、設計変更したシステムによるサービスの提供を実現することができる。なお、オーケストレータ部１５は、設計変更したシステムのテストを実行してもよい。
なお、選択されたアプリやインフラ次第では、パラメータの設定なしでブループリントを生成することができる場合があり、パラメータは必須ではない。よって、パラメータの設定は任意である。また、設計処理において、ベストプラクティス群ｄ４を参照して、アプリおよびインフラを選択してもよい。
また、決定した設計変更案に応じて、アプリ選択部１２によるアプリの選択（ステップＳ４）およびインフラ選択部１３によるインフラの選択（ステップＳ５）の順序は適宜変更することができる。つまり、アプリの選択の前に特定のインフラが選択される場合があってもよい。

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

図３の設計変更処理は繰り返し実行可能である。つまり、外部情報の収集を継続することにより、システムの設計変更は、人手を介さずに自動的に行うことができる。その結果、最適なシステムに収束するように自己進化させることができる。

［具体例］
具体例として、「インターネット経由で入力される映像から不審者を検知したい」という要求に対して設計されたシステムの設計変更について説明する。運用を開始したシステムを構成するリソース群は、図４に示す通りであったとする。図４に示すように、データ受信ａ１、映像解析ａ２、および、データ保存ａ３がアプリレイヤに配置されている。また、ストレージｖ１、仮想ネットワークｖ２、ＧＷ（GateWay）ｖ３、および、ＶＭ（Virtual Machine）ｖ４～ｖ６が仮想レイヤに配置されている。また、監視カメラｐ１、インターネットｐ２、および、データセンタ（ＤＣ）ｐ３が物理レイヤに配置されている。

また、図４に示すように、監視カメラｐ１をデータの送信元としストレージｖ１をデータの送信先とするデータパイプラインが設定されている（矢印付き太線）。データパイプラインは、アプリ選択部１２が選択したアプリに依存するため、データパイプラインの設定は、例えば、アプリ選択部１２の処理とすることができるが、これに限定されない。例えば、データパイプラインの設定は、例えば、設計部１４の処理としてもよい。なお、選択したアプリに対して複数種類のデータパイプラインが設定可能である場合、インフラ選択部１３によるインフラの選択に応じて１つのデータパイプラインを設定することができる。データパイプラインを設定する場合、アプリ間のベストプラクティスを保持することが好ましい。図４のシステムは、監視カメラｐ１が不審者を撮影可能なシステムを設計し、要求を満たすサービスを実現することができる。

運用を開始したシステムは、モニタリングすることで様々な状況を確認することができる。例えば、性能面の状況としては、処理が遅い、アプリの動作要件を満たさない、オーバースペックなどがある。また、例えば、コスト面の状況としては、高い、想定外の費用が発生しているなどがある。また、例えば、利用傾向面の状況としては、サービスの利用率が低い、データソースに偏りがある、サービスの利用時間帯に偏りがあるなどがある。また、例えば、不具合と判定される状況として、システムにつながらない、システムが落ちるなどがある。

なお、システムのモニタリングは、リソース管理装置１が行うことができる。しかし、複数種類のサービスが提供されるシステムが大規模であることに鑑みて、システムのモニタリングは、リソース管理装置１とは異なる複数の監視装置（計算機）が行うようにすることが好ましい。この場合、複数の監視装置のモニタリングの結果をリソース管理装置１に集約させることができる。複数の監視装置の各々は、例えば、サービスごと、エリアごと、テナントごとに用意することができるが、これらに限定されない。

運用を開始したシステムのモニタリングにより、例えば、以下の状況Ａ～Ｄが確認されたとする。

状況Ａ（性能面）：映像解析のアプリの動作要件を満たしていない（レイテンシ高）。
状況Ｂ（性能面）：ＧＷのトラヒック量が多い（リソース使用量高）。
状況Ｃ（コスト面）：クラウドサービス用のＤＣのＧＷにかかるコストが莫大。
状況Ｄ（利用傾向面）：データソースが特定のエリアに偏っている。

取得部１１は、上記状況Ａ～Ｄを外部情報として取得することができる。判定部１６は、状況Ａ～Ｄを解析して、以下の設計変更案：オプション（１）～（３）を導出したとする。

オプション（１）：ＧＷのリソースを拡張する。
オプション（２）：映像のビットレートを落とす。
オプション（３）：映像解析のアプリをデータソース近くに移動する。
なお、状況からオプションを導出する方法は以下の通りである。つまり、リソース管理装置１は、状況に対する対応（オプション）をルールとして予め保持している。また、リソース管理装置１は、保持するルールに対してスコアを付しておく。状況が確認された場合、リソース管理装置１は、確認された状況に対応するルールを抽出する。また、リソース管理装置１は、抽出したルールに付したスコアに基づいて最終的にどのルールを選択するかを決定する。ただし、上記方法は一例であり、状況からオプションを導出する方法はこれに限定されない。例えば、専用のＡＩモデルを導入してもよい。

判定部１６は、オプション（１）～（３）を評価する。その結果、オプション（１）は、ＧＷのコストが増大することになり、状況Ｃに対してマイナス評価となってしまい、スコアは低い。また、オプション（２）は、映像解析のアプリの動作要件を満たすことができず、状況Ａに対して極めてマイナス評価となってしまい、スコアは極めて低い。一方、オプション（３）は、状況Ａ～Ｄのすべてを改善することができプラス評価となり、スコアは高い。以上から、判定部１６は、オプション（３）を採用し、オプション（３）を要求としてシステムの設計を変更する。なお、複数のオプションを評価して１つのオプションを採用する方法は、上記に限られず、例えば、所定のアルゴリズムを用いて実現することができる。

まず、図５に示すように、インフラ選択部１３は、データソース：エリアｅ１の物理レイヤに配置される物理リソースとしてエッジｐ４を選択する。インフラ選択部１３は、物理リソースの選択の際、当該物理リソースの利用状況、利用範囲、用途、利用権限などを考慮する。エッジｐ４は、例えば、多目的・多用途の共用エッジであり、使用時にプロビジョニングし、使用後に解放される。

次に、図６に示すように、アプリ選択部１２は、エリアｅ１に用いるアプリを選択する（図３のステップＳ４参照）。具体的には、アプリ選択部１２は、データセンタｐ３のドメインに配置されていた映像解析ａ２を、エリアｅ１のエッジｐ４のドメインのアプリレイヤに移動する。また、アプリ選択部１２は、エッジｐ４のドメインのアプリレイヤにデータ入力ａ４およびデータ送信ａ５を新たに配置する。本具体例では、監視カメラｐ１を用いるサービスを提供する環境がシングルドメインから分散環境に切り替わるため、切り替え前後でアプリの構成パターンが保持されるようにアプリの選択がなされることが好ましい。データ入力ａ４およびデータ送信ａ５は、データ送受信の仕様に関して、データ受信ａ１およびデータ保存ａ３と概ね共通する。

次に、図７に示すように、アプリ選択部１２は、選択したアプリ（データ入力ａ４、映像解析ａ２、データ送信ａ５、データ受信ａ１、および、データ保存ａ３）が利用するデータパイプライン（矢印付き太線）を設定する。アプリ選択部１２は、選択したアプリ（データ入力ａ４、映像解析ａ２、データ送信ａ５、データ受信ａ１、および、データ保存ａ３）を経由した、監視カメラｐ１からストレージｖ１までのデータパイプラインを設定することができる。なお、データパイプラインを設定する場合、アプリ間のベストプラクティスを保持することが好ましい。

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

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

その後、設計部１４がパラメータの設定、ブループリントの生成をし（図３のステップＳ６～ステップＳ７参照）、オーケストレータ部１５がオーケストレーションの実行をする（図３のステップＳ８参照）。よって、監視カメラｐ１が不審者を撮影可能なシステムを設計変更し、モニタリングにより確認された状況Ａ～Ｄをすべて解消することができる。

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

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

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

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

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

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

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

［効果］
上述してきたように、本実施形態は、外部情報に基づいて、サービスを提供するシステムの設計を変更するか否かを判定する判定部１６と、変更する場合、データモデルに従い、データのやり取りが可能な複数のリソースを選択する選択部（アプリ選択部１２、インフラ選択部１３）と、前記選択されたリソースを用いて、前記システムの設計を変更するためのブループリントを生成する設計部１４と、前記設計を変更したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するオーケストレータ部１５と、を備えることを特徴とするリソース管理装置１である。

また、本実施形態は、リソース管理装置１が、外部情報に基づいて、サービスを提供するシステムの設計を変更するか否かを判定するステップと、変更する場合、データモデルに従い、データのやり取りが可能な複数のリソースを選択するステップと、前記選択されたリソースを用いて、前記システムの設計を変更するためのブループリントを生成するステップと、前記設計を変更したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するステップと、を実行することを特徴とするリソース管理方法である。

これらにより、複数種類のサービスを提供するためのデータパイプラインを再設定することができる。したがって、複数種類のサービスを提供するシステムの設計変更を容易にすることができる。また、外部情報の収集を継続することにより、システムの設計変更は、人手を介さずに自動的に行うことができる。その結果、最適なシステムに収束するように自己進化させることができる。

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

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

また、前記リソースは、ベストプラクティスのリソースを含むことを特徴とする。

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

また、判定部１６は、前記システムのモニタリングにより取得された前記外部情報を解析して１または複数の設計変更案を導出し、所定のアルゴリズムを用いて、前記導出した設計変更案の１つを採用することを特徴とする。

これにより、システムのモニタリングを継続することにより、システムの設計変更は、人手を介さずに自動的に行うことができる。その結果、最適なシステムに収束するように自己進化させることができる。

［変形例］
（ａ）：要求と、要求を満たすために選択されたベストプラクティスと、ベストプラクティスからなるシステムの性能値（例：スループット）の組み合わせを機械学習させたＡＩモデルを構築することができる。未知の要求を当該ＡＩモデルに入力することで、システムの性能値が所望の値となるベストプラクティスを出力として得ることができる。また、出力したベストプラクティスに対して、要求と、当該ベストプラクティスと、当該ベストプラクティスからなるシステムの性能値の組み合わせを前記ＡＩモデルに機械学習させることができ、本実施形態の設計変更処理に応用することができる。

（ｂ）：判定部１６は、複数の設計変更案（オプション）を導出した場合、導出した設計変更案の２つ以上の組み合わせを１つの新たな設計変更案とすることができる。当該新たな設計変更案のスコアが最大であった場合、判定部１６が当該新たな設計変更案を採用し、リソース管理装置１による設計変更処理を実現することができる。

（ｃ）：本発明のシステムの設計変更は、リソースの追加、削除を伴わない設計変更、つまり、システムを構成するリソース群が同じままの設計変更を含む。このような設計変更は、例えば、先述した外部情報ではなく、システムの内部情報に基づいて実行することができるが、これに限定されない。例えば、監視カメラで不審者を監視するスマートシティにおいて、不審者が検知された際、自律的に監視カメラ（インフラ）の映像の符号化レートを高めたり、自律的にネットワークの帯域を増大させたりすることで、自律的に監視カメラの映像を高精細にすることができる。
（ｄ）：本実施形態で説明した各種技術を適宜組み合わせることができる。

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

Claims (7)

1. サービス提供するためのリソースを管理するリソース管理装置であって、
   前記リソース管理装置は、
   アプリケーションレイヤに配置されるリソースとしての複数のアプリケーション、仮想レイヤに配置されるリソースとしての複数の仮想リソース、物理レイヤに配置されるリソースとしての複数の物理リソース、のいずれかのリソースのうち、リレーションをもつ２つのリソースの組を示すデータモデルの集合であるデータモデル群を記憶しており、
   外部情報に基づいて、サービスを提供するシステムの設計を変更するか否かを判定する判定部と、
   変更する場合、サービスの提供に必要なアプリケーションを選択し、選択したアプリケーションが利用するデータの送信元のリソースから送信先のリソースまでの経路を示すデータパイプラインを設定し、
   選択した前記アプリケーションに対して、前記データモデル群を参照し、前記データパイプラインにおいてデータのやりとりが可能となるように複数のリソースを選択する選択部と、
   前記選択されたリソースを用いて、前記システムの設計を変更するためのブループリントを生成する設計部と、
   前記設計を変更したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するオーケストレータ部と、を備えることを特徴とするリソース管理装置。
2. 前記リソースは、ベストプラクティスのリソースを含むことを特徴とする請求項１に記載のリソース管理装置。
3. 前記判定部は、前記システムのモニタリングにより取得された前記外部情報を解析して１または複数の設計変更案を導出し、所定のアルゴリズムを用いて、前記導出した設計変更案の１つを採用することを特徴とする請求項１または請求項２に記載のリソース管理装置。
4. サービス提供するためのリソースを管理するリソース管理装置が、
   アプリケーションレイヤに配置されるリソースとしての複数のアプリケーション、仮想レイヤに配置されるリソースとしての複数の仮想リソース、物理レイヤに配置されるリソースとしての複数の物理リソース、のいずれかのリソースのうち、リレーションをもつ２つのリソースの組を示すデータモデルの集合であるデータモデル群を記憶しており、
   外部情報に基づいて、サービスを提供するシステムの設計を変更するか否かを判定するステップと、
   変更する場合、サービスの提供に必要なアプリケーションを選択し、選択したアプリケーションが利用するデータの送信元のリソースから送信先のリソースまでの経路を示すデータパイプラインを設定するステップと、
   選択した前記アプリケーションに対して、前記データモデル群を参照し、前記データパイプラインにおいてデータのやりとりが可能となるように複数のリソースを選択するステップと、
   前記選択されたリソースを用いて、前記システムの設計を変更するためのブループリントを生成するステップと、
   前記設計を変更したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するステップと、を実行することを特徴とするリソース管理方法。
5. 前記リソースは、ベストプラクティスのリソースを含むことを特徴とする請求項４に記載のリソース管理方法。
6. 前記リソース管理装置が、
   前記判定するステップにおいて、前記システムのモニタリングにより取得された前記外部情報を解析して１または複数の設計変更案を導出し、所定のアルゴリズムを用いて、導出した設計変更案の１つを採用することを特徴とする請求項４または請求項５に記載のリソース管理方法。
7. コンピュータに、請求項４から請求項６の何れか１項に記載のリソース管理方法を実行させるためのリソース管理プログラム。

Images