JP4905120B2 - 負荷集約プログラム、該プログラムを記録した記録媒体、負荷集約装置および負荷集約方法 - Google Patents

Description

この発明は、複数のリソースに分散した負荷を集約する負荷集約プログラム、該プログラムを記録した記録媒体、負荷集約装置および負荷集約方法に関する。

従来、システムの構成に柔軟性がないために、処理能力の増強に多額の追加投資が必要になる場合がある。たとえば、ビジネスの状況の変化とともに必要なピーク性能が高くなり、追加の計算資源を余儀なくされている。逆に突発的な負荷上昇を見越して予め大量の予備のリソースを確保することもあるが、多くの場合無駄遣いになっている。

このため、資源利用者の優先度に基づく計算資源（以下、「リソース」という）の割り振りをおこなう、あるいは、リソースの解放を依頼された資源利用者がリソースを解放することにより、当該リソースを有効に使い回す技術が提案されている（たとえば、下記特許文献１参照。）。

また、優先度の低いサービスを強制待ち状態に遷移させ、この優先度の低いサービスに割り振られていたリソースを優先度の高いサービスに割り振ることにより、リソースを有効に利用する技術が提案されている（たとえば、下記特許文献２参照。）。

特開平１０−９７４３５号公報 特開平０５−１２００４１号公報

しかしながら、上述した特許文献１および特許文献２の従来技術では、あるサービスに複数のリソースが利用されている状況下で当該サービスの負荷が減少すると、各リソースに割り当てられている負荷が均等に減少し、サービスの負荷が複数のリソースに分散しすぎてしまう場合がある。

すなわち、サービスの負荷の減少にともなって、複数のリソースに割り当てられている負荷をどのように減少させるかについては想定されていないため、たとえば、少ない負荷が各リソースに均等に割り当てられた状態となってしまい、すべてのリソースにサービスの負荷が残ってしまう。

また、あるサービスに利用されているリソースを、他のサービスに利用されるリソースとして切り替えるためには、実行中のサービスを完全に停止したあとに、他のサービスに切り替えることが望ましい。

このため、すべてのリソースにサービスの負荷が残っている状態では、どのリソースを切り替え対象として選択した場合であっても、実行中のサービスを停止する時間的なコストがかかってしまい、結果的に他のサービスの提供に時間がかかってしまうという問題があった。

この発明は、上述した従来技術による問題点を解消するため、効率的なリソース融通を可能とすることにより、個々のサービスの円滑な提供を実現することができる負荷集約プログラム、該プログラムを記録した記録媒体、負荷集約装置および負荷集約方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、この発明にかかる負荷集約プログラム、該プログラムを記録した記録媒体、負荷集約装置および負荷集約方法は、サービスに利用されているリソースごとの負荷情報を取得し、この負荷情報に基づいて、並列に実行されているサービスの負荷が当該サービスに割り振られている複数のリソースに、どのように分散されて割り当てられているかを示す指標値を算出し、この算出結果に基づいて、前記複数のリソースに分散している前記サービスの負荷を集約させるか否かを判定し、前記サービスの負荷を集約させると判定された場合、当該サービスに利用されている複数のリソースの中から一のリソースを検出し、一のリソースの負荷を当該一のリソース以外の他のリソースに割り当てることを特徴とする。

この発明によれば、一のリソースの負荷を他のリソースに割り当てることにより、サービスの負荷を集約させることができる。

また、上記発明において、複数のリソースのうち所定の閾値よりも少ない負荷のリソースの数を算出することとしてもよい。

この発明によれば、サービスに利用されている複数のリソースにおける負荷の少ないリソースの割合から、負荷集約の要否を適切に判定することができる。

また、上記発明において、サービスに利用されている複数のリソースの負荷平均を算出することとしてもよい。

この発明によれば、サービスに利用されている複数のリソースの負荷平均から、負荷集約の要否を適切に判定することができる。

また、上記発明において、サービスに利用されている複数のリソースの中から最も負荷の少ない一のリソースを検出することとしてもよい。

この発明によれば、一のリソースの負荷を他のリソースに割り当てる際の時間的なコストを削減することができ、サービスの負荷を効率的に集約させることができる。

また、上記発明において、一のリソースの負荷を、当該一のリソースの負荷と同等あるいはそれ以上の負荷が割り当てられている他のリソースに割り当てることとしてもよい。

この発明によれば、一のリソースの負荷を他のリソースに割り当てることによって、サービスの負荷がさらに分散してしまうことを防ぐことができ、当該サービスの負荷を効率的に集約させることができる。

また、上記発明において、前記他のリソースに割り当て可能な負荷の許容量を算出し、この許容量と前記一のリソースの負荷とを比較することにより、前記他のリソースの中から前記一のリソースの負荷と適合する許容量のリソースを決定し、前記一のリソースの負荷を決定されたリソースに割り当てることとしてもよい。

この発明によれば、個々のリソースの処理能力を最大限に利用したサービスの実行をおこなうことができ、当該サービスの負荷をより効率的に集約させることができる。

本発明にかかる負荷集約プログラム、該プログラムを記録した記録媒体、負荷集約装置および負荷集約方法によれば、効率的なリソース融通を可能とすることにより、個々のサービスの円滑な提供を実現することができるという効果を奏する。

以下に添付図面を参照して、この発明にかかる負荷集約プログラム、該プログラムを記録した記録媒体、負荷集約装置および負荷集約方法の好適な実施の形態を詳細に説明する。

（リソース融通システムのシステム構成図）
まず、この発明の実施の形態にかかるリソース融通システムのシステム構成について説明する。図１は、この発明の実施の形態にかかるリソース融通システム１００のシステム構成図である。図１において、リソース融通システム１００は、負荷集約装置１０１と、各サイトＣに設置されているリソース１０２とが、ネットワーク１１０を介して通信可能に接続されている。

負荷集約装置１０１は、複数のサービス間で利用されるリソース１０２をブローカリングするとともに、各リソース１０２に割り当てる負荷を管理するコンピュータ装置である。また、負荷集約装置１０１は、リソース１０２ごとの負荷情報を記憶する負荷情報ＤＢ１０３を備えている。

