特許 7469655 コンテナ配置先決定プログラム、及びコンテナ配置先決定方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-04-09

(45)【発行日】2024-04-17

(54)【発明の名称】コンテナ配置先決定プログラム、及びコンテナ配置先決定方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240410BHJP

   G06F 9/455 20180101ALI20240410BHJP

【ＦＩ】

G06F9/50 120A

G06F9/455 150

【請求項の数】 5

(21)【出願番号】P 2020120485

(22)【出願日】2020-07-14

(65)【公開番号】P2022017754

(43)【公開日】2022-01-26

【審査請求日】2023-04-07

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100087480

【弁理士】

【氏名又は名称】片山 修平

(72)【発明者】

【氏名】新井 宏明

(72)【発明者】

【氏名】佐藤 昌浩

(72)【発明者】

【氏名】山崎 公敬

(72)【発明者】

【氏名】和田 裕二

【審査官】三坂 敏夫

(56)【参考文献】

【文献】特開２０１９－１３５５９７（ＪＰ，Ａ）

【文献】特開２０１２－２２１０４９（ＪＰ，Ａ）

【文献】特開２０２０－３８４７７（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／４５５－９／５４

(57)【特許請求の範囲】

【請求項1】

コンピュータに、
第１の仮想マシンに配置されている第１のコンテナのリソース使用率が閾値を超えたときに、前記第１のコンテナで動作している第１のプログラムに対して処理を依頼している第２のプログラムを特定し、
前記第２のプログラムが動作している第２のコンテナが配置されている第２の仮想マシンを特定し、
前記第２の仮想マシンを前記第１のコンテナのスケールアウト先として決定する、
処理を実行させるためのコンテナ配置先決定プログラム。

【請求項2】

前記コンピュータに、
前記第２の仮想マシンに前記第１のコンテナをスケールアウトし、
前記第２のプログラムが処理を依頼する依頼先を、スケールアウトにより前記第２の仮想マシンに配置された前記第１のコンテナで動作する前記第１のプログラムに変更する、
処理を実行させるための請求項１に記載のコンテナ配置先決定プログラム。

【請求項3】

前記第１の仮想マシンと前記第２の仮想マシンは、それぞれ異なるクラウド拠点に配置されていることを特徴とする請求項１に記載のコンテナ配置先決定プログラム。

【請求項4】

前記コンピュータに、
前記第１のプログラムと前記第２のプログラムとを対応付けた情報を記憶した記憶部を参照することにより、前記第１のプログラムに対して処理を依頼している前記第２のプログラムを特定する、
処理を実行させるための請求項１に記載のコンテナ配置先決定プログラム。

【請求項5】

コンピュータが、
第１の仮想マシンに配置されている第１のコンテナのリソース使用率が閾値を超えたときに、前記第１のコンテナで動作している第１のプログラムに対して処理を依頼している第２のプログラムを特定し、
前記第２のプログラムが動作している第２のコンテナが配置されている第２の仮想マシンを特定し、
前記第２の仮想マシンを前記第１のコンテナのスケールアウト先として決定する、
処理を実行することを特徴とするコンテナ配置先決定方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コンテナ配置先決定プログラム、及びコンテナ配置先決定方法に関する。

【背景技術】

【0002】

仮想化技術の発展に伴い、データセンタ内で起動している仮想マシンを利用して種々のサービスを利用者に提供するクラウドが普及しつつある。特に、近年では異なるクラウド事業者のクラウド同士を組み合わせたマルチクラウドと呼ばれる新たなサービスが普及しつつある。マルチクラウドにおいては、いずれかのクラウド事業者に障害が発生しても、残りクラウド事業者のクラウドで仮想マシンを稼働し続けることができるため、サービスの可用性を高めることができる。

【0003】

マルチクラウドを実現するためのアプリケーションプログラムは、仮想マシンが直接実行するのではなく、仮想マシンに起動したコンテナが実行することがある。なお、以下ではアプリケーションプログラムのことを単にアプリとも呼ぶ。

【0004】

コンテナは、ゲストOSのカーネルの一部のみを利用した仮想的なユーザ空間であって、DOCKER（登録商標）等のコンテナエンジンによって生成される。アプリが実行時に参照するライブラリをコンテナに予め格納しておくことで、アプリをコンテナごと他の仮想マシンに移動したときに、移動前と同じ環境でアプリを実行することができる。

