JP4824807B2

JP4824807B2 - 負荷管理装置、情報処理システムおよび負荷管理方法

Info

Publication number: JP4824807B2
Application number: JP2009228704A
Authority: JP
Inventors: 友雄三崎; 和彦松政; 真也沖; 敏宏幸田; 甫小林; 諭岡野; 毅保呂
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2009-09-30
Filing date: 2009-09-30
Publication date: 2011-11-30
Anticipated expiration: 2029-09-30
Also published as: JP2011076470A

Description

本発明は、並列処理における負荷管理装置、方法およびその装置を備える情報処理システムに関する。

地球温暖化と言う問題が、昨今聞かれる。地球温暖化対策の一つとしては電力需要を減らすことがある。電力は一般的に水力発電、太陽光発電、風力発電、地熱発電などの自然由来の発電や、原子力を使う原子力発電や、ガス、石油、石炭などを燃料として燃やし発電を行う火力発電によって供給されている。この中でも特に火力発電は地球温暖化を進める大きな要因となっている。電力需要を減らせば火力発電の発電量も減らすことができるので、その分地球温暖化も抑止されうる。

ＩＴ（Information Technology）やＩＣＴ（Information and Communication Technology）の分野でも、コンピュータやネットワーク機器、データセンタ機器が消費する電力を低減する必要性が指摘され始めている。

近年のインターネットの普及により、多くのデータセンタは、ネットワーク接続型の形態を有しており、インターネットなどの外部のネットワークからの仕事要求を受けて処理を行う。これらのデータセンタのなかには、一度に多くのアクセスを処理するために複数の並列に配置されたサーバを備える構成を採用したものがある（特許文献１参照）。

このようなデータセンタを管理する運用管理システムとしては、株式会社野村総合研究所が提供する千手（登録商標）や株式会社日立製作所が提供するＯｐｅｎＴＰ１（登録商標）や富士通株式会社が提供するシステムウォーカーがある。
また、ネットワーク接続装置の消費電力低減装置が知られている（特許文献２参照）。

特開２００８−２２５７９３号公報特開２００７−９７１２６号公報

城田真琴、クラウドの衝撃、東洋経済新報社、２００９年

現行の運用管理システムはロードバランサを備え、アクセス数が少ない場合でも個々のサーバに要求を分散させる。アクセス数によっては一部のサーバに要求が振られない場合もあり、そのようなサーバはアイドル状態で要求を待ち受けることになる。しかしながら、ユーザからのアクセスがなく仕事が発生していないアイドル状態でも、基本ＯＳ（operating system）機能とネットワークモニタリング等のタスクとが稼動しており相当の電力が消費されている。サーバ機器にもよるが、アイドル状態の消費電力は、概ね最大性能発揮時の消費電力の３０％から７０％であると考えられる。省エネの観点から見ると、サーバをアイドル状態に置いておくことは電力の無駄使いと言える。

また、近年クラウドと呼ばれるデータセンタサービスの形態が現れたが（非特許文献１参照）、上述の課題はこのクラウドにおいても生じうる。

本発明はこうした課題に鑑みてなされたものであり、その目的は、要求の並列処理において消費電力を低減できる負荷管理装置の提供にある。

本発明のある態様は負荷管理装置に関する。この負荷管理装置は、互いにネットワークによって接続された複数の情報処理装置を管理する負荷管理装置である。この負荷管理装置は、各情報処理装置の運用に必要な電気料金を記憶する電気料金テーブルと、電気料金テーブルを参照し、電気料金がより高い情報処理装置に含まれる、ネットワークからの要求を受付可能な第１状態となっている要求処理ユニットを電気料金がより安い情報処理装置に含まれる、第１状態よりも省電力の第２状態となっている要求処理ユニットで代替することができるかどうかを判別する電気料金ルーティング部と、電気料金ルーティング部において代替可能と判別された場合に、第１状態となっている要求処理ユニットを第２状態に設定し、第２状態となっている要求処理ユニットを第１状態に設定する状態設定部と、を備える。

「要求」は、例えば情報処理装置に対する処理の要求であってもよい。

この態様によると、電気料金を考慮して要求を処理させる要求処理ユニットを代替できる。

本発明の別の態様は、情報処理システムである。この情報処理システムは、互いにネットワークによって接続された複数の情報処理装置と、複数の情報処理装置を管理する負荷管理装置と、を備える。負荷管理装置は、各情報処理装置の運用に必要な電気料金を記憶する電気料金テーブルと、電気料金テーブルを参照し、電気料金がより高い情報処理装置に含まれる、ネットワークからの要求を受付可能な第１状態となっている要求処理ユニットを電気料金がより安い情報処理装置に含まれる、第１状態よりも省電力の第２状態となっている要求処理ユニットで代替することができるかどうかを判別する電気料金ルーティング部と、電気料金ルーティング部において代替可能と判別された場合に、第１状態となっている要求処理ユニットを第２状態に設定し、第２状態となっている要求処理ユニットを第１状態に設定する状態設定部と、を含む。

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

本発明によれば、要求の並列処理において消費電力を低減できる。

第１の実施の形態に係る情報処理システムおよびその周辺を示す概略図である。図１におけるアクセスの流れを説明するための説明図である。図１のロードバランサの機能および構成を示すブロック図である。図３の接続テーブルを示すデータ構造図である。図３の第１サーバ群状態テーブルを示すデータ構造図である。図１の負荷管理装置およびその周辺の機能および構成を示すブロック図である。図６の負荷履歴テーブルを示すデータ構造図である。図８（ａ）〜（ｄ）は、ステータス画面の代表画面図である。警告画面の代表画面図である。状態設定画面の代表画面図である。図１の負荷管理装置における一連の処理を時系列に沿って示すチャートである。図１の情報処理システムが証券会社のインターネット株取引システムを提供するデータセンタとして使用される場合の、負荷履歴テーブルの一例を示すデータ構造図である。図１の情報処理システムが検索サービスを提供するデータセンタとして使用される場合の、負荷履歴テーブルの一例を示すデータ構造図である。第２の実施の形態に係る負荷管理装置を有するクラウドコンピューティングシステムを示す概略図である。図１４の負荷管理装置およびその周辺の機能および構成を示すブロック図である。図１４の負荷履歴テーブルを示すデータ構造図である。図１４のリソース状態テーブルを示すデータ構造図である。図１４の電気料金テーブルを示すデータ構造図である。図１４の表示制御部によってディスプレイに表示されるステータス画面の代表画面図である。オーバヘッドと性能のかねあいを説明するための、各サーバ群の稼働率を示すグラフである。本発明のある実施の形態を大学の共用データセンタに適用した場合の負荷履歴テーブルを示すデータ構造図である。

以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。

（第１の実施の形態）
第１の実施の形態に係る負荷管理装置は、複数の並列に配置されたサーバ群でユーザからのアクセスを処理している情報処理システムの管理サーバとして好適に利用される。負荷管理装置は、ネットワークから情報処理システム宛に到来する要求の負荷を過去の運用実績から予測し、その予測値が少ない場合は不必要なサーバ群のＯＳを休眠させたり、サーバ群の電源自体をオフにする。そして残りのサーバ群に要求を割り当てる。これにより無駄な待機電力を削り情報処理システム全体の消費電力を低減できる。

図１は、第１の実施の形態に係る情報処理システム２およびその周辺を示す概略図である。情報処理システム２は、ネットワーク接続型のデータセンタであり、例えば証券会社のインターネット株取引システムを提供するデータセンタである。情報処理システム２はネットワーク４と接続され、同じくネットワーク４に接続されている少なくともひとつのユーザ端末６から要求を受ける。ここで要求とは、例えばネットワーク４のユーザからのアクセスである。アクセスとは、ユーザ端末６と情報処理システム２のひとつのサーバ群とが接続を確立して一連の情報をやりとりすることである。異なるユーザ端末からのアクセスは異なるアクセスであり、同じユーザ端末からでも異なるアクセスがなされうる。
ネットワーク４は、例えばＬＡＮ（Local Area Network）・ＷＡＮ（Wide Area Network）・インターネットである。ユーザ端末６は、ユーザが使用するコンピュータであり、例えば有線でネットワーク４に接続された家庭用デスクトップコンピュータや、無線でネットワーク４に接続されたラップトップコンピュータである。

情報処理システム２は、負荷管理装置１０と、情報処理装置２０と、ロードバランサ３０と、を備える。
ロードバランサ３０は、ネットワーク４と接続され、また情報処理装置２０に含まれる個々のサーバ群とバスＢＵＳを介して接続される。ロードバランサ３０は、データの流れの観点からは情報処理装置２０とネットワーク４との間に位置し、ネットワーク４からの情報処理装置２０に対するアクセスを仲介する。
ロードバランサ３０はさらに、情報処理装置２０に含まれる複数のサーバ群のうちアクセスを受付可能な状態（以下、稼動状態と称する）に設定されたサーバ群に、ユーザからのアクセスを割り当てる。

負荷管理装置１０は、情報処理装置２０およびロードバランサ３０を管理する管理サーバである。負荷管理装置１０は以下で説明する負荷予測機能などの他に、例えば株式会社野村総合研究所が提供する先手（登録商標）と同様のサーバ運用管理のための機能を搭載する。

負荷管理装置１０は、ネットワーク４からの負荷をロードバランサ３０から取得して記録する一方、過去に要求された負荷をもとに今後発生する負荷を予測し、その予測された負荷が所定のモード切替値Ｍｏより少なくなると省電力モードに入る。この省電力モードでは負荷管理装置１０は、アクセスの処理に不要なサーバ群を稼動状態よりも省電力の状態（以下、省電力状態と称する）に設定する。ここで負荷とは、例えばサーバ群が行う仕事の量を表す値であり、単位時間当たりのアクセスの数を基に定められる。例えば負荷は、単位時間当たりのアクセスの数と比例関係などの数学的関係を有する値であってもよい。また、負荷は単位時間当たりのアクセスの数に上限値または下限値若しくはその両方を課した値であってもよい。以下では、負荷が単に単位時間当たりのアクセスの数（以下、アクセス数と称す）である場合について説明する。
なお、予測された負荷がモード切替値Ｍｏ以上の場合は負荷管理装置１０は全てのサーバ群を稼動状態に設定する。このモードを通常モードと呼ぶ。

情報処理装置２０は、ネットワーク４からのアクセスを処理する。情報処理装置２０は、並列に配置された複数のサーバ群を含み、そのそれぞれのサーバ群はアクセスの処理単位である要求処理ユニットとして機能する。本実施の形態では情報処理装置２０は、第１サーバ群２２ａと、第２サーバ群２２ｂと、第３サーバ群２２ｃと、第４サーバ群２２ｄと、第５サーバ群２２ｅと、を含む。しかしながら情報処理装置２０が２つ以上の任意の数のサーバ群を含んでよいことは本明細書に触れた当業者には理解される。

