JP5597872B2 - 分散情報処理システム、分散情報処理方法及びデータ転送装置 - Google Patents

Description

本発明は、コンピュータ・ネットワーク分野に関する。具体的には、分散情報処理を実現するデータ転送技術に関する。

Ｗｅｂサイトを運用するデータセンタでは、複数のサーバを負荷分散装置で統合したシステムを構築することで、ユーザからの膨大なリクエストを短時間に処理することを可能としている。ＷｅｂサイトのＵＲＬは、リクエストを処理するサーバではなく、負荷分散装置に割り当てられる。ユーザからのＷｅｂサイトへのリクエストを受信した負荷分散装置は、その後段に接続されたサーバ群にリクエストを振り分けることで、サーバ台数に比例したスケーラビリティを実現できる。

効率的なスケーラビリティを実現するためには、すべてのサーバの稼働率を向上させる振り分けを行う必要がある。例えば、特許文献１には、定期的に収集するＣＰＵ使用率及び応答時間等の情報に基づき、ユーザからのリクエストを最適なサーバに転送する技術が記載されている。

また、同一サービスを提供するサーバが距離の離れた拠点に複数存在する場合、ユーザからのリクエストは、特定のサーバに偏らないように、ネットワークコストを考慮した上で、サーバへ送信する必要がある。これに関して、特許文献２には、ユーザとサーバとの間の距離及びサーバの負荷情報に基づき、ユーザからのリクエストの転送先サーバを選択する技術が記載されている。

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

上記特許文献１および特許文献２の技術では、ユーザからのリクエストを単体のサーバで処理する際には、サーバの稼動状況に基づいたリクエストの転送が実現される。しかし、複数のサーバ上のサービスが連携して機能する分散アプリケーションにおいて、負荷分散装置からリクエストを受信したサーバが、負荷分散装置の管理下にはない外部サーバによって提供されるサービスを使用する場合、外部サーバへのネットワーク状況および外部サーバの稼動状況によってはリクエストの転送が適切でない場合があるという問題があった。

すなわち、ユーザからのリクエストを受信した負荷分散装置がリクエストを振り分ける際には、リクエストの処理が完了するまでに経由するすべてのネットワークおよびサーバの稼動状況を判断する必要があるという課題があった。

そこで本発明は、上記問題点を鑑みてなされたもので、ネットワークおよびサーバの稼動状況に基づき、分散アプリケーションにおける適切なリクエスト転送を実現することを目的とする。

本発明の代表的な一例を示せば次のとおりである。すなわち、ネットワークに接続される複数のデータ転送装置と、前記複数のデータ転送装置に接続される複数のサーバと、を備える分散情報処理システムであって、前記データ転送装置は、前記ネットワークに接続されるインタフェースと、前記インタフェースに接続されるプロセッサと、を備え、前記複数のサーバによって実行される各サービスプログラムと、そのサービスプログラムによるサービスを提供するために使用される別のサービスプログラムとを対応付ける第１情報を保持し、前記各サービスプログラムを実行するために要するリソース量を示す第２情報を保持し、前記各サービスプログラムの実行を要求するサービス要求パケットの送信先として指定できる前記サーバ及び前記データ転送装置の一つ以上のアドレスを示す第３情報を保持し、前記複数のサーバ及び前記ネットワークの少なくとも一方の状態を示す第４情報を保持し、前記サービス要求パケットを受信すると、前記第１情報に基づいて、受信した前記サービス要求パケットによって要求されたサービスを提供するために実行する必要がある第１サービスプログラムと、前記第１サービスプログラムによるサービスを提供するために使用される別のサービスプログラムである第２サービスプログラムと、を含む、前記受信したサービス要求パケットによって要求されたサービスを提供するために実行する必要がある全てのサービスプログラムを特定し、前記第３情報に基づいて、前記特定された全てのサービスプログラムの各々について、そのサービスプログラムの実行を要求するサービス要求パケットの送信先として指定できる一つ以上のアドレスを特定し、前記特定されたアドレスに基づいて、前記特定された全てのサービスプログラムの実行を要求するサービス要求パケットの送信先の複数の組み合わせを特定し、前記第２情報及び前記第４情報に基づいて、前記特定された複数の組み合わせのうち、処理が最適化される組み合わせを選択し、前記受信したサービス要求パケットの送信先を前記選択された組み合わせに含まれる送信先のアドレスに書き換えて、当該サービス要求パケットを送信することを特徴とする。

本発明によれば、データ転送装置が、実行する分散アプリケーションに応じてリクエストの処理が完了するまでのネットワーク経路およびサーバ群の稼動状況を認識した上で、次に処理を実行するサーバへリクエストを転送できるため、システム全体で効率的な情報処理を実現できる。

本発明の実施形態における分散処理システムの構成例を示すブロック図である。 本発明の実施形態の分散処理システムにおいて実行される分散アプリケーションの構成例を示す説明図である。 本発明の実施形態の分散アプリケーションを構成するクライアントプログラム（Client）のアプリケーショングラフの例を示す説明図である。 本発明の実施形態の分散アプリケーションを構成するサービスプログラム（MacNegatives）のアプリケーショングラフの例を示す説明図である。 本発明の実施形態の分散アプリケーションを構成するサービスプログラム（Mac）のアプリケーショングラフの例を示す説明図である。 本発明の実施形態の分散アプリケーションを構成するサービスプログラム（Add）のアプリケーショングラフの例を示す説明図である。 本発明の実施形態のネットワーク構成の例を示す説明図である。 本発明の実施形態のネットワーク構成において使用されるアドレスの例を示す説明図である。 本発明の実施形態の第１のデータ転送装置が保持するセッションＤＢの例を示す説明図である。 本発明の実施形態の第２のデータ転送装置が保持するセッションＤＢの例を示す説明図である。 本発明の実施形態の第３のデータ転送装置が保持するセッションＤＢの例を示す説明図である。 本発明の実施形態の第１のデータ転送装置が保持するサービスノードＤＢに含まれるサービスＩＤ表の例を示す説明図である。 本発明の実施形態の第１のデータ転送装置が保持するサービスノードＤＢに含まれるサービスノード稼動情報表の例を示す説明図である。 本発明の実施形態の第１のデータ転送装置が保持するサービスノードＤＢに含まれるサービスノード間往復遅延表の例を示す説明図である。 本発明の実施形態の第２のデータ転送装置が保持するサービスノードＤＢに含まれるサービスＩＤ表の例を示す説明図である。 本発明の実施形態の第２のデータ転送装置が保持するサービスノードＤＢに含まれるサービスノード稼動情報表の例を示す説明図である。 本発明の実施形態の第２のデータ転送装置が保持するサービスノードＤＢに含まれるサービスノード間往復遅延表の例を示す説明図である。 本発明の実施形態の第３のデータ転送装置が保持するサービスノードＤＢに含まれるサービスＩＤ表の例を示す説明図である。 本発明の実施形態の第３のデータ転送装置が保持するサービスノードＤＢに含まれるサービスノード稼動情報表の例を示す説明図である。 本発明の実施形態の第３のデータ転送装置が保持するサービスノードＤＢに含まれるサービスノード間往復遅延表の例を示す説明図である。 本発明の実施形態の第１のデータ転送装置が保持する利用予約ＤＢの例を示す説明図である。 本発明の実施形態の第２のデータ転送装置が保持する利用予約ＤＢの例を示す説明図である。 本発明の実施形態の第３のデータ転送装置が保持する利用予約ＤＢの例を示す説明図である。 本発明の実施形態の第４のデータ転送装置が保持する利用予約ＤＢの例を示す説明図である。 本発明の実施形態の第５のデータ転送装置が保持する利用予約ＤＢの例を示す説明図である。 本発明の実施形態の第１のデータ転送装置が保持するマップ結果ＤＢの例を示す説明図である。 本発明の実施形態の第２のデータ転送装置が保持するマップ結果ＤＢの例を示す説明図である。 本発明の実施形態の第３のデータ転送装置が保持するマップ結果ＤＢの例を示す説明図である。 本発明の実施形態の第１のデータ転送装置が保持するアプリケーショングラフＤＢの例を示す説明図である。 本発明の実施形態の第２のデータ転送装置が保持するアプリケーショングラフＤＢの例を示す説明図である。 本発明の実施形態の第３のデータ転送装置が保持するアプリケーショングラフＤＢの例を示す説明図である。 本発明の実施形態の第４のデータ転送装置が保持するアプリケーショングラフＤＢの例を示す説明図である。 本発明の実施形態の第５のデータ転送装置が保持するアプリケーショングラフＤＢの例を示す説明図である。 本発明の実施形態のデータ転送装置にアプリケーショングラフを登録する手順の例を示すシーケンス図である。 本発明の実施形態のデータ転送装置がサーバの稼動情報を収集する手順の例を示すシーケンス図である。 本発明の実施形態のデータ転送装置間でマップ結果を伝播させる手順の例を示すシーケンス図である。 本発明の実施形態のデータ転送装置のアドレス変換部が実行するアドレス変換処理の例を示すフローチャートである。 本発明の実施形態のデータ転送装置のセッション管理部が実行するセッションＤＢ参照処理の例を示すフローチャートである。 本発明の実施形態のデータ転送装置のセッション管理部が実行するセッション作成処理の例を示すフローチャートである。 本発明の実施形態のデータ転送装置のマッピング計算部が実行するリソースマッピング処理の例を示すフローチャートである。 本発明の実施形態のデータ転送装置のマッピング計算部が実行するマップ処理の例を示すフローチャートである。 本発明の実施形態のデータ転送装置のマッピング計算部が実行する遅延計算処理の例を示すフローチャートである。 本発明の実施形態のデータ転送装置のセッションＤＢの接続状態（ＴＣＰ使用時）を決める状態遷移図である。 本発明の実施形態のデータ転送装置のセッションＤＢの接続状態（ＵＤＰ使用時）を決める状態遷移図である。

以下、本発明の実施形態の例を添付図面に基づき説明する。各図における同一符号は同一物または相当物を示す。説明の都合上、符号に添え字を追加して区別することがある。

図１は、本発明の実施形態における分散処理システムの構成例を示すブロック図である。

本実施形態の分散処理システムは、管理装置１０１、１台以上のデータ転送装置１０３、およびユーザ端末１０４を備え、広域網１０２を介して互いに接続される。データ転送装置１０３には、それぞれサーバ１０５およびＤＮＳ（Domain Name System）１０６がＬＡＮ（Local Area Network）１０７を介して接続される。管理装置１０１、サーバ１０５、ＤＮＳ１０６およびユーザ端末１０４の台数は、本実施形態の台数に限定されない。

データ転送装置１０３は、広域網１０２を介して管理装置１０１、他のデータ転送装置およびユーザ端末１０４と通信する。また、データ転送装置１０３は、ＬＡＮ１０７を介してサーバ１０５およびＤＮＳ１０６と通信する。

データ転送装置１０３は、記憶装置１２０、ＣＰＵ１２１、ネットワークＩ／Ｆ１２２から構成される。ネットワークＩ／Ｆ１２２は、広域網１０２およびＬＡＮ１０７と接続できれば良く、その数は問わないが、ネットワークＩ／Ｆ１２２の数を増やすことで、ネットワーク帯域のボトルネックの問題を改善できる。

図１には、一つのデータ転送装置１０３が広域網１０２に接続されるネットワークＩ／Ｆ１２２及びＬＡＮ１０７に接続されるネットワークＩ／Ｆ１２２を備える例を示す。図１では、これらが、枝番（１）および（２）を用いて、それぞれネットワークＩ／Ｆ１２２（１）および１２２（２）と表示される。以下、各ネットワークＩ／Ｆ１２２を区別して説明する必要がある場合には枝番を記載し、いずれのネットワークＩ／Ｆ１２２にも共通する説明をする場合（または任意のネットワークＩ／Ｆ１２２に関する説明をする場合）には枝番を記載しない。他の構成要素（例えばデータ転送装置１０３等）についても同様である。

ＣＰＵ１２１とネットワークＩ／Ｆ１２２は共有バス１２３、記憶装置１２０とＣＰＵ１２１は共有バス１２４で接続される。共有バス１２３および共有バス１２４は、別の通信手段によって置き換えられてもよい。例えば、ＣＰＵ１２１の数が多数の場合、通信ボトルネックを起こしやすい共有バス１２４ではなく、ネットワークオンチップ等を利用しても良い。