【0005】

但し、コンテナを利用したマルチクラウドには、アプリ等のプログラム間の通信の遅延を抑制するという点で改善の余地がある。

【先行技術文献】

【特許文献】

【0006】

【文献】特開２０１７－２１９９７２号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

一側面によれば、プログラム間の通信の遅延を抑制することを目的とする。

【課題を解決するための手段】

【0008】

一側面によれば、コンピュータに、第１の仮想マシンに配置されている第１のコンテナのリソース使用率が閾値を超えたときに、前記第１のコンテナで動作している第１のプログラムに対して処理を依頼している第２のプログラムを特定し、前記第２のプログラムが動作している第２のコンテナが配置されている第２の仮想マシンを特定し、第２の仮想マシンを第１のコンテナのスケールアウト先として決定する、処理を実行させるためのコンテナ配置先決定プログラムが提供される。

【発明の効果】

【0009】

一側面によれば、プログラム間の通信の遅延を抑制することができる。

【図面の簡単な説明】

【0010】

【図1】図１は、本願発明者が検討したマルチクラウドのシステム構成図である。

【図2】図２は、処理の依頼元と依頼先の各アプリの模式図である。

【図3】図３は、スケールアウトの一例を示す模式図である。

【図4】図４は、スケールアウトをしたときの各アプリへの処理の振り分けを示す模式図である。

【図5】図５は、遅延時間の定義を示す模式図である。

【図6】図６は、本実施形態に係る情報処理システムの構成図である。

【図7】図７は、本実施形態に係る物理サーバの模式図である。

【図8】図８は、本実施形態において各クラウド拠点で動作している仮想マシン、コンテナ、及びアプリの各々を示す模式図である。

【図9】図９は、本実施形態において仮想マシン、コンテナ、及びアプリの各々によって構築されるシステムの模式図である。

【図10】図１０は、本実施形態に係るコンテナ配置先決定方法について示す模式図（その１）である。

【図11】図１１は、本実施形態に係るコンテナ配置先決定方法について示す模式図（その２）である。

【図12】図１２は、本実施形態に係るコンテナ配置先決定方法について示す模式図（その３）である。

【図13】図１３は、本実施形態における各コンテナのリソース使用率の監視結果を示す図である。

【図14】図１４は、本実施形態に係る設計情報の模式図である。

【図15】図１５は、本実施形態に係る管理情報の模式図である。

【図16】図１６は、本実施形態においてスケールアウトを行った後におけるシステム３０の模式図である。

【図17】図１７は、本実施形態に係る情報処理装置の機能構成図である。

【図18】図１８は、本実施形態に係るコンテナ配置先決定方法のフローチャートである。

【図19】図１９は、本実施形態に係る情報処理装置のハードウェア構成図である。

【発明を実施するための形態】

【0011】

本実施形態の説明に先立ち、本願発明者が検討した事項について説明する。
図１は、本願発明者が検討したマルチクラウドのシステム構成図である。

【0012】

このシステム１は、利用者に対してサービスを提供するためのシステムであって、クラウドを提供する事業者やリージョンが異なる複数の仮想マシンVMを組み合わせて構築される。

【0013】

リージョンは、仮想マシンVMを実行する物理マシンを収容したデータセンタが存在する地域である。例えば、「日本」や「米国」がリージョンとなる。また、事業者は、そのデータセンタを利用して仮想マシンVMを提供する事業者である。図１の例では、事業者Aと事業者Bの各々が提供する仮想マシンVMによってシステム１が構築される。以下では、事業者とリージョンの組のことをクラウド拠点と呼ぶ。例えば、（事業者A、日本）、（事業者A、米国）、（事業者B、日本）、及び（事業者B、米国）は、相異なるクラウド拠点の一例である。

【0014】

なお、システム１の利用者がオンプレミスでデータセンタを運用している場合には、利用者が自己所有するデータセンタで仮想マシンVMを稼働し、その仮想マシンVMをシステム１に取り入れてもよい。

【0015】

また、この例では、一つの仮想マシンVMの各々に複数のコンテナ４を配置する。そして、各々のコンテナ４にアプリ５を一つずつ配置する。これにより、コンテナ４をアプリ５ごと他の仮想マシンVMに移動することで、アプリ単位での仮想マシンVMの移動が可能となる。

【0016】

