(57)【要約】【課題】コンピュータ環境におけるジョブスケジューリングの方法等を提供する。【解決手段】複数のユーザから受け取られたジョブ依頼に関連する履歴ジョブデータが収集される。履歴ジョブデータは、ジョブを実行するためにユーザによってリクエストされたリソースを示すリソースリクエストデータと、そのジョブを実行するために使用された実際のリソースを示すリソース利用データとを含む。夫々のユーザについて、信憑性スコアが、ユーザから受け取られた１以上のジョブ依頼に関連するリソースリクエストデータとリソース利用データとの間の比較に基づき計算される。信憑性スコアは、ジョブを実行するためにリクエストされるリソースをユーザが過大に見積もる程度を示す。１人のユーザから、実行されるべき新しいジョブと、その新しいジョブを実行するためにユーザによってリクエストされたリソースとを特定する新しいジョブ依頼が受け取られる。そして、ユーザの信憑性スコアに基づき、実行のために新しいジョブがスケジューリングされる。【選択図】図１
2015133112.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ環境におけるジョブスケジューリングの方法であって、
複数のユーザから受け取られたジョブ依頼に関連する履歴ジョブデータを収集し、ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータが、ジョブを実行するために当該ユーザによってリクエストされたリソースを示すリソースリクエストデータと、前記ジョブを実行するために使用された実際のリソースを示すリソース利用データとを含み、
前記複数のユーザの夫々について、当該ユーザから受け取られた１又はそれ以上のジョブ依頼に関連する前記リソースリクエストデータと前記リソース利用データとの間の比較に基づき、ジョブを実行するためにリクエストされるリソースを当該ユーザが過大に見積もる程度を示す信憑性スコアを計算し、
前記複数のユーザの１人から、実行されるべき新しいジョブと、該新しいジョブを実行するために当該ユーザによってリクエストされたリソースとを特定する新しいジョブ依頼を受け取り、
当該ユーザの前記信憑性スコアに基づき、実行のために前記新しいジョブをスケジューリングする、方法。
【請求項２】
実行のために前記新しいジョブをスケジューリングすることは、当該ユーザによってリクエストされたリソースよりも少ないリソースから構成されるバックフィルウィンドウに前記新しいジョブを割り当てることを含む、
請求項１に記載の方法。
【請求項３】
前記バックフィルウィンドウを構成するリソースに対する当該ユーザによってリクエストされたリソースの割合に基づき、前記新しいジョブの利用率を計算し、
実行のために前記新しいジョブをスケジューリングすることは、当該ユーザの前記信憑性スコア及び前記利用率に基づく、
請求項２に記載の方法。
【請求項４】
前記新しいジョブは、履歴データが収集されたことがある以前に実行されたジョブに対応し、
ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータは、前記ジョブを実行することに関連する性能特性を示す性能データを更に含み、
実行のために前記新しいジョブをスケジューリングすることは、当該ユーザの前記信憑性スコア及び前記以前に実行されたジョブの前記性能データに基づく、
請求項１乃至３のうちいずれか一項に記載の方法。
【請求項５】
ジョブは、１又はそれ以上のアプリケーションを含み、前記複数のユーザの夫々についての前記信憑性スコアは、夫々のアプリケーションに関して計算される、
請求項１乃至４のうちいずれか一項に記載の方法。
【請求項６】
前記複数のユーザの夫々についての前記信憑性スコアは、以前に実行されたジョブに実際に使用されたリクエストされたリソースのうちのパーセンテージに基づき計算される、
請求項１乃至５のうちいずれか一項に記載の方法。
【請求項７】
前記新しいジョブ依頼は、前記複数のユーザのうちの２又はそれ以上から受け取られた複数の新しいジョブ依頼のうちの１つであり、
前記新しいジョブは、実行のためにキューにおいて順序付けられ、
実行のために前記新しいジョブをスケジューリングすることは、前記キューにおいてより高いがより低い信憑性スコアを有するユーザによって発せられる少なくとも１つの新しいジョブに対して、前記キューにおいてより低いがより高い信憑性スコアを有するユーザによって発せられる少なくとも１つの新しいジョブを優先することを含む、
請求項１乃至６のうちいずれか一項に記載の方法。
【請求項８】
前記新しいジョブの実行中に、前記割り当てられたリソースは前記ジョブを完了するには不十分であると決定し、前記新しいジョブを終了又は一時中断する、
請求項２乃至７のうちいずれか一項に記載の方法。
【請求項９】
前記新しいジョブの実行後に、前記新しいジョブを実行するために使用された実際のリソースと前記割り当てられたリソースとの間の比較に基づき前記スケジューリングの精度を決定する、
請求項２乃至８のうちいずれか一項に記載の方法。
【請求項１０】
データ解析モジュールを備え、該データ解析モジュールは、
複数のユーザから受け取られたジョブ依頼に関連する履歴ジョブデータにアクセスし、ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータが、ジョブを実行するために当該ユーザによってリクエストされたリソースを示すリソースリクエストデータと、前記ジョブを実行するために使用された実際のリソースを示すリソース利用データとを含み、
前記複数のユーザの夫々について、当該ユーザから受け取られた１又はそれ以上のジョブ依頼に関連する前記リソースリクエストデータと前記リソース利用データとの間の比較に基づき、ジョブを実行するためにリクエストされるリソースを当該ユーザが過大に見積もる程度を示す信憑性スコアを計算する
よう構成される、データアナライザ。
【請求項１１】
前記信憑性スコアに基づきユーザから受け取られた新しいジョブ依頼を変更するよう構成されるジョブ依頼変更モジュール
を更に有する、請求項１０に記載のデータアナライザ。
【請求項１２】
請求項１０又は１１に記載のデータアナライザと、
複数のユーザから受け取られたジョブ依頼に関連する履歴ジョブデータを記憶するよう構成されるデータベースと
を備え、
ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータが、ジョブを実行するために当該ユーザによってリクエストされたリソースを示すリソースリクエストデータと、前記ジョブを実行するために使用された実際のリソースを示すリソース利用データとを含む、データ解析装置。
【請求項１３】
ジョブをスケジューリングするよう構成されるスケジューラと、
請求項１２に記載のデータ解析装置と、
スケジューリングされたジョブを実行するよう構成されるコンピューティングリソースと
を備えるコンピュータシステム。
【請求項１４】
コンピュータによって実行される場合に、該コンピュータに、請求項１乃至９のうちいずれか一項に記載の方法を実行させる
コンピュータ可読コードを担持するコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本願で開示される実施形態は、概して、ジョブスケジューリングに関し、特に、ジョブスケジューリングをバックフィリングすることに関するが、それに限られない。
【背景技術】
【０００２】
ジョブのグループがスケジューリングアルゴリズムに従ってコンピュータ環境における実行のためにスケジューリングされるプロセスは、一般に、バッチスケジューリングと呼ばれる。最も基本的なバッチスケジューリングアルゴリズムは、先着順制（First-Come-First-Served）（ＦＣＦＳ）スケジューリングアルゴリズムである。このアルゴリズムによれば、ジョブは、到着時に先入れ先出し（First  In,  First  Out）（ＦＩＦＯ）キューに置かれる。キューの先頭にあるジョブを実行するために利用可能な十分なリソースが存在する場合は、リソースは割り当てられ、ジョブは開始される。十分なリソースが存在しない場合は、十分なりソースが利用可能になるまで、例えば、現在実行中のジョブが終了するときまで、プロセスは待機する。しかし、このアプローチは、非効率的なシステム利用を欠点とする。
【０００３】
バックフィリングは、利用及びＦＣＦＣ順序の維持の目標を釣り合わせようと試みる最適化技術である。キューの先頭にあるジョブが待機している間、他の、より小さいジョブが、特に、それらがキューの先頭にあるジョブの開始を遅延させない場合に、スケジューリングされることが可能である。これは、さもなければ利用されないままであるリソースが使用されることを可能にする。バックフィルスケジューリングは、一般に、スケジューラがどこにジョブを置くべきかを決定することを可能にするために、ユーザに、彼らのジョブのためのランタイム制限を特定するよう求める。しかし、それらの特定されたランタイムを超えて実行するジョブは、通常は、システムによって終了されるので、ユーザはしばしば、彼らのジョブのランタイムを過大に見積もる。これは、スケジューリングの非効率性及びリソースの浪費を生じさせる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従って、改善されたジョブスケジューリング技術が、コンピュータ産業において歓迎されるであろう。
【課題を解決するための手段】
【０００５】
一実施形態に従って、コンピュータ環境におけるジョブスケジューリングの方法であって、
複数のユーザから受け取られたジョブ依頼に関連する履歴ジョブデータを収集し、ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータが、ジョブを実行するために当該ユーザによってリクエストされたリソースを示すリソースリクエストデータと、前記ジョブを実行するために使用された実際のリソースを示すリソース利用データとを含み、
前記複数のユーザの夫々について、当該ユーザから受け取られた１又はそれ以上のジョブ依頼に関連する前記リソースリクエストデータと前記リソース利用データとの間の比較に基づき、ジョブを実行するためにリクエストされるリソースを当該ユーザが過大に見積もる程度を示す信憑性スコアを計算し、
前記複数のユーザの１人から、実行されるべき新しいジョブと、該新しいジョブを実行するために当該ユーザによってリクエストされたリソースとを特定する新しいジョブ依頼を受け取り、
当該ユーザの前記信憑性スコアに基づき、実行のために前記新しいジョブをスケジューリングする、方法が提供される。
【０００６】
ユーザの信憑性スコアは、そのユーザによってリクエストされたリソースが、ジョブを実行するのに実際に必要とされるリソースを反映するかどうかの有用な推定を提供し、ジョブスケジューリングを改善する簡単だが有効な方法である。更に、信憑性スコアはユーザに関連付けられるので、スケジューリングの改善は、新しいジョブがコンピュータ環境に置いて以前に実行されたジョブと異なる場合でさえ、達成され得る。
【０００７】
信憑性スコアは、例えば、ジョブが、それらのジョブを提示するユーザの信憑性スコアに基づき（少なくともある程度）キュー内で体系化及び／又は優先順位付けされ得る、修正されたＦＩＦＯスケジューリングアルゴリズムを含む異なるスケジューリングアルゴリズムとともに使用され得る。なお、信憑性スコアの使用は、特に、バックフィルスケジューリングにうまく適する。一実施形態において、実行のために前記新しいジョブをスケジューリングすることは、当該ユーザによってリクエストされたリソースよりも少ないリソースから構成されるバックフィルウィンドウに前記新しいジョブを割り当てることを含む。例えば、新しいジョブは、ユーザによってリクエストされたランタイムよりも短いランタイム制限を有するバックフィルウィンドウに割り当てられ得る。信憑性スコアに基づくバックフィルスケジューリングは、ウィンドウが満了する前にジョブが完了され得ない危険性の高まりが最小限でありながら、バックフィルウィンドウに収まり得るジョブの数を増やす。そのようなバックフィルウィンドウに新しいジョブを割り当てる１つの方法は、例えば、特定されたランタイム制限を低減することによって、ジョブ依頼を変更することであってよい。新しいジョブへ割り当てられるリソースの量は、それ自体が信憑性スコアに基づき決定され得る。
【０００８】
利用可能なりソースの最良の使用を行うために、スケジューリングは、前記バックフィルウィンドウを構成するリソースに対する当該ユーザによってリクエストされたリソースの割合である計算された利用率に更に基づくことができる。これは、新しいジョブのためのリソース要件に最もよく適合するバックフィルウィンドウを見つけることができる。同様に、新しいジョブ依頼が複数のそのような新しいジョブ依頼のうちの１つである場合に、前記利用率は、所与のバックフィルウィンドウに最もよく適合するジョブを選択するために使用され得る。
【０００９】
一実施形態において、前記新しいジョブは、履歴データが収集されたことがある以前に実行されたジョブに対応し、ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータは、前記ジョブを実行することに関連する性能特性を示す性能データを更に含み、
実行のために前記新しいジョブをスケジューリングすることは、当該ユーザの前記信憑性スコア及び前記以前に実行されたジョブの前記性能データに基づく。性能データの使用は、ジョブのためにユーザによってリクエストされたリソースが、そのジョブを実行するのに実際に必要とされるリソースを反映するかどうかのより正確な推定を提供するのに役立つ。
【００１０】
一実施形態において、ジョブは、１又はそれ以上のアプリケーションを含み、前記複数のユーザの夫々についての前記信憑性スコアは、夫々のアプリケーションに関して計算される。これは先と同じく、ジョブが、利用可能なりソースにより良く適合されることを可能にする。スケジューリングが実行される際に基づく信憑性スコアは、複数の信憑性スコアのうちの１つ、又は複数の信憑性スコアの結合（例えば、複数の信憑性スコアの平均）であることができる。１又はそれ以上のアプリケーションは、前処理、シミュレーションの実行、及び／又は後処理のような、ジョブワークフローの異なるフェーズに対応することができる。然るに、上記の性能データは、例えば、アプリケーションの実行からのデータのトレーシング及び／又はプロファイリングを含むアプリケーション性能解析データであることができる。アプリケーションにおける異なるプロシージャ（サブルーチン及び関数）に関し、そのようなアプリケーション性能解析データは、いつどこでそれが呼び出されたかの呼び出しツリー、それが呼び出された回数、及び／又はどれくらいの時間がプロシージャ及びその命令文において費やされたかを含むことができる。アプリケーション性能解析データは、コミュニケーション呼び出し（例えば、移植効率が高く且つメッセージパッシング並列プログラムを記述するために使用される変動標準である様々なメッセージパッシングインターフェース（Message  Passing  Interface）（ＭＰＩ）呼び出しにおいて費やされた時間）、メモリ（例えば、ハードウェアカウンタ情報）、及びＩ／Ｏ呼び出しに関するより詳細な情報を更に含むことができる。そのような情報は、アプリケーションが、所与の入力について計算、通信及びＩ／Ｏにおいて費やされた時間の量に関して特性化されることを可能にする。
【００１１】
一実施形態において、前記複数のユーザの夫々についての前記信憑性スコアは、以前に実行されたジョブに実際に使用されたリクエストされたリソースのうちのパーセンテージに基づき計算される。例えば、最も簡単な場合において、以前に実行されたジョブに実際に使用されたリクエストされたリソースのパーセンテージと信憑性スコアとの間には線形な関係が存在することができる。更に、信憑性スコアが下回らない下位閾値が設定され得る。これは、ジョブが早期に終了する可能性が高いことが知られる場合に役立つことができる。
【００１２】
複数の新しいジョブが実行のためにキューに入れられる場合に、すなわち、利用可能なリソースを割り当てられるのを待っている場合に、信憑性スコアは、キューの順序を変更するために使用され得る。特に、スケジューリングは、前記キューにおいてより高いがより低い信憑性スコアを有するユーザによって発せられる少なくとも１つの新しいジョブに対して、前記キューにおいてより低いがより高い信憑性スコアを有するユーザによって発せられる少なくとも１つの新しいジョブを優先することを含むことができる。一般的に言えば、より低い信憑性スコアを有するユーザは、より高い信憑性スコアを有するユーザよりも、ジョブを実行するのに必要とされるリソースを過大に見積もる傾向が大きい。このアプローチは、より低い信憑性スコアを有するユーザが、より高い信憑性スコアを有するユーザによりも過大な見積もりを提供する可能性が高いとして、正確な推定を提供するようユーザに働きかける。つまり、これはスケジューリング効率を改善する。なお、公平性を確保するよう、方法は、優先されるジョブがどの程度キュー内で繰り上げられ得るかを制限してよい。
【００１３】
ジョブが必要とされるよりも少ないリソースを割り当てられている場合に、多種多様なアプローチが採用され得る。例えば、新しいジョブの実行中に、割り当てられているリソースがジョブを完了するには不十分であると決定される場合は、新しいジョブは終了又は一時中断され得る。なお、ジョブがほとんど完了している場合は、ジョブは終了することを認められてよい。
【００１４】
一実施形態において、方法は、新しいジョブの実行後に、前記新しいジョブを実行するために使用された実際のリソースと前記割り当てられたリソースとの間の比較に基づき前記スケジューリングの精度を決定することを更に有する。これは、スケジューリングのインテグリティが正当であると確認されることを可能にする。
【００１５】
一実施形態に従って、データ解析モジュールを備え、該データ解析モジュールは、
複数のユーザから受け取られたジョブ依頼に関連する履歴ジョブデータにアクセスし、ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータが、ジョブを実行するために当該ユーザによってリクエストされたリソースを示すリソースリクエストデータと、前記ジョブを実行するために使用された実際のリソースを示すリソース利用データとを含み、
前記複数のユーザの夫々について、当該ユーザから受け取られた１又はそれ以上のジョブ依頼に関連する前記リソースリクエストデータと前記リソース利用データとの間の比較に基づき、ジョブを実行するためにリクエストされるリソースを当該ユーザが過大に見積もる程度を示す信憑性スコアを計算する
よう構成される、データアナライザが提供される。
【００１６】
一実施形態において、当該データアナライザは、前記信憑性スコアに基づきユーザから受け取られた新しいジョブ依頼を変更するよう構成されるジョブ依頼変更モジュールを更に有する。
【００１７】
当該データアナライザは、プラグ着脱可能なモジュールであることができる。これは、システム構成に関して柔軟性を提供する。
【００１８】
一実施形態に従って、上記のデータアナライザと、複数のユーザから受け取られたジョブ依頼に関連する履歴ジョブデータを記憶するよう構成されるデータベースとを備え、ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータが、ジョブを実行するために当該ユーザによってリクエストされたリソースを示すリソースリクエストデータと、前記ジョブを実行するために使用された実際のリソースを示すリソース利用データとを含む、データ解析装置が提供される。
【００１９】
一実施形態に従って、ジョブをスケジューリングするよう構成されるスケジューラと、上記のデータ解析装置と、スケジューリングされたジョブを実行するよう構成されるコンピューティングリソースとを備えるコンピュータシステムが提供される。コンピューティングリソースは、ハイパフォーマンスコンピューティング（High-Performance  Computing）（ＨＰＣ）リソースであることができる。
【００２０】
一実施形態に従って、コンピュータによって実行される場合に、該コンピュータに、上記の方法を実行させるコンピュータ可読コードを担持するコンピュータ可読媒体が提供される。
【００２１】
実施形態は、ハードウェア、ファームウェア、ソフトウェア、又はそれらのあらゆる組み合わせにおいて実施されてよい。実施形態はまた、１又はそれ以上のプロセッサ及び／又はコントローラによって読み出されて実行され得る１又はそれ以上の非一時的なコンピュータ可読媒体において記憶されている命令として実施されてよい。非一時的なコンピュータ可読媒体には、コンピュータ（例えば、コンピュータ装置）によって読出可能な形で情報を記憶又は伝送するあらゆる有形なメカニズムが含まれてよい。例えば、非一時的なコンピュータ可読媒体には、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置、及び他が含まれてよい。代替的に、コンピュータ可読媒体は、インターネットウェブサイトから提供されるダウンロード可能なデータ信号のような信号の形をとってよい。
【００２２】
本発明の更なる実施形態、特徴及び利点、並びに本発明の様々な実施形態の構造及び動作は、添付の図面を参照して以下で詳細に記載される。
【発明の効果】
【００２３】
本発明の実施形態によれば、コンピュータ環境における改善されたジョブスケジューリングを提供することが可能となる。
【図面の簡単な説明】
【００２４】
【図１】実施形態に従って、ジョブスケジューリングが実行されるコンピュータ環境を図解で説明する。
【図２Ａ】実施形態に従って、バックフィルジョブスケジューリングの図形表現である。
【図２Ｂ】実施形態に従って、バックフィルジョブスケジューリングの図形表現である。
【図３Ａ】実施形態に従って、図１に示されるデータアナライザによる変更の前のジョブ依頼スクリプトを表す。
【図３Ｂ】実施形態に従って、図１に示されるデータアナライザによる変更の後のジョブ依頼スクリプトを表す。
【図４】実施形態に従って、ユーザの以前のジョブを実行するのに実際に使用されたリクエストされたリソースのパーセンテージに基づき如何にしてユーザの信憑性スコアが決定され得るかを示すプロットである。
【図５】実施形態に従って、ユーザの以前のジョブを実行するのに実際に使用されたリクエストされたリソースのパーセンテージに基づき如何にしてユーザの信憑性スコアが決定され得るかを示すプロットである。
【図６】実施形態に従って、バックフィルジョブスケジューリングの間のオーバーラン決定の図形表現である。
【図７】実施形態に従って、バックフィルジョブスケジューリングの間のジョブの優先順位付けの図形表現である。
【図８】実施形態に従って、図１に示されるデータストアをポピュレートする方法のフロー図である。
【図９】実施形態に従って、ジョブスケジューリングの方法のフロー図である。
【図１０】実施形態に従って、図１に示されるデータアナライザのブロック図である。
【発明を実施するための形態】
【００２５】
具体的な実施形態は、以下で、単なる一例として与えられている添付の図面を参照して記載される。
【００２６】
図１は、実施形態に従って、ジョブスケジューリングが実行されるコンピュータ環境１００を図解で説明する。ここで、コンピュータ環境１００は、ソースコンピュータユニット１０２、マスタコンピュータユニット１０３及びあて先コンピュータユニット１０４を含むハイパフォーマンスコンピューティング（ＨＰＣ）環境である。コンピュータユニット（１０２、１０３及び／又は１０４）は、ジョブ又はアプリケーションを処理することができる１又はそれ以上のノードを有する。複数のコンピューティングノードを備えるコンピュータユニット（例えば、ＨＰＣノードのクラスタ）において、ノードは、例えば、ローカルエリアネットワーク又は他のタイプのコネクションを介して、互いに結合され得る。
【００２７】
マスタコンピュータユニット１０３は、ソースコンピュータユニット１０２からジョブを受け取り、あて先コンピュータユニット１０４による実行のためにジョブをスケジューリングする（以下でより詳細に記載される。）。マスタコンピュータユニット１０３は、パーサ１０６、ジョブスケジューラ１０８、及びデータ解析ユニット１１０を有する。データ解析ユニット１１０は、データアナライザ１１２及びデータストア１１４を有し、それらはいずれも、以下でより詳細に記載される。
【００２８】
コンピュータユニット１０２、１０３、１０４は、様々な異なる構成において実施可能であり、別個のコンピュータユニット（図１参照）であることができ、あるいは、様々な異なる組み合わせにおいて結合され得る。例えば、マスタコンピュータユニット１０３及びあて先コンピュータユニット１０４は、１つのコンピュータユニットにまとめられてよい。同様に、コンピュータユニット１０２、１０３、１０４の要素は、様々な異なる構成において実施可能である。例えば、データ解析ユニット１１０は、パーサ１０６及びジョブスケジューラ１０８とは異なるコンピュータユニットにおいて設けられてよい。同様に、データアナライザ１１２及びデータストア１１４は、互いに異なるコンピュータユニットにおいて設けられてよい。別個のコンピュータユニットは、例えば、ギガビットイーサネット（登録商標）のような高速リンクを介して、互いに結合されてよい。他のタイプのリンク、スイッチ又は他のコネクションがまた使用されてよく、当業者によく知られている。
【００２９】
図１は、マスタコンピュータユニット１０３への入力及びそれからの出力並びにその要素の幾つかを示す。特に、点線矢印は、データ解析ユニット１１０のデータストア１１４への入力を表し、破線矢印は、データ解析ユニット１１０のデータアナライザ１１２からの出力を表す。実線矢印は、マスタコンピュータユニット１０３の他の要素への入力及びそれからの出力の幾つかを表す。データアナライザ１１２とデータストア１１４との間及びパーサ１０６とジョブスケジューラ１０８との間のような、様々な他の入力、出力及びインタラクションが可能であるが、明りょうさのために図示されていないことが認識されるであろう。
【００３０】
ユーザは、ユーザインターフェース１１６、例えば、ディスプレイ上に提示されるグラフィカルユーザインターフェースを用いて、ソースコンピュータユニット１０２でジョブ依頼を作成する。ジョブ依頼は、通常は、実行されるべきジョブと、それらのジョブを実行するためのリクエストされているリソースとを特定する。特に、ジョブ依頼は、Ｐｅｒｌ、Ｐｙｔｈｏｎ又はＢａｓｈのようなプログラミング言語において記述されるジョブスクリプトを構築することによって生成され、ジョブを実行するプログラムを起動するための適切なコマンドを含む。例となるジョブスクリプトは、以下でより詳細に記載される。
【００３１】
ジョブ依頼１２２は、パーサ１０６によって受け取られる。夫々のジョブ依頼について、パーサ１０６はジョブスクリプト、アプリケーション入力及びデータファイル（集合的に点線矢印１２４によって表される。）をデータストア１１４へ出力する。データストア１１４から、それらは、スケジューリングの最適化のためにデータアナライザ１１２によって解析される。これは、後に詳細に記載されるが、あえて言うならば、最適化は、例えば、
以前に実行されたジョブからのジョブスクリプト、アプリケーション入力及びデータファイル、
それらの入力から為されたジョブスケジューラ決定及びジョブの実行からのジョブスケジューラ統計値（集合的に、参照符号１２８によって表される。）、
計算時間、通信時間及びＩ／Ｏ時間の間のバランスのような、アプリケーション性能解析データ、
内部ソース１３５から得られたアプリケーション実行中のデータセンターエネルギ使用量及び効率データ１３２、並びに
例えば、他のサイトからのデータ又は他のシステムからのアプリケーション性能特性を含む外部ソース１３７からの何らかの他の関連データ１３６
のうちの１又はそれ以上を含む、データストア１１４に記憶された履歴データの解析に基づく。新しいジョブ依頼が実行される場合に、ジョブスクリプト、アプリケーション入力及びデータファイル１２４は、データストア１１４に記憶されている以前に実行されたジョブに関するデータの部分になる。
【００３２】
最適化されたジョブ依頼１２６は、データアナライザ１１２によってジョブスケジューラ１０８へ出力される。ジョブスケジューラ１０８は、利用可能なリソースを識別すること、ジョブをスケジューリングすること、及びジョブの現在のステータスを追跡すること（集合的に、実線矢印１３０によって表される。）に関与する。データアナライザ１１２はまた、通知１３８、例えば、ジョブスクリプト変更を示す通知、をソースコンピュータユニット１０２へ出力する。
【００３３】
ジョブスケジューリングの方法が、これより記載される。図２Ａ及び２Ｂに示されるように、ジョブスケジューリングは、２次元のチャートを用いて、この特定の例では、横軸の時間及び縦軸のプロセッサ数により、視覚的に表現可能である。夫々のジョブは、ジョブを実行するのに必要とされる、時間を表す長さ及びプロセッサ数を表す幅を有する長方形と考えられてよい。本開示に関連して、長さは、ユーザによってリクエストされた時間又は割り当てられた時間のいずれかを表すことができ、これは、それが記載される文脈から明らかである。
【００３４】
上述されたように、従来のバックフィルスケジューリングは、利用可能なリソース（２次元チャートにおける“ホール”）を特定し、それらのホールに適合するジョブを、ユーザによってリクエストされている必要とされるリソースに基づきスケジューリングすることによって、働く。しかし、ユーザが、必要とされるリソースを過大に見積もる場合に、ジョブは、実行されるために利用可能なリソースを待つキューにおいて、長い時間を費やすことがある。これは、非効率的なリソース利用を生じさせる。例えば、図２Ａにおいて、既にスケジューリングされているジョブは、実線長方形として示されている。ジョブ２０４は、４時間単位の間に１ユニットのプロセッサリソースを使用するとのリクエストを伴ってユーザによって提起されている。しかしながら、バックフィルウィンドウ２０２における利用可能なリソースはそのリクエストを満足せず、故に、バックフィルウィンドウ２０２ではスケジューリングされ得ない。ここで使用されるように、語「バックフィルウィンドウ」は、待機中のジョブが実行されるとバックフィルスケジューラが計算した将来における時間を指す。ジョブのためのリソースは、バックフィルウィンドウ内で完了することができるあらゆる他のジョブを実行するようこの時間量の間に利用可能である。
【００３５】
実施形態において、ユーザによって提起されたジョブのバックフィルスケジューリングは、そのユーザによって為された以前のジョブ依頼に関する情報に基づく。特に、バックフィルスケジューリングは、どれくらい正確にユーザが以前のジョブを実行するのに必要とされるリソースを見積もったかを表す信憑性スコアに基づく。これは、入力ファイル及びアプリケーションランタイム設定の詳細、並びに／又はジョブのアプリケーション／プログラムについての性能情報を付加することによって、更に精緻化され得る。よって、見積もられるランウィンドウは、ジョブが早期に終了する、すなわち、リクエストされたリソースの全てを使用しない、との期待に基づき“重なり合う”ことを認められる。これを達成するよう、ジョブ依頼スクリプトは、図２Ｂに示されるように、ジョブをバックフィルウィンドウに収めるために変更され得る。図２Ｂにおいて、ジョブ２０４のためのリクエストされた時間は、バックフィルウィンドウに適合するために、データアナライザ１１２によって最適化される。ジョブスクリプトを変更する例は、図３Ａ及び３Ｂを参照して以下で記載される。図３Ａは、ユーザによって提起されたジョブ依頼スクリプト３０４を示し、図３Ｂは、変更されたジョブ依頼スクリプト３０４’を示す。
【００３６】
ジョブ依頼スクリプト３０４は、とりわけ、アプリケーション（＃ＪＯＢ−ｎａｍｅ  ｒｕｎ＿ａｐｐ＿ｓｉｍ１）、リクエストされているリソースノード（＃ＪＯＢ−ｒｅｓｏｕｒｃｅ  ｎｏｄｅｓ＝４）、リクエストされているリソースコア（＃ＪＯＢ−ｒｅｓｏｕｒｃｅ  ｃｏｒｅｓ＝６４）、ユーザ（＃ＪＯＢ−ｕｓｅｒ  ｅｖｅ）、及びリクエストされているランタイム（＃ＪＯＢ−ｔｉｍｅ  ０２：００：００）を特定する。よって、ジョブ依頼スクリプトは、Ｅｖｅは、アプリケーション“ａｐｐ＿ｓｉｍ１”が、２時間で６４のコア（トータルで１２８コア時間）により実行されることを要求していると特定する。３２コア時間のバックフィルウィンドウ、すなわち、１／２時間に６４のコア、しか利用可能でないとする。
【００３７】
然るに、データアナライザ１１２は、ユーザ（この例では、Ｅｖｅ）によってリクエストされているリソースの量が、必要とされる実際のリソースを正確に反映しているかどうかを決定する。これは、データストア１１４に記憶されているそのユーザ（Ｅｖｅ）に関連する履歴ジョブ依頼情報及び夫々のユーザについての統計値を解析することによって、行われる。実施形態において、この精度は、ユーザについての“信憑性スコア”によって表される。データストア１１４は、ユーザＥｖｅの信憑性スコアをクエリされる。例となるテーブルが以下に示される。
【表１】
2015133112.tif 000003
【００３８】
テーブルから、Ｅｖｅは低い信憑性スコアを有することが分かる。結果として、データアナライザ１１２は、依頼において特定されているリクエストされるリソースを変更し（又は、変更するための命令を発し）、それにより、ジョブ２０４’が、これより、図２Ｂに示されるバックフィルウィンドウにおいてスケジューリングされ得る。すなわち、予測されたランタイムは、ユーザによって見積もられたランタイムよりも短い。
【００３９】
変更後のジョブ依頼スクリプト３０４’が図３Ｂにおいて示される。明らかなように、リクエストされている時間についてのコマンド行は、２時間から３０分に変更されている。リクエストされているリソースが変更される量は、信憑性スコアと、リクエストされているリソース又はアプリケーション性能のような他の変数とから、導出され得る。最も簡単な形において、例えば、５０％の信憑性スコアを有するユーザ（すなわち、ユーザは、必要とされるリソースを２倍だけ過大に見積もる。）についてのリクエストされているリソースは、半分にされ得る。結果として、全体のリソース利用における改善は、さもなければバックフィリングされないジョブがバックフィリングされ得ることから、達成され得る。
【００４０】
信憑性スコアを計算する例が、これより記載される。
【００４１】
夫々のジョブの終わりに、リクエストされたリソース及び使用された実際のリソースが取り出され、データストア１１４において、例えば、以下に示されるテーブルにおいて、保存される。
【表２】
2015133112.tif 000004
【００４２】
それらの値から、ジョブのために使用されたリクエストされたリソースのうちのパーセンテージが計算され得る。例えば、Ｂｏｂ（ＮａｍｅＩＤ＝２）は６４コア時間をリクエストしたが、使用された実際の時間も６４コア時間であった。よって、ジョブに使用されたリクエストされたリソースのうちのパーセンテージは１００％である。他方で、Ｅｖｅ（ＮａｍｅＩＤ＝１）は１つのアプリケーション（“ａｐｐ＿ｓｉｍ１”）のために２５６コア時間をリクエストし、他のアプリケーション（“ａｐｐ＿ｓｉｍ４”）のために４８コア時間をリクエストしたが、それらは実際には、夫々、実行するために６４コア時間及び１６コア時間しか使用しなかった（２５％及び３３％）。それらのパーセンテージ及び所定の関数を用いると、その場合に、信憑性スコアが算出され得る。例えば、図４に示されるように、関数は、実際に使用されたリクエストされたリソースと信憑性スコアとの間の線形マッピングであることができる。他の関数は図５に示され、下位閾値より上では線形に増大する関係を含む。そのような関数は、例えば、アプリケーションの試験フェーズ中に早期に終わるジョブを提起する開発者ユーザグループに使用されてよい。信憑性スコアが下回らない下位閾値を設定することによって、グループは、リクエストされるリソースを過大に見積もることに対して過度に厳しく不利益をもたらされない。例えば、たとえジョブがリクエストされたリソースのうちの１０％しか使用しない（９０％の過大見積もりに対応する。）としても、信憑性スコアは６０を下回らない。関数の範囲は、使用されるリソースのパーセンテージを信憑性スコアにマッピングするよう定義され得ることが認識されるであろう（パーセンテージは、複数のパーセンテージの平均、中央値又は他の値であることができる。）。更に、異なる関数が、異なるユーザグループへ、それらがシステムを使用する方法に依存して、割り当てられ得る。
【００４３】
上述されたように、１つのジョブが多数のアプリケーションをそのジョブの異なるフェーズの部分として実行する状況があり得る。そのような状況では、性能情報がそのジョブを含むアプリケーションの一部又は全てについて利用可能である場合は、信憑性スコアは夫々のアプリケーションについて計算され得る。次いで、個々の信憑性スコアは、より正確なリソースリクエストを与えるよう結合されてよい。代替的に、ジョブはアプリケーションにわたって分割され得る。すなわち、アプリケーションは、対応する信憑性スコアに基づき個々にスケジューリングされ得る。
【００４４】
公平性を確保するよう、（変更された）バックフィリングされるジョブは、既にスケジューリングされている他のジョブを尊重することが望ましい。バックフィリングされるジョブと既にスケジューリングされているジョブとの間に潜在的な重なり合いがある場合に、オーバーラン決定が行われる必要がある臨界点が導入される。例えば、図６に示されるように、ジョブ２０４’は、バックフィルウィンドウに適合するよう変更されており、臨界点は時間ｔで到達される。２つのジョブスケジューリングオプションのうちの１つは、この時点で行われてよい。第１のオプションは、ジョブ２０４’を実行させ、事前に割り当てられていたジョブ２０５を遅延させることである。第２のオプションは、ジョブ２０５の優先順位を尊重することである。後者の場合に、ジョブ２０４’のチェックポイントは、それが一時中断され、後のインターバルでその現在の状態から再開されるように行われる。代替的に、ジョブ２０４’は終了され、後の時点で最初から再開され得る。
【００４５】
他のシナリオは、これより図７を参照して記載される。ユーザＡｌｉｃｅ、Ｂｏｂ及びＥｖｅは、夫々が夫々提起されたジョブ７０４、７０６，７０８を有する。それらはバックフィルウィンドウに適合する。ここで、Ａｌｉｃｅ及びＢｏｂは、彼らのリソース利用の悪い又は平均的な推定をこれまで与えており、一方、Ｅｖｅは、良好な推定をこれまで与えているが、彼女のジョブは最初にスケジューリングされるとする。Ａｌｉｃｅ、Ｂｏｂ及びＥｖｅによって発せられたジョブは、それらが提起される順序においてキューに入れられる。最も簡単な場合では、キューにおいて下位である、高い信憑性スコアを有するユーザのジョブ、例えば、Ｅｖｅのジョブ７０８は、キューにおいて高位にある１又はそれ以上のジョブ、ここでは、Ａｌｉｃｅ及びＢｏｂのジョブ７０４及び７０６より先に、リソースを割り当てられる。
【００４６】
一実施形態において、信憑性スコアと、リクエストされている時間及び実行されるべきジョブについての性能情報のような他の変数とを用いる多変量解析は、夫々のジョブがバックフィルウィンドウにおいて実行される可能性を生成する。ここで、多変量解析は、リクエストされているリソース及びアプリケーション性能が、信憑性スコアに加えて、全ての利用可能なもののうちどのジョブがバックフィルウィンドウにおいて実行されるかを決定することを意味する。信憑性スコアと、バックフィルウィンドウにおいてジョブが実行され得る可能性との間には差が存在することが知られる。実際には、可能性は、リクエストされているリソースが上述されたように変更される時間の量に関係がある。この可能性は、信憑性スコアと、リクエストされているリソース又はアプリケーション性能のような他の変数とから導出され得る。可能性を用いることは、同じ信憑性スコアを有するユーザを区別するのに役立つことができる。
【００４７】
バックフィルウィンドウを満たそうと試みるときに、多数のユーザが同じ信憑性スコアを有する場合は、リクエストされている時間及びアプリケーション性能のような他の評価が、どのジョブが実行されるかを決定するために使用される。例えば、４人のユーザが６０コア時間のバックフィルウィンドウに適合可能なジョブを提起しているとする。ユーザ及び提起されているジョブについての詳細は、以下のテーブルで与えられる。
【表３】
2015133112.tif 000005
【００４８】
一実施形態において、それらのジョブのうちのどれをバックフィルウィンドウにおいて実行すべきかを選択することは、消去プロセスに従う。
【００４９】
第１のステップで、最悪（最低）の信憑性スコアを有するユーザが識別されて除外される。この例では、これは、信憑性スコアが４０であるＭａｌｏｒｙを除外する。
【００５０】
第２のステップで、利用率が、残りのジョブ（ここで、Ｅｖｅ、Ｂｏｂ及びＡｌｉｃｅのジョブ）の夫々について計算され、最も高い利用率の値を有するジョブが選択される。利用率は、次のように定義され得る：
利用率＝リクエストされたリソース／利用可能なバックフィルウィンドウ
例えば、６０コア時間のバックフィルウィンドウが利用可能であるとすると、Ｅｖｅのジョブ（ＪｏｂＩＤ＝１０６）は選択から除外される（利用率＝３０／６０＝０．５）。ボブのジョブ（ＪｏｂＩＤ＝１０７）及びＡｌｉｃｅのジョブ（ＪｏｂＩＤ＝１０８）はいずれも１の利用率を有し、依然として選択のために残る。
【００５１】
第３のステップで、このステップは幾つかの場合に必要とされ得ないが、アプリケーション性能情報が、どのジョブがバックフィルウィンドウにおいて実行されるべきかを選択するために使用される。ある‘アプリケーション性能係数’がアプリケーションどうしを比較するために使用され、最も高い値を有するジョブが実行するために選択される。このステップから、Ａｌｉｃｅからのジョブが除去され、ボブのジョブがバックフィルウィンドウにおいて実行される。
【００５２】
プロセスはこの特定の順序で実行される必要はなく、全てのステップが含まれる必要はないことが理解されるべきである。
【００５３】
データストアに情報をポピュレートし、捕捉されたデータを、リソース利用を最適化するために使用する方法が、これより記載される。
【００５４】
図８は、図１に示されるデータストア１１４をポピュレートする方法を示すフロー図である。方法は、次のステップを有する：
Ｓ８０２：ＨＰＣシステムのようなコンピュータシステムによって実行されるべきジョブがユーザから受け取られる。
【００５５】
Ｓ８０４：依頼スクリプト並びにあらゆる入力及びデータファイルがパーサ１１０によってパースされる。
【００５６】
Ｓ８０６：パースされたスクリプト及びファイルが、プロセスの数、リクエストされているメモリ又は他のリソース、並びに入力及びデータファイルのコピー又はハッシュシグニチャのようなジョブの特性を識別するよう、関連情報についてデータ解析モジュール１１２によって解析される。
【００５７】
Ｓ８０８：次いで、ジョブが、リクエストされたリソースにより実行される。大まかに言えば、ジョブは、それがリソースを用いて完了され得る場合に、それらのリソースを用いて実行され得る。そのようなリソースは、例えば、プロセッサ時間の量、プロセッサの数、メモリ使用量、入力／出力容量、等を含むことができる。
【００５８】
Ｓ８１０：ジョブの実行中に、ジョブの性能の定期的なスナップショットが、例えば、計算、メモリ、Ｉ／Ｏ及びエネルギリソースを含む、それが消費するリソースに関して、アプリケーションを特性化するために取られる。
【００５９】
Ｓ８１２：性能情報がデータストア１１４に格納される。取得された情報から、データ解析モジュール１０６は、リクエストされたリソース及び如何に効率よくそれらが使用されたかに関して、ジョブ及びその性能の特徴ピクチャ（characterising  picture）を構築することができる。
【００６０】
Ｓ８１４：ユーザの信憑性スコアが、ステップＳ８０６及びＳ８１０で収集されたデータに基づき計算される。
【００６１】
図９は、図１に示されるデータアナライザ１１２によってジョブをスケジューリングする方法を示すフロー図である。方法は、次のステップを有する：
Ｓ９０２：ＨＰＣシステムのようなコンピュータシステムによって実行されるべきジョブがユーザから受け取られる。
【００６２】
Ｓ９０４：依頼スクリプト並びにあらゆる入力及びデータファイルがパーサ１１０によってパースされる。
【００６３】
Ｓ９０６：次いで、パースされたスクリプトが、ジョブパラメータを最適化するために、データストアを解析するのに使用される。これは、最適化されたパラメータを使用するようジョブ依頼を変更すること、例えば、リクエストされている時間を変更すること、を伴ってよい。
【００６４】
Ｓ９０８：次いで、ジョブが、更新されたリソースにより実行される。
【００６５】
方法の更なるステップは、以下を含むことができる：
Ｓ９１０：ジョブの実行中に、ジョブの性能の定期的なスナップショットが、例えば、計算、メモリ、Ｉ／Ｏ及びエネルギリソースを含む、それが消費するリソースに関して、アプリケーションを特性化するために取られる。
【００６６】
Ｓ９１２：性能情報に基づき、データ解析モジュール１１２によって為された決定のインテグリティは、最適化が期待されたとおりに実行されたかどうかを確認するために、ジョブ完了後に解析され得る。データストア１１４は、決定の有効性に関する評価を提供するよう、この解析の結果により更新され得る。
【００６７】
ステップＳ９１２をより詳細に見ると、スケジューリングされたジョブの終わりに、比較は、ジョブをスケジューリングするのに使用された推定されたリソースと、使用された実際のリソースとの間で、行われ得る。ここで、バリデーション情報は、実行からのアプリケーション性能情報が予めデータベースにフィードバックされるので、後続のジョブについて決定を行う際に直接に使用されない。むしろ、その情報は、リクエストされているリソースを変更することでどれくらいより多くのジョブが実行されたのか、又は不良決定によりどの程度ジョブが遅延されたのかといった統計値を提供することによって、バックフィルウィンドウを使用する際にデータ解析モジュールの有効性を報告するのに使用される。
【００６８】
図１０は、実施形態に従って、図１のデータアナライザ１１２の実施を説明するブロック図である。
【００６９】
一実施形態において、データアナライザ１１２は、データストアにアクセスしてこれを解析し且つ最適化を提供し機能性を報告するＡＰＩインターフェースルーチンの組を有する。より具体的には、“データストア解析”ルーチン１００２は、データストア１１２から情報を読み出し、この情報を、例えば、信憑性スコアを計算するために、解析するよう構成される。“ジョブ設定変更”ルーチン１００４は、図３Ａ及び３Ｂを参照して記載されたように、“データストア解析”ルーチン１００２によって決定された結果を用いてジョブ依頼設定を変更するよう構成される。“報告生成”ルーチン１００６は、報告を生成するよう構成される。報告は、単純なユーザ通知、又はより詳細な報告であることができる。“決定検証”ルーチン１００８は、上記のインテグリティバリデーション機能性を実施するよう構成される。
【００７０】
データアナライザ１１２は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせにおいて実施されてよい。例えば、多数の可能な実施形態のうちの１つにおいて、データアナライザ１１２は、メモリにおいて記憶され且つプロセッサ（図示せず。）によって実行されるソフトウェアにおいて実施される。ハードウェアにおいて実施される場合に、データアナライザ１１２は、揮発性メモリ素子（例えば、ランダムアクセスメモリ（ＲＡＭ、例えば、ＤＲＡＭ、ＳＲＡＭ、ＳＲＡＭ等））及び不揮発性メモリ素子（例えば、ＲＯＭ、ハードドライブ、テープ、ＣＤＲＯＭ等）のいずれか１つ又は組み合わせにおいて実施され得る。メモリは、電子式、磁気式、光学式、及び／又は他の形式の記憶媒体を組み込んでよい。メモリはまた、様々なコンポーネントが互いから遠く離れて設置される分散アーキテクチャを有してよい。ハードウェアにおいて実施される場合に、代替の実施形態において見られるように、ロジックは、当該技術でよく知られている次のロジック、すなわち、データ信号に対してロジック関数を実施するロジックゲートを備えるディスクリートロジック回路、適切な組み合わせロジックゲートを備える特定用途向け集積回路（ＡＳＩＣ）、プログラマブルゲートアレイ（ＰＧＡ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、等、のいずれか又は組み合わせにより実施されてよい。
【００７１】
図１に示されるシステムの設計は変更に順応できる。特に、設計は、異なるタイプの解析が、異なる（プラグ着脱可能な）データ解析モジュールによって実行されることを可能にする。これは、データアナライザ１１２（それ自体がプラグ着脱可能なモジュールであってよい。）に加えて、他のプラグ着脱可能なモジュールが必要に応じて作成されて実装され得るという利点を有する。関連データをデータストア内でカプセル化し、データにアクセスするよう標準インターフェースを設けることによって、幅広いそのようなモジュールが容易に作成され得る。そのようなモジュールの例には、次のものが含まれる：
・ジョブスケジューラ及び入力ファイル情報を検索し、これに基づきアプリケーションを実行すべき最良の計算リソースを自動的に選択することによって、アプリケーションの最適な性能を得るモジュール；
・アプリケーションのエネルギ利用要件を、データストアから得られるそのアプリケーションについての以前のエネルギ利用測定に基づき推定し、このエネルギ利用推定を、データセンターがその電力閾内に留まることを確かにするよう、ジョブスケジューラメトリックとして使用するモジュール；及び
・ＨＰＣシステムのどの部分が最も高い需要があるのかを報告することによってバジェット決定を方向付け、又は最も頻繁に使用されるアプリケーションについて重要なリソースボトルネックがどこにあるかを解析し識別するモジュール。
【００７２】
実施形態は、ランタイム制限がジョブ依頼において特定されるバックフィルスケジューリングに関連して記載されてきたが、当業者は、様々な実施形態が、他のタイプのスケジューリングに同じく適用可能であると認識するであろう。例えば、リクエストされるリソースは、プロセッサ制限、メモリ制限、入力／出力制限、等に関して特定され得る。
【００７３】
たとえフローチャートのブロックが順次的な順序で表されているとしても、それらのブロックは、必要に応じて、同時に、及び／又は記載されているのとは異なる順序で、実行されてもよい。また、様々なブロックは、より少ないブロックにまとめられても、更なるブロックに分けられても、及び／又は所望の実施に基づき削除されてもよい。更に、ここで開示される方法及び他のプロセスに関し、フローチャートは、本実施形態の１つの可能な実施の機能性及び動作を示す。これに関連して、夫々のブロックは、プロセスにおける特定の論理的な機能又はステップを実施するためにプロセッサによって実行可能な１又はそれ以上の命令を含むモジュール、セグメント、又はプログラムコードの部分に相当してよい。加えて、ここで開示されている方法及び他のプロセスに関して、夫々のブロックは、プロセスにおける特定の論理的な機能を実行するよう配線されている回路に相当してよい。
【００７４】
本発明は、例となる実施形態を参照して記載されてきたが、当業者には明らかなように、様々な改良及び変更が、本発明の適用範囲又は精神から逸脱することなしに行われ得る。例えば、一実施形態の部分として図示又は記載されている特徴は、更なる実施形態を得るよう他の実施形態とともに使用され得る。よって、本発明は、そのような改良及び変更を、添付の特許請求の範囲及びその均等の適用範囲内にあるとして含むことが意図される。
【００７５】
上記の実施形態に加えて、以下の付記を開示する。
（付記１）
コンピュータ環境におけるジョブスケジューリングの方法であって、
複数のユーザから受け取られたジョブ依頼に関連する履歴ジョブデータを収集し、ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータが、ジョブを実行するために当該ユーザによってリクエストされたリソースを示すリソースリクエストデータと、前記ジョブを実行するために使用された実際のリソースを示すリソース利用データとを含み、
前記複数のユーザの夫々について、当該ユーザから受け取られた１又はそれ以上のジョブ依頼に関連する前記リソースリクエストデータと前記リソース利用データとの間の比較に基づき、ジョブを実行するためにリクエストされるリソースを当該ユーザが過大に見積もる程度を示す信憑性スコアを計算し、
前記複数のユーザの１人から、実行されるべき新しいジョブと、該新しいジョブを実行するために当該ユーザによってリクエストされたリソースとを特定する新しいジョブ依頼を受け取り、
当該ユーザの前記信憑性スコアに基づき、実行のために前記新しいジョブをスケジューリングする、方法。
（付記２）
実行のために前記新しいジョブをスケジューリングすることは、当該ユーザによってリクエストされたリソースよりも少ないリソースから構成されるバックフィルウィンドウに前記新しいジョブを割り当てることを含む、
付記１に記載の方法。
（付記３）
前記バックフィルウィンドウを構成するリソースに対する当該ユーザによってリクエストされたリソースの割合に基づき、前記新しいジョブの利用率を計算し、
実行のために前記新しいジョブをスケジューリングすることは、当該ユーザの前記信憑性スコア及び前記利用率に基づく、
付記２に記載の方法。
（付記４）
前記新しいジョブは、履歴データが収集されたことがある以前に実行されたジョブに対応し、
ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータは、前記ジョブを実行することに関連する性能特性を示す性能データを更に含み、
実行のために前記新しいジョブをスケジューリングすることは、当該ユーザの前記信憑性スコア及び前記以前に実行されたジョブの前記性能データに基づく、
付記１乃至３のうちいずれか１つに記載の方法。
（付記５）
ジョブは、１又はそれ以上のアプリケーションを含み、前記複数のユーザの夫々についての前記信憑性スコアは、夫々のアプリケーションに関して計算される、
付記１乃至４のうちいずれか１つに記載の方法。
（付記６）
前記複数のユーザの夫々についての前記信憑性スコアは、以前に実行されたジョブに実際に使用されたリクエストされたリソースのうちのパーセンテージに基づき計算される、
付記１乃至５のうちいずれか１つに記載の方法。
（付記７）
前記新しいジョブ依頼は、前記複数のユーザのうちの２又はそれ以上から受け取られた複数の新しいジョブ依頼のうちの１つであり、
前記新しいジョブは、実行のためにキューにおいて順序付けられ、
実行のために前記新しいジョブをスケジューリングすることは、前記キューにおいてより高いがより低い信憑性スコアを有するユーザによって発せられる少なくとも１つの新しいジョブに対して、前記キューにおいてより低いがより高い信憑性スコアを有するユーザによって発せられる少なくとも１つの新しいジョブを優先することを含む、
付記１乃至６のうちいずれか１つに記載の方法。
（付記８）
前記新しいジョブの実行中に、前記割り当てられたリソースは前記ジョブを完了するには不十分であると決定し、前記新しいジョブを終了又は一時中断する、
付記２乃至７のうちいずれか１つに記載の方法。
（付記９）
前記新しいジョブの実行後に、前記新しいジョブを実行するために使用された実際のリソースと前記割り当てられたリソースとの間の比較に基づき前記スケジューリングの精度を決定する、
付記２乃至８のうちいずれか１つに記載の方法。
（付記１０）
データ解析モジュールを備え、該データ解析モジュールは、
複数のユーザから受け取られたジョブ依頼に関連する履歴ジョブデータにアクセスし、ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータが、ジョブを実行するために当該ユーザによってリクエストされたリソースを示すリソースリクエストデータと、前記ジョブを実行するために使用された実際のリソースを示すリソース利用データとを含み、
前記複数のユーザの夫々について、当該ユーザから受け取られた１又はそれ以上のジョブ依頼に関連する前記リソースリクエストデータと前記リソース利用データとの間の比較に基づき、ジョブを実行するためにリクエストされるリソースを当該ユーザが過大に見積もる程度を示す信憑性スコアを計算する
よう構成される、データアナライザ。
（付記１１）
前記信憑性スコアに基づきユーザから受け取られた新しいジョブ依頼を変更するよう構成されるジョブ依頼変更モジュール
を更に有する、付記１０に記載のデータアナライザ。
（付記１２）
付記１０又は１１に記載のデータアナライザと、
複数のユーザから受け取られたジョブ依頼に関連する履歴ジョブデータを記憶するよう構成されるデータベースと
を備え、
ユーザから受け取られたジョブ依頼に関連する前記履歴ジョブデータが、ジョブを実行するために当該ユーザによってリクエストされたリソースを示すリソースリクエストデータと、前記ジョブを実行するために使用された実際のリソースを示すリソース利用データとを含む、データ解析装置。
（付記１３）
ジョブをスケジューリングするよう構成されるスケジューラと、
付記１２に記載のデータ解析装置と、
スケジューリングされたジョブを実行するよう構成されるコンピューティングリソースと
を備えるコンピュータシステム。
（付記１４）
コンピュータによって実行される場合に、該コンピュータに、付記１乃至９のうちいずれか１つに記載の方法を実行させる
コンピュータ可読コードを担持するコンピュータ可読媒体。
【符号の説明】
【００７６】
１００  コンピュータ環境
１０８  ジョブスケジューラ
１１０  データ解析ユニット
１１２  データアナライザ
１１４  データストア
１２２  ジョブ依頼
２０２  バックフィルウィンドウ
２０４，２０５  ジョブ
【図１】
2015133112.tif 000006
【図２Ａ】
2015133112.tif 000007
【図２Ｂ】
2015133112.tif 000008
【図３Ａ】
2015133112.tif 000009
【図３Ｂ】
2015133112.tif 000010
【図４】
2015133112.tif 000011
【図５】
2015133112.tif 000012
【図６】
2015133112.tif 000013
【図７】
2015133112.tif 000014
【図８】
2015133112.tif 000015
【図９】
2015133112.tif 000016
【図１０】
2015133112.tif 000017