JP7092345B2 - サーバ制御装置、サーバ制御方法およびサーバ制御プログラム - Google Patents

Description

本発明はサーバ制御技術に関し、特に、サーバの動作状態を制御するサーバ制御装置、サーバ制御方法およびサーバ制御プログラムに関する。

従来、複数のサーバが処理した過去のトラフィック量から将来のトラフィック量を予測してサーバの動作状態を制御する様々な技術が提案されている。例えば、特許文献１が開示する制御方法は、予測対象期間の直近のトラフィック情報を用いて近似曲線を生成すると共に、当該予測対象期間と条件が同じトラフィック情報に基づくトラフィック予測モデルを生成する。そして、当該近似曲線に基づくトラフィック量の最大値と、当該トラフィック予測モデルに基づくトラフィック量の最大値を比較し、数値の大きい方のトラフィック量を選択し、このトラフィック量に所定の補正値を加算して最大トラフィック量Ｔ_ｍａｘを算出する。そして、当該最大トラフィック量Ｔ_ｍａｘに応じた稼働設備数を算出し、当該稼働設備数に対応した設備を稼働させる。

また、特許文献２が開示する方法は、過去数年分のトラフィック量を変動パラメータ毎に集積し、変動パラメータおよび時間毎にトラフィック量の平均値および標準偏差を算出し、このトラフィック量の平均値および標準偏差の加算値に対応するサーバの稼働数を、最適なサーバの稼働数として決定する。

国際公開第２０１２／００１７７２号 特開２０１３－２２５２０４号公報

しかしながら、特許文献１が開示する制御方法は、トラフィック予測モデルに基づくトラフィック量の最大値が、近似曲線に基づくトラフィック量の最大値、すなわち、予測対象期間の直近のトラフィック情報に基づくトラフィック量の最大値よりも大きい場合には、当該トラフィック予測モデルに基づくトラフィック量の最大値を選択する。その結果、予測対象期間の直近のトラフィック情報が反映されないため、サーバ数の予測精度が低く、実際に必要な数よりも過剰な数の設備を稼働させるため、省電力効果が低いという問題があった。

また、特許文献２が開示する方法は、現時点におけるトラフィック量を考慮することなく、過去のトラフィック量のみに基づいて最適なサーバの稼働数を予測するため、予測したサーバの稼働数と、実際に必要なサーバの稼働数とが乖離する恐れがあり、特許文献１に記載の制御方法と同様に、サーバ数の予測精度が低く、省電力効果が低いという問題があった。

本発明の目的は、上述した課題を鑑み、トラフィック処理に必要なサーバ数の予測精度が高く、省電力効果が高いサーバ制御装置、サーバ制御方法およびサーバ制御プログラムを提供することを目的とする。

本発明の一実施形態に係るサーバ制御装置は、複数のノードとの通信において発生するトラフィックの少なくともデータ転送量に関する内容を示すトラフィック情報に基づき、所定の各時間帯において前記トラフィックを処理するために必要なサーバ数を算出する必要サーバ数算出部と、前記所定の各時間帯において必要なサーバ数に基づき、連続する２つの時間帯におけるサーバ数の変化量を算出する変化量算出部と、現在の時間帯から後続の予測対象の時間帯に移行した場合のサーバ数の予測変化量と、現在の時間帯における最大必要サーバ数とに基づき、予測対象の時間帯において必要とされる予測サーバ数を算出する予測サーバ数算出部と、前記予測サーバ数に基づき、トラフィックを処理するサーバの数を増減させる動作状態制御部とを含む。

本発明により、トラフィック処理に必要なサーバ数の予測精度が高く、省電力効果が高いサーバ制御装置、サーバ制御方法およびサーバ制御プログラムを提供することができる。

本発明の第１の実施形態に係る通信システムを示す図である。 本発明の第１の実施形態に係るサーバ制御装置の概略的な構成を示すブロック図である。 本発明の第１の実施形態に係るサーバ制御装置の詳細な構成を示すブロック図である。 本発明の第１の実施形態に係る必要サーバ数テーブルを示す図である。 本発明の第１の実施形態に係るサーバ数変化量度数分布テーブルを示す図である。 本発明の第１の実施形態に係るサーバ数変化量集計テーブルを示す図である。 本発明の第１の実施形態に係るサーバ管理テーブルを示す図である。 本発明の第１の実施形態に係る呼制御サーバの構成を示すブロック図である。 本発明の第１の実施形態に係るＵ－Ｐｌａｎｅ処理サーバの構成を示すブロック図である。 本発明の第１の実施形態に係るパケット振分サーバの構成を示すブロック図である。 本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。 本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。 本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。 本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。 本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。 本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。 本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。 本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。 本発明の第１の実施形態に係る呼制御サーバが実行する処理を示すフローチャートである。 サーバ数が不足している場合に実行される一連の処理の一実施形態を示すシーケンス図である。 サーバ数が過剰な場合に実行される一連の処理の一実施形態を示すシーケンス図である。 サーバ数が過剰な状態が是正された後に実行される一連の処理の一実施形態を示すシーケンス図である。 予測サーバ数とサーバの動作状態の時系列変化を示す概念図である。 本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。 本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。 本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。 輻輳が発生した場合に実行される一連の処理の一実施形態を示すシーケンス図である。 本発明の第２の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。

＜第１の実施形態＞
以下、図面を参照して本発明の第１の実施形態について説明する。図１は、本発明の第１の実施形態に係る通信システム１００を示す図である。通信システム１００は、複数のノード（図示せず）とデータ通信を行う装置である。ノードとは、通信システム１００とデータ通信が可能な通信装置であり、例えば、ユーザが利用するスマートフォンやタブレット型端末、ラップトップＰＣ等の携帯型の通信装置やデータサーバである。通信システム１００は、サーバ制御装置１０と、呼制御サーバ２０と、ユーザープレーン（Ｕｓｅｒ－Ｐｌａｎｅ）（以下、「Ｕ－Ｐｌａｎｅ」とする。）処理サーバ３０１～３０ｎ（ｎは任意の整数）と、パケット振分サーバ４０と、レイヤスイッチ５０とを含む。サーバ制御装置１０、呼制御サーバ２０、Ｕ－Ｐｌａｎｅ処理サーバ３０１～３０ｎおよびパケット振分サーバ４０は、それぞれネットワークを介してレイヤスイッチ５０に接続される。レイヤスイッチ５０は、通信システム１００内の送信元から受信したパケットを送信先に転送する。

図２は、本発明の第１の実施形態に係るサーバ制御装置１０の概略的な構成を示すブロック図である。サーバ制御装置１０は、Ｕ－Ｐｌａｎｅ処理サーバ３０１～３０ｎの動作状態を制御する装置である。サーバ制御装置１０は、演算装置であるＣＰＵ（Central Processing Unit）（図示せず）を備えており、ＲＯＭ（Read Only Memory）（図示せず）に保存されたプログラムをＲＡＭ（Random Access Memory）（図示せず）に展開して、プログラムモジュールである必要サーバ数算出部１１と、変化量算出部１２と、予測サーバ数算出部１３と、動作状態制御部１４を呼び出し、後述する処理を実行する。

図３は、本発明の第１の実施形態に係るサーバ制御装置１０の詳細な構成を示すブロック図である。サーバ制御装置１０は、上述したプログラムモジュールに加えて、サーバ数評価部１５と、必要サーバ数テーブル１６と、サーバ数変化量度数分布テーブル１７と、サーバ数変化量集計テーブル１８と、サーバ管理テーブル１９とを含む。

必要サーバ数算出部１１は、通信システム１００と複数のノードとの間の通信において発生するトラフィックに起因する情報（以下、「トラフィック情報」とする。）に基づき、所定の各時間帯において当該トラフィックを処理するために必要なＵ－Ｐｌａｎｅ処理サーバの数（以下、「必要サーバ数」とする。）を算出する必要サーバ数算出処理を実行するプログラムモジュールである。必要サーバ数算出部１１は、必要サーバ数の算出に先立ち、呼制御サーバ２０およびパケット振分サーバ４０にトラフィック情報の取得要求を周期的に送信する。当該取得要求の送信間隔は、例えば、数秒～数分間隔とすることができるが、トラフィック情報のリアルタイム性を高めるため、送信間隔は短い方が好ましい。

トラフィック情報は、トラフィックの少なくともデータ転送量に関する内容を示す情報であり、例えば、単位時間当たりのリソース制御信号の数やユーザ信号の数、通信システム１００と通信中のノードの数（同時接続数）、Ｕ－Ｐｌａｎｅ処理サーバ３０１～３０ｎの単位時間当たりの実際のデータ転送量を示すスループット等である。ここで、リソース制御信号は、呼制御サーバ２０がＵ－Ｐｌａｎｅ処理サーバ３０１～３０ｎに送信する制御信号であり、ノードとの通信においてＵ－Ｐｌａｎｅ処理サーバ３０１～３０ｎがユーザ信号を処理するために必要な情報を設定するための制御信号である。また、ユーザ信号とは、通信システム１００とノードとの間で通信されるＵ－Ｐｌａｎｅ信号である。

必要サーバ数算出部１１は、呼制御サーバ２０およびパケット振分サーバ４０からトラフィック情報を受信すると、これらのトラフィック情報に基づいて必要サーバ数を算出する。具体的には、単位時間当たりのリソース制御信号およびユーザ信号の数から必要サーバ数を算出する場合、単位時間当たりのリソース制御信号およびユーザ信号の数を、各Ｕ－Ｐｌａｎｅ処理サーバが単位時間当たりに処理可能なデータ量の和で除算することにより、必要サーバ数を算出することができる。通信システム１００と通信中のノードの数から必要サーバ数を算出する場合、通信システム１００と通信中のノードの数を、Ｕ－Ｐｌａｎｅ処理サーバ３０１～３０ｎで処理可能なノード数の和で除算することにより、必要サーバ数を算出することができる。

Ｕ－Ｐｌａｎｅ処理サーバ３０１～３０ｎの単位時間当たりの実際のデータ転送量を示すスループット（実測値）には、携帯型の通信装置から受信したユーザ信号の単位時間当たりの転送量が含まれる。当該スループットを、各Ｕ－Ｐｌａｎｅ処理サーバの単位時間当たりに処理可能なデータ量の和で除算することにより、必要サーバ数を算出することができる。必要サーバ数算出部１１は、このようにして算出した必要サーバ数を、必要サーバ数テーブル１６に登録する。

