JP2018072907A - 情報処理システム - Google Patents

Abstract

【課題】アプリケーション利用者の実行要求毎に必要な計算機リソース量を判断して、実行毎に計算機リソースを確保可能な並列コンピューティングシステムを提供する。【解決手段】本発明の一実施形態に係る情報処理システムは、管理サーバと、アプリケーションプログラムを実行するための１以上のプロセッサを備えた処理サーバを複数有する。管理サーバは、ユーザからアプリケーションプログラムの並列度を受領すると、複数の処理サーバの有する使用可能な計算機リソースの中から、受領した並列度でアプリケーションプログラムを実行するために必要な計算機リソースを確保し、確保された計算機リソースを有する処理サーバに、アプリケーションプログラムを配置し、アプリケーションプログラムを並列実行させる。【選択図】 図１

Description

本発明は、複数のサーバを含む情報処理システム及びその制御方法に関するものである。

近年、人工知能や機械学習などのように、大量のデータを網羅的に繰返し分析して、人が想定し得ない結果を導き出す分析アプリケーションが注目を集めている。このようなアプリケーションは、結果を導き出すまでに長時間掛かるため、繰返し処理部分に並列コンピューティングシステムを適用して、実行時間を短縮することが望まれている。しかし、アプリケーションの分析対象となるデータ量や分析パラメータ（たとえば、データの分割粒度など）により、実行時間が異なるため、アプリケーションを利用する分析者は、希望する実行時間以内に処理を完了するために、どれだけの計算機リソースを準備しておけばよいか決定することが困難である。

このような分野の背景技術として、特許文献１では、クラウドを活用して、アプリケーションに対する処理の需要を予測して、クラウドのリソースを自動で拡張及び縮小するアプリケーション・リソース・マネージャを提供している。

特表２０１４−５２７２２１号公報

特許文献１に記載されたアプリケーション・リソース・マネージャを用いれば、アプリケーションの負荷状況を予測して、指定されたポリシーに基づき迅速に計算機リソースを確保すると共に、イメージを高速配備（プロビジョニング）、もしくは使用されてないイメージをスタッシュして、アプリケーションの処理負荷を動的に変更することができる。これにより、アプリケーション利用者は、事前に計算機リソース量を決定しなくても、ポリシーに基づいた計算機リソースを利用することができる。

しかしながら、アプリケーション・リソース・マネージャで想定されているポリシーは、継続的にアプリケーションが実行されているときの負荷変動に対して、一定に保つように計算機リソースを確保する方法であり、アプリケーション利用者が、実行要求毎に利用形態やコスト等を鑑みて、計算機リソース量を決定するようなケースは想定されていない。

たとえば、アプリケーション利用者が、分析パラメータを試行錯誤しながら調整する利用形態を想定した場合、最初は分析粒度を粗く検証するために短実行時間であまり計算機リソースを使わず、すなわち計算機リソースにコストを掛けずに分析を行い、詳細分析をする際に、分析粒度を細かくするように分析パラメータを設定して、実行時間を短縮させるために、コストを掛けて計算機リソースを多めに利用したい、などのニーズが考えられる。このような利用形態の場合、アプリケーション利用者ごとに必要とする計算機リソース量が異なるために、特許文献１に記載の技術のように、ポリシーに基づく計算機リソースの確保を行う方法では、対応が困難である。

上記目的を達成するために、本発明の一実施形態に係る情報処理システムは、管理サーバと、アプリケーションプログラムを実行するための１以上のプロセッサを備えた処理サーバを複数有する。管理サーバは、ユーザからアプリケーションプログラムの並列度を受領すると、複数の処理サーバの有する使用可能な計算機リソースの中から、受領した並列度でアプリケーションプログラムを実行するために必要な計算機リソースを確保し、確保された計算機リソースを有する処理サーバに、アプリケーションプログラムを配置し、アプリケーションプログラムを並列実行させる。

本発明によれば、アプリケーション利用者が、アプリケーションの実行要求毎に必要な計算機リソース量を、アプリケーション利用者の処理要求に合わせて柔軟に決定して、決定した計算機リソース量で迅速に並列コンピューティングシステムを構築することが可能となる。

情報処理システムの全体構成の例を示す図である。 各種サーバの物理的な構成の例を示す図である。 処理サーバの機能の概要を示す図である。 アプリ管理記憶部のテーブルの例を示す図である。 ノード-クラスタ管理情報記憶部のテーブルの例を示す図である。 アプリ実行計算部の動作フローの例を示す図である。 クラスタ生成部の動作フローの例を示す図である。 クラスタ破棄部の動作フローの例を示す図である。 アプリの実行依頼前に並列度を設定する動作シーケンスの例を示す図である。 アプリの実行依頼から処理サーバで並列処理を実行する動作シーケンスの例を示す図である。 アプリ実行完了後にクラスタ破棄する動作シーケンスの例を示す図である。 計算機リソース量の設定画面の例を示す図である。 計算機リソース量の設定画面の別の例を示す図である。

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

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

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

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

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

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

アプリ管理サーバ１１０は、処理サーバ１３０で実行されるアプリケーションの情報を管理するとともに、入力データや計算機リソースを設定することでアプリケーションの実行処理時間の見積もり値を計算するサーバである。アプリ管理サーバ１１０は、アプリケーションの情報を管理するアプリ管理記憶部１１１と、入力データと計算機リソース量に基づきアプリケーションの実行時間を事前に計算するアプリ実行時間計算部１１２と、を有する。詳細は、図４および図６で説明する。

クラスタ管理サーバ１２０は、各処理サーバ１３０の利用状態を管理して、クラスタの生成/破棄を動的に行うサーバであり、ノード-クラスタ管理情報記憶部１２１とクラスタ生成部１２２、クラスタ破棄部１２３、を有する。本実施例では、１つのアプリケーションを実行する際に使用される計算機リソースの集合（あるいはこの計算機リソースを有する処理サーバ１３０の集合）を「クラスタ」と呼ぶ。詳細は、図５および図７、図８で説明する。

