JP5867238B2 - オートスケーリング方法，オートスケーリングプログラムおよびコンピュータノード - Google Patents

Description

本発明は，システムが備えるコンピュータノード数を制御するオートスケーリング方法，オートスケーリングプログラムおよびコンピュータノードに関するものである。

従来のオンプレミスのシステムでは，システムが持つリソース量が固定であったので，そのシステムが持つリソース量を超えて，クライアントからの処理要求を受け付けることができなかった。

これに対して，近年発展しているクラウドコンピューティングを利用したシステムでは，システムが持つリソース量を動的に変更可能である。そのため，クライアントから要求される処理を実行することによってシステムのリソース消費量がシステムが持つリソース量を超えてしまうような場合でも，システムのリソースを動的に増やすことで，クライアントからの要求を受け付け可能となる。

このようなシステムのリソースを増減する技術として，システムにおける仮想化されたコンピュータノードのリソース量を増減するスケールアップ・スケールダウンと呼ばれる技術がある。しかし，仮想化されたコンピュータノードのリソースの増加には，物理マシンのリソース量の限界がある。

システムのリソースを増減する別の技術として，システムにおけるコンピュータノードの数を増減するスケールアウト・スケールシュリンクと呼ばれる技術がある。この技術では，システムのリソース量の増加に，物理マシンのリソース量の限界がない。システムのリソース消費率に応じて自動でスケールアウト・スケールシュリンクを行う，オートスケーリングと呼ばれる技術もある。

なお，分散バッチシステムにおいて，新たなバッチ処理が要求された際に，ある処理サーバで実行中のバッチ処理を他のサーバに移行し，処理可能となったサーバで新しいバッチ処理を実行することで，バッチ処理のデッドラインを管理する技術が知られている。

特開２００２−３４２０９８号公報

しかし，上述のように，システムのリソース消費率に応じてオートスケーリングを行うと，スケールアウトによって無駄なコンピュータノードが増設されたり，誤ったスケールシュリンクによってシステムが実行中の処理が強制的に中断される場合がある。クラウドコンピューティングにおいて，コンピュータノードの数に応じた従量課金が行われる場合には，無駄なスケールアウトによって無駄な課金が発生してしまう場合がある。

一側面では，本発明は，課金の効率がよいシステムの運用が可能となる技術を提供することを目的とする。

１態様では，オートスケーリング方法では，要求された処理を複数の仮想化されたコンピュータノードに分散して実行するシステムにおいて，該システムで実行するタスクの管理を行うコンピュータノードが，納期が指定された処理要求を受け付けた際に，記憶部に記憶されたシステムが備えるコンピュータノードが実行するタスクを管理する管理情報を参照して，該処理要求のタスクをコンピュータノードに割り当てるシミュレーションを実行し，割り当てのシミュレーションにより，処理要求のタスクを納期内に処理終了可能なコンピュータノードがなく，さらに他のコンピュータノードでも納期内に処理終了可能なタスクを移動しても処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に，システムのコンピュータノードの数を増加する処理を実行する。

１態様では，課金の効率がよいシステムの運用が可能となる。

オンプレミスで実現されるシステムの課題を説明する図である。 クラウドコンピューティングで実現されるシステムの課題を説明する図である。 本実施の形態によるシステムの構成例を示す図である。 本実施の形態による各ノードの機能構成例を示す図である。 本実施の形態によるノードを実現する仮想マシンシステムの例を示す図である。 本実施の形態のマスタノードにおけるスケジュール処理部による処理要求のタスクの割り当てシミュレーションの例を説明する図である。 本実施の形態のマスタノードにおけるスケジュール処理部による処理要求のタスクの割り当てシミュレーションの例を説明する図である。 本実施の形態のマスタノードにおけるスケジュール処理部による処理要求のタスクの割り当てシミュレーションの例を説明する図である。 本実施の形態のマスタノードにおけるスケジュール処理部による処理要求のタスクの割り当てシミュレーションの例を説明する図である。 本実施の形態のマスタノードにおけるリスケジュール処理部によるタスクの移動シミュレーションの例を説明する図である。 本実施の形態のマスタノードにおけるリスケジュール処理部によるタスクの移動シミュレーションの例を説明する図である。 本実施の形態のマスタノードにおけるリスケジュール処理部によるスレーブノードにロック設定を行う例を説明する図である。 本実施の形態のマスタノードにおけるリスケジュール処理部によるスレーブノードにロック設定を行う例を説明する図である。 本実施の形態のマスタノードにおけるスケジュール処理部によるスレーブノードのロック解除を行う例を説明する図である。 本実施の形態のマスタノードによる処理要求受け付け時の処理フローチャートである。 本実施の形態のマスタノードによる処理要求受け付け時の処理フローチャートである。 本実施の形態のマスタノードによるリスケジュールの処理フローチャートである。

以下，本実施の形態について，図を用いて説明する。

図１は，オンプレミスで実現されるシステムの課題を説明する図である。

図１に示す例において，タスクを示す図形の縦の長さは該タスクのリソース消費量を示し，横の長さは該タスクの処理時間を示す。また，図１に示す例において，グラフの縦軸はシステムのリソース消費量を示し，横軸は時間の経過を示す。ｔ₀ 〜ｔ₃ は，等間隔の時刻を示す。

オンプレミスのシステムでは，システムが持つリソースの量は固定となる。すなわち，あらかじめシステムが持つリソース量を超えたリソース消費量の処理を行うことはできない。図１に示す例において，システムリソースのラインは，システムが持つリソースの量を示す。

例えば，図１（Ａ）において，システムに対して，タスク＃１〜タスク＃４の処理要求が，ほぼ同時刻ｔ₀ にあったものとする。このとき，システムは，処理要求を受け付けた順，ここではタスク＃１，タスク＃２，タスク＃３，タスク＃４の順に処理を開始する。しかし，図１（Ａ）に示すように，タスク＃３の処理を開始したところで，システムのリソース消費量がシステムが持つリソース量に達してタスク＃４の処理を開始できない状態となり，タスク＃４の処理要求を受け付けられなくなる。

図１（Ｂ）に示す例は，スケジューリングを行うシステムの例である。スケジューリングを行うシステムでは，処理要求を受け付けた時点でタスクの処理時間を見積もり，処理要求が発生した時点でリソースに空きがなくても，実行中の他のタスクの終了後に受け付けた処理要求のタスクを実行するように，タスクのスケジューリングを行う。

