JP2016051446A - 計算機システム、計算機、負荷分散方法及びそのプログラム - Google Patents

Abstract

【課題】簡単な構成で計算機の負荷を分散する。【解決手段】計算機システムであって、複数の外部システムからの要求によって処理を実行する複数の計算機を備え、前記複数の計算機の各々は、メモリと、前記メモリを参照するプロセッサと、他の計算機と通信するためのネットワークインタフェースと、を有し、同一ネットワークセグメント内の他の計算機と、前記各計算機が算出した受付重み統計値を共有しており、前記各計算機のプロセッサは、一つの前記外部システムから同一ネットワークセグメント内に同報されるブロードキャストを受信し、前記共有される受付重み統計値を参照して、前記受信したブロードキャストに応答するかを判定し、応答すると判定した場合、前記一つの外部システムに処理要求を送信させるために、前記ブロードキャストを送信した外部システムに応答を返信する。【選択図】図１

Description

本発明は、計算機に関し、特に、アプリケーションを実行する計算機に関する。

＜分散アプリケーション基盤のアーキテクチャ＞
近年、分散配置型アプリケーションサーバは、サーバノードのスケールアウトを容易にし及び冗長性を確保するために、ＡＣＴ−ＳＴＡＮＢＹで代替サーバを予め用意しておく高信頼性を有する固定的なアーキテクチャがある。この他に、ノードを分散配置して、分散配置されたノードを監視し、状態通知ノードが各ノードの状態を他のノードへ通知し、各ノードが互いの状態を把握しながら、障害が発生したノードの代替をするアーキテクチャが提案されている。

この様な分散配置型アプリケーションサーバの実装例として特許文献１に記載されるサーバアクセス制御システムがある。特許文献１に記載されるサーバアクセス制御システムでは、サーバは、全て同一のＩＰｖ６エニキャストアドレスとマルチキャストアドレスとを実装し、端末１からのアクセスはエニキャストアドレスを用いる。サーバは、端末１からのファイル要求に対し提供不可と判断した場合に、マルチキャストアドレスを用いて該ファイル要求内容を他のサーバに送信し、提供可能な旨を最初に受信したサーバのユニキャストアドレスをルーティング情報として端末１へ通知する。端末１は、ルーティング情報を受信した後、受信したエニキャストアドレスをルーティング情報とするＩＰｖ６拡張ヘッダを付加してエニキャストアドレス宛のメッセージを送信する。

＜一般的なアプリケーションサーバでの負荷分散・冗長管理技術＞
一般的なアプリケーションサーバにおいて、大量のリクエスト処理に対応するためにスケールアウトして処理能力を増やす場合、主に以下の二つの方法が採用される。

一つ目は、負荷分散装置による処理分散である。具体的には、アプリケーションサーバ群の前段にＬ４ＳＷやＬ７ＳＷ等の負荷分散装置を配置する。外部システムは、負荷分散装置のＩＰアドレスに対して処理要求を送信する。処理要求を受信した負荷分散装置は、後段に設置した各アプリケーションサーバの状態に従って処理を振り分ける。アプリケーションサーバをスケールアウトする場合、追加するアプリケーションサーバを負荷分散装置に登録する。負荷分散装置は、受信した処理要求を追加されたアプリケーションサーバに振り分けることによって、追加されたアプリケーションサーバは処理要求を受信する。

二つ目は、ネームサーバによるアプリケーションサーバのアドレスの管理である。具体的には、アプリケーションサーバ群のＩＰアドレスを管理するネームサーバを配置する。ネームサーバは、各アプリケーションサーバの状態を監視する。外部システムは、アプリケーションサーバへ処理要求を送信する前にアプリケーションサーバのＩＰアドレスをネームサーバに問い合わせ、応答で受信したＩＰアドレスに処理要求を送信する。アプリケーションサーバをスケールアウトする場合、追加するアプリケーションサーバをネームサーバに登録する。ネームサーバは、外部システムからのＩＰアドレスの問い合わせに対して、追加されたアプリケーションサーバのＩＰアドレスを応答することによって、追加されたアプリケーションサーバは処理要求を受信する。

＜一般的なアプリケーションサーバでの負荷分散ポリシ＞
一般的に、負荷分散技術を導入して複数のアプリケーションサーバを配置した場合、外部システムからのリクエストをどのサーバに割り振るかについて、主に以下の二つの方法が採用される。

一つ目は、ラウンドロビンである。具体的には、外部システムからのリクエストを、複数のアプリケーションサーバに順に振り分ける方式である。ラウンドロビンでは、外部システムからのリクエストを各アプリケーションサーバに均等に振り分けることができる。

二つ目は、アプリケーションサーバの負荷によって処理を振り分ける方法である。複数のアプリケーションサーバのＣＰＵ負荷、メモリ使用量、ネットワークの利用帯域など、アプリケーションサーバから取得できる情報を用いて、現在の負荷が低いアプリケーションサーバに処理要求を転送する。この方法では、各アプリケーションサーバの現在の負荷状態に応じて、負荷を効率よく分散できる（例えば、特許文献２参照）。

特開２００６−３３８６２４公報 特開２０１０−９４４９公報

前述した従来技術を用いた負荷分散では、アプリケーションサーバの前段に負荷分散装置又はネームサーバを導入する必要がある。

通常、外部システムの増加や処理要求量の増加に伴ってアプリケーションサーバを増設するが、負荷分散装置やネームサーバがボトルネックとなり、アプリケーションサーバの増設が限界に達する。また、負荷分散装置やネームサーバを配置することによって、システム内で管理する装置が増加して管理コストが高くなる。

さらに、特許文献１に記載された技術では、ファイルを提供可能と判断した場合に、サーバは、ファイル送信パケットとして要求されたファイルを指定されたアドレスから、端末へ送信する。その際、端末からのエニキャストアドレス宛のメッセージが自身のユニキャストアドレスへ到達されるようなルーティング情報をＩＰｖ６拡張ヘッダとして付加したファイル送信パケットを作成、送信する（段落［００２８］参照）。しかし、他のサーバの状況を考慮して、処理の可否を判断していない。

また、従来技術を用いた負荷分散では、ＣＰＵ負荷状態、メモリ使用量、ネットワーク帯域の利用量などの一般的な負荷計測値を用いることによって、サーバ全体の現在の負荷状態や、サーバ全体の過去の負荷状態の統計値を取得することができる。しかし、サーバ全体的の情報及び各サーバの情報では、将来において各サーバへ掛かる負荷状態の予測が困難で、負荷分散の効率を向上することができない。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、計算機システムであって、複数の外部システムからの要求によって処理を実行する複数の計算機を備え、前記複数の計算機の各々は、メモリと、前記メモリを参照するプロセッサと、他の計算機と通信するためのネットワークインタフェースと、を有し、同一ネットワークセグメント内の他の計算機と、前記各計算機が算出した受付重み統計値を共有しており、前記各計算機のプロセッサは、一つの前記外部システムから同一ネットワークセグメント内に同報されるブロードキャストを受信し、前記共有される受付重み統計値を参照して、前記受信したブロードキャストに応答するかを判定し、応答すると判定した場合、前記一つの外部システムに処理要求を送信させるために、前記ブロードキャストを送信した外部システムに応答を返信する。

本発明の代表的な実施の形態によれば、簡単な構成で計算機の負荷を分散することができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

第１の実施例のネットワークの概要を説明する図である。 第１の実施例のアプリケーションサーバ及び外部システムの物理的な構成を示すブロック図である。 第１の実施例の外部システムの機能ブロック図である。 第１の実施例のアプリケーションサーバの機能ブロック図である。 第１の実施例の処理カウント数を更新する処理のフローチャートである。 第１の実施例の受付重み統計値算出処理のフローチャートである。 第１の実施例の自ノード管理テーブルの構成例を示す図である。 第１の実施例の自ノード管理テーブルの構成例を示す図である。 第１の実施例の処理カウント管理テーブルの構成例を示す図である。 第１の実施例の受付重み統計値管理テーブルの構成例を示す図である。 第１の実施例の受付重み統計値管理テーブルの構成例を示す図である。 第１の実施例の実行処理管理テーブルの構成例を示す図である。 第１の実施例のキューレコード追加時の更新処理のフローチャートである。 第１の実施例のキューレコード削除時の更新処理のフローチャートである。 第１の実施例の処理要求管理キューの構成例を示す図である。 第１の実施例のアプリケーションサーバ間で情報を共有するシーケンス図である。 第１の実施例の他ノード管理テーブルの構成例を示す図である。 第１の実施例の他ノード管理テーブルの構成例を示す図である。 第１の実施例の処理シーケンスである。 第１の実施例の処理シーケンスである。 第１の実施例の処理要求送受信機能が実行する処理を示すフローチャートである。 第１の実施例の受信可否判定処理のフローチャートである。 第１の実施例の処理要求受信処理の詳細を示すフローチャートである。 第１の実施例の受付設定管理テーブルの構成例を示す図である。 第１の実施例の受付重み統計値管理テーブルの構成例を示す図である。 第１の実施例の受付重み統計値管理テーブルの構成例を示す図である。 第１の実施例の受付重み統計値算出処理のフローチャートである。 第１の実施例の受付重み統計値管理テーブルの構成例を示す図である。 第１の実施例の受付重み統計値管理テーブルの構成例を示す図である。

図１は、本発明の第１実施例のアプリケーションサーバ２と、該アプリケーションサーバ２にアクセスする外部システム６との間を接続するネットワークの概要を説明する図である。

まず、図１を用いて、本実施例のアプリケーションサーバ２（分散ノード）について、端末−サーバ間における通信のネットワークの概要、及びアプリケーションサーバ２とノードとの間のネットワークの概要を説明する。アプリケーションサーバ２−１からアプリケーションサーバｎ（２−ｎ）は、同一のネットワークセグメント７内のＩＰアドレスを持ち、ルータ４の配下の一つのセグメント内で接続している。また、アプリケーションサーバ２−１〜２−ｎを収容するネットワークセグメント内には、状態通知ノード１が設けられる。複数の外部システム６−１〜６−ｎは、ネットワーク５及びルータ４を経由して、各アプリケーションサーバ２−１〜２−ｎに処理要求を送信する。

