JP4594874B2

JP4594874B2 - ネットワークエリアにおける資源割当て方法、割当てプログラム、およびネットワークシステム

Info

Publication number: JP4594874B2
Application number: JP2006030345A
Authority: JP
Inventors: 武石田; 実山本; 拓鎌田; 伸彦福井
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2005-02-28
Filing date: 2006-02-07
Publication date: 2010-12-08
Anticipated expiration: 2026-02-07
Also published as: US20060198507A1; JP2006270925A

Description

本発明は、複数のノードによって構成されるネットワークエリアにおける資源割当て方式に係り、さらに詳しくは１つのネットワークエリアにおいて提供すべきサービスの品質に対応して、自ネットワークエリア内のノード資源だけでは不足する場合に、異なるネットワークエリア内のノード資源を借用し、借用したノード資源をサービスに割当てて、ネットワークエリアを超えた資源割当てを自律的に行なうことを可能にする、ネットワークエリアにおける資源割当て方法に関する。

従来、ネットワークによって提供される資源を共有し、複数の分散処理システムが動作する方式が広範に用いられているが、このようなシステムにおいてその構成が静的に決められる場合には、リクエストの偏りなどに対応することができず、一部のサーバに負荷が集中して、品質の維持が困難になるという問題点があった。

またシステムを分散化させるためには、事前にそれを考慮してサービスの開発を行なう必要があり、分散化の対象範囲が大きくなるにつれてコストが大きくなり、開発が困難になるという問題点があった。さらにシステムの設定を変更する場合には、システムを構成する全てのノードの設定を個々に修正する必要があり、運用コストがかかるだけでなく、修正漏れが発生しやすいという問題点もあった。

ネットワーク上で動作する分散処理システムなどでは、利用状況や資源の状況に応じて動的な資源割当ても行なわれているが、このようなシステムでも、ある処理で資源の不足が起きた場合には、特定のネットワーク内の資源のみを対象として資源の再割当が行われるために、処理のリクエストが急増した場合などにはサービスの品質に対する要求を維持することが困難になるという問題点があった。

このような分散処理システムなどにおける資源割当て方式に関して次のような文献がある。
特開平５−２３５９４８号「サービスノード増殖方式」特開平８−１３７８１１号「ネットワーク資源割当変更方法」特開２００２−２５１３４４号「サービス管理装置」特許文献１には、処理ビジーである処理手段がサービス要求パケットを受信した時、その処理手段がサービス増殖先ノードのステーションアドレスを付加したパケットを伝送路に送出し、サービス要求元にその増殖サービスノードに対してサービス再要求を行なわせる技術が開示されている。

特許文献２には、各処理モジュールから資源割当ての依頼を受けたノードが、自ノードの負荷を考慮してどの処理モジュールにどのぐらい資源を割当てるかを決定したり、他のノードに新たな資源割当てを要求することによって、負荷の平滑化と効率的な資源割当てを可能にする技術が開示されている。

特許文献３には、クライアントに対するアプリケーション提供サービスの品質を保証するＳＬＡ（サービス・レベル・アグリーメント）を実現するために、サービスサーバを、提供すべきサービスの品質に応じて複数のレベルにグループ化するとともに、さらにサービス提供品質レベルを可変とする中間サーバを設け、いずれかのレベルのグループのサービスサーバの負荷が大きくなった時には中間サーバをそのグループのサーバとして使用することによって、負荷をグループ間で均一にしながら、サービス品質の維持を図るサービス管理方式が開示されている。

しかしながらこのような従来技術においても、資源の割当ての変更は閉じたネットワークの内部で行なわれており、閉じたネットワーク内で資源をまかなえない時にはサービスの品質を維持することができないという問題点を解決することはできなかった。

本発明の課題は、上述の問題点に鑑み、複数のノードから構成される１つのネットワークエリアにおいて提供すべきサービスの品質を満たそうとしても、そのネットワークエリア内のノード資源だけでは不足する場合には、他のネットワークエリアと連携して自律的に資源割当てを行なうことによってサービスの品質を動的に維持可能とすることである。

図１は、本発明のネットワークエリアにおける資源割当て方法の原理的な機能ブロック図である。同図は、複数のノードから構成されるネットワークエリアにおける資源割当方法の原理的な機能ブロック図である。

図１において、まず１でそのネットワークエリアにおいて提供すべきサービスの品質に対応して自ネットワークエリア内のノード資源をそのサービスに割当て、自ネットワークエリア内だけではノード資源が不足の時には、２で自ネットワークエリアと異なるネットワークエリアへのノード資源の貸出を中止して、貸出していたノード資源をそのサービスに割当て、さらに資源が不足する時には、３で異なるネットワークエリア内のノード資源を借用し、借用したノード資源をそのサービスに割当てる方法が用いられる。

本発明において、異なるネットワークエリアへのノード資源の貸出が行なわれていない場合には、１で自ネットワークエリア内のノード資源をそのサービスに割当てた後にノード資源が不足する時には、３で異なるネットワークエリア内のノード資源を借用して、借用したノード資源をそのサービスに割当てる方法が用いられる。

本発明の資源割当てプログラムは、以上のような資源割当方法を計算機に実行させるためのプログラムであり、また記憶媒体はそのようなプログラムを格納した計算機読出し可能可搬型記憶媒体である。

さらに本発明のネットワークシステムは、複数のノードから構成される１つのエリアに対応するものであり、そのネットワークエリアにおいて提供すべきサービスを構成するアプリケーションを実行する一般ノードと、そのサービスの品質に対応して、自ネットワークエリア内の一般ノードのノード資源をそのサービスに割当て、自ネットワークエリア内でノード資源が不足の時に自ネットワークエリアと異なるネットワークエリア内の一般ノードのノード資源を借用して、借用したノード資源をそのサービスに割当てるエリア管理ノードとを備えるものである。

以上のように本発明によれば、自ネットワークエリアにおいてノード資源が不足する場合には、自律的に異なるネットワークエリア内のノード資源を借用して、借用したノード資源にもサービスが割当てられる。

本発明によれば、サービスを構成するアプリケーションにおけるリクエストの推移に基づいて、自律的にアプリケーションを実行するノード、すなわちサーバの配置を更新することが可能となり、自エリア内でノード資源が不足した場合には他のエリアと連携することによってサービスレベルを効率的に維持することが可能となり、サービス・レベル・アグリーメントの実現に寄与するところが大きい。

図２は、本発明におけるネットワークシステムの基本構成の説明図である。同図においてシステム１０は複数のノード１１によって構成されるが、このシステムにおいてはノード同士が自律的に連携してグループを形成し、グループ単位でサービスの品質を維持するために状況に応じてグループの構成を変化させ、外部に対して規定の品質でサービスを提供することに最も基本的な特徴がある。なおサービスは一般に複数のアプリケーションによって構成され、後述するようにそれらのアプリケーションは一般ノードと呼ばれるノードによって実行され、規定の品質でサービスが維持されるように運用が行なわれる。

本実施形態においては、システム１０の運用状態がリアルタイムで監視され、サービス毎の運用情報がモニタされる。そしてその運用情報の収集結果に対応して、提供すべきサービスに対する規定の品質を維持できるようにサービスの運用計画が立案され、サービス毎にグループ編成が行なわれる。

すなわち運用情報の収集、運用計画の立案、サービス毎のグループ編成という３つのシーケンスが自律的に繰り返され、システムの運用状況に応じてサービスの品質を維持する動作が行われる。運用情報の収集や解析が自律的に行なわれるため、外部からの管理コストを最小限におさえることが可能となる。

システム１０を構成するノード１１は固定的なものでなく、例えば従来他のシステムに所属していたような既存のノード１２に本実施形態で必要とされる機能を後付けで搭載することによって、既存のノードでもシステムに参加することが可能であり、サービスに対するリクエストなどの状況に応じてシステム構成を柔軟に変更することも可能である。

図３は、本実施形態におけるノードの物理構成の説明図である。ノード１１は一般的には中央処理装置１５、メモリ１６、外部記憶装置１７、およびネットワークインターフェース１８を備える。

図４は、図３の各ノードのメモリ１６、または外部記憶装置１７の内部の仮想領域に展開されるプログラムの説明図である。同図において、基本ソフトウェア２１は例えばオペレーティングシステムであり、基盤ソフトウェア２２は、例えばＪａｖａ（登録商標）の仮想マシンであり、コンテナソフト２３は例えばアプリケーションサーバのようにアプリケーションを動かすための基本ソフトである。本発明のプログラム２５は、アプリケーションモジュール２４とコンテナソフトウェア２３との間の中継処理などを行ないながら、本実施形態におけるシステム内の運用情報の収集、運用計画立案、サービス毎のグループ編成という３つのシーケンスを自律的に繰り返すための処理を実行するためのものである。

図５は、システムの全体構成の説明図である。同図においてシステムは、複数のエリア３０と、全てのエリアを横断的に管理するノードとしてのルート管理ノード３１を備え、各エリア３０内のノードは最上位にエリア管理ノード３２、その下にサービス管理ノード３３、最下位に一般ノード３４が配置される階層的構造を持っている。

すなわちエリア３０の内部には、そのエリア内の全てのノードを管理するエリア管理ノード３２、サービス毎に品質に責任を持つための管理を行うサービス管理ノード３３、サービス管理ノード３３からの指示に対応して、サービスを構成するアプリケーションを実行する一般ノード３４を備えており、一般ノード３４はその初期状態ではサービスを構成するアプリケーションを持たず、必要に応じてサービス管理ノード３３からアプリケーションモジュールが配布されることによってアプリケーションを実行するものとする。

図６は、全体システムを説明するための用語定義を示す。同図においてエリアは、物理的な距離や、通信遅延の小さい範囲で区切られ、エリア内でサービスを提供するための集まりとしてのグループは、一般に複数の一般ノードとサービス管理ノードによって構成される。どのような範囲でエリアを区切るかは、システムの運用者が適宜決めることができる。例えば、神奈川地区と千葉地区と北米地区というようにエリアを区切ることも可能である。

ルート管理ノードはシステムに唯一存在するものであり、ユニバーサル・ディスクリプション・ディスカバリー・アンド・インテグレーション（ＵＤＤＩ）として、どのサービスがどのエリアで提供されているかを示す役割を担っている。エリア管理ノードはエリア内でのサービスとそのエンドポイントを管理するＵＤＤＩの役割も果たす。サービス管理ノードには、管理すべきサービスを構成するアプリケーションが事前にインストールされていることが前提となっている。一般ノードは、実行すべきアプリケーションによって構成されるサービスを担当するサービス管理ノードに運用情報の報告を行なう。

またアプリケーションは、サービスを構成する、例えば単体のＷｅｂサービスであり、サービスは外部に提供され、品質を保証すべき機能の単位として、一般に複数のＷｅｂサービスを連携した形式で構成される。

図７は、グループ形成例の説明図である。同図においてＡサービスは、サービス管理ノード３３_１によって管理され、Ａサービスグループ３５_１はさらに３つの一般ノード３４_１、３４_２、および３４_３を加えて構成される。Ａサービスは、アプリケーションとして３つのアプリケーションａ、ｂ、ｃが、例えばこの順序で実行されることによって提供される。例えば一般ノード３４_１はａアプリケーションを実行し、その実行の結果について、配属されているＡサービスグループ３５_１を管理するサービス管理ノード３３_１に対して運用情報の報告を行なう。例えば一般ノード３４_２のように、そのノードが実行するアプリケーションに対応して複数のサービスに配属されている場合は、それぞれのサービスに関連する運用情報を、それぞれのグループを管理するサービス管理ノードに報告することになる。

本実施形態においては、アプリケーションを実行する一般ノードの能力を数値化することによってサービスの管理が行なわれる。図８はノード能力数値化の説明図である。同図に示すように、ノードの能力の基準となる一般的なスペックのノードをモデルノードとして用意し、モデルノード３７によるアプリケーションの実行結果の成績、例えばリクエストに対するレスポンスタイムの平均値などを基準の１００ポイントとして定義し、一般ノード３４による実行結果の成績、すなわち計測用アプリケーション３８による計測結果としてのレスポンスタイムの平均値などと比較し、比率によってノードのパワーを示すポイント数が数値化される。この一般ノード３４毎のノードパワーは、一般的に事前に測定され、後述する運用設定定義体に格納される。

