JP6924083B2 - 情報処理システムおよびリソース割り当て方法 - Google Patents

Description

本発明は、リソース割り当て方法およびその情報処理システムに関するものである。

近年、コンテナと呼ばれる仮想化技術の発展により、様々なアプリケーションプログラム（以下、アプリケーション）の実行環境を迅速に立ち上げることができるようになった。これにより、クラウドサービス提供者は、クラウド上で提供する様々なアプリケーションの実行環境向けに、それぞれ専用のリソースを確保することなく、アプリケーション共通のリソースプールを確保し、ユーザのアプリケーション実行要求毎に、リソースプールにアプリケーションに対応したコンテナをデプロイするだけで、アプリケーションの実行環境を構築できるようになり、リソースプールとして確保しておくべきリソース量を削減することができる。

しかし、リソースプールのリソース量を削減しすぎると、多数のユーザのアプリケーション実行要求がタイミング悪く重なった場合に、リソースが枯渇する可能性がある。リソースが枯渇すると、空きリソース待ちやクラウドからの新規のリソース取得等の待機時間が発生し、応答性が悪化する。特に、ユーザのアプリケーション実行要求が、本来、短時間で終了するような要求であった場合、要求に対する待機時間の割合が相対的に非常に大きくなり、高速応答を期待したユーザに対して、サービス品質を大きく低下させる要因となる。

このような分野の背景技術として、特許文献１では、サービス義務を果たすのに必要なリソースのフリープール・サイズを推定するモデル化方法を開示している。

特表２００９−５２４１３５号公報

特許文献１に記載されたモデル化方法は、顧客のリソース利用率をベータ分布としてモデル化し（段落［０００９］）、ベータ分布シミュレーションを用いて利用率目標を達成するのに必要なフリープール・サイズを予測する（段落［００１５］）。これにより、リソースプールが枯渇しそうなタイミングを予測して、リソースを増加させることができる。

しかしながら、特許文献１に記載されているモデル化方法では、リソース利用量が徐々に変化する場合は有効であるが、突発的に発生した多数のユーザからのアプリケーション実行要求には対応できない。この予想が外れたアプリケーション実行要求が、短時間で終了する要求であった場合、サービス品質を低下させる問題は解決されない。

そこで、本発明は、計算機リソースプールが枯渇している場合でも、アプリケーションプログラムを迅速に開始することができ、短時間で終了するアプリケーションでもサービス品質を低下させること無く、処理を完了させる情報処理システムを提供することを目的とする。

本発明の情報処理システムの好ましい例では、管理サーバと、複数の処理サーバを有し、ユーザからの要求に応じてネットワークを介してアプリケーションプログラムの実行を提供する情報処理システムであって、前記処理サーバはそれぞれ、アプリケーションプログラムを実行するための１以上のプロセッサを有し、前記管理サーバは、それぞれの前記処理サーバとして実行可能な計算機リソースと、前記計算機リソースの使用状態、及び１つのアプリケーションプログラムを実行しているクラスタごとに、クラスタ利用状況やユーザからの要求情報、アプリケーションプログラムの実行時間に関する情報を管理しており、前記管理サーバのクラスタ生成部は、ユーザから前記アプリケーションプログラムの実行要求と共に、その実行の並列度と予想実行時間を受領した際に、前記管理サーバが管理していた計算機リソースに空きがない場合で無く、かつ実行要求の対象である前記アプリケーションプログラムの予想実行時間が基準時間値以下である場合に、前記管理サーバで管理している使用中の計算機リソースの中から、一時的にアプリケーションプログラムを複数同時に実行しても、当初の予想実行時間からの変動割合が相対的に小さいアプリケーションプログラムが実行されている計算機リソースを選定して、前記選定した計算機リソースに対して、実行要求の対象である前記アプリケーションプログラムを配置して、実行するように構成する。

また、本発明の他の特徴として、前記情報処理システムにおいて、前記管理サーバのクラスタ生成部は、一時的にアプリケーションプログラムを複数同時に実行しても、当初の予想実行時間からの変動割合が相対的に小さいアプリケーションプログラムが実行されている計算機リソースを選定する際に、残り時間が大きく、かつ共存数が小さく、かつ共存時間が小さく、かつＰｏｏｌ利用数が多いクラスタに属する計算機リソースを優先的に選定する。

また、本発明の更に他の特徴として、前記情報処理システムにおいて、前記管理サーバのクラスタ生成部は、一時的にアプリケーションプログラムを複数同時に実行しても、当初の予想実行時間からの変動割合が相対的に小さいアプリケーションプログラムが実行されている計算機リソースを選定する際に、残り時間、共存数、共存時間、およびＰｏｏｌ利用数の各情報の大小の値に重み係数を掛けて優先度を設定したクラスタに属する計算機リソースを優先的に選定する。

また、本発明のリソース割り当て方法の好ましい例では、管理サーバと、複数の処理サーバを有し、ユーザからの要求に応じてネットワークを介してアプリケーションプログラムの実行を提供する情報処理システムにおいて、前記処理サーバはそれぞれ、アプリケーションプログラムを実行するための１以上のプロセッサを有し、前記管理サーバは、それぞれの前記処理サーバとして実行可能な計算機リソースと、前記計算機リソースの使用状態、及び１つのアプリケーションプログラムを実行しているクラスタごとに、クラスタ利用状況やユーザからの要求情報、アプリケーションプログラムの実行時間に関する情報を管理しており、前記管理サーバが、ユーザからアプリケーションプログラムの実行要求と共に、その実行の並列度と予想実行時間を受領した際に、前記管理サーバが管理していた計算機リソースに空きが無く、かつ実行要求の対象である前記アプリケーションプログラムの予想実行時間が基準値以下である場合に、前記管理サーバで管理している使用中の計算機リソースの中から、一時的にアプリケーションプログラムを複数同時に実行しても、当初の予想実行時間からの変動割合が相対的に小さいアプリケーションプログラムが実行されている計算機リソースを選定して、前記選定した計算機リソースに対して、実行要求の対象である前記アプリケーションプログラムを配置して、実行するように構成する。

本発明によれば、リソースプールが枯渇している場合でも、アプリケーションプログラムを迅速に開始することができ、短時間で終了するアプリケーションでもサービス品質を低下させること無く、処理を完了させることができる。

