JP2005056201A - 異種混合計算機接続システム及びシステムにおける処理割り当て方法及び課金方法 - Google Patents

Abstract

【課題】 異種混合計算機環境上でのサービスにおける適切な処理の割り当てを行う。
【解決手段】 リクエスト管理手段３０２２は、リクエストを受け付け、内容を保持し、リクエスト内容の実行を管理する。リクエスト管理手段３０２２は、リクエストを複数のジョブに分割する。サービス結果出力手段３０２３は、リクエストの実行結果の出力データを生成する。ジョブ実行時間予測手段３０２４は、リクエスト受付時の計算リソースの状況やリクエスト内容に基づいて、リクエスト完了までに要する時間を見積もる。ジョブスケジューリング管理手段３０２５は、リクエストに基づいて分割されたジョブの実行スケジュールを決めるとともに、ジョブの実行状況を監視し、ジョブが終了するとその結果をサービス結果出力手段３０２３に送る。計算リソース情報管理手段３０２６は、グリッド上でジョブを実行可能な計算機の情報を管理する。
【選択図】 図３

Description

本発明は、コンピュータネットワーク上で提供するアプリケーションサービスに関連する処理割り当て技術に関し、特に、複数の計算機などの情報処理装置をネットワークで接続したグリッドシステムにおいて、プログラムやデータを互いに共有できるようにした異種混合計算機接続環境（以下、「異種混合システム」と称する。）上での処理割り当て技術及びそれに関連する課金方法に関する。

科学技術分野における処理の中には、処理が完了するまでに長時間を要する処理が多く存在する。例えば、バイオテクノロジーの分野における遺伝子解析処理や相同性検索処理、原子力分野における実験結果解析処理などが挙げられる。できるだけ短時間でこれらの処理を完了させるためには、スーパーコンピュータ等の高性能な計算機の利用が不可欠である。

しかしながら、高性能な計算機は非常に高価であるため、必ずしも各研究組織において用意することができず、研究者は性能の低い計算機を用いて処理を行わざるを得ない場合が多い。その結果、負荷が大き過ぎ処理の途中で計算機がハングアップし、或いは、ハングアップしない場合でも処理に何日もかかるために少しずつパラメータを変えながら何度も実行する必要がある処理を行うことが実質的に困難になり、研究の効率を低下させる大きな要因となっていた。

このような問題を解決するものとして、近年、グリッドコンピューティングと呼ばれる技術が注目され始めている。グリッドとは、複数の計算機などから構成される異種混合システムを構成し、データやプログラムの実行環境を組織間で互いに共有できるようにした仕組みである。これにより、自身が高性能な計算機を持たない場合でも、グリッド内の高性能な計算機のリソースを利用することができ、高負荷の処理も実行することができる。また、独立して並列に実行できる単位に処理を分割し、グリッド内に存在する複数の計算機にそれぞれ割り当てて実行させることにより負荷を分散し、比較的性能の低い計算機の組合せであっても負荷の大きい処理を実行することが可能になる。

さらに、高性能な計算機を既に複数所有している組織では、グリッドにより負荷の分散が適切に行えるようになる。すなわち、意識的な負荷分散を行っていない場合は、最も高性能な計算機に負荷が集中し、他の比較的低速な計算機は殆どＣＰＵパワーを使っていないという状況に陥りやすいため、所有する計算機をグリッドの一員として管理することにより負荷を分散化させることが可能になり、資源の効率的な利用が可能となる。

これらのメリットを有するため、既にいくつかのグリッドが実験的に構築され、成果を上げている。尚、グリッドにおけるメリットは、科学技術分野においてのみ限定的に得られるものではなく、例えば、商用アプリケーションサービスを効率良く提供するビジネスグリッドへの応用も期待されている。

ところで、グリッドを商用サービスに適用するためには、十分にセキュリティを確保しつつ、利用者の理解が得られるような処理割り当てを行い、かつ、処理割当てに基づいてユーザも満足する課金を行う必要がある。一般的なアプリケーションサービスに対する課金方法に関しては、サービスの種類に応じて一定の契約期間に対して一定の料金を課す固定額方式と、サービス利用回数、サービス利用時間、使用したリソースの量などの変動値に応じて課金する従量制方式とが存在する。従量制の場合は、利用回数に応じて課金する方式と、サービス完了までに要したＣＰＵ占有時間又はメモリ占有量などに基づいて金額を算出する方式とがある。

グリッドを利用したサービスの場合は、サービスの実行をグリッドのいずれの計算機に割り当てたかにより、実行速度に大きな違いがある。グリッドはスーパーコンピュータ、汎用大型計算機、ワークステーション、パーソナルコンピュータ、クラスタシステム等、様々なハードウェアと、様々なオペレーティングシステムと、によって構成されるのが一般的であるため、同じサービスを実施する場合でも、そのサービスを実装するプログラムをいずれの計算機上で実行させるかによってターンアラウンドタイムは異なってくる。これは、計算機が持つＣＰＵ性能やメモリ搭載量などの静的な要因のみではなく、サービス実行時に他の処理によって既に消費されているメモリやＣＰＵパワー、ネットワークトラフィックなどの動的な要因にも影響される。

複数のサービスが実行されている場合は、それぞれのサービスを分割したジョブの割り当てが同一の計算機に集中しないようにスケジューリングを行う必要がある。クラスタシステムにおいては、並列処理のためのスケジューリングが行われる。グリッドにおいても、異種計算機間でのスケジューリング、指定期限内にジョブを完了させるための研究がなされている。しかし、現状のグリッドは科学技術分野での共同研究を目的とした利用、又は、ボランティアベースで利用されるのがほとんどであり、商用利用を目的とした課金を伴うアプリケーションサービスが実施されている例は見られない。

本発明は、異種混合計算機環境上でのサービスにおける適切な処理の割り当てを行うとともに、それに応じた課金が可能なシステムと方法とを提供することである。

