特許 6984576 リソース決定装置、方法及びプログラム

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

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

(11)【特許番号】6984576

(24)【登録日】2021年11月29日

(45)【発行日】2021年12月22日

(54)【発明の名称】リソース決定装置、方法及びプログラム

(51)【国際特許分類】

   H04L 12/917 20130101AFI20211213BHJP

   H04L 12/813 20130101ALI20211213BHJP

   H04L 12/70 20130101ALI20211213BHJP

【ＦＩ】

   H04L12/917

   H04L12/813

   H04L12/70 D

【請求項の数】5

【全頁数】19

(21)【出願番号】特願2018-203673(P2018-203673)

(22)【出願日】2018年10月30日

(65)【公開番号】特開2020-72327(P2020-72327A)

(43)【公開日】2020年5月7日

【審査請求日】2021年1月27日

(73)【特許権者】

【識別番号】000004226

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

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100179062

【弁理士】

【氏名又は名称】井上 正

(72)【発明者】

【氏名】呉 超

(72)【発明者】

【氏名】堀内 信吾

【審査官】 宮島 郁美

(56)【参考文献】

【文献】 特開２０１４−９０５０１（ＪＰ，Ａ）

【文献】 特開２０１７−１１４６５（ＪＰ，Ａ）

【文献】 国際公開第２０１８／０１６０４３（ＷＯ，Ａ１）

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

Ｈ０４Ｌ１２／００−１２／２６，１２／５０−１２／９５５

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

【請求項1】

仮想マシンの処理負荷、前記仮想マシンの処理性能、前記仮想マシンが収容される物理マシンのリソースの運用状態、及び前記仮想マシンのリソースの運用状態と、前記仮想マシンに配置されるリソース量との関係を示すモデルを格納する格納部と、
前記仮想マシンが収容される物理マシンのリソースの運用状態の監視結果、前記仮想マシンの処理負荷、及び前記格納部に格納されるモデルに基づいて、前記仮想マシンの処理性能の要件及び前記仮想マシンのリソースの運用状態のポリシをそれぞれ満たす、前記仮想マシンに配置されるリソース量を算出する算出手段と、
を備えたリソース決定装置。

【請求項2】

前記算出手段は、
前記仮想マシンの処理負荷、前記仮想マシンの処理性能の要件、前記仮想マシンのリソースの運用状態のポリシ、及び前記仮想マシンが収容される物理マシンのリソースの運用状態の監視結果のうち少なくとも１つが変動したときに、前記仮想マシンの処理性能の要件及び前記仮想マシンのリソースの運用状態のポリシをそれぞれ満たす、前記仮想マシンに配置されるリソース量を再度算出する、
請求項１に記載のリソース決定装置。

【請求項3】

前記算出手段による算出結果に基づいて、前記仮想マシンにリソースを実装する実装手段と、
前記実装手段によりリソースが実装された前記仮想マシンが収容される前記物理マシンのリソースの運用状態、前記実装手段によりリソースが実装された仮想マシンのリソースの運用状態、前記実装手段によりリソースが実装された仮想マシンの処理負荷、前記実装手段によりリソースが実装された仮想マシンの処理性能をそれぞれ監視し、前記監視結果として出力する監視手段と、
をさらに備え、
前記モデルは、前記監視手段による監視結果に基づいて学習され、
前記算出手段は、
前記実装手段によりリソースが実装された仮想マシンの処理負荷、前記実装手段によりリソースが実装された仮想マシンが収容される物理マシンのリソースの運用状態の監視結果、及び前記格納部に格納されるモデルに基づいて、前記仮想マシンの処理性能の要件及び前記仮想マシンのリソースの運用状態のポリシをそれぞれ満たす、前記仮想マシンに配置されるリソース量を算出する、
請求項１に記載のリソース決定装置。

【請求項4】

リソース決定装置が行うリソース決定方法であって、
仮想マシンの処理負荷、前記仮想マシンの処理性能、前記仮想マシンが収容される物理マシンのリソースの運用状態、及び前記仮想マシンのリソースの運用状態と、前記仮想マシンに配置されるリソース量との関係を示すモデルを格納部から取得し、前記取得されたモデルと、前記仮想マシンが収容される物理マシンのリソースの運用状態の監視結果と、前記仮想マシンの処理負荷とに基づいて、前記仮想マシンの処理性能の要件及び前記仮想マシンのリソースの運用状態のポリシをそれぞれ満たす、前記仮想マシンに配置されるリソース量を算出する、リソース決定方法。

【請求項5】

請求項１乃至３のいずれか１項に記載のリソース決定装置の前記各手段としてプロセッサを機能させるリソース決定処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、リソース決定装置、方法及びプログラムに関する。

【背景技術】

【0002】

様々な法人ユーザ（以下、ユーザ）が、クラウド提供者が提供するクラウドサービス（以下、サービスと称することがある）を利用し、自組織内あるいはエンドユーザにサービスを提供する形態が今後増えると考えられる。そこで、クラウド提供者に対しては、ユーザが求めるサービスを迅速かつ低コストに正確に提供することが求められる。クラウド提供者は、仮想化技術を用いてサービスをユーザに提供している。

【0003】

この仮想化技術は、汎用サーバ上で仮想マシンであるVM(Virtual Machine)を生成し、VMに様々な機能（例えば、Firewall(FW)機能、Web Server(WS)機能、Deep Packet Inspection(DPI)、Database(DB)機能等）を実装できる。さらに、仮想化技術は、各VMに割り当てられるリソース量（例えばvCPU(virtual Central Processing Unit)数、メモリ量）を自由に変更することによって、機能の処理能力を自由に変更できる。クラウド提供者は、上記の機能を組み合わせて、ユーザにサービスを提供する（例えば、非特許文献１、２を参照）。