処理サーバ１３０は、アプリ管理サーバ１１０が管理しているアプリケーションを実行するためのサーバであり、アプリケーションの実行コードを記憶するアプリケーション管理部１３１と、アプリケーションの並列処理を実現する並列処理管理部１３２と、を有する。アプリケーション管理部１３１には、複数のアプリケーションが登録されてもよい。複数のアプリケーションが登録されている場合、クラスタはアプリケーションの処理要求ごとに生成されるため、処理サーバ１３０は複数のクラスタに属していることとなり、それぞれのクラスタ内の処理サーバ１３０からアプリケーションの処理を割り振られることとなる。詳細は図３で説明する。

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

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

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

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

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

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

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

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

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

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

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

図３は、処理サーバ１３０でアプリケーションが実行される時の仕組みを概説する図である。

処理サーバ１３０は先に述べたとおり、アプリケーションが配置されるアプリケーション管理部１３１と、同一クラスタ内の処理サーバ１３０を管理して、処理を各処理サーバ１３０に割り振りながらアプリケーションを並列実行することを管理する並列処理管理部１３２と、を有する。

アプリケーション管理部１３１はアプリケーションプログラムを格納する機能部で、メモリ２０２や補助記憶装置２０３の記憶領域を用いてアプリケーションプログラムを保持する。

並列処理管理部１３２は、アプリケーションを並列実行させるために必要な、各種機能を提供する。並列処理管理部１３２の説明の前に、処理サーバ１３０でアプリケーションがどのようにして並列実行されるか、概説する。

本実施例では一例として、アプリケーションがデータの分析を行うためのプログラムである例を説明する。アプリケーションは、１以上の処理を実行するためのプログラムコード（実行コード）を含む。図４の４１０は、アプリケーション（Ａｐｐ Ａ）の構成例を示している。図４の４１０に示されているように、Ａｐｐ Ａは複数の処理Ａａ，Ａｂ，Ａｃを含んでおり、Ａｐｐ Ａが処理サーバで実行される時、処理Ａａ，Ａｂ，Ａｃの順に実行される。ここで、たとえば処理Ａａは入力データの正規化を行う処理、処理Ａｂは正規化されたデータの分析を行う処理、そして処理Ａｃは処理Ａｂにて分析されたデータの統計処理である。

各処理の中には、複数の処理サーバ１３０（あるいは複数のプロセッサ２０１）で並列処理されてもよいものもある。本実施例では処理Ａａ，Ａｂが、並列実行可能な処理である例を説明する。

アプリケーションは、これらの各処理（Ａａ，Ａｂ，Ａｃ）をプロセッサ２０１に実行させるための実行コードと、各処理の実行を各処理サーバ１３０に依頼する（振り分ける）処理をプロセッサ２０１に行わせる実行コードとを有し、前者の実行コードのことを「実行部」（図３の３１２）と呼び、後者の実行コードのことを「振分部」（図３の３１１）と呼ぶ。本実施例では、振分部３１１が各処理サーバ１３０に、実行部の処理を依頼するために送信される情報のことを「メッセージ」と呼ぶ。また、図３または図４に示されたＡｐｐ Ａのように、複数の処理（Ａａ，Ａｂ，Ａｃ）が実行されるアプリケーションでは、実行部３１２には処理Ａａを行う実行コード，処理Ａｂを行う実行コード，処理Ａｃを行う実行コードが含まれる。以下では処理Ａａ，Ａｂ，Ａｃを行う実行コードをそれぞれ、「コードＡａ」，「コードＡｂ」，「コードＡｃ」と呼ぶ。

処理サーバ１３０の並列処理管理部１３２は、振分部３１１と実行部３１２の形で分離設計定義されたアプリケーションの並列実行の管理を行う。並列処理管理部１３２は、リクエスト受付サーバ１０３などの外部からアプリケーションの実行依頼を受け付けて、アプリケーションの振分部３１１の実行を開始するリクエスト受付部３２１と、振分部３１１が生成したメッセージを、処理サーバ（実行）１３０に送信するメッセージ振分部３２２、処理サーバ（振分）１３０から受信したメッセージを解析して、対象の実行部３１２に含まれる実行コード（コードＡａ，Ａｂ，Ａｃ）を呼び出すメッセージ受付部３２３により、アプリケーションの並列実行を行う。

また並列処理管理部１３２は、クラスタ管理サーバ１２０などからアプリケーションのデプロイまたはアンデプロイ依頼を受けとり、アプリケーション管理部３１０にアプリケーションの配置と削除を行うアプリ・デプロイ/アンデプロイ受付部３２４と、アプリケーション管理部３１０に配置されているアプリケーションが所属しているクラスタについてのクラスタ情報を管理するクラスタ情報記憶部３２５の機能も提供する。クラスタ情報については後述する。

並列処理管理部１３２は、このメッセージの送受信や、受信したメッセージに基づいて実行部に処理を実行させる等の処理を行う。以下では図３を参照しながら、Ａｐｐ Ａ３１０が実行される時の処理の流れを概説する。

以下では、処理ＡａがＮ個のプロセッサ２０１で並列処理され、処理ＡｂがＭ個のプロセッサ２０１で並列処理される例を説明する（Ｎ，Ｍはいずれも１以上の整数で、ＮとＭは等しい場合もある）。なお、アプリケーションが処理サーバ１３０で実行される前に、アプリケーションを実行するクラスタ内の各処理サーバ１３０にはアプリケーションが配布され、クラスタ内の各処理サーバ１３０のアプリケーション管理部１３１にはアプリケーションが格納された状態にある。この処理は後述する。

ここで、処理サーバ１３０のうち、メッセージを生成して振り分ける振分部３１１を担当する処理サーバ１３０を処理サーバ（振分）１３０、メッセージを受け取り、処理を実行する実行部３１２を担当する処理サーバ１３０を処理サーバ（実行）１３０と呼ぶ。処理サーバ（実行）１３０と処理サーバ（振分）１３０は同一サーバであってもよい。

