特許 6795536 ＶＭ性能保証システムおよびＶＭ性能保証方法

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

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

(11)【特許番号】6795536

(24)【登録日】2020年11月16日

(45)【発行日】2020年12月2日

(54)【発明の名称】ＶＭ性能保証システムおよびＶＭ性能保証方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20201119BHJP

   G06F 9/455 20060101ALI20201119BHJP

   G06F 11/34 20060101ALI20201119BHJP

【ＦＩ】

   G06F9/50 150A

   G06F9/455 150

   G06F11/34 195

   G06F11/34 142

【請求項の数】4

【全頁数】16

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

(22)【出願日】2018年3月12日

(65)【公開番号】特開2019-159646(P2019-159646A)

(43)【公開日】2019年9月19日

【審査請求日】2020年2月28日

【新規性喪失の例外の表示】特許法第３０条第２項適用 （１）平成３０年１月１２日に電子情報通信学会 第１５回ネットワークソフトウェア研究会のウェブサイト（ｈｔｔｐ：／／ｗｗｗ．ｉｅｉｃｅ．ｏｒｇ／ｃｓ／ｎｓ／ｎｗｓ／２０１８０１１８＿ｎｗｓｐａｐｅｒ．ｚｉｐ）で講演原稿を公開 （２）平成３０年１月１８日・１９日に開催された電子情報通信学会 第１５回ネットワークソフトウェア研究会において１８日に発表

(73)【特許権者】

【識別番号】000004226

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

(74)【代理人】

【識別番号】110001807

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

(72)【発明者】

【氏名】伊藤 義人

(72)【発明者】

【氏名】浜田 信

【審査官】 桜井 茂行

(56)【参考文献】

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

【文献】 米国特許出願公開第２０１０／０３１２８９３（ＵＳ，Ａ１）

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

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

【文献】 米国特許出願公開第２０１５／００４０１３１（ＵＳ，Ａ１）

【文献】 宮田 康志，仮想化環境におけるクラスタ構成の動的変更制御による省電力化方式の提案，電子情報通信学会技術研究報告，日本，社団法人電子情報通信学会，２０１０年 ７月，Ｖｏｌ．１１０ Ｎｏ．１６７，pp. 49-54

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

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ ９／４５５

Ｇ０６Ｆ １１／３４

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

【請求項1】

複数のＶＭ（Virtual Machine）を稼働させる物理サーバと、前記物理サーバに接続され、前記ＶＭの稼働状態を管理するコントローラとを備えるＶＭ性能保証システムであって、
前記物理サーバは、
当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるＶＭ数を異なるように設定して、前記共有できるＶＭ数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるＶＭとの対応関係を格納する優先度グループ設定情報が記憶される記憶部と、
前記ＶＭそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するリソース利用量収集部と、
前記ＶＭそれぞれに対する前記優先度グループの変更指示を示す優先度グループ変更情報を前記コントローラから受信すると、前記優先度グループ設定情報を参照し、当該ＶＭが属する優先度グループを変更する優先度グループ変更部と、を備え、
前記コントローラは、
前記物理サーバから前記ＶＭそれぞれのリソース利用量を取得するデータ取得部と、
取得した前記リソース利用量に基づき算出された性能値が当該ＶＭの性能不足を判定する第１の条件を満たすか否か、および、前記性能値が当該ＶＭの性能過多を判定する第２の条件を満たすか否か、を判定し、前記第１の条件を満たす場合に、より優先度の高い優先度グループへの変更指示を示す第１の前記優先度グループ変更情報を前記物理サーバに送信し、前記第２の条件を満たす場合に、より優先度の低い優先度グループへの変更指示を示す第２の前記優先度グループ変更情報を前記物理サーバに送信する優先度変更判定部と、を備え、
前記物理サーバの優先度グループ変更部は、
第１の前記優先度グループ変更情報を受信した場合に、当該ＶＭが属する優先度グループをより優先度の高い優先度グループに変更し、第２の前記優先度グループ変更情報を受信した場合に、当該ＶＭが属する優先度グループをより優先度の低い優先度グループに変更すること
を特徴とするＶＭ性能保証システム。

【請求項2】

前記コントローラは、
前記優先度グループに属するＶＭそれぞれに対して、負荷を所定のパターンで変動させて稼働するテストツールの実行を指示するテストツール機能部と、
前記物理サーバから、前記テストツールによる稼働で得られたリソース利用量および性能値をテスト結果情報として受信し、前記テスト結果情報に基づき、前記リソース利用量に応じた性能値の推定に用いる学習結果データを機械学習により生成する学習機能部と、
前記物理サーバから取得した現時点での前記ＶＭそれぞれのリソース利用量に基づき、前記学習結果データを用いて前記ＶＭそれぞれの性能推定値を計算する性能値推定部と、をさらに備え、
前記優先度変更判定部は、前記算出された性能値の替わりに、計算された前記性能推定値を用いて、前記第１の条件および前記第２の条件を満たすか否かを判定することにより、前記ＶＭそれぞれの前記優先度グループの変更を判定すること
を特徴とする請求項１に記載のＶＭ性能保証システム。

【請求項3】

