特許 7485590 制御装置、情報処理システム、制御方法及びコンピュータプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-05-08

(45)【発行日】2024-05-16

(54)【発明の名称】制御装置、情報処理システム、制御方法及びコンピュータプログラム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240509BHJP

【ＦＩ】

G06F9/50 120A

【請求項の数】 13

(21)【出願番号】P 2020197240

(22)【出願日】2020-11-27

(65)【公開番号】P2022085510

(43)【公開日】2022-06-08

【審査請求日】2023-02-22

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100165179

【弁理士】

【氏名又は名称】田▲崎▼ 聡

(74)【代理人】

【識別番号】100175824

【弁理士】

【氏名又は名称】小林 淳一

(74)【代理人】

【識別番号】100114937

【弁理士】

【氏名又は名称】松本 裕幸

(72)【発明者】

【氏名】森澤 雄太

【審査官】田中 幸雄

(56)【参考文献】

【文献】特表２０１７－５３３５０２（ＪＰ，Ａ）

【文献】特開２０１７－１０７２７４（ＪＰ，Ａ）

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

Ｇ０６Ｆ ９／５０

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

【請求項1】

コンピュータ上で起動された状態になっている実行ノードをプールするプール部と、
アプリケーションからの要求に応じて、前記プール部にプールされている実行ノードを前記アプリケーションに割り当てる割当部と、
複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プール部の所要のプールサイズを算出する所要プールサイズ算出部と、を備え、
前記プール部は、前記所要プールサイズ算出部が算出した結果のプールサイズに基づいて、自己のプールサイズを変え、
前記所要プールサイズ算出部は、前記複数のアプリケーションを対象にして、要求遅延を満たすことができないデータ量の総和の期待値が予めユーザによって設定された閾値を下回るように、前記プール部の所要のプールサイズを算出する、
制御装置。

【請求項2】

前記所要プールサイズ算出部は、プールサイズ候補毎に、各トラヒック増加パターンについて要求遅延を満たすことができないデータ量の総和を算出し、当該算出された総和から前記期待値を算出し、当該算出された前記期待値が前記閾値を下回るプールサイズ候補を前記プール部の所要のプールサイズに決定する、
請求項１に記載の制御装置。

【請求項3】

コンピュータ上で起動された状態になっている実行ノードをプールするプール部と、
アプリケーションからの要求に応じて、前記プール部にプールされている実行ノードを前記アプリケーションに割り当てる割当部と、
複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プール部の所要のプールサイズを算出する所要プールサイズ算出部と、を備え、
前記プール部は、前記所要プールサイズ算出部が算出した結果のプールサイズに基づいて、自己のプールサイズを変え、
前記所要プールサイズ算出部は、前記複数のアプリケーション毎に、前記プール部の所要のプールサイズの算出対象の時間幅に少なくとも１回は突発的にトラヒックの増加が発生する確率と追加の計算リソース量の平均値とに基づいて追加の計算リソース量の期待値を算出し、当該算出された各アプリケーションの期待値のうち最大の期待値から前記プール部の所要のプールサイズを決定する、
制御装置。

【請求項4】

コンピュータ上で起動された状態になっている実行ノードをプールするプール部と、
アプリケーションからの要求に応じて、前記プール部にプールされている実行ノードを前記アプリケーションに割り当てる割当部と、
複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プール部の所要のプールサイズを算出する所要プールサイズ算出部と、を備え、
前記プール部は、前記所要プールサイズ算出部が算出した結果のプールサイズに基づいて、自己のプールサイズを変え、
前記プール部は、前記所要プールサイズ算出部が算出した結果のプールサイズに対して現在のプールサイズが不足する場合に、コンピュータ上で起動された状態なっている実行ノードを追加してプールする、
制御装置。

【請求項5】

コンピュータ上で起動された状態になっている実行ノードをプールするプール部と、
アプリケーションからの要求に応じて、前記プール部にプールされている実行ノードを前記アプリケーションに割り当てる割当部と、
を備え、
前記割当部は、アプリケーションからの要求において、
至急フラグがオンされている場合に、前記プール部にプールされている実行ノードを前記アプリケーションに割り当てる、
一方、至急フラグがオフされている場合には、前記プール部にプールされている実行ノード以外の他の実行ノードを前記アプリケーションに割り当てる、
制御装置。

【請求項6】