アプリケーションＡｐｐＡ３１０の実行が開始されると、処理サーバ（振分）１３０の振分部３１１はまずメッセージＡａをＮ個生成して、並列処理管理部１３２のメッセージ振分部３２２を介して、クラスタ内の各処理サーバ１３０にメッセージＡａを送信する。メッセージＡａの送信先となる処理サーバ１３０は、振分部３１１により決定される。メッセージＡａを送信された処理サーバ１３０（実行）では、メッセージ受付部３２３がメッセージＡａに対応した実行部３１２内の処理Ａａを実行するコードを呼び出して、処理Ａａを実行させる。処理Ａａの実行後、メッセージ受付部３２３は処理サーバ（振分）１３０に、処理結果を返信する。

処理サーバ（振分）１３０の振分部３１１は、メッセージＡａに対応する処理結果の返信をＮ個分受け取ると、次の処理としてメッセージＡｂをＭ個生成して、同様に並列処理管理部１３２のメッセージ振分部３２２を介して、メッセージＡｂをクラスタ内の処理サーバ（実行）１３０に送信する。振分部３１１は、各処理（Ａａ，Ａｂ，Ａｃ）について、メッセージの送信及び結果の受信を行い、メッセージＡｃに対応する結果を受信し終えると、アプリケーションは終了する。つまり、アプリケーションを、処理依頼となるメッセージを生成する振分部３１１と、メッセージを受け取る実行部３１２に分けて設計定義しておくことで、繰り返し処理部分を並列に処理させることができる。

並列処理管理部１３２により、処理サーバ１３０にアプリケーションを配置するだけで、クラスタ内の処理サーバ１３０のどれか１つに対して実行依頼を送信することで、処理サーバ１３０が自動で処理サーバ（振分）１３０と処理サーバ（実行）１３０に分かれて、アプリケーションの処理を処理サーバ（実行）１３０に振り分けながら並列に処理を実行することができる。これらの処理の流れについては、後で図９から図１１のシーケンス図を用いて説明する。

図４は、アプリ管理サーバ１１０内に保持されているアプリ管理記憶部１１１のテーブルの例を示す図である。

アプリ管理記憶部１１１は、アプリケーションとして配置する実行コードや、アプリケーションの処理時間を計算するための処理フローの情報や、処理ごとの実行時間を計算するための計算ロジックの情報を格納する機能部で、これらの情報を格納するために、メモリ２０２や補助記憶装置２０３の記憶領域を用いる。アプリ管理記憶部１１１は一例として、公知のファイルシステムプログラムまたはデータベース管理システム（ＤＢＭＳ）のようなプログラムを用いて実装されて良い。本実施例ではアプリ管理記憶部１１１は、アプリケーションの実行コードや処理フローや計算ロジックの情報を、メモリ２０２や補助記憶装置２０３の記憶領域上に形成されたテーブルに記憶させる例を説明する。

アプリ管理記憶部１１１が有するテーブル４００は、図４に示されるように６つのカラムを有する。以下、各カラムに格納される情報について説明する。アプリ名４０１には、アプリケーションの名称が格納される。アプリケーションの名称とは、アプリケーション利用者が、アプリケーションの実行を依頼する際に、アプリケーションを特定するために用いる名称である。実行コード４０２には、アプリ名４０１に対応したアプリケーションの実行コード（のファイル）が格納される。

並列度計算ロジック４０３には、入力データ量に応じてアプリケーションの各処理の繰り返し回数を算出するためのロジックが記述されたファイルが格納される。本実施例では、各処理の繰り返し回数を算出するためのロジックを「並列度計算ロジック」と呼ぶ。処理フロー４０４には、アプリケーションの処理実行手順が記録される。並列性４０５には、処理フロー４０４に記述されている各処理が、並列実行が可能か否かを表す情報が格納される。計算ロジック４０６には、処理フロー４０４内の各処理の１回の実行時間を算出するための計算ロジック（これを「実行時間計算ロジック」と呼ぶ）が記述されたファイルが格納される。

たとえば図４を参照しながら、各カラムに格納される情報の具体例を説明する。図４のテーブルの先頭行に格納されているアプリケーション（ＡｐｐＡと呼ぶ）が、図４の４１０に記述されているように、処理Ａａ、処理Ａｂ、処理Ａｃの３つの処理を含み、処理Ａａ、処理Ａｂ、処理Ａｃの順で処理を行うものとする。また処理Ａａ及び処理Ａｂは並列実行可能で、与えられた入力データの量に応じて、繰り返し実行される回数が変動する処理とする。

この時並列度計算ロジック４０３には、入力データの量から処理Ａａ及び処理Ａｂの繰り返し実行回数を算出するためのロジックが記述されたファイルのファイル名（図４の例では“AppA_message.py”）が記述される。また処理フロー４０４には“処理Ａａ，処理Ａｂ，処理Ａｃ”が記述される。以下では、処理フロー４０４のカラムに“処理Ａａ”が格納された行を“行４０７”，“処理Ａｂ”が格納された行を“行４０８”，“処理Ａｃ” が格納された行を“行４０９”と呼ぶ。

並列性４０５の欄には、行４０７及び行４０８には“○”が格納され、処理Ａａ及び処理Ａｂは並列実行可能であることを表す。一方、行４０９には“×”、つまり処理Ａｃは並列実行可能でないことを表す情報が格納される。

そして、処理Ａａの実行時間計算ロジックが記述されたファイルが“AppA_calcAa.py”、処理Ａｂの実行時間計算ロジックが記述されたファイルが“AppA_calcAb.py”、処理Ａｃの実行時間計算ロジックが記述されたファイルが“AppA_calcAc.py”の場合、計算ロジック４０６の欄には、行４０７に“AppA_calcAa.py”、行４０８に“AppA_calcAb.py”、行４０９に“AppA_calcAc.py”が格納される。

アプリ管理記憶部１１１のテーブルに格納されるこれらの情報は、あらかじめ情報処理システムの管理者、またはアプリケーションの利用者によって、アプリ管理記憶部１１１に登録される。また並列度計算ロジックや実行時間計算ロジックは、あらかじめアプリケーションの開発者によって作成されたものである。