前記コントローラの前記データ取得部は、前記物理サーバから、前記優先度グループに属するＶＭそれぞれのリソース利用量および性能値を、所定期間の稼働において実データとして取得し、
前記コントローラは、
前記実データに基づき、前記リソース利用量に応じた性能値の推定に用いる学習結果データを機械学習により生成する学習機能部と、
前記物理サーバから取得した現時点での前記ＶＭそれぞれのリソース利用量に基づき、前記学習結果データを用いて前記ＶＭそれぞれの性能推定値を計算する性能値推定部と、をさらに備え、
前記優先度変更判定部は、前記算出された性能値の替わりに、計算された前記性能推定値を用いて、前記第１の条件および前記第２の条件を満たすか否かを判定することにより、前記ＶＭそれぞれの前記優先度グループの変更を判定すること
を特徴とする請求項１に記載のＶＭ性能保証システム。

【請求項4】

複数のＶＭを稼働させる物理サーバと、前記物理サーバに接続され、前記ＶＭの稼働状態を管理するコントローラとを備えるＶＭ性能保証システムのＶＭ性能保証方法であって、
前記物理サーバは、
当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるＶＭ数を異なるように設定して、前記共有できるＶＭ数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるＶＭとの対応関係を格納する優先度グループ設定情報が記憶される記憶部を備えており、
前記ＶＭそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するステップを実行し、
前記コントローラは、
前記物理サーバから前記ＶＭそれぞれのリソース利用量を取得するステップと、
取得した前記リソース利用量に基づき算出された性能値が当該ＶＭの性能不足を判定する第１の条件を満たすか否か、および、前記性能値が当該ＶＭの性能過多を判定する第２の条件を満たすか否か、を判定し、前記第１の条件を満たす場合に、より優先度の高い優先度グループへの変更指示を示す第１の優先度グループ変更情報を前記物理サーバに送信し、前記第２の条件を満たす場合に、より優先度の低い優先度グループへの変更指示を示す第２の優先度グループ変更情報を前記物理サーバに送信するステップと、を実行し、
前記物理サーバは、
前記第１の優先度グループ変更情報を受信した場合に、前記優先度グループ設定情報を参照し、当該ＶＭが属する優先度グループをより優先度の高い優先度グループに変更し、前記第２の優先度グループ変更情報を受信した場合に、前記優先度グループ設定情報を参照し、当該ＶＭが属する優先度グループをより優先度の低い優先度グループに変更するステップを実行すること
を特徴とするＶＭ性能保証方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワーク仮想化技術を用いて、物理マシン上で共有されるＶＭ（Virtual Machine：仮想マシン）の性能を保証する、ＶＭ性能保証システムおよびＶＭ性能保証方法に関する。

【背景技術】

【0002】

物理サーバ上で複数のＶＭを稼働させる一般的な仮想化環境では、サーバリソースは全ＶＭで共有される。そして、その共有の仕方は、ハイパーバイザおよびホストＯＳ（Operating System）のスケジューラに一任され、制御することができない。仮想化環境として広く用いられているOpenStackでも、例えば物理ＣＰＵ（ｐＣＰＵ）は物理サーバ上の全ＶＭに共有される。

【0003】

一方、ＶＭを専用の物理ＣＰＵ（ＣＰＵコア）に固定化（ピニング）する技術が開示されている（非特許文献１）。

【先行技術文献】

【非特許文献】

【0004】

【非特許文献1】「Red Hat OpenStack Platform インスタンス＆イメージガイド 第４章 ＮＵＭＡノードを使用するＣＰＵピニングの設定」、［online］、Red Hat、［平成30年3月1日検索］、インターネット＜ＵＲＬ：https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/9/html/instances_and_images_guide/ch-cpu_pinning＞

【発明の概要】

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

【0005】

上記のような従来技術では、物理サーバ上の複数のＶＭを、どの物理ＣＰＵで稼働させるかに関し、共有の程度を制御することはできない。このため、ネットワーク機能としてサービスの性能保証が求められる場合において、OpenStackをはじめとする仮想化環境では特に制御を行わないと、リソースが制御できない形で共有されてしまいＶＭの性能保証を行うことができなかった。
また、リソースを占有して固定的にＶＭを割り当てる手法を用いてしまうと、仮想化本来のメリットである柔軟な構成を用いることや、リソースの有効活用ができないという結果となる。

【0006】

このような点に鑑みて本発明がなされたのであり、本発明は、リソースの利用効率を高めつつ、ＶＭの性能保証を実現することができるＶＭ性能保証システムおよびＶＭ性能保証方法を提供することを課題とする。

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

【0007】

前記した課題を解決するため、請求項１に記載の発明は、複数のＶＭを稼働させる物理サーバと、前記物理サーバに接続され、前記ＶＭの稼働状態を管理するコントローラとを備えるＶＭ性能保証システムであって、前記物理サーバが、当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるＶＭ数を異なるように設定して、前記共有できるＶＭ数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるＶＭとの対応関係を格納する優先度グループ設定情報が記憶される記憶部と、前記ＶＭそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するリソース利用量収集部と、前記ＶＭそれぞれに対する前記優先度グループの変更指示を示す優先度グループ変更情報を前記コントローラから受信すると、前記優先度グループ設定情報を参照し、当該ＶＭが属する優先度グループを変更する優先度グループ変更部と、を備え、前記コントローラが、前記物理サーバから前記ＶＭそれぞれのリソース利用量を取得するデータ取得部と、取得した前記リソース利用量に基づき算出された性能値が当該ＶＭの性能不足を判定する第１の条件を満たすか否か、および、前記性能値が当該ＶＭの性能過多を判定する第２の条件を満たすか否か、を判定し、前記第１の条件を満たす場合に、より優先度の高い優先度グループへの変更指示を示す第１の前記優先度グループ変更情報を前記物理サーバに送信し、前記第２の条件を満たす場合に、より優先度の低い優先度グループへの変更指示を示す第２の前記優先度グループ変更情報を前記物理サーバに送信する優先度変更判定部と、を備え、前記物理サーバの優先度グループ変更部が、第１の前記優先度グループ変更情報を受信した場合に、当該ＶＭが属する優先度グループをより優先度の高い優先度グループに変更し、第２の前記優先度グループ変更情報を受信した場合に、当該ＶＭが属する優先度グループをより優先度の低い優先度グループに変更することを特徴とするＶＭ性能保証システムとした。