本発明の一観点によれば、複数の計算機をネットワークにより接続したグリッドを含む異種混合計算機接続システムにおいて、利用者からのリクエストを実行するプログラム上の処理を複数のジョブに分割するリクエスト管理手段と、前記グリッド上のそれぞれの前記計算機の静的性能と動的に変化する計算機の負荷状態又はネットワークのトラフィック状況を含む動的性能とを含む計算リソース情報を管理する計算リソース情報管理手段と、前記計算リソース情報と前記リクエストの内容とに基づいて、分割された前記それぞれのジョブを複数の前記計算機に動的に割り当てる管理を行うジョブスケジューリング管理手段とを備えたことを特徴とする異種混合計算機接続システムが提供される。

上記システムによれば、静的性能と動的に変化する動的性能とを考慮して、分割されたジョブの割り当てを行うため、複数の計算機をネットワークにより接続したグリッドを含む異種混合計算機接続システムにおいてリクエストに応じた適切な処理を行うことができる。

さらに、分割した前記ジョブと割り当てられた前記計算機とに関する処理の実行結果の履歴データを格納する実行履歴データベースと、該実行履歴データベースに格納された前記履歴データを更新する処理を行うデータ更新部と、最新の前記履歴データと前記ジョブスケジューリング管理手段により割り当てられたジョブと計算機との組合せとに基づいて、ジョブの実行時間を予測するジョブ実行時間予測手段とを有する。上記システムにおいては、処理毎に更新されていく過去の実行履歴を考慮してジョブの実行時間を予測するため、予測の精度を高めることができる。

さらに、選択された計算機の組合せとそれぞれの計算機上で使用するリソース量と使用時間とに応じて前記リクエストに応じたサービスに対する課金金額を求める課金算出部を有する。上記システムにおいては、選択された計算機の組合せとそれぞれの計算機上で使用するリソース量と使用時間とに応じて課金金額を求めるため、リクエストに応じた適切な課金を行うことができる。さらに、前記リクエストに応じたサービスの実行終了までに要する時間と課金金額との組合せを提示する手段を有する。これにより、サービスの実行期限又は課金金額の上限を利用者に選択させることができる。

さらに、前記課金金額が前記利用者により指定された上限値以下になるように、ジョブを割り当てる計算機の組合せを動的に選択する手段を備える。これにより、利用者は、自己の予算範囲内において適切な処理の選択を行うことができる。さらに、利用者が指定した期限までにサービスを完了できる確率を利用者に提示する手段を有する。これにより、利用者にサービス実行期限の再考を促す機会が得られる。

さらに、利用者が指定した実行期間と、予め提示された時間内でのサービス完了確率と、実際の実行期間とに基づいて、課金金額を変更する手段を有する。例えば、結果に応じて、料金を割り引くか、又は払い戻すことができる。予期せぬ障害があった場合の課金にも対応可能である。さらに、複数の利用者が利用する計算リソースが競合した場合に課す追加料金の代わりに、その利用者のジョブの実行優先度を上げることもできる。他の利用者のジョブに優先して実行することで、特定利用者のサービスのターンアラウンドタイムを最小にする手段を備える。

さらに、複数の利用者から同時に追加料金に関する指定がなされた場合に備えて、予め優先度を記憶する手段を備える。追加金額が大きい順、利用者の所属機関や過去のサービス利用回数などによる顧客優先度順といった、あらかじめ決められたポリシーに基づいて、優先度を決めることができる。

本発明の他の観点によれば、複数の計算機をネットワークにより接続したグリッドを含む異種混合計算機接続システムにおいて、前記グリッド上のそれぞれの前記計算機の静的性能と動的に変化する計算機の負荷状態又はネットワークのトラフィック状況を含む動的性能とを含む計算リソース情報を取得するステップと、利用者からのリクエストを実行するプログラム上の処理を複数のジョブに分割するステップと、前記グリッド上のそれぞれの前記計算機の静的性能と動的に変化する計算機の負荷状態又はネットワークのトラフィック状況を含む動的性能とを含む計算リソース情報を監視するステップと、前記計算リソース情報と前記リクエストの内容とに基づいて、分割された前記それぞれのジョブを複数の前記計算機に動的に割り当てるための管理を行うジョブスケジューリングを管理するステップとを備えたことを特徴とする異種混合計算機接続システム管理方法が提供される。

本発明を用いることにより、異種混合計算機環境上でのサービス提供能力の変動に応じて、計算機と分割されたジョブとの割り当てを適切に決めることができ、効率的な資源の利用が可能となる。また、提供可能な各サービスについて、完了期限とその期限内にサービスが完了する確率の組を提示して利用者がサービス完了の確度を知る目安とすると共に、完了期限ごとに課金金額も変動させ、利用者が自身の都合に合わせてサービスの品質を選択できるようになる。これによりサービス全体の使い勝手が向上し、それに伴いサービス提供者側の収入増加につながる効果が期待できる。

利用者の立場からすると、サービスの利用において重要となる要素は、サービスの金額とサービス完了までにかかる時間である。同じ内容のサービスであれば、完了までに要する時間が短ければサービスの品質が高く、長時間かかる場合にはサービスの品質が低いと言える。品質の高いサービスほど高額にするのが妥当であると考えられる。利用者が、サービス利用時毎にその品質を指定できることが好ましい。これにより、サービス利用者の、「いくら時間がかかっても良いから安く」、「速さが最優先」などの要望に十分応えることができる。

サービスの品質は、同時に複数の利用者からのサービス要求の集中、ネットワークトラフィックの変動などによって簡単に変動する。また、アプリケーションサービスがグリッド上で構築されている場合は、グリッドを構成する計算機の増減によってもサービス品質が変動する可能性がある。サービスを実行する場合に、品質が激しく変動しないようにする必要がある。グリッドは、クラスタシステムと異なり、インターネット／イントラネットのドメインをまたがって構築される場合があり、各ドメインはそれぞれ別の組織で管理され、計算機やネットワークは組織毎に管理される。例えば、ある組織がグリッド用に提供している計算機が停電などで使えなくなれば、それがサービスの品質低下の一因となり得る。サービス品質の低下を防ぐことは難しいが、利用者が事前に品質を有る程度把握できることが望ましい。

また、利用者が指定した時刻までにサービスが完了しなかった場合には、利用者の要望が高い対策として、遅延分の料金の割引または返却、失敗する確率の事前提示、他の利用者と比べてサービス実行の優先度を上げることにより処理時間の短縮などの対策を行う。