ネットワーク５は、ＴＣＰ／ＩＰプロトコルを用いた、ＩＰネットワークでよいが、他の形式のネットワークでもよい。

図２は、第１実施例のアプリケーションサーバ２及び外部システム６の物理的な構成を示すブロック図であり、図３、図４にて後述するアプリケーションサーバ２及び外部システム６の機能ブロックを実現するためのハードウェアを示す。

アプリケーションサーバ２及び外部システム６は、ＣＰＵ１２、メモリ１３、ストレージ１６、インタフェース２０、２１を有する計算機である。

ＣＰＵ１２は、メモリ１３に格納されたアプリケーションプログラム１５から、その動作手順を読み出して、図３、図４に示した種々の処理モジュールの動作を実行する。メモリ１３は、ストレージ１６に格納されたプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。ストレージ１６は、例えば、磁気記憶装置、フラッシュメモリ等の大容量かつ不揮発性の記憶装置であり、ＣＰＵ１２によって実行されるプログラム及びプログラムの実行時に使用されるデータを格納する。すなわち、アプリケーションプログラム１５は、プログラムを起動する際に、ストレージ１６に格納されたアプリケーションプログラムファイル１８がコピーされることによって生成される。

ＣＰＵ１２が実行するプログラムは、リムーバブルメディア（ＣＤ−ＲＯＭ、フラッシュメモリなど）又はネットワークを介して計算機に提供され、非一時的記憶媒体であるストレージ１６に格納される。このため、計算機は、リムーバブルメディアからデータを読み込むインタフェースを有するとよい。

データベース２２及びメモリ１３上のアプリケーション情報一時格納領域２６は、各処理モジュールが動作する際に必要な情報を格納しており、ＣＰＵ１２は、この情報を必要に応じて読み出し及び書き込む。具体的には、ＣＰＵ１２は、インタフェース２１を経由して、データベース２２に格納されたデータを読み出し及び書き込む。

データベース２２は、例えば、磁気記憶装置、フラッシュメモリ等の大容量かつ不揮発性の記憶装置及び該記憶装置のデータの入出力を制御する制御システム（例えば、ＤＢＭＳ）によって構成される。データベース２２とアプリケーションサーバ２は物理的に異なる装置で構成しても、一つの装置内に構成してもよい。また、アプリケーションサーバ２及び外部システム６の各処理モジュールの一部をソフトウェアではなく、ハードウェアで構成してもよい。さらに、外部システム６は、必要に応じてデータベース２２を持ってもよいし、持たなくてもよい。

インタフェース２０は、所定のプロトコルに従って、他の装置との通信を制御するネットワークインタフェース装置である。また、アプリケーションサーバ２及び外部システム６は、インタフェース２０を経由して、物理的に異なる位置に配置された装置と通信する。

本実施例のアプリケーションサーバ２及び外部システム６の各々は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。

次に、図３、図４の機能ブロック図、図１５、図１６のシーケンス図、図１７の外部システム６の処理のフローチャート、及び図１８、図１９のアプリケーションサーバ２の処理のフローチャートを用いて、外部システム６がアプリケーションサーバ２に処理を要求するまでの動作を説明する。

図３は、第１実施例の外部システム６の機能ブロック図である。

外部システム６は、処理要求送信先アプリケーションサーバ管理機能３１、ブロードキャスト送受信機能３４、ユーザプログラム保持・実行機能３７及び処理要求送受信機能３９を有する。

処理要求送信先アプリケーションサーバ管理機能３１は、外部システム６が処理要求を送信するアプリケーションサーバ２の送信元情報（ＩＰアドレス、送信先ポート番号など）、及びアプリケーションサーバ２を特定するためのブロードキャスト送信の情報（ＩＰアドレス、ポート番号など）を管理する機能ブロックである。

処理要求送信先アプリケーションサーバ管理機能３１は、送信先ノード管理モジュール３２を有する。送信先ノード管理モジュール３２は、アプリケーションサーバ２の間の通信状況に合せでデータを登録及び削除する。具体的には、ブロードキャスト送信やブロードキャスト応答を受信した時、アプリケーションサーバ２のＩＰアドレスやポート番号を記録する。また、アプリケーションサーバ２に処理要求が到達しなかった時、記録したＩＰアドレスやポート番号を削除する。

ブロードキャスト送受信機能３４は、アプリケーションサーバ２を特定するためのブロードキャストの送受信を行う機能ブロックであり、ブロードキャスト情報生成・結果解析モジュール３５及びブロードキャスト送受信モジュール３６を有する。ブロードキャスト情報生成・結果解析モジュール３５は、送信するブロードキャストのデータを生成し、受信したブロードキャスト応答のデータを解析する。ブロードキャスト送受信モジュール３６は、ブロードキャストパケットを送信し、応答を待ち受ける。

ユーザプログラム保持・実行機能３７は、外部システム６が実行するプログラムを保持し、実行する機能ブロックであり、保持されたユーザプログラム３８を適時実行する。

処理要求送受信機能３９は、外部システム６からアプリケーションサーバ２への処理要求を送受信する機能ブロックである。処理要求送受信機能３９は、処理要求先判定モジュール４０、処理要求生成・処理結果解析モジュール４１及び処理要求送受信モジュール４２を有する。

処理要求先判定モジュール４０は、ユーザプログラム３８からアプリケーションサーバ２へ送信する処理要求を受けた時、処理要求の宛先となるアプリケーションサーバ２のＩＰアドレス及びポート番号を、送信先ノード管理モジュール３２から取得する。処理要求生成・処理結果解析モジュール４１は、送信する処理要求のデータ作成及び受信した処理結果応答のデータを解析する。処理要求送受信モジュール４２は、処理要求パケットを送信し、応答を待ち受ける。

図４は、第１実施例のアプリケーションサーバ２の機能ブロック図である。

アプリケーションサーバ２は、ブロードキャスト管理機能５１、ブロードキャスト送受信機能５５、アプリケーションサーバ状態管理機能５８、分散状態送受信機能６３、要求処理実行機能６６及び処理要求送受信機能７１を有する。

ブロードキャスト管理機能５１は、外部システム６から受信したブロードキャストに応答を返信するか判定する機能ブロックであり、受付設定管理テーブル５２、受付設定管理部５３及びブロードキャスト応答可否判定部５４を有する。受付設定管理テーブル５２は、ブロードキャストパケットを待ち受けるポート番号を管理するためのテーブルである（図２０参照）。受付設定管理部５３は、受付設定管理テーブル５２からデータを取得する。ブロードキャスト応答可否判定部５４は、自ノード及び他ノードの状態に基づいて、外部システム６から受信したブロードキャストに応答するかを判定する。

ブロードキャスト送受信機能５５は、外部システム６からブロードキャストを受信し、受信したブロードキャストに対する応答を返信する機能ブロックであり、受信ブロードキャスト分析・応答生成モジュール５６及びブロードキャスト受信・応答返信モジュール５７を有する。受信ブロードキャスト分析・応答生成モジュール５６は、受信したブロードキャストパケットのデータを解析し、受信したブロードキャストパケットに返信する応答のデータを生成する。ブロードキャスト受信・応答返信モジュール５７は、ブロードキャストパケットを待ち受け、ブロードキャストパケットへの応答パケットを送信する。

アプリケーションサーバ状態管理機能５８は、他ノードの状態を保持し、自ノードの状態を計算及び保持する機能ブロックであり、他ノード管理テーブル５９、他ノード状態管理部６１、自ノード管理テーブル６０及び自ノード状態管理部６２を有する。他ノード管理テーブル５９は、他ノードの状態を保持するテーブルである（図１４Ａ参照）。また、他ノード管理テーブル５９は、図示を省略する処理カウント管理テーブル１３１（図８参照）及び受付重み統計値管理テーブル３７１（図９Ａ参照）を含む。他ノード状態管理部６１は、他ノード管理テーブル５９のデータを入出力する。自ノード管理テーブル６０は、自ノードの状態を保持するテーブルである（図７Ａ参照）。自ノード状態管理部６２は、自ノードの処理状況に応じて自ノードの状態を算出し、算出した自ノードの状態を保持する。また、自ノード状態管理部６２は、自ノードの状態が変化した場合、自ノードの状態を他ノードへ通知する。

分散状態送受信機能６３は、他ノードの状態を受信し、自ノードの状態が変化した場合に他ノードへ通知する機能ブロックであり、状態解析・生成モジュール６４及び他ノード状態送受信モジュール６５を有する。状態解析・生成モジュール６４は、受信した他ノードの状態のデータを解析し、送信する自ノードの状態のデータを生成する。他ノード状態送受信モジュール６５は、他ノードからの状態通知を待ち受け、自ノードの状態の通知パケットを送信する。

要求処理実行機能６６は、アプリケーションサーバ２内で実行する処理モジュールを保持し、外部システム６からの要求に応じて処理を実行する機能ブロックであり、実行処理管理テーブル６７、実行処理管理部６８及び要求処理実行部７０を有する。実行処理管理テーブル６７は、実行する処理を保持するテーブルである（図１０参照）。実行処理管理部６８は、実行処理管理テーブル６７で管理される処理に関する情報を入出力する。要求処理実行部７０は、外部システム６から受けた処理要求に対応する処理のモジュールを取得して、実行する。

処理要求送受信機能７１は、外部システム６から処理要求を受信し、処理結果を応答する機能ブロックであり、処理要求管理キュー７２、処理要求解析・処理結果返信モジュール７３及び処理要求送受信モジュール７４を有する。処理要求管理キュー７２は、外部システム６から受信した複数の処理要求の状態を管理する（図１２参照）。具体的には、外部システム６から受信した処理要求はキュー７２にキューイングされ、処理応答を返信すると対応する処理要求をキュー７２から削除する。処理要求解析・処理結果返信モジュール７３は、受信した処理要求のデータを解析し、返信する応答のデータを生成する。処理要求送受信モジュール７４は、外部システム６からの処理要求パケットを待ち受け、処理結果応答を送信する。

次に、外部システム６がアプリケーションサーバ２に処理を要求する動作を説明する。