【先行技術文献】

【非特許文献】

【0004】

【非特許文献1】A. Iosup, N. Yigitbasi, and D. Epema, “On the PerformanceVariability of Production Cloud Services,” IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing, 2011

【非特許文献2】G.Kousiouriset al, "Translation of application-level terms to resource level attributes across the Cloud stack layers," IEEE Symposium on Computers and Communications, pp. 153-160, 2011

【発明の概要】

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

【0005】

現在、クラウドサービスの一般的な提供形態としては、リソース量単位（例えばvCPUの数、メモリの量)でサービスを提供する。しかし、非特許文献１では、リソース量を保障した条件で、サービスのパフォーマンスを保障することができない。現状としては、サービスのパフォーマンスを保障するために、次の課題（１）、（２）が存在する。

【0006】

（１）サービス開通する際に、ユーザが求めるサービスのパフォーマンス要件を満たすため、ワークロード、環境条件、及び運用ポリシを考慮して、VMに配置される必要なリソース量に関する決定
（２）サービスを運用する際に、ユーザが求めるサービスのパフォーマンス要件を満たし続けるため、ワークロード、環境条件、及び運用ポリシの少なくとも１つが変動する際の、VMに配置されるリソース量の調整に関する決定
上記の（１）、（２）の決定のためには高いスキルが必要になり、クラウド提供者または法人ユーザの有スキル者に依存するため、人的コストの高さが問題になっている。
そのため、非特許文献２では、パフォーマンス要件を保障するためにリソース量を決定する方法を提案している。しかしながら、実運用でリソース量の決定に影響を与える要素としての環境条件および運用ポリシは考慮されていなかった。

【0007】

パフォーマンス要件は、主にワークロード処理能力要件と遅延要件でなる２つの分類がある。
ワークロード処理能力は、サービス処理能力への、ユーザからの要求を表す。
例えば、クラウドベースのweb service、 firewall、 DPIサービス等のワークロード処理能力要件は、95[%]以上のリクエストを処理する、90[%]以上のユーザを収容できる、等が挙げられる。

【0008】

また、遅延要件は、サービスの処理時間への、ユーザからの要求を表す。
例えば、クラウドベースのweb service、 firewall、 DPIサービス等の遅延要件は、リクエストの処理時間の90[%]を100[ms]以下にする、等が挙げられる。
また、例えば、クラウドベースの機械学習訓練サービス等のワークロード処理能力要件は、１batchの訓練データを130[ms]内に処理する、等が挙げられる。

【0009】

この例では、上記のワークロードは、ユーザがクラウドを使って収容・処理しようとしているワークロードの種類、ワークロードの特徴、及びワークロードの量を総称したものである。
例えば、ワークロードの種類をweb serviceと定義し、ワークロードの特徴をweb pageのサイズ20[KB]等と定義し、ワークロードの量を１秒で10000リクエスト（以下、10000 [requests per second]と記述する）と定義する、等が挙げられる。

【0010】

また、別の例として、ワークロードの種類を機械学習訓練と定義し、特徴を学習アルゴリズムの構成と定義し、ワークロードの量を１batchの訓練データのサイズ（例えば30枚の32*32[pixel]、256色の画像)と定義する、等が挙げられる。

【0011】

上記の環境条件は、サービスを構成するVMが収容される物理サーバ（ホスト）の状態である。
動的な環境条件の例として、物理サーバのリソースの利用率（ここではホストの混雑度とも呼ぶ）が挙げられる。また、静的な環境条件の例として、物理サーバのCPUの種類、メモリのアーキテクチャ等が挙げられる。

【0012】

上記の運用ポリシは、ユーザあるいはクラウド提供者が定めたポリシであって、クラウドサービスが運用される際に従われるポリシである。運用ポリシを定めることで、クラウドサービスの運用状態を望ましい状態に維持することができる。例えば、VM内のリソース利用率制限に関する運用ポリシを定めることで、VMのリソース利用率の向上、ボトルネック発生可能性の低減、等の効果が期待できる。

【0013】

この発明は、上記事情に着目してなされたもので、その目的とするところは、仮想マシンに必要なリソース量を適切に求めることができるようにしたリソース決定装置、方法及びプログラムを提供することにある。

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

【0014】

上記目的を達成するために、この発明の一実施形態に係るリソース決定装置の第１の態様は、リソース決定装置が、仮想マシンの処理負荷、前記仮想マシンの処理性能、前記仮想マシンが収容される物理マシンのリソースの運用状態、及び前記仮想マシンのリソースの運用状態と、前記仮想マシンに配置されるリソース量との関係を示すモデルを格納する格納部と、前記仮想マシンが収容される物理マシンのリソースの運用状態の監視結果、前記仮想マシンの処理負荷、及び前記格納部に格納されるモデルに基づいて、前記仮想マシンの処理性能の要件及び前記仮想マシンのリソースの運用状態のポリシをそれぞれ満たす、前記仮想マシンに配置されるリソース量を算出する算出手段とを備えるようにしたものである。

【0015】

この発明のリソース決定装置の第２の態様は、第１の態様において、前記算出手段は、前記仮想マシンの処理負荷、前記仮想マシンの処理性能の要件、前記仮想マシンのリソースの運用状態のポリシ、及び前記仮想マシンが収容される物理マシンのリソースの運用状態の監視結果のうち少なくとも１つが変動したときに、前記仮想マシンの処理性能の要件及び前記仮想マシンのリソースの運用状態のポリシをそれぞれ満たす、前記仮想マシンに配置されるリソース量を再度算出するようにしたものである。

【0016】