以下、本発明の実施の形態によるグリッドについて図面を参照しつつ説明を行う。

図１は、本発明の実施の形態によるグリッドのハードウェア構成例を示す図である。本実施の形態によるグリッド１０１は、例えば、５台の計算機１０２〜１０６までを含んで構成されている。５台の計算機を結ぶ線分は、計算機１０２〜１０６が互いにネットワーク的に接続されていることを模式的に示している。これらの構成は、実際には一般的なＬＡＮ構成により実現することができる。但し、計算機１０２〜１０６は、必ずしも同一ネットワークドメイン又は同一組織内に設置されている必要はなく、ネットワーク接続が確保できていれば、組織間をまたがっていてもよい。

グリッド１０１を構築する５台の計算機１０２〜１０６のうち、１０３〜１０６までの４台は、アプリケーションサービスを実行するための計算リソースとして機能している。計算機１０２は、グリッド１０１の外部のネットワークと接続され、サービスを公開すると共にサービスの具体的な実行を計算リソースに依頼する中間サーバとして機能する。クライアントコンピュータ１０７は、イントラネットまたはインターネットを通して中間サーバ１０２に対してサービスの実行を要求するクライアントである。

図２は、本実施の形態によるグリッドのソフトウェア的な構成の概要を示した図である。クライアントコンピュータ２０１（図１においては符号１０７で示される。）には、サービスを利用するためのクライアントアプリケーション（プログラム）２０１１が含まれる。中間サーバ２０２（図１においては符号１０２で示される。）は、クライアントコンピュータ２０１からのサービス利用要求の受付、クライアントコンピュータ２０１へのサービス実行結果の返送等を行うリクエスト受付部分２０２１と、サービスのリクエストを処理すると共に計算リソースの管理を行うグリッドミドルウェア２０２２と、グリッド内の他の計算機との通信を受け持つグリッドインタフェース２０２３とを含んで構成される。

計算リソース２０３（図１では、符号１０３〜１０６までで示される）は、グリッドインタフェース２０３１と、サービスを実際に実行するプログラムであるサービスアプリケーション２０３２とを含んで構成される。グリッドインタフェース２０３１は、グリッドを構成する計算機間での認証及び通信処理を行う部分であり、例えばアルゴンヌ国立研究所と南カリフォルニア大により作成されたGlobus Toolkit等を用いて実施することができる。グリッドミドルウェア２０２２は、リクエストのジョブへの分割、ジョブを実行する計算リソースの選択、ジョブ実行に必要なデータやプログラムの計算リソースへの送信及び結果の受信、分割したジョブから得られた処理結果の統合などを行う。このうち、計算リソースとの通信はGlobus Toolkitの提供するAPIを用いて実施することができる。本実施の形態によるグリッドにおける、グリッドミドルウェアでの計算リソース選択やジョブ（コンピュータでの実行単位）の実行に関する管理方法上の特徴点について詳細に説明する。

図３は、グリッドミドルウェアを実現するソフトウェアモジュールの内部構造例を示すブロック図である。リクエスト受付部分３０１は、クライアントからのリクエストを受け付けるモジュールであり、一般的なウェブアプリケーションの場合と同様にＨＴＴＰサーバとサーブレット等との形態で実施される。グリッドミドルウェア３０２は、機能により以下のように細分化される。

アカウント管理手段３０２１は、リクエストを要求してきた利用者に本実施の形態によるサービスの利用許可があるか否かをチェックするための機能を有するモジュールであり、例えば、一般的な利用者名とパスワードによる認証処理を行う。リクエスト管理手段３０２２は、認証を通った後のリクエストを受け付け、内容を保持し、リクエスト内容の実行を管理する。サービス結果出力手段３０２３は、リクエストの実行結果の出力データを生成する。ジョブ実行時間予測手段３０２４は、リクエスト受付時の計算リソースの状況やリクエスト内容に基づいて、リクエスト完了までに要する時間を見積もる。ジョブスケジューリング管理手段３０２５は、リクエストに基づいて分割されたジョブの実行スケジュールを決める。また、ジョブの実行状況を監視し、ジョブが終了すると、その結果をサービス結果出力手段３０２３に送る。

計算リソース情報管理手段３０２６は、グリッド上でジョブを実行可能な計算機の情報を管理する。グリッド上の計算機に定期的にアクセスし、ＣＰＵの負荷状況やメモリ使用状況などを確認するとともに、グリッド上の計算機の増減を監視する。グリッドインタフェースは、グリッド上の計算機と通信するためのインタフェースモジュールである。グリッドインタフェースは、中間サーバと計算リソースとの双方に設置される。図２に示すように、中間サーバ２０２側のグリッドインタフェース２０２３は、計算リソース２０３に対して、プログラムの実行指示を送る。計算リソース２０３のグリッドインタフェース２０３１は、中間サーバ２０２から送付された実行指示に基づいてサービスアプリケーション（２０３２）を実行し、結果を返送する。ジョブ実行履歴管理手段（３０２７）は、ジョブの実際の処理時間の実測値を記録・更新・参照できるようにする部分である。これらのモジュールを用いて具体的に提供されるサービスに関して以下に説明する。

図４は、アカウント管理手段３０２１（図３）が実行する利用者認証画面の一例を示す図である。この画面はクライアントコンピュータ上で動作するWWWブラウザ等のウィンドウ４０１として表示され、ウィンドウの内部に例えばＨＴＭＬ等で実装された認証画面４０２が表示される。認証画面には、利用者名を入力するログイン領域４０３と、パスワードを入力するパスワード領域４０４と、認証の開始を指示するＯＫボタン４０５と、認証の中止を指示するキャンセルボタン４０６とが含まれる。この画面は、インターネット上でＣＧＩ等を用いて実装される一般的なサービスの認証画面と同様である。

図５は、本実施の形態によるグリッド上のアプリケーションサービスの一覧を示す表示画面例である。図４での認証処理により承認されると、このサービスメニュー画面５０１に移行する。この例では３種類のサービスＡ〜Ｃまでの一覧が表示されており、実行するサービスを選択するためのラジオボタン５０２も表示されている。各サービスＡ〜Ｃでは、実行のためのパラメータを指定することができる。パラメータの具体例としては、例えば、サービスの内容が塩基配列の相同性検索とすると、問合せ配列と対象データベース名がパラメータとして考えられる。