図９は、運用計画作成方式の説明図である。同図において、サービス管理ノード３３_１によってＡサービスが管理され、サービス管理ノード３３_２によってＢサービスとＣサービスとが管理されているものとする。Ａサービスはａ、ｂ、およびｃの３つのアプリケーションによって構成され、Ｂサービスは２つのアプリケーションｃとｄ、Ｃサービスは２つのアプリケーションｂとｄとによって構成されているものとする。サービス管理ノード３３_１は、担当するＡサービスの提供に必要なノードの能力、すなわちノードパワーをアプリケーション毎に図８で説明したポイント数として算出し、同様にサービス管理ノード３３_２は担当するＢサービスとＣサービスの提供のための３つのアプリケーションに必要なノードパワーをポイント数として算出する。

後述するようにエリア管理ノードは、エリア内の全てのサービス管理ノードの計画をマージし、エリア内で必要なノードパワーの総量を算出し、それぞれのサービスを運用するための計画を立案する。この計画立案においては、ただ１つの計画を作成するとは限らず、特にノードパワーが不足の場合には、どのサービスをパワー不足のままで運用するかなどによって複数のパターンの計画が立案される。

例えばエリア内の一般ノードのパワーのみで全てのサービスに対する計画が立案できる場合には、計画１のようにエリア内ノードのみでサービスが構成される計画が立案され、エリア内の一般ノードのパワーで不足の場合には、計画２のように他のエリアの余剰のノードパワーを利用する計画が立案される。この場合には、エリア管理ノードは、例えば隣接エリアのエリア管理ノードを通して隣接エリアの余剰のパワーを調査し、可能であれば他のエリアのノードのパワーを借りる前提で計画の作成が行われる。複数のパターンの計画が立案される場合には、例えばシステムの運用管理者によって計画の選択や必要な修正の指示が行なわれる。

図１０は、本発明の第１の実施例におけるエリアを越えたノードパワー貸出方式の説明図である。例えばエリア３０_ａにおける計画立案においてノードパワーが不足すると、エリア管理ノード３２_ａは他のエリア３０_ｂを管理するエリア管理ノード３２_ｂに対してノードパワーの貸出を依頼し、エリア管理ノード３２_ｂ側では自エリア内のノードパワーの貸出が可能か否かを調査し、貸出可能な場合には貸出可能なノードパワーを通知するとともに、そのノードパワーを持つ一般ノードを管理するサービス管理ノードを紹介する。

ノードパワー貸出可能な場合には、エリア管理ノード３２_ｂは貸出可能なノードパワーを持つ一般ノード、例えば３４_ｂを管理するサービス管理ノード３３_ｂに新規サービスをアサインし、パワーを借りるエリア３０_ａの内部でそのサービスを管理するサービス管理ノード３３_ａは、サービス管理ノード３３_ｂに対して必要なアプリケーションモジュールなどを転送し、そのモジュールはサービス管理ノード３３_ｂから一般ノード３４_ｂに配布され、そのアプリケーションの実行結果、すなわちサービス運用情報は一般ノード３４_ｂからサービス管理ノード３３_ｂを介してノードパワーを借りたエリア３０_ａ側のサービス管理ノード３３_ａに報告される。

これに対して後述する第２の実施例においては、エリアを超えたノードパワー貸出はエリア管理ノード相互間ではなく、ルート管理ノードの仲介によって行われるものとする。すなわち第２の実施例では、後述するように、各エリアにおけるシステム運用計画立案に伴うグループ編成終了時に、各エリアのエリア管理ノードは自エリアのノードパワーの空き状態をルート管理ノードに報告する。

そしてノードパワー借用を希望するエリアのエリア管理ノードは、ルート管理ノードに対してノードパワー貸出が可能なエリアの問い合わせを行い、ルート管理ノードは各エリアのノードパワー空き状態に対応して貸出可能エリアを紹介する。ただし紹介後の実際のサービス実行準備、例えばアプリケーションモジュールの配布や、サービス実行情報の報告などについてはルート管理ノードは仲介しないものとするが、その詳細は第１の実施例の説明の後に、図５８から図６９を用いて説明する。

続いて本発明の第１の実施例について図１１から図５７を用いて説明するが、まず図１１から図１３を用いてノードの詳細論理構成について説明する。図１１は、一般ノードの論理構成ブロック図である。前述のように本発明のプログラム２５は、アプリケーションモジュール２４とコンテナソフトウェア２３との間に位置するものであり、全体を制御する基本機能部４０、他のノードとの通信を行なうための会話ユニット４１、アプリケーションモジュール２４によるアプリケーションの実行にあたって、本実施形態に必要な処理を折り込む前処理折込部４２、後処理折込部４３に加えて、各種機能部と各種データベースを備えている。

各種機能部としては、サービスの運用情報の収集などを行なう運用情報収集機能部４５、運用情報のサービス管理ノードへの報告などのスケジュールを管理するスケジュール機能部４６、立案された計画が実行された場合のサービスの品質を調べる品質検査機能部４７を備え、各種データベースとしては運用情報を保存する場合のデータ形式の定義を格納するデータ形式定義体５０、アプリケーションの実行結果、すなわちリクエストの処理に関する情報等の運用情報を蓄積する運用情報蓄積部５１、ノードの運用上必要となる、例えばノードパワーなどの設定情報の定義を格納する運用設定定義体５２、サービス毎に守るべき品質、例えば規定のレスポンスタイムなどを格納する品質要件定義体５３を備えている。

会話ユニット４１の内部には、他の機能部などとの間のデータ転送などを制御する会話機能部５５、管理用の通信以外の通信のための一般会話モジュール５６、他のノードとの間のメッセージを解析するメッセージ解析部５７、他のノードからのメッセージを受信するメッセージ受信部５８、他のノードへのメッセージを送信するメッセージ送信部５９を備えている。

図１２は、サービス管理ノードの論理構成ブロック図である。このサービス管理ノードは、一般ノードを構成する各部、および定義体などに加えて、システムの運用管理者との間の通信などを行なうための運用管理ユニット６１、いくつかの機能部、およびいくつかのデータベースが追加された構成となっている。また会話ユニット４１の内部に、他のノードとの間で管理用の通信を行なうための管理用会話モジュール６９が追加されている。なお運用管理ユニット６１の内部には、運用管理者に対する必要な通知を行う管理者通知機能部７１、および通信管理のための運用管理インターフェース７２を備えている。

追加された機能部としては、サービスの運用計画を立案する運用計画立案機能部６２、立案された計画に対応してサービスの品質を予測する品質効果予測機能部６３、アプリケーションモジュールを管理するモジュール管理部６４、および例えば一般ノードへのアプリケーションモジュールの配布にあたり、グループ内の運用情報を更新する運用構成更新機能部６５を備えている。

追加されたデータベースとしては、立案したサービス計画を格納する運用計画蓄積部６６、運用計画に基づき、どの一般ノードがどのサービスを実行するかなどを構成情報として蓄積する構成情報蓄積部６７、アプリケーションモジュールを格納するモジュール蓄積部６８を備えている。

図１３は、エリア管理ノードの論理構成ブロック図である。その構成は図１２におけるサービス管理ノードの構成と類似しているが、エリア管理ノードはエリア内の全てのノードの管理を行なうだけの機能を持つのみで十分であり、特にアプリケーション関係の機能部やデータベースは必要がなく、アプリケーションモジュール２４、前処理折込部４２、後処理折込部４３、モジュール管理部６４、モジュール蓄積部６８を省いた構成となっており、追加されるデータベースとして、エリア内に存在するノードに関するデータのリストを格納するエリア構成定義体７５が備えられる。

図１４、および図１５は、図１１から図１３で説明した各ノード内のデータベースが保持するデータの説明図である。まず図１４において、データ形式定義体５０は運用情報保存のための情報別のデータフォーマットを格納している。運用設定定義体５２はノード運用上必要な設定情報として所属エリアのＩＤなどの各種のデータを格納する。これらのデータのうち、エリア管理ノードアドレスは一般ノードとサービス管理ノードにおいて保持され、ノードパワーから、サービス毎に運用情報の報告を行なう間隔までのデータは一般ノードに保持され、また連携可能エリアのデータはエリア管理ノードに保持される。なお、本実施形態ではサービスを構成するアプリケーションは一般ノードによって実行され、ノードパワーは一般ノードのみに保持されているが、サービス管理ノードもアプリケーションを実行する場合にはサービス管理ノードにもそのノードパワーが保持される。次に品質要件定義体５３にはサービス毎に守るべき品質として規定のレスポンスタイムが格納される。

エリア構成定義体７５には、エリア内に存在するノードに関するデータとして、ノードＩＤなどのデータが格納されている。この内ノード種別としては一般ノード、サービス管理ノード、他のエリアから借用しているノードの種別が格納されている。管理しているサービスのデータはサービス管理ノードのみに対して格納され、借用期限のデータは借用ノードのみに対して格納され、貸出先と貸出期限は他のエリアにノードパワーを貸出中のノードのみについて格納されている。

図１５は、各種の蓄積部に蓄積されるデータの説明図である。運用情報蓄積部５１には、一般ノードにおいてはそのノードでアプリケーションを実行した結果としての運用情報が、サービス管理ノードでは一般ノードから報告された運用情報が格納される。データ内容としてのリクエスト受信時刻などから実行されたリクエストの数も明らかとなる。

モジュール蓄積部６８には、サービス管理ノードにおいて、そのノードが管理するサービスの実行のために必要なモジュールが格納され、運用計画蓄積部６６にはサービス毎に必要とされるノードパワーの日にち／曜日ごとのリストが格納され、過去の立案計画も実績との比較のために蓄積される。さらに構成情報蓄積部６７には、運用計画に基づいてどの一般ノードがどのサービスを実行するかのデータが過去の情報も含めて蓄積される。

続いて本実施形態において各ノードによって実行される処理のシーケンスについて詳細に説明する。図１６は、そのようなシーケンスの全体、すなわちシステム運用サイクルの全体説明図である。まずシステムの初回起動時には起動シーケンス、すなわちステップＳ１として、基本的には自エリア内の各ノードがエリア管理ノードに対して自ノードの情報を登録する処理が行われる。

続いてステップＳ２で計画立案のシーケンスが実行される。このシーケンスでは、各サービス管理ノードにおいて、サービス実行のために必要なノードパワーと、運用中に収集された運用情報を基に、サービスの品質を維持するための最適な構成計画の立案が行なわれる。

続いてステップＳ３でグループ編成のシーケンスが実行される。このシーケンスでは計画立案のシーケンスで立案された計画を基に、サービス毎にサービス管理ノードと一般に複数の一般ノードとによって構成されるグループの編成が行なわれる。

ステップＳ４では運用情報収集のシーケンスが行なわれる。このシーケンスではシステムの運用中の運用情報が収集され、サービス品質のチェックが行われる。その結果はステップＳ２の計画立案のシーケンスで利用される。

図１７は、運用計画立案タイミングと、その運用の時系列の説明図である。計画立案タイミングが来ると、ステップＳ２で運用計画の立案が行なわれる。この計画は次の計画立案タイミング以降の運用において用いられるものであり、運用計画が立案されるとステップＳ３のグループ編成が行なわれ、その結果が次の計画立案タイミングの時点以降の運用、すなわちステップＳ４で利用されることになる。

図１８は、図１６のシステム運用サイクルに対応するシーケンスの全体的関連を示すフローチャートである。同図においてシステムが起動されると、まずステップＳ１で起動シーケンスの処理が行われ、続いてステップＳ２で個々のサービス管理ノードにおいて運用計画の立案シーケンスの処理が行われる。システムにおいて新規サービスが追加される場合は、その追加内容がこのシーケンスにおいて反映される。

運用計画が立案されるとステップＳ３でエリア管理ノードにおいてグループ編成シーケンスの処理が行なわれる。新規ノードが追加される場合は、その新規ノードに対応してステップＳ１の起動シーケンスの処理が実行され、新規ノードはグループ編成シーケンスにおいてグループ編成に追加される。なおすでにステップＳ２で運用計画が立案されているために、運用計画そのものの練り直しは行われず、例えば新規ノードのパワーがノードパワーの不足しているサービスや、ぎりぎりのノードパワーによって提供されるサービスに対して追加される形式でグループ編成が行なわれる。