例えば，最後に受け付けるタスク＃４の処理の納期が，時刻ｔ₃ であるものとする。図１（Ｂ）に示すように，最も処理終了時刻が早いタスク＃３の処理終了時刻がｔ₁ であるので，タスク＃４をタスク＃３の後にスケジュールすれば，タスク＃４の処理終了時刻はｔ₃ となり，納期に間に合う。この場合，タスク＃４の処理要求は，システムで受け付け可能となる。

ところが，図１（Ｃ）に示す例では，最も処理終了時刻が早いタスク＃２の後にタスク＃４をスケジュールすると，タスク＃４の処理終了時刻はｔ₃ を超えてしまい，納期に間に合わない。この場合，タスク＃４の処理要求は，システムで受け付けられない。オンプレミスのシステムでは，スケジューリングを行っても，処理要求を受け付けできない場合がある。

このようなオンプレミスの技術の対極に存在するのが，クラウドコンピューティングの技術である。クラウドコンピューティングによって実現されるシステムのリソース量は，可変となる。

クラウドコンピューティングでは，システムが備える各コンピュータノードが，例えば仮想マシン（ＶＭ：Virtual Machine ）で実現される。なお，以下では，システムが備えるコンピュータノードを，単にノードとも呼ぶ。

クラウドコンピューティングにおいて，システムのリソース量を変更する技術として，例えば，スケールアップ・スケールダウンの技術がある。スケールアップは，ノードのリソース量を増加させる技術である。また，スケールダウンは，ノードのリソース量を減少させる技術である。スケールアップの技術を利用すれば，例えば，現状のリソースでは新たな処理要求のタスクを実行しても納期に間に合わないような場合でも，ノードのリソース量を増加させることで，新たな処理要求のタスクを納期に間に合うように実行できるようになる。

しかし，スケールアップ可能なリソースは，仮想マシンであるノードを実現する物理マシンのリソースが上限となるため，ノードのスケールアップには限界がある。また，通常は１つの物理マシン上に複数の仮想マシンのノードが配置されており，物理マシンのリソースを各ノードに配分しきって余剰がない場合には，他のノードの性能を下げることなく特定のノードの性能を上げることは不可能となる。例えば，マルチテナントの環境では，１つの物理マシン上で複数のテナントの仮想マシンを動作することになり，あるテナントの仮想マシンのリソース量を増やすために，他のテナントのリソース量を減らすといったことは，簡単にはできない。よって，スケールアップの技術を用いても，要求された処理のタスクをすべて納期を保証して実行できるわけではない。

クラウドコンピューティングにおいて，システムのリソース量を変更する技術として，スケールアップ・スケールダウンの技術以外に，スケールアウト・スケールシュリンクの技術がある。スケールアウトは，システムにノードを増設する技術である。スケールシュリンクは，システムからノードを撤去する技術である。スケールアウトの技術を用いれば，ほぼ確実に要求された処理のタスクをすべて納期を保証して実行できるようになる。

ただし，クラウドコンピューティングの世界では，通常はサービス使用料金が従量制となっており，スケールアウトによってシステムが備えるノードの数が増加するにつれて，サービスの使用料金が増えてしまう。

図２は，クラウドコンピューティングで実現されるシステムの課題を説明する図である。

図２に示す例において，タスクを示す図形の縦の長さは該タスクのリソース消費量を示し，横の長さは該タスクの処理時間を示す。また，図２に示す例において，グラフの縦軸はシステムを構成するノードのリソース消費量の合計を示し，横軸は時間の経過を示す。ｔ₀ 〜ｔ₃ は，等間隔の時刻を示す。図２に示す例において，システムリソースのラインは，システムを構成するノードが持つリソースの量の合計を示す。

図２（Ａ）において，システムは，当初，ＶＭ＃１〜ＶＭ＃３の３つのノードを備えているものとする。ここで，システムに対して，タスク＃１〜タスク＃４の処理要求が，ほぼ同時刻ｔ₀ にあったものとする。このとき，システムでは，処理要求を受け付けた順，ここではタスク＃１，タスク＃２，タスク＃３，タスク＃４の順に，ノードにタスクが割り当てられ，処理が開始される。しかし，図２（Ａ）に示すように，ＶＭ＃３のノードにタスク＃３の処理を割り当てたところで，システムのすべてのノードのリソース消費量が上限となり，タスク＃４の処理を割り当て可能なノードがなくなる。

このとき，例えば図２（Ａ）に示すように，システムではスケールアウトが行われ，ＶＭ＃４のノードがシステムに増設される。図２（Ａ）に示すように，スケールアウトによってＶＭ＃４のノードがシステムに増設されることで，要求されたタスク＃４の処理が実行可能となる。例えば，クラウドコンピューティングにおいて，仮想マシンやネットワークなどのインフラをサービスとして提供するＩａａＳ（Infrastructure as a Service ）ベンダのサービスとして，システムのリソース消費率が所定以上となったときに自動でスケールアウトを行うサービスがある。クラウドコンピューティングにおいて，自動でシステムの拡張／縮小を行う技術は，オートスケーリングとも呼ばれる。

ここで，タスク＃４の処理の納期が時刻ｔ₃ であるものとする。図２（Ａ）に示すように，最も処理終了時刻が早いタスク＃３の処理終了時刻がｔ₁ であるので，タスク＃４をタスク＃３の後にスケジュールすれば，タスク＃４の処理終了時刻はｔ₃ となり，納期に間に合う。

このように，タスクのスケジューリングを行うことができれば，スケールアウトによりＶＭ＃４のノードを増設しなくても，納期に間に合うようにタスク＃４の処理を実行することが可能であった。しかし，このような判断は，上述のＩａａＳのサービスのようにリソース消費を見ただけではできない。上述したように，クラウドコンピューティングでは，ノードが増えるごとに使用料金が増えるため，ノードを増設しなくても納期に間に合うようにタスクの処理を実行できるのであれば，ノードを増設したくないという要望がある。

また，無駄なノードの使用料金を抑えるために，システムで運用されていないと判断されるノードに対するスケールシュリンクが行われ，該ノードがシステムから撤去される。例えば，クラウドコンピューティングにおいて，ＩａａＳベンダのサービスとして，ノードのＣＰＵ（Central Processing Unit ）使用率が所定以下となったときに，該ノードではタスクの処理が行われておらずＯＳなどのミドルウェアしか動作していないと判断し，自動でスケールシュリンクを行うサービスがある。