「serviceＡ」では、第１及び第２の２種類のパラメータを設定するための領域５０３、５０４が表示されている。同様に、「service Ｂ」と「service Ｃ」では１つずつパラメータ設定領域５０５，５０６が表示されている。必要となるパラメータの数はそれぞれのサービスによって異なり、サービス実装者によって規定される。見積依頼ボタン５０７を押すことにより、選択したサービスの指定パラメータにおける実行の見積依頼が行われる。キャンセルボタン５０８を押すと何もせずに図４の画面に戻る。

図６は、「service Ａ」に対して見積依頼を実行した場合の見積結果表示画面６０１を示す図である。符号６０２で示す領域は、このサービスの依頼時における最短実行完了時間の予測値を表示する領域である。予測値を求める方法に関しては後述するが、基本的に実行時間を短くしようとするほど多くの計算リソースを使用する必要がある。そこで、サービス提供者は、実行時間に応じた課金金額を設定する。領域６０３には、予測実行時間の範囲と課金金額との組合せ一覧表が示されている。利用者は、この一覧表の中から、好みの組合せをラジオボタン６０４により選択する。実行ボタン６０５を押すと、実際にサービスが開始される。また、キャンセルボタン６０６を押すと図５の画面に戻る。

図７は、本実施の形態によるサービスを利用する一連の処理の流れを示すフローチャート図である。まず、図１、２に示すシステムにおいて、図４に示すようなログイン画面をクライアント側に送り、利用者はクライアント上のブラウザ等を用いてアカウント名とパスワードとを入力しログインを行う(701)。次に、アカウント管理手段３０２１（図３）において、入力された利用者名とパスワードとを検証し、認証処理を行う(702)。認証が成功したか否かをチェックし(703)、認証処理が失敗した場合は認証が失敗した旨をクライアント側に知らせる認証不可画面の表示用データを生成し、この表示用データをクライアントへ返送する(704)。

認証が成功した場合は、例えば、図５に表示されるようなサービスメニューを表示させるデータをクライアント側に送る(705)。クライアント側では、利用者にサービスの選択とパラメータの入力とを促し、入力されたデータに基づいて見積要求を中間サーバ側に送る(706)。中間サーバでは、得られたパラメータの内容と、計算リソース情報管理手段が保持する情報とに基づいて、サービス実行時間の見積データを生成する(707)。サービス実行時間の見積データを生成する方法に関しては、図８以降を参照して後述する。

次に、生成した見積データをクライアント側に送る(708)。クライアント側では、利用者に対して例えば図６に相当する見積結果を表示し、サービスの実行又は取り消しの決定を促す。クライアント側の判断によりサービスの実行が決定され、その旨の入力操作が行われると、クライアントからサービス実行要求が中間サーバに送られ(709)、中間サーバはグリッド上の計算リソースを用いてサービスの実行処理を行う(710)。尚、グリッドを用いてサービスを実行する処理の詳細に関しては後述する。

中間サーバはサービス実行処理の結果をチェックし(711)、正常に終了していた場合は複数の計算機から得られた実行結果を合成しサービス全体の出力を生成する(712)。また、異常終了した場合は、失敗であった旨を示す画面データを生成する(713)。最後に、サービスの結果(成功または失敗)をクライアント側に返送する(714)。

図８は、図７のステップ707の処理の詳細な流れを示すフローチャート図である。この処理はジョブ実行時間予測手段３０２４（図３）により行われる。まず、サービスが完了する最短の実行時間を予測する(801)。最短実行時間の予測方法の詳細は図１５を参照して説明する。次に、サービス提供者が別に用意した課金設定ファイルを開き、その内容を参照できるようにする(802)。

課金設定ファイルの例を図９に示す。課金設定ファイルは、例えば１行ずつ参照する。図９に示す表示例９０１では、１行につき３つの数値がカンマで区切られて記述されている。各行の左から１番目と２番目の数値は、サービス時間の範囲を規定するものであり、サービス最短実行時間を基準として、範囲の開始値と終了値とを例えば分単位で指定している。３番目の数値は課金金額を円単位で示している。例えば、２行目のデータでは、サービス時間の範囲がサービス最短実行時間の６０分後から１７９分後までの範囲では、８００円を課金することを示している。フローチャート図では、読み込んだファイルに行データが残っているか否かをチェックし(803)、もし残っていれば行データの内容から時間範囲と課金金額とを計算する(804)。行データが残っていない場合は、これまでに計算したサービス時間範囲と課金金額データとから見積表示用のデータを生成する(805)。生成した見積表示用データは図６の表示例に相当する。

計算リソース情報管理手段３０２６（図６）は、グリッドインタフェース３０３（図３）を用いて、リモートの計算機からデータを定期的に入手する。計算リソース情報は、装備するＣＰＵのクロック数や搭載メモリ容量、ハードディスクの容量などの比較的静的な情報と、ＣＰＵの負荷状況や空きメモリ状況などの比較的動的な情報とに分類される。以降、グリッド上で実際にサービスを実行するプログラムを実装している計算機をワーカと呼ぶ。

図１０は、各ワーカから収集する静的情報を指定する一覧表の例である。この例では、５台のワーカについて、ＣＰＵのクロック数１００１と搭載メモリ容量１００２とを、グリッドインタフェースを用いて定期的に入手する。静的情報の場合は、収集間隔を1日おき等の単位に設定する。

図１１は各ワーカの動的情報を指定する一覧表の例である。この例では、５台のワーカについて、ネット到達性１１０２と、割り当て中のジョブの数１１０３と、ＣＰＵ負荷状況と、空きメモリ状況とを管理している。このうち、グリッドインタフェースを用いてワーカ上でuptime等のコマンドを実行した結果を収集するものはＣＰＵ負荷１１０４と空きメモリ情報１１０５とであり、例えば１分おきに収集するようにグリッドインタフェースプログラムを設定しておく。ネット到達性は、例えば中間サーバ上でpingコマンドを実行し、その応答時間を記録する。割当中ジョブは、中間サーバ側でワーカに割り当てたジョブの数を記録する。状態１１０１は、ネット到達性が無い場合や、ワーカがハングアップしている等、ジョブを割り当てることができない状態である場合にｄｏｗｎとし、それ以外をＯＫとする。