具体的には、負荷集約装置１０１は、要求されるサービスに応じて、どのサイトＣのどのリソース１０２を割り振るかを決定したり、あるサービスを提供しているあるサイトＣのリソース１０２を他のサービスに割り振ったりする。

また、負荷集約装置１０１は、負荷情報ＤＢ１０３に記憶されているリソース１０２ごとの負荷情報に基づいて、各リソース１０２に割り当てるサービスの負荷を管理する。具体的には、サービスに利用されているリソース１０２に割り当てる負荷を適切に調整することにより、サービスの負荷が分散しすぎてしまうことを防ぐ。負荷情報ＤＢ１０３についての詳細な説明は後述する。

リソース１０２は、各サイトＣに設置されており、サービスを実行するために利用されるコンピュータ装置である。具体的には、リソース１０２は、負荷集約装置１０１によって割り振られたサービスを端末（不図示）に提供する。

（コンピュータ装置のハードウェア構成）
つぎに、図１に示したコンピュータ装置のハードウェア構成について説明する。図２は、図１に示したコンピュータ装置のハードウェア構成を示すブロック図である。図２において、コンピュータ装置は、ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、ＨＤＤ（ハードディスクドライブ）２０４と、ＨＤ（ハードディスク）２０５と、ＦＤＤ（フレキシブルディスクドライブ）２０６と、着脱可能な記録媒体の一例としてのＦＤ（フレキシブルディスク）２０７と、ディスプレイ２０８と、Ｉ／Ｆ（インターフェース）２０９と、キーボード２１０と、マウス２１１と、スキャナ２１２と、プリンタ２１３とを備えている。また、各構成部は、バス２００によってそれぞれ接続されている。

ここで、ＣＰＵ２０１は、コンピュータ装置の全体の制御を司る。ＲＯＭ２０２は、ブートプログラムなどのプログラムを記録している。ＲＡＭ２０３は、ＣＰＵ２０１のワークウェアとして使用される。ＨＤＤ２０４は、ＣＰＵ２０１の制御にしたがってＨＤ２０５に対するデータのリード／ライトを制御する。ＨＤ２０５は、ＨＤＤ２０４の制御で書き込まれたデータを記憶する。

ＦＤＤ２０６は、ＣＰＵ２０１の制御にしたがってＦＤ２０７に対するデータのリード／ライトを制御する。ＦＤ２０７は、ＦＤＤ２０６の制御で書き込まれたデータを記憶したり、ＦＤ２０７に記憶されたデータをコンピュータ装置に読み取らせたりする。

また、着脱可能な記録媒体として、ＦＤ２０７のほか、ＣＤ−ＲＯＭ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、ＭＯ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、メモリカードなどであってもよい。ディスプレイ２０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ２０８には、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

Ｉ／Ｆ２０９は、通信回線を通じてインターネットなどのネットワーク１１０に接続され、このネットワーク１１０を介して他の装置に接続される。そして、Ｉ／Ｆ２０９は、ネットワーク１１０と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ２０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

キーボード２１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス２１１は、カーソルの移動や範囲選択、あるいはウインドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様の機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ２１２は、画像を光学的に読み取り、装置内に画像データを読み込む。なお、スキャナ２１２は、ＯＣＲ機能を持たせてもよい。また、プリンタ２１３は、画像データや文書データを印刷する。プリンタ２１３には、たとえば、レーザプリンタやインクジェットプリンタなどを採用することができる。

（負荷情報ＤＢ１０３の記憶内容）
つぎに、図１に示した負荷情報ＤＢ１０３の記憶内容について説明する。図３は、負荷情報ＤＢ１０３の記憶内容を示す説明図（その１）である。図３において、負荷情報ＤＢ１０３には、リソースＩＤごとにサービス情報およびリソース情報からなる負荷情報が記憶されている。

ここで、リソースＩＤ：ｉ（ｉ＝１〜Ｎ）とは、ネットワーク１１０を介して負荷集約装置１０１と通信可能に接続されている複数のリソース１０２のうち、どのリソース１０２かを特定する識別情報である。また、各リソースＩＤには、サービス情報およびリソース情報が関連付けられている。

サービス情報には、サービス名、サービス数およびサービスパワーに関する情報が含まれている。サービス名は、各リソース１０２に割り振られているサービスの名称である。サービスとは、リソース１０２のコンピュータ端末に提供する情報処理であり、たとえば、シミュレーションジョブのバッチ処理などの非インタラクティブなサービスやインターネット電話やテレビ会議システムといったインタラクティブなサービスがある。

サービス数は、各サービスについて要求されているサービスの数である。たとえば、５つの地域間を結ぶテレビ会議システムを提供するためには、少なくともサービスの数が５つ必要となる。サービスパワーは、１つのサービスを実行するために各リソース１０２で必要となるＣＰＵ性能やメモリ容量などの処理能力を数値的にあらわした指標である。

また、リソース情報には、リソースパワー、実行可能なサービス数および実行中のサービス数に関する情報が含まれている。リソースパワーは、各リソース１０２のＣＰＵ性能やメモリ容量などの処理能力を数値的にあらわす指標である。ここでは、サービスパワーおよびリソースパワーを統一的な指標によってあらわすこととする。

実行可能なサービス数は、各リソース１０２において並列に実行することができる最大数のサービスの数である。具体的には、たとえば、あるリソース１０２のリソースパワーが「１００」であり、一つのサービスを実行するために必要となるサービスパワーが「３０」であった場合、実行可能なサービス数は「３」となる。

実行中のサービス数は、各リソース１０２において現在実行中のサービスの数をあらわしている。具体的には、負荷集約装置１０１により、要求されているサービスの負荷に応じて、各リソース１０２にサービスが割り振られることとなる。

ここで、リソースＩＤ：３のリソース１０２を例に挙げると、サービス情報として、利用されているサービスのサービス名：サービスＢ、そのサービスＢについて要求されているサービス数：４、１つのサービスＢを実行するために必要となるサービスパワー：３０が示されている。