まず、図１５のステップ２５５で、外部システム６がアプリケーションサーバ２へ処理要求を送信したい旨の要求が、ユーザプログラム３８（図３参照）内で発生する。これは、例えば、Ｊａｖａプログラム（Ｊａｖａは登録商標、以下同じ。）の場合、図３に示す処理要求送信先アプリケーションサーバ管理機能３１、ブロードキャスト送受信機能３４、処理要求送受信機能３９を包含したプログラムライブラリをユーザプログラム３８にインポートして、ユーザプログラム３８からこれらのライブラリを参照可能にする。そして、ユーザプログラム３８内で、インポートしたライブラリのメソッドを呼び出すことによって要求を発生することができる。

図１７は、発生した処理要求を受け付けた後に、処理要求送受信機能３９が実行する処理を示すフローチャートである。

まず、ステップ２８１で、処理要求送受信機能３９が処理要求を受け付けると、処理要求生成・処理結果解析モジュール４１はアプリケーションサーバ２へブロードキャスト送信をする処理要求のメッセージを生成する（ステップ２８２）。次に、処理要求送受信モジュール４２は、処理要求先判定モジュール４０を経由して、送信先ノード管理モジュール３２に処理要求先を取得する（ステップ２８３）。送信先ノード管理モジュール３２は、受け付けた処理要求を送信するアプリケーションサーバ２の情報（例えば、ＩＰアドレス）を保持しているかを判定する（ステップ２８４）。送信先のアプリケーションサーバ２の情報を保持している場合、ステップ２９０へ進み、処理要求先を決定し、決定された処理要求先を処理要求先判定モジュール４０を経由して、処理要求送受信モジュール４２へ返信する。

一方、ステップ２８４で、送信先のアプリケーションサーバ２の情報を保持していない場合、アプリケーションサーバ２が存在するネットワークセグメントのブロードキャストＩＰアドレス及びネットワークポートにブロードキャストパケットを送信する（ステップ２８５）。このアプリケーションサーバ２が存在するネットワークセグメントのブロードキャストＩＰアドレス及びネットワークポートは、予め外部システム６に設定ファイルとして保持される。例えば、図１に示す様に、アプリケーションサーバ２のネットワークセグメントが１９２．１６８．０．０／２４である場合、ブロードキャストアドレスは１９２．１６８．０．２５５となる。

図１５のＳｅｑ１：初回処理要求２５５のシーケンスを用いて、外部システム６が処理要求をアプリケーションサーバ２に送信する正常系の動作（ブロードキャストの送信、処理要求の送信、結果を正常に受信）を説明する。

前述したステップ２８４の処理は、図１５のステップ２３２の要求先判定に対応する。外部システム６が送信したブロードキャストパケット２３３−１は、一旦ルータ４で受信した後、ルータ４がネットワークセグメント配下の全てのＩＰアドレス（アプリケーションサーバ２）にブロードキャストパケット２３３−２を送信する。

各アプリケーションサーバ２では、ブロードキャスト受信・応答返信モジュール５７が、受付設定管理テーブル５２に予め設定されているＩＰアドレス及び受付ポート番号で待ち受けをしている。

図２０は、受付設定管理テーブル５２の構成例を示す図である。

受付設定管理テーブル５２は、設定項目に対応する値を保持するテーブルであり、受付設定管理部５３によってアクセスされる。例えば、レコード３４２にはＩＰアドレスが設定され、レコード３４３には受付ポート番号が設定される。

外部システム６が送信するブロードキャストパケットのポート番号は、アプリケーションサーバ２が待ち受けているポート番号（レコード３４３の値）と一致しているので、アプリケーションサーバ２は送信されたブロードキャストパケットを受信する。

次に、アプリケーションサーバ２は、受信可否を判定する（ステップ２３４）。この受信可否判定の詳細を図１８を用いて説明する。

図１８は、受信可否判定処理のフローチャートである。

まず、アプリケーションサーバ２では、ブロードキャスト受信・応答返信モジュール５７がブロードキャストパケットを受信する（ステップ３０１）。

次に、受信ブロードキャスト分析・応答生成モジュール５６が、ブロードキャストパケットの内容を解析し、受信したブロードキャストパケットのＩＰアドレスから、ブロードキャストパケットを送信した外部システム６を判定し、当該ブロードキャストパケットに応答すべきかの判定をブロードキャスト応答可否判定部５４に依頼する（ステップ３０２）。

ブロードキャスト応答可否判定部５４は、判定の依頼を受けると、アプリケーションサーバ状態管理機能５８にアクセスして、アプリケーションサーバ状態管理機能５８内の処理カウント管理テーブル１３１（図８参照）及び受付重み統計値管理テーブル３７１（図９Ａ参照）を参照する（ステップ３０３）。

図８は、処理カウント管理テーブル１３１の構成例を示す図である。

処理カウント管理テーブル１３１は、処理要求を受け付けたプロセスの数を保持するテーブルであり、他ノード状態管理部６１によってアクセスされる。処理カウント管理テーブル１３１は、外部システムのＩＰアドレス１３２、処理１３３〜１３５及び重み合計値１３６のカラムを有する。すなわち、処理カウント管理テーブル１３１は、全ての外部システム６のＩＰアドレスをカラム１３２に記録したレコードを保持している。つまり、処理カウント管理テーブル１３１は、集計期間において処理要求を受け付けた外部システム６の数のレコードを保持する。

図９Ａ、図９Ｂは、受付重み統計値管理テーブル３７１の構成例を示す図である。

受付重み統計値管理テーブル３７１は、外部システム６毎の受付重み統計値を管理するテーブルであり、他ノード状態管理部６１によってアクセスされる。受付重み統計値管理テーブル３７１は、外部システムのＩＰアドレス３７２に対応して受付重み統計値３７３を保持する。受付重み統計値管理テーブル３７１は、処理カウント管理テーブル１３１と同様に、全ての外部システム６のＩＰアドレスをカラム３７２に記録したレコードを保持している。つまり、受付重み統計値管理テーブル３７１は、集計期間において処理要求を受け付けた外部システム６の数のレコードを保持する。

図１８に戻って説明を続ける。受信したブロードキャストパケットを送信した外部システム６のＩＰアドレスと、処理カウント管理テーブル１３１に記録されたＩＰアドレス１３２と、受付重み統計値管理テーブル３７１に記録されたＩＰアドレス３７２とを比較することによって、ブロードキャストパケットを送信した外部システム６のＩＰアドレスに対応するレコードが各テーブルに存在するかを判定する（ステップ３０４）。

いずれかのテーブルにレコードが存在する場合、各テーブルから該当レコードを削除して（ステップ３０５）、ステップ３０６に進む。一方、いずれのテーブルにもレコードが存在しない場合、ステップ３０６に進む。

ステップ３０６では、ブロードキャスト応答可否判定部５４は、自ノード状態管理部６２を経由して自ノード管理テーブル６０を参照することによって、自ノードの負荷状態を取得する。

図７Ａは、自ノード管理テーブル６０の構成例を示す図である。

自ノード管理テーブル６０は、設定項目１２１と値１２２とを組み合わせたレコードによって自ノードの状態を管理するテーブルであり、自ノード状態管理部６２によってアクセスされる。例えば、レコード１２３にはノード名が設定され、レコード１２４にはＩＰアドレスが設定され、レコード１２５には処理要求受け付けポート番号が設定され、レコード１２６には受付重み統計値が設定され、レコード１２７には受付重み現在値が設定され、レコード１２８には現在の受付可否状態が設定され、レコード１２９には状態通知ノード１のＩＰアドレスが設定される。

例えば、レコード１２８の現在の受付可否状態の値によって、ノードの負荷状態を知ることができる。レコード１２８の値が「受付可」である場合、プロセスの受け付けが可能な低い負荷状態である。また、レコード１２８の値が「受付不可」である場合、プロセスの受け付けが不可能な高い不可状態である。

図１８に戻って説明を続ける。ステップ３０７では、ステップ３０６で取得した負荷状態（レコード１２８の現在の受付可否状態）の値が「受付不可」である場合、ステップ３１４に進み、ブロードキャストパケットに対して応答せずに、受信可否判定処理を終了する。

一方、ステップ３０６で取得した負荷状態の値が「受付可」である場合、ステップ３０８へ進み、他ノード状態管理部６１を経由して他ノード管理テーブル５９を参照して、自ノードの受付重み統計値と他ノードの受付重み統計値とを比較する。

図１４Ａは、他ノード管理テーブル５９の構成例を示す図である。

他ノード管理テーブル５９は、他ノードの状態を管理するためのテーブルであり、他ノード状態管理部６１によってアクセスされる。他ノード管理テーブル５９は、ノード名２１２、ＩＰアドレス２１３、状態２１４、受付重み統計値２１５、受付可否状態２１６及び処理要求ポート番号２１７のカラムを有する。

ノード名２１２は他ノードの名称であり、ＩＰアドレス２１３は他ノードのＩＰアドレスである。状態２１４は、他ノードが現在稼働中であるかを示し、「稼働中」又は「未稼働」のいずれかが記録される。受付重み統計値２１５は、他ノードの受付重み統計値である。受付可否状態２１６は、他ノードの現在の状態を示し、「受付可」又は「受付不可」のいずれかが記録される。

図１８に戻って説明を続ける。ステップ３０８では、他ノード管理テーブル５９のレコードのうち、状態２１４が「稼働中」であり且つ受付可否状態２１６が「受付可」であるノードを選択し、選択されたノードの受付重み統計値２１５の値を取得する。そして、ステップ３０６で取得した自ノード管理テーブル６０から取得した自ノードの受付重み統計値１２６の値と、取得した他ノードの受付重み統計値とを比較する。例えば、自ノードの受け付け重み統計値の合計値を示すレコード１２７の値は「７８２」である。また、他ノード管理テーブル５９からは、レコード２１８の受付重み統計値は「２２００」であり、レコード２２１の受付重み統計値の合計値は「１０２２」である。

なお、対象ノードについて、図９Ａに示す外部システム単位での受付重み統計値を比較してもよい。また、図２１に示す処理毎の受付重み統計値を比較してもよい。

