特開 2024-16940 情報処理装置および情報処理方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024016940

(43)【公開日】2024-02-08

(54)【発明の名称】情報処理装置および情報処理方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240201BHJP

   G06F 9/455 20180101ALI20240201BHJP

【ＦＩ】

G06F9/50 150A

G06F9/455 150

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2022119248

(22)【出願日】2022-07-27

(71)【出願人】

【識別番号】000005223

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

(74)【代理人】

【識別番号】110002918

【氏名又は名称】弁理士法人扶桑国際特許事務所

(72)【発明者】

【氏名】中原 紘平

(72)【発明者】

【氏名】伊與田 敏

(72)【発明者】

【氏名】道場 栄介

(57)【要約】

【課題】コンテナ起動時間を低減すること。
【解決手段】記憶部１１は、ノード２０，３０，４０それぞれが保持する、コンテナのイメージを示すキャッシュ情報１１ａを記憶する。処理部１２は、キャッシュ情報１１ａに基づいて、ノード２０により実行中であるコンテナ２２に対応するイメージ２１ａが記憶されていないノード３０，４０のうちリソースの空き容量が最も多いノード４０にイメージ４１ｂを格納する。イメージ４１ｂは、イメージ２１ａの複製である。処理部１２は、コンテナ２２のスケールアウトまたはコンテナ２２の障害に応じてコンテナ２２と同じコンテナ４３を起動させる場合、コンテナ２２が動作していないノードのうち、イメージ４１ｂを保持するノード４０によりコンテナ４３を起動させる。
【選択図】図１

【特許請求の範囲】

【請求項1】

複数のノードそれぞれが保持する、コンテナのイメージを示すキャッシュ情報を記憶する記憶部と、
前記キャッシュ情報に基づいて、前記複数のノードのうちの第１ノードにより実行中である第１コンテナに対応する第１イメージが記憶されていない、前記第１ノード以外のノードのうちリソースの空き容量が最も多い第２ノードに前記第１イメージの複製である第２イメージを格納し、前記第１コンテナのスケールアウトまたは前記第１コンテナの障害に応じて前記第１コンテナと同じ第２コンテナを起動させる場合、前記第１コンテナが動作していないノードのうち、前記第２イメージを保持する前記第２ノードにより前記第２コンテナを起動させる処理部と、
を有する情報処理装置。

【請求項2】

前記処理部は、前記第２コンテナを起動させる際に、前記キャッシュ情報に基づいて前記第２イメージを保持する前記第２ノードを優先して選択し、前記第２ノードにより前記第２コンテナを起動させる、
請求項１記載の情報処理装置。

【請求項3】

前記処理部は、前記複数のノードそれぞれの前記リソースの空き容量を、当該ノードで動作中のコンテナにより消費される第１リソース量と、当該ノードで未動作であるが当該ノードが保持するイメージから起動可能なコンテナの動作に所要される第２リソース量とに基づいて評価する、
請求項１記載の情報処理装置。

【請求項4】

前記処理部は、前記複数のノードそれぞれが保持する前記イメージの情報を定期的に収集し、前記キャッシュ情報を更新する、
請求項１記載の情報処理装置。

【請求項5】

前記処理部は、前記第１イメージから複製された前記第２イメージを前記第１ノードから前記第２ノードへ転送させることで、前記第２イメージを前記第２ノードに格納する、
請求項１記載の情報処理装置。

【請求項6】

前記処理部は、前記第２コンテナを起動させる際に、前記第２イメージを保持する前記第２ノードが複数ある場合、複数の前記第２ノードのうちリソースの空き容量が最も多い前記第２ノードにより前記第２コンテナを起動させる、
請求項１記載の情報処理装置。

【請求項7】

コンピュータが、
複数のノードそれぞれが保持するコンテナのイメージを示すキャッシュ情報に基づいて、前記複数のノードのうちの第１ノードにより実行中である第１コンテナに対応する第１イメージが記憶されていない、前記第１ノード以外のノードのうちリソースの空き容量が最も多い第２ノードに前記第１イメージの複製である第２イメージを格納し、
前記第１コンテナのスケールアウトまたは前記第１コンテナの障害に応じて前記第１コンテナと同じ第２コンテナを起動させる場合、前記第１コンテナが動作していないノードのうち、前記第２イメージを保持する前記第２ノードにより前記第２コンテナを起動させる、
情報処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は情報処理装置および情報処理方法に関する。

【背景技術】

【0002】

コンピュータにおける仮想化技術の１つにコンテナ型仮想化がある。コンテナ型仮想化では、アプリケーションの起動に用いるライブラリなどの資源を纏めたコンテナが、ソフトウェアの実行環境として定義される。コンテナの起動に用いられるデータは、コンテナイメージまたは単にイメージと言われる。例えば、コンピュータにより実現されるノードはコンテナエンジンを実行し、コンテナイメージからノード上にコンテナを起動することができる。ノードは、ＣＰＵ（Central Processing Unit）やＲＡＭ（Random Access Memory）などのリソースを有する物理マシンでもよいし、物理マシン上で動作する仮想マシンでもよい。

【0003】

例えば、スケールアウト対象となるコンテナである追加対象コンテナを起動するコンテナ管理装置の提案がある。提案のコンテナ管理装置は、既存のノードに追加対象コンテナを起動できるリソースがなければ、既存のノードで起動中のコンテナのうち停止させるコンテナを選択して当該コンテナを停止させ、既存のノードで追加対象コンテナを起動する。

【0004】

また、起動対象のコンテナを起動させた場合の各コンテナホストでの複数種類の負荷を予測し、それらの負荷が最も小さいコンテナホストを起動対象のコンテナを起動するホストとして決定するコンテナ起動ホスト選択装置の提案もある。

【0005】

更に、ローカルサイトのレジストリ装置およびリモートサイトのレジストリ装置それぞれにコンテナイメージを格納するコンテナ提供支援システムの提案もある。提案のコンテナ提供支援システムは、ローカルサイトにてコンテナの利用時に障害が発生した際、リモートサイトにおいてコンテナイメージから当該コンテナを起動して業務を継続する。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２０２０－１５４３９２号公報

【特許文献2】特開２０２０－１６０７７５号公報

【特許文献3】特開２０２０－９５５４７号公報

【発明の概要】

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

【0007】

スケールアウト時などの新たなコンテナの起動の際、ノードによるコンテナ起動用のイメージの取得に時間がかかり、コンテナ起動時間が長くなることがある。１つの側面では、本発明は、コンテナ起動時間を低減することを目的とする。

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

【0008】

１つの態様では、情報処理装置が提供される。情報処理装置は記憶部と処理部とを有する。記憶部は、複数のノードそれぞれが保持する、コンテナのイメージを示すキャッシュ情報を記憶する。処理部は、キャッシュ情報に基づいて、複数のノードのうちの第１ノードにより実行中である第１コンテナに対応する第１イメージが記憶されていない、第１ノード以外のノードのうちリソースの空き容量が最も多い第２ノードに第１イメージの複製である第２イメージを格納する。処理部は、第１コンテナのスケールアウトまたは第１コンテナの障害に応じて第１コンテナと同じ第２コンテナを起動させる場合、第１コンテナが動作していないノードのうち、第２イメージを保持する第２ノードにより第２コンテナを起動させる。

【0009】

また、１つの態様では、情報処理方法が提供される。

【発明の効果】

【0010】

１つの側面では、コンテナ起動時間を低減できる。

【図面の簡単な説明】

【0011】

【図1】第１の実施の形態の情報処理装置を説明する図である。

【図2】第２の実施の形態の情報処理システムの例を示す図である。

【図3】管理装置のハードウェア例を示す図である。

【図4】管理装置の機能例を示す図である。

【図5】リソースの空き容量指標値の計算例を示す図である。

【図6】コンテナ管理テーブルの例を示す図である。

【図7】キャッシュイメージテーブルの例を示す図である。

【図8】リソーステーブルの例を示す図である。

【図9】コンテナ起動時処理の例を示すフローチャートである。

【図10】スケールアウトまたは自動復旧時処理の例を示すフローチャートである。

【図11】イメージ配置およびコンテナ起動の例を示す図である。

【図12】第３の実施の形態のアプリ消費リソーステーブルの例を示す図である。

【図13】リソーステーブルの例を示す図である。

【図14】コンテナ起動時処理の例を示すフローチャートである。

【図15】スケールアウトまたは自動復旧時処理の例を示すフローチャートである。

【図16】イメージ配置の例を示す図である。

【図17】コンテナ起動の例を示す図である。

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

【0012】

以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態を説明する。

【0013】

図１は、第１の実施の形態の情報処理装置を説明する図である。
情報処理装置１０およびノード２０，３０，４０は、ネットワーク５０に接続される。ノード２０，３０，４０は、コンテナを実行する。コンテナの起動には、ノードが保持するコンテナイメージが用いられる。コンテナイメージは単にイメージと言われる。イメージは、例えば図示を省略しているコンテナレジストリ装置に集約して保持されてもよい。コンテナレジストリ装置は、ノード２０，３０，４０にイメージを提供し得る。

