WO2017200037A1

WO2017200037A1 - 処理システムおよびそのプログラム

Info

Publication number: WO2017200037A1
Application number: PCT/JP2017/018651
Authority: WO
Inventors: 芳樹松浦; 辰彦宮田; 潤吉原; 哲朗安部
Original assignee: 株式会社日立製作所
Priority date: 2016-05-20
Filing date: 2017-05-18
Publication date: 2017-11-23
Also published as: US20200319946A1; JPWO2017200037A1; EP3460661A4; US11340969B2; EP3460661A1; JP6668465B2

Abstract

データ振り分け装置と複数の処理サーバから構成される処理システムであって、前記データ振り分け装置はデータを複数の前記処理サーバのいずれかに転送し、前記処理サーバは、複数の前記処理サーバそれぞれの負荷情報が格納されたサーバ判定情報記憶部と、アプリケーションに固有の転送する条件が格納されたアプリ別転送判定情報記憶部と、を有し、アプリケーションが特定される情報を含むデータを受信したと判定するとメッセージを生成し、メッセージを受信したと判定するとアプリケーションを特定し、前記サーバ判定情報記憶部と前記アプリ別転送判定情報記憶部に格納された情報に基づいて処理サーバを選定し、選定された処理サーバに応じて、アプリケーションを実行するか、選定された処理サーバにメッセージを転送する。

Description

処理システムおよびそのプログラム

　本発明は、処理システムおよびそのプログラムに関するものである。

　近年、クラウド等の潤沢なコンピューティング環境を利用し、デバイスなどのクライアント端末から送信されるデータを活用するアプリケーションにおいて、大量かつ多様なデータを適切なアプリケーションに振り分けながら負荷分散を行える高性能な処理システムが望まれている。

　このような分野の背景技術として、特許文献１では、アプリケーションごとに負荷分散装置を用意して、負荷分散装置配下にアプリケーションのデータ処理を実行する処理サーバを複数配置して、負荷分散を行うことが記載されている（図１）。

　さらに、特許文献１では、１台の処理サーバに複数のアプリケーションが配置されており、アプリケーションに関する負荷データや性能データに応じて複数のアプリケーション間で資源割り当てを動的に行うことで、ピーク負荷期間の異なるアプリケーション間でコンピュータリソースを有効に活用することができることが記載されている（段落０００４、００２５）。

特開２００８－２３４６５１号公報

　特許文献１に記載された負荷分散システムを用いれば、アプリケーションに割り当てられたデータを、複数の処理サーバにより、効率的に負荷分散することができる。しかしながら、クライアント端末から送信される多様なデータを適切なアプリケーションの負荷分散装置に振り分ける際に、アプリケーションに応じて異なるプロトコルの解析が必要となる場合もあり、データ振り分け処理の負荷も無視することができない。

　すなわち、このような場合は、データを負荷分散装置に振り分けるための、受信データのレイヤ７レベルのプロトコルを解析して、アプリケーションを特定し、特定されたアプリケーションに応じた負荷分散装置に振り分ける、という一連のデータ振り分け処理の負荷が大きくなる。

　そして、このデータ振り分け処理を行う装置（たとえば、レイヤ７レベルの処理が可能なロードバランサなど）がボトルネックとなり、処理サーバの台数が多くても、大量のデータをそもそも処理できなくなってしまう。

　なお、レイヤ７レベルのプロトコルの種類には、たとえば、ＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ　Ｓｔａｔｅ　Ｔｒａｎｓｆｅｒ）やＭＱＴＴ（ＭＱ　Ｔｅｌｅｍｅｔｒｙ　Ｔｒａｎｓｐｏｒｔ）などがある。

　これに対して、特許文献１では、クラスタエイリアシングにより負荷分散装置にルーティングすることは記載されているが（段落００１５）、プロトコル解析やアプリケーション特定処理に関する技術の開示は見当たらない。

　また、データ振り分け処理を行う装置のボトルネックを解消するために、データ振り分け処理を行う装置の前段に、レイヤ４レベルのプロトコル解析で複数のデータ振り分け処理を行う装置にデータを振り分けるロードバランサを配置することも考えられるが、装置の台数を増加させることとなり、コスト増につながる。

　本発明は、上記課題に鑑みてなされたものであり、データの処理の分散に加えて、処理サーバがデータ振り分け処理の負荷も分散できる負荷分散処理システムを提供することを目的とする。

　上記目的を達成するために、本発明に係る代表的な処理システムは、データ振り分け装置と複数の処理サーバから構成される処理システムであって、前記データ振り分け装置は、アプリケーションプログラムが特定される情報を含むデータを受信し、受信されたデータもしくは受信されたデータから生成されたメッセージを、複数の前記処理サーバのいずれかに転送し、前記処理サーバは、複数の前記処理サーバそれぞれのアプリケーションプログラムの登録情報と、複数の前記処理サーバそれぞれの負荷情報が格納されたサーバ判定情報記憶部と、アプリケーションプログラムに固有の転送する条件が格納されたアプリ別転送判定情報記憶部と、を有し、アプリケーションプログラムが特定される情報を含むデータもしくはメッセージを受信し、受信されたデータもしくはメッセージがデータであると判定すると、受信されたデータからメッセージを生成し、受信されたデータもしくはメッセージがメッセージであると判定すると、受信されたメッセージからアプリケーションプログラムを特定し、前記サーバ判定情報記憶部と前記アプリ別転送判定情報記憶部に格納された情報に基づいて、複数の前記処理サーバの中から処理サーバを選定し、選定された処理サーバが前記処理サーバ自身であると判定すると、特定されたアプリケーションプログラムを実行し、選定された処理サーバが前記処理サーバ自身でないと判定すると、受信されたもしくは生成されたメッセージを、選定された処理サーバに転送することを特徴とする。

　本発明によれば、データの処理の分散に加えて、処理サーバがデータ振り分け処理の負荷も分散できる負荷分散処理システムを提供することが可能となる。

システムの全体構成の例を示す図である。処理サーバの構成の例を示す図である。デプロイアプリ管理サーバの構成の例を示す図である。アプリ-メッセージ管理記憶部のテーブルの例を示す図である。サーバ判定情報記憶部のテーブルの例を示す図である。アプリ別転送判定情報記憶部（キャッシュ）のテーブルの例を示す図である。アプリ別転送判定情報記憶部（ＩＤトラン）のテーブルの例を示す図である。データもしくはメッセージの受信の動作フローの例を示す図である。処理サーバ選定の動作フローの例を示す図である。データ振り分け装置で単純に処理サーバに転送する動作シーケンスの例を示す図である。データ振り分け装置でメッセージを生成までして処理サーバに転送する動作シーケンスの例を示す図である。データ振り分け装置でアプリの登録されている処理サーバを選定までして転送する動作シーケンスの例を示す図である。データ振り分け装置でアプリ別の転送判定処理により処理サーバを選定までして転送する動作シーケンスの例を示す図である。

　以下、各実施例における実施形態について図面を参照して説明する。なお、以下の実施例に用いる図において、同一の符号を付した部分は同一物を表し、それらの構造および動作は同じである。

　図１は、システムの全体構成の例である。このシステムは、複数のクライアント端末１０１（クライアント端末１０１ａ～１０１ｄを特に区別することなく、それらの１つをクライアント端末１０１と代表的に表し、以下、他の符号も同じ表記とする）と、クライアント端末１０１とネットワーク１０２などを介して接続されるデータ振り分け装置１０３、データ振り分け装置１０３と接続される複数の処理サーバ１０４、およびデプロイアプリ管理サーバ１０５から構成される。図１に示したシステムの中で、特にデータ振り分け装置１０３と処理サーバ１０４を、処理システムと呼んでもよい。

