JP6089783B2 - 制御装置、リソース制御プログラムおよびリソース制御方法 - Google Patents

Description

本発明は、制御装置、リソース制御プログラムおよびリソース制御方法に関する。

従来、データセンタ等の計算機システムが、計算機リソースを顧客に対して提供する技術が知られている。このような技術の一例として、顧客が実行するアプリケーションの負荷に応じて、顧客に対して提供する計算機リソースの量を変更する技術が知られている。

例えば、顧客に対して提供する計算機リソースを提供する計算機システムは、顧客が実行するアプリケーションが使用するメモリの量やアプリケーションを実行する際のＣＰＵ（Central Processing Unit）使用率等の負荷を計測する。そして、計算機システムは、計測した負荷が所定の閾値を超えた場合は、顧客に対して提供する計算機リソースにあらかじめ設定された量の計算機リソースを追加する。

特開２００４−３１８４７４号公報 特開２００５−１７３９２８号公報

しかしながら、上述した閾値を用いて顧客に提供する計算機リソースを変更させる技術では、アプリケーションの負荷が急に変化した際に、顧客に提供する計算機リソースの量を負荷の変化に追従させることができないという問題がある。

例えば、アプリケーションの負荷が指数関数的に増加した場合は、計算機リソースの追加がアプリケーションの負荷の増加に追従できない場合がある。この結果、アプリケーションの実行に支障が発生する場合がある。

本願は、上述した問題に鑑みてなされたものであり、１つの側面では、アプリケーションの負荷に対して計算機リソースを短時間で追従させることを目的とする。

１つの側面では、アプリケーションを実行する際に利用するリソース量を制御する制御装置である。また、制御装置は、アプリケーションを実行する情報処理装置から、アプリケーションを実行する際の負荷を示す負荷情報を収集する。また、制御装置は、収集した負荷情報が示す負荷が所定の閾値を超えているか否かを判定する。また、制御装置は、負荷が所定の閾値を超えていると判定した場合は、収集した負荷情報と、過去に収集した負荷情報とを用いて、アプリケーションを実行する際の負荷の増減量を算出する。そして、制御装置は、算出した増減量に基づいて、アプリケーションに割当るリソース量を決定する。

１つの側面では、アプリケーションの負荷に対して計算機リソースを短時間で追従させることができる。

図１は、実施例１に係る情報処理システムを説明する図である。 図２は、サービス提供サーバの機能構成を説明する図である。 図３は、空きＡＰＬ番号テーブルの一例を説明する図である。 図４は、メモリ管理テーブルの一例を説明する図である。 図５は、アドレス関係テーブルの一例を説明する図である。 図６は、サービス関係テーブルの一例を説明する図である。 図７は、ＡＰＬ負荷計測部が計測するデータの一例を説明する図である。 図８は、変更依頼の一例を説明する図である。 図９は、リソース割当制御サーバの機能構成を説明する図である。 図１０は、負荷状況テーブルの一例を説明する図である。 図１１は、閾値の一例を説明する図である。 図１２は、実施例１に係る情報処理システムが実行する処理の流れを説明するためのシーケンス図である。 図１３は、実施例２に係るリソース割当制御サーバの機能構成を説明する図である。 図１４は、負荷状況テーブルのバリエーションを説明する図である。 図１５は、実施例２に係る情報処理システムが実行する処理の流れを説明するためのシーケンス図である。 図１６は、実施例３に係るサービス提供サーバの機能構成を説明する図である。 図１７は、実施例３に係るサービス関係テーブルの一例を説明する図である。 図１８は、実施例３に係る情報処理システムが実行する処理の流れを説明するためのシーケンス図である。 図１９は、実施例３に係るサービス関係テーブルのバリエーションを説明する図である。 図２０は、実施例３に係る情報処理システムが実行する処理のバリエーションを説明するためのシーケンス図である。 図２１は、リソース制御プログラムを実行するコンピュータを説明する図である。

以下に添付図面を参照して本願に係る制御装置、リソース制御プログラムおよびリソース制御方法の実施例を図面に基づいて詳細に説明する。なお、この実施例により開示技術が限定されるものではない。また、各実施例は、矛盾しない範囲で適宜組みあわせてもよい。

以下の実施例１では、図１を用いて、本願に係る制御サーバを含む情報処理システム１を説明する。図１は、実施例１に係る情報処理システムを説明する図である。図１に示す例では、情報処理システム１は、利用者端末２、ＩＳＰ（Internet Service Provider）３、サービス提供者端末４、ＩＳＰ５、インターネット６、データセンタ１０を有する。また、データセンタ１０は、複数のサービス提供サーバ１１〜１３、リソース割当制御サーバ１４を有する。また、図１に示す例では、利用者端末２は、ＩＳＰ３、インターネット６を介して、データセンタ１０に接続する。また、サービス提供者端末４は、ＩＳＰ５、インターネット６を介して、データセンタ１０に接続する。

なお、データセンタ１０は、サービス提供サーバ１１〜１３以外にも、複数のサービス提供サーバを有するものとする。またＩＳＰ３、５は、利用者端末２や、サービス提供者端末４をインターネット６に接続するサービスを提供するインターネット接続業者のネットワークである。また、サービス提供サーバ１２、１３は、サービス提供サーバ１１と同様の機能を発揮するものとして、以下の説明を省略する。

利用者端末２は、ＩＳＰ３、およびインターネット６を介して、データセンタ１０が有する各サービス提供サーバ１１〜１３が実行するサービスの提供を受ける端末である。また、サービス提供者端末４は、利用者端末２に対して提供されるサービスの提供元が有する端末である。

例えば、サービス提供者端末４は、利用者端末２に対して各種サービスを提供するためのアプリケーションの実行をデータセンタ１０に対して指示する。このような場合は、データセンタ１０は、指示に従ってアプリケーションを稼動させ、利用者端末２に対してサービスの提供を行う。

サービス提供サーバ１１〜１３は、利用者端末２に対して各種サービスを提供するためのアプリケーションや仮想マシンを稼動させる。例えば、サービス提供サーバ１１〜１３は、サービス提供者端末４からの指示に従って、サービスを提供するための１つ以上のアプリケーションを実行する。そして、サービス提供サーバ１１は、アプリケーションの実行結果を利用者端末２に提供する。

また、サービス提供サーバ１１は、各アプリケーションに対し、リソース割当制御サーバ１４が設定するリソース量を割当てて実行する。ここで、リソース量とは、アプリケーション実行する際に使用するリソースの量であり、例えば、アプリケーションに割当てられたメモリ量、実行するアプリケーションの数、アプリケーションを実行するＶＭ（仮想マシン：Virtual Machine）の数である。

ここで、アプリケーションを実行する際にサービス提供サーバ１１が利用する計算機リソース、すなわちアプリケーションを実行する際の負荷は、アプリケーションが提供するサービスの内容やサービスの提供対象となる利用者端末の数により変化する。しかしながら、このような負荷が所定の閾値を超えた際に所定量のリソースを追加したとしても、例えば指数関数的に増加した負荷に対して、割当てるリソース量を追従させることができない。

そこで、リソース割当制御サーバ１４は、負荷の増減量に基づいて、アプリケーションを実行する際に必要なリソースの量を予測し、予測した量のリソースを割当てる。詳細には、リソース割当制御サーバ１４は、各サービス提供サーバ１１〜１３が実行するアプリケーションごとに、アプリケーションを実行する際の負荷を収集する。また、リソース割当制御サーバ１４は、収集した負荷を記憶する。

また、リソース割当制御サーバ１４は、アプリケーションを実行する際の負荷の増減量を算出する。そして、リソース割当制御サーバ１４は、算出した負荷の増減量に基づいて、アプリケーションに割当てるリソース量を算出し、算出したリソース量を各サービス提供サーバ１１〜１３に通知することで、リソース量の追加や減少を行う。この結果、リソース割当制御サーバ１４は、例えば、アプリケーションを実行する際の負荷が指数関数的に増加した際にも、アプリケーションに対して割当てるリソース量を付加に追従させることができる。

次に、図２を用いて、サービス提供サーバ１１の機能構成について説明する。図２は、サービス提供サーバの機能構成を説明する図である。図２に示すように、サービス提供サーバ１１は、通信部２０、ＡＰＬ（Application）負荷計測部２１、振分け部２２、記憶部２３、リソース制御部２４、使用中リソース２５、残余リソース２６を有する。また、記憶部２３は、空きＡＰＬ番号テーブル２７、メモリ管理テーブル２８、アドレス関係テーブル２９、サービス関係テーブル３０を記憶する。

また、リソース制御部２４は、リソース管理部３１、テーブル管理部３２を有する。また、使用中リソース２５には、メモリ３３とＣＰＵ（Central Processing Unit）３７が含まれる。ここで、メモリ３３には実行中アプリケーション３４として、複数のサービスＡＰＬ３５、３６が含まれる。また、残余リソース２６には、メモリ３８が含まれる。なお、図２では記載を省略したが、サービス提供サーバ１１は、サービスＡＰＬ３５、３６以外にも、様々なサービスＡＰＬを実行しているものとする。

また、使用中リソース２５とは、サービス提供サーバ１１が各サービスＡＰＬ３５、３６を実行するために使用中の計算機リソースである。例えば、メモリ３３とは、使用中リソース２５に、サービスＡＰＬ３５、３６に割当てられたメモリ領域である。また、ＣＰＵ３７は、サービスＡＰＬ３５、３６を実行する演算処理装置である。一方、残余リソース２６とは、サービス提供サーバ１１が有する計算機リソースのうち、サービスＡＰＬ３５、３６に割当てられていない計算機リソースである。例えば、メモリ３８は、各サービスＡＰＬ３５、３６に割当てられていない、すなわち使用されていないメモリ領域である。

まず、図３〜６を用いて、記憶部２３が記憶する各テーブル２７〜３０に格納される情報の内容について説明する。まず、図３を用いて、空きＡＰＬ番号テーブルの一例について説明する。図３は、空きＡＰＬ番号テーブルの一例を説明する図である。図３に示すように、空きＡＰＬ番号テーブルは、サービス提供サーバ１１が実行する１つ以上のサービスＡＰＬに対して割当てられていないＡＰＬ番号を記憶する。

すなわち、サービス提供サーバ１１は、実行中のサービスＡＰＬに対してＡＰＬ番号を割当てており、実行中のサービスＡＰＬに対して割当てていないＡＰＬ番号を空きＡＰＬ番号テーブル２７にプールする。例えば、図３に示す例では、空きＡＰＬ番号テーブル２７には、ＡＰＬ番号「５」、「６」…がプールされている。

