JP2014501010A - サーバ側の処理能力を拡張するための方法及び装置 - Google Patents

Abstract

【課題】サーバ側の処理能力を拡張するための方法及び装置を提供すること。
【解決手段】サーバ側の処理能力を拡張するための方法は、（ａ）前記サーバ側からオフロードすべき一のジョブを決定するステップと、（ｂ）前記ジョブを１つ以上のタスクに分割するステップと、（ｃ）１つ以上のクライアントから送信されたＨＴＴＰ要求に応答して、前記１つ以上のタスクを前記１つ以上のクライアントに割り振るステップと、（ｄ）前記１つ以上のクライアントから送信された前記ＨＴＴＰ要求から、前記１つ以上のタスクに対する前記１つ以上のクライアントの応答を受信するステップを有する。
【選択図】 図４

Description

本発明は、データ処理に係り、さらに詳細に説明すれば、サーバ側の処理能力を拡張するための方法及び装置に係る。

ネットワーク技術及び分散コンピューティング技術のサポートにより、複数のサーバを有するデータ・センタを設置することが可能となり、そして超大規模のデータ処理能力を必要とするアプリケーションが、複数のサーバ間の共同作業を通して実行されるようになってきた。しかし、幾つかの計算については、サーバ側の処理能力だけに依存して、計算動作を完了することができない。そのため、サーバ側の処理能力を拡張するための新しい解決方法を開発することが必要である。

何百万及び何千万ものユーザを有する大きなウェブサイトでは、大量のユーザが照会を同時に行うか又は当該ウェブサイト内のあるデータについて索引を作成する場合、超大規模のデータ処理能力が常に必要となる。一例として、ショッピング・ウェブサイトを使用して、サーバ側の処理能力を拡張することができる解決方法を概説する。ショッピング・ウェブサイトのサーバ側に関する限り、複数のサーバをウェブ・アプリケーション・サーバ及び分析サーバの２つのタイプに分割することができる。これらの両タイプのサーバは、同一の物理ホスト資源を共有する。一般に、ウェブ・アプリケーション・サーバは、フロントエンドのウェブ・サービスをサポートするために必要なアプリケーションを稼働させるために使用される。これに対し、分析サーバは、他の関係する分析機能を提供するために使用される。

図１は、第１の解決方法１１０に従った、サーバ側１１３における構成のアーキテクチャ全体図を示す。第１の解決方法１１０では、ユーザ１１４の数が比較的少ない場合、比較的少数のサーバをウェブ・サーバ１１１として割り振り、それ以上のサーバを分析サーバ１１２として使用することができる。しかし、ユーザの数が増大すると、ウェブ・サーバ側１１３が負担する負荷が増加し、指数関数的に増加することさえある。このため、増大傾向にあるデマンドに適合するためのより多くのデータ処理能力を提供するように、より多くのハードウェア・サーバをウェブ・サーバ１１１として購入しなければならない。

図２は、ハードウェア投資を増やさずにサーバ側の処理能力を拡張するための、第２の解決方法１２０のアーキテクチャ全体図を示す。第２の解決方法１２０は、サーバ側１２３におけるそれぞれのサーバ間で機能性を再分割するというものである。例えば、第２の解決方法１２０によれば、比較的多数のサーバをウェブ・サーバ１２１として割り当て、比較的少数のサーバを分析サーバ１２２として割り当てることができる。

前記第１及び第２の解決方法は、ウェブ・サーバ１２１の資源不足の問題をある程度まで解決することができるであろうが、分析サーバ１２２の数を減少させると、種々の問題（例えば、分析能力の低下及び過度に長いフィードバック時間）を引き起こすことになろう。このため、切迫した問題は、分析サーバのハードウェア投資を増やさずにサーバ側の処理能力を拡張するためには、他の使用可能な資源をどのように行使すればよいかということである。

従って、至急に要請されているのは、ハードウェア投資を増やさずにサーバ側の処理能力を拡張するための便利で且つ確実な方法を提供することである。さらに要請されているのは、既存のハードウェア及びソフトウェア構成への変更を最小限に留めるとともに、サーバ側の処理能力を展開が容易な態様で拡張することである。

本発明の第１の側面に従って、サーバ側の処理能力を拡張するための方法が提供される。この方法は、（ａ）前記サーバ側からオフロードすべき一のジョブを決定するステップと、（ｂ）前記ジョブを１つ以上のタスクに分割するステップと、（ｃ）１つ以上のクライアントから送信されたＨＴＴＰ要求に応答して、前記１つ以上のタスクを前記１つ以上のクライアントに割り振るステップと、（ｄ）前記１つ以上のクライアントから送信された前記ＨＴＴＰ要求から、前記１つ以上のタスクに対する前記１つ以上のクライアントの応答を受信するステップを有する。

前記方法は、前記１つ以上のタスクを実行するための前記１つ以上のクライアントを選択するステップをさらに有する。

前記方法の前記ステップ（ａ）は、前記サーバ側の現在の負荷レベルを決定するステップと、前記現在の負荷レベルが一のしきい値負荷レベルを超えそうか又は既に当該しきい値負荷レベルを超えていると決定することに応答して、前記サーバ側からオフロードすべき一のジョブを指定するステップを含む。

前記方法の前記ステップ（ｃ）は、前記１つ以上のクライアントの属性に基づき、前記１つ以上のクライアントをグループ化するステップと、１つ以上のグループと適合する１つ以上のタスクを、グループ単位で、前記１つ以上のクライアントに割り振るステップを含む。

本発明の第２の側面に従って、サーバ側の処理能力を拡張するための装置が提供される。この装置は、前記サーバ側からオフロードすべき一のジョブを決定するように構成された決定手段と、前記ジョブを１つ以上のタスクに分割するように構成された分割手段と、１つ以上のクライアントから送信されたＨＴＴＰ要求に応答して、前記１つ以上のタスクを前記１つ以上のクライアントに割り振るように構成された割り振り手段と、前記１つ以上のクライアントから送信された前記ＨＴＴＰ要求から、前記１つ以上のタスクに対する前記１つ以上のクライアントの応答を受信するように構成された受信手段を備える。

前記装置は、前記１つ以上のタスクを実行するための前記１つ以上のクライアントを選択するように構成された選択手段をさらに備える。

前記装置の前記決定手段は、前記サーバ側の現在の負荷レベルを決定するように構成された決定手段と、前記現在の負荷レベルが一のしきい値負荷レベルを超えそうか又は既に当該しきい値負荷レベルを超えていると決定することに応答して、前記サーバ側からオフロードすべき一のジョブを指定するように構成された指定手段を有する。

前記装置の前記割り振り手段は、前記１つ以上のクライアントの属性に基づき、前記１つ以上のクライアントをグループ化するように構成されたグループ化手段と、１つ以上のグループと適合する１つ以上のタスクを、グループ単位で、前記１つ以上のクライアントに割り当てるように構成された割り当て手段を有する。

本発明は、ハードウェア投資を増やさずにサーバ側の処理能力を便利で且つ確実に拡張するとともに、サーバ側の処理能力を展開が容易な態様で拡張することができるという効果を奏する。