【0008】

また、請求項４に記載の発明は、複数のＶＭを稼働させる物理サーバと、前記物理サーバに接続され、前記ＶＭの稼働状態を管理するコントローラとを備えるＶＭ性能保証システムのＶＭ性能保証方法であって、前記物理サーバが、当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるＶＭ数を異なるように設定して、前記共有できるＶＭ数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるＶＭとの対応関係を格納する優先度グループ設定情報が記憶される記憶部を備えており、前記ＶＭそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するステップを実行し、前記コントローラが、前記物理サーバから前記ＶＭそれぞれのリソース利用量を取得するステップと、取得した前記リソース利用量に基づき算出された性能値が当該ＶＭの性能不足を判定する第１の条件を満たすか否か、および、前記性能値が当該ＶＭの性能過多を判定する第２の条件を満たすか否か、を判定し、前記第１の条件を満たす場合に、より優先度の高い優先度グループへの変更指示を示す第１の優先度グループ変更情報を前記物理サーバに送信し、前記第２の条件を満たす場合に、より優先度の低い優先度グループへの変更指示を示す第２の優先度グループ変更情報を前記物理サーバに送信するステップと、を実行し、前記物理サーバが、前記第１の優先度グループ変更情報を受信した場合に、前記優先度グループ設定情報を参照し、当該ＶＭが属する優先度グループをより優先度の高い優先度グループに変更し、前記第２の優先度グループ変更情報を受信した場合に、前記優先度グループ設定情報を参照し、当該ＶＭが属する優先度グループをより優先度の低い優先度グループに変更するステップを実行することを特徴とするＶＭ性能保証方法とした。

【0009】

このように、ＶＭ性能保証システムでは、物理リソースを複数のグループに分割し、共有できるＶＭ数の異なる優先度グループを定義しておく。そして、コントローラが、ＶＭのリソース利用量に基づき、性能不足もしくは性能過多と判定した場合に、物理サーバにおいて、そのＶＭの優先度グループを変更することができる。よって、物理サーバの物理リソースを有効活用した上で、ＶＭの性能保証を実現することができる。

【0010】

請求項２に記載の発明は、前記コントローラが、前記優先度グループに属するＶＭそれぞれに対して、負荷を所定のパターンで変動させて稼働するテストツールの実行を指示するテストツール機能部と、前記物理サーバから、前記テストツールによる稼働で得られたリソース利用量および性能値をテスト結果情報として受信し、前記テスト結果情報に基づき、前記リソース利用量に応じた性能値の推定に用いる学習結果データを機械学習により生成する学習機能部と、前記物理サーバから取得した現時点での前記ＶＭそれぞれのリソース利用量に基づき、前記学習結果データを用いて前記ＶＭそれぞれの性能推定値を計算する性能値推定部と、をさらに備え、前記優先度変更判定部が、前記算出された性能値の替わりに、計算された前記性能推定値を用いて、前記第１の条件および前記第２の条件を満たすか否かを判定することにより、前記ＶＭそれぞれの前記優先度グループの変更を判定することを特徴とする請求項１に記載のＶＭ性能保証システムとした。

【0011】

このように、コントローラが、テストツール機能部、学習機能部および性能値推定部を備えることにより、ＶＭのリアルタイムのリソース利用量から性能値が算出できない場合であっても、テストツールで稼働させたテスト結果情報に基づき、当該ＶＭの性能推定値を計算することができる。この性能推定値を用いて、コントローラが、性能不足もしくは性能過多を判定することにより、物理サーバにおいて、動的にＶＭの優先度グループを変更することができる。よって、物理サーバの物理リソースを有効活用した上で、ＶＭの性能保証を実現することができる。

【0012】

請求項３に記載の発明は、前記コントローラの前記データ取得部は、前記物理サーバから、前記優先度グループに属するＶＭそれぞれのリソース利用量および性能値を、所定期間の稼働において実データとして取得し、前記コントローラが、前記実データに基づき、前記リソース利用量に応じた性能値の推定に用いる学習結果データを機械学習により生成する学習機能部と、前記物理サーバから取得した現時点での前記ＶＭそれぞれのリソース利用量に基づき、前記学習結果データを用いて前記ＶＭそれぞれの性能推定値を計算する性能値推定部と、をさらに備え、前記優先度変更判定部が、前記算出された性能値の替わりに、計算された前記性能推定値を用いて、前記第１の条件および前記第２の条件を満たすか否かを判定することにより、前記ＶＭそれぞれの前記優先度グループの変更を判定することを特徴とする請求項１に記載のＶＭ性能保証システムとした。

【0013】

このように、コントローラが、学習機能部および性能値推定部を備えることにより、ＶＭの所定期間の稼働における実データに基づき、当該ＶＭの性能推定値を計算することができる。この性能推定値を用いて、コントローラが、性能不足もしくは性能過多を判定することにより、物理サーバにおいて、動的にＶＭの優先度グループを変更することができる。よって、物理サーバの物理リソースを有効活用した上で、ＶＭの性能保証を実現することができる。