次に、ステップ３０９では、自ノードの受付重み統計値と他ノードの受付重み統計値とを比較した結果、自ノードが要求を受け付けるかを判定する。具体的には、自ノードの受付重み統計値が最小値であるかを判定する。自ノードの受付重み統計値が最小値ではない場合、ステップ３１４へ進み、ブロードキャストパケットに対して応答せずに、受信可否判定処理を終了する。一方、自ノードの受付重み統計値が最小値である場合、ステップ３１０へ進む。前述した例では、自サーバの受付重み統計値は「７８２」であり、他ノードの受付重み統計値が「２２００」、「１０２２」であるため、自ノードが最小値があると判定され、ステップ３１０へ進む。

なお、ステップ３０８、３０９では、図１４に示す他ノード管理テーブル５９の受付重み統計値２１５の値を比較しているが、よりきめ細やかな比較を行うために、各ノードが共有する受付重み統計値管理テーブル（図９Ａ）で管理される外部システム毎の受付重み統計値や、受付重み統計値管理テーブル（図２１Ａ、図２１Ｂ）で管理される処理毎の受付重み統計値を用いて比較してもよい。

例えば、図２３に示す外部システム毎の受付重み統計値をノード間で共有している場合、最も処理負荷が大きい外部システム６の重み統計値を各ノードの外部システム毎の受付重み統計値管理テーブルから選択する。そして、ステップ３０９で、選択された重み統計値が最小のノードが要求を受けると判定してもよい。図２３に示す例では、アプリケーションサーバ２−１についてのテーブル４０１のレコード４１１と、アプリケーションサーバ２についてのテーブル４０２のレコード４１２と、アプリケーションサーバｎについてのテーブル４０３のレコード４１３とを比較する。その結果、アプリケーションサーバ２−１の重み統計値「４８９」が最小であるため、アプリケーションサーバ２−１が要求を受けると判定する。また、アプリケーションサーバ２〜ｎは、重み統計値が最小ではないため、要求を受けないと判定する。

図２３に示す受付重み統計値管理テーブルでは、各アプリケーションサーバの受付重み統計値の合計値４１４〜４１６は「１１２４」、「７７９」、「７１９」であるため、合計値で判定すればアプリケーションサーバｎが要求を受けると判定できる。しかし、特定の外部システム６からの負荷の集中度を重視した場合、アプリケーションサーバｎはＩＰアドレスが４３．５７．１９３．２３８の外部システム６から高い頻度で処理要求を受けており、一つの外部システム６からのアクセスの集中度は、アプリケーションサーバ２−１より高い。

また、例えば、図２４に示す処理毎の受付重み統計値をノード間で共有している場合、ステップ３０９で、処理「ｐ１」の要求数が最小のノードが処理を受けると判定してもよい。図２４に示す例では、アプリケーションサーバ２−１についてのテーブル４２１のレコード４３１と、アプリケーションサーバ２についてのテーブル４２２のレコード４３２と、アプリケーションサーバｎについてのテーブル４２３のレコード４３３とを比較する。その結果、アプリケーションサーバ２−１の要求数「１５」が最小であるため、アプリケーションサーバ２−１が要求を受けると判定する。また、アプリケーションサーバ２〜ｎは、要求数が最小値ではないため、要求を受けないと判定をする。

このように重みの比較方法や、比較する値を変えることによって、処理要求を受けるアプリケーションサーバ２の全体の負荷だけでなく、様々な要素を用いて判定することができる。

図１８に戻って説明を続ける。ステップ３１０では、ブロードキャスト応答可否判定部５４が、ブロードキャストパケットに返信するために、自ノード状態管理部６２を経由して自ノード管理テーブル６０から応答情報を取得する。具体的には、ノード名１２３、ＩＰアドレス１２４及び処理要求受付ポート番号１２５を自ノード管理テーブル６０（図７Ａ）から取得する。ブロードキャスト応答可否判定部５４は、取得した情報を受信ブロードキャスト分析・応答生成モジュール５６へ送信する。

次に、受信ブロードキャスト分析・応答生成モジュール５６は、受信した情報に基づいてブロードキャストパケットへの応答メッセージを生成する（ステップ３１１）。そして、ブロードキャスト受信・応答返信モジュール５７は、送信元の外部システム６のＩＰアドレス及びポート番号に応答を返信し（ステップ３１２）、受信可否判定処理を終了する（ステップ３１３）。

ステップ３１２で返信されたブロードキャスト応答パケットは、ルータ４を経由して外部システム６に到達する（図１５のステップ２３５）。

外部システム６は、図１７のステップ２８５でブロードキャストパケットを送信した後、ブロードキャスト送受信モジュール３６にて、アプリケーションサーバ２からの応答を待ち受ける（ステップ２８６）。ブロードキャスト応答を受信していない場合、ステップ２８７に進み、タイマがタイムアウトしたかを判定する。タイムアウトまでの時間は外部システム６に予め設定されている。また、外部システム６はステップ２８５でブロードキャスト情報を送信してからの経過時刻をカウントする。そして、カウントされた経過時間が予め設定されたタイムアウト時間を超過した場合、処理要求送信処理は異常終了する（ステップ２８８）。

具体的には、ブロードキャスト送受信モジュール３６は、タイムアウトを検知すると、タイムアウトをブロードキャスト情報生成・結果解析モジュール３５に送信する。ブロードキャスト情報生成・結果解析モジュール３５は、タイムアウトをユーザプログラム３８に送信する。例えば、Ｊａｖａプログラムの場合、ブロードキャスト情報生成・結果解析モジュール３５は、タイムアウトの状態を例外としてユーザプログラム３８にスローする。ユーザプログラム３８は例外をキャッチするプログラムを作成することで、スローされたタイムアウトを検知することができる。

カウントされた経過時刻が予め設定されたタイムアウト時刻を超過していない場合、ステップ２８６に戻り、ブロードキャスト応答の受信を繰り返し判定する。

一方、ステップ２８６で、ブロードキャスト応答の受信を判定した場合、ステップ２８９へ進む。ステップ２８９では、送信先ノード管理モジュール３２は、受信したブロードキャスト応答の内容をメモリに格納することによって、処理要求先を登録する（図１５のステップ２３６）。そして、受信したブロードキャスト応答の情報を処理要求先判定モジュール４０へ送信する。処理要求先判定モジュール４０は、処理要求先を決定し（ステップ２９０）、処理要求送受信モジュール４２は、決定された処理要求先に処理要求を送信する（ステップ２９１）。

外部システム６が送信した処理要求は、ルータ４を経由して、ブロードキャストパケットに応答したアプリケーションサーバ２へ到達する（図１５のステップ２３７）。

そして、処理要求を受信したアプリケーションサーバ２は、処理要求を受けるかを判定し（ステップ２３８）、処理を実行する（ステップ２３９）。以下、処理要求受付判定から実行された処理結果の返信について説明する。

図１９は、ステップ２３８及び２３９の処理（処理要求受信処理）の詳細を示すフローチャートである。

アプリケーションサーバ２の処理要求送受信モジュール７４が処理要求を受けると（ステップ３２１）、処理要求解析・処理結果返信モジュール７３は、受信した処理要求の内容を解析する。具体的には、処理要求解析・処理結果返信モジュール７３は、実行処理管理部６８を経由して実行処理管理テーブル６７を参照して、受信した処理要求の種類を判定し、メッセージに対応する処理を特定する（ステップ３２２）。

図１０は、実行処理管理テーブル６７の構成例を示す図である。

実行処理管理テーブル６７は、処理１４２、メッセージ１４３及び各処理の重み係数１４４のカラムを有するテーブルで、実行処理管理部６８によってアクセスされる。アプリケーションサーバ２では、起動前に実行処理管理テーブル６７が設定され、処理モジュールが実行可能なようにデプロイされる。

例えば、外部システム６からメッセージ「ｍｓｇＰ１」が付与された処理要求を受けた場合、ステップ３２２でメッセージの内容を解析し、実行処理管理テーブル６７の処理１４２が「ｍｓｇＰ１」であるレコードを選択する。本例では、レコード１４５が選択され、メッセージ「ｍｓｇＰ１」はアプリケーションサーバ２で管理するメッセージであり、対象プロセスが「ｐ１」であるため、処理を実行する。一方、実行処理管理テーブル６７にレコードが存在しないメッセージを受信した場合、当該アプリケーションサーバ２で処理が実行できないので、エラー応答を外部システム６へ返信する。

図１９に戻って説明を続ける。ステップ３２２で処理要求内容の解析が正常に終了すると、処理要求解析・処理結果返信モジュール７３は、自ノード状態管理部６２を経由して自ノード管理テーブル６０（図７Ａ）の受付可否状態１２８の値を参照し、自ノードの現在の受付可否を判定する（ステップ３２３）。

次に、ステップ３２４で、自ノードの受付可否状態の値が「受付可」であるかを判定する。自ノードの受付可否状態の値が「受付可」である場合、ステップ３２７に進み、処理要求を処理要求管理キュー７２へ格納する。その後、処理要求受信処理を終了する（ステップ３２８）。

要求処理実行部７０は、キュー７２へ格納された処理要求を、順次、取得して処理する。要求処理実行部７０は、キュー７２から取得した処理要求の処理結果を処理要求管理キュー７２を経由して処理要求解析・処理結果返信モジュール７３に送る。処理要求解析・処理結果返信モジュール７３は、処理結果に基づいて返信情報を生成し、処理要求送受信モジュール７４が外部システム６へ応答を返信する。

アプリケーションサーバ２から返信された処理結果応答メッセージは、ルータ４を経由して外部システム６へ転送される（図１５のステップ２４０）。

一方、ステップ３２４で、自ノードの受付可否状態の値が「受付不可」である場合の処理は、図１６のＳｅｑ３：アプリケーションサーバ要求受信拒否（代替要求先ノード付与）２７５のシーケンスを用いて後述する。

外部システム６は、図１７のステップ２９１で処理要求を送信すると、処理要求の応答を待ち受け、処理要求の応答を受信したかを判定する（ステップ２９２）。そして、外部システム６は、処理要求の応答を受信しない場合、ステップ２９４に進み、タイマがタイムアウトしたかを判定する。タイムアウトまでの時間は外部システム６に予め設定されている。また、外部システム６はステップ２９１で処理要求を送信してからの経過時刻をカウントする。そして、カウントされた経過時刻が予め設定されたタイムアウト時刻を超過していない場合、ステップ２９２に戻り、処理要求の応答の受信を繰り返し判定する。