次に、図４を用いて、メモリ管理テーブル２８の一例について説明する。図４は、メモリ管理テーブルの一例を説明する図である。例えば、メモリ管理テーブル２８には、図４中（ａ）に示す、サービス提供サーバ１１が有するメモリ全体に係る情報と、図４中（ｂ）に示すように、サービス提供サーバ１１が実行する各サービスＡＰＬに割当てられたメモリ量とが格納されている。

例えば、メモリ管理テーブル２８には、図４中（ａ）に示すように、サービス提供サーバ１１が有する全メモリ量を示すサーバ全体メモリ量「１０００００ＧＢ（ギガバイト）」が格納されている。また、メモリ管理テーブル２８には、サーバ全体の空きメモリ量を示すサーバ全体空きメモリ量「４８０５５ＧＢ」が格納されている。

また、メモリ管理テーブル２８には、図４中（ｂ）に示すように、サービス提供サーバ１１が実行するサービスＡＰＬに付与されたサービスＡＰＬ番号とサービスＡＰＬに割当てられたメモリ量を示す使用メモリ量とが対応付けて格納されている。例えば、メモリ管理テーブル２８は、サービスＡＰＬ番号「１」のサービスＡＰＬに「１５ＧＢ」のメモリが割当てられ、サービスＡＰＬ番号「２」のサービスＡＰＬに「１０ＧＢ」のメモリが割当てられている旨を示す。

次に、図５を用いて、アドレス関係テーブル２９の一例について説明する。図５は、アドレス関係テーブルの一例を説明する図である。図５に示す例では、アドレス関係テーブル２９には、サービスＡＰＬ番号、プロセスＩＤ、Ｍａｃ（Media Access Control）アドレス、ＩＰ（Internet Protocol）アドレスが対応付けて格納されている。ここで、プロセスＩＤとは、サービスＡＰＬの起動時に割当てられた識別子である。例えば、サービス提供サーバ１１が有するＣＰＵは、プロセスＩＤを用いて、実行するサービスＡＰＬの指定を行う。また、Ｍａｃアドレス、およびＩＰアドレスは、サービスＡＰＬからサービスの提供を受けるため、利用者端末２がサービスＡＰＬにアクセスする際に用いるＭａｃアドレス、およびＩＰアドレスである。

例えば、図５に示す例では、アドレス関係テーブル２９は、サービスＡＰＬ番号「１」のサービスＡＰＬには、プロセスＩＤ「１２３４５６」が割当てられている旨を示す。また、アドレス関係テーブル２９は、サービスＡＰＬ番号「１」のサービスＡＰＬに対し、Ｍａｃアドレス「００−１２−３４−５６−７８−９０」およびＩＰアドレス「１２３．４５．６７．８９」でアクセス可能である旨を示す。

次に、図６を用いて、サービス関係テーブル３０の一例について説明する。図６は、サービス関係テーブルの一例を説明する図である。図６に示す例では、サービス関係テーブル３０には、サービスＡＰＬ ＩＤ、サービスＡＰＬファイル所在、サービスＡＰＬ番号が対応付けて格納されている。ここで、サービスＡＰＬ ＩＤとは、サービス提供サーバ１１が提供するサービスの種別を示す識別子である。

また、サービスＡＰＬファイル所在とは、サービスを提供するためのサービスＡＰＬの所在を示す情報であり、例えば、図示を省略した記憶装置においてサービスＡＰＬが格納されたアドレスである。また、図６に示すように、サービス関係テーブル３０には、サービスＡＰＬ ＩＤが示すサービスを提供するために動作するサービスＡＰＬに割当てられたサービスＡＰＬ番号が、実行された順番を示すナンバーとともに格納される。

例えば、図６に示す例では、サービス関係テーブル３０は、サービスＡＰＬ ＩＤ「１」が示すサービスを提供するためのサービスＡＰＬが「／ｓｅｒｖｉｃｅ／ＡＰＬ／ｌｏｇｉｎ」に格納されている旨を示す。また、サービス関係テーブル３０は、サービスＡＰＬ ＩＤ「１」が示すサービスを提供するため、サービスＡＰＬ番号「１」のサービスＡＰＬとサービスＡＰＬ番号「５」のサービスＡＰＬとが実行される旨を示す。すなわち、サービスＡＰＬ番号「１」のサービスＡＰＬとサービスＡＰＬ番号「５」のサービスＡＰＬとは、サービスＡＰＬ ＩＤ「１」が示すサービスを提供するために連携して動作するサービスＡＰＬである。

また、図６に示す例では、サービス関係テーブル３０は、サービスＡＰＬ ＩＤ「２」が示すサービスを提供するためのサービスＡＰＬが「／ｓｅｒｖｉｃｅ／ＡＰＬ／ｃａｒｔ」に格納されている旨を示す。また、サービス関係テーブル３０は、サービスＡＰＬ ＩＤ「２」が示すサービスを提供するため、サービスＡＰＬ番号「２」のサービスＡＰＬが実行される旨を示す。

図２に戻り、通信部２０は、サービス提供サーバ１１と、利用者端末２、サービス提供者端末４、リソース割当制御サーバ１４との通信を制御する。また、ＡＰＬ負荷計測部２１は、所定の時間間隔で、サービス提供サーバ１１が実行する各サービスＡＰＬ３５、３６を実行する際の負荷を計測する。そして、ＡＰＬ負荷計測部２１は、負荷情報をリソース割当制御サーバ１４に対して送信する。

ここで、図７を用いて、ＡＰＬ負荷計測部２１が計測する負荷の一例について説明する。図７は、ＡＰＬ負荷計測部が計測するデータの一例を説明する図である。例えば、ＡＰＬ負荷計測部２１は、各サービスＡＰＬ３５、３６を実行する際のＣＰＵ使用率とメモリ使用率とを測定する。ここで、ＣＰＵ使用率とは、ＣＰＵ３７が各サービスＡＰＬ３５、３６の処理を実行している時間の割合を示す情報である。また、メモリ使用率とは、各サービスＡＰＬ３５、３６に割当てられたメモリ量のうち、実際に使用されているメモリ量の割合を示す情報である。

例えば、ＡＰＬ負荷計測部２１は、各サービスＡＰＬ３５、３６によるＣＰＵ使用率とメモリ使用率とを測定する。また、ＡＰＬ負荷計測部２１は、各サービスＡＰＬ３５、３６に割当てられたメモリ量を識別する。そして、ＡＰＬ負荷計測部２１は、測定したＣＰＵ使用率およびメモリ使用率とともに、負荷を計測した計測日時と各サービスＡＰＬのサービスＡＰＬ番号と各サービスＡＰＬに割当てられたメモリ量とを対応付けた負荷情報をサービス提供サーバ１１に通知する。

例えば、ＡＰＬ負荷計測部２１は、図７に示すように、サービスＡＰＬ番号「１」、計測日時「２０１２／１２／１０ １２：３４：５５」、ＣＰＵ使用率「８０％」、メモリ使用率「９０％」とを対応付けた負荷情報を生成する。そして、ＡＰＬ負荷計測部２１は、生成した負荷情報に、サービスＡＰＬ番号「１」が示すサービスＡＰＬのメモリ使用量を含め、通信部２０を介して、生成した負荷情報をリソース割当制御サーバ１４に送信する。

また、ＡＰＬ負荷計測部２１は、サービスＡＰＬ番号「２」、計測日時「２０１２／１２／１０ １２：３４：５２」、ＣＰＵ使用率「４０％」、メモリ使用率「３５％」を対応付けてリソース割当制御サーバ１４に通知する。また、ＡＰＬ負荷計測部２１は、サービスＡＰＬ番号「３」、計測日時「２０１２／１２／１０ １２：３４：５４」、ＣＰＵ使用率「６５％」、メモリ使用率「５０％」を対応付けてリソース割当制御サーバ１４に通知する。

図２に戻り、振分け部２２は、アドレス関係テーブル２９、およびサービス関係テーブル３０を用いて、利用者端末２からのリクエストの振分けを行うロードバランサである。例えば、振分け部２２は、サービスＡＰＬ ＩＤ「１」が示すサービスの提供を開始するよう要求するリクエストを受信する。

このような場合には、振分け部２２は、サービス関係テーブル３０を参照し、サービスＡＰＬ ＩＤ「１」が示すサービスをサービスＡＰＬ番号「１」のサービスとサービスＡＰＬ番号「５」のサービスＡＰＬとが提供する旨を識別する。そして、振分け部２２は、サービスＡＰＬ番号「１」のサービスＡＰＬとサービスＡＰＬ番号「５」のサービスＡＰＬとでサービスの提供を行う利用者端末の数がほぼ均等となるように、サービスの提供を行うサービスＡＰＬを選択する。

また、振分け部２２は、利用者端末２に対するサービスの提供が開始されると、アドレス関係テーブル２９を用いて、選択したサービスＡＰＬと利用者端末２との間で発生するデータの送受信を制御する。

リソース制御部２４は、サービス提供サーバ１１が有する使用中リソース２５および残余リソースの制御を行う。例えば、リソース管理部３１は、通信部２０を介して、リソース割当制御サーバ１４から、各サービスＡＰＬ３５、３６に対して割当てるリソース量の変更を指示する変更依頼を受信する。すると、リソース管理部３１は、受信した変更依頼に従って、各サービスＡＰＬ３５、３６に対して割当てるリソース量を変更する。そして、リソース管理部３１は、変更内容をテーブル管理部３２に通知する。

例えば、図８は、変更依頼の一例を説明する図である。図８に示すように、変更依頼は、サービスＡＰＬ番号、ＡＰＬ増加／減少数、メモリ増加／減少量とが対応付けて格納されている。例えば、リソース管理部３１は、変更依頼として、サービスＡＰＬ番号「１」とＡＰＬ増加／減少数「＋１」とが対応付けられている場合は、サービスＡＰＬ番号「１」が示すサービスＡＰＬと同一のサービスＡＰＬを追加で起動させる。そして、リソース管理部３１は、追加したサービスＡＰＬに対して、すでに起動済みのサービスＡＰＬに割当てられたメモリ量と同じメモリ量を割当る。

また、リソース管理部３１は、変更依頼として、サービスＡＰＬ番号「１」とメモリ増加／減少量「＋１３．５ＧＢ」とが対応付けられている場合は、サービスＡＰＬ番号「１」が示すサービスＡＰＬに割当てられたメモリ量を「１３．５ＧＢ」追加する。

なお、例えば、リソース管理部３１は、サービスＡＰＬ番号「１」とＡＰＬ増加／減少数「−１」とが対応付けられている場合は、サービスＡＰＬ番号「１」が示すサービスＡＰＬと同一のサービスＡＰＬを１つ終了させる。また、例えば、リソース管理部３１は、サービスＡＰＬ番号「１」とメモリ増加／減少量「−１３．５ＧＢ」とが対応付けられている場合は、サービスＡＰＬ番号「１」が示すサービスＡＰＬに割当てられたメモリ量を「１３．５ＧＢ」減少させる。