だだし，ノードのリソース消費量が少ないからといって，必ずしも要求されたタスクの処理が行われていないとは限らない。たとえば，図２（Ｂ）に示す例において，ＶＭ＃３のノードでは，タスク＃３の処理が終了すると，リソース消費量が極端に減ってしまう。しかし，図２（Ｂ）に示す例において，ＶＭ＃３のノードでは，タスク＃３と並列にリソース消費量が少ないタスク＃４が実行されている。タスク＃３の処理の終了と同時にＶＭ＃３のノードに対するスケールシュリンクが行われると，タスク＃４の処理が強制終了されてしまう。このように，上述のＩａａＳベンダのサービスのようにリソース消費を見ただけでスケールシュリンクを判断すると，例えば，図２（Ｂ）に示すタスク＃４のようにリソース消費量が少ないタスクの処理を実行中であるノードを，誤って撤去してしまう可能性がある。

以下では，このような問題の解決を図った本実施の形態によるオートスケーリングの技術を説明する。

図３は，本実施の形態によるシステムの構成例を示す図である。

本実施の形態において，図３に示すシステム１００は，クラウドコンピューティングにおいて，ＩａａＳ側から提供される仮想マシンのノードから構成されるコンピュータシステムであるものとする。システム１００は，クライアント２００から要求された処理を，複数のノードで分散して実行する。システム１００とクライアント２００とは，ＬＡＮ（Local Area Network）やインターネットなどのネットワーク３００で接続されている。システム１００は，マスタノード１１０，スレーブノード１２０を備える。

マスタノード１１０は，クライアント２００からの処理要求を受け付け，各スレーブノード１２０に対するタスクの割り当てや，システム１００で実行するタスクの管理を行う。なお，本実施の形態によるマスタノード１１０は，スレーブノード１２０のスケールアウトやスケールシュリンクなどのオートスケーリングの処理を行う。なお，マスタノード１１０が，同時にスレーブノード１２０の１つであってもよい。

スレーブノード１２０は，マスタノード１１０から割り当てられた処理要求のタスクを実行するコンピュータノードである。スレーブノード１２０は，複数のタスクの並列処理が可能である。スレーブノード１２０は，オートスケーリングの処理によって，システム１００に増設，またはシステム１００から削除される。例えば，図３において，＃ａのスレーブノード１２０ａと＃ｂのスレーブノード１２０ｂがタスクの処理を実行している場合に，それらのスレーブノード１２０で実行しきれない処理要求があれば，＃ｃのスレーブノード１２０ｃがシステム１００に増設される。また，たとえば，＃ｃのスレーブノード１２０ｃが実行するタスクがなくなれば，＃ｃのスレーブノード１２０ｃがシステム１００から削除される。

クライアント２００は，システム１００に対して，システム１００が提供する処理の実行要求を行う上位アプリケーションを有するコンピュータである。なお，図１に示す例では，クライアント２００がシステム１００外部の装置となっているが，例えばクライアント２００がシステム１００内部のノードであってもよい。

図４は，本実施の形態による各ノードの機能構成例を示す図である。

マスタノード１１０は，クライアント通信部１１１，スケジュール処理部１１２，スケジュール情報記憶部１１３，スケールアウト処理部１１４，スレーブ通信部１１５，リスケジュール処理部１１６，スケールシュリンク処理部１１７を備える。

クライアント通信部１１１は，クライアント２００からの処理要求を受け付ける。クライアント通信部１１１は，受け付けた要求の処理がシステム１００内で実行可能なものであれば，スケジュール処理部１１２に渡す。クライアント通信部１１１は，受け付けた要求の処理がシステム１００内で処理実行不可能なものであれば，その旨をクライアント２００に応答する。システム１００内で処理実行不可能な処理は，例えばスレーブノード１２０にないアプリケーションの処理や，１仮想マシンのスレーブノード１２０では納期までに終了できない大規模な処理などである。大規模な処理を，複数のノードで分散して実行する技術については，本実施の形態による技術の範囲外であるので，ここでは説明を行わない。クライアント通信部１１１は，スレーブノード１２０から受け取った処理結果をクライアント２００に通知する。

スケジュール処理部１１２は，クライアント通信部１１１が納期が指定された処理要求を受け付けた際に，スケジュール情報記憶部１１３に記憶された管理情報を参照して，該処理要求のタスクをスレーブノード１２０に割り当てるシミュレーションを実行する。

スケジュール情報記憶部１１３は，システム１００が備えるスレーブノード１２０が実行するタスクを管理する管理情報の記憶部である。スケジュール情報記憶部１１３に記憶された管理情報には，すべてのスレーブノード１２０で実行するタスクのスケジュールが記録されている。

より具体的には，スケジュール処理部１１２は，まず，現行の状態で，受け付けた処理要求のタスクを，指定された納期内に処理終了可能なスレーブノード１２０の検出を行う。ここでは，スケジュール処理部１１２は，即時に処理実行可能なスレーブノード１２０だけではなく，他のタスクの処理終了後に処理要求のタスクを実行しても，納期内に処理終了可能なスレーブノード１２０も検出する。スケジュール処理部１１２は，ここで検出されたスレーブノード１２０から，処理要求のタスクを割り当てるスレーブノード１２０を選択する。なお，ここでは，ロック中のスレーブノード１２０については，検出の対象外とする。本実施の形態において，ロックは，スレーブノード１２０を，処理要求のタスクの割り当て対象外に設定することをいう。

スケジュール処理部１１２は，現行の状態で処理要求のタスクを納期内に処理終了可能なスレーブノード１２０がなければ，他のスレーブノード１２０に移動しても納期内に処理終了可能なタスクを検出する。スケジュール処理部１１２は，検出されたタスクを移動することで，処理要求のタスクを納期内に処理終了可能なスレーブノード１２０を用意できるかを判定する。タスクを移動することで処理要求のタスクを納期内に処理終了可能なスレーブノード１２０を用意できると判定される場合，スケジュール処理部１１２は，該当タスクを他のスレーブノード１２０に移動する処理を，スレーブ通信部１１５を介して実行する。タスクの移動は，例えば該タスクの処理を移動元のスレーブノード１２０で停止し，移動先のスレーブノード１２０で再起動させる方法でもよいし，移動元のスレーブノード１２０における該タスクの実行中のイメージデータを移動先のスレーブノード１２０に転送する方法でもよい。本実施の形態では，該タスクの処理を移動先のスレーブノード１２０で再起動させる方法でタスクの移動を行うものとする。スケジュール処理部１１２は，タスクの移動により空きができたスレーブノード１２０を，処理要求のタスクを割り当てる対象のスレーブノード１２０に決定する。

