特許 7459014 コンテナ管理装置、及びコンテナ管理プログラム

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

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

(11)【特許番号】

(24)【登録日】2024-03-22

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

(54)【発明の名称】コンテナ管理装置、及びコンテナ管理プログラム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240325BHJP

   G06F 9/455 20180101ALI20240325BHJP

【ＦＩ】

G06F9/50 150C

G06F9/455 150

【請求項の数】 6

(21)【出願番号】P 2021084145

(22)【出願日】2021-05-18

(65)【公開番号】P2022177712

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

【審査請求日】2022-12-15

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(73)【特許権者】

【識別番号】518366555

【氏名又は名称】コリア アドバンスト インスティテュート オブ サイエンス アンド テクノロジー

(74)【代理人】

【識別番号】110001519

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

(72)【発明者】

【氏名】李 忠翰

(72)【発明者】

【氏名】チェ ビョングォン

(72)【発明者】

【氏名】パク ジンウ

(72)【発明者】

【氏名】ハン ドンス

【審査官】坂東 博司

(56)【参考文献】

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

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

【文献】中国特許出願公開第１１１９１３８０３（ＣＮ，Ａ）

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

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ ９／４５５

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

【請求項1】

処理を行うためのコンテナが配置されたマイクロサービスを各々接続したサービスにおいて、前記サービスに係るワークロード、前記マイクロサービスがどのように接続されているかに関する情報である接続情報、及び前記ワークロードに係る各々の処理がマイクロサービス間を伝搬するサービスチェインを取得する取得部と、
各々のマイクロサービスにおけるワークロード、及びリソース使用量の関係を表す予測モデルを用いて、取得した前記ワークロード、前記接続情報、及び前記サービスチェインからマイクロサービス毎のリソース使用量を導出し、コンテナの数を予測する予測部と、
予測された前記マイクロサービス毎のコンテナの数に応じて、各々のマイクロサービスに同一契機に配置するコンテナを制御する制御部と、
を備えたコンテナ管理装置。

【請求項2】

前記取得部は、過去のマイクロサービス毎のワークロード、及びリソース使用量の情報であるリソース情報をさらに取得し、
前記リソース情報を用いて、前記予測モデルを生成するモデル生成部をさらに備える
請求項１に記載のコンテナ管理装置。

【請求項3】

前記予測モデルは、予め定められた回帰モデル、又はガウス過程によって定められた回帰モデルである請求項２に記載のコンテナ管理装置。

【請求項4】

前記モデル生成部は、前記リソース情報のデータ量に応じて、予め定められた回帰モデル、又はガウス過程によって定められた回帰モデルを選択する請求項３に記載のコンテナ管理装置。

【請求項5】

前記予測部は、前記サービスチェインから処理が伝搬するマイクロサービスを特定して、各々のマイクロサービスのワークロードを推定し、前記予測モデルを用いて、推定した前記マイクロサービス毎のワークロードから、前記リソース使用量を導出する請求項１から請求項４の何れか１項に記載のコンテナ管理装置。

【請求項6】

処理を行うためのコンテナが配置されたマイクロサービスを各々接続したサービスにおいて、前記サービスに係るワークロード、前記マイクロサービスがどのように接続されているかに関する情報である接続情報、及び前記ワークロードに係る各々の処理がマイクロサービス間を伝搬するサービスチェインを取得する取得ステップと、
各々のマイクロサービスにおけるワークロード、及びリソース使用量の関係を表す予測モデルを用いて、取得した前記ワークロード、前記接続情報、及び前記サービスチェインからマイクロサービス毎のリソース使用量を導出し、コンテナの数を予測する予測ステップと、
予測された前記マイクロサービス毎のコンテナの数に応じて、マイクロサービスに同一契機に配置するコンテナを制御する制御ステップと、
をコンピュータに実行させるためのコンテナ管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コンテナ管理装置、及びコンテナ管理プログラムに関する。

【背景技術】

【0002】

従来技術として、各々のマイクロサービスにおけるリソースのワークロード（処理負荷）に合わせて、コンテナ（Ｐｏｄ）を動的に削減、及び増設して、マイクロサービスにおけるリソース量を制御して処理を行う技術が提案されている（例えば、非特許文献１参照）。

【0003】

