(57)【要約】  負荷の変動に応じた適切なリソースの割当てを可能にするリソース割当システム等を提供する。  リソース割当システム１００は、タスクを実行するサーバの負荷に関する情報を取得する負荷取得部１１０と、負荷に関する情報を用いて求められる緊急度に基づいて、タスクに対するリソースの割当てに関する必要性を判定する緊急度判定部１２０と、緊急度判定部１２０がサーバの負荷の傾向を確認する必要があると判定した場合に、サーバの負荷の傾向を判定する負荷判定部１３０と、緊急度判定部１２０がタスクにリソースを割当てる必要があると判定した場合に、タスクにリソースを割当てるリソース割当部１４０とを備える。
2017013872.tif 000002
【特許請求の範囲】
【請求項１】
タスクを実行するサーバの負荷に関する情報を取得する負荷取得手段と、
前記負荷に関する情報に基づいて、前記タスクに対するリソースの割当てに関する必要性を判定する緊急度判定手段と、
前記緊急度判定手段が前記サーバの負荷の傾向を確認する必要があると判定した場合に、前記サーバの負荷の傾向を判定する負荷判定手段と、
前記緊急度判定手段が前記タスクにリソースを割当てる必要があると判定した場合に、前記タスクに前記リソースを割当てるリソース割当手段とを備える、リソース割当システム。
【請求項２】
前記負荷取得手段による前記情報の取得間隔を変更する間隔調整手段を備える、請求項１に記載のリソース割当システム。
【請求項３】
前記間隔調整手段は、前記緊急度判定手段が前記サーバの負荷の傾向を確認する必要があると判定した場合に、前記情報の取得間隔をそれまでより短い時間間隔に変更する、請求項２に記載のリソース割当システム。
【請求項４】
前記間隔調整手段は、前記緊急度判定手段が前記サーバの負荷の傾向を確認する必要があると判定した場合に、前記情報の取得間隔を、前記情報を用いて求められる緊急度の程度に応じて異なる短い時間間隔に変更する、請求項２に記載のリソース割当システム。
【請求項５】
前記負荷判定手段は、前記情報の取得間隔が所定の取得間隔と比較して短くされている場合に、前記サーバの負荷の傾向を判定する、請求項３又は４に記載のリソース割当システム。
【請求項６】
前記負荷判定手段は、前記負荷取得手段において取得された前記情報が、所定の回数に亘って前記サーバの負荷の増加を示す場合に、前記サーバの負荷が増加傾向にあると判定する、請求項５に記載のリソース割当システム。
【請求項７】
前記負荷判定手段は、前記サーバの負荷の時間的な変化の様子が所定のパターンと類似するか否かを判定することで、前記サーバの負荷の傾向を判定する、請求項１から６のいずれか一項に記載のリソース割当システム。
【請求項８】
前記リソース割当手段は、前記負荷が増加傾向にあると前記負荷判定手段が判定した場合に前記タスクに前記リソースを割当てる、請求項１から７のいずれか一項に記載のリソース割当システム。
【請求項９】
タスクを実行するサーバの負荷に関する情報を取得し、
前記負荷に関する情報を用いて求められる緊急度に基づいて、前記タスクに対するリソースの割当てに関する必要性を判定し、
前記必要性として、前記サーバの負荷の傾向を確認する必要があると判定された場合に、前記サーバの負荷の傾向を判定し、
前記必要性として、前記緊急度判定手段が前記タスクにリソースを割当てる必要があると判定された場合に、前記タスクに前記リソースを割当てる、リソース割当方法。
【請求項１０】
コンピュータに、
タスクを実行するサーバの負荷に関する情報を取得する処理と、
前記負荷に関する情報を用いて求められる緊急度に基づいて、前記タスクに対するリソースの割当てに関する必要性を判定する処理と、
前記必要性の判定において、前記サーバの負荷の傾向を確認する必要があると判定された場合に、前記サーバの負荷の傾向を判定する処理と、
前記必要性の判定において、前記タスクにリソースを割当てる必要があると判定された場合に、前記タスクに前記リソースを割当てる処理とを実行させるプログラムを格納したコンピュータ読み取り可能記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース割当システム、リソース割当方法及びコンピュータ読み取り可能記録媒体に関する。
【背景技術】
【０００２】
複数のタスクを実行する計算機システムにおいては、当該タスクの負荷に応じて、必要なリソースの割り当てが必要となる。また、タスクの負荷が急激に増加した場合には、処理性能を低下させないよう、当該タスクに対する速やかなリソースの割り当てが求められる。【０００３】
特許文献１には、アプリケーションの負荷に対して計算機リソースを短時間で追従させる技術が記載されている。特許文献１に記載のリソース割当制御サーバは、収集した負荷情報と、過去に収集した負荷情報とを用いて、アプリケーションを実行する際の負荷の増減量を算出する。そして、特許文献１に記載のリソース割当制御サーバは、算出した増減量に基づいて、アプリケーションに割当るリソース量を決定する。【０００４】
特許文献２には、システムの動作状況に応じて不足している資源の種別を適切に判断し、その資源を増設できるようにする技術が記載されている。特許文献２に記載のシステム管理装置においては、運用中のシステムの負荷状態が動作状況監視手段で測定され、追加資源判定手段により、資源追加ポリシーに基づいて、ハードウェア資源の追加の要否等が判定される。そして、特許文献２に記載のシステム管理装置においては、サーバを追加すべきと判定された場合、サーバ追加手段により、予備用サーバによる運用が開始される。【０００５】
特許文献３には、負荷の変動に対して過敏に反応して資源の再割り当てが頻繁に発生するのを防止する技術が記載されている。特許文献３に記載の計算機システムは、資源数算出式テーブルに保持されている情報の定義する複数の資源数算出式に従って、当該複数の資源数算出式毎にサービスに必要な資源数を算出する。有効資源数判定機構は、複数の資源数算出式毎に算出された必要資源数の１つを、有効資源数判定式選択機構によって有効資源数判定式テーブルの中から選択された有効資源数判定式に従って有効資源数として判定する。割り当て資源数調整機構は、判定された有効資源数をもとに、対応するサービスに割当てる資源数を調整する。特許文献３に記載の計算機システムにおいては、有効資源数判定式は、ユーザによって選択される。【０００６】
特許文献４には、リソースの負荷情報の測定を構成度に保ちつつネットワークを効果的に管理して安定に制御すると同時に、測定オーバーヘッドを減少させる技術が記載されている。特許文献４に記載のリソース負荷測定方法においては、リソースの負荷情報を測定間隔で測定した測定負荷情報とリソースの負荷情報を予測アルゴリズムに応じて予測した予測負荷情報とに基づいて測定間隔を調整するように構成されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１４−１６４７１５号公報
【特許文献２】特開２００６−１１８６０号公報
【特許文献３】特開２００５−１７３９２８号公報
【特許文献４】特開２００５−８６８０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１又は２に記載の技術においては、計算機システムの負荷に関する単一の閾値に基づいてリソースの割り当てが制御される。この場合においては、例えば相対的に小さな負荷に対してリソースの割り当てが行われるように閾値が設定されることで、計算機システムにおける急激な負荷の変動への速やかな対応が可能となる。しかしながら、このように閾値が設定されることで、閾値に近い範囲での負荷の変動に応じて、必ずしも必要ではないリソースの割り当てが行われる場合がある。【０００９】
一方、特許文献３に記載の技術においては、例えばユーザが選択した資源数算出式に基づいて、対応するサービスに割当てる資源数が調整される。そのため、例えば急激な負荷の上昇であるスパイク現象が発生しないとの想定に基づいて資源数算出式が選択されている際にスパイク現象が発生した場合等においては、速やかなリソースの割り当てが行われない可能性がある。【００１０】
すなわち、特許文献１から４に記載の技術においては、負荷の変動に応じた適切なリソースの割り当てが困難であるという課題がある。【００１１】
本発明は、上記課題を解決するためになされたものであって、負荷の変動に応じた適切なリソースの割当てを可能にするリソース割当システム等を提供することを主たる目的とする。
【課題を解決するための手段】
【００１２】
本発明の一態様におけるリソース割当システムは、タスクを実行するサーバの負荷に関する情報を取得する負荷取得手段と、負荷に関する情報を用いて求められる緊急度に基づいて、タスクに対するリソースの割当てに関する必要性を判定する緊急度判定手段と、緊急度判定手段がサーバの負荷の傾向を確認する必要があると判定した場合に、サーバの負荷の傾向を判定する負荷判定手段と、緊急度判定手段がタスクにリソースを割当てる必要があると判定した場合に、タスクにリソースを割当てるリソース割当手段とを備える。【００１３】
また、本発明の一態様におけるリソース割り当て方法は、タスクを実行するサーバの負荷に関する情報を取得し、負荷に関する情報を用いて求められる緊急度に基づいて、タスクに対するリソースの割当てに関する必要性を判定し、必要性として、サーバの負荷の傾向を確認する必要があると判定された場合に、サーバの負荷の傾向を判定し、必要性として、緊急度判定手段がタスクにリソースを割当てる必要があると判定された場合に、タスクにリソースを割当てる。【００１４】
また、本発明の一態様におけるコンピュータ読み取り可能記録媒体は、コンピュータに、タスクを実行するサーバの負荷に関する情報を取得する処理と、負荷に関する情報を用いて求められる緊急度に基づいて、タスクに対するリソースの割当てに関する必要性を判定する処理と、必要性の判定において、サーバの負荷の傾向を確認する必要があると判定された場合に、サーバの負荷の傾向を判定する処理と、必要性の判定において、タスクにリソースを割当てる必要があると判定された場合に、タスクにリソースを割当てる処理とを実行させるプログラムを非一時的に格納する。
【発明の効果】
【００１５】
本発明によると、負荷の変動に応じた適切なリソースの割当てを可能にするリソース割当システム等を提供することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の第１の実施形態におけるリソース割当システムの構成を示す図である。
【図２】本発明の第１の実施形態等におけるリソース割当システムとタスク実行サーバとの接続関係を示す図である。
【図３】本発明の第１の実施形態におけるリソース割当システムの動作の一例を示すフローチャートである。
【図４】本発明の第２の実施形態におけるリソース割当システムの構成を示す図である。
【図５】本発明の第２の実施形態において測定値記憶部にて記憶される負荷に関する情報の一例を示す図である。
【図６】本発明の第２の実施形態におけるリソース割当システムの動作の一例を示すフローチャートである。
【図７】は、本発明の第２の実施形態におけるリソース割当システムに含まれる傾向判定部の動作の一例を示すフローチャートである。
【図８】本発明の第３の実施形態におけるリソース割当システムの構成を示す図である。
【図９】本発明の第３の実施形態におけるリソース割当システムのパターン照合部に関する具体的な構成例を示す図である。
【図１０】本発明の第３の実施形態において負荷上昇パターンの一例を示す図である。
【図１１】本発明の第３の実施形態において負荷取得部により取得される負荷と負荷上昇パターンとの関係を説明する図である。
【図１２】本発明の第３の実施形態におけるリソース割当システムの動作の一例を示すフローチャートである。
【図１３】本発明の第３の実施形態におけるリソース割当システムに含まれる傾向判定部の動作の一例を示すフローチャートである。
【図１４】本発明の第４の実施形態におけるリソース割当システムを示す図である。
【図１５】本発明の第４の実施形態におけるリソース割当システムの動作の一例を示すフローチャートである。
【図１６】本発明の第５の実施形態におけるリソース割当システムを示す図である。
【図１７】本発明の第５の実施形態におけるリソース割当システムの動作の一例を示すフローチャートである。
【図１８】実施例１におけるリソース割当システムとタスク実行サーバの構成を示す図である。
【図１９】実施例１において、負荷に関する情報と、当該負荷に対して求められた緊急度の例を示す表である。
【図２０】図１９に示すＣＰＵ負荷とＣＰＵ負荷が測定された時刻との関係を示すグラフである。
【図２１】実施例１において、負荷に関する情報と、当該負荷に対して求められた緊急度の別の例を示す表である。
【図２２】図２１に示すＣＰＵ負荷とＣＰＵ負荷が測定された時刻との関係を示すグラフである。
【図２３】実施例１において、負荷に関する情報と、当該負荷に対して求められた緊急度の更に別の例を示す表である。
【図２４】図２３に示すＣＰＵ負荷とＣＰＵ負荷が測定された時刻との関係を示すグラフである。
【図２５】実施例２におけるリソース割当システムとタスク実行サーバの構成を示す図である。
【図２６】実施例２においてパターン記憶部に記憶されるパターンの例である。
【図２７】負荷に関する情報と、当該負荷に対して求められた緊急度の例を示す表である。
【図２８】本発明の各実施形態におけるリソース割当システム等を実現する情報処理装置の一例を示す図である。
【発明を実施するための形態】
【００１７】
本発明の各実施形態について、添付の図面を参照して説明する。なお、本発明の各実施形態において、各装置の各構成要素は、機能単位のブロックを示している。各装置の各構成要素は、例えば図２８に示すような情報処理装置１０００とソフトウェアとの任意の組み合わせにより実現することができる。情報処理装置１０００は、一例として、以下のような構成を含む。
【００１８】
・ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１００１
・ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１００２
・ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１００３
・ＲＡＭ１００３にロードされるプログラム１００４
・プログラム１００４を格納する記憶装置１００５
・記憶媒体１００６の読み書きを行うドライブ装置１００７
・通信ネットワーク１００９と接続する通信インターフェース１００８
・データの入出力を行う入出力インターフェース１０１０
・各構成要素を接続するバス１０１１
上述した情報処理装置１０００は、複数のＣＰＵ１００１を備えてもよい。ＣＰＵ１００１は、複数のプロセッサコアを含むマルチコアプロセッサであってもよい。各装置の実現方法には様々な変形例がある。例えば、各装置は、専用の装置として実現される。また、各装置は、複数の装置の組み合わせにより実現される。
【００１９】
（第１の実施形態）
まず、本発明の第１の実施形態について説明する。図１は、本発明の第１の実施形態におけるリソース割当システムを示す図である。図２は、本発明の第１の実施形態等におけるリソース割当システムとタスク実行サーバとの接続関係を示す図である。図３は、本発明の第１の実施形態におけるリソース割当システムの動作の一例を示すフローチャートである。
【００２０】
図１に示すとおり、本発明の第１の実施形態におけるリソース割当システム１００は、負荷取得部１１０と、緊急度判定部１２０と、負荷判定部１３０と、リソース割当部１４０とを備える。負荷取得部１１０は、タスクを実行するサーバの負荷に関する情報を取得する。緊急度判定部１２０は、負荷に関する情報に基づいて、タスクに対するリソースの割当てに関する必要性を判定する。負荷判定部１３０は、緊急度判定部１２０がサーバの負荷の傾向を確認する必要があると判定した場合に、サーバの負荷の傾向を判定する。リソース割当部１４０は、緊急度判定部１２０がタスクにリソースを割当てる必要があると判定した場合に、タスクに対してリソースを割当てる。また、リソース割当システム１００は、測定値記憶部１５０を備えてもよい。測定値記憶部１５０は、負荷取得部１１０にて取得したサーバの負荷に関する情報を記憶する。
【００２１】
本実施形態及び本発明の各実施形態におけるリソース割当システム１００は、一例として、図２（Ａ）に示すタスク実行サーバ１１において実行されるタスクに対するリソースの割当てを行う。リソース割当システム１００は、タスク実行サーバ１１と通信ネットワーク１２を介して接続される。また、タスク実行サーバ１１は、外部通信ネットワーク１３と接続される。
【００２２】
タスク実行サーバ１１は、例えば上述した情報処理装置１０００にて実現される。また、タスク実行サーバ１１では、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や、ハイパーバイザによって管理される仮想機械（以下「ＯＳ等」とする）が動作する。タスク実行サーバ１１で動作するＯＳ等において、ユーザからの要求等に応じて任意のタスクが実行される。
【００２３】
各々のタスクに対しては、予め定められた範囲でタスク実行サーバ１１等のリソースが割当てられる。各々のタスクに対して割り当てられるリソースは、例えば、タスク実行サーバ１１を実現する情報処理装置１０００のプロセッサコアやメモリ等がある。また、各々のタスクに対して割り当てられるリソースは、タスク実行サーバ１１と通信ネットワーク１２を介して接続される他の情報処理装置が備えるリソースであってもよい。また、タスクに対して割り当てられるリソースは、タスク実行サーバ等に対して予め行われた設定等に応じて変更される。
【００２４】
リソース割当システム１００は、図２（Ｂ）に示すように、タスク実行サーバ１１−１からタスク実行サーバ１１−ｎの各々において実行されるタスクをリソースの割当ての対象としてもよい。すなわち、リソース割当システム１００は、タスク実行サーバ１１−１からタスク実行サーバ１１−ｎの複数のタスク実行サーバにて実行されるタスクに対するリソースの割当てを行う。
【００２５】
また、本発明の各実施形態におけるリソース割当システム１００、及びリソースの割当ての対象となるタスクは、一つの情報処理装置にて動作するＯＳ等において、それぞれ別のプロセスとして実行されるプログラムであってもよい。
【００２６】
なお、本実施形態及び本発明の各実施形態において、リソース割当システム１００は、サーバの負荷としてタスクが実行されるサーバのＣＰＵの使用率を取得し、プロセッサコアをリソースとしてタスクに割当てることを想定する。
【００２７】
続いて、本発明の第１の実施形態におけるリソース割当システム１００の各構成要素について説明する。
【００２８】
負荷取得部１１０は、タスクを実行するサーバの負荷に関する情報を取得する。サーバの負荷に関する情報は、サーバが備えるリソースや、サーバが通信ネットワークを介して利用する外部のリソースに対する負荷の様子を任意の形式で表す情報である。このリソースは、タスクの実行に際して必要となるリソースである。サーバの負荷に関する情報には、サーバが備えるＣＰＵやメモリ、ネットワーク等のリソースの各々の使用率等が含まれる。また、サーバの負荷に関する情報は、上述した使用率等を取得した時刻や、使用率等を取得した間隔などを含んでもよい。以下、サーバの負荷に関する情報によって表されるサーバの負荷を、単に「サーバの負荷」又は「負荷」と表す場合がある。
【００２９】
負荷取得部１１０は、例えば図２（Ａ）に示すタスク実行サーバ１１に負荷の測定を指示して、タスク実行サーバ１１の負荷に関する情報を取得する。一例として、負荷取得部１１０は、予め定められた一定の時間間隔に基づいて、タスク実行サーバ１１の負荷に関する情報を取得する。本実施形態においては、負荷取得部１１０は、負荷に関する情報として、例えば、ＣＰＵの使用率、当該ＣＰＵ使用率の測定時刻、当該ＣＰＵ使用率の測定間隔等の情報を取得する。
【００３０】
負荷取得部１１０にて取得された負荷に関する情報は、後述する緊急度判定部１２０に通知される。また、負荷取得部１１０は、負荷に関する情報を測定値記憶部１５０に記憶させてもよい。測定値記憶部１５０に記憶される情報の詳細については後述する。
【００３１】
緊急度判定部１２０は、負荷取得部１１０にて取得されたサーバの負荷に基づいて、サーバが備えるリソースのタスクに対する割当てが必要であるかを判定する。具体的には、緊急度判定部１２０は、負荷取得部１１０によって取得されたサーバの負荷を用いて、緊急度を求める。そして、緊急度に基づいて、サーバが備えるリソースのタスクに対する割当てが必要であるかを判定する。なお、緊急度判定部１２０は、これ以外の方法でサーバが備えるリソースのタスクに対する割当てが必要であるかを判定してもよい。
【００３２】
緊急度は、サーバが備えるリソースのタスクに対する割当てに関する必要性の程度を表す。緊急度は、例えば、サーバの負荷と、負荷の傾向とに基づいて求められる。過去の時点におけるサーバの負荷を用いて緊急度を求める場合には、緊急度判定部１２０は、測定値記憶部１５０に記憶された情報を必要に応じて読み出して求めてもよい。
【００３３】
負荷取得部１１０が一定の時間間隔で負荷を取得する場合において、緊急度判定部１２０は、具体的な一例として緊急度を以下のように求める。この場合に、緊急度を求める時点において直近となる時点に測定された負荷をＷとする。また、Ｗと、当該時点より一つ前の時点に測定された負荷との差をΔＷとする。そして、ａ及びｂを予め定められた正の係数とする。この場合に、緊急度Ｅは、以下の（１）式の形で求められる。
【００３４】
【数１】
2017013872.tif 000003
【００３５】
すなわち、緊急度は、緊急度を求める時点におけるサーバの負荷と、当該時点における負荷の傾向に基づいて求められる。ａ及びｂは、緊急度を求める時点におけるサーバの負荷と、当該時点における負荷の傾向とのいずれが重要であるか等に応じて適宜定められる。また、上述の（１）式において、負荷の傾向は、緊急度を求める時点において直近となる時点と、当該時点から一つ前の時点において測定された負荷を用いて求められる。しかしながら、負荷の傾向は、緊急度を求める時点において直近となる時点から二つ以上前の時点において測定された負荷を用いてもよい。
【００３６】
なお、緊急度判定部１２０は、上述した直近となる時点より前の時点において測定された負荷を予め保持し、緊急度を求める際に必要に応じて読み出してもよい。または、緊急度判定部１２０は、上負荷取得部１１０が直近より前の時点に測定された負荷を保持してもよい。この場合には、緊急度判定部１２０は、緊急度を求める際に必要に応じて直近より前の時点に測定された負荷取得部１１０から取得する。また、測定値記憶部１５０が備えられている場合には、緊急度判定部１２０は、測定値記憶部１５０に記憶されている、直近より前の時点に測定された負荷を必要に応じて読み出して用いてもよい。
【００３７】
緊急度判定部１２０は、緊急度に基づいて、タスクに対するリソースの割当てが必要かを判定する。
【００３８】
本実施形態においては、緊急度判定部１２０は、二つの基準によってタスクに対するリソースの割当てが必要かを判定する。すなわち、緊急度判定部１２０は、リソースの割当ての必要性が高い場合に、タスクに対してリソースを割当てるべき状態であると判定する。また、緊急度判定部１２０は、リソースの割当ての必要性が高いが、タスクに対してリソースを割当てるべき程度ではない場合に、サーバの負荷の傾向を更に確認する必要があると判定する。
【００３９】
本実施形態では、緊急度判定部１２０は、緊急度が第１及び第２の条件を満たすか否かを判定して、上述した二つの基準によってタスクに対するリソースの割当ての必要性を判定する。第１の条件は、リソースの割当ての必要性が高く、タスクに対してリソースを割当てるべき状態であることを示す条件である。また、第２の条件は、リソースの割当ての必要性が高いが、タスクに対してリソースを割当てるべき程度ではない場合に、サーバの負荷の傾向を更に確認する必要があることを示す条件である。
【００４０】
本実施形態においては、第１及び第２の条件は、緊急度として求められた値に対する閾値として表される。例えば、緊急度Ｅが上述の（１）式にて求められる場合には、第１の条件に関する閾値としてＥ１が、第２の条件に関する閾値としてＥ２が定められる。そして、緊急度判定部１２０は、緊急度がＥ１≦Ｅを満たす（すなわち、緊急度Ｅの大きさがＥ１以上である）場合に、緊急度が第１の条件を満たすと判定する。また、緊急度判定部１２０は、緊急度ＥがＥ２≦Ｅ＜Ｅ１を満たす（すなわち、緊急度Ｅの大きさがＥ２以上であり、かつ、Ｅ１よりも小さい）場合に、緊急度が第２の条件を満たすと判定する。緊急度がＥ＜Ｅ２を満たす（すなわち、緊急度の大きさがＥ２よりも小さい）場合には、緊急度判定部１２０は、緊急度が第１及び第２のいずれの条件も満たさないと判定する。
【００４１】
後述する負荷判定部１３０又はリソース割当部１４０は、緊急度判定部１２０における判定の結果に応じて動作を行う。つまり、緊急度判定部１２０は、緊急度が第１又は第２の条件を満たすと判定した場合には、負荷判定部１３０又はリソース割当部１４０の各々は、緊急度判定部１２０が満たすと判定した条件に応じて必要な動作を行う。
【００４２】
負荷判定部１３０は、リソースの割当ての必要性が高いが、タスクに対してリソースを割当てるべき程度ではない旨が緊急度判定部１２０によって判定された場合に、サーバの負荷の傾向を判定する。すなわち、負荷判定部１３０は、緊急度が第２の条件を満たす場合に、サーバの負荷の傾向を判定する。負荷判定部１３０は、例えば、負荷取得部１１０にて取得された負荷を、予め定められたリソース割当実行判定式に当てはめることで、負荷の傾向を判定する。リソース割当実行判定式は、一つ以上の任意の数の負荷の測定値を引数として取得し、リソースの割当てが必要か否かを表す判定結果を示す式である。ただし、負荷判定部１３０は、これ以外の任意の手法に基づいてサーバの負荷の傾向を判定してもよい。
【００４３】
負荷判定部１３０は、負荷の傾向の判定に際して、必要に応じて、測定値記憶部１５０に記憶された負荷に関する情報を参照してもよい。また、負荷判定部１３０は、複数の時点における負荷に関する情報を用いて負荷の傾向を判定してもよい。この場合には、負荷判定部１３０は、測定値記憶部１５０に記憶された負荷に関する情報を参照する等して、緊急度が第２の条件を満たすと判定された時点より前の時点における既に計測された負荷に関する情報を用いてもよい。また、負荷判定部１３０は、当該時点より後の時点における負荷に関する情報を用いてもよい。
【００４４】
そして、負荷判定部１３０は、負荷が上昇する傾向にあると判定した場合に、タスクに対してリソースを割当てることを決定してもよい。負荷判定部１３０がタスクに対してリソースを割当てることを決定した場合には、リソース割当部１４０は、後述のようにリソースを割当てる動作を行う。負荷判定部１３０は、負荷が上昇する傾向にあると判定しない場合には、予め定めた任意の条件等に応じて、負荷の傾向の判定を終了してもよいし、引き続き負荷の傾向の判定を継続してもよい。
【００４５】
リソース割当部１４０は、緊急度判定部１２０によってリソースの割当ての必要性が高いと判定された場合に、タスクに対してリソースを割当てる動作を行う。すなわち、リソース割当部１４０は、緊急度が上述した第１の条件を満たす場合、タスクに対してリソースを割当てる動作を行う。リソース割当部１４０は、例えば、図２に示すタスク実行サーバ１１等のようなタスクを実行するサーバに対して、リソースの割当てを要求する。また、リソース割当部１４０は、負荷判定手段において負荷が上昇する傾向にあると判定された場合にも、タスクに対してリソースを割当てる動作を行う。
【００４６】
割当ての対象となるリソースは、例えば１個以上のプロセッサコア等がある。ただし、リソース割当部１４０は、タスク実行サーバ１１等が備える任意のリソースを割当ててもよい。リソース割当部１４０は、タスク実行サーバ１１等のタスクが実行されるサーバに置いて割当てが可能となるリソースの情報を予め保持してもよい。
【００４７】
続いて、図３に示すフローチャートを参照して、本発明の第１の実施形態におけるリソース割当システム１００の動作の一例について説明する。図３に示すフローチャートにおいては、緊急度判定部１２０は、タスクに対するリソースの割当てに関する必要性の判定として、緊急度が上述した第１又は第２の条件のいずれかを満たすか否かを判定する。
【００４８】
最初に、負荷取得部１１０は、タスクを実行するサーバの負荷に関する情報を取得する（ステップＳ１０１）。
【００４９】
次に、緊急度判定部１２０は、緊急度を求める（ステップＳ１０２）。続いて、緊急度判定部１２０は、タスクに対するリソースの割当てに関する必要性を判定する。まず、緊急度判定部１２０は、緊急度が先に説明した上述した第１の条件を満たすかを判定する（ステップＳ１０３）。
【００５０】
緊急度が上述した第１の条件を満たす場合（ステップＳ１０３：Ｙｅｓ）には、緊急度判定部１２０は、リソースの割当ての必要性が高く、タスクに対してリソースを割当てるべき状態であると判定する。この判定に応じて、リソース割当部１４０は、プロセッサコア等のリソースをタスクに対して割当てる（ステップＳ１０４）。
【００５１】
緊急度判定部１２０は、緊急度が上述した第１の条件を満たさない場合（ステップＳ１０３：Ｎｏ）に、緊急度が上述した第２の条件を満たすかを判定する（ステップＳ１０５）。緊急度が第２の条件を満たす（ステップＳ１０５：Ｙｅｓ）場合には、緊急度判定部１２０は、サーバの負荷の傾向を更に確認する必要があると判定する。この判定に応じて、負荷判定部１３０は、負荷傾向を測定する（ステップＳ１０６）。負荷判定部１３０は、測定した負荷傾向に応じて、リソース割当部１４０に対してリソースの割当てを行うことを決定してもよい。この場合には、リソース割当部１４０は、プロセッサコア等のリソースをタスクに対して割当てる。
【００５２】
なお、緊急度判定部１２０において緊急度が第１及び第２のいずれの条件も満たさないと判定された場合（ステップＳ１０５：Ｎｏ）には、リソース割当システム１００は、動作を終了する。なお、負荷取得部１１０が定期的にサーバの負荷に関する情報を取得する場合には、リソース割当システム１００は、図３に示すフローチャートの動作を繰り返して実行してもよい。
【００５３】
以上のとおり、本発明の第１の実施形態におけるリソース割当システム１００は、緊急度判定部１２０にて求められた緊急度に応じてリソースの割当てを行う。
【００５４】
具体的には、緊急度が高いと判定される場合（すなわち、緊急度が上述した第１の条件を満たす場合）には、リソース割当システム１００は、更なる判定を行わずにリソースの割当てを行う。緊急度の高さが中程度であると判定される場合（すなわち、緊急度が上述した第２の条件を満たす場合）には、リソース割当システム１００は、更に負荷の傾向を判定する。そして、負荷が上昇する傾向にあると判定された場合には、リソース割当システム１００は、必要に応じてリソースの割当てを行う場合がある。
【００５５】
すなわち、リソース割当システム１００は、急激に負荷が上昇した場合等、負荷が高い場合には迅速にリソースを割当てることが可能である。また、リソース割当システム１００は、緊急度の高さが中程度である場合に、リソースの割当てに先立ち、負荷の傾向を判定してリソースの割当てを行う。このようにすることで、一時的な負荷の変動に対して過敏に反応したリソースの割当てが回避される。更に、リソース割当システム１００による上述したリソースの割当てに際して、リソースの割当て等に関して事前のポリシーの設定は不要である。
【００５６】
したがって、本実施形態におけるリソース割当システム１００は、負荷の変動に応じた適切なリソースの割当てを可能にする。
【００５７】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。図４は、本発明の第２の実施形態におけるリソース割当システムを示す図である。図５は、測定値記憶部にて記憶される負荷に関する情報の一例を示す図である。図６は、本発明の第２の実施形態におけるリソース割当システムの動作の一例を示すフローチャートである。図７は、本発明の第２の実施形態におけるリソース割当システムに含まれる傾向判定部の動作の一例を示すフローチャートである。
【００５８】
図４に示すとおり、本発明の第２の実施形態におけるリソース割当システム２００は、負荷取得部１１０と、緊急度判定部１２０と、間隔調整部２３１と、傾向判定部２３２と、リソース割当部１４０とを備える。負荷取得部１１０、緊急度判定部１２０及びリソース割当部１４０は、以下に説明がある箇所を除き、基本的に、本発明の第１の実施形態におけるリソース割当システム１００が備える同じ構成要素と同様の動作を行う。間隔調整部２３１は、負荷取得部１１０による負荷に関する情報の取得間隔を変更する。傾向判定部２３２は、間隔調整部２３１が負荷取得部１１０による情報の取得間隔を短くした場合における負荷の傾向に基づいて、タスクに対してリソースを割当てるかを判定する。傾向判定部２３２は、負荷判定部１３０の一つの例である。また、リソース割当システム２００は、負荷取得部１１０にて取得したサーバの負荷に関する計測値を記憶する測定値記憶部１５０を備えてもよい。
【００５９】
すなわち、本実施形態におけるリソース割当システム２００は、間隔調整部２３１を備え、更に負荷判定部１３０として傾向判定部２３２を備える点が、第１の実施形態におけるリソース割当システム１００と異なる。それ以外の点については、本実施形態におけるリソース割当システム２００は、第１の実施形態におけるリソース割当システム１００と基本的に同様の構成を備える。
【００６０】
なお、本実施形態におけるリソース割当システム２００がリソースの割当ての対象とするタスクは、本発明の第１の実施形態におけるリソース割当システム１００がリソースの割当ての対象とするタスクと同様である。
【００６１】
続いて、本発明の第２の実施形態におけるリソース割当システム２００の各構成要素について説明する。
【００６２】
本実施形態においては、負荷取得部１１０は、予め定められた間隔でタスクを実行するサーバの負荷に関する情報を取得する。また、この間隔は、間隔調整部２３１の指示に基づいて変更される場合がある。
【００６３】
例えば、緊急度判定部１２０が、リソースの割当てに関する必要性の判定として、第２の条件を満たすと判定した場合には、傾向判定部２３２からの指示に基づいて、負荷に関する情報を取得する間隔は、短い間隔に変更される。また、傾向判定部２３２による判定結果に基づいて、負荷に関する情報を取得する間隔は、予め定められた当初の間隔に変更される。
【００６４】
なお、先に説明したように、負荷取得部１１０にて取得された負荷に関する情報は、測定値記憶部１５０に記憶される場合がある。測定値記憶部１５０は、負荷に関する情報を、例えば図５に示すテーブルの形式にて記憶する。図５に示すテーブルでは、ＣＰＵの負荷が、測定時刻及び測定時刻間隔と共に記憶される。なお、測定時刻間隔は、ＣＰＵの負荷が測定された一つの測定時刻と、その前にＣＰＵの負荷が測定された測定時刻との間隔を示す。
【００６５】
間隔調整部２３１は、緊急度判定部１２０において緊急度が第２の条件を満たすと判定された場合に、負荷取得部１１０による負荷に関する情報の取得間隔を変更する。本実施形態においては、間隔調整部２３１は、負荷取得部１１０による負荷に関する情報の取得間隔を、通常の時間間隔と、通常の時間間隔と比較して短い時間間隔との２つの時間間隔のいずれかに設定する。
【００６６】
具体的には、間隔調整部２３１は、緊急度が第２の条件を満たす場合に、負荷取得部１１０による負荷に関する情報の取得間隔を短くするように設定する。また、間隔調整部２３１は、後述する傾向判定部２３２の判定結果に基づいて、負荷に関する情報の取得間隔を通常の時間間隔とするように負荷取得部１１０の動作を設定してもよい。
【００６７】
傾向判定部２３２は、負荷に関する情報の取得間隔が短くされた場合における負荷の傾向に基づいて、タスクに対してリソースを割当てるかを判定する。すなわち、傾向判定部２３２は、負荷が増加傾向にある場合には、タスクに対してリソースを割当てると判定する。具体的には、負荷に関する情報の取得間隔が短くされた場合において、傾向判定部２３２は、負荷が所定の測定回数に亘って継続して増加している場合に、負荷が増加傾向にあるとして、タスクに対してリソースを割当てると判定する。
【００６８】
また、傾向判定部２３２は、負荷が減少傾向にある場合には、タスクに対してリソースを割当てないと判定し、かつ、負荷取得部１１０による負荷に関する情報の取得間隔を通常の時間間隔に変更してもよい。
【００６９】
具体的には、負荷に関する情報の取得間隔が短くされた場合において、傾向判定部２３２は、負荷が所定の測定回数に亘って継続して減少している場合に、負荷が減少傾向にあるとして、タスクに対してリソースを割当てないと判定する。そして、傾向判定部２３２は、負荷取得部１１０による負荷に関する情報の取得間隔を通常の間隔に変更する。
【００７０】
一例として、取得間隔が短くされた場合における負荷に関する情報の測定値が測定値記憶部１５０に記憶される場合に、傾向判定部２３２は次のように動作する。
【００７１】
この場合には、傾向判定部２３２は、測定値記憶部１５０の負荷を記憶するテーブルから、直近の所定の回数の測定結果を読み出す。そして、傾向判定部２３２は、測定結果として記録された複数の時点における負荷の全てが、その一つ前の時点に測定された負荷と比較して増加している場合に、負荷が増加傾向にあると判定する。傾向判定部２３２は、負荷が増加傾向にあると判定した場合には、タスクに対するリソースの割当てを決定する。リソース割当部１４０は、当該決定に応じて、タスクに対してリソースを割当てる。
【００７２】
また、この場合において、傾向判定部２３２は、測定結果として記録された複数の時点における負荷の全てが、その一つ前の時点に測定された負荷と比較して減少している場合に、負荷が減少傾向にあると判定する。そして、傾向判定部２３２は、タスクに対してリソースを割当てない旨を決定する。間隔調整部２３１は、この決定に応じて、負荷取得部１１０による負荷に関する情報の取得間隔を通常の間隔に変更する。
【００７３】
なお、傾向判定部２３２は、負荷に関する情報の測定値が上述した場合とは異なる場合には、その時点においてリソースを割当てるか否かの判定を行わなくてもよい。この場合には、傾向判定部２３２は、新たに負荷に関する情報の測定値を取得する等して、当該新たに取得した負荷の傾向に基づいて、改めてリソースを割当てるか否かの判定を行う。
【００７４】
また、傾向判定部２３２は、上述した動作とは異なる動作や基準によって、タスクに対してリソースを割当てるかを判定してもよい。
【００７５】
続いて、図６に示すフローチャートを参照して、本発明の第２の実施形態におけるリソース割当システム２００の動作の一例について説明する。
【００７６】
最初に、負荷取得部１１０は、タスクを実行するサーバの負荷に関する情報を取得する（ステップＳ２０１）。次に、緊急度判定部１２０は、負荷取得部１１０における負荷に関する情報の取得間隔として、通常の時間間隔が設定されているかを判定する（ステップＳ２０２）。
【００７７】
負荷取得部１１０に対して、負荷に関する情報の取得間隔として通常の時間間隔が設定されている場合（ステップＳ２０２：Ｙｅｓ）には、緊急度判定部１２０は、緊急度を求める（ステップＳ２０３）。そして、緊急度判定部１２０は、タスクに対するリソースの割当てに関する必要性を判定する。緊急度判定部１２０は、緊急度が第１の条件を満たすかを判定する（ステップＳ２０４）。
【００７８】
ステップＳ２０３にて求めた緊急度が第１の条件を満たす場合（ステップＳ２０４：Ｙｅｓ）には、緊急度判定部１２０は、タスクに対するリソースの割当てを決定する。この決定に応じて、リソース割当部１４０は、プロセッサコア等のリソースをタスクに対して割当てる（ステップＳ２０５）。
【００７９】
緊急度判定部１２０は、緊急度が先に説明した第１の条件を満たさない場合（ステップＳ２０４：Ｎｏ）に、緊急度が先に説明した第２の条件を満たすかを判定する（ステップＳ２０６）。緊急度が第２の条件を満たす（ステップＳ２０５：Ｙｅｓ）場合には、間隔調整部２３１は、負荷取得部１１０における負荷に関する情報の取得間隔を通常の時間間隔と比較して短い時間間隔とするように設定する（ステップＳ２０７）。ステップＳ２０７における処理が行われると、リソース割当システム２００は、動作を終了する。
【００８０】
なお、ステップＳ２０４、Ｓ２０５及びＳ２０６の動作は、本発明の第１の実施形態におけるステップＳ１０３、Ｓ１０４及びＳ１０５とそれぞれ同様の動作を行う。
【００８１】
負荷取得部１１０に対して、負荷に関する情報の取得間隔として通常の時間間隔が設定されていない場合（ステップＳ２０２：Ｎｏ）には、負荷に関する情報の取得間隔として、短い時間間隔が設定されていると想定される。この場合には、傾向判定部２３２は、負荷傾向を判定する（ステップＳ２０８）。ステップＳ２０８における処理は後述する。ステップＳ２０８における処理が行われると、リソース割当システム２００は、動作を終了する。
【００８２】
なお、負荷取得部１１０が定期的にサーバの負荷に関する情報を取得する場合には、リソース割当システム２００は、図６に示すフローチャートの動作を繰り返して行ってもよい。
【００８３】
なお、負荷取得部１１０が定期的にサーバの負荷に関する情報を取得する場合には、リソース割当システム２００は、負荷取得部１１０が次にサーバの負荷に関する情報を取得する時点から、再びステップＳ２０１以降の動作を実行する。
【００８４】
図７は、傾向判定部２３２が負荷傾向を判定する場合における動作を示すフローチャートである。ステップＳ２０８において傾向判定部２３２が負荷傾向を判定する場合には、傾向判定部２３２は、次のように動作する。
【００８５】
最初に、傾向判定部２３２は、負荷取得部１１０によって上述した短い時間間隔で計測された負荷に関する情報を取得する（ステップＳ２５１）。また、傾向判定部２３２は、例えば測定値記憶部１５０が備えるテーブルから測定結果を読み出して、直近の測定から予め定められた回数の測定結果を取得する。
【００８６】
続いて、傾向判定部２３２は、負荷が、上述した所定の回数に亘って連続して増加しているか否かを判定する（ステップＳ２５２）。傾向判定部２３２は、先に説明したように、上述した所定の回数の各々の時点において計測された負荷の全てが、その一つ前の時点に測定された負荷と比較して大きい場合に、負荷が増加傾向にあると判定する。また、傾向判定部２３２は、測定値記憶部１５０等に記憶された直近の負荷の測定値と、新たに負荷取得部１１０にて取得された負荷との比較を所定の回数について行うことで、負荷の傾向を判定してもよい。
【００８７】
傾向判定部２３２が、上述した所定の測定回数に亘って連続して負荷が上昇していると判断した場合（ステップＳ２５２：Ｙｅｓ）には、負荷が増加傾向にあると判定する。この場合には、傾向判定部２３２は、タスクに対するリソースの割当を決定する。決定に応じて、リソース割当部１４０は、タスクに対してプロセッサコアなどのリソースを割当てる（ステップＳ２５３）。そして、リソースの割当てが行われたことから、傾向判定部２３２は、負荷取得部１１０における負荷に関する情報の取得間隔を通常の間隔に変更することを決定する。決定に応じて、間隔調整部２３１は、負荷取得部における負荷に関する情報の取得間隔を通常の間隔に変更する（ステップＳ２５４）。
【００８８】
また、負荷が上述した所定の測定回数に亘って連続して増加していないと傾向判定部２３２が判断した場合（ステップＳ２５２：Ｎｏ）には、タスクに対するリソースの割当てが必要ではないことが想定される。この場合に、傾向判定部２３２は、負荷が上述した所定の回数に亘って連続して減少しているか否かを判定する（ステップＳ２５５）。傾向判定部２３２は、先に説明したように、上述した所定の回数の各々の時点において計測された負荷の全てが、その一つ前の時点に測定された負荷と比較して小さい場合に、負荷が減少傾向にあると判定する。傾向判定部２３２は、負荷が第２の条件を満たした時点から後の時点に取得された負荷を用いてこの判定を行う。
【００８９】
傾向判定部２３２が、上述した所定の測定回数に亘って連続して負荷が減少していると判断した場合（ステップＳ２５５：Ｙｅｓ）には、負荷が減少しておりタスクに対するリソースの割当ては不要であると想定される。そこで、傾向判定部２３２は、負荷取得部１１０における負荷に関する情報の取得間隔を通常の間隔に変更することを決定する。決定に応じて、間隔調整部２３１は、上述したステップＳ２５４の処理として、負荷取得部における負荷に関する情報の取得間隔を通常の間隔に変更する。
【００９０】
傾向判定部２３２が、上述した所定の測定回数に亘って連続して負荷が減少していないと判断した場合（ステップＳ２５５：Ｎｏ）には、負荷は増加傾向にはないものの、引き続き負荷の傾向を確認する必要がある状態であると想定される。この場合に、傾向判定部２３２は、処理を終了する。すなわち、負荷取得部１１０は、上述した短い時間間隔での負荷に関する情報の取得を継続して行う。また、傾向判定部２３２は、例えば予め定められた時間が経過した後に、再び上述のように負荷傾向を判定してもよい。
【００９１】
以上のとおり、本発明の第２の実施形態におけるリソース割当システム２００は、第１の実施形態におけるリソース割当システム１００と同様に、緊急度判定部１２０にて求められた緊急度に応じてリソースの割当てを行う。緊急度が高いと判定される場合には、リソース割当システム２００は、更なる判定を行わずにリソースの割当てを行う。緊急度が、タスクに対してリソースを割当てる程度の高さではないと判定される場合には、リソース割当システム２００は、負荷の測定間隔を短くして、更に負荷の傾向を判定する。そして、負荷が上昇する傾向にあると判定された場合には、リソース割当システム１００は、リソースの割当てを行う。
【００９２】
すなわち、本実施形態におけるリソース割当システム２００は、第１の実施形態におけるリソース割当システム１００と同様の効果を奏する。また、リソース割当システム２００は、緊急度の程度が、リソースの割当ての必要性が高いものの、タスクに対してリソースを割当てる程度ではないである場合に、負荷の測定間隔を短くして負荷の傾向を判定する。このように負荷の傾向が判定されることで、リソース割当システム２００は、負荷が増加傾向にあることを高い精度で判定することができる。
【００９３】
したがって、本実施形態におけるリソース割当システム２００は、第１の実施形態におけるリソース割当システム１００と比較して、更に適切に負荷の変動に応じたリソースの割当てを可能にする。
【００９４】
（第３の実施形態）
次に、本発明の第３の実施形態について説明する。図８は、本発明の第３の実施形態におけるリソース割当システムを示す図である。図９は、本発明の第３の実施形態におけるリソース割当システムのパターン照合部に関する具体的な構成例を示す図である。図１０は、本発明の第３の実施形態において負荷上昇パターンの一例を示す図である。図１１は、本発明の第３の実施形態において負荷取得部により取得される負荷と負荷上昇パターンとの関係を説明する図である。図１２は、本発明の第３の実施形態におけるリソース割当システムの動作の一例を示すフローチャートである。図１３は、本発明の第３の実施形態におけるリソース割当システムに含まれる傾向判定部の動作の一例を示すフローチャートである。
【００９５】
図８に示すように、本発明の第３の実施形態におけるリソース割当システム３００は、負荷取得部１１０と、緊急度判定部１２０と、パターン照合部３３３と、リソース割当部１４０と、測定値記憶部１５０とを備える。負荷取得部１１０、緊急度判定部１２０及びリソース割当部１４０は、以下に説明がある箇所を除き、基本的に、本発明の第１の実施形態におけるリソース割当システム１００が備える同じ構成要素と同様の動作を行う。パターン照合部３３３は、緊急度判定部１２０において、サーバの負荷の傾向を更に確認する必要があると判定された場合に、負荷の時間的な変化の様子が所定のパターンと類似するかを判定する。
【００９６】
すなわち、本実施形態におけるリソース割当システム３００は、負荷判定部１３０としてパターン照合部３３３を備える点が、第１の実施形態におけるリソース割当システム１００と異なる。それ以外の点については、本実施形態におけるリソース割当システム３００は、第１の実施形態におけるリソース割当システム１００と基本的に同様の構成を備える。
【００９７】
続いて、本発明の第３の実施形態におけるリソース割当システム３００の各構成要素について説明する。
【００９８】
本実施形態においては、負荷取得部１１０は、予め定められた間隔でタスクを実行するサーバの負荷に関する情報を取得する。また、負荷取得部１１０にて取得された負荷に関する情報は、測定値記憶部１５０に記憶される。測定値記憶部１５０は、負荷に関する情報を、例えば第２の実施形態における図５に示すテーブルの形式にて記憶する。
【００９９】
パターン照合部３３３は、緊急度判定部１２０において緊急度が第２の条件を満たし、サーバの負荷の傾向を更に確認する必要があると判定された場合に、負荷の時間的な変化の様子が所定のパターンと類似するかを照合する。この所定のパターンは、負荷の上昇を表すパターンである。
【０１００】
例えば、パターン照合部３３３は、緊急度が第２の条件を満たすと判定された時点より前の予め設定された期間における負荷を取得する。パターン照合部３３３は、当該期間における負荷の時間的な変化の様子と、予め用意された、負荷が時間的に上昇することを表す所定のパターンとを比較する。そして、これらの相違が予め定められた条件を満たす場合に、パターン照合部３３３は、負荷の時間的な変化の様子が負荷の上昇を表す所定のパターンと類似すると判定する。この場合には、パターン照合部３３３は、負荷が増加の傾向にあるとして、タスクへのリソースの割当てを決定する。リソース割当部１４０は、当該決定に応じて、タスクに対してリソースを割当てる。
【０１０１】
パターン照合部３３３は、具体的な一例として、図９に示す構成を有する。図９に示す例では、パターン照合部３３３は、類似度判定部３３４と、パターン記憶部３３５とを有する。
【０１０２】
パターン記憶部３３５は、負荷が時間的に上昇することを表す任意の数のパターンを記憶する。パターン記憶部３３５において記憶されるパターンは、例えば、過去に測定された負荷が上昇する様子である。このパターンは、例えば、シミュレーションによって求められた負荷の上昇の様子であってもよい。また、パターン記憶部３３５において記憶されるパターンの数は特に制限されない。
【０１０３】
図１０は、パターン記憶部３３５において記憶されるパターンの例を示す図である。図１０に示すパターンは、図１１における時刻ＴｓからＴ０までの間に取得された負荷の計測値の系列を表す。Ｔ０は、その時点に取得された負荷に基づいて求められた緊急度が初めて第２の条件を満たした時刻である。Ｔｓは、負荷取得部１１０による負荷の取得が行われた過去の時点である。Ｔｓは、一例として、ＴｓからＴ０までの時間が負荷取得部１１０による負荷の取得間隔の３０倍となるように定められる。なお、Ｔ１は、その時点に取得された負荷に基づいて求められた緊急度が初めて第１の条件を満たす時刻である。
【０１０４】
類似度判定部３３４は、負荷取得部１１０にて取得された負荷の時間的な変化の様子と、パターン記憶部３３５において記憶されたパターンの各々との類似度を求める。
【０１０５】
類似度判定部３３４は、例えば以下の計算式を用いて類似度を求める。類似度判定部３３４は、パターン記憶部３３５に複数のパターンが記憶されている場合には、予め一つを選択する。負荷取得部１１０にて取得された負荷の測定値はＷｉ、パターン記憶部３３５において記憶されたパターンに含まれる負荷の値はＬｉとして表されるとする。また、負荷取得部１１０にて取得された負荷の測定値及び負荷の上昇を表すパターンのそれぞれにｎ個の値が含まれているとする。この場合に、類似度判定部３３４は、類似度Ｒを例えば以下の（２）式を用いて求める。
【０１０６】
【数２】
2017013872.tif 000004
類似度Ｒが求められると、類似度判定部３３４は、求められた類似度Ｒが類似の程度に関する条件を満たすかを判定する。一例として、類似度判定部３３４は、求められた類似度Ｒと類似度に関する閾値Ｒ０との比較を行う。Ｒ＜Ｒ０との条件を満たす（すなわち、類似度Ｒの大きさが閾値Ｒ０よりも小さい）場合には、類似度判定部３３４は、負荷取得部１１０にて取得された負荷の時間的な変化の様子が類似すると判定する。すなわち、類似度判定部３３４は、負荷が上昇傾向にあると判定する。そして、類似度判定部３３４は、タスクに対するリソースの割当てを決定する。リソース割当部１４０は、当該決定に応じて、タスクに対してリソースを割当てる。
【０１０７】
また、Ｒ＜Ｒ０との条件を満たさない（すなわち、類似度Ｒの大きさが閾値Ｒ０以上である）場合には、類似度判定部３３４は、負荷取得部１１０にて取得された負荷の時間的な変化の様子が比較対象とされたパターンと異なると判定する。この場合には、類似度判定部３３４は、パターン記憶部３３５に記憶された他のパターンを選択して、再び類似度Ｒを求める。パターン記憶部３３５に記憶された全てのパターンについてＲ＜Ｒ０との条件を満たさない場合には、その時点での負荷の傾向がいずれのパターンにも類似しないことが想定される。この場合には、類似度判定部３３４は、負荷が上昇傾向にないと判定する。
【０１０８】
続いて、図１２に示すフローチャートを参照して、本発明の第３の実施形態におけるリソース割当システム３００の動作の一例について説明する。
【０１０９】
最初に、負荷取得部１１０は、タスクを実行するサーバの負荷に関する情報を取得する（ステップＳ３０１）。次に、緊急度判定部１２０は、緊急度を求める（ステップＳ３０２）。続いて、緊急度判定部１２０は、緊急度が第１の条件を満たすかを判定する（ステップＳ３０３）。
【０１１０】
緊急度が第１の条件を満たす場合（ステップＳ３０３：Ｙｅｓ）には、緊急度判定部１２０は、タスクに対するリソースの割当てを決定する。この決定に応じて、リソース割当部１４０は、プロセッサコア等のリソースをタスクに対して割当てる（ステップＳ３０４）。
【０１１１】
緊急度判定部１２０は、緊急度が先に説明した第１の条件を満たさない場合（ステップＳ３０３：Ｎｏ）に、緊急度が先に説明した第２の条件を満たすかを判定する（ステップＳ３０５）。緊急度が第２の条件を満たす（ステップＳ３０５：Ｙｅｓ）場合には、パターン照合部３３３は、負荷の時間的な変化の様子とパターンとの照合を行う（ステップＳ３０６）。
【０１１２】
なお、負荷取得部１１０が定期的にサーバの負荷に関する情報を取得する場合には、リソース割当システム３００は、図１２に示すフローチャートの動作を繰り返して行ってもよい。
【０１１３】
図１３は、パターン照合部３３３が負荷傾向を判定する場合における動作を示すフローチャートである。上述のステップＳ３０６においてパターン照合部３３３がパターンの照合を行う場合には、パターン照合部３３３は、次のように動作する。なお、この動作例において、パターン照合部３３３は、図９に示す構成を有することを想定する。
【０１１４】
最初に、類似度判定部３３４は、パターン記憶部３３５に記憶されたパターンの一つを選択して読み出す（ステップＳ３５１）。続いて、類似度判定部３３４は、上述した（２）式などを用いて、計測された負荷のステップＳ３５１で読み出されたパターンとの類似度を求める（ステップＳ３５２）。
【０１１５】
類似度が求められると、類似度判定部３３４は、求められた類似度Ｒが類似の程度に関する条件を満たすかを判定する（ステップＳ３５３）。すなわち、類似度判定部３３４は、類似度Ｒと閾値Ｒ０との比較を行う。類似度Ｒ及び閾値Ｒ０がＲ＜Ｒ０との条件を満たす場合（ステップＳ３５３：Ｙｅｓ）には、類似度判定部３３４は、タスクに対するリソースの割当てを決定する。この決定に応じて、リソース割当部１４０は、プロセッサコア等のリソースをタスクに対して割当てる（ステップＳ３５４）。
【０１１６】
類似度Ｒ及び閾値Ｒ０がＲ＜Ｒ０との条件を満たさない場合（ステップＳ３５３：Ｎｏ）には、類似度判定部３３４は、ステップＳ３５５の処理を行う。ステップＳ３５５においては、類似度判定部３３４は、パターン記憶部３３５に記憶された全てのパターンに対してステップＳ３５２の処理において類似度を求めて閾値との比較を行ったかを判定する。
【０１１７】
パターン記憶部３３５に記憶された全てのパターンに対して類似度Ｒが類似の程度に関する条件を満たさないと判定された場合（ステップＳ３５５：Ｙｅｓ）には、類似度判定部３３４は、負荷が上昇の傾向にないと判定する。この場合には、類似度判定部３３４は、処理を終了する。
【０１１８】
パターン記憶部３３５に記憶された全てのパターンに対して既に類似度の導出等を行っていない場合（ステップＳ３５５：Ｎｏ）には、類似度判定部３３４は、ステップＳ３５１に戻って処理を継続して行う。すなわち、類似度判定部３３４は、ステップＳ３５１においてパターン記憶部３３５に記憶された他のパターンを選択して、処理を継続する。
【０１１９】
以上のとおり、本発明の第３の実施形態におけるリソース割当システム３００は、第１の実施形態におけるリソース割当システム１００と同様に、緊急度判定部１２０にて求められた緊急度に応じてリソースの割当てを行う。緊急度が高いと判定される場合には、リソース割当システム２００は、更なる判定を行わずにリソースの割当てを行う。緊急度が、タスクに対してリソースを割当てる程度の高さではないと判定される場合には、リソース割当システム２００は、負荷の時間的な変化の様子が負荷の上昇を表すパターンと類似するかを判定して、更に負荷の傾向を判定する。そして、負荷が上昇する傾向にあると判定された場合には、リソース割当システム１００は、リソースの割当てを行う。
【０１２０】
すなわち、本実施形態におけるリソース割当システム３００は、第１の実施形態におけるリソース割当システム１００と同様の効果を奏する。また、リソース割当システム３００は、緊急度の高さが中程度である場合に、負荷の時間的な変化の様子が負荷の上昇を表すパターンと類似するかを判定する。そのため、リソース割当システム３００は、種々の負荷上昇のパターンに基づいて、負荷が増加傾向にあることを判定することができる。
【０１２１】
したがって、本実施形態におけるリソース割当システム３００は、第１の実施形態におけるリソース割当システム１００と比較して、更に適切に負荷の変動に応じたリソースの割当てを可能にする。
【０１２２】
（第４の実施形態）
次に、本発明の第４の実施形態について説明する。図１４は、本発明の第４の実施形態におけるリソース割当システムを示す図である。図１５は、本発明の第４の実施形態におけるリソース割当システムの動作の一例を示すフローチャートである。
【０１２３】
図１４に示すとおり、本発明の第４の実施形態におけるリソース割当システム４００は、負荷取得部１１０と、緊急度判定部４２０と、間隔調整部２３１と、傾向判定部２３２と、リソース割当部１４０とを備える。緊急度判定部４２０は、以下に説明がある箇所を除き、本発明の第２の実施形態におけるリソース割当システム２００が備える緊急度判定部１２０と基本的に同様の動作を行う。
【０１２４】
本実施形態においては、緊急度判定部４２０は、サーバの負荷の傾向を確認する必要があると判定する場合に、更に、その時点における緊急度の程度を判定する。具体的には、緊急度判定部４２０は、先に説明した第２の条件に相当し、緊急度の程度が異なる複数の条件のいずれを満たすかを判定する。また、間隔調整部２３１は、緊急度の程度が異なる複数の条件のそれぞれに基づいて、負荷取得部１１０による負荷に関する情報の取得間隔を変更する。それ以外の点については、本実施形態におけるリソース割当システム２００は、第１の実施形態におけるリソース割当システム１００と基本的に同様の構成を備える。
【０１２５】
続いて、本発明の第４の実施形態におけるリソース割当システム４００の各構成要素について説明する。
【０１２６】
本実施形態においては、負荷取得部１１０は、予め定められた間隔でタスクを実行するサーバの負荷に関する情報を取得する。また、この間隔は、間隔調整部２３１の指示に基づいて、予め定められた間隔よりも短い異なる間隔のいずれかに変更される場合がある。
【０１２７】
上述のように、緊急度判定部４２０は、サーバの負荷の傾向を更に確認する必要があると判定する場合に、更に、その時点における緊急度の程度を判定する。本実施形態では、一例として、緊急度判定部４２０は、サーバの負荷の傾向を更に確認する必要があると判定する場合に、緊急度の程度が異なる複数の条件を用いる。
【０１２８】
緊急度判定部４２０は、具体的には、緊急度が第１から第３の条件のいずれかを満たす場合に、サーバの負荷の傾向を更に確認する必要があると判定する。第２及び第３の条件は、タスクに対してリソースを割当てるべきか否かを更に判断する必要がある状態であることを示す条件である。また、第２及び第３の条件は、緊急度の程度が異なる条件である。本実施形態においては、第３の条件は、第２の条件と比較して緊急度の程度が低く、タスクに対するリソースの割当ての必要性が低いことを示す。なお、本実施形態においては、第１の条件は、上述した各実施形態における第１の条件と同様の条件となる。
【０１２９】
第２の実施形態における緊急度判定部１２０にて用いられる条件と同様に、第１から第３の条件のそれぞれは、緊急度として求められた値に対する閾値の形式で表される。例えば、緊急度Ｅが上述した（１）式にて求められる場合には、第１の条件に関する閾値としてＥ１が、第２の条件に関する閾値としてＥ２が、第３の条件に関する閾値としてＥ３が定められる。そして、緊急度判定部４２０は、緊急度がＥ１≦Ｅを満たす（すなわち、緊急度Ｅの大きさがＥ１以上である）場合に、緊急度が第１の条件を満たすと判定する。緊急度判定部４２０は、緊急度ＥがＥ２≦Ｅ＜Ｅ１を満たす（すなわち、緊急度Ｅの大きさがＥ２以上であり、かつ、Ｅ１よりも小さい）場合に、緊急度が第２の条件を満たすと判定する。また、緊急度判定部４２０は、緊急度がＥ３≦Ｅ＜Ｅ２を満たす（すなわち、緊急度Ｅの大きさがＥ３以上であり、かつ、Ｅ２よりも小さい）場合に、緊急度が第３の条件を満たすと判定する。緊急度がＥ＜Ｅ３を満たす（すなわち、緊急度の大きさがＥ３よりも小さい）場合には、緊急度判定部４２０は、緊急度がいずれの条件も満たさないと判定する。
【０１３０】
間隔調整部２３１は、緊急度判定部４２０において緊急度が第２又は第３の条件のいずれかを満たすと判定された場合に、負荷取得部１１０による負荷に関する情報の取得間隔を変更する。本実施形態においては、間隔調整部２３１は、緊急度が第２又は第３の条件のいずれかを満たすと判定された場合に、負荷取得部１１０による負荷に関する情報の取得間隔を通常の時間間隔と比較して短い時間間隔に設定する。
【０１３１】
例えば、間隔調整部２３１は、緊急度が第３の条件を満たす場合には、負荷取得部１１０による取得間隔を通常の時間間隔と比較して短い時間間隔に設定する。そして、間隔調整部２３１は、緊急度が第２の条件を満たす場合には、負荷取得部１１０による取得間隔を、緊急度が第３の条件を満たす場合における時間間隔と比較して更に短い時間間隔に設定する。
【０１３２】
すなわち、間隔調整部２３１は、タスクに対してリソースを割当てるべきか否かを更に判断する必要がある場合に、緊急度の高さに応じて時間間隔が短くなるように、負荷取得部１１０による負荷に関する情報の取得間隔を設定する。
【０１３３】
続いて、図１５に示すフローチャート参照して、本発明の第４の実施形態におけるリソース割当システム４００の動作の一例について説明する。
【０１３４】
最初に、負荷取得部１１０は、タスクを実行するサーバの負荷に関する情報を取得する（ステップＳ４０１）。次に、緊急度判定部４２０は、負荷取得部１１０における負荷に関する情報の取得間隔として、通常の時間間隔が設定されているかを判定する（ステップＳ４０２）。
【０１３５】
負荷取得部１１０に対して、負荷に関する情報の取得間隔として通常の時間間隔が設定されている場合（ステップＳ４０２：Ｙｅｓ）には、緊急度判定部４２０は、緊急度を求める（ステップＳ４０３）。そして、緊急度判定部４２０は、緊急度が第１の条件を満たすかを判定する（ステップＳ４０４）。
【０１３６】
ステップＳ４０３にて求めた緊急度が第１の条件を満たす場合（ステップＳ４０４：Ｙｅｓ）には、緊急度判定部４２０は、タスクに対するリソースの割当てを決定する。この決定に応じて、リソース割当部１４０は、プロセッサコア等のリソースをタスクに対して割当てる（ステップＳ４０５）。
【０１３７】
緊急度判定部４２０は、緊急度が先に説明した第１の条件を満たさない場合（ステップＳ４０４：Ｎｏ）に、緊急度が先に説明した第２の条件を満たすかを判定する（ステップＳ４０６）。緊急度が第２の条件を満たす（ステップＳ４０６：Ｙｅｓ）場合には、間隔調整部２３１は、負荷取得部１１０における負荷に関する情報の取得間隔を通常の時間間隔と比較して短い時間間隔とするように設定する（ステップＳ４０７）。
【０１３８】
また、負荷取得部１１０に対して、負荷に関する情報の取得間隔として通常の時間間隔が設定されていない場合（ステップＳ４０２：Ｎｏ）には、負荷に関する情報の取得間隔として、短い時間間隔が設定されていると想定される。この場合には、傾向判定部２３２は、負荷傾向を判定する（ステップＳ４０８）。
【０１３９】
なお、ステップＳ４０１からＳ４０８までの動作は、本発明の第２の実施形態におけるステップＳ２０１からＳ２０８までの各ステップとそれぞれ同様の動作を行う。また、ステップＳ４０８において、傾向判定部２３２は、図７に示すフローチャートに従って負荷傾向の判定を行う。
【０１４０】
更に、緊急度判定部４２０は、ステップＳ４０５において緊急度が第２の条件を満たさない（ステップＳ４０６：Ｎｏ）場合には、緊急度が先に説明した第３の条件を満たすかを判定する（ステップＳ４０９）。緊急度が第３の条件を満たす（ステップＳ４０９：Ｙｅｓ）場合には、間隔調整部２３１は、負荷取得部１１０における負荷に関する情報の取得間隔を通常の時間間隔と比較して短い時間間隔とするように設定する（ステップＳ４１０）。ステップＳ４１０において設定される時間間隔は、通常の時間間隔と比較して短く、かつ、ステップＳ４０７において設定される時間間隔と比較して長い間隔である。
【０１４１】
なお、負荷取得部１１０が定期的にサーバの負荷に関する情報を取得する場合には、リソース割当システム４００は、図１５に示すフローチャートの動作を繰り返し行ってもよい。
【０１４２】
以上のとおり、本発明の第４の実施形態におけるリソース割当システム４００は、第２の実施形態におけるリソース割当システム２００と同様に、負荷の測定間隔を短くして負荷の傾向を判定する。したがって、本実施形態におけるリソース割当システム４００は、第２の実施形態におけるリソース割当システム２００と同様の効果を奏する。
【０１４３】
更に、本実施形態におけるリソース割当システム４００では、緊急度判定部４２０が、サーバの負荷の傾向を更に確認する必要があると判断された場合に、緊急度の高さが異なる複数の条件を用いる。そして、負荷取得部１１０による負荷に関する情報の取得間隔を通常と比較して短い間隔に設定する場合に、緊急度判定部４２０にて求められた緊急度の高さに応じて時間間隔が短くなるように時間間隔を設定する。このようにすることで、傾向判定部２３２は、負荷が増加傾向にあることを早い段階で判定することが可能となる。
【０１４４】
したがって、本実施形態におけるリソース割当システム４００は、第２の実施形態におけるリソース割当システム２００等と比較して、更に適切に負荷の変動に応じたリソースの割当てを可能にする。
【０１４５】
なお、本実施形態においては、緊急度判定部４２０は、一例として緊急度が第１から第３の条件のいずれかを満たすか否かを判定した。そして、間隔調整部２３１は、第２又は第３の条件のうち、求められた緊急度が満たす条件に応じて、負荷取得部１１０による負荷に関する情報の取得間隔を変更した。しかしながら、緊急度判定部４２０は、緊急度の程度に関する更に多くの条件を用いてもよい。この場合には、間隔調整部２３１は、例えば、求められた緊急度が満たす条件に応じて、負荷取得部１１０による負荷に関する情報の取得間隔を変更する。
【０１４６】
（第５の実施形態）
次に、本発明の第５の実施形態について説明する。図１６は、本発明の第５の実施形態におけるリソース割当システムを示す図である。図１７は、本発明の第５の実施形態におけるリソース割当システムの動作の一例を示すフローチャートである。
【０１４７】
図１６に示すように、本発明の第５の実施形態におけるリソース割当システム５００は、負荷取得部１１０と、緊急度判定部５２０と、傾向判定部５３２と、間隔調整部５３１と、パターン照合部５３３と、リソース割当部１４０と、測定値記憶部１５０とを備える。
【０１４８】
本実施形態において、負荷取得部１１０及びリソース割当部１４０は、以下に説明がある箇所を除き、本発明の第１の実施形態におけるリソース割当システム１００が備える同じ構成要素と基本的に同様の動作を行う。また、緊急度判定部５２０は、以下に説明がある箇所を除き、本発明の第４の実施形態におけるリソース割当システム１００が備える緊急度判定部４２０と基本的に同様の動作を行う。傾向判定部５３２及び間隔調整部５３１は、以下に説明がある箇所を除き、基本的に、本発明の第２の実施形態におけるリソース割当システム１００が備える傾向判定部２３２及び間隔調整部２３１と同様の動作を行う。パターン照合部５３３は、以下に説明がある箇所を除き、基本的に、本発明の第３の実施形態におけるリソース割当システム３００が備えるパターン照合部３３３と同様の動作を行う。
【０１４９】
すなわち、本実施形態におけるリソース割当システム５００は、第２の実施形態における傾向判定部２３２及び間隔調整部２３１と、第３の実施形態におけるパターン照合部３３３とを共に備える点が上述した各実施形態と異なる。
【０１５０】
続いて、本発明の第５の実施形態におけるリソース割当システム５００の各構成要素について説明する。
【０１５１】
本実施形態においては、負荷取得部１１０は、予め定められた間隔でタスクを実行するサーバの負荷に関する情報を取得する。また、この間隔は、間隔調整部５３１の指示に基づいて変更される場合がある。
【０１５２】
緊急度判定部５２０は、第４の実施形態と同様に、タスクに対するリソースの割当てに関する必要性の判定として、緊急度が程度の異なる複数の条件のいずれかを満たすかを判定する。すなわち、緊急度判定部５２０は、緊急度が上述した第１から第３の条件のいずれかを満たすか否かを判定する。間隔調整部５３１、傾向判定部５３２及びパターン照合部５３３は、緊急度判定部５２０の判定に応じてリソースの割当てに関する動作を行う。
【０１５３】
間隔調整部５３１は、緊急度判定部５２０において緊急度が例えば上述した第３の条件を満たすと判定された場合に、負荷取得部１１０による負荷に関する情報の取得間隔を変更する。本実施形態においては、間隔調整部５３１は、緊急度が第２の条件を満たすと判定された場合に、負荷取得部１１０による負荷に関する情報の取得間隔を通常の時間間隔と比較して短い時間間隔に設定する。
【０１５４】
パターン照合部５３３は、緊急度判定部５２０において緊急度が例えば上述した第２の条件を満たすと判定された場合に、負荷の時間的な変化の様子が負荷の上昇を表す所定のパターンと類似するかを照合する。パターン照合部５３３は、具体的な一例として、本発明の第３の実施形態にて説明した構成を有する。
【０１５５】
すなわち、本実施形態におけるリソース割当システム５００は、サーバの負荷の傾向を確認する必要があると判断した場合に、緊急度の程度に応じて異なる手順でサーバの負荷の傾向の確認を行う。このようにすることで、リソース割当システム５００は、無用なリソースの割当てを抑制しつつ、負荷が上昇傾向にある場合に迅速なリソースの割当てを行うことができる。
【０１５６】
続いて、図１７に示すフローチャート参照して、本発明の第５の実施形態におけるリソース割当システム５００の動作の一例について説明する。
【０１５７】
最初に、負荷取得部１１０は、タスクを実行するサーバの負荷に関する情報を取得する（ステップＳ５０１）。次に、緊急度判定部５２０は、負荷取得部１１０における負荷に関する情報の取得間隔として、通常の時間間隔が設定されているかを判定する（ステップＳ５０２）。
【０１５８】
負荷取得部１１０に対して、負荷に関する情報の取得間隔として通常の時間間隔が設定されている場合（ステップＳ５０２：Ｙｅｓ）には、緊急度判定部５２０は、緊急度を求める（ステップＳ５０３）。そして、緊急度判定部５２０は、緊急度が第１の条件を満たすかを判定する（ステップＳ５０４）。
【０１５９】
ステップＳ５０３にて求めた緊急度が第１の条件を満たす場合（ステップＳ５０４：Ｙｅｓ）には、緊急度判定部５２０は、タスクに対するリソースの割当てを決定する。この決定に応じて、リソース割当部１４０は、プロセッサコア等のリソースをタスクに対して割当てる（ステップＳ５０５）。
【０１６０】
なお、ステップＳ５０１からＳ５０５までの各々では、本発明の第４の実施形態におけるステップＳ４０１からＳ４０５までの各々と同様の動作が行われる。
緊急度判定部５２０は、緊急度が先に説明した第１の条件を満たさない場合（ステップＳ５０４：Ｎｏ）に、緊急度が先に説明した第２の条件を満たすかを判定する（ステップＳ５０６）。緊急度が第２の条件を満たす（ステップＳ５０６：Ｙｅｓ）場合には、パターン照合部５３３は、負荷の時間的な変化の様子とパターンとの照合を行う（ステップＳ５０７）。
【０１６１】
なお、ステップＳ５０６では、本発明の第４の実施形態におけるステップＳ４０６と同様の動作が行われる。また、ステップＳ５０７では、本発明の第３の実施形態におけるステップＳ３０６と同様の動作が行われる。すなわち、パターン照合部５３３は、先に第３の実施形態において図１３に示すフローチャートを用いて説明した動作を行う。ステップＳ５０７における処理が行われると、リソース割当システム５００は、動作を終了する。
【０１６２】
パターン照合部５３３は、測定値記憶部１５０に記憶されている測定値を参照する等して、新たに負荷に関する情報を取得せずにパターンの照合を行うことが可能である。したがって、パターン照合部５３３は、必要な場合に迅速にリソースの割当てを行うことができる。
【０１６３】
続いて、緊急度判定部５２０は、ステップＳ５０６において緊急度が第２の条件を満たさない（ステップＳ５０６：Ｎｏ）場合には、緊急度が先に説明した第３の条件を満たすかを判定する（ステップＳ５０８）。緊急度が第３の条件を満たす（ステップＳ５０８：Ｙｅｓ）場合には、間隔調整部５３１は、負荷取得部１１０における負荷に関する情報の取得間隔を、通常の時間間隔と比較して短い時間間隔に設定する（ステップＳ５０９）。ステップＳ５０９では、第２の実施形態におけるステップＳ２０７等と同様の動作が行われる。ステップＳ５０９における処理が行われると、リソース割当システム５００は、動作を終了する。
【０１６４】
なお、緊急度判定部５２０において緊急度に関するいずれの条件も満たさないと判定された場合（ステップＳ５０８：Ｎｏ）には、リソース割当システム５００は、動作を終了する。
【０１６５】
また、負荷取得部１１０に対して、負荷に関する情報の取得間隔として通常の時間間隔が設定されていない場合（ステップＳ５０２：Ｎｏ）には、負荷に関する情報の取得間隔として、短い時間間隔が設定されていると想定される。この場合には、傾向判定部５３２は、負荷傾向を判定する（ステップＳ５１０）。また、ステップＳ５１０において、傾向判定部５３２は、図７に示すフローチャートに従って負荷傾向の判定を行う。ステップＳ５１０における処理が行われると、リソース割当システム５００は、動作を終了する。
【０１６６】
なお、負荷取得部１１０が定期的にサーバの負荷に関する情報を取得する場合には、リソース割当システム５００は、図１７に示すフローチャートの動作を繰り返し実行してもよい。
【０１６７】
以上のとおり、本発明の第５の実施形態におけるリソース割当システム５００は、間隔調整部５３１と、傾向判定部５３２と、パターン照合部５３３とを備える。したがって、本実施形態におけるリソース割当システム５００は、第２の実施形態におけるリソース割当システム２００及び第３の実施形態におけるリソース割当システム３００の各々と同様の効果を奏する。
【０１６８】
また、本実施形態におけるリソース割当システム５００では、サーバの負荷の傾向を更に確認する必要があると判断された場合に、負荷の傾向を異なる手段を用いて確認することが可能となる。
【０１６９】
すなわち、パターン照合部５３３が、測定値記憶部１５０に記憶された負荷とパターンとを照合して負荷の傾向を判断することで、負荷の傾向が迅速に判断される。また、本実施形態においては、サーバの負荷の傾向を確認する必要があると判定され、かつ、緊急度の程度が相対的に高い場合に、上述したパターンの照合が行われる。したがって、負荷が増加の傾向にある場合に、迅速なリソースの割当てが可能となる。
【０１７０】
また、間隔調整部５３１及び傾向判定部５３２が、新たに負荷取得部１１０にて通常と比較して短い間隔で取得された負荷を用いて負荷の傾向を判断することで、負荷の傾向が正確に判断される。また、本実施形態においては、サーバの負荷の傾向を確認する必要があると判定され、かつ、緊急度の程度が相対的に低い場合に、上述した短い間隔で取得された負荷を用いて負荷の傾向が判断される。したがって、負荷が増加の傾向にある場合に、適切なリソースの割当てが行われる。
【０１７１】
したがって、本実施形態におけるリソース割当システム５００は、他の実施形態と比較して更に高い精度で負荷の変動に応じた適切なリソースの割当てを可能にする。
【０１７２】
（実施例１）
次に、本発明の各実施形態におけるリソース割当システムを用いたリソース割当の例を説明する。最初に、本発明の第２の実施形態におけるリソース割当システム２００を用いたリソース割当の例を説明する。図１８は、実施例１におけるリソース割当システムとタスク実行サーバの構成を示す図である。
【０１７３】
本実施例においては、リソース割当システム２００と、リソースの割当ての対象となるタスクが実行されるタスク実行サーバ１１は、図１８のように通信ネットワーク１２を介して接続される。
【０１７４】
タスク実行サーバ１１は、例えば、図２８に示す上述した情報処理装置１０００である。タスク実行サーバ１１においては、タスクとして、他のサーバ等からの要求に応じた処理を行うプログラムが実行される。プログラムは、例えば情報処理装置１０００の記憶装置１００５に記憶されており、プログラムの実行に際して記憶装置１００５から読み出されてＲＡＭ１００３に展開される。また、タスク実行サーバ１１は、外部通信ネットワーク１３を介して他のサーバ等と接続する。
【０１７５】
本実施例では、タスク実行サーバ１１は、複数のＣＰＵを備える。または、タスク実行サーバ１１は、ＣＰＵとして、複数のプロセッサコアを有するマルチコアプロセッサを備えてもよい。上述したプログラムは、当初は、複数のＣＰＵのうちの一つのＣＰＵ（又は一つのプロセッサコア）によって実行されることを想定する。
【０１７６】
また、本実施例においては、リソース割当システム２００は、図２８に示す上述した情報処理装置１０００にて実行されるプログラムとして実現される。リソース割当システム２００とタスク実行サーバ１１は、通信ネットワーク１２を介して接続される。リソース割当システム２００（を実現するプログラム）は、タスク実行サーバ１１における負荷に関する情報を、当該通信ネットワーク１２を介して取得する。
【０１７７】
測定値記憶部１５０は、情報処理装置１０００の記憶装置１００５に保持されるリレーショナルデータベース（Ｒｅｌａｔｉｏｎａｌ  Ｄａｔａｂａｓｅ、以下「ＲＤＢ」とする）のテーブルとして実現される。ＲＤＢのテーブルには、属性として、負荷の測定時刻、当該測定時刻におけるＣＰＵ負荷、及び当該測定時刻とその前の測定時刻との測定時刻の間隔が含まれる。負荷取得部１１０による負荷に関する情報の取得間隔は、予めＲＡＭ１００３に保持される。
【０１７８】
本実施例において、負荷取得部１１０は、通常の時間間隔を５秒、短い時間間隔を１秒として負荷を取得する。取得した負荷に関する情報は、測定が行われる度に、測定値記憶部１５０となるＲＤＢを構成するテーブルのレコードとして記録される。測定値記憶部１５０に含まれるテーブルの属性である測定時刻にはインデックスが付されており、値の探索又は整列が高速に行われる。
【０１７９】
本実施例においては、緊急度判定部１２０は、具体的には、緊急度Ｅを以下の（３）式を用いて求める。（３）式は、上述した（１）式において、ａを１．０、ｂを０．５とした式である。
【０１８０】
【数３】
2017013872.tif 000005
なお、Ｗ及びΔＷは、（１）式における同様の記号と同様の意味である。“＊”は、乗算を表す記号である。また、緊急度判定部１２０は、緊急度が６０を超える場合に、緊急度が第２の条件を満たすと判定する。緊急度判定部１２０は、緊急度が９０を超える場合に、緊急度が第１の条件を満たすと判定する。
【０１８１】
傾向判定部２３２は、緊急度が第１の条件を満たし、短い時間間隔にて負荷が取得される場合において、負荷が続けて３回増加すると、負荷が増加傾向にあるとしてタスクに対してリソースを割当てると判定する。また、この場合に、傾向判定部２３２は、負荷が続けて３回減少すると、負荷が減少傾向にあるとしてタスクに対してリソースを割当てないと判定する。
【０１８２】
図１９は、負荷取得部１１０にて取得された負荷に関する情報と、当該負荷に対して求められた緊急度の例を示す表である。図１９において、負荷に関する情報はＣＰＵの負荷を示す。また、図２０は、図１９に示す負荷について、横軸を測定時刻とし、縦軸を負荷として表したグラフである。図１９に示す例において、時刻５：４２：４０（「５：４２：４０」は、５時４２分４０秒を表す。以下、同様に時刻を表す）における緊急度は、時刻５：４２：４０における負荷の値である２７と、時刻５：４２：３５における負荷の値である２５とを用いて次のように求められる。
【０１８３】
【数４】
2017013872.tif 000006
この時刻においては、緊急度は、上述した第１及び第２のいずれの条件も満たさない。したがって、緊急度判定部１２０は、リソースの割当て等に関する特段の処理を行わず、次の測定結果に対して緊急度の導出及び緊急度の判定を行う。同様に、時刻５：４２：５５までの各々の時刻にて計測された負荷に基づき求められた緊急度は、いずれも上述した第１及び第２のいずれの条件も満たさない。したがって、緊急度判定部１２０は、リソースの割当て等に関する特段の処理を行わない。
【０１８４】
一方、時刻５：４３：００において、緊急度判定部１２０が、当該時刻と時刻５：４２：５５にて計測された負荷に基づいて緊急度を計算すると、緊急度は１００と求められる。すなわち、緊急度は、上述した第１の条件を満たす。この場合には、緊急度判定部１２０は、タスクに対しリソースを割当てる旨を決定する。この決定に応じて、リソース割当部１４０は、タスクに対してリソースとしてＣＰＵ（又はプロセッサコア）を割当てる。すなわち、リソースの割当ての対象となるタスクは、二つのＣＰＵ（又はプロセッサコア）を用いて実行される。
【０１８５】
図２１は、負荷取得部１１０にて取得された負荷に関する情報と、当該負荷に対して求められた緊急度の別の例を示す表である。図２１において、負荷に関する情報は、ＣＰＵの負荷を示す。また、図２２は、図２１に示す負荷について、横軸を測定時刻とし、縦軸を負荷として表したグラフである。
【０１８６】
図２１に示す表は、図１８に示すリソース割当システム２００において、図１９の表が示す負荷とは異なる時刻に取得された負荷等の情報を示す。図２１に示す表において、緊急度は、先に説明した（３）式を用いて緊急度を求められている。
【０１８７】
図２１に示す表の例では、時刻７：１２：２０及び時刻７：１２：２５に求められた緊急度の各々は、第１及び第２の条件のいずれも満たさない。そして、時刻７：１２：３０に取得された負荷に基づいて求められた緊急度は、上述した第２の条件を満たす。したがって、間隔調整部２３１は、負荷取得部１１０による負荷の取得の間隔を短い時間間隔に変更する。
【０１８８】
負荷取得部１１０は、この場合に、１秒間隔で負荷に関する情報を取得する。しかしながら、１秒間隔で負荷が取得される時刻７：１２：３１以降の３つの時点の各時刻において取得された負荷は、いずれもその直前に取得された負荷と比較して小さな値である。すなわち、負荷が続けて３回減少している。
【０１８９】
したがって、傾向判定部２３２は、負荷が減少傾向にあるとして、タスクに対してリソースを割当てないと判定する。そして、この判定に基づいて、間隔調整部２３１は、負荷の測定間隔を通常の間隔に変更する。
【０１９０】
図２３は、負荷取得部１１０にて取得された負荷に関する情報と、当該負荷に対して求められた緊急度の更に別の例を示す表である。図２３において、負荷に関する情報は、ＣＰＵの負荷を示す。また、図２４は、図２３に示す負荷について、横軸を測定時刻とし、縦軸を負荷として表したグラフである。
【０１９１】
図２３に示す表は、図１８に示すリソース割当システム２００において、図１９又は図２３の表が示す負荷とは異なる時刻に取得された負荷等の情報を示す。図２３に示す表においては、緊急度は、先に説明した（３）式を用いて緊急度を求められている。
【０１９２】
図２３に示す表の例では、時刻８：２５：２０及び時刻８：２５：２５に求められた緊急度の各々は、第１及び第２の条件のいずれも満たさない。そして、時刻８：２５：３０に取得された負荷に基づいて求められた緊急度は、上述した第２の条件を満たす。したがって、間隔調整部２３１は、負荷取得部１１０による負荷の取得の間隔を短い時間間隔に変更する。
【０１９３】
負荷取得部１１０は、この場合に、１秒間隔で負荷に関する情報を取得する。そして、１秒間隔で負荷が取得される時刻８：２５：３１以降の３つの時点の各時刻において取得された負荷は、いずれもその直前に取得された負荷と比較して大きな値である。すなわち、負荷が続けて３回増加している。
【０１９４】
したがって、傾向判定部２３２は、負荷が増加傾向にあるとして、タスクに対してリソースを割当てると判定する。そして、この判定に基づいて、傾向判定部２３２は、タスクに対するリソースの割当てを決定する。この決定に応じて、リソース割当部１４０は、タスクに対してリソースとしてＣＰＵ（又はプロセッサコア）を割当てる。すなわち、リソースの割当ての対象となるタスクは、二つのＣＰＵ（又はプロセッサコア）を用いて実行される。また、間隔調整部２３１は、リソース割当部１４０によるリソースの割当てが行われると、負荷の測定間隔を通常の間隔に変更する。
【０１９５】
このように、本実施例においては、リソース割当システム２００によって、緊急度が第１の条件を満たすと判定された場合に速やかにタスクに対してリソースの割当てが行われた。また、緊急度が第２の条件を満たすと判定された場合には、負荷の測定の間隔を短い時間間隔に設定された。そして、負荷が増加傾向にある場合に、タスクに対してリソースの割当てが行われた。
【０１９６】
すなわち、リソース割当システム２００によって、負荷の変動に応じた適切なリソースの割当てが行われる。
【０１９７】
（実施例２）
次に、本発明の各実施形態におけるリソース割当システムを用いたリソース割当の別の例を説明する。最初に、本発明の第３の実施形態におけるリソース割当システム３００を用いたリソース割当の例を説明する。
【０１９８】
本実施例においては、リソース割当システム３００と、リソースの割当ての対象となるタスクが実行されるタスク実行サーバ１１は、図２５のように通信ネットワークを介して接続される。タスク実行サーバ１１は、先に説明した実施例１の場合と同様に、例えば、図２８に示す上述した情報処理装置１０００である。
また、実施例１の倍と同様に、タスク実行サーバ１１は、複数のＣＰＵ（又は複数のプロセッサコア）を備えていることを想定する。そして、タスク実行サーバにて実行されるプログラムは、当初は、複数のＣＰＵのうち、一つのＣＰＵ（又は一つのプロセッサコア）によって実行されることを想定する。
【０１９９】
また、本実施例においては、リソース割当システム３００は、第１の実施例において説明したリソース割当システム２００と同様に、図２８に示す上述した情報処理装置１０００にて実行されるプログラムとして実現される。パターン照合部３３３のパターン記憶部３３５は、情報処理装置１０００の記憶装置１００５に保持されるＲＤＢのテーブルとして実現される。図２６は、パターン記憶部３３５に記憶されるパターンの例である。パターン記憶部３３５は、５つのパターンを記憶する。また、パターンの各々は、１０個の負荷を含む。本実施例では、負荷は、５秒毎の負荷の変動を表す。
【０２００】
本実施例においては、負荷取得部１１０は、負荷に関する情報を５秒間隔にて取得する。また、緊急度判定部１２０は、具体的には、緊急度Ｅを上述した（３）式を用いて求める。また、緊急度判定部１２０は、緊急度が６０を超える場合に、緊急度が第２の条件を満たすと判定する。緊急度判定部１２０は、緊急度が９０を超える場合に、緊急度が第１の条件を満たすと判定する。測定値記憶部１５０は、負荷取得部１１０にて取得された負荷と、上述したパターン記憶部３３５に記憶されるパターンとの比較を可能にするよう、直近に取得された負荷から少なくとも１０回分の負荷を記憶する。パターン照合部３３３の類似度判定部３３４は、類似度に関する閾値Ｒ０を１．０とする。
【０２０１】
図２７は、負荷取得部１１０にて取得された負荷に関する情報と、当該負荷に対して求められた緊急度の例を示す表である。図２７において、負荷に関する情報は、ＣＰＵの負荷を示す。
【０２０２】
図２７に示す表の例では、時刻９：５３：４０以降の各々の時刻において負荷が取得された場合に、緊急度判定部１２０は緊急度を求める。時刻９：５４：２０以前の時刻においては、緊急度は第１及び第２の条件のいずれも満たさない。そして、時刻９：５４：２５において、緊急度判定部１２０が、緊急度を計算すると、緊急度は８２．０と求められる。すなわち、緊急度は第２の条件を満たす。
【０２０３】
そこで、類似度判定部３３４は、負荷の時間的な変化の様子とパターンとの照合を行う。すなわち、類似度判定部３３４は、時刻９：５３：４０から時刻９：５４：２５までに計測された負荷と、図２６に示すパターンの各々との類似度を求める。ＩＤが１のパターンとの類似度は、上述した（２）式を用いて、以下に示す計算式に沿って求められる。
2017013872.tif 000007
【０２０４】
すなわち、ＩＤが１のパターンとの類似度は４．３である。同様に、ＩＤが２のパターンとの類似度は２．７、ＩＤが３のパターンとの類似度は２．０、ＩＤが４のパターンとの類似度は２．９、ＩＤが５のパターンとの類似度は０．８と求められる。そして、ＩＤが５のパターンに関して求められた類似度は、上述した閾値Ｒ０の値である１．０よりも小さい。したがって、類似度判定部３３４は、負荷が増加傾向にあると判定する。
【０２０５】
そこで、類似度判定部３３４は、タスクに対するリソースの割当てを決定する。当該決定に応じて、リソース割当部１４０は、タスクに対してリソースとしてＣＰＵ（又はプロセッサコア）を割当てる。すなわち、リソースの割当ての対象となるタスクは、二つのＣＰＵ（又はプロセッサコア）を用いて実行される。
【０２０６】
すなわち、本実施形態においても、リソース割当システム３００によって、負荷の変動に応じた適切なリソースの割当てが行われる。
【０２０７】
以上、実施形態及び実施例を参照して本発明を説明したが、本発明は上記実施形態及び実施例に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。また、各実施形態における構成は、本発明のスコープを逸脱しない限りにおいて、互いに組み合わせることが可能である。
【０２０８】
この出願は、２０１５年７月２１日に出願された日本出願特願２０１５−１４４００３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【０２０９】
１１    タスク実行サーバ
１２    通信ネットワーク
１３    外部通信ネットワーク
１００、２００、３００、４００、５００    リソース割当システム
１１０    負荷取得部
１２０、４２０、５２０    緊急度判定部
１３０    負荷判定部
２３１、５３１    間隔調整部
２３２、５３２    傾向判定部
３３３、５３３    パターン照合部
３３４    類似度判定部
３３５    パターン記憶部
１４０    リソース割当部
１５０    測定値記憶部
１０００    情報処理装置
１００１    ＣＰＵ
１００２    ＲＯＭ
１００３    ＲＡＭ
１００４    プログラム
１００５    記憶装置
１００６    記憶媒体
１００７    ドライブ装置
１００８    通信インターフェース
１００９    通信ネットワーク
１０１０    入出力インターフェース
１０１１    バス
【図１】
2017013872.tif 000008
【図２】
2017013872.tif 000009
【図３】
2017013872.tif 000010
【図４】
2017013872.tif 000011
【図５】
2017013872.tif 000012
【図６】
2017013872.tif 000013
【図７】
2017013872.tif 000014
【図８】
2017013872.tif 000015
【図９】
2017013872.tif 000016
【図１０】
2017013872.tif 000017
【図１１】
2017013872.tif 000018
【図１２】
2017013872.tif 000019
【図１３】
2017013872.tif 000020
【図１４】
2017013872.tif 000021
【図１５】
2017013872.tif 000022
【図１６】
2017013872.tif 000023
【図１７】
2017013872.tif 000024
【図１８】
2017013872.tif 000025
【図１９】
2017013872.tif 000026
【図２０】
2017013872.tif 000027
【図２１】
2017013872.tif 000028
【図２２】
2017013872.tif 000029
【図２３】
2017013872.tif 000030
【図２４】
2017013872.tif 000031
【図２５】
2017013872.tif 000032
【図２６】
2017013872.tif 000033
【図２７】
2017013872.tif 000034
【図２８】
2017013872.tif 000035
【手続補正書】
【提出日】平成30年1月5日(2018.1.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
タスクを実行するサーバの負荷に関する情報を取得する負荷取得手段と、
前記負荷に関する情報に基づいて、前記タスクに対するリソースの割当てに関する必要性を判定する緊急度判定手段と、
前記緊急度判定手段が前記サーバの負荷の傾向を確認する必要があると判定した場合に、前記サーバの負荷の傾向を判定する負荷判定手段と、
前記緊急度判定手段が前記タスクにリソースを割当てる必要があると判定した場合に、前記タスクに前記リソースを割当てるリソース割当手段とを備える、リソース割当システム。
【請求項２】
前記負荷取得手段による前記情報の取得間隔を変更する間隔調整手段を備える、請求項１に記載のリソース割当システム。
【請求項３】
前記間隔調整手段は、前記緊急度判定手段が前記サーバの負荷の傾向を確認する必要があると判定した場合に、前記情報の取得間隔をそれまでより短い時間間隔に変更する、請求項２に記載のリソース割当システム。
【請求項４】
前記間隔調整手段は、前記緊急度判定手段が前記サーバの負荷の傾向を確認する必要があると判定した場合に、前記情報の取得間隔を、前記情報を用いて求められる緊急度の程度に応じて異なる短い時間間隔に変更する、請求項２に記載のリソース割当システム。
【請求項５】
前記負荷判定手段は、前記情報の取得間隔が所定の取得間隔と比較して短くされている場合に、前記サーバの負荷の傾向を判定する、請求項３又は４に記載のリソース割当システム。
【請求項６】
前記負荷判定手段は、前記負荷取得手段において取得された前記情報が、所定の回数に亘って前記サーバの負荷の増加を示す場合に、前記サーバの負荷が増加傾向にあると判定する、請求項５に記載のリソース割当システム。
【請求項７】
前記負荷判定手段は、前記サーバの負荷の時間的な変化の様子が所定のパターンと類似するか否かを判定することで、前記サーバの負荷の傾向を判定する、請求項１から６のいずれか一項に記載のリソース割当システム。
【請求項８】
前記リソース割当手段は、前記負荷が増加傾向にあると前記負荷判定手段が判定した場合に前記タスクに前記リソースを割当てる、請求項１から７のいずれか一項に記載のリソース割当システム。
【請求項９】
タスクを実行するサーバの負荷に関する情報を取得し、
前記負荷に関する情報を用いて求められる緊急度に基づいて、前記タスクに対するリソースの割当てに関する必要性を判定し、
前記必要性として、前記サーバの負荷の傾向を確認する必要があると判定された場合に、前記サーバの負荷の傾向を判定し、
前記必要性として、前記緊急度判定手段が前記タスクにリソースを割当てる必要があると判定された場合に、前記タスクに前記リソースを割当てる、リソース割当方法。
【請求項１０】
コンピュータに、
タスクを実行するサーバの負荷に関する情報を取得する処理と、
前記負荷に関する情報を用いて求められる緊急度に基づいて、前記タスクに対するリソースの割当てに関する必要性を判定する処理と、
前記必要性の判定において、前記サーバの負荷の傾向を確認する必要があると判定された場合に、前記サーバの負荷の傾向を判定する処理と、
前記必要性の判定において、前記タスクにリソースを割当てる必要があると判定された場合に、前記タスクに前記リソースを割当てる処理とを実行させるプログラム。
【国際調査報告】
2017013872.tif 000036
2017013872.tif 000037