第１サーバ群２２ａは、第１フロントエンドサーバ２４ａと、第１アプリケーションサーバ２６ａと、第１データベースサーバ２８ａと、を含む。これはいわゆる３階層のサーバ群であり、これら１セットでアクセスの処理単位を構成する。第１フロントエンドサーバ２４ａはバスＢＵＳと接続される。第１フロントエンドサーバ２４ａは、ウェブサーバとも呼ばれ、ＨＴＴＰ（HyperText Transfer Protocol）に則り、ユーザ端末６のウェブブラウザに対して、ＨＴＭＬ（HyperText Markup Language）や画像などのオブジェクトの表示を提供するサービスが動作するサーバコンピュータである。第１アプリケーションサーバ２６ａは、第１フロントエンドサーバ２４ａからジャバサーブレット（Java Servlet、ジャバは登録商標）の処理などのアプリケーションに関する機能を切り出して実現するサーバコンピュータである。第１データベースサーバ２８ａは、第１アプリケーションサーバ２６ａのアプリケーションが使用するデータが格納されるサーバコンピュータである。第１フロントエンドサーバ２４ａ、第１アプリケーションサーバ２６ａ、および第１データベースサーバ２８ａは、公知の情報処理技術を使用して実現される。本実施の形態では、第１フロントエンドサーバ２４ａと第１アプリケーションサーバ２６ａと第１データベースサーバ２８ａとは別個のサーバであり、この順に直列に接続されている。

第２サーバ群２２ｂ、第３サーバ群２２ｃ、第４サーバ群２２ｄ、および第５サーバ群２２ｅは、それぞれ第１サーバ群２２ａと同等の構成を有する。情報処理装置２０では、第１サーバ群２２ａ〜第５サーバ群２２ｅのアクセスの処理能力はほぼ等しく設定される。第１サーバ群２２ａ〜第５サーバ群２２ｅはそれぞれ負荷管理装置１０と接続され、負荷管理装置１０によって管理される。

なお、個々のサーバ群に含まれるサーバは個々にもしくは全体としてＯＳに管理されている。個々のサーバ群の稼動状態は、ユーザからのアクセスを即時処理可能な状態である。この状態は、サーバ群がユーザからのアクセスを処理しつつ新たなアクセスを処理可能である状態と、ユーザからのアクセスがなく仕事が発生していないアイドル状態と、を含む。稼動状態では、たとえアイドル状態であっても少なくとも基本ＯＳ機能とネットワークモニタリングのタスクは稼動しており、その分電力を消費する。本発明者の当業者としての経験から、このアイドル状態での消費電力は、サーバ機器の種類によってピークアクセス数での稼動時のおよそ３０％から７０％の範囲にある。特に標準的なサーバ機器を用いる場合は６０％程度である。ここでピークアクセス数とは、サーバ群がその処理速度を落とさずに稼動できるアクセス数の範囲の上限値であり、サーバ群ごとにその仕様を基に予め定められている。ここで処理速度とは、サーバ群におけるユーザからのアクセスの処理速度である。

個々のサーバ群の省電力状態は、ユーザからのアクセスを即時処理できない状態である。この状態は、サーバ群へ電源は供給されているがそのサーバ群はユーザからのアクセスを処理できないＯＳ休眠状態を含む。サーバ群は負荷管理装置１０から休眠導入信号を受信するとＯＳ休眠状態となる。このＯＳ休眠状態では、サーバ群のＯＳは休眠（ハイボネート）しており、ユーザからのアクセスがあってもそれを受け付けない。ＯＳ休眠状態にあるサーバ群は負荷管理装置１０から休眠解除信号を受信すると、稼動状態に復帰する。ＯＳ休眠状態から稼動状態に復帰するためには通常数秒から数十秒かかる。また本発明者の当業者としての経験から、ＯＳ休眠状態におけるサーバ群の消費電力は、ピークアクセス数での稼働時のおよそ５％から１０％である。

サーバ群の省電力状態はさらに、サーバ群への電源が遮断されている電源オフ状態を含む。サーバ群は負荷管理装置１０から電源オフ信号を受信すると電源オフ状態となる。サーバ群は負荷管理装置１０からＷＯＬ（Wake Up on LAN）信号などの電源オン信号を受信すると、稼動状態に復帰する。電源オフ状態から稼動状態に復帰するためには通常数分かかる。
詳細は後述するが、本実施の形態ではサーバ群が省電力状態から稼動状態に復帰するためにかかる時間（以下、オーバヘッドと称す）と、省電力状態で低減される消費電力とのかねあいで、省電力状態とされるサーバ群の数が決定される。つまり、予測されるアクセス数を処理するのに必要なぎりぎりの数のサーバ群だけを稼動状態とすると、突然のアクセス数の増大に対して対処できなくなる可能性がある。一方で稼動状態のサーバ群の数が多いほど待機電力由来の消費電力も大きくなる。そこでそれらの影響が拮抗するように、省電力状態とされるサーバ群の数が決定される。

図２は、図１におけるアクセスの流れを説明するための説明図である。以下、１回のアクセスにおいて、少なくともひとつのパケットがユーザ端末６とアクセスが割り当てられたサーバ群との間でやりとりされる場合について説明する。このパケットは、送信元のＩＰアドレスであるソースＩＰアドレスＳｒｃと、受信先のＩＰアドレスであるあて先ＩＰアドレスＤｓｔと、後述するシーケンス番号と、を含む。多くの場合において一回のアクセスにつき複数個のパケットがユーザ端末６とサーバ群との間を行き来する。図２では第３サーバ群２２ｃがアクセスに割り当てられたとする。ユーザ端末６のＩＰアドレスを「１７５．３４．１１．２１」、ロードバランサ３０のＩＰアドレスを「１００．１０．１０．１０」、第３サーバ群２２ｃに含まれる第３フロントエンドサーバ２４ｃのＩＰアドレスを「１２１．２１．１５．３」とする。

ロードバランサ３０は、ユーザ端末６に対して仮想サーバとして働く。つまり、ネットワーク４では、ユーザが情報処理装置２０が有する情報資源にアクセスしようとする場合、かかる情報資源のＵＲＬ（Uniform Resource Locator）がロードバランサ３０のＩＰアドレス「１００．１０．１０．１０」に名前解決されるよう設定されている。

まずユーザは、ユーザ端末６のウェブブラウザに対して情報処理装置２０が有する情報資源のＵＲＬを指定する。ユーザ端末６のウェブブラウザによってソースＩＰアドレスＳｒｃを「１７５．３４．１１．２１」、あて先ＩＰアドレスＤｓｔを「１００．１０．１０．１０」とした第１パケットＰ１が生成され、ネットワーク４に送られる。ロードバランサ３０は第１パケットＰ１を受信し、稼動状態にあるサーバ群のなかから第３サーバ群２２ｃを選択してこのアクセスを割り当てる。ロードバランサ３０は、第１パケットＰ１のソースＩＰアドレスＳｒｃはそのままにしてあて先ＩＰアドレスＤｓｔを「１２１．２１．１５．３」とした第２パケットＰ２をバスＢＵＳに送出する。第３サーバ群２２ｃの第３フロントエンドサーバ２４ｃは自己宛の第２パケットＰ２を受信し、第２パケットＰ２の指示にしたがい処理を行う。その処理の結果ユーザ端末６へ戻すべき情報は、ソースＩＰアドレスＳｒｃを「１２１．２１．１５．３」、あて先ＩＰアドレスＤｓｔを「１７５．３４．１１．２１」とした第３パケットＰ３に含められ、第３フロントエンドサーバ２４ｃからバスＢＵＳに送出される。ロードバランサ３０は第３パケットＰ３を受信する。ロードバランサ３０は、第３パケットＰ３のあて先ＩＰアドレスＤｓｔはそのままにしてソースＩＰアドレスＳｒｃを「１００．１０．１０．１０」とした第４パケットＰ４をネットワーク４に送る。ユーザ端末６は自己宛の第４パケットＰ４をネットワーク４から受信する。
以下、ユーザ端末６からロードバランサ３０に送られるパケット（第１パケットＰ１）を総称して行きパケット、ロードバランサ３０から情報処理装置２０へ送られるパケット（第２パケットＰ２）を総称して割当パケットという。

図３は、ロードバランサ３０の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

ロードバランサ３０は、第１記憶装置３２と、要求取得部３４と、要求割当部３６と、負荷検出部３８と、を備える。

第１記憶装置３２は、第１サーバ群状態テーブル３２２と、接続テーブル３２４と、を含む。第１サーバ群状態テーブル３２２は、現在設定されているであろうサーバ群の状態を記憶するテーブルである。第１サーバ群状態テーブル３２２の詳細は後述する。

接続テーブル３２４は、同一アクセス内のパケットは同じサーバ群へ送られること（以下、アクセスの同一性と称す）を保証するためのテーブルである。図４は、接続テーブル３２４を示すデータ構造図である。接続テーブル３２４には、後述する接続テーブル更新部３６８によってアクセスに対応するエントリ１１８が生成される。一回のアクセスに対してひとつのエントリが対応する。接続テーブル３２４のエントリ１１８は、アクセスしてきたユーザ端末６のＩＰアドレスであるユーザ端末ＩＰアドレス２１０と、ロードバランサ３０のＩＰアドレスであるロードバランサＩＰアドレス２１２と、ロードバランサ３０によってそのアクセスに割り当てられたサーバ群のフロントエンドサーバのＩＰアドレスである割当サーバ群ＩＰアドレス２１４と、ユーザ端末６が同一の場合にアクセスの異同を判別するためのシーケンス番号２１６と、を有する。同一ユーザ端末６において、異なるアクセスには異なるシーケンス番号２１６が割り振られる。以下、サーバ群のフロントエンドサーバのＩＰアドレスを単にサーバ群のＩＰアドレスと称す。

図３に戻る。要求取得部３４は、ネットワーク４と接続される。要求取得部３４は、ネットワーク４から到来するユーザ端末６からのアクセスの行きパケットを取得する。この際、要求取得部３４は行きパケットに含まれるあて先ＩＰアドレスＤｓｔを基に自己宛のパケットであるか否かを判別する。要求取得部３４は、取得した行きパケットを要求割当部３６に渡す。

なお、本明細書において「渡す」とは、ある機能ブロックからある機能ブロックに情報要素に対する処理が移ることを意味する。要求取得部３４と要求割当部３６との間で言うと、渡すとは、例えば要求取得部３４が図示しない一時メモリを有し、取得した行きパケットをそこに蓄えた上で、要求割当部３６からの要請に応じて適宜行きパケットを一時メモリから要求割当部３６に伝達することである。また渡すとは、第１記憶装置３２が図示しない記憶領域を有し、要求取得部３４は取得した行きパケットをその記憶領域に書き込み、要求割当部３６は適宜その記憶領域から必要な行きパケットを読み出して処理することであってもよい。

要求割当部３６は、ユーザ端末６からのアクセスの行きパケットを稼動状態にあるサーバ群のうちのひとつに割り当てる。要求割当部３６は、同一接続判断部３６２と、サーバ群選択部３６４と、アドレス変換部３６６と、接続テーブル更新部３６８と、を含む。

