JP2018190355A

JP2018190355A - リソース管理方法

Info

Publication number: JP2018190355A
Application number: JP2017095021A
Authority: JP
Inventors: 悠司大嶋; Yuji Oshima; 圭大村; Kei Omura
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: NTT Inc
Priority date: 2017-05-11
Filing date: 2017-05-11
Publication date: 2018-11-29

Abstract

【課題】複数のアプリケーションを動作させるサーバにおいて、重要度の高いアプリケーションのリソース不足を防止し、かつ、リソースの利用効率を向上させる。
【解決手段】サーバ１は、サーバ１上で起動させるアプリケーション（コンテナ）の重要度に基づき、ＡＰＬグループを作成する。そして、サーバ１は、重要度の高いＡＰＬグループから優先的に、リソースを割り当てる。ＡＰＬグループの各コンテナは、当該ＡＰＬグループに割り当てられたリソースを共用する。その後、サーバ１は、ＡＰＬグループそれぞれのリソース利用量を監視し、いずれかのＡＰＬグループにおいてリソース不足が発生した場合、余剰リソースを持つＡＰＬグループのリソース割り当て量の一部を、リソース不足が発生したＡＰＬグループに割り当てる。
【選択図】図１

Description

本発明は、リソース管理方法に関する。

サーバ上で動作する様々なアプリケーションに計算リソース（リソース）を割り当てる際、アプリケーションから申告のあったリソース量を動的に割り当てる技術がある（非特許文献１参照）。このような技術によれば、サーバのリソースを有効利用できる。

Benjamin Hindman, et al.,"Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center",NSDI. Vol. 11. No. 2011. 2011.

しかし、上記の技術は、各アプリケーションにリソースの割り当てを行った結果、リソースが枯渇してしまい、重要度の高いアプリケーションにリソースを割り当てることができないおそれがある。例えば、エッジコンピューティングアーキテクチャに用いられるサーバ等、限られたリソースで複数のアプリケーションを動作させる必要のあるサーバに、上記の技術によりリソースの割り当てを行った場合、重要度の低いアプリケーションがリソースを使い切ってしまい、重要度の高いアプリケーションにリソース不足が発生するおそれがある。

また、上記の技術では、各アプリケーションが利用リソース量の最大値を要求するため、要求通りにリソースを割り当てると、各アプリケーションでリソースを使い切らない場合もある。このため、リソースの利用効率が低くなる可能性がある。

そこで、本発明は、前記した問題を解決し、複数のアプリケーションを動作させるサーバにおいて、重要度の高いアプリケーションのリソース不足を防止し、かつ、リソースの利用効率を向上させることを課題とする。

前記した課題を解決するため、本発明は、サーバ上で動作する複数のアプリケーションに対するリソース割り当て量を管理するリソース管理装置において実行されるリソース管理方法であって、前記アプリケーションそれぞれの重要度を受け付ける受け付けステップと、前記受け付けた重要度に応じて、前記アプリケーションを２以上のグループにグルーピングするグルーピングステップと、前記重要度の高いアプリケーションのグループから優先的にリソースを割り当てるリソース割り当てステップと、前記グループそれぞれのアプリケーションのリソース利用量を監視する監視ステップと、前記監視の結果、割り当てリソース量に対する前記リソース利用量であるリソース利用率が所定値以上のグループを検出した場合、余剰リソースを持つグループのリソース割り当て量の少なくとも一部を、前記リソース利用率が前記所定値以上のグループに割り当てるリソース再割り当てステップと、を含んだことを特徴とする。

本発明によれば、複数のアプリケーションを動作させるサーバにおいて、重要度の高いアプリケーションのリソース不足を防止し、かつ、リソースの利用効率を向上させることができる。

図１は、本実施形態のサーバの構成例を示すブロック図である。図２は、図１のリソース管理情報の例を示す図である。図３は、図１のサーバの処理手順の概要を示すフローチャートである。図４は、図３のＳ１の処理の詳細を示すフローチャートである。図５は、図３のＳ２およびＳ３の処理の詳細を示すフローチャートである。図６は、図３のＳ４の処理の詳細を示すフローチャートである。図７は、リソース管理プログラムを実行するコンピュータを示す図である。