スケジュール処理部１１２は，タスクを移動しても処理要求のタスクを納期内に処理終了可能なスレーブノード１２０を用意できない場合，ロック中のスレーブノード１２０があれば，そのロックを解除すれば，処理要求のタスクを納期内に処理終了可能であるかを判定する。ロック解除により，処理要求のタスクを納期内に処理終了可能となると判定される場合には，スケジュール処理部１１２は，ロック中のスレーブノード１２０のロックを解除する。スケジュール処理部１１２は，ロックを解除したスレーブノード１２０を，処理要求のタスクを割り当てる対象のスレーブノード１２０に決定する。

スケジュール処理部１１２は，ここまでの処理で，処理要求のタスクを割り当てる対象のスレーブノード１２０が見つけられなかった場合，スケールアウトにより，システム１００にスレーブノード１２０を増設すると判断する。

スケールアウト処理部１１４は，スケールアウトによって，システム１００にコンピュータノードを増設する処理を行う。より具体的には，スケールアウト処理部１１４は，ＩａａＳ側で用意しているインタフェースを用いて，ＩａａＳ側の管理コンピュータにアクセスし，自システム１００へのスケールアウトを要求する。

スレーブ通信部１１５は，スレーブノード１２０との通信を行う。例えば，スレーブ通信部１１５は，受け付けた処理要求のタスクを割り当てる対象のスレーブノード１２０に対して，該タスクの処理を依頼する。また，スレーブ通信部１１５は，スレーブノード１２０から，依頼したタスクの処理結果を応答として受け付ける。また，スレーブ通信部１１５は，タスクの移動が行われる際に，移動元のスレーブノード１２０に対して該当タスクの停止を通知し，移動先のスレーブノード１２０に対して該当タスクの実行を通知する。

リスケジュール処理部１１６は，例えば定期的に，スケジュール情報記憶部１１３に記憶された管理情報を参照し，実行するタスクがないスレーブノード１２０を，スケールシュリンクの対象とする。

また，リスケジュール処理部１１６は，スケジュール情報記憶部１１３に記憶された管理情報を参照して，あるスレーブノード１２０で動作するタスクを，他のスレーブノード１２０に移動するシミュレーションを実行する。リスケジュール処理部１１６は，他のスレーブノード１２０に移動しても納期内に処理終了可能なタスクを検出する。

リスケジュール処理部１１６は，検出されたタスクを移動することで，実行するタスクがないスレーブノード１２０を用意できるかを判定する。タスクを移動することで実行するタスクがないスレーブノード１２０を用意できると判定される場合，リスケジュール処理部１１６は，該当タスクを他のスレーブノード１２０に移動する処理を，スレーブ通信部１１５を介して実行する。タスクの移動については，上述のスケジュール処理部１１２の場合と同様である。リスケジュール処理部１１６は，タスクの移動により実行するタスクがなくなったスレーブノード１２０を，スケールシュリンクの対象とする。

また，リスケジュール処理部１１６は，検出されたタスクを移動することで，実行するタスクの数が所定数以下となるスレーブノード１２０を用意できるかを判定する。タスクの移動により実行するタスクの数が所定数以下となるスレーブノード１２０を用意できると判定される場合，リスケジュール処理部１１６は，該当タスクを他のスレーブノード１２０に移動する処理を，スレーブ通信部１１５を介して実行する。リスケジュール処理部１１６は，タスクの移動により実行するタスクの数が所定数以下となるスレーブノード１２０にロックを設定する。ロック中のスレーブノード１２０には，原則として新たな処理要求のタスクが割り当てられないので，残ったタスクの処理が終了した後で，スケールシュリンクの対象となる。

スケールシュリンク処理部１１７は，スケールシュリンクによって，対象のスレーブノード１２０をシステム１００から削除する処理を行う。より具体的には，スケールシュリンク処理部１１７は，ＩａａＳ側で用意しているインタフェースを用いて，ＩａａＳ側の管理コンピュータにアクセスし，対象スレーブノード１２０のスケールシュリンクを要求する。

スレーブノード１２０は，マスタ通信部１２１，アプリケーション１２２を備える。図４に示すように，スレーブノード１２０では，複数種類のアプリケーション１２２ａ，ｂ，... を稼働することが可能である。処理要求のタスクが割り当てられた際には，該処理要求に対応するアプリケーション１２２によって，タスクの処理が実行される。

マスタ通信部１２１は，マスタノード１１０との通信を行う。例えば，マスタ通信部１２１は，マスタノード１１０からタスクの実行要求や停止要求を受け付け，タスクの実行開始または実行停止の処理を行う。また，タスクの処理が終了した場合には，マスタ通信部１２１は，マスタノード１１０に処理結果の応答を返す。

図５は，本実施の形態によるノードを実現する仮想マシンシステムの例を示す図である。

図５に示す仮想マシンシステムは，例えば，１台の物理マシン上で１または複数台の仮想マシンが動作するシステムである。図５に示す仮想マシンシステムの例では，ＣＰＵ１１やメモリ１２などの，物理マシンであるコンピュータ１０の資源を利用して，マスタノード１１０やスレーブノード１２０を含む複数の仮想マシン３０が動作している。なお，図５に示す仮想マシンシステムでは，マスタノード１１０とスレーブノード１２０とが同じ物理マシンで実現されているが，クラウドコンピューティングの環境では，マスタノード１１０や，各スレーブノード１２０が，それぞれ異なる物理マシンで実現されることも多い。

図５に示す仮想マシンシステムにおいて，ハイパーバイザ２０は，コンピュータ１０を利用した仮想化環境を実現するソフトウェアである。マスタノード１１０やスレーブノード１２０を含む仮想マシン３０は，ハイパーバイザ２０上に構築可能である。

図４に示すマスタノード１１０，スレーブノード１２０を仮想マシンで実現するコンピュータ１０は，例えば，ＣＰＵ１１，主記憶となるメモリ１２，記憶装置１３，通信装置１４，媒体読取・書込装置１５，入力装置１６，出力装置１７等のハードウェアを備える。記憶装置１３は，例えばＨＤＤ（Hard Disk Drive ）等の外部記憶装置や，補助記憶装置などである。媒体読取・書込装置１５は，例えばＣＤ−Ｒ（Compact Disc Recordable ）ドライブやＤＶＤ−Ｒ（Digital Versatile Disc Recordable ）ドライブなどである。入力装置１６は，例えばキーボード・マウスなどである。出力装置１７は，例えばディスプレイ等の表示装置などである。なお，コンピュータ１０のハードウェア構成は，必要に応じて任意の設計が可能である。