記憶装置１２０には、セッションＤＢ（Database）１３１、サービスノードＤＢ１３２、利用予約ＤＢ１３３、マップ結果ＤＢ１３４およびアプリケーショングラフＤＢ１３５が格納される。これらの情報は、アドレス変換部１４０および装置連携部１５０によって作成されるものであり、詳細は後述する。記憶装置１２０としては半導体メモリＤＲＡＭ（Dynamic Random Access Memory）、ＳＲＡＭ（Static Random Access Memory）またはＣＡＭ（Content Addressable Memory）等を利用することが考えられる。ＳＲＡＭ、ＣＡＭの利用によって、ＤＢへのアクセス速度を改善できる。

ＣＰＵ１２１は、プログラムであるアドレス変換部１４０および装置連携部１５０を実行する。アドレス変換部１４０および装置連携部１５０の機能の一部またはすべてを専用ＬＳＩ（Large-Scale Integrated Circuit）またはＦＰＧＡ（Field Programmable Gate Array）等のハードウェアで実装しても良い。ハードウェアとして実装することで、処理の高速化および省電力化が可能となる。

アドレス変換部１４０は、パケット解析部１４１、セッション管理部１４２、サービスノード管理部１４３、アプリケーショングラフ管理部１４４、利用予約管理部１４５およびマッピング計算部１４６から構成される。

パケット解析部１４１は、ネットワークＩ／Ｆ１２２から受信したパケットの送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号、プロトコル番号およびＶＬＡＮなどを解析する。パケットのヘッダデータだけでなく、ペイロードデータを解析する形態も考えられ、この場合、サービスの機能選択、及び、同一のポート番号を使用する複数のアプリケーションの識別が可能となる。

セッション管理部１４２は、パケット解析部１４１の解析結果に基づいて、接続元と接続先との通信を管理する。セッション管理部１４２は、アドレス変換に必要なセッションＤＢ１３１を操作（登録、削除、変更または参照）する。

サービスノード管理部１４３は、サービスノード登録Ｉ／Ｆ１５１およびサービスノード情報収集・交換Ｉ／Ｆ１５２と連携して、サービスノードの情報を格納するサービスノードＤＢ１３２を操作（登録、削除、変更または参照）する。なお、後述するように、サービスノードとは、サーバ１０５またはデータ転送装置１０３に相当する。サービスノード管理部１４３は、サービスノード登録Ｉ／Ｆ１５１を通して登録されるサービスノードの稼動情報を、サービスノード情報収集・交換Ｉ／Ｆ１５２を通して収集し、必要に応じて他のデータ転送装置１０３に送信する。

サービスノードの収集する稼動情報としては、サーバ１０５のＣＰＵ演算速度、空メモリ量、ネットワーク帯域、およびネットワーク往復遅延等が考えられる。サーバ１０５の情報は、ＬＡＮ１０７を通してＳＮＭＰ（Simple Network Management Protocol）等を用いて収集する。他のデータ転送装置１０３の稼動情報は、広域網１０２を通してＳＮＭＰ等を用いて交換する。稼動情報の収集・交換手段は、ＳＮＭＰに限定されず、機器の識別子、稼動情報種別及び値を単純にテキスト形式で並べて送受信する実装の容易なプロトコルを用いても良い。

アプリケーショングラフ管理部１４４は、アプリケーションを構成するサービスの依存関係を格納するアプリケーショングラフＤＢ１３５を操作（登録、削除、変更または参照）する。登録のための手法として、システム管理者が管理装置１０１を使用して手動で登録する手法のほか、データ転送装置１０３が、アプリケーショングラフを部分グラフに分割し、データ転送装置に再帰的に登録していく手法が考えられる。アプリケーショングラフは、サービスノードの利用予約時に、どのサービスノードに利用予約をするか判断するのに使用したり、実際に使用するサービスノードの選択時に使用したりする。アプリケーショングラフについては詳細を後述する。

データ転送装置１０３の利用予約管理部１４５は、他のデータ転送装置１０３から要求されるサービス利用予約を管理し、利用予約状況を格納する利用予約ＤＢ１３３を操作（登録、削除、更新または参照）する。利用予約Ｉ／Ｆ１５３を通してサービスの利用予約を受けたデータ転送装置１０３は、サービスを実行するのに使用されるサーバ１０５およびネットワークリソースの稼動情報を、サービスの利用予約を登録したデータ転送装置１０３に通知する。利用予約は、データ転送装置１０３に限らず、ユーザ端末１０４またはサーバ１０５等が行っても良い。

マッピング計算部１４６は、アプリケーショングラフおよびサービスノード情報に基づき、アプリケーションを構成するサービスを実行するサーバ群を選択する。サーバ群の選択指標としては、応答時間の短縮、サーバ負荷制御によるサービス実行の優先度制御、サーバ使用の片寄せによる省電力化等が考えられる。本実施形態では、アプリケーションの応答時間が最短となる手順を後述する。

装置連携部１５０は、サービスノード登録Ｉ／Ｆ１５１、サービスノード情報収集・交換Ｉ／Ｆ１５２、利用予約Ｉ／Ｆ１５３およびアプリケーショングラフ登録Ｉ／Ｆ１５４から構成される。各Ｉ／Ｆの通信シーケンスおよび通信内容については後述する。

ネットワークＩ／Ｆ１２２（１）は、広域網１０２を介して、管理装置１０１、他のデータ転送装置、およびユーザ端末１０４と通信するための装置であり、イーサネットなどの通信手段を用いることが考えられる。ネットワークＩ／Ｆ１２２（２）は、サーバ１０５およびＤＮＳ１０６と通信するための装置であり、ネットワークＩ／Ｆ１２２（１）と同様にイーサネットなどを利用できる。ネットワークＩ／Ｆ１２２は、ＣＰＵ１２１の制御によって動作し、広域網１０２またはＬＡＮ１０７とのパケット入出力を実行する。

サーバ１０５は、ＬＡＮ１０７を介して、データ転送装置１０３およびＤＮＳ１０６と通信する。サーバ１０５は、分散アプリケーションを構成するサービスを実行する。サーバ１０５では、ＳＮＭＰエージェントが稼動し、サーバ１０５内のＣＰＵおよびメモリ（図示省略）等の使用状況をデータ転送装置１０３に通知する。サーバ１０５は、分散アプリケーションのサービスが動作するのに必要な仕様(機種、性能等)を満たしていればよく、その形態は限定されない。例えば、サーバ１０５は、Ｌｉｎｕｘ等のＯＳが搭載された汎用ＰＣ（Personal Computer）等であっても良い。また、サーバ１０５は、物理的な装置ではなく、仮想計算機等の論理的な装置であっても良い。

ＤＮＳ１０６は、ＬＡＮ１０７を介して、データ転送装置１０３およびサーバ１０５と通信する。データ転送装置１０３のパケット解析部１４１およびサーバ１０５上のアプリケーションは、ホスト名からＩＰアドレスを取得する際に、ＤＮＳ１０６にホスト名を送信し、対応するＩＰアドレスを得る。同様に、ＤＮＳ１０６にＩＰアドレスを送信することで、ホスト名を参照することもできる。ＤＮＳ１０６は、ＬＡＮ１０７ではなく広域網１０２に接続されてもよい。

本実施例のＬＡＮ１０７は、イーサネット（登録商標：Ethernet）としたが、データ転送装置１０３、サーバ１０５およびＤＮＳ１０６が相互に通信できるかぎり、他の種類のネットワーク、例えば、Ｍｙｒｉｎｅｔ（登録商標）またはＩｎｆｉｎｉｂａｎｄ（登録商標）等であってもよい。他の通信手段の利用によって、通信速度および遅延時間の改善が可能となる。

ユーザ端末１０４は、広域網１０２を介して、データ転送装置１０３と通信する。ユーザ端末１０４は、ユーザ端末用アプリケーションが動作するのに必要な仕様(機種、処理性能等)を満たしていればよく、その形態は限定されない。例えば、ユーザ端末１０４は、ＰＣ、スマートフォンまたは携帯電話等であってもよい。

本実施形態の広域網１０２は、高遅延のＷＡＮ（Wide Area Network）である。本発明ではネットワークの遅延時間も考慮してリクエストの転送先が決定されるため、ネットワークの遅延が大きいほど本発明の効果も大きくなる。このため、本実施形態では広域網１０２の例として高遅延のＷＡＮを採用したが、IEEE 802.11a/b/g等の無線ＬＡＮ、イーサネットによるＬＡＮなど、他の通信手段によって置き換えられてもよい。他の通信手段の利用によって通信速度および配置の自由度等の改善が可能となる。

管理装置１０１は、広域網１０２を介してデータ転送装置１０３と通信し、サービスノード登録Ｉ／Ｆ（Interface）１５１を通してサービスノードを登録し、データ転送装置１０３のアプリケーショングラフ登録Ｉ／Ｆ１５４を通してアプリケーショングラフを登録する。通信は、Ｔｅｌｎｅｔ、ｓｓｈ等の既存のプロトコルに基づくものでも、独自のプロトコルに基づくものでもよい。管理装置１０１の通信手段、通信プロトコルは、本発明の本質とは関係がなく、データ転送装置１０３が提供する通信手段および通信プロトコルに対応していればよい。管理装置１０１からデータ転送装置１０３へ接続後、ＣＵＩ（Character-based User Interface）またはＧＵＩ（Graphical User Interface）等を備えたプログラムを通して、サービスノードＤＢ１３２の操作を行う。サービスノードＤＢ１３２の操作手段は、特に制限がなく、後述する内容を設定できればよい。人手による接続および設定が行われてもよいが、接続および設定のための一連の操作が自動化されてもよい。自動化された場合、設定ミスの軽減およびサーバ管理ソフトなどとの連携による管理・運用コスト削減が可能となる。

サービスノードは、分散アプリケーションを構成するプログラムが動作するサーバ１０５、または、サーバ１０５の代わりにサービス要求を受け付けるデータ転送装置１０３である。本実施形態では、データ転送装置１０３がサービス要求を透過的にサーバ１０５に転送するため、サービスノードに言及する際に、サーバ１０５とデータ転送装置１０３を区別していない。複数のサーバ１０５をそれらに接続された一つのデータ転送装置１０３によって集約して、それらを一つのサービスノードとして扱う形態も考えられる。個々の機器を区別する必要がある場合は、明示的にサーバ１０５またはデータ転送装置１０３と記載する。

続いて、本実施形態における分散処理システムの動作の概略について説明する。

まず、図２を用いて、本実施形態の分散処理システムにおいて実行される分散アプリケーションの構成を説明する。なお、図２ではデータ転送装置１０３およびネットワーク等の図示が省略されている。本分散アプリケーションは、ユーザ端末１０４で実行されるクライアントプログラム（Client）２０１、サーバ１０５（１）で実行されるサービスプログラム（MacNegatives）２０２、サーバ１０５（２）で実行されるサービスプログラム（Mac）２０３、およびサーバ１０５（３）で実行されるサービスプログラム（Add）２０４から構成される。なお、Client、MacNegatives、MacおよびAddは、提供されるサービスを識別する名称の一例である。

それぞれのプログラムはＸＭＬ−ＲＰＣ（Extensible Markup Language-Remote Procedure Call）プロトコルを用いて通信する。本実施形態ではＸＭＬ−ＲＰＣを用いる例を説明するが、ＳＯＡＰ（Simple Object Access Protocol）または独自プロトコルが用いられてもよい。ＳＯＡＰを用いることで再利用性、相互運用性の高いサービスプログラムの開発が可能となる。一方、独自プロトコルを用いる場合には、通信帯域および通信処理のオーバヘッドを改善できる。

図３〜図６は、図２の分散アプリケーションを構成するサービスプログラムの依存関係（すなわち、各サービスプログラムと、そのサービスプログラムによるサービスを提供するために使用される別のサービスプログラムとの関係）および構成するサービスプログラムのプロパティをＸＭＬ形式で定義したアプリケーショングラフのファイルの例を示している。依存関係としては、外部のプログラムと通信を行う関数のみを示せばよく、内部処理を記述する必要は必ずしもない。アプリケーショングラフは、分散アプリケーションを構成するサービスプログラムの依存関係およびサービスプログラムのプロパティを示していればよく、ＸＭＬ形式以外の形式で記述されてもよい。

図３のＸＭＬファイル３００は、クライアントプログラム（Client）のアプリケーショングラフを示している。行３０１のserviceタグはアプリケーションプログラム名（Client）、行３０２のpublic_methodタグは、他のプログラムに公開されているサービスメソッド（main）を示している。行３０３のcallタグは、public_method内で使用されている外部プログラムのサービスの呼び出し順序を規定する。呼び出しは、シーケンシャル（seq）、並列（par）または選択（alt）等が考えられる。行３０４のuse_serverタグは、外部サービスプログラムのＵＲＬ（http://mac-negatives-service-example.com/calc.php:80）、行３０５のuse_methodタグは、外部サービスプログラムのメソッド名（mac_negatives）を指定している。以降、既出のタグについては説明を省略する。