前記割当部は、要求遅延を満たせないデータ量が少なくなるように、実行ノードの割り当てを行う、
請求項１から５のいずれか１項に記載の制御装置。

【請求項7】

前記割当部は、要求遅延を満たせないアプリケーションの個数が最も少なくなるように、実行ノードの割り当てを行う、
請求項１から５のいずれか１項に記載の制御装置。

【請求項8】

コンピュータ上で起動された状態になっている実行ノードと、
請求項１から７のいずれか１項に記載の制御装置と、
を備える情報処理システム。

【請求項9】

制御装置が、コンピュータ上で起動された状態になっている実行ノードをプールするプールステップと、
前記制御装置が、アプリケーションからの要求に応じて、前記プールステップでプールされている実行ノードを前記アプリケーションに割り当てる割当ステップと、
前記制御装置が、複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プールステップの所要のプールサイズを算出する所要プールサイズ算出ステップと、を含み、
前記プールステップは、前記所要プールサイズ算出ステップが算出した結果のプールサイズに基づいて、自己のプールサイズを変え、
前記所要プールサイズ算出ステップは、前記複数のアプリケーションを対象にして、要求遅延を満たすことができないデータ量の総和の期待値が予めユーザによって設定された閾値を下回るように、前記プールステップの所要のプールサイズを算出する、
制御方法。

【請求項10】

制御装置が、コンピュータ上で起動された状態になっている実行ノードをプールするプールステップと、
前記制御装置が、アプリケーションからの要求に応じて、前記プールステップでプールされている実行ノードを前記アプリケーションに割り当てる割当ステップと、
前記制御装置が、複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プールステップの所要のプールサイズを算出する所要プールサイズ算出ステップと、を含み、
前記プールステップは、前記所要プールサイズ算出ステップが算出した結果のプールサイズに基づいて、自己のプールサイズを変え、
前記所要プールサイズ算出ステップは、前記複数のアプリケーション毎に、前記プールステップの所要のプールサイズの算出対象の時間幅に少なくとも１回は突発的にトラヒックの増加が発生する確率と追加の計算リソース量の平均値とに基づいて追加の計算リソース量の期待値を算出し、当該算出された各アプリケーションの期待値のうち最大の期待値から前記プールステップの所要のプールサイズを決定する、
制御方法。

【請求項11】

制御装置が、コンピュータ上で起動された状態になっている実行ノードをプールするプールステップと、
前記制御装置が、アプリケーションからの要求に応じて、前記プールステップでプールされている実行ノードを前記アプリケーションに割り当てる割当ステップと、
前記制御装置が、複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プールステップの所要のプールサイズを算出する所要プールサイズ算出ステップと、を含み、
前記プールステップは、前記所要プールサイズ算出ステップが算出した結果のプールサイズに基づいて、自己のプールサイズを変え、
前記プールステップは、前記所要プールサイズ算出ステップが算出した結果のプールサイズに対して現在のプールサイズが不足する場合に、コンピュータ上で起動された状態なっている実行ノードを追加してプールする、
制御方法。

【請求項12】

制御装置が、コンピュータ上で起動された状態になっている実行ノードをプールするプールステップと、
前記制御装置が、アプリケーションからの要求に応じて、前記プールステップでプールされている実行ノードを前記アプリケーションに割り当てる割当ステップと、を含み、
前記割当ステップは、アプリケーションからの要求において、
至急フラグがオンされている場合に、前記プールステップにプールされている実行ノードを前記アプリケーションに割り当てる、
一方、至急フラグがオフされている場合には、前記プールステップにプールされている実行ノード以外の他の実行ノードを前記アプリケーションに割り当てる、
制御方法。

【請求項13】

請求項９から１２のいずれか１項に記載の制御方法をコンピュータに実行させるためのコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、制御装置、情報処理システム、制御方法及びコンピュータプログラムに関する。

【背景技術】

【0002】

従来、データが発生した時に所定のアプリケーションにより逐次にデータ処理を実行するストリーム処理が知られている。ストリーム処理によれば、逐次に発生するデータに対してリアルタイムに集計や分析等の処理を行うことができる。ストリーム処理を実行する情報処理技術として例えば特許文献１や非特許文献１に記載の技術が知られている。特許文献１に記載の従来技術では、スイッチがデータの一次処理を実行し、その実行結果をストリームクラスタへ転送している。スイッチはサーバから受領した記述子に基づいてストリームの処理を実行する。非特許文献１には、アプリケーションによるストリーム処理を実行する「Worker Node」と、アプリケーションのジョブのスケジューリングを行う「Driver Program」と、リソースを管理する「Cluster Manager」とを備える分散ストリーム処理システムが記載されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特許第５８０２２１５号公報

