JP6511006B2

JP6511006B2 - リソース割当管理装置および割当て先サーバ決定方法

Info

Publication number: JP6511006B2
Application number: JP2016088931A
Authority: JP
Inventors: 弘之栗田
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2016-04-27
Filing date: 2016-04-27
Publication date: 2019-05-08
Anticipated expiration: 2036-04-27
Also published as: JP2017199176A

Description

本発明は、サーバ（以下。「汎用サーバ」と表記する場合がある）が実行するネットワーク機能（以下、「ＮＷ（network）機能」と表記する場合がある）が使用するリソースを管理する技術に関する。

従来、専用のハードウェア装置で実現されてきたＮＷ機能、例えば、ファイアウォールやＷＡＮ（Wide Area Network）高速化機能などをソフトウェア化し、汎用サーバ上で動作させることが行われつつある。このとき一般に複数のＮＷ機能が１台の汎用サーバ上で動作し、それらＮＷ機能は汎用サーバ上のリソース、例えばＣＰＵ（Central Processing Unit）コアやメモリ、ディスクＩＯ（Input Output）帯域などを分け合って使用する。

ＮＷ機能が使用するリソースの量は多様であり、上述のような汎用サーバ上の複数種類のリソースのうち、どの種類のリソースを相対的に多く使用するか、使用されるリソースの種類間の偏りの度合い、などはさまざまである。例えば、トラフィック1Gbpsあたり、ＣＰＵを８コア、メモリを2GB使用するＮＷ機能もあれば、ＣＰＵを２コア、メモリを16GB使用するようなＮＷ機能もある、などである。

このような状況において、サーバに割り当てるユーザが使用するＮＷ機能に偏りがあった場合、つまり例えば、相対的にＣＰＵコアを多く使用するＮＷ機能を利用するユーザを１つのサーバに数多く割り当ててしまった場合、汎用サーバのリソースのうち、ＣＰＵコアだけが全て使われている一方でメモリやディスクＩＯ容量は余るといった状況が生じる。現行の汎用サーバでは、複数のサーバを跨いでリソースを融通しあう技術はなく、このように余ってしまったリソースを有効に活用することはできない。このため、サーバリソースを有効に活用できず、ユーザへのサービス提供に必要なサーバ数を増やすなどして対処せざるを得ず、コストの増大を招くという課題がある。
なお、「サーバにユーザを割り当てる」とは、ユーザへのサービス提供に必要なＮＷ機能が使用するリソースを、そのＮＷ機能を備えるサーバに割り当てる、という意味である。

サーバの負荷の均等化を目的とした負荷分散技術としては様々な方式が存在する。例えば、特許文献１では、メディアサーバに対して必要リソース量の異なる要求がある中で、サーバの負荷の偏りを小さくする技術が開示されている。

特開２０１３−１３００４号公報

しかし、特許文献１で考慮されているリソースの種類は単一であり、上述のような複数種類のリソース間での利用率の偏りに起因するサーバリソース利用効率の低下という課題は解決されない。

このような事情に鑑みて、本発明は、複数種類のネットワーク機能が動作するサーバのリソース利用効率を向上させ、ユーザへのサービス提供に必要なサーバ数を低減させることを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、複数種類のＮＷ機能が動作するサーバのリソースを管理するリソース割当管理装置であって、前記サーバごと、かつ、前記リソースの種類ごとに、前記リソースの未使用率を記憶するサーバリソース利用状況テーブル、を記憶する記憶部と、ユーザ追加要求があった場合、追加ユーザが利用するＮＷ機能の提供に必要な要求リソース量を算出し、前記算出した要求リソース量以上の空きリソース量を持つサーバが存在するか否かを判定するために前記サーバリソース利用状況テーブルを検索し、前記検索によって該当するサーバが存在する場合には、当該サーバごとに、前記追加ユーザの当該サーバへの割当てに関する、割当前未使用リソース偏りおよび割当後未使用リソース偏りを算出し、前記算出した割当後未使用リソース偏りが所定の閾値以下となり、かつ、前記追加ユーザの割当て前後で未使用リソース偏りが最も改善されるサーバを、前記追加ユーザの割当て先サーバとして決定する、制御部と、を備える、ことを特徴とする。