【0014】

また、ノード２０，３０，４０は、自ノードで動作するコンテナのイメージを保持する。ノード２０，３０，４０は、自ノードで現在は動作していないが過去に動作していたコンテナのイメージを削除せずに保持していることもある。ノード２０，３０，４０に保持されるイメージは、キャッシュイメージと言われることがある。

【0015】

情報処理装置１０は、記憶部１１および処理部１２を有する。記憶部１１は、ＲＡＭなどの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。処理部１２は、ＣＰＵ、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。処理部１２はプログラムを実行するプロセッサでもよい。「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。

【0016】

また、ノード２０，３０，４０は、それぞれ記憶部２１，３１，４１を有する。記憶部２１，３１，４１は、ＲＡＭやＨＤＤなどの記憶装置により実現される。記憶部２１，３１，４１はコンテナのイメージを記憶する。更に、図示を省略しているが、ノード２０，３０，４０はＣＰＵなどのプロセッサを有する。ノード２０，３０，４０それぞれのプロセッサは、コンテナエンジンを実行し、コンテナエンジンの機能により、自ノードの記憶部に保持されるイメージに基づいてコンテナを動作させる。コンテナエンジンはコンテナランタイムと言われてもよい。ノードが有するＣＰＵおよびＲＡＭなどのリソースの一部が、当該ノードで動作するコンテナに割り当てられる。なお、ノード２０，３０，４０は、プロセッサとＲＡＭとを有する物理マシンにより実現されてもよいし、物理マシン上で動作する仮想マシンにより実現されてもよい。ノード２０，３０，４０が仮想マシンにより実現される場合、物理マシンが備えるＣＰＵおよびＲＡＭなどリソースの一部が、当該ノードに割り当てられる。

【0017】

ここで、コンテナによりアプリケーションを提供することで、コンテナのスケールアウトや自動復旧によりアプリケーションの可用性を向上させることができる。アプリケーションの提供は、例えばネットワーク５０を介し、不図示のクライアントコンピュータに対して行われる。スケールアウトは、コンテナの負荷に応じて、同じイメージを基に動作するコンテナの数を増加させることで、複数のノードに負荷を分散させる技術である。自動復旧は、コンテナが動作するノードが異常停止した場合などに、別ノードによりコンテナを自動起動させることで復旧させる技術である。

【0018】

そこで、情報処理装置１０は、スケールアウトまたは自動復旧時における、ノード２０，３０，４０によるコンテナの起動の高速化を図る。以下の説明では、スケールアウトまたは自動復旧時における起動の高速化対象のコンテナに対応するアプリケーションを「Ａ」とする。例えば、スケールアウトまたは自動復旧時における起動の高速化対象とするコンテナまたは当該コンテナに対応するアプリケーション「Ａ」はユーザにより予め指定されてもよい。ただし、ノード２０，３０，４０で実行される全てのアプリケーションに対応するコンテナが、スケールアウトまたは自動復旧時における起動の高速化対象とされてもよい。

【0019】

記憶部１１は、キャッシュ情報１１ａおよびリソース情報１１ｂを記憶する。キャッシュ情報１１ａは、ノード２０，３０，４０それぞれが保持する、コンテナのイメージを示す情報である。リソース情報１１ｂは、ノード２０，３０，４０それぞれのリソースの空き容量指標値を示す情報である。図１におけるリソース情報１１ｂの「リソース空き容量」の記載は、空き容量指標値を示す。空き容量指標値は、ノード２０，３０，４０それぞれのＣＰＵおよびＲＡＭなどの空きリソースの量を示す指標値である。空き容量指標値は、例えば該当ノードの空きＣＰＵ数（ｎ）とＲＡＭの空き容量（ｍ）との線形結合（αｎ＋βｍ）により計算されてもよい。α，βは正の定数である。ＣＰＵ数は、例えばＣＰＵ１個のうちの１０％（例えば動作クロック周波数の１０％を０．１個とする）が最小単位とされる。空き容量指標値が大きい程、リソースの空き容量が多い。

【0020】

キャッシュ情報１１ａおよびリソース情報１１ｂは、処理部１２により生成され、記憶部１１に格納される。処理部１２は、所定のタイミングで、ノード２０，３０，４０それぞれが保持するイメージの情報や空きリソース量の情報を、ノード２０，３０，４０から収集し、キャッシュ情報１１ａおよびリソース情報１１ｂを生成する。なお、ノード２０，３０，４０それぞれの保有するＣＰＵ数やＲＡＭ容量が異なる場合、処理部１２は、空き容量指標値を、ノード２０，３０，４０全体のリソース量で正規化して求めてもよい。例えば、ノード２０，３０，４０のＣＰＵ数の総和をＮ、ノード２０，３０，４０のＲＡＭ容量の総和をＭとする。このとき、該当ノードの空き容量指標値は（α＊ｎ／Ｎ＋β＊ｍ／Ｍ）と計算されてもよい。また、所定のタイミングは、何れかのノードで特定のコンテナを起動したタイミングでもよいし、周期的なタイミングでもよい。特定のコンテナは、スケールアウトまたは自動復旧時の起動の高速化対象のコンテナである。

【0021】

ある時点で、ユーザの指示などに応じて、アプリケーション「Ａ」に対応するコンテナ２２が、ノード２０で新たに起動される。このとき、記憶部２１は、イメージ２１ａ，２１ｂを記憶する。イメージ２１ａは、コンテナ２２のイメージである。イメージ２１ａは、コンテナレジストリ装置から新たにダウンロードされたものでもよい。イメージ２１ｂは、コンテナ２３のイメージである。コンテナ２３は、ノード２０で既に動作中であるアプリケーション「Ｂ」のコンテナである。また、記憶部３１は、イメージ３１ａを記憶する。イメージ３１ａは、コンテナ３２のイメージである。コンテナ３２は、ノード３０で既に動作中であるアプリケーション「Ｃ」のコンテナである。更に、記憶部４１は、イメージ４１ａを記憶する。イメージ４１ａは、コンテナ４２のイメージである。コンテナ４２は、ノード４０で既に動作中であるアプリケーション「Ｄ」のコンテナである。

【0022】

ノード２０，３０，４０は、自ノードで動作するコンテナのイメージを保持する。この場合、例えばキャッシュ情報１１ａは、ノード２０にイメージ２１ａ，２１ｂが保持され、ノード３０にイメージ３１ａが保持され、ノード４０にイメージ４１ａが保持されることを示す。また、リソース情報１１ｂは、コンテナ２２がノード２０で起動された時点におけるノード２０，３０，４０それぞれの空き容量指標値Ｒ１，Ｒ２，Ｒ３を示す。Ｒ３はＲ２より大きい（Ｒ３＞Ｒ２）と仮定する。

【0023】

処理部１２は、キャッシュ情報１１ａに基づいて、ノード２０により実行中であるコンテナ２２に対応するイメージ２１ａが記憶されていない、ノード２０以外のノード３０，４０を特定する。

【0024】

処理部１２は、ノード３０，４０のうちリソースの空き容量が最も多いノード４０にイメージ２１ａの複製であるイメージ４１ｂを格納する。イメージ４１ｂは、イメージ２１ａと同様に、アプリケーション「Ａ」に対応するコンテナのイメージである。処理部１２は、ノード２０により、イメージ２１ａからイメージ４１ｂを生成させ、ノード２０からノード４０へネットワーク５０を介してイメージ４１ｂを転送させてもよい。あるいは、処理部１２は、前述のコンテナレジストリ装置からイメージ２１ａと同じイメージ４１ｂを取得し、ノード４０に送信してもよい。更に別の例では、処理部１２は、ノード４０により、コンテナレジストリ装置からイメージ４１ｂを取得させてもよい。コンテナレジストリ装置から取得されるイメージ４１ｂも、イメージ２１ａの複製であると言うことができる。こうして、記憶部４１にイメージ４１ｂが予備的に格納される。この時点では、ノード４０は、予備のイメージ４１ｂに対応するコンテナを起動しないが、イメージ４１ｂを記憶部４１に保持したままとする。

【0025】

その後、処理部１２は、コンテナ２２のスケールアウトまたはコンテナ２２の障害に応じてコンテナ２２と同じコンテナを起動させることを決定する。この場合に、処理部１２は、コンテナ２２が動作していないノード３０，４０のうち、イメージ４１ｂを保持するノード４０によりコンテナ４３を起動させる。コンテナ４３は、コンテナ２２と同様に、アプリケーション「Ａ」に対応するコンテナである。コンテナ２２のスケールアウトは、コンテナ２２に対するアクセス負荷の増大に応じて行われる。コンテナ２２の障害は、コンテナ２２が異常停止したり、通信不能に陥ったりした状態である。コンテナ２２の障害は、例えばノード２０の一部または全部の機能の異常停止に起因する。

【0026】