以下、図面を参照しながら、本発明の実施形態を説明する。なお、本発明は、以下に示す実施形態に限定されない。

まず、図１を用いて、本実施形態のリソース管理装置（リソース管理部１３）が装備されるサーバ１の概要を説明する。

なお、サーバ１は、例えば、エッジコンピューティングアーキテクチャにおいてエッジサーバとして用いられるサーバであり、複数のアプリケーションを動作させるものとする。サーバ１は、例えば、管理用アプリケーション等、重要度が比較的高いアプリケーションと、３ｒｄパーティの開発したアプリケーション等、重要度が比較的低いアプリケーションとを動作させる。

また、サーバ１の動作させる各アプリケーションは、例えば、コンテナ仮想化技術により、各アプリケーションが利用可能なリソース（ＣＰＵやメモリ等）が隔離されているものとする。例えば、サーバ１は、アプリケーションＡのコンテナＡ、アプリケーションＢのコンテナＢ、および、アプリケーションＣのコンテナＣを備える。

このサーバ１は、コンテナＡ，Ｂ，Ｃを、各コンテナのアプリケーションの重要度に基づきグルーピングする。例えば、サーバ１は、管理用アプリケーション等、比較的重要度の高いアプリケーションのコンテナＡ，ＢをＡＰＬグループＡにグルーピングし、３ｒｄパーティの開発したアプリケーション等、比較的重要度の低いアプリケーションのコンテナＣをＡＰＬグループＢにグルーピングする。

また、サーバ１は、優先度の高いアプリケーション（コンテナ）のＡＰＬグループから優先的にリソースを割り当てる。例えば、サーバ１は、比較的重要度の高いアプリケーションのＡＰＬグループＡには、ユーザにより要求された当該アプリケーションの割り当てリソース量をそのまま割り当て、比較的重要度の低いアプリケーションのＡＰＬグループＢには、ユーザにより要求された当該アプリケーションの割り当てリソース量よりも少ない（例えば、８割程度の）リソースを割り当てる。

その後、サーバ１は、各ＡＰＬグループのリソース利用量を監視し、いずれかのＡＰＬグループで、リソース利用率が高くなっていれば、他のＡＰＬグループの余剰リソースを割り当てる。例えば、サーバ１は、ＡＰＬグループＡのリソース利用率が高くなっており、ＡＰＬグループＢに余剰リソースがあれば、ＡＰＬグループＢの余剰リソースの一部を割り当てる。これにより、サーバ１は、重要度の高いアプリケーションのコンテナのリソース不足を防止し、かつ、リソースの利用効率を向上させることができる。

引き続き、図１を用いてサーバ１の構成例を説明する。図１に示すように、サーバ１は、例えば、コンテナＡ，Ｂ，Ｃと、ハードウェア１１と、コンテナ制御部１２と、リソース管理部１３とを備える。

コンテナは、サーバ１上でアプリケーションが動作する当該アプリケーションの専用領域である。つまり、サーバ１上の各アプリケーションは、コンテナ仮想化技術によりリソースが隔離される。例えば、コンテナは、コンテナ制御部１２により設定された割り当てリソース量の範囲内でリソースを利用する。これにより、サーバ１は、アプリケーションごとのリソース利用量を制限することができる。また、各アプリケーション間の通信はＡＰＩ（Application Programming Interface）を介して行うことになる。したがって、サーバ１は、アプリケーション間の通信の頻度等の制御を行いやすくなる。その結果、サーバ１は、一部のアプリケーションが大量の通信を重要なアプリケーションに対して行うことによる、システムの停止を防止することができる。

また、コンテナがＡＰＬグループにグルーピングされた後は、ＡＰＬグループは、当該ＡＰＬグループ内の各コンテナリソース利用量の合計が、コンテナ制御部１２により設定された当該ＡＰＬグループの割り当てリソース量の範囲内でリソースを利用する。

例えば、サーバ１の作成したＡＰＬグループが、管理用アプリケーション等、重要度が比較的高いアプリケーションのＡＰＬグループＡと、３ｒｄパーティの開発したアプリケーション等、重要度が比較的低いアプリケーションとのＡＰＬグループＢとである場合を考える。