また、リソース管理部３１は、サービスＡＰＬを追加する場合は、追加するサービスＡＰＬが使用する空きメモリが存在するかをメモリ管理テーブル２８から判定し、追加するサービスＡＰＬが使用する空きメモリを確保してからサービスＡＰＬを起動してもよい。また、例えば、リソース管理部３１は、サービスＡＰＬを追加する場合は、追加するサービスＡＰＬが使用する空きメモリが存在しない場合は、エラーの通知、もしくは、他のサービス提供サーバ１２、１３に対して、サービスＡＰＬの追加実行を依頼してもよい。

図２に戻って、テーブル管理部３２は、リソース管理部３１から各サービスＡＰＬ３５、３６に割当てられたリソース量の変更内容を受信すると、受信した変更内容に従って、記憶部２３が記憶する各テーブル２７〜３０の更新を行う。

例えば、テーブル管理部３２は、リソース管理部３１が実行するサービスＡＰＬを１つ追加した場合は、空きＡＰＬ番号テーブル２７に格納された空きＡＰＬ番号を１つ取得し、取得した空きＡＰＬ番号を新たに追加したサービスＡＰＬに割当てる。また、テーブル管理部３２は、取得した空きＡＰＬ番号を空きＡＰＬ番号テーブル２７から削除する。

また、テーブル管理部３２は、追加したサービスＡＰＬに割当てたＡＰＬ番号を、追加したサービスＡＰＬが提供するサービスを示すサービスＡＰＬ ＩＤと対応付けてサービス関係テーブル３０に格納する。例えば、テーブル管理部３２は、サービスＡＰＬ ＩＤが「１」のサービスを提供するサービスＡＰＬを追加し、追加したサービスＡＰＬにサービスＡＰＬ番号「５」を割当てた場合は、以下の処理を実行する。すなわち、テーブル管理部３２は、サービス関係テーブル３０からサービスＡＰＬ ＩＤが「１」のエントリを抽出し、抽出したエントリのサービスＡＰＬ番号にサービスＡＰＬ番号「５」を追加する。

また、テーブル管理部３２は、追加したサービスＡＰＬに対して割当てられたサービスＡＰＬ番号、プロセスＩＤ、Ｍａｃアドレス、ＩＰアドレスを対応付けてアドレス関係テーブル２９に格納する。ここで、テーブル管理部３２は、追加したサービスＡＰＬに対して割当てられたプロセスＩＤ、Ｍａｃアドレス、ＩＰアドレスを、サービス提供サーバ１１が実行するＯＳ等から取得する。また、テーブル管理部３２は、追加したサービスＡＰＬに対して割当てられたサービスＡＰＬ番号と、追加したサービスＡＰＬに対して割当てられたメモリ量とを対応付けてメモリ管理テーブル２８に格納する。

一方、テーブル管理部３２は、サービスＡＰＬが終了した場合は、終了したサービスＡＰＬに割当てられたサービスＡＰＬ番号をサービス関係テーブル３０から削除する。また、テーブル管理部３２は、終了したサービスＡＰＬ番号が格納されたエントリをメモリ管理テーブル２８、およびアドレス関係テーブル２９から削除する。そして、テーブル管理部３２は、終了したサービスＡＰＬに割当てられたサービスＡＰＬ番号を空きＡＰＬ番号テーブル２７に格納する。

また、テーブル管理部３２は、いずれかのサービスＡＰＬに対して割当られたメモリ量が追加、または削減された場合は、メモリ管理テーブル２８に格納されたメモリ量を更新する。例えば、テーブル管理部３２は、サービスＡＰＬ番号「１」のメモリ量が「１３．５ＧＢ」追加された場合は、メモリ管理テーブル２８にサービスＡＰＬ番号「１」と対応付けて格納されたメモリ量に「１３．５ＧＢ」を加算する。

また、テーブル管理部３２は、サービスＡＰＬの追加や削除、または、メモリ量の追加や削除が行われた場合は、サービスＡＰＬの追加・削除内容、およびメモリ量の追加・削減内容をリソース割当制御サーバ１４に送信する。

次に、図９を用いて、リソース割当制御サーバの機能構成について説明する。図９は、リソース割当制御サーバの機能構成を説明する図である。図９に示す例では、リソース割当制御サーバ１４は、記憶部４０、通信部４２、負荷状況収集部４３、リソース増減判定部４４、リソース増減量決定部４５を有する。また、記憶部４０は、負荷状況テーブル４１を記憶する。

まず、図１０を用いて、記憶部４０が記憶する負荷状況テーブル４１について説明する。図１０は、負荷状況テーブルの一例を説明する図である。図１０に示すように、負荷状況テーブルの各エントリには、サービス提供サーバ番号、サービスＡＰＬ番号、ＣＰＵ使用率、メモリ使用率、メモリ使用量が対応付けられている。

なお、サービス提供サーバ番号とは、サービス提供サーバ１１〜１３を識別するための番号であり、対応付けられたサービスＡＰＬ番号が示すサービスＡＰＬを実行するサービス提供サーバを示す番号である。また、負荷状況テーブル４１には、前回測定したＣＰＵ使用率と最新のＣＰＵ使用率、および前回測定したメモリ使用率と最新のメモリ使用率とが格納されている。

図９に戻って、通信部４２は、リソース割当制御サーバ１４と各サービス提供サーバ１１〜１３との通信を制御する。負荷状況収集部４３は、通信部４２を介して、各サービス提供サーバ１１〜１３から、負荷情報を収集する。そして、負荷状況収集部４３は、収集した負荷情報を用いて、負荷状況テーブル４１の更新を行う。

以下、負荷状況収集部４３が実行する処理の一例を説明する。なお、以下の説明では、サービス提供サーバ１１のサービス提供サーバ番号が「１」であるものとする。例えば、負荷状況収集部４３は、サービスＡＰＬ番号「１」、ＣＰＵ使用率「８０％」、メモリ使用率「９０％」、メモリ使用量「１５ＧＢ」とを対応付けた負荷情報を受信する。

このような場合には、負荷状況収集部４３は、サービス提供サーバ番号「１」とサービスＡＰＬ番号「１」が格納されたエントリを負荷状況テーブル４１から抽出する。次に、負荷状況収集部４３は、抽出したエントリに格納された前回のＣＰＵ使用率を削除し、最新のＣＰＵ使用率を前回のＣＰＵ使用率とする。また、負荷状況収集部４３は、抽出したエントリに格納された前回のメモリ使用率を削除し、最新のメモリ使用率を前回のＣＰＵ使用率とする。

続いて、負荷状況収集部４３は、サービス提供サーバ１１から受信した負荷情報のＣＰＵ使用率「８０％」を最新のＣＰＵ使用率として、抽出したエントリに格納する。また、負荷状況収集部４３は、サービス提供サーバ１１から受信した負荷情報のメモリ使用率「９０％」を最新のメモリ使用率として、抽出したエントリに格納する。また、負荷状況収集部４３は、サービス提供サーバ１１から受信したメモリ使用量「１５ＧＢ」を、新たなメモリ使用量として、抽出したエントリに格納する。

なお、負荷状況収集部４３は、サービスＡＰＬの追加・削除内容、およびメモリ使用量の追加・削減内容をサービス提供サーバ１１から受信する。このような場合は、負荷状況収集部４３は、サービスＡＰＬの追加・削除内容、およびメモリ使用量の追加・削減内容に従って、負荷状況テーブル４１の更新を行う。

リソース増減判定部４４は、負荷状況テーブル４１を参照し、各サービスＡＰＬ３５、３６の付加が所定の閾値を超えているか否かを判定する。具体的には、リソース増減判定部４４には、計算機リソースを削減するか否かを判定する削減閾値と、計算機リソースを追加するか否かを判定する追加閾値とが設定されている。

そして、リソース増減判定部４４は、例えば、サービスＡＰＬ３５を実行する際の負荷が削除閾値よりも小さい場合には、サービスＡＰＬ３５に割当る計算機リソースの削減をリソース増減量決定部４５に指示する。また、リソース増減判定部４４は、サービスＡＰＬ３５を実行する際の負荷が追加閾値よりも大きい場合には、サービスＡＰＬ３５に割当てる計算機リソースの追加をリソース増減量決定部４５に指示する。

以下、リソース増減判定部４４が実行する処理の一例について説明する。まず、図１１を用いて、リソース増減判定部４４が用いる閾値の一例について説明する。図１１は、閾値の一例を説明する図である。例えば、リソース増減判定部４４は、ＣＰＵ使用率とメモリ使用率との削減閾値、およびＣＰＵ使用率とメモリ使用率との追加閾値とを記憶する。

図１１に示す例では、リソース増減判定部４４は、ＣＰＵ使用率の削減閾値として「３０％」が設定されており、メモリ使用率の削減閾値として「３０％」が設定されている。また、リソース増減判定部４４は、ＣＰＵ使用率の追加閾値として「７０％」が設定されており、メモリ使用率の追加閾値として「７０％」が設定されている。

例えば、リソース増減判定部４４は、負荷状況テーブル４１からサービス提供サーバ番号「１」、サービスＡＰＬ番号「１」のエントリを抽出し、抽出したエントリに格納された最新のＣＰＵ使用率「８０％」を、削減閾値および追加閾値と比較する。すると、リソース増減判定部４４は、最新のＣＰＵ使用率「８０％」が追加閾値「７０％」以上であると判定する。このような場合には、リソース増減判定部４４は、リソース増減量決定部４５に対し、サービス提供サーバ番号「１」のサービスＡＰＬ番号「１」が示すサービスＡＰＬについて、同一のサービスＡＰＬを追加起動するよう指示する。

また、リソース増減判定部４４は、抽出したエントリに格納された最新のメモリ使用率「９０％」を、削減閾値および追加閾値と比較する。すると、リソース増減判定部４４は、最新のメモリ使用率「９０％」が追加閾値「７０％」以上であると判定する。このような場合には、リソース増減判定部４４は、リソース増減量決定部４５に対し、サービス提供サーバ番号「１」のサービスＡＰＬ番号「１」が示すサービスＡＰＬについて、割当てるメモリ使用量を追加するよう指示する。

なお、リソース増減判定部４４は、抽出したエントリに格納された最新のＣＰＵ使用率が削除閾値未満である場合は、以下の処理を実行する。すなわち、リソース増減判定部４４は、抽出したエントリのサービス提供サーバ番号およびサービスＡＰＬ番号が示すサービスＡＰＬの削減をリソース増減量決定部４５に指示する。