第１の解決方法に従った、サーバ側の構成のアーキテクチャ全体図である。 サーバ側の処理能力を拡張するための、第２の解決方法のアーキテクチャ全体図である。 本発明に従った、サーバ側の処理能力を拡張するためのアーキテクチャ全体図である。 本発明に従った、サーバ側の処理能力を拡張するための方法を示すフローチャートである。 本発明に従った、サーバ側の諸タスクを諸クライアントに割り振るための方法を示すフローチャートである。 本発明に従った、サーバ側の負荷検査フローを示すフローチャートである。 本発明に従った、サーバ側のイベント処理フローを示すフローチャートである。 図７のイベント処理フローのうち新しいクライアントのログオン用の処理フローを示すフローチャートである。 図７のイベント処理フローのうちタスク結果を戻す処理フローを示すフローチャートである。 図７のイベント処理フローのうち一のジョブをオフロードすることを要求する処理フローを示すフローチャートである。 図７のイベント処理フローのうちタスク処理の処理フローを示すフローチャートである。 本発明に従った、サーバ側の処理能力を拡張するための装置を示すブロック図である。

フローチャート及びブロック図内のブロックは、本発明に従った方法及び装置によって実行可能な機能及び動作を示す。この点に関連して、フローチャート又はブロック図内の各ブロックは、指定された論理機能を実行するための１つ以上の動作可能命令を保持する、モジュール、プログラム・セグメント又はコード部分を表すことがある。幾つかの代替的実装では、諸ブロック内に表記された機能を図面に示した順序とは異なる順序で実行することができる。例えば、特定の機能性に依存して、連続的に示した２つのブロックを実質的に並列に実行したり、これらのブロックを反対の順序で実行することができる。ブロック図及び／又はフローチャートの各ブロック及び諸ブロックの組み合わせは、指定された機能又は行為を実行する専用のハードウェア・ベースのシステム又は専用ハードウェア及びコンピュータ命令の組み合わせによって実装することができる。

以下、本発明に従った方法の処理フローを、ショッピング・ウェブサイトを使用する一例のみに沿って詳述することにする。しかし、本発明によれば、種々の方法、装置及びコンピュータ・プログラムの実装は、ショッピング・ウェブサイトによって表されるウェブ・ベースのアプリケーションに制限されない点に留意されたい。かかる実装は、他の種々のアプリケーションにおいても行うことができるからである。

一のクライアントは、種々の態様でサーバ側にアクセスすることができる。説明の便宜上、本明細書では、サーバ側によって提供されるウェブ・ページにアクセスするという態様におけるサーバ側への接続だけを説明する。しかし、クライアント側のコンピュータ装置は、他のアプリケーションを通してネットワークを介してサーバ側にアクセスすることができる。例えば、サーバ側は、特定のアプリケーションを通して、又はプラグ・インをインストールすることにより、アクセスすることができる。

本明細書では、クライアントの特定の例として通常のコンピュータ端末を想定し、そして通常のコンピュータ端末がサーバ側によって提供されるウェブ・ページにアクセスするという特定の例を想定するが、クライアントは、データ処理能力を有する種々のコンピュータ端末（例えば、デスクトップ・コンピュータ、ラップトップ・コンピュータ、パネル・コンピュータ、ワークステーション等）のうち何れかとすることもできる。また、コンピュータ装置の小型化の動向及び処理能力の拡張を考慮すると、クライアントは、ポータブル式のモバイル・コンピュータ装置（例えば、携帯情報端末、インテリジェント電話機及びモバイル端末）とすることもできる。

本発明の実施形態では、ショッピング・ウェブサイト内の分析サーバを想定するが、本発明の実施形態は、この例に制限されるものではなく、その上で稼働中の一のジョブを複数のコンピュータ端末上で実行される複数のタスクに分割することができる、任意のサーバを備えることができる。本明細書で説明するジョブの分割化については、種々の要因（例えば、当該ジョブの緊急度、そのリアルタイム性質、機密性等）を考慮する必要があり、そしてサーバ側に接続されたクライアント上で全てのジョブを実行することが適切であるとは限らない点に留意されたい。本発明の方法を使用することによって、サーバ側に接続された複数のクライアントは、元々サーバ側で実行されると計画されていたタスクを共有することができ、このため、サーバ側の負荷が緩和されることになる。

本発明の一の利点は、一のクライアントに透明な態様でサーバ側の処理能力を拡張するという点にある。例えば、当該クライアントにとっては、割り振られたタスクを受信し且つ処理結果を戻すための専用アプリケーションをインストールすることが不要となる。これに対し、サーバ側は、当該クライアントから送信されたＨＴＴＰ要求に応答して、一のタスクを当該クライアントに割り振ることができ、このため、サーバにとっては、当該クライアントから送信された前記要求から当該タスクに対する一の応答を受信することだけが必要となる。その上、当該クライアントにとっては、前記タスクを実行するための専用アプリケーションをインストールすることが不要となり、前記割り振られたタスクは、タスク記述式に実装することができる。すなわち、当該クライアントは、タスク記述のみに基づき、前記割り振られたタスクを実装することができる。

図３は、本発明に従った、サーバ側２３０の処理能力を拡張するためのアーキテクチャ全体図２００を示す。サーバ側２３０の資源（例えば、分析サーバ２２０）が不足している場合、サーバ側２３０の全体的なデータ処理能力を改良するために、分析サーバ２２０に接続されたクライアントの処理能力を共同的（collaboratively）に利用することができる。

図１及び図２に示した解決方法とは異なり、図３のアーキテクチャでは、一のユーザ２４０が使用するクライアントと分析サーバ２２０との間の対話は、当該クライアントがデータを要求し且つ分析サーバ２２０からデータを受信するという通常の動作に制限されない。すなわち、当該クライアントは、分析サーバ２２０によって割り振られたタスク及びそれに関係する処理すべきデータを受信し、タスク記述に基づいて当該処理すべきデータを処理した後、その処理結果を分析サーバ２２０に戻すように動作する。このため、サーバ側２３０は、それ自体のジョブを適切なサイズの諸タスクに分割することを通して、これらのタスク及びそれに関係する処理すべきデータを資格のある諸クライアントに割り振り、そしてこれらのクライアントから処理結果を受信する。その結果、ユーザ２４０の諸クライアントは、元々分析サーバ２２０自体によって実行されると計画されていたジョブの一部を共有することになる。

以下、図４〜図１２を参照して、本発明に従った方法及び装置の処理フローを説明する。図４は、サーバ側の処理能力を拡張するための方法を示すフローチャート３００である。この方法のステップＳ３０２では、サーバ側からオフロードすべき一のジョブを決定する。ここで、「オフロード」動作とは、一般に、元々サーバ側のコンピュータ装置によって実行すべきであった一のジョブを、実行のために他のコンピュータ装置に対し再割り当てするプロセスを意味するものとする。かかるオフロードされたジョブは、サーバ側に割り振られたばかりでまだ実行されていない新しいジョブであるか、又は実行中であるがサーバ側が過度に重い負荷が有するために、他のコンピュータ装置が共有しなければならないジョブとすることができる。オフロードすべき一のジョブを決定する場合には、種々の要因（例えば、サーバ側の現在の負荷、サーバ側の処理能力、当該ジョブの機密性、当該ジョブの応答時間等）を考慮することができる。例えば、高い機密性を有し且つ最大のリアルタイム応答を必要とする一のジョブをサーバ側で優先的に実行するように考慮し、低い機密性及び応答時間に関する低い要件を有する一のジョブをクライアントが実行するためにオフロードするように選択することができる。

ステップＳ３０４では、ステップＳ３０２で決定されたジョブを、１つ以上のタスクに分割する。サーバ側は、所定の規則に基づいて当該ジョブを分割することができる。例えば、分割中に、諸タスクの粒度を決定し、これらのタスクに対応する処理すべきデータを決定することができる。諸クライアントの計算能力及び諸クライアントとサーバ側との間のネットワーク接続状態のような諸要因に基づき、諸クライアントに割り振られる諸タスクは、一般により細かな粒度を有し、そしてサーバ側が少なくとも１つのクライアントからの応答を受信することを保証するように、冗長機構（例えば、一の同じタスクを複数のクライアントに割り振ること）を採用することが必要とされる点に留意されたい。一のジョブを分割する場合、各タスクは異なる粒度を有し、各タスクに対応する処理すべきデータは異なるサイズを有することができる。