図１０と図１１とのそれぞれの値は、計算リソース情報管理手段において保持し、常に最新の情報になるように管理する。どのコマンドを実行すればどのようなデータがどのような形式で得られるかは、計算機のプラットフォームにより異なるが、各計算機上で実行するコマンドを記述したスクリプト（またはバッチファイル）を用意し、それをグリッドインタフェースから呼び出すようにすることにより解決できる。

図１２は、サービス毎のワーカのリストを記述したファイル名を記述した表である。リクエスト管理手段では、サービスを実行するプログラムが、どの計算機上に実装されているかを知っている必要がある。この例では、「service A」のワーカリストがファイル「serviceA_workers」(1201)に記述されていることを示している。「service B」、「service C」もそれぞれ「serviceB_workers」、「serviceC_workers」に記述される(1202,1203)。図１３は、図１２に示すそれぞれのワーカリストファイルの内容を示した図である。図１３に示すように、この例では、「service A」のワーカは、worker01、worker02、worker04、worker05という名前の計算機であることを示している(1301)。同様に、「service B」のワーカはworker01、worker03、worker04であり(1302)、「service C」のワーカはworker01、worker03、worker05であることを示している(1303)。

ジョブ実行履歴管理手段３０２７（図３）においては、分割したジョブと割り当てられた計算機とに関する処理の実行結果の履歴データを格納する実行履歴データベースが設けられているのが好ましい。この実行履歴データベースに格納された前記履歴データはジョブ実行履歴管理手段により常に更新される。ジョブ実行時間予測手段は、最新の履歴データとジョブスケジューリング管理手段により割り当てられたジョブと計算機との組合せとに基づいて、ジョブの実行時間を予測する。すなわち、例えば、図１０から図１３までに示した表と、図１４に示す過去の実測値データと重み付けパラメータとに基づいて、サービスの最短実行完了時間の予測値を算出する。サービスの実行時間は、サービスに与えるパラメータと、サービスを実行するワーカの性能とによって決まる。様々なワーカ上での様々なパラメータによる実行時間を予測するために、基準となる性能のワーカ上で基準となるパラメータによるサービス実行時間の測定値を記録しておく。図１４では、基準となるパラメータとそのパラメータでのサービス実行時間の実測値の記録１４０１（図１４ａ）及びその時に使用したワーカの性能値の記録１４０５（図１４（ｂ））との例を示している。符号１４０２で示す領域には、「service A」のサービス実行時間の実測値が、符号１４０３と１４０４には、その時に指定したパラメータが記録される。

また、符号１４０６は、実測時のワーカのＣＰＵクロック数(メガヘルツ)であり、符号１４０７は搭載メモリサイズ(メガバイト)であり、符号１４０８はｐｉｎｇコマンドのレスポンス(ミリ秒)であり、割り当て中のジョブの数、ＣＰＵの平均負荷、空きメモリサイズ（メガバイト）を示した例である。

これらの情報から、異なるワーカ上での異なるパラメータでのサービスの実行時間(Tx)を算出する計算式としては、例えば、以下の（１）式を用いる。
T_x = [ w₁・(p_1x - p_1r)/p_1r + w₂・(p_2x - p_2r)/p_2r + w₃・(s_1x - s_1r)/s_1r + w₄・(s_2x - s_2r)/s_2r + w₅・(s_3x - s_3r)/s_3r + w₆・(s_4x - s_4r)/s_4r + w₇・(s_5x - s_5r)/s_5r + w₈・(s_6x - s_6r)/s_6r ]・T_r + T_r （１）

ここで、p_ir(service Aの場合、iは１〜２)は基準としたパラメータから導き出される値であり、符号１４０１に示した表で指定した内容から得られる値である。例えば、相同性検索の場合は、問合せ配列と対象データベース名がパラメータとして与えられ、p₁およびp₂はそれぞれのサイズを用いるという仕様が考えられる。p_ix(service Aの場合、iは１〜２)は、予測しようとするサービスのパラメータから導き出される値を表す。また、s_ir(iは１〜６)は基準とするワーカの性能値であり、符号１４０５で示される表（図１４（ｂ））で指定した値である。s_ix(iは１〜６)は予測しようとするサービスを実行するワーカの性能値である。w_i(service Aの場合、iは１〜８)は、各パラメータや性能値の差に対する重みを表す値であり、サービス毎に重み付けの調整などの設定がなされる。サービスＡと同様にサービスＢに関しても同様に補正を行うことができる。

「service A」における重みの例を図１４（ｃ）の領域１４１２に、「service B」における重みの例を図１４（ｄ）の符号１４２１に示す。また、Ｔ_rは符号１４０２に示した基準実測値である。この式では、それぞれのパラメータやワーカ性能値の差異に、指定した重みをかけた値の和を基準実測値Ｔ_rに乗算して予測値T_xを算出している。もちろん、予測値の算出方法としては（１）式に基づく方法に限られる訳ではなく、様々な式に基づいてジョブ実行時間予測手段を実装することができる。符号１４１２に示した重みの例では、例えば、基準のワーカのＣＰＵクロック数が１０００ＭＨｚであり、ジョブを実行しようとするワーカのＣＰＵクロック数が１２００ＭＨｚであり、他の要素が全て同一の場合は、基準値T_rと比較して０．９T_rの処理時間になるという予測値を算出する。サービス提供者は、この予測値ができるだけ実際の値に近くなるようにサービス毎の重み（１４１２，１４２１）を、実験等を通じて設定することができる。

