(57)【要約】【課題】リソースを有効に活用し、システム全体の能力を向上させるサブシステム制御ノードを提供する。【解決手段】サブシステム制御ノードは、分散キャッシュクラスタが格納するキャッシュデータに対するアクセスに関する情報を含むキャッシュ利用状況データから、キャッシュデータに対するアクセス分布を推定するアクセス分布推定部と、推定されたアクセス分布から、分散キャッシュクラスタに含まれるリソースの増減が、分散キャッシュクラスタを含むサービス提供システムに与える影響を示すリソース増減影響度を算出するリソース増減影響判定部と、リソース増減影響度に基づき、分散キャッシュクラスタに含まれるリソースを増減するか、又は、他のサブシステムに含まれるリソースを増減するか、を決定するリソース増減対象算出部と、リソース増減対象算出部が決定したサブシステムに対し、リソースの増減を指示する制御指示部と、を備える。【選択図】図１
2013205962.tif 000002
【特許請求の範囲】
【請求項１】
分散キャッシュクラスタが格納するキャッシュデータに対するアクセスに関する情報を含むキャッシュ利用状況データから、前記キャッシュデータに対するアクセス分布を推定するアクセス分布推定部と、
推定されたアクセス分布から、前記分散キャッシュクラスタに含まれるリソースの増減が、前記分散キャッシュクラスタを含むサービス提供システムに与える影響を示すリソース増減影響度を算出するリソース増減影響判定部と、
前記リソース増減影響度に基づき、前記分散キャッシュクラスタに含まれるリソースを増減するか、又は、他のサブシステムに含まれるリソースを増減するか、を決定するリソース増減対象算出部と、
前記リソース増減対象算出部が決定したサブシステムに対し、リソースの増減を指示する制御指示部と、
を備えることを特徴とするサブシステム制御ノード。
【請求項２】
前記リソース増減影響判定部は、前記キャッシュデータに対するアクセスがジップ分布に従うと仮定した場合の前記キャッシュデータに対するアクセスをモデル化するモデル関数と、前記分散キャッシュクラスタに格納できるキャッシュの個数と、に基づき前記リソース増減影響度を算出する請求項１のサブシステム制御ノード。
【請求項３】
前記リソース増減対象算出部は、前記サービス提供システムを構成するサブシステムのリソースを増加させる指示を受け取った場合、かつ、前記リソース増減影響度が予め定めた閾値以上の場合に、前記分散キャッシュクラスタに含まれるリソースを増加させ、
前記サービス提供システムを構成するサブシステムのリソースを減少させる指示を受け取った場合、かつ、前記リソース増減影響度が予め定めた閾値より小さい場合に、前記分散キャッシュクラスタに含まれるリソースを減少させる請求項１又は２のサブシステム制御ノード。
【請求項４】
前記リソース増減対象算出部は、前記分散キャッシュクラスタとは異なるサブシステムに含まれるリソースの増減を、前記分散キャッシュクラスタとは異なるサブシステムのリソース負荷情報に基づき決定する請求項１乃至３のいずれか一に記載のサブシステム制御ノード。
【請求項５】
分散キャッシュクラスタが格納するキャッシュデータに対するアクセスに関する情報を含むキャッシュ利用状況データから、前記キャッシュデータに対するアクセス分布を推定するアクセス分布推定工程と、
推定されたアクセス分布から、前記分散キャッシュクラスタに含まれるリソースの増減が、前記分散キャッシュクラスタを含むサービス提供システムに与える影響を示すリソース増減影響度を算出するリソース増減影響判定工程と、
前記リソース増減影響度に基づき、前記分散キャッシュクラスタに含まれるリソースを増減するか、又は、他のサブシステムに含まれるリソースを増減するか、を決定するリソース増減対象算出工程と、
前記リソース増減対象算出工程において決定したサブシステムに対し、リソースの増減を指示する工程と、
を含むことを特徴とするサブシステムの制御方法。
【請求項６】
前記リソース増減影響判定工程は、前記キャッシュデータに対するアクセスがジップ分布に従うと仮定した場合の前記キャッシュデータに対するアクセスをモデル化するモデル関数と、前記分散キャッシュクラスタに格納できるキャッシュの個数と、に基づき前記リソース増減影響度を算出する請求項５のサブシステムの制御方法。
【請求項７】
前記リソース増減対象算出工程は、前記サービス提供システムを構成するサブシステムのリソースを増加させる指示を受け取った場合、かつ、前記リソース増減影響度が予め定めた閾値以上の場合に、前記分散キャッシュクラスタに含まれるリソースを増加させ、
前記サービス提供システムを構成するサブシステムのリソースを減少させる指示を受け取った場合、かつ、前記リソース増減影響度が予め定めた閾値より小さい場合に、前記分散キャッシュクラスタに含まれるリソースを減少させる請求項５又は６のサブシステムの制御方法。
【請求項８】
前記リソース増減対象算出工程は、前記分散キャッシュクラスタとは異なるサブシステムに含まれるリソースの増減を、前記分散キャッシュクラスタとは異なるサブシステムのリソース負荷情報に基づき決定する請求項５乃至７のいずれか一に記載のサブシステムの制御方法。
【請求項９】
分散キャッシュクラスタが格納するキャッシュデータに対するアクセスに関する情報を含むキャッシュ利用状況データから、前記キャッシュデータに対するアクセス分布を推定するアクセス分布推定処理と、
推定されたアクセス分布から、前記分散キャッシュクラスタに含まれるリソースの増減が、前記分散キャッシュクラスタを含むサービス提供システムに与える影響を示すリソース増減影響度を算出するリソース増減影響判定処理と、
前記リソース増減影響度に基づき、前記分散キャッシュクラスタに含まれるリソースを増減するか、又は、他のサブシステムに含まれるリソースを増減するか、を決定するリソース増減対象算出処理と、
前記リソース増減対象算出処理において決定したサブシステムに対し、リソースの増減を指示する処理と、
をサブシステム制御ノードを制御するコンピュータに実行させるプログラム。
【請求項１０】
キャッシュデータの格納が可能な分散キャッシュノードと、
前記キャッシュデータに対するアクセスに関する情報を含むキャッシュ利用状況データを生成するキャッシュ利用状況監視部と、
を備える分散キャッシュクラスタと、
前記キャッシュ利用状況データから、前記キャッシュデータに対するアクセス分布を推定するアクセス分布推定部と、
推定されたアクセス分布から、前記分散キャッシュクラスタに含まれるリソースを増減した際に、前記分散キャッシュクラスタを含むシステムへ与える影響を示すリソース増減影響度を算出するリソース増減影響判定部と、
前記リソース増減影響度に基づき、前記分散キャッシュクラスタに含まれるリソースを増減するか、又は、他のサブシステムに含まれるリソースを増減するか、を決定するリソース増減対象算出部と、
前記リソース増減対象算出部が決定したサブシステムに対し、リソースの増減を指示する制御指示部と、
を備えるサブシステム制御ノードと、
を含むことを特徴とするサービス提供システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サブシステム制御ノード、サブシステムの制御方法、プログラム、サービス提供システムに関する。特に、分散キャッシュクラスタを含むサブシステム制御ノード、サブシステムの制御方法、プログラム、サービス提供システムに関する。
【背景技術】
【０００２】
複数のサブシステムから構成され、クライアントに対してサービスを提供するシステムが存在する。例えば、ＷＥＢ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）上に構成されるショッピングシステム等が該当する。このようなシステムには、クライアントからの要求を受け付け、受け付けた要求に基づき処理を行うアプリケーションサーバを複数含むアプリケーションサーバクラスタが含まれる。
【０００３】
また、上記のシステムは、特定のアプリケーションサーバで行った処理内容の一部をキャッシュし、他のアプリケーションサーバで再利用する分散キャッシュクラスタをサブシステムとして含むことも多い。このような分散キャッシュクラスタでは、データベースサーバに格納されたデータのリードキャッシュや、アプリケーションサーバの計算結果のキャッシュを構成ノードである分散キャッシュサーバに保持し、他のアプリケーションサーバでの使用を可能とする。
【０００４】
ここで、特許文献１において、ディスクストレージのアクセスを監視することでアクセスが集中する領域を特定し、その領域をキャッシュする技術が開示されている。
【０００５】
また、特許文献２において、アクセス元からの入出力コマンドに伴う入出力の状況を表す情報であるＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）状況情報に基づき、アクセス元からのＩ／Ｏ性能が低下するか否かを判断し、Ｉ／Ｏ性能を向上させるようにキャッシュの利用状況を変更する技術が開示されている。
【０００６】
さらに、特許文献３において、サービス需要の増減に応じてクラスタシステムのサーバ台数を調整する技術が開示されている。特許文献３が開示する技術は、クラスタ再構成技術を用いて、システムを構成する計算機を増減する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１０−００２９４２号公報
【特許文献２】特開２０１０−２８６９２３号公報
【特許文献３】特開２００５−０９２８６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。
【０００９】
上述のように、特定のサービスを提供するシステムを複数のサブシステムにより構成すると共に、分散キャッシュクラスタをサブシステムとして含む場合がある。分散キャッシュクラスタは、その中に含まれるリソースを増加することで、分散キャッシュクラスタの能力を増強することができる。
【００１０】
しかし、分散キャッシュクラスタの能力をみだりに増強したとしても、サービス提供システム全体の性能向上に貢献しないことがある。そのような場合には、分散キャッシュクラスタへリソース（計算機ノード）を割り当てる意義は薄く、分散キャッシュクラスタにはリソースを割り当てない、又は、他のサブシステムに割り当てる等の対応が望まれる。
【００１１】
しかしながら、複数のサブシステムから構成されるシステムにおいて、時間経過に応じた負荷の変動に対し、サブシステムに含まれるいずれの構成ノードを増減したらよいかといった指標は、特許文献１〜３を含めた先行技術には開示がない。そのため、分散キャッシュクラスタにリソースを割り当てたとしても、割り当てたリソースが有効に活用されず、システム全体の性能向上に寄与しないことが想定される。
【００１２】
以上のことから、リソースを有効に活用し、サービス提供システム全体の能力を向上させるサブシステム制御ノード、サブシステムの制御方法、プログラム、サービス提供システムが、望まれる。なお、分散キャッシュクラスタの能力増強と、サービス提供システム全体の性能に対する影響についての詳細は後述する。
【課題を解決するための手段】
【００１３】
本発明の第１の視点によれば、分散キャッシュクラスタが格納するキャッシュデータに対するアクセスに関する情報を含むキャッシュ利用状況データから、前記キャッシュデータに対するアクセス分布を推定するアクセス分布推定部と、推定されたアクセス分布から、前記分散キャッシュクラスタに含まれるリソースの増減が、前記分散キャッシュクラスタを含むサービス提供システムに与える影響を示すリソース増減影響度を算出するリソース増減影響判定部と、前記リソース増減影響度に基づき、前記分散キャッシュクラスタに含まれるリソースを増減するか、又は、他のサブシステムに含まれるリソースを増減するか、を決定するリソース増減対象算出部と、前記リソース増減対象算出部が決定したサブシステムに対し、リソースの増減を指示する制御指示部と、を備えるサブシステム制御ノードが提供される。
【００１４】
本発明の第２の視点によれば、分散キャッシュクラスタが格納するキャッシュデータに対するアクセスに関する情報を含むキャッシュ利用状況データから、前記キャッシュデータに対するアクセス分布を推定するアクセス分布推定工程と、推定されたアクセス分布から、前記分散キャッシュクラスタに含まれるリソースの増減が、前記分散キャッシュクラスタを含むサービス提供システムに与える影響を示すリソース増減影響度を算出するリソース増減影響判定工程と、前記リソース増減影響度に基づき、前記分散キャッシュクラスタに含まれるリソースを増減するか、又は、他のサブシステムに含まれるリソースを増減するか、を決定するリソース増減対象算出工程と、前記リソース増減対象算出工程において決定したサブシステムに対し、リソースの増減を指示する工程と、を含むサブシステムの制御方法が提供される。
【００１５】
本発明の第３の視点によれば、分散キャッシュクラスタが格納するキャッシュデータに対するアクセスに関する情報を含むキャッシュ利用状況データから、前記キャッシュデータに対するアクセス分布を推定するアクセス分布推定処理と、推定されたアクセス分布から、前記分散キャッシュクラスタに含まれるリソースの増減が、前記分散キャッシュクラスタを含むサービス提供システムに与える影響を示すリソース増減影響度を算出するリソース増減影響判定処理と、前記リソース増減影響度に基づき、前記分散キャッシュクラスタに含まれるリソースを増減するか、又は、他のサブシステムに含まれるリソースを増減するか、を決定するリソース増減対象算出処理と、前記リソース増減対象算出処理において決定したサブシステムに対し、リソースの増減を指示する処理と、をサブシステム制御ノードを制御するコンピュータに実行させるプログラムが提供される。
なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（ｎｏｎ−ｔｒａｎｓｉｅｎｔ）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。
【００１６】
本発明の第４の視点によれば、キャッシュデータの格納が可能な分散キャッシュノードと、前記キャッシュデータに対するアクセスに関する情報を含むキャッシュ利用状況データを生成するキャッシュ利用状況監視部と、を備える分散キャッシュクラスタと、前記キャッシュ利用状況データから、前記キャッシュデータに対するアクセス分布を推定するアクセス分布推定部と、推定されたアクセス分布から、前記分散キャッシュクラスタに含まれるリソースを増減した際に、前記分散キャッシュクラスタを含むシステムへ与える影響を示すリソース増減影響度を算出するリソース増減影響判定部と、前記リソース増減影響度に基づき、前記分散キャッシュクラスタに含まれるリソースを増減するか、又は、他のサブシステムに含まれるリソースを増減するか、を決定するリソース増減対象算出部と、前記リソース増減対象算出部が決定したサブシステムに対し、リソースの増減を指示する制御指示部と、を備えるサブシステム制御ノードと、を含むサービス提供システムが提供される。
【発明の効果】
【００１７】
本発明の各視点によれば、リソースを有効に活用し、サービス提供システム全体の能力を向上させるサブシステム制御ノード、サブシステムの制御方法、プログラム、サービス提供システムが、提供される。
【図面の簡単な説明】
【００１８】
【図１】一実施形態の概要を説明するための図である。
【図２】サービス提供システム１の全体構成の一例を示す図である。
【図３】第１の実施形態に係るサービス提供システム８の全体構成の一例を示す図である。
【図４】制御指示ノード６ａの動作の一例を示すフローチャートである。
【図５】アクセス状況の数値データの一例を示す図である。
【図６】推定したモデル関数のパラメータを用いて算出したアクセス分布グラフの一例を示す図である。
【図７】推定したモデル関数のパラメータを用いて算出したアクセス分布グラフの一例を示す図である。
【図８】推定したモデル関数のパラメータを用いて算出したアクセス分布グラフの一例を示す図である。
【発明を実施するための形態】
【００１９】
初めに、図１を用いて一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。
【００２０】
上述のように、複数のサブシステムから構成されるシステムにおいて、時間経過に応じた負荷の変動に対して、サブシステムに含まれるいずれのリソースを増減したらよいかといった点に関し、明確な指標が存在しない。そのため、分散キャッシュクラスタにリソースを割り当てたとしても、割り当てたリソースが有効に活用されず、システム全体の性能向上に寄与しない場合がある。以上のことから、リソースを有効に活用し、サービス提供システム全体の能力を向上させるサブシステム制御ノードが、望まれる。
【００２１】
そこで、一例として図１に示すサブシステム制御ノード１００を提供する。サブシステム制御ノード１００は、分散キャッシュクラスタが格納するキャッシュデータに対するアクセスに関する情報を含むキャッシュ利用状況データから、キャッシュデータに対するアクセス分布を推定するアクセス分布推定部１０１と、推定されたアクセス分布から、分散キャッシュクラスタに含まれるリソースの増減が、分散キャッシュクラスタを含むサービス提供システムに与える影響を示すリソース増減影響度を算出するリソース増減影響判定部１０２と、リソース増減影響度に基づき、分散キャッシュクラスタに含まれるリソースを増減するか、又は、他のサブシステムに含まれるリソースを増減するか、を決定するリソース増減対象算出部１０３と、リソース増減対象算出部１０３が決定したサブシステムに対し、リソースの増減を指示する制御指示部１０４と、を備える。
【００２２】
サブシステム制御ノード１００は、キャッシュデータに対するアクセス情報（キャッシュ利用状況データ）からアクセス分布を推定し、推定したアクセス分布から分散キャッシュクラスタの能力を増減（リソースを増減）した場合、システム全体の性能向上にどの程度寄与するかを定量化したリソース増減影響度を算出する。このリソース増減影響度と任意に指定された閾値とを比較し、分散キャッシュクラスタに含まれるリソースの増加によるシステム全体の性能向上が期待できる場合に限り、分散キャッシュクラスタに含まれるリソースを増加させる。その結果、リソースが有効に活用され、サービス提供システム全体の能力を向上させることができる。
【００２３】
さらに、下記の形態が可能である。
【００２４】
［形態１］上記第１の視点に係るサブシステム制御ノードのとおりである。
【００２５】
［形態２］前記リソース増減影響判定部は、前記キャッシュデータに対するアクセスがジップ分布に従うと仮定した場合の前記キャッシュデータに対するアクセスをモデル化するモデル関数と、前記分散キャッシュクラスタに格納できるキャッシュの個数と、に基づき前記リソース増減影響度を算出することが好ましい。
【００２６】
［形態３］前記リソース増減対象算出部は、前記サービス提供システムを構成するサブシステムのリソースを増加させる指示を受け取った場合、かつ、前記リソース増減影響度が予め定めた閾値以上の場合に、前記分散キャッシュクラスタに含まれるリソースを増加させ、前記サービス提供システムを構成するサブシステムのリソースを減少させる指示を受け取った場合、かつ、前記リソース増減影響度が予め定めた閾値より小さい場合に、前記分散キャッシュクラスタに含まれるリソースを減少させることが好ましい。
【００２７】
［形態４］前記リソース増減対象算出部は、前記分散キャッシュクラスタとは異なるサブシステムに含まれるリソースの増減を、前記分散キャッシュクラスタとは異なるサブシステムのリソース負荷情報に基づき決定することが好ましい。
【００２８】
［形態５］上記第２の視点に係るサブシステムの制御方法のとおりである。
【００２９】
［形態６］前記リソース増減影響判定工程は、前記キャッシュデータに対するアクセスがジップ分布に従うと仮定した場合の前記キャッシュデータに対するアクセスをモデル化するモデル関数と、前記分散キャッシュクラスタに格納できるキャッシュの個数と、に基づき前記リソース増減影響度を算出することが好ましい。
【００３０】
［形態７］前記リソース増減対象算出工程は、前記サービス提供システムを構成するサブシステムのリソースを増加させる指示を受け取った場合、かつ、前記リソース増減影響度が予め定めた閾値以上の場合に、前記分散キャッシュクラスタに含まれるリソースを増加させ、前記サービス提供システムを構成するサブシステムのリソースを減少させる指示を受け取った場合、かつ、前記リソース増減影響度が予め定めた閾値より小さい場合に、前記分散キャッシュクラスタに含まれるリソースを減少させることが好ましい。
【００３１】
［形態８］前記リソース増減対象算出工程は、前記分散キャッシュクラスタとは異なるサブシステムに含まれるリソースの増減を、前記分散キャッシュクラスタとは異なるサブシステムのリソース負荷情報に基づき決定することが好ましい。
【００３２】
［形態９］上記第３の視点に係るプログラムのとおりである。
【００３３】
［形態１０］前記リソース増減影響判定処理は、前記キャッシュデータに対するアクセスがジップ分布に従うと仮定した場合の前記キャッシュデータに対するアクセスをモデル化するモデル関数と、前記分散キャッシュクラスタに格納できるキャッシュの個数と、に基づき前記リソース増減影響度を算出することが好ましい。
【００３４】
［形態１１］前記リソース増減対象算出処理は、前記サービス提供システムを構成するサブシステムのリソースを増加させる指示を受け取った場合、かつ、前記リソース増減影響度が予め定めた閾値以上の場合に、前記分散キャッシュクラスタに含まれるリソースを増加させ、前記サービス提供システムを構成するサブシステムのリソースを減少させる指示を受け取った場合、かつ、前記リソース増減影響度が予め定めた閾値より小さい場合に、前記分散キャッシュクラスタに含まれるリソースを減少させることが好ましい。
【００３５】
［形態１２］前記リソース増減対象算出処理は、前記分散キャッシュクラスタとは異なるサブシステムに含まれるリソースの増減を、前記分散キャッシュクラスタとは異なるサブシステムのリソース負荷情報に基づき決定することが好ましい。
【００３６】
［形態１３］上記第４の視点に係るサービス提供システムのとおりである。
【００３７】
以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。
【００３８】
初めに、分散キャッシュクラスタを含むサービス提供システム１について説明する。
【００３９】
図２は、サービス提供システム１の全体構成の一例を示す図である。
【００４０】
サービス提供システム１には、アプリケーションサーバクラスタ２と、分散キャッシュクラスタ３と、分散ストレージシステム４と、リソースプール５と、制御指示ノード６と、制御イベント通知部７と、が含まれている。アプリケーションサーバクラスタ２、分散キャッシュクラスタ３、分散ストレージシステム４、の各サブシステムには、それぞれ構成ノード（図示せず）が含まれている。
【００４１】
サービス提供システム１は、アプリケーションサーバクラスタ２、分散キャッシュクラスタ３、分散ストレージシステム４、をネットワークにより接続することで、任意のサービスを提供する。例えば、ＷＥＢショッピングシステムのような３層モデルで実現されるシステムにおいては、ＷＥＢ画面を提供するＵＩ（プレゼンテーション層）が図２に示すサブシステムに加えて存在し、動的コンテンツを生成する機能をアプリケーションサーバクラスタ２が担当する。
【００４２】
また、生成された動的コンテンツ及びプレゼンテーション層の静的コンテンツの内容をキャッシュし高速化する機能を分散キャッシュクラスタ３が担当する。
【００４３】
さらに、静的コンテンツの情報や動的コンテンツを生成するための情報を格納するデータベース（データ層）の機能を分散ストレージシステム４が担当する。
【００４４】
アプリケーションサーバクラスタ２は、提供するサービスのＵＩ（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）機能などを提供する上位層からの処理リクエストを受け付け、必要に応じて分散ストレージシステム４が記憶するデータにアクセスし、そのデータを用いた計算処理を実行する。その際、アプリケーションサーバクラスタ２は、同一のリクエストに対する応答データ、一時的に保持する必要があるデータ（例えば、ＷＥＢショッピングシステムのショッピングカートに入れて注文していないデータ等）、分散ストレージシステム４からのリードキャッシュ、等を分散キャッシュクラスタ３に格納する。
【００４５】
さらに、アプリケーションサーバクラスタ２は、計算結果をリクエストの発行元に対して応答する。また、アプリケーションサーバクラスタ２は、同等の結果を応答すればよいリクエストに対しては、再度の計算処理や分散ストレージシステム４へのアクセスを行わず、分散キャッシュクラスタ３に保持されているデータを利用し、アクセスに対する応答を行う。
【００４６】
分散キャッシュクラスタ３は、アプリケーションサーバクラスタ２がアクセスする分散ストレージシステム４のデータや、アプリケーションサーバクラスタ２が計算して生成したデータを一時的に保持する。分散キャッシュクラスタ３は、アプリケーションサーバクラスタ２を初めとした他のシステム（サブシステム）からのアクセスリクエストに対し、一時的に保持したデータを用いて応答する。なお、キャッシュデータは、リクエストに対する応答を高速に行うという観点から、構成ノードのメモリ上に格納されることが多い。
【００４７】
分散キャッシュクラスタ３が存在することによって、アプリケーションサーバクラスタ２等は、分散ストレージシステム４に対する度重なるアクセスや、同じ計算結果となる計算の実行が、不要となる。その結果、アプリケーションサーバクラスタ２、分散ストレージシステム４の負荷が軽減され、サービス提供システム１全体の性能向上や、リソースの利用率の向上が期待できる。
【００４８】
分散ストレージシステム４は、提供するサービスに必要なデータを保持し、アプリケーションサーバクラスタ２等からのリクエストに対し応答する。分散ストレージシステム４は、データベースサーバやファイルシステムサーバ等を含んで構成されることが多い。
【００４９】
ここで、アプリケーションサーバクラスタ２、分散キャッシュクラスタ３、分散ストレージシステム４は、それぞれ単一又は複数の計算機ノードを含んで構成される。この計算機ノードが、各サブシステムの機能を実現するために必要なリソースに相当する。計算機ノードは、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、メモリ、ＨＤＤ等備えるサーバが想定できる。あるいは、１つのコンピュータ上に複数のコンピュータをエミュレーションする仮想マシンであってもよい。
【００５０】
リソースプール５は、アプリケーションサーバクラスタ２等に割り当てるリソースの増減を保持管理する制御ノードである。より具体的には、リソースプール５は、アプリケーションサーバクラスタ２等のサブシステムに対してリソースを割り当て、又は、離脱させる（取り除く）といった機能を実現するプログラムを実行する制御ノードである。なお、リソースプール５は、図２に示すように、リソースを一元管理しても、サブシステムごとに管理してもよい（サブシステムごとにリソースプールが存在してもよい）。
【００５１】
制御指示ノード６は、各サブシステムに含まれるリソースの増減を指示する。制御イベント通知部７は、制御指示ノード６に対してリソース増減処理を実行させる契機を通知する。例えば、システム管理者等からの指示が該当する。
【００５２】
次に、サービス提供システム１の性能について説明する。
【００５３】
分散キャッシュクラスタ３を使用することで、提供するサービスにおける参照系の処理リクエストの性能を向上することができる。
【００５４】
一方、更新系の処理リクエストに対しては、分散ストレージシステム４へのアクセスが必要であり、分散キャッシュクラスタ３の能力を増強しても（リソースを多く割り当てても）、サービス提供システム１全体の性能が向上するとは限らない。例えば、更新系の処理リクエストを受けた際、そのリクエストが、分散キャッシュクラスタ３が保持するキャッシュデータへのリードアクセスが支配的な処理の場合には、更新系のリクエストを受け付けた場合であっても、システム全体の性能向上が期待できる。あるいは、更新系の処理リクエストが、分散ストレージシステム４へのデータ書き込み時に、分散キャッシュクラスタ３にデータを一度書き込んだ上で、非同期的に分散ストレージシステム４にデータを書き込む場合にも、更新系のリクエストに対する分散キャッシュクラスタ３の貢献が期待できる。
【００５５】
しかし、これらの場合を除いて、更新系の処理リクエストに対する分散キャッシュクラスタ３の能力増強による、サービス提供システム１全体の性能向上に対する貢献はさほど期待できない。
【００５６】
リソースプール５が管理するリソースは、アプリケーションサーバクラスタ２、分散キャッシュクラスタ３、分散ストレージシステム４のいずれにも割り当て可能である。このようなサービス提供システム１の場合、サービスに対する負荷リクエストが増加した場合に、いずれのサブシステム（アプリケーションサーバクラスタ２等）にリソースを割り当てるべきであるかが問題となる。
【００５７】
その際、単にリソースが不足しているサブシステムに多くのリソースを割り当てるという対応が考えられる。しかし、このような対応では、サービス提供システム１のようなシステムでは、各サブシステムの動作が相互に影響するため、必ずしもシステム全体の性能が向上する訳ではない。より具体的には、分散キャッシュクラスタ３に多くのリソースを割り当てたとしても、分散キャッシュクラスタ３が応答できる負荷リクエストが増大していなければ、サービス提供システム１全体の性能向上には寄与しない。即ち、有限なリソースをどのような比率で各サブシステムに割り当てるべきかといった点は、特許文献１〜３を含めた先行技術には開示がない。
【００５８】
さらに、サービス提供システム１の負荷が減少した際には、余剰のリソースを停止させることが求められる。例えば、電力コストを下げるため、一部のリソースへの電源供給を停止することが行われる。あるいは、クラウドコンピューティングに代表されるリソースの利用量に比例してコストが定まる場合については、サービス提供者（システム運用者）は、できるだけリソースを縮退して稼働させる必要がある。
【００５９】
次に、サービス提供システム１において分散キャッシュクラスタ３のリソースを増減させた場合に、システム全体に与える影響について分析する。
【００６０】
初めに、分散キャッシュクラスタ３に含まれるリソースを減少する場合について考える。この場合、分散キャッシュクラスタ３が提供できるキャッシュ容量が削減されることを意味するため、キャッシュされないデータの種類が増える。従って、削減された容量に相当するキャッシュデータについては、キャッシュアクセスでなくアプリケーションサーバクラスタ２自身による再計算により応答する。そのため、アプリケーションサーバクラスタ２の負荷が増大する。さらに、再計算処理の増加に伴い、分散ストレージシステム４へのアクセス負荷が増大する。
【００６１】
次に、分散キャッシュクラスタ３に含まれるリソースを増加する場合について考える。この場合、アプリケーションサーバクラスタ２の計算結果をキャッシュする容量が大きくなるため、アプリケーションサーバクラスタ２による計算処理が減少する。そのため、分散ストレージシステム４に対するアクセス負荷も減少する。
【００６２】
その際、分散ストレージシステム４へのアクセス分布がジップ分布のような分布であれば、アクセス頻度の順位が低いデータは再びアクセスされる可能性は低い。例えば、ＷＥＢページへのアクセス頻度はジップ分布に従うことが多い。
【００６３】
アクセス頻度の順位が低いデータには、再度アクセスされる可能性が低いため、計算結果を分散キャッシュクラスタ３にキャッシュしたとしても、そのようなデータに再びアクセスすることは希である。そのため、アプリケーションサーバクラスタ２及び分散ストレージシステム４の負荷が、軽減されることはない。即ち、このような場合には、分散キャッシュクラスタ３の能力を増強したとしても、サービス提供システム１全体の性能向上は期待できない。
【００６４】
以上のことから、有限なリソースを有効活用するためには、分散キャッシュクラスタ３に含まれるリソースを増加させるのか、他のサブシステムに含まれるリソースを増加させるのか、を適切に定めることが求められる。
【００６５】
［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。
【００６６】
図３は、本実施形態に係るサービス提供システム８の全体構成の一例を示す図である。図３において図２と同一構成要素には、同一の符号を表し、その説明を省略する。
【００６７】
初めに、サービス提供システム８に含まれる各構成要素の詳細について説明する。
【００６８】
分散キャッシュクラスタ３ａは、キャッシュ利用状況監視部１０と、ノード増減部１１と、分散キャッシュノード１２及び１３と、を含んで構成される。
【００６９】
分散キャッシュノード１２及び１３は、分散キャッシュクラスタ３ａを実現するためのリソースである。図３では、２つのノードにより分散キャッシュクラスタ３ａは実現されているが、１つ以上の任意のノードを用いることができるのは勿論である。分散キャッシュノード１２及び１３は、分散キャッシュを実現する手段及びキャッシュデータの記憶手段（図示せず）を備える。
【００７０】
キャッシュ利用状況監視部１０は、分散キャッシュクラスタ３ａにキャッシュとして登録されているデータのアクセス回数を取得する。また、キャッシュ利用状況監視部１０は、制御指示ノード６ａに含まれるアクセス分布推定部４０からのリクエストに応じ、登録データのアクセス回数を応答する。
【００７１】
なお、キャッシュ利用状況監視部１０の実現形態として、様々な形態が考えられる。例えば、分散キャッシュノード１２及び１３が利用されるごとに利用履歴をカウントし、任意の計算機ノードで動作するプログラムによってこのような利用履歴を収集し、データベースプログラムなどの記憶管理手段により保持される方法が考えられる。
【００７２】
ノード増減部１１は、分散キャッシュクラスタ３ａを構成する分散キャッシュノードの台数を増加させ、又は、減少させる機能を持つ。ノード増減部１１は、分散キャッシュクラスタ３ａに割り当てられているリソースを分散キャッシュクラスタ３ａから離脱させリソースプール５にその旨を通知する。あるいは、割り当てられているノードを増加させる場合には、リソースプール５からリソースを確保して分散キャッシュクラスタ３ａに参加させる。
【００７３】
ノード増減部１１は、分散キャッシュクラスタ３ａを構成する分散キャッシュノードのいずれかにおいて、プログラムを実行することで実現するか、又は、複数のノードのプログラムが協調して動作することで実現できる。
【００７４】
ノード増減部１１が、分散キャッシュクラスタ３ａの分散キャッシュノードの数を減少させる際に、キャッシュデータを、キャッシュ利用状況監視部１０が取得しているアクセス回数に応じて、他の分散キャッシュノードに移行（マイグレーション）することもできる。例えば、分散キャッシュノードを減少させる際に、アクセス回数が多いキャッシュデータをキャッシュに残すようにキャッシュデータの再配置を行った後、分散キャッシュノードを離脱させる処理を行ってもよい。
【００７５】
さらに、このようなデータの再配置は行わず、離脱した分散キャッシュノードが保持していたキャッシュデータは、分散キャッシュクラスタ３ａから削除し、削除されたキャッシュデータに関してはアプリケーションサーバクラスタ２で再計算、又は、分散ストレージシステム４へ再アクセスにより取得してもよい。
【００７６】
アプリケーションサーバクラスタ２は、構成ノード２１及び２２と、ノード増減部２０から構成される。
【００７７】
構成ノード２１及び２２は、アプリケーションサーバクラスタ２に求められる機能を実現するためのリソースである。図３では、２つのノードによりアプリケーションサーバクラスタ２は実現されているが、１つ以上の任意のノードを用いることができるのは勿論である。
【００７８】
ノード増減部２０は、アプリケーションサーバクラスタ２を構成する構成ノード２１及び２２の台数を増減させる機能を持つ。ノード増減部２０は、ノード増減部１１と同様に、リソースプール５からリソースを確保してアプリケーションサーバクラスタ２に割り当て、あるいは、アプリケーションサーバクラスタ２からリソースを離脱させ、リソースプール５に戻す。
【００７９】
分散ストレージシステム４は、提供するサービスに必要なデータを保持し、アプリケーションサーバクラスタ２等からのリクエストに対し応答する。分散ストレージシステム４は、データベースサーバやファイルシステムサーバ等を含んで構成されることが多い。
【００８０】
また、多数の計算機ノードをネットワークにより結合し、計算機ノードのＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やメモリを用いてデータを格納又は利用するシステムを実現する分散ストレージ技術も存在する。このような分散ストレージ技術では、データをどの計算機ノードに配置するか、処理をどの計算機ノードで行うかといった機能を、プログラム又はハードウェアにより実現する。分散ストレージシステム４では、システムの状態に対し動作を動的に変更することで、システム内のリソース利用量を調整し、システム利用者（クライアント計算機）に対する性能向上を実現している。図３に示すサービス提供システム８では、このような分散ストレージ技術を採用した分散ストレージシステム４を用いる。ただし、分散ストレージシステム４のリソースを制御（計算機ノードを増減）しない場合は、分散ストレージ技術を採用していないストレージシステムやデータベースシステムも、分散ストレージシステム４に含めることが可能である。
【００８１】
さらに、分散ストレージシステムに含まれる構成ノードの一部を低消費電力モードに遷移させることで消費電力の抑制を実現するストレージシステムが、同一の出願人よって提案されている（日本特許出願：特願２０１０−２２４６９７に基づく優先権主張による国際出願ＰＣＴ／ＪＰ２０１１／０７１８５７）。本実施形態に係るサービス提供システム８では、このようなシステムを分散ストレージシステム４として利用することできる。
【００８２】
分散ストレージシステム４は、構成ノード３１及び３２と、ノード増減部３０から構成される。ノード増減部３０は、分散ストレージシステム４の一部のノードをストレージシステムに参加させつつ、低消費電力モードに遷移させる制御を実行してもよい。
【００８３】
制御指示ノード６ａは、アクセス分布推定部４０と、リソース増減影響判定部４１と、リソース増減対象算出部４２と、制御指示部４３と、から構成される。これらの各部は、計算機上のプログラム又はハードウェアにより実現する。制御指示ノード６ａが、上述のサブシステム制御ノード１００に相当する。制御指示ノード６ａに含まれる各部の動作は後述する。
【００８４】
制御イベント通知部７は、制御指示ノード６ａにリソース増減判定処理を実行させる契機を通知する。その際の実現には、様々考えられ、下記に列挙する。
【００８５】
第１に、制御指示ノード６ａと同一の計算機又は他の計算機によって動作するタイマを用いることが考えられる。即ち、定期的に判定処理を起動するモジュールとして制御イベント通知部７を実現する。
【００８６】
第２に、システム管理者が監視する画面等に付与されるボタンや、コマンドラインから実行されるコマンドのようなユーザインタフェースを用いることが考えられる。
【００８７】
第３に、外部に存在するクラスタ管理システム等からのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）経由等による命令が考えられる。
【００８８】
第４に、外部の負荷監視システムや負荷予測システムによってリソースの増減の予兆を検知した場合に、ＡＰＩ等を経由した命令が考えられる。
【００８９】
第５に、外部の電力監視システム等が、リソースの増減要求の必要性を検出した場合に、ＡＰＩ等を経由した命令が考えられる。
【００９０】
第６に、サービスを実現するサブシステムのいずれかのリソース（構成ノード）をそれぞれ監視し、ボトルネックや余剰を検知した場合にＡＰＩ等を経由した命令が考えられる。より具体的には、その際のボトルネックや余剰を計算機のＣＰＵ利用率などが一定時間、閾値より高い又は低い、といった方法で検知する。
【００９１】
第７に、サービスに対する負荷パターンの変更をシステムや管理者が検知して、通知することが考えられる。
【００９２】
以上のリソース増減判定処理を実行させる契機は、サービスを実現するシステムに対するリソースの調整要求と捉えることができる。以降、このようなリソース調整要求の情報として、リソースを増加するのか、又は、減少させるかについての指定が存在することを前提とする。ただし、リソースの増加又は減少について、制御指示ノード６ａの内部で判定してもよいことは勿論である。
【００９３】
次に、サービス提供システム８及び制御指示ノード６ａの動作について説明する。
【００９４】
図４は、制御指示ノード６ａの動作の一例を示すフローチャートである。
【００９５】
ステップＳ０１において、制御指示ノード６ａは、制御イベント通知部７が発行する制御イベント通知を受け付ける。なお、制御イベント通知の態様については前述したとおりである。
【００９６】
ステップＳ０２において、アクセス分布推定部４０は、キャッシュ利用状況監視部１０からキャッシュ利用状況データを取得し、リソース増減影響判定部４１にキャッシュ利用状況データを出力する。
【００９７】
ステップＳ０３において、リソース増減影響判定部４１は、受け取ったキャッシュ利用状況データからキャッシュに対するアクセス分布を推定する。
【００９８】
ここで、本ステップにおけるアクセス分布の推定方法について詳細に説明する。アクセス分布の確率モデルには、様々なモデルが存在する（例えば、一様分布やジップ分布等）。リソース増減影響判定部４１は、それらの分布モデルを利用し、アクセス分布を推定する。このアクセス分布は、提供するサービス（アプリケーション）が異なれば、それに応じて異なる分布モデルとなることが多い。また、同一のサービス（アプリケーション）であっても、時期や時間によって負荷パターンが異なることもある。
【００９９】
図５は、アクセス状況の数値データの一例を示す図である。図５のキャッシュキーは、アプリケーションサーバクラスタ２（あるいは、他のサブシステム）が、分散キャッシュクラスタ３ａが保持するキャッシュデータにアクセスするためのユニークなキーである。このキャッシュキーに対応付けられたキャッシュデータが分散キャッシュクラスタ３ａに格納、保持され、アクセス可能となる。例えば、ユーザごとに、何らかのデータを計算して応答するようなサービスの場合、キャッシュキーにはユーザＩＤのようなものを利用する。図５に示す例では、キャッシュキーごとに分散キャッシュクラスタ３ａの利用回数を記憶及び管理し、キャッシュ利用状況データとする。
【０１００】
キャッシュ利用状況監視部１０は、図５に示すようなデータをキャッシュ利用状況データとして応答する。なお、アクセス回数は、予め定められた期間内にアクセスされた回数とするのが望ましい。なぜならば、特殊な場合を除き、極端に古いキャッシュデータは、無効データと考えられるためである。
【０１０１】
リソース増減影響判定部４１は、キャッシュ利用状況データ（アクセス分布データ）とモデル関数を使用し、数学的手法を用いた近似や、非線形回帰分析により、モデル関数のパラメータを推定する。例えば、分布モデルとしてジップ分布を仮定すれば、下記の数式（１）により、パラメータｓの値が推定できる。
2013205962.tif 000003
なお、Ｎは、全要素の総数、ｋはアクセス順位とする。また、モデル関数を指数分布（ｙ＝ａ×ｅｂｘ）と仮定すれば、ａ及びｂの値を推定する。
【０１０２】
ステップＳ０４において、リソース増減影響判定部４１は、推定したモデル関数（アクセス分布）を用いて、リソースを増減した際の影響を定量化したスコアを算出し、算出したスコアをリソース増減対象算出部４２に出力する。このスコアが、上述のリソース増減影響度に相当する。
【０１０３】
その際、制御イベント通知（リソース調整要求）が、リソースを増加させる指示であれば、分散キャッシュクラスタ３ａに含まれるリソースを増加させた時のスコアを算出する。一方、制御イベント通知が、リソースを減少させる指示であれば、分散キャッシュクラスタ３ａに含まれるリソースを減少させた時のスコアを算出する。以下の説明では、制御イベント通知は、リソースを増加させる指示とする。
【０１０４】
なお、制御イベント通知が、リソースの増減に関する指示を明確化していない場合には、本ステップでリソースの増減を判定する。その際の判定方法には、様々な方法が考えられる。例えば、各サブシステムのリソース利用状況の監視情報を取得、あるいは、電力利用状況を監視している情報を取得し、実現しているサービスの応答時間等のＳＬＡ（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ）を取得し、これらに基づいて判定する。
【０１０５】
次に、リソース増減影響判定部４１におけるスコア算出について詳細に説明する。
【０１０６】
図６〜図８は、推定したモデル関数のパラメータを用いて算出したアクセス分布グラフの一例を示す図である。図６〜図８の横軸は、リクエストのアクセス量順位を示し、縦軸はそれぞれのアクセス回数を示す。
【０１０７】
この場合、分散キャッシュクラスタ３ａの保持できるキャッシュデータの容量は各図の横軸における幅と同様に扱うことができる。例えば、分散キャッシュクラスタ３ａに含まれる分散キャッシュノード（リソース）１台あたりのキャッシュ提供能力を１００ＭＢ、キャッシュキー１つあたりのキャッシュデータを平均１ＭＢとすると、分散キャッシュノード１台に格納できるキャッシュは１００個である。即ち、各図の横軸のアクセス順位１００位分をキャッシュとして保持できる。
【０１０８】
従って、分散キャッシュクラスタ３ａが、キャッシュデータをアクセスが多い順に保持するようなアルゴリズムで動作するとすれば、分散キャッシュクラスタ３ａが分散キャッシュノード３台で動作し、１台あたり１００個のキャッシュが保持できるとすると、分散キャッシュクラスタ３ａが保持しているキャッシュデータは、アクセス順位が１〜３００位のキャッシュデータとなる。なお、このキャッシュ容量の算出は、あくまでも概略であって、厳密には異なる。しかし、本実施形態における説明においてキャッシュ容量を厳密に計算する必要はない。
【０１０９】
また、１回目のアクセスはキャッシュを登録するアクセスであるため、アプリケーションサーバクラスタ２や分散ストレージシステム４の負荷低減に寄与しない。即ち、分散キャッシュクラスタ３ａがサービス提供システム８全体の性能向上に寄与しているアクセスは図７の領域２００となる。従って、この領域の面積を、分散キャッシュクラスタ３ａのシステム全体に対する性能向上に対する貢献とみなすことができる。
【０１１０】
さらに、分散キャッシュノードを１台追加した際のシステム全体の性能向上に対する貢献は図８の領域２０１となる。即ち、この領域２０１の面積が、分散キャッシュノードの増加によるシステム全体の性能向上への影響度と等価である。この領域２０１の面積を、本実施形態におけるスコアとして扱う。
【０１１１】
各キャッシュキーが保持するキャッシュ容量が、ほぼ等しいと仮定するならば、この面積に相当するスコアは次の式（２）から算出できる。
2013205962.tif 000004
なお、ｆ（ｘ）は分布モデル関数、ｘはアクセス順位、αは構成ノード１台あたりに保持可能なキャッシュキーの数、ｎは現在の分散キャッシュクラスタ３ａに含まれる構成ノードの台数である。同様に、構成ノードを１台離脱させた場合についても同様に算出することができる。
【０１１２】
ステップＳ０５において、リソース増減対象算出部４２は、算出されたスコアと予め定めた閾値との比較を行う。
【０１１３】
算出されたスコアが閾値以上の場合（ステップＳ０５、Ｙｅｓ分岐）には、リソースを増加する対象は分散キャッシュクラスタ３ａとする（ステップＳ０６）。一方、閾値を超えない場合（ステップＳ０５、Ｎｏ分岐）には、リソースを増加する対象を他のサブシステム（アプリケーションサーバクラスタ２、又は、分散ストレージシステム４）とする（ステップＳ０７）。
【０１１４】
ここで、ステップＳ０７に遷移した場合は、分散キャッシュクラスタ３ａではなく、他のサブシステム（アプリケーションサーバクラスタ２又は分散ストレージシステム４）に含まれるリソースを増加する。いずれのサブシステムのリソースを増加するかの選択方法は、任意の方法を採用することができる。一例として、以下のような方法が考えられる。
【０１１５】
アプリケーションサーバクラスタ２又は分散ストレージシステム４のリソース負荷情報（例えば、ＣＰＵ利用率や、メモリ利用量）と、閾値を比較し、閾値を超えるサブシステムにリソースを割り当てる。さらに、両者のリソース負荷情報が閾値を超える場合には、より逼迫しているサブシステムにリソースを割り当てる。
【０１１６】
なお、ステップＳ０１において、制御イベント通知として、リソースを減少させる指示を受け付けた場合には、ステップＳ０５の判定結果により分岐先が異なる。より具体的には、算出されたスコアが閾値以上である場合に、他のサブシステムのリソースを減少させ、閾値を超えない場合に、分散キャッシュクラスタ３ａのリソースを減少させる。
【０１１７】
また、スコアと比較する閾値を、制御指示ノード６ａに操作ＩＦ（図示せず）やその他のプログラムによって、システム管理者が決定してもよい。さらに、過去の制御履歴に基づき閾値を調整してもよい。
【０１１８】
ステップＳ０８において、リソース増減対象算出部４２が、ステップＳ０６又はステップＳ０７で決定されたリソースを増減する対象となるサブシステムを制御指示部４３に通知する。制御指示部４３は、対象となるサブシステム（分散キャッシュクラスタ３ａ、アプリケーションサーバクラスタ２又は分散ストレージシステム４）のノード増減部に対してリソース増減要求を発行する。
【０１１９】
本実施形態に係る制御指示ノード６ａは、３層モデルに基づくシステムアーキテクチャの各層のリソース制御、分散キャッシュクラスタに含まれるリソースの増減、クラウドコンピューティングを実現するインフラストラクチャにおける複数システムを混載させた分散システムの各リソースの制御等に適用できる。
【０１２０】
以上のように、本実施形態に係るサービス提供システム８では、分散キャッシュクラスタ３ａのキャッシュ利用状況をキャッシュ利用状況監視部１０が監視し、アクセス分布推定部４０がキャッシュ利用状況データからキャッシュデータに対するアクセス分布を推定する。さらに、リソース増減影響判定部４１が、推定されたアクセス分布に基づいてスコアを算出し、算出したスコアに基づいてリソースを増減する対象となるサブシステムを選択する。特に、分散キャッシュクラスタ３ａに含まれる分散キャッシュノードの増減によるシステム全体への影響を推定し、推定結果を用いてリソースの割り当て先となるサブシステムを決定する。
【０１２１】
より具体的には、推定したアクセス分布を用いて、分散キャッシュクラスタ３ａの能力を増強した場合のシステム全体に与える影響を数値化（スコアを算出）し、リソース（分散キャッシュノード）の増加に値する場合に限り、リソースを増加する。一方、分散キャッシュクラスタ３ａの能力を増強しても、システム全体の性能向上に対する貢献が期待できない場合は、他のサブシステムのリソースを増加する。その結果、リソースを増加する効果の高いサブシステムにリソースを追加できるため、リソースの利用効率が高いシステム運用を実現することができる。
【０１２２】
さらに、サービス提供システム８全体の消費電力を抑制することもできる。リクエスト分布から、サブシステムに対する負荷分布を算出し、各サブシステムに必要なリソースを算出し、算出結果に合わせてリソースを減少する。このようなシステムの運用により、サービス提供システム８全体の消費電力を抑制できる。即ち、リソースを有効活用することで、サービス提供システム８の消費電力を抑制できる。
【０１２３】
なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
【符号の説明】
【０１２４】
１、８  サービス提供システム
２  アプリケーションサーバクラスタ
３、３ａ  分散キャッシュクラスタ
４  分散ストレージシステム
５  リソースプール
６、６ａ  制御指示ノード
７  制御イベント通知部
１０  キャッシュ利用状況監視部
１１、２０、３０  ノード増減部
１２、１３  分散キャッシュノード
２１、２２、３１、３２  構成ノード
４０、１０１  アクセス分布推定部
４１、１０２  リソース増減影響判定部
４２、１０３  リソース増減対象算出部
４３、１０４  制御指示部
１００  サブシステム制御ノード
２００、２０１  領域
【図１】
2013205962.tif 000005
【図２】
2013205962.tif 000006
【図３】
2013205962.tif 000007
【図４】
2013205962.tif 000008
【図５】
2013205962.tif 000009
【図６】
2013205962.tif 000010
【図７】
2013205962.tif 000011
【図８】
2013205962.tif 000012