ノード４０は、コンテナ４３の起動の際、自ノードの記憶部４１に予め格納されたイメージ４１ｂを使用可能である。このため、ノード４０は、コンテナ４３の起動のために、コンテナレジストリ装置などの他の装置から、イメージ４１ｂを取得しなくてよい。

【0027】

情報処理装置１０によれば、複数のノードそれぞれが保持する、コンテナのイメージを示すキャッシュ情報１１ａが取得される。キャッシュ情報１１ａに基づいて、複数のノードのうちの第１ノードにより実行中である第１コンテナに対応する第１イメージが記憶されていない、第１ノード以外のノードが特定される。特定されたノードのうちリソースの空き容量が最も多い第２ノードに第１イメージの複製である第２イメージが格納される。第１コンテナのスケールアウトまたは第１コンテナの障害に応じて第１コンテナと同じ第２コンテナを起動させる場合、第１コンテナが動作していないノードのうち、第２イメージを保持する第２ノードにより第２コンテナを起動させる。これにより、情報処理装置１０は、コンテナの起動に要する時間、すなわち、コンテナ起動時間を低減できる。

【0028】

ここで、あるノードでコンテナを起動する際に、当該ノードが起動対象のコンテナのイメージを保持していない場合、当該ノードは、コンテナレジストリ装置などからイメージを取得することになる。この場合、イメージの取得に要する時間がコンテナ起動時間に加算される。このため、コンテナ起動時間が長くなる。

【0029】

一方、情報処理装置１０によれば、ノード４０の記憶部４１には、イメージ２１ａと同じイメージ４１ｂが予め格納される。このため、ノード４０は、コンテナ４３を起動する際、記憶部４１に格納されているイメージ４１ｂを使用可能である。したがって、ノード４０は、コンテナ４３の起動のために、コンテナレジストリ装置などの他の装置から、イメージ４１ｂを取得しなくてよい。よって、ノード４０においてイメージ４１ｂの取得に要する時間が削減される。こうして、情報処理装置１０は、コンテナ２２のスケールアウトまたは自動復旧時において、コンテナ４３の起動時間を低減できる。その結果、情報処理装置１０は、コンテナ２２，４３により提供されるアプリケーション「Ａ」の可用性を一層向上できる。

【0030】

また、情報処理装置１０は、イメージ２１ａと同じイメージを保持していないノード３０，４０のうち、リソースの空き容量が最も多いノード４０を、イメージ４１ｂの格納先とする。リソースの空き容量が最も多いノード４０は、他のノード（ノード３０）よりもコンテナ４３の起動時に、コンテナ４３に割り当てるリソースを適切に確保できる可能性が高い。仮にコンテナ４３に割り当てるリソースを確保できない場合、他のノードでコンテナ４３を起動することになり、そのために他のノードでコンテナ４３のイメージを取得するなどの余計なオーバーヘッドが生じる。そこで、情報処理装置１０は、リソースの空き容量が最も多いノード４０を、イメージ４１ｂの格納先とすることで、余計なオーバーヘッドが生じる可能性を減らせ、コンテナ４３の起動の円滑化を図れる。また、情報処理装置１０は、リソースの空き容量が最も多いノード４０を、イメージ４１ｂの格納先とし、当該ノード４０でコンテナ４３を起動させることで、ノード３０，４０の負荷が偏らないように適切な負荷分散を図れる利点もある。

【0031】

以下では、より具体的な例により、情報処理装置１０の機能を更に詳細に説明する。
［第２の実施の形態］
次に、第２の実施の形態を説明する。

【0032】

図２は、第２の実施の形態の情報処理システムの例を示す図である。
第２の実施の形態の情報処理システムは、管理装置１００およびノード２００，２００ａ，２００ｂ，…（以降、ノード２００，２００ａ，２００ｂ，…の任意のノードをノード２００ｎということがある）を有する。管理装置１００およびノード２００ｎは、ネットワーク６０に接続される。ネットワーク６０は、例えばＬＡＮ（Local Area Network）である。ネットワーク６０には、コンテナレジストリ７０および端末装置８０が接続される。コンテナレジストリ７０および端末装置８０は、インターネットやＷＡＮ（Wide Area Network）を介して、ネットワーク６０に接続されてもよい。

【0033】

第２の実施の形態の情報処理システムは、ノード２００ｎによりコンテナを実行する。コンテナ上のアプリケーションは、端末装置８０により利用される。当該アプリケーションを利用する端末装置８０は、複数存在し得る。

【0034】

コンテナレジストリ７０は、コンテナのイメージを集約して保持するサーバである。コンテナレジストリ７０には、複数のアプリケーションに対応する複数のイメージが予め登録される。コンテナレジストリ７０は、ノード２００ｎにイメージを提供する。

【0035】

端末装置８０は、ユーザにより操作されるクライアントである。端末装置８０は、コンテナ上のアプリケーションにリクエストを送信し、当該リクエストに対する処理結果を受信する。

【0036】

管理装置１００は、ノード２００ｎによるコンテナの実行を管理するサーバである。管理装置１００は、端末装置８０を介してユーザにより指示されたコンテナの起動をノード２００ｎに指示する。また、管理装置１００は、ノード２００ｎを監視し、コンテナのスケールアウトや自動復旧時におけるコンテナの起動を制御する。管理装置１００は、第１の実施の形態の情報処理装置１０の一例である。

【0037】

ノード２００ｎは、コンテナを実行するサーバである。ノード２００ｎは、コンテナランタイムを実行する。ノード２００ｎは、コンテナランタイムの機能により、自ノードが保持するイメージからコンテナを起動する。管理装置１００による管理対象のノードのグループは、クラスタと言われる。

【0038】

図３は、管理装置のハードウェア例を示す図である。
管理装置１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、ＧＰＵ（Graphics Processing Unit）１０４、入力インタフェース１０５、媒体リーダ１０６およびＮＩＣ（Network Interface Card）１０７を有する。なお、ＣＰＵ１０１は、第１の実施の形態の処理部１２の一例である。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１の一例である。

【0039】

ＣＰＵ１０１は、プログラムの命令を実行するプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、ＣＰＵ１０１は複数のプロセッサコアを含んでもよい。また、管理装置１００は複数のプロセッサを有してもよい。以下で説明する処理は複数のプロセッサまたはプロセッサコアを用いて並列に実行されてもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。

【0040】

ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、管理装置１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。

【0041】

ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、管理装置１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。

【0042】

ＧＰＵ１０４は、ＣＰＵ１０１からの命令に従って、管理装置１００に接続されたディスプレイ６１に画像を出力する。ディスプレイ６１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなど、任意の種類のディスプレイを用いることができる。

【0043】

入力インタフェース１０５は、管理装置１００に接続された入力デバイス６２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス６２としては、マウス、タッチパネル、タッチパッド、トラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、管理装置１００に、複数の種類の入力デバイスが接続されていてもよい。

【0044】

媒体リーダ１０６は、記録媒体６３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体６３として、例えば、磁気ディスク、光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤが含まれる。光ディスクには、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）が含まれる。

【0045】

媒体リーダ１０６は、例えば、記録媒体６３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、ＣＰＵ１０１によって実行される。なお、記録媒体６３は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体６３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。

【0046】

ＮＩＣ１０７は、ネットワーク６０に接続され、ネットワーク６０を介して他のコンピュータと通信を行うインタフェースである。ＮＩＣ１０７は、例えば、スイッチやルータなどの通信装置とケーブルで接続される。ＮＩＣ１０７は、無線通信インタフェースでもよい。

【0047】

ノード２００ｎ、コンテナレジストリ７０および端末装置８０は、管理装置１００と同様のハードウェアにより実現される。
図４は、管理装置の機能例を示す図である。

【0048】

管理装置１００は、記憶部１１０および制御部１２０を有する。記憶部１１０には、ＲＡＭ１０２やＨＤＤ１０３の記憶領域が用いられる。制御部１２０は、ＲＡＭ１０２に記憶されたプログラムがＣＰＵ１０１により実行されることで実現される。

【0049】

記憶部１１０は、制御部１２０の処理に用いられる情報を記憶する。具体的には、記憶部１１０は、コンテナ管理テーブル、キャッシュイメージテーブルおよびリソーステーブルを記憶する。コンテナ管理テーブルは、ノード２００ｎで動作中のコンテナに関する情報である。キャッシュイメージテーブルは、ノード２００ｎが保持するコンテナのイメージに関する情報である。リソーステーブルは、ノード２００ｎのリソースに関する情報である。ここで、リソースは、ノード２００ｎが有するＣＰＵおよびＲＡＭ（メモリ）である。

【0050】

制御部１２０は、ノード２００ｎによるコンテナの実行を制御する。また、制御部１２０は、あるコンテナについて、スケールアウトや自動復旧時に当該コンテナと同じコンテナを他ノードで起動させるために、当該コンテナに対応する予備のイメージを他ノードへ予め配置する。制御部１２０は、ノード監視部１２１、イメージ配置制御部１２２およびコンテナ起動制御部１２３を有する。

