情報処理システムおよび情報処理方法
【課題】並列処理を行うサーバ群の消費電力を低減する。
【解決手段】情報処理システム２は、解析装置１００と、負荷管理装置１０１０と、情報処理装置１０２０と、を有する。情報処理装置１０２０は、複数のサーバ群を含む。負荷管理装置１０１０は、情報処理装置１０２０に対するアクセスを外部から取得し、複数のサーバ群のうちの少なくともひとつに、取得されたアクセスを割り当てる。解析装置１００は、外部ネットワーク１００４、負荷管理装置１０１０、内部ネットワーク３などから得られる情報から、複数のサーバ群の稼動状況が示された指標を算出する。負荷管理装置１０１０は、解析装置１００によって算出された指標に基づいて、複数のサーバ群の状態を制御する。
【解決手段】情報処理システム２は、解析装置１００と、負荷管理装置１０１０と、情報処理装置１０２０と、を有する。情報処理装置１０２０は、複数のサーバ群を含む。負荷管理装置１０１０は、情報処理装置１０２０に対するアクセスを外部から取得し、複数のサーバ群のうちの少なくともひとつに、取得されたアクセスを割り当てる。解析装置１００は、外部ネットワーク１００４、負荷管理装置１０１０、内部ネットワーク３などから得られる情報から、複数のサーバ群の稼動状況が示された指標を算出する。負荷管理装置１０１０は、解析装置１００によって算出された指標に基づいて、複数のサーバ群の状態を制御する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システムおよび情報処理方法に関する。
【背景技術】
【０００２】
地球温暖化と言う問題が、昨今聞かれる。地球温暖化対策の一つとしては電力需要を減らすことがある。電力は一般的に水力発電、太陽光発電、風力発電、地熱発電などの自然由来の発電や、原子力を使う原子力発電や、ガス、石油、石炭などを燃料として燃やし発電を行う火力発電によって供給されている。この中でも特に火力発電は地球温暖化を進める大きな要因となっている。電力需要を減らせば火力発電の発電量も減らすことができるので、その分地球温暖化も抑止されうる。
【０００３】
ＩＴ（Information Technology）やＩＣＴ（Information and Communication Technology）の分野でも、コンピュータやネットワーク機器、データセンタ機器が消費する電力を低減する必要性が指摘され始めている。
【０００４】
近年のインターネットの普及により、多くのデータセンタは、ネットワーク接続型の形態を有しており、インターネットなどの外部のネットワークからの仕事要求を受けて処理を行う。これらのデータセンタのなかには、一度に多くのアクセスを処理するために複数の並列に配置されたサーバを備える構成を採用したものがある（特許文献１参照）。このようなデータセンタは、一般に「ロードバランサ」と呼ばれる負荷分散を行う装置を有する。このロードバランサはネットワーク側の通信機器とサーバとの間に配置され、ネットワークから到来するアクセスを個々のサーバに均等に近い形で分散させている。
また、ネットワーク接続装置の消費電力低減装置が知られている（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−２２５７９３号公報
【特許文献２】特開２００７−９７１２６号公報
【非特許文献】
【０００６】
【非特許文献１】The Green Grid Association、［online］、インターネット＜URL：http://www.thegreengrid.org＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
現行のロードバランサには、それに接続されているサーバに均等にアクセスを分配するものが多い。この場合、各サーバの処理能力や省エネの度合いは無視された形でアクセスが分配されうる。
【０００８】
サーバの特性について、製造年月日や機器の種類やメーカや装備（メモリ、ディスク）や電源ユニットなどの違いにより、処理能力や省エネの度合いはサーバごとに異なる場合が多い。例えば、同じＷＥＢ（World Wide Web）サーバで同じプロセスを走らせた場合でも、メーカが異なればそのプロセスで消費される電力は異なりうる。したがって、現行のロードバランサにおけるアクセスの分配の方法は、省エネ化の観点からは必ずしも最適な方法とは言えない。
【０００９】
本発明はこうした課題に鑑みてなされたものであり、その目的は、複数の要求処理ユニットで並列的に要求を処理する際の消費電力を低減できる情報処理技術の提供にある。
【課題を解決するための手段】
【００１０】
本発明のある態様は情報処理システムに関する。この情報処理システムは、複数の要求処理ユニットがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数の要求処理ユニットのうちの少なくともひとつに、取得された要求を割り当てる負荷管理装置と、ネットワークから得られる情報から、複数の要求処理ユニットの稼動状況が示された指標を算出する解析装置と、を備える。負荷管理装置は、解析装置によって算出された指標に基づいて、複数の要求処理ユニットの状態を制御する。
【００１１】
「要求」とは、例えば情報処理装置に対する処理の要求であってもよい。
【００１２】
この態様によると、解析装置によって算出された指標に基づいて、複数の要求処理ユニットの状態を制御できる。
【００１３】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１４】
本発明によれば、複数の要求処理ユニットで並列的に要求を処理する際の消費電力を低減できる。
【図面の簡単な説明】
【００１５】
【図１】実施の形態に係る情報処理システムを示す概略図である。
【図２】図１におけるアクセスの流れを説明するための説明図である。
【図３】図１の解析装置の機能および構成を示すブロック図である。
【図４】図３の通信情報保持部に保持されるデータの一例を示すデータ構造図である。
【図５】図３のサーバ情報保持部に保持されるデータの一例を示すデータ構造図である。
【図６】図３の第１指標保持部に保持されるデータの一例を示すデータ構造図である。
【図７】図３の使用状況保持部に保持されるデータの一例を示すデータ構造図である。
【図８】図３の係数保持部に保持されるデータの一例を示すデータ構造図である。
【図９】図３の第２指標保持部に保持されるデータの一例を示すデータ構造図である。
【図１０】図３の第３指標保持部に保持されるデータの一例を示すデータ構造図である。
【図１１】図１の負荷管理装置の機能および構成を示すブロック図である。
【図１２】図１１の接続保持部を示すデータ構造図である。
【図１３】図１１のサーバ群状態保持部を示すデータ構造図である。
【図１４】図１１の稼動履歴保持部を示すデータ構造図である。
【図１５】図１の解析装置における一連の処理を示すフローチャートである。
【図１６】図１の負荷管理装置における一連の処理を示すフローチャートである。
【図１７】図１７（ａ）〜（ｄ）は、全アクセス数に対する各サーバ群の稼働率の一例を示すグラフである。
【図１８】変形例に係る解析装置における一連の処理を示すフローチャートである。
【発明を実施するための形態】
【００１６】
以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。
【００１７】
実施の形態に係る情報処理システムは、複数の並列に配置されたサーバ群でユーザからのアクセスを処理する。負荷管理装置はその情報処理システムのゲートウエイとして機能し、外部ネットワークから情報処理システム宛に到来する要求の負荷が少ない場合は不必要なサーバ群のＯＳ（operating system）を休眠させたり、サーバ群の電源自体をオフにする。また、サーバ群の電力特性は使用する機種等により異なる場合があるが、情報処理システムの解析装置が電力特性を計測して負荷管理装置に報告する。負荷管理装置は、その報告を受けて例えば電力効率が悪いサーバ群からＯＳを休眠させたり電源をオフにしたりする。これにより情報処理システムが総合的に省エネ化される。
【００１８】
図１は、実施の形態に係る情報処理システム２を示す概略図である。情報処理システム２は、ネットワーク接続型のデータセンタであり、例えば証券会社のインターネット株取引システムを提供するデータセンタである。情報処理システム２は、解析装置１００と、負荷管理装置１０１０と、情報処理装置１０２０と、を備える。情報処理装置１０２０は、第１サーバ群１０２２ａと、第２サーバ群１０２２ｂと、第３サーバ群１０２２ｃと、第４サーバ群１０２２ｄと、第５サーバ群１０２２ｅと、を含む。第１サーバ群１０２２ａは、第１フロントエンドサーバ１０２４ａと、第１アプリケーションサーバ１０２６ａと、第１データベースサーバ１０２８ａと、を含む。第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃ、第４サーバ群１０２２ｄ、および第５サーバ群１０２２ｅは、それぞれ第１サーバ群１０２２ａと同等の構成を有する。
【００１９】
以下、第１サーバ群１０２２ａ、第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃ、第４サーバ群１０２２ｄ、第５サーバ群１０２２ｅ、はサーバ群１０２２と総称される場合がある。また、第１フロントエンドサーバ１０２４ａ、第２フロントエンドサーバ１０２４ｂ、第３フロントエンドサーバ１０２４ｃ、第４フロントエンドサーバ１０２４ｄ、第５フロントエンドサーバ１０２４ｅ、はフロントエンドサーバ１０２４と総称される場合がある。また、第１アプリケーションサーバ１０２６ａ、第２アプリケーションサーバ１０２６ｂ、第３アプリケーションサーバ１０２６ｃ、第４アプリケーションサーバ１０２６ｄ、第５アプリケーションサーバ１０２６ｅ、はアプリケーションサーバ１０２６と総称される場合がある。また、第１データベースサーバ１０２８ａ、第２データベースサーバ１０２８ｂ、第３データベースサーバ１０２８ｃ、第４データベースサーバ１０２８ｄ、第５データベースサーバ１０２８ｅ、はデータベースサーバと総称される場合がある。
【００２０】
情報処理システム２は、外部ネットワーク１００４と接続され同じく外部ネットワーク１００４に接続されている少なくともひとつのユーザ端末１００６から要求を受ける。ここで要求とは、例えばユーザ端末１００６からのアクセスである。アクセスとは、ユーザ端末１００６と情報処理システム２のひとつのサーバ群１０２２とが接続を確立して一連の情報をやりとりすることである。異なるユーザ端末からのアクセスは異なるアクセスであり、同じユーザ端末１００６からでも異なるアクセスがなされうる。
外部ネットワーク１００４は、例えばＬＡＮ（Local Area Network）・ＷＡＮ（Wide Area Network）・インターネットである。ユーザ端末１００６は、ユーザが使用するコンピュータであり、例えば有線で外部ネットワーク１００４に接続された家庭用デスクトップコンピュータや、無線で外部ネットワーク１００４に接続されたラップトップコンピュータである。
【００２１】
負荷管理装置１０１０は、外部ネットワーク１００４と接続され、また情報処理装置１０２０に含まれる個々のサーバ群１０２２と内部ネットワーク３を介して接続される。負荷管理装置１０１０は、データの流れの観点からは情報処理装置１０２０と外部ネットワーク１００４との間に位置し、外部ネットワーク１００４からの情報処理装置１０２０に対するアクセスを仲介する。
【００２２】
負荷管理装置１０１０は、解析装置１００が算出する情報処理装置１０２０に含まれる複数のサーバ群１０２２の稼動状況が示された指標を以下の３通りで使用する。
１．負荷管理装置１０１０は、外部ネットワーク１００４を介してユーザ端末１００６から情報処理装置１０２０に対するアクセスを取得する。負荷管理装置１０１０は、解析装置１００によって算出された指標に基づいて、情報処理装置１０２０に含まれる複数のサーバ群１０２２のうちアクセスを受付可能な状態（以下、稼動状態と称する）にあるサーバ群に、取得されたユーザからのアクセスを割り当てる。
【００２３】
２．負荷管理装置１０１０は、解析装置１００によって算出された指標に基づいて、複数のサーバ群１０２２の状態を制御する。サーバ群１０２２の状態として、稼動状態と省電力状態とが基本的に規定される。負荷管理装置１０１０は、外部ネットワーク１００４からの負荷を監視する。負荷管理装置１０１０は、負荷が所定の値より少なくなると、解析装置１００によって算出された指標に基づいて、稼動状態にあるサーバ群のうちアクセスの処理に不要なサーバ群を選択し、選択されたサーバ群を稼動状態よりも省電力の省電力状態に設定する。
【００２４】
ここで負荷とは、例えばサーバ群１０２２が行う仕事の量を表す値であり、単位時間当たりのアクセスの数を基に定められる。例えば負荷は、単位時間当たりのアクセスの数と比例関係などの数学的関係を有する値であってもよい。また、負荷は単位時間当たりのアクセスの数に上限値または下限値若しくはその両方を課した値であってもよい。以下では、負荷の一例が、単に単位時間当たりのアクセスの数（以下、アクセス数と称す）である場合について説明する。
なお、負荷が所定の値以上の場合は負荷管理装置１０１０は全てのサーバ群１０２２を稼動状態に設定する。
【００２５】
３．本実施の形態では、負荷管理装置１０１０は、負荷としてアクセス数以外に、ユーザ端末１００６などの外部から負荷管理装置１０１０に送られるパケットおよび負荷管理装置１０１０から外部に送られるパケットの総データ量も利用する。負荷管理装置１０１０は、解析装置１００によって算出されるその総データ量を監視する。
【００２６】
情報処理装置１０２０は、外部ネットワーク１００４からのアクセスを処理する。情報処理装置１０２０は、複数のサーバ群１０２２を含み、そのそれぞれのサーバ群１０２２はアクセスの処理単位である要求処理ユニットとして機能する。
本実施の形態では、ＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）プロトコルにしたがった通信が行われる場合を考える。
【００２７】
サーバ群１０２２はいわゆる３階層のサーバ群であり、これら１セットでアクセスの処理単位を構成する。フロントエンドサーバ１０２４は、ＷＥＢサーバとも呼ばれ、ＨＴＴＰ（HyperText Transfer Protocol）に則り、ユーザ端末１００６のＷＥＢブラウザに対して、ＨＴＭＬ（HyperText Markup Language）や画像などのオブジェクトの表示を提供するサービスが動作するサーバコンピュータである。アプリケーションサーバ１０２６は、フロントエンドサーバ１０２４からジャバサーブレット（Java Servlet、ジャバは登録商標）の処理などのアプリケーションに関する機能を切り出して実現するサーバコンピュータである。データベースサーバ１０２８は、アプリケーションサーバ１０２６のアプリケーションが使用するデータが格納されるサーバコンピュータである。フロントエンドサーバ１０２４、アプリケーションサーバ１０２６、およびデータベースサーバ１０２８は、公知の情報処理技術を使用して実現される。本実施の形態では、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とデータベースサーバ１０２８とは別個のサーバであり、この順に直列に接続されている。
【００２８】
サーバ群１０２２のフロントエンドサーバ１０２４は内部ネットワーク３を介して負荷管理装置１０１０と接続される。
【００２９】
なお、個々のサーバ群１０２２に含まれるサーバは個々にもしくは全体としてＯＳに管理されている。個々のサーバ群の稼動状態は、ユーザからのアクセスを即時処理可能な状態である。この状態は、サーバ群１０２２がユーザからのアクセスを処理しつつ新たなアクセスを処理可能である状態と、ユーザからのアクセスがなく仕事が発生していないアイドル状態と、を含む。稼動状態では、たとえアイドル状態であっても少なくとも基本ＯＳ機能とネットワークモニタリングのタスクは稼動しており、その分電力を消費する。本発明者の当業者としての経験から、このアイドル状態での消費電力は、サーバ機器の種類によってピークアクセス数での稼動時のおよそ３０％から７０％の範囲にある。特に、最新のブレードサーバでは、その高密度な回路構成と狭いスペースに多くの半導体素子が設置されている都合上、アイドル状態でも消費電力は大きくなる。一部のブレードサーバではアイドル状態においてピークアクセス数での稼動時の７０％もの電力を消費しているものも存在する。また、標準的なサーバ機器を用いる場合は６０％程度である。ここでピークアクセス数とは、サーバ群１０２２がその処理速度を落とさずに稼動できるアクセス数の範囲の上限値であり、サーバ群１０２２ごとにその仕様を基に予め定められている。ここで処理速度とは、サーバ群１０２２におけるユーザからのアクセスの処理速度である。
【００３０】
個々のサーバ群１０２２の省電力状態は、ユーザからのアクセスを即時処理できない状態である。この状態は、サーバ群１０２２へ電源は供給されているがそのサーバ群１０２２はユーザからのアクセスを処理できないＯＳ休眠状態を含む。サーバ群１０２２は負荷管理装置１０１０から休眠導入信号を受信するとＯＳ休眠状態となる。このＯＳ休眠状態では、サーバ群１０２２のＯＳは休眠（ハイボネート）しており、ユーザからのアクセスがあってもそれを受け付けない。ＯＳ休眠状態にあるサーバ群１０２２は負荷管理装置１０１０から休眠解除信号を受信すると、稼動状態に復帰する。ＯＳ休眠状態から稼動状態に復帰するためには通常数秒から数十秒かかる。また本発明者の当業者としての経験から、ＯＳ休眠状態におけるサーバ群１０２２の消費電力は、ピークアクセス数での稼働時のおよそ５％から１０％である。
【００３１】
サーバ群１０２２の省電力状態はさらに、サーバ群１０２２への電源が遮断されている電源オフ状態を含む。サーバ群１０２２は負荷管理装置１０１０から電源オフ信号を受信すると電源オフ状態となる。サーバ群１０２２は負荷管理装置１０１０からＷＯＬ（Wake Up on LAN）信号などの電源オン信号を受信すると、稼動状態に復帰する。電源オフ状態から稼動状態に復帰するためには通常数分かかる。
本実施の形態ではサーバ群１０２２が省電力状態から稼動状態に復帰するためにかかる時間（以下、オーバヘッドと称す）と、省電力状態で低減される消費電力とのかねあいで、省電力状態とされるサーバ群の数が決定される。つまり、現在のアクセス数を処理するのに必要なぎりぎりの数のサーバ群だけを稼動状態としていると、突然のアクセス数の増大に対して対処できなくなる可能性がある。一方で稼動状態のサーバ群の数が多いほど待機電力由来の消費電力も大きくなる。そこでそれらの影響が拮抗するように、省電力状態とされるサーバ群の数が決定される。
【００３２】
解析装置１００は、外部ネットワーク１００４、負荷管理装置１０１０、内部ネットワーク３、のそれぞれを通過するパケットを傍受する。また解析装置１００は、各サーバ群１０２２の内部でやりとりされるパケットも傍受する。これは例えば、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とを接続するサブネットや、アプリケーションサーバ１０２６とデータベースサーバ１０２８とを接続するサブネットに解析装置１００が接続されることによって実現される。
「傍受する」ことは、傍受対象のパケットを消滅させることなくその内容を取得することであってもよく、例えばパケットをそれに含まれる終点ＩＰアドレスによらずに取得することであってもよい。
解析装置１００は、傍受したパケットの内容を蓄積し、ＩＰアドレスでソートすることで各ＩＰアドレスに対応するサーバや負荷管理装置１０１０における仕事の内訳を導出する。
【００３３】
解析装置１００は、例えば各サーバに電力を供給するバスバー方式のテーブルタップ型のＰＤＵから、各サーバに供給された電力の計測値を取得し蓄積する。解析装置１００は、蓄積された電力の計測値および上記の仕事の内訳から、サーバ群１０２２の稼働状況が示された指標、例えばサーバ群１０２２における単位有効仕事量あたりの消費電力を算出する。
【００３４】
図２は、図１におけるアクセスの流れを説明するための説明図である。以下、１回のアクセスにおいて、少なくともひとつのパケットがユーザ端末１００６とアクセスが割り当てられたサーバ群との間でやりとりされる場合について説明する。このパケットは、送信元のＩＰアドレスである始点ＩＰアドレスと、受信先のＩＰアドレスである終点ＩＰアドレスと、シーケンス番号と、ポート番号と、タイムスタンプと、を含む。多くの場合において一回のアクセスにつき複数個のパケットがユーザ端末１００６とサーバ群との間を行き来する。図２では第３サーバ群１０２２ｃがアクセスに割り当てられたとする。ユーザ端末１００６のＩＰアドレスを「１７５．３４．１１．２１」、負荷管理装置１０１０のＩＰアドレスを「１００．１０．１０．１０」、第３サーバ群１０２２ｃに含まれる第３フロントエンドサーバ１０２４ｃのＩＰアドレスを「１２１．２１．１５．３」とする。
【００３５】
負荷管理装置１０１０は、ユーザ端末１００６に対して仮想サーバとして働く。つまり、外部ネットワーク１００４では、ユーザが情報処理装置１０２０が有する情報資源にアクセスしようとする場合、かかる情報資源のＵＲＬ（Uniform Resource Locator）が負荷管理装置１０１０のＩＰアドレス「１００．１０．１０．１０」に名前解決されるよう設定されている。
【００３６】
まずユーザは、ユーザ端末１００６のウェブブラウザに対して情報処理装置１０２０が有する情報資源のＵＲＬを指定する。ユーザ端末１００６のウェブブラウザによって始点ＩＰアドレスを「１７５．３４．１１．２１」、終点ＩＰアドレスを「１００．１０．１０．１０」とした第１パケットＰ１が生成され、外部ネットワーク１００４に送られる。負荷管理装置１０１０は第１パケットＰ１を受信し、稼動状態にあるサーバ群のなかから第３サーバ群１０２２ｃを選択してこのアクセスを割り当てる。負荷管理装置１０１０は、第１パケットＰ１の始点ＩＰアドレスはそのままにして終点ＩＰアドレスを「１２１．２１．１５．３」とした第２パケットＰ２を内部ネットワーク３に送出する。第３サーバ群１０２２ｃの第３フロントエンドサーバ１０２４ｃは自己宛の第２パケットＰ２を受信し、第２パケットＰ２のポート番号やそのパケットに搭載されるデータに基づき処理を行う。その処理の結果ユーザ端末１００６へ戻すべき情報は、始点ＩＰアドレスを「１２１．２１．１５．３」、終点ＩＰアドレスを「１７５．３４．１１．２１」とした第３パケットＰ３に含められ、第３フロントエンドサーバ１０２４ｃから内部ネットワーク３に送出される。負荷管理装置１０１０は第３パケットＰ３を受信する。負荷管理装置１０１０は、第３パケットＰ３の終点ＩＰアドレスはそのままにして始点ＩＰアドレスを「１００．１０．１０．１０」とした第４パケットＰ４を外部ネットワーク１００４に送る。ユーザ端末１００６は自己宛の第４パケットＰ４を外部ネットワーク１００４から受信する。
以下、ユーザ端末１００６から負荷管理装置１０１０に送られるパケット（第１パケットＰ１）を総称して行きパケット、負荷管理装置１０１０から情報処理装置１０２０へ送られるパケット（第２パケットＰ２）を総称して割当パケットという。
【００３７】
以下ではまず解析装置１００について説明し、次いで負荷管理装置１０１０について説明する。
【００３８】
（解析装置１００）
図３は、解析装置１００の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【００３９】
解析装置１００は、ネットワークインタフェース部１０２と、通信情報保持部１０４と、分類部１３２と、集計部１３０と、第１指標保持部１０８と、係数保持部１１４と、第１解析部１１６と、使用状況取得部１１０と、使用状況保持部１１２と、第２指標保持部１１８と、第２解析部１５２と、第３指標保持部１５８と、指標送信部１５４と、表示制御部１２０と、を備える。
【００４０】
ネットワークインタフェース部１０２は、傍受部１２２と、抽出部１２４と、フィルタ部１２６と、登録部１２８と、を含む。
傍受部１２２は、外部ネットワーク１００４と内部ネットワーク３とからパケットを傍受する。内部ネットワーク３は、各サーバ群１０２２のサーバを相互接続するサブネットを含む。抽出部１２４は、傍受部１２２によって傍受されたパケットから始点ＩＰアドレスと終点ＩＰアドレスとポート番号とを抽出する。
【００４１】
以下、負荷管理装置１０１０またはサーバ群１０２２またはサーバ群１０２２のサーバをノードと呼ぶ場合がある。
フィルタ部１２６は、フィルタ機能がオンとされるフィルタリングモードでは、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスを基に、計測対象のノードのＩＰアドレスが含まれたパケットのみを選択して、登録部１２８に出力する。より具体的にはフィルタ部１２６は、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスのうちの少なくとも一方が計測対象のノードのＩＰアドレスと一致する場合にのみ、抽出元のパケットを登録部１２８に出力する。
【００４２】
特にフィルタ部１２６は、計測対象のノードを、情報処理システム２に含まれる複数のノードから順番に選択する。すなわち、フィルタ部１２６は、計測対象のノードのＩＰアドレスを、情報処理システム２に含まれる複数のノードのＩＰアドレスのなかで順番に切り替える。
フィルタ部１２６は、フィルタ機能がオフとされるフィルタリングオフモードでは、抽出部１２４によって始点ＩＰアドレスと終点ＩＰアドレスとポート番号とが抽出されたパケットを登録部１２８に出力する。
【００４３】
登録部１２８は、フィルタ部１２６によって出力されたパケットについて、そのパケットに関する時刻と、抽出部１２４によってそのパケットから抽出された始点ＩＰアドレスと、抽出部１２４によってそのパケットから抽出された終点ＩＰアドレスと、抽出部１２４によってそのパケットから抽出されたポート番号に対応する通信用途と、そのパケットのデータ量と、を対応付けて通信情報保持部１０４に登録する。
【００４４】
図４は、通信情報保持部１０４に保持されるデータの一例を示すデータ構造図である。通信情報保持部１０４は、時刻２０２と、始点ＩＰアドレス２０４と、終点ＩＰアドレス２０６と、通信用途２０８と、データ量２１０と、を対応付けて保持する。
時刻２０２は、パケットに関する時刻であり、例えばパケットにタイムスタンプが含まれているのであればそのタイムスタンプで示される時刻である。あるいはまた、傍受部１２２によってパケットが傍受された時刻であってもよい。
始点ＩＰアドレス２０４および終点ＩＰアドレス２０６はそれぞれ、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスである。
通信用途２０８は、抽出部１２４によって抽出されたポート番号に対応する通信用途である。
データ量２１０は、パケットに搭載されているデータの量をバイト（Ｂ）単位で示す。
【００４５】
図３に戻る。分類部１３２は、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスのうちの少なくともひとつとポート番号とによってパケットを分類する。以下では分類部１３２が始点ＩＰアドレスとポート番号とによってパケットを分類する場合について説明する。しかしながら、分類部が終点ＩＰアドレスとポート番号とによってパケットを分類する場合、および分類部が始点および終点ＩＰアドレスとポート番号とによってパケットを分類する場合でも以下と同様の説明が成り立つことは、本明細書に触れた当業者には明らかである。
【００４６】
分類部１３２は、通信情報保持部１０４に保持されるデータを始点ＩＰアドレスについてソーティングする。以下、通信情報保持部１０４に登録されている始点ＩＰアドレスを登録ＩＰアドレスと称す。分類部１３２は、各登録ＩＰアドレスについて通信用途によってパケットを分類する。特に分類部１３２は、サーバ情報保持部１３８を参照し、登録ＩＰアドレスに対応するノード（以下、登録ノードと称す）に対して予め定められた通信用途である本来用途に関する情報を取得する。分類部１３２は、その本来用途に対応したパケットと、本来用途以外の通信用途である非本来用途に対応したパケットとに分類する。本来用途は、例えば登録ノードがＷＥＢサーバであれば、ポート番号「８０」に対応するＷＥＢ通信である。非本来用途は、例えば本来用途以外の通信用途であり、登録ノードがＷＥＢサーバであればポート番号「２０」に対応するＦＴＰ転送などである。
【００４７】
図５は、サーバ情報保持部１３８に保持されるデータの一例を示すデータ構造図である。サーバ情報保持部１３８は、ノードのノード名２１４と、ノードのＩＰアドレス２１８と、ノードの用途２２４と、を対応付けて保持する。
分類部１３２は、サーバ情報保持部１３８を参照してあるノードの本来用途に関する情報を取得する際、そのノードの用途を参照して本来用途を取得してもよい。
【００４８】
図３に戻る。集計部１３０は、少なくともひとつの登録ノードについて、本来用途に対応したパケットを集計する。特に集計部１３０は、所定の長さの期間すなわち時間帯ごとに、登録ノードの本来用途に対応したパケットのデータ量を集計し、また非本来用途に対応したパケットのデータ量を集計する。
例えば、登録ＩＰアドレス「121.21.15.1」に対応する登録ノードについて、時間帯「02/15/10 11:10:00~11:20:00」で集計する場合について考える。図５のサーバ情報保持部１３８から登録ノードは第１フロントエンドサーバ１０２４ａでありＷＥＢサーバである。集計部１３０は、分類部１３２における分類結果から、始点ＩＰアドレスが「121.21.15.1」であり、通信用途が「ＷＥＢ通信」であり、時刻が時間帯「02/15/10 11:10:00~11:20:00」に含まれるパケットのデータ量を足し合わせて、本来用途に対する集計結果を得る。また、集計部１３０は、始点ＩＰアドレスが「121.21.15.1」であり、通信用途が「ＷＥＢ通信」ではなく、時刻が時間帯「02/15/10 11:10:00~11:20:00」に含まれるパケットのデータ量を足し合わせて、非本来用途に対する集計結果を得る。
【００４９】
なお、集計部１３０は、負荷管理装置１０１０については、外部から負荷管理装置１０１０に送られるパケットおよび負荷管理装置１０１０から外部に送られるパケットの総データ量（以下、単に総データ量と称す）を集計する。特に集計部１３０は、時間帯ごとに、情報処理システム２の外部のＩＰアドレスを始点ＩＰアドレスとし負荷管理装置１０１０のＩＰアドレスを終点ＩＰアドレスとするパケットのデータ量を集計し、負荷管理装置１０１０のＩＰアドレスを始点ＩＰアドレスとし情報処理システム２の外部のＩＰアドレスを終点ＩＰアドレスとするパケットのデータ量を集計し、それぞれの集計結果を足し合わせて総データ量を得る。
集計部１３０は、集計結果を第１指標保持部１０８に登録する。
【００５０】
図６は、第１指標保持部１０８に保持されるデータの一例を示すデータ構造図である。第１指標保持部１０８は、登録ノードのノード名２２８と、登録ノードの本来用途２３０と、本来用途に対応するポート番号である主なポート番号２３２と、本来用途データ量２３４と、非本来用途データ量２３６と、集計部１３０で使用される所定の長さの期間すなわち時間帯に対応する計測期間２３８と、を対応付けて保持する。
本来用途データ量２３４は、登録ノードの本来用途に対応したパケットのデータ量を計測期間内で足し合わせた結果のデータ量である。
非本来用途データ量２３６は、登録ノードの非本来用途に対応したパケットのデータ量を計測期間内で足し合わせた結果のデータ量である。
なお、負荷管理装置１０１０については本来用途データ量として総データ量が保持されることは上述の通りである。
【００５１】
図３に戻る。使用状況取得部１１０は、内部ネットワーク３を通じて所定の時間間隔もしくはリアルタイムで、情報処理システム２のノードから、そのノードの使用状況に関する情報を取得する。ノードの使用状況は、例えばノードがフロントエンドサーバ（ＷＥＢサーバ）１０２４やアプリケーションサーバ１０２６であれば消費電力（単位はＷ）や機器の温度（単位は℃）やＣＰＵ使用率（単位は％）であり、ノードがデータベースサーバ１０２８であればデータ転送量（単位はＭＢ／秒）や消費電力や機器の温度であり、ノードが負荷管理装置１０１０などのネットワーク機器であればデータ転送量や消費電力や機器の温度である。
【００５２】
使用状況取得部１１０は、サーバの基本ＯＳに搭載されているシステムパフォーマンスモニタのデータを取得してもよい。
使用状況取得部１１０は、各ノードに電力を供給するバスバー方式のテーブルタップ型のＰＤＵから各ノードに供給された電力の計測値を消費電力として取得してもよい。
使用状況取得部１１０は、ノードの温度を計測できる市販の装置（温度センサや、光ファイバ方式の温度センサ）と、その温度データを記憶して報告するデータ収集機能（市販されているソフトウエアパッケージ、またはサーバ組み込み型の特殊ハードウエアパッケージ）と、を利用して機器の温度を取得してもよい。
【００５３】
あるいはまた、使用状況取得部１１０は、米国ＥＰＡのEnergy Star for Server 2で登録し認定されるノードからは、下記の３つの報告機能を使用して消費電力と機器の温度とＣＰＵ使用率とを取得する。すなわち、米国のＥＰＡが行っているEnergy Star for Server 2では、登録し認定される機器は、３つの報告機能をハードウエア本体のマイクロコード（ファームウエア）のレベルで提供でき、基本ＯＳや他の計測ソフト、アプリケーションや本来のサーバの処理能力（本体のＣＰＵ・ＭＰＵ（Micro Processing Unit））には、影響を与えないハードウエアの管理機能を持つこととされている。この３つの報告機能は、１）サーバの実電力消費数値、２）サーバの本体ＣＰＵ・ＭＰＵ等の処理用プロセッサの使用率、３）サーバの実稼動の温度、である。
【００５４】
使用状況取得部１１０は、取得した使用状況に関する情報と、それを取得した時刻に対応する時間帯と、取得先のノード名と、ＩＰアドレスと、を対応付けて使用状況保持部１１２に登録する。使用状況取得部１１０が所定の時間間隔で情報を取得する場合は、時間帯は例えば取得した時刻から所定の時間間隔が経過するまでの期間に設定される。あるいはまた、使用状況取得部１１０がリアルタイムで情報を取得する場合は、所定の長さを有する期間を時間帯とし、使用状況に関する情報をその期間で時間平均する。
【００５５】
図７は、使用状況保持部１１２に保持されるデータの一例を示すデータ構造図である。使用状況保持部１１２は、使用状況取得部１１０によって使用状況が取得されたノードのノード名２４４と、ＩＰアドレス２４５と、使用状況が取得された時刻に対応する記録時間帯２４６と、取得された消費電力２４８と、取得された機器温度２５０と、取得されたＣＰＵ使用率２５２と、取得されたデータ転送量２５３と、を対応付けて保持する。
【００５６】
一般的に、ＷＥＢサーバにおいて、所定の量、例えば１ｋＢのＷＥＢ通信用のデータを処理して送るにはどれだけのＣＰＵ使用率が必要かは測定できる。つまり、ＷＥＢサーバについて、ＷＥＢ通信用のデータ量とＣＰＵ使用率との関係は事前に測定できる。係数保持部１１４（図８で後述）はその関係を示す係数（例えば、％・分／ＧＢの単位）を保持する。この係数が１である場合、例えば１ＧＢ分のＷＥＢ通信用のデータを処理して送るためにＷＥＢサーバは１％のＣＵＰ使用率で１分間稼動しなければならないことを意味する。
【００５７】
図８は、係数保持部１１４に保持されるデータの一例を示すデータ構造図である。係数保持部１１４は、ＷＥＢサーバのサーバ名２４０と、係数２４２と、を対応付けて保持する。
【００５８】
図３に戻る。第１解析部１１６は、第１算出部１３４と、第２算出部１３６と、第１合成部１４２と、を含む。
第１算出部１３４は、第１指標保持部１０８に登録される登録ノードのうちＷＥＢサーバ（以下、登録ＷＥＢサーバと称す）について、本来用途データ量すなわちＷＥＢ通信用のデータ量を対応する計測期間の長さ、例えば分を単位とする長さ、で除し、ＷＥＢ通信用の時間平均データ量（例えば、ＧＢ／分の単位）を得る。第１算出部１３４は、係数保持部１１４からその登録ＷＥＢサーバに対応する係数を取得する。第１算出部１３４は、その登録ＷＥＢサーバについて、ＷＥＢ通信用の時間平均データ量と係数とを乗算し、乗算の結果得られる値（例えば、％の単位）を、その登録ＷＥＢサーバおよび計測期間における、ＷＥＢ通信に関する処理によるＣＰＵ使用率の推測値（以下、第１推測値と称す）とする。
【００５９】
例えば、図６の第１指標保持部１０８に登録されるノード名「第１フロントエンドサーバ」に着目すると、第１算出部１３４は、計測期間「02/15/10 11:10:00~11:20:00」におけるＷＥＢ通信用のデータ量として「５００（ＧＢ）」を得る。第１算出部１３４は、「５００（ＧＢ）」を計測期間の長さ「１０（分）」で除し、ＷＥＢ通信用の時間平均データ量「５０（ＧＢ／分）」を得る。第１算出部１３４は、図８の係数保持部１１４を参照し、係数「１．５（％・分／ＧＢ）」を得る。第１算出部１３４は、ＷＥＢ通信用の時間平均データ量「５０（ＧＢ／分）」と係数「１．５（％・分／ＧＢ）」とを乗算し「７５（％）」を得る。第１算出部１３４は、この値「７５（％）」をノード名「第１フロントエンドサーバ」のＷＥＢサーバにおける計測期間「02/15/10 11:10:00~11:20:00」中のＷＥＢ通信に関する処理による第１推測値とする。
【００６０】
第２算出部１３６は、第１算出部１３４における第１推測値の計算で対象とされた登録ＷＥＢサーバのサーバ名と計測期間とをキーとして使用状況保持部１１２を検索し、対応する消費電力と機器温度とＣＰＵ使用率とを抽出する。第２算出部１３６は、第１推測値を使用状況保持部１１２から抽出したＣＰＵ使用率から減じ、ＷＥＢ通信に関する処理以外の処理によるＣＰＵ使用率の推測値（以下、第２推測値と称す）とする。
ＷＥＢ通信に関する処理以外の処理は、例えば他の通信に関する処理や、ウイルスチェッカーによるウイルススキャンや、ハードディスクドライブへのデータの書き込みである。あるいはまた、アイドル状態にあってなにも仕事をしていないことも考えられる。
【００６１】
第２算出部１３６は、抽出された消費電力を第１推測値と第２推測値との比に分け、第１推測値に対応する値をＷＥＢ通信に関する処理のために使用された電力の推測値、第２推測値に対応する値をそうでない処理のために使用された電力の推測値とする。機器温度についても、機器温度と外気温との差を第１推測値と第２推測値との比に分ける点で同様である。
【００６２】
例えば、図６の第１指標保持部１０８に登録されるノード名「第１フロントエンドサーバ」に着目すると、第２算出部１３６は図７に示される使用状況保持部１１２から、ノード名「第１フロントエンドサーバ」と計測期間「02/15/10 11:10:00~11:20:00」とに対応する消費電力「３０（Ｗ）」、機器温度「３５（℃）」、ＣＰＵ使用率「８０（％）」を抽出する。第２算出部１３６は、第１推測値「７５（％）」をＣＰＵ使用率「８０（％）」から減じ、第２推測値「５（％）」を得る。第２算出部１３６は、消費電力「３０（Ｗ）」を第１推測値「７５（％）」と第２推測値「５（％）」との比すなわち１５：１に分け、ＷＥＢ通信に関する処理のために使用された電力の推測値「２８（Ｗ）」とそれ以外の処理のために使用された電力の推測値「２（Ｗ）」と、を得る。
【００６３】
第１合成部１４２は、時刻およびノード名をキーとして、第１指標保持部１０８に保持されるデータと、使用状況保持部１１２に保持されるデータと、第２算出部１３６による計算結果（登録ＷＥＢサーバについての、ＷＥＢ通信処理由来の消費電力、ＷＥＢ通信処理由来の上昇温度、ＷＥＢ通信処理由来のＣＰＵ使用率）と、を対応付けて第２指標保持部１１８に登録する。
【００６４】
図９は、第２指標保持部１１８に保持されるデータの一例を示すデータ構造図である。第２指標保持部１１８は、ノード名２５４と、本来用途２５６と、主なポート番号２５８と、本来用途データ量２６０と、非本来用途データ量２６２と、計測期間２６４と、消費電力２６６と、機器温度２６８と、ＣＰＵ使用率２７０と、データ転送量２７１と、ＷＥＢ通信由来消費電力２７２と、ＷＥＢ通信由来上昇温度２７４と、ＷＥＢ通信由来ＣＰＵ使用率２７６と、を対応付けて保持する。
ＷＥＢ通信由来消費電力２７２は、第２算出部１３６によって算出された、ＷＥＢ通信に関する処理のために使用された電力の推測値である。ＷＥＢ通信由来上昇温度２７４は、第２算出部１３６によって算出された、機器温度と外気温との差のうちＷＥＢ通信に関する処理によって上昇したと予測される分である。ここでは外気温は２５（℃）とされている。ＷＥＢ通信由来ＣＰＵ使用率２７６は、第１算出部１３４によって算出された第１推測値である。
【００６５】
図３に戻る。第２解析部１５２は、第２指標保持部１１８に保持されるデータのうちＷＥＢサーバ（フロントエンドサーバ１０２４）に関するデータを、使用状況取得部１１０における所定の時間間隔よりも長い時間間隔、例えば１ヶ月や半年の時間間隔で統計処理する。
第２解析部１５２は、第２指標保持部１１８に登録されているノードのうちＷＥＢサーバについて、消費電力の時間平均である平均消費電力と、統計処理対象の期間内における消費電力の最高値である最高消費電力と、を算出する。
第２解析部１５２は、第２指標保持部１１８に登録されているノードのうちＷＥＢサーバについて、ＷＥＢ通信由来の消費電力の時間平均を本来用途データ量（ＷＥＢ通信用のデータ量）の時間平均で除した値（例えば、Ｗ／ＧＢの単位）を算出する。ここで算出される値は、ＷＥＢ通信用の単位データ量に対する消費電力を表す電力コストである。例えばこの電力コストが１（Ｗ／ＧＢ）であることは、ＷＥＢサーバにおいて１ＧＢ分のＷＥＢ通信用のデータを処理するのに１Ｗ消費することを示す。ＷＥＢ通信用のデータ量をＷＥＢサーバに対する負荷と考えると、電力コストは、各ＷＥＢサーバにおいて同じ負荷（単位データ量）がかけられた場合にそのＷＥＢサーバで消費される電力を示す。
第２解析部１５２は、サーバ名と、平均消費電力と、最高消費電力と、電力コストと、を対応付けて第３指標保持部１５８に登録する。
【００６６】
図１０は、第３指標保持部１５８に保持されるデータの一例を示すデータ構造図である。第３指標保持部１５８は、サーバ名３０４と、平均消費電力３０６と、最高消費電力３０８と、電力コスト３１０と、を対応付けて保持する。
【００６７】
図３に戻る。表示制御部１２０は、第１指標保持部１０８、第２指標保持部１１８、第３指標保持部１５８のうちの少なくともひとつに基づき、ノードごとに各種パラメータを示す画面をモニタ１４０に表示させる。
【００６８】
指標送信部１５４は、第３指標保持部１５８に登録されているデータを負荷管理装置１０１０に送信する。
【００６９】
上述の解析装置１００において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
【００７０】
（負荷管理装置１０１０）
図１１は、負荷管理装置１０１０の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【００７１】
負荷管理装置１０１０は、稼動履歴保持部１１１２と、サーバ群状態保持部１１１４と、接続保持部１１１６と、要求取得部１１２０と、要求割当部１１３０と、負荷検出部１１４０と、状態設定部１１５０と、負荷予測部１１６０と、稼動履歴記録部１１８０と、を備える。
【００７２】
稼動履歴保持部１１１２は、情報処理装置１０２０の過去の稼動履歴を保持する。サーバ群状態保持部１１１４は、現在のサーバ群１０２２の状態を保持する。稼動履歴保持部１１１２およびサーバ群状態保持部１１１４の詳細は後述する。
【００７３】
接続保持部１１１６は、同一アクセス内のパケットは同じサーバ群１０２２へ送られること（以下、アクセスの同一性と称す）を保証するために設けられる。
図１２は、接続保持部１１１６を示すデータ構造図である。接続保持部１１１６には、後述する接続更新部１１３８によってアクセスに対応するエントリが生成される。一回のアクセスに対してひとつのエントリが対応する。接続保持部１１１６のエントリ１１１８は、アクセスしてきたユーザ端末１００６のＩＰアドレスであるユーザ端末ＩＰアドレス１２１０と、負荷管理装置１０１０のＩＰアドレスである負荷管理装置ＩＰアドレス１２１２と、負荷管理装置１０１０によってそのアクセスに割り当てられたサーバ群１０２２のフロントエンドサーバ１０２４のＩＰアドレスである割当サーバ群ＩＰアドレス１２１４と、ユーザ端末１００６が同一の場合にアクセスの異同を判別するためのシーケンス番号１２１６と、を有する。同一ユーザ端末１００６において、異なるアクセスには異なるシーケンス番号が割り振られる。以下、サーバ群１０２２のフロントエンドサーバ１０２４のＩＰアドレスを単にサーバ群１０２２のＩＰアドレスと称す。
【００７４】
図１１に戻る。要求取得部１１２０は、外部ネットワーク１００４と接続される。要求取得部１１２０は、外部ネットワーク１００４から到来するユーザ端末１００６からのアクセスの行きパケットを取得する。この際、要求取得部１１２０は行きパケットに含まれる終点ＩＰアドレスを基に自己宛のパケットであるか否かを判別する。要求取得部１１２０は、取得した行きパケットを要求割当部１１３０に渡す。
【００７５】
なお、本明細書において「渡す」とは、ある機能ブロックからある機能ブロックに情報要素に対する処理が移ることを意味する。要求取得部１１２０と要求割当部１１３０との間で言うと、渡すとは、例えば要求取得部１１２０が図示しない一時メモリを有し、取得した行きパケットをそこに蓄えた上で、要求割当部１１３０からの要請に応じて適宜行きパケットを一時メモリから要求割当部１１３０に伝達することである。また渡すとは、負荷管理装置１０１０が図示しない記憶領域を有し、要求取得部１１２０は取得した行きパケットをその記憶領域に書き込み、要求割当部１１３０は適宜その記憶領域から必要な行きパケットを読み出して処理することであってもよい。
【００７６】
要求割当部１１３０は、ユーザ端末１００６からのアクセスの行きパケットを稼動状態にあるサーバ群のうちのひとつに割り当てる。特に傾斜配分モードでは、ユーザ端末１００６からのアクセスが新規のアクセスである場合、要求割当部１１３０は解析装置１００から取得する指標に基づいて、その新規のアクセスをサーバ群のうちのひとつに割り当てる。要求割当部１１３０は、同一接続判断部１１３２と、サーバ群選択部１１３４と、アドレス変換部１１３６と、接続更新部１１３８と、を含む。
【００７７】
同一接続判断部１１３２は、要求取得部１１２０から行きパケットを取得し、その行きパケットが新規のアクセスによるものか否かを判別する。同一接続判断部１１３２は、取得した行きパケットの始点ＩＰアドレスとシーケンス番号とを読み取る。同一接続判断部１１３２は、読み取られた始点ＩＰアドレスとシーケンス番号とをキーとして接続保持部１１１６のエントリを検索し、それらと一致するエントリが存在する場合、そのエントリに含まれる割り当てられたサーバ群の割当サーバ群ＩＰアドレスを取得する。同一接続判断部１１３２は、この取得された割当サーバ群ＩＰアドレスと行きパケットとをアドレス変換部１１３６に渡す。
【００７８】
なお、このように一致するエントリが存在する場合は、当該行きパケットは既にあるサーバ群１０２２（エントリの割当サーバ群ＩＰアドレスで指定されるサーバ群１０２２）に割り当てられたアクセスのなかのひとつのパケットである。アドレス変換部１１３６は、渡された行きパケットの終点ＩＰアドレスを、同一接続判断部１１３２によって接続保持部１１１６から取得された割当サーバ群ＩＰアドレスに変換する。このように終点ＩＰアドレスが変換された行きパケットはアドレス変換部１１３６から割当パケットとして内部ネットワーク３に送出される。
【００７９】
一致するエントリが存在しない場合は、同一接続判断部１１３２は当該行きパケットをサーバ群選択部１１３４に渡す。この場合は同一接続判断部１１３２は新規のアクセスを検知したと言うことができる。
【００８０】
サーバ群選択部１１３４は、同一接続判断部１１３２から新規のアクセスに対応する行きパケットを受け取ると、サーバ群状態保持部１１１４を参照してそのアクセスを処理させるサーバ群１０２２を選択する。
【００８１】
図１３は、サーバ群状態保持部１１１４を示すデータ構造図である。サーバ群状態保持部１１１４は、サーバ群１０２２のＩＰアドレス１２０２と、サーバ群１０２２の状態１２０４と、サーバ群１０２２の稼働率１２０６と、を対応付けて保持する。サーバ群１０２２の稼働率１２０６は、サーバ群１０２２のピークアクセス数に対する現在そのサーバ群１０２２が処理しているアクセス数の割合を％単位で示す。この稼働率は、図示されない稼働率更新部によって、予め定められているサーバ群１０２２のピークアクセス数と、接続保持部１１１６から分かるサーバ群１０２２に現在割り当てられているアクセス数とから演算され更新されてもよい。あるいは、図示されない稼働率更新部が稼動状態にあるサーバ群１０２２から稼働率を取得し、サーバ群状態保持部１１１４の稼働率を更新してもよい。
【００８２】
図１１に戻る。サーバ群選択部１１３４は、サーバ群状態保持部１１１４に登録されたサーバ群のなかからサーバ群の状態を参照して稼動状態にあるサーバ群を抽出する。要求割当部１１３０が省電力モードに設定されているか通常モードに設定されているか傾斜配分モードに設定されているかによって、サーバ群選択部１１３４が稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択するアルゴリズムは異なる。以下それぞれの場合について説明する。
【００８３】
１．省電力モード
省電力モードでは、サーバ群選択部１１３４は、稼動状態にあるサーバ群の稼働率が１００％となるように、稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択する。例えば図１３の例では、サーバ群選択部１１３４は新規のアクセスを処理させるサーバ群として第３サーバ群１０２２ｃを選択する。また、例えば第１サーバ群１０２２ａ、第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃが稼動状態に設定されており、第１サーバ群１０２２ａの稼働率が１００％、第２サーバ群１０２２ｂの稼働率が８０％、第３サーバ群１０２２ｃの稼働率が０％の場合、サーバ群選択部１１３４は新規のアクセスを処理させるサーバ群として第２サーバ群１０２２ｂを選択する。
【００８４】
２．通常モード
通常モードでは、サーバ群選択部１１３４は、予め情報処理システム２の管理者によって設定されている負荷分散アルゴリズムにしたがって、新規のアクセスを処理させるのに最適なサーバ群を選択する。ここで使用される負荷分散アルゴリズムは、順番にサーバ群１０２２が選択されるラウンドロビン方式や、処理しているアクセス数が最小のサーバ群を選択する最小接続方式や、１番早く応答しているサーバ群を選択する最速方式などの公知のアルゴリズムである。
【００８５】
３．傾斜配分モード
傾斜配分モードでは、サーバ群選択部１１３４は、解析装置１００の指標送信部１５４から第３指標保持部１５８に保持されるデータを受信する。サーバ群選択部１１３４は受信したデータから、稼動状態にあるサーバ群のフロントエンドサーバの電力コストをそのサーバ群の電力コストとして抽出する。サーバ群選択部１１３４は、稼動状態にあるサーバ群から、新規のアクセスを処理させるサーバ群として電力コストが小さいサーバ群を優先的に選択する。
【００８６】
サーバ群選択部１１３４は、選択されたサーバ群のＩＰアドレスと新規のアクセスに対応する行きパケットとをアドレス変換部１１３６に渡す。アドレス変換部１１３６は、渡された行きパケットの終点ＩＰアドレスを、サーバ群選択部１１３４によって選択されたサーバ群のＩＰアドレスに変換する。このように終点ＩＰアドレスが変換された行きパケットはアドレス変換部１１３６から割当パケットとして内部ネットワーク３に送出される。
【００８７】
接続更新部１１３８は、サーバ群選択部１１３４で新規のアクセスに対してサーバ群１０２２の選択が行われる毎に、その選択に関する情報をサーバ群選択部１１３４から取得し、接続保持部１１１６に対応するエントリを追加する。この選択に関する情報は、新規のアクセスを行ったユーザのユーザ端末１００６のユーザ端末ＩＰアドレスと、負荷管理装置ＩＰアドレスと、新規のアクセスに対して選択されたサーバ群の割当サーバ群ＩＰアドレスと、シーケンス番号と、を含む。
また、接続更新部１１３８は、適宜不要となったエントリを削除する。
【００８８】
負荷検出部１１４０は、要求取得部１１２０によって取得されたアクセスのアクセス数を周期的に検出する。負荷検出部１１４０は、接続保持部１１１６を参照してエントリの数をカウントすることで、所定の時間間隔で情報処理装置１０２０全体へのアクセス数（以下、全アクセス数と称す）を取得する。また負荷検出部１１４０は、要求取得部１１２０と要求割当部１１３０との間の行きパケットの流れを監視し、所定の時間間隔でアクセスの数をカウントし、そのカウント数から単位時間当たりのアクセスの数、つまりアクセス数を導出してもよい。なお、負荷検出部１１４０は要求取得部１１２０の前段や要求割当部１１３０の後段など、負荷管理装置１０１０の任意の箇所で負荷を監視してもよい。負荷検出部１１４０は、検出した全アクセス数を状態設定部１１５０の負荷比較部１１５２に渡す。
【００８９】
負荷検出部１１４０における上述の時間間隔は負荷管理装置１０１０のモードを更新する基準となる時間間隔であり、アクセス数の変動率に基づいて定められる。負荷検出部１１４０は図示しない時間間隔設定部を有し、時間間隔設定部はアクセス数の変動率を監視し、変動率が大きいほど時間間隔を短く設定する。これにより、より適応的なサーバ群状態の制御が可能となる。また、処理を簡素化するという観点からは時間間隔は情報処理システム２の管理者によって予め定められてもよい。
【００９０】
状態設定部１１５０は、全アクセス数が所定のアクセスしきい値Ｍｏより少ない場合もしくは解析装置１００から得られる総データ量が所定のデータ量しきい値Ｄｏより少ない場合、情報処理装置１０２０に含まれる少なくともひとつのサーバ群１０２２を省電力状態に設定する。
【００９１】
状態設定部１１５０におけるアクセスしきい値Ｍｏまたはデータ量しきい値Ｄｏは、情報処理装置１０２０の性能が落ちない範囲に設定される。ここで性能とは、例えばどれだけのアクセス数をどの程度の速さで処理できるかということである。あるいは性能とは、ひとつのアクセスが処理されるのにかかる時間などのレスポンスタイムであってもよい。また、情報処理装置１０２０の性能が落ちる、とは、例えばあるサーバ群１０２２に対してピークアクセス数を越える数のアクセスが割り当てられ、その結果そのサーバ群１０２２の処理速度が落ちることにより情報処理装置１０２０全体のアクセスの処理速度が落ちることである。
【００９２】
例えば第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする。この場合アクセスしきい値Ｍｏを９０００に設定すると、全アクセス数が８５００であっても少なくともひとつのサーバ群１０２２を省電力状態に設定しなくてはならない。ここでは第５サーバ群１０２２ｅを省電力状態に設定したとする。残りの４つのサーバ群１０２２ａ〜１０２２ｄのトータルのピークアクセス数は８０００であり、全アクセス数９５００よりも少ない。したがってこの場合残りの４つのサーバ群１０２２ａ〜１０２２ｄのうちの少なくともひとつのサーバ群はピークアクセス数以上のアクセスを処理しなくてはならずそのサーバ群の処理速度は低下する。これにより情報処理装置１０２０全体の処理速度が落ちることとなる。このような状況を避けるために、アクセスしきい値Ｍｏまたはデータ量しきい値Ｄｏは情報処理装置１０２０の性能が落ちない範囲に設定される。上述の例ではアクセスしきい値Ｍｏは８０００以下に設定されればよい。
【００９３】
状態設定部１１５０は、サーバ群１０２２の最大性能を発揮せしめる前提で、要求取得部１１２０によって取得されたアクセスを処理させるサーバ群を選択し、残りのサーバ群を省電力状態に設定する。この場合サーバ群１０２２の最大性能を発揮せしめる、とは、例えばサーバ群１０２２にピークアクセス数でアクセス処理を行わせることであり、言い換えるとサーバ群１０２２を１００％の稼働率で使用することである。さらに状態設定部１１５０は、全アクセス数または総データ量の変動により情報処理装置１０２０の性能が落ちると予測される場合には、省電力状態に設定されている少なくともひとつのサーバ群を稼動状態に設定する。
【００９４】
サーバ群１０２２を省電力状態または稼動状態に設定することに関して、状態設定部１１５０では、稼動状態にするサーバ群の数に応じた全アクセス数の範囲または総データ量の範囲が定められている。状態設定部１１５０は例えば全アクセス数が０から第１しきい値Ｔ１の範囲にあればひとつのサーバ群のみを稼動状態とし、他のサーバ群を省電力状態とする。表１は、状態設定部１１５０における状態設定に関して、稼動状態とするサーバ群の数と、ＯＳ休眠状態とするサーバ群の数と、電源オフ状態とするサーバ群の数と、全アクセス数の範囲と、の関係を示す。Ｔ２は第２しきい値、Ｔ３は第３しきい値であり、Ｔ１＜Ｔ２＜Ｔ３である。個々のしきい値は予め情報処理システム２の管理者によって設定される。
【表１】
【００９５】
第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３はそれぞれサーバ群１０２２を１００％の稼働率で使用することを前提に設定される。つまり上述の第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする例では、Ｔ１＝２０００、Ｔ２＝４０００、Ｔ３＝６０００である。この場合、全アクセス数のアクセスを処理するのに必要最低限の数のサーバ群が稼動状態とされる。また、例えば第１しきい値Ｔ１と第２しきい値Ｔ２との間にあった全アクセス数が増大して第２しきい値Ｔ２を越えた場合、そのままだと少なくともひとつのサーバ群の稼働率が１００％を上回ると予測されるので、稼動状態とするサーバ群の数をひとつ増やして情報処理装置１０２０の処理速度の低下を回避する。
【００９６】
状態設定部１１５０は、負荷比較部１１５２と、稼動サーバ群決定部１１５４と、状態信号生成部１１５６と、を含む。
負荷比較部１１５２は、全アクセス数を使用するアクセス数モードと、総データ量を使用するデータ量モードと、を有する。
負荷比較部１１５２は、全アクセス数モードでは、負荷検出部１１４０から取得した全アクセス数と、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３、アクセスしきい値Ｍｏとの大小関係を判別する。この大小関係は例えば「Ｔ２＜全アクセス数＜Ｔ３」という情報である。負荷比較部１１５２はこの大小関係に関する情報を稼動サーバ群決定部１１５４に渡す。
負荷比較部１１５２は、総データ量モードでは、解析装置１００から第１指標保持部１０８に保持される総データ量を取得する。負荷比較部１１５２は、取得した総データ量について上記の全アクセス数の場合と同様に大小関係を判別し、判別された大小関係に関する情報を稼動サーバ群決定部１１５４に渡す。
【００９７】
稼動サーバ群決定部１１５４は、負荷比較部１１５２から渡された情報が全アクセス数についての大小関係に関する情報であれば、その情報を基に表１のストラテジにしたがい、サーバ群１０２２の状態の切替の必要性を判別する。稼動サーバ群決定部１１５４は、負荷比較部１１５２から渡された情報が総データ量についての大小関係に関する情報であれば、その情報を基に表１と同様のストラテジにしたがい、サーバ群１０２２の状態の切替の必要性を判別する。
稼動サーバ群決定部１１５４は、サーバ群１０２２の状態の切替が必要な場合には、解析装置１００から取得する指標に基づいて、稼動状態とするサーバ群とＯＳ休眠状態とするサーバ群と電源オフ状態とするサーバ群を選択する。
稼動サーバ群決定部１１５４はこの選択に基づきサーバ群状態保持部１１１４を更新する。稼動サーバ群決定部１１５４は、状態の切り替えが必要なサーバ群１０２２の情報を状態信号生成部１１５６に渡す。稼動サーバ群決定部１１５４は、状態の切り替えが必要ない場合には処理を中断または終了し、次の情報を待ち受ける。
【００９８】
稼動サーバ群決定部１１５４は、全アクセス数についての表１のストラテジまたは総データ量についての同様のストラテジから稼動状態、ＯＳ休眠状態および電源オフ状態とするサーバ群の数をまず決める。次に稼動サーバ群決定部１１５４はサーバ群状態保持部１１１４を参照し、サーバ群１０２２の状態を切り替える必要があるか、言い換えると負荷検出部１１４０が取得した全アクセス数または解析装置１００から取得した総データ量に対応する各状態のサーバ群の数とサーバ群状態保持部１１１４に登録されている現在の各状態のサーバ群の数とが一致するか否かを判断する。そこで一致する場合は稼動サーバ群決定部１１５４は処理を中断または終了する。
【００９９】
一致しない場合は、稼動サーバ群決定部１１５４はそれぞれの状態にするサーバ群を決める。稼動サーバ群決定部１１５４は、解析装置１００の指標送信部１５４から第３指標保持部１５８に保持されるデータを受信する。稼動サーバ群決定部１１５４は、受信したデータを基に各サーバ群１０２２に対して省電力状態とされる順番を示す省エネ停止可能順位を設定する。省エネ停止可能順位は「１」が最も高く、数が増えるにつれて低くなる順位である。
稼動サーバ群決定部１１５４では、第３指標保持部１５８に保持されるフロントエンドサーバ１０２４の平均消費電力、最高消費電力、電力コストを、そのフロントエンドサーバ１０２４が属するサーバ群１０２２の平均消費電力、最高消費電力、電力コストのそれぞれとみなす。
【０１００】
表２は、サーバ群１０２２の電力コストに基づき省エネ停止可能順位を定める場合の、サーバ群名と平均消費電力と最高消費電力と電力コストと省エネ停止可能順位との関係を示す。
【表２】
表２のストラテジでは、サーバ群１０２２の電力コストが大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定される。電力コストが遜色ない２つのサーバ群が存在する場合は、平均消費電力や最高消費電力が高いほうのサーバ群の省エネ停止可能順位をより高く設定する（表２の第４サーバ群と第５サーバ群）。
【０１０１】
表３は、サーバ群１０２２の消費電力に基づき省エネ停止可能順位を定める場合の、サーバ群名と平均消費電力と最高消費電力と電力コストと省エネ停止可能順位との関係を示す。
【表３】
表３のストラテジでは、サーバ群１０２２の平均消費電力と最高消費電力との和が大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定される。
情報処理装置１０２０において各サーバ群１０２２が主にＷＥＢ通信をおこなっており他の用途の処理は無視できる程度であり、また要求割当部１１３０において稼動状態にあるサーバ群にアクセスが均等に割り当てられる設定となっている場合は、稼動状態にあるサーバ群には同じ負荷がかけられれていると考えることができる。したがって、稼動状態にある各サーバ群の平均消費電力は、同じ負荷がかけられれている場合に消費される電力の平均値と同一視することができ、また、稼動状態にある各サーバ群の最高消費電力は、同じ負荷がかけられれている場合に消費される電力の最高値と同一視することができる。この場合、表３のストラテジでは、サーバ群１０２２に同じ負荷がかけられた場合に消費される電力が大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定されているといえる。
【０１０２】
稼動サーバ群決定部１１５４は、稼動状態にあるサーバ群のひとつを省電力状態に切り替える必要がある場合、稼動状態にあるサーバ群のうち表２または表３で設定される省エネ停止可能順位が最も高いサーバ群を省電力状態とすべきサーバ群として選択する。
稼動サーバ群決定部１１５４は、省電力状態にあるサーバ群のひとつを稼動状態に切り替える必要がある場合、省電力状態にあるサーバ群のうち表２または表３で設定される省エネ停止可能順位が最も低いサーバ群を稼動状態とすべきサーバ群として選択する。
【０１０３】
なお、稼動サーバ群決定部１１５４でのサーバ群１０２２を決める上述のアルゴリズムでは、特に稼動状態を省電力状態に切り替える場合は、アクセスの同一性が考慮されてもよい。つまり、稼動サーバ群決定部１１５４は、接続保持部１１１６を参照し、省電力状態に切り替えるべきサーバ群へのアクセスがなくなるまで待機する。稼動サーバ群決定部１１５４はそのようなアクセスがなくなると、省電力状態に切り替えるべきサーバ群の情報を状態信号生成部１１５６に渡す。これによりアクセスの同一性が保証されうる。
【０１０４】
状態信号生成部１１５６は、状態の切り替えが必要なサーバ群の情報に基づきそのサーバ群に対して切替に対応する休眠導入信号、休眠解除信号、電源オフ信号、および電源オン信号のうちのいずれかを送る。例えば第３サーバ群１０２２ｃを稼動状態（ＯＳ休眠状態）からＯＳ休眠状態（稼動状態）とする必要がある場合、状態信号生成部１１５６は第３サーバ群１０２２ｃに対して休眠導入信号（休眠解除信号）を内部ネットワーク３を介して送出する。また、第３サーバ群１０２２ｃを稼動状態（電源オフ状態）から電源オフ状態（稼動状態）とする必要がある場合、状態信号生成部１１５６は第３サーバ群１０２２ｃに対して電源オフ信号（電源オン信号）を内部ネットワーク３を介して送出する。
状態信号生成部１１５６によって省電力状態から稼動状態に設定されたサーバ群は、それが稼動状態であることが稼動サーバ群決定部１１５４によってサーバ群状態保持部１１１４に記録されるので、要求割当部１１３０によって新規のアクセスが割り当てられる。
【０１０５】
負荷管理装置１０１０は、負荷検出部１１４０で検出された全アクセス数または解析装置１００から取得する総データ量を基に状態設定部１１５０でサーバ群１０２２の状態を適応的に設定する検出モードの他に、過去の稼動履歴を基に予測されたアクセス数（以下、予測アクセス数と称す）を基に状態設定部１１５０でサーバ群１０２２の状態を設定する負荷予測モードを有する。以下、この負荷予測モードについて説明する。
【０１０６】
稼動履歴記録部１１８０は、定期的に情報処理装置１０２０に含まれるサーバ群１０２２ａ〜２２ｅの稼動履歴を稼動履歴保持部１１１２に記録する。稼動履歴記録部１１８０は、例えば１５分に１度サーバ群状態保持部１１１４を参照してその時点での各サーバ群１０２２の状態と稼働率とを取得する。また稼動履歴記録部１１８０はその時点で負荷検出部１１４０によって検出された全アクセス数を取得する。稼動履歴記録部１１８０はそれらの情報を稼動履歴保持部１１１２に書き込む。
図１４は、稼動履歴保持部１１１２を示すデータ構造図である。稼動履歴保持部１１１２は、日時１２１８と、アクセス数１２２０と、稼動サーバ群の数１２２２と、平均稼働率１２２４と、を対応付けて保持する。日時１２１８は、暦の上での日時である。稼動サーバ群の数１２２２は、その日時に稼動状態にあったサーバ群の数である。平均稼働率１２２４は、稼動状態にあったサーバ群の稼働率の平均値である。
【０１０７】
図１１に戻る。負荷予測部１１６０は、過去の稼動履歴を基に負荷を予測する。負荷予測部１１６０は、稼動履歴保持部１１１２を参照し、予測対象の時間帯に対して一年以上前の同月同日の同じ時間帯の稼動履歴を取得し、これを基に予測対象の時間帯の予測アクセス数を決定する。例えば、負荷予測部１１６０が２００９年７月２８日の９：１５〜９：３０におけるアクセス数を予測する場合、負荷予測部１１６０は２００８年７月２８日の９：１５〜９：３０におけるアクセス数（図１４の場合、５４００）を稼動履歴保持部１１１２から取得し、それを予測アクセス数とする。この予測アクセス数の取得は、負荷検出部１１４０における時間間隔と同様の時間間隔で行われる。
【０１０８】
負荷予測部１１６０は予測アクセス数を負荷比較部１１５２に渡す。状態設定部１１５０は、負荷予測部１１６０から予測アクセス数が負荷比較部１１５２に渡された場合、この予測アクセス数を全アクセス数と読み替えて上述した処理を行う。
【０１０９】
上述の負荷管理装置１０１０において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
【０１１０】
以上の構成による情報処理システム２の動作を説明する。図１５は、解析装置１００における一連の処理を示すフローチャートである。傍受部１２２は、ネットワークからパケットを傍受する（Ｓ４０２）。抽出部１２４は、傍受されたパケットから始点アドレスとポート番号とを抽出する（Ｓ４０４）。登録部１２８は、抽出された始点アドレスとポート番号とパケットのデータ量とを通信情報保持部１０４に登録する（Ｓ４０６）。分類部１３２は、通信情報保持部１０４に保持されるデータを始点アドレスでソーティングする（Ｓ４０８）。分類部１３２は、ソーティングされたデータを本来用途と非本来用途とに分類する（Ｓ４１０）。集計部１３０は、分類されたデータを集計する（Ｓ４１２）。第２解析部１５２は、集計結果から各サーバ群１０２２の電力コストを算出する（Ｓ４１４）。
【０１１１】
図１６は、負荷管理装置１０１０における一連の処理を示すフローチャートである。図１６では、要求取得部１１２０と、負荷検出部１１４０と、状態設定部１１５０とで行われる処理についてのフローチャートを示すが、それと平行して要求割当部１１３０がサーバ群状態保持部１１１４を参照して新規のアクセスのサーバ群１０２２への割り当てを行っていることは上述の通りである。また、負荷比較部１１５２ではアクセス数モードが使用される場合を考える。
【０１１２】
要求取得部１１２０は、外部ネットワーク１００４からアクセスを取得する（Ｓ７０２）。負荷検出部１１４０は、全アクセス数を検出する（Ｓ７０４）。状態設定部１１５０は、全アクセス数とアクセスしきい値Ｍｏ、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３との大小比較を行う（Ｓ７０６）。状態設定部１１５０は、その大小比較を基にサーバ群１０２２の状態の切替が必要か否かを判断する（Ｓ７０８）。状態の切替が必要でない場合（Ｓ７０８のＮ）、処理をアクセス取得ステップＳ７０２に戻す。状態の切替が必要な場合（Ｓ７０８のＹ）、状態設定部１１５０は稼動状態のサーバ群の数を増やすか減らすかを判断する（Ｓ７１０）。減らす必要がある場合（Ｓ７１０の減らす）、状態設定部１１５０は、省エネ停止可能順位が最も高い稼動状態のサーバ群を省電力状態に設定する（Ｓ７１２）。増やす必要がある場合（Ｓ７１０の増やす）、状態設定部１１５０は省エネ停止可能順位が最も低い省電力状態のサーバ群を稼動状態に設定する（Ｓ７１４）。負荷管理装置１０１０はこの処理を所定の時間間隔で繰り返す。
【０１１３】
本実施の形態に係る情報処理システム２によると、負荷管理装置１０１０は全アクセス数または総データ量に応じて適応的に稼動状態とするサーバ群を選択し、残りのサーバ群を省電力状態に設定する。ユーザからのアクセスは稼動状態にあるサーバ群のうちのひとつのサーバ群に割り当てられ、そこで処理される。現時点でのアクセス数を処理するのに不必要なサーバ群は省電力状態とされる。したがって、省電力状態としたサーバ群の待機電力分だけ情報処理システム２全体の消費電力を低減できる。また、アクセス数の増大により情報処理システム２の処理能力を増やす必要が出てくると、負荷管理装置１０１０は稼動状態とするサーバ群の数を増やす。
これに加えて、解析装置１００はネットワークを傍受して各サーバ群１０２２の特性の違いを示す指標を算出し、負荷管理装置１０１０は解析装置１００によって算出されたこの指標に基づいて、複数のサーバ群１０２２の状態を制御する。したがって、各サーバ群１０２２の特性の違い合わせてサーバ群１０２２の状態が制御できるので、情報処理システム２の省エネ化を一層進めることができる。
【０１１４】
また、本実施の形態では、負荷管理装置１０１０は解析装置１００によって計測された総データ量がデータ量しきい値Ｄｏより少ない場合、情報処理装置１０２０に含まれるサーバ群１０２２のうちの少なくともひとつのサーバ群を省電力状態に設定する。したがって、負荷管理装置１０１０自身が負荷検出機能を有しない場合でも、解析装置１００から負荷を取得できる。
【０１１５】
また、本実施の形態では、稼動サーバ群決定部１１５４は負荷が所定の値より少ない場合、解析装置１００によって算出された指標に基づいて、稼動状態に設定されている複数のサーバ群のうちアクセスを処理する必要のない少なくともひとつのサーバ群を選択する。状態信号生成部１１５６は、稼動サーバ群決定部１１５４によって選択された少なくともひとつのサーバ群を省電力状態に設定する。
したがって、解析装置１００による各サーバ群１０２２の特性の違いの解析結果を取り入れた形で、稼動状態にあるサーバ群のなかから省電力状態とするサーバ群を選択できる。これにより、全てのサーバ群１０２２を特性上同等と見なした上で省電力状態とするサーバ群を選択する場合と比べて、選択に各サーバ群１０２２の特性の違いを反映できるので、省エネの観点からより好適なサーバ群１０２２の状態制御が可能となる。
【０１１６】
また、稼動サーバ群決定部１１５４は、電力コストが大きいサーバ群を省電力状態とするサーバ群として優先的に選択する。したがって、結果として稼動状態とされるサーバ群の電力コストは、省電力状態とされるサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１１７】
また、本実施の形態では、負荷管理装置１０１０は、解析装置１００によって算出された指標に基づいて、取得されたアクセスを複数のサーバ群１０２２のうちの少なくともひとつに割り当てる。したがって、解析装置１００による各サーバ群１０２２の特性の違いの解析結果を取り入れた形で、アクセスを分配できる。これにより、全てのサーバ群１０２２を特性上同等と見なした上でアクセスを割り当てる場合と比べて、割り当てに各サーバ群１０２２の特性の違いを反映できるので、省エネの観点からより好適な負荷分散が可能となる。
【０１１８】
また、負荷管理装置１０１０は、取得されたアクセスを、電力コストが小さいサーバ群に優先的に割り当てる。したがって、結果としてアクセスがより多く割り当てられるサーバ群の電力コストは、そうでないサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１１９】
また、本実施の形態では、稼動サーバ群決定部１１５４は、負荷が所定の値より多くなると予測される場合には、解析装置１００によって算出された指標に基づいて、省電力状態に設定されている複数のサーバ群のうちの少なくともひとつのサーバ群を選択する。状態信号生成部１１５６は、稼動サーバ群決定部１１５４によって選択された少なくともひとつのサーバ群を稼動状態に設定する。
したがって、解析装置１００による各サーバ群１０２２の特性の違いの解析結果を取り入れた形で、省電力状態にあるサーバ群のなかから稼動状態とするサーバ群を選択できる。これにより、全てのサーバ群を特性上同等と見なした上で稼動状態とするサーバ群を選択する場合と比べて、選択に各サーバ群１０２２の特性の違いを反映できるので、省エネの観点からより好適なサーバ群１０２２の状態制御が可能となる。
【０１２０】
また、稼動サーバ群決定部１１５４は、電力コストが小さいサーバ群を稼動状態とするサーバ群として優先的に選択する。したがって、結果として稼動状態とされるサーバ群の電力コストは、省電力状態とされるサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１２１】
図１７（ａ）〜図１７（ｄ）は、全アクセス数に対する各サーバ群１０２２の稼働率の一例を示すグラフである。ここでは、第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする。また、稼動サーバ群決定部１１５４では表２のストラテジが使用され、サーバ群選択部１１３４では傾斜配分モードが使用される場合を考える。
図１７（ａ）〜図１７（ｄ）はそれぞれ全アクセス数が１６００、２８００、４４００、７０００の場合に対応する。図１７（ａ）〜図１７（ｄ）において「△」はＯＳ休眠状態を示し、「×」は電源オフ状態を示す。
【０１２２】
図１７（ａ）では、第１サーバ群１０２２ａのみが稼動状態とされ、第４サーバ群１０２２ｄはＯＳ休眠状態とされ、第３サーバ群１０２２ｃと、第４サーバ群１０２２ｄと、第５サーバ群１０２２ｅと、は電源オフ状態とされる。図１７（ｂ）では、第５サーバ群１０２２ｅはＯＳ休眠状態とされ、第２サーバ群１０２２ｂと、第３サーバ群１０２２ｃと、は電源オフ状態とされる。図１７（ｃ）では、第３サーバ群１０２２ｃはＯＳ休眠状態とされ、第２サーバ群１０２２ｂは電源オフ状態とされる。図１７（ｄ）では、第２サーバ群１０２２ｂはＯＳ休眠状態とされる。
【０１２３】
本実施の形態に係る情報処理システム２の負荷管理装置１０１０によると、負荷に応じて情報処理装置１０２０に含まれるサーバ群１０２２が省電力状態に設定される。上述した通り稼動状態のサーバ群の消費電力は、アイドル状態であってもピーク時のおよそ６０％である。これに対して省電力状態のサーバ群の消費電力はピーク時のおよそ０〜１０％である。したがって、本実施の形態では、負荷分散を実現しつつ、負荷が少なくアクセスを処理する必要のないサーバ群がある場合はそれらのサーバ群をアイドル状態ではなく省電力状態としている。これにより、情報処理装置１０２０全体の消費電力を低減でき、電力の無駄遣いを抑え、省エネ化を図ることができる。
【０１２４】
また、稼動サーバ群決定部１１５４は接続保持部１１１６を参照してアクセスの同一性を保証し、サーバ群選択部１１３４はサーバ群状態保持部１１１４を参照して現在稼動状態にあるサーバ群を判別している。このように本実施の形態では状態切替機能と負荷分散機能とがひとつの負荷管理装置１０１０で実現されているので、アクセスの同一性が必要な場合はそれをより容易に保証でき、また省電力状態にあるサーバ群に誤ってパケットを送信してしまう可能性を低減できる。
【０１２５】
本実施の形態に係る負荷管理装置１０１０では、全アクセス数＜アクセスしきい値Ｍｏとなる場合、表１に示される通りＯＳ休眠状態とするサーバ群と電源オフ状態とするサーバ群との両方を設けている。これにより、突然の全アクセス数の増大に対しては、復帰のためのオーバヘッドが小さいＯＳ休眠状態にあるサーバ群を稼動状態に戻すことで対応できる。また、そのように対応できる限りにおいては他のサーバ群は電力を消費しない電源オフ状態とし、情報処理装置１０２０全体の消費電力をさらに低減している。なお、表１ではＯＳ休眠状態とするサーバ群をひとつだけ確保しているが、この数はオーバヘッドと消費電力とのかねあいで定められればよく、適宜増減可能であることは本明細書に触れた当業者には理解される。
【０１２６】
本実施の形態に係る負荷管理装置１０１０では、状態設定部１１５０はサーバ群１０２２の最大性能を発揮せしめる前提で稼動状態とするサーバ群を決定する。このサーバ群１０２２の決定方式によると、所与の負荷に対してより多くの数のサーバ群１０２２を省電力状態とすることができる。したがって、情報処理装置１０２０全体の消費電力をより低減できる。なお、稼働率によってサーバ群１０２２の消費電力が異なるのも事実ではあるが、上述の通りアイドル状態でもピーク時のおよそ６０％の電力が消費されることを考えると、稼働率を下げることによる電力削減効果よりもアイドル状態を省電力状態とすることによる電力削減効果のほうが大きいと考えられる。
【０１２７】
また、アクセスしきい値Ｍｏは情報処理装置１０２０の性能が落ちない範囲に設定される。これにより、負荷が多い場合は通常モードで情報処理装置１０２０の並列処理能力をいかんなく発揮させ、負荷が少なくなると省電力モードに移行させて性能を保ちつつ電力消費量を低減できる。
【０１２８】
また、状態設定部１１５０は負荷の変動により情報処理装置１０２０の性能が落ちると予測される場合には、省電力状態にあるサーバ群を稼動状態に設定する。これにより、サーバ群１０２２をピークアクセス数以上で使用しなければならない状況を回避し、アクセス処理の遅滞を避けることができる。
【０１２９】
また、負荷予測部１１６０は過去の稼動履歴を基にアクセス数を予測し、状態設定部１１５０はその予測値に基づいてサーバ群１０２２の状態を設定する。つまり負荷管理装置１０１０は、情報処理システム２の運用の実態を日時、曜日、祭日等のカレンダー区分にて、外部ネットワーク１００４側から発生するアクセス数の傾向情報を過去にさかのぼり蓄積し、その情報を元に運用に該当する日時に予測されるアクセス数を算出する学習機能と、その運用時間帯特異のアクセス数の予測を元に必要な稼動状態サーバ群の数を推測し、必要台数のサーバ群を稼動状態にする機能と、を有する。
【０１３０】
これらの機能は特に情報処理システム２がネットワーク接続型のデータセンタである場合に有益である。これは以下の本発明者の当業者としての知見に基づく。
日々の運用では、ネットワーク接続型のデータセンタの運用では、運用されているアプリケーションシステムにより、稼働率やアクセス数の傾向が把握できる。これは、例えば、インターネット検索を主としているアプリケーションサーバ群では、平日より休日の利用が多く、平日でも、午前より午後、夕方から夜までの利用が多いと言える。また、証券取引所接続の証券会社のインターネット株取引システムでは、証券取引所の運用時間帯に多くの取引による仕事量があり、取引所が取引を閉じている夕方から朝、土日と祝祭日には仕事量は少ない。取引所が閉まっている時間帯では、証券会社の顧客は主に個々の口座の情報を参照するなどのアクセスを行うので取引時間帯より仕事量は低い。
【０１３１】
これらの日々の運用実績のデータを基に、特定の運用日の特定の時間帯に予測される外部ネットワーク１００４よりの仕事量が予測出来ることに本発明者は想到した。証券会社の取引システムのサーバ群は、取引所の運用の時間外は、負荷管理装置１０１０により運用に必要なサーバ群の数を予測し、不必要なサーバ群の電源を切るとかＯＳを休眠させることで消費電力を低減できる。仮に、この予測に反して仕事量が多くなった場合は、省電力状態（電源オフ状態か、ＯＳ休眠状態）のサーバ群をその仕事量に応じて稼動状態とすることにより、多くなった仕事量を分散させる事ができる。
【０１３２】
本実施の形態に係る情報処理システム２に含まれる解析装置１００によると、パケットをネットワークから傍受し、傍受したパケットを始点ＩＰアドレスとポート番号とで分類する。したがって、始点ＩＰアドレスごとおよびポート番号ごとに通信データ量を計測できる。これにより、所望の解析対象のノードについて、どの通信用途（メール通信やＷＥＢ閲覧など）に対応する仕事をどの程度行ったかを、そのノードに直接問い合わせることなしにネットワーク上を流れるパケットから追跡できる。ノードへ問い合わせないので、仕事量の解析に伴うノード側の負担はほとんどない。解析装置１００はネットワークの傍受を行うので、解析装置１００自身の測定への寄与は小さく、また把握できる。
【０１３３】
ＩＰアドレスは仕事の主体を示し、ポート番号は通信用途を示すので、解析装置１００ではそれらを用いてノードで行われている仕事の内訳を導出し、特に有効仕事量を計測できる。この点、現実的に有効仕事量の計測が困難であった従来の技術とは大きく異なる。解析装置１００によると、ノードにおける仕事量を解析することで、そのノードが有効な仕事をどの程度行ったかを計測でき、情報処理システム２を省エネ化するためのよい指標が得られる。
【０１３４】
また、解析装置１００では、通信情報保持部１０４に保持される傍受されたパケットの情報を本来用途と非本来用途とで分類する。したがって、図６の第１指標保持部１０８に示されるように、所望の解析対象のノードについて、本来用途データ量と非本来用途データ量とを得ることができる。これにより、両者の比率などから解析対象のノードがどの程度本来の用途で使用されているかを追跡できる。これは情報処理システム２を省エネ化するためのよい指標のひとつである。例えば、本来の用途で使用されていないノードを発見し、適切な処置を施すことでデータセンタの効率を向上できる。
【０１３５】
また、解析装置１００では、第２指標保持部１１８は、第１指標保持部１０８と使用状況保持部１１２とが対応付けられた形となっている。したがって、情報処理システム２の省エネ化を考える際に、ノードにおける仕事量と使用状況とを対応付けて把握できる。すなわち、ノードが何の仕事をいつどれだけ行ったことにより、どれだけのＣＰＵの処理能力を使用し、どれだけの電力を消費し、どれだけの温度上昇があったかを解析できる。
【０１３６】
例えば、ＣＰＵ使用率が１００％とされているサーバの仕事量の内訳を見ることにより、実際１００％のＣＰＵ使用率のうちどれだけが有効な仕事のために使用されたかを知ることができる。１００％のＣＰＵ使用率でもその大半が有効な仕事のために使用されていなければ、そのサーバは省エネ化のための検討対象とすべきである。ＰＵＥ（Power Usage Effectiveness）（非特許文献１参照）などを使用する従来の技術では、仕事の内訳が見えないのでこのような判断をすることができなかったが、解析装置１００を使用すると可能となる。
【０１３７】
また例えば、消費電力および有効仕事量の両者が共に低いサーバがある場合、使用状況だけを見ていると消費電力が低いので省エネ的によいサーバに見え、このサーバに対しては何ら対策がなされない可能性が高い。しかしながら、解析装置１００を使用して使用状況と仕事量とが対比可能な形で提示される場合、有効仕事量も低いことが分かるので、データセンタの効率を向上してさらなる省エネ化を進めるために、例えば仮想化により他の高負荷サーバから仕事を回す等の対策を取ることができる。したがって、データセンタの省エネ化への寄与は大きい。
【０１３８】
また例えば、有効仕事量的には問題ないが排熱の大きなサーバがある場合にそれを見つけることができる。したがって、そのようなサーバがホットアイルに存在する場合には他の位置に移設したほうがよいことをサーバの持ち主に提案できる。
【０１３９】
また、解析装置１００では、フィルタ部１２６は、フィルタリングモードでは、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスを基に、計測対象のノードのＩＰアドレスが含まれたパケットのみを選択して、登録部１２８に出力する。したがって、計測に影響を与えない範囲で通信情報保持部１０４に保持されるデータの量を低減できる。
【０１４０】
また、フィルタ部１２６は、計測対象のノードを、情報処理システム２に含まれる複数のノードから順番に選択する。つまり、一度に全てのノードを計測対象とするのではなく、例えば月曜日は第１サーバ群１０２２ａ、火曜日は第２サーバ群１０２２ｂ、等のように計測対象のノードを順番に変えてゆく。これにより、計測に影響を与えない範囲で通信情報保持部１０４に保持されるデータの量を低減した上で、ネットワークの全てのノードを計測対象とすることができる。
【０１４１】
仮想化が行なわれているサーバについて考える。従来では主に、親（ホスト）仮想化ＯＳの上での個々のサーバイメージ（個々のゲストＯＳ）のプロセッサ使用率を取得して比較する。そして、ゲストＯＳを他のプロセッサ使用率的に空いている仮想化ホストＯＳサーバへ移設させている。しかしながら、このように単にプロセッサ使用率のみを尺度として仮想化サーバ間のゲストＯＳの移動を行う場合には、実際にゲストＯＳで行われている仕事の内訳までは考慮されていない。したがって、有効仕事量に基づいた移設が行われているとは言い難い。
【０１４２】
解析装置１００を使用して仮想化されたサーバにおける仕事を解析する場合、仮想化のプラットフォームごとに仕事量が分かるので、有効仕事量に基づいた精度の高いゲストＯＳの移設が可能となる。
また、例えば仮想化したことによってどの程度状況が改善されているかを知ることができる。つまり、有効仕事量と消費電力とについて仮想化の前後で比較することで、改善の度合いを知ることができる。また、仮想化後は個々のゲストＯＳが行っている仕事についてはあまり注意されないのが現状であるが、解析装置１００で各ゲストＯＳについて有効仕事量を追跡することにより、例えば時と共に使用されなくなったゲストＯＳを特定できる。したがって、そのように特定されたゲストＯＳを外すことで他のゲストＯＳの性能を改善できる。これはデータセンタの効率の向上に貢献する。
【０１４３】
従来ではシステム運用者は、システムを運用するにあたり、主にサーバのプロセッサ使用率やメモリの利用度を使用してサーバの性能を評価し、その性能評価を軸にして、サーバの統合、アプリケーションの移設、分配、統合、サーバの更新（新しい機器に交換する・買い換える）を行っている。しかしながら、特に昨今の景気低迷期では、サーバのさらなる有効利用やさらなる消費電力の低減によって一段とデータセンタ全体の運用コストを下げることが求められている。
そこで、解析装置１００を使用することにより、サーバにおける仕事が内向け（対サーバ）か、外向け（サーバ発）なのかを詳細に解析でき、また、その仕事がデータセンタ外部への仕事なのかデータセンタ内の他のサーバやアプリケーションに対する仕事なのかも解析できる。したがって、この解析を元にして、省エネ化のための精度の高いサーバ統合、分配、アプリケーション統合、分配、機器の更新、増強、廃止などが行える。
【０１４４】
以上、実施の形態に係る情報処理システム２の構成と動作について説明した。この実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０１４５】
実施の形態では、負荷管理装置１０１０において、ユーザ端末１００６からサーバ群１０２２へのパケットの流れを基に説明したが、サーバ群１０２２からユーザ端末１００６へパケットを返すときも負荷管理装置１０１０が適宜接続保持部１１１６を参照してアドレス変換できることは本明細書に触れた当業者には明らかである。
【０１４６】
実施の形態では、負荷管理装置１０１０は内部ネットワーク３を介して情報処理装置１０２０の各サーバ群１０２２と通信する場合について説明したが、これに限られない。例えば、各サーバ群１０２２と負荷管理装置とが１対１で接続され、結果として負荷管理装置がサーバ群側に５つの入出力ポートを有してもよい。この場合、パケットはアドレス変換ではなく直接個々の入出力ポートに振り分けられてもよい。
【０１４７】
実施の形態では、アクセスしきい値Ｍｏ、第１しきい値Ｔ１、第２しきい値Ｔ２、および第３しきい値Ｔ３が稼動状態のサーバ群の数を決めるしきい値となる場合について説明したが、これに限られない。例えば、それぞれのしきい値にヒステリシスを持たせてもよい。この場合、全アクセス数がしきい値付近で変動しても、しきい値をまたぐ毎にサーバ群１０２２の状態を切り替えなくてもよいので、状態切替に伴うオーバヘッドを低減できる。その結果情報処理システム２全体のレスポンスが向上しうる。
【０１４８】
実施の形態では、サーバ群１０２２の状態制御について、状態設定部１１５０において表１に示されるストラテジが使用される場合について説明したが、これに限られない。例えば、省電力状態としてＯＳ休眠状態を使用し、電源オフ状態を使用しなくてもよい。この場合、電源オンオフにかかる比較的長いオーバヘッドがなくなるので、より早いレスポンスが期待できる。また、処理が簡素化される。別の例としては、省電力状態として電源オフ状態を使用し、ＯＳ休眠状態を使用しなくてもよい。この場合、消費電力をより低減できる。
【０１４９】
実施の形態では、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とデータベースサーバ１０２８とは別個のサーバであり、この順に直列に接続されている場合について説明したが、これに限られない。個々のサーバ群は少なくともひとつのサーバを含めばよく、例えば、サーバ群はフロントエンドサーバとアプリケーションサーバとデータベースサーバの機能を全て併せ持つ１台のサーバを含んでもよい。また、サーバ群は、それら３つのサーバの機能のうちの任意の２つの機能を併せ持つサーバと、残りの機能を持つサーバと、を含んでもよい。
【０１５０】
実施の形態では、負荷予測部１１６０は予測アクセス数を負荷比較部１１５２に渡す場合について説明したが、これに限られない。例えば、負荷予測部１１６０は一年以上前の同月同日の同じ時間帯の稼動サーバ群の数を取得し、その稼動サーバ群の数を稼動サーバ群決定部１１５４に渡してもよい。この場合、稼動サーバ群決定部１１５４はこの稼動サーバ群の数を基に稼動状態にするサーバ群を決定する。
【０１５１】
実施の形態では、要求処理ユニットがサーバ群である場合について説明したが、これに限られない。本実施の形態に係る技術思想は例えばＧＳＬＢ（Global Server Load Balance）にも応用されうる。そこでは、要求処理ユニットはそれ自体が複数の並列に配されたサーバ群を有するシステムであってもよい。また、実施の形態では要求はユーザからのアクセスである場合について説明したが、これに限られず、本実施の形態に係る技術思想が適用されるシステムによって異なってもよい。要求とは処理主体への処理の指示であるとも言える。
【０１５２】
実施の形態では、負荷管理装置１０１０と情報処理装置１０２０とが異なる装置である場合について説明したが、これに限られず、負荷管理装置１０１０と情報処理装置１０２０とが一体となっていてもよい。
【０１５３】
実施の形態では、サーバ群１０２２の平均消費電力、最高消費電力、電力コストのそれぞれとして、そのサーバ群１０２２のフロントエンドサーバ（ＷＥＢサーバ）１０２４の平均消費電力、最高消費電力、電力コストを採用する場合について説明したが、これに限られない。例えば、サーバ群１０２２に含まれる各サーバの電力コストを算出し、それを平均した値をそのサーバ群１０２２の電力コストとして採用してもよい。
【０１５４】
実施の形態では、例えば図１５に示されるように、解析装置１００においてパケットの傍受（Ｓ４０２）からデータの集計（Ｓ４１２）が一連の処理として行われる場合について説明したが、これに限られない。例えば、解析装置は、パケットの傍受からデータの分類までを随時行って分類結果のデータを蓄積し、所定の条件が満たされると分類結果のデータを集計してもよい。ここで所定の条件は、例えば前回の集計から所定の期間が経過したこと、もしくは分類結果のデータの量が所定の量に達したことである。
【０１５５】
図１８は、変形例に係る解析装置における一連の処理を示すフローチャートである。変形例に係る解析装置は、傍受部と、抽出部と、登録部と、通信情報保持部と、分類部と、分類結果保持部と、集計部と、を備える。傍受部は、ネットワークからパケットを傍受する（Ｓ５０２）。抽出部は、傍受されたパケットから始点アドレスとポート番号とを抽出する（Ｓ５０４）。登録部は、抽出された始点アドレスとポート番号とパケットのデータ量とを通信情報保持部に登録する（Ｓ５０６）。分類部は、通信情報保持部に保持されるデータを始点アドレスでソーティングする（Ｓ５０８）。分類部は、ソーティングされたデータを本来用途と非本来用途とに分類する（Ｓ５１０）。分類部は、分類結果を分類結果保持部に登録する（Ｓ５１２）。所定の条件が満たされていない場合（Ｓ５１４のＮ）、ステップＳ５０２に処理が戻る。これにより、所定の条件が満たされるまで分類結果が分類結果保持部に蓄積されてゆく。所定の条件が満たされた場合（Ｓ５１４のＹ）、集計部は、分類結果保持部に蓄積されたデータを集計する（Ｓ５１６）。
本変形例によると、所定の条件を変えることにより、集計の母集団として使用する分類結果データの量を調整できる。したがって、集計の結果得られる指標に対して求められている精度に応じて柔軟に分類結果データの量を調整できる。
【０１５６】
以上、実施の形態にもとづき本発明を説明したが、実施の形態は、本発明の原理、応用を示しているにすぎないことはいうまでもなく、実施の形態には、請求の範囲に規定された本発明の思想を逸脱しない範囲において、多くの変形例や配置の変更が可能であることはいうまでもない。
【符号の説明】
【０１５７】
２ 情報処理システム、 １００ 解析装置、 １０４ 通信情報保持部、 １０８ 第１指標保持部、 １１８ 第２指標保持部、 １５８ 第３指標保持部、 １００４ 外部ネットワーク、 １００６ ユーザ端末、 １０１０ 負荷管理装置、 １０２０ 情報処理装置、 １１１２ 稼動履歴保持部、 １１１４ サーバ群状態保持部、 １１１６ 接続保持部、 １１２０ 要求取得部、 １１３０ 要求割当部、 １１４０ 負荷検出部、 １１５０ 状態設定部、 １１６０ 負荷予測部、 １１８０ 稼動履歴記録部。
【技術分野】
【０００１】
本発明は、情報処理システムおよび情報処理方法に関する。
【背景技術】
【０００２】
地球温暖化と言う問題が、昨今聞かれる。地球温暖化対策の一つとしては電力需要を減らすことがある。電力は一般的に水力発電、太陽光発電、風力発電、地熱発電などの自然由来の発電や、原子力を使う原子力発電や、ガス、石油、石炭などを燃料として燃やし発電を行う火力発電によって供給されている。この中でも特に火力発電は地球温暖化を進める大きな要因となっている。電力需要を減らせば火力発電の発電量も減らすことができるので、その分地球温暖化も抑止されうる。
【０００３】
ＩＴ（Information Technology）やＩＣＴ（Information and Communication Technology）の分野でも、コンピュータやネットワーク機器、データセンタ機器が消費する電力を低減する必要性が指摘され始めている。
【０００４】
近年のインターネットの普及により、多くのデータセンタは、ネットワーク接続型の形態を有しており、インターネットなどの外部のネットワークからの仕事要求を受けて処理を行う。これらのデータセンタのなかには、一度に多くのアクセスを処理するために複数の並列に配置されたサーバを備える構成を採用したものがある（特許文献１参照）。このようなデータセンタは、一般に「ロードバランサ」と呼ばれる負荷分散を行う装置を有する。このロードバランサはネットワーク側の通信機器とサーバとの間に配置され、ネットワークから到来するアクセスを個々のサーバに均等に近い形で分散させている。
また、ネットワーク接続装置の消費電力低減装置が知られている（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−２２５７９３号公報
【特許文献２】特開２００７−９７１２６号公報
【非特許文献】
【０００６】
【非特許文献１】The Green Grid Association、［online］、インターネット＜URL：http://www.thegreengrid.org＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
現行のロードバランサには、それに接続されているサーバに均等にアクセスを分配するものが多い。この場合、各サーバの処理能力や省エネの度合いは無視された形でアクセスが分配されうる。
【０００８】
サーバの特性について、製造年月日や機器の種類やメーカや装備（メモリ、ディスク）や電源ユニットなどの違いにより、処理能力や省エネの度合いはサーバごとに異なる場合が多い。例えば、同じＷＥＢ（World Wide Web）サーバで同じプロセスを走らせた場合でも、メーカが異なればそのプロセスで消費される電力は異なりうる。したがって、現行のロードバランサにおけるアクセスの分配の方法は、省エネ化の観点からは必ずしも最適な方法とは言えない。
【０００９】
本発明はこうした課題に鑑みてなされたものであり、その目的は、複数の要求処理ユニットで並列的に要求を処理する際の消費電力を低減できる情報処理技術の提供にある。
【課題を解決するための手段】
【００１０】
本発明のある態様は情報処理システムに関する。この情報処理システムは、複数の要求処理ユニットがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数の要求処理ユニットのうちの少なくともひとつに、取得された要求を割り当てる負荷管理装置と、ネットワークから得られる情報から、複数の要求処理ユニットの稼動状況が示された指標を算出する解析装置と、を備える。負荷管理装置は、解析装置によって算出された指標に基づいて、複数の要求処理ユニットの状態を制御する。
【００１１】
「要求」とは、例えば情報処理装置に対する処理の要求であってもよい。
【００１２】
この態様によると、解析装置によって算出された指標に基づいて、複数の要求処理ユニットの状態を制御できる。
【００１３】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１４】
本発明によれば、複数の要求処理ユニットで並列的に要求を処理する際の消費電力を低減できる。
【図面の簡単な説明】
【００１５】
【図１】実施の形態に係る情報処理システムを示す概略図である。
【図２】図１におけるアクセスの流れを説明するための説明図である。
【図３】図１の解析装置の機能および構成を示すブロック図である。
【図４】図３の通信情報保持部に保持されるデータの一例を示すデータ構造図である。
【図５】図３のサーバ情報保持部に保持されるデータの一例を示すデータ構造図である。
【図６】図３の第１指標保持部に保持されるデータの一例を示すデータ構造図である。
【図７】図３の使用状況保持部に保持されるデータの一例を示すデータ構造図である。
【図８】図３の係数保持部に保持されるデータの一例を示すデータ構造図である。
【図９】図３の第２指標保持部に保持されるデータの一例を示すデータ構造図である。
【図１０】図３の第３指標保持部に保持されるデータの一例を示すデータ構造図である。
【図１１】図１の負荷管理装置の機能および構成を示すブロック図である。
【図１２】図１１の接続保持部を示すデータ構造図である。
【図１３】図１１のサーバ群状態保持部を示すデータ構造図である。
【図１４】図１１の稼動履歴保持部を示すデータ構造図である。
【図１５】図１の解析装置における一連の処理を示すフローチャートである。
【図１６】図１の負荷管理装置における一連の処理を示すフローチャートである。
【図１７】図１７（ａ）〜（ｄ）は、全アクセス数に対する各サーバ群の稼働率の一例を示すグラフである。
【図１８】変形例に係る解析装置における一連の処理を示すフローチャートである。
【発明を実施するための形態】
【００１６】
以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。
【００１７】
実施の形態に係る情報処理システムは、複数の並列に配置されたサーバ群でユーザからのアクセスを処理する。負荷管理装置はその情報処理システムのゲートウエイとして機能し、外部ネットワークから情報処理システム宛に到来する要求の負荷が少ない場合は不必要なサーバ群のＯＳ（operating system）を休眠させたり、サーバ群の電源自体をオフにする。また、サーバ群の電力特性は使用する機種等により異なる場合があるが、情報処理システムの解析装置が電力特性を計測して負荷管理装置に報告する。負荷管理装置は、その報告を受けて例えば電力効率が悪いサーバ群からＯＳを休眠させたり電源をオフにしたりする。これにより情報処理システムが総合的に省エネ化される。
【００１８】
図１は、実施の形態に係る情報処理システム２を示す概略図である。情報処理システム２は、ネットワーク接続型のデータセンタであり、例えば証券会社のインターネット株取引システムを提供するデータセンタである。情報処理システム２は、解析装置１００と、負荷管理装置１０１０と、情報処理装置１０２０と、を備える。情報処理装置１０２０は、第１サーバ群１０２２ａと、第２サーバ群１０２２ｂと、第３サーバ群１０２２ｃと、第４サーバ群１０２２ｄと、第５サーバ群１０２２ｅと、を含む。第１サーバ群１０２２ａは、第１フロントエンドサーバ１０２４ａと、第１アプリケーションサーバ１０２６ａと、第１データベースサーバ１０２８ａと、を含む。第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃ、第４サーバ群１０２２ｄ、および第５サーバ群１０２２ｅは、それぞれ第１サーバ群１０２２ａと同等の構成を有する。
【００１９】
以下、第１サーバ群１０２２ａ、第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃ、第４サーバ群１０２２ｄ、第５サーバ群１０２２ｅ、はサーバ群１０２２と総称される場合がある。また、第１フロントエンドサーバ１０２４ａ、第２フロントエンドサーバ１０２４ｂ、第３フロントエンドサーバ１０２４ｃ、第４フロントエンドサーバ１０２４ｄ、第５フロントエンドサーバ１０２４ｅ、はフロントエンドサーバ１０２４と総称される場合がある。また、第１アプリケーションサーバ１０２６ａ、第２アプリケーションサーバ１０２６ｂ、第３アプリケーションサーバ１０２６ｃ、第４アプリケーションサーバ１０２６ｄ、第５アプリケーションサーバ１０２６ｅ、はアプリケーションサーバ１０２６と総称される場合がある。また、第１データベースサーバ１０２８ａ、第２データベースサーバ１０２８ｂ、第３データベースサーバ１０２８ｃ、第４データベースサーバ１０２８ｄ、第５データベースサーバ１０２８ｅ、はデータベースサーバと総称される場合がある。
【００２０】
情報処理システム２は、外部ネットワーク１００４と接続され同じく外部ネットワーク１００４に接続されている少なくともひとつのユーザ端末１００６から要求を受ける。ここで要求とは、例えばユーザ端末１００６からのアクセスである。アクセスとは、ユーザ端末１００６と情報処理システム２のひとつのサーバ群１０２２とが接続を確立して一連の情報をやりとりすることである。異なるユーザ端末からのアクセスは異なるアクセスであり、同じユーザ端末１００６からでも異なるアクセスがなされうる。
外部ネットワーク１００４は、例えばＬＡＮ（Local Area Network）・ＷＡＮ（Wide Area Network）・インターネットである。ユーザ端末１００６は、ユーザが使用するコンピュータであり、例えば有線で外部ネットワーク１００４に接続された家庭用デスクトップコンピュータや、無線で外部ネットワーク１００４に接続されたラップトップコンピュータである。
【００２１】
負荷管理装置１０１０は、外部ネットワーク１００４と接続され、また情報処理装置１０２０に含まれる個々のサーバ群１０２２と内部ネットワーク３を介して接続される。負荷管理装置１０１０は、データの流れの観点からは情報処理装置１０２０と外部ネットワーク１００４との間に位置し、外部ネットワーク１００４からの情報処理装置１０２０に対するアクセスを仲介する。
【００２２】
負荷管理装置１０１０は、解析装置１００が算出する情報処理装置１０２０に含まれる複数のサーバ群１０２２の稼動状況が示された指標を以下の３通りで使用する。
１．負荷管理装置１０１０は、外部ネットワーク１００４を介してユーザ端末１００６から情報処理装置１０２０に対するアクセスを取得する。負荷管理装置１０１０は、解析装置１００によって算出された指標に基づいて、情報処理装置１０２０に含まれる複数のサーバ群１０２２のうちアクセスを受付可能な状態（以下、稼動状態と称する）にあるサーバ群に、取得されたユーザからのアクセスを割り当てる。
【００２３】
２．負荷管理装置１０１０は、解析装置１００によって算出された指標に基づいて、複数のサーバ群１０２２の状態を制御する。サーバ群１０２２の状態として、稼動状態と省電力状態とが基本的に規定される。負荷管理装置１０１０は、外部ネットワーク１００４からの負荷を監視する。負荷管理装置１０１０は、負荷が所定の値より少なくなると、解析装置１００によって算出された指標に基づいて、稼動状態にあるサーバ群のうちアクセスの処理に不要なサーバ群を選択し、選択されたサーバ群を稼動状態よりも省電力の省電力状態に設定する。
【００２４】
ここで負荷とは、例えばサーバ群１０２２が行う仕事の量を表す値であり、単位時間当たりのアクセスの数を基に定められる。例えば負荷は、単位時間当たりのアクセスの数と比例関係などの数学的関係を有する値であってもよい。また、負荷は単位時間当たりのアクセスの数に上限値または下限値若しくはその両方を課した値であってもよい。以下では、負荷の一例が、単に単位時間当たりのアクセスの数（以下、アクセス数と称す）である場合について説明する。
なお、負荷が所定の値以上の場合は負荷管理装置１０１０は全てのサーバ群１０２２を稼動状態に設定する。
【００２５】
３．本実施の形態では、負荷管理装置１０１０は、負荷としてアクセス数以外に、ユーザ端末１００６などの外部から負荷管理装置１０１０に送られるパケットおよび負荷管理装置１０１０から外部に送られるパケットの総データ量も利用する。負荷管理装置１０１０は、解析装置１００によって算出されるその総データ量を監視する。
【００２６】
情報処理装置１０２０は、外部ネットワーク１００４からのアクセスを処理する。情報処理装置１０２０は、複数のサーバ群１０２２を含み、そのそれぞれのサーバ群１０２２はアクセスの処理単位である要求処理ユニットとして機能する。
本実施の形態では、ＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）プロトコルにしたがった通信が行われる場合を考える。
【００２７】
サーバ群１０２２はいわゆる３階層のサーバ群であり、これら１セットでアクセスの処理単位を構成する。フロントエンドサーバ１０２４は、ＷＥＢサーバとも呼ばれ、ＨＴＴＰ（HyperText Transfer Protocol）に則り、ユーザ端末１００６のＷＥＢブラウザに対して、ＨＴＭＬ（HyperText Markup Language）や画像などのオブジェクトの表示を提供するサービスが動作するサーバコンピュータである。アプリケーションサーバ１０２６は、フロントエンドサーバ１０２４からジャバサーブレット（Java Servlet、ジャバは登録商標）の処理などのアプリケーションに関する機能を切り出して実現するサーバコンピュータである。データベースサーバ１０２８は、アプリケーションサーバ１０２６のアプリケーションが使用するデータが格納されるサーバコンピュータである。フロントエンドサーバ１０２４、アプリケーションサーバ１０２６、およびデータベースサーバ１０２８は、公知の情報処理技術を使用して実現される。本実施の形態では、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とデータベースサーバ１０２８とは別個のサーバであり、この順に直列に接続されている。
【００２８】
サーバ群１０２２のフロントエンドサーバ１０２４は内部ネットワーク３を介して負荷管理装置１０１０と接続される。
【００２９】
なお、個々のサーバ群１０２２に含まれるサーバは個々にもしくは全体としてＯＳに管理されている。個々のサーバ群の稼動状態は、ユーザからのアクセスを即時処理可能な状態である。この状態は、サーバ群１０２２がユーザからのアクセスを処理しつつ新たなアクセスを処理可能である状態と、ユーザからのアクセスがなく仕事が発生していないアイドル状態と、を含む。稼動状態では、たとえアイドル状態であっても少なくとも基本ＯＳ機能とネットワークモニタリングのタスクは稼動しており、その分電力を消費する。本発明者の当業者としての経験から、このアイドル状態での消費電力は、サーバ機器の種類によってピークアクセス数での稼動時のおよそ３０％から７０％の範囲にある。特に、最新のブレードサーバでは、その高密度な回路構成と狭いスペースに多くの半導体素子が設置されている都合上、アイドル状態でも消費電力は大きくなる。一部のブレードサーバではアイドル状態においてピークアクセス数での稼動時の７０％もの電力を消費しているものも存在する。また、標準的なサーバ機器を用いる場合は６０％程度である。ここでピークアクセス数とは、サーバ群１０２２がその処理速度を落とさずに稼動できるアクセス数の範囲の上限値であり、サーバ群１０２２ごとにその仕様を基に予め定められている。ここで処理速度とは、サーバ群１０２２におけるユーザからのアクセスの処理速度である。
【００３０】
個々のサーバ群１０２２の省電力状態は、ユーザからのアクセスを即時処理できない状態である。この状態は、サーバ群１０２２へ電源は供給されているがそのサーバ群１０２２はユーザからのアクセスを処理できないＯＳ休眠状態を含む。サーバ群１０２２は負荷管理装置１０１０から休眠導入信号を受信するとＯＳ休眠状態となる。このＯＳ休眠状態では、サーバ群１０２２のＯＳは休眠（ハイボネート）しており、ユーザからのアクセスがあってもそれを受け付けない。ＯＳ休眠状態にあるサーバ群１０２２は負荷管理装置１０１０から休眠解除信号を受信すると、稼動状態に復帰する。ＯＳ休眠状態から稼動状態に復帰するためには通常数秒から数十秒かかる。また本発明者の当業者としての経験から、ＯＳ休眠状態におけるサーバ群１０２２の消費電力は、ピークアクセス数での稼働時のおよそ５％から１０％である。
【００３１】
サーバ群１０２２の省電力状態はさらに、サーバ群１０２２への電源が遮断されている電源オフ状態を含む。サーバ群１０２２は負荷管理装置１０１０から電源オフ信号を受信すると電源オフ状態となる。サーバ群１０２２は負荷管理装置１０１０からＷＯＬ（Wake Up on LAN）信号などの電源オン信号を受信すると、稼動状態に復帰する。電源オフ状態から稼動状態に復帰するためには通常数分かかる。
本実施の形態ではサーバ群１０２２が省電力状態から稼動状態に復帰するためにかかる時間（以下、オーバヘッドと称す）と、省電力状態で低減される消費電力とのかねあいで、省電力状態とされるサーバ群の数が決定される。つまり、現在のアクセス数を処理するのに必要なぎりぎりの数のサーバ群だけを稼動状態としていると、突然のアクセス数の増大に対して対処できなくなる可能性がある。一方で稼動状態のサーバ群の数が多いほど待機電力由来の消費電力も大きくなる。そこでそれらの影響が拮抗するように、省電力状態とされるサーバ群の数が決定される。
【００３２】
解析装置１００は、外部ネットワーク１００４、負荷管理装置１０１０、内部ネットワーク３、のそれぞれを通過するパケットを傍受する。また解析装置１００は、各サーバ群１０２２の内部でやりとりされるパケットも傍受する。これは例えば、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とを接続するサブネットや、アプリケーションサーバ１０２６とデータベースサーバ１０２８とを接続するサブネットに解析装置１００が接続されることによって実現される。
「傍受する」ことは、傍受対象のパケットを消滅させることなくその内容を取得することであってもよく、例えばパケットをそれに含まれる終点ＩＰアドレスによらずに取得することであってもよい。
解析装置１００は、傍受したパケットの内容を蓄積し、ＩＰアドレスでソートすることで各ＩＰアドレスに対応するサーバや負荷管理装置１０１０における仕事の内訳を導出する。
【００３３】
解析装置１００は、例えば各サーバに電力を供給するバスバー方式のテーブルタップ型のＰＤＵから、各サーバに供給された電力の計測値を取得し蓄積する。解析装置１００は、蓄積された電力の計測値および上記の仕事の内訳から、サーバ群１０２２の稼働状況が示された指標、例えばサーバ群１０２２における単位有効仕事量あたりの消費電力を算出する。
【００３４】
図２は、図１におけるアクセスの流れを説明するための説明図である。以下、１回のアクセスにおいて、少なくともひとつのパケットがユーザ端末１００６とアクセスが割り当てられたサーバ群との間でやりとりされる場合について説明する。このパケットは、送信元のＩＰアドレスである始点ＩＰアドレスと、受信先のＩＰアドレスである終点ＩＰアドレスと、シーケンス番号と、ポート番号と、タイムスタンプと、を含む。多くの場合において一回のアクセスにつき複数個のパケットがユーザ端末１００６とサーバ群との間を行き来する。図２では第３サーバ群１０２２ｃがアクセスに割り当てられたとする。ユーザ端末１００６のＩＰアドレスを「１７５．３４．１１．２１」、負荷管理装置１０１０のＩＰアドレスを「１００．１０．１０．１０」、第３サーバ群１０２２ｃに含まれる第３フロントエンドサーバ１０２４ｃのＩＰアドレスを「１２１．２１．１５．３」とする。
【００３５】
負荷管理装置１０１０は、ユーザ端末１００６に対して仮想サーバとして働く。つまり、外部ネットワーク１００４では、ユーザが情報処理装置１０２０が有する情報資源にアクセスしようとする場合、かかる情報資源のＵＲＬ（Uniform Resource Locator）が負荷管理装置１０１０のＩＰアドレス「１００．１０．１０．１０」に名前解決されるよう設定されている。
【００３６】
まずユーザは、ユーザ端末１００６のウェブブラウザに対して情報処理装置１０２０が有する情報資源のＵＲＬを指定する。ユーザ端末１００６のウェブブラウザによって始点ＩＰアドレスを「１７５．３４．１１．２１」、終点ＩＰアドレスを「１００．１０．１０．１０」とした第１パケットＰ１が生成され、外部ネットワーク１００４に送られる。負荷管理装置１０１０は第１パケットＰ１を受信し、稼動状態にあるサーバ群のなかから第３サーバ群１０２２ｃを選択してこのアクセスを割り当てる。負荷管理装置１０１０は、第１パケットＰ１の始点ＩＰアドレスはそのままにして終点ＩＰアドレスを「１２１．２１．１５．３」とした第２パケットＰ２を内部ネットワーク３に送出する。第３サーバ群１０２２ｃの第３フロントエンドサーバ１０２４ｃは自己宛の第２パケットＰ２を受信し、第２パケットＰ２のポート番号やそのパケットに搭載されるデータに基づき処理を行う。その処理の結果ユーザ端末１００６へ戻すべき情報は、始点ＩＰアドレスを「１２１．２１．１５．３」、終点ＩＰアドレスを「１７５．３４．１１．２１」とした第３パケットＰ３に含められ、第３フロントエンドサーバ１０２４ｃから内部ネットワーク３に送出される。負荷管理装置１０１０は第３パケットＰ３を受信する。負荷管理装置１０１０は、第３パケットＰ３の終点ＩＰアドレスはそのままにして始点ＩＰアドレスを「１００．１０．１０．１０」とした第４パケットＰ４を外部ネットワーク１００４に送る。ユーザ端末１００６は自己宛の第４パケットＰ４を外部ネットワーク１００４から受信する。
以下、ユーザ端末１００６から負荷管理装置１０１０に送られるパケット（第１パケットＰ１）を総称して行きパケット、負荷管理装置１０１０から情報処理装置１０２０へ送られるパケット（第２パケットＰ２）を総称して割当パケットという。
【００３７】
以下ではまず解析装置１００について説明し、次いで負荷管理装置１０１０について説明する。
【００３８】
（解析装置１００）
図３は、解析装置１００の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【００３９】
解析装置１００は、ネットワークインタフェース部１０２と、通信情報保持部１０４と、分類部１３２と、集計部１３０と、第１指標保持部１０８と、係数保持部１１４と、第１解析部１１６と、使用状況取得部１１０と、使用状況保持部１１２と、第２指標保持部１１８と、第２解析部１５２と、第３指標保持部１５８と、指標送信部１５４と、表示制御部１２０と、を備える。
【００４０】
ネットワークインタフェース部１０２は、傍受部１２２と、抽出部１２４と、フィルタ部１２６と、登録部１２８と、を含む。
傍受部１２２は、外部ネットワーク１００４と内部ネットワーク３とからパケットを傍受する。内部ネットワーク３は、各サーバ群１０２２のサーバを相互接続するサブネットを含む。抽出部１２４は、傍受部１２２によって傍受されたパケットから始点ＩＰアドレスと終点ＩＰアドレスとポート番号とを抽出する。
【００４１】
以下、負荷管理装置１０１０またはサーバ群１０２２またはサーバ群１０２２のサーバをノードと呼ぶ場合がある。
フィルタ部１２６は、フィルタ機能がオンとされるフィルタリングモードでは、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスを基に、計測対象のノードのＩＰアドレスが含まれたパケットのみを選択して、登録部１２８に出力する。より具体的にはフィルタ部１２６は、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスのうちの少なくとも一方が計測対象のノードのＩＰアドレスと一致する場合にのみ、抽出元のパケットを登録部１２８に出力する。
【００４２】
特にフィルタ部１２６は、計測対象のノードを、情報処理システム２に含まれる複数のノードから順番に選択する。すなわち、フィルタ部１２６は、計測対象のノードのＩＰアドレスを、情報処理システム２に含まれる複数のノードのＩＰアドレスのなかで順番に切り替える。
フィルタ部１２６は、フィルタ機能がオフとされるフィルタリングオフモードでは、抽出部１２４によって始点ＩＰアドレスと終点ＩＰアドレスとポート番号とが抽出されたパケットを登録部１２８に出力する。
【００４３】
登録部１２８は、フィルタ部１２６によって出力されたパケットについて、そのパケットに関する時刻と、抽出部１２４によってそのパケットから抽出された始点ＩＰアドレスと、抽出部１２４によってそのパケットから抽出された終点ＩＰアドレスと、抽出部１２４によってそのパケットから抽出されたポート番号に対応する通信用途と、そのパケットのデータ量と、を対応付けて通信情報保持部１０４に登録する。
【００４４】
図４は、通信情報保持部１０４に保持されるデータの一例を示すデータ構造図である。通信情報保持部１０４は、時刻２０２と、始点ＩＰアドレス２０４と、終点ＩＰアドレス２０６と、通信用途２０８と、データ量２１０と、を対応付けて保持する。
時刻２０２は、パケットに関する時刻であり、例えばパケットにタイムスタンプが含まれているのであればそのタイムスタンプで示される時刻である。あるいはまた、傍受部１２２によってパケットが傍受された時刻であってもよい。
始点ＩＰアドレス２０４および終点ＩＰアドレス２０６はそれぞれ、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスである。
通信用途２０８は、抽出部１２４によって抽出されたポート番号に対応する通信用途である。
データ量２１０は、パケットに搭載されているデータの量をバイト（Ｂ）単位で示す。
【００４５】
図３に戻る。分類部１３２は、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスのうちの少なくともひとつとポート番号とによってパケットを分類する。以下では分類部１３２が始点ＩＰアドレスとポート番号とによってパケットを分類する場合について説明する。しかしながら、分類部が終点ＩＰアドレスとポート番号とによってパケットを分類する場合、および分類部が始点および終点ＩＰアドレスとポート番号とによってパケットを分類する場合でも以下と同様の説明が成り立つことは、本明細書に触れた当業者には明らかである。
【００４６】
分類部１３２は、通信情報保持部１０４に保持されるデータを始点ＩＰアドレスについてソーティングする。以下、通信情報保持部１０４に登録されている始点ＩＰアドレスを登録ＩＰアドレスと称す。分類部１３２は、各登録ＩＰアドレスについて通信用途によってパケットを分類する。特に分類部１３２は、サーバ情報保持部１３８を参照し、登録ＩＰアドレスに対応するノード（以下、登録ノードと称す）に対して予め定められた通信用途である本来用途に関する情報を取得する。分類部１３２は、その本来用途に対応したパケットと、本来用途以外の通信用途である非本来用途に対応したパケットとに分類する。本来用途は、例えば登録ノードがＷＥＢサーバであれば、ポート番号「８０」に対応するＷＥＢ通信である。非本来用途は、例えば本来用途以外の通信用途であり、登録ノードがＷＥＢサーバであればポート番号「２０」に対応するＦＴＰ転送などである。
【００４７】
図５は、サーバ情報保持部１３８に保持されるデータの一例を示すデータ構造図である。サーバ情報保持部１３８は、ノードのノード名２１４と、ノードのＩＰアドレス２１８と、ノードの用途２２４と、を対応付けて保持する。
分類部１３２は、サーバ情報保持部１３８を参照してあるノードの本来用途に関する情報を取得する際、そのノードの用途を参照して本来用途を取得してもよい。
【００４８】
図３に戻る。集計部１３０は、少なくともひとつの登録ノードについて、本来用途に対応したパケットを集計する。特に集計部１３０は、所定の長さの期間すなわち時間帯ごとに、登録ノードの本来用途に対応したパケットのデータ量を集計し、また非本来用途に対応したパケットのデータ量を集計する。
例えば、登録ＩＰアドレス「121.21.15.1」に対応する登録ノードについて、時間帯「02/15/10 11:10:00~11:20:00」で集計する場合について考える。図５のサーバ情報保持部１３８から登録ノードは第１フロントエンドサーバ１０２４ａでありＷＥＢサーバである。集計部１３０は、分類部１３２における分類結果から、始点ＩＰアドレスが「121.21.15.1」であり、通信用途が「ＷＥＢ通信」であり、時刻が時間帯「02/15/10 11:10:00~11:20:00」に含まれるパケットのデータ量を足し合わせて、本来用途に対する集計結果を得る。また、集計部１３０は、始点ＩＰアドレスが「121.21.15.1」であり、通信用途が「ＷＥＢ通信」ではなく、時刻が時間帯「02/15/10 11:10:00~11:20:00」に含まれるパケットのデータ量を足し合わせて、非本来用途に対する集計結果を得る。
【００４９】
なお、集計部１３０は、負荷管理装置１０１０については、外部から負荷管理装置１０１０に送られるパケットおよび負荷管理装置１０１０から外部に送られるパケットの総データ量（以下、単に総データ量と称す）を集計する。特に集計部１３０は、時間帯ごとに、情報処理システム２の外部のＩＰアドレスを始点ＩＰアドレスとし負荷管理装置１０１０のＩＰアドレスを終点ＩＰアドレスとするパケットのデータ量を集計し、負荷管理装置１０１０のＩＰアドレスを始点ＩＰアドレスとし情報処理システム２の外部のＩＰアドレスを終点ＩＰアドレスとするパケットのデータ量を集計し、それぞれの集計結果を足し合わせて総データ量を得る。
集計部１３０は、集計結果を第１指標保持部１０８に登録する。
【００５０】
図６は、第１指標保持部１０８に保持されるデータの一例を示すデータ構造図である。第１指標保持部１０８は、登録ノードのノード名２２８と、登録ノードの本来用途２３０と、本来用途に対応するポート番号である主なポート番号２３２と、本来用途データ量２３４と、非本来用途データ量２３６と、集計部１３０で使用される所定の長さの期間すなわち時間帯に対応する計測期間２３８と、を対応付けて保持する。
本来用途データ量２３４は、登録ノードの本来用途に対応したパケットのデータ量を計測期間内で足し合わせた結果のデータ量である。
非本来用途データ量２３６は、登録ノードの非本来用途に対応したパケットのデータ量を計測期間内で足し合わせた結果のデータ量である。
なお、負荷管理装置１０１０については本来用途データ量として総データ量が保持されることは上述の通りである。
【００５１】
図３に戻る。使用状況取得部１１０は、内部ネットワーク３を通じて所定の時間間隔もしくはリアルタイムで、情報処理システム２のノードから、そのノードの使用状況に関する情報を取得する。ノードの使用状況は、例えばノードがフロントエンドサーバ（ＷＥＢサーバ）１０２４やアプリケーションサーバ１０２６であれば消費電力（単位はＷ）や機器の温度（単位は℃）やＣＰＵ使用率（単位は％）であり、ノードがデータベースサーバ１０２８であればデータ転送量（単位はＭＢ／秒）や消費電力や機器の温度であり、ノードが負荷管理装置１０１０などのネットワーク機器であればデータ転送量や消費電力や機器の温度である。
【００５２】
使用状況取得部１１０は、サーバの基本ＯＳに搭載されているシステムパフォーマンスモニタのデータを取得してもよい。
使用状況取得部１１０は、各ノードに電力を供給するバスバー方式のテーブルタップ型のＰＤＵから各ノードに供給された電力の計測値を消費電力として取得してもよい。
使用状況取得部１１０は、ノードの温度を計測できる市販の装置（温度センサや、光ファイバ方式の温度センサ）と、その温度データを記憶して報告するデータ収集機能（市販されているソフトウエアパッケージ、またはサーバ組み込み型の特殊ハードウエアパッケージ）と、を利用して機器の温度を取得してもよい。
【００５３】
あるいはまた、使用状況取得部１１０は、米国ＥＰＡのEnergy Star for Server 2で登録し認定されるノードからは、下記の３つの報告機能を使用して消費電力と機器の温度とＣＰＵ使用率とを取得する。すなわち、米国のＥＰＡが行っているEnergy Star for Server 2では、登録し認定される機器は、３つの報告機能をハードウエア本体のマイクロコード（ファームウエア）のレベルで提供でき、基本ＯＳや他の計測ソフト、アプリケーションや本来のサーバの処理能力（本体のＣＰＵ・ＭＰＵ（Micro Processing Unit））には、影響を与えないハードウエアの管理機能を持つこととされている。この３つの報告機能は、１）サーバの実電力消費数値、２）サーバの本体ＣＰＵ・ＭＰＵ等の処理用プロセッサの使用率、３）サーバの実稼動の温度、である。
【００５４】
使用状況取得部１１０は、取得した使用状況に関する情報と、それを取得した時刻に対応する時間帯と、取得先のノード名と、ＩＰアドレスと、を対応付けて使用状況保持部１１２に登録する。使用状況取得部１１０が所定の時間間隔で情報を取得する場合は、時間帯は例えば取得した時刻から所定の時間間隔が経過するまでの期間に設定される。あるいはまた、使用状況取得部１１０がリアルタイムで情報を取得する場合は、所定の長さを有する期間を時間帯とし、使用状況に関する情報をその期間で時間平均する。
【００５５】
図７は、使用状況保持部１１２に保持されるデータの一例を示すデータ構造図である。使用状況保持部１１２は、使用状況取得部１１０によって使用状況が取得されたノードのノード名２４４と、ＩＰアドレス２４５と、使用状況が取得された時刻に対応する記録時間帯２４６と、取得された消費電力２４８と、取得された機器温度２５０と、取得されたＣＰＵ使用率２５２と、取得されたデータ転送量２５３と、を対応付けて保持する。
【００５６】
一般的に、ＷＥＢサーバにおいて、所定の量、例えば１ｋＢのＷＥＢ通信用のデータを処理して送るにはどれだけのＣＰＵ使用率が必要かは測定できる。つまり、ＷＥＢサーバについて、ＷＥＢ通信用のデータ量とＣＰＵ使用率との関係は事前に測定できる。係数保持部１１４（図８で後述）はその関係を示す係数（例えば、％・分／ＧＢの単位）を保持する。この係数が１である場合、例えば１ＧＢ分のＷＥＢ通信用のデータを処理して送るためにＷＥＢサーバは１％のＣＵＰ使用率で１分間稼動しなければならないことを意味する。
【００５７】
図８は、係数保持部１１４に保持されるデータの一例を示すデータ構造図である。係数保持部１１４は、ＷＥＢサーバのサーバ名２４０と、係数２４２と、を対応付けて保持する。
【００５８】
図３に戻る。第１解析部１１６は、第１算出部１３４と、第２算出部１３６と、第１合成部１４２と、を含む。
第１算出部１３４は、第１指標保持部１０８に登録される登録ノードのうちＷＥＢサーバ（以下、登録ＷＥＢサーバと称す）について、本来用途データ量すなわちＷＥＢ通信用のデータ量を対応する計測期間の長さ、例えば分を単位とする長さ、で除し、ＷＥＢ通信用の時間平均データ量（例えば、ＧＢ／分の単位）を得る。第１算出部１３４は、係数保持部１１４からその登録ＷＥＢサーバに対応する係数を取得する。第１算出部１３４は、その登録ＷＥＢサーバについて、ＷＥＢ通信用の時間平均データ量と係数とを乗算し、乗算の結果得られる値（例えば、％の単位）を、その登録ＷＥＢサーバおよび計測期間における、ＷＥＢ通信に関する処理によるＣＰＵ使用率の推測値（以下、第１推測値と称す）とする。
【００５９】
例えば、図６の第１指標保持部１０８に登録されるノード名「第１フロントエンドサーバ」に着目すると、第１算出部１３４は、計測期間「02/15/10 11:10:00~11:20:00」におけるＷＥＢ通信用のデータ量として「５００（ＧＢ）」を得る。第１算出部１３４は、「５００（ＧＢ）」を計測期間の長さ「１０（分）」で除し、ＷＥＢ通信用の時間平均データ量「５０（ＧＢ／分）」を得る。第１算出部１３４は、図８の係数保持部１１４を参照し、係数「１．５（％・分／ＧＢ）」を得る。第１算出部１３４は、ＷＥＢ通信用の時間平均データ量「５０（ＧＢ／分）」と係数「１．５（％・分／ＧＢ）」とを乗算し「７５（％）」を得る。第１算出部１３４は、この値「７５（％）」をノード名「第１フロントエンドサーバ」のＷＥＢサーバにおける計測期間「02/15/10 11:10:00~11:20:00」中のＷＥＢ通信に関する処理による第１推測値とする。
【００６０】
第２算出部１３６は、第１算出部１３４における第１推測値の計算で対象とされた登録ＷＥＢサーバのサーバ名と計測期間とをキーとして使用状況保持部１１２を検索し、対応する消費電力と機器温度とＣＰＵ使用率とを抽出する。第２算出部１３６は、第１推測値を使用状況保持部１１２から抽出したＣＰＵ使用率から減じ、ＷＥＢ通信に関する処理以外の処理によるＣＰＵ使用率の推測値（以下、第２推測値と称す）とする。
ＷＥＢ通信に関する処理以外の処理は、例えば他の通信に関する処理や、ウイルスチェッカーによるウイルススキャンや、ハードディスクドライブへのデータの書き込みである。あるいはまた、アイドル状態にあってなにも仕事をしていないことも考えられる。
【００６１】
第２算出部１３６は、抽出された消費電力を第１推測値と第２推測値との比に分け、第１推測値に対応する値をＷＥＢ通信に関する処理のために使用された電力の推測値、第２推測値に対応する値をそうでない処理のために使用された電力の推測値とする。機器温度についても、機器温度と外気温との差を第１推測値と第２推測値との比に分ける点で同様である。
【００６２】
例えば、図６の第１指標保持部１０８に登録されるノード名「第１フロントエンドサーバ」に着目すると、第２算出部１３６は図７に示される使用状況保持部１１２から、ノード名「第１フロントエンドサーバ」と計測期間「02/15/10 11:10:00~11:20:00」とに対応する消費電力「３０（Ｗ）」、機器温度「３５（℃）」、ＣＰＵ使用率「８０（％）」を抽出する。第２算出部１３６は、第１推測値「７５（％）」をＣＰＵ使用率「８０（％）」から減じ、第２推測値「５（％）」を得る。第２算出部１３６は、消費電力「３０（Ｗ）」を第１推測値「７５（％）」と第２推測値「５（％）」との比すなわち１５：１に分け、ＷＥＢ通信に関する処理のために使用された電力の推測値「２８（Ｗ）」とそれ以外の処理のために使用された電力の推測値「２（Ｗ）」と、を得る。
【００６３】
第１合成部１４２は、時刻およびノード名をキーとして、第１指標保持部１０８に保持されるデータと、使用状況保持部１１２に保持されるデータと、第２算出部１３６による計算結果（登録ＷＥＢサーバについての、ＷＥＢ通信処理由来の消費電力、ＷＥＢ通信処理由来の上昇温度、ＷＥＢ通信処理由来のＣＰＵ使用率）と、を対応付けて第２指標保持部１１８に登録する。
【００６４】
図９は、第２指標保持部１１８に保持されるデータの一例を示すデータ構造図である。第２指標保持部１１８は、ノード名２５４と、本来用途２５６と、主なポート番号２５８と、本来用途データ量２６０と、非本来用途データ量２６２と、計測期間２６４と、消費電力２６６と、機器温度２６８と、ＣＰＵ使用率２７０と、データ転送量２７１と、ＷＥＢ通信由来消費電力２７２と、ＷＥＢ通信由来上昇温度２７４と、ＷＥＢ通信由来ＣＰＵ使用率２７６と、を対応付けて保持する。
ＷＥＢ通信由来消費電力２７２は、第２算出部１３６によって算出された、ＷＥＢ通信に関する処理のために使用された電力の推測値である。ＷＥＢ通信由来上昇温度２７４は、第２算出部１３６によって算出された、機器温度と外気温との差のうちＷＥＢ通信に関する処理によって上昇したと予測される分である。ここでは外気温は２５（℃）とされている。ＷＥＢ通信由来ＣＰＵ使用率２７６は、第１算出部１３４によって算出された第１推測値である。
【００６５】
図３に戻る。第２解析部１５２は、第２指標保持部１１８に保持されるデータのうちＷＥＢサーバ（フロントエンドサーバ１０２４）に関するデータを、使用状況取得部１１０における所定の時間間隔よりも長い時間間隔、例えば１ヶ月や半年の時間間隔で統計処理する。
第２解析部１５２は、第２指標保持部１１８に登録されているノードのうちＷＥＢサーバについて、消費電力の時間平均である平均消費電力と、統計処理対象の期間内における消費電力の最高値である最高消費電力と、を算出する。
第２解析部１５２は、第２指標保持部１１８に登録されているノードのうちＷＥＢサーバについて、ＷＥＢ通信由来の消費電力の時間平均を本来用途データ量（ＷＥＢ通信用のデータ量）の時間平均で除した値（例えば、Ｗ／ＧＢの単位）を算出する。ここで算出される値は、ＷＥＢ通信用の単位データ量に対する消費電力を表す電力コストである。例えばこの電力コストが１（Ｗ／ＧＢ）であることは、ＷＥＢサーバにおいて１ＧＢ分のＷＥＢ通信用のデータを処理するのに１Ｗ消費することを示す。ＷＥＢ通信用のデータ量をＷＥＢサーバに対する負荷と考えると、電力コストは、各ＷＥＢサーバにおいて同じ負荷（単位データ量）がかけられた場合にそのＷＥＢサーバで消費される電力を示す。
第２解析部１５２は、サーバ名と、平均消費電力と、最高消費電力と、電力コストと、を対応付けて第３指標保持部１５８に登録する。
【００６６】
図１０は、第３指標保持部１５８に保持されるデータの一例を示すデータ構造図である。第３指標保持部１５８は、サーバ名３０４と、平均消費電力３０６と、最高消費電力３０８と、電力コスト３１０と、を対応付けて保持する。
【００６７】
図３に戻る。表示制御部１２０は、第１指標保持部１０８、第２指標保持部１１８、第３指標保持部１５８のうちの少なくともひとつに基づき、ノードごとに各種パラメータを示す画面をモニタ１４０に表示させる。
【００６８】
指標送信部１５４は、第３指標保持部１５８に登録されているデータを負荷管理装置１０１０に送信する。
【００６９】
上述の解析装置１００において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
【００７０】
（負荷管理装置１０１０）
図１１は、負荷管理装置１０１０の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【００７１】
負荷管理装置１０１０は、稼動履歴保持部１１１２と、サーバ群状態保持部１１１４と、接続保持部１１１６と、要求取得部１１２０と、要求割当部１１３０と、負荷検出部１１４０と、状態設定部１１５０と、負荷予測部１１６０と、稼動履歴記録部１１８０と、を備える。
【００７２】
稼動履歴保持部１１１２は、情報処理装置１０２０の過去の稼動履歴を保持する。サーバ群状態保持部１１１４は、現在のサーバ群１０２２の状態を保持する。稼動履歴保持部１１１２およびサーバ群状態保持部１１１４の詳細は後述する。
【００７３】
接続保持部１１１６は、同一アクセス内のパケットは同じサーバ群１０２２へ送られること（以下、アクセスの同一性と称す）を保証するために設けられる。
図１２は、接続保持部１１１６を示すデータ構造図である。接続保持部１１１６には、後述する接続更新部１１３８によってアクセスに対応するエントリが生成される。一回のアクセスに対してひとつのエントリが対応する。接続保持部１１１６のエントリ１１１８は、アクセスしてきたユーザ端末１００６のＩＰアドレスであるユーザ端末ＩＰアドレス１２１０と、負荷管理装置１０１０のＩＰアドレスである負荷管理装置ＩＰアドレス１２１２と、負荷管理装置１０１０によってそのアクセスに割り当てられたサーバ群１０２２のフロントエンドサーバ１０２４のＩＰアドレスである割当サーバ群ＩＰアドレス１２１４と、ユーザ端末１００６が同一の場合にアクセスの異同を判別するためのシーケンス番号１２１６と、を有する。同一ユーザ端末１００６において、異なるアクセスには異なるシーケンス番号が割り振られる。以下、サーバ群１０２２のフロントエンドサーバ１０２４のＩＰアドレスを単にサーバ群１０２２のＩＰアドレスと称す。
【００７４】
図１１に戻る。要求取得部１１２０は、外部ネットワーク１００４と接続される。要求取得部１１２０は、外部ネットワーク１００４から到来するユーザ端末１００６からのアクセスの行きパケットを取得する。この際、要求取得部１１２０は行きパケットに含まれる終点ＩＰアドレスを基に自己宛のパケットであるか否かを判別する。要求取得部１１２０は、取得した行きパケットを要求割当部１１３０に渡す。
【００７５】
なお、本明細書において「渡す」とは、ある機能ブロックからある機能ブロックに情報要素に対する処理が移ることを意味する。要求取得部１１２０と要求割当部１１３０との間で言うと、渡すとは、例えば要求取得部１１２０が図示しない一時メモリを有し、取得した行きパケットをそこに蓄えた上で、要求割当部１１３０からの要請に応じて適宜行きパケットを一時メモリから要求割当部１１３０に伝達することである。また渡すとは、負荷管理装置１０１０が図示しない記憶領域を有し、要求取得部１１２０は取得した行きパケットをその記憶領域に書き込み、要求割当部１１３０は適宜その記憶領域から必要な行きパケットを読み出して処理することであってもよい。
【００７６】
要求割当部１１３０は、ユーザ端末１００６からのアクセスの行きパケットを稼動状態にあるサーバ群のうちのひとつに割り当てる。特に傾斜配分モードでは、ユーザ端末１００６からのアクセスが新規のアクセスである場合、要求割当部１１３０は解析装置１００から取得する指標に基づいて、その新規のアクセスをサーバ群のうちのひとつに割り当てる。要求割当部１１３０は、同一接続判断部１１３２と、サーバ群選択部１１３４と、アドレス変換部１１３６と、接続更新部１１３８と、を含む。
【００７７】
同一接続判断部１１３２は、要求取得部１１２０から行きパケットを取得し、その行きパケットが新規のアクセスによるものか否かを判別する。同一接続判断部１１３２は、取得した行きパケットの始点ＩＰアドレスとシーケンス番号とを読み取る。同一接続判断部１１３２は、読み取られた始点ＩＰアドレスとシーケンス番号とをキーとして接続保持部１１１６のエントリを検索し、それらと一致するエントリが存在する場合、そのエントリに含まれる割り当てられたサーバ群の割当サーバ群ＩＰアドレスを取得する。同一接続判断部１１３２は、この取得された割当サーバ群ＩＰアドレスと行きパケットとをアドレス変換部１１３６に渡す。
【００７８】
なお、このように一致するエントリが存在する場合は、当該行きパケットは既にあるサーバ群１０２２（エントリの割当サーバ群ＩＰアドレスで指定されるサーバ群１０２２）に割り当てられたアクセスのなかのひとつのパケットである。アドレス変換部１１３６は、渡された行きパケットの終点ＩＰアドレスを、同一接続判断部１１３２によって接続保持部１１１６から取得された割当サーバ群ＩＰアドレスに変換する。このように終点ＩＰアドレスが変換された行きパケットはアドレス変換部１１３６から割当パケットとして内部ネットワーク３に送出される。
【００７９】
一致するエントリが存在しない場合は、同一接続判断部１１３２は当該行きパケットをサーバ群選択部１１３４に渡す。この場合は同一接続判断部１１３２は新規のアクセスを検知したと言うことができる。
【００８０】
サーバ群選択部１１３４は、同一接続判断部１１３２から新規のアクセスに対応する行きパケットを受け取ると、サーバ群状態保持部１１１４を参照してそのアクセスを処理させるサーバ群１０２２を選択する。
【００８１】
図１３は、サーバ群状態保持部１１１４を示すデータ構造図である。サーバ群状態保持部１１１４は、サーバ群１０２２のＩＰアドレス１２０２と、サーバ群１０２２の状態１２０４と、サーバ群１０２２の稼働率１２０６と、を対応付けて保持する。サーバ群１０２２の稼働率１２０６は、サーバ群１０２２のピークアクセス数に対する現在そのサーバ群１０２２が処理しているアクセス数の割合を％単位で示す。この稼働率は、図示されない稼働率更新部によって、予め定められているサーバ群１０２２のピークアクセス数と、接続保持部１１１６から分かるサーバ群１０２２に現在割り当てられているアクセス数とから演算され更新されてもよい。あるいは、図示されない稼働率更新部が稼動状態にあるサーバ群１０２２から稼働率を取得し、サーバ群状態保持部１１１４の稼働率を更新してもよい。
【００８２】
図１１に戻る。サーバ群選択部１１３４は、サーバ群状態保持部１１１４に登録されたサーバ群のなかからサーバ群の状態を参照して稼動状態にあるサーバ群を抽出する。要求割当部１１３０が省電力モードに設定されているか通常モードに設定されているか傾斜配分モードに設定されているかによって、サーバ群選択部１１３４が稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択するアルゴリズムは異なる。以下それぞれの場合について説明する。
【００８３】
１．省電力モード
省電力モードでは、サーバ群選択部１１３４は、稼動状態にあるサーバ群の稼働率が１００％となるように、稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択する。例えば図１３の例では、サーバ群選択部１１３４は新規のアクセスを処理させるサーバ群として第３サーバ群１０２２ｃを選択する。また、例えば第１サーバ群１０２２ａ、第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃが稼動状態に設定されており、第１サーバ群１０２２ａの稼働率が１００％、第２サーバ群１０２２ｂの稼働率が８０％、第３サーバ群１０２２ｃの稼働率が０％の場合、サーバ群選択部１１３４は新規のアクセスを処理させるサーバ群として第２サーバ群１０２２ｂを選択する。
【００８４】
２．通常モード
通常モードでは、サーバ群選択部１１３４は、予め情報処理システム２の管理者によって設定されている負荷分散アルゴリズムにしたがって、新規のアクセスを処理させるのに最適なサーバ群を選択する。ここで使用される負荷分散アルゴリズムは、順番にサーバ群１０２２が選択されるラウンドロビン方式や、処理しているアクセス数が最小のサーバ群を選択する最小接続方式や、１番早く応答しているサーバ群を選択する最速方式などの公知のアルゴリズムである。
【００８５】
３．傾斜配分モード
傾斜配分モードでは、サーバ群選択部１１３４は、解析装置１００の指標送信部１５４から第３指標保持部１５８に保持されるデータを受信する。サーバ群選択部１１３４は受信したデータから、稼動状態にあるサーバ群のフロントエンドサーバの電力コストをそのサーバ群の電力コストとして抽出する。サーバ群選択部１１３４は、稼動状態にあるサーバ群から、新規のアクセスを処理させるサーバ群として電力コストが小さいサーバ群を優先的に選択する。
【００８６】
サーバ群選択部１１３４は、選択されたサーバ群のＩＰアドレスと新規のアクセスに対応する行きパケットとをアドレス変換部１１３６に渡す。アドレス変換部１１３６は、渡された行きパケットの終点ＩＰアドレスを、サーバ群選択部１１３４によって選択されたサーバ群のＩＰアドレスに変換する。このように終点ＩＰアドレスが変換された行きパケットはアドレス変換部１１３６から割当パケットとして内部ネットワーク３に送出される。
【００８７】
接続更新部１１３８は、サーバ群選択部１１３４で新規のアクセスに対してサーバ群１０２２の選択が行われる毎に、その選択に関する情報をサーバ群選択部１１３４から取得し、接続保持部１１１６に対応するエントリを追加する。この選択に関する情報は、新規のアクセスを行ったユーザのユーザ端末１００６のユーザ端末ＩＰアドレスと、負荷管理装置ＩＰアドレスと、新規のアクセスに対して選択されたサーバ群の割当サーバ群ＩＰアドレスと、シーケンス番号と、を含む。
また、接続更新部１１３８は、適宜不要となったエントリを削除する。
【００８８】
負荷検出部１１４０は、要求取得部１１２０によって取得されたアクセスのアクセス数を周期的に検出する。負荷検出部１１４０は、接続保持部１１１６を参照してエントリの数をカウントすることで、所定の時間間隔で情報処理装置１０２０全体へのアクセス数（以下、全アクセス数と称す）を取得する。また負荷検出部１１４０は、要求取得部１１２０と要求割当部１１３０との間の行きパケットの流れを監視し、所定の時間間隔でアクセスの数をカウントし、そのカウント数から単位時間当たりのアクセスの数、つまりアクセス数を導出してもよい。なお、負荷検出部１１４０は要求取得部１１２０の前段や要求割当部１１３０の後段など、負荷管理装置１０１０の任意の箇所で負荷を監視してもよい。負荷検出部１１４０は、検出した全アクセス数を状態設定部１１５０の負荷比較部１１５２に渡す。
【００８９】
負荷検出部１１４０における上述の時間間隔は負荷管理装置１０１０のモードを更新する基準となる時間間隔であり、アクセス数の変動率に基づいて定められる。負荷検出部１１４０は図示しない時間間隔設定部を有し、時間間隔設定部はアクセス数の変動率を監視し、変動率が大きいほど時間間隔を短く設定する。これにより、より適応的なサーバ群状態の制御が可能となる。また、処理を簡素化するという観点からは時間間隔は情報処理システム２の管理者によって予め定められてもよい。
【００９０】
状態設定部１１５０は、全アクセス数が所定のアクセスしきい値Ｍｏより少ない場合もしくは解析装置１００から得られる総データ量が所定のデータ量しきい値Ｄｏより少ない場合、情報処理装置１０２０に含まれる少なくともひとつのサーバ群１０２２を省電力状態に設定する。
【００９１】
状態設定部１１５０におけるアクセスしきい値Ｍｏまたはデータ量しきい値Ｄｏは、情報処理装置１０２０の性能が落ちない範囲に設定される。ここで性能とは、例えばどれだけのアクセス数をどの程度の速さで処理できるかということである。あるいは性能とは、ひとつのアクセスが処理されるのにかかる時間などのレスポンスタイムであってもよい。また、情報処理装置１０２０の性能が落ちる、とは、例えばあるサーバ群１０２２に対してピークアクセス数を越える数のアクセスが割り当てられ、その結果そのサーバ群１０２２の処理速度が落ちることにより情報処理装置１０２０全体のアクセスの処理速度が落ちることである。
【００９２】
例えば第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする。この場合アクセスしきい値Ｍｏを９０００に設定すると、全アクセス数が８５００であっても少なくともひとつのサーバ群１０２２を省電力状態に設定しなくてはならない。ここでは第５サーバ群１０２２ｅを省電力状態に設定したとする。残りの４つのサーバ群１０２２ａ〜１０２２ｄのトータルのピークアクセス数は８０００であり、全アクセス数９５００よりも少ない。したがってこの場合残りの４つのサーバ群１０２２ａ〜１０２２ｄのうちの少なくともひとつのサーバ群はピークアクセス数以上のアクセスを処理しなくてはならずそのサーバ群の処理速度は低下する。これにより情報処理装置１０２０全体の処理速度が落ちることとなる。このような状況を避けるために、アクセスしきい値Ｍｏまたはデータ量しきい値Ｄｏは情報処理装置１０２０の性能が落ちない範囲に設定される。上述の例ではアクセスしきい値Ｍｏは８０００以下に設定されればよい。
【００９３】
状態設定部１１５０は、サーバ群１０２２の最大性能を発揮せしめる前提で、要求取得部１１２０によって取得されたアクセスを処理させるサーバ群を選択し、残りのサーバ群を省電力状態に設定する。この場合サーバ群１０２２の最大性能を発揮せしめる、とは、例えばサーバ群１０２２にピークアクセス数でアクセス処理を行わせることであり、言い換えるとサーバ群１０２２を１００％の稼働率で使用することである。さらに状態設定部１１５０は、全アクセス数または総データ量の変動により情報処理装置１０２０の性能が落ちると予測される場合には、省電力状態に設定されている少なくともひとつのサーバ群を稼動状態に設定する。
【００９４】
サーバ群１０２２を省電力状態または稼動状態に設定することに関して、状態設定部１１５０では、稼動状態にするサーバ群の数に応じた全アクセス数の範囲または総データ量の範囲が定められている。状態設定部１１５０は例えば全アクセス数が０から第１しきい値Ｔ１の範囲にあればひとつのサーバ群のみを稼動状態とし、他のサーバ群を省電力状態とする。表１は、状態設定部１１５０における状態設定に関して、稼動状態とするサーバ群の数と、ＯＳ休眠状態とするサーバ群の数と、電源オフ状態とするサーバ群の数と、全アクセス数の範囲と、の関係を示す。Ｔ２は第２しきい値、Ｔ３は第３しきい値であり、Ｔ１＜Ｔ２＜Ｔ３である。個々のしきい値は予め情報処理システム２の管理者によって設定される。
【表１】
【００９５】
第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３はそれぞれサーバ群１０２２を１００％の稼働率で使用することを前提に設定される。つまり上述の第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする例では、Ｔ１＝２０００、Ｔ２＝４０００、Ｔ３＝６０００である。この場合、全アクセス数のアクセスを処理するのに必要最低限の数のサーバ群が稼動状態とされる。また、例えば第１しきい値Ｔ１と第２しきい値Ｔ２との間にあった全アクセス数が増大して第２しきい値Ｔ２を越えた場合、そのままだと少なくともひとつのサーバ群の稼働率が１００％を上回ると予測されるので、稼動状態とするサーバ群の数をひとつ増やして情報処理装置１０２０の処理速度の低下を回避する。
【００９６】
状態設定部１１５０は、負荷比較部１１５２と、稼動サーバ群決定部１１５４と、状態信号生成部１１５６と、を含む。
負荷比較部１１５２は、全アクセス数を使用するアクセス数モードと、総データ量を使用するデータ量モードと、を有する。
負荷比較部１１５２は、全アクセス数モードでは、負荷検出部１１４０から取得した全アクセス数と、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３、アクセスしきい値Ｍｏとの大小関係を判別する。この大小関係は例えば「Ｔ２＜全アクセス数＜Ｔ３」という情報である。負荷比較部１１５２はこの大小関係に関する情報を稼動サーバ群決定部１１５４に渡す。
負荷比較部１１５２は、総データ量モードでは、解析装置１００から第１指標保持部１０８に保持される総データ量を取得する。負荷比較部１１５２は、取得した総データ量について上記の全アクセス数の場合と同様に大小関係を判別し、判別された大小関係に関する情報を稼動サーバ群決定部１１５４に渡す。
【００９７】
稼動サーバ群決定部１１５４は、負荷比較部１１５２から渡された情報が全アクセス数についての大小関係に関する情報であれば、その情報を基に表１のストラテジにしたがい、サーバ群１０２２の状態の切替の必要性を判別する。稼動サーバ群決定部１１５４は、負荷比較部１１５２から渡された情報が総データ量についての大小関係に関する情報であれば、その情報を基に表１と同様のストラテジにしたがい、サーバ群１０２２の状態の切替の必要性を判別する。
稼動サーバ群決定部１１５４は、サーバ群１０２２の状態の切替が必要な場合には、解析装置１００から取得する指標に基づいて、稼動状態とするサーバ群とＯＳ休眠状態とするサーバ群と電源オフ状態とするサーバ群を選択する。
稼動サーバ群決定部１１５４はこの選択に基づきサーバ群状態保持部１１１４を更新する。稼動サーバ群決定部１１５４は、状態の切り替えが必要なサーバ群１０２２の情報を状態信号生成部１１５６に渡す。稼動サーバ群決定部１１５４は、状態の切り替えが必要ない場合には処理を中断または終了し、次の情報を待ち受ける。
【００９８】
稼動サーバ群決定部１１５４は、全アクセス数についての表１のストラテジまたは総データ量についての同様のストラテジから稼動状態、ＯＳ休眠状態および電源オフ状態とするサーバ群の数をまず決める。次に稼動サーバ群決定部１１５４はサーバ群状態保持部１１１４を参照し、サーバ群１０２２の状態を切り替える必要があるか、言い換えると負荷検出部１１４０が取得した全アクセス数または解析装置１００から取得した総データ量に対応する各状態のサーバ群の数とサーバ群状態保持部１１１４に登録されている現在の各状態のサーバ群の数とが一致するか否かを判断する。そこで一致する場合は稼動サーバ群決定部１１５４は処理を中断または終了する。
【００９９】
一致しない場合は、稼動サーバ群決定部１１５４はそれぞれの状態にするサーバ群を決める。稼動サーバ群決定部１１５４は、解析装置１００の指標送信部１５４から第３指標保持部１５８に保持されるデータを受信する。稼動サーバ群決定部１１５４は、受信したデータを基に各サーバ群１０２２に対して省電力状態とされる順番を示す省エネ停止可能順位を設定する。省エネ停止可能順位は「１」が最も高く、数が増えるにつれて低くなる順位である。
稼動サーバ群決定部１１５４では、第３指標保持部１５８に保持されるフロントエンドサーバ１０２４の平均消費電力、最高消費電力、電力コストを、そのフロントエンドサーバ１０２４が属するサーバ群１０２２の平均消費電力、最高消費電力、電力コストのそれぞれとみなす。
【０１００】
表２は、サーバ群１０２２の電力コストに基づき省エネ停止可能順位を定める場合の、サーバ群名と平均消費電力と最高消費電力と電力コストと省エネ停止可能順位との関係を示す。
【表２】
表２のストラテジでは、サーバ群１０２２の電力コストが大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定される。電力コストが遜色ない２つのサーバ群が存在する場合は、平均消費電力や最高消費電力が高いほうのサーバ群の省エネ停止可能順位をより高く設定する（表２の第４サーバ群と第５サーバ群）。
【０１０１】
表３は、サーバ群１０２２の消費電力に基づき省エネ停止可能順位を定める場合の、サーバ群名と平均消費電力と最高消費電力と電力コストと省エネ停止可能順位との関係を示す。
【表３】
表３のストラテジでは、サーバ群１０２２の平均消費電力と最高消費電力との和が大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定される。
情報処理装置１０２０において各サーバ群１０２２が主にＷＥＢ通信をおこなっており他の用途の処理は無視できる程度であり、また要求割当部１１３０において稼動状態にあるサーバ群にアクセスが均等に割り当てられる設定となっている場合は、稼動状態にあるサーバ群には同じ負荷がかけられれていると考えることができる。したがって、稼動状態にある各サーバ群の平均消費電力は、同じ負荷がかけられれている場合に消費される電力の平均値と同一視することができ、また、稼動状態にある各サーバ群の最高消費電力は、同じ負荷がかけられれている場合に消費される電力の最高値と同一視することができる。この場合、表３のストラテジでは、サーバ群１０２２に同じ負荷がかけられた場合に消費される電力が大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定されているといえる。
【０１０２】
稼動サーバ群決定部１１５４は、稼動状態にあるサーバ群のひとつを省電力状態に切り替える必要がある場合、稼動状態にあるサーバ群のうち表２または表３で設定される省エネ停止可能順位が最も高いサーバ群を省電力状態とすべきサーバ群として選択する。
稼動サーバ群決定部１１５４は、省電力状態にあるサーバ群のひとつを稼動状態に切り替える必要がある場合、省電力状態にあるサーバ群のうち表２または表３で設定される省エネ停止可能順位が最も低いサーバ群を稼動状態とすべきサーバ群として選択する。
【０１０３】
なお、稼動サーバ群決定部１１５４でのサーバ群１０２２を決める上述のアルゴリズムでは、特に稼動状態を省電力状態に切り替える場合は、アクセスの同一性が考慮されてもよい。つまり、稼動サーバ群決定部１１５４は、接続保持部１１１６を参照し、省電力状態に切り替えるべきサーバ群へのアクセスがなくなるまで待機する。稼動サーバ群決定部１１５４はそのようなアクセスがなくなると、省電力状態に切り替えるべきサーバ群の情報を状態信号生成部１１５６に渡す。これによりアクセスの同一性が保証されうる。
【０１０４】
状態信号生成部１１５６は、状態の切り替えが必要なサーバ群の情報に基づきそのサーバ群に対して切替に対応する休眠導入信号、休眠解除信号、電源オフ信号、および電源オン信号のうちのいずれかを送る。例えば第３サーバ群１０２２ｃを稼動状態（ＯＳ休眠状態）からＯＳ休眠状態（稼動状態）とする必要がある場合、状態信号生成部１１５６は第３サーバ群１０２２ｃに対して休眠導入信号（休眠解除信号）を内部ネットワーク３を介して送出する。また、第３サーバ群１０２２ｃを稼動状態（電源オフ状態）から電源オフ状態（稼動状態）とする必要がある場合、状態信号生成部１１５６は第３サーバ群１０２２ｃに対して電源オフ信号（電源オン信号）を内部ネットワーク３を介して送出する。
状態信号生成部１１５６によって省電力状態から稼動状態に設定されたサーバ群は、それが稼動状態であることが稼動サーバ群決定部１１５４によってサーバ群状態保持部１１１４に記録されるので、要求割当部１１３０によって新規のアクセスが割り当てられる。
【０１０５】
負荷管理装置１０１０は、負荷検出部１１４０で検出された全アクセス数または解析装置１００から取得する総データ量を基に状態設定部１１５０でサーバ群１０２２の状態を適応的に設定する検出モードの他に、過去の稼動履歴を基に予測されたアクセス数（以下、予測アクセス数と称す）を基に状態設定部１１５０でサーバ群１０２２の状態を設定する負荷予測モードを有する。以下、この負荷予測モードについて説明する。
【０１０６】
稼動履歴記録部１１８０は、定期的に情報処理装置１０２０に含まれるサーバ群１０２２ａ〜２２ｅの稼動履歴を稼動履歴保持部１１１２に記録する。稼動履歴記録部１１８０は、例えば１５分に１度サーバ群状態保持部１１１４を参照してその時点での各サーバ群１０２２の状態と稼働率とを取得する。また稼動履歴記録部１１８０はその時点で負荷検出部１１４０によって検出された全アクセス数を取得する。稼動履歴記録部１１８０はそれらの情報を稼動履歴保持部１１１２に書き込む。
図１４は、稼動履歴保持部１１１２を示すデータ構造図である。稼動履歴保持部１１１２は、日時１２１８と、アクセス数１２２０と、稼動サーバ群の数１２２２と、平均稼働率１２２４と、を対応付けて保持する。日時１２１８は、暦の上での日時である。稼動サーバ群の数１２２２は、その日時に稼動状態にあったサーバ群の数である。平均稼働率１２２４は、稼動状態にあったサーバ群の稼働率の平均値である。
【０１０７】
図１１に戻る。負荷予測部１１６０は、過去の稼動履歴を基に負荷を予測する。負荷予測部１１６０は、稼動履歴保持部１１１２を参照し、予測対象の時間帯に対して一年以上前の同月同日の同じ時間帯の稼動履歴を取得し、これを基に予測対象の時間帯の予測アクセス数を決定する。例えば、負荷予測部１１６０が２００９年７月２８日の９：１５〜９：３０におけるアクセス数を予測する場合、負荷予測部１１６０は２００８年７月２８日の９：１５〜９：３０におけるアクセス数（図１４の場合、５４００）を稼動履歴保持部１１１２から取得し、それを予測アクセス数とする。この予測アクセス数の取得は、負荷検出部１１４０における時間間隔と同様の時間間隔で行われる。
【０１０８】
負荷予測部１１６０は予測アクセス数を負荷比較部１１５２に渡す。状態設定部１１５０は、負荷予測部１１６０から予測アクセス数が負荷比較部１１５２に渡された場合、この予測アクセス数を全アクセス数と読み替えて上述した処理を行う。
【０１０９】
上述の負荷管理装置１０１０において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
【０１１０】
以上の構成による情報処理システム２の動作を説明する。図１５は、解析装置１００における一連の処理を示すフローチャートである。傍受部１２２は、ネットワークからパケットを傍受する（Ｓ４０２）。抽出部１２４は、傍受されたパケットから始点アドレスとポート番号とを抽出する（Ｓ４０４）。登録部１２８は、抽出された始点アドレスとポート番号とパケットのデータ量とを通信情報保持部１０４に登録する（Ｓ４０６）。分類部１３２は、通信情報保持部１０４に保持されるデータを始点アドレスでソーティングする（Ｓ４０８）。分類部１３２は、ソーティングされたデータを本来用途と非本来用途とに分類する（Ｓ４１０）。集計部１３０は、分類されたデータを集計する（Ｓ４１２）。第２解析部１５２は、集計結果から各サーバ群１０２２の電力コストを算出する（Ｓ４１４）。
【０１１１】
図１６は、負荷管理装置１０１０における一連の処理を示すフローチャートである。図１６では、要求取得部１１２０と、負荷検出部１１４０と、状態設定部１１５０とで行われる処理についてのフローチャートを示すが、それと平行して要求割当部１１３０がサーバ群状態保持部１１１４を参照して新規のアクセスのサーバ群１０２２への割り当てを行っていることは上述の通りである。また、負荷比較部１１５２ではアクセス数モードが使用される場合を考える。
【０１１２】
要求取得部１１２０は、外部ネットワーク１００４からアクセスを取得する（Ｓ７０２）。負荷検出部１１４０は、全アクセス数を検出する（Ｓ７０４）。状態設定部１１５０は、全アクセス数とアクセスしきい値Ｍｏ、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３との大小比較を行う（Ｓ７０６）。状態設定部１１５０は、その大小比較を基にサーバ群１０２２の状態の切替が必要か否かを判断する（Ｓ７０８）。状態の切替が必要でない場合（Ｓ７０８のＮ）、処理をアクセス取得ステップＳ７０２に戻す。状態の切替が必要な場合（Ｓ７０８のＹ）、状態設定部１１５０は稼動状態のサーバ群の数を増やすか減らすかを判断する（Ｓ７１０）。減らす必要がある場合（Ｓ７１０の減らす）、状態設定部１１５０は、省エネ停止可能順位が最も高い稼動状態のサーバ群を省電力状態に設定する（Ｓ７１２）。増やす必要がある場合（Ｓ７１０の増やす）、状態設定部１１５０は省エネ停止可能順位が最も低い省電力状態のサーバ群を稼動状態に設定する（Ｓ７１４）。負荷管理装置１０１０はこの処理を所定の時間間隔で繰り返す。
【０１１３】
本実施の形態に係る情報処理システム２によると、負荷管理装置１０１０は全アクセス数または総データ量に応じて適応的に稼動状態とするサーバ群を選択し、残りのサーバ群を省電力状態に設定する。ユーザからのアクセスは稼動状態にあるサーバ群のうちのひとつのサーバ群に割り当てられ、そこで処理される。現時点でのアクセス数を処理するのに不必要なサーバ群は省電力状態とされる。したがって、省電力状態としたサーバ群の待機電力分だけ情報処理システム２全体の消費電力を低減できる。また、アクセス数の増大により情報処理システム２の処理能力を増やす必要が出てくると、負荷管理装置１０１０は稼動状態とするサーバ群の数を増やす。
これに加えて、解析装置１００はネットワークを傍受して各サーバ群１０２２の特性の違いを示す指標を算出し、負荷管理装置１０１０は解析装置１００によって算出されたこの指標に基づいて、複数のサーバ群１０２２の状態を制御する。したがって、各サーバ群１０２２の特性の違い合わせてサーバ群１０２２の状態が制御できるので、情報処理システム２の省エネ化を一層進めることができる。
【０１１４】
また、本実施の形態では、負荷管理装置１０１０は解析装置１００によって計測された総データ量がデータ量しきい値Ｄｏより少ない場合、情報処理装置１０２０に含まれるサーバ群１０２２のうちの少なくともひとつのサーバ群を省電力状態に設定する。したがって、負荷管理装置１０１０自身が負荷検出機能を有しない場合でも、解析装置１００から負荷を取得できる。
【０１１５】
また、本実施の形態では、稼動サーバ群決定部１１５４は負荷が所定の値より少ない場合、解析装置１００によって算出された指標に基づいて、稼動状態に設定されている複数のサーバ群のうちアクセスを処理する必要のない少なくともひとつのサーバ群を選択する。状態信号生成部１１５６は、稼動サーバ群決定部１１５４によって選択された少なくともひとつのサーバ群を省電力状態に設定する。
したがって、解析装置１００による各サーバ群１０２２の特性の違いの解析結果を取り入れた形で、稼動状態にあるサーバ群のなかから省電力状態とするサーバ群を選択できる。これにより、全てのサーバ群１０２２を特性上同等と見なした上で省電力状態とするサーバ群を選択する場合と比べて、選択に各サーバ群１０２２の特性の違いを反映できるので、省エネの観点からより好適なサーバ群１０２２の状態制御が可能となる。
【０１１６】
また、稼動サーバ群決定部１１５４は、電力コストが大きいサーバ群を省電力状態とするサーバ群として優先的に選択する。したがって、結果として稼動状態とされるサーバ群の電力コストは、省電力状態とされるサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１１７】
また、本実施の形態では、負荷管理装置１０１０は、解析装置１００によって算出された指標に基づいて、取得されたアクセスを複数のサーバ群１０２２のうちの少なくともひとつに割り当てる。したがって、解析装置１００による各サーバ群１０２２の特性の違いの解析結果を取り入れた形で、アクセスを分配できる。これにより、全てのサーバ群１０２２を特性上同等と見なした上でアクセスを割り当てる場合と比べて、割り当てに各サーバ群１０２２の特性の違いを反映できるので、省エネの観点からより好適な負荷分散が可能となる。
【０１１８】
また、負荷管理装置１０１０は、取得されたアクセスを、電力コストが小さいサーバ群に優先的に割り当てる。したがって、結果としてアクセスがより多く割り当てられるサーバ群の電力コストは、そうでないサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１１９】
また、本実施の形態では、稼動サーバ群決定部１１５４は、負荷が所定の値より多くなると予測される場合には、解析装置１００によって算出された指標に基づいて、省電力状態に設定されている複数のサーバ群のうちの少なくともひとつのサーバ群を選択する。状態信号生成部１１５６は、稼動サーバ群決定部１１５４によって選択された少なくともひとつのサーバ群を稼動状態に設定する。
したがって、解析装置１００による各サーバ群１０２２の特性の違いの解析結果を取り入れた形で、省電力状態にあるサーバ群のなかから稼動状態とするサーバ群を選択できる。これにより、全てのサーバ群を特性上同等と見なした上で稼動状態とするサーバ群を選択する場合と比べて、選択に各サーバ群１０２２の特性の違いを反映できるので、省エネの観点からより好適なサーバ群１０２２の状態制御が可能となる。
【０１２０】
また、稼動サーバ群決定部１１５４は、電力コストが小さいサーバ群を稼動状態とするサーバ群として優先的に選択する。したがって、結果として稼動状態とされるサーバ群の電力コストは、省電力状態とされるサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１２１】
図１７（ａ）〜図１７（ｄ）は、全アクセス数に対する各サーバ群１０２２の稼働率の一例を示すグラフである。ここでは、第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする。また、稼動サーバ群決定部１１５４では表２のストラテジが使用され、サーバ群選択部１１３４では傾斜配分モードが使用される場合を考える。
図１７（ａ）〜図１７（ｄ）はそれぞれ全アクセス数が１６００、２８００、４４００、７０００の場合に対応する。図１７（ａ）〜図１７（ｄ）において「△」はＯＳ休眠状態を示し、「×」は電源オフ状態を示す。
【０１２２】
図１７（ａ）では、第１サーバ群１０２２ａのみが稼動状態とされ、第４サーバ群１０２２ｄはＯＳ休眠状態とされ、第３サーバ群１０２２ｃと、第４サーバ群１０２２ｄと、第５サーバ群１０２２ｅと、は電源オフ状態とされる。図１７（ｂ）では、第５サーバ群１０２２ｅはＯＳ休眠状態とされ、第２サーバ群１０２２ｂと、第３サーバ群１０２２ｃと、は電源オフ状態とされる。図１７（ｃ）では、第３サーバ群１０２２ｃはＯＳ休眠状態とされ、第２サーバ群１０２２ｂは電源オフ状態とされる。図１７（ｄ）では、第２サーバ群１０２２ｂはＯＳ休眠状態とされる。
【０１２３】
本実施の形態に係る情報処理システム２の負荷管理装置１０１０によると、負荷に応じて情報処理装置１０２０に含まれるサーバ群１０２２が省電力状態に設定される。上述した通り稼動状態のサーバ群の消費電力は、アイドル状態であってもピーク時のおよそ６０％である。これに対して省電力状態のサーバ群の消費電力はピーク時のおよそ０〜１０％である。したがって、本実施の形態では、負荷分散を実現しつつ、負荷が少なくアクセスを処理する必要のないサーバ群がある場合はそれらのサーバ群をアイドル状態ではなく省電力状態としている。これにより、情報処理装置１０２０全体の消費電力を低減でき、電力の無駄遣いを抑え、省エネ化を図ることができる。
【０１２４】
また、稼動サーバ群決定部１１５４は接続保持部１１１６を参照してアクセスの同一性を保証し、サーバ群選択部１１３４はサーバ群状態保持部１１１４を参照して現在稼動状態にあるサーバ群を判別している。このように本実施の形態では状態切替機能と負荷分散機能とがひとつの負荷管理装置１０１０で実現されているので、アクセスの同一性が必要な場合はそれをより容易に保証でき、また省電力状態にあるサーバ群に誤ってパケットを送信してしまう可能性を低減できる。
【０１２５】
本実施の形態に係る負荷管理装置１０１０では、全アクセス数＜アクセスしきい値Ｍｏとなる場合、表１に示される通りＯＳ休眠状態とするサーバ群と電源オフ状態とするサーバ群との両方を設けている。これにより、突然の全アクセス数の増大に対しては、復帰のためのオーバヘッドが小さいＯＳ休眠状態にあるサーバ群を稼動状態に戻すことで対応できる。また、そのように対応できる限りにおいては他のサーバ群は電力を消費しない電源オフ状態とし、情報処理装置１０２０全体の消費電力をさらに低減している。なお、表１ではＯＳ休眠状態とするサーバ群をひとつだけ確保しているが、この数はオーバヘッドと消費電力とのかねあいで定められればよく、適宜増減可能であることは本明細書に触れた当業者には理解される。
【０１２６】
本実施の形態に係る負荷管理装置１０１０では、状態設定部１１５０はサーバ群１０２２の最大性能を発揮せしめる前提で稼動状態とするサーバ群を決定する。このサーバ群１０２２の決定方式によると、所与の負荷に対してより多くの数のサーバ群１０２２を省電力状態とすることができる。したがって、情報処理装置１０２０全体の消費電力をより低減できる。なお、稼働率によってサーバ群１０２２の消費電力が異なるのも事実ではあるが、上述の通りアイドル状態でもピーク時のおよそ６０％の電力が消費されることを考えると、稼働率を下げることによる電力削減効果よりもアイドル状態を省電力状態とすることによる電力削減効果のほうが大きいと考えられる。
【０１２７】
また、アクセスしきい値Ｍｏは情報処理装置１０２０の性能が落ちない範囲に設定される。これにより、負荷が多い場合は通常モードで情報処理装置１０２０の並列処理能力をいかんなく発揮させ、負荷が少なくなると省電力モードに移行させて性能を保ちつつ電力消費量を低減できる。
【０１２８】
また、状態設定部１１５０は負荷の変動により情報処理装置１０２０の性能が落ちると予測される場合には、省電力状態にあるサーバ群を稼動状態に設定する。これにより、サーバ群１０２２をピークアクセス数以上で使用しなければならない状況を回避し、アクセス処理の遅滞を避けることができる。
【０１２９】
また、負荷予測部１１６０は過去の稼動履歴を基にアクセス数を予測し、状態設定部１１５０はその予測値に基づいてサーバ群１０２２の状態を設定する。つまり負荷管理装置１０１０は、情報処理システム２の運用の実態を日時、曜日、祭日等のカレンダー区分にて、外部ネットワーク１００４側から発生するアクセス数の傾向情報を過去にさかのぼり蓄積し、その情報を元に運用に該当する日時に予測されるアクセス数を算出する学習機能と、その運用時間帯特異のアクセス数の予測を元に必要な稼動状態サーバ群の数を推測し、必要台数のサーバ群を稼動状態にする機能と、を有する。
【０１３０】
これらの機能は特に情報処理システム２がネットワーク接続型のデータセンタである場合に有益である。これは以下の本発明者の当業者としての知見に基づく。
日々の運用では、ネットワーク接続型のデータセンタの運用では、運用されているアプリケーションシステムにより、稼働率やアクセス数の傾向が把握できる。これは、例えば、インターネット検索を主としているアプリケーションサーバ群では、平日より休日の利用が多く、平日でも、午前より午後、夕方から夜までの利用が多いと言える。また、証券取引所接続の証券会社のインターネット株取引システムでは、証券取引所の運用時間帯に多くの取引による仕事量があり、取引所が取引を閉じている夕方から朝、土日と祝祭日には仕事量は少ない。取引所が閉まっている時間帯では、証券会社の顧客は主に個々の口座の情報を参照するなどのアクセスを行うので取引時間帯より仕事量は低い。
【０１３１】
これらの日々の運用実績のデータを基に、特定の運用日の特定の時間帯に予測される外部ネットワーク１００４よりの仕事量が予測出来ることに本発明者は想到した。証券会社の取引システムのサーバ群は、取引所の運用の時間外は、負荷管理装置１０１０により運用に必要なサーバ群の数を予測し、不必要なサーバ群の電源を切るとかＯＳを休眠させることで消費電力を低減できる。仮に、この予測に反して仕事量が多くなった場合は、省電力状態（電源オフ状態か、ＯＳ休眠状態）のサーバ群をその仕事量に応じて稼動状態とすることにより、多くなった仕事量を分散させる事ができる。
【０１３２】
本実施の形態に係る情報処理システム２に含まれる解析装置１００によると、パケットをネットワークから傍受し、傍受したパケットを始点ＩＰアドレスとポート番号とで分類する。したがって、始点ＩＰアドレスごとおよびポート番号ごとに通信データ量を計測できる。これにより、所望の解析対象のノードについて、どの通信用途（メール通信やＷＥＢ閲覧など）に対応する仕事をどの程度行ったかを、そのノードに直接問い合わせることなしにネットワーク上を流れるパケットから追跡できる。ノードへ問い合わせないので、仕事量の解析に伴うノード側の負担はほとんどない。解析装置１００はネットワークの傍受を行うので、解析装置１００自身の測定への寄与は小さく、また把握できる。
【０１３３】
ＩＰアドレスは仕事の主体を示し、ポート番号は通信用途を示すので、解析装置１００ではそれらを用いてノードで行われている仕事の内訳を導出し、特に有効仕事量を計測できる。この点、現実的に有効仕事量の計測が困難であった従来の技術とは大きく異なる。解析装置１００によると、ノードにおける仕事量を解析することで、そのノードが有効な仕事をどの程度行ったかを計測でき、情報処理システム２を省エネ化するためのよい指標が得られる。
【０１３４】
また、解析装置１００では、通信情報保持部１０４に保持される傍受されたパケットの情報を本来用途と非本来用途とで分類する。したがって、図６の第１指標保持部１０８に示されるように、所望の解析対象のノードについて、本来用途データ量と非本来用途データ量とを得ることができる。これにより、両者の比率などから解析対象のノードがどの程度本来の用途で使用されているかを追跡できる。これは情報処理システム２を省エネ化するためのよい指標のひとつである。例えば、本来の用途で使用されていないノードを発見し、適切な処置を施すことでデータセンタの効率を向上できる。
【０１３５】
また、解析装置１００では、第２指標保持部１１８は、第１指標保持部１０８と使用状況保持部１１２とが対応付けられた形となっている。したがって、情報処理システム２の省エネ化を考える際に、ノードにおける仕事量と使用状況とを対応付けて把握できる。すなわち、ノードが何の仕事をいつどれだけ行ったことにより、どれだけのＣＰＵの処理能力を使用し、どれだけの電力を消費し、どれだけの温度上昇があったかを解析できる。
【０１３６】
例えば、ＣＰＵ使用率が１００％とされているサーバの仕事量の内訳を見ることにより、実際１００％のＣＰＵ使用率のうちどれだけが有効な仕事のために使用されたかを知ることができる。１００％のＣＰＵ使用率でもその大半が有効な仕事のために使用されていなければ、そのサーバは省エネ化のための検討対象とすべきである。ＰＵＥ（Power Usage Effectiveness）（非特許文献１参照）などを使用する従来の技術では、仕事の内訳が見えないのでこのような判断をすることができなかったが、解析装置１００を使用すると可能となる。
【０１３７】
また例えば、消費電力および有効仕事量の両者が共に低いサーバがある場合、使用状況だけを見ていると消費電力が低いので省エネ的によいサーバに見え、このサーバに対しては何ら対策がなされない可能性が高い。しかしながら、解析装置１００を使用して使用状況と仕事量とが対比可能な形で提示される場合、有効仕事量も低いことが分かるので、データセンタの効率を向上してさらなる省エネ化を進めるために、例えば仮想化により他の高負荷サーバから仕事を回す等の対策を取ることができる。したがって、データセンタの省エネ化への寄与は大きい。
【０１３８】
また例えば、有効仕事量的には問題ないが排熱の大きなサーバがある場合にそれを見つけることができる。したがって、そのようなサーバがホットアイルに存在する場合には他の位置に移設したほうがよいことをサーバの持ち主に提案できる。
【０１３９】
また、解析装置１００では、フィルタ部１２６は、フィルタリングモードでは、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスを基に、計測対象のノードのＩＰアドレスが含まれたパケットのみを選択して、登録部１２８に出力する。したがって、計測に影響を与えない範囲で通信情報保持部１０４に保持されるデータの量を低減できる。
【０１４０】
また、フィルタ部１２６は、計測対象のノードを、情報処理システム２に含まれる複数のノードから順番に選択する。つまり、一度に全てのノードを計測対象とするのではなく、例えば月曜日は第１サーバ群１０２２ａ、火曜日は第２サーバ群１０２２ｂ、等のように計測対象のノードを順番に変えてゆく。これにより、計測に影響を与えない範囲で通信情報保持部１０４に保持されるデータの量を低減した上で、ネットワークの全てのノードを計測対象とすることができる。
【０１４１】
仮想化が行なわれているサーバについて考える。従来では主に、親（ホスト）仮想化ＯＳの上での個々のサーバイメージ（個々のゲストＯＳ）のプロセッサ使用率を取得して比較する。そして、ゲストＯＳを他のプロセッサ使用率的に空いている仮想化ホストＯＳサーバへ移設させている。しかしながら、このように単にプロセッサ使用率のみを尺度として仮想化サーバ間のゲストＯＳの移動を行う場合には、実際にゲストＯＳで行われている仕事の内訳までは考慮されていない。したがって、有効仕事量に基づいた移設が行われているとは言い難い。
【０１４２】
解析装置１００を使用して仮想化されたサーバにおける仕事を解析する場合、仮想化のプラットフォームごとに仕事量が分かるので、有効仕事量に基づいた精度の高いゲストＯＳの移設が可能となる。
また、例えば仮想化したことによってどの程度状況が改善されているかを知ることができる。つまり、有効仕事量と消費電力とについて仮想化の前後で比較することで、改善の度合いを知ることができる。また、仮想化後は個々のゲストＯＳが行っている仕事についてはあまり注意されないのが現状であるが、解析装置１００で各ゲストＯＳについて有効仕事量を追跡することにより、例えば時と共に使用されなくなったゲストＯＳを特定できる。したがって、そのように特定されたゲストＯＳを外すことで他のゲストＯＳの性能を改善できる。これはデータセンタの効率の向上に貢献する。
【０１４３】
従来ではシステム運用者は、システムを運用するにあたり、主にサーバのプロセッサ使用率やメモリの利用度を使用してサーバの性能を評価し、その性能評価を軸にして、サーバの統合、アプリケーションの移設、分配、統合、サーバの更新（新しい機器に交換する・買い換える）を行っている。しかしながら、特に昨今の景気低迷期では、サーバのさらなる有効利用やさらなる消費電力の低減によって一段とデータセンタ全体の運用コストを下げることが求められている。
そこで、解析装置１００を使用することにより、サーバにおける仕事が内向け（対サーバ）か、外向け（サーバ発）なのかを詳細に解析でき、また、その仕事がデータセンタ外部への仕事なのかデータセンタ内の他のサーバやアプリケーションに対する仕事なのかも解析できる。したがって、この解析を元にして、省エネ化のための精度の高いサーバ統合、分配、アプリケーション統合、分配、機器の更新、増強、廃止などが行える。
【０１４４】
以上、実施の形態に係る情報処理システム２の構成と動作について説明した。この実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０１４５】
実施の形態では、負荷管理装置１０１０において、ユーザ端末１００６からサーバ群１０２２へのパケットの流れを基に説明したが、サーバ群１０２２からユーザ端末１００６へパケットを返すときも負荷管理装置１０１０が適宜接続保持部１１１６を参照してアドレス変換できることは本明細書に触れた当業者には明らかである。
【０１４６】
実施の形態では、負荷管理装置１０１０は内部ネットワーク３を介して情報処理装置１０２０の各サーバ群１０２２と通信する場合について説明したが、これに限られない。例えば、各サーバ群１０２２と負荷管理装置とが１対１で接続され、結果として負荷管理装置がサーバ群側に５つの入出力ポートを有してもよい。この場合、パケットはアドレス変換ではなく直接個々の入出力ポートに振り分けられてもよい。
【０１４７】
実施の形態では、アクセスしきい値Ｍｏ、第１しきい値Ｔ１、第２しきい値Ｔ２、および第３しきい値Ｔ３が稼動状態のサーバ群の数を決めるしきい値となる場合について説明したが、これに限られない。例えば、それぞれのしきい値にヒステリシスを持たせてもよい。この場合、全アクセス数がしきい値付近で変動しても、しきい値をまたぐ毎にサーバ群１０２２の状態を切り替えなくてもよいので、状態切替に伴うオーバヘッドを低減できる。その結果情報処理システム２全体のレスポンスが向上しうる。
【０１４８】
実施の形態では、サーバ群１０２２の状態制御について、状態設定部１１５０において表１に示されるストラテジが使用される場合について説明したが、これに限られない。例えば、省電力状態としてＯＳ休眠状態を使用し、電源オフ状態を使用しなくてもよい。この場合、電源オンオフにかかる比較的長いオーバヘッドがなくなるので、より早いレスポンスが期待できる。また、処理が簡素化される。別の例としては、省電力状態として電源オフ状態を使用し、ＯＳ休眠状態を使用しなくてもよい。この場合、消費電力をより低減できる。
【０１４９】
実施の形態では、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とデータベースサーバ１０２８とは別個のサーバであり、この順に直列に接続されている場合について説明したが、これに限られない。個々のサーバ群は少なくともひとつのサーバを含めばよく、例えば、サーバ群はフロントエンドサーバとアプリケーションサーバとデータベースサーバの機能を全て併せ持つ１台のサーバを含んでもよい。また、サーバ群は、それら３つのサーバの機能のうちの任意の２つの機能を併せ持つサーバと、残りの機能を持つサーバと、を含んでもよい。
【０１５０】
実施の形態では、負荷予測部１１６０は予測アクセス数を負荷比較部１１５２に渡す場合について説明したが、これに限られない。例えば、負荷予測部１１６０は一年以上前の同月同日の同じ時間帯の稼動サーバ群の数を取得し、その稼動サーバ群の数を稼動サーバ群決定部１１５４に渡してもよい。この場合、稼動サーバ群決定部１１５４はこの稼動サーバ群の数を基に稼動状態にするサーバ群を決定する。
【０１５１】
実施の形態では、要求処理ユニットがサーバ群である場合について説明したが、これに限られない。本実施の形態に係る技術思想は例えばＧＳＬＢ（Global Server Load Balance）にも応用されうる。そこでは、要求処理ユニットはそれ自体が複数の並列に配されたサーバ群を有するシステムであってもよい。また、実施の形態では要求はユーザからのアクセスである場合について説明したが、これに限られず、本実施の形態に係る技術思想が適用されるシステムによって異なってもよい。要求とは処理主体への処理の指示であるとも言える。
【０１５２】
実施の形態では、負荷管理装置１０１０と情報処理装置１０２０とが異なる装置である場合について説明したが、これに限られず、負荷管理装置１０１０と情報処理装置１０２０とが一体となっていてもよい。
【０１５３】
実施の形態では、サーバ群１０２２の平均消費電力、最高消費電力、電力コストのそれぞれとして、そのサーバ群１０２２のフロントエンドサーバ（ＷＥＢサーバ）１０２４の平均消費電力、最高消費電力、電力コストを採用する場合について説明したが、これに限られない。例えば、サーバ群１０２２に含まれる各サーバの電力コストを算出し、それを平均した値をそのサーバ群１０２２の電力コストとして採用してもよい。
【０１５４】
実施の形態では、例えば図１５に示されるように、解析装置１００においてパケットの傍受（Ｓ４０２）からデータの集計（Ｓ４１２）が一連の処理として行われる場合について説明したが、これに限られない。例えば、解析装置は、パケットの傍受からデータの分類までを随時行って分類結果のデータを蓄積し、所定の条件が満たされると分類結果のデータを集計してもよい。ここで所定の条件は、例えば前回の集計から所定の期間が経過したこと、もしくは分類結果のデータの量が所定の量に達したことである。
【０１５５】
図１８は、変形例に係る解析装置における一連の処理を示すフローチャートである。変形例に係る解析装置は、傍受部と、抽出部と、登録部と、通信情報保持部と、分類部と、分類結果保持部と、集計部と、を備える。傍受部は、ネットワークからパケットを傍受する（Ｓ５０２）。抽出部は、傍受されたパケットから始点アドレスとポート番号とを抽出する（Ｓ５０４）。登録部は、抽出された始点アドレスとポート番号とパケットのデータ量とを通信情報保持部に登録する（Ｓ５０６）。分類部は、通信情報保持部に保持されるデータを始点アドレスでソーティングする（Ｓ５０８）。分類部は、ソーティングされたデータを本来用途と非本来用途とに分類する（Ｓ５１０）。分類部は、分類結果を分類結果保持部に登録する（Ｓ５１２）。所定の条件が満たされていない場合（Ｓ５１４のＮ）、ステップＳ５０２に処理が戻る。これにより、所定の条件が満たされるまで分類結果が分類結果保持部に蓄積されてゆく。所定の条件が満たされた場合（Ｓ５１４のＹ）、集計部は、分類結果保持部に蓄積されたデータを集計する（Ｓ５１６）。
本変形例によると、所定の条件を変えることにより、集計の母集団として使用する分類結果データの量を調整できる。したがって、集計の結果得られる指標に対して求められている精度に応じて柔軟に分類結果データの量を調整できる。
【０１５６】
以上、実施の形態にもとづき本発明を説明したが、実施の形態は、本発明の原理、応用を示しているにすぎないことはいうまでもなく、実施の形態には、請求の範囲に規定された本発明の思想を逸脱しない範囲において、多くの変形例や配置の変更が可能であることはいうまでもない。
【符号の説明】
【０１５７】
２ 情報処理システム、 １００ 解析装置、 １０４ 通信情報保持部、 １０８ 第１指標保持部、 １１８ 第２指標保持部、 １５８ 第３指標保持部、 １００４ 外部ネットワーク、 １００６ ユーザ端末、 １０１０ 負荷管理装置、 １０２０ 情報処理装置、 １１１２ 稼動履歴保持部、 １１１４ サーバ群状態保持部、 １１１６ 接続保持部、 １１２０ 要求取得部、 １１３０ 要求割当部、 １１４０ 負荷検出部、 １１５０ 状態設定部、 １１６０ 負荷予測部、 １１８０ 稼動履歴記録部。
【特許請求の範囲】
【請求項１】
複数の要求処理ユニットがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数の要求処理ユニットのうちの少なくともひとつに、取得された要求を割り当てる負荷管理装置と、
ネットワークから得られる情報から、要求処理ユニットごとにその要求処理ユニットに対して予め定められた用途の単位仕事量当たりの消費電力を算出する解析装置と、を備え、
前記負荷管理装置は、
複数の要求処理ユニットのうち要求に対応した処理の実行が不要な少なくともひとつの要求処理ユニットを選択するユニット選択部と、
前記ユニット選択部によって選択された少なくともひとつの要求処理ユニットを、要求を受付可能な稼動状態から、稼動状態よりも省電力の省電力状態に設定するユニット設定部と、を含み、
前記ユニット選択部は、前記解析装置によって算出された消費電力が大きいほど優先的に省電力状態に設定されるように、各要求処理ユニットに対して省電力状態とされる順番を設定し、
前記ユニット選択部は、要求の負荷が所定の値より少ない場合、稼動状態にある要求処理ユニットのうち省電力状態とされる順番が最も高い要求処理ユニットを、要求に対応した処理の実行が不要な要求処理ユニットとして選択することを特徴とする情報処理システム。
【請求項２】
前記負荷管理装置は、取得された要求を、前記解析装置によって算出された消費電力が小さい要求処理ユニットに優先的に割り当てることを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記ユニット選択部は、複数の要求処理ユニットのうち一部が前記稼動状態に設定されており、残りが前記省電力状態に設定されているとき、要求の負荷が前記所定の値より多くなると予測される場合には、前記省電力状態に設定されている要求処理ユニットのうち省電力状態とされる順番が最も低い要求処理ユニットを優先的に選択し、
前記ユニット設定部は、前記省電力状態に設定されている要求処理ユニットから前記ユニット選択部によって選択された要求処理ユニットを前記稼動状態に設定することを特徴とする請求項１または２に記載の情報処理システム。
【請求項４】
前記解析装置は、
通信に関わる要求処理ユニットを特定するユニット情報とその通信の用途を示す用途情報とを含む通信情報を前記ネットワークから傍受する傍受部と、
前記傍受部によって傍受された通信情報からユニット情報と用途情報とを抽出する抽出部と、
前記抽出部によって抽出されたユニット情報と用途情報とによって通信情報を分類する分類部と、
前記分類部における分類結果に基づいて、要求処理ユニットごとにその要求処理ユニットに対して予め定められた用途の単位仕事量当たりの消費電力を算出する解析部と、を含むことを特徴とする請求項１から３のいずれかに記載の情報処理システム。
【請求項５】
前記解析装置は、前記負荷管理装置によって取得される要求の負荷を算出し、
前記ユニット選択部は、前記解析装置によって算出された負荷が前記所定の値より少ない場合、稼動状態にある要求処理ユニットのうち省電力状態とされる順番が最も高い要求処理ユニットを、要求に対応した処理の実行が不要な要求処理ユニットとして選択することを特徴とする請求項１から４のいずれかに記載の情報処理システム。
【請求項６】
複数の要求処理ユニットがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数の要求処理ユニットのうちの少なくともひとつに、取得された要求を割り当てるステップと、
ネットワークから得られる情報から、要求処理ユニットごとにその要求処理ユニットに対して予め定められた用途の単位仕事量当たりの消費電力を算出するステップと、
複数の要求処理ユニットのうち要求に対応した処理の実行が不要な少なくともひとつの要求処理ユニットを選択するステップと、
選択された少なくともひとつの要求処理ユニットを、要求を受付可能な稼動状態から、稼動状態よりも省電力の省電力状態に設定するステップと、
算出された消費電力が大きいほど優先的に省電力状態に設定されるように、各要求処理ユニットに対して省電力状態とされる順番を設定するステップと、
要求の負荷が所定の値より少ない場合、稼動状態にある要求処理ユニットのうち省電力状態とされる順番が最も高い要求処理ユニットを、要求に対応した処理の実行が不要な要求処理ユニットとして選択するステップと、を含むことを特徴とする情報処理方法。
【請求項７】
複数の要求処理ユニットがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数の要求処理ユニットのうちの少なくともひとつに、取得された要求を割り当てる機能と、
ネットワークから得られる情報から、要求処理ユニットごとにその要求処理ユニットに対して予め定められた用途の単位仕事量当たりの消費電力を算出する機能と、
複数の要求処理ユニットのうち要求に対応した処理の実行が不要な少なくともひとつの要求処理ユニットを選択する機能と、
選択された少なくともひとつの要求処理ユニットを、要求を受付可能な稼動状態から、稼動状態よりも省電力の省電力状態に設定する機能と、
算出された消費電力が大きいほど優先的に省電力状態に設定されるように、各要求処理ユニットに対して省電力状態とされる順番を設定する機能と、
要求の負荷が所定の値より少ない場合、稼動状態にある要求処理ユニットのうち省電力状態とされる順番が最も高い要求処理ユニットを、要求に対応した処理の実行が不要な要求処理ユニットとして選択する機能と、をコンピュータに実現させることを特徴とするコンピュータプログラム。
【請求項１】
複数の要求処理ユニットがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数の要求処理ユニットのうちの少なくともひとつに、取得された要求を割り当てる負荷管理装置と、
ネットワークから得られる情報から、要求処理ユニットごとにその要求処理ユニットに対して予め定められた用途の単位仕事量当たりの消費電力を算出する解析装置と、を備え、
前記負荷管理装置は、
複数の要求処理ユニットのうち要求に対応した処理の実行が不要な少なくともひとつの要求処理ユニットを選択するユニット選択部と、
前記ユニット選択部によって選択された少なくともひとつの要求処理ユニットを、要求を受付可能な稼動状態から、稼動状態よりも省電力の省電力状態に設定するユニット設定部と、を含み、
前記ユニット選択部は、前記解析装置によって算出された消費電力が大きいほど優先的に省電力状態に設定されるように、各要求処理ユニットに対して省電力状態とされる順番を設定し、
前記ユニット選択部は、要求の負荷が所定の値より少ない場合、稼動状態にある要求処理ユニットのうち省電力状態とされる順番が最も高い要求処理ユニットを、要求に対応した処理の実行が不要な要求処理ユニットとして選択することを特徴とする情報処理システム。
【請求項２】
前記負荷管理装置は、取得された要求を、前記解析装置によって算出された消費電力が小さい要求処理ユニットに優先的に割り当てることを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記ユニット選択部は、複数の要求処理ユニットのうち一部が前記稼動状態に設定されており、残りが前記省電力状態に設定されているとき、要求の負荷が前記所定の値より多くなると予測される場合には、前記省電力状態に設定されている要求処理ユニットのうち省電力状態とされる順番が最も低い要求処理ユニットを優先的に選択し、
前記ユニット設定部は、前記省電力状態に設定されている要求処理ユニットから前記ユニット選択部によって選択された要求処理ユニットを前記稼動状態に設定することを特徴とする請求項１または２に記載の情報処理システム。
【請求項４】
前記解析装置は、
通信に関わる要求処理ユニットを特定するユニット情報とその通信の用途を示す用途情報とを含む通信情報を前記ネットワークから傍受する傍受部と、
前記傍受部によって傍受された通信情報からユニット情報と用途情報とを抽出する抽出部と、
前記抽出部によって抽出されたユニット情報と用途情報とによって通信情報を分類する分類部と、
前記分類部における分類結果に基づいて、要求処理ユニットごとにその要求処理ユニットに対して予め定められた用途の単位仕事量当たりの消費電力を算出する解析部と、を含むことを特徴とする請求項１から３のいずれかに記載の情報処理システム。
【請求項５】
前記解析装置は、前記負荷管理装置によって取得される要求の負荷を算出し、
前記ユニット選択部は、前記解析装置によって算出された負荷が前記所定の値より少ない場合、稼動状態にある要求処理ユニットのうち省電力状態とされる順番が最も高い要求処理ユニットを、要求に対応した処理の実行が不要な要求処理ユニットとして選択することを特徴とする請求項１から４のいずれかに記載の情報処理システム。
【請求項６】
複数の要求処理ユニットがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数の要求処理ユニットのうちの少なくともひとつに、取得された要求を割り当てるステップと、
ネットワークから得られる情報から、要求処理ユニットごとにその要求処理ユニットに対して予め定められた用途の単位仕事量当たりの消費電力を算出するステップと、
複数の要求処理ユニットのうち要求に対応した処理の実行が不要な少なくともひとつの要求処理ユニットを選択するステップと、
選択された少なくともひとつの要求処理ユニットを、要求を受付可能な稼動状態から、稼動状態よりも省電力の省電力状態に設定するステップと、
算出された消費電力が大きいほど優先的に省電力状態に設定されるように、各要求処理ユニットに対して省電力状態とされる順番を設定するステップと、
要求の負荷が所定の値より少ない場合、稼動状態にある要求処理ユニットのうち省電力状態とされる順番が最も高い要求処理ユニットを、要求に対応した処理の実行が不要な要求処理ユニットとして選択するステップと、を含むことを特徴とする情報処理方法。
【請求項７】
複数の要求処理ユニットがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数の要求処理ユニットのうちの少なくともひとつに、取得された要求を割り当てる機能と、
ネットワークから得られる情報から、要求処理ユニットごとにその要求処理ユニットに対して予め定められた用途の単位仕事量当たりの消費電力を算出する機能と、
複数の要求処理ユニットのうち要求に対応した処理の実行が不要な少なくともひとつの要求処理ユニットを選択する機能と、
選択された少なくともひとつの要求処理ユニットを、要求を受付可能な稼動状態から、稼動状態よりも省電力の省電力状態に設定する機能と、
算出された消費電力が大きいほど優先的に省電力状態に設定されるように、各要求処理ユニットに対して省電力状態とされる順番を設定する機能と、
要求の負荷が所定の値より少ない場合、稼動状態にある要求処理ユニットのうち省電力状態とされる順番が最も高い要求処理ユニットを、要求に対応した処理の実行が不要な要求処理ユニットとして選択する機能と、をコンピュータに実現させることを特徴とするコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１１−２１０２２５（Ｐ２０１１−２１０２２５Ａ）
【公開日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願番号】特願２０１０−１５９５５２（Ｐ２０１０−１５９５５２）
【出願日】平成２２年７月１４日（２０１０．７．１４）
【分割の表示】特願２０１０−７２２１４（Ｐ２０１０−７２２１４）の分割
【原出願日】平成２２年３月２６日（２０１０．３．２６）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願日】平成２２年７月１４日（２０１０．７．１４）
【分割の表示】特願２０１０−７２２１４（Ｐ２０１０−７２２１４）の分割
【原出願日】平成２２年３月２６日（２０１０．３．２６）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]