また、リソース増減判定部４４は、抽出したエントリに格納された最新のメモリ使用率が削除閾値未満である場合は、以下の処理を実行する。すなわち、リソース増減判定部４４は、抽出したエントリのサービス提供サーバ番号およびサービスＡＰＬ番号が示すサービスＡＰＬに割当られたメモリ使用量の削減を指示する。また、リソース増減判定部４４は、負荷状況テーブル４１の各エントリについて上述した処理を実行する。

図９に戻り、リソース増減量決定部４５は、各サービスＡＰＬごとに、負荷の増減量を算出し、算出した増減量に基づいて、各サービスＡＰＬに割当てる計算機リソースの量を決定する。そして、リソース増減量決定部４５は、決定した計算機リソースの量を、各サービス提供サーバ１１〜１３に対して通知する。

例えば、リソース増減量決定部４５は、サービス提供サーバ番号「１」のサービスＡＰＬ番号「１」が示すサービスＡＰＬについて、同一のサービスＡＰＬを追加起動する旨の指示をリソース増減判定部４４から受信する。このような場合には、リソース増減量決定部４５は、サービスＡＰＬ番号「１」と、ＡＰＬ増加／減少数「＋１」とを対応付けた変更依頼を生成する。

また、リソース増減量決定部４５は、サービス提供サーバ番号「１」のサービスＡＰＬ番号「１」が示すサービスＡＰＬについて、割当てるメモリ使用量を追加する旨の指示を受信する。このような場合には、リソース増減量決定部４５は、サービス提供サーバ番号が「１」でサービスＡＰＬ番号が「１」となるエントリを負荷状況テーブル４１から抽出し、抽出したエントリから前回のメモリ使用率、最新のメモリ使用率、メモリ使用量とを取得する。

そして、リソース増減量決定部４５は、最新のメモリ使用率から前回のメモリ使用率を削減した値にメモリ使用量と所定の係数、例えば「３」、とを乗算した値をメモリ増加／減少量として算出する。例えば、リソース増減量決定部４５は、サービス提供サーバ番号「１」のサービスＡＰＬ番号「１」が示すサービスＡＰＬについて、最新のメモリ使用率「９０％」から前回のメモリ使用率「６０％」を減算した値「３０％」を算出する。そして、リソース増減量決定部４５は、算出した「３０％」にメモリ使用量「１５ＧＢ」と係数「３」とを乗算したメモリ増加／減少量「＋１３．５ＧＢ」を算出する。

その後、リソース増減量決定部４５は、算出したメモリ増加／減少量「＋１３．５ＧＢ」とサービスＡＰＬ番号「１」とを対応付けた変更依頼を生成する。そして、リソース増減量決定部４５は、通信部４２を介して、生成した変更依頼をサービス提供サーバ番号が「１」のサービス提供サーバ、すなわちサービス提供サーバ１１へ送信する。

なお、リソース増減量決定部４５は、例えば、サービス提供サーバ番号「１」のサービスＡＰＬ番号「１」が示すサービスＡＰＬの削減を指示された場合は、サービスＡＰＬ「１」とＡＰＬ増加／減少数「−１」とを対応付けた変更依頼を生成する。また、リソース増減量決定部４５は、例えば、サービス提供サーバ番号「１」のサービスＡＰＬ番号「１」が示すメモリ使用量の削減を指示された場合は、以下の処理を実行する。

すなわち、リソース増減量決定部４５は、最新のメモリ使用率から前回のメモリ使用率を削減した値にメモリ使用量と所定の係数とを乗算した値をメモリ増加／減少量として算出する。このため、リソース増減量決定部４５は、サービスＡＰＬ番号「１」のメモリ使用率が低下している場合は、負の値のメモリ増加／減少量を算出する。そして、リソース増減量決定部４５は、算出したメモリ増加／減少量とサービスＡＰＬ番号とを対応付けた変更依頼を生成し、生成した変更依頼を対応するサービス提供サーバへ送信する。

このように、リソース増減量決定部４５は、メモリ使用率の増減量に応じて、サービスＡＰＬ３５、３６に割当てるメモリ使用量の追加量、削減量を算出する。このため、リソース割当制御サーバ１４は、各サービスＡＰＬの付加が急に増大または減少した際にも、割り当てる計算機リソース量を追従させることができる。

なお、メモリ使用量の追加量、削減量を算出する際に用いる係数は、リソース割当制御サーバ１４が新たなリソース増減量を算出するまでの間に、各サービスＡＰＬに割り当てた計算機リソースが枯渇しないように考慮されるマージンである。すなわち、リソース増減量決定部４５は、サービスＡＰＬを実行する際の負荷が変化する時間に対し、十分に短い時間間隔で新たなリソース増減量を算出できるのであれば、係数を考慮せずとも、適切なメモリ使用量の追加量、削減量を算出してもよい。また、この係数は、各サービス提供サーバ１１〜１３が実行するサービスＡＰＬの性質や計算機リソースの量等に応じて、任意の値を設定することができる。

次に、図１２を用いて、実施例１に係る情報処理システム１が実行する処理の流れについて説明する。図１２は、実施例１に係る情報処理システムが実行する処理の流れを説明するためのシーケンス図である。なお、図１２に示す例では、理解を容易にするため、ＣＰＵ使用率又はメモリ使用率が追加閾値以上となった際に実行する処理の流れについて記載した。

例えば、図１２に示す例では、サービス提供サーバ１１は、ＣＰＵ使用率、メモリ使用率を計測し（ステップＳ１０１）、負荷情報をリソース割当制御サーバ１４に送信する（ステップＳ１０２）。このような場合は、リソース割当制御サーバ１４は、直近２回分の負荷情報を負荷状況テーブル４１に格納する（ステップＳ１０３）。

続いて、リソース割当制御サーバ１４は、負荷状況テーブル４１を読み出し、最新の計測値が閾値を超えたアプリケーション、すなわち最新の計測値が削減閾値未満、または追加閾値以上のサービスＡＰＬを検索する（ステップＳ１０４）。そして、リソース割当制御サーバ１４は、閾値を超えたサービスＡＰＬのサービス提供サーバ番号と、サービスＡＰＬ番号とを識別する（ステップＳ１０５）。

また、リソース割当制御サーバ１４は、ＣＰＵ使用率が追加閾値を超えているか否かを判定し（ステップＳ１０６）、ＣＰＵ使用率が追加閾値を超えている場合は（ステップＳ１０６肯定）、サービスＡＰＬの追加起動を決定する（ステップＳ１０７）。また、リソース割当制御サーバ１４は、メモリ使用率が追加閾値を超えているか判定し（ステップＳ１０８）、メモリ使用率が追加閾値を超えている場合は（ステップＳ１０８肯定）、負荷状況テーブル４１を読み出す（ステップＳ１０９）。

そして、リソース割当制御サーバ１４は、メモリ使用率の増加量とメモリ使用量との積の３倍のメモリ使用量追加を決定する（ステップＳ１１０）。そして、リソース割当制御サーバ１４は、各決定結果を含む変更依頼をサービス提供サーバ１１に送信する（ステップＳ１１１）。なお、リソース割当制御サーバ１４は、ＣＰＵ使用率が閾値を超えていない場合は（ステップＳ１０６否定）、ステップＳ１０７の処理をスキップする。また、リソース割当制御サーバ１４は、メモリ使用率が閾値を超えていない場合は（ステップＳ１０８否定）、ステップＳ１０９およびステップＳ１１０をスキップする。

一方、サービス提供サーバ１１は、変更依頼を受信すると、受信した変更依頼に従って、サービスＡＰＬのメモリ使用量を追加し、メモリ管理テーブル２８を更新する（ステップＳ１１２）。続いて、サービス提供サーバ１１は、追加するサービスＡＰＬが使用する空きメモリを確認し（ステップＳ１１３）、メモリを確保してサービスＡＰＬを追加して起動する（ステップＳ１１４）。また、サービス提供サーバ１１は、ＡＰＬ番号を起動したプログラムの数だけ空きＡＰＬ番号テーブルから確保する（ステップＳ１１５）。

そして、サービス提供サーバ１１は、プロセスＩＤと通信用のアドレス、すなわちＭａｃアドレスとＩＰアドレス、および確保したサービスＡＰＬ番号をアドレス関係テーブル２９に格納する（ステップＳ１１６）。また、サービス提供サーバ１１は、空きＡＰＬ番号テーブル２７、メモリ管理テーブル２８、サービス関係テーブル３０を修正し（ステップＳ１１７）、更新後のメモリ使用量をリソース割当制御サーバ１４に通知する（ステップＳ１１８）。

その後、サービス提供サーバ１１は、同一のサービスを提供するサービスＡＰＬ間で処理が均等になるように、利用者からの要求を振分ける（ステップＳ１１９）。また、リソース割当制御サーバ１４は、更新後のメモリ使用量に従って、負荷状況テーブル４１に新規エントリの追加、もしくは負荷状況テーブル４１のメモリ使用量の更新を行う（ステップＳ１２０）。

［リソース割当制御サーバ１４の効果］
上述したように、リソース割当制御サーバ１４は、サービスＡＰＬ３５、３６を実行する際の負荷を示す負荷情報を収集する。また、リソース割当制御サーバ１４は、収集した負荷が、所定の閾値を超えているか否かを判定する。そして、リソース割当制御サーバ１４は、収集した負荷が所定の閾値を超えている場合は、収集した負荷と過去に収集した負荷とを用いて、負荷の増減量を算出し、算出した増減量に基づいて、サービスＡＰＬに割り当てる計算機リソースの量を決定する。その後、リソース割当制御サーバ１４は、各サービス提供サーバ１１〜１３に対し、決定した量の計算機リソースを割り当てるよう指示する。

このように、リソース割当制御サーバ１４は、負荷の増減量に基づいた量の計算機リソースを各サービスＡＰＬ３５、３６に割り当てることができる。このため、リソース割当制御サーバ１４は、例えば、サービスＡＰＬ３５、３６を実行する際の負荷が指数関数的に増加する場合にも、各サービスＡＰＬ３５、３６に対して割り当てる計算機リソースの量を負荷に追従させることができる。また、リソース割当制御サーバ１４は、計算機リソースの量を負荷に追従させることができるので、例えば、混雑などを起因とする処理の遅延等の悪影響を防止する。

また、リソース割当制御サーバ１４は、サービスＡＰＬ３５を実行する際のメモリ使用率を収集する。そして、リソース割当制御サーバ１４は、最新のメモリ使用率から前回収集したメモリ使用率を減算した値に、サービスＡＰＬ３５に割り当てられたメモリ使用量と所定の係数とを乗算した値を算出する。その後、リソース割当制御サーバ１４は、サービスＡＰＬ３５に割り当てられたメモリ使用量に、算出した値を追加させる。