図４は、或る月の必要サーバ数テーブル１６の一例を示す。図４に示す必要サーバ数テーブル１６には、リソース制御信号数、ノード数（同時接続数）、ユーザ信号数およびスループットそれぞれに基づく必要サーバ数が、日付、曜日および時間帯毎に登録される。必要サーバ数算出部１１は、トラフィック情報の種類毎の必要サーバ数を登録すると、これらの必要サーバ数の最大値を最大必要サーバ数として登録する。ここで、必要サーバ数算出部１１は、同一の時間帯について必要サーバ数を複数回算出するが、既に登録されている必要サーバ数を超える必要サーバ数を算出した場合にのみ、必要サーバ数テーブル１６の各フィールドを更新する。なお、本実施形態では、所定の時間帯の間隔として１時間を採用するが、その他の間隔（例えば、１５分や３０分等）を採用してもよい。

変化量算出部１２は、必要サーバ数テーブル１６を参照し、所定の各時間帯の必要サーバ数に基づき、連続する２つの時間帯における必要サーバ数の変化量を算出する変化量算出処理を実行するプログラムモジュールである。変化量算出部１２は、必要サーバ数テーブル１６の所定の時間帯が終了したタイミングや１日の終わり、月の終わり等の任意のタイミングで変化量算出処理を実行することができる。

例えば、図４に示す必要サーバ数テーブル１６に基づいて、「１日」の「００：００～００：５９」から「０１：００～０１：５９」に移行した場合の必要サーバ数の変化量を算出する場合について説明する。「１日」の「００：００～００：５９」の最大必要サーバ数は「１．８」であり、「１日」の「０１：００～０１：５９」の最大必要サーバ数は「１．６」である。この場合、変化量算出部１２は、「０１：００～０１：５９」の最大必要サーバ数「１．６」から「００：００～００：５９」の最大必要サーバ数「１．８」を減算し、必要サーバ数の変化量として「－０．２（＝１．６－１．８）」を算出する。変化量算出部１２は、このようにして算出した必要サーバ数の変化量を、「０１：００～０１：５９」の必要サーバ数の変化量としてサーバ数変化量度数分布テーブル１７に登録する。

図５は、或る月のサーバ数変化量度数分布テーブル１７の一例を示す。図５に示すサーバ数変化量度数分布テーブル１７には、曜日、時間帯およびサーバ数の変化量区分毎に、当該変化量区分に該当する必要サーバ数の変化量の日数と、当該必要サーバ数の変化量の加算値である累積変化量が登録される。変化量算出部１２は、サーバ数変化量度数分布テーブル１７を参照し、必要サーバ数テーブル１６に基づいて算出した必要サーバ数の変化量が該当する変化量区分を特定し、当該変化量区分に対応する「日数」のフィールドの値をインクリメントすると共に、「累積変化量」のフィールドに変化量の加算値を登録する。

また、変化量算出部１２は、任意の期間（例えば、３ヶ月等）のサーバ数変化量度数分布テーブル１７の必要サーバ数の変化量を集計して、予測対象の時間帯の必要サーバ数の変化量である予測変化量を算出し、図６に示すようなサーバ数変化量集計テーブル１８に登録する。図６に示すサーバ数変化量集計テーブル１８には、曜日および時間帯毎に、予測変化量が登録される。変化量算出部１２は、サーバ数変化量度数分布テーブル１７を参照し、必要サーバ数の変化量の日数および累積変化量から予測変化量を算出する。

ここで、予測変化量の算出方法の一例について説明する。例えば、図５に示すサーバ数変化量度数分布テーブル１７から「平日」の「００：００～００：５９」における予測変化量を算出する場合、変化量算出部１２は、「平日」の「００：００～００：５９」に関連する全ての変化量区分について、累積変化量を日数で除算して累積変化量の平均値を算出する。例えば、「±０．０～＋０．５」の変化量区分について、累積変化量「＋０．３」を日数「２」で除算することにより、累積変化量の平均値「＋０．１５」を算出することができる。

そして、変化量算出部１２は、全ての変化量区分の累積変化量を加算し、その和を当該時間帯の全日数（２０（＝２＋１４＋４））で除算することにより、予測変化量を算出することができる（（０．３－５．８－２．６）÷２０＝－０．４０５）。変化量算出部１２は、任意の期間（例えば、３か月等）のサーバ数変化量度数分布テーブル１７から、それぞれ予測変化量を算出し、これらの予測変化量を加算し、その和を当該期間の月数（３ヶ月の場合は「３」）で除算することにより、当該期間における予測変化量を算出することができる。

上述した予測変化量の算出方法では、対象となる時間帯の全ての変化量区分に関連する日数および累積変化量を用いて予測変化量を算出するが、他の算出方法では、日数の値が最も大きい変化量区分の日数および累積変化量を用いて予測変化量を算出してもよい。この場合、変化量算出部１２は、「平日」の「００：００～００：５９」に関連する変化量区分のうち「－０．１～－０．５」の変化量区分について、累積変化量「－５．８」を日数「１４」で除算することにより、予測変化量を算出することができる。

予測サーバ数算出部１３は、現在の時間帯から後続の予測対象の時間帯に移行した場合の必要サーバ数の予測変化量と、現在の時間帯における最大必要サーバ数に基づき、予測対象の時間帯において必要とされるサーバ数（以下、「予測サーバ数」とする。）を算出する予測サーバ数算出処理を実行する。具体的には、予測サーバ数算出部１３は、必要サーバ数テーブル１６を参照して現在の時間帯における最大必要サーバ数を特定し、サーバ数変化量集計テーブル１８を参照して予測対象の時間帯の予測変化量を特定し、当該最大必要サーバ数と当該予測変化量を加算することにより、予測サーバ数を算出することができる。

動作状態制御部１４は、予測サーバ数に基づき、Ｕ－Ｐｌａｎｅ処理サーバ３０１～３０ｎの動作状態を制御する動作状態制御処理を実行する。Ｕ－Ｐｌａｎｅ処理サーバの動作状態には、（１）通常の動作状態である通常動作モード、（２）ノードとの通信に伴うタスクの新たな割り当てが制限された状態の抑止モード、（３）省電力の休止状態である休止モード、および（４）電源がＯＦＦの状態の停止モードがある。動作状態制御部１４は、Ｕ－Ｐｌａｎｅ処理サーバ３０１～３０ｎの動作状態を、図７に示すようなサーバ管理テーブル１９に登録する。サーバ管理テーブル１９には、Ｕ－Ｐｌａｎｅ処理サーバ３０１～３０ｎの識別情報と、動作状態とが関連付けて登録される。

サーバ数評価部１５は、トラフィックを処理する通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数の適正を評価するサーバ数評価処理を実行するプログラムモジュールである。サーバ数評価部１５は、サーバ管理テーブル１９を参照して通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数を計数する。そして、サーバ数評価部１５は、この計数値から予測サーバ数を減算して得られた値（以下、「サーバ数評価値」とする。）に基づき、サーバ数の適正を判断する。具体的には、サーバ数評価部１５は、サーバ数が不足するか、サーバ数が過剰であるか、サーバ数に余裕が有るか、サーバ数に余裕が無いか、またはサーバ数が適正であるかを判断する。

ここで、予測サーバ数とＵ－Ｐｌａｎｅ処理サーバの動作状態の時系列変化を示す図２３を参照して、サーバの数の適正の判断方法の具体例について説明する。本実施形態では、（１）サーバ数評価値が０未満の場合には、サーバ数が不足すると判断し、（２）サーバ数評価値が１以上の場合には、サーバ数は過剰であると判断する。また、（３）サーバ数評価値が０．７～１未満の場合には、サーバ数に余裕が有ると判断し、（４）サーバ数評価値が０～０．３以下の場合には、サーバ数に余裕が無いと判断する。なお、サーバ数評価値の判断に使用する閾値は、これらに限定されるものではなく、サーバ数の不適正な状態を識別し得る限り、任意の値を使用することができる。

例えば、図２２に示す例において、現在の時間帯を「１２：００～１３：００」とし、予測対象の時間帯を「１３：００～１４：００」とすると、現在の通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数は「２」であり、予測対象の時間帯「１３：００～１４：００」における予測サーバ数は「２．２」である。したがって、サーバ数評価値は「－０．２（＝２－２．２）」となり、サーバ数評価部１５は、サーバ数が不足すると判断する。この場合、動作状態制御部１４は、停止モードのＵ－Ｐｌａｎｅ処理サーバを起動させる。この処理については、図１１～１４を参照して後述する。

また、図２３に示す例において、現在の時間帯を「１４：００～１５：００」とし、予測対象の時間帯を「１５：００～１６：００」とすると、現在の通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数は「４」であり、予測対象の時間帯「１５：００～１６：００」における予測サーバ数は、「２．３」である。したがって、サーバ数評価値は「１．７（＝４－２．３）」となり、サーバ数評価部１５は、サーバ数が過剰であると判断する。この場合、動作状態制御部１４は、通常動作モードのＵ－Ｐｌａｎｅ処理サーバを抑止モードに移行させる。この処理については、図１１および図１５を参照して後述する。

次いで、サーバ数評価部１５は、再度、現在の通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数を計数し、この計数値「３」から予測サーバ数「２．３」を減算して、新たなサーバ数評価値「０．７」を算出する。そして、サーバ数評価部１５は、当該サーバ数評価値「０．７」に基づき、サーバ数に余裕が有ると判断する。この場合、動作状態制御部１４は、休止モードのＵ－Ｐｌａｎｅ処理サーバの数を停止モードに移行させる。この処理については、図１７を参照して後述する。

さらに、図２３に示す例において、現在の時間帯を「９：００～１０：００」とし、予測対象の時間帯を「１０：００～１１：００」とすると、現在の通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数は「１」であり、予測対象の時間帯「１０：００～１１：００」における予測サーバ数は、「０．８」である。したがって、サーバ数評価値は「０．２（＝１－０．８）」となり、サーバ数評価部１５は、サーバ数に余裕が無いと判断する。この場合、動作状態制御部１４は、停止モードのＵ－Ｐｌａｎｅ処理サーバを起動させて休止モードに移行させる。この処理については、図１１および図１４を参照して後述する。