情報処理システムの全体構成の例を示す図である。 各種サーバの物理的な構成の例を示す図である。 リソース割り当て情報記憶部が管理するデータテーブルの例を示す図である。 アプリ進捗情報記憶部が管理するデータテーブルの例を示す図である。 アプリケーション実行依頼からリソースを割り当ててアプリケーションを実行するまでの動作フローの例を示す図である。 リソース割り当て処理の動作フローの例を示す図である。 クラスタ監視処理の動作フローの例を示す図である。 アプリケーション実行完了後にクラスタ破棄するまでの動作シーケンスの例を示す図である。 アプリケーション利用者が実行要求毎にアプリケーションや入力データや並列度や保障レベルを決定するための設定画面の例を示す図である。

以下、各実施例における実施形態について図面を参照して説明する。なお、以下の実施例に用いる図において、同一の符号を付した部分は同一物を表し、それらの構造および動作は同じである。

図１は、実施例１に係る情報処理システムの全体構成の例である。実施例１に係る情報システムは、クライアント端末１０１と、クライアント端末１０１とネットワーク１０２を介して接続されるリクエスト生成サーバ１０３、そしてネットワーク１０６を介してリクエスト生成サーバ１０３と接続されるデータ管理サーバ１０４、アプリ管理サーバ１０５、リソース管理サーバ１２０、複数の処理サーバ１３０を有する。図１ではクライアント端末１０１とそれ以外のサーバ（リクエスト生成サーバ１０３、データ管理サーバ１０４、アプリ管理サーバ１０５、リソース管理サーバ１２０、処理サーバ１３０）が異なるネットワーク（１０２，１０６）に接続されているが、クライアント端末１０１とそれ以外のサーバが同一ネットワークに接続されるように、情報処理システムが構成されていてもよい。

クライアント端末１０１は、アプリケーション利用者が使用する端末であり、アプリケーション利用者が、アプリケーションプログラム（以下、「アプリケーション」と略記する）に処理させるための入力データを作成して、リクエスト生成サーバ１０３にアプリケーションの処理要求を入力データとともに送信するために用いられる。クライアント端末１０１はたとえば、会社や工場内の、または一般の個人のパーソナルコンピュータやサーバであり、複数台存在する。あるいはクライアント端末１０１は、スマートフォンやタブレット端末などの、通信機能を有する通信デバイスであってもよい。

ネットワーク１０２は、通信キャリアなどによって提供される無線ネットワークまたは有線ネットワークである。ネットワーク１０２は、個別の会社などが所有するネットワークを、ネットワーク１０２の一部に含んでもよく、複数種類のプロトコルを通過させるネットワークであってもよい。

リクエスト生成サーバ１０３は、クライアント端末１０１からアプリケーション実行要求などの処理要求を受け付け、受け付けた処理要求に基づき、データ管理サーバ１０４、アプリ管理サーバ１０５、リソース管理サーバ１２０、処理サーバ１３０に処理依頼を行い、処理結果をクライアント端末１０１に返信する処理を実行するサーバである。

データ管理サーバ１０４は、処理要求を受け付けたアプリケーションの実行時に処理対象となるデータ（入力データ）を格納するサーバであり、入力データがファイルの場合は共有ファイルサーバ、レコードとして格納しておく場合は構造データベースサーバ、ｊｓｏｎなどの形式で格納しておく場合はキーバリューストアなどの非構造データベースなどのデータを格納するサーバである。

アプリ管理サーバ１０５は、処理サーバ１３０で実行されるアプリケーションの情報を管理するとともに、入力データや計算機リソースを設定することでアプリケーションの実行処理時間の見積もり値を計算するサーバである。

アプリケーションの実行処理時間の見積もり方法は、アプリケーションが処理するデータ量やパラメータなどから算出され、アプリケーションごとにそれぞれ計算ロジックを予め設計時に作成して有するか、もしくは過去のアプリケーションの実行処理時間の履歴から統計的に算出する方法がある。

リソース管理サーバ１２０は、各処理サーバ１３０の利用状態を管理して、クラスタの生成や監視や破棄を動的に行うサーバであり、リソース割り当て情報記憶部１２１、アプリ進捗情報記憶部１２２、クラスタ生成部１２３、クラスタ監視部１２４、クラスタ破棄部１２５、を有する。本実施例では、１つのアプリケーションを実行する際に使用される計算機リソースの集合（あるいはこの計算機リソースを有する処理サーバ１３０の集合）を「クラスタ」と呼ぶ。

処理サーバ１３０は、アプリ管理サーバ１０５が管理しているアプリケーションを実行するためのサーバであり、アプリ管理サーバ１０５からデプロイメントされたアプリケーションの実行コードを記憶するアプリケーション管理部１３１を有する。アプリケーション管理部１３１には、複数のアプリケーションが登録されてもよい。複数のアプリケーションが登録されている場合、クラスタはアプリケーションの処理要求ごとに生成されるため、処理サーバ１３０は複数のクラスタに属していることとなり、それぞれのクラスタ内に属する１つ以上の処理サーバ１３０へ各アプリケーションの処理が割り振られることとなる。

本実施例では、これらのサーバがそれぞれ物理的に異なる計算機である例を説明する。ただし必ずしもこれらのサーバが、異なる計算機である必要はなく、上で述べたいくつかのサーバが有する機能部が、単一の計算機上に実装されていてもよい。たとえば情報処理システム内に、上で述べたリクエスト生成サーバ１０３、データ管理サーバ１０４、アプリ管理サーバ１０５、リソース管理サーバ１２０に代えて、１台の計算機（仮に「管理サーバ」と呼ぶ）を設け、上で述べたリクエスト生成サーバ１０３、データ管理サーバ１０４、アプリ管理サーバ１０５、リソース管理サーバ１２０が有する機能部を、その管理サーバ上に設けてもよい。あるいは、処理サーバの１つ（または複数）が、管理サーバとして用いられてもよい。

さらに別の実施形態として、情報処理システム内に設けられた１台または複数台の計算機上で、いわゆる仮想計算機を提供するためのソフトウェア（一般的にハイパーバイザと呼ばれる）を実行させ、計算機上に、リクエスト生成サーバの役割を果たす仮想計算機、データ管理サーバの役割を果たす仮想計算機、アプリ管理サーバの役割を果たす仮想計算機、リソース管理サーバの役割を果たす仮想計算機を定義することで、情報処理システムが構成されてもよい。