【0051】

ノード監視部１２１は、ノード２００ｎを監視する。ノード監視部１２１は、ノード２００ｎで動作中のコンテナの情報を収集し、コンテナ管理テーブルに記録する。ノード監視部１２１は、ノード２００ｎが保持するコンテナのイメージの情報を収集し、キャッシュイメージテーブルに記録する。ノード監視部１２１は、ノード２００ｎが有するリソースの情報を収集し、リソーステーブルに記録する。ノード監視部１２１は、周期的なタイミングまたは新たなコンテナを起動するタイミングで、これらの情報をノード２００ｎから収集する。

【0052】

また、ノード監視部１２１は、ノード２００ｎの負荷に応じたコンテナのスケールアウトの実行要否や、コンテナの障害に応じた自動復旧の実行要否を判断する。ノード監視部１２１は、スケールアウトや自動復旧の実行が必要であると判断すると、該当のコンテナの起動をコンテナ起動制御部１２３に指示する。

【0053】

イメージ配置制御部１２２は、ノード２００ｎに対する予備のイメージの配置を制御する。具体的には、イメージ配置制御部１２２は、記憶部１１０に記憶されたコンテナ管理テーブルおよびキャッシュイメージテーブルに基づいて、予備のイメージの配置対象のコンテナのイメージを保持していないノードを特定する。

【0054】

イメージ配置制御部１２２は、コンテナ管理テーブルおよびリソーステーブルに基づいて、特定したノードのうちリソースの空き容量が最も多いノードを予備のイメージの配置先に決定する。このとき、イメージ配置制御部１２２は、各ノードの空き容量指標値を評価する。空き容量指標値の計算方法は後述される。イメージ配置制御部１２２は、決定した配置先ノードに予備のイメージを格納する。この段階では、配置先ノードでは予備のイメージからのコンテナの起動は行われない。

【0055】

コンテナ起動制御部１２３は、ノード２００ｎによるコンテナの起動を制御する。コンテナ起動制御部１２３は、端末装置８０からコンテナの起動指示を受け付ける。すると、コンテナ起動制御部１２３は、ノード監視部１２１により収集された情報に基づいて、各ノードの空き容量指標値を計算する。例えば、コンテナ起動制御部１２３は、各ノードの空き容量指標値に基づいて、リソースの空き容量が最も多いノードによりコンテナを起動させる。

【0056】

また、コンテナ起動制御部１２３は、ノード監視部１２１から、スケールアウトや自動復旧に応じたコンテナの起動指示を受け付けることもある。すると、コンテナ起動制御部１２３は、ノード監視部１２１により収集された情報に基づいて計算される各ノードの空き容量指標値に基づいて、リソースの空き容量が最も多いノードによりコンテナを起動させる。

【0057】

図５は、リソースの空き容量指標値の計算例を示す図である。
空き容量指標値は、各ノードのＣＰＵ数およびメモリ容量の空きをそれぞれクラスタ内のＣＰＵ数の総和およびメモリ容量の総和で正規化して加算した値である。ＣＰＵ数は、例えばＣＰＵ１個の１０％（例えば、動作クロック周波数の１０％を０．１個とする）が最小単位とされる。１ＣＰＵ当たりのスペックは各ノードで同じとする。各ノードが保有するＣＰＵ数は異なってもよい。

【0058】

クラスタ内のノードのＣＰＵ数の総和をＮ、クラスタ内のノードのメモリ容量の総和をＭとする。このとき、利用可能ＣＰＵ数ｎかつ利用可能メモリ容量ｍのノードの空き容量指標値は（α＊ｎ／Ｎ＋β＊ｍ／Ｍ）と計算される。α，βは、ＣＰＵ数およびメモリ容量に対する重みであり、予め定められる正の実数である。本例ではα＝β＝１とする。また、利用可能ＣＰＵ数は、空きＣＰＵ数と言われてもよい。また、利用可能メモリ容量は、空きメモリ容量と言われてもよい。更に、利用可能ＣＰＵ数は、ノードの（保有ＣＰＵ数－消費ＣＰＵ数）により計算される。利用可能メモリ容量は、ノードの（保有メモリ容量－消費メモリ容量）により計算される。

【0059】

ここで、図５では、一例として、クラスタに属するノードが、ノード２００ｄ，２００ｅ，２００ｆと仮定した場合のノード２００ｄ，２００ｅ，２００ｆそれぞれの空き容量指標値の計算例を示す。ノード２００ｄの保有ＣＰＵ数は４であり、保有メモリ容量は８ＧＢ（Giga Bytes）である。ノード２００ｅの保有ＣＰＵ数は６であり、保有メモリ容量は１２ＧＢである。ノード２００ｆの保有ＣＰＵ数は２であり、保有メモリ容量は４ＧＢである。この場合、Ｎ＝１２であり、Ｍ＝２４ＧＢである。

【0060】

図５（Ａ）は、ノード２００ｄに対する空き容量指標値の計算例を示す。ノード２００ｄにおいて、利用可能ＣＰＵ数ｎ＝２．２であり、利用可能メモリ容量ｍ＝４．５ＧＢであるとする。この場合、ノード２００ｄの空き容量指標値は、２．２／１２＋４．５ＧＢ／２４ＧＢ≒０．３７である。

【0061】

図５（Ｂ）は、ノード２００ｅに対する空き容量指標値の計算例を示す。ノード２００ｅにおいて、利用可能ＣＰＵ数ｎ＝４．８であり、利用可能メモリ容量ｍ＝９．５ＧＢであるとする。この場合、ノード２００ｅの空き容量指標値は、４．８／１２＋９．５ＧＢ／２４ＧＢ≒０．８０である。

【0062】

図５（Ｃ）は、ノード２００ｆに対する空き容量指標値の計算例を示す。ノード２００ｆにおいて、利用可能ＣＰＵｎ＝０．５であり、利用可能メモリ容量ｍ＝１．５ＧＢであるとする。この場合、ノード２００ｆの空き容量指標値は、０．５／１２＋１．５ＧＢ／２４ＧＢ≒０．１０である。

【0063】

図５の例の場合、リソースの空き容量が最も多いノードは、空き容量指標値の最も大きいノード２００ｅである。こうして、イメージ配置制御部１２２およびコンテナ起動制御部１２３は、各ノードの空き容量指標値に基づいて、リソースの空き容量が最も多いノードを特定する。

【0064】

図６は、コンテナ管理テーブルの例を示す図である。
コンテナ管理テーブル１１１は、記憶部１１０に記憶される。コンテナ管理テーブル１１１には、各ノードで動作中のコンテナの情報が登録される。コンテナ管理テーブル１１１は、ノード名、コンテナ名、イメージ名：版数、消費ＣＰＵ数および消費メモリ容量の項目を含む。

【0065】

ノード名の項目には、ノード名が登録される。ノード名はノードの識別情報である。コンテナ名の項目には、該当のノードで動作中であるコンテナのコンテナ名が登録される。コンテナ名はコンテナの識別情報である。イメージ名：版数の項目には、当該コンテナの起動に用いられたイメージのイメージ名と版数との組が登録される。イメージ名と版数との組は、イメージの識別情報である。消費ＣＰＵ数の項目には、当該コンテナにより消費されるＣＰＵ数が登録される。消費メモリ容量の項目には、当該コンテナにより消費されるメモリ容量が登録される。メモリ容量の単位は例えばＧＢである。

【0066】

ここで、ノード２００のノード名を「ｎｏｄｅ０１」とする。ノード２００ａのノード名を「ｎｏｄｅ０２」とする。ノード２００ｂのノード名を「ｎｏｄｅ０３」とする。
例えば、コンテナ管理テーブル１１１は、ノード名「ｎｏｄｅ０１」、コンテナ名「ａｐｐ０１－０１」、イメージ名「ａｐｐ０１：２．１」、消費ＣＰＵ数「０．５」、消費メモリ容量「１」のレコードを有する。このレコードは、ノード２００でコンテナ名「ａｐｐ０１－０１」のコンテナが動作しており、当該コンテナにより使用されるＣＰＵ数が０．５個、使用されるメモリ容量が１ＧＢであることを示す。また、コンテナ名「ａｐｐ０１－０１」のコンテナに対応するイメージのイメージ名：版数が「ａｐｐ０１：２．１」であることを示す。イメージ名：版数の「ａｐｐ０１：２．１」の表記は、イメージ名が「ａｐｐ０１」であり、版数が「２．１」である。このように、コンテナのイメージは、イメージ名と版数との組により識別される。

【0067】

コンテナ管理テーブル１１１には、動作中の他のコンテナに関するレコードも登録されている。
図７は、キャッシュイメージテーブルの例を示す図である。

【0068】

キャッシュイメージテーブル１１２は、記憶部１１０に格納される。キャッシュイメージテーブル１１２には、各ノードが保持するイメージの情報が登録される。キャッシュイメージテーブル１１２は、ノード名およびイメージ名：版数の項目を含む。ノード名の項目には、ノード名が登録される。イメージ名：版数の項目には、イメージ名：版数が登録される。