また、請求項３に記載の発明は、複数種類のＮＷ機能が動作するサーバのリソースを管理するリソース割当管理装置における割当て先サーバ決定方法であって、前記リソース割当管理装置が、ユーザ追加要求があった場合、追加ユーザが利用するＮＷ機能の提供に必要な要求リソース量を算出するステップと、前記算出した要求リソース量以上の空きリソース量を持つサーバが存在するか否かを判定するために、前記サーバごと、かつ、前記リソースの種類ごとに、前記リソースの未使用率を記憶するサーバリソース利用状況テーブルを検索するステップと、前記検索によって該当するサーバが存在する場合には、当該サーバごとに、前記追加ユーザの当該サーバへの割当てに関する、割当前未使用リソース偏りおよび割当後未使用リソース偏りを算出するステップと、前記算出した割当後未使用リソース偏りが所定の閾値以下となり、かつ、前記追加ユーザの割当て前後で未使用リソース偏りが最も改善されるサーバを、前記追加ユーザの割当て先サーバとして決定するステップと、を実行する、ことを特徴とする。

請求項１，３に記載の発明によれば、複数種類のリソースを対象にした未使用リソース偏りという値を導入することで、十分な空きリソース量を持つサーバのうち、複数種類のリソース間での利用率の偏りに起因するサーバリソース利用効率の低下の抑制に資するサーバを決定することができる。
したがって、複数種類のネットワーク機能が動作するサーバのリソース利用効率を向上させ、ユーザへのサービス提供に必要なサーバ数を低減させることができる。

また、請求項２に記載の発明は、請求項１に記載のリソース割当管理装置であって、前記制御部は、前記検索によって該当するサーバが存在しない場合、または、前記該当するサーバが存在しても前記割当後未使用リソース偏りが前記所定の閾値以下とならない場合、サーバプール中のすべてのサーバのうち、前記追加ユーザの割当後未使用リソース偏りが最小となるサーバを、前記追加ユーザが割り当てられる追加サーバとして決定する、ことを特徴とする。

請求項２に記載の発明によれば、十分な空きリソース量を持つサーバが存在しない場合には、次善の策として、追加ユーザ割当て後の未使用リソース偏りが最小となるサーバを追加することで、ユーザへのサービス提供に必要なサーバ数の増大を最小限に抑えることができる。

本発明によれば、複数種類のネットワーク機能が動作するサーバのリソース利用効率を向上させ、ユーザへのサービス提供に必要なサーバ数を低減させることができる。

本実施形態のシステムの機能構成図の例である。リソース割当管理サーバの機能構成図の例である。ＮＷ機能使用リソース量テーブルのデータ構造図の例である。サーバリソース利用状況テーブルのデータ構造図の例である。ユーザ情報テーブルのデータ構造図の例である。サーバ保有リソース量テーブルのデータ構造図での例ある。ユーザ追加処理のシーケンスの例である。割当てサーバ決定処理のフローチャートの例である。未使用リソース偏りの算出例を示す表である。追加サーバ決定処理のフローチャートの例である。ユーザ削除処理のシーケンスの例である。

本発明の好適な例となる実施形態について、図面を参照しながら詳細に説明する。

≪全体構成≫
図１に示すように、本実施形態のシステムは、複数のクライアント端末１１，１２，１３，・・・と、オペレータ端末２０と、リソース割当管理サーバ３０（リソース割当管理装置）と、インフラ管理サーバ４０と、トラフィック振り分け装置５０と、複数のＮＷ機能サーバ６１，６２，６３，・・・とを備える。クライアント端末１１，１２，１３，・・・と、オペレータ端末２０と、リソース割当管理サーバ３０と、インフラ管理サーバ４０と、トラフィック振り分け装置５０と、複数のＮＷ機能サーバ６１，６２，６３，・・・は、ＩＰ（Internet Protocol）ネットワーク７１，７２によって通信可能に接続されている。説明の便宜上、「ＮＷ機能サーバ」を単に「サーバ」と呼ぶ場合がある。

