(57)【特許請求の範囲】
【請求項１】
（ａ）未完了のジョブを同定する情報をスケジューラから要件エンジンに入力する工程と、
（ｂ）新しいジョブと関連したメタデータを上記要件エンジンに入力する工程と、
（ｃ）上記新しいジョブを完了するために、上記要件エンジンへの入力に対応する仮想マシンおよび仮想マシンセットの少なくとも一方をプロビジョニングする工程と、
を備えた方法。
【請求項２】
利用可能な仮想マシン構成のリストを格納する工程をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
上記メタデータが、仮想マシン構成に関する、上記新しいジョブのためのランク式を含むことを特徴とする請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、公的、私的、および公私のハイブリッド環境における仮想演算インフラストラクチャ（virtualized compute infrastructure）に関し、その環境内で実行しようとするジョブの特徴に基づいて、上記仮想演算インフラストラクチャを自動的かつリアルタイムに最適化する方法およびシステムに関する。
【背景技術】
【０００２】
クラウドベースのリソースは、典型的には仮想演算環境である。この仮想演算環境では、各物理マシン（physical machine）の全リソースのサブセットを利用して、一連の物理サーバ（physical severs）がプロビジョニングされ（provisioned;準備、供給、配置）
、一時的に使用可能な１つまたは複数の仮想サーバとなる。１つまたは複数のinfrastructure-as-a-service（IaaS）プロバイダを用いる場合、ユーザは、典型的には、仮想イン
フラストラクチャの所望の構成を制御することができる。この制御の例としては、所定の構成のリストから仮想ハードウェアを選択すること、あるいは所望の仮想ハードウェア構成に必要とされるリソースを厳密に特定することが含まれよう。クラウドベースの演算インフラストラクチャは、典型的には、異なるタイプの仮想マシンによって提供されるリソースに基づいて、異なる価格設定ポイントを有する。提供されるリソースが多ければ多いほど、単位時間当たりのコストが高くなる。
【０００３】
伝統的な演算環境は、典型的には、購入時の限られたハードウェア構成に基づいているため、サイズが固定されており、異種性（heterogeneity）が限定されている。その結果
、マシンは、プラットホームとの互換性の欠如、ディスクの空き容量、メモリ、またはネットワーク相互接続等の限定要因のために、ジョブの要求する作業を行うことが出来ることもあり、出来ないこともある。逆に、単一のマシンで実行されているジョブがマシンを十分に活用しておらず、リソースが無駄になっている可能性もある。
【０００４】
アプリケーションのための現行の自動スケーリング演算リソース（auto-scaling compute resources）は、米国特許第８，３４６，９２１号に示されるように、ＲＡＭ、ＣＰＵ数、またはインスタンスタイプ等に関する単一の仮想マシン構成の使用履歴に基づく、予測型の自動スケーリングに焦点を当てている。一方、演算環境に多数のアプリケーションがサブミットされ（submited；提出、委託、送信）、各アプリケーションがそれぞれに最適なＶＭ（仮想マシン）構成または複数のＶＭ構成を要求するような状況は無視されている。
【０００５】
CycleCloud等の、これと似た現行のクラウドベースのソリューションは、キューイングシステム、メッセージングシステム、またはCondorまたはGridEngine等のバッチスケジューリングシステムにおけるアイドルジョブ（idel jobs；実行されていないジョブ）の数
に基づいて、仮想ハードウェアをプロビジョニングする。これらのソリューションは、ジョブの実行に用いられる実行ノードの仮想構成を予め決めておくことを要求し、それから、キュー（queue;待ち行列）、メッセージバスまたはスケジューラにおけるアイドルジョブを実行するために、この１つの構成に適合する仮想マシンを自動的にプロビジョニングする。その結果、ワークフロー内のあらゆるジョブを実行することの出来る仮想マシン構成、すなわち全ジョブのための最小公倍数的なマシン構成を定義する必要が、しばしば生じる（たとえ、この構成が大多数のジョブが必要とするよりも過剰なリソースを含んでいたとしても）。
【０００６】
現代の仮想演算環境の、異なるハードウェア構成をリアルタイムに特定する能力を活用して、ジョブのキュー（待ち行列）における各ジョブの特定のニーズと特徴に基づいて、インフラストラクチャの自動プロビジョニングが出来るようにすることが望ましい。キューに投入されたジョブからメタデータを用いて作成される仮想インスタンスのタイプを最適化することにより、より速く、より低コストで、より少ないエラーでジョブを完了することが可能になる。本発明はそのような方法とシステムを記述する。
【発明の概要】
【０００７】
本システムは、演算インフラストラクチャをジョブ実行要件に基づいてリアルタイムに自動的に最適化する方法について、情報に基づいた判断をするための要件エンジン（requirements engine）を提供する。この要件エンジンに加えて、本システムはジョブメタデ
ータの格納メカニズムを提供する。この格納メカニズムは、ジョブが利用すると考えられる種々のソフトウエアアプリケーションのランタイム要件、または、サブミッション時に分かっている場合はキューの中の特定のジョブの特徴（characteristics）、を取り込む
。本システムによって格納されたメタデータは、ジョブを適切に実行するために必要とする環境を記述した論理式を含む。これは、１つまたは複数の仮想サーバの測定可能ないかなる特性を含んでいてもよく、例えば以下のメトリックのいずれでもよいが、これに限定されない。
【０００８】
ＣＰＵのパフォーマンスの総計(aggregate)
【０００９】
利用可能なＣＰＵの数
【００１０】
利用可能な最大メモリ
【００１１】
利用可能な最大ディスク空き容量
【００１２】
ディスクのパフォーマンスの総計
【００１３】
ネットワーク帯域幅の総計
【００１４】
ベースオペレーティングシステム
【００１５】
追加的に要求されるソフトウエア構成
【００１６】
IaaSプロビジョニングされたハードウェアの１時間当たりの最大コスト
【００１７】
物理ハードウェアの地理的ロケーション
【００１８】
ジョブが投入されたスケジューリングシステムのキュー
【００１９】
物理ハードウェアの管轄権（法的管轄圏；jurisdiction）（例えば、米国愛国者法で管理されているサーバでは実行出来ない）、および
【００２０】
使用する可能性のある１つまたは複数のIaaSプロバイダの名前
【００２１】
上記プロパティの一部を用いて、４つ以上のＣＰＵと２ギガバイト以上のＲＡＭを要求するジョブを記述した論理式の例は、以下のようになろう。
CPUCount>4&&Memory>2G
【００２２】
上記プロパティの一部を用いて、複数のマシン（１つのマシンは４つ以上のＣＰＵと２ギガバイト以上のＲＡＭを有し、もう１つのマシンは８つのＣＰＵと８ギガバイトのＲＡＭを有する）を要求するジョブを記述した一組の論理式の例は、以下のようになろう。
[“CPUCount>4&&Memory>2G”,“CPUCount>8&&Memory>8G”]
【００２３】
論理式はまた、ジョブを実行するのに要求される仮想マシン構成のタイプ“m1.small”等）であってもよく、またはジョブを実行するのに要求される一組のノード[“m1.small
”, “cl.xlarge”, “m1.xlarge”]であってもよい。
【００２４】
要件エンジンは、キューにおける各ジョブのためのメタデータをリアルタイムに処理し、メタデータで特定された要件に基づいて、そのジョブを実行するのに最適な仮想マシン構成を決定する。オプションで、このプロセスは、ジョブが入っているキューの名前から、それらのジョブのために作成された１つまたは複数の仮想マシンの構成のタイプへの、ダイレクトマッピングであってもよい。さらにジョブがキューに追加されると、本システムは各アイドルジョブと関連したメタデータを処理し続け、追加の仮想マシン（ジョブあたり１つのマシンまたはリソース、またはジョブあたり複数のリソース）をプロビジョニングする。各リソースは各ジョブ固有のランタイム要件に合わせて最適化される。  
【００２５】
キューまたはスケジューリングシステム内のアイドルジョブに基づいてノードを開始および停止させることに加えて、要件エンジンは、どの仮想インスタンスがすでにプロビジョニングされ、開始されたかに基づいて、新しいプロビジョニングの決定をする。そして、現在のインスタンスのワークの未処理分（バックログ；backlog）が何らかのユーザ定
義の閾値を超えた時のみ、追加のインスタンスを開始させる。メタデータに基づいてジョブのハードウェア要件を決定する際、本システムは、前にプロビジョニングされたハードウェアであって、最初に委託された何らかのジョブを完了または完了間近なハードウエアを検査し、このハードウェアが現在アイドル状態にあるジョブを実行するのに適しているか否かを判断する。このハードウェアを再び利用することが出来る場合、本システムは、新しい仮想マシンのプロビジョニングは行わず、代わりに、このジョブがアイドル状態にあるかアイドル状態間近なノードに割り当てられることを許容する。
【００２６】
さらに、要件エンジンは、ユーザからの要求があれば、前にジョブを実行するようプロビジョニングされ、そのジョブがもう完了してマシンのプールの中で使用されない状態でいる、あらゆる仮想マシンを終了させることが出来る。ほとんどのIaaS環境において、レンタルされた仮想マシンは、特定の時間間隔で、典型的にはマシンがプロビジョニングされた時から１時間毎に課金される。本願で提案するシステムは、開始させた各インスタンスについて、この課金間隔を追跡し、アイドル状態にある仮想マシンを次の課金期間の前に必ず終了させることが出来る。もはやジョブを実行しておらず、キュー内にジョブがない時に仮想マシンを終了させることにより、IaaSクラウド環境における全体のコストが低減され、演算環境のライフスパンにわたってクラスタトポグラフィが最小限に保たれる。
【００２７】
ジョブを実行するのに要求されるハードウェアを決定するために、要件エンジンが提供するアルゴリズムは、ジョブの実行ための最低要件(minimum requirements）のみならず
、そのジョブの実行には要求されない優先メトリック（preferential metrics）も含むように拡張することが出来る。その結果、利用可能な仮想マシン構成に対する動的ランク付けシステムが出来る。例えば、ジョブを記述するメタデータが、そのジョブを実行するのに２ギガバイトのメモリしか要求しないが、利用可能であればより大きなメモリを好むシステムを記述するとする。そして、２ギガバイトのＲＡＭの仮想マシンと４ギガバイトのＲＡＭの仮想マシンとの選択を与えられた場合、どちらのマシンをプロビジョニングするかを決めるに当たっては、ＲＡＭの容量がより大きい仮想マシンをより高位にランク付けすべきである。
【図面の簡単な説明】
【００２８】
【図１】ジョブとそれに伴うメタデータのサブミッションの両プロセスを、要件エンジンと共に示すブロック図である。上記サブミッションは、エンドユーザまたはジョブサブミッションポータル、コマンドラインツール、ＡＰＩまたはウェブページ／サービス（CycleServer、shell commands、RESTfulAPI等であるが、それらに限定されない。）による。上記要求エンジンは、１つまたは複数のIaaSプロバイダから、適合する仮想マシン構成を決定する。
【００２９】
【図２】どの利用可能な仮想ハードウェアをプロビジョニングするかを決定するアルゴリズムを作動させることの出来る、要件エンジンと変数を示すブロック図である。
【００３０】
【図３】アイドルジョブとそのジョブに関連したメタデータを、前にプロビジョニングされた、ジョブ完了または完了間近の仮想マシンセットとマッチングさせる工程を示すブロック図である。
【００３１】
【図４】アイドルジョブを、そのジョブに関連したメタデータを用いて、仮想マシンとマッチングさせる工程を示すブロック図である。このマッチングは、最低要件式(minimum requirements expression)と、複数のマシン構成が要件に適合した時の選択に用いられるランク式(ranking expression)との両者に基づいて行われる。
【発明の詳細な説明】
【００３２】
本発明に係るプロセスおよびシステムの好ましい実施形態を以下に述べる。ただし、本発明はこの実施形態に限定されるものではない。
【００３３】
ジョブを実行するために要求される仮想のマシン構成またはインスタンス／ノードタイプは、マシンの単一のプロセッサ、複数のプロセッサ、または様々なタイプの複数の仮想マシンであってよいことが理解される。
【００３４】
この好ましい実施形態において、要件エンジンは、スケジューラまたはメッセージングミドルウェアにおける個々のジョブキューまたは複数のジョブキューを見て、それらのキューにおけるタスクまたはジョブのために要求されるインフラストラクチャを演算し、様々な構成の仮想マシンの現行の数、予期される数および理想的な数の間の相違に基づいて、要求される新しいインフラストラクチャを開始させる。ここで、スケジューラまたはメッセージングミドルウェアは、例えば、Condor、GridEngine、Platform LSF、Platform Symphony、AMQPqueue、MQseries、AWS SQS等を含むが、これらに限定されない。
【００３５】
図１を参照すると、このブロック図は、エンドユーザまたはCycleServer等のジョブサ
ブミッションポータルによる、ジョブとそれに伴うメタデータの両方のサブミッションプロセスを、要件エンジンと共に示すものである。この要件エンジンは、１つまたは複数のIaaSプロバイダから、適合する仮想マシン構成を決定する。
【００３６】
このシステムのプロセスおよび構成要素は次の通りである。
【００３７】
・エンドユーザまたはサブミッションポータル、コマンドライン、ＡＰＩまたはウェブページ／サービス（Ａ１）がジョブを生成してキュー／バッチスケジューラ（Ａ２）にサブミットし、それに加えて、そのジョブの論理要件を記述したメタデータを生成してメタデータ格納システム（Ａ３）に格納する。  
【００３８】
・これにより要件エンジン（Ａ４）を作動させ、要件エンジンは、キュー／スケジューリングシステム（Ａ２）におけるアイドルジョブおよび適合するメタデータ（Ａ３）を見つける。
【００３９】
・要件エンジンは、１つまたは複数のIaaSプロバイダ（Ａ５）とやり取りして、利用可能な仮想マシン構成（Ａ５）を決定する。
【００４０】
・要件エンジン（Ａ４）は、上記のリスト（Ａ５）から、メタデータ（Ａ３）に定義された全ての論理要件に適合する仮想構成を選択し、新しい仮想マシン（Ａ６）をプロビジョニングする。この新しい仮想マシン上でジョブ（Ａ２）が実行される。
【００４１】
図２は、利用可能な仮想ハードウェアの中からどれをプロビジョニングするかを決定するアルゴリズムを作動させることの出来る、要件エンジンと変数を示すブロック図である。
【００４２】
このシステムのプロセスおよび構成要素は次の通りである。
【００４３】
・ジョブキュー／バッチスケジューラ（Ｂ１）は、まだ完了していないジョブを含む。一方、メタデータ格納部（Ｂ２）はキューにおける各ジョブのマッチング要件を含む。  
【００４４】
・要件エンジン（Ｂ３）は、１つまたは複数のIaaSプロバイダ（Ｂ４ａ＆Ｂ４ｂ）によりプロビジョニングできる利用可能な仮想マシンの各々のメトリックを格納する。
【００４５】
・要件エンジンのアルゴリズムは、ジョブメタデータ（Ｂ２）における要件に適合する仮想マシン構成（Ｂ５）を決定し、ジョブを実行するために、適切なIaaSプロバイダの適合する構成をプロビジョニングする。
【００４６】
図３は、アイドルジョブとそのジョブに関連したメタデータを、以前にプロビジョニングされジョブ完了または完了間近の仮想マシンのセットとマッチングさせる工程を示すブロック図である。
【００４７】
このシステムのプロセスおよび構成要素は次の通りである。
【００４８】
・ジョブキュー／バッチスケジューラ（Ｃ１）は、まだ完了していないジョブを含み、メタデータ格納部（Ｃ２）は、各アイドルジョブのマッチング要件を含む。
【００４９】
・これら情報は要件エンジン（Ｃ３）に供給され、要件エンジンは、１つまたは複数のIaaSプロバイダ（Ｃ５）からの利用可能なマシン構成のリストと、現在プロビジョニングされている全仮想マシン（Ｃ６）の構成の両方を処理する。
【００５０】
既にプロビジョニングされアイドルになっているか又はアイドルになろうとしているインスタンス（Ｃ３ｂ／Ｃ４ｃ）で、キュー（Ｃ１）内のジョブが実行可能である場合には、新しい仮想マシンはプロビジョニングされず、ジョブメタデータで特定された要件に適合する既にプロビジョニングされたハードウェアで、ジョブの実行が許可される。
【００５１】
図４は、アイドルジョブを、それに関連したメタデータを用いて、仮想マシンとマッチングさせる工程を示すブロック図である。このマッチングは、最低要件式（minimum requirements expression）と、複数のマシン構成が要件に適合した時の選択のために用いら
れるランク式との両者に基づいて行われる。
【００５２】
このシステムのプロセスおよび構成要素は次の通りである。
【００５３】
・ジョブキュー／バッチスケジューラはまだ完了していないジョブ（Ｄ１）を含み、メタデータ格納部はアイドルジョブのマシン要件（Ｄ２）を含む。
【００５４】
・上記情報は、要件エンジン（Ｄ３）に供給され、この要件エンジンは、１つまたは複数のIaaSプロバイダからの利用可能なマシン構成のリスト（Ｄ４）を格納する。
【００５５】
・要件エンジン（Ｄ３）は、メタデータ（Ｄ２）を用いて、上記ジョブ（Ｄ１）に適合する構成（Ｄ４ｂ＆Ｄ４ｃ）を見つける。
【００５６】
・要件エンジン（Ｄ３）は、メタデータで定義されたランク式に従って、上記適合する構成（Ｄ４ｂ＆Ｄ４ｃ）のそれぞれをランク付けする。
【００５７】
・ジョブメタデータ（Ｄ２）による最高ランクの適合構成（Ｄ４ｃ）に基づいて、マシンがプロビジョニングされる（Ｄ５）。
【００５８】
仮想演算クラウド環境を利用するあらゆる当事者のために、キュー環境またはスケジューリング環境におけるジョブのランタイム構成（実行時構成；runtime configuration)に基づいて、演算クラスタのトポグラフィーをリアルタイムに動的に最適化するシステムおよび方法を提供する。ランタイム構成はメタデータとして定められる。上記当事者とは、このようなクラウド環境を提供するプロバイダを含む。
本システムは、現在のキューにおけるジョブの全てのアプリケーションのプロファイルに基づいて、関連するメタデータ内の要件およびランク式として定義されたランタイム構成の集合（aggregate runtime configuration）に基づいて、クラウド中の複数タイプの
仮想リソースをプロビジョニングしたり終了させる。
ジョブがキューを出入りすると、本システムは、継続的に演算リソースを要求し終了させ、クラスタを、キュー内の全てのジョブを完了させるために最適化しつつ、最小限に維持する。コスト、ランタイムその他のメトリックを最適化する。
本システムは、エンドユーザに、ジョブのランタイム要件を特定する方法を提供するが、この方法では、エンドユーザは、ジョブを実行するシステムに対してジョブを具体的に設計するために、演算クラスタの物理プロファイルについて知る必要がない。
【００５９】
好ましい実施例を参照して本発明を具体的に記載してきたが、本発明の精神および範囲を逸脱することなく、形態および詳細を種々変更してもよいことは、当業者に理解されよう。
【図１】
0006373432.tif 000002
【図２】
0006373432.tif 000003
【図３】
0006373432.tif 000004
【図４】
0006373432.tif 000005