一方、カウントされた経過時間が予め設定されたタイムアウト時間を超過した場合、ステップ２９５に進み、処理要求先としてメモリに記録している情報は無効であるため、処理要求先の情報を削除する。この具体的なシーケンスは、図１５のＳｅｑ２：アプリケーションサーバダウン時２５６のシーケンスを用いて後述する。

ステップ２９２で処理結果を受信したと判定された場合、受信した応答が正常かを判定する（ステップ２９６）。正常な応答を受信した場合、受信した応答（すなわち、処理の結果）を処理要求生成・処理結果解析モジュール４１を経由してユーザプログラム３８へ返信し、処理要求送信処理を終了する（ステップ２９３）。

一方、ステップ２９６にて、拒否応答を受信したと判定された場合、代替となるアプリケーションサーバ２の情報を取得し（ステップ２９７）、ステップ２８９へ戻る。この処理の詳細は、図１６のＳｅｑ３：アプリケーションサーバ要求受信拒否（代替要求先ノード付与）２７５のシーケンスを用いて後述する。

次に、図１５のＳｅｑ２：アプリケーションサーバダウン時２５６のシーケンスを参照して、外部システム６がアプリケーションサーバ２宛に処理要求を送信したが、アプリケーションサーバ２に処理要求が到達しないので、再度ブロードキャストして、処理を行うアプリケーションサーバ２を特定する動作を説明する。Ｓｅｑ２の処理要求受付（ステップ２４１）から要求先判定（ステップ２４２）、処理要求送信（ステップ２４３−１）までの処理は、前述のＳｅｑ１の処理要求受付（ステップ２３１）から処理要求送信（ステップ２３７）と同じであるため、説明は省略する。

例えば、外部システム６が処理要求先として特定しているアプリケーションサーバ２−ｎがダウンした場合（ステップ２４４）、外部システム６が送信した処理要求は宛先のアプリケーションサーバ２−ｎに届かない（ステップ２４３）。このため、前述した図１７のステップ２９４でタイムアウトと判定される。この場合、メモリに登録している処理要求先の情報は無効であるため、外部システム６は処理要求先の情報を削除する（図１７のステップ２９５、図１５のステップ２４５）。

その後、図１７においてステップ２８３へ戻り再度処理要求先の存在を判定するが、ステップ２９５で、先に決定された処理要求先のアプリケーションサーバ２の情報を既に削除しているため、ステップ２８４の判定はＮとなり、ブロードキャスト情報を再度送信する（ステップ２８５）。すなわち、図１５のステップ２４６で要求先を判定し、ブロードキャストパケットを送信する（ステップ２４７−１）。その後のシーケンスは、ステップ２３３−１でブロードキャストパケットを送信した後のシーケンスと同じである。

しかし、アプリケーションサーバ２−ｎはダウンしているため、ステップ２４７−２のブロードキャストは受信できない。一方、ブロードキャストパケットを受信した各アプリケーションサーバ２は、ステップ２３４と同様に受信可否を判定する（ステップ２４８）。判定処理の詳細は前述と同じである。この受信可否判定２４８で、アプリケーションサーバ２−１が受信すると判定した場合、ブロードキャスト応答が外部システム６に転送される（ステップ２４９）。外部システム６は新たな処理要求先としてアプリケーションサーバ２−１の情報を登録し（ステップ２５０）、アプリケーションサーバ２−１に処理要求を送信する（ステップ２５１）。アプリケーションサーバ２−１は、処理要求を受信すると、処理要求を受けるかを判定し（ステップ２５２）、処理を実行し（ステップ２５３）、処理結果応答メッセージを送信する。アプリケーションサーバ２−１から返信された処理結果応答メッセージは、ルータ４を経由して外部システム６へ転送される（ステップ２５４）。

以上に説明した処理によって、処理要求から処理結果返信までのシーケンスが終了する。

次に、図１６のＳｅｑ３：アプリケーションサーバ要求受信拒否（代替要求先ノード付与）２７５のシーケンスを参照して、外部システム６が拒否応答を受信して、代替の処理要求先に対して処理要求を送信する動作を説明する。図１６の処理要求受付（ステップ２６１）から要求先判定（ステップ２６２）、処理要求送信（ステップ２６３）までの処理は、前述のＳｅｑ１の処理要求受付（ステップ２３１）から処理要求送信（ステップ２３７）と同じであるため、説明は省略する。

アプリケーションサーバ２−ｎが処理要求を受けると判定すると、図１９に示すフローチャートの処理を実行する。そして、ステップ３２４で「受付不可」と判定された場合（ステップ２６４）、Ｓｅｑ３のシーケンスを実行する可能性がある。

図１９のフローチャートを参照して、アプリケーションサーバ２の動作を説明する。

アプリケーションサーバ２は、ステップ３２４で値が「受付不可」であった場合、ステップ３２５に進む。

ステップ３２５では、図１８のステップ３０８と同様に、他ノード状態管理部６１を経由して他ノード管理テーブル５９のレコードを取得し、取得したレコードを比較する。なお、ステップ３２５では、比較対象に自ノードは含めない。これは、ステップ３２４で自ノードは現在の受付可否状態が「受付不可」となっていることを確認しているためである。

次に、ステップ３２５での比較結果に基づいて、対象となる他ノードが存在するかを判定する（ステップ３２６）。処理を実行可能なノードが存在する場合、代替サーバの情報を外部システム６に送信する前に、受付重み統計値を代替先のアプリケーションサーバ２−１に送信する（ステップ３３２）。これは、代替先のアプリケーションサーバ２が外部システム６から処理要求を受ける際に、代替前のアプリケーションサーバ２が管理していた受付重み統計値を引き継ぎ、ブロードキャストパケットへの応答可否判定で活用するためである。

具体的には、まず、他ノード状態管理部６１を経由して他ノード管理テーブル５９を参照し、ステップ３２２で解析した外部システム６のＩＰアドレスと、処理カウント管理テーブル１３１の外部システム１３２と、受付重み統計値管理テーブル３７１の外部システム３７２とが一致するレコードを抽出する。例えば、処理要求に含まれる外部システム６のＩＰアドレスが「１９２．１６８．１．２１」である場合、処理カウント管理テーブル１３１（図８）のレコード１３７及び受付重み統計値管理テーブル３７１（図９Ａ）のレコード３７４が該当する。

次に、状態解析・生成モジュール６４が、これらのレコードに基づいて、代替先のアプリケーションサーバ２へ送信する受付重み統計値を生成する。他ノード状態送受信モジュール６５は、生成した受付重み統計値を代替先のアプリケーションサーバ２に送信する。例えば、図１６に示す場合、アプリケーションサーバ２−ｎがアプリケーションサーバ２−１を代替サーバとして選択しており、アプリケーションサーバ２−１へ受付重み統計情報を送信して、処理を要求した外部システム６の情報を通知する（ステップ２６５）。状態解析・生成モジュール６４は、他ノード状態管理部６１を経由して他ノード管理テーブル５９へアクセスし、他ノード管理テーブル５９（図１４）のＩＰアドレス２１３から、送信先のアプリケーションサーバ２−１のＩＰアドレスを取得する。

アプリケーションサーバ２−１では、他ノード状態送受信モジュール６５が、受付重み統計値を受信し、受信した受付重み統計値は状態解析・生成モジュール６４を経由して、他ノード状態管理部６１が他ノード管理テーブル５９内の処理カウント管理テーブル１３１（図８）及び受付重み統計値管理テーブル３７１（図９Ａ）にレコードを追加する（ステップ２６６）。

図１９に戻って、アプリケーションサーバ２−ｎが実行する処理の説明を続ける。アプリケーションサーバｎでは、ステップ３３２で受付重み統計値を送信した後、処理要求解析・処理結果返信モジュール７３が受付を拒否する応答を生成する（ステップ３２９）。生成される応答は、代替ノードとしてステップ３２５で比較して特定したノードのノード名、ＩＰアドレス及び処理要求受付ポート番号を含む。具体的には、処理要求解析・処理結果返信モジュール７３は、他ノード管理テーブル５９（図１４）からノード名２１２、ＩＰアドレス２１３及び処理要求ポート番号２１７の値を取得し、要求受付拒否応答に含める。この処理は、図１６の代替要求受付ノード情報付与２６７に該当する。処理要求送受信モジュール７４は、生成した応答メッセージを外部システム６へ送信する（ステップ３３０）。その後、処理要求受信処理を終了する（ステップ３３１）。

ステップ３３０で外部システム６へ送信された要求受付拒否応答は、図１６のステップ２６８にて、ルータ４を経由して外部システム６へ到達する。

外部システム６は、図１７に示すステップ２９２で、処理要求の応答を待ち受けている。外部システム６は、ステップ２６８で応答が到達すると、受信した応答が正常かを判定する（ステップ２９６）。しかし、この応答は拒否応答であるため、ステップ２９６ではＮと判定され、代替となるアプリケーションサーバ２の情報を拒否応答メッセージから取得する（ステップ２９７）。そして、メモリに登録している処理要求先の情報は不要であるため、外部システム６は処理要求先の情報を削除する（ステップ２９８）。その後、ステップ２８９へ戻り、代替の処理要求先を登録する。ステップ２９７で取得した代替要求先の情報とステップ２８６で受信したブロードキャスト応答の情報は同じ情報である。具体的には、他ノード管理テーブル５９（図１４）のノード名２１２、ＩＰアドレス２１３及び処理要求ポート番号２１７を登録する。この処理は、図１６の要求先削除２６９、要求先登録２７０に該当する。

その後のシーケンス（ステップ２７１〜２７４）は、Ｓｅｑ１：初回処理要求２５５のシーケンス（ステップ２３７〜２４０）と同じである。すなわち、外部システム６は、代替要求先に処理要求を送信する（ステップ２７１）。代替先のアプリケーションサーバ２−１は、処理要求受付可否を判定し（ステップ２７２）、要求された処理を実行し（ステップ２７３）、処理結果（正常応答）を外部システム６へ応答する（ステップ２７４）。