このようなシステム１においては複数のアプリ５の各々が互いに処理を依頼し合うことにより一つのサービスが実現される。

【0017】

図２は、処理の依頼元と依頼先の各アプリ５の模式図である。
図２の例では、「appA」、「appB」、「appO」、「appP」、「appW」、及び「appX」の各アプリ５が、「appV」のアプリ５に処理を依頼する場合を想定している。このように「appV」のアプリ５に処理が集中すると、「appV」のアプリ５のコンテナ４に割り当てられたメモリやCPU(Central Processing Unit)等のリソースが不足し、該アプリ５の処理速度が低下するおそれがある。

【0018】

これを避けるために、「appV」のアプリ５が動作しているクラウド拠点（事業者A、米国）に新たに仮想マシンVMを作成し、その仮想マシンVMに「appV」のアプリ５が動作しているコンテナ４をスケールアウトすることが考えられる。スケールアウトは、ある仮想マシンVMで動作しているコンテナ４を、そのコンテナ４で動作しているアプリ５ごと他の仮想マシンVMにコピーする操作である。これにより、クラウド拠点（事業者A、米国）の二つの仮想マシンVMで「appV」のアプリ５が動作するため、該アプリ５に処理が集中するのを抑制できる。

【0019】

但し、このように新たな仮想マシンVMを作成すると、システム１に含まれる仮想マシンVMの個数が増えてしまうため、システム１の利用料金が増えてしまう。

【0020】

そこで、利用料金が増えるのを防止しつつ、「appV」のアプリ５に処理が集中するのを抑制するために、次のようにシステム１に既に存在する仮想マシンVMをスケールアウト先とすることが考えられる。

【0021】

図３は、この場合のスケールアウトの一例を示す模式図である。
図３の例では、クラウド拠点（事業者A、米国）において「appV」のアプリ５が動作しているコンテナ４を、クラウド拠点（事業者B、米国）の既存の仮想マシンVMにスケールアウトする。ここでは、スケールアウト前のアプリ５の名前「appV」にプライムを付けた名前「appV’」をスケールアウト先でのアプリ５の名前とする。

【0022】

図４は、このようにスケールアウトをしたときの各アプリ５への処理の振り分けを示す模式図である。

【0023】

図４の例では、適当な仮想マシンVMにおいてロードバランサ６を起動し、そのロードバランサ６を用いて「appV」と「appV’」の各アプリ５に処理を均等に振り分ける。これにより、「appV」のアプリ５のコンテナ４に割り当てられたメモリやCPU等のリソースが不足するのを抑制できる。しかも、スケールアウト先の仮想マシンVMはシステム１に元々存在しているため、当該仮想マシンVMを新たに作成する必要がなく、システム１の利用料金が増加するのを防止できる。

【0024】

しかし、この例のようにスケールアウト先の仮想マシンVMのクラウド拠点が、スケールアウト元の仮想マシンVMのクラウド拠点と異なると、アプリ５の間の遅延時間が増大する可能性が高くなる。

【0025】

図５は、遅延時間の定義を示す模式図である。
ここでは、「appA」のアプリ５が「appB」のアプリ５に処理を依頼してからその結果が通知されるまでの時間を応答時間T_Rとする。また、「appB」のアプリ５が当該処理をするのに要する時間を処理時間T_Pとする。この場合、遅延時間T_LはT_R - T_Pで定義される。この定義によれば、遅延時間T_Lは、通信路に起因した遅延の長さということになる。そのため、異なるクラウド拠点にあるアプリ５の間のように、地理的に離れたアプリ５の間において遅延時間T_Lは増大し易い。

【0026】

利用者に対してサービスを提供するシステム１（図３参照）の要件には、遅延時間T_Lは上限値（例えば５msec）以下にすべきとの制約が課せられることがある。このとき、上記のようにスケールアウトによって二つのアプリ５が異なるクラウド拠点に配置されると、例えばこれらのアプリ５の間の遅延時間T_Lが１０msecとなってしまい、システム１の要件を満たせなくなってしまう。

【0027】

（本実施形態）
図６は、本実施形態に係る情報処理システムの構成図である。
この情報処理システム２０は、マルチクラウドにより利用者にサービスを提供するシステムであって、インターネット等のネットワーク２１を介して相互に接続された複数の物理サーバ２２と情報処理装置２３とを有する。

【0028】