　クライアント端末１０１は、アプリケーションの処理を実行するためのデータを生成して送信する端末であり、会社や工場内のデータ管理サーバや、スマートフォンやタブレット端末などの通信デバイス、また近年では、センサデバイス、スマートメータや車などの装置でも通信機能を有するものがあり、そのような通信機能を有する装置である。

　ネットワーク１０２は、通信キャリアなどによって提供される無線ネットワークまたは有線ネットワークである。ネットワーク１０２は、個別の会社などが所有するネットワークを、ネットワーク１０２の一部に含んでもよく、複数種類のプロトコルを通過させるネットワークであってもよい。

　データ振り分け装置１０３は、クライアント端末１０１からデータを受信して、受信したデータを複数の処理サーバ１０４に振り分ける装置である。従来技術（特許文献１）では、ルーティングもしくは負荷分散装置により、アプリケーションごとの負荷分散装置もしくはアプリケーションに対応したクラスタノードにデータを振り分けていた。本実施例では、データ振り分け装置１０３における振り分け処理の負荷を軽減して、１台のデータ振り分け装置１０３でも大量のデータを処理できるようにする。

　データ振り分け装置１０３は、中央処理装置、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）、データ記憶装置、プログラム記憶装置を備えるたとえばコンピュータであってもよい。これらの装置それぞれは、図２を用いて説明する処理サーバ１０４内の装置それぞれと同じ構造であってもよい。また、プログラム記憶装置に格納されたプログラムを実行する中央処理装置の動作一部は、それと同じ動作をする集積回路などのハードウェアであってもよい。

　処理サーバ１０４は、クライアント端末１０１から送信されたデータに対応して、アプリケーションの処理を実行するサーバである。ここで、アプリケーションの処理の実行は、アプリケーションプログラムの実行であり、以下ではアプリケーションプログラムをアプリと略す。

　図１では処理サーバ１０４の論理的な構成の例を示し、処理サーバ１０４は、アプリを実行するために実行プラットフォームとミドルウェアを有する。処理サーバ１０４ごとにアプリが異なってもよく、図１の例では、処理サーバ１０４ａが３つのアプリ（ＡｐｐＡ、ＡｐｐＢ、ＡｐｐＣ）を有し、処理サーバ１０４ｂが２つのアプリ（ＡｐｐＡ、ＡｐｐＣ）を有し、処理サーバ１０４ｃが２つのアプリ（ＡｐｐＡ、ＡｐｐＢ）を有する。処理サーバ１０４の構成については、図２を用いて詳細に説明する。

　デプロイアプリ管理サーバ１０５は、処理サーバ１０４に搭載されているアプリの種類や処理サーバ１０４の負荷情報、アプリの実行に関連する情報などを管理するサーバである。デプロイアプリ管理サーバ１０５の構成については、図３を用いて詳細に説明する。

　ここでは、これらのサーバが別々の物理マシンの例を説明するが、これらのサーバは、同じ物理マシンの別々の仮想マシンであってもよいし、別々の物理マシンの別々の仮想マシンであってもよいし、物理マシンおよび仮想マシンとして混在してもよい。

　図２は、処理サーバ１０４の構成の例である。処理サーバ１０４は、外部と通信する通信Ｉ／Ｆ２１０、永続化する情報が格納されるデータ記憶装置２２０、プログラムが格納されるプログラム記憶装置２３０、データ記憶装置２２０やプログラム記憶装置２３０から必要な情報やプログラムを読み込んで実行する中央処理装置２１１といった、一般的なコンピュータの備える部品がバス接続されて構成される。

　通信Ｉ／Ｆ２１０は、たとえばＥｔｈｅｒｎｅｔ（登録商標）と接続し、他の処理サーバ１０４やデータ振り分け装置１０３と通信するためのインターフェイスである。通信Ｉ／Ｆ２１０は、後で説明する実行プラットフォーム２４０のプログラムにより制御されてもよく、特にレイヤ４レベル以上のプロトコルはプログラムにより処理されてもよい。

　処理サーバ１０４におけるデータ記憶装置２２０は、クライアント端末１０１から送信されたデータに対応したメッセージと、アプリ２６１との関係が格納されるアプリ-メッセージ管理記憶部２２１、各処理サーバ１０４に搭載されているアプリ２６１の情報と処理サーバ１０４の負荷情報が格納されるサーバ判定情報記憶部２２２、アプリ２６１に固有の条件であって処理サーバ１０４間で転送するか否かを判定するための条件がある場合、その情報が格納されるアプリ別転送判定情報記憶部２２３を含む。

　アプリ-メッセージ管理記憶部２２１、サーバ判定情報記憶部２２２、アプリ別転送判定情報記憶部２２３のそれぞれは、データ記憶装置２２０内の異なる記憶領域であってもよい。また、データ記憶装置２２０は、ハードディスクドライブ、ソリッドステートドライブ、フラッシュメモリなどであってもよい。

　ここで、メッセージとは、処理サーバ１０４間でのデータ転送に使用される情報であり、転送される複数のデータの型や種類の組み合わせを識別する情報であってもよいし、転送される複数のデータの変数名の組み合わせを識別する情報であってもよい。このように、メッセージそのものはデータの内容ではなく、どのようなデータが組み合わされているかを表す情報であってもよい。

　また、メッセージは、アプリ２６１に対応する情報であってもよく、アプリ２６１が処理の対象とするデータの項目の組み合わせを表す情報であってもよい。そして、メッセージはメッセージの情報で示されるデータをともなって転送されてもよく、処理サーバ１０４間で固有に定められたプロトコルにしたがって転送される。

　アプリ別転送判定情報記憶部２２３の例として、図２では、アプリ２６１ａ（ＡｐｐＡ）の転送判定処理として各処理サーバ１０４のキャッシュに保持されたデータを利用する際に使用されるＡｐｐＡ転送判定情報記憶部（キャッシュ）２２４ａ、アプリ２６１ｃ（ＡｐｐＣ）の転送判定処理として同一のＩＤを有するトランザクションを同一の処理サーバ１０４で実行する際に使用されるＡｐｐＣ転送判定情報記憶部（ＩＤトラン）２２４ｃがある。これらについては、図６Ａ、６Ｂを用いて詳細に説明する。

　処理サーバ１０４におけるプログラム記憶装置２３０は、実行プラットフォーム２４０、ミドルウェア２５０、アプリ群２６０の３つを含む。実行プラットフォーム２４０は、Ｊａｖａ（登録商標）の実行環境やＡｐａｃｈｅ　Ｈａｄｏｏｐ（登録商標）などであり、分散処理の実行環境であって、プログラムを実行するための環境となるプログラムである。また、実行プラットフォーム２４０は、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）を含んでもよく、ＯＳは通信のプロトコルスタックの一部を含んでもよい。

　ミドルウェア２５０は、いわゆるミドルウェアであり、実行プラットフォーム２４０上で動作して、アプリ群２６０の複数のアプリ２６１が利用する共通機能や、アプリ２６１それぞれの個別機能を埋め込むためのフレームワークを提供するプログラムである。このために、ミドルウェア２５０は、アプリ群２６０（アプリ２６１）とのインターフェイスおよび／あるいは実行プラットフォーム２４０とのインターフェイスを有するプログラムの集合であってもよい。