【0069】

例えば、キャッシュイメージテーブル１１２は、ノード名「ｎｏｄｅ０１」、イメージ名：版数「ａｐｐ０１：２．１」のレコードを有する。このレコードは、ノード２００がイメージ名：版数「ａｐｐ０１：２．１」で識別されるイメージを保持していることを示す。キャッシュイメージテーブル１１２には、各ノードが保持するイメージを示す複数のレコードが登録される。

【0070】

図８は、リソーステーブルの例を示す図である。
リソーステーブル１１３は、記憶部１１０に格納される。リソーステーブル１１３には、各ノードのリソースの情報が登録される。リソーステーブル１１３は、ノード名、ＣＰＵ数、使用中のＣＰＵ数、メモリ容量、使用中のメモリ容量および空き容量指標値の項目を含む。

【0071】

ノード名の項目には、ノード名が登録される。ＣＰＵ数の項目には、当該ノード名で識別されるノードが保有するＣＰＵ数が登録される。使用中のＣＰＵ数の項目には、当該ノードで使用中のＣＰＵ数が登録される。メモリ容量の項目には、当該ノードが保有するメモリ容量が登録される。メモリ容量の単位は例えばＧＢである。使用中のメモリ容量の項目には、当該ノードで使用中のメモリ容量が登録される。空き容量指標値の項目には、当該ノードに対して評価された空き容量指標値が登録される。

【0072】

例えば、リソーステーブル１１３は、ノード名「ｎｏｄｅ０１」、ＣＰＵ数「４」、使用中のＣＰＵ数「１．５」、メモリ容量「６」、使用中のメモリ容量「３」、空き容量指標値「０．４」のレコードを有する。このレコードは、ノード２００が保有するＣＰＵ数が４個、メモリ容量が６ＧＢであり、そのうち使用中のＣＰＵ数が１．５個、メモリ容量が３ＧＢであること、および、ノード２００の空き容量指標値が０．４であることを示す。

【0073】

ここで、リソーステーブル１１３では、一例として、クラスタ内のノードがノード２００，２００ａ，２００ｂのみであると仮定したときの空き容量指標値の例が示されている。リソーステーブル１１３の例では、ＣＰＵ数の総和Ｎ＝４＋２＋４＝１０であり、メモリ容量の総和Ｍ＝６＋６＋８＝２０ＧＢである。

【0074】

したがって、ノード名「ｎｏｄｅ０１」のノード２００の空き容量指標値は（４－１．５）／１０＋（６－３）／２０＝０．４である。ノード名「ｎｏｄｅ０２」のノード２００ａの空き容量指標値は（２－０．５）／１０＋（６－１）／２０＝０．４である。ノード名「ｎｏｄｅ０３」のノード２００ｂの空き容量指標値は（４－１）／１０＋（８－２）／２０＝０．６である。

【0075】

次に、管理装置１００の処理手順を説明する。
図９は、コンテナ起動時処理の例を示すフローチャートである。
コンテナ起動時処理は、新たなアプリケーションの配置のために新たなコンテナが起動されるタイミングや、スケールアウトや自動復旧のためのコンテナが起動されるタイミングで実行される。

【0076】

（Ｓ１０）コンテナ起動制御部１２３は、クラスタ内の何れかのノードでコンテナを起動させる。
（Ｓ１１）ノード監視部１２１は、クラスタ内の各ノードのコンテナとキャッシュイメージに関する情報を、各ノードから収集し、コンテナ管理テーブル１１１およびキャッシュイメージテーブル１１２に登録する。

【0077】

（Ｓ１２）イメージ配置制御部１２２は、該当のコンテナ、すなわち、ステップＳ１０で起動したコンテナが動作しておらず、かつ、該当のコンテナのキャッシュイメージをもつノードが存在するか否かを判定する。該当のコンテナで起動したコンテナが動作しておらず、かつ、該当のコンテナのキャッシュイメージをもつノードが存在する場合、コンテナ起動時処理が終了する。該当のコンテナで起動したコンテナが動作しておらず、かつ、該当のコンテナのキャッシュイメージをもつノードが存在しない場合、ステップＳ１３に処理が進む。イメージ配置制御部１２２は、コンテナ管理テーブル１１１およびキャッシュイメージテーブル１１２に基づいて、ステップＳ１２の判定を行う。

【0078】

（Ｓ１３）ノード監視部１２１は、各ノードのリソースに関する情報を収集し、リソーステーブル１１３に登録する。ステップＳ１３の段階では、リソーステーブル１１３の各レコードにおける空き容量指標値は未登録である。なお、ノード監視部１２１は、ステップＳ１５の処理のために、各ノードにおいて使用可能なディスク容量（すなわち、ＨＤＤやＳＳＤなどの補助記憶装置の使用可能な容量）の情報も収集し、記憶部１１０に格納する。

【0079】

（Ｓ１４）イメージ配置制御部１２２は、リソーステーブル１１３に基づいて、各ノードの空き容量指標値を算出し、リソーステーブル１１３に登録する。
（Ｓ１５）イメージ配置制御部１２２は、該当のコンテナが動作しておらず、かつ、該当のコンテナに必要なリソース容量が使用可能、かつ、使用可能なディスク容量が閾値よりも大きいノードを抽出する。ここで、イメージ配置制御部１２２は、該当のコンテナに必要なリソース容量が使用可能なノードをコンテナ管理テーブル１１１およびリソーステーブル１１３に基づいて抽出する。また、イメージ配置制御部１２２は、ステップＳ１３で収集された各ノードの使用可能なディスク容量の情報に基づいて、使用可能なディスク容量が閾値よりも大きいノードを抽出する。ここで、閾値は、該当のコンテナのキャッシュイメージのサイズである。

【0080】

（Ｓ１６）イメージ配置制御部１２２は、ステップＳ１５で抽出したノードの中から空き容量指標値が最大のノードを、ステップＳ１０で起動したコンテナに対応するキャッシュイメージの転送先に決定する。

【0081】

（Ｓ１７）イメージ配置制御部１２２は、決定した転送先のノードに、該当のキャッシュイメージを転送する。例えば、イメージ配置制御部１２２は、ステップＳ１０で該当のコンテナを起動したノード（転送元ノード）から、転送先のノードに、キャッシュイメージを転送するように指示し、転送元ノードによりキャッシュイメージを転送させてもよい。また、イメージ配置制御部１２２は、コンテナレジストリ７０から該当のキャッシュイメージを取得して、転送先のノードに転送してもよい。あるいは、イメージ配置制御部１２２は、コンテナレジストリ７０から該当のキャッシュイメージをダウンロードするように転送先のノードに指示し、転送先のノードにより該当のキャッシュイメージをダウンロードさせてもよい。こうして、転送先のノードにキャッシュイメージが予備的に格納される。そして、コンテナ起動時処理が終了する。

【0082】

なお、ノード監視部１２１は、ステップＳ１１，Ｓ１３の情報の収集およびテーブル更新を所定の周期で定期的に行ってもよい。その場合、制御部１２０は、ステップＳ１１，Ｓ１３をスキップすることで、コンテナ起動時処理の高速化を図ってもよい。

【0083】

次に、スケールアウトまたは自動復旧時における処理手順を説明する。
図１０は、スケールアウトまたは自動復旧時処理の例を示すフローチャートである。
スケールアウトまたは自動復旧時処理は、ノード監視部１２１が各ノードの監視に応じて、あるコンテナについてスケールアウトまたは自動復旧を行うと判断した際に起動される。

【0084】

（Ｓ２０）ノード監視部１２１は、各ノードのリソースに関する情報を収集し、リソーステーブル１１３に登録する。ステップＳ２０の段階では、リソーステーブル１１３の各レコードにおける空き容量指標値は未登録である。このとき、ノード監視部１２１は、各ノードで動作するコンテナや各ノードで保持されるイメージの情報も収集して、コンテナ管理テーブル１１１およびキャッシュイメージテーブル１１２を最新の状態に更新してもよい。

【0085】

（Ｓ２１）コンテナ起動制御部１２３は、リソーステーブル１１３に基づいて、各ノードの空き容量指標値を算出し、リソーステーブル１１３に登録する。
（Ｓ２２）コンテナ起動制御部１２３は、該当のコンテナが動作しておらず、かつ、該当のコンテナに必要なリソース容量が使用可能であるノードを抽出する。ここで、コンテナ起動制御部１２３は、該当のコンテナに必要なリソース容量が使用可能なノードをコンテナ管理テーブル１１１およびリソーステーブル１１３に基づいて抽出する。

【0086】