図８は、本発明の第１の実施形態に係る呼制御サーバ２０の構成を示すブロック図である。呼制御サーバ２０は、演算装置であるＣＰＵ（図示せず）を備えており、ＲＯＭ（図示せず）に保存されたプログラムをＲＡＭ（図示せず）に展開して、プログラムモジュールであるトラフィック情報収集部２１と、コントロールプレーン（Ｃｏｎｔｒｏｌ－Ｐｌａｎｅ）（以下、「Ｃ－Ｐｌａｎｅ」とする。）処理部２２と、制御部２３を呼び出し、後述する処理を実行する。

呼制御サーバ２０の記憶装置には、ノード管理テーブル２４と、サーバ管理テーブル２５が構築される。ノード管理テーブル２４は、Ｕ－Ｐｌａｎｅ処理サーバの識別情報とノードの識別情報とが関連付けられて登録されるデータテーブルである。Ｕ－Ｐｌａｎｅ処理サーバの識別情報には、複数のノードの識別情報が関連付けて登録され得る。サーバ管理テーブル２５は、サーバ管理テーブル１９と同様に、Ｕ－Ｐｌａｎｅ処理サーバの識別情報と、当該Ｕ－Ｐｌａｎｅ処理サーバの動作状態とが関連付けられて登録されるデータテーブルである。

トラフィック情報収集部２１は、トラフィック情報を収集し、サーバ制御装置１０からのトラフィック情報の取得要求に応じて、現在のトラフィック情報を提供するプログラムモジュールである。トラフィック情報収集部２１が収集するトラフィック情報には、リソース制御信号数と、ノード管理テーブル２４に登録されている通信中のノードの数（同時接続数）が含まれる。Ｃ－Ｐｌａｎｅ処理部２２は、ノードが送信したＣ－Ｐｌａｎｅ信号を終端し、通信システム１００とノードとの間の通信に必要な制御情報を制御部２３に提供するプログラムモジュールである。Ｃ－Ｐｌａｎｅ信号は、ノードからパケット振分サーバ４０に送信され、パケット振分サーバ４０からＣ－Ｐｌａｎｅ処理部２２に送信される。

制御部２３は、呼制御サーバ２０の全体制御を行うプログラムモジュールである。制御部２３は、パケット振分サーバ４０からＣ－Ｐｌａｎｅ処理部２２を介して、新たなノードとの通信開始を示す制御情報を受信すると、当該新たなノードとの間の通信に関するパケットを処理すべきＵ－Ｐｌａｎｅ処理サーバを決定する。この制御情報には、新たなノードが送信したＣ－Ｐｌａｎｅ信号に付加された当該新たなノードの識別情報が含まれる。制御部２３は、サーバ管理テーブル２５を参照し、動作状態が通常動作モードのＵ－Ｐｌａｎｅ処理サーバを、新たなノードとの通信に関するパケットを処理するＵ－Ｐｌａｎｅ処理サーバとして選択する。そして、制御部２３は、選択したＵ－Ｐｌａｎｅ処理サーバの識別情報と、当該制御情報に含まれる当該新たなノードの識別情報とを、パケットの振分先を規定する振分先情報としてパケット振分サーバ４０に送信する。なお、制御部２３は、動作状態が抑止モードや休止モード、停止モードのＵ－Ｐｌａｎｅ処理サーバを選択しない。制御部２３が実行する他の処理については、後述する。

図９は、本発明の第１の実施形態に係るＵ－Ｐｌａｎｅ処理サーバ３０１の構成を示すブロック図である。その他のＵ－Ｐｌａｎｅ処理サーバ３０２～３０ｎは、Ｕ－Ｐｌａｎｅ処理サーバ３０１と同様の構成を有するため、説明を省略する。

Ｕ－Ｐｌａｎｅ処理サーバ３０１は、複数のノードからパケット振分サーバ４０を介して受信したユーザ信号に関するパケットを処理する装置である。Ｕ－Ｐｌａｎｅ処理サーバ３０１は、演算装置であるＣＰＵ（図示せず）を備えており、ＲＯＭ（図示せず）に保存されたプログラムをＲＡＭ（図示せず）に展開して、プログラムモジュールである電源制御部３１と、ノード設定部３２と、輻輳監視部３４と、パケット処理部３３を呼び出し、後述する処理を実行する。

Ｕ－Ｐｌａｎｅ処理サーバ３０１の記憶装置には、ノード管理テーブル３５が構築される。ノード管理テーブル３５は、Ｕ－Ｐｌａｎｅ処理サーバの識別情報とノードの識別情報とが関連付けられて登録されるデータテーブルである。Ｕ－Ｐｌａｎｅ処理サーバの識別情報には、複数のノードの識別情報が関連付けて登録され得る。

電源制御部３１は、サーバ制御装置１０の要求に応じてＵ－Ｐｌａｎｅ処理サーバ３０１の電源を制御し、Ｕ－Ｐｌａｎｅ処理サーバ３０１の動作状態を制御するプログラムモジュールである。ノード設定部３２は、呼制御サーバ２０からのリソース制御信号に応じてノード管理テーブル３５を処理するプログラムモジュールである。ノード設定部３２は、呼制御サーバ２０から受信した単位時間当たりのリソース制御信号数と、ノード管理テーブル３５に登録されているノード数（同時接続数）を輻輳監視部３４に提供する。

パケット処理部３３は、パケット振分サーバ４０から転送されたユーザ信号を処理するプログラムモジュールである。パケット処理部３３は、パケット振分サーバ４０からユーザ信号を受信すると、当該ユーザ信号に関連するトラフィック情報（例えば、単位時間当たりにノードから受信したユーザ信号の数、単位時間当たりの実際のデータ転送量を示すスループット等）を輻輳監視部３４に提供する。

輻輳監視部３４は、呼制御サーバ２０から受信したリソース制御信号の数と、Ｕ－Ｐｌａｎｅ処理サーバに設定されているノード数（同時接続数）と、ノードからパケット振分サーバ４０を介して受信したユーザ信号の数と、ユーザ信号のスループットを常時監視し、Ｕ－Ｐｌａｎｅ処理サーバ３０１の処理限界に近づくと、輻輳が発生したと判断し、その旨を通知するプログラムモジュールである。輻輳監視部３４は、単位時間当たりのリソース制御信号の数またはユーザ信号の数が所定の閾値を超えた場合に、輻輳が発生したと判断し、当該リソース制御信号の数またはユーザ信号の数が当該所定の閾値未満になった場合に、輻輳が終了したと判断することができる。また、輻輳監視部３４は、単位時間当たりの実際のデータ転送量を示すスループット（実測値）がＵ－Ｐｌａｎｅ処理サーバの処理可能なデータ転送量の上限値に近い所定の閾値に達した場合に、輻輳が発生したと判断し、当該スループットが当該所定の閾値を下回った場合に、輻輳が終了したと判断することができる。また、輻輳監視部３４は、設定されているノード数がＵ－Ｐｌａｎｅ処理サーバの処理可能なノード数の上限値に近い所定の閾値に達した場合に、輻輳が発生したと判断し、当該ノード数が当該所定の閾値を下回った場合に、輻輳が終了したと判断することができる。

図１０は、本発明の第１の実施形態に係るパケット振分サーバの構成を示すブロック図である。パケット振分サーバ４０は、複数のノードから受信したパケットを呼制御サーバ２０およびＵ－Ｐｌａｎｅ処理サーバに振り分ける装置である。パケット振分サーバ４０は、演算装置であるＣＰＵ（図示せず）を備えており、ＲＯＭ（図示せず）に保存されたプログラムをＲＡＭ（図示せず）に展開して、プログラムモジュールであるトラフィック情報収集部４１と、振分先情報設定部４２と、パケット転送部４３を呼び出し、後述する処理を実行する。パケット振分サーバ４０の記憶装置には、振分先情報が登録される振分先情報テーブル４４が構築される。

トラフィック情報収集部４１は、ノードから受信したユーザ信号に関するトラフィック情報（例えば、ユーザ信号数、スループット等）を収集し、サーバ制御装置１０からのトラフィック情報の取得要求に応じて、現在のトラフィック情報を提供するプログラムモジュールである。

振分先情報設定部４２は、振分先情報テーブル４４を用いて、振分先情報の登録、変更および削除を行うプログラムモジュールである。振分先情報設定部４２は、呼制御サーバ２０から振分先情報を受信すると、当該振分先情報を振分先情報テーブル４４に登録する。具体的には、振分先情報であるノード識別情報と、当該ノード識別情報の示すノードが送信したユーザ信号に関するパケットを処理すべきＵ－Ｐｌａｎｅ処理サーバの識別情報とを関連付けて振分先情報テーブル４４に登録する。

パケット転送部４３は、ノードから受信したパケットを呼制御サーバ２０およびＵ－Ｐｌａｎｅ処理サーバに振り分けるプログラムモジュールである。このパケットには、当該パケットを送信したノードの識別情報、Ｃ－Ｐｌａｎｅ信号およびユーザ信号が含まれている。パケット転送部４３は、Ｃ－Ｐｌａｎｅ信号に関するパケットを呼制御サーバ２０に転送し、ユーザ信号に関するパケットをＵ－Ｐｌａｎｅ処理サーバに転送する。より詳細には、パケット転送部４３は、ユーザ信号に関するパケットを受信した場合、振分先情報テーブル４４を参照して、当該パケットの送信元のノードの識別情報に関連付けられているＵ－Ｐｌａｎｅ処理サーバの識別情報を特定し、当該ユーザ信号に関するパケットを当該Ｕ－Ｐｌａｎｅ処理サーバに転送する。

図１１～１８は、本発明の第１の実施形態に係るサーバ制御装置が実行する処理を示すフローチャートである。この処理は、所定のタイミング、例えば、予測対象の時間帯に移行する直前に実行される。図１１に示す処理は、ステップＳ１００から開始し、ステップＳ１０１では、サーバ制御装置１０の予測サーバ数算出部１３が、予測対象の時間帯における予測サーバ数を算出する。