この発明のリソース決定装置の第３の態様は、第１の態様において、前記算出手段による算出結果に基づいて、前記仮想マシンにリソースを実装する実装手段と、前記実装手段によりリソースが実装された前記仮想マシンが収容される前記物理マシンのリソースの運用状態、前記実装手段によりリソースが実装された仮想マシンのリソースの運用状態、前記実装手段によりリソースが実装された仮想マシンの処理負荷、前記実装手段によりリソースが実装された仮想マシンの処理性能をそれぞれ監視し、前記監視結果として出力する監視手段と、をさらに備え、前記モデルは、前記監視手段による監視結果に基づいて学習され、前記算出手段は、前記実装手段によりリソースが実装された仮想マシンの処理負荷、前記実装手段によりリソースが実装された仮想マシンが収容される物理マシンのリソースの運用状態の監視結果、及び前記格納部に格納されるモデルに基づいて、前記仮想マシンの処理性能の要件及び前記仮想マシンのリソースの運用状態のポリシをそれぞれ満たす、前記仮想マシンに配置されるリソース量を算出するようにしたものである。

【0017】

本発明の一実施形態に係る、リソース決定装置が行うリソース決定方法の一つの態様は、仮想マシンの処理負荷、前記仮想マシンの処理性能、前記仮想マシンが収容される物理マシンのリソースの運用状態、及び前記仮想マシンのリソースの運用状態と、前記仮想マシンに配置されるリソース量との関係を示すモデルを格納部から取得し、前記取得されたモデルと、前記仮想マシンが収容される物理マシンのリソースの運用状態の監視結果と、前記仮想マシンの処理負荷とに基づいて、前記仮想マシンの処理性能の要件及び前記仮想マシンのリソースの運用状態のポリシをそれぞれ満たす、前記仮想マシンに配置されるリソース量を算出するようにしたものである。

【0018】

本発明の一実施形態に係るリソース決定処理プログラムの一つの態様は、第１乃至第３の態様のいずれか１つにおけるリソース決定装置の前記各手段としてプロセッサを機能させるものである。

【発明の効果】

【0019】

この発明の一実施形態に係るリソース決定装置の第１の態様によれば、仮想マシンが収容される物理マシンのリソースの運用状態の監視結果、仮想マシンの処理負荷に基づいて、仮想マシンの処理性能の要件及び仮想マシンのリソースの運用状態のポリシをそれぞれ満たす、仮想マシンに配置されるリソース量が算出されるので、仮想マシンに必要なリソース量を適切に求め、リソース決定にかかる人的コストを低減することができる。

【0020】

この発明の一実施形態に係るリソース決定装置の第２の態様によれば、仮想マシンの処理負荷、仮想マシンの処理性能の要件、仮想マシンのリソースの運用状態のポリシ、及び仮想マシンが収容される物理マシンのリソースの運用状態の監視結果のうち少なくとも１つが変動したときに、仮想マシンの処理性能の要件及び仮想マシンのリソースの運用状態のポリシをそれぞれ満たす、仮想マシンに配置されるリソース量が再度算出されるので、リソース量を適切に調整できる。

【0021】

この発明の一実施形態に係るリソース決定装置の第３の態様によれば、リソースが実装された仮想マシンが収容される物理マシンのリソースの運用状態、リソースが実装された仮想マシンのリソースの運用状態、リソースが実装された仮想マシンの処理負荷、リソースが実装された仮想マシンの処理性能がそれぞれ監視されて、その結果が出力され、この監視結果に基づいて必要に応じて前記モデルが再学習される。監視データの蓄積量に伴い、モデルを用いたリソース量の算出精度を向上することが可能である。また、監視結果に応じて、仮想マシンに配置されるリソース量が算出されるので、ユーザが設定してなくても、自主的にリソース量を適切に求めることができ、仮想マーションの処理性能を維持することができる。

【0022】

すなわち、本発明によれば、仮想マシンに必要なリソース量を適切に求めることが可能になる。

【図面の簡単な説明】

【0023】

【図1】本発明の一実施形態に係るリソース決定装置の適用例を示す図。

【図2】本発明の一実施形態に係るリソース決定装置の実装方式の一例を示す図。

【図3】本発明の一実施形態に係るリソース決定装置が入力する環境条件の影響の一例を示す図。

【図4】本発明の一実施形態に係るリソース決定装置が入力する運用ポリシに制限を設けない場合に発生しやすい運用問題の一例を示す図。

【図5】本発明の一実施形態に係るリソース決定装置が出力する監視データの一例を表形式で示す図。

【図6】本発明の一実施形態に係るリソース決定装置に適用されるモデルの一例を示す図。

【図7】本発明の一実施形態に係るリソース決定装置のリソース量算出部のロジックの一例を示す図。

【図8】本発明の一実施形態に係るリソース決定装置に適用されるニューラルネットワークモデル・学習手法における第１のモデルの一例を示す図。

【図9】本発明の一実施形態に係るリソース決定装置に適用されるニューラルネットワークモデル・学習手法における第２のモデルの一例を示す図。

【図10】本発明の一実施形態に係るリソース決定装置のリソース量算出部のロジックの一例を示す図。

【図11】本発明の一実施形態に係るリソース決定装置によるサービス開通、スケーリングの支援の流れの一例を示す図。

【図12】本発明の一実施形態に係るリソース決定装置によるサービス開通する際における、VMに配置されるリソース量の算出の具体例を示す図。

【図13】本発明の一実施形態に係るリソース決定装置によるサービス開通後のスケーリングにおける、VMに配置されるリソース量の調整の具体例を示す図。

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

【0024】