ステップＳ３０６では、１つ以上のクライアントから送信されたＨＴＴＰ要求に応答して、１つ以上のタスクを当該１つ以上のクライアントに割り振る。異なる割り当てポリシーをセットすることができる点に留意されたい。例えば、１つのクライアントが１つのタスクだけを同時に実行することができ、当該タスクが完了し且つタスク実行結果をサーバ側にサブミットした後にだけ、次のタスクを取得することができるように制限することが可能であり、或いは１つのクライアントが同じジョブからの複数のタスクを同時に実行することができるか、又は一のクライアントが異なるジョブからの複数のタスクを実行することができるように制限することが可能である。タスク割り振りは、クライアントから送信されたＨＴＴＰ要求に応答して実行される。例えば、サーバ側が一のクライアントのログオンを検出する場合、サーバ側は、タスク割り振り動作を行うことができる。当該クライアントがログオンの後にサーバ側への接続を維持する限り、諸タスクを当該クライアントに割り振ることができる。当該クライアントが一のタスクを完了した後、サーバ側は、それ自体のポリシーに基づき、他の１つ以上のタスクを当該クライアントに割り振るか、又は当該クライアントにタスクをもはや割り振らないであろう。当該クライアントがサーバ側とのその接続を切断する（例えば、ウェブ・ページを閉じる）場合、サーバ側は、当該クライアントにタスクをもはや割り振らないであろう。さらに、当該クライアントは、異なるデータ・センタ内の諸サーバから複数のタスクを受信することができる。

次に、ステップＳ３０８では、１つ以上のクライアントから送信された１つ以上のＨＴＴＰ要求から、１つ以上のタスクに対する当該１つ以上のクライアントの応答を受信する。本発明に従って、当該クライアントが応答を有さないという例外状況を処理することがさらに含まれる。ステップＳ３０６及びＳ３０８では、タスク割り振り及び当該タスクに対する一のクライアントの応答の受信は、諸クライアントの既存の構成を変更することなく、何れもＨＴＴＰ要求の態様で実装される。

本発明に従って、サーバ側（例えば、データ・センタ）において、１つ以上のタスクを実行するための１つ以上のクライアントを選択するステップがさらに含まれる。何百万ものクライアントがサーバ側に接続されている状況が存在し得るから、この選択ステップの目的は、このタスクをより適時に且つ正確に完了するように、使用可能な諸クライアントから当該タスクを実行するのに適切なクライアントを選択することである。諸クライアントの属性は、諸タスクを実行するのに適切なクライアントを選択するための、フィルタ基準として使用することができる。本発明では、より高度のハードウェア構成、より軽い負荷及びより良いネットワーク接続条件を有する諸クライアントを選択することができる。或いは、選択をランダムに行うか、又は現在サーバ側にアクセス中の全てのクライアントを使用することができる。

サーバ側からオフロードすべき一のジョブを決定するステップＳ３０２は、サーバ側の現在の負荷レベルを決定することと、当該現在の負荷レベルが一のしきい値負荷レベルを超えそうか又は既に当該しきい値負荷レベルを超えていると決定することに応答して、サーバ側からオフロードすべき一のジョブを指定することを含む。

オフロードすることが必要な一のジョブを決定する場合、サーバ側は、先ずそれ自体の現在の負荷を検査することができる。もし、サーバ側の現在の負荷が比較的小さければ、新しいジョブをサーバ側で完全に実行することができる。一方、サーバ側の現在の負荷が全負荷に接近していれば、当該ジョブの一部を実行のためにサーバ側のホストに割り当て且つ残りの一部を諸クライアントに割り当てるか、又は当該ジョブの全体を実行のために諸クライアントに割り振ることができる。さらに、ジョブ実行プロセス中に、現在の負荷レベルがしきい値負荷レベルに接近するか又は既に超過したことをサーバ側が検出する場合、サーバ側で実行中のジョブをサーバ側から除去し、これをさらに１つ以上のタスクに分割した後、当該１つ以上のタスクを実行するように１つ以上のクライアントを割り当てることができる。

次に、図５を参照して、サーバ側の諸タスクを諸クライアントに割り振るための方法のフローチャート４００を説明する。ステップＳ４０２では、１つ以上のクライアントを、それらの属性に基づいてグループ化する。このグループ化は、サーバ側に接続された諸クライアントの共通の性質を考慮することができる。すなわち、同一の属性を有する諸クライアントは、対応する一のグループにグループ化され、また諸タスクを割り振る場合、諸クライアントによって実行するのにより適切な諸タスクを選択することができる。

諸クライアントの諸属性は、諸クライアントの処理能力、諸クライアントの現在の負荷、諸クライアントの応答時間、諸クライアントの信頼度（confidence degree）、諸クライアントからサーバ側までの経路指定条件、諸クライアントのタスク完了履歴及び諸クライアントとサーバ側との間の契約のうちの１つ以上を含むことができる。

本発明の着想は、諸クライアントの処理能力を共同的に利用することである。この共同的態様は、ユーザに対し透明なものとすることができる。すなわち、ユーザからの多くの手動的関与を必要としないか、又は諸クライアントのアプリケーションを変更することを必要としない。例えば、サーバ側と諸クライアントとの間で処理能力共有契約を締結して、サーバ側は、一のタスクを諸クライアントに割り振ることを約束し、諸クライアントは、当該タスクを実行し且つその処理結果をサーバ側に戻すことを約束することができる。かかる契約に合意した後、諸クライアントは、サーバ側から割り振られたタスクを受信し、その後の動作を行うことができる。異なるビジネス運用モデルに従って、諸クライアントの処理能力を共同的に共有することを他の態様で実装することができるが、そのような運用プロセスに関係するビジネス・モデル及び法的問題については、ここでは触れないことにする。

グループ単位で、当該グループと適合する１つ以上のタスクを、１つ以上のクライアントに割り当てることができる。例えば、より強力な処理能力を有する諸クライアントを１つのグループにセットして、より高度の処理能力を必要とする諸タスクを当該グループ内の諸クライアントに割り振ることができる。例えば、それらのクライアントには、高度の計算力及び重い計算負荷を有する一のタスクを割り振るか、又はより大きなサイズを有する処理すべきデータ・ブロックを割り振ることができる。他の例について説明すると、過去の経験から幾つかのクライアントの応答時間が非常に短いことが分かっている場合、これらのクライアントを１つのグループに分類し、応答時間についてより高いデマンドを有する一のタスクをこのグループに割り振ることができる。さらに他の例について説明すると、幾つかのクライアントのジョブ完了の履歴から、以前のタスクのそれらの完了レートが非常に高いことが分かっている場合、これらのクライアントを１つのグループに分類し、諸タスクをこのグループに優先的に割り振ることができる。諸クライアントは、サーバ側と諸クライアントとの間の異なるサービス契約に基づき、異なるグループに分割することができる。例えば、諸クライアントが夜間（例えば、００：００〜０６：００）におけるそれら自体の計算能力を提供することに合意し、そして当該クライアントがこの期間中にサーバ側に接続されるということを保証する場合、サーバ側は、同様の状況を有する諸クライアントを同じグループに分割するとともに、夜間においてこのグループ内のクライアントに対し諸タスクを連続的に割り振ることができる。