続いてステップＳ４でシステムが実際に運用されながら、サービス管理ノードにおいて運用情報の収集とチェックのシーケンスの処理が実行される。そしてステップＳ５で運用情報のチェックの結果に応じて、品質不良が定義された回数以上発生したか否かが判定され、定義された回数以上発生していない場合には、ステップＳ６で次の計画立案予定日に達したか否か、すなわち図１７の計画立案タイミングに達したか否かが判定され、まだ達していない場合にはステップＳ４のシーケンスが続行される。そしてステップＳ５で品質不良、例えばレスポンスタイムオーバーが定義された回数以上発生した場合、あるいはステップＳ６で計画立案予定日に達したと判定された場合にはステップＳ２に戻り、再び運用計画の立案シーケンスの処理が行われる。

図１９、および図２０は、図１８におけるステップＳ１の起動シーケンスの詳細フローチャートである。このシーケンスでは、前述のように新しく起動したノード、すなわち基本的にはエリア内の一般ノードやサービス管理ノードが、エリア管理ノードに自ノードの情報を登録する処理が実行される。

図１９において、まずコンテナソフトウェア２３から基本機能部４０に対して、ステップＳ１１で起動イベントが発信され、基本機能部４０はステップＳ１２で自ノードにインストールされている機能部などの自ノード構成を確認し、ステップＳ１３で運用設定定義体５２から運用設定データとして静的に定義されている、自ノードが所属するエリアのエリア管理ノードのアドレスを取得し、ステップＳ１４で会話機能部５５に対してエリア管理ノードへの登録を依頼する。

会話機能部５５は、ステップＳ１５で一般会話モジュール５６を用いてメッセージを作成し、メッセージ送信部５９に対してステップＳ１６でメッセージの送信を依頼し、メッセージ送信部５９はステップＳ１７でエリア管理ノードのメッセージ受信部５８に対して自ノードの情報、例えばアドレスやノードパワーなどを送信し、自ノードの情報の登録を依頼する。

図２０において、エリア管理ノード側ではメッセージ受信部５８が新しく起動したノードからのメッセージを受信し、ステップＳ１８でそのメッセージを会話機能部５５に通知し、会話機能部５５はステップＳ１９でメッセージの解析をメッセージ解析部５７に依頼し、その解析結果としてのメッセージをステップＳ２０で基本機能部４０に通知する。

基本機能部４０は、ステップＳ２１でエリア構成定義体７５内のノードリストとして、新規に起動したノードのアドレスやノードパワーを登録し、登録完了メッセージの返信を会話機能部５５にステップＳ２２で依頼する。会話機能部５５は、ステップＳ２３で管理用会話モジュール６９にメッセージの作成を依頼し、作成されたメッセージの返信をステップＳ２４でメッセージ送信部５９に依頼する。メッセージ送信部５９は、ステップＳ２５で登録完了メッセージを新しく起動したノード側のメッセージ受信部５８に対して送信する。

次に運用計画立案のシーケンスについて説明する。図２１は、この運用計画立案の全体を示すシーケンス関連図である。同図において運用計画立案シーケンスは、システムに新しいサービスが登録された場合、他のエリアから借りていたノードパワーの貸出停止通知を他のエリアから受け取った場合、品質不良が多数回発生した場合、および図１７で説明した計画立案タイミングに達した時のスケジューラによる起動の場合に開始される。

この全体シーケンスでは、まずステップＳ３０で各サービスに対する計画立案がサービスを担当するサービス管理ノード毎に行なわれ、ステップＳ３１でそれらの計画のマージがエリア管理ノードによって行なわれ、このマージ結果に対応して、全ての計画を自エリア内のノードのパワーだけで実行できない場合にはステップＳ３２で他のエリアへのノードパワー借用依頼が行なわれ、あるいは他のエリアに自エリア内のノードパワーを貸出している場合にはステップＳ３３でその貸出停止通知が他のエリアに対して行われる。

例えば他のエリアからノードパワーの借用が可能な場合にはステップＳ３１に戻り、その借用可能なノードパワーを含めて再度個々のサービスに対応する運用計画の立案がなされる。

ステップＳ３１で計画のマージの結果、作成されたサービス毎の運用計画に対して、必要があればステップＳ３４で品質予測の実行が行なわれる。原則的には、この品質予測は、ステップＳ３０で各サービス管理ノードによって立案されたサービス毎の計画に対してノードパワーが不足した場合にのみ実行される。ノードパワーが不足していない場合には、この品質予測の実行は行なわれない。

続いてまた必要に応じて、ステップＳ３５でマージによって作成された運用計画、あるいはステップＳ３４で実行された品質予測の結果に対して運用管理者への提案が行なわれ、運用管理者からすべてのサービスの運用計画実行に対する許可が得られた場合には、運用計画立案のシーケンスは終了し、そのままその運用計画にしたがってシステムの運用が行なわれる。１つでも計画に対して運用管理者から承認が得られない場合や修正が指示された場合には、再びステップＳ３１に戻り、計画のマージ以降のシーケンスが実行される。なおこのステップＳ３５における運用管理者への提案は必ずしも必須のものではなく、図１６で説明したように計画立案、グループ編成、運用情報収集のサイクルがシステムによって自律的に行なわれる場合は必要のないものである。

図２２、および図２３は、運用計画の立案ロジックの説明図である。この計画立案ロジックにおいては、例えばサービス毎の規定レスポンスタイムを満足するように計画の立案が行なわれる。図２２は、サービス毎の、また曜日毎のリクエスト数と平均レスポンスタイムの例である。例えばＡサービスに対する規定レスポンスタイムは４０ｍｓであり、月曜と金曜はリクエスト数が多いために、この規定レスポンスタイムを平均レスポンスタイムが上回ることが示されている。

図２３は、サービス毎のノードパワー割当て計画の例である。表中の数値は、各サービスを構成するアプリに必要なノードパワーのポイントの和を示している。ＡサービスとＢサービスのそれぞれに対して、曜日毎にノードパワーのポイント数を割当てることによって、品質予測として平均レスポンスタイムが得られる。パターン１では木曜日にＡ、Ｂの両方のサービスに対してそれぞれ２００ポイントのノードパワーが割当てられるが、Ｂサービスに対するレスポンスタイムの予測値は８０ｍｓとなり、規定レスポンスタイムを超えることが、またパターン２においては同じく木曜日にＡサービスに対して１００ポイント、Ｂサービスに対して３００ポイントのノードパワーが割当てられるが、Ａサービスに対する予測レスポンスタイムが５０ｍｓとなり、規定レスポンスタイムを超えることが示されている。

図２４、および図２５は、図２１のステップＳ３０、すなわちサービス毎の計画立案の詳細シーケンスである。このシーケンスの処理は、各サービスを担当するサービス管理ノードによって実行される。まずスケジュール機能部４６がステップＳ４０で運用計画立案機能部６２に計画の作成を依頼し、運用計画立案機能部６２はステップＳ４１で構成情報蓄積部６７からサービス毎の担当ノードやそのノードのパワーなどの構成情報を取得し、ステップＳ４２で運用情報蓄積部５１からサービス毎のリクエスト数、レスポンスタイムなどの運用情報を取得する。ここで運用情報蓄積部５１から運用計画立案機能部６２に渡されるデータは、図２６の受け渡しデータ詳細テーブルの項目“０１”の内容である。

続いて運用計画立案機能部６２は、品質要件定義体５３からサービス毎に守るべきレスポンスタイムをステップＳ４３でサービス品質要件として取得する。このデータは図２６のテーブルの項目“０２”の内容である。そして運用計画立案機能部６２はこれらのデータを基にして、サービス要件を満たすためにステップＳ４４でサービスを構成するアプリケーションの実行に必要なノードパワーの算出を行なう。

図２７は、このノードパワー算出のために用いられる、蓄積された過去の構成情報および運用情報の具体例である。ここでこのサービスは２つのアプリケーションａとｂとで構成され、サービスの品質要件としてレスポンスタイムが５秒以内と規定されているものとする。

図２７において品質要件、すなわちレスポンスタイム５秒以内が満たされているのは３つのパターンであるが、これらのパターンのうちで合計のノードパワーが最も少ないパターンとしてアプリケーションａに１００ポイント、アプリケーションｂに５０ポイントを割当てるものとして、図２４のステップＳ４４でノードパワーの算出が行なわれる。

図２５は、図２４のシーケンスの続きである。まずステップＳ４５で運用計画立案機能部６２は会話機能部５５に対してエリア管理ノードへの計画の通知を依頼し、会話機能部５５はステップＳ４６で管理用会話モジュール６９にメッセージの作成を依頼し、作成されたメッセージの送信をステップＳ４７でメッセージ送信部５９に依頼し、メッセージ送信部５９はステップＳ４８でエリア管理ノードに対して運用計画を送信する。ここで送られるデータは、図２６の項目“０３”に示すように、サービスおよび日にち毎に必要なノードパワーの値と、自ノードを識別するＩＤである。

エリア管理ノード側では、メッセージ受信部５８がサービス管理ノードから送られたメッセージを受信し、ステップＳ４９で会話機能部５５にそのメッセージを通知する。会話機能部５５はステップＳ５０でメッセージの解析をメッセージ解析部５７に依頼し、解析結果はサービス毎の運用計画としてステップＳ５１で運用計画蓄積部６６に格納される。

図２８は、図２１のステップＳ３１における計画のマージの詳細シーケンスである。このシーケンスの処理はエリア管理ノードによって実行される。まず運用計画立案機能部６２がステップＳ５３で運用計画蓄積部６６から各サービスの運用計画を取得し、ステップＳ５４でその計画をマージし、ステップＳ５５でエリア構成定義体７５からエリア内のノードリストを取得し、ステップＳ５６で、例えば図２１のステップＳ３２としての他のエリアへのパワー借用依頼をすでに実行し、他のエリアからノードパワーを借用できる場合にはその借用ノードの情報も含めてマージを行い、ステップＳ５７で使用可能なノードリソースを基に計画と実際のノードリソースを比較して各サービスに実際に割当て可能なノードパワーを算出する。

以上の結果によってエリア内のノードパワーだけで計画を満たすことができるか、ステップＳ３２をすでに実行していればステップＳ３４、またはＳ３５に進む。エリア内のノードパワーだけでは不足し、他のエリアに貸出中のノードがある場合にはステップＳ３３に進む。エリア内のノードパワーだけでは不足し、他のエリアへの貸出もなく、ステップＳ３２をまだ実行していない場合にはステップＳ３２に進む。

図２９から図３１は図２１のステップＳ３２、すなわち他のエリアへのパワー借用依頼の詳細シーケンスである。図２９は、エリア管理ノード、すなわちノードパワーを借りようとするエリアの管理ノードから全てのエリアを管理するルート管理ノードに対してノードパワーを借用したいエリアのエリア管理ノードのアドレスを問合せる処理のシーケンスである。まず運用計画立案機能部６２が、ステップＳ６０で運用設定定義体５２の格納内容から連携可能エリアの範囲を取得する。ここでノード借用可能なエリアは静的に定義され、図１４に示すように運用設定定義体５２に格納されているものとする。運用計画立案機能部６２は連携可能エリア、すなわち対象エリアのエリア管理ノード取得メッセージ、すなわちエリア管理ノードのアドレスを取得するためのメッセージをルート管理ノード側に送信するために、ステップＳ６１からＳ６４で、会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９を介して、ルート管理ノードに対してエリア管理ノード取得メッセージを送信する。

ここで前述のように、ノード借用可能なエリアは、エリア毎に例えばエリア管理者によって静的に設定されるものとする。借用可能か否かの判断は、基本的にはそのエリア相互間での通信に対して発生する遅延が実用上無視できるかどうか、およびエリア相互間での通信が許可されているかによって判定される。実際にはエリアの管理者同士による契約によって決定されるものと想定される。

若干の通信遅延が発生しても、ノードパワーの借用可能なエリアに関しては遅延の程度によってノードパワーに対して１より小さい係数を掛けることによって調整を行う。通信遅延のために他のエリアからの出力に対して８０％の係数を掛けるべき場合には、１００ポイントのパワーを持つノードを、８０ポイントのパワーを持つノードとして扱うことになる。

