JP6062034B2 - 処理制御システム、処理制御方法、および処理制御プログラム - Google Patents

Description

参照による取り込み

本出願は、２０１３年３月１９日に出願された日本特許出願第２０１３−０５６８４４号の優先権を主張し、その内容を、参照により本出願に取り込む。

本発明は、処理を複数の計算機に分散させる技術に関する。

昨今、様々な機器やセンサから送出されるログやセンサ情報等に代表される多量のデータ（ビッグデータと呼ばれる）を解析（分析）し、ビジネスに役立つ知見（情報）を得る取り組みがある。このような解析において、データベース等に蓄えられる多量のデータを、特定のタイミングでバッチ処理により解析する技術が知られている。

また、金融機関のアルゴリズム取引のように、リアルタイムで解析し、その結果をリアルタイムに取得するという、複合イベント処理（ＣＥＰ：Complex Event Processing）技術が知られている。バッチ処理は、処理対象のデータ範囲が広い（数日〜数年単位）。一方、ＣＥＰ技術では直近（数分単位）のデータ範囲を対象としている。このような性質の違いから、バッチ処理は傾向分析等に向いており、ＣＥＰ技術はアクセスログ等を元にした不正値検出やリアルタイム課金制御等に向いている。

ＣＥＰ技術のシステムにおいて解析サーバが大量のデータを解析する場合、解析サーバの処理性能に限界があるため、全てをリアルタイムに処理できない恐れがある。ＣＥＰ技術で処理するデータが特に多いと、ＣＥＰ技術でのデータ解析処理の遅延によって性能劣化が発生する恐れがある。

このような問題に対し、解析サーバを複数設け、解析サーバでＣＥＰとして実行されるイベントの関連度に応じて、イベント処理を分散させることにより、性能劣化を防止する技術が知られている（例えば特許文献１、段落００３９、００４１）。

特許文献１に示されている仕組みは、性能劣化を防止するために、処理の負荷が低い解析サーバを選択して処理を実行させる仕組みである。

同様に、複数の計算機間で負荷を分散させる技術が考えられている（特許文献２）。この技術では、複数の計算機が、それぞれの負荷をキューの使用率で表し、その使用率が最も低い計算機へクライアントの要求を転送することにより、負荷の偏りを防止しようとする。

一般に、システムの性能限界がサーバの処理性能に達することによる防止策として、ハードウエアの性能向上を図る手法と、上記特許文献のように処理を分散させる手法とが挙げられる。前者の手法はハードウエア更新時のサービス停止を伴う等の問題がある。従って、データセンタ運用業者等は、サービスを停止させず、通信量の増加に対応できる後者の手法（スケールアウト）による能力増強を図ることが多い。スケールアウトによって能力増強を図る場合、複数のサーバに対して如何に処理を分散させるかが問題となる。

スケールアウトを行う場合、通常、システム全体の処理性能不足がトリガーとなる。サーバまたは計算機のハードウエア処理性能は日々向上している。そのため、システム構築時に導入したサーバとスケールアウト時に導入するサーバのハードウエア処理性能が同じになるようにサーバを導入することは、現実的には困難である。処理性能の異なる複数のサーバで構築されたシステムにおいて、例えば処理要求を順番に割り振るラウンドロビン方法を利用した場合、スペックが異なるが故にサーバ間の負荷バランスに差が生じ、要求の処理に時間差が生じることになるなどの問題がある。

一方、１以上の複数のサーバやそれらを接続する１以上のネットワークを構成する機器などの、様々な構成要素から成るシステムでは、それらの構成要素の障害や故障などにより、システムが停止したり、正しい結果が得られなかったりすることにより、信頼性が低下するというリスクがある。

これに対し、信頼性を高める、すなわち、フォールトトレランス性（耐障害性）を持たせる仕組みの１つとして、冗長化がある。冗長化では、同じシステムを複数用意して、それら全てに同じ処理を並列に実行させ、あるシステムに障害が発生しても、他のシステムが動作し続けることによって信頼性を確保する。ここで、障害の度合い（例えばＣＰＵの内部障害による計算間違い発生）によっては、複数のシステムで同じ処理をしても結果が同一に至らない場合もあり、そのような場合、多数決により、正しいと考えられる結果を得る仕組みが知られている。

例えば特許文献３には、処理要求を受け、その要求を計算機により処理した結果を伝送するシステムにおいて、同一の処理要求を複数の計算機の全てに送信し、複数の計算機からその処理結果を受信して、複数の受信結果を比較して正しい処理結果を出力する構成が示されている。

このような仕組みを用いることによって、計算機における障害や故障、ソフトウエアバージョン違いによる異なる結果出力、といったことを防止でき、信頼性を向上させたシステムとして動作させることが可能である。

米国特許出願公開第２０１２／０８４７８８号明細書 米国特許出願公開第２００６／２１２８７３号明細書 特開平７−３０６７９４号明細書

特許文献１に示されるイベント処理を分散させる技術は、負荷に基づき関連度の高いイベントを特定の解析サーバへ集約するため、解析対象のデータが特に多い場合、解析サーバの負荷が処理性能の限界に達し、所定の時間内に解析を完了させることが難しくなる。

また、特許文献２に示される複数の計算機間で要求を転送する技術は、効率よく負荷分散を行うことが難しい。また、前述のようなスペックの異なる複数の計算機間で処理要求を処理した場合、複数の計算機間で負荷バランスの差が生じるため、要求処理の時間差が発生することになる。

さらに、特許文献１、２の仕組みは、処理の負荷が低いサーバまたは計算機を一つ選択するに過ぎず、障害発生を考慮していないから、フォールトトレランスを備えていない。

また、特許文献３に示される技術では、処理を複数の計算機全てで並列実行する。このような仕組みでは、１つの計算機の処理性能の上限が、システム全体の性能を決めてしまう。そのため、特許文献３に示される技術を、例えばビッグデータのような大量の情報を分析や解析するシステムへ適用すると、処理量の増大に伴ってシステムのスループットが低下してしまうという問題がある。

従って、高い信頼性を備えつつ、処理量が増大してもスループットが低下しない、安定して要求を処理できる負荷分散技術が求められている。

上記課題を解決するために、本明細書では、ｎ個（ｎは３以上）の計算機（たとえば解析サーバ）に掛かっている負荷と、要求された処理に対する能力と、を考慮して、ｍ個（１＜ｍ＜ｎ）の計算機（たとえば解析サーバ）を選択し、選択した計算機（たとえば解析サーバ）による複数の処理結果を、所定の方法で処理して、もっとも確からしい結果を得る技術が提供される。

開示する技術に基づけば、要求された処理を複数の計算機に処理させることが可能になり、結果的に処理時間の短縮、システムに掛かる負荷の削減、が可能になる。

また、全ての計算機ではなく、一部の複数の計算機（たとえば解析サーバ）を選択することにより、システム全体で必要な電力などの資源も抑えることが可能になる。

より具体的な一態様である処理システムは、以下の構成を備える。

ｎ個（ｎは３以上）の処理装置に接続された負荷分散装置と、前記ｎ個の処理装置に接続された処理結果判定装置と、前記負荷分散装置及び前記処理結果判定装置に接続された管理装置と、を備える。前記管理装置は、前記ｎ個の処理装置の夫々について、過去の処理において要した時間情報を取得し、前記ｎ個の処理装置の夫々が処理対象情報の処理に掛かる所要時間を、前記時間情報に基づいて推定して推定時間とし、前記推定時間及び処理装置の関係を示す推定時間情報を前記負荷分散装置へ送信する。

前記負荷分散装置は、前記推定時間情報に基づいて、前記処理対象情報を処理させる、ｍ個（１＜ｍ＜ｎ）の処理装置を決定し、前記処理対象情報を、前記決定したｍ個の指定処理装置へ送信する。前記ｍ個の指定処理装置の夫々は、前記処理対象情報を処理することにより処理結果を算出し、前記処理結果を前記処理結果判定装置へ送信する。前記処理結果判定装置は、前記ｍ個の指定処理装置からｍ個の処理結果を夫々受信し、所定の方法により前記ｍ個の処理結果から真の値を推定して推定値とし、前記推定値を処理する後段の処理装置へ前記推定値を送信する。

また、別の一態様である、ｎ個（ｎは３以上）の処理装置に接続された負荷分散装置のコンピュータのための負荷分散プログラムは、前記負荷分散装置に接続された管理装置が、前記ｎ個の処理装置の夫々について、過去の処理において要した時間情報を取得し、前記ｎ個の処理装置の夫々が処理対象情報の処理に掛かる所要時間を、前記時間情報に基づいて推定して推定時間とし、前記推定時間及び処理装置の関係を示す推定時間情報を前記負荷分散装置へ送信した場合、前記推定時間情報に基づいて、前記処理対象情報を処理させるｍ個（１＜ｍ＜ｎ）の処理装置を決定することを前記コンピュータに実行させ、前記処理対象情報を、前記決定したｍ個の指定処理装置へ送信することを前記コンピュータに実行させる。前記ｍ個の指定処理装置の夫々は、前記処理対象情報を処理することにより処理結果を算出し、前記処理結果を前記処理結果判定装置へ送信する。前記処理結果判定装置は、前記ｍ個の指定処理装置からｍ個の処理結果を夫々受信し、所定の方法により前記ｍ個の処理結果から真の値を推定して推定値とし、前記推定値を処理する後段の処理装置へ前記推定値を送信する。

また、別の一態様である、ｎ個（ｎは３以上）の処理装置に接続された処理結果判定装置のコンピュータのための処理結果判定プログラムは、前記処理結果判定装置に接続された管理装置が、前記ｎ個の処理装置の夫々について、過去の処理において要した時間情報を取得し、前記ｎ個の処理装置の夫々が処理対象情報の処理に掛かる所要時間を、前記時間情報に基づいて推定して推定時間とし、前記推定時間及び処理装置の関係を示す推定時間情報を、前記管理装置、前記ｎ個の処理装置、及び前記処理結果判定装置に接続された前記負荷分散装置へ送信し、前記負荷分散装置が、前記推定時間情報に基づいて、前記処理対象情報を処理させる、ｍ個（１＜ｍ＜ｎ）の処理装置を決定し、前記処理対象情報を、前記決定したｍ個の指定処理装置へ送信し、前記ｍ個の指定処理装置の夫々が、前記処理対象情報を処理することにより処理結果を算出し、前記処理結果を前記処理結果判定装置へ送信した場合、前記ｍ個の指定処理装置からｍ個の処理結果を夫々受信することを前記コンピュータに実行させ、所定の方法により前記ｍ個の処理結果から真の値を推定して推定値とすることを前記コンピュータに実行させ、前記推定値を処理する後段の処理装置へ前記推定値を送信することを前記コンピュータに実行させる。