図４のＸＭＬファイル４００は、サービスプログラム（MacNegatives）のアプリケーショングラフを示している。行４０１のparamタグは、サービスメソッドに渡される引数の名前（a）および型（int）を示している。行４０２のresponseタグは、サービスメソッドの戻り値の型（int）を示している。paramタグおよびresponseタグは、分散アプリケーション全体のアプリケーショングラフを構築する際に、サービスメソッド呼び出しが定義と一致するか確認するために用いられる。

行４０３のrequirementタグでは、サービスメソッドが要求するリソース量、具体的には、サービスプログラムを実行するために必要とされるＣＰＵ処理時間（行４０４のcpuタグ）およびメモリ使用量（行４０５のmemoryタグ）を指定する。ＣＰＵ処理時間およびメモリ使用量は、プログラマが設計時にプロファイラ等を使用して取得しておく。図４の例では、ＣＰＵ処理時間およびメモリ使用量としてそれぞれ５０ｍｓおよび３００ＫＢが指定されている。これは、サービスプログラム（MacNegatives）によるサービスをサーバ１０５が処理するために必要なＣＰＵ時間が５０ｍｓであり、その処理のために必要なメモリ使用量が３００ＫＢであることを示している。

ＣＰＵ処理時間については、分散処理システム全体で統一の基準を設ける。例えば、Ｉｎｔｅｌ（登録商標）社のＸｅｏｎ（登録商標）の２．０ＧＨｚを基準ＣＰＵとして定義し、このＣＰＵの１コアを使用した場合の実行時間をＣＰＵ処理時間としてもよい。

行４０６のuse_serverタグは、外部サービスプログラムのＵＲＬ（http://mac-service-example.com/calc.php:80）、行４０７のuse_methodタグは、外部サービスプログラムのメソッド名（mac）を指定している。

図５のＸＭＬファイル５００は、サービスプログラム（Mac）のアプリケーショングラフを示している。図４の場合と同様、行５０１および行５０２において、サービスプログラム（Mac）によるサービスをサーバ１０５が処理するために必要なＣＰＵ時間およびメモリ使用量が指定されている。また、行５０３のuse_serverタグは、外部サービスプログラムのＵＲＬ（http://add-service-example.com/calc.php:80）、行５０４のuse_methodタグは、外部サービスプログラムのメソッド名（add）を指定している。

図６のＸＭＬファイル６００は、サービスプログラム（Add）のアプリケーショングラフを示している。図４の場合と同様、行６０１および行６０２において、サービスプログラム（add）によるサービスをサーバ１０５が処理するために必要なＣＰＵ時間およびメモリ使用量が指定されている。

なお、図４から図６に示すアプリケーショングラフは、データ転送装置１０３のアプリケーショングラフＤＢ１３５に格納される（図１３Ａ〜図１３Ｅ参照）。データ転送装置１０３は、行４０６、４０７、５０３および５０４によって指定された情報を参照することによって、サービスプログラムの依存関係を特定することができる。

続いて、図７を用いて、分散アプリケーションが動作する分散処理システムのネットワーク構成を説明する。ユーザ端末７０１、データ転送装置７０２およびＤＮＳ７０４は、ネットワーク７００によって接続されている。データ転送装置７０２の後段にはサーバ７０３が接続されている。なお、図７のネットワーク７００、ユーザ端末７０１、データ転送装置７０２、サーバ７０３およびＤＮＳ７０４は、それぞれ、図１に示す広域網１０２、ユーザ端末１０４、データ転送装置１０３、サーバ１０５およびＤＮＳ１０６に相当する。ただし、図７の例ではＤＮＳ７０４がネットワーク７００（すなわち広域網１０２）に接続されている。

図７において、データ転送装置７０２およびサーバ７０３の内部に、各装置のＩＰアドレスの略称が記載されている。例えば、データ転送装置７０２（１）のＩＰアドレスの略称は「Ａｇ」および「Ａｐ」である。「Ａｇ」は広域網１０２における（すなわちネットワークＩ／Ｆ１２２（１）の）ＩＰアドレスに、「Ａｐ」はＬＡＮ１０７における（すなわちネットワークＩ／Ｆ１２２（２）の）ＩＰアドレスに相当する。図８にアドレス略称８０１とＩＰアドレス８０２の対応を示す。

本実施形態では、ユーザ端末７０１からのサービス実行要求に対し、分散処理システムは、応答時間が短くなるようにサーバおよびネットワーク経路を選択し、サービス実行およびデータの転送を行う。

ただし、本発明では、データ転送装置によるサーバおよびネットワーク経路の選択基準を変更することで、応答時間の改善だけでなく、サーバ利用およびネットワーク利用の偏在化などを実現できる。サーバ利用、ネットワーク利用の偏在化によって、未使用状態のサーバおよびルータを一時的に作り出し、そのサーバおよびルータの電源を遮断することで、省電力化または優先度の高い要求に対するリソース確保などが実現できる。

ユーザ端末７０１で動作するクライアントプログラム（Client）２０１は、サービスプログラム（MacNegatives）２０２の公開ＩＰアドレスをＤＮＳ７０４から取得し、その公開ＩＰアドレスにサービス要求パケットを送信する。図７の例ではＩＰアドレス「Ｃｇ」が取得され、サービス要求パケットは、データ転送装置７０２（３）に送られる。本実施形態では、サービスプログラムのＩＰアドレスとして、データ転送装置７０２のＩＰアドレスがＤＮＳ７０４で公開されていることを前提とする。データ転送装置７０２の詳細な動作についてはフローチャートを参照して後述する。

データ転送装置７０２（３）は、新規セッションを作成し、本発明のマッピング計算部１４６によって、応答時間が最短となるサービス提供が期待されるサービスノード群を選択する。アプリケーショングラフに対するマッピング結果は、マップ結果ＤＢ１３４に格納される。リソースマッピングの詳細については後述する。

その後、データ転送装置７０２（３）は、サービスプログラム（MacNegatives）が実際に動作しているサーバのＩＰアドレス宛にＮＡＰＴ（Network Address Port Translation）を適用し、パケットを転送する。すなわち、送信元ＩＰアドレスをデータ転送装置７０２（３）のアドレス８０４、送信元ポートを自動的に割り当てたＮＡＰＴポート９０７のポート番号（5001）、送信先ＩＰアドレスをサーバ７０３（３）のアドレス８０３、ポート番号をサーバ７０３（３）で動作しているサービスプログラムの待ち受けポート番号（80）に書き換える。

本実施形態では、リソースマッピングの契機を、パケットの到着時としているが、サービスノードの稼動情報を更新するたびにリソースマッピングを実行してもよい。パケット受信とリソースマッピングとを独立させることで、データ転送装置のＣＰＵ負荷を分散させることが期待される。

パケットを受信したサーバ７０３（３）のサービスプログラム（MacNegatives）は、外部のサービスプログラム(Mac)を使用してサービスを提供しているため、サービスプログラム（Mac）の公開ＩＰアドレスをＤＮＳ７０４から取得し、取得した公開ＩＰアドレスにサービス要求パケットを送信する。サーバ７０３（３）のデフォルトゲートウェイはデータ転送装置７０２（３）となっており、このサービス要求パケットはデータ転送装置７０２（３）に送信される。

データ転送装置７０２（３）は、新規のセッションを作成し、リソースマッピングの結果をマップ結果ＤＢ１３４から読み出し、サービスプログラム（Mac）のサービスを提供しているサービスノードを選択する。データ転送装置７０２（３）は、送信先ＮＡＰＴおよび送信元ＮＡＰＴをパケットに実施し送信する。送信先はデータ転送装置７０２（１）、送信元は、データ転送装置７０２（３）となる。

以下、同様に、データ転送装置７０２（１）でサーバ７０３（１）が選択され、サーバ７０３（１）から送信されたサービスプログラム（Add）宛のパケットがデータ転送装置７０２（１）によってデータ転送装置７０２（２）に送られる。データ転送装置７０９（２）は、サーバ７０３（２）上のサービスプログラム（２）へパケットを送信する。処理の結果は、これまでの逆向きの経路を辿って最終的にユーザ端末７０１に返信される。

続いて、データ転送装置を実現する上で必要となる、セッションＤＢ１３１、サービスノードＤＢ１３２、利用予約ＤＢ１３３、マップ結果ＤＢ１３４およびアプリケーショングラフＤＢ１３５について説明する。

図９Ａの表９２０に、データ転送装置７０２（３）のセッションＤＢ１３１の例を示す。セッションＤＢ１３１は、セッション管理部１４２によって作成および参照される。セッションＤＢ１３１が格納する情報は、登録フラグ９０１、接続元ＩＰアドレス９０２、接続元ポート９０３、接続先ＩＰアドレス９０４、接続先ポート９０５、プロトコル番号９０６、ＮＡＰＴポート９０７、サービスＩＰアドレス９０８、サービスポート９０９、接続状態９１０およびタイムスタンプ９１１等である。

セッションＤＢの実装方法としては、ハッシュテーブル、ＲＤＢ（Relational Database）等によるソフトウェア実装、またはＣＡＭを使ったハードウェア実装が考えられる。本実施形態では、ＤＲＡＭ上に格納されるハッシュを使用した例について説明する。

登録フラグ９０１は、ハッシュにおいてそのエントリが登録済みか否かを示す。

本実施形態では、セッションは、ＴＣＰの場合はコネクションに相当するものとし、ＵＤＰの場合は通信が存在する一定期間の接続関係を示すものとする。セッションが無い状態から最初にセッションを作成するパケットの送信元を接続元、送信先を接続先とする。接続元ＩＰアドレス９０２および接続元ポート９０３は、それぞれパケットの送信元ＩＰアドレスおよび送信元ポート番号を記録する。同様に接続先ＩＰアドレス９０４および接続先ポート９０５は、それぞれパケットの送信先ＩＰアドレスおよび送信先ポート番号を記録する。

プロトコル番号９０６は、ＩＰプロトコルで定義されている番号であり、ＴＣＰ、ＵＤＰ等の番号である。ＮＡＰＴポート９０７は、データ転送装置で送信元ＮＡＰＴを適用した場合に自動的に割り当てられる、装置内で一意となるポート番号である。

サービスＩＰアドレス９０８およびサービスポート９０９は、リソースマッピングの結果、割り当てられたサービスノードのＩＰアドレスおよびサービスノードのポート番号である。

接続状態９１０はセッションの接続状態を示す。接続状態については後述する。タイムスタンプ９１１は、セッションエントリが最後に更新された時刻を格納する。タイムスタンプ９１１は、ＴＣＰコネクションが切断されてから、セッションエントリを未使用状態にするまでのタイムアウト時間の基準時刻として使用したり、ＵＤＰ通信において非通信状態がどのくらい続いているかを測定したりするのに使用する。

図９Ｂの表９３０に、データ転送装置７０２（１）のセッションＤＢ１３１の例を、図９Ｃの表９４０にデータ転送装置７０２（２）のセッションＤＢ１３１の例を示す。図９Ａ〜図９Ｃに示す表９２０、表９３０および表９４０の内容は、分散アプリケーションを構成するサービスプログラムがすべて接続された状態を示す。

例えば、図９Ａの表９２０の先頭のエントリの接続元ＩＰアドレス９０２としてユーザ端末７０１のＩＰアドレスである「10.0.0.1」が、接続先ＩＰアドレス９０４としてデータ転送装置７０２（３）のグローバルＩＰアドレスである「10.0.1.3」が、サービスＩＰアドレス９０８としてサーバ７０３（３）のＩＰアドレスである「192.168.1.3」が、それぞれ記録されている。この場合、データ転送装置７０２（３）は、ユーザ端末７０１からデータ転送装置７０２（３）に送信されたパケットの送信先をサーバ７０３（３）のＩＰアドレスに書き換えて送信する。

同様に、表９２０の２番目のエントリの接続元ＩＰアドレス９０２として「192.168.1.3」が、接続先ＩＰアドレス９０４としてデータ転送装置７０２（５）のグローバルＩＰアドレスである「10.0.1.5」が、サービスＩＰアドレス９０８としてデータ転送装置７０２（１）のグローバルＩＰアドレスである「10.0.1.1」が、それぞれ記録されている。この場合、データ転送装置７０２（３）は、サーバ７０３（３）からデータ転送装置７０２（５）に送信されたパケットの送信先をデータ転送装置７０２（１）のＩＰアドレスに書き換えて送信する。

