JP6273069B2 - データ処理システムおよびデータ処理方法 - Google Patents

Description

本発明は、データ処理を実行するデータ処理システムおよびデータ処理方法に関する。

近年、通信、電力、交通、産業といった社会インフラサービスにおいて、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）／ｍ２ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）が普及しはじめている。ＩｏＴサービスを提供するサーバシステム（以下、ＩｏＴサービスシステム）は、携帯電話、スマートメータ、自動車、工場の機器といった様々な通信デバイスから送信されるデータ（以下、メッセージ）を収集し、サービス目的に応じてデータを加工する。

ＩｏＴサービスシステムは、メッセージの活用目的の変更や追加により、頻繁にシステム変更を要求される。その度に、作業者による負荷分散設計と何度も負荷試験を行って負荷分散のパラメータを決定する作業（以下、チューニング）とが発生し、そのためのコストや負荷分散設計およびチューニング作業の日数の増加を抑制することが、ビジネス上の課題である。負荷分散設計およびチューニング作業では、作業者は、リソースに対する負荷試験と、ボトルネック解析と、リソース振分と、パラメータ設定という作業を何度も繰り返す。そして、作業者は、システムの処理性能（スループット）が最大となるパラメータの値および分散設計を探索する。

上記課題の解決方法として、特許文献１、２および非特許文献１に示すような動的な分散手法およびチューニング手法が開示されている。特許文献１は、サーバ内のたとえばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のリソースを管理するリソース管理部が、各処理にキューとそれを処理するスレッドプールを結びつけ、キューの滞留数に応じてスレッドを割り当てる方法を開示する。特許文献２は、キューと複数のサーバとを結びつけ、キューの滞留数から分散先を振り分ける方法を開示する。非特許文献１は、サーバを増減する方法を開示する。

米国特許第８２３０４４７号明細書 特開２００６−２５９８１２号公報

Ａｕｔｏ Ｓｃａｌｉｎｇ Ｄｅｖｅｌｏｐｅｒ Ｇｕｉｄｅ ＡＰＩ Ｖｅｒｓｉｏｎ ２０１１−０１−０１、［平成２７年７月２日検索］、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｄｏｃｓ.ａｗｓ.ａｍａｚｏｎ.ｃｏｍ／ＡｕｔｏＳｃａｌｉｎｇ／ｌａｔｅｓｔ／ＤｅｖｅｌｏｐｅｒＧｕｉｄｅ／ａｓ−ｕｓｉｎｇ−ｓｑｓ−ｑｕｅｕｅ.ｈｔｍｌ〉

近年、一部のＩｏＴサービスシステムは、業種により、多種大量のセンサから送信される粒度の異なるデータを多様な業務目的に活用するため、複雑なデータ加工と配信を要求される。たとえば、電力分野のＩｏＴサービスシステムは、スマートメータやＨＥＭＳ（Ｈｏｍｅ Ｅｎｅｒｇｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）から集めたデータを、電力会社、一般の電力供給者、電力の需給業者といった宛先ごとに、地域、時間、データフォーマットが異なるデータ処理を行う。また、産業分野のＩｏＴサービスシステムは、工場の監視や保全のために、工場の機器の情報に加え、ビデオカメラの動画データやタブレット等のデバイスのデータを収集してつき合わせるデータ処理を行う。

これらの複雑なデータ処理の多くは、ＳＯＡ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）やＭｉｃｒｏｓｅｒｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅと呼ばれる一連のデータ処理を複数のモジュールに分割して処理を行う形態で実現する。一方、従来のようにデータ処理を分割せずに一つのモジュールで実行する形態は、モノリシックと呼ばれる。複雑なデータ処理は１種類のデータ処理であっても、処理性能向上や冗長性確保のため複数のサーバで実行される。また、センサデータ活用目的の変更や追加、または、宛先の変更や追加は、上記複雑なデータ処理を行うＩｏＴサービスシステムに、システム変更を頻繁に要求する。

しかしながら、上述した特許文献１、２および非特許文献１の方法は、複雑なデータ処理に適用できるアーキテクチャを前提としていないため、以下の技術課題が解決できない場合がある。

第１に、複雑なデータ処理は、ボトルネック解析が困難で、ボトルネックにより、たとえば、サーバのＣＰＵやＩ／Ｏのようなリソースを十分に活用できない。また、サーバを増設しても処理性能が増設台数に比例して伸びないため、サーバ増設による性能拡張を前提とする分散処理システムにおいて大きな課題となる。

第２に、複雑なデータ処理は、複数のモジュールに分割され、各データ処理が関連して、一連のデータ処理が完了する（以下、一連のデータ処理の流れをデータフローとする）。たとえば、前述の電力分野のＩｏＴサービスシステムは、スマートメータから集めたメッセージのプロトコル変換処理、複数のメッセージから地域別の統計情報を出力する処理、複数のメッセージから時間別の統計情報を出力する処理、ＨＥＭＳから集めたメッセージのプロトコル変換処理、ＨＥＭＳからのメッセージとスマートメータからのメッセージとの付き合せ処理といった複数種類のデータ処理を組み合わせたデータフローを用いる。そして、電力分野のＩｏＴサービスシステムは、このデータフローにより、電力会社、一般の電力供給者、電力の需給業者といった宛先毎に異なるデータ処理を実現する。

ここで、一つのデータ処理の設定変更や処理変更を行った結果、変更前後で消費するリソース量が異なると、上記複雑に関連している各データ処理のリソース消費のバランスが変化し、新たなボトルネックが発生する。これにより、負荷分散設計とチューニング作業が必要になる。

第３に、特許文献１の方法を上記複雑なデータ処理に適用した技術は、最初のボトルネックであるデータ処理に残りのリソースを全て消費してしまい、ＩｏＴサービスシステムのスループットを最大化できない場合がある。また、特許文献１は、１サーバ内のリソース管理に言及しており、複数のサーバで構成されたシステムについては言及していない。特許文献２および非特許文献１の方法も、１種類のデータ処理を対象としているため、上記複雑なデータ処理のボトルネック解消に言及していない。

本発明は、複数種類のデータ処理が混在するデータフロー群のスループットの向上を図ることを目的とする。

本願において開示される発明の一側面となるデータ処理システムおよびデータ処理方法は、送信元からのメッセージに対しデータ処理を実行して宛先に送信するデータ処理システムおよびデータ処理方法であって、前記データ処理が異なる複数種類のデータ処理部の各々を１以上有し、前記メッセージに対し種類が異なる一連のデータ処理を実行して前記一連のデータ処理後のメッセージを前記宛先に送信する複数のデータフローについて、前記送信元からのメッセージに指定されるデータフローにしたがって、当該メッセージおよび前記データ処理部によるデータ処理後のメッセージを後続のデータ処理部に振り分ける振分部を有し、前記振分部は、前記複数のデータフローを流れるメッセージの滞留量と前記データ処理のリソース情報とに基づいて、ボトルネックまたはボトルネックとなり得る特定の状態である特定のデータ処理部を検出する検出処理と、前記検出処理によって検出された特定のデータ処理部のリソース情報に基づいて、前記特定のデータ処理部の台数の増加により前記特定のデータ処理部が前記特定の状態から解消される台数に決定する決定処理と、前記特定のデータ処理部を、前記決定処理によって決定された前記特定の状態から解消される台数分設定する設定処理と、を実行することを特徴とする。

本発明の代表的な実施の形態によれば、複数種類のデータ処理が混在するデータフロー群のスループットの向上を図ることができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

本実施例にかかるネットワークシステムのシステム構成例を示すブロック図である。 サーバ群の論理的な接続関係を示す説明図である。 サーバのハードウェア構成例を示すブロック図である。 サーバの記憶デバイスの記憶内容例を示す説明図である。 データフローテーブルの記憶内容例を示す説明図である。 データ処理テーブルの記憶内容例を示す説明図である。 分散システムにおけるデータ処理例を示す説明図である。 データ処理シーケンス例を示すシーケンス図である。 振分部の流量制御を行うためのフロー計算処理手順例を示すフローチャートである。 流量制御後のデータフローの一例を示す説明図である。

本実施例のデータ処理システムは、複雑なデータ処理が組み合わさったデータフロー上でメッセージのデータ処理を実行するデータ処理部の数、すなわち、リソースを制御することにより、間接的にデータフロー上を流れるメッセージの流量を制御する。これにより、データフローに発生したボトルネックを解消し、複数種類のデータ処理が混在するデータフロー群のスループットの向上を図る。ここで、メッセージは、一つ以上のパケットから構成されるデータであり、ヘッダとボディを含む。メッセージは、たとえば、携帯電話の電子メールやＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）のメッセージデータ、センサ情報、携帯電話、パーソナルコンピュータ、自動車、鉄道、工場の機器が発信するデータを含む。

また、本実施例では、たとえば、携帯電話、パーソナルコンピュータ、自動車、鉄道、工場の機器といったＩｏＴ／Ｍ２Ｍサービスのメッセージ処理を対象とし、具体例として電力のスマートメータやＨＥＭＳからのデータ処理を対象とする。

また、本実施例では、「流量」とは、単位時間あたりのメッセージ処理数である。たとえば、データ処理部の「流量」は、データ処理部において、単位時間あたりの流出メッセージ量から流入メッセージ量を引いた値であり、データフローの「流量」は、データフロー上の各データ処理部における流量の統計値（たとえば、最大値、最小値、中央値、平均値）とする。