上記態様によれば、低信頼のサーバや、低信頼のソフトウエアを導入したシステム構成であっても、要求時間内に処理結果を出力するように、処理を分散させることができる。

また、本発明の一態様によれば、サーバの信頼性低下または、ハードウエア停止、交換、ソフトウエアの停止、交換による影響を受けることなく、多数決に則った、確からしい結果を得ることができる。

また、本発明の一態様によれば、複数のサーバにおける処理結果について、真の結果と捉えるための仕組みとして、あるサーバの処理の結果について管理者の重みづけを行って、それを踏まえた多数決による真の結果を得ることもできる。

また、本発明の一態様によれば、複数のサーバにおける処理結果について、真の結果と捉えるための仕組みとして、複数のサーバの処理の結果を判定する際に、あるサーバの処理の結果を無効として、それを踏まえた多数決による真の結果を得ることもできる。

また、本発明の一態様によれば、複数のサーバにおける処理結果について、真の結果を推定するための仕組みとして、結果が多値で出力される場合の、確率分布や平均値を利用して推定値を得る仕組みや、判定のための結果数が偶数個であったとしても判定する仕組みを備えることによる、確からしい推定値を得ることもできる。

開示によれば、高い信頼性を備えつつ、安定した処理が可能な負荷分散技術を提供可能になる。

各実施例で用いるコンピュータシステムの構成を示す。 分散装置１０の構成を示す。 管理サーバ９の構成を示す。 解析サーバ１１の構成を示す。 ログ出力サーバ８の構成を示す。 判定装置１２の構成を示す。 分散装置１０における分散管理テーブル１２１を示す。 分散装置１０におけるイベント型識別テーブル１２２を示す。 分散装置１０における通信管理テーブル１２３を示す。 管理サーバ９における要求時間テーブル９２０を示す。 管理サーバ９における解析ロジック管理テーブル９２１を示す。 管理サーバ９における接続先管理テーブル９２２を示す。 管理サーバ９における時間管理テーブル９２３を示す。 管理サーバ９における統計時間管理テーブル９２４を示す。 解析サーバ１１におけるロジック管理テーブル１１２０を示す。 解析サーバ１１におけるキュー管理テーブル１１２１を示す。 解析サーバ１１における接続先管理テーブル１１２３を示す。 ログ出力サーバ８における簡易分散ルール８２０を示す。 ログ出力サーバ８における簡易分散先テーブル８２１を示す。 判定装置１２における解析結果管理テーブル７２０を示す。 管理サーバ９及び判定装置１２における分散数管理テーブル７２１を示す。 判定装置１２における通信用管理テーブル７２２を示す。 管理サーバ９による分散数情報送信処理を示す。 管理サーバ９によるキュー統計情報送信処理を示す。 分散装置１０による分散順位更新処理を示す。 ログ出力サーバ８によるイベント送信処理を示す。 分散装置１０による分散処理を示す。 管理サーバ９による分散先応答処理を示す。 管理サーバ９による分散先登録処理を示す。 解析サーバ１１による解析処理を示す。 判定装置１２による分散数情報更新処理を示す。 判定装置１２による解析結果判定処理を示す。 管理サーバ９による解析結果登録処理を示す。 実施例２の管理サーバ９の構成を示す。 実施例２の管理サーバ９における解析サーバ状態管理テーブル９２５を示す。 実施例３の分散装置１０の構成を示す。 実施例３の分散装置１０におけるセッション管理テーブル１２４を示す。 実施例３の分散装置１０による分散処理を示す。

以下、本発明の実施例について図面を参照しつつ説明する。

本発明の一態様の表現における用語について説明する。ｎ個の処理装置の夫々は、解析装置や解析サーバ１１などに対応する。処理は、解析などに対応する。負荷分散装置は、分散装置１０などに対応する。処理結果判定装置は、解析結果判定装置や判定装置１２などに対応する。管理装置は、管理サーバ９などに対応する。後段の処理装置は、推定値を処理する処理装置やＡＰサーバ１３などに対応する。処理対象情報は、解析対象情報やイベントなどに対応する。ｍ個の指定処理装置の夫々は、特定解析装置や分散先の解析サーバ１１などに対応する。時間情報は、時間管理テーブル９２３や見積時間などに対応する。推定時間は、統計時間管理テーブル９２４や見積時間や平均見積時間などに対応する。推定時間情報は、キュー統計情報や分散先応答などに対応する。負荷分散プログラムは、分散装置１０のプログラムなどに対応する。処理結果判定プログラムは、判定装置１２のプログラム等に対応する。通信装置は、ログ出力サーバ８などに対応する。処理制御プログラムは、管理サーバ９のプログラムなどに対応する。上限は、要求時間などに対応する。

以下、本発明の実施例のコンピュータシステムの構成について説明する。

図１は、本発明の実施例のコンピュータシステムの構成を示す。

本実施例のコンピュータシステムは、複数のクライアント７と、複数のログ出力サーバ８と、管理サーバ９と、複数の分散装置１０と、複数の解析サーバ１１と、複数の判定装置１２と、複数のＡＰ（Application）サーバ１３とを有する。なお、ログ出力サーバ８の数は一つであっても良いし、分散装置１０の数は一つであっても良いし、判定装置１２の数は一つであっても良いし、ＡＰサーバ１３の数は一つであっても良い。また、クライアント７は省かれても良い。

クライアント７は、ネットワーク１５を介してログ出力サーバ８に接続される。ログ出力サーバ８はネットワーク１６を介して複数の分散装置１０に接続される。分散装置１０はネットワーク１７を介して複数の解析サーバ１１に接続される。解析サーバ１１はネットワーク１８を介して複数の判定装置１２に接続される。判定装置１２はネットワーク１９を介して複数のＡＰサーバ１３に接続される。また、管理サーバ９はネットワーク５を介して複数の分散装置１０に接続される。管理サーバ９はネットワーク６を介して複数の解析サーバ１１に接続される。管理サーバ９はネットワーク１４を介して複数の判定装置１２に接続される。なお、管理サーバ９は複数の解析サーバ１１に接続されていなくても良い。

本実施例では、分散装置１０と判定装置１２を別々のハードウエアとして設けられている形態を示しているが、分散装置１０と判定装置１２が同一のハードウエア内に設けられていても構わない。また、分散装置１０と解析サーバ１１と判定装置１２が同一のハードウエア内に設けられていても構わない。本実施例では、管理サーバ９が、分散装置１０、解析サーバ１１、判定装置１２とは別のハードウエアとして設けられている形態を示しているが、管理サーバ９が、分散装置１０、解析サーバ１１、判定装置１２の何れかの中に設けられていても構わない。また、本実施例では管理サーバ９が１台のコンピュータとして設けられているが、複数の管理サーバ９を有するコンピュータシステムとして設けられていても構わない。ただし、その場合、複数の管理サーバ９間で情報の共有又は同期を行う必要がある。

クライアント７は、ログ出力サーバ８との通信を行う。ログ出力サーバ８は、クライアント７との通信の内容を示すログを生成し、ログ内のイベントの内容に応じて複数の分散装置１０の中から送信先を選択し、選択された分散装置１０へイベントを出力する。イベントを受信した分散装置１０は、イベントの内容に応じて複数の解析サーバ１１の中から送信先を選択し、選択された解析サーバ１１へイベントを送信する。イベントを受信した解析サーバ１１は、イベントを解析し、その解析から得られる解析値を含む解析結果情報を判定装置１２へ送信する。複数の解析値を受信した判定装置１２は、複数の解析値の真の値を推定して推定値とし、その推定値を最終的な解析結果として、解析結果を要求するＡＰサーバ１３へ送信する。推定値を受信したＡＰサーバ１３は、推定値を用いるＡＰを実行する。このようなコンピュータシステムの構成により、解析の処理を複数の解析サーバ１１に分散させることができる。

このコンピュータシステムが移動体通信システムに適用される場合について説明する。この場合、クライアント７は、ユーザにより使用される携帯電話機やスマートフォン等の通信端末装置に対応する。ログ出力サーバ８は、基地局やＧＷ（Gateway）等に対応し、通信端末装置の通信のログをイベントとして出力する。解析サーバ１１は、イベントに基づいて、ユーザ毎の通信量や有料コンテンツの利用量等を解析する。ＡＰサーバ１３におけるＡＰは、通信端末装置毎の通信量や有料コンテンツの利用に応じてユーザへの課金を処理する課金処理や、通信端末装置の通信量に応じてその通信端末装置の帯域を制御する帯域制御等を行う。

ログ出力サーバ８は、カメラやセンサ等であっても良い。この場合のログ出力サーバ８は、検出した情報をイベントとして分散装置１０へ送信する。この場合のコンピュータシステムは、クライアント７を有していなくても良い。

このようなコンピュータシステムは他に、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）やメールシステム、データセンタ等、サーバとクライアントの間でデータを通信するネットワークシステムにも適用されることができる。

以下の説明において、管理サーバ９と、分散装置１０と、判定装置１２とを有するシステムを解析制御システムと呼ぶことがある。また、解析制御システムと、複数の解析サーバ１１とを有するシステムを解析システムと呼ぶことがある。

図２は、分散装置１０の構成を示す。

分散装置１０は、１つ以上のＣＰＵ（Central Processing Unit）１０１と、１つ以上のネットワークインタフェース（ＮＷ Ｉ／Ｆ）１０２〜１０４と、入出力装置１０５と、メモリ１０７と有するコンピュータにより実現される。分散装置１０の各部は、内部バス１０６等の通信路を介して相互に接続される。ＮＷ Ｉ／Ｆ１０２は、ネットワーク１６を介してログ出力サーバ８と接続される。ＮＷ Ｉ／Ｆ１０３は、ネットワーク１７を介して解析サーバ１１と接続される。ＮＷ Ｉ／Ｆ１０４は、ネットワーク６を介して管理サーバ９と接続される。メモリ１０７には、分散機能１１１、ロジック負荷取得機能１１２の各プログラムと、分散管理テーブル１２１、イベント型識別テーブル１２２、通信管理テーブル１２３とが格納される。

分散装置１０の各プログラムは、予め分散装置１０のメモリ１０７に格納されていても良いし、分散装置１０により利用可能な記録媒体に記録され、必要な時に、メモリ１０７に導入されてもよい。記録媒体とは、例えば分散装置１０における図示しない外部デバイスインタフェースに着脱可能な記憶媒体を指す。

分散機能１１１は、分散管理テーブル１２１を基に、ログ出力サーバ８から受信したイベントの分散先となる解析サーバ１１を決定し、そのイベントを分散先へ転送する。

