(57)【要約】【課題】  コンピュータリソースの共用において、同業などの動向を考慮したリソース配分を行う。【解決手段】  予め各利用主体毎に、当該利用主体のリソース配分の変更を行う条件および自身が所属するグループ内の他の利用主体のリソース配分の変更に従うかを示す従属情報を記録しておく。そして、予め決められたトリガ（例：定期的、管理者や利用主体の指定）に応じて、任意のグループの利用主体のうち、従属しない利用主体について、上記条件を満たすかを判断する。この結果、満たす場合は、同じグループ内の従属する利用主体についても変更すると判断する。この場合、各従属しない利用主体について、上記条件を満たさない場合に、上記条件を満たすかを判断するものである。なお、従属しない利用主体に関し、上記条件を満たすこと判断された場合、他の従属しない利用主体についても変更すると判断する。【選択図】  図１
2014081858.tif 000002
【特許請求の範囲】
【請求項１】
複数の利用主体でコンピュータリソースを共有する場合の自律型リソース配分方法において、
予め各利用主体毎に、当該利用主体のリソースの配分を変更する際の条件および自身が所属するグループ内の他の利用主体のリソース増強に従うかを示す従属情報を記録しておき、所定のトリガに応じて、任意のグループの利用主体のうち、従属しない利用主体について、上記条件を満たすかを判断し、前記判断の結果、従属しない利用主体のうち少なくとも１つが満たす場合は、前記任意グループ内の従属する利用主体について、リソース配分を変更すると判定し、前記判断の結果、各従属しない利用主体のいずれもが前記条件を満たさない場合に、前記従属する利用主体のそれぞれについて、条件を満たすかを判断し、当該判断の結果、上記条件を満たすこと判断された場合、他の従属しない利用主体について変更すると判定し、前記変更する判定された利用主体について、前記リソース配分を変更することを特徴とする自律型リソース配分方法。
【請求項２】
請求項１に記載の自律型リソース配分方法において、
前記従属する利用主体のそれぞれについての条件を満たすかを判断は、当該判断の処理負荷が少ない利用主体の条件から順に実行することを特徴とする自律型リソース配分方法。
【請求項３】
請求項２に記載の自律型リソース配分方法において、
前記処理負荷が少ない順とは、予め設定された当該条件を構成するパラメータの数の少ない順もしくは前記条件のロジックの簡便さの順であることを特徴とする自律型リソース配分方法。
【請求項４】
請求項１に記載の自律型リソース配分方法において、
前記従属する利用主体のそれぞれについての条件を満たすかを判断は、前記条件の満たし易い条件から順に実行することを特徴とする自律型リソース配分方法。
【請求項５】
請求項４に記載の自律型リソース配分方法において、
前記条件の満たし易さは、当該条件に対応する過去の判断処理の履歴データに基づいて決定することを特徴とする自律型リソース配分方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の利用主体に対してコンピュータリソースを提供する場合に、その状況に応じて、提供内容を変更（増強）するための技術に関する。
【背景技術】
【０００２】
現在、データセンタ等において、複数の利用主体に対してコンピュータリソースを提供するサービスが行われている(例えば、クラウドコンピューティングと称して)。このような場合、各利用主体と提供者側は、利用できる範囲（SLA）を特定し、その範囲でコンピュータリソースの利用が可能になっている。この際、通常利用できる内容と、何らかの理由で「増強」が必要になった場合の利用内容を変更することも行われている。例えば、特許文献１では、待機系でも現行系と同じ内容のリソースを用意しているため、サービス毎に待機系を維持しなければならなかった問題を解決するための技術が開示されている。その内容は、複数のサービス間で余剰のリソースを融通しあうために、リソーススケジュールの精度を高める技術が開示されている。その内容は、アプリケーションがインストールされていないデッドスタンドバイ状態であるコンピュータリソースを、複数サービスないし利用主体で共有し、また、個々のサービスの稼動履歴を用いて負荷予測を行っている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−１４１６０５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ここで、複数の利用主体によりコンピュータリソースの利用（提供）においては、同業などの特定のグループが共有していることが多い。このような場合、ある利用主体がリソースの増強を必要とする場合、同じグループの利用主体も増強を希望する場合が多い。しかしながら、特許文献１では、この点に関する考慮はされていない。そこで、本発明では、グループの動向も考慮したリソース配分を行うことを課題とする。
【課題を解決するための手段】
【０００５】
上記の課題を解決するために、本発明では以下の構成を採用する。
予め各利用主体毎に、当該利用主体のリソース配分の変更（増強、別リースへの変更、削減等）を行う条件および自身が所属するグループ内の他の利用主体のリソース配分変更に従うかを示す従属情報を記録しておく。そして、予め決められたトリガ（例：定期的、管理者や利用主体の指定）に応じて、任意のグループの利用主体のうち、従属しない利用主体について、上記条件を満たすかを判断する。この結果、満たす場合は、同じグループ内の従属する利用主体についても変更すると判断する。この場合、各従属しない利用主体について、上記条件を満たさない場合に、上記条件を満たすかを判断するものである。なお、従属しない利用主体に関し、上記条件を満たすと判断された場合、他の従属しない利用主体についても変更すると判断する。このように、本発明では、従属情報を用いて、変更の判断を伝播させ、条件を満たすかの判断を、一定範囲で省略している。
【０００６】
また、本発明においては、従属する利用主体が条件を満たすかの判断を、利用主体の条件が「少ない」ものから順序に行うとより好適である。少ないとは、条件の判断処理の負荷が小さい順序であり、用いるパラメータの数の少なさ、ロジックの簡便さなどが含まれる。このことにより、より負荷の掛かる条件ほど判断を省略（スキップ）できる可能性が高まり、処理負荷を総合的に低減可能になる。さらに「少なさ」の代わりに（ないしこれとの組み合わせで）、過去の履歴などから条件を満たし易い（条件を満たすことが多かった）ものから順番に判断を行ってもよい。
【０００７】
またさらに、リソースの増強、変更だけでなく、リソースの削減（費用の抑止）を行うよう制御してもよい。
【発明の効果】
【０００８】
以上の構成により、本発明では、同業などの動向を考慮したリソース配分が可能になる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態における自律型リソース配分装置の構成図
【図２Ａ】本発明の一実施形態における自律型リソース配分処理フローチャート（その１）
【図２Ｂ】本発明の一実施形態における自律型リソース配分処理フローチャート（その２）
【図３】本発明の一実施形態で用いられる市場情報登録テーブルを示す図
【図４】本発明の一実施形態で用いられる稼動統計情報登録テーブルを示す図
【図５】本発明の一実施形態で用いられるSLA登録テーブルを示す図
【図６】本発明の一実施形態で用いられるシナリオ定義テーブルを示す図
【図７】本発明の一実施形態でシナリオ実行テーブルを示す図
【発明を実施するための形態】
【００１０】
以下、本発明の一実施形態について、図面を用いて説明する。本実施形態では、複数の利用主体に対するクラウドコンピューティング環境の提供において、予め決められたトリガ（例：定期的、管理者や利用主体の指定）に加え、同業種などの動向も考慮した上での自律的なリソースの配分を実現可能なものとして説明する。また、リソースの増強、変更に加え、リソースの削減（費用の抑止）に向けた制御としても活用可能である。
【００１１】
例えば、予め決められたトリガとは具体的に、月初や期初、年初もしくは、月末、期末、年末などの決まったタイミングにおける定期的なものもあれば、CPUやメモリなどのシステムリソース使用におけるリソース不足のタイミングや、株価や為替相場などの市場指数値の増減もトリガの一つであると考えている。
添付図面を参照し、以下に自律的なリソース配分における配分対象範囲の判断処理について示す。
【００１２】
図１に、本発明の実施形態におけるシステム全体の構成を示す。本発明のシステムは、複数の利用主体が利用しているクラウドコンピューティング環境１０、リソースの配分を司るリソース配分マネージャ２０、リソース配分マネージャがリソース配分対象を選定する際に利用する各種テーブル(記憶装置)３０によって構成される。クラウドコンピューティング環境１０には、複数の利用主体向けにSLAに基づく業務上必要となる仮想ノードが割り当てられており、各種テーブルに格納されている市場指数値やシステムリソースの稼動統計情報に応じ、リソース配分マネージャが各利用主体単位に仮想ノードを適宜配分する仕組みとなる。ここで、リソース配分マネージャ２０は、いわゆるコンピュータで実現され、後述するフローチャートで示される処理を、ＣＰＵの如き演算装置がプログラムに従って実行する。また、クラウドコンピューティング環境１０もデータセンタのようなコンピュータ群であり、図示しない利用者端末（例：ＰＣ）やリソース配分マネージャ２０とネットワークを介して接続される。特に、利用者端末に関しては、複数の利用者（利用企業等）からの入力に従って所望の処理を実行していく。
【００１３】
図２ＡおよびＢに、自律型リソース配分処理フローの詳細について説明する。尚、図３の市場情報登録テーブル、図４の稼動統計情報登録テーブル、図５のSLA登録テーブル、図６のシナリオ定義テーブル、図７のシナリオ実行テーブルには事前に値が設定されている。ここでは、パラメータの形式、設定方法及び配置場所は問わない。
【００１４】
まず、101において定期的に実施される自律型リソース配分処理を開始し、102にて図３の市場情報登録テーブル、103にて図４の稼動統計情報登録テーブルの値を読み込む。104では、シナリオ実行判断が未決の会社が残っているかを確認する。これは、図７のシナリオ実行テーブルの6013：シナリオ実行フラグの値に従って判断する。6013：シナリオ実行フラグの値であるONは、後述する113、115、120、122の処理が終わった会社に記録され、値であるOFFは、後述する112、119の処理が終わった会社に記録される。尚、値であるNULLは、上記の判断処理が未実行であることを示すため、シナリオ実行判断が未決の会社と判断できる。この104にてシナリオ実行判断未決会社が存在しない場合は、処理105にて図7のシナリオ実行テーブルの6013：シナリオ実行フラグの値がONの会社に対し、図6のシナリオ定義テーブルの5013：配分内容に従い、新規にリソースを配分する処理を実行する。その後106にて図7のシナリオ実行テーブルの6013：シナリオ実行フラグの初期化処理として、登録されている各会社に対しNULLを記録し、107にて一連の自律型リソース配分処理を終了させる。
【００１５】
それとは逆に、104にてシナリオ実行判断未決会社が存在する場合は108に遷移し、図５のSLA登録テーブルの4013：業種より未決の会社が属する業種を１つ特定し、109にて特定した業種に属する会社の中で、シナリオ実行判断が未決かつ、他の利用主体と従属しない会社の存在を確認する。これは、図５のSLA登録テーブルの4015：従属フラグの値に従って判断する。値である0は他の利用主体と従属しない会社であり、値である1は他の利用主体と従属する会社である。ここで他の利用主体と従属しない会社が存在する場合、110にて、その中から他の利用主体と従属しない会社を１社特定し、111にて当該会社が新規のリソース配分が必要か否か確認する。これは、102にて読み込んだ図３の市場情報登録テーブルの値、および103にて読み込んだ図４の稼動統計情報登録テーブルの値と、図5のSLA登録テーブルの4016：シナリオ実行条件とのマッチングにより判断する。条件が合致しない場合は、112にて図7シナリオ実行テーブルにおける当該会社の6013：シナリオ実行フラグの値をOFFと記録し、109に戻る。逆に111にて条件が合致する場合は、113にて図7シナリオ実行テーブルにおける当該会社の6013：シナリオ実行フラグの値をONと記録し、且つ114にて同一業種の中且つ、従属フラグが１の会社の中でシナリオ実行判断が未決の会社の存在について確認する。存在しない場合は109に遷移するが、存在する場合は115にて図7のシナリオ実行テーブルにおける当該会社の6013：シナリオ実行フラグの値をONと記録し、109に遷移する。
【００１６】
109にてシナリオ実行判断が未決の会社の中で他の利用主体と従属しない会社（従属フラグの値が0）が存在しない場合は、116にて他の利用主体と従属する会社の存在を確認する。存在しない場合は104に遷移し、存在する場合は、117にて従属フラグが1である会社を特定し、118にて当該会社に対し新規のリソース配分が必要か否か確認する。これは、上述の111と同様の判断となるが、102にて読み込んだ図３の市場情報登録テーブルの値、および103にて読み込んだ図４の稼動統計情報登録テーブルの値と、図5のSLA登録テーブルの4016：シナリオ実行条件とのマッチングにより判断する。条件が合致しない場合は、119にて図7のシナリオ実行テーブルにおける当該会社の6013：シナリオ実行フラグの値をOFFと記録し、116に戻る。逆に条件が合致する場合は、120にて図7のシナリオ実行テーブルにおいて当該会社の6013：シナリオ実行フラグの値をONと記録し、且つ121にて同一業種の中且つ、従属フラグが１の会社の中でシナリオ実行判断が未決の会社の存在について確認する。存在しない場合は104に遷移することとなるが、存在する場合は122にて、図7のシナリオ実行テーブルにおける当該会社の6013：シナリオ実行フラグの値をONと記録し、104に遷移する。
【００１７】
尚、従属フラグが１となる契約会社におけるシナリオ実行条件チェックの順序は、契約会社のシナリオ実行条件が「少ない」ものから順序に行うとより好適である。少ないとは、条件の判断処理の負荷が小さい順序であり、用いるパラメータの数の少なさ、ロジックの簡便さなどが含まれる。このことにより、より負荷の掛かる条件ほど判断を省略（スキップ）できる可能性が高まり、処理負荷を総合的に低減可能になる。さらに「少なさ」の代わりに（ないしこれとの組み合わせで）、過去の履歴などから条件を満たし易い（条件を満たすことが多かった）ものから順番に判断を行ってもよい。
【００１８】
また、日次にて当日の稼動統計情報と前月の稼動実績統計情報を比較し、当月当該日以降においてリソース不足が想定される場合、自律的にリソースの増強を行う事も可能である。
【符号の説明】
【００１９】
１０…クラウドコンピューティング環境１０、２０…リソース配分マネージャ２０、３０…各種テーブル(記憶装置)
【図１】
2014081858.tif 000003
【図２Ａ】
2014081858.tif 000004
【図２Ｂ】
2014081858.tif 000005
【図３】
2014081858.tif 000006
【図４】
2014081858.tif 000007
【図５】
2014081858.tif 000008
【図６】
2014081858.tif 000009
【図７】
2014081858.tif 000010