【非特許文献】

【0004】

【文献】Apache Spark、“Cluster Mode Overview”、インターネット＜ＵＲＬ：https://spark.apache.org/docs/latest/cluster-overview.html＞

【発明の概要】

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

【0005】

上述した分散ストリーム処理システムでは、同じストリーム処理を実行する複数の「Worker Node」に負荷を分散して大量のデータをリアルタイムに処理することが可能である。ここで、ストリーム処理への将来の入力データ量が現在の処理能力を超えると予測された場合、新規に「Worker Node」を起動して追加することが考えられる。しかしながら、将来の入力データ量が突発的に増大する場合には、新規に「Worker Node」を起動して追加するだけの時間的余裕がない可能性がある。そして、新規に「Worker Node」を起動して追加することが時間的に間に合わないと、突発的に増大した入力データを処理することができない。

【0006】

本発明は、このような事情を考慮してなされたものであり、その目的は、ストリーム処理への入力データ量が突発的に増大することに対処することを図ることにある。

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

【0007】

（１）本発明の一態様は、コンピュータ上で起動された状態になっている実行ノードをプールするプール部と、アプリケーションからの要求に応じて、前記プール部にプールされている実行ノードを前記アプリケーションに割り当てる割当部と、複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プール部の所要のプールサイズを算出する所要プールサイズ算出部と、を備え、前記プール部は、前記所要プールサイズ算出部が算出した結果のプールサイズに基づいて、自己のプールサイズを変え、前記所要プールサイズ算出部は、前記複数のアプリケーションを対象にして、要求遅延を満たすことができないデータ量の総和の期待値が予めユーザによって設定された閾値を下回るように、前記プール部の所要のプールサイズを算出する、制御装置である。
（２）本発明の一態様は、前記所要プールサイズ算出部は、プールサイズ候補毎に、各トラヒック増加パターンについて要求遅延を満たすことができないデータ量の総和を算出し、当該算出された総和から前記期待値を算出し、当該算出された前記期待値が前記閾値を下回るプールサイズ候補を前記プール部の所要のプールサイズに決定する、上記（１）の制御装置である。
（３）本発明の一態様は、コンピュータ上で起動された状態になっている実行ノードをプールするプール部と、アプリケーションからの要求に応じて、前記プール部にプールされている実行ノードを前記アプリケーションに割り当てる割当部と、複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プール部の所要のプールサイズを算出する所要プールサイズ算出部と、を備え、前記プール部は、前記所要プールサイズ算出部が算出した結果のプールサイズに基づいて、自己のプールサイズを変え、前記所要プールサイズ算出部は、前記複数のアプリケーション毎に、前記プール部の所要のプールサイズの算出対象の時間幅に少なくとも１回は突発的にトラヒックの増加が発生する確率と追加の計算リソース量の平均値とに基づいて追加の計算リソース量の期待値を算出し、当該算出された各アプリケーションの期待値のうち最大の期待値から前記プール部の所要のプールサイズを決定する、制御装置である。
（４）本発明の一態様は、コンピュータ上で起動された状態になっている実行ノードをプールするプール部と、アプリケーションからの要求に応じて、前記プール部にプールされている実行ノードを前記アプリケーションに割り当てる割当部と、複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プール部の所要のプールサイズを算出する所要プールサイズ算出部と、を備え、前記プール部は、前記所要プールサイズ算出部が算出した結果のプールサイズに基づいて、自己のプールサイズを変え、前記プール部は、前記所要プールサイズ算出部が算出した結果のプールサイズに対して現在のプールサイズが不足する場合に、コンピュータ上で起動された状態なっている実行ノードを追加してプールする、制御装置である。
（５）本発明の一態様は、コンピュータ上で起動された状態になっている実行ノードをプールするプール部と、アプリケーションからの要求に応じて、前記プール部にプールされている実行ノードを前記アプリケーションに割り当てる割当部と、を備え、前記割当部は、アプリケーションからの要求において、至急フラグがオンされている場合に、前記プール部にプールされている実行ノードを前記アプリケーションに割り当てる、一方、至急フラグがオフされている場合には、前記プール部にプールされている実行ノード以外の他の実行ノードを前記アプリケーションに割り当てる、制御装置である。
（６）本発明の一態様は、前記割当部は、要求遅延を満たせないデータ量が少なくなるように、実行ノードの割り当てを行う、上記（１）から（５）のいずれかの制御装置である。
（７）本発明の一態様は、前記割当部は、要求遅延を満たせないアプリケーションの個数が最も少なくなるように、実行ノードの割り当てを行う、上記（１）から（５）のいずれかの制御装置である。