【発明の効果】

【0014】

本発明によれば、リソースの利用効率を高めつつ、ＶＭの性能保証を実現するＶＭ性能保証システムおよびＶＭ性能保証方法を提供することができる。

【図面の簡単な説明】

【0015】

【図1】ＶＭの負荷が増大した場合にリソース割当を増やす従来の手法を説明するための図である。

【図2】本実施形態に係るＶＭ性能保証システムでの、共有するＶＭ数を変更する処理を説明するための図である。

【図3】本実施形態に係る物理サーバにおいて、リソースを優先度の異なるグループに分割することを説明するための図である。

【図4】本実施形態に係る優先度グループの変更処理を説明するための図である。

【図5】優先度グループの変更により、ＶＭの性能保証が実現することを説明するための図である。

【図6】本実施形態に係るＶＭ性能保証システムを構成する物理サーバおよびコントローラの構成例を示す図である。

【図7】本実施形態に係るＶＭ性能保証システムが実行する学習結果データ生成処理の流れを示すフローチャートである。

【図8】本実施形態に係るＶＭ性能保証システムが実行する優先度グループ変更処理の流れを示すフローチャートである。

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

【0016】

次に、本発明を実施するための形態（以下、「本実施形態」という。）について説明する。まず、本実施形態に係るＶＭ性能保証システムＳの特徴となる構成について、その概要を説明する。

【0017】

＜概要＞
ＶＭ性能保証システムＳは、後記する図６で示すように、複数のＶＭ１を備える物理サーバ１０（コンピュート）と、コントローラ２０とを備えて構成される。そして、ＶＭ性能保証システムＳは、物理サーバ１０の利用効率を高めつつ、ＶＭ１の性能保証を実現するため、以下に示す技術的特徴を備える。

【0018】

従来、図１に示すように、例えば、１つの物理リソース（ＣＰＵコア：図１の●印）に１つのＶＭ１（図１では１つのＶＭ１に２つの仮想ＣＰＵ（図１の〇印）を備える。）が稼働する状況において、ＶＭ１の負荷が増大した場合、物理リソースの割り当てを増やす、つまり、ＣＰＵコアを追加しＶＭ１へのリソース割当量を変更することにより、ＶＭ１の性能低下を防いでいた。具体的には、図１の左図のＶＭ１の負荷が増大した場合、図１の右図に示すように、例えば、ＣＰＵコアを増加し、１つの仮想ＣＰＵに１つの物理リソース（ＣＰＵコア）を割り当てる制御を行っていた。

【0019】

これに対し、本実施形態に係るＶＭ性能保証システムＳでは、図２に示すように、２つの物理リソース（ＣＰＵコア）を２つのＶＭ１が共有する状況において、ＶＭ１の負荷が増大した場合に、物理リソースに割り当てるＶＭの数を変更することにより、ＶＭ１の性能低下を防ぐようにする。図２では、物理リソースに共有するＶＭ１の数を「２」から「１」に変更する制御を行う（図２の右図参照）。
つまり、ＶＭ１のリソース割当量を変更するのではなく、有限な物理リソース（ＣＰＵコア）に対して、割り当てるＶＭ数を制御することを特徴とする。

【0020】

また、ＶＭ性能保証システムＳの物理サーバ１０では、有限の物理リソース（ＣＰＵコア）を優先度の異なるグループに分割しておく（図３参照）。そして、各ＶＭ１のリソース利用量から計算されるＶＭ１の性能推定値に基づき、性能不足のＶＭ１は、高優先のグループに所属させるように優先度グループの所属先を変更する。また、性能過多のＶＭ１は、低優先のグループに所属させるように、優先度グループの所属先を変更する。このように、ＶＭ性能保証システムＳでは、各ＶＭ１について計算される性能推定値に基づき、どの優先度のグループに所属させるかを判断して所属先の優先度グループを変更する。

【0021】

本実施形態において、この優先度グループは、物理リソースに対するＶＭ１の共有数（ＶＭ数）が異なるグループとして定義する。具体的には、オーバーコミット率の異なるＣＰＵピニングパターンのグループに、物理リソースを分割しておく。そして、ＶＭ１の負荷に応じて、オーバーコミット率の異なる優先度グループ（ＣＰＵピニングパターン）を動的に変更する。高負荷時はオーバーコミット率の小さい（高優先）パターンでＣＰＵを占有（固定化）し、低負荷時はオーバーコミット率の大きい（低優先）パターンでＣＰＵを占有する。これにより、所定値以上の性能を保証しながら、物理リソースの利用効率を高めることができる。

【0022】

例えば、図４に示すように、優先度の最も高いグループとして「優先度Ａのグループ」を設定する。この「優先度Ａのグループ」は、分割した有限の物理リソース（ここでは、２つのＣＰＵコア）に、ＶＭ数が「２」、つまり２つのＶＭ１まで共有できる設定のオーバーコミット率の小さい（高優先）のパターンである。次の「優先度Ｂのグループ」は、分割した有限の物理リソース（２つのＣＰＵコア）に、ＶＭ数が「４」まで共有できるグループである。次の「優先度Ｃのグループ」は、分割した有限の物理リソース（２つのＣＰＵコア）に、ＶＭ数が「８」まで共有できるグループである。そして、「優先度Ｄのグループ」は、分割した有限の物理リソース（２つのＣＰＵコア）に、ＶＭ数が「１６」まで共有できる設定のオーバーコミット率の大きい（低優先）のパターンである。

【0023】