ルート管理ノード側では、メッセージを受信したメッセージ受信部５８から、ステップＳ６５からＳ６７において会話機能部５５、メッセージ解析部５７を介して処理が行われ、会話機能部５５はステップＳ６７でルート管理ノード内の、例えばエリア構成定義体、すなわちエリア管理ノードのリストから、問合せのあったエリアのエリア管理ノードのアドレスを取得する。なおルート管理ノードの構成は、図１３で説明したエリア管理ノードの構成と類似しているものとする。

図３０および図３１は、図２９のシーケンスの続きである。ルート管理ノード側では、会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９のステップＳ７０からＳ７２の処理によって、エリア管理ノード側に対して他エリアのエリア管理ノードの情報が送信される。

エリア管理ノード側では、ステップＳ７３からＳ７５でメッセージ受信部５８、会話機能部５５、メッセージ解析部５７による処理によって、運用計画立案機能部６２にエリア管理ノードの情報、すなわちアドレスが通知される。

続いてエリア管理ノードから他のエリアのエリア管理ノードに対してパワー借用依頼のメッセージを送るために、運用計画立案機能部６２、会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９によってステップＳ７６からＳ７９の処理が行われ、他のエリアのエリア管理ノードに対してパワー借用依頼メッセージが送信される。このメッセージで送られるデータは、図２６の項目“０４”に示すように借用希望ノードパワーの値と、借用希望期間である。

このパワー借用依頼メッセージは図３１で、他のエリアのエリア管理ノードのメッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ８１とＳ８２の処理によって解析される。会話機能部５５は、この解析結果に対応してノードパワーの貸出が可能か否かを判定するために、ステップＳ８３で構成情報蓄積部６７からエリア内のノード状況を取得し、ステップＳ８４で運用計画蓄積部６６から各サービスに必要なノードパワーの計画を取得し、ノードパワーの貸出が可能か否かを判定する。

図３２は、このノードパワー貸出可能性判定処理の詳細フローチャートである。この処理は、他のエリアからのノードパワーの貸出依頼を受信した時点で起動される。まずステップＳ９０で構成情報蓄積部６７から得られた各サービスに割当てられているノードの情報、運用計画蓄積部６６から得られた各サービスに必要なノードパワーの計画がノード状況として取得され、ステップＳ９１で計画で要求されているノードパワーと実際に割当てられているノードパワーを比較し、現時点でサービスの要求品質に対してノードパワーが足りているか否かが判定され、足りていない場合にはステップＳ９２で貸出は不可能と判定される。足りている場合には、ステップＳ９３で割当てられているノードパワーから要求されているノードパワーを減算して、ノードパワーの余剰値を算出することによって貸出可能ノードパワーが算出され、ステップＳ９４でこの貸出可能ノードパワーがパワー貸出を依頼してきた他のエリアのエリア管理ノードに通知されることになる。

すなわち図３１のステップＳ８５からＳ８７の処理において、会話機能部５５、メッセージ送信部５９によってパワー貸出を依頼してきたエリアのエリア管理ノードに対して貸出可能なパワーが通知される。この通知メッセージに含まれるデータは、図２６の項目“０５”のように貸出可能なノードパワーの値と、貸出可能期間である。この図３１のシーケンスが終了すると、図２１のステップＳ３１、すなわち図２８の処理に戻ることになる。

図３３は、図２１のステップＳ３３、すなわち他のエリアへの貸出停止通知の詳細シーケンスである。同図において、まずノードパワーを貸出しているエリア管理ノード側の運用計画立案機能部６２、会話機能部５５、管理用会話モジュール６９、およびメッセージ送信部５９によるステップＳ９５からＳ９８の処理によって、ノードパワーの貸出停止メッセージがパワーを借りている他のエリアのエリア管理ノードに対して送信される。このメッセージにおいて通知されるデータは、図２６の項目“０６”で示すように貸出停止予定のノードパワーの値、パワーを貸出したノードで実行中のサービス、およびそのサービスを管理するサービス管理ノードのアドレスである。

この貸出停止通知メッセージを受けた他のエリアのエリア管理ノード側では、メッセージ受信部５８、会話機能部５５、およびメッセージ解析部５７によるステップＳ９９、Ｓ１００の処理によってメッセージの内容が解析され、その解析結果に対応して図２１で説明したように、この通知を受けたエリア管理ノード側では計画立案シーケンスが開始される。

図３４は、このノードパワー貸出停止通知に対応して、ノードパワーを貸しているエリア側と、ノードパワーを借りているエリア側での運用計画立案、およびグループ編成におけるその取扱の説明図である。まずノードパワーを貸しているエリア側のステップＳ２における運用計画立案シーケンスにおいて、ノードパワーの不足のためにノードパワーを貸しているエリア側に対して貸出停止通知が発信される。ノードパワーを借りているエリア側では、その通知に対して直ちにノードパワーを返却するというような即座の対応は不可能であり、次の計画立案タイミングまでは借りているノードパワーを含めて運用が行なわれる。

ノードパワーを借りているエリア側では、次の計画立案タイミングの時点ｔ_２で立案する運用計画においてノードパワー返却が可能か否かを検討し、返却が可能であればノードパワーを貸しているエリア側にそれを通知し、借りているノードパワーを含まない形で運用計画の立案を行なう。

ノードパワーを貸しているエリア側でも同時に運用計画の立案が行なわれているが、この運用計画立案タイミングの時点ｔ_２ではまだノードパワーを借りているエリア側からの返却可能通知が届いていないために、貸しているノードパワーを含めた運用計画を立案することはできず、運用計画立案の途中でノードパワーを借りているエリア側から返却可能通知を受け取ったとしても、前述のようにステップＳ３のグループ編成においては、例えばぎりぎりのノードパワーで運用しなければならないサービスのグループにそのノードパワーを組入れることは可能であるが、立案される運用計画そのものに返却されるノードパワーを活用することはできず、返却されるノードパワーを含めた運用計画の立案は次の計画立案タイミングｔ_３において行なわれることになる。

ノードパワーの貸借は前述のように貸出可能期間、貸出期限を指定して行なわれる。この貸出期限が到来した時には、ノードパワーを借りているエリア側のエリア管理ノードは、前述の貸出停止通知を受け取らない限り、借用期間の更新を貸出側のエリア管理ノードに申請することができる。図３５はその借用期間更新申請処理のフローチャートである。

図３５において貸出期限がきた時点で処理が開始され、ステップＳ１０２でノードパワーの貸出もとのエリア管理ノードに借用期間の更新が申請され、ステップＳ１０３で更新が許可されるか否かによって、許可される場合にはステップＳ１０４で借用期限が更新され、継続して利用することが可能になるが、更新が許可されない場合にはステップＳ１０５で借用ノードが返却される。

なお、図３４のようにノードパワー貸出停止通知を受けた場合および、図３５のように借用期間の更新が許可されなかった場合におけるノードの返却処理は、該ノードパワーを借用しているエリアのエリア管理ノードから貸出元のエリアのエリア管理ノードへ返却メッセージを送信し、それぞれの構成情報蓄積部６７およびエリア構成定義体７５を修正することで実施される。

図３６、および図３７は、図２１のステップＳ３４、すなわち品質予測実行の詳細シーケンスである。前述のようにこの処理は、例えばステップＳ３１の計画マージのシーケンスの結果、サービス管理ノードによって立案された各サービス毎の計画に対して割当てられるノードパワーが不足する場合にのみ実行される。

図３６でエリア管理ノード側からサービス管理ノードに対して品質予測の実行が依頼される。運用計画立案機能部６２が、エリア構成定義体７５から品質予測を実行すべきサービスを管理するサービス管理ノードの情報、例えばそのアドレスをステップＳ１０８で取得し、ステップＳ１０９からＳ１１２の処理において会話機能部５５、管理用会話モジュール６９、およびメッセージ送信部５９の処理によって、エリア内でマージされた計画において各サービスに割当て可能なノードパワーを通知して、品質予測の実行依頼メッセージがサービス管理ノード側に送られる。

サービス管理ノード側では、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ１１３からＳ１１５の処理によって、品質効果予測機能部６３に対してそのメッセージの内容が通知される。

図３７においてサービス管理ノード側の品質効果予測機能部６３は、ステップＳ１１７で運用情報蓄積部５１から過去の運用情報を取得し、ステップＳ１１８で品質要件定義体５３からサービス毎の品質要件を取得し、さらにステップＳ１１９で構成情報蓄積部６７から過去の構成情報を取得して、ステップＳ１２０でサービス毎の品質予測を実行する。この品質予測では、実際にそのサービスに割当てられたノードパワーと過去の運用実績に基づいて、サービス毎の品質、例えばレスポンスタイムの予測などが、図２７におけると同様に実行される。

図３８、図３９は、図２１のステップＳ３５、すなわち運用管理者への提案の詳細シーケンスである。前述のように、このシーケンスはノードパワーが不足し、ステップＳ３４で品質予測が実行された後には原則的に行われる処理であるが、ノードパワーが不足していない場合にはシステムの自律的動作を実現するために原則的にはこのシーケンスは実行されないものである。例えばシステムの運用の初期においては、システムの運用状態の確認を行なうために図３８、および図３９のシーケンスが実行されるが、運用が定常状態に入ってからはノードパワーが不足していない場合には基本的に実行されないことになる。

図３８において、サービス管理ノード側で品質効果予測機能部６３、管理者通知機能部７１、メッセージ送信部５９、運用管理インターフェース７２によるステップＳ１２２からＳ１２４の処理によって、サービス運用管理者に対してサービスの運用結果と品質予測の結果の通知が行われる。

サービス運用管理者は、システム内でサービス管理ノードとの通信が可能な範囲に存在するものとし、サービス運用管理者はステップＳ１２５でサービス管理ノードから送られた運用計画と品質予測結果を検討し、例えばサービス相互間の優先度などに応じて、サービスＡに対しては、レスポンスタイムを短くするために割当てるノードパワーを増加させ、サービスＢに割当てるノードパワーをその分減少させるというような修正、あるいは運用計画の承認の内容を、ステップＳ１２６、Ｓ１２７の運用管理インターフェース７２を介する処理によって品質効果予測機能部６３に通知する。図２３で説明したように、パターン１とパターン２との２つのパターンのいずれかをサービス運用管理者が選択する形式をとることも可能である。

図３９は、図３８のシーケンスの続きである。サービス管理ノード側では、品質効果予測機能部６３がステップＳ１２８で、運用管理者からの修正指示がある場合には、その指示に対応してサービス毎の必要パワーリストを再作成し、その再作成結果を含めて運用管理者による承認や修正の結果を、ステップＳ１２９からＳ１３２における会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９の処理によって、エリア管理ノード側のメッセージ受信部５８に送信する。なおステップＳ１２８の必要パワーリスト再作成の処理は、例えば前述のようにサービスＡのノードパワーを増加させ、サービスＢのノードパワーを減少させるような運用管理者からの修正指示に対応して実行される。

以上で図２１で説明した運用計画立案シーケンスの説明を終了し、続いて図１８のステップＳ３、すなわちグループ編成シーケンスの詳細について説明する。図４０は、グループ編成シーケンスの全体的なシーケンス関連図である。このシーケンスは計画立案シーケンスの終了にともなって開始される。まずステップＳ１３５で計画立案結果にしたがって実ノードの割当て、すなわちどのサービスのどのアプリケーションをどのノードで実行するかの割当てが行なわれ、次に他のエリアのノードパワーを借用する場合には、ステップＳ１３６でパワーを借りるエリアのエリア管理ノードに実際にノードパワーを借りることを通知し、そのエリア内でサービスを管理するサービス管理ノード、すなわち代理サービス管理ノードの情報を取得した後に、ステップＳ１３７でサービス管理ノードへの通知、すなわち運用計画の通知が行われ、他のエリアのノードパワーを借りる場合にはステップＳ１３８でパワー借用エリアへのアプリケーションモジュールの配布、すなわち代理サービス管理ノードへのモジュール配布が行なわれた後に、ステップＳ１３９で自エリア内、および他のエリアでノードパワーを借りる一般ノードへのモジュール配布が行われる。