なお、上記の２番目のエントリの例は、サーバ７０３（３）がＤＮＳ７０４から取得したサービスプログラム（Mac）の公開ＩＰアドレスが「10.0.1.5」であった（より詳細には、取得した公開ＩＰアドレスのリストの先頭が「10.0.1.5」であった）ことを示す。データ転送装置７０２（３）は、後述するリソースマッピングによって、パケットの最適な送信先（すなわち応答時間が最も短くなる送信先）としてデータ転送装置７０２（１）を選択し、パケットの送信先を「10.0.1.1」に書き換える。ＤＮＳ７０４から取得したＩＰアドレスとリソースマッピングによって選択されたＩＰアドレスが同一である可能性もあり、その場合、サービスＩＰアドレス９０８は接続先ＩＰアドレス９０４と同一になる（図９Ｂの２番目のエントリ参照）。

図１０Ａ、図１０Ｂおよび図１０Ｃは、データ転送装置７０２（３）のサービスノードＤＢ１３２の例を示している。サービスノードＤＢ１３２は、サービスノード管理部１４３によって作成および参照される。サービスノードＤＢ１３２は主に、サービスＩＤ表１０２０、サービスノード稼動情報表１０２１およびサービスノード間往復遅延表１０２２から構成される。サービスノード稼動情報表１０２１は主にノードのプロパティ、サービスノード間往復遅延表１０２２はネットワークのプロパティを格納する。プロパティの項目、表の分割方法はこの例に限らない。例えば、サービスノードのプロパティとして消費電力を追加しても良いし、ネットワークのプロパティとして帯域使用率等を追加しても良い。また、表を管理のしやすいように分離または統合しても良い。

サービスノードＤＢ１３２は、ハッシュテーブル、配列構造、またはＲＤＢ等による実装が考えられる。本実施形態では、ＤＲＡＭ上に格納される配列構造を使用した例について説明する。

サービスＩＤ表１０２０が格納する情報は、ＩＤ１００１、サービスＵＲＬ１００２およびメソッド１００３である。サービスＩＤ表１０２０は、サービスＵＲＬ１００２およびメソッド１００３によって一意に定義される識別子をＩＤ１００１として対応付けるものである。

サービスノード稼動情報表１０２１が格納する情報は、サービスＩＤ１００４、ＩＰアドレス１００５、ＣＰＵ負荷１００６、空きメモリ容量（ＧＢ）１００７等である。サービスＩＤ１００４は、サービスＩＤ表１０２０のＩＤ１００１に対応する。ＩＰアドレス１００５は、サービスＩＤ１００４で識別されるサービスを提供している装置（データ転送装置７０２またはサーバ７０３）のＩＰアドレス（すなわち、そのサービスを要求するパケットの送信先として指定できるＩＰアドレス）であり、ＣＰＵ負荷１００６および空きメモリ容量（ＧＢ）１００７は前記装置の稼動情報である。ＣＰＵ負荷１００６および空きメモリ容量（ＧＢ）１００７は、サーバ７０３および他のデータ転送装置７０２から収集され、随時更新される。

なお、サービスＩＤ表１０２０には、例えば、管理者が管理装置１０１を操作して入力した情報が登録される。サービスノード稼動情報表１０２１のサービスＩＤ１００４、ＩＰアドレス１００５、サービスノード間往復遅延表１０２２の送信元ＩＰ１００８および送信先ＩＰ１００９についても同様である。これらの情報に基づいて、各サービスプログラムを使用するサービス要求パケットの送信先として指定できるアドレスを特定することができる。

例えば、サービスプログラム（Mac）２０３を使用するサービス要求パケットについては、メソッド「mac」に対応するサービスＩＤ１００１の値「２」と同じサービスＩＤ１００４に対応する二つのＩＰアドレス「10.0.1.1」及び「10.0.1.5」が特定される。これは、サービスプログラム（Mac）２０３を使用するサービス要求パケットをデータ転送装置７０２（１）または７０２（５）に送信できること（すなわち、それらのデータ転送装置７０２に接続されたサーバ７０３がサービスプログラム（Mac）２０３を実行できること）を意味する。

サービスノード間往復遅延表１０２２が格納する情報は、送信元ＩＰ１００８、送信先ＩＰ１００９、および送信元ＩＰ１００８と送信先ＩＰ１００９間の往復遅延（ｍｓ）１０１０である。往復遅延（ｍｓ）１０１０は、送信元ＩＰ１００８と送信先ＩＰ１００９間の往復遅延であり、データ転送装置７０２がpingなどの仕組みを用いて直接収集するか、他のデータ転送装置７０２から収集するなどの方法によって、随時更新される。

図１０Ｂの例では、ＩＰアドレス「192.168.1.3」に対応するＣＰＵ負荷１００６として「１」が格納されている。これは、データ転送装置７０２（３）に接続されたサーバ７０３（３）のＣＰＵ負荷が「１」であることを示す。一方、ＩＰアドレス「10.0.1.1」に対応するＣＰＵ負荷１００６として「２」が格納されている。これは、データ転送装置７０２（１）に接続されたサーバ７０３（１）のＣＰＵ負荷が「２」であることを示す。同様に、図１０Ｂのサービスノード稼動情報表１０２１は、データ転送装置７０２（５）に接続されたサーバ７０３（５）、データ転送装置７０２（２）に接続されたサーバ７０３（２）、およびデータ転送装置７０２（４）に接続されたサーバ７０３（４）のＣＰＵ負荷が、それぞれ「２」、「１」および「３」であることを示す。

なお、ＣＰＵ負荷１００６の値をアプリケーショングラフによって指定された処理時間に乗じることによって、ＣＰＵ負荷の影響を考慮した実際のＣＰＵ処理時間が計算される。例えば、サービスプログラム（Add）を使用するサービス要求パケットをデータ転送装置７０２（４）が受信した場合の処理時間は、１００ｍｓ（図６の行６０１）×３（エントリ１０１４のＣＰＵ負荷１００６）＝３００ｍｓと計算される。

また、サービスノード稼動情報表１０２１のＩＰアドレス１００５に格納されているアドレスが、自身（すなわちデータ転送装置７０２（３））に接続されたサーバ７０３（３）のアドレスであるか、他のデータ転送装置７０２のアドレスであるかは、そのアドレスの値そのものに基づいて判定してもよいが、サービスノード稼動情報表１０２１が両者を区別するフラグ情報をさらに保持し、それに基づいて判定してもよい。

一方、図１０Ｃの例では、サービスノード間往復遅延表１０２２の先頭のエントリの送信元ＩＰ「10.0.1.3」および送信先ＩＰ「192.168.1.3」に対応する往復遅延１０１０として「２」が格納されている。これは、データ転送装置７０２（３）とサーバ７０３（３）との間をパケットが往復するのに要する時間が２ｍｓであることを示す。同様に、２番目以降のエントリには、二つのデータ転送装置７０２間をパケットが往復するのに要する時間が格納されている。例えば、５番目のエントリは、データ転送装置７０２（１）とサーバ７０３（４）との間をパケットが往復するのに要する時間が２５０ｍｓであることを示す。

上記のように、サービスプログラム（Add）を使用するサービス要求パケットをデータ転送装置７０２（４）が受信した場合の処理時間が１００ｍｓであるので、データ転送装置７０２（１）が当該パケットをデータ転送装置７０２（４）に送信してから、それに対する応答を受信するまでの時間（すなわち応答遅延時間）は、１００ｍｓ＋２５０ｍｓ＝３５０ｍｓと計算される。

図１０Ｄ、図１０Ｅおよび図１０Ｆは、それぞれ、データ転送装置７０２（１）のサービスノードＤＢ１３２に含まれるサービスＩＤ表１０３０、サービスノード稼動情報表１０３１およびサービスノード間往復遅延表１０３２の内容の例を示している。図１０Ｇ、図１０Ｈおよび図１０Ｉは、それぞれ、データ転送装置７０２（２）のサービスノードＤＢ１３２に含まれるサービスＩＤ表１０４０、サービスノード稼動情報表１０４１およびサービスノード間往復遅延表１０４２の内容の例を示している。

図１１Ａの表１１２０に、データ転送装置７０２（３）の利用予約ＤＢ１３３の例を示す。利用予約ＤＢ１３３は、利用予約管理部１４５によって作成および参照される。利用予約ＤＢ１３３が格納する情報は、サービスＵＲＬ１１０１、メソッド１１０２および利用予約元１１０３等である。

利用予約ＤＢ１３３は、ハッシュテーブル、配列構造、ＲＤＢ、またはＣＡＭ等による実装が考えられる。本実施形態では、ＤＲＡＭ上に格納される配列構造を使用した例について説明する。

サービスＵＲＬ１１０１は、サービスにアクセスする際に使用するＵＲＬであり、サービスを一意に示す文字列およびポート番号から構成される。ＵＲＬは、サービスを一意に示せればよく、ＩＰアドレスまたはＵＵＩＤ（Universally Unique Identifier）によって表現されてもよい。

メソッド１１０２には、サービスの機能が登録される。利用予約元１１０３には、データ転送装置７０２が収集したサービスノードの稼動情報を通知するＩＰアドレスが登録される。サービスノードの稼動情報は、サーバ単位、またはデータ転送装置で集約した稼動単位で収集することが考えられる。データ転送装置７０２で稼動情報を集約した場合は、負荷分散などによる処理性能向上および冗長構成による高信頼化などの効果が得られる。利用予約元への通知は、１エントリずつ実行してもよいし、複数ＣＰＵによる並列実行をしてもよい。並列実行した場合は、短時間で利用予約元に稼動情報を通知することが可能となる。

図１１Ｂの表１１３０、図１１Ｃの表１１４０、図１１Ｄの表１１５０および図１１Ｅの表１１６０は、それぞれ、データ転送装置７０２（１）、データ転送装置７０２（５）、データ転送装置７０２（２）およびデータ転送装置７０２（４）の利用予約ＤＢ１３３の例を示している。

例えば、データ転送装置７０２（３）が保持する表１１２０には、サービスＵＲＬ「http://mac-negatives-service-example.com/calc.php:80」およびメソッド「mac_negatives」に対応する利用予約元として、データ転送装置７０２（３）自身のグローバルＩＰアドレスである「10.0.1.3」が登録されている。この場合、データ転送装置７０２（３）は、自らが管理する、サービスプログラム（MacNegatives）を実行するサーバ７０３（すなわちサーバ７０３（３））から稼動情報を取得し、その稼動情報をデータ転送装置７０２（３）自身が保持する。

一方、データ転送装置７０２（１）が保持する表１１３０には、サービスＵＲＬ「http://mac-service-example.com/calc.php:80」およびメソッド「mac」に対応する利用予約元として、データ転送装置７０２（１）自身のグローバルＩＰアドレスである「10.0.1.1」及びデータ転送装置７０２（３）のグローバルＩＰアドレスである「10.0.1.3」が登録されている。この場合、データ転送装置７０２（１）は、自らが管理する、サービスプログラム（Mac）を実行するサーバ７０３（１）から稼動情報を取得し、その稼動情報をデータ転送装置７０２（１）自身が保持し、さらに、その稼動情報をデータ転送装置７０２（３）に送信する。

上記のように、本実施形態において「利用予約」とは稼動情報の送信要求に相当し、「利用予約元」とは、送信要求の要求元、すなわち、稼動情報の送信先を意味する。利用予約元は、利用予約先のデータ転送装置７０２を将来利用する（すなわちそこにサービス要求パケットを送信する）可能性はあるが、必ず利用するとは限らない。

本実施形態において、データ転送装置７０２（３）は、残りすべてのデータ転送装置７０２から、サービスノードの稼動情報を直接収集しているが、途中のデータ転送装置７０２を中継して収集する方法も考えられる。例えば、データ転送装置７０２（３）がデータ転送装置７０２（２）から受信する稼動情報は、データ転送装置７０２（１）にも送られているため、データ転送装置７０２（１）がデータ転送装置７０２（２）から送られた稼動情報をデータ転送装置７０２（３）に転送してもよい。このように、稼動情報を間接的に収集することで、稼動情報のトラフィック量を削減することが可能である。

図１２Ａの表１２２０に、データ転送装置７０２（３）のマップ結果ＤＢ１３４の例を示す。マップ結果ＤＢ１３４は、マッピング計算部１４６によって作成および参照される。マップ結果ＤＢ１３４が格納する情報は、サービスＵＲＬ１２０１、メソッド１２０２および実行サービスノード１２０３等である。