図１５は、各ワーカでのサービスの実行予測時間を算出し、分割したジョブを実行させるワーカの割り当てを決定する処理の流れを示すフローチャート図であり、図８の符号８０１の処理を詳細に示す図である。図１５に示す処理は、ジョブスケジューリング管理手段３０２５（図３）において行われる。まず、計算リソース情報管理手段３０２６（図３）から、リソース情報の一覧を取得し、その中から、図１３に示すワーカファイルの情報を元に、指定のサービスを実行できるワーカ数を調べ、性能が高い順にランキングを作成する(1501)。次に、リクエストを複数のジョブに分割する(1502)。分割の方法や個数はサービスアプリケーションの制限に従う。例えば、サービスのリクエストを並列して実行することが可能なワーカの個数分のジョブに分割する。「service A」の２つのパラメータがある値の範囲を表しており、範囲の指定で分割可能であるとすると、例えば、各ジョブでパラメータの値をそれぞれ変えることによりジョブを分割する。

次に、図１４の内容を記述したファイルを参照して基準パラメータと実測値データを取得し、式（１）に基づいて、各ワーカ上で各ジョブを実行した場合の予測実行時間を計算する (1503)。そして、全体の処理時間が最小になるように各ワーカに割り当てるジョブを決定する (1504)。最後に、ジョブ実行部分以外のリクエスト処理のオーバヘッド分を加えて、リクエスト全体の処理時間を算出する (1505)。

図１６は、ステップ１５０３で生成される、service Ａを実行可能なワーカと４分割したジョブ１〜４の処理時間予測の一覧表である。第１列（１６０１）はservice Aを実行可能なワーカの名前を表し、第２列（１６０２）は各ワーカが基準とする計算機の性能に比べて基準となるジョブを実行するためにどの程度の時間を要するかを示している。この例では、worker04は基準とする性能の計算機と同等の性能を有することを示し、worker04は同じジョブを実行するのに0.6倍の時間しかかからず、worker05は逆に1.5倍の時間がかかることを示している。第３列から第６列（１６０３〜１６０６）は、分割したそれぞれのジョブが、実際に指定されたパラメータを用いて各ワーカ上で実行されたとき、どの程度の時間がかかるかを（１）式に基づいて予測した値である。ジョブの分割は必ずしも等分に分割できるとは限らず、この例ではジョブ１が最も負荷の高いジョブとなり、worker04上で3300秒を要し、同様にジョブ２が2500秒、ジョブ３が2400秒、ジョブ４が1800秒を要している。worker01では、それぞれ0.6倍の時間を要する。この表に基づいて、最も時間のかかるジョブに最速のワーカを割り当てていく。図１６において、太字で書かれた数値が、全体の処理時間が最も短くなる組合せを示している。

図１７は、中間サーバと各ワーカにおける、リクエスト実行のタイムチャートの一例である。リクエスト全体の処理時間は、リクエストの受付とジョブへの分割処理、ジョブの発行処理、各ワーカ上でのジョブ実行、ジョブ実行結果の統合処理から構成される。ジョブ実行部分は、前述のように最も全体の時間が短くなる組合せを求める。それ以外の部分は、予め実測値の平均を求めておき、これを基準として決定する。これらを足し合わせて、最終的なサービス最短実行時間の予測値を算出する。

以上の方法により、最短の時間でサービスを実行終了できるようにジョブを割り当てる計算機の組合せを動的に選択することができる。また、これに基づいて、課金金額を動的に決定し、さらにサービス実行時間と課金金額との組合せを利用者に提示することが実現できるようになる。

一方、予め上限の時間が与えられており、その上限の時間に間に合うようにワーカにジョブを割り当てていくことも可能である。図１８は、図１６と同内容であるが、選択したジョブとワーカとの組合せ（太字で記載）が異なっている。例えば、リクエスト受付・ジョブ分割処理にかかる時間が100秒、ジョブ発行処理が1回につき10秒、結果統合が50秒としたとき、これらの合計は190秒程度となる。もし、上限の実行時間が7000秒程度と指定された場合、図１８に示したように、worker04とworker05だけを使って時間内にリクエスト全体の処理を終了することができる。図１９にその場合のタイムチャートの例を示す。この組合せでは、worker04とworker05に二つずつジョブを割り当てている。このようにworker01とworker02を空けることで、別のリクエストのジョブを割り当てるための余裕を持たせることができる。

図２０は、制限時間内にリクエストに関する処理を終了できるようにジョブとワーカとの組合せを決定する処理の流れを示すフローチャート図である。まず、指定されたリクエスト処理上限時間から、リクエスト受付・ジョブ分割処理の時間、ジョブ発行処理の時間にジョブ分割数を乗算した時間、結果統合の時間を差し引いて、ジョブ実行の上限時間を求める(2001)。次に、利用可能なワーカが残っているか否かをチェックする(2002)。もし、利用可能なワーカが残っていなければ、指定された時間内でリクエストを終了させることは不可能と判断して(2007)終了する。利用可能なワーカが残っている場合は、最も低速なワーカを割当てリストに追加する(2003)。次に、割当てリストに含まれているワーカと分割したジョブの組合せの中から、全体の処理時間ができるだけ小さくなる組合せを求める(2004)。2004の詳細図２１を参照して後述する。求めた最速の組合せでのジョブ実行時間が2001で求めた制限時間内に収まっているか調べ(2005)、もし収まっていた場合はその組合せを最適解とする(2006)。ステップ2005で、もし制限時間内に収まっていない場合は、ステップ2002へ戻る。

図２１は、ワーカにジョブを割り当てる処理の流れを示すフローチャート図であり、図２０のステップ2004と図１５のステップ1504の処理の詳細を示す図である。最初に、割当て可能な各ワーカのジョブ実行時間の累計値を0で初期化する(2101)。次に、まだ割り当てていないジョブがあるか否かを調べる(2102)。割り当てていないジョブが残っている場合は、最も重いジョブ（いずれかのワーカ上での実行時間が最も大きいもの）から順に、割り当てるワーカを決める。この時、各ワーカのそれまでの実行時間の累計値に、新たに割り当てるジョブの実行時間を加えた値が最小になるようにワーカを選択する(2103)。割り当てたワーカの実行時間累計値を更新した後、ステップ2102へ戻る。ステップ2102において未割り当てジョブが残っていない場合は処理を終了する。