＜システム構成＞
図１は、本実施例にかかるネットワークシステム１００のシステム構成例を示すブロック図である。ネットワークシステム１００は、１以上の通信デバイス１０１と、ロードバランサ１０３およびサーバ群ＳＶｓと、運用端末１０４と、１以上の宛先サーバ１０６と、がネットワーク１０２を介して通信可能に接続されたシステムである。

通信デバイス１０１は、サーバ群ＳＶｓのいずれかのサーバＳＶｉ（ｉはサーバを特定する番号であり、１≦ｉ≦ｎの整数。ｎは２以上の整数。）にアクセスするコンピュータである。通信デバイス１０１は、たとえば、携帯電話端末、タブレット、パーソナルコンピュータ、スマートメータ、ＨＥＭＳ、センサデバイス、車等のデータ通信可能な装置であり、取得したメッセージをサーバ群ＳＶｓに転送する。また、通信デバイス１０１は、上記データ通信可能な装置からのメッセージを収集して、当該メッセージを定期的にまとめてサーバ群ＳＶｓへ送信する中間サーバまたはゲートウェイでもよい。

ネットワーク１０２は、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などである。有線でも無線でもよい。ロードバランサ１０３は、通信デバイス１０１からのメッセージを分散して、いずれかのサーバＳＶｉに、たとえばラウンドロビンで振り分ける。

通信デバイス１０１からのメッセージは、上述したように、ヘッダとボディにより構成されるが、ヘッダは、宛先サーバのアドレス、サーバＳＶｉの受信ポート番号、および、データフローの識別子を含む。たとえば、通信デバイス１０１ごとに、どの宛先にどのデータフローを用いてメッセージを送信するかがあらかじめ設定されている。

サーバ群ＳＶｓは、複数のサーバＳＶ１〜ＳＶｎにより構成されるデータ処理システムである。各サーバＳＶｉは相互に通信可能である。サーバＳＶｉは各々、振分部Ｈｉと、記憶部ＤＳｉと、データ処理部ＤＰｉＸ（Ｘは、データ処理の種別を示すアルファベット。）と、を有する。データ処理部ＤＰｉＸについて、所属するサーバＳＶｉを区別しない場合は、データ処理部ＤＰＸと表記する。

振分部Ｈｉは、通信デバイス１０１からのメッセージやデータ処理部ＤＰＸがデータ処理Ｘをしたメッセージを、後述するデータフローにしたがって、１以上のつぎのデータ処理部ＤＰＹに振り分ける（Ｙ≠Ｘ）。ロードバランサ１０３は通信デバイス１０１からの接続（コネクション）を振り分けるだけである。振分部Ｈｉは、通信デバイス１０１からロードバランサ１０３を介して受信したメッセージを一度、記憶部ＤＳｉ上に蓄積してから各データ処理部ＤＰＸへ振り分ける。

具体的には、たとえば、振分部Ｈｉは、メッセージのヘッダに含まれているポート番号により特定されるポートでメッセージを受信し、データフローの識別子から、当該メッセージを流すデータフローを特定する。そして、振分部Ｈｉは、特定したデータフローにしたがって記憶部ＤＳｉを介してメッセージを転送する。振分部Ｈｉが受信したメッセージを保証することにより、データ処理部ＤＰＸへ流入するメッセージ量の平準化や、通信デバイス１０１への即時応答（再送確率低減や輻輳回避）を実現する。

記憶部ＤＳｉは、振分部Ｈｉからのアクセスによりメッセージを書き込んだり、振分部Ｈｉに読み出したりする。すなわち、記憶部ＤＳｉは、振分部Ｈｉからのデータの格納、更新、削除等の要求に応じて処理を実行する。記憶部ＤＳｉとしては、たとえば、分散型ＫＶＳ（Ｋｅｙ−Ｖａｌｕｅ Ｓｔｏｒｅ）であり、同一のメッセージを複製し、複数のサーバＳＶｉ上でメッセージを多重で保持し、永続性を実現する。なお、分散型ＫＶＳに限定されることなく、データグリッド、外部ストレージ、ＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）等の他の記憶装置でも実現可能である。したがって、どの記憶部ＤＳｉも同じデータを保存する。なお、記憶部ＤＳｉは、振分部Ｈｉからアクセス可能であれば、サーバＳＶｉの外部に存在してもよい。

データ処理部ＤＰｉＸは、サーバＳＶｉ内のデータ処理Ｘを実行するソフトウェアモジュールである。Ｘが同一であるデータ処理部ＤＰｉＸは、同種のデータ処理Ｘを実行する。たとえば、サーバＳＶｉ内のデータ処理部ＤＰｉＡ，ＤＰｉＢ，…は、異なるデータ処理Ａ，Ｂを実行し、サーバＳＶ１〜ＳＶｎのデータ処理部ＤＰ１Ａ，…，ＤＰｉＡ，…，ＤＰｎＡは、同種のデータ処理Ａを実行する。

また、複数のメッセージから地域別の統計情報を出力するデータ処理と、複数のメッセージから時間別の統計情報を出力するデータ処理とは、異なるデータ処理である。また、スマートメータから集めたメッセージのプロトコル変換処理と、ＨＥＭＳから集めたメッセージのプロトコル変換処理とは、異なるデータ処理である。なお、同一サーバＳＶｉ内で同種のデータ処理部ＤＰｉＸは複数存在してもよい。この場合、データ処理部ＤＰｉ−１Ｘ，ＤＰｉ−２Ｘ，…というように、枝番で表記する。

サーバＳＶｉには他にもプログラムが存在するが、そのようなプログラムを除外する意図はない。サーバＳＶｉは、物理サーバでも仮想サーバでもよい。ＩｏＴサービスでは、たとえば、オンプレミスでサーバリソースが限られている場合は、振分部Ｈｉと記憶部ＤＳｉとデータ処理部ＤＰｉＸとを同一サーバＳＶｉ内にサーバプログラムとして実現することが多く、一方データセンタ内のようなクラウド環境では、振分部Ｈｉと記憶部ＤＳｉとデータ処理部ＤＰｉＸとを仮想マシンまたは物理サーバとして実現することが多い。なお、本実施例のシステム構成は、図１に限定されること無く、他の構成のメッセージングシステムにも適用可能である。

データ処理部ＤＰＸは、データ処理Ｘを実行し、データ処理Ｘをしたメッセージをデータフローにしたがって振分部Ｈｉまたは宛先サーバ１０６に送信する。データ処理部ＤＰＸは、メッセージの入出力を備えるソフトウェアであれば適用可能である。データ処理部ＤＰＸとしては、たとえば、不図示のＲＤＢ（リレーショナルデータベース）、メールボックス、オンラインストレージシステム、ユーザ情報の管理サーバ等の制御プログラムが挙げられる。

なお、データ処理部ＤＰＸは、同種のプログラムであれば、バージョンが異なっていてもよいし、互換性を持つ異なるプログラムを複数いれてもよい（例えば、データベースのように共通のアクセスプロトコル（ＳＱＬ）をもつデータ処理部ＤＰＸであって、プログラム自体は別の場合でもよい。）。これらは、データ処理部ＤＰＸのバージョンアップ時の不具合抽出や、データ処理部ＤＰｉＸを変更する際の過渡期の不具合抽出に利用することができる。

これにより、通信デバイス１０１からのメッセージ（たとえば、ＳＱＬ文）に含まれるデータは、振分部Ｈｉを介して複数の記憶部ＤＳｉに書き込まれるため、データ処理部ＤＰｉＸを非改造のままデータをｎ重化することができる。

宛先サーバ１０６は、サーバ群ＳＶｓと接続し、データ処理部ＤＰＸから送信されたメッセージを受信する。例えば、電力の例では、宛先サーバ１０６は、スマートメータやＨＥＭＳからのメッセージを活用する電力会社のシステム、一般の電力供給者のシステム、電力の需給業者のシステムである。

＜サーバ群ＳＶｓの論理的な接続関係＞
図２は、サーバ群ＳＶｓの論理的な接続関係を示す説明図である。図３に示すように、振分部Ｈｉは、記憶部ＤＳｉにアクセス可能である。振分部Ｈｉおよびデータ処理部ＤＰｉＸは、相互にアクセス可能である。

＜サーバＳＶｉのハードウェア構成例＞
図３は、サーバＳＶｉのハードウェア構成例を示すブロック図である。サーバＳＶｉは、プロセッサ３０１と、記憶デバイス３０２と、入力デバイス３０３と、出力デバイス３０４と、通信インターフェース（通信ＩＦ３０５）と、を有する。プロセッサ３０１、記憶デバイス３０２、入力デバイス３０３、出力デバイス３０４、および通信ＩＦ３０５は、バス３０６により接続される。プロセッサ３０１は、サーバＳＶｉを制御する。記憶デバイス３０２は、プロセッサ３０１の作業エリアとなる。また、記憶デバイス３０２は、各種プログラムやデータを記憶する非一時的なまたは一時的な記録媒体である。記憶デバイス３０２としては、たとえば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、フラッシュメモリがある。また、記憶デバイスの一部には、記憶部ＤＳｉが含まれる。

入力デバイス３０３は、データを入力する。入力デバイス３０３としては、たとえば、キーボード、マウス、タッチパネル、テンキー、スキャナがある。出力デバイス３０４は、データを出力する。出力デバイス３０４としては、たとえば、ディスプレイ、プリンタがある。通信ＩＦ３０５は、ネットワーク１０２と接続し、データを送受信する。

＜記憶デバイス３０２＞
図４は、サーバＳＶｉの記憶デバイス３０２の記憶内容例を示す説明図である。記憶デバイス３０２は、プログラム格納領域４０１とデータ領域４０２とを含む。プログラム格納領域４０１には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）４１１と、振分プログラム４１２と、記憶プログラム４１３と、データ処理プログラム４１４と、が格納される。