マップ結果ＤＢ１３４は、ハッシュテーブル、配列構造、ＲＤＢまたはＣＡＭ等によって実装することが考えられる。本実施形態では、ＤＲＡＭ上に格納される配列構造を使用した例について説明する。サービスＵＲＬ１２０１およびメソッド１２０２は、利用予約ＤＢ１３３におけるサービスＵＲＬおよびメソッドに相当するものである。実行サービスノード１２０３は、マッピングの結果選択されたサービスを実行するサービスノードのＩＰアドレスである。サービスノードは、サーバ７０３である場合と、データ転送装置７０２である場合がある。

図１２Ｂの表１２３０および図１２Ｃの表１２４０は、それぞれデータ転送装置７０２（１）およびデータ転送装置７０２（２）のマップ結果ＤＢ１３４の例を示している。

表１２２０の作成方法について説明する。まず、エントリ１２０４のサービスＵＲＬを実行可能なサービスノードが、表１０２１からサーバ７０３（３）のみであるため、実行サービスノード１２０３は192.168.1.3と決定される。エントリ１２０５のサービスＵＲＬを実行可能なサービスノードは、表１０２１のエントリ１０１１およびエントリ１０１２から、データ転送装置７０２（１）またはデータ転送装置７０２（５）と分かる。同様に、エントリ１２０５のサービスＵＲＬを実行可能なサービスノードは、表１０２１のエントリ１０１３およびエントリ１０１４から、データ転送装置７０２（２）またはデータ転送装置７０２（４）と分かる。

本実施形態では応答遅延時間を短縮するサービスノードの選択をする。ＣＰＵ負荷は、基準を１として何倍処理時間が増加するかを示す数値である。サービスノードの詳細な選択手順は後述するため、計算結果の一例を示す。アプリケーション名MacNegativesの処理時間は行４０４に記載された５０ｍｓ、アプリケーション名Macの処理時間は行５０１に記載された１５０ｍｓ、アプリケーション名Addの処理時間は行６０１に記載された１００ｍｓであり、それぞれアプリケーショングラフＤＢ１３５に格納されている。

例えば、データ転送装置７０２（３）−データ転送装置７０２（１）−データ転送装置７０２（２）を使用した場合（すなわち、ユーザ端末７０１がサービスプログラム（MacNegatives）２０２を使用するサービス要求パケットをデータ転送装置７０２（３）に送信し、データ転送装置７０２（３）がサービスプログラム（Mac）２０３を使用するサービス要求パケットをデータ転送装置７０２（１）に送信し、データ転送装置７０２（１）がサービスプログラム（Add）２０４を使用するサービス要求パケットをデータ転送装置７０２（２）に送信する場合）の応答遅延時間は、５０ｍｓ（処理時間）×１（ＣＰＵ負荷）＋２００ｍｓ（通信遅延）＋１５０ｍｓ（処理時間）×２（ＣＰＵ負荷）＋５０ｍｓ（通信遅延）＋１００ｍｓ（処理時間）×１（ＣＰＵ負荷）によって計算され、合計７００ｍｓとなる。なお、データ転送装置７０２（３）、７０２（１）および７０２（２）のＣＰＵ負荷はサービスノード稼動情報表１０２１（図１０Ｂ）から、データ転送装置７０２（３）とデータ転送装置７０２（１）の間の通信遅延およびデータ転送装置７０２（１）とデータ転送装置７０２（２）の間の通信遅延はサービスノード間往復遅延表１０２２（図１０Ｃ）から取得される。

データ転送装置７０２（３）は、同様にして、データ転送装置７０２（３）−データ転送装置７０２（１）−データ転送装置７０２（４）を使用した場合、データ転送装置７０２（３）−データ転送装置７０２（５）−データ転送装置７０２（２）を使用した場合、およびデータ転送装置７０２（３）−データ転送装置７０２（５）−データ転送装置７０２（４）を使用した場合のそれぞれの応答遅延時間を計算する。

本実施形態では、応答遅延時間が小さくなるようにパケットの送信先が決定される。上記の例では、上記の４通りの組み合わせについて計算した応答遅延時間のうち、データ転送装置７０２（３）−データ転送装置７０２（１）−データ転送装置７０２（２）を使用した場合の応答遅延時間が最も小さい。このため、データ転送装置７０２（３）は、サービスプログラム（Mac）２０３を使用するサービス要求パケットの送信先としてデータ転送装置７０２（１）を選択する。

上記のように応答遅延時間が小さくなるようにパケットの送信先の組み合わせを選択する処理（すなわちリソースマッピング処理）の詳細な手順については、図２０〜図２２を参照して後述する。

図１３Ａの表１３２０に、データ転送装置７０２（３）のアプリケーショングラフＤＢ１３５の例を示す。アプリケーショングラフＤＢ１３５は、アプリケーショングラフ管理部１４４によって作成および参照される。アプリケーショングラフＤＢ１３５が格納する情報は、アプリケーション名１３０１、グラフ１３０２、ＩＰアドレス１３０３およびポート番号１３０４等である。

アプリケーション名１３０１は、アプリケーションを識別する一意の識別子であれば、文字列でも数字でもよい。

グラフ１３０２は、アプリケーショングラフデータへのポインタを格納する。アプリケーショングラフデータは、隣接行列または隣接リストに変換した形式で保存することが考えられ、公知または周知の技術を使用することができる。アプリケーショングラフデータもアプリケーショングラフＤＢ１３５内に格納される。

ＩＰアドレス１３０３およびポート番号１３０４は、アプリケーションと通信する際に使用する代表ＩＰアドレスおよび代表ポート番号であり、実際のアプリケーションは他のサーバで実行される。本実施形態では、アプリケーションをＩＰアドレスおよびポート番号で区別しているが、ポート番号の代わりに、ペイロード内に埋め込まれた、数字または文字列といった識別子によって区別してもよい。ペイロードでアプリケーションを識別する場合、少ないポート番号のみを開放すれば足りるため、セキュリティ確保などの面で運用が容易となる。

アプリケーショングラフＤＢ１３５は、ハッシュテーブル、配列構造、ＲＤＢまたはＣＡＭ等によって実装することが考えられる。本実施形態では、ＤＲＡＭ上に格納される配列構造を使用した例について説明する。

アプリケーショングラフデータは、サービスノードＵＲＬをグラフノードとして、ノード間をエッジで結合した形式で表現される。例えば、図２に示すサービスプログラム２０２〜２０４がノードに、それらを結合する矢印がエッジに相当する。ノードにはプロパティとして、サービスのＣＰＵ使用時間、メモリ使用量等、サービスを実行する際の条件などが格納される。エッジには、プロパティとして、必要なネットワーク帯域、要求通信時間等の条件が格納される。

同様に、図１３Ｂの表１３３０、図１３Ｃの表１３４０、図１３Ｄの表１３５０および図１３Ｅの表１３６０は、それぞれ、データ転送装置７０２（１）、データ転送装置７０２（５）、データ転送装置７０２（２）およびデータ転送装置７０２（４）のアプリケーショングラフＤＢ１３５の例を示している。

図１４に、アプリケーショングラフの登録シーケンスを示す。アプリケーショングラフの登録は、ネットワークシステム管理者が管理装置１０１を用いて実行する。

ネットワークシステム管理者は、管理装置１０１を用いてデータ転送装置７０２（３）のアプリケーショングラフ管理部１４４へアクセスし、予め作成したアプリケーショングラフを定義するＸＭＬファイル（図４〜図６参照）を転送するか、またはコンソール上で入力することで、アプリケーショングラフを登録できる（メッセージ１４０７）。アプリケーショングラフ管理部１４４は、アプリケーショングラフＤＢ１３５にアプリケーショングラフを保存する（メッセージ１４０８）。

なお、ネットワークシステム管理者は、上記と同様の手順で他のデータ転送装置７０２にもアプリケーショングラフを登録する必要がある。具体的には、ネットワークシステム管理者は、上記と同様の手順で図４〜図６に示すＸＭＬファイルを各データ転送装置７０２に転送し、それぞれのアプリケーショングラフＤＢ１３５に保存させてもよい。

ただし、図７以降に示した例では、リソースマッピングを行うためにデータ転送装置７０２（１）および７０２（５）が保存する必要がある情報は図５および図６に示したもののみであり、データ転送装置７０２（２）および７０２（４）が保存する必要がある情報は図６に示したもののみである。各データ転送装置７０２は、転送された全ての情報を保存してもよいが、必要なものだけを保持し、その他のものを廃棄してもよい。あるいは、管理装置１０１が各データ転送装置７０２に必要な情報だけを転送してもよい。

次に、データ転送装置７０２（３）の利用予約管理部１４５は、利用予約ＤＢ１３３にサービス（MacNegatives）を登録する（メッセージ１４０９）。これによって、表１１２０の先頭のエントリが登録される（図１１Ａ参照）。

次に、アプリケーショングラフ管理部１４４は、アプリケーショングラフからサービス（MacNegatives）がサービス（Mac）を使用していることを検出し、サービス（Mac）を提供しているデータ転送装置７０２を、サービスノードＤＢ１３２から検索する（メッセージ１４１０）。そして、検索されたサービス（Mac）を提供しているデータ転送装置７０２に対して、サービス（Mac）の利用予約を登録する（メッセージ１４１１）。サービス（Mac）を提供しているデータ転送装置７０２が複数存在する場合は、すべてのデータ転送装置７０２に対してメッセージ１４１１を送信する。本実施例では、データ転送装置７０２（１）およびデータ転送装置７０２（５）の二つが該当するため、これらにメッセージ１４１１が送信される。

データ転送装置７０２（１）およびデータ転送装置７０２（５）では、それぞれが持つ利用予約ＤＢにサービス（Mac）を登録する（メッセージ１４１２）。これによって表１１３０および表１１４０の各エントリが登録される（図１１Ｂおよび図１１Ｃ参照）。

サービス(Mac)はサービス（Add）を使用しているため、データ転送装置７０２（３）の動作と同様に、サービス（Add）を提供しているデータ転送装置を検索し（メッセージ１４１３）、発見したデータ転送装置７０２（２）およびデータ転送装置７０２（４）にサービス（Add）の利用予約を登録する（メッセージ１４１４）。

最後にデータ転送装置７０２（２）およびデータ転送装置７０２（４）では、それぞれが持つ利用予約ＤＢにサービス（Add）を登録する（メッセージ１４１５）。これによって表１１５０および表１１６０の各エントリが登録される（図１１Ｄおよび図１１Ｅ参照）。

図１５に、サーバの稼動情報を収集するシーケンスを示す。本実施形態では、ブロック１５０１に示すように、データ転送装置７０２がサーバの稼動情報を繰り返し収集する。具体的には、すべてのデータ転送装置７０２は、自身に接続されたサーバに対してＳＮＭＰを用いてＣＰＵ負荷およびメモリ使用量等の稼動情報を収集する（メッセージ１５０３）。ＳＮＭＰは多くのサーバ・ネットワーク機器でサポートされているため、これを用いることによって統一された収集方法を実現できる。ただし、この収集方法は一例であり、ＳＮＭＰを用いない方法によって稼動情報を収集してもよい。

それぞれのデータ転送装置７０２は、稼動情報を収集後、利用予約ＤＢに基づき、稼動情報を必要なデータ転送装置７０２（すなわち利用予約ＤＢ１３３に利用予約元として登録されたデータ転送装置７０２）のみに送る（ブロック１５０２）。本実施形態では、稼動情報は途中のデータ転送装置７０２に中継させている。

具体的には、データ転送装置７０２（１）がデータ転送装置７０２（３）に送信する稼動情報（メッセージ１５０４）は、データ転送装置７０２（１）がサーバ７０３（１）から取得した稼動情報だけでなく、データ転送装置７０２（１）がデータ転送装置７０２（２）から取得した稼動情報（メッセージ１５０７）およびデータ転送装置７０２（４）から取得した稼動情報（メッセージ１５１０）を含む。同様に、データ転送装置７０２（５）がデータ転送装置７０２（３）に送信する稼動情報（メッセージ１５０５）は、データ転送装置７０２（５）がサーバ７０３（５）から取得した稼動情報だけでなく、データ転送装置７０２（５）がデータ転送装置７０２（２）から取得した稼動情報（メッセージ１５０８）およびデータ転送装置７０２（４）から取得した稼動情報（メッセージ１５１１）を含む。なお、データ転送装置７０２（２）及び７０２（４）が送信する稼動情報は、それぞれ、サーバ７０３（２）および７０３（４）から取得された稼動情報を含む。