図２は、図１で示したリクエスト生成サーバ１０３、データ管理サーバ１０４、アプリ管理サーバ１０５、リソース管理サーバ１２０、処理サーバ１３０、クライアント端末１０１の物理的な構成を示す図である。本実施例ではこれらのサーバ（またはクライアント端末）には、プロセッサ（ＣＰＵ）２０１、メモリ２０２、補助記憶装置２０３、及び通信インターフェース（通信Ｉ／Ｆ）２０４を有する計算機２００が用いられる。この計算機は一例として、パーソナルコンピュータ（ＰＣ）等の汎用的な計算機でよい。

プロセッサ２０１は、メモリ２０２に格納されたプログラムを実行する。プロセッサ２０１の数は１とは限らない。計算機２００は複数のプロセッサ２０１を有していてもよい。またプロセッサ２０１は複数のプロセッサコアを有する、いわゆるマルチコアプロセッサであってもよい。メモリ２０２は、不揮発性の記憶素子であるＲＯＭ及び揮発性の記憶素子であるＲＡＭを含む。ＲＯＭは、不変のプログラム（例えば、ＢＩＯＳ）などを格納する。ＲＡＭは、ＤＲＡＭ（Dynamic Random Access Memory）のような高速かつ揮発性の記憶素子であり、プロセッサ２０１が実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。

補助記憶装置２０３は、例えば、磁気記憶装置（ＨＤＤ）、フラッシュメモリ（ＳＳＤ）等の大容量かつ不揮発性の記憶装置であり、プロセッサ２０１が実行するプログラム及びプログラムの実行時に使用されるデータを格納する。すなわち、プログラムは、補助記憶装置２０３から読み出されて、メモリ２０２にロードされて、プロセッサ２０１によって実行される。

通信インターフェース２０４は、所定のプロトコルに従って、他の装置との通信を制御するネットワークインターフェース装置である。

計算機２００はまた、入力インターフェース（入力Ｉ／Ｆ）２０５及び出力インターフェース（出力Ｉ／Ｆ）２０８を有してもよい。入力インターフェース２０５は、キーボード２０６やマウス２０７などが接続され、オペレータからの入力を受けるインターフェースである。出力インターフェース２０８は、ディスプレイ装置２０９やプリンタなどが接続され、プログラムの実行結果をオペレータが視認可能な形式で出力するインターフェースである。

なお、本実施例では、アプリ管理サーバ１０５、リソース管理サーバ１２０、処理サーバ１３０の有する各機能部は、ソフトウェア（プログラム）によって実装されるものとする。たとえばリソース管理サーバ１２０では、リソース管理サーバ１２０をリソース割り当て情報記憶部１２１とアプリ進捗情報記憶部１２２とクラスタ生成部１２３とクラスタ監視部１２４とクラスタ破棄部１２５として機能させるためのプログラムが、リソース管理サーバ１２０（計算機２００）のメモリ２０２上にロードされ、プロセッサ２０１により実行される。これによりリソース管理サーバ１２０は、リソース割り当て情報記憶部１２１とアプリ進捗情報記憶部１２２とクラスタ生成部１２３とクラスタ監視部１２４とクラスタ破棄部１２５を有する装置として動作する。

処理サーバ１３０でも同様に、計算機２００（リソース管理サーバ１２０や処理サーバ１３０）のプロセッサ２０１で、上で述べた各機能部を実現するためのプログラムが実行される。これによって処理サーバ１３０は、上で述べた各機能部を有する装置として動作する。以下では、アプリ管理サーバ１０５やリソース管理サーバ１２０、あるいは処理サーバ１３０等で実行される処理を説明する際に、リソース割り当て情報記憶部１２１やクラスタ生成部１２３等の機能部を主語とした説明を行うことがあるが、それは実際には、機能部を有する計算機２００のプロセッサ２０１が処理を行うことを意味する。

また、プロセッサ２０１が実行するプログラムは、計算機が読み取り可能な記憶メディア又はネットワークを介して計算機２００に提供され、非一時的記憶媒体である補助記憶装置２０３に格納される。計算機が読み取り可能な記憶メディアとは、非一時的なコンピュータ可読媒体で、たとえばＣＤ−ＲＯＭやフラッシュメモリなどの、不揮発性のリムーバブルメディアである。このため計算機２００は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。

また、別の実施形態として、各機能部の一部またはすべては、ＦＰＧＡやＡＳＩＣなどのハードウェアを用いて実装されていてもよい。

図３は、リソース管理サーバ１２０内に保持されているリソース割り当て情報記憶部１２１が管理するデータテーブル３００の例を示す図である。本実施例ではリソース割り当て情報記憶部１２１が、メモリ２０２や補助記憶装置２０３の記憶領域上に形成されたデータテーブル３００に、各種情報を記憶させる例を説明する。

リソース割り当て情報記憶部１２１は、アプリケーションを配置可能な全ての処理サーバ１３０の情報を管理しており、またこれらの処理サーバ１３０のうち、同一アプリケーションが配置されて、クラスタを形成している処理サーバ１３０の情報もデータテーブル３００に格納して管理している。

リソース割り当て情報記憶部１２１が管理するデータテーブル３００の各行（レコード）は、図３に示す７つのカラム（欄）を有し、各レコードには情報処理システム内の処理サーバ１３０についての情報が格納される。ノード名３０１欄は、処理サーバ１３０の名称を格納するための欄である。各処理サーバ１３０は情報処理システム内で一意な名称を有しており、本実施例ではその名称を「ノード名」と呼ぶ。IPアドレス３０２欄には、ノード名３０１で特定される処理サーバ１３０のＩＰアドレスが格納される。ＣＰＵ Ｃｏｒｅ３０３欄には、処理サーバ１３０の有するプロセッサコア（ＣＰＵ Ｃｏｒｅ）の数が格納される。

Ｐｏｏｌフラグ３０４欄は、処理サーバ１３０が情報処理システムとして事前に確保した計算機リソースのノードであるかどうかを表すフラグ情報が格納される。事前に確保しているノード(事前にクラウド等から確保しているノードを含む)の場合は「○」が格納され、アプリケーションの実行要求に対して、必要に応じてクラウド等から一時的に確保したノードの場合は「−」が格納される。

クラスタ名３０５欄には、処理サーバ１３０がクラスタに属している場合、所属しているクラスタの名称が格納され、並列数３０６欄には、クラスタに割り当てられているプロセッサコア数が格納される。そのため、ＣＰＵ Ｃｏｒｅ３０３と並列数３０６の差を算出することで、まだいずれのクラスタにも割り当てられていないプロセッサコア（「未使用コア」と呼ぶ）の数が求められる。またアプリ名３０７欄には、処理サーバ１３０に配置されているアプリケーションのアプリ名が格納される。アプリケーションの名称とは、アプリケーション利用者が、アプリケーションの実行を依頼する際に、アプリケーションを特定するために用いる名称である。