振分プログラム４１２は、プロセッサ３０１により実行されることで、振分部Ｈｉとして機能する。記憶プログラム４１３は、プロセッサ３０１により実行されることで、記憶部ＤＳｉを制御する。データ処理プログラム４１４は、プロセッサ３０１により実行されることで、データ処理部ＤＰｉＸとして機能する。

なお、本明細書の説明で、振分部Ｈｉ、記憶部ＤＳｉ、およびデータ処理部ＤＰｉＸの各処理については、便宜的に振分部Ｈｉ、記憶部ＤＳｉ、およびデータ処理部ＤＰｉＸを主語にして説明するが、実際には、上述したように、振分プログラム４１２、記憶プログラム４１３、およびデータ処理プログラム４１４をプロセッサ３０１に実行させることで、振分部Ｈｉ、記憶部ＤＳｉ、およびデータ処理部ＤＰｉＸの各処理が実行されることになる。また、各プログラムやその機能を便宜的に主語にして説明することもある。

データ領域４０２には、データフローテーブル４３１と、データ処理テーブル４３２と、メッセージ状態テーブル４３３と、過去リソース情報４３４と、キューＱｉＸと、が格納される。また、データ領域４０２は、データ処理記憶領域４５０を有する。

データフローテーブル４３１は、データフローを規定するテーブルである。データフローとは、メッセージが経由するデータ処理部ＤＰｉＸを規定するテーブルである。データフローテーブル４３１の詳細については、図５で後述する。

データ処理テーブル４３２は、データ処理部ＤＰｉＸを管理するテーブルである。データ処理テーブル４３２の詳細については、図６で後述する。

メッセージ状態テーブル４３３は、データフロー上を流れるメッセージの状態を管理するテーブルである。具体的には、たとえば、メッセージ状態テーブル４３３には、キューに滞留中のメッセージがこれまでどのキューおよびデータ処理部ＤＰｉＸを経由してきたかを示すログを格納する。

過去リソース情報４３４は、データ処理部ＤＰｉＸごとの過去のリソース値を格納する。リソース値は、たとえば、ＣＰＵ使用率やＣＰＵ処理時間であり、後述するデータフローテーブル４３１のリソース値が更新される際に、更新前のリソース値が格納される。

キューＱｉＸは、いわゆるＦＩＦＯメモリである。キューＱｉＸは、キュー管理情報４４０を有し、振分部Ｈｉやデータ処理部ＤＰｉＸからのメッセージを保持し、格納順にメッセ―ジを出力する。キューＱｉＸは、データ処理テーブル４３２により、データ処理部ＤＰｉＸと関連付けられる。各サーバＳＶｉでは、キューＱｉＸは、対応するデータ処理部ＤＰｉＸにメッセージを出力する。

キュー管理情報４４０は、キューＱｉＸのキュー長と、キューＱｉＸに格納されたメッセージのメッセージ数と、キューＱｉＸへ流入する流入メッセージ量と、キューＱｉＸから流出する流出メッセージ量と、つぎに送られるキューＱＹを指定する情報と、を管理する。なお、メッセージ数のかわりに、キューＱｉＸに滞留中のメッセージの量（滞留メッセージ量）でもよい。１メッセージのサイズが固定であれば、メッセージ数でよい。ただし、当該サイズは、キュー管理情報４４０で管理されるものとする。

キューＱｉＸに流入するメッセージは、メッセージ情報４４１とメッセージメタ情報４４２という組み合わせでキューＱｉＸ内に滞留する。メッセージ情報４４１は、メッセージのヘッダおよびボディである。メッセージメタ情報４４２は、キューＱｉＸに滞留中のメッセージがこれまでどのキューＱｉＸおよびデータ処理部ＤＰｉＸを経由してきたかを示すログである。すなわち、上述したメッセージ状態テーブル４３３に格納される情報は、厳密にはログ自体ではなく、メッセージメタ情報４４２を呼び出すためのポインタである。当該ポインタは、メッセージがキューＱｉＸに流入したタイミングで記憶プログラム４１３により生成される。

なお、本例では、各サーバＳＶｉの記憶部ＤＳｉは、データ処理ＸごとにキューＱｉＸを保持する例としたが、データ処理Ｘごとではなく、１つのキューＱｉを保持することとしてもよい。

データ処理記憶領域４５０は、データ処理プログラム４１４がメッセージを処理するワークエリアである。

振分プログラム４１２は、振分機能４２１、キュー管理機能４２２、データフロー計算機能４２３、データフロー登録機能４２４、メッセージ状態管理機能４２５といったプログラムモジュールを含む。

振分機能４２１は、通信デバイス１０１から受信したメッセージに含まれるデータフローの識別子（フローＩＤ）から、当該メッセージを流すデータフローを特定する。振分機能４２１は、通信デバイス１０１から受信したメッセージを、特定したデータフロー上の送信先となる各データ処理部ＤＰＸにアクセスする記憶部ＤＳｉ内のキューＱｉＸに格納する。また、振分機能４２１は、各データ処理部ＤＰＸによってデータ処理されたデータ処理後のメッセージを当該各データ処理部ＤＰＸから受信する。

そして、振分機能４２１は、受信した各メッセージを、データフロー上の送信先となるデータ処理部ＤＰＹにアクセスするキューＱＹに格納する。ＹはＸとは異なるアルファベット、すなわち、異種のデータ処理であることを示す。

キュー管理機能４２２は、キュー管理情報４４０で管理されている情報に基づいて、キューＱＸに対応するデータ処理部ＤＰＸがボトルネックであるか否か、または、ボトルネックになり得るか否かを判断する。具体的には、たとえば、キュー管理機能４２２は、メッセージの滞留量がキューＱＸのキュー長の８０％に達した場合、ボトルネックになり得ると判断し、９０％に達した場合、ボトルネックであると判断する。また、キュー管理機能４２２は、流入メッセージ量（または流入メッセージ量から流出メッセージ量を引いたメッセージ量）がキューＱＸの空き容量よりも大きい場合に、ボトルネックであると判断してもよい。

データフロー計算機能４２３は、データフローテーブル４３１と、データ処理テーブル４３２と、キュー管理情報４４０と、を用いて、振分機能４２１が行う振分処理を制御するための動的な設定値である流量制御値を決定する。流量制御値を計算する処理をフロー計算と呼び、詳細は図９で説明する。

データフロー計算機能４２３は、サーバリソースの有効利用および処理性能をスケールアウトすることを実現するために、流量制御値を動的に計算して、その結果をデータ処理テーブル４３２に格納する。

データフロー登録機能４２４は、運用端末１０４からの操作により、データフローテーブル４３１に、データ処理部ＤＰＸを経由するメッセージの流れであるデータフローを登録する。

メッセージ状態管理機能４２５は、各メッセージがどのデータ処理部ＤＰＸで処理中であるかを示す情報をメッセージメタ情報４４２に追加する。

記憶プログラム４１３は、記憶部ＤＳｉを制御するプログラムである。具体的には、たとえば、記憶プログラム４１３は、メッセージをキューＱｉＸに格納したり、キューＱｉＸからメッセージを出力したり、キュー管理情報４４０を格納したり、メッセージメタ情報４４２を生成したり、メッセージ状態テーブル４３３にポインタを生成したりする。

データ処理プログラム４１４はメッセージを処理するプログラムである。具体的には、たとえば、データ処理プログラム４１４は、メッセージのプロトコル変換処理、複数のメッセージから地域別の統計情報を出力する処理、複数のメッセージから時間別の統計情報を出力する処理、メッセージ同士を突き合わせる処理、圧縮処理、伸長処理、暗号化処理、復号処理など各種データ処理を実行する。

＜データフローテーブル４３１＞
図５は、データフローテーブル４３１の記憶内容例を示す説明図である。データフローテーブル４３１は、フィールドとして、フローＩＤフィールド５０１と、フロー定義フィールド５０２と、フロー要件フィールド５０３と、優先度フィールド５０４と、流量目標値フィールド５０５と、流量現在値フィールド５０６と、リソース値フィールド５０７と、を有し、各フィールドの値によりデータフローを規定するエントリを構成する。以降、○○フィールドｘｘｘ（○○はフィールド名、ｘｘｘは符号）の値も、○○ｘｘｘと表記する。たとえば、フローＩＤフィールド５０１の値であるフローＩＤを、フローＩＤ５０１と表記する。

フローＩＤフィールド５０１は、値として、データフローの識別子であるフローＩＤ５０１を格納する記憶領域である。フロー定義フィールド５０２は、値として、データフローの定義情報であるフロー定義５０２を格納する記憶領域である。たとえば、フロー定義５０２：「Ａ−Ｃ−Ｄ」は、データ処理部ＤＰＡ→データ処理部ＤＰＣ→データ処理部ＤＰＤを経由して、データ処理Ｄ後のメッセージを宛先サーバ１０６に配信するデータフローを意味する。

フロー要件フィールド５０３は、値として、フロー要件５０３を格納する記憶領域である。フロー要件５０３とは、データフローに求められる性能を規定する要件である。フロー要件５０３には、たとえば、サーバＳＶｉの振分部Ｈｉが通信デバイス１０１からメッセージを受信し、宛先サーバ１０６へメッセージが配信されるまでの時間や、通信デバイス１０１への応答時間がある。

優先度フィールド５０４は、値として、優先度５０４を格納する記憶領域である。優先度５０４は、複数のデータフロー中での優先順位を示す値である。優先度５０４は、後述するフロー計算でリソースを融通する場合に利用される。フローＩＤフィールド５０１〜優先度フィールド５０４の値は、運用端末１０４からあらかじめ設定される。