同一接続判断部３６２は、要求取得部３４から行きパケットを取得し、その行きパケットが新規のアクセスによるものか否かを判別する。同一接続判断部３６２は、取得した行きパケットのソースＩＰアドレスＳｒｃとシーケンス番号とを読み取る。同一接続判断部３６２は、読み取られたソースＩＰアドレスＳｒｃとシーケンス番号とをキーとして接続テーブル３２４のエントリ１１８を検索し、それらと一致するエントリ１１８が存在する場合、そのエントリ１１８に含まれる割り当てられたサーバ群の割当サーバ群ＩＰアドレス２１４を取得する。同一接続判断部３６２は、この取得された割当サーバ群ＩＰアドレス２１４と行きパケットとをアドレス変換部３６６に渡す。

なお、このように一致するエントリ１１８が存在する場合は、当該行きパケットは既にあるサーバ群（エントリ１１８の割当サーバ群ＩＰアドレス２１４で指定されるサーバ群）に割り当てられたアクセスのなかのひとつのパケットである。アドレス変換部３６６は、渡された行きパケットのあて先ＩＰアドレスＤｓｔを、同一接続判断部３６２によって接続テーブル３２４から取得された割当サーバ群ＩＰアドレス２１４に変換する。このようにあて先ＩＰアドレスＤｓｔが変換された行きパケットはアドレス変換部３６６から割当パケットとしてバスＢＵＳに送出される。

一致するエントリ１１８が存在しない場合は、同一接続判断部３６２は当該行きパケットをサーバ群選択部３６４に渡す。この場合は同一接続判断部３６２は新規のアクセスを検知したと言うことができる。

サーバ群選択部３６４は、同一接続判断部３６２から新規のアクセスに対応する行きパケットを受け取ると、第１サーバ群状態テーブル３２２を参照してそのアクセスを処理させるサーバ群を選択する。第１サーバ群状態テーブル３２２は、負荷管理装置１０におけるアクセス数の予測に基づき負荷管理装置１０によって更新される。
図５は、第１サーバ群状態テーブル３２２を示すデータ構造図である。第１サーバ群状態テーブル３２２は、サーバ群のＩＰアドレス２０２と、サーバ群の状態２０４と、サーバ群の稼働率２０６と、を対応付けて記憶する。サーバ群の稼働率２０６は、サーバ群のピークアクセス数に対する現在そのサーバ群が処理しているアクセス数の割合を％単位で示す。この稼働率２０６は、図示されない稼働率更新部によって、予め定められているサーバ群のピークアクセス数と、接続テーブル３２４から分かるサーバ群に現在割り当てられているアクセス数とから演算され更新されてもよい。あるいは、図示されない稼働率更新部が稼動状態にあるサーバ群から稼働率を取得し、第１サーバ群状態テーブル３２２の稼働率２０６を更新してもよい。または、負荷管理装置１０によって更新されてもよい。

図３に戻る。サーバ群選択部３６４は、第１サーバ群状態テーブル３２２に登録されたサーバ群のなかからサーバ群の状態２０４を参照して稼動状態にあるサーバ群を抽出する。後述する負荷管理装置１０によってロードバランサ３０が省電力モードに設定されているか通常モードに設定されているかによって、サーバ群選択部３６４が稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択するアルゴリズムは異なる。以下それぞれの場合について説明する。

１．省電力モード
省電力モードでは、サーバ群選択部３６４は、稼動状態にあるサーバ群の稼働率が１００％となるように、稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択する。例えば図５の例では、サーバ群選択部３６４は新規のアクセスを処理させるサーバ群として第３サーバ群２２ｃを選択する。また、例えば第１サーバ群２２ａ、第２サーバ群２２ｂ、第３サーバ群２２ｃが稼動状態に設定されており、第１サーバ群２２ａの稼働率が１００％、第２サーバ群２２ｂの稼働率が８０％、第３サーバ群２２ｃの稼働率が０％の場合、サーバ群選択部３６４は新規のアクセスを処理させるサーバ群として第２サーバ群２２ｂを選択する。

２．通常モード
通常モードでは、全てのサーバ群が稼動状態にある。サーバ群選択部３６４は、予め設定されている負荷分散アルゴリズムにしたがって、新規のアクセスを処理させるのに最適なサーバ群を選択する。ここで使用される負荷分散アルゴリズムは、順番にサーバ群が選択されるラウンドロビン方式や、処理しているアクセス数が最小のサーバ群を選択する最小接続方式や、１番早く応答しているサーバ群を選択する最速方式などの公知のアルゴリズムである。

サーバ群選択部３６４は、選択されたサーバ群のＩＰアドレスと新規のアクセスに対応する行きパケットとをアドレス変換部３６６に渡す。アドレス変換部３６６は、渡された行きパケットのあて先ＩＰアドレスＤｓｔを、サーバ群選択部３６４によって選択されたサーバ群のＩＰアドレスに変換する。このようにあて先ＩＰアドレスＤｓｔが変換された行きパケットはアドレス変換部３６６から割当パケットとしてバスＢＵＳに送出される。

接続テーブル更新部３６８は、サーバ群選択部３６４で新規のアクセスに対してサーバ群の選択が行われる毎に、その選択に関する情報をサーバ群選択部３６４から取得し、接続テーブル３２４に対応するエントリを追加する。この選択に関する情報は、新規のアクセスを行ったユーザのユーザ端末６のユーザ端末ＩＰアドレス２１０と、ロードバランサＩＰアドレス２１２と、新規のアクセスに対して選択されたサーバ群の割当サーバ群ＩＰアドレス２１４と、シーケンス番号２１６と、を含む。
また、接続テーブル更新部３６８は、適宜不要となったエントリを削除する。

負荷検出部３８は、要求取得部３４によって取得されたアクセスのアクセス数を周期的に検出する。負荷検出部３８は、接続テーブル３２４を参照してエントリ１１８の数をカウントすることで、所定の時間間隔で情報処理装置２０全体へのアクセス数（以下、総アクセス数と称す）を取得する。また負荷検出部３８は、要求取得部３４と要求割当部３６との間の行きパケットの流れを監視し、所定の時間間隔でアクセスの数をカウントし、そのカウント数から単位時間当たりのアクセスの数、つまりアクセス数を導出してもよい。なお、負荷検出部３８は要求取得部３４の前段や要求割当部３６の後段など、ロードバランサ３０の任意の箇所で負荷を監視してもよい。負荷検出部３８は、検出した総アクセス数を負荷管理装置１０に渡す。

負荷検出部３８における上述の時間間隔は負荷管理装置１０のモードを更新する基準となる時間間隔であり、負荷管理装置１０によって定められる。以下、この時間間隔の長さを有する期間を時間帯と呼ぶ。つまり、時間間隔は例えば１５分間隔であり、時間帯は例えば２００９年９月１６日の０９：００−０９：１５である。

図６は、負荷管理装置１０およびその周辺の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

負荷管理装置１０は、第２記憶装置１１０と、負荷取得部１２０と、学習部１３０と、状態設定部１４０と、乖離判定部１５０と、オーバライド部１６０と、表示制御部１７０と、を備える。第２記憶装置１１０は、負荷履歴テーブル１１２と、第２サーバ群状態テーブル１１４と、を含む。
負荷取得部１２０は、ロードバランサ３０の負荷検出部３８からそこで検出された総アクセス数を取得する。つまり、負荷取得部１２０はネットワーク４からの情報処理装置２０に対するアクセスの総アクセス数を取得する。負荷取得部１２０はこの総アクセス数をテーブル更新部１３２および乖離判定部１５０に渡す。後述する適応モードでは、負荷取得部１２０は取得した総アクセス数を予測総アクセス数の代わりに負荷比較部１４２に渡す。

学習部１３０は、テーブル更新部１３２と、負荷予測部１３４と、を含む。学習部１３０は、テーブル更新部１３２によって総アクセス数の履歴を負荷履歴テーブル１１２に記憶し、その記憶をふまえて負荷予測部１３４によって今後発生しうる総アクセス数を予測する。これにより、運用実績が長いほど省エネの観点からより賢くなる運用管理が可能となる。

テーブル更新部１３２は、負荷取得部１２０によって取得された総アクセス数をもとに事前にないし事後的に、負荷履歴テーブル１１２を更新する。負荷履歴テーブル１１２はしたがって、過去に要求された総アクセス数を記録する。ここで事前に更新する、とは例えば総アクセス数にカウントされているアクセスがサーバ群によって処理される前若しくは処理されている間に更新するという意味であり、事後的に更新するとは例えばそのようなアクセスがサーバ群によって処理されてしまった後に更新するという意味である。あるいはまた、事前に更新するとは、総アクセス数にカウントされているアクセスがサーバ群によって確かに処理されることを前提として更新することであってもよく、事後的に更新するとはそのようなアクセスがサーバ群によって処理されたことを確認した後に更新することであってもよい。

図７は、負荷履歴テーブル１１２を示すデータ構造図である。負荷履歴テーブル１１２は、時間帯２１８と、その時間帯が属する属性２２０と、その時間帯に取得された総アクセス数２２２と、その時間帯に稼動状態に設定される稼動サーバ群の数２２４と、その時間帯の平均稼動率２２６と、を対応付けて記憶する。時間帯が属する属性２２０とは、例えば月曜日、火曜日などの曜日や、平日休日の別や、年末年始とそれ以外の別や、午前午後の別や、それらの任意の組み合わせである。平均稼働率２２６は、稼動状態に設定されるサーバ群の稼働率の平均値である。
テーブル更新部１３２は、稼動状態に設定される稼動サーバ群の数２２４を取得するために第２サーバ群状態テーブル１１４を参照してもよい。

図６に戻る。負荷予測部１３４は、過去に要求された総アクセス数をもとに今後発生する総アクセス数を予測する。負荷予測部１３４は、未来の時間帯毎に総アクセス数を予測する。後述の状態設定部１４０もまた、この時間帯毎に必要に応じてサーバ群の状態を設定する。特に負荷予測部１３４は、総アクセス数予測の対象となる時間帯（以下、予測対象の時間帯と称す）について負荷履歴テーブル１１２を参照して総アクセス数を予測する。以下、負荷予測部１３４によって予測される総アクセス数を予測総アクセス数と称す。

負荷予測部１３４では、情報処理システム２が使用される目的に応じた総アクセス数の傾向（トレンド）を負荷履歴テーブル１１２から抽出する処理と、抽出された傾向に基づいて予測対象の時間帯の総アクセス数を予測する処理とが行われる。特に負荷予測部１３４では、時間帯の属性をキーとして総アクセス数の傾向が抽出される。

負荷予測部１３４は予測対象の時間帯が属する属性に対応する総アクセス数を負荷履歴テーブル１１２から取得してその時間帯に対する予測総アクセス数とする。
例えば、曜日がキーとして設定された場合、負荷予測部１３４は負荷履歴テーブル１１２を参照し、曜日毎の総アクセス数の平均値を演算する。負荷予測部１３４は、これらの平均値のうち予測対象の時間帯の曜日にマッチする曜日の平均値を予測総アクセス数とする。また、例えば平日休日の別がキーとして設定された場合、負荷予測部１３４は負荷履歴テーブル１１２を参照し、平日の総アクセス数の平均値と休日の総アクセス数の平均値を演算する。負荷予測部１３４は、これらの平均値のうち予測対象の時間帯が平日であれば平日の、休日であれば休日の平均値を予測総アクセス数とする。
なお、ここでは一例として平均値を用いたが、代表値などの他の統計的なパラメータであってもよい。

