JP6431454B2 - クラスタ内リソース管理システム、クラスタ内リソース管理方法、管理サーバ及びプログラム - Google Patents

Description

本発明は、仮想化技術が適用されたアプリケーションとしての仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに配置するクラスタ内リソース管理システム、クラスタ内リソース管理方法、管理サーバ及びプログラムに関する。

仮想化技術には、物理的なコンピュータ（サーバ）上にホストＯＳ(Operating System)を介して任意のゲストＯＳ及びアプリケーションを含む仮想マシンを配置したハイパーバイザ方式や、物理的なコンピュータ（サーバ）上にホストＯＳを介してアプリケーションを収容するコンテナを配置したコンテナ方式等がある。この仮想化技術において、アプリケーションをホストする仮想マシンやコンテナ等の仮想インスタンスを、極力少数の物理的なサーバ上に集約して、サーバのＣＰＵ(Central Processing Unit)やメモリ等のリソースを有効に使用することが行われている。

従来技術では、複数のリソース次元を持つ仮想インスタンスのサーバへの最適配置問題（後述）を、多次元のベクトルパッキング問題(Multi-dimentional Vector Packing Problem)としてモデル化し、後述の欲張り法（Greedy Method）を適用することで計算負荷を抑えつつ、サーバ数を効率的に削減する方法がある。なお、サーバは、複数のサーバが設置されたクラスタ内のサーバである。

欲張り法では、仮想インスタンスを特定の基準により並べ替えた後、１つずつの仮想インスタンスにつき、サーバの空き容量（残容量）を考慮した評価式（後述）によって最適配置先のサーバを決定している。評価式には、主に仮想インスタンスのリソース使用量ベクトルとサーバの残容量ベクトル間の差分ベクトルの大きさや内積が用いられる。

最適配置問題とは、例えば、複数の物を複数の箱に詰める際に、箱の数を最小化する問題を考えることである。言い換えれば、箱の数が最小となるように箱に物を詰める最適配置を考えることである。

本明細書中では、対象とするリソースをＣＰＵとメモリの２次元とし、図１２に示すように、仮想インスタンスとしての複数のコンテナ（物に相当）Ｃ１〜Ｃ６を、複数のサーバ（箱に相当）ＳＶ１〜ＳＶ２に詰める配置を行う際に、欲張り法によりサーバ数を常に最小限に抑制することを行う。言い換えれば、サーバ数の最小化を行うために多次元ベクトルパッキング問題の２次元版である２ＤＶＰＰ(2D Vector Packing Problem)としてモデル化し、欲張り法による解法を継続的に適用することを行う。

各サーバＳＶ１〜ＳＶ２のリソースが同一である場合に、図１３及び図１４に示す横軸をＣＰＵ使用率、縦軸をメモリ使用率とした２次元座標上に、各サーバＳＶ１〜ＳＶ２の全体容量のベクトル（サーバ全体容量ベクトル）をＶｔで表す。このベクトルＶｔは、サーバのＣＰＵ使用率１００％、メモリ使用率１００％に対応するリソース使用可能量を表す。図１３はサーバＳＶ１のリソース使用率のベクトルを示す図、図１４はサーバＳＶ２のリソース使用率のベクトルを示す図である。

まず、図１３に示すように、サーバＳＶ１に、ベクトルＶＣ１で示すＣＰＵ使用率３０％及びメモリ使用率１０％のコンテナＣ１を載せたとする。この場合、サーバＳＶ１のリソース残容量は、ＣＰＵ使用可能率１００％−３０％＝７０％、メモリ使用可能率１００％−１０％＝９０％に対応する残容量となる。次に、サーバＳＶ１に、ベクトルＶＣ３で示すＣＰＵ使用率５０％及びメモリ使用率６０％のコンテナＣ３を載せた場合、リソース残容量は、ＣＰＵ使用可能率７０％−５０％＝２０％、メモリ使用可能率９０％−６０％＝３０％に対応する残容量となる。次に、サーバＳＶ１に、ベクトルＶＣ４で示すＣＰＵ使用率２０％及びメモリ使用率３０％のコンテナＣ４を載せた場合、リソース残容量は、ＣＰＵ使用可能率２０％−２０％＝０％、メモリ使用可能率３０％−３０％＝０％に対応する残容量＝０となる。このようにサーバＳＶ１のＣＰＵ及びメモリの双方を１００％全て使い切ることが、サーバ台数を削減する上では理想的である。

しかし、サーバにメモリ使用量の多いコンテナを載せてしまうと、ＣＰＵの余力はあるが、メモリが不足し、このサーバ以外に追加のサーバが必要となってしまう。
例えば、図１４に示すように、サーバＳＶ２に、ベクトルＶＣ２で示すＣＰＵ使用率２０％及びメモリ使用率４０％のコンテナＣ２と、ベクトルＶＣ５で示すＣＰＵ使用率４０％及びメモリ使用率１０％のコンテナＣ５と、ベクトルＶＣ６で示すＣＰＵ使用率４０％及びメモリ使用率２０％のコンテナＣ６を載せたとする。この場合、リソース残容量は、ＣＰＵ使用可能率１００％−（２０＋４０＋４０）％＝０％、メモリ使用可能率１００％−（４０＋１０＋２０）％＝３０％に対応する残容量となる。つまり、メモリ使用率７０％なので、この値を１００％から減算した３０％に対応するメモリ容量が未使用リソースとして残ってしまう。

この未使用リソースを解消するために従来では、次のような手法（欲張り法）を用いていた。図１５（ａ）に示すように、６つのコンテナＣ１〜Ｃ６がある場合、これらを優先度に応じて並び替える。優先度は、例えばＣＰＵ及びメモリの合計の使用率が多い順に並び変える。この例では、コンテナＣ５が最大の優先度を有し、以降、コンテナＣ３，Ｃ２，Ｃ４，Ｃ６，Ｃ１となっている。

次に、図１５（ｂ）に示すように、コンテナＣ５を、どのサーバＳＶ１〜ＳＶ４に置けば、稼働サーバ数が最小となるようにコンテナＣ５をサーバに最適配置することができるかを判断する。この判断には、サーバＳＶ１〜ＳＶ４に「スコア」と呼ばれる値を用いる。スコアには、ベクトルの差分や内積を用いる。

差分ベクトル（差分）は、サーバＳＶの残容量ベクトルＶＳと、各コンテナＣのリソース使用量ベクトルＶＡとの差分である。この差分をサーバＳＶ１〜ＳＶ４毎に求めてスコアとして設定する。差分が小さい程に、サーバＳＶに対するコンテナＣの最適配置となるので、差分が小さい程にスコアを大きい値とする。

ベクトルの内積は、サーバＳＶの残容量ベクトルＶＳと、各コンテナＣのリソース使用量ベクトルＶＡとの内積である。この内積をサーバＳＶ１〜ＳＶ４毎に求めてスコアとして設定する。内積が大きい程に、サーバＳＶに対するコンテナＣの最適配置となるので、内積が大きい程にスコアを大きい値とする。

図１５（ｂ）の例では、サーバＳＶ１のスコアがＲ５、サーバＳＶ２のスコアがＲ２、サーバＳＶ３のスコアがＲ１、サーバＳＶ４のスコアがＲ８である。この場合、サーバＳＶ４のスコアＲ８が最も大きいので、図１５（ｃ）に示すように、サーバＳＶ４にコンテナＣ５を配置すれば最適配置となる。次に、コンテナＣ５の次のコンテナＣ３を同様にサーバＳＶ１〜ＳＶ４に対して最適配置し、以降同様に、コンテナＣ２，Ｃ４，Ｃ６，Ｃ１の順に全てを最適配置する。この種の技術内容が、例えば非特許文献１，２に開示されている。

Rina Panigrahy,et.al.,"Heuristics for Vector Bin Packing"、［online］、2011、［平成２７年７月３日検索］、インターネット〈URL:http://research .microsoft.com/a/i/c/segoe_msr_logo.png〉 Mark Stillwell,et.al.,"Resource Allocation Algorithms for Virtualized Service Hosting Platforms"、［online］、June 1, 2010、［平成２７年７月３日検索］、インターネット〈URL: http://wrs.search.yahoo.co.jp /FOR=u2BbYN1V3ija0LCM9fyn2DnbkhQ02HNwU5VLf2DemdVf.gKsIUjGD8iPVn7PTO5OHC6SYJL6okzvVCi0APeb5T0vruBSzf4YCgOTo6vjbv23mIHO0RpVK3mnxxdtric8q9kbhckT1mWhXvBzuTYuSiPmkDoya〉