このうち、物理サーバ２２は、クラウドを提供する事業者Aと事業者Bの各々のデータセンタに収容された計算機である。ここでは、事業者A、Bが、それぞれ「日本」と「米国」という異なるリージョンにデータセンタを保有しているものとする。なお、サービスの提供を受ける利用者が自己所有する物理サーバ２２を情報処理システム２０に含めてもよい。

【0029】

各物理サーバ２２には仮想マシンが起動しており、更にその仮想マシンの内部でコンテナが起動する。そして、各コンテナは、利用者にサービスを提供するための種々のアプリを実行する。

【0030】

情報処理装置２３は、ある仮想マシンで動作しているコンテナのリソース使用率が増えたときに、そのコンテナを他の仮想マシンにスケールアウトする制御を行うためのPC(Personal Computer)やサーバ等の計算機である。

【0031】

図７は、物理サーバ２２の模式図である。
図７に示すように、物理サーバ２２は、CPU(Central Processing Unit)やメモリ等の物理的なリソース２５を有しており、そのリソース２５がホストOS２６を実行する。

【0032】

更に、物理サーバ２２は、ホストOS２６の上で複数の仮想マシン２７を起動する。以下では、各仮想マシン２７を「VM₁」、「VM₂」、…等の文字列で識別する。各仮想マシン２７は、リソース２５の一部を使用してコンテナ２８を起動する。コンテナ２８を起動するために各仮想マシン２７が使用するコンテナエンジンとしては例えばDOCKER（登録商標）がある。そして、各コンテナ２８が一つのアプリ２９を実行する。

【0033】

図８は、各クラウド拠点で動作している仮想マシン２７、コンテナ２８、及びアプリ２９の各々を示す模式図である。

【0034】

図８に示すように、例えばクラウド拠点（事業者A、米国）において「VM₁₀」の仮想マシン２７が動作しており、この仮想マシン２７の各コンテナ２８において「appV」、「appW」、「appX」の各アプリ２９が動作している。

【0035】

図９は、仮想マシン２７、コンテナ２８、及びアプリ２９の各々によって構築されるシステム３０の模式図である。

【0036】

システム３０は、利用者が利用するシステムであって、ネットワーク２１によって相互に接続された複数の仮想マシン２７を有する。そのシステム３０においては、あるアプリ２９に処理が集中すると、そのアプリ２９を実行しているコンテナ２８に割り当てられたリソース２５（図７参照）が不足することがある。この場合には、以下のようにして情報処理装置２３（図６参照）がコンテナ２８をスケールアウトする。

【0037】

図１０～図１２は、本実施形態に係るコンテナ配置先決定方法について示す模式図である。

【0038】

まず、図１０に示すように、情報処理装置２３が、スケールアウトするコンテナ２８として、「appV」のアプリ２９が動作しているコンテナ２８を特定する。一例として、情報処理装置２３は、各コンテナ２８のリソース使用率を監視し、リソース使用率が閾値を超えた「appV」のアプリ２９が動作しているコンテナ２８をスケールアウトが必要なコンテナ２８として特定する。

【0039】

図１３は、各コンテナ２８のリソース使用率の監視結果を示す図である。
図１３においては、各コンテナ２８で動作しているアプリ２９の名前で各コンテナ２８を区別する。また、この例では、各コンテナ２８のリソース使用率としてCPU使用率とメモリ使用率の各々を採用し、リソース使用率の閾値として８５％を採用した場合を想定する。この場合、情報処理装置２３は、CPU使用率とメモリ使用率のいずれかが９５％を超えたコンテナ２８を、スケールアウトが必要なコンテナ２８として特定する。

【0040】

再び図１０を参照する。
次に、情報処理装置２３が、「appV」のアプリ２９に対して処理を依頼している依頼元のアプリ２９を特定する。アプリ２９の特定方法は特に限定されない。ここでは、情報処理装置２３は、各アプリ２９同士が対応付けられた設計情報を参照することにより依頼元のアプリ２９を特定する。

【0041】

図１４は、設計情報４０の模式図である。
設計情報４０は、開発者が情報処理システム２０を設計した際に生成した情報であって、処理の依頼元と依頼先のアプリ２９同士を対応付けた情報である。ここでは、二つのアプリ２９が処理の依頼元と依頼先との関係にある場合に記号「〇」を付し、依頼元と依頼先との関係にない場合には記号「×」を付してある。図１４によれば、情報処理装置２３は、「appV」のアプリ２９に対して処理を依頼している依頼元のアプリ２９として、「appA」、「appB」、「appO」、「appP」、「appW」、及び「appX」の各アプリ２９を特定する。