【0008】

（８）本発明の一態様は、コンピュータ上で起動された状態になっている実行ノードと、上記（１）から（７）のいずれかの制御装置と、を備える情報処理システムである。

【0009】

（９）本発明の一態様は、制御装置が、コンピュータ上で起動された状態になっている実行ノードをプールするプールステップと、前記制御装置が、アプリケーションからの要求に応じて、前記プールステップでプールされている実行ノードを前記アプリケーションに割り当てる割当ステップと、前記制御装置が、複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プールステップの所要のプールサイズを算出する所要プールサイズ算出ステップと、を含み、前記プールステップは、前記所要プールサイズ算出ステップが算出した結果のプールサイズに基づいて、自己のプールサイズを変え、前記所要プールサイズ算出ステップは、前記複数のアプリケーションを対象にして、要求遅延を満たすことができないデータ量の総和の期待値が予めユーザによって設定された閾値を下回るように、前記プールステップの所要のプールサイズを算出する、制御方法である。
（１０）本発明の一態様は、制御装置が、コンピュータ上で起動された状態になっている実行ノードをプールするプールステップと、前記制御装置が、アプリケーションからの要求に応じて、前記プールステップでプールされている実行ノードを前記アプリケーションに割り当てる割当ステップと、前記制御装置が、複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プールステップの所要のプールサイズを算出する所要プールサイズ算出ステップと、を含み、前記プールステップは、前記所要プールサイズ算出ステップが算出した結果のプールサイズに基づいて、自己のプールサイズを変え、前記所要プールサイズ算出ステップは、前記複数のアプリケーション毎に、前記プールステップの所要のプールサイズの算出対象の時間幅に少なくとも１回は突発的にトラヒックの増加が発生する確率と追加の計算リソース量の平均値とに基づいて追加の計算リソース量の期待値を算出し、当該算出された各アプリケーションの期待値のうち最大の期待値から前記プールステップの所要のプールサイズを決定する、制御方法である。
（１１）本発明の一態様は、制御装置が、コンピュータ上で起動された状態になっている実行ノードをプールするプールステップと、前記制御装置が、アプリケーションからの要求に応じて、前記プールステップでプールされている実行ノードを前記アプリケーションに割り当てる割当ステップと、前記制御装置が、複数のアプリケーションについての過去に突発的に発生したトラヒックの増加に関する統計情報に基づいて、前記プールステップの所要のプールサイズを算出する所要プールサイズ算出ステップと、を含み、前記プールステップは、前記所要プールサイズ算出ステップが算出した結果のプールサイズに基づいて、自己のプールサイズを変え、前記プールステップは、前記所要プールサイズ算出ステップが算出した結果のプールサイズに対して現在のプールサイズが不足する場合に、コンピュータ上で起動された状態なっている実行ノードを追加してプールする、制御方法である。
（１２）本発明の一態様は、制御装置が、コンピュータ上で起動された状態になっている実行ノードをプールするプールステップと、前記制御装置が、アプリケーションからの要求に応じて、前記プールステップでプールされている実行ノードを前記アプリケーションに割り当てる割当ステップと、を含み、前記割当ステップは、アプリケーションからの要求において、至急フラグがオンされている場合に、前記プールステップにプールされている実行ノードを前記アプリケーションに割り当てる、一方、至急フラグがオフされている場合には、前記プールステップにプールされている実行ノード以外の他の実行ノードを前記アプリケーションに割り当てる、制御方法である。

【0010】

（１３）本発明の一態様は、上記（９）から（１２）のいずれかの制御方法をコンピュータに実行させるためのコンピュータプログラムである。

【発明の効果】

【0011】

本発明によれば、ストリーム処理への入力データ量が突発的に増大することに対処することができるという効果が得られる。