この場合、ＡＰＬグループＢの一部のアプリケーション（コンテナ）がリソースを大量に利用した場合でも、ＡＰＬグループＢは、ＡＰＬグループＢ全体としてのリソース利用量が割り当てリソース量以内となるようリソースを利用する。例えば、サーバ１は、ＡＰＬグループＢのアプリケーションが必要とするリソースに対するオーバーコミットを行うことでＡＰＬグループＢ全体としてのリソース利用量が割り当てリソース量以内となるようにする。その結果、サーバ１は、ＡＰＬグループＢの一部のアプリケーション（コンテナ）がリソースを大量に利用した場合でも、重要度が比較的高いアプリケーションに影響が及ばないようにすることができる。

ハードウェア１１は、サーバ１の備えるＣＰＵやメモリ、ハードディスク、通信インタフェース、入出力インタフェース等である。

コンテナ制御部１２は、コンテナに対する各種制御を行う。例えば、コンテナ制御部１２は、リソース管理部１３のリソース管理情報１３１（詳細は後記）を参照して、コンテナ（アプリケーション）それぞれに、当該コンテナの割り当てリソース量を設定する。なお、各コンテナがＡＰＬグループにグルーピングされた後は、コンテナ制御部１２は、リソース管理情報１３１を参照して、ＡＰＬグループそれぞれに、当該ＡＰＬグループの割り当てリソース量を設定する。

リソース管理部１３は、コンテナそれぞれの重要度に基づき、コンテナをＡＰＬグループにグルーピングし、ＡＰＬグループのそれぞれのリソース割り当て量を管理する。このリソース管理部１３は、リソース管理情報１３１と、リソース割当部１３２と、リソース監視部１３３と、リソース再割当部１３４とを備える。

リソース管理情報１３１は、コンテナごとに、当該コンテナの割り当てリソース量と、当該コンテナの属するＡＰＬグループと、当該ＡＰＬグループの割り当てリソース量とを示した情報である。

例えば、図２に示すリソース管理情報１３１は、コンテナの識別情報と、当該コンテナの割り当てリソース量と、当該コンテナ（アプリケーション）の重要度と、当該コンテナの属するＡＰＬグループと、当該ＡＰＬグループの割り当てリソース量とを対応付けた情報である。このリソース管理情報１３１は、サーバ１の備える記憶部（図示省略）に記憶される。

リソース割当部１３２は、コンテナそれぞれの重要度に基づき、コンテナをＡＰＬグループにグルーピングし、重要度の高いアプリケーションのグループ（ＡＰＬグループ）から優先的にリソースの割り当てを行う。具体的には、まず、リソース割当部１３２は、サーバ１のユーザ等から、アプリケーションそれぞれの重要度と、当該重要度のアプリケーションに割り当てたいリソース量（要求リソース量）との入力を受け付ける。次に、リソース割当部１３２は、入力されたアプリケーションそれぞれの重要度に基づき、アプリケーションのコンテナを２以上のＡＰＬグループにグルーピングする。

例えば、リソース割当部１３２は、アプリケーションの重要度が同一または類似であり、かつ、当該アプリケーションが重点的に利用するリソースの種類の異なるアプリケーションのコンテナ同士を同じＡＰＬグループにグルーピングする。

一例を挙げると、リソース割当部１３２は、重要度が同一または類似するアプリケーションのコンテナうち、メモリ使用量の多いアプリケーションのコンテナとＣＰＵ使用率の高いアプリケーションのコンテナとを、同じＡＰＬグループにグルーピングする。これにより、同じＡＰＬグループに属するコンテナのアプリケーション同士が、当該ＡＰＬグループに割り当てられたリソースを奪い合わないので、効率のよいリソース割り当てを行うことができる。

また、リソース割当部１３２は、重要度の高いＡＰＬグループから優先的に、要求リソース量のリソースを割り当てる。

例えば、リソース割当部１３２は、重要度の高いＡＰＬグループには、ユーザからの要求リソース量どおりのリソース量を割り当てるが、重要度の低いＡＰＬグループには、ユーザからの要求リソース量の８割程度のリソース量を割り当てる。