ただし別の実施形態として、実行時間計算ロジックを情報処理システムが自動作成する手段を備えていてもよい。たとえばデータ量と実行時間の因果関係を考慮して、入力データを統計的に処理して自動で計算ロジックを作成する機能，またデータ量以外に実行時間との因果関係のある項目を分析して自動で計算ロジックの予測モデルを構築する機能を、情報処理システムが備えており、アプリケーションがアプリ管理サーバ１１０に登録された時に、情報処理システムが実行時間計算ロジックを生成して、アプリ管理記憶部１１１に登録してもよい。

なお、図４では説明を分かりやすくするために、実行コード４０２、並列度計算ロジック４０３、計算ロジック４０６のカラムには、実行コードや計算ロジックのファイル名（AppA.appなど）のみが記載されているが、これらのカラムにファイルの実体も格納される。あるいは別の実施形態として、実行コードや計算ロジックのファイルの実体は、アプリ管理記憶部１１１（を構成する補助記憶装置２０３の記憶領域）に格納され、実行コード４０２、並列度計算ロジック４０３、計算ロジック４０６のカラムには、各ファイルのパス名が格納される形態であってもよい。

図５は、クラスタ管理サーバ１２０内に保持されているノード-クラスタ管理情報記憶部１２１のテーブルの例を示す図である。本実施例ではノード-クラスタ管理情報記憶部１２１はアプリ管理記憶部１１１と同様に、メモリ２０２や補助記憶装置２０３の記憶領域上に形成されたテーブルに、各種情報を記憶させる例を説明する。

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

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

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

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

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

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

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

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

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

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

たとえば情報処理システム内に、図５のテーブル５００に示されているように、Ｎｏｄｅ１〜Ｎｏｄｅ８の処理サーバ１３０が存在し、Ｎｏｄｅ１〜Ｎｏｄｅ５のＣＰＵ Ｃｏｒｅが既に何らかのアプリケーションに割り当てられている場合、未使用コアを２以上有する処理サーバ１３０としてＮｏｄｅ５，Ｎｏｄｅ６が選択されるとよい。そしてこの場合、クラスタ生成部１２２はＮｏｄｅ５とＮｏｄｅ６の割り当てＣＰＵ Ｃｏｒｅ５０５に２を加算することで、計算機リソース（ＣＰＵ Ｃｏｒｅ）を確保するとよい。

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

図６は、アプリ管理サーバ１１０のアプリ実行時間計算部１１２の動作フローの例である。まず、アプリ実行時間計算部１１２は要求発行元から、アプリ名、入力データ、並列度を引数として指定した、アプリ実行時間計算依頼を受け付ける（ステップ６０１）。本実施例ではアプリ実行時間計算依頼の要求発行元は、リクエスト受付サーバ１０３とする。また並列度は、アプリケーションを構成する処理毎に指定されてもよい。たとえばアプリケーションが図４の４１０のように処理Ａａ，Ａｂ，Ａｃから構成されており、処理Ａａ，Ａｂがそれぞれ並列実行可能な処理の場合、要求発行元は処理Ａａの並列度と処理Ａｂの並列度を引数として指定したアプリ実行時間計算依頼を、アプリ実行時間計算部１１２に発行してもよい。ただし以下の説明では、特に断りのない限り、並列度が１つだけ指定される例（並列実行可能な各処理がいずれも、同じ並列度で実行される例）を説明し、またここで指定される並列度をｎとする。

次にアプリ実行時間計算部１１２は、アプリ管理記憶部１１１から、アプリ名に対応した並列度計算ロジック４０３と処理フロー４０４内の各処理に対応する計算ロジック４０６を取得する（ステップ６０２）。そしてアプリ実行時間計算部１１２は、並列度計算ロジック４０３を利用して、入力データ量からアプリケーションの各処理の繰り返し数を算出し（ステップ６０３）、次に各処理の計算ロジック４０６を利用して、各処理が入力データに対応した処理を１回実行する時の実行時間を算出する（ステップ６０４）。

次にアプリ実行時間計算部１１２は、ステップ６０３で求められた各処理の繰り返し数と、ステップ６０４で求められた各処理の１回の実行時間を用いて、アプリケーションの実行時間（並列処理を行わない場合の実行時間）を計算し（ステップ６０５）、さらに並列実行可能な処理群が並列実行された場合の、各処理の繰り返し回数、各処理の実行時間、アプリケーションの合計実行時間を算出し、実行結果を要求発行元に返信する（ステップ６０６）。各処理が並列実行される場合の、繰り返し回数や実行時間は、ステップ６０３で求められた各処理の繰り返し数と、ステップ６０４で求められた各処理の１回の実行時間をそれぞれ、並列度（ｎ）で除算することにより求められる。

アプリ実行時間計算部１１２は上に述べたフローを実行することで、アプリケーションの実行時間を入力データと並列度から瞬時に計算して、アプリケーション利用者に対して計算時間に対する情報を提示する。これによりアプリケーション利用者は、許容可能な実行時間に対する並列度を試行錯誤しながら決定することができる。

図７は、クラスタ管理サーバ１２０のクラスタ生成部１２２の動作フローの例である。まず、クラスタ生成部１２２は要求発行元から発行されたクラスタ生成依頼を受け付ける（ステップ７０１）。本実施例では、クラスタ生成依頼の要求発行元は、リクエスト受付サーバ１０３とする。またクラスタ生成依頼には、アプリ名と並列度が引数として含まれている。

次にクラスタ生成部１２２は、ノード-クラスタ管理情報記憶部１２１を見て、まだノード-クラスタ管理情報記憶部１２１に記録されていない名称のクラスタ名を生成することで、今回生成されるクラスタに一意な名称を付す（ステップ７０２）。そしてクラスタ生成部１２２はノード-クラスタ管理情報記憶部１２１を参照することで、まだどのクラスタにも割り当てられていないプロセッサコアを有する処理サーバ１３０を１または複数選択して（ステップ７０３）、ノード-クラスタ管理情報記憶部１２１にクラスタ情報を作成する（ステップ７０４）。ステップ７０３における処理サーバ１３０の選択方法は、図５の説明で述べたため、ここでの説明は略す。