当該技術では、各々のマイクロサービスにおいてリソースのワークロードの閾値を設定し、ワークロードが閾値を超えた場合、マイクロサービス毎にコンテナを増設してリソース量を増やす制御を行う。

【先行技術文献】

【非特許文献】

【0004】

【文献】"Kubernetes"、［令和３年３月１０日検索］、インターネット＜URL: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/＞

【発明の概要】

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

【0005】

ところで、近年、各々のアプリケーションを配置したマイクロサービスをそれぞれ接続し、接続されたマイクロサービス間において連携して処理を行うサービスが提供されている。当該サービスでは、マイクロサービス間をワークロードが伝搬しながら処理を行っている。

【0006】

しかしながら、非特許文献１では、マイクロサービスに生じるワークロードに合わせてコンテナの増設を行うため、ワークロードが急激に変動した場合、ワークロードがマイクロサービスの末端まで伝搬するのに時間を要し、各々のマイクロサービスにおけるワークロードが即座に把握できないことがある。そのため、当該サービスは、各々のマイクロサービスに適切なリソース量を即座に割り当てることができず、全体的なサービスのサービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）の低下を抑制できるとは限らなかった。

【0007】

本発明は、急にワークロードが変動した場合であっても、全体的なサービスのサービス品質の低下を抑制できるコンテナ管理装置及びコンテナ管理プログラムを提供することを目的とする。

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

【0008】

請求項１に記載のコンテナ管理装置は、処理を行うためのコンテナが配置されたマイクロサービスを各々接続したサービスにおいて、前記サービスに係るワークロード、前記マイクロサービスがどのように接続されているかに関する情報である接続情報、及び前記ワークロードに係る各々の処理がマイクロサービス間を伝搬するサービスチェインを取得する取得部と、各々のマイクロサービスにおけるワークロード、及びリソース使用量の関係を表す予測モデルを用いて、取得した前記ワークロード、前記接続情報、及び前記サービスチェインからマイクロサービス毎のリソース使用量を導出し、コンテナの数を予測する予測部と、予測された前記マイクロサービス毎のコンテナの数に応じて、マイクロサービスに同一契機に配置するコンテナを制御する制御部と、を備えている。

【0009】

コンテナ管理装置は、取得部が、サービスに係るワークロード、マイクロサービスがどのように接続されているかに関する接続情報、及びワークロードが伝搬するサービスチェインを取得する。コンテナ管理装置は、予測部がマイクロサービスにおけるワークロード、及びリソース使用量の関係を表す予測モデルを用いて、サービスに係るワークロード、接続情報、及びサービスチェインからリソースの使用量を導出し、コンテナの数を予測する。コンテナ管理装置は、制御部が、予測されたコンテナの数に応じて、マイクロサービスに同一契機に配置するコンテナを制御する制御する。当該コンテナ管理装置によれば、急にワークロードが変動した場合であっても、全体的なサービスのサービス品質の低下を抑制できる。

【0010】

請求項２に記載のコンテナ管理装置は、請求項１に記載のコンテナ管理装置において、前記取得部は、過去のマイクロサービス毎のワークロード、及びリソース使用量の情報であるリソース情報をさらに取得し、前記リソース情報を用いて、前記予測モデルを生成するモデル生成部をさらに備える。

【0011】

請求項２に記載のコンテナ管理装置では、過去のマイクロサービス毎のワークロード、及びリソース使用量であるリソース情報をさらに取得し、モデル生成部がリソース情報を用いて予測モデルを生成する。当該コンテナ管理装置によれば、過去のワークロードに基づいて、コンテナを配置することができる。

【0012】

請求項３に記載のコンテナ管理装置は、請求項２に記載のコンテナ管理装置において、前記予測モデルは、予め定められた回帰モデル、又はガウス過程によって定められた回帰モデルである。

【0013】

請求項３に記載のコンテナ管理装置によれば、各々のマイクロサービスにおけるリソース使用量を予測することができる。

【0014】

請求項４に記載のコンテナ管理装置は、請求項３に記載のコンテナ管理装置において、前記モデル生成部は、前記リソース情報のデータ量に応じて、予め定められた回帰モデル、又はガウス過程によって定められた回帰モデルを選択する。

【0015】

請求項４に記載のコンテナ管理装置によれば、過去のワークロードのデータ量に応じて精度の高い予測モデルを選択することができる。