すなわち、リソース割当制御サーバ１４は、サービスＡＰＬ３５を実行する際のメモリ使用率の増加量に基づいて、サービスＡＰＬ３５に割り当てるメモリ使用量を追加する。このため、リソース割当制御サーバ１４は、サービスＡＰＬ３５が使用するメモリ使用量が急に増大した場合にも、サービスＡＰＬ３５に割り当てるメモリ使用量を追従させることができる。

また、リソース割当制御サーバ１４は、所定の係数を考慮したメモリ使用量を追加するので、次回リソース割当制御サーバ１４がメモリ使用量を追加するまでのマージンを、追加するメモリ使用量に含めることができる。この結果、リソース割当制御サーバ１４は、サービスＡＰＬ３５が使用するメモリ使用量が不足し、サービスＡＰＬ３５が停止するといった不具合を防ぐことができる。

上述したリソース割当制御サーバ１４は、直近２回の測定による負荷情報を用いて、各サービスＡＰＬ３５、３６に割当てる計算機リソースの量を決定した。しかしながら、実施例は、これに限定されるものではない。例えば、リソース割り当て制御サーバ１４は、複数回の測定による負荷情報を用いて、各サービスＡＰＬ３５、３６に割当てる計算機リソースの量を決定してもよい。

以下、複数回の測定による負荷情報を用いて、各サービスＡＰＬ３５、３６に割当てる計算機リソースの量を決定するリソース割当制御サーバ１４ａについて説明する。例えば、図１３は、実施例２に係るリソース割当制御サーバの機能構成を説明する図である。なお、図１３に示すリソース割当制御サーバ１４ａが有する機能構成のうち、図９に示すリソース割当制御サーバ１４が有する機能構成と同様の機能を発揮するものについては、同一の符号を付し、説明を省略する。

図１３に示す例では、リソース割当制御サーバ１４ａは、負荷状況収集部４３ａ、リソース増減量決定部４５ａを有する。また、記憶部４０は、負荷状況テーブル４１ａを記憶する。まず、図１４を用いて、記憶部４０が記憶する負荷状況テーブル４１ａについて説明する。

図１４は、負荷状況テーブルのバリエーションを説明する図である。図１４に示すように、負荷状況テーブル４１ａは、負荷状況テーブル４１と同様に、サービス提供サーバ番号、サービスＡＰＬ番号、ＣＰＵ使用率、メモリ使用率、メモリ使用量が対応付けて格納されている。ここで、負荷状況テーブル４１ａには、ＣＰＵ使用率として、過去ｎ回分の負荷情報に格納されたＣＰＵ使用率とメモリ使用率とが格納されている。すなわち、負荷状況テーブル４１ａには、過去に測定された複数回分の負荷がサービスＡＰＬごとに格納されている。

図１３に戻り、負荷状況収集部４３ａは、図９に示す負荷状況収集部４３と同様の機能を発揮する。さらに、負荷状況収集部４３ａは、負荷情報を受信した際に、直近２回の計測に係るＣＰＵ使用率およびメモリ使用率だけではなく、過去ｎ回分のＣＰＵ使用率およびメモリ使用率を負荷状況テーブル４１ａに格納する。例えば、負荷状況収集部４３ａは、新たな負荷情報を受信すると、ｎ回前に測定されたＣＰＵ使用率およびメモリ使用率を削除し、新たに測定されたＣＰＵ使用率およびメモリ使用率を負荷状況テーブル４１ａに格納する。

一方リソース増減量決定部４５ａは、図９に示すリソース増減量決定部４５と同様の機能を発揮する。ここで、リソース増減量決定部４５ａは、過去ｎ回分の測定に係るメモリ使用率を用いて、加算するメモリ使用量の算出を行う。例えば、リソース増減量決定部４５ａは、過去ｎ回分のメモリ使用率のうち、値が最も少ないメモリ使用率を抽出する。そして、リソース増減量決定部４５ａは、最新のメモリ使用率から抽出したメモリ使用率を減算し、減算した値にメモリ使用量と所定の係数、例えば「３」、とを乗算した値を加算するメモリ使用量とする。

このように、リソース割当制御サーバ１４ａは、過去ｎ回分の測定に係るメモリ使用率のうち、最低のメモリ使用率と最新のメモリ使用率との差分に基づいて、加算するメモリ使用量を算出する。このため、リソース割当制御サーバ１４ａは、例えば、サービスＡＰＬ３５が使用するメモリの量が大きく増加する際に、先取りしてメモリ使用量を追加することができる。

次に、図１５を用いて、実施例２に係る情報処理システムが実行する処理の流れについて説明する。図１５は、実施例２に係る情報処理システムが実行する処理の流れを説明するためのシーケンス図である。なお、図１５に示す各処理のうち、ステップＳ２０１、Ｓ２０２、Ｓ２０４〜Ｓ２０９、Ｓ２１１〜Ｓ２２０は、図１２に示すステップＳ１０１、Ｓ１０２、Ｓ１０４〜Ｓ１０９、Ｓ１１１〜Ｓ１２０と同様の処理であるものとし、説明を省略する。

例えば、リソース割当制御サーバ１４ａは、サービス提供サーバ１０から負荷情報を受信すると、複数回分の負荷情報を負荷状況テーブル４１ａに格納する（ステップＳ２０３）。そして、リソース割当制御サーバ１４ａは、あるサービスＡＰＬについて、最新のメモリ使用率から、最低のメモリ使用率を減算した値に、メモリ使用量と係数「３」とを乗算した値を、追加するメモリ使用量とする（ステップＳ２１０）。

［リソース割当制御サーバ１４ａの効果］
上述したように、リソース割当制御サーバ１４ａは、最新のメモリ使用率から過去に収集したメモリ利用率のうち、最低のメモリ使用率を減算した値に、メモリ使用量と所定の係数とを乗算した値を、加算するメモリ使用量とする。このため、リソース割当制御サーバ１４ａは、サービスＡＰＬが使用するメモリ量が大きく増加する際に、先取りしてメモリ使用量を追加することができる。

上述したサービス提供サーバ１１は、受信した変更依頼に格納されたサービスＡＰＬ番号が示すアプリケーションのメモリ使用量のみを増加、もしくは削減した。しかし、実施例は、これに限定されるものではない。例えば、サービス提供サーバ１１は、サービスＡＰＬに割当てるメモリ使用量を増加もしくは減少させる場合は、同一のサービスを提供するための他のサービスＡＰＬに対して割当てるメモリ使用量についても増加もしくは減少させてもよい。

以下、同一のサービスを提供する複数のサービスＡＰＬを実行する際に、代表となるサービスＡＰＬのメモリ使用量を増加させる場合は、他のサービスＡＰＬに対して割当てるメモリ使用量についても増加させるサービス提供サーバ１１ａについて説明する。まず、図１６を用いて、サービス提供サーバ１１ａの機能構成について説明する。

図１６は、実施例３に係るサービス提供サーバの機能構成を説明する図である。なお、図１６に示すサービス提供サーバ１１ａが有する機能構成のうち、図２に示すサービス提供サーバ１１が有する機能構成と同様の機能を発揮するものについては、同一の符号を付し、説明を省略する。図１６に示す例では、サービス提供サーバ１１ａは、リソース制御部２４ａを有する。また、リソース制御部２４ａは、ＡＰＬ負荷計測部２１ａ、リソース管理部３１ａ、およびテーブル管理部３２ａを有する。また、サービス提供サーバ１１ａの記憶部２３は、サービス関係テーブル３０ａを有する。

まず、図１７を用いて、サービス関係テーブル３０ａに格納された情報の一例について説明する。図１７は、実施例３に係るサービス関係テーブルの一例を説明する図である。図１７に示すように、サービス関係テーブル３０ａは、図６に示すサービス関係テーブルと同様に、サービスＡＰＬ ＩＤ、サービスＡＰＬファイル所在、サービスＡＰＬ番号とが対応付けて格納されている。

また、サービス関係テーブル３０ａには、各サービスＡＰＬ ＩＤが示すサービスを提供するサービスＡＰＬのサービスＡＰＬ番号とともに、代表番号が格納されている。ここで、代表番号とは、あるサービスを提供するためのサービスＡＰＬのうち、代表として定めれたサービスＡＰＬを示すサービスＡＰＬ番号である。

図１６に戻り、ＡＰＬ負荷計測部２１ａは、図２に示すＡＰＬ負荷計測部２１と同様の機能を発揮する。ここで、ＡＰＬ負荷計測部２１ａは、各サービスＡＰＬ３５、３６のうち、代表となるサービスＡＰＬを実行する際の負荷を計測する。例えば、ＡＰＬ負荷計測部２１ａは、記憶部２３が記憶するサービス関係テーブル３０ａを参照し、代表番号をサービスＡＰＬ番号とするサービスＡＰＬ、すなわち代表となるサービスＡＰＬを識別する。そして、ＡＰＬ負荷計測部２１ａは、代表となるサービスＡＰＬを実行する際の負荷を計測し、計測結果を負荷情報としてリソース割当制御サーバ１４へ送信する。

リソース管理部３１ａは、図２に示すリソース管理部３１と同様の機能を発揮する。また、リソース管理部３１ａは、メモリ増加量が格納された変更依頼を受信すると、以下の処理を実行する。例えば、リソース管理部３１ａは、変更依頼に格納されたサービスＡＰＬ番号を代表番号とする１つ以上のエントリをサービス関係テーブル３０ａから抽出する。

なお、リソース割当制御サーバ１４には、代表となるサービスＡＰＬに係る負荷情報のみが送信される。このため、リソース割当制御サーバ１４からサービス提供サーバ１１ａに送信される変更依頼には、代表となるサービスＡＰＬのサービスＡＰＬ番号が格納されることとなる。

また、リソース管理部３１ａは、抽出したエントリに、代表番号以外の番号がサービスＡＰＬ番号として格納されているか否かを判定する。すなわち、リソース管理部３１ａは、代表となるサービスＡＰＬと同じサービスを提供するための他のサービスＡＰＬが実行されているか否かを判定する。

また、リソース管理部３１ａは、抽出したエントリに代表番号以外の番号がサービスＡＰＬ番号として格納されている場合は、抽出したエントリに格納されている全てのサービスＡＰＬ番号の数と、変更依頼に格納されたメモリ増加量とを積算する。すなわち、リソース管理部３１ａは、抽出したエントリに格納されている全てのサービスＡＰＬ番号が示すサービスＡＰＬに対して追加予定の総メモリ使用量を算出する。

そして、リソース管理部３１ａは、空きメモリを参照し、総メモリ使用量を確保することができるか否かを判定し、確保できる場合には、以下の処理を実行する。すなわち、リソース管理部３１ａは、抽出したエントリに格納された各サービスＡＰＬ番号が示すサービスＡＰＬを識別し、識別した全てのサービスＡＰＬに割当てられたメモリ使用量に、変更依頼に格納されたメモリ増加量を追加する。