負荷予測部１３４は予測総アクセス数を乖離判定部１５０および状態設定部１４０の負荷比較部１４２に渡す。

状態設定部１４０は、予測総アクセス数がモード切替値Ｍｏより少ない場合、予測対象の時間帯において情報処理装置２０に含まれる少なくともひとつのサーバ群を省電力状態に設定し、負荷管理装置１０およびロードバランサ３０を省電力モードに設定する。なお、負荷管理装置１０およびロードバランサ３０は、状態設定部１４０によって省電力モードに設定されなければ、通常モードで動作するよう設定されている。

状態設定部１４０におけるモード切替値Ｍｏは、情報処理装置２０の性能が落ちない範囲に設定される。ここで性能とは、例えばどれだけのアクセス数をどの程度の速さで処理できるかということである。あるいは性能とは、ひとつのアクセスが処理されるのにかかる時間などのレスポンスタイムであってもよい。また、情報処理装置２０の性能が落ちる、とは、例えばあるサーバ群に対してピークアクセス数を越える数のアクセスが割り当てられ、その結果そのサーバ群の処理速度が落ちることにより情報処理装置２０全体のアクセスの処理速度が落ちることである。

例えば第１サーバ群２２ａから第５サーバ群２２ｅのピークアクセス数が全て２０００であるとする。この場合モード切替値Ｍｏを９０００に設定すると、予測総アクセス数が８５００であっても予測対象の時間帯で少なくともひとつのサーバ群を省電力状態に設定しなくてはならない。ここでは第５サーバ群２２ｅを省電力状態に設定したとする。残りの４つのサーバ群２２ａ〜２２ｄのトータルのピークアクセス数は８０００であり、予測総アクセス数８５００よりも少ない。したがってこの場合、予測対象の時間帯が到来したときに、残りの４つのサーバ群２２ａ〜２２ｄのうちの少なくともひとつのサーバ群がピークアクセス数以上のアクセスを処理しなくてはならなくなる可能性が高くなり、その場合そのサーバ群の処理速度は低下する。これにより情報処理装置２０全体の処理速度が落ちる可能性がある。このような状況を避けるために、モード切替値Ｍｏは情報処理装置２０の性能が落ちない範囲に設定される。上述の例ではモード切替値Ｍｏは８０００以下に設定されればよい。

状態設定部１４０は、サーバ群の最大性能を発揮せしめる前提で、アクセスを処理させるサーバ群を決定し、予測対象の時間帯において残りのサーバ群を省電力状態に設定する。この場合サーバ群の最大性能を発揮せしめる、とは、例えばサーバ群にピークアクセス数でアクセス処理を行わせることであり、言い換えるとサーバ群を１００％の稼働率で使用することである。さらに状態設定部１４０は、予測総アクセス数の変動により情報処理装置２０の性能が落ちると予測される場合には、予測対象の時間帯において省電力状態に設定されている少なくともひとつのサーバ群を稼動状態に設定する。

サーバ群を省電力状態または稼動状態に設定することに関して、状態設定部１４０では、予測対象の時間帯において稼動状態にするサーバ群の数に応じた予測総アクセス数の範囲が定められている。状態設定部１４０は例えば予測総アクセス数が０から第１しきい値Ｔ１の範囲にあれば予測対象の時間帯においてひとつのサーバ群のみを稼動状態とし、他のサーバ群を省電力状態とする。表１は、状態設定部１４０における状態設定に関して、稼動状態とするサーバ群の数と、ＯＳ休眠状態とするサーバ群の数と、電源オフ状態とするサーバ群の数と、予測総アクセス数の範囲と、の関係を示す。Ｔ２は第２しきい値、Ｔ３は第３しきい値であり、Ｔ１＜Ｔ２＜Ｔ３である。個々のしきい値は予め情報処理システム２の管理者によって設定される。

第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３はそれぞれサーバ群を１００％の稼働率で使用することを前提に設定される。つまり上述の第１サーバ群２２ａから第５サーバ群２２ｅのピークアクセス数が全て２０００であるとする例では、Ｔ１＝２０００、Ｔ２＝４０００、Ｔ３＝６０００である。この場合、予測総アクセス数のアクセスを処理するのに必要最低限の数のサーバ群が予測対象の時間帯において稼動状態とされる。また、例えば第１しきい値Ｔ１と第２しきい値Ｔ２との間にあった予測総アクセス数が増大して第２しきい値Ｔ２を越えた場合、そのままだと予測対象の時間帯において少なくともひとつのサーバ群の稼働率が１００％を上回ると予測されるので、予測対象の時間帯において稼動状態とするサーバ群の数をひとつ増やして情報処理装置２０の処理速度の低下を回避する。

状態設定部１４０は、負荷比較部１４２と、稼動サーバ群決定部１４４と、状態信号生成部１４６と、を含む。
負荷比較部１４２は、負荷予測部１３４から取得した予測総アクセス数と、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３、モード切替値Ｍｏとの大小関係を判別する。この大小関係は例えば「Ｔ２＜予測総アクセス数＜Ｔ３」という情報である。負荷比較部１４２はこの大小関係に関する情報を稼動サーバ群決定部１４４に渡す。

稼動サーバ群決定部１４４は、この情報を基に表１のストラテジにしたがい、次の時間帯で状態の切替が必要な場合には、稼動状態とするサーバ群とＯＳ休眠状態とするサーバ群と電源オフ状態とするサーバ群を決定する。稼動サーバ群決定部１４４は次の時間帯の到来に合わせて、この決定に基づき第２サーバ群状態テーブル１１４およびロードバランサ３０の第１サーバ群状態テーブル３２２を更新する。稼動サーバ群決定部１４４は、次の時間帯の到来に合わせて、状態の切り替えが必要なサーバ群の情報を状態信号生成部１４６に渡す。稼動サーバ群決定部１４４は、状態の切り替えが必要ない場合には処理を中断または終了し、次の情報を待ち受ける。
第２サーバ群状態テーブル１１４は図５に示される第１サーバ群状態テーブル３２２と同様のテーブルである。なお、負荷管理装置１０またはロードバランサ３０のいずれか一方がサーバ群状態テーブルを備え、そのテーブルを備えない方が備える方のテーブルを参照する構成としてもよい。

稼動サーバ群決定部１４４は、表１のストラテジから稼動状態、ＯＳ休眠状態および電源オフ状態とするサーバ群の数をまず決める。次に稼動サーバ群決定部１４４は第２サーバ群状態テーブル１１４を参照し、次の時間帯でサーバ群の状態を切り替える必要があるか、言い換えると負荷予測部１３４が予測した次の時間帯での予測総アクセス数に対応する各状態のサーバ群の数と第２サーバ群状態テーブル１１４に登録されている現在の各状態のサーバ群の数とが一致するか否かを判断する。そこで一致する場合は稼動サーバ群決定部１４４は処理を中断または終了する。

一致しない場合は、稼動サーバ群決定部１４４は次の時間帯でそれぞれの状態にするサーバ群を決める。ここでそれぞれの状態にするサーバ群を決めるアルゴリズムは、例えば稼動状態、ＯＳ休眠状態、電源オフ状態の順番で第１サーバ群２２ａから第５サーバ群２２ｅに順番に割り当てる方式である。言い換えると、サーバ群の状態を切り替える必要がある場合、稼動状態にあるサーバ群はなるべく稼動状態のままでおいておく方式である。この場合、サーバ群の状態を切り替える回数が少なくてすみ、切り替えに伴うオーバヘッドの低減、レスポンスの高速化に寄与する。また、オーバヘッドが気にならない間隔（例えば、一週間や一月）でランダムに設定してもよい。この場合、サーバ機器のＨＤＤ（Hard Disk Drive）などの消耗品の耐用年数を平均化できる。また、サーバ群の性能が異なる場合は、その異なる性能に基づき決めてもよい。

なお、稼動サーバ群決定部１４４でのサーバ群を決める上述のアルゴリズムでは、特に稼動状態を省電力状態に切り替える場合は、アクセスの同一性が考慮されてもよい。例えば、稼動サーバ群決定部１４４は、稼動状態を省電力状態に切り替える場合、次の時間帯の到来に合わせて第２サーバ群状態テーブル１１４および第１サーバ群状態テーブル３２２を更新して省電力状態に切り替えるべきサーバ群への新規アクセスの割り当てを制限する一方、ロードバランサ３０の接続テーブル３２４を参照し、省電力状態に切り替えるべきサーバ群へのアクセスがなくなったことを確認してから状態の切り替えが必要なサーバ群の情報を状態信号生成部１４６に渡してもよい。これによりアクセスの同一性が保証されうる。

状態信号生成部１４６は第１サーバ群２２ａ〜第５サーバ群２２ｅに接続される。
状態信号生成部１４６は、状態の切り替えが必要なサーバ群の情報に基づきそのサーバ群に対して切替に対応する休眠導入信号、休眠解除信号、電源オフ信号、および電源オン信号のうちのいずれかを送る。例えば第３サーバ群２２ｃを稼動状態（ＯＳ休眠状態）からＯＳ休眠状態（稼動状態）とする必要がある場合、状態信号生成部１４６は第３サーバ群２２ｃに対して休眠導入信号（休眠解除信号）を送出する。また、第３サーバ群２２ｃを稼動状態（電源オフ状態）から電源オフ状態（稼動状態）とする必要がある場合、状態信号生成部１４６は第３サーバ群２２ｃに対して電源オフ信号（電源オン信号）を送出する。
状態信号生成部１４６によって省電力状態から稼動状態に設定されたサーバ群は、それが稼動状態であることが稼動サーバ群決定部１４４によってロードバランサ３０の第１サーバ群状態テーブル３２２に記録されるので、ロードバランサ３０の要求割当部３６によって新規のアクセスが割り当てられる。

ロードバランサ３０の負荷検出部３８における検出の時間間隔に関し、負荷管理装置１０は図示しない時間間隔設定部を有し、時間間隔設定部は総アクセス数の変動率を監視し、変動率が大きいほど時間間隔を短く設定してもよい。これにより、より適応的なサーバ群状態の制御が可能となる。また、処理を簡素化するという観点からは時間間隔は情報処理システム２の管理者によって予め定められてもよい。

負荷管理装置１０は、予測総アクセス数を基に状態設定部１４０でサーバ群の状態を設定する上述の負荷予測モードの他に、負荷取得部１２０で取得された総アクセス数を基に状態設定部１４０でサーバ群の状態を適応的に設定する適応モードを有する。以下、この適応モードについて説明する。

乖離判定部１５０は、予測された総アクセス数と実際の総アクセス数との差が大きい、つまりその差の絶対値が所定の乖離値よりも大きい場合、状態設定部１４０に実際の総アクセス数に基づいてサーバ群の状態を設定せしめる。
乖離判定部１５０は、負荷取得部１２０からロードバランサ３０で検出された現在の時間帯に対応する総アクセス数を取得する。また乖離判定部１５０は負荷予測部１３４から現在の時間帯に対して予測された予測総アクセス数も取得する。そして乖離判定部１５０は、両者の差を演算する。その差の絶対値が乖離値より大きい場合は、乖離判定部１５０は状態設定部１４０の負荷比較部１４２に、予測総アクセス数の代わりに負荷取得部１２０からの総アクセス数を使用させる。この場合負荷比較部１４２は、負荷取得部１２０からの総アクセス数と、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３、モード切替値Ｍｏとの大小関係を判別する。状態設定部１４０はかかる大小関係を使用して上述の処理と同様の処理を行う。これにより状態設定部１４０は、予測された総アクセス数と実際の総アクセス数との差が大きい場合に、実際の総アクセス数に応じて適応的にサーバ群の状態を設定することができる。