次に、受付重み統計値、受付重み現在値をアプリケーションサーバ２が算出する処理を説明する。

図１２は、処理要求管理キュー７２の構成例を示す図である。

キュー７２は、送信元となる外部システムのＩＰアドレス１７２、受信メッセージ１７３、処理１７４、状態１７５のカラムを有する。状態１７５は、「処理待ち」「処理中」「処理完了」の何れかの値となる。キュー７２の構造は、テーブル形式でもよいし、別の形式でもよい。また、キュー７２は、メモリ１３に保持されてもよいし、データベース２２に保持されてもよい。

処理要求管理キュー７２の動作を説明する。新たな処理要求がキュー７２へ入力されると、テーブル７２の最下行に新たなレコードが追加される。また、要求処理実行部７０が処理を実行する場合、テーブル７２の最上行のレコードを取得して、当該レコードの状態１７５を「処理待ち」から「処理中」へと更新する。キュー７２は、最上行のレコードの処理が完了すると、処理の完了を処理要求解析・処理結果返信モジュール７３へ通知し、状態１７５を「処理完了」へ更新する。そして、処理要求解析・処理結果返信モジュール７３は、処理要求送受信モジュール７４を経由して、外部システム６へ処理結果応答を送信する。キュー７２は、処理結果応答の送信が完了すると、当該処理のレコードをキュー７２から削除する。

キュー７２へのレコードの追加及び削除時に、要求された処理の実行と共に、受付重み統計値のカウントアップ処理、及び受付重み現在値の更新処理が実行される。

図５は、受付重み統計値で利用する処理カウント数を更新する処理のフローチャートである。

まず、キュー７２からレコードの削除を検知すると（ステップ８１）、自ノード状態管理部６２は、処理要求管理キュー７２の送信元１７２から、処理要求元の外部システム６のＩＰアドレスを取得する（ステップ８２）。

次に、取得したＩＰアドレスが処理カウント管理テーブル１３１（図８参照）に記録されているかを判定する（ステップ８３）。取得したＩＰアドレスが処理カウント管理テーブル１３１に記録されていない場合、新たな処理要求元の外部システム６を登録するため、外部システムのＩＰアドレス１３２が処理要求元の外部システム６のＩＰアドレスであるレコードを処理カウント管理テーブル１３１に追加する（ステップ８４）。この時、レコードを処理カウント管理テーブル１３１の他のカラム１３３〜１３６には０を記録する。

一方、ステップ８３で、取得したＩＰアドレスが処理カウント管理テーブル１３１に記録されている場合は、ステップ８５に進み、削除したキュー７２のレコードから、要求された処理を完了した処理名を取得する（ステップ８５）。例えば、図１２に示すキュー７２においてレコード１７６が削除された場合、完了した処理が「ｐ１」であることが処理１７４から取得できる。

次に、処理カウント管理テーブル１３１において、処理要求元に対応するレコードの完了した処理１３３〜１３５の値を１増加する（ステップ８６）。例えば、図１２に示すキュー７２においてレコード１７６が削除された場合、送信元の外部システム６のＩＰアドレスが「１９２．１６８．２．２１」であり、要求された処理が「ｐ１」であるため、処理カウント管理テーブル１３１のレコード１３７の「ｐ１」１３３の値を１増加する。

その後、処理カウント管理テーブル１３１のレコード１３７の重み合計値１３６を更新する（ステップ８７）。具体的には、実行処理管理テーブル６７（図１０）の重み係数１４４から対応する処理の重み係数を取得し、処理カウント管理テーブル１３１のレコード１３７の重み合計値１３６に加算する。その後、処理カウント数更新処理を終了する（ステップ８８）。

このようにして、アプリケーションサーバ２は、要求を受けた処理が完了すると、処理カウント数更新処理を実行し、処理カウント管理テーブル１３１を更新する。

次に、前述した受信可否判定処理（図１８）のステップ３０３やステップ３０８などで参照される受付重み統計値を、各アプリケーションサーバが算出する動作を説明する。

図６は、受付重み統計値算出処理のフローチャートである。

アプリケーションサーバ２は、統計値算出処理を繰り返し（例えば所定の時間毎に）実行する（ステップ１０１）。統計値の算出時間を制御するためのパラメータは、予めメモリに記録される。例えば、統計値算出間隔は３６００秒（１時間ごと）と設定してもよい。アプリケーションサーバ２は、この算出で統計値を算出する。また、１回の統計値の算出に用いるサンプリング回数を記録するとよい。さらに、統計値を最後に算出した時刻を記録するとよい。アプリケーションサーバ２は、統計値最終算出時刻に統計値算出間隔を加算した時刻に次の受付重み統計値を算出する。例えば、統計値最終算出時刻が「２０１４／０６／２４ １３：３１：１５」である場合、次回の算出処理開始時刻は、その１時間後の「２０１４／０６／２４ １４：３１：１５」となる。

次に、処理カウント管理テーブル１３１（図８）から、処理対象とする外部システム６のレコードを選択する（ステップ１０２）。統計値算出処理のループによって１レコードずつ処理し、最終的には全レコードについて統計値を算出する。

次に、選択したレコードの外部システムのＩＰアドレス１３２が、受付重み統計値管理テーブル３７１（図９Ａ）の外部システム３７２に登録されているかを判定する（ステップ１０３）。

選択したレコードの外部システム６が受付重み統計値管理テーブル３７１に登録されていない場合、この外部システム６の統計値は初めて算出するので、受付重み統計値管理テーブル３７１にレコードを追加する（ステップ１０４）。その時、処理カウント管理テーブル１３１（図８）の重み合計値１３６の値を、受付重み統計値３７３の値に登録する。この重み統計値の値が、最初に算出する統計値となる。

次に、ステップ１０５〜１０８で統計値を算出する。まず、現在の重み統計値と（統計サンプリング回数−１）とを乗算した値を求める（ステップ１０５）。例えば、受付重み統計値管理テーブル３７１（図９Ａ）のレコード３７４の値から統計値を算出する場合、レコード３７４の受付重み統計値３７３は「２３３」であり、統計サンプリング回数は「３」であるため、計算結果は２３３×（３−１）＝４６６となる。

次に、ステップ１０５で算出された乗算値に、処理カウント管理テーブル１３１の重み合計値１３６を加算する（ステップ１０６）。例えば、処理カウント管理テーブル１３１のレコード１３７の重み合計値１３６が「３０２」であるため、計算結果は４６６＋３０２＝７６８となる。

次に、ステップ１０６で算出された加算値を、統計サンプリング回数で除した値を算出する（ステップ１０７）。例えば、統計サンプリング回数は「３」であるため、計算結果は７６８÷３＝２５６となる。なお、この値が新たな重み統計値となる。

最後に、ステップ１０７の計算結果を受付重み統計値３７３に記録する（ステップ１０８）。更新前の受付重み統計値管理テーブル３７１（図９Ａ）と、更新後の受付重み統計値管理テーブル３７１−２（図９Ｂ）を比較すると、ＩＰアドレスが１９２．１６８．１．２１の外部システム６の重み統計値は、「２３３」から「２５６」へ変化した。

選択された一つの外部システム６についてステップ１０８までの処理が終了すると、全ての外部システム６についての重み統計値の算出が終了したかを判定する（ステップ１０９）。一部の外部システム６についての重み統計値が算出されていない場合、ステップ１０２へ戻り、次に統計値を算出する外部システム６のレコードを選択する。一方、全ての外部システム６についての重み統計値の算出が終了している場合、全ての外部システム６の算出後の受付重み統計値を合計し、その合計値で自ノード管理テーブル６０（図７Ａ）の受付重み統計値１２６の値を更新する（ステップ１１０）。例えば、受付重み統計値管理テーブル３７１−２（図９Ｂ）の各レコードの受付重み統計値３７３の合計値が、全ての外部システム６の統計値を算出後の受付重み統計値であり、２５６＋４５＋４４５＝７４６となる。

最後にステップ１１１で、メモリに記録された統計値最終算出時刻を現在時刻に更新し、受付重み統計値算出処理を終了する（ステップ１１２）。

次に、処理要求管理キュー７２レコードを追加又は削除する時の受付重み現在値及びアプリケーションサーバ２の受付可否状態を更新する処理を説明する。

図１１Ａは、キューレコード追加時の更新処理のフローチャートである。

処理要求管理キュー７２（図１２）にレコードが追加されると（ステップ１５１）、自ノード状態管理部６２は、追加された処理要求の対象である処理の重み係数を、自ノード管理テーブル６０（図７Ａ）の受付重み現在値へ加算する（ステップ１５２）。具体的には、自ノード状態管理部６２は、追加された処理要求の対象である処理の重み係数を、実行処理管理テーブル６７（図１０）の重み係数１４から取得する。また、自ノード状態管理部６２は、処理要求管理キュー７２から受けた追加レコードの処理１７４と一致するレコードを実行処理管理テーブル６７から検索する。例えば、キュー７２にレコード１７７が追加された場合、処理１７４は「ｐ３」であり、実行処理管理テーブル６７のレコード１４６が該当し、当該処理ｐ３の重み係数は「１」である。その結果、自ノード状態管理部６２は、自ノード管理テーブル６０の受付重み現在値１２７に１を加算する。

次に、受付重み現在値が閾値を超えているかを判定する（ステップ１５３）。閾値は予めアプリケーションサーバ２に設定されている値であり、例えば３０を定義する。受付重み現在値が閾値を超えると受け付けが不可能となる。受付重み現在値が閾値を超えていない場合、ステップ１５４をスキップして、更新処理を終了する（ステップ１５５）。

一方、受付重み現在値が閾値を超えている場合、自ノード管理テーブル６０の現在の受付可否状態１２８を「受付不可」へ更新する（ステップ１５４）。その結果、受信可否判定処理（図１８）のステップ３０７でブロードキャストに応答しないと判定し、処理要求受信処理（図１９）のステップ３２４で処理要求を拒否する。

図１１Ｂは、キューレコード削除時の更新処理のフローチャートである。