図３は、管理サーバ９の構成を示す。

管理サーバ９は、１つ以上のＣＰＵ９０１と、１つ以上のネットワークインタフェース（ＮＷ Ｉ／Ｆ）９０２〜９０４と、入出力装置９０５と、メモリ９０７とを有するコンピュータにより実現される。管理サーバ９の各部は、内部バス９０６等の通信路を介して相互に接続される。ＮＷ Ｉ／Ｆ９０２は、ネットワーク５を介して分散装置１０と接続される。ＮＷ Ｉ／Ｆ９０３は、ネットワーク１４を介して判定装置１２と接続される。ＮＷ Ｉ／Ｆ９０４は、ネットワーク６を介して解析サーバ１１と接続される。メモリ９０７には、管理機能９１０、ロジック管理機能９１１の各プログラムと、要求時間テーブル９２０、解析ロジック管理テーブル９２１、分散数管理テーブル７２１、接続先管理テーブル９２２、時間管理テーブル９２３、統計時間管理テーブル９２４とが格納される。

分散装置１０と同様に、管理サーバ９の各プログラムは、予め管理サーバ９のメモリ９０７に格納されていても良いし、管理サーバ９により利用可能な記録媒体に記録され、必要な時に、メモリ９０７に導入されてもよい。

ロジック管理機能９１１は、分散装置１０と判定装置１２から分散に関する情報を取得して、その情報に基づいて解析サーバ１１のキュー状態を解析する。そして、管理機能９１０は、ロジック管理機能９１１が解析した結果を基にして、ＡＰの要求時間に応じた分散先を決定する。また、管理機能９１０は、コンピュータシステムの管理者からの指示を受け付ける。

図４は、解析サーバ１１の構成を示す。

解析サーバ１１は、１つ以上のＣＰＵ１１０１と、１つ以上のネットワークインタフェース（ＮＷ Ｉ／Ｆ）１１０２〜１１０４と、入出力装置１１０５と、メモリ１１０７とを有するコンピュータにより実現される。解析サーバの各部は、内部バス１１０６等の通信路を介して相互に接続される。ＮＷ Ｉ／Ｆ１１０２は、ネットワーク１７を介して分散装置１０と接続される。ＮＷ Ｉ／Ｆ１１０３は、ネットワーク１８を介して判定装置１２と接続される。ＮＷ Ｉ／Ｆ１１０４は、ネットワーク６を介して管理サーバ９と接続される。メモリ１１０７には、解析機能１１１０、キュー管理機能１１１１の各プログラムと、ロジック管理テーブル１１２０、キュー管理テーブル１１２１、イベント型識別テーブル１２２、接続先管理テーブル１１２３とが格納される。

分散装置１０と同様に、解析サーバ１１の各プログラムは、予め解析サーバ１１のメモリ１１０７に格納されていても良いし、解析サーバ１１により利用可能な記録媒体に記録され、必要な時に、メモリ１１０７に導入されてもよい。

解析機能１１１０は、イベント型識別テーブル１２２及びロジック管理テーブル１１２０に基づいて、分散装置１０より受信したイベントを解析する解析ロジックを選択し、その解析ロジックに従って解析処理を実行する。キュー管理機能１１１１は、分散装置１０より受信したイベントを一度キュー管理テーブル１１２１に格納し、解析機能１１１０の必要に応じてキュー管理テーブル１１２１からイベントを取り出す。以下の説明及び図面において、解析サーバ１１内のキュー管理テーブル１１２１を単にキューと呼ぶことがある。

図５は、ログ出力サーバ８の構成を示す。

ログ出力サーバ８は、１つ以上のＣＰＵ８０１と、１つ以上のネットワークインタフェース（ＮＷ Ｉ／Ｆ）８０２〜８０３と、入出力装置８０４と、メモリ８０６とを有するコンピュータにより実現される。ログ出力サーバ８の各部は、内部バス８０５等の通信路を介して相互に接続される。ＮＷ Ｉ／Ｆ８０２は、ネットワーク１５を介してクライアント７と接続される。ＮＷ Ｉ／Ｆ８０３は、ネットワーク１６を介して分散装置１０と相互に接続される。メモリ８０６には、ノード機能８１０、簡易分散機能８１１の各プログラムと、簡易分散ルール８２０、簡易分散先テーブル８２１、イベント型識別テーブル１２２とが格納される。

分散装置１０と同様に、ログ出力サーバ８の各プログラムは、予めログ出力サーバ８のメモリ８０６に格納されていても良いし、ログ出力サーバ８により利用可能な記録媒体に記録され、必要な時に、メモリ８０６に導入されてもよい。

ノード機能８１０は、クライアント７から受信した要求に対する処理を実行する。簡易分散機能８１１は、クライアント７の要求がノード機能８１０により処理された過程で出力されるアクセスログを分散装置１０へ転送するために、簡易分散先テーブル８２１に登録される分散装置１０の中から、簡易分散ルール８２０に則り分散装置１０を選択して、分散する。

図６は、判定装置１２の構成を示す。

判定装置１２は、１つ以上のＣＰＵ１２０１と、１つ以上のネットワークインタフェース（ＮＷ Ｉ／Ｆ）１２０２〜１２０３と、入出力装置１２０４と、メモリ１２０６とを有するコンピュータにより実現される。判定装置１２の内部バス１２０５等の通信路を介して相互に接続される。ＮＷ Ｉ／Ｆ１２０２は、ネットワーク１８を介して解析サーバ１１と接続される。ＮＷ Ｉ／Ｆ１２０３は、ネットワーク１９を介してＡＰサーバ１３と接続される。メモリ１２０６には、判定機能１２１０のプログラムと、解析結果管理テーブル７２０、分散数管理テーブル７２１、要求時間テーブル９２０、通信用管理テーブル７２２とが格納される。

分散装置１０と同様に、各プログラムは、予め判定装置１２のメモリ１２０６に格納されていても良いし、判定装置１２が利用可能な記録媒体に記録され、必要な時に、メモリ１２０６に導入されてもよい。

判定機能１２１０は、複数の解析サーバ１１から受信した解析結果情報を解析結果管理テーブル７２０へ格納し、複数の解析結果情報に示された解析値に基づいて、確率が最も高い解析値を推定値として決定し、推定値をＡＰサーバ１３へ送信する。

図７は、分散装置１０における分散管理テーブル１２１を示す。

分散管理テーブル１２１は、分散装置１０がログ出力サーバ８から受信したイベントを分散させるための情報であり、イベントの分類に応じた分散の指示を示す。分散管理テーブル１２１は、イベント型毎のレコードを有する。イベント型は、要求時間の分類を示す。要求時間は、解析に用いることができる処理時間（所要時間）の上限であり、ＡＰにより要求される。本実施例におけるイベント型は、一定時間型とリアルタイム型である。リアルタイム型の要求時間は、一定時間型の要求時間より短い。分散管理テーブル１２１の各レコードは、イベント種別欄１２１１と、分散順位欄１２１２と、更新時刻欄１２１３と、分散数欄１２１４とを有する。

イベント型欄１２１１には、イベント型が登録される。ここに登録される内容は、後述のイベント型識別テーブル１２２のイベント型欄１２２１の内容である。分散順位欄１２１２には、当該イベント型のイベントの分散先の候補である複数の解析サーバ１１の優先順位が登録される。更新時刻欄１２１３には、当該レコードの更新時刻が登録される。分散数欄１２１４には、当該イベント型のイベントの分散先となる解析サーバ１１の数である分散数が登録される。

この図の例では、イベント型が「一定時間型」の場合、分散装置１０は、分散数である「５」個の解析サーバ１１へ分散させることを示している。分散装置１０は、分散順位欄１２１２に登録される上位から順に分散数だけの解析サーバ１１を分散先として選択する。なお、分散数は、分散順位欄１２１２に登録された解析サーバ１１の数より少なくても良い。

図８は、分散装置１０におけるイベント型識別テーブル１２２を示す。

イベント型識別テーブル１２２には、ログ出力サーバ８から受信したイベントを識別するための情報である。イベント型識別テーブル１２２は、イベント型毎のレコードを有する。各レコードは、イベント型欄１２２１と、プロトコル欄１２２２と、ヘッダ欄１２２３とを有する。

イベント型欄１２２１には、当該コンピュータシステム内で判別されるイベント型が登録される。プロトコル欄１２２２には、ログ出力サーバ８から受信したイベントのプロトコル名が登録される。ヘッダ欄１２２３には、イベント型を識別するために参照される特定のヘッダの名称が登録される。分散装置１０は、イベントのプロトコルと特定のヘッダを参照することにより、対応するイベント型を識別する。

図９は、分散装置１０における通信管理テーブル１２３を示す。

通信管理テーブル１２３には、分散装置１０が接続先と通信するために必要なＩＰアドレスやネットマスクが登録される。接続先は、解析サーバ１１や管理サーバ９等である。通信管理テーブル１２３は、接続先毎のレコードを有する。各レコードは、区別欄１２３１と、アドレス欄１２３２と、マスク値欄１２３３とを有する。

区別欄１２３１には、接続先を識別するための接続先の名称が登録される。アドレス欄１２３２とマスク値欄１２３３には、当該接続先のＩＰアドレスとネットマスク値が夫々登録される。

図１０は、管理サーバ９における要求時間テーブル９２０を示す。

要求時間テーブル９２０には、ＡＰにより要求される解析の時間である要求時間が登録される。要求時間テーブル９２０は、イベント型毎のレコードを有する。各レコードは、イベント型欄９２０１と、要求時間欄９２０２とを有する。

イベント型欄９２０１には、イベント型が登録される。要求時間欄９２０２には、当該イベント型に対する要求時間が登録される。

この図の例では、イベント型が「リアルタイム型」である場合に、ＡＰサーバ１３の要求は、イベントの発生から要求時間「５００ｍｓ」以下でＡＰサーバ１３へ個々の推定値を転送してほしいことを示す。なお、３個以上の要求時間に夫々対応して３個以上のイベント型が、要求時間テーブル９２０に登録されても良い。

図１１は、管理サーバ９における解析ロジック管理テーブル９２１を示す。

解析ロジック管理テーブル９２１は、各解析サーバ１１で実行される解析ロジックに関する情報である。管理サーバ９は、この情報を基にして解析サーバ１１で一つのイベントの解析処理にどれ程の時間かかるのかを算出する。解析ロジック管理テーブル９２１は、イベント型と解析サーバと解析ロジックとの組み合わせ毎のレコードを有する。各レコードは、イベント型欄９２１１と、解析サーバ欄９２１２には、解析サーバ１１と、解析ロジック欄９２１３とを有する。