１つ以上のタスクを１つ以上のクライアントに割り振るステップＳ３０６（図４）は、１つ以上のクライアントがサーバ側にログオンすることに応答して、当該１つ以上のタスクに対応するタスク記述及び処理すべきデータを当該１つ以上のクライアントに送信することを含む。諸タスクを諸クライアントに割り振ることは、当該クライアントがサーバ側に接続されていることを条件とする点に留意されたい。例えば、一のクライアントがサーバ側の一のページにアクセスしている場合、一のタスクを当該クライアントに割り振ることができ、そして当該クライアントがサーバ側への接続を維持している期間中、サーバ側は、当該クライアントの処理能力を活用することができる。但し、当該クライアントが当該ページを離れた後は、当該クライアントの処理能力を活用することはできない。クライアントは、ウェブ・ベースの態様でサーバ側にアクセスすることができる点に留意されたい。このウェブ態様には、広い意味を与えるべきである。この態様は、サーバ側にアクセスすることにより提供されるウェブ・ページを含むだけでなく、既に存在しているか又は将来に開発されるであろう種々の種類のウェブ・ベースのアクセス態様を含む。サービス契約に従って、一のタスクは、諸クライアントがサーバ側にログオンする期間中に、当該クライアントに割り振ることができる。

本発明の一の利点は、新しいアプリケーションをクライアント上に追加的にインストールすることなく、諸クライアントの計算能力を活用することができるという点にある。というのは、当該タスクを割り振る間に、当該タスクに対応する一のタスク記述及び処理すべきデータを諸クライアントに送信することができるからである。従って、諸クライアントは、受信したタスク記述を使用して、処理すべきデータを処理することができる。このタスク記述は、入力データ記述、出力データ記述及び処理アルゴリズム又はその記述のうちの１つ以上を含むことができる。

例えば、ショッピング・ウェブサイトの一のログがトランザクションのより小さな各要素（例えば、特定の時間に販売された商品の数、当該商品の単価）の諸レコードだけを記録するというシナリオにおいて、一のジョブが最大の単一トランザクションの量及び対応する商品の名称を計算することを意図するものであると仮定すると、このジョブは、次のように分割することができる。

前記ログが諸トランザクション・レコードの１０,０００個の要素（piece）を記録したものと仮定すると、例えば、これらのレコードを、１,０００個のデータ・セグメントに分割し、そして一のデータ・セグメントにおける最大の単一トランザクションの量を計算するタスクを、各クライアントに割り振る（一のクライアント・グループをセットした場合には、当該タスクは当該クライアント・グループにも割り振ることができる）。この場合、一のタスク記述及び対応する処理すべきデータを、諸クライアント（又は諸クライアント・グループ）に送信する。当該クライアント・グループを考慮することなく、サーバ側は、当該タスクを１,０００個のクライアントに送信することができる。一方、処理すべきデータの各要素は、諸トランザクション・レコードの１０個の要素を含む、一のデータ・セグメントとすることができる。クライアントの信頼度及びネットワーク条件のような要因を考慮して、信頼度を拡張することができる他の割り振り態様も採用することができる。その特定の例については、以下で詳述する。

本発明に従って、タスク記述は、次の通りとすることができる。
｛入力データ：諸トランザクション・レコードの１０個の要素を含む。
但し、諸データ・レコードの各要素は、
商品名：ａ；販売された商品の量：ｂ；及び商品の単価：ｃ；を含む。
出力データ：最大の単一トランザクションの量，商品名；
アルゴリズム：最大の単一トランザクションの量＝ｂ×ｃ，商品名＝ａ｝

前記タスク記述を受信した各クライアントは、諸トランザクション・レコードの１０個の要素について処理結果を計算するために、前記アルゴリズムを採用することができる。このアルゴリズムは、スクリプト技術（例えば、ＡＪＡＸ技術）で、又は諸クライアントによって直接的に又は間接的に実行することができる他のプログラムで記述することができる。サーバ側が１,０００個のクライアントから戻された処理結果、例えば、２タプル（最大の単一トランザクションの量、商品名）を受信する場合、諸レコード・ログの１０,０００個の要素内のデータを１つずつ比較することなく、１,０００個の２タプルから「最大の単一トランザクションの量」を有する一の２タプルを選択することだけが必要となるに過ぎない。

一のジョブを１つ以上のタスクに分割するステップＳ３０２（図４）は、所定の規則に基づいて行われる。この規則は、当該タスクの粒度、当該ジョブの計算負荷、当該ジョブの優先順位、当該ジョブの機密性等のうちの少なくとも１つに関係する。例えば、当該ジョブの計算負荷が重い場合、当該ジョブを比較的軽い計算負荷を有するより多くのタスクに分割することができる。その結果、諸クライアントは、各タスクを比較的短い時間内に完了し、その処理結果をサーバ側にできるだけ早く戻すことができる。例えば、最高優先順位を有する一のジョブを優先的に処理することを考慮する場合、その分割後に、対応する諸タスクは、高い処理能力及び早い応答時間を有し且つより高い信頼度を有する諸クライアントに割り振られる。例えば、一のジョブの機密性に基づき、より高い機密性を有する当該ジョブをより少数のタスクに分割し、これらのタスクを実行のためにより高い信頼度を有する諸クライアントに割り振るようにすれば、当該タスク割り振り及び結果回復プロセス中に不法に侵入されるというリスクを減少させることができる。

諸タスクの粒度は、以前のタスク実行におけるクライアントの経験に基づき、動的にセットすることができる。例えば、以前のタスク実行プロセス中に、過度に粗いタスクの粒度に起因して、多数のクライアントが所定の応答時間内に処理結果を得ることができない場合は、その後、より細かいタスクの粒度をセットすることができ、逆も同様である。タスクの粒度をセットする場合、諸クライアントの属性をさらに考慮することができる。一のジョブについては、その分割中に、複数のタスクの粒度をセットすることができる。すなわち、そのジョブを、異なるサイズを有する複数のタスクに分割し、対応するタスクを異なるクライアント及び／又はクライアント・グループに割り振ることができる。

本発明に従って、１つ以上のタスクに対する１つ以上のクライアントの応答に基づき、一のジョブの少なくとも一部の処理結果を生成するステップがさらに含まれる。ここで、当該生成するプロセスは、処理結果を取得するために複数のクライアントからの諸応答を集約することを意味する。例えば、最大の単一トランザクションの量及びショッピング・ウェブサイトの対応する商品名の計算中に、サーバ側は、１,０００個のクライアントからの処理結果、例えば、１,０００個の２タプル（最大の単一トランザクションの量、商品名）を受信した後、「最大の単一トランザクションの量」を有する一の２タプルを選択する。

さらに、サーバ側から一のジョブの一部のみをオフロードする場合（例えば、サーバ側が、諸ログ・レコードの５,０００個の要素における「最大の単一トランザクションの量」を計算しているのに対し、諸クライアントが諸ログ・レコードの他の５,０００個の要素を処理している場合）、タスク分割の態様が変わらなければ、サーバ側は、５００個のクライアントからの応答（すなわち、５００個の２タプル）に基づき、当該ジョブの少なくとも一部（すなわち、諸ログ・レコードの５,０００個の要素）の処理結果のみを生成することを必要とするに過ぎない。

一のジョブの少なくとも一部の処理結果を生成するステップは、１つ以上のクライアントからの応答の信頼度を取得するステップと、当該信頼度に基づき、当該ジョブの少なくとも一部の処理結果を提供するステップをさらに含む。最終結果の信頼度を保証する方法に関する原理は、以上で簡潔に説明した。以下、特定の動作フローを詳述する。