図８、図１５の処理により求めたサービス実行時間の見積値は、各ワーカの状況の値が見積計算時から変化しないことを前提として算出している。サービス要求が集中する時間帯などでは、サービス実行後に他の利用者によるリクエストによってワーカの負荷が急激に増大して、見積作成時で指定した時間内にサービスが完了しない可能性が高くなる。そこで、見積データ生成時に、処理時間と課金金額に加えて、その時間内でサービスを完了できる確率を併記することにより、利用者の不安を軽減することがきる。成功確率が低くなっている場合は、利用者は、その時間帯がサービスの品質が不安定な時間帯であることを知り、別の時間帯でのサービス利用に変更するなどの判断契機を得られる。図２２にサービス成功確率を併記した見積画面の表示例を示す。この図は、図６に、各時間範囲内にサービスが完了する確率(2201)が追加表示されている。

成功確率は、利用可能なワーカの数と、各時間帯でのジョブの実行履歴と、サービス完了までの最短実行時間と指定上限時間との差と、から算出する。図２３は、ジョブ実行履歴の例である。ジョブ実行履歴はジョブ実行履歴管理手段(3027)が保持・管理する。符号2301は、０時から１２時までの、符号2302は１２時から２４時までの１時間ごとのジョブ発行の平均回数を示す表である。ここでは、あるワーカ上でのあるジョブの実行時間が、例えば100秒とするとき、同じジョブを一つのワーカ上で同時に二つ実行させた場合は、各ジョブの実行時間は200秒になるものとする。すなわち、同時にｎ個のジョブが稼動している間は、各ジョブの実行速度はｎ分の１になるもとのして計算する。この計算方法に基づいて、あるワーカ上でジョブが稼動中の時、いくつのジョブが追加されると指定された制限時間をオーバーしてしまうかを求めることができる。追加されるジョブの実行時間はジョブ実行時間の平均値で計算する。

図２４は、リクエストが制限時間内で終わる確率を求める処理の流れを示すフローチャート図である。まず、各ワーカ上でのジョブの予定実行時間と制限時間を算出する(2401)。次に、予定実行時間が制限時間を超えるには予定実行時間をｎ倍する必要かある場合のｎの値を求める(2402)。利用可能なワーカの数にｎを掛けた値を、制限時間内でリクエストを終了することができる限界ジョブ追加数とする(2403)。図２３の頻度表からリクエスト開始時刻の平均ジョブ発行数を参照し、それを平均とする正規分布と限界ジョブ追加数から、実際に発行されると予測されるジョブ数が限界追加ジョブ数を超えない確率を求め、これを成功確率とする(2404)。図２５に、正規分布の図を示す。限界追加ジョブ数以下の部分の面積が成功確率となる。成功確率の要素を加味して課金金額を設定することもできる。例えば、ジョブが制限時間内に終了しなかった場合は、(1−成功確率)×予定金額を実際の課金金額とすることが考えられる。

追加料金を課すことにより、特定利用者のジョブの実行優先度を上げ、他の利用者よりも早くリクエストが完了するようにすることができる。同一内容の二つのジョブを一つのワーカ上で同時に実行した場合、もし二つのジョブの優先度が同じならば、二つのジョブは同時に終了する。しかし、例えばUNIXのniceコマンド等を用いてジョブの優先度を調整することにより、両者のジョブ実行速度のバランスを変えることができる。

図２６は、図６に優先度設定機能を追加した画面例である。２６０７に優先度を上げる設定値を入力する。優先度をあげた場合の最短実行時間見積は２６０２に表示される。２６０３の一覧表では、優先度上昇により短縮された分の時間範囲と課金金額が追加表示する。

図２７は、複数の利用者が同一の優先度の設定を行った場合の処理の流れを示すフローチャートである。まず、図２６の画面から入力された優先度情報を読み取り(2701)、その値に適応した優先度でジョブが稼動中でないか調べる(2702)。もし、同一優先度のジョブがあった場合、それぞれのジョブの利用者情報を参照し、利用回数の多い方の利用者のジョブ優先度を＋１する(2703)。同一の優先度でなかった場合は入力された優先度をそのまま用いる。最終的に設定された優先度で、ジョブを発行する(2704)。図２８は、利用者情報の一例である。2801は利用者名を表し、2802はジョブの累積発行回数を表す。利用者毎にジョブ発行回数累計が示される。

以上説明した通り、本実施の形態によれば、異種混合計算機環境上でのサービス提供能力の変動に応じて、提供可能な各サービスについて、完了期限とその期限内にサービスが完了する確率の組を提示して利用者がサービス完了の確度を知る目安を得ることができる。また、完了期限ごとに課金金額を変動させることで、利用者自身の都合に合わせてサービスの品質を選択できるようになる。これによりサービス全体の使い勝手が向上し、それに伴いサービス提供者側の収入増加にもつながる効果が期待できる。

本発明によれば、異種混合計算機環境上でのサービス提供に関する課金を含めた種々の情報を得ることができる。また、上記処理手順をコンピュータに実行させるためのプログラムも本発明の範疇に入るものである。

本発明の一実施の形態によるグリッドのハードウェア構成例を示す図である。 本発明の一実施の形態によるグリッドのソフトウェア構成例を示す図である。 グリッドミドルウェアを実現するソフトウェアモジュールの内部構造例を示したブロック図である。 アカウント管理手段が実行する利用者認証画面の一表示例を示す図である。 本実施例によるグリッド上のアプリケーションサービスの一覧を示す画面の一例である。 見積結果表示画面例を示す図である。 本実施の形態によるサービスを利用する一連の流れを示すフローチャート図である。 見積生成処理の詳細を示すフローチャート図である。 課金設定ファイルの構成例を示す図である。 各ワーカから収集する静的情報を指定する一覧表の例を示す図である。 各ワーカの動的情報を指定する一覧表の例を示す図である。 サービス毎のワーカのリストを記述したファイル名の表示例を示す図である。 ワーカリストファイルの内容を示した例を示す図である。 基準となるパラメータとそのパラメータでのサービス実行時間の実測値の記録及びその時に使用したワーカの性能値の記録を示す図である。 各ワーカでのサービスの実行予測時間を算出し、分割したジョブを実行させるワーカ割り当ての決定処理の流れを示すフローチャート図である。 各ワーカにおける各ジョブの予測実行時間の一覧表の例である。 最短の実行時間でリクエストを完了するようにジョブの割り当てを行った場合のタイムチャート図である。 各ワーカにおける各ジョブの予測実行時間の一覧表の例である。 指定された制限時間に間に合うようにジョブの割当てを行った場合のタイムチャート図である。 制限時間内でリクエストを終了できるようにジョブとワーカの組合せを決定する処理の流れを示すフローチャート図である。 ワーカにジョブを割り当てる手順を示すフローチャート図である。 サービス成功確率を併記した見積画面の表示例を示す図である。 時間ごとのジョブ平均発行回数の頻度表の例である。 リクエストが制限時間内で終わる確率を求める手順を表すフローチャート図である。 サービス成功確率を求める際に用いる正規分布を示す図である。 優先度設定機能を追加した見積結果表示画面である。 複数の利用者が同一の優先度の設定を行った場合の処理の流れを示すフローチャート図である。 利用者情報の一例を示す図である。