また、負荷管理装置１０は、情報処理システム２の管理者がマニュアルでサーバ群の状態を設定できるマニュアル設定モードも有する。オーバライド部１６０は、負荷管理装置１０に付随するキーボードなどの入力装置１２から管理者によるマニュアル設定を受け付ける。オーバライド部１６０はこのマニュアル設定を受け付けると状態設定部１４０に、このマニュアル設定に基づいてサーバ群の状態を設定せしめる。これにより急激な使用環境の変化にも対応可能となる。

表示制御部１７０は、負荷取得部１２０からは現在の時間帯における総アクセス数を、第２サーバ群状態テーブル１１４からは現在のサーバ群の状態を、取得する。表示制御部１７０は、負荷管理装置１０に付随するディスプレイ１４に総アクセス数とサーバ群の状態とを示すステータス画面４００ａ〜４００ｄ（図８（ａ）〜（ｄ）で後述）を表示させる。また、表示制御部１７０は、乖離判定部１５０において予測された総アクセス数と実際の総アクセス数との差の絶対値が乖離値よりも大きいと判断された場合、ディスプレイ１４に警告画面４０２（図９で後述）を表示させる。また、表示制御部１７０は、管理者によるマニュアル設定のための状態設定画面４０４（図１０で後述）をディスプレイ１４に表示させる。

図８（ａ）〜（ｄ）は、ステータス画面４００ａ〜４００ｄの代表画面図である。ここでは、第１サーバ群２２ａから第５サーバ群２２ｅのピークアクセス数が全て２０００であるとする。図８（ａ）〜図８（ｄ）はそれぞれ現在の時間帯における総アクセス数が１６００、２８００、４４００、７０００の場合に対応する。
図８（ａ）は、現在の時間帯における総アクセス数が１６００の場合に対応するステータス画面４００ａの代表画面図である。ステータス画面４００ａは、総アクセス数領域４０６と、グラフ４０８と、オーバライドボタン４１０と、を含む。総アクセス数領域４０６は、現在の時間帯における総アクセス数を示す。グラフ４０８は、各サーバ群の稼働率を示す。グラフ４０８において「△」はＯＳ休眠状態を示し、「×」は電源オフ状態を示す。オーバライドボタン４１０は、押し下げられるとオーバライド部１６０をトリガする。オーバライドボタン４１０が押し下げられると表示制御部１７０は状態設定画面４０４をディスプレイ１４に表示させる。図８（ｂ）〜図８（ｄ）についても同様である。

図９は、警告画面４０２の代表画面図である。
図１０は、状態設定画面４０４の代表画面図である。状態設定画面４０４は、設定領域４１２と、設定ボタン４１４と、を含む。状態設定画面４０４を開いた直後の状態では、設定領域４１２には各サーバ群の現在の状態がラジオボタン方式で示されている。設定領域４１２では第１サーバ群２２ａ〜第５サーバ群２２ｅはそれぞれサーバ群Ａ〜サーバ群Ｅという名称で表示されている。管理者はマウスなどの入力装置１２を使用して各サーバ群の状態を選択し、設定ボタン４１４を押し下げる。すると設定領域４１２に設定された各サーバ群の状態が所望のマニュアル設定としてオーバライド部１６０に送られる。これにより、第１サーバ群２２ａ〜第５サーバ群２２ｅのそれぞれを稼動状態とするか、ＯＳ休眠状態とするか、または電源オフ状態とするかを設定できる。

図１１は、負荷管理装置１０における一連の処理を時系列に沿って示すチャートである。負荷検出部３８における総アクセス数検出の時間間隔は１５分間隔である場合を考える。２００９年９月１６日の９：１５に、負荷取得部１２０はロードバランサ３０から総アクセス数を取得する（Ｓ５０２）。テーブル更新部１３２は、取得された総アクセス数をもとに負荷履歴テーブル１１２を更新する（Ｓ５０４）。一方、２００９年９月１６日の９：１５−９：３０の時間帯内でステップＳ５０４の負荷履歴テーブル１１２更新と重ならないときに、負荷予測部１３４は負荷履歴テーブル１１２を参照して次の時間帯（９：３０−９：４５）の総アクセス数を予測する（Ｓ５０６）。状態設定部１４０は、予測総アクセス数とモード切替値Ｍｏ、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３との大小比較を行う（Ｓ５０８）。状態設定部１４０は、その大小比較を基に次の時間帯においてサーバ群の状態の切替が必要か否かを判断する（Ｓ５１０）。状態の切替が必要でない場合（Ｓ５１０のＮ）、次の時間帯が到来してもサーバ群の状態の設定は行わない。状態の切替が必要な場合（Ｓ５１０のＹ）、状態設定部１４０は次の時間帯におけるサーバ群の状態を決定する（Ｓ５１２）。次の時間帯が到来すると、つまり２００９年９月１６日の９：３０になると、状態設定部１４０はサーバ群の状態をステップＳ５１２で決定されたように設定する。また、状態設定部１４０は平行して第２サーバ群状態テーブル１１４およびロードバランサ３０の第１サーバ群状態テーブル３２２を更新する（Ｓ５１４）。負荷管理装置１０はこの処理を時間帯単位で繰り返す。

以上の構成による負荷管理装置１０および情報処理システム２の動作を説明する。情報処理システム２は例えばインターネット上のデータセンタであり、ユーザはユーザ端末６を使用してこの情報処理システム２にあるウェブページなどの情報資源にアクセスする。負荷管理装置１０はこのようなアクセスの履歴を負荷履歴テーブル１１２に蓄積する。そして負荷管理装置１０はこの負荷履歴テーブル１１２を解析し、発生しうるアクセス数を予測する。負荷管理装置１０はその予測値に基づいて稼動状態とするサーバ群を選択し、残りのサーバ群を省電力状態に設定する。予測対象の時間帯においてユーザからのアクセスは稼動状態にあるサーバ群のうちのひとつのサーバ群に割り当てられ、そこで処理される。したがって、省電力状態としたサーバ群の待機電力分だけ情報処理システム２全体の消費電力を低減できる。また、予測値の増大により情報処理システム２の処理能力を増やす必要が出てくると、負荷管理装置１０は稼動状態とするサーバ群の数を増やす。

上述の第１の実施の形態において、記憶装置の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。

本実施の形態に係る負荷管理装置１０によると、データセンタなどの情報処理システム２が使用される目的、例えば証券業務や検索エンジンなど、に応じた総アクセス数の傾向を把握し、それを用いて今後発生しうる総アクセス数を予測できる。そしてこの予測総アクセス数が少ない場合は、予測対象の時間帯において少なくともひとつのサーバ群が省電力状態に設定される。
上述した通り稼動状態のサーバ群の消費電力は、アイドル状態であってもピーク時のおよそ６０％である。これに対して省電力状態のサーバ群の消費電力はピーク時のおよそ０〜１０％である。本実施の形態では、アクセス数が少ないと予測され、したがってアクセスを処理する必要がないと予測されるサーバ群がある場合はそれらのサーバ群をアイドル状態ではなく省電力状態としている。これにより、情報処理装置２０全体の消費電力を低減でき、電力の無駄遣いを抑え、省エネ化を図ることができる。
また本実施の形態に係る負荷管理装置１０では、情報処理システム２が使用される目的に応じた総アクセス数の傾向を把握し、それを用いて今後発生しうる総アクセス数を予測しているので、個々の使用目的に対して最適な消費電力低減化、省エネ化を実現できる。

また本実施の形態に係る負荷管理装置１０では、負荷履歴テーブル１１２は、取得された総アクセス数と、その総アクセス数が取得された時間帯が属する属性と、を対応付けて記憶する。したがって、総アクセス数の傾向を属性を基準にして把握することができる。さらに負荷管理装置１０では、予測対象の時間帯が属する属性に対応する総アクセス数を負荷履歴テーブル１１２から取得してその時間帯に対して予測される総アクセス数とする。したがって、属性を情報処理システム２の使用目的に応じて適切に設定することにより、予測される総アクセス数の精度を向上することができる。

図１２は、本実施の形態に係る情報処理システム２が証券会社のインターネット株取引システムを提供するデータセンタとして使用される場合の、負荷履歴テーブル１１２ａの一例を示すデータ構造図である。ここでは稼動サーバ群の数および平均稼動率は説明を明瞭とするため省略される。この場合の総アクセス数の傾向としては、証券取引所の取引時間内にアクセスが集中することがある。また、証券取引所が閉まってからしばらくはいわゆるバッチ処理を行うためにいくらかの仕事が発生する。それ以外で証券取引所が閉まっている時間帯、例えば休日などにはアクセスはほとんどない。あっても証券会社の顧客が自己の口座の情報を参照する程度である。したがって、図１２に示されるように、時間帯の属性として、証券取引所の取引時間にあたる時間帯に「取引時間」という属性を、バッチ処理が行われる時間帯に「バッチ処理」という属性を、それ以外の時間帯に「時間外」もしくは土日祝日の場合は「休日」を、それぞれ与えてもよい。このような属性を付与することで、証券会社のインターネット株取引システムを提供するデータセンタに発生する総アクセス数をより適切に予測することができる。

図１３は、本実施の形態に係る情報処理システム２が検索サービスを提供するデータセンタとして使用される場合の、負荷履歴テーブル１１２ｂの一例を示すデータ構造図である。ここでは稼動サーバ群の数および平均稼動率は説明を明瞭とするため省略される。この場合の総アクセス数の傾向としては、平日よりも休日の方が利用が多く、また平日でも午前よりも午後の方が利用が多いことがある。したがって、図１３に示されるように、時間帯の属性として、平日休日の別と午前午後の別との組み合わせを与えてもよい。このような属性を付与することで、検索サービスを提供するデータセンタに発生する総アクセス数をより適切に予測することができる。

本実施の形態に係る負荷管理装置１０では、省電力モード（予測総アクセス数＜モード切替値Ｍｏ）においては、表１に示される通りＯＳ休眠状態とするサーバ群と電源オフ状態とするサーバ群との両方を設けている。これにより、予測対象の時間帯において突然総アクセス数が増大した場合は、適応モードに移行した後復帰のためのオーバヘッドが小さいＯＳ休眠状態にあるサーバ群を稼動状態に戻すことで対応できる。また、そのように対応できる限りにおいては他のサーバ群は電力を消費しない電源オフ状態とし、情報処理装置２０全体の消費電力をさらに低減している。なお、表１ではＯＳ休眠状態とするサーバ群をひとつだけ確保しているが、この数はオーバヘッドと消費電力とのかねあいで定められればよく、適宜増減可能であることは本明細書に触れた当業者には理解される。