ただし、上記のような収集方法は一例であり、データ転送装置に中継させずに稼動情報を収集する方法も考えられる。その場合、各データ転送装置７０２は、サーバ７０３から取得した稼動情報を、利用予約元として登録されたデータ転送装置７０２に直接送信する。

上記のメッセージ１５０３〜１５１１の送受信（すなわちブロック１５０１）を所定のタイミングで（例えば定期的に）繰り返し実行することによって、サービスノードＤＢのＣＰＵ負荷１００６及び空きメモリ容量１００７等が最新の値に更新される。これによって、サーバ７０３の稼動状態が変化した場合にも、最新の稼動状態に基づいて最適なリソースマッピングを行うことができる。

図１６にデータ転送装置間でリソースマッピングの結果を伝播させる処理のシーケンスを示す。

データ転送装置７０２（３）が、サービス（MacNegatives）への新規要求１６０１をユーザ端末７０１から受信すると、マップ要求１６０２がデータ転送装置７０２（３）のマッピング計算部１４６に通知される。リソースマッピングの詳細については後述する。

マッピングの結果、分散アプリケーションを実行するサーバ群が決定される。本実施形態では、サービス(MacNegatives)はサーバ７０３（３）、サービス(Mac)は、データ転送装置７０２（１）、サービス（Add）は、データ転送装置７０２（２）にマップされる。データ転送装置７０２（３）は、リソースマッピング後、サービス（Add）のマッピング結果１６０３をデータ転送装置７０２（１）へ送ることができる。

データ転送装置７０２（１）は、受信したサービス（Add）のマッピング結果を使用することによって、マッピング処理の実行を省略することができ、より多くの要求を短時間に処理することができるようになる。

ただし、データ転送装置７０２（１）は、自身でサービス（Add）のマッピングを実行することも可能である。これによって、新しいサーバおよびネットワーク稼動情報に基づくマッピングが実施され、より最適なマッピングが可能となる。この場合、データ転送装置７０２（３）は、マッピング結果１６０３をデータ転送装置７０２（１）へ送る必要がない。

なお、本実施形態では、データ転送装置７０２（２）は、さらに他のデータ転送装置７０２にサービス要求パケットを送信する必要がない。このため、データ転送装置７０２（２）自身がリソースマッピングを行う必要はないし、データ転送装置７０２（１）がデータ転送装置７０２（３）から受信したマッピング結果をさらにデータ転送装置７０２（２）に送信する必要もない。しかし、データ転送装置７０２（２）が他のデータ転送装置７０２にサービス要求パケットを送信する必要がある場合には、自身でマッピングを行うか、または、上記と同様にデータ転送装置７０２（１）からマッピング結果を受信し、いずれかのマッピング結果に基づいてパケットの送信先を決定する。

図１７にデータ転送装置７０２のアドレス変換部１４０が実行するアドレス変換処理を説明するフローチャートを示す。

まず、処理は開始状態２００１からステップ２００２に進む。ステップ２００２においてアドレス変換部１４０はパケットを受信し、ステップ２００３に進む。ステップ２００３においてアドレス変換部１４０は、パケットを解析する。具体的には、アドレス変換部１４０は、受信したパケットの送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号、プロトコル番号、およびＴＣＰフラグ等を識別する。一つのポート番号を複数のアプリケーションが使用している可能性があるため、アドレス変換部１４０は、さらにパケットのペイロード部分のデータを解析することで、同じポート番号を使用しているアプリケーションを区別してもよい。

次に、アドレス変換部１４０は、ステップ２００４において、セッションＤＢ１３１のセッションエントリを参照し、ステップ２００５に進む。セッションデータベース１３１の参照については後述する（図１８参照）。ステップ２００５においてアドレス変換部１４０は、参照したセッションエントリが新規セッションであるか否かを判定する。ステップ２００３において識別された情報に対応するエントリがセッションＤＢ１３１に登録されていなければ、参照したセッションエントリが新規セッションであると判定される。判定の結果がＹＥＳ（すなわち新規セッションである）場合はステップ２００６に、ＮＯ（すなわち新規セッションでない）場合はステップ２００７に進む。

ステップ２００６においてアドレス変換部１４０は、セッションエントリを作成し、ステップ２００７に進む。セッションエントリの作成については後述する（図１９参照）。ステップ２００７においてアドレス変換部１４０は、ＮＡＰＴを適用する。これによって、パケットの送信先ＩＰアドレスおよび送信先ポート番号が、参照されたセッションエントリのサービスＩＰアドレス９０８およびサービスポート９０９の値に書き換えられる。

次に、ステップ２００８においてアドレス変換部１４０は、セッションエントリの接続状態とタイムスタンプを現在の時刻に更新して、ステップ２００９に進む。セッションエントリの接続状態の更新は、図２３または図２４の状態遷移図に従う。ステップ２００９においてアドレス変換部１４０は、パケットをネットワークに送信して、終了状態２０１０に進む。

図１８にデータ転送装置７０２のセッション管理部１４２が実行するセッションＤＢ参照処理を説明するフローチャートを示す。

まず、処理は初期状態２１０１からステップ２１０２に進む。ステップ２１０２においてセッション管理部１４２は、受信パケットの送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号、およびプロトコル番号からハッシュ値を計算し、ステップ２１０３に進む。ハッシュ値の計算方法は、すべての値を排他的論理和演算するなどの方法が考えられる。ハッシュ値が均等にばらつく方法であれば別の方法を使用してもよい。

ステップ２１０３においてセッション管理部１４２は、計算したハッシュ値をアドレスとしてセッションテーブル（例えば図９Ａの表９２０）のエントリを読み出し、エントリの登録フラグ（例えば登録フラグ９０１）を確認する。ハッシュ値がアドレス空間のサイズより大きい場合は、上位のビットを捨てる等の処理によって有効なアドレス空間に収まるようにする。ステップ２１０３がＹＥＳの場合、すなわちエントリが登録されている場合は、ステップ２１０４に進み、ＮＯの場合、ステップ２１０５に進む。

ステップ２１０４においてセッション管理部１４２は、登録されているエントリの一致を確認する。本実施形態では、受信したパケットの送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号、およびプロトコル番号が、エントリの対応する項目すべてに一致するか否かを判定する。エントリの一致確認の結果がＹＥＳ（すなわち一致する）の場合、参照されたエントリが、受信したパケットに対応するものであるため、終了状態２１０９へ進む。一方、エントリの一致確認の結果がＮＯの場合、ステップ２１０６に進む。

ステップ２１０５においてセッション管理部１４２は、エントリが登録されていない空きエントリメモリアドレスを作業用メモリに記録して終了状態２１０９に進む。

ステップ２１０６においてセッション管理部１４２は、既に実行されたハッシュ回数が、予め設定されたハッシュ試行回数を超えているか否かを判定する。ＹＥＳ（すなわち超えている）の場合は、ステップ２１０７に進み、ＮＯの場合はステップ２１０８に進む。許可する再ハッシュの回数が多ければ、ハッシュが衝突しても登録できる可能性が高くなるが、登録・参照時間が長くなる。

ステップ２１０７においてセッション管理部１４２は、空きエントリが無いことを作業用メモリに記録して終了状態２１０９に進む。

ステップ２１０８においてセッション管理部１４２は、再ハッシュ計算を実行して、ステップ２１０３に進む。再ハッシュの計算は、例えば、元のハッシュ値に、再ハッシュの試行回数の二乗を加算するなどの方法がある。再ハッシュの計算は、公知または周知の技術を適用すればよい。

図１９にデータ転送装置７０２のセッション管理部１４２が実行するセッション作成処理を説明するフローチャートを示す。

まず、処理は初期状態２２０１からステップ２２０２に進む。ステップ２２０２においてセッション管理部１４２は、作業用メモリに保存されている空きエントリの有無を確認する。確認の結果がＹＥＳ（すなわち空きエントリが有る）である場合は、ステップ２２０３に進み、ＮＯ（すなわち空きエントリが無い）である場合は、ステップ２２０４に進む。

ステップ２２０３においてセッション管理部１４２はリソースマッピングを実行し、ステップ２２０５に進む。リソースマッピングについては後述する（図２０〜図２２参照）。ステップ２２０５においてセッション管理部１４２は、空きエントリアドレスに、セッション情報を登録し、終了状態２２０６に進む。

ステップ２２０４においてセッション管理部１４２は、エラー処理を実施してから終了状態２２０６に進む。エラー処理の方法としては、送信元へコネクション拒否のパケットを返信したり、エラーページへのリダイレクトを表示したりする方法が考えられる。

図２０、図２１および図２２を用いてリソースマッピングについて説明する。アプリケーショングラフを、サービスを実際に提供するデータ転送装置７０２またはサーバ７０３に割り当てることをリソースマッピングと呼ぶ。本実施形態では、データ転送装置７０２がサーバ７０３への要求を代理で受け付けるため、リソースマッピングは、アプリケーションの実行を要求するパケットの送信先のデータ転送装置７０２を選択することを意味する。

本実施形態では、応答時間を短縮するように、アプリケーションを実行するサーバ群を選択する。しかし、応答時間は、処理を最適化するための指標の一例に過ぎない。応答時間以外の指標を用いた最適化の例として、例えば、消費電力が最小になるようにサーバ群を選択すること、ＣＰＵ負荷が平準化されるように（あるいは特定のサーバ群に偏るように）サーバ群を選択すること、またはネットワーク使用帯域が平準化されるようにサーバ群を選択すること、等も考えられる。また、リソースマッピングのアルゴリズムも本実施形態に限定されるものではなく、最適化の精度を落としてマッピング時間を短くするアルゴリズム、または厳密な最適化を求めるアルゴリズムなども考えられる。

図２０にデータ転送装置７０２のマッピング計算部１４６が実行するリソースマッピング処理を説明するフローチャートを示す。

まず、処理は初期状態２３０１からステップ２３０２に進む。ステップ２３０２においてマッピング計算部１４６は、受信したパケットの送信先ＩＰアドレスおよび送信先ポート番号からアプリケーションを判別し、それに該当するアプリケーショングラフをアプリケーショングラフデータベースから読み出し、ステップ２３０３に進む。

ステップ２３０２を実行することによって、受信したパケットによって要求されたサービスを提供するために必要なアプリケーションの依存関係が特定される。言い換えると、これによって、受信したパケットによって要求されたサービスを提供するために実行する必要がある全てのサービスプログラムが特定される。例えば、サービス（MacNegatives）の提供を要求された場合、それを提供するために、サービスプログラム（MacNegatives）だけでなく、サービスプログラム（Mac）及びサービスプログラム（Add）も実行する必要があることが特定される（図２参照）。

本実施形態では、受信したパケットの送信先ＩＰアドレス及び送信先ポート番号に基づいてアプリケーションを判別しているが、パケット解析部１４１が、受信したパケットのペイロード内容を判断してアプリケーションを判別することも考えられる。ペイロード内容の解析に基づく方法によって、ポート番号が同一の複数のアプリケーションを区別することができる。

ステップ２３０３においてマッピング計算部１４６は、アプリケーションを実行可能なサーバ群の情報をサービスノードＤＢから読み出し、ステップ２３０４に進む。ステップ２３０３を実行することによって、ステップ２３０２で特定されたそれぞれのアプリケーションを実行可能な一つ以上のサーバが特定される。すなわち、これによって、ステップ２３０２で特定された全てのアプリケーションを実行するためにサービス要求パケットの送信先として指定できるサービスノードの複数の組み合わせ（例えば、図１２Ａ〜図１２Ｃを参照して説明した４通りの組み合わせ）を特定できる。

ステップ２３０４においてマッピング計算部１４６は、アプリケーショングラフをリスト構造に変換したアプリケーションノードリストを用意し、ステップ２３０５に進む。

ステップ２３０５においてマッピング計算部１４６は、サービスノードリストを格納する配列nodes[]を確保し、ステップ２３０６に進む。

ステップ２３０６においてマッピング計算部１４６は、変数min_delayに無限時間を示す十分大きな数値を設定し、ステップ２３０７に進む。十分大きな数値は、例えば３６５日等、アプリケーション全体の処理が終了すると期待される時間より１桁以上大きければよい。

ステップ２３０７においてマッピング計算部１４６は、マップ処理を行い終了状態２３０８へ進む。マップ処理については後述する。

図２１にデータ転送装置７０２のマッピング計算部１４６が実行するマップ処理を説明するフローチャートを示す。