しかし、上述したように、差分ベクトルでコンテナＣ（仮想インスタンス）の最適配置を評価した場合、次のような問題がある。この問題を図１６を参照して説明する。図１６（ａ）において、矢印ＶＡは、コンテナＣのリソース使用量ベクトル（「コンテナ使用量ベクトルＶＡ」又は、単に「ＶＡ」ともいう）である。矢印ＶＳ１はサーバＳＶ１のコンテナ配置前の残容量ベクトル、矢印ＶＳ２はサーバＳＶ２のコンテナ配置前の残容量ベクトルである。破線矢印ＶＳ１ａは、サーバＳＶ１のコンテナ配置後、即ち、残容量ベクトルＶＳ１からコンテナ使用量ベクトルＶＡを引いた後の残容量ベクトルである。破線矢印ＶＳ２ａは、サーバＳＶ２のコンテナ配置後、即ち、残容量ベクトルＶＳ２からコンテナ使用量ベクトルＶＡを引いた後の残容量ベクトルである。

サーバＳＶ１の残容量ベクトルＶＳ１と、サーバＳＶ２の残容量ベクトルＶＳ２とを比較すると、図１６（ｂ）に示すように、絶対値は、ＶＳ１が大、ＶＳ２が小である。コンテナ使用量ベクトルＶＡとの間の角度は、ＶＳ１が小、ＶＳ２が中である。ＶＳ−ＶＡの絶対値は、ＶＳ１が中、ＶＳ２が小である。但し、大＞中＞小の関係とする。

このような関係から、サーバＳＶ１にコンテナＣを配置した場合と、サーバＳＶ２にコンテナＣを配置した場合とでは、図１６（ａ）に示す破線矢印ＶＳ１ａとＶＳ２ａとの比較から分かるように、サーバＳＶ１にコンテナＣを配置した方が、配置後のサーバリソースの残容量がそれまでの容量に対して変化が少ない。つまり、ＶＳ２とＶＡ間の角度よりも、ＶＳ１とＶＡ間の角度の方が小さく、ＶＳ１とＶＡ間では角度差が殆んどないので、その後のコンテナの配置を考慮すると容量に変化の少ないＶＳ１の方が差分ベクトルが小さく有利となる。

一方、ＶＳ２とＶＡ間では角度差が大きいが、ベクトルの大きさが小さい。この関係から、サーバＳＶ２のリソース残容量であるメモリ容量は大きく、ＣＰＵ容量は小さいので、サーバＳＶ２にコンテナＣを配置した場合、ＣＰＵは殆んど余らないが、メモリは余ってしまうといったリソース間のアンバランスが生じる。

つまり、ＶＡは、ＶＳ１とは角度差が小さく、ＶＳ２とは角度差が大きいので、本来であればＶＳ１のサーバＳＶ１にコンテナＣを配置した方が、メモリ及びＣＰＵの双方の容量がアンバランスな余り方をしないで済む。しかし、ＶＡは、長いベクトルのＶＳ１よりも、短いベクトルＶＳ２に近い大きさのベクトルを有するので、その差分ベクトルは、ＶＳ２との差分の方が小さくなってしまう。このため、差分ベクトルの小さいサーバＳＶ２に、ＶＡを有するコンテナＣが配置されてしまう。この場合、サーバＳＶ２にＣＰＵ使用率の大きいコンテナＣを載せることになるので、ＣＰＵが不足し、このサーバ以外に追加のサーバが必要となってしまう。つまり、稼働サーバ数が増加するという問題が生じる。

次に、ベクトルの内積で最適配置を評価した場合、次のような問題がある。この問題を図１７を参照して説明する。図１７（ａ）において、矢印ＶＡは上記と同じである。矢印ＶＳ３はサーバＳＶ３のコンテナ配置前の残容量ベクトル、矢印ＶＳ４はサーバＳＶ４のコンテナ配置前の残容量ベクトルである。破線矢印ＶＳ３ａは、サーバＳＶ３のコンテナ配置後、即ち、残容量ベクトルＶＳ３からコンテナ使用量ベクトルＶＡを引いた後の残容量ベクトルである。破線矢印ＶＳ４ａは、サーバＳＶ４のコンテナ配置後、即ち、残容量ベクトルＶＳ４からコンテナ使用量ベクトルＶＡを引いた後の残容量ベクトルである。

サーバＳＶ３の残容量ベクトルＶＳ３と、サーバＳＶ４の残容量ベクトルＶＳ４とを比較すると、図１７（ｂ）に示すように、絶対値は、ＶＳ３が小、ＶＳ４が大である。コンテナ使用量ベクトルＶＡとの間の角度は、ＶＳ３が小、ＶＳ４が中である。ＶＳ・ＶＡは、ＶＳ３が小、ＶＳ４が大である。

このような関係から、サーバＳＶ３にコンテナＣを配置した場合と、サーバＳＶ４にコンテナＣを配置した場合とでは、図１７（ａ）に示す破線矢印ＶＳ３ａとＶＳ４ａとの比較から分かるように、角度差の小さいサーバＳＶ３にコンテナＣを配置した方が、配置後のサーバリソースの残容量がそれまでの容量に対して変化が少ない。つまり、ＶＳ４とＶＡ間の角度よりも、ＶＳ３とＶＡ間の角度の方が小さく、ＶＳ３とＶＡでは角度差が殆んどないので、その後のコンテナの配置を考慮すると容量に変化の少ないＶＳ３の方が有利となる。

しかし、ＶＡと、ＶＳ３又はＶＳ４の内積は、ＶＡとＶＳ３との内積よりも、ＶＡとの角度差が大きく且つベクトルが大きいＶＳ４との内積の方が大きくなってしまう。このため、ＶＡとＶＳ３の内積、ＶＡとＶＳ４の内積を取ると、内積の大きいＶＳ４が選択されてしまう。このようにリソース残容量の絶対値が大きい方のサーバＳＶ４が選択されてしまう。このため、ベクトルの内積の大きいサーバＳＶ４に、ＶＡを有するコンテナＣが配置されてしまう。この場合、サーバＳＶ４にＣＰＵ使用率の大きいコンテナＣを載せることになるので、ＣＰＵが不足し、このサーバ以外に追加のサーバが必要となってしまう。つまり、稼働サーバ数が増加するという問題が生じる。

本発明は、このような事情に鑑みてなされたものであり、複数のサーバが設置されたクラスタ内で、稼働サーバ数が最小となるように仮想インスタンスをサーバに最適配置することができるクラスタ内リソース管理システム、クラスタ内リソース管理方法、管理サーバ及びプログラムを提供することを課題とする。

上記課題を解決するための手段として、請求項１に係る発明は、アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに配置するクラスタ内リソース管理システムであって、前記仮想インスタンスのリソース使用量を記憶する記憶手段と、前記記憶手段に記憶された仮想インスタンスのリソース使用量をベクトル化したリソース使用量ベクトルと、当該リソース使用量ベクトルを有する仮想インスタンスを配置する候補となるサーバのリソース残容量ベクトルとの双方を単位ベクトル化し、当該双方の単位ベクトルの内積を求め、当該内積が最大となるサーバへ当該仮想インスタンスを配置する制御を行う計算制御手段とを有する管理サーバを備え、前記計算制御手段は、複数の前記仮想インスタンスを予め定められた優先度に応じて並び替え、この並び替えられた順で仮想インスタンス毎に、仮想インスタンスが配置可能で前記内積が最大となる最大適合率の前記サーバを検出し、この検出されたサーバに当該最大適合率の仮想インスタンスを配置する処理を行うことを特徴とするクラスタ内リソース管理システムである。

請求項５に係る発明は、アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに配置する管理サーバであって、前記仮想インスタンスのリソース使用量を記憶する記憶手段と、前記記憶手段に記憶された仮想インスタンスのリソース使用量をベクトル化したリソース使用量ベクトルと、当該リソース使用量ベクトルを有する仮想インスタンスを配置する候補となるサーバのリソース残容量ベクトルとの双方を単位ベクトル化し、当該双方の単位ベクトルの内積を求め、当該内積が最大となるサーバへ当該仮想インスタンスを配置する制御を行う計算制御手段とを備え、前記計算制御手段は、複数の前記仮想インスタンスを予め定められた優先度に応じて並び替え、この並び替えられた順で仮想インスタンス毎に、仮想インスタンスが配置可能で前記内積が最大となる最大適合率の前記サーバを検出し、この検出されたサーバに当該最大適合率の仮想インスタンスを配置する処理を行うことを特徴とする管理サーバである。

これらの請求項１，５の構成によれば、仮想インスタンスのリソース使用量ベクトル（使用量ベクトル）と、仮想インスタンスを配置する候補となるサーバのリソース残容量ベクトル（残容量ベクトル）との双方を単位ベクトル化することで、双方のベクトルの大きさが同じになる。この同じ大きさの双方の単位ベクトルの内積を取ることで、サーバの残容量ベクトルの絶対値が内積結果に次の悪影響を及ぼさなくなる。