次にクラスタ生成部１２２は、選定した処理サーバ１３０にアプリケーションを配置するために、アプリ管理サーバ１１０からアプリ名に対応するアプリケーションの実行コード４０２を取得して、各処理サーバにアプリケーションの配置を依頼する（ステップ７０５、７０６）。アプリケーションの配置を依頼された処理サーバ１３０で行われる処理については、後で説明する。

続いてクラスタ生成部１２２は、アプリケーションの実行コード４０２を配置した処理サーバ１３０の中から、処理サーバ（振分）１３０となる処理サーバ１３０を選択して（ステップ７０７）、クラスタ名と処理サーバ（振分）１３０へのアクセスＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を、要求発行元に返信する（ステップ７０８）。

図８は、クラスタ管理サーバ１２０のクラスタ破棄部１２３の動作フローの例である。まず、クラスタ破棄部１２３は要求発行元から、クラスタ名が引数に指定されたクラスタ破棄依頼を受け付ける（ステップ８０１）。ここでも要求発行元はリクエスト受付サーバ１０３とする。次にクラスタ破棄部１２３は、ノード-クラスタ管理情報記憶部１２１からクラスタ内の処理サーバ１３０の情報を取得して（ステップ８０２）、各処理サーバ１３０にアプリケーションを削除させる（ステップ８０３）。削除が完了すると、クラスタ破棄部１２３はノード-クラスタ管理情報記憶部１２１のクラスタ情報を削除して（ステップ８０４）、完了通知を要求発行元に返信する（ステップ８０５）。

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

まずクライアント端末１０１はアプリケーション利用者から、アプリケーション利用者が利用するアプリケーションのアプリ名と入力データを受け付けると、リクエスト受付サーバ１０３にアプリケーションの登録依頼を送信する（９０１）。このアプリケーションの登録依頼には、アプリケーション名（たとえば“ＡｐｐＡ”など）と入力データが含まれる。リクエスト受付サーバ１０３はこの登録依頼に応じて、まず入力データをデータ管理サーバ１０４に登録する（９０２、９０３）。データ管理サーバ１０４は入力データを受領すると、入力データへのアクセス方法であるアクセスＵＲＬ（９０４）をリクエスト受付サーバ１０３に返送する。リクエスト受付サーバ１０３はアクセスＵＲＬ（９０４）を受け取ると、クライアント端末１０１にＯＫ（９０５）を返信する。この時、リクエスト受付サーバ１０３は、入力データへのＵＲＬとアプリ名とを対応付けて保持する。

次にアプリケーション利用者は、クライアント端末１０１を用いて並列度（９０６）を指定する。リクエスト受付サーバ１０３は並列度を受け取ると、アプリ管理サーバ１１０のアプリ実行時間計算部１１２に、繰り返し数と各処理の実行時間を計算させて（９０７、９０８、９０９）、その結果をクライアント端末１０１に返信する（９１０）。９０７、９０８、９０９でアプリ管理サーバ１１０で行われる処理は、図６の処理に相当する。

アプリケーション利用者は、アプリ実行時間計算部１１２によって算出されるアプリケーションの実行時間が、アプリケーション利用者の希望する時間に収まるようになるまで、並列度を変更しながら、９０６〜９１０の処理を繰り返す。たとえばある並列度（ｎとする）が指定された時に算出されたアプリケーションの実行時間が、アプリケーション利用者の希望する実行時間より長かった場合には、アプリケーション利用者は、ｎよりも高い並列度（たとえば（ｎ＋１）等）を指定して、アプリ実行時間計算部１１２にアプリケーションの実行時間を算出させるとよい。逆に算出されたアプリケーションの実行時間が、アプリケーション利用者の希望する時間よりも短かった場合、アプリケーション利用者は最初に指定した並列度（ｎ）よりも低い並列度（たとえば（ｎ−１）等）を指定して、アプリ実行時間計算部１１２にアプリケーションの実行時間を算出させてもよい。

アプリケーション利用者は上に述べた９０６〜９１０の処理を繰り返すことで、実際にアプリケーションを実行する時の並列度を決定する（以下では、ここでアプリケーション利用者が決定した並列度を「実行時並列度」と呼び、図９の９０６でアプリケーション利用者が指定する並列度とを区別する）。実行時並列度が決定されると、アプリケーション利用者はクライアント端末１０１から、実行時並列度とアプリケーション名を指定したクラスタ生成依頼をリクエスト受付サーバ１０３経由でクラスタ管理サーバ１２０に送信する（９１１，９１２）。ここの処理でアプリケーション利用者が並列度等を指定するための具体的な方法については、後で図１２（または図１３）を用いて説明する。

クラスタ管理サーバ１２０はクラスタ生成依頼（９１２）を受け取ると、クラスタ生成部１２２により、クラスタ名を作成し（９１３）、実行時並列度に応じた処理サーバ１３０の計算機リソース（ＣＰＵ Ｃｏｒｅ）の確保を行い（９１４）、ノード-クラスタ管理情報記憶部１２１にクラスタ情報を作成する（９１５）。９１２〜９１５の処理はそれぞれ、図７のステップ７０１〜７０４に相当する処理である。

続いてクラスタ生成部１２２は、アプリ管理サーバ１１０からアプリケーションの実行コード（９１６）を取得して（９１７）、各処理サーバ１３０にアプリケーションの配置を依頼する（９１８）。９１７〜９１８の処理はそれぞれ、図７のステップ７０５〜７０６に相当する処理である。クラスタ生成部１２２が処理サーバ１３０にアプリケーションの配置を依頼する際、アプリケーションの実行コード、そしてクラスタ情報を処理サーバ１３０に送信する。