つまり、リソース割当部１３２は、重要度の高いＡＰＬグループほど、ユーザの要求リソース量に対する、当該ＡＰＬグループへの実際の割り当てリソース量の割合を高くし、重要度の低いＡＰＬグループほど、ユーザの要求リソース量に対する、当該ＡＰＬグループへの実際の割り当てリソース量の割合を低くする。

リソース割当部１３２は、上記のようにして各ＡＰＬグループのコンテナの割り当てリソース量を決定すると、決定した割り当てリソース量をリソース管理情報１３１（図２参照）に記録する。

リソース監視部１３３は、各ＡＰＬグループのコンテナのリソース利用量を監視し、各ＡＰＬグループにリソースの再割り当て（再分配）が必要か否かを判定する。

例えば、リソース監視部１３３は、各ＡＰＬグループのリソース利用量を監視した結果、優先度の高いＡＰＬグループＡにおけるリソース利用率（割り当てリソース量に対するリソース利用量の割合）が所定値（例えば、８０％）以上であった場合を考える。この場合、リソース監視部１３３は、優先度の低いＡＰＬグループＢに余剰リソースがあれば、リソースの再割り当て（再分配）を行う必要があると判定する。そして、リソース監視部１３３は、リソース再割当部１３４に、ＡＰＬグループＢにおける割り当てリソース量の一部（例えば、当該ＡＰＬグループＢの割り当てリソース量の２０％）を、ＡＰＬグループＡへ割り当てるよう指示する。

リソース再割当部１３４は、リソース監視部１３３からの指示に従い、ＡＰＬグループ間でのリソースの再割り当てを行う。例えば、リソース再割当部１３４に、リソース監視部１３３からの指示に従い、優先度が低く余剰リソースのあるＡＰＬグループＢの割り当てリソース量の一部を、優先度が高くリソース利用率が所定値以上のＡＰＬグループＡへ割り当てる。具体的には、リソース再割当部１３４は、リソース管理情報１３１におけるＡＰＬグループＢの割り当てリソース量の一部を減らし、減らした分のリソース量をＡＰＬグループＡに割り当てる。

以上説明したサーバ１によれば、重要度（優先度）の高いアプリケーションにおけるリソース不足を防止し、かつ、リソースの利用効率を向上させることができる。

なお、上記の例では、サーバ１が、優先度の低いＡＰＬグループＢの余剰リソースを、優先度の高いＡＰＬグループＡへ割り当てる（リソース移動を行う）場合について説明したが、これに限定されない。例えば、サーバ１は、優先度の低いＡＰＬグループＢのリソース利用率が所定値以上となった場合、優先度の高いＡＰＬグループＡの余剰リソースをＡＰＬグループＢに割り当ててもよい。この場合、優先度の高いＡＰＬグループＡの余剰リソースが、当該ＡＰＬグループＡの割り当てリソース量の３０％以上あること等の条件を設ける。このようにすることで、優先度の高いＡＰＬグループの余剰リソースを確保しつつ、優先度の低いＡＰＬグループのリソース不足を防止することができる。

次に、サーバ１の処理手順を説明する。まず、図３を用いて、サーバ１の処理手順の概要を説明する。

まず、サーバ１のリソース割当部１３２は、アプリケーション（コンテナ）をグルーピングする（Ｓ１）。これにより、ＡＰＬグループが複数個作成される。その後、リソース監視部１３３は、各ＡＰＬグループのリソース利用量を監視し（Ｓ２）、リソースの再割り当てが必要と判定した場合（Ｓ３でＹｅｓ）、リソース再割当部１３４は、各ＡＰＬグループのリソースの再割り当てを行う（Ｓ４）。一方、リソース監視部１３３が、リソースの再割り当てが不要と判定した場合（Ｓ３でＮｏ）、Ｓ２の処理へ戻る。

次に、図４を用いて、図３のＳ１の処理を、具体例を交えながら詳細に説明する。

例えば、サーバ１のリソース割当部１３２は、ＡＰＬグループを複数個作成する（Ｓ１１）。例えば、リソース割当部１３２は、アプリケーションの重要度：高、アプリケーションの重要度：中、アプリケーションの重要度：低の３つのＡＰＬグループを作成する。その後、リソース割当部１３２は、サーバ１のユーザ等から、起動するアプリケーション（コンテナ）と、当該アプリケーションの重要度および要求リソース量との入力を受け付ける（Ｓ１２）。