流量目標値フィールド５０５は、値として、流量目標値５０５を格納する記憶領域である。流量目標値５０５は、後述するデータ処理テーブル４３２を元に計算される値であり、フロー定義５０２で規定されるデータフローでのメッセージ流量の目標値である。流量目標値５０５は、データフロー計算機能４２３により動的に変更される。たとえば、流量目標値５０５は、データフロー上のデータ処理部ＤＰｉＸの流量制御値（後述する流量制御情報フィールド６０５の値）の統計値（たとえば、最大値、最小値、中央値、平均値）が採用される。ただし、振分部Ｈｉが制御する流量制御値はデータ処理部ＤＰｉＸ単位である。流量目標値５０５は、運用者への表示に利用される。

流量現在値フィールド５０６は、値として、流量現在値５０６を格納する記憶領域である。流量現在値５０６は、キュー管理情報４４０から取得した現在のメッセージ流量であり、定期的に更新される。流量現在値５０６は、データフローの現在流量であるため、データフロー上の各データ処理部ＤＰｉＸの現在流量の統計値（たとえば、最大値、最小値、中央値、平均値）が採用される。

リソース値フィールド５０７は、値として、リソース値５０７を格納する記憶領域である。リソース値５０７は、このデータフローが使用しているリソースの値である。リソースは、たとえば、ＣＰＵ使用率、ディスクやネットワークＩ／Ｏ処理数を含む。リソース値５０７は、たとえば、振分部Ｈｉが、データフローを構成する各データ処理部ＤＰＸの現在のリソースの値を収集して合計した値をリソース値５０７としてリソース値フィールド５０７に格納する。振分部Ｈｉは、更新前のリソース値５０７を、過去リソース情報に格納する。

＜データ処理テーブル４３２＞
図６は、データ処理テーブル４３２の記憶内容例を示す説明図である。データ処理テーブル４３２は、キューＱＸごとにサーバＳＶｉ内のデータ処理部ＤＰｉＸを管理するテーブルである。データ処理テーブル４３２は、キューＩＤフィールド６０１と、処理名フィールド６０２と、リソース要件フィールド６０３と、処理優先度フィールド６０４と、流量制御情報フィールド６０５と、流量現在値フィールド６０６と、リソース値フィールド６０７と、プロトコル情報フィールド６０８と、を有し、各フィールドの値によりサーバＳＶｉが管理するデータ処理部ＤＰｉＸの状態をキューＱＸごとに規定するエントリを構成する。

キューＩＤフィールド６０１は、キューＩＤ６０１を格納する記憶領域である。キューＩＤ６０１は、キューＱＸを一意に特定する識別情報である。キューＱＸは、他サーバＳＶｊ（ｊ≠ｉ）内のキューＱｊＸであってもよい。処理名フィールド６０２は、処理名６０２を格納する記憶領域である。処理名６０２は、キューＱＸからのデータを処理するデータ処理部ＤＰｉＸのデータ処理Ｘ、または、キューＱＸからのデータを受信する宛先サーバ１０６への配信処理の種別を一意に特定する識別情報である。キューＩＤ６０１と処理名６０２との組み合わせは、キューＱＸとデータ処理部ＤＰｉＸとを関連付ける。

リソース要件フィールド６０３は、リソース要件６０３を格納する記憶領域である。リソース要件６０３とは、処理名６０２により特定されるデータ処理部ＤＰｉＸに要求される性能を規定する要件である。たとえば、リソース要件６０３が「自サーバ」である場合は、同種のデータ処理部ＤＰｉＸを自サーバＳＶｉに分散することを意味し、「他サーバ」である場合は、同種のデータ処理部ＤＰｉＸを他サーバＳＶｊに分散することを意味する。

また、リソース要件６０３に「（自動拡張可）」がある場合は、データ処理部ＤＰｉＸの分散に際し、振分部Ｈｉまたは運用者は、運用機能との連携により拡張可能、すなわち、物理的または仮想的に増設可能であることを意味する。リソース要件６０３に「（自動拡張不可）」がある場合は、データ処理部ＤＰｉＸの分散に際し、上記自動拡張ができないことを意味する。この場合、自サーバＳＶｉおよび他サーバＳＶｊにおける既存のデータ処理部ＤＰｉＸにより不足分のリソースを補うことになる。

処理優先度フィールド６０４は、処理名６０２により特定されるデータ処理部ＤＰｉＸの処理優先度６０４を格納する記憶領域である。処理優先度６０４は、データ処理テーブル４３２のエントリ間のデータ処理部ＤＰｉＸの優先度を示す。本例では、処理優先度６０４の数値が高い方が優先順位が高い。

流量制御情報フィールド６０５は、流量制御情報６０５を格納する記憶領域である。流量制御情報６０５は、同一処理名６０２、すなわち同種のデータ処理部ＤＰｉＸの分散先数と流量制御値との組み合わせである。分散先数とは、同種のデータ処理部ＤＰｉＸで並行処理させる、すなわち、振分部Ｈｉから分散させるデータ処理部ＤＰｉＸの台数である。流量制御値は、振分部Ｈｉが制御する値である。流量制御値は、キューＱｉＸから分散先数分のデータ処理部ＤＰｉＸへのメッセージ流量の目標値である。たとえば、流量現在値５０６，６０６が流量制御値未満であれば、振分部Ｈｉは、データ処理部ＤＰｉＸにメッセージを送信することができる。流量制御情報６０５は、データフロー計算機能４２３により動的に変更される。

分散先数は、言い換えれば、振分部Ｈｉが、同時に何台の同種のデータ処理部ＤＰＸで処理させるかということを意味しており、これにより、振分部Ｈｉはデータ処理部ＤＰＸの同時処理数の制御を可能にする。データ処理部ＤＰＸが分散先数よりも多く存在する場合、すなわち、利用されていないデータ処理部ＤＰＸが存在する場合、分散先数の増加により、どのサーバＳＶｉでもデータ処理部ＤＰＸの処理が実行可能となる。逆に、データ処理部ＤＰＸが分散先数以下である場合は、サーバ群ＳＶｓ内で利用されていないデータ処理部ＤＰＸの台数を参照してデータ処理部ＤＰＸの台数が分散先数を超えないように増加される。また、データ処理部ＤＰＸが不足する場合は、新たにデータ処理部ＤＰＸをデプロイ、またはデータ処理システムの運用機能により自動増設することが必要である。

流量現在値フィールド６０６は、流量現在値６０６を格納する記憶領域である。流量現在値６０６とは、データ処理部ＤＰｉＸへ流入する現在のメッセージ流量である。流量現在値６０６は、キュー管理情報４４０から取得される。

リソース値フィールド６０７は、リソース値６０７を格納する記憶領域である。リソース値６０７は、処理名６０２により特定されるデータ処理部ＤＰｉＸが使用しているリソースの値である。リソースは、たとえば、ＣＰＵ使用率、ディスクやネットワークＩ／Ｏ処理数を含む。リソース値６０７は、振分部Ｈｉが直接収集したデータ処理部ＤＰｉＸのリソースの現在値でもよいし、データ処理部ＤＰｉＸの特性や処理内容からデータ処理部ＤＰｉＸのリソースの現在値を算出してもよい。

プロトコル情報フィールド６０８は、プロトコル情報６０８を格納する記憶領域である。プロトコル情報６０８は、振分部Ｈｉが処理名６０２により特定されるデータ処理部ＤＰｉＸへメッセージを送信するときのプロトコルと、当該メッセージの送信方法に関する設定情報とを含む。データ処理部ＤＰｉＸの種類ごとに入力プロトコルが異なるため、振分部Ｈｉがプロトコル情報６０８に対応したプロトコルに変換してメッセージの振分処理を行う。また、メッセージの送信方法にも種類がある。たとえば、振分部Ｈｉからデータ処理部ＤＰｉＸへメッセージが到着したことを示す通知を送り、データ処理部ＤＰｉＸが当該通知をトリガーにメッセージを取得しにくる方式がある。また、振分部Ｈｉからデータ処理部ＤＰｉＸへメッセージを直接送信する方式がある。また、データ処理部ＤＰｉＸが定期的に振分部Ｈｉへアクセスするポーリング方式がある。設定情報は、このような方式を示す識別情報である。

＜データ処理例＞
図７は、分散システムにおけるデータ処理例を示す説明図である。図７では、「Ａ→Ｂ」、「Ａ→Ｃ→Ｄ」、「Ａ→Ｃ→Ｆ」、「Ｅ→Ｆ」の４つのデータフローを示す。各データ処理部ＤＰＡ〜ＤＰＦは、サーバ群ＳＶｓにおいて１台以上用意される。たとえば、図７の例では、データ処理部ＤＰＡ、ＤＰＢはそれぞれ２台、データ処理部ＤＰＣ〜ＤＰＦはそれぞれ３台である。同種の複数のデータ処理部ＤＰＸは、同一サーバＳＶｉに存在してもよいし、異なるサーバＳＶｊに存在してもよい。ただし、データ処理テーブル４３２のリソース要件６０３に従う。また、各データ処理部ＤＰＸは複数存在するが、あるデータ処理部ＤＰＸに着目して説明する。また、図７では、データフロー「Ａ→Ｂ」に着目して説明する。

振分部Ｈｉは、各データ処理部ＤＰＸとキューＱＸとを対応させて、その対応関係をデータフローテーブル４３１およびデータ処理テーブル４３２で管理する。最初に、振分部Ｈｉは、通信デバイス１０１−１から受信したメッセージをキューＱＡに格納する。次に、データ処理部ＤＰＡが、振分部Ｈｉを介してキューＱＡからメッセージを取出し、データ処理Ａを実行する。