イベント型欄９２１１には、イベント形が登録される。解析サーバ欄９２１２には、解析サーバ１１の識別のための名称が登録される。解析ロジック欄９２１３には、当該解析サーバ１１の当該イベント型に対する解析ロジックが登録される。解析時間欄９２１４には、当該解析サーバ１１で当該解析ロジックを実行した時の解析処理に要する時間である解析時間が登録される。

この図の例では、「解析サーバａ」の解析サーバ１１がリアルタイム型のイベントを解析ロジック「Ｒ１」により処理することに要する解析時間が「１２３ｍｓ」であることを示している。本実施例において管理サーバ９は、解析サーバ１１のキューが空の状態で、分散装置１によるイベントの分散を示す情報を分散装置１０から受信した時刻と、判定装置１２による当該イベントの解析の結果の受信を示す情報を判定装置１２から受信した時刻との差を解析時間として算出する。他に、分散装置１０や管理サーバ９等が擬似的なイベントを解析サーバ１１へ送信して解析結果を取得することにより、要した時間を解析時間として算出しても良い。

なお、図１のシステムにおいて、スケールアウトなどによりシステム構成を変更した場合、前述の通り、複数の解析サーバ１１それぞれの性能が異なることも考えられる。

このような状況では、例えば同じイベントを各解析サーバ１１において処理させた場合、イベントの解析処理にかかる時間は異なるものとなる。すなわち、イベントの解析処理にかかる時間は、解析サーバ１１の性能情報を含むことになる。

したがって、後述する分散を行う場合、イベントの解析処理にかかる時間を性能情報として利用することによって、解析サーバの性能を考慮した、より適切な分散が可能になる。

図１２は、管理サーバ９における接続先管理テーブル９２２を示す。

接続先管理テーブル９２２には、管理サーバ９が接続先と通信するために必要なＩＰアドレスやネットマスクの情報である。接続先は、分散装置１０、判定装置１２、解析サーバ１１等である。接続先管理テーブル９２２は、接続先毎のレコードを有する。各レコードは、区別欄９２２１と、アドレス欄９２２２と、マスク値欄９２２３とを有する。

区別欄９２２１には、接続先の名称が登録される。アドレス欄９２２２とマスク値欄９２２３には、当該接続先のＩＰアドレスとネットマスク値が夫々登録される。

図１３は、管理サーバ９における時間管理テーブル９２３を示す。

時間管理テーブル９２３は、解析サーバ１１のキューに、どんなイベントがどれだけ登録されているかを把握するための情報である。また、時間管理テーブル９２３は、リアルタイム型の分散先を決定するために用いられる見積時間を示す。管理サーバ９は、解析サーバ１１の前後に当る分散装置１０と判定装置１２から、どの解析サーバ１１へイベントを分散したかを示す情報と、どの解析サーバ１１から解析結果情報を得たかを示す情報とを夫々受信し、時間管理テーブル９２３に逐次登録する。管理サーバ９は、時間管理テーブル９２３を参照することによって、各解析サーバ１１のキューの状況を推測することができる。時間管理テーブル９２３は、管理サーバ９により分散装置１０又は判定装置１２から受信された情報毎のレコードを有する。各レコードは、解析サーバ欄９２３１と、受信元欄９２３２と、イベント型欄９２３３と、イベント種別欄９２３４と、見積時間欄９２３５と、更新時刻欄９２３５とを有する。なお、推定時間は、見積時間等に対応する。

解析サーバ欄９２３１には、分散装置１０から受信された情報に示された解析サーバ１１の識別情報、又は判定装置１２から受信された情報に示された解析サーバ１１の識別情報が登録される。受信元欄９２３２には、当該レコードの情報を分散装置１０及び判定装置１２の何れから受信したかを示す情報が登録される。イベント型欄９２３３には、分散装置１０から受信された情報に示されたイベントのイベント型、又は分散装置１０から受信された情報に示されたイベントのイベント型が登録される。イベント種別欄９２３４には、当該イベントのイベント種別が登録される。イベント種別は、クライアント７の識別情報や、クライアント７のユーザの識別情報等である。見積時間欄９２３５には、解析ロジック管理テーブル９２１で当該レコードのイベント型に対応する解析ロジックで処理を実行した場合にイベントをキューへ投入してからその解析を終了するまでの見積時間が登録される。見積時間欄９２３５には、判定装置１２より受信した見積時間は登録されない。更新時刻欄９２３５には、当該レコードが更新された時刻が登録される。管理サーバ９は、後述の解析結果登録処理により、時間管理テーブル９２３を更新する。

例えば、移動体通信システムにおいて、イベント種別は、通信端末装置の識別情報である。解析サーバ１１がイベント種別に応じて通信量等の解析を行うことにより、特定の通信端末装置への課金や帯域制御を決定することができる。

この図において二番目のレコードは、分散装置１０が「リアルタイム型」で識別子「Ｂ」のイベントを「解析サーバｂ」へ送信してから、判定装置１２が「解析サーバｂ」から解析結果情報を受信するまでの見積時間が「０．１２３ｓｅｃ」であることを示している。また四番目のレコード0は、判定装置１２が二番目のレコードに示されたイベントの解析結果情報を「解析サーバｂ」から受信したことを示している。二番目のレコードによれば、「解析サーバｂ」のキューに分散装置１０からの一つのイベントが積まれたことが分かる。そして、四番目のレコードによれば、キュー内の一つのイベントがデキューされて解析が行われ、判定装置１２がその解析結果情報を受信したことが分かる。このように、管理サーバ９は、時間管理テーブル９２３を走査することによって、各解析サーバ１１の状態を推定することができる。

図１４は、管理サーバ９における統計時間管理テーブル９２４を示す。

統計時間管理テーブル９２４は、一定時間型の分散先を決定するために用いられる平均見積時間を示す。統計時間管理テーブル９２４は、解析サーバ１１と解析ロジックの組み合わせ毎のレコードを有する。各レコードは、解析サーバ欄９２４１と、平均見積時間欄９２４２と、更新時刻欄９２４３と、総時間欄９２４４と、カウンタ欄９２４５と、解析ロジック９２４６とを有する。

解析サーバ欄９２４１には、解析サーバ１１の識別情報が登録される。平均見積時間欄９２４２には、現在の当該解析サーバ１１へ新たに当該解析ロジックのイベントを投入してから解析結果情報が出力されるまでの平均見積時間が、総時間欄９２４４とカウンタ欄９２４５との情報に基づいて算出され登録される。なお、平均見積時間は、新たに投入されるイベントの解析時間を含まなくても良い。更新時刻欄９２４３には、当該レコードが更新された時刻が登録される。総時間欄９２４４は、当該解析サーバ１１の当該解析ロジックにイベントが投入されてからその解析が完了するまでの時間の累積値である総時間が登録される。カウンタ欄９２４５は、当該解析サーバ１１の当該解析ロジックへ投入されたイベントのカウンタ値が登録される。総時間及びカウンタ値は、当該解析サーバ１１の動作開始からの累積値であっても良いし、定期的にリセットされても良い。解析ロジック９２４６には、解析ロジックの識別情報が登録される。解析ロジックの代わりに対応するイベント型の識別情報が登録されても良い。

管理サーバ９は、後述の解析結果登録処理により、統計時間管理テーブル９２４を更新する。平均見積時間欄９２４２に登録される平均見積時間は、総時間欄９２４４の総時間を、カウンタ欄９２４５のカウンタ値で割った商である。即ち、平均見積時間は、当該解析サーバ１１の当該解析ロジックのイベントを投入してから解析結果情報が出力されるまでの時間の平均値である。このように、統計時間管理テーブル９２４には、各解析サーバ１１でイベントが処理されている際の統計的な平均見積時間が登録される。統計時間管理テーブル９２４を利用することで、管理サーバ９は、解析サーバ１１のキュー状況をイベント単位で把握しなくても要求時間を満たす分散を行うことができる。なお、統計時間管理テーブル９２４は、解析サーバ１１毎のレコードを有していても良い。

図１５は、解析サーバ１１におけるロジック管理テーブル１１２０を示す。

ロジック管理テーブル１１２０は、解析サーバ１１が分散装置１０より受信したイベント毎の解析ロジックを示す。ロジック管理テーブル１１２０は、イベント型毎のレコードを有する。各レコードは、イベント型欄１１２０１と、解析ロジック欄１１２０３とを有する。

イベント型欄１１２０１には、イベント型が登録される。解析ロジック欄１１２０３には、当該イベント型のイベントを解析する解析ロジックが登録される。

図１６は、解析サーバ１１におけるキュー管理テーブル１１２１を示す。

解析サーバ１１は、分散装置１０から受信したイベントをキュー管理テーブル１１２１へ逐次登録する。また、解析サーバ１１は、キュー管理テーブル１１２１の先頭から順に逐次イベントを実行していく。キュー管理テーブル１１２１は、イベント毎のレコードを有する。各レコードは、番号（Ｎｏ．）欄１１２１１と、解析ロジック欄１１２１２と、イベント内容欄１１２１３と、受信時刻欄１１２１４とを有する。

番号欄１１２１１には、当該イベントの通し番号が登録される。解析ロジック欄１１２１２には、当該イベントの解析ロジックが登録される。イベント内容欄１１２１３には、分散装置１０から受信したイベント内容が登録される。ここでイベント内容とは、受信したイベントのデータの全てである。例えば、イベント内容は、受信されたバイナリデータである。受信時刻欄１１２１４には、当該レコードが登録された時刻が登録される。

図１７は、解析サーバ１１における接続先管理テーブル１１２３を示す。

接続先管理テーブル１１２３は、解析サーバ１１が接続先と通信するために必要なＩＰアドレスやネットマスクの情報である。接続先は、分散装置１０、判定装置１２、管理サーバ９等である。接続先管理テーブル１１２３は、接続先毎のレコードを有する。各レコードは、区別欄１１２３１と、アドレス欄１１２３２と、マスク値欄１１２３３とを有する。

区別欄１１２３１には、接続先の名称が登録される。アドレス欄１１２３２とマスク値欄１１２３３には、当該接続先のＩＰアドレスとネットマスク値が夫々登録される。

図１８は、ログ出力サーバ８における簡易分散ルール８２０を示す。

ログ出力サーバ８は、簡易分散ルール８２０に則り、複数の分散装置１０の中からイベントの送信先を選択する。簡易分散ルール８２０は、ルール欄８２０１を有する。ルール欄８２０１には、イベントの送信先を選択するための分散ロジックが登録される。

図１９は、ログ出力サーバ８における簡易分散先テーブル８２１を示す。

簡易分散先テーブル８２１には、ログ出力サーバ８がイベントを分散装置１０へ送信するために必要なＩＰアドレスやネットマスクの情報が登録される。簡易分散先テーブル８２１は、分散装置１０毎のレコードを有する。各レコードは、区別欄８２１１と、アドレス欄８２１２と、マスク値欄８２１３とを有する。