処理要求管理キュー７２からレコードが削除されると（ステップ１６１）、自ノード状態管理部６２は、削除された処理要求の対象である処理の重み係数を、実行処理管理テーブル６７（図１０）の重み係数１４から取得し、自ノード管理テーブル６０（図７Ａ）の受付重み現在値から減算する（ステップ１６２）。

次に、受付重み現在値が閾値以下となったかを判定する（ステップ１６３）。閾値は予めアプリケーションサーバ２に設定されている値であり、例えば３０を定義する。受付重み現在値が閾値以下でない場合、ステップ１６４をスキップして、更新処理を終了する（ステップ１６５）。

一方、受付重み現在値が閾値以下である場合、自ノード管理テーブル６０の現在の受付可否状態１２８を「受付可」へ更新する（ステップ１６４）。その結果、受信可否判定処理（図１８）のステップ３０７でブロードキャストに応答すると判定し、処理要求受信処理（図１９）のステップ３２４で処理要求を受け付ける。

次に、アプリケーションサーバ２の状態が変化した場合（サーバ起動時、サーバ状態変化時、サーバダウン時）のサーバ間での情報を共有を説明する。本実施例では、アプリケーションサーバ２は、他ノード管理テーブル５９（図１４）を共有しているが、他の情報を共有してもよい。

図１３は、アプリケーションサーバ２の状態が変化した場合にアプリケーションサーバ間で情報を共有するシーケンス図である。

まず、Ｓｅｑ１：サーバ起動時２０３のシーケンスを用いて、各アプリケーションサーバが起動したときの情報の共有の動作を説明する。

例えば、アプリケーションサーバ２−１が起動する（ステップ１８１）。起動直後のアプリケーションサーバ２−１の自ノード管理テーブル６０−１は、図７Ｂに示す様に、受付重み統計値１２６は「０」であり、受付重み現在値１２７は「０」であり、現在の受付可否状態１２８は「受付可」である。アプリケーションサーバ２−１は、起動後、起動したことと現在の自ノード状態を、状態通知ノード１へ送信する（ステップ１８２）。状態通知ノード１のＩＰアドレスは、アプリケーションサーバ２−１の起動前に、自ノード管理テーブル６０−１のレコード１２９に事前に設定しておく。

状態通知ノード１は、起動通知１８２を受けると、アプリケーションサーバ２−１が稼働状態であること及び送信された情報を内部の記憶装置に保持する。また、状態通知ノード１は、情報が保持されている他のアプリケーションサーバにアプリケーションサーバ２−１の情報の追加・変更を通知する。図示する例では、アプリケーションサーバ２−１からの起動通知１８２のタイミングでは、他のアプリケーションサーバは起動しておらず、状態通知ノード１も起動しているアプリケーションサーバ２の情報を保持していないため、他のアプリケーションサーバ２へ通知されない。

その後、アプリケーションサーバ２−２が起動する（ステップ１８３）。アプリケーションサーバ２−２は、アプリケーションサーバ２−１と同様に、起動後、起動したことと現在の自ノードの情報を、状態通知ノード１へ送信する（ステップ１８４）。状態通知ノード１は、起動通知１８４を受けると、このタイミングでアプリケーションサーバ２−１の情報を保持しているため、アプリケーションサーバ２−２が追加されたこと、及びアプリケーションサーバ２−２の状態情報をアプリケーションサーバ２−１に通知する（ステップ１８５）。

また、現在稼動しているアプリケーションサーバの情報を、新たに起動したアプリケーションサーバ２−２に通知する（ステップ１８６）。アプリケーションサーバ２−２では、他ノード状態送受信モジュール６５が稼動中のアプリケーションサーバの情報を受信し、状態解析・生成モジュール６４が通知を受けた他のアプリケーションサーバ２の情報を他ノード状態管理部６１を経由して他ノード管理テーブル５９に登録する。既に同じアプリケーションサーバが登録されている場合は、既に登録されている情報を更新する。

その後、アプリケーションサーバ２−３が起動すると（ステップ１８７）、前述と同様に、アプリケーションサーバ２−３は、状態通知ノード１へ起動通知を送信する（ステップ１８８）。状態通知ノード１は、稼働中サーバ変更通知をアプリケーションサーバ２−１、２−２に通知し（ステップ１８９、１９０）。現在稼動しているアプリケーションサーバの情報を、新たに起動したアプリケーションサーバ２−３に通知する（ステップ１９１）。

その結果、各アプリケーションサーバの現在の状態をアプリケーションサーバ間で共有することができる。例えば、Ｓｅｑ１：サーバ起動時２０３のシーケンスの後のアプリケーションサーバ２−１の他ノード管理テーブル５９−１は、図１４Ｂに示す形態となる。

次に、Ｓｅｑ２：サーバ状態変化時２０４のシーケンスを用いて、アプリケーションサーバ２の自ノード管理テーブル６０の値が変化したときの情報の共有の動作を説明する。

例えば、アプリケーションサーバ２−１が大量の処理要求を受けた（ステップ１９２）。アプリケーションサーバ２−１は、処理要求受信処理（図１９）のステップ３２７で、受信した処理要求を処理要求管理キュー７２に登録し（ステップ１９３）、更新処理（図１１Ａ）のステップ１５２で受付重み現在値を更新する。しかし、所定量のキューが格納されると、受付重み現在値が閾値を超えるため、更新処理（図１１Ａ）のステップ１５４の処理が実行され、現在の受付可否状態を「受付不可」へ更新する（ステップ１９４）。

その後、アプリケーションサーバ２−１は、状態の変化を状態通知ノード１へ通知する（ステップ１９５）。状態通知ノード１は、状態変化通知１９５を受けると、アプリケーションサーバ２−１の新しい状態を内部の記憶装置に保持する。また、状態通知ノード１は、情報が保持されている他のアプリケーションサーバに、アプリケーションサーバ２−１の情報の変更を通知する（ステップ１９６、１９７）。図示する例では、アプリケーションサーバ２−１からの状態変化通知１９５のタイミングで、他のアプリケーションサーバ２−２、２−ｎが稼働しており、状態通知ノード１がこれらのアプリケーションサーバの情報を保持している。このため、状態通知ノード１は、アプリケーションサーバ２−１の状態変化を、他のアプリケーションサーバ２−２、２−ｎに通知する。

アプリケーションサーバ２−２、２−ｎでは、他ノード状態送受信モジュール６５が稼動中アプリケーションサーバの情報を受信し、状態解析・生成モジュール６４が通知を受けた他のアプリケーションサーバ２の情報を他ノード状態管理部６１を経由して他ノード管理テーブル５９の他アプリケーションサーバの情報を更新する。

次に、Ｓｅｑ３：サーバダウン時２０５のシーケンスを用いて、アプリケーションサーバがダウンしたときの情報の共有の動作を説明する。

アプリケーションサーバ２−１及び状態通知ノード１は、アプリケーションサーバ２−１の起動通知時からコネクションを張っている。状態通知ノード１は、このコネクションを定期的に監視している。例えば、アプリケーションサーバ２−１がダウンした場合（ステップ１９８）、アプリケーションサーバ２−１と状態通知ノード１の間のコネクションは切断される（ステップ１９９）。このため、アプリケーションサーバ２−１がダウンして一定期間が経過すると、状態通知ノード１は、定期監視により、アプリケーションサーバ２−１とのコネクションが切れたことを検知する（ステップ２００）。

状態通知ノード１は、ステップ２００でコネクション切断を検知すると、アプリケーションサーバ２−１の新しい状態を内部の記憶装置に保持する。また、状態通知ノード１は、情報が保持されている他のアプリケーションサーバに、アプリケーションサーバ２−１のダウンを通知する（ステップ２０１、２０２）。図示する例では、アプリケーションサーバ２−１のダウンを検出したタイミングで、他のアプリケーションサーバ２−２、２−ｎが稼働しており、状態通知ノード１がこれらのアプリケーションサーバの情報を保持している。このため、状態通知ノード１は、アプリケーションサーバ２−１のダウンを、他のアプリケーションサーバ２−２、２−ｎに通知する。

アプリケーションサーバ２−２、２−ｎでは、他ノード状態送受信モジュール６５が稼動中アプリケーションサーバの情報を受信し、状態解析・生成モジュール６４が通知を受けた他のアプリケーションサーバ２の情報を他ノード状態管理部６１を経由して他ノード管理テーブル５９の状態２１４を「未稼働」へ更新する。

このように、各アプリケーションサーバは状態通知ノード１を経由して、互いの情報を共有する。なお、情報の共有方法は例示した以外の方法でもよい。

図２１Ａ、図２１Ｂ、図２２には、前述した受付重み統計値算出処理（図６、図９Ａ）の別な例を示す。

図６では外部システム毎に受付重み統計値を算出する処理を説明し、図９Ａでは算出された受付重み統計値を外部システム毎に管理する受付重み統計値管理テーブルを説明した。一方、図２２では処理毎に受付重み統計値を算出する処理を説明し、図２１Ａ、図２１Ｂでは算出された受付重み統計値を管理する処理毎に統計値管理テーブルを説明する。

図２２に示す受付重み統計値算出処理では、図６と同様に、アプリケーションサーバは、繰り返し（例えば所定の時間毎に）処理を実行する（ステップ３９１）。

ステップ３９２から３９５で、処理毎に統計値を算出する。例えば、処理ｐ１について、ステップ３９２では、図２１Ａに示す受付重み統計値管理テーブル３８１の処理３８２が「ｐ１」のレコード３８４の要求数３８３の「１５」を用いる。ステップ３９３では、処理カウント管理テーブル１３１（図８）の全外部システムのカラム１３３の合計値を加算する。ステップ３９４では、算出された加算値を、統計サンプリング回数「３」で除する。ステップ３９５では、受付重み統計値管理テーブル３８１（図２１Ａ）の要求数３８３及び重み３８５を更新する。

その後、選択された一つの外部システム６についてステップ１０８までの処理が終了すると、全ての外部システム６についての重み統計値の算出が終了したかを判定する（ステップ３９６）。

ステップ３９７、３９８の処理は、図６のステップ１１０、１１１の処理と同じである。