【0016】

請求項５に記載のコンテナ管理装置は、請求項１から請求項４の何れか１項に記載のコンテナ管理装置において、前記予測部は、前記サービスチェインから処理が伝搬するマイクロサービスを特定して、各々のマイクロサービスのワークロードを推定し、前記予測モデルを用いて、推定した前記マイクロサービス毎のワークロードから、前記リソース使用量を導出する。

【0017】

請求項５に記載のコンテナ管理装置によれば、マイクロサービス間の接続関係を考慮してコンテナを配置することができる。

【発明の効果】

【0018】

本発明によれば、急にワークロードが変動した場合であっても、全体的なサービスのサービス品質の低下を抑制できる。

【図面の簡単な説明】

【0019】

【図1】本実施形態に係る複数のマイクロサービスによって構成されたサービスが提供する画面の一例を示す正面図である。

【図2】本実施形態に係る複数のマイクロサービスによって構成されたサービスのネットワークの一例を示す模式図である。

【図3】本実施形態に係るコンテナ管理装置のハードウェア構成の一例を示すブロック図である。

【図4】本実施形態に係るコンテナ管理装置の機能構成の一例を示すブロック図である。

【図5】本実施形態に係るワークロード、及びリソース使用量の関係の一例を示すグラフである。

【図6】本実施形態に係るガウス過程の説明に供する処理負荷（ワークロード）及びリソース使用量の関係の一例を示すグラフである。

【図7】本実施形態に係るコンテナの数を予測する処理の流れの一例を示すフローチャートである。

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

【0020】

以下、図面を参照して、本発明を実施するための形態例を詳細に説明する。本発明は、サービスに生じるワークロード（処理負荷）に応じて、サービス全体のマイクロサービスに、処理を実行するコンテナを略同時に配置（スケールアウト）する制御を行うコンテナ管理装置１０についてなされたものである。ここで、本実施形態に係るコンテナとは、サーバのメモリ及びＣＰＵ等のリソースを複数に分割して割り当てたアプリケーションの実行環境である。なお、本実施形態に係る「略同時」は「同一契機」の一例である。

【0021】

まず、図１、及び図２を参照して、本実施形態に係るサービス、及びマイクロサービスについて説明する。なお、本実施形態では、サービスが処理として、画面を表示するアプリケーションが実行された場合、図１に示す商品の詳細画面１００を表示する形態について説明する。一例として図１に示すように、商品の詳細画面１００は、商品詳細領域１１０、商品レビュー領域１２０、及び商品の評価値領域１３０を備えている。

【0022】

サービスは、商品の詳細画面１００、商品詳細領域１１０、商品レビュー領域１２０、及び商品の評価値領域１３０の各々を表示する処理を行うマイクロサービスを備えている。サービスは、各々のマイクロサービスが順に処理を実行することによって、サービスの処理として商品の詳細画面１００が表示される。一例として図２に示すように、各々のマイクロサービスは、それぞれ接続され、各々のマイクロサービス間を処理が伝搬することによって一連の処理を実行する。

【0023】

図２は、本実施形態に係るサービスのネットワークの一例を示す模式図である。図２に示すように、サービス１４０は、複数のマイクロサービス１６０が接続されて構成されている。例えば、サービス１４０が処理として、画面を表示するアプリケーションが実行された場合、マイクロサービス１６０Ａは、商品の詳細画面１００を表示する処理を行い、マイクロサービス１６０Ｂは、商品詳細領域１１０を表示する処理を行う。また、マイクロサービス１６０Ｃは、商品レビュー領域１２０を表示する処理を行い、マイクロサービス１６０Ｄは、商品の評価値領域１３０を表示する処理を行う。

【0024】

サービス１４０は、商品の詳細画面１００を表示するアプリケーションが実行された場合、サービスの接続情報、及びサービスチェインに基づいて、各々のマイクロサービスに処理を伝搬させて、上述した処理を実行させる。

【0025】

ここで、接続情報とは、全体のサービスの中で各々のマイクロサービスがどのように接続されているか（ネットワークトポロジー）に関する情報である。なお、本実施形態に係るサービスのネットワークは、ツリー型である形態について説明する。しかし、これに限定されない。サービスのネットワークは、バス型、スター型、リング型、及びコネクト型等の如何なるネットワークであってもよい。