なお本実施例では、処理サーバ１３０がいわゆるマルチコアプロセッサを有することが前提で説明しているが、処理サーバ１３０の有するプロセッサがシングルコアプロセッサの場合、ＣＰＵ Ｃｏｒｅ３０３欄や並列数３０６欄には、プロセッサコア数に代えてプロセッサ数が格納される。

また本実施例では、リソース割り当て情報記憶部１２１が管理するデータテーブル３００の各レコードのうち、クラスタ名３０５が同じレコードの集合に含まれる情報、特にこれらのレコードのカラム３０５〜３０７の情報を、「クラスタ情報」と呼ぶ。図３において、行３１０−５と行３１０−６のカラム３０５〜３０７の情報がそれぞれ、クラスタ名“User5-AppB-1”のクラスタ情報、クラスタ名“User6-AppB-1”のクラスタ情報である。クラスタ情報を参照することで、クラスタに所属している処理サーバ１３０、ＣＰＵ Ｃｏｒｅ数を知ることができる。

後述するリソース管理サーバ１２０のクラスタ生成部１２３がクラスタを生成（定義）するとき、クラスタに所属させる処理サーバ１３０をデータテーブル３００の中から選択する。そして、クラスタ生成部１２３は、選択された処理サーバ１３０に対応するレコードのカラム３０５〜３０７に、クラスタ名や使用するＣＰＵ Ｃｏｒｅ数などの情報を格納する。本実施例ではクラスタ生成部１２３が、カラム３０５〜３０７に、クラスタ名等の情報を格納する処理を「クラスタ情報を作成する」処理と呼ぶ。クラスタ情報が作成されることにより、アプリケーションの実行に使用される計算機リソースが実質的に確保（予約）されることを意味する。

逆に、定義されたクラスタにおけるアプリケーションの実行が終了すると、クラスタ破棄部１２５がカラム３０５〜３０７からクラスタ名等の情報を削除する。この処理は「クラスタ情報を削除する」処理と呼ばれる。クラスタ情報の削除により、アプリケーションの実行のために確保されていた計算機リソースが実質的に解放され、解放された計算機リソースを他の用途に使用することができるようになる。

ここで、処理サーバ１３０としてクラウド（非図示）上の計算機リソースを使う場合、つまりクラスタ生成の要求ごとにクラウド上の計算機リソースを確保して使用する場合は、計算機リソースが確保されるたびにリソース割り当て情報記憶部１２１が管理するデータテーブル３００にレコードが追加され、アプリケーションの実行が終了してクラスタを削除すると、そのレコードが削除される。

また、処理サーバ１３０が複数のＣＰＵ Ｃｏｒｅを保持しており、アプリケーションの並列度が、処理サーバ１３０の有するＣＰＵ Ｃｏｒｅ数より少ない場合は、１つの処理サーバ１３０に複数のアプリケーションが配置されることもあり得る。その場合は、処理サーバ１３０は複数のクラスタに所属することになる。

また、本実施例では、処理サーバ１３０がｎ個のＣＰＵ Ｃｏｒｅを有している場合、基本的にはアプリケーションの実行コードをｎ個並列実行可能という前提で、計算機リソースの確保が行われる。そのため、アプリケーションの並列度が４の場合（アプリケーション利用者がアプリケーションを４並列実行させる要求をした場合）、リソース管理サーバ１２０のクラスタ生成部１２３（後述）は、未使用コアを有する処理サーバ１３０を１または複数選択する。その際、クラスタ生成部１２３は、選択された処理サーバ１３０が有する未使用コアの数が４つ（以上）になるように、処理サーバ１３０を選択する。

ただし、アプリケーションの特性によっては、ＣＰＵ Ｃｏｒｅの数以外に、メモリ量やＣＰＵの処理性能を考慮して、１または複数の処理サーバ１３０が選択されてもよい。

ここで、アプリケーションの並列度に対して、選択可能なＣＰＵ Ｃｏｒｅ数だけでは確保できない場合は、アプリケーションの予想実行時間を加味して、新たにクラウド等から計算機リソースを確保するか、すでに割り当て済みの処理サーバ１３０の中から、処理時間やユーザ要求に対して最も影響の少ない処理サーバ１３０を選択するかを判断する。詳細は、図６にて後述する。

図４は、リソース管理サーバ１２０内に保持されているアプリ進捗情報記憶部１２２が管理するデータテーブル４００の例を示す図である。

アプリ進捗情報記憶部１２２は、１つのアプリケーションを実行しているクラスタごとに、クラスタ利用状況やユーザからの要求情報、アプリケーションの実行時間に関する情報を格納する機能部で、これらの情報を格納するために、メモリ２０２や補助記憶装置２０３の記憶領域を用いる。アプリ進捗情報記憶部１２２は一例として、公知のファイルシステムプログラムまたはデータベース管理システム（ＤＢＭＳ）のようなプログラムを用いて実装されて良い。

アプリ進捗情報記憶部１２２が管理するデータテーブル４００は、図４に示されるように８つのカラム（欄）を有する。以下、各カラムに格納される情報について説明する。クラスタ名４０１欄には、ユーザからのアプリケーション実行要求ごとに生成される計算機リソースの集合であるクラスタを一意に表すクラスタ名が格納される。これは、リソース割り当て情報記憶部１２１が管理するデータテーブル３００のクラスタ名３０５と同じ名称が格納される。

並列数４０２欄には、クラスタ内で利用されているトータルのＣＰＵ Ｃｏｒｅ数が格納され、これは、リソース割り当て情報記憶部１２１が管理するデータテーブル３００の並列数３０６を同クラスタ内分足し合わせた数となる。

共存数４０３欄には、並列数４０２のうち、他のクラスタと共存しているＣＰＵ Ｃｏｒｅ数が格納される。

Ｐｏｏｌ利用数４０４欄には、並列数４０２のうち、リソース割り当て情報記憶部１２１が管理するデータテーブル３００のＰｏｏｌフラグ３０４が「○」となっている処理サーバ１３０のＣＰＵ Ｃｏｒｅを利用している数が格納される。