アプリケーションの配置を依頼された処理サーバ１３０は、アプリケーションをインストールするとともに（９１９）、並列処理管理部１３２のクラスタ情報記憶部３２５にクラスタ情報を作成する（９２０）。クラスタに属する各処理サーバ１３０へのアプリケーションの配置が完了すると（９２１）、クラスタ管理サーバ１２０はクラスタに属する各処理サーバ１３０の中から、処理サーバ（振分）１３０となる処理サーバ１３０を１台選定して、リクエスト受付サーバ１０３にクラスタ名とともに、処理サーバ（振分）１３０へのアクセスＵＲＬを返信する（９２３）。

リクエスト受付サーバ１０３はクライアント端末１０１にＯＫ（９２４）を返信して、処理が完了する。

図１０は、図９の処理の続きで、図９の処理によって決定された処理サーバ１３０群を利用して、アプリケーションの処理を並列に実行する動作シーケンスの例である。

まず、アプリケーション利用者がクライアント端末１０１を用いてアプリケーション実行要求（１００１）をリクエスト受付サーバ１０３に発行すると、リクエスト受付サーバ１０３は、処理サーバ（振分）１３０へのアクセスＵＲＬに対して、入力データのアクセスＵＲＬと合わせて実行依頼を送信する（１００２）。

なお、図９（及び図１０）のシーケンス図には、リクエスト受付サーバ１０３はクライアント端末１０１にＯＫを返送し（９２４）、その後アプリケーション利用者がアプリケーション実行要求（１００１）を発行したことを契機に、処理サーバ（振分）１３０に実行依頼を送信（１００２）する例を示している。ただし別の実施形態として、リクエスト受付サーバ１０３がクラスタ管理サーバ１２０から処理サーバ（振分）１３０へのアクセスＵＲＬを受領（９２３）した後、リクエスト受付サーバ１０３はクライアント端末１０１に返信（９２４）を行うことなく、処理サーバ（振分）１３０にアプリケーションの実行依頼を送信（１００２）してもよい。

処理サーバ（振分）１３０では、アプリケーションの振分部３１１が、９１１で指定された並列度（実行時並列度）と同数のメッセージＡａを生成して（１００４）、メッセージＡａ（１００５）を各処理サーバ（実行）１３０に送信する。メッセージＡａを生成する際に、入力データを利用する場合は、処理サーバ（振分）１３０はデータ管理サーバ１０４から入力データを取得する（１００３）。

処理サーバ（実行）１３０はメッセージＡａを受け取ると、データ管理サーバ１０４に格納されている入力データの中から処理Ａａに必要な対象データ（１００６）を取得して、実行部３１２の処理Ａａを実行して（１００７）、処理結果（１００８）をデータ管理サーバ１０４に書き込むとともに、処理の完了通知（１００９）を処理サーバ（振分）１３０に返信する。

処理サーバ（振分）１３０は、メッセージを送信した全ての処理サーバ（実行）１３０から完了通知を受領すると（１００９）、次のメッセージ（図１０の例では“メッセージＡｂ”）を生成して、各処理サーバ（実行）１３０に振り分ける。処理サーバ（振分）１３０はこのように、メッセージを生成して各処理サーバ（実行）１３０にメッセージを振り分け、各処理サーバ（実行）１３０から処理の完了通知を受領する、という処理を繰り返す。そして処理サーバ（振分）１３０は、最後のメッセージ（図１０の例では“メッセージＡｃ”）に対する処理の完了通知を処理サーバ（実行）１３９から受け取ると、最終結果をデータ管理サーバ１０４から取得し（１０２２）、アプリケーションとしての実行結果を生成して（１０２３）、リクエスト受付サーバ１０３経由で実行結果（１０２４，１０２５）をクライアント端末１０１に返信する。

図１１は、図１０の後に行われる処理、つまりアプリケーションの実行が終わってから、クラスタを破棄するまでの処理の例である。

まず、クライアント端末１０１からアプリケーションの実行完了通知（１１０１）をリクエスト受付サーバ１０３が受け取ると、リクエスト受付サーバ１０３は、クラスタ管理サーバ１２０に対して、クラスタ破棄依頼（１１０２）を送信し、クラスタ破棄部１２３はこのクラスタ破棄依頼を受け付ける。この処理は図８のステップ８０１に相当する処理である。先に述べたとおり、クラスタ破棄依頼には、破棄対象のクラスタ名が含まれている。

クラスタ破棄依頼を受け取ったクラスタ管理サーバ１２０では、クラスタ破棄部１２３がノード-クラスタ管理情報記憶部１２１を参照することで、クラスタ内の処理サーバ１３０とアプリ名を特定する（１１０３）。この処理はステップ８０２に相当する処理である。そしてクラスタ破棄部１２３は、特定された各処理サーバ１３０にアプリケーション破棄依頼（１１０４）を送信する（ステップ８０３に相当する処理である）。

アプリケーション破棄依頼を受領した各処理サーバ１３０は、アプリケーションのアンインストール（１１０５）、クラスタ情報記憶部３２５に記録されていたクラスタ情報の破棄（１１０６）を実施した後、完了通知をクラスタ管理サーバ１２０に返送する。クラスタ破棄部１２３が各処理サーバ１３０から完了通知（１１０７）を受け取ると、ノード-クラスタ管理情報記憶部１２１のクラスタ情報を削除して（１１０８）、リクエスト受付サーバ１０３経由でクライアント端末１０１に完了通知（１１０９，１１０１）を返信する。

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

図１２において、１２０１はアプリ名入力ボックス、１２０２はデータ名入力ボックス、１２０６は並列度設定欄である。アプリケーション利用者がアプリ名入力ボックス１２０１とデータ名入力ボックス１２０２のそれぞれに、アプリケーションの名称及び入力データの名称（ファイル名）を入力することで、リクエスト受付サーバ１０３は図９の９０１〜９０５を実行する。