本実施形態に係るＶＭ性能保証システムＳでは、例えば、図５に示すように、最初は、ＶＭ数「１６」の「優先度Ｄのグループ」に所属していたＶＭ１が、その性能が低下し、予めユーザとの間で取り決めがなされたＳＬＡ（Service Level Agreement：サービス品質保証）で示される性能値に所定値以上近づいた場合（性能不足に至る状況の場合）に、所属グループをより高優先でオーバーコミット率の小さい「優先度Ｃのグループ」（共有できるＶＭ数「８」）に変更する。そのＶＭ１について、その後さらに性能が低下し、ＳＬＡで示される性能値に所定値以上近づいた場合には、同様に、所属グループを「優先度Ｂのグループ」（共有できるＶＭ数「４」）、「優先度Ａのグループ」（共有できるＶＭ数「２」）のように、より高優先でオーバーコミット率の小さいグループに変更する。このようにすることにより、ＶＭ１の性能保証を実現することができる。
また、ＶＭ性能保証システムＳでは、性能に余裕がある場合には（性能過多の場合）には、そのＶＭ１の所属グループをより低優先でオーバーコミット率の大きいグループに変更する。このようにすることで、物理リソース（ＣＰＵコア）の利用効率を高めることができる。

【0024】

＜本実施形態の構成＞
次に、本実施形態に係るＶＭ性能保証システムＳについて説明する。
図６は、本実施形態に係るＶＭ性能保証システムＳを構成する物理サーバ１０およびコントローラ２０の機能ブロック図である。
物理サーバ１０とコントローラ２０は、通信ネットワークを介して接続される。本実施形態では、１台の物理サーバ１０上に、仮想ルータとして機能するＶＭ１が複数配置されるものとして説明する。なお、物理サーバ１０は１台に限定されるものではなく、複数台の物理サーバ１０がコントローラ２０に接続されていてもよい。また、仮想ルータもＶＭ１の機能の一例であり、他の機能をＶＭ１で実現するようにしてもよい。

【0025】

≪物理サーバ≫
物理サーバ１０は、自身の物理サーバ上に複数のＶＭ１（仮想マシン）を設定する機能（コンピュートとしての機能）を有する。ここでは、具体例として、各ＶＭ１に対してＳＬＡ等で規定される性能を、ＶＭ１（仮想ルータ）のパケット転送の遅延（レイテンシ）とする。なお、ＳＬＡ等で規定される性能は、遅延（レイテンシ）以外でも、例えばスループット等であってもよい。また、ＶＭ１（仮想ルータ）のＣＰＵ使用量、メモリ使用量、パケット送受信数等をリソース利用量とする。

【0026】

この物理サーバ１０は、自身が備える物理リソース（例えば、ＣＰＵコア）を優先度の異なる複数のグループに分割しておき、その分割された物理リソース毎に、ＶＭ１の共有数（ＶＭ数）が異なるグループを定義しておく。そして、物理サーバ１０は、ＶＭ１の負荷に応じて、そのＶＭ１の優先度グループをオーバーコミット率の異なる他の優先度グループを変更する。

【0027】

この物理サーバ１０は、ＶＭ１を生成する機能（図示省略）を備えるとともに、リソース利用量収集部１１、優先度グループ定義部１２、優先度グループ変更部１３を備える。また、物理サーバ１０は、入出力部および記憶部（いずれも図示省略）を備える。
入出力部は、情報の送受信を行うための通信インタフェース、および、タッチパネルやキーボード等の入力装置や、モニタ等の出力装置との間で情報の送受信を行うための入出力インタフェースからなる。
また、記憶部は、フラッシュメモリやハードディスク、ＲＡＭ（Random Access Memory）等により構成される。この物理サーバ１０の記憶部には、図６に示すように、優先度グループ設定情報１４が記憶される（詳細は後記）。

【0028】

リソース利用量収集部１１は、各ＶＭ１のリソース利用量（ＣＰＵ使用量、メモリ使用量、パケット送受信数等）を収集する。そして、リソース利用量収集部１１は、収集した各ＶＭ１のリソース利用量の情報を、コントローラ２０に送信する。
なお、リソース利用量収集部１１は、コントローラ２０の指示により、後記するテストツールが実行された場合には、そのテストツールのテスト結果である各ＶＭ１のリソース利用量をコントローラ２０に送信する。

【0029】

優先度グループ定義部１２は、物理サーバ１０の物理リソースであるＣＰＵコアを、複数のグループに分割する。そして、各グループを、オーバーコミット率の異なるＣＰＵピニングパターンに分けて設定する。
具体的には、優先度グループ定義部１２は、図４で示したように、優先度が最も高いグループとして、共有できるＶＭ数を「２」とする「優先度Ａのグループ」を設定する。次に優先度が高いグループとして、共有できるＶＭ数を「４」とする「優先度Ｂのグループ」を設定する。さらにその次に優先度が高いグループとして、共有できるＶＭ数を「８」とする「優先度Ｃのグループ」を設定する。さらにその次に優先度が高いグループ（優先度が最も低いグループ）として、共有できるＶＭ数を「１６」とする「優先度Ｄのグループ」を設定する。
なお、この優先度グループは、優先度Ａ〜Ｄの４つのグループに限定されることなく、ＣＰＵコアを分割できる範囲で、２つ以上の任意の数のグループに設定可能である。
また、ＶＭ１を専用のＣＰＵコアに固定化（ピニング）する技術は、例えば非特許文献１の技術により実現することができる。

【0030】