クライアント端末１１，１２，１３，・・・と、オペレータ端末２０と、リソース割当管理サーバ３０と、インフラ管理サーバ４０と、トラフィック振り分け装置５０と、複数のＮＷ機能サーバ６１，６２，６３，・・・は、記憶部、制御部、通信部、入力部、出力部といったハードウェアを備えたコンピュータである。制御部は、例えば、記憶部に記憶されているプログラムを記憶部の記憶領域に展開し実行することにより、さまざまな処理を実行することができる。本実施形態のシステムは、このようなソフトウェアとハードウェアの協働を実現することができる。

クライアント端末１１，１２，１３，・・・は、ユーザが、通信キャリアの提供するネットワークサービスを利用するために使用する汎用端末である。クライアント端末１１，１２，１３，・・・は、例えば、スマートフォン、タブレット端末、携帯電話である。

オペレータ端末２０は、通信キャリアのオペレータが使用する汎用端末である。オペレータ端末２０は、リソース割当管理サーバ３０に対して、新たなユーザへのＮＷ機能の提供の要求や、解約ユーザに提供していたＮＷ機能の解除の要求を行うことができる。

リソース割当管理サーバ３０は、複数のＮＷ機能サーバ６１，６２，６３，・・・のリソースを管理する汎用サーバ装置である。リソース割当管理サーバ３０の詳細は後記する。

インフラ管理サーバ４０は、データセンタに設置されているすべてのサーバ、つまり、データセンタが提供するサーバプール中のすべてのサーバの使用状況、および各サーバのリソース情報を保持、管理する汎用サーバ装置である。

トラフィック振り分け装置５０は、リソース割当管理サーバ３０からの要求に応じて、クライアント端末１１，１２，１３，・・・から送信されたユーザトラフィック（単に、「トラフィック」と呼ぶ場合がある）を、ユーザごとに割り当てられているＮＷ機能サーバ６１，６２，６３，・・・に振り分ける、つまり転送する汎用ＩＰパケット転送装置である。トラフィック振り分け装置５０は、トラフィックの振り分け先となるユーザは、当該ユーザが使用するクライアント端末のＩＰアドレスによって識別することができる。

ＮＷ機能サーバ６１，６２，６３，・・・は、ユーザトラフィックに対して、オペレータ端末２０から送信される要求によって指定されたＮＷ機能（単体の場合もあるし組み合わせの場合もある）を提供する汎用サーバ装置である。

本実施形態において、ＮＷ機能サーバ６１，６２，６３，・・・が提供する複数種類のＮＷ機能は、プロセスまたはスレッドで実現されるとする。これにより、本実施形態のＮＷ機能の各々は、トラフィック量に応じて、ＮＷ機能サーバ６１，６２，６３，・・・内で柔軟にスケールインしたりスケールアウトしたりすることができる。つまり、本実施形態のＮＷ機能の各々の使用リソース量を可変とすることができる。その結果、ユーザの割当て先となるサーバを調整したり、ＮＷ機能の使用リソース量を動的に調整したりすることができる。なお、ＮＷ機能の各々の使用リソース量を可変とすることができるのであれば、ＮＷ機能を仮想マシンで実現してもよい。

［リソース割当管理サーバ３０の詳細］
図２に示すように、リソース割当管理サーバ３０は、ユーザ追加要求受付部３１と、割当て先サーバ決定部３２と、サーバリソース情報取得部３３と、振り分け設定変更要求部３４といった機能部を備える。また、リソース割当管理サーバ３０は、ＮＷ機能使用リソース量テーブルｔ１と、サーバリソース利用状況テーブルｔ２と、ユーザ情報テーブルｔ３といった管理用のテーブルを記憶する。また、インフラ管理サーバ４０は、サーバ保有リソース量テーブルｔ４といった管理用のテーブルを記憶する。

ユーザ追加要求受付部３１は、オペレータ端末２０から送信されるユーザ追加要求を受け付ける。ユーザ追加要求は、特定のサーバに割り当てられることになる新たなユーザ（追加ユーザ）を追加することを通知する要求である。
割当て先サーバ決定部３２は、追加ユーザの割当て先となるサーバを割当て先サーバとして決定する。割当て先サーバの決定方法の詳細は、後記する。
サーバリソース情報取得部３３は、インフラ管理サーバ４０が保持する、利用可能なサーバのリソース情報を取得する。
振り分け設定変更要求部３４は、割当て先サーバ決定部３２が決定した割当て先サーバにユーザを割り当てるための所定の設定をトラフィック振り分け装置５０に要求する。