その後リクエスト受付サーバ１０３は、アプリケーション利用者がアプリ名入力ボックス１２０１とデータ名入力ボックス１２０２に入力したアプリ名と登録した入力データを基に、まず並列処理を行わない場合の処理フロー内の各処理の繰り返し数、各処理の処理時間の予想値、各処理のトータルの実行時間の算出をアプリ実行時間計算部１１２に行わせる（図６のステップ６０５までの処理が行われる）。そしてリクエスト受付サーバ１０３は、算出されたこれらの情報（１２０４）をアプリケーションの処理フロー（１２０３）と対応付けて表示する画面を作成し、この画面をクライアント端末１０１のディスプレイ装置２０９に出力させる。

アプリケーション利用者が、この表示された情報を基に、並列度設定欄１２０６に並列度を入力すると、入力された並列度はアプリ管理サーバ１１０に送信される。先に図６や図９を用いて説明したとおり、アプリ管理サーバ１１０は、渡された並列度等を用いて並列処理を行った場合の、各処理の繰り返し数と処理時間の予想値およびアプリケーションの合計実行時間を求め、その結果を表示領域（１２０５）に表示した画面を作成し、クライアント端末１０１に表示させる。そのためアプリケーション利用者は、表示領域（１２０５）に表示されるアプリケーションの合計実行時間が、アプリケーション利用者の希望する実行時間以内になるまで、並列度設定欄１２０６に入力する並列度を少しずつ増やすことを繰り返すとよい。

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

アプリケーション利用者が実行時並列度を決定した後確定ボタン（１２０７）を押すと、図９の９１１，９１２の処理が行われる。つまりリクエスト受付サーバ１０３はクライアント端末１０１から、アプリケーション利用者がアプリ名入力ボックス１２０１と並列度設定欄１２０６に設定したアプリケーション名称と並列度（実行時並列度）とを受け取る。そしてリクエスト受付サーバ１０３はクラスタ管理サーバ１２０に対して、実行時並列度とアプリケーション名を指定したクラスタ生成依頼を送信する（図９の９１１，９１２の処理が行われる）。クラスタの生成が完了し、リクエスト受付サーバ１０３がクラスタ管理サーバ１２０からの返答を受領すると（図９ ９２３）、リクエスト受付サーバ１０３は処理サーバ（振分）１３０にアプリケーションの実行依頼を送信する（図１０ １００２）。

本実施例に係る情報処理システムは、上で述べた機能を備えることにより、実行要求を満たす並列コンピューティングシステムの実行環境を実行要求毎に生成し、アプリケーションを並列実行させることができる。

実施例２では、アプリケーションの処理ごとに並列度を設定できる情報処理システムの例を説明する。実施例２に係る情報処理システムの構成は実施例１で説明したものと同じなので、構成の説明は略し、実施例１で説明した内容と異なる点についてのみ説明する。

図１３は、実施例２に係る計算機リソース量の設定画面１２００’の例を示している。図１３の設定画面１２００’と図１２で説明した設定画面１２００との違いは、図１３の設定画面１２００’では並列実行可能な処理毎に、並列度設定欄が設けられており（図１３ １２０６’及び１２０６’’）、アプリケーション利用者は処理毎に並列度を設定可能である。また、アプリ管理サーバ１１０がアプリケーションの実行時間を計算する際には、設定画面１２００’’で処理毎に設定された並列度に基づいて計算を行う。

実施例２に係る情報処理システムでは、アプリケーションの処理ごとに並列度を設定できることで、各処理の１回あたりの処理時間が異なる場合に、アプリケーション利用者は処理時間がより大きい処理の並列度の設定を大きくするなどして、トータルの実行時間の短縮の効果が大きく、コストをできるだけ小さくするような施策を選択することができるようになる。

このように、各処理に並列度を設定させることで、たとえば、並列後のトータルの実行時間を指定することで、各処理の並列度を算出する、といった並列度の設定方法や、コストを設定して、それに応じてもっとも実行時間が短くなるような各処理の並列度の設定を算出する、といった並列度の設定方法も考えられる。

以上により、アプリケーション利用者がアプリケーションの実行要求毎に、トータルの実行時間やコストなどの観点から、アプリケーション利用者の希望する計算機リソース量を決定でき、決定した計算機リソースを自動で確保して、アプリケーション利用者がすぐにアプリケーションを並列実行させる並列コンピューティングシステムの実行環境を提供することができる。

なお、上で説明した実施例では、アプリケーションの実行要求の際にクライアント端末１０１から入力データが指定される方法を説明したが、事前にデータ管理サーバ１０４にデータを登録しておき、実行要求の際に、アプリケーション利用者がデータ管理サーバ１０４に蓄積されているデータを入力データとして指定することで、入力データを処理してもよい。

１０１：クライアント端末、１０２：ネットワーク、１０３：リクエスト受付サーバ、１０４：データ管理サーバ、１１０：アプリ管理サーバ、１２０：クラスタ管理サーバ、１３０：処理サーバ

Claims (13)

1. 管理サーバと、複数の処理サーバを有する情報処理システムであって、
   前記処理サーバはそれぞれ、アプリケーションプログラムを実行するための１以上のプロセッサを有し、
   前記管理サーバは、それぞれの前記処理サーバが有する計算機リソースの使用状態を管理しており、
   前記管理サーバは、ユーザから前記アプリケーションプログラムの並列度を受領すると、
   複数の前記処理サーバの有する使用可能な計算機リソースの中から、前記並列度で前記アプリケーションプログラムを実行するために必要な計算機リソースを確保し、
   前記確保された計算機リソースを有する前記処理サーバに、前記アプリケーションプログラムを配置し、前記アプリケーションプログラムを並列実行させる、
   ことを特徴とする情報処理システム。
2. 前記管理サーバは、前記アプリケーションプログラムを並列実行させる時、
   前記確保された計算機リソースを有する前記処理サーバのうち１つを選定し、
   選定された前記処理サーバに対して、前記アプリケーションプログラムの実行を依頼する、
   ことを特徴とする、請求項１に記載の情報処理システム。