優先度グループ定義部１２は、各優先度グループに対応する物理リソース（ＣＰＵコア）の情報と、その優先度グループの物理リソース（ＣＰＵコア）において共有するＶＭ数（オーバーコミット率）と、ＶＭ１それぞれがどの優先度グループ（優先度Ａ〜Ｄのグループ）に所属するかを示す情報とを、優先度グループ設定情報１４として記憶部に記憶する。

【0031】

優先度グループ変更部１３は、コントローラ２０から、そのＶＭ１についての優先度グループの変更指示を示す優先度グループ変更情報を受信し、その優先度グループ変更情報で示される、より優先度の高いグループまたはより優先度の低いグループに、そのＶＭ１が所属する優先度グループを変更する。

【0032】

≪コントローラ≫
コントローラ２０は、物理サーバ１０から各ＶＭ１のリソース利用量の情報を取得し、ＶＭ１（仮想ルータ）の性能推定値を計算する。そして、コントローラ２０は、計算したＶＭ１の性能推定値が、性能不足領域、無変更領域、性能過多領域のうちのどの領域に属するのかを判定する。コントローラ２０は、ＶＭ１の性能推定値が、性能不足領域に属すると判定した場合には、よりオーバーコミット率の小さいＣＰＵピニングパターンの優先度グループに変更する指示（優先度グループ変更情報）を物理サーバ１０に送信する。また、コントローラ２０は、ＶＭ１の性能推定値が、性能過多領域に属すると判定した場合には、よりオーバーコミット率の大きいＣＰＵピニングパターンの優先度グループに変更する指示（優先度グループ変更情報）を物理サーバ１０に送信する。

【0033】

このコントローラ２０は、データ取得部２１と、テストツール機能部２２と、学習機能部２３と、性能値推定部２４と、優先度変更判定部２５とを備える。また、コントローラ２０は、入出力部および記憶部（いずれも図示省略）を備える。
入出力部は、情報の送受信を行うための通信インタフェース、および、タッチパネルやキーボード等の入力装置や、モニタ等の出力装置との間で情報の送受信を行うための入出力インタフェースからなる。
また、記憶部は、フラッシュメモリやハードディスク、ＲＡＭ等により構成される。このコントローラ２０の記憶部は、図６に示すように、データ保存ＤＢ２６を備える。このデータ保存ＤＢ２６は、物理サーバ１０から取得した各ＶＭ１のリソース利用量（ＣＰＵ使用量、メモリ使用量、パケット送受信数等）の情報が記憶される。また、このデータ保存ＤＢ２６には、テストツール機能部２２の指示により、物理サーバ１０から取得したＶＭ１ごとのテスト結果の情報が記憶される。

【0034】

データ取得部２１は、物理サーバ１０が収集した各ＶＭ１についてのリソース利用量を取得し、データ保存ＤＢ２６に記憶する。また、データ取得部２１は、物理サーバ１０が実行したテストツールの結果として収集した、リソース利用量等のテスト結果情報を取得し、データ保存ＤＢ２６に記憶する。

【0035】

テストツール機能部２２は、テストツールを起動し、物理サーバ１０にデータ取得開始指示を送信することにより、各ＶＭ１のリソース利用量のデータとそれに対応する性能値（遅延）のデータを物理サーバ１０から取得する。
テストツール機能部２２は、例えば、異なるオーバーコミット率で設定された優先度グループに属するＶＭ１それぞれについて、負荷を所定パターンで変動させ、それにより得られるリソース利用量と、そのときの性能値とをテスト結果情報として取得する。
なお、テストツールを用いる理由は、実性能のデータは、実際のサービス提供時には取得できないことが多いためである。

【0036】

学習機能部２３は、テストツール機能部２２が取得したテストツールの結果データ（テスト結果情報）を用いて、機械学習による分析（例えば、回帰分析学習）を行い、学習結果データを生成する。この学習結果データは、各オーバーコミット率（優先度グループ）に所属するＶＭ１毎に、リソース利用量から性能値を推定するための情報である。

【0037】

性能値推定部２４は、物理サーバ１０から取得した（現時点での）各ＶＭ１のリソース利用量に基づき、学習機能部２３が保持する学習結果データを用いて、ＶＭ１それぞれの性能推定値を計算する。

【0038】

優先度変更判定部２５は、性能値推定部２４が計算したＶＭ１それぞれの性能推定値を用いて、計算したＶＭ１の性能推定値が、性能不足領域、無変更領域、性能過多領域のうちのどの領域に属するのかを判定する。
例えば、優先度変更判定部２５は、ＶＭ１の性能推定値が、性能不足領域に属すると判定した場合には、よりオーバーコミット率の小さいＣＰＵピニングパターンの優先度グループに変更する指示（優先度グループ変更情報）を物理サーバ１０に送信する。また、優先度変更判定部２５は、ＶＭ１の性能推定値が、性能過多領域に属すると判定した場合には、よりオーバーコミット率の大きいＣＰＵピニングパターンの優先度グループに変更する指示（優先度グループ変更情報）を物理サーバ１０に送信する。なお、優先度変更判定部２５は、ＶＭ１の性能推定値が、無変更領域に属すると判定した場合には、優先度グループを変更する指示を物理サーバ１０に送信しない。これにより、そのＶＭ１のその時点での優先度グループへの所属を維持させるようにする。

【0039】

＜処理の流れ＞
次に、ＶＭ性能保証システムＳが実行する処理の流れについて図７および図８を参照して説明する。図７では、ＶＭ１（仮想ルータ）の推定遅延値を算出するために必要となる学習結果データを生成する処理（学習結果データ生成処理）について説明する。また、図８では、ＶＭ１の優先度グループの変更処理について説明する。