（ＮＷ機能使用リソース量テーブルｔ１）
ＮＷ機能使用リソース量テーブルｔ１は、サーバが提供する各種ＮＷ機能が動作するときの使用リソース量を記載したテーブルである。
図３に示すように、ＮＷ機能使用リソース量テーブルｔ１は、例えば、１Ｇｂｐｓ当たりの使用リソース量として「ＣＰＵコア数」欄と、「メモリ量［ＧＢ］」欄といった項目を有し、ＮＷ機能（図３では、Ａ〜Ｅ）ごとにエントリを作成している。

「ＣＰＵコア数」欄には、トラフィック１Ｇｂｐｓを処理するのに使用するＣＰＵのコア数が格納される。
「メモリ量［ＧＢ］」欄には、トラフィック１Ｇｂｐｓを処理するのに使用するメモリ量の数値がＧｂｙｔｅｓ単位で格納される。

例えば、ユーザ追加要求に含まれるＮＷ機能がＡ，Ｂ，Ｃであり、利用する帯域が２Ｇｂｐｓであったとき、ＮＷ機能の提供に必要となるリソース量（要求リソース量）は、ＣＰＵコア数：１０（＝(2+2+1)*2）、メモリ量：２０ＧＢ（＝(5+2+3)*2）となる。
なお、本実施形態では簡単のため、リソース割当管理サーバ３０が管理するリソースの種類としてはＣＰＵおよびメモリを採り上げるが、リソースの種類としてはこれらに限定されず、例えば、ディスクＩＯ（Input Output）を扱うようにしてもよい。

（サーバリソース利用状況テーブルｔ２）
サーバリソース利用状況テーブルｔ２は、サーバリソースが現在どの程度利用されているかをサーバごとに管理するテーブルである。
図４に示すように、サーバリソース利用状況テーブルｔ２は、「保有リソース」欄と、「未使用リソース」欄と、「未使用リソース率」欄といった項目を有し、サーバ（図４では、W_1,X_1,X_2,Y_1）ごとにエントリを作成している。

「保有リソース」欄には、サーバが保有するリソース量、つまり、サーバへの割当リソース量がリソースの種類（ＣＰＵおよびメモリ）ごとに格納される。保有リソース量は、使用リソース量と未使用リソース量の和に等しい。
「未使用リソース」欄には、サーバが保有するリソース量のうち未使用分の量がリソースの種類（ＣＰＵおよびメモリ）ごとに格納される。
「未使用リソース率」欄には、保有リソース量に対する未使用リソース量の割合（％）がリソースの種類（ＣＰＵおよびメモリ）ごとに格納される。

例えば、図４中の使用中のサーバ４台（W_1,X_1,X_2,Y_1）についていずれも、未使用リソース量が、図３から導き出される要求リソース量（ＣＰＵコア数：１０、メモリ量：２０ＧＢ）を上回ることが分かる。

（ユーザ情報テーブルｔ３）
ユーザ情報テーブルｔ３は、通信キャリアの提供するサービスを利用するユーザのサービス利用形態を管理するテーブルである。
図５に示すように、ユーザ情報テーブルｔ３は、「利用ＮＷ機能」欄と、「利用帯域」欄と、「ＩＰアドレス」欄と、「割当て先サーバ」欄といった項目を有し、ユーザ（図５では、User1,User2,User3）ごとにエントリを作成している。

「利用ＮＷ機能」欄には、ユーザがサービスを享受するときに利用するＮＷ機能の識別子が格納される。
「利用帯域」欄には、ユーザが利用可能となる帯域量が格納される。
「ＩＰアドレス」欄には、ユーザが使用するクライアント端末に割り当てられたＩＰアドレスが格納される。ＩＰアドレスはユーザの識別情報として機能する。
「割当て先サーバ」欄には、ユーザについて、割当て先サーバ決定部３２が割当て先として決定したサーバの識別子（またはサーバ名）が格納される。