　ミドルウェア２５０は、クライアント端末１０１から送信されたデータに基づきメッセージを生成する、もしくは他の処理サーバ１０４から転送されたメッセージを受信するメッセージ受信生成部２５１、生成もしくは受信されたメッセージに対してアプリケーションすなわち処理実行部２６２を実行するための処理サーバ１０４を選定する処理サーバ選定部２５２、処理実行部２６２を呼び出し実行するアプリ実行部２５３を含む。

　さらに、ミドルウェア２５０は、アプリ２６１を実行することでサーバ判定情報記憶部２２２もしくはアプリ別転送判定情報記憶部２２３の情報が更新された場合、デプロイアプリ管理サーバ１０５に更新情報を通知する判定情報更新チェック部２５４、デプロイアプリ管理サーバ１０５から他の処理サーバ１０４のサーバ判定情報もしくはアプリ別転送判定情報の更新が通知されてきた場合、通知を受信してサーバ判定情報記憶部２２２もしくはアプリ別転送判定情報記憶部２２３を更新する判定情報受信更新部２５５を含む。

　ここで、メッセージ受信生成部２５１は、処理サーバ１０４間で共通のメッセージを受信してアプリ２６１を特定することに加えて、アプリ２６１ごとに異なるプロトコルのデータを受信できるように、アプリ２６１の開発者が新たに追加できるアプリ別受信処理部２６４を起動させて、複数のプロトコルのデータを受信できるように待機させる。メッセージ受信生成部２５１と処理サーバ選定部２５２については、図７と図８を用いて詳細に説明する。

　アプリ群２６０は１つまたは複数のアプリ２６１を含む。アプリ２６１の処理実行部２６２は、メッセージに応じた動作をするためのメインプログラムであり、この処理実行部２６２に加えて、アプリ２６１に固有の条件で転送判定処理を行いたい場合に追加されるアプリ別処理サーバ選定部２６３と、アプリ２６１ごとに異なるプロトコルのデータを受信してメッセージを生成するアプリ別受信処理部２６４を含んでもよい。

　これにより、アプリ２６１の開発者にとっては、処理実行部２６２、アプリ別処理サーバ選定部２６３、アプリ別受信処理部２６４の３つが開発対象となる。これら３つをセットにして１つのアプリ２６１として各処理サーバ１０４に配置すれば、配置された処理サーバ１０４のそれぞれはアプリケーションを実行可能なクラスタとして動作する。

　また、３つをセットにすることに限定されるものではなく、アプリ別受信処理部２６４は多くの処理サーバ１０４に配置されて、アプリ別受信処理部２６４の配置された処理サーバ１０４の中で、処理実行部２６２とアプリ別処理サーバ選定部２６３がアプリケーションの処理量に応じた少ない台数分の処理サーバ１０４に配置されてもよい。

　これにより、多くの処理サーバ１０４でデータのプロトコルを解析することができ、かつ、処理実行部２６２が配置されている処理サーバ１０４の中から処理サーバ１０４が選定されて、選定された処理サーバ１０４にデータ（メッセージ）が転送される。このような構成では、処理実行部２６２とアプリ別処理サーバ選定部２６３の２つがアプリ２６１であってもよく、アプリ別受信処理部２６４はアプリ２６１に含まれなくてもよい。また、処理実行部２６２がアプリ２６１であってもよい。

　なお、プログラム記憶装置２３０に含まれる各部は、中央処理装置２１１により読み込まれて実行されるプログラムであるが、２つ以上の部が１つのプログラムを構成してもよい。以下の説明において、プログラム記憶装置２３０に含まれる各部が主体となる説明は、その各部を読み込んで実行する中央処理装置２１１が主体となる説明に置き換えられてもよい。プログラム記憶装置２３０はメモリであってもよく、プログラム記憶装置２３０に含まれる各部は、データ記憶装置２２０にも格納されて、データ記憶装置２２０からロードされてもよく、通信Ｉ／Ｆ２１０もしくは図示を省略した記憶媒体の読み取り装置からロードされてもよい。

　以上で説明したように、アプリ別処理サーバ選定部２６３とアプリ別受信処理部２６４により、従来は、データ振り分け装置１０３が行っていたプロトコル解析処理やサーバ選定処理を、処理サーバ１０４側に委譲することができ、データ振り分け装置１０３の処理負担を軽減することができる。

　図３は、デプロイアプリ管理サーバ１０５の構成の例である。デプロイアプリ管理サーバ１０５は、各処理サーバ１０４から通知されてくる最新のサーバ判定情報もしくはアプリ別転送判定情報を管理して、通知した処理サーバ１０４以外の処理サーバ１０４に配信するサーバである。なお、通知した処理サーバ１０４が配信先に含まれてもよい。

　図３に示すようにデプロイアプリ管理サーバ１０５は、処理サーバ１０４と同じく、外部と通信する通信Ｉ／Ｆ３１０、永続化する情報を格納するデータ記憶装置３２０、プログラム処理を格納するプログラム記憶装置３３０、データ記憶装置３２０やプログラム記憶装置３３０から必要な情報やプログラムを読み込み実行する中央処理装置３１１といった、一般的なコンピュータの備える部品がバス接続されて構成される。

　デプロイアプリ管理サーバ１０５におけるデータ記憶装置３２０は、各処理サーバ１０４が保持しているサーバ判定情報とアプリ別転送判定情報の最新情報をそれぞれ保持するサーバ判定情報記憶部３２２とアプリ別転送判定情報記憶部２２３を含む。各処理サーバ１０４では、自身に配置されているアプリ２６１に関する情報を保持しているのに対し、デプロイアプリ管理サーバ１０５では、処理サーバ１０４のいずれかに配置されていれば、その配置されているアプリ２６１に関する情報も保持している点が異なる。

　デプロイアプリ管理サーバ１０５におけるプログラム記憶装置３３０は、各処理サーバ１０４から通知されてくるサーバ判定情報もしくはアプリ別転送判定情報を基に、サーバ判定情報記憶部３２２、アプリ別転送判定情報記憶部３２３を最新状態に更新し、更新前の情報を保持する処理サーバ１０４を抽出して、抽出された処理サーバ１０４に最新情報を配信するための判定情報更新転送部３３１を含む。

　判定情報更新転送部３３１は、中央処理装置３１１により読み込まれて実行されるプログラムであり、以下の説明において、判定情報更新転送部３３１が主体となる説明は、判定情報更新転送部３３１を読み込んで実行する中央処理装置３１１が主体となる説明に置き換えられてもよい。プログラム記憶装置３３０はメモリであってもよく、判定情報更新転送部３３１は、データ記憶装置３２０にも格納されて、データ記憶装置３２０からロードされてもよく、通信Ｉ／Ｆ３１０もしくは図示を省略した記憶媒体の読み取り装置からロードされてもよい。

　各処理サーバ１０４の判定情報更新チェック部２５４は、自身のサーバ判定情報記憶部２２２もしくはアプリ別転送判定情報記憶部２２３の情報が更新されたこと、あるいは更新する動作を検出して、更新された情報を通信Ｉ／Ｆ２１０で通知する。デプロイアプリ管理サーバ１０５の判定情報更新転送部３３１は、通知を通信Ｉ／Ｆ３１０で受け取り、通知された更新情報を基に、サーバ判定情報記憶部３２２もしくはアプリ別転送判定情報記憶部３２３を更新し、通信Ｉ／Ｆ３１０で配信する。