更新前の受付重み統計値管理テーブル３８１（図２１Ａ）と、更新後の受付重み統計値管理テーブル３８１−２（図２１Ｂ）を比較すると、処理ｐ１の重み統計値は、「３０」から「４２」へ変化した。

このようにして、図２４に示す処理毎の受付重み統計値をノード間で共有することができる。

なお、図６に示すシーケンスと図２２に示すシーケンスとは、両方を実行しても、いずれか一方のみを実行してもよい。なお、情報を共有するアプリケーションサーバ２は、互いに同じ種類の情報を共有するために、同じ処理を行い、各アプリケーションサーバ２は同じ情報を算出する必要がある。

以上に説明したように、本発明の第１実施例によれば、負荷分散装置やネームサーバ等の特別な装置を導入することなく、Ｌ２ＳＷ、Ｌ３ＳＷ等の汎用的なネットワーク装置によって、アプリケーションサーバを分散配置環境を実現することができ、負荷分散や冗長性を確保することができる。

また、システム拡張のボトルネックを解消することができる。さらに、システム内の管理装置が減ることによって、管理の手間やコストを軽減することができる。

さらに、各ノードへの処理要求と受付重み統計値を参照して振分先を決定するので、ノードクラスタ全体の負荷分散の効率をより高めることができる。

また、受付重み統計値を参照して代替先のアプリケーションサーバを選択するので、自ノードが処理を実行できない場合でも、適切なアプリケーションサーバを選択することができる。また、選択された代替先のアプリケーションサーバの情報を処理要求を送信した外部システムに通知し、処理要求を送信した外部システムの情報を選択された代替先のアプリケーションサーバに通知するので、代替先のアプリケーションサーバに確実に処理を引き継ぐことができる。

また、受付重み統計値が最低のアプリケーションサーバを代替先のアプリケーションサーバとして選択するので、負荷が低いアプリケーションサーバを的確に選択することができる。

また、受付重み統計値は、外部システム毎に要求された処理の種別毎の回数と、処理の種別の重み係数とを乗じて、前記外部システム毎に算出される負荷情報としたので、集中的に処理を依頼している外部システムを特定できる。このため、特定の外部システムからの負荷が集中しているアプリケーションサーバではなく、複数の外部システムからの平均的な負荷がかかっているアプリケーションサーバを選択することができる。

また、受付重み統計値は、外部システム毎に要求された処理の種別毎の回数と、処理の種別の重み係数とを乗じて、処理の種別毎に算出される負荷情報としたので、処理毎に負荷を平準化することができる。

また、受付重み統計値が最低である場合に、ブロードキャストに応答すると判定するので、負荷が低いアプリケーションサーバを選択することができる。

また、現在処理要求を受付可能なアプリケーションサーバの中で受付重み統計値を比較するので、突発的な負荷変動によって、現在処理要求を受け付けていない計算機を除外して、的確に振り分け先を決定できる。

また、現在稼働中である計算機の中で受付重み統計値を比較するのでメンテナンスなどで停止中の計算機を除外して、的確に振り分け先を決定できる。

なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を有するものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。

また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

１ 状態通知ノード
２、２−１〜２−ｎ アプリケーションサーバ
４ ルータ
５ ネットワーク
６、６−１〜６−ｎ 外部システム
７ ネットワークセグメント
１２ ＣＰＵ
１３ メモリ
１５ アプリケーションプログラム
１６ ストレージ
１８ プリケーションプログラムファイル
２０、２１ インタフェース
２２ データベース
２６ アプリケーション情報一時格納領域

Claims (14)

1. 計算機システムであって、
   複数の外部システムからの要求によって処理を実行する複数の計算機を備え、
   前記複数の計算機の各々は、
   メモリと、前記メモリを参照するプロセッサと、他の計算機と通信するためのネットワークインタフェースと、を有し、
   同一ネットワークセグメント内の他の計算機と、前記各計算機が算出した受付重み統計値を共有しており、
   前記各計算機のプロセッサは、
   一つの前記外部システムから同一ネットワークセグメント内に同報されるブロードキャストを受信し、
   前記共有される受付重み統計値を参照して、前記受信したブロードキャストに応答するかを判定し、
   応答すると判定した場合、前記一つの外部システムに処理要求を送信させるために、前記ブロードキャストを送信した外部システムに応答を返信することを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記各計算機のプロセッサは、
   一つの前記外部システムから処理要求を受信し、
   前記要求された処理を実行するかを判定し、
   前記要求された処理を実行しないと判定した場合、前記共有される受付重み統計値を参照して、前記複数の計算機から代替計算機を選択し、
   前記選択した代替計算機の情報を前記処理要求を送信した外部システムに通知し、
   前記処理要求を送信した外部システムの情報を、前記選択した代替計算機に通知することを特徴とする計算機システム。
3. 請求項１又は２に記載の計算機システムであって、
   前記受付重み統計値は、前記外部システム毎に要求された処理の種別及び回数と、各前記処理の種別に対応して定められた重み係数とに基づいて、前記外部システム毎に算出される負荷情報であることを特徴とする計算機システム。
4. 請求項１又は２に記載の計算機システムであって、
   前記受付重み統計値は、前記外部システム毎に要求された処理の種別及び回数と、各前記処理の種別に対応して定められた重み係数とに基づいて、前記処理の種別毎に算出される負荷情報であることを特徴とする計算機システム。
5. 請求項１又は２に記載の計算機システムであって、
   前記各計算機のプロセッサは、前記他の計算機より前記受付重み統計値が低い場合に、前記ブロードキャストに応答すると判定することを特徴とする計算機システム。
6. 請求項５に記載の計算機システムであって、
   前記複数の計算機は、処理要求の受付可否の情報を共有しており、
   前記各計算機のプロセッサは、現在処理要求を受け付けできる計算機の中で前記受付重み統計値が最も低い場合に、前記ブロードキャストに応答すると判定することを特徴とする計算機システム。
7. 請求項５に記載の計算機システムであって、
   前記複数の計算機は、稼働中であるかの情報を共有しており、
   前記各計算機のプロセッサは、現在稼働中である計算機の中で前記受付重み統計値が最も低い場合に、前記ブロードキャストに応答すると判定することを特徴とする計算機システム。
8. 請求項２に記載の計算機システムであって、
   前記各計算機のプロセッサは、前記受付重み統計値が最も低い計算機を前記代替計算機として選択することを特徴とする計算機システム。
9. 複数の外部システムからの要求によって処理を実行する計算機であって、
   メモリと、
   前記メモリを参照するプロセッサと、
   他の計算機と通信するためのネットワークインタフェースと、を有し、
   同一ネットワークセグメント内の他の計算機と受付重み統計値を共有しており、
   前記プロセッサは、
   一つの前記外部システムからブロードキャストを受信し、
   前記共有される受付重み統計値を参照して、前記受信したブロードキャストに応答するかを判定し、
   応答すると判定した場合、前記一つの外部システムに処理要求を送信させるために、前記ブロードキャストを送信した外部システムに応答を返信することを特徴とする計算機。
10. 請求項９に記載の計算機であって、
    前記プロセッサは、
    一つの前記外部システムから処理要求を受信し、
    前記要求された処理を実行するかを判定し、
    前記要求された処理を実行しないと判定した場合、前記共有される各計算機の受付重み統計値を参照して、代替計算機を選択し、
    前記選択した代替計算機の情報を前記外部システムに通知し、
    前記処理要求を送信した外部システムの情報を、前記選択した代替計算機に通知することを特徴とする計算機。
11. 計算機システムにおける負荷分散方法であって、
    前記計算機システムは、複数の外部システムからの要求によって処理を実行する複数の計算機を有し、
    前記複数の計算機の各々は、
    メモリと、前記メモリを参照するプロセッサと、他の計算機と通信するためのネットワークインタフェースと、を有し、
    同一ネットワークセグメント内の他の計算機と、前記各計算機が算出した受付重み統計値を共有しており、
    前記方法は、
    前記プロセッサが、一つの前記外部システムからブロードキャストを受信し、
    前記プロセッサが、前記共有される受付重み統計値を参照して、前記受信したブロードキャストに応答するかを判定し、
    前記プロセッサが、応答すると判定した場合、前記一つの外部システムに処理要求を送信させるために、前記ブロードキャストを送信した外部システムに応答を返信することを特徴とする負荷分散方法。
12. 請求項１１に記載の負荷分散方法であって、
    前記プロセッサが、一つの前記外部システムから処理要求を受信し、
    前記プロセッサが、前記要求された処理を実行するかを判定し、
    前記プロセッサが、前記要求された処理を実行しないと判定した場合、前記共有される受付重み統計値を参照して、前記複数の計算機から代替計算機を選択し、
    前記プロセッサが、前記選択した代替計算機の情報を前記処理要求を送信した外部システムに通知し、
    前記プロセッサが、前記処理要求を送信した外部システムの情報を、前記選択した代替計算機に通知することを特徴とする負荷分散方法。
13. 計算機に処理を実行させるためのプログラムであって、
    前記計算機は、
    メモリと、前記メモリを参照するプロセッサと、他の計算機と通信するためのネットワークインタフェースと、を有し、
    複数の外部システムからの要求によって処理を実行し、
    同一ネットワークセグメント内の他の計算機と受付重み統計値を共有しており、
    前記プログラムは、
    一つの前記外部システムからブロードキャストを受信する手順と、
    前記共有される受付重み統計値を参照して、前記受信したブロードキャストに応答するかを判定する手順と、
    応答すると判定した場合、前記一つの外部システムに処理要求を送信させるために、前記ブロードキャストを送信した外部システムに応答を返信する手順とを実行させるためのプログラム。
14. 請求項１３に記載のプログラムであって、
    一つの前記外部システムから処理要求を受信する手順と、
    前記要求された処理を実行するかを判定する手順と、
    前記要求された処理を実行しないと判定した場合、前記共有される各計算機の受付重み統計値を参照して、代替計算機を選択する手順と、
    前記選択した代替計算機の情報を前記外部システムに通知する手順、
    前記処理要求を送信した外部システムの情報を、前記選択した代替計算機に通知する手順と、を実行させるためのプログラム。

Images