また、リソース情報として、リソースパワー：１００、並列に実行可能なサービスＢの数：３、現在実行中のサービスＢの数：２が示されている。なお、各リソース１０２の負荷情報は、時間の経過にともなって動的に変化するため、負荷情報ＤＢ１０３の記憶内容は一定時間ごとに更新されるようにしてもよい。

（負荷集約装置１０１の機能的構成）
つぎに、この発明の実施の形態にかかる負荷集約装置１０１の機能的構成について説明する。図４は、この発明の実施の形態にかかる負荷集約装置１０１の機能的構成を示すブロック図である。図４において、負荷集約装置１０１は、負荷情報ＤＢ１０３と、取得部４０１と、算出部４０２と、判定部４０３と、検出部４０４と、割当部４０５とを備えている。

取得部４０１は、サービスに利用されているリソース１０２ごとの負荷情報を取得する機能を有する。負荷とは、サービスの実行にともなう各リソース１０２でのＣＰＵ使用率、メモリ使用量およびネットワーク帯域の利用率（トラフィック）などを統一的にあらわした指標である。

また、負荷情報は、各リソース１０２に割り当てられているサービスの負荷に関する情報であり、時間の経過にともなって動的に変化する情報である。たとえば、上述したサービス情報やリソース情報（図３参照）などである。

具体的には、取得部４０１は、ネットワーク１１０を介して各リソース１０２から負荷情報を取得してもよく、また、各サービスに関する情報（たとえば、サービスに利用されている各リソース１０２の負荷やリソース１０２の割り振り状態）の収集と提供をおこなうコンピュータ装置から取得してもよい。

取得部４０１によって取得された負荷情報は負荷情報ＤＢ１０３に格納される。また、各リソース１０２の負荷情報は、時間の経過にともなって動的に変化するため、一定時間ごとに取得され、その都度、負荷情報ＤＢ１０３に記憶される。なお、取得部４０１によって取得される負荷情報は、ＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶されることとしてもよい。

具体的には、取得部４０１により、予め設定されている一定時間ごとに送信されてくる負荷情報を取得することとしてもよい。また、取得部４０１により、各リソース１０２に負荷情報の送信要求をおこなうことによって負荷情報を取得することとしてもよい。

なお、取得部４０１は、負荷情報ＤＢ１０３に記憶される負荷情報のうち、動的に変化する一部の情報（サービス数、サービスパワーなど）のみを取得することとしてもよい。この場合、その他の静的な情報（各リソース１０２のリソースパワーなど）は予め負荷情報ＤＢ１０３に記憶されていてもよい。

算出部４０２は、取得部４０１によって取得された負荷情報に基づいて、サービスに利用されているリソース間の負荷分散の割合を算出する機能を有する。具体的には、算出部４０２は、負荷情報ＤＢ１０３から各リソース１０２の負荷情報を読み出し、その負荷情報に基づく負荷分散の割合を所定の価値基準を用いて算出する。また、算出部４０２は、ＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶されている負荷情報を読み出して、その負荷情報に基づく負荷分散の割合を算出することとしてもよい。

ここで、負荷分散の割合とは、並列に実行されているサービスの負荷が当該サービスに割り振られている複数のリソース１０２に、どのように分散されて割り当てられているかを示す指標であり、複数のリソース１０２において相対的にあらわされる。

より具体的には、負荷分散の割合として、複数のリソース１０２のうち所定の閾値よりも少ない負荷のリソース１０２の数を算出することとしてもよい。所定の閾値は、負荷集約装置１０１に直接入力することによって任意に設定可能であり、予め設定されてＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶されている。

たとえば、「実行中のサービス数」を「実行可能なサービス数」で除算した値が所定の閾値よりも小さいリソース１０２を、負荷の少ないリソース１０２として計数することとしてもよい。すなわち、任意のリソース１０２について「（実行中のサービス数／実行可能なサービス数）＜所定の閾値」となった場合に、そのリソース１０２を負荷の少ないリソース１０２として計数する。

このとき、サービスに割り振られているすべてのリソース１０２について、「実行中のサービス数／実行可能なサービス数＜所定の閾値」となるか否かを判断してもよく、また、任意のリソース１０２についてのみ判断してもよい。なお、算出部４０２による負荷の少ないリソース１０２の数を算出する具体的処理については後述する。

また、負荷分散の割合として、サービスに利用されている複数のリソース１０２の負荷平均を算出することとしてもよい。負荷平均とは、サービスを並列に実行した場合に個々のリソース１０２にかかる負荷の平均である。

ここでは、「一つのサービスに必要なパワー」に「実行中のサービス数」を乗算したものを、「サービスに割り振られているすべてのリソース１０２のリソースパワーの総和」で除算した値を負荷平均とする。なお、算出部４０２による負荷平均を算出する具体的処理については後述する。算出部４０２による算出結果はＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶される。

判定部４０３は、算出部４０２の算出結果に基づいて、複数のリソース１０２に分散しているサービスの負荷を集約させるか否かを判定する機能を有する。具体的には、判定部４０３は、ＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶されている算出結果を読み出して、その算出結果に基づいて負荷を集約させるか否かを判定する。

より具体的には、判定部４０３は、算出部４０２により、負荷分散の割合として、負荷の少ないリソース１０２の数が算出された場合には、その算出結果と予め設定されている所定の数Ｎとを比較する。そして、負荷の少ないリソース１０２の数が、予め設定されている所定の数Ｎよりも多くなった場合に、複数のリソース１０２に分散しているサービスの負荷を集約させると判定する。

なお、算出部４０２により算出された負荷の少ないリソース１０２の数と比較する所定の数Ｎは、負荷集約装置１０１に直接入力することによって任意に設定可能であり、予め設定されてＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶されている。

また、判定部４０３は、算出部４０２により、負荷分散の割合として、負荷平均が算出された場合には、その負荷平均と予め設定されている所定の閾値Ｚとを比較する。そして、負荷平均が所定の閾値Ｚより小さくなった場合に、複数のリソース１０２に分散しているサービスの負荷を集約させると判定する。

なお、算出部４０２により算出された負荷平均と比較する所定の閾値Ｚは、負荷集約装置１０１に直接入力することによって任意に設定可能であり、予め設定されてＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶されている。また、判定部４０３による判定結果はＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶される。