ステップＳ１０２では、サーバ数評価部１５が、サーバ管理テーブル１９に登録されている通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数と、ステップＳ１０１で算出された予測サーバ数とを用いてサーバ数評価値を算出し、サーバ数の適正を判断する。サーバ数が不足する場合は、図１２に示すステップＳ２００に処理が進む。サーバ数が過剰である場合は、図１５に示すステップＳ３００に処理が進む。サーバ数に余裕が無い場合は、図１４に示すステップＳ２１４に処理が進む。サーバ数に余裕が有る場合は、図１７に示すステップＳ３１４に処理が進む。その他の場合、すなわち、サーバ数が適正な場合は、ステップＳ１０３で処理が終了する。

次に、図１２～１４を参照して、サーバ数が不足すると判断した場合に実行される処理について説明する。図１２に示すステップＳ２００では、動作状態制御部１４が、サーバ管理テーブル１９を参照し、休止中（すなわち、休止モード）のＵ－Ｐｌａｎｅ処理サーバが有るか否か判断する。休止モードのＵ－Ｐｌａｎｅ処理サーバが無い場合（ＮＯ）、図１３に示すステップＳ２０６に処理が進む。一方、休止モードのＵ－Ｐｌａｎｅ処理サーバが有る場合（ＹＥＳ）、ステップＳ２０１に進む。

ステップＳ２０１では、動作状態制御部１４は、休止モードのＵ－Ｐｌａｎｅ処理サーバに対し、休止解除要求を送信する。ステップＳ２０２では、動作状態制御部１４は、当該休止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として休止解除完了通知を受信したか否か判断する。休止解除完了通知を受信していない場合（ＮＯ）、ステップＳ２０２が再び実行される。一方、休止解除完了通知を受信した場合（ＹＥＳ）、ステップＳ２０３に処理が進む。

ステップＳ２０３では、動作状態制御部１４は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバの休止が解除された旨を通知する。ステップＳ２０４では、動作状態制御部１４は、サーバ管理テーブル１９の当該Ｕ－Ｐｌａｎｅ処理サーバの動作状態を休止モードから通常動作モードに変更し、サーバ管理テーブル１９を更新する。ステップＳ２０５では、サーバ数評価部１５は、サーバ管理テーブル１９に登録されている通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数と、ステップＳ１０１で算出された予測サーバ数とを用いてサーバ数評価値を算出し、サーバ数が不足するか否か判断する。サーバ数が不足すると判断した場合（ＹＥＳ）、ステップＳ２００に処理が戻る。一方、サーバ数が不足しない判断した場合（ＮＯ）、図１４に示すステップＳ２１２に処理が進む。

図１３に示すステップＳ２０６では、動作状態制御部１４は、サーバ管理テーブル１９を参照し、停止中（すなわち、停止モード）のＵ－Ｐｌａｎｅ処理サーバが有るか否か判断する。停止モードのＵ－Ｐｌａｎｅ処理サーバが無い場合（ＮＯ）、ステップＳ２１２に処理が進む。一方、停止モードのＵ－Ｐｌａｎｅ処理サーバが有る場合（ＹＥＳ）、ステップＳ２０７に進む。

ステップＳ２０７では、動作状態制御部１４は、停止モードのＵ－Ｐｌａｎｅ処理サーバに対して起動要求を送信する。ステップＳ２０８では、動作状態制御部１４は、当該停止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として起動完了通知を受信したか否か判断する。起動完了通知を受信していない場合（ＮＯ）、ステップＳ２０８が再び実行される。一方、起動完了通知を受信した場合（ＹＥＳ）、ステップＳ２０９に処理が進む。

ステップＳ２０９では、動作状態制御部１４は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバが起動した旨を通知する。ステップＳ２１０では、動作状態制御部１４は、サーバ管理テーブル１９の当該Ｕ－Ｐｌａｎｅ処理サーバの動作状態を停止モードから通常動作モードに変更し、サーバ管理テーブル１９を更新する。ステップＳ２１１では、サーバ数評価部１５は、サーバ管理テーブル１９に登録されている通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数と、ステップＳ１０１で算出された予測サーバ数とを用いてサーバ数評価値を算出し、サーバ数が不足するか否か判断する。サーバ数が不足すると判断した場合（ＹＥＳ）、ステップＳ２０６に処理が戻る。一方、サーバ数が不足しない判断した場合（ＮＯ）、図１４に示すステップＳ２１２に処理が進む。

ステップＳ２１２では、サーバ数評価部１５は、サーバ管理テーブル１９に登録されている通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数と、ステップＳ１０１で算出された予測サーバ数とを用いてサーバ数評価値を算出し、サーバ数に余裕が無いか否か判断する。サーバ数に余裕が無い状態ではない場合（ＮＯ）、ステップＳ２１３で処理が終了する。一方、サーバ数に余裕が無いと判断した場合（ＹＥＳ）、ステップＳ２１４に処理が進む。ステップＳ２１４では、動作状態制御部１４は、サーバ管理テーブル１９を参照し、停止モードのＵ－Ｐｌａｎｅ処理サーバが有るか否か判断する。停止モードのＵ－Ｐｌａｎｅ処理サーバが無い場合（ＮＯ）、ステップＳ２１３で処理が終了する。一方、停止モードのＵ－Ｐｌａｎｅ処理サーバが有る場合（ＹＥＳ）、ステップＳ２１５に進む。

ステップＳ２１５では、動作状態制御部１４は、停止モードのＵ－Ｐｌａｎｅ処理サーバに対して起動要求を送信する。ステップＳ２１６では、動作状態制御部１４は、当該停止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として起動完了通知を受信したか否か判断する。起動完了通知を受信していない場合（ＮＯ）、ステップＳ２１６が再び実行される。起動完了通知を受信した場合（ＹＥＳ）、ステップＳ２１７に処理が進む。ステップＳ２１７では、動作状態制御部１４は、当該起動したＵ－Ｐｌａｎｅ処理サーバに対し、休止要求を送信する。ステップＳ２１８では、動作状態制御部１４は、当該停止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として休止完了通知を受信したか否か判断する。休止完了通知を受信していない場合（ＮＯ）、ステップＳ２１８が再び実行される。休止完了通知を受信した場合（ＹＥＳ）、ステップＳ２１９に処理が進む。

ステップＳ２１９では、動作状態制御部１４は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバが休止した旨、すなわち、休止モードである旨を通知する。ステップＳ２１０では、動作状態制御部１４は、サーバ管理テーブル１９の当該Ｕ－Ｐｌａｎｅ処理サーバの動作状態を停止モードから休止モードに変更し、サーバ管理テーブル１９を更新し、ステップＳ２１２に処理が戻る。

次に、図１５～１８を参照して、サーバ数が過剰であると判断した場合に実行される処理について説明する。図１５に示すステップＳ３００では、動作状態制御部１４は、サーバ管理テーブル１９を参照し、抑止中（すなわち、抑止モード）のＵ－Ｐｌａｎｅ処理サーバが有るか否か判断する。抑止モードのＵ－Ｐｌａｎｅ処理サーバが無い場合（ＮＯ）、図１６に示すステップＳ３０８に処理が進む。一方、抑止モードのＵ－Ｐｌａｎｅ処理サーバが有る場合（ＹＥＳ）、ステップＳ３０１に進む。

ステップＳ３０１では、動作状態制御部１４は、呼制御サーバ２０に対し、抑止モードのＵ－Ｐｌａｎｅ処理サーバを指定した休止準備要求を送信する。ステップＳ３０２では、動作状態制御部１４は、呼制御サーバ２０から、応答として休止準備完了通知を受信したか否か判断する。休止準備完了通知を受信していない場合（ＮＯ）、ステップＳ３０２が再び実行される。一方、休止準備完了通知を受信した場合（ＹＥＳ）、ステップＳ３０３に処理が進む。ステップＳ３０３では、動作状態制御部１４は、抑止モードのＵ－Ｐｌａｎｅ処理サーバに対して休止要求を送信する。ステップＳ３０４では、動作状態制御部１４は、当該抑止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として休止完了通知を受信したか否か判断する。休止完了通知を受信していない場合（ＮＯ）、ステップＳ３０４が再び実行される。一方、休止完了通知を受信した場合（ＹＥＳ）、ステップＳ３０５に処理が進む。

ステップＳ３０５では、動作状態制御部１４は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバが休止した旨を通知する。ステップＳ３０６では、動作状態制御部１４は、サーバ管理テーブル１９の当該Ｕ－Ｐｌａｎｅ処理サーバの動作状態を抑止モードから休止モードに変更し、サーバ管理テーブル１９を更新する。ステップＳ３０７では、サーバ数評価部１５は、サーバ管理テーブル１９に登録されている通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数と、ステップＳ１０１で算出された予測サーバ数とを用いてサーバ数評価値を算出し、サーバ数が過剰であるか否か判断する。サーバ数が過剰であると判断した場合（ＹＥＳ）、ステップＳ３００に処理が戻る。一方、サーバ数が過剰ではないと判断した場合（ＮＯ）、図１７に示すステップＳ３１３に処理が進む。

図１６に示すステップＳ３０８では、動作状態制御部１４は、サーバ管理テーブル１９を参照し、通常動作モードのＵ－Ｐｌａｎｅ処理サーバが有るか否か判断する。通常動作モードのＵ－Ｐｌａｎｅ処理サーバが無い場合（ＮＯ）、図１７に示すステップＳ３１３に処理が進む。一方、通常動作モードのＵ－Ｐｌａｎｅ処理サーバが有る場合（ＹＥＳ）、ステップＳ３０９に処理が進む。

ステップＳ３０９では、動作状態制御部１４は、呼制御サーバ２０に抑止要求を送信し、後述する抑止設定処理を実行させる。ステップＳ３１０では、動作状態制御部１４は、呼制御サーバ２０から、応答として抑止完了通知を受信したか否か判断する。抑止完了通知を受信していない場合（ＮＯ）、ステップＳ３１０が再び実行される。一方、抑止完了通知を受信した場合（ＹＥＳ）、ステップＳ３１１に処理が進む。抑止完了通知には、抑止モードに移行した抑止対象のＵ－Ｐｌａｎｅ処理サーバの識別情報が含まれる。