つまり、リソース管理部３１ａは、代表となるサービスＡＰＬの負荷が増加した場合は、代表となるサービスＡＰＬと同じサービスを提供するための他のサービスＡＰＬに対しても、割当てるメモリ使用量を追加する。例えば、リソース管理部３１ａは、サービスＡＰＬ番号「１」のサービスＡＰＬに割当てられたメモリ使用量を追加する場合は、サービスＡＰＬ番号「５」が示すサービスＡＰＬについても同じ量のメモリ使用量を追加する。

なお、リソース管理部３１ａは、変更依頼に格納されたメモリ増加量が負である場合、すなわちメモリ削減量が格納されている場合は、代表となるサービスＡＰＬと同じサービスを提供する複数のサービスＡＰＬに対して割当てたメモリ使用量を削減する。

また、リソース管理部３１ａは、変更依頼にＡＰＬ増加数が格納されている場合は、変更依頼に格納されたサービスＡＰＬ番号を代表番号とするエントリをサービス関係テーブル３０ａから抽出する。そして、リソース管理部３１ａは、抽出したエントリに格納されたサービスＡＰＬ番号が示すサービスＡＰＬ一式を追加起動させた際に必要なメモリ量が確保可能であるか空きメモリを確認する。そして、リソース管理部３１ａは、メモリの割当が可能である場合は、抽出したエントリに格納されたサービスＡＰＬ番号が示すサービスＡＰＬ一式をＡＰＬ増加数の分だけ追加で実行する。

例えば、変更依頼にサービスＡＰＬ番号「１」とＡＰＬ増加数「１」が格納されている場合は、リソース管理部３１ａは、サービスＡＰＬ番号「１」が示すサービスＡＰＬとサービスＡＰＬ番号「５」が示すサービスＡＰＬとをそれぞれ追加で実行する。なお、リソース管理部３１ａは、変更依頼にＡＰＬ減少数が格納されている場合は、格納されたＡＰＬ減少数と同数のサービスＡＰＬを停止させる。

テーブル管理部３２ａは、図２に示すテーブル管理部３２と同様の機能を発揮する。また、テーブル管理部３２ａは、新たなサービスを実行するサービスＡＰＬが実行された場合は、サービス関係テーブル３０ａに新たなエントリを作成し、作成したエントリにサービスＡＰＬ ＩＤとサービスＡＰＬファイル所在とを格納する。そして、テーブル管理部３２ａは、新たに実行されたサービスＡＰＬのサービスＡＰＬ番号を代表番号として、追加されたエントリに格納する。

次に、図１８を用いて、実施例３に係る情報処理システムが実行する処理の流れについて説明する。図１８は、実施例３に係る情報処理システムが実行する処理の流れを説明するためのシーケンス図である。なお、図１８に示す各処理のうち、Ｓ３０２〜Ｓ３１１、、Ｓ３１６〜Ｓ３２１は、図１２に示すステップＳ１０２〜Ｓ１１１、Ｓ１１５〜Ｓ１２０と同様の処理であるものとし、説明を省略する。また、図１８に示す例では、あるサービスを提供するサービスＡＰＬが複数実行されている際に、同じサービスを提供するサービスＡＰＬが追加実行され、さらに各サービスＡＰＬに割当てるメモリ使用量も追加される例について説明する。

まず、サービス提供サーバ１１ａは、代表となるサービスＡＰＬのＣＰＵ使用率、メモリ使用率を計測する（ステップＳ３０１）。また、サービス提供サーバ１１ａは、受信した変更依頼に格納されたサービスＡＰＬ番号を代表番号とするエントリに代表番号以外のサービスＡＰＬ番号が登録されている場合は、以下の処理を実行する。

すなわち、サービス提供サーバ１１ａは、メモリ増加量とサービスＡＰＬの数の積、すなわち追加予定の総メモリ使用量が空きメモリで確保できるか確認する（ステップＳ３１２）。そして、サービス提供サーバ１１ａは、抽出したエントリに格納されたサービスＡＰＬ番号が示すサービスＡＰＬのメモリ使用量を追加し、メモリ管理テーブル２８を更新する（ステップＳ３１３）。

また、サービス提供サーバ１１ａは、代表番号のエントリに代表番号以外のサービスＡＰＬ番号が登録されている場合は、追加するサービスＡＰＬ一式に割当てるメモリを確保できるか確認する（ステップＳ３１４）。つまり、サービス提供サーバ１１ａは、代表番号となるサービスＡＰＬと連携して１つのサービスを提供する複数のサービスＡＰＬ一式を起動する際に必要なメモリを確保できるか確認する。そして、サービス提供サーバ１１ａは、指示された数だけサービスＡＰＬを追加起動する（ステップＳ３１５）。

［サービス提供サーバ１１ａの効果］
上述したように、サービス提供サーバ１１ａは、同一のサービスを提供するための複数のサービスＡＰＬのうち、代表となるサービスＡＰＬによるメモリ使用率を測定する。そして、サービス提供サーバ１１ａは、代表となるサービスＡＰＬのメモリ使用量を追加する場合は、同一のサービスを提供するための他のサービスＡＰＬのメモリ使用量についても、同様に追加する。

すなわち、同一のサービスを提供するために連携して動作する複数のサービスＡＰＬのうち、どれか１つのサービスＡＰＬを実行する際の負荷が増大した場合は、他のサービスＡＰＬを実行する際の負荷も増大すると考えられる。そこで、サービス提供サーバ１１ａは、同一のサービスを提供する複数のサービスＡＰＬのうち、代表となるサービスＡＰＬを実行する際の負荷を計測する。

そして、サービス提供サーバ１１ａは、代表となるサービスＡＰＬに割当てられた計算機リソースを追加する場合は、他のサービスＡＰＬに割当てられた計算機リソースについても、同様に追加する。この結果、サービス提供サーバ１１ａは、同一のサービスを提供するための複数のサービスＡＰＬについて負荷を計測せずとも、各サービスＡＰＬに対して割当てる計算機リソースを負荷に追従させることができる。

これまで本発明の実施例について説明したが実施例は、上述した実施例以外にも様々な異なる形態にて実施されてよいものである。そこで、以下では実施例４として本発明に含まれる他の実施例を説明する。

（１）サービス提供サーバ１１ａのバリエーションについて
上述したサービス提供サーバ１１ａは、代表となるサービスＡＰＬのメモリ使用量を追加する場合は、同一のサービスを提供するための他のサービスＡＰＬのメモリ使用量についても、同様に追加した。しかしながら、実施例は、これに限定されるものではない。例えば、サービス提供サーバ１１ａは、サービスＡＰＬごとに、追加もしくは削減するメモリの変化量を設定してもよい。

例えば、図１９は、実施例３に係るサービス関係テーブルのバリエーションを説明する図である。図１９に示す例では、サービス関係テーブル３０ａは、図１７に示した各情報に加え、個別メモリ変化量が格納されている。例えば、図１９に示す例では、サービス関係テーブル３０ａには、サービスＡＰＬ ＩＤ「２」とともに、代表番号「１」、個別メモリ変化量「５０％」、サービスＡＰＬ番号「２」を対応付けて格納されている。

すなわち、図１９に示す例では、サービス関係テーブル３０ａは、サービスＡＰＬ番号が「１」のサービスＡＰＬについてメモリ使用量を追加する際、サービスＡＰＬ番号が「２」のサービスＡＰＬについてもメモリ使用量を追加する旨を示す。また、サービス関係テーブル３０ａは、サービスＡＰＬ番号「２」のサービスＡＰＬについて追加するメモリ使用量は、サービスＡＰＬ番号「１」のサービスＡＰＬについて追加するメモリ使用量の「５０％」である旨を示す。

図１９に示す情報がサービス関係テーブル３０ａに格納されている場合、リソース管理部３１ａは、以下の処理を実行する。まず、リソース管理部３１ａは、実施例３と同様に、変更依頼に格納されたサービスＡＰＬ番号を代表番号とするエントリをサービス関係テーブル３０ａから抽出する。

また、リソース管理部３１ａは、抽出したエントリに、代表番号と代表番号以外の番号とがサービスＡＰＬ番号として格納されている場合は、抽出したエントリに格納されている全てのサービスＡＰＬ番号の数と、変更依頼に格納されたメモリ増加量とを積算する。すなわち、リソース管理部３１ａは、抽出したエントリに格納されている全てのサービスＡＰＬ番号が示すサービスＡＰＬに対して追加予定の総メモリ使用量を算出する。

また、リソース管理部３１ａは、抽出したエントリに代表番号以外の番号がサービスＡＰＬ番号として格納されている場合は、抽出したエントリに格納された個別メモリ変化量を識別する。そして、リソース管理部３１ａは、識別した個別メモリ変化量と、変更依頼に格納されたメモリ増加量とを積算し、積算した値を総メモリ使用量に加算する。そして、リソース管理部３１ａは、空きメモリを参照し、総メモリ使用量を確保することができるか否かを判定し、確保できる場合には、計算リソースの追加を行う。

すなわち、リソース管理部３１ａは、代表番号と代表番号以外の番号とがサービスＡＰＬ番号として格納されているエントリについては、エントリに格納された各サービスＡＰＬ番号が示すサービスＡＰＬを識別する。そして、リソース管理部３１ａは、識別した全てのサービスＡＰＬに割当てられたメモリ使用量に、変更依頼に格納されたメモリ増加量を追加する。

また、リソース管理部３１ａは、代表番号以外の番号とがサービスＡＰＬ番号として格納されているエントリについては、エントリに格納された各サービスＡＰＬ番号が示すサービスＡＰＬを識別する。そして、リソース管理部３１ａは、識別した全てのサービスＡＰＬに割当てられたメモリ使用量に、変更依頼に格納されたメモリ増加量と個別メモリ変化量との積を追加する。

例えば、リソース管理部３１ａは、サービスＡＰＬ番号「１」とメモリ増加量「１０ＧＢ」とが格納された変更依頼を受信すると以下の処理を実行する。まず、リソース管理部３１ａは、サービスＡＰＬ番号「１」が示すサービスＡＰＬとサービスＡＰＬ番号「５」が示すサービスＡＰＬとに割当てるメモリ使用量を「１０ＧＢ」追加する。また、リソース管理部３１ａは、サービスＡＰＬ番号「２」が示すサービスＡＰＬに割当てるメモリ使用量を「５ＧＢ」追加する。

次に、図２０を用いて、実施例３に係る情報処理システムが実行する処理のバリエーションについて説明する。図２０は、実施例３に係る情報処理システムが実行する処理のバリエーションを説明するためのシーケンス図である。なお、図２０に示す各処理のうち、Ｓ４０１〜Ｓ４１１、Ｓ４１６〜Ｓ４２３は、図１８に示すステップＳ３０１〜Ｓ３１１、Ｓ３１４〜Ｓ３２１と同様の処理であるものとし、説明を省略する。