【0042】

再び図１０を参照する。
次に、情報処理装置２３が、「appV」のアプリ２９に対して処理を依頼している各アプリ２９が配置されている仮想マシン２７を特定する。図１０の例では、情報処理装置２３は、「VM₁」、「VM₇」、及び「VM₁₀」の仮想マシン２７を特定する。

【0043】

仮想マシン２７の特定方法は特に限定されない。例えば、情報処理装置２３は、Kubernetes等のコンテナ管理プログラムを実行することにより管理情報を生成し、その管理情報に基づいて仮想マシン２７を特定する。

【0044】

図１５は、その管理情報４１の模式図である。
管理情報４１は、アプリ２９とそれを実行する仮想マシン２７とを対応付けた情報である。図１５の例では、「VM₁」の仮想マシン２７が「appA」と「appB」の各コンテナ２８を実行し、「VM₇」の仮想マシン２７が「appO」と「appP」の各コンテナ２８を実行している。また、「VM₁₀」の仮想マシン２７が「appW」と「appX」の各コンテナ２８を実行している。

【0045】

次に、図１１に示すように、情報処理装置２３が、上記で特定した「VM₁」と「VM₇」の各仮想マシン２７を、「appV」のアプリ２９を実行しているコンテナ２８のスケールアウト先として決定する。なお、「VM₁₀」の仮想マシン２７においては既に「appV」のアプリ２９が実行されているため、情報処理装置２３は、「VM₁₀」の仮想マシン２７についてはスケールアウト先から除外する。

【0046】

その後、情報処理装置２３が、「VM₁」と「VM₇」の各仮想マシン２７に、「appV」のアプリ２９を実行しているコンテナ２８をスケールアウトする。ここでは、「VM₁」の仮想マシン２７にスケールアウトしたコンテナ２８が実行するアプリ２９の名前を「appV’」とし、「VM₇」の仮想マシン２７にスケールアウトしたコンテナ２８が実行するアプリ２９の名前を「appV”」とする。

【0047】

次に、図１２に示すように、情報処理装置２３が、「appA」と「appB」の各アプリ２９が処理を依頼する依頼先を、これらのアプリ２９と同じ「VM₁」の仮想マシン２７にある「appV’」のアプリ２９に変更する。同様に、情報処理装置２３は、「appO」と「appP」の各アプリ２９が処理を依頼する依頼先を、これらのアプリ２９と同じ「VM₇」の仮想マシン２７にある「appV”」のアプリ２９に変更する。

【0048】

以上により、本実施形態に係るコンテナ配置先決定方法の基本的な処理を終える。

【0049】

図１６は、上記のようにスケールアウトを行った後におけるシステム３０の模式図である。

【0050】

図１６に示すように、スケールアウトした後においては、「appA」と「appB」の各アプリ２９が処理を依頼する依頼先が、これらのアプリ２９と同じ「VM₁」の仮想マシン２７で動作する「appV’」のアプリ２９となる。同様に、「appO」と「appP」の各アプリ２９が処理を依頼する依頼先が、これらのアプリ２９と同じ「VM₇」の仮想マシン２７で動作する「appV”」のアプリ２９となる。

【0051】

これにより、スケールアウトに起因して相異なるクラウド拠点にあるアプリ２９間で処理の依頼が発生するのを抑制でき、アプリ２９の間の通信の遅延を抑制できる。その結果、システム３０の要件に遅延時間の上限値が規定されている場合に、スケールアウト後でもその要件を満たすことができるようになる。

【0052】

次に、本実施形態に係る情報処理装置２３の機能構成について説明する。

【0053】

図１７は、本実施形態に係る情報処理装置２３の機能構成図である。
図１７に示すように、情報処理装置２３は、記憶部５１、通信部５２、及び制御部５３を備える。

【0054】

このうち、記憶部５１は、前述の設計情報４０（図１４）と管理情報４１（図１５参照）とを記憶する。

【0055】

また、通信部５２は、情報処理装置２３をネットワーク２１（図６参照）に接続する通信インターフェースである。

【0056】