ステップＳ３１１では、動作状態制御部１４は、サーバ管理テーブル１９を参照し、抑止完了通知に含まれる抑止対象のＵ－Ｐｌａｎｅ処理サーバの動作状態を通常動作モードから抑止モードに変更し、サーバ管理テーブル１９を更新する。ステップＳ３１２では、サーバ数評価部１５は、サーバ管理テーブル１９に登録されている通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数と、ステップＳ１０１で算出された予測サーバ数とを用いてサーバ数評価値を算出し、サーバ数が過剰であるか否か判断する。サーバ数が過剰であると判断した場合（ＹＥＳ）、ステップＳ３０８に処理が戻る。一方、サーバ数が過剰ではないと判断した場合（ＮＯ）、図１７に示すステップＳ３１３に処理が進む。

ステップＳ３１３では、サーバ数評価部１５は、サーバ管理テーブル１９に登録されている通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数と、ステップＳ１０１で算出された予測サーバ数とを用いてサーバ数評価値を算出し、サーバ数に余裕が有るか否か判断する。サーバ数に余裕が無いと判断した場合（ＮＯ）、図１８に示すステップＳ３２０に処理が進む。一方、サーバ数に余裕が有ると判断した場合（ＹＥＳ）、ステップＳ３１４に処理が進む。

ステップＳ３１４では、動作状態制御部１４は、サーバ管理テーブル１９を参照し、休止モードのＵ－Ｐｌａｎｅ処理サーバが有るか否か判断する。休止モードのＵ－Ｐｌａｎｅ処理サーバが無い場合（ＮＯ）、ステップＳ３１９で処理が終了する。一方、休止モードのＵ－Ｐｌａｎｅ処理サーバが有る場合（ＹＥＳ）、ステップＳ３１５に進む。ステップＳ３１５では、動作状態制御部１４は、休止モードのＵ－Ｐｌａｎｅ処理サーバに対し、停止要求を送信する。ここで、複数のＵ－Ｐｌａｎｅ処理サーバが休止モードの場合、本実施形態では、全ての休止モードのサーバに対して停止要求を送信する。

ステップＳ３１６では、動作状態制御部１４は、当該休止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として停止完了通知を受信したか否か判断する。停止完了通知を受信していない場合（ＮＯ）、ステップＳ３１６が再び実行される。一方、停止完了通知を受信した場合（ＹＥＳ）、ステップＳ３１７に処理が進む。ステップＳ３１７では、動作状態制御部１４は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバが停止モードである旨を通知する。ステップＳ３１８では、動作状態制御部１４は、サーバ管理テーブル１９の当該Ｕ－Ｐｌａｎｅ処理サーバの動作状態を休止モードから停止モードに変更し、サーバ管理テーブル１９を更新し、ステップＳ３１９で処理が終了する。

図１８に示すステップＳ３２０では、動作状態制御部１４は、サーバ管理テーブル１９を参照し、停止モードのＵ－Ｐｌａｎｅ処理サーバが有るか否か判断する。停止モードのＵ－Ｐｌａｎｅ処理サーバが無い場合（ＮＯ）、ステップＳ３２７で処理が終了する。一方、停止モードのＵ－Ｐｌａｎｅ処理サーバが有る場合（ＹＥＳ）、ステップＳ３２１に進む。

ステップＳ３２１では、動作状態制御部１４は、停止モードのＵ－Ｐｌａｎｅ処理サーバに起動要求を送信する。ここで、停止モードのＵ－Ｐｌａｎｅ処理サーバが複数存在する場合、本実施形態では、動作状態制御部１４は、停止モードのＵ－Ｐｌａｎｅ処理サーバのうちいずれか１つに起動要求を送信する。

ステップＳ３２２では、動作状態制御部１４は、当該停止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として起動完了通知を受信したか否か判断する。起動完了通知を受信していない場合（ＮＯ）、ステップＳ３２２が再び実行される。一方、起動完了通知を受信した場合（ＹＥＳ）、ステップＳ３２３に処理が進む。ステップＳ３２３では、動作状態制御部１４は、当該起動したＵ－Ｐｌａｎｅ処理サーバに休止要求を送信する。ステップＳ３２４では、動作状態制御部１４は、当該停止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として休止完了通知を受信したか否か判断する。休止完了通知を受信していない場合（ＮＯ）、ステップＳ３２４が再び実行される。一方、休止完了通知を受信した場合（ＹＥＳ）、ステップＳ３２５に処理が進む。

ステップＳ３２５では、動作状態制御部１４は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバが休止モードである旨を通知する。ステップＳ３２６では、動作状態制御部１４は、サーバ管理テーブル１９の当該Ｕ－Ｐｌａｎｅ処理サーバの動作状態を停止モードから休止モードに変更してサーバ管理テーブル１９を更新し、ステップＳ３２７で処理が終了する。

図１９は、本発明の第１の実施形態に係る呼制御サーバ２０が実行する休止準備処理の一実施形態を示すフローチャートである。休止準備処理は、抑止モードのＵ－Ｐｌａｎｅ処理サーバを休止モードに移行させる前に実行される処理である。

図１９に示す処理は、呼制御サーバ２０がサーバ制御装置１０から休止準備要求を受信することにより、ステップＳ４００から開始する。休止準備要求には、休止準備要求である旨を示す要求コードと、抑止モードのＵ－Ｐｌａｎｅ処理サーバの識別情報が含まれる。ステップＳ４０１では、呼制御サーバ２０の制御部２３が、ノード管理テーブル２４を参照し、休止準備要求で指定された抑止モードのＵ－Ｐｌａｎｅ処理サーバに対するノードの割り当てが有るか否か判断する。当該Ｕ－Ｐｌａｎｅ処理サーバに対するノードの割り当てが無い場合（ＮＯ）、ステップＳ４０８に処理が進む。一方、当該Ｕ－Ｐｌａｎｅ処理サーバに対するノードの割り当てが有る場合（ＹＥＳ）、ステップＳ４０２に処理が進む。

ステップＳ４０２では、制御部２３は、サーバ管理テーブル２５を参照して通常動作モードのＵ－Ｐｌａｎｅ処理サーバを特定し、当該通常動作モードのＵ－Ｐｌａｎｅ処理サーバにノード設定要求を送信する。ノード設定要求は、休止準備要求で指定された抑止モードのＵ－Ｐｌａｎｅ処理サーバに割り当てられているノードを、当該通常動作モードのＵ－Ｐｌａｎｅ処理サーバに設定するための要求である。

ステップＳ４０３では、制御部２３は、当該通常動作モードのＵ－Ｐｌａｎｅ処理サーバから、応答としてノード設定完了通知を受信したか否か判断する。ノード設定完了通知を受信していない場合（ＮＯ）、ステップＳ４０３が再び実行される。一方、ノード設定完了通知を受信した場合（ＹＥＳ）、ステップＳ４０４に処理が進む。

ステップＳ４０４では、制御部２３は、パケット振分サーバ４０に対し、パケットの振分先の変更を要求する振分先変更要求を送信する。ステップＳ４０５では、制御部２３は、パケット振分サーバ４０から、応答として振分先変更完了通知を受信したか否か判断する。振分先変更完了通知を受信していない場合（ＮＯ）、ステップＳ４０５が再び実行される。一方、振分先変更完了通知を受信した場合（ＹＥＳ）、ステップＳ４０６に処理が進む。

ステップＳ４０６では、制御部２３は、抑止モードのＵ－Ｐｌａｎｅ処理サーバに対し、当該Ｕ－Ｐｌａｎｅ処理サーバに割り当てられているノードの削除を要求するノード削除要求を送信する。ステップＳ４０７では、制御部２３は、当該抑止モードのＵ－Ｐｌａｎｅ処理サーバからノード削除完了通知を受信したか否か判断する。ノード削除完了通知を受信していない場合（ＮＯ）、ステップＳ４０７が再び実行される。一方、ノード削除完了通知を受信した場合（ＹＥＳ）、ステップＳ４０８に処理が進む。ステップＳ４０８では、制御部２３は、サーバ制御装置１０に対し、休止準備処理が完了した旨を示す休止準備完了通知を送信し、ステップＳ４０９で処理が終了する。

図２０は、図１１に示すステップＳ１０２において予測対象の時間帯におけるサーバ数が不足すると判断した場合に、通信システム１００において実行される一連の処理の一実施形態を示すシーケンス図である。なお、図２０に示す例では、Ｕ－Ｐｌａｎｅ処理サーバ３０１の動作状態は休止モードであり、Ｕ－Ｐｌａｎｅ処理サーバ３０２、３０３の動作状態は停止モードであり、Ｕ－Ｐｌａｎｅ処理サーバ３０４の動作状態は通常動作モードである。

サーバ制御装置１０は、予測対象の時間帯におけるサーバ数が不足すると判断すると、休止モードのＵ－Ｐｌａｎｅ処理サーバ３０１に対し、休止解除要求を送信する。Ｕ－Ｐｌａｎｅ処理サーバ３０１は、休止解除要求を受信すると、休止解除処理を実行して通常動作モードに移行し、休止解除完了通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、休止解除完了通知を受信すると、呼制御サーバ２０に対し、Ｕ－Ｐｌａｎｅ処理サーバ３０１の休止が解除された旨の休止解除通知を送信する。呼制御サーバ２０は、休止解除通知を受信すると、サーバ管理テーブル２５のＵ－Ｐｌａｎｅ処理サーバ３０１の動作状態を休止モードから通常動作モードに変更する。

この時点で、予測対象の時間帯におけるサーバ数が未だ不足する場合、サーバ制御装置１０は、停止モードのＵ－Ｐｌａｎｅ処理サーバ３０２に対し、起動要求を送信する。Ｕ－Ｐｌａｎｅ処理サーバ３０２は、起動要求を受信すると、起動処理を実行して通常動作モードに移行し、起動完了通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、起動完了通知を受信すると、呼制御サーバ２０に対し、Ｕ－Ｐｌａｎｅ処理サーバ３０２が起動した旨の起動通知を送信する。呼制御サーバ２０は、起動通知を受信すると、サーバ管理テーブル２５のＵ－Ｐｌａｎｅ処理サーバ３０２の動作状態を停止モードから通常動作モードに変更する。