【0026】

また、サービスチェインは、非特許文献１のＫｕｂｅｒｎｅｔｅｓにおける後述するＩｎｇｒｅｓｓ１５０の分類器によって分類される。Ｉｎｇｒｅｓｓは、例えば、サービスに係るＷＥＢブラウザやアプリケーションが実行され、サービス１４０にワークロードが生じた際に、接続情報を用いて、ワークロードに係る処理に応じたマイクロサービスを選定する。換言すると、サービスチェインには、接続情報に基づいて、ワークロードに係る処理を実行するマイクロサービス、及びワークロードが伝搬するマイクロサービスの順番が設定されている。

【0027】

例えば、図２に示すサービス１４０が処理として商品の詳細画面１００を表示するアプリケーションが実行された場合、Ｉｎｇｒｅｓｓ１５０の分類器は、接続情報に基づいて、ワークロードをサービスチェイン１７０Ａ、及びサービスチェイン１７０Ｂに分類する。サービスチェイン１７０Ａは、フロントエンドであるマイクロサービス１６０Ａから、バックエンドであるマイクロサービス１６０Ｂへ処理を伝搬するフローを示している。また、サービスチェイン１７０Ｂは、フロントエンドであるマイクロサービス１６０Ａから、マイクロサービス１６０Ｃを経由して、バックエンドであるマイクロサービス１６０Ｄへ処理を伝搬するフローを示している。

【0028】

サービス１４０は、サービスチェイン１７０Ａ、及びサービスチェイン１７０Ｂに基づいて、サービス１４０における各々のマイクロサービス１６０に処理を実行させることによってサービス全体の処理を実行する。

【0029】

従来技術では、各々のマイクロサービス１６０にワークロードが伝搬した際に、マイクロサービスが処理を行うために必要なリソースが、設定したリソースの閾値以上であるか否かを判定し、コンテナを配置するか否かを判定して、コンテナを制御している。本実施形態に係るコンテナ管理装置１０は、サービス１４０（例えば、マイクロサービス１６０Ａ）にワークロードが生じた際に、サービス１４０全体の各々のマイクロサービス１６０における必要なコンテナの数を予測して、コンテナの配置を制御する。

【0030】

次に、図３を参照して、本実施形態に係るコンテナ管理装置１０のハードウェア構成について説明する。図３は、本実施形態に係るコンテナ管理装置１０のハードウェア構成の一例を示すブロック図である。

【0031】

コンテナ管理装置１０は、サービスに生じるワークロード（処理負荷）に応じて、サービス全体のマイクロサービスに、略同時にコンテナ配置する制御を行うサーバ、又は端末である形態について説明する。

【0032】

図３に示すように、本実施形態に係るコンテナ管理装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ストレージ１４、入力部１５、モニタ１６、及び通信インターフェース（通信Ｉ／Ｆ）１７を含んで構成されている。ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ストレージ１４、入力部１５、モニタ１６、及び通信Ｉ／Ｆ１７の各々は、バス１８により相互に接続されている。

【0033】

ＣＰＵ１１は、コンテナ管理装置１０の全体を統括し、制御する。ＲＯＭ１２は、本実施形態で用いるコンテナ管理プログラムを含む各種プログラム及びデータ等を記憶している。ＲＡＭ１３は、各種プログラムの実行時のワークエリアとして用いられるメモリである。ＣＰＵ１１は、ＲＯＭ１２に記憶されたプログラムをＲＡＭ１３に展開して実行することにより、サービスに生じるワークロードに応じて、マイクロサービスにコンテナを配置する処理を行う。ストレージ１４は、一例としてＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、又はフラッシュメモリ等である。なお、ストレージ１４には、コンテナ管理プログラム等を記憶してもよい。入力部１５は、文字の入力等を受け付けるマウス、及びキーボード等である。モニタ１６は、文字及び画像等を表示する。通信Ｉ／Ｆ１７は、データの送受信を行う。

【0034】

次に、図４を参照して、コンテナ管理装置１０の機能構成について説明する。図４は、本実施形態に係るコンテナ管理装置１０の機能的な構成の一例を示すブロック図である。

【0035】