本実施の形態に係る負荷管理装置１０では、状態設定部１４０はサーバ群の最大性能を発揮せしめる前提で、予測対象の時間帯において稼動状態とするサーバ群を決定する。このサーバ群の決定方式によると、所与の予測総アクセス数に対してより多くの数のサーバ群を省電力状態とすることができる。したがって、情報処理装置２０全体の消費電力をより低減できる。なお、稼働率によってサーバ群の消費電力が異なるのも事実ではあるが、上述の通りアイドル状態でもピーク時のおよそ６０％の電力が消費されることを考えると、稼働率を下げることによる電力削減効果よりもアイドル状態を省電力状態とすることによる電力削減効果のほうが大きいと考えられる。

また、モード切替値Ｍｏは情報処理装置２０の性能が落ちない範囲に設定される。これにより、予測総アクセス数が多い場合は通常モードで情報処理装置２０の並列処理能力をいかんなく発揮させ、予測総アクセス数が少なくなると省電力モードに移行させて性能を保ちつつ電力消費量を低減できる。

また、状態設定部１４０は予測総アクセス数の変動により情報処理装置２０の性能が落ちると予測される場合には、予測対象の時間帯において省電力状態のサーバ群を稼動状態に設定する。これにより、サーバ群をピークアクセス数以上で使用しなければならない状況を回避し、アクセス処理の遅滞を避けることができる。

（第２の実施の形態）
第１の実施の形態では、並列に配置された複数のサーバ群を有するひとつのデータセンタを管理する負荷管理装置１０が、負荷の傾向を把握して省エネの観点から適切にサーバ群の状態を管理する場合について説明した。第２の実施の形態では、近年登場したクラウドコンピューティングシステムにおいて省エネの観点から適切にそのリソースを制御する負荷管理装置を説明する。

インターネットの発展により、新たなデータセンタサービスの形態として、クラウドコンピューティング方式が登場した。この方式では、企業などのユーザが自前でデータセンタ機器（ルータなどのネットワーク機器やサーバ、ストレージなどであり、以下リソースと称す）を用意する代わりに、時間貸しや運用アウトソースの形態でクラウドサービス提供事業者のリソースを利用する。

ユーザ側から見ると自分が利用しているサーバやストレージが何処にあるか分からないので、雲（クラウド）の中に居るようなという意味でクラウドコンピューティングと言う名前が発祥した。

クラウドサービス提供事業者によっては、ソフトウエアやアプリケーションのサービスを提供する場合もある。この場合で特にパブリッククラウドと呼ばれる一般の不特定多数のユーザが時間貸しやストレージのデータ量で課金を受けるサービスでは、その利用形態からクラウドサービス提供事業者は多くのリソースを持つ必要がある。クラウドサービス提供事業者は、通常複数のデータセンタを持ち、必要に応じてユーザからの負荷を複数のデータセンタに分散させる方式を取っている。

クラウドコンピューティングシステムにユーザから課される仕事には、サーバのみの利用、ストレージのみの利用、およびサーバやストレージの利用によるルータの負荷などがある。事例としては、米国の大手新聞社が、１００年にわたる過去の出版紙面の全ページの電子化プロジェクトを行った。そこでは自前でデータセンタを用意してのデータ処理は行わずに、クラウドサービス提供事業者を利用し、新聞紙面のイメージの電子化の処理（サーバ処理）と電子化された全紙面を一時保存する為のストレージの利用を行った。この利用においては、膨大な量のデータが発生し、ストレージの利用が大きなものとなったが、プロジェクトの終結後には、ストレージからデータが消去されストレージの利用率が大きく下がった。この新聞社のプロジェクトの事例では、予め利用されるサーバとストレージの量が決まっているので、クラウドサービス提供事業者はその利用分のサーバとストレージを用意すればよい。しかし、パブリッククラウドでの利用となると、この新聞社のように決まった分量のサーバ負荷予測とストレージを利用するデータ量の予測が難しい。したがってパブリッククラウドを提供するクラウドサービス提供事業者は、負荷が大きくなっても対処可能なようにできるだけ多くのリソースを保持し必要に応じて運用しなければならない。

しかしながら、負荷が小さい場合は、アイドル状態で仕事を待ち受けるリソースが多数発生する。しかしながら上述の通りアイドル状態でもリソースにおいて相当の電力が消費されている。したがって、省エネの観点から見ると、リソースをアイドル状態に置いておくことは電力の無駄使いと言える。

そこで第２の実施の形態に係る負荷管理装置は、クラウドコンピューティングシステムに対する過去の仕事量から今後発生する仕事量を予測し、その予測された仕事量が少ない場合はクラウドコンピューティングシステムが有する複数のデータセンタ内のリソースを適宜稼動状態から省電力状態に設定する。クラウドコンピューティングシステムは場合によっては数万から数百万台のリソースを有しているのであるが、それらのうち不必要なものを省電力状態とすることで消費電力を大きく削減できる。

ここで、クラウドコンピューティングシステムに対する仕事は計算やデータ処理や通信処理などであり、この仕事が第１の実施の形態における要求（アクセス）に対応する。また、負荷は例えばクラウドコンピューティングシステムに対する仕事を処理するために必要な単位時間当たりのリソースの台数である。

なお、リソースの稼動状態とは、第１の実施の形態で定義したサーバ群の稼動状態と同様の状態であり、例えばクラウドコンピューティングサービスの利用者からの仕事要求を即時実行可能な状態である。リソースの省電力状態もまた第１の実施の形態で定義したサーバ群の省電力状態と同様の状態であり、ＯＳ休眠状態と電源オフ状態とを含む。

図１４は、第２の実施の形態に係る負荷管理装置５１０を有するクラウドコンピューティングシステム５００を示す概略図である。クラウドコンピューティングシステム５００は、米国ニューヨーク市にある第１データセンタ５０２と、米国サンフランシスコ市にある第２データセンタ５０４と、米国ホノルル市にある第３データセンタ５０６と、第２の実施の形態に係る負荷管理装置５１０と、を備える。
クラウドコンピューティングシステム５００は、現実には３つのデータセンタを備えているが、ネットワーク５０８のユーザに対しては仮想的なひとつのデータセンタである。

負荷管理装置５１０は、インターネットなどのネットワーク５０８を通じて第１データセンタ５０２、第２データセンタ５０４、第３データセンタ５０６を管理する。第１データセンタ５０２、第２データセンタ５０４、第３データセンタ５０６はネットワーク５０８を通じてクラウドコンピューティングシステム５００の利用者からの仕事を受ける。

図１５は、負荷管理装置５１０およびその周辺の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

負荷管理装置５１０は、ネットワーク５０８からクラウドコンピューティングシステム５００のリソースの現在の使用状況を取得して履歴として保存し、その履歴を用いて今後発生する仕事量、必要となるであろうリソースの台数を予測する。負荷管理装置５１０はその予測に基づきネットワーク５０８を介してクラウドコンピューティングシステム５００の各データセンタのリソースの状態を設定する。特に、負荷管理装置５１０は稼動状態としなくてもよいと予測されるリソースは省電力状態とする。

負荷管理装置５１０は、記憶装置５８０と、負荷取得部５２０と、学習部５３０と、状態設定部５４０と、乖離判定部５５０と、オーバライド部５６０と、表示制御部５７０と、電気料金ルーティング部５９０と、を備える。
記憶装置５８０は、負荷履歴テーブル５８２と、リソース状態テーブル５８４と、電気料金テーブル５８６と、を含む。負荷履歴テーブル５８２、リソース状態テーブル５８４、はそれぞれ第１の実施の形態における、負荷履歴テーブル１１２、第２サーバ群状態テーブル１１４に対応する。電気料金テーブル５８６は、各データセンタについて時間別に設定された電気料金を記憶する。ここで電気料金とは、電力会社が電気使用者に電気を販売する際の値段である。負荷履歴テーブル５８２は図１６で、リソース状態テーブル５８４は図１７で、電気料金テーブル５８６は図１８で、後述する。

学習部５３０は、テーブル更新部５３２と、負荷予測部５３４と、を含む。状態設定部５４０は、負荷比較部５４２と、稼動リソース決定部５４４と、状態信号生成部５４６と、を含む。負荷取得部５２０、学習部５３０、テーブル更新部５３２、負荷予測部５３４、状態設定部５４０、負荷比較部５４２、稼動リソース決定部５４４、状態信号生成部５４６、乖離判定部５５０、オーバライド部５６０、表示制御部５７０、はそれぞれ第１の実施の形態における、負荷取得部１２０、学習部１３０、テーブル更新部１３２、負荷予測部１３４、状態設定部１４０、負荷比較部１４２、稼動サーバ群決定部１４４、状態信号生成部１４６、乖離判定部１５０、オーバライド部１６０、表示制御部１７０、に対応する。負荷管理装置５１０と接続された入力装置５１２、ディスプレイ５１４もまたそれぞれ第１の実施の形態における、入力装置１２、ディスプレイ１４に対応する。

アクセスをクラウドコンピューティングシステム５００に課されたサーバ処理、ストレージ貸しなどの仕事、総アクセス数をクラウドコンピューティングシステム５００に課された仕事を処理するために必要な単位時間当たりのリソースの台数（以下リソース必要台数と称す）、予測総アクセス数を過去に要求された仕事をもとに負荷予測部５３４によって予測されたリソース必要台数、と読み替えることで、第１の実施の形態に係る負荷管理装置１０について図６を参照してなされた上の説明と同様の説明が第２の実施の形態に係る負荷管理装置５１０にも基本的に当てはまる。以下、第１の実施の形態に係る負荷管理装置１０と第２の実施の形態に係る負荷管理装置５１０との主な差異を説明する。

第１の実施の形態における負荷取得部１２０はロードバランサ３０の負荷検出部３８からそこで検出された総アクセス数を取得するが、第２の実施の形態における負荷取得部５２０は、ネットワーク５０８から第１データセンタ５０２、第２データセンタ５０４および第３データセンタ５０６の現在のリソース必要台数を取得する。

第２の実施の形態に係る稼動リソース決定部５４４は、電気料金テーブル５８６を参照し、予測対象の時間帯において電気料金がより安いデータセンタに含まれるリソースに優先的に仕事を処理させてもよい。稼動リソース決定部５４４は、予測対象の時間帯においてリソースの状態の切替が必要な場合には、稼動状態とするリソースとＯＳ休眠状態とするリソースと電源オフ状態とするリソースを決定する。ここでそれぞれの状態にするリソースを決めるアルゴリズムは、第１の実施の形態で説明したアルゴリズムに加えて、電気料金を考慮して決めるアルゴリズムを有する。この電気料金考慮型のアルゴリズムでは、稼動状態とするリソースの台数を増やす場合は、予測対象の時間帯において電気料金がより安い、好ましくは最も安い、データセンタのリソースを優先的に稼動状態とする。また、稼動状態とするリソースの台数を減らす場合には、予測対象の時間帯において電気料金がより高い、好ましくは最も高い、データセンタのリソースを優先的に省電力状態とする。

第１の実施の形態における状態信号生成部１４６は第１サーバ群２２ａ〜第５サーバ群２２ｅに接続されるが、第２の実施の形態における状態信号生成部５４６は、ネットワーク５０８を介して第１データセンタ５０２、第２データセンタ５０４、第３データセンタ５０６のリソースに状態を切り替えるための信号を送る。