図４１は、図４０のステップＳ１３５、すなわち実ノード割当ての詳細シーケンスである。同図において運用計画立案機能部６２が、運用計画蓄積部６６から運用管理者によって承認された運用計画をステップＳ１５１で取得し、またエリア構成定義体７５からステップＳ１５２で他のエリア内の借用ノードを含めた利用可能なノード情報を取得し、ステップＳ１５３でどのサービスのアプリケーションをどのノードで実行するかを、運用計画のパワー割当てを基に決定し、計画に対して実際のノードを割当てる処理が終了する。

図４２、および図４３は、図４０のステップＳ１３６、すなわちパワー借用エリアへの通知の詳細シーケンスである。図４２においてエリア管理ノードの運用計画立案機能部６２、会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９によるステップＳ１５５からＳ１５８までの処理によって、他のエリアのエリア管理ノードに計画立案にあたって借用を依頼したノードパワーを実際に借用することを通知する借用メッセージが送信される。

このメッセージを受け取ったノードパワーを貸与するエリア側のエリア管理ノードでは、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ１５９からＳ１６１の処理によって、基本機能部４０に対して借用メッセージの内容が通知される。

図４３で、このメッセージの内容を受け取った基本機能部４０は、エリア構成定義体７５からサービスを管理するサービス管理ノードの情報をステップＳ１６２で取得する。すなわちパワーを貸与するエリアのために実行されるサービスを管理する代理サービス管理ノードを選定する。その選定結果は基本機能部４０、会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９によるステップＳ１６３からＳ１６６の処理によって、ノードパワーを借りるエリア側のエリア管理ノードに通知される。ここで通知される内容は図２６の項目“０７”に示すように、他のエリア側でサービスを管理する代理サービス管理ノードのアドレスである。

このメッセージを受け取ったノードパワーを借りる側のエリア管理ノードのメッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ１６７からＳ１６９までの処理によって、運用計画立案機能部６２にその代理サービス管理ノードのアドレスが通知される。

図４４は、図４０のステップＳ１３７、すなわちサービス管理ノードへの通知の詳細シーケンスである。このシーケンスではエリア管理ノードから、サービスを担当するサービス管理ノードに対してサービス毎の運用計画、例えば日にちや曜日毎に各ノードが実行すべきアプリケーションなどを指定する情報が通知される。まずエリア管理ノード側の運用計画立案機能部６２が、エリア構成定義体７５からステップＳ１７１でエリア内のノードの情報を取得する。そして運用計画立案機能部６２、会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９によるステップＳ１７２からＳ１７５の処理によって、計画通知メッセージがサービス管理ノードに通知される。

サービス管理ノード側では、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ１７６からＳ１７８の処理によって、受信したメッセージの解析が行われ、その内容としての構成情報が構成情報蓄積部６７に格納される。

図４５、および図４６は、図４０のステップＳ１３８、すなわちパワー借用エリアへのモジュール配布の詳細シーケンスである。図４５においてノードパワーを借りる側のエリア管理ノードの運用計画立案機能部６２、会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９によるステップＳ１８０からＳ１８３の処理によって、借用ノード情報メッセージ、すなわち他のエリアでサービスを管理する代理サービス管理ノードのアドレス情報を含むメッセージが、パワーを借りるエリア側のサービス管理ノードに送られる。

パワーを借りる側のサービス管理ノードでは、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ１８４からＳ１８６の処理によって基本機能部４０に借用ノード情報が通知される。

図４６において、パワーを借りるエリア側のサービス管理ノードでは、運用計画立案機能部６２がステップＳ１８８でモジュール蓄積部６８からアプリケーションの実行に必要なモジュールを取得する。そして運用計画立案機能部６２、会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９のステップＳ１８９からＳ１９２の処理によって、サービスの実行に必要なモジュールが代理サービス管理ノード側に送信される。

代理サービス管理ノード、すなわち他のエリア側のサービス管理ノードでは、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ１９３からＳ１９５の処理によって、送信されたモジュールがモジュール蓄積部６８に格納される。

図４７から図４９は、図４０のステップＳ１３９、すなわち一般ノードへのモジュール配布の詳細シーケンスである。図４７においてサービス管理ノード側で運用構成更新機能部６５が構成情報蓄積部６７からグループ内の運用情報をステップＳ２００で取得する。そして運用構成更新機能部６５、会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９によるステップＳ２０１からＳ２０４までの処理によって、一般ノードに対してノード運用設定メッセージが送信される。このノード運用設定メッセージの内容は、図２６の項目“０８に”に示すようなサービス実行に関する設定情報である。

このメッセージを受け取った一般ノード側では、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７、基本機能部４０によるステップＳ２０５からＳ２０８の処理によって、メッセージ内のノード運用設定情報が運用設定定義体５２に格納される。ここでノード運用設定情報の内容は、当然、前述のようにエリア管理ノードによって一般ノードにアプリケーション単位に割当てられたノードパワーに対応するが、実際のアプリケーション実行時のクライアントからのリクエストの割当ては、例えば重み付きのラウンドロビン方式などの公知の技術によって行なわれ、ノードパワーの割当てとは必ずしも直接的には対応しないものとなる可能性もある。

図４８において一般ノード側では、基本機能部４０がステップＳ２１０で、コンテナソフトウェア２３からインストール済みのモジュールの情報を取得し、ステップＳ２１１でノード運用設定情報とインストール済みのモジュールの情報とを比較し、モジュールが不足しているか否かを判定する。不足している場合には基本機能部４０、会話機能部５５、一般会話モジュール５６、メッセージ送信部５９によるステップＳ２１２からＳ２１５までの処理によって、サービス管理ノード側に不足モジュールの取得を依頼するメッセージが送信される。

このメッセージを受信したサービス管理ノード側では、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ２１６からＳ２１８までの処理によって、メッセージの内容が解析され、モジュール管理部６４に対して不足モジュールの取得依頼が通知される。

図４９において、サービス管理ノードのモジュール管理部６４はステップＳ２２０でモジュール蓄積部６８から追加モジュールを取得する。そしてモジュール管理部６４、会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９によるステップＳ２２１からＳ２２４の処理によって、追加モジュール転送メッセージが一般ノードに送信される。

一般ノード側では追加モジュール転送メッセージを受信し、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７、基本機能部４０によるステップＳ２２５からＳ２２８までの処理によって、転送された追加モジュールがコンテナソフトウェア２３にインストールされる。

図５０、および図５１は、一般ノードによるサービス、すなわちアプリケーション実行時の詳細シーケンスである。図５０は１つのエリア内、すなわち実質的に１つのサービスを管理するサービス管理ノード、およびそのサービスを構成するアプリケーションを実行する一般ノードが１つのエリア内に限定される場合の、一般ノードによるサービス実行シーケンスである。

図５０において、クライアント８０からアプリケーションモジュール２４に対して、例えばＢサービスの実行指示がステップＳ２３０で与えられると、ステップＳ２３１でアプリケーションモジュール２４から前処理折込部４２に対して折り込み処理実行が指示され、前処理折込部４２によって構成情報蓄積部６７からステップＳ２３２でアプリケーションを実行するのがどのノードであるかが取得され、また同時に前処理折込部４２によって、例えばＢサービスを構成するアプリケーションｃを実行する一般ノード内のアプリケーションモジュール２４に対してステップＳ２３３でアプリケーションｃの実行が指示される。また同時にＢサービスを構成するアプリケーションｄを実行する一般ノードのアプリケーションモジュール２４に対しても、ステップＳ２３４でアプリケーションｄの実行が指示される。アプリケーションの実行結果は、前処理折込部４２から、ステップＳ２３５でアプリケーションモジュール２４を介して、ステップＳ２３６でクライアント８０に対して返信される。

このように本実施形態では、クライアント８０との間のサービスの窓口をサービス管理ノードとすることによって、サービスを構成する個々のアプリケーションを実行するノードが変化してもクライアントはその変化を意識する必要がない。またサービスを構成する個々のアプリケーションは一般ノードによって実行されるが、同一のアプリケーションを複数のノードが担当する場合には、ノードのパワーの比率によってリクエストの振り分けが制御される。例えばアプリケーションｃをノード１が５０ポイント、ノード２が１００ポイントのノードパワーで実行する場合にはリクエストが１：２の比率で振り分けられる。

図５１は、他のエリアのノード、すなわち借用ノードがアプリケーションを実行する場合の詳細シーケンスである。同図において、他のエリアのサービス管理ノード、すなわち代理サービス管理ノードが、アプリケーションを実行する一般ノードと、ノードパワーを借りるエリア側でＢサービスを管理するサービス管理ノードの間に存在し、Ｂサービスを管理するサービス管理ノードの前処理折込部４２から他のエリアのサービス管理ノード、すなわち代理サービス管理ノードに対してアプリケーションの実行が依頼される点を除いては、そのシーケンスは図５０におけるとほぼ同様であり、その詳細な説明を省略する。

シーケンスの説明の最後として、図１８のステップＳ４、すなわち運用情報の収集とチェックの詳細シーケンスについて説明する。図５２は、この運用情報収集、およびチェックシーケンスの全体関連図である。同図（ａ）においてクライアントからサービスへのリクエストがあると、ステップＳ２５０で運用情報の取得とデータの正規化が行なわれる。すなわちリクエスト毎に一般ノードがサービスの実行情報としてレスポンスタイムなどを計測し、そのデータをある形式に従って正規化し、ノード内に保存する。そしてステップＳ２５１で品質チェックを実行する。

図５２（ｂ）でスケジューラ、すなわち図１１の一般ノードの論理構成におけるスケジュール機能部４６によって、一定の間隔で運用情報のサービス管理ノードへの提出指示が行なわれると、ステップＳ２５２でサービス管理ノードへの運用情報提出処理が行われる。

図５３は、図５２のステップＳ２５０、すなわち運用情報取得とデータ正規化の詳細シーケンスである。このシーケンスは一般ノードによって実行される。まず前処理折込部４２に対してクライアントからのリクエストが与えられると、そのリクエスト情報がステップＳ２５５で運用情報収集機能部４５に一時保存されるとともに、そのリクエストがステップＳ２５６でアプリケーション２４に通知され、ステップＳ２５７によって処理が実行され、ステップＳ２５８で後処理折込部４３に対して実行結果が返され、後処理折込部４３からクライアントに対してステップＳ２５９で処理結果が返される。

このアプリケーションの処理結果のクライアントへの返却などとは非同期に、ステップＳ２６０で後処理折込部４３から運用情報収集機能部４５に対してレスポンス情報が通知される。運用情報収集機能部４５はステップＳ２６１でデータ形式定義体５０からデータ形式を取得し、ステップＳ２６２でデータを正規化し、ステップＳ２６３で品質検査機能部４７に対して品質チェックを依頼する。このデータの正規化では、リクエスト情報とレスポンス情報から得られたリクエスト元の情報や、処理の所要時間などのデータをデータ形式に合わせて正規化する処理が実行される。

図５４から図５６は図５２のステップＳ２５１における品質チェックの詳細シーケンスである。この品質チェックは一般ノードによって実行され、必要に応じてサービス管理ノードに警告が通知され、さらにサービス運用管理者に警告メッセージを通知する処理が行なわれる。

図５４において、一般ノードの運用情報収集機能部４５はステップＳ２６５で品質検査機能部４７に対して品質検査を依頼し、品質検査機能部４７は品質要件定義体５３からステップＳ２６６でサービスに対応する品質要件を取得し、ステップＳ２６７で品質検査、例えばレスポンスタイムが規定の値以下であるか否かを調べ、品質要件を満たさない場合にはステップＳ２６８でサービス管理ノードに警告通知を行うために会話機能部５５にその通知を依頼し、運用情報収集機能部にステップＳ２６９で品質検査の結果を返し、運用情報収集機能部４５はステップＳ２７０で運用情報蓄積部５１に品質検査済みの運用情報を格納する。

図５５において、一般ノードの品質検査機能部４７は前述のようにステップＳ２６８で会話機能部５５に対して警告の通知を依頼する。この依頼に対応して会話機能部５５、一般会話モジュール５６、メッセージ送信部５９によるステップＳ２７４からＳ２７６の処理によって、サービス管理ノードに対して警告メッセージが送信される。