　この配信は、更新情報を基に、更新前の情報を保持する処理サーバ１０４を抽出して、抽出された処理サーバ１０４を宛先とする配信であってもよい。処理サーバ１０４の判定情報受信更新部２５５は、配信を通信Ｉ／Ｆ２１０で受信し、配信された更新情報を基に、自身のサーバ判定情報記憶部２２２もしくはアプリ別転送判定情報記憶部２２３を更新する。

　なお、処理サーバ１０４の処理サーバ選定部２５２が、最新のサーバ判定情報とアプリ別転送判定情報を参照できればよく、たとえば処理サーバ１０４内にこれらの情報を保持せず、デプロイアプリ管理サーバ１０５で保持して、処理サーバ選定部２５２が参照するたびに処理サーバ１０４がデプロイアプリ管理サーバ１０５にアクセスしてもよい。

　ただし、処理サーバ選定部２５２の処理負荷の比率が処理実行部２６２に対して大きくなると、アプリケーションの処理のオーバーヘッドとなり、負荷分散の効果が小さくなるため、処理サーバ選定部２５２の処理負荷の比率が大きくならないように、処理サーバ選定部２５２が自身の処理サーバ１０４のサーバ判定情報記憶部２２２とアプリ別転送判定情報記憶部２２３を参照することが好ましい。

　図４は、処理サーバ１０４内に保持されるアプリ-メッセージ管理記憶部２２１をテーブルで構成した例である。アプリ-メッセージ管理記憶部２２１には、アプリ２６１とメッセージの関係を定義した情報が記憶される。この例では、アプリ２６１を特定するアプリ名４０１とメッセージを特定するメッセージタイプ４０２を含み、アプリ名４０１の情報とメッセージタイプ４０２の情報が互いに対応付けられている。

　アプリ名４０１の「ＡｐｐＡ」、「ＡｐｐＢ」、「ＡｐｐＣ」のそれぞれは、図２に示したアプリ２６１ａ、アプリ２６１ｂ、アプリ２６１ｃのそれぞれを特定するものである。アプリ-メッセージ管理記憶部２２１に記憶される情報は、通信Ｉ／Ｆ２１０経由あるいは図示を省略した入力装置により予め設定される。

　図５は、処理サーバ１０４とデプロイアプリ管理サーバ１０５内に保持されるサーバ判定情報記憶部２２２、３２２をテーブルで構成した例である。サーバ判定情報記憶部２２２、３２２には、各処理サーバ１０４に配置されているアプリ２６１の情報と、各処理サーバ１０４の負荷情報が記憶される。

　この例では、処理サーバ１０４を特定する処理サーバ名５０１、処理サーバ１０４に配置されているアプリ２６１を表すデプロイアプリ名５０２、処理サーバ１０４の負荷状態を表す負荷情報５０３を含み、これらの情報が互いに対応付けられている。処理サーバ名５０１の「ＳｅｒｖｅｒＡ」、「ＳｅｒｖｅｒＢ」、「ＳｅｒｖｅｒＣ」のそれぞれは、図１に示した処理サーバ１０４ａ、処理サーバ１０４ｂ、処理サーバ１０４ｃのそれぞれを特定するものである。

　デプロイアプリ名５０２の「ＡｐｐＡ」などはアプリ名４０１の「ＡｐｐＡ」などに対応する。負荷情報５０３の負荷状態は、中央処理装置２１１の負荷や、処理実行部２６２に割り当てられて処理待ちしているメッセージの量に所定の重み係数を乗じた量などを指針にしてもよい。負荷状態の表現は、「Ｂｕｓｙ」や「Ｆｒｅｅ」でもよく、数値などでもよい。

　処理サーバ名５０１とデプロイアプリ名５０２の情報は、通信Ｉ／Ｆ２１０経由あるいは図示を省略した入力装置により予め設定され、負荷情報５０３の情報は、中央処理装置２１１により定期的に検出されて更新されてもよいし、図１に示したシステムとは別の運用管理サーバなどが各処理サーバ１０４を監視して負荷状態を収集し、定期的に更新されてもよい。

　図６Ａは、処理サーバ１０４とデプロイアプリ管理サーバ１０５内に保持されるＡｐｐＡ転送判定情報記憶部（キャッシュ）２２４ａ、３２４ａをテーブルで構成した例である。ＡｐｐＡ転送判定情報記憶部（キャッシュ）２２４ａ、３２４ａには、各処理サーバ１０４がアプリ２６１ａ（ＡｐｐＡ）を過去に実行した際に、実行した処理サーバ１０４にキャッシュされたデータ（キャッシュデータ）であって、その後もキャッシュとして保持されているデータを特定する情報が記憶される。

　この例では、処理サーバ１０４を特定する処理サーバ名６０１と処理サーバ１０４がキャッシュデータの情報を表す保持キャッシュ情報６０２を含み、これらの情報が互いに対応付けられている。処理サーバ名６０１の「ＳｅｒｖｅｒＡ」などは、デプロイアプリ名５０２の「ＡｐｐＡ」に対応する処理サーバ名５０１の「ＳｅｒｖｅｒＡ」などと一致する。

　保持キャッシュ情報６０２の「ＡＡＡＡＡ」などは、キャッシュデータを特定できる情報であればよく、データ量が少ない場合はキャッシュデータの内容そのものでもよく、キャッシュデータの内容を特定するために付与された識別子やキャッシュデータのハッシュ関数値などであってもよい。

　処理サーバ名６０１の情報は、通信Ｉ／Ｆ２１０経由あるいは図示を省略した入力装置により予め設定され、保持キャッシュ情報６０２の情報は、中央処理装置２１１によりキャッシュの処理時に更新されてもよい。

　図６Ｂは、処理サーバ１０４とデプロイアプリ管理サーバ１０５内に保持されるＡｐｐＣ転送判定情報記憶部（ＩＤトラン）２２４ｃ、３２４ｃをテーブルで構成した例である。ＡｐｐＣ転送判定情報記憶部（ＩＤトラン）２２４ｃ、３２４ｃは、各処理サーバ１０４が現在処理中のアプリ２６１ｃ（ＡｐｐＣ）に関するトランザクションのＩＤが記憶される。

　この例では、処理サーバ１０４を特定する処理サーバ名６１１と処理サーバ１０４が現在処理しているアプリ２６１に関するトランザクションのＩＤである処理中ＩＤ６１２を含み、これらの情報が互いに対応付けられている。処理サーバ名６１１の「ＳｅｒｖｅｒＡ」などは、デプロイアプリ名５０２の「ＡｐｐＣ」に対応する処理サーバ名５０１の「ＳｅｒｖｅｒＡ」などと一致する。

　処理サーバ名６１１の情報は、通信Ｉ／Ｆ２１０経由あるいは図示を省略した入力装置により予め設定され、処理中ＩＤ６１２の情報は、中央処理装置２１１によりトランザクションの起動時や終了時に更新されてもよい。

　図７は、処理サーバ１０４のデータもしくはメッセージの受信の動作フローの例である。まず、各種プロトコルのデータやメッセージを受信するために、ミドルウェア２５０あるいはメッセージ受信生成部２５１は、アプリ別受信処理部２６４のそれぞれとメッセージ受信生成部２５１を受信可能な状態にする。具体的には、アプリ別受信処理部２６４のそれぞれに含まれる受信用サーバとメッセージ受信生成部２５１に含まれる受信用サーバを起動状態にする（ステップ７０１）。

　たとえば、メッセージの受信用サーバとして、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）のポート番号１２３４５で受信待ちする受信用サーバ、アプリケーションプロトコルの受信用サーバとして、ＨＴＴＰサーバやＭＱＴＴサーバなどの受信用サーバなどがある。