以下、図面を参照しながら、この発明に係わる一実施形態を説明する。
本実施形態に係るリソース決定装置は、有スキル者に依存せずに、サービス開通する際にユーザが求めるサービスのパフォーマンス要件を満たすために、ワークロード、環境条件、運用ポリシに応じて、仮想マシン(VM)に配置される必要なリソース量を自動的に決定する。ワークロードは仮想マシンの処理負荷に対応し、パフォーマンス要件は仮想マシンの処理性能要件に対応し、環境条件は、仮想マシンが収容される物理マシンのリソースの運用状態に対応し、運用ポリシは、仮想マシンのリソースの運用状態のポリシに対応する。
また、本実施形態に係るリソース決定装置は、サービスを運用する際に、ユーザが求めるサービスのパフォーマンス要件を満たし続けるために、パフォーマンス要件、ワークロード、環境条件、運用ポリシの少なくとも１つが変動する際に、VMに配置されるリソース量を自動的に調整する。

【0025】

故に、クラウドサービスのパフォーマンス要件を保障し、パフォーマンス単位でクラウドサービスの契約を可能にし、クラウドサービスを提供するための人的なコストを削減する、等の効果が期待できる。

【0026】

図１は、本発明の一実施形態に係るリソース決定装置の適用例を示す図である。
図１に示すように、本発明の一実施形態に係るリソース決定装置１０は、モデル管理・保存部１１、リソース量算出部１２、VM実装・スケーリング制御部１３、監視・データ収集部１４を備える。VM実装・スケーリング制御部１３と監視・データ収集部１４とをあわせて実装・監視部と称することもできる。

【0027】

また、リソース決定装置１０は、パーソナルコンピュータ（ＰＣ）などのコンピュータデバイスを用いたシステムにより実現可能である。例えば、コンピュータデバイスは、ＣＰＵなどのプロセッサと、プロセッサに接続されるメモリと、入出力インタフェースとを備える。このうちメモリは、不揮発性メモリなどの記憶媒体を有する記憶装置により構成される。

【0028】

リソース決定装置１０のリソース量算出部１２、VM実装・スケーリング制御部１３、監視・データ収集部１４の機能は、例えば、プロセッサがメモリに格納されているプログラムを読み出して実行することにより実現される。なお、これらの機能の一部又は全部は、特定用途向け集積回路（ＡＳＩＣ）などの回路によって実現されてもよい。
モデル管理・保存部１１は、上記メモリのうち随時書込及び読み出しが可能な不揮発性メモリに設けられる。

【0029】

モデル管理・保存部１１は、VMのパフォーマンス、VMのワークロード、VMのリソースの運用状態、環境条件とリソース量との関係性（相互影響度合）を表すフィッティング・学習モデル（以下、後述するフィッティングモデル又は学習モデル）を記憶する。このフィッティング・学習モデルは初期モデルに対し、過去監視データを用いて図示しない既存の学習器によりフィッティング・学習することで生成される。過去監視データとは、クラウドサービスを提供する際に蓄積された、ワークロードに関するログデータ、パフォーマンスに関するログデータ、VMのリソースの運用状態に関するログデータ、環境条件に関するログデータ、リソース量に関するログデータ、等によって構成される。

【0030】

リソース量算出部１２は、入力データ（ワークロードに関するログデータ）、パフォーマンス要件、運用ポリシ、環境条件に関するログデータ）をフィッティング・学習モデルに入力することで、VMに配置される必要なリソース量を算出する。
環境条件に関するログデータは監視・データ収集部１４部の出力となる監視データからリアルタイムに抽出することができる。ワークロードに関するログデータは、クラウドユーザの設定データあるいは上記の監視データから抽出が可能である。パフォーマンス要件は、クラウドユーザが設定可能である。運用ポリシは、クラウドユーザあるいはクラウド提供者が設定可能である。

【0031】

VM実装・スケーリング制御部１３は、リソース量算出部１２の出力である、VMに配置される必要なリソース量に従って、VMを実装あるいはスケーリングし、他のオペレーションサポートシステムと連携してサービスを提供する。

【0032】

監視・データ収集部１４は、VM実装・スケーリング制御部１３により実装あるいはスケーリングされたVMまたはVMを収容する物理マシンに関する監視データを収集する。
具体的には、監視・データ収集部１４は、VM実装・スケーリング制御部１３により実装あるいはスケーリングされたVMのパフォーマンスに関するログデータ、VM実装・スケーリング制御部１３により実装あるいはスケーリングされたVMのワークロードに関するログデータ、VM実装・スケーリング制御部１３により実装あるいはスケーリングされたVMのリソースの運用状態に関するログデータ、VM実装・スケーリング制御部１３により実装あるいはスケーリングされたVMを収容する物理マシンに関する環境条件に関するログデータ、VM実装・スケーリング制御部１３により実装あるいはスケーリングされたVMのリソース量に関するログデータ、等でなる監視データを収集し、また、この監視データを過去監視データとしてフィッティング・学習モデルの継続学習（更新）に用いることもできる。

【0033】

VM実装・スケーリング制御部１３の機能を実現する方法は、以下の（１）、（２）が挙げられる。
（１）必要なリソース量をYAML（yaml ain't markup language）に書き込み、HEATに渡してVMを実装する。
（２）必要なリソース量をTOSCA（Topology and Orchestration Specification for Cloud Applications）に書き込み、Tackerに渡してVMを実装する。

【0034】

監視・データ収集部１４を実現する方法としては、openstack（登録商標） ceilometer、top、dstat、sar、httpry等を用いて監視・収集する方法が挙げられる。
YAML、HEAT、TOSCA、Tacker、openstack ceilometerは以下に開示されている。
YAML：http://yaml.org/
HEAT：https://wiki.openstack.org/wiki/Heat
TOSCA：http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html
Tacker：https://wiki.openstack.org/wiki/Tacker
openstack ceilometer：https://docs.openstack.org/ceilometer/queens/

【0035】