図４に示すように、コンテナ管理装置１０は、取得部２１、モデル生成部２２、記憶部２３、予測部２４、及び制御部２５を備えている。また、取得部２１は、ワークロード取得部２１Ａ、接続情報取得部２１Ｂ、サービスチェイン取得部２１Ｃ、及びリソース情報取得部２１Ｄを備えている。ＣＰＵ１１がコンテナ管理プログラムを実行することで、取得部２１、モデル生成部２２、記憶部２３、予測部２４、及び制御部２５として機能する。

【0036】

取得部２１は、現にサービスに生じるワークロード、サービスの接続情報（ネットワークトポロジー）、及びワークロードに係るサービスチェインを取得する。

【0037】

具体的には、ワークロード取得部２１Ａは、現にサービスに生じているワークロードに関する情報を取得する。例えば、ワークロード取得部２１Ａは、ワークロードに関する情報として、単位時間当たりのトランザクション量（ＴＰＳ：Ｔｒａｎｓａｃｔｏｉｎｓ Ｐｅｒ Ｓｅｃｏｎｄ）を取得する。ここで、トランザクションとは、例えば、ＷＥＢブラウザやアプリケーションの画面を表示する指示を受けてから画面を表示するまでの処理を一つの単位とした一連の処理である。

【0038】

接続情報取得部２１Ｂは、サービスの接続情報（ネットワークトポロジー）を取得する。

【0039】

サービスチェイン取得部２１Ｃは、ワークロード、及び接続情報を用いて生成された、ワークロードがマイクロサービス間を伝搬するサービスチェインを取得する。

【0040】

リソース情報取得部２１Ｄは、各々のマイクロサービスにおける過去のワークロード、及びリソース使用量を示す情報であるリソース情報を取得する。

【0041】

モデル生成部２２は、取得したリソース情報を用いて、マイクロサービス毎にワークロード、及びリソース使用量の関係を示す予測モデルを生成する。具体的には、モデル生成部２２は、予測モデルとして、マイクロサービス毎に予め定められた線形回帰モデルとして、一例として図５に示すグラフを生成する。

【0042】

図５は、本実施形態に係るワークロード、及びリソース使用量の関係の一例を示すグラフである。図５の各々のグラフにおける横軸はマイクロサービスに生じたワークロードであり、縦軸は、ワークロードに対応するリソース使用量（ＣＰＵ使用率）である。

【0043】

図５（ａ）は、商品の詳細画面１００を表示する処理を実行するマイクロサービス１６０Ａに係るグラフであり、図５（ｂ）は、商品詳細領域１１０を表示する処理を実行するマイクロサービス１６０Ｂに係るグラフである。また、図５（ｃ）は、商品レビュー領域１２０を表示する処理を実行するマイクロサービス１６０Ｃに係るグラフであり、図５（ｄ）は、商品の評価値領域１３０を表示する処理を実行するマイクロサービス１６０Ｄに係るグラフである。

【0044】

なお、本実施形態に係るモデル生成部２２は、線形回帰モデルを生成する形態について説明した。しかし、これに限定されない。モデル生成部２２は、非線形回帰モデルを生成してもよいし、ガウス過程によって定められた回帰モデルを生成してもよいし、如何なる回帰モデルを生成してもよい。

【0045】

例えば、一例として図６に示すように、ガウス過程による回帰モデルは、変数に対する観測値の相関を考慮する事によって、未知の変数に対しても観測値を補間及び予測する事が可能なモデルである。ガウス過程による回帰モデルは、一般的に変数と観測値との相関をガウス分布によって決定するというもので、離散的な観測値を確率的に連続的に補間ができるのみならず、予測誤差を算出可能である。なお、図６に示す回帰線３０が補完された観測値を示し、網掛けされた領域３１が予測誤差を示す。

【0046】

また、リソース情報の特徴である統計値及び確率分布を用いて、他の予測モデルを生成してもよい。他の予測モデルは、例えば、過去のワークロードと、対応するコンテナの数と、の統計値及び確率分布から、必要なコンテナの数を予測するベイジアンモデルであってもよい。また、他の予測モデルは、過去にコンテナを配置したコンテナの数の時系列を考慮して、必要なコンテナの数を予測する自己回帰モデルであってもよい。

【0047】