　アプリケーションプロトコルの受信用サーバはアプリ２６１ごとに１つずつ別々に起動されてもよいし、異なるアプリ２６１であっても同じプロトコルの場合は、受信用サーバは１つにして、データ内の識別子などからアプリ２６１が識別されてもよい。このように同じプロトコルの場合は、アプリ２６１間でアプリ別受信処理部２６４が共通になってもよい。受信用サーバが起動されると、それぞれの受信用サーバはメッセージあるいはデータの受信待ち状態になる（ステップ７０２）。

　処理サーバ１０４がデータを受信した場合、たとえばクライアント端末１０１から送信されたデータが、ＨＴＴＰのプロトコルのデータすなわちアプリ２６１ａ（ＡｐｐＡ）で処理するデータである場合、アプリ２６１ａ内のＡアプリ別受信処理部２６４ａがデータを受信して、プロトコルを解析し（ステップ７０３）、アプリ２６１ａ（ＡｐｐＡ）に対応したメッセージを１つないし複数生成する（ステップ７０４）。

　そして、処理サーバ１０４を選定するために、図８を用いて説明する処理へ進む（ステップ７０６）。ここで、データにはアプリ２６１を特定する情報が含まれているため、データからアプリ２６１を特定するための処理を行う必要はないが、メッセージにはアプリ２６１を特定する情報そのものは含まれていないため、以下の処理が行われる。

　処理サーバ１０４がメッセージを受信した場合、たとえばクライアント端末１０１からではなく他の処理サーバ１０４などにより変換されたメッセージを受信した場合、受信されたメッセージでアプリ-メッセージ管理記憶部２２１のメッセージタイプ４０２を検索し、受信されたメッセージに対応するアプリ名４０１の情報を取得し、アプリ２６１を特定する（ステップ７０５）。そして、処理サーバ１０４を選定するために、図８を用いて説明する処理へ進む（ステップ７０６）。

　なお、処理サーバ１０４の通信Ｉ／Ｆ２１０がデータあるいはメッセージを受信すると、一般的なコンピュータの動作と同じように、実行プラットフォーム２４０のＯＳに含まれるプロトコルスタックがＴＣＰを処理し、ＴＣＰのポート番号に応じたプログラムを呼び出して、データあるいはメッセージを渡してもよい。

　たとえば、予め対応付けが設定されたポート番号に応じて、ＯＳは、メッセージ受信生成部２５１の受信用サーバ、Ａアプリ別受信処理部２６４ａの受信用サーバ、Ｂアプリ別受信処理部２６４ｂの受信用サーバ、Ｃアプリ別受信処理部２６４ｃの受信用サーバのいずれかを呼び出してもよい。また、このＴＣＰのポート番号に応じたプログラムの呼び出しを、メッセージ受信生成部２５１が行ってもよい。

　図８は、処理サーバ１０４の処理サーバ選定の動作フローの例である。まず、処理サーバ選定部２５２は、メッセージ受信生成部２５１により特定されたアプリ２６１あるいはデータに含まれる情報により特定されるアプリ２６１が、判定を実行する処理サーバ１０４自身に登録されているかどうかを判定する（ステップ８０１）。ここで、データを処理サーバ選定部２５２はアプリ別受信処理部２６４から取得してもよい。

　このために処理サーバ選定部２５２は、サーバ判定情報記憶部２２２の処理サーバ名５０１で、ステップ８０１を実行している処理サーバ選定部２５２自身の処理サーバ１０４を検索し、検索で一致した処理サーバ１０４に対応するデプロイアプリ名５０２に、特定されたアプリ２６１が登録されているかを判定してもよい。

　処理サーバ選定部２５２は、特定されたアプリ２６１が登録されていると判定した場合、さらにアプリ２６１に固有の条件での転送判定処理が存在するかどうかを判定する（ステップ８０２）。たとえば、特定されたアプリ２６１がアプリ２６１ａ（ＡｐｐＡ）である場合は、Ａアプリ別処理サーバ選定部（キャッシュ）２６３ａが存在すると判定してもよいし、特定されたアプリ２６１がアプリ２６１ｂ（ＡｐｐＢ）である場合は、アプリ２６１ｂに固有の条件での転送判定処理が存在しないと判定してもよい。

　処理サーバ選定部２５２は、ステップ８０１とステップ８０２のどちらかでＮｏと判定した場合、サーバ判定情報記憶部２２２をもとに、特定されたアプリ２６１をデプロイアプリ名５０２に含む処理サーバ１０４を選定する（ステップ８０３）。なお、特定されたアプリ２６１をデプロイアプリ名５０２に含む処理サーバ１０４が複数存在する場合、この選定として、複数の存在の中から、負荷が少ない処理サーバ１０４を選定してもよいし、単純にラウンドロビンで選定してもよいし、それ以外のアプリ２６１に非依存の情報で選定してもよい。この選定は、ミドルウェア２５０として標準でサポートとなる。

　ステップ８０２でＹＥＳと判定された場合、処理サーバ選定部２５２は、特定されたアプリ２６１に固有の条件での転送判定処理を呼び出す（ステップ８０４）。呼び出されたアプリ別処理サーバ選定部２６３は、アプリ別転送判定情報記憶部２２３とサーバ判定情報記憶部２２２の情報を使って処理サーバ１０４を選定する（ステップ８０５）。

　たとえば、特定されたアプリ２６１がアプリ２６１ａ（ＡｐｐＡ）の場合、Ａアプリ別処理サーバ選定部（キャッシュ）２６３ａが呼び出され、Ａアプリ別処理サーバ選定部（キャッシュ）２６３ａは、ＡｐｐＡ転送判定情報記憶部（キャッシュ）２２４ａとサーバ判定情報記憶部２２２の情報をもとに、キャッシュデータを保持する処理サーバ１０４を優先しつつ、負荷の小さい処理サーバ１０４を選定する。

　ここで、同じキャッシュデータを保持する処理サーバ１０４が複数存在する場合は、それら複数存在する処理サーバ１０４が特定され、特定された処理サーバ１０４の中で負荷の相対的に小さい処理サーバ１０４が選定されてもよい。また、特定された処理サーバ１０４の間で負荷が同じ場合は、たとえばラウンドロビンで選択されてもよい。

　次に、処理サーバ選定部２５２は、選定された処理サーバ１０４が処理サーバ１０４自身であるかどうかを判定し（ステップ８０６）、処理サーバ１０４自身であると判定した場合、アプリ実行部２５３を呼び出す（ステップ８０７）。そして、アプリ実行部２５３はアプリ２６１を呼び出す。たとえば、特定されたアプリ２６１がアプリ２６１ａ（ＡｐｐＡ）の場合は、Ａ処理実行部２６２ａを呼び出す。

　ステップ８０６で処理サーバ１０４自身でないと判定した場合、処理サーバ選定部２５２は、ステップ８０２で受信されたメッセージあるいはステップ７０４で生成されたメッセージを、ステップ８０３あるいはステップ８０５で選定された処理サーバ１０４へ転送する（ステップ８０８）。

　図９は、図７と図８を用いて説明した動作フローを組合せた全体の動作シーケンスの例である。この動作シーケンスは、レイヤ４レベルのプロトコルを解析し、データに依存することなく処理サーバ１０４を選定するデータ振り分け装置１０３を用いた場合の例である。