悪影響とは、本来であれば、仮想インスタンスの使用量ベクトルとの角度差が小さい残容量ベクトルのサーバに、仮想インスタンスを配置した方が、配置後のサーバリソースの残容量がそれまでの容量に対して変化が少ない。つまり、双方のベクトルの角度差が小さい方がその後の仮想インスタンス配置の観点で有利となる。しかし、双方のベクトルの内積を求めた場合、ベクトルが大きい使用量ベクトルを有する仮想インスタンスの方が、上記の角度差が大きくても、内積が大きくなってしまうケースが生じる。このため、残容量ベクトルの絶対値の大きい方のサーバが、仮想インスタンスの配置先として選択されてしまう。

しかし、本発明では、サーバの残容量ベクトルの絶対値が双方のベクトルの内積結果に悪影響を及ぼさないように単位ベクトル化したので、角度差がより小さいのみの判定で仮想インスタンスのサーバへの最適配置を決定することができる。このため、仮想インスタンスのサーバへの最適配置を行うことができる。

請求項２に係る発明は、前記計算制御手段は、前記リクエストの変動に応じた新規の仮想インスタンスが、稼働中のサーバに配置不可能な場合に、前記稼働中のサーバと、前記新規の仮想インスタンス用のサーバを含めた稼働中のサーバにおける全ての仮想インスタンスとに対して、前記双方を単位ベクトル化し、当該双方の単位ベクトルの内積が最大となるサーバを求める計算を行い、この計算の結果、稼働対象のサーバ数が増加していれば、当該増加した数の停止中のサーバを起動させて増加分のサーバとする制御を行うことを特徴とする請求項１に記載のクラスタ内リソース管理システムである。

この構成によれば、新規のリクエストに応じた仮想インスタンスの増加時に、この増加した仮想インスタンスを最適配置可能に、サーバを増設することができる。

請求項３に係る発明は、前記管理サーバは、稼働中のサーバから前記仮想インスタンスが消去された際に、前記稼働中のサーバと、当該稼働中のサーバにおける前記消去後の全ての仮想インスタンスとに対して、前記双方を単位ベクトル化し、当該双方の単位ベクトルの内積が最大となるサーバを求める計算を行い、この計算の結果、稼働対象のサーバ数が減少していれば、当該減少した数の稼働サーバを停止させる制御を行うことを特徴とする請求項１に記載のクラスタ内リソース管理システムである。

この構成によれば、稼働中のサーバ上の仮想インスタンスがリクエストを受ける必要が無くなった等の理由により、稼働中のサーバから仮想インスタンスが消去された際に、消去後の全ての仮想インスタンスが最適に配置されるサーバを計算する。この計算の結果、稼働対象のサーバ数が減少していれば、この減少対象のサーバを停止させるようにしたので、仮想インスタンスを最適配置可能に、サーバを減少させることができる。

請求項４に係る発明は、アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに配置する管理サーバが行うクラスタ内リソース管理方法であって、前記管理サーバは、前記仮想インスタンスのリソース使用量を記憶する記憶手段を備えており、前記記憶手段に記憶された仮想インスタンスのリソース使用量をベクトル化したリソース使用量ベクトルと、前記仮想インスタンスを配置する候補となるサーバのリソース残容量ベクトルとの双方を単位ベクトル化するステップと、複数の前記仮想インスタンスを予め定められた優先度に応じて並び替えるステップと、前記並び替えられた順で仮想インスタンス毎に、前記単位ベクトル化による前記双方の単位ベクトルの内積を求め、仮想インスタンスが配置可能で当該内積が最大となる最大適合率の前記サーバを検出するステップと、前記検出されたサーバに当該最大適合率の仮想インスタンスを配置するステップとを実行することを特徴とするクラスタ内リソース管理方法である。

この方法によれば、上記請求項１に記載したように、仮想インスタンスの使用量ベクトルとサーバの残容量ベクトルとの双方を単位ベクトル化した後の角度差が、より小さいサーバへ仮想インスタンスを配置する。このため、仮想インスタンスのサーバへの最適配置を行うことができる。

請求項６に係る発明は、アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに配置する管理サーバとしてのコンピュータを、前記仮想インスタンスのリソース使用量を記憶する手段、前記記憶された仮想インスタンスのリソース使用量をベクトル化したリソース使用量ベクトルと、前記仮想インスタンスを配置する候補となるサーバのリソース残容量ベクトルとの双方を単位ベクトル化する手段、複数の前記仮想インスタンスを予め定められた優先度に応じて並び替える手段、前記並び替えられた順で仮想インスタンス毎に、前記単位ベクトル化による前記双方の単位ベクトルの内積を求め、仮想インスタンスが配置可能で当該内積が最大となる最大適合率の前記サーバを検出する手段、前記検出されたサーバに当該最大適合率の仮想インスタンスを配置する手段として機能させるためのプログラムである。

このプログラムによれば、上記請求項１，５に記載したように、仮想インスタンスのサーバへの最適配置を行うことができる。

本発明によれば、複数のサーバが設置されたクラスタ内で、稼働サーバ数が最小となるように仮想インスタンスをサーバに最適配置することができるクラスタ内リソース管理システム、クラスタ内リソース管理方法、管理サーバ及びプログラムを提供することができる。

本発明の実施形態に係るクラスタ内リソース管理システムの構成を示すブロック図である。 サーバ残容量ベクトルとコンテナリソース使用量ベクトルとを単位ベクトル化する際の説明図である。 管理サーバの構成を示すブロック図である。 サーバの構成を示すブロック図である。 （ａ）コンテナリストの一例を示す図、（ｂ）コンテナのＣＰＵ使用率及びメモリ使用率と、コンテナ使用率との一例を示す図である。 （ａ）サーバリストの一例を示す図、（ｂ）サーバのＣＰＵ使用可能率及びメモリ使用可能率の一例を示す図である。 個別コンテナリストの一例を示す図である。 本実施形態のクラスタ内リソース管理システムによるコンテナ増加時のサーバ増減動作を説明するフローチャートである。 本実施形態のクラスタ内リソース管理システムによるコンテナ減少時のサーバ増減動作を説明するフローチャートである。 本実施形態のクラスタ内リソース管理システムによるコンテナ再配置計算の処理動作を説明するフローチャートである。 本実施形態のシミュレーションに基づく効果を示す図である。 サーバへのコンテナ配置の模式図である。 従来のサーバのリソース使用率のベクトル図である。 従来の他のサーバのリソース使用率のベクトル図である。 （ａ）従来のコンテナの優先度に応じた並び替えを示す図、（ｂ）コンテナの最適化の判断の説明図、（ｃ）コンテナのサーバへの最適配置を示す図である。 差分ベクトルでサーバへのコンテナの最適配置を評価した場合の問題を説明するベクトル図である。 ベクトルの内積でサーバへのコンテナの最適配置を評価した場合の問題を説明するベクトル図である。

以下、本発明の実施形態を、図面を参照して説明する。
＜実施形態の構成＞
図１は、本発明の実施形態に係るクラスタ内リソース管理システムの構成を示すブロック図である。
本実施形態のクラスタ内リソース管理システム（システムともいう）の特徴は、リソースとしてＣＰＵ及びメモリの２次元を考慮し、仮想化技術が適用されたアプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、欲張り法を適用してクラスタ内の稼働サーバ数を最小限に抑えることが可能な、サーバへの仮想インスタンスの最適配置を行うものである。つまり、最適配置（又はコンテナ最適配置）とは、サーバにおけるリソース（ＣＰＵ＋メモリ）残容量が極力少なく又は無くなるように、サーバに仮想インスタンスを配置することである。

特に、欲張り法により仮想インスタンス毎に、当該仮想インスタンスを最適配置可能なサーバを決定する評価を行う。この評価は、仮想インスタンスのリソース使用量ベクトルと、サーバのリソース残容量（空き容量）ベクトルとの双方を単位ベクトル化し、双方の単位ベクトルの内積を取って仮想インスタンスのサーバへの最大適合率を求めることである。言い換えれば、その内積が最大となるサーバへの仮想インスタンスの配置が、仮想インスタンスのサーバへの最大適合率となる。

但し、仮想インスタンスは、アプリケーションをホストする仮想マシンやコンテナ等であり、本実施形態では、コンテナであるとする。このコンテナは、１コンテナ中に１種類のアプリケーションをホストし、固定量のリソースを物理的なサーバから確保することを前提条件とする。なお、１コンテナ中に複数種類のアプリケーションをホストする構成としてもよい。また、リソース使用量ベクトルを使用量ベクトル、リソース残容量ベクトルを残容量ベクトルともいう。
また、本実施形態では、サーバは全て同じＣＰＵ及びメモリ容量を持つ物理的なサーバとする。このため、コンテナのリソース使用量、サーバの残容量は全てＣＰＵ使用率及びメモリ使用率を用いて表すこととする。更に、リソース使用率が１００％であれば、リソース使用量が「１００」、１５％であれば「１５」となるように、以降、１対１の対応関係があるものとして記載する。なお、各サーバが異なるＣＰＵ、メモリ容量を持ってもよい。この場合、コンテナのリソース使用量、サーバの残容量は全サーバで比較可能な適切な尺度により評価する。