データ処理部ＤＰＡは、データフロー「Ａ→Ｂ」にしたがってデータ処理部ＤＰＢに対応するキューＱＢを指定するとともに、「Ａ→Ｃ→Ｄ」および「Ａ→Ｃ→Ｆ」にしたがってデータ処理部ＤＰＣに対応するキューＱＣを指定する。振分部Ｈｉは、指定されたキューＱＢ，ＱＣにデータ処理Ａ後のメッセージを送信する。キューＱＢ、ＱＣは、送信されてくるメッセージを格納する。

データ処理部ＤＰＢは、振分部Ｈｉを介してキューＱＢからメッセージを取出し、データ処理Ｂを実行する。そして、データ処理部ＤＰＢは、データ処理Ｂ後のメッセージを宛先サーバ１０６−１へ送信する。データフロー「Ａ→Ｃ→Ｄ」、「Ａ→Ｃ→Ｆ」、「Ｅ→Ｆ」についても同様に処理される。なお、データ処理部ＤＰＦは、データ処理部ＤＰＣでデータ処理Ｃされたメッセージと、データ処理部ＤＰＥでデータ処理Ｅされたメッセージとを用いて、データ処理Ｆを実行する。

＜キューＱＸとデータ処理部ＤＰＸとの関係＞
ここで、キューＱＸとデータ処理部ＤＰＸとの関係について説明する。たとえば、通信デバイス１０１からの同一データフロー「Ａ→Ｂ」を指定する一連のメッセージを受信したサーバＳＶｉをサーバＳＶ１（ｉ＝１）とする。データフロー「Ａ→Ｂ」は、データ処理部ＤＰＡでデータ処理Ａを実行して、データ処理Ａ後のメッセージをデータ処理部ＤＰＢに与えてデータ処理Ｂを実行し、データ処理Ｂ後のメッセージを宛先サーバ１０６に送信するデータフローを意味する。

例として、データ処理部ＤＰＡを、４台のデータ処理部ＤＰ１−１Ａ，ＤＰ１−２Ａ，ＤＰ２Ａ，ＤＰ３Ａとする。データ処理部ＤＰＢを、２台のデータ処理部ＤＰ１Ｂ、ＤＰ２Ｂとする。

第１の例は、あるサーバＳＶｉのキューＱｉＸとデータ処理部ＤＰＸとが対応する例である。たとえば、サーバＳＶ１は、受信した一連のメッセージＭ１〜Ｍ４を振分部Ｈ１によりキューＱ１Ａに格納する。振分部Ｈ１は、キューＱ１Ａから一連のメッセージＭ１〜Ｍ４を入力順に取り出す。振分部Ｈ１は、たとえば、キューＱ１Ａから取り出したメッセージＭ１をデータ処理部ＤＰ１−１Ａに、つぎのメッセージＭ２をデータ処理部ＤＰ１−２Ａに、そのつぎのメッセージＭ３をＤＰ２Ａに、そのつぎのメッセージＭ４をＤＰ３Ａに振り分ける。

データフロー「Ａ→Ｂ」上のつぎのデータ処理Ｘはデータ処理Ｂであるため、４台のデータ処理部ＤＰ１−１Ａ、ＤＰ１−２Ａ，ＤＰ２Ａ，ＤＰ３Ａは、キューＱＢを指定して、データ処理Ａ後のメッセージＭ１〜Ｍ４（以降、メッセージＭ１Ａ〜Ｍ４Ａとする）を振分部Ｈ１に返す。振分部Ｈ１は、キューＱＢとして自サーバＳＶ１のキューＱ１Ｂを指定し、当該キューＱ１ＢにメッセージＭ１Ａ〜Ｍ４Ａを格納する。

振分部Ｈ１は、キューＱ１ＢからメッセージＭ１Ａ〜Ｍ４Ａを順次取出し、メッセージＭ１Ａをデータ処理部ＤＰ１Ｂに振り分け、メッセージＭ２Ａをデータ処理部ＤＰ２Ｂに振り分け、メッセージＭ３Ａをデータ処理部ＤＰ１Ｂに振り分け、メッセージＭ４Ａをデータ処理部ＤＰ２Ｂに振り分ける。

データ処理部ＤＰ１Ｂは、データ処理ＢをしたメッセージＭ１Ａ，Ｍ３Ａ（以降、メッセージＭ１Ｂ，Ｍ３Ｂとする）を宛先サーバ１０６に送信し、データ処理部ＤＰ２Ｂは、データ処理ＢをしたメッセージＭ２Ａ，Ｍ４Ａ（以降、メッセージＭ２Ｂ，Ｍ４Ｂとする）を宛先サーバ１０６に送信する。

第２の例は、所属するサーバＳＶｉのキューＱｉＸおよびデータ処理部ＤＰｉＸどうしが対応する例である。たとえば、サーバＳＶ１は振分部Ｈ１により、受信した一連のメッセージＭ１〜Ｍ４のうち、メッセージＭ１、Ｍ２をキューＱ１Ａに、メッセージＭ３をサーバＳＶ２のキューＱ２Ａに、メッセージＭ４をキューＱ３Ａに格納する。振分部Ｈ１は、キューＱ１Ａから一連のメッセージＭ１、Ｍ２を入力順に取り出す。振分部Ｈ１は、キューＱ２ＡからメッセージＭ３を取り出す。振分部Ｈ１は、キューＱ３ＡからメッセージＭ４を取り出す。

振分部Ｈ１は、たとえば、キューＱ１Ａから取り出したメッセージＭ１をデータ処理部ＤＰ１−１Ａに、つぎのメッセージＭ２をデータ処理部ＤＰ１−２Ａに振り分ける。

振分部Ｈ１は、キューＱ２Ａから取り出したメッセージＭ３をデータ処理部ＤＰ２Ａに振り分ける。振分部Ｈ１は、キューＱ３Ａから取り出したメッセージＭ４をデータ処理部ＤＰ３Ａに振り分ける。

データフロー「Ａ→Ｂ」上のつぎのデータ処理Ｘはデータ処理Ｂであるため、データ処理部ＤＰ１−１Ａ、ＤＰ１−２ＡはキューＱ１Ｂを指定して、データ処理Ａ後のメッセージＭ１Ａ、Ｍ２Ａを振分元の振分部Ｈ１に返す。データ処理部ＤＰ２ＡはキューＱ２Ｂを指定して、データ処理Ａ後のメッセージＭ３Ａを振分元の振分部Ｈ１に返す。データ処理部ＤＰ３ＡはキューＱ３Ｂを指定して、データ処理Ａ後のメッセージＭ４Ａを振分元の振分部Ｈ１に返す。

振分部Ｈ１は、キューＱＢとしてサーバＳＶ１のキューＱ１Ｂを指定し、当該キューＱ１ＢにメッセージＭ１Ａ，Ｍ２Ａを格納する。振分部Ｈ１は、キューＱＢとしてサーバＳＶ２のキューＱ２Ｂを指定し、当該キューＱ２ＢにメッセージＭ３Ａを格納する。振分部Ｈ１は、キューＱＢとしてサーバＳＶ３のキューＱ３Ｂを指定し、当該キューＱ３ＢにメッセージＭ４Ａを格納する。

振分部Ｈ１は、キューＱ１ＢからメッセージＭ１Ａ，Ｍ２Ａを順次取出し、メッセージＭ１Ａをデータ処理部ＤＰ１Ｂに振り分け、メッセージＭ２Ａをデータ処理部ＤＰ２Ｂに振り分ける。振分部Ｈ１は、キューＱ２ＢからメッセージＭ３Ａを取出し、メッセージＭ３Ａをデータ処理部ＤＰ１Ｂに振り分ける。振分部Ｈ１は、キューＱ３ＢからメッセージＭ４Ａを取出し、メッセージＭ４Ａをデータ処理部ＤＰ２Ｂに振り分ける。

データ処理部ＤＰ１Ｂは、データ処理ＢをしたメッセージＭ１Ｂ，Ｍ３Ｂを宛先サーバ１０６に送信し、データ処理部ＤＰ２Ｂは、データ処理ＢをしたメッセージＭ２Ｂ，Ｍ４Ｂを宛先サーバ１０６に送信する。

なお、第１の例および第２の例は、あくまでもキューＱＸとデータ処理部ＤＰＸとの関係の例示であり、整合性が取れる範囲であれば、他の例でもよい。たとえば、第１の例および第２の例では、通信デバイス１０１からメッセージを受信したサーバＳＶ１の振分部Ｈ１が振分処理を実行したが、メッセージを保持するキューＱｉＸと同一サーバＳＶｉの振分部Ｈｉが当該メッセージを振り分けてもよい。

＜データ処理シーケンス＞
図８は、データ処理シーケンス例を示すシーケンス図である。図８では、実際は振分部Ｈｉによる記憶部ＤＳｉのキューＱｉへのメッセージ格納や各種テーブル操作でアクセスを行うが、シーケンスの単純化のため、記憶部ＤＳｉへの操作を振分部Ｈｉの処理として記述し、記憶部ＤＳｉをシーケンスからは割愛する。図８では、図７に示したデータフロー「Ａ→Ｂ」を用いて説明する。

通信デバイス１０１−１は、宛先サーバ１０６−１を宛先としてメッセージを送信する（ステップＳ８０１）。当該メッセージを受信したロードバランサ１０３は、振分部Ｈｉに当該メッセージを振り分ける。