　処理サーバ１０４ａ、１０４ｂ、１０４ｃのそれぞれは、図１に示した「ＡｐｐＡ」、「ＡｐｐＢ」、「ＡｐｐＣ」のとおりに、各アプリ２６１の処理実行部２６２とアプリ別処理サーバ選定部２６３を有する。また、処理サーバ１０４ａ、１０４ｂ、１０４ｃのそれぞれが、少なくともＣアプリ別受信処理部２６４ｃを有する。

　まず、クライアント端末１０１が、プロトコルとしてＲＥＳＴを利用して、「ＡｐｐＣ」に対応し、トランザクションのＩＤが「１０１」のデータ９０１を送信する。データ振り分け装置１０３は、受信したデータ９０１をレイヤ４レベルであるＴＣＰのプロトコル解析を行い（ステップ９０２）、転送先の処理サーバ１０４ｃをラウンドロビンなど軽量な処理で選定し（ステップ９０３）、そのままのデータ９０４として転送する。

　ここでは、ラウンドロビンにより処理サーバ１０４ｃが選択されたとしたが、処理サーバ１０４ｃは「ＡｐｐＣ」のためのＣ処理実行部２６２ｃが登録されておらず、アプリ２６１ｃの処理を実行することができない。

　処理サーバ１０４ｃは、Ｃアプリ別受信処理部２６４ｃにより、レイヤ７レベルの「ＡｐｐＣ」のプロトコル解析を行い（ステップ９０５）、データ振り分け装置１０３にＯＫ９０６を返信し、メッセージ（ＭｅｓｓａｇｅＣ）を生成して（ステップ９０８）、図８に示したステップ８０３の標準サポートの選定を行う（ステップ９０９）。

　標準サポートの選定では、サーバ判定情報記憶部２２２から「ＡｐｐＣ」に対応した処理サーバ１０４であって、負荷が少ない処理サーバ１０４が選定され、負荷の同じ処理サーバ１０４が複数存在する場合は、その中でラウンドロビンにより「ＳｅｒｖｅｒＡ」（処理サーバ１０４ａ）が選定される。処理サーバ１０４ｃは、選定された処理サーバ１０４ａにメッセージ９１０を転送する。

　ここで、処理サーバ１０４ｃには、「ＡｐｐＣ」のためのＣアプリ別処理サーバ選定部２６３ｃも登録されていないため、ミドルウェア２５０が、標準でサポートしている選定により、処理サーバ１０４ａを選定したことになる。

　処理サーバ１０４ａは、メッセージ９１０を受信すると、アプリ-メッセージ管理記憶部２２１からメッセージ９１０（ＭｅｓｓａｇｅＣ）対応した「ＡｐｐＣ」（アプリ２６１ｃ）を特定して（ステップ９１１）、ＯＫ９１２を返信するとともに、アプリ２６１ｃに固有の条件での転送判定処理が存在するために、Ｃアプリ別処理サーバ選定部２６３ｃが呼び出され、処理サーバ１０４の選定を行う（ステップ９１３）。

　この選定では、メッセージ９１０のデータに含まれるトランザクションのＩＤが「１０１」であるため、ＡｐｐＣ転送判定情報記憶部（ＩＤトラン）２２４ｃを参照して、「ＳｅｒｖｅｒＢ」（処理サーバ１０４ｂ）が選定される。この選定にしたがって、処理サーバ１０４ａは、メッセージ９１０と同じメッセージ９１４をさらに処理サーバ１０４ｂに転送する。

　処理サーバ１０４ｂは、メッセージ９１４を受信すると、処理サーバ１０４ａと同様にアプリ-メッセージ管理記憶部２２１から対応したアプリ２６１ｃを特定して（ステップ９１５）、ＯＫ９１６を返信するとともに、アプリ２６１ｃに固有の条件で転送判定処理が存在するために、Ｃアプリ別処理サーバ選定部２６３ｃが呼び出され、処理サーバ１０４ｂ自身を選定して（ステップ９１７）、アプリ２６１ｃ（ＡｐｐＣ）のＣ処理実行部２６２ｃを呼び出し、アプリケーション処理する（ステップ９１８）。

　以上のように、データ振り分け装置１０３が、レイヤ７レベルの処理や処理サーバ１０４の負荷の処理をせずに、処理サーバ１０４を適当に選定しても、データはレイヤ７レベルや負荷に応じた処理サーバ１０４に転送されて、処理が実行される。また、従来のデータ振り分け装置の処理負荷となっていた処理を、処理サーバ１０４側に委譲でき、大量データかつ複数のプロトコルが存在する多様なデータにおいても、データ振り分け装置１０３がボトルネックになることなく、処理サーバ１０４に振り分けて負荷分散を行うことができる。

　さらに、データ振り分け装置１０３はレイヤ４レベルのプロトコル解析で転送できることにより、データ振り分け装置１０３はレイヤ７レベルのプロトコルやアプリ２６１の配置に依存することなく、データ振り分け装置１０３として市販のロードバランサを導入することも可能となる。

　ただし、以上のように、処理サーバ１０４側でプロトコル解析、メッセージ生成、アプリ別の転送判定処理が行われると、処理サーバ１０４の負荷が大きくなり、データ振り分け装置１０３に余裕があるにも関わらず、処理サーバ１０４の台数を拡張せざるを得ない場合が出てくる。

　そこで、以上のようなデータ振り分け装置１０３側で、レイヤ７レベルのプロトコルを解析せずに処理サーバ１０４に転送する例に加えて、レイヤ７レベルのプロトコルを解析してメッセージ生成まで行うがアプリ２６１を特定せずに処理サーバ１０４に転送する例、アプリ２６１が登録されている処理サーバ１０４まで選定して転送する例、アプリ別の転送判定処理まで行ったうえで処理サーバ１０４を選定して転送する例、を用いて、データ振り分け装置１０３の段階的な処理内容の変更に対して、処理サーバ１０４は対応できることを、以下で説明する。

　図１０から図１２は、データ振り分け装置１０３の段階的な処理内容の変更に応じたシステム全体の動作シーケンスの例である。各図におけるデータ振り分け装置１０３は物理的に同じ装置であるが、何らかの設定が異なるため処理内容が異なるものであってもよいし、データ振り分け装置１０３と同じ符号で説明するが、処理内容の異なる物理的に別の装置であってもよい。

　処理サーバ１０４ａ、１０４ｂ、１０４ｃは、図が異なっても共通であり、図１から図９を用いて説明した処理サーバ１０４ａ、１０４ｂ、１０４ｃである。ただし、図によって、処理サーバ１０４ａ、１０４ｂ、１０４ｃの受信するデータあるいはメッセージが異なるため、処理サーバ１０４ａ、１０４ｂ、１０４ｃの動作が異なる。

　図１０は、データ振り分け装置１０３が、プロトコル解析してメッセージ生成まで行うが、アプリ２６１を特定せずに処理サーバ１０４に転送する動作シーケンスの例である。まず、クライアント端末１０１が、プロトコルとしてＲＥＳＴを利用して「ＡｐｐＣ」に対応し、トランザクションのＩＤが「１０１」のデータ１００１を送信する。

　データ振り分け装置１０３は、受信したデータ１００１のレイヤ７レベルのプロトコルを解析して（ステップ１００２）、クライアント端末１０１にＯＫ１００３を返信するとともに、メッセージ（ＭｅｓｓａｇｅＣ）を生成する（ステップ１００４）。そして、メッセージ（ＭｅｓｓａｇｅＣ）に対応したアプリ２６１ｃ（ＡｐｐＣ）が登録されている処理サーバ１０４の特定までは行わずに、ラウンドロビンなどランダムに選定した結果である処理サーバ１０４ｃに、メッセージ１００６を転送する。