本発明の着想は、諸クライアントがインターネットを介してサーバ側に常時接続されている間に、諸クライアントの処理能力を共同的に利用することにあるから、サーバ側から割り振られた諸タスクを受信する諸クライアントは、絶えず変わることがある。その結果、当該ジョブの最終処理結果の信頼度は、それぞれのクライアントからの諸処理結果の信頼度を保証することによってのみ保証することができる。

諸クライアントからの諸応答の信頼度は、整合性（consistency）を決定する態様で推定することができる。例えば、一のタスク及びその対応する処理すべきデータは、少なくとも１つのクライアントが処理結果を戻すことを保証するように、複数のクライアントに送信することができる。一の同じタスク及びこれに対応する処理すべきデータに対する複数のクライアントからの処理結果を（例えば、これらの処理結果の整合性を分析することによって）包括的に比較し、前記複数の処理結果と整合する一の処理結果を選択することができる。一のタスクを、一のクライアント・グループに割り振ることができる。一の同じタスクを複数のクライアント・グループに割り振る場合は、複数のグループからの処理結果の整合性を比較し、比較的高い整合性を有する一の処理結果を選択する。本発明に従って、複数の処理結果を「平均する」ための方法を採用することもできる。ここで、「平均する」は、単純な数学的平均値解法を意味するのではなく、複数のクライアントからの諸処理結果に基づき、最も信頼度の高い結果を取得するプロセスを意味する。

他の例について説明する。諸クライアントからの諸応答を使用することにより、一のジョブの少なくとも一部の処理結果を生成する場合、最終処理結果が履歴上の経験的な値、既存の標準及び常識の何れかと一致しなければ、諸クライアントからのこれらの応答を廃棄することができる。サーバ側自体の処理能力に基づき、又はより信頼度の高い諸クライアントを選択することにより、諸タスクの再割り振りが行われる。本発明に従って、一のタスクを諸クライアントに割り振るための全ての動作は、一のタスクをクライアント・グループに割り振るためにも適切である点に留意されたい。本発明に従って、一のジョブを異なる粒度に従って異なる複数セットのタスクに分割し、当該複数セットのタスクを処理のために異なるクライアント・グループに割り振り、そして当該グループからの処理結果を比較して信頼度を決定することができる。

以上では、図３〜図５を参照して、諸タスクをサーバ側の諸クライアントに割り振るための方法を説明した。以下では、図６〜図１１を参照して、サーバ側における処理を詳述する。

図６及び図７は、サーバ側の処理を示すフローチャートである。具体的には、図６は、サーバ側の負荷検査フロー５１０を示す。サーバ側が過度に重い負荷を有している場合は、ジョブの一部をサーバ側から「オフロード」して、これを諸クライアントによって実行することを保証するように、サーバ側の現在の負荷を所定の時間インターバル内に検査することが必要となる。図６のステップＳ５１２では、サーバ側の現在の負荷を検査し、ステップＳ５１４では、一の規則を照会する。ここでは、当該規則とは、サーバ側の処理能力用の負荷しきい値のような、サーバ側から一のジョブをオフロードするために必要とされる諸条件をセットする所定の規則であって、どのジョブを優先的にオフロードすることができるか、どのジョブがオフロードすることに適さないか等を指定するものである点に留意されたい。さらに、この規則は、サーバ側のジョブ完了状態に応じて動的に変わるか、又は管理者によって経験的にセットすることができる。

ステップＳ５１６では、サーバ側から一のジョブをオフロードすることが必要であるか否かを決定する。当該ジョブをオフロードすることが必要であれば、ステップＳ５１８に進み、そこで一のオフロード要求を送信する。当該ジョブをオフロードすることが不要であれば、ステップＳ５２０に進む。ステップＳ５２０は、次の検査用のインターバルを制御する。例えば、一のインターバル制御タイマをセットし、当該タイマが期限切れとなる場合、次のラウンドの負荷検査を行うためにステップＳ５１２を反復することができる。ステップＳ５１８の後は、ステップＳ５２０に進み、そこで次の検査を待機する。ステップＳ５１２〜Ｓ５２０は、反復的な実行プロセスである。サーバ側が稼働状態にある限り、このプロセスを実行することにより、サーバ側の現在の負荷に基づき、諸クライアントの処理能力を活用することが必要であるか否かを決定する。

次に、図７を参照して説明する。図７は、サーバ側のイベント処理フロー５３０を示す。図６の負荷検査プロセスのように、図７のイベント処理フロー５３０は、サーバ側の稼働期間中に反復的に実行される動作である。説明の便宜上、記号「Ａ」は、各ラウンドのイベント処理の出発点を表し、記号「Ｂ」は、各ラウンドのイベント処理の終了点を表すものとする。図７では、５ステップの全部が出発点「Ａ」から開始し、終了点「Ｂ」で終了するように示されているが、このことは、各ラウンド中にこれらの５ステップを厳密に並列に実行しなければならないことを意味しない。すなわち、これらの５ステップは、対応するイベントの発生に応答して異なる時間インターバル中に実行してもよく、またこれらの５ステップのうち２つ以上のステップを同時に実行してもよいからである。

図７に示すように、このプロセスの実行中、サーバ側は、次のイベントを処理しなければならない。
Ｓ５３２：新しいクライアントがログオン
Ｓ５３４：ジョブのオフロードを要求
Ｓ５３６：タスク処理
Ｓ５３８：タスク結果を戻す
Ｓ５４０：タイムアウト。
一ラウンドの処理に関する限り、ステップＳ５３４からステップＳ５３８の間は、ステップＳ５３４〜Ｓ５３８を順次に実行することができる。しかし、異なるラウンドについては、ステップＳ５３４〜Ｓ５３８の実行は、必ずしも順次的な関係を有しておらず、またこれらのステップを厳密に並行に実行する必要はない。例えば、ステップＳ５３４を実行している間、他のステップＳ５３６を実行してもよいし、他のタスクのためのステップＳ５３８を実行してもよい。

ステップＳ５４０は、サーバが一のタスクを諸クライアントに割り振ったが、所定の期間内に予期された戻り結果を受信することができないというシナリオのための処理である。サーバ側が一のタイムアウト・イベントの発生を検出する場合、その処理は、次のものを含むことができる。
１）タスク完了状態に関する統計を更新すること。タイムアウト状態にある諸タスクは完了しないから、当該タイムアウト・タスクを「未終了」とマークすること、すなわち、それぞれのタスクの完了状態を更新することが必要となる。
２）一のタスクをタスク・リストに追加すること。「未完了」タスクについては、これらのタスクを処理のために諸クライアントに再割り振りすることが必要である。この再割り振りは、以下で詳述するステップＳ５３６に類似する。
３）使用可能なグループをマークすること。タイムアウトの後は、一のタスクの実行がタイムアウトで終わるグループは、アイドル状態にある。従って、このグループは、他の割り振り済みタスクを実行するように、「使用可能」としてマークすることができる。

以下、図８〜図１１を参照して、他のイベントの処理フローを説明する。これらの図面における記号「Ａ」及び「Ｂ」は、図７に示すような各ラウンドのイベント処理の出発点及び終了点をそれぞれ表す。