図４に示すマスタノード１１０，スレーブノード１２０および各ノードが備える機能部は，コンピュータ１０が備えるＣＰＵ１１，メモリ１２等のハードウェアと，ソフトウェアプログラムとによって実現することが可能である。コンピュータ１０が実行可能なプログラムは，例えば，記憶装置１３に記憶され，その実行時にメモリ１２に読み出され，ＣＰＵ１１により実行される。

コンピュータ１０は，可搬型記録媒体から直接プログラムを読み取り，そのプログラムに従った処理を実行することもできる。また，コンピュータ１０は，サーバコンピュータからプログラムが転送されるごとに，逐次，受け取ったプログラムに従った処理を実行することもできる。さらに，このプログラムは，コンピュータで読み取り可能な記録媒体に記録しておくことができる。

以下，本実施の形態によるマスタノード１１０による処理について，より具体的な例を用いて説明する。

図６〜図９は，本実施の形態のマスタノードにおけるスケジュール処理部による処理要求のタスクの割り当てシミュレーションの例を説明する図である。

図６（Ａ）は，タスクの表記の例を示す。図６（Ａ）において，塗り潰しされた図形が，タスクの処理を表す。タスクの処理を示す図形の縦の長さは該タスクのリソース消費量を示し，横の長さは該タスクの処理時間を示す。また，図６（Ａ）において，白抜き図形の右端は，該タスクの納期を示す。納期は，クライアント２００に指定されたタスクの処理を終了する期限である。以下の説明において，タスクについてはすべて図６（Ａ）に示す通りの表記が行われる。

図６（Ｂ）は，クライアント２００から時刻ｔ₀ に処理要求を受け付けた時点における，システム１００が備える各スレーブノード１２０ａ，ｂが実行するタスクのスケジュールを示す。図６（Ｂ）に示すように，この時点でシステム１００が備えるスレーブノード１２０は，＃ａのスレーブノード１２０ａと＃ｂのスレーブノード１２０ｂの２つである。なお，スケジュール情報記憶部１１３には，例えば図６（Ｂ）のグラフに示すようなシステム１００が備えるスレーブノード１２０が実行するタスクのスケジュールをデータ化した管理情報が記憶されている。図６（Ｂ）において，グラフの縦軸はスレーブノードのリソース消費量を示し，横軸は時間の経過を示す。ｔ_-1〜ｔ₃ は，等間隔の時刻を示す。

図６（Ｃ）は，時刻ｔ₀ の時点でクライアント２００から受け付けた処理要求のタスクＸを示す図形である。図６（Ｃ）に示すように，処理要求のタスクＸの処理については，他のタスクと区別がつくように，ハッチングで表されている。図６（Ｃ）に示すように，処理要求のタスクＸについては，時刻ｔ₃ の納期が指定されている。

なお，タスクの処理時間やリソース消費量の推定については，過去の実績から求める方法や理論的に求める方法などで多数の周知技術が存在するので，ここでは詳細な説明を省略する。タスクの処理時間の推定は，タスクが対象とする処理によって異なる。例えば画像の処理の処理時間については，画像ファイルサイズの影響を受ける。データベースを用いた処理では，データベースへのアクセス回数の影響を受ける。また，タスクのリソース消費量については，例えば，タスクの処理を行うアプリケーション１２２ごとに値が決まっている場合にはその値を用いることができる。スレーブノード１２０にリソース消費量を問い合わせるようにしてもよい。その他，様々な周知技術の利用が可能である。

マスタノード１１０において，スケジュール処理部１１２は，処理要求を受け付けると，まず，現状で，処理要求のタスクをスレーブノード１２０に割り当て可能であるかを検証する。

図７（Ａ）は，処理要求のタスクＸを，時刻ｔ₀ に処理実行を開始するように，＃ａのスレーブノード１２０ａに対して割り当てした検証の例を示す。また，図７（Ｂ）は，処理要求のタスクＸを，時刻ｔ₀ に処理実行を開始するように，＃ｂのスレーブノード１２０ｂに対して割り当てした検証の例を示す。いずれも，ノードのリソース消費量が，ノードのリソース限界量を超えてしまうため，検証結果はＮＧとなる。

図７（Ｃ）は，最も早く処理が終了する，＃ａのスレーブノード１２０ａが実行するタスクＡ＃１の処理終了後に，処理要求のタスクＸをスケジュールした検証の例を示す。この場合，処理要求のタスクＸの処理終了時刻が納期ｔ₃ を超えてしまうため，検証結果はＮＧとなる。

次に，スケジュール処理部１１２は，他のタスクで再起動しても納期までに処理終了可能なタスクを移動する検証を行う。図８（Ａ）に示すように，＃ｂのスレーブノード１２０ｂが実行するタスクＢ＃３は，リソース消費量の面でも＃ａのスレーブノード１２０ａに移動可能であり，＃ａのスレーブノード１２０ａで再起動しても納期までに処理終了可能である。図８（Ｂ）は，図８（Ａ）に示すタスクの移動によってリソース消費量が減った＃ｂのスレーブノード１２０ｂに対して，処理要求のタスクＸを割り当てした検証の例を示す。タスクの移動を行っても，ノードのリソース消費量が，ノードのリソース限界量を超えてしまうため，検証結果はＮＧとなる。

他にロック中のスレーブノード１２０が存在しないので，スケジュール処理部１１２は，スケールアウト処理部１１４によるスケールアウトの処理でスレーブノード１２０を増設すると判断する。図９は，スケールアウト処理部１１４によって増設された＃ｃのスレーブノード１２０ｃに，処理要求のタスクＸが割り当てられた状態を示す。

このように，本実施の形態によるマスタノード１１０は，現状のスレーブノード１２０の状態でスケジューリングを含めた検証を行っても，さらにタスクの移動を行う検証を行っても，納期内に処理が終了するように処理要求のタスクを割り当てできない場合にのみ，スケールアウトを実行する。これにより，無駄なスケールアウトを抑制できるので，無駄な課金が発生しない，効率がよいシステム１００の運用が可能となる。

図１０，図１１は，本実施の形態のマスタノードにおけるリスケジュール処理部によるタスクの移動シミュレーションの例を説明する図である。

図１０は，時刻ｔ₀ の時点での，システム１００が備える各スレーブノード１２０ａ，ｂ，ｃが実行するタスクのスケジュールを示す。図１０に示すように，この時点でシステム１００が備えるスレーブノード１２０は，＃ａのスレーブノード１２０ａと，＃ｂのスレーブノード１２０ｂと，＃ｃのスレーブノード１２０ｃの３つである。

