(57)【要約】【課題】仮想インスタンスを複数のサーバに再配置する際に、少ないマイグレーション数でサーバのリソース使用効率を高くする。【解決手段】クラスタ内マイグレーション管理システム１０は、アプリをホストする仮想インスタンスとしてのコンテナへのリクエストの変動に応じ、複数のサーバＳＶが設置されたクラスタ２０内でコンテナをサーバＳＶに再配置する。その再配置を行う契機と、再配置の対象となるコンテナとを少数に限定する内容を定めたマイグレポリシを備える。管理サーバ４０が、マイグレポリシに基づき、再配置を行う契機を判断し、この判断で再配置を行う際に当該再配置の対象となるコンテナを決定するように構成した。【選択図】図１
2017146791.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに再配置するクラスタ内マイグレーション管理システムであって、
前記再配置を行う契機と前記再配置の対象となる仮想インスタンスと、を少数に限定する内容を定めたポリシを記憶する記憶手段と、
前記ポリシに基づき、前記再配置を行う契機を判断し、この判断で前記再配置を行う際に当該再配置の対象となる仮想インスタンスを決定する配置制御手段と
を備えることを特徴とするクラスタ内マイグレーション管理システム。
【請求項２】
前記仮想インスタンスがマイグレーションに伴い及ぼす影響が大きい程に、前記仮想インスタンスのマイグレーションを発生しにくくさせるため、予め定められた所定パーセンテージの確率で示すコストを前記記憶手段に更に備え、
前記配置制御手段は、前記コストの確率に基づき、当該仮想インスタンスを前記再配置の対象から外す制御を行う
ことを特徴とする請求項１に記載のクラスタ内マイグレーション管理システム。
【請求項３】
前記配置制御手段は、前記再配置を行う契機を判断し、当該再配置が不要と判断された際に、新規に追加された１つの前記仮想インスタンスのみをサーバに配置する制御を行う
ことを特徴とする請求項１に記載のクラスタ内マイグレーション管理システム。
【請求項４】
アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに再配置する制御を管理サーバが行なうクラスタ内マイグレーション管理方法であって、
前記管理サーバは、
前記再配置を行う契機と前記再配置の対象となる仮想インスタンスと、を少数に限定する内容を定めたポリシを記憶する記憶手段と、
前記ポリシに基づき、前記再配置を行う契機を判断し、この判断で前記再配置を行う際に当該再配置の対象となる仮想インスタンスを決定するステップ
を実行することを特徴とするクラスタ内マイグレーション管理方法。
【請求項５】
アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに再配置する管理サーバであって、
前記再配置を行う契機と前記再配置の対象となる仮想インスタンスと、を少数に限定する内容を定めたポリシを記憶する記憶手段と、
前記ポリシに基づき、前記再配置を行う契機を判断し、この判断で前記再配置を行う際に当該再配置の対象となる仮想インスタンスを決定する配置制御手段と
を備えることを特徴とする管理サーバ。
【請求項６】
アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに再配置する管理サーバとしてのコンピュータを、
前記再配置を行う契機と前記再配置の対象となる仮想インスタンスと、を少数に限定する内容をポリシとして定める手段、
前記ポリシに基づき、前記再配置を行う契機を判断し、この判断で前記再配置を行う際に当該再配置の対象となる仮想インスタンスを決定する手段
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想化技術が適用されたアプリケーションとしての仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスのサーバへの配置先を決定する際に、少ないマイグレーション（後述）数でサーバのリソース使用効率を高めるクラスタ内マイグレーション管理システム、クラスタ内マイグレーション管理方法、管理サーバ及びプログラムに関する。
【背景技術】
【０００２】
仮想化技術には、物理的なコンピュータ（サーバ）上にホストＯＳ(Operating System)を介して任意のゲストＯＳ及びアプリケーション（アプリともいう）を含む仮想マシンを配置したハイパーバイザ方式や、物理的なコンピュータ（サーバ）上にホストＯＳを介してアプリを収容するコンテナを配置したコンテナ方式等がある。この仮想化技術において、アプリをホストする仮想マシンやコンテナ等の仮想インスタンスを、極力少数の物理的なサーバ上に集約して、サーバのＣＰＵ(Central Processing Unit)やメモリ等のリソースを有効に使用することが行われている。
【０００３】
従来技術では、複数のリソース次元を持つ仮想インスタンスのサーバへの最適配置問題（後述）を、多次元のベクトルパッキング問題(Multi-dimentional Vector Packing Problem)としてモデル化し、後述の欲張り法（Greedy Method）を適用することで計算負荷を抑えつつ、サーバ数を効率的に削減する方法がある。なお、サーバは、複数のサーバが設置されたクラスタ内のサーバである。
【０００４】
欲張り法では、仮想インスタンスを特定の基準により並べ替えた後、１つずつの仮想インスタンスにつき、サーバの空き容量（残容量）を考慮した評価式（後述）によって最適な配置先のサーバを決定している。評価式には、主に仮想インスタンスのリソース使用量ベクトルとサーバの残容量ベクトル間の差分ベクトルの大きさや内積が用いられる。
【０００５】
最適配置問題とは、例えば、複数の物を複数の箱に詰める際に、箱の数を最小化する問題を考えることである。言い換えれば、箱の数が最小となるように箱に物を詰める最適配置を考えることである。
【０００６】
本明細書中では、対象とするリソースをＣＰＵとメモリの２次元とし、図２２に示すように、仮想インスタンスとしての複数のコンテナ（物に相当）Ｃ１〜Ｃ６を、複数のサーバ（箱に相当）ＳＶ１〜ＳＶ２に詰める配置を行う際に、欲張り法によりサーバ数を常に最小限に抑制することを行う。言い換えれば、サーバ数の最小化を行うために多次元ベクトルパッキング問題の２次元版である２ＤＶＰＰ(Dimensional 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〉
【発明の概要】
【発明が解決しようとする課題】
【００１６】
しかし、上述したように、仮想インスタンスを複数のサーバに最適配置する技術を実サービスに適用する場合、配置対象となる仮想インスタンスの生成や消滅毎に、全ての仮想インスタンスのサーバへの再配置計算を行うことになる。このため、仮想インスタンスの配置先が異なる場合に生じる後述のマイグレーションが多発するという懸念がある。マイグレーションとは、仮想インスタンスがサーバから他のサーバへ移動する（配置換えされる）ことをいう。
【００１７】
マイグレーション数（マイグレ数ともいう）が多くなると、システムの運用側ではマイグレーションに係るネットワーク帯域等のネットワークリソースを消費してしまう。一方、サービス利用側（ユーザ側）では、マイグレーション時のサービス中断によるサービス品質劣化が発生することになる。
【００１８】
本発明は、このような事情に鑑みてなされたものであり、仮想インスタンスを複数のサーバに再配置する際に、少ないマイグレーション数でサーバのリソース使用効率を高くすることができるクラスタ内マイグレーション管理システム、クラスタ内マイグレーション管理方法、管理サーバ及びプログラムを提供することを課題とする。
【課題を解決するための手段】
【００１９】
上記課題を解決するための手段として、請求項１に係る発明は、アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに再配置するクラスタ内マイグレーション管理システムであって、前記再配置を行う契機と前記再配置の対象となる仮想インスタンスと、を少数に限定する内容を定めたポリシを記憶する記憶手段と、前記ポリシに基づき、前記再配置を行う契機を判断し、この判断で前記再配置を行う際に当該再配置の対象となる仮想インスタンスを決定する配置制御手段とを備えることを特徴とするクラスタ内マイグレーション管理システムである。
【００２０】
請求項４に係る発明は、アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに再配置する制御を管理サーバが行なうクラスタ内マイグレーション管理方法であって、前記管理サーバは、前記再配置を行う契機と前記再配置の対象となる仮想インスタンスと、を少数に限定する内容を定めたポリシを記憶する記憶手段と、前記ポリシに基づき、前記再配置を行う契機を判断し、この判断で前記再配置を行う際に当該再配置の対象となる仮想インスタンスを決定するステップを実行することを特徴とするクラスタ内マイグレーション管理方法である。
【００２１】
請求項５に係る発明は、アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに再配置する管理サーバであって、前記再配置を行う契機と前記再配置の対象となる仮想インスタンスと、を少数に限定する内容を定めたポリシを記憶する記憶手段と、前記ポリシに基づき、前記再配置を行う契機を判断し、この判断で前記再配置を行う際に当該再配置の対象となる仮想インスタンスを決定する配置制御手段とを備えることを特徴とする管理サーバである。
【００２２】
請求項６に係る発明は、アプリケーションをホストする仮想インスタンスへのリクエストの変動に応じ、複数のサーバが設置されたクラスタ内で仮想インスタンスをサーバに再配置する管理サーバとしてのコンピュータを、前記再配置を行う契機と前記再配置の対象となる仮想インスタンスと、を少数に限定する内容をポリシとして定める手段、前記ポリシに基づき、前記再配置を行う契機を判断し、この判断で前記再配置を行う際に当該再配置の対象となる仮想インスタンスを決定する手段として機能させるためのプログラムである。
【００２３】
請求項１及び５の構成、請求項４の方法、請求項６のプログラムによれば、仮想インスタンスを複数のサーバに再配置する際に、ポリシに基づき、仮想インスタンスをサーバに再配置する契機を少数に限定して行なうことが判断され、この判断で再配置を行う際に、再配置の対象となる仮想インスタンスが少数に限定される。このため、マイグレーション数が少なくなり、効率的にサーバのリソース使用効率を高くすることができる。
【００２４】
請求項２に係る発明は、前記仮想インスタンスがマイグレーションに伴い及ぼす影響が大きい程に、前記仮想インスタンスのマイグレーションを発生しにくくさせるため、予め定められた所定パーセンテージの確率で示すコストを前記記憶手段に更に備え、前記配置制御手段は、前記コストの確率に基づき、当該仮想インスタンスを前記再配置の対象から外す制御を行うことを特徴とする請求項１に記載のクラスタ内マイグレーション管理システムである。
【００２５】
この構成によれば、マイグレーションに伴い及ぼす影響が大きい仮想インスタンスが再配置の対象から外されるので、サービス品質を向上することができる。
【００２６】
請求項３に係る発明は、前記配置制御手段が、前記再配置を行う契機を判断し、当該再配置が不要と判断された際に、新規に追加された１つの前記仮想インスタンスのみをサーバに配置する制御を行うことを特徴とする請求項１に記載のクラスタ内マイグレーション管理システムである。
【００２７】
この構成によれば、再配置が不要と判断された際に、新規に追加された１つの仮想インスタンスのみをサーバに配置するので、１つの仮想インスタンスが１つのサーバに配置されることになる。このため、既存の仮想インスタンスがサーバから他のサーバへ移動するといったマイグレーションが生じなくなる。このような配置方法を織り交ぜることで、全体のマイグレーション数を抑えることができる。
【発明の効果】
【００２８】
本発明によれば、仮想インスタンスを複数のサーバに再配置する際に、少ないマイグレーション数でサーバのリソース使用効率を高くすることができるクラスタ内マイグレーション管理システム、クラスタ内マイグレーション管理方法、管理サーバ及びプログラムを提供することができる。
【図面の簡単な説明】
【００２９】
【図１】本発明の実施形態に係るクラスタ内マイグレーション管理システムの構成を示すブロック図である。
【図２】本発明の仮想インスタンスのサーバへの再配置の契機であるランダム契機を説明するための図である。
【図３】本発明の仮想インスタンスのサーバへの再配置の契機であるサーバ閾値契機を説明するための図である。
【図４】本発明の仮想インスタンスのサーバへの再配置の契機であるアプリ閾値契機を説明するための図である。
【図５】本発明の仮想インスタンスのサーバへの再配置の対象であるランダム対象の処理を説明するための図である。
【図６】本発明の仮想インスタンスのサーバへの再配置の対象であるサーバ閾値対象の処理を説明するための図である。
【図７】本発明の仮想インスタンスのサーバへの再配置の契機であるアプリ閾値対象の処理を説明するための図である。
【図８】マイグレーションコストを説明するための図である。
【図９】管理サーバの構成を示すブロック図である。
【図１０】サーバの構成を示すブロック図である。
【図１１】コンテナリストの一例を示す図である。
【図１２】サーバリストの一例を示す図である。
【図１３】マイグレーションポリシの一例を示す図である。
【図１４】個別コンテナリストの一例を示す図である。
【図１５】本実施形態のクラスタ内マイグレーション管理システムによるサーバへのコンテナ増設時の処理動作を説明するフローチャートである。
【図１６】本実施形態のクラスタ内マイグレーション管理システムによるサーバへのコンテナ減設時の処理動作を説明するフローチャートである。
【図１７】本実施形態のクラスタ内マイグレーション管理システムによるコンテナ再配置計算の処理動作を説明するフローチャートである。
【図１８】本実施形態のクラスタ内マイグレーション管理システムによるコンテナ単純配置計算の処理動作を説明するフローチャートである。
【図１９】本実施形態のクラスタ内マイグレーション管理システムによるサーバへのコンテナ増設時の詳細動作を説明するシーケンス図である。
【図２０】本実施形態のクラスタ内マイグレーション管理システムによるサーバへのコンテナ増設時のコンテナ再配置計算の詳細な処理を説明するシーケンス図である。
【図２１】本実施形態のクラスタ内マイグレーション管理システムによるサーバへのコンテナ増設時の詳細動作を説明するシーケンス図である。
【図２２】サーバへのコンテナ配置の模式図である。
【図２３】従来のサーバのリソース使用率のベクトル図である。
【図２４】従来の他のサーバのリソース使用率のベクトル図である。
【図２５】（ａ）従来のコンテナの優先度に応じた並び替えを示す図、（ｂ）コンテナの最適化の判断の説明図、（ｃ）コンテナのサーバへの最適配置を示す図である。
【発明を実施するための形態】
【００３０】
以下、本発明の実施形態を、図面を参照して説明する。
＜実施形態の構成＞
【００３１】
図１は、本発明の実施形態に係るクラスタ内マイグレーション管理システムの構成を示すブロック図である。
最初に、本発明の要点について説明する。本発明では、まず、アプリケーション（アプリ）をホストする仮想インスタンスへのリクエストの変動に応じ、欲張り法を適用してクラスタ内の稼働サーバ数を最小限に抑制するために、サーバへの仮想インスタンスの再配置を行う。この際、再配置計算を行う契機と、再配置計算の対象の仮想インスタンスとを絞る（少数に限定する）ためのマイグレーションポリシ（後述）を適用し、マイグレーション数（マイグレ数）に対するサーバのリソース（ＣＰＵ＋メモリ）使用効率の改善を最大限に行う。更に、アプリ毎に設定されたマイグレーションコスト（後述）に基づき、マイグレーションの有無を判断することでサービス品質を良好に保持するようにした。なお、マイグレーションポリシは請求項記載のポリシを構成し、マイグレーションコストは、請求項記載のコストを構成する。
【００３２】
言い換えれば、仮想インスタンスを複数のサーバに再配置する際に、少ないマイグレーション数でサーバのリソース使用効率を高くするようにした。なお、マイグレーションポリシをマイグレポリシともいい、マイグレーションコストをマイグレコストともいう。
【００３３】
ここで、本発明の仮想インスタンスのサーバへの再配置の契機と、再配置の対象とについて説明する。
まず、再配置の契機について説明する。再配置を行う契機としてのランダム契機、サーバ閾値契機、アプリ閾値契機（アプリケーション閾値契機）等をカテゴリとして定めた複数のマイグレポリシがある。このマイグレポリシは、再配置計算を行う契機や、再配置計算の対象となる仮想インスタンスを絞るために予め定められる。
【００３４】
ランダム契機は、時刻に沿ったアプリの発生・消滅のイベント発生毎に再配置を行うのではなく、イベント発生のｎ回につき１回等のランダムタイミング毎に再配置を行なうためのきっかけである。例えば、そのイベントが時刻ｔ１，ｔ２，ｔ３，…ｔｍ毎に１回ずつ発生する際に、イベント発生を４回毎に区切り、この４回の内の何れか１回のタイミングで仮想インスタンスの再配置を行なうとする。この場合、図２に示すように、例えば時刻ｔ３，ｔ５，ｔ９，ｔ１４，ｔ１９，ｔ２１の契機で再配置が行なわれる。なお、イベント発生の所定回数毎のタイミングで再配置を行なう等の一定間隔毎に再配置を行ってもよい。
【００３５】
サーバ閾値契機は、リソース使用率が予め定められた閾値ｔｈ１よりも低いサーバが存在する場合に、仮想インスタンスを再配置するためのきっかけである。例えば、図３に示すように、リソース使用率が、サーバＳＶ１１は８０％、サーバＳＶ１２は７０％、サーバＳＶ１３は２０％であり、閾値ｔｈ１は５０％であるとする。この場合、サーバＳＶ１３のリソース使用率＝２０％が、閾値ｔｈ１＝５０％よりも低いので、サーバＳＶ１１〜ＳＶ１３に対して仮想インスタンスの再配置が行なわれる。なお、全てのサーバのリソース使用率が高ければ（高く使われていれば）、再配置の必要はないので、再配置不要と判断される。
【００３６】
アプリ閾値契機は、予め定められた閾値ｔｈ２以上のリソース（リソース使用量）を使用するアプリをホストする仮想インスタンスが、生成又は消滅した時のみに仮想インスタンスを再配置するためのきっかけである。例えば、図４（ａ）に示すように、閾値ｔｈ２＝６０％以上のリソース使用量の仮想インスタンスＡ１が生成されたとすると、この契機で、全ての仮想インスタンスが、サーバＳＶ１１〜ＳＶ１３の何れかに再配置される。また、図４（ｂ）に示すように、サーバＳＶ１２において、閾値ｔｈ２＝６０％以上のリソース使用量の仮想インスタンスＡ２が消滅したとすると、この契機で、サーバＳＶ１１〜ＳＶ１３に全ての仮想インスタンスが再配置される。一方、閾値ｔｈ２＝６０％未満のリソース使用量のアプリをホストする仮想インスタンスが生成又は消滅しても再配置は行なわれない。
【００３７】
次に、仮想インスタンスのサーバへの再配置の対象について説明する。再配置の対象として、ランダム対象、サーバ閾値対象、アプリ閾値対象（アプリケーション閾値対象）等をカテゴリとして定めた複数のマイグレポリシがある。
【００３８】
ランダム対象の処理は、各サーバに配置された仮想インスタンスの中からランダムに仮想インスタンスを選択し、この選択した仮想インスタンスを再配置対象とする処理である。例えば、図５に示すように、サーバＳＶ１１に仮想インスタンスＡ１，Ａ３が配置され、サーバＳＶ１２に仮想インスタンスＡ２，Ａ５が、サーバＳＶ１３に仮想インスタンスＡ４，Ａ６が配置されているとする。この場合に、各サーバＳＶ１１〜ＳＶ１３に配置された仮想インスタンスＡ１〜Ａ６からランダムに仮想インスタンスＡ４，Ａ５，Ａ６を選択し、この選択した仮想インスタンスＡ４〜Ａ６を再配置対象とする。
【００３９】
サーバ閾値対象の処理は、サーバにリソース使用率の閾値ｔｈ３を予め定めておき、その閾値ｔｈ３を下回ったリソース使用率のサーバに配置された仮想インスタンスのみを、再配置対象とする処理である。例えば、図６に示すように、リソース使用率は、サーバＳＶ１１が８０％、サーバＳＶ１２が７０％、サーバＳＶ１３が２０％であり、閾値ｔｈ３は５０％であるとする。この場合、サーバＳＶ１３のリソース使用率＝２０％は、閾値ｔｈ３＝５０％を下回っているので、サーバＳＶ１３に配置された仮想インスタンスＡ４，Ａ６のみを、再配置対象とする。
【００４０】
アプリ閾値対象の処理は、アプリのリソース使用量の閾値ｔｈ４を予め定めておき、サーバに配置されたアプリの内、リソース使用量が閾値ｔｈ４を下回っているアプリをホストする仮想インスタンスのみを再配置対象とする処理である。リソース使用量が大きいアプリは、マイグレーション時の影響が大きいので再配置対象としたくはない。そこで、マイグレーション時の影響が大きいリソース使用量の境界を閾値ｔｈ４で表し、リソース使用量が閾値ｔｈ４を下回るアプリをホストする仮想インスタンスを再配置対象とし、閾値ｔｈ４以上のアプリをホストする仮想インスタンスを再配置対象から除外する。
【００４１】
例えば、図７に示すように、サーバＳＶ１２に配置された仮想インスタンスＡ２のリソース使用量が７０％であり、仮想インスタンスＡ５のリソース使用量が４０％であり、閾値ｔｈ４は５０％であるとする。この場合、閾値ｔｈ４＝５０％を下回るリソース使用量＝４０％の仮想インスタンスＡ５を再配置対象とする。同様に、サーバＳＶ１３に配置された仮想インスタンスＡ４，Ａ６の内、仮想インスタンスＡ６が閾値ｔｈ４を下回っているとすると、仮想インスタンスＡ６を再配置対象とする。
【００４２】
次に、マイグレコストは、アプリのマイグレーションのし易さ又はし難さを表すものであり、アプリの再配置の対象を絞るために用いられる。なお、アプリには、当該アプリのリソース使用量に応じて、マイグレーションし易いものと、し難いものとがある。
本発明では、マイグレコストは、仮想インスタンスが再配置の対象となった場合に実際にマイグレーションが発生する割合（又は確率）を「０％〜１００％」で示している。確率が「０％」であればマイグレーションされないことを表す。換言すれば、サーバへの仮想インスタンスの再配置が行なわれないことを表す。「７０％」であれば７０％の割合でマイグレーションされること、つまり、７０％の確率で再配置が行なわれることを表す。「１００％」であれば必ずマイグレーションされる（再配置される）ことを表す。
【００４３】
例えば、図８（ａ）に示すように、各サーバＳＶ１１〜ＳＶ１３に配置された仮想インスタンスＡ１〜Ａ６からランダムに仮想インスタンスＡ４，Ａ５，Ａ６が選択され、この選択された仮想インスタンスＡ４〜Ａ６が再配置対象とされているとする。この場合に、例えば仮想インスタンスＡ４のマイグレコストが５０％の場合、２回に１回の割合で、図８（ｂ）に示すように、仮想インスタンスＡ４が再配置対象から外されることになる。
【００４４】
次に、図１に示す本実施形態のクラスタ内マイグレーション管理システム（システム）１０について説明する。
但し、本実施形態で再配置とは、少ないマイグレーション数でサーバのリソース（ＣＰＵ＋メモリ）使用効率が高くなるように、仮想インスタンスを複数のサーバに再配置することである。仮想インスタンスは、アプリをホストする仮想マシンやコンテナ等であり、本実施形態では、コンテナであるとする。このコンテナは、１コンテナ中に１種類のアプリをホストし、固定量のリソースを物理的なサーバ（物理サーバ）から確保することを前提条件とする。なお、１コンテナ中に複数種類のアプリをホストする構成としてもよい。また、サーバは、全て同じＣＰＵ及びメモリ容量を持つ物理サーバとする。
【００４５】
図１に示すシステム１０は、コンピュータであるクライアント端末機（端末機）１１と、インターネット１２と、ローカルネット１３と、ロードバランサ１４と、複数サーバが設置されたクラスタ２０と、ローカルネット２３と、管理サーバ４０とを備えて構成されている。クラスタ２０には、稼働サーバ群２１としての稼働中の各サーバＳＶ１１〜ＳＶ１４と、サーバプール２２における停止中の各サーバＳＶ２１〜２４とが設置されている。
【００４６】
なお、各稼働サーバＳＶ１１〜ＳＶ１４と各停止サーバＳＶ２１〜２４とは、実際にはクラスタ２０内に混在配置されているが、図１においては、分かり易くするため、稼働サーバ群２１の稼働サーバＳＶ１１〜ＳＶ１４と、サーバプール２２の停止サーバＳＶ２１〜ＳＶ２４とを区分けして表した。
【００４７】
端末機１１と、クラスタ２０内の各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４とは、インターネット１２、ローカルネット１３及びロードバランサ１４を介して接続されている。各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４と管理サーバ４０とは、ローカルネット２３を介して接続されている。
【００４８】
ロードバランサ１４は、端末機１１から送信されるコンテナへのリクエストに応じた各稼働サーバＳＶ１１〜ＳＶ１４の処理負荷を分散する処理を行う。この際、ロードバランサ１４は、管理サーバ４０からの制御信号Ｇ１が入力されることにより、コンテナへのリクエストを他のサーバへ変更する処理を行う。
【００４９】
ここで、管理サーバ４０は、各稼働サーバＳＶ１１〜ＳＶ１４のコンテナ利用状況をコンテナリスト４３（図１１参照）で管理しているので、例えば、特定のコンテナがクライアントのリクエストに対応できない場合に、ロードバランサ１４に、別のサーバにリクエストを送るように制御信号Ｇ１で指示する。これにより、新規にコンテナを入れるサーバができるので、ロードバランサ１４は、そのサーバにリクエストを入れるように処理する。このように、稼働サーバＳＶ１１〜ＳＶ１４のコンテナ利用状況の変化に対応するために、管理サーバ４０からロードバランサに制御信号Ｇ１で指示を行うようになっている。
【００５０】
各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４は、１種類のアプリをホストするコンテナを起動できるようなコンテナエンジン（図１０の符号５２ａ参照）を搭載している。また、各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４は、管理サーバ４０に対して自サーバのリソース使用状況を通知し、この通知の応答としての管理サーバ４０からのコンテナ起動又は消去の命令に応じて、自サーバのコンテナを起動又は消去する。
【００５１】
稼働サーバＳＶ１１〜ＳＶ１４は、管理サーバ４０からのサーバ停止命令に応じて、自サーバをシャットダウンする。このシャットダウンされたサーバはサーバプール２２に移行する。この逆に、管理サーバ４０からの起動命令を受けた停止サーバＳＶ２１〜ＳＶ２４は、起動状態となって稼働サーバ群２１に移行する。但し、初期状態では、クラスタ２０内の全てのサーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４が停止中であり、サーバプール２２に存在する。なお、サーバプール２２のサーバＳＶ２１〜ＳＶ２４は、シャットダウン状態なので電力消費が無い状態となる。
【００５２】
管理サーバ４０は、稼働サーバＳＶ１１〜ＳＶ１４からリソース使用状況を収集し、コンテナ配置先の決定を行い、決定結果に応じて稼働サーバＳＶ１１〜ＳＶ１４にコンテナ起動又は消去命令を送信する。また、管理サーバ４０は、コンテナ再配置の判断結果に応じて、サーバ起動又は停止の判断を行い、判断結果に応じて稼働サーバＳＶ１１〜ＳＶ１４に停止命令、サーバプール２２の停止サーバＳＶ２１〜ＳＶ２４に起動命令を送信する。
【００５３】
この管理サーバ４０によるサーバの起動命令又は停止命令は、コンテナの増加（又は増設）又は減少（又は減設）に応じて次のように実行される。
まず、コンテナ増加時について説明する。端末機１１からアプリにリクエストがあると、このリクエストは、ロードバランサ１４により稼働サーバＳＶ１１〜ＳＶ１４の該当アプリをホストするコンテナに対して振り分けられる。この際、稼働サーバＳＶ１１〜ＳＶ１４の全てのコンテナが新規のリクエストを処理不能であれば、新規コンテナ起動のため後述するコンテナ再配置の計算又は後述のコンテナ単純配置の計算を行う。これら計算結果に応じて、コンテナを新規に配置するためのサーバを起動させる必要がある。このため、停止サーバＳＶ２１〜ＳＶ２４に起動命令を送信するようになっている。
【００５４】
コンテナ単純配置（単純配置ともいう）とは、新しく追加された１つのコンテナのみをサーバに配置することである。この単純配置を行う場合、既にサーバに配置されたコンテナは据え置き、新しく追加された１つのコンテナのみをサーバに配置する。
【００５５】
次に、コンテナ減少時について説明する。稼働サーバ（例えばＳＶ１１）において、全ての処理を終えたコンテナがある場合に、管理サーバ４０は、後述するコンテナ再配置の計算を行う。これら計算結果に応じて、全てのコンテナが消去された稼働サーバに停止命令を送信するようになっている。
【００５６】
コンテナ再配置を行う場合の契機判断について説明する。上述したコンテナの増加又は減少が発生した場合に、前述したランダム契機、サーバ閾値契機、アプリ閾値契機等を定めたマイグレポリシに基づき、既存のコンテナをサーバに再配置する必要性を判断する。この判断では、前述したようにコンテナの再配置の契機が強制的に減少するようになっている。
【００５７】
コンテナ再配置が必要と判断された場合、管理サーバ４０はコンテナ再配置の計算を行いコンテナの移動先サーバを決定する。この再配置計算において、管理サーバ４０は、欲張り法によりコンテナ毎に配置すべきサーバを決定する。
【００５８】
次に、コンテナ増加時のコンテナ単純配置について説明する。上述したコンテナ再配置の契機判断において、再配置が不要と判断された場合、管理サーバ４０がコンテナ単純配置の計算を行い新規コンテナの配置先サーバを決定する。コンテナ単純配置の計算においては、管理サーバは欲張り法により当該コンテナを配置すべきサーバを決定する。
【００５９】
次に、コンテナのサーバへの配置先を変える場合について説明する。図１に示す管理サーバ４０は、例えば稼働サーバＳＶ１１からＳＶ１２へコンテナを移動する場合、コンテナ移動元の稼働サーバＳＶ１１にコンテナ消去命令を発し、該当コンテナを消去させる。この消去後、コンテナの移動先の稼働サーバＳＶ１２にコンテナ起動命令を発し、該当コンテナを起動させてコンテナを移動する。また、前述したリクエストに応じた新規コンテナを増加する場合は、この新規コンテナの配置先の稼働サーバ（例えばＳＶ１３）にコンテナ起動命令を発し、該当コンテナを起動させる。但し、コンテナの移動においてデータやＣＰＵ状態を保持する必要がある場合には、データやＣＰＵ状態を外部記憶装置等に一時的に保存し、移動後のコンテナに同期させるといった手段を講じるものとする。
【００６０】
このようにコンテナを移動した後に、１つもコンテナをホストしない稼働サーバ（例えばＳＶ１４）がある場合、管理サーバ４０はその稼働サーバＳＶ１４に停止命令を発して停止させ、サーバプール２２に移行させる。
【００６１】
また、コンテナ再配置計算により、コンテナを配置するためにサーバ増設が必要となった場合、管理サーバ４０は、サーバプール２２の停止サーバＳＶ２１〜ＳＶ２４にサーバ起動命令を発し、これで起動したサーバ（例えばＳＶ２１）を稼働サーバ群２１に移行させる。
【００６２】
このような処理を行う管理サーバ４０の構成を図９に示し、また、各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４（符号ＳＶ）の構成を図１０に示し、その詳細な説明を行う。但し、各サーバＳＶ１１〜ＳＶ１４，ＳＶ２１〜ＳＶ２４は、同一のリソース量（ＣＰＵ、メモリ）を備えるものとする。
【００６３】
図９に示す管理サーバ４０は、コンテナ配置計算制御部４１と、サーバ制御部４２と、コンテナリスト４３と、サーバリスト４４と、マイグレポリシ４５とを備えて構成されている。
コンテナ配置計算制御部４１は、再配置契機判断部４１ａと、対象サーバ・コンテナ決定部４１ｂと、配置計算部４１ｃとを備える。
サーバ制御部４２は、サーバ起動停止部４２ａと、サーバ情報収集部４２ｂと、コンテナ増減制御部４２ｃと、コンテナ情報収集部４２ｄとを備える。なお、コンテナリスト４３、サーバリスト４４、マイグレポリシ（マイグレーションポリシ）４５は、ハードディスク等の記憶手段に記憶されている。また、コンテナ配置計算制御部４１は、請求項記載の配置制御手段を構成する。
【００６４】
コンテナリスト４３は、図１１に示すように、各コンテナ＃１〜＃３の中のアプリ種別、コンテナ使用状態、コンテナ使用率、コンテナの配置先サーバ、ＣＰＵ使用率、メモリ使用率、マイグレコスト、更新フラグ、新配置先サーバの各情報を保持する。
【００６５】
アプリ種別には、コンテナ中のアプリの種類を識別する情報（例えば、「Ａ」、「Ｂ」）が記載される。コンテナ使用状態は、「処理中」、「要起動」（図示せず）、「要消去」（図示せず）の３つの状態を取る。コンテナ使用率は、コンテナの確保したリソース使用率（ＣＰＵ使用率及びメモリ使用率）の内の現在使用している割合、例えば「１０％」、「２０％」である。配置先サーバは、現在コンテナが配置されているサーバ「ＳＶ１１」、「ＳＶ１３」を示す。
【００６６】
ＣＰＵ使用率は、個々のコンテナ＃１〜＃３が確保するサーバのＣＰＵ使用率（コンテナが使用可能な最大値）であり、例えば「１０％」、「２０％」である。メモリ使用率は、個々のコンテナ＃１〜＃３が確保するサーバのメモリ使用率（コンテナが使用可能な最大値）であり、例えば「１０％」、「２０％」である。
【００６７】
マイグレコストは、コンテナが再配置の対象となった場合に実際にマイグレーションが発生する割合を「０％〜１００％」で示し、本例では「０％」、「６０％」で示している。例えば「６０％」であれば６０％の割合でサーバへのコンテナの再配置が行なわれること、つまり、６０％の割合でコンテナがマイグレーションされることを表す。なお、割合が「０％」であればサーバへのコンテナの再配置が行なわれないこと、つまり、マイグレーションされないことを表す。因みに「１００％」であれば必ずマイグレーションされる（再配置される）ことを表す。
【００６８】
更新フラグは、「完了」、「起動」（図示せず）、「消去」（図示せず）、「移動」（図示せず）の４つの状態に更新される。例えば、更新フラグは、初期値「０」から「完了＝１」、「起動＝２」、「消去＝３」、「移動＝４」に更新される。新配置先サーバは、コンテナの最適配置の確定後に配置すべきサーバ、例えば「ＳＶ１２」、「ＳＶ１４」を示す。
【００６９】
図１２に示すように、サーバリスト４４は、稼働サーバ群２１及びサーバプール２２（図１）における各サーバＳＶ１１，ＳＶ１２，ＳＶ２１のサーバ種別、サーバ状態、ＣＰＵ使用可能率、メモリ使用可能率、更新フラグの各情報を保持する。
サーバ種別には、サーバの種類を識別する情報（例えば、「Ａ」）が記載される。サーバ状態は、「稼働中」、「プール」、「起動中」（図示せず）、「停止中」（図示せず）の４つの状態を取る。
【００７０】
ＣＰＵ使用可能率は、コンテナが使用できるサーバのＣＰＵ残容量を示し、例えば「６０％」、「３０％」である。メモリ使用可能率は、コンテナが使用できるサーバのメモリ残容量を示し、例えば「５０％」、「２０％」である。更新フラグは、「増設」（図示せず）、「減設」（図示せず）、「完了」の３つの状態に更新される。例えば、更新フラグは、図示せぬ初期値「０」から「増設＝１」、「減設＝２」、「完了＝３」に更新される。
【００７１】
図１３に示すマイグレポリシ４５は、再配置の契機や、再配置の対象となるコンテナを絞るために予め定められたポリシであり、各ポリシＰ１〜Ｐ６のカテゴリ、カテゴリの方式、当該方式の状態、パラメータの各情報を保持する。
【００７２】
カテゴリには、コンテナのサーバへの「再配置契機」と、再配置の対象がコンテナであることを示す「対象コンテナ」が記載される。方式（カテゴリの方式）には、ポリシの再配置契機が「ランダム契機」、「サーバ閾値契機」、「アプリ閾値契機」であることが記載される。ポリシＰ１の再配置契機の方式には、「ランダム契機」であることが記載されている。ポリシＰ２の再配置契機の方式には「サーバ閾値契機」、ポリシＰ３の再配置契機の方式には「アプリ閾値契機」であることが記載されている。
【００７３】
更に、方式（カテゴリの方式）には、ポリシの対象コンテナが「ランダム対象」、「サーバ閾値対象」、「アプリ閾値対象」であることが記載される。ポリシＰ４の対象コンテナの方式には「ランダム対象」、ポリシＰ５の対象コンテナの方式には「サーバ閾値対象」、ポリシＰ６の対象コンテナの方式には「アプリ閾値対象」であることが記載されている。
【００７４】
状態（方式の状態）には、前欄の方式が適用中か、未適用かが記載される。但し、図１３においては、３つの再配置契約において１つのみが適用中となっているが、２つ以上が適用中であってもよい。これは３つの対象コンテナにおいても同様である。
【００７５】
パラメータには、この前々欄の方式に記載の各契機のパラメータ及び各対象のパラメータが記載される。本例では、ランダム契機、サーバ閾値契機、アプリ閾値契機、ランダム対象、サーバ閾値対象、アプリ閾値対象のパラメータが記載されている。
【００７６】
方式がランダム契機であれば、パラメータとして、時刻に沿ったアプリの発生・消滅のイベント発生のｎ回につき１回等のランダムタイミング毎に再配置を行なう割合が記載される。本例では、イベント発生の１００回につき４０回のランダムタイミングで再配置を行なう割合４０％が記載されている。方式がサーバ閾値契機であれば、パラメータとして、サーバの全リソース容量に対するリソース使用率を判定するための閾値ｔｈ１（例えば５０％）が記載される。方式がアプリ閾値契機であれば、パラメータとして、アプリのサーバリソース使用量を判定するための閾値ｔｈ２（例えば６０％）が記載される。
【００７７】
方式がランダム対象であれば、パラメータとして、各サーバに配置されたコンテナの中からランダムにコンテナを選択して再配置対象とする際の、コンテナの選択数の割合（例えば５０％）が記載される。方式がサーバ閾値対象であれば、パラメータとして、サーバの全リソース容量に対するリソース使用率を判定するための閾値ｔｈ３（例えば５０％）が記載される。方式がアプリ閾値対象であれば、パラメータとして、アプリのサーバリソース使用量を判定するための閾値ｔｈ４（例えば５０％）が記載される。
【００７８】
図９に戻って、コンテナ配置計算制御部４１の再配置契機判断部４１ａは、後述のコンテナ情報収集部４２ｄからコンテナ情報更新の通知を受け取り、マイグレポリシ４５に基づき、コンテナのサーバへの再配置又は単純配置の判断を行う。この再配置又は単純配置の判断結果は、配置計算部４１ｃへ通知される。
【００７９】
対象サーバ・コンテナ決定部４１ｂは、マイグレポリシ４５に従い、再配置又は単純配置の対象とするコンテナを決定する。また、対象サーバ・コンテナ決定部４１ｂは、コンテナリスト４３のマイグレコストに従い、上記コンテナを実際にマイグレーションするか決定する。ここで決定されたコンテナは、配置計算部４１ｃへ通知される。
【００８０】
配置計算部４１ｃは、再配置契機判断部４１ａから再配置又は単純配置の判断結果の通知を受け取り、コンテナのサーバへの再配置又は単純配置の計算を行う。この計算時には、対象サーバ・コンテナ決定部４１ｂで対象と決定されたサーバ及びコンテナに対して欲張り法を適用して配置先サーバを決定する。ここで、移動（マイグレーション）が発生するコンテナについては、コンテナリスト４３（図１１）の更新フラグ（例えば「移動＝４」）を設定する。また、サーバ増減が発生する場合には、サーバリスト４４（図１２）の更新フラグ（例えば「増設＝１」又は「減設＝２」）を設定する。その後、配置計算部４１ｃは、コンテナ増減制御部４２ｃ及びサーバ起動停止部４２ａに、配置計算完了通知を通知する。
【００８１】
次に、サーバ制御部４２のコンテナ増減制御部４２ｃは、配置計算部４１ｃから最適配置計算完了通知と、サーバ起動停止部４２ａからサーバ増設通知とを受け取った場合、コンテナリスト４３（図１１）の更新フラグが「移動」に設定されたコンテナ（例えば＃１）の移動元の稼働サーバ（例えばＳＶ１１）にコンテナ消去命令を発する。また、移動先の稼働サーバ（例えばＳＶ１２）にコンテナ起動命令を発する。これによって移動元の稼働サーバＳＶ１１から該当コンテナが消去され、また、移動先の稼働サーバＳＶ１２では該当コンテナが起動する。更に、コンテナ増減制御部４２ｃは、消去及び起動命令を発した後、サーバ起動停止部４２ａに配置完了通知を通知する。
【００８２】
サーバ起動停止部４２ａは、配置計算部４１ｃから配置計算完了通知を受け取った場合、サーバリスト４４（図１２）の更新フラグが「増設」に設定された、サーバプール２２の該当サーバ（例えばＳＶ２１）にサーバ起動命令を発する。この起動命令を受けたサーバＳＶ２１は、自サーバ起動停止部５５ｂ（図１０参照）の制御によって自サーバＳＶ２１を起動する。その後、サーバ起動停止部４２ａは、コンテナ増減制御部４２ｃにサーバ増設通知を行い、同コンテナ増減制御部４２ｃから配置完了通知を受け取ると、サーバリスト４４の更新フラグが「減設」に設定された稼働サーバ（例えばＳＶ１１）にサーバ停止命令を通知する。この停止命令を受けた稼働サーバＳＶ１１は、自サーバ起動停止部５５ｂの制御によって自サーバを停止（シャットダウン）する。
【００８３】
コンテナ情報収集部４２ｄは、各稼働サーバＳＶ１１〜ＳＶ１４のサーバ情報提供部５４ｂ（図１０参照）から、当該稼働サーバＳＶ１１〜ＳＶ１４で起動中のコンテナのコンテナ情報を取得し、コンテナリスト４３を更新する。その後、コンテナ情報収集部４２ｄは、配置計算部４１ｃにコンテナ情報更新を通知する。
サーバ情報収集部４２ｂは、各稼働サーバＳＶ１１〜ＳＶ１４のサーバ情報提供部５４ｂからサーバ使用率情報を取得し、サーバリスト４４を更新する。
【００８４】
次に、図１０に示すサーバＳＶは、監視部５１と、コンテナ部５２と、個別コンテナリスト５３と、外部連携部５４と、制御部５５とを備えて構成されている。監視部５１は、物理リソース監視部５１ａと、コンテナリソース監視部５１ｂとを備える。コンテナ部５２は、複数のコンテナ＃１〜＃ｎと、コンテナエンジン５２ａとを備える。外部連携部５４は、配置情報受理部５４ａと、サーバ情報提供部５４ｂとを備える。制御部５５は、コンテナ起動消去部５５ａと、自サーバ起動停止部５５ｂとを備える。
【００８５】
個別コンテナリスト５３は、図１４に示すように、稼働サーバＳＶ１１〜ＳＶ１４（図１）が保有するものであり、各コンテナ＃１〜＃３のアプリ種別、コンテナ使用状態、コンテナ使用率、コンテナの配置先サーバ、ＣＰＵ使用率、メモリ使用率の各情報を保持する。これらの情報は、図１１に示すコンテナリスト４３に示した情報と同様であるため説明を省略する。
【００８６】
図１０に示すコンテナ＃１〜＃ｎは、１種類のアプリ用のサーバリソースを一定量確保し、アプリを動作させる。
コンテナエンジン５２ａは、コンテナ＃１〜＃ｎを物理サーバ上でホストするために、物理サーバリソースをコンテナ毎に切り分けて各コンテナ＃１〜＃ｎに供与する。
【００８７】
配置情報受理部５４ａは、管理サーバ４０（図９）のコンテナ増減制御部４２ｃからコンテナ起動命令又は消去命令を受信し、コンテナ起動消去部５５ａに対してその受信命令を発する。
コンテナ起動消去部５５ａは、配置情報受理部５４ａから指定のあったコンテナ（例えば＃１）を起動又は消去する。
自サーバ起動停止部５５ｂは、自サーバＳＶを起動又は停止する制御を行うものである。
【００８８】
物理リソース監視部５１ａは、サーバＳＶのリソース使用率を定期的に取得し、サーバ情報提供部５４ｂに通知する。
コンテナリソース監視部５１ｂは、サーバＳＶのコンテナ＃１〜＃ｎからコンテナ使用率を定期的に取得し、サーバ情報提供部５４ｂに通知する。
【００８９】
サーバ情報提供部５４ｂは、物理リソース監視部５１ａからサーバリソース使用率を定期的に受け取り、管理サーバ４０のサーバ情報収集部４２ｂ（図９）へ送信する。また、サーバ情報提供部５４ｂは、コンテナリソース監視部５１ｂから各コンテナ＃１〜＃ｎのコンテナ使用率を受け取り、管理サーバ４０のコンテナ情報収集部４２ｄに送信する。
【００９０】
＜実施形態の動作＞
次に、本実施形態のシステム１０によるサーバへのコンテナ増設及び減設時の処理動作を説明する。
＜コンテナ増設動作＞
最初に、サーバへのコンテナ増設時の処理動作を、図１５に示すフローチャートを参照して説明する。
ステップＳ１において、各稼働サーバＳＶ１１〜ＳＶ１４（図１）の個別コンテナリスト５３（図１１）のコンテナ使用率が随時更新される。これは、各稼働サーバＳＶ１１〜ＳＶ１４が、端末機１１からアプリへのリクエストを受信したタイミングで行なわれる。
【００９１】
この際、ステップＳ２において、管理サーバ４０は、コンテナリスト４３（図１１）を検出し、各稼働サーバＳＶ１１〜ＳＶ１４で立ち上がっているコンテナ＃１〜＃ｎにおいて、新規の受信リクエストに対処可能なコンテナ＃１〜＃ｎが有るか否かを次のように判定する。
【００９２】
コンテナ＃１〜＃ｎでは、受信可能なリクエスト数の上限が決まっている。例えば、受信可能なリクエスト数の上限が１００件の場合に、現在８０件のコンテナが使用中であれば、まだ２０件の余裕がある。この場合、上記ステップＳ２の判定結果は、Ｙｅｓとなってコンテナ増設時のサーバ増減動作が終了する。
【００９３】
一方、対処可能なコンテナ＃１〜＃ｎが無ければ判定結果はＮｏとなって、ステップＳ３へ進む。このステップＳ３では、管理サーバ４０が、新規の受信クエストに対処するために新規にサーバに配置されるコンテナを、コンテナリスト４３に追加する。
【００９４】
次に、ステップＳ４において、管理サーバ４０が、現在の稼働サーバＳＶ１１〜ＳＶ１４における空コンテナ及び新規コンテナを合わせた全てのコンテナに対して再配置契機の判断を行う。この判断は、前述した通り、ランダム契機、サーバ閾値契機、アプリ閾値契機等を定めたマイグレポリシ４５（図１３）に基づき行なわれる。
【００９５】
ここで、管理サーバ４０は、ステップＳ５において、上記ステップＳ４でのコンテナの再配置契機の判断において、再配置が必要と判断（Ｙｅｓ）された場合は、ステップＳ６において、管理サーバ４０がコンテナ再配置の計算を行いコンテナの移動先サーバを決定する。この再配置計算においては、欲張り法によりコンテナ毎に配置すべきサーバを決定する。一方、ステップＳ５で再配置が不要と判断（Ｎｏ）された場合は、ステップＳ７において、管理サーバ４０がコンテナ単純配置の計算を行い１つのコンテナの配置先サーバを決定する。この単純配置の計算においては、管理サーバは欲張り法により１つのコンテナを配置すべきサーバを決定する。
【００９６】
上記ステップＳ６，Ｓ７でのコンテナの配置先サーバの決定後に、ステップＳ８において、管理サーバ４０は、サーバ台数が増加したか否かを判定する。この判定結果、サーバ台数が増加していれば、管理サーバ４０が、ステップＳ９において、サーバ（例えばＳＶ１２）を増設し、サーバリスト４４（図１２）の増加サーバＳＶ１２に更新フラグ「増設」を設定する。この後、ステップＳ１０へ進む。
【００９７】
一方、上記ステップＳ８の判定結果、サーバ台数に変化無し又は減少している場合、ステップＳ１０へ進む。ステップＳ１０において、管理サーバ４０は、再配置計算によりコンテナリスト４３（図１１）の更新フラグが設定されたコンテナ（例えば＃ｎ）の、移動元の稼働サーバ（例えばＳＶ１１）にコンテナ消去命令を通知する。この通知を受けた移動元の稼働サーバＳＶ１１から該当コンテナ＃ｎが消去される。
【００９８】
更に、ステップＳ１１において、管理サーバ４０は、移動先の稼働サーバＳＶ１２にコンテナ起動命令を通知し、これを受けた移動先の稼働サーバＳＶ１２の該当コンテナ＃ｎが起動する。この後、ステップＳ１２において、管理サーバ４０は、そのコンテナ増設結果に応じてコンテナリスト４３を更新する。
【００９９】
この後、ステップＳ１３において、管理サーバ４０は、サーバ台数が減少したか否かを判定する。この判定結果、サーバ台数が減少（Ｙｅｓ）していれば、管理サーバ４０が、ステップＳ１４において、サーバ（例えばＳＶ１１）を減設し、サーバリスト４４（図１２）の減少サーバＳＶ１２に更新フラグ「減設」を設定する。この後、ステップＳ１５へ進む。
【０１００】
一方、上記ステップＳ１３の判定結果、サーバ台数に変化無し又は増加（Ｎｏ）している場合、ステップＳ１５へ進む。ステップＳ１５において、管理サーバ４０は、そのサーバ増減結果に応じてサーバリスト４４（図１２）を更新する。ステップＳ１６において、管理サーバ４０は、上記サーバ増減が更新されたサーバリスト４４に応じて制御信号Ｇ１をロードバランサ１４へ送信することにより、ロードバランサ１４のリクエスト振分先を変更する。
【０１０１】
＜コンテナ減設動作＞
次に、サーバへのコンテナ減設時の処理動作を、図１６に示すフローチャートを参照して説明する。
ステップＳ２１において、各稼働サーバＳＶ１１〜ＳＶ１４（図１）の個別コンテナリスト５３（図１１）のコンテナ使用率が随時更新される。これは、各稼働サーバＳＶ１１〜ＳＶ１４が、端末機１１からのアプリへのリクエストを受信したタイミングで行なわれる。
【０１０２】
この際、ステップＳ２２において、管理サーバ４０は、各稼働サーバＳＶ１１〜ＳＶ１４において削除可能なコンテナが有るか否かを判定する。これは、管理サーバ４０がコンテナリスト４３（図１１）の全体のコンテナ＃１〜＃ｎを検出しており、各コンテナ＃１〜＃ｎについてリクエスト受付がゼロなので削除可能であると判定（Ｙｅｓ）する。この他に、全体のリクエスト数が平均して低いようであれば、リクエストを纏めて１つのコンテナで対応するように処理し、この処理で空コンテナが存在すれば当該空コンテナを削除可能であると判定してもよい。
【０１０３】
削除可能なコンテナ＃１〜＃ｎが無ければ判定結果はＮｏとなって、コンテナ減設時のサーバ増減動作が終了する。一方、削除可能なコンテナ＃１〜＃ｎが有れば判定結果はＹｅｓとなって、ステップＳ２３へ進む。このステップＳ２３では、当該サーバ（例えばＳＶ１１）からコンテナ＃１が消去され、この後、管理サーバ４０により、削除コンテナ＃１がコンテナリスト４３から削除される。
【０１０４】
次に、ステップＳ２４において、管理サーバ４０が、現在の稼働サーバＳＶ１１〜ＳＶ１４における空コンテナ及び新規コンテナを合わせた全てのコンテナに対して、マイグレポリシ４５（図１３）に基づき、再配置契機の判断を行う。
【０１０５】
ここで、管理サーバ４０は、ステップＳ２５において、再配置が不要と判断（Ｎｏ）された場合は、ステップＳ３０へ進む。一方、再配置が必要と判断（Ｙｅｓ）された場合は、ステップＳ２６において、管理サーバ４０がコンテナ再配置の計算を行いコンテナの移動先サーバを決定する。この再配置計算において、欲張り法によりコンテナ毎に配置すべきサーバを決定する。
【０１０６】
次に、ステップＳ２７において、管理サーバ４０は、再配置計算によりコンテナリスト４３（図１１）の更新フラグが設定されたコンテナ（例えば＃ｎ）の、移動元の稼働サーバ（例えばＳＶ１１）にコンテナ消去命令を通知する。この通知を受けた移動元の稼働サーバＳＶ１１から該当コンテナ＃ｎが消去される。
【０１０７】
更に、ステップＳ２８において、管理サーバ４０は、移動先の稼働サーバＳＶ１２にコンテナ起動命令を通知し、これを受けた移動先の稼働サーバＳＶ１２の該当コンテナ＃ｎが起動する。この後、ステップＳ２９において、管理サーバ４０は、上記のコンテナ消去結果に応じてコンテナリスト４３を更新する。
【０１０８】
この後、ステップＳ３０において、管理サーバ４０は、サーバ台数が減少したか否かを判定する。この判定結果、サーバ台数が減少していれば（Ｙｅｓ）、管理サーバ４０が、ステップＳ３１において、サーバ（例えばＳＶ１１）を減設し、サーバリスト４４（図１２）の減少サーバＳＶ１２に更新フラグ「減設」を設定する。この後、ステップＳ３２へ進む。
【０１０９】
一方、上記ステップＳ３０の判定結果、サーバ台数に変化無し又は増加している場合（Ｎｏ）、ステップＳ３２へ進む。ステップＳ３２において、管理サーバ４０は、そのサーバ増減結果に応じてサーバリスト４４（図１２）を更新する。ステップＳ３３において、管理サーバ４０は、上記サーバ減が更新されたサーバリスト４４に応じてロードバランサ１４のリクエスト振分先を変更する。
【０１１０】
＜コンテナ再配置計算の処理＞
次に、図１７を参照してコンテナ再配置計算（コンテナ最適配置計算）の処理動作について説明する。このコンテナ再配置計算は、上述した図１５のステップＳ６及び図１６のステップＳ２６の再配置計算であり、管理サーバ４０が行う。
【０１１１】
まず、ステップＳ４１において、コンテナ再配置計算に当たって、コンテナの移動元の対象サーバを決定する。同時に、ステップＳ４２において、対象サーバから移動される対象コンテナを決定する。
【０１１２】
次に、ステップＳ４３において、ｎ台のコンテナを優先度等の所定のパラメータに応じて並び替える。優先度は、例えばＣＰＵ及びメモリの合計の使用率が多い順である。次に、その並び替えたコンテナ＃１〜＃ｎを、１番目から最終のｎ番目までコンテナ毎に、最大適合率（後述）の１台のサーバを選択する。これは、次のステップＳ４４〜Ｓ５２の間で行なわれる。
【０１１３】
ここで、最大適合率について説明する。サーバへのコンテナの最適配置は、コンテナへのリクエストの変動に応じ、欲張り法を適用してクラスタ内の稼働サーバ数を最小限に抑えることが可能な配置である。つまり、最適配置とは、サーバにおけるリソース（ＣＰＵ＋メモリ）残容量が極力少なく又は無くなるように、サーバにコンテナを配置することである。コンテナ毎に、当該コンテナを最適配置可能なサーバを決定する評価は、コンテナのリソース使用量ベクトルと、サーバのリソース残容量（空き容量）ベクトルとの双方を単位ベクトル化し、双方の単位ベクトルの内積を取ってコンテナのサーバへの最大適合率を求めることである。言い換えれば、その内積が最大となるサーバへのコンテナの配置が、コンテナのサーバへの最大適合率となる。但し、このコンテナのサーバへの最大適合率を求める評価は、これに限定されず他の評価方法であってもよい。
【０１１４】
次に、ステップＳ４４において、１番目のコンテナ＃１を用い、次に、ステップＳ４５において、そのコンテナ＃１に最も適合するサーバを、１番目から最終のｍ番目まで１つずつ組合せる。最初は、ステップＳ４５において、コンテナ＃１にサーバ（例えば＊１）を組合せる。
【０１１５】
次に、ステップＳ４６において、上記ステップＳ４５での組合せられたサーバ＊１にコンテナ＃１を配置した際に、コンテナ＃１がサーバ＊１に配置可能か否かを判定する。この結果、配置不可能（Ｎｏ）であれば、ステップＳ５０において、次の２番目のサーバ＊２を組合せることを指示し、ステップＳ４５に戻って２番目のサーバ＊２を選択し、ステップＳ４６において、コンテナ＃１がサーバ＊２に配置可能か否かを判定する。
【０１１６】
この判定結果、配置可能（Ｙｅｓ）であれば、ステップＳ４７において、適合率の計算を行う。この計算では、サーバ＊２のリソース残容量ベクトルと、コンテナ＃１のリソース使用量ベクトルとの双方を単位ベクトル化し、この双方の単位ベクトルの内積を計算して適合率を求める。
【０１１７】
ステップＳ４８において、上記ステップＳ４７で求めた適合率が、最大適合率か否かを判定する。最初は、最大適合率（Ｙｅｓ）と判定され、ステップＳ４９において、予め設定された最大適合率の初期値（例えば「０」）が、その求められた最大適合率に更新される。この更新後、ステップＳ５０において、次の３番目のサーバ＊３を組合せることを指示し、ステップＳ４５に戻って３番目のサーバ＊３を選択し、ステップＳ４６において、コンテナ＃１がサーバ＊３に配置可能か否かを判定する。
【０１１８】
この判定結果、配置可能（Ｙｅｓ）であれば、ステップＳ４７において、上記同様に適合率の計算を行って適合率を求める。ステップＳ４８において、その求めた適合率が、最大適合率と判定（Ｙｅｓ）されれば、ステップＳ４９において、最大適合率が更新され、ステップＳ５０へ進む。
【０１１９】
一方、ステップＳ４８の結果、最大で無いと判定（Ｎｏ）された場合、ステップＳ５０へ進む。ステップＳ５０において、次の４番目のサーバ＊４を組合せることを指示し、ステップＳ４５に戻って４番目のサーバ＊４を選択し、ステップＳ４６において、コンテナ＃１がサーバ＊４に配置可能か否かを判定する。
【０１２０】
このようにステップＳ４５〜Ｓ５０の処理を、最後のサーバ＊ｍまで１つずつ順番に繰り返した後、ステップＳ５１において、コンテナ＃１を最大適合率のサーバ＊ｋに配置する。
【０１２１】
この具体例を説明する。まず、コンテナ＃１に対して、サーバ＊２は適合率が「２」、サーバ＊３は「３」、サーバ＊４は「１」、サーバ＊５は「４」であるとする。この場合、最初の適合率計算では、サーバ＊２は「２」と計算され、次のサーバ＊３では「３」と計算されるので、最大適合率は「３」に更新される。次の計算でサーバ＊４では「１」と計算され、この場合、最大適合率は更新されずにそのまま「３」となる。次にサーバ＊５で「４」と計算されると、最大適合率は「４」に更新される。このようにコンテナ＃１に対して全てのサーバ＊１〜＊ｍの中から最大適合率のサーバ＊ｋを選択し、このサーバ＊ｋにコンテナ＃１を配置する。
【０１２２】
このような配置後、ステップＳ５２において、次の２番目のコンテナ＃２を組合せることを指示し、ステップＳ４４に戻って２番目のコンテナ＃２を選択する。次に、ステップＳ４５において、そのコンテナ＃２に最初のサーバ＊１を組合せ、ステップＳ４６において、コンテナ＃２がサーバ＊１に配置可能か否かを判定する。以降、上述のステップＳ４７〜Ｓ４９の処理を行った後、ステップＳ５０において次のサーバ＊２を指示する。このステップＳ４５〜Ｓ５０の処理を最後のサーバ＊ｍまで繰り返した後、ステップＳ５１において、コンテナ＃２を、最大適合率のサーバ＊ｈに配置する。この配置後、ステップＳ５２において、次の３番目のコンテナ＃３を組合せることを指示する。
【０１２３】
このようにコンテナ＃１〜＃ｎ毎に、１つずつサーバ＊１〜＊ｍを組合せて最大適合率のサーバ＊ｈを検出し、この検出した最大適合率のサーバ＊ｈに該当コンテナを配置する処理を、最後のコンテナ＃ｎ及びサーバ＊ｍまで行う。これによって、個々のコンテナ＃１〜＃ｎが、最大適合率のサーバ＊ｈに配置される。
【０１２４】
＜コンテナ単純配置計算の処理＞
次に、図１８を参照してコンテナ単純配置計算の処理動作について説明する。このコンテナ再配置計算は、上述した図１５のステップＳ７の単純配置計算であり、管理サーバ４０が行う。つまり、図１５のステップＳ５において、コンテナの再配置契機の判断で再配置が不要と判断された際に、ステップＳ７において、コンテナ単純配置の計算により１つのコンテナ（例えば＃１）の配置先サーバが決定される。
【０１２５】
図１８のステップＳ６１において、１つのコンテナ＃１に最も適合するサーバを、１番目から最終のｍ番目まで１つずつ組合せる。最初は、ステップＳ６１において、コンテナ＃１にサーバ（例えば＊１）を組合せる。以降、ステップＳ６１〜Ｓ６７までの処理は、図１７のステップＳ４５〜Ｓ５１までの処理と同じである。即ち、ステップＳ６１〜Ｓ６２の処理を、最後のサーバ＊ｍまで１つずつ順番に繰り返した後、ステップＳ６７において、１つのコンテナ＃１に対して全てのサーバ＊１〜＊ｍの中から最大適合率のサーバ＊ｋが選択され、このサーバ＊ｋに１つのコンテナ＃１が配置される。
【０１２６】
＜コンテナ増設動作シーケンス＞
次に、サーバへのコンテナ増設時の詳細な動作シーケンスを、図１９〜図２１に示すシーケンス図を参照して説明する。但し、図１９と図２１に示すサーバＡはコンテナ利用状況が随時更新されるサーバである。サーバＢは増設又は減設のサーバ、又はマイグレーション対象の仮想インスタンスが入るサーバであるとする。なお、サーバＡ，Ｂは共に１つしか記載していないが実際には複数存在するものとする。また、サーバ制御部４２及びコンテナ配置計算制御部４１は、管理サーバ４０（図９）に配置されている。
【０１２７】
図１９において、サーバＡの個別コンテナリスト５３（図１４）のコンテナ使用率が随時更新され、この更新内容をサーバＡの監視部５１が検出している。この検出により、監視部５１は、ステップＳ７１，Ｓ７２で示すように、個別コンテナリスト５３の更新内容を、サーバＡの外部連携部５４を経由して、管理サーバ４０（図９）のサーバ制御部４２へ通知（個別コンテナリスト更新通知）する。
【０１２８】
サーバ制御部４２は、個別コンテナリスト更新通知の内容に応じて、ステップＳ７３に示すように、コンテナの再配置命令をコンテナ配置計算制御部４１へ通知する。コンテナ配置計算制御部４１は、その再配置命令に従ってコンテナ再配置の計算を実行し、配置先サーバＢを求める。この計算は、管理サーバ４０のコンテナ配置計算制御部４１とサーバ制御部４２との連携により行なわれ、前述した図１５に示したステップＳ４〜Ｓ７の処理により実行される。これにより、コンテナの移動先サーバＢが計算結果として求められる。
【０１２９】
このコンテナ再配置計算のより詳細な計算処理を、図２０に示すシーケンス図を参照して説明する。
図２０において、個別コンテナリスト５３のコンテナ使用率の更新ありのサーバＡが、ステップＳ７３ａで示すように個別コンテナリスト更新通知を、管理サーバ４０のコンテナ情報収集部４２ｄに対して行なう。コンテナ情報収集部４２ｂは、ステップＳ７３ｂで示すように、コンテナリスト４３にコンテナリスト更新命令を行う。ここで、コンテナリスト４３は、全体のコンテナリストを更新するが、そのコンテナのアプリが既存のコンテナでは対応できないといったケースが生じたとする。コンテナリスト４３は、ステップＳ７３ｃで示すように、そのケースの内容をコンテナ対処不可通知としてコンテナ情報収集部４２ｄへ通知する。
【０１３０】
そのコンテナ対処不可通知を受けたコンテナ情報収集部４２ｄは、ステップＳ７３ｄで示すように、コンテナリストの新規追加命令をコンテナリスト４３へ通知する。コンテナリスト４３は、その新規追加命令に応じた新規追加後、ステップＳ７３ｅで示すように、新規追加による更新の通知をコンテナ情報収集部４２ｄに行なう。新規追加の更新通知を受けたコンテナ情報収集部４２ｄは、ステップＳ７３ｆで示すように、再配置契機判断部４１ａに再配置命令を通知する。再配置契機判断部４１ａは、ステップＳ７３ｇ，７３ｈで示すように、コンテナリスト４３を参照して全コンテナのコンテナ情報を得た後、ステップＳ７３ｉ，７３ｊで示すように、サーバリスト４４を参照して全サーバのサーバ情報を得る。
【０１３１】
次に、再配置契機判断部４１ａは、ステップＳ７３ｋ，Ｓ７３ｌで示すように、マイグレポリシ４５を参照してポリシ情報を得ることで、前述した再配置契機の判断を行う。この判断において、再配置契機判断部４１ａは、再配置が必要なタイミングであれば、ステップＳ７３ｍで示すように、対象サーバ・コンテナ決定部４１ｂに、再配置計算の命令を行うと共に、計算に必要なコンテナ・サーバ情報を通知する。
【０１３２】
対象サーバ・コンテナ決定部４１ｂは、ステップＳ７３ｎ，Ｓ７３ｏで示すように、マイグレポリシ４５を参照してポリシ情報を得た後、ポリシに応じて対象を絞ったコンテナやサーバを決定する。この対象サーバ・コンテナ決定部４１ｂは、その決定した対象コンテナ・サーバ情報と、再配置計算命令とを、ステップＳ７３ｐで示すようにコンテナ配置計算制御部４１（図９）の配置計算部４１ｃへ通知する。
【０１３３】
配置計算部４１ｃが、その対象コンテナ・サーバ情報を用いて再配置計算を行い配置先サーバを求める。この計算結果が、ステップＳ７３ｑ，７３ｒ，７３ｓで示すように、対象サーバ・コンテナ決定部４１ｂ、再配置契機判断部４１ａ、サーバ制御部４２のコンテナ情報収集部４２ｄの順に通知される。
【０１３４】
この計算結果の通知は、図１９にステップＳ７４に示すように、コンテナ配置計算制御部４１からサーバ制御部４２に対して行なわれる。ここで、サーバ制御部４２は、その計算結果の配置先サーバＢ（図１のサーバプール２２に配置されているサーバＳＶ２１〜ＳＶ２４に該当）を増設するための、サーバ増設命令を、ステップＳ７５，Ｓ７６に示すように、サーバ外部連携部５４を介してサーバＢの制御部５５へ通知する。
【０１３５】
サーバＢの制御部５５は、図１５のステップＳ９で説明したように、サーバＢを増設し、サーバリスト４４の増加サーバＢに更新フラグ「増設」を設定する。次に、図１９に戻り、サーバ制御部４２は、そのサーバ増設を行った通知（サーバ増設通知）を、ステップＳ７７で示すようにサーバＢの外部連携部５４へ通知する。外部連携部５４は、サーバＢを増設したことと同時に、増設した物理サーバＢの情報をアップデートする必要がある。このため、増設サーバＢのリソース情報を、ステップＳ７８で示すようにサーバＢの監視部５１に要求（リソース情報要求）して、ステップＳ７９で示すようにリソース情報を取得する。
【０１３６】
この取得後、サーバＢの外部連携部５４は、ステップＳ８０で示すように、管理サーバ４０のサーバ制御部４２へ、サーバ増設したことを通知（サーバ増設通知）すると共に、ステップＳ８１で示すように、増設サーバＢのリソース情報を通知する。
【０１３７】
次に、サーバ制御部４２は、ステップＳ８２，Ｓ８３，Ｓ８４で示すように、サーバＢの外部連携部５４及びサーバＢの制御部５５を介して移動元の稼働サーバＢのコンテナ群のコンテナ（例えば＃ｎ）に対してコンテナ消去命令を通知する。これは、図１５のステップＳ１０で説明したように、サーバ制御部４２が、上述した再配置計算によりコンテナリスト４３の更新フラグが設定されたコンテナ（例えば＃ｎ）の、移動元の稼働サーバにコンテナ消去命令を通知することである。この通知を受けた移動元の稼働サーバから該当コンテナ＃ｎが消去される。
【０１３８】
この消去が行なわれたサーバから、ステップＳ８５，Ｓ８６で示すように、コンテナ消去通知がサーバＢの制御部５５を介して外部連携部５４へ通知される。外部連携部５４は、ステップＳ８７で示すように、サーバＢの監視部５１にコンテナのリソース情報を要求する。この要求に応じてステップＳ８８で示すように、監視部５１から外部連携部５４へコンテナのリソース情報が通知される。サーバＢの外部連携部５４は、管理サーバ４０（図９）のサーバ制御部４２に対して、ステップＳ８９に示すように、そのリソース情報に応じたコンテナ消去の通知を行なうと共に、ステップＳ９０で示すようにリソース情報を通知する。つまり、サーバ制御部４２は、最終的に、コンテナのリソース情報を受け取ることになる。
【０１３９】
そのステップＳ９０でコンテナのリソース情報を受け取ったサーバ制御部４２は、図１５に示したステップＳ１１の移動先コンテナの起動を行う。
即ち、図２１に示すように、サーバ制御部４２は、ステップＳ９１，Ｓ９２，Ｓ９３で示すように、移動先の稼働サーバＢの外部連携部５４及び制御部５５を介してサーバＢのコンテナ群のコンテナ＃ｎにコンテナ起動命令を通知する。これを受けた移動先の稼働サーバＢの該当コンテナ＃ｎが起動する。この起動後、ステップＳ９４，Ｓ９５で示すように、コンテナ＃ｎのコンテナ起動通知がサーバＢの制御部を介してサーバＢの外部連携部５４へ通知される。
【０１４０】
外部連携部５４は、コンテナを起動したサーバＢのリソース情報を、ステップＳ９６で示すようにサーバＢの監視部５１に要求（リソース情報要求）し、この要求に応じたリソース情報をステップＳ９７で示すように監視部５１から取得する。
【０１４１】
この取得後、サーバＢの外部連携部５４は、ステップＳ９８で示すように、管理サーバ４０（図９）のサーバ制御部４２へ、コンテナ起動したことを通知（コンテナ起動通知）すると共に、ステップＳ９９で示すように、コンテナを起動したサーバＢのリソース情報を通知する。ここで、サーバ制御部４２は、図１５のステップＳ１３，Ｓ１４のように、サーバ台数が減少したか否かを判定し、サーバ台数が減少していれば、サーバを減設し、この減少サーバのサーバリスト４４に更新フラグ「減設」を設定する。
【０１４２】
この減設処理は、図２１のステップＳ１００，Ｓ１０１で示すように、サーバ制御部４２がサーバ減設命令を、サーバＢの外部連携部５４を介して制御部５５へ通知することで行なわれる。この通知を受けた制御部５５が対象のサーバを減設する。この減設通知は、ステップＳ１０２で示すように、サーバＢの外部連携部５４へ通知される。外部連携部５４は、ステップＳ１０３で示すように、サーバＢの監視部５１にサーバのリソース情報を要求する。この要求に応じてステップＳ１０４で示すように、監視部５１から外部連携部５４へサーバのリソース情報が通知される。外部連携部５４は、管理サーバ４０のサーバ制御部４２に対して、ステップＳ１０５に示すように、そのリソース情報に応じたサーバ減設通知を行なうと共に、ステップＳ１０６で示すようにリソース情報を通知する。つまり、サーバ制御部４２は、最終的に、サーバのリソース情報を受け取ることになる。
【０１４３】
＜実施形態の効果＞
以上説明したように、本実施形態のクラスタ内マイグレーション管理システム１０は、アプリをホストする仮想インスタンスとしてのコンテナへのリクエストの変動に応じ、複数のサーバＳＶが設置されたクラスタ内でコンテナをサーバＳＶに再配置するようになっている。このシステム１０の特徴による効果を説明する。
（１）上記の再配置を行う契機と再配置の対象となるコンテナと、を少数に限定する内容を定めたマイグレポリシ４５に基づき、再配置を行う契機を判断し、この判断で再配置を行う際に当該再配置の対象となるコンテナを決定する配置制御手段としてのコンテナ配置計算制御部４１を備える。
【０１４４】
この構成によれば、コンテナを複数のサーバＳＶに再配置する際に、マイグレポリシ４５に基づき、コンテナをサーバＳＶに再配置する契機を少数に限定して行なうことが判断され、この判断で再配置を行う際に、再配置の対象となるコンテナが少数に限定される。このため、マイグレーション数が少なくなり、効率的にサーバＳＶのリソース使用効率を高くすることができる。
【０１４５】
（２）コンテナがマイグレーションに伴い及ぼす影響が大きい程に、コンテナのマイグレーションを発生しにくくさせるため、予め定められた所定パーセンテージの確率で示すコストを記憶手段に備え、コンテナ配置計算制御部４１は、コストの確率に基づき、当該コンテナを再配置の対象から外す制御を行うようにした。
【０１４６】
この構成によれば、マイグレーションに伴い及ぼす影響が大きい仮想インスタンスが再配置の対象から外されるので、サービス品質を向上することができる。
【０１４７】
（３）コンテナ配置計算制御部４１は、再配置を行う契機を判断し、当該再配置が不要と判断された際に、新規に追加された１つのコンテナのみをサーバＳＶに配置する制御を行うようにした。
【０１４８】
この構成によれば、再配置が不要と判断された際に、新規に追加された１つの仮想インスタンスのみをサーバに配置するので、１つの仮想インスタンスが１つのサーバに配置されることになる。このため、既存の仮想インスタンスがサーバから他のサーバへ移動するといったマイグレーションが生じなくなる。このような配置方法を織り交ぜることで、全体のマイグレーション数を抑えることができる。
【０１４９】
次に、クラスタ内マイグレーション管理方法について説明する。この方法では、アプリをホストする仮想インスタンスとしてのコンテナへのリクエストの変動に応じ、複数のサーバＳＶが設置されたクラスタ内でコンテナをサーバＳＶに再配置する管理サーバ４０が行なうようになっている。
【０１５０】
管理サーバ４０は、上記の再配置を行う契機と再配置の対象となるコンテナと、を少数に限定する内容を定めたマイグレポリシ４５に基づき、再配置を行う契機を判断し、この判断で再配置を行う際に当該再配置の対象となるコンテナを決定するステップを実行するようにした。
【０１５１】
この方法によれば、上述したシステム１０の効果と同様に、マイグレーション数が少なくなり、効率的にサーバＳＶのリソース使用効率を高くすることができる。
【０１５２】
次に、本実施形態のコンピュータを実行するプログラムについて説明する。コンピュータは、アプリをホストする仮想インスタンスとしてのコンテナへのリクエストの変動に応じ、複数のサーバＳＶが設置されたクラスタ内でコンテナをサーバＳＶに再配置する管理サーバ４０であるとする。
このプログラムは、上記のコンピュータを、上記の再配置を行う契機と再配置の対象となるコンテナと、を少数に限定する内容を定めたマイグレポリシ４５として定める手段、マイグレポリシ４５に基づき、再配置を行う契機を判断し、この判断で再配置を行う際に当該再配置の対象となるコンテナを決定する手段として機能させる。
【０１５３】
このプログラムによれば、上述したシステム１０の効果と同様に、マイグレーション数が少なくなり、効率的にサーバＳＶのリソース使用効率を高くすることができる。
【０１５４】
その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【０１５５】
１０  クラスタ内マイグレーション管理システム
１１  クライアント端末機
１２  インターネット
１３，２３  ローカルネット
１４  ロードバランサ
２０  クラスタ
２１  稼働サーバ群
２２  サーバプール
４０  管理サーバ
４１  コンテナ配置計算制御部（配置制御手段）
４１ａ  再配置契機判断部
４１ｂ  対象サーバ・コンテナ決定部
４１ｃ  配置計算部
４２  サーバ制御部
４２ａ  サーバ起動停止部
４２ｂ  サーバ情報収集部
４２ｃ  コンテナ増減制御部
４２ｄ  コンテナ情報収集部
４３  コンテナリスト
４４  サーバリスト
４５  マイグレーションポリシ
５１  監視部
５１ａ  物理リソース監視部
５１ｂ  コンテナリソース監視部
５２  コンテナ部
５２ａ  コンテナエンジン
５３  個別コンテナリスト
５４  外部連携部
５４ａ  配置情報受理部
５４ｂ  サーバ情報提供部
５５  制御部
５５ａ  コンテナ起動消去部
５５ｂ  自サーバ起動停止部
ＳＶ１１〜ＳＶ１４  稼働サーバ
ＳＶ２１〜ＳＶ２４  停止サーバ
＃１〜＃ｎ  コンテナ
【図１】
2017146791.tif 000003
【図２】
2017146791.tif 000004
【図３】
2017146791.tif 000005
【図４】
2017146791.tif 000006
【図５】
2017146791.tif 000007
【図６】
2017146791.tif 000008
【図７】
2017146791.tif 000009
【図８】
2017146791.tif 000010
【図９】
2017146791.tif 000011
【図１０】
2017146791.tif 000012
【図１１】
2017146791.tif 000013
【図１２】
2017146791.tif 000014
【図１３】
2017146791.tif 000015
【図１４】
2017146791.tif 000016
【図１５】
2017146791.tif 000017
【図１６】
2017146791.tif 000018
【図１７】
2017146791.tif 000019
【図１８】
2017146791.tif 000020
【図１９】
2017146791.tif 000021
【図２０】
2017146791.tif 000022
【図２１】
2017146791.tif 000023
【図２２】
2017146791.tif 000024
【図２３】
2017146791.tif 000025
【図２４】
2017146791.tif 000026
【図２５】
2017146791.tif 000027