制御部５３は、情報処理装置２３の各部を制御する処理部であって、リソース監視部５５、アプリ特定部５６、仮想マシン特定部５７、決定部５８、スケールアウト実行部５９、及び依頼先変更部６０を有する。

【0057】

このうち、リソース監視部５５は、システム３０（図９参照）に含まれる全てのコンテナ２８のリソース使用率を監視する処理部である。監視対象のリソース使用率としては、例えばメモリ使用率とCPU使用率がある。

【0058】

アプリ特定部５６は、リソース使用率が閾値を超えたコンテナ２８で動作しているアプリ２９を特定し、更にそのアプリ２９に処理を依頼している依頼元のアプリ２９を特定する処理部である。一例として、アプリ特定部５６は、図１４の設計情報４０を参照して依頼元のアプリ２９を特定する。図１４の例において「appV」のアプリ２９が動作しているコンテナ２８のリソース使用率が閾値を超えた場合には、アプリ特定部５６は、「appA」、「appB」、「appO」、「appP」、「appW」、及び「appX」の各アプリ２９を依頼元として特定する。

【0059】

仮想マシン特定部５７は、図１５の管理情報４１を参照することにより、アプリ特定部５６が特定したアプリ２９が動作しているコンテナ２８が配置されている仮想マシン２７を特定する処理部である。図１５の例では、仮想マシン特定部５７は、「VM₁」、「VM₇」、及び「VM₁₀」の各仮想マシン２７を特定する。

【0060】

決定部５８は、仮想マシン特定部５７が特定した仮想マシン２７を、リソース使用率が閾値を超えたコンテナ２８のスケールアウト先として決定する処理部である。図１５の場合では、決定部５８は、「VM₁」と「VM₇」の各仮想マシン２７を、「appV」のアプリ２９を実行しているコンテナ２８のスケールアウト先として決定する。なお、決定部５８は、既に「appV」のアプリ２９を実行している「VM₁₀」の仮想マシン２７についてはスケールアウト先から除外する。

【0061】

スケールアウト実行部５９は、図１１に示したように、決定部５８が決定したスケールアウト先の仮想マシン２７に実際にコンテナ２８をスケールアウトする処理部である。

【0062】

依頼先変更部６０は、アプリ特定部５６が特定したアプリ２９が処理を依頼する依頼先を、スケールアウト後のコンテナ２８で動作するアプリ２９に変更する処理部である。図１２の例では、依頼先変更部６０は、「appA」と「appB」の各アプリ２９が処理を依頼する依頼先を「appV’」のアプリ２９に変更する。同様に、依頼先変更部６０は、「appO」と「appP」の各アプリ２９が処理を依頼する依頼先を「appV”」のアプリ２９に変更する。

【0063】

次に、本実施形態に係るコンテナ配置先決定方法について説明する。
図１８は、本実施形態に係るコンテナ配置先決定方法のフローチャートである。

【0064】

まず、リソース監視部５５が、システム３０（図９参照）に含まれる全てのコンテナ２８のリソース使用率を監視する（ステップＳ１１）。

【0065】

次に、アプリ特定部５６が、リソース使用率が閾値を超えたコンテナ２８で動作しているアプリ２９を特定し、更にそのアプリ２９に処理を依頼している依頼元のアプリ２９を特定する（ステップＳ１２）。

【0066】

次いで、仮想マシン特定部５７が、依頼元のアプリ２９が動作しているコンテナ２８が配置されている仮想マシン２７を特定する（ステップＳ１３）。

【0067】

続いて、決定部５８が、ステップＳ１３で特定した仮想マシン２７を、リソース使用率が閾値を超えたコンテナ２８のスケールアウト先として決定する（ステップＳ１４）。

【0068】

次に、スケールアウト実行部５９が、ステップＳ１４で決定したスケールアウト先の仮想マシン２７に、リソース使用率が閾値を超えたコンテナ２８をスケールアウトする（ステップＳ１５）。

【0069】

そして、依頼先変更部６０が、ステップＳ１２で特定したアプリ２９が処理を依頼する依頼先を、スケールアウト後のコンテナ２８で動作するアプリ２９に変更する（ステップＳ１６）。

【0070】

以上により、本実施形態に係るコンテナ配置先決定方法の基本的な処理を終える。

【0071】