検出部４０４は、判定部４０３によってサービスの負荷を集約させると判定された場合、当該サービスに利用されている複数のリソース１０２の中から一のリソース１０２を検出する機能を有する。具体的には、検出部４０４は、ＲＯＭ２０２やＲＡＭ２０３などのメモリから判定結果を読み出して、その判定結果に従って、一のリソース１０２を検出する。

より具体的には、たとえば、検出部４０４は、負荷情報ＤＢ１０３に記憶されている負荷情報に基づいて、サービスに利用されている複数のリソース１０２の中から任意のリソース１０２を検出することとしてもよい。検出部４０４による検出結果はＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶される。

また、検出部４０４は、サービスに利用されている複数のリソース１０２の中から最も負荷の少ないリソース１０２を検出することとしてもよい。より具体的には、たとえば、検出部４０４は、実行中のサービス数が最も少ないリソース１０２を検出してもよく、また、サービスパワーおよび実行中のサービス数から各リソース１０２の負荷を算出し、最も負荷の少ないリソース１０２を検出することとしてもよい。

割当部４０５は、検出部４０４によって検出された一のリソース１０２の負荷を当該一のリソース１０２以外の他のリソース１０２に割り当てる機能を有する。具体的には、割当部４０５は、ＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶されている検出結果を読み出して、一のリソース１０２の負荷を当該一のリソース１０２以外の他のリソース１０２に割り当てる。

より具体的には、割当部４０５は、まず、一のリソース１０２にサービスの停止要求を送信し、一のリソース１０２で実行されているサービスを停止させる。そして、他のリソース１０２に負荷の割当要求を送信することにより、そのサービスに利用するリソース１０２を、一のリソース１０２以外の他のリソース１０２に切り替える。

このとき、一のリソース１０２で実行中のサービスの数が複数であった場合、すべてのサービスの負荷を同一の他のリソース１０２に割り当ててもよく、また、一つのサービスの負荷ごとに割り当てる他のリソース１０２を決定してもよい。

なお、一のリソース１０２の負荷を他のリソース１０２に割り当てる際の各種指示を、各サービスに関する情報の収集と提供をおこなうコンピュータ装置に送信することとしてもよい。この場合、そのコンピュータ装置から各リソース１０２に負荷の割り当てなどに関する指示がおこなわれることとなる。

また、割当部４０５は、検出部４０４によって検出された一のリソース１０２の負荷を、当該一のリソース１０２の負荷と同等あるいはそれ以上の負荷が割り当てられている他のリソース１０２に割り当てる機能を有することとしてもよい。

具体的には、割当部４０５は、負荷情報ＤＢ１０３に記憶されている負荷情報を読み出して、一のリソース１０２の負荷と同等あるいはそれ以上の負荷が割り当てられている他のリソース１０２を検索し、検索された他のリソース１０２に一のリソース１０２の負荷を割り当てることとしてもよい。

これにより、一のリソース１０２の負荷を他のリソース１０２に割り当てることによって、サービスの負荷がさらに分散してしまうことを防ぐことができ、サービスの負荷を効率的に集約させることができる。

また、割当部４０５は、許容量算出部４０６と決定部４０７とを有することとしてもよい。許容量算出部４０６は、他のリソース１０２に割り当て可能な負荷の許容量を算出する機能を有する。負荷の許容量とは、他のリソース１０２に割り当て可能な負荷をあらわす指標であり、たとえば、各リソース１０２におけるメモリの空き容量などである。

具体的には、たとえば、許容量算出部４０６は、負荷情報ＤＢ１０３に記憶されている負荷情報を読み出して、他のリソース１０２に割り当て可能な負荷の許容量をそれぞれ算出する。許容量算出部４０６によって算出された他のリソース１０２の負荷の許容量は、ＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶される。

決定部４０７は、許容量算出部４０６によって算出された許容量と一のリソース１０２の負荷とを比較することにより、他のリソース１０２の中から一のリソース１０２の負荷と適合する許容量のリソース１０２を決定する機能を有する。一のリソース１０２の負荷と適合する許容量のリソース１０２とは、一のリソース１０２の負荷を割り当て可能で、かつ、他のリソース１０２のうち最も負荷の許容量が少ないリソース１０２である。

具体的には、決定部４０７は、まず、ＲＯＭ２０２やＲＡＭ２０３などのメモリに記憶された他のリソース１０２の負荷の許容量を読み出して、一のリソース１０２の負荷と比較する。このあと、一のリソース１０２の負荷と適合する許容量のリソース１０２を、他のリソース１０２の中から決定する。

これにより、個々のリソース１０２の処理能力を最大限に利用したサービスの実行をおこなうことができ、当該サービスの負荷をより効率的に集約させることができる。

また、負荷集約装置１０１は、他のサービスからのリソース要求があった場合、割当部４０５によって負荷が他のリソース１０２に割り当てられた一のリソース１０２を他のサービスに利用されるリソース１０２に切り替える機能を有していてもよい。

これにより、異なるサービス間でのリソース１０２の切り替えにかかる時間的なコストを削減することができ、効率的なリソース融通をおこなうことができる。

なお、上述した取得部４０１、算出部４０２、判定部４０３、検出部４０４、割当部４０５は、具体的には、たとえば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、ＨＤ２０５などの記録媒体に記録されたプログラムを、ＣＰＵ２０１が実行することによって、または、Ｉ／Ｆ２０９によって、その機能を実現する。

（リソース融通システム１００の処理の概要）
つぎに、この発明の実施の形態にかかるリソース融通システム１００の処理の概要について説明する。図５−１および図５−２は、この発明の実施の形態にかかるリソース融通システム１００の処理の概要を示す説明図である。

ここでは、ある企業におけるバッチ処理（図５−１，図５−２中「サービスＡ」と表記する）およびテレビ会議システム（図５−１，図５−２中「サービスＢ」と表記する）に複数のリソース１０２が利用される場合について説明する。図５−１，図５−２において、時刻Ｐ〜Ｔは時刻をあらわしており、時刻Ｐ→時刻Ｑ→時刻Ｒ→時刻Ｓ→時刻Ｔ→時刻Ｕの順に時間が経過している。