図８は、図７に示すような新しいクライアント・ログオンの処理フローＳ５３２の詳細を示す。このラウンドの動作中、ステップＳ６１０で、新しいクライアント・ログオン・イベントの発生に応答して、当該クライアントに関する情報を取得する。この情報は、当該クライアントの属性（例えば、当該クライアントの処理能力、当該クライアントの現在の負荷、当該クライアントの応答時間、当該クライアントの信頼度、当該クライアントからサーバ側までの経路指定条件、当該クライアントのタスク完了履歴、当該クライアントとサーバ側との間の契約、又は当該クライアントに関連する他の情報）とすることができる。次に、ステップＳ６１２で、一の規則を照会する。ここの規則は、諸クライアントをグループ化するための規則である。例えば、特定のタイプの諸クライアントのための一のグループが既に存在しているというケースでは、この規則は、どんな属性を有するかということに基づいて諸クライアントをこのグループに追加することに関する規則とすることができる。

ステップＳ６１４では、当該クライアントを当該クライアント・グループに追加すべきか否かを決定する。当該クライアントを当該クライアント・グループに追加することが不要であれば、ステップＳ６２４に進み、そこで当該クライアントを無視する。新しいクライアント・ログオン・イベント処理のこのラウンドが終了し、そして動作フローは、他のイベントを待機するように継続する。ステップＳ６１４の決定結果が「Ｙｅｓ」であれば、ステップＳ６１６に進み、そこでグループ・リストを検査する。次に、ステップＳ６１８では、当該クライアントを一の新しいグループに追加すべきか否かを決定する。その決定結果が「Ｙｅｓ」であれば、ステップＳ６２６に進み、そこで一の新しいグループを作成する。さもなければ、ステップＳ６２０に進み、そこで当該クライアントを既存のクライアント・グループに追加する。次のステップＳ６２２では、当該クライアント・グループ・リストを更新し、その後、このラウンドのイベント処理が終了する。新しいグループを作成するステップＳ６２６及び当該クライアントを既存のクライアント・グループに追加するステップＳ６２０は、ステップＳ６１０及びステップＳ６１２で取得されたクライアント情報及び規則に基づいて行われる。

図９は、図７に示すような一のジョブをオフロードすることを要求する処理フローＳ５３４の詳細を示す。このラウンドの動作中、ステップＳ６３０で、一のジョブをオフロードすることを要求するイベントの発生に応答して、一の規則を照会する。この規則は、どのタイプのジョブをオフロードすることができるか、どのタイプのジョブをオフロードすることができないか、そしてオフロード可能な複数のジョブが同時に存在する場合の優先順位等を指定する。次のステップＳ６３２では、一のジョブの完了状態を検査し、ステップＳ６３４では、諸タスクの粒度を調整することが必要であるか否かを決定する。諸タスクの粒度を調整することが不要であれば、ステップＳ６４０に進み、そこで当該タスクを一のタスク・リストに追加する。一方、諸タスクの粒度を調整することが必要であれば、ステップＳ６３６に進み、そこで当該タスクの粒度をリセットする。諸タスクの粒度は、以前のタスク実行における一のクライアントの経験に基づき、動的にセットすることができる。次のステップＳ６４０では、当該タスクは、図７に示すようなタスク処理プロセスＳ５３６によってスケジュールすべき、タスク・リストに追加される。この点で、一のジョブをオフロードすることを要求するイベントのための処理が終了し、そして本プロセスは他のイベントを待機する状態に入る。

図１０は、図７に示すようなタスク処理の処理フローＳ５３６の詳細を示す。このタスク処理イベントのための動作は、本発明に従った重要な動作フローであり、クライアントの処理能力を共同的に活用するようにサーバ側を制御するための主要なプロセス・フローである点に留意されたい。

このラウンドの動作中、ステップＳ６５０で、タスク処理のイベントの発生に応答して、クライアント・グループのリストを検査し、ステップＳ６５２では、新しいクライアント・グループを使用すべきか否かを決定する。その決定結果が「Ｙｅｓ」であれば、ステップＳ６５４に進み、そこで諸タスクを当該グループ内の諸クライアントに割り振る。一方、ステップＳ６５２の決定結果が「Ｎｏ」であれば、ステップＳ６６２に進み、そこで使用可能な一のグループが存在するか否かを決定する。ステップＳ６６２の決定結果が「Ｎｏ」であれば、ステップＳ６６４に進み、そこで一のログを記録し且つサーバ側のイベント・スケジューラに対し現在使用可能なグループは存在しないことを報告する。ステップＳ６５４の後、ステップＳ６５６では、諸レコードを更新し、ステップＳ６５８では、当該クライアント・グループの占有をマークし、ステップＳ６６０では、処理されている当該タスクのための一のタイマを開始する。この点で、タスク処理イベントのための処理が終了する。ステップＳ６６０のタイマは、図１１のステップＳ６８０に示すようなタイマである点に留意されたい。図１０のタスク処理フローのステップＳ６６０は、当該タイマを開始するための出発点であるのに対し、図１１のタスク結果を戻すフローのステップＳ６８０は、当該タイマが停止するための終了点である。これらの開始及び終了ステップは、異なるイベント処理フロー内で実行されるが、同じタスクに関する限り、これらの２つの動作は、当該クライアント・グループが当該タスク上の処理を完了し且つその処理結果を所定の時間内にサーバに戻したか否かを示すように同じタイマをセットすべきものである。当該タスクを前記所定の時間内に完了しない場合には、図７のステップＳ５４０に示すように対応するタイムアウト動作が呼び出される。

図１１は、図７に示すようなタスク結果を戻す処理フローＳ５３８の詳細を示す。このラウンドの動作中、ステップＳ６７０では、新しいクライアント・ログオンというイベントの発生に応答して、一のタスク・リストを検査する。当該タスク・リストは、当該ジョブが分割される諸タスクについての情報（例えば、当該タスクと当該ジョブとの対応関係、当該タスクの現在の状態（例えば、まだ割り振られていない、割り振り済み、完了済み）、当該クライアント・グループと当該クライアント・グループ内の一のクライアントとの対応関係）を維持することができる。ステップＳ６７２では、一のタスク結果を戻すことに関連する一の規則を照会し、ステップＳ６７４では、前述の整合性を分析する方法又は他の方法によって当該処理結果の信頼度が十分に高いか否かを決定する。

ステップＳ６７４の決定結果が「Ｎｏ」（すなわち、信頼できない）であれば、ステップＳ６８４に進み、そこで当該処理結果を保存し、ステップＳ６８６では、処理結果の量を更新した後、このイベントのための処理が終了する。ステップＳ６７４の決定結果が「Ｙｅｓ」（すなわち、信頼できる）であれば、ステップ６７６に進み、タスク完了をマークし、ステップ６７８では、当該クライアント・グループが使用可能であることをマークし、ステップＳ６８０では、関連するタイマを停止する。このタイマは、一のタスク実行がタイムアウトであるか否かを決定する点に留意されたい。このタイマがタイムアウトし且つ当該処理結果がまだ求められていない場合は、図７のステップＳ５４０に示するようなタイムアウト・イベントが生成される。ステップＳ６８０の後、タスク結果を戻すための処理が終了している場合は、ステップＳ６８２で、タスク完了状態を更新し、そして本プロセスは他のイベントを待機する状態に入る。

図１２は、本発明に従った、サーバ側の処理能力を拡張するための装置のブロック図１２００を示す。図１２の左側ブロックに示すように、この装置は、サーバ側からオフロードすべき一のジョブを決定するための決定手段７１０と、当該ジョブを１つ以上のタスクに分割するための分割手段７２０と、１つ以上のクライアントから送信されたＨＴＴＰ要求に応答して、当該１つ以上のタスクを当該１つ以上のクライアントに割り振るための割り振り手段７４０と、当該１つ以上のクライアントから送信されたＨＴＴＰ要求から、当該１つ以上のタスクに対する当該１つ以上のクライアントの応答を受信するための受信手段７５０を備える。

前記装置は、前記１つ以上のタスクを実行するためにサーバ側で前記１つ以上のクライアントを選択するための選択手段７３０をさらに備えることができる。

前記装置は、諸決定（例えば、サーバ側から一のジョブをオフロードすること、前記ジョブを諸タスクに分割すること、諸タスクを諸クライアントに割り振ること、諸クライアントからの諸応答に基づき前記ジョブの少なくとも一部の処理結果を生成すること、諸クライアントを諸グループに分類すること）に関係する種類の規則を格納するための規則ベース７６０をさらに備えることができる。図１２では、規則ベース７６０をサーバ側に設置するように示しているが、前記装置が規則ベース７６０にアクセスし且つそこから一の規則を取得することができる限り、実際上、規則ベース７６０をサーバ側の外部にある任意のデータ・ストレージ手段内に設置することができる。

図１２の右側には、クライアント・グループ及び対応する諸クライアントが示されている。サーバ側は、それ自体の負荷を共有するために、これらのクライアント・グループ及び対応する諸クライアントを使用することができる。例えば、クライアント・グループ１（７７２）はＭ個のクライアントを含み、一方、クライアント・グループＫ（７７２）はＮ個のクライアントを含む。

図１２の装置が、決定手段７１０によって決定されたオフロードすべきジョブについて稼働するとき、分割手段７２０は、そのジョブを１つ以上のタスクに分割する。その後、割り振り手段７４０は、分割手段７２０による分割から取得された諸タスクを対応するクライアント・グループにそれぞれ割り振る。また、受信手段７５０は、それぞれのクライアント・グループから生成された諸応答を受信し、前記ジョブの少なくとも一部について一の処理結果を生成する。この動作プロセス中、それぞれの手段は、それ自体の動作を制御するために規則ベース７６０から諸規則を読み取ることができる。

決定手段７１０は、サーバ側の現在の負荷レベルを決定するための決定手段と、前記現在の負荷レベルが一のしきい値負荷レベルを超えそうか又は既に当該しきい値負荷レベルを超えていると決定することに応答して、サーバ側からオフロードすべき前記ジョブを指定するための指定手段を有する。

割り振り手段７４０は、前記１つ以上のクライアントの属性に基づき、前記１つ以上のクライアントをグループ化するためのグループ化手段と、前記グループと適合する一のタスクを、グループ単位で、前記１つ以上のクライアントに割り当てるための割り当て手段を有する。

前記１つ以上のクライアントの前記属性は、前記１つ以上のクライアントの処理能力、前記１つ以上のクライアントの現在の負荷、前記１つ以上のクライアントの応答時間、前記１つ以上のクライアントの信頼度、前記１つ以上のクライアントから前記サーバ側までの経路指定条件、前記１つ以上のクライアントのタスク完了履歴及び前記１つ以上のクライアントと前記サーバ側との間の契約のうちの１つ以上を含む。

割り振り手段７４０は、前記１つ以上のクライアントが前記サーバ側にログオンすることに応答して、前記１つ以上のタスクに対応するタスク記述及び処理すべきデータを前記１つ以上のクライアントに送信するための送信手段を有する。

前記タスク記述は、入力データ記述、出力データ記述及び処理アルゴリズム又はその記述のうちの１つ以上を含む。

分割手段７２０は、前記ジョブの計算負荷、前記ジョブの優先順位、前記ジョブの機密性及び前記タスクの粒度のうちの少なくとも１つに関係する所定の規則に基づいて動作する。

前記タスクの粒度は、以前のタスクを実行する際のクライアントの経験に基づいて動的にセットされる。

サーバ側の処理能力を拡張するための前記装置は、前記１つ以上のタスクに対する前記１つ以上のクライアントの応答に基づき、前記ジョブの少なくとも一部の処理結果を生成するための生成手段をさらに備える。

前記生成手段は、前記１つ以上のクライアントからの応答の信頼度を取得するための取得手段と、前記信頼度に基づき、前記ジョブの少なくとも一部の処理結果を提供するための提供手段を有する。

サーバ側の処理能力を拡張するための前記装置内の種々の手段は、図面には詳細に示していないが、当業者は、本明細書の開示に基づきこれらの手段を実装することができる点に留意されたい。さらに、図１２に示されている各手段及び図１２に示されていない他の手段は、サーバ側の１つ以上のサーバ又は１つ以上の他の専用装置内に設置することができる。本発明の諸実施形態は、サーバ側の処理能力を拡張するための前記装置の物理位置を制限しないから、この装置を構成する各手段は、本明細書に開示した諸機能を全体として実装することができる限り、任意の適当な物理デバイス内に集合的に又は分散的に設置することができる。

以上では、図１〜図１２を参照して、本発明に従った、サーバ側の処理能力を拡張するための方法及び装置を説明した。しかし、本明細書において提示したショッピング・ウェブサイトの例や、これらの例における特定のウェブサイト・レコード・ログの態様は、本発明の動作原理を説明するための単なる例であるに過ぎない点に留意されたい。サーバ側及びクライアントにおけるセッティングの相違に基づき、本発明の原理から逸脱することなく、他の態様で実装することができる。サーバ側の処理能力を拡張するための方法において、MapReduce アーキテクチャを採用することができる。

本発明は、ハードウェア実施形態、ソフトウェア実施形態又はハードウェア及びソフトウェア要素の両方を含む実施形態の形式を取ることができる。好ましい実施形態では、本発明は、（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）ソフトウェアとして実装される。

さらに、本発明は、コンピュータ又は任意の命令実行システムによって或いはそれらに関連して使用するためのプログラム・コードを提供するコンピュータ使用可能媒体又はコンピュータ可読媒体からアクセス可能なコンピュータ・プログラムとして実装することができる。この点に関連して、コンピュータ使用可能媒体又はコンピュータ可読媒体は、命令実行システム、装置又はデバイスによってあるいはそれらに関連して使用するためのプログラムを保持し、格納し、通信し、伝播し又は搬送することができる任意の有形的手段とすることができる。

かかる媒体は、電子的、磁気的、光学的、電磁的、赤外線、又は半導体システム（装置又はデバイス）或いは伝播媒体とすることができる。コンピュータ可読媒体の例は、半導体又は固体ストレージ・デバイス、磁気テープ、取り外し可能なフレキシブル・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、固定磁気ディスク及び光ディスクを含む。光ディスクの現在の例は、コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク・リード／ライト（ＣＤ−Ｒ／Ｗ）及びＤＶＤを含む。

プログラム・コードを格納又は実行するのに適したデータ処理システムは、メモリ要素に直接的に結合されるか又はシステム・バスを通してメモリ要素に間接的に結合された少なくとも１つのプロセッサを含むであろう。かかるメモリ要素は、プログラム・コードの実際の実行中に使用されるローカル・メモリと、大容量ストレージ、及び実行中にコードが大容量ストレージから検索されなければならない回数を減らすために、プログラム・コードの一時的ストレージを提供するキャッシュとを含む。

Ｉ／Ｏデバイス（キーボード、ディスプレイ、ポインティング・デバイス等を含む）は、直接的に又はＩ／Ｏコントローラを介してシステムに結合することができる。

また、ネットワーク・アダプタをデータ処理システムに結合すると、当該データ処理システムを、プライベート・ネットワーク又は公衆ネットワークを介して、他のデータ処理システム、リモート・プリンタ、ストレージ・デバイス等に結合することができる。モデム、ケーブル・モデム及びイーサネット（登録商標）カードは、現時点で使用可能なタイプのネットワーク・アダプタである。