また、本実施形態に係るモデル生成部２２は、予め定められた予測モデルを生成する形態について説明した。しかし、これに限定されない。モデル生成部２２によって生成する予測モデルが選択されてもよい。例えば、リソース情報のデータ量に応じて、線形回帰モデル、又はガウス過程による回帰モデルを選択してもよい。具体的には、モデル生成部２２は、取得したリソース情報のデータ量が予め定められた閾値より多い場合、線形回帰モデルを生成し、リソース情報のデータ量が予め定められた閾値以下である場合、ガウス過程による回帰モデルを生成してもよい。

【0048】

記憶部２３は、モデル生成部２２によって生成された予測モデル２３Ａを記憶する。

【0049】

予測部２４は、記憶部２３に記憶されている予測モデル２３Ａを用いて、取得したワークロード、接続情報、及びサービスチェインからマイクロサービス毎に必要なコンテナの数を予測する。

【0050】

具体的には、予測部２４は、取得したサービスチェインから処理が伝搬するマイクロサービスを特定し、ワークロード、及びサービスチェインを用いて、各々のマイクロサービスに係るワークロードを推定する。予測部２４は、記憶部２３に記憶されている予測モデル２３Ａを用いて、マイクロサービス毎に、推定したワークロードに対するリソース使用量を導出し、マイクロサービス毎に必要なコンテナの数を予測する。

【0051】

なお、１つのコンテナに割り当てられるリソース使用量は、予め設定されているものとする。例えば、１コンテナに対して、１００ｍｉｌｌｉｃｏｒｅのリソース使用量を割り当てる設定がされている場合において、予測部２４は、マイクロサービスに必要なリソース使用量を５００ｍｉｌｌｉｃｏｒｅと導出した場合、必要なコンテナの数は５つと予測する。

【0052】

制御部２５は、予測したコンテナの数に応じて、コンテナを複数のマイクロサービスに略同時に配置する制御を行う。具体的には、制御部２５は、マイクロサービスに現に配置されているコンテナの数が予測したコンテナの数より少ない場合、対応するマイクロサービスに、予測した数のコンテナを配置する。

【0053】

なお、本実施形態に係る制御部２５は、マイクロサービスに現に配置されているコンテナの数が予測したコンテナの数より少ない場合、コンテナを配置する制御を行う形態について説明した。しかし、これに限定されない。マイクロサービスに現に配置されているコンテナの数が予測したコンテナの数より多い場合、コンテナを削減する制御を行ってもよい。

【0054】

（制御の流れ）
次に、図７を参照して、本実施形態に係るコンテナ管理装置１０の作用について説明する。図７は、本実施形態に係るコンテナの数を予測する処理の一例を示すフローチャートである。ＣＰＵ１１がＲＯＭ１２又はストレージ１４からコンテナ管理プログラムを読み出し、実行することによって、図７に示すコンテナ管理プログラムが実行される。図７に示すコンテナ管理プログラムは、例えば、コンテナの数を予測する指示が入力された場合、実行される。

【0055】

ステップＳ１０１において、ＣＰＵ１１は、マイクロサービス毎における過去のワークロード、及び過去のリソース使用量であるリソース情報を取得する。

【0056】

ステップＳ１０２において、ＣＰＵ１１は、リソース情報を用いて、マイクロサービス毎に、ワークロード、及びリソース使用量の関係を示す予測モデルを生成し、記憶部２３に記憶する。

【0057】

ステップＳ１０３において、ＣＰＵ１１は、サービスにワークロードが生じたか否かの判定を行う。サービスにワークロードが生じた場合（ステップＳ１０３：ＹＥＳ）、ＣＰＵ１１は、ステップＳ１０４に移行する。一方、サービスにワークロードが生じていない場合（ステップＳ１０３：ＮＯ）、ＣＰＵ１１は、サービスにワークロードが生じるまで待機する。

【0058】

ステップＳ１０４において、ＣＰＵ１１は、現にサービスに生じているワークロード、ワークロードのサービスチェイン、及びサービスの接続情報を取得する。

【0059】

ステップＳ１０５において、ＣＰＵ１１は、ワークロード、サービスチェイン、及び接続情報を用いて、マイクロサービス毎の現在のワークロードを推定する。

【0060】

ステップＳ１０６において、ＣＰＵ１１は、マイクロサービス毎の予測モデルを用いて、リソース使用量を導出し、必要なコンテナの数を予測する。

【0061】