区別欄８２１１には、送信先の分散装置１０の名称が登録される。アドレス欄８２１２とマスク値欄８２１３には、当該レコードの登録先名称のＩＰアドレスとネットマスク値が登録される。

図２０は、判定装置１２における解析結果管理テーブル７２０を示す。

判定装置１２は、解析サーバ１１から受信した解析結果情報を解析結果管理テーブル７２０へ登録し、解析結果管理テーブル７２０に基づいて多数決判定等の判定を行うことにより、推定値を決定し、推定値をＡＰサーバ１３へ送信する。解析結果管理テーブル７２０は、解析結果情報毎のレコードを有する。各レコードは、番号（Ｎｏ．）欄１２２０１と、イベント型欄１２２０２と、解析サーバ欄１２２０３と、イベント種別欄１２２０４と、解析値欄１２２０５と、受信時刻欄１２２０６とを有する。

番号欄１２２０１には、当該解析結果情報の通し番号が登録される。イベント型欄１２２０２には、当該解析結果情報の対象のイベントのイベント型が登録される。解析サーバ欄１２２０３には、当該解析結果情報を出力した（当該解析結果情報の送信元の）解析サーバ１１の識別情報が登録される。イベント種別欄１２２０４には、当該イベントのイベント種別が登録される。解析値欄１２２０５には、当該解析結果情報に示された解析の結果であり、当該解析サーバ１１による解析により出力された解析値が登録される。受信時刻欄１２２０６には、当該解析結果情報を受信した時刻が登録される。判定装置１２は、解析サーバ欄１２２０３とイベント種別欄１２２０４の２つの情報を用いて各イベントを識別し、識別されたイベントを用いて判定を行う。

図２１は、管理サーバ９及び判定装置１２における分散数管理テーブル７２１を示す。

分散数管理テーブル７２１は、イベント型毎の分散数を示す。判定装置１２は、分散数管理テーブル７２１と解析結果情報の数を基にして、解析結果情報の多数決判定を行うタイミングを決定する。分散数管理テーブル７２１は、イベント型毎のレコードを有する。各レコードは、イベント型欄１２２１１と、分散数欄１２２１２とを有する。

イベント型欄１２２１１には、イベント型が登録される。分散数欄１２２１２には、当該イベント型のイベントの分散先となる解析サーバ１１の数である分散数が登録される。

図２２は、判定装置１２における通信用管理テーブル７２２を示す。

通信用管理テーブル７２２は、判定装置１２が、接続先と通信するために必要なＩＰアドレスやネットマスクの情報である。接続先は、管理サーバ９やＡＰサーバ１３等である。通信用管理テーブル７２２は、接続先毎のレコードを有する。各レコードは、区別欄１２２３１と、アドレス欄１２２３２と、マスク値欄１２２３３とを有する。

区別欄１２２３１には、接続先の名称が登録される。アドレス欄１２２３２とマスク値欄１２２３３には、当該接続先のＩＰアドレスとネットマスク値が夫々登録される。

以下、本実施例のコンピュータシステムの動作について説明する。

図２３は、管理サーバ９による分散数情報送信処理を示す。

管理サーバ９の管理機能９１０は、管理者からの入力に従って、分散数管理テーブル７２１の内容を登録する。管理機能９１０は、分散数管理テーブル７２１の内容を分散装置１０と判定装置１２へ送信する分散数情報送信処理を行う。

管理機能９１０は、分散数管理テーブル７２１の内容を取得する（ステップＳ３４１）。次に、管理機能９１０は、ステップＳ３４１で取得した情報を分散数情報として分散装置１０と判定装置１２へ送信する（ステップＳ３４２）。分散数情報は、イベント型毎の分散数を示す。以上が分散数情報送信処理である。

図２４は、管理サーバ９によるキュー統計情報送信処理を示す。

管理サーバ９の管理機能９１０は、統計時間管理テーブル９２４に基づいて解析サーバ１１のキューの状況を示すキュー統計情報を定期的に分散装置１０へ送信するキュー統計情報送信処理を行う。

管理機能９１０は、統計時間管理テーブル９２４のレコードが登録済であるか否かを確認する（ステップＳ２６１）。管理機能９１０は、ステップＳ２６１でレコードが登録済であると判定された場合、処理をステップＳ２６２へ移し、レコードが登録されていないと判定された場合、処理をステップＳ２６３へ移す。ステップＳ２６１でレコードが登録済であると判定された場合、管理機能９１０は、分散装置１０が一定時間型のイベントの分散先を決定するための情報として、キュー統計情報を分散装置１０へ送信する（ステップＳ２６２）。キュー統計情報は、統計時間管理テーブル９２４の解析サーバ欄９２４１及び平均見積時間欄９２４２の情報を含む。次に、管理機能９１０は、一定時間スリープ（待機）する（ステップＳ２６３）。そして、管理者からのアボート指示の入力の有無を確認し、アボート指示がある場合はキュー統計情報送信処理を終了し、アボート指示がない場合、処理をステップＳ２６１へ戻す（ステップＳ２６４）。なお、管理機能９１０は、平均見積時間に基づいて各解析サーバ１１が要求時間を満たせるか否かを判定し、要求時間を満たせないと判定された解析サーバ１１をキュー統計情報から除いても良い。以上がキュー統計情報送信処理である。

図２５は、分散装置１０による分散順位更新処理を示す。

前述のキュー統計情報送信処理により管理サーバ９からキュー統計情報を受信した分散装置１０の分散機能１１１は、キュー統計情報に基づいて分散管理テーブル１２１を更新する分散順位更新処理を行う。

分散機能１１１は、管理サーバ９からキュー統計情報を受信する（ステップＳ２７１）。次に、分散機能１１１は、キュー統計情報に基づき、分散管理テーブル１２１を更新する（ステップＳ２７２）。ここで分散機能１１１は、キュー統計情報に示された解析サーバ１１毎の平均見積時間に基づいて、一定時間型のイベントの分散先となる解析サーバ１１の優先順位を決定し、分散管理テーブル１２１において一定時間型に対応する分散順位欄１２１２へ登録する。更に分散機能１１１は、そのレコードを更新した時刻を更新時刻欄１２１３に登録する。以上が分散順位更新処理である。また、前述の分散数情報送信処理により管理サーバ９から分散数情報を受信した分散装置１０の分散機能１１１は、分散数情報に示された分散数を分散数管理テーブル７２１へ登録する。

図２６は、ログ出力サーバ８によるイベント送信処理を示す。

クライアント７から要求を受信したログ出力サーバ８のノード機能８１０は、その要求に対応する処理を行った後、その処理を示すアクセスログをイベントとして分散装置１０へ送信するイベント送信処理を行う。

ノード機能８１０は、クライアント７から要求を受信する（ステップＳ２９１）。次に、ノード機能８１０は、ステップＳ２９１で受信した要求を処理し、そのアクセスログを生成する（ステップＳ２９２）。簡易分散機能８１１は、分散先テーブル８２１に登録された分散装置１０の中から、簡易分散ルール８２０に沿ってイベント送信先の分散装置１０を選択する（ステップＳ２９３）。そして、ノード機能８１０は、生成されたアクセスログからイベントを生成し、そのイベントをイベント送信先へ送信する（ステップＳ２９４）。ここで生成されるイベントは、イベント型識別テーブル１２２の内容に沿っており、イベント型に応じたプロトコル及びヘッダを有する。以上がイベント送信処理である。

図２７は、分散装置１０による分散処理を示す。

ログ出力サーバ８からイベントを受信した分散装置１０の分散機能１１１は、分散先の解析サーバ１１を決定して、イベントを送信する分散処理を行う。

分散機能１１１は、ログ出力サーバ８からイベントを受信する（ステップＳ２８１）。次に、分散機能１１１は、イベント型識別テーブル１２２に基づいて、受信されたイベントのイベント型を識別し、リアルタイム型であれば処理をステップＳ２８３へ移し、リアルタイム型以外であれば処理をステップＳ２８７へ移す（ステップＳ２８２）。ここで分散機能１１１は、分散機能１１１は、イベント型識別テーブル１２２のプロトコル欄１２２２とヘッダ欄１２２３の情報を基に、受信したイベントのプロトコル及びヘッダを判定し、それらに対応するイベント型欄１２２１のイベント型を取得する。その情報を基に、ステップＳ２８２で判定を行う。

ステップＳ２８２でイベント型がリアルタイム型と判定されなかった（一定時間型と判定された）場合（ステップＳ２８２：Ｎ）、分散機能１１１は、分散管理テーブル１２１を参照し、イベント型欄１２１１に合致する分散先を取得し（ステップＳ２８７）、処理をステップＳ２８５へ移す。ここで分散機能１１１は、分散順位欄１２１２の分散順位に示されている複数の解析サーバ１１の中から、上位から分散数欄１２１４の分散数だけの解析サーバ１１を分散先として選択する。

ステップＳ２８２でイベント型がリアルタイム型と判定された場合（ステップＳ２８２：Ｙ）、分散機能１１１は、管理サーバ９から分散先を取得する（ステップＳ２８３）。ここで分散機能１１１は、分散先問合せを管理サーバ９へ送信し、その分散先問合せに対する分散先応答を管理サーバ９から受信し、その分散先応答に含まれた分散先を取得する。

分散機能１１１は、ステップＳ２８１で受信したイベントを、ステップＳ２８４又はステップＳ２８７で取得した解析サーバ１１の分散先へ転送する（ステップＳ２８５）。そして、分散機能１１１は、その分散先を示す分散先情報を管理サーバ９へ送信する（ステップＳ２８６）。分散先情報は、分散装置１０により送信されたイベントのイベント型及びイベント種別、分散先の解析サーバ１１の識別情報等を含む。以上が分散処理である。

分散先として或るイベント送信された複数の解析サーバ１１の夫々は、そのイベントを同一の解析ロジックで解析する。

なお、分散機能１１１は、リアルタイム型のイベントを分散させるにあたって、予め定められた選択数まで、キューに登録されたイベントの数が少ない解析サーバ１１を選択しても良い。

なお、ステップＳ２８２以降において、分散装置１０は、受信したイベントがリアルタイム型である場合に、ステップＳ２８７と同様、分散管理テーブル１２１から分散先を取得し、受信したイベントがリアルタイム型でない場合に、ステップＳ２８３及びＳ２８４と同様、分散先問合せにより管理サーバ９から分散先を取得しても良い。

この処理によれば、分散装置１０は、一定時間型のイベントの解析に適した分散先を選択することができる。また、分散装置１０は、リアルタイム型のイベントの解析に適した分散先を管理サーバ９から取得することができる。