例えば、サービス提供サーバ１１ａは、変更依頼に格納されたサービスＡＰＬ番号を代表番号とするエントリを抽出する。そして、サービス提供サーバ１１ａは、抽出したエントリに、サービスＡＰＬ番号に代表番号と代表番号以外のサービスＡＰＬ番号とが格納されている場合は、メモリ増加量と、エントリに含まれるサービスＡＰＬの数の積を算出する（ステップＳ４１２）。また、サービス提供サーバ１１ａは、抽出したエントリに、代表番号がサービスＡＰＬ番号として格納されていない場合は、メモリ増加量とエントリに登録されたサービスＡＰＬの数と個別メモリ変化量との積を算出する（ステップＳ４１３）。

次に、サービス提供サーバ１１ａは、ステップＳ４１２、及びステップＳ４１３において算出した値の分だけ、メモリを確保できるか確認する（ステップＳ４１４）。そして、サービス提供サーバ１１ａは、抽出したエントリに登録されたサービスＡＰＬ番号が示すサービスＡＰＬに対して割当てるメモリを追加し、メモリ管理テーブル２８を更新する（ステップＳ４１５）。

具体的には、サービス提供サーバ１１ａは、サービスＡＰＬ番号に代表番号と代表番号以外のサービスＡＰＬ番号とが格納されている場合は、各サービスＡＰＬ番号が示すサービスＡＰＬのメモリ使用量を、変更依頼に格納されたメモリ増加量の分だけ追加する。また、サービス提供サーバ１１ａは、サービスＡＰＬ番号に代表番号が格納されていない場合は、各サービスＡＰＬ番号が示すサービスＡＰＬのメモリ使用量を、変更依頼に格納されたメモリ増加量と個別メモリ変化量の分だけ追加する。

このように、サービス提供サーバ１１ａは、代表となるサービスＡＰＬのメモリ使用量を追加する際に、他のサービスＡＰＬのメモリ使用量を追加する割合を記憶する。そして、サービス提供サーバ１１ａは、代表となるサービスＡＰＬのメモリ使用量については、リソース割当制御サーバ１４から通知されたメモリ増加量を追加する。一方、サービス提供サーバ１１ａは、他のサービスＡＰＬについては、リソース割当制御サーバ１４から通知されたメモリ増加量に記憶した割合とを乗算した値を追加する。このため、サービス提供サーバ１１ａは、代表となるサービスＡＰＬの負荷のみを測定する際にも、各サービスＡＰＬに対して適切な量のメモリを割当てることができる。

（２）負荷について
上述した実施例１〜３では、サービスＡＰＬを実行した際の負荷としてＣＰＵ使用率およびメモリ使用率を測定した。しかし、実施例はこれに限定されるものではない。例えば、サービス提供サーバ１１、１１ａは、ＣＰＵ使用率、メモリ使用率、利用者端末２からのリクエスト数、記憶装置に対するアクセス数、所定の処理に要する時間等、任意の情報を負荷として用いることができる。

（３）計算機リソースについて
上述した実施例１〜３では、サービスＡＰＬを実行した際のＣＰＵ使用率に基づいて、サービスを提供するサービスＡＰＬの追加や停止を行った。ここで、リソース割当制御サーバ１４は、ＣＰＵ使用率の増加量に基づいて、追加実行するサービスＡＰＬの数を算出してもよい。例えば、リソース割当制御サーバ１４は、最新のＣＰＵ使用率から前回測定したＣＰＵ使用率を減算したＣＰＵ使用率の増減量を算出し、算出した増減量に基づいて、追加実行するサービスＡＰＬの数を算出する。そして、リソース割当制御サーバ１４は、算出した数のサービスＡＰＬを追加実行するように、サービス提供サーバ１１に通知してもよい。

なお、追加実行するサービスＡＰＬの数を算出する際には、他の情報を考慮してもよい。例えば、リソース割当制御サーバ１４は、サービスＡＰＬを実行した際の平均的なＣＰＵ使用率や残余リソース等、任意の情報を考慮し、情報処理システム１において適切なポリシに従って、追加実行するサービスＡＰＬの数を算出してもよい。リソース割当制御サーバ１４は、ＣＰＵ使用率の増減量に基づいて、追加実行するサービスＡＰＬの数を算出した場合は、利用者端末２に対して提供するサービスが、混雑のために停止してしまうといった不具合を防ぐことができる。

また、上述した実施例では、サービスＡＰＬを実行した際のＣＰＵ使用率に基づいて、サービスを提供するサービスＡＰＬの追加や停止を行った。しかし、実施例は、これに限定されるものではない。例えば、サービス提供サーバ１１は、利用者端末２に提供するサービスの種別ごとに、サービスＡＰＬを仮想マシン上で動作させる場合は、ＣＰＵ使用率に基づいて、実行する仮想マシンの数を変更してもよい。

例えば、サービス提供サーバ１１は、サービスＡＰＬを実行する仮想マシンのＣＰＵ使用率を測定する。また、リソース割当制御サーバ１４は、サービス提供サーバ１１が測定したＣＰＵ使用率の増減に基づいて、追加実行する仮想マシンの数を算出する。そして、サービス提供サーバ１１は、リソース割当制御サーバ１４が算出した数の仮想マシンを追加で実行する。このように、リソース割当制御サーバ１４は、ＣＰＵ使用率の増減量に基づいて、追加実行する仮想マシンの数を変更した場合は、利用者端末２に対して提供するサービスが、混雑のために停止してしまうといった不具合を防ぐことができる。

（４）増減量について
上述した実施例１〜３では、主に、サービスＡＰＬに割当てる計算機リソースを増加させる例について説明したが、実施例はこれに限定されるものではなく、同様の処理を行うことで、負荷に応じて計算機リソースを削減することもできる。すなわち、負荷が減少し、負荷の増減量が負の値となった場合は、追加実行するサービスＡＰＬの数や追加するメモリ使用量の値も負の値となる。この結果、上述した処理と同様の処理を実行することで、リソース割当制御サーバ１４、１４ａは、負荷が減少した際に、停止させるサービスＡＰＬの数や削減するメモリ使用量を算出することができる。

なお、停止させるサービスＡＰＬの数や削減するメモリ使用量を指示する変更依頼には、ＡＰＬ増加／減少数、およびメモリ増加／減少量として負の値が格納される。このため、サービス提供サーバ１１は、変更依頼に格納されたＡＰＬ増加／減少数が負の値である場合は、サービスＡＰＬの停止を行い、メモリ増加／減少量が負の値である場合は、メモリ使用量の削減を行う。

（５）プログラム
ところで、実施例１に係るリソース割当制御サーバ１４は、ハードウェアを利用して各種の処理を実現する場合を説明した。しかし、実施例はこれに限定されるものではなく、あらかじめ用意されたプログラムをコンピュータで実行することによって実現するようにしてもよい。そこで、以下では、図２１を用いて、実施例１に示したリソース割当制御サーバ１４と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図２１は、リソース制御プログラムを実行するコンピュータを説明する図である。

図２１に例示されたコンピュータ１００は、ＲＯＭ（Read Only Memory）１１０、ＨＤＤ（Hard Disk Drive）１２０、ＲＡＭ（Random Access Memory）１３０、ＣＰＵ（Central Processing Unit）１４０がバス１６０で接続される。また、図１２に例示されたコンピュータ１００は、パケットを送受信するためのＩ／Ｏ（Input Output）１５０を有する。

ＨＤＤ１２０は、図９に示した記憶部４０が記憶する負荷状況テーブル４１と同様の情報である負荷状況テーブル１２１を記憶する。また、ＲＡＭ１３０には、リソース制御プログラム１３１があらかじめ保持される。ＣＰＵ１４０がリソース制御プログラム１３１をＲＡＭ１３０から読み出して実行することによって、図２１に示す例では、リソース制御プログラム１３１は、リソース制御プロセス１４１として機能するようになる。なお、リソース制御プロセス１４１は、図９に示した負荷状況収集部４３、リソース増減判定部４４、リソース増減量決定部４５と同様の機能を発揮する。

なお、本実施例で説明したリソース制御プログラムは、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＭＯ（Magneto Optical Disc）、ＤＶＤ（Digital Versatile Disc）などのコンピュータで読取可能な記録媒体に記録される。また、このプログラムは、コンピュータによって記録媒体から読み出されることによって実行することもできる。

以上の各実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）アプリケーションを実行する情報処理装置から、前記アプリケーションを実行する際の負荷を示す負荷情報を収集する収集部と、
前記収集部が収集した負荷情報が示す負荷が所定の閾値を超えているか否かを判定する判定部と、
前記負荷が所定の閾値を超えていると前記判定部が判定した場合は、前記収集部が収集した負荷情報と、前記収集部が過去に収集した負荷情報とを用いて、前記アプリケーションを実行する際の負荷の増減量を算出し、当該算出した増減量に基づいて、前記アプリケーションを実行する際に割当るリソース量を決定する決定部と、
前記アプリケーションに対し、前記決定部が決定したリソース量の割当を行う割当部と
を有することを特徴とする制御装置。

（付記２）前記収集部は、前記アプリケーションによるメモリ使用率を示す負荷情報を収集し、
前記決定部は、前記収集部が収集した負荷情報が示すメモリ使用率から前記収集部が前回収集した負荷情報が示すメモリ使用率を減算した値に、前記アプリケーションに割当られたメモリ量と所定の値とを乗算した値を算出し、
前記割当部は、前記アプリケーションに割当られたメモリ量に、前記決定部が算出した値を追加することを特徴とする付記１に記載の制御装置。

（付記３）前記収集部は、前記アプリケーションによるメモリ使用率を示す負荷情報を収集し、
前記決定部は、前記収集部が収集した負荷情報が示すメモリ使用率から前記収集部が過去に収集した負荷情報が示すメモリ使用率のうち、最低のメモリ使用率を減算した値に、前記アプリケーションに割当られたメモリ量と所定の値とを乗算した値を算出し、
前記割当部は、前記アプリケーションに割当られたメモリ量に、前記決定部が算出した値を追加することを特徴とする付記１に記載の制御装置。

（付記４）前記収集部は、同一のサービスを提供するための複数のアプリケーションのうち、代表となるアプリケーションによるメモリ使用率を示す負荷情報を収集し、
前記割当部は、前記同一のサービスを提供するためのアプリケーションのそれぞれに割当られたメモリ量に対し、前記決定部が算出した値を追加することを特徴とする付記２または３に記載の制御装置。

（付記５）前記代表となるアプリケーションのメモリ量を追加する際に、他のアプリケーションのメモリ量を追加する割合を記憶する記憶部を有し、
前記割当部は、前記代表となるアプリケーションのメモリ量に、前記決定部が算出した値を追加し、前記代表となるアプリケーション以外のアプリケーションのメモリ量に、前記決定部が算出した値に前記記憶部が記憶する割合を乗算した値を追加することを特徴とする付記４に記載の制御装置。