保障レベル４０５欄には、ユーザがアプリケーションの実行要求を出す際にユーザが設定する予想実行時間における保障レベルを表す情報が格納される。本実施例では、保障レベルを０，１，２という数値で表現しており、数字が高いほど、予想実行時間に対するブレが大きくなることを表す（予想実行時間よりも実際の実行時間がより長く掛かる許容範囲が大きくなることを表す）。例えば、保障レベル０であれば、予想実行時間とのブレが数分程度であり、保障レベル１であれば、予想実行時間とのブレが数十分程度、保障レベル２であれば、予想実行時間とのブレが数時間程度、ということを表す。すなわち、保障レベルは、ユーザが要求する予想実行時間の変動割合の許容度を表す。

残り時間４０６欄には、クラスタ内で実行されているアプリケーションの処理の進捗状況から算出された、アプリケーションが完了するまでの残り時間が格納される。アプリケーションの処理の進捗状況は、例えば、アプリケーションが実行する処理全体がＮ個だとして、そのうちＭ個まで処理が進んでいるため、現在の進捗はＭ／Ｎであり、予想実行時間と掛け合わせて、残り時間を算出する、などの計算を行う。進捗状況の算出方法はアプリケーションごとに異なるため、アプリケーション開発時に進捗状況を測定するロジックを組み込み、ログなどに出力することで、進捗状況を把握できるようにしておく。

当初終了予定時刻４０７欄には、ユーザからのアプリケーションの実行要求を受け取った際に、アプリケーションの予想実行時間から算出した終了予定時刻が格納される。

共存時間４０８欄には、クラスタ内のアプリケーションが、他のクラスタ内のアプリケーションとＣＰＵ Ｃｏｒｅを共存した時間が格納される。

アプリ進捗情報記憶部１２２が管理するデータテーブル４００に格納されている情報を利用して、ユーザからのアプリケーションの実行要求があったが、当該アプリケーションの実行に要求されたＣＰＵ Ｃｏｒｅ数が、選択可能なＣＰＵ Ｃｏｒｅ数だけでは確保できない場合で、すでに割り当て済みの処理サーバ１３０の中から処理時間やユーザ要求に対して最も影響の少ない処理サーバ１３０を選択するかを判断する。詳細は、図６にて後述する。

図５は、アプリケーション利用者が、本実施例に係る情報処理システムを用いてアプリケーションの実行を要求した時に、情報処理システム内の各サーバで行われる処理の流れを表したシーケンス図である。図５では、クライアント端末１０１がリクエスト生成サーバ１０３に要求を発行し、アプリケーションを実行するクラスタが生成されるまでの処理の流れが記述されている。

まず、アプリケーション利用者は、クライアント端末１０１を操作しながら、リクエスト生成サーバ１０３やアプリ管理サーバ１０５を利用して、実行要求調整（Ｓ５２０）を行う。実行要求調整（Ｓ５２０）では、アプリケーション利用者は、アプリ管理サーバ１０５が算出する予想実行時間やそれに掛かるコストを考慮しながら、利用するアプリケーションの選択、入力データの登録、アプリケーションを実行する際の並列度の設定、予想実行時間の保障レベルの設定を行う。

ここで、予想実行時間の算出に、アプリケーションの情報を管理しているアプリ管理サーバ１０５を利用することを想定している。

アプリケーション利用者が実行要求調整（Ｓ５２０）を行うと、クライアント端末１０１はアプリケーション利用者から、アプリケーション利用者が利用するアプリケーションのアプリ名と入力データを受け付け、リクエスト生成サーバ１０３にアプリケーションの実行依頼を送信する（Ｓ５０１）。このアプリケーションの実行依頼には、アプリ名（たとえば“ＡｐｐＡ”など）、入力データ、並列度、予想実行時間、保障レベルが含まれる。リクエスト生成サーバ１０３はこの実行依頼に応じて、まず入力データをデータ管理サーバ１０４に登録する（Ｓ５０２，Ｓ５０３）。データ管理サーバ１０４は入力データを受領すると、入力データへのアクセス方法であるアクセスＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をリクエスト生成サーバ１０３に返送する（Ｓ５０４）。この時、リクエスト生成サーバ１０３は、入力データへのＵＲＬとアプリ名とを対応付けて保持する。

次に、リクエスト生成サーバ１０３は、アプリケーション名と予想実行時間と並列度と保障レベルとアクセスＵＲＬを指定したクラスタ生成依頼をリソース管理サーバ１２０に送信する（Ｓ５０５）。

リソース管理サーバ１２０はクラスタ生成依頼（Ｓ５０５）を受け取ると、クラスタ生成部１２３の処理を実行する。クラスタ生成部１２３では、まず一意に識別可能なクラスタ名を作成し（Ｓ５０６）、並列度や保障レベルに応じた処理サーバ１３０の計算機リソース（ＣＰＵ Ｃｏｒｅ）の確保を行うためのリソース割り当て処理（Ｓ６００）を実行する。リソース割り当て処理（Ｓ６００）の詳細は図６にて後述する。

リソース割り当て処理（Ｓ６００）により、適切な処理サーバ１３０の割り当てを行い、割り当てられた処理サーバ１３０に対してアプリケーションを配置するため、まず、アプリ管理サーバ１０５からアプリケーションの実行コードを取得して（Ｓ５０７，Ｓ５０８）、各処理サーバ１３０にアプリケーションの配置を依頼する（Ｓ５０９）。

アプリケーションの配置を依頼された処理サーバ１３０は、アプリケーションをインストールし（Ｓ５１０）、クラスタに属する各処理サーバ１３０へのアプリケーションの配置が完了すると（Ｓ５１１）、リソース管理サーバ１２０はリソース割り当て情報記憶部１２１とアプリ進捗情報記憶部１２２が管理するデータテーブル情報を更新して（Ｓ５１２）、クラスタに属する１つないしは複数の処理サーバ１３０に対して、アクセスＵＲＬとともに実行要求を送信する（Ｓ５１３）。

処理サーバ１３０は、実行要求を受け取ると、リソース管理サーバ１２０にＯＫを返信して（Ｓ５１４）、アプリケーションを実行する（Ｓ５１７）。

リソース管理サーバ１２０は、処理サーバ１３０からのＯＫを受け取ると、リクエスト生成サーバ１０３を経由して、クライアント端末１０１にＯＫを返信して（Ｓ５１５，Ｓ５１６）、クラスタ生成部１２３の処理を完了するとともに、クラスタ監視部１２４を起動して、処理サーバ１３０のアプリケーションの実行状況を監視する。クラスタ監視部１２４の処理の詳細は図７で後述する。

図６は、リソース管理サーバ１２０のクラスタ生成部１２３の処理の一部であるリソース割り当て処理（Ｓ６００）の動作フローの例である。