（サーバ保有リソース量テーブルｔ４）
サーバ保有リソース量テーブルｔ４は、サーバのリソースの空塞状態を管理するテーブルである。
図６に示すように、インフラ管理サーバ４０が管理するサーバ保有リソース量テーブルｔ４は、「保有リソース」欄と、「空塞情報」欄といった項目を有し、サーバごとにエントリを作成している。
「保有リソース」欄は、サーバリソース利用状況テーブルｔ２（図４）の「保有リソース」欄と同等である。
「空塞情報」欄には、対象サーバがサービスの提供のために使用中であるか（「塞」）、未使用であるか（「空」）を示す値が格納される。

≪処理≫
（ユーザ追加処理）
次に、本実施形態のシステムが行う処理について説明する。まず、ユーザが追加されたときのユーザ追加処理について説明する。
図７に示すように、ユーザ追加処理では、まず、オペレータ端末２０が、リソース割当管理サーバ３０に、ユーザ追加要求を送信する（ステップＳ１０１）。ユーザ追加要求には、新たに追加するユーザが利用するＮＷ機能のリスト（例えば、ＮＷ機能Ａ〜Ｃ）と、利用する帯域（例えば、２Ｇｂｐｓ）と、ユーザの使用するクライアント端末１１のＩＰアドレスなどの情報が含まれる。

ユーザ追加要求を受信したリソース割当管理サーバ３０は、割当て先サーバ決定処理を行う（ステップＳ１０２）。割当て先サーバ決定処理の詳細は後記する。結果的には、追加ユーザが割り当てられる割当て先サーバが決定される。

次に、リソース割当管理サーバ３０は、決定した割当て先サーバにユーザのトラフィックを振り分けるため、振り分け設定変更要求をトラフィック振り分け装置５０を送信する（ステップＳ１０７）。振り分け設定変更要求には、ユーザが使用するクライアント端末１１のＩＰアドレス、および、振り分け先のサーバ（つまり、割当て先サーバ）のＩＰアドレスが含まれる。

振り分け設定変更要求を受信したトラフィック振り分け装置５０は、振り分けに関する設定を自身に追加し、その設定が完了した旨を示す振り分け設定変更応答をリソース割当管理サーバ３０に送信する（ステップＳ１０８）。振り分け設定変更応答を受信したリソース割当管理サーバ３０は、ステップＳ１０１のユーザ追加要求に対応するユーザ追加応答をオペレータ端末２０に応答する（ステップＳ１０９）。

以降、クライアント端末１１から送信されるトラフィックは、トラフィック振り分け装置５０により、ステップＳ１０２の割当て先サーバ決定処理にて決定された割当て先サーバ（ここでは、ＮＷ機能サーバ６１とする）に振り分けられる（ステップＳ１１０，Ｓ１１１）。

以上の手順を経て、ユーザ追加処理が完了する。
なお、図７中ステップＳ１０３〜ステップＳ１０６については後記する。

（割当て先サーバ決定処理）
リソース割当管理サーバ３０が実行する、ステップＳ１０２の割当て先サーバ決定処理の詳細を説明する。
図８に示すように、割当て先サーバ決定処理では、まず、リソース割当管理サーバ３０が、ユーザ追加要求に記載されているＮＷ機能（のリスト）の提供に必要となるリソース量（要求リソース量）を、ＮＷ機能使用リソース量テーブルｔ１の内容に基づいて算出する（ステップＳ２０１）。なお、図８の説明において、ユーザ追加要求に含まれるＮＷ機能がＡ，Ｂ，Ｃであり、利用する帯域が２Ｇｂｐｓであるとする。よって、ＮＷ機能の提供に必要となるリソース量（要求リソース量）は、ＣＰＵコア数：１０（＝(2+2+1)*2）、メモリ量：２０ＧＢ（＝(5+2+3)*2）となる（図３参照）。

次に、リソース割当管理サーバ３０は、Ｓ２０１で算出したリソース量以上の空きリソースを持つサーバが存在するか否かを、サーバリソース利用状況テーブルｔ２から検索する（ステップＳ２０２）。もし、サーバリソース利用状況テーブルｔ２の検索によって該当するサーバが存在しない場合には、後記の追加サーバ決定処理（ステップＳ３００）を行う。