以下、図５−１，図５−２中丸印（以下、「負荷メータ」という）は、各リソース１０２における割り当て可能なサービスの負荷、すなわち、各リソース１０２において実行可能なサービスの数をあらわす。また、負荷が割り当てられている負荷メータはハッチングまたは黒塗りされており、負荷が割り当てられていない負荷メータは空白となっている

ここでは、リソース１０２−１および１０２−２のリソースパワーを「８０」とし、リソース１０２−３〜１０２−８のリソースパワーを「１００」とする。また、サービスＡのサービスパワーを「２５」とし、サービスＢのサービスパワーを「３０」とする。

図５−１中の時刻Ｐにおいて、リソース１０２−１およびリソース１０２−２がサービスＡに利用されている。具体的には、サービスＡのサービス数は「４」であり、そのうちリソース１０２−１に割り当てられているサービス数は「３」であり、リソース１０２−２に割り当てられているサービス数は「１」である。

また、リソース１０２−３および１０２−４がサービスＢに利用されている。具体的には、サービスＢのサービス数は「４」であり、そのうちリソース１０２−３に割り当てられているサービス数は「２」であり、リソース１０２−４に割り当てられているサービス数は「２」である。

なお、リソース１０２−５〜１０２−８は、どのサービスにも利用されておらず、すべての負荷メータが空白となっている。ここでは、どのサービスにも利用されていないリソース１０２（ここでは、リソース１０２−５〜１０２−８）を「フリー」と表記する。

図５−１中の時刻Ｑにおいて、テレビ会議システムを利用する人が増えたことにより、サービスＢの負荷が高くなり、フリーとなっていたリソース１０２−５〜１０２−８がサービスＢに利用されている。具体的には、サービスＢのサービス数が「４」から「１８」に増加することにより、リソース１０２−３〜１０２−８に割り当てられているサービス数が「３」となっている。

図５−１中の時刻Ｒにおいて、テレビ会議システムを利用する人が減ったことにより、サービスＢの負荷が少なくなっている。このとき、サービスＢに利用されているリソース１０２間の負荷分散の割合を算出し、サービスＢの負荷が分散しすぎている場合には、その負荷を集約する。

なぜなら、図５−１中の時刻Ｒに示す状況下において、サービスＢに利用されているリソース１０２−３〜１０２−８を他のサービス（たとえば、サービスＡ）に融通するためには、リソース１０２−３〜１０２−８において現在実行中のサービスＢを停止する必要があり、時間的なコストがかかってしまう。

そこで、他のサービスからのリソース融通の要求を予め想定して、リソース１０２−３〜１０２−８の負荷を集約させておくことにより、リソース融通にかかる時間的なコストを削減する。ここで、負荷集約の要否を判定する際の具体的な処理の内容を説明する。

図６は、負荷情報ＤＢ１０３の記憶内容を示す説明図（その２）である。図６において、図５−１中の時刻ＲにおけるサービスＢに利用されているリソース１０２−３〜１０２−８の負荷情報６００−１〜６００−６が示されている。この負荷情報６００−１〜６００−６を用いて、サービスＢに関する負荷分散の割合を算出する。

ここでは、まず、負荷分散の割合として、リソース１０２−３〜１０２−８のうち所定の閾値よりも負荷の少ないリソース１０２の数を算出する場合について説明する。図７は、負荷集約の要否を判定する処理の概要を示す説明図である。

図７において、まず、図６中点線枠６１０内に示す「実行可能なサービス数」および「実行中のサービス数」に基づいて、各リソース１０２−３〜１０２−８における「実行中のサービス数／実行可能なサービス数」を算出する。そして、その算出結果が所定の閾値Ｐよりも小さくなったリソース１０２を負荷の少ないリソース１０２として計数する。

ここでは、上記算出結果と比較する所定の閾値Ｐを「Ｐ＝０．５」とする。これは、各リソース１０２−３〜１０２−８での空きの負荷、すなわち、余分に割り当てることができるサービスＢの負荷がそれぞれの処理能力の半分以上となっているリソース１０２を負荷の少ないリソース１０２とすることを意味する。

具体的には、リソース１０２−３については「実行中のサービス数／実行可能なサービス数＝２／３＞Ｐ」となるため、負荷の少ないリソース１０２として計数しない。また、リソース１０２−４については「実行中のサービス数／実行可能なサービス数＝２／３＞Ｐ」となるため、負荷の少ないリソース１０２として計数しない。

さらに、リソース１０２−５については「実行中のサービス数／実行可能なサービス数＝１／３＜Ｐ」となるため、負荷の少ないリソース１０２として計数する。同様に、リソース１０２−５〜１０２−８について「実行中のサービス数／実行可能なサービス数」を算出し、その算出結果が所定の閾値Ｐより小さくなるリソース１０２の数を計数する。この結果、「実行中のサービス数／実行可能なサービス数＜Ｐ」となるリソース１０２は、リソース１０２−５，１０２−６，１０２−７，１０２−８の４台となる。

そして、負荷の少ないリソース１０２の数、すなわち、「実行中のサービス数／実行可能なサービス数＜Ｐ」となるリソース１０２の数が予め設定されている所定の数Ｎよりも大きくなった場合に、負荷が分散しすぎているため集約する必要があると判定する。

ここでは、予め設定されている所定の数Ｎを「Ｎ＝２」とすると、「実行中のサービス数／実行可能なサービス数＜Ｐ」となるリソース１０２の数は「４」であり、「負荷の少ないリソース１０２の数＞Ｎ＝４」となるため、サービスＢの負荷が分散しすぎているため集約する必要があると判定する。

つぎに、負荷分散の割合として、サービスＢに利用されているリソース１０２−３〜１０２−８の負荷平均を算出する場合について説明する。ここでは、リソース１０２−３〜１０２−８の負荷平均を下記式（１）によって算出する。

負荷平均＝（サービスＢのサービスパワー×サービスＢのサービス数）／（サービスＢに利用されているリソース１０２−３〜１０２−８のリソースパワーの総和）
・・・（１）

