(57)【要約】【課題】タスクの実行のためのコスト及び／または完了時間を最適化する。【解決手段】コスト最小化ジョブスケジュール設定のための方法及びシステムを開示する。タスクの定義が受信される。定義は必要期限時刻を含む。必要期限時刻は、タスクの実行の完了に対する期限を含む。タスクの実行を完了するための推定期間は、複数のコンピューティングリソースの各々に対して決定される。コンピューティングリソースのうちの１つ以上は、コンピューティングリソースを使用して実行を完了する推定コストに基づいて選択される。タスクの実行は、選択された１つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に開始される。スケジュール設定された時刻は、少なくとも推定期間だけ必要期限時刻よりも早い。【選択図】図４
2018163697.tif 000002
【特許請求の範囲】
【請求項１】
リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対する期限を含む、受信することと、
前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有し、前記推定期間は、前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、前記決定することと、
前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コストに基づいて、前記必要期限時刻よりも前に前記タスクの前記実行を完了するために利用可能である前記コンピューティングリソースの中から、１つ以上の前記コンピューティングリソースを選択することと、
前記リソースマネージャが、前記選択された１つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、開始することと、を含む、コンピュータ実装方法。
【請求項２】
前記必要期限時刻前に前記タスクの前記実行の前記完了を確実にすることをさらに含む、請求項１に記載の方法。
【請求項３】
前記リソースマネージャが、前記タスクの前記実行のために、前記１つ以上のクラウドベースのコンピューティングリソースの構成を選択することをさらに含み、前記構成が、実行ウィンドウ内で前記タスクの前記実行のコストを最小限に抑えるように選択され、前記実行ウィンドウのエンドポイントが、前記必要期限時刻に基づく、請求項１に記載の方法。
【請求項４】
前記複数のコンピューティングリソースが、使用量コストの面で異なり、前記コンピューティングリソースのうちの１つ以上を選択することが、
前記必要期限時刻前に、前記タスクの前記実行の完了を可能にする、それぞれの推定期間を有する前記複数のコンピューティングリソースのうちの前記コンピューティングリソースから、最低の使用量コストを有する前記１つ以上のコンピューティングリソースを選択することを含み、
前記タスクの前記実行が、前記選択された１つ以上のコンピューティングリソースを使用して、前記スケジュール設定された時刻に開始される、請求項１に記載の方法。
【請求項５】
前記タスクの前記実行を完了するための前記推定期間が、前記複数のコンピューティングリソースを使用する前記タスクの実行に基づいて決定される、請求項１に記載の方法。
【請求項６】
前記タスクの前記実行を完了するための前記推定期間が、１つ以上の他のタスクの以前の実行に基づいて決定される、請求項１に記載の方法。
【請求項７】
前記１つ以上のコンピューティングリソースが、前記タスク及び１つ以上の追加のタスクを実行するグローバルコストを最小限に抑えるように選択され、前記タスク及び前記１つ以上の追加のタスクの定義のそれぞれは、前記必要期限時刻を含み、前記１つ以上のコンピューティングリソースは、前記タスク及び前記１つ以上の追加のタスクのそれぞれの実行のためにそれぞれ選択される、請求項１に記載の前記方法。
【請求項８】
前記タスクの前記実行のための顧客価格を評価することをさらに含み、前記顧客価格が、前記必要期限時刻に基づく割引を含む、請求項１に記載の方法。
【請求項９】
前記タスクのための実行ウィンドウが、第１の時点で開始し、かつ第２の時点で終了し、前記第１の時点が、前記タスクの前記定義が受信される時点を含み、前記第２の時点が、前記必要期限時刻に基づき、前記割引が、前記実行ウィンドウの大きさに基づいて異なる、請求項８に記載の方法。
【請求項１０】
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに連結されたメモリであって、前記メモリが、プログラム命令を記憶し、前記プログラム命令が、前記少なくとも１つのプロセッサによって実行可能であって、
リソースマネージャが、タスクの必要期限時刻を受信することであって、前記必要期限時刻が、前記タスクの実行の完了の期限を含む、受信することと、
前記リソースマネージャが、クラウドベースの複数のリソース構成の各々に対して前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のリソース構成は、複数のリソースプールに体系化され、前記複数のリソース構成の各々が、それぞれの使用量コストを有し、前記推定期間は、前記複数のコンピューティングリソースを使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、決定することと、
前記リソースマネージャが、実行ウィンドウ内で前記タスクの前記実行のコストを最小限に抑えるように、前記タスクの前記実行を完了する推定コストに基づいて、前記必要期限時刻よりも前に前記タスクの前記実行を完了するために利用可能である前記リソース構成の中から、１つ以上の前記リソース構成を選択することであって、前記実行ウィンドウのエンドポイントが、前記必要期限時刻に基づく、選択することと、
前記リソースマネージャが、前記選択された１つ以上のリソース構成を有する１つ以上の計算インスタンス上の前記タスクの前記実行のためのスケジュール設定された時刻を決定することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、決定することと、を行うように実行可能である、メモリと、を備える、システム。
【請求項１１】
前記１つ以上のリソース構成が、前記タスク及び１つ以上の追加のタスクの実行のグローバルコストを最小限に抑えるように選択され、前記タスク及び前記１つ以上の追加のタスクのそれぞれは、前記必要期限時刻を含み、前記１つ以上のリソース構成は、前記タスク及び前記１つ以上の追加のタスクのそれぞれの実行のためにそれぞれ選択される、請求項１０に記載のシステム。
【請求項１２】
前記リソース構成のうちの１つ以上を選択する際に、前記プログラム命令が、前記少なくとも１つのプロセッサによって、
前記必要期限時刻前に、前記タスクの前記実行の完了を可能にする、それぞれの推定期間を有する前記複数のリソース構成のうちの前記リソース構成から、最低の使用量コストを有する前記１つ以上のリソース構成を選択するようにさらに実行可能である、請求項１０に記載のシステム。
【請求項１３】
前記タスクの前記実行を完了するための前記推定期間が、前記タスクの１つ以上の以前の実行に基づいて決定される、請求項１０に記載のシステム。
【請求項１４】
前記プログラム命令が、前記少なくとも１つのプロセッサによって、
前記タスクの前記実行のための顧客価格を決定するようにさらに実行可能であり、前記顧客価格が、前記必要期限時刻に基づく割引を含む、請求項１０に記載のシステム。
【請求項１５】
前記タスクのための実行ウィンドウが、第１の時点で開始し、かつ第２の時点で終了し、前記第１の時点が、前記タスクの前記定義が受信される時点を含み、前記第２の時点が、前記必要期限時刻に基づき、前記割引が、前記実行ウィンドウの大きさに基づいて異なる、請求項１４に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
多数の企業及び他の組織は、（例えば、ローカルネットワークの一部として）共同設置
されるか、またはその代わりに（１つ以上の非公開または公開中間ネットワークを介して
接続された）複数の個別の地理的場所に設置されたコンピューティングシステム等、それ
らの運営をサポートするために、多数のコンピューティングシステムを相互接続するコン
ピュータネットワークを運用する。例えば、単一の組織によって、かつその代理として運
用される非公開データセンター、及びコンピューティングリソースを顧客に提供する事業
として事業体によって運用される公開データセンター等、かなりの数の相互接続されたコ
ンピューティングシステムを収容するデータセンターが普及している。いくつかの公開デ
ータセンター運用者は、多様な顧客によって所有されるハードウェアのためのネットワー
クアクセス、電源、及び安全な設置の施設を提供する一方で、他の公開データセンター運
用者は、その顧客による使用のために利用可能になったハードウェアリソースも含む「フ
ルサービス」の施設を提供する。しかしながら、典型的なデータセンターの規模及び範囲
が増大するにつれて、物理的なコンピューティングリソースをプロビジョニング、システ
ム管理、及び管理するタスクは、ますます複雑になっている。
【０００２】
一般的なハードウェアに対する仮想化技術の出現は、多様な必要性を有する多数の顧客
のための大規模なコンピューティングリソースを管理する上で利益をもたらし、これによ
って、多種多様なコンピューティングリソースが、複数の顧客によって効率的かつ安全に
共有されることが可能になる。例えば、仮想化技術は、各ユーザーに、単一の物理的コン
ピューティングマシンによってホストされる１つ以上の仮想マシンを提供することによっ
て、単一の物理的コンピューティングマシンが、複数のユーザーの間で共有されることを
可能にすることができ、各々のこのような仮想マシンは、ユーザーが単一の運用者である
という錯覚をユーザーに提供する個別の論理的コンピューティングシステムとしての役割
を果たし、同時に多種多様な仮想マシン間のアプリケーション分離及びセキュリティも提
供する、ソフトウェアシミュレーションである。その上、いくつかの仮想化技術は、複数
の個別の物理的コンピューティングシステムにまたがる複数の仮想プロセッサを備えた単
一の仮想マシン等、２つ以上の物理的リソースにまたがる仮想リソースを提供することが
可能である。別の例として、仮想化技術は、複数のデータ記憶装置にわたって分散され得
る仮想データストアを各ユーザーに提供することによって、データ記憶ハードウェアが複
数のユーザー間で共有されることを可能にすることができ、各々のこのような仮想データ
ストアは、ユーザーがデータ記憶リソースの単独の運用者かつ管理者であるという錯覚を
ユーザーに提供する個別の論理的データストアとしての役割を果たす。
【０００３】
多くの環境において、多種の仮想コンピューティング、記憶、及び／または他のネット
ワークからアクセス可能な機能を実装するプロバイダネットワークの運用者は、顧客が、
いくつかの異なるリソース取得モードのいずれかでリソースへのアクセスを予約または購
入することを可能にする。例えば、顧客は、１年間または３年間等、比較的長期間にわた
って仮想コンピューティングリソースインスタンスを予約してもよく、または、顧客は、
必要に応じて特定の目的のために、より短期間にわたってリソースを購入してもよい。い
くつかのタイプのリソース予約の場合、顧客によって支払われた価格のうちの少なくとも
一部は、プロバイダネットワーク内部のリソースの変化する需要及び供給に対応して、経
時的に変動し得る。プロバイダネットワークの運用者は、例えば、クライアントに対する
全ての保証された約束（既に支払い済みの長期間の予約等）が守られること、リソース価
格設定の動的に異なる構成要素が、顧客の満足度が低下するまで高くならないこと、プロ
バイダのデータセンターの投資が妥当なレベルのリソース利用状況及び収益によって正当
化されること等、いくつかの潜在的に競合する需要が満たされることを保証しようとし得
る。顧客の予算に応じて、少なくとも所定の種類の典型的に長時間稼動するアプリケーシ
ョンで、その主要な制約が、アプリケーションが理想的にはいくらか比較的先の期限前に
完了されるべきことである場合、一部の顧客は、特に、価格設定利点の代償として、どの
リソースがいつ配備されるかを正確に判断する際に、ネットワークプロバイダの運用者に
柔軟性を許容する意思があり得る。
【図面の簡単な説明】
【０００４】
【図１】一実施形態に従う、リソース管理システムのための例示的システム環境を示す。
【図２】図２ａ、図２ｂは、一実施形態に従う、例示的なリソースインスタンス分類手法を示す。
【図３】一実施形態に従う、リソース管理システムによって使用されるデータソースのセットの例を示す。
【図４】一実施形態に従う、必要期限時刻スケジュール設定を含むリソース管理システムのための例示的システム環境を示す。
【図５】一実施形態に従う、タスクをスケジュール設定するために、リソース管理システムによって使用される必要期限時刻を含むデータソースのセットの例を示す。
【図６】一実施形態に従う、必要期限時刻を使用して、タスクの実行をスケジュール設定するための方法を示すフローチャートである。
【図７】一実施形態に従う、入力データ特徴に基づくタイムアウトを含むリソース管理システムのための例示的システム環境を示す。
【図８】一実施形態に従う、タスクのタイムアウト期間を決定するために、リソース管理システムによって使用される、入力データ特徴を含むデータソースセットの例を示す。
【図９】一実施形態に従う、入力データ特徴に基づいてタスクタイムアウトを実施するための方法を示すフローチャートである。
【図１０】一実施形態に従う、動的クラスタ最適化を含むリソース管理システムのための例示的システム環境を示す。
【図１１】一実施形態に従う、タスクの実行を最適化するために、リソース管理システムによって使用されるデータソースのセットの例を示す。
【図１２】一実施形態に従う、動的クラスタ最適化のための方法を示すフローチャートである。
【図１３】一実施形態に従う、遠隔クライアントが、定義された様式でソースデータを操作する定義されたワークフローを作成、構成、及び実行することを可能にする機能を提供する、構成可能なワークフローサービスの例示的実施形態を示す。
【図１４】いくつかの実施形態において使用され得るコンピューティングデバイスの例を示す。
【０００５】
実施形態は、本明細書において、いくつかの実施形態及び例示の図面の例として説明さ
れるが、当業者は、実施形態が説明される実施形態または図面に限定されないことを認識
するであろう。図面及びそれに対する詳細説明は、実施形態を開示される特定の形態に限
定するものではなく、それとは反対に、添付の請求項によって定義される趣旨及び範囲内
に該当する、すべての変形、同等物、及び代替を網羅することを意図することを理解され
たい。本明細書に使用される見出しは、体系化目的に過ぎず、説明または請求の範囲を限
定するために使用されることを意味しない。本明細書全体で使用されるように、「〜して
もよい、〜することができる（ｍａｙ）」という単語は、必須の意味（すなわち、「〜し
なければならない（ｍｕｓｔ）」を意味する）ではなく、許容の意味（すなわち、「〜す
る可能性を有する（ｈａｖｉｎｇ  ｔｈｅ  ｐｏｔｅｎｔｉａｌ  ｔｏ）」を意味する）
」において使用される。同様に、「を含む（ｉｎｃｌｕｄｅ、ｉｎｃｌｕｄｉｎｇ、及び
ｉｎｃｌｕｄｅｓ）」という単語は、「〜を含むが〜に限定されない（ｉｎｃｌｕｄｉｎ
ｇ，ｂｕｔ  ｎｏｔ  ｌｉｍｉｔｅｄ  ｔｏ）」を意味する。
【発明を実施するための形態】
【０００６】
リソース管理システムと関連付けられる方法及びシステムの多様な実施形態を説明する
。リソース管理システムは、計算インスタンス等のリソースを使用して、タスクをスケジ
ュール設定し、かつ実行することができる。いくつかの実施形態において、本明細書に記
載されるシステム及び方法を使用して、タスクは、タスクの実行の推定期間に基づいて、
必要期限時刻前に終了するようにスケジュール設定することができる。いくつかの実施形
態において、本明細書に記載されるシステム及び方法を使用して、タスクのタイムアウト
期間は、タスクの入力データの１つ以上の特徴に応じて異なるように、決定することがで
きる。いくつかの実施形態において、本明細書に記載されるシステム及び方法を使用して
、タスクの実行のためのパラメータ値（例えば、リソースの構成パラメータ）は、タスク
の実行のためのコスト及び／または完了時間を最適化するように自動的に選択することが
できる。
【０００７】
いくつかの実施形態において、リソース管理システムは、ネットワークがアクセス可能
なリソースの動的価格設定、予約、及び割り当てを管理することができる。インターネッ
ト及び／または他のネットワークを介してアクセス可能な１つ以上のサービス（多種多様
なクラウドベースのコンピューティングまたは記憶等）を、分散された一連のクライアン
トへ提供するために、企業または公共機関組織等のエンティティによって設定されたネッ
トワークは、プロバイダネットワークと呼ぶことができる。プロバイダネットワークは、
プロバイダによって提供されるインフラストラクチャ及びサービスを実装かつ分散するた
めに使用される、物理的及び／または仮想化されたコンピュータサーバー、記憶装置、ネ
ットワーク接続機器等の多様なリソースプールをホストする無数のデータセンターを含む
ことができる。リソースは、いくつかの実施形態において、仮想または物理的計算インス
タンスまたは記憶インスタンス等、「インスタンス」と呼ばれる単位において、クライア
ントへ提供されてもよい。仮想計算インスタンスは、例えば、指定された計算能力（ＣＰ
Ｕの種類及び数、メインメモリサイズ等を示すことによって特定されてもよい）、及び指
定されたソフトウェアスタック（例えば、これによってハイパーバイザの上位で稼動する
ことができる、オペレーティングシステムの特定のバージョン）を備える１つ以上のサー
バーを含むことができる。異なる実施形態において、プロバイダネットワークのリソース
を実装するために、汎用または特殊コンピュータサーバー、記憶装置、ネットワーク機器
等を含む、いくつかの異種のコンピューティングデバイスが単独または組み合わされて使
用されてもよい。
【０００８】
いくつかの実施形態において、プロバイダネットワークの運用者は、そのクライアント
のために、柔軟な一連のリソース予約、制御、及びアクセスインターフェースを実装する
ことができる。例えば、プロバイダネットワークのリソースマネージャーは、クライアン
トが、リソースインスタンスについて学習、リソースインスタンスを選択、リソースイン
スタンスへのアクセスを購入、及び／またはリソースインスタンスを予約することを可能
にする、プログラム的リソース予約インターフェースを（例えば、ウェブサイトまたは一
連のウェブページを介して）実装することができる。このようなインターフェースは、リ
ソースカタログの閲覧を可能にする能力を含み、サポートされた異なる種類またはサイズ
のリソースの詳細及び仕様、サポートされた異なる予約種類またはモード、価格設定モデ
ル等を提供することができる。一実施形態において、プロバイダネットワークは、例えば
、長期的予約、オンデマンドのリソース割り当て、またはスポット価格ベースのリソース
割り当て等、いくつかの異なる購入モード（本明細書において、予約モードとも参照され
てもよい）をサポートすることができる。長期的予約モードを使用すると、クライアント
は、リソースインスタンスに対して低価格の１回限りの前払いを行ない、１年間または３
年間等の指定期間にわたってそれを予約し、そのインスタンスに対して低価格の時間あた
りの料金を支払うことができ、クライアントは、予約の期間にわたって利用可能な予約さ
れたインスタンスを有することが保証される。オンデマンドモードを使用すると、クライ
アントは、長期間の約束または前払いをすることなく、１時間（または何らかの適切な時
間単位）毎に容量に対して支払うことが可能である。スポット価格モードにおいて、クラ
イアントは、特定の種類のリソースに対して支払うことを望んでいる、単位時間あたりの
最高価格を指定することが可能であり、クライアントの最高価格が、少なくとも部分的に
供給及び需要によって決定された動的スポット価格を超えた場合、その種類のリソースが
クライアントに提供されることになる。いくつかの実施形態において、リソースインスタ
ンスの動的にサイズ変更可能なプールは、異なる予約タイプまたはモードのために確保さ
れてもよく、例えば、長期的に予約されたインスタンスはあるプールから、オンデマンド
インスタンスは別のプールから等と割り当てられてもよい。リクエストされたリソースの
供給が需要を超える期間中、スポット価格は、オンデマンドモードの価格よりもはるかに
低くなり得る。いくつかの実装において、スポット価格がクライアントによって指定され
た最高の指値を上回って上昇した場合、リソース割り当ては中断されてもよく、すなわち
、以前にクライアントに割り当てられていたリソースインスタンスは、リソースマネージ
ャーによって回収されてもよく、より高い価格を支払うことを望んでいる誰か他のクライ
アントに割り当てられてもよい。いくつかの実施形態において、他の購入モードまたはモ
ードの組み合わせがリソースマネージャーによって実装されてもよい。
【０００９】
いくつかのクライアントは、多様な価格設定オプション、リソースサイズ等の中で利用
可能な選択肢を完全に利用することを所望する場合があり、クライアントは、必要とする
リソースインスタンスのそれぞれの詳細を指定することを希望している場合がある。しか
しながら、所定の種類のアプリケーションでは、いくつかのクライアントは、アプリケー
ションが指定された期限以前かつ指定された予算以内で完了する限り、正確にどのタイプ
のリソースがいつ利用されるかに関して懸念しない場合がある。例えば、生物情報工学、
物理、または天文学アプリケーションを使用する、可能性として何ヶ月間もの長い計算列
を実行することを希望する科学者または研究者は、かなり限られた予算しかない場合があ
り、したがって、計算のより低い合計コストの代償として、リソース選択及びスケジュー
ル設定に関して厳密な制御をトレードオフとすることを希望している場合がある。いくつ
かの事例では、クライアントは、正確にどのリソースが使用されるか、またはいつ使用さ
れるかに関わりなく、所与のタスクが可能な限り最低のコストで完了されることだけを所
望する場合がある。他のクライアントは、使用されるインスタンスの合計数及び／または
サイズ、またはデータ転送タスクの場合には、指定されたソースから指定された転送先へ
転送されるデータの合計量等、いくつかの制約を指定することを希望する場合があり、リ
ソースの選択をリソースマネージャーに委ねることを希望する場合がある。いくつかのク
ライアントの場合、リソースマネージャーに、リソースを選択し、アプリケーションのサ
ブタスクをスケジュール設定することを可能にすることは、任意の金銭的利点とは無関係
に、それ自体、利点と見なされる場合がある。そのような柔軟性を与えられた場合、リソ
ースマネージャーは、より広範な一連のクライアントの必要性を満たすように、より効果
的なスケジュール設定の決定を行うことが可能になってもよく、例えば、長期的計算タス
クの部分は、リソースがあまり利用されていない間のリソースでスケジュール設定されて
もよく、それらのリソース上の（科学者または研究者よりも高い価格設定料金を支払う意
思があり得る）他の顧客からの作業負荷が増加すると、一時停止または一時中断されても
よい。プロバイダネットワークのリソースが関連付けられた価格設定ポリシーを含むプー
ルに体系化される実施形態において、長期的計算の任意の所与の時間中に使用される予定
のリソースインスタンスは、例えば、プールのリソースの現在の価格設定及びプールの現
在の利用度に基づいて、例えば、スポットインスタンスプールまたはオンデマンドインス
タンスプール等の適切なプールから選択されてもよい。
【００１０】
このような一実施形態に従い、このような環境のリソースマネージャーは、クライアン
トのために実施されるタスクの仕様を含むタスク実行クエリを受信することができ、仕様
は、タスクの完了のための関連目標期限、及びタスクの完了のための関連予算制約を有す
る。これに応答して、リソースマネージャーは、タスクの実行計画を生成することができ
、実行計画は、タスクの少なくとも一部を実施するために、選択されたリソースプールの
うちの１つ以上のリソースを使用することを含む。リソースプールは、リソースプールの
価格設定ポリシー及びタスク仕様の分析に少なくとも部分的に基づいて選択されてもよい
。リソースプールまたはリソースタイプを選択する際に、過剰なオーバーヘッドを用いる
ことなく一時中断後にタスクまたはサブタスクを再開することができるか等、他の因子も
考慮されてもよい。リソースマネージャーは、例えば、計画の承認を受信するために、い
くつかの実施形態において、実行計画の指標をクライアントに提供することができる。リ
ソースマネージャーは次いで、選択されたリソースプールのリソース上で、タスクの少な
くとも一部の実行をスケジュール設定することができる。
【００１１】
１つの単純なシナリオにおいて、タスク全体が１つの作業単位としてスケジュール設定
されてもよく、タスク完了後、クライアントがタスク完了を通知されてもよい。しかしな
がら、多数のシナリオにおいて、タスクは、クライアントによって定義された明示的なサ
ブタスク境界に基づいて、またはリソースマネージャーによる自動化されたサブタスク生
成に基づいてのいずれかで、より小さいサブタスクに分割されてもよい。一実施形態にお
いて、クライアントには、各サブタスクの詳細を指定するか、自動化されたサブタスクス
ケジュール設定オプションを選択するかのいずれかの機会が提供されてもよい。クライア
ントは、異なる実施形態において、例えば、タスクまたは個別のサブタスクの割り込み可
能特徴、サブタスクのいずれかまたは全てを並列に実行できるか、タスクまたはサブタス
クの性能要件または所望されるリソースサイズ等、多様なタスク及びサブタスクの特性を
指定することができる。いくつかの実施形態において、期限及びまたは予算制約は、サブ
タスクレベルならびにタスクレベルで、またはタスクレベルの代わりにサブタスクレベル
で指定されてもよい。
【００１２】
いくつかの実施形態において、プロバイダネットワークは、複数の地理的領域に体系化
されてもよく、各領域は、１つ以上の利用可能ゾーンを含むことができる。このため、１
つの利用可能ゾーンは、１つ以上の個別の場所またはデータセンターを含むことができ、
所与の利用可能ゾーン内のリソースが、他の利用可能ゾーン内の障害から保護されるよう
な方式で設計される。すなわち、１つの利用可能ゾーン内の障害は、任意の他の利用可能
ゾーン内の障害になることが期待されなくてもよく、したがって、リソースインスタンス
の利用可能プロファイルは、異なる利用可能ゾーン内のリソースインスタンスの利用可能
プロファイルとは独立的であることを意図する。クライアントは、それぞれの利用可能ゾ
ーン内で複数のアプリケーションインスタンスを起動することによって、単一場所での障
害から、アプリケーションを保護することが可能であってもよい。同時に、いくつかの実
施形態において、廉価かつ短い待ち時間のネットワーク接続性は、同じ地域的領域内に存
在するリソースインスタンス間に提供されてもよい（そして、同じ利用可能ゾーンのリソ
ース間のネットワーク伝送がさらに高速であってもよい）。いくつかの実装において、ク
ライアントは、タスク及び／またはサブタスクのための好ましい利用可能ゾーンを指定す
ることも可能であってもよい。
【００１３】
リソースマネージャーは、クライアントのタスク及び／またはサブタスクに最も適切な
リソース及び／またはリソースプールを特定するためのその試みにおいて、指定された詳
細設定及び特性、目標期限（単数または複数）、ならびに予算制約を使用することができ
る。いくつかの実施形態において、リソースマネージャーは、リソース選択及びスケジュ
ール設定に役立てるためにリソース使用履歴を利用するように構成されてもよい。例えば
、クライアントがそれまでにスケジュール設定した同様なタスクを有する場合、リソース
マネージャーは、現在のタスクの割り込み可能性を推測するために、それより以前のタス
クで収集されたメトリクス（タスクまたはサブタスクが一時中断されて再開されたか、い
つ一時中断されて再開されたか等）を使用することが可能であってもよく、それによって
、リソースマネージャーが、より優れたプール選択決定を行うことを可能にすることがで
きる。リソースマネージャーが、著しいオーバーヘッドなしに、クライアントのサブタス
クを再開できると決定することが可能である場合、より安価なスポットリソースインスタ
ンス（短時間の通知または通知なく一時中断できる）が、潜在的により高価なオンデマン
ドインスタンスの代わりの適切な選択肢であってもよい。いくつかの実施形態において、
クライアントが、サブタスクを並列に実施できることを明示的に示さない場合であっても
、リソースマネージャーは、クライアントによって提供されたタスク仕様（またはクライ
アントのリソース使用履歴）を分析し、任意のサブタスクを実際に並列に実行できるかど
うかを決定することが可能であってもよい。同様に、いくつかの実施形態において、リソ
ースマネージャーは、タスク仕様の分析に基づいて、及び／またはリソース使用履歴に基
づいて、タスクまたはサブタスクに必要であり得るリソースの性能評価を特定することが
可能であってもよい。
【００１４】
いくつかの実施形態において、リソースマネージャーによって、いくつかの異なる種類
のタスク及びサブタスクがスケジュール設定されてもよい。例えば、一実施形態において
、リソースマネージャーは、データ転送タスク及びサブタスク、ならびに計算タスク及び
サブタスクをスケジュール設定することが可能であってもよい。計算タスクが、１つ以上
のアプリケーションの実行成功を必要とする場合があるが、データ転送タスクは（その名
前が暗示するように）、ソースデバイスから転送先デバイスへの指定されたデータセット
の移動を含む場合がある。例えば、オンラインビデオのプロバイダは、大量のビデオデー
タセットを、プロバイダネットワークの１つのデータセンターにある一連の記憶装置から
、別のデータセンターへ複製またはコピーすることを希望する場合があり、プロバイダは
、リソースマネージャーが、全体的な期限が満たされる限り、経時的にデータの転送をス
ケジュール設定することを可能にすることによって有効なコスト節約を利用することを希
望する場合がある。データ転送タスクまたはサブタスクの転送元または転送先デバイスは
、プロバイダネットワーク内部にあってもよく、またはクライアントネットワークの一部
を形成してもよい（すなわち、転送元または転送先は、クライアントによって制御、管理
、または所有される施設またはデータセンターに位置してもよい）。いくつかの実施形態
において、クライアントタスクは、計算サブタスク及びデータ転送サブタスクの両方を含
むことができる。
【００１５】
異なる実施形態において、データ転送タスクまたはサブタスクのために、多様な異なる
技術が使用されてもよい。例えば、クライアントネットワークデバイスとプロバイダネッ
トワークリソースとの間のデータ転送の場合、リソースマネージャーは、（ａ）複数のク
ライアントによって共有される、または共有可能であるネットワーク経路、（ｂ）１つの
クライアントによる使用専用であり、クライアントのネットワーク機器とプロバイダネッ
トワークの機器との間のクライアントリクエストに設置された直接物理的リンクを含むネ
ットワーク経路で、非公開ネットワーク経路または「直接接続」経路と参照されてもよい
、または（ｃ）取り外し可能ディスクドライブ、ＤＶＤ等の携帯用物理的記憶装置の転送
を使用する選択肢を有することができる。
【００１６】
一実施形態において、リソースマネージャーは、いくつかの異なる種類のタスク実行ク
エリをサポートすることができる。上記のように、いくつかのタスク実行クエリは、時間
制約（期限等）及び予算制約の両方を指定することができ、リソースマネージャーは、こ
れに応答して、これらの制約両方を満たすことを目的とする実行計画を生成することがで
きる。第２のタイプのタスク実行クエリにおいて、クライアントは、予算制約を指定し、
タスク仕様を提供し、事実上、リソースマネージャーに「この予算限界内で指定されたタ
スクをどの程度速やかに完了できるか？」を問うことができる。第３の種類のタスク実行
クエリにおいて、クライアントは、時間制約を指定し、事実上、リソースマネージャーに
「これらの時間制約内でこのタスクを完了するために見積もることができる最低のコスト
はいくつか」を問うことができる。いくつかの実施形態において、別のサポートされるク
エリの種類は、リソースマネージャーが、例えば、指定された予算限界または指定された
期限さえもなく、最低の概算実行コストで実行計画を生成することを単にリクエストする
ことができる。さらに別のクエリタイプは、インスタンスが存在する場所に依存せず、タ
スクのために取得される必要または最低数のリソースインスタンスを指定することができ
る。特定の期限または目標予算を含まずに、指定されたデータセットを転送するリクエス
ト等、他のクエリタイプもサポートされてもよい。各タイプのクエリに対して、リソース
マネージャーは、必要な作業を記述するタスク仕様、ならびにクライアントによって指定
された他の特性または特徴を分析し、クライアントのクエリに対する回答を取得しようと
最大限の努力を行うことができる。
【００１７】
クライアントは、いくつかの実施形態において、タスク実行クエリを指定するために、
インターフェースマネージャー（いくつかの実施形態において、リソースマネージャー内
部に組み入れられてもよい）によって実装されたインターフェース（１つ以上のウェブペ
ージ、アプリケーションプログラミングインターフェースまたはＡＰＩ、あるいはコマン
ド行インターフェース等）を使用することができる。パラメータ及び制約を変更すること
によって、クライアントは、特定の実行計画に合意する前に、多様な異なる「仮定」シナ
リオを試すことが可能であってもよい。いくつかの実施形態において、クライアントは、
インターフェースを使用して、その他タスクまたはサブタスクの最新実行ステータスを視
認することが可能であってもよい。いくつかの実施形態において、実行されたタスク及び
サブタスクに関する追加情報は、プログラム出力、エラーログ、実行ログ等、インターフ
ェース（単数または複数）を介して利用可能であってもよい。
例示的なシステム環境
【００１８】
図１は、少なくともいくつかの実施形態に従う、リソース管理システムのための例示的
システム環境を示す。リソース管理システム１００は、領域１１２Ａ及び１１２Ｂ等の複
数の地理的領域を含むプロバイダネットワーク１１０を含む。各地理的領域１１２は、領
域１１２Ａ内の利用可能ゾーン１２０Ａ及び１２０Ｂ、及び領域１１２Ｂ内の利用可能ゾ
ーン１２０Ｋ及び１２０Ｌ等の１つ以上の利用可能ゾーン１２０を含むことができる。各
利用可能ゾーン１２０は、これによって、利用可能ゾーン１２０Ａ内のリソースインスタ
ンス１３０Ａ、１３０Ｂ、１３０Ｄ、１３０Ｅ、１３０Ｇ、及び１３０Ｈ等の複数のリソ
ースを含むことができる。インスタンスは、いくつかの実施形態において、予約インスタ
ンスプール１２１Ａ、オンデマンドインスタンスプール１２１Ｂ、及びスポットインスタ
ンスプール１２１Ｃ等、多様なリソースプールに体系化することができる。異なる利用可
能ゾーン１２０内の多様なリソースインスタンス１３０は、クライアント１４８による使
用のために予約及び／または割り当てることができる。各インスタンスプール１２１は、
関連リソース管理及び価格設定ポリシーを有し、例えば、リソースインスタンスの予約ま
たは割り当てを中断することができるか、１つのクライアントの予約を別のクライアント
に再販売できるか、プールのインスタンスに対して有効な異なる種類の静的及び動的価格
決定率等を規定する。明確にするために、実装され得る多様な種類のインスタンスプール
１２１は、図１において、利用可能ゾーン１２０Ａのみに示され、他の利用可能ゾーンは
、それらの独自の一連のインスタンスプール１２１を有することができる。全ての利用可
能ゾーンが同じ一連のプールを実装しなくてもよく、例えば、いくつかの利用可能ゾーン
は、予約インスタンスプール及びオンデマンドプールだけを実装してもよく、スポットイ
ンスタンスプールを実装しなくてもよい。いくつかの実施形態において、現在アイドルな
インスタンスを含む「利用可能インスタンス」プール等、図１に示されない他のインスタ
ンスプールが実装されてもよく、そこから、インスタンス有効リクエストに応答して、イ
ンスタンスが他のプールへ移動してもよい。プールは、論理的集合または集積を表すこと
ができるので、例えば、同じプールまたはサブプール内の２つのインスタンスの存在は必
ずしも、その２つのインスタンスに使用されるハードウェアの物理的場所について何かを
暗示しなくてもよいことに注意されたい。
【００１９】
図示された実施形態において、リソース管理システム１００は、クライアント１４８に
よって提出されたリクエストに応答して、多様な操作を実行するように動作可能なリソー
スマネージャー１８０を含む。リソースマネージャー１８０のインターフェースマネージ
ャー構成要素１８３は、以下にさらに詳細を記載するように、いくつかの実施形態におい
て、クライアント１４８が、タスク仕様、目標、要件、期限、及び／または予算制約が指
定される、タスク実行クエリを提出することを可能にする１つ以上のプログラムインター
フェースを実装し、タスク実行計画を生成することによって、このようなリクエストに応
答することができる。いくつかの実施形態において、リソースマネージャー１８０内部に
含まれる代わりに、インターフェースマネージャー１８３は、外部に実装されてもよい。
許容可能なタスク実行計画が見出された場合、リソースマネージャー１８０は、１つ以上
の利用可能ゾーン１２０にある１つ以上のプール１２１から選択されたリソース１３０を
使用して、計画に従ってタスクをスケジュール設定することができる。いくつかの実施形
態において、リソースマネージャー１８０は、タスクを開始する前に、クライアントから
のタスク実装リクエストを待機することができる。リソースマネージャー１８０によって
実装されたインターフェースは、クライアントが、例えば、多様なアプリケーションを実
行及び／またはアクセスするために、多様な種類のサービスを取得するように所望の種類
のインスタンス１３０を検索、閲覧、予約、及び入手することを可能にする等、多様な他
の機能もサポートすることができる。図１に示されるインスタンス１３０は、利用可能ゾ
ーン１２０に属すると示されるが、他の実施形態において、プロバイダネットワーク１１
０は、異なって体系化されてもよく、例えば、いくつかの実施形態において、利用可能ゾ
ーンは実装されなくてもよい。いくつかの実施形態において、利用可能ゾーン内部にイン
スタンスプールが実装されてもよく（例えば、各利用可能ゾーンが、その独自の予約イン
スタンスプールを有することができる）、一方、他の実装において、１つのインスタンス
プールまたはサブプールが、複数の利用可能ゾーンにまたがってもよい。
【００２０】
図１に示されるように、リソースマネージャー１８０は、クライアント１４８から、多
様なタイプのタスク実行クエリを受信することができる。１つの種類のクエリにおいて、
クライアントは、使用される実行可能プログラム（単数または複数）、タスクの完了の時
間制約、及び例えば、クライアントがタスクの完了のために支払う用意がある最大額を示
す予算制約等のタスク仕様を指定することができる。いくつかの実施形態において、例え
ば、クライアントによって示される指定期限または指定予算限度を含めずに、リソースマ
ネージャーが最低の推定コスト実行計画で応答することだけをリクエストするクエリがサ
ポートされてもよい。別の実施形態において、クライアントは、インスタンスの特定の利
用可能ゾーンまたは他の場所詳細を示すことなく、タスクのために必要または最低数のリ
ソースインスタンスを指定することができる（いくつかの事例において、必要なインスタ
ンスの種類／サイズも指定することができる）。データ転送タスクの場合、いくつかの実
施形態において、例えば、特定の予算限度または期限を含めずに、転送されるデータセッ
ト、ならびに転送元／転送先情報が指定されてもよい。これに応答して、リソースマネー
ジャー１８０は、リクエストにおいてクライアントによって提供された情報、ならびに多
様なリソースプール１２１、及びいくつかの事例においてリソース使用量データに有効な
価格設定及び／または割り込み可能ポリシー等の追加の情報源を使用して、タスクの１つ
以上の実行計画を生成することができる。リソース使用量データ（いくつかの実施形態に
おいて、リソース管理データベース１９１から呼び出されてもよい）は、例えば、クライ
アントのタスクに有用であり得る所与の一連のインスタンス１３０に対するリクエストし
ているクライアントの過去のタスク実行履歴、リソース利用履歴、請求履歴、及び全体的
なリソース使用傾向を含むことができる。いくつかの事例において、リソースマネージャ
ーは、将来のリソース使用の予測を開発するために所与の一連のリソースインスタンスの
過去のリソース使用量データ及び傾向を使用し、実行計画（単数または複数）を開発する
際にこれらの予測を使用することができる。タスク仕様及びこれらの追加のデータ情報源
のいくつかまたは全てからの情報の分析に基づいて、リソースマネージャー１８０は、実
行計画の一環としてタスクの少なくとも一部分を実施するために１つ以上のリソースプー
ル１２１を選択することができる。いくつかの実施形態において、リソースマネージャー
１８０は、実行計画の通知をクライアント１４８へ送信することができる。クライアント
１４８からのタスク実装リクエストに応答して、リソースマネージャー１８０は、実行計
画に特定されたプールからのリソースインスタンスで、タスクの少なくとも一部分をスケ
ジュール設定及び／または開始することができる。いくつかの実施形態において、タスク
実行クエリとは別のタスク実装リクエストは必要とされなくてもよく、すなわち、リソー
スマネージャー１８０が、実行クエリに示された多様な制約を満たす実行計画を見出すこ
とができる場合、実行計画は、クライアント１４８とのさらなる相互作用なく、開始され
てもよい。
【００２１】
いくつかの実施形態において、インターフェースマネージャー１８３またはリソースマ
ネージャー１８０によって実装されたインターフェースは、クライアント１４８が、実行
計画を生成する際に有用であり得る多様な詳細設定または指示を指定することを可能にす
ることができる。例えば、一実施形態において、クライアント１４８は、例えば、さらに
微細なスケジュール設定のために、タスクを分割することができるサブタスクの詳細を指
定することができる。クライアントが、リソースマネージャー１８０にタスクをサブタス
クに分割させることを希望している場合、代わりに、自動化されたサブタスク生成のため
の詳細設定または設定が指定されてもよい。例えば、いくつかの事例において、クライア
ントのアプリケーションは、周知の実行パターンまたは業界標準方法論（マップ削減プロ
グラミングフレームワーク、あるいはメッセージ通信インターフェースまたはＭＰＩを使
用する多様な並列プログラミング手法のうちの１つ等）に従う場合があり、リソースマネ
ージャー１８０は、クライアントによって提供されたタスク仕様または記述を分析した結
果、サブタスク境界を決定することが可能であってもよい。いくつかの実施形態において
、タスクまたはサブタスクの割り込み可能設定または詳細設定が実行クエリに含まれても
よい。タスクアプリケーション（単数または複数）の性質が、所与のタスクまたはサブタ
スクが、実質的なオーバーヘッドまたは作業を再実行する必要なく、一時停止されてから
、後で再開されてもよい場合、タスクは、例えば、スポットインスタンスに最適であって
もよく、逆に、タスクまたはサブタスクの状態を再開するために保存することが困難であ
る場合、あるいは割り込みされるとタスク全体を繰り返さなければならない場合、タスク
は、オンデマンドインスタンスまたは予約インスタンスにより最適であってもよい。いく
つかの実施形態において、リソースマネージャー１８０は、クライアントが割り込み詳細
設定を提供することに依存する代わりに、例えば、タスク仕様の分析、これまでに提出さ
れたタスクの分析、または他の因子に基づいて、割り込み特性を推論することが可能であ
ってもよい。いくつかの実施形態において、クライアントのタスクに使用される特定のプ
ールの選択は、割り込み可能性ではなく、期限及び価格に大幅に基づいて行われてもよく
、例えば、クライアントのタスクが、割り込み後に、比較的小さいオーバーヘッドで再開
できる場合であっても、単にタスク期限が近く、かつ小さい割り込みオーバーヘッドであ
っても潜在的に期限を守れなくする可能性があるため、スポットインスタンスの代わりに
、オンデマンドインスタンス等の割り込み不可能なインスタンスを使用することが推奨さ
れてもよい。
【００２２】
クライアント１４８は、いくつかの実施形態において、十分なリソースが利用可能であ
る場合にいくつかまたは全てのサブタスクを並列で実行できるかを示す等、そのアプリケ
ーションの並列化可能性特徴も指定することができる。一実施形態において、上記の割り
込み可能性特徴の場合と同様に、リソースマネージャーは、タスク仕様を分析して、任意
のサブタスクが並列化可能であるかを特定することが可能であってもよい。多様なタスク
またはサブタスクのために使用されるリソースの好ましい性能評価もまた、いくつかの実
施形態において、インターフェースを介して指定することができ、例えば、クライアント
は、特定のＣＰＵアーキテクチャの４つの３ＧＨｚコアに等しい性能を備えるリソースが
、可能であれば所与のサブタスク専用でなければならないことを示すことができる。クラ
イアント１４８がリソース性能要件を指定しない場合、リソースマネージャー１８０は、
ここでも、タスク仕様及び／または過去に実行された同様なタスクのリソース使用履歴の
分析に基づいて、使用されるインスタンスのサイズを選択することができる。いくつかの
実施形態において、場所に関係する詳細設定（タスクをスケジュール設定すべき利用可能
ゾーンまたは領域等）もまた、クライアントによって提供されてもよい。クライアントの
これまでのリソース使用履歴、ならびにクライアントが使用中または予約中のリソースを
現在有する場所もまた、クライアントのタスク実行のためのインスタンス場所を決定する
ために使用されてもよい。
【００２３】
いくつかの実施形態において、計算タスク（プログラム実行可能ファイルが成功して実
行されることが必要）及びデータ転送タスク（指定されたデータセットが、ソースデバイ
スからターゲットデバイスへ成功して運ばれることが必要）の両方がサポートされてもよ
い。このような実施形態において、所与のタスクは、計算サブタスクならびにデータ転送
サブタスクを含むことができる。いくつかの実装において、所与のサブタスクまたはタス
クにおいて、データ転送操作は、計算操作と組み合わされてもよい。
【００２４】
いくつかの実施形態において、リソースマネージャー１８０は、いくつかの種類のタス
ク実行クエリをサポートすることができる。例えば、クライアント１４８は、タスクの期
限を入力する代わりに、タスクを所与の予算制約内で完了することができる可能な限り早
い時刻を決定することを望む場合がある。あるいは、クライアント１４８は、予算制約を
指定する代わりに、目標期限前にタスクを完了するコストを決定することを希望する場合
がある。上記のように、いくつかの実施形態において、例えば、最低推定コスト計画をリ
クエストするクエリ、指定数及び／または種類のリソースインスタンスを入手することを
含む計画をリクエストするクエリ、あるいは指定された量のデータまたは特定のデータセ
ットのデータ転送のための計画をリクエストするクエリ等、多様な他の種類のタスク実行
クエリもサポートされてもよい。リソースマネージャー１８０によってサポートされるタ
スク実行リクエストのためのインターフェースは、クライアントが、特定の実行計画が実
装のために選択または承認される前に、このような異なる種類のクエリの組み合わせを使
用して、多様な異なる「仮定シナリオ」を指定することを可能にすることができる。例え
ば、第１の計算サブタスクまたはデータ転送サブタスクの実行を開始することによって、
実行計画が実装されると、クライアント１４８は、いくつかの実施形態において、インタ
ーフェースを介して、実行の現在のステータスを視認することが可能になってもよい。
【００２５】
サブタスクが実行されると、または所与のサブタスクまたはタスクの実行中であっても
、リソースマネージャー１８０は、いくつかの実施形態において、例えば、プロバイダネ
ットワーク内の現在の運用状態及び価格に基づいて、実行計画を再生成または更新するこ
とができる。例えば、特に長時間実行するタスクまたはサブタスクの場合、最初の実行計
画が策定されてから、利用レベルまたは価格が変化している場合があり、リソースマネー
ジャー１８０がタスクの残りの部分の計画を修正することになり得る。加えて、所与のサ
ブタスクは、最初の実行計画が生成されたときに推定されたよりも長くかかる、またはよ
り多くのリソースを使用する可能性があり、これもまた残っているサブタスクのスケジュ
ール設定に影響を与えかねない。いくつかの実施形態において、リソースマネージャー１
８０は、実行計画が変更される予定があると、クライアント１４８に通知（またはそこか
ら承認を取得）してもよく、他の実施形態において、クライアントによって指定された価
格設定及び／または時刻設定の本来の制約が満たされる限り、リソースマネージャー１８
０は、計画に対する変更をクライアントに通知する義務を負わなくてもよい。
リソースインスタンスカテゴリ及び関連価格設定モデル
【００２６】
上記のように、プロバイダネットワークのリソースインスタンス１３０は、いくつかの
実施形態において、いくつかの異なる側面に基づいて、クラスまたはカテゴリにグループ
化することができ、異なるクラスと関連付けられた価格設定ポリシーは、異なる。カテゴ
リのうちのいくつかは、図１に示されるように、リソースがプールに体系化される様式に
反映することができる。図２ａ及び２ｂは、少なくともいくつかの実施形態に従う、例示
的なリソースインスタンス分類手法を示す。図２ａは、インスタンス割り当てのタイミン
グまたは期間、すなわち、インスタンスがいつクライアントによって取得されるか、クラ
イアントによっていつ解放されるかに少なくとも部分的に基づいて分類される手法を示す
。リソースインスタンスの３つの上位のタイプ２０１が示され、予約インスタンス２０３
、オンデマンドインスタンス２０５、及びスポットインスタンス２０７は、各々それぞれ
の価格設定ポリシー２０３Ｐ、２０５Ｐ、及び２０７Ｐを有する。一実施形態において、
クライアント１４８は、インスタンスの低価格の１回限りの前払いを支払ってから、次い
で、予約の期間中、任意の所望される時点でインスタンスの実際の使用に対して低価格の
時間当たりの料金を支払うことによって、価格設定ポリシー２０３Ｐに従って１年間また
は３年間等、かなり長期間にわたってインスタンスを予約することができる。このように
、クライアント１４８は、長期間の予約をすることによって、その予約したインスタンス
２０３が必要な場合にいつでも利用可能であることが保証されてもよい。
【００２７】
クライアント１４８が、長期間の予約をすることを希望しない場合、その代わりに、ク
ライアントは、オンデマンドインスタンス２０５（またはスポットインスタンス２０７）
を使用することを選択してもよい。オンデマンドインスタンス２０５の価格設定ポリシー
２０５Ｐは、クライアント１４８が、長期的な約束または前払いなく、時間毎にリソース
容量に対して支払うことを可能にすることができる。クライアント１４８は、アプリケー
ションの必要性に基づいて、使用されるリソース容量を増加または減少することができ、
使用されたインスタンスの時間あたりの料金のみを支払いさえすればよい。いくつかの事
例において、オンデマンドインスタンスの時間あたりの価格設定は、比較的長期間の予約
は、オンデマンドインスタンスによって提供される潜在的により動的な収益ストリームよ
りも安定した収益ストリームをプロバイダネットワークの運用者に提供することができる
ため、予約されたインスタンスの時間あたりの料金よりも高くてもよい。スポットインス
タンス２０７は、第３のタイプのリソース購入及び割り当てモデルを提供することができ
る。スポット価格設定ポリシー２０７Ｐは、クライアント１４８が、クライアントが支払
うことを希望する最大の時間当たりの価格を指定することを可能にすることができ、リソ
ースマネージャー１８０は、クライアントが支払うことを希望する価格、及びスポットモ
デルをサポートするために利用可能なインスタンスの数に基づいて動的に、所与の一連の
リソースインスタンス１３０のスポット価格を設定することができる。クライアント１４
８からの指値が現在のスポット価格に合致またはそれを上回る場合、インスタンスがクラ
イアントに割り当てられてもよい。スポット価格がスポットインスタンス２０７を使用す
るクライアントの指値を超えて上昇すると、クライアントによるインスタンスへのアクセ
スは取り消されてもよい（例えば、インスタンスがシャットダウンされてもよい）。
【００２８】
予約インスタンス２０３、オンデマンドインスタンス２０５、及びスポットインスタン
ス２０７の価格もまた、インスタンスが位置する利用可能ゾーン１２０または地理的領域
に基づいて異なってもよい。プロバイダネットワーク１１０の運用者は、異なる物理的場
所でデータセンターを設置するために異なるコストを支払わなければならなかった場合が
あり、ネットワーク接続性、冷房等、インフラストラクチャ及び保守サービスに対して異
なる、場所に依存した継続的なコストを支払わなければならない場合があり、このために
、異なる利用可能ゾーン及び／または領域に対する異なる価格設定ポリシーとなり得る。
供給及び需要における変動もまた、異なる種類のインスタンスに対する時間変動価格にな
り得る。言うまでもなく、所与の長期的な予約の価格は典型的に、クライアントが予約を
完了した後、不変のままであってもよい。
【００２９】
いくつかの実施形態において、予約インスタンス２０３は、期待される稼働率に基づい
て、さらに分類されてもよい。特定の予約インスタンス１３０の稼働率は、インスタンス
が予約されている合計時間量に対して、インスタンスが有効である時間量の比率として定
義されてもよい。稼働率は、いくつかの実装において、利用率とも参照される場合がある
。クライアント１４８が、インスタンスが予約されている時間のうちの比較的小さい割合
の間、予約インスタンスを使用することが期待される場合（例えば、１年間の予約の３０
％〜３５％）、クライアントは、低稼働率インスタンス２１５としてインスタンスを予約
することを決定してもよく、関連価格設定ポリシー２１５Ｐに従って割引された時間当た
りの使用料金を支払うことができる。クライアント１４８が、インスタンスがほとんどの
時間稼動していることを要求する安定した状態の作業負荷を有することを期待する場合、
クライアントは、高稼働率インスタンス２１１を予約し、可能性としてさらに低い時間あ
たりの使用料金を支払う場合があるが、いくつかの実施形態において、時間あたりの料金
は、価格設定ポリシー２１１Ｐに従うと、実際の使用時関数に関係なく、予約の全体期間
に対して課金されてもよい。対応する価格設定ポリシー２１３Ｐでは、中稼働率インスタ
ンス２１３の選択肢も、いくつかの実施形態でサポートされてもよく、前払いコスト及び
時間あたりのコストは、対応する高稼働率コストと低稼働率コストとの中間に位置する。
【００３０】
インスタンス価格設定は、他の因子にも基づいて異なってもよい。例えば、計算インス
タンスの場合、異なるＣＰＵの性能能力及びメモリサイズ等の計算サーバーの他の構成要
素が関与し得る。図２ｂは、インスタンス性能評価２５１に基づく、計算インスタンスの
例示的分類を示す。大型インスタンス２５３は、中型インスタンス２５５よりも大きい計
算容量を有することができ、中型インスタンスは、小型インスタンス２５７よりも大きい
計算容量を有することができる。したがって、異なる価格設定ポリシー２５３Ｐ、２５５
Ｐ及び２５７Ｐが異なるサイズのインスタンスに実装されてもよい。一実施形態において
、クライアントによって提出されたタスク実行クエリは、取得されるインスタンスのサイ
ズ及び／またはタイプを指定することができ、タスク実行クエリは、インスタンスが取得
される場所（例えば、どの利用可能ゾーン（単数または複数）か）の決定を、リソースマ
ネージャー１８０に委ねることができる。例えば、タスク実行リクエストは、実質的に、
リソースマネージャーに「私のタスクのために６つの大型インスタンスを割り当てるよう
に実行計画を生成してください。タスクがいつどこで実行されるかの詳細はあなたに任せ
ます」と依頼することができる。いくつかの実施形態において、オペレーティングシステ
ム、ハイパーバイザ、ミドルウェアスタック等のソフトウェア特徴もまた、多様なインス
タンスと関連付けられる価格設定ポリシーを決定する上で考慮されてもよい。計算インス
タンス及び記憶インスタンスの両方で、いくつかの実施形態において、価格設定ポリシー
を開発するために、記憶容量合計、サポートされるＩ／Ｏ速度等、記憶装置の特徴が使用
されてもよい。価格設定ポリシーは、ネットワーク能力及びネットワーク使用量（例えば
、転送されたデータのメガバイト数、及び／またはネットワークトラフィックが伝送され
る距離）によっても決定され得る。他の実施形態において、図２ａ及び２ｂに示された基
本的階層の拡張を含む、他の分類側面及び技法が実装されてもよい。以下にさらに詳細を
説明するように、いくつかの実施形態において、タスク実行クエリに応答して実行計画を
開発する際、価格設定の静的及び動的構成要素、ならびに場所依存及び場所非依存の構成
要素を含む、多様な価格設定ポリシーが、リソースマネージャー１８０によって考慮され
てもよい。価格設定情報のいくつかまたは全ては、リソース管理データベース１９１に記
憶され、そこから呼び出されてもよい。
実行計画生成に使用される情報源
【００３１】
図３は、一実施形態に従う、タスク実行計画を生成するために、リソースマネージャー
１８０によって収集され得るデータの一連の情報源の例を示す。示されるように、リソー
スマネージャー１８０は、クライアント１４８によって提出されたタスク実行クエリ３０
３から、タスク仕様３０７、タスク予算目標（最低の実現可能な推定コストの計画が生成
されるべきであることを示すことによって簡単に表現されてもよい）または制約３０９（
指定された予算目標等）、及び／または期限等のタスクタイミング制約３１１を取得する
ことができる。いくつかの実施形態において、クライアントは、インスタンスカウント要
件３１３（例えば、特定のタイプのＮ個のインスタンスが割り当てられることを要求）及
び／またはデータ転送要件３１５（例えば、指定された転送元から指定された転送先へ、
転送されるデータの量、または転送される特定のデータセットを示す）を指定することが
できる。タスク仕様３０７は、例えば、タスクが計算タスクまたはデータ転送タスクであ
るか、どのプログラムまたは実行可能ファイルがタスクに使用されるか、タスクの成功が
どのように決定されるか、性能関係要件（最低ＣＰＵ能力、メモリサイズ、ネットワーク
帯域幅）等、タスクの多様な詳細を示すことができる。クライアント１４８がサブタスク
を指定することが可能である実施形態において、同じ種類の情報が各サブタスクに指定さ
れてもよい。予算制約及びタイミング制約はまた、いくつかの実施形態において、タスク
レベルだけでなくサブタスクレベルでも、またはタスクレベルの代わりにサブタスクレベ
ルで指定されてもよい。予算制約３０９は、例えば、クライアントがタスクまたはサブタ
スク完了のために支払うことを希望している合計価格、またはクライアントが支払うこと
を希望している最大使用ベースの請求料金を含むことができる。タイミング制約３１１は
、タスクまたはサブタスクが完了される予定の期限を示すことができる。いくつかの実施
形態において、特定の予算制約及び／またはタイミング制約は省略されてもよく、リソー
スマネージャー１８０が、タスク及びサブタスクを計画及びスケジュール設定する際に、
さらにより大きい柔軟性を可能にする。
【００３２】
リソースマネージャー１８０によって使用される価格設定データ３０４は、プロバイダ
ネットワークの多様な場所にある多様な種類のリソース（オンデマンドまたはスポットイ
ンスタンス等）に有効な現在の価格設定、ならびにそのような価格の経時的な過去の変動
を含むことができる。いくつかの実施形態において、リソースマネージャー１８０は、例
えば、過去の価格設定変動に基づいて、将来の価格設定変更を予測する予測モデルを開発
することができる。特に長期的に継続するタスク及びサブタスクの場合、過去の傾向に基
づく将来の価格設定の予測は、クライアントのクエリに対して実行計画を決定する上で有
用であり得る。リクエストしているクライアント１４８のリソース使用量レコード３０５
、ならびにサポートされる多様なタイプのインスタンスの全体的なリソース利用量データ
もまた、クライアントのタスクをどこで、いつ実行すべきかを決定する際に有用であり得
る。リソースマネージャー１８０は、いくつかの実施形態において、クライアントのそれ
までに実行されたタスクと現在のタスク仕様３０７との間の類似性を特定することが可能
であってもよく、リソースマネージャー１８０が、より多くの情報に基づいた選択を行う
ことを可能にする。例えば、１つのシナリオにおいて、タスクＴ１は、利用可能ゾーンＡ
Ｚ１にあるリソースインスタンスＲ１を使用して、所与のクライアントの代理としてより
早く実行されていてもよく、Ｔ１を完了するためにかかった時間の最初の推定は最終的に
、１０％間違っていることが見出された。同じクライアントから、タスクＴ２の新しいタ
スク実行クエリ３０３が受信された場合、Ｔ２のタスク仕様３０７は、Ｔ１のためにその
前に受信されたタスク仕様に非常に類似しているので、リソースマネージャー１８０は、
Ｔ１によって使用されたリソースの記録を使用して、Ｔ２を完了するためにかかるかもし
れない時間のより優れた推定を行うための位置にあり得る。加えて、リソースマネージャ
ー１８０はまた、例えば、使用履歴データが、類似のタスクＴ１が一切の機能的エラーな
く、完了に成功したことを示すため、以前に使用された同じ利用可能ゾーンＡＺ１にある
類似のリソースを使用することを決定することもできる。より一般的なリソース使用量デ
ータ（すなわち、リクエストしているクライアントに特定されないデータ）もまた、現在
のリクエストに使用される特定の場所及びリソースの種類を決定する際に有用であり得る
。例えば、リソースマネージャーは、非常に忙しいゾーンより利用が少ない利用可能ゾー
ンに新しいタスクをスケジュール設定してもよい。将来のリソース利用の予測はまた、過
去の使用量データに基づいて行われてもよく、いくつかの実装において、将来の価格設定
の予測に結びつけられてもよい。価格設定データ３０４及び／または使用量レコード３０
５は、いくつかの実施形態において、リソース管理データベース１９１等のレポジトリに
維持されてもよい。いくつかの実施形態において、リソースマネージャー１８０は、レポ
ジトリから履歴使用量データを取得する代わりに、またはこれに加えて、プロバイダネッ
トワーク内に分散された多様な監視エージェントから、最新のリソース使用量データを取
得することができる。
【００３３】
クエリ３０３の内容とともに、これらのデータのいくつかまたは全てを考慮して、リソ
ースマネージャー１８０は、クライアントの制約を満たす少なくとも１つのタスク実行計
画３５１を生成することができる。タスク実行計画は、多様なサブタスクをいつ及びどこ
で開始すべきか、これらがいつ完了されることが期待されるかの現在の推定、推定コスト
等の詳細を含むことができる。いくつかの実施形態において、タスク実行計画３０３は、
例えば、ＸＭＬファイルまたはいくつかの他の適切な形式において、リソース管理データ
ベース１９１等の永久的ストアにも記憶されてもよい。いくつかの実施形態において、ク
ライアント１４８は、例えば、タスク仕様３０７の複雑度に基づいて、タスク実行計画の
生成に対して指定された額が請求されてもよいが、他の実施形態において、実行計画は、
関連付けられた請求額を含まずに生成されてもよい。一実施形態において、リソースマネ
ージャーが、クライアントによって指定された制約を満たす１つの実行計画３５１さえ生
成することが不可能である場合、リソースマネージャー１８０は、実現可能な実行計画を
もたらし得る、制約に対する代替を示唆することができる。例えば、リソースマネージャ
ー１８０は、クライアントに対し、指定されたタスクは、リクエストされた価格ではリク
エストされた３０日以内に完了することができないが、リクエストされた価格でタスクを
４０日以内に完了することは実現可能であり得ることを示すことができる。実行計画３５
１が許容された後、計画に含まれたスケジュールに従って、リソースマネージャー１８０
によって実施に移すことができる。
コスト最小化タスクスケジューラ
【００３４】
いくつかの実施形態において、本明細書に記載されるシステム及び方法を使用して、タ
スクは、クライアントによって指定されてもよい必要期限時刻前に終了するようにスケジ
ュール設定することができる。プロバイダネットワークの他の使用量データに加えて、類
似のタスクのための以前の実行時間に基づいて、タスクがユーザー指定期限までに完了す
るように自動的にスケジュール設定することができるように、タスクの実行の推定期間が
決定されてもよい。必要期限時刻によって提供される実行ウィンドウの追加された柔軟性
を通じて、タスクを実行するために使用される演算インスタンス及び他のリソースのコス
トを最小限に抑えることができる。
【００３５】
図４は、一実施形態に従う、必要期限時刻スケジュール設定を含むリソース管理システ
ムのための例示的システム環境を示す。図１を参照して上記に検討したように、リソース
管理システム１００は、領域１１２Ａ等の複数の地理的領域を含むプロバイダネットワー
ク１１０を含む。追加の地理的領域は図４には図示されない。各地理的領域１１２は、領
域１１２Ａ内の利用可能ゾーン１２０Ａ及び１２０Ｂ等、１つ以上の利用可能ゾーン１２
０を含むことができる。各利用可能ゾーン１２０は、これによって、利用可能ゾーン１２
０Ａ内のリソースインスタンス１３０Ａ、１３０Ｂ、１３０Ｄ、１３０Ｅ、１３０Ｇ、及
び１３０Ｈ等の複数のリソースを含むことができる。インスタンスは、いくつかの実施形
態において、予約インスタンスプール１２１Ａ、オンデマンドインスタンスプール１２１
Ｂ、及びスポットインスタンスプール１２１Ｃ等、多様なリソースプールに体系化するこ
とができる。異なる利用可能ゾーン１２０内の多様なリソースインスタンス１３０は、ク
ライアント１４８による使用のために予約及び／または割り当てることができる。各イン
スタンスプール１２１は、関連リソース管理及び価格設定ポリシーを有し、例えば、リソ
ースインスタンスの予約または割り当てを中断することができるか、１つのクライアント
の予約を別のクライアントに再販売できるか、プールのインスタンスに対して有効な異な
る種類の静的及び動的価格決定率等を規定する。
【００３６】
図示された実施形態において、リソース管理システム１００は、クライアント１４８に
よって提出されたリクエストに応答して、多様な操作を実行するように動作可能なリソー
スマネージャー１８０を含む。リソースマネージャー１８０のインターフェースマネージ
ャー構成要素１８３は、いくつかの実施形態において、クライアント１４８が必要期限時
刻４０５を含むタスク仕様を提出することを可能にする、１つ以上のプログラムインター
フェースを実装することができる。必要期限時刻は、クライアント１４８がタスクの実行
が完了されることを期待する日時を含むことができる。タスク仕様４０５は、実施される
関数（単数または複数）または実行されるプログラム（単数または複数）の識別、入力デ
ータの識別、必要期限時刻のような制約等を含む、スケジュール設定されるタスクの定義
を供給することができる。図示された実施形態において、リソースマネージャー１８０は
、タスクの実行をスケジュール設定するように動作可能であるスケジュールマネージャー
構成要素４１０も含む。以下にさらに詳細を説明するように、スケジュールマネージャー
５１０は、タスク仕様４０５によって定義されたタスクの推定実行期間４１５を決定する
ことができる。スケジュールマネージャー４１０は次いで、タスクの実行が必要期限時刻
前に完了するように、特定の時刻に実行を開始するようにタスクをスケジュールすること
ができる。いくつかの実施形態において、タスクの実行を開始するためにスケジュール設
定された時刻は、クライアント１４８によってタスク仕様が提出された時刻よりもはるか
に後であってもよい。
【００３７】
一実施形態において、スケジュールマネージャー４１０は、提出されたタスクのために
有用であり得る、所与の一連のインスタンス１３０の、例えば、タスク実行履歴、リソー
ス利用履歴、及び全体的なリソース使用傾向等、リソース使用量データに基づいて、推定
実行期間４１５を決定することができる。リソース使用量データは、リソース管理データ
ベース１９１から呼び出されてもよい。いくつかの事例において、リソースマネージャー
は、所与の一連のリソースインスタンスの過去のリソース使用量データ及び傾向を使用し
て将来のリソース使用の予測を開発し、推定実行期間４１５を決定する際に、これらの予
測を使用することができる。タスク仕様及びこれらの追加のデータ情報源のいくつかまた
は全てからの情報の分析に基づいて、リソースマネージャー１８０は、タスクの少なくと
も一部分を実施するために１つ以上のリソースプール１２１を選択することができる。
【００３８】
提出されたタスクの実行ウィンドウに関係するリソース使用量データの要素が使用され
てもよい。一実施形態において、実行ウィンドウは、クライアント１４８によってタスク
定義４０５の提出によって開始し、必要期限時刻に終了することができる。例えば、実行
ウィンドウが月曜日の午後５時に開始し、午後１１時に終了する場合、プロバイダネット
ワーク１１０内の多様なインスタンスプールのリソース使用傾向は、それまでの月曜日の
同じ時刻に対して分析されてもよい。同様なタスクの実行履歴も、そのような履歴が利用
可能である場合、分析されてもよい。一実施形態において、同様なタスクの実行履歴が利
用可能ではない場合、ユーザーは、推定実行期間４１５を提供するようにプロンプトが表
示されてもよい。一実施形態において、推定実行期間４１５は、提出されたタスクの一部
分を実行してから、次いで、部分的な実行期間から合計推定実行期間４１５を外挿するこ
とによって決定されてもよい。
【００３９】
実行ウィンドウによって提供されるスケジュール設定の柔軟性を使用することによって
、タスクを実行するコストを最小限に抑えることができる。図２ａ及び２ｂを参照して説
明したように、インスタンスタイプの各々は、異なる価格設定ポリシー及び関連コストを
有することができる。したがって、いくつかの実施形態において、スケジュールマネージ
ャー４１０は、タスクの実行ウィンドウ内でタスクの実行を完了するために利用可能であ
る最低コストのインスタンスプールを使用して、タスクを実行するようにスケジュール設
定することができる。リソース使用量データを使用して、スケジュールマネージャー４１
０は、プロバイダネットワーク１１０内の１つ以上のインスタンスプールに対して、提出
されたタスクの推定実行期間４１５を決定することができる。一実施形態において、例え
ば、推定実行期間４１５は、オンデマンドインスタンスプール１２１Ｂにはより短く、ス
ポットインスタンスプール１２１Ｃにはより長いことが決定されてもよい。その上、提出
されたタスクを実施するためにより短い推定実行期間を有するインスタンスプール（例え
ば、オンデマンドインスタンスプール１２１Ｂ）を使用するコストは、より長い推定実行
期間を有するインスタンスプール（例えば、スポットインスタンスプール１２１Ｃ）を使
用するコストよりも高い場合がある。一実施形態において、したがって、タスクは、実行
ウィンドウがタスクを完了するには十分長いが、そうでない場合より高いコスト（かつよ
り高速）のインスタンスプール上ではタスクを完了するには十分長くない場合、最低コス
ト（かつより低速）のインスタンスプール上で実行するようにスケジュール設定されても
よい。
【００４０】
したがって、リソースマネージャー１８０は、上記のコスト抑制分析に基づいて、タス
クの実行を開始するインスタンスプールを選択することができる。一実施形態において、
リソースマネージャー１８０は、タスクの実行を監視することができる。リソースマネー
ジャー１８０が、タスクが選択されたインスタンスプール上で、必要期限時刻までに実行
を完了するに十分迅速に実行していないと決定した場合、リソースマネージャー１８０は
、タスクの実行を完了するより高速（しかし、典型的にはより高いコスト）のリソースプ
ールを選択することができる。リソースマネージャー１８０は次いで、タスクが必要期限
時刻までに完了されるように、タスクの実行を、より高速のリソースプールに切り替える
ことができる。
【００４１】
一実施形態において、タスクは、各々のノードが異なるタスクを表す、複数のノードを
含むグラフ内の１つのノードに対応することができる。グラフ内のタスク全てを実行する
グローバルコストは、本明細書に記載される技法を使用して最小限に抑えることができる
。グラフは、タスクの少なくとも１つの実行が、他のタスクの少なくとも１つの実行に依
存するように、依存グラフを含むことができる。グラフは、特定の時間ウィンドウにわた
って、プロバイダネットワーク１１０上で実行するように提出またはスケジュール設定さ
れているタスクの一部分を表すことができる。タスクの任意の適切なサブセットは、グラ
フ全体を実行するコストの抑制のために、特定のグラフに追加されてもよい。
【００４２】
一実施形態において、推定実行期間４１５は、分析される各計算リソースに対して単一
の期間を含むことができる。一実施形態において、推定実行期間４１５は、１つ以上の種
類の計算リソース及び／またはその構成に対する確率分布または他の値範囲を含むことが
できる。推定実行期間４１５は、異なる時刻に実行するための異なる値も含むことができ
る。推定実行期間４１５内の各可能性は、リソース（単数または複数）がタスクによって
使用される時間にわたって、特定のリソース（単数または複数）に想定される使用量コス
トと関連付けられてもよい。
【００４３】
一実施形態において、スケジュールマネージャー４１０は、１つ以上の緊急時対応策を
生成することができる。例えば、第１の計画に従う実行が失敗した場合（例えば、選択さ
れたコンピューティングリソースが障害を経験した場合）、スケジュールマネージャー４
１０は、緊急時対応策（単数または複数）から別の選択肢を選択し、タスクの実行を、別
の一連のコンピューティングリソースへ移動させることができる。対応策（単数または複
数）は、例えば、異なる種類のコンピューティングリソース及び構成間の差に基づいて、
推定実行期間４１５と関連付けられる、ある範囲の潜在値に基づいてもよい。
【００４４】
一実施形態において、クライアント１４８には、必要期限時刻４０５を含むタスク定義
を提出することに対して、割り引かれた価格が与えられてもよい。割引は、タスクの実行
に対して、正規の価格から、ある割合を引く、及び／または任意の他の減額を含むことが
できる。一実施形態において、割引は、実際のパススルー節約を含むことができる。より
長期間の実行ウィンドウは、より短期間の実行ウィンドウよりも大きいコスト抑制の可能
性を提供することができる。したがって、割引は、実行ウィンドウの大きさによって異な
ってもよく、クライアントは、より早い必要期限時刻に対するよりも、より後の必要期限
時刻に対してより大きい割引が与えられてもよい。
【００４５】
図５は、一実施形態に従う、タスクをスケジュール設定するために、リソース管理シス
テムによって使用される必要期限時刻を含む一連のデータソースの例を示す。タスクを定
義するために、クライアントによって提出されたタスク実行クエリ３０３の一環として、
タスク仕様３０７及び必要期限時刻４０５は、リソースマネージャー１８０へ提供されて
もよい。タスク実行クエリは、図３に示されるように、タスク定義の追加要素を含むこと
ができる。タスク仕様３０７は、例えば、タスクが計算タスクまたはデータ転送タスクで
あるか、どのプログラムまたは実行可能ファイルがタスクに使用されるか、タスクの成功
がどのように決定されるか、性能関係要件（最低ＣＰＵ能力、メモリサイズ、ネットワー
ク帯域幅）等、タスクの多様な詳細を示すことができる。
【００４６】
リソースマネージャー１８０によって使用される価格設定データ３０４は、プロバイダ
ネットワークの多様な場所にある多様な種類のリソース（オンデマンドまたはスポットイ
ンスタンス等）に有効な現在の価格設定、ならびにそのような価格の経時的な過去の変動
を含むことができる。いくつかの実施形態において、リソースマネージャー１８０は、例
えば、過去の価格設定変動に基づいて、将来の価格設定変更を予測する予測モデルを開発
することができる。特に長期的に継続するタスク及びサブタスクの場合、過去の傾向に基
づく将来の価格設定の予測は、クライアントのクエリに対して実行計画を決定する上で有
用であり得る。リクエストしているクライアント１４８または他のクライアントのための
リソース使用量レコード３０５、ならびにサポートされる多様な種類のインスタンスの全
体的なリソース利用量データもまた、提出されたタスクのためのインスタンスタイプ及び
スケジュール設定された時刻を選択する上で有用であり得る。
【００４７】
使用量レコード３０５に基づいて、リソースマネージャー１８０は、いくつかの実施形
態において、クライアントのそれまでに実行されたタスクと現在のタスク仕様３０７との
間の類似性を特定することが可能であってもよく、リソースマネージャー１８０が、より
情報に基づいた選択を行うことを可能にする。例えば、１つのシナリオにおいて、タスク
Ｔ１は、利用可能ゾーンＡＺ１にあるリソースインスタンスＲ１を使用して、所与のクラ
イアントの代理としてより早く実行されていてもよく、Ｔ１を完了するためにかかった時
間の最初の推定は最終的に、１０％間違っていることが見出された。同じクライアントか
ら、タスクＴ２の新しいタスク実行クエリ３０３が受信された場合、Ｔ２のタスク仕様３
０７は、Ｔ１のためにその前に受信されたタスク仕様に非常に類似しているので、リソー
スマネージャー１８０は、Ｔ１によって使用されたリソースの記録を使用して、Ｔ２を完
了するためにかかるかもしれない時間のより優れた推定を行うための位置にあり得る。加
えて、リソースマネージャー１８０はまた、例えば、使用履歴データが、類似のタスクＴ
１が一切の機能的エラーなく、完了に成功したことを示すため、以前に使用された同じ利
用可能ゾーンＡＺ１にある類似のリソースを使用することを決定することもできる。より
一般的なリソース使用量データ（すなわち、リクエストしているクライアントに特定され
ないデータ）もまた、現在のリクエストに使用される特定の場所及びリソースの種類を決
定する際に有用であり得る。例えば、リソースマネージャーは、非常に忙しいゾーンより
利用が少ない利用可能ゾーンに新しいタスクをスケジュール設定してもよい。将来のリソ
ース利用の予測はまた、過去の使用量データに基づいて行われてもよく、いくつかの実装
において、将来の価格設定の予測に結びつけられてもよい。価格設定データ３０４及び／
または使用量レコード３０５は、いくつかの実施形態において、リソース管理データベー
ス１９１等のレポジトリに維持されてもよい。いくつかの実施形態において、リソースマ
ネージャー１８０は、レポジトリから履歴使用量データを取得する代わりに、またはこれ
に加えて、プロバイダネットワーク内に分散された多様な監視エージェントから、最新の
リソース使用量データを取得することができる。
【００４８】
これらの情報源及び制約のいくつかまたは全てに基づいて、スケジュールマネージャー
４１０は、１つ以上のインスタンスタイプまたはインスタンスプールに対して、タスクの
推定実行期間４１５を決定することができる。リソースマネージャー１８０はまた、タス
クを実行するコストを最小限に抑えるために、タスクの実行のための１つ以上の計算イン
スタンス（例えば、インスタンスプール）も選択することができる。スケジュールマネー
ジャー４１０は、選択された計算インスタンス（例えば、選択されたインスタンスプール
）上でタスクの実行を開始するスケジュール設定された時刻４２０を決定することができ
る。図４を参照して上述したように、スケジュール設定された時刻４２０及び選択された
インスタンスプールは、必要期限時刻によって決定された実行ウィンドウ内部でタスクを
実行するコストを最小限に抑えるために、選択されてもよい。リソースマネージャー１８
０は次いで、スケジュール設定された時刻４２０に、選択されたインスタンスプール上で
タスクの実行を監督することができる。
【００４９】
図６は、一実施形態に従う、必要期限時刻を使用して、タスクの実行をスケジュール設
定するための方法を図示するフローチャートである。４５０に示されるように、タスクの
定義を受信することができる。一実施形態において、定義は、タスク実行クエリの一部で
あってもよい。定義は、タスクの実行の時間制約として、必要期限時刻を含むことができ
る。必要期限時刻は、タスクの実行が完了されることが必要である時点（例えば、特定の
日付及び特定の時刻）を含むことができる。必要期限時刻は、タスクの実行の完了に対す
るユーザー指定の期限を含むことができる。
【００５０】
４５５に示されるように、タスクの実行を完了するための推定期間を決定することがで
きる。推定期間は、複数の異なる種類の計算リソース（例えば、複数のインスタンスプー
ル）及び／または計算リソースの異なる構成に対して決定することができる。異なる種類
及び／または構成の計算リソースは、異なる使用量コストを有する可能性があるので、あ
るインスタンスタイプ／構成上のタスクの実行は、別のインスタンスタイプ／構成上の実
行よりもコストが高い場合がある。多様な実施形態において、推定期間は、タスクの１つ
以上の以前の実行、１つ以上の他のタスクの以前の実行、ユーザーが提供した推定等に基
づいていてもよい。一実施形態において、多様な異なる時刻の推定実行期間は、各リソー
ス及び／または構成に対して決定されてもよい。
【００５１】
４６０に示されるように、１つ以上の計算リソース及び／または構成は、予想された使
用量コストに基づいて、タスクの実行のために選択されてもよい。一実施形態において、
最低コストの計算インスタンスプールは、実行ウィンドウ内にタスクの実行を完了するた
めに利用可能である計算インスタンスプールから、すなわち、必要期限時刻前にタスクの
実行の完了を可能にする推定期間を有する計算インスタンスプールから選択されてもよい
。予想されたコストは、実行の時刻に依存し得るため、実行のコストを最小限に抑えるた
めに、リソース（単数または複数）及び／または構成（単数または複数）を選択する際に
、異なる時刻のリソース（単数または複数）及び／または構成（単数または複数）が比較
されてもよい。一実施形態において、タスクは、複数のタスクを表すグラフ内のノードに
対応することができ、グラフ内のタスク全てを実行するグローバルコストを最小限に抑え
ることができる。
【００５２】
４６５に示されるように、タスクの実行を開始するためのスケジュール設定された時刻
を決定することができる。スケジュール設定された時刻は、少なくとも推定期間だけ必要
期限時刻よりも早い。４７０に示されるように、タスクの実行は、選択された計算リソー
ス及び／または構成を使用して、スケジュール設定された時刻に開始することができる。
タスクの実行が開始した後に、必要期限時刻が満たされる可能性が低いと推定された場合
、実行は、別の一連のコンピューティングリソースへ転送されてもよい。
【００５３】
一実施形態において、タスクの実行のために、顧客に対して、価格を評価することがで
きる。顧客の価格は、タスクの実行をスケジュール設定するために、必要期限時刻の使用
に基づく割引を含むことができる。一実施形態において、タスクの実行ウィンドウは、第
１の時点（例えば、タスクの定義が受信された時刻）で開始し、第２の時点（例えば、必
要期限時刻に基づく時刻）に終了し、割引は、実行ウィンドウの大きさに基づいて異なる
。
入力データ特徴に応じたタイムアウト
【００５４】
いくつかの実施形態において、本明細書に記載されるシステム及び方法を使用して、タ
スクのタイムアウト期間は、タスクの入力データの１つ以上の特徴に応じて異なるように
、決定することができる。一実施形態において、タスクのタイムアウト期間は、タスクの
実行が完了前に停止されなければならない期間を示す。すなわち、タスクの実行がタイム
アウト期間を超えると、タスクは、失敗したと見なされる。多様な実施形態において、タ
イムアウト期間を決定するために使用され得る入力データの特徴は、入力データのサイズ
、入力データの一部分のサイズ（例えば、複数のデータ型のうちの１つのデータ型）、入
力データの要素の数、入力データを完全に処理するために必要な反復またはプロセス（例
えば、シミュレーション）の数、タスクのパラメータ、タスクの複雑度またはコストを示
すクライアントが供給した関数または値等を含むが、これらに限定されない。例えば、い
くつかのタスクは、そのサイズまたは複雑度が規則的な変動を経験する入力データセット
を有する場合があり、このようなタスクを完了するためにかかる時間が同様に変動する。
ユーザー指定の時間値またはタスクのタイプに対する固定時間値（例えば、２時間）にタ
イムアウト期間を基礎とする代わりに、タイムアウト期間は、タスクによって使用される
入力データの１つ以上の特徴に応じて自動的に決定されてもよく、可能性として、タスク
自体の実行に指定された特徴を含む。一実施形態において、クライアントは、リソースマ
ネージャー１８０に（例えば、タスク実行クエリ３０３の一部として）、絶対時間値とし
てではなく、入力特徴（単数または複数）に応じてタイムアウト期間を設定するように命
令することができる。一実施形態において、タイムアウト期間は、クライアントに視認さ
れず、クライアントからの直接入力に基づかない様式で決定されてもよい。
【００５５】
図７は、一実施形態に従う、入力データ特徴に基づくタイムアウトを含むリソース管理
システムのための例示的システム環境を示す。図１を参照して上記に検討したように、リ
ソース管理システム１００は、領域１１２Ａ等の複数の地理的領域を含むプロバイダネッ
トワーク１１０を含む。追加の地理的領域は図７には図示されない。各地理的領域１１２
は、領域１１２Ａ内の利用可能ゾーン１２０Ａ及び１２０Ｂ等、１つ以上の利用可能ゾー
ン１２０を含むことができる。各利用可能ゾーン１２０は、これによって、利用可能ゾー
ン１２０Ａ内のリソースインスタンス１３０Ａ、１３０Ｂ、１３０Ｄ、１３０Ｅ、１３０
Ｇ、及び１３０Ｈ等の複数のリソースを含むことができる。インスタンスは、いくつかの
実施形態において、予約インスタンスプール１２１Ａ、オンデマンドインスタンスプール
１２１Ｂ、及びスポットインスタンスプール１２１Ｃ等、多様なリソースプールに体系化
することができる。異なる利用可能ゾーン１２０内の多様なリソースインスタンス１３０
は、クライアント１４８による使用のために予約及び／または割り当てることができる。
各インスタンスプール１２１は、関連リソース管理及び価格設定ポリシーを有し、例えば
、リソースインスタンスの予約または割り当てを中断することができるか、１つのクライ
アントの予約を別のクライアントに再販売できるか、プールのインスタンスに対して有効
な異なる種類の静的及び動的価格決定率等を規定する。
【００５６】
図示された実施形態において、リソース管理システム１００は、クライアント１４８に
よって提出されたリクエストに応答して、多様な操作を実行するように動作可能なリソー
スマネージャー１８０を含む。リソースマネージャー１８０のインターフェースマネージ
ャー構成要素１８３は、いくつかの実施形態において、クライアント１４８が、入力デー
タセット５０５を含むタスク仕様を提出することを可能にする、１つ以上のプログラムイ
ンターフェースを実装することができる。入力データセットは、入力データの特定のサイ
ズ等の特徴を有することができる。入力データセットは、例えば、実行するシミュレーシ
ョンの数等、タスクの実行に関係するパラメータも含むことができる。入力データセット
のサイズは、絶対的条件（例えば、１０ＭＢ）、処理されるデータ要素またはレコードの
数等、任意の適切な様式で測定されてもよい。入力データ５０５を含むタスク仕様は、実
施される関数（単数または複数）または実行されるプログラム（単数または複数）の識別
、入力データ及びその多様な特徴の識別、タスクパラメータ、時間制約等を含む、スケジ
ュール設定されるタスクの定義を供給することができる。図示される実施形態において、
リソースマネージャー１８０は、入力データ特徴に応じて、タスクのタイムアウト期間５
１５を決定するように動作可能であるタイムアウトマネージャー構成要素５１０も含むこ
とができる。プロバイダネットワーク上でタスクが実行を開始すると、リソースマネージ
ャー１８０等の構成要素は、タイムアウト期間を超えないことを確実にするために、タス
クの実行を監視することができる。
【００５７】
多様な実施形態において、タイムアウト期間５１５は、多様な方式で決定されてもよい
。一実施形態において、タイムアウトマネージャー５１０は、提出されたタスクのために
有用であり得る、所与の一連のインスタンス１３０の、例えば、タスク実行履歴、リソー
ス利用履歴、及び全体的なリソース使用傾向等、リソース使用量データに基づいて、タス
クのタイムアウト期間５１５を決定することができる。例えば、タイムアウトマネージャ
ー５１０は、異なる入力データサイズにわたってタスクの繰り返し実行を監視することが
できる。タイムアウトマネージャーは次いで、入力データサイズとタスクの実行期間との
間の適切な関係を推論することができる。特定のタスクの異なる実行に対して、入力デー
タ特徴（単数または複数）に応じて期待実行期間を決定するために、任意の適切な技法（
例えば、曲線近似）が使用されてもよい。一実施形態において、入力データ特徴（単数ま
たは複数）と実行期間との間の関係は、線形であると決定されてもよい。一実施形態にお
いて、関係をキャプチャし、将来の推定を提供するために、機械学習技法が使用されても
よい。タスクの以前の実行期間と入力データ特徴（単数または複数）との間の関係は、リ
ソース管理データベース１９１内にリソース使用量データとともに記憶されてもよい。特
定の入力データセット５０５を含む新しいタスク仕様が受信されると、タイムアウトマネ
ージャー５１０は、次いで、リソース管理データベース１９１から呼び出されたリソース
使用量データに基づいて、入力データセットの特徴（単数または複数）に応じて、適切な
タイムアウト期間５１５を決定することができる。
【００５８】
一実施形態において、タイムアウトマネージャー５１０は、入力データのサブセットの
タスクを実行することによって、タスクのタイムアウト期間５１５を決定することができ
る。例えば、入力データの５％に対してタスクを実行する時間は、特定の入力データセッ
ト５０５を含む新しいタスク仕様が受信された後に、入力データのそれらの要素に対して
タスクを実際に実行することによって決定されてもよい。入力データのサブセットの実行
時間を試験するために、同じタイプの計算インスタンス及び完全な入力データセットに使
用される他のリソースが使用されてもよい。入力データセットは実質的に均一であるとい
う想定の下で、タスクの期待実行時間は次いで、入力データの５％の実際の実行時間に２
０を乗算することによって、決定されてもよい。一実施形態において、入力データのサブ
セットの実行時間は、リソース管理データベース１９１内にリソース使用履歴とともに記
憶されてもよい。
【００５９】
一実施形態において、クライアントは、入力データセット内の要素またはレコードあた
りの部分的実行時間を指定することができる。部分的実行時間は、規則的ベースで実行さ
れる特定のタスクとともにデフォルトとして記憶されてもよい。特定の入力データセット
５０５を含む新しいタスク仕様が受信されると、タイムアウトマネージャー５１０は、要
素あたりの実行時間に入力データセットのサイズを乗算することによって、タスクの推定
実行期間を決定することができる。
【００６０】
タスクの期待実行時間が決定されると、タイムアウト期間がそれに応じて設定されても
よい。一実施形態において、タイムアウト期間は、入力データセット全体に対して、タス
クの期待実行時間の割合（１００％を超える）として、例えば、期待実行時間の１２０％
と設定されてもよい。一実施形態において、タイムアウト期間は、期待実行時間を上回る
１つまたは２つの標準偏差として設定されてもよい。一実施形態において、タイムアウト
期間は、期待実行時間（例えば、２時間）及び追加の固定期間（例えば、３０分）の和と
して設定されてもよい。タイムアウト期間は、下限及び／または上限内、すなわち、最低
及び最高値以内で決定されてもよい。一実施形態において、タイムアウト期間の下限及び
上限値は、ユーザーによって指定または承認されてもよい。一実施形態において、タイム
アウト期間は、期待される高いリソース使用の期間中に延長されてもよい。
【００６１】
いくつかの実施形態において、タイムアウト期間は、タスクの実行のために使用される
計算インスタンスのタイプに基づいて異なってもよい。タスクの期待実行時間がタスクの
ために使用されるインスタンスプールに基づいて異なる場合、タスクのタイムアウト期間
は、それに応じて決定されてもよい。一実施形態において、インスタンスプールのそのよ
うな変動は、リソース使用履歴の一部として、決定する際に含まれてもよい。
【００６２】
一実施形態において、タイムアウト期間は、タスクの１つ以上のサブタスクに対するデ
ータ入力特徴に応じて決定されてもよい。タイムアウト期間は、タスクに対して本明細書
で記載される同じ技法を使用して、サブタスクに対して決定されてもよい。一実施形態に
おいて、タイムアウト期間は、入力データセット内の複数のデータ型のうちの１つのデー
タ型の特徴に基づいて決定されてもよい。例えば、あるデータ型が最大であり、タスクの
実行時間を支配する傾向がある場合、期待実行時間を決定する際、入力データ内のそのデ
ータ型のみのサイズが使用されてもよい。一実施形態において、期待実行時間に対する入
力データセット内の異なるデータ型の関連性及び影響の統計的モデルを作成するために、
任意の適切な機械学習技法が使用されてもよい。
【００６３】
図８は、一実施形態に従う、タスクのタイムアウト期間を決定するために、リソース管
理システムによって使用される、特定の特徴を有するデータソースセットを含む、一連の
データソースの例を示す。タスクを定義するためにクライアントによって提出されたタス
ク実行クエリ３０３の一環として、タスク仕様３０７及び入力データセット５０５は、リ
ソースマネージャー１８０へ提供されてもよい。タスク実行クエリは、図３に示されるよ
うに、タスク定義の追加要素を含むことができる。タスク仕様３０７は、例えば、タスク
が計算タスクまたはデータ転送タスクであるか、どのプログラムまたは実行可能ファイル
がタスクに使用されるか、タスクの成功がどのように決定されるか、性能関係要件（最低
ＣＰＵ能力、メモリサイズ、ネットワーク帯域幅）等、タスクの多様な詳細を示すことが
できる。
【００６４】
使用量レコード３０５に基づいて、リソースマネージャー１８０は、いくつかの実施形
態において、クライアントのそれまでに実行されたタスクと現在のタスク仕様３０７との
間の類似性を特定することが可能であってもよく、リソースマネージャー１８０が、より
情報に基づいた選択を行うことを可能にする。例えば、１つのシナリオにおいて、タスク
Ｔ１は、利用可能ゾーンＡＺ１にあるリソースインスタンスＲ１を使用して、所与のクラ
イアントの代理としてより早く実行されていてもよく、Ｔ１を完了するためにかかった時
間の最初の推定は最終的に、１０％間違っていることが見出された。同じクライアントか
ら、タスクＴ２の新しいタスク実行クエリ３０３が受信された場合、Ｔ２のタスク仕様３
０７は、Ｔ１のためにその前に受信されたタスク仕様に非常に類似しているので、リソー
スマネージャー１８０は、Ｔ１によって使用されたリソースの記録を使用して、Ｔ２を完
了するためにかかるかもしれない時間のより優れた推定を行うための位置にあり得る。加
えて、リソースマネージャー１８０はまた、例えば、使用履歴データが、類似のタスクＴ
１が一切の機能的エラーなく、完了に成功したことを示すため、以前に使用された同じ利
用可能ゾーンＡＺ１にある類似のリソースを使用することを決定することもできる。より
一般的なリソース使用量データ（すなわち、リクエストしているクライアントに特定され
ないデータ）もまた、現在のリクエストに使用される特定の場所及びリソースの種類を決
定する際に有用であり得る。例えば、リソースマネージャーは、非常に忙しいゾーンより
利用が少ない利用可能ゾーンに新しいタスクをスケジュール設定してもよい。使用量レコ
ード３０５は、いくつかの実施形態において、リソース管理データベース１９１等のレポ
ジトリに維持されてもよい。いくつかの実施形態において、リソースマネージャー１８０
は、レポジトリから履歴使用量データを取得する代わりに、またはこれに加えて、プロバ
イダネットワーク内に分散された多様な監視エージェントから、最新のリソース使用量デ
ータを取得することができる。
【００６５】
これらの情報源及び制約のいくつかまたは全てに基づいて、タイムアウトマネージャー
５１０は、１つ以上のインスタンスタイプまたはインスタンスプール上の実行に対する入
力データ特徴に応じて、タスクのタイムアウト期間５１５を決定することができる。リソ
ースマネージャー１８０はまた、タスクの実行のための１つ以上の計算インスタンス（例
えば、インスタンスプール）も選択することができる。リソースマネージャー１８０は次
いで、選択されたインスタンスプール上でタスクの実行を監視することができる。
【００６６】
一実施形態において、タイムアウト期間は、タスクの実行を開始した後、監視及び／ま
たは修正されてもよい。リソースマネージャー１８０（またはリソース管理システム１０
０の別の適切な構成要素）は、期待実行時間と比較して、タスクの進捗状況を監視するこ
とができる。タスクの進捗状況が期待よりもはるかに遅い場合、タイムアウト期間は、入
力データセットのサブセットに対する推定実行時間と観察された実行時間との間の差に基
づいて、修正（すなわち、延長）されてもよい。例えば、入力データの２０％が実際に処
理されている場合、入力データセット全体の期待実行期間は、入力データの処理された２
０％の実際の実行時間に５を乗算することによって決定されてもよい。タイムアウトマネ
ージャー５１０は、上記のように、修正された推定実行期間に基づいて、修正タイムアウ
ト期間を決定することができる。
【００６７】
図９は、一実施形態に従う、入力データサイズに基づいてタスクタイムアウトを実施す
るための方法を示すフローチャートである。５５０に示されるように、タスクの定義を受
信することができ、タスクの定義は、タスクのための入力データセットを示す。タスクの
定義及び入力データセットは、入力データのサイズ、入力データの一部分のサイズ（例え
ば、複数のデータ型のうちの１つのデータ型）、入力データの要素の数、入力データを完
全に処理するために必要な反復またはプロセス（例えば、シミュレーション）の数、タス
クのパラメータ、タスクの複雑度またはコストを示すクライアントによって供給された関
数または値等、タスク及び／または入力データの多様な特徴を含むことができる。
【００６８】
５５５に示されるように、タスクのタイムアウト期間は、タイムアウト期間が１つ以上
の特徴に伴い変動するように、入力データセットの１つ以上の特徴に基づいて決定するこ
とができる。タスクのタイムアウト期間は、タスクがその実行を完了する前にタスクの実
行が停止されなければならない期間を示す。タイムアウト期間は、多様な異なる方式で決
定されてもよい。一実施形態において、タイムアウト期間は、入力データのサイズ等、特
定の特徴が変動する追加の入力データセットを使用する同じタスクの実行に基づいて決定
される。一実施形態において、タスクのタイムアウト期間は、入力データセットを使用す
るタスクの実行の推定期間に応じて決定される。一実施形態において、タスクのタイムア
ウト期間は、入力データセットのサブセットを使用するタスクの実行に基づいて、あるい
はその他、実行時間期間または出力サイズを推定するために入力データをサンプリングす
ることによって、決定される。一実施形態において、タイムアウト期間は、複数の要素の
重み付け組み合わせとして決定され、複数の要素のうちの１つ以上が、入力データの特徴
に基づく。一実施形態において、タイムアウト期間は、入力データセット内またはタスク
の定義内に含まれる、実行時間コスト関数または実行時間複雑度関数に基づいて決定され
る。一実施形態において、タイムアウト期間は、推定実行時間期間に加えて、入力データ
のクリーニングまたは標準化等、１つ以上の前処理ステップの推定期間の組み合わせに基
づいて決定され、前処理ステップの期間は入力データをサンプリングすることによって推
定される。
【００６９】
５６０に示されるように、タスクの実行を開始することができる。タスクの実行は、タ
イムアウト期間を超えないことを保証するために、監視されてもよい。一実施形態におい
て、タスクを実行するためにかかる時間は周期的に確認されてもよい。５６５に示される
ように、タスクの実行がタイムアウト期間を超えたかどうかを決定してもよい。５７０に
示されるように、タイムアウト期間を超えた場合、タスクの実行は中断またはその他、完
了前に停止されてもよい。一実施形態において、タスクの実行は、ユーザーの承認がある
場合に限り停止することができる。ユーザーの承認は、タイムアウト期間を超えた後（例
えば、ユーザーにタスクをキャンセルするようにプロンプトを表示することによって）、
またはタイムアウト期間を決定する時点で、受信されてもよい。５７５に示されるように
、タイムアウト期間を超えていない場合、タスクの実行を完了することができる。一実施
形態において、５６５に示される監視操作は、タスクが完全に実行される、またはタイム
アウトするかのいずれかまで、繰り返して実施されてもよい。
【００７０】
一実施形態において、閾値データ処理速度は、タイムアウト期間の代わりに、またはタ
イムアウト期間に加えて決定されてもよい。閾値データ処理速度は、より遅い速度のデー
タ処理が、入力データセット全体でタイムアウト期間を超えるように決定されてもよい。
例えば、閾値データ処理速度は、タイムアウト期間を、入力データセット内のデータ要素
またはレコード数で除算することによって決定されてもよい。タスクの進捗状況が監視さ
れてもよく、タスクは、観察されたデータ処理速度が、閾値データ処理速度よりも小さい
場合、永久的に停止されてもよい。一実施形態において、タスクは、入力データセットの
最低量、例えば、１０％が処理された後、低いデータ処理速度に起因してのみ、停止され
てもよい。
【００７１】
一実施形態において、タイムアウト期間は、入力データとともにクライアントによって
指定されたタイムアウト関数に基づいてもよい。タイムアウト関数は、実行時間期間、実
行時コスト、及び／または実行時複雑度を推定するために使用されてもよい。一実施形態
において、１つのクライアントによって供給されたタイムアウト関数は、本来のクライア
ントの匿名性を保護する様式で、他のクライアントによって提出されたタスクのために使
用されてもよい。クライアントによって供給されたタイムアウト関数の予測値が測定され
てもよく、最も正確に実行時間期間、実行時コスト、及び／または実行時複雑度を予測す
るタイムアウト関数は、再び、同じクライアントのために、または他のクライアントのた
めに使用されてもよい。適切なタイムアウト期間は、タスクタイプ及び／または入力デー
タの特徴の一致に基づいて、新しいタスクのために選択されてもよい。
【００７２】
タイムアウト期間は、タスクの実行が必要期限時刻または他のクライアントが指定した
目標を満たすように決定されてもよい。例えば、クライアントは、必要期限時刻、すなわ
ち、タスクの実行が完了されるべき時刻を指定することができる。クライアントは、不要
期限時刻、すなわち、実行の結果が必要ではなくなる時刻（例えば、結果は有用であるに
は遅すぎる）を指定することができる。加えて、クライアントは、コスト限界、タイミン
グ限界等、実行条件を指定することができる。これらの要素は、タスクの入力データとと
もに指定されてもよく、タイムアウト期間は、これに応じて決定されてもよい。
タスク実行の最適化
【００７３】
いくつかの実施形態において、本明細書に記載されるシステム及び方法を使用して、タ
スクの実行のためのパラメータ値及び／またはコンピューティングリソース（例えば、リ
ソースの構成パラメータ）は、タスクの実行のためのコスト及び／または完了時間を最適
化するように自動的に選択することができる。類似のタスクの異なる反復が実施されると
、タスクの性能特徴が監視され、タスク履歴データとして記憶されてもよい。新しいタス
クがクライアントによって提出されると、タスク履歴データは、新しいタスクの実行のた
めの最適な構成を自動的に選択するために使用されてもよい。最適な構成は、クラスタサ
イズ、クラスタ構成、インスタンスタイプ、Ｈａｄｏｏｐ構成設定（例えば、マッパー／
リデユーサ比）、及び任意の他の適切なパラメータに関係するパラメータ値を含むことが
できる。一実施形態において、パラメータ値は、タスクを実行するコストを最適化する（
すなわち、最小限に抑える）ように選択されてもよい。一実施形態において、パラメータ
値は、タスクの完了時間（すなわち、実行期間）を最適化する（すなわち、最小限に抑え
る）ように選択されてもよい。一実施形態において、コスト及び完了時間の両方が最適化
されてもよい。
【００７４】
図１０は、一実施形態に従う、動的クラスタ最適化を含むリソース管理システムのため
の例示的システム環境を示す。図１を参照して上記に検討したように、リソース管理シス
テム１００は、領域１１２Ａ等の複数の地理的領域を含むプロバイダネットワーク１１０
を含む。追加の地理的領域は図１０には図示されない。各地理的領域１１２は、領域１１
２Ａ内の利用可能ゾーン１２０Ａ及び１２０Ｂ等、１つ以上の利用可能ゾーン１２０を含
むことができる。各利用可能ゾーン１２０は、これによって、利用可能ゾーン１２０Ａ内
のリソースインスタンス１３０Ａ、１３０Ｂ、１３０Ｄ、１３０Ｅ、１３０Ｇ、及び１３
０Ｈ等の複数のリソースを含むことができる。インスタンスは、いくつかの実施形態にお
いて、予約インスタンスプール１２１Ａ、オンデマンドインスタンスプール１２１Ｂ、及
びスポットインスタンスプール１２１Ｃ等、多様なリソースプールに体系化することがで
きる。異なる利用可能ゾーン１２０内の多様なリソースインスタンス１３０は、クライア
ント１４８による使用のために予約及び／または割り当てることができる。各インスタン
スプール１２１は、関連リソース管理及び価格設定ポリシーを有し、例えば、リソースイ
ンスタンスの予約または割り当てを中断することができるか、１つのクライアントの予約
を別のクライアントに再販売できるか、プールのインスタンスに対して有効な異なる種類
の静的及び動的価格決定率等を規定する。
【００７５】
図示された実施形態において、リソース管理システム１００は、クライアント１４８に
よって提出されたリクエストに応答して、多様な操作を実行するように動作可能なリソー
スマネージャー１８０を含む。リソースマネージャー１８０のインターフェースマネージ
ャー構成要素１８３は、いくつかの実施形態において、クライアント１４８が、最適化プ
ロセスのために１つ以上の制約６０５を含むタスク仕様（例えば、タスク実行クエリ３０
３の一部として）を提出することを可能にする、１つ以上のプログラムインターフェース
を実装することができる。タスク仕様は、実施される関数（単数または複数）または実行
されるプログラム（単数または複数）の識別を含む、スケジュール設定されるタスクの識
別に加えて、最適化プロセスに適用される１つ以上の制約（例えば、コスト及び／または
完了時刻）の指示を供給することができる。図示される実施形態において、リソースマネ
ージャー１８０は、制約（単数または複数）６０５に基づいて、提出されたタスクの一連
の１つ以上の最適パラメータ６１５を決定するように動作可能である最適化マネージャー
構成要素６１０も含む。最適化マネージャー６１０は、最適パラメータを用いて、プロバ
イダネットワーク１１０内の適切なリソース（例えば、１つ以上のインスタンス１３０）
を構成することができ、タスクは次いで、最適環境においてこれらのリソースを使用して
実行することができる。タスクがプロバイダネットワーク上で実行を開始すると、リソー
スマネージャー１８０等の構成要素は、タスクの実行を監視することもできる。
【００７６】
図１１は、一実施形態に従う、タスクの実行を最適化するためにリソース管理システム
によって使用される一連のデータソースの例を示す。タスクを定義するために、クライア
ントによって提出されたタスク実行クエリ３０３の一部として、タスク仕様３０７がリソ
ースマネージャー１８０へ提供されてもよい。タスク実行クエリは、図３に示されるよう
に、タスク定義の追加要素を含むことができる。タスク仕様３０７は、例えば、タスクが
計算タスクまたはデータ転送タスクであるか、どのプログラムまたは実行可能ファイルが
タスクに使用されるか、タスクの成功がどのように決定されるか、性能関係要件（最低Ｃ
ＰＵ能力、メモリサイズ、ネットワーク帯域幅）等、タスクの多様な詳細を示すことがで
きる。
【００７７】
リソースマネージャー１８０によって使用される価格設定データ３０４は、プロバイダ
ネットワークの多様な場所にある多様な種類のリソース（オンデマンドまたはスポットイ
ンスタンス等）に有効な現在の価格設定、ならびにそのような価格の経時的な過去の変動
を含むことができる。いくつかの実施形態において、リソースマネージャー１８０は、例
えば、過去の価格設定変動に基づいて、将来の価格設定変更を予測する予測モデルを開発
することができる。特に長期的に継続するタスク及びサブタスクの場合、過去の傾向に基
づく将来の価格設定の予測は、クライアントのクエリに対して実行計画を決定する上で有
用であり得る。リクエストしているクライアント１４８または他のクライアントのための
リソース使用量レコード３０５、ならびにサポートされる多様な種類のインスタンスの全
体的なリソース利用量データもまた、提出されたタスクのためのインスタンスタイプ及び
スケジュール設定された時刻を選択する上で有用であり得る。
【００７８】
使用量レコード３０５に基づいて、リソースマネージャー１８０は、いくつかの実施形
態において、クライアントのそれまでに実行されたタスクと現在のタスク仕様３０７との
間の類似性を特定することが可能であってもよく、リソースマネージャー１８０が、より
情報に基づいた選択を行うことを可能にする。例えば、１つのシナリオにおいて、タスク
Ｔ１は、利用可能ゾーンＡＺ１にあるリソースインスタンスＲ１を使用して、所与のクラ
イアントの代理としてより早く実行されていてもよく、Ｔ１を完了するためにかかった時
間の最初の推定は最終的に、１０％間違っていることが見出された。同じクライアントか
ら、タスクＴ２の新しいタスク実行クエリ３０３が受信された場合、Ｔ２のタスク仕様３
０７は、Ｔ１のためにその前に受信されたタスク仕様に非常に類似しているので、リソー
スマネージャー１８０は、Ｔ１によって使用されたリソースの記録を使用して、Ｔ２を完
了するためにかかるかもしれない時間のより優れた推定を行うための位置にあり得る。加
えて、リソースマネージャー１８０はまた、例えば、使用履歴データが、類似のタスクＴ
１が一切の機能的エラーなく、完了に成功したことを示すため、以前に使用された同じ利
用可能ゾーンＡＺ１にある類似のリソースを使用することを決定することもできる。より
一般的なリソース使用量データ（すなわち、リクエストしているクライアントに特定され
ないデータ）もまた、現在のリクエストに使用される特定の場所及びリソースの種類を決
定する際に有用であり得る。例えば、リソースマネージャーは、非常に忙しいゾーンより
利用が少ない利用可能ゾーンに新しいタスクをスケジュール設定してもよい。将来のリソ
ース利用の予測はまた、過去の使用量データに基づいて行われてもよく、いくつかの実装
において、将来の価格設定の予測に結びつけられてもよい。価格設定データ３０４及び／
または使用量レコード３０５は、いくつかの実施形態において、リソース管理データベー
ス１９１等のレポジトリに維持されてもよい。いくつかの実施形態において、リソースマ
ネージャー１８０は、レポジトリから履歴使用量データを取得する代わりに、またはこれ
に加えて、プロバイダネットワーク内に分散された多様な監視エージェントから、最新の
リソース使用量データを取得することができる。
【００７９】
使用量レコード３０５は、プロバイダネットワーク１１０上で以前に実行されたことが
あるタスクのために収集されたタスク履歴データを含むことができる。多様な実施形態に
おいて、使用量レコード３０５は、タスクまたはサブタスクのための、プロセッサ利用量
データ、メモリ利用量データ、ディスク利用量データ等を含むことができる。タスク履歴
データは、新しいタスクが最適化されることが求められる同じクライアントのために以前
に実行されたタスクについて収集されてもよい。一実施形態において、タスク履歴データ
はまた、プロバイダネットワーク上の複数のクライアントの代理として以前に実行された
タスクから収集されてもよい。例えば、標準タスクのタスク履歴が収集され、異なるクラ
イアントによって提出された同じタスクまたは類似タスクに適用されてもよい。この様式
において、タスク履歴の範囲は、最適パラメータのさらに優れた調整を提供するために増
大されてもよい。一実施形態において、タスク履歴の要素は、あるクライアントから別の
クライアントへ提供される際に匿名化されてもよい。使用量レコード３０５の要素は、多
様な方式で収集されてもよい。タスクに関与する１つ以上のプロセスは、関連使用量デー
タを収集するために搭載されてもよい。一実施形態において、仮想マシンの実行のための
使用量データは、外部モジュール（すなわち、仮想マシンの外部にあるモジュール）によ
って監視かつ収集されてもよい。一実施形態において、エージェントは、仮想マシン内部
で実行され、内部で使用量データを収集してもよい。
【００８０】
最適化マネージャー６１０によって実施された最適化プロセスに適用される制約６０５
は、例えば、クライアントによって決定されるように、異なる。一実施形態において、ユ
ーザーは、最適化プロセスに関する制約として、コストまたは完了時刻のいずれかを選択
することができる。いくつかの実施形態において、ユーザーは、制約として、コスト及び
完了時間の両方を選択することができる。両方の制約が使用される場合、コスト制約及び
完了時刻制約の相対的順序は、任意の適切なユーザーインターフェース技法または要素を
使用して決定されてもよい。例えば、コスト制約または完了時刻制約のいずれかが、一次
制約として選択されてもよく、残りの制約が二次制約であってもよい。一実施形態におい
て、グラフィカルユーザーインターフェース（ＧＵＩ）のスライダバーは、コスト制約及
び完了時刻制約の相対的貢献度を決定するために、ユーザー入力を受信することができ、
スライダバーの一方の端は１００％のコスト制約（及び０％の完了時刻制約）を示し、ス
ライダバーの他方の端は１００％の完了時刻制約（及び０％のコスト制約）を示す。追加
の制約もまた、最適化プロセスに適用されてもよい。例えば、タスクの成功または失敗の
確率制約が適用されてもよい。別の例として、場所制約が適用されてもよい。
【００８１】
これらの情報源及び制約のいくつかまたは全てに基づいて、最適化マネージャー６１０
は、プロバイダネットワーク１１０の適切なリソースを使用してタスクを実行するために
、一連の１つ以上の最適パラメータ６１５を決定することができる。最適化マネージャー
６１０は、制約された最適化問題に対する解決策を生成するために、任意の他の関連デー
タ（例えば、使用量レコード３０５及び価格設定データ３０４）とともに、選択された制
約（単数または複数）６０５を使用することができる。制約された最適化問題を解決する
ための任意の適切な技法を使用することができる。いくつかの実施形態において、最適パ
ラメータ６１５は、プロバイダネットワーク１１０内のソフトウェアまたはハードウェア
の任意の選択可能なリソース及び／または任意の構成可能な要素に関係することができる
。例えば、最適パラメータ６１５は、クラスタサイズ６３１、クラスタ構成６３２、イン
スタンスタイプ６３３、Ｈａｄｏｏｐ構成設定（例えば、マッパー／リデユーサ比）６３
４、及び任意の他の適切なパラメータを含むことができるが、これらに限定されない。一
実施形態において、タスクの個別のサブタスクのための最適パラメータは、類似の様式に
おいて生成することができる。
【００８２】
Ｈａｄｏｏｐ設定は、Ｈａｄｏｏｐソフトウェアフレームワークに基づいてデータ集約
的分散アプリケーションをサポートするコンピューティング環境に関係することができる
。Ｈａｄｏｏｐ環境は、アプリケーションに信頼性及びデータ移動の両方を提供しながら
、汎用ハードウェアの大型クラスタ上でアプリケーションの実行をサポートすることがで
きる。Ｈａｄｏｏｐ環境は、マッパー／リデューサと参照される演算パラダイムを実装す
ることができ、アプリケーションは、クラスタ内の任意のノードで実行または再実行され
てもよい、多数の小さいフラグメントに分割される。したがって、マッパーのリデューサ
に対する比は、Ｈａｄｏｏｐ環境において、タスクの実行のために最適化することができ
る。Ｈａｄｏｏｐ環境はまた、計算ノード上にデータを記憶し、クラスタ全体に非常に高
い集約帯域幅を提供する、分散ファイルシステムも提供することができる。
【００８３】
一実施形態において、タスクは、各々のノードが異なるタスクを表す、複数のノードを
含むグラフ内の１つのノードに対応することができる。グラフ内の複数のタスクの実行は
、本明細書に記載される技法を使用して最適化されてもよい。グラフは、タスクの少なく
とも１つの実行が、他のタスクの少なくとも１つの実行に依存するように、依存グラフを
含むことができる。
【００８４】
一実施形態において、最適化マネージャー６１０は、最適化問題に対する適切に最適化
された解決策に基づく適切な履歴データを構築するために、学習段階を使用することがで
きる。学習段階中、最適化マネージャー６１０は、リソースマネージャー１８０に、プロ
バイダネットワーク１１０上で多数のタスクを実行するように指示することができ、タス
クは、異なる構成を有する。学習段階中、タスクは、異なるインスタンスプールの性能特
徴（例えば、完了時刻及び／またはコストの点で）を特徴付けるために、異なるインスタ
ンスタイプの計算インスタンス上で実行されてもよい。この様式において、最適化マネー
ジャー６１０は、異なるパラメータ値が異なるインスタンスタイプの性能特徴に影響を与
える様式のモデルを構築することができる。一実施形態において、最適化マネージャー６
１０は、性能モデルを構築するために、任意の適切な機械学習技法を使用することができ
る。学習段階の結果は、リソース管理データベース１９１に記憶されてもよい。結果（例
えば、性能モデル）はその後、新しく提出されたタスクの実行を最適化するために、最適
化マネージャー６１０によって呼び出されてもよい。
【００８５】
図１２は、一実施形態に従う、動的クラスタ最適化のための方法を示すフローチャート
である。６５０に示されるように、タスクの定義を受信することができる。６５５に示さ
れるように、例えば、クライアントから、１つ以上の実行制約も受信されてもよい。実行
制約は、タスクを実行するコスト、タスクの実行のための完了時間、タスクの成功または
失敗の可能性、あるいは任意のこのような制約の組み合わせを含むことができる。場所制
約（例えば、プロバイダネットワーク１１０内の１つ以上の特定の領域または利用可能ゾ
ーン）等の追加の制約も受信することができる。２つ以上の制約が指定される場合、制約
は、相対的順序で特定することができ、１つの制約が一次制約であり、もう１つの制約が
二次制約等となる。
【００８６】
６６０に示されるように、タスクを実行するための１つ以上のパラメータ値及び／また
は１つ以上のコンピューティングリソースを自動的に選択することができる。パラメータ
値及び／またはコンピューティングリソースは、タスクの実行のための１つ以上の実行制
約を最適化するように自動的に選択することができる。この様式において、プロバイダネ
ットワーク１１０のハードウェア及び／またはソフトウェア要素の特定の構成は、選択さ
れた制約（単数または複数）を最適化する様式において、タスクの実行のために選択する
ことができる。６６０に示される操作は、タスクを適切な構成に一致させるために、履歴
使用量データ、価格設定データ等に基づいて、制約された最適化問題に対する解決策を生
成することができる。６６５に示されるように、タスクの実行は、選択されたパラメータ
値を用いて構成された１つ以上のコンピューティングリソースを使用して開始されてもよ
い。
【００８７】
一実施形態において、最適化プロセスは、複数の追加タスクの実行から取得されたデー
タを採用することができ、パラメータ値は、複数の追加タスクのそれぞれで異なる。追加
タスクは、学習段階中に最適化マネージャー６１０によって生成されたタスク及び／また
は他のユーザーによって以前に提出されたタスクであってもよい。複数の追加タスク間の
性能の違いを監視することができる。６６０に示される操作において、複数のパラメータ
値は、複数の追加タスク間の性能の差に基づいて、タスクの実行のために自動的に選択さ
れてもよい。
構成ワークフローサービス
【００８８】
多様な実施形態において、データパイプラインは、ユーザーがデータ主導のワークフロ
ーをスケジュール設定し、管理することを可能にする１つ以上のサービスを提供すること
ができる。いくつかの実施形態において、データパイプラインは、クライアントに、複数
のリモートクライアントに利用可能である構成可能ワークフローサービスの制御下等、定
義された様式においてソースデータを操作する定義されたワークフローを作成、構成、及
び実行するための機能へのアクセスを提供することができる。少なくともいくつかの実施
形態において、リモートクライアントは、クライアントによって使用されるために、構成
可能ワークフローサービスによって提供される定義ワークフローを作成かつ構成するため
に、１つ以上の公開ネットワーク上から、構成可能ワークフローサービスと相互作用する
ことができる。このような定義されたワークフローは、例えば、特定のタイプの入力デー
タ上で、１つ以上の指定されたタイプのデータ操作演算を実施するように各々構成される
、複数の相互接続されたワークフロー構成要素を含むことができる。クライアントがこの
ような定義されたワークフローを構成した後、構成可能ワークフローサービスは、１回以
上かつ多様な様式で、いくつかの状況においては、定義されたワークフローのワークフロ
ー構成要素の少なくとも１つを各々実装するために構成可能ワークフローサービスによっ
て提供された複数のコンピューティングノードをプロビジョニングすることによって、及
び定義されたタイプのソースデータを呼び出し、それを定義された様式でワークフロー構
成要素にプロビジョニングすることによって等、定義されたワークフローをさらに実行す
ることができる。このように、少なくともいくつかの実施形態において、記載の技法のい
くつかまたは全ては、構成可能ワークフローサービスの実施形態によって自動的に実施さ
れるので、以下に詳細を記載するように、１つ以上の構成されたコンピューティングシス
テム上で実行する１つ以上のソフトウェアモジュールによって実装されてもよい。
【００８９】
上記のように、定義されたワークフローは、定義されたワークフローの入力データに対
応する１つ以上のデータソースワークフロー構成要素、データ上で実施される定義された
データ変換または他の操作に対応する１つ以上のデータ操作ワークフロー構成要素、及び
定義されたワークフローから出力データを提供することに対応する１つ以上のデータ転送
先ワークフロー構成要素を含む、少なくともいくつかの実施形態において複数のタイプで
あってもよい、複数のワークフロー構成要素を含むことができる。加えて、ワークフロー
構成要素間のデータフローに対応するワークフロー構成要素間で相互接続が定義されても
よいので、第１の構成要素からのデータ出力は、第２の構成要素への入力として提供され
てもよく、その関係が、第１の構成要素から第２の構成要素への接続として表される。少
なくともいくつかの実施形態及び状況において、構成可能ワークフローサービスは、任意
選択的に１つ以上の様式で構成された後、クライアントがクライアントの定義下ワークフ
ローにおいて選択かつ使用することができる事前定義されたワークフロー構成要素群を提
供することができる。さらに、少なくともいくつかの実施形態及び状況において、構成可
能ワークフローサービスは、クライアントが、クライアントの定義下ワークフローにおい
て使用されるいくつかまたは全てのワークフロー構成要素を供給またはその他定義するこ
とを可能にすることができる。
【００９０】
ワークフローに定義される各データソースワークフロー構成要素は、示されたデータソ
ースから取得されたデータに対応することができ、データの記憶場所及び記憶場所に関係
する任意選択的に追加のアクセス情報（例えば、クライアントと関連付けられたログイン
情報、メタデータ及び／またはデータ内容等、使用されるデータを識別するために使用す
る特定の検索または他の情報）等の情報を含むことができる。いくつかの実施形態におい
て、構成可能ワークフローサービスは、そのソースデータを記憶する際にクライアントに
よって使用されるための内部記憶場所を提供することができ、特定のデータソースは、こ
のような内部記憶場所に対応する一方で、他の実施形態及び状況においては、特定のデー
タソースは、クライアントによって提供される、またはそうでない場合は制御される、１
つ以上のネットワークからアクセス可能な記憶システム、１つ以上のオンライン記憶サー
ビス、１つ以上のオンラインデータ生成サービス等、構成可能ワークフローサービスの外
部に存在してもよい。使用され得るオンライン記憶サービスの例の非包括的リストは、多
様なタイプのオブジェクトデータを記憶するＡｍａｚｏｎ  Ｓｉｍｐｌｅ  Ｓｔｏｒａｇ
ｅ  Ｓｅｒｖｉｃｅ（Ｓ３）、関係データベース機能を提供するＡｍａｚｏｎ  Ｒｅｌａ
ｔｉｏｎａｌ  Ｄａｔａｂａｓｅ  Ｓｅｒｖｉｃｅ（ＲＤＳ）、キー値ペアを記憶するデ
ータベース機能を提供するＡｍａｚｏｎ  ＳｉｍｐｌｅＤＢ、ＮｏＳＱＬデータベース機
能を提供するＡｍａｚｏｎ  ＤｙｎａｍｏＤＢサービス、ｒａｗブロック記憶装置（例え
ば、ターゲットコンピュータシステム上の仮想ローカルブロック記憶装置をマウントする
）へのアクセスを提供するＡｍａｚｏｎ  Ｅｌａｓｔｉｃ  Ｂｌｏｃｋ  Ｓｔｏｒｅ（Ｅ
ＢＳ）等を含む。オンラインデータ生成サービスの例の非包括的リストは、ＲＳＳフィー
ド、アプリケーション及びサービスを実行するための監視機能を提供し、対応する情報を
生成するＡｍａｚｏｎ  Ｃｌｏｕｄｗａｔｃｈ  Ｓｅｒｖｉｃｅ等を含む。このため、デ
ータソースは、任意選択的に分散様式で実装される、関係または他のデータベース（例え
ば、ＨＢａｓｅオープンソース分散データベース、ＢｉｇＴａｂｌｅ分散データベース、
ＭｏｎｇｏＤＢデータベースシステム、Ａｐａｃｈｅ  Ｃａｓｓａｎｄｒａ分散データベ
ース管理システム等）、ハッシュ表、ファイルシステム、オブジェクトストア等の多様な
形式であり得る。データソースから取得され得るデータ群の例の非包括的リストは、ファ
イル（例えば、ウェブサーバーログ）、データベース行または他のレコード、記憶された
データオブジェクト、ストリームされたデータ群などを含む。
【００９１】
このため、いくつかの状況及び実施形態において、特定の定義されたワークフローは、
複数のデータソースからデータを取得かつ使用することができ、データソースのいくつか
または全ては、任意選択的に、構成可能ワークフローサービスの外部に存在する。加えて
、構成可能ワークフローサービスは、任意選択的に、構成可能ワークフローサービスの特
定の内部記憶機構に対応する、１つ以上の特定のオンライン記憶サービス（例えば、構成
可能ワークフローサービスと統合またはその他連携される、あるいはそうではなく、構成
可能ワークフローサービスとは連携されないオンライン記憶サービス）と対応する等のよ
うに、１つ以上のタイプのデータソースワークフロー構成要素を事前定義することができ
る。同様に、クライアントは、任意選択的に、クライアント特定の記憶場所、事前定義さ
れたデータソースワークフロー構成要素のないオンライン記憶サービス等に対応するよう
に等、１つ以上のデータソースワークフロー構成要素を定義することができる。
【００９２】
ワークフローに定義される各々のデータ操作ワークフロー構成要素は、データ操作ワー
クフロー構成要素への入力であるデータ上の１つ以上の定義されたデータ変換または他の
操作に対応することができる。加えて、データ操作ワークフロー構成要素からの出力は、
データ転送先ワークフロー構成要素に提供され（そして、それによってクライアントに提
供されるように）てもよく、またはその代わりに、（構成可能ワークフローサービスによ
って提供された１つ以上の記憶場所を使用して）次のデータ操作ワークフロー構成要素に
アクセス可能な記憶場所に中間データを記憶することによって、１つ以上の電子メッセー
ジ等を介して、次のデータ操作ワークフロー構成要素に提供される中間データであっても
よい。定義されたデータ操作は、１つ以上の入力データ群上の定義されたタイプの計算、
１つ以上の様式における複数の入力データ群の集合、１つ以上の入力データ群のうちのサ
ブセットの選択、ある記憶場所から別へのデータの移動等を含む、多様な形式であり得る
。例示的なデータ操作の非包括的リストは、分散データコピーの実施、１つ以上のＳＱＬ
（構造化問い合わせ言語）変換の実施、マップリデュースアーキテクチャ内部の１つ以上
のマップ及び／またはリデュース機能の実施（例えば、Ａｍａｚｏｎ  Ｅｌａｓｔｉｃ  
ＭａｐＲｅｄｕｃｅサービス内部で使用するために）、科学または数学パッケージ（例え
ば、ＭａｔＬａｂ、Ｍａｔｈｅｍａｔｉｃａ等）の使用、クライアントが提供したスクリ
プトまたは他のプログラムの実行等を含む。このように、いくつかの状況及び実施形態に
おいて、特定の定義されたワークフローは、事前定義及び／またはクライアント定義デー
タ操作ワークフロー構成要素を使用して、複数の定義されたデータ操作ワークフロー構成
要素を介して、複数のデータ操作演算を実施することができる。
【００９３】
ワークフローのために定義される各データ転送先ワークフロー構成要素は、定義された
ワークフローから、１つ以上の記憶場所にかつ１つ以上の様式で提供された出力データに
対応することができる。データ転送先ワークフロー構成要素（及びこのようなデータ転送
先ワークフロー構成要素に記憶される対応する情報）によって使用される記憶場所のタイ
プは、少なくともいくつかの実施形態において、構成可能ワークフローサービスに内部及
び／または外部である記憶場所を含めて、データソースワークフロー構成要素に類似また
は同一であってもよい。加えて、少なくともいくつかの実施形態及び状況において、特定
のデータ転送先ワークフロー構成要素は、特定のタイプのレポートを生成することによっ
て、１つ以上のタイプの定義された電子通信等を介して出力データを送信することによっ
て等、特定の様式に出力データを準備及び／または提供するための操作を含むことができ
る。このように、いくつかの状況及び実施形態において、特定の定義されたワークフロー
は、事前定義及び／またはクライアント定義のデータ転送先ワークフロー構成要素を使用
して、複数の定義されたデータ転送先ワークフロー構成要素を介して、複数のタイプの出
力データを複数の様式で提供することができる。
【００９４】
加えて、多様な実施形態において、クライアントは、多様な様式でワークフローを定義
することができる。例えば、構成可能ワークフローサービスの実施形態は、定義されたＧ
ＵＩ（「グラフィカルユーザーインターフェース」）、定義されたＡＰＩ（「アプリケー
ションプログラミングインターフェース」）、及び／または定義されたＣＬＩ（「コマン
ド行インターフェース」）等、クライアントによって使用されるための１つ以上のインタ
ーフェースを提供することができる。提供されたＧＵＩを使用する場合、クライアントを
代表するユーザーは、例えば、定義されているワークフローに特定のワークフロー構成要
素を指定するためにビジュアルエディタを使用することができ、さらに、データフローに
対応する特定のワークフロー構成要素間の相互接続を指定することができる。少なくとも
いくつかのこのような実施形態において、構成可能ワークフローサービスは、ワークフロ
ーを論理的に表すグラフとして、定義されたワークフローを表すことができ、多様なグラ
フノードが、特定のワークフロー構成要素に対応する。
【００９５】
構成可能ワークフローサービスは、さらに、多様な様式で何度も、クライアントのため
に定義されたワークフローを実装することができる。いくつかの実施形態において、定義
されたワークフローが使用されるたびに、構成可能ワークフローサービスは、各々が定義
されたワークフローのための少なくとも１つのワークフロー構成要素を実装する、複数の
コンピューティングノードを使用することによって等、定義されたワークフローを表す論
理的グラフの物理的コピーをインスタンス化する。具体的には、少なくともいくつかの実
施形態において、コンピューティングノードのいくつかまたは全ては、このような実装さ
れた各ワークフロー構成要素に対応するワークロードワーカープロセスを各々実行するよ
うに等、特定のワークフロー構成要素（例えば、これらのコンピューティングノード上に
対応するソフトウェア及び／またはデータをロードする）を実装するために、構成可能ワ
ークフローサービスによってプロビジョニングされる。コンピューティングノードは、少
なくともいくつかの実施形態において、個別の物理的コンピュータシステム、個別の仮想
マシン（例えば、物理的コンピュータシステム上でホストされる複数の仮想マシンのうち
の１つ）、分散様式で動作している複数の物理的コンピュータシステム等、多様な形式を
有することができる。定義されたワークフローに使用されるいくつかまたは全てのこのよ
うなコンピューティングノードは、いくつかの実施形態において、クライアントによって
使用されるために、構成可能ワークフローサービスによって提供される複数のコンピュー
ティングノードから選択されてもよい。加えて、いくつかまたは全てのこのようなコンピ
ューティングノードは、構成可能ワークフローサービスによって提供されるコンピューテ
ィングノードの代わりに、またはこれらに加えて、クライアントによって提供、またはそ
の他制御されてもよく、及び／あるいは１つ以上のオンライン実行サービスによって提供
されてもよい。使用され得る例示的なオンライン実行サービスの非包括的リストは、Ａｍ
ａｚｏｎ  Ｅｌａｓｔｉｃ  Ｃｏｍｐｕｔｅ  Ｃｌｏｕｄ（「ＥＣ２」）プログラム実行
サービス、（例えば、構成可能ワークフローサービスのためのコンピューティングノード
を表現または実装するサービスからコンピューティングシステムのクラスタを使用するこ
とによって）分散マップリデュース操作を実施するためのＡｍａｚｏｎ  Ｅｌａｓｔｉｃ
ＭａｐＲｅｄｕｃｅサービス等を含む。加えて、特定の定義されたワークフローが複数
回実装される場合、構成可能ワークフローサービスは、いくつかの実施形態において、（
例えば、構成可能ワークフローサービスによる自動化決定に基づいて、クライアントから
の命令に従って等）２つ以上のそのような時間の間、定義されたワークフローのいくつか
または全てのコンピューティングノードのプロビジョニング及び可用性を維持することが
できる。他の実施形態において、構成可能ワークフローサービスは、実装後に利用可能に
するために、いくつかまたは全てのこのようなコンピューティングノードを解放し、次の
実装のために、同じタイプのコンピューティングノード（任意選択的に異なるコンピュー
ティングノード）のプロビジョニングを提供することができる。
【００９６】
定義されたワークフローは、少なくともいくつかの実施形態において、追加のタイプの
関連情報をさらに有することができる。例えば、クライアントは、例えば、直ちに実装す
るためのクライアント指示に基づいて、１つ以上の定義された将来の時刻に将来の実装を
スケジュール設定することによって、（例えば、特定のソースデータの可用性に少なくと
も部分的に基づいて）１つ以上の定義された条件が満たされたときに１つ以上の将来の実
装をスケジュールすることによって等、定義されたワークフローを実装するときを示す情
報を指定することができる。定義された条件は、特定のワークフロー構成要素またはその
代わりに定義されたワークフロー全体と関連付けられる条件等、多様な様式において指定
されてもよい。例えば、特定のワークフロー構成要素は、ワークフロー構成要素をいつ実
行するかを決定するために評価される定義された事前条件基準を有することができる。加
えて、特定のワークフロー構成要素は、いつ実行を完了するか、及び／または出力データ
をどこへ提供するか（例えば、次のワークフロー構成要素へ、中間記憶場所へ等）を決定
するために評価される定義された事後条件基準を有することができる。いくつかの実施形
態及び状況において、定義されたワークフローはさらに、１つ以上の指定された条件が満
たされる、または満たされなかったとき（例えば、定義されたワークフローが特定の時刻
に実装されない場合、特定のソースデータが利用可能ではない場合等）、クライアントに
通知を提供する（または他のアクティビティを実施する）ために使用され得る１つ以上の
関連アラームを有してもよい。
【００９７】
構成可能ワークフローサービスはさらに、少なくともいくつかの実施形態において、構
成可能ワークフローサービスのクライアントは、構成可能ワークフローサービスによって
提供される機能の少なくともいくつかに対して、構成可能ワークフローサービスのプロバ
イダに料金を支払う顧客である等、料金ベースのサービスであってもよい。加えて、１つ
以上のオンライン記憶サービス及び／またはオンライン実行サービスが、特定のクライア
ントのために特定の定義されたワークフローを実装する一環として、構成可能ワークフロ
ーサービスによって使用される場合、このような他のサービスのプロバイダ（単数または
複数）もまた、構成可能ワークフローサービスを介して、またはクライアントに直接に、
このような使用に対する料金を任意選択的に課金することができる。
【００９８】
このように、データパイプラインにおける構成可能ワークフローサービスの使用は、ク
ライアントが、特定の時刻にまたはその他特定の条件が満たされるときに複数のソースか
らデータを収集することをスケジュール設定することを可能にする、ソースデータで定義
されたタイプのデータ操作演算を実施する、及び多様な様式で定義されたワークフローに
よって生成された出力データを定義することを含めて、多様な実施形態において多用な利
点を提供することができる。追加の利点は、本明細書の他の部分で検討され、そうでない
場合は当業者によって理解されるであろう。
【００９９】
一実施形態において、構成可能ワークフローサービス（「ＣＷＳ」）ワークフロー（「
パイプライン」とも呼ばれる）は、パイプラインを形成するノード（「オブジェクト」と
も呼ばれる）の記述を可能にする構成言語を介して定義される。一実施形態において、パ
イプラインは、データソース、アクティビティ、事前条件、事後条件、スケジュール、ア
ラームというカテゴリのうちのいずれかからのオブジェクトを含むことができる。一実施
形態において、データソースは、データ操作ワークフロー構成要素（この例示的な実施形
態において、「アクティビティ」とも呼ばれる）への入力、またはそこからの出力である
。
【０１００】
一実施形態において、アクティビティとは、データ処理変換、データコピー等、実施さ
れる操作である。アクティビティは、所定の状態で警告し、失敗した場合に複数回再試行
するように設定することができる。一実施形態において、事前定義されたアクティビティ
は、Ｃｏｐｙ、ＳＱＬＴｒａｎｓｆｏｒｍ、ＨｉｖｅＱＬＴｒａｎｓｆｏｒｍ、Ｅｌａｓ
ｔｉｃＭａｐＲｅｄｕｃｅＴｒａｎｓｆｏｒｍ、ＣｏｍｍａｎｄＬｉｎｅＴｒａｎｓｆｏ
ｒｍ、及び他の適切なアクティビティを含むことができる。
【０１０１】
一実施形態において、事前条件または事後条件は、データソースが利用可能及び／また
は良好に形成されたと考えられるときに真と評価するデータソースと関連付けられるアク
ションである。成功して完了する事前条件は、入力としてデータソースを消費する次のア
クティビティが実行されることを可能にする。成功して完了する事後条件は、データソー
スを作成するアクティビティが成功して完了したと考えられることを可能にすることがで
きる。
【０１０２】
一実施形態において、スケジュールは、データの周期性を記述するデータソースの属性
、または実行するときの周期性を定義するアクティビティの属性である。周期性は、１分
以上、１時間以上、１日以上、１週間以上、１ヵ月以上等の粒度であり得る。
【０１０３】
一実施形態において、アラームは、通知サービス（例えば、アマゾンのＳＮＳ、または
Ｓｉｍｐｌｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ）にパブリッシュされ、電子
通信（例えば、電子メール）等を介して送信されるメッセージを記述する。パイプライン
及び個別のアクティビティは、失敗及び／または成功に定義されたアラームを有すること
ができる。
【０１０４】
パイプラインシステムのユーザーは、基本的リソースとしてパイプラインを作成するこ
とができる。パイプラインは、例えば、無期限の時間にわたって、１回から毎時間の範囲
で、構成可能な回数実行する１つ以上のスケジュール設定されたアクティビティを含む。
バックエンド上では、これらのアクティビティの各々は、継続してポーリングするＳｉｍ
ｐｌｅ  Ｗｏｒｋｆｌｏｗ  Ｓｅｒｖｉｃｅ（ＳＷＦ）に基づいてオブジェクト定義とし
て実装されてもよく、必要に応じてオブジェクト定義（別名アクティビティ）を表現する
個別のスケジュール設定された実行に対応するＳＷＦベースのオブジェクトを作成する。
各オブジェクト定義（及びその関連付けられたスケジュール設定された実行）は、パイプ
ラインシステムが失敗を自動的に再試行できるため、１つ以上の実際のＳＷＦオブジェク
ト実行を要求することができる。これらのオブジェクトの全ては、その作成と関連付けら
れるＳＷＦコスト、及びその追跡と関連付けられるＤｙｎａｍｏＤＢ（または他のデータ
ベース）コストの両方を有することができる。実行は、本明細書ではタスク実行者とも呼
ばれる、遠隔実行者によって実施されてもよく、作業のためにパイプラインアプリケーシ
ョンプログラミングインターフェース（ＡＰＩ）をポーリングしてから、適切に応答する
Ｊａｖａ（登録商標）エージェントである。このポーリング動作は、実行タイムアウトを
追跡するために使用されるＤｙｎａｍｏ操作の形式において、パイプラインシステムには
ゼロではないコストを有する。
【０１０５】
加えて、パイプラインシステムは、例えば、その制御プレーンから実施されるデータ可
用性チェック等、制御プレーン事前条件をサポートすることができる。これらのチェック
では、ポーリング動作及び実行の両方は、パイプラインシステムの制御プレーンにおいて
、マシンのフリート上で実施されてもよい。これらの事前条件は、パイプラインシステム
の制御プレーンにおけるハードウェア可用性要件に起因して、ＥＤＰにより高いコストを
課し得る。加えて、パイプラインシステムに寄与するいくつかのコスト（例えば、コンソ
ールをホストするウェブサーバーハードウェア、顧客のＡＰＩリクエストに応答するウェ
ブサーバー）は、オブジェクト及びパイプラインの数に応じて徐々に拡大する。
【０１０６】
図１３は、構成可能ワークフローサービスの多様なクラインアントのために定義された
ワークフローの作成及び実行を管理する構成可能ワークフローサービス１１１０の例示的
実施形態を図示するネットワーク図である。定義されたワークフローを実装する一部とし
て、構成可能ワークフローサービス１１１０はさらに、定義されたワークフローに対応す
る指定されたアクティビティを各々実施するために特定のコンピューティングノードをプ
ロビジョニングする。いくつかの実施形態において、構成可能ワークフローサービス１１
１０は、クライアントのために定義されたワークフローが実行されてもよい、コンピュー
ティングノード群１１４０を任意選択的に提供する。他の実施形態において、構成可能ワ
ークフローサービスによって使用されるコンピューティングノードのいくつかまたは全て
は、そのために定義されたワークフローが実装されるクライアントによって、１つ以上の
オンライン実行サービスによって等、構成可能ワークフローサービスの外部に提供されて
もよい。加えて、いくつかの実施形態において、構成可能ワークフローサービス１１１０
は、任意選択的に、定義されたワークフローの実行を促進するためにデータが記憶されて
もよい、１つ以上の記憶ノード１１５０を含む。例えば、存在する場合、記憶ノード１１
５０は、定義されたワークフローの実行中に生成される中間データ結果を記憶するために
使用されてもよく、いくつかの実施形態において、さらに、定義されたワークフローに提
供されたソースデータ、及び／または定義されたワークフローによって生成された最終出
力データを記憶するために使用されてもよい。図１３に図示されないが、構成可能ワーク
フローサービスは、図１４を参照して、及び本明細書の他の部分で詳細に記載されるよう
に、１つ以上の構成されたコンピューティングシステムを使用して実装されてもよい。
【０１０７】
図１３はさらに、１つ以上のネットワーク１１９０、及び構成可能ワークフローサービ
ス１１１０のクライアントが、ワークフローを定義かつ実行するためにサービス１１１０
と相互作用することができる多様なクライアントコンピューティングシステム１１６０を
図示する。図１３のネットワーク（単数または複数）１１９０は、イントラネット、イン
ターネット、インターネットへの及び／またはインターネットからのアクセスを備える１
つ以上の非公開ネットワーク、セルラーネットワーク、ローカルエリアネットワーク、ま
たは任意の他のこのようなネットワーク、あるいはこれらの組み合わせを含む、任意の適
切なネットワークまたはネットワークの組み合わせを含むことができる。ネットワーク上
の通信は、有線または無線接続、及びこれらの組み合わせによって可能にされてもよい。
【０１０８】
いくつかの実施形態において、構成可能ワークフローサービス１１１０は、クライアン
トが、サービス１１１０との多様な相互作用を実施することを可能にするために等、ＧＵ
Ｉ（図示せず）及び／またはＡＰＩ（図示せず）のうちの１つまたは両方を提供すること
ができる。例えば、特定のクライアントを代表するユーザー（図示せず）は、ネットワー
ク（単数または複数）１１９０上から構成可能ワークフローサービス１１１０とのさらな
る相互作用を発生させるために、クライアントコンピューティングシステム１１６０のう
ちの１つとローカルに相互作用することができる。ユーザーは、例えば、ユーザーがクラ
イアントのために関心の１つ以上のワークフローを定義することができる、構成可能ワー
クフローサービスのワークフローエディタモジュール１１２０と相互作用することができ
る。ユーザーとの相互作用の一環として、構成可能ワークフローサービス１１１０は、ク
ライアント及び任意選択的にユーザー代表に関する多様なクライアント情報１１１２を記
憶することができ、情報１１１４の一部としてクライアントのために新しく定義されたワ
ークフローの特定の定義を記憶することができる。いくつかの実施形態において、特定の
ワークフローの定義は、１つ以上の事前定義されたシステムが提供するワークフロー構成
要素定義１１１６を使用することによって等、１つ以上の定義されたワークフロー構成要
素を選択し、これらのワークフロー構成要素間の相互作用を指定する際のユーザーによる
アクションを含むことができる。他の実施形態において、構成可能なワークフローサービ
ス１１１０は、このようなシステムによって提供される既定のワークフロー構成要素を一
切提供しなくてもよい。新しいワークフローを定義することの一部として、ユーザーは、
ワークフロー定義のためにソースデータが呼び出され、使用される１つ以上の情報源場所
、及び定義されたワークフローによって生成されるデータが提供される１つ以上の転送先
の場所をさらに指定することができる。構成可能なワークフローサービス１１１０によっ
て使用される多様な情報１１１２、１１１４、及び１１１６は、構成可能なワークフロー
サービスのデータベース等、構成可能なワークフローサービス１１０をサポートまたは提
供する１つ以上のシステム上に、さらに記憶されてもよいが、このようなシステムは、図
１３には図示されない。
【０１０９】
加えて、クライアントを代表するユーザーは、いくつかの実施形態において、任意選択
的に、新しいワークフローを定義することの一部として、１つ以上の新しいワークフロー
構成要素を定義することができ、定義する場合、このようなクライアント定義ワークフロ
ー構成要素は、少なくともいくつかの実施形態において、情報１１１６に記憶された定義
情報をさらに有することができる。クライアント定義ワークフロー及び任意のクライアン
ト定義ワークフロー構成要素は、いくつかの実施形態において、クライアントによって別
段の指定がない限り、非公開として処理されてもよいが（例えば、その他指定されない限
り、そのクライアントのみにアクセス可能または表示可能である）、他の実施形態及び状
況において、少なくともいくつかのそのようなクライアント指定情報は、その代わりに、
他のクライアントがそのクライアントの定義ワークフロー構成要素及び／またはワークフ
ローのうちのいくつかまたは全てを使用することを可能にする等、指定された状況におい
て他のクライアントに利用可能にされてもよい（例えば、このような情報を定義したクラ
イアントが、他による使用を承認する場合、このような情報を定義したクライアントに提
供される料金に対してまたは他の利点に対して）。同様な様式において、クライアントの
定義ワークフローによって使用されるソースデータ及びクライアントの定義ワークフロー
によって生成される最終出力データは、少なくともいくつかの実施形態において、別段の
指定がない限り、そのクライアントに対してプライベートとして処理されてもよいが、他
の実施形態において、このようなソースデータ及び／または最終出力データのうちのいく
つかまたは全ては、そうではなく、指定された状況において他のクライアントに利用可能
であってもよい（例えば、このような情報と関連付けられるクライアントが他による使用
を承認する場合、そのデータが関連付けられるクライアントに対する料金に対してまたは
他の利点に対して）。
【０１１０】
クライアントが、定義されたワークフローのために、ソースデータが取得されてもよい
、及び／または最終出力データが提供されてもよい、１つ以上の記憶場所を示す場合、こ
のような記憶場所は、他の場所でさらに詳細が検討されるように、多様な実施形態におい
て多様な形態を有することができる。一例として、少なくともいくつかの実施形態におい
て、構成可能ワークフローサービスは、単一のシステム１１０５（例えば、単一のエンテ
ィティによって運用される単一のシステム）を形成するように、１つ以上の特定の任意選
択のオンラインス記憶サービス１１４５と統合またはその他提携されてもよい。その場合
、このような任意選択のオンライン記憶サービス１１４５との相互作用１１４７は、ソー
スデータを呼び出すために、及び／または最終出力データを記憶するために実行されても
よい。その上、少なくともいくつかの実施形態において、ワークフローの実行中に生成さ
れる中間データ結果は、１つ以上の任意選択の記憶ノード１１５０に加えて、またはその
代わりであるかに関わらず、定義されたワークフローの第１の部分によって生成され、ワ
ークフローの第２の定義部分によってその後、アクセスされ、使用されるために、このよ
うなオンライン記憶サービス１１４５に同様に記憶されてもよい。さらに、少なくともい
くつかの実施形態及び状況において、１つ以上のオンライン記憶サービス１１７０は、ネ
ットワーク１１９０上から、クライアントコンピューティングシステム１１６０及び構成
可能ワークフローサービス１１１０に利用可能であり、任意選択のオンライン記憶サービ
ス１１４５に加えて、またはそのいくつかまたは全ての代わりに、ネットワーク（単数ま
たは複数）１１９０上から同様な様式で使用されてもよい。加えて、少なくともいくつか
の実施形態及び状況において、特定のクライアントは、ネットワーク（単数または複数）
１１９０上から同様に使用され得る、１つ以上の他のコンピューティングシステム１１８
５を使用する、１つ以上のクライアント特定の記憶システムまたは他の記憶場所を提供す
ることができる。
【０１１１】
クライアントがワークフローを定義するために構成可能ワークフローサービスと相互作
用した後、クライアントは、定義されたワークフローの実行を開始するために、構成可能
ワークフローサービスのワークフローエンジンモジュール１１３０とさらに相互作用する
ことができる。特定のワークフローの実行は、クライアントからの対応する命令直後に実
施されるように、指定された将来の時刻に発生、またはワークフローの実行を開始する他
の指定された条件（１つ以上の定義された事前条件等）が満たされる時等、多様な様式で
開始されてもよい。ワークフローエディタモジュール１１２０と同様に、ワークフローエ
ンジンモジュール１１３０は、いくつかの実施形態において、クライアントによって使用
されるためのＧＵＩインターフェース及び／または及びＡＰＩインターフェースを提供す
ることができる。定義されたワークフローの実行が開始されると、例示的な実施形態にお
けるワークフローエンジンモジュール１１３０は、情報１１１４からその定義されたワー
クフローのためのワークフロー定義情報を呼び出し、１つ以上のコンピューティングノー
ド上で定義されたワークフローの実行を開始する。具体的には、ワークフロー定義は、各
々が定義された操作に対応し、多様な様式で相互接続される多様な論理ノードで構築され
てもよく、ワークフローエンジンモジュール１１３０は、特定のこのような操作を実施す
るため、ならびにプロビジョニングするためのアクティビティをさらに実施するために使
用する特定のコンピューティングノードを選択することができ、各々のこのような選択さ
れたコンピューティングノード上で対応するワークフローワーカープロセスの実行を開始
することができる。このようなコンピューティングノードをプロビジョニング、及び／ま
たはコンピューティングノード上でワークフローワーカープロセスを実行する一環として
、定義されたワークフローの他のワークフローワーカーによって使用するための中間結果
データのためを含む、使用される入力データを取得するために、及び／または生成される
結果データを記憶するために、１つ以上の記憶場所との追加の相互作用が実施されてもよ
い。
【０１１２】
定義されたワークフローを実装するために使用されるコンピューティングノードのいく
つかまたは全ては、例えば、存在する場合、構成可能なワークフローサービス１１１０に
よって提供される任意選択のコンピューティングノード１１４０から選択されてもよく、
ワークフローワーカープロセス１１４２は、定義された操作を実装するために、それらの
コンピューティングノード上で実行されてもよい。他の実施形態において、ワークフロー
エンジンモジュール１１３０は、任意選択のコンピューティングノード１１４０の代わり
に、またはこれに加えて、構成可能ワークフロー表面１１１０によって提供されない、コ
ンピューティングノードを使用することができる。例えば、いくつかの実施形態及び状況
において、特定のクライアントは、１つ以上の他のコンピューティングシステム１１８５
を提供またはそうでない場合は制御することができ、ワークフローエンジン１１３０は、
このような他のコンピューティングシステム１１８５を、そのクライアントの定義された
ワークフローを実行する際に使用するためのコンピューティングノードとして構成かつ使
用することができる。加えて、いくつかの実施形態において、１つ以上のオンラインプロ
グラム実行サービス１１４８及び／または１１７５は、多様な様式においてプログラムを
実行する際に利用可能であってもよく、利用可能である場合、特定のクライアントの定義
されたワークフローのいくつかまたは全てを実行するために、コンピューティングノード
（図示せず）を提供するために使用されてもよい。例えば、ワークフローエンジンモジュ
ール１１３０は、このようなオンラインプログラム実行サービスによって提供された特定
のコンピューティングノード上で特定のワークフローワーカープロセスの実行をプロビジ
ョニングかつ開始することができる。一例として、少なくともいくつかの実施形態におい
て、構成可能ワークフローサービスは、上記の単一のシステム１１０５の一部としてのよ
うに、１つ以上の特定の任意選択のオンラインプログラム実行サービス１１４８（１つ以
上の任意選択の記憶サービス１１４５に加えて、またはその代わりに）と統合されても、
またはその他連携されてもよい。その場合、このような任意選択のオンラインプログラム
実行サービス１１４８との相互作用１１４９は、コンピューティングノードをプロビジョ
ニングし、特定のワークフロー構成要素の実行を開始し、特定のワークフロー構成要素に
よって生成された出力データを受信する等のために実施されてもよい。
【０１１３】
他の実施形態において、構成可能ワークフローサービス１１１０は、定義されたワーク
フローのために特定のタイプのソースデータを生成して提供する、クライアントの定義さ
れたワークフローによって生成された最終出力データを管理することに関する追加のアク
ティビティを実施する等、追加の技法を実施することができる。加えて、構成可能ワーク
フローサービス１１１０は、いくつかの実施形態において、サーバーコンピューティング
システム（単数または複数）の１つ以上のハードウェアＣＰＵプロセッサ（図示せず）を
プログラムする等、説明された技法のいくつかまたは全てを実施するために、サーバーコ
ンピューティングシステム（単数または複数）をプログラムまたはその他構成するように
１つ以上のサーバーコンピューティングシステム上で実行するソフトウェア命令に基づい
て実装されてもよい。このようなソフトウェア命令は、例えば、モジュール１１２０及び
／または１１３０を実装するために使用されてもよく、あるいはその代わりに、構成可能
ワークフローサービスの機能は、他のタイプのモジュールを使用して提供されてもよい。
【０１１４】
この様式において、構成可能ワークフローサービス１１１０は、操作されるデータを取
得するために多様なタイプのオンラインデータソースと相互するために、及び記憶または
他の使用のために生成される出力データを提供するために、部分的または全体的に、構成
可能ワークフローサービス１１１０のコンピューティング及び記憶リソースを使用して実
行されてもよいワークフローをクライアントが定義することを可能にすることを含めて、
多様な外部クライアントに多様なメリットを提供する。構成可能ワークフローサービス１
１１０の特定の操作に関する追加の詳細は、本明細書の他の部分に含まれる。
【０１１５】
図１３の前述の例示的実施形態は、各々が１つ以上の関連付けられたユーザーを有する
ことができる、１つ以上のクライアントシステムに関連して多様なタイプの機能を提供す
る構成可能ワークフローサービス１１１０に関して記載するが、多様な他の実施形態が存
在し得ることが理解されるであろう。例えば、少なくともいくつかの実施形態及び状況に
おいて、クライアントは、組織または他のグループ（例えば、個人の代わりに複数の人を
有する企業）を表すことができる。このため、クライアントエンティティは、多様な実施
形態において多様な形態を有することができる。
【０１１６】
いくつかの実施形態において、使用される構成可能ワークフローサービス１１１０なら
びに任意選択的に任意のオンライン記憶サービス及び／またはオンラインプログラム実行
サービスは、各々、１つ以上の料金ベース構造または合意に従って運用することができる
。例えば、構成可能ワークフローサービス１１１０からの記載の技法のいくつかまたは全
てへのアクセスは、いくつかの実施形態において、構成可能ワークフローサービス１１１
０及び／または構成可能ワークフローサービス１１１０の記載される技法を使用する少な
くともいくつかのクライアントシステムのプロバイダまたは運用者に対する料金ベースま
たは他の支払い様式において提供されてもよい。一例として、構成可能ワークフローサー
ビス１１１０のクライアントは、構成可能ワークフローサービス１１１０によって提供さ
れる機能を使用するために、１回払い料金、定期的（例えば月次）料金、及び／または１
つ以上のタイプの使用量ベース料金を支払うことができる。このような料金は、特定のワ
ークフローを定義するために実施される数量及び／または相互作用のタイプに基づく、定
義されたワークフロー及び／または定義されたワークフロー構成要素のいくつかまたは全
てのサイズ及び／またはタイプ、定義されたワークフローを実行する際に使用されたコン
ピューティングリソースの測定（例えば、使用されたコンピューティングノードの数）、
使用されたプロセッサ能力の測定（例えば、ＣＰＵサイクル）、定義されたワークフロー
の実行中に発生する時間量、定義されたワークフローのためにコンピューティングノード
をプロビジョニングする際のアクティビティ、それらのコンピューティングノードが、ソ
ースデータが利用可能になる、または他の事前条件が満たされるまで待機する間など、定
義されたワークフローのためプロビジョニングされたコンピューティングノードが他の使
用のために利用不可能である時間量等の定義されたワークフローの使用量に基づく、デー
タのサイズ、記憶の時間量等の記憶及び／または転送されるデータの数量に基づく、記憶
、操作、及び／または生成される特定のデータグループの内容または他の特徴に基づく等
、の非包括的リストに含まれるような、１つ以上の因子及びアクティビティに基づくこと
ができる。
【０１１７】
本開示の実施形態は、以下の付記を考慮して説明することができる。
１．プロバイダネットワークの複数のリソースを実装するように構成される複数のコ
ンピューティングデバイスであって、リソースが、複数のリソースプールに体系化され、
各リソースプールが関連付けられた使用量コストを有する、複数のコンピューティングデ
バイスと、
リソースマネージャーを実装するように構成される１つ以上のコンピューティングデ
バイスであって、リソースマネージャーが、
タスクの必要期限時刻であって、タスクの実行の完了の期限を含む、必要期限時刻を
含むタスク仕様を受信することと、
複数のリソースプールの複数のリソース構成の各々に対してタスクの実行を完了する
ための推定期間を決定することと、
必要期限時刻前にタスクの実行の完了を可能にする、それぞれの推定期間を有する複
数のリソース構成のうちのリソース構成から、最低の使用量コストを有する１つ以上のリ
ソース構成を選択することと、
選択された１つ以上のリソース構成を有するリソースプールのうちの１つ以上で、タ
スクの実行の開始のためのスケジュール設定された時刻であって、少なくとも推定期間だ
け必要期限時刻よりも早い、スケジュール設定された時刻を決定することと、
必要期限時刻前に、選択された１つ以上のリソース構成を有する１つ以上のリソース
プール上でタスクの実行の完了を保証することと、を行うように動作可能である、１つ以
上のコンピューティングシステムと、を備えるシステム。
２．タスクが、複数の追加ノードを含むグラフ内の第１のノードに対応し、複数の追
加ノードの各々が、それぞれの追加タスクに対応し、１つ以上のリソース構成が、タスク
及び追加タスクのうちの１つ以上を実行するグローバルコストを最小限に抑えるように選
択される、付記１に記載のシステム。
３．リソースマネージャーが、
タスクの実行に対する顧客価格を決定するように動作可能であり、顧客価格が、必要
期限時刻に基づく割引を含む、付記１に記載のシステム。
４．タスクのための実行ウィンドウが、第１の時点で開始し、かつ第２の時点で終了
し、第１の時点が、タスクの定義が受信される時点を含み、第２の時点が、必要期限時刻
に基づき、割引が、実行ウィンドウの大きさに基づいて異なる、付記１に記載のシステム
。
５．タスクの定義を受信することであって、定義が、必要期限時刻を含み、必要期限
時刻が、タスクの実行の完了に対するユーザー指定期限を含む、受信することと、
複数のコンピューティングリソースの各々に対して、タスクの実行を完了するための
推定期間を決定することと、
複数のコンピューティングリソースの各々に対して、タスクの実行を完了する推定コ
ストに基づいて、コンピューティングリソースのうちの１つ以上を選択することと、
選択された１つ以上のコンピューティングリソースを使用して、スケジュール設定さ
れた時刻にタスクの実行を開始することであって、スケジュール設定された時刻が、少な
くとも推定期間だけ必要期限時刻よりも早い、開始することと、を含む、コンピュータ実
装方法。
６．タスクの実行のために、１つ以上のコンピューティングリソースの構成を選択す
ることをさらに含み、構成が、実行ウィンドウ内でタスクの実行のコストを最小限に抑え
るように選択され、実行ウィンドウのエンドポイントが、必要期限時刻に基づく、付記５
に記載の方法。
７．複数のコンピューティングリソースが使用量コストの面で異なり、コンピューテ
ィングリソースのうちの１つ以上を選択することが、
必要期限時刻前に、タスクの実行の完了を可能にする、それぞれの推定期間を有する
複数のコンピューティングリソースのうちのコンピューティングリソースから、最低の使
用量コストを有する１つ以上のコンピューティングリソースを選択することを含み、
タスクの実行が、選択された１つ以上のコンピューティングリソースを使用して、ス
ケジュール設定された時刻に開始される、付記５に記載の方法。
８．タスクの実行を完了するための推定期間が、タスクの１つ以上の以前の実行に基
づいて決定される、付記５に記載の方法。
９．タスクの実行を完了するための推定期間が、１つ以上の他のタスクの以前の実行
に基づいて決定される、付記５に記載の方法。
１０．１つ以上のコンピューティングリソースが、タスク及び１つ以上の追加のタス
クを実行するグローバルコストを最小限に抑えるように選択される、付記５に記載の方法
。
１１．タスクの実行のための顧客価格を評価することをさらに含み、顧客価格が、必
要期限時刻に基づく割引を含む、付記５に記載の方法。
１２．タスクのための実行ウィンドウが、第１の時点で開始し、かつ第２の時点で終
了し、第１の時点が、タスクの定義が受信される時点を含み、第２の時点が、必要期限時
刻に基づき、割引が、実行ウィンドウの大きさに基づいて異なる、付記１１に記載の方法
。
１３．少なくとも１つのプロセッサと、
少なくとも１つのプロセッサに連結されたメモリであって、メモリが、プログラム命
令を記憶し、プログラム命令が、少なくとも１つのプロセッサによって実行可能であって
、
タスクの必要期限時刻を受信することであって、必要期限時刻が、タスクの実行の
完了の期限を含む、受信することと、
複数のリソース構成の各々に対してタスクの実行を完了するための推定期間を決定
することであって、複数のリソース構成の各々が、それぞれの使用量コストを有する、決
定することと、
実行ウィンドウ内でタスクの実行のコストを最小限に抑えるようにリソース構成の
うちの１つ以上を選択することであって、実行ウィンドウのエンドポイントが、必要期限
時刻に基づく、選択することと、
選択された１つ以上のリソース構成を有する１つ以上の計算インスタンス上のタス
クの実行のためのスケジュール設定された時刻を決定することであって、スケジュール設
定された時刻が、少なくとも推定期間だけ必要期限時刻よりも早い、決定することと、を
行うように実行可能である、メモリと、を備える、システム。
１４．１つ以上のリソース構成が、タスク及び１つ以上の追加のタスクの実行のグロ
ーバルコストを最小限に抑えるように選択される、付記１３に記載のシステム。
１５．リソース構成のうちの１つ以上を選択することにおいて、プログラム命令が、
少なくとも１つのプロセッサによってさらに実行可能であって、
必要期限時刻前にタスクの実行の完了を可能にする、それぞれの推定期間を有する複
数のリソース構成のうちのリソース構成から、最低の使用量コストを有する１つ以上のリ
ソース構成を選択することがさらに実行可能である、付記１３に記載のシステム。
１６．タスクの実行を完了するための推定期間が、タスクの１つ以上の以前の実行に
基づいて決定される、付記１３に記載のシステム。
１７．プログラム命令が、少なくとも１つのプロセッサによってさらに実行可能であ
って、
タスクの実行のための顧客価格を決定することをさらに実行可能であり、顧客価格が
、必要期限時刻に基づく割引を含む、付記１３に記載のシステム。
１８．タスクのための実行ウィンドウが、第１の時点で開始し、かつ第２の時点で終
了し、第１の時点が、タスクの定義が受信される時点を含み、第２の時点が、必要期限時
刻に基づき、割引が、実行ウィンドウの大きさに基づいて異なる、付記１７に記載のシス
テム。
１９．タスクの定義を受信することであって、定義が、タスクの実行の完了の期限を
含む、受信することと、
タスクの実行のために１つ以上のリソース構成を選択することであって、１つ以上の
リソース構成が、タスクの実行のコストを最小限に抑えるように選択される、選択するこ
とと、
スケジュール設定された時刻に、選択された１つ以上のリソース構成を使用して、実
行するためのタスクをスケジュール設定することであって、スケジュール設定された時刻
が、タスクの実行を完了するための少なくとも推定期間だけ期限よりも早い、スケジュー
ル設定することと、を実施するためのコンピュータ実行可能プログラム命令を記憶する、
コンピュータ可読記憶媒体。
２０．１つ以上のリソース構成が、タスク及び１つ以上の追加のタスクの実行のグロ
ーバルコストを最小限に抑えるように選択される、付記１９に記載のコンピュータ可読記
憶媒体。
２１．複数のリソース構成が、使用量コストの点で異なり、１つ以上のリソース構成
を選択することが、
期限前に、タスクの実行を完了することが可能な複数のリソース構成のうちのリソー
ス構成から、最低の使用量コストを有する１つ以上のリソース構成を選択することをさら
に含み、
タスクの実行が、選択された１つ以上のリソース構成を使用して、スケジュール設定
された時刻に開始される、付記１９に記載のコンピュータ可読記憶媒体。
２２．タスクの実行を完了するための推定期間が、タスクの１つ以上の以前の実行に
基づいて決定される、付記１９に記載のコンピュータ可読記憶媒体。
２３．プログラム命令が、
タスクの実行のための顧客価格を評価することを実施するためにさらにコンピュータ
実行可能であり、顧客価格が、期限に基づく割引を含む、付記１９に記載のコンピュータ
可読記憶媒体。
２４．タスクのための実行ウィンドウが、第１の時点で開始し、かつ第２の時点で終
了し、第１の時点が、タスクの定義が受信される時点を含み、第２の時点が、期限に基づ
き、割引が、実行ウィンドウの大きさに基づいて異なる、付記２３に記載のコンピュータ
可読記憶媒体。
例示的コンピュータシステム
【０１１８】
少なくともいくつかの実施形態において、本明細書に記載される技術の１つ以上の一部
または全てを実装するコンピュータシステムは、１つ以上のコンピュータ可読媒体を含む
、またはこれらにアクセスするように構成される汎用コンピュータシステムを含むことが
できる。図１４は、このような汎用コンピューティングデバイス３０００を示す。図示さ
れる実施形態において、コンピューティングデバイス３０００は、入力／出力（Ｉ／Ｏ）
インターフェース３０３０を介して、システムメモリ３０２０に連結された１つ以上のプ
ロセッサ３０１０を含む。コンピューティングデバイス３０００は、Ｉ／Ｏインターフェ
ース３０３０に連結されたネットワークインターフェース３０４０をさらに含む。
【０１１９】
多様な実施形態において、コンピューティングデバイス３０００は、１つのプロセッサ
３０１０を含むユニプロセッサシステム、またはいくつかのプロセッサ３０１０（例えば
、２、４、８、または別の適切な数）を含むマルチプロセッサシステムであってもよい。
プロセッサ３０１０は、命令を実行することが可能な任意の適切なプロセッサを含むこと
ができる。例えば、多様な実施形態において、プロセッサ３０１０は、ｘ８６、Ｐｏｗｅ
ｒＰＣ、ＳＰＡＲＣ、またはＭＩＰＳ  ＩＳＡ、あるいは任意の他の適切なＩＳＡ等、多
様な命令セットアーキテクチャ（ＩＳＡ）のうちのいずれかを実装する汎用または埋め込
み型プロセッサであってもよい。マルチプロセッサシステムにおいて、プロセッサ３０１
０の各々は、一般に、同じＩＳＡを実装することができるが必ずしもそうではない。
【０１２０】
システムメモリ３０２０は、プロセッサ（単数または複数）３０１０によってアクセス
可能なプログラム命令及びデータを記憶するように構成されてもよい。多様な実施形態に
おいて、システムメモリ３０２０は、静的ランダムアクセスメモリ（ＳＲＡＭ）、同期動
的ＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュタイプメモリ、または任意の他の種類の
メモリ等、任意の適切なメモリ技術を使用して実装されてもよい。図示される実施形態に
おいて、上記の方法、技術、及びデータ等、１つ以上の所望される機能を実装するプログ
ラム命令及びデータは、コード（すなわち、プログラム命令）３０２５及びデータ３０２
６として、システムメモリ３０２０内部に記憶されて示される。
【０１２１】
一実施形態において、Ｉ／Ｏインターフェース３０３０は、ネットワークインターフェ
ース３０４０または他の周辺インターフェースを含めて、デバイス内のプロセッサ３０１
０と、システムメモリ３０２０と、任意の周辺デバイスとの間のＩ／Ｏトラフィックを調
整するように構成されてもよい。いくつかの実施形態において、Ｉ／Ｏインターフェース
３０３０は、１つの構成要素（例えば、システムメモリ３０２０）を、別の構成要素（例
えば、プロセッサ３０１０）によって使用されるために適切な形式へデータ信号を変換す
るために、任意の必要なプロトコル、タイミング、または他のデータ変換を実施すること
ができる。いくつかの実施形態において、Ｉ／Ｏインターフェース３０３０は、例えば、
周辺構成要素相互接続（ＰＣＩ）バス標準またはユニバーサルシリアルバス（ＵＳＢ）標
準の変形等、多様な種類の周辺バスを通じて付設されたデバイスに対するサポートを含む
ことができる。いくつかの実施形態において、Ｉ／Ｏインターフェース３０３０の機能は
、例えば、ノースブリッジ及びサウスブリッジ等、２つ以上の個別の構成要素に分割され
てもよい。また、いくつかの実施形態において、システムメモリ３０２０へのインターフ
ェースのようなＩ／Ｏインターフェース３０３０の機能のいくつかまたは全ては、プロセ
ッサ３０１０に直接組み込まれてもよい。
【０１２２】
ネットワークインターフェース３０４０は、コンピューティングデバイス３０００と、
例えば、図１に示される他のコンピュータシステムまたはデバイス等、ネットワーク（単
数または複数）３０５０に付設された他のデバイス３０６０との間でデータが交換される
ことを可能にするように構成されてもよい。多様な実施形態において、ネットワークイン
ターフェース３０４０は、例えば、イーサネット（登録商標）ネットワークの種類等、任
意の適切な有線または無線の汎用データネットワークを介して、通信をサポートすること
ができる。加えて、ネットワークインターフェース３０４０は、アナログ音声網またはデ
ジタルファイバー通信網等の電話通信／電話網を介して、ファイバーチャネルＳＡＮ等の
ストレージエリアネットワークを介して、あるいは任意の他の適切な種類のネットワーク
及び／またはプロトコルを介して、通信をサポートすることができる。
【０１２３】
いくつかの実施形態において、システムメモリ３０２０は、対応する方法及び装置の実
施形態を実装するための、上記のプログラム命令及びデータを記憶するように構成された
コンピュータ可読（すなわち、コンピュータがアクセス可能な）媒体の一実施形態であっ
てもよい。しかしながら、他の実施形態において、プログラム命令及び／またはデータは
、異なる種類のコンピュータ可読媒体上で受信、送信、または記憶されてもよい。一般に
、コンピュータ可読媒体は、Ｉ／Ｏインターフェース３０３０を介してコンピューティン
グデバイス３０００に連結される、例えば、ディスクまたはＤＶＤ／ＣＤ等の磁気または
光学式媒体のような非一時的記憶媒体またはメモリ媒体を含むことができる。非一時的コ
ンピュータ可読記憶媒体はまた、システムメモリ３０２０または別の種類のメモリとして
、コンピューティングデバイス３０００のいくつかの実施形態に含まれてもよい、ＲＡＭ
（例えば、ＳＤＲＡＭ、ＤＤＲ  ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の任
意の揮発性または不揮発性媒体も含むことができる。その上、コンピュータ可読媒体は、
伝送媒体、あるいはネットワークインターフェース３０４０を介して実装され得るように
、ネットワーク及び／または無線リンク等の通信媒体を介して伝達される、電子、電磁気
、またはデジタル信号等の信号を含むことができる。図１４に示されるような複数のコン
ピューティングデバイスの一部または全ては、多様な実施形態において説明された機能を
実装するために使用されてもよく、例えば、多種多様な異なるデバイス及びサーバー上で
稼動するソフトウェア構成要素が、機能性を提供するために連携することができる。いく
つかの実施形態において、説明された機能の一部は、汎用目的コンピュータシステムを使
用して実装されることに加えて、またはこの代わりに、記憶装置、ネットワークデバイス
、または特殊目的コンピュータシステムを使用して実装されてもよい。本明細書に使用さ
れるように、「コンピューティングデバイス」という用語は、少なくとも全てのこれらの
種類のデバイスを参照し、これらの種類のデバイスに制限されない。
【０１２４】
多様な実施形態は、コンピュータ可読媒体上に、前述の説明に従い実装された命令及び
／またはデータを受信、送信、または記憶することをさらに含むことができる。一般に、
コンピュータ可読媒体は、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ等の磁気または光学式媒
体、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の揮発
性または不揮発性媒体を含むことができる。いくつかの実施形態において、コンピュータ
可読媒体は、伝送媒体、あるいはネットワーク及び／または無線リンク等通信媒体を介し
て伝達される電子、電磁気、またはデジタル信号等の信号も含むことができる。
【０１２５】
本明細書の図面及び説明に例示される多様な方法は、方法の例示的実施形態を表す。方
法は、ソフトウェア、ハードウェア、またはこれらの組み合わせにおいて実装されてもよ
い。多様な方法において、ステップの順序が変更されてもよく、多様な要素が、追加され
ても、順番を変更されても、組み合わされても、省かれても、変形等されてもよい。多様
なステップは、自動的に（例えば、ユーザー入力によって直接問い合わされることなく）
、及び／またはプログラム的に（例えば、プログラム命令に従って）実行されてもよい。
【０１２６】
本開示の利点を有する当業者には明らかであるように、多様な変形及び変更が行われて
もよい。全てのこのような変形及び変更を包含することが意図され、したがって、上記の
説明は、制限の意味ではなく、例示として認識されたい。
【図１】
2018163697.tif 000003
【図２ａ】
2018163697.tif 000004
【図２ｂ】
2018163697.tif 000005
【図３】
2018163697.tif 000006
【図４】
2018163697.tif 000007
【図５】
2018163697.tif 000008
【図６】
2018163697.tif 000009
【図７】
2018163697.tif 000010
【図８】
2018163697.tif 000011
【図９】
2018163697.tif 000012
【図１０】
2018163697.tif 000013
【図１１】
2018163697.tif 000014
【図１２】
2018163697.tif 000015
【図１３】
2018163697.tif 000016
【図１４】
2018163697.tif 000017
【外国語明細書】
2018163697000001.pdf