ステップＳ６０１において、まず、リクエスト生成サーバ１０３から受け取ったクラスタ生成依頼（Ｓ５０５）の引数である並列数分の空き計算機リソースがあるかどうかをリソース割り当て情報記憶部１２１が管理するデータテーブル３００から未使用コア数を算出して、判定する。もし空き計算機リソースがあると判定されればＳ６０２へ移行し、空き計算機リソースが足りないと判定されればＳ６０３へ移行する。

ステップＳ６０２において、空き計算機リソースを有する処理サーバ１３０の中より、割り当てる処理サーバ１３０を選定して、リソース割り当て処理を終了する。

ステップＳ６０３において、クラスタ生成依頼（Ｓ５０５）の引数である該当アプリケーションの予想実行時間が基準値以上であるかどうかを判定する。
ここで、予想実行時間と比較する基準値とは、例えば、短時間の予想実行時間のアプリケーションの実行要求であった場合には、クラウドから不足した分の計算機リソースを確保して立ち上げる時間を待たされたアプリケーション利用者が、待ち時間により予想実行時間が延びたことによってサービス品質が低下していると印象を持つか否かの閾値として予め決めておくものとする。例えば、逆に予想実行時間が長いアプリケーションの実行要求であった場合には、クラウドから不足した分の計算機リソースを確保して立ち上げる時間を待たされたとしても、予想実行時間が延びる時間の比率は相対的に僅かであるので、アプリケーション利用者にとってはサービス品質の低下は感じない。
すなわち、上記の基準値としては、計算機リソースの立ち上げに要する待ち時間が予想実行時間に対して相対的に大きくなくて、アプリケーション利用者にサービス品質が低下していると感じさせないことを目的として、例えば、アプリケーションの予想実行時間が１分以上や、クラウドから計算機リソースを確保して立ち上げるまでに必要な時間（実績値のログを取っておいて、その平均値を求める）と同程度（またはその半分程度）以上、などの基準値を設ける。
Ｓ６０３において、予想実行時間が基準値以上であればＳ６０４へ移行し、予想実行時間が基準値未満であればＳ６０５へ移行する。

ステップＳ６０４において、クラウドから計算機リソースとして不足している分の処理サーバ１３０を立ち上げて、処理サーバ１３０を割り当てして、リソース割り当て処理を終了する。

ステップＳ６０５において、予想実行時間が基準値を下回る程短いのでクラウドから不足した分の計算機リソースを確保することはせずに、アプリ進捗情報記憶部１２２が管理しているデータテーブル４００に格納された各クラスタ内のアプリケーションの実行状況から、アプリケーションの実行を共存しても影響が少ないであろうクラスタを選択する。
ここで、アプリケーションの実行を共存しても、影響が少ないとは、クラスタ内のアプリケーションを、新たなアプリケーションと共存させて実行することにより、クラスタ内のアプリケーションの当初の予想実行時間は延びることになる。この予想実行時間の変動量が、当初の予想実行時間に対して相対的に小さいほど影響が少ないとする。
アプリケーションの実行を共存しても、影響が少ないであろうクラスタとは、たとえば、残り時間４０６が大きく、かつ共存数４０３が小さく、かつ共存時間４０８が小さく、かつＰｏｏｌ利用数４０４が多いクラスタが該当する。これらの情報に重み係数を掛けるなどして、優先度を設定し、クラスタを選択する。

ステップＳ６０６において、選択したクラスタの中から割り当てる処理サーバ１３０をリソース割り当て情報記憶部１２１が管理するデータテーブル３００から選択して、リソース割り当て処理を終了する。

図７はリソース管理サーバ１２０のクラスタ監視部１２４の動作フローの例である。
ステップＳ７０１において、アプリ進捗情報記憶部１２２が管理するデータテーブル４００に登録されている各クラスタで実行しているアプリケーションから、現在のアプリケーションの進捗情報を取得する。

ステップＳ７０２において、Ｓ７０１で取得した進捗情報を元に、アプリ進捗情報記憶部１２２が管理するデータテーブル４００に登録されている各クラスタごとの残り時間４０６と共存時間４０８を更新する。

ステップＳ７０３とステップＳ７０８に挟まれた処理を、アプリ進捗情報記憶部１２２が管理するデータテーブル４００に登録されている各クラスタ１つずつに対して実行する。

ステップＳ７０４において、残り時間４０６がクラウドから計算機リソースを確保するために必要な時間以上あり、かつ共存時間４０８に値が書き込まれているかをチェックする。ＹＥＳであればＳ７０５へ移行し、ＮＯであればＳ７０８へ移行する。

ステップＳ７０５において、残り時間４０６により想定されるアプリケーションの終了時刻と、当初終了予定時刻４０７との差が、保障レベル４０５に設定されている値が表すユーザが要求する許容範囲以上となりそうであるかをチェックする。ＹＥＳであればＳ７０６へ移行し、ＮＯであればＳ７０８へ移行する。

ステップＳ７０６において、クラウドから新たに計算機リソースを取得して処理サーバ１３０を追加し、追加した処理サーバ１３０に、該当クラスタで実行されているアプリケーションをインストールして、クラスタ内のアプリケーションとして実行できるようにする。これらの処理をオートスケール処理と呼ぶ。

ステップＳ７０７において、Ｓ７０６でオートスケール処理が実行されると、リソース割り当て情報記憶部１２１が管理するデータテーブル３００に追加した処理サーバ１３０のレコードを格納し、及びアプリ進捗情報記憶部１２２が管理するデータテーブル４００の該当クラスタの情報を更新する。

ステップＳ７０９において、数分待機し、定期的にステップＳ７０１から処理を実行する。

クラスタ監視部１２４の以上の処理により、アプリケーションの実行が共存されて、当初終了予定時刻と残り時間から想定される終了時刻との間に大きく差が開き、アプリケーション利用者が指定した保障レベル(許容時間範囲)以上の実行時間の開きが生じると予測された場合でも、クラウドから計算機リソースを確保するオートスケール処理により、自動的に実行時間の短縮化を図り、保障レベルの範囲内に抑えることができる。

また、本実施例では、クラスタ生成部１２３により、残り時間が長い順にアプリケーションを共存させることを優先度を高くすることで、クラスタ監視部１２４のオートスケール処理による実行時間の短縮を効果的に利用することができる。