具体的には、図６中点線枠６２０内に示す「サービスパワー」、「リソースパワー」および「実行中のサービス数」を上記式（１）に代入することにより、リソース１０２−３〜１０２−８の負荷平均を算出する。より具体的には、上記式（１）＝「（３０×８）／（１００×６）＝２４０／６００＝２／５」となる。

そして、この負荷平均が予め設定されている所定の閾値Ｚよりも小さくなった場合に、サービスＢの負荷が分散しすぎているため集約すると判定する。ここでは、予め設定されている所定の閾値Ｚを「Ｚ＝１／２」とすると、「負荷平均＝２／５」であり、「負荷平均＜Ｚ」となるため、サービスＢの負荷が分散しすぎているため集約する必要があると判定する。

つぎに、図５−２中の時刻Ｓにおいて、リソース１０２−３〜１０２−８に分散しているサービスＢの負荷が集約されている。具体的には、リソース１０２−３〜１０２−８に分散していたサービスＢの負荷をリソース１０２−３〜１０２−５に集約する。

より具体的には、リソース１０２−８の負荷をリソース１０２−３に割り当て（図５−２中矢印ｘ）、リソース１０２−７の負荷をリソース１０２−４に割り当て（図５−２中矢印ｙ）、リソース１０２−６の負荷をリソース１０２−５に割り当てる（図５−２中矢印ｚ）。

このときの負荷の割り当て手順を詳細に説明すると、まず、リソース１０２−３〜１０２−８のうち最も負荷の少ないリソース１０２−８を検出し、その負荷をリソース１０２−８の負荷と同等あるいはそれ以上の負荷が割り当てられているリソース１０２−３に割り当てる（図５−２中矢印ｘ）。

つぎに、リソース１０２−３〜１０２−７のうち最も負荷の少ないリソース１０２−７を検出し、その負荷をリソース１０２−７の負荷と同等あるいはそれ以上の負荷が割り当てられているリソース１０２−４に割り当てる（図５−２中矢印ｙ）。

最後に、リソース１０２−３〜１０２−６のうち最も負荷の少ないリソース１０２−６を検出し、その負荷をリソース１０２−７の負荷と同等あるいはそれ以上の負荷が割り当てられているリソース１０２−５に割り当てる（図５−２中矢印ｚ）。

このようにして、負荷を割り当てる際の時間的なコストを削減することにより、サービスＢの負荷を効率的に集約させることができる。この結果、リソース１０２−６〜１０２−８は、サービスＢに割り振られてはいるが負荷のないリソース１０２となり、他のサービスへのリソース融通を効率的におこなうことができることとなる。

図５−２中の時刻Ｔにおいて、売上集計や受注集計のためにバッチ処理の利用が増えることにより、サービスＡにかかる負荷が高くなっている。このとき、リソース１０２−６〜１０２−８は、サービスＢに割り振られてはいるが、負荷のない状態、すなわち、サービスＢに利用されていない状態となっている。

図５−２中の時刻Ｕにおいて、サービスＢに割り振られていたリソース１０２−６〜１０２−８がサービスＡに割り振られて利用されている。このとき、リソース１０２−６〜１０２−８は、サービスＢに割り振られてはいるが負荷のない状態となっていたため、利用するサービスの切り替え（サービスＢからサービスＡへの切り替え）にかかる時間的なコストが少なくなり、効率的なリソース融通がおこなわれる。

このように、異なるサービス間でのリソース融通を予め想定してサービスの負荷を一部のリソース１０２に集約させておくことにより、効率的なリソース融通をおこなうことができ、個々のサービスの円滑な提供を実現することができる。

なお、図５−２中の時刻Ｓにおいて、リソース１０２−６〜１０２−８で実行されていたサービスＢを完全に停止したあと、リソース１０２−６〜１０２−８をサービスＡに割り振ることとしたが、リソース１０２−６〜１０２−８のうちサービスＢの負荷がなくなった順にサービスＡに割り振ることとしてもよい。

すなわち、リソース１０２−６〜１０２−８のうちサービスＢの実行が完全に停止されたものから順にサービスＡに割り振ることとしてもよい。これにより、リソース１０２−６〜１０２−８間でのサービスＢの停止にかかる相対的な時間の差異にかかわらず、効率的なリソース融通をおこなうことができる。

（負荷集約装置１０１の負荷集約処理手順）
つぎに、この発明の実施の形態にかかる負荷集約装置１０１の負荷集約処理手順について説明する。図８は、この発明の実施の形態にかかる負荷集約装置１０１の負荷集約処理手順を示すフローチャートである。図８において、まず、取得部４０１により、サービスに利用されているリソース１０２ごとの負荷情報を取得したか否かを判断する（ステップＳ８０１）。

ここで、負荷情報を取得するのを待って（ステップＳ８０１：Ｎｏ）、取得した場合（ステップＳ８０１：Ｙｅｓ）、算出部４０２により、取得部４０１によって取得された負荷情報に基づいて、サービスに利用されているリソース１０２間の負荷分散の割合を算出する（ステップＳ８０２）。

このあと、判定部４０３により、算出部４０２の算出結果に基づいて、複数のリソース１０２に分散しているサービスの負荷を集約させるか否かを判定する（ステップＳ８０３）。ここで、サービスの負荷を集約させると判定された場合（ステップＳ８０３：Ｙｅｓ）、検出部４０４により、サービスに利用されている複数のリソース１０２の中から一のリソース１０２を検出する（ステップＳ８０４）。

そして、検出された一のリソース１０２の負荷の割り当て先となる他のリソース１０２を決定し（ステップＳ８０５）、割当部４０５により、一のリソース１０２の負荷を他のリソース１０２に割り当てる（ステップＳ８０６）。このあと、実行中のすべてのサービスについて負荷集約の要否を判定したか否かを判断する（ステップＳ８０７）。

ここで、すべてのサービスについて負荷集約の要否を判定したと判断された場合（ステップＳ８０７：Ｙｅｓ）、本フローチャートによる一連の処理を終了する。一方、すべてのサービスについて負荷集約の要否を判定していないと判断された場合（ステップＳ８０７：Ｎｏ）、ステップＳ８０１に戻り一連の処理を繰り返す。

