JP7081513B2 - ネットワーク性能保証システム及びネットワーク性能保証方法 - Google Patents

ネットワーク性能保証システム及びネットワーク性能保証方法 Download PDF

Info

Publication number
JP7081513B2
JP7081513B2 JP2019014760A JP2019014760A JP7081513B2 JP 7081513 B2 JP7081513 B2 JP 7081513B2 JP 2019014760 A JP2019014760 A JP 2019014760A JP 2019014760 A JP2019014760 A JP 2019014760A JP 7081513 B2 JP7081513 B2 JP 7081513B2
Authority
JP
Japan
Prior art keywords
value
resource allocation
performance
allocation amount
container
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019014760A
Other languages
English (en)
Other versions
JP2020123848A (ja
Inventor
義人 伊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2019014760A priority Critical patent/JP7081513B2/ja
Priority to US17/424,101 priority patent/US20220100548A1/en
Priority to PCT/JP2020/001414 priority patent/WO2020158436A1/ja
Publication of JP2020123848A publication Critical patent/JP2020123848A/ja
Application granted granted Critical
Publication of JP7081513B2 publication Critical patent/JP7081513B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H04L41/0897—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities by horizontal or vertical scaling of resources, or by migrating entities, e.g. virtual resources or entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/142—Network analysis or design using statistical or mathematical methods
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Environmental & Geological Engineering (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、ネットワーク接続されたサーバに生成されるＶＭ（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が「２，２，２，２」の場合の合計値は「８」なので、総量が「８」となる。この総量が少ない程に、リソースであるＶＭ／コンテナ数が少ないので、無駄なリソースが少なくなる。
次に、推定最適算出部１２ｃは、サービス性能推定値がＳＬＯ（性能目標値）以下で（言い換えれば性能目標値を満たしており）、且つ、総量が最小のＶＭ／コンテナ数（リソース割当量）となる組合せ候補を検索する。この検索された組合せ候補が、最適なリソース割当量となる。
例えば、図５の表２６に示すように、ＳＬＯが５０ｍｓであるとする。この場合、性能推定値である遅延が５０ｍｓ以下で、且つ総量が最小となる組合せ候補を検索する。総量は、表２６の上から小さい順に配列してある。なお、この逆に大きい順に配列してもよい。
推定最適算出部１２ｃは、表２６に示す性能推定値（遅延）が５０ｍｓ以下の遅延を検索する。この例の場合、ＶＭ／コンテナ数が矢印Ｙ１で指示する「２，４，２，４」の場合に遅延５０ｍｓのものが初めて検索される。この時点で、初検索された遅延５０ｍｓの場合の総量「１２」が最小であるため、遅延５０ｍｓ以下且つ最小の総量「１２」となる組合せ候補が確定する。この確定した組合せ候補のＳＬＯ比較の欄に○を付す。
更に、上記確定後、最小の総量「１２」を検索しながら、確定した遅延５０ｍｓ以下且つ最小の総量「１２」となる組合せ候補が順次検索される都度、ＳＬＯ比較の欄に順次○を付す。この検索中に、表２６の例では、矢印Ｙ２で指示する総量が「１２」の次の「１４」となった時点、つまり、最小値を超えた時点で検索動作が終了する。この検索では、遅延５０ｍｓ以下且つ最小の総量「１２」となるＶＭ／コンテナ数（リソース割当量）の組合せ候補が、○を付した通り４つあったとする。
ここで、Ｖ１～Ｖ４のＶＭ／コンテナ数は、出来るだけ変更が少ない方がリソースの揺動が少なくなり性能目標値に影響が少ないので、極力、ＶＭ／コンテナ数の変更を回避したい。Ｖ１～Ｖ４のＶＭ／コンテナ数が、例えば図６の表２７に示す「２，２，２，４」で運用されている場合に、例えばＶ４の「４」を減少、Ｖ１の「２」を増加する等の変更を回避する必要がある。そこで、ＶＭ／コンテナ数の変更が出来るだけ少ない組合せ候補を検索する必要がある。この検索を次のようにユークリッド距離を用いて行うようにした。
推定最適算出部１２ｃは、現在のＶＭ／コンテナＶ１～Ｖ４のリソース割当量（ＶＭ／コンテナ数）と、上記で求めた性能推定値がＳＬＯ以下で、且つ、総量が最小のリソース割当量（ＶＭ／コンテナ数）と、のユークリッド距離が最小となる組合せ候補を算出する。
ここで、現在のＶＭ／コンテナＶ１，…，Ｖｎ）のリソース割当量（ｒＶ１，ｒＶ２，…，ｒＶｎ）と、組合せ候補（ｒ′Ｖ１，ｒ′Ｖ２，…，ｒ′Ｖｎ）とのユークリッド距離ｄが最小となる組合せ候補は、次式（４）でユークリッド距離ｄを求めて得られる。
ｄ＝√｛（ｒＶ１－ｒ′Ｖ１）２＋（ｒＶ２－ｒ′Ｖ２）２＋…＋（ｒＶｎ－ｒ′Ｖｎ）２｝ …（４）
この式（４）を用いてユークリッド距離ｄを次のように求める。即ち、図６の表２７に示す現在のＶ１～Ｖ４の組合せ「２，２，２，４」と、図７の表２８の１行目に示す組合せ候補「２，４，２，４」とのユークリッド距離ｄは、（２－２）２＋（２－４）２＋（２－２）２＋（４－４）２の計算結果である平方根を計算した結果の「４」となる。この「４」を距離ｄの欄に記載する。以降同様に、２行目～４行目を計算すると、各々が「１２」となる。
この結果、推定最適算出部１２ｃは、表２８に示すユークリッド距離ｄが最小となる１行目の組合せ候補のＶＭ／コンテナ数「２，４，２，４」を、ＶＭ／コンテナＶ１～Ｖ４のリソース割当量として採用する。
この採用されたＶ１～Ｖ４のリソース割当量（ＶＭ／コンテナ数）「２，４，２，４」は、コンピュート１１のリソース制御部１１ｂへ通知される。リソース制御部１１ｂは、ＶＭ／コンテナＶ１～Ｖ４のリソースであるＶＭ／コンテナ数を、リソース割当量の「２，４，２，４」とする制御を行う。この制御によって、システム１０における通信サービス性能の最適な保証が可能となる。
＜実施形態の動作＞
次に、本実施形態に係るネットワーク性能保証システムの動作を、図８のシーケンス図を参照して説明する。
ステップＳ１において、コントローラ１２のデータ収集部１２ａに、コンピュート１１から各ＶＭ／コンテナＶ１～Ｖ４（図１）が生成されたことが通知されたとする。この通知を受けたデータ収集部１２ａは、ステップＳ２において、コンピュート１１にデータ収集開始指示を行う。
この指示を受けたコンピュート１１のデータ収集部１１ａは、ステップＳ３において、上記生成された各ＶＭ／コンテナＶ１～Ｖ４の数や、遅延やスループット等のリソースの性能値のデータ収集を開始する。
このデータ収集部１１ａは、ステップＳ４において、各ＶＭ／コンテナＶ１～Ｖ４のリソースを追加又は削除して増減する指示（リソース割当指示）を、リソース制御部１１ｂに行う。ステップＳ５において、リソース制御部１１ｂは、その指示に応じてＶ１～Ｖ４のリソースを増減するリソース割当の制御を行う。この制御では、リソースとしてのＶ１～Ｖ４のＶＭ／コンテナ数が定められ、この際のサービス性能値である遅延の測定データも求められるとする。例えば、図２の表２１に示した測定データａ～ｅが求められる。この他に、物理サーバ全体のＣＰＵ使用量、ＶＭ／コンテナ個別のＣＰＵ使用量やリソース割当量等のリソースの測定データも得られる。
図８のステップＳ６において、リソース制御部１１ｂは、上記リソース割当により定まったＶＭ／コンテナ数とサービス性能値の測定データをデータ収集部１１ａに通知する。
データ収集部１１ａは、ステップＳ７において、その通知された測定データを収集し、この収集データを、ステップＳ８において、コントローラ１２のデータ収集部１２ａへ転送する。この転送された収集データは、ＤＢ１３（図１）に記憶される。
上記ステップＳ４～Ｓ８の処理は、次のように繰り返される。例えば、図３の表２３に示すＶ１～Ｖ４のリソース割当量としてのＶＭ／コンテナ数を、最小「２」、最大「４」とし、これをステップ数「２」ずつ順次変えながら、ＶＭ／コンテナ数の総当りの組合せ候補（「２，２，２，２」～「４，４，４，４」）を生成する。この繰り返し生成において、リソースの測定データが収集されてデータ収集部１２ａに通知され、ＤＢ１３に記憶される。
上記ステップＳ４～Ｓ８の処理の繰り返しにより、様々なパターンのデータが所定数収集されると、コンピュート１１のデータ収集部１１ａからコントローラ１２のデータ収集部１２ａへデータ収集完了が通知される（ステップＳ９）。この通知をデータ収集部１２ａが受けた時にデータ収集フェーズが終了する。
上記データ収集完了を受信したデータ収集部１２ａは、ステップＳ１０において、学習部１２ｂに学習フェーズでの計算を依頼する。
依頼を受けた学習部１２ｂは、ステップＳ１１において、ＤＢ１３に記憶された収集データを基に、次のように回帰分析を行う。
即ち、学習部１２ｂは、まず、ＤＢ１３に記憶された図２の表２１に示す測定データａ～ｅと、上記ステップＳ５のリソース割当で用いられたリソース割当量との相関係数ｒを求める。次に、第１閾値「０．２」を超える相関係数ｒの測定データａ，ｅを排除する。この排除後に残った図２の表２２に示す測定データｂ，ｃ，ｄと、上記データ収集フェーズでＤＢ１３に記憶されたサービス性能値との相関係数ｒ１を求める。この相関係数ｒ１が第２閾値「０．４」を超えた測定データｂ，ｃを用いて回帰分析を行う。この回帰分析により、学習結果としてのモデルサービス性能値が得られる。
次に、学習部１２ｂは、図８に示すステップＳ１２において、上記回帰分析で得られた学習結果としてのモデルサービス性能値を推定最適算出部１２ｃに通知する。推定最適算出部１２ｃは、ステップＳ１３において、その学習結果のモデルサービス性能値をＤＢ１３に保存する。この保存により学習フェーズが終了する。
上記モデルサービス性能値の保存後、推定最適算出部１２ｃは、ステップＳ１４において、運用開始指示をコンピュート１１へ通知する。この通知を受けたコンピュート１１のデータ収集部１１ａは、ステップＳ１５において、ＶＭ／コンテナＶ１～Ｖ４からリソース運用時の測定データを収集し、この収集データを、ステップＳ１６において、コントローラ１２のデータ収集部１２ａへ転送する。この転送された収集データは、ステップＳ１７において、データ収集部１２ａから推定最適算出部１２ｃへ通知される。
ステップＳ１８において、推定最適算出部１２ｃは、推定最適検索処理を次のように行う。但し、運用フェーズにおいて、スケールアウト／インでリソース割当が実行されるとする。まず、推定最適算出部１２ｃは、図３の表２３に示すＶ１～Ｖ４のリソース割当量としてのＶＭ／コンテナ数の総当りの組合せ候補（「２，２，２，２」～「４，４，４，４」）を生成する。
次に、推定最適算出部１２ｃは、上記組合せ候補毎に、ＤＢ１３内の入力測定データｂ，ｃに応じたリソースのリアルタイムのサービス性能値であるＲＴサービス性能値と、上記ステップＳ１３でＤＢ１３に記憶された学習結果としてのモデルサービス性能値との関係から回帰分析を行う。この回帰分析により、図３の表２４に示す組合せ候補毎にサービス性能推定値（遅延）が求められる。
次に、推定最適算出部１２ｃは、図４の表２５に示す組合せ候補毎の合計値を総量として求める。総量が少ない程に無駄なリソースが少なくなる。次に、推定最適算出部１２ｃは、図５の表２６に示す性能推定値がＳＬＯ（５０ｍｓ）以下で、且つ、総量が最小のＶＭ／コンテナ数となる組合せ候補を検索する。この検索によりＳＬＯ比較の欄に○を付したように組合せ候補が４つあったとする。
ここで、Ｖ１～Ｖ４のＶＭ／コンテナ数が、図６の表２７に示す組合せ「２，２，２，４」で運用されている場合に、この組合せ「２，２，２，４」と、図７の表２７の各行の組合せ候補「２，４，２，４」とのユークリッド距離ｄを算出する。このユークリッド距離ｄが最小「４」となる１行目の組合せ候補「２，４，２，４」を、ＶＭ／コンテナＶ１～Ｖ４のリソース割当量であるＶＭ／コンテナ数として採用する。
推定最適算出部１２ｃは、ステップＳ１９において、その採用されたＶ１～Ｖ４のリソース割当量（ＶＭ／コンテナ数）の「２，４，２，４」を、コンピュート１１のリソース制御部１１ｂへ通知する。ステップＳ２０において、リソース制御部１１ｂは、ＶＭ／コンテナＶ１～Ｖ４のリソースであるＶＭ／コンテナ数を、スケールアウト／インによるオートスケール実行によって、リソース割当量の「２，４，２，４」とする制御を行う。この制御によって、システム１０における通信サービス性能が最適に保証される。
＜実施形態の効果＞
本実施形態に係るネットワーク性能保証システム１０の効果について説明する。このシステム１０は、ネットワーク接続されたサーバに生成されるＶＭ及びコンテナの何れか一方又は双方であるＶＭ／コンテナＶ１～Ｖ４の数及び、当該ＶＭ／コンテナＶ１～Ｖ４のＣＰＵ及びメモリに代表されるリソースを、リソース割当量に応じて増減するオートスケールを行う。このシステム１０の特徴構成を説明する。
（１）システム１０は、コンピュート１１に、複数種類のＶＭ／コンテナＶ１～Ｖ４と、データ収集部１１ａと、リソース制御部１１ｂとを備え、コントローラ１２に、学習部１２ｂと、推定最適算出部１２ｃとを備える構成とした。
データ収集部１１ａは、ＶＭ／コンテナＶ１～Ｖ４のリソース割当量に応じたリソースの動作を測定して得られるリソース利用量及び、ＶＭ／コンテナＶ１～Ｖ４に係る通信サービスの性能値を含む測定データを収集する。リソース制御部１１ｂは、ＶＭ／コンテナＶ１～Ｖ４のリソースをリソース割当量に応じて増減するオートスケールを行う。
学習部１２ｂは、データ収集部１１ａで収集された測定データの内の性能値から、リソース割当量に相関が高い性能値をモデル性能値として求める。推定最適算出部１２ｃは、モデル性能値と、モデル性能値に対応するリソースの動作に係る性能値との回帰分析により、リソース割当量の変更に応じた性能の推定値を求め、この推定値が、性能値の目標値を満たし且つリソース割当量が最小となる場合の、リソース割当量を算出する。更に、リソース制御部１１ｂは、上記算出されたリソース割当量に応じたオートスケールの実行によってＶＭ／コンテナＶ１～Ｖ４のリソースを増減する。
この構成によれば、少ないリソース割当量でのオートスケールの実行により、ＶＭ／コンテナＶ１～Ｖ４において無駄なリソースが少なくなるようにリソース割当を行うことができる。このため、オートスケールによってＶＭ／コンテナＶ１～Ｖ４数等のリソース割当量を適正に制御できる。
（２）学習部１２ｂは、データ収集部１１ａで収集された測定データの中から、測定データとＶＭ／コンテナＶ１～Ｖ４のリソース割当量との相関が予め定められた第１閾値よりも高い測定データを排除する構成とした。
この構成によれば、次のような作用効果が得られる。ＶＭ／コンテナＶ１～Ｖ４のリソースをリソース割当量で変更する際に、この変更に釣られて変わってしまう測定データ（リソース利用量が該当）は、モデル性能値を求める場合に不適正となる。この不適正な測定データは、リソース割当量に依存するリソースの測定データとの相関が高い場合に、多くなる特性がある。このため、本発明のように、不適正な測定データを事前に排除すれば、モデル性能値を推定できる精度を高めることができる。
（３）学習部１２ｂは、排除の後に残った測定データの内、ＶＭ／コンテナＶ１～Ｖ４に係る通信サービスの性能値との相関が予め定められた第２閾値よりも高い測定データを、モデル性能値を求めるために用いる構成とした。
この構成によれば、実際に、ＶＭ／コンテナＶ１～Ｖ４に係る通信サービスの性能値を計算する場合、測定データとの依存関係を反映するパラメータを使用しなければ、正しい性能値を得ることができない。このため、性能値を推定するために使用可能なパラメータとして、前述の排除後に残った測定データから、性能値との相関が第２閾値よりも高い測定データのみを用いるようにした。
（４）推定最適算出部１２ｃは、ＶＭ／コンテナＶ１～Ｖ４のリソースの数量を予め定められた最小数から最大数の間で可変し、この可変に応じた総当りの数量の組合せ候補を生成し、この生成された組合せ候補毎の数量を合計した総量が小又は大の順番となり、この順番の総量に推定値を対応付けた組合せ候補の中から、推定値が性能値の目標値を満たし且つ総量が最小値となる条件を検索し、総量の最小値が検索された以降、検索を総量が最小値以外の値となった際に終了する第１処理を行う構成とした。
この構成によれば、推定値が性能値の目標値を満たし且つ総量が最小値となる条件を全て検索した以降に、総量が最小値以外の値となった際に検索を終了するようにした。このため、総当りの数量の組合せ候補を全て検索する処理に比べ、大幅に検索処理を削減できる。
（５）推定最適算出部１２ｃは、ＶＭ／コンテナＶ１～Ｖ４の稼働中リソースのリソース割当量と、推定値が性能値を満たし且つ終了時に検索された組合せ候補において総量が最小であるリソース割当量と、の差分の絶対値が最小である組合せ候補を選択し、この選択された組合せ候補のリソース割当量をリソース制御部１１ｂへ通知する第２処理を行う構成とした。
この構成によれば、次の作用効果が得られる。ＶＭ／コンテナＶ１～Ｖ４のリソースに対してリソース割当量を変更すると悪影響が出るので、通信サービスとして途中でリソース割当量を頻繁に変えると、通信サービスの性能値が低下する。しかし、本発明では、ＶＭ／コンテナＶ１～Ｖ４のリソースにおける総当り数量の組合せ候補の中から、現在、稼働中リソースのリソース割当量に最も近いリソース割当量を選択するようにした。このため、途中でリソース割当量を変えても、性能値の低下を防止又は抑制できる。
この他、推定最適算出部１２ｃは、上述した第１処理と第２処理を、性能値が予め定められた所定値よりも大きくなった場合、又は、一定時間間隔で行うようにしてもよい。
この構成によれば、突然ユーザ数が増加して通信サービスの性能値（遅延やスループット等）が大きくなった場合に、第１処理と第２処理を行うことで対応できる。
その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
１０ ネットワーク性能保証システム
１１ コンピュート（第１サーバ）
１１ａ データ収集部
１１ｂ リソース制御部
１２ コントローラ（第２サーバ）
１２ａ データ収集部
１２ｂ 学習部
１２ｃ 推定最適算出部
１３ ＤＢ
Ｖ１～Ｖ４ ＶＭ／コンテナ

Claims (7)

  1. ネットワーク接続されたサーバに生成されるＶＭ（Virtual Machine）及びコンテナの何れか一方又は双方であるＶＭ／コンテナの数及び、当該ＶＭ／コンテナのＣＰＵ（Central Processing Unit）及びメモリに代表されるリソースを、リソース割当量に応じて増減するオートスケールを行うネットワーク性能保証システムであって、
    複数種類の前記ＶＭ／コンテナと、
    前記ＶＭ／コンテナのリソース割当量に応じたリソースの動作を測定して得られるリソース利用量及び、当該ＶＭ／コンテナに係る通信サービスの性能値を含む測定データを収集する収集部と、
    前記ＶＭ／コンテナのリソースを前記リソース割当量に応じて増減するオートスケールを行う制御部と
    を有する第１サーバを備えると共に、
    前記収集部で収集された測定データの内の前記性能値から、前記リソース割当量に相関が高い性能値をモデル性能値として求める学習部と、
    前記モデル性能値と、当該モデル性能値に対応する前記リソースの動作に係る性能値との回帰分析により、前記リソース割当量の変更に応じた性能の推定値を求め、この推定値が、前記性能値の目標値を満たし且つ前記リソース割当量が最小となる場合の、リソース割当量を算出する算出部と
    を有する第２サーバを備え、
    前記制御部は、前記算出されたリソース割当量に応じたオートスケールの実行によって該当ＶＭ／コンテナのリソースを増減する
    ことを特徴とするネットワーク性能保証システム。
  2. 前記学習部は、
    前記収集部で収集された測定データの中から、当該測定データと前記ＶＭ／コンテナのリソース割当量との相関が予め定められた第１閾値よりも高い測定データを排除する
    ことを特徴とする請求項１に記載のネットワーク性能保証システム。
  3. 前記学習部は、
    前記排除の後に残った測定データの内、前記ＶＭ／コンテナに係る通信サービスの性能値との相関が予め定められた第２閾値よりも高い測定データを、前記モデル性能値を求めるために用いる
    ことを特徴とする請求項２に記載のネットワーク性能保証システム。
  4. 前記算出部は、
    前記ＶＭ／コンテナのリソースの数量を予め定められた最小数から最大数の間で可変し、この可変に応じた総当りの数量の組合せ候補を生成し、この生成された組合せ候補毎の数量を合計した総量が小又は大の順番となり、この順番の総量に前記推定値を対応付けた組合せ候補の中から、当該推定値が前記性能値の目標値を満たし且つ当該総量が最小値となる条件を検索し、当該総量の最小値が検索された以降、当該検索を総量が最小値以外の値となった際に終了する第１処理を行う
    ことを特徴とする請求項３に記載のネットワーク性能保証システム。
  5. 前記算出部は、
    前記ＶＭ／コンテナの稼働中リソースのリソース割当量と、前記推定値が前記性能値を満たし且つ前記終了時に検索された組合せ候補において前記総量が最小であるリソース割当量と、の差分の絶対値が最小である組合せ候補を選択し、この選択された組合せ候補のリソース割当量を前記制御部へ通知する第２処理を行う
    ことを特徴とする請求項４に記載のネットワーク性能保証システム。
  6. 前記算出部は、
    前記第１処理と前記第２処理を、前記性能値が予め定められた所定値よりも大きくなった場合、又は、一定時間間隔で行う
    ことを特徴とする請求項５に記載のネットワーク性能保証システム。
  7. ネットワーク接続されたサーバに生成されるＶＭ及びコンテナの何れか一方又は双方であるＶＭ／コンテナの数及び、当該ＶＭ／コンテナのＣＰＵ及びメモリに代表されるリソースを、リソース割当量に応じて増減するオートスケールを行うシステムのオートスケール型性能保証方法であって、
    前記システムは、複数種類の前記ＶＭ／コンテナが生成された第１サーバと、当該第１サーバに接続された第２サーバとを備え、
    前記第１サーバは、
    前記ＶＭ／コンテナのリソース割当量に応じたリソースの動作を測定して得られるリソース利用量及び、当該ＶＭ／コンテナに係る通信サービスの性能値を含む測定データを収集するステップと、
    前記ＶＭ／コンテナのリソースを前記リソース割当量に応じて増減するオートスケールを行うステップとを実行し、
    前記第２サーバは、
    前記収集された測定データの内の前記性能値から、前記リソース割当量に相関が高い性能値をモデル性能値として求めるステップと、
    前記モデル性能値と、当該モデル性能値に対応する前記リソースの動作に係る性能値との回帰分析により、前記リソース割当量の変更に応じた性能の推定値を求め、この推定値が、前記性能値の目標値を満たし且つ前記リソース割当量が最小となる場合の、リソース割当量を算出するステップとを実行し、
    前記第１サーバは、
    前記算出されたリソース割当量に応じたオートスケールの実行によって該当ＶＭ／コンテナのリソースを増減するステップを実行する
    ことを特徴とするネットワーク性能保証方法。
JP2019014760A 2019-01-30 2019-01-30 ネットワーク性能保証システム及びネットワーク性能保証方法 Active JP7081513B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2019014760A JP7081513B2 (ja) 2019-01-30 2019-01-30 ネットワーク性能保証システム及びネットワーク性能保証方法
US17/424,101 US20220100548A1 (en) 2019-01-30 2020-01-17 Network performance assurance system and network performance assurance method
PCT/JP2020/001414 WO2020158436A1 (ja) 2019-01-30 2020-01-17 ネットワーク性能保証システム及びネットワーク性能保証方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019014760A JP7081513B2 (ja) 2019-01-30 2019-01-30 ネットワーク性能保証システム及びネットワーク性能保証方法

Publications (2)

Publication Number Publication Date
JP2020123848A JP2020123848A (ja) 2020-08-13
JP7081513B2 true JP7081513B2 (ja) 2022-06-07

Family

ID=71842066

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019014760A Active JP7081513B2 (ja) 2019-01-30 2019-01-30 ネットワーク性能保証システム及びネットワーク性能保証方法

Country Status (3)

Country Link
US (1) US20220100548A1 (ja)
JP (1) JP7081513B2 (ja)
WO (1) WO2020158436A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021149808A (ja) * 2020-03-23 2021-09-27 富士通株式会社 Ｃｐｕ状態表示方法及びｃｐｕ状態表示プログラム
JP7191906B2 (ja) * 2020-09-09 2022-12-19 株式会社日立製作所 リソース割当制御装置、計算機システム、及びリソース割当制御方法
KR102563329B1 (ko) * 2021-09-01 2023-08-03 고려대학교 산학협력단 컨테이너에 대한 리소스 간 의존성 스케줄링 방법 및 이를 수행하는 네트워크 시스템
JP2023102641A (ja) * 2022-01-12 2023-07-25 株式会社日立製作所 計算機システム及びスケールアップ管理方法
WO2023157199A1 (ja) * 2022-02-17 2023-08-24 楽天モバイル株式会社 妥当性検証システム及び妥当性検証方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3035619A1 (en) 2014-12-15 2016-06-22 Alcatel Lucent A method and system for scaling and a telecommunications network
US20170126792A1 (en) 2015-11-02 2017-05-04 Telefonaktiebolaget L M Ericsson (Publ) System and methods for intelligent service function placement and autoscale based on machine learning

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3035619A1 (en) 2014-12-15 2016-06-22 Alcatel Lucent A method and system for scaling and a telecommunications network
US20170126792A1 (en) 2015-11-02 2017-05-04 Telefonaktiebolaget L M Ericsson (Publ) System and methods for intelligent service function placement and autoscale based on machine learning

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
伊藤 義人 Yoshito Ito，ＶＮＦのサービス要件保証に向けた性能予測の検討，電子情報通信学会２０１７年通信ソサイエティ大会講演論文集２ PROCEEDINGS OF THE 2017 IEICE COMMUNICAT，2017年08月29日，P.S-14,BS-4-4
平島 陽子 Yoko Hirashima，応答性能保証率向上のためのハイブリッドオートスケール方式 Hybrid Auto-Scaling Mechanism for Dynamic，電気学会論文誌Ｃ Ｖｏｌ．１３７ Ｎｏ．３ IEEJ，日本，一般社団法人電気学会 The Institute of Electrical，2017年03月01日，P.521-531
水野 潤 Jun MIZUNO，クラウド向けサービス性能劣化の原因特定方式の検討 Study of Baseline Analysis Method of Service Perfo，電子情報通信学会技術研究報告 Ｖｏｌ．１１６ Ｎｏ．５０７ IEICE Technical Report，日本，一般社団法人電子情報通信学会 The Institute of Ele，2017年03月02日，P.37-42

Also Published As

Publication number Publication date
US20220100548A1 (en) 2022-03-31
WO2020158436A1 (ja) 2020-08-06
JP2020123848A (ja) 2020-08-13

Similar Documents

Publication Publication Date Title
JP7081513B2 (ja) ネットワーク性能保証システム及びネットワーク性能保証方法
US20200236012A1 (en) System and method for applying machine learning algorithms to compute health scores for workload scheduling
US9921809B2 (en) Scaling a cloud infrastructure
Ghorbannia Delavar et al. HSGA: a hybrid heuristic algorithm for workflow scheduling in cloud systems
US8566835B2 (en) Dynamically resizing a virtual machine container
Han et al. Lightweight resource scaling for cloud applications
US9940162B2 (en) Realtime optimization of compute infrastructure in a virtualized environment
US9201690B2 (en) Resource aware scheduling in a distributed computing environment
JP7081514B2 (ja) オートスケール型性能保証システム及びオートスケール型性能保証方法
US9645909B2 (en) Operation management apparatus and operation management method
JP5954430B2 (ja) 運用管理装置、及び、運用管理方法
EP2977898B1 (en) Task allocation in a computing environment
US9378058B2 (en) Method and system for dynamic control of a multi-tier processing system
US20170264500A1 (en) Number-of-scales estimation apparatus, number-of-scales management system, number-of-scales estimation method, number-of-scales management method, and storage medium
JP5445739B2 (ja) リソース割当装置、リソース割当方法、及びプログラム
Li et al. KneeScale: Efficient resource scaling for serverless computing at the edge
CN112000460A (zh) 一种基于改进贝叶斯算法的服务扩缩容的方法及相关设备
JP2005148911A (ja) 負荷分散方法及び装置とシステム並びにプログラム
Nehra et al. Efficient resource allocation and management by using load balanced multi-dimensional bin packing heuristic in cloud data centers
CN111538567A (zh) 一种边缘设备上虚拟网络功能链的部署方法和设备
Gąsior et al. A Sandpile cellular automata-based scheduler and load balancer
Jena et al. Performance evaluation of load balancing algorithms on cloud data centers
JP6806065B2 (ja) 仮想計算機システムの性能予測装置、性能予測方法およびコンピュータプログラム
CN112948114B (zh) 边缘计算方法和边缘计算平台
Prasad et al. RConf (PD): Automated resource configuration of complex services in the cloud

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210510

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220426

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220509

R150 Certificate of patent or registration of utility model

Ref document number: 7081513

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150