図８は、処理サーバ１３０のアプリケーションの実行が終了した時に、情報処理システム内の各サーバで行われる処理の流れを表したシーケンス図である。図８では、処理サーバ１３０のアプリケーションの実行が終了するところから始まり、クラスタが破棄されるまでの処理の流れが記載されている。

まず、リソース管理サーバ１２０は、処理サーバ１３０からクラスタ名が指定されたクラスタ破棄依頼（Ｓ８０１）を受け取ると、クラスタ破棄部１２５を実行する。クラスタ破棄部１２５は、リソース割り当て情報記憶部１２１が管理するデータテーブル３００を参照することで、クラスタ内の処理サーバ１３０とアプリ名を特定する（Ｓ８０２）。次に、特定された各処理サーバ１３０にアプリケーション破棄依頼（Ｓ８０３）を送信する。

アプリケーション破棄依頼を受領した各処理サーバ１３０は、アプリケーションのアンインストール（Ｓ８０４）を行い、完了通知（Ｓ８０５）をリソース管理サーバ１２０に返送する。完了通知（Ｓ８０５）を受け取ると、リソース割り当て情報記憶部１２１が管理するデータテーブル３００とアプリ進捗情報記憶部１２２が管理するデータテーブル４００の該当クラスタに関連する情報を削除する。ここで、リソース割り当て情報記憶部１２１が管理するデータテーブル３００の該当クラスタに関連する情報は、もしＰｏｏｌフラグが「○」である処理サーバ１３０であれば、クラスタ情報のみを削除し、Ｐｏｏｌフラグが「−」であれば、レコードごと削除する。

図９は、アプリケーション利用者が実行要求毎にアプリケーションや入力データや並列度や保障レベルを決定するための設定画面イメージの例である。本実施例では、リクエスト生成サーバ１０３がこの設定画面９００を作成してクライアント端末１０１に提供する（クライアント端末１０１のディスプレイ装置２０９に表示させる）例を説明する。ただし、リクエスト生成サーバ１０３以外の計算機が、この設定画面９００を作成してもよい。

図９において、９０１はアプリ名入力ボックス、９０２はデータ名入力ボックス、９０３は並列度設定欄、９０４は(終了)保障レベル設定欄（アプリケーション利用者は、予想実行時間に対する実際の実行時間のブレの許容幅をいずれの保証レベルを要求するのか指定する。例えば、数十分レベルまで実行時間のブレの範囲を許容すると、￥500減額することを示している。）である。アプリケーション利用者がアプリ名入力ボックス９０１とデータ名入力ボックス９０２と並列度設定欄９０３と保障レベル設定欄９０４のそれぞれを入力することで、リクエスト生成サーバ１０３を経由してアプリ管理サーバ１０５に問合せを行い、アプリ管理サーバ１０５が想定される予想実行時間を算出するとともに、予想実行時間と並列度と保障レベルの設定に基づきコストを算出して、その結果を表示領域９０５，９０６に表示した画面を作成し、クライアント端末１０１に表示させる。
そのためアプリケーション利用者は、表示領域９０５に表示されるアプリケーションの予想実行時間が、アプリケーション利用者の希望する実行時間以内になるまで、並列度設定欄９０３に入力する並列度を少しずつ増やすことを繰り返すとよい。

また、使用する計算機リソースの量と計算機リソースの使用時間に応じて、アプリケーション利用者が情報処理システムの管理者（または所有者）に使用料金を支払うように、情報処理システムが運営されている場合、設定画面９００にコスト表示欄９０６を設け、リクエスト生成サーバ１０３（またはアプリ管理サーバ１０５）はアプリケーションの並列度とアプリケーションの実行時間（アプリケーションが並列実行される場合の実行時間）と保障レベルの値に応じたコスト（情報処理システムの使用料金）を算出し、算出されたコストの情報をアプリケーション利用者に対して提供してもよい。これによりアプリケーション利用者は、アプリケーションを完了させたい実行時間と並列度に応じて掛かるコストのバランスを見ながら、今回の実行要求を満たす並列度（実行時並列度）を決定することができる。

アプリケーション利用者が実行時の設定を決定した後確定ボタン９０７を押すと、図５のＳ５０１の処理が行われる。

本実施例に係る情報処理システムは、上で述べた機能を備えることにより、計算機リソースプールが枯渇している場合でも、アプリケーションプログラムを迅速に開始することができ、短時間で終了するアプリケーションでもサービス品質を低下させること無く、処理を完了させることができる。

１０１：クライアント端末、１０２：ネットワーク、１０３：リクエスト生成サーバ、１０４：データ管理サーバ、１０５：アプリ管理サーバ、１２０：リソース管理サーバ、
１２１：リソース割り当て情報記憶部、１２２：アプリ進捗情報記憶部、１２３：クラスタ生成部、１２４：クラスタ監視部、１２５：クラスタ破棄部、１３０：処理サーバ、
２００：計算機、２０１：プロセッサ（ＣＰＵ）、２０２：メモリ、２０３：補助記憶装置、２０４：通信インターフェース（通信Ｉ／Ｆ）、２０５：入力インターフェース（入力Ｉ／Ｆ）、２０６：キーボード、２０７：マウス、２０８：出力インターフェース（出力Ｉ／Ｆ）、２０９：ディスプレイ装置、
３００：リソース割り当て情報記憶部が管理するデータテーブル、
４００：アプリ進捗情報記憶部が管理するデータテーブル、
９００：アプリケーション利用者が実行要求毎にアプリケーションや入力データや並列度や保障レベルを決定するための設定画面、９０１：アプリ名入力ボックス、９０２：データ名入力ボックス、９０３：並列度設定欄、９０４：保障レベル設定欄、９０５：予想実行時間表示領域、９０６：コスト表示欄、９０７：確定ボタン

Claims (9)

1. 管理サーバと、複数の処理サーバを有し、ユーザからの要求に応じてネットワークを介してアプリケーションプログラムの実行を提供する情報処理システムであって、
   前記処理サーバはそれぞれ、アプリケーションプログラムを実行するための１以上のプロセッサを有し、
   前記管理サーバは、それぞれの前記処理サーバとして実行可能な計算機リソースと、前記計算機リソースの使用状態、及び１つのアプリケーションプログラムを実行しているクラスタごとに、クラスタ利用状況やユーザからの要求情報、アプリケーションプログラムの実行時間に関する情報を管理しており、
   前記管理サーバのクラスタ生成部は、ユーザから第１のアプリケーションプログラムの実行要求と共に、その実行の並列度と予想実行時間を受領した際に、前記管理サーバが管理していた計算機リソースに前記並列度を満たすだけの空きが足りなく、かつ実行要求の対象である前記第１のアプリケーションプログラムの予想実行時間が基準値以下である場合に、
   前記管理サーバで管理している使用中の計算機リソースの中から、実行中の第２のアプリケーションプログラムと、前記第１のアプリケーションプログラムとの実行を共存させたとしても、当初の予想実行時間からの変動割合が相対的に小さい第２のアプリケーションプログラムが実行されている計算機リソースを選定して、
   前記選定した計算機リソースに対して、実行要求の対象である前記第１のアプリケーションプログラムを配置して、実行する、
   ことを特徴とする情報処理システム。