一方、サーバリソース利用状況テーブルｔ２の検索によって該当するサーバが存在する場合には、当該サーバごとに、追加ユーザを当該サーバに割り当てる前の未使用リソース偏りである割当前未使用リソース偏り、および、追加ユーザを当該サーバに（仮に）割り当てた後の未使用リソース偏りである割当後未使用リソース偏りを算出する（ステップＳ２０３）。リソースの種類がＣＰＵおよびメモリの２種類としたときの未使用リソース偏りＵは、下記式［１］によって算出される。

Ｕ＝ｍａｘ（Ｒ（ＣＰＵ），Ｒ（ＭＥＭ））／
ｍｉｎ（Ｒ（ＣＰＵ），Ｒ（ＭＥＭ））
・・・［１］
ここで、Ｒ（ＣＰＵ）は、ＣＰＵコアの未使用リソース率である。Ｒ（ＭＥＭ）は、メモリの未使用リソース率である。ｍａｘ（Ｒ（ＣＰＵ），Ｒ（ＭＥＭ））は、Ｒ（ＣＰＵ）およびＲ（ＭＥＭ）のうち大きい方を示す。ｍｉｎ（Ｒ（ＣＰＵ），Ｒ（ＭＥＭ））は、Ｒ（ＣＰＵ）およびＲ（ＭＥＭ）のうち小さい方を示す。

割当前未使用リソース偏りは、追加ユーザを対象サーバに割り当てる前のＲ（ＣＰＵ）およびＲ（ＭＥＭ）を用いて算出され、具体的には、図４のサーバリソース利用状況テーブルｔ２の未使用リソース率の値を用いて算出される。
割当後未使用リソース偏りは、追加ユーザを対象サーバに割り当てた後のＲ（ＣＰＵ）およびＲ（ＭＥＭ）を用いて算出される。具体的には、追加ユーザの要求リソース量を加味することで、図４のサーバリソース利用状況テーブルｔ２の未使用リソース量が更新されるため、この更新された未使用リソース量から算出される未使用リソース率の値を用いて、割当後未使用リソース偏りが算出される。

なお、一般的に、リソースの種類がｎ種類あるときの未使用リソース偏りＵ（ｎ）は、下記式［２］のようになる。
Ｕ（ｎ）＝ｍａｘ（Ｒ（１），Ｒ（２）,・・・，Ｒ（ｎ））／
ｍｉｎ（Ｒ（１），Ｒ（２）,・・・，Ｒ（ｎ））
・・・［２］
ここで、Ｒ（１），Ｒ（２）,・・・，Ｒ（ｎ）は、ｎ種類の未使用リソース率である。

割当前未使用リソース偏りＵｂおよび割当後未使用リソース偏りＵａを算出することで、リソース割当管理サーバ３０は、サーバごとに、未使用リソース改善率Ｉを算出することができる。例えば、未使用リソース改善率Ｉは、下記式［３］のようになる。
Ｉ＝（Ｕｂ−Ｕａ）／Ｕｂ
・・・［３］
式［３］による未使用リソース改善率の算出例を図９に示す。

該当サーバについてステップＳ２０３の処理を行った後、追加ユーザについて、割当後未使用リソース偏りが所定の閾値以下となるサーバが存在するか否か判定する（ステップＳ２０４）。存在しない場合は、未使用リソース偏りを抑制するため、使用中のサーバに追加ユーザを割り当てることはせず、後記の追加サーバ決定処理（ステップＳ３００）を行う。

一方、追加ユーザについて、割当後未使用リソース偏りが所定の閾値（例：３）以下となるサーバが存在する場合、追加ユーザを割り当てることによって未使用リソース偏りが最も改善されるサーバ、つまり、未使用リソース偏り改善率が最大となるサーバ（図９ではW_1）を追加ユーザの割当て先サーバとして決定する（ステップＳ２０５）。また、このとき、サーバリソース利用状況テーブルｔ２の該当サーバのエントリについて、未使用リソース（量）および未使用リソース率を、追加ユーザを割り当てた後の値に更新する。また、リソース割当管理サーバ３０は、ユーザ情報テーブルｔ３（図７）において、追加ユーザ（例：User3）のエントリを追加する。
以上の手順を経て、割当て先サーバ決定処理が完了する。