（Ｓ２３）コンテナ起動制御部１２３は、ステップＳ２２で抽出したノードの中から空き容量指標値が最大のノードをコンテナの起動先に決定する。
（Ｓ２４）コンテナ起動制御部１２３は、起動先に決定したノードにより該当のコンテナを起動させる。起動先のノードが起動対象のコンテナのキャッシュイメージを保持している場合、当該ノードは自ノードに保持されるキャッシュイメージから当該コンテナを起動することができる。そして、スケールアウトまたは自動復旧時処理が終了する。

【0087】

なお、ノード監視部１２１は、ステップＳ２０の情報の収集およびテーブル更新を、所定の周期で定期的に行ってもよい。その場合、制御部１２０は、ステップＳ２０をスキップすることで、スケールアウトまたは自動復旧時処理の高速化を図ってもよい。

【0088】

次に、管理装置１００によるイメージ配置およびコンテナ起動の流れを説明する。
図１１は、イメージ配置およびコンテナ起動の例を示す図である。
図１１の例では、ノード２００，２００ａ，２００ｂ，２００ｃがクラスタに属するものとする。ノード２００，２００ａ，２００ｂ，２００ｃは、それぞれコンテナランタイム２１０，２１０ａ，２１０ｂ，２１０ｃを実行し、コンテナランタイム２１０，２１０ａ，２１０ｂ，２１０ｃ上でコンテナを動作させる。

【0089】

まず、管理装置１００は、ノード２００，２００ａにおいて、それぞれ新たなコンテナ２１１，２１１ａを起動させる。コンテナ２１１，２１１ａは、何れもアプリケーション「Ａ」のコンテナである。このとき、ノード２００はイメージＡを保持する。イメージＡは、アプリケーション「Ａ」に対応するイメージであることを示す。イメージＡは、コンテナ２１１の起動元のイメージである。また、ノード２００ａは、イメージＡ，Ｂを保持する。イメージＡは、コンテナ２１１ａの起動元のイメージである。

【0090】

また、ノード２００ｂは、イメージＣを保持する。イメージＣは、ノード２００ｂで動作中のコンテナ２１１ｂの起動元のイメージである。更に、ノード２００ｃは、イメージＥ，Ｄを有する。イメージＥ，Ｄは、コンテナ２１１ｃを含む、ノード２００ｃで動作中のコンテナの起動元のイメージである。

【0091】

すると、管理装置１００は、ノード２００～２００ｃからキャッシュイメージに関する情報の収集（キャッシュ情報収集）を行い、キャッシュイメージテーブル１１２に記録する（ステップＳＴ１０）。このとき、管理装置１００は、ノード２００～２００ｃから、動作中のコンテナやリソースに関する情報の収集も行い、コンテナ管理テーブル１１１およびリソーステーブル１１３に記録する。

【0092】

次に、管理装置１００は、ノード２００～２００ｃそれぞれのリソースの空き容量指標値に基づいて、イメージＡを保持していないノード２００ｂ，２００ｃのうち、空き容量指標値が最大であるノード２００ｂに、イメージＡを転送させる（ステップＳＴ１１）。例えば、管理装置１００は、ノード２００，２００ａのうちの任意のノード（例えば、ノード２００ａ）からノード２００ｂへイメージＡを複製して転送させることで、ノード２００ｂにイメージＡを格納する。なお、管理装置１００は、ノード２００，２００ａのうちの負荷が小さい方のノードにより、ノード２００ｂへのイメージＡの転送を実行させてもよい。

【0093】

ここで、各ノードは同一ＬＡＮに接続されることが多い。一方、コンテナレジストリ７０は、インターネット上など、各ノードとは異なるネットワークに存在する場合もある。この場合、管理装置１００は、ノード間でイメージを転送させる方が、コンテナレジストリ７０からイメージをダウンロードするよりも、転送先のノードに高速にイメージを転送できる。

【0094】

そして、管理装置１００は、アプリケーション「Ａ」のコンテナ２１１，２１１ａに対する負荷が高まり、スケールアウトを実行すると判定する。すると、管理装置１００は、ノード２００～２００ｃそれぞれのリソースの空き容量指標値を評価する。そして、管理装置１００は、イメージＡを保持していないノード２００ｂ，２００ｃのうち、空き容量指標値が最大であるノード２００ｂにおいて、アプリケーション「Ａ」のコンテナ２１２ｂを起動させる（ステップＳＴ１２）。

【0095】

なお、ステップＳＴ１２は、自動復旧の場合も同様である。例えば、管理装置１００は、コンテナ２１１，２１１ａの少なくとも何れかにおける障害を検知したときに、自動復旧の処理として、ステップＳＴ１２を実行してもよい。

【0096】

ステップＳＴ１２のタイミングにおいて、ノード２００ｂは、イメージＡを既に保持している。このため、ノード２００ｂは、コンテナレジストリ７０から新たにイメージＡを取得しなくてよい。こうして、管理装置１００は、ノード２００ｂにおけるコンテナ２１２ｂの起動時間を低減できる。また、ノード２００ｂにおけるコンテナ２１２ｂの起動が高速化される。その結果、管理装置１００は、コンテナ２１１，２１１ａ，２１２ｂにより提供されるアプリケーション「Ａ」の可用性を一層向上できる。

【0097】

また、管理装置１００は、イメージＡを保持していないノード２００ｂ，２００ｃのうち、リソースの空き容量が最も多いノード２００ｂを、予備のイメージＡの格納先とする。リソースの空き容量が最も多いノード２００ｂは、他のノード（ノード２００ｃ）よりも新たなコンテナの起動時に、当該コンテナに割り当てるリソースを適切に確保できる可能性が高い。仮に、新たなコンテナに割り当てるリソースを確保できない場合、他のノードでコンテナを起動することになり、そのための余計なオーバーヘッドが生じる。そこで、管理装置１００は、リソースの空き容量が最も多いノードを、予備のイメージの格納先とすることで、余計なオーバーヘッドが生じる可能性を減らせ、スケールアウトや自動復旧時のコンテナの起動の円滑化を図れる。また、管理装置１００は、リソースの空き容量が最も多いノードを、予備のイメージの格納先とし、当該ノードでコンテナを起動させることで、各ノードの負荷が偏らないように適切な負荷分散を図れる利点もある。

【0098】

［第３の実施の形態］
次に第３の実施の形態を説明する。前述の第２の実施の形態と相違する事項を主に説明し、共通する事項の説明を省略する。

【0099】

第３の実施の形態では、管理装置１００は、スケールアウトまたは自動復旧時におけるコンテナ起動の際、当該コンテナの予備のイメージを配置したノードにより優先的にコンテナを起動させる機能を提供する。

【0100】

ただし、予備のイメージを配置したノードで優先してコンテナを起動する場合、イメージを多く保持するノードにコンテナが集中し易くなり、当該ノードでリソースが枯渇する可能性が高まる。そこで、第３の実施の形態では、管理装置１００は、イメージ配置制御における各ノードの空き容量指標値の計算に、各ノードで動作していないが、各ノードで動作する可能性のあるコンテナによる消費リソース量を考慮する。そのため、管理装置１００は、アプリ消費リソーステーブルを更に保持する。

【0101】

図１２は、第３の実施の形態のアプリ消費リソーステーブルの例を示す図である。
アプリ消費リソーステーブル１１４は、記憶部１１０に格納される。例えば、アプリ消費リソーステーブル１１４は、記憶部１１０に予め記憶される。ただし、ノード監視部１２１は、コンテナ管理テーブル１１１やキャッシュイメージテーブル１１２の作成のために各ノードから収集した情報に基づいて、アプリ消費リソーステーブル１１４を作成し、記憶部１１０に格納してもよい。

【0102】

アプリ消費リソーステーブル１１４は、アプリケーションに対応するコンテナのイメージと、当該コンテナにより消費されるリソース量とを示す情報である。アプリ消費リソーステーブル１１４は、アプリ名、コンテナ数、コンテナイメージ、１コンテナ当たりの消費ＣＰＵ数および１コンテナ当たりの消費メモリ容量の項目を含む。

【0103】

アプリ名の項目には、アプリケーションの名称が登録される。コンテナ数の項目には、該当のアプリケーションに対して実行されたコンテナの数が登録される。コンテナイメージの項目には、当該アプリケーションに対応するコンテナのイメージの識別名（イメージ名：版数）が登録される。１コンテナ当たりの消費ＣＰＵ数の項目には、当該アプリケーションに対応するコンテナ１個当たりの消費ＣＰＵ数が登録される。１コンテナ当たりの消費メモリ容量の項目には、当該アプリケーションに対応するコンテナ１個当たりの消費メモリ容量が登録される。メモリ容量の単位は、例えばＧＢである。

【0104】

例えば、アプリ消費リソーステーブル１１４は、アプリ名「ａｐｐ０１」、コンテナ数「１」、コンテナイメージ「ａｐｐ０１：２．１」、１コンテナ当たりの消費ＣＰＵ数「０．５」、１コンテナ当たりの消費メモリ容量「１」のレコードを有する。このレコードは、アプリ名「ａｐｐ０１」に対応するコンテナのイメージの識別名「ａｐｐ０１：２．１」であり、当該コンテナ１個当たりの消費ＣＰＵ数が０．５であり、同消費メモリ容量が１ＧＢであることを示す。

