(57)【要約】【課題】サーバ単位の粗いリソース制御ではなく、より効率的にリソースを使用することのできる仕組みを実現すること。【解決手段】アプリケーションを構成する１つ以上のプログラムモジュールをスケーラブルな処理リソースを用いて実行する際の前記プログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定する判定部、を備える情報処理装置を提供する。【選択図】図３
2014164425.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションを構成する１つ以上のプログラムモジュールをスケーラブルな処理リソースを用いて実行する際の前記プログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定する判定部、
を備える情報処理装置。
【請求項２】
前記情報処理装置は、
割当てられているプロセス数を変更すべきであると前記判定部により判定された前記プログラムモジュールについて、プロセス数の割当てを変更するリソース制御部、
をさらに備える、請求項１に記載の情報処理装置。
【請求項３】
前記情報処理装置は、
前記プログラムモジュールごとに前記負荷を測定する測定部、
をさらに備える、請求項２に記載の情報処理装置。
【請求項４】
前記測定部は、処理中の入力データの数を前記プログラムモジュールごとに前記負荷として測定する、請求項３に記載の情報処理装置。
【請求項５】
前記処理リソースのスケールは、少なくともサーバ数及びサーバごとのプロセス数によって制御され、
前記判定部は、アプリケーションごとに又はサーバごとに測定される非計算負荷に基づいて、各プログラムモジュールに割当てられているサーバ数を変更すべきかをさらに判定する、
請求項４に記載の情報処理装置。
【請求項６】
前記判定部は、前記プログラムモジュールに割当てられているプロセス数を増加すべきであると判定した場合において、前記非計算負荷が閾値を上回るときは当該プログラムモジュールに割当てられているサーバ数を増加すべきであると判定し、前記非計算負荷が閾値を下回るときは当該プログラムモジュールに割当てられているサーバ数を維持しつつプロセス数を増加すべきであると判定する、請求項５に記載の情報処理装置。
【請求項７】
前記リソース制御部は、前記処理中の入力データの数が高い割合を示す前記プログラムモジュールにより多くのプロセス数を割当てる、請求項４に記載の情報処理装置。
【請求項８】
前記非計算負荷は、メモリ負荷、Ｉ／Ｏ負荷及び通信負荷のうち少なくとも１つを含む、請求項５に記載の情報処理装置。
【請求項９】
前記リソース制御部は、前記アプリケーションへのリクエスト数と前記処理リソースの所要スケールとの関係を表現するリソースモデルに従って、前記アプリケーションへのリクエスト数に応じて前記処理リソースのスケールを制御する、請求項２に記載の情報処理装置。
【請求項１０】
前記リソースモデルは、前記リクエスト数と対応する所要スケールとの複数の組を用いた回帰分析によって予め取得される、請求項９に記載の情報処理装置。
【請求項１１】
前記情報処理装置は、
前記アプリケーションの実行中に、前記リクエスト数と対応する所要スケールとの新たな組を用いて前記リソースモデルを更新するモデル更新部、
をさらに備える、請求項１０に記載の情報処理装置。
【請求項１２】
情報処理装置により実行されるリソース制御方法であって、
アプリケーションを構成する１つ以上のプログラムモジュールをスケーラブルな処理リソースを用いて実行する際の前記プログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定すること、
を含むリソース制御方法。
【請求項１３】
情報処理装置を制御するコンピュータを、
アプリケーションを構成する１つ以上のプログラムモジュールをスケーラブルな処理リソースを用いて実行する際の前記プログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定する判定部、
として機能させるための、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置、リソース制御方法及びプログラムに関する。
【背景技術】
【０００２】
近年、クラウドコンピューティングと呼ばれるコンピュータの利用形態が広く活用されている。ＮＩＳＴ（National  Institute  of  Standards  and  Technology）の定義によれば、クラウドコンピューティングは、共用されるコンピューティングリソースのプールへのオンデマンドなネットワークアクセスを可能とするモデルであって、最小限の利用手続又はサービスプロバイダとの最小限のやり取りで、迅速にリソースの割当て及び提供が行われるモデルである。
【０００３】
クラウドコンピューティングの特徴の１つは、スケーラブルなリソースが提供され、ユーザの又はアプリケーションのニーズに応じて迅速に又は自動的にリソースのスケールイン又はスケールアウトが実行されることである。一般的に、スケールインとはリソースの規模（scale）の縮小をいい、スケールアウトとはリソースの規模の拡大をいう。例えば、下記非特許文献１には、ユーザが予め設定する閾値をプロセッサの負荷が上回る場合に、物理的な又は仮想的なアプリケーションサーバのインスタンスの割当て数を自動的に増加させる手法が記載されている。下記特許文献１には、サーバの負荷の履歴を用いて予測される未来の負荷に基づいて、サーバのスケールイン又はスケールアウトを実行する手法が記載されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】「Auto  Scaling」、［online］、［２０１３年１月２８日検索］、インターネット＜URL：http://aws.amazon.com/en/autoscaling/＞
【特許文献】
【０００５】
【特許文献１】特開２０１１−１１８５２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、サーバには、プロセッサのみならずメモリ、Ｉ／Ｏ（Input/Output）デバイス及び通信デバイスなどの様々な種類のリソースが関連付られ得る。サーバ単位のスケールイン及びスケールアウトでは、これらリソースを無駄なく使用することが難しい。
【０００７】
従って、サーバ単位の粗いリソース制御ではなく、より効率的にリソースを使用することのできる仕組みが実現されることが望ましい。
【課題を解決するための手段】
【０００８】
本開示によれば、アプリケーションを構成する１つ以上のプログラムモジュールをスケーラブルな処理リソースを用いて実行する際の前記プログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定する判定部、を備える情報処理装置が提供される。
【０００９】
また、本開示によれば、情報処理装置により実行されるリソース制御方法であって、アプリケーションを構成する１つ以上のプログラムモジュールをスケーラブルな処理リソースを用いて実行する際の前記プログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定すること、を含むリソース制御方法が提供される。
【００１０】
また、本開示によれば、情報処理装置を制御するコンピュータを、アプリケーションを構成する１つ以上のプログラムモジュールをスケーラブルな処理リソースを用いて実行する際の前記プログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定する判定部、として機能させるための、プログラムが提供される。
【発明の効果】
【００１１】
本開示に係る技術によれば、サーバ単位のリソース制御よりも効率的にコンピューティングリソースを使用することことが可能となる。
【図面の簡単な説明】
【００１２】
【図１】一実施形態に係る情報処理装置の概要について説明するための説明図である。
【図２Ａ】サーバ単位のリソース制御の一例について説明するための第１の説明図である。
【図２Ｂ】サーバ単位のリソース制御の一例について説明するための第２の説明図である。
【図２Ｃ】プロセス単位のリソース制御の一例について説明するための第１の説明図である。
【図２Ｄ】プロセス単位のリソース制御の一例について説明するための第２の説明図である。
【図３】第１の実施形態に係る情報処理装置の構成の一例を示すブロック図である。
【図４】プログラムモジュールごとに負荷を測定するための手法の一例について説明するための説明図である。
【図５Ａ】負荷の割合に応じたプロセス数の割当ての第１の例について説明するための説明図である。
【図５Ｂ】負荷の割合に応じたプロセス数の割当ての第２の例について説明するための説明図である。
【図６】プログラムモジュールごとに負荷を測定するための手法の他の例について説明するための説明図である。
【図７】プログラムモジュールごとに負荷を測定するための手法の他の例について説明するための説明図である。
【図８】プログラムモジュールごとに負荷を測定するための手法の他の例について説明するための説明図である。
【図９】第１の実施形態において実行され得るリソース制御処理の流れの一例を示すフローチャートである。
【図１０】図９に示したリソース割当て判定処理の詳細な流れの一例を示すフローチャートである。
【図１１】第２の実施形態に係る情報処理装置の構成の一例を示すブロック図である。
【図１２】リクエスト数とリソースの所要スケールとの関係を表現するリソースモデルについて説明するための説明図である。
【発明を実施するための形態】
【００１３】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１４】
また、以下の順序で説明を行う。
１．概要
２．第１の実施形態
２−１．装置の構成例
２−２．処理の流れ
３．第２の実施形態
４．まとめ
【００１５】
＜１．概要＞
まず、図１〜図２Ｄを用いて、一実施形態に係る情報処理装置の概要について説明する。
【００１６】
図１は、一実施形態に係る情報処理装置１００の概要について説明するための説明図である。図１を参照すると、コンピューティングシステム１０、及びコンピューティングシステム１０のリソースを制御する情報処理装置１００が示されている。
【００１７】
コンピューティングシステム１０は、アプリケーションを実行するリソースを有するシステムである。より具体的には、コンピューティングシステム１０は、アプリケーションを構成する１つ以上のプログラムモジュールをスケーラブルな処理リソースを用いて実行する。図１の例において、コンピューティングシステム１０は、プロセッサ２０、メモリ３０、ストレージ４０及び通信デバイス５０を含む。プロセッサ２０は、例えばＣＰＵ（Central  Processing  Unit）又はＤＳＰ（Digital  Signal  Processor）であってよい。メモリ３０は、ＲＡＭ（Random  Access  Memory）及びＲＯＭ（Read  Only  Memory）を含み、プロセッサ２０により実行されるプログラムコードを記憶する。ストレージ４０は、例えばハードディスクなどの大容量の記憶媒体であってよく、各プログラムモジュールへ入力されるデータ及び各プログラムモジュールから出力されるデータを記憶する。通信デバイス５０は、コンピューティングシステム１０と他の装置との間の通信を仲介する。コンピューティングシステム１０は、実質的には、１つの物理的なコンピュータであってもよく、又は複数の物理的なコンピュータの集合であってもよい。
【００１８】
既存のクラウドコンピューティングシステムにおいて、リソースは、サーバ単位で仮想化され得る。仮想的なサーバの数は、ユーザの又はアプリケーションのニーズに応じて動的に変更され得る。図１の例では、コンピューティングシステム１０は、Ｍ個のサーバＳ１、Ｓ２、…、ＳＭを含む。サーバＳ１、Ｓ２、…、ＳＭの各々は、メモリ３０のメモリ空間の一部を割り当てられ、ストレージ４０との間のインタフェース及び通信デバイス５０との間のインタフェースを有する。
【００１９】
サーバＳ１、Ｓ２、…、ＳＭの各々は、さらに柔軟なリソースのスケーラビリティを実現するために、１つ以上のプロセスＰｉｊ（ｉ＝１，２，…，Ｍ、ｊ＝１，２，…，ＮＭ）を含む。なお、Ｎｉは、ｉ番目のサーバのプロセスの数である。例えば、いわゆる“ビッグデータ”をリアルタイムで処理するためにＴｗｉｔｔｅｒ（登録商標）の開発者により提案されているＳｔｏｒｍフレームワークでは、処理リソースはサーバ及びプロセスという階層化された構造で管理される。Ｓｔｏｒｍは、本開示に係る技術を実現するために利用可能なフレームワークの一例である。
【００２０】
ここで、処理リソースをサーバ及びプロセスに階層化したとしても、既存の仕組みのようにサーバ単位でリソースのスケールイン及びスケールアウトが行われるとすれば、リソースに無駄が生じ得る。
【００２１】
図２Ａ及び図２Ｂは、サーバ単位のリソース制御の一例について説明するための説明図である。図２Ａを参照すると、プログラムモジュールＭ１及びＭ２により構成されるアプリケーションが示されている。一例として、プログラムモジュールＭ１にはサーバＳ１が割り当てられている。サーバＳ１は、プロセスＰ１１及びＰ１２、並びにメモリ空間Ｒ１ｂ、Ｉ／ＯインタフェースＲ１ｃ及び通信インタフェースＲ１ｄを有する。プログラムモジュールＭ２にはサーバＳ２が割り当てられている。サーバＳ２は、プロセスＰ２１、Ｐ２２及びＰ２３、並びにメモリ空間Ｒ２ｂ、Ｉ／ＯインタフェースＲ２ｃ及び通信インタフェースＲ２ｄを有する。
【００２２】
負荷Ｌ１は、プログラムモジュールＭ１について測定される負荷である。負荷Ｌ２は、プログラムモジュールＭ２について測定される負荷である。ここで、例えばアプリケーションへの処理リクエストの増加が検出され又は予測された場合において、負荷Ｌ２の増加を回避することが望まれるときに、プログラムモジュールＭ２についてのサーバ単位のスケールアウトが実行され得る。図２Ｂを参照すると、プログラムモジュールＭ２に新たにサーバＳ３が割り当てられている。サーバＳ３は、プロセスＰ３１、並びにメモリ空間Ｒ３ｂ、Ｉ／ＯインタフェースＲ３ｃ及び通信インタフェースＲ３ｄを有する。しかしながら、負荷Ｌ２の増加の原因は、様々である。例えば、プログラムモジュールＭ２が多数の又は複雑な演算を特徴とする場合、処理リソース（Processing  Resource）の不足が負荷Ｌ２の増加の主な原因となるであろう。一方で、プログラムモジュールＭ２が多量のデータの読み込み又は書き込みを特徴とする場合、処理リソースの不足ではなく、メモリリソースの不足又はＩ／Ｏのための長い待ち時間が負荷Ｌ２の増加の主な原因になり得る。後者の場合には、物理的な又は仮想的なサーバを増加させるサーバ単位のスケールアウトが効果的な対策になり得る。しかし、前者の場合に物理的な又は仮想的なサーバを増加させることは、メモリ空間及びＩ／Ｏインタフェースの無駄を生じさせる結果となる。
【００２３】
そこで、本開示に係る技術の一実施形態において、各プログラムモジュールに割当てられるリソースをプロセス単位で制御するための情報処理装置１００を導入する。情報処理装置１００は、各プログラムモジュールに割当てられるリソースをプロセス単位で制御することにより、コンピューティングシステム１０のリソースを効率的に使用しつつ、アプリケーションの所望の性能（スループット又はレイテンシなど）が満足されるように負荷を調整する。
【００２４】
図２Ｃ及び図２Ｄは、プロセス単位のリソース制御の一例について説明するための説明図である。図２Ｃを参照すると、図２Ａに示したプログラムモジュールＭ１及びＭ２により構成されるアプリケーションが再び示されている。プログラムモジュールＭ２に割当てられているサーバの数は１つのまま維持されており、サーバＳ２内のプロセスＰ２４が新たにプログラムモジュールＭ２に割り当てられている。このようなプロセス単位のスケールアウトは、多数の又は複雑な演算を特徴とするプログラムモジュールについて、メモリ空間及びＩ／Ｏインタフェースの無駄を生じさせることなく、その負荷を抑制することを可能とする。
【００２５】
なお、図２Ａ〜図２Ｃの例に限定されず、１つのサーバが複数のプログラムモジュールに割当てられてもよい。図２Ｄを参照すると、サーバＳ１は、プロセスＰ１１、Ｐ１２、Ｐ１３及びＰ１４並びにメモリ空間Ｒ１ｂ、Ｉ／ＯインタフェースＲ１ｃ及び通信インタフェースＲ１ｄを有する。サーバＳ２は、プロセスＰ２１、Ｐ２２、Ｐ２３及びＰ２４、並びにメモリ空間Ｒ２ｂ、Ｉ／ＯインタフェースＲ２ｃ及び通信インタフェースＲ２ｄを有する。プログラムモジュールＭ１には、サーバＳ１のプロセスＰ１１及びＰ１２が割り当てられている。プログラムモジュールＭ２には、サーバＳ１のプロセスＰ１３及びＰ１４、並びにサーバＳ２のプロセスＰ２１、Ｐ２２、Ｐ２３及びＰ２４が割り当てられている。この場合にも、情報処理装置１００は、プログラムモジュールＭ１及びＭ２の各々に割当てられるリソースを、プロセス単位で制御し得る。
【００２６】
＜２．第１の実施形態＞
情報処理装置１００は、クラウドコンピューティングサービスを運営するサービス事業者によって、サービスの一部として実装されてもよい。その代わりに、情報処理装置１００は、クラウドコンピューティングサービスを利用するユーザによって実装されてもよい。なお、本開示に係る技術は、必ずしも「クラウドコンピューティング」との用語で表現されない形態のサービスにも適用可能である。情報処理装置１００は、例えばＰＣ（Personal  Computer）又はワークステーションなどの汎用の装置であってもよく、又はリソースの制御という固有の目的のために設計される専用の装置であってもよい。
【００２７】
［２−１．装置の構成例］
図３は、第１の実施形態に係る情報処理装置１００の構成の一例を示すブロック図である。図３を参照すると、情報処理装置１００は、プログラム構成ＤＢ１１０、リソース構成ＤＢ１２０、負荷測定部１３０、判定部１４０及びリソース制御部１５０を備える。
【００２８】
（１）プログラム構成ＤＢ
プログラム構成ＤＢ１１０は、コンピューティングシステム１０により実行される１つ以上のアプリケーションのプログラム構成を示すプログラム構成データを記憶するデータベースである。プログラム構成データは、各アプリケーションを構成する１つ以上のプログラムモジュールのリストと、それらプログラムモジュールの間の呼び出し関係とを示す。さらに、プログラム構成データは、各プログラムモジュールの入力データ及び出力データを識別する情報を含む。プログラム構成データは、アプリケーションを解析することにより自動的に生成されてもよく、又はアプリケーションを開発したユーザにより生成されてもよい。典型的なプログラム構成のいくつかの例について、後にさらに説明する。
【００２９】
（２）リソース構成ＤＢ
リソース構成ＤＢ１２０は、コンピューティングシステム１０により実行中のアプリケーションの各プログラムモジュールに割当てられているリソースの構成を示すリソース構成データを記憶するデータベースである。コンピューティングシステム１０の処理リソースは、上述したように、割当て規模を動的に変更可能なリソース、即ちスケーラブルなリソースである。リソース構成データは、例えば、プログラムモジュール別の、割り当て済みのサーバ数と及びサーバごとの割り当て済みのプロセス数とを示す。後述するリソース制御部１５０によりリソースの割当てが変更されると、リソース構成ＤＢ１２０により記憶されているリソース構成データは、その変更を反映するように更新される。
【００３０】
（３）負荷測定部
負荷測定部１３０は、コンピューティングシステム１０により実行中のアプリケーションを構成するプログラムモジュールの各々について、負荷を測定する。本実施形態において負荷測定部１３０により測定される負荷は、プログラムモジュールごとの計算負荷（computational  load）、及びサーバごとの非計算負荷（non-computational  load）を含む。非計算負荷は、例えば、メモリ負荷（メモリ使用率など）、Ｉ／Ｏ負荷（単位時間当たりのＩ／Ｏ回数又はＩ／Ｏ待ち時間など）及び通信負荷（単位時間当たりの通信データ量又は通信待機時間など）のうち少なくとも１つを含む。計算負荷は、典型的にはプロセッサに掛かる負荷である。但し、多くのクラウドコンピューティング環境において、どのプログラムモジュールの実行がどのプロセッサにどれだけの負荷を与えているかを直接的に測定することは難しい。そこで、本実施形態において、負荷測定部１３０は、プログラムモジュールごとに、処理中の入力データの数を計算負荷として測定する。処理中の入力データの数は、各プログラムモジュールの入力データ数から出力データ数を減算することにより計算され得る。クラウドコンピューティング環境において、処理リソースが高度に仮想化されているとしても、ストレージに設けられるファイルシステムをモニタリングすることは可能である。従って、ファイルシステム上の入力データ数及び出力データ数を用いて計算負荷を近似的に導く手法を採用することにより、クラウドコンピューティング環境のシステム的な改変を要することなく、プログラムモジュールごとの計算負荷を把握することができる。
【００３１】
図４は、プログラムモジュールごとに負荷を測定するための手法の一例について説明するための説明図である。図４を参照すると、アプリケーションＡＰ１を構成する４つのプログラムモジュールＭ１１、Ｍ１２、Ｍ１３及びＭ１４が示されている。一例として、アプリケーションＡＰ１は、入力画像（例えば、エンドユーザが撮像した写真）を自動的に画像アルバムに追加するための画像処理アプリケーションである。プログラムモジュールＭ１１は、入力画像の特徴を解析することにより画像特徴量を抽出する。プログラムモジュールＭ１２は、抽出された特徴量と他の画像の特徴量とを比較し、画像間の類似度を判定する。プログラムモジュールＭ１３は、判定された類似度に応じて入力画像を複数のグループのいずれか（又は新たなグループ）に分類する。プログラムモジュールＭ１４は、入力画像が分類されたグループのアルバムに、入力画像を追加する。図４に示したように、プログラムモジュールＭ１１、Ｍ１２、Ｍ１３及びＭ１４は、単純にシーケンシャルな呼び出し関係を有する。即ち、プログラムモジュールＭ１１は、入力画像を入力データとして受け取り、画像特徴量を出力すると共に、入力画像のステータスを解析済み画像に変更する。入力画像の数Ｄ１０及び解析済み画像の数Ｄ１１は、それぞれ、プログラムモジュールＭ１１の入力データ数及び出力データ数に等しい。プログラムモジュールＭ１２は、画像特徴量を入力データとして受け取り、類似判定の結果としての類似度のセットを出力すると共に、解析済み画像のステータスを判定済み画像に変更する。解析済み画像の数Ｄ１１及び判定済み画像の数Ｄ１２は、それぞれ、プログラムモジュールＭ１２の入力データ数及び出力データ数に等しい。プログラムモジュールＭ１３は、類似度のセットを入力データとして受け取り、分類結果（例えば、入力画像が属するグループの識別子）を出力すると共に、判定済み画像のステータスを分類済み画像に変更する。判定済み画像の数Ｄ１２及び分類済み画像の数Ｄ１３は、それぞれ、プログラムモジュールＭ１３の入力データ数及び出力データ数に等しい。プログラムモジュールＭ１４は、分類結果を入力データとして受け取り、対応するアルバムに入力画像を追加すると共に、分類済み画像のステータスを処理済み画像Ｄ１４に変更する。分類済み画像の数Ｄ１３及び処理済み画像の数Ｄ１４は、それぞれ、プログラムモジュールＭ１４の入力データ数及び出力データ数に等しい。負荷測定部１３０は、これら入出力データ数Ｄ１０〜Ｄ１４を用いて、プログラムモジュールＭ１１、Ｍ１２、Ｍ１３及びＭ１４についての負荷Ｌ１１、Ｌ１２、Ｌ１３及びＬ１４を、次のように測定し得る：
【００３２】
【数１】
2014164425.tif 000003
【００３３】
負荷測定部１３０は、このような計算負荷をアプリケーションの実行中に周期的に測定する。また、負荷測定部１３０は、非計算負荷をアプリケーションの実行中に周期的に測定する。そして、負荷測定部１３０は、測定される計算負荷及び非計算負荷の値を、判定部１４０へ出力する。なお、図４を用いて説明したアプリケーションは一例に過ぎない。本開示に係る技術は、図４に示した例とは異なる種類のアプリケーションに適用されてもよい。
【００３４】
（４）判定部
判定部１４０は、負荷測定部１３０から入力されるプログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定する。例えば、判定部１４０は、あるプログラムモジュールについて測定された負荷が予め定義され得る閾値を上回る場合に、当該プログラムモジュールに割当てられているプロセス数を増加させることを決定してもよい。また、判定部１４０は、あるプログラムモジュールについて測定された負荷が予め定義され得る（同じ又は別の）閾値を下回る場合に、当該プログラムモジュールに割当てられているプロセス数を減少させることを決定してもよい。
【００３５】
また、本実施形態において、判定部１４０は、サーバごとに測定される非計算負荷に基づいて、各プログラムモジュールに割当てられているサーバ数を変更すべきかをさらに判定する。判定部１４０は、例えば、あるプログラムモジュールに割当てられているプロセス数を増加すべきであると判定した場合において、非計算負荷が予め定義され得る閾値を上回るときは、当該プログラムモジュールに割当てられているサーバ数を増加すべきであると判定し得る。こうした判定を導入することで、非計算負荷が全体としての負荷の主な原因となっている場合に、サーバ数を動的に増加させることにより、負荷を解消し又は軽減することができる。また、判定部１４０は、あるプログラムモジュールに割当てられているプロセス数を増加すべきであると判定した場合において、非計算負荷が閾値を下回るときは、当該プログラムモジュールに割当てられているサーバ数を維持しつつプロセス数を増加すべきであると判定し得る。こうした判定を導入することで、計算負荷が全体としての負荷の主な原因となっている場合に、負荷に寄与していないリソースを無駄に追加することなく、プロセス数を動的に増加させることにより、負荷を解消し又は軽減することができる。同様に、判定部１４０は、あるプログラムモジュールに割当てられているプロセス数を減少すべきであると判定した場合において、非計算負荷と閾値との比較に基づいて、当該プログラムモジュールに割当てられているサーバ数を減少すべきか否かを判定してもよい。
【００３６】
判定部１４０は、負荷の測定結果に基づくこのような判定の結果を、リソース制御部１５０へ出力する。
【００３７】
（５）リソース制御部
リソース制御部１５０は、割当てられているプロセス数を変更すべきであると判定部１４０により判定されたプログラムモジュールについて、プロセス数の割当てを変更する。例えば、リソース制御部１５０は、プロセス数を増加すべきであると判定されたプログラムモジュールについて、割り当て済みのプロセス数を単純に１つ加算してもよい。その代わりに、リソース制御部１５０は、その時点の負荷の大きさに応じて異なる数だけプロセス数を増加させてもよい。それにより負荷が軽減されない場合は、次の制御周期において、プロセス数はさらに増加され得る。同様に、リソース制御部１５０は、プロセス数を減少すべきであると判定されたプログラムモジュールについて、割り当て済みのプロセス数を単純に１つ減らしてもよい。その代わりに、リソース制御部１５０は、その時点の負荷の大きさに応じて異なる数だけプロセス数を減少させてもよい。リソース制御部１５０は、さらに、割当てられているサーバ数を変更すべきであると判定されたプログラムモジュールについて、サーバ数の割当てを変更し得る。こうしたリソース制御が繰り返されると、処理中の入力データの数が高い割合を示すプログラムモジュールに、より多くのプロセス数が割当てられる結果となる。
【００３８】
リソース制御部１５０は、あるプログラムモジュールについて、プロセス数又はプロセス数及びサーバ数の割当てが変更されると、コンピューティングシステム１０へ制御信号を送信することにより、コンピューティングシステム１０のリソース構成を変更させる。また、リソース制御部１５０は、リソース構成ＤＢ１２０により記憶されているリソース構成データも更新する。
【００３９】
図５Ａは、負荷の割合に応じたプロセス数の割当ての第１の例について説明するための説明図である。図５Ａの例において、当初、プログラムモジュールＭ１１、Ｍ１２、Ｍ１３及びＭ１４に、共通の１つのサーバとそれぞれ１つのプロセスとが割り当てられている。判定部１４０は、これらプログラムモジュールの負荷Ｌ１１、Ｌ１２、Ｌ１３及びＬ１４を、例えば上述した式（１）〜式（４）に従って測定する。その測定結果において、プログラムモジュールＭ１２が最も高い負荷の割合を示し、プログラムモジュールＭ１３が次に高い負荷の割合を示したものとする（Ｌ１２＞Ｌ１３＞Ｌ１１，Ｌ１４）。すると、１つ以上の制御周期を経て、リソース制御部１５０は、プログラムモジュールＭ１２に割当てられているプロセス数を４つに、プログラムモジュールＭ１３に割当てられているプロセス数を２つに増加させる。それにより、プログラムモジュールＭ１１、Ｍ１２、Ｍ１３及びＭ１４の間のリソースのバランスを適正化し、アプリケーションの所望の性能を確保することができる。なお、図５Ａの例では、サーバ数は維持されている。
【００４０】
図５Ｂは、負荷の割合に応じたプロセス数の割当ての第２の例について説明するための説明図である。図５Ｂの例においても、当初、プログラムモジュールＭ１１、Ｍ１２、Ｍ１３及びＭ１４に、共通の１つのサーバとそれぞれ１つのプロセスとが割り当てられている。判定部１４０は、これらプログラムモジュールの負荷Ｌ１１、Ｌ１２、Ｌ１３及びＬ１４を、例えば上述した式（１）〜式（４）に従って測定する。その測定結果において、プログラムモジュールＭ１２が最も高い負荷の割合を示し、プログラムモジュールＭ１３が次に高い負荷の割合を示したものとする（Ｌ１２＞Ｌ１３＞Ｌ１１，Ｌ１４）。また、非計算負荷が高い値を示したものとする。すると、１つ以上の制御周期を経て、リソース制御部１５０は、サーバ数を２つに増加させる。また、リソース制御部１５０は、プログラムモジュールＭ１２に割当てられているプロセス数を４つ（サーバごとに２つ）に、プログラムモジュールＭ１３に割当てられているプロセス数を２つ（サーバごとに１つ）に増加させる。それにより、プログラムモジュール間のリソースのバランスを適正化すると共に、処理リソース以外のリソースをも補強して、アプリケーションの所望の性能を確保することができる。
【００４１】
（６）負荷測定の他の例
図４では、単純なシーケンシャルな呼び出し関係を有するプログラムモジュールの各々について負荷を測定するための手法の一例を説明した。本項では、プログラムモジュールがより複雑な呼び出し関係を有するいくつかのケースについて負荷を測定するための手法をさらに説明する。
【００４２】
図６は、プログラムモジュールごとに負荷を測定するための手法の他の例について説明するための説明図である。図６を参照すると、あるアプリケーションを構成する４つのプログラムモジュールＭ２１、Ｍ２２、Ｍ２３及びＭ２４が示されている。プログラムモジュールＭ２２は、サブルーチンＭ２２１及びＭ２２２を含み、１つの入力データについて２回呼び出される。プログラムモジュールＭ２１の入力データ数はＤ２０、出力データ数はＤ２１である。サブルーチンＭ２２１の１回目の実行の入力データ数はＤ２１、出力データ数はＤ２１１＿１である。サブルーチンＭ２２２の１回目の実行の入力データ数はＤ２１１＿１、出力データ数はＤ２１２＿１である。プログラムモジュールＭ２３の入力データ数はＤ２１２＿１、出力データ数はＤ２３である。サブルーチンＭ２２１の２回目の実行の入力データ数はＤ２３、出力データ数はＤ２１１＿２である。サブルーチンＭ２２２の２回目の実行の入力データ数はＤ２１１＿２、出力データ数はＤ２１２＿２である。プログラムモジュールＭ２４の入力データ数はＤ２１２＿２、出力データ数はＤ２４である。負荷測定部１３０は、これら入出力データ数を用いて、プログラムモジュールＭ２１、Ｍ２２、Ｍ２３及びＭ２４についての負荷Ｌ２１、Ｌ２２、Ｌ２３及びＬ２４を、次のように測定し得る：
【００４３】
【数２】
2014164425.tif 000004
【００４４】
このように、複数回呼び出されるプログラムモジュール（又はサブルーチン）については、呼び出しごとに計算される出力データ数と入力データ数との差を合計することにより、当該プログラムモジュールの負荷が測定されてよい。
【００４５】
図７は、プログラムモジュールごとに負荷を測定するための手法のまた別の例について説明するための説明図である。図７を参照すると、あるアプリケーションを構成する３つのプログラムモジュールＭ３１、Ｍ３２及びＭ３３が示されている。これらプログラムモジュールは、ある終了条件が満たされるまで、繰返し呼び出される。プログラムモジュールＭ３１の１回目の実行の入力データ数はＤ３０、出力データ数はＤ３１＿１である。プログラムモジュールＭ３１の２回目以降のｋ回目の実行の入力データ数はＤ３３＿（ｋ−１）、出力データ数はＤ３１＿ｋである。プログラムモジュールＭ３２のｋ回目の実行の入力データ数はＤ３１＿ｋ、出力データ数はＤ３２＿ｋである。プログラムモジュールＭ３３のｋ回目の実行の入力データ数はＤ３２＿ｋ、出力データ数はＤ３３＿ｋである。負荷測定部１３０は、これら入出力データ数を用いて、プログラムモジュールＭ３１、Ｍ３２及びＭ３３についての負荷Ｌ３１、Ｌ３２及びＬ３３を、次のように測定し得る：
【００４６】
【数３】
2014164425.tif 000005
【００４７】
なお、式（９）〜式（１１）におけるＫは、繰り返し回数を表す。
【００４８】
図８は、プログラムモジュールごとに負荷を測定するための手法のまた別の例について説明するための説明図である。図８を参照すると、あるアプリケーションを構成する４つのプログラムモジュールＭ４１、Ｍ４２、Ｍ４３及びＭ４４が示されている。プログラムモジュールＭ４２及びＭ４３は、プログラムモジュールＭ４１から並列的に分岐し、共にプログラムモジュールＭ４４を呼び出す。プログラムモジュールＭ４１の入力データ数はＤ４０、プログラムモジュールＭ４２への出力データ数はＤ４１＿ａ、プログラムモジュールＭ４３への出力データ数はＤ４１＿ｂである。プログラムモジュールＭ４２の入力データ数はＤ４１＿ａ、出力データ数はＤ４２である。プログラムモジュールＭ４３の入力データ数はＤ４１＿ｂ、出力データ数はＤ４３である。プログラムモジュールＭ４４のプログラムモジュールＭ４２からの入力データ数はＤ４２、プログラムモジュールＭ４３からの入力データ数はＤ４３、出力データ数はＤ４４である。負荷測定部１３０は、これら入出力データ数を用いて、プログラムモジュールＭ４１、Ｍ４２、Ｍ４３及びＭ４４についての負荷Ｌ４１、Ｌ４２、Ｌ４３及びＬ４４を、次のように測定し得る：
【００４９】
【数４】
2014164425.tif 000006
【００５０】
なお、負荷を近似的に測定するためのこれら手法は、プログラム構成に従って、どのように組み合わされてもよい。
【００５１】
［２−２．処理の流れ］
（１）全体的な流れ
図９は、本実施形態において情報処理装置１００により実行され得るリソース制御処理の流れの一例を示すフローチャートである。
【００５２】
図９を参照すると、まず、負荷測定部１３０は、コンピューティングシステム１０により実行中のアプリケーションのプログラム構成を、プログラム構成ＤＢ１１０により記憶されているプログラム構成データを参照することにより認識する（ステップＳ１１０）。
【００５３】
次に、負荷測定部１３０は、認識したプログラム構成に含まれる１つ以上のプログラムモジュールについて、入力データ数及び出力データ数を測定する（ステップＳ１２０）。そして、負荷測定部１３０は、測定した入力データ数及び出力データ数をに基づいて、プログラムモジュールごとの負荷を計算する（ステップＳ１３０）。
【００５４】
また、負荷測定部１３０は、リソース構成ＤＢ１２０を参照し、実行中のアプリケーションに割当てられている１つ以上のサーバについての非計算負荷（例えば、メモリ負荷、Ｉ／Ｏ負荷、及び通信負荷など）を測定する（ステップＳ１４０）。
【００５５】
次に、判定部１４０は、負荷測定部１３０による負荷の測定結果に基づいて、リソース割当て判定処理を実行する（ステップＳ１５０）。それにより、リソースの新たな割当てが決定され得る。
【００５６】
次に、リソース制御部１５０は、割当てられているプロセス数又はサーバ数を変更すべきであると判定されたプログラムモジュールについて、コンピューティングシステム１０へ制御信号を送信することにより、リソースの割当てを変更する（ステップＳ１７０）。新たなリソースの割当ては、リソース構成ＤＢ１２０により記憶される。
【００５７】
上述した処理は、典型的には、アプリケーションの実行が終了するまで周期的に繰り返され得る（ステップＳ１８０）。アプリケーションの実行が終了した場合には、図９のリソース制御処理は終了する。
【００５８】
（２）リソース割当て判定処理
図１０は、図９に示したリソース割当て判定処理の詳細な流れの一例を示すフローチャートである。
【００５９】
図１０の処理は、負荷測定部１３０から判定部１４０へ入力される負荷の測定結果に基づいて分岐する。まず、非計算負荷の高いサーバが存在する場合には、処理はステップＳ１５５へ進む（ステップＳ１５１）。非計算負荷の高いサーバが存在せず、リソースが過剰である（例えば、計算負荷が所定の閾値よりも高いプログラムモジュールが存在せず、かつ非計算負荷も所定の閾値を下回る、など）場合には、処理はステップＳ１５７へ進む。いずれのケースにも該当しない場合には、処理はステップＳ１５９へ進む。
【００６０】
ステップＳ１５５では、判定部１４０は、サーバ数を増加させることを決定する。ステップＳ１５７では、判定部１４０は、（サーバ数が既に１つである場合を除き）サーバ数を減少させることを決定する。ステップＳ１５９では、判定部１４０は、サーバ数を維持することを決定する。
【００６１】
次に、判定部１４０は、プログラムモジュールごとの計算負荷の割合に応じて、各プログラムモジュールに割当てるプロセス数を決定する（ステップＳ１６１）。その結果、高い計算負荷を示すプログラムモジュールのために、割り当て済みのサーバ内の追加的なプロセス、又は新たなサーバ内のプロセスが割り当てられ得る。
【００６２】
＜３．第２の実施形態＞
第１の実施形態では、処理リソースは、プログラムモジュールごとの負荷をモニタリングすることにより動的に変更される。アプリケーションへのリクエスト数が緩やかに変動する条件下では、このようないわゆるフィードバック型の制御方式によってリソース構成を最適化することができる。しかし、アプリケーションへのリクエスト数の変動が緩やかでない条件下では、フィードバック型の制御方式はリクエスト数の変動に追いつかない可能性がある。その場合、リクエスト数から負荷の増加を予測し、実際に負荷が発生する前にリソース構成を変化させることが、アプリケーションの所望の性能を確保するために有益である。そこで、第２の実施形態として、アプリケーションへのリクエスト数から処理リソースの所要スケール（例えば、所要プロセス数）を予測し、負荷が実際に増加する前に所要の処理リソースをプログラムモジュールに割り当てる仕組みについて説明する。
【００６３】
図１１は、第２の実施形態に係る情報処理装置２００の構成の一例を示すブロック図である。図１１を参照すると、情報処理装置２００は、プログラム構成ＤＢ１１０、リソース構成ＤＢ１２０、負荷測定部１３０、リソースモデルＤＢ２３５、判定部２４０、リソース制御部１５０及びモデル更新部２７０を備える。
【００６４】
（１）リソースモデルＤＢ
リソースモデルＤＢ２３５は、コンピューティングシステム１０により実行される各アプリケーションについて、リクエスト数と処理リソースの所要スケールとの関係を表現するリソースモデルを予め記憶するデータベースである。処理リソースの所要スケールとは、例えば、所定の性能要件が満足されるという条件の下で、あるリクエスト数についてのアプリケーション処理を完了させることのできるプロセス数の下限値であってよい。所定の性能要件とは、アプリケーション処理の総実行時間の上限値、個々のプログラムモジュールの実行時間の上限値、利用可能な最大のサーバ数、又は特定の通信環境など、いかなる要件であってもよい。
【００６５】
図１２は、アプリケーションへのリクエスト数とリソースの所要スケールとの関係を表現するリソースモデルについて説明するための説明図である。図１２の例において、横軸はリクエスト数、縦軸は所要プロセス数である。図１２において点線で描かれているのは、所要プロセス数の増加がリクエスト数の増加に比例するという、線形モデルである。しかしながら、コンピュータを使用して実際に所要プロセス数を測定し、リクエスト数と所要プロセス数との関係をプロットすると、プロットされる線は理想的な直線を描かない。実際には、図１２において実線で示した曲線のように、リクエスト数がより大きくなるほど、リクエスト数の増加に対する所要プロセス数の増加の割合（図１２のモデルの傾き）は高くなる。このようなリソースモデルの曲線は、例えば、アプリケーションへのリクエスト数と対応する所要スケールの（例えば試験環境における）実測値との複数の組を用いた回帰分析によって、アプリケーションごとに、又はアプリケーションを構成するプログラムモジュールごとに予め取得され得る。そして、リソースモデルＤＢ２３５は、取得されるそれらリソースモデルをデータとして記憶する。
【００６６】
（２）判定部
判定部２４０は、実行中のアプリケーションへのリクエスト数をコンピューティングシステム１０から取得し、リソースモデルＤＢ２３５により記憶されているリソースモデルと取得したリクエスト数とに基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定する。また、判定部２４０は、プロセス数を変更すべきである場合には、変更後のプロセス数をも決定する。判定部２４０は、リソースモデルから決定されるプロセス数では負荷測定部１３０により測定される負荷が軽減されないと判定される場合には、最新の負荷に基づいてプロセス数を決定（修正）してもよい。また、判定部２４０は、サーバごとに測定される非計算負荷に基づいて、各プログラムモジュールに割当てられているサーバ数を変更すべきかをさらに判定する。第１の実施形態と同様、各プログラムモジュールに割当てられるプロセス数は、サーバ数の変更と共に変更されてもよく、サーバ数を変更することなく変更されてもよい。リソース制御部１５０は、判定部２４０から入力される判定結果に従って、各プログラムモジュールに割当てられているプロセス数及びサーバ数の一方又は双方を変更する。
【００６７】
（３）モデル更新部
モデル更新部２７０は、アプリケーションの実行中に、コンピューティングシステム１０から取得されるリクエスト数と対応する所要スケールとの新たな組を用いて、リソースモデルＤＢ２３５により記憶されているリソースモデルを更新する。例えば、モデル更新部２７０は、判定部２４０において負荷の最新値に基づいてプロセス数の割当てが（リソースモデルに基づく予測値から）修正された場合に、リクエスト数と修正されたプロセス数との新たな組を回帰分析に取り入れることにより、リソースモデルを更新し得る。このような動的なリソースモデルの更新を通じてリソースモデルを精緻化することにより、所要スケールの予測精度が向上される。それにより、リクエスト数が激しく変動する条件下においても処理リソースの割当てをリクエスト数の変動に迅速に追随させ、アプリケーションの性能が一時的にでも劣化することを回避することが可能となる。
【００６８】
＜４．まとめ＞
ここまで、図１〜図１２を用いて、本開示に係る技術のいくつかの実施形態について詳細に説明した。上述した実施形態によれば、スケーラブルな処理リソースを用いてアプリケーションが実行される際のプログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられる処理リソースがプロセス単位で動的に変更される。従って、サーバ単位のリソース制御とは異なり、処理リソース以外の様々なリソースがアプリケーションに無駄に割り当てられることを防止することができる。それにより、既存の手法よりもリソースを効率的に使用することが可能となる。
【００６９】
また、上述した実施形態によれば、処理中の入力データの数がプログラムモジュールごとに負荷として測定され得る。従って、どのプログラムモジュールの実行がどのプロセッサにどれだけの負荷を与えているかを直接的に測定することの難しいクラウドコンピューティング環境においても、処理リソースの負荷を近似的に測定し、測定した近似的な負荷をプロセス単位のリソース制御のために活用することができる。
【００７０】
また、上述した実施形態によれば、処理リソースのスケールは、少なくともサーバ数及びサーバごとのプロセス数によって制御される。そして、アプリケーションごとに又はサーバごとに測定される非計算負荷に基づいて、各プログラムモジュールに割当てられているサーバ数を変更すべきかが判定され得る。従って、負荷の増加の原因に応じて、適切な種類のリソース（サーバ／プロセス）の割当てを制御することができる。それにより、一層効率的なリソースの使用が実現される。
【００７１】
また、上述した実施形態によれば、アプリケーションへのリクエスト数と処理リソースの所要スケールとの関係を表現するリソースモデルに従って、処理リソースのスケールがプロセス単位で制御され得る。この場合、負荷の実測値に基づく純粋なフィードバック型の制御方式とは異なり、予測される負荷の増大を未然に防ぐことが可能となる。それにより、リクエスト数が変動する条件下でも、アプリケーションの所望の性能を確保することができる。
【００７２】
なお、本明細書において説明した情報処理装置による一連の処理は、典型的には、ソフトウェアを用いて実現される。一連の処理を実現するソフトウェアを構成するプログラムは、例えば、情報処理装置の内部又は外部に設けられる記憶媒体（非一時的な媒体：non-transitory  media）に予め格納される。そして、各プログラムは、例えば、実行時にＲＡＭに読み込まれ、ＣＰＵなどのプロセッサにより実行される。
【００７３】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【００７４】
なお、以下のような構成も本開示の技術的範囲に属する。
（１）
アプリケーションを構成する１つ以上のプログラムモジュールをスケーラブルな処理リソースを用いて実行する際の前記プログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定する判定部、
を備える情報処理装置。
（２）
前記情報処理装置は、
割当てられているプロセス数を変更すべきであると前記判定部により判定された前記プログラムモジュールについて、プロセス数の割当てを変更するリソース制御部、
をさらに備える、前記（１）に記載の情報処理装置。
（３）
前記情報処理装置は、
前記プログラムモジュールごとに前記負荷を測定する測定部、
をさらに備える、前記（２）に記載の情報処理装置。
（４）
前記測定部は、処理中の入力データの数を前記プログラムモジュールごとに前記負荷として測定する、前記（３）に記載の情報処理装置。
（５）
前記処理リソースのスケールは、少なくともサーバ数及びサーバごとのプロセス数によって制御され、
前記判定部は、アプリケーションごとに又はサーバごとに測定される非計算負荷に基づいて、各プログラムモジュールに割当てられているサーバ数を変更すべきかをさらに判定する、
前記（４）に記載の情報処理装置。
（６）
前記判定部は、前記プログラムモジュールに割当てられているプロセス数を増加すべきであると判定した場合において、前記非計算負荷が閾値を上回るときは当該プログラムモジュールに割当てられているサーバ数を増加すべきであると判定し、前記非計算負荷が閾値を下回るときは当該プログラムモジュールに割当てられているサーバ数を維持しつつプロセス数を増加すべきであると判定する、前記（５）に記載の情報処理装置。
（７）
前記リソース制御部は、前記処理中の入力データの数が高い割合を示す前記プログラムモジュールにより多くのプロセス数を割当てる、前記（４）〜（６）のいずれか１項に記載の情報処理装置。
（８）
前記非計算負荷は、メモリ負荷、Ｉ／Ｏ負荷及び通信負荷のうち少なくとも１つを含む、前記（５）又は前記（６）に記載の情報処理装置。
（９）
前記リソース制御部は、前記アプリケーションへのリクエスト数と前記処理リソースの所要スケールとの関係を表現するリソースモデルに従って、前記アプリケーションへのリクエスト数に応じて前記処理リソースのスケールを制御する、前記（２）〜（８）のいずれか１項に記載の情報処理装置。
（１０）
前記リソースモデルは、前記リクエスト数と対応する所要スケールとの複数の組を用いた回帰分析によって予め取得される、前記（９）に記載の情報処理装置。
（１１）
前記情報処理装置は、
前記アプリケーションの実行中に、前記リクエスト数と対応する所要スケールとの新たな組を用いて前記リソースモデルを更新するモデル更新部、
をさらに備える、前記（１０）に記載の情報処理装置。
（１２）
情報処理装置により実行されるリソース制御方法であって、
アプリケーションを構成する１つ以上のプログラムモジュールをスケーラブルな処理リソースを用いて実行する際の前記プログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定すること、
を含むリソース制御方法。
（１３）
情報処理装置を制御するコンピュータを、
アプリケーションを構成する１つ以上のプログラムモジュールをスケーラブルな処理リソースを用いて実行する際の前記プログラムモジュールごとの負荷の測定結果に基づいて、各プログラムモジュールに割当てられているプロセス数を変更すべきかを判定する判定部、
として機能させるための、プログラム。
【符号の説明】
【００７５】
１０              コンピューティングシステム
１００，２００    情報処理装置
１１０            プログラム構成ＤＢ
１２０            リソース構成ＤＢ
１３０            負荷測定部
１４０，２４０    判定部
１５０            リソース制御部
２３５            リソースモデルＤＢ
２７０            モデル更新部
【図１】
2014164425.tif 000007
【図２Ａ】
2014164425.tif 000008
【図２Ｂ】
2014164425.tif 000009
【図２Ｃ】
2014164425.tif 000010
【図２Ｄ】
2014164425.tif 000011
【図３】
2014164425.tif 000012
【図４】
2014164425.tif 000013
【図５Ａ】
2014164425.tif 000014
【図５Ｂ】
2014164425.tif 000015
【図６】
2014164425.tif 000016
【図７】
2014164425.tif 000017
【図８】
2014164425.tif 000018
【図９】
2014164425.tif 000019
【図１０】
2014164425.tif 000020
【図１１】
2014164425.tif 000021
【図１２】
2014164425.tif 000022