マップ処理は再帰的処理であり、引数としてアプリケーションノードリストのインデックスを示す自然数ｎを取る。まず、初期状態２４０１からステップ２４０２に進む。ステップ２４０２においてマッピング計算部１４６は、引数ｎがアプリケーションノードリストのサイズより大きいか否かを確認し、ＹＥＳ（すなわち大きい）の場合はステップ２４０４に、ＮＯの場合はステップ２４０３に進む。

ステップ２４０３からステップ２４０７は、アプリケーションノードリストのｎ番目のサービスを提供できるすべてのサービスノード候補に対する繰り返し処理である。ステップ２４０５においてマッピング計算部１４６は、サービスノードリストの配列nodes[]に、現在対象とするｉ番目のサービスノードを登録し、ステップ２４０６に進む。ステップ２４０６においてマッピング計算部１４６は、マップ処理を呼び出す。このとき、引数としてｎ＋１を渡す。ステップ２４０３からステップ２４０７をサービスノード数分繰り返した後、終了状態２４１２に進む。

ステップ２４０４においてマッピング計算部１４６は、アプリケーショングラフの全ノードを“未訪問”状態に初期化し、ステップ２４０８に進む。これはグラフのノードを２度以上訪問しないようにするためである。ステップ２４０８においてマッピング計算部１４６は、アプリケーショングラフの根ノードを引数として、遅延計算処理を呼び出して、得られた遅延時間を変数ｖに格納し、ステップ２４０９に進む。根ノードは、サービス要求元のノードに相当する。遅延計算処理については後述する。ステップ２４０９においてマッピング計算部１４６は、変数ｖの値が変数min_delayの値より小さいか確認し、ＹＥＳの場合ステップ２４１０に、ＮＯの場合、終了状態２４１２に進む。

ステップ２４１０においてマッピング計算部１４６は、変数min_delayに変数vの値を格納しステップ２４１１に進む。ステップ２４１１においてマッピング計算部１４６は、マップされた結果であるサービスノード配列nodes[]を別の領域に保存し、終了状態２４１２に進む。

図２２にデータ転送装置７０２のマッピング計算部１４６が実行する遅延計算処理を説明するフローチャートを示す。

遅延計算処理は再帰的処理であり、引数としてノードｋを取る。まず、初期状態２５０１からステップ２５０２に進む。ステップ２５０２においてマッピング計算部１４６は、ノードｋを“訪問済み”に設定して、ステップ２５０３に進む。ステップ２５０３においてマッピング計算部１４６は、遅延時間の最大値を格納する変数max_path_delayを０に初期化して、ステップ２５０４に進む。

ステップ２５０４からステップ２５０９は、ノードｋの隣接ノードのうち、“未訪問”状態のすべてのノードに対する繰り返し処理である。ステップ２５０５においてマッピング計算部１４６は、ｉ番目の隣接ノードを引数として、遅延計算処理を呼び出し、結果を変数delayに格納して、ステップ２５０６に進む。ステップ２５０６においてマッピング計算部１４６は、ノードｋからｉ番目の隣接ノードへの通信遅延を、サービスノードＤＢから取得して変数edge_delayに格納し、ステップ２５０７に進む。ステップ２５０７においてマッピング計算部１４６は、変数edge_delayと変数delayの合計が変数max_path_delayより大きいか確認し、ＹＥＳの場合、ステップ２５０８に、ＮＯの場合、ステップ２５０９に進む。

ステップ２５０８においてマッピング計算部１４６は、変数edge_delayと変数delayの合計を変数max_path_delayに代入してステップ２５０９に進む。ステップ２５０４からステップ２５０９の繰り返しが終了したら、マッピング計算部１４６の処理はステップ２５１０に進む。ステップ２５１０においてマッピング計算部１４６は、ノードｋ自身の処理遅延を変数max_path_delayに加算して、終了状態２５１１に進む。処理遅延は、サービスが必要としているＣＰＵ処理時間／サーバが提供できる毎秒ＣＰＵ処理速度を計算することによって求められる。本遅延計算処理は、戻り値として変数max_path_delayの値を返す。

図２０〜図２２のリソースマッピングによって取得された最終的なマップ結果は、マップ結果ＤＢ１３４に格納され（図１２Ａ〜図１２Ｃ参照）、さらに、マップ結果として取得されたＩＰアドレスがサービスＩＰアドレス９０８としてセッションＤＢ１３１に格納される（図９Ａ〜図９Ｃ参照）。

図２０〜図２２の処理の結果、図１２Ａを参照して説明したように、要求されたサービスを提供するために使用されるサービスノードの複数の組み合わせのうち、応答遅延時間が最小になる組み合わせが選択される。しかし、応答遅延時間は、リソースマッピングによって処理を最適化するために使用される指標の一例であり、他の指標が使用されてもよい。他の指標としては、例えば、消費電力またはサービスノードの負荷が挙げられる。

ここで、消費電力に基づくリソースマッピングについて説明する。この場合、例えば、サービスノードＤＢ１３２のサービスノード稼動情報表１０２１が、各サービスノードにおける単位ＣＰＵ処理時間当たりの消費電力を示す情報をさらに含む。そして、図２１のステップ２４０８において、遅延計算の代わりに消費電力が計算される。各サービスノードの消費電力は、各サービスノードにおいて実行されるサービスプログラムを実行するためのＣＰＵ処理時間（図４〜図６参照）に、ＣＰＵ負荷（図１０Ｂ、図１０Ｅ及び図１０Ｈ参照）及び単位ＣＰＵ処理時間当たりの消費電力を乗じることによって算出される。

例えば、ＩＰアドレス「10.0.1.1」が示すサービスノードにおける消費電力は、図５の行５０１が示す「１５０ｍｓ」に図１０Ｂのエントリ１０１１が示す「２」を乗じた値「３００ｍｓ」にさらに単位ＣＰＵ処理時間当たりの消費電力を乗じることによって算出される。

上記の処理によって、消費電力が最小になるサービスノードの組み合わせが特定される。

次に、負荷に基づくリソースマッピングについて説明する。負荷に基づく処理の最適化にはいくつかの考え方があり、その代表的な例は負荷の平坦化及び負荷の片寄せである。負荷の平坦化は、負荷の集中による処理性能の低下を回避するために行われる。一方、負荷の片寄せは、負荷を意図的に偏在させ、負荷がゼロになった（すなわち処理を行っていない）サービスノードの電源を遮断することによって、システム全体としての消費電力を削減すること等を目的として行われる。

最初に、負荷の平坦化のためのリソースマッピングについて説明する。この場合、例えば図２０のステップ２３０７において、サービスノードＤＢ１３２のＣＰＵ負荷が参照され、各サービスプログラムを実行するサービスノードのうち、ＣＰＵ負荷が最も小さいものの組み合わせが特定される。

次に、負荷の片寄せのためのリソースマッピングについて説明する。負荷を片寄せする単純な方法は、例えば図２０のステップ２３０７において、サービスノードＤＢ１３２のＣＰＵ負荷を参照し、各サービスプログラムを実行するサービスノードのうち、ＣＰＵ負荷が最も大きいものの組み合わせを特定する、というものである。

ただし、既に負荷がゼロになっているサービスノードが存在する場合には、そのサービスノードを含まない組み合わせを選択することが望ましい。また、負荷が大きいサービスノードを選択した場合、そのサービスノードにおいてさらに要求されたサービスプログラムを実行することによってそのサービスノードのＣＰＵ負荷が１００％に達する可能性がある。これによるサービスノードの処理性能の低下を避けるために、要求されたサービスプログラムを実行した場合のＣＰＵ負荷の上限（例えば１００％）を設定し、その上限を超えないサービスノードの組み合わせを特定してもよい。

すなわち、負荷を片寄せする場合は、サービスノードの複数の組み合わせから、負荷がゼロであるサービスノードを含まず、かつ、要求されたサービスプログラムを実行した場合に負荷の上限を超えるサービスノードを含まない組み合わせを特定し、さらにその中で、負荷が最も大きいサービスノードの組み合わせを特定することが望ましい。なお、上記のようにＣＰＵ負荷の上限としてＣＰＵ使用率の値（例えば１００％）が設定される場合には、サービスノードＤＢ１３２のＣＰＵ負荷としてＣＰＵ使用率（％）が保持されている必要がある。

図２３に、データ転送装置のセッションＤＢの接続状態（ＴＣＰ使用時）を決める状態遷移図を示す。

初期状態３００１（ＣＬＯＳＥＤ）は未接続を示す。初期状態３００１で、ＳＹＮフラグが設定されたパケットを接続元から受信すると状態３００２（ＳＹＮ＿ＲＣＶ１）に遷移する。状態３００２で、ＳＹＮ−ＡＣＫフラグが設定されたパケットを接続先から受信すると状態３００３（ＳＹＮ＿ＲＣＶ２）に遷移する。状態３００３で、ＡＣＫフラグが設定されたパケットを接続元から受信すると状態３００４（ＯＰＥＮ）に遷移する。図９Ａの接続状態９１０の値「ＯＰＥＮ」は、セッションの状態が状態３００４または後述する状態３１０２であることを意味する。

状態３００４は接続が確立した状態である。状態３００４で、ＦＩＮフラグが設定されたパケットを接続元または接続先のいずれかから受信すると状態３００５（ＦＩＮ＿ＷＡＩＴ）に遷移する。状態３００５において、ＦＩＮフラグが設定された先ほどのパケットの送信先から、ＦＩＮ−ＡＣＫフラグが設定されたパケットを受信すると状態３００６（ＣＬＯＳＥ＿ＷＡＩＴ）に遷移する。なお、ＦＩＮ−ＡＣＫフラグをＦＩＮフラグとＡＣＫフラグの２回に分けても同じ意味である。状態３００６で、最後に受信したＦＩＮに対するＡＣＫを受信すると状態３００７（ＴＩＭＥＯＵＴ）に遷移する。

これらはＴＣＰ通信の接続および切断の通常の遷移に基づいている。状態３００７では、一定時間経過した後、初期状態３００１に遷移する。タイムアウトまでの時間は、ＮＡＴ装置における公知または周知の技術に準拠することができる。

図２４にデータ転送装置のセッションＤＢの接続状態（ＵＤＰ使用時）を決める状態遷移図を示す。

ＵＤＰのようなコネクションレス通信の場合、セッションがいつまで続いているか厳密に判断できないため、通信が一定時間なければセッションが一度終了したものと見なす。初期状態３１０１（ＣＬＯＳＥＤ）は未接続を示す。初期状態３１０１から、パケットを受信すると状態３１０２（ＯＰＥＮ）に遷移する。この際、最初に受信したパケットの送信元を接続元、送信先を接続先とする。

状態３１０２は接続が確立したことを示す。状態３１０２では、パケットを受信するたびにタイマーをセットし、一定時間パケットの受信が、接続元、接続先双方から無ければ、状態３１０１に遷移する。

以上に説明した実施形態のリソースマッピングによれば、広域網１０２を介して互いに接続される管理装置１０１、データ転送装置１０３、ユーザ端末１０４、およびＬＡＮ１０７によってデータ転送装置１０３と接続されるサーバ１０５およびＤＮＳ１０６から構成される分散処理システムにおいて、多段に接続されたサービスプログラムによって構成される分散アプリケーションを実行する際、データ転送装置１０３は、隣接するサービスノードの稼動情報のみでなく、アプリケーショングラフに基づいて、間接的に利用するサービスノードの稼動情報にも基づいて、隣接するサービスノードをサービスプログラム実行環境とする。これによって、総合的に分散アプリケーションの応答遅延時間を短縮することができる。さらに、応答遅延時間以外の指標を用いてリソースマッピングを行うことによって、省電力化または負荷の平坦化等を実現することもできる。

１０１ 管理装置
１０２、７００ 広域網
１０３、７０２ データ転送装置
１０４、７０１ ユーザ端末
１０５、７０３ サーバ
１０６、７０４ ＤＮＳ
１０７ ＬＡＮ
１２３、１２４ 共有バス
３００、４００、５００、６００ ＸＭＬファイル

Claims (15)