次に、リソース割当部１３２は、Ｓ１２で受け付けた要求リソース量に任意の倍率をかけたリソース量を各ＡＰＬグループに割り当て、起動させる（Ｓ１３）。例えば、リソース割当部１３２は、Ｓ１２で受け付けた重要度に対応するＡＰＬグループを特定する。そして、リソース割当部１３２は、当該ＡＰＬグループの割り当てリソース量について、Ｓ１２で受け付けた要求リソース量＊任意のかけ率（例えば、アプリケーションの重要度：高ならば「１．０」、アプリケーションの重要度：中ならば「０．８」等）分、増加させる。その後、リソース割当部１３２は、Ｓ１２で入力されたアプリケーションを、Ｓ１２で入力された重要度のＡＰＬグループとして起動させる。なお、上記の任意のかけ率は、Ｓ１２で入力されたアプリケーションの重要度が高いほど高い値とし、アプリケーションの重要度が引くほど低い値とする。この任意のかけ率の値は、ユーザが設定可能である。

このようにすることで、サーバ１は、各アプリケーション（コンテナ）の重要度に応じ、各アプリケーションをＡＰＬグループにグルーピングできる。また、サーバ１は、重要度の高いアプリケーションのＡＰＬグループから優先的に、リソースの割り当てを行うことができる。その結果、サーバ１は、重要度の高いアプリケーションにおけるリソース不足を防止することができる。

次に、図５を用いて、図３のＳ２およびＳ３の処理を、具体例を交えながら詳細に説明する。

まず、サーバ１のリソース監視部１３３は、各ＡＰＬグループのリソース利用量を監視する（Ｓ２１）。例えば、リソース監視部１３３は、各ＡＰＬグループのリソース利用量を定期的に監視する。そして、リソース監視部１３３が、リソース利用率が所定値（例えば、８０％）以上のＡＰＬグループが存在し、かつ、余剰リソースのある（例えば、リソース利用率が５０％以下の）ＡＰＬグループが存在する場合（Ｓ２２でＹｅｓ）、リソース再割当部１３４に対してリソースの再割り当てを要求する（Ｓ２３）。

例えば、リソース再割当部１３４に対して、余剰リソースのあるＡＰＬグループの割り当てリソース量の一部（例えば、当該ＡＰＬグループの割り当てリソース量の２０％）を、リソース利用率が所定値（例えば、８０％）以上のＡＰＬグループに割り当てるよう要求する。そして、Ｓ２１の処理へ戻る。

一方、リソース監視部１３３が、リソース利用率が所定値以上のＡＰＬグループがない場合、または、リソース利用率が所定値以上のＡＰＬグループがあったとしても、余剰リソースのあるＡＰＬグループが存在しない場合（Ｓ２２でＮｏ）、リソース再割当部１３４に対してリソースの再割り当ては要求せず、Ｓ２１の処理へ戻る。

次に、図６を用いて、図３のＳ４の処理を、具体例を交えながら詳細に説明する。サーバ１のリソース再割当部１３４は、リソース監視部１３３からリソースの再割り当ての要求を受け付けると（Ｓ４１でＹｅｓ）、リソース管理情報１３１を参照して、リソースの再割り当てが可能か否かを判定する（Ｓ４２）。例えば、リソース再割当部１３４は、リソース管理情報１３１を参照して、余剰リソースのあるＡＰＬグループの割り当てリソース量の一部（例えば、当該ＡＰＬグループの割り当てリソース量の２０％）を、リソース利用率が所定値（例えば、８０％）以上のＡＰＬグループに割り当てることができるか否かを判定する。

Ｓ４２において、リソース再割当部１３４が、リソースの再割り当てが可能と判定した場合（Ｓ４２でＹｅｓ）、リソースの再割り当てを実行する（Ｓ４３）。つまり、リソース再割当部１３４は、リソース管理情報１３１におけるＡＰＬグループ間の割り当てリソース量を変更する。例えば、リソース再割当部１３４は、リソース管理情報１３１における、余剰リソースのあるＡＰＬグループの割り当てリソース量の一部を減らし、減らした分の割り当てリソース量を、リソース利用率が所定値以上のＡＰＬグループの割り当てリソース量に加算する。なお、ここでは図示を省略しているが、Ｓ４３の後、コンテナ制御部１２は、更新後のリソース管理情報１３１に基づき、各ＡＰＬグループの割り当てリソース量の設定を行う。