上記した本実施形態によれば、リソース使用率が閾値を超えたコンテナ２８のスケールアウト先を、該アプリ２９に処理を依頼している依頼元のアプリ２９が動作しているコンテナ２８が配置されている仮想マシン２７とする。これにより、処理の依頼元と依頼先の二つのアプリ２９がスケールアウト後に同一の仮想マシン２７で動作するため、異なるクラウド拠点にある二つのアプリ２９の間で処理の依頼が発生しない。その結果、アプリ２９の間における遅延時間T_Lを抑制することができ、遅延時間T_Lがシステム３０の要件を満たさなくなる可能性を低減できる。

【0072】

（ハードウェア構成）
図１９は、情報処理装置２３のハードウェア構成図である。
図１９に示すように、情報処理装置２３は、記憶装置２３ａ、メモリ２３ｂ、プロセッサ２３ｃ、通信インターフェース２３ｄ、表示装置２３ｅ、入力装置２３ｆ、及び媒体読取装置２３ｇを有する。これらの各部は、バス２３ｉにより相互に接続される。

【0073】

このうち、記憶装置２３ａは、HDD(Hard Disk Drive)やSSD(Solid State Drive)等の不揮発性のストレージであって、本実施形態に係るコンテナ配置先決定プログラム１００を記憶する。

【0074】

なお、コンテナ配置先決定プログラム１００をコンピュータが読み取り可能な記録媒体２３ｈに記録し、媒体読取装置２３ｇを介してプロセッサ２３ｃにそのコンテナ配置先決定プログラム１００を読み取らせるようにしてもよい。

【0075】

そのような記録媒体２３ｈとしては、例えばCD-ROM (Compact Disc - Read Only Memory)、DVD (Digital Versatile Disc)、及びUSB (Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体２３ｈとして使用してもよい。これらの記録媒体２３ｈは、物理的な形態を持たない搬送波のような一時的な媒体ではない。

【0076】

更に、公衆回線、インターネット、及びLAN等に接続された装置にコンテナ配置先決定プログラム１００を記憶させてもよい。その場合は、プロセッサ２３ｃがそのコンテナ配置先決定プログラム１００を読み出して実行すればよい。

【0077】

一方、メモリ２３ｂは、DRAM(Dynamic Random Access Memory)等のようにデータを一時的に記憶するハードウェアであって、その上にコンテナ配置先決定プログラム１００が展開される。

【0078】

プロセッサ２３ｃは、情報処理装置２３の各部を制御するCPUやGPU(Graphical Processing Unit)等のハードウェアである。また、プロセッサ２３ｃは、メモリ２３ｂと協働してコンテナ配置先決定プログラム１００を実行する。

【0079】

このようにメモリ２３ｂとプロセッサ２３ｃとが協働してコンテナ配置先決定プログラム１００を実行することにより、情報処理装置２３の制御部５３（図１７参照）が実現される。その制御部５３には、リソース監視部５５、アプリ特定部５６、仮想マシン特定部５７、決定部５８、スケールアウト実行部５９、及び依頼先変更部６０が含まれる。

【0080】

また、記憶部５１（図１７参照）は、記憶装置２３ａとメモリ２３ｂによって実現される。

【0081】

更に、通信インターフェース２３ｄは、情報処理装置２３をネットワーク２１（図６参照）に接続するためのNIC(Network Interface Card)等のハードウェアである。その通信インターフェース２３ｄにより通信部５２（図１７参照）が実現される。

【0082】

そして、表示装置２３ｅは、各種の情報を表示するための液晶ディスプレイやタッチパネル等のハードウェアである。

【0083】

また、入力装置２３ｆは、システム３０の管理者が情報処理装置２３に各種のデータを入力するためのキーボードやマウス等のハードウェアである。

【0084】

媒体読取装置２３ｇは、記録媒体２３ｈを読み取るためのCDドライブ、DVDドライブ、及びUSBインターフェース等のハードウェアである。

【符号の説明】

【0085】

１…システム、４…コンテナ、５…アプリ、６…ロードバランサ、２０…情報処理システム、２１…ネットワーク、２２…物理サーバ、２３…情報処理装置、２５…リソース、２７…仮想マシン、２８…コンテナ、２９…アプリ、３０…システム、４０…設計情報、４１…管理情報、５１…記憶部、５２…通信部、５３…制御部、５５…リソース監視部、５６…アプリ特定部、５７…仮想マシン特定部、５８…決定部、５９…スケールアウト実行部、６０…依頼先変更部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】