　処理サーバ１０４ｃは、メッセージ１００６を受信すると、アプリ-メッセージ管理記憶部２２１からメッセージ１００６（ＭｅｓｓａｇｅＣ）に対応した「ＡｐｐＣ」（アプリ２６１ｃ）を特定して（ステップ１００７）、ＯＫ１００８を返信する。「ＡｐｐＣ」が特定された後のステップ１００９からステップ１０１８は、図９を用いて説明したステップ９０９からステップ９１８と同じ動作シーケンスであり、処理サーバ１０４ｂがアプリ２６１ｃ（ＡｐｐＣ）のＣ処理実行部２６２ｃを呼び出してアプリケーション処理する。

　図１０に示した例では、データ振り分け装置１０３が、レイヤ７レベルのプロトコル解析とメッセージ生成を行い、アプリ２６１を特定せずに処理サーバ１０４に転送するため、図９に示した例より処理サーバ１０４ｃの処理が軽量化され、データ振り分け装置１０３でアプリ２６１を特定までするよりデータ振り分け装置１０３の処理が軽量化される。また、処理サーバ１０４ｃの構成や設定を変更する必要はない。

　図１１は、データ振り分け装置１０３が、アプリ２６１が登録されている処理サーバ１０４まで選定して転送する動作シーケンスの例である。まず、クライアント端末１０１が、プロトコルとしてＨＴＴＰを利用して「ＡｐｐＡ」に対応し、アプリ２６１ａ（ＡｐｐＡ）の処理に使用されるデータが「ＡＡＡＡＡ」のデータ１１０１を送信する。ここで、「ＡＡＡＡＡ」は保持キャッシュ情報６０２に対応する情報である。

　データ振り分け装置１０３は、受信したデータ１１０１のレイヤ７レベルのプロトコルを解析して（ステップ１１０２）、クライアント端末１０１にＯＫ１１０３を返信するとともに、メッセージ（ＭｅｓｓａｇｅＡ）を生成する（ステップ１１０４）。次に、「ＡｐｐＡ」が登録されている処理サーバ１０４ａを選定する（ステップ１１０５）。このとき、「ＡｐｐＡ」が登録されている処理サーバ１０４ａ、１０４ｃの中から、ラウンドロビンなどランダムに処理サーバ１０４ａを選定し、メッセージ１１０６を転送する。

　処理サーバ１０４ａは、メッセージ１１０６を受信すると、アプリ-メッセージ管理記憶部２２１からメッセージ１１０６（ＭｅｓｓａｇｅＡ）に対応した「ＡｐｐＡ」（アプリ２６１ａ）を特定して（ステップ１１０７）、ＯＫ１１０８を返信するとともに、アプリ２６１ａに固有の条件での転送判定処理が存在するために、Ａアプリ別処理サーバ選定部（キャッシュ）２６３ａが呼び出され、処理サーバ１０４の選定を行う（ステップ１１０９）。

　この選定では、メッセージ１１０６に含まれるデータが「ＡＡＡＡＡ」であるため、ＡｐｐＡ転送判定情報記憶部（キャッシュ）２２４ａを参照して、「ＳｅｒｖｅｒＣ」（処理サーバ１０４ｃ）が選定される。この選定にしたがって、処理サーバ１０４ａは、メッセージ１１０６と同じメッセージ１１１０をさらに処理サーバ１０４ｃに転送する。

　処理サーバ１０４ｃは、メッセージ１１１０を受信すると、処理サーバ１０４ａと同様にアプリ-メッセージ管理記憶部２２１から対応したアプリ２６１ａを特定して（ステップ１１１１）、ＯＫ１１１２を返信するとともに、アプリ２６１ａに固有の条件で転送判定処理が存在するために、Ａアプリ別処理サーバ選定部（キャッシュ）２６３ａが呼び出され、処理サーバ１０４ｃ自身を選定して（ステップ１１１３）、アプリ２６１ａ（ＡｐｐＡ）のＡ処理実行部２６２ａを呼び出し、アプリケーション処理する（ステップ１１１４）。

　データ振り分け装置１０３で、アプリ２６１が登録されている処理サーバ１０４にメッセージが転送されるため、受信した処理サーバ１０４では、アプリ２６１の固有の条件での転送判定処理があれば、１回の転送が発生する可能性があるものの、図９と図１０で示した例のように２回の転送が発生することはない。

　図１１で示した動作シーケンスの例では、データ振り分け装置１０３でプロトコル解析とメッセージ生成を行い、さらにメッセージに対応したアプリ２６１が登録されている処理サーバ１０４まで選定するため、データ振り分け装置１０３でサーバ判定情報記憶部２２２相当の情報を管理する。ただし、アプリ２６１に固有の条件での転送判定処理を行わずに、ラウンドロビンなどを行うため、アプリ２６１の種類が増えても転送判定処理負荷の増加にはつながらない。

　図１２は、データ振り分け装置１０３が、アプリ２６１に固有の条件で転送判定処理を行って処理サーバ１０４を選定して転送する動作シーケンスの例である。まず、クライアント端末１０１が、プロトコルとしてＨＴＴＰを利用して「ＡｐｐＡ」に対応し、アプリ２６１ａ（ＡｐｐＡ）の処理に使用されるデータが「ＡＡＡＡＡ」のデータ１２０１を送信する。

　データ振り分け装置１０３は、受信したデータ１２０１のレイヤ７レベルのプロトコルを解析して（ステップ１２０２）、クライアント端末１０１にＯＫ１２０３を返信するとともに、メッセージ（ＭｅｓｓａｇｅＡ）を生成する（ステップ１２０４）。次に、メッセージ（ＭｅｓｓａｇｅＡ）の転送先となる処理サーバ１０４をアプリ別処理サーバ選定部２６３と同じ処理により選定する（ステップ１２０５）。

　このためにデータ振り分け装置１０３は、ＡｐｐＡ転送判定情報記憶部（キャッシュ）２２４ａ相当の情報と、サーバ判定情報記憶部２２２相当の情報を有し、「ＡｐｐＡ」の登録された「ＳｅｒｖｅｒＡ」と「ＳｅｒｖｅｒＣ」の中から、データが「ＡＡＡＡＡ」であるため、「ＳｅｒｖｅｒＣ」（処理サーバ１０４ｃ）を選定する。

　データ振り分け装置１０３がメッセージ１２０６を転送し、処理サーバ１０４ｃがメッセージ１２０６を受信すると、ステップ１２０７からステップ１２１０は、図１１を用いて説明したステップ１１１１からステップ１１１４と同じ動作シーケンスであり、処理サーバ１０４ｃがアプリ２６１ａ（ＡｐｐＡ）のＡ処理実行部２６２ａを呼び出してアプリケーション処理する。

　図１２で示した動作シーケンスの例では、データ振り分け装置１０３でプロトコル解析とメッセージ生成を行い、さらにメッセージに対応したアプリ２６１が登録され、かつアプリ２６１に固有の条件での転送判定処理を行って選定するため、アプリ２６１の種類が増えると、データ振り分け装置１０３の転送判定処理負荷が増加する。これに対して処理サーバ１０４は、転送が発生することなく、処理負荷が軽減される。

　以上、図９から図１２で示したように、データ振り分け装置１０３の処理負荷のレベルが変更されても、変更に合わせて処理サーバ１０４は柔軟に動作することができる。また、データ振り分け装置１０３において処理負荷のレベルがアプリ２６１ごとに異なった処理負荷にされたとしても、処理サーバ１０４はアプリ２６１ごとのデータ振り分け装置１０３からの受信内容に合わせて動作することができる。