振分部Ｈｉは、ロードバランサ１０３からのメッセージを受信し、振分機能４２１により、メッセージに含まれているフローＩＤ５０１から、当該メッセージを流すデータフローを特定する。振分部Ｈｉは、振分機能４２１を用いて、メッセージを、フローＩＤ５０１で特定したデータフロー「Ａ→Ｂ」上の送信先となる各データ処理部ＤＰＡにアクセスするキューＱＡに格納する（ステップＳ８０２）。また、振分部Ｈｉは、キュー管理情報４４０に含まれるメッセージ数やキューＱＡへの流入メッセージ数を更新する。そして、振分部Ｈｉは、通信デバイス１０１−１へ正常応答を送信する（ステップＳ８０３）。

振分部Ｈｉは、特定したデータフローに対応するデータフローテーブル４３１の流量現在値５０６と、データ処理テーブル２３２の流量制御情報６０５の流量制御値および流量現在値６０６とを参照し、流量現在値５０６，６０６がそれぞれ流量制御値未満であるか否かを判定する。流量現在値５０６，６０６がともに流量制御値未満であれば、振分部Ｈｉはデータ処理部ＤＰＡにメッセージを送信可能であると判定し、そうでなければ、送信不可と判定する（ステップＳ８０４）。以下、このような処理を流量制御判定と称す。

なお、流量制御判定（ステップＳ８０４）において、流量現在値５０６，６０６がそれぞれ流量制御値未満であるか否かを判定することとしたが、流量現在値５０６，６０６のいずれか一方が流量制御値未満であるか否かを判定するだけでもよい。

流量制御判定（ステップＳ８０４）において送信可能と判定された場合、振分部Ｈｉは、データ処理テーブル２３２のプロトコル情報５０８に基づいて、メッセージがキューＱＡに到着したことを示す到着通知をデータ処理部ＤＰＡに送信する（ステップＳ８０５）。

なお、流量制御判定（ステップＳ８０４）において送信不可と判定された場合、振分部Ｈｉは流量制御判定で送信可能になるまで、到着通知の送信（ステップＳ８０５）を遅らせる。たとえば、１秒単位でメッセージ量の上限が規定されている場合は、振分部Ｈｉは、１秒後に流量制御判定（ステップＳ８０４）を再実行する。

データ処理部ＤＰＡは、到着通知を受信する（ステップＳ８０５）と、振分部Ｈｉにメッセージの取得要求を送信する（ステップＳ８０６）。振分部Ｈｉは、取得要求に応じてキューＱＡから出力されるメッセージを各データ処理部ＤＰＡに送信し、各データ処理部ＤＰＡは当該メッセージを受信する（ステップＳ８０７）。

なお、ステップＳ８０７において、キューＱＡは、データ処理部ＤＰＡに取得された後にも同一のメッセージを、一定時間ロックがかけられた状態で保持する。キューＱＡに保持されたメッセージは、ロックがかけられている間は、データフロー上のつぎのデータ処理部ＤＰＢに送られることはない。これは、データ処理部ＤＰＡがデータ処理Ａ中に障害等で停止した場合にメッセージをロストしないための仕組みである。たとえば、データ処理部ＤＰＡが停止した場合、振分部Ｈｉは、キューＱＡのメッセージのロックを一定時間後に解除し、データフロー上のつぎのデータ処理部ＤＰＢにメッセージを振り分ける。

つぎに、データ処理部ＤＰＡは、メッセージのデータ処理Ａを実行し（ステップＳ８０８）、データフロー「Ａ→Ｂ」にしたがってキューＱＢを指定して、データ処理Ａ後のメッセージＡを振分部Ｈｉに送信する（ステップＳ８０９）。同様に、データ処理部ＤＰＡは、データフロー「Ａ→Ｃ→Ｄ」および「Ａ→Ｃ→Ｆ」にしたがってキューＱＣを指定して、データ処理Ａ後のメッセージＡを振分部Ｈｉに送信する（ステップＳ８１０）。

振分部Ｈｉは、ステップＳ８０９、Ｓ８１０で受信したメッセージＡをそれぞれキューＱＢ，ＱＣに格納し（ステップＳ８１１、Ｓ８１２）、正常応答を送信する（ステップＳ８１３、Ｓ８１４）。

つぎに、データ処理部ＤＰＡは、ステップＳ８０７でキューＱＡにロックされた状態の残存メッセージ（データ処理Ａ前のメッセージ）を削除する要求を振分部Ｈｉに送信する（ステップＳ８１５）。振分部Ｈｉは、削除要求を受けると当該メッセージを削除する（ステップＳ８１６）。ステップＳ８０４〜Ｓ８１６までが、振分部Ｈｉとデータ処理部ＤＰＡとの間での１メッセージ分の通信である。

つぎに、振分部Ｈｉは、データ処理部ＤＰＢ，ＤＰＣについても、ステップＳ８０４〜Ｓ８０６と同様に、各データ処理部ＤＰＢ，ＤＰＣの流量制御判定を行い、到着通知を送信し、各データ処理部ＤＰＢ，ＤＰＣから取得要求を受信する（ステップＳ８２０，Ｓ８２１）。

データ処理部ＤＰＢは、ステップＳ８２０後にメッセージＡを取得し（ステップＳ８２２）、データ処理Ｂを実行し（ステップＳ８２３）、データ処理ＢされたメッセージＢを宛先サーバ１０６−１へ送信する（ステップＳ８２４）。宛先サーバ１０６−１は、データ処理部ＤＰＢに正常応答を送信する（ステップＳ８２５）。

データ処理部ＤＰＢは、宛先サーバ１０６−１から正常応答を受信（ステップＳ８２５）後、キューＱＢでロック状態の残存メッセージＡの削除要求を振分部Ｈｉに送信する（ステップＳ８２６）。振分部ＨｉはメッセージＡをキューＱＢから削除する（ステップＳ８２７）。

データ処理部ＤＰＣは、ステップＳ８２１後にメッセージＡを取得し（ステップＳ８２８）、データ処理Ｃを実行し（ステップＳ８２９）、データフロー「Ａ→Ｃ→Ｄ」にしたがってキューＱＤを指定し、データ処理Ｃ後のメッセージＣを振分部Ｈｉに送信する（ステップＳ８３０）。以降の処理は、図８では割愛するが、このあと、振分部Ｈｉが、ステップＳ８２０，Ｓ８２１と同様にデータ処理部ＤＰＤとメッセージ交換を行い、宛先サーバ１０６−２へメッセージを送信する。

＜フロー計算処理例＞
図９は、振分部Ｈｉの流量制御を行うためのフロー計算処理手順例を示すフローチャートである。振分部Ｈｉは、データフロー計算機能４２３により、所定のタイミング、たとえば、一定時間おきにフロー計算処理を実行する。図９では、ボトルネックが発生した場合を例に説明するが、ボトルネックとなり得る状態の場合にも適用される。

振分部Ｈｉは、キュー管理情報４４０を元にキューＱｉＸのキュー長と、当該キューＱｉＸに滞留中のメッセージ数と、により、ボトルネックであるキューＱｉＸを特定する。振分部Ｈｉは、特定したキューＱｉＸに関連付けされたデータ処理部ＤＰｉＸをボトルネックとしてデータ処理テーブル４３２から検出する（ステップＳ９０１）。

つぎに、振分部Ｈｉは、データフローテーブル４３１のフロー定義５０２から、ボトルネックであるデータ処理部ＤＰｉＸに関連するデータフロー（関連データフロー）を特定し（ステップＳ９０２）、かつ、過去リソース情報４３４を取得する（ステップＳ９０３）。たとえば、図７のキューＱＣのメッセージ数がキュー長の閾値を超過したことによりデータ処理部ＤＰＣがボトルネックになったとする。この場合、振分部Ｈｉは、データ処理部ＤＰＣを含むデータフロー「Ａ→Ｃ→Ｄ」、「Ａ→Ｃ→Ｆ」を関連データフローとして特定する。

そして、振分部Ｈｉは、ボトルネックであるデータ処理部ＤＰｉＸと、特定したデータフロー上のデータ処理部ＤＰＹとを特定し、過去リソース情報４３４を用いて、各データ処理部ＤＰｉＸ，ＤＰＹへ割り当てる分散先数を仮計算する（ステップＳ９０４）。具体的には、たとえば、データ処理部ＤＰＣがボトルネックである場合、特定したデータフローが、「Ａ→Ｃ→Ｄ」、「Ａ→Ｃ→Ｆ」であるため、振分部Ｈｉは、データ処理部ＤＰＡ、ＤＰＤ、ＤＰＦを特定する。

そして、振分部Ｈｉは、データ処理部ＤＰＣと、関連するデータ処理部ＤＰＡ、ＤＰＤ、ＤＰＦへのリソースの配分を決定する。

ボトルネックであるデータ処理部ＤＰＣについては、振分部Ｈｉは、過去リソース情報４３４、たとえば、特定のデータフローの過去のＣＰＵ使用率を用いて、ボトルネックが解消するために分散先数をどのくらいまで増やせるか仮計算する。

たとえば、振分部Ｈｉは、ボトルネックであるデータ処理部ＤＰｉＸの台数を１つずつ増加させて、増加後のデータ処理部ＤＰｉＸのＣＰＵ使用率を仮計算し、当該ＣＰＵ使用率を用いた特定のデータフローのＣＰＵ使用率を仮計算する。振分部Ｈｉは、特定のデータフローのＣＰＵ使用率が、特定のデータフローの過去のＣＰＵ使用率、すなわちボトルネックから解消されるＣＰＵ使用率以下となったときのボトルネックであるデータ処理部ＤＰｉＸの台数を分散先数に仮決定する。