電気料金ルーティング部５９０は、リソース状態テーブル５８４および電気料金テーブル５８６を参照し、電気料金がより高いデータセンタで稼動状態となっているリソースを電気料金がより安いデータセンタで省電力状態となっている同種のリソースで代替することができる場合は、そのような代替を行うように状態信号生成部５４６に指示を出す。

電気料金ルーティング部５９０は、リソース状態テーブル５８４を参照して各データセンタで稼動状態となっているリソースの台数を取得する一方、電気料金テーブル５８６を参照して各データセンタの現在の電気料金を取得する。電気料金ルーティング部５９０はそれらの情報を基にクラウドコンピューティングシステム５００全体の現在の電気使用量に応じた電力会社への支払い（以下、電気使用料金と称す）を演算する。また電気料金ルーティング部５９０は、仮に電気料金の安いデータセンタのリソースから順番に使用していった場合の理想的な（最安値の）現在の電気使用料金を演算する。そして電気料金ルーティング部５９０は、実測値としての現在の電気使用料金と理想的な現在の電気使用料金との差が所定の設定値よりも大きい場合は、電気料金がより高いデータセンタで稼動状態となっているリソースと同種のリソースが、電気料金がより安いデータセンタで省電力状態となっているか否かを電気料金テーブル５８６およびリソース状態テーブル５８４を参照して確認する。そして電気料金ルーティング部５９０は、同種のリソースが電気料金がより安いデータセンタで省電力状態となっていれば、電気料金がより高いデータセンタで稼動状態となっているリソースを省電力状態とし、電気料金がより安いデータセンタで省電力状態となっている同種のリソースを稼動状態とするように状態信号生成部５４６に指示を出す。その際、図示されていないが、電気料金ルーティング部５９０は電気料金がより高いデータセンタで稼動状態となっていたリソースで処理されていた仕事を、新しく稼動状態となる電気料金がより安いデータセンタのリソースにルーティングする。
なお、電気料金ルーティング部５９０における上述の処理は、リソース必要台数の予測に基づくリソースの状態設定とは別系統の処理とされてもよい。

図１６は、負荷履歴テーブル５８２を示すデータ構造図である。負荷履歴テーブル５８２は、時間帯６１８と、その時間帯が属する属性６２０と、その時間帯に稼動状態にあったリソースの種類である必要リソース分類６２２と、その種類のリソースの台数であるリソース必要台数６２４と、を対応付けて記憶する。必要リソース分類６２２は、例えばサーバ、ストレージ、ルータの別である。時間帯６１８は第１の実施の形態の図７の時間帯２１８に、属性６２０は属性２２０に、必要リソース分類６２２およびリソース必要台数６２４は総アクセス数２２２に、それぞれ対応する。

図１７は、リソース状態テーブル５８４を示すデータ構造図である。リソース状態テーブル５８４は、データセンタ６０２ごとにリソース６０４とその状態６０６とその稼働率６０８とを対応付けて記憶する。データセンタ６０２およびリソース６０４は第１の実施の形態の図５のＩＰアドレス２０２に、状態６０６は状態２０４に、稼働率６０８は稼働率２０６に、それぞれ対応する。

図１８は、電気料金テーブル５８６を示すデータ構造図である。電気料金テーブル５８６は、ニューヨーク時間での時間帯６２６と、その時間帯における各データセンタの電気料金の売値単価６２８と、を対応付けて記憶する。負荷管理装置５１０は外部の電力取引所と通信を行い、絶えず相場で売られている電気料金のデータで電気料金テーブル５８６を更新する。または、負荷管理装置５１０は過去の電気料金のデータから予測して電気料金テーブル５８６を生成してもよい。

図１９は、表示制御部５７０によってディスプレイ５１４に表示されるステータス画面６３０の代表画面図である。ステータス画面６３０は、ニューヨーク市にある第１データセンタ５０２の状態を示す第１表示領域６３２と、サンフランシスコ市にある第２データセンタ５０４の状態を示す第２表示領域６３４と、ホノルル市にある第３データセンタ５０６の状態を示す第３表示領域６３６と、を含む。各表示領域は、サーバの稼働状況を示すサーバ運用状況表示領域６３８と、ストレージの稼働状況を示すストレージ運用状況表示領域６４０と、ルータの稼働状況を示すルータ運用状況表示領域６４２と、を含む。サーバ運用状況表示領域６３８の上段のインジケータは現在予測に基づき稼動状態とされているサーバの台数、下段のインジケータは現在仕事を処理しているサーバの台数を示す。それらの差は現在稼動状態にあるが仕事を行っていない、つまりアイドル状態にあるサーバの台数を示す。ストレージ運用状況表示領域６４０、ルータ運用状況表示領域６４２についても同様である。クラウドコンピューティングシステム５００の管理者はこのステータス画面６３０を見ることにより、現況を一目で把握して設定されている予測アルゴリズム（属性の決め方など）が適切か否かを判断でき、そのような予測アルゴリズムを最適化していく一助となる。また、この目的のため、ステータス画面６３０はクラウドコンピューティングシステム５００の現在の消費電力を示す領域６４４と、アイドル状態にあるリソースの消費電力に対応する、無駄と考えられる消費電力を示す領域６４６と、を含んでもよい。

第２の実施の形態に係る負荷管理装置５１０によると、第１の実施の形態で説明した作用効果と同様の作用効果を得ることができる。
特に、クラウドコンピューティングサービスでは複数種類のリソースが使用され、そのそれぞれに対して仕事が発生する。第２の実施の形態では図１６に見られるように、負荷履歴テーブル５８２はその種類毎にリソース必要台数を記録する。したがって、リソースの種類毎に仕事量の傾向を把握し、それに基づいて種類毎に仕事量を予測し、その予測に基づいて種類毎に不必要なリソースを省電力状態とする。したがって、クラウドコンピューティングシステム５００においてもこれまで無駄となっていた電力を削減して消費電力を低減できる。

なお、クラウドコンピューティングシステム５００における仕事量の傾向としては図１６に示されるように、平日は利用が多く休日は少ないことがある。また、クラウドコンピューティングシステム５００のワールドワイドな性質上、国毎の祝日によってもまた左右されうる。したがって、予測のための属性としては、平日休日の別と、他国の休日か否かと、を組み合わせることが好ましい。

クラウドコンピューティングシステム５００では一般的に複数のデータセンタが地理的に離れて配置される。本実施の形態では、ニューヨーク市とサンフランシスコ市とホノルル市とに配置され、それらの間の時差は３時間、３時間である。また電気料金は地域ごと、電力会社ごと、時間帯ごとに異なる。本発明者はこれらのことから、クラウドコンピューティングシステム５００ではデータセンタ間の電力料金の差を利用したコスト削減が図れることに想到した。

そこで第２の実施の形態に係る負荷管理装置５１０では、稼動リソース決定部５４４は電気料金テーブル５８６を参照し、予測対象の時間帯において電気料金がより安いデータセンタに含まれるリソースに優先的に仕事を処理させる。したがって、例えば図１８の例では、ニューヨーク時間で２００９年４月１５日の１０：１５−１０：３０の時間帯において仕事を処理させるリソースを決定する際には、ニューヨーク市にある第１データセンタ５０２のリソースよりもホノルル市にある第３データセンタ５０６のリソースを優先的に選ぶ。これにより、消費電力だけでなく電気使用料金を低減でき、コストの面でより効率的な管理が可能となる。
また、電気料金ルーティング部５９０によっても同様の作用効果を得ることができる。つまり、例えば図１８の例では、ニューヨーク時間で２００９年４月１５日の１０：１５−１０：３０の時間帯においてニューヨーク市の第１データセンタ５０２で発生している仕事をホノルル市の第３データセンタ５０６に回すことで電気使用料金を低減できる。

従来では電気使用料金を低減するためにデータセンタそのものを電気料金の安い土地に移転することは行われていた。しかしながら移転には当然莫大なコストがかかる。そこで本実施の形態に係る手法を用いると、移転を行うことなく電気料金の地域差および時差を利用して電気使用料金を低減できる。

以上、実施の形態に係る負荷管理装置の構成と動作について説明した。これらの実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。さらには実施の形態同士の組み合わせもまた可能である。例えば、第２の実施の形態におけるクラウドコンピューティングシステム５００の各データセンタを、第１の実施の形態に係るデータセンタとしてもよい。

第１の実施の形態では、ユーザ端末６からサーバ群へのパケットの流れを基に説明したが、サーバ群からユーザ端末６へパケットを返すときも負荷管理装置１０が適宜接続テーブル３２４を参照してアドレス変換できることは本明細書に触れた当業者には明らかである。

第１の実施の形態では、モード切替値Ｍｏ、第１しきい値Ｔ１、第２しきい値Ｔ２、および第３しきい値Ｔ３が稼動状態のサーバ群の数を決めるしきい値となる場合について説明したが、これに限られない。例えば、それぞれのしきい値にヒステリシスを持たせてもよい。つまり状態設定部は、通常モードから省電力モードへ移行する第１モード切替値Ｍｏ１と、省電力モードから通常モードへ移行する第２モード切替値Ｍｏ２とを有し、Ｍｏ１＜Ｍｏ２であってもよい。第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３についても同様である。この場合、予測総アクセス数がしきい値付近で変動しても、しきい値をまたぐ毎にサーバ群の状態を切り替えなくてもよいので、状態切替に伴うオーバヘッドを低減できる。その結果情報処理システム２全体のレスポンスが向上しうる。なお、第１モード切替値Ｍｏ１と第２モード切替値Ｍｏ２とは、やはりオーバヘッドと処理速度とのかねあいで定めればよい。

図２０は、オーバヘッドと性能のかねあいを説明するための、各サーバ群の稼働率を示すグラフである。ここでは、第１サーバ群２２ａから第５サーバ群２２ｅのピークアクセス数が全て２０００であるとする。また、第１モード切替値Ｍｏ１は７７００、第２モード切替値Ｍｏ２は８３００に設定されている。
図２０では予測総アクセス数が７５００から８２００に変わった際の予測対象の時間帯における各サーバ群の稼働率が示される。この場合、変わった後の予測総アクセス数は第２モード切替値Ｍｏ２に届かないので、負荷管理装置１０は依然として省電力モードに設定されたままである。したがって、予測対象の時間帯が到来し、予測通り８２００のアクセスが発生すると例えば第４サーバ群２２ｄにピークアクセス数を越える数のアクセスが割り当てられることとなる。したがって第４サーバ群２２ｄにおける処理速度は低下し、情報処理装置２０全体の処理速度が低下する。対して第１の実施の形態のようにヒステリシスを設けない場合は第５サーバ群２２ｅが稼動状態に設定され、そこで第１サーバ群２２ａ〜第４サーバ群２２ｄでは処理しきれない新規のアクセスが処理される。しかしながら、第５サーバ群２２ｅを省電力状態から稼動状態とする際にはオーバヘッドが存在するので、新規のアクセスを第５サーバ群２２ｅに割り当てる前にそのオーバヘッドだけ待たなければならない。これはやはり情報処理装置２０全体の処理速度の低下と見ることができる。したがって、サーバ群にピークアクセス数以上のアクセスを課すことによる処理速度の低下と、サーバ群の状態切替に伴うオーバヘッドが引き起こす処理速度の低下と、のかねあいでヒステリシスが決定されてもよい。