【0040】

図７は、本実施形態に係るＶＭ性能保証システムＳが実行する学習結果データ生成処理の流れを示すフローチャートである。

【0041】

まず、物理サーバ１０の優先度グループ定義部１２は、各優先度グループに対応する物理リソース（ＣＰＵコア）において共有するＶＭ数（オーバーコミット率）の情報と、ＶＭ１それぞれがどの優先度グループ（優先度Ａ〜Ｄのグループ）に所属するかを示す情報とを、優先度グループ設定情報１４として記憶部に記憶する（ステップＳ１０）。

【0042】

この優先度グループ設定情報１４では、例えば、図４に示すように、共有できるＶＭ数を「２」とする優先度が最も高い「優先度Ａのグループ」、次に優先度が高く共有できるＶＭ数を「４」とする「優先度Ｂのグループ」、さらにその次に優先度が高く共有できるＶＭ数を「８」とする「優先度Ｃのグループ」、優先度が最も低く共有できるＶＭ数を「１６」とする「優先度Ｄのグループ」が設定される。また、優先度グループ設定情報１４には、物理サーバ１０上のＶＭ１それぞれをどの優先度グループに所属させるかの初期設定の情報が格納させる。
なお、優先度グループ定義部１２は、この優先度グループ設定情報１４を、外部装置（例えば、コントローラ２０やネットワークの管理装置等）から受信することにより取得してもよいし、入出力部（図示省略）を介して情報の入力を受け付けてもよい。

【0043】

次に、コントローラ２０のテストツール機能部２２が、テストツールを起動し（ステップＳ１１）、物理サーバ１０にデータ取得開始指示を送信する（ステップＳ１２）。

【0044】

このデータ取得開始指示を受信すると、物理サーバ１０は、負荷を所定パターンで変更させ、リソース利用量収集部１１が、各ＶＭ１についてのリソース利用量およびそのときの性能値の情報をテスト結果として収集する（ステップＳ１３）。そして、リソース利用量収集部１１は、収集したテスト結果をコントローラ２０に送信する。

【0045】

コントローラ２０のデータ取得部２１は、テスト結果を受信しテスト結果情報としてデータ保存ＤＢ２６に記憶する（ステップＳ１４）。
続いて、コントローラ２０の学習機能部２３が、各ＶＭ１についてのテスト結果情報を用いて、機械学習による分析（例えば、回帰分析学習）を行い、学習結果データを生成する（ステップＳ１５）。

【0046】

このように、ＶＭ性能保証システムＳでは、テストツールを用いて、各優先度グループでのＶＭ１についてリソース利用量に応じた性能値を事前に計測しておくことにより、学習結果データを生成する。この学習結果データを用いて、ＶＭ性能保証システムＳは、リアルタイムに更新される各ＶＭ１のリソース利用量のデータに基づき、性能推定値を計算することができる。

【0047】

次に、ＶＭ性能保証システムＳが実行するＶＭ１の優先度グループの変更処理について説明する。
図８は、本実施形態に係るＶＭ性能保証システムＳが実行する優先度グループ変更処理の流れを示すフローチャートである。
ここでは、物理サーバ１０のリソース利用量収集部１１が、所定の時間間隔で各ＶＭ１のリソース利用量を収集し、コントローラ２０に送信する。そして、コントローラ２０の性能値推定部２４が、学習結果データを用いてＶＭ１の性能推定値を計算する。計算された性能推定値について、優先度変更判定部２５が、性能不足領域、性能過多領域に属するかを判定する。以下、詳細に説明する。
なお、図８の処理以前に、図７で行った物理サーバ１０による優先度グループ設定情報１４の記憶と、コントローラ２０による学習結果データの生成が終わっているものとする。

【0048】

まず、物理サーバ１０のリソース利用量収集部１１は、所定時間が経過したか否かを判定する（ステップＳ２０）。所定時間が経過していない場合には（ステップＳ２０→Ｎｏ）、ステップＳ２０に戻り、所定時間が経過するまで待機する。一方、所定時間が経過した場合には（ステップＳ２０→Ｙｅｓ）、次のステップＳ２１へ進む。つまり、以降の処理は、所定の時間間隔で繰り返し実行されるものである。

【0049】

ステップＳ２１において、物理サーバ１０のリソース利用量収集部１１が、各ＶＭ１についてのリソース利用量の情報を収集し、コントローラ２０に送信する。
コントローラ２０のデータ取得部２１は、取得した各ＶＭ１についてのリソース利用量の情報をデータ保存ＤＢ２６に記憶する（ステップＳ２２）。このステップＳ２２以降の処理は、ＶＭ１毎に行われる。

【0050】

次に、コントローラ２０の性能値推定部２４は、データ保存ＤＢ２６に記憶された各ＶＭ１のリソース利用量に基づき、学習機能部２３が保持する学習結果データを用いて、ＶＭ１それぞれの性能推定値ｘを計算する（ステップＳ２３）。

【0051】

そして、コントローラ２０の優先度変更判定部２５は、性能値推定部２４が計算したＶＭ１の性能推定値が、性能不足領域、無変更領域、性能過多領域のうちのどの領域に属するのかを判定する。ここで、ＶＭ１（仮想ルータ）の性能（遅延）に対する性能推定値ｘを、性能不足領域（ｘ＞８ｍｓ：第１の条件）、無変更領域（４ｍｓ≦ｘ≦８ｍｓ）、性能過多領域（ｘ＜４ｍｓ：第２の条件）と設定しておき、以下の処理により、そのＶＭ１の性能推定値が、性能不足領域に属するのか、または、性能過多領域に属するのかを判定する。具体的には、以下の処理を実行する。