図１に示すシステム１０は、コンピュータであるクライアント端末機（端末機）１１と、インターネット１２と、ローカルネット１３と、ロードバランサ１４と、複数サーバが設置されたクラスタ２０と、ローカルネット２３と、管理サーバ４０とを備えて構成されている。クラスタ２０には、稼働サーバ群２１としての稼働中の各サーバＳＶ１１〜ＳＶ１４と、サーバプール２２における停止中の各サーバＳＶ２１〜２４とが設置されている。なお、各稼働サーバＳＶ１１〜ＳＶ１４と各停止サーバＳＶ２１〜２４とは、実際にはクラスタ２０内に混在配置されているが、図１においては、分かり易くするため、稼働サーバ群２１の稼働サーバＳＶ１１〜ＳＶ１４と、サーバプール２２の停止サーバＳＶ２１〜ＳＶ２４とを区分けして表した。

端末機１１と、クラスタ２０内の各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４とは、インターネット１２、ローカルネット１３及びロードバランサ１４を介して接続されている。各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４と管理サーバ４０とは、ローカルネット２３を介して接続されている。
ロードバランサ１４は、端末機１１から送信されるコンテナへのリクエストに応じた各稼働サーバＳＶ１１〜ＳＶ１４の処理負荷を分散する処理を行う。

各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４は、１種類のアプリケーションをホストするコンテナを起動できるようなコンテナエンジン（図４の符号５２ａ参照）を搭載している。また、各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４は、管理サーバ４０に対して自サーバのＣＰＵ及びメモリのリソース使用状況を通知し、この通知の応答としての管理サーバ４０からのコンテナ起動又は消去の命令に応じて、自サーバのコンテナを起動又は消去する。

稼働サーバＳＶ１１〜ＳＶ１４は、管理サーバ４０からのサーバ停止命令に応じて、自サーバをシャットダウンする。このシャットダウンされたサーバはサーバプール２２に移行する。この逆に、管理サーバ４０からの起動命令を受けた停止サーバＳＶ２１〜ＳＶ２４は、起動状態となって稼働サーバ群２１に移行する。但し、初期状態では、クラスタ２０内の全てのサーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４が停止中であり、サーバプール２２に存在する。なお、サーバプール２２のサーバＳＶ２１〜ＳＶ２４は、シャットダウン状態なので電力消費が無い状態となる。

管理サーバ４０は、稼働サーバＳＶ１１〜ＳＶ１４からリソース使用状況を収集し、コンテナ最適配置の判断を行い、この判断結果に応じて稼働サーバＳＶ１１〜ＳＶ１４にコンテナ起動又は消去命令を送信する。また、管理サーバ４０は、コンテナ最適配置の判断結果に応じて、サーバ起動又は停止の判断を行い、稼働サーバＳＶ１１〜ＳＶ１４に停止命令、サーバプール２２の停止サーバＳＶ２１〜ＳＶ２４に起動命令を送信する。

このサーバの起動命令又は停止命令は、コンテナの増加又は減少に応じて次のように実行される。
まず、コンテナ増加時について説明する。端末機１１からアプリケーションにリクエストがあると、このリクエストは、ロードバランサ１４により稼働サーバＳＶ１１〜ＳＶ１４の該当アプリケーションをホストするコンテナに対して振り分けられる。この際、稼働サーバＳＶ１１〜ＳＶ１４の全てのコンテナが新規のリクエストを処理不能であれば、後述のコンテナ最適配置の計算を行って、コンテナを新規に配置するためのサーバを起動させる必要がある。このため、停止サーバＳＶ２１〜ＳＶ２４に起動命令を送信するようになっている。

次に、コンテナ減少時について説明する。稼働サーバ（例えばＳＶ１１）において、全ての処理を終えたコンテナがある場合に、後述のコンテナ最適配置の計算を行って、全てのコンテナが消去された稼働サーバに停止命令を送信するようになっている。

コンテナ最適配置の計算について説明する。上述したコンテナの増加又は減少が発生した場合、コンテナのサーバへの組合せを再度変える。例えば、コンテナの５台が４台に、又は４台が５台となる場合に、コンテナ最適配置の計算を管理サーバ４０が行う。即ち、管理サーバ４０が、どのコンテナをどのサーバに割り当てるのが最適配置となるかを計算する。言い換えれば、サーバ台数が極力少なくなるように、コンテナのサーバへの配置先（コンテナ移動先）を変える。

より具体的には、管理サーバ４０は、コンテナ最適配置計算を行って、欲張り法によりコンテナ毎に、当該コンテナを最適配置可能なサーバを決定するが、この際、稼働サーバＳＶ１１〜ＳＶ１４のリソース残容量（ＣＰＵ使用可能率＋メモリ使用可能率）のベクトルと、コンテナのリソース使用率（ＣＰＵ使用率＋メモリ使用率）のベクトルとの双方を単位ベクトル化する。但し、ＣＰＵ使用可能率及びメモリ使用可能率は、コンテナが使用できるサーバのＣＰＵ残容量及びメモリ残容量を示すものである。

例えば、図２に示すように、各々ベクトル長が異なる、サーバ残容量ベクトルＶＳ７とコンテナ使用量ベクトルＶＡ７とを各々単位ベクトル化すると、各々同じ長さ「１」のサーバ単位ベクトルＶＳ７ａとコンテナ単位ベクトルＶＡ７ａとなる。次に、その双方の単位ベクトルＶＳ７ａ，ＶＡ７ａの内積を計算し、この計算された内積が最も大きくなる稼働サーバ（例えばＳＶ１１）をコンテナ配置先として選択する。但し、サーバとコンテナの組み合わせによっては、ＣＰＵ使用率１００％超や、メモリ使用率１００％超となる配置も生じるが、この場合、再度計算を行い、１００％超とならないようにする。

次に、コンテナのサーバへの配置先を変える場合について説明する。図１に示す管理サーバ４０は、例えば稼働サーバＳＶ１１からＳＶ１２へコンテナを移動する場合、コンテナ移動元の稼働サーバＳＶ１１にコンテナ消去命令を発し、該当コンテナを消去させる。この消去後、コンテナの移動先の稼働サーバＳＶ１２にコンテナ起動命令を発し、該当コンテナを起動させる。また、前述したリクエストに応じた新規コンテナを増加する場合は、この新規コンテナの配置先の稼働サーバ（例えばＳＶ１３）にコンテナ起動命令を発し、該当コンテナを起動させる。但し、コンテナの移動においてデータやＣＰＵ状態を保持する必要がある場合には、データやＣＰＵ状態を外部記憶装置等に一時的に保存し、移動後のコンテナに同期させるといった手段を講じるものとする。

このようにコンテナを移動した後に、１つもコンテナをホストしない稼働サーバ（例えばＳＶ１４）がある場合、管理サーバ４０はその稼働サーバＳＶ１４に停止命令を発して停止させ、サーバプール２２に移行させる。

また、上述したコンテナ最適配置計算により、コンテナを配置するためにサーバ増設が必要となった場合、管理サーバ４０は、サーバプール２２の停止サーバＳＶ２１〜ＳＶ２４にサーバ起動命令を発し、これで起動したサーバ（例えばＳＶ２１）を稼働サーバ群２１に移行させる。

このような処理を行う管理サーバ４０の構成を図３に示し、また、各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４（符号ＳＶ）の構成を図４に示し、その詳細な説明を行う。但し、各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４は、同一のリソース量（ＣＰＵ、メモリ）を備えるものとする。

図３に示す管理サーバ４０は、コンテナ配置先計算制御部４１と、サーバ制御部４２と、コンテナリスト４３と、サーバリスト４４とを備えて構成されている。コンテナ配置先計算制御部４１は、配置先計算部４１ａと、コンテナ増減制御部４１ｂと、コンテナ情報収集部４１ｃとを備える。サーバ制御部４２は、サーバ起動停止部４２ａと、サーバ情報収集部４２ｂとを備える。なお、コンテナリスト４３及びサーバリスト４４は、ハードディスク等の記憶手段に記憶されている。また、コンテナ配置先計算制御部４１は、請求項記載の計算制御手段を構成する。

コンテナリスト４３は、図５（ａ）に示すように、各コンテナ＃１〜＃３のコンテナ種別、コンテナ使用状態、コンテナ使用率、コンテナの配置先サーバ、ＣＰＵ使用率、メモリ使用率、更新フラグ、新配置先サーバの各情報を保持する。

コンテナ種別は、コンテナの種類を識別する情報（例えば、「Ａ」、「Ｂ」）が記載される。コンテナ使用状態は、「処理中」、「要起動」（図示せず）、「要消去」（図示せず）の３つの状態を取る。コンテナ使用率は、コンテナの確保したリソース使用率（ＣＰＵ使用率及びメモリ使用率）の内の現在使用している割合｛図５（ｂ）を参照して後述する｝、例えば「１０％」、「２０％」である。配置先サーバは、現在コンテナが配置されているサーバ「ＳＶ１１」、「ＳＶ１３」を示す。