第１の実施の形態では、サーバ群をどの状態に置くかについて、状態設定部１４０において表１に示されるストラテジが使用される場合について説明したが、これに限られない。例えば、省電力状態としてＯＳ休眠状態を使用し、電源オフ状態を使用しなくてもよい。この場合、電源オンオフにかかる比較的長いオーバヘッドがなくなるので、より早いレスポンスが期待できる。また、処理が簡素化される。別の例としては、省電力状態として電源オフ状態を使用し、ＯＳ休眠状態を使用しなくてもよい。この場合、消費電力をより低減できる。

第１の実施の形態では、第１サーバ群２２ａ〜第５サーバ群２２ｅの要求の処理能力はほぼ等しく設定される場合について説明したが、これに限られない。情報処理装置２０に含まれる複数のサーバ群のうちの少なくとも２つについて、それらの要求の処理能力が異なる場合でも、本実施の形態と同等の作用効果を有することは本明細書に触れた当業者には理解される。

第１の実施の形態では、サーバ群選択部３６４は省電力モードでは、稼動状態にあるサーバ群の稼働率が１００％となるように、稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択する場合について説明したが、これに限られない。例えば、サーバ群選択部３６４は、稼動状態にあるサーバ群のなかから、ラウンドロビン方式や最速方式などの公知の負荷分散アルゴリズムを使用して新規のアクセスを処理させるサーバ群を選択してもよい。これらの場合でも、依然として省電力モードでは省電力状態（ＯＳ休眠状態もしくは電源オフ状態）のサーバ群を設けているので、全体としての電力消費量を低減できる。

第１の実施の形態では、第１フロントエンドサーバ２４ａと第１アプリケーションサーバ２６ａと第１データベースサーバ２８ａとは別個のサーバであり、この順に直列に接続されている場合について説明したが、これに限られない。個々のサーバ群は少なくともひとつのサーバを含めばよく、例えば、サーバ群はフロントエンドサーバとアプリケーションサーバとデータベースサーバの機能を全て併せ持つ１台のサーバを含んでもよい。また、サーバ群は、それら３つのサーバの機能のうちの任意の２つの機能を併せ持つサーバと、残りの機能を持つサーバと、を含んでもよい。

第１の実施の形態では、負荷管理装置１０は、負荷がモード切替値Ｍｏより少ない場合は省電力モード、以上の場合は通常モードに設定される場合について説明したが、これに限られない。例えば、多くのサーバ群を有する情報処理システムでは、負荷の許容量が大きく、通常モードを設定する必要がない場合もある。このような場合では負荷管理装置は常に省電力モードに設定され、通常モードは設定されないか実装されていなくてもよい。この場合でも第１の実施の形態で説明した効果と同様の効果を得ることができる。

第１の実施の形態では、負荷予測部１３４は属性をキーとする場合について説明したが、時間帯であってもよい。負荷予測部１３４は、負荷履歴テーブル１１２を参照し、予測対象の時間帯に対して過去の同月同日の同じ時間帯の負荷履歴を取得し、これを基に予測対象の時間帯の予測総アクセス数を決定する。例えば、負荷予測部１３４が２００９年７月２８日の９：１５〜９：３０における総アクセス数を予測する場合、負荷予測部１３４は２００８年７月２８日の９：１５〜９：３０における総アクセス数（図７の場合、５４００）を負荷履歴テーブル１１２から取得し、それを予測総アクセス数とする。

第１の実施の形態では、情報処理システム２が使用される例として証券業務や検索エンジンを挙げ、第２の実施の形態では負荷管理装置５１０がクラウドコンピューティングシステム５００を管理する場合について説明したが、これに限られない。本発明は例えば不特定多数のユーザが利用するコンピュータセンタの機器の管理に適用されうる。このコンピュータセンタの例としては、大学等の学術関係で、多くの生徒や研究者が利用するサーバとストレージのシステムがある。
図２１は、本発明のある実施の形態を大学の共用データセンタに適用した場合の負荷履歴テーブル１１２ｃを示すデータ構造図である。この場合、仕事量の傾向をより正確に把握するために大学のスケジュールに応じた属性が選択されることが望ましい。

以上、実施の形態にもとづき本発明を説明したが、実施の形態は、本発明の原理、応用を示しているにすぎないことはいうまでもなく、実施の形態には、請求の範囲に規定された本発明の思想を逸脱しない範囲において、多くの変形例や配置の変更が可能であることはいうまでもない。

２情報処理システム、４ネットワーク、６ユーザ端末、１０負荷管理装置、２０情報処理装置、３０ロードバランサ、１１０第２記憶装置、１２０負荷取得部、１３０学習部、１４０状態設定部、１５０乖離判定部、１６０オーバライド部、１７０表示制御部、５００クラウドコンピューティングシステム、５０２第１データセンタ、５０４第２データセンタ、５０６第３データセンタ、５１０負荷管理装置、５２０負荷取得部、５３０学習部、５４０状態設定部、５５０乖離判定部、５６０オーバライド部、５７０表示制御部、５８０記憶装置。

Claims

互いにネットワークによって接続され、互いに地理的に離れて配置された複数のデータセンタを含むシステムを管理する負荷管理装置であって、各データセンタは複数の要求処理ユニットを有しており、本負荷管理装置は、
各データセンタについて設定された電気料金を記憶する電気料金テーブルと、
前記電気料金テーブルを参照し、電気料金がより高いデータセンタに含まれる、ネットワークからの前記システムに対する要求を受付可能な第１状態となっている要求処理ユニットを電気料金がより安いデータセンタに含まれる、前記第１状態よりも省電力の第２状態となっている要求処理ユニットで代替することができるかどうかを判別する電気料金ルーティング部と、
前記電気料金ルーティング部において代替可能と判別された場合に、前記第１状態となっている要求処理ユニットを前記第２状態に設定し、前記第２状態となっている要求処理ユニットを前記第１状態に設定する状態設定部と、を備えることを特徴とする負荷管理装置。
前記システムは複数種類の要求処理ユニットを有し、
ネットワークからの前記システムに対する要求の負荷を要求処理ユニットの種類毎に取得する負荷取得部と、
過去に要求された負荷をもとに今後発生する負荷を要求処理ユニットの種類毎に予測する負荷予測部と、をさらに備え、
前記状態設定部は、前記負荷予測部によって要求処理ユニットの種類のそれぞれについて予測された負荷が所定の値より少ない場合、その種類に属する少なくともひとつの要求処理ユニットを前記第２状態に設定することを特徴とする請求項１に記載の負荷管理装置。
ネットワークからの前記システムに対する要求の負荷を取得する負荷取得部と、
取得された負荷と、その負荷が取得された時間帯が属する属性と、を対応付けて記憶する負荷履歴テーブルと、
前記負荷履歴テーブルを参照して今後発生する負荷を予測する負荷予測部と、をさらに備え、
時間帯が属する属性は、前記システムの使用目的に応じて設定され、
前記負荷予測部は、負荷予測の対象となる時間帯が属する属性に対応する負荷を前記負荷履歴テーブルから取得し、取得された負荷に基づいて負荷予測の対象となる時間帯における負荷を予測し、
前記状態設定部は、前記負荷予測部によって予測された負荷が所定の値より少ない場合、少なくともひとつの要求処理ユニットを前記第２状態に設定することを特徴とする請求項１に記載の負荷管理装置。
前記状態設定部は、要求処理ユニットの最大性能を発揮せしめる前提で、ネットワークからの前記システムに対する要求を処理させる要求処理ユニットを決定し、残りの要求処理ユニットを前記第２状態に設定することを特徴とする請求項２または３に記載の負荷管理装置。
前記状態設定部は、前記負荷予測部によって予測された負荷の変動により前記システムの性能が落ちると予測される場合には、前記第２状態に設定されている少なくともひとつの要求処理ユニットを前記第１状態に設定することを特徴とする請求項２から４のいずれかに記載の負荷管理装置。
前記状態設定部は、前記電気料金テーブルを参照し、前記負荷予測部で負荷予測の対象となる時間帯において電気料金がより安いデータセンタに含まれる要求処理ユニットに優先的に要求を処理させることを特徴とする請求項２から５のいずれかに記載の負荷管理装置。
互いにネットワークによって接続され、互いに地理的に離れて配置された複数のデータセンタを含むシステムと、
前記複数のデータセンタを管理する負荷管理装置と、を備え、
各データセンタは複数の要求処理ユニットを有し、
前記負荷管理装置は、
各データセンタについて設定された電気料金を記憶する電気料金テーブルと、
前記電気料金テーブルを参照し、電気料金がより高いデータセンタに含まれる、ネットワークからの前記システムに対する要求を受付可能な第１状態となっている要求処理ユニットを電気料金がより安いデータセンタに含まれる、前記第１状態よりも省電力の第２状態となっている要求処理ユニットで代替することができるかどうかを判別する電気料金ルーティング部と、
前記電気料金ルーティング部において代替可能と判別された場合に、前記第１状態となっている要求処理ユニットを前記第２状態に設定し、前記第２状態となっている要求処理ユニットを前記第１状態に設定する状態設定部と、を含むことを特徴とする情報処理システム。
互いにネットワークによって接続され、互いに地理的に離れて配置された複数のデータセンタを含むシステムを管理する負荷管理方法であって、各データセンタは複数の要求処理ユニットを有しており、本負荷管理方法は、
各データセンタについて設定された電気料金を記憶する電気料金テーブルを生成するステップと、
前記電気料金テーブルを参照し、電気料金がより高いデータセンタに含まれる、ネットワークからの前記システムに対する要求を受付可能な第１状態となっている要求処理ユニットを電気料金がより安いデータセンタに含まれる、前記第１状態よりも省電力の第２状態となっている要求処理ユニットで代替することができるかどうかを判別するステップと、
代替可能と判別された場合に、前記第１状態となっている要求処理ユニットを前記第２状態に設定し、前記第２状態となっている要求処理ユニットを前記第１状態に設定するステップと、を含むことを特徴とする負荷管理方法。
互いにネットワークによって接続され、互いに地理的に離れて配置された複数のデータセンタであってそれぞれが複数の要求処理ユニットを有する複数のデータセンタを含むシステムを管理する負荷管理装置に、
各データセンタについて設定された電気料金を記憶する電気料金テーブルを生成する機能と、
前記電気料金テーブルを参照し、電気料金がより高いデータセンタに含まれる、ネットワークからの前記システムに対する要求を受付可能な第１状態となっている要求処理ユニットを電気料金がより安いデータセンタに含まれる、前記第１状態よりも省電力の第２状態となっている要求処理ユニットで代替することができるかどうかを判別する機能と、
代替可能と判別された場合に、前記第１状態となっている要求処理ユニットを前記第２状態に設定し、前記第２状態となっている要求処理ユニットを前記第１状態に設定する機能と、を実現させることを特徴とするコンピュータプログラム。