また、リソース再割当部１３４は、リソース監視部１３３からリソースの再割り当ての要求を受け付けなかった場合（Ｓ４１でＮｏ）、または、Ｓ４２でリソースの再割り当てが不可能と判定した場合（Ｓ４２でＮｏ）、処理を終了する。

このようにすることで、サーバ１は、いずれかのＡＰＬグループにおいてリソース不足が発生した場合、余剰リソースのあるＡＰＬグループのリソースを割り当てることができる。その結果、サーバ１は各アプリケーションのリソース不足を防止し、かつ、リソースの利用効率を向上させることができる。

なお、リソース管理部１３は、サーバ１に装備される場合を例に説明したが、これに限定されない。例えば、リソース管理部１３を、サーバ１とは別個の装置により実現してもよい。この場合、リソース管理部１３は、ネットワーク経由で、サーバ１のリソースの管理を行えばよい。

（プログラム）
また、各実施形態で述べたサーバ１の機能を実現するプログラムを所望の情報処理装置（コンピュータ）にインストールすることによって実装できる。例えば、パッケージソフトウェアやオンラインソフトウェアとして提供される上記のプログラムを情報処理装置に実行させることにより、情報処理装置をサーバ１として機能させることができる。ここで言う情報処理装置には、デスクトップ型またはノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはスマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）等の移動体通信端末、さらには、ＰＤＡ（Personal Digital Assistants）等がその範疇に含まれる。また、サーバ１を、クラウドサーバに実装してもよい。

図７を用いて、上記のプログラム（リソース管理プログラム）を実行するコンピュータの一例を説明する。図７に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１およびＲＡＭ（Random Access Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。

ここで、図７に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。前記した実施形態で説明した各種データや情報は、例えばハードディスクドライブ１０９０やメモリ１０１０に記憶される。

そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。

なお、上記のリソース管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、上記のプログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮやＷＡＮ（Wide Area Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１サーバ
１１ハードウェア
１２コンテナ制御部
１３リソース管理部
１３１リソース管理情報
１３２リソース割当部
１３３リソース監視部
１３４リソース再割当部

Claims

サーバ上で動作する複数のアプリケーションに対するリソース割り当て量を管理するリソース管理装置において実行されるリソース管理方法であって、
前記アプリケーションそれぞれの重要度を受け付ける受け付けステップと、
前記受け付けた重要度に応じて、前記アプリケーションを２以上のグループにグルーピングするグルーピングステップと、
前記重要度の高いアプリケーションのグループから優先的にリソースを割り当てるリソース割り当てステップと、
前記グループそれぞれのアプリケーションのリソース利用量を監視する監視ステップと、
前記監視の結果、いずれかのグループにおいて割り当てリソース量に対する前記リソース利用量であるリソース利用率が所定値以上となった場合、余剰リソースを持つグループのリソース割り当て量の少なくとも一部を、前記リソース利用率が前記所定値以上のグループに割り当てるリソース再割り当てステップと、
を含んだことを特徴とするリソース管理方法。
前記リソース割り当てステップにおいて、さらに、
前記重要度が高いアプリケーションのグループほど、前記アプリケーションのグループに対する割り当てリソース量を多くし、前記重要度が低いアプリケーションのグループほど、前記アプリケーションのグループに対する割り当てリソース量を少なくする
ことを特徴とする請求項１に記載のリソース管理方法。
前記リソース割り当てステップにおいて、
前記アプリケーションそれぞれの重要度が類似しており、かつ、当該アプリケーションそれぞれが重点的に利用するリソースの種類が異なるアプリケーション同士を同じグループにグルーピングする
ことを特徴とする請求項１に記載のリソース管理方法。
前記アプリケーションは、コンテナ仮想化技術により、当該アプリケーションが利用可能なリソースが隔離されている
ことを特徴とする請求項１に記載のリソース管理方法。