ＣＰＵ使用率は、個々のコンテナ＃１〜＃３が確保するサーバのＣＰＵ使用率（コンテナが使用可能な最大値）であり、例えば「１０％」、「２０％」である。メモリ使用率は、個々のコンテナ＃１〜＃３が確保するサーバのメモリ使用率（コンテナが使用可能な最大値）であり、例えば「１０％」、「２０％」である。更新フラグは、「完了」、「起動」（図示せず）、「消去」（図示せず）、「移動」（図示せず）の４つの状態に更新される。例えば、更新フラグは、初期値「０」から「完了＝１」、「起動＝２」、「消去＝３」、「移動＝４」に更新される。新配置先サーバは、コンテナの最適配置の確定後に配置すべきサーバ、例えば「ＳＶ１２」、「ＳＶ１４」を示す。

ここで、図５（ａ）に示すコンテナ＃１のＣＰＵ使用率１０％及びメモリ使用率１０％は、図５（ｂ）に示す２次元座標で表すと、サーバＳＶの全てのＣＰＵ使用率１００％及びメモリ使用率１００％における正方形破線枠＃１ａで示す部分となる。また、コンテナ＃１のコンテナ使用率１０％は、コンテナの確保した＃１ａで示すＣＰＵ使用率１０％及びメモリ使用率１０％の内の現在使用している割合、即ち、正方形破線枠＃１ｂで示す部分となる。

図３に示すサーバリスト４４は、図６（ａ）に示すように、稼働サーバ群２１及びサーバプール２２（図１）における各サーバＳＶ１１，ＳＶ１２，ＳＶ２１のサーバ種別、サーバ状態、ＣＰＵ使用可能率、メモリ使用可能率、更新フラグの各情報を保持する。サーバ種別は、サーバの種類を識別する情報（例えば、「Ａ」）が記載される。サーバ状態は、「稼働中」、「プール」、「起動中」（図示せず）、「停止中」（図示せず）の４つの状態を取る。ＣＰＵ使用可能率は、コンテナが使用できるサーバのＣＰＵ残容量を示し、例えば「６０％」、「３０％」である。メモリ使用可能率は、コンテナが使用できるサーバのメモリ残容量を示し、例えば「５０％」、「２０％」である。更新フラグは、「増設」（図示せず）、「減設」（図示せず）、「完了」の３つの状態に更新される。例えば、更新フラグは、図示せぬ初期値「０」から「増設＝１」、「減設＝２」、「完了＝３」に更新される。

図６（ａ）に示す例えばサーバＳＶ１１のＣＰＵ使用可能率６０％及びメモリ使用可能率５０％は、図６（ｂ）に示す２次元座標で表すと、ＣＰＵ使用率及びメモリ使用率が各１００％の正方形から、４０％と５０％の正方形を除く領域ＳＶ１１ａとなる。

図３に戻って、配置先計算部４１ａは、コンテナ情報収集部４１ｃから更新されたコンテナ情報の通知を受け取り、コンテナ＃１〜＃ｎの配置先サーバを求めるためのコンテナ最適配置計算を行う。この計算は、コンテナリスト４３に存在する全コンテナ＃１〜＃３｛図５（ａ）｝に対して欲張り法を適用してコンテナ配置先のサーバＳＶを決定するものである。この決定された移動対象のコンテナ（例えば＃１）については、コンテナリスト４３内の該当コンテナ＃１に更新フラグ｛図５（ａ）｝を設定する。サーバ増減が発生する場合には、サーバリスト４４内｛図６（ａ）｝の増減サーバ（例えばＳＶ１１，ＳＶ１２）に更新フラグを設定する。この後、配置先計算部４１ａは、コンテナ増減制御部４１ｂ及びサーバ起動停止部４２ａに、コンテナ最適配置計算の完了を通知する。

コンテナ増減制御部４１ｂは、配置先計算部４１ａから最適配置計算完了通知と、サーバ起動停止部４２ａからサーバ増設通知とを受け取った場合、コンテナリスト４３内の更新フラグが「移動」に設定されたコンテナ（例えば＃１）の移動元の稼働サーバ（例えばＳＶ１１）にはコンテナ消去命令を、移動先の稼働サーバ（例えばＳＶ１２）にはコンテナ起動命令を発する。これによって移動元の稼働サーバＳＶ１１から該当コンテナが消去され、また、移動先の稼働サーバＳＶ１２では該当コンテナが起動する。更に、コンテナ増減制御部４１ｂは、消去及び起動命令を発した後、サーバ起動停止部４２ａに最適配置の完了通知を通知する。

サーバ起動停止部４２ａは、配置先計算部４１ａから最適配置計算の完了通知を受け取った場合、サーバリスト４４内｛図６（ａ）｝の更新フラグが「増設」に設定された、サーバプール２２の該当サーバ（例えばＳＶ２１）にサーバ起動命令を発する。この起動命令を受けたサーバＳＶ２１は、自サーバ起動停止部５６の制御によって自サーバを起動する。その後、サーバ起動停止部４２ａは、コンテナ増減制御部４１ｂにサーバ増設通知を行い、配置先計算部４１ａから最適配置完了通知を受け取ると、サーバリスト４４内の更新フラグが「減設」に設定された稼働サーバ（例えばＳＶ１１）にサーバ停止命令を通知する。この停止命令を受けた稼働サーバＳＶ１１は、自サーバ起動停止部５６の制御によって自サーバを停止（シャットダウン）する。

コンテナ情報収集部４１ｃは、各稼働サーバＳＶ１１〜ＳＶ１４のサーバ情報提供部５４ｂ（図４）から、当該稼働サーバＳＶ１１〜ＳＶ１４で起動中のコンテナのコンテナ情報を取得し、コンテナリスト４３を更新する。その後、コンテナ情報収集部４１ｃは、配置先計算部４１ａにコンテナ情報更新を通知する。

サーバ情報収集部４２ｂは、各稼働サーバＳＶ１１〜ＳＶ１４のサーバ情報提供部５４ｂからサーバ使用率情報を取得し、サーバリスト４４を更新する。

次に、図４に示すサーバＳＶは、監視部５１と、コンテナ部５２と、個別コンテナリスト５３と、外部連携部５４と、制御部５５と、自サーバ起動停止部５６とを備えて構成されている。監視部５１は、物理リソース監視部５１ａと、コンテナリソース監視部５１ｂとを備える。コンテナ部５２は、１又は複数のコンテナ＃１〜＃ｎと、コンテナエンジン５２ａとを備える。外部連携部５４は、配置情報受理部５４ａと、サーバ情報提供部５４ｂとを備える。制御部５５は、コンテナ起動消去部５５ａを備える。

個別コンテナリスト５３は、図７に示すように、稼働サーバＳＶ１１〜ＳＶ１４（図１）が保有するものであり、各コンテナ＃１〜＃３のコンテナ種別、コンテナ使用状態、コンテナ使用率、コンテナの配置先サーバ、ＣＰＵ使用率、メモリ使用率の各情報を保持する。これらの情報は、図５のコンテナリスト４３に示した情報と同様であるため説明を省略する。

図４に示すコンテナ＃１〜＃ｎは、１種類のアプリケーション用のサーバリソースを一定量確保し、アプリケーションを動作させる。
コンテナエンジン５２ａは、コンテナ＃１〜＃ｎをサーバ上でホストするために、サーバリソースをコンテナ毎に切り分けて各コンテナ＃１〜＃ｎに供与する。

配置情報受理部５４ａは、管理サーバ４０（図３）のコンテナ増減制御部４１ｂからコンテナ起動命令又は消去命令を受信し、コンテナ起動消去部５５ａに対してその受信命令を発する。
コンテナ起動消去部５５ａは、配置情報受理部５４ａから指定のあったコンテナ（例えば＃１）を起動又は消去する。

物理リソース監視部５１ａは、サーバＳＶのリソース使用率を定期的に取得し、サーバ情報提供部５４ｂに通知する。
コンテナリソース監視部５１ｂは、サーバＳＶ内のコンテナ＃１〜＃ｎからコンテナ使用率を定期的に取得し、サーバ情報提供部５４ｂに通知する。

サーバ情報提供部５４ｂは、物理リソース監視部５１ａからサーバリソース使用率を定期的に受け取り、管理サーバ４０のサーバ情報収集部４２ｂ（図３）へ送信する。また、サーバ情報提供部５４ｂは、コンテナリソース監視部５１ｂから各コンテナ＃１〜＃ｎのコンテナ使用率を受け取り、管理サーバ４０のコンテナ情報収集部４１ｃに送信する。

＜実施形態の動作＞
次に、本実施形態のクラスタ内リソース管理システム１０によるサーバＳＶへのコンテナ最適配置の処理を行う際の動作を、図８〜図１０に示すフローチャートを参照して説明する。

