JP7331407B2 - コンテナ起動ホスト選択装置、コンテナ起動ホスト選択システム、コンテナ起動ホスト選択方法及びプログラム - Google Patents

コンテナ起動ホスト選択装置、コンテナ起動ホスト選択システム、コンテナ起動ホスト選択方法及びプログラム Download PDF

Info

Publication number
JP7331407B2
JP7331407B2 JP2019059250A JP2019059250A JP7331407B2 JP 7331407 B2 JP7331407 B2 JP 7331407B2 JP 2019059250 A JP2019059250 A JP 2019059250A JP 2019059250 A JP2019059250 A JP 2019059250A JP 7331407 B2 JP7331407 B2 JP 7331407B2
Authority
JP
Japan
Prior art keywords
container
running
types
load
host
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019059250A
Other languages
English (en)
Other versions
JP2020160775A (ja
Inventor
琢也 鈴木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2019059250A priority Critical patent/JP7331407B2/ja
Publication of JP2020160775A publication Critical patent/JP2020160775A/ja
Application granted granted Critical
Publication of JP7331407B2 publication Critical patent/JP7331407B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Stored Programmes (AREA)

Description

本発明は、コンテナ起動ホスト選択装置、コンテナ起動ホスト選択システム、コンテナ起動ホスト選択方法及びプログラムに関する。
現在、多くのコンピュータシステムで仮想マシンやコンテナが利用されている。コンテナが起動するコンピュータをコンテナホストといい、1台のコンテナホスト上では複数のコンテナが動作することがある。例えば、負荷が高いアプリケーションが稼働するコンテナが、あるコンテナホストに集中すると、それらのコンテナで稼働するアプリケーションの性能に影響する。従って、コンテナを起動させる際には、コンテナホストを適切に選択し、コンテナホスト間の負荷を平準化する必要がある。CPU(Central Processing Unit)やメモリの負荷を考慮してコンテナホストを選択する技術は既に提供されている。例えば、特許文献1には、起動するコンテナについて記載する定義書にCPU、メモリのリソース要求を記載しておき、要求を満たすコンテナホストを、確率的な分散スキームに従って選択したり、ラウンドロビン式で選択したりする方法が開示されている。また、コンテナのオーケストレーションツールであるKubernetesでは、コンテナを起動するコンテナホストの選択をフィルタ、優先度付けにより行う。このツールを用いると、設定により、コンテナホスト間のCPU、メモリの負荷が均等になるようコンテナを起動することができる。
なお、特許文献2には、既存の仮想マシンをCPU、メモリ、ネットワーク、ストレージ、OS、ミドルウェア等の項目で構成別にタイプ分けして、各タイプ別に負荷状況を示す履歴情報を蓄積する。そして、新しい仮想マシンを配置するときに、上記項目の一致度から、新しい仮想マシンと既存の仮想マシンの類似度を算出し、その類似度と蓄積した既存マシンの負荷の履歴情報から新しい仮想マシンの負荷を予測し、その予測結果に基づいて、配置先の物理マシンを決定する方法が開示されている。
特開2016-057898号公報 特開2017-538204号公報
特許文献1に記載の方法は、CPU、メモリのみを負荷分散の対象としている。このため、コンテナホスト間のブロックIOの負荷やネットワークIOの負荷にばらつきがでてしまう。また、特許文献2に記載の方法では、各項目の各種負荷への寄与度が考慮されていない。従って、例えば、CPU、メモリ、ネットワーク、ストレージ、OS、ミドルウェアの各項目が一致する既存の同タイプの仮想マシンの負荷履歴に基づいて新たな仮想マシンの負荷を予測したとしても、新たな仮想マシンで稼働するアプリケーションが、同タイプの仮想マシンのアプリケーションと異なれば、ブロックIOやネットワークIOの負荷に大きな差異が生じる可能性がある。従って、特許文献2に記載の仮想マシンを配置する物理マシンの選択方法を、コンテナホストの選択に適用したとしても、コンテナホスト間でのブロックIOの負荷やネットワークIOの負荷のばらつきは解消できない。
コンテナホスト間の各種負荷が均等になるように、コンテナを起動するコンテナホストを選択する方法が求められている。
そこでこの発明は、上述の課題を解決するコンテナ起動ホスト選択装置、コンテナ起動ホスト選択システム、コンテナ起動ホスト選択方法及びプログラムを提供することを目的としている。
本発明の一態様によれば、コンテナ起動ホスト選択装置は、複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷の合計を予測し、複数種類の前記負荷が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定するコンテナホスト制御部と、前記起動コンテナの作成元となるイメージの識別情報と、イメージの識別情報とアプリケーションの情報とを対応付けて記憶するテーブルと、に基づいて、前記起動コンテナで稼働するアプリケーションを特定し、前記コンテナの作成元となるイメージの識別情報と、前記テーブルと、に基づいて、前記コンテナで稼働するアプリケーションを特定するアプリ情報判断部と、前記コンテナホストで動作した前記コンテナで稼働したアプリケーションによる前記複数種類の負荷の実績値に基づいて、前記起動コンテナで稼働するアプリケーションおよび動作中の前記コンテナで稼働するアプリケーションによる複数種類の前記負荷の予測を行う負荷情報予測部と、を備え、前記起動コンテナに対する起動要求があると、前記アプリ情報判断部は、前記起動コンテナで稼働するアプリケーションを特定するとともに、前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションを特定し、前記負荷情報予測部は、特定された前記起動コンテナで稼働するアプリケーションの前記複数種類の負荷と、特定された前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションの前記複数種類の負荷とを予測し、前記コンテナホスト制御部は、前記複数のコンテナホスト別に前記コンテナホストで動作中の全てのコンテナにて稼働するアプリケーションの前記複数種類の負荷の予測値を前記複数種類別に合計し、さらにその合計した値に前記複数のコンテナホスト別に前記起動コンテナで稼働するアプリケーションの前記複数種類別の負荷を加算して、加算後の前記複数種類別の負荷の合計が最も小さい前記コンテナホストで前記起動コンテナを起動すると決定する。
また、本発明の他の一態様によれば、コンテナ起動ホスト選択システムは、上記のコンテナ起動ホスト選択装置と、自機で動作中のコンテナにて稼働するアプリケーションによる複数種類の前記負荷を取得して、前記コンテナ起動ホスト選択装置へ通知するコンテナ負荷情報収集部、を備える1又は複数のコンテナホストと、を含む。
また、本発明の他の一態様によれば、コンピュータによって実行されるコンテナ起動ホスト選択方法であって、複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷を予測し、複数種類の前記負荷の合計が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定するステップと、前記起動コンテナの作成元となるイメージの識別情報と、イメージの識別情報とアプリケーションの情報とを対応付けて記憶するテーブルと、に基づいて、前記起動コンテナで稼働するアプリケーションを特定し、前記コンテナの作成元となるイメージの識別情報と、前記テーブルと、に基づいて、前記コンテナで稼働するアプリケーションを特定するステップと、前記コンテナホストで動作した前記コンテナで稼働したアプリケーションによる複数種類の前記負荷の実績値に基づいて、前記起動コンテナで稼働するアプリケーションおよび動作中の前記コンテナで稼働するアプリケーションによる複数種類の前記負荷の予測を行うステップと、を有し、前記起動コンテナに対する起動要求があると、前記アプリケーションを特定するステップにて、前記起動コンテナで稼働するアプリケーションを特定するとともに、前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションを特定し、前記予測を行うステップにて、特定された前記起動コンテナで稼働するアプリケーションの前記複数種類の負荷と、特定された前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションの前記複数種類の負荷とを予測し、前記決定するステップにて、前記複数のコンテナホスト別に前記コンテナホストで動作中の全てのコンテナにて稼働するアプリケーションの前記複数種類の負荷の予測値を前記複数種類別に合計し、さらにその合計した値に前記複数のコンテナホスト別に前記起動コンテナで稼働するアプリケーションの前記複数種類別の負荷を加算して、加算後の前記複数種類別の負荷の合計が最も小さい前記コンテナホストで前記起動コンテナを起動すると決定する、コンテナ起動ホスト選択方法である。
また、本発明の他の一態様によれば、プログラムは、コンピュータに、複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷を予測し、複数種類の前記負荷の合計が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定するステップと、前記起動コンテナの作成元となるイメージの識別情報と、イメージの識別情報とアプリケーションの情報とを対応付けて記憶するテーブルと、に基づいて、前記起動コンテナで稼働するアプリケーションを特定し、前記コンテナの作成元となるイメージの識別情報と、前記テーブルと、に基づいて、前記コンテナで稼働するアプリケーションを特定するステップと、前記コンテナホストで動作した前記コンテナで稼働したアプリケーションによる複数種類の前記負荷の実績値に基づいて、前記起動コンテナで稼働するアプリケーションおよび動作中の前記コンテナで稼働するアプリケーションによる複数種類の前記負荷の予測を行うステップと、を有し、前記起動コンテナに対する起動要求があると、前記アプリケーションを特定するステップにて、前記起動コンテナで稼働するアプリケーションを特定するとともに、前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションを特定し、前記予測を行うステップにて、特定された前記起動コンテナで稼働するアプリケーションの前記複数種類の負荷と、特定された前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションの前記複数種類の負荷とを予測し、前記決定するステップにて、前記複数のコンテナホスト別に前記コンテナホストで動作中の全てのコンテナにて稼働するアプリケーションの前記複数種類の負荷の予測値を前記複数種類別に合計し、さらにその合計した値に前記複数のコンテナホスト別に前記起動コンテナで稼働するアプリケーションの前記複数種類別の負荷を加算して、加算後の前記複数種類別の負荷の合計が最も小さい前記コンテナホストで前記起動コンテナを起動すると決定する処理を実行させるプログラム。
本発明によれば、複数のコンテナホストの負荷を均等に分散することができる。
本発明の一実施形態によるコンテナ起動ホスト選択システムの一例を示す第1のブロック図である。 本発明の一実施形態によるコンテナ起動ホスト選択システムの一例を示す第2のブロック図である。 本発明の一実施形態による処理の一例を示す第1のフローチャートである。 本発明の一実施形態による処理の一例を示す第2のフローチャートである。 本発明の一実施形態による処理の一例を示すアプリケーション情報蓄積テーブルの一例を示す図である。 本発明の一実施形態による処理の一例を示す第3のフローチャートである。 本発明の一実施形態による処理の一例を示すアプリケーション推測情報蓄積テーブルの一例を示す図である。 本発明の一実施形態による処理の一例を示す第4のフローチャートである。 本発明の一実施形態による処理の一例を示す第5のフローチャートである。 本発明の一実施形態による処理の一例を示す負荷情報蓄積テーブルの一例を示す図である。 本発明の一実施形態による処理の一例を示す第6のフローチャートである。 本発明の一実施形態による処理の一例を示す第7のフローチャートである。 本発明の一実施形態による処理の一例を示す第8のフローチャートである。 本発明の一実施形態によるコンテナ起動ホスト選択システムの最小構成を示す図である。 本発明の一実施形態におけるコンテナ起動ホスト選択システムのハードウェア構成の一例を示す図である。
以下、一実施形態に係るコンテナ起動ホスト選択システムについて図1~図15を参照して説明する。
(構成の説明)
図1、図2は、それぞれ本発明の一実施形態によるコンテナ起動ホスト選択システムの一例を示す第1、第2のブロック図である。
図1に示すようにコンテナ起動ホスト選択システム30は、クライアント001と、コンテナ起動ホスト選択装置100と、1又は複数のコンテナホスト200と、を含む。クライアント001は、コンテナ起動要求部010を備える。コンテナ起動ホスト選択装置100は、コンテナ起動要求受付部101と、コンテナホスト制御部102と、アプリ情報判断部110と、アプリ情報記憶部111と、アプリ情報推測部112と、アプリ情報受付部113と、負荷情報予測部120と、負荷情報記憶部121と、負荷情報受付部122と、を備える。コンテナホスト200は、コンテナ制御部210と、アプリ情報収集部211と、コンテナ負荷情報収集部212と、1又は複数のコンテナ220とを備える。
図2にコンテナホスト200が2台の場合の構成例を示す。以下、この構成例を前提として説明を行う。図2に示すようにコンテナ起動ホスト選択システム30は、クライアント001と、コンテナ起動ホスト選択装置100と、コンテナホスト200a,200bと、を含む。説明の便宜のため、コンテナホスト200aでは1台のコンテナ220aが起動し、コンテナホスト200bでは1台のコンテナ220bが起動しているとする。コンテナホスト200aとコンテナホスト200bが備える機能部は、図1を参照して説明したものと同様である。各機能部はそれぞれ以下の機能を有している。
(クライアント001)
コンテナ起動要求部010は、クライアント001のコンテナの起動要求を、コンテナ起動ホスト選択装置100のコンテナ起動要求受付部101に通知する。
(コンテナ起動ホスト選択装置100)
コンテナ起動要求受付部101は、コンテナ起動要求部010からのコンテナ起動要求を受け付ける。コンテナ起動要求受付部101は、受け付けたコンテナ起動要求をコンテナホスト制御部102に通知する。
コンテナホスト制御部102は、アプリ情報判断部110にコンテナ情報を通知して、当該コンテナで動作するアプリケーションの情報(以下、アプリケーション情報と記載する。)を要求し、アプリケーション情報を取得する。コンテナホスト制御部102は、そのアプリケーション情報を負荷情報予測部120に通知し、負荷予測値を取得する。また、コンテナホスト制御部102は、各コンテナホスト200a,200bで動作するコンテナ220a,220bの識別情報をコンテナ制御部210a,210bから取得し、さらにコンテナ220a,220bで動作するアプリケーション情報を取得する。コンテナホスト制御部102は、それらのアプリケーション情報を負荷情報予測部120に通知し、負荷情報を取得する。そして、コンテナホスト制御部102は、現在稼働仲のコンテナ220a,220bの負荷予測値と、起動要求のあったコンテナの負荷予測値とに基づいて、コンテナを起動するコンテナホストを選択し、コンテナ制御部210a,210bのいずれかにコンテナ起動要求を通知する。
アプリ情報判断部110は、アプリ情報記憶部111に蓄積されたコンテナ別のアプリケーションの情報に基づいて、コンテナで動作するアプリケーションが何であるかを判断する。また、アプリ情報判断部110は、アプリケーション情報がアプリ情報記憶部111に存在しない場合、アプリ情報推測部112にコンテナ情報を通知し、どのようなアプリケーションが動作しているかの推測結果を得る。アプリ情報判断部110は、コンテナで動作するアプリケーションを示すアプリケーション情報を、コンテナホスト制御部102に通知する。
アプリ情報記憶部111は、コンテナ別にそのコンテナで動作するアプリケーションの情報を記憶する。
アプリ情報推測部112は、コンテナで動作するアプリケーションが未知の場合(アプリ情報記憶部111にアプリケーション情報が存在しない場合)、コンテナの作成元となるイメージの操作履歴情報から、コンテナで動作するアプリケーションの推測を行う。
アプリ情報受付部113は、起動中のコンテナ220a,220bで起動しているアプリケーション情報を取得し、アプリ情報記憶部111に格納する。
負荷情報予測部120は、負荷情報記憶部121に蓄積された情報に基づいて、アプリケーションの負荷を予測する。
負荷情報記憶部121は、アプリケーションの負荷予測に用いる情報を記憶する。
負荷情報受付部122は、負荷情報の蓄積を行う。負荷情報受付部122は、コンテナ負荷情報収集部212a,212bから、それぞれコンテナ220a,220bの負荷情報を取得し、アプリ情報判断部110からコンテナに対応するアプリケーション情報を取得した後、負荷情報を負荷情報記憶部121に格納する。
(コンテナホスト200a,200b)
コンテナ制御部210aは、コンテナホスト制御部102からの起動指示を受け、コンテナ220aを起動する。また、コンテナ制御部210aは、現在動作中のコンテナ220aの情報をコンテナホスト制御部102に通知する。コンテナ制御部210bについても同様である。
アプリ情報収集部211aは、コンテナ220a内で動作しているアプリケーション情報をアプリ情報受付部113に通知する。アプリ情報収集部211bについても同様である。
コンテナ負荷情報収集部212aは、定期的にコンテナホスト200aで動作しているコンテナの負荷情報を収集し、負荷情報受付部122に通知する。コンテナ負荷情報収集部212bについても同様である。
(動作の説明)
以下、コンテナ起動ホスト選択システム30の動作について詳細に説明する。
図3は、本発明の一実施形態による処理の一例を示す第1のフローチャートである。
図3にコンテナ起動ホスト選択システム30の動作の概要を示す。
まず、コンテナ起動要求部010が、コンテナ起動要求受付部101に対し、コンテナ起動要求を通知する(ステップS101)。コンテナ起動要求では、コンテナの作成元となるイメージの識別ID(以降イメージIDと記載する。)が指定される。
次にコンテナホスト制御部102が、アプリ情報判断部110に対し、イメージIDを通知し、アプリ情報判断部110からアプリケーション情報を取得する(ステップS102)。
次にコンテナホスト制御部102が、負荷情報予測部120にアプリケーション情報などを通知し、負荷情報予測部120から負荷予測値を取得する(ステップS103)。
次にコンテナホスト制御部102が、コンテナホスト200a,200bの負荷予測値を要求し、それぞれの負荷予測値を取得する(ステップS104)。
次にコンテナホスト制御部102が、コンテナを起動するコンテナホストの選択を行う(ステップS105)。例えば、コンテナホスト200aの負荷がコンテナホスト200bに比べ小さい場合、コンテナホスト制御部102はコンテナホスト200aを選択する。
次にコンテナホスト制御部102が、選択したコンテナホスト200aのコンテナ制御部210aに対し、コンテナ220aの起動要求を通知し、コンテナ220aを起動する(ステップS106)。コンテナホスト200bが選択されたときも同様である。
次にアプリ情報収集部211が、起動したコンテナ220aで動作するアプリケーションの情報をアプリ情報受付部113に通知する。アプリ情報受付部113は、アプリ情報記憶部111が記憶するコンテナ220aのイメージIDに対するアプリケーション情報を取得した情報で更新する(ステップS107)。
次にコンテナ負荷情報収集部212a,212bが、負荷情報受付部122に対し、動作中のコンテナ220a、220bの負荷情報を定期的に通知する。負荷情報受付部122は、アプリ情報判断部110に当該コンテナのイメージIDを通知し、コンテナ220a,220bに対応するアプリケーションの情報を得る。そして、負荷情報受付部122は、アプリケーションに対する負荷情報を負荷情報記憶部121に蓄積する。
次に図4、図5を参照して、ステップS102のイメージIDに対応するアプリケーションを取得する処理について詳細に説明する。
図4は、本発明の一実施形態による処理の一例を示す第2のフローチャートである。
図5は、本発明の一実施形態による処理の一例を示すアプリケーション情報蓄積テーブルの一例を示す図である。
まず、アプリ情報判断部110は、アプリ情報記憶部111に格納されているアプリケーション情報蓄積テーブル400から、イメージIDに対応するアプリケーション情報のレコードを照会する(ステップS201)。図5にアプリケーション情報蓄積テーブル400を例示する。例えば、イメージID「cef95d42a67e」には、このイメージIDが示すコンテナで稼働するアプリケーション「nginx」が対応付けて格納されている。
次にアプリ情報判断部110は、アプリケーション情報蓄積テーブル400にイメージIDのレコードが存在するかどうかを判断する(ステップS202)。
レコードが存在する場合(ステップS202;Yes)、アプリ情報判断部110は、イメージIDに対応するアプリケーション情報を、アプリケーション情報蓄積テーブル400から読み出して要求元のコンテナホスト制御部102に通知する(ステップS203)。
レコードが存在しない場合(ステップS202;No)、アプリ情報判断部110は、アプリ情報推測部112にイメージIDを通知し、アプリケーション情報の推測を要求する。アプリ情報推測部112は、アプリケーション情報の推測を実施する(ステップS204)。次にアプリ情報推測部112は、アプリケーションの推測結果をアプリ情報判断部110へ通知する。アプリ情報判断部110は、イメージIDに対応するアプリケーションの推測情報をコンテナホスト制御部102に通知する(ステップS205)。
次に図6、図7を参照して、ステップS204のアプリケーションの推測を実施する処理について詳細に説明する。
図6は、本発明の一実施形態による処理の一例を示す第3のフローチャートである。
図7は、本発明の一実施形態による処理の一例を示すアプリケーション推測情報蓄積テーブルの一例を示す図である。
まず、アプリ情報推測部112は、図7に例示するアプリ情報記憶部111に格納されているアプリケーション推測情報蓄積テーブル500、イメージIDに対応するアプリケーション推測情報のレコードを照会する(ステップS301)。図7にアプリケーション推測情報蓄積テーブル500を例示する。例えば、イメージID「siselksi3l23」には、このイメージIDが示すコンテナで稼働すると推定されるアプリケーション推測情報「httpd」が対応付けて格納されている。
次にアプリ情報推測部112は、レコードが存在するどうかを判断する(ステップS302)。
レコードが存在する場合(ステップS302;Yes)、アプリ情報推測部112は、イメージIDに対応するアプリケーション推測情報をアプリケーション推測情報蓄積テーブル500から読み出して、アプリ情報判断部110へ通知する(ステップS303)。
レコードが存在しない場合(ステップS302;No)、アプリ情報推測部112は、イメージの操作履歴を取得する。操作履歴は、例えば、dockerが提供するコマンド(「docker history」)を用いて取得することができる。操作履歴には、操作ログ、時刻情報と、当該操作に対応する時点のイメージIDの情報が含まれる。なお、dockerとは、オープンソースで提供されるコンテナ実行基盤ソフトウェアである(ステップS304)。次にアプリ情報推測部112は、操作履歴よりアプリケーションのインストール操作を抽出する(ステップS305)。例えば、アプリ情報推測部112は、操作履歴からパッケージインストールコマンド(yum install、apt-get install)を抽出し、どのようなソフトウェアをインストールしたかの情報を取得する。例として「apt-get install tomcat」という操作履歴が存在した場合には、「tomcat」がインストールされたものと判断する。
アプリ情報推測部112は、インストール操作の履歴が存在するどうかを判断する(ステップS306)。
履歴が存在する場合(ステップS306;Yes)、アプリ情報推測部112は、インストール対象をアプリケーション推測情報として、イメージIDと対応付けてアプリケーション推測情報蓄積テーブル500に格納する(ステップS307)。
履歴が存在しない場合(ステップS306;No)、アプリ情報推測部112は、アプリケーションが不明である旨、アプリケーション推測情報蓄積テーブル500に格納する(ステップS308)。
アプリ情報推測部112は、アプリケーションの推測結果、あるいは不明である旨をアプリ情報判断部110へ通知する(ステップS309)。
なお本実施例では単純にインストール操作履歴のみを抽出対象としているが、インストール対象がライブラリなど、アプリケーションとは異なるものの場合もある。これを除外するため、事前にアプリケーション一覧のテーブルを用意し、一覧に記載されているもののみを抽出対象としてもよい。また、別途でサンドボックス環境を用意し、隔離した状態でイメージからコンテナを起動し、コンテナで起動したプロセスの一覧を得ることで、イメージIDに対応するアプリケーションを推測してもよい。
次に図8を参照して、ステップS107のイメージIDに対応するアプリケーション情報の更新処理について詳細に説明する。
図8は、本発明の一実施形態による処理の一例を示す第4のフローチャートである。
例えば、コンテナホスト200aがコンテナの起動先として選択され、コンテナホスト200aで新たなコンテナ220a2を起動したとする。アプリ情報収集部211aが、コンテナ220a2の名前空間上でプロセス一覧取得コマンドを実行する。プロセス一覧取得コマンドとは、具体的には「nsenter --target <$PID> --pid -ps」等である。アプリ情報収集部211aは、プロセス一覧から取得できたプロセスが、コンテナ220a2で動作するアプリケーションであると特定し、そのプロセスが示すアプリケーションをアプリケーション情報として取得する(ステップS401)。
次にアプリ情報収集部211aが、アプリ情報受付部113に、コンテナ220a2のイメージIDと、ステップS401で取得したアプリケーション情報を通知する(ステップS402)。
次にアプリ情報受付部113が、アプリ情報記憶部111に格納されているアプリケーション情報蓄積テーブル400に対し、イメージIDとアプリケーション情報を対応付けたレコードを追加する(ステップS403)。
次に図9、図10を参照して、ステップS108のアプリケーションの負荷情報を蓄積する処理について詳細に説明する。
図9は、本発明の一実施形態による処理の一例を示す第5のフローチャートである。
図10は、本発明の一実施形態による処理の一例を示す負荷情報蓄積テーブルの一例を示す図である。
まず、コンテナ負荷情報収集部212aが、定期的にコンテナ220aの性能情報を取得する。例えば、コンテナ負荷情報収集部212aは、コンテナ実行基盤ソフトウェアdockerが提供する「docker status」コマンドを実行し、コンテナ毎にCPU、メモリ、ブロックIO、ネットワークIOの負荷情報を取得する。コンテナホスト200aで、コンテナ220a2が起動された場合、コンテナ負荷情報収集部212aは、同様にして、定期的にコンテナ220a2の各種負荷情報を取得する。また、コンテナ負荷情報収集部212bは、同様にして、定期的にコンテナ220bの性能情報を取得する(ステップS501)。
次にコンテナ負荷情報収集部212a,212bが、負荷情報受付部122に、負荷情報を取得したコンテナ情報(コンテナ220a等のイメージID)と、取得した負荷情報を通知する(ステップS502)。
次に負荷情報受付部122が、アプリ情報判断部110にイメージIDを通知し、イメージIDに対応するアプリケーション情報を取得する(ステップS503)。
次に負荷情報受付部122は、ステップS502、503で受け付けた情報に基づいて、負荷情報記憶部121に対し、アプリケーション情報に対応する負荷情報を格納する。具体的には、負荷情報記憶部121は、図10に例示する負荷情報蓄積テーブル600にコンテナIDとイメージIDとアプリケーション情報と負荷情報とを対応付けた情報を、負荷情報を取得した時刻とともに追加する(ステップS504)。
次に図11を参照して、ステップS103のアプリケーションの負荷予測値を取得する処理について詳細に説明する。
図11は、本発明の一実施形態による処理の一例を示す第6のフローチャートである。
本実施形態では、アプリケーションの実行元(テナント)が同一であれば、同じアプリケーションは、同程度の周期性の負荷がかかるものと仮定し負荷予測を行う。
本実施形態ではシングルテナント環境を対象としているが、後述するようにマルチテナント環境へも拡張可能である。また、周期性は1週間として予測を行う。周期性の予測については、例えば、特開2013-214171に開示された技術を用いることができる。
まず、負荷情報予測部120が、アプリケーションに対応するCPU、メモリ、ブロックIO、ネットワークIOの予測期間分の負荷情報を、負荷情報記憶部121から取得する(ステップS601)。例えば、負荷情報予測部120は、負荷情報記憶部121が記憶する負荷情報蓄積テーブル600(図10)から1週間分の負荷情報を取得する。対象のアプリケーションについて、複数のコンテナ220から取得したデータが存在する場合、負荷情報予測部120は、その全てを負荷情報蓄積テーブル600から取得する。
負荷情報予測部120が、取得した負荷情報に対し統計処理を行う。例えば、負荷情報予測部120は、CPU、メモリ、ブロックIO、ネットワークIOの各負荷別に平均値を算出する。負荷情報予測部120は、CPU、メモリ、ブロックIO、ネットワークIOの各負荷の平均値を、負荷予測値としてコンテナホスト制御部102に通知する(ステップS602)。
次に図12を参照して、ステップS104の各コンテナホストの負荷予測を取得する処理について詳細に説明する。
図12は、本発明の一実施形態による処理の一例を示す第7のフローチャートである。
まず、コンテナホスト制御部102が、コンテナ制御部210a,210bに対し、各コンテナホストで動作中のコンテナの一覧情報(コンテナIDの一覧)を要求し、取得する(ステップS701)。例えば、図2で例示した構成例であれば、コンテナ制御部210aは,一覧情報としてコンテナ220aの識別情報(コンテナID)を取得する。複数のコンテナ220が動作中の場合には、それら全てのコンテナIDを取得する。コンテナ制御部210bについても同様である。また、コンテナホスト制御部102は、例えば、所定のコマンドを発行することにより、一覧情報に含まれる各コンテナの識別情報からイメージIDを取得する。
次にコンテナホスト制御部102が、アプリ情報判断部110に対し、取得したコンテナのイメージIDを通知し、アプリケーション情報を取得する(ステップS702)。
次にコンテナホスト制御部102は、負荷情報予測部120に対し、各コンテナホスト200a、200bで現在動作中のコンテナについて、コンテナIDとイメージIDとアプリケーション情報を通知し、動作中のアプリケーション全てについて、負荷予測値を要求し、取得する(ステップS703)。負荷情報予測部120は、図10に例示する負荷情報蓄積テーブル600から、例えば、1週間分の負荷情報を取得し、コンテナホスト制御部102へ出力する。コンテナホスト制御部102は、例えば、取得した1週間分の負荷情報(実績値)を1週間分の負荷予測値とする。
次にコンテナホスト制御部102が、S703で取得した負荷予測値をコンテナホスト毎に、全アプリケーションについてのCPU、メモリ、ブロックIO、ネットワークIOの各負荷の予測値を負荷別に合算し、各コンテナホストの負荷予測値を算出する(ステップS704)。
次に図13を参照して、ステップS105のコンテナを起動するコンテナホストを選択する処理について詳細に説明する。
図13は、本発明の一実施形態による処理の一例を示す第8のフローチャートである。
まず、コンテナホスト制御部102が、ステップS103で取得したアプリケーションの負荷予測値と、ステップS104で取得した各コンテナホストの負荷予測値とを、CPU、メモリ、ブロックIO、ネットワークIO別に合算する(ステップS801)。つまり、コンテナホスト制御部102は、コンテナホスト200a,200bのそれぞれについて、起動対象のコンテナ220を追加で起動した場合の各種負荷の値を算出する。
次にコンテナホスト制御部102が、ステップS801で算出した各負荷の合算値の何れかが、ある時間帯に閾値を超過しているかどうかを判断する(ステップS802)。閾値を超えていた場合は、当該コンテナホストは選択対象から除外する。ただし全てのコンテナホストで閾値を超過していた場合は、全てのコンテナホストに対し次のステップを実行する。
次にコンテナホスト制御部102が、以下の評価関数Fを用いてコンテナを起動するコンテナホストを選択する(ステップS803)。コンテナホスト制御部102は、評価関数Fが示すコンテナホストを選択する。
Figure 0007331407000001
ここで、式(1)のxは、コンテナホスト(図2の構成例ではコンテナホスト200a、200bを示す。yは、負荷の種類(本実施形態ではCPU、メモリ、ブロックIO、ネットワークIO)を示す。Axyは、コンテナホストx,負荷yについての予測期間における予測負荷値の平均値を示す。Byは、全コンテナホスト、負荷yについての予測期間における予測負荷値の平均値を示す。式(1)によって、予測期間におけるCPU、メモリ、ブロックIO、ネットワークIOの各予測負荷値の平均の合計が最も小さな値となるコンテナホスト200が選択される。
本実施形態によれば、コンテナ220の起動時に、そのコンテナ220動作するアプリケーションを判断し、起動しようとするアプリケーション、およびコンテナホスト200で起動中のアプリケーションが消費するCPU、メモリ、ブロックIO、ネットワークIOの各負荷の大きさを予測し、負荷が低いと予測されたコンテナホスト200を選択し、そのコンテナホスト200でコンテナ220を起動する。これにより、コンテナ220を起動するコンテナホスト200の負荷について、CPU、メモリ、ブロックIO、ネットワークIOの負荷を均等に分散することができる。
上記の実施形態では、負荷の指標として、コンテナ実行基盤ソフトウェアdockerが提供するコマンド(「docker status」)の実行で得られるCPU、メモリ、ブロックIO、ネットワークIOを用いることとしているが、例えば、CPU負荷やメモリ負荷の代わりに、あるいは、CPU、メモリ、ブロックIO、ネットワークIOに加えてコンテナ220毎のスレッド数やファイルディスクリプタ数を用いたりするなど、他の値を負荷の指標としてもよい。
上記の実施形態では、コンテナホスト200を選択するにあたり、CPU、メモリ、ブロックIO、ネットワークIOの負荷を同等の重みづけで扱っているが、各負荷の重みを調整してもよい。
また、例えば、CPU負荷およびメモリ負荷については、それらの値が所定の閾値以下であることをコンテナホスト選択の条件とし、一方、ブロックIO負荷、ネットワークIO負荷については本実施形態の方法で負荷予測を行い、予測される負荷が最小となるコンテナホストを選択するようにしてもよい。
上記の実施形態では、シングルテナント環境を対象としているが、負荷情報を区別するアプリケーション情報に対し、テナントを識別するID(以下、テナントIDと記載する。)をさらに対応付けて管理するようにすることで、マルチテナント環境を対象とすることも可能である。その場合は、コンテナ起動要求通知、負荷情報通知、負荷情報蓄積テーブル600の列項目にテナントIDを追加し、テナントID、アプリケーション情報に応じた負荷情報を記録し、予測に用いるようにする。
図14は、本発明の一実施形態によるコンテナ起動ホスト選択装置の最小構成を示す図である。
図14に示すようにコンテナ起動ホスト選択装置100は、少なくともコンテナホスト制御部102を備える。
コンテナホスト制御部102は、複数のコンテナホストのそれぞれについて、各コンテナホストで動作中のコンテナで稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナで稼働するアプリケーションによる複数種類の負荷の予測値とに基づいて、複数のコンテナホストそれぞれで起動コンテナを起動した場合の複数種類の負荷を予測し、複数種類の負荷が最も小さいコンテナホストで、起動コンテナを起動すると決定する。複数種類の負荷には、ブロックIO(ディスクIO)又はネットワークIOが含まれていてもよい。
図15は、本発明の一実施形態におけるコンテナ起動ホスト選択システムのハードウェア構成の一例を示す図である。
コンピュータ900は、CPU901、主記憶装置902、補助記憶装置903、入出力インタフェース904、通信インタフェース905を備える。上述のコンテナ起動ホスト選択装置100、コンテナホスト200は、コンピュータ900に実装される。そして、上述した各機能部の動作は、プログラムの形式で補助記憶装置903に記憶されている。CPU901は、プログラムを補助記憶装置903から読み出して主記憶装置902に展開し、当該プログラムに従って上記処理を実行する。また、CPU901は、プログラムに従って、記憶領域を主記憶装置902に確保する。また、CPU901は、プログラムに従って、処理中のデータを記憶する記憶領域を補助記憶装置903に確保する。
なお、少なくとも1つの実施形態において、補助記憶装置903は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例としては、入出力インタフェース904を介して接続される磁気ディスク、光磁気ディスク、CD-ROM、DVD-ROM、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ900に配信される場合、配信を受けたコンピュータ900が当該プログラムを主記憶装置902に展開し、上記処理を実行しても良い。また、当該プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、当該プログラムは、前述した機能を補助記憶装置903に既に記憶されている他のプログラムとの組み合わせで実現するもの、いわゆる差分ファイル(差分プログラム)であっても良い。
その他、本発明の趣旨を逸脱しない範囲で、上記した実施の形態における構成要素を周知の構成要素に置き換えることは適宜可能である。また、この発明の技術範囲は上記の実施形態に限られるものではなく、本発明の趣旨を逸脱しない範囲において種々の変更を加えることが可能である。
30・・・コンテナ起動ホスト選択システム
001・・・クライアント
010・・・コンテナ起動要求部
100・・・コンテナ起動ホスト選択装置
101・・・コンテナ起動要求受付部
102・・・コンテナホスト制御部
110・・・アプリ情報判断部
111・・・アプリ情報記憶部
112・・・アプリ情報推測部
113・・・アプリ情報受付部
120・・・負荷情報予測部
121・・・負荷情報記憶部
122・・・負荷情報受付部
200、200a、200b・・・コンテナホスト
210、210a、210b・・・コンテナ制御部
211、211a、211b・・・アプリ情報収集部
212、212a、212b・・・コンテナ負荷情報収集部
220、220a、220b・・・コンテナ
900・・・コンピュータ
901・・・CPU
902・・・主記憶装置
903・・・補助記憶装置
904・・・入出力インタフェース
905・・・通信インタフェース

Claims (10)

  1. 複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷を予測し、複数種類の前記負荷の合計が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定するコンテナホスト制御部と、
    前記起動コンテナの作成元となるイメージの識別情報と、イメージの識別情報とアプリケーションの情報とを対応付けて記憶するテーブルと、に基づいて、前記起動コンテナで稼働するアプリケーションを特定し、前記コンテナの作成元となるイメージの識別情報と、前記テーブルと、に基づいて、前記コンテナで稼働するアプリケーションを特定するアプリ情報判断部と、
    前記コンテナホストで動作した前記コンテナで稼働したアプリケーションによる前記複数種類の負荷の実績値に基づいて、前記起動コンテナで稼働するアプリケーションおよび動作中の前記コンテナで稼働するアプリケーションによる複数種類の前記負荷の予測を行う負荷情報予測部と、
    を備え
    前記起動コンテナに対する起動要求があると、
    前記アプリ情報判断部は、前記起動コンテナで稼働するアプリケーションを特定するとともに、前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションを特定し、
    前記負荷情報予測部は、特定された前記起動コンテナで稼働するアプリケーションの前記複数種類の負荷と、特定された前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションの前記複数種類の負荷とを予測し、
    前記コンテナホスト制御部は、前記複数のコンテナホスト別に前記コンテナホストで動作中の全てのコンテナにて稼働するアプリケーションの前記複数種類の負荷の予測値を前記複数種類別に合計し、さらにその合計した値に前記複数のコンテナホスト別に前記起動コンテナで稼働するアプリケーションの前記複数種類別の負荷を加算して、加算後の前記複数種類別の負荷の合計が最も小さい前記コンテナホストで前記起動コンテナを起動すると決定する、コンテナ起動ホスト選択装置。
  2. 前記複数種類の負荷には、ディスクIOの負荷が含まれている、
    請求項1に記載のコンテナ起動ホスト選択装置。
  3. 前記複数種類の負荷には、ネットワークIOの負荷が含まれている、
    請求項1または請求項2に記載のコンテナ起動ホスト選択装置。
  4. 前記コンテナホスト制御部は、加算後の前記複数種類別の負荷のうちの何れか1つ又は複数を所定の閾値と比較して、前記閾値を超える負荷が存在する場合には、そのコンテナホストを、記起動コンテナを起動する対象から除外する、
    請求項1から請求項3の何れか1項に記載のコンテナ起動ホスト選択装置。
  5. 前記コンテナホストから、当該コンテナホストで動作したコンテナで稼働したアプリケーションによる複数の前記負荷の実績値を取得して、前記アプリケーションごとに前記負荷の実績値を記憶部に格納する負荷情報受付部、
    をさらに備える請求項1から請求項4の何れか1項に記載のコンテナ起動ホスト選択装置。
  6. 前記コンテナホスト制御部は、加算後の前記複数種類別の負荷のそれぞれについて、全ての前記コンテナホストの平均値を算出し、前記コンテナホストごとに加算後の前記複数種類別の負荷のそれぞれから同じ種類の負荷に係る前記平均値を減算し、さらに減算した値を前記平均値で除算して第1評価値を算出し、全ての前記複数種類の負荷について前記第1評価値の加重和を計算した値が最も小さい前記コンテナホストで前記起動コンテナを起動すると決定する、
    請求項1から請求項5の何れか1項に記載のコンテナ起動ホスト選択装置。
  7. 前記起動コンテナで稼働するアプリケーションについて前記テーブルが前記アプリケーションの情報を記憶していない場合、前記起動コンテナの作成元となるイメージに対するアプリケーションのインストール履歴に基づいて、前記起動コンテナで稼働するアプリケーションを推定するアプリ情報推測部、
    をさらに備え
    前記負荷情報予測部は、推定された前記アプリケーションの前記複数種類の負荷を予測する、
    請求項1から請求項6の何れか1項に記載のコンテナ起動ホスト選択装置。
  8. 請求項1から請求項6の何れか1項に記載のコンテナ起動ホスト選択装置と、
    自機で動作中のコンテナで稼働するアプリケーションによる複数種類の前記負荷を取得して、前記コンテナ起動ホスト選択装置へ通知するコンテナ負荷情報収集部、を備える1又は複数のコンテナホストと、
    を含むコンテナ起動ホスト選択システム。
  9. コンピュータによって実行されるコンテナ起動ホスト選択方法であって、
    複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷を予測し、複数種類の前記負荷の合計が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定するステップと、
    前記起動コンテナの作成元となるイメージの識別情報と、イメージの識別情報とアプリケーションの情報とを対応付けて記憶するテーブルと、に基づいて、前記起動コンテナで稼働するアプリケーションを特定し、前記コンテナの作成元となるイメージの識別情報と、前記テーブルと、に基づいて、前記コンテナで稼働するアプリケーションを特定するステップと、
    前記コンテナホストで動作した前記コンテナで稼働したアプリケーションによる複数種類の前記負荷の実績値に基づいて、前記起動コンテナで稼働するアプリケーションおよび動作中の前記コンテナで稼働するアプリケーションによる複数種類の前記負荷の予測を行うステップと、を有し、
    前記起動コンテナに対する起動要求があると、
    前記アプリケーションを特定するステップにて、前記起動コンテナで稼働するアプリケーションを特定するとともに、前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションを特定し、
    前記予測を行うステップにて、特定された前記起動コンテナで稼働するアプリケーションの前記複数種類の負荷と、特定された前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションの前記複数種類の負荷とを予測し、
    前記決定するステップにて、前記複数のコンテナホスト別に前記コンテナホストで動作中の全てのコンテナにて稼働するアプリケーションの前記複数種類の負荷の予測値を前記複数種類別に合計し、さらにその合計した値に前記複数のコンテナホスト別に前記起動コンテナで稼働するアプリケーションの前記複数種類別の負荷を加算して、加算後の前記複数種類別の負荷の合計が最も小さい前記コンテナホストで前記起動コンテナを起動すると決定する、コンテナ起動ホスト選択方法。
  10. コンピュータに、
    複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションによる複数種類の負荷の予測値と、起動対象のコンテナである起動コンテナにて稼働するアプリケーションによる複数種類の前記負荷の予測値とに基づいて、前記コンテナホストのそれぞれについて前記起動コンテナを起動した場合の複数種類の前記負荷を予測し、複数種類の前記負荷の合計が最も小さい前記コンテナホストを選択し、選択した前記コンテナホストで前記起動コンテナを起動すると決定するステップと、
    前記起動コンテナの作成元となるイメージの識別情報と、イメージの識別情報とアプリケーションの情報とを対応付けて記憶するテーブルと、に基づいて、前記起動コンテナで稼働するアプリケーションを特定し、前記コンテナの作成元となるイメージの識別情報と、前記テーブルと、に基づいて、前記コンテナで稼働するアプリケーションを特定するステップと、
    前記コンテナホストで動作した前記コンテナで稼働したアプリケーションによる複数種類の前記負荷の実績値に基づいて、前記起動コンテナで稼働するアプリケーションおよび動作中の前記コンテナで稼働するアプリケーションによる複数種類の前記負荷の予測を行うステップと、を有し、
    前記起動コンテナに対する起動要求があると、
    前記アプリケーションを特定するステップにて、前記起動コンテナで稼働するアプリケーションを特定するとともに、前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションを特定し、
    前記予測を行うステップにて、特定された前記起動コンテナで稼働するアプリケーションの前記複数種類の負荷と、特定された前記複数のコンテナホストのそれぞれで動作中のコンテナにて稼働するアプリケーションの前記複数種類の負荷とを予測し、
    前記決定するステップにて、前記複数のコンテナホスト別に前記コンテナホストで動作中の全てのコンテナにて稼働するアプリケーションの前記複数種類の負荷の予測値を前記複数種類別に合計し、さらにその合計した値に前記複数のコンテナホスト別に前記起動コンテナで稼働するアプリケーションの前記複数種類別の負荷を加算して、加算後の前記複数種類別の負荷の合計が最も小さい前記コンテナホストで前記起動コンテナを起動すると決定する処理、を実行させるプログラム。
JP2019059250A 2019-03-26 2019-03-26 コンテナ起動ホスト選択装置、コンテナ起動ホスト選択システム、コンテナ起動ホスト選択方法及びプログラム Active JP7331407B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2019059250A JP7331407B2 (ja) 2019-03-26 2019-03-26 コンテナ起動ホスト選択装置、コンテナ起動ホスト選択システム、コンテナ起動ホスト選択方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019059250A JP7331407B2 (ja) 2019-03-26 2019-03-26 コンテナ起動ホスト選択装置、コンテナ起動ホスト選択システム、コンテナ起動ホスト選択方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2020160775A JP2020160775A (ja) 2020-10-01
JP7331407B2 true JP7331407B2 (ja) 2023-08-23

Family

ID=72643482

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019059250A Active JP7331407B2 (ja) 2019-03-26 2019-03-26 コンテナ起動ホスト選択装置、コンテナ起動ホスト選択システム、コンテナ起動ホスト選択方法及びプログラム

Country Status (1)

Country Link
JP (1) JP7331407B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102438916B1 (ko) * 2020-11-18 2022-09-01 (주)글루시스 컨테이너 기반의 가상화 시스템 및 가상화 시스템에서 컨테이너의 자원을 확장하는 방법
JP7399427B2 (ja) * 2021-03-05 2023-12-18 ソフトバンク株式会社 サーバ、およびコンテナシステム
WO2023218664A1 (ja) * 2022-05-13 2023-11-16 楽天モバイル株式会社 リプレースシステム及びリプレース方法
WO2023218663A1 (ja) * 2022-05-13 2023-11-16 楽天モバイル株式会社 実行基盤決定システム及び実行基盤決定方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018003031A1 (ja) 2016-06-29 2018-01-04 富士通株式会社 仮想化管理プログラム、仮想化管理装置および仮想化管理方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6455035B2 (ja) * 2014-09-10 2019-01-23 富士通株式会社 負荷分散管理装置、制御方法およびプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018003031A1 (ja) 2016-06-29 2018-01-04 富士通株式会社 仮想化管理プログラム、仮想化管理装置および仮想化管理方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
叶如絵ほか,コンテナ型仮想化環境向き負荷予測システム「Tetris」の開発,情報処理学会第78回(平成28年)全国大会講演論文集(1) コンピュータシステム ソフトウェア科学・工学 データとウェブ,日本,一般社団法人情報処理学会,2016年03月10日,1-11~1-12ページ

Also Published As

Publication number Publication date
JP2020160775A (ja) 2020-10-01

Similar Documents

Publication Publication Date Title
JP7331407B2 (ja) コンテナ起動ホスト選択装置、コンテナ起動ホスト選択システム、コンテナ起動ホスト選択方法及びプログラム
US11032359B2 (en) Multi-priority service instance allocation within cloud computing platforms
US9378056B2 (en) Management server, and virtual machine move control method
EP2437168B1 (en) Method and device for balancing load of multiprocessor system
US8700752B2 (en) Optimized efficient LPAR capacity consolidation
JP6075226B2 (ja) プログラム、仮想マシン管理方法および情報処理装置
JP6233413B2 (ja) タスク割り当て判定装置、制御方法、及びプログラム
JP2011118525A (ja) サーバ管理装置とサーバ管理方法およびサーバ管理プログラム
US20110231860A1 (en) Load distribution system
JP5484601B2 (ja) 並列分散処理システムのデータ転送制御方法、並列分散処理システム及び記憶媒体
US10193973B2 (en) Optimal allocation of dynamically instantiated services among computation resources
JP2005234917A (ja) 障害時のサーバ決定方法
US9792142B2 (en) Information processing device and resource allocation method
US10496430B2 (en) Information processing system, autoscaling association apparatus, and non-transitory computer readable medium for determining a necessary number of virtual machines
US20170262196A1 (en) Load monitoring method and information processing apparatus
US20100251248A1 (en) Job processing method, computer-readable recording medium having stored job processing program and job processing system
US10684901B2 (en) Data store device and data management method
WO2013171944A1 (ja) 仮想マシン管理システム、仮想マシン管理方法およびプログラム
US20150074454A1 (en) Information processing method and apparatus for migration of virtual disk
US20170262310A1 (en) Method for executing and managing distributed processing, and control apparatus
US20210019160A1 (en) Quality of service scheduling with workload profiles
US9983911B2 (en) Analysis controller, analysis control method and computer-readable medium
JP6960444B2 (ja) 計算機システム及びリソース管理方法
JP6963465B2 (ja) 計算機システム及びデータ処理の制御方法
US11893417B2 (en) Process request management apparatus, process request management method and program

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220207

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20221227

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230117

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230316

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230711

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230724

R151 Written notification of patent or utility model registration

Ref document number: 7331407

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151