次に、リソース決定装置１０をシステムとして実装する方式の例について説明する。図２は、本発明の一実施形態に係るリソース決定装置の実装方式の一例を示す図である。
図２に示す方式では、モデル管理・保存部１１、リソース量算出部１２、VM実装・スケーリング制御部１３、監視・データ収集部１４でなる各機能部を一つの計算機に実装する方式、または各機能部をそれぞれ単独に計算機に実装する方式が挙げられる。
機能部間の通信はhttp等の通信プロトコルによって実現可能である。

【0036】

また、クラウドリソースを提供する物理サーバ（ホスト)群２０を設け、各サーバに、監視client、及びVM実装clientをそれぞれ実装する。
監視clientと監視・データ収集部１４間の通信、及びVM実装clientとVM実装・スケーリング制御部１３間の通信は、http等の通信プロトコルによって実現可能である。

【0037】

上記のように、リソース決定装置１０は、ワークロード、パフォーマンス要件、運用ポリシ、環境条件を考慮して、VMに配置するリソース量を決定できる。
また、パフォーマンス要件を満たしつつ、運用ポリシに従って、サービスを運用可能である。

【0038】

また、（１）パフォーマンス要件の新規追加、変更、及び（２）ワークロード、環境条件、及び運用ポリシの変更に応じて、リアルタイムで適切なリソース量を算出することができる。

【0039】

次に、環境条件によるVMのパフォーマンスへの影響について説明する。
図３は、本発明の一実施形態に係るリソース決定装置が入力する環境条件の影響の一例を示す図である。
環境条件の例としては、ホスト混雑度（即ちホストリソース利用率）が挙げられる。

【0040】

ホスト混雑度の変動によって、VMの処理能力等のパフォーマンス指標が変動する可能性がある。従って、パフォーマンス要件を満たし続けるために、ホスト混雑度を考慮して、VMに配置されるリソース量を決定及び調整する必要がある。

【0041】

次に、VMに配置されるリソース量を決定する際に、ホスト混雑度を考慮する必要性を示す。
まず、混雑度が低いホスト（図３に示した例では、ホストCPU（ホストに搭載されたCPU）利用率が０[%]であるホスト(A)）に配置された、vCPU数が４であるVM(A)のパフォーマンスと、混雑度が高いホスト（図３に示した例では、ホストCPU利用率が９０[%]であるホスト(B)）に配置された、vCPU数が４であるVM(B)のパフォーマンスとは等しくない可能性が高い。そのため、同じパフォーマンス要件を満たすため、VM(B)に、VM(A)と比較して、より多くのリソースを配置する必要がある。

【0042】

また、ホスト混雑度が極めて高い場合は、該当ホストに収容されるVMに配置されるリソース量を増やしてもパフォーマンス要件を満たせない可能性があり、この場合、VMを他のホストに配置する必要がある。

【0043】

次に、運用ポリシを考慮する必要性について説明する。図４は、本発明の一実施形態に係るリソース決定装置が入力する運用ポリシを制限しない場合に発生しやすい運用問題の一例を示す図である。
運用ポリシの例としては、VM内のリソース利用率制限が挙げられる。
サービスの差別化、運用の安定性向上、及びリソース利用効率化、等のため、クラウド提供者のVM内のリソース利用率に制限を定めることがある。図４では、リソース利用率制限を定めないことが、パフォーマンス要件の不満足、ボトルネックの発生、リソース利用効率の低下につながることを示す。
VM内のリソース利用率を制限範囲に維持するには、ワークロードに応じて、VMに配置されるリソース量を決定・調整する必要がある。

【0044】

図４に示した第１の例では、VM（vCPU数=3）内のリソース利用率がすでに100[%]であることから、VMが提供できる処理力がワークロード処理量要件（要求処理量）を満たせない。
図４に示した第２の例では、ワークロード等の増加によって、VM（vCPU数=4）内のリソース利用率が70[%]から100[%]に増加したことから、SLA（Service Level Agreement）に違反する可能性が上昇する。
図４に示した第３の例では、サービスを構成する複数のVM（例えば１つ目のVM（vCPU数=4）、２つ目のVM（vCPU数=6））において、１つ目のVM内のリソース利用率が99[%]で２つ目のVM内のリソース利用率が20[%]であることから、リソース使用率が高い１つ目のVMがボトルネックになる可能性が高い。また、２つ目のVMに過剰なリソースが配置されることを防ぐことができないため、２つ目のVMのリソース利用効率が低下する可能性がある。

【0045】

上記を踏まえ、VM内のリソース利用率を適切な範囲（例えば、50〜70[%])に維持することによって、（１）パフォーマンス要件の達成、（２）ボトルネックの防止、及び（３）ワークロード増減に応じてリソースを効率的に配置する、等の効果がある。
該当のパフォーマンス要件に対して、VM内のリソース利用率を適切な範囲に維持するためには、適切なリソース量を決定する必要がある。

【0046】

次に監視データの例について説明する。図５は、本発明の一実施形態に係るリソース決定装置が出力する監視データの一例を表形式で示す図である。
図５に示した例では、監視データは、timestamp（年月日）、sent requests per second、received responses per second、average process time[ms]、VMに配置したvCPU数、VMに配置したメモリ量[GB]、VMに配置したstorage size[GB]、VM内のCPU利用率[%]、VM内のメモリ利用率[%]、ホストCPU利用率[%]、ホストメモリ（ホストに配置されたメモリ）利用率[%]を含む。その他、監視データは、i/o throughput、storage 利用率、paging ratioなどを含んでもよい。

【0047】

timestampは、１分ごとに過去監視データを収集することを示す。
sent requests per secondはワークロードの量に関するログデータに対応する。
received responses per second、average process timeは、パフォーマンスに関するログデータに対応する。また、received responses per secondは、該当環境条件及び運用ポリシのときに実際に処理したワークロードの量を示す。