まず、図８を参照してコンテナ増加時のサーバ増減動作について説明する。
ステップＳ１において、稼働サーバ（例えばＳＶ１１）が、端末機１１からのアプリケーションへのリクエストを受信したとする。

この際、ステップＳ２において、管理サーバ４０は、各稼働サーバＳＶ１１〜ＳＶ１４の立ち上がっているコンテナ＃１〜＃ｎにおいて、上記受信したリクエストに対処可能なコンテナ＃１〜＃ｎが有るか否かを次のように判定する。

コンテナ＃１〜＃ｎでは、受信可能なリクエスト数の上限が決まっている。例えば、受信可能なリクエスト数の上限が１００件の場合に、現在８０件のコンテナが使用中であれば、まだ２０件の余裕がある。この場合、上記ステップＳ２の判定結果は、Ｙｅｓとなってコンテナ増加時のサーバ増減動作が終了する。

一方、対処可能なコンテナ＃１〜＃ｎが無ければ判定結果はＮｏとなって、ステップＳ３へ進む。このステップＳ３では、管理サーバ４０のコンテナ情報収集部４１ｃが、上記ステップＳ１で受信されたリクエストに対処するために新規にサーバＳＶに配置されるコンテナを、コンテナリスト４３に追加する。

次に、ステップＳ４において、管理サーバ４０の配置先計算部４１ａが、現在の稼働サーバＳＶ１１〜ＳＶ１４における空コンテナ及び新規コンテナを合わせた全てに対して配置先計算（この配置先計算は、前述のコンテナ最適配置計算、言い換えれば再配置計算を行うことと同じである）を行って、全コンテナの配置先サーバＳＶを決定する。なお、配置先計算部４１ａには、コンテナ情報収集部４１ｃで収集される現時点のコンテナ情報が通知され、このコンテナ情報を用いて上述の全コンテナの配置先サーバＳＶが決定される。

ここで、ステップＳ５において、配置先計算部４１ａは、上記ステップＳ４での全コンテナの配置先サーバＳＶの決定後に、サーバ台数が増加したか否かを判定する。この判定結果、サーバ台数が増加していれば、コンテナ増減制御部４１ｂが、ステップＳ６において、サーバ（例えばＳＶ１２）を増設し、サーバリスト４４内｛図６（ａ）｝の増加サーバＳＶ１２に更新フラグ「増設」を設定する。この後、ステップＳ７へ進む。

一方、上記ステップＳ５の判定結果、サーバ台数に変化無し又は減少している場合、ステップＳ７へ進む。ステップＳ７において、コンテナ増減制御部４１ｂは、再配置計算によりコンテナリスト４３内の更新フラグが設定されたコンテナ（例えば＃ｎ）の、移動元の稼働サーバ（例えばＳＶ１１）にコンテナ消去命令を通知し、これを受けた移動元の稼働サーバＳＶ１１から該当コンテナ＃ｎが消去される。

更に、ステップＳ８において、コンテナ増減制御部４１ｂは、移動先の稼働サーバＳＶ１２にコンテナ起動命令を通知し、これを受けた移動先の稼働サーバＳＶ１２の該当コンテナ＃ｎが起動する。この後、ステップＳ９において、コンテナ増減制御部４１ｂは、そのサーバ増設結果に応じてコンテナリスト４３を更新する。

次に、図９を参照してコンテナ減少時のサーバ増減動作について説明する。
ステップＳ１１において、例えば稼働サーバＳＶ１１にコンテナ＃１，＃２が配置され、サーバＳＶ１２にコンテナ＃３が配置されていた状態から、稼働サーバＳＶ１１上のコンテナ＃１がリクエストを受ける必要が無くなったとする。

ステップＳ１２において、当該サーバＳＶ１１のコンテナ起動消去部５５ａによりコンテナ＃１が消去する。この際に、ステップＳ１３において、管理サーバ４０のサーバ情報収集部４２ｂにより、その消去コンテナ＃１がコンテナリスト４３から削除される。

次に、ステップＳ１４において、配置先計算部４１ａがコンテナ最適配置計算（再配置計算）を行い、消去コンテナ＃１以外のコンテナ＃２〜＃ｎの配置先サーバＳＶを決定する。

次に、ステップＳ１５において、コンテナ増減制御部４１ｂが、その計算結果に応じて、サーバＳＶ１２のコンテナ（例えば＃２）をサーバＳＶ１１に移動し、この移動元コンテナ＃２をサーバＳＶ１２から消去する。

更に、ステップＳ１６において、コンテナ増減制御部４１ｂは、移動先の稼働サーバＳＶ１１にコンテナ起動命令を通知し、これを受けた移動先の稼働サーバＳＶ１１の該当コンテナ＃２を起動する。

次に、ステップＳ１７において、配置先計算部４１ａは、上記ステップＳ１４でのコンテナの配置先計算の結果において、サーバ台数が減少したか否かを判定する。この判定結果、サーバ台数が減少していれば、配置先計算部４１ａは、ステップＳ１８において、サーバ（例えばＳＶ１２）を減設し、サーバリスト４４内｛図６（ａ）｝のサーバＳＶ１２に更新フラグ「減設」を設定する。この後、ステップＳ１９へ進む。

一方、上記ステップＳ１７の判定結果、サーバ台数に変化なし又は増加している場合、ステップＳ１９へ進む。ステップＳ１９において、コンテナ増減制御部４１ｂは、そのサーバ減設結果に応じてコンテナリスト４３を更新する。

次に、図１０を参照してコンテナ再配置計算（コンテナ最適配置計算）の処理動作について説明する。このコンテナ再配置計算は、上述した図８のステップＳ４及び図９のステップＳ１４の再配置計算であり、配置先計算部４１ａが行う。

ステップＳ２１において、ｎ台のコンテナを優先度等の所定のパラメータに応じて並び替える。優先度は、例えばＣＰＵ及びメモリの合計の使用率が多い順である。次に、その並び替えたコンテナ＃１〜＃ｎを、１番目から最終のｎ番目までコンテナ毎に、前述の最大適合率の１台のサーバを選択する。これは、ステップＳ２２〜Ｓ３０の間で行なわれる。

まず、ステップＳ２２において、１番目のコンテナ＃１を用い、次に、ステップＳ２３において、そのコンテナ＃１に最も適合するサーバを、１番目から最終のｍ番目まで１つずつ組合せる。最初は、ステップＳ２３において、コンテナ＃１にサーバ（例えば＊１）を組合せる。

次に、ステップＳ２４において、上記ステップＳ２３での組合せられたサーバ＊１にコンテナ＃１を配置した際に、コンテナ＃１がサーバ＊１に配置可能か否かを判定する。この結果、配置不可能（Ｎｏ）であれば、ステップＳ２８において、次の２番目のサーバ＊２を組合せることを指示し、ステップＳ２３に戻って２番目のサーバ＊２を選択し、ステップＳ２４において、コンテナ＃１がサーバ＊２に配置可能か否かを判定する。

この判定結果、配置可能（Ｙｅｓ）であれば、ステップＳ２５において、適合率の計算を行う。この計算では、サーバ＊２のリソース残容量ベクトルと、コンテナ＃１のリソース使用量ベクトルとの双方を単位ベクトル化し、この双方の単位ベクトルの内積を計算して適合率を求める。

ステップＳ２６において、上記ステップＳ２５で求めた適合率が、最大適合率か否かを判定する。最初は、最大適合率（Ｙｅｓ）と判定され、ステップＳ２７において、予め設定された最大適合率の初期値（例えば「０」）が、その求められた最大適合率に更新される。この更新後、ステップＳ２８において、次の３番目のサーバ＊３を組合せることを指示し、ステップＳ２３に戻って３番目のサーバ＊３を選択し、ステップＳ２４において、コンテナ＃１がサーバ＊３に配置可能か否かを判定する。

この判定結果、配置可能（Ｙｅｓ）であれば、ステップＳ２５において、上記同様に適合率の計算を行って適合率を求める。ステップＳ２６において、その求めた適合率が、最大適合率と判定されれば、ステップＳ２７において、最大適合率が更新され、ステップＳ２８へ進む。

一方、ステップＳ２６の結果、最大で無いと判定された場合、ステップＳ２８へ進む。ステップＳ２８において、次の４番目のサーバ＊４を組合せることを指示し、ステップＳ２３に戻って４番目のサーバ＊４を選択し、ステップＳ２４において、コンテナ＃１がサーバ＊４に配置可能か否かを判定する。

このようにステップＳ２３〜Ｓ２８の処理を、最後のサーバ＊ｍまで１つずつ順番に繰り返した後、ステップＳ２９において、コンテナ＃１を最大適合率のサーバ＊ｋに配置する。