サービス管理ノード側では、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ２７７からステップＳ２７９の処理によって受信したメッセージが解析され、その内容としての警告が基本機能部４０に通知される。ここでサービス管理ノードの基本機能部４０は、次の図５６のシーケンスによってサービス運用管理者に警告メッセージを送信する。図５６のシーケンスは、ステップS２８２で警告の通知の依頼を受けるたびに起動される必要はなく、例えば、品質不良が、例えば予め定められた回数以上発生したとき、に起動されてもよい。

図５６において、サービス管理ノードの基本機能部４０はステップＳ２８１で管理者通知機能部７１に警告の通知を依頼し、管理者通知機能部７１、メッセージ送信部５９によるステップＳ２８２、Ｓ２８３の処理によって、サービス運用管理者に対して警告メッセージが通知される。このような警告メッセージの通知により、サービス管理者は、サービスのレスポンス実績とリクエスト数などの運用状況を考慮して、計画の見直し等の対応を検討することが可能になる。

図５７は、図５２のステップＳ２５２、すなわちサービス管理ノードへの運用情報提出の詳細シーケンスである。同図において一般ノード内のスケジュール機能部４６は、例えば一定の間隔で会話機能部５５に対して保持されている運用情報の通知をステップＳ２８５で依頼する。この依頼に対応して会話機能部５５、一般会話モジュール５６、メッセージ送信部５９によるステップＳ２８６からＳ２８８の処理によって、運用情報がサービス管理ノードに送信される。前述のように複数のサービス管理ノードの管理下にある場合は、関係するサービス（アプリケーション）の運用情報をそれぞれ対応するサービス管理ノードに送信する。

サービス管理ノード側では、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７、運用情報収集機能部４５によるステップＳ２８９からＳ２９２の処理によって、メッセージの内容が解析され、運用情報が運用情報蓄積部５１に格納される。

以上において本発明の第１の実施例について詳細に説明したが、次に本発明の第２の実施例について説明する。前述のように第２の実施例では、立案された運用計画の実行時に自エリアのノードパワーだけでは不足する場合に、ルート管理ノードを介してノードパワーの空いているエリアに対してパワーの借用を依頼し、ルート管理ノードが各エリアのノードパワーの空き状況に対応してパワーを貸出可能なエリアを紹介する形式で、ノードパワーの貸し借りが行われる。なおルート管理ノードの構成は、前述のように、図１３で説明したエリア管理ノードの構成と同様とする。

図５８は、第２の実施例におけるエリアを超えたノードパワー貸出方式の説明図である。同図を第１の実施例における図１０と比較すると、エリア管理ノード３２ａと３２ｂとの間で直接にノードパワーの貸借の交渉が行われる代わりに、ノードパワーを借用しようとするエリア管理ノード３２ａはルート管理ノード３１に対してノードパワーの貸出を依頼し、各エリアのノードパワーの空き状況を管理しているルート管理ノード３１が、ノードパワーの貸出可能なエリアをエリア管理ノード３２ａに紹介することになる。

すなわち第２の実施例では、例えば図１７で説明した運用計画立案の後のグループ編成の時点で、各エリア管理ノード３２はルート管理ノード３１に対してノードパワーの空き状況を登録し、各エリアのノードパワーの空き状況はルート管理ノード３１によって一括管理される。ルート管理ノード３１の役割は、第１の実施例では各エリア管理ノードのネットワークアドレスの管理を基本とするのに対して、第２の実施例ではそれに加えて各エリアのノードパワー空き状態、およびエリア間でのノードパワー貸借状況の管理も行うことになる。

以下図５９から図６９を用いてノードパワー貸出方式の相違による第１の実施例との処理の相違を説明する。ノードパワーのエリアを越えた貸借以外の処理については第１の実施例におけると同様であり、その説明は省略する。

図５９から図６１は、第２の実施例における他のエリアへのパワー借用依頼の詳細シーケンスであり、第１の実施例に対する図２９から図３１に対応するものである。まず図５９では、ステップＳ３０１で運用計画立案機能部６２によって運用設定定義体５２から、図２９のステップＳ６０と同様に連携可能エリアの範囲が取得される。この場合、ノード借用可能なエリアは前述のように静的に定義されているものとする。

続いて運用計画立案機能部６２、会話機能部５５、管理用会話モジュール６９、およびメッセージ送信部５９によるステップＳ３０２からＳ３０５までの処理によって、ノードパワー借用依頼メッセージがルート管理ノードに対して送信される。第１の実施例においては、エリア管理ノードからステップＳ６４でルート管理ノードに対してエリア管理ノード取得メッセージが送られ、他のエリアのエリア管理ノードのアドレスのみの問い合わせが行われるが、第２の実施例では借用希望のノードパワーを示すことによって、その条件に合うエリアのリストの要求が行われる。

ルート管理ノード側ではメッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ３０６からＳ３０８までの処理によって受信メッセージの解析が行われ、構成情報蓄積部６７からエリア管理ノードの情報取得、すなわち要求されているノードパワーを貸出可能なエリアのエリア管理ノードの検索が行われる。

次に図６０においてルート管理ノード側では、会話機能部５５、管理用会話モジュール６９、およびメッセージ送信部５９によるステップＳ３１０からＳ３１２までの処理によって、エリア管理ノード側へのメッセージの送信、すなわち貸出可能エリアのリストの送信が行われる。

エリア管理ノード側ではメッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ３１３からＳ３１５までの処理によって、受信メッセージの解析が行われ、貸出可能エリアのリストが運用計画立案機能部６２に通知される。そして運用計画立案機能部６２、会話機能部５５、管理用会話モジュール６９によるステップＳ３１６からＳ３１８までの処理によって、ノードパワー借用予約を依頼するメッセージの送信指示がメッセージ送信部５９に与えられる。すなわちルート管理ノードから取得した貸出可能エリアのリストから、ノードパワーの借用依頼を行うエリアが選定され、借用予約メッセージが作成され、そのメッセージの送信がメッセージ送信部５９に指示される。

続いて図６１において、エリア管理ノードのメッセージ送信部からルート管理ノードに対してステップＳ３２０でノードパワー借用依頼メッセージが送信され、ルート管理ノード側ではメッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ３２１からＳ３２３までの処理によって、受信メッセージが解析され、構成情報蓄積部６７にノードパワー借用予約の登録が行われる。

この段階では借用予約の対象となるエリアのエリア管理ノードに対して予約が行われたことは通知されないものとする。これはノードパワーの空き状況の管理がルート管理ノードのみで行われるため、借用予約がエリア管理ノードに通知されなくても、ダブルブッキングのような事態は発生しないためである。そしてこの時点では実際のノードパワーの貸借は行われず、予約のみが行われ、予約されたエリアのノードパワーは、次に他のエリアからノードパワーの借用要求があった場合には、図５９のステップＳ３０８におけるノードパワー貸出可能なエリアの検索の対象外となる。

図３２におけるノードパワー貸出可否判定処理については、第２の実施例においてはノードパワーの空き状況が常にルート管理ノードに対して報告されているために、基本的に不必要な処理となる。

図６２、図６３は、第２の実施例における他のエリアへのノードパワー貸出停止通知の詳細シーケンスである。この処理は第１の実施例に対する図３３に相当する。まず図６２において、ノードパワーの貸出を停止したい側のエリア管理ノードでは、運用計画立案機能部６２、会話機能部５５、管理用会話モジュール６９、およびメッセージ送信部５９によるステップＳ３２５からＳ３２８までの処理によって、ノードパワー貸出停止メッセージが作成されて、そのメッセージがルート管理ノード側に送信される。ノードパワー貸出停止メッセージの内容は、図３３のステップＳ９８におけると同様に図２６の項目０６に相当する。

ルート管理ノード側では、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ３２９からＳ３３１までの処理によって、受信メッセージの内容が解析され、ノードパワー貸出停止通知の対象となる貸出先のエリアのエリア管理ノードが構成情報蓄積部６７から検索される。

続いて図６３で、ルート管理ノード側で、会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９によるステップＳ３３３からＳ３３５までの処理によって、ノードパワー貸出停止メッセージが作成されて、そのメッセージが貸出停止通知の対象となる他のエリアのエリア管理ノードに送信される。このメッセージの内容も図２６の項目０６と同じである。

このメッセージを受信した他のエリアのエリア管理ノード側では、メッセージ受信部５８、会話機能部５５、およびメッセージ解析部５７によるステップＳ３３６、Ｓ３３７の処理によって、メッセージの内容が解析され、ノードパワー貸出停止通知を受けたエリア管理ノードは、前述のように計画立案シーケンスを開始することになる。このように第２の実施例では、ノードパワー貸出停止の通知もルート管理ノードを介して行われる。

図６４は、第２の実施例におけるグループ編成シーケンスの全体関連図である。この関連図は第１の実施例における図４０に相当する。図６４において、図４０と同様にステップＳ３４０からＳ３４４までの処理において、一般ノードへのモジュール配布までの処理が終了するが、第２の実施例においてはその後、ステップＳ３４６の処理、すなわちルート管理ノードへの報告の処理が追加される。すなわち第２の実施例では各エリアのノードパワー空き状態がルート管理ノードによって一括管理されるために、その空き状況がグループ編成の終了時点でルート管理ノードに報告され、ルート管理ノードは構成情報蓄積部６７に保持している各エリアのノードパワーの空き状態の更新を行う。

図６５は、図６４のステップＳ３４６のルート管理ノードへのノードパワー空き状況報告処理の詳細シーケンスである。同図においてエリア管理ノード側では、運用計画立案機能部６２、会話機能部５５、管理用会話モジュール６９、およびメッセージ送信部５９によるステップＳ３５０からＳ３５３までの処理によって、ノードパワー空き状況の報告メッセージが作成されて、そのメッセージがルート管理ノード側へ送信される。

ルート管理ノード側では、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ３５４からＳ３５６までの処理によって、受信メッセージが解析されて、構成情報蓄積部６７内のエリアの情報、すなわちノードパワー空き状況が更新とされる。

図６６，図６７は、パワー借用メッセージのパワー貸出エリアへの通知の詳細シーケンスである。このシーケンスは、第１の実施例における図４２に相当するが、図４２ではノードパワーの借用メッセージが、パワーを借りるエリアの管理ノードからパワーを貸すエリアのエリア管理ノードに対して直接に送信されるが、第２の実施例ではノードパワー借用メッセージがルート管理ノードによって仲介される形式で、ノードパワーを貸すエリア側のエリア管理ノードに送信される。

図６６、図６７において、まずノードパワーを借りる側のエリア管理ノードにおいて、運用計画立案機能部６２、会話機能部５５、管理用会話モジュール６９、およびメッセージ送信部５９によるステップＳ３６０からＳ３６３までの処理によって、ノードパワーの借用メッセージが作成されてルート管理ノード側に送信される。

ルート管理ノード側では、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ３６４からＳ３６６までの処理によって、受信メッセージが解析され、構成情報蓄積部６７からノードパワー貸出先となるエリアのエリア管理ノードが検索される。前述のようにノードパワー借用の予約はすでに行われており、その予約状況は、例えば構成情報蓄積部６７に保持されているものとする。

図６７において、ルート管理ノード側の会話機能部５５、管理用会話モジュール６９、メッセージ送信部５９によるステップＳ３７０からＳ３７２までの処理によって、ノードパワーの借用メッセージが作成され、ノードパワー貸出側エリアのエリア管理ノードに対して送信される。

このメッセージを受信したノードパワー貸出元となるエリア側のエリア管理ノードでは、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ３７３からＳ３７５までの処理によって、受信メッセージが解析され、基本機能部４０に対してノードパワー借用メッセージの内容が通知される。