（追加サーバ決定処理）
リソース割当管理サーバ３０が実行する、ステップＳ３００の追加サーバ決定処理の詳細を説明する。
図１０に示すように、追加サーバ決定処理では、まず、リソース割当管理サーバ３０が、インフラ管理サーバ４０からサーバプールに存在するサーバ、つまり未使用状態のすべてのサーバについて保有リソース量を取得する（ステップＳ３０１）。この取得のために、リソース割当管理サーバ３０は、インフラ管理サーバ４０にサーバリソース情報取得要求を送信する（図７のステップＳ１０３）。また、インフラ管理サーバ４０は、自身が管理するサーバ保有リソース量テーブルｔ４（図６）において、空塞情報が「空」となっているサーバについて保有リソース量を、サーバリソース情報取得応答としてリソース割当管理サーバ３０に応答する（図７のステップＳ１０４）。

次に、リソース割当管理サーバ３０は、サーバリソース情報を取得したサーバのすべてについて、図８のステップＳ２０３と同様にして、追加ユーザを当該サーバに（仮に）割り当てた後の未使用リソース偏りである割当後未使用リソース偏りを算出する（ステップＳ３０２）。次に、リソース割当管理サーバ３０は、割当後未使用リソース偏りが最小となるサーバを、追加ユーザが割り当てられる追加サーバとして決定する（ステップＳ３０３）。

次に、リソース割当管理サーバ３０は、ステップＳ３０３にて決定した追加サーバの空塞情報の更新をインフラ管理サーバ４０に要求する（ステップＳ３０４）。この要求は、リソース割当管理サーバ３０がインフラ管理サーバ４０に送信するサーバリソース情報更新要求（図７のステップＳ１０５）に等しい。インフラ管理サーバ４０は、追加サーバについて、サーバ保有リソース量テーブルｔ４（図６）の空塞情報を「空」から「塞」に更新する。インフラ管理サーバ４０は、空塞情報の更新が完了したことを示すサーバリソース情報更新応答をリソース割当管理サーバ３０に送信する（図７のステップＳ１０６）。
以上の手順を経て、追加サーバ決定処理が完了する。

（ユーザ削除処理）
ユーザがサービスを解約したなどの場合には、リソース割当管理サーバ３０はユーザ削除処理を実行する。
図１１に示すように、ユーザ削除処理では、まず、オペレータ端末２０が、リソース割当管理サーバ３０に、ユーザ削除要求を送信する（ステップＳ１０１）。ユーザ削除要求には、削除ユーザのユーザ名が含まれる。ユーザ削除要求を受信したリソース割当管理サーバ３０は、ユーザ情報テーブルｔ３（図５）から、当該ユーザが割り当てられているサーバと、当該ユーザが利用しているＮＷ機能を参照し、サーバリソース利用状況テーブルｔ２（図４）に対して、当該ユーザが使用している分のリソースを未使用リソースに加算する更新を行う。

また、リソース割当管理サーバ３０は、削除ユーザへのトラフィックの振り分けを解除するため、振り分け設定変更要求をトラフィック振り分け装置５０に送信する（ステップＳ３０２）。振り分け設定変更要求を受信したトラフィック振り分け装置５０は、当該ユーザへの振り分け設定を解除し、その解除が完了したことを示す振り分け設定変更応答をリソース割当管理サーバ３０に送信する（ステップＳ３０３）。振り分け設定変更応答を受信したリソース割当管理サーバ３０は、ユーザ削除要求に対応するユーザ削除応答をオペレータ端末２０に送信する（ステップＳ３０４）。
以上の手順を経て、ユーザ削除処理が完了する。

≪まとめ≫
本実施形態によれば、複数種類のリソースを対象にした未使用リソース偏りという値を導入することで、十分な空きリソース量を持つサーバのうち、複数種類のリソース間での利用率の偏りに起因するサーバリソース利用効率の低下の抑制に資するサーバを決定することができる。
したがって、複数種類のネットワーク機能が動作するサーバのリソース利用効率を向上させ、ユーザへのサービス提供に必要なサーバ数を低減させることができる。

また、十分な空きリソース量を持つサーバが存在しない場合には、次善の策として、追加ユーザ割当て後の未使用リソース偏りが最小となるサーバを追加することで、ユーザへのサービス提供に必要なサーバ数の増大を最小限に抑えることができる。