なお、ここでは、過去リソース情報４３４を用いたが、過去リソース情報４３４を用いずに、振分部Ｈｉは、所定のＣＰＵ使用率をボトルネックが解消するしきい値とし、特定のデータフローのＣＰＵ使用率が所定のＣＰＵ使用率以下となるデータ処理部ＤＰｉＸの台数を分散先数に仮決定してもよい。この場合、ステップＳ９０３は不要である。

また、関連するデータ処理部ＤＰＡ、ＤＰＢ、ＤＰＤ〜ＤＰＦについては、たとえば、振分部Ｈｉは、以下の（１）〜（４）の基準でリソースを仮計算する。

（１）振分部Ｈｉは、ボトルネック（本例では、データ処理部ＤＰＣ）を含む関連データフロー上において、ボトルネックの上流側のデータ処理部ＤＰＹ（本例では、データ処理部ＤＰＡ）については、ボトルネックが解消された場合でも、上流側のデータ処理部ＤＰＹからデータ処理部ＤＰＣへのメッセージ流量が多いと、データ処理部ＤＰＣが再度ボトルネックにあるおそれがある。したがって、振分部Ｈｉは、上流側のキューＱＹの滞留中のメッセージ数に応じて、上流側のデータ処理部ＤＰＹの分散先数を増加させる。たとえば、ボトルネックを規定する第１のしきい値には達していないが、当該第１のしきい値よりも低い第２のしきい値を超過している場合、振分部Ｈｉは、上流側のデータ処理部ＤＰＹの分散先数を増加させる。第２のしきい値を超過していない場合、現状維持とする。なお、ボトルネックの上流側のデータ処理部ＤＰＹのうち、ボトルネックに近いほど増加数を多くしてもよい。

（２）ボトルネックを含む関連データフロー上において、ボトルネックの下流側のデータ処理部ＤＰＹ（本例では、データ処理部ＤＰＤ，ＤＰＦ）については、ボトルネックが解消された場合、下流側のデータ処理部ＤＰＹに流れてくるメッセージ量が増加する。したがって、振分部Ｈｉは、下流側のキューＱＹの滞留中のメッセージ数に応じて、データ処理部ＤＰＹの分散先数を増加させる。たとえば、ボトルネックを規定する第１のしきい値には達していないが、当該第１のしきい値よりも低い第２のしきい値を超過している場合、振分部Ｈｉは、データ処理部ＤＰＹの分散先数を増加させる。第２のしきい値を超過していない場合、現状維持とする。なお、ボトルネックの下流側のデータ処理部ＤＰＹのうち、ボトルネックに近いほど増加数を多くしてもよい。

（３）また、振分部Ｈｉは、関連データフローでないデータフロー（非関連データフロー）上のデータ処理部ＤＰＹの中で、処理優先度６０４が相対的または絶対的に低いデータ処理部ＤＰＺのリソースを減少させてもよい。減少数は、あらかじめ設定される。たとえば、振分部Ｈｉは、流量制御前後でサーバ群ＳＶｓの総分散先数が同一となるように、処理優先度６０４を用いてデータ処理部ＤＰＺの分散先数を減少させてもよい。ただし、振分部Ｈｉは、減少後にデータ処理部ＤＰＺでボトルネックが発生しない分散先数にする。

（４）関連データフロー上のデータ処理部ＤＰＹの中で、非関連データフローとの合流点となるデータ処理部ＤＰＺ（本例では非関連データフロー「Ｅ→Ｆ」にも属するデータ処理部ＤＰＦ）が存在する場合がある。合流元のデータ処理部ＤＰＸ（本例ではデータ処理部ＤＰＣ，ＤＰＥ）のキューＱＸ（本例ではキューＱＣ，ＱＥ）に滞留中のメッセージ数に一定数以上の差がある場合、振分部Ｈｉは、メッセージ数が少ない方のキューＱＸに対応するデータ処理部ＤＰＸの分散先数を増加させる。増加数は、あらかじめ設定される値でもよい。

またこの場合、振分部Ｈｉは、メッセージ数が多い方のキューＱＸに対応するデータ処理部ＤＰＸの分散先数と同数となるように、少ない方のデータ処理部ＤＰＸの分散先数を増加してもよい。たとえば、データ処理部ＤＰＦの分散元は、ボトルネックであるデータ処理部ＤＰＣと、非関連データフロー「Ｅ→Ｆ」に属するデータ処理部ＤＰＥである。たとえば、ボトルネックであるデータ処理部ＤＰＣの分散先数が「６」であり、データ処理部ＤＰＥの分散先数が「２」であるとする。一定数を「４」とする。分散先数の差が一定数以上であることを満たす。ボトルネックであるデータ処理部ＤＰＣの分散先数が「６」から「８」に増加される場合、振分部Ｈｉは、データ処理部ＤＰＥ５の分散先数を「２」から「８」に増加してもよい。

つぎに、振分部Ｈｉは、ボトルネックの拡張性を判定する（ステップＳ９０５）。拡張性判定（ステップＳ９０５）とは、ボトルネックであるデータ処理部ＤＰｉＸの拡張が不要であるか、自動拡張不可であるか、自動拡張可であるか否かを判定する処理である。振分部Ｈｉが、ステップＳ９０４の仮計算結果と、各サーバＳＶｉで利用されていないデータ処理部ＤＰｉＹの台数と、データ処理テーブル４３２のリソース要件６０３であるリソースの自動拡張の有無と、に基づいて、拡張性を判定する。

たとえば、仮計算結果により、残存するデータ処理部ＤＰＹでリソース増加分を賄える場合は、振分部Ｈｉは、拡張不要と判定する（ステップＳ９０５：拡張不要）。ただし、ボトルネックであるデータ処理部ＤＰｉＸについてデータ処理テーブル４３２のリソース要件６０３に「自動拡張不可」がある場合、振分部Ｈｉは、自動拡張不可であると判定する（ステップＳ９０５：自動判定不可）。また、ボトルネックであるデータ処理部ＤＰｉＸについてデータ処理テーブル４３２のリソース要件６０３が「自動拡張可」である場合、振分部Ｈｉは、自動拡張可能であると判定する（ステップＳ９０５：自動判定可）。

拡張不要である場合（ステップＳ９０５：拡張不要）、振分部Ｈｉは、仮計算結果にしたがって、ボトルネックのデータ処理部ＤＰｉＸおよび関連するデータ処理部ＤＰＹの流量制御情報６０５である分散先数と流量制御値とを決定する（ステップＳ９０６）。振分部Ｈｉは、たとえば、分散先数に応じて流量制御値を増減する。すなわち、分散先数が増加すれば流量制御値も増加し、分散先数が減少すれば、流量制御値も減少する。たとえば、分散先数が「４」で流量制御値が「１００［ｍｓｇ／ｓｅｃ］」である場合、分散先１台について流量制御値は「２５［ｍｓｇ／ｓｅｃ］」である。したがって、分散先数が「４」から「５」に増加される場合、流量制御値は「１００［ｍｓｇ／ｓｅｃ］」から「１２５［ｍｓｇ／ｓｅｃ］」となる。同様に、分散先数が「４」から「３」に減少される場合、流量制御値は「１００［ｍｓｇ／ｓｅｃ］」から「７５［ｍｓｇ／ｓｅｃ］」となる。

自動拡張不可である場合（ステップＳ９０５：自動判定不可）、残存リソースを駆使してボトルネックであるデータ処理部ＤＰｉＸの増加分を賄うしかない。したがって、振分部Ｈｉは、ボトルネックのデータ処理部ＤＰｉＸを含むデータフローと関連しないデータ処理部ＤＰＺを特定し、関連しないデータ処理部ＤＰｉＸへのリソース割当を削減する。具体的には、振分部Ｈｉは、関連しないデータ処理部ＤＰＺのうち、その流量現在値６０６が相対的に低いデータ処理部ＤＰＺの分散先数および流量制御値を減少させる。また、流量現在値６０６により制御対象となるデータ処理部ＤＰＺを絞り込めない場合は、振分部Ｈｉは、関連しないデータ処理部ＤＰＺのうち、その優先度５０４が相対的に低いデータ処理部ＤＰＺの分散先数および流量制御値を減少させてもよい。また、優先度５０４ではなく、処理優先度６０４でもよい。

自動拡張可能である場合（ステップＳ９０５：自動判定可）、振分部Ｈｉまたは運用者は、運用機能との連携によりリソースを拡張し（ステップＳ９０８）、ステップＳ９０６と同様、振分部Ｈｉは、仮計算結果にしたがって、ボトルネックのデータ処理部ＤＰｉＸおよび関連するデータ処理部ＤＰＹの流量制御情報６０５の値である分散先数と流量制御値とを決定する（ステップＳ９０９）。

ステップＳ９０６、Ｓ９０７、Ｓ９０９のあと、振分部Ｈｉは、ステップＳ９０６、Ｓ９０７、Ｓ９０９で決定した分散先数および流量制御値を流量制御情報６０５に反映し、反映後の流量制御情報６０５を元にデータフローテーブル４３１の流量目標値５０５を更新する（ステップＳ９１０）。

そして、振分部Ｈｉは、ステップＳ９０６、Ｓ９０７、Ｓ９０９で決定した分散先数および流量制御値にしたがって、データ処理部ＤＰＸを増減する（ステップＳ９１１）。