この時点で、予測対象の時間帯におけるサーバ数に余裕が無い場合、サーバ制御装置１０は、停止モードのＵ－Ｐｌａｎｅ処理サーバ３０３に対し、起動要求を送信する。Ｕ－Ｐｌａｎｅ処理サーバ３０３は、サーバ制御装置１０から起動要求を受信すると、起動処理を実行して通常動作モードに移行し、起動完了通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、Ｕ－Ｐｌａｎｅ処理サーバ３０３から起動完了通知を受信すると、Ｕ－Ｐｌａｎｅ処理サーバ３０３に休止要求を送信する。Ｕ－Ｐｌａｎｅ処理サーバ３０３は、サーバ制御装置１０から休止要求を受信すると、休止処理を実行して休止モードに移行し、休止完了通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、Ｕ－Ｐｌａｎｅ処理サーバ３０３から休止完了通知を受信すると、呼制御サーバ２０に対し、Ｕ－Ｐｌａｎｅ処理サーバ３０３が休止した旨の休止通知を送信する。呼制御サーバ２０は、休止通知を受信すると、サーバ管理テーブル２５のＵ－Ｐｌａｎｅ処理サーバ３０３の動作状態を停止モードから休止モードに変更する。

図２１および図２２は、図１１に示すステップＳ１０２において予測対象の時間帯におけるサーバ数が過剰であると判断した場合に、通信システム１００において実行される一連の処理の一実施形態を示すシーケンス図である。なお、ここに示す例では、Ｕ－Ｐｌａｎｅ処理サーバ３０１、３０２の当初の動作状態は通常動作モードであり、Ｕ－Ｐｌａｎｅ処理サーバ３０３の当初の動作状態は抑止モードであり、Ｕ－Ｐｌａｎｅ処理サーバ３０４の当初の動作状態は停止モードである。

サーバ制御装置１０は、予測対象の時間帯におけるサーバ数が過剰であると判断すると、抑止モードのＵ－Ｐｌａｎｅ処理サーバ３０３を休止モードに移行させるために、呼制御サーバ２０に対し、Ｕ－Ｐｌａｎｅ処理サーバ３０３の休止準備要求を送信する。呼制御サーバ２０は、休止準備要求を受信すると、図１９を参照して説明した休止準備処理を実行する。

具体的には、呼制御サーバ２０は、サーバ管理テーブル２５を参照して通常動作モードのＵ－Ｐｌａｎｅ処理サーバ３０１を特定し、当該通常動作モードのＵ－Ｐｌａｎｅ処理サーバ３０１にノード設定要求を送信する。ノード設定要求には、ノードを設定する旨の要求コードと、抑止モードのＵ－Ｐｌａｎｅ処理サーバ３０３に割り当てられている全てのノードの識別情報が含まれる。Ｕ－Ｐｌａｎｅ処理サーバ３０１は、ノード設定要求を受信すると、当該ノード設定要求で指定された全てのノードの識別情報をノード管理テーブル３５に登録し、ノード設定完了通知を呼制御サーバ２０に送信する。

呼制御サーバ２０は、ノード設定完了通知を受信すると、振分先変更要求をパケット振分サーバ４０に送信する。振分先変更要求は、抑止モードのＵ－Ｐｌａｎｅ処理サーバ３０３に割り当てられているパケットの振分先を通常動作モードのＵ－Ｐｌａｎｅ処理サーバ３０１に変更するための要求である。振分先変更要求には、パケットの振分先を変更する旨を示す要求コードと、抑止モードのＵ－Ｐｌａｎｅ処理サーバ３０３の識別情報と、通常動作モードのＵ－Ｐｌａｎｅ処理サーバ３０１の識別情報が含まれる。

パケット振分サーバ４０は、振分先変更要求を受信すると、振分先情報テーブル４４において抑止モードのＵ－Ｐｌａｎｅ処理サーバ３０３の識別情報に関連付けられているノードの識別情報を削除すると共に、当該ノードの識別情報を、通常動作モードのＵ－Ｐｌａｎｅ処理サーバ３０１の識別情報に関連付けて登録する。そして、パケット振分サーバ４０は、振分先変更完了通知を呼制御サーバ２０に送信する。

呼制御サーバ２０は、振分先変更完了通知を受信すると、抑止モードのＵ－Ｐｌａｎｅ処理サーバ３０３に対し、ノードの識別情報を削除する旨のノード削除要求を送信する。Ｕ－Ｐｌａｎｅ処理サーバ３０３は、ノード削除要求を受信すると、ノード管理テーブル３５に登録されている全てのノードの識別情報を削除し、ノード削除完了通知を呼制御サーバ２０に送信する。呼制御サーバ２０は、ノード削除完了通知を受信すると、休止準備完了通知をサーバ制御装置１０に送信する。

サーバ制御装置１０は、休止準備完了通知を受信すると、抑止モードのＵ－Ｐｌａｎｅ処理サーバ３０３に対し、休止要求を送信する。Ｕ－Ｐｌａｎｅ処理サーバ３０３は、休止要求を受信すると、休止処理を実行して休止モードに移行すると共に、休止完了通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、休止完了通知を受信すると、呼制御サーバ２０に対し、Ｕ－Ｐｌａｎｅ処理サーバ３０３が休止した旨の休止通知を送信する。呼制御サーバ２０は、休止通知を受信すると、サーバ管理テーブル２５のＵ－Ｐｌａｎｅ処理サーバ３０３の動作状態を抑止モードから休止モードに変更する。

この時点で、予測対象の時間帯におけるサーバ数が未だ過剰である場合、サーバ制御装置１０は、呼制御サーバ２０に抑止要求を送信する。呼制御サーバ２０は、抑止要求を受信すると、通常動作モードのＵ－Ｐｌａｎｅ処理サーバを抑止モードに移行させる抑止設定処理を実行する。抑止設定処理では、呼制御サーバ２０の制御部２３が、ノード管理テーブル２４を参照し、ノードの識別情報が関連付けられている数が最も少ないＵ－Ｐｌａｎｅ処理サーバ３０２、すなわち、割り当てられているノードの数が最も少ないＵ－Ｐｌａｎｅ処理サーバ３０２の識別情報を特定する。次いで、制御部２３は、サーバ管理テーブル２５を参照し、割り当てられているノードの数が最も少ないＵ－Ｐｌａｎｅ処理サーバの動作状態を抑止モードに変更し、サーバ制御装置１０にＵ－Ｐｌａｎｅ処理サーバ３０２を抑止モードにした旨の抑止完了通知を送信する。

この時点で、予測対象の時間帯におけるサーバ数に余裕が有る場合、図２２に示すように、サーバ制御装置１０は、休止モードのＵ－Ｐｌａｎｅ処理サーバ３０３に停止要求を送信する。Ｕ－Ｐｌａｎｅ処理サーバ３０３は、停止要求を受信すると、停止処理を実行して停止モードに移行し、停止完了通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、停止完了通知を受信すると、呼制御サーバ２０に対し、Ｕ－Ｐｌａｎｅ処理サーバ３０３が停止した旨の停止通知を送信する。呼制御サーバ２０は、停止通知を受信すると、サーバ管理テーブル２５のＵ－Ｐｌａｎｅ処理サーバ３０３の動作状態を休止モードから停止モードに変更する。

一方、予測対象の時間帯におけるサーバ数に余裕が無い場合、図２２に示すように、サーバ制御装置１０は、停止モードのＵ－Ｐｌａｎｅ処理サーバ３０４に対し、起動要求を送信する。Ｕ－Ｐｌａｎｅ処理サーバ３０４は、サーバ制御装置１０から起動要求を受信すると、起動処理を実行して通常動作モードに移行し、起動完了通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、Ｕ－Ｐｌａｎｅ処理サーバ３０４から起動完了通知を受信すると、Ｕ－Ｐｌａｎｅ処理サーバ３０４に休止要求を送信する。Ｕ－Ｐｌａｎｅ処理サーバ３０４は、サーバ制御装置１０から休止要求を受信すると、休止処理を実行して休止モードに移行し、休止完了通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、Ｕ－Ｐｌａｎｅ処理サーバ３０４から休止完了通知を受信すると、呼制御サーバ２０に対し、Ｕ－Ｐｌａｎｅ処理サーバ３０４が休止した旨の休止通知を送信する。呼制御サーバ２０は、休止通知を受信すると、サーバ管理テーブル２５のＵ－Ｐｌａｎｅ処理サーバ３０４の動作状態を停止モードから休止モードに変更する。

図２４および図２５は、Ｕ－Ｐｌａｎｅ処理サーバに輻輳が発生した場合に、サーバ制御装置１０が実行する処理の一実施形態を示すフローチャートである。図２４に示す処理は、サーバ制御装置１０が輻輳の発生したＵ－Ｐｌａｎｅ処理サーバから輻輳発生通知を受信することにより、ステップＳ５００から開始する。輻輳発生通知には、輻輳が発生した旨を示すイベント情報と、当該Ｕ－Ｐｌａｎｅ処理サーバの識別情報が含まれる。ステップＳ５０１では、サーバ制御装置１０の動作状態制御部１４が、サーバ管理テーブル１９を参照し、当該Ｕ－Ｐｌａｎｅ処理サーバの識別情報によって特定されるＵ－Ｐｌａｎｅ処理サーバの動作状態を、通常動作モードから輻輳状態を示す情報に変更する。

ステップＳ５０２では、動作状態制御部１４は、輻輳の発生したＵ－Ｐｌａｎｅ処理サーバを指定して抑止要求を呼制御サーバ２０に送信し、後述する抑止設定処理を実行させる。ステップＳ５０３では、動作状態制御部１４は、呼制御サーバ２０から抑止完了通知を受信したか否か判断する。抑止完了通知を受信していない場合（ＮＯ）、ステップＳ５０３が再び実行される。一方、抑止完了通知を受信した場合（ＹＥＳ）、ステップＳ５０４に処理が進む。

ステップＳ５０４では、予測サーバ数算出部１３が、予測対象の時間帯における予測サーバ数を算出する。ステップＳ５０５では、サーバ数評価部１５が、サーバ管理テーブル１９に登録されている通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数と、ステップＳ５０４で算出した予測サーバ数とを用いてサーバ数評価値を算出し、サーバ数が不足するか否か判断する。

