以下,本実施の形態について,図を用いて説明する。
図1は,オンプレミスで実現されるシステムの課題を説明する図である。
図1に示す例において,タスクを示す図形の縦の長さは該タスクのリソース消費量を示し,横の長さは該タスクの処理時間を示す。また,図1に示す例において,グラフの縦軸はシステムのリソース消費量を示し,横軸は時間の経過を示す。t0 〜t3 は,等間隔の時刻を示す。
オンプレミスのシステムでは,システムが持つリソースの量は固定となる。すなわち,あらかじめシステムが持つリソース量を超えたリソース消費量の処理を行うことはできない。図1に示す例において,システムリソースのラインは,システムが持つリソースの量を示す。
例えば,図1(A)において,システムに対して,タスク#1〜タスク#4の処理要求が,ほぼ同時刻t0 にあったものとする。このとき,システムは,処理要求を受け付けた順,ここではタスク#1,タスク#2,タスク#3,タスク#4の順に処理を開始する。しかし,図1(A)に示すように,タスク#3の処理を開始したところで,システムのリソース消費量がシステムが持つリソース量に達してタスク#4の処理を開始できない状態となり,タスク#4の処理要求を受け付けられなくなる。
図1(B)に示す例は,スケジューリングを行うシステムの例である。スケジューリングを行うシステムでは,処理要求を受け付けた時点でタスクの処理時間を見積もり,処理要求が発生した時点でリソースに空きがなくても,実行中の他のタスクの終了後に受け付けた処理要求のタスクを実行するように,タスクのスケジューリングを行う。
例えば,最後に受け付けるタスク#4の処理の納期が,時刻t3 であるものとする。図1(B)に示すように,最も処理終了時刻が早いタスク#3の処理終了時刻がt1 であるので,タスク#4をタスク#3の後にスケジュールすれば,タスク#4の処理終了時刻はt3 となり,納期に間に合う。この場合,タスク#4の処理要求は,システムで受け付け可能となる。
ところが,図1(C)に示す例では,最も処理終了時刻が早いタスク#2の後にタスク#4をスケジュールすると,タスク#4の処理終了時刻はt3 を超えてしまい,納期に間に合わない。この場合,タスク#4の処理要求は,システムで受け付けられない。オンプレミスのシステムでは,スケジューリングを行っても,処理要求を受け付けできない場合がある。
このようなオンプレミスの技術の対極に存在するのが,クラウドコンピューティングの技術である。クラウドコンピューティングによって実現されるシステムのリソース量は,可変となる。
クラウドコンピューティングでは,システムが備える各コンピュータノードが,例えば仮想マシン(VM:Virtual Machine )で実現される。なお,以下では,システムが備えるコンピュータノードを,単にノードとも呼ぶ。
クラウドコンピューティングにおいて,システムのリソース量を変更する技術として,例えば,スケールアップ・スケールダウンの技術がある。スケールアップは,ノードのリソース量を増加させる技術である。また,スケールダウンは,ノードのリソース量を減少させる技術である。スケールアップの技術を利用すれば,例えば,現状のリソースでは新たな処理要求のタスクを実行しても納期に間に合わないような場合でも,ノードのリソース量を増加させることで,新たな処理要求のタスクを納期に間に合うように実行できるようになる。
しかし,スケールアップ可能なリソースは,仮想マシンであるノードを実現する物理マシンのリソースが上限となるため,ノードのスケールアップには限界がある。また,通常は1つの物理マシン上に複数の仮想マシンのノードが配置されており,物理マシンのリソースを各ノードに配分しきって余剰がない場合には,他のノードの性能を下げることなく特定のノードの性能を上げることは不可能となる。例えば,マルチテナントの環境では,1つの物理マシン上で複数のテナントの仮想マシンを動作することになり,あるテナントの仮想マシンのリソース量を増やすために,他のテナントのリソース量を減らすといったことは,簡単にはできない。よって,スケールアップの技術を用いても,要求された処理のタスクをすべて納期を保証して実行できるわけではない。
クラウドコンピューティングにおいて,システムのリソース量を変更する技術として,スケールアップ・スケールダウンの技術以外に,スケールアウト・スケールシュリンクの技術がある。スケールアウトは,システムにノードを増設する技術である。スケールシュリンクは,システムからノードを撤去する技術である。スケールアウトの技術を用いれば,ほぼ確実に要求された処理のタスクをすべて納期を保証して実行できるようになる。
ただし,クラウドコンピューティングの世界では,通常はサービス使用料金が従量制となっており,スケールアウトによってシステムが備えるノードの数が増加するにつれて,サービスの使用料金が増えてしまう。
図2は,クラウドコンピューティングで実現されるシステムの課題を説明する図である。
図2に示す例において,タスクを示す図形の縦の長さは該タスクのリソース消費量を示し,横の長さは該タスクの処理時間を示す。また,図2に示す例において,グラフの縦軸はシステムを構成するノードのリソース消費量の合計を示し,横軸は時間の経過を示す。t0 〜t3 は,等間隔の時刻を示す。図2に示す例において,システムリソースのラインは,システムを構成するノードが持つリソースの量の合計を示す。
図2(A)において,システムは,当初,VM#1〜VM#3の3つのノードを備えているものとする。ここで,システムに対して,タスク#1〜タスク#4の処理要求が,ほぼ同時刻t0 にあったものとする。このとき,システムでは,処理要求を受け付けた順,ここではタスク#1,タスク#2,タスク#3,タスク#4の順に,ノードにタスクが割り当てられ,処理が開始される。しかし,図2(A)に示すように,VM#3のノードにタスク#3の処理を割り当てたところで,システムのすべてのノードのリソース消費量が上限となり,タスク#4の処理を割り当て可能なノードがなくなる。
このとき,例えば図2(A)に示すように,システムではスケールアウトが行われ,VM#4のノードがシステムに増設される。図2(A)に示すように,スケールアウトによってVM#4のノードがシステムに増設されることで,要求されたタスク#4の処理が実行可能となる。例えば,クラウドコンピューティングにおいて,仮想マシンやネットワークなどのインフラをサービスとして提供するIaaS(Infrastructure as a Service )ベンダのサービスとして,システムのリソース消費率が所定以上となったときに自動でスケールアウトを行うサービスがある。クラウドコンピューティングにおいて,自動でシステムの拡張/縮小を行う技術は,オートスケーリングとも呼ばれる。
ここで,タスク#4の処理の納期が時刻t3 であるものとする。図2(A)に示すように,最も処理終了時刻が早いタスク#3の処理終了時刻がt1 であるので,タスク#4をタスク#3の後にスケジュールすれば,タスク#4の処理終了時刻はt3 となり,納期に間に合う。
このように,タスクのスケジューリングを行うことができれば,スケールアウトによりVM#4のノードを増設しなくても,納期に間に合うようにタスク#4の処理を実行することが可能であった。しかし,このような判断は,上述のIaaSのサービスのようにリソース消費を見ただけではできない。上述したように,クラウドコンピューティングでは,ノードが増えるごとに使用料金が増えるため,ノードを増設しなくても納期に間に合うようにタスクの処理を実行できるのであれば,ノードを増設したくないという要望がある。
また,無駄なノードの使用料金を抑えるために,システムで運用されていないと判断されるノードに対するスケールシュリンクが行われ,該ノードがシステムから撤去される。例えば,クラウドコンピューティングにおいて,IaaSベンダのサービスとして,ノードのCPU(Central Processing Unit )使用率が所定以下となったときに,該ノードではタスクの処理が行われておらずOSなどのミドルウェアしか動作していないと判断し,自動でスケールシュリンクを行うサービスがある。
だだし,ノードのリソース消費量が少ないからといって,必ずしも要求されたタスクの処理が行われていないとは限らない。たとえば,図2(B)に示す例において,VM#3のノードでは,タスク#3の処理が終了すると,リソース消費量が極端に減ってしまう。しかし,図2(B)に示す例において,VM#3のノードでは,タスク#3と並列にリソース消費量が少ないタスク#4が実行されている。タスク#3の処理の終了と同時にVM#3のノードに対するスケールシュリンクが行われると,タスク#4の処理が強制終了されてしまう。このように,上述のIaaSベンダのサービスのようにリソース消費を見ただけでスケールシュリンクを判断すると,例えば,図2(B)に示すタスク#4のようにリソース消費量が少ないタスクの処理を実行中であるノードを,誤って撤去してしまう可能性がある。
以下では,このような問題の解決を図った本実施の形態によるオートスケーリングの技術を説明する。
図3は,本実施の形態によるシステムの構成例を示す図である。
本実施の形態において,図3に示すシステム100は,クラウドコンピューティングにおいて,IaaS側から提供される仮想マシンのノードから構成されるコンピュータシステムであるものとする。システム100は,クライアント200から要求された処理を,複数のノードで分散して実行する。システム100とクライアント200とは,LAN(Local Area Network)やインターネットなどのネットワーク300で接続されている。システム100は,マスタノード110,スレーブノード120を備える。
マスタノード110は,クライアント200からの処理要求を受け付け,各スレーブノード120に対するタスクの割り当てや,システム100で実行するタスクの管理を行う。なお,本実施の形態によるマスタノード110は,スレーブノード120のスケールアウトやスケールシュリンクなどのオートスケーリングの処理を行う。なお,マスタノード110が,同時にスレーブノード120の1つであってもよい。
スレーブノード120は,マスタノード110から割り当てられた処理要求のタスクを実行するコンピュータノードである。スレーブノード120は,複数のタスクの並列処理が可能である。スレーブノード120は,オートスケーリングの処理によって,システム100に増設,またはシステム100から削除される。例えば,図3において,#aのスレーブノード120aと#bのスレーブノード120bがタスクの処理を実行している場合に,それらのスレーブノード120で実行しきれない処理要求があれば,#cのスレーブノード120cがシステム100に増設される。また,たとえば,#cのスレーブノード120cが実行するタスクがなくなれば,#cのスレーブノード120cがシステム100から削除される。
クライアント200は,システム100に対して,システム100が提供する処理の実行要求を行う上位アプリケーションを有するコンピュータである。なお,図1に示す例では,クライアント200がシステム100外部の装置となっているが,例えばクライアント200がシステム100内部のノードであってもよい。
図4は,本実施の形態による各ノードの機能構成例を示す図である。
マスタノード110は,クライアント通信部111,スケジュール処理部112,スケジュール情報記憶部113,スケールアウト処理部114,スレーブ通信部115,リスケジュール処理部116,スケールシュリンク処理部117を備える。
クライアント通信部111は,クライアント200からの処理要求を受け付ける。クライアント通信部111は,受け付けた要求の処理がシステム100内で実行可能なものであれば,スケジュール処理部112に渡す。クライアント通信部111は,受け付けた要求の処理がシステム100内で処理実行不可能なものであれば,その旨をクライアント200に応答する。システム100内で処理実行不可能な処理は,例えばスレーブノード120にないアプリケーションの処理や,1仮想マシンのスレーブノード120では納期までに終了できない大規模な処理などである。大規模な処理を,複数のノードで分散して実行する技術については,本実施の形態による技術の範囲外であるので,ここでは説明を行わない。クライアント通信部111は,スレーブノード120から受け取った処理結果をクライアント200に通知する。
スケジュール処理部112は,クライアント通信部111が納期が指定された処理要求を受け付けた際に,スケジュール情報記憶部113に記憶された管理情報を参照して,該処理要求のタスクをスレーブノード120に割り当てるシミュレーションを実行する。
スケジュール情報記憶部113は,システム100が備えるスレーブノード120が実行するタスクを管理する管理情報の記憶部である。スケジュール情報記憶部113に記憶された管理情報には,すべてのスレーブノード120で実行するタスクのスケジュールが記録されている。
より具体的には,スケジュール処理部112は,まず,現行の状態で,受け付けた処理要求のタスクを,指定された納期内に処理終了可能なスレーブノード120の検出を行う。ここでは,スケジュール処理部112は,即時に処理実行可能なスレーブノード120だけではなく,他のタスクの処理終了後に処理要求のタスクを実行しても,納期内に処理終了可能なスレーブノード120も検出する。スケジュール処理部112は,ここで検出されたスレーブノード120から,処理要求のタスクを割り当てるスレーブノード120を選択する。なお,ここでは,ロック中のスレーブノード120については,検出の対象外とする。本実施の形態において,ロックは,スレーブノード120を,処理要求のタスクの割り当て対象外に設定することをいう。
スケジュール処理部112は,現行の状態で処理要求のタスクを納期内に処理終了可能なスレーブノード120がなければ,他のスレーブノード120に移動しても納期内に処理終了可能なタスクを検出する。スケジュール処理部112は,検出されたタスクを移動することで,処理要求のタスクを納期内に処理終了可能なスレーブノード120を用意できるかを判定する。タスクを移動することで処理要求のタスクを納期内に処理終了可能なスレーブノード120を用意できると判定される場合,スケジュール処理部112は,該当タスクを他のスレーブノード120に移動する処理を,スレーブ通信部115を介して実行する。タスクの移動は,例えば該タスクの処理を移動元のスレーブノード120で停止し,移動先のスレーブノード120で再起動させる方法でもよいし,移動元のスレーブノード120における該タスクの実行中のイメージデータを移動先のスレーブノード120に転送する方法でもよい。本実施の形態では,該タスクの処理を移動先のスレーブノード120で再起動させる方法でタスクの移動を行うものとする。スケジュール処理部112は,タスクの移動により空きができたスレーブノード120を,処理要求のタスクを割り当てる対象のスレーブノード120に決定する。
スケジュール処理部112は,タスクを移動しても処理要求のタスクを納期内に処理終了可能なスレーブノード120を用意できない場合,ロック中のスレーブノード120があれば,そのロックを解除すれば,処理要求のタスクを納期内に処理終了可能であるかを判定する。ロック解除により,処理要求のタスクを納期内に処理終了可能となると判定される場合には,スケジュール処理部112は,ロック中のスレーブノード120のロックを解除する。スケジュール処理部112は,ロックを解除したスレーブノード120を,処理要求のタスクを割り当てる対象のスレーブノード120に決定する。
スケジュール処理部112は,ここまでの処理で,処理要求のタスクを割り当てる対象のスレーブノード120が見つけられなかった場合,スケールアウトにより,システム100にスレーブノード120を増設すると判断する。
スケールアウト処理部114は,スケールアウトによって,システム100にコンピュータノードを増設する処理を行う。より具体的には,スケールアウト処理部114は,IaaS側で用意しているインタフェースを用いて,IaaS側の管理コンピュータにアクセスし,自システム100へのスケールアウトを要求する。
スレーブ通信部115は,スレーブノード120との通信を行う。例えば,スレーブ通信部115は,受け付けた処理要求のタスクを割り当てる対象のスレーブノード120に対して,該タスクの処理を依頼する。また,スレーブ通信部115は,スレーブノード120から,依頼したタスクの処理結果を応答として受け付ける。また,スレーブ通信部115は,タスクの移動が行われる際に,移動元のスレーブノード120に対して該当タスクの停止を通知し,移動先のスレーブノード120に対して該当タスクの実行を通知する。
リスケジュール処理部116は,例えば定期的に,スケジュール情報記憶部113に記憶された管理情報を参照し,実行するタスクがないスレーブノード120を,スケールシュリンクの対象とする。
また,リスケジュール処理部116は,スケジュール情報記憶部113に記憶された管理情報を参照して,あるスレーブノード120で動作するタスクを,他のスレーブノード120に移動するシミュレーションを実行する。リスケジュール処理部116は,他のスレーブノード120に移動しても納期内に処理終了可能なタスクを検出する。
リスケジュール処理部116は,検出されたタスクを移動することで,実行するタスクがないスレーブノード120を用意できるかを判定する。タスクを移動することで実行するタスクがないスレーブノード120を用意できると判定される場合,リスケジュール処理部116は,該当タスクを他のスレーブノード120に移動する処理を,スレーブ通信部115を介して実行する。タスクの移動については,上述のスケジュール処理部112の場合と同様である。リスケジュール処理部116は,タスクの移動により実行するタスクがなくなったスレーブノード120を,スケールシュリンクの対象とする。
また,リスケジュール処理部116は,検出されたタスクを移動することで,実行するタスクの数が所定数以下となるスレーブノード120を用意できるかを判定する。タスクの移動により実行するタスクの数が所定数以下となるスレーブノード120を用意できると判定される場合,リスケジュール処理部116は,該当タスクを他のスレーブノード120に移動する処理を,スレーブ通信部115を介して実行する。リスケジュール処理部116は,タスクの移動により実行するタスクの数が所定数以下となるスレーブノード120にロックを設定する。ロック中のスレーブノード120には,原則として新たな処理要求のタスクが割り当てられないので,残ったタスクの処理が終了した後で,スケールシュリンクの対象となる。
スケールシュリンク処理部117は,スケールシュリンクによって,対象のスレーブノード120をシステム100から削除する処理を行う。より具体的には,スケールシュリンク処理部117は,IaaS側で用意しているインタフェースを用いて,IaaS側の管理コンピュータにアクセスし,対象スレーブノード120のスケールシュリンクを要求する。
スレーブノード120は,マスタ通信部121,アプリケーション122を備える。図4に示すように,スレーブノード120では,複数種類のアプリケーション122a,b,... を稼働することが可能である。処理要求のタスクが割り当てられた際には,該処理要求に対応するアプリケーション122によって,タスクの処理が実行される。
マスタ通信部121は,マスタノード110との通信を行う。例えば,マスタ通信部121は,マスタノード110からタスクの実行要求や停止要求を受け付け,タスクの実行開始または実行停止の処理を行う。また,タスクの処理が終了した場合には,マスタ通信部121は,マスタノード110に処理結果の応答を返す。
図5は,本実施の形態によるノードを実現する仮想マシンシステムの例を示す図である。
図5に示す仮想マシンシステムは,例えば,1台の物理マシン上で1または複数台の仮想マシンが動作するシステムである。図5に示す仮想マシンシステムの例では,CPU11やメモリ12などの,物理マシンであるコンピュータ10の資源を利用して,マスタノード110やスレーブノード120を含む複数の仮想マシン30が動作している。なお,図5に示す仮想マシンシステムでは,マスタノード110とスレーブノード120とが同じ物理マシンで実現されているが,クラウドコンピューティングの環境では,マスタノード110や,各スレーブノード120が,それぞれ異なる物理マシンで実現されることも多い。
図5に示す仮想マシンシステムにおいて,ハイパーバイザ20は,コンピュータ10を利用した仮想化環境を実現するソフトウェアである。マスタノード110やスレーブノード120を含む仮想マシン30は,ハイパーバイザ20上に構築可能である。
図4に示すマスタノード110,スレーブノード120を仮想マシンで実現するコンピュータ10は,例えば,CPU11,主記憶となるメモリ12,記憶装置13,通信装置14,媒体読取・書込装置15,入力装置16,出力装置17等のハードウェアを備える。記憶装置13は,例えばHDD(Hard Disk Drive )等の外部記憶装置や,補助記憶装置などである。媒体読取・書込装置15は,例えばCD−R(Compact Disc Recordable )ドライブやDVD−R(Digital Versatile Disc Recordable )ドライブなどである。入力装置16は,例えばキーボード・マウスなどである。出力装置17は,例えばディスプレイ等の表示装置などである。なお,コンピュータ10のハードウェア構成は,必要に応じて任意の設計が可能である。
図4に示すマスタノード110,スレーブノード120および各ノードが備える機能部は,コンピュータ10が備えるCPU11,メモリ12等のハードウェアと,ソフトウェアプログラムとによって実現することが可能である。コンピュータ10が実行可能なプログラムは,例えば,記憶装置13に記憶され,その実行時にメモリ12に読み出され,CPU11により実行される。
コンピュータ10は,可搬型記録媒体から直接プログラムを読み取り,そのプログラムに従った処理を実行することもできる。また,コンピュータ10は,サーバコンピュータからプログラムが転送されるごとに,逐次,受け取ったプログラムに従った処理を実行することもできる。さらに,このプログラムは,コンピュータで読み取り可能な記録媒体に記録しておくことができる。
以下,本実施の形態によるマスタノード110による処理について,より具体的な例を用いて説明する。
図6〜図9は,本実施の形態のマスタノードにおけるスケジュール処理部による処理要求のタスクの割り当てシミュレーションの例を説明する図である。
図6(A)は,タスクの表記の例を示す。図6(A)において,塗り潰しされた図形が,タスクの処理を表す。タスクの処理を示す図形の縦の長さは該タスクのリソース消費量を示し,横の長さは該タスクの処理時間を示す。また,図6(A)において,白抜き図形の右端は,該タスクの納期を示す。納期は,クライアント200に指定されたタスクの処理を終了する期限である。以下の説明において,タスクについてはすべて図6(A)に示す通りの表記が行われる。
図6(B)は,クライアント200から時刻t0 に処理要求を受け付けた時点における,システム100が備える各スレーブノード120a,bが実行するタスクのスケジュールを示す。図6(B)に示すように,この時点でシステム100が備えるスレーブノード120は,#aのスレーブノード120aと#bのスレーブノード120bの2つである。なお,スケジュール情報記憶部113には,例えば図6(B)のグラフに示すようなシステム100が備えるスレーブノード120が実行するタスクのスケジュールをデータ化した管理情報が記憶されている。図6(B)において,グラフの縦軸はスレーブノードのリソース消費量を示し,横軸は時間の経過を示す。t-1〜t3 は,等間隔の時刻を示す。
図6(C)は,時刻t0 の時点でクライアント200から受け付けた処理要求のタスクXを示す図形である。図6(C)に示すように,処理要求のタスクXの処理については,他のタスクと区別がつくように,ハッチングで表されている。図6(C)に示すように,処理要求のタスクXについては,時刻t3 の納期が指定されている。
なお,タスクの処理時間やリソース消費量の推定については,過去の実績から求める方法や理論的に求める方法などで多数の周知技術が存在するので,ここでは詳細な説明を省略する。タスクの処理時間の推定は,タスクが対象とする処理によって異なる。例えば画像の処理の処理時間については,画像ファイルサイズの影響を受ける。データベースを用いた処理では,データベースへのアクセス回数の影響を受ける。また,タスクのリソース消費量については,例えば,タスクの処理を行うアプリケーション122ごとに値が決まっている場合にはその値を用いることができる。スレーブノード120にリソース消費量を問い合わせるようにしてもよい。その他,様々な周知技術の利用が可能である。
マスタノード110において,スケジュール処理部112は,処理要求を受け付けると,まず,現状で,処理要求のタスクをスレーブノード120に割り当て可能であるかを検証する。
図7(A)は,処理要求のタスクXを,時刻t0 に処理実行を開始するように,#aのスレーブノード120aに対して割り当てした検証の例を示す。また,図7(B)は,処理要求のタスクXを,時刻t0 に処理実行を開始するように,#bのスレーブノード120bに対して割り当てした検証の例を示す。いずれも,ノードのリソース消費量が,ノードのリソース限界量を超えてしまうため,検証結果はNGとなる。
図7(C)は,最も早く処理が終了する,#aのスレーブノード120aが実行するタスクA#1の処理終了後に,処理要求のタスクXをスケジュールした検証の例を示す。この場合,処理要求のタスクXの処理終了時刻が納期t3 を超えてしまうため,検証結果はNGとなる。
次に,スケジュール処理部112は,他のタスクで再起動しても納期までに処理終了可能なタスクを移動する検証を行う。図8(A)に示すように,#bのスレーブノード120bが実行するタスクB#3は,リソース消費量の面でも#aのスレーブノード120aに移動可能であり,#aのスレーブノード120aで再起動しても納期までに処理終了可能である。図8(B)は,図8(A)に示すタスクの移動によってリソース消費量が減った#bのスレーブノード120bに対して,処理要求のタスクXを割り当てした検証の例を示す。タスクの移動を行っても,ノードのリソース消費量が,ノードのリソース限界量を超えてしまうため,検証結果はNGとなる。
他にロック中のスレーブノード120が存在しないので,スケジュール処理部112は,スケールアウト処理部114によるスケールアウトの処理でスレーブノード120を増設すると判断する。図9は,スケールアウト処理部114によって増設された#cのスレーブノード120cに,処理要求のタスクXが割り当てられた状態を示す。
このように,本実施の形態によるマスタノード110は,現状のスレーブノード120の状態でスケジューリングを含めた検証を行っても,さらにタスクの移動を行う検証を行っても,納期内に処理が終了するように処理要求のタスクを割り当てできない場合にのみ,スケールアウトを実行する。これにより,無駄なスケールアウトを抑制できるので,無駄な課金が発生しない,効率がよいシステム100の運用が可能となる。
図10,図11は,本実施の形態のマスタノードにおけるリスケジュール処理部によるタスクの移動シミュレーションの例を説明する図である。
図10は,時刻t0 の時点での,システム100が備える各スレーブノード120a,b,cが実行するタスクのスケジュールを示す。図10に示すように,この時点でシステム100が備えるスレーブノード120は,#aのスレーブノード120aと,#bのスレーブノード120bと,#cのスレーブノード120cの3つである。
まず,マスタノード110において,リスケジュール処理部116は,定期的にスケジュール情報記憶部113を参照して,実行するタスクがないスレーブノード120があるかをチェックする。図10に示すように,この時点では,すべてのスレーブノード120が処理を実行しているので,実行するタスクがないスレーブノード120はない。このとき,リスケジュール処理部116は,現状のままでスケールシュリンクできるスレーブノード120はないと判断する。
次に,リスケジュール処理部116は,他のタスクで再起動しても納期までに処理終了可能なタスクを移動する検証を行う。
図11(A)は,#bのスレーブノード120bが実行するタスクB#1を,#aのスレーブノード120aで再起動する検証の例を示す。図11(A)に示すように,タスクB#1を他のスレーブノード120で再起動すると,処理の終了時刻が納期t2 を超えてしまうため,検証結果はNGとなる。リスケジュール処理部116は,タスクを移動して#bのスレーブノード120bに対してスケールシュリンクを行うことはできないと判断する。
図11(B)は,#cのスレーブノード120cが実行するタスクC#1を,#aのスレーブノード120aで再起動する検証の例を示す。図11(B)に示すように,タスクC#1は,#aのスレーブノード120aで再起動しても納期t3 までに処理終了可能である。さらに,タスクC#1を#aのスレーブノード120aに移動すると,#Cのスレーブノード120cが実行するタスクがなくなるため,#Cのスレーブノード120cに対してスケールシュリンクを行うことが可能である。
リスケジュール処理部116は,スレーブ通信部115を介して,#Cのスレーブノード120cにタスクC#1の停止を指示し,#Aのスレーブノード120aにタスクC#1の実行を指示する。#Cのスレーブノード120cが実行するタスクがなくなるので,リスケジュール処理部116は,#Cのスレーブノード120cをスケールシュリンクの対象とする。スケールシュリンク処理部117は,#Cのスレーブノード120cに対するスケールシュリンクの処理を実行する。
このように,本実施の形態によるマスタノード110は,他のスレーブノード120にタスクを移動することで,実行するタスクがないスレーブノード120を積極的に作り,スケールシュリンクを実行する。これにより,無駄なスレーブノード120を積極的に削除することが可能となるので,無駄な課金が発生しない効率がよいシステム100の運用が可能となる。
図12,図13は,本実施の形態のマスタノードにおけるリスケジュール処理部によるスレーブノードにロック設定を行う例を説明する図である。
図12は,時刻t0 の時点での,システム100が備える各スレーブノード120a,bが実行するタスクのスケジュールを示す。図12に示すように,この時点でシステム100が備えるスレーブノード120は,#aのスレーブノード120aと#bのスレーブノード120bの2つである。
マスタノード110において,リスケジュール処理部116は,タスクを移動しても実行するタスクがないスレーブノード120が用意できない場合に,タスクを移動することで実行するタスクの数が所定数以下となるスレーブノード120を用意できるかを検証する。例えば,ここでは,所定数を1とする。
図13(A)は,#bのスレーブノード120bが実行するタスクB#2を,#aのスレーブノード120aで再起動する検証の例を示す。図13(A)に示すように,タスクB#2は,#aのスレーブノード120aで再起動しても納期t3 までに処理終了可能である。なお,#bのスレーブノード120bが実行するタスクB#1を,#aのスレーブノード120aで再起動しようとしても,処理の終了時刻が納期t2 を超えてしまうため,タスクB#1は移動できない。
タスクB#2を#aのスレーブノード120aに移動したとすると,図13(B)に示すように,#bのスレーブノード120bは,実行するタスクの数が所定数1以下となる。このとき,リスケジュール処理部116は,スレーブ通信部115を介して,#Bのスレーブノード120bにタスクB#2の停止を指示し,#Aのスレーブノード120aにタスクB#2の実行を指示する。
また,図13(B)に示すように,実行するタスクがB#1のみとなった#bのスレーブノード120bに,ロックを設定する。なお,ロックを設定したスレーブノード120の情報は,スケジュール情報記憶部113など,スケジュール処理部112がアクセス可能な記憶部に記録しておく。これで,#bのスレーブノード120bには,原則として,新規の処理要求のタスクが割り当てされないので,残っている#B1のタスクの終了後に,スケールシュリンク処理部117によって,#bのスレーブノード120bを削除することができる。
このように,本実施の形態によるマスタノード110は,他のスレーブノード120にタスクを移動して,実行するタスクが少ないスレーブノード120を積極的に作り,そのスレーブノード120に対する新規の処理要求のタスクの割り当てを抑制する。これにより,システム100の環境が,実行するタスクがないスレーブノード120ができやすい環境となり,無駄なスレーブノード120を積極的に削除することが可能となるので,無駄な課金が発生しない効率がよいシステム100の運用が可能となる。
図14は,本実施の形態のマスタノードにおけるスケジュール処理部によるスレーブノードのロック解除を行う例を説明する図である。
ここで,システム100が,図13(B)に示す状態で,クライアント200から,図6(C)に示すタスクXの処理要求を受けたものとする。このとき,スケジュール処理部112は,処理要求のタスクXを,図14(A)に示すようにロックされていない#aのスレーブノード120aに割り当てしようとするが,ノードのリソース消費量がノードのリソース限界量を超えてしまうため,割り当てできない。さらに,他にタスクを移動できる相手先のスレーブノード120もない。
このとき,スケジュール処理部112は,ロック中の#bのスレーブノード120bのロックを解除すれば,#bのスレーブノード120bで処理要求のタスクXが納期までに処理終了可能かを検証する。図14(B)に示すように,#bのスレーブノード120bで処理要求のタスクXが納期までに処理終了可能であるので,スケジュール処理部112は,ロック中の#bのスレーブノード120bのロックを解除し,#bのスレーブノード120bに処理要求のタスクXを割り当てる。
このように,ロック中のスレーブノード120には,他のスレーブノード120に処理要求のタスクを割り当てできない場合にのみ,処理要求のタスクの割り当てが行われる。これにより,スケールシュリンクを実行しやすい環境をギリギリまで維持しながら,スケールアウトの発生を抑制できるので,無駄な課金が発生しない効率がよいシステム100の運用が可能となる。
なお,本実施の形態によるマスタノード110は,納期内にタスクの処理が終了することを最優先としているので,システム100では常に最低限の処理性能が維持されている。
図15,図16は,本実施の形態のマスタノードによる処理要求受け付け時の処理フローチャートである。
マスタノード110において,クライアント通信部111は,クライアントから処理要求を受け付ける(ステップS10)。ここで受け付ける処理要求には,納期が指定されている。クライアント通信部111は,処理要求が受け入れ可能かを判定する(ステップS11)。処理要求が受け入れ可能でなければ(ステップS11のNO),クライアント通信部111は,クライアントに処理要求の受け入れが不可能である旨を応答し(ステップS12),処理を終了する。
処理要求が受け入れ可能であれば(ステップS11のYES),スケジュール処理部112は,スケジュール情報記憶部113の管理情報を参照し,現状のスレーブノード120に処理要求のタスクを割り当てるシミュレーションを行う(ステップS13)。ここでは,例えば,図7に示すようにスケジューリングを含めた検証が行われる。
スケジュール処理部112は,現状のスレーブノード120に対する処理要求のタスクの割り当てが可能かを判定する(ステップS14)。処理要求のタスクの割り当てが可能であれば(ステップS14のYES),スケジュール処理部112は,処理要求のタスクを割り当てる先のスレーブノード120を決定する(ステップS15)。スレーブ通信部115は,決定されたスレーブノード120に処理要求のタスクの処理を依頼する(ステップS22)。
処理要求のタスクの割り当てが可能でなければ(ステップS14のNO),スケジュール処理部112は,スケジュール情報記憶部113の管理情報を参照し,既存のタスクを移動して,処理要求のタスクを割り当てるシミュレーションを行う(ステップS16)。ここでは,例えば,図8に示すように,他のスレーブノード120に移動して再実行しても納期内に処理を終了可能な既存のタスクがある場合に,その既存タスクを移動してリソースに空きができたスレーブノード120に処理要求のタスクを割り当てることができるかが検証される。
スケジュール処理部112は,既存タスクを移動して処理要求のタスクの割り当てが可能となるかを判定する(ステップS17)。処理要求のタスクの割り当てが可能となれば(ステップS17のYES),スケジュール処理部112は,該当既存タスクの移動を実行する(ステップS18)。より具体的には,スケジュール処理部112は,スレーブ通信部115を介して,既存タスクの移動元のスレーブノード120に該タスクの停止を依頼する。また,スケジュール処理部112は,スレーブ通信部115を介して,既存タスクの移動先のスレーブノード120に該タスクの実行を依頼する。スレーブ通信部115は,既存タスクの移動によりリソースに空きができたスレーブノード120に処理要求のタスクの処理を依頼する(ステップS22)。
処理要求のタスクの割り当てが可能とならなければ(ステップS17のNO),スケジュール処理部112は,ロック中のスレーブノード120が存在して,該スレーブノード120のロックを解除すれば,処理要求のタスクの割り当てが可能となるかを判定する(ステップS19)。ロックを解除して処理要求のタスクの割り当てが可能となれば(ステップS19のYES),スケジュール処理部112は,ロック中のスレーブノード120のロックを解除する(ステップS20)。スレーブ通信部115は,ロックが解除されたスレーブノード120に処理要求のタスクの処理を依頼する(ステップS22)。このケースは,図14の例に示されるケースである。
ロック中のスレーブノード120がないか,ロックを解除しても処理要求のタスクの割り当てが可能とならなければ(ステップS19のNO),スケールアウト処理部114は,スケールアウトの処理を実行する(ステップS21)。スケールアウトにより,システム100にスレーブノード120が増設される。スレーブ通信部115は,増設されたスレーブノード120に処理要求のタスクの処理を依頼する(ステップS22)。このケースは,図9の例に示されるケースである。
スレーブ通信部115が,スレーブノード120から処理要求に対する処理結果の応答を受け付けると(ステップS23),クライアント通信部111は,その応答をクライアントに送信する(ステップS24)。
図17は,本実施の形態のマスタノードによるリスケジュールの処理フローチャートである。
マスタノード110において,リスケジュール処理部116は,所定のタイミングで本処理を開始する。
リスケジュール処理部116は,スケジュール情報記憶部113の管理情報を参照し,現状で実行するタスクがないスレーブノード120があるかを判定する(ステップS30)。実行するタスクがないスレーブノード120があれば(ステップS30のYES),スケールシュリンク処理部117は,該当スレーブノード120に対するスケールシュリンクの処理を実行する(ステップS31)。スケールシュリンクにより,システム100からスレーブノード120が削除される。
リスケジュール処理部116は,スケジュール情報記憶部113の管理情報を参照し,タスクを移動するシミュレーションを行う(ステップS32)。ここでは,例えば図11に示すように,他のスレーブノード120に移動して再実行しても納期内に処理を終了可能なタスクがある場合に,そのタスクを移動して実行するタスクがないスレーブノード120を生成できるかが検証される。また,例えば図13に示すように,他のスレーブノード120に移動して再実行しても納期内に処理を終了可能なタスクがある場合に,そのタスクを移動して実行するタスクが所定数以下となるスレーブノード120を生成できるかが検証される。
リスケジュール処理部116は,タスクを移動して実行するタスクがないスレーブノード120を生成できるか,すなわちタスクを移動してスケールシュリンクが可能となるかを判定する(ステップS33)。タスクを移動してスケールシュリンクが可能となれば(ステップS33のYES),リスケジュール処理部116は,該当タスクの移動を実行する(ステップS34)。より具体的には,リスケジュール処理部116は,スレーブ通信部115を介して,タスクの移動元のスレーブノード120に該タスクの停止を依頼する。また,リスケジュール処理部116は,スレーブ通信部115を介して,タスクの移動先のスレーブノード120に該タスクの実行を依頼する。スケールシュリンク処理部117は,タスクの移動により実行するタスクがなくなったスレーブノード120に対するスケールシュリンクの処理を実行する(ステップS35)。スケールシュリンクにより,システム100からスレーブノード120が削除される。
タスクを移動してもスケールシュリンクが可能とならなければ(ステップS33のNO),リスケジュール処理部116は,タスクを移動して実行するタスクが所定数以下となるスレーブノード120があるかを判定する(ステップS36)。タスクを移動しても実行するタスクが所定数以下となるスレーブノード120がなければ(ステップS36のNO),リスケジュール処理部116は,処理を終了する。
タスクを移動して実行するタスクが所定数以下となるスレーブノード120があれば(ステップS36のYES),リスケジュール処理部116は,該当タスクの移動を実行する(ステップS37)。より具体的には,リスケジュール処理部116は,スレーブ通信部115を介して,タスクの移動元のスレーブノード120に該タスクの停止を依頼する。また,リスケジュール処理部116は,スレーブ通信部115を介して,タスクの移動先のスレーブノード120に該タスクの実行を依頼する。リスケジュール処理部116は,タスクを移動して実行するタスクが所定数以下となったスレーブノード120にロックを設定する(ステップS38)。このまま,ロックが解除されずに残ったタスクの処理がすべて終了すれば,ロックが設定されたスレーブノード120は,その後のステップS30,S31の処理でスケールシュリンクの対象となる。
以上,本実施の形態について説明したが,本発明はその主旨の範囲において種々の変形が可能であることは当然である。