2. 前記管理サーバのクラスタ生成部は、管理している使用中の計算機リソースの中から、実行中の第２のアプリケーションプログラムと、前記第１のアプリケーションプログラムとの実行を共存させたとしても、当初の予想実行時間からの変動割合が相対的に小さい第２のアプリケーションプログラムが実行されている計算機リソースを選定する際に、残り時間が大きく、かつ共存数が小さく、かつ共存時間が小さく、かつＰｏｏｌ利用数が多いクラスタに属する計算機リソースを優先的に選定する、
   ことを特徴とする請求項１に記載の情報処理システム。
3. 前記管理サーバのクラスタ生成部は、管理している使用中の計算機リソースの中から、実行中の第２のアプリケーションプログラムと、前記第１のアプリケーションプログラムとの実行を共存させたとしても、当初の予想実行時間からの変動割合が相対的に小さい第２のアプリケーションプログラムが実行されている計算機リソースを選定する際に、残り時間、共存数、共存時間、およびＰｏｏｌ利用数の各情報の大小の値に重み係数を掛けて優先度を設定したクラスタに属する計算機リソースを優先的に選定する、
   ことを特徴とする請求項２に記載の情報処理システム。
4. 前記管理サーバは、前記計算機リソースの使用状態、各クラスタ内のアプリケーションプログラムの実行時間に関する情報に加えて、ユーザがアプリケーションプログラムの実行要求と共に要求した予想実行時間の変動割合の許容度を表す保障レベルを管理しており、
   前記管理サーバのクラスタ監視部は、所定時間のサイクル時間ごとに、各クラスタ内のアプリケーションプログラムの進捗情報を取得して、残り時間、および共存時間を更新し、
   前記管理サーバのクラスタ監視部は、管理している全てのクラスタのうち、残り時間がクラウドから計算機リソースを確保するために必要な時間以上あり、かつ共存時間があり、かつ残り時間により想定されるアプリケーションプログラムの終了時刻と、当初終了予定時刻との差が、保障レベルが表すユーザが要求する許容範囲以上となるクラスタに対しては、クラウドから新たに計算機リソースを取得して、当該クラスタで実行されているアプリケーションプログラムをインストールする、
   ことを特徴とする請求項１に記載の情報処理システム。
5. 前記管理サーバは、ユーザがアプリケーションプログラムの実行要求を検討する際に、クライアント端末に実行要求情報を設定する画面を提示して、
   前記画面には、選定アプリ名、入力データ、および並列度を設定する各欄と共に、予想実行時間の変動割合の許容度を表す保障レベルを選択する欄が配置され、
   前記管理サーバは、ユーザによる選定アプリ名、入力データ、および並列度の設定を受付けて、選定されたアプリケーションプログラムの実行を、入力データ、および並列度に基づいてシミュレーションして、予想実行時間を算出して、前記画面に予想実行時間を提示し、続いて、算出した前記予想実行時間と、ユーザが設定した並列度、および保障レベルを受付けて、コストを算出して、前記画面にコストを提示する、
   ことを特徴とする請求項１に記載の情報処理システム。
6. 前記複数の処理サーバの一部、または全てが、クラウドから予め取得された計算機リソースであることを特徴とする請求項１に記載の情報処理システム。
7. 管理サーバと、複数の処理サーバを有し、ユーザからの要求に応じてネットワークを介してアプリケーションプログラムの実行を提供する情報処理システムにおいて、
   前記処理サーバはそれぞれ、アプリケーションプログラムを実行するための１以上のプロセッサを有し、
   前記管理サーバは、それぞれの前記処理サーバとして実行可能な計算機リソースと、前記計算機リソースの使用状態、及び１つのアプリケーションプログラムを実行しているクラスタごとに、クラスタ利用状況やユーザからの要求情報、アプリケーションプログラムの実行時間に関する情報を管理しており、
   前記管理サーバが、ユーザから第１のアプリケーションプログラムの実行要求と共に、その実行の並列度と予想実行時間を受領した際に、前記管理サーバが管理していた計算機リソースに前記並列度を満たすだけの空きが足りなく、かつ実行要求の対象である前記第１のアプリケーションプログラムの予想実行時間が基準値以下である場合に、
   前記管理サーバで管理している使用中の計算機リソースの中から、実行中の第２のアプリケーションプログラムと、前記第１のアプリケーションプログラムとの実行を共存させたとしても、当初の予想実行時間からの変動割合が相対的に小さい第２のアプリケーションプログラムが実行されている計算機リソースを選定して、
   前記選定した計算機リソースに対して、実行要求の対象である前記第１のアプリケーションプログラムを配置して、実行する、
   ことを特徴とするリソース割り当て方法。
8. 前記管理サーバが、管理している使用中の計算機リソースの中から、実行中の第２のアプリケーションプログラムと、前記第１のアプリケーションプログラムとの実行を共存させたとしても、当初の予想実行時間からの変動割合が相対的に小さい第２のアプリケーションプログラムが実行されている計算機リソースを選定する際に、残り時間が大きく、かつ共存数が小さく、かつ共存時間が小さく、かつＰｏｏｌ利用数が多いクラスタに属する計算機リソースを優先的に選定する、
   ことを特徴とする請求項７に記載のリソース割り当て方法。
9. 前記管理サーバが、管理している使用中の計算機リソースの中から、実行中の第２のアプリケーションプログラムと、前記第１のアプリケーションプログラムとの実行を共存させたとしても、当初の予想実行時間からの変動割合が相対的に小さい第２のアプリケーションプログラムが実行されている計算機リソースを選定する際に、残り時間、共存数、共存時間、およびＰｏｏｌ利用数の各情報の大小の値に重み係数を掛けて優先度を設定したクラスタに属する計算機リソースを優先的に選定する、
   ことを特徴とする請求項８に記載のリソース割り当て方法。

Images