サーバ数が不足しない場合（ＮＯ）、ステップＳ５０６で処理が終了する。一方、サーバ数が不足する場合（ＹＥＳ）、ステップＳ５０７に処理が進む。ステップＳ５０７では、動作状態制御部１４は、サーバ管理テーブル１９を参照し、休止モードのＵ－Ｐｌａｎｅ処理サーバが有るか否か判断する。休止モードのＵ－Ｐｌａｎｅ処理サーバが無い場合（ＮＯ）、図２５に示すステップＳ５１２に処理が進む。一方、休止モードのＵ－Ｐｌａｎｅ処理サーバが有る場合（ＹＥＳ）、ステップＳ５０８に進む。

ステップＳ５０８では、動作状態制御部１４は、休止モードのＵ－Ｐｌａｎｅ処理サーバに休止解除要求を送信する。ステップＳ５０９では、動作状態制御部１４は、当該休止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として休止解除完了通知を受信したか否か判断する。休止解除完了通知を受信していない場合（ＮＯ）、ステップＳ５０９が再び実行される。一方、休止解除完了通知を受信した場合（ＹＥＳ）、ステップＳ５１０に処理が進む。

ステップＳ５１０では、動作状態制御部１４は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバの休止が解除された旨を通知する。ステップＳ５１１では、動作状態制御部１４は、サーバ管理テーブル１９の当該Ｕ－Ｐｌａｎｅ処理サーバの動作状態を休止モードから通常動作モードに変更し、サーバ管理テーブル１９を更新する。

図２５に示すステップＳ５１２では、動作状態制御部１４は、サーバ管理テーブル１９を参照し、停止モードのＵ－Ｐｌａｎｅ処理サーバが有るか否か判断する。停止モードのＵ－Ｐｌａｎｅ処理サーバが無い場合（ＮＯ）、ステップＳ５１８で処理が終了する。一方、停止モードのＵ－Ｐｌａｎｅ処理サーバが有る場合（ＹＥＳ）、ステップＳ５１３に進む。

ステップＳ５１３では、動作状態制御部１４は、停止モードのＵ－Ｐｌａｎｅ処理サーバに対し、起動要求を送信する。ステップＳ５１４では、動作状態制御部１４は、当該停止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として起動完了通知を受信したか否か判断する。起動完了通知を受信していない場合（ＮＯ）、ステップＳ５１４が再び実行される。一方、起動完了通知を受信した場合（ＹＥＳ）、ステップＳ５１５に処理が進む。

ステップＳ５１５では、動作状態制御部１４は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバが起動した旨を通知する。ステップＳ５１６では、動作状態制御部１４は、サーバ管理テーブル１９の当該Ｕ－Ｐｌａｎｅ処理サーバの動作状態を停止モードから通常動作モードに変更し、サーバ管理テーブル１９を更新する。ステップＳ５１７では、サーバ数評価部１５は、サーバ管理テーブル１９に登録されている通常動作モードのＵ－Ｐｌａｎｅ処理サーバの数と、ステップＳ５０４で算出した予測サーバ数とを用いてサーバ評価値を算出し、サーバ数が不足するか否か判断する。サーバ数が不足すると判断した場合（ＹＥＳ）、ステップＳ５１２に処理が戻る。一方、サーバ数が不足しないと判断した場合（ＮＯ）、ステップＳ５１８で処理が終了する。

図２６は、Ｕ－Ｐｌａｎｅ処理サーバに輻輳が解消した場合に、サーバ制御装置１０が実行する処理の一実施形態を示すフローチャートである。図２６に示す処理は、サーバ制御装置１０が、輻輳の解消したＵ－Ｐｌａｎｅ処理サーバから輻輳終了通知を受信することにより、ステップＳ５１９から開始する。輻輳終了通知には、輻輳が解消した旨を示すイベント情報と、当該Ｕ－Ｐｌａｎｅ処理サーバの識別情報が含まれる。ステップＳ５２０では、動作状態制御部１４は、輻輳の解消したＵ－Ｐｌａｎｅ処理サーバを指定して抑止解除要求を呼制御サーバ２０に送信する。ステップＳ５２１では、動作状態制御部１４は、当該呼制御サーバ２０から、応答として抑止解除通知を受信したか否か判断する。抑止解除通知を受信していない場合（ＮＯ）、ステップＳ５２１が再び実行される。一方、抑止解除通知を受信した場合（ＹＥＳ）、ステップＳ５２２に処理が進む。ステップＳ５２２では、サーバ制御装置１０の動作状態制御部１４が、サーバ管理テーブル１９を参照し、当該Ｕ－Ｐｌａｎｅ処理サーバの識別情報によって特定されるＵ－Ｐｌａｎｅ処理サーバの動作状態を、輻輳状態を示す情報から通常動作モードに変更し、ステップＳ５２３で処理が終了する。

図２７は、輻輳が発生した場合に、通信システム１００において実行される一連の処理の一実施形態を示すシーケンス図である。図２７に示す例は、通常動作モードのＵ－Ｐｌａｎｅ処理サーバ３０１に輻輳が発生した場合に、休止モードのＵ－Ｐｌａｎｅ処理サーバ３０２および停止モードのＵ－Ｐｌａｎｅ処理サーバ３０３を通常動作モードに移行させる処理を示す。

Ｕ－Ｐｌａｎｅ処理サーバ３０１は、輻輳を検知すると、輻輳発生通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、輻輳発生通知を受信すると、サーバ管理テーブル１９を参照し、Ｕ－Ｐｌａｎｅ処理サーバ３０１の動作状態を、通常動作モードから輻輳状態を示す情報に変更する。そして、サーバ制御装置１０は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバ３０１を指定して抑止要求を送信する。呼制御サーバ２０は、抑止要求を受信すると、抑止設定処理を実行する。抑止設定処理では、呼制御サーバ２０の制御部２３が、サーバ管理テーブル２５を参照し、抑止要求で指定されたＵ－Ｐｌａｎｅ処理サーバ３０１の動作状態を通常動作モードから抑止モードに変更し、サーバ制御装置１０に抑止完了通知を送信する。

この時点で、予測対象の時間帯におけるサーバ数が不足する場合、サーバ制御装置１０は、休止モードのＵ－Ｐｌａｎｅ処理サーバ３０２に対し、休止解除要求を送信する。Ｕ－Ｐｌａｎｅ処理サーバ３０２は、休止解除要求を受信すると、休止解除処理を実行して通常動作モードに移行し、休止解除完了通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、休止解除完了通知を受信すると、呼制御サーバ２０に対し、Ｕ－Ｐｌａｎｅ処理サーバ３０２の休止が解除された旨の休止解除通知を送信する。呼制御サーバ２０は、休止解除通知を受信すると、サーバ管理テーブル２５のＵ－Ｐｌａｎｅ処理サーバ３０２の動作状態を休止モードから通常動作モードに変更する。

この時点で、予測対象の時間帯におけるサーバ数が未だ不足する場合、サーバ制御装置１０は、停止モードのＵ－Ｐｌａｎｅ処理サーバ３０３に対し、起動要求を送信する。Ｕ－Ｐｌａｎｅ処理サーバ３０３は、起動要求を受信すると、起動処理を実行して通常動作モードに移行し、起動完了通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、起動完了通知を受信すると、呼制御サーバ２０に対し、Ｕ－Ｐｌａｎｅ処理サーバ３０３が起動した旨の起動通知を送信する。呼制御サーバ２０は、起動通知を受信すると、サーバ管理テーブル２５のＵ－Ｐｌａｎｅ処理サーバ３０３の動作状態を停止モードから通常動作モードに変更する。

Ｕ－Ｐｌａｎｅ処理サーバ３０１は、輻輳の終了を検知すると、輻輳終了通知をサーバ制御装置１０に送信する。サーバ制御装置１０は、輻輳終了通知を受信すると、Ｕ－Ｐｌａｎｅ処理サーバ３０１の動作状態を、輻輳状態を示す情報から通常動作モードに変更する。そして、サーバ制御装置１０は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバ３０１を指定して抑止解除要求を送信する。呼制御サーバ２０は、抑止解除要求を受信すると、抑止解除処理を実行する。抑止解除処理では、呼制御サーバ２０の制御部２３が、サーバ管理テーブル２５を参照し、抑止解除要求で指定されたＵ－Ｐｌａｎｅ処理サーバ３０１の動作状態を、抑止モードから通常動作モードに変更し、サーバ制御装置１０に抑止解除通知を送信する。

本発明の第１の実施形態は、以下の効果を奏する。第１の実施形態では、予測サーバ数算出部１３が、現在の時間帯における最大必要サーバ数と、現在の時間帯に後続する予測対象の時間帯の予測変化量に基づいて予測サーバ数を算出する。その結果、現在のトラフィック情報を予測サーバ数に必ず反映させることができるため、サーバ数の予測精度を高めることができる。そして、この高精度の予測サーバ数に基づき、トラフィックを処理するＵ－Ｐｌａｎｅ処理サーバの数を増減させるため、Ｕ－Ｐｌａｎｅ処理サーバを過剰に稼働させることがなく、省電力効果を高めることができる。

また、第１の実施形態では、Ｕ－Ｐｌａｎｅ処理サーバの動作状態として抑止モードを採用する。抑止モードでは、タスクの新たな割り当てが制限されるため、抑止モードのＵ－Ｐｌａｎｅ処理サーバは、通常動作モードのＵ－Ｐｌａｎｅ処理サーバに比べ、休止モードまたは停止モードに速やかに移行することができる。その結果、サーバ数が過剰であると判断した場合、抑止モードのＵ－Ｐｌａｎｅ処理サーバが速やかに休止モードまたは停止モードに移行することができ、省電力効果をさらに高めることができる。

＜第２の実施形態＞
次に、図２８を参照して、サーバ数が過剰であると判断した場合に実行される処理の第２の実施形態について説明する。第２の実施形態では、図１１に示すステップＳ１０２においてサーバ数が過剰であると判断した場合に、サーバ数の過剰の度合に応じて、抑止モードのＵ－Ｐｌａｎｅ処理サーバを休止モードまたは停止モードに移行させることを特徴とする。

図２８に示すステップＳ６００では、動作状態制御部１４は、サーバ管理テーブル１９を参照し、抑止モードのＵ－Ｐｌａｎｅ処理サーバが有るか否か判断する。抑止モードのＵ－Ｐｌａｎｅ処理サーバが無い場合（ＮＯ）、図１６に示すステップＳ３０８に処理が進む。一方、抑止モードのＵ－Ｐｌａｎｅ処理サーバが有る場合（ＹＥＳ）、ステップＳ６０１に進む。

