(57)【要約】【課題】オートスケールによってＶＭ／コンテナ数等のリソース割当量を適正に制御する。【解決手段】ネットワーク性能保証システム１０は、サーバに生成されるＶＭ／コンテナＶ１〜Ｖ４（Ｖ１〜Ｖ４）の数及びＶ１〜Ｖ４のリソースを増減するオートスケールを行う。データ収集部１１ａでＶ１〜Ｖ４のリソース割当量（割当量）に応じたリソース動作に係るリソース利用量とＶ１〜Ｖ４に係る通信サービスの性能値とを含む測定データを収集する。学習部１２ｂにより収集測定データの内の性能値から、割当量に相関が高い性能値をモデル性能値とする。推定最適算出部１２ｃで、モデル性能値と、これに対応するリソースに係る性能値との回帰分析で割当量変更に応じた性能の推定値を求め、推定値が、性能値の目標値を満たし且つ割当量が最小となる割当量を算出する。リソース制御部１１ｂでその算出した割当量に応じたオートスケールでＶ１〜Ｖ４のリソースを増減する。【選択図】図１
2020123848.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク接続されたサーバに生成されるＶＭ（Virtual Machine）及びコンテナの何れか一方又は双方であるＶＭ／コンテナの数及び、当該ＶＭ／コンテナのＣＰＵ（Central Processing Unit）及びメモリに代表されるリソースを、リソース割当量に応じて増減するオートスケールを行うネットワーク性能保証システムであって、
複数種類の前記ＶＭ／コンテナと、
前記ＶＭ／コンテナのリソース割当量に応じたリソースの動作を測定して得られるリソース利用量及び、当該ＶＭ／コンテナに係る通信サービスの性能値を含む測定データを収集する収集部と、
前記ＶＭ／コンテナのリソースを前記リソース割当量に応じて増減するオートスケールを行う制御部と
を有する第１サーバを備えると共に、
前記収集部で収集された測定データの内の前記性能値から、前記リソース割当量に相関が高い性能値をモデル性能値として求める学習部と、
前記モデル性能値と、当該モデル性能値に対応する前記リソースの動作に係る性能値との回帰分析により、前記リソース割当量の変更に応じた性能の推定値を求め、この推定値が、前記性能値の目標値を満たし且つ前記リソース割当量が最小となる場合の、リソース割当量を算出する算出部と
を有する第２サーバを備え、
前記制御部は、前記算出されたリソース割当量に応じたオートスケールの実行によって該当ＶＭ／コンテナのリソースを増減する
ことを特徴とするネットワーク性能保証システム。
【請求項２】
前記学習部は、
前記収集部で収集された測定データの中から、当該測定データと前記ＶＭ／コンテナのリソース割当量との相関が予め定められた第１閾値よりも高い測定データを排除する
ことを特徴とする請求項１に記載のネットワーク性能保証システム。
【請求項３】
前記学習部は、
前記排除の後に残った測定データの内、前記ＶＭ／コンテナに係る通信サービスの性能値との相関が予め定められた第２閾値よりも高い測定データを、前記モデル性能値を求めるために用いる
ことを特徴とする請求項２に記載のネットワーク性能保証システム。
【請求項４】
前記算出部は、
前記ＶＭ／コンテナのリソースの数量を予め定められた最小数から最大数の間で可変し、この可変に応じた総当りの数量の組合せ候補を生成し、この生成された組合せ候補毎の数量を合計した総量が小又は大の順番となり、この順番の総量に前記推定値を対応付けた組合せ候補の中から、当該推定値が前記性能値の目標値を満たし且つ当該総量が最小値となる条件を検索し、当該総量の最小値が検索された以降、当該検索を総量が最小値以外の値となった際に終了する第１処理を行う
ことを特徴とする請求項３に記載のネットワーク性能保証システム。
【請求項５】
前記算出部は、
前記ＶＭ／コンテナの稼働中リソースのリソース割当量と、前記推定値が前記性能値を満たし且つ前記終了時に検索された組合せ候補において前記総量が最小であるリソース割当量と、の差分の絶対値が最小である組合せ候補を選択し、この選択された組合せ候補のリソース割当量を前記制御部へ通知する第２処理を行う
ことを特徴とする請求項４に記載のネットワーク性能保証システム。
【請求項６】
前記算出部は、
前記第１処理と前記第２処理を、前記性能値が予め定められた所定値よりも大きくなった場合、又は、一定時間間隔で行う
ことを特徴とする請求項５に記載のネットワーク性能保証システム。
【請求項７】
ネットワーク接続されたサーバに生成されるＶＭ及びコンテナの何れか一方又は双方であるＶＭ／コンテナの数及び、当該ＶＭ／コンテナのＣＰＵ及びメモリに代表されるリソースを、リソース割当量に応じて増減するオートスケールを行うシステムのオートスケール型性能保証方法であって、
前記システムは、複数種類の前記ＶＭ／コンテナが生成された第１サーバと、当該第１サーバに接続された第２サーバとを備え、
前記第１サーバは、
前記ＶＭ／コンテナのリソース割当量に応じたリソースの動作を測定して得られるリソース利用量及び、当該ＶＭ／コンテナに係る通信サービスの性能値を含む測定データを収集するステップと、
前記ＶＭ／コンテナのリソースを前記リソース割当量に応じて増減するオートスケールを行うステップとを実行し、
前記第２サーバは、
前記収集された測定データの内の前記性能値から、前記リソース割当量に相関が高い性能値をモデル性能値として求めるステップと、
前記モデル性能値と、当該モデル性能値に対応する前記リソースの動作に係る性能値との回帰分析により、前記リソース割当量の変更に応じた性能の推定値を求め、この推定値が、前記性能値の目標値を満たし且つ前記リソース割当量が最小となる場合の、リソース割当量を算出するステップとを実行し、
前記第１サーバは、
前記算出されたリソース割当量に応じたオートスケールの実行によって該当ＶＭ／コンテナのリソースを増減するステップを実行する
ことを特徴とするネットワーク性能保証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク接続されたサーバに生成されるＶＭ（Virtual Machine：仮想マシン）及びコンテナの数や、ＣＰＵ（Central Processing Unit）及びメモリ等のリソースのオートスケールを行うネットワーク性能保証システム及びネットワーク性能保証方法に関する。
【背景技術】
【０００２】
ネットワーク性能保証システム（システムともいう）は、ネットワークで接続される物理的なサーバに、１又は複数のＶＭ及びコンテナの何れか一方又は双方を用いた構成となっている。このＶＭ及びコンテナの何れか一方又は双方を、ＶＭ／コンテナと表現する。このＶＭ／コンテナによりＶＮＦ（Network Functions Virtualization：ＶＮＦネットワーク機能仮想化）の構成が成されている。
【０００３】
また、複数のＶＭ／コンテナを用いたネットワークにおける遅延やスループット等の通信サービスの品質を「性能」又は「性能値」という。つまり、性能が良いとは通信サービス品質が良いことを表わし、性能が悪いとは通信サービス品質が悪いことを表わす。
【０００４】
オートスケールとは、サーバ負荷に応じて、自動的にＶＭ／コンテナの数を増減させる機能である。このオートスケールによって、システムのサーバにアクセスが集中したときはＶＭ／コンテナ数を自動で増やし、アクセスが少ないときはＶＭ／コンテナ数を減らすことで、極力最適なＶＭ／コンテナ数でシステムを稼働するようになっている。
【０００５】
オートスケールには、ＶＭ／コンテナ数を増やしてサーバ性能を高めるスケールアウトと、この逆に、ＶＭ／コンテナ数を減らしてサーバ性能を適正にするスケールインがある。更に、オートスケールには、ＶＭ／コンテナのＣＰＵやメモリ等のリソースの追加を行ってサーバ性能を高めるスケールアップと、この逆に、ＶＭ／コンテナのリソースの削除を行ってサーバ性能を適正にするスケールダウンとがある。なお、スケールアウト又はスケールインをスケールアウト／インと表現し、スケールアップ又はスケールダウンをスケールアップ／ダウンと表現する。
【０００６】
上述したシステムのオートスケールの一例として非特許文献１，２の技術が有る。非特許文献１には、ＳＬＯ（サービスレベル目標値又は性能目標値）を意識した性能制御のコンセプトが広く開示されている。一方、非特許文献２における仕様及び機能では、仮想化技術における性能制御手法の既存のオートスケールが、ＶＭ／コンテナ毎に予め規定したリソース利用率の閾値を用いてスケール契機を判断するようになっている。このオートスケールでは、スケールアップ／ダウン或いはスケールアウト／インによるＣＰＵやメモリ等のリソース追加／削除によって、ＶＭ／コンテナへのリソース割当量の変更を実施している。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】M.G. Jaatun,et al.,“SLA-Driven Adaptive Resource Management for Web Applications on a Heterogeneous Compute Cloud”，［online］，2009，［平成３１年１月１６日検索］，インターネット〈URL: http://www.cs.ait.ac.th/~mdailey/papers/Iqbal-RTSLA.pdf〉
【非特許文献２】富士通クラウドテクノロジーズ，“ニフクラのオートスケール”，［online］，2017-2019，［平成３１年１月１６日検索］，インターネット〈URL: https://cloud.nifty.com/service/autoscale.htm〉
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、特許文献２のオートスケール技術では、リソース利用率の閾値と、リソース制御対象のＶＭ／コンテナの選定と、ＶＭ／コンテナの増減等の制御量とを、人が予め適正に規定することが必要となっている。この人による規定は容易に行えず手間暇が掛かり、規定後にオートスケール制御を行ってもＶＭ／コンテナ数やリソース割当量を適正に制御できないという問題が生じる。
【０００９】
また、複数のＶＭ／コンテナで構成されるＶＮＦでは、遅延やスループット等の性能値と、各ＶＭ／コンテナのｖＣＰＵ（仮想ＣＰＵ）数、メモリ量やＶＭ／コンテナ数等のリソース割当量とが複雑に依存し、ボトルネックとなるリソース部分が次のように存在している。
【００１０】
例えば、図９に示すように、ＶＮＦに複数のＶＭ／コンテナＶ１，Ｖ２，…，Ｖｋ，…，Ｖｎがあるとする。この際に、ＶＮＦの性能値ｐが、ＶＭ／コンテナＶ１，Ｖ２，…，Ｖｋ，…，Ｖｎのリソース割当量ｒＶ１，ｒＶ２，…，ｒＶｋ，…，ｒＶｎに依存しているとすれば、性能値ｐは次の関数式（１）で表わされる。
【００１１】
ｐ＝ｆ（ｒＶ１，ｒＶ２，…，ｒＶｋ，…，ｒＶｎ）…（１）
【００１２】
このように性能値ｐが、ＶＭ／コンテナＶ１，Ｖ２，…，Ｖｋ，…，Ｖｎのリソース割当量の関数の場合に、図１０に示すように、ある１つのＶＭ／コンテナＶｋのリソース割当量ｒＶｋだけを増加（例えば３つに増加）させても、ＶＮＦ全体の性能値ｐを向上させることができない。この理由は次の通りである。
【００１３】
この例のように、１つのＶＭ／コンテナＶｋのリソース割当量ｒＶｋだけを３つに増加させても、これ以外の他のＶＭ／コンテナＶ１，Ｖ２，…，Ｖｎは各々１つのみなので、これらのＶＭ／コンテナＶ１，Ｖ２，…，Ｖｎで性能値ｐが不足してボトルネックとなり、ＶＮＦ全体として性能が向上しない。この場合、他のＶＭ／コンテナＶ１，Ｖ２，…，Ｖｎも増加させればよいが、人手によるため、幾つ増やせば良いかが簡単に判らず手間暇が掛かってしまう。
【００１４】
このように、あるＶＭ／コンテナＶｋのリソース割当量ｒＶｋだけを増加させるオートスケールを行っても、ＶＮＦの性能値をＳＬＯ（性能目標値）とすることができない。言い換えれば、オートスケールを行っても、ＶＭ／コンテナ数等のリソース割当量を適正に制御できない。
【００１５】
本発明は、このような事情に鑑みてなされたものであり、オートスケールによってＶＭ／コンテナ数等のリソース割当量を適正に制御できるネットワーク性能保証システム及びネットワーク性能保証方法を提供することを課題とする。
【課題を解決するための手段】
【００１６】
上記課題を解決するための手段として、請求項１に係る発明は、ネットワーク接続されたサーバに生成されるＶＭ（Virtual Machine）及びコンテナの何れか一方又は双方であるＶＭ／コンテナの数及び、当該ＶＭ／コンテナのＣＰＵ（Central Processing Unit）及びメモリに代表されるリソースを、リソース割当量に応じて増減するオートスケールを行うネットワーク性能保証システムであって、複数種類の前記ＶＭ／コンテナと、前記ＶＭ／コンテナのリソース割当量に応じたリソースの動作を測定して得られるリソース利用量及び、当該ＶＭ／コンテナに係る通信サービスの性能値を含む測定データを収集する収集部と、前記ＶＭ／コンテナのリソースを前記リソース割当量に応じて増減するオートスケールを行う制御部とを有する第１サーバを備えると共に、前記収集部で収集された測定データの内の前記性能値から、前記リソース割当量に相関が高い性能値をモデル性能値として求める学習部と、前記モデル性能値と、当該モデル性能値に対応する前記リソースの動作に係る性能値との回帰分析により、前記リソース割当量の変更に応じた性能の推定値を求め、この推定値が、前記性能値の目標値を満たし且つ前記リソース割当量が最小となる場合の、リソース割当量を算出する算出部とを有する第２サーバを備え、前記制御部は、前記算出されたリソース割当量に応じたオートスケールの実行によって該当ＶＭ／コンテナのリソースを増減することを特徴とするネットワーク性能保証システムである。
【００１７】
請求項７に係る発明は、ネットワーク接続されたサーバに生成されるＶＭ及びコンテナの何れか一方又は双方であるＶＭ／コンテナの数及び、当該ＶＭ／コンテナのＣＰＵ及びメモリに代表されるリソースを、リソース割当量に応じて増減するオートスケールを行うシステムのオートスケール型性能保証方法であって、前記システムは、複数種類の前記ＶＭ／コンテナが生成された第１サーバと、当該第１サーバに接続された第２サーバとを備え、前記第１サーバは、前記ＶＭ／コンテナのリソース割当量に応じたリソースの動作を測定して得られるリソース利用量及び、当該ＶＭ／コンテナに係る通信サービスの性能値を含む測定データを収集するステップと、前記ＶＭ／コンテナのリソースを前記リソース割当量に応じて増減するオートスケールを行うステップとを実行し、前記第２サーバは、前記収集された測定データの内の前記性能値から、前記リソース割当量に相関が高い性能値をモデル性能値として求めるステップと、前記モデル性能値と、当該モデル性能値に対応する前記リソースの動作に係る性能値との回帰分析により、前記リソース割当量の変更に応じた性能の推定値を求め、この推定値が、前記性能値の目標値を満たし且つ前記リソース割当量が最小となる場合の、リソース割当量を算出するステップとを実行し、前記第１サーバは、前記算出されたリソース割当量に応じたオートスケールの実行によって該当ＶＭ／コンテナのリソースを増減するステップを実行することを特徴とするネットワーク性能保証方法である。
【００１８】
請求項１の構成及び請求項７の方法によれば、少ないリソース割当量でのオートスケールの実行により、ＶＭ／コンテナにおいて無駄なリソースが少なくなるようにリソース割当を行うことができる。このため、オートスケールによってＶＭ／コンテナ数等のリソース割当量を適正に制御できる。
【００１９】
請求項２に係る発明は、前記学習部が、前記収集部で収集された測定データの中から、当該測定データと前記ＶＭ／コンテナのリソース割当量との相関が予め定められた第１閾値よりも高い測定データを排除することを特徴とする請求項１に記載のネットワーク性能保証システムである。
【００２０】
この構成によれば、次のような作用効果が得られる。ＶＭ／コンテナのリソースをリソース割当量で変更する際に、この変更に釣られて変わってしまう測定データ（リソース利用量が該当）は、モデル性能値を求める場合に不適正となる。この不適正な測定データは、リソース割当量に依存するリソースの測定データとの相関が高い場合に、多くなる特性がある。このため、本発明のように、不適正な測定データを事前に排除すれば、モデル性能値を推定できる精度を高めることができる。
【００２１】
請求項３に係る発明は、前記学習部が、前記排除の後に残った測定データの内、前記ＶＭ／コンテナに係る通信サービスの性能値との相関が予め定められた第２閾値よりも高い測定データを、前記モデル性能値を求めるために用いることを特徴とする請求項２に記載のネットワーク性能保証システムである。
【００２２】
この構成によれば、次のような作用効果が得られる。実際に、ＶＭ／コンテナに係る通信サービスの性能値を計算する場合、測定データとの依存関係を反映するパラメータを使用しなければ、正しい性能値を得ることができない。このため、性能値を推定するために使用可能なパラメータとして、前述の排除後に残った測定データから、性能値との相関が第２閾値よりも高い測定データのみを用いるようにした。このため、ＶＭ／コンテナに係る通信サービスの正しい性能値を得ることができる。
【００２３】
請求項４に係る発明は、前記算出部が、前記ＶＭ／コンテナのリソースの数量を予め定められた最小数から最大数の間で可変し、この可変に応じた総当りの数量の組合せ候補を生成し、この生成された組合せ候補毎の数量を合計した総量が小又は大の順番となり、この順番の総量に前記推定値を対応付けた組合せ候補の中から、当該推定値が前記性能値の目標値を満たし且つ当該総量が最小値となる条件を検索し、当該総量の最小値が検索された以降、当該検索を総量が最小値以外の値となった際に終了する第１処理を行うことを特徴とする請求項３に記載のネットワーク性能保証システムである。
【００２４】
この構成によれば、推定値が前記性能値の目標値を満たし且つ当該総量が最小値となる条件を全て検索した以降に、総量が最小値以外の値となった際に検索を終了するようにした。このため、総当りの数量の組合せ候補を全て検索する処理に比べ、大幅に検索処理を削減できる。
【００２５】
請求項５に係る発明は、前記算出部が、前記ＶＭ／コンテナの稼働中リソースのリソース割当量と、前記推定値が前記性能値を満たし且つ前記終了時に検索された組合せ候補において前記総量が最小であるリソース割当量と、の差分の絶対値が最小である組合せ候補を選択し、この選択された組合せ候補のリソース割当量を前記制御部へ通知する第２処理を行うことを特徴とする請求項４に記載のネットワーク性能保証システムである。
【００２６】
この構成によれば、次の作用効果が得られる。ＶＭ／コンテナのリソースに対してリソース割当量を変更すると悪影響が出るので、通信サービスとして途中でリソース割当量を頻繁に変えると、通信サービスの性能値が低下する。しかし、本発明では、ＶＭ／コンテナのリソースにおける総当り数量の組合せ候補の中から、現在、稼働中リソースのリソース割当量に最も近いリソース割当量を選択するようにした。このため、途中でリソース割当量を変えても、性能値の低下を防止又は抑制できる。
【００２７】
請求項６に係る発明は、前記算出部が、前記第１処理と前記第２処理を、前記性能値が予め定められた所定値よりも大きくなった場合、又は、一定時間間隔で行うことを特徴とする請求項５に記載のネットワーク性能保証システムである。
【００２８】
この構成によれば、突然ユーザ数が増加して通信サービスの性能値（遅延やスループット等）が大きくなった場合に、上記請求項４記載の第１処理と、請求項５記載の第２処理を行うことで対応できる。
【発明の効果】
【００２９】
本発明によれば、オートスケールによってＶＭ／コンテナ数等のリソース割当量を適正に制御するネットワーク性能保証システム及びネットワーク性能保証方法を提供することができる。
【図面の簡単な説明】
【００３０】
【図１】本発明の実施形態に係るネットワーク性能保証システムの構成を示すブロック図である。
【図２】オートスケール型性能保証システムのコントローラの学習部が学習結果としてのモデルサービス性能値を得る処理を説明するブロック図である。
【図３】コントローラの推定最適算出部が各ＶＭ／コンテナのＶＭ／コンテナ数の組合せ候補毎にサービス性能推定値を得る処理を説明するブロック図である。
【図４】各ＶＭ／コンテナのＶＭ／コンテナ数の組合せ候補毎のＶＭ／コンテナ数の合計値である総量を含む表である。
【図５】各ＶＭ／コンテナのＶＭ／コンテナ数の組合せ候補毎のＳＬＯが５０ｍｓ以下で且つ総量が最小の条件のものを○で示す図である。
【図６】現在のＶＭ／コンテナの組合せ候補を示す表である。
【図７】ＶＭ／コンテナの上記条件のＶＭ／コンテナ数の組合せ候補におけるユークリッド距離を含む表である。
【図８】本実施形態に係るネットワーク性能保証システムの動作を説明するためのシーケンス図である。
【図９】ＶＮＦ内の複数のＶＭ／コンテナを示す図である。
【図１０】ＶＮＦ内の複数のＶＭ／コンテナの内、特定のＶＭ／コンテナをオートスケールで増加する様態を示す図である。
【発明を実施するための形態】
【００３１】
以下、本発明の実施形態を、図面を参照して説明する。
＜実施形態の構成＞
図１は、本発明の実施形態に係るネットワーク性能保証システムの構成を示すブロック図である。
図１に示すネットワーク性能保証システム（システム）１０は、ネットワークで接続される複数のコンピュート１１，…，１１（後述）に、コントローラ１２がネットワーク接続されて構成されている。
【００３２】
コンピュート１１は、データ収集部１１ａと、リソース制御部１１ｂと、複数種類のＶＭ／コンテナＶ１〜Ｖ４とを備えて構成されている。
【００３３】
コントローラ１２は、データ収集部１２ａと、学習部１２ｂと、推定最適算出部１２ｃとを備えて構成されている。データ収集部１２ａ及び学習部１２ｂは、ＤＢ（Data Base）１３に接続されている。
【００３４】
各コンピュート１１及びコントローラ１２は、物理サーバ（サーバ）によって構成されている。但し、内部に仮想的に作られたＶＭ／コンテナＶ１〜Ｖ４が動くサーバを、コンピュート１１と定義している。コントローラ１２からＶＭ／コンテナを増加又は削減する指示を出し、この指示に応じてコンピュート１１がオートスケールによって、内部にＶＭ／コンテナＶ１〜Ｖ４を増設又は減設するようになっている。なお、ＶＭ／コンテナＶ１〜Ｖ４は、Ｖ１〜Ｖ４とも表現する。
【００３５】
なお、コンピュート１１は、請求項記載の第１サーバを構成する。コントローラ１２は、請求項記載の第２サーバを構成する。データ収集部１１ａ，１２ａは、請求項記載の収集部を構成する。リソース制御部１１ｂは、請求項記載の制御部を構成する。学習部１２ｂは、請求項記載の学習部を構成する。推定最適算出部１２ｃは、請求項記載の算出部１２ｃを構成する。
【００３６】
システム１０においては、コンピュート１１のＣＰＵやメモリ等のリソース及び、コンピュート１１内に生成された各ＶＭ／コンテナＶ１〜Ｖ４のリソースへの割当量（リソース割当量）を、コントローラ１２の制御に応じて変更している。例えば、ネットワークにおける遅延やスループット等の通信サービスの品質を提供するためのサービス性能（又はサービス性能値）が低下した際に、リソース割当量を変更してリソースを追加している。なお、サービス性能を性能、サービス性能値を性能値とも称す。
【００３７】
本発明では、一定時間毎又はサービス性能値をトリガとしてリソース割当量を変更する際に、リソース割当量が最小となるＶＭ／コンテナＶ１〜Ｖ４のリソース割当の組合せを、推定計算により最適に検索（推定最適検索）する。この推定最適検索で得られたリソース割当量でリソース割当を実行するようにし、この実行により、通信サービス性能の保証が可能なシステム１０を実現している。
【００３８】
このシステム１０では、本発明の特徴であるデータ収集フェーズと、学習フェーズと、運用フェーズとの３段階の処理が行われる。最初に、３段階のフェーズ処理の概要を説明する。
【００３９】
データ収集フェーズでは、各ＶＭ／コンテナＶ１〜Ｖ４を用いたネットワークにおける通信のサービス性能値と、コンピュート１１のリソース及び各ＶＭ／コンテナＶ１〜Ｖ４のリソースの利用量（リソース利用量）と、各ＶＭ／コンテナＶ１〜Ｖ４のリソース割当量とのデータを収集する処理が行われる。
【００４０】
但し、コンピュート１１のリソース利用量とは、コンピュート１１を構成する物理サーバのＣＰＵ使用量、メモリ使用量、パケット送受信数、補助記憶装置であるストレージＩＯ（入出力）などである。各ＶＭ／コンテナＶ１〜Ｖ４のリソース利用量とは、各ＶＭ／コンテナＶ１〜Ｖ４のｖＣＰＵ使用量、メモリ使用量、パケット送受信数、ストレージＩＯ数、ＶＭ／コンテナ数などである。
【００４１】
学習フェーズでは、サービス性能値とリソース割当量との関係を回帰分析によって学習する処理が行われる。
【００４２】
運用フェーズでは、リソース割当量を変更した場合のサービス性能値を学習の結果から推定することにより、ＳＬＯ（サービスレベル目標値又は性能目標値）に最も近いサービス性能推定値（性能推定値ともいう）を得る。この性能推定値は、サービス性能値を推定するための値である。更に、運用フェーズでは、性能推定値に応じて、ＶＭ／コンテナＶ１〜Ｖ４へのリソース割当量が最小となるリソース割当の組合せを検索（推定最適検索）し、この検索されたリソース割当量に応じたオートスケールにより、リソース割当を変更する処理が行われる。
【００４３】
次に、３段階のフェーズ処理の詳細な説明を行う。システム１０において、リソース割当量を最適に変更して通信のサービス性能を向上させるためには、まず、サービスを構成するＶＭ／コンテナＶ１〜Ｖ４が生成されたことを契機又は一定時間間隔を契機に、コントローラ１２がコンピュート１１にデータ収集を指示する。この指示に応じてコンピュート１１のデータ収集部１１ａが、各ＶＭ／コンテナＶ１〜Ｖ４のリソース割当量を変更しながら、変更後の割当量に応じたリソース動作時の測定データを収集する。この収集された測定データは、コントローラ１２のデータ収集部１２ａへ通知され、ＤＢ１３に記憶される。
【００４４】
学習部１２ｂは、ＤＢ１３に記憶された測定データを基に学習フェーズの処理を次のように行う。
【００４５】
学習部１２ｂは、図２に示すステップＳａにおいて、ＤＢ１３に記憶された測定データから、各ＶＭ／コンテナＶ１〜Ｖ４のリソース割当量に依存する測定データを、次のように排除する。但し、ＤＢ１３の測定データは、Ｖ１〜Ｖ４のリソース割当量に応じたリソース利用量（例えばＶＭ／コンテナ数）等が含まれている。この際、測定データは、上述したようにリソース割当量が変更されながら収集されるので、変更に応じたデータとなる。例えば、図２の表２１に示すように、測定データａ，ｂ，ｃ，ｄ，ｅであるとする。
【００４６】
学習部１２ｂは、リソース割当量をｙとし、測定データをｘとして、ｙとｘとの２つのデータの関係を示す標本共分散Ｓｘｙと、２つのデータのバラツキの大きさを表わす標本標準偏差Ｓｘ，Ｓｙとを用いて、２つのデータの相関関係を示す標本相関係数ｒを次式（２）から算出する。なお、標本共分散は共分散、標本標準偏差は標準偏差、標本相関係数は相関係数とも称す。
【００４７】
ｒ＝Ｓｘｙ／ＳｘＳｙ  …（２）
【００４８】
式（２）により算出された相関係数ｒは、図２の表２１に示すように、測定データのａが「０．６」、ｂが「０．１」、ｃが「０．０」、ｄが「０．１」、ｅが「０．８」になったとする。
【００４９】
次に、学習部１２ｂは、測定データａ〜ｅから、各ＶＭ／コンテナＶ１〜Ｖ４のリソース割当量に依存する測定データを排除する。この排除は、予め定められた第１閾値（例えば０．２）を超える相関係数ｒの測定データａ＝「０．６」、ｅ＝「０．８」を排除する。つまり、リソース割当量に対して所定以上大きな相関関係を有する測定データａ，ｅが排除されることになる。表２１に示すように、排除する測定データには「１」、排除しない測定データには「０」を付す。
【００５０】
ここで、測定データ（上記では測定データａ，ｅ）を排除する理由を説明する。適正なサービス性能値を得るために推定されるサービス性能推定値は、図３の表２３に示すように、Ｖ１〜Ｖ４のＶＭ／コンテナ数の組合せ候補（「２，２，２，２」〜「４，４，４，４」）としてのリソース割当量（ＶＭ／コンテナ数）を、次の関数式（３）に当て嵌めながら求める。
【００５１】
性能推定値＝ｆ（リソース利用量，リソース割当量）  …（３）
【００５２】
この場合、表２３に示すように、Ｖ１〜Ｖ４のＶＭ／コンテナ数が「４，４，４，４」のように多ければ、サービス性能推定値である遅延が（性能が）１０ｍｓと良くなる。一方、ＶＭ／コンテナ数が「２，２，２，２」のように少なければ、遅延が１００ｍｓと悪くなる傾向がある。
【００５３】
しかし、上式（３）では、性能推定値を決める要素として、リソース割当量の他に、リソース利用量も存在する。このため、リソース割当量（ＶＭ／コンテナ数）を変えた際に、この変更に釣られてリソース利用量（ＶＭ／コンテナ数）が変わってしまう。この場合、リソース利用量とリソース割当量との何れの影響で性能推定値が変わったのか判別できなくなる。
【００５４】
そこで、式（３）からリソース利用量を事前に排除しておきたい。リソース利用量は、Ｖ１〜Ｖ４へのリソース割当量と、この割当量に依存するリソースの測定データとの相関関係が大きい場合に、リソース利用量が多くなる特性がある。
【００５５】
そこで、上述したように、Ｖ１〜Ｖ４のリソース割当量ｙと各測定データｘとの相関係数ｒ（図２の表２１参照）が、第１閾値「０．２」を超えた測定データａ＝「０．６」、ｅ＝「０．８」を排除すれば、リソース利用量が上式（３）から排除されることになる。この場合、式（３）において、リソース割当量のみとなるので、リソース割当量のみに依存した適正なサービス性能推定値を得ることができる。
【００５６】
このように処理して、図２のステップＳａでの排除後に残った測定データｂ，ｃ，ｄは、ＤＢ１３に記憶される。
【００５７】
次に、学習部１２ｂは、図２のステップＳｂにおいて、上記残った測定データｂ，ｃ，ｄの各々について、表２２に示すように、後述の標本相関係数ｒ１を計算し、相関が認められた測定データｂ，ｃを、サービス性能の回帰分析の入力測定データとして定義する。
【００５８】
即ち、学習部１２ｂは、上記データ収集フェーズでＤＢ１３に記憶されたサービス性能値と測定データｂ〜ｄとの相関係数ｒ１を求める。この相関係数ｒ１は、表２２に示すように、測定データのｂが「０．８」、ｃが「０．５」、ｄが「０．１」になったとする。
【００５９】
学習部１２ｂは、相関係数ｒ１が、予め定められた第２閾値「０．４」を超えた測定データｂ＝「０．８」、ｃ＝「０．５」を、後述のサービス性能値の回帰分析に利用する。利用する測定データには「１」、利用しない測定データには「０」を付す。この利用される相関係数ｒ１の高い測定データｂ，ｃは、入力測定データｂ，ｃとして、サービス性能値と共に、ＤＢ１３に記憶する。
【００６０】
ここで、上述したサービス性能値と測定データｂ〜ｄとの相関係数ｒ１を求める理由について説明する。実際にサービス性能値を計算する場合、測定データとの依存関係を反映するパラメータを使用しなければ、正しいサービス性能値を得ることができない。このため、サービス性能値を推定するために使用可能なパラメータとして、測定データｂ〜ｄから測定データｂ，ｃのみを取り出すことを目的として、上記相関係数ｒ１を計算する必要がある。
【００６１】
次に、学習部１２ｂは、図２のステップＳｃにおいて、入力測定データｂ，ｃを用いて、モデルとしてのサービス性能値（モデルサービス性能値）を推定するための回帰分析を行い、この結果得られる学習結果としてのモデルサービス性能値をＤＢ１３に保存する。但し、回帰分析には、ＳＶＲ（Support Vector Regression：サポートベクター回帰）等を利用する。なお、モデルサービス性能値は請求項記載のモデル性能値を構成する。
【００６２】
上記学習結果としての相関係数ｒ１の高い測定データ（入力測定データ）ｂ，ｃに係るモデルサービス性能値と、リソース割当量とを用いれば、次の運用フェーズにおいて適正なサービス性能推定値が得られる。
【００６３】
運用フェーズにおいて、推定最適算出部１２ｃは、オートスケールで実行されるスケールアウト／イン又はスケールアップ／ダウンの場合に、リソース割当量（ＶＭ／コンテナ数）の組合せ候補を下記のように生成する。
【００６４】
スケールアウト／インの場合、推定最適算出部１２ｃは、図３のステップＳｄにおいて、表２３に示すＶ１〜Ｖ４のリソース割当量としてのＶＭ／コンテナ数を、例えば最小数「２」、最大数「４」とし、これをステップ数の例えば「２」ずつ順次変えながら、ＶＭ／コンテナ数（リソース割当量）の総当りの組合せ候補（「２，２，２，２」〜「４，４，４，４」）を生成する。
【００６５】
スケールアップ／ダウンの場合、推定最適算出部１２ｃは、Ｖ１〜Ｖ４のリソース割当量としての図示せぬリソース割当セット数（表２３のＶＭ／コンテナ数を参照）を、例えば最小「２」、最大「４」とし、これをステップ数の例えば「２」ずつ順次変えながら、リソース割当セット数（リソース割当量）の総当りの組合せ候補（「２，２，２，２」〜「４，４，４，４」）を生成する。
これらの組合せ候補の生成は、スケールアウト／インの場合を代表して説明する。
【００６６】
次に、推定最適算出部１２ｃは、図３のステップＳｅにおいて、上記ＶＭ／コンテナ数毎に生成した各組合せ候補で、ＤＢ１３内の入力測定データｂ，ｃに応じた現時点におけるリソースのリアルタイムのサービス性能値（ＲＴサービス性能値という）を取得する。
【００６７】
次に、推定最適算出部１２ｃは、上記組合せ候補毎に順次取得されるＲＴサービス性能値と、ＤＢ１３に記憶された学習結果としてのモデルサービス性能値との関係から回帰分析を行う。この回帰分析により、Ｖ１〜Ｖ４の組合せ候補毎に、リソース割当量（ＶＭ／コンテナ数）の変更に応じたサービス性能を推定する。この推定によって、表２４に示す組合せ候補毎のサービス性能推定値（ターゲット）を求める。
【００６８】
ところで、上記組合せ候補は、ＶＭ／コンテナ数が例のように「２」と「４」の２種類でも組合せ数が多いが、推定最適検索の処理を行う上で、出来るだけ少ない試行回数で上記ターゲットを絞り込めればよい。そこで、次の処理を行うようにした。
【００６９】
推定最適算出部１２ｃは、図４の表２５に示すように、Ｖ１〜Ｖ４のＶＭ／コンテナ数の組合せ候補毎の合計値を総量として求める。例えば、ＶＭ／コンテナ数の組合せ候補0が「２，２，２，２」の場合の合計値は「８」なので、総量が「８」となる。この総量が少ない程に、リソースであるＶＭ／コンテナ数が少ないので、無駄なリソースが少なくなる。
【００７０】
次に、推定最適算出部１２ｃは、サービス性能推定値がＳＬＯ（性能目標値）以下で（言い換えれば性能目標値を満たしており）、且つ、総量が最小のＶＭ／コンテナ数（リソース割当量）となる組合せ候補を検索する。この検索された組合せ候補が、最適なリソース割当量となる。
【００７１】
例えば、図５の表２６に示すように、ＳＬＯが５０ｍｓであるとする。この場合、性能推定値である遅延が５０ｍｓ以下で、且つ総量が最小となる組合せ候補を検索する。総量は、表２６の上から小さい順に配列してある。なお、この逆に大きい順に配列してもよい。
【００７２】
推定最適算出部１２ｃは、表２６に示す性能推定値（遅延）が５０ｍｓ以下の遅延を検索する。この例の場合、ＶＭ／コンテナ数が矢印Ｙ１で指示する「２，４，２，４」の場合に遅延５０ｍｓのものが初めて検索される。この時点で、初検索された遅延５０ｍｓの場合の総量「１２」が最小であるため、遅延５０ｍｓ以下且つ最小の総量「１２」となる組合せ候補が確定する。この確定した組合せ候補のＳＬＯ比較の欄に○を付す。
【００７３】
更に、上記確定後、最小の総量「１２」を検索しながら、確定した遅延５０ｍｓ以下且つ最小の総量「１２」となる組合せ候補が順次検索される都度、ＳＬＯ比較の欄に順次○を付す。この検索中に、表２６の例では、矢印Ｙ２で指示する総量が「１２」の次の「１４」となった時点、つまり、最小値を超えた時点で検索動作が終了する。この検索では、遅延５０ｍｓ以下且つ最小の総量「１２」となるＶＭ／コンテナ数（リソース割当量）の組合せ候補が、○を付した通り４つあったとする。
【００７４】
ここで、Ｖ１〜Ｖ４のＶＭ／コンテナ数は、出来るだけ変更が少ない方がリソースの揺動が少なくなり性能目標値に影響が少ないので、極力、ＶＭ／コンテナ数の変更を回避したい。Ｖ１〜Ｖ４のＶＭ／コンテナ数が、例えば図６の表２７に示す「２，２，２，４」で運用されている場合に、例えばＶ４の「４」を減少、Ｖ１の「２」を増加する等の変更を回避する必要がある。そこで、ＶＭ／コンテナ数の変更が出来るだけ少ない組合せ候補を検索する必要がある。この検索を次のようにユークリッド距離を用いて行うようにした。
【００７５】
推定最適算出部１２ｃは、現在のＶＭ／コンテナＶ１〜Ｖ４のリソース割当量（ＶＭ／コンテナ数）と、上記で求めた性能推定値がＳＬＯ以下で、且つ、総量が最小のリソース割当量（ＶＭ／コンテナ数）と、のユークリッド距離が最小となる組合せ候補を算出する。
【００７６】
ここで、現在のＶＭ／コンテナＶ１，…，Ｖｎ）のリソース割当量（ｒＶ１，ｒＶ２，…，ｒＶｎ）と、組合せ候補（ｒ′Ｖ１，ｒ′Ｖ２，…，ｒ′Ｖｎ）とのユークリッド距離ｄが最小となる組合せ候補は、次式（４）でユークリッド距離ｄを求めて得られる。
【００７７】
ｄ＝√｛（ｒＶ１−ｒ′Ｖ１）２＋（ｒＶ２−ｒ′Ｖ２）２＋…＋（ｒＶｎ−ｒ′Ｖｎ）２｝  …（４）
【００７８】
この式（４）を用いてユークリッド距離ｄを次のように求める。即ち、図６の表２７に示す現在のＶ１〜Ｖ４の組合せ「２，２，２，４」と、図７の表２８の１行目に示す組合せ候補「２，４，２，４」とのユークリッド距離ｄは、（２−２）２＋（２−４）２＋（２−２）２＋（４−４）２の計算結果である平方根を計算した結果の「４」となる。この「４」を距離ｄの欄に記載する。以降同様に、２行目〜４行目を計算すると、各々が「１２」となる。
【００７９】
この結果、推定最適算出部１２ｃは、表２８に示すユークリッド距離ｄが最小となる１行目の組合せ候補のＶＭ／コンテナ数「２，４，２，４」を、ＶＭ／コンテナＶ１〜Ｖ４のリソース割当量として採用する。
【００８０】
この採用されたＶ１〜Ｖ４のリソース割当量（ＶＭ／コンテナ数）「２，４，２，４」は、コンピュート１１のリソース制御部１１ｂへ通知される。リソース制御部１１ｂは、ＶＭ／コンテナＶ１〜Ｖ４のリソースであるＶＭ／コンテナ数を、リソース割当量の「２，４，２，４」とする制御を行う。この制御によって、システム１０における通信サービス性能の最適な保証が可能となる。
【００８１】
＜実施形態の動作＞
次に、本実施形態に係るネットワーク性能保証システムの動作を、図８のシーケンス図を参照して説明する。
【００８２】
ステップＳ１において、コントローラ１２のデータ収集部１２ａに、コンピュート１１から各ＶＭ／コンテナＶ１〜Ｖ４（図１）が生成されたことが通知されたとする。この通知を受けたデータ収集部１２ａは、ステップＳ２において、コンピュート１１にデータ収集開始指示を行う。
【００８３】
この指示を受けたコンピュート１１のデータ収集部１１ａは、ステップＳ３において、上記生成された各ＶＭ／コンテナＶ１〜Ｖ４の数や、遅延やスループット等のリソースの性能値のデータ収集を開始する。
【００８４】
このデータ収集部１１ａは、ステップＳ４において、各ＶＭ／コンテナＶ１〜Ｖ４のリソースを追加又は削除して増減する指示（リソース割当指示）を、リソース制御部１１ｂに行う。ステップＳ５において、リソース制御部１１ｂは、その指示に応じてＶ１〜Ｖ４のリソースを増減するリソース割当の制御を行う。この制御では、リソースとしてのＶ１〜Ｖ４のＶＭ／コンテナ数が定められ、この際のサービス性能値である遅延の測定データも求められるとする。例えば、図２の表２１に示した測定データａ〜ｅが求められる。この他に、物理サーバ全体のＣＰＵ使用量、ＶＭ／コンテナ個別のＣＰＵ使用量やリソース割当量等のリソースの測定データも得られる。
【００８５】
図８のステップＳ６において、リソース制御部１１ｂは、上記リソース割当により定まったＶＭ／コンテナ数とサービス性能値の測定データをデータ収集部１１ａに通知する。
【００８６】
データ収集部１１ａは、ステップＳ７において、その通知された測定データを収集し、この収集データを、ステップＳ８において、コントローラ１２のデータ収集部１２ａへ転送する。この転送された収集データは、ＤＢ１３（図１）に記憶される。
【００８７】
上記ステップＳ４〜Ｓ８の処理は、次のように繰り返される。例えば、図３の表２３に示すＶ１〜Ｖ４のリソース割当量としてのＶＭ／コンテナ数を、最小「２」、最大「４」とし、これをステップ数「２」ずつ順次変えながら、ＶＭ／コンテナ数の総当りの組合せ候補（「２，２，２，２」〜「４，４，４，４」）を生成する。この繰り返し生成において、リソースの測定データが収集されてデータ収集部１２ａに通知され、ＤＢ１３に記憶される。
【００８８】
上記ステップＳ４〜Ｓ８の処理の繰り返しにより、様々なパターンのデータが所定数収集されると、コンピュート１１のデータ収集部１１ａからコントローラ１２のデータ収集部１２ａへデータ収集完了が通知される（ステップＳ９）。この通知をデータ収集部１２ａが受けた時にデータ収集フェーズが終了する。
【００８９】
上記データ収集完了を受信したデータ収集部１２ａは、ステップＳ１０において、学習部１２ｂに学習フェーズでの計算を依頼する。
【００９０】
依頼を受けた学習部１２ｂは、ステップＳ１１において、ＤＢ１３に記憶された収集データを基に、次のように回帰分析を行う。
【００９１】
即ち、学習部１２ｂは、まず、ＤＢ１３に記憶された図２の表２１に示す測定データａ〜ｅと、上記ステップＳ５のリソース割当で用いられたリソース割当量との相関係数ｒを求める。次に、第１閾値「０．２」を超える相関係数ｒの測定データａ，ｅを排除する。この排除後に残った図２の表２２に示す測定データｂ，ｃ，ｄと、上記データ収集フェーズでＤＢ１３に記憶されたサービス性能値との相関係数ｒ１を求める。この相関係数ｒ１が第２閾値「０．４」を超えた測定データｂ，ｃを用いて回帰分析を行う。この回帰分析により、学習結果としてのモデルサービス性能値が得られる。
【００９２】
次に、学習部１２ｂは、図８に示すステップＳ１２において、上記回帰分析で得られた学習結果としてのモデルサービス性能値を推定最適算出部１２ｃに通知する。推定最適算出部１２ｃは、ステップＳ１３において、その学習結果のモデルサービス性能値をＤＢ１３に保存する。この保存により学習フェーズが終了する。
【００９３】
上記モデルサービス性能値の保存後、推定最適算出部１２ｃは、ステップＳ１４において、運用開始指示をコンピュート１１へ通知する。この通知を受けたコンピュート１１のデータ収集部１１ａは、ステップＳ１５において、ＶＭ／コンテナＶ１〜Ｖ４からリソース運用時の測定データを収集し、この収集データを、ステップＳ１６において、コントローラ１２のデータ収集部１２ａへ転送する。この転送された収集データは、ステップＳ１７において、データ収集部１２ａから推定最適算出部１２ｃへ通知される。
【００９４】
ステップＳ１８において、推定最適算出部１２ｃは、推定最適検索処理を次のように行う。但し、運用フェーズにおいて、スケールアウト／インでリソース割当が実行されるとする。まず、推定最適算出部１２ｃは、図３の表２３に示すＶ１〜Ｖ４のリソース割当量としてのＶＭ／コンテナ数の総当りの組合せ候補（「２，２，２，２」〜「４，４，４，４」）を生成する。
【００９５】
次に、推定最適算出部１２ｃは、上記組合せ候補毎に、ＤＢ１３内の入力測定データｂ，ｃに応じたリソースのリアルタイムのサービス性能値であるＲＴサービス性能値と、上記ステップＳ１３でＤＢ１３に記憶された学習結果としてのモデルサービス性能値との関係から回帰分析を行う。この回帰分析により、図３の表２４に示す組合せ候補毎にサービス性能推定値（遅延）が求められる。
【００９６】
次に、推定最適算出部１２ｃは、図４の表２５に示す組合せ候補毎の合計値を総量として求める。総量が少ない程に無駄なリソースが少なくなる。次に、推定最適算出部１２ｃは、図５の表２６に示す性能推定値がＳＬＯ（５０ｍｓ）以下で、且つ、総量が最小のＶＭ／コンテナ数となる組合せ候補を検索する。この検索によりＳＬＯ比較の欄に○を付したように組合せ候補が４つあったとする。
【００９７】
ここで、Ｖ１〜Ｖ４のＶＭ／コンテナ数が、図６の表２７に示す組合せ「２，２，２，４」で運用されている場合に、この組合せ「２，２，２，４」と、図７の表２７の各行の組合せ候補「２，４，２，４」とのユークリッド距離ｄを算出する。このユークリッド距離ｄが最小「４」となる１行目の組合せ候補「２，４，２，４」を、ＶＭ／コンテナＶ１〜Ｖ４のリソース割当量であるＶＭ／コンテナ数として採用する。
【００９８】
推定最適算出部１２ｃは、ステップＳ１９において、その採用されたＶ１〜Ｖ４のリソース割当量（ＶＭ／コンテナ数）の「２，４，２，４」を、コンピュート１１のリソース制御部１１ｂへ通知する。ステップＳ２０において、リソース制御部１１ｂは、ＶＭ／コンテナＶ１〜Ｖ４のリソースであるＶＭ／コンテナ数を、スケールアウト／インによるオートスケール実行によって、リソース割当量の「２，４，２，４」とする制御を行う。この制御によって、システム１０における通信サービス性能が最適に保証される。
【００９９】
＜実施形態の効果＞
本実施形態に係るネットワーク性能保証システム１０の効果について説明する。このシステム１０は、ネットワーク接続されたサーバに生成されるＶＭ及びコンテナの何れか一方又は双方であるＶＭ／コンテナＶ１〜Ｖ４の数及び、当該ＶＭ／コンテナＶ１〜Ｖ４のＣＰＵ及びメモリに代表されるリソースを、リソース割当量に応じて増減するオートスケールを行う。このシステム１０の特徴構成を説明する。
【０１００】
（１）システム１０は、コンピュート１１に、複数種類のＶＭ／コンテナＶ１〜Ｖ４と、データ収集部１１ａと、リソース制御部１１ｂとを備え、コントローラ１２に、学習部１２ｂと、推定最適算出部１２ｃとを備える構成とした。
【０１０１】
データ収集部１１ａは、ＶＭ／コンテナＶ１〜Ｖ４のリソース割当量に応じたリソースの動作を測定して得られるリソース利用量及び、ＶＭ／コンテナＶ１〜Ｖ４に係る通信サービスの性能値を含む測定データを収集する。リソース制御部１１ｂは、ＶＭ／コンテナＶ１〜Ｖ４のリソースをリソース割当量に応じて増減するオートスケールを行う。
【０１０２】
学習部１２ｂは、データ収集部１１ａで収集された測定データの内の性能値から、リソース割当量に相関が高い性能値をモデル性能値として求める。推定最適算出部１２ｃは、モデル性能値と、モデル性能値に対応するリソースの動作に係る性能値との回帰分析により、リソース割当量の変更に応じた性能の推定値を求め、この推定値が、性能値の目標値を満たし且つリソース割当量が最小となる場合の、リソース割当量を算出する。更に、リソース制御部１１ｂは、上記算出されたリソース割当量に応じたオートスケールの実行によってＶＭ／コンテナＶ１〜Ｖ４のリソースを増減する。
【０１０３】
この構成によれば、少ないリソース割当量でのオートスケールの実行により、ＶＭ／コンテナＶ１〜Ｖ４において無駄なリソースが少なくなるようにリソース割当を行うことができる。このため、オートスケールによってＶＭ／コンテナＶ１〜Ｖ４数等のリソース割当量を適正に制御できる。
【０１０４】
（２）学習部１２ｂは、データ収集部１１ａで収集された測定データの中から、測定データとＶＭ／コンテナＶ１〜Ｖ４のリソース割当量との相関が予め定められた第１閾値よりも高い測定データを排除する構成とした。
【０１０５】
この構成によれば、次のような作用効果が得られる。ＶＭ／コンテナＶ１〜Ｖ４のリソースをリソース割当量で変更する際に、この変更に釣られて変わってしまう測定データ（リソース利用量が該当）は、モデル性能値を求める場合に不適正となる。この不適正な測定データは、リソース割当量に依存するリソースの測定データとの相関が高い場合に、多くなる特性がある。このため、本発明のように、不適正な測定データを事前に排除すれば、モデル性能値を推定できる精度を高めることができる。
【０１０６】
（３）学習部１２ｂは、排除の後に残った測定データの内、ＶＭ／コンテナＶ１〜Ｖ４に係る通信サービスの性能値との相関が予め定められた第２閾値よりも高い測定データを、モデル性能値を求めるために用いる構成とした。
【０１０７】
この構成によれば、実際に、ＶＭ／コンテナＶ１〜Ｖ４に係る通信サービスの性能値を計算する場合、測定データとの依存関係を反映するパラメータを使用しなければ、正しい性能値を得ることができない。このため、性能値を推定するために使用可能なパラメータとして、前述の排除後に残った測定データから、性能値との相関が第２閾値よりも高い測定データのみを用いるようにした。
【０１０８】
（４）推定最適算出部１２ｃは、ＶＭ／コンテナＶ１〜Ｖ４のリソースの数量を予め定められた最小数から最大数の間で可変し、この可変に応じた総当りの数量の組合せ候補を生成し、この生成された組合せ候補毎の数量を合計した総量が小又は大の順番となり、この順番の総量に推定値を対応付けた組合せ候補の中から、推定値が性能値の目標値を満たし且つ総量が最小値となる条件を検索し、総量の最小値が検索された以降、検索を総量が最小値以外の値となった際に終了する第１処理を行う構成とした。
【０１０９】
この構成によれば、推定値が性能値の目標値を満たし且つ総量が最小値となる条件を全て検索した以降に、総量が最小値以外の値となった際に検索を終了するようにした。このため、総当りの数量の組合せ候補を全て検索する処理に比べ、大幅に検索処理を削減できる。
【０１１０】
（５）推定最適算出部１２ｃは、ＶＭ／コンテナＶ１〜Ｖ４の稼働中リソースのリソース割当量と、推定値が性能値を満たし且つ終了時に検索された組合せ候補において総量が最小であるリソース割当量と、の差分の絶対値が最小である組合せ候補を選択し、この選択された組合せ候補のリソース割当量をリソース制御部１１ｂへ通知する第２処理を行う構成とした。
【０１１１】
この構成によれば、次の作用効果が得られる。ＶＭ／コンテナＶ１〜Ｖ４のリソースに対してリソース割当量を変更すると悪影響が出るので、通信サービスとして途中でリソース割当量を頻繁に変えると、通信サービスの性能値が低下する。しかし、本発明では、ＶＭ／コンテナＶ１〜Ｖ４のリソースにおける総当り数量の組合せ候補の中から、現在、稼働中リソースのリソース割当量に最も近いリソース割当量を選択するようにした。このため、途中でリソース割当量を変えても、性能値の低下を防止又は抑制できる。
【０１１２】
この他、推定最適算出部１２ｃは、上述した第１処理と第２処理を、性能値が予め定められた所定値よりも大きくなった場合、又は、一定時間間隔で行うようにしてもよい。
【０１１３】
この構成によれば、突然ユーザ数が増加して通信サービスの性能値（遅延やスループット等）が大きくなった場合に、第１処理と第２処理を行うことで対応できる。
【０１１４】
その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【０１１５】
１０  ネットワーク性能保証システム
１１  コンピュート（第１サーバ）
１１ａ  データ収集部
１１ｂ  リソース制御部
１２  コントローラ（第２サーバ）
１２ａ  データ収集部
１２ｂ  学習部
１２ｃ  推定最適算出部
１３  ＤＢ
Ｖ１〜Ｖ４  ＶＭ／コンテナ
【図１】
2020123848.tif 000003
【図２】
2020123848.tif 000004
【図３】
2020123848.tif 000005
【図４】
2020123848.tif 000006
【図５】
2020123848.tif 000007
【図６】
2020123848.tif 000008
【図７】
2020123848.tif 000009
【図８】
2020123848.tif 000010
【図９】
2020123848.tif 000011
【図１０】
2020123848.tif 000012