【0105】

アプリ消費リソーステーブル１１４には、他のアプリケーションに対しても同様のレコードが登録される。なお、各アプリケーションに対して、コンテナのイメージの識別名、１コンテナ当たりの消費ＣＰＵ数および同消費メモリ容量が予め分かっている場合、前述のように、アプリ消費リソーステーブル１１４には、これらの情報が予め登録されていてもよい。アプリ消費リソーステーブル１１４は、コンテナ数の項目を有していなくてもよい。

【0106】

例えば、イメージ配置制御部１２２は、コンテナ管理テーブル１１１、キャッシュイメージテーブル１１２およびアプリ消費リソーステーブル１１４に基づいて、各ノードで保持される未使用キャッシュイメージを抽出することができる。未使用キャッシュイメージとは、当該ノードで保持されるキャッシュイメージであって、当該ノードで動作していないコンテナのキャッシュイメージである。これらのテーブルの例では、ノード名「ｎｏｄｅ０３」に対応するノード２００ｂに保持される、イメージ名：版数が「ａｐｐ０３：１．４」のキャッシュイメージが未使用キャッシュイメージである。また、当該未使用キャッシュイメージから作成される１つのコンテナが消費するリソース量は、消費ＣＰＵ２個、消費メモリ容量４ＧＢとなる。

【0107】

未使用キャッシュイメージから作成されるコンテナが消費するリソース量は、該当のノードにおいて、当該コンテナにより将来利用される可能性のある潜在的な消費リソース量であると言える。

【0108】

なお、アプリ消費リソーステーブル１１４におけるコンテナの数の項目には、該当のアプリケーション用に１つのノードで起動されるコンテナの数が登録されてもよい。その場合、１コンテナ当たりの消費リソース量に当該コンテナの数を乗じた値が、当該アプリケーションに対応する各コンテナによる、該当のノードでの潜在的な消費リソース量となる。ただし、１つのアプリケーションに対し、該当のノードで起動されるコンテナの数が常に１つである場合、アプリ消費リソーステーブル１１４は、コンテナ数の項目をもたなくてもよい。

【0109】

例えば、イメージ配置制御部１２２は、クラスタ内のノード２００，２００ａ，２００ｂに対して、未使用キャッシュイメージを考慮した実質の空き容量指標値を次のように求める。

【0110】

図１３は、リソーステーブルの例を示す図である。
リソーステーブル１１３ａは、リソーステーブル１１３に代えて、記憶部１１０に格納される。リソーステーブル１１３ａは、リソーステーブル１１３で例示した各項目に加えて、実質の空き容量指標値の項目を更に含む。

【0111】

実質の空き容量指標値の項目には、該当のノードに対して計算された実質の空き容量指標値が登録される。実質の空き容量指標値は、未使用キャッシュイメージにより作成されるコンテナによる消費リソース量を考慮した空き容量指標値である。

【0112】

ここで、未使用キャッシュイメージにより作成されるコンテナで消費されるＣＰＵ数をｐ個とし、当該コンテナで消費されるメモリ容量をｑＧＢとする。実質の空き容量指標値は、ｐ，ｑおよび前述のｎ，ｍ，Ｎ，Ｍを用いて、（α＊（ｎ－ｐ）／Ｎ）＋β＊（ｍ－ｑ）／Ｍ）と計算される。前述のように、α，βは正の実数である。本例ではα＝β＝１とする。

【0113】

アプリ消費リソーステーブル１１４の例では、ノード２００，２００ａに対してｐ＝ｑ＝０であり、ノード２００ｃに対してｐ＝２、ｑ＝４である。このため、ノード２００，２００ａの実質の空き容量指標値は、空き容量指標値に等しくなる。一方、ノード２００ｂの実質の空き容量指標値は、（４－１－２）／１０＋（８－２－４）／２０＝０．２である。

【0114】

次に、第３の実施の形態の管理装置１００の処理手順を説明する。
図１４は、コンテナ起動時処理の例を示すフローチャートである。
第３の実施の形態では、図９のステップＳ１４に代えてステップＳ１４ａ，Ｓ１４ｂを実行する点、ステップＳ１６に代えてステップＳ１６ａを実行する点が図９の手順と異なる。そこで、以下ではステップＳ１４ａ，Ｓ１４ｂ，Ｓ１６ａを説明し、他のステップの説明を省略する。

【0115】

ステップＳ１４ａは、ステップＳ１３の後に実行される。なお、アプリ消費リソーステーブル１１４は、ノード監視部１２１により予め作成され、記憶部１１０に格納されている。また、ステップＳ１３では、ノード監視部１２１は、各ノードのリソースに関する情報を収集し、リソーステーブル１１３ａに登録する。ただし、ステップＳ１３の段階では、空き容量指標値や実質の空き容量指標値は登録されない。

【0116】

（Ｓ１４ａ）イメージ配置制御部１２２は、各ノードに対し、当該ノードが保有する全てのキャッシュイメージによりコンテナを起動した場合に消費されるリソース容量を算出する。例えば、イメージ配置制御部１２２は、リソーステーブル１１３ａおよびアプリ消費リソーステーブル１１４に基づいて、当該リソース容量の算出を行う。

【0117】

（Ｓ１４ｂ）イメージ配置制御部１２２は、ステップＳ１４ａで算出した、ノードが保有する全てのキャッシュイメージよりコンテナを起動した場合に消費されるリソース容量に基づいて、各ノードの実質の空き容量指標値を算出する。イメージ配置制御部１２２は、算出した実質の空き容量指標値をリソーステーブル１１３ａに登録する。そして、ステップＳ１５に処理が進む。

【0118】

ステップＳ１５の実行後にステップＳ１６ａが実行される。
（Ｓ１６ａ）イメージ配置制御部１２２は、ステップＳ１５で抽出したノードの中から実質の空き容量指標値が最大のノードをキャッシュイメージの転送先に決定する。そして、ステップＳ１７に処理が進む。

【0119】

このように、イメージ配置制御部１２２は、各ノードの実質の空き容量指標値に基づいて、イメージの配置先のノードを決定してもよい。
図１５は、スケールアウトまたは自動復旧時処理の例を示すフローチャートである。

【0120】

第３の実施の形態では、図１０のステップＳ２２とステップＳ２３との間にステップＳ２２ａを実行する点が図１０の手順と異なる。そこで、以下ではステップＳ２２ａを説明し、他のステップの説明を省略する。ステップＳ２２ａは、ステップＳ２２の後に実行される。

【0121】

（Ｓ２２ａ）コンテナ起動制御部１２３は、ステップＳ２２で抽出されたノードのうち、スケールアウトまたは自動復旧のために起動する該当のコンテナのキャッシュイメージが存在するノードを抽出する。コンテナ起動制御部１２３は、コンテナ管理テーブル１１１およびキャッシュイメージテーブル１１２に基づいて、該当のコンテナのキャッシュイメージが存在するノードを抽出する。そして、ステップＳ２３に処理が進む。

【0122】

ステップＳ２３では、第２の実施の形態と同様に、ステップＳ２２ａで抽出されたノードのうち空き容量指標値が最大のノードがコンテナの起動先に決定される。
このように、コンテナ起動制御部１２３は、予備のイメージを配置したノードにより優先的に、スケールアウトまたは自動復旧対象のコンテナを起動させてもよい。

【0123】

次に、第３の実施の形態の管理装置１００によるイメージ配置およびコンテナ起動の流れを説明する。
図１６は、イメージ配置の例を示す図である。

【0124】

クラスタには、図１１と同様に、ノード２００，２００ａ，２００ｂ，２００ｃが属するものとする。図１６では、ノード２００，２００ａ，２００ｂ，２００ｃそれぞれの保有リソースのクラスタ内での割合が便宜的に示されている。ノード２００の保有リソースの割合は０．５である。ノード２００ａの保有リソースの割合は０．１である。ノード２００ｂの保有リソースの割合は０．２５である。ノード２００ｃの保有リソースの割合は０．１５である。

【0125】

まず、管理装置１００は、ノード２００，２００ａにおいて、それぞれ新たなコンテナ２１１，２１１ａを起動させる（ステップＳＴ２０）。コンテナ２１１，２１１ａ、何れもアプリケーション「Ａ」のコンテナである。このとき、ノード２００はイメージＡを保持する。ノード２００ａは、イメージＡ，Ｂを保持する。ノード２００ｂは、イメージＥ，Ｃを保持する。ノード２００ｂは、コンテナ２１１ｂを実行する。ノード２００ｃは、イメージＤを有する。ノード２００ｃは、コンテナ２１１ｃを実行する。ノード２００，２００ａ，２００ｂ，２００ｃそれぞれは複数のコンテナを実行していてもよい。

【0126】