（付記６）前記収集部は、前記アプリケーションを実行する際のＣＰＵ使用率を収集し、
前記決定部は、前記収集部が収集したＣＰＵ使用率と前回収集部が収集したＣＰＵ利用率とを用いて、ＣＰＵ使用率の増減量を算出し、当該算出した増減量に基づいて、前記情報処理装置が追加実行するアプリケーションの数を算出し、
前記割当部は、前記情報処理装置に、前記決定部が算出した数のアプリケーションを追加実行させることを特徴とする付記１に記載の制御装置。

（付記７）前記収集部は、前記アプリケーションを実行する仮想マシンを稼動させる情報処理装置から、前記アプリケーションを実行する際のＣＰＵ使用率を収集し、
前記決定部は、前記収集部が収集したＣＰＵ使用率と前回収集部が収集したＣＰＵ利用率とを用いて、ＣＰＵ使用率の増減量を算出し、当該算出した増減量に基づいて、前記仮想マシンを追加する数を算出し、
前記割当部は、前記情報処理装置に、前記決定部が決定した数の仮想マシンを追加稼動させることを特徴とする付記１に記載の制御装置。

（付記８）コンピュータに、アプリケーションを実行する情報処理装置から、前記アプリケーションを実行する際の負荷を示す負荷情報を収集し、
前記収集した負荷情報が示す負荷が所定の閾値を超えているか否かを判定し、
前記負荷が所定の閾値を超えていると判定した場合は、前記収集した負荷情報と、過去に収集した負荷情報とを用いて、前記アプリケーションを実行する際の負荷の増減量を算出し、当該算出した増減量に基づいて、前記アプリケーションに割当るリソース量を決定する
処理を実行させることを特徴とするリソース制御プログラム。

（付記９）アプリケーションに対して割当るリソース量を制御する制御装置が、
前記アプリケーションを実行する情報処理装置から、前記アプリケーションを実行する際の負荷を示す負荷情報を収集し、
前記収集した負荷情報が示す負荷が所定の閾値を超えているか否かを判定し、
前記負荷が所定の閾値を超えていると判定した場合は、前記収集した負荷情報と、過去に収集した負荷情報とを用いて、前記アプリケーションを実行する際の負荷の増減量を算出し、当該算出した増減量に基づいて、前記アプリケーションに割当るリソース量を決定する
処理を実行することを特徴とするリソース制御方法。

１ 情報処理システム
２ 利用者端末
３、５ ＩＳＰ
４ サービス提供者端末
６ インターネット
１０ データセンタ
１１〜１３、１１ａ サービス提供サーバ
１４、１４ａ リソース割当制御サーバ
２０ 通信部
２１、２１ａ ＡＰＬ負荷計測部
２２ 振分け部
２３ 記憶部
２４、２４ａ リソース制御部
２５ 使用中リソース
２６ 残余リソース
２７ 空きＡＰＬ番号テーブル
２８ メモリ管理テーブル
２９ アドレス関係テーブル
３０、３０ａ サービス関係テーブル
３１、３１ａ リソース管理部
３２、３２ａ テーブル管理部
３３、３８ メモリ
３４ 実行中アプリケーション
３５、３６ サービスＡＰＬ
３７ ＣＰＵ
４０ 記憶部
４１、４１ａ 負荷状況テーブル
４２ 通信部
４３、４３ａ 負荷状況収集部
４４ リソース増減判定部
４５、４５ａ リソース増減量決定部

Claims (10)

1. アプリケーションを実行する情報処理装置から、前記アプリケーションを実行する際の負荷を示す負荷情報を収集する収集部と、
   前記収集部が収集した負荷情報が示す負荷が所定の閾値を超えているか否かを判定する判定部と、
   前記負荷が所定の閾値を超えていると前記判定部が判定した場合は、前記収集部が収集した負荷情報と、前記収集部が過去に収集した負荷情報とを用いて、前記アプリケーションを実行する際の負荷の増減量を算出し、当該算出した増減量に基づいて、前記アプリケーションを実行する際に割当るリソース量を決定する決定部と、
   前記アプリケーションに対し、前記決定部が決定したリソース量の割当を行う割当部と
   を有し、
   前記収集部は、前記アプリケーションによるメモリ使用率を示す負荷情報を収集し、
   前記決定部は、前記収集部が収集した負荷情報が示すメモリ使用率から前記収集部が過去に収集した負荷情報が示すメモリ使用率のうち、最低のメモリ使用率を減算した値に、前記アプリケーションに割当られたメモリ量と所定の値とを乗算した値を算出し、
   前記割当部は、前記アプリケーションに割当るメモリ量に、前記決定部が算出した値を追加することを特徴とする制御装置。
2. 前記決定部は、前記収集部が収集した負荷情報が示すメモリ使用率から前記収集部が前回収集した負荷情報が示すメモリ使用率を減算した値に、前記アプリケーションに割当られたメモリ量と所定の値とを乗算した値を算出し、
   前記割当部は、前記アプリケーションに割当るメモリ量に、前記決定部が算出した値を追加することを特徴とする請求項１に記載の制御装置。
3. アプリケーションを実行する情報処理装置から、前記アプリケーションを実行する際の負荷を示す負荷情報を収集する収集部と、
   前記収集部が収集した負荷情報が示す負荷が所定の閾値を超えているか否かを判定する判定部と、
   前記負荷が所定の閾値を超えていると前記判定部が判定した場合は、前記収集部が収集した負荷情報と、前記収集部が過去に収集した負荷情報とを用いて、前記アプリケーションを実行する際の負荷の増減量を算出し、当該算出した増減量に基づいて、前記アプリケーションを実行する際に割当るリソース量を決定する決定部と、
   前記アプリケーションに対し、前記決定部が決定したリソース量の割当を行う割当部と
   を有し、
   前記収集部は、同一のサービスを提供するための複数のアプリケーションのうち、代表となるアプリケーションによるメモリ使用率を示す負荷情報を収集し、
   前記割当部は、前記同一のサービスを提供するためのアプリケーションのそれぞれに割当られたメモリ量に対し、前記決定部が算出した値を追加することを特徴とする制御装置。
4. 前記代表となるアプリケーションのメモリ量を追加する際に、他のアプリケーションのメモリ量を追加する割合を記憶する記憶部を有し、
   前記割当部は、前記代表となるアプリケーションのメモリ量に、前記決定部が算出した値を追加し、前記代表となるアプリケーション以外のアプリケーションのメモリ量に、前記決定部が算出した値に前記記憶部が記憶する割合を乗算した値を追加することを特徴とする請求項３に記載の制御装置。
5. 前記収集部は、前記アプリケーションを実行する際のＣＰＵ使用率を収集し、
   前記決定部は、前記収集部が収集したＣＰＵ使用率と前回収集部が収集したＣＰＵ利用率とを用いて、ＣＰＵ使用率の増減量を算出し、当該算出した増減量に基づいて、前記情報処理装置が追加実行するアプリケーションの数を算出し、
   前記割当部は、前記情報処理装置に、前記決定部が算出した数のアプリケーションを追加実行させることを特徴とする請求項１に記載の制御装置。
6. 前記収集部は、前記アプリケーションを実行する仮想マシンを稼動させる情報処理装置から、前記アプリケーションを実行する際のＣＰＵ使用率を収集し、
   前記決定部は、前記収集部が収集したＣＰＵ使用率と前回収集部が収集したＣＰＵ利用率とを用いて、ＣＰＵ使用率の増減量を算出し、当該算出した増減量に基づいて、前記仮想マシンを追加する数を算出し、
   前記割当部は、前記情報処理装置に、前記決定部が決定した数の仮想マシンを追加稼動させることを特徴とする請求項１に記載の制御装置。
7. コンピュータに、
   アプリケーションを実行する情報処理装置から、前記アプリケーションを実行する際の負荷を示す前記アプリケーションによるメモリ使用率を示す負荷情報を収集し、
   前記収集した負荷情報が示す負荷が所定の閾値を超えているか否かを判定し、
   前記負荷が所定の閾値を超えていると判定した場合は、前記収集した負荷情報が示すメモリ使用率から過去に収集した最低のメモリ使用率を減算した値に前記アプリケーションに割当られたメモリ量と所定の値とを乗算して前記アプリケーションを実行する際の負荷の増減量を算出し、当該算出した増減量に基づいて、前記アプリケーションに割当るリソース量を決定する
   処理を実行させることを特徴とするリソース制御プログラム。
8. コンピュータに、
   アプリケーションを実行する情報処理装置から、同一のサービスを提供するための複数のアプリケーションのうち、代表となるアプリケーションによるメモリ使用率を示す負荷情報を収集し、
   前記収集した負荷情報が示す負荷が所定の閾値を超えているか否かを判定し、
   前記負荷が所定の閾値を超えていると判定した場合は、前記収集した負荷情報と、過去に収集した負荷情報とを用いて、前記アプリケーションを実行する際の負荷の増減量を算出し、当該算出した増減量に基づいて、前記アプリケーションに割当るリソース量を決定する
   処理を実行させることを特徴とするリソース制御プログラム。
9. アプリケーションに対して割当るリソース量を制御する制御装置が、
   前記アプリケーションを実行する情報処理装置から、前記アプリケーションを実行する際の負荷を示す前記アプリケーションによるメモリ使用率を示す負荷情報を収集し、
   前記収集した負荷情報が示す負荷が所定の閾値を超えているか否かを判定し、
   前記負荷が所定の閾値を超えていると判定した場合は、前記収集した負荷情報が示すメモリ使用率から過去に収集した最低のメモリ使用率を減算した値に前記アプリケーションに割当られたメモリ量と所定の値とを乗算して前記アプリケーションを実行する際の負荷の増減量を算出し、当該算出した増減量に基づいて、前記アプリケーションに割当るリソース量を決定する
   処理を実行することを特徴とするリソース制御方法。
10. アプリケーションに対して割当るリソース量を制御する制御装置が、
    前記アプリケーションを実行する情報処理装置から、同一のサービスを提供するための複数のアプリケーションのうち、代表となるアプリケーションによるメモリ使用率を示す負荷情報を収集し、
    前記収集した負荷情報が示す負荷が所定の閾値を超えているか否かを判定し、
    前記負荷が所定の閾値を超えていると判定した場合は、前記収集した負荷情報と、過去に収集した負荷情報とを用いて、前記アプリケーションを実行する際の負荷の増減量を算出し、当該算出した増減量に基づいて、前記アプリケーションに割当るリソース量を決定する
    処理を実行することを特徴とするリソース制御方法。

Images