まず，マスタノード１１０において，リスケジュール処理部１１６は，定期的にスケジュール情報記憶部１１３を参照して，実行するタスクがないスレーブノード１２０があるかをチェックする。図１０に示すように，この時点では，すべてのスレーブノード１２０が処理を実行しているので，実行するタスクがないスレーブノード１２０はない。このとき，リスケジュール処理部１１６は，現状のままでスケールシュリンクできるスレーブノード１２０はないと判断する。

次に，リスケジュール処理部１１６は，他のタスクで再起動しても納期までに処理終了可能なタスクを移動する検証を行う。

図１１（Ａ）は，＃ｂのスレーブノード１２０ｂが実行するタスクＢ＃１を，＃ａのスレーブノード１２０ａで再起動する検証の例を示す。図１１（Ａ）に示すように，タスクＢ＃１を他のスレーブノード１２０で再起動すると，処理の終了時刻が納期ｔ₂ を超えてしまうため，検証結果はＮＧとなる。リスケジュール処理部１１６は，タスクを移動して＃ｂのスレーブノード１２０ｂに対してスケールシュリンクを行うことはできないと判断する。

図１１（Ｂ）は，＃ｃのスレーブノード１２０ｃが実行するタスクＣ＃１を，＃ａのスレーブノード１２０ａで再起動する検証の例を示す。図１１（Ｂ）に示すように，タスクＣ＃１は，＃ａのスレーブノード１２０ａで再起動しても納期ｔ₃ までに処理終了可能である。さらに，タスクＣ＃１を＃ａのスレーブノード１２０ａに移動すると，＃Ｃのスレーブノード１２０ｃが実行するタスクがなくなるため，＃Ｃのスレーブノード１２０ｃに対してスケールシュリンクを行うことが可能である。

リスケジュール処理部１１６は，スレーブ通信部１１５を介して，＃Ｃのスレーブノード１２０ｃにタスクＣ＃１の停止を指示し，＃Ａのスレーブノード１２０ａにタスクＣ＃１の実行を指示する。＃Ｃのスレーブノード１２０ｃが実行するタスクがなくなるので，リスケジュール処理部１１６は，＃Ｃのスレーブノード１２０ｃをスケールシュリンクの対象とする。スケールシュリンク処理部１１７は，＃Ｃのスレーブノード１２０ｃに対するスケールシュリンクの処理を実行する。

このように，本実施の形態によるマスタノード１１０は，他のスレーブノード１２０にタスクを移動することで，実行するタスクがないスレーブノード１２０を積極的に作り，スケールシュリンクを実行する。これにより，無駄なスレーブノード１２０を積極的に削除することが可能となるので，無駄な課金が発生しない効率がよいシステム１００の運用が可能となる。

図１２，図１３は，本実施の形態のマスタノードにおけるリスケジュール処理部によるスレーブノードにロック設定を行う例を説明する図である。

図１２は，時刻ｔ₀ の時点での，システム１００が備える各スレーブノード１２０ａ，ｂが実行するタスクのスケジュールを示す。図１２に示すように，この時点でシステム１００が備えるスレーブノード１２０は，＃ａのスレーブノード１２０ａと＃ｂのスレーブノード１２０ｂの２つである。

マスタノード１１０において，リスケジュール処理部１１６は，タスクを移動しても実行するタスクがないスレーブノード１２０が用意できない場合に，タスクを移動することで実行するタスクの数が所定数以下となるスレーブノード１２０を用意できるかを検証する。例えば，ここでは，所定数を１とする。

図１３（Ａ）は，＃ｂのスレーブノード１２０ｂが実行するタスクＢ＃２を，＃ａのスレーブノード１２０ａで再起動する検証の例を示す。図１３（Ａ）に示すように，タスクＢ＃２は，＃ａのスレーブノード１２０ａで再起動しても納期ｔ₃ までに処理終了可能である。なお，＃ｂのスレーブノード１２０ｂが実行するタスクＢ＃１を，＃ａのスレーブノード１２０ａで再起動しようとしても，処理の終了時刻が納期ｔ₂ を超えてしまうため，タスクＢ＃１は移動できない。

タスクＢ＃２を＃ａのスレーブノード１２０ａに移動したとすると，図１３（Ｂ）に示すように，＃ｂのスレーブノード１２０ｂは，実行するタスクの数が所定数１以下となる。このとき，リスケジュール処理部１１６は，スレーブ通信部１１５を介して，＃Ｂのスレーブノード１２０ｂにタスクＢ＃２の停止を指示し，＃Ａのスレーブノード１２０ａにタスクＢ＃２の実行を指示する。

また，図１３（Ｂ）に示すように，実行するタスクがＢ＃１のみとなった＃ｂのスレーブノード１２０ｂに，ロックを設定する。なお，ロックを設定したスレーブノード１２０の情報は，スケジュール情報記憶部１１３など，スケジュール処理部１１２がアクセス可能な記憶部に記録しておく。これで，＃ｂのスレーブノード１２０ｂには，原則として，新規の処理要求のタスクが割り当てされないので，残っている＃Ｂ１のタスクの終了後に，スケールシュリンク処理部１１７によって，＃ｂのスレーブノード１２０ｂを削除することができる。

このように，本実施の形態によるマスタノード１１０は，他のスレーブノード１２０にタスクを移動して，実行するタスクが少ないスレーブノード１２０を積極的に作り，そのスレーブノード１２０に対する新規の処理要求のタスクの割り当てを抑制する。これにより，システム１００の環境が，実行するタスクがないスレーブノード１２０ができやすい環境となり，無駄なスレーブノード１２０を積極的に削除することが可能となるので，無駄な課金が発生しない効率がよいシステム１００の運用が可能となる。

図１４は，本実施の形態のマスタノードにおけるスケジュール処理部によるスレーブノードのロック解除を行う例を説明する図である。

ここで，システム１００が，図１３（Ｂ）に示す状態で，クライアント２００から，図６（Ｃ）に示すタスクＸの処理要求を受けたものとする。このとき，スケジュール処理部１１２は，処理要求のタスクＸを，図１４（Ａ）に示すようにロックされていない＃ａのスレーブノード１２０ａに割り当てしようとするが，ノードのリソース消費量がノードのリソース限界量を超えてしまうため，割り当てできない。さらに，他にタスクを移動できる相手先のスレーブノード１２０もない。

このとき，スケジュール処理部１１２は，ロック中の＃ｂのスレーブノード１２０ｂのロックを解除すれば，＃ｂのスレーブノード１２０ｂで処理要求のタスクＸが納期までに処理終了可能かを検証する。図１４（Ｂ）に示すように，＃ｂのスレーブノード１２０ｂで処理要求のタスクＸが納期までに処理終了可能であるので，スケジュール処理部１１２は，ロック中の＃ｂのスレーブノード１２０ｂのロックを解除し，＃ｂのスレーブノード１２０ｂに処理要求のタスクＸを割り当てる。