図６８、図６９は、ノードパワー借用メッセージを受信したノードパワー貸出側のエリア管理ノードから、そのエリアにおいて一般ノードによって行われるサービスを管理するサービス管理ノード、すなわち代理サービス管理ノードの情報の送信メッセージの、ノードパワー借用側のエリア管理ノードに対する送信シーケンスの詳細である。このシーケンスは、第１の実施例に対する図４３に相当するものである。まず図６８でノードパワー貸出元となるエリアのエリア管理ノードにおける基本機能部４０によるステップＳ３８０の処理によって、エリア構成定義体７５からサービスを管理するノード、すなわち代理サービス管理ノードが選定され、そのアドレスなどの情報が取得される。そして基本機能部４０、会話機能部５５、管理用会話モジュール６９、およびメッセージ送信部５９によるステップＳ３８１からＳ３８４までの処理によって、サービス管理ノードの情報のメッセージがルート管理ノード側に送信される。このメッセージによって送信される内容は図２６の項目０７に相当する。ルート管理ノード側では、メッセージ受信部５８、会話機能部５５、メッセージ解析部５７によるステップＳ３８５、Ｓ３８６の処理によって、メッセージの内容が解析される。

そして図６９で会話機能部５５、管理用会話モジュール６９、およびメッセージ送信部５９によるステップＳ３９０からＳ３９２までの処理によって、代理サービス管理ノードの情報の送信メッセージが作成され、ノードパワーを借用するエリア側のエリア管理ノードに送られる。

このメッセージを受信したエリア管理ノード側では、メッセージ受信部５８、会話機能部５５、およびメッセージ解析部５７によるステップＳ３９３からＳ３９５までの処理によって、受信メッセージが解析され、運用計画立案機能部６２に代理サービス管理ノードの情報が通知される。

このように第２の実施例では、ノードパワーを借用するエリア側のエリア管理ノードがルート管理ノードを介して、ノードパワーの借用メッセージをノードパワーを貸す側のエリアのエリア管理ノードに対して送信し、そのメッセージを受信したエリア管理ノードが代理サービス管理ノードを選定し、その情報をルート管理ノードを介してノードパワーを借りるエリア側のエリア管理ノードに送信することになるが、その後の実際のサービス実行に必要な準備やサービス実行情報の報告などについては、ルート管理ノードによる仲介を受けることなく、第１の実施例におけると同様に、例えばパワーを借りる側のサービス管理ノードとパワーを貸す側のサービス管理ノード、すなわち代理サービス管理ノードとの間で直接に行われるものとする。

例えば図４４から図４９で説明したサービス管理ノードへの通知や、サービス実行のためのモジュール配布などの処理は、すべてルート管理ノードの仲介を受けることなく、第１の実施例におけると同様に、２つのエリアの間で直接に行われる。これは、ルート管理ノードはノードパワーの空き状態を一括管理し、ノードパワーの貸借に関する基本的仲介だけを行うためであり、例えばモジュール配布などのように転送データ量が大きくなると、ルート管理ノードの仲介はパフォーマンス上のボトルネックとなる恐れがあるという問題点などを防止するためのものである。さらにノードパワーの貸借に関する基本的仲介をルート管理ノードが行うという点以外は、第２の実施例における処理は第１の実施例におけると同様であり、その説明はすべて省略する。

以上において本発明の資源割当方法、およびネットワークシステムについてその詳細を説明したが、この資源割当方法を実現するために各ノードで実行されるプログラムは当然一般的なコンピュータシステムによって実行することが可能である。図７０はそのようなコンピュータシステム、すなわちハードウェア環境の構成ブロック図である。

図７０においてコンピュータシステムは中央処理装置（ＣＰＵ）９０、リードオンリメモリ（ＲＯＭ）９１、ランダムアクセスメモリ（ＲＡＭ）９２、通信インタフェース９３、記憶装置９４、入出力装置９５、可搬型記憶媒体の読取り装置９６、およびこれらの全てが接続されたバス９７によって構成されている。

記憶装置９４としてはハードディスク、磁気ディスクなど様々な形式の記憶装置を使用することができ、このような記憶装置９４、またはＲＯＭ９１に図１８から図６９までのシーケンスとして説明したプログラムが格納され、そのようなプログラムがＣＰＵ９０によって実行されることにより、本実施形態における自エリア内のノード資源が不足した場合の他エリア内のノード資源の借用、サービス運用計画の立案、グループ編成、運用情報収集のシーケンスの繰返しなどが可能となる。

このようなプログラムは、プログラム提供者９８からネットワーク９９、および通信インタフェース９３を介して、例えば記憶装置９４に格納されることも、また市販され、流通している可搬型記憶媒体１００に格納され、読取り装置９６にセットされて、ＣＰＵ９０によって実行されることも可能である。可搬型記憶媒体１００としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＤＶＤなど様々な形式の記憶媒体を使用することができ、このような記憶媒体に格納されたプログラムが読取り装置９６によって読取られることにより、本実施形態におけるネットワークエリアを超えた自律的な資源割当などが可能となる。

以上詳細に説明したように、本実施形態によればシステム内でサービスに関する運用情報の収集、運用計画の立案、サービス毎のノードグループの編成という３つのシーケンスがノード同士が自律的に連携する形式で繰り返されることによって、例えばリクエストの状況変化に応じて、規定の品質を保ちながらサービスを提供することが可能となる。

また運用情報の収集、解析がシステム内で自律的に行なわれるために、外部から必要とされる管理コストを最小限に抑えることができる。さらに既存のノードに本発明の機能を後付けで搭載することによって、そのノードがシステムに参加することが可能となり、システム構成の柔軟性が大きくなる。

またこのような自律的な動作が１つのエリア内に限定されることなく、他のエリア内のノードパワーを借用して行なわれることも可能となり、さらに他のエリアに貸出しているノードパワーの貸出も中止することによって、１つのエリア内、すなわち閉じたネットワークの内部で資源をまかなうことができない場合に、他のネットワークと連携してサービスの品質を維持することが可能となる。

（付記１）複数のノードから構成されるネットワークエリアにおける資源割当て方法であって、
該ネットワークエリアにおいて提供すべきサービスの品質に対応して、自ネットワークエリア内のノード資源を該サービスに割当て、
自ネットワークエリア内でノード資源が不足する時、自ネットワークエリアと異なるネットワークエリア内のノード資源を借用して、該借用したノード資源を該サービスに割当てることを特徴とするネットワークエリアにおける資源割当て方法。
（付記２）前記サービスが１つ以上のアプリケーションによって構成され、前記ノード資源を該１つ以上のアプリケーションのうちで指定したアプリケーションに割当てることを特徴とする付記１記載のネットワークエリアにおける資源割当て方法。
（付記３）前記ノード資源の大きさをアプリケーション処理能力としてのノードパワーで表し、
該ノードの持つノードパワーと、前記アプリケーションの処理に必要なノードパワーとに対応して前記ノード資源のアプリケーションへの割当てを行なうことを特徴とする付記２記載のネットワークエリアにおける資源割当て方法。
（付記４）前記ネットワークエリア内のノードが、
前記エリア内のノードを統一的に管理するエリア管理ノードと、
該エリア管理ノードの下で、前記提供すべきサービスを管理するサービス管理ノードと、
該サービス管理ノードの下で、前記サービスを構成するアプリケーションのうちで、割当てられたアプリケーションの処理を実行する一般ノードとによって階層的に構成されることを特徴とする付記３記載のネットワークエリアにおける資源割当て方法。
（付記５）前記サービス管理ノードが、自ノードが管理すべきサービスを構成するアプリケーションの処理に必要なノードパワーを算出して、ある一定期間に対する該サービスの運用計画を作成し、
前記エリア管理ノードが、複数のサービス管理ノードによって作成されたサービスの運用計画をマージして、自エリア内で提供すべき複数のサービスに必要なノードパワーを該サービスを構成するアプリケーション単位に自エリア内の一般ノードのノード資源に割当て、
自エリア内でノードパワーが不足する時、前記借用した異なるネットワークエリア内の一般ノードのノード資源への前記アプリケーション単位のノードパワー割当てを行なうことを特徴とする付記４記載のネットワークエリアにおける資源割当て方法。
（付記６）前記一般ノードが、前記エリア管理ノードによって自ノードのノードパワーに割当てられたアプリケーションの実行結果の品質を、前記一定期間に対して作成されたサービス運用計画の運用中に前記サービス管理ノードに報告し、
該サービス管理ノードが、該一般ノードからの報告に基づいて、該一定期間の次の一定期間に対するサービス運用計画を作成することを特徴とする付記５記載のネットワークエリアにおける資源割当て方法。
（付記７）前記不足のノードパワーがアプリケーション単位に割当てられた他エリア内の一般ノードが、自ノードのノードパワーに割当てられたアプリケーションの実行結果の品質を自エリア内で自ノードを管理するサービス管理ノードに報告し、
該サービス管理ノードが、前記サービスの運用計画を作成したサービス管理ノードに、該アプリケーションの実行結果の品質の報告を中継することを特徴とする付記６記載のネットワークエリアにおける資源割当て方法。
（付記８）前記一般ノードが、サービスにおけるリクエストに対応して前記アプリケーションの実行結果を正規化して、該実行結果の品質を調べることを特徴とする付記６記載のネットワークエリアにおける資源割当て方法。
（付記９）前記サービスを構成するアプリケーションが割当てられた１つ以上の一般ノードと、該サービスの運用計画を作成したサービス管理ノードとが１つのグループを構成することを特徴とする付記５記載のネットワークエリアにおける資源割当て方法。
（付記１０）前記サービス管理ノードによるサービス運用計画作成の手順、エリア管理ノードによるサービス運用計画のマージと、該サービスに必要なノードパワーのアプリケーション単位の一般ノードへの割当てによるグループ編成の手順、および一般ノードのアプリケーションの実行と実行結果のサービス管理ノードへの報告の手順とを自律的に繰り返すことを特徴とする付記９記載のネットワークエリアにおける資源割当て方法。
（付記１１）前記一般ノードが、前記エリア管理ノードによって自ノードのノードパワーに割当てられたアプリケーションの実行結果の品質を、前記一定期間に対して作成されたサービス運用計画の運用中に前記サービス管理ノードに報告し、
該サービス管理ノードが、該一般ノードからの報告に基づいて、該アプリケーションによって構成されるサービスの品質が予め定められた回数以上規定値に違反したことが判明した時、前記サービスの運用計画を再作成することを特徴とする付記５記載のネットワークエリアにおける資源割当て方法。
（付記１２）前記サービス管理ノードが、前記エリア管理ノードによってアプリケーション単位のノードパワーが割当てられた一般ノードに対して、該アプリケーションの実行に必要なモジュールを配布することを特徴とする付記５記載のネットワークエリアにおける資源割当て方法。
（付記１３）前記サービス管理ノードが、前記エリア管理ノードによって前記異なるエリア内でアプリケーション単位のノードパワーが割当てられた一般ノードに対して、該アプリケーションが割当てられた一般ノードを管理するサービス管理ノードであって、該異なるネットワーク内のサービス管理ノードを介して、該アプリケーションの実行に必要なモジュールを配布することを特徴とする付記５記載のネットワークエリアにおける資源割当て方法。
（付記１４）前記異なるネットワークエリアを管理するエリア管理ノードが、前記ノードパワーが不足しているネットワークエリアのエリア管理ノードからのノードパワー借用要求に対して、
自エリア内で提供されるべき各サービスに必要なノードパワーの算出結果に基くサービス運用計画に対応して、サービスの要求品質に対する自エリア内でのノードパワーの過不足を判定し、
ノードパワーに余剰がある時、貸出可能なノードパワーを算出し、
該貸出可能なノードパワーをノードパワー借用要求を行なったエリア管理ノードに通知することを特徴とする付記５記載のネットワークエリアにおける資源割当て方法。
（付記１５）複数のネットワークエリアのすべてに対する前記エリア管理ノードを管理するルート管理ノードをさらに備えるとともに、
該複数のネットワークエリアに対する各エリア管理ノードが、前記サービスに必要なノードパワーの自エリア内の一般ノードのノード資源への割り当ての結果として自エリア内のノードパワーに余剰が生じたとき、該余剰の状況を前記ルート管理ノードに報告し、
該報告の結果に対応して、該ルート管理ノードが、ノードパワーが不足しているネットワークエリアのエリア管理ノードからのノードパワー借用要求に対して、ノードパワー貸出可能なエリアを検索し、ノードパワーの貸借を仲介することを特徴とする付記５記載のネットワークエリアにおける資源割り当て方法。
（付記１６）前記サービス管理ノードが、前記サービス運用計画の作成にあたり、過去に作成された運用計画の運用時においてサービスを構成する各アプリケーションに割当てられたノードパワーに対応して得られたサービスの品質の実績に基づいて、サービスを構成する各アプリケーションに必要なノードパワーを算出することを特徴とする付記５記載のネットワークエリアにおける資源割当て方法。
（付記１７）複数のノードから構成されるネットワークエリアにおける資源割当て方法であって、
該ネットワークエリアにおいて提供すべきサービスの品質に対応して、自ネットワークエリア内のノード資源を該サービスに割当て、
自ネットワークエリア内でノード資源が不足する時、自ネットワークエリアと異なるネットワークエリアへのノード資源の貸出を中止して、該貸出していたノード資源を該サービスに割当て、
さらにノード資源が不足する時、自ネットワークエリアと異なるネットワークエリア内のノード資源を借用して、該借用したノード資源を該サービスに割当てることを特徴とするネットワークエリアにおける資源割当て方法。
（付記１８）複数のノードから構成されるネットワークエリアにおける資源割当てを行なう計算機によって使用されるプログラムであって、
該ネットワークエリアにおいて提供すべきサービスの品質に対応して、自ネットワークエリア内のノード資源を該サービスに割当てる手順と、
自ネットワークエリア内でノード資源が不足する時、自ネットワークエリアと異なるネットワークエリアへのノード資源の貸出を中止して、該貸出していたノード資源を該サービスに割当てる手順と、
さらにノード資源が不足する時、自ネットワークエリアと異なるネットワークエリア内のノード資源を借用して、該借用したノード資源を該サービスに割当てる手順とを計算機に実行させることを特徴とするネットワークエリアにおける資源割当てプログラム。
（付記１９）複数のノードから構成されるネットワークエリアにおける資源割当てを実行する計算機によって使用されるプログラムであって、
該ネットワークエリアにおいて提供すべきサービスの品質に対応して、自ネットワークエリア内のノード資源を該サービスに割当てる手順と、
自ネットワークエリア内でノード資源が不足する時、自ネットワークエリアと異なるネットワークエリア内のノード資源を借用して、該借用したノード資源を該サービスに割当てる手順とを計算機に実行させることを特徴とするネットワークエリアにおける資源割当プログラム。
（付記２０）複数のノードから構成されるネットワークエリアにおける資源割当てを実行する計算機によって使用される記憶媒体であって、
該ネットワークエリアにおいて提供すべきサービスの品質に対応して、自ネットワークエリア内のノード資源を該サービスに割当てるステップと、
自ネットワークエリア内でノード資源が不足する時、自ネットワークエリアと異なるネットワークエリア内のノード資源を借用して、該借用したノード資源を該サービスに割当てるステップとを計算機に実行させるネットワークエリアにおける資源割当プログラムを格納した計算機読出し可能可搬型記憶媒体。