【0052】

優先度変更判定部２５は、ＶＭ１の性能推定値ｘが、ｘ＞８ｍｓ（第１の条件）に該当するか否かを判定する（ステップＳ２４）。そして、優先度変更判定部２５は、第１の条件に該当する場合には（ステップＳ２４→Ｙｅｓ）、性能推定値ｘが性能不足領域にあると判定する。そして、優先度変更判定部２５は、よりオーバーコミット率の小さいＣＰＵピニングパターンの優先度グループに変更する指示（第１の優先度グループ変更情報）を物理サーバ１０に送信する（ステップＳ２５）。

【0053】

物理サーバ１０の優先度グループ変更部１３は、この優先度グループ変更情報を受信すると、当該ＶＭ１の所属する優先度グループを、優先度グループ設定情報１４を参照して確認し、よりオーバーコミット率の小さいＣＰＵピニングパターンの優先度グループに変更する（ステップＳ２６）。この際、優先度グループ変更部１３は、当該ＶＭ１について新たに所属する優先度グループに基づき、優先度グループ設定情報１４を更新する。

【0054】

一方、ステップＳ２４において、第１の条件に該当しない場合には（ステップＳ２４→Ｎｏ）、ステップＳ２７に進む。
ステップＳ２７において、優先度変更判定部２５は、ＶＭ１の性能推定値ｘが、ｘ＜４ｍｓ（第２の条件）に該当するか否かを判定する。そして、優先度変更判定部２５は、第２の条件に該当する場合には（ステップＳ２７→Ｙｅｓ）、性能推定値ｘが性能過多領域にあると判定する。そして、優先度変更判定部２５は、よりオーバーコミット率の大きいＣＰＵピニングパターンの優先度グループに変更する指示（第２の優先度グループ変更情報）を物理サーバ１０に送信する（ステップＳ２８）。

【0055】

物理サーバ１０の優先度グループ変更部１３は、この優先度グループ変更情報を受信すると、当該ＶＭ１の所属する優先度グループを、優先度グループ設定情報１４を参照して確認し、よりオーバーコミット率の大きいＣＰＵピニングパターンの優先度グループに変更する（ステップＳ２９）。この際、優先度グループ変更部１３は、当該ＶＭ１について新たに所属する優先度グループに基づき、優先度グループ設定情報１４を更新する。

【0056】

一方、ステップＳ２７において、第２の条件に該当しない場合には（ステップＳ２７→Ｎｏ）、処理を終える。
優先度変更判定部２５は、ステップＳ２４〜Ｓ２９の処理を、物理サーバ１０（優先度グループ変更部１３）とともに、各ＶＭ１について実行する。

【0057】

以上説明したように、本実施形態に係るＶＭ性能保証システムＳによれば、負荷が小さいＶＭ１が過剰となった物理リソースを確保し続けることがないため、物理サーバ１０のリソース利用効率を高めることができる。また、共有できるＶＭ数の異なる優先度グループを定義し、性能不足もしくは性能過多の場合に動的に優先度グループを変更することで、物理リソースを効率的に活用した上で、ＶＭ１の性能保証を実現することができる。

【0058】

（変形例）
本発明は、上記した実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で変更実施が可能である。例えば、以下のような変形例として実施することもできる。

【0059】

＜変形例１＞
本実施形態では、上記のように、実性能のデータが実際のサービス提供時には取得できないことが多いため、コントローラ２０にテストツール機能部２２（図６参照）を備え、異なる優先度グループに属するＶＭ１の負荷を所定パターンで変動させてテスト結果情報を取得し、性能推定値を計算できるようにした。
これに対し、ＳＬＡ等で規定される性能の種別やシステム構成、アプリケーションの設定等により、各ＶＭ１のリソース利用量からコントローラ２０が性能値をリアルタイムで取得（算出）できる場合には、テストツール機能部２２、学習機能部２３、性能値推定部２４（図６参照）を設けない構成とする。このとき、コントローラ２０の優先度変更判定部２５は、リアルタイムに取得した性能値を用いて、各ＶＭの性能不足、性能過多を判定することにより、優先度グループの変更処理を実行する。

【0060】

＜変形例２＞
また、本実施形態では、コントローラ２０にテストツール機能部２２（図６参照）を設け、テストツールを起動させてテスト結果情報を物理サーバ１０から取得するようにした。このテスト結果情報を用いて、学習機能部２３が学習結果データを生成する替わりに、コントローラ２０が、所定期間の実運用（稼働）での各ＶＭのリソース利用量と性能値のデータを蓄積し、その蓄積データ（過去の実データ）を用いて、学習機能部２３が学習結果データを生成するようにしてもよい。

【0061】

このような本実施形態の変形例１，２によっても、本実施形態と同様に、物理リソースの利用効率を高めつつ、ＶＭ１の性能保証を実現することが可能となる。

【符号の説明】

【0062】

１ ＶＭ（仮想ルータ）
１０ 物理サーバ（コンピュート）
１１ リソース利用量収集部
１２ 優先度グループ定義部
１３ 優先度グループ変更部
１４ 優先度グループ設定情報
２０ コントローラ
２１ データ取得部
２２ テストツール機能部
２３ 学習機能部
２４ 性能値推定部
２５ 優先度変更判定部
２６ データ保存ＤＢ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】