このように，ロック中のスレーブノード１２０には，他のスレーブノード１２０に処理要求のタスクを割り当てできない場合にのみ，処理要求のタスクの割り当てが行われる。これにより，スケールシュリンクを実行しやすい環境をギリギリまで維持しながら，スケールアウトの発生を抑制できるので，無駄な課金が発生しない効率がよいシステム１００の運用が可能となる。

なお，本実施の形態によるマスタノード１１０は，納期内にタスクの処理が終了することを最優先としているので，システム１００では常に最低限の処理性能が維持されている。

図１５，図１６は，本実施の形態のマスタノードによる処理要求受け付け時の処理フローチャートである。

マスタノード１１０において，クライアント通信部１１１は，クライアントから処理要求を受け付ける（ステップＳ１０）。ここで受け付ける処理要求には，納期が指定されている。クライアント通信部１１１は，処理要求が受け入れ可能かを判定する（ステップＳ１１）。処理要求が受け入れ可能でなければ（ステップＳ１１のＮＯ），クライアント通信部１１１は，クライアントに処理要求の受け入れが不可能である旨を応答し（ステップＳ１２），処理を終了する。

処理要求が受け入れ可能であれば（ステップＳ１１のＹＥＳ），スケジュール処理部１１２は，スケジュール情報記憶部１１３の管理情報を参照し，現状のスレーブノード１２０に処理要求のタスクを割り当てるシミュレーションを行う（ステップＳ１３）。ここでは，例えば，図７に示すようにスケジューリングを含めた検証が行われる。

スケジュール処理部１１２は，現状のスレーブノード１２０に対する処理要求のタスクの割り当てが可能かを判定する（ステップＳ１４）。処理要求のタスクの割り当てが可能であれば（ステップＳ１４のＹＥＳ），スケジュール処理部１１２は，処理要求のタスクを割り当てる先のスレーブノード１２０を決定する（ステップＳ１５）。スレーブ通信部１１５は，決定されたスレーブノード１２０に処理要求のタスクの処理を依頼する（ステップＳ２２）。

処理要求のタスクの割り当てが可能でなければ（ステップＳ１４のＮＯ），スケジュール処理部１１２は，スケジュール情報記憶部１１３の管理情報を参照し，既存のタスクを移動して，処理要求のタスクを割り当てるシミュレーションを行う（ステップＳ１６）。ここでは，例えば，図８に示すように，他のスレーブノード１２０に移動して再実行しても納期内に処理を終了可能な既存のタスクがある場合に，その既存タスクを移動してリソースに空きができたスレーブノード１２０に処理要求のタスクを割り当てることができるかが検証される。

スケジュール処理部１１２は，既存タスクを移動して処理要求のタスクの割り当てが可能となるかを判定する（ステップＳ１７）。処理要求のタスクの割り当てが可能となれば（ステップＳ１７のＹＥＳ），スケジュール処理部１１２は，該当既存タスクの移動を実行する（ステップＳ１８）。より具体的には，スケジュール処理部１１２は，スレーブ通信部１１５を介して，既存タスクの移動元のスレーブノード１２０に該タスクの停止を依頼する。また，スケジュール処理部１１２は，スレーブ通信部１１５を介して，既存タスクの移動先のスレーブノード１２０に該タスクの実行を依頼する。スレーブ通信部１１５は，既存タスクの移動によりリソースに空きができたスレーブノード１２０に処理要求のタスクの処理を依頼する（ステップＳ２２）。

処理要求のタスクの割り当てが可能とならなければ（ステップＳ１７のＮＯ），スケジュール処理部１１２は，ロック中のスレーブノード１２０が存在して，該スレーブノード１２０のロックを解除すれば，処理要求のタスクの割り当てが可能となるかを判定する（ステップＳ１９）。ロックを解除して処理要求のタスクの割り当てが可能となれば（ステップＳ１９のＹＥＳ），スケジュール処理部１１２は，ロック中のスレーブノード１２０のロックを解除する（ステップＳ２０）。スレーブ通信部１１５は，ロックが解除されたスレーブノード１２０に処理要求のタスクの処理を依頼する（ステップＳ２２）。このケースは，図１４の例に示されるケースである。

ロック中のスレーブノード１２０がないか，ロックを解除しても処理要求のタスクの割り当てが可能とならなければ（ステップＳ１９のＮＯ），スケールアウト処理部１１４は，スケールアウトの処理を実行する（ステップＳ２１）。スケールアウトにより，システム１００にスレーブノード１２０が増設される。スレーブ通信部１１５は，増設されたスレーブノード１２０に処理要求のタスクの処理を依頼する（ステップＳ２２）。このケースは，図９の例に示されるケースである。

スレーブ通信部１１５が，スレーブノード１２０から処理要求に対する処理結果の応答を受け付けると（ステップＳ２３），クライアント通信部１１１は，その応答をクライアントに送信する（ステップＳ２４）。

図１７は，本実施の形態のマスタノードによるリスケジュールの処理フローチャートである。

マスタノード１１０において，リスケジュール処理部１１６は，所定のタイミングで本処理を開始する。

リスケジュール処理部１１６は，スケジュール情報記憶部１１３の管理情報を参照し，現状で実行するタスクがないスレーブノード１２０があるかを判定する（ステップＳ３０）。実行するタスクがないスレーブノード１２０があれば（ステップＳ３０のＹＥＳ），スケールシュリンク処理部１１７は，該当スレーブノード１２０に対するスケールシュリンクの処理を実行する（ステップＳ３１）。スケールシュリンクにより，システム１００からスレーブノード１２０が削除される。

リスケジュール処理部１１６は，スケジュール情報記憶部１１３の管理情報を参照し，タスクを移動するシミュレーションを行う（ステップＳ３２）。ここでは，例えば図１１に示すように，他のスレーブノード１２０に移動して再実行しても納期内に処理を終了可能なタスクがある場合に，そのタスクを移動して実行するタスクがないスレーブノード１２０を生成できるかが検証される。また，例えば図１３に示すように，他のスレーブノード１２０に移動して再実行しても納期内に処理を終了可能なタスクがある場合に，そのタスクを移動して実行するタスクが所定数以下となるスレーブノード１２０を生成できるかが検証される。