1. ネットワークに接続される複数のデータ転送装置と、前記複数のデータ転送装置に接続される複数のサーバと、を備える分散情報処理システムであって、
   前記データ転送装置は、
   前記ネットワークに接続されるインタフェースと、前記インタフェースに接続されるプロセッサと、を備え、
   前記複数のサーバによって実行される各サービスプログラムと、そのサービスプログラムによるサービスを提供するために使用される別のサービスプログラムとを対応付ける第１情報を保持し、
   前記各サービスプログラムを実行するために要するリソース量を示す第２情報を保持し、
   前記各サービスプログラムの実行を要求するサービス要求パケットの送信先として指定できる前記サーバ及び前記データ転送装置の一つ以上のアドレスを示す第３情報を保持し、
   前記複数のサーバ及び前記ネットワークの少なくとも一方の状態を示す第４情報を保持し、
   前記サービス要求パケットを受信すると、前記第１情報に基づいて、受信した前記サービス要求パケットによって要求されたサービスを提供するために実行する必要がある第１サービスプログラムと、前記第１サービスプログラムによるサービスを提供するために使用される別のサービスプログラムである第２サービスプログラムと、を含む、前記受信したサービス要求パケットによって要求されたサービスを提供するために実行する必要がある全てのサービスプログラムを特定し、
   前記第３情報に基づいて、前記特定された全てのサービスプログラムの各々について、そのサービスプログラムの実行を要求するサービス要求パケットの送信先として指定できる一つ以上のアドレスを特定し、前記特定されたアドレスに基づいて、前記特定された全てのサービスプログラムの実行を要求するサービス要求パケットの送信先の複数の組み合わせを特定し、
   前記第２情報及び前記第４情報に基づいて、前記特定された複数の組み合わせのうち、処理が最適化される組み合わせを選択し、
   前記受信したサービス要求パケットの送信先を前記選択された組み合わせに含まれる送信先のアドレスに書き換えて、当該サービス要求パケットを送信することを特徴とする分散情報処理システム。
2. 前記第２情報は、前記リソース量として、前記各サービスプログラムを実行するために要する処理時間を含み、
   前記第４情報は、前記複数のサーバの負荷を示す情報、及び、前記第３情報に含まれるアドレスが示す前記送信先の間で前記サービス要求パケットを通信するために要する遅延時間を示す情報を含み、
   前記データ転送装置は、前記特定された複数の組み合わせのうち、前記第２情報及び前記第４情報に基づいて計算される応答遅延時間が最小になる前記送信先の組み合わせを、前記処理が最適化される組み合わせとして選択することを特徴とする請求項１に記載の分散情報処理システム。
3. 前記データ転送装置は、
   前記第１情報及び前記第３情報に基づいて、前記データ転送装置に接続された前記サーバによって実行される前記サービスプログラムを特定し、前記特定されたサービスプログラムによるサービスを提供するために実行する必要がある全てのサービスプログラムを特定し、前記特定された全てのサービスプログラムの各々について、その実行を要求するサービス要求パケットの一つ以上の送信先を特定し、前記特定された送信先に前記サーバの負荷を示す情報の送信要求を送信し、
   前記送信要求の送信先から受信した前記サーバの負荷を示す情報を前記第４情報として保持することを特徴とする請求項２に記載の分散情報処理システム。
4. 前記データ転送装置は、前記送信要求を受信すると、前記データ転送装置に接続された前記サーバから、当該サーバの負荷を示す情報を繰り返し取得し、前記取得した情報を前記送信要求の送信元に繰り返し送信することを特徴とする請求項３に記載の分散情報処理システム。
5. 前記第２情報は、前記リソース量として、前記各サービスプログラムを実行するために要する処理時間を含み、
   前記第４情報は、前記複数のサーバの負荷を示す情報、及び、前記複数のサーバの消費電力を示す情報を含み、
   前記データ転送装置は、前記特定された複数の組み合わせのうち、前記第２情報及び前記第４情報に基づいて計算される消費電力が最小になる前記送信先の組み合わせを、前記処理が最適化される組み合わせとして選択することを特徴とする請求項１に記載の分散情報処理システム。
6. 前記第２情報は、前記リソース量として、前記各サービスプログラムを実行するために要する処理時間を含み、
   前記第４情報は、前記複数のサーバの負荷を示す情報を含み、
   前記データ転送装置は、前記特定された複数の組み合わせのうち、前記第４情報が示す負荷が最も低い前記送信先の組み合わせを、前記処理が最適化される組み合わせとして選択することを特徴とする請求項１に記載の分散情報処理システム。
7. 前記第２情報は、前記リソース量として、前記各サービスプログラムを実行するために要する処理時間を含み、
   前記第４情報は、前記複数のサーバの負荷を示す情報を含み、
   前記データ転送装置は、前記特定された複数の組み合わせのうち、前記第４情報が示す負荷がゼロである前記送信先を含まず、前記要求されたサービスを提供するための前記サービスプログラムを実行した場合の負荷が所定の上限を超えず、かつ、前記第４情報が示す負荷が最も高い前記送信先の組み合わせを、前記処理が最適化される組み合わせとして選択することを特徴とする請求項１に記載の分散情報処理システム。
8. 前記分散情報処理システムは、前記ネットワークに接続された管理装置をさらに備え、
   前記管理装置は、前記第１情報及び前記第２情報を前記データ転送装置に送信し、
   前記データ転送装置は、前記管理装置から受信した前記第１情報及び前記第２情報を保持することを特徴とする請求項１に記載の分散情報処理システム。
9. 前記管理装置は、前記第３情報を前記データ転送装置に送信し、
   前記データ転送装置は、前記管理装置から受信した前記第３情報を保持することを特徴とする請求項８に記載の分散情報処理システム。
10. 分散情報処理システムが実行する分散処理方法であって、
    前記分散情報処理システムは、ネットワークに接続される複数のデータ転送装置と、前記複数のデータ転送装置に接続される複数のサーバと、を備え、
    前記データ転送装置は、
    前記ネットワークに接続されるインタフェースと、前記インタフェースに接続されるプロセッサと、を備え、
    前記複数のサーバによって実行される各サービスプログラムと、そのサービスプログラムによるサービスを提供するために使用される別のサービスプログラムとを対応付ける第１情報を保持し、
    前記各サービスプログラムを実行するために要するリソース量を示す第２情報を保持し、
    前記各サービスプログラムの実行を要求するサービス要求パケットの送信先として指定できる前記サーバ及び前記データ転送装置の一つ以上のアドレスを示す第３情報を保持し、
    前記複数のサーバ及び前記ネットワークの少なくとも一方の状態を示す第４情報を保持し、
    前記分散情報処理方法は、
    前記データ転送装置が、前記サービス要求パケットを受信すると、前記第１情報に基づいて、受信した前記サービス要求パケットによって要求されたサービスを提供するために実行する必要がある第１サービスプログラムと、前記第１サービスプログラムによるサービスを提供するために使用される別のサービスプログラムである第２サービスプログラムと、を含む、前記受信したサービス要求パケットによって要求されたサービスを提供するために実行する必要がある全てのサービスプログラムを特定する第１手順と、
    前記データ転送装置が、前記第３情報に基づいて、前記特定された全てのサービスプログラムの各々について、そのサービスプログラムの実行を要求するサービス要求パケットの送信先として指定できる一つ以上のアドレスを特定し、前記特定されたアドレスに基づいて、前記特定された全てのサービスプログラムの実行を要求するサービス要求パケットの送信先の複数の組み合わせを特定する第２手順と、
    前記データ転送装置が、前記第２情報及び前記第４情報に基づいて、前記特定された複数の組み合わせのうち、処理が最適化される組み合わせを選択する第３手順と、
    前記データ転送装置が、前記受信したサービス要求パケットの送信先を前記選択された組み合わせに含まれる送信先のアドレスに書き換えて、当該サービス要求パケットを送信する第４手順と、を含むことを特徴とする分散情報処理方法。
11. 前記第２情報は、前記リソース量として、前記各サービスプログラムを実行するために要する処理時間を含み、
    前記第４情報は、前記複数のサーバの負荷を示す情報、及び、前記第３情報に含まれるアドレスが示す前記送信先の間で前記サービス要求パケットを通信するために要する遅延時間を示す情報を含み、
    前記第３手順は、前記データ転送装置が、前記特定された複数の組み合わせのうち、前記第２情報及び前記第４情報に基づいて計算される応答遅延時間が最小になる前記送信先の組み合わせを、前記処理が最適化される組み合わせとして選択する手順を含むことを特徴とする請求項１０に記載の分散情報処理方法。
12. 前記分散情報処理方法は、さらに、
    前記データ転送装置が、前記第１情報及び前記第３情報に基づいて、前記データ転送装置に接続された前記サーバによって実行される前記サービスプログラムを特定し、前記特定されたサービスプログラムによるサービスを提供するために実行する必要がある全てのサービスプログラムを特定し、前記特定された全てのサービスプログラムの各々について、その実行を要求するサービス要求パケットの一つ以上の送信先を特定し、前記特定された送信先に前記サーバの負荷を示す情報の送信要求を送信する手順と、
    前記送信要求を受信した前記データ転送装置が、前記データ転送装置に接続された前記サーバから、当該サーバの負荷を示す情報を繰り返し取得し、前記取得した情報を前記送信要求の送信元に繰り返し送信する手順と、
    前記データ転送装置が、前記送信要求の送信先から受信した前記サーバの負荷を示す情報を前記第４情報として保持する手順と、を含むことを特徴とする請求項１１に記載の分散情報処理方法。
13. ネットワーク及び一つ以上のサーバに接続されるデータ転送装置であって、
    前記ネットワークには、複数の他のデータ転送装置が接続され、
    前記複数の他のデータ転送装置の各々には、一つ以上のサーバが接続され、
    前記データ転送装置は、
    前記ネットワークに接続されるインタフェースと、前記インタフェースに接続されるプロセッサと、を備え、
    前記複数のサーバによって実行される各サービスプログラムと、そのサービスプログラムによるサービスを提供するために使用される別のサービスプログラムとを対応付ける第１情報を保持し、
    前記各サービスプログラムを実行するために要するリソース量を示す第２情報を保持し、
    前記各サービスプログラムの実行を要求するサービス要求パケットの送信先として指定できる前記サーバ及び前記他のデータ転送装置の一つ以上のアドレスを示す第３情報を保持し、
    前記複数のサーバ及び前記ネットワークの少なくとも一方の状態を示す第４情報を保持し、
    前記サービス要求パケットを受信すると、前記第１情報に基づいて、受信した前記サービス要求パケットによって要求されたサービスを提供するために実行する必要がある第１サービスプログラムと、前記第１サービスプログラムによるサービスを提供するために使用される別のサービスプログラムである第２サービスプログラムと、を含む、前記受信したサービス要求パケットによって要求されたサービスを提供するために実行する必要がある全てのサービスプログラムを特定し、
    前記第３情報に基づいて、前記特定された全てのサービスプログラムの各々について、そのサービスプログラムの実行を要求するサービス要求パケットの送信先として指定できる一つ以上のアドレスを特定し、前記特定されたアドレスに基づいて、前記特定された全てのサービスプログラムの実行を要求するサービス要求パケットの送信先の複数の組み合わせを特定し、
    前記第２情報及び前記第４情報に基づいて、前記特定された複数の組み合わせのうち、処理が最適化される組み合わせを選択し、
    前記受信したサービス要求パケットの送信先を前記選択された組み合わせに含まれる送信先のアドレスに書き換えて、当該サービス要求パケットを送信することを特徴とするデータ転送装置。
14. 前記第２情報は、前記リソース量として、前記各サービスプログラムを実行するために要する処理時間を含み、
    前記第４情報は、前記複数のサーバの負荷を示す情報、及び、前記第３情報に含まれるアドレスが示す前記送信先の間で前記サービス要求パケットを通信するために要する遅延時間を示す情報を含み、
    前記データ転送装置は、前記特定された複数の組み合わせのうち、前記第２情報及び前記第４情報に基づいて計算される応答遅延時間が最小になる前記送信先の組み合わせを、前記処理が最適化される組み合わせとして選択することを特徴とする請求項１３に記載のデータ転送装置。
15. 前記データ転送装置は、
    前記第１情報及び前記第３情報に基づいて、前記データ転送装置に接続された前記サーバによって実行される前記サービスプログラムを特定し、前記特定されたサービスプログラムによるサービスを提供するために実行する必要がある全てのサービスプログラムを特定し、前記特定された全てのサービスプログラムの各々について、その実行を要求するサービス要求パケットの一つ以上の送信先を特定し、前記特定された送信先に前記サーバの負荷を示す情報の送信要求を送信し、
    前記送信要求を受信すると、前記データ転送装置に接続された前記サーバから、当該サーバの負荷を示す情報を繰り返し取得し、前記取得した情報を前記送信要求の送信元に繰り返し送信し、
    前記送信要求の送信先から前記サーバの負荷を示す情報を受信すると、受信した前記サーバの負荷を示す情報を前記第４情報として保持することを特徴とする請求項１４に記載のデータ転送装置。

Images