この具体例を説明する。まず、コンテナ＃１に対して、サーバ＊２は適合率が「２」、サーバ＊３は「３」、サーバ＊４は「１」、サーバ＊５は「４」であるとする。この場合、最初の適合率計算では、サーバ＊２は「２」と計算され、次のサーバ＊３では「３」と計算されるので、最大適合率は「３」に更新される。次の計算でサーバ＊４では「１」と計算され、この場合、最大適合率は更新されずにそのまま「３」となる。次にサーバ＊５で「４」と計算されると、最大適合率は「４」に更新される。このようにコンテナ＃１に対して全てのサーバ＊１〜＊ｍの中から最大適合率のサーバ＊ｋを選択し、このサーバ＊ｋにコンテナ＃１を配置する。

このような配置後、ステップＳ３０において、次の２番目のコンテナ＃２を組合せることを指示し、ステップＳ２２に戻って２番目のコンテナ＃２を選択する。次に、ステップＳ２３において、そのコンテナ＃２に最初のサーバ＊１を組合せ、ステップＳ２４において、コンテナ＃２がサーバ＊１に配置可能か否かを判定する。以降、上述のステップＳ２５〜Ｓ２７の処理を行った後、ステップＳ２８において次のサーバ＊２を指示する。このステップＳ２３〜Ｓ２８の処理を最後のサーバ＊ｍまで繰り返した後、ステップＳ２９において、コンテナ＃２を、最大適合率のサーバ＊ｈに配置する。この配置後、ステップＳ３０において、次の３番目のコンテナ＃３を組合せることを指示する。

このようにコンテナ＃１〜＃ｎ毎に、１つずつサーバ＊１〜＊ｍを組合せて最大適合率のサーバ＊ｈを検出し、この検出した最大適合率のサーバ＊ｈに該当コンテナを配置する処理を、最後のコンテナ＃ｎ及びサーバ＊ｍまで行う。これによって、個々のコンテナ＃１〜＃ｎが、最大適合率のサーバ＊ｈに配置される。

＜実施形態の効果＞
以上説明したように、本実施形態のクラスタ内リソース管理システム１０は、アプリケーションをホストするコンテナ＃１〜＃ｎへのリクエストの変動に応じ、複数のサーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４が設置されたクラスタ２０内で、コンテナ＃１〜＃ｎを各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４に最適配置するシステムである。

本実施形態の特徴は、システム１０が次の処理を行う管理サーバ４０を備えることにある。即ち、管理サーバ４０は、仮想インスタンスとしてのコンテナ＃１〜＃ｎのリソース使用量を保持するコンテナリスト４３を記憶する記憶手段と、コンテナリスト４３に保持されたコンテナ＃１〜＃ｎのリソース使用量をベクトル化したリソース使用量ベクトルと、このリソース使用量ベクトルを有するコンテナ＃１〜＃ｎを配置する候補となるサーバＳＶ１１〜ＳＶ１４のリソース残容量ベクトルとの双方を単位ベクトル化し、双方の単位ベクトルの内積を求め、内積が最大となるサーバＳＶ１１〜ＳＶ１４へコンテナ＃１〜＃ｎを配置する制御を行うコンテナ配置先計算制御部（計算制御手段）４１を有する。

この構成によれば、コンテナ＃１〜＃ｎの使用量ベクトルと、コンテナ＃１〜＃ｎを稼働サーバＳＶ１１〜ＳＶ１４に配置した際のサーバＳＶ１１〜ＳＶ１４の残容量ベクトルとの双方を単位ベクトル化することで、双方のベクトルの大きさが同じになる。この同じ大きさの双方の単位ベクトルの内積を取ることで、稼働サーバＳＶ１１〜ＳＶ１４の残容量ベクトルの絶対値が内積結果に次の悪影響を及ぼさなくなる。

悪影響とは、本来であれば、コンテナ＃１〜＃ｎの使用量ベクトルとの角度差が小さい残容量ベクトルの稼働サーバＳＶ１１〜ＳＶ１４に、コンテナ＃１〜＃ｎを配置した方が、配置後のサーバリソースの残容量がそれまでの容量に対して変化が少ない。つまり、双方のベクトルの角度差が小さい方がその後の仮想インスタンス配置の観点で有利となる。しかし、双方のベクトルの内積を求めた場合、ベクトルが大きい使用量ベクトルを有するコンテナ＃１〜＃ｎの方が、上記の角度差が大きくても、内積が大きくなってしまうケースが生じる。このため、残容量ベクトルの絶対値の大きい方のサーバＳＶ１１〜ＳＶ１４が、コンテナ＃１〜＃ｎの配置先として選択されてしまう。

しかし、本実施形態では、サーバＳＶ１１〜ＳＶ１４の残容量ベクトルの絶対値が、双方のベクトルの内積結果に悪影響を及ぼさないように単位ベクトル化したので、角度差がより小さいのみの判定でコンテナ＃１〜＃ｎのサーバＳＶ１１〜ＳＶ１４への最適配置を決定することができる。このため、コンテナ＃１〜＃ｎのサーバＳＶ１１〜ＳＶ１４への最適配置を行うことができる。

また、管理サーバ４０のコンテナ配置先計算制御部４１は、リクエストの変動に応じた新規のコンテナ＃１〜＃ｎが、稼働中のサーバＳＶ１１〜ＳＶ１４に配置不可能な場合に、稼働中のサーバＳＶ１１〜ＳＶ１４と、新規のコンテナ＃ｆ用のサーバを含めた稼働中のサーバＳＶ１１〜ＳＶ１４における全てのコンテナ＃１〜＃ｎとに対して、上述の単位ベクトル化及び内積が最大となるサーバＳＶ１１〜ＳＶ１４を求める計算を行い、この計算の結果、稼働対象のサーバＳＶ１１〜ＳＶ１４の数が増加していれば、この増加した数の停止中のサーバＳＶ２１を起動させて増加分のサーバＳＶ２１とする制御を行うようにした。

この構成によれば、新規のリクエストに応じたコンテナ＃１〜＃ｎの増加時に、この増加したコンテナ＃１〜＃ｎを最適配置可能に、サーバＳＶ２１を増設することができる。

また、管理サーバ４０のコンテナ配置先計算制御部４１は、稼働中のサーバＳＶ１１〜ＳＶ１４からコンテナ＃１〜＃ｎが消去された際に、稼働中のサーバＳＶ１１〜ＳＶ１４と、稼働中のサーバＳＶ１１〜ＳＶ１４における消去後の全てのコンテナ＃１〜＃ｎとに対して、上述の単位ベクトル化及び内積が最大となるサーバＳＶ１１〜ＳＶ１４を求める計算を行い、この計算の結果、稼働対象のサーバＳＶ１１〜ＳＶ１４の数が減少していれば、減少した数の稼働サーバＳＶ１４を停止させる制御を行うようにした。

この構成によれば、稼働中のサーバＳＶ１１〜ＳＶ１４上のコンテナ＃１〜＃ｎがリクエストを受ける必要が無くなった等の理由により、稼働中のサーバＳＶ１１〜ＳＶ１４からコンテナ＃１が消去された際に、消去後の全てのコンテナ＃２〜＃ｎが最適に配置されるサーバＳＶ１１〜ＳＶ１４を計算する。この計算結果、稼働対象のサーバＳＶ１１〜ＳＶ１４の数が減少していれば、この減少対象のサーバＳＶ１４を停止させるようにしたので、コンテナ＃２〜＃ｎを最適配置可能に、サーバＳＶ１４を減少させることができる。

ここで、システム１０において、次の条件でシミュレーションを行った場合に、図１１に示す効果が得られた。
シミュレーション条件は、各サーバ（ＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４）のリソース及びコンテナ（＃１〜＃ｎ）の使用リソースをＣＰＵとメモリとの２次元とした。また、サーバは固定容量のものを用意し、コンテナは一定量のリソースを消費するものを複数種類（ＣＰＵ及びメモリ等）用意した。サーバとコンテナの容量の関係は、１台のサーバにおよそ３〜４程度のコンテナが載せることのできるものとした。

コンテナの生成及び消滅をランダムに３０００回行い、その度に、下記方式（１）〜（３）の何れかにより、コンテナ最適配置計算により再配置を行い、リソース使用率（ＣＰＵ及びメモリ使用率の平均値）を測定した。
方式（１）は、コンテナ配置先の評価に差分ベクトルを用いる方式である。
方式（２）は、コンテナ配置先の評価に内積を用いる方式である。
方式（３）は、コンテナ配置先の評価に単位ベクトル化した後の内積を用いる方式である。
各方式（１）〜（３）を図１１の横軸に示し、また、縦軸にリソース使用率の平均（棒グラフ）及び標準偏差（誤差棒）を示した。

コンテナの生成及び消滅頻度は、ＣＰＵ重視のコンテナとメモリ重視のコンテナが同等の割合で生成及び消滅とした条件において、コンテナは４００程度生成するものとした。

この結果、図１１に各方式（１）〜（３）の棒グラフで示すように、（３）、（１）、（２）の順に、コンテナのサーバリソース使用率が高くなっており、本発明による方式（３）では、他の方式（１）よりも６％程度の改善がみられる。また、各方式（１）〜（３）の誤差棒で示す標準偏差も、方式（３）が最もバラツキが小さく良好である結果が得られた。

