JP7081514B2 - オートスケール型性能保証システム及びオートスケール型性能保証方法 - Google Patents
オートスケール型性能保証システム及びオートスケール型性能保証方法 Download PDFInfo
- Publication number
- JP7081514B2 JP7081514B2 JP2019014761A JP2019014761A JP7081514B2 JP 7081514 B2 JP7081514 B2 JP 7081514B2 JP 2019014761 A JP2019014761 A JP 2019014761A JP 2019014761 A JP2019014761 A JP 2019014761A JP 7081514 B2 JP7081514 B2 JP 7081514B2
- Authority
- JP
- Japan
- Prior art keywords
- container
- autoscale
- resource
- containers
- dependency
- 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
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/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
-
- 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/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5019—Ensuring fulfilment of SLA
-
- 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/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
- H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
本発明は、ネットワーク接続されたサーバに生成されるVM(Virtual Machine:仮想マシン)及びコンテナの数や、CPU(Central Processing Unit)及びメモリ等のリソースのオートスケールを行うオートスケール型性能保証システム及びオートスケール型性能保証方法に関する。
オートスケール型性能保証システム(システムともいう)は、ネットワークで接続される物理的なサーバに、1又は複数のVM及びコンテナの何れか一方又は双方を用いた構成となっている。このVM及びコンテナの何れか一方又は双方を、VM/コンテナと表現する。このVM/コンテナによりVNF(Network Functions Virtualization:VNFネットワーク機能仮想化)の構成が成されている。
また、複数のVM/コンテナを用いたネットワークにおける遅延やスループット等の通信サービスの品質を「性能」又は「性能値」という。つまり、性能が良いとは通信サービス品質が良いことを表わし、性能が悪いとは通信サービス品質が悪いことを表わす。
オートスケールとは、サーバ負荷に応じて、自動的にVM/コンテナの数を増減させる機能である。このオートスケールによって、システムのサーバにアクセスが集中したときはVM/コンテナ数を自動で増やし、アクセスが少ないときはVM/コンテナ数を減らすことで、極力最適なVM/コンテナ数でシステムを稼働するようになっている。
オートスケールには、VM/コンテナ数を増やしてサーバ性能を高めるスケールアウトと、この逆に、VM/コンテナ数を減らしてサーバ性能を適正にするスケールインがある。更に、オートスケールには、VM/コンテナのCPUやメモリ等のリソースの追加を行ってサーバ性能を高めるスケールアップと、この逆に、VM/コンテナのリソースの削除を行ってサーバ性能を適正にするスケールダウンとがある。なお、スケールアウト又はスケールインをスケールアウト/インと表現し、スケールアップ又はスケールダウンをスケールアップ/ダウンと表現する。また、リソースの追加又は削除をリソース追加/削除と表現する。
上述したシステムのオートスケールの一例として非特許文献1,2の技術が有る。非特許文献1には、SLO(サービスレベル目標値又は性能目標値)を意識した性能制御のコンセプトが広く開示されている。一方、非特許文献2における仕様及び機能では、仮想化技術における性能制御手法の既存のオートスケールが、VM/コンテナ毎に予め規定したリソース利用率の閾値を用いてスケール契機を判断するようになっている。このオートスケールでは、スケールアップ/ダウン或いはスケールアウト/インによるCPUやメモリ等のリソース追加/削除によって、VM/コンテナへのリソース割当量の変更を実施している。
M.G. Jaatun,et al.,"SLA-Driven Adaptive Resource Management for Web Applications on a Heterogeneous Compute Cloud",[online],2009,[平成31年1月16日検索],インターネット〈URL: http://www.cs.ait.ac.th/~mdailey/papers/Iqbal-RTSLA.pdf〉
富士通クラウドテクノロジーズ,"ニフクラのオートスケール",[online],2017-2019,[平成31年1月16日検索],インターネット〈URL: https://cloud.nifty.com/service/autoscale.htm〉
しかし、特許文献2のオートスケール技術では、リソース利用率の閾値と、リソース制御対象のVM/コンテナの選定と、VM/コンテナの増減等の制御量とを、人が予め適正に規定することが必要となっている。この人による規定は容易に行えず手間暇が掛かり、規定後にオートスケール制御を行ってもVM/コンテナ数やリソース割当量を適正に制御できないという問題が生じる。
また、複数のVM/コンテナで構成されるVNFでは、遅延やスループット等の性能値と、各VM/コンテナのvCPU(仮想CPU)数、メモリ量やVM/コンテナ数等のリソース割当量とが複雑に依存し、ボトルネックとなるリソース部分が次のように存在している。
例えば、図13に示すように、VNFに複数のVM/コンテナV1,V2,…,Vk,…,Vnがあるとする。この際に、VNFの性能値pが、VM/コンテナV1,V2,…,Vk,…,Vnのリソース割当量rV1,rV2,…,rVk,…,rVnに依存しているとすれば、性能値pは次の関数式(1)で表わされる。
p=f(rV1,rV2,…,rVk,…,rVn)…(1)
このように性能値pが、VM/コンテナV1,V2,…,Vk,…,Vnのリソース割当量の関数の場合に、図14に示すように、ある1つのVM/コンテナVkのリソース割当量rVkだけを増加(例えば3つに増加)させても、VNF全体の性能値pを向上させることができない。この理由は次の通りである。
この例のように、1つのVM/コンテナVkのリソース割当量rVkだけを3つに増加させても、これ以外の他のVM/コンテナV1,V2,…,Vnは各々1つのみなので、これらのVM/コンテナV1,V2,…,Vnで性能値pが不足してボトルネックとなり、VNF全体として性能が向上しない。この場合、他のVM/コンテナV1,V2,…,Vnも増加させればよいが、人手によるため、幾つ増やせば良いかが簡単に判らず手間暇が掛かってしまう。
このように、あるVM/コンテナVkのリソース割当量rVkだけを増加させるオートスケールを行っても、VNFの性能値をSLO(性能目標値)とすることができない。言い換えれば、オートスケールを行っても、VM/コンテナ数等のリソース割当量を適正に制御できない。
本発明は、このような事情に鑑みてなされたものであり、オートスケールによってVM/コンテナ数等のリソース割当量を適正に制御できるオートスケール型性能保証システム及びオートスケール型性能保証方法を提供することを課題とする。
上記課題を解決するための手段として、請求項1に係る発明は、ネットワーク接続されたサーバに生成されるVM(Virtual Machine)及びコンテナの何れか一方又は双方であるVM/コンテナの数及び、当該VM/コンテナのCPU(Central Processing Unit)及びメモリに代表されるリソースを追加又は削除して増減するオートスケールを行うオートスケール型性能保証システムであって、複数種類の前記VM/コンテナと、前記VM/コンテナのリソースの割当量を収集する収集部と、前記VM/コンテナのリソースを増減するオートスケールを行う制御部とを有する第1サーバを備えると共に、前記収集された割当量を基に、前記VM/コンテナに係る通信サービス品質を提供するための性能に対して、前記リソースの割当量が依存する依存有りか否かを表わす依存度を算出する算出部と、前記算出された依存有りの依存度に係るリソースのみを増減させるためのリソース制御量を求める判断部とを有する第2サーバを備え、前記制御部は、前記判断部で求められるリソース制御量に応じたオートスケールの実行によって該当VM/コンテナのリソースを増減することを特徴とするオートスケール型性能保証システムである。
請求項8に係る発明は、ネットワーク接続されたサーバに生成されるVM及びコンテナの何れか一方又は双方であるVM/コンテナの数及び、当該VM/コンテナのCPU及びメモリに代表されるリソースを追加又は削除して増減するオートスケールを行うシステムのオートスケール型性能保証方法であって、前記システムは、複数種類の前記VM/コンテナが生成された第1サーバと、当該第1サーバに接続された第2サーバとを備え、前記第1サーバは、前記VM/コンテナのリソースの割当量を収集するステップを実行し、前記第2サーバは、前記収集された割当量を基に、前記VM/コンテナに係る通信サービス品質を提供するための性能に対して、前記リソースの割当量が依存する依存有りか否かを表わす依存度を算出するステップと、前記算出された依存有りの依存度に係るリソースのみを増減させるためのリソース制御量を求めるステップとを実行し、前記第1サーバは、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナのリソースを増減するステップを実行することを特徴とするオートスケール型性能保証方法である。
請求項1の構成及び請求項8の方法によれば、複数種類のVM/コンテナのリソースの割当量を基に、VM/コンテナに係る性能に対してリソースの割当量の依存度が有るか否かを求め、依存有りに該当する割当量のリソースのみをオートスケール実行により増減可能とした。このため、従来のように、人手によるリソースの増減設定が必要なため手間暇が掛かるといったことが無くなり、本発明では、オートスケールの実行(運用)によってVM/コンテナ数等のリソース割当量を適正に制御可能となる。
請求項2に係る発明は、前記算出部は、前記リソースの割当量としての前記VM/コンテナの数と前記性能との相関係数を求め、この求められた相関係数が予め定められた閾値を超える場合に前記依存度を依存有りとして算出し、前記判断部は、前記算出された依存有りの依存度に係る前記VM/コンテナの数のみを増減させるためのリソース制御量を求め、前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナの数を増減することを特徴とする請求項1に記載のオートスケール型性能保証システムである。
この構成によれば、次のような作用効果が得られる。通常、性能とVM/コンテナの数(VM/コンテナ数)との相関係数が大きければ、VM/コンテナ数を増やすと性能が向上する。このため、性能が向上する相関係数を判別するための閾値を予め定め、この閾値を相関係数が超えた際に、性能とVM/コンテナ数との依存有りを示す依存度に該当する割当量のVM/コンテナ数のみを増減させるようにした。これによって、例えば増加したVM/コンテナに係る性能を向上できる。
請求項3に係る発明は、前記算出部は、前記リソースの割当量としての前記VM/コンテナのリソース割当セット数と前記性能との相関係数を求め、この求められた相関係数が予め定められた閾値を超える場合に前記依存度を依存有りとして算出し、前記判断部は、前記算出された依存有りの依存度に係る前記VM/コンテナのリソース割当セット数のみを増減させるためのリソース制御量を求め、前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナのリソース割当セット数を増減することを特徴とする請求項1に記載のオートスケール型性能保証システムである。
この構成によれば、次のような作用効果が得られる。通常、性能とVM/コンテナのリソース割当セット数との相関係数が大きければ、VM/コンテナ数を増やすと性能が向上する。このため、性能が向上する相関係数を判別するための閾値を予め定め、この閾値を相関係数が超えた際に、性能とリソース割当セット数との依存有りを示す依存度に該当する割当量のVM/コンテナのリソース割当セット数のみを増減させるようにした。これによって、例えばリソース割当セット数が増加したVM/コンテナに係る性能を向上できる。
請求項4に係る発明は、前記算出部は、前記リソースの割当量としての前記VM/コンテナの数と前記性能との相関係数を求め、この求められた相関係数に応じて当該VM/コンテナ毎に重み定数を算出し、前記判断部は、前記算出されたVM/コンテナ毎の重み定数に応じてVM/コンテナ毎の増減数を定め、このVM/コンテナ毎の増減数の比で、各VM/コンテナの数を増減させるためのリソース制御量を求め、前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナの数を増減することを特徴とする請求項1に記載のオートスケール型性能保証システムである。
この構成によれば、オートスケール実行時に、VM/コンテナ毎の重み定数の比に応じたVM/コンテナ毎の増減数の比で、各VM/コンテナを増減するので、VM/コンテナ全体として、性能を最適に向上させることが可能となる。
請求項5に係る発明は、前記算出部は、前記VM/コンテナのリソース割当セット数を用い、当該リソース割当セット数と前記性能との相関係数を求め、この求められた相関係数に応じて当該VM/コンテナ毎に重み定数を算出し、前記判断部は、前記算出されたVM/コンテナ毎の重み定数に応じてVM/コンテナ毎の増減数を定め、このVM/コンテナ毎の増減数の比で、VM/コンテナ毎にリソース割当セット数を増減させるためのリソース制御量を求め、前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナ毎にリソース割当セット数を増減することを特徴とする請求項1に記載のオートスケール型性能保証システムである。
この構成によれば、オートスケール実行時に、VM/コンテナ毎の重み定数の比に応じたVM/コンテナ毎の増減数の比で、VM/コンテナ毎にリソース割当セット数を増減するので、VM/コンテナ全体として、性能を最適に向上できる。
請求項6に係る発明は、前記算出部は、前記リソースの割当量としての前記VM/コンテナの数と前記性能との相関係数を求め、この求められた相関係数が予め定められた閾値を超える場合に前記依存度を依存有り、当該閾値以下の場合に前記依存度を依存無しと定義し、当該依存無しに係るVM/コンテナ以外の依存有りのVM/コンテナ毎の相関係数に応じて当該VM/コンテナ毎に重み定数を算出し、前記判断部は、前記算出されたVM/コンテナ毎の重み定数に応じてVM/コンテナ毎の増減数を定め、このVM/コンテナ毎の増減数の比で、各VM/コンテナの数を増減させるためのリソース制御量を求め、前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナの数を増減することを特徴とする請求項1に記載のオートスケール型性能保証システムである。
この構成によれば、VM/コンテナの数と性能との相関係数が、閾値以下の場合の依存無しに係るVM/コンテナが外される。この外された残りの依存有りのVM/コンテナ毎の相関係数に応じてVM/コンテナ毎の重み定数が算出され、この重み定数に応じたVM/コンテナ毎の増減数の比で、各VM/コンテナの数が増減される。このため、VM/コンテナ全体として、性能を最適に向上できる。
請求項7に係る発明は、前記算出部は、前記リソースの割当量としての前記VM/コンテナのリソース割当セット数と前記性能との相関係数を求め、この求められた相関係数が予め定められた閾値を超える場合に前記依存度を依存有り、当該閾値以下の場合に前記依存度を依存無しと定義し、当該依存無しに係るVM/コンテナ以外の依存有りのVM/コンテナ毎の相関係数に応じて当該VM/コンテナ毎に重み定数を算出し、前記判断部は、前記算出されたVM/コンテナ毎の重み定数に応じてVM/コンテナ毎の増減数を定め、このVM/コンテナ毎の増減数の比で、VM/コンテナ毎にリソース割当セット数を増減させるためのリソース制御量を求め、前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナ毎にリソース割当セット数を増減することを特徴とする請求項1に記載のオートスケール型性能保証システムである。
この構成によれば、VM/コンテナのリソース割当セット数と性能との相関係数が、閾値以下の場合の依存無しに係るVM/コンテナが外される。この外された残りの依存有りのVM/コンテナ毎の相関係数に応じてVM/コンテナ毎の重み定数が算出され、この重み定数に応じたVM/コンテナ毎の増減数の比で、各VM/コンテナのリソース割当セット数が増減される。このため、VM/コンテナ全体として、性能を最適に向上できる。
本発明によれば、オートスケールによってVM/コンテナ数等のリソース割当量を適正に制御するオートスケール型性能保証システム及びオートスケール型性能保証方法を提供することができる。
以下、本発明の実施形態を、図面を参照して説明する。
<実施形態の構成>
図1は、本発明の実施形態に係るオートスケール型性能保証システムの構成を示すブロック図である。
図1に示すオートスケール型性能保証システム(システム)10は、複数種類のVM/コンテナを用いたネットワークにおける遅延やスループット等の通信サービスの品質を提供するための性能(又は性能値)を、トリガとしてオートスケールを行うものである。このオートスケールでは、システム10を構成するVM/コンテナの全てをスケールアウトやスケールアップしても意味が無いため、性能を向上できるVM/コンテナのみをスケールアウトやスケールアップするようにした。又は、性能を所定以上の適正値とできるVM/コンテナのみをスケールインやスケールダウンするようにした。
<実施形態の構成>
図1は、本発明の実施形態に係るオートスケール型性能保証システムの構成を示すブロック図である。
図1に示すオートスケール型性能保証システム(システム)10は、複数種類のVM/コンテナを用いたネットワークにおける遅延やスループット等の通信サービスの品質を提供するための性能(又は性能値)を、トリガとしてオートスケールを行うものである。このオートスケールでは、システム10を構成するVM/コンテナの全てをスケールアウトやスケールアップしても意味が無いため、性能を向上できるVM/コンテナのみをスケールアウトやスケールアップするようにした。又は、性能を所定以上の適正値とできるVM/コンテナのみをスケールインやスケールダウンするようにした。
このシステム10は、ネットワークで接続される複数のコンピュート11,…,11に、コントローラ12がネットワーク接続されて構成されている。各コンピュート11及びコントローラ12は、物理サーバ(サーバ)によって構成されている。なお、コンピュート11は、請求項記載の第1サーバを構成する。コントローラ12は、請求項記載の第2サーバを構成する。
但し、内部に仮想的に作られたVM/コンテナV1~V4が動くサーバを、コンピュート11と定義している。コントローラ12からVM/コンテナを増加又は削減する指示を出し、この指示に応じてコンピュート11がオートスケールによって、内部にVM/コンテナV1~V4を増設又は減設するようになっている。なお、VM/コンテナV1~V4は、V1~V4とも表現する。
コンピュート11は、データ収集部11aと、リソース制御部11bと、複数のVM/コンテナV1~V4とを備えて構成されている。
コントローラ12は、データ収集部12aと、依存度算出部12bと、オートスケール判断部12cとを備えて構成されている。データ収集部12a及び依存度算出部12bは、DB(Data Base)13に接続されている。
なお、データ収集部11a,12aは、請求項記載の収集部を構成する。リソース制御部11bは、請求項記載の制御部を構成する。依存度算出部12bは、請求項記載の算出部を構成する。オートスケール判断部12cは、請求項記載の判断部を構成する。
コンピュート11のデータ収集部11aは、VM/コンテナV1~V4のCPUやメモリ等の資源であるリソースの利用状況を含むリソース割当量のデータを収集してコントローラ12へ通知する。なお、リソースの利用状況は、物理サーバ全体のCPU使用量、VM/コンテナ数、VM/コンテナ個別のvCPU使用量、メモリ使用量などの使用状況である。
コントローラ12のデータ収集部12aは、上記通知されたデータをDB13に記憶する。
ここで、上述した性能を向上させるためには、各VM/コンテナV1~V4の増加比(又は減少比)を知る必要があり、このために、データ収集部11a,12aによってデータを収集する。これをデータ収集フェーズという。
データ収集フェーズは、サービスを構成するVM/コンテナが生成されたことを契機に、コントローラ12がコンピュート11にデータ収集を指示する。この指示に応じてコンピュート11のデータ収集部11aが、各VM/コンテナV1~V4のリソース割当量を変更しながら、変更後のリソース割当量のデータを取得し、コントローラ12のデータ収集部12aへ通知する。データ収集部12aは、その通知されたリソース割当量のデータを、DB13に記憶する。
依存度算出部12bは、データ収集部12aから依存度算出指示が有った際に、DB13に記憶されたリソース割当量のデータを基に、各VM/コンテナV1~V4の上記性能に対するリソース割当量の依存関係(依存度)を算出する。この依存度を算出することを依存度算出フェーズという。
この依存度算出フェーズでは、各V1~V4の数や、CPU数、メモリ量等のリソース割当量が、性能(性能値)に対して、どれ位依存度が有るか(どれ位関与しているか)を明らかにする。つまり、依存度算出部12bが、各V1~V4の依存度を算出し、この算出された依存度をオートスケール判断部12cに出力する。
オートスケール判断部12cは、その算出された依存度を基にオートスケールを次のように判断する。即ち、性能を適正な一定以上の性能値にしたいので、オートスケール判断部12cは、性能が低下してきた際にリソースを増加させ、性能が向上してきた際にリソースを減少させるためのリソース制御量を求め、このリソース制御量をコンピュート11のリソース制御部11bに通知する。
この依存度算出フェーズの実行後に、各VM/コンテナV1~V4に対するリソース追加/削除(増減)を行う運用フェーズを、リソース制御部11bによって次のように実行する。即ち、リソース制御部11bは、コントローラ12から通知されたリソース制御量に応じたオートスケール、即ち、スケールアウト/イン又はスケールアップ/ダウンによって、V1~V4のリソース増減を行う。
このような算出依存度に基づくリソース制御量に応じたオートスケール実行までの処理(オートスケール処理)として、次の第1~第3オートスケール処理がある。これらのオートスケール処理には、スケールアウト/イン又はスケールアップ/ダウンの2つの処理がある。
<第1オートスケール処理(スケールアウト/イン)>
前提条件としてコンピュート11において、図2のデータ収集結果の表に示すように、4つのVM/コンテナV1~V4の各々の数が、「1」~「8」の何れか場合を想定する。性能は、遅延であるとする。
前提条件としてコンピュート11において、図2のデータ収集結果の表に示すように、4つのVM/コンテナV1~V4の各々の数が、「1」~「8」の何れか場合を想定する。性能は、遅延であるとする。
この条件の場合に、VM/コンテナV1~V4の各々の数が「1」の場合に遅延が200msであり、VM/コンテナV1の数が「2」且つVM/コンテナV2~V4の各々の数が「1」の場合に遅延が180ms、VM/コンテナV1~V4の各々の数が「8」の場合に遅延が50msであるとする。これらのデータは、コントローラ12のデータ収集部12aで収集され、DB13に記憶される。
次に、依存度算出部12bにより、DB13の記憶データを基に、性能yとVM/コンテナ数xとの2つのデータの関係を示す標本共分散Sxyと、2つのデータのバラツキの大きさを表わす標本標準偏差Sx,Syとを用いて、2つのデータの相関関係を示す標本相関係数rを次式(2)から算出する。なお、標本共分散は共分散、標本標準偏差は標準偏差、標本相関係数は相関係数とも称す。
r=Sxy/SxSy …(2)
式(2)により算出された相関係数rは、図3に示すように、VM/コンテナV1が「0.6」、VM/コンテナV2が「0.1」、VM/コンテナV3が「0.0」、VM/コンテナV4が「0.8」であるとする。
通常、性能yとVM/コンテナ数xとの相関係数rが大きければ、VM/コンテナ数を増やすと性能(遅延)が向上する。そこで、性能(遅延)を向上可能とする相関係数rを判別するために、閾値を予め定める。例えば、閾値=「0.4」に定めたとする。
依存度算出部12bは、閾値「0.4」を超える相関係数r=「0.6」,「0.8」のVM/コンテナV1,V4が、性能(遅延)に影響が出るので、依存有りの「1」とする。一方、閾値「0.4」以下の相関係数r=「0.1」と「0.0」のVM/コンテナV2,V3は、性能(遅延)に影響が出ないので、依存無しの「0」とする。
つまり、VM/コンテナV1,V4は、数を増やせば性能が向上するので増加させ、VM/コンテナV2,V3は、数を増やしても性能が向上しないので増加させないように制御するためのリソース制御量が定義できる。言い換えれば、V1,V4のみを増加させるためのリソース制御量が定義できる。
このことから、オートスケール判断部12cは、上記算出された依存度「1」のVM/コンテナV1,V4のみの数を増加させるように制御するためのリソース制御量を求め、コンピュート11のリソース制御部11bに通知する。
リソース制御部11bは、その通知されたリソース制御量に応じて、図4に示すようにVM/コンテナV1,V4のみの数を増加させるスケールアウトの制御を行う。この制御により、VM/コンテナV1,V4の数が増加される。
各VM/コンテナV1~V4の数を減少させる場合も、上記同様に依存度「1」又は「0」に基づくリソース制御量に応じたスケールインの制御によって行われる。
<第1オートスケール処理(スケールアップ/ダウン)>
次に、前提条件としてコンピュート11において、図5のデータ収集結果の表に示すように、VM/コンテナV1~V4のリソース割当セット数が、「1」~「8」の何れか場合を想定する。リソース割当セット数とは、例えばリソースであるCPUのセット数が2コアの場合をいう。この場合、図7に示すように、2コアのCPU(2CPUと表わす)が「1」つとなり、この2CPU単位でリソースを増加することになる。以降、リソース割当セット数が、2CPU単位のセット数を引例とする。
次に、前提条件としてコンピュート11において、図5のデータ収集結果の表に示すように、VM/コンテナV1~V4のリソース割当セット数が、「1」~「8」の何れか場合を想定する。リソース割当セット数とは、例えばリソースであるCPUのセット数が2コアの場合をいう。この場合、図7に示すように、2コアのCPU(2CPUと表わす)が「1」つとなり、この2CPU単位でリソースを増加することになる。以降、リソース割当セット数が、2CPU単位のセット数を引例とする。
図5に示すように、V1~V4の各々のリソース割当セット数が「1」の場合に遅延が200msであり、V1のリソース割当セット数が「2」且つV2~V4の各々のリソース割当セット数が「1」の場合に遅延が180ms、V1~V4の各々のリソース割当セット数が「8」の場合に遅延が50msであるとする。これらのデータは、コントローラ12のデータ収集部12aで収集され、DB13に記憶される。
次に、依存度算出部12bにより、DB13の記憶データを基に、性能yとリソース割当セット数x1との2つのデータの関係を示す標本共分散Sx1y1と、2つのデータのバラツキの大きさを表わす標本標準偏差Sx1,Sy1とを用いて、2つのデータの相関関係を示す標本相関係数r1を次式(3)から算出する。
r1=Sx1y1/Sx1Sy1 …(3)
上式(3)により算出された性能yとリソース割当セット数x1との相関係数r1は、図6に示すように、VM/コンテナV1において「0.6」、VM/コンテナV2において「0.1」、VM/コンテナV3において「0.0」、VM/コンテナV4において「0.8」であるとする。
通常、性能yとリソース割当セット数x1との相関係数r1が大きければ、VM/コンテナのリソース割当セット数を増やすと性能(遅延)が向上する。そこで、性能(遅延)を向上可能とする相関係数r1を判別する閾値を予め定める。例えば、閾値=「0.4」に定めたとする。
依存度算出部12bは、閾値「0.4」を超える相関係数r1=「0.6」,「0.8」のV1,V4のリソース割当セット数が、性能(遅延)に影響が出るので、依存有りの「1」とする。一方、閾値「0.4」以下の相関係数r1=「0.1」,「0.0」のV2,V3のリソース割当セット数は、性能(遅延)に影響が出ないので、依存無しの「0」とする。
つまり、VM/コンテナV1,V4では、リソース割当セット数を増やせば性能が向上するので増加させ、VM/コンテナV2,V3では、リソース割当セット数を増やしても性能が向上しないので増加させないように制御するためのリソース制御量が定義できる。言い換えれば、V1,V4のリソース割当セット数のみを増加させるためのリソース制御量が定義できる。
このことから、オートスケール判断部12cは、上記算出された図6に示す依存度「1」のVM/コンテナV1,V4のみのリソース割当セット数を増加させるように制御するためのリソース制御量を求め、コンピュート11のリソース制御部11bに通知する。
リソース制御部11bは、その通知されたリソース制御量に応じて、図7に示すようにVM/コンテナV1,V4のみの2CPUのリソース割当セット数を増加させるスケールアップの制御を行う。この制御により、VM/コンテナV1,V4の2CPUのリソース割当セット数が増加される。
VM/コンテナV1~V4のリソース割当セット数を減少させる場合も、上記同様に依存度「1」又は「0」に基づくリソース制御量に応じたスケールダウンの制御によって行われる。
<第2オートスケール処理(スケールアウト/イン)>
第2オートスケール処理(スケールアウト/イン)の場合のコンピュート11の前提条件は、図2を参照して説明した第1オートスケール処理の場合と同様である。この場合、各VM/コンテナV1~V4は、数珠繋ぎのように接続されているが、全てのV1~V4を同数増加しても性能は向上しない。各V1~V4には、前述したように、VM/コンテナ数の増加に応じて性能が向上するものと、向上しないものがある。
第2オートスケール処理(スケールアウト/イン)の場合のコンピュート11の前提条件は、図2を参照して説明した第1オートスケール処理の場合と同様である。この場合、各VM/コンテナV1~V4は、数珠繋ぎのように接続されているが、全てのV1~V4を同数増加しても性能は向上しない。各V1~V4には、前述したように、VM/コンテナ数の増加に応じて性能が向上するものと、向上しないものがある。
このため、第2オートスケール処理では、各V1~V4において、多く増加させたいVM/コンテナと、そうでないVM/コンテナとを、前述した性能yとVM/コンテナ数xとの相関係数r(図3参照)に応じて重み付けを行い、この重み付けによる重み定数に応じた比率で、VM/コンテナV1~V4を増減するようにした。
従って、依存度算出部12bは、性能をy、VM/コンテナ数をxとして、重み定数wを用いて、下式(4)を求める。
y=w1x1+w2x2+w3x3+w4x4 …(4)
上式(4)の重み定数wは、図8に示すように、V1の重み定数w1が「2」、V2の重み定数w2が「1」、V3の重み定数w3が「1」、V4の重み定数w4が「3」であるとする。
重み定数wは、大きい程に傾きが大きくなって性能yが上がり易く、小さい程に傾きが小さくなって性能yが上がり難い。図8の例では、V4は、重み定数w4=「3」なので性能が上がり易く、V2,V3は、重み定数w2,w3=「1」なので性能が上がり難い。V1は、重み定数w1=「2」なのでV2,V3よりも性能が上がり易い。
このことから、オートスケール運用時に、重み定数w1~w4に応じて、V1は2セットずつ増加させ、V2,V3は1セットずつ増加させ、V4は3セットずつ増加させれば、VM/コンテナV1~V4全体として、性能を最適に向上させることが可能となる。
そこで、オートスケール判断部12cによって、各重み定数w1~W4の比(2:1:1:3)を、各VM/コンテナV1~V4の増減数の比(2:1:1:3)とし、この比(2:1:1:3)でVM/コンテナ数の増減を制御するためのリソース制御量を求める。図8の数値の場合、V1:V2:V3:V4=2:1:1:3の割合でVM/コンテナ数の増減を行えば、全体として、性能を最適に向上可能となる。
このことから、オートスケール判断部12cは、V1:V2:V3:V4=2:1:1:3の割合でVM/コンテナ数の増減を制御するためのリソース制御量を求め、コンピュート11のリソース制御部11bに通知する。
リソース制御部11bは、その通知されたリソース制御量に応じて、図9に示すように、V1は2セットずつ増加させ、V2,V3は1セットずつ増加させ、V4は3セットずつ増加させるスケールアウトの制御を行う。この制御比に応じて、各VM/コンテナV1~V4の数が増加される。
各VM/コンテナV1~V4の数を減少させる場合も、上記同様にV1:V2:V3:V4=2:1:1:3の比に基づくリソース制御量に応じたスケールインの制御によって行われる。
<第2オートスケール処理(スケールアップ/ダウン)>
第2オートスケール処理(スケールアップ/ダウン)の場合のコンピュート11の前提条件は、図5を参照して説明した第1オートスケール処理の場合と同様である。この場合、各VM/コンテナV1~V4には、前述したように、リソース割当セット数(2CPUとする)の増加に応じて性能が向上するものと、向上しないものがある。
第2オートスケール処理(スケールアップ/ダウン)の場合のコンピュート11の前提条件は、図5を参照して説明した第1オートスケール処理の場合と同様である。この場合、各VM/コンテナV1~V4には、前述したように、リソース割当セット数(2CPUとする)の増加に応じて性能が向上するものと、向上しないものがある。
このため、第2オートスケール処理では、各VM/コンテナV1~V4において、多く増加させたいVM/コンテナと、そうでないVM/コンテナとを、前述した性能yとリソース割当セット数x1との相関係数r1(図6参照)に応じて重み付けを行い、この重み付けによる重み定数に応じた比率で、VM/コンテナV1~V4のリソース割当セット数(2CPU)を増減するようにした。
従って、依存度算出部12bは、性能をya、リソース割当セット数をxaとして、重み定数waを用いて、下式(5)を求める。
ya=wa1xa1+wa2xa2+wa3xa3+wa4xa4 …(5)
上式(5)の重み定数wは、図10に示すように、V1の重み定数wa1が「2」、V2の重み定数wa2が「1」、V3の重み定数wa3が「1」、V4の重み定数wa4が「3」であるとする。重み定数waも、前述の重み定数wと同様に大きい程に傾きが大きくなって性能yが上がり易く、小さい程に傾きが小さくなって性能yが上がり難い。
このことから、オートスケール運用時に、V1では2CPUを2セットずつ増加させ、V2,V3では2CPUを1セットずつ増加させ、V4では2CPUを3セットずつ増加させれば、VM/コンテナV1~V4全体として、性能を最適に向上させることが可能となる。
そこで、オートスケール判断部12cによって、各重み定数wa1~Wa4の比(2:1:1:3)を、各VM/コンテナV1~V4のリソース割当セット数(2CPU)の増減数の比(2:1:1:3)とし、この比(2:1:1:3)でリソース割当セット数の増減を制御するためのリソース制御量を求める。図10の数値の場合、V1:V2:V3:V4=2:1:1:3の割合でリソース割当セット数を変更すれば、全体として、性能を最適に向上可能となる。
このことから、オートスケール判断部12cは、V1:V2:V3:V4=2:1:1:3の割合で、各VM/コンテナV1~V4のリソース割当セット数の増減を制御するためのリソース制御量を求め、コンピュート11のリソース制御部11bに通知する。
リソース制御部11bは、その通知されたリソース制御量に応じて、図11に示すように、V1では2CPUを2セットずつ増加させ、V2,V3では2CPUを1セットずつ増加させ、V4では2CPUを3セットずつ増加させるスケールアップの制御を行う。この制御比に応じて、各VM/コンテナV1~V4の2CPUの数が増加される。
各VM/コンテナV1~V4の2CPUの数を減少させる場合も、上記同様にV1:V2:V3:V4=2:1:1:3の比に基づくリソース制御量に応じたスケールダウンの制御によって行われる。
<第3オートスケール処理(スケールアウト/イン)>
第3オートスケール処理(スケールアウト/イン)は、第1オートスケール処理(スケールアウト/イン)と同様に、依存度算出部12bが、図3に示す各VM/コンテナV1~V4の依存度V1=「1」、V2=「0」、V3=「0」、V4=「1」を求め、この中から依存無し「0」のV2,V3をオートスケール対象から外す。
第3オートスケール処理(スケールアウト/イン)は、第1オートスケール処理(スケールアウト/イン)と同様に、依存度算出部12bが、図3に示す各VM/コンテナV1~V4の依存度V1=「1」、V2=「0」、V3=「0」、V4=「1」を求め、この中から依存無し「0」のV2,V3をオートスケール対象から外す。
次に、依存度算出部12bは、残った依存有り「1」のV1,V4を用いて、第2オートスケール処理の重み付けを行う。この場合、図8を参照するように、V1の重み定数w1が「2」、V4の重み定数w4が「3」となる。
次に、オートスケール判断部12cによって、各重み定数w1,W4の比(2:3)を、各VM/コンテナV1,V4の増減数の比(2:3)とし、この比(2:3)でVM/コンテナ数の増減を制御するためのリソース制御量を求める。このリソース制御量が、コンピュート11のリソース制御部11bに通知される。
リソース制御部11bは、その通知されたリソース制御量に応じて、図11を参照するように、V1を2セットずつ増加させ、V4を3セットずつ増加させるスケールアウトの制御を行う。この制御比に応じて、各VM/コンテナV1,V4のみの数が増加される。V1,V4の数を減少させる場合も、上記同様にV1:V4=2:3の比に基づくリソース制御量に応じたスケールインの制御によって行われる。
<第3オートスケール処理(スケールアップ/ダウン)>
第3オートスケール処理(スケールアップ/ダウン)は、第1オートスケール処理(スケールアップ/ダウン)と同様に、依存度算出部12bが、図6に示す各VM/コンテナV1~V4のリソース割当セット数(2CPUとする)の依存度V1=「1」、V2=「0」、V3=「0」、V4=「1」を求め、この中から依存無し「0」のV2,V3をオートスケール対象から外す。
第3オートスケール処理(スケールアップ/ダウン)は、第1オートスケール処理(スケールアップ/ダウン)と同様に、依存度算出部12bが、図6に示す各VM/コンテナV1~V4のリソース割当セット数(2CPUとする)の依存度V1=「1」、V2=「0」、V3=「0」、V4=「1」を求め、この中から依存無し「0」のV2,V3をオートスケール対象から外す。
次に、依存度算出部12bは、残った依存有り「1」のV1,V4を用いて、第2オートスケール処理の重み付けを行う。この場合、図10を参照するように、V1の重み定数wa1が「2」、V4の重み定数wa4が「3」となる。
次に、オートスケール判断部12cによって、各重み定数wa1,Wa4の比(2:3)を、各VM/コンテナV1,V4の増減数の比(2:3)とし、この比(2:3)でV1,V4のリソース割当セット数(2CPU)の増減を制御するためのリソース制御量を求める。このリソース制御量が、コンピュート11のリソース制御部11bに通知される。
リソース制御部11bは、その通知されたリソース制御量に応じて、図11を参照するように、V1の2CPUを2セットずつ増加させ、V4の2CPUを3セットずつ増加させるスケールアップの制御を行う。この制御比に応じて、各VM/コンテナV1,V4のみの2CPUの数が増加される。V1,V4の2CPU数を減少させる場合も、上記同様にV1:V4=2:3の比に基づくリソース制御量に応じたスケールダウンの制御によって行われる。
<実施形態の動作>
次に、本実施形態に係るオートスケール型性能保証システムの動作を、図12のシーケンス図を参照して説明する。但し、第1オートスケール処理のスケールアウト/イン処理が実行される場合を代表して説明する。
次に、本実施形態に係るオートスケール型性能保証システムの動作を、図12のシーケンス図を参照して説明する。但し、第1オートスケール処理のスケールアウト/イン処理が実行される場合を代表して説明する。
ステップS1において、コントローラ12のデータ収集部12aに、コンピュート11から各VM/コンテナV1~V4(図1)が生成されたことが通知されたとする。この通知を受けたデータ収集部12aは、ステップS2において、コンピュート11にデータ収集開始指示を行う。
この指示を受けたコンピュート11のデータ収集部11aは、ステップS3において、上記生成された各VM/コンテナV1~V4の数や、遅延やスループット等のリソースの性能値のデータ収集を開始する。
このデータ収集部は、ステップS4において、各VM/コンテナV1~V4のリソースを仮想的に追加又は削除して増減する指示(リソース追加/削除指示)を、リソース制御部11bに行う。ステップS5において、リソース制御部11bは、その指示に応じてV1~V4のリソースを仮想的に追加/削除する制御を行う。この制御では、図2に示したように、リソースとしてのV1~V4のVM/コンテナ数が仮想的に定められ、この際の性能である遅延のデータが求められる。この他に、物理サーバ全体のCPU使用量、VM/コンテナ個別のCPU使用量やリソース割当量等のリソースのデータが得られる。
ステップS6において、リソース制御部11bは、上記追加/削除により仮想的に定まったVM/コンテナ数と性能のデータをデータ収集部11aに通知する。例えば図2に示す1行目のV1~V4の全てのVM/コンテナ数の「1」と、この際の性能値である遅延=200msとのデータがデータ収集部11aに通知される。
データ収集部11aは、ステップS7において、その通知されたデータを収集し、この収集データを、ステップS8において、コントローラ12のデータ収集部12aへ転送する。この転送された収集データは、DB13(図1)に記憶される。
上記ステップS4~S8の処理は、例えば図2に示す各V1~V4の数が「1」~「8」の間で可変され、この可変時の際の遅延が得られるように繰り返される。この際、上述した物理サーバ全体のCPU使用量、VM/コンテナ個別のCPU使用量やリソース割当量等の様々なパターンのリソースのデータも得られる。この得られたデータは、DB13に記憶される。
上記ステップS4~S8の処理を繰り返すことにより、様々なパターンのデータが所定数収集されると、コンピュート11のデータ収集部11aからコントローラ12のデータ収集部12aへデータ収集完了が通知される(ステップS9)。この通知をデータ収集部12aが受けた時にデータ収集フェーズが終了する。
上記データ収集完了を受信したデータ収集部12aは、ステップS10において、依存度算出部12bに依存度の計算を依頼する。この依頼を受けた依存度算出部12bは、ステップS11において、DB13に記憶された収集データを基に、図3に示した各VM/コンテナV1~V4における性能(遅延)とVM/コンテナ数との依存度「1」及び「0」を算出する。この算出された依存度「1」及び「0」は、ステップS12において、オートスケール判断部12cへ通知される。
ステップS13において、オートスケール判断部12cは、各V1~V4の依存度「1」及び「0」に応じて、各V1~V4の数を増減(追加/削除)して設定(リソース制御設定)する。このリソース制御設定により依存度算出フェーズが終了する。
上記リソース制御設定後、オートスケール判断部12cは、ステップS14において、運用開始指示をコンピュート11へ通知する。この通知を受けたコンピュート11のデータ収集部11aは、ステップS15において、VM/コンテナV1~V4からリソース使用量のデータを収集し、この収集データを、ステップS16において、コントローラ12のデータ収集部12aへ転送する。この転送された収集データは、ステップS17において、データ収集部12aからオートスケール判断部12cへ通知される。
ステップS18において、オートスケール判断部12cは、上記ステップS13のリソース制御設定、即ち、各VM/コンテナV1~V4における性能(遅延)とVM/コンテナ数との依存度「1」及び「0」に応じて、V1~V4をどの位、増加又は減少するかを次のようにオートスケール判断する。
即ち、オートスケール判断部12cは、依存度「1」のVM/コンテナV1,V4の数を増加させ、依存度「0」のVM/コンテナV2,V3の数を増加させないように制御するためのリソース制御量を求める。オートスケール判断部12cは、その求めたリソース制御量を、ステップS19において、コンピュート11のリソース制御部11bに通知する。
ステップS20において、リソース制御部11bは、上記通知されてきたリソース制御量に応じて、図4に示すようにVM/コンテナV1,V4の数を増加させ、VM/コンテナV2,V3の数を増加させないスケールアウトの制御を行う。この制御により、VM/コンテナV1,V4の数が増加される。なお、V1,V4の数を減少させる場合は、依存度「1」又は「0」に基づくリソース制御量に応じたスケールインの制御によって行われる。
<実施形態の効果>
本実施形態に係るオートスケール型性能保証システム10の効果について説明する。このシステム10は、ネットワーク接続されたサーバに生成されるVM/コンテナV1~V4の数及び、VM/コンテナV1~V4のCPU及びメモリに代表されるリソースを追加又は削除して増減するオートスケールを行う。
本実施形態に係るオートスケール型性能保証システム10の効果について説明する。このシステム10は、ネットワーク接続されたサーバに生成されるVM/コンテナV1~V4の数及び、VM/コンテナV1~V4のCPU及びメモリに代表されるリソースを追加又は削除して増減するオートスケールを行う。
(1)複数種類のVM/コンテナV1~V4と、VM/コンテナV1~V4のリソースの割当量を収集するデータ収集部11aと、VM/コンテナV1~V4のリソースを増加又は削除により増減するオートスケールを行うリソース制御部11bとをサーバに有して成るコンピュート11を備える。更に、データ収集部11aで収集された割当量を基に、VM/コンテナV1~V4に係る通信サービス品質を提供するための性能に対して、リソースの割当量が依存する依存有りか否かを表わす依存度を算出する依存度算出部12bと、算出された依存有りの依存度に係るリソースのみを増減させるためのリソース制御量を求めるオートスケール判断部12cとをサーバに有して成るコントローラ12を備える。そして、リソース制御部11bが、オートスケール判断部12cで求められるリソース制御量に応じたオートスケールの実行によって該当VM/コンテナV1~V4のリソースを増減する構成とした。
この構成によれば、複数種類のVM/コンテナV1~V4のリソースの割当量を基に、VM/コンテナV1~V4に係る性能に対してリソースの割当量の依存度が有るか否かを求め、依存有りに該当する割当量のリソースのみをオートスケールの実行(運用)により増減可能とした。このため、従来のように、人手によるリソースの増減設定が必要なため手間暇が掛かるといったことが無くなり、本発明では、オートスケールの実行によってVM/コンテナV1~V4数等のリソース割当量を適正に制御可能となる。
(2)依存度算出部12bは、リソースの割当量としてVM/コンテナV1~V4の数を用い、当該V1~V4の数と性能との相関係数を求め、この求められた相関係数が予め定められた閾値を超える場合に依存度を依存有りとして算出する。オートスケール判断部12cは、算出された依存有りの依存度「1」に該当する割当量のV1~V4の数のみを増減させるためのリソース制御量を求める。リソース制御部11bは、リソース制御量に応じたオートスケールの実行によって該当VM/コンテナV1~V4の数を増減する構成とした。
この構成によれば、次のような効果が得られる。通常、性能とVM/コンテナV1~V4の数との相関係数が大きければ、V1~V4数を増やすと性能が向上する。このため、性能が向上する相関係数を判別するための閾値を予め定め、この閾値を相関係数が超えた際に、性能とV1~V4数との依存有りを示す依存度に該当する割当量のV1~V4数のみを増減させるようにした。これによって、例えば増加したVM/コンテナV1~V4に係る性能を向上できる。
(3)依存度算出部12bは、リソースの割当量としてVM/コンテナV1~V4のリソース割当セット数を用い、当該リソース割当セット数と性能との相関係数を求め、この求められた相関係数が閾値を超える場合に依存度を依存有りとして算出する。オートスケール判断部12cは、算出された依存有りの依存度に係るVM/コンテナV1~V4のリソース割当セット数のみを増減させるためのリソース制御量を求める。リソース制御部11bは、リソース制御量に応じたオートスケールの実行によって該当VM/コンテナV1~V4のリソース割当セット数を増減する構成とした。
この構成によれば、次のような作用効果が得られる。通常、性能とVM/コンテナV1~V4のリソース割当セット数との相関係数が大きければ、VM/コンテナV1~V4数を増やすと性能が向上する。このため、性能が向上する相関係数を判別するための閾値を予め定め、この閾値を相関係数が超えた際に、性能とリソース割当セット数との依存有りを示す依存度に該当する割当量のVM/コンテナV1~V4のリソース割当セット数のみを増減させるようにした。これによって、例えばリソース割当セット数が増加したVM/コンテナV1~V4に係る性能を向上できる。
(4)依存度算出部12bは、リソースの割当量としてVM/コンテナV1~V4の数を用い、当該VM/コンテナV1~V4の数と性能との相関係数を求め、この求められた相関係数に応じて当該VM/コンテナV1~V4毎に重み定数を算出する。オートスケール判断部12cは、算出されたVM/コンテナV1~V4毎の重み定数に応じてVM/コンテナV1~V4毎の増減数を定め、このVM/コンテナV1~V4毎の増減数の比で、各VM/コンテナV1~V4の数を増減させるためのリソース制御量を求める。リソース制御部11bは、リソース制御量に応じたオートスケールの実行によって該当VM/コンテナV1~V4の数を増減する構成とした。
この構成によれば、オートスケール実行時に、VM/コンテナV1~V4毎の重み定数の比に応じたVM/コンテナV1~V4毎の増減数の比で、各VM/コンテナV1~V4を増減するので、VM/コンテナV1~V4全体として、性能を最適に向上させることが可能となる。
(5)依存度算出部12bは、VM/コンテナV1~V4のリソース割当セット数を用い、当該リソース割当セット数と性能との相関係数を求め、この求められた相関係数に応じて当該VM/コンテナV1~V4毎に重み定数を算出する。オートスケール判断部12cは、算出されたVM/コンテナV1~V4毎の重み定数に応じてVM/コンテナV1~V4毎の増減数を定め、このVM/コンテナV1~V4毎の増減数の比で、VM/コンテナV1~V4毎にリソース割当セット数を増減させるためのリソース制御量を求める。リソース制御部11bは、リソース制御量に応じたオートスケールの実行によって該当VM/コンテナV1~V4毎にリソース割当セット数を増減する構成とした。
この構成によれば、オートスケール実行時に、VM/コンテナV1~V4毎の重み定数の比に応じたVM/コンテナV1~V4毎の増減数の比で、VM/コンテナV1~V4毎にリソース割当セット数を増減するので、VM/コンテナV1~V4全体として、性能を最適に向上できる。
(6)依存度算出部12bは、リソースの割当量としてVM/コンテナV1~V4の数を用い、当該VM/コンテナV1~V4の数と性能との相関係数を求め、この求められた相関係数が予め定められた閾値を超える場合に依存度を依存有り、当該閾値以下の場合に依存度を依存無しと定義し、当該依存無しに係るVM/コンテナV1~V4以外の依存有りのVM/コンテナV1~V4毎の相関係数に応じて当該VM/コンテナV1~V4毎に重み定数を算出する。オートスケール判断部12cは、算出されたVM/コンテナV1~V4毎の重み定数に応じてVM/コンテナV1~V4毎の増減数を定め、このVM/コンテナV1~V4毎の増減数の比で、各VM/コンテナV1~V4の数を増減させるためのリソース制御量を求める。リソース制御部11bは、リソース制御量に応じたオートスケールの実行によって該当VM/コンテナV1~V4の数を増減する構成とした。
この構成によれば、VM/コンテナV1~V4の数と性能との相関係数が、閾値以下の場合の依存無しに係るVM/コンテナV1~V4が外される。この外された残りの依存有りのVM/コンテナV1~V4毎の相関係数に応じてVM/コンテナV1~V4毎の重み定数が算出され、この重み定数に応じたVM/コンテナV1~V4毎の増減数の比で、各VM/コンテナV1~V4の数が増減される。このため、VM/コンテナV1~V4全体として、性能を最適に向上できる。
(7)依存度算出部12bは、リソースの割当量としてVM/コンテナV1~V4のリソース割当セット数を用い、当該リソース割当セット数と性能との相関係数を求め、この求められた相関係数が予め定められた閾値を超える場合に依存度を依存有り、当該閾値以下の場合に依存度を依存無しと定義し、当該依存無しに係るVM/コンテナV1~V4以外の依存有りのVM/コンテナV1~V4毎の相関係数に応じて当該VM/コンテナV1~V4毎に重み定数を算出する。オートスケール判断部12cは、算出されたVM/コンテナV1~V4毎の重み定数に応じてVM/コンテナV1~V4毎の増減数を定め、このVM/コンテナV1~V4毎の増減数の比で、VM/コンテナV1~V4毎にリソース割当セット数を増減させるためのリソース制御量を求める。リソース制御部11bは、リソース制御量に応じたオートスケールの実行によって該当VM/コンテナV1~V4毎にリソース割当セット数を増減する構成とした。
この構成によれば、VM/コンテナV1~V4のリソース割当セット数と性能との相関係数が、閾値以下の場合の依存無しに係るVM/コンテナV1~V4が外される。この外された残りの依存有りのVM/コンテナV1~V4毎の相関係数に応じてVM/コンテナV1~V4毎の重み定数が算出され、この重み定数に応じたVM/コンテナV1~V4毎の増減数の比で、各VM/コンテナV1~V4のリソース割当セット数が増減される。このため、VM/コンテナV1~V4全体として、性能を最適に向上できる。
その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
10 オートスケール型性能保証システム
11 コンピュート(第1サーバ)
11a データ収集部
11b リソース制御部
12 コントローラ(第2サーバ)
12a データ収集部
12b 依存度算出部
12c オートスケール判断部
13 DB
V1~V4 VM/コンテナ
11 コンピュート(第1サーバ)
11a データ収集部
11b リソース制御部
12 コントローラ(第2サーバ)
12a データ収集部
12b 依存度算出部
12c オートスケール判断部
13 DB
V1~V4 VM/コンテナ
Claims (8)
- ネットワーク接続されたサーバに生成されるVM(Virtual Machine)及びコンテナの何れか一方又は双方であるVM/コンテナの数及び、当該VM/コンテナのCPU(Central Processing Unit)及びメモリに代表されるリソースを追加又は削除して増減するオートスケールを行うオートスケール型性能保証システムであって、
複数種類の前記VM/コンテナと、
前記VM/コンテナのリソースの割当量を収集する収集部と、
前記VM/コンテナのリソースを増減するオートスケールを行う制御部と
を有する第1サーバを備えると共に、
前記収集された割当量を基に、前記VM/コンテナに係る通信サービス品質を提供するための性能に対して、前記リソースの割当量が依存する依存有りか否かを表わす依存度を算出する算出部と、
前記算出された依存有りの依存度に係るリソースのみを増減させるためのリソース制御量を求める判断部と
を有する第2サーバを備え、
前記制御部は、前記判断部で求められるリソース制御量に応じたオートスケールの実行によって該当VM/コンテナのリソースを増減する
ことを特徴とするオートスケール型性能保証システム。 - 前記算出部は、前記リソースの割当量としての前記VM/コンテナの数と前記性能との相関係数を求め、この求められた相関係数が予め定められた閾値を超える場合に前記依存度を依存有りとして算出し、
前記判断部は、前記算出された依存有りの依存度に係る前記VM/コンテナの数のみを増減させるためのリソース制御量を求め、
前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナの数を増減する
ことを特徴とする請求項1に記載のオートスケール型性能保証システム。 - 前記算出部は、前記リソースの割当量としての前記VM/コンテナのリソース割当セット数と前記性能との相関係数を求め、この求められた相関係数が予め定められた閾値を超える場合に前記依存度を依存有りとして算出し、
前記判断部は、前記算出された依存有りの依存度に係る前記VM/コンテナのリソース割当セット数のみを増減させるためのリソース制御量を求め、
前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナのリソース割当セット数を増減する
ことを特徴とする請求項1に記載のオートスケール型性能保証システム。 - 前記算出部は、前記リソースの割当量としての前記VM/コンテナの数と前記性能との相関係数を求め、この求められた相関係数に応じて当該VM/コンテナ毎に重み定数を算出し、
前記判断部は、前記算出されたVM/コンテナ毎の重み定数に応じてVM/コンテナ毎の増減数を定め、このVM/コンテナ毎の増減数の比で、各VM/コンテナの数を増減させるためのリソース制御量を求め、
前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナの数を増減する
ことを特徴とする請求項1に記載のオートスケール型性能保証システム。 - 前記算出部は、前記VM/コンテナのリソース割当セット数を用い、当該リソース割当セット数と前記性能との相関係数を求め、この求められた相関係数に応じて当該VM/コンテナ毎に重み定数を算出し、
前記判断部は、前記算出されたVM/コンテナ毎の重み定数に応じてVM/コンテナ毎の増減数を定め、このVM/コンテナ毎の増減数の比で、VM/コンテナ毎にリソース割当セット数を増減させるためのリソース制御量を求め、
前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナ毎にリソース割当セット数を増減する
ことを特徴とする請求項1に記載のオートスケール型性能保証システム。 - 前記算出部は、前記リソースの割当量としての前記VM/コンテナの数と前記性能との相関係数を求め、この求められた相関係数が予め定められた閾値を超える場合に前記依存度を依存有り、当該閾値以下の場合に前記依存度を依存無しと定義し、当該依存無しに係るVM/コンテナ以外の依存有りのVM/コンテナ毎の相関係数に応じて当該VM/コンテナ毎に重み定数を算出し、
前記判断部は、前記算出されたVM/コンテナ毎の重み定数に応じてVM/コンテナ毎の増減数を定め、このVM/コンテナ毎の増減数の比で、各VM/コンテナの数を増減させるためのリソース制御量を求め、
前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナの数を増減する
ことを特徴とする請求項1に記載のオートスケール型性能保証システム。 - 前記算出部は、前記リソースの割当量としての前記VM/コンテナのリソース割当セット数と前記性能との相関係数を求め、この求められた相関係数が予め定められた閾値を超える場合に前記依存度を依存有り、当該閾値以下の場合に前記依存度を依存無しと定義し、当該依存無しに係るVM/コンテナ以外の依存有りのVM/コンテナ毎の相関係数に応じて当該VM/コンテナ毎に重み定数を算出し、
前記判断部は、前記算出されたVM/コンテナ毎の重み定数に応じてVM/コンテナ毎の増減数を定め、このVM/コンテナ毎の増減数の比で、VM/コンテナ毎にリソース割当セット数を増減させるためのリソース制御量を求め、
前記制御部は、前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナ毎にリソース割当セット数を増減する
ことを特徴とする請求項1に記載のオートスケール型性能保証システム。 - ネットワーク接続されたサーバに生成されるVM及びコンテナの何れか一方又は双方であるVM/コンテナの数及び、当該VM/コンテナのCPU及びメモリに代表されるリソースを追加又は削除して増減するオートスケールを行うシステムのオートスケール型性能保証方法であって、
前記システムは、複数種類の前記VM/コンテナが生成された第1サーバと、当該第1サーバに接続された第2サーバとを備え、
前記第1サーバは、
前記VM/コンテナのリソースの割当量を収集するステップを実行し、
前記第2サーバは、
前記収集された割当量を基に、前記VM/コンテナに係る通信サービス品質を提供するための性能に対して、前記リソースの割当量が依存する依存有りか否かを表わす依存度を算出するステップと、
前記算出された依存有りの依存度に係るリソースのみを増減させるためのリソース制御量を求めるステップとを実行し、
前記第1サーバは、
前記リソース制御量に応じたオートスケールの実行によって該当VM/コンテナのリソースを増減するステップを実行する
ことを特徴とするオートスケール型性能保証方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019014761A JP7081514B2 (ja) | 2019-01-30 | 2019-01-30 | オートスケール型性能保証システム及びオートスケール型性能保証方法 |
US17/423,958 US11403151B2 (en) | 2019-01-30 | 2020-01-17 | Auto-scale performance assurance system and auto-scale performance assurance method |
PCT/JP2020/001415 WO2020158437A1 (ja) | 2019-01-30 | 2020-01-17 | オートスケール型性能保証システム及びオートスケール型性能保証方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019014761A JP7081514B2 (ja) | 2019-01-30 | 2019-01-30 | オートスケール型性能保証システム及びオートスケール型性能保証方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2020123849A JP2020123849A (ja) | 2020-08-13 |
JP7081514B2 true JP7081514B2 (ja) | 2022-06-07 |
Family
ID=71840562
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019014761A Active JP7081514B2 (ja) | 2019-01-30 | 2019-01-30 | オートスケール型性能保証システム及びオートスケール型性能保証方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US11403151B2 (ja) |
JP (1) | JP7081514B2 (ja) |
WO (1) | WO2020158437A1 (ja) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220027778A1 (en) * | 2020-07-22 | 2022-01-27 | International Business Machines Corporation | Runtime environment determination for software containers |
US11740921B2 (en) * | 2020-11-23 | 2023-08-29 | Google Llc | Coordinated container scheduling for improved resource allocation in virtual computing environment |
US20220197701A1 (en) * | 2020-12-22 | 2022-06-23 | Red Hat, Inc. | Managing resource allocation in a software-defined system |
US20220357861A1 (en) * | 2021-05-10 | 2022-11-10 | Dropbox, Inc. | Service management system for scaling services based on dependency information in a distributed database |
US20230092751A1 (en) * | 2021-09-20 | 2023-03-23 | Prophetstor Data Services, Inc. | Prediction-based method for analyzing change impact on software components |
JPWO2023084777A1 (ja) * | 2021-11-15 | 2023-05-19 | ||
JP2023102641A (ja) * | 2022-01-12 | 2023-07-25 | 株式会社日立製作所 | 計算機システム及びスケールアップ管理方法 |
Citations (2)
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 |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5745652A (en) * | 1993-10-08 | 1998-04-28 | International Business Machines Corporation | Adaptive resource allocation using neural networks |
US8185909B2 (en) * | 2007-03-06 | 2012-05-22 | Sap Ag | Predictive database resource utilization and load balancing using neural network model |
US10013281B2 (en) * | 2011-06-29 | 2018-07-03 | Microsoft Technology Licensing, Llc | Controlling network utilization |
US8756609B2 (en) * | 2011-12-30 | 2014-06-17 | International Business Machines Corporation | Dynamically scaling multi-tier applications vertically and horizontally in a cloud environment |
US20140207425A1 (en) * | 2013-01-18 | 2014-07-24 | Michael Yeung | System, Method and Apparatus for Adaptive Virtualization |
US9235801B2 (en) * | 2013-03-15 | 2016-01-12 | Citrix Systems, Inc. | Managing computer server capacity |
US9973375B2 (en) * | 2013-04-22 | 2018-05-15 | Cisco Technology, Inc. | App store portal providing point-and-click deployment of third-party virtualized network functions |
US9419916B2 (en) * | 2013-11-01 | 2016-08-16 | Google Inc. | Network fallback using resource request expectations |
US9503391B2 (en) * | 2014-04-11 | 2016-11-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for network function placement |
US20160179582A1 (en) * | 2014-12-23 | 2016-06-23 | Intel Corporation | Techniques to dynamically allocate resources for local service chains of configurable computing resources |
-
2019
- 2019-01-30 JP JP2019014761A patent/JP7081514B2/ja active Active
-
2020
- 2020-01-17 US US17/423,958 patent/US11403151B2/en active Active
- 2020-01-17 WO PCT/JP2020/001415 patent/WO2020158437A1/ja active Application Filing
Patent Citations (2)
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)
Title |
---|
伊藤 義人 Yoshito Ito,VNFのサービス要件保証に向けた性能予測の検討,電子情報通信学会2017年通信ソサイエティ大会講演論文集2 PROCEEDINGS OF THE 2017 IEICE COMMUNICAT,2017年08月29日,P.S-14,BS-4-4 |
平島 陽子 Yoko Hirashima,応答性能保証率向上のためのハイブリッドオートスケール方式 Hybrid Auto-Scaling Mechanism for Dynamic,電気学会論文誌C Vol.137 No.3 IEEJ,日本,一般社団法人電気学会 The Institute of Electrical,2017年03月01日,P.521-531 |
水野 潤 Jun MIZUNO,クラウド向けサービス性能劣化の原因特定方式の検討 Study of Baseline Analysis Method of Service Perfo,電子情報通信学会技術研究報告 Vol.116 No.507 IEICE Technical Report,日本,一般社団法人電子情報通信学会 The Institute of Ele,2017年03月02日,P.37-42 |
Also Published As
Publication number | Publication date |
---|---|
US20220091900A1 (en) | 2022-03-24 |
JP2020123849A (ja) | 2020-08-13 |
WO2020158437A1 (ja) | 2020-08-06 |
US11403151B2 (en) | 2022-08-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7081514B2 (ja) | オートスケール型性能保証システム及びオートスケール型性能保証方法 | |
US8990807B2 (en) | Virtual instance reconfiguration | |
US8725912B2 (en) | Dynamic balancing of IO resources on NUMA platforms | |
Dhari et al. | An efficient load balancing scheme for cloud computing | |
JP7081513B2 (ja) | ネットワーク性能保証システム及びネットワーク性能保証方法 | |
Hussain et al. | SLA-RALBA: cost-efficient and resource-aware load balancing algorithm for cloud computing | |
KR102640232B1 (ko) | 가상화 환경에서의 자원 할당 방법 및 장치 | |
CN103488538B (zh) | 云计算系统中的应用扩展装置和应用扩展方法 | |
CN108376103A (zh) | 一种云平台的资源平衡控制方法及服务器 | |
JP2018139064A (ja) | 仮想計算機システムおよびそのリソース割当て方法 | |
CN112433858A (zh) | 一种负载分配方法、装置、设备及可读存储介质 | |
Seth et al. | Dynamic threshold-based dynamic resource allocation using multiple VM migration for cloud computing systems | |
US11803414B2 (en) | Diagonal autoscaling of serverless computing processes for reduced downtime | |
Kumar et al. | Load balancing algorithm to minimize the makespan time in cloud environment | |
CN115640113A (zh) | 多平面弹性调度方法 | |
Komarasamy et al. | ScHeduling of jobs and Adaptive Resource Provisioning (SHARP) approach in cloud computing | |
Sharma et al. | A credits based scheduling algorithm with K-means clustering | |
US20240061718A1 (en) | Method and system for managing hybrid spark cluster for efficient spark job execution | |
JP6795536B2 (ja) | Vm性能保証システムおよびvm性能保証方法 | |
CN112685167A (zh) | 资源使用方法、电子设备和计算机程序产品 | |
JP6732693B2 (ja) | リソース割当制御システム、リソース割当制御方法、及びプログラム | |
JP6600250B2 (ja) | マルチコアcpuを有するパケット転送装置の制御装置及びプログラム | |
JP2009087213A (ja) | 計算機余力算出装置、計算機余力算出方法 | |
CN110764875A (zh) | 一种基于竞争机制的Docker容器创建方法 | |
Aluri et al. | Priority based non-preemptive shortest job first resource allocation technique in cloud computing |
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: 7081514 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |