特許 6971294 コンピュータ処理のためのリソース割当て

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

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

(11)【特許番号】6971294

(24)【登録日】2021年11月4日

(45)【発行日】2021年11月24日

(54)【発明の名称】コンピュータ処理のためのリソース割当て

(51)【国際特許分類】

   G06F 9/50 20060101AFI20211111BHJP

【ＦＩ】

   G06F9/50 120A

【請求項の数】13

【外国語出願】

【全頁数】30

(21)【出願番号】特願2019-229115(P2019-229115)

(22)【出願日】2019年12月19日

(62)【分割の表示】特願2018-536462(P2018-536462)の分割

【原出願日】2016年12月19日

(65)【公開番号】特開2020-74101(P2020-74101A)

(43)【公開日】2020年5月14日

【審査請求日】2020年1月17日

(31)【優先権主張番号】62/303,827

(32)【優先日】2016年3月4日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

【氏名又は名称原語表記】Ｇｏｏｇｌｅ ＬＬＣ

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】ブラッドショウ，ロバート

(72)【発明者】

【氏名】モクテスマ，ラファエル・デ・ヘスス・フェルナンデス

(72)【発明者】

【氏名】ミルズ，ダニエル

(72)【発明者】

【氏名】マクビーティ，サミュエル・グリーン

(72)【発明者】

【氏名】ウィットル，サミュエル・カール

(72)【発明者】

【氏名】マクシメンカ，アンドレイ

(72)【発明者】

【氏名】アラド，コスミン・イオネル

(72)【発明者】

【氏名】シールズ，マーク・ブライアン

(72)【発明者】

【氏名】ノーバー，ハリス・サミュエル

(72)【発明者】

【氏名】ファンドリヒ，マヌエル・アルフレート

(72)【発明者】

【氏名】ガードナー，ジェフリー・ポール

(72)【発明者】

【氏名】シュムリアン，ミクハイル

(72)【発明者】

【氏名】ラックス，ルーベン

(72)【発明者】

【氏名】アルタイ，アフメット

(72)【発明者】

【氏名】チャンバーズ，クレイグ・ディ

【審査官】 井上 宏一

(56)【参考文献】

【文献】 国際公開第２０１５／１６５５４６（ＷＯ，Ａ１）

【文献】 特開２０１１−２１０２２５（ＪＰ，Ａ）

【文献】 特開２０１４−１４９６９０（ＪＰ，Ａ）

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

Ｇ０６Ｆ ９／４５５−９／５４

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

【請求項1】

コンピュータシステムにおいてリソースを割当てるための方法であって、
データストリームを入力として受信するジョブを実行するステップと、
前記コンピュータシステムによって処理されるデータのバックログ量が所定の閾値を満たしているか否かを判定するステップと、
前記ジョブに入力される受信された前記データストリームにおける未処理データの増大量である、バックログ増大を判定するステップと、
前記データのバックログ量が前記所定の閾値を満たしていると判定されたことに基づいて、前記ジョブに割当てる処理リソースの量を調整するステップとを含み、前記ジョブに割当てる処理リソースの量を調整するステップは、前記バックログ量が前記所定の閾値を満たしていると判定されたことに応答して、前記ジョブに割当てる処理リソースの量を増加させるステップを含み、前記方法はさらに、
前記コンピュータシステムによって処理される前記データのバックログ量について、
（ｉ）前記バックログ増大は正であると判定され、かつ、当該バックログ量が前記所定の閾値を満たさなくなるまで、または
（ｉｉ）前記バックログ増大は負またはゼロであると判定され、かつ、当該バックログ量が他の所定の閾値を満たすまで、
前記ジョブに割当てる処理リソースの量を維持するステップを含む、方法。

【請求項2】

前記データのバックログ量は、前記ジョブに入力される受信されたデータストリームにおける未処理データの量である、請求項１に記載の方法。

【請求項3】

前記バックログ量はデータサイズの観点で測定されたものである、請求項１または２に記載の方法。

【請求項4】

前記処理リソースは、プロセッサリソースまたはストレージリソースを含む、請求項１から３のいずれか１項に記載の方法。

【請求項5】

前記処理リソースの量を調整した後、
前記コンピュータシステムによって処理される前記データのバックログ量が前記所定の閾値を満たしていないと判定するステップと、
前記ジョブに割当てる処理リソースの量を、前記処理リソースの量の増加前に前記コンピュータシステムが使用していたリソースのレベルに調整すると判定するステップとを含む、請求項１から４のいずれか１項に記載の方法。

【請求項6】

前記処理リソースの量を調整した後、
前記コンピュータシステムによって処理される前記データのバックログ量が前記他の所定の閾値を満たしていると判定するステップと、
前記処理リソースの量の増加に加えて追加の処理リソースを割当てることによって前記ジョブに割当てる処理リソースの量をさらに調整すると判定するステップとを含む、請求項１から５のいずれか１項に記載の方法。

【請求項7】

１つ以上のプロセッサを備えるコンピュータシステムであって、
データストリームを入力として受信するジョブを実行する手段と、
前記コンピュータシステムによって処理されるデータのバックログ量が所定の閾値を満たしているか否かを判定する手段と、
前記ジョブに入力される受信された前記データストリームにおける未処理データの増大量である、バックログ増大を判定する手段と、
前記データのバックログ量が前記所定の閾値を満たしていると判定されたことに基づいて、前記ジョブに割当てる処理リソースの量を調整する手段とを含み、前記ジョブに割当てる処理リソースの量を調整する手段は、前記バックログ量が前記所定の閾値を満たしていると判定されたことに応答して、前記ジョブに割当てる処理リソースの量を増加させる手段を含み、前記コンピュータシステムは、さらに、
前記コンピュータシステムによって処理される前記データのバックログ量について、
（ｉ）前記バックログ増大は正であると判定され、かつ、当該バックログ量が前記所定の閾値を満たさなくなるまで、または
（ｉｉ）前記バックログ増大は負またはゼロであると判定され、かつ、当該バックログ量が他の所定の閾値を満たすまで、
前記ジョブに割当てる処理リソースの量を維持する手段を含む、コンピュータシステム。

【請求項8】

前記データのバックログ量は、前記ジョブに入力される受信されたデータストリームにおける未処理データの量である、請求項７に記載のコンピュータシステム。

【請求項9】

前記バックログ量はデータサイズの観点で測定されたものである、請求項７または８に記載のコンピュータシステム。

【請求項10】

前記処理リソースは、プロセッサリソースまたはストレージリソースを含む、請求項７から９のいずれか１項に記載のコンピュータシステム。

【請求項11】

前記コンピュータシステムは、さらに、
前記ジョブに割当てる処理リソースの量が調整された後に、前記コンピュータシステムによって処理される前記データのバックログ量が前記所定の閾値を満たしていないと判定する手段と、
前記ジョブに割当てる処理リソースの量が調整された後に、前記ジョブに割当てる処理リソースの量を、前記処理リソースの量の増加前に前記コンピュータシステムが使用していたリソースのレベルに調整すると判定する手段とを含む、請求項７から１０のいずれか１項に記載のコンピュータシステム。

【請求項12】

前記コンピュータシステムは、さらに、
前記ジョブに割当てる処理リソースの量が調整された後に、前記コンピュータシステムによって処理される前記データのバックログ量が前記他の所定の閾値を満たしていると判定する手段と、
前記ジョブに割当てる処理リソースの量が調整された後に、前記処理リソースの量の増加に加えて追加の処理リソースを割当てることによって前記ジョブに割当てる処理リソースの量をさらに調整すると判定する手段とを含む、請求項７から１１のいずれか１項に記載のコンピュータシステム。

【請求項13】

コンピュータによって実行されるプログラムであって、前記プログラムは、前記コンピュータに、請求項１から６のいずれか１項に記載の方法を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本願は、２０１６年３月４日に出願された米国仮出願第６２／３０３，８２７号に基づく優先権を主張し、その開示を本明細書に引用により援用する。

【0002】

本明細書は、並列処理環境における入力のコンピュータ処理に関する。

【背景技術】

【0003】

背景
コンピュータネットワークは、リソースおよび情報の共有を可能にする通信チャネルによって相互接続されたコンピュータおよび他のハードウェアの集合である。通信プロトコルは、コンピュータネットワークにおいて情報を交換するための規則およびデータフォーマットを規定する。

【発明の概要】

【0004】

概要
一局面において、方法はコンピュータシステムによって行なわれる。方法は、複数の処理リソースを備えるコンピュータシステムにおいて、データストリームを入力として受信するジョブを実行するステップを備える。データストリーム内のデータ量は、無限である。方法は、ジョブについて、ジョブに入力される受信されたデータストリームにおける未処理データの増大量である、第１の期間にわたるバックログ増大と、ジョブに入力される受信されたデータストリームにおける未処理データの量であるバックログ量と、バックログ増大およびバックログ量に基づいて、ジョブに割当てる処理リソースの量を調整するか否か、とを繰り返し判定するステップを含む。方法は、ジョブに割当てる処理リソースの量を調整すると判定された繰り返し毎に、ジョブに割当てる処理リソースの量を調整するステップを含む。方法は、ジョブに割当てる処理リソースの量を調整しないと判定された繰り返し毎に、ジョブに割当てる処理リソースの量を維持するステップを含む。

【0005】

実現例は、以下の特徴のうちのいずれか、もしくはすべてを含んでもよく、または以下の特徴を含まなくてもよい。判定の繰り返しについて、バックログ増大はゼロまたは負であると判定され、バックログ量は目標と等しいと判定され、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標と等しいと判定されたことに応答して、ジョブに割当てる処理リソースの量を調整しないと判定される。判定の繰り返しについて、バックログ増大はゼロまたは負であると判定され、バックログ量は目標未満であると判定され、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を削減するステップを含む。判定の繰り返しについて、バックログ増大はゼロまたは負であると判定され、バックログ量は目標よりも大きいと判定され、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標よりも大きいと判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標よりも大きいと判定されたことに応答して、ジョブに割当てる処理リソースの量を増加させるステップを含む。判定の繰り返しについて、バックログ増大は正であると判定され、バックログ量は目標未満であると判定され、バックログ増大が正であると判定され、かつ、バックロ
グ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整しないと判定される。判定の繰り返しについて、バックログ増大は正であると判定され、バックログ量は目標以上であると判定され、バックログ増大が正であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、バックログ増大が正であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を増加させるステップを含む。バックログ増大はデータサイズの大きさである。データサイズの単位は、ビット、バイト、メガバイト、ギガバイト、レコード、および基数からなる群のうちの少なくとも１つである。バックログ増大は処理時間の長さである。処理時間の単位は、マイクロ秒、秒、分、時間、および日からなる群のうちの少なくとも１つである。バックログ量はデータサイズの大きさである。データサイズの単位は、ビット、バイト、メガバイト、ギガバイト、レコード、および基数からなる群のうちの少なくとも１つである。バックログ量は処理時間の長さである。処理時間の単位は、マイクロ秒、秒、分、時間、および日からなる群のうちの少なくとも１つである。方法は、ジョブについて、プロセッサ使用率を繰り返し判定するステップをさらに含み、ジョブに割当てる処理リソースの量を調整するか否かを繰り返し判定するステップは、さらにプロセッサ使用率に基づく。判定の繰り返しについて、プロセッサ使用率はある値未満であり、プロセッサ使用率がある値未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、プロセッサ使用率がある値未満であると判定されたことに応答してジョブに割当てる処理リソースの量を削減するステップを含む。プロセッサ使用率がある値未満であると判定されたことに応答してジョブに割当てる処理リソースの量を削減するステップは、ジョブに割当てるリソースの離散数を減少させるステップを含み、離散数はプロセッサ使用率に基づく。離散数はコンピュータメモリディスクの数である。バックログ増大およびバックログ量に基づいてジョブに割当てる処理リソースの量を調整するか否かを判定するステップは、ジョブに割当てる処理リソースの量の変動を生じさせる判定するステップを平滑化するステップを含む。判定するステップを平滑化するステップは、第２の期間待つステップを含む。判定するステップを平滑化するステップは、ジョブに割当てる処理リソースの量を調整するか否かの複数の判定を平均化するステップを含む。

【0006】

一局面において、システムは、コンピュータプログラム命令を実行するように構成された１つ以上のプロセッサと、コンピュータプログラム命令が符号化されたコンピュータ記憶媒体とを備え、コンピュータプログラム命令は、１つ以上のプロセッサによって実行されると、コンピュータデバイスに演算を行なわせる。演算は、複数の処理リソースを備えるコンピュータシステムにおいて、データストリームを入力として受信するジョブを行なわせる。データストリーム内のデータ量は、無限である。演算は、ジョブについて、ジョブに入力される受信されたデータストリームにおける未処理データの増大量である、第１の期間にわたるバックログ増大と、ジョブに入力される受信されたデータストリームにおける未処理データの量であるバックログ量と、バックログ増大およびバックログ量に基づいて、ジョブに割当てる処理リソースの量を調整するか否か、とを繰り返し判定するステップを含む。演算は、ジョブに割当てる処理リソースの量を調整すると判定された繰り返し毎に、ジョブに割当てる処理リソースの量を調整するステップを含む。演算は、ジョブに割当てる処理リソースの量を調整しないと判定された繰り返し毎に、ジョブに割当てる処理リソースの量を維持するステップを含む。

【0007】

ここで記載されるシステムおよび処理を用いて、多くの潜在的な利点が提供され得る。リソース割当てレベルを判定するための測定基準としてバックログ量を用いることによって、過剰供給および過少供給という不都合が低減または排除され得る。過剰供給は、使用されない、またはアイドル状態のネットワークリソースを生じさせるため、コストが上昇
し、処理可能なジョブ数が減少する。作業負荷に合わせてリソース割当てを削減することによって、使用されていないリソースが他のジョブのために自由に使えるようになり得る。過少供給はバックログの増加につながり、データ損失およびレイテンシの増大を生じさせるおそれがある。作業負荷に合わせてリソース割当てを増加させることによって、入力が増加した際にジョブをより速く処理することができる。多くの場合において、データは、予測不能に増加または減少し得るストリーム、または連続する無限のデータの流れとしてジョブに入力される。この入力を一括として扱い、または最悪のシナリオのために計画するのではなく、この入力に動的に応答することによって、入力の大きな急上昇または低下への柔軟な応答が可能になる。

【0008】

他の特徴、局面、および潜在的な利点は、添付の明細書および図面から明らかになるである。

【図面の簡単な説明】

【0009】

図面の説明
さまざまな図面における同様の参照符号は、同様の要素を指す。

【図1】ジョブ群へのリソース割当てをオートチューニングする、高度に分散されたコンピューティング環境のブロック図である。

【図2】オートチューニングを行なう場合および行わない場合のジョブへのリソース割当てを示すチャートを含む図である。

【図3】経時的なストリーミング信号を示すチャートを含む図である。

【図4】オートチューニングリソース割当てのための処理例のフローチャートである。

【図5】リソース割当てを増加するか削減するかを判定するための処理例のフローチャートである。

【図6A】タスクのセットアップ、サイズ変更、および休止のための処理例のフローチャートである。

【図6B】タスクのセットアップ、サイズ変更、および休止のための処理例のフローチャートである。

【図6C】タスクのセットアップ、サイズ変更、および休止のための処理例のフローチャートである。

【図7】コンピューティングデバイスの例を示す概略図である。

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

【0010】

詳細な説明
共用並列コンピューティング環境において、コンピューティングリソースは、異なるタスク（単一のジョブ内の異なる並列実行タスク、および、同時に処理され得る異なるジョブの両方）に割当てられ得る。それらのリソースの割当て方を決定するために、ジョブには、許容される入力バックログの量を規定するバックログサイズが割当てられ得る。次いで、実際のバックログを割当てられたバックログレベル以下に保つために、バックログの実際のサイズに基づいてリソースが動的に割当てられたり除去されたりする。これにより、例えば、特定のジョブの要求に経時的に合致するリソースの動的割当てを可能にすることができる。

【0011】

この動的割当ては、オートスケーリングと呼ばれることがある。これは、特定のジョブに利用可能なリソースが、ジョブに供給される入力の処理要件に経時的に合致するように自動的にスケール変更されるからである。入力量が経時的に変化するのに伴って、許容できない未処理入力が生じるのを防ぐためには、より多くのリソースが必要になる。この未処理入力はバックログを生じさせる。バックログとは、本質的には、処理に利用可能であるが未処理の入力である。

【0012】

バックログは、データサイズ（例えば、バイト、メガバイト）、処理時間（例えば、データが利用可能であるが未処理である継続時間、現在のリソース量または一定のリソース量を用いて現在のバックログデータのすべてを処理するまでの予想時間、経時的なデータのスループットの値）、カウント（例えば、ファイルまたはシャードの数）、または他の適切な次元で計測され得る。

【0013】

バックログサイズは、オートチューニングのための有用な測定基準として使用される。なぜなら、それは他のコンピューティングリソースにも影響を与え得て、コンピュータベースの製品の有用性に影響を与え得て、かつ、人間のユーザによって容易に理解され得る測定基準だからである。例えば、コンピュータメモリに格納されたバックログは、バックログの増加に伴ってより多くのメモリを必要とするであろう。バックログを目標サイズ以下に保つことにより、必要メモリ量を把握し、計画を立てることができる。同様に、バックログを目標サイズ未満に保つことにより、高い質のサービスが提供され得る。ソーシャルメディア投稿を構文解析するジョブは、投稿が公開されたときに当該投稿を構文解析して初めて有用であり得る。構文解析されていない投稿のバックログを例えば２分未満に保つことによって、ジョブがその意図された目的のために有用であることが保証され得る。人間のユーザに理解できる次元でバックログを記録および報告することによって、ユーザは、如何にしてジョブを利用するか、および、如何にして将来のジョブを活用して報酬を得ることができるかについて決定することができる。

【0014】

図１は、ジョブ群へのリソース割当てをオートチューニングする、高度に分散されたコンピューティング環境１００のブロック図である。ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネット、またはそれらの組み合わせなどのコンピュータネットワーク１０２により、分散処理システム１０４と、ストリーミングデータプロバイダ１０６と、１つ以上のネットワーク記憶装置１０８とが接続される。分散処理システム１０４は、例えば、分散処理システムマネージャ１１０と、ワーカーマネージャ１１２と、複数のデータプロセッサ１１４とを含み得る。ネットワーク記憶装置１０８は分散処理システム１０４とは別に図示されているが、分散処理システム１０４に含まれてもよい。

【0015】

ストリーミングデータプロバイダ１０６は、分散処理システム１０４による処理のためにデータを提供する。分散処理システム１０４は、データレコードおよび命令を取得して、当該データレコード上の１つ以上のジョブ１１１を行ない得る。一例として、ストリーミングデータプロバイダ１０６は、フィルタリング、ソーティング、および他の分析のために、分散処理システム１０４に検索クエリレコードを提供し得る。検索クエリレコードは、例えば、検索システムに送られる検索クエリおよび関連情報（例えば、クエリが受取られた時間を示すタイムスタンプなど）を含み得る。

【0016】

ストリーミングデータプロバイダからのデータは、例えば、無限であり、予測不能であり、非常に変化しやすく、および／またはバースト的であり得る。無限のデータは、絶えずアップデートされ、確定したサイズを持たないデータセット、すなわちストリーミングデータを含む。絶えずアップデートされるデータセットの例は、発生するサーバログ、または処理されるすべての新たな命令であり得る。予測不能なデータは、少なくとも何らかの次元において予測が難しいデータ、予測ができないデータ、または、予測されていないデータを含む。例えば、ユーザが受信する電子メールのレートは予測不能であり得る。なぜなら、それは高度に分散されたコンピューティング環境１００がアクセスしない、またはアクセスできない要因に依存し得るからである。非常に変化しやすいデータは、少なくとも１つの次元において著しく変化するデータを含む。非常に変化しやすいデータは、極めて季節的または周期的なデータであり得る。小売業者のウェブサイトからのログのアッ
プデートは、１年のうちの時期および買い物シーズン次第で速くなったり遅くなったりし得る。バーストデータは、現在のデータ生成レートが平均のデータ生成レートに近いことがほとんどないデータを含む。言い換えると、多くの場合、バーストデータは、高度に分散されたコンピューティング環境１００によってバーストで大量受信され、その後に少ない量のデータ受信が続く。

【0017】

分散処理システムマネージャ１１０は、例えば、ワーカー１１３によって実行されるジョブ１１１を割当てることによって、データプロセッサ１１４のうちの１つ以上をワーカー１１３に割当てることによって、ネットワーク記憶装置１０８の１つ以上のディスクをワーカー１１３に割当てることによって、障害およびバックログを特定して対処することによって、および、一時的および長期的なストレージを管理することによって、データ処理システム１０４のためのプロセススケジューリングおよびリソース管理サービスを行ない得る。ワーカーマネージャ１１２は、分散処理システムマネージャ１１０とは別に図示されているが、いくつかの実現例では、分散処理システムマネージャ１１０の一部であってもよい。ワーカーマネージャ１１２は、ワーカー１１３、データプロセッサ１１４、およびネットワーク記憶装置１０８を監視して、作業負荷バックログが生じているか否か、および作業負荷バックログがいつ生じるかを判定する。作業負荷バックログが生じている場合、または、リソース（例えば、データプロセッサ１１４および／またはネットワーク記憶装置１０８）がアイドル状態で作業負荷バックログが生じていない場合、作業負荷マネージャ１１２は、ジョブ１１１に割当てるリソースをオートチューニングし得る。

【0018】

ジョブ１１１は、ストリーミングデータプロバイダ１０６からのデータを処理し、出力を生成する。この出力は、ネットワーク記憶装置１０８に格納されるか、または他の目的で使用され得る。いくつかの実現例では、ジョブ１１１は、複数のデータストリームから入力データを受信する。例えば、ジョブ１１は、ストリーミングデータプロバイダ１０６からソーシャルメディア投稿のストリームを受信し、別の（図示しない）ストリーミングデータプロバイダから天気データのストリームを受信し得る。受信された入力データのストリームを処理するために、ジョブ１１１にワーカー１１３が割当てられてもよい。各ワーカー１１３には、例えば、１つ以上のプロセッサ１１４と、ネットワーク記憶装置１０８の１つ以上のディスク（現実または仮想）とが割当てられてもよい。特定のジョブ１１１に割当てられたワーカー１１３は、次いで、ジョブ１１１によって規定された処理に従ってストリーミング入力データを処理し、出力を生成し得る。この出力は、ネットワーク記憶装置１０８に格納され、別の場所に送信され得る。

【0019】

この例では、リソース（例えば、データプロセッサ１１４およびネットワーク記憶装置１０８）がワーカー１１３に割当てられ、ワーカー１１３がジョブ１１１に割当てられる場合を説明しているが、リソースをジョブ１１１に割当てるための他の仕組みも可能である。例えば、データプロセッサ１１４および／またはネットワーク記憶装置１０８のディスクが、分散処理システムマネージャによってジョブ１１１に直接割当てられてもよい。

【0020】

いくつかの場合には、ジョブ１１１が複数の処理に分解され、各々の処理が１つのワーカー１１３に割当てられてもよい。これは、例えばジョブ１１１が並列化可能である場合（例えば、ジョブ１１１が、互いに独立して実行され得る複数の動作に分解可能である場合）に有利であり得る。

【0021】

図２は、オートチューニングを行なう場合および行わない場合のジョブへのリソース割当てを示すチャート２００、２０８、および２１６を含む図である。オートチューニングを行わない場合、リソースは過剰供給または過少供給の場合がある。過剰供給の場合にはリソースが無駄になる可能性があり、一方、過少供給の場合には、作業負荷の急上昇の際に遅延につながる可能性がある。これに対して、作業負荷の増加時にワーカーの供給をオ
ートチューニングし、同様に作業負荷の減少時にワーカーの数を削減すると、需要に従ってリソースを動的に調整することが可能である。

【0022】

チャート２００では、リソースの過剰生成を示す。線２０２は、線２０４で示す作業負荷が到達するよりも常に多い、一定レベルの供給を表わす。領域２０６は、割当てられたものの使用されていない、つまり無駄になったリソースを表わす。

【0023】

チャート２０８では、リソースの過少生成を示す。線２１０は、急上昇の際に線２１２で示す作業負荷よりも少ない、一定レベルの供給を表わす。領域２１４は、処理できずにバックログとなる作業負荷を表わす。

【0024】

チャート２１６では、オートチューニングされたリソースの割当てを示す。線２１８は、線２２０で示す作業負荷の変化に応じたリソース割当ての動的割当てレベルを表わす。図示のように、割当てられたリソースは、作業負荷とほぼ同じか、または作業負荷よりも多い。さらに、割当てられたリソースよりも作業負荷が多くなることによってバックログの発生が増加する場合もあるが、リソース割当てのレベルがすぐに高まり、その結果、短期間でリソース割当てが増加する。このように、バックログの増加はリソース割当ての増加によって対処され、処理されて目標レベルに戻され得る。

【0025】

一例として、オートチューニングは以下の信号を用いて決定を行なうことができる。
ＣＰＵ使用率：ジョブにおけるすべてのワーカーＶＭの平均ＣＰＵ使用率
ステージバックログ増大：未処理データのサイズ
ステージバックログ量：ジョブに入力される受信されたデータストリームにおける未処理データの量
いくつかの実現例では、バックログ量はバックログ時間であってもよい。バックログ時間とは、現在のスループットで追加の入力がない場合に、そのバックログを処理するのに必要となるであろう時間の長さである。他の信号が使用されてもよい。

【0026】

オートチューニングは、以下の条件を用いてジョブのすべてのステージ間の均衡を求める。すなわち、バックログ増大、バックログ量、およびＣＰＵ使用率という条件である。これらの条件のサブセットを用いて調整を行なってもよい。例えば、いくつかの実現例では、バックログ増大およびバックログ量が用いられ得る。バックログ増大条件は、バックログ増大≦平均０である。バックログ増大が正の場合、バックログが累積してジョブが遅延する。バックログ量条件は、バックログ量≦目標バックログ量である。例えば、バックログ量がバックログ時間である場合、バックログ時間は比較的短いことが望ましい。さもなければ、バックログは増大しないが高い処理レイテンシが存在する安定状態を回避するためである。許容可能なより短いバックログは、より多くの処理リソースを必要とするが、より低いレイテンシを実現する。いくつかの場合には、許容可能なバックログレイテンシ時間は０であるか、または０に近い。他の場合、許容可能なバックログレイテンシ時間は、より長い。ＣＰＵ条件は、ＣＰＵ（例えば、データプロセッサ１１４）使用率が閾値よりも大きいことである。ＣＰＵ使用率が低い安定状態は、ストリーミングジョブが少ないワーカー数に対応可能であろうことを示す。いくつかの実現例では、バックログ条件を用いて、ジョブに割当てるリソースの数を調整するか否かを判定し、システムがリソースの数を調整すると判定された場合には、ＣＰＵ条件を用いて、調整するリソースの数を決定する。

【0027】

全体のジョブサイジングは、すべてのステージについてバックログ条件を満たすのに必要なワーカーの最大数によって決まる。すべてのステージについてバックログ条件を満たす場合、ＣＰＵ条件を用いて、割当て削減の程度を判定する。

【0028】

いくつかの実現例では、永続ディスクを用いて状態を格納する。ジョブ状態を格納するために、ジョブは一定数（いくつかの場合には、そのジョブについてのワーカーの最大数と同じ数）の永続ディスクを有し得る。各ディスクは、ジョブによる処理中のキー範囲に対応する。そのため、ディスク数が多いワーカーの方が、ディスク数が少ないワーカーよりもビジーである（範囲間でデータ分散が均等であると想定した場合）。いくつかの場合には、ディスク分散が不均等な状態でワーカーの数を増減させると、最も負荷のかかったワーカーのレベルで動作することになる。そのため、オートチューニングは、最も均等なディスク分散を提供するワーカー数を選択する（例えば、システムがワーカー１個当たりｄ個のディスクを目標とする場合、システムは、ｄ１個のディスクを有するワーカーの数を最小限にする）。

【0029】

いくつかの実現例では、現在の入力レート（スループット＋バックログ増大）を現在のスループットで除することによって、かつ、それをワーカーの現在の数によってスケール変更することによって、特定のステージについての望ましいワーカー数が計算される。例えば、ワーカーが１０個でスループットが１ＭＢ／ｓであり、バックログ増大が２００Ｋ／ｓである場合、オートチューニングは、１．２×１０＝１２個のワーカーを要求するであろう。さらに、望ましいバックログ時間よりも長い場合、余分のワーカーが追加され得る。

【0030】

いくつかの実現例では、各ステージは、この望ましいワーカー数を独立して計算する。次いで、ジョブのためのプールは、すべてのステージにわたって望ましいワーカー数の最大値に合わせてスケール変更される。

【0031】

ジョブに割当てるリソースの数を削減するために、ジョブは、平均バックログ時間がある閾値未満であり、かつ、バックログ増大が０である安定状態（例えば、平均して、経時的に、閾値距離内で）にされ得る。いくつかの実現例では、システムは、割当て削減の程度を次のように判定する。均等なディスク分散への要望を考慮して、オートチューニングは、ジョブがすぐ下のワーカーレベルに対処可能であるか否かのプロキシとして、ＣＰＵを次のように使用する。現在の数ｗ１のワーカーがワーカー１個当たりｄ１（またはｄ１−１）個のディスクを有すると想定する。ワーカー１個当たり最少のｄ２＞ｄ１のディスク数、および必要なワーカーの最少数ｗ２を、ｗ２＜ｗ１、かつ、各ワーカーがｄ２（またはｄ２−１）個のディスクを得るように求める。理想的なスケール変更かつオーバーヘッドのない状態を想定すると、新たなワーカーは、現在のＣＰＵレートにｗ１／ｗ２を掛けたもので動作することになる。この新たなＣＰＵレートが妥当な閾値（例えば、１.０
）未満である場合、オートチューニングは、割当てをｗ２まで削減することを試みる。

【0032】

前回の割当て増加または削減の直後の信号は、多くの場合、定常状態を表わすものではない（例えば、頻発するキャッシュミスなどのため）。そのため、オートチューニングは、決定の平滑化を採用することにより、不要な変動を回避しつつ、作業負荷の実際の変化に依然として反応することができる。スケール拡大の決定の平滑化は、以下の１）および２）によって行なわれる。
１）ワーカー変更の後、入力信号が安定するまである期間待つ。
２）出力信号を平滑化して、スケール拡大時の時間枠内の望ましいワーカーの平均値を選択する（その時間枠において要求される最少のワーカー数が現在の数よりも多いと想定した場合）。
最少値が増加するまで時間枠の全体にわたって待つことにより、入力レートにおける短期のノイズへの反応が回避される。例えば、現在のワーカー数が１０未満であり、時間枠が望ましいワーカー数［１１、１２、１０］を含む場合、割当て増加は、（均等なディスク分散を得るために数を正規化する前に）作動させるワーカーの数として１１を選択するであろう。

【0033】

いくつかの実現例では、スケール縮小のために、オートチューニングは、ある期間にわたる時間枠におけるすべての値が現在のワーカー数未満となるまで待ち、その後最大値（ディスク分散が均等な状態で、現時点で常にすぐ下のワーカーレベル）までスケール縮小する。

【0034】

ワーカーに関係し得る以下の信号が、ワーカーマネージャから受信され得る。
ｐｅｒ＿ｓｔａｇｅ信号
ｉｎｐｕｔ＿ｓｉｚｅ：絶えず増加する、処理されたバイトの合計
スループットとして計算された派生信号（derivative）（以下参照）
ｂａｃｋｌｏｇ＿ｓｉｚｅ：バックログの現在のバイトサイズ
バックログ増大として計算された派生信号（以下参照）
ａｃｔｉｖｅ＿ｓｉｚｅ：そのステージで現在処理中のバイト
ステージの固有のレイテンシを判定するために使用される
ｓｙｓｔｅｍ＿ｗａｔｅｒｍａｒｋ：ステージのシステム透かし
いくつかの実現例では、１Ｍ／ｓで増加する。

【0035】

ジョブ信号
ａｃｔｉｖｅ＿ｗｏｒｋｅｒｓ：現在のアクティブなワーカー数
ストリーミングの文脈において、ワーカーは、ワーカー処理、および／またはワーカースレッドであり得る。いくつかの実現例では、構成アップデートを受信した後にチェックインするワーカー数として計算される。カウントは、動作可能なワーカー数（例えば、すべてのディスク割当て、スキャニングが行なわれた後）を反映し得る。
ａｔｔａｃｈｅｄ＿ｄｉｓｋｓ：すべてのディスクが装着されているわけではないため、スケール変更の決定を行なうべきではないと判定するために使用される。
平均ＣＰＵ使用率：ジョブにおけるすべてのワーカーＶＭの平均ＣＰＵ使用率
例えばジョブのステージ毎の派生信号
ｉｎｐｕｔ＿ｓｉｚｅからのスループット（前回のアップデート以降、かつ指数平滑平均）
バックログサイズからのｂａｃｋｌｏｇ＿ｇｒｏｗｔｈ（前回のアップデート以降、かつ指数平滑平均）
ｂａｃｋｌｏｇ＿ｔｉｍｅ:（ｂａｃｋｌｏｇ＿ｓｉｚｅ ａｃｔｉｖｅ＿ｓｉｚｅ）／
スループット
追加の入力がない場合にバックログを処理するのに必要となるであろう時間（現在処理中の分を割引いてもよい）
いくつかの実現例では、システムが実時間に近づくにつれて、効率が低下し、ひいては事実上のバックログ時間が長くなり得る。
ｍｉｎ＿ｔｈｒｏｕｇｈｐｕｔ＝スループット＋ｍａｘ（０、ｂａｃｋｌｏｇ＿ｇｒｏｗｔｈ）：遅延しないために必要な最小スループット。

【0036】

ステージ毎の目標は、以下の条件で均衡に到達するようにワーカーを増減することである。
ｂａｃｋｌｏｇ＿ｇｒｏｗｔｈ≦平均０（つまり、バックログ長さが増大せずに安定している）
ｂａｃｋｌｏｇ＿ｔｉｍｅ≦ａｃｃｅｐｔａｂｌｅ＿ｂａｃｋｌｏｇ＿ｔｉｍｅ（構成パラメータ）
ｂａｃｋｌｏｇ＿ｔｉｍｅ≧ｍａｘ＿ｂａｃｋｌｏｇ＿ｔｏ＿ｄｏｗｎｓｃａｌｅ（構成パラメータ）
ｂａｃｋｌｏｇ＿ｔｉｍｅ条件は、レイテンシが許容可能範囲内となることを保証し、バックログが極めて大きい安定バックログ状態となることを回避することを試みる。ｍａｘ
＿ｂａｃｋｌｏｇ＿ｔｏ＿ｄｏｗｎｓｃａｌｅ条件は、割当てを削減することを試みる信号である。システムがその閾値未満である場合、システムはリソースを無駄にする可能性が高く、より少ないシステムワーカーで対処可能であろう。

【0037】

いくつかの実現例では、スケール拡大は、１）入力レートに対応するため、および、２）バックログを最小長さに向けて減少させるために、ワーカーを追加することに基づく。いくつかの例では、ワーカー数に対してスループットが最終的には線形的にスケール変更されることが想定され得る。すなわち、要因ｘによってワーカー数が増加または減少するのに伴い、要因ｘによってスループットが増加または減少する。いくつかの実現例では、必要ワーカー数は、必要スループットの最小レベルを、ワーカー１個当たりのスループットで除したものとして算出され得る。

【0038】

残存バックログは、許容可能バックログよりも大きいバックログであって、現在のバックログ増大が負であるときに、見かけ上、システムが当該負の増大の分だけ減少させていないバックログである。これは、バックログアクティブサイズからバックログの許容可能サイズを差引き、負のバックログ増大およびバックログ回復時間の合計を加えたものとして算出され得る。

【0039】

追加のワーカー数は、ワーカー１個当たりの現在のスループットに基づいて、バックログ回復時間内に残存バックログを処理できるように選択される。追加のワーカー数は、残存バックログを、ワーカー１個当たりのスループットおよびバックログ回復時間の合計で除したものとして算出され得る。次いで、新たな望ましいワーカー数が、スループットワーカー数とバックログワーカー数とを足したものとして算出される。

【0040】

ディスクの総数はジョブ毎に一定であり得るため、システムがスケール変更する際に、システムは、存在するディスクをワーカー間に分散させ得る。ディスクはデータのソース／範囲に対応するため、ディスク数が多いワーカーの方が、システムディスク数が少ないワーカーよりもビジーである（範囲間でデータ分散が均等であると想定した場合）。いくつかの場合には、ディスク分散が不均等な状態でワーカーの数に合わせて増減させると、最も負荷のかかったワーカーのレベルで動作することになる。そのため、システムは、均等なディスク分散を提供するワーカー数に最も近い数に合わせるようにスケール変更を試み得る。

【0041】

割当てを削減するために、いくつかの実現例では、システムは、平均バックログ時間がｍａｘ＿ｂａｃｋｌｏｇ＿ｔｏ＿ｄｏｗｎｓｃａｌｅ未満であり、かつ、バックログ増大が平均０である安定状態となる必要があり得る。割当て削減の程度を判定するために、システムは、当該システムがすぐ下のワーカーレベルに対処可能であるか否のプロキシとして、ＣＰＵを使用する。プロキシに基づく決定の一例は、次のようなものであり得る。現在の数ｗ１のワーカーが、ワーカー１個当たり最大ｄ１個のディスクを含むものと想定する。システムは、各ワーカーが最大でｄ２＞ｄ１のディスクを有するような最大ワーカーｗ２＜ｗ１を計算する。いくつかの状況では、新たなワーカーは、現在のＣＰＵレートにｗ１／ｗ２を掛けたもので動作することになる。この新たなＣＰＵが許容可能最大値（例えば、１.０）未満である場合、システムは、割当てをｗ２まで削減することを試みる。

【0042】

ジョブのスケール変更のために、各ステージは、望ましいワーカー数を独立して有し得る。次いで、ジョブのためのプールは、すべてのステージにわたって望ましいワーカー数の最大値に合わせてスケール変更される。

【0043】

平滑化は、以下の１）および２）によって行なわれ得る。
１）ワーカー変更の後、入力信号が安定するまである期間待つ。
２）出力信号を平滑化して、スケール拡大時の時間枠内の望ましいワーカーの平均値を選択する（最少値が現在の数よりも多いと想定した場合）。
最少値が増加するまで時間枠の全体にわたって待つことにより、ｍｉｎ＿ｔｈｒｏｕｇｈｐｕｔの短期間の急上昇への反応を回避することができる。

【0044】

いくつかの実現例では、スケール縮小のために、システムは、時間枠におけるすべての値が現在のワーカー数未満となるまで待ち、その後、特定される最大値（ディスク分散が均等な状態で、現時点で常にシステムのワーカーレベルの次のレベル）までスケール縮小し得る。

【0045】

図３は、経時的なストリーミング信号を示すチャート４００、４０２、４０６、および４０８を含む図である。チャート４００は、アクティブワーカーの数を示す。このチャートにおいて、要求されるワーカーを示す一番下のチャートから分かるように、ワーカーは１５から８まで割当てを次第に減少させる。要求されるワーカーとアクティブワーカーとの間の不一致は、サイズ変更時の短期間いくつかのワーカーがアクティブではない場合があること、いくつかのワーカーが停止して回復する場合があることなどを示す。なお、すべてのワーカーが現時点ですべてのステージで動作するとき、アクティブワーカーおよび要求されるワーカーのチャートは各ステージで同一である。

【0046】

チャート４０２は、このステージについてのバックログ時間を示す。それは、現在の平均処理速度でバックログを０まで減少させるのに必要となるであろう推定時間である。

【0047】

チャート４０４は、ストリーミングＣＰＵ使用率を示す。ここでは、すべての仮想マシンの平均使用率を示す。しかしながら、外れ値を除いた平均値、中央値、最頻値、最小値、最大値、またはこれらの値を組み合わせた測定基準を含む、他の測定基準を用いてもよい。

【0048】

チャート４０６は、入力レートが約５ＭＢ／ｓから始まり、６.６ＭＢ／ｓまで増加し
、次いで減少し始めて４ＭＢ／ｓ未満となることを示す。レートの隆起は、チャート４０８で減少として示されるサイズ変更点に起因するものである。サイズ変更はパイプラインを滞らせ、ひいてはバックアップおよびその後の取戻し作業につながる。したがって、これらの過渡事象は派生信号に現れる。

【0049】

図４は、オートチューニングリソース割当てのための処理５００の例のフローチャートである。処理５００は、例えば、高度に分散されたコンピューティング環境１００の要素によって実行され得る。したがって、一例として、高度に分散されたコンピューティング環境１００を参照して処理５００を説明する。しかしながら、処理５００または他の同様の処理を実行するために、他の要素を用いてもよい。

【0050】

処理５００は、複数の処理リソースを含むコンピュータシステムにおいて、データストリームを入力として受信するジョブを実行すること（５０２）を含む。データストリーム内のデータ量は、無限である。例えば、分散処理システムマネージャ１１０は、外部のユーザからジョブを受信し得る。このジョブは、例えば、入力データとして用いられる、ストリーミングデータプロバイダ１０６からの１つ以上の入力ソースのための命令を含み得る。高度に分散されたコンピューティング環境１００は、データプロセッサ１１４および／またはネットワーク記憶装置１０８のディスクを１つ以上のワーカー１１３に割当てることによって、または割当てるようにワーカーマネージャ１１２に命令することによって、および、これらの１つ以上のワーカー１１３をジョブに割当てることによって、ジョブを実行し得る。このようなジョブへの初期割当ては、技術的に適当な任意の要因に基づいて設定され得る。これらの要因には、ジョブ１１１の過去の実行、利用可能なシステムリ
ソース、または他の要因が含まれるが、それらに限定されない。

【0051】

処理５００は、ジョブについて、バックログ増大５０４、バックログ量５０６、および、割当てを調整するか否か５０８を繰り返し判定することを含む。

【0052】

ジョブについてバックログ増大５０４を繰り返し判定することは、ジョブに入力される受信されたデータストリームにおける未処理データの増大量であるバックログ増大を、第１の期間にわたって判定することを含む。例えば、ジョブ１１１が実行される際に、ジョブ１１１はストリーミングデータプロバイダ１０６から入力を受信する。この入力は、ジョブ１１１がデータのうちのより多くを受付けて処理することが可能になるまで、キューまたはバッファのような適切なストレージ構造に格納され得る。このため、データの受信と同じ速度でジョブ１１１がデータを処理することができない場合には、経時的にバックログ増大が発生または追加され得る。データがストレージ構造に受信されるよりも速い速度でジョブ１１１がデータを処理可能である場合には、バックログ増大が低減され得る。いずれの場合にも、増大の変化または無変化が監視され得る。このバックログ増大は、例えば、データサイズ（すなわち、ビット、バイト、メガバイト、ギガバイト、レコード、基数）の変化、処理時間（すなわち、マイクロ秒、秒、分、時間、日、ＭＢ／ｓ）、またはその他の観点で測定され得る。

【0053】

ジョブについてバックログ量５０６を繰り返し判定することは、ジョブに入力される受信されたデータストリームにおける未処理データの量であるバックログ量を判定することを含む。記載したように、ジョブ１１１による処理待ちのデータは、バックログと呼ばれ得る。このバックログは、例えば、データサイズ（すなわち、ビット、バイト、メガバイト、ギガバイト、レコード、基数）、処理時間（すなわち、マイクロ秒、秒、分、時間、日）、またはその他の観点で測定され得る。

【0054】

ジョブについて割当てを調整するか否か５０８を繰り返し判定することは、バックログ増大およびバックログ量に基づいて、ジョブに割当てる処理リソースの量を調整するか否かを判定することを含む。以下の処理６００の例でさらに説明するように、バックログ増大およびバックログ量の状態を過剰供給または過少供給の指標として用いることにより、より少ない、またはより多いリソースの割当てが可能になり、または望まれ得る。

【0055】

ジョブに割当てる処理リソースの量を調整すると判定された繰り返し毎に、ジョブに割当てる処理リソースの量が調整される（５１０）。例えば、ネットワークリソースがジョブ１１１に対して過剰供給された場合には、それらは削減され得る。ネットワークリソースが過少供給された場合には、それらは増加され得る。

【0056】

ジョブに割当てる処理リソースの量を調整しないと判定された繰り返し毎に、ジョブに割当てる処理リソースの量が維持される（５１２）。例えば、ネットワークリソースが過剰供給でも過少供給でもない場合には、同一またはほぼ同一レベルのネットワークリソースがジョブ１１１に供給され得る。このことは、全く同一のリソースが引続き供給されることを含んでもよいし、または、異なるリソースが同程度に供給されることを含んでもよい。

【0057】

他の処理例は、異なる数、種類、および順序の要素を含んでもよい。例えば、バックログ増大およびバックログ量に加えて、平均プロセッサ使用率が判定されてもよい。この例では、ジョブに割当てる処理リソースの量を調整するか否かを繰り返し判定することは、さらにプロセッサ使用率に基づく。プロセッサ使用率（例えば、使用される仮想マシンの平均）がある値未満である場合に、システムは、ジョブに割当てる処理リソースの量を調整すると判定し得る。例えば、プロセッサ使用率がある値未満である場合に、システムは
、プロセッサ値がある値未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定してもよい。次いで、システムは、ジョブに割当てる処理リソースの量を調整し得る。これは、プロセッサ値がある値未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を削減することを含む。例えば、多くのワーカーのプロセッサのプロセッサ使用率が低い場合には、これは過剰供給を示すものとして解釈され、システムは割当てリソースを削減することによって割当てリソースをオートチューニングし得る。

【0058】

図５は、リソース割当てを増加するか削減するかを判定するための処理６００の例のフローチャートである。処理６００は、例えば、高度に分散されたコンピューティング環境１００の要素によって実行され得る。処理６００は、例えば、処理５００の実行の一部として実行されてもよい。しかしながら、他の要素を用いて、処理６００または他の同様の処理を、処理５００の一部として、または処理５００の一部としてではなく実行してもよい。

【0059】

ジョブに割当てる処理リソースの量が維持され得る（６０６）。例えばバックログ増大が負またはゼロであると判定され（例えば、ゼロ、ゼロの閾値の範囲内）、かつ、バックログ量が目標値（例えば、目標と同一、目標の閾値の範囲内）であると判定された場合には、これは、割当てリソースが過剰供給にならずに、なおかつ、ジョブによる入力データの処理を可能にするには十分であることを示し得る。

【0060】

ジョブに割当てる処理リソースの量が削減され得る（６０８）。例えば、バックログ増大が負またはゼロであり、かつ、バックログ量が目標未満であると判定された場合には、バックログは、場合によっては目標に近づくまで、または目標に到達するまで増大し得る。

【0061】

ジョブに割当てる処理リソースの量が増加され得る（６１０）。例えば、バックログ増大がゼロであり、かつ、バックログ量が目標と等しいと判定された場合には、バックログを場合によっては目標に近づくまで、または目標に到達するまで減少させるために、追加のリソースが割当てられ得る。

【0062】

ジョブに割当てる処理リソースの量が維持され得る（６１２）。例えば、バックログ増大が正であり、かつ、バックログ量が目標未満であると判定された場合には、バックログは、場合によっては目標に近づくまで、または目標に到達するまで増大し得る。

【0063】

ジョブに割当てる処理リソースの量が増加され得る（６１４）。例えば、バックログ増大が正であり、かつ、バックログ量が目標以上であると判定された場合には、バックログ増大が停止または逆転するように、追加のリソースがジョブに割当てられ得る。

【0064】

他の処理例は、異なる数、種類、および順序の要素を含んでもよい。
図６Ａ、図６Ｂ、図６Ｃは、タスクのセットアップ、サイズ変更、および休止のための処理例のフローチャートである。

【0065】

初期スタートアップ７００の時に、ストリーミングロードバランサは、ワーカーがどの範囲を有しているか、どのディスクをマウントすべきかをワーカーに伝えるとともに、正しいワーカーにデータディスクを装着するように調整する役割を担い得る。サイズ変更時には、ロードバランサはワーカーに、特定の範囲での動作を停止し、対応のディスクをアンマウントし、ディスクを取外し、ディスクを再び装着し、すべてのワーカーについて新たなトポロジセットアップタスクを生成し、新たな開始計算タスクを生成するように伝え得る。

【0066】

ストリーミングロードバランサは、スモールステップ（small step）実行インスタンスを用いて、ワーカーと対話する。これらは、ストリーミングロードバランサがワーカーとの対話を要する際にトリガされる。これらのステップの結果、ストリーミングロードバランサが、開始したステップが終了したことを知るために使う特殊ディスク移行アップデート結果が生成され得る。ストリーミングロードバランサがディスク移行アップデートを受信した後、ストリーミングロードバランサは、すべてのワーカーに、新たなディスク割当ての新たなセットアップ（トポロジ）タスクを発行し得る。

【0067】

初期スタートアップ７０２。ストリーミングロードバランサは、最初に、トポロジおよびディスク割当てを含むタスクセットアップメッセージを各ワーカーに送信する。初期セットアップタスクはワーカー毎にディスクを含み得るが、システムは、初期セットアップタスクのディスク割当てを送信しないことを決定し得る。これにより、ワーカーが未装着のディスクをマウントしようとすることを防止することができる。ワーカーはこのセットアップタスクを要求し得るが、それが最初であるために、ワーカーがディスクをマウントしようとしてもセットアップタスクにディスクが現れないことがある。その場合、システムにエラーが生じ得る。

【0068】

次いで、ストリーミングロードバランサはディスク装着７０４を開始し得る。第１のステップは、ステップ入力でトポロジが与えられている場合、すべてのワーカーへのディスク装着を行ない得る。例えばすべてのディスクが装着されると、すべてのワーカーについてのストリーミング計算タスクを生成する後続の計算開始がトリガされ、どのディスクを装着すべきであるかをそれらのワーカーに伝える。このステップは、これらすべてのタスクが完了状態となるまで待ってもよい。ワーカーはこれらの計算タスクを要求し、ディスクのマウントを試み、関連付けられた範囲の要求を開始し得る。その時点で、ワーカーは７０６の動作を開始し得る。

【0069】

すべてのストリーミング計算タスクが完了したことをシステムが検知すると、ディスク移行アップデート７０８は、すべてが完了したことをストリーミングロードバランサに伝え始めてもよい。ストリーミングロードバランサは、ディスク移行アップデートを監視し、すべての既存のセットアップタスクをキャンセルするとともに、最終的なディスク割当てを含むすべてのワーカーに新たなセットアップタスクを送出し得る。

【0070】

タスクセットアップメッセージリース（１ｓ）の次のアップデート時のワーカーは、セットアップタスクを手放し、新たなセットアップタスクを探し得る。しかしながら、ワーカーが既にマウントされた正しいディスクを有していると想定した場合、ワーカーの最初のものではないため、ワーカーは、必ずしも新たなセットアップタスクのディスクに働きかけるとは限らない。

【0071】

サイズ変更（例えば、ディスク移動）７１０。少なくとも、サイズ拡大およびサイズ縮小の２つの場合があり得る。それらはともにプロトコルの同一または類似のステップで対処され得る。その例が以下のものである。新たなワーカーのための新たな空のセットアップタスクが送出される（サイズ縮小では無し）（７１２）。これらは、最初はディスクを含まない。新たなワーカーがこれらの空のセットアップタスクを要求するのを待つ（既存のストリーミングの停止を早めすぎないため）。サイズ縮小では待つことは不要であり得る。ディスクを失うすべてのワーカーに停止計算タスク７１２を送信し、それらすべてが完了するまで待つ。ディスク取外し７１４ステップを行なう。ディスク装着７１６ステップを行なう。ディスクを得るすべてのワーカーに開始計算７１８タスクを送信し、それらすべてが完了するまで待つ。すべての既存のセットアップタスクをキャンセルし、すべてのワーカーに新たな最終セットアップ７２０タスクを送出する。ストリーミングロードバ
ランサと上述のミニワークフローステップとの間の組織化は、初期セットアップ時と同じ方法で行なわれ得る。すなわち、最後のステップが完了した後、ストリーミングロードバランサが新たな最終セットアップタスクを送出する前に使うディスク移行アップデート結果が生成され得る。

【0072】

休止７４０。ワークフローを休止するために、休止パラメータが初期化され得る（７４２）。ワーカーによる計算の休止が開始され得る（７０４）。いくつかまたはすべてのワーカーからディスクが取外され得る（７０６）。ディスク移行アップデート７０８が完了し得る。

【0073】

処理７００、７１０、および７４０を特定の数、順序、および種類の動作によって説明したが、他のものも可能である。例えば、他の処理を以下で説明する。この処理では、システムが開始計算タスクおよび停止計算タスクを送出するのと同時に、システムが新たなセットアップタスクを送出し得る。それにより、ワーカー挙動が障害に対して冪等となる。各ディスク移行には、少なくとも３種類のワーカーがあり得る。すなわち、ディスクを失うワーカー、ディスクを得るワーカー、および、同じディスクを保持するワーカーである。テストのために、システムは、ディスクを得るワーカーとディスクを失うワーカーとの第４の組み合わせをサポートし得る。

【0074】

いずれかのディスクを失うワーカーは、同時にタスクを得てもよく、ワーカーが失ったディスクをもはや含まない新たなセットアップタスクを得る必要がある。加えて、ワーカーが次のタスクのディスクを得る場合、その時点で送出されたセットアップタスクは、ワーカーが既に有していないディスクを含まない場合がある。したがって、ワーカーがクラッシュした場合、ワーカーは手放している、または手放したばかりのディスクのマウントを試みるとは限らないし、まだ受取っていないディスクのマウントを試みるとは限らない。ワーカーが当該ワーカーのディスクを首尾よくアンマウントした場合、ワーカーは望ましい状態となり得る。そうでなければ、ワーカーはアンマウントを再び要求および実行し得る。それが既に行なわれていた場合、ｎｏｏｐとなり得る。ワーカーがクラッシュおよび再始動する場合、ワーカーはこのラウンドで保持するディスクのみをマウントする（失うことも得ることもない）。

【0075】

ディスクを得るワーカーは、開始計算タスクを得ると同時に新たなセットアップタスクを得てもよい。ワーカーがクラッシュした場合、ワーカーは、開始計算タスクを完了したか否かにかかわらず、再始動時に新たなディスクをマウントし得る。また、ワーカーがいくつかのディスクを既にマウントしている場合には、再度のマウントは冪等となり得て、問題を生じさせない。同じディスクを保持するワーカーは、移行時にいつでも新たなセットアップタスクを与えられ得る。システムは、停止計算の時点、すなわち、既存のトポロジによっていくつかのワーカーが動作を停止しなければならない第１の時点で、これらのワーカーのための新たなセットアップタスクを生成し得る。

【0076】

初期始動。初期始動時、システムは、もはや初期セットアップタスクを送出しない。代わりに、システムはディスクを装着し、次いで、すべての最終セットアップタスクを開始計算ステップの一部として送出する。これによって競合が調整され、スタートアップ時間が改善される。なぜなら、放棄するセットアップタスク、再要求するセットアップタスクがないからである。

【0077】

サイズ変更（移行）。サイズ拡大時、システムは、ディスクを有効なワーカーから移行させる前に、新たな仮想マシンが使用可能になるまで待たなければならない。したがって、システムは、新たなワーカーのための初期セットアップタスクを、フラグセットとともに依然として送出する（割当てられていないディスクがないため、それらはその時点で実
際にはディスクを含まない）。新たなワーカーは最初は空のセットアップタスクを得てもよいが、そうすると、それらが使用可能になるまで待つことになる。

【0078】

その後、ディスクを失う既存のワーカーのために、当該ワーカーの新たなセットアップタスク（および既存のセットアップタスクのキャンセル）とともに停止計算タスクが送出される。同時に、システムは、ディスクを得ることも失うこともないワーカーのために、すべてのセットアップタスクを送出し得る。すべての停止計算タスクが完了すると、ディスクが取外され、次いで装着される。最後に、ディスクを得るワーカーのために、新たなセットアップタスク（および既存のセットアップタスクのキャンセル）とともに、新たな開始計算タスクが送出される。

【0079】

次いで、新たなワーカーは、最終的なディスク割当てを含む新たなセットアップタスク、または開始計算タスクをまず確認する。いずれの場合にも、ワーカーはその時点で有しているディスクをマウントし得る。その時間前後にワーカーがクラッシュした場合にも、ワーカーは当該新たな目標状態となり得る。

【0080】

休止。休止時には、システムは、既存のセットアップタスクのキャンセル、およびディスク割当てを含まない新たなセットアップタスクとともに、停止計算タスクをすべての仮想マシンに送出する（したがって、クラッシュの場合には、ワーカーは、手放した可能性のあるディスクのマウントを試みない）。ディスクが取外される。

【0081】

ワーカーから当該ワーカーのセットアップタスクまでのマップを計算することが有用であり得る。このマップは、独自の入れ子型トランザクションを有する停止計算ステップおよび開始計算ステップの際に修正されるため、ストリーミングロードバランサにおいて行なわれていたように一貫してこのマップを維持することはできない。その代わりに、これらのステップの結果キャッシュを用いて、オンデマンド式でマップを計算する。これにより、すべての打ち切られたタスクおよび完了したタスクに関する古い呼出し結果を削除する機会も提供される。

【0082】

このマップは、新たなセットアップタスクを送出して、当該ワーカーのための既存のセットアップタスク（もしあれば）をキャンセルするたびに計算および参照され得る。これは、停止計算ステップ時または開始計算ステップ時、および、サイズ縮小または休止の後に行なわれる。

【0083】

加えて、ジョブ処理の通信は、システムが利用可能な情報のうちのすべてではなく一部を用いて、ユーザに伝達され得る。以下は、使用されるいくつかの詳細例である。

【0084】

図７は、本明細書に記載の技術を実現するために用いられ得るコンピューティングデバイス８００およびモバイルコンピューティングデバイス８５０の例を示す。コンピューティングデバイス８００は、ラップトップ、デスクトップ、ワークステーション、携帯情報端末、サーバ、ブレードサーバ、メインフレーム、および他の適切なコンピュータなどの、さまざまな形態のデジタルコンピュータを表わすことを意図している。モバイルコンピューティングデバイス８５０は、携帯情報端末、セルラー電話、スマートフォン、および他の同様のコンピューティングデバイスなどの、さまざまな形態のモバイルデバイスを表わすことを意図している。ここに示すコンポーネント、それらの接続および関係、ならびにそれらの機能は例示であることが意図されているに過ぎず、限定することを意図していない。

【0085】

コンピューティングデバイス８００は、プロセッサ８０２、メモリ８０４、記憶装置８０６、メモリ８０４および複数の高速拡張ポート８１０に接続している高速インターフェ
イス８０８、ならびに低速拡張ポート８１４および記憶装置８０６に接続している低速インターフェイス８１２を含む。プロセッサ８０２、メモリ８０４、記憶装置８０６、高速インターフェイス８０８、高速拡張ポート８１０、および低速インターフェイス８１２の各々はさまざまなバスを用いて相互に接続されており、共通のマザーボード上にまたは他の態様で適宜搭載され得る。プロセッサ８０２は、コンピューティングデバイス８００内で実行される命令を処理可能であり、この命令には、ＧＵＩのためのグラフィック情報を高速インターフェイス８０８に結合されているディスプレイ８１６などの外部入出力デバイス上に表示するためにメモリ８０４内または記憶装置８０６上に記憶されている命令が含まれる。他の実現例では、複数のプロセッサおよび／または複数のバスが、複数のメモリおよび複数種類のメモリとともに必要に応じて用いられ得る。また、複数のコンピューティングデバイスが接続され得て、各デバイスは（例えば、サーババンク、ブレードサーバ群、またはマルチプロセッサシステムとして）必要な動作の一部を提供する。

【0086】

メモリ８０４は情報をコンピューティングデバイス８００内に記憶する。いくつかの実現例では、メモリ８０４は１つまたは複数の揮発性メモリユニットである。いくつかの実現例では、メモリ８０４は１つまたは複数の不揮発性メモリユニットである。また、メモリ８０４は、磁気ディスクまたは光ディスクなどの別の形態のコンピュータ読取可能媒体であってもよい。

【0087】

記憶装置８０６は、コンピューティングデバイス８００に大容量記憶を提供可能である。いくつかの実現例では、記憶装置８０６は、フロッピー（登録商標）ディスクデバイス、ハードディスクデバイス、光ディスクデバイス、またはテープデバイス、フラッシュメモリもしくは他の同様のソリッドステートメモリデバイス、またはストレージエリアネットワークもしくは他のコンフィギュレーションにおけるデバイスを含む一連のデバイスなどの、コンピュータ読取可能媒体であってもよく、または当該コンピュータ読取可能媒体を含んでいてもよい。命令が情報媒体内に記憶され得る。命令は、１つ以上の処理装置（例えば、プロセッサ８０２）によって実行されると、上述のような１つ以上の方法を実行する。また、命令は、コンピュータ読取可能媒体または機械読取可能媒体（例えば、メモリ８０４、記憶装置８０６、またはプロセッサ８０２上のメモリ）などの１つ以上の記憶装置によって記憶され得る。

【0088】

高速インターフェイス８０８はコンピューティングデバイス８００のための帯域幅集約的な動作を管理するのに対して、低速インターフェイス８１２はより低い帯域幅集約的な動作を管理する。そのような機能の割当ては例示に過ぎない。いくつかの実現例では、高速インターフェイス８０８はメモリ８０４、ディスプレイ８１６に（例えばグラフィックスプロセッサまたはアクセラレータを介して）、およびさまざまな拡張カード（図示せず）を受付け得る高速拡張ポート８１０に結合される。当該実現例では、低速インターフェイス８１２は記憶装置８０６および低速拡張ポート８１４に結合される。さまざまな通信ポート（例えばＵＳＢ、ブルートゥース（登録商標）、イーサネット（登録商標）、無線イーサネット）を含み得る低速拡張ポート８１４は、キーボード、ポインティングデバイス、スキャナ、またはスイッチもしくはルータといったネットワーキングデバイスなどの１つ以上の入出力デバイスに、例えばネットワークアダプタを介して結合され得る。

【0089】

コンピューティングデバイス８００は、図に示すように多数の異なる形態で実現されてもよい。例えば、コンピューティングデバイス８００は標準的なサーバ８２０として、またはそのようなサーバ群内で複数回実現されてもよい。さらに、コンピューティングデバイス８００はラップトップコンピュータ８２２などのパーソナルコンピュータにおいて実現されてもよい。また、コンピューティングデバイス８００はラックサーバシステム８２４の一部として実現されてもよい。あるいは、コンピューティングデバイス８００からのコンポーネントは、モバイルコンピューティングデバイス８５０などのモバイルデバイス
（図示せず）内の他のコンポーネントと組み合わされてもよい。そのようなデバイスの各々が１つ以上のコンピューティングデバイス８００およびモバイルコンピューティングデバイス８５０を含んでいてもよく、システム全体が、互いに通信する複数のコンピューティングデバイスで構成されてもよい。

【0090】

モバイルコンピューティングデバイス８５０は、数あるコンポーネントの中でも特に、プロセッサ８５２、メモリ８６４、ディスプレイ８５４などの入出力デバイス、通信インターフェイス８６６、およびトランシーバ８６８を含む。また、モバイルコンピューティングデバイス８５０には、マイクロドライブまたは他のデバイスなどの記憶装置が提供されて付加的なストレージが提供されてもよい。プロセッサ８５２、メモリ８６４、ディスプレイ８５４、通信インターフェイス８６６、およびトランシーバ８６８の各々はさまざまなバスを用いて相互に接続されており、当該コンポーネントのいくつかは共通のマザーボード上にまたは他の態様で適宜搭載され得る。

【0091】

プロセッサ８５２は、メモリ８６４に記憶されている命令を含む、モバイルコンピューティングデバイス８５０内の命令を実行可能である。プロセッサ８５２は、別個の複数のアナログおよびデジタルプロセッサを含むチップのチップセットとして実現されてもよい。プロセッサ８５２は、例えば、ユーザインターフェイス、モバイルコンピューティングデバイス８５０が実行するアプリケーション、およびモバイルコンピューティングデバイス８５０による無線通信の制御などの、モバイルコンピューティングデバイス８５０の他のコンポーネントの協調を提供し得る。

【0092】

プロセッサ８５２は、制御インターフェイス８５８と、ディスプレイ８５４に結合されたディスプレイインターフェイス８５６とを介してユーザと通信し得る。ディスプレイ８５４は、例えば、ＴＦＴ（薄膜トランジスタ）液晶ディスプレイもしくはＯＬＥＤ（有機発光ダイオード）ディスプレイ、または他の適切なディスプレイ技術であり得る。ディスプレイインターフェイス８５６は、ディスプレイ８５４を駆動してグラフィックおよび他の情報をユーザに提示するための適切な回路を含み得る。制御インターフェイス８５８はユーザからコマンドを受信し、当該コマンドをプロセッサ８５２に提出するために変換し得る。さらに、外部インターフェイス８６２が、モバイルコンピューティングデバイス８５０と他のデバイスとの隣接通信を可能にするために、プロセッサ８５２との通信を提供してもよい。外部インターフェイス８６２は、例えば、ある実現例では有線通信を提供し、他の実現例では無線通信を提供してもよく、また、複数のインターフェイスが用いられてもよい。

【0093】

メモリ８６４は情報をモバイルコンピューティングデバイス８５０内に記憶する。メモリ８６４は、１つもしくは複数のコンピュータ読取可能媒体、１つもしくは複数の揮発性メモリユニット、または１つもしくは複数の不揮発性メモリユニットの１つ以上として実現され得る。さらに、拡張メモリ８７４が提供され、例えばＳＩＭＭ（Single In Line Memory Module）カードインターフェイスを含み得る拡張インターフェイス８７２を介してモバイルコンピューティングデバイス８５０に接続されてもよい。このような拡張メモリ８７４はモバイルコンピューティングデバイス８５０に余分のストレージスペースを提供し得るか、またはモバイルコンピューティングデバイス８５０のためのアプリケーションもしくは他の情報をさらに記憶し得る。具体的には、拡張メモリ８７４は上述のプロセスを実行または補足するための命令を含み得て、さらにセキュア情報を含み得る。ゆえに、例えば、拡張メモリ８７４はモバイルコンピューティングデバイス８５０のためのセキュリティモジュールとして提供されてもよく、モバイルコンピューティングデバイス８５０のセキュアな使用を許可する命令でプログラムされてもよい。さらに、ハッキング不可能なようにＳＩＭＭカード上に識別情報を置くなどのように、セキュアなアプリケーションが付加的な情報とともにＳＩＭＭカードを介して提供されてもよい。

【0094】

メモリは、以下に記載のように、例えばフラッシュメモリおよび／またはＮＶＲＡＭメモリ（不揮発性ランダムアクセスメモリ）を含み得る。いくつかの実現例では、命令が情報媒体内に記憶される。命令は、１つ以上の処理装置（例えば、プロセッサ８５２）によって実行されると、上述のような１つ以上の方法を実行する。また、命令は、１つ以上のコンピュータ読取可能媒体または機械読取可能媒体（例えば、メモリ８６４、拡張メモリ８７４、またはプロセッサ８５２上のメモリ）などの１つ以上の記憶装置によって記憶され得る。いくつかの実現例では、命令は伝搬信号で、例えばトランシーバ８６８または外部インターフェイス８６２上で受信され得る。

【0095】

モバイルコンピューティングデバイス８５０は、必要に応じてデジタル信号処理回路を含み得る通信インターフェイス８６６を介して無線通信し得る。通信インターフェイス８６６は、とりわけ、ＧＳＭ（登録商標）音声通話（Global System for Mobile communications）、ＳＭＳ（ショートメッセージサービス：Short Message Service）、ＥＭＳ（Enhanced Messaging Service）、またはＭＭＳ（マルチメディア・メッセージングサービス：Multimedia Messaging Service）メッセージング、ＣＤＭＡ（符号分割多元接続：code
division multiple access）、ＴＤＭＡ（時分割多元接続：time division multiple access）、ＰＤＣ（Personal Digital Cellular）、ＷＣＤＭＡ（登録商標、Wideband Code
Division Multiple Access）、ＣＤＭＡ２０００、またはＧＰＲＳ（General Packet Radio Service）などの、さまざまなモードまたはプロトコル下の通信を提供し得る。その
ような通信は、例えば無線周波数トランシーバ８６８を介して起こり得る。さらに、ブルートゥース、Ｗｉ−Ｆｉ、または他のそのようなトランシーバ（図示せず）を用いるなどして、短距離通信が起こり得る。さらに、ＧＰＳ（全地球測位システム）レシーバモジュール８７０が付加的なナビゲーション関連および位置関連の無線データをモバイルコンピューティングデバイス８５０に提供し得て、当該データはモバイルコンピューティングデバイス８５０上で実行されるアプリケーションによって適宜用いられ得る。

【0096】

また、モバイルコンピューティングデバイス８５０は、ユーザから口頭情報を受信して当該情報を使用可能なデジタル情報に変換し得る音声コーデック８６０を用いて可聴的に通信し得る。音声コーデック８６０も同様に、例えばモバイルコンピューティングデバイス８５０のハンドセット内で、スピーカを介すなどしてユーザに可聴音を生成し得る。そのような音は音声電話からの音を含んでいてもよく、録音された音（例えば音声メッセージ、音楽ファイル等）を含んでいてもよく、さらに、モバイルコンピューティングデバイス８５０上で実行されるアプリケーションが生成する音を含んでいてもよい。

【0097】

モバイルコンピューティングデバイス８５０は、図に示すように多数の異なる形態で実現されてもよい。例えば、モバイルコンピューティングデバイス８５０はセルラー電話８８０として実現されてもよい。また、モバイルコンピューティングデバイス８５０は、スマートフォン８８２、携帯情報端末、または他の同様のモバイルデバイスの一部として実現されてもよい。

【0098】

本明細書に記載のシステムおよび技術のさまざまな実現例は、デジタル電子回路、集積回路、特別に設計されたＡＳＩＣ（特定用途向け集積回路）、コンピュータハードウェア、ファームウェア、ソフトウェア、および／またはそれらの組み合わせで実現され得る。これらのさまざまな実現例は、少なくとも１つのプログラマブルプロセッサを含むプログラマブルシステム上で実行可能および／または解釈可能な１つ以上のコンピュータプログラムにおける実現例を含んでいてもよく、当該プロセッサは専用であっても汎用であってもよく、ストレージシステム、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスからデータおよび命令を受信するように、かつこれらにデータおよび命令を送信するように結合されている。

【0099】

これらのコンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーションまたはコードとしても公知）はプログラマブルプロセッサのための機械命令を含んでおり、高レベル手続き言語および／もしくはオブジェクト指向プログラミング言語で、ならびに／またはアセンブリ言語／機械言語で実現され得る。本明細書において使用する「機械読取可能媒体」および「コンピュータ読取可能媒体」という用語は、機械命令および／またはデータをプログラマブルプロセッサに提供するために用いられる任意のコンピュータプログラムプロダクト、装置および／またはデバイス（例えば磁気ディスク、光ディスク、メモリ、プログラマブルロジックデバイス（ＰＬＤ））を指し、機械命令を機械読取可能信号として受信する機械読取可能媒体を含む。「機械読取可能信号」という用語は、機械命令および／またはデータをプログラマブルプロセッサに提供するために用いられる任意の信号を指す。

【0100】

ユーザとの対話を提供するために、本明細書に記載のシステムおよび技術は、情報をユーザに表示するためのディスプレイデバイス（例えばＣＲＴ（陰極線管）またはＬＣＤ（液晶ディスプレイ）モニタ）と、ユーザが入力をコンピュータに提供する際に使用可能なキーボードおよびポインティングデバイス（例えばマウスまたはトラックボール）とを有するコンピュータ上で実現され得る。他の種類のデバイスを用いてユーザとの対話を提供することもでき、例えば、ユーザに提供されるフィードバックは任意の形態の感覚フィードバック（例えば視覚フィードバック、聴覚フィードバック、または触覚フィードバック）であり得て、ユーザからの入力は、音響入力、スピーチ入力、または触覚入力を含む任意の形態で受信され得る。

【0101】

本明細書に記載のシステムおよび技術は、バックエンドコンポーネントを（例えばデータサーバとして）含む、またはミドルウェアコンポーネント（例えばアプリケーションサーバ）を含む、またはフロントエンドコンポーネント（例えば、ユーザが上記のシステムおよび技術の実現例と対話する際に使用可能なグラフィックユーザインターフェイスもしくはウェブブラウザを有するクライアントコンピュータ）、またはそのようなバックエンド、ミドルウェア、もしくはフロントエンドコンポーネントの任意の組み合わせを含むコンピューティングシステムにおいて実現され得る。システムのコンポーネントは、任意の形態または媒体のデジタルデータ通信（例えば通信ネットワーク）によって相互に接続され得る。通信ネットワークの例として、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、およびインターネットが挙げられる。

【0102】

コンピューティングシステムはクライアントおよびサーバを含み得る。クライアントおよびサーバは一般に互いにリモートであり、典型的には通信ネットワークを介して対話する。クライアントとサーバとの関係は、それぞれのコンピュータ上で実行されて互いにクライアント−サーバ関係を有するコンピュータプログラムによって生じる。

【0103】