管理装置１００は、各ノードから収集した情報に基づいて、各ノードの実質の空き容量指標値を算出する。管理装置１００は、起動したコンテナ２１１，２１１ａに対応するイメージＡを保持していないノード２００ｂ，２００ｃのうち、実質の空き容量指標値が最大であるノードを抽出する。例えば、ノード２００ｂの実質の空き容量指標値は０．１である。また、ノード２００ｃの実質の空き容量指標値は０．１２である。この場合、管理装置１００は、ノード２００ｃを抽出し、イメージＡの転送先とする（ステップＳＴ２１）。

【0127】

管理装置１００は、転送先のノード２００ｃに、イメージＡを転送させる（ステップＳＴ２２）。例えば、管理装置１００は、ノード２００，２００ａのうちの任意のノード（例えば、ノード２００ａ）からノード２００ｃへイメージＡを複製して転送させることで、ノード２００ｃにイメージＡを格納する。なお、管理装置１００は、ノード２００，２００ａのうちの負荷が小さい方のノードにより、ノード２００ｃへのイメージＡの転送を実行させてもよい。

【0128】

図１７は、コンテナ起動の例を示す図である。
ステップＳＴ２２の実行後、管理装置１００は、コンテナ２１１，２１１ａの負荷の増大に応じてスケールアウトを行うと決定する。すると、管理装置１００は、最新のキャッシュイメージテーブルに基づいて、コンテナ２１１，２１１ａに対応する予備のイメージＡを保持するノード２００ｃを特定する。管理装置１００は、スケールアウト対象のコンテナをノード２００ｃにより起動すると決定する（ステップＳＴ３０）。なお、予備のイメージＡを保持するノードが複数存在する場合、管理装置１００は、そのうち空き容量指標値が最大のノードを、該当のコンテナの起動先のノードとして決定する。

【0129】

そして、管理装置１００は、イメージＡに基づくコンテナ２１２ｃの起動をノード２００ｃに指示し、ノード２００ｃによりコンテナ２１２ｃを起動させる（ステップＳＴ３１）。イメージＡは、ノード２００ｃにキャッシュされている。このため、ノード２００ｃによりコンテナ２１２ｃが高速に起動される。

【0130】

管理装置１００は、ノード２００ｃにおけるコンテナ２１２ｃの起動に応じて、図１４の手順によりイメージＡをノード２００ｂに転送させる（ステップＳＴ３２）。例えば、管理装置１００は、ノード２００ｃからノード２００ｂへイメージＡを複製して転送させることで、ノード２００ｂにイメージＡを格納する。こうして、次回のスケールアウトに備えて、ノード２００ｂにイメージＡがキャッシュされる。

【0131】

なお、ステップＳＴ３０～ＳＴ３２は、自動復旧の場合も同様である。例えば、管理装置１００は、コンテナ２１１，２１１ａの少なくとも何れかにおける障害を検知したときに、自動復旧の処理として、ステップＳＴ３０～ＳＴ３２を実行してもよい。

【0132】

第３の実施の形態で例示したように、管理装置１００は、予備のイメージを配置したノードを優先して選択し、当該ノードによりスケールアウトまたは自動復旧対象のコンテナを起動させてもよい。これにより、管理装置１００は、該当のコンテナを高速に起動できる可能性を高められる。

【0133】

ただし、予備のイメージを配置したノードで優先してコンテナを起動する場合、キャッシュイメージを多く保持するノードにコンテナが集中し易くなり、当該ノードでリソースが枯渇する可能性が高まる。そこで、管理装置１００は、各ノードにおける未使用キャッシュイメージを考慮した実質の空き容量指標値に基づいて予備のリソースの格納先を決定することで、特定のノードへコンテナが集中する可能性を低減できる。その結果、管理装置１００は、当該ノードでリソースが枯渇する可能性を低減できる。

【0134】

こうして、管理装置１００は、アプリケーションの可用性を、より一層向上させることができる。
以上説明したように第２，第３の実施の形態の管理装置１００は次の処理を実行する。

【0135】

記憶部１１０は、複数のノードそれぞれが保持する、コンテナのイメージを示すキャッシュ情報を記憶する。制御部１２０は、キャッシュ情報に基づいて、複数のノードのうちの第１ノードにより実行中である第１コンテナに対応する第１イメージが記憶されていない、第１ノード以外のノードを特定する。制御部１２０は、特定したノードのうちリソースの空き容量が最も多い第２ノードに第１イメージの複製である第２イメージを格納する。制御部１２０は、第１コンテナのスケールアウトまたは第１コンテナの障害に応じて第１コンテナと同じ第２コンテナを起動させる場合、第１コンテナが動作していないノードのうち、第２イメージを保持する第２ノードにより第２コンテナを起動させる。

【0136】

これにより、管理装置１００は、コンテナ起動時間を低減できる。特に、管理装置１００は、スケールアウトや自動復旧時において、第２コンテナの起動を高速化できる。このため、管理装置１００は、第２コンテナにより提供されるアプリケーションの可用性を高められる。なお、キャッシュイメージテーブル１１２は、キャッシュ情報の一例である。

【0137】

なお、制御部１２０は、第２イメージを、複数の第２ノードに格納してもよい。例えば、制御部１２０は、第１コンテナに対応する第１イメージが記憶されていない、第１ノード以外のノードのうち、リソースの空き容量が多い順に、２以上の所定数の第２ノードを選択してもよい。そして、制御部１２０は、選択した所定数の第２ノードそれぞれに、第２イメージを格納してもよい。

【0138】

制御部１２０は、第２コンテナを起動させる際に、キャッシュ情報に基づいて第２イメージを保持する第２ノードを優先して選択し、当該第２ノードにより第２コンテナを起動させてもよい。

【0139】

これにより、管理装置１００は、第２イメージを予め保持する第２ノードにより適切に第２コンテナを起動させることができ、第２コンテナの起動時間を低減できる。例えば、制御部１２０は、まずは第２ノードにおいて第２コンテナの起動に所要されるリソースを確保できるか否かを判定し、確保できる場合は、第２ノードにより第２コンテナを起動させる。一方、第２ノードで第２コンテナ用のリソースを確保できない場合に、制御部１２０は、第２コンテナの起動に所要されるリソースを確保可能な他ノードにより、第２コンテナを起動させてもよい。

【0140】

制御部１２０は、複数のノードそれぞれのリソースの空き容量を、当該ノードで動作中のコンテナにより消費される第１リソース量と、当該ノードで未動作であるが当該ノードが保持するイメージから起動可能なコンテナの動作に所要される第２リソース量とに基づいて評価してもよい。

【0141】

こうして、管理装置１００は、該当のノードで将来消費される可能性の高いリソース量を加味して当該ノードのリソースの空き容量を評価し、イメージの配置先の第２ノードを決めることで、第２ノードにコンテナが集中することを抑えられる。なお、前述の未使用キャッシュイメージから起動可能なコンテナは、当該ノードで未動作であるが当該ノードが保持するイメージから起動可能なコンテナに相当する。

【0142】

制御部１２０は、複数のノードそれぞれが保持するイメージの情報を定期的に収集し、キャッシュ情報を更新してもよい。これにより、管理装置１００は、キャッシュ情報を最新の状態に保てる。また、管理装置１００は、第２イメージの配置や、第２コンテナの起動時にキャッシュ情報を取得するためのオーバーヘッドを削減でき、第２イメージの配置や第２コンテナの起動に要する時間を低減できる。

【0143】

制御部１２０は、第２イメージを第２ノードに格納する際、第１イメージから複製された第２イメージを第１ノードから第２ノードへ転送させることで、第２イメージを第２ノードに格納してもよい。管理装置１００は、第２ノードへの第２イメージの格納を効率的に行える。例えば、第１ノードと第２ノードとは、同じネットワークに属する可能性が高い。このため、コンテナレジストリ７０が上位ネットワークに存在する場合にコンテナレジストリ７０から第２イメージをダウンロードするよりも、上位ネットワークの負荷が抑えられる。また、この場合に管理装置１００は、コンテナレジストリ７０から第２イメージをダウンロードするよりも、第２ノードへの第２イメージの格納を高速に行える。

【0144】

制御部１２０は、第２コンテナを起動させる際に、第２イメージを保持する第２ノードが複数ある場合、複数の第２ノードのうちリソースの空き容量が最も多い第２ノードにより第２コンテナを起動させてもよい。これにより、管理装置１００は、複数のノードに対して適切に負荷を分散させることができる。

【0145】

なお、第１の実施の形態の情報処理は、処理部１２にプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、ＣＰＵ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体６３に記録できる。

【0146】

例えば、プログラムを記録した記録媒体６３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体６３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。

【符号の説明】

【0147】

１０ 情報処理装置
１１ 記憶部
１１ａ キャッシュ情報
１１ｂ リソース情報
１２ 処理部
２０，３０，４０ ノード
２１，３１，４１ 記憶部
２１ａ，２１ｂ，３１ａ，４１ａ，４１ｂ イメージ
２２，２３，３２，４２，４３ コンテナ
５０ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】