本発明の資源割当方法の原理的な機能ブロック図である。本発明におけるネットワークシステムの自律的運用方式の基本説明図である。本実施形態におけるノードの物理構成を示す図である。各ノードのメモリ上に展開されるプログラムの構成を示す図である。ノードによって構成されるシステムの全体構成を示す図である。システム全体構成に関連する用語の説明図である。グループ形成の例を示す図である。ノード能力の数値化を説明する図である。運用計画作成の概要の説明図である。第１の実施例におけるエリアを超えたノードパワー貸出を説明する図である。一般ノードの論理構成ブロック図である。サービス管理ノードの論理構成ブロック図である。エリア管理ノードの論理構成ブロック図である。ノード内の各データベースの保持情報を示す図（その１）である。ノード内の各データベースの保持情報を示す図（その２）である。システム運用の全体サイクルを示す図である。運用計画立案からシステム運用までの時系列を示す図である。システム運用の全体フローチャートである。システム起動の詳細シーケンスである。システム起動の詳細シーケンス（続き）である。運用計画立案の全体シーケンス関連図である。運用計画立案ロジックを説明する図である。サービス毎のノードパワー割当て計画の例を示す図である。運用計画立案の詳細シーケンスである。運用計画立案の詳細シーケンス（続き）である。シーケンス内の受け渡しデータ内容の説明図である。アプリケーションに必要なノードパワー算出ロジックの説明図である。計画マージの詳細シーケンスである。他のエリアへのパワー貸出依頼の詳細シーケンスである。他のエリアへのパワー貸出依頼の詳細シーケンス（続き１）である。他のエリアへのパワー貸出依頼の詳細シーケンス（続き２）である。他のエリアへのノードパワー貸出可否判定処理の詳細フローチャートである。他のエリアへの貸出停止通知の詳細シーケンスである。貸出停止通知にともなう運用計画立案シーケンスを含む時系列の説明図である。ノードパワー借用期間更新申請処理の詳細フローチャートである。品質予測実行の詳細シーケンスである。品質予測実行の詳細シーケンス（続き）である。運用管理者への提案の詳細シーケンスである。運用管理者への提案の詳細シーケンス（続き）である。グループ編成シーケンスの全体関連図である。実ノード割当ての詳細シーケンスである。パワー借用エリアへの通知の詳細シーケンスである。パワー借用エリアへの通知の詳細シーケンス（続き）である。サービス管理ノードへの通知の詳細シーケンスである。パワー借用エリアへのモジュール配布の詳細シーケンスである。パワー借用エリアへのモジュール配布の詳細シーケンス（続き）である。一般ノードへのモジュール配布の詳細シーケンスである。一般ノードへのモジュール配布の詳細シーケンス（続き１）である。一般ノードへのモジュール配布の詳細シーケンス（続き２）である。一般ノードによるアプリケーション実行時の詳細シーケンスである。パワー借用ノードによるアプリケーション実行時の詳細シーケンスである。運用情報収集とチェックの全体シーケンス関連図である。運用情報取得とデータ正規化の詳細シーケンスである。品質チェックの詳細シーケンスである。品質チェックの詳細シーケンス（続き１）である。品質チェックの詳細シーケンス（続き２）である。サービス管理ノードへの運用情報提出の詳細シーケンスである。第２の実施例におけるエリアを超えたノードパワー貸出方式を説明する図である。第２の実施例におけるパワー貸出依頼の詳細シーケンスである。第２の実施例におけるパワー貸出依頼の詳細シーケンス（続き１）である。第２の実施例におけるパワー貸出依頼の詳細シーケンス（続き２）である。第２の実施例におけるノードパワー貸出停止通知の詳細シーケンスである。第２の実施例におけるノードパワー貸出停止通知の詳細シーケンス（続き）である。第２の実施例におけるグループ編成シーケンスの全体関連図である。図６４におけるルート管理ノードへの報告の詳細シーケンスである。第２の実施例におけるパワー借用エリアへの通知の詳細シーケンスである。第２の実施例におけるパワー借用エリアへの通知の詳細シーケンス（続き）である。第２の実施例における代理サービス管理ノード情報通知の詳細シーケンスである。第２の実施例における代理サービス管理ノード情報通知の詳細シーケンス（続き）である。本実施形態におけるプログラムのコンピュータへのローディングを説明する図である。

符号の説明

１０ネットワークシステム
１１ノード
１２既存ノード
１５中央処理装置
１６メモリ
１７外部記憶装置
１８ネットワークインターフェース
２１基本ソフトウェア
２２基盤ソフトウェア
２３コンテナソフトウェア
２４アプリケーションモジュール
２５本発明のプログラム
３０エリア
３１ルート管理ノード
３２エリア管理ノード
３３サービス管理ノード
３４一般ノード
３５グループ
３７モデルノード
３８計測用アプリケーション
４０基本機能部
４１会話ユニット
４２前処理折込部
４３後処理折込部
４５運用情報収集機能部
４６スケジュール機能部
４７品質検査機能部
５０データ形式定義体
５１運用情報蓄積部
５２運用設定定義体
５３品質要件定義体
５５会話機能部
５６一般会話モジュール
５７メッセージ解析部
５８メッセージ受信部
５９メッセージ送信部
６１運用管理ユニット
６２運用計画立案機能部
６３品質効果予測機能部
６４モジュール管理部
６５運用構成更新機能部
６６運用計画蓄積部
６７構成情報蓄積部
６８モジュール蓄積部
６９管理用会話モジュール
７１管理者通知機能部
７２運用管理インターフェース
７５エリア構成定義体
８０クライアント
９０ＣＰＵ
９１リード・オンリ・メモリ（ＲＯＭ）
９２ランダム・アクセス・メモリ（ＲＡＭ）
９３通信インターフェース
９４記憶装置
９５入出力装置
９６読取装置
９７バス
９８プログラム提供者
９９ネットワーク
１００可搬型記憶媒体

Claims

複数のノードから構成されるネットワークエリアにおける資源割当て方法であって、
該ネットワークエリアにおいて提供すべきサービスの品質に対応して、自ネットワークエリア内のノード資源を該サービスに割当て、
自ネットワークエリア内でノード資源が不足する時、自ネットワークエリアと異なるネットワークエリアへのノード資源の貸出を中止して、該貸出していたノード資源を該サービスに割当て、
さらにノード資源が不足する時、自ネットワークエリアと異なるネットワークエリア内のノード資源を借用して、該借用したノード資源を該サービスに割当て、
前記ネットワークエリア内のノードが、前記エリア内のノードを統一的に管理するエリア管理ノードと、該エリア管理ノードの下で、前記提供すべきサービスを管理するサービス管理ノードと、該サービス管理ノードの下で、前記サービスを構成するアプリケーションのうちで、割当てられたアプリケーションの処理を実行する一般ノードとによって階層的に構成され、
前記一般ノードによる運用情報の収集シーケンス、前記サービス管理ノードによる運用計画立案シーケンス、前記一般ノードおよび前記サービス管理ノードによるサービス毎のグループ編成シーケンスを自律的に繰り返すことを特徴とするネットワークエリアにおける資源割当て方法。
複数のノードから構成されるネットワークエリアにおける資源割当て方法であって、
該ネットワークエリアにおいて提供すべきサービスの品質に対応して、自ネットワークエリア内のノード資源を該サービスに割当て、
自ネットワークエリア内でノード資源が不足する時、自ネットワークエリアと異なるネットワークエリア内のノード資源を借用して、該借用したノード資源を該サービスに割当て、
前記ネットワークエリア内のノードが、前記エリア内のノードを統一的に管理するエリア管理ノードと、該エリア管理ノードの下で、前記提供すべきサービスを管理するサービス管理ノードと、該サービス管理ノードの下で、前記サービスを構成するアプリケーションのうちで、割当てられたアプリケーションの処理を実行する一般ノードとによって階層的に構成され、
前記一般ノードによる運用情報の収集シーケンス、前記サービス管理ノードによる運用計画立案シーケンス、前記一般ノードおよび前記サービス管理ノードによるサービス毎のグループ編成シーケンスを自律的に繰り返すことを特徴とするネットワークエリアにおける資源割当て方法。
前記サービス管理ノードが、自ノードが管理すべきサービスを構成するアプリケーションの処理に必要なノードパワーを算出して、ある一定期間に対する該サービスの運用計画を作成し、
前記エリア管理ノードが、複数のサービス管理ノードによって作成されたサービスの運用計画をマージして、自エリア内で提供すべき複数のサービスに必要なノードパワーを該サービスを構成するアプリケーション単位に自エリア内の一般ノードのノード資源に割当て、
自エリア内でノードパワーが不足する時、前記借用した異なるネットワークエリア内の一般ノードのノード資源への前記アプリケーション単位のノードパワー割当てを行なうことを特徴とする請求項１または２記載のネットワークエリアにおける資源割当て方法。
前記異なるネットワークエリアを管理するエリア管理ノードが、前記ノードパワーが不足しているネットワークエリアのエリア管理ノードからのノードパワー借用要求に対して、
自エリア内で提供されるべき各サービスに必要なノードパワーの算出結果に基くサービス運用計画に対応して、サービスの要求品質に対する自エリア内でのノードパワーの過不足を判定し、
ノードパワーに余剰がある時、貸出可能なノードパワーを算出し、
該貸出可能なノードパワーをノードパワー借用要求を行なったエリア管理ノードに通知することを特徴とする請求項３記載のネットワークエリアにおける資源割当て方法。