図２８は、管理サーバ９による分散先応答処理を示す。

前述の分散処理により分散装置１０から分散先問合せを受信した管理サーバ９の管理機能９１０は、その分散装置１０へ分散先を示す分散先応答を送信する分散先応答処理を行う。

管理機能９１０は、分散装置１０から分散先問合せを受信する（ステップＳ２５１）。次に、管理機能９１０は、時間管理テーブル９２３内の見積時間が短い順に、対象のイベント型の分散数の解析サーバ１１を選択する（ステップＳ２５３）。ここで管理機能９１０は、分散数管理テーブル７２１を参照することにより対象のイベント型の分散数を取得する。本実施例において対象のイベント型は、リアルタイム型である。更に管理機能９１０は、時間管理テーブル９２３において各解析サーバ１１におけるキューの状況を示す見積時間（待ち時間）を参照し、見積時間が短い順に分散数だけの解析サーバ１１を分散先として選択する。次に、管理機能９１０は、分散先問合せの応答として、分散先を示す分散先応答を、分散先問合せの送信元の分散装置１０へ送信する（ステップＳ２５７）。なお、管理機能９１０は、見積時間に基づいて各解析サーバ１１が要求時間を満たせるか否かを判定し、要求時間を満たせないと判定された解析サーバ１１を分散先応答から除いても良い。以上が分散先応答処理である。

ここで、管理機能９１０は、個々の分散先問合せに対してその都度ステップＳ２５２の処理を繰り返してもよいが、効率を考えて、分散先応答処理の途中経過を複数の分散先問合せの間で共有してもかまわない。

この処理によれば、管理サーバ９は、リアルタイム型のイベントの解析に適した分散先を選択し、分散装置１０へ伝えることができる。

図２９は、管理サーバ９による分散先登録処理を示す。

前述の分散処理により分散装置１０から分散先情報を受信した管理サーバ９の管理機能９１０は、分散装置１０から受信した分散先情報を時間管理テーブル９２３へ登録する分散先登録処理を行う。分散先情報は、分散装置１０による分散先を示し、分散管理テーブル１２１の分散順位欄１２１２に示された解析サーバ１１の上位から分散数だけの解析サーバ１１の識別情報等を含む。

管理機能９１０は、分散装置１０から分散先情報を受信する（ステップＳ２３１）。次に、管理機能９１０は、ステップＳ２３１で取得した分散装置１０がイベントを分散した先の解析サーバ１１の識別情報及びイベント種別等の情報を時間管理テーブル９２３へ登録する（ステップＳ２３２）。以上が分散先登録処理である。

図３０は、解析サーバ１１による解析処理を示す。

前述の分散処理により分散装置１０からイベントを受信した解析サーバ１１の解析機能１１１０は、そのイベントを解析する解析処理を行う。

解析サーバ１１の解析機能１１１０は、分散装置１０からイベントを受信する（ステップＳ３０１）。次に、解析機能１１１０は、イベント型識別テーブル１２２を参照し、受信されたイベント型を識別する（ステップＳ３０２）。ここでの識別方法は、分散先更新処理のステップＳ２８２と同様の方法である。

解析機能１１１０は、ロジック管理テーブル１１２０を参照し、識別されたイベント型に対応する解析ロジックを決定する（ステップＳ３０３）。次に、解析機能１１１０は、キュー管理機能１１１１を利用して、キュー管理テーブル１１２１へステップＳ３０１で受信したイベントを登録する。その後、解析機能１１１０は、キュー管理テーブル１１２１の上位のイベントから順に解析を行い、その結果を示す解析結果情報を生成する（ステップＳ３０４）。解析結果情報は、解析の対象となったイベントのイベント型及びイベント種別や、その解析の結果である解析値を含む。そして、解析機能１１１０は、その解析結果情報を判定装置１２へ送信する（ステップＳ３０５）。ここで複数の判定装置１２が存在する場合、解析機能１１１０は、例えばキュー管理テーブル１１２１のイベント内容欄１１２１３のイベント内容のハッシュ値による収容分散を行うことにより、複数の判定装置１２の中から解析結果情報の送信先の判定装置１２を選択する。

図３１は、判定装置１２による分散数情報更新処理を示す。

前述の分散数情報送信処理により管理サーバ９から分散数情報を受信した判定装置１２の判定機能１２１０は、分散数情報更新処理を行う。

判定機能１２１０は、管理サーバ９から分散数情報を受信する（ステップＳ３１１）。次に、判定機能１２１０は、受信された分散数情報を基に、イベント型毎の分散数を分散数管理テーブル７２１へ登録する（ステップＳ３１２）。以上が分散数情報更新処理である。

図３２は、判定装置１２による解析結果判定処理を示す。

前述の解析処理により解析サーバ１１から解析結果情報を受信した判定装置１２の判定機能１２１０は、多数決判定を行う解析結果判定処理を行う。

判定機能１２１０は、解析サーバ１１から解析結果情報を受信する（ステップＳ３２１）。次に、判定機能１２１０は、受信された解析結果情報を解析結果管理テーブル７２０へ登録する（ステップＳ３２２）。次に判定機能１２１０は、解析結果情報の受信を示す解析結果受信情報を管理サーバ９へ送信する（ステップＳ３２３）。解析結果受信情報は、解析結果情報に示されたイベント型、イベント種別、解析値を含む。次に判定機能１２１０は、当該解析結果情報のイベント型に対応する分散数を分散数管理テーブル７２１から取得し、解析結果管理テーブル７２０から同一のイベント型及び同一のイベント種別を有する解析結果情報に示された解析値の中で、同一の解析値の数をカウントする。次に判定機能１２１０は、特定の解析値の数が対象の分散数の過半数に達した（対象の分散数の半数を超えた）か否かを判定する（ステップＳ３２４）。ここで判定機能１２１０は、カウントされた解析結果情報の数が分散数の過半数に達した場合、処理をステップＳ３２５へ移し、分散数の過半数に達しなかった場合、処理をステップＳ３２１へ移す。

ステップＳ３２４で解析結果情報の数が分散数の過半数に達したと判定された場合、判定機能１２１０は、ステップＳ３２４で抽出された解析結果情報の中から、解析値毎の解析結果情報の数をカウントする。その後、判定機能１２１０は、解析値毎の解析結果情報の数を比較することにより、多数決判定を行う（ステップＳ３２５）。

そして、判定機能１２１０は、抽出された解析結果情報の解析値の中から、多数決判定により最も多いと判定された解析値を推定値として選択し、推定値をＡＰサーバ１３へ送信する（ステップＳ３２６）。以上が解析結果判定処理である。

この処理によれば、最も確率の高い解析値を推定値として選択することができ、推定値の信頼性を高めることができる。また、判定機能１２１０は、全ての解析結果情報を待たずに推定値を決定することができ、推定値の決定までの時間を短縮することができる。

解析値がＹＥＳ／ＮＯといった白黒が付く結果（２値）であれば、判定機能１２１０は、それぞれの解析値の総数をカウントし、総数が多い方の解析値を正しいと判定する。一方、解析値が数値（多値）で表されるような結果である場合、例えば判定機能１２１０は、全ての解析値の平均値を推定値としても良いし、解析値の確率分布を算出し、その確率分布から期待値を算出して推定値としても良い。

２値の解析値の多数決判定を行うにあたっては、分散数が奇数であることが望ましい。本実施例においては、分散数（解析サーバ１１の数）は奇数としている。ただし、対象となる解析結果情報の総数が多い場合、多数決判定を行う際に、２値が同数に近くなる可能性は確率的に低くなる。このような場合、偶数であってもさほど問題とはならない。ただし、２値が同数に至る可能性も排除できないため、判定機能１２１０は、その場合の対応手段も有する。

判定機能１２１０は、解析値の複数の値が同数に至った場合、予め定められた指定値を推定値として選択しても良い。この場合、管理サーバ９は、管理者から入力された指定値を判定装置１２へ送信しても良い。また、判定機能１２１０は、複数の値の総数に予め定められた重み付けを与え、重み付けされた総数に基づいて複数の値の一つを推定値として選択しても良い。この場合、管理サーバ９は、管理者から入力された重み付けを判定装置１２へ送信しても良い。

また、特に分散数（解析サーバ１１の数）が多い場合、判定機能１２１０は、多数決判定を行うために或る解析値の数が分散数の過半数に達する数まで待つ必要がなく、予め定められた判定数に達した解析値を推定値として選択し、ＡＰサーバ１３へ送信しても良い。これにより、分散数が多くても推定値を得るまでの時間を抑えることができる。この場合、管理サーバ９は、管理者から入力された判定数を判定装置１２へ送信しても良い。

図３３は、管理サーバ９による解析結果登録処理を示す。

前述の解析結果判定処理により判定装置１２から解析結果受信情報を受信した管理サーバ９の管理機能９１０は、その解析結果受信情報を時間管理テーブル９２３及び統計時間管理テーブル９２４へ登録する解析結果受信状況登録処理を行う。解析結果受信情報は、判定装置１２による解析結果情報の受信の状況を示し、例えば、解析結果管理テーブル７２０の解析サーバ欄１２２０３や、イベント種別１２２０４等を含む。

管理機能９１０は、判定装置１２から解析結果受信情報を受信する（ステップＳ２４１）。次に、管理機能９１０は、ステップＳ２４１で取得した解析結果受信情報に基づく情報を時間管理テーブル９２３及び統計時間管理テーブル９２４へ登録する。（ステップＳ２４２）。

ここで管理機能９１０は、時間管理テーブル９２３のレコードを作成し、解析結果受信情報に示された解析サーバ１１の識別情報、イベント型、イベント種別を、当該レコードの解析サーバ欄９２３１、イベント型欄９２３３、イベント種別欄９２３４へそれぞれ登録する。更に管理機能９１０は、これらの情報を判定装置１２から受信したことを受信元欄９２３２へ登録する。更に管理機能９１０は、当該レコードを更新した時刻を当該レコードの更新時刻欄９２３５へ登録する。

更に管理機能９１０は、分散先情報に基づいて時間管理テーブル９２３に登録されたレコードの更新時刻（分散先登録処理のステップＳ２３２）と、対応する解析結果受信情報に基づいて時間管理テーブル９２３に登録されたレコードの更新時刻（解析結果登録処理のステップＳ２４２）との差を見積時間として算出し、当該レコードの見積時間欄９２３５へ登録する。