3. 前記アプリケーションプログラムは前記プロセッサに、前記ユーザから受領した入力データの処理を行わせるためのプログラムであって、
   前記管理サーバは、前記ユーザから前記入力データと並列度（ｎ）を受け取ると、１つの前記プロセッサが前記アプリケーションプログラムを実行することによって前記入力データに係る処理を実行した場合の実行時間と、ｎ個の前記プロセッサで前記入力データに係る処理を並列実行した場合の実行時間と、を算出して前記ユーザに提示する、
   ことを特徴とする、請求項２に記載の情報処理システム。
4. 前記管理サーバは、前記プロセッサが前記アプリケーションプログラムを実行することによって前記入力データに係る処理を実行した場合の実行時間を算出するための計算ロジックを、前記アプリケーションプログラムごとに保持している、
   ことを特徴とする、請求項３に記載の情報処理システム。
5. 前記入力データに係る処理は、第１の処理と第２の処理を含んでおり、
   前記計算ロジックは、前記第１の処理の実行時間を算出するための第１の計算ロジックと前記第２の処理の実行時間を算出するための第２の計算ロジックとを含んでいる、
   ことを特徴とする、請求項４に記載の情報処理システム。
6. 前記管理サーバは、前記第１の処理の並列度と前記第２の処理の並列度とを受け付け可能に構成されており、
   前記管理サーバは、前記第１の処理の並列度（Ｎ）と前記第２の処理の並列度（Ｍ）とを受け取ると、前記計算ロジックを用いて、
   Ｎ個の前記プロセッサで前記第１の処理を実行した場合の第１実行時間と、Ｍ個の前記プロセッサで前記第２の処理を実行した場合の第２実行時間と、前記第１実行時間と前記第２実行時間の合計と、を算出して前記ユーザに提示する、
   ことを特徴とする、請求項５に記載の情報処理システム。
7. 前記管理サーバは、前記並列度と、前記入力データに係る処理を並列実行した場合の実行時間とから、前記情報処理システムの使用料金を算出して前記ユーザに提示する、
   ことを特徴とする、請求項３に記載の情報処理システム。
8. 前記管理サーバは、前記計算機リソースの使用状態を管理するための管理情報記憶部を有し、
   前記管理サーバは前記管理情報記憶部に、それぞれの前記処理サーバが有するプロセッサ数と、前記プロセッサのうち前記アプリケーションプログラムの実行で使用中のプロセッサ数とを保持しており、
   前記管理サーバは、前記アプリケーションプログラムの並列度を受領すると、
   前記管理情報記憶部を参照することで、複数の前記処理サーバの中から未使用の前記プロセッサを有する前記処理サーバを、前記並列度を充足するために必要な数だけ確保し、前記管理情報記憶部に、前記アプリケーションプログラムの実行で使用する前記処理サーバと前記プロセッサの数についての情報を、前記アプリケーションプログラムの名称と対応付けて記録し、
   前記確保された前記処理サーバに、前記アプリケーションプログラムの実行を依頼する、
   ことを特徴とする、請求項２に記載の情報処理システム。
9. 前記管理サーバは、前記処理サーバから前記アプリケーションプログラムの実行が終了した旨を受領すると、
   前記アプリケーションプログラムを実行していた各処理サーバに、前記アプリケーションプログラムのアンインストールを実行させ、
   前記アプリケーションプログラムの実行に使用していた前記処理サーバと前記プロセッサの数についての情報を前記管理情報記憶部から削除する、
   ことを特徴とする、請求項８に記載の情報処理システム。
10. 前記アプリケーションプログラムは、
    入力データに係る処理を前記プロセッサに実行させるプログラムコードである実行部と、
    複数の前記プロセッサに前記実行部の実行を指示させるためのプログラムコードである振分部と、を有し、
    前記選定された前記処理サーバのプロセッサは前記振分部を実行することで、前記複数の前記処理サーバに、前記実行部を実行させるためのメッセージを発行し、
    前記メッセージを受領したそれぞれの前記処理サーバが前記実行部を実行することで、並列に前記入力データに係る処理を実行する、
    ことを特徴とする、請求項２に記載の情報処理システム。
11. 管理サーバと、アプリケーションプログラムを実行するための１以上のプロセッサを備えた処理サーバを複数有する情報処理システムの制御方法であって、
    ａ） ユーザが前記管理サーバに、入力データと、前記アプリケーションプログラムの並列度（ｎ）を送信する工程と、
    ｂ） 前記管理サーバが、１つの前記プロセッサが前記アプリケーションプログラムを実行することによって前記入力データに係る処理を実行した場合の実行時間と、ｎ個の前記プロセッサで前記アプリケーションプログラムを実行することによって前記入力データに係る処理を並列実行した場合の実行時間である並列処理実行時間と、を算出して前記ユーザに提示する工程と、
    ｃ） 前記ユーザが、前記並列処理実行時間に基づいて、前記アプリケーションプログラムを実行させる時の並列度である実行時並列度を決定する工程と、
    ｄ） 前記管理サーバが前記ユーザから、前記実行時並列度を受領する工程と、
    ｅ） 前記管理サーバが、複数の前記処理サーバの有する使用可能な計算機リソースの中から、前記実行時並列度で前記アプリケーションプログラムを実行するために必要な計算機リソースを確保する工程と、
    ｆ） 前記管理サーバが、前記確保された計算機リソースを有する前記処理サーバに前記アプリケーションプログラムを配置する工程と、
    ｇ） 前記管理サーバが前記処理サーバに、前記アプリケーションプログラムを並列実行させる工程と、
    を実行することを特徴とする情報処理システムの制御方法。
12. 前記工程ｇ）は、
    前記確保された計算機リソースを有する前記処理サーバのうち１つを選定する工程と、
    選定された前記処理サーバに対して、前記管理サーバが前記アプリケーションプログラムの実行を依頼する工程と、
    を含むことを特徴とする、請求項１１に記載の情報処理システムの制御方法。
13. 前記方法はさらに、
    ｈ） 前記処理サーバでの前記アプリケーションプログラムの実行が終了すると、前記アプリケーションプログラムを実行していた各処理サーバに、前記アプリケーションプログラムのアンインストールを実行させる工程、
    を含むことを特徴とする、請求項１１に記載の情報処理システムの制御方法。

Images