次に、クラスタ内リソース管理方法について説明する。この方法では、アプリケーションをホストするコンテナ＃１〜＃ｎへのリクエストの変動に応じ、複数のサーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４が設置されたクラスタ内でコンテナ＃１〜＃ｎをサーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４に配置する管理サーバ４０を有する。

管理サーバ４０は、仮想インスタンスとしてのコンテナ＃１〜＃ｎのリソース使用量を保持するコンテナリスト４３を記憶する記憶手段を備えており、コンテナリスト４３に保持されたコンテナ＃１〜＃ｎのリソース使用量をベクトル化したリソース使用量ベクトルと、このリソース使用量ベクトルを有するコンテナ＃１〜＃ｎを配置する候補となるサーバＳＶ１１〜ＳＶ１４のリソース残容量ベクトルとの双方を単位ベクトル化するステップと、単位ベクトル化による双方の単位ベクトルの内積を求めるステップと、内積が最大となるサーバＳＶ１１〜ＳＶ１４へ該当コンテナ＃１〜＃ｎを配置するステップとを実行するようにした。

この方法によれば、上述したシステム１０の効果と同様に、コンテナ＃１〜＃ｎの使用量ベクトルと稼働サーバＳＶ１１〜ＳＶ１４の残容量ベクトルとの双方の単位ベクトル化後の角度差が、より小さいサーバＳＶ１１〜ＳＶ１４へコンテナ＃１〜＃ｎを配置する。従って、コンテナ＃１〜＃ｎのサーバＳＶ１１〜ＳＶ１４への最適配置を行うことができる。

また、本実施形態のコンピュータを実行するプログラムについて説明する。コンピュータは、アプリケーションをホストするコンテナ＃１〜＃ｎへのリクエストの変動に応じ、複数のサーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４が設置されたクラスタ内でコンテナ＃１〜＃ｎをサーバＳＶ１１〜ＳＶ１４に配置する管理サーバ４０であるとする。

このプログラムは、上記コンピュータを、仮想インスタンスとしてのコンテナ＃１〜＃ｎのリソース使用量を保持するコンテナリスト４３を記憶する手段、その記憶されたコンテナ＃１〜＃ｎのリソース使用量をベクトル化したリソース使用量ベクトルと、このリソース使用量ベクトルを有するコンテナ＃１〜＃ｎを配置する候補となるサーバＳＶ１１〜ＳＶ１４のリソース残容量ベクトルとの双方を単位ベクトル化する手段、単位ベクトル化による双方の単位ベクトルの内積を求める手段、内積が最大となるサーバＳＶ１１〜ＳＶ１４へ該当コンテナ＃１〜＃ｎを配置する手段として機能させる。

このプログラムによれば、上述したシステム１０の効果と同様に、コンテナ＃１〜＃ｎのサーバＳＶ１１〜ＳＶ１４への最適配置を行うことができる。

その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。

１０ クラスタ内リソース管理システム
１１ クライアント端末機
１２ インターネット
１３，２３ ローカルネット
１４ ロードバランサ
２０ クラスタ
２１ 稼働サーバ群
２２ サーバプール
４０ 管理サーバ
４１ コンテナ配置先計算制御部（計算制御手段）
４１ａ 配置先計算部
４１ｂ コンテナ増減制御部
４１ｃ コンテナ情報収集部
４２ サーバ制御部
４２ａ サーバ起動停止部
４２ｂ サーバ情報収集部
４３ コンテナリスト
４４ サーバリスト
５１ 監視部
５１ａ 物理リソース監視部
５１ｂ コンテナリソース監視部
５２ コンテナ部
＃１〜＃ｎ コンテナ
５２ａ コンテナエンジン
５３ 個別コンテナリスト
５４ 外部連携部
５４ａ 配置情報受理部
５４ｂ サーバ情報提供部
５５ 制御部
５５ａ コンテナ起動消去部
５６ 自サーバ起動停止部
ＳＶ１１〜ＳＶ１４ 稼働サーバ
ＳＶ２１〜ＳＶ２４ 停止サーバ

Claims (6)

1. アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに配置するクラスタ内リソース管理システムであって、
   前記仮想インスタンスのリソース使用量を記憶する記憶手段と、前記記憶手段に記憶された仮想インスタンスのリソース使用量をベクトル化したリソース使用量ベクトルと、当該リソース使用量ベクトルを有する仮想インスタンスを配置する候補となるサーバのリソース残容量ベクトルとの双方を単位ベクトル化し、当該双方の単位ベクトルの内積を求め、当該内積が最大となるサーバへ当該仮想インスタンスを配置する制御を行う計算制御手段とを有する管理サーバを備え、
   前記計算制御手段は、複数の前記仮想インスタンスを予め定められた優先度に応じて並び替え、この並び替えられた順で仮想インスタンス毎に、仮想インスタンスが配置可能で前記内積が最大となる最大適合率の前記サーバを検出し、この検出されたサーバに当該最大適合率の仮想インスタンスを配置する処理を行う
   ことを特徴とするクラスタ内リソース管理システム。
2. 前記計算制御手段は、前記リクエストの変動に応じた新規の仮想インスタンスが、稼働中のサーバに配置不可能な場合に、前記稼働中のサーバと、前記新規の仮想インスタンス用のサーバを含めた稼働中のサーバにおける全ての仮想インスタンスとに対して、前記双方を単位ベクトル化し、当該双方の単位ベクトルの内積が最大となるサーバを求める計算を行い、この計算の結果、稼働対象のサーバ数が増加していれば、当該増加した数の停止中のサーバを起動させて増加分のサーバとする制御を行う
   ことを特徴とする請求項１に記載のクラスタ内リソース管理システム。
3. 前記計算制御手段は、稼働中のサーバから前記仮想インスタンスが消去された際に、前記稼働中のサーバと、当該稼働中のサーバにおける前記消去後の全ての仮想インスタンスとに対して、前記双方を単位ベクトル化し、当該双方の単位ベクトルの内積が最大となるサーバを求める計算を行い、この計算の結果、稼働対象のサーバ数が減少していれば、当該減少した数の稼働サーバを停止させる制御を行う
   ことを特徴とする請求項１に記載のクラスタ内リソース管理システム。
4. アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに配置する管理サーバが行うクラスタ内リソース管理方法であって、
   前記管理サーバは、
   前記仮想インスタンスのリソース使用量を記憶する記憶手段を備えており、
   前記記憶手段に記憶された仮想インスタンスのリソース使用量をベクトル化したリソース使用量ベクトルと、前記仮想インスタンスを配置する候補となるサーバのリソース残容量ベクトルとの双方を単位ベクトル化するステップと、
   複数の前記仮想インスタンスを予め定められた優先度に応じて並び替えるステップと、
   前記並び替えられた順で仮想インスタンス毎に、前記単位ベクトル化による前記双方の単位ベクトルの内積を求め、仮想インスタンスが配置可能で当該内積が最大となる最大適合率の前記サーバを検出するステップと、
   前記検出されたサーバに当該最大適合率の仮想インスタンスを配置するステップと
   を実行することを特徴とするクラスタ内リソース管理方法。
5. アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに配置する管理サーバであって、
   前記仮想インスタンスのリソース使用量を記憶する記憶手段と、
   前記記憶手段に記憶された仮想インスタンスのリソース使用量をベクトル化したリソース使用量ベクトルと、当該リソース使用量ベクトルを有する仮想インスタンスを配置する候補となるサーバのリソース残容量ベクトルとの双方を単位ベクトル化し、当該双方の単位ベクトルの内積を求め、当該内積が最大となるサーバへ当該仮想インスタンスを配置する制御を行う計算制御手段とを備え、
   前記計算制御手段は、複数の前記仮想インスタンスを予め定められた優先度に応じて並び替え、この並び替えられた順で仮想インスタンス毎に、仮想インスタンスが配置可能で前記内積が最大となる最大適合率の前記サーバを検出し、この検出されたサーバに当該最大適合率の仮想インスタンスを配置する処理を行う
   ことを特徴とする管理サーバ。
6. アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに配置する管理サーバとしてのコンピュータを、
   前記仮想インスタンスのリソース使用量を記憶する手段、
   前記記憶された仮想インスタンスのリソース使用量をベクトル化したリソース使用量ベクトルと、前記仮想インスタンスを配置する候補となるサーバのリソース残容量ベクトルとの双方を単位ベクトル化する手段、
   複数の前記仮想インスタンスを予め定められた優先度に応じて並び替える手段、
   前記並び替えられた順で仮想インスタンス毎に、前記単位ベクトル化による前記双方の単位ベクトルの内積を求め、仮想インスタンスが配置可能で当該内積が最大となる最大適合率の前記サーバを検出する手段、
   前記検出されたサーバに当該最大適合率の仮想インスタンスを配置する手段
   として機能させるためのプログラム。

Images