更に管理機能９１０は、統計時間管理テーブル９２４において、当該レコードの解析サーバ１１及びイベント型の解析ロジックに対応するレコードの総時間に、算出された見積時間を加えることにより新たな総時間を算出し、当該レコードの総時間欄９２４４を更新する。更に管理機能９１０は、当該レコードのカウンタ値に１を加えることにより新たなカウンタ値を算出し、当該レコードのカウンタ欄９２４５を更新する。更に管理機能９１０は、当該レコードの総時間をカウンタ値で除することにより平均見積時間を算出し、当該レコードの平均見積時間欄９２４２を更新する。以上が解析結果登録処理である。

この処理によれば、管理サーバ９は、解析サーバ１１との通信を行うことなく、分散装置１０及び判定装置１２との通信から、イベントが解析サーバ１１に投入されてから、そのイベントの解析が完了するまでの所要時間を推定することができる。この時間は、見積時間として、リアルタイム型の分散先の選択に用いられる。また、管理サーバ９は、見積時間の平均値を算出して分散装置１０へ送信することにより、イベント毎のキューの状態を分散装置１０へ送信する必要がなく、ネットワークの負荷を抑えることができる。この平均値は、平均見積時間として、一定時間型の分散先の選択に用いられる。

本実施例によれば、クライアントのアクセス等によって発生したログを対象として解析を行って、その結果をアプリケーションが利用するシステムにおいて、ＡＰによる要求時間に応じて、分散先の決定方法を選択することにより、ＣＥＰの負荷分散の効率を向上させ、解析システムの効率を向上させることができる。

ＡＰサーバ１３には、短い要求時間内に解析結果を得ることを要求するＡＰや、それより長い要求時間内に解析結果を得られれば良いＡＰ等が混在する場合がある。以上の実施例によれば、ＡＰにより定められた要求時間に対応するイベント型を判定し、イベント型に応じて、解析を行う解析サーバを選択し、解析の負荷を分散させることにより、複数のアプリケーションのそれぞれの要求を満たすように解析を実行することが可能である。従来の解析サーバへの負荷分散においては、ＡＰにより定められた要求時間に応じた分散が考慮されていない。そのため、要求時間を満たしつつ、イベントの種類に応じて効率良く分散させることは出来ない。

また、従来のスケールアウトによって解析システムの処理性能を向上させる場合、解析サーバの増加によるコストの増加が問題になる。本実施例では、複数の解析サーバで同じ解析を分散させ、解析を並列実行させ、複数の解析値から推定値を算出することにより、解析サーバ１１の信頼性が低い場合であっても、推定値の信頼性を高めることができる。これにより、解析サーバ１１は、汎用ＰＣ（Personal Computer）のハードウエアや、ＯＳＳ（Open Source Software）の解析ロジックを用いることができる。

従って、以上の実施例は、高性能で高価な解析サーバを必要とせず、解析を担うソフトウエア費用を削減でき、解析システムのコストダウンを図ることが可能となる。

また、本実施例によれば、解析システムによる解析を止めることなく、複数の解析サーバ１１の一部のハードウエア又はソフトウエアの交換を行うことができる。この交換により、複数の解析サーバ１１の一部の信頼性が低下した場合でも、複数の解析値から推定値を算出することにより、推定値の信頼性を維持することができる。これにより、解析サーバ１１のバージョンアップ等を容易に行うことができる。

従来、或る解析サーバにより実行されているＣＥＰを特定の解析サーバへ移動させる技術は、移動中にＣＥＰの解析を停止させる必要がある。一方、本実施例によれば、一つのイベントの解析を複数の解析サーバ１１へ分散させるため、解析を行う解析サーバ１１を変更する場合でも、他の解析サーバ１１が解析を継続し、複数の解析値から推定値を算出することにより、解析システムの停止を防ぐことができる。

実施例１では、管理サーバ９は、分散装置１０から分散先情報を受信した時刻と、判定装置１２から解析結果受信情報を受信した時刻とから、解析サーバ１１のキューの状態、要するに、解析サーバ１１の負荷を推測する方法を説明した。

実施例２では、管理サーバ９は、解析サーバ１１からキューの状態を示す情報を受信することにより、解析サーバ１１のキューの状態を把握する方法、要するに、解析サーバ１１から負荷を示す情報を取得し、その負荷を把握する方法を説明する。

以下、実施例１との相違点を中心に説明する。

図３４は、実施例２の管理サーバ９の構成を示す。

実施例１の管理サーバ９のメモリ９０７と比較すると、本実施例の管理サーバ９のメモリ９０７は、新たに解析サーバ状態管理テーブル９２５を格納する。なお、本実施例においては、時間管理テーブル９２３が省かれても良い。

管理サーバ９の管理機能９１０は、解析サーバ１１へキュー情報の問合せを送信する。その問合せを受信した解析サーバ１１は、自身のキューの状態を示すキュー情報を管理サーバ９へ送信する。キュー情報を受信した管理機能９１０は、キュー情報に基づく情報を解析サーバ状態管理テーブル９２５へ登録する。キュー情報は例えば、当該解析サーバ１１のキュー長（キューに溜まっている処理待ちイベント数）を含む。

図３５は、実施例２の管理サーバ９における解析サーバ状態管理テーブル９２５を示す。

解析サーバ状態管理テーブル９２５は、解析サーバ１１毎のレコードを有する。各レコードは、解析サーバ欄９２５１と、キュー長欄９２５２と、見積時間欄９２５３と、更新時刻欄９２５４欄とを有する。

解析サーバ欄９２５１には、解析サーバ１１の識別情報が登録される。キュー長欄９２５２には、当該解析サーバ１１のキュー長が登録される。見積時間欄９２５３には、新たに当該解析サーバ１１のキューへ積んだイベントの解析が完了するまでの見積時間（待ち時間）が登録される。言い換えれば、この見積時間は、現在のキューに登録されているイベントの解析時間の総和である。更新時刻欄９２５４欄には、当該レコードが更新された時刻が登録される。

キュー情報を受信した管理機能９１０は、送信元の解析サーバ１１の識別情報と、キュー情報に含まれたキュー長と、キュー情報を受信した時刻とを、解析サーバ状態管理テーブル９２５へ登録する。更に管理機能９１０は、解析ロジック管理テーブル９２１内の解析時間に、解析サーバ１１から受信したキュー情報内のキュー長を乗じることにより、見積時間を算出し、解析サーバ状態管理テーブル９２５へ登録する。

実施例１において、管理サーバ９は、解析サーバ１１の前後に配される分散装置１０及び判定装置１２から、分散先情報及び解析結果受信情報をそれぞれ取得し、これらを取得した時刻を基にして、各解析サーバ１１のキューの状況、要するに、負荷を推測し、推測した結果を時間管理テーブル９２３の見積時間として格納する。

一方、実施例２において、管理サーバ９は、解析サーバ１１へ問合せを行ってキューの状況、要するに、負荷情報を取得し、取得した結果を解析サーバ状態管理テーブル９２５の見積時間として格納する。実施例１の時間管理テーブル９２３の見積時間の代わりに、解析サーバ状態管理テーブル９２５の見積時間を用いることにより、実施例１と同様の制御を行うことができると共に、その制御の精度を向上させることができる。

なお、分散装置１０は、解析サーバ１１のキュー長を管理サーバ９経由で取得し、取得されたキュー長を分散管理テーブル１２１へ記憶することで、解析サーバ１１のキューの状況を把握、要するに、負荷情報を取得しても良い。更に、分散装置１０が、新たにイベントのキューを有し、例えば一定時間型イベントの分散を行う際に、解析サーバ１１のキュー長の情報を基にして、解析サーバ１１のキューが一定量を超えないよう、イベントを分散装置１０のキューへ格納すると共に分散先を決めて、要するに、取得した負荷情報に基づき、各解析サーバ１１に係る負荷が所定量を超えないように、イベント転送を制御しても良い。

実施例３では、或るログ出力サーバ８における一連のイベントが同一の解析サーバ１１により解析される。

以下、実施例１との相違点を中心に説明する。

図３６は、実施例３の分散装置１０の構成を示す。

実施例１の分散装置１０と比較すると、本実施例の分散装置１０のメモリ１０７は、更にセッション管理テーブル１２４を格納する。

図３７は、実施例３の分散装置１０におけるセッション管理テーブル１２４を示す。

セッション管理テーブル１２４は、クライアント７とログ出力サーバ８の間に張られたセッションと、解析サーバ１１との対応付けを示す。セッション管理テーブル１２４は、セッション毎のレコードを有する。各レコードは、セッションＩＤ欄１２４１と、分散先欄１２４２と、イベント型欄１２４３と、イベント種別欄１２４４とを有する。

セッションＩＤ欄１２４１には、クライアント７とログ出力サーバ８の間に張られたセッションの識別情報が登録される。分散先欄１２４２には、当該セッション内のイベントが転送された分散先の解析サーバ１１の識別情報が登録される。イベント型欄１２４３には、転送されたイベントのイベント型が登録される。イベント種別欄１２４４には、転送されたイベントのイベント種別が登録される。

セッションとは、アクセス単位の１つであり、クライアント７とログ出力サーバ８の間で通信を行うための、論理的な接続関係である。

図３８は、実施例３の分散装置１０による分散処理を示す。

実施例１の分散処理と比較すると、本実施例の分散処理は、ステップＳ２８３の代わりに、ステップＳ３５１〜Ｓ３５６を有する。

ステップＳ２８１の後、分散装置１０の分散機能１１１は、受信されたイベントが新たなセッションの開始であるか否かを判定する（ステップＳ３５１）。ここで、セッションの開始時のイベントは、セッションの開始を示す情報を含んでいても良い。この場合、分散機能１１１は、受信されたイベントが新たなセッションの開始を示す情報を含むか否かを判定しても良い。また、分散機能１１１は、セッション管理テーブル１２４内に、受信されたイベントのイベント型及びイベント種別に対応するセッションのレコードがあるか否かを判定しても良い。

受信されたイベントが新たなセッションの開始であると判定された場合（ステップＳ３５１：Ｙ）、分散機能１１１は、実施例１と同様のステップＳ２８２により、当該イベントのイベント型がリアルタイム型であるか否かを判定する。イベント型がリアルタイム型であると判定された場合、分散機能１１１は、実施例１と同様のステップＳ２８３により、管理サーバ９から分散先を取得し、処理をステップＳ３５３へ移す。イベント型がリアルタイム型でない（一定時間型である）と判定された場合、実施例１と同様のステップＳ２８７により、分散管理テーブル１２１に基づいて分散先を決定し、処理をステップＳ３５３へ移す。その後、分散機能１１１は、セッション管理テーブル１２４において、開始されたセッションのレコードを作成し（ステップＳ３５３）、処理を実施例１と同様のステップＳ２８５へ移す。