ステップＳ１０７において、ＣＰＵ１１は、予測したコンテナの数に応じて、コンテナを略同時に配置する。

【0062】

ステップＳ１０８において、ＣＰＵ１１は、処理を終了するか否かの判定を行う。処理を終了する場合（ステップＳ１０８：ＹＥＳ）、ＣＰＵ１１は、処理を終了する。一方、処理を終了しない場合（ステップＳ１０８：ＮＯ）、ＣＰＵ１１は、ステップＳ１０１に移行して、リソース情報を取得する。

【0063】

（第１の実施形態のまとめ）
本実施形態のコンテナ管理装置１０は、取得部２１がリソース情報、ワークロード、サービスチェイン、及び接続情報を取得し、モデル生成部２２がリソース情報を用いて、マイクロサービス毎のワークロード、及びリソース使用量の関係を示す予測モデルを生成する。コンテナ管理装置１０は、予測部２４が生成した予測モデルを用いて、ワークロード、サービスチェイン、及び接続情報からマイクロサービス毎にワークロードに対応するためのコンテナの数を予測し、制御部２５が予測したコンテナの数に応じて、コンテナを配置する。本実施形態に係るコンテナ管理装置１０は、サービスにワークロードが生じた際に、マイクロサービス毎に必要となるコンテナの数を予測して、各々のマイクロサービスに略同時にコンテナを配置する。

【0064】

以上、本実施形態によれば、急にワークロードが変動した場合であっても、全体的なサービスのサービス品質の低下を抑制できる。

【0065】

［備考］
なお、本実施形態では、Ｋｕｂｅｒｎｅｔｅｓを用いて、コンテナを管理する形態について説明した。しかし、これに限定されない。例えば、Ｄｏｃｋｅｒ Ｅｎｔｅｒｐｒｉｓｅ、及びＭｅｓｏｓ等のコンテナの配置（オートスケール）を制御するアプリケーションであれば、如何なるアプリケーションであってもよい。

【0066】

また、本実施形態に係るリソース使用量は、ＣＰＵ使用率（ｍｉｌｌｉｃｏｒｅ）である形態について説明した。しかし、これに限定されない。リソース使用量は、メモリであってもよい。

【0067】

また、本実施形態では、リソース情報を取得して回帰モデルを生成する形態について説明した。しかし、これに限定されない。予測部２４が推定したマイクロサービス毎のワークロードを用いて、予測モデルが生成されてもよい。例えば、コンテナ管理装置１０は、リソース情報に、予測部２４が推定したマイクロサービス毎のワークロードを加えて、予測モデルを生成してもよい。予測部２４が推定したマイクロサービス毎のワークロードを加えることによって、最新の情報を反映した予測モデルが生成される。

【0068】

なお、上記実施形態でＣＰＵ１１がソフトウェア（プログラム）を読み込んで実行した各種処理を、ＣＰＵ以外の各種のプロセッサが実行してもよい。この場合のプロセッサとしては、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等の製造後に回路構成を変更可能なＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）、及びＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）等の特定の処理を実行させるために専用に設計された回路構成を有するプロセッサである専用電気回路等が例示される。また、上述した処理を、これらの各種のプロセッサのうちの１つで実行してもよいし、同種又は異種の２つ以上のプロセッサの組み合わせ（例えば、複数のＦＰＧＡ、及びＣＰＵとＦＰＧＡとの組み合わせ等）で実行してもよい。また、これらの各種のプロセッサのハードウェア的な構造は、より具体的には、半導体素子等の回路素子を組み合わせた電気回路である。

【0069】

また、上記実施形態において、各プログラムはコンピュータが読み取り可能な非一時的記録媒体に予め記憶（インストール）されている態様で説明した。例えば、ＣＰＵ１１における制御プログラムはＲＯＭ１２に予め記憶されている。しかしこれに限らず、各プログラムは、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＤＶＤ－ＲＯＭ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、及びＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ等の非一時的記録媒体に記録された形態で提供されてもよい。また、プログラムは、ネットワークを介して外部装置からダウンロードされる形態としてもよい。

【符号の説明】

【0070】

１０ コンテナ管理装置
２１ 取得部
２２ モデル生成部
２４ 予測部
２５ 制御部
１４０ サービス
１６０ マイクロサービス
１７０ サービスチェイン

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】