前述の説明から理解されるように、本発明の精神から逸脱することなく、本発明のそれぞれの実施形態に対し修正又は変形を施すことができる。本明細書の説明は、例示を目的としたものであって、本発明を制限するものではない。本発明の範囲は、添付の特許請求の範囲における請求項の記載のみによって制限される。

１１１、１２１、２１０・・・ウェブ・サーバ
１１２、１２２、２２０・・・分析サーバ
１１３、１２３、２３０・・・サーバ側
１１４、１２４、２４０・・・ユーザ
７１０・・・決定手段
７２０・・・分割手段
７３０・・・選択手段
７４０・・・割り振り手段
７５０・・・受信手段
７６０・・・規則ベース
７７１・・・クライアント・グループ１
７７２・・・クライアント・グループＫ

Claims (22)

1. サーバ側の処理能力を拡張するための方法であって、
   （ａ）前記サーバ側からオフロードすべき一のジョブを決定するステップと、
   （ｂ）前記ジョブを１つ以上のタスクに分割するステップと、
   （ｃ）１つ以上のクライアントから送信されたＨＴＴＰ要求に応答して、前記１つ以上のタスクを前記１つ以上のクライアントに割り振るステップと、
   （ｄ）前記１つ以上のクライアントから送信された前記ＨＴＴＰ要求から、前記１つ以上のタスクに対する前記１つ以上のクライアントの応答を受信するステップを有する、方法。
2. 前記１つ以上のタスクを実行するための前記１つ以上のクライアントを選択するステップをさらに有する、請求項１に記載の方法。
3. 前記ステップ（ａ）が、
   前記サーバ側の現在の負荷レベルを決定するステップと、
   前記現在の負荷レベルがしきい値負荷レベルを超えそうか又は既に当該しきい値負荷レベルを超えていると決定することに応答して、前記サーバ側からオフロードすべき一のジョブを指定するステップを含む、請求項１に記載の方法。
4. 前記ステップ（ｃ）が、
   前記１つ以上のクライアントの属性に基づき、前記１つ以上のクライアントをグループ化するステップと、
   １つ以上のグループと適合する１つ以上のタスクを、グループ単位で、前記１つ以上のクライアントに割り当てるステップを含む、請求項１ないし請求項３の何れか１項に記載の方法。
5. 前記１つ以上のクライアントの前記属性が、
   前記１つ以上のクライアントの処理能力、前記１つ以上のクライアントの現在の負荷、前記１つ以上のクライアントの応答時間、前記１つ以上のクライアントの信頼度、前記１つ以上のクライアントから前記サーバ側までの経路指定条件、前記１つ以上のクライアントのタスク完了履歴及び前記１つ以上のクライアントと前記サーバ側との間の契約のうちの１つ以上を含む、請求項４に記載の方法。
6. 前記ステップ（ｃ）が、
   前記１つ以上のクライアントが前記サーバ側にログオンすることに応答して、前記１つ以上のタスクに対応するタスク記述及び処理すべきデータを前記１つ以上のクライアントに送信するステップを含む、請求項１ないし請求項３の何れか１項に記載の方法。
7. 前記タスク記述が、
   入力データ記述、出力データ記述及び処理アルゴリズム又はその記述のうちの１つ以上を含む、請求項６に記載の方法。
8. 前記ステップ（ａ）が、
   前記ジョブの計算負荷、前記ジョブの優先順位、前記ジョブの機密性及び前記タスクの粒度のうちの少なくとも１つに関係する所定の規則に基づいて実行される、請求項１ないし請求項３の何れか１項に記載の方法。
9. 前記タスクの粒度が、
   以前のタスクを実行する際のクライアントの経験に基づいて動的にセットされる、請求項８に記載の方法。
10. 前記１つ以上のタスクに対する前記１つ以上のクライアントの応答に基づき、前記ジョブの少なくとも一部の処理結果を生成するステップをさらに有する、請求項１ないし請求項３の何れか１項に記載の方法。
11. 前記生成するステップが、
    前記１つ以上のクライアントからの応答の信頼度を取得するステップと、
    前記信頼度に基づき、前記ジョブの少なくとも一部の処理結果を提供するステップを含む、請求項１０に記載の方法。
12. サーバ側の処理能力を拡張するための装置であって、
    前記サーバ側からオフロードすべき一のジョブを決定するように構成された決定手段と、
    前記ジョブを１つ以上のタスクに分割するように構成された分割手段と、
    １つ以上のクライアントから送信されたＨＴＴＰ要求に応答して、前記１つ以上のタスクを前記１つ以上のクライアントに割り振るように構成された割り振り手段と、
    前記１つ以上のクライアントから送信された前記ＨＴＴＰ要求から、前記１つ以上のタスクに対する前記１つ以上のクライアントの応答を受信するように構成された受信手段を備える、装置。
13. 前記１つ以上のタスクを実行するための前記１つ以上のクライアントを選択するように構成された選択手段をさらに備える、請求項１２に記載の装置。
14. 前記決定手段が、
    前記サーバ側の現在の負荷レベルを決定するように構成された決定手段と、
    前記現在の負荷レベルがしきい値負荷レベルを超えそうか又は既に当該しきい値負荷レベルを超えていると決定することに応答して、前記サーバ側からオフロードすべき一のジョブを指定するように構成された指定手段を有する、請求項１２に記載の装置。
15. 前記割り振り手段が、
    前記１つ以上のクライアントの属性に基づき、前記１つ以上のクライアントをグループ化するように構成されたグループ化手段と、
    １つ以上のグループと適合する１つ以上のタスクを、グループ単位で、前記１つ以上のクライアントに割り当てるように構成された割り当て手段を有する、請求項１２ないし請求項１４の何れか１項に記載の装置。
16. 前記１つ以上のクライアントの前記属性が、
    前記１つ以上のクライアントの処理能力、前記１つ以上のクライアントの現在の負荷、前記１つ以上のクライアントの応答時間、前記１つ以上のクライアントの信頼度、前記１つ以上のクライアントから前記サーバ側までの経路指定条件、前記１つ以上のクライアントのタスク完了履歴及び前記１つ以上のクライアントと前記サーバ側との間の契約のうちの１つ以上を含む、請求項１５に記載の装置。
17. 前記割り振り手段が、
    前記１つ以上のクライアントが前記サーバ側にログオンすることに応答して、前記１つ以上のタスクに対応するタスク記述及び処理すべきデータを前記１つ以上のクライアントに送信するように構成された送信手段を有する、請求項１２ないし請求項１４の何れか１項に記載の装置。
18. 前記タスク記述が、
    入力データ記述、出力データ記述及び処理アルゴリズム又はその記述のうちの１つ以上を含む、請求項１７に記載の装置。
19. 前記分割手段が、
    前記ジョブの計算負荷、前記ジョブの優先順位、前記ジョブの機密性及び前記タスクの粒度のうちの少なくとも１つに関係する所定の規則に基づいて動作する、請求項１２ないし請求項１４の何れか１項に記載の装置。
20. 前記タスクの粒度が、
    以前のタスクを実行する際のクライアントの経験に基づいて動的にセットされる、請求項１９に記載の装置。
21. 前記１つ以上のタスクに対する前記１つ以上のクライアントの応答に基づき、前記ジョブの少なくとも一部の処理結果を生成するように構成された生成手段をさらに備える、請求項１２ないし請求項１４の何れか１項に記載の装置。
22. 前記生成手段が、
    前記１つ以上のクライアントからの応答の信頼度を取得するように構成された取得手段と、
    前記信頼度に基づき、前記ジョブの少なくとも一部の処理結果を提供するように構成された提供手段を有する、請求項２１に記載の装置。

Images