つぎに、振分部Ｈｉは、流量制御情報６０５の反映結果をフィードバックするために、当該反映結果に効果があるか否かを判定する（ステップＳ９１２）。効果の有無とは、ボトルネックになったデータ処理部ＤＰＸの検出の場合は、特定のデータフローにおいてボトルネックが解消するか否かであり、ボトルネックとなり得るデータ処理部ＤＰＸの検出の場合は、特定のデータフローにおいてボトルネックとなり得る状態が解消するか否かである。

ボトルネック検出の場合、具体的には、たとえば、振分部Ｈｉは、データフローテーブル４３１において、ボトルネックのデータ処理部ＤＰｉＸを含むデータフローの流量目標値５０５の下限しきい値と、流量現在値５０６とに基づいて、流量制御情報６０５の反映結果に効果があるか否かを判定する。流量目標値５０５の下限しきい値は、ボトルネックの指標となるしきい値である。流量現在値５０６が下限しきい値以下である場合、流量制御情報６０５の反映結果に効果がない、すなわち、データフロー上のどこかのキューＱＸでボトルネックが発生していることを意味する。下限しきい値は固定値でもよく、ステップＳ９１０による更新後の流量目標値５０５に依存する値、たとえば、当該更新後の流量目標値５０５の１／３でもよい。

効果がない場合（ステップＳ９１２：Ｎｏ）、振分部Ｈｉは、ボトルネックのデータ処理部ＤＰｉＸの分散先数および流量制御値を所定量減少させて下方修正し（ステップＳ９１３）、データ処理テーブル４３２の流量制御情報６０５を更新する。所定量とは、たとえば、上述した分散先１台についての流量制御値（以降、１段階分の制御量という）であり、上記の例では、分散先数を「１」減少させて、流量制御値を「２５［ｍｓｇ／ｓｅｃ］」減少させる。なお、振分部Ｈｉは、２段階以上の制御量を減少させてもよく、また、増減したすべての分散先数および流量制御値を増減前の状態に戻してもよい。

一方、効果がある場合（ステップＳ９１２：Ｙｅｓ）、振分部Ｈｉは、分散先数および流量制御値を所定量（たとえば、１段階分の制御量）増加させて上方修正し（ステップＳ９１４）、データ処理テーブル４３２の流量制御情報６０５を更新する。なお、振分部Ｈｉは、２段階以上の制御量を減少させてもよい。

ステップＳ９１３またはＳ９１４のあと、振分部Ｈｉは、ステップＳ９１３またはＳ９１４での修正後の分散先数および流量制御値を流量制御情報６０５に反映し、反映後の流量制御情報６０５を元にデータフローテーブル４３１の流量目標値５０５を更新する（ステップＳ９１５）。

そして、振分部Ｈｉは、ステップＳ９１３またはＳ９１４での修正後の分散先数および流量制御値にしたがって、データ処理部ＤＰＸを増減する（ステップＳ９１６）。なお、図９では、データ処理部ＤＰＸの増減をステップＳ９１１とステップＳ９１６に分けて説明したが、ステップＳ９１６でまとめてデータ処理部ＤＰＸを増減してもよい。

図１０は、流量制御後のデータフローの一例を示す説明図である。図１０では、上述した基準（１）〜（４）の適用によりボトルネックのデータ処理部ＤＰｉＸおよび他のデータ処理部ＤＰＹが増減した例を示す。この流量制御後に、振分部Ｈｉは、図８に示した流量制御判定（ステップＳ８０４）を実行する。

このように、本実施例のデータ処理システムは、ボトルネックまたはボトルネックとなり得るとなるデータ処理部を増加することにより、当該データ処理部のメッセージ処理量を増加させ、キューでのメッセージの滞留量を間接的に減少させる。これにより、本実施例のデータ処理システムは、複数種類のデータ処理が混在するデータフロー群で発生するボトルネックを事後的にまたは未然に解消し、データフロー群のスループットの向上を図ることができる。

また、ボトルネックに関連するデータ処理部を増加することにより、より効率的にデータフロー群のスループットの向上を図ることができる。また、ボトルネックに関連しないデータ処理部を減少させることにより、その減少分のリソースを増加が必要なデータ処理部に融通することができる。

このように、本実施例によれば、複数のデータ処理から構成される複雑なデータ処理を行うデータ処理システムでの処理性能をスケールアップまたはスケールアウトすることができ、運用者の負荷分散設計やチューニング作業の削減と開発迅速化とを実現することができる。

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

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

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

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

Claims (8)

1. 送信元からのメッセージに対しデータ処理を実行して宛先に送信するデータ処理システムであって、
   前記データ処理が異なる複数種類のデータ処理部の各々を１以上有し、前記メッセージに対し種類が異なる一連のデータ処理を実行して前記一連のデータ処理後のメッセージを前記宛先に送信する複数のデータフローについて、前記送信元からのメッセージに指定されるデータフローにしたがって、当該メッセージおよび前記データ処理部によるデータ処理後のメッセージを後続のデータ処理部に振り分ける振分部を有し、
   前記振分部は、
   前記複数のデータフローを流れるメッセージの滞留量と前記データ処理のリソース情報とに基づいて、ボトルネックまたはボトルネックとなり得る特定の状態である特定のデータ処理部を検出する検出処理と、
   前記検出処理によって検出された特定のデータ処理部のリソース情報に基づいて、前記特定のデータ処理部の台数の増加により前記特定のデータ処理部が前記特定の状態から解消される台数に決定する決定処理と、
   前記特定のデータ処理部を、前記決定処理によって決定された前記特定の状態から解消される台数分設定する設定処理と、
   を実行することを特徴とするデータ処理システム。
2. 前記決定処理では、前記振分部は、前記複数のデータフローのうち前記特定のデータ処理部を経由する関連データフローにおいて、前記特定のデータ処理部以外の他のデータ処理部の台数を、前記特定の状態の検出前よりも多い台数に決定し、
   前記設定処理では、前記振分部は、前記他のデータ処理部を、前記特定の状態の検出前よりも多い台数分設定することを特徴とする請求項１に記載のデータ処理システム。
3. 前記決定処理では、前記振分部は、前記複数のデータフローのうち前記特定のデータ処理部を経由する関連データフローではない非関連データフロー上において、前記特定のデータ処理部以外の他のデータ処理部の台数を、前記特定の状態の検出前よりも少ない台数に決定し、
   前記設定処理では、前記振分部は、前記他のデータ処理部を、前記特定の状態の検出前よりも少ない台数分設定することを特徴とする請求項１に記載のデータ処理システム。
4. 前記決定処理では、前記振分部は、前記他のデータ処理部に設定された優先度に基づいて、前記他のデータ処理部の台数を決定することを特徴とする請求項２または３に記載のデータ処理システム。
5. 前記決定処理では、前記振分部は、前記複数のデータフローのうち前記特定のデータ処理部を経由する関連データフローではない非関連データフローが前記関連データフローと合流するデータ処理部が存在する場合、前記非関連データフロー上において、前記合流するデータ処理部の上流側のデータ処理部の台数を、前記特定の状態の検出前よりも多い台数に決定し、
   前記設定処理では、前記振分部は、前記上流側のデータ処理部を、前記特定の状態の検出前よりも多い台数分設定することを特徴とする請求項１に記載のデータ処理システム。
6. 前記決定処理では、前記振分部は、前記複数のデータフローのうち前記特定のデータ処理部を経由する関連データフロー上の前記特定のデータ処理部でのデータ処理後のメッセージをデータ処理する後続のデータ処理部に当該メッセージを送信可能なメッセージ流量の目標値である流量制御値を、前記特定の状態から解消される台数に応じた流量制御値に決定し、
   前記振分部は、
   前記特定のデータ処理部の現在のメッセージ流量である流量現在値が前記決定処理によって決定された流量制御値以上であるか否かを判定する流量制御判定処理と、
   前記流量制御判定処理によって前記流量現在値が前記決定処理によって決定された流量制御値以上であると判定された場合、前記特定のデータ処理部によるデータ処理後のメッセージを前記後続のデータ処理部に振り分ける振分処理と、を実行することを特徴とする請求項１に記載のデータ処理システム。
7. 前記振分部は、
   前記特定のデータフローにおける現在のメッセージ流量である流量現在値と、前記決定処理によって決定された流量制御値に応じた流量目標値と、に基づいて、前記データフローにおいて前記特定の状態が解消されるか否かを判定する効果判定処理と、
   前記効果判定処理による判定結果に基づいて、前記決定処理によって決定された台数および流量制御値を増減制御する増減制御処理と、
   を実行することを特徴とする請求項６に記載のデータ処理システム。
8. 送信元からのメッセージに対しデータ処理を実行して宛先に送信するデータ処理システムによるデータ処理方法であって、
   前記データ処理システムは、
   前記データ処理が異なる複数種類のデータ処理部の各々を１以上有し、前記メッセージに対し種類が異なる一連のデータ処理を実行して前記一連のデータ処理後のメッセージを前記宛先に送信する複数のデータフローについて、前記送信元からのメッセージに指定されるデータフローにしたがって、当該メッセージおよび前記データ処理部によるデータ処理後のメッセージを後続のデータ処理部に振り分ける振分部を有し、
   前記振分部は、
   前記複数のデータフローを流れるメッセージの滞留量と前記データ処理のリソース情報とに基づいて、ボトルネックまたはボトルネックとなり得る特定の状態である特定のデータ処理部を検出する検出処理と、
   前記検出処理によって検出された特定のデータ処理部のリソース情報に基づいて、前記特定のデータ処理部の台数の増加により前記特定のデータ処理部が前記特定の状態から解消される台数に決定する決定処理と、
   前記特定のデータ処理部を、前記決定処理によって決定された前記特定の状態から解消される台数分設定する設定処理と、
   を実行することを特徴とするデータ処理方法。

Images