符号の説明

１０１…グリッド、１０２…中間サーバ、１０３〜１０６…計算機、
３０１…リクエスト受付部、３０２１…アカウント管理手段、３０２２…リクエスト管理部、３０２３…サービス結果出力手段、３０２４…ジョブ実行時間予測手段、３０２５…ジョブスケジューリング管理手段、３０２６…計算リソース情報管理手段、３０３…グリッドインターフェイス。

Claims (14)

1. 複数の計算機をネットワークにより接続したグリッドを含む異種混合計算機接続システムにおいて、
   利用者からのリクエストを実行するプログラム上の処理を複数のジョブに分割するリクエスト管理手段と、
   前記グリッド上のそれぞれの前記計算機の静的性能と、動的に変化する計算機の負荷状態又はネットワークのトラフィック状況を含む動的性能と、を含む計算リソース情報を管理する計算リソース情報管理手段と、
   前記計算リソース情報と前記リクエストの内容とに基づいて、分割された前記それぞれのジョブを複数の前記計算機に動的に割り当てる管理を行うジョブスケジューリング管理手段と
   を備えたことを特徴とする異種混合計算機接続システム。
2. さらに、分割した前記ジョブと割り当てられた前記計算機とに関する処理の実行結果の履歴データを格納する実行履歴データベースと、
   該実行履歴データベースに格納された前記履歴データを更新する処理を行うデータ更新部と、
   最新の前記履歴データと前記ジョブスケジューリング管理手段により割り当てられたジョブと計算機との組合せとに基づいて、ジョブの実行時間を予測するジョブ実行時間予測手段と
   を有することを特徴とする請求項１に記載の異種混合計算機接続システム。
3. さらに、前記ジョブの優先度を設定する優先度設定手段を有することを特徴とする請求項１又は２に記載の異種混合計算機接続システム。
4. さらに、選択された計算機の組合せとそれぞれの計算機上で使用するリソース量と使用時間とに基づいて、前記リクエストに応じたサービスに対する課金金額を求める課金算出部を有することを特徴とする請求項１から３までのいずれか１項に記載の異種混合計算機接続システム。
5. 請求項１から４までのいずれか１項に記載の異種混合計算機接続システムにおいて、
   さらに、前記リクエストに応じたサービスの実行終了までに要する時間と課金金額との組合せを提示する手段を有することを特徴とする異種混合計算機接続システム。
6. 請求項５に記載の異種混合計算機接続システムにおいて、
   さらに、前記課金金額が前記利用者により指定された上限値以下になるように、ジョブを割り当てる計算機の組合せを動的に選択する手段を備えることを特徴とする異種混合計算機接続システム。
7. 請求項５又は６に記載の異種混合計算機接続システムにおいて、さらに、利用者が指定した期限までにサービスを完了できる確率を利用者に提示する手段を有することを特徴とする異種混合計算機接続システム。
8. 請求項７に記載の異種混合計算機接続システムにおいて、
   さらに、利用者が指定した実行期間と、予め提示された時間内でのサービス完了確率と、実際の実行期間とに基づいて、課金金額を変更する手段を有することを特徴とする異種混合計算機接続システム。
9. 請求項８に記載の異種混合計算機接続システムにおいて、
   さらに、複数の利用者が利用する計算リソースが競合した場合に課す追加料金の代わりに、その利用者のジョブの実行優先度を上げることを特徴とする異種混合計算機接続システム。
10. 請求項９に記載の異種混合計算機接続システムにおいて、
    さらに、複数の利用者から同時に追加料金に関する指定がなされた場合に備えて、予め優先度を記憶する手段を備えることを特徴とする異種混合計算機接続システム。
11. 複数の計算機をネットワークにより接続したグリッドを含む異種混合計算機接続システムにおいて、
    前記グリッド上のそれぞれの前記計算機の静的性能と動的に変化する計算機の負荷状態又はネットワークのトラフィック状況を含む動的性能とを含む計算リソース情報を取得するステップと、
    利用者からのリクエストを実行するプログラム上の処理を複数のジョブに分割するステップと、
    前記グリッド上のそれぞれの前記計算機の静的性能と動的に変化する計算機の負荷状態又はネットワークのトラフィック状況を含む動的性能とを含む計算リソース情報を監視するステップと、
    前記計算リソース情報と前記リクエストの内容とに基づいて、分割された前記それぞれのジョブを複数の前記計算機に動的に割り当てるための管理を行うジョブスケジューリングを管理するステップと
    を備えたことを特徴とする異種混合計算機接続システム管理方法。
12. 前記ジョブスケジューリングを管理するステップは、分割されたそれぞれのジョブをそれぞれの前記計算機により実行させた場合の処理時間を求めるステップと、時間を要するジョブに対してより処理時間の短い計算機を割り当てていくステップと、を有することを特徴とする請求項１１に記載の異種混合計算機接続システム管理方法。
13. ジョブの計算機への割当てステップは、実行要求時間の範囲内において、可能な限り同じ計算機にジョブを割り当てていくステップを有することを特徴とする請求項１１に記載の異種混合計算機接続システム管理方法。
14. さらに、利用可能な計算機数と、それぞれの計算機に関するジョブの実行履歴と、処理完了までの最短処理時間と指定された上限処理時間との差と、に基づいて時間範囲内に処理の成功する確率を求めるステップを有することを特徴とする請求項１１に記載の異種混合計算機接続システム管理方法。

Images