【0048】

VMに配置したvCPU数、VMに配置したメモリ量、VMに配置したstorage sizeは、VMに配置されたリソース量に関するログデータに対応する。
VM内のCPU利用率、VM内のメモリ利用率は、VMのリソースの運用状態に対応する。
ホストCPU利用率、ホストメモリ利用率は、環境条件に対応する。

【0049】

次に、リソース決定装置１０の実現にかかる詳細について説明する。
モデルの形、モデルのフィッティング・学習手法及びリソース量の算出手法の実現手法は複数存在する。ここでは以下の２つの例をあげる。
（１）数理モデル・フィッティング手法
（２）ニューラルネットワークモデル（Neural Network Model）・学習手法
数理モデル・フィッティング手法のモデル、フィッティング手法は、以下のとおりである。
モデル：数理関数、例えば線形モデル、多項式モデル及びその組み合わせ
フィッティング手法：選定された関数にフィッティング（近似）する。

【0050】

ニューラルネットワークモデルのモデル、学習手法は、以下のとおりである。
モデル：ニューラルネットワークモデル
学習手法：過去監視データを訓練データとして、ニューラルネットワークを学習させる。

【0051】

次に、上記の２種類の手法をそれぞれ使ってモデルを生成し、この生成されたモデルを使って、ワークロード、ワークロード処理能力要件(パフォーマンス要件の一種)、ホスト混雑度（環境条件の一種)、VM内のリソース利用率制限（運用ポリシの一種)に応じて、VMに割り当てられるvCPU数（リソース量の一種)を算出する例を説明する。

【0052】

次に、モデルの形について説明する。図６は、本発明の一実施形態に係るリソース決定装置に適用されるモデルの一例を示す図である。
フィッティング・学習モデルに相当する、リソースパラメータ決定・変更用モデルは、リソースパラメータ、ワークロード、環境条件を入力し、パフォーマンスに関する推測結果、及びVMのリソースの運用状態に関する推測結果をそれぞれ出力する。

【0053】

リソースパラメータは、リソース量（e.g. vCPU: x［個］、memory: y [MB]）を含む。
ワークロードは、ワークロード種類・特性（e.g. LB(Load Balancer)/ WS/ DB...）、ワークロード量（e.g. 1000[requests/s]...）を含む。
環境条件は、Hostリソース利用率（混雑度)（e.g. ホストCPU利用率20[%]...）、その他ハードウエア条件を含む。
パフォーマンスに関する推測結果は、パフォーマンス（workload収容量等)（e.g. m [requests/s]...）を含む。
VMのリソースの運用状態に関する推測結果は、VM リソース利用率（e.g. CPU: 60〜80[%]、 memory: < 60[%]）を含む。

【0054】

次に、数理モデル・フィッティング手法の例について説明する。図６は、本発明の一実施形態に係るリソース決定装置に適用される数理モデル・フィッティング手法の一例を示す図である。
数理モデル・フィッティング手法における初期モデルは、２つの多項式モデルf1、f2を用いて構成される。多項式モデルの選定基準は、過去監視データに対する観察分析結果である。また、多項式モデル以外に、他の数理モデルの形もありうる。

【0055】

モデルf1は、パフォーマンスを推測するモデルで、VM最大ワークロード処理能力を求めるモデルである。
VM最大ワークロード処理能力は、以下の式（１）で表される。
VM最大ワークロード処理能力＝f1(vCPU数、ホスト混雑度) …式（１）
VM最大ワークロード処理能力は、過去監視データから、該当のvCPU数とホスト混雑度に対して抽出することができる。

【0056】

モデルf2は、VMのリソースの運用状態を推測するモデルで、VM内のリソース利用率を求めるモデルである。
VM内のリソース利用率は、以下の式（２）で表される。
VM内のリソース利用率＝f2(vCPU数、ワークロード) …式（２）
過去監視データに対する観察分析では、VM内のリソース利用率は、vCPU数とワークロードに影響され、ホスト混雑度に影響されないことが示されている。
学習器により、初期モデルに過去監視データがフィッティングされることよって、初期モデルの関数f1とf2が確定されて、フィッティングモデルが生成される。

【0057】

次に、数理モデル・フィッティング手法におけるモデルを用いたときの、リソース量算出部のロジックについて説明する。図７は、本発明の一実施形態に係るリソース決定装置のリソース量算出部のロジックの一例を示す図である。
まず、リソース量算出部１２は、ワークロードのログデータ、パフォーマンス要件（ワークロード処理能力要件)、環境条件（ホストの混雑度）のログデータ、及び運用ポリシ（VM内のリソース利用率制限）をそれぞれ入力する（Ｓ１１）。

【0058】

リソース量算出部１２は、Ｓ１１での入力結果と、数理モデル・フィッティング手法におけるモデルの関数f1とを用いて、現時点で入力されたホストの混雑度において、vCPU数が設定許容値最小値から最大値までの条件におけるパフォーマンス（VMの最大ワークロード処理能力）をそれぞれ算出する（Ｓ１２）。この算出結果は、パフォーマンスに関する推測結果に対応する。

【0059】

リソース量算出部１２は、Ｓ１２で算出したパフォーマンス（VMの最大ワークロード処理能力）を、クラウドユーザにより設定されるパフォーマンス要件（ワークロード処理能力要件）と比較して、当該パフォーマンス要件を満たせるリソース量（vCPU数）を選出する（Ｓ１３）。この選出結果は、パフォーマンス要件を満たせるリソース量の選出結果に対応する。ここで選出されるvCPU数は単一種類（例えば４つ）であってもよいし、複数種類（例えば、４つ、５つ）であってもよい。

【0060】