リスケジュール処理部１１６は，タスクを移動して実行するタスクがないスレーブノード１２０を生成できるか，すなわちタスクを移動してスケールシュリンクが可能となるかを判定する（ステップＳ３３）。タスクを移動してスケールシュリンクが可能となれば（ステップＳ３３のＹＥＳ），リスケジュール処理部１１６は，該当タスクの移動を実行する（ステップＳ３４）。より具体的には，リスケジュール処理部１１６は，スレーブ通信部１１５を介して，タスクの移動元のスレーブノード１２０に該タスクの停止を依頼する。また，リスケジュール処理部１１６は，スレーブ通信部１１５を介して，タスクの移動先のスレーブノード１２０に該タスクの実行を依頼する。スケールシュリンク処理部１１７は，タスクの移動により実行するタスクがなくなったスレーブノード１２０に対するスケールシュリンクの処理を実行する（ステップＳ３５）。スケールシュリンクにより，システム１００からスレーブノード１２０が削除される。

タスクを移動してもスケールシュリンクが可能とならなければ（ステップＳ３３のＮＯ），リスケジュール処理部１１６は，タスクを移動して実行するタスクが所定数以下となるスレーブノード１２０があるかを判定する（ステップＳ３６）。タスクを移動しても実行するタスクが所定数以下となるスレーブノード１２０がなければ（ステップＳ３６のＮＯ），リスケジュール処理部１１６は，処理を終了する。

タスクを移動して実行するタスクが所定数以下となるスレーブノード１２０があれば（ステップＳ３６のＹＥＳ），リスケジュール処理部１１６は，該当タスクの移動を実行する（ステップＳ３７）。より具体的には，リスケジュール処理部１１６は，スレーブ通信部１１５を介して，タスクの移動元のスレーブノード１２０に該タスクの停止を依頼する。また，リスケジュール処理部１１６は，スレーブ通信部１１５を介して，タスクの移動先のスレーブノード１２０に該タスクの実行を依頼する。リスケジュール処理部１１６は，タスクを移動して実行するタスクが所定数以下となったスレーブノード１２０にロックを設定する（ステップＳ３８）。このまま，ロックが解除されずに残ったタスクの処理がすべて終了すれば，ロックが設定されたスレーブノード１２０は，その後のステップＳ３０，Ｓ３１の処理でスケールシュリンクの対象となる。

以上，本実施の形態について説明したが，本発明はその主旨の範囲において種々の変形が可能であることは当然である。

１００ システム
１１０ マスタノード
１１１ クライアント通信部
１１２ スケジュール処理部
１１３ スケジュール情報記憶部
１１４ スケールアウト処理部
１１５ スレーブ通信部
１１６ リスケジュール処理部
１１７ スケールシュリンク処理部
１２０ スレーブノード
１２１ マスタ通信部
１２２ アプリケーション
２００ クライアント
３００ ネットワーク

Claims (6)

1. 要求された処理を複数の仮想化されたコンピュータノードに分散して実行するシステムにおいて，該システムで実行するタスクの管理を行うコンピュータノードが，
   納期が指定された処理要求を受け付けた際に，記憶部に記憶された，前記システムが備えるコンピュータノードが実行するタスクを管理する管理情報を参照して，該処理要求のタスクをコンピュータノードに割り当てるシミュレーションを実行し，
   前記割り当てのシミュレーションにより，前記処理要求のタスクを納期内に処理終了可能なコンピュータノードがなく，さらに他のコンピュータノードでも納期内に処理終了可能なタスクを移動しても前記処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に，前記システムのコンピュータノードの数を増加する処理を実行する
   ことを特徴とするオートスケーリング方法。
2. 前記タスクの管理を行うコンピュータノードが，さらに，
   前記管理情報を参照して，あるコンピュータノードで動作するタスクを，他のコンピュータノードに移動するシミュレーションを実行し，
   前記移動のシミュレーションにより，他のコンピュータノードでも納期内に処理終了可能なタスクを移動して，実行するタスクがないコンピュータノードを用意できると判定された場合に，該他のコンピュータノードでも納期内に処理終了可能なタスクを移動し，
   実行するタスクがないコンピュータノードを前記システムから削除する処理とを実行する
   ことを特徴とする請求項１に記載のオートスケーリング方法。
3. 前記タスクの管理を行うコンピュータノードが，さらに，
   前記移動のシミュレーションにより，他のコンピュータノードでも納期内に処理終了可能なタスクを移動して，実行するタスクの数が所定数以下となるコンピュータノードを用意できると判定された場合に，該他のコンピュータノードでも納期内に処理終了可能なタスクを移動し，
   実行するタスクの数が所定数以下のコンピュータノードを処理要求のタスクの割り当て対象外に設定する処理を実行する
   ことを特徴する請求項２に記載のオートスケーリング方法。
4. 前記システムにコンピュータノードを増設する処理では，さらに，前記処理要求のタスクの割り当て対象外に設定されたコンピュータノードの設定を解除しても，前記処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に，前記システムにコンピュータノードを増設する
   ことを特徴とする請求項３に記載のオートスケーリング方法。
5. 要求された処理を複数の仮想化されたコンピュータノードに分散して実行するシステムにおいて，該システムで実行するタスクの管理を行うコンピュータノードに，
   納期が指定された処理要求を受け付けた際に，記憶部に記憶された，前記システムが備えるコンピュータノードが実行するタスクを管理する管理情報を参照して，該処理要求のタスクをコンピュータノードに割り当てるシミュレーションを実行し，
   前記割り当てのシミュレーションにより，前記処理要求のタスクを納期内に処理終了可能なコンピュータノードがなく，さらに他のコンピュータノードでも納期内に処理終了可能なタスクを移動しても前記処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に，前記システムのコンピュータノードの数を増加する
   処理を実行させるためのオートスケーリングプログラム。
6. 複数の仮想化されたコンピュータノードを備えるシステムにおいて，該システムで実行されるタスクの管理を行うコンピュータノードであって，
   前記システムが備えるコンピュータノードが実行するタスクを管理する管理情報の記憶部と，
   納期が指定された処理要求を受け付けた際に，前記管理情報を参照して，該処理要求のタスクをコンピュータノードに割り当てるシミュレーションを実行するスケジュール処理部と，
   前記スケジュール処理部により，前記処理要求のタスクを納期内に処理終了可能なコンピュータノードがなく，さらに他のコンピュータノードでも納期内に処理終了可能なタスクを移動しても前記処理要求のタスクを納期内に処理終了可能なコンピュータノードを用意できないと判定された場合に，前記システムのコンピュータノードの数を増加する処理を実行するスケールアウト処理部とを備える
   ことを特徴とするコンピュータノード。

Images