その他の実現例を以下の例において要約する。
例１：コンピュータシステムにおいて実現される方法であって、複数の処理リソースを備えるコンピュータシステムにおいて、データストリームを入力として受信するジョブを実行するステップを備え、データストリーム内のデータ量は、無限であり、ジョブについて、ジョブに入力される受信されたデータストリームにおける未処理データの増大量である、第１の期間にわたるバックログ増大と、ジョブに入力される受信されたデータストリームにおける未処理データの量であるバックログ量と、バックログ増大およびバックログ量に基づいて、ジョブに割当てる処理リソースの量を調整するか否か、とを繰り返し判定するステップと、ジョブに割当てる処理リソースの量を調整すると判定された繰り返し毎に、ジョブに割当てる処理リソースの量を調整するステップと、ジョブに割当てる処理リソースの量を調整しないと判定された繰り返し毎に、ジョブに割当てる処理リソースの量
を維持するステップとを含む、方法。

【0104】

例２：例１の方法において、判定の繰り返しについて、バックログ増大はゼロまたは負であると判定され、バックログ量は目標と等しいと判定され、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標と等しいと判定されたことに応答して、ジョブに割当てる処理リソースの量を調整しないと判定される。

【0105】

例３：例１または例２の方法において、判定の繰り返しについて、バックログ増大はゼロまたは負であると判定され、バックログ量は目標未満であると判定され、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を削減するステップを含む。

【0106】

例４：例１〜例３のうちの１つの例の方法において、判定の繰り返しについて、バックログ増大はゼロまたは負であると判定され、バックログ量は目標よりも大きいと判定され、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標よりも大きいと判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標よりも大きいと判定されたことに応答して、ジョブに割当てる処理リソースの量を増加させるステップを含む。

【0107】

例５：例１〜例４のうちの１つの例の方法において、判定の繰り返しについて、バックログ増大は正であると判定され、バックログ量は目標未満であると判定され、バックログ増大が正であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整しないと判定される。

【0108】

例６：例１〜例５のうちの１つの例の方法において、判定の繰り返しについて、バックログ増大は正であると判定され、バックログ量は目標以上であると判定され、バックログ増大が正であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、バックログ増大が正であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を増加させるステップを含む。

【0109】

例７：例１〜例６のうちの１つの例の方法において、バックログ増大はデータサイズの大きさである。

【0110】

例８：例７の方法において、データサイズの単位は、ビット、バイト、メガバイト、ギガバイト、レコード、および基数からなる群のうちの少なくとも１つである。

【0111】

例９：例１〜例６のうちの１つの例の方法において、バックログ増大は処理時間の長さである。

【0112】

例１０：例９の方法において、処理時間の単位は、マイクロ秒、秒、分、時間、および日からなる群のうちの少なくとも１つである。

【0113】

例１１：例１〜例１０のうちの１つの例の方法において、バックログ量はデータサイズの大きさである。

【0114】

例１２：例１１の方法において、データサイズの単位は、ビット、バイト、メガバイト、ギガバイト、レコード、および基数からなる群のうちの少なくとも１つである。

【0115】

例１３：例１〜例１０のうちの１つの例の方法において、バックログ量は処理時間の長さである。

【0116】

例１４：例１３の方法において、処理時間の単位は、マイクロ秒、秒、分、時間、および日からなる群のうちの少なくとも１つである。

【0117】

例１５：例１〜例１４のうちの１つの例の方法において、方法は、ジョブについて、プロセッサ使用率を繰り返し判定するステップをさらに含み、ジョブに割当てる処理リソースの量を調整するか否かを繰り返し判定するステップは、さらにプロセッサ使用率に基づく。

【0118】

例１６：例１５の方法において、判定の繰り返しについて、プロセッサ使用率はある値未満であり、プロセッサ使用率がある値未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、プロセッサ使用率がある値未満であると判定されたことに応答してジョブに割当てる処理リソースの量を削減するステップを含む。

【0119】

例１７：例１６の方法において、プロセッサ使用率がある値未満であると判定されたことに応答してジョブに割当てる処理リソースの量を削減するステップは、ジョブに割当てるリソースの離散数を減少させるステップを含み、離散数はプロセッサ使用率に基づく。

【0120】

例１８：例１７の方法において、離散数はコンピュータメモリディスクの数である。
例１９：例１〜例１８のうちの１つの例の方法において、バックログ増大およびバックログ量に基づいてジョブに割当てる処理リソースの量を調整するか否かを判定するステップは、ジョブに割当てる処理リソースの量の変動を生じさせる判定するステップを平滑化するステップを含む。

【0121】

例２０：例１９の方法において、判定するステップを平滑化するステップは、第２の期間待つステップを含む。

【0122】

例２１：例１９の方法において、判定するステップを平滑化するステップは、ジョブに割当てる処理リソースの量を調整するか否かの複数の判定を平均化するステップを含む。

【0123】

例２２：コンピュータプログラム命令を実行するように構成された１つ以上のプロセッサと、コンピュータプログラム命令が符号化されたコンピュータ記憶媒体とを備え、コンピュータプログラム命令は、１つ以上のプロセッサによって実行されると、コンピュータデバイスに、複数の処理リソースを備えるコンピュータシステムにおいて、データストリームを入力として受信するジョブを含む演算を行わせ、データストリーム内のデータ量は、無限であり、ジョブについて、ジョブに入力される受信されたデータストリームにおける未処理データの増大量である、第１の期間にわたるバックログ増大と、ジョブに入力される受信されたデータストリームにおける未処理データの量であるバックログ量と、バックログ増大およびバックログ量に基づいて、ジョブに割当てる処理リソースの量を調整するか否か、とを繰り返し判定するステップと、ジョブに割当てる処理リソースの量を調整すると判定された繰り返し毎に、ジョブに割当てる処理リソースの量を調整するステップと、ジョブに割当てる処理リソースの量を調整しないと判定された繰り返し毎に、ジョブに割当てる処理リソースの量を維持するステップとを含む演算を行なわせる、システム。

【0124】

例２３：例２２のシステムにおいて、判定の繰り返しについて、バックログ増大はゼロまたは負であると判定され、バックログ量は目標と等しいと判定され、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標と等しいと判定されたことに応答して、ジョブに割当てる処理リソースの量を調整しないと判定される。

【0125】

例２４：例２２または例２３のシステムにおいて、判定の繰り返しについて、バックログ増大はゼロまたは負であると判定され、バックログ量は目標未満であると判定され、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を削減するステップを含む。

【0126】

例２５：例２２〜例２４のうちの１つの例のシステムにおいて、判定の繰り返しについて、バックログ増大はゼロまたは負であると判定され、バックログ量は目標よりも大きいと判定され、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標よりも大きいと判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、バックログ増大がゼロまたは負であると判定され、かつ、バックログ量が目標よりも大きいと判定されたことに応答して、ジョブに割当てる処理リソースの量を増加させるステップを含む。

【0127】

例２６：例２２〜例２５のうちの１つの例のシステムにおいて、判定の繰り返しについて、バックログ増大は正であると判定され、バックログ量は目標未満であると判定され、バックログ増大が正であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整しないと判定される。

【0128】

例２７：例２２〜例２６のうちの１つの例のシステムにおいて、判定の繰り返しについて、バックログ増大は正であると判定され、バックログ量は目標以上であると判定され、バックログ増大が正であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、バックログ増大が正であると判定され、かつ、バックログ量が目標未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を増加させるステップを含む。

【0129】

例２８：例２２〜例２７のうちの１つの例のシステムにおいて、バックログ増大はデータサイズの大きさである。

【0130】

例２９：例２８のシステムにおいて、データサイズの単位は、ビット、バイト、メガバイト、ギガバイト、レコード、および基数からなる群のうちの少なくとも１つである。

【0131】

例３０：例２２〜例２７のうちの１つの例のシステムにおいて、バックログ増大は処理時間の長さである。

【0132】

例３１：例３０のシステムにおいて、処理時間の単位は、マイクロ秒、秒、分、時間、および日からなる群のうちの少なくとも１つである。

【0133】

例３２：例２２〜例３１のうちの１つの例のシステムにおいて、バックログ量はデータサイズの大きさである。

【0134】

例３３：例３２のシステムにおいて、データサイズの単位は、ビット、バイト、メガバイト、ギガバイト、レコード、および基数からなる群のうちの少なくとも１つである。

【0135】

例３４：例２２〜例３１のうちの１つの例のシステムにおいて、バックログ量は処理時間の長さである。

【0136】

例３５：例３４のシステムにおいて、処理時間の単位は、マイクロ秒、秒、分、時間、および日からなる群のうちの少なくとも１つである。

【0137】

例３６：例２２〜例３５のうちの１つの例のシステムにおいて、演算は、ジョブについて、プロセッサ使用率を繰り返し判定するステップをさらに含み、ジョブに割当てる処理リソースの量を調整するか否かを繰り返し判定するステップは、さらにプロセッサ使用率に基づく。

【0138】

例３７：例３６のシステムにおいて、判定の繰り返しについて、プロセッサ使用率はある値未満であり、プロセッサ使用率がある値未満であると判定されたことに応答して、ジョブに割当てる処理リソースの量を調整すると判定され、ジョブに割当てる処理リソースの量を調整するステップは、プロセッサ使用率がある値未満であると判定されたことに応答してジョブに割当てる処理リソースの量を削減するステップを含む。

【0139】

例３８：例３７のシステムにおいて、プロセッサ使用率がある値未満であると判定されたことに応答してジョブに割当てる処理リソースの量を削減するステップは、ジョブに割当てるリソースの離散数を減少させるステップを含み、離散数はプロセッサ使用率に基づく。

【0140】

例３９：例３８のシステムにおいて、離散数はコンピュータメモリディスクの数である。

【0141】

例４０：例２２〜例３９のうちの１つの例のシステムにおいて、バックログ増大およびバックログ量に基づいてジョブに割当てる処理リソースの量を調整するか否かを判定するステップは、ジョブに割当てる処理リソースの量の変動を生じさせる判定するステップを平滑化するステップを含む。

【0142】

例４１：例４０のシステムにおいて、判定するステップを平滑化するステップは、第２の期間待つステップを含む。

【0143】

例４２：例４０または例４１のシステムにおいて、判定するステップを平滑化するステップは、ジョブに割当てる処理リソースの量を調整するか否かの複数の判定を平均化するステップを含む。

【0144】

いくつかの実現例を上記で詳細に説明してきたが、他の変更例も可能である。例えば、クライアントアプリケーションがデリゲートにアクセスするものとして説明したが、他の実現例では、デリゲートは、１つ以上のサーバ上で実行されるアプリケーションなどの、１つ以上のプロセッサによって実現される他のアプリケーションに用いられ得る。また、所望の結果を達成するために、図面に示す論理フローが、図示される特定の順序、または起こる順序を必要とするわけではない。また、記載のフローに他の動作が提供されてもよく、または記載のフローから動作が除去されてもよい。また、記載のシステムに他のコンポーネントが追加されてもよく、または記載のシステムからコンポーネントが除去されてもよい。したがって、他の実現例も以下の請求項の範囲内にある。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図6C】

【図7】