ステップＳ６０１では、動作状態制御部１４は、呼制御サーバ２０に対し、休止準備要求を送信する。ステップＳ６０２では、動作状態制御部１４は、呼制御サーバ２０から、応答として休止準備完了通知を受信したか否か判断する。休止準備完了通知を受信していない場合（ＮＯ）、ステップＳ６０２が再び実行される。休止準備完了通知を受信した場合（ＹＥＳ）、ステップＳ６０３に処理が進む。

ステップＳ６０３では、動作状態制御部１４は、サーバ数の過剰の度合に応じて、抑止モードのＵ－Ｐｌａｎｅ処理サーバを休止モードまたは停止モードのいずれに移行させるべきか判断する。具体的には、サーバ評価値が１～２未満の場合には過剰の度合が小さく、２以上の場合には過剰の度合が大きいとする。すなわち、動作状態制御部１４は、サーバ評価値が１～２未満の場合には休止モードに移行すべきと判断し、サーバ評価値が２以上の場合には停止モードに移行すべきと判断する。なお、サーバ数評価値の判断に使用する閾値は、これらに限定されるものではなく、サーバ数の過剰の度合を識別し得る限り、任意の値を使用することができる。

抑止モードのＵ－Ｐｌａｎｅ処理サーバを休止モードに移行すべきと判断した場合、ステップＳ６０４に処理が進む。ステップＳ６０４では、動作状態制御部１４は、抑止モードのＵ－Ｐｌａｎｅ処理サーバに対し、休止要求を送信する。ステップＳ６０５では、動作状態制御部１４は、当該抑止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として休止完了通知を受信したか否か判断する。休止完了通知を受信していない場合（ＮＯ）、ステップＳ６０５が再び実行される。一方、休止完了通知を受信した場合（ＹＥＳ）、ステップＳ６０６に処理が進む。

ステップＳ６０６では、動作状態制御部１４は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバが休止した旨を通知する。ステップＳ６０７では、動作状態制御部１４は、サーバ管理テーブル１９の当該Ｕ－Ｐｌａｎｅ処理サーバの動作状態を抑止モードから休止モードに変更し、サーバ管理テーブル１９を更新する。

一方、ステップＳ６０３において抑止モードのＵ－Ｐｌａｎｅ処理サーバを停止モードに移行すべきと判断した場合、ステップＳ６０８に処理が進む。ステップＳ６０８では、動作状態制御部１４は、抑止モードのＵ－Ｐｌａｎｅ処理サーバに対し、停止要求を送信する。ステップＳ６０９では、動作状態制御部１４は、当該抑止モードのＵ－Ｐｌａｎｅ処理サーバから、応答として停止完了通知を受信したか否か判断する。停止完了通知を受信していない場合（ＮＯ）、ステップＳ６０９が再び実行される。一方、停止完了通知を受信した場合（ＹＥＳ）、ステップＳ６１０に処理が進む。

ステップＳ６１０では、動作状態制御部１４は、呼制御サーバ２０に対し、当該Ｕ－Ｐｌａｎｅ処理サーバが停止した旨を通知する。ステップＳ６１１では、動作状態制御部１４は、サーバ管理テーブル１９の当該Ｕ－Ｐｌａｎｅ処理サーバの動作状態を抑止モードから停止モードに変更し、サーバ管理テーブル１９を更新する。

ステップＳ６１２では、サーバ数評価部１５は、サーバ管理テーブル１９と予測サーバ数を参照し、サーバ数が過剰であるか否か判断する。サーバ数が過剰であると判断した場合（ＹＥＳ）、ステップＳ６００に処理が戻る。一方、サーバ数が過剰ではないと判断した場合（ＮＯ）、図１７に示すステップＳ３１３に処理が進む。

本発明の第２の実施形態は、第１の実施形態の効果に加えて、以下の効果を奏する。第２の実施形態では、動作状態制御部１４は、サーバ数の過剰の度合に応じて、抑止モードのＵ－Ｐｌａｎｅ処理サーバを休止モードまたは停止モードのいずれに移行させるべきか判断する。そして、サーバ数の過剰の度合が大きい場合、抑止モードのＵ－Ｐｌａｎｅ処理サーバを、休止モードではなく停止モードに移行させる。このため、抑止モードのＵ－Ｐｌａｎｅ処理サーバを速やかに停止させることができ、省電力効果をさらに高めることができる。

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに提供することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＣＤ－Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ）を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに提供されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜その他の実施形態＞
本発明は、上述した実施形態に限られたものではなく、本発明の趣旨を逸脱しない範囲で適宜変更することができる。例えば、上述した実施形態では、呼制御サーバ２０とパケット振分サーバ４０を個別のサーバとして説明しているが、これらのサーバを１のサーバに統合してもよい。また、サーバ制御装置１０、呼制御サーバ２０およびパケット振分サーバ４０を１のサーバに統合してもよい。さらに、サーバ制御装置１０の機能を呼制御サーバ２０またはパケット振分サーバ４０に実装してもよい。さらに、上述した実施形態では、Ｕ－Ｐｌａｎｅ処理サーバが、ノードの送信したパケットを処理するが、ノードの送信したパケットを処理するサーバは、Ｕ－Ｐｌａｎｅ処理サーバに限定されるものではなく、他の様々なデータ処理サーバを使用することができる。

１０ サーバ制御装置
１１ 必要サーバ数算出部
１２ 変化量算出部
１３ 予測サーバ数算出部
１４ 動作状態制御部
１５ サーバ数評価部
１６ 必要サーバ数テーブル
１７ サーバ数変化量度数分布テーブル
１８ サーバ数変化量集計テーブル
１９ サーバ管理テーブル
２０ 呼制御サーバ
４０ パケット振分サーバ
５０ レイヤスイッチ
１００ 通信システム
３０１ Ｕ-Ｐｌａｎｅ処理サーバ
３０２ Ｕ-Ｐｌａｎｅ処理サーバ
３０３ Ｕ-Ｐｌａｎｅ処理サーバ
３０ｎ Ｕ-Ｐｌａｎｅ処理サーバ

Claims (8)

1. 複数のノードとの通信において発生するトラフィックの少なくともデータ転送量に関する内容を示すトラフィック情報に基づき、所定の各時間帯において前記トラフィックを処理するために必要なサーバ数を算出する必要サーバ数算出部と、
   前記所定の各時間帯において必要なサーバ数に基づき、連続する２つの時間帯におけるサーバ数の変化量を算出する変化量算出部と、
   現在の時間帯から後続の予測対象の時間帯に移行した場合のサーバ数の予測変化量と、現在の時間帯における最大必要サーバ数とに基づき、予測対象の時間帯において必要とされる予測サーバ数を算出する予測サーバ数算出部と、
   前記予測サーバ数に基づき、トラフィックを処理するサーバの数を増減させる動作状態制御部と
   を含む、サーバ制御装置。
2. 前記サーバ制御装置は、前記トラフィックを処理するサーバの数の適正を評価するサーバ数評価部を備え、
   前記サーバ数評価部が、前記サーバの数が過剰であると判断した場合、前記動作状態制御部は、通常動作モードのサーバを、タスクの新たな割り当てが制限される抑止モードに移行させる、請求項１に記載のサーバ制御装置。
3. 前記サーバ数評価部が、前記サーバの数が過剰であると判断した場合、前記動作状態制御部は、抑止モードのサーバが存在するときは、抑止モードのサーバを休止モードに移行させる、請求項２に記載のサーバ制御装置。
4. 前記サーバ数評価部が、前記サーバの数が過剰であると判断した場合、前記動作状態制御部は、抑止モードのサーバが存在するときは、前記サーバ数の過剰の度合に応じて、抑止モードのサーバを休止モードまたは停止モードに移行させる、請求項２に記載のサーバ制御装置。
5. 前記サーバ数評価部が、前記サーバの数が不足していると判断した場合、前記動作状態制御部は、休止モードまたは停止モードのサーバのうち少なくとも１つを通常動作モードに移行させる、請求項２～４のいずれか１項に記載のサーバ制御装置。
6. 前記動作状態制御部は、前記サーバに輻輳が発生した場合、前記輻輳が発生したサーバを抑止モードに移行させると共に、休止モードまたは停止モードのサーバのうち少なくとも１つを通常動作モードに移行させる、請求項１～５のいずれか１項に記載のサーバ制御装置。
7. サーバの動作状態を制御するサーバ制御装置が実行するサーバ制御方法であって、
   複数のノードとの通信において発生するトラフィックの少なくともデータ転送量に関する内容を示すトラフィック情報に基づき、所定の各時間帯において前記トラフィックを処理するために必要なサーバ数を算出するステップと、
   前記所定の各時間帯において必要なサーバ数に基づき、連続する２つの時間帯におけるサーバ数の変化量を算出するステップと、
   現在の時間帯から後続の予測対象の時間帯に移行した場合のサーバ数の予測変化量と、現在の時間帯における最大必要サーバ数とに基づき、予測対象の時間帯において必要とされる予測サーバ数を算出するステップと、
   前記予測サーバ数に基づき、トラフィックを処理するサーバの数を増減させるステップと
   を含む、サーバ制御方法。
8. プログラムを実行する演算部を備えるサーバ制御装置の演算部において実行されるサーバ制御プログラムであって、
   複数のノードとの通信において発生するトラフィックの少なくともデータ転送量に関する内容を示すトラフィック情報に基づき、所定の各時間帯において前記トラフィックを処理するために必要なサーバ数を算出する必要サーバ数算出処理と、
   前記所定の各時間帯において必要なサーバ数に基づき、連続する２つの時間帯におけるサーバ数の変化量を算出する変化量算出処理と、
   現在の時間帯から後続の予測対象の時間帯に移行した場合のサーバ数の予測変化量と、現在の時間帯における最大必要サーバ数とに基づき、予測対象の時間帯において必要とされる予測サーバ数を算出する予測サーバ数算出処理と、
   前記予測サーバ数に基づき、トラフィックを処理するサーバの数を増減させる動作状態制御処理と
   を実行する、サーバ制御プログラム。

Images