(57)【要約】【課題】負荷が均等になるようにコンテナを起動するコンテナホストを選択する方法を提供する。【解決手段】コンテナ起動ホスト選択システムは、複数のコンテナホストのそれぞれで動作するコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値とに基づいて、起動対象のコンテナを起動させた場合の各コンテナホストでの複数種類の負荷を予測し、それらの負荷が最も小さいコンテナホストを、起動対象コンテナを起動するホストとして決定する。【選択図】図１
2020160775.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷を予測し、複数種類の前記負荷が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定するコンテナホスト制御部、
を備えるコンテナ起動ホスト選択装置。
【請求項２】
前記複数種類の負荷には、ディスクＩＯの負荷が含まれている、
請求項１に記載のコンテナ起動ホスト選択装置。
【請求項３】
前記複数種類の負荷には、ネットワークＩＯの負荷が含まれている、
請求項１または請求項２に記載のコンテナ起動ホスト選択装置。
【請求項４】
前記コンテナホストで動作した前記コンテナで稼働したアプリケーションによる複数種類の前記負荷の実績値に基づいて、前記起動コンテナで稼働するアプリケーションおよび動作中の前記コンテナで稼働するアプリケーションによる複数種類の前記負荷の予測を行う負荷情報予測部、
をさらに備える請求項１から請求項３の何れか１項に記載のコンテナ起動ホスト選択装置。
【請求項５】
前記コンテナホストから、当該コンテナホストで動作したコンテナで稼働したアプリケーションによる複数の前記負荷の実績値を取得して、前記アプリケーションごとに前記負荷の実績値を記憶部に格納する負荷情報受付部、
をさらに備える請求項１から請求項４の何れか１項に記載のコンテナ起動ホスト選択装置。
【請求項６】
前記起動コンテナに対する起動要求があると、前記起動コンテナの作成元となるイメージの識別情報と、イメージの識別情報とアプリケーションの情報とを対応付けて記憶するテーブルと、に基づいて、前記起動コンテナで稼働するアプリケーションを特定するアプリ情報判断部、
をさらに備える請求項１から請求項５の何れか１項に記載のコンテナ起動ホスト選択装置。
【請求項７】
前記テーブルが前記アプリケーションの情報を記憶していない場合、前記起動コンテナの作成元となるイメージに対するアプリケーションのインストール履歴に基づいて、前記起動コンテナで稼働するアプリケーションを推定するアプリ情報推測部、
をさらに備える請求項６に記載のコンテナ起動ホスト選択装置。
【請求項８】
請求項１から請求項６の何れか１項に記載のコンテナ起動ホスト選択装置と、
自機で動作中のコンテナで稼働するアプリケーションによる複数種類の前記負荷を取得して、前記コンテナ起動ホスト選択装置へ通知するコンテナ負荷情報収集部、を備える１又は複数のコンテナホストと、
を含むコンテナ起動ホスト選択システム。
【請求項９】
複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷を予測し、複数種類の前記負荷が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定する、
コンテナ起動ホスト選択方法。
【請求項１０】
コンピュータに、
複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷を予測し、複数種類の前記負荷が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定する処理、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテナ起動ホスト選択装置、コンテナ起動ホスト選択システム、コンテナ起動ホスト選択方法及びプログラムに関する。
【背景技術】
【０００２】
現在、多くのコンピュータシステムで仮想マシンやコンテナが利用されている。コンテナが起動するコンピュータをコンテナホストといい、１台のコンテナホスト上では複数のコンテナが動作することがある。例えば、負荷が高いアプリケーションが稼働するコンテナが、あるコンテナホストに集中すると、それらのコンテナで稼働するアプリケーションの性能に影響する。従って、コンテナを起動させる際には、コンテナホストを適切に選択し、コンテナホスト間の負荷を平準化する必要がある。ＣＰＵ（Central Processing Unit）やメモリの負荷を考慮してコンテナホストを選択する技術は既に提供されている。例えば、特許文献１には、起動するコンテナについて記載する定義書にＣＰＵ、メモリのリソース要求を記載しておき、要求を満たすコンテナホストを、確率的な分散スキームに従って選択したり、ラウンドロビン式で選択したりする方法が開示されている。また、コンテナのオーケストレーションツールであるＫｕｂｅｒｎｅｔｅｓでは、コンテナを起動するコンテナホストの選択をフィルタ、優先度付けにより行う。このツールを用いると、設定により、コンテナホスト間のＣＰＵ、メモリの負荷が均等になるようコンテナを起動することができる。
【０００３】
なお、特許文献２には、既存の仮想マシンをＣＰＵ、メモリ、ネットワーク、ストレージ、ＯＳ、ミドルウェア等の項目で構成別にタイプ分けして、各タイプ別に負荷状況を示す履歴情報を蓄積する。そして、新しい仮想マシンを配置するときに、上記項目の一致度から、新しい仮想マシンと既存の仮想マシンの類似度を算出し、その類似度と蓄積した既存マシンの負荷の履歴情報から新しい仮想マシンの負荷を予測し、その予測結果に基づいて、配置先の物理マシンを決定する方法が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１６−０５７８９８号公報
【特許文献２】特開２０１７−５３８２０４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に記載の方法は、ＣＰＵ、メモリのみを負荷分散の対象としている。このため、コンテナホスト間のブロックＩＯの負荷やネットワークＩＯの負荷にばらつきがでてしまう。また、特許文献２に記載の方法では、各項目の各種負荷への寄与度が考慮されていない。従って、例えば、ＣＰＵ、メモリ、ネットワーク、ストレージ、ＯＳ、ミドルウェアの各項目が一致する既存の同タイプの仮想マシンの負荷履歴に基づいて新たな仮想マシンの負荷を予測したとしても、新たな仮想マシンで稼働するアプリケーションが、同タイプの仮想マシンのアプリケーションと異なれば、ブロックＩＯやネットワークＩＯの負荷に大きな差異が生じる可能性がある。従って、特許文献２に記載の仮想マシンを配置する物理マシンの選択方法を、コンテナホストの選択に適用したとしても、コンテナホスト間でのブロックＩＯの負荷やネットワークＩＯの負荷のばらつきは解消できない。
コンテナホスト間の各種負荷が均等になるように、コンテナを起動するコンテナホストを選択する方法が求められている。
【０００６】
そこでこの発明は、上述の課題を解決するコンテナ起動ホスト選択装置、コンテナ起動ホスト選択システム、コンテナ起動ホスト選択方法及びプログラムを提供することを目的としている。
【課題を解決するための手段】
【０００７】
本発明の一態様によれば、コンテナ起動ホスト選択装置は、複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷を予測し、複数種類の前記負荷が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定するコンテナホスト制御部、を備える。
【０００８】
また、本発明の他の一態様によれば、コンテナ起動ホスト選択システムは、上記のコンテナ起動ホスト選択装置と、自機で動作中のコンテナにて稼働するアプリケーションによる複数種類の前記負荷を取得して、前記コンテナ起動ホスト選択装置へ通知するコンテナ負荷情報収集部、を備える１又は複数のコンテナホストと、を含む。
【０００９】
また、本発明の他の一態様によれば、複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷を予測し、複数種類の前記負荷が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定する、コンテナ起動ホスト選択方法である。
【００１０】
また、本発明の他の一態様によれば、プログラムは、コンピュータに、複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷を予測し、複数種類の前記負荷が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定する処理、を実行させる。
【発明の効果】
【００１１】
本発明によれば、複数のコンテナホストの負荷を均等に分散することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態によるコンテナ起動ホスト選択システムの一例を示す第１のブロック図である。
【図２】本発明の一実施形態によるコンテナ起動ホスト選択システムの一例を示す第２のブロック図である。
【図３】本発明の一実施形態による処理の一例を示す第１のフローチャートである。
【図４】本発明の一実施形態による処理の一例を示す第２のフローチャートである。
【図５】本発明の一実施形態による処理の一例を示すアプリケーション情報蓄積テーブルの一例を示す図である。
【図６】本発明の一実施形態による処理の一例を示す第３のフローチャートである。
【図７】本発明の一実施形態による処理の一例を示すアプリケーション推測情報蓄積テーブルの一例を示す図である。
【図８】本発明の一実施形態による処理の一例を示す第４のフローチャートである。
【図９】本発明の一実施形態による処理の一例を示す第５のフローチャートである。
【図１０】本発明の一実施形態による処理の一例を示す負荷情報蓄積テーブルの一例を示す図である。
【図１１】本発明の一実施形態による処理の一例を示す第６のフローチャートである。
【図１２】本発明の一実施形態による処理の一例を示す第７のフローチャートである。
【図１３】本発明の一実施形態による処理の一例を示す第８のフローチャートである。
【図１４】本発明の一実施形態によるコンテナ起動ホスト選択システムの最小構成を示す図である。
【図１５】本発明の一実施形態におけるコンテナ起動ホスト選択システムのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１３】
以下、一実施形態に係るコンテナ起動ホスト選択システムについて図１〜図１５を参照して説明する。
（構成の説明）
図１、図２は、それぞれ本発明の一実施形態によるコンテナ起動ホスト選択システムの一例を示す第１、第２のブロック図である。
図１に示すようにコンテナ起動ホスト選択システム３０は、クライアント００１と、コンテナ起動ホスト選択装置１００と、１又は複数のコンテナホスト２００と、を含む。クライアント００１は、コンテナ起動要求部０１０を備える。コンテナ起動ホスト選択装置１００は、コンテナ起動要求受付部１０１と、コンテナホスト制御部１０２と、アプリ情報判断部１１０と、アプリ情報記憶部１１１と、アプリ情報推測部１１２と、アプリ情報受付部１１３と、負荷情報予測部１２０と、負荷情報記憶部１２１と、負荷情報受付部１２２と、を備える。コンテナホスト２００は、コンテナ制御部２１０と、アプリ情報収集部２１１と、コンテナ負荷情報収集部２１２と、１又は複数のコンテナ２２０とを備える。
【００１４】
図２にコンテナホスト２００が２台の場合の構成例を示す。以下、この構成例を前提として説明を行う。図２に示すようにコンテナ起動ホスト選択システム３０は、クライアント００１と、コンテナ起動ホスト選択装置１００と、コンテナホスト２００ａ，２００ｂと、を含む。説明の便宜のため、コンテナホスト２００ａでは１台のコンテナ２２０ａが起動し、コンテナホスト２００ｂでは１台のコンテナ２２０ｂが起動しているとする。コンテナホスト２００ａとコンテナホスト２００ｂが備える機能部は、図１を参照して説明したものと同様である。各機能部はそれぞれ以下の機能を有している。
【００１５】
（クライアント００１）
コンテナ起動要求部０１０は、クライアント００１のコンテナの起動要求を、コンテナ起動ホスト選択装置１００のコンテナ起動要求受付部１０１に通知する。
【００１６】
（コンテナ起動ホスト選択装置１００）
コンテナ起動要求受付部１０１は、コンテナ起動要求部０１０からのコンテナ起動要求を受け付ける。コンテナ起動要求受付部１０１は、受け付けたコンテナ起動要求をコンテナホスト制御部１０２に通知する。
【００１７】
コンテナホスト制御部１０２は、アプリ情報判断部１１０にコンテナ情報を通知して、当該コンテナで動作するアプリケーションの情報（以下、アプリケーション情報と記載する。）を要求し、アプリケーション情報を取得する。コンテナホスト制御部１０２は、そのアプリケーション情報を負荷情報予測部１２０に通知し、負荷予測値を取得する。また、コンテナホスト制御部１０２は、各コンテナホスト２００ａ，２００ｂで動作するコンテナ２２０ａ，２２０ｂの識別情報をコンテナ制御部２１０ａ，２１０ｂから取得し、さらにコンテナ２２０ａ，２２０ｂで動作するアプリケーション情報を取得する。コンテナホスト制御部１０２は、それらのアプリケーション情報を負荷情報予測部１２０に通知し、負荷情報を取得する。そして、コンテナホスト制御部１０２は、現在稼働仲のコンテナ２２０ａ，２２０ｂの負荷予測値と、起動要求のあったコンテナの負荷予測値とに基づいて、コンテナを起動するコンテナホストを選択し、コンテナ制御部２１０ａ，２１０ｂのいずれかにコンテナ起動要求を通知する。
【００１８】
アプリ情報判断部１１０は、アプリ情報記憶部１１１に蓄積されたコンテナ別のアプリケーションの情報に基づいて、コンテナで動作するアプリケーションが何であるかを判断する。また、アプリ情報判断部１１０は、アプリケーション情報がアプリ情報記憶部１１１に存在しない場合、アプリ情報推測部１１２にコンテナ情報を通知し、どのようなアプリケーションが動作しているかの推測結果を得る。アプリ情報判断部１１０は、コンテナで動作するアプリケーションを示すアプリケーション情報を、コンテナホスト制御部１０２に通知する。
【００１９】
アプリ情報記憶部１１１は、コンテナ別にそのコンテナで動作するアプリケーションの情報を記憶する。
【００２０】
アプリ情報推測部１１２は、コンテナで動作するアプリケーションが未知の場合（アプリ情報記憶部１１１にアプリケーション情報が存在しない場合）、コンテナの作成元となるイメージの操作履歴情報から、コンテナで動作するアプリケーションの推測を行う。
【００２１】
アプリ情報受付部１１３は、起動中のコンテナ２２０ａ，２２０ｂで起動しているアプリケーション情報を取得し、アプリ情報記憶部１１１に格納する。
【００２２】
負荷情報予測部１２０は、負荷情報記憶部１２１に蓄積された情報に基づいて、アプリケーションの負荷を予測する。
負荷情報記憶部１２１は、アプリケーションの負荷予測に用いる情報を記憶する。
【００２３】
負荷情報受付部１２２は、負荷情報の蓄積を行う。負荷情報受付部１２２は、コンテナ負荷情報収集部２１２ａ，２１２ｂから、それぞれコンテナ２２０ａ，２２０ｂの負荷情報を取得し、アプリ情報判断部１１０からコンテナに対応するアプリケーション情報を取得した後、負荷情報を負荷情報記憶部１２１に格納する。
【００２４】
（コンテナホスト２００ａ，２００ｂ）
コンテナ制御部２１０ａは、コンテナホスト制御部１０２からの起動指示を受け、コンテナ２２０ａを起動する。また、コンテナ制御部２１０ａは、現在動作中のコンテナ２２０ａの情報をコンテナホスト制御部１０２に通知する。コンテナ制御部２１０ｂについても同様である。
アプリ情報収集部２１１ａは、コンテナ２２０ａ内で動作しているアプリケーション情報をアプリ情報受付部１１３に通知する。アプリ情報収集部２１１ｂについても同様である。
コンテナ負荷情報収集部２１２ａは、定期的にコンテナホスト２００ａで動作しているコンテナの負荷情報を収集し、負荷情報受付部１２２に通知する。コンテナ負荷情報収集部２１２ｂについても同様である。
【００２５】
（動作の説明）
以下、コンテナ起動ホスト選択システム３０の動作について詳細に説明する。
図３は、本発明の一実施形態による処理の一例を示す第１のフローチャートである。
図３にコンテナ起動ホスト選択システム３０の動作の概要を示す。
まず、コンテナ起動要求部０１０が、コンテナ起動要求受付部１０１に対し、コンテナ起動要求を通知する（ステップＳ１０１）。コンテナ起動要求では、コンテナの作成元となるイメージの識別ＩＤ（以降イメージＩＤと記載する。）が指定される。
次にコンテナホスト制御部１０２が、アプリ情報判断部１１０に対し、イメージＩＤを通知し、アプリ情報判断部１１０からアプリケーション情報を取得する（ステップＳ１０２）。
【００２６】
次にコンテナホスト制御部１０２が、負荷情報予測部１２０にアプリケーション情報などを通知し、負荷情報予測部１２０から負荷予測値を取得する（ステップＳ１０３）。
次にコンテナホスト制御部１０２が、コンテナホスト２００ａ，２００ｂの負荷予測値を要求し、それぞれの負荷予測値を取得する（ステップＳ１０４）。
【００２７】
次にコンテナホスト制御部１０２が、コンテナを起動するコンテナホストの選択を行う（ステップＳ１０５）。例えば、コンテナホスト２００ａの負荷がコンテナホスト２００ｂに比べ小さい場合、コンテナホスト制御部１０２はコンテナホスト２００ａを選択する。
次にコンテナホスト制御部１０２が、選択したコンテナホスト２００ａのコンテナ制御部２１０ａに対し、コンテナ２２０ａの起動要求を通知し、コンテナ２２０ａを起動する（ステップＳ１０６）。コンテナホスト２００ｂが選択されたときも同様である。
【００２８】
次にアプリ情報収集部２１１が、起動したコンテナ２２０ａで動作するアプリケーションの情報をアプリ情報受付部１１３に通知する。アプリ情報受付部１１３は、アプリ情報記憶部１１１が記憶するコンテナ２２０ａのイメージＩＤに対するアプリケーション情報を取得した情報で更新する（ステップＳ１０７）。
【００２９】
次にコンテナ負荷情報収集部２１２ａ，２１２ｂが、負荷情報受付部１２２に対し、動作中のコンテナ２２０ａ、２２０ｂの負荷情報を定期的に通知する。負荷情報受付部１２２は、アプリ情報判断部１１０に当該コンテナのイメージＩＤを通知し、コンテナ２２０ａ，２２０ｂに対応するアプリケーションの情報を得る。そして、負荷情報受付部１２２は、アプリケーションに対する負荷情報を負荷情報記憶部１２１に蓄積する。
【００３０】
次に図４、図５を参照して、ステップＳ１０２のイメージＩＤに対応するアプリケーションを取得する処理について詳細に説明する。
図４は、本発明の一実施形態による処理の一例を示す第２のフローチャートである。
図５は、本発明の一実施形態による処理の一例を示すアプリケーション情報蓄積テーブルの一例を示す図である。
まず、アプリ情報判断部１１０は、アプリ情報記憶部１１１に格納されているアプリケーション情報蓄積テーブル４００から、イメージＩＤに対応するアプリケーション情報のレコードを照会する（ステップＳ２０１）。図５にアプリケーション情報蓄積テーブル４００を例示する。例えば、イメージＩＤ「ｃｅｆ９５ｄ４２ａ６７ｅ」には、このイメージＩＤが示すコンテナで稼働するアプリケーション「ｎｇｉｎｘ」が対応付けて格納されている。
【００３１】
次にアプリ情報判断部１１０は、アプリケーション情報蓄積テーブル４００にイメージＩＤのレコードが存在するかどうかを判断する（ステップＳ２０２）。
レコードが存在する場合（ステップＳ２０２；Ｙｅｓ）、アプリ情報判断部１１０は、イメージＩＤに対応するアプリケーション情報を、アプリケーション情報蓄積テーブル４００から読み出して要求元のコンテナホスト制御部１０２に通知する（ステップＳ２０３）。
【００３２】
レコードが存在しない場合（ステップＳ２０２；Ｎｏ）、アプリ情報判断部１１０は、アプリ情報推測部１１２にイメージＩＤを通知し、アプリケーション情報の推測を要求する。アプリ情報推測部１１２は、アプリケーション情報の推測を実施する（ステップＳ２０４）。次にアプリ情報推測部１１２は、アプリケーションの推測結果をアプリ情報判断部１１０へ通知する。アプリ情報判断部１１０は、イメージＩＤに対応するアプリケーションの推測情報をコンテナホスト制御部１０２に通知する（ステップＳ２０５）。
【００３３】
次に図６、図７を参照して、ステップＳ２０４のアプリケーションの推測を実施する処理について詳細に説明する。
図６は、本発明の一実施形態による処理の一例を示す第３のフローチャートである。
図７は、本発明の一実施形態による処理の一例を示すアプリケーション推測情報蓄積テーブルの一例を示す図である。
まず、アプリ情報推測部１１２は、図７に例示するアプリ情報記憶部１１１に格納されているアプリケーション推測情報蓄積テーブル５００、イメージＩＤに対応するアプリケーション推測情報のレコードを照会する（ステップＳ３０１）。図７にアプリケーション推測情報蓄積テーブル５００を例示する。例えば、イメージＩＤ「ｓｉｓｅｌｋｓｉ３ｌ２３」には、このイメージＩＤが示すコンテナで稼働すると推定されるアプリケーション推測情報「ｈｔｔｐｄ」が対応付けて格納されている。
次にアプリ情報推測部１１２は、レコードが存在するどうかを判断する（ステップＳ３０２）。
【００３４】
レコードが存在する場合（ステップＳ３０２；Ｙｅｓ）、アプリ情報推測部１１２は、イメージＩＤに対応するアプリケーション推測情報をアプリケーション推測情報蓄積テーブル５００から読み出して、アプリ情報判断部１１０へ通知する（ステップＳ３０３）。
【００３５】
レコードが存在しない場合（ステップＳ３０２；Ｎｏ）、アプリ情報推測部１１２は、イメージの操作履歴を取得する。操作履歴は、例えば、ｄｏｃｋｅｒが提供するコマンド(「ｄｏｃｋｅｒ ｈｉｓｔｏｒｙ」)を用いて取得することができる。操作履歴には、操作ログ、時刻情報と、当該操作に対応する時点のイメージＩＤの情報が含まれる。なお、ｄｏｃｋｅｒとは、オープンソースで提供されるコンテナ実行基盤ソフトウェアである（ステップＳ３０４）。次にアプリ情報推測部１１２は、操作履歴よりアプリケーションのインストール操作を抽出する（ステップＳ３０５）。例えば、アプリ情報推測部１１２は、操作履歴からパッケージインストールコマンド(ｙｕｍ ｉｎｓｔａｌｌ、ａｐｔ−ｇｅｔ ｉｎｓｔａｌｌ)を抽出し、どのようなソフトウェアをインストールしたかの情報を取得する。例として「ａｐｔ−ｇｅｔ ｉｎｓｔａｌｌ ｔｏｍｃａｔ」という操作履歴が存在した場合には、「ｔｏｍｃａｔ」がインストールされたものと判断する。
アプリ情報推測部１１２は、インストール操作の履歴が存在するどうかを判断する（ステップＳ３０６）。
【００３６】
履歴が存在する場合（ステップＳ３０６；Ｙｅｓ）、アプリ情報推測部１１２は、インストール対象をアプリケーション推測情報として、イメージＩＤと対応付けてアプリケーション推測情報蓄積テーブル５００に格納する（ステップＳ３０７）。
履歴が存在しない場合（ステップＳ３０６；Ｎｏ）、アプリ情報推測部１１２は、アプリケーションが不明である旨、アプリケーション推測情報蓄積テーブル５００に格納する（ステップＳ３０８）。
アプリ情報推測部１１２は、アプリケーションの推測結果、あるいは不明である旨をアプリ情報判断部１１０へ通知する（ステップＳ３０９）。
なお本実施例では単純にインストール操作履歴のみを抽出対象としているが、インストール対象がライブラリなど、アプリケーションとは異なるものの場合もある。これを除外するため、事前にアプリケーション一覧のテーブルを用意し、一覧に記載されているもののみを抽出対象としてもよい。また、別途でサンドボックス環境を用意し、隔離した状態でイメージからコンテナを起動し、コンテナで起動したプロセスの一覧を得ることで、イメージＩＤに対応するアプリケーションを推測してもよい。
【００３７】
次に図８を参照して、ステップＳ１０７のイメージＩＤに対応するアプリケーション情報の更新処理について詳細に説明する。
図８は、本発明の一実施形態による処理の一例を示す第４のフローチャートである。
例えば、コンテナホスト２００ａがコンテナの起動先として選択され、コンテナホスト２００ａで新たなコンテナ２２０ａ２を起動したとする。アプリ情報収集部２１１ａが、コンテナ２２０ａ２の名前空間上でプロセス一覧取得コマンドを実行する。プロセス一覧取得コマンドとは、具体的には「ｎｓｅｎｔｅｒ −−ｔａｒｇｅｔ ＜＄ＰＩＤ＞ −−ｐｉｄ −ｐｓ」等である。アプリ情報収集部２１１ａは、プロセス一覧から取得できたプロセスが、コンテナ２２０ａ２で動作するアプリケーションであると特定し、そのプロセスが示すアプリケーションをアプリケーション情報として取得する（ステップＳ４０１）。
次にアプリ情報収集部２１１ａが、アプリ情報受付部１１３に、コンテナ２２０ａ２のイメージＩＤと、ステップＳ４０１で取得したアプリケーション情報を通知する（ステップＳ４０２）。
次にアプリ情報受付部１１３が、アプリ情報記憶部１１１に格納されているアプリケーション情報蓄積テーブル４００に対し、イメージＩＤとアプリケーション情報を対応付けたレコードを追加する（ステップＳ４０３）。
【００３８】
次に図９、図１０を参照して、ステップＳ１０８のアプリケーションの負荷情報を蓄積する処理について詳細に説明する。
図９は、本発明の一実施形態による処理の一例を示す第５のフローチャートである。
図１０は、本発明の一実施形態による処理の一例を示す負荷情報蓄積テーブルの一例を示す図である。
まず、コンテナ負荷情報収集部２１２ａが、定期的にコンテナ２２０ａの性能情報を取得する。例えば、コンテナ負荷情報収集部２１２ａは、コンテナ実行基盤ソフトウェアｄｏｃｋｅｒが提供する「ｄｏｃｋｅｒ ｓｔａｔｕｓ」コマンドを実行し、コンテナ毎にＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯの負荷情報を取得する。コンテナホスト２００ａで、コンテナ２２０ａ２が起動された場合、コンテナ負荷情報収集部２１２ａは、同様にして、定期的にコンテナ２２０ａ２の各種負荷情報を取得する。また、コンテナ負荷情報収集部２１２ｂは、同様にして、定期的にコンテナ２２０ｂの性能情報を取得する（ステップＳ５０１）。
次にコンテナ負荷情報収集部２１２ａ，２１２ｂが、負荷情報受付部１２２に、負荷情報を取得したコンテナ情報（コンテナ２２０ａ等のイメージＩＤ）と、取得した負荷情報を通知する（ステップＳ５０２）。
次に負荷情報受付部１２２が、アプリ情報判断部１１０にイメージＩＤを通知し、イメージＩＤに対応するアプリケーション情報を取得する（ステップＳ５０３）。
次に負荷情報受付部１２２は、ステップＳ５０２、５０３で受け付けた情報に基づいて、負荷情報記憶部１２１に対し、アプリケーション情報に対応する負荷情報を格納する。具体的には、負荷情報記憶部１２１は、図１０に例示する負荷情報蓄積テーブル６００にコンテナＩＤとイメージＩＤとアプリケーション情報と負荷情報とを対応付けた情報を、負荷情報を取得した時刻とともに追加する（ステップＳ５０４）。
【００３９】
次に図１１を参照して、ステップＳ１０３のアプリケーションの負荷予測値を取得する処理について詳細に説明する。
図１１は、本発明の一実施形態による処理の一例を示す第６のフローチャートである。
本実施形態では、アプリケーションの実行元（テナント）が同一であれば、同じアプリケーションは、同程度の周期性の負荷がかかるものと仮定し負荷予測を行う。
本実施形態ではシングルテナント環境を対象としているが、後述するようにマルチテナント環境へも拡張可能である。また、周期性は１週間として予測を行う。周期性の予測については、例えば、特開２０１３−２１４１７１に開示された技術を用いることができる。
まず、負荷情報予測部１２０が、アプリケーションに対応するＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯの予測期間分の負荷情報を、負荷情報記憶部１２１から取得する（ステップＳ６０１）。例えば、負荷情報予測部１２０は、負荷情報記憶部１２１が記憶する負荷情報蓄積テーブル６００（図１０）から１週間分の負荷情報を取得する。対象のアプリケーションについて、複数のコンテナ２２０から取得したデータが存在する場合、負荷情報予測部１２０は、その全てを負荷情報蓄積テーブル６００から取得する。
負荷情報予測部１２０が、取得した負荷情報に対し統計処理を行う。例えば、負荷情報予測部１２０は、ＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯの各負荷別に平均値を算出する。負荷情報予測部１２０は、ＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯの各負荷の平均値を、負荷予測値としてコンテナホスト制御部１０２に通知する（ステップＳ６０２）。
【００４０】
次に図１２を参照して、ステップＳ１０４の各コンテナホストの負荷予測を取得する処理について詳細に説明する。
図１２は、本発明の一実施形態による処理の一例を示す第７のフローチャートである。
まず、コンテナホスト制御部１０２が、コンテナ制御部２１０ａ，２１０ｂに対し、各コンテナホストで動作中のコンテナの一覧情報（コンテナＩＤの一覧）を要求し、取得する（ステップＳ７０１）。例えば、図２で例示した構成例であれば、コンテナ制御部２１０ａは，一覧情報としてコンテナ２２０ａの識別情報（コンテナＩＤ）を取得する。複数のコンテナ２２０が動作中の場合には、それら全てのコンテナＩＤを取得する。コンテナ制御部２１０ｂについても同様である。また、コンテナホスト制御部１０２は、例えば、所定のコマンドを発行することにより、一覧情報に含まれる各コンテナの識別情報からイメージＩＤを取得する。
次にコンテナホスト制御部１０２が、アプリ情報判断部１１０に対し、取得したコンテナのイメージＩＤを通知し、アプリケーション情報を取得する（ステップＳ７０２）。
次にコンテナホスト制御部１０２は、負荷情報予測部１２０に対し、各コンテナホスト２００ａ、２００ｂで現在動作中のコンテナについて、コンテナＩＤとイメージＩＤとアプリケーション情報を通知し、動作中のアプリケーション全てについて、負荷予測値を要求し、取得する（ステップＳ７０３）。負荷情報予測部１２０は、図１０に例示する負荷情報蓄積テーブル６００から、例えば、１週間分の負荷情報を取得し、コンテナホスト制御部１０２へ出力する。コンテナホスト制御部１０２は、例えば、取得した１週間分の負荷情報（実績値）を１週間分の負荷予測値とする。
次にコンテナホスト制御部１０２が、Ｓ７０３で取得した負荷予測値をコンテナホスト毎に、全アプリケーションについてのＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯの各負荷の予測値を負荷別に合算し、各コンテナホストの負荷予測値を算出する（ステップＳ７０４）。
【００４１】
次に図１３を参照して、ステップＳ１０５のコンテナを起動するコンテナホストを選択する処理について詳細に説明する。
図１３は、本発明の一実施形態による処理の一例を示す第８のフローチャートである。
まず、コンテナホスト制御部１０２が、ステップＳ１０３で取得したアプリケーションの負荷予測値と、ステップＳ１０４で取得した各コンテナホストの負荷予測値とを、ＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯ別に合算する（ステップＳ８０１）。つまり、コンテナホスト制御部１０２は、コンテナホスト２００ａ，２００ｂのそれぞれについて、起動対象のコンテナ２２０を追加で起動した場合の各種負荷の値を算出する。
次にコンテナホスト制御部１０２が、ステップＳ８０１で算出した各負荷の合算値の何れかが、ある時間帯に閾値を超過しているかどうかを判断する（ステップＳ８０２）。閾値を超えていた場合は、当該コンテナホストは選択対象から除外する。ただし全てのコンテナホストで閾値を超過していた場合は、全てのコンテナホストに対し次のステップを実行する。
次にコンテナホスト制御部１０２が、以下の評価関数Ｆを用いてコンテナを起動するコンテナホストを選択する（ステップＳ８０３）。コンテナホスト制御部１０２は、評価関数Ｆが示すコンテナホストを選択する。
【００４２】
【数１】
2020160775.tif 000003
【００４３】
ここで、式（１）のｘは、コンテナホスト(図２の構成例ではコンテナホスト２００ａ、２００ｂを示す。ｙは、負荷の種類（本実施形態ではＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯ）を示す。Ａｘｙは、コンテナホストｘ,負荷ｙについての予測期間における予測負荷値の平均値を示す。Ｂｙは、全コンテナホスト、負荷ｙについての予測期間における予測負荷値の平均値を示す。式（１）によって、予測期間におけるＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯの各予測負荷値の平均の合計が最も小さな値となるコンテナホスト２００が選択される。
【００４４】
本実施形態によれば、コンテナ２２０の起動時に、そのコンテナ２２０動作するアプリケーションを判断し、起動しようとするアプリケーション、およびコンテナホスト２００で起動中のアプリケーションが消費するＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯの各負荷の大きさを予測し、負荷が低いと予測されたコンテナホスト２００を選択し、そのコンテナホスト２００でコンテナ２２０を起動する。これにより、コンテナ２２０を起動するコンテナホスト２００の負荷について、ＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯの負荷を均等に分散することができる。
【００４５】
上記の実施形態では、負荷の指標として、コンテナ実行基盤ソフトウェアｄｏｃｋｅｒが提供するコマンド（「ｄｏｃｋｅｒ ｓｔａｔｕｓ」）の実行で得られるＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯを用いることとしているが、例えば、ＣＰＵ負荷やメモリ負荷の代わりに、あるいは、ＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯに加えてコンテナ２２０毎のスレッド数やファイルディスクリプタ数を用いたりするなど、他の値を負荷の指標としてもよい。
【００４６】
上記の実施形態では、コンテナホスト２００を選択するにあたり、ＣＰＵ、メモリ、ブロックＩＯ、ネットワークＩＯの負荷を同等の重みづけで扱っているが、各負荷の重みを調整してもよい。
【００４７】
また、例えば、ＣＰＵ負荷およびメモリ負荷については、それらの値が所定の閾値以下であることをコンテナホスト選択の条件とし、一方、ブロックＩＯ負荷、ネットワークＩＯ負荷については本実施形態の方法で負荷予測を行い、予測される負荷が最小となるコンテナホストを選択するようにしてもよい。
【００４８】
上記の実施形態では、シングルテナント環境を対象としているが、負荷情報を区別するアプリケーション情報に対し、テナントを識別するＩＤ（以下、テナントＩＤと記載する。）をさらに対応付けて管理するようにすることで、マルチテナント環境を対象とすることも可能である。その場合は、コンテナ起動要求通知、負荷情報通知、負荷情報蓄積テーブル６００の列項目にテナントＩＤを追加し、テナントＩＤ、アプリケーション情報に応じた負荷情報を記録し、予測に用いるようにする。
【００４９】
図１４は、本発明の一実施形態によるコンテナ起動ホスト選択装置の最小構成を示す図である。
図１４に示すようにコンテナ起動ホスト選択装置１００は、少なくともコンテナホスト制御部１０２を備える。
コンテナホスト制御部１０２は、複数のコンテナホストのそれぞれについて、各コンテナホストで動作中のコンテナで稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナで稼働するアプリケーションによる複数種類の負荷の予測値とに基づいて、複数のコンテナホストそれぞれで起動コンテナを起動した場合の複数種類の負荷を予測し、複数種類の負荷が最も小さいコンテナホストで、起動コンテナを起動すると決定する。複数種類の負荷には、ブロックＩＯ（ディスクＩＯ）又はネットワークＩＯが含まれていてもよい。
【００５０】
図１５は、本発明の一実施形態におけるコンテナ起動ホスト選択システムのハードウェア構成の一例を示す図である。
コンピュータ９００は、ＣＰＵ９０１、主記憶装置９０２、補助記憶装置９０３、入出力インタフェース９０４、通信インタフェース９０５を備える。上述のコンテナ起動ホスト選択装置１００、コンテナホスト２００は、コンピュータ９００に実装される。そして、上述した各機能部の動作は、プログラムの形式で補助記憶装置９０３に記憶されている。ＣＰＵ９０１は、プログラムを補助記憶装置９０３から読み出して主記憶装置９０２に展開し、当該プログラムに従って上記処理を実行する。また、ＣＰＵ９０１は、プログラムに従って、記憶領域を主記憶装置９０２に確保する。また、ＣＰＵ９０１は、プログラムに従って、処理中のデータを記憶する記憶領域を補助記憶装置９０３に確保する。
【００５１】
なお、少なくとも１つの実施形態において、補助記憶装置９０３は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例としては、入出力インタフェース９０４を介して接続される磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ９００に配信される場合、配信を受けたコンピュータ９００が当該プログラムを主記憶装置９０２に展開し、上記処理を実行しても良い。また、当該プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、当該プログラムは、前述した機能を補助記憶装置９０３に既に記憶されている他のプログラムとの組み合わせで実現するもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【００５２】
その他、本発明の趣旨を逸脱しない範囲で、上記した実施の形態における構成要素を周知の構成要素に置き換えることは適宜可能である。また、この発明の技術範囲は上記の実施形態に限られるものではなく、本発明の趣旨を逸脱しない範囲において種々の変更を加えることが可能である。
【符号の説明】
【００５３】
３０・・・コンテナ起動ホスト選択システム
００１・・・クライアント
０１０・・・コンテナ起動要求部
１００・・・コンテナ起動ホスト選択装置
１０１・・・コンテナ起動要求受付部
１０２・・・コンテナホスト制御部
１１０・・・アプリ情報判断部
１１１・・・アプリ情報記憶部
１１２・・・アプリ情報推測部
１１３・・・アプリ情報受付部
１２０・・・負荷情報予測部
１２１・・・負荷情報記憶部
１２２・・・負荷情報受付部
２００、２００ａ、２００ｂ・・・コンテナホスト
２１０、２１０ａ、２１０ｂ・・・コンテナ制御部
２１１、２１１ａ、２１１ｂ・・・アプリ情報収集部
２１２、２１２ａ、２１２ｂ・・・コンテナ負荷情報収集部
２２０、２２０ａ、２２０ｂ・・・コンテナ
９００・・・コンピュータ
９０１・・・ＣＰＵ
９０２・・・主記憶装置
９０３・・・補助記憶装置
９０４・・・入出力インタフェース
９０５・・・通信インタフェース
【図１】
2020160775.tif 000004
【図２】
2020160775.tif 000005
【図３】
2020160775.tif 000006
【図４】
2020160775.tif 000007
【図５】
2020160775.tif 000008
【図６】
2020160775.tif 000009
【図７】
2020160775.tif 000010
【図８】
2020160775.tif 000011
【図９】
2020160775.tif 000012
【図１０】
2020160775.tif 000013
【図１１】
2020160775.tif 000014
【図１２】
2020160775.tif 000015
【図１３】
2020160775.tif 000016
【図１４】
2020160775.tif 000017
【図１５】
2020160775.tif 000018