受信されたイベントが新たなセッションの開始でないと判定された場合（ステップＳ３５１：Ｎ）、分散機能１１１は、セッション管理テーブル１２４において、受信されたイベントに対応するセッションのレコードを選択し、そのレコードに示された分散先の解析サーバ１１を分散先として選択する（ステップＳ３５４）。ここで、分散機能１１１は、セッション管理テーブル１２４において、イベント型欄１２４３及びイベント種別欄１２４４に夫々示されたイベント型及びイベント種別が、受信されたイベントと一致するレコードを選択する。その後、分散機能１１１は、セッション管理テーブル１２４において、選択されたレコードの分散先欄１２４２に示された分散先の解析サーバ１１を選択する。

その後、分散機能１１１は、受信されたイベントがセッションの終了であるか否かを判定する（Ｓ３５５）。ここで、セッションの終了時のイベントは、セッションの終了を示す情報を含んでいても良い。この場合、分散機能１１１は、受信されたイベントが新たなセッションの終了を示す情報を含むか否かを判定しても良い。

受信されたイベントがセッションの終了でないと判定された場合（ステップＳ３５５：Ｎ）、分散機能１１１は、処理をステップＳ２８５へ移す。

受信されたイベントがセッションの終了であると判定された場合（ステップＳ３５５：Ｙ）、分散機能１１１は、セッション管理テーブル１２４において、選択されたセッションのレコードを削除し、処理を実施例１と同様のステップＳ２８５へ移す。以後の処理は実施例１と同様である。以上が、本実施例の分散処理である。

なお、分散機能１１１は、セッションの代わりに、トランザクション等、他の一連の操作内のイベントを同一の分散先へ送信しても良い。

本実施例によれば、解析サーバ１１は、一連のイベントの解析を行うことができる。例えば、ログ出力サーバ８において、或るイベントと、それに続くイベントが関連している場合に、分散装置１０は、それらのイベントを同一の解析サーバ１１へ転送することにより、その解析サーバ１１は、それらのイベントを用いて解析を行うことができる。これにより、複数のイベントにより夫々示される値の変化を解析する場合や、或るクライアント７による一連の操作を解析する場合等であっても、適切な負荷分散を行うことができる。例えば、或る株価の変動を解析する場合や、クライアント７における一連の操作を解析する場合に本実施例を適用することができる。

本発明は、以上の実施例に限定されるものでなく、その趣旨から逸脱しない範囲で、他の様々な形に変更することができる。

５、６、１４、１５、１６、１７、１８、１９：ネットワーク、 ７：クライアント、 ８：ログ出力サーバ、 ９：管理サーバ、 １０：分散装置、 １１：解析サーバ、 １２：判定装置、 １３：ＡＰサーバ

Claims (18)

1. ｎ個（ｎは３以上）の処理装置に接続された分散装置と、
   前記分散装置に接続された管理装置と、を備える処理制御システムであって、
   前記管理装置は、
   前記ｎ個の処理装置の夫々について、処理対象情報の処理において要した時間を示す時間情報を取得し、
   前記ｎ個の処理装置の夫々が前記処理対象情報の処理に掛かる所要時間を、前記時間情報に基づいて推定して推定時間とし、
   前記推定時間及び前記処理装置の関係を示す推定時間情報を前記分散装置へ送信し、
   前記分散装置は、
   セッションの開始を示す処理対象情報と前記推定時間情報とに基づいて、前記処理装置のｍ個（１＜ｍ＜ｎ）を、前記セッションに属する一連の処理対象情報を処理させる指定処理装置と決定し、
   前記一連の処理対象情報を、前記ｍ個の指定処理装置へ送信する
   ことを特徴とする処理制御システム。
2. 請求項１に記載の処理制御システムであって、
   前記管理装置は、
   前記時間情報に基づいて過去の所要時間に関する所要時間情報を記憶し、
   前記所要時間情報に基づいて前記過去の所要時間の平均値を算出して前記推定時間とし、
   当該推定時間を、前記ｍ個の指定処理装置の決定に用いる
   ことを特徴とする処理制御システム。
3. 請求項２に記載の処理制御システムであって、
   前記管理装置は、前記ｎ個の処理装置の夫々の前記推定時間を示す前記推定時間情報と、前記指定処理装置の数を示すｍとを前記分散装置へ送信し、
   前記セッションの開始を示す処理対象情報が所定の第１分類に属する場合、前記分散装置は、前記ｎ個の処理装置の中から前記推定時間が短い順に前記ｍ個の指定処理装置を選択する
   ことを特徴とする処理制御システム。
4. 請求項１から３のいずれか一に記載の処理制御システムであって、
   前記セッションの開始を示す処理対象情報が所定の第２分類に属する場合、前記分散装置は、前記推定時間情報の問合せを前記管理装置へ送信し、
   前記管理装置は、前記問合せを受信した場合、
   前記ｎ個の処理装置の中から前記推定時間が短い順に前記ｍ個の指定処理装置を選択し、
   前記ｍ個の指定処理装置を示す前記推定時間情報を前記分散装置へ送信する
   ことを特徴とする処理制御システム。
5. 請求項１から４のいずれか一に記載の処理制御システムであって、
   前記管理装置は、
   前記ｎ個の処理装置の夫々のキューの状態を示すキュー情報を、前記ｎ個の処理装置から受信し、
   前記キュー情報に基づいて前記時間情報を算出する
   ことを特徴とする処理制御システム。
6. 請求項１に記載の処理制御システムであって、
   前記ｎ個の処理装置に接続された処理結果判定装置を備え、
   前記ｍ個の指定処理装置の夫々は、
   前記処理対象情報を処理することにより処理結果を算出し、
   前記処理結果を前記処理結果判定装置へ送信し、
   前記処理結果判定装置は、
   前記ｍ個の指定処理装置からｍ個の処理結果を夫々受信し、
   所定の方法により前記ｍ個の処理結果から真の値を推定して推定値とし、
   他の処理装置へ前記推定値を送信する
   ことを特徴とする処理制御システム。
7. 請求項６に記載の処理制御システムであって、
   前記処理対象情報に対して、前記推定時間の上限が予め定められており、
   前記管理装置は、前記推定時間情報を前記分散装置へ送信し、
   前記分散装置は、前記推定時間情報に基づいて、前記上限を満たす処理装置の中から前記ｍ個の指定処理装置を決定する
   ことを特徴とする処理制御システム。
8. 請求項６または７に記載の処理制御システムであって、
   前記処理結果判定装置は、
   処理結果毎に受信された数をカウントし、
   前記ｍ個の処理結果の中で、最も多く受信された処理結果を前記推定値として選択する
   ことを特徴とする処理制御システム。
9. 請求項８に記載の処理制御システムであって、
   前記管理装置は、前記指定処理装置の数を示すｍを前記処理結果判定装置へ送信し、
   前記処理結果判定装置は、
   前記最も多く受信された処理結果の数が、前記ｍの半数を超えた場合、前記最も多く受信された処理結果を前記推定値として選択し、
   前記推定値を前記処理装置へ送信する
   ことを特徴とする処理制御システム。
10. ｎ個（ｎは３以上）の処理装置を備えるシステムにおける情報の処理方法であって、
    前記ｎ個の処理装置の夫々について、処理対象情報の処理において要した時間を示す時間情報を取得し、
    前記ｎ個の処理装置の夫々が前記処理対象情報の処理に掛かる所要時間を、前記時間情報に基づいて推定して推定時間とし、
    セッションの開始を示す処理対象情報と、前記推定時間及び前記処理装置の関係を示す推定時間情報とに基づいて、前記処理装置のｍ個（１＜ｍ＜ｎ）を、前記セッションに属する一連の処理対象情報を処理させる指定処理装置と決定し、
    前記一連の処理対象情報を、前記ｍ個の指定処理装置に処理させる
    ことを特徴とする情報の処理方法。
11. 請求項１０に記載の情報の処理方法であって、
    前記時間情報に基づいて過去の所要時間に関する所要時間情報を記憶し、
    前記所要時間情報に基づいて前記過去の所要時間の平均値を算出して前記推定時間とし、
    当該推定時間を、前記ｍ個の指定処理装置の決定に用いる
    ことを特徴とする情報の処理方法。
12. 請求項１１に記載の情報の処理方法であって、
    分散装置が前記ｎ個の処理装置に接続され、管理装置が前記分散装置に接続され、
    前記管理装置が、前記ｎ個の処理装置の夫々の前記推定時間を示す前記推定時間情報と、前記ｍ個の指定処理装置の数を示すｍとを前記分散装置へ送信し、
    前記セッションの開始を示す処理対象情報が所定の第１分類に属する場合、前記分散装置が、前記ｎ個の処理装置の中から前記推定時間が短い順に前記ｍ個の指定処理装置を選択する
    ことを特徴とする情報の処理方法。
13. 請求項１０から１２のいずれか一に記載の情報の処理方法であって、
    分散装置が前記ｎ個の処理装置に接続され、管理装置が前記分散装置に接続され、
    前記セッションの開始を示す処理対象情報が所定の第２分類に属する場合、前記分散装置が、前記推定時間情報の問合せを前記管理装置へ送信し、
    前記管理装置が、前記問合せを受信した場合、
    前記ｎ個の処理装置の中から前記推定時間が短い順に前記ｍ個の指定処理装置を選択し、
    前記ｍ個の指定処理装置を示す前記推定時間情報を前記分散装置へ送信する
    ことを特徴とする情報の処理方法。
14. 請求項１０から１３のいずれか一に記載の情報の処理方法であって、
    前記ｎ個の処理装置の夫々のキューの状態を示すキュー情報を、前記ｎ個の処理装置から受信し、
    前記キュー情報に基づいて前記時間情報を算出する
    ことを特徴とする情報の処理方法。
15. 請求項１０に記載の情報の処理方法であって、
    前記ｍ個の指定処理装置の夫々が、
    前記処理対象情報を処理することにより算出したｍ個の処理結果から、所定の方法により、真の値を推定して推定値とする
    ことを特徴とする情報の処理方法。
16. 請求項１５に記載の情報の処理方法であって、
    前記処理対象情報に対して、前記推定時間の上限を予め定め、
    前記推定時間情報に基づいて、前記上限を満たす処理装置の中から前記ｍ個の指定処理装置を決定する
    ことを特徴とする情報の処理方法。
17. 請求項１５または１６に記載の情報の処理方法であって、
    前記ｍ個の処理結果の中で、最多の処理結果を前記推定値として選択する
    ことを特徴とする情報の処理方法。
18. 請求項１７に記載の情報の処理方法であって、
    前記最多の処理結果の数が、前記指定処理装置の数ｍの半数を超えた場合、前記最多の処理結果を前記推定値として選択する
    ことを特徴とする情報の処理方法。

Images