また、ステップＳ８０３において、サービスの負荷を集約させないと判定された場合（ステップＳ８０３：Ｎｏ）、ステップＳ８０７に移行する。

このように、この発明の実施の形態によれば、異なるサービス間でのリソース融通を予め想定してサービスの負荷を一部のリソース１０２に集約させておくことにより、効率的なリソース融通をおこなうことができ、個々のサービスの円滑な提供を実現することができる。

なお、ステップＳ８０４において、検出部４０４により、サービスに利用されている複数のリソース１０２の中から最も負荷の少ない一のリソース１０２を検出することとしてもよい。

これにより、ステップＳ８０６において一のリソース１０２の負荷を他のリソース１０２に割り当てる際の時間的なコストを削減することができ、サービスの負荷を効率的に集約させることができる。

また、ステップＳ８０５において、検出部４０４によって検出された一のリソース１０２の負荷の割り当て先を、一のリソース１０２の負荷と同等あるいはそれ以上の負荷が割り当てられている他のリソース１０２に決定することとしてもよい。

これにより、一のリソース１０２の負荷を他のリソース１０２に割り当てることによって、サービスの負荷がさらに分散してしまうことを防ぐことができ、当該サービスの負荷を効率的に集約させることができる。

また、ステップＳ８０５において、許容量算出部４０６により、他のリソース１０２に割り当て可能な負荷の許容量を算出し、決定部４０７により、許容量算出部４０６によって算出された許容量と一のリソース１０２の負荷とを比較することにより、他のリソース１０２の中から一のリソース１０２の負荷と適合する許容量のリソース１０２を、一のリソース１０２の負荷の割り当て先として決定することとしてもよい。

これにより、個々のリソース１０２の処理能力を最大限に利用したサービスの実行をおこなうことができ、当該サービスの負荷をより効率的に集約させることができる。

以上説明したように、負荷集約プログラム、該プログラムを記録した記録媒体、負荷集約装置および負荷集約方法によれば、効率的なリソース融通を可能とすることにより、個々のサービスの円滑な提供を実現することができる。

なお、本実施の形態で説明した負荷集約方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネットなどのネットワークを介して配布することが可能な伝送媒体であってもよい。

（付記１）サービスに利用されているリソースごとの負荷情報を取得させる取得工程と、
前記取得工程によって取得された負荷情報に基づいて、前記サービスに利用されているリソース間の負荷分散の割合を算出させる算出工程と、
前記算出工程の算出結果に基づいて、前記複数のリソースに分散している前記サービスの負荷を集約させるか否かを判定させる判定工程と、
前記判定工程によって前記サービスの負荷を集約させると判定された場合、当該サービスに利用されている複数のリソースの中から一のリソースを検出させる検出工程と、
前記検出工程によって検出された一のリソースの負荷を当該一のリソース以外の他のリソースに割り当てさせる割当工程と、
をコンピュータに実行させることを特徴とする負荷集約プログラム。

（付記２）前記算出工程は、
前記複数のリソースのうち所定の閾値よりも少ない負荷のリソースの数を算出させることを特徴とする付記１に記載の負荷集約プログラム。

（付記３）前記算出工程は、
前記サービスに利用されている複数のリソースの負荷平均を算出させることを特徴とする付記１に記載の負荷集約プログラム。

（付記４）前記検出工程は、
前記サービスに利用されている複数のリソースの中から最も負荷の少ない一のリソースを検出させることを特徴とする付記１〜３のいずれか一つに記載の負荷集約プログラム。

（付記５）前記割当工程は、
前記検出工程によって検出された一のリソースの負荷を、当該一のリソースの負荷と同等あるいはそれ以上の負荷が割り当てられている他のリソースに割り当てさせることを特徴とする付記１〜４のいずれか一つに記載の負荷集約プログラム。

（付記６）前記他のリソースに割り当て可能な負荷の許容量を算出させる許容量算出工程と、
前記許容量算出工程によって算出された許容量と前記一のリソースの負荷とを比較することにより、前記他のリソースの中から前記一のリソースの負荷と適合する許容量のリソースを決定させる決定工程と、を前記コンピュータに実行させ、
前記割当工程は、
前記一のリソースの負荷を、前記決定工程によって決定されたリソースに割り当てさせることを特徴とする付記１〜５のいずれか一つに記載の負荷集約プログラム。

（付記７）付記１〜６のいずれか一つに記載の負荷集約プログラムを記録した前記コンピュータに読み取り可能な記録媒体。

（付記８）サービスに利用されているリソースごとの負荷情報を取得する取得工程と、
前記取得工程によって取得された負荷情報に基づいて、前記サービスに利用されているリソース間の負荷分散の割合を算出する算出工程と、
前記算出工程の算出結果に基づいて、前記複数のリソースに分散している前記サービスの負荷を集約させるか否かを判定する判定工程と、
前記判定工程によって前記サービスの負荷を集約させると判定された場合、当該サービスに利用されている複数のリソースの中から一のリソースを検出する検出工程と、
前記検出工程によって検出された一のリソースの負荷を当該一のリソース以外の他のリソースに割り当てる割当工程と、
を含んだことを特徴とする負荷集約方法。

（付記９）サービスに利用されているリソースごとの負荷情報を取得する取得手段と、
前記取得手段によって取得された負荷情報に基づいて、前記サービスに利用されているリソース間の負荷分散の割合を算出する算出手段と、
前記算出手段の算出結果に基づいて、前記複数のリソースに分散している前記サービスの負荷を集約させるか否かを判定する判定手段と、
前記判定工程によって前記サービスの負荷を集約させると判定された場合、当該サービスに利用されている複数のリソースの中から一のリソースを検出する検出手段と、
前記検出手段によって検出された一のリソースの負荷を当該一のリソース以外の他のリソースに割り当てる割当手段と、
を備えることを特徴とする負荷集約装置。