本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）〜（ｃ）のようなものがある。
（ａ）：本実施形態では、リソース割当管理サーバ３０とインフラ管理サーバ４０とは別体のサーバ装置であるとしたが、両サーバ３０，４０を合わせた一体のサーバ装置としてもよい。
（ｂ）：本実施形態のシステムは、トラフィック振り分け装置５０を介して、２つのＩＰネットワーク７１，７２を用いて構築したが、１つのＩＰネットワークを用いて、クライアント端末１１，１２，１３，・・・と、オペレータ端末２０と、リソース割当管理サーバ３０と、インフラ管理サーバ４０と、トラフィック振り分け装置５０と、複数のＮＷ機能サーバ６１，６２，６３，・・・が通信可能に接続されたシステムを構築することもできる。
（ｃ）：また、本実施形態では、未使用リソース偏りの改善率が最大のサーバをユーザの割当て先サーバとして決定したが、未使用リソース偏りが多少なりとも改善されるサーバの中で、割当前未使用リソース偏りが最も大きいサーバを、当該ユーザの割当て先サーバとすることで、未使用リソース偏りが最大のサーバの未使用リソース偏りを改善する方式をとってもよい。

また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
また、本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、処理手順などについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１１，１２，１３クライアント端末
２０オペレータ端末
３０リソース割当管理サーバ（リソース割当管理装置）
４０インフラ管理サーバ
５０トラフィック振り分け装置
６１，６２，６３ＮＷ機能サーバ（サーバ）
７１，７２ＩＰネットワーク

Claims

複数種類のＮＷ機能が動作するサーバのリソースを管理するリソース割当管理装置であって、
前記サーバごと、かつ、前記リソースの種類ごとに、前記リソースの未使用率を記憶するサーバリソース利用状況テーブル、を記憶する記憶部と、
ユーザ追加要求があった場合、追加ユーザが利用するＮＷ機能の提供に必要な要求リソース量を算出し、
前記算出した要求リソース量以上の空きリソース量を持つサーバが存在するか否かを判定するために前記サーバリソース利用状況テーブルを検索し、
前記検索によって該当するサーバが存在する場合には、当該サーバごとに、前記追加ユーザの当該サーバへの割当てに関する、割当前未使用リソース偏りおよび割当後未使用リソース偏りを算出し、
前記算出した割当後未使用リソース偏りが所定の閾値以下となり、かつ、前記追加ユーザの割当て前後で未使用リソース偏りが最も改善されるサーバを、前記追加ユーザの割当て先サーバとして決定する、制御部と、を備える、
ことを特徴とするリソース割当管理装置。
前記制御部は、
前記検索によって該当するサーバが存在しない場合、または、前記該当するサーバが存在しても前記割当後未使用リソース偏りが前記所定の閾値以下とならない場合、サーバプール中のすべてのサーバのうち、前記追加ユーザの割当後未使用リソース偏りが最小となるサーバを、前記追加ユーザが割り当てられる追加サーバとして決定する、
ことを特徴とする請求項１に記載のリソース割当管理装置。
複数種類のＮＷ機能が動作するサーバのリソースを管理するリソース割当管理装置における割当て先サーバ決定方法であって、
前記リソース割当管理装置が、
ユーザ追加要求があった場合、追加ユーザが利用するＮＷ機能の提供に必要な要求リソース量を算出するステップと、
前記算出した要求リソース量以上の空きリソース量を持つサーバが存在するか否かを判定するために、前記サーバごと、かつ、前記リソースの種類ごとに、前記リソースの未使用率を記憶するサーバリソース利用状況テーブルを検索するステップと、
前記検索によって該当するサーバが存在する場合には、当該サーバごとに、前記追加ユーザの当該サーバへの割当てに関する、割当前未使用リソース偏りおよび割当後未使用リソース偏りを算出するステップと、
前記算出した割当後未使用リソース偏りが所定の閾値以下となり、かつ、前記追加ユーザの割当て前後で未使用リソース偏りが最も改善されるサーバを、前記追加ユーザの割当て先サーバとして決定するステップと、を実行する、
ことを特徴とする割当て先サーバ決定方法。