【図面の簡単な説明】

【0012】

【図1】一実施形態に係る情報処理システムの構成例を示す図である。

【図2】一実施形態に係る実行ノードプール管理テーブルの構成例を示す図である。

【図3】一実施形態に係る制御方法の手順の例を示すシーケンス図である。

【図4】一実施形態に係る実行ノード割当方法の手順の例を示すフローチャートである。

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

【0013】

以下、図面を参照し、本発明の実施形態について説明する。
図１は、一実施形態に係る情報処理システム１の構成例を示す図である。図１において、情報処理システム１は、制御装置１０と、アプリケーションクラスタ（アプリケーション群）１００と、サーバシステム２００とを備える。これらは通信により情報を送受する。

【0014】

制御装置１０は、アプリケーションクラスタ１００に対する計算リソース（計算資源）の割り当てに関する制御を行う。アプリケーションクラスタ１００は、複数のアプリケーションａｐｐ１，ａｐｐ２，ａｐｐ３，・・・が属するクラスタである。以下、アプリケーションａｐｐ１，ａｐｐ２，ａｐｐ３，・・・を特に区別しないときはアプリケーションａｐｐと称する。

【0015】

アプリケーションａｐｐは、ストリーム処理を行うアプリケーションである。本実施形態では、各アプリケーションａｐｐは、異なるデータに対して異なるストリーム処理を実行する。言い換えると、同一データに対してストリーム処理を行うアプリケーションａｐｐは全て同一のものとみなす。また、各アプリケーションａｐｐには、それぞれ許容されるストリーム処理の上限遅延が要求遅延として設定される。そして、情報処理システム１において、その要求遅延を超過するデータの割合が一定の閾値を下回ることが要求される。

【0016】

サーバシステム２００は、一又は複数のサーバコンピュータ２１０と、サーバ管理装置２２０とを備える。サーバシステム２００は、例えば、クラウドコンピューティングを実現するシステムであってもよい。また、制御装置１０が、サーバシステム２００によるクラウドコンピューティングによって実現されてもよい。

【0017】

一のサーバコンピュータ２１０において、一又は複数の実行ノード２３０が存在し得る。実行ノード２３０は、サーバコンピュータ２１０上で起動された状態になっているノードである。実行ノード２３０には、自己が存在するサーバコンピュータ２１０の計算リソースが割り当てられている。計算リソースとして、ＣＰＵ（Central Processing Unit：中央演算処理装置）やメモリやストレージやネットワークなどがある。本実施形態では、各実行ノード２３０に割り当てられる計算リソース量は同一である。実行ノード２３０は、自己に割り当てられている計算リソースを使用して情報処理を実行することができる状態（起動された状態）にある。

【0018】

サーバ管理装置２２０は、各サーバコンピュータ２１０の計算リソースを管理する。サーバ管理装置２２０は、各サーバコンピュータ２１０に対して、実行ノード２３０の起動及び解放を制御する。サーバコンピュータ２１０は、サーバ管理装置２２０から実行ノード２３０の起動命令を受けると、新規に起動する実行ノード２３０のために自己の計算リソースを確保して新規に実行ノード２３０を起動する。サーバコンピュータ２１０は、サーバ管理装置２２０から実行ノード２３０の解放命令を受けると、解放対象の実行ノード２３０に割り当てていた計算リソースを解放して当該実行ノード２３０の起動を停止する。

【0019】

制御装置１０は、プール部１１と、割当部１２と、所要プールサイズ算出部１３と、メトリスク収集部１４とを備える。プール部１１は、実行ノードプール管理テーブル２０を備える。

【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】

また、上述した各装置の機能を実現するためのコンピュータプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行するようにしてもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＤＶＤ（Digital Versatile Disc）等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。

【0069】

さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

【符号の説明】

【0070】

１…情報処理システム、１０…制御装置、１１…プール部、１２…割当部、１３…所要プールサイズ算出部、１４…メトリスク収集部、２０…実行ノードプール管理テーブル、１００…アプリケーションクラスタ、ａｐｐ（ａｐｐ１，ａｐｐ２，ａｐｐ３）…アプリケーション、２００…サーバシステム、２１０…サーバコンピュータ、２２０…サーバ管理装置、２３０…実行ノード

【図1】

【図2】

【図3】

【図4】