以上のように、本発明にかかる負荷集約プログラム、該プログラムを記録した記録媒体、負荷集約装置および負荷集約方法は、異なるサービス間においてリソースの融通が可能なビジネスグリッドのミドルウェアに有用であり、特に、顧客のサーバを預かり、インターネットへの接続回線や保守・運用サービスなどを提供するＩＤＣ（Ｉｎｔｅｒｎｅｔ Ｄａｔａ Ｃｅｎｔｅｒ）に適している。

この発明の実施の形態にかかるリソース融通システムのシステム構成図である。 図１に示したコンピュータ装置のハードウェア構成を示すブロック図である。 負荷情報ＤＢの記憶内容を示す説明図（その１）である。 この発明の実施の形態にかかる負荷集約装置の機能的構成を示すブロック図である。 この発明の実施の形態にかかるリソース融通システムの処理の概要を示す説明図（その１）である。 この発明の実施の形態にかかるリソース融通システムの処理の概要を示す説明図（その２）である。 負荷情報ＤＢの記憶内容を示す説明図（その２）である。 負荷集約の要否を判定する処理の概要を示す説明図である。 この発明の実施の形態にかかる負荷集約装置の負荷集約処理手順を示すフローチャートである。

符号の説明

１００ リソース融通システム
１０１ 負荷集約装置
１０２ リソース
１０３ 負荷情報ＤＢ
１１０ ネットワーク
４０１ 取得部
４０２ 算出部
４０３ 判定部
４０４ 検出部
４０５ 割当部
４０６ 許容量算出部
４０７ 決定部

Claims (8)

1. サービスに利用されているリソースごとの負荷情報を取得させる取得工程と、
   前記取得工程によって取得された負荷情報に基づいて、並列に実行されているサービスの負荷が当該サービスに割り振られている複数のリソースに、どのように分散されて割り当てられているかを示す指標値である、負荷が所定の閾値よりも少ないリソースの総数、又は、各々のリソースの前記サービスの実行にかかる負荷平均を算出させる算出工程と、
   前記算出工程の算出結果に基づいて、前記負荷が所定の閾値よりも少ないリソースの総数が所定の数よりも多いか否か、又は、前記負荷平均が所定の閾値よりも小さいか否かに応じて、前記複数のリソースに分散している前記サービスの負荷を集約させるか否かを判定させる判定工程と、
   前記判定工程によって前記サービスの負荷を集約させると判定された場合、当該サービスに利用されている複数のリソースの中から一のリソースを検出させる検出工程と、
   前記検出工程によって検出された前記一のリソースの負荷を当該一のリソース以外の他のリソースに割り当てさせる割当工程と、
   をコンピュータに実行させることを特徴とする負荷集約プログラム。
2. 前記算出工程は、
   前記取得工程によって取得された負荷情報に基づいて、前記複数のリソースのうち実行中のサービス数を実行可能なサービス数で除算した値が所定の閾値よりも小さいリソースの数を、前記負荷が所定の閾値よりも少ないリソースの総数として算出させることを特徴とする請求項１に記載の負荷集約プログラム。
3. 前記算出工程は、
   前記取得工程によって取得された負荷情報に基づいて、前記サービスの実行に必要となる前記リソースのパワーと実行中の前記サービスのサービス数とを乗算した値を、前記複数のリソースのパワーの総和で除算した値を前記負荷平均として算出させることを特徴とする請求項１に記載の負荷集約プログラム。
4. 前記検出工程は、
   前記サービスに利用されている複数のリソースの中から最も負荷の少ない一のリソースを検出させることを特徴とする請求項１〜３のいずれか一つに記載の負荷集約プログラム。
5. 前記割当工程は、
   前記検出工程によって検出された一のリソースの負荷を、当該一のリソースの負荷と同等あるいはそれ以上の負荷が割り当てられている他のリソースに割り当てさせることを特徴とする請求項１〜４のいずれか一つに記載の負荷集約プログラム。
6. 請求項１〜５のいずれか一つに記載の負荷集約プログラムを記録した前記コンピュータ
   に読み取り可能な記録媒体。
7. コンピュータが、
   サービスに利用されているリソースごとの負荷情報を取得する取得工程と、
   前記取得工程によって取得された負荷情報に基づいて、並列に実行されているサービスの負荷が当該サービスに割り振られている複数のリソースに、どのように分散されて割り当てられているかを示す指標値である、負荷が所定の閾値よりも少ないリソースの総数、又は、各々のリソースの前記サービスの実行にかかる負荷平均を算出する算出工程と、
   前記算出工程の算出結果に基づいて、前記負荷が所定の閾値よりも少ないリソースの総数が所定の数よりも多いか否か、又は、前記負荷平均が所定の閾値よりも小さいか否かに応じて、前記複数のリソースに分散している前記サービスの負荷を集約させるか否かを判定する判定工程と、
   前記判定工程によって前記サービスの負荷を集約させると判定された場合、当該サービスに利用されている複数のリソースの中から一のリソースを検出する検出工程と、
   前記検出工程によって検出された前記一のリソースの負荷を当該一のリソース以外の他のリソースに割り当てる割当工程と、
   を実行することを特徴とする負荷集約方法。
8. サービスに利用されているリソースごとの負荷情報を取得する取得手段と、
   前記取得手段によって取得された負荷情報に基づいて、並列に実行されているサービスの負荷が当該サービスに割り振られている複数のリソースに、どのように分散されて割り当てられているかを示す指標値である、負荷が所定の閾値よりも少ないリソースの総数、又は、各々のリソースの前記サービスの実行にかかる負荷平均を算出する算出手段と、
   前記算出手段の算出結果に基づいて、前記負荷が所定の閾値よりも少ないリソースの総数が所定の数よりも多いか否か、又は、前記負荷平均が所定の閾値よりも小さいか否かに応じて、前記複数のリソースに分散している前記サービスの負荷を集約させるか否かを判定する判定手段と、
   前記判定手段によって前記サービスの負荷を集約させると判定された場合、当該サービスに利用されている複数のリソースの中から一のリソースを検出する検出手段と、
   前記検出手段によって検出された前記一のリソースの負荷を当該一のリソース以外の他のリソースに割り当てる割当手段と、
   を備えることを特徴とする負荷集約装置。

Images