　たとえば、データ振り分け装置１０３が、アプリ２６１ａ（ＡｐｐＡ）はアプリ２６１ａが登録されている処理サーバ１０４まで選定して転送し、アプリ２６１ｂ（ＡｐｐＢ）はレイヤ７レベルのプロトコルを解析せずにラウンドロビンで処理サーバ１０４を選定して転送してもよい。

　これを運用管理サーバから動的に設定可能とすることにより、運用管理サーバは、データ量が少ないときや対応するアプリ２６１の数が少ないときは、データ振り分け装置１０３の処理負荷を高くして、最小限の処理サーバ１０４の台数で負荷分散を行うように設定し、データ量が増えてきたら、データ量が多いアプリ２６１から順に、データ振り分け装置１０３の処理負荷を段階的に減らすように設定してもよい。

　このような設定により、全体的に最適な負荷分散システムを構築することができ、最終的に従来よりも大量のデータで多数のアプリ２６１に対応可能な負荷分散システムを構築することができる。

１０１：クライアント端末、１０２：ネットワーク、１０３：データ振り分け装置、１０４：処理サーバ、１０５：デプロイアプリ管理サーバ

Claims

　データ振り分け装置と複数の処理サーバから構成される処理システムであって、
　前記データ振り分け装置は、
　アプリケーションプログラムが特定される情報を含むデータを受信し、受信されたデータもしくは受信されたデータから生成されたメッセージを、複数の前記処理サーバのいずれかに転送し、
　前記処理サーバは、
　複数の前記処理サーバそれぞれのアプリケーションプログラムの登録情報と、複数の前記処理サーバそれぞれの負荷情報が格納されたサーバ判定情報記憶部と、
　アプリケーションプログラムに固有の転送する条件が格納されたアプリ別転送判定情報記憶部と、
を有し、
　アプリケーションプログラムが特定される情報を含むデータもしくはメッセージを受信し、
　受信されたデータもしくはメッセージがデータであると判定すると、受信されたデータからメッセージを生成し、
　受信されたデータもしくはメッセージがメッセージであると判定すると、受信されたメッセージからアプリケーションプログラムを特定し、
　前記サーバ判定情報記憶部と前記アプリ別転送判定情報記憶部に格納された情報に基づいて、複数の前記処理サーバの中から処理サーバを選定し、
　選定された処理サーバが前記処理サーバ自身であると判定すると、特定されたアプリケーションプログラムを実行し、
　選定された処理サーバが前記処理サーバ自身でないと判定すると、受信されたもしくは生成されたメッセージを、選定された処理サーバに転送すること
を特徴とする処理システム。
　請求項１に記載の処理システムであって、
　前記処理サーバは、
　特定されたアプリケーションプログラムが前記処理サーバ自身に登録されていると判定すると、特定されたアプリケーションプログラムに固有の転送する条件があるかを判定し、
　特定されたアプリケーションプログラムに固有の転送する条件があると判定すると、前記サーバ判定情報記憶部に格納された情報と前記アプリ別転送判定情報記憶部に格納された情報の両方に基づいて、複数の前記処理サーバの中から処理サーバを選定すること
を特徴とする処理システム。
　請求項２に記載の処理システムであって、
　前記処理サーバは、
　特定されたアプリケーションプログラムに固有の転送する条件があると判定すると、前記アプリ別転送判定情報記憶部に格納された情報に基づいて、複数の前記処理サーバの中から、特定されたアプリケーションプログラムに固有の転送する条件に一致する処理サーバを特定し、前記サーバ判定情報記憶部に格納された情報に基づいて、特定された処理サーバの中で負荷の小さい処理サーバを選定すること
を特徴とする処理システム。
　請求項３に記載の処理システムであって、
　前記アプリ別転送判定情報記憶部に格納されたアプリケーションプログラムに固有の転送する条件は、複数の前記処理サーバそれぞれのキャッシュデータの情報であること
を特徴とする処理システム。
　請求項３に記載の処理システムであって、
　前記アプリ別転送判定情報記憶部に格納されたアプリケーションプログラムに固有の転送する条件は、複数の前記処理サーバそれぞれで実行されたトランザクションの情報であること
を特徴とする処理システム。
　請求項１に記載の処理システムであって、
　前記処理サーバは、
　特定されたアプリケーションプログラムが前記処理サーバ自身に登録されていると判定すると、特定されたアプリケーションプログラムに固有の転送する条件があるかを判定し、
　特定されたアプリケーションプログラムに固有の転送する条件がないと判定すると、前記サーバ判定情報記憶部に格納された情報に基づいて、複数の前記処理サーバの中から処理サーバを選定すること
を特徴とする処理システム。
　請求項１に記載の処理システムであって、
　特定されたアプリケーションプログラムが前記処理サーバ自身に登録されていないと判定すると、前記サーバ判定情報記憶部に格納された情報に基づいて、複数の前記処理サーバの中から処理サーバを選定すること
を特徴とする処理システム。
　請求項１に記載の処理システムであって、
　前記データ振り分け装置は、
　クライアント端末からデータを受信し、受信されたデータのレイヤ４レベルのプロトコルを解析し、受信されたデータを複数の前記処理サーバのいずれかに転送すること
を特徴とする処理システム。
　請求項１に記載の処理システムであって、
　前記データ振り分け装置は、
　クライアント端末からデータを受信し、受信されたデータのレイヤ７レベルのプロトコルを解析し、受信されたデータからメッセージを生成し、生成されたメッセージを複数の前記処理サーバのいずれかに転送すること
を特徴とする処理システム。
　請求項１に記載の処理システムであって、
　前記データ振り分け装置は、
　クライアント端末からデータを受信し、受信されたデータのレイヤ７レベルのプロトコルを解析し、受信されたデータからメッセージを生成し、複数の前記処理サーバの中でアプリケーションプログラムの登録された処理サーバを選定し、選定された処理サーバに生成されたメッセージを転送すること
を特徴とする処理システム。
　請求項１に記載の処理システムであって、
　前記データ振り分け装置は、
　クライアント端末からデータを受信し、受信されたデータのレイヤ７レベルのプロトコルを解析し、受信されたデータからメッセージを生成し、複数の前記処理サーバの中でアプリケーションプログラムの登録された処理サーバを特定し、特定された処理サーバの中でアプリケーションプログラムに固有の転送する条件と一致する処理サーバをさらに選定し、選定された処理サーバに生成されたメッセージを転送すること
を特徴とする処理システム。
　データ振り分け装置および他の処理サーバに接続された処理サーバで実行され、実行プラットフォームとのインターフェイスとアプリケーションプログラムとのインターフェイスを有するプログラムであって、
　前記データ振り分け装置もしくは前記他の処理サーバから受信されたメッセージを前記実行プラットフォームから取得してアプリケーションプログラムを特定し、
　特定されたアプリケーションプログラムに固有の転送する条件があると判定すると、特定されたアプリケーションプログラムに処理サーバを選定させ、
　特定されたアプリケーションプログラムに固有の転送する条件がないと判定すると、前記処理サーバおよび前記他の処理サーバの負荷に応じて処理サーバを選定し、
　前記他の処理サーバが選定されたと判定すると、選定された前記他の処理サーバにメッセージを転送し、
　前記処理サーバが選定されたと判定すると、特定されたアプリケーションプログラムに処理を実行させること
を特徴とするプログラム。