リソース量算出部１２は、Ｓ１１での入力結果と、数理モデル・フィッティング手法におけるモデルの関数f2とを用いて、Ｓ１１で入力されたワークロードにおいて、Ｓ１３で選出されたvCPU数に対して、VM内のリソース利用率を算出する（Ｓ１４）。この算出結果は、VMのリソースの運用状態に関する推測結果に対応する。

【0061】

リソース量算出部１２は、Ｓ１１で入力された、VM内のリソース利用率制限を満たせるために必要なvCPU数を選出する（Ｓ１５）。この選出結果は、運用ポリシを満たせるリソース量の選出結果に対応する。
リソース量算出部１２は、Ｓ１５での選出結果であるvCPU数を、ワークロード処理能力要件、運用ポリシをそれぞれ満たせる、VMに配置するリソース量としてVM実装・スケーリング制御部１３に出力する（Ｓ１６）。

【0062】

次に、上記のニューラルネットワークモデル・学習手法の例について説明する。
ニューラルネットワークモデル・学習手法における初期モデルは、２つのニューラルネットワークモデル（モデルＡ、モデルＢ）によって構成される。

【0063】

モデルＡは、VMのパフォーマンスを推測するモデルであって、ワークロード処理量に対して、該当のホスト混雑度及びVM内のリソース利用率の条件で、処理できるワークロード量を算出するモデルである。

【0064】

図８は、本発明の一実施形態に係るリソース決定装置に適用されるニューラルネットワークモデル・学習手法における第１のモデルの一例を示す図である。
図８に示すように、モデルＡは、ワークロード、ホストCPUリソース混雑度、VM内のCPUリソース利用率、vCPU数を入力し、VMが処理できるワークロード処理量を出力する。

【0065】

モデルＢは、VMのリソースの運用状態を推測するモデルであって、要求されたワークロード要件及び該当ホスト混雑度に対して、VM内のリソース利用率を算出するモデルである。

【0066】

図９は、本発明の一実施形態に係るリソース決定装置に適用されるニューラルネットワークモデル・学習手法における第２のモデルの一例を示す図である。
図９に示すように、モデルＢは、ワークロード、ホストCPUリソース混雑度、ワークロード処理量、vCPU数を入力し、VM内のCPUリソース利用率を出力する。

【0067】

過去監視データの一部分が訓練データとして初期モデルに入力されて、ニューラルネットワークに学習させることで、学習モデルが生成される。また、リソース決定装置１０は、過去監視データの一部分を用いて、学習モデルの精度を評価する。
また、図８、９に示したニューラルネットワークモデルの形以外に、他のニューラルネットワークモデルの形もありうる。

【0068】

次に、ニューラルネットワークにおけるモデルを用いたときの、リソース量算出部のロジックについて説明する。図１０は、本発明の一実施形態に係るリソース決定装置のリソース量算出部のロジックの一例を示す図である。
まず、リソース量算出部１２は、ワークロードのログデータ、パフォーマンス要件(ワークロード処理能力要件）、環境条件（ホストの混雑度）のログデータ、及び運用ポリシ（VM内のリソース利用率制限）をそれぞれ入力する（Ｓ２１）。

【0069】

リソース量算出部１２は、Ｓ２１での入力結果と、ニューラルネットワークにおけるモデルのモデルＡを用いて、現時点のワークロード及びホスト混雑度において、vCPU数が最小値から最大値までの条件におけるパフォーマンス（VMが処理できるワークロード量）を算出する（Ｓ２２）。この算出結果は、パフォーマンスに関する推測結果に対応する。

【0070】

リソース量算出部１２は、Ｓ１２で算出されたパフォーマンス（VMが処理できるワークロード量）と、クラウドユーザにより設定されるパフォーマンス要件（VMが処理できるワークロード量の要件）とを比較して、当該パフォーマンス要件を満たせるリソース量（vCPU数）を選出する（Ｓ２３）。この選出結果は、パフォーマンス要件を満たせるリソース量の選出結果に対応する。

【0071】

リソース量算出部１２は、Ｓ２１での入力結果と、ニューラルネットワークにおけるモデルのモデルＢを使って、Ｓ２１で入力されたワークロード及びホスト混雑度において、Ｓ２１で入力されたvCPU数に対して、VM内のリソース利用率を算出する（Ｓ２４）。この算出結果は、VMのリソースの運用状態に関する推測結果に対応する。

【0072】

リソース量算出部１２は、Ｓ２１で入力された、VM内のリソース利用率制限を満たすために必要なvCPU数を選出する（Ｓ２５）。この選出結果は、運用ポリシを満たせるリソース量の選出結果に対応する。
リソース量算出部１２は、Ｓ１５での選出結果であるvCPU数を、ワークロード処理能力要件、運用ポリシをそれぞれ満たせる、VMに配置するリソース量としてVM実装・スケーリング制御部１３に出力する（Ｓ２６）。

【0073】

次に、リソース決定装置１０を用いて、サービス開通・スケーリングを支援する例について説明する。図１１は、本発明の一実施形態に係るリソース決定装置によるサービス開通、スケーリングの支援の流れの一例を示す図である。
（１）サービス開通する際に、リソース決定装置１０のリソース量算出部１２は、ワークロード、パフォーマンス要件、環境状況、運用ポリシに応じて、VMに配置されるリソース量を算出する。

【0074】

（２）サービス開通後に、サービスの運用保守とともに、リソース量算出部１２は、ワークロード、パフォーマンス要件、環境状況、運用ポリシの監視の結果を取得し、この監視の結果の変化に応じて、VMに配置されたリソース量を調整（スケーリング）する。

【0075】

次に、サービス開通する際における、VMに配置されるリソース量の算出の具体例について説明する。図１２は、本発明の一実施形態に係るリソース決定装置によるサービス開通する際における、VMに配置されるリソース量の算出の具体例を示す図である。
ここでは、初期モデルにニューラルネットワークが用いられる。

【0076】

図１２に示した例において、クラウドサービスを開通する際に、リソース決定装置１０のリソース量算出部１２は、パフォーマンス要件を満たすために、ワークロード、ホスト混雑度（環境条件の一種)、VM内のリソース利用率制限（運用ポリシの一種）に応じて、VMに配置される必要なリソース量（vCPU数、メモリ量)をそれぞれ算出する。必要なリソース量とは、パフォーマンス要件、運用ポリシをそれぞれ満たせるリソース量である。

【0077】

初期モデルにはニューラルネットワークモデルが用いられる。ニューラルネットワークモデルの構築、学習は、既存の機械学習ライブラリ例えばtensorflow（登録商標）（例えばhttps://www.tensorflow.org/を参照）によって実現可能である。
ここでは、過去に提供されたサービスの過去監視データが学習器に入力されて学習モデルが生成されてモデル管理・保存部１１に格納されている。

【0078】

リソース量算出部１２が入力する、新規のサービスのワークロード(種類:web server、特徴値：web pageサイズ＝10[KB]の条件）は10000[requests per second]であり、VM内のリソース利用率制限は50〜70[%]に定められ、VMが配置されようとしているホストのCPUリソースの混雑度は10[%]で、当該ホストのメモリリソースの混雑度は40[%]である。

【0079】

リソース量算出部１２は、ワークロード、VM内のリソース利用率制限、VMが配置されようとしているホストのCPUリソースの混雑度は、当該ホストのメモリリソースの混雑度を入力し、パフォーマンス要件（97%以上のrequestsを処理する）を満たすために、VMに配置されるリソース量(vCPU数:4、メモリ量:1[GB])を算出する。
VM実装・スケーリング制御部１３は、vCPU数が４で、メモリ量が1[GB]のVMを実装し、他のオペレーションサポートシステムと連携してサービスを提供する。

【0080】

監視・データ収集部１４は、サービスのワークロード、パフォーマンス、サービスを収容するVM内のリソース利用率、ホストの混雑度、リソース量等を監視し、監視データを収集する。監視・データ収集部１４は、収集した、ホストの混雑度をリソース量算出部１２の入力であるホスト混雑度をリアルタイムに更新する。また、定期的に監視データを過去監視データとして学習器に渡して再学習させることで、モデルを更新することができる。

【0081】

次に、サービス開通後のスケーリングにおける、VMに配置されるリソース量の調整の具体例について説明する。図１３は、本発明の一実施形態に係るリソース決定装置によるサービス開通後のスケーリングにおける、VMに配置されるリソース量の調整の具体例を示す図である。
ここでは、初期モデルにニューラルネットワークが用いられる。

【0082】

図１３に示した例において、運用中のクラウドサービスにおいて、リソース決定装置１０のリソース量算出部１２は、パフォーマンス要件、ワークロード、ホスト混雑度（環境状況の一種)、VM内のリソース利用率制限（運用ポリシの一種）のうち少なくとも１つが変動する際に、パフォーマンス要件を満たし続けるための、VMのリソース量（vCPU数、メモリ量)を調整する。ここではパフォーマンス要件は変動しない例について説明するが、このパフォーマンス要件が変動する際に、この要件を満たし続けるためのVMのリソース量を調整することも考えられる。

【0083】

ここでは、過去監視データが学習器に入力されて、学習モデルが生成されてモデル管理・保存部１１に格納されている。
サービスのワークロード量が10000[requests per second]から20000[requests per second]に変更され、VM内のリソース利用率制限が50〜70[%]から60〜80[%]に変更され、また、VMが収容されるホストのCPUリソースの混雑が10[%]から30[%]に変動し、ホストのメモリリソースの混雑度が40[%]から50[%]に変動したと仮定する。

【0084】

リソース量算出部１２は、これらの変動した情報を入力し、サービス開通時からのパフォーマンス要件（97[%]以上のrequestsを処理する）を満たし続けるために、適切なリソース量（vCPU数:10メモリ:1.5[GB])を算出する。

【0085】

VM実装・スケーリング制御部１３は、リソース量算出部１２による算出結果を受けて、VMにおいて実装されるvCPU数を４から１０にスケールアップし、実装されるメモリ量を1[GB]から1.5[GB]にスケールアップする。

【0086】

監視・データ収集部１４は、提供したサービスのワークロード、パフォーマンス、サービスが収容されるVM内のリソース利用率、ホストCPU及びメモリの混雑度、リソース量をそれぞれ監視し、データを収集する。

【0087】

監視・データ収集部１４により収集されたホスト混雑度により、リソース量算出部１２の入力となるホスト混雑度がリアルタイムに更新され、また、過去監視データとして学習器に渡され、再学習することで、学習モデルを更新することができる。

【0088】

以上説明したように、本発明の一実施形態に係るリソース決定装置は、仮想マシンが収容される物理マシンのリソースの運用状態の監視結果、仮想マシンの処理負荷に基づいて、仮想マシンの処理性能の要件及び仮想マシンのリソースの運用状態のポリシをそれぞれ満たす、仮想マシンに配置されるリソース量を算出するので、仮想マシンに必要なリソース量を適切に求め、リソース決定にかかる人的コストを低減することができる。

【0089】

なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の発明が含まれており、開示される複数の構成要件から選択された組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、課題が解決でき、効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。

【0090】

また、各実施形態に記載した手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段（実行プログラムのみならずテーブル、データ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスク、半導体メモリ等の記憶媒体を含むものである。

【符号の説明】

【0091】

１０…リソース決定装置、１１…モデル管理・保存部、１２…リソース量算出部、１３…VM実装・スケーリング制御部、１４…監視・データ収集部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】