(57)【要約】【課題】ストリームデータ紐付けの分散処理において，時間効率がよいストリームデータ紐付け処理が可能となる技術を提供する。【解決手段】入力部１１は，ストリームデータや検索子を入力し，記憶部に格納する。紐付け部１２は，検索子が有する紐付けデータと，検索子が有する検索条件を満たすストリームデータとを紐付けし，新たな紐付けデータを生成する。負荷収集部１７は，各紐付けサーバ１の負荷情報を収集する。紐付け順序更新部１４は，各紐付けサーバ１の負荷状況に基づいて，より負荷が低い紐付けサーバ１での処理を優先するように，ストリームデータの紐付け順序を更新する。検索子生成部１５は，次の紐付け対象となるストリームデータの検索子と新たな紐付けデータとを有する検索子を生成する。出力部１６は，生成された検索子を，次の紐付け対象となるストリームデータが配置された紐付けサーバ１に送信する。【選択図】図４
2010134513.tif 000002
【特許請求の範囲】
【請求項１】
複数の情報処理装置による分散処理によって，関係するストリームデータ同士の紐付けを行うシステムにおいて，前記情報処理装置のコンピュータがストリームデータの紐付けを行うためのデータ紐付けプログラムであって，
前記コンピュータを，
特定の値を持つ所定のキー情報を有するストリームデータを入力するデータ入力部，
前記入力されたストリームデータを記憶するデータ記憶部，
紐付け対象となるストリームデータを検索する検索条件と，ストリームデータ紐付けの途中結果である紐付けデータとを有する紐付け要求を入力する紐付け要求入力部，
前記入力された紐付け要求を記憶する紐付け要求記憶部，
前記ストリームデータが前記紐付け要求が有する検索条件を満たす場合に，前記紐付け要求が有する紐付けデータと，前記検索条件を満たすストリームデータとを紐付けして，新たな紐付けデータを生成する紐付け部，
各情報処理装置の負荷状況を取得する負荷状況取得部，
前記取得された各情報処理装置の負荷状況に基づいて，負荷が低い情報処理装置に配置されたストリームデータが優先的に早い順番で紐付けされるように，ストリームデータを紐付けする順序を決定する紐付け順序決定部，
次の紐付け対象となるストリームデータを特定し，特定された次の紐付け対象となるストリームデータを検索する検索条件と，最初の紐付けデータまたは前記生成された新たな紐付けデータとを有する紐付け要求を生成する紐付け要求生成部，
前記次の紐付け対象となるストリームデータが有する所定のキー情報の値に基づいて，前記次の紐付け対象となるストリームデータが配置された情報処理装置を特定し，特定された情報処理装置に対して前記生成された紐付け要求を送信する出力部として
機能させるためのデータ紐付けプログラム。
【請求項２】
前記コンピュータを，ストリームデータの紐付け関係があらかじめ定義された情報である紐付けルールを記憶する紐付けルール記憶部として機能させ，
前記紐付けルールは，少なくとも紐付け関係が定義された各ストリームデータの発生順序を示す情報を有し，
前記紐付け順序決定部は，前記紐付けルールが有する各ストリームデータの発生順序を示す情報に基づいて，発生順序が早いストリームデータが優先的に早い順番になるように，ストリームデータを紐付けする順序を決定する
ことを特徴とする請求項１に記載のデータ紐付けプログラム。
【請求項３】
前記紐付け順序決定部は，同じ情報処理装置に配置されたストリームデータが優先的に連続した順番で紐付けされるように，ストリームデータを紐付けする順序を決定する
ことを特徴とする請求項１または請求項２に記載のデータ紐付けプログラム。
【請求項４】
前記紐付け順序決定部は，次の紐付け対象となるストリームデータが配置された情報処理装置の負荷が所定の閾値を上回っている場合に，ストリームデータを紐付けする順序を変更する
ことを特徴とする請求項１から請求項３までのいずれかに記載のデータ紐付けプログラム。
【請求項５】
複数の情報処理装置による分散処理によって，関係するストリームデータ同士の紐付けを行うシステムにおいて，ストリームデータの紐付けを行う情報処理装置であって，
特定の値を持つ所定のキー情報を有するストリームデータを入力するデータ入力部と，
前記入力されたストリームデータを記憶するデータ記憶部と，
紐付け対象となるストリームデータを検索する検索条件と，ストリームデータ紐付けの途中結果である紐付けデータとを有する紐付け要求を入力する紐付け要求入力部と，
前記入力された紐付け要求を記憶する紐付け要求記憶部と，
前記ストリームデータが前記紐付け要求が有する検索条件を満たす場合に，前記紐付け要求が有する紐付けデータと，前記検索条件を満たすストリームデータとを紐付けして，新たな紐付けデータを生成する紐付け部と，
各情報処理装置の負荷状況を取得する負荷状況取得部と，
前記取得された各情報処理装置の負荷状況に基づいて，負荷が低い情報処理装置に配置されたストリームデータが優先的に早い順番で紐付けされるように，ストリームデータを紐付けする順序を決定する紐付け順序決定部と，
次の紐付け対象となるストリームデータを特定し，特定された次の紐付け対象となるストリームデータを検索する検索条件と，最初の紐付けデータまたは前記生成された新たな紐付けデータとを有する紐付け要求を生成する紐付け要求生成部と，
前記次の紐付け対象となるストリームデータが有する所定のキー情報の値に基づいて，前記次の紐付け対象となるストリームデータが配置された情報処理装置を特定し，特定された情報処理装置に対して前記生成された紐付け要求を送信する出力部とを備える
ことを特徴とする情報処理装置。
【請求項６】
複数の情報処理装置による分散処理によって，関係するストリームデータ同士の紐付けを行うシステムにおいて，前記情報処理装置のコンピュータがストリームデータの紐付けを行うデータ紐付け方法であって，
前記コンピュータが，
特定の値を持つ所定のキー情報を有するストリームデータを入力するデータ入力過程と，
前記入力されたストリームデータを記憶装置に記憶するデータ記憶過程と，
紐付け対象となるストリームデータを検索する検索条件と，ストリームデータ紐付けの途中結果である紐付けデータとを有する紐付け要求を入力する紐付け要求入力過程と，
前記入力された紐付け要求を記憶装置に記憶する紐付け要求記憶過程と，
前記ストリームデータが前記紐付け要求が有する検索条件を満たす場合に，前記紐付け要求が有する紐付けデータと，前記検索条件を満たすストリームデータとを紐付けして，新たな紐付けデータを生成する紐付け過程と，
各情報処理装置の負荷状況を取得する負荷状況取得過程と，
前記取得された各情報処理装置の負荷状況に基づいて，負荷が低い情報処理装置に配置されたストリームデータが優先的に早い順番で紐付けされるように，ストリームデータを紐付けする順序を決定する紐付け順序決定過程と，
次の紐付け対象となるストリームデータを特定し，特定された次の紐付け対象となるストリームデータを検索する検索条件と，最初の紐付けデータまたは前記生成された新たな紐付けデータとを有する紐付け要求を生成する紐付け要求生成過程と，
前記次の紐付け対象となるストリームデータが有する所定のキー情報の値に基づいて，前記次の紐付け対象となるストリームデータが配置された情報処理装置を特定し，特定された情報処理装置に対して前記生成された紐付け要求を送信する出力過程とを実行する  ことを特徴とするデータ紐付け方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，関係するストリームデータ同士の紐付け処理を行う技術に関するものであり，例えば，複数の情報処理装置によって紐付け処理を分散環境で行う場合に，各情報処理装置の負荷状況に応じてストリームデータの紐付け順序を変更することにより，効率的なストリームデータの紐付け処理を可能とするデータ紐付けプログラム，情報処理装置およびデータ紐付け方法に関するものである。
【背景技術】
【０００２】
ストリームデータ，もしくはイベントデータと呼ばれるデータは，現在，様々な場面で利用され始めている。ストリームデータとは，“ある時点（time）における事象（data）”を表した時系列データである。スタンフォード大学の研究チームは，イベントデータを，
"Continuous, unbounded, rapid, time-varying streams of data elements" 
と定義している。
【０００３】
近年，物流の世界から広がりを見せているＲＦＩＤ（Radio Frequency IDentification）タグを読み取った結果であるセンサデータも，ストリームデータの一種である。また，携帯機器の発達やＷｅｂ2.0 ，クラウドコンピューティングに代表されるネットワークを介したサービスの充実によって増加しているネットワークトラフィックデータも，ストリームデータである。
【０００４】
ここで，ストリームデータ処理の応用の１つとして，システム可視化の技術を紹介する。
【０００５】
世界中に存在するインターネット上のＩＴサービスの多くは，Ｗｅｂ３階層モデルを採用したシステム環境で提供されている。ＩＴサービスのシステム環境は，その重要性が高まる一方で複雑性を増し，部分最適化はできても全体最適化がきわめて難しいという状況が顕在化し始めている。これは，多種多様なコンポーネントからなるＩＴシステムの不具合や性能劣化の発見ならびに特定が難しいということにもつながる。結果として，システム運用管理も煩雑になり，サービス品質（ＱｏＳ：Quality of Service）の低下を引き起こす可能性がある。
【０００６】
そこで，システム運用者の負荷を軽減し，ＩＴサービスを安定稼働させることを目指して，ＩＴサービスのシステム全体の動作を外部から観測し，リアルタイムで可視化する技術が重要になる。このような技術を，ここでは“システム可視化”と呼ぶ。
【０００７】
以下，システム可視化を実現するための技術の例と，その課題を説明する。
【０００８】
図１３は，システム可視化の技術の概要を説明する図である。
【０００９】
図１３において，システム可視化の対象となるＩＴシステム３００は，複数のシステム可視化の対象となるサーバ３１０を有する。また，システム可視化の対象となるＩＴシステム３００は，各サーバ３１０間を中継する，ルータやスイッチ等のネットワーク機器３２０を有する。
【００１０】
図１３に示すシステム可視化では，まず，システム可視化の処理を行う装置が，ネットワーク機器３２０を行き来する通信メッセージを，ポートミラーリングと呼ばれる技術を用いて外部から観測する。
【００１１】
ポートミラーリングは，ネットワーク機器３２０を通過するメッセージのコピーを，ネットワーク機器３２０のミラーポートから取得する技術である。この観測技術は，システム可視化の対象となるサーバ３１０に特別なエージェント等を組み入れる必要がないため，導入が容易であり，かつ対象とするサーバやＯＳを選ばないというメリットがある。
【００１２】
次に，システム可視化の処理を行う装置は，観測したメッセージから必要な情報を取り出し，ＩＴシステム内部で進行中の業務トランザクションの処理状況を読み解く。このとき，システム可視化の処理を行う装置は，あらかじめデータマイニング技術によって取得された，通常の動作タイミングやフローと業務とを紐付けた“挙動モデル”をもとに，現在の業務トランザクションを一つ一つ判断する。
【００１３】
このようにして得られた情報を，処理内容ごとにまとめた統計情報として，ＩＴシステム３００の動作ログとして蓄積したり，グラフやシーケンス図等で表示したりすることができる。例えば，図１３には，クライアント（Ｃｌｉａｎｔ）からメッセージが発行されてから，Ｗｅｂサーバ，アプリケーションサーバ（図中，ＡＰサーバ），データベースサーバ（図中，ＤＢサーバ）へと順に関連するメッセージが発行され，逆順を辿ってクライアントに応答のメッセージが返るまでの一連の業務処理において，各サーバの業務処理タイミングが可視化された表示例が示されている。
【００１４】
図１４は，システム可視化によって得られた統計情報の表示例を示す図である。
【００１５】
システム可視化の技術によって，図１３に示す表示例の他にも，例えば図１４（Ａ），図１４（Ｂ），図１４（Ｃ）に示すような，様々な統計情報を得ることができる。図１４（Ａ）は，業務ごとの平均処理時間と内訳を示すグラフの例である。図１４（Ｂ）は，業務の発生頻度と平均処理時間の分布の例である。図１４（Ｃ）は，業務の平均処理時間の時系列変化の例である。
【００１６】
システム可視化におけるストリームデータとは，ネットワークを流れるメッセージのことである。ストリームデータの特徴の１つとして，関係のある複数のストリームデータを結びつけることにより意味のある情報が得られるというものがある。このような関係のあるストリームデータ同士を結びつけることを，“紐付け”と呼ぶ。システム可視化では，このストリームデータをポートミラーリングによって拾い上げ，それらの中から関係のあるもの同士を紐付けることで，システム環境の挙動の可視化が図られる。
【００１７】
図１５は，システム可視化の技術における紐付けの例を説明する図である。
【００１８】
図１５において，紐付け装置２００は，ストリームデータを解析し，関係するストリームデータ同士の紐付けを行う情報処理装置である。
【００１９】
例えば，図１５に示すＷｅｂ３階層モデルのシステムにおいて，ユーザＰＣ３１１は，Ｗｅｂサーバ３１２にＨＴＴＰリクエストを送る。ＨＴＴＰリクエストを受けたＷｅｂサーバ３１２は，ユーザＰＣ３１１からのＨＴＴＰリクエストに応じたＩＩＯＰリクエストをアプリケーションサーバ３１３に送る。ＩＩＯＰリクエストを受けたアプリケーションサーバ３１３は，Ｗｅｂサーバ３１２からのＩＩＯＰリクエストに応じたＤＢリクエストをデータベースサーバ３１４に送る。これらのユーザＰＣ３１１からデータベースサーバ３１４に至る処理を，一連の処理とする。
【００２０】
紐付け装置２００は，一連の処理における各メッセージ，すなわちストリームデータを，ポートミラーリングにより収集し，関係するもの同士を紐付けする。関係するストリームデータは，例えば，メッセージ中に同じｓｅｓｓｉｏｎ＿ｉｄ番号を持つストリームデータなどである。図１５に示す一連の処理の場合，紐付け装置２００は，収集された多数のストリームデータから，一連の処理の流れで順に発行されたＨＴＴＰリクエスト，ＩＩＯＰリクエスト，ＤＢリクエストの互いに関係する組合せを，一連のストリームデータに共通する情報の検出などにより抽出する。紐付け装置２００は，抽出された関係するストリームデータ同士の紐付けを行い，その紐付け結果を得る。
【００２１】
このようなシステム可視化の技術において，精度の高いシステム可視化を実現するためには，すべてのストリームデータに対して，何らかの処理を行う必要がある。例えば，システム可視化の対象となるサーバ３１０が１０台あれば，その１０台から出力されるすべてのストリームデータに対して，「他のストリームデータと紐付けできるか」や「関係のないストリームデータなのか」などの判定処理を行わなければならない。また，ストリームデータは，流量や種類が多く，決まった型が存在するわけではない。さらに，１つのストリームデータに対して，それと紐付けるべきストリームデータが複数であることも多い。つまり，１つのストリームデータに対して行うべき処理は１つと決まっているわけではなく，状況によって変動する。
【００２２】
これらのことは，システム可視化の対象となるサーバ３１０の台数が多ければ多いほど，ストリームデータに対する処理量が増えることを意味する。つまり，大規模なＩＴシステム３００に対してシステム可視化を適用するときには，多数のシステム可視化の対象となるサーバ３１０から発行されるすべてのストリームデータを処理可能な，高い能力のマシンが必要となる。
【００２３】
しかし，高性能ストリームデータ処理を１台のマシンで実現することは，困難である。システム可視化で要求されるストリームデータ処理のスループットは，システム可視化の対象となるサーバ３１０の台数に比例する。単純にストリームデータを受け取ることを考えてみても，１０台のシステム可視化対象サーバ３１０から最大性能で出力されるストリームデータを，１台のマシンで受けとることはできない。
【００２４】
さらに，ＩＴシステム３００は，利用するユーザ数に合わせて，日々成長する。このことを鑑みると，たとえスタートアップ時には１台のマシンでシステム可視化を実現できていたとしても，処理しなければならないストリームデータの量が１台のマシンでの処理能力を超える日がくることは明らかである。そのため，システム可視化を１台でなく複数のマシンで分散処理することで，処理のスループットを向上させる機構が重要になる。
【００２５】
なお，複数のノードで分散処理を実行する分散環境において，イベント処理を行う技術が知られている。
【特許文献１】特開平８−１２９５３６号公報
【発明の開示】
【発明が解決しようとする課題】
【００２６】
ここで，複数の情報処理装置によってストリームデータ紐付けの分散処理を行う方法の例として，収集されたストリームデータを複数の情報処理装置に分散配置し，各情報処理装置間でストリームデータ紐付けの途中結果を送受信することにより，ストリームデータの紐付けを行う例を想定する。
【００２７】
図１６は，複数の情報処理装置による分散処理でストリームデータの紐付けを行う例を示す図である。
【００２８】
例えば，図１６に示すＷｅｂ３階層モデルのシステムにおいて，Ｗｅｂサーバ３１２は，ストリームデータ＃０１をアプリケーションサーバ３１３に送る。アプリケーションサーバ３１３は，ストリームデータ＃０１に応じたストリームデータ＃０２をデータベースサーバ３１４に送る。データベースサーバ３１４は，ストリームデータ＃０２に対する応答として，ストリームデータ＃０３をアプリケーションサーバ３１３に送る。アプリケーションサーバ３１３は，ストリームデータ＃０１に対する応答として，ストリームデータ＃０３に応じたストリームデータ＃０４をＷｅｂサーバ３１２に送る。
【００２９】
ポートミラーリングにより収集されたストリームデータ＃０１，＃０２，＃０３，＃０４は，それぞれ紐付け装置２００ａ，２００ｂ，２００ｃ，２００ｄに分散配置されるものとする。
【００３０】
紐付け装置２００ａは，最初の紐付け結果として，ストリームデータ＃０１のみの紐付け結果（＃１）を，ストリームデータ＃０２が配置された紐付け装置２００ｂに送信する。
【００３１】
紐付け装置２００ｂは，紐付け装置２００ａから受け取った紐付け結果（＃０１）に，ストリームデータ＃２を紐付ける。紐付け装置２００ｂは，その紐付け結果（＃０１−＃０２）を，ストリームデータ＃０３が配置された紐付け装置２００ｃに送信する。
【００３２】
紐付け装置２００ｃは，紐付け装置２００ｂから受け取った紐付け結果（＃０１−＃０２）に，ストリームデータ＃３を紐付ける。紐付け装置２００ｃは，その紐付け結果（＃０１−＃０２−＃０３）を，ストリームデータ＃０４が配置された紐付け装置２００ｄに送信する。
【００３３】
紐付け装置２００ｄは，紐付け装置２００ｃから受け取った紐付け結果（＃０１−＃０２−＃０３）に，ストリームデータ＃４を紐付ける。得られた紐付け結果（＃０１−＃０２−＃０３−＃０４）が，最終的な紐付け結果となる。
【００３４】
ここで，紐付け装置２００ｃの負荷が一時的に高くなったものとする。例えば，紐付け装置２００ｃに瞬間的に多数の紐付け処理が集中すると，紐付け装置２００ｃの負荷が高くなる。また，紐付け装置２００ｃのハードディスクのストリームデータ蓄積量が増えると，目的とするストリームデータの探索時間が長くなる。
【００３５】
このとき，ストリームデータ＃１〜ストリームデータ＃４を紐付ける一連の処理は，紐付け装置２００ｃで処理待ちが発生するようになる。そのため，ストリームデータ＃１〜ストリームデータ＃４を紐付ける全体の処理が遅くなってしまう。
【００３６】
このように，複数の情報処理装置によるストリームデータ紐付けの分散処理では，負荷が高くなった一部の情報処理装置によって，ストリームデータ紐付け処理の全体が遅くなってしまうという問題が発生する。
【００３７】
本発明は，上記の問題点の解決を図り，複数の情報処理装置によるストリームデータ紐付けの分散処理において，一部に負荷が高くなった情報処理装置があっても，ストリームデータ紐付け処理が全体として遅くならないようにすることが可能となる技術を提供することを目的とする。
【課題を解決するための手段】
【００３８】
開示するプログラムは，複数の情報処理装置による分散処理によって，関係するストリームデータ同士の紐付けを行うシステムの，１つの情報処理装置のコンピュータを次のように機能させる。
【００３９】
すなわち，前記プログラムがインストールされ，実行される情報処理装置は，特定の値を持つ所定のキー情報を有するストリームデータを入力するデータ入力部と，入力されたストリームデータを記憶するデータ記憶部と，紐付け対象となるストリームデータを検索する検索条件とストリームデータ紐付けの途中結果である紐付けデータとを有する紐付け要求を入力する紐付け要求入力部と，入力された紐付け要求を記憶する紐付け要求記憶部と，ストリームデータが紐付け要求が有する検索条件を満たす場合に，紐付け要求が有する紐付けデータと検索条件を満たすストリームデータとを紐付けして，新たな紐付けデータを生成する紐付け部と，各情報処理装置の負荷状況を取得する負荷状況取得部と，取得された各情報処理装置の負荷状況に基づいて，負荷が低い情報処理装置に配置されたストリームデータが優先的に早い順番で紐付けされるように，ストリームデータを紐付けする順序を決定する紐付け順序決定部と，次の紐付け対象となるストリームデータを特定し，特定された次の紐付け対象となるストリームデータを検索する検索条件と，最初の紐付けデータまたは生成された新たな紐付けデータとを有する紐付け要求を生成する紐付け要求生成部と，次の紐付け対象となるストリームデータが有する所定のキー情報の値に基づいて，次の紐付け対象となるストリームデータが配置された情報処理装置を特定し，特定された情報処理装置に対して生成された紐付け要求を送信する出力部とを備える。
【発明の効果】
【００４０】
ストリームデータの紐付けを行う各情報処理装置の負荷状況に応じて，負荷が高い情報処理装置に配置されたストリームデータの紐付けを後に回し，できるだけ負荷が低い情報処理装置に配置されたストリームデータの順番が早くなるように，ストリームデータの紐付け順序を決定することにより，紐付け処理のレイテンシが向上する。
【発明を実施するための最良の形態】
【００４１】
以下，本発明の実施の形態について，図を用いて説明する。
【００４２】
図１は，本実施の形態によるシステム可視化構成の概略を示す図である。
【００４３】
本実施の形態では，図１に示すように，Ｗｅｂ３階層モデルである可視化対象システム３のシステム可視化の例を説明する。
【００４４】
図１の例に示す可視化対象システム３は，スイッチ３０，Ｗｅｂサーバ３１，ＡＰ（Application ）サーバ３２，ＤＢ（Database）サーバ３３，ＬＢ（Load Balancer ）３４，ＦＷ（Firewall）３５，ＤＮＳ（Domain Name System）３６を有する。
【００４５】
図１に示すＷｅｂ３階層モデルにおいて，例えば，リクエストのストリームデータは，クライアント装置（図示省略）からＷｅｂサーバ３１へ，そのＷｅｂサーバ３１からＡＰサーバ３２へ，そのＡＰサーバ３２からＤＢサーバ３３へと，順に発行される。リクエストに対するレスポンスのストリームデータは，リクエストのときと同じサーバを介して，ＤＢサーバ３３からＡＰサーバ３２へ，そのＡＰサーバ３２からＷｅｂサーバ３１へ，そのＷｅｂサーバから最初のクライアント装置へと，返される。
【００４６】
データ分散配置装置２は，各スイッチ３０のミラーポートから，ポートミラーリングにより，可視化対象システム３のネットワークを流れるストリームデータを収集する。また，データ分散配置装置２は，収集された各ストリームデータを，所定のポリシに従って，各紐付けサーバ１に分散配置する。
【００４７】
ストリームデータの分散配置を行う手法としては，例えば，ハッシュ関数を用いる手法などがある。データ分散配置装置２は，ストリームデータが有する所定のキーとなる情報の値にハッシュ関数を用い，得られたハッシュ値で分散配置先の紐付けサーバ１を決定する。このようなハッシュ関数を用いた手法は，特定の紐付けサーバ１に集中的にストリームデータが配置されることを防ぎ，効率的なストリームデータの分散配置を実現する。
【００４８】
紐付けサーバ１は，可視化対象システム３から収集されたストリームデータを解析し，関係するストリームデータ同士の紐付けを行う情報処理装置である。本実施の形態によるシステム可視化では，複数の紐付けサーバ１によって，ストリームデータ紐付けの分散処理が行われる。各紐付けサーバ１は，データ分散配置装置２から受け取ったストリームデータを解析し，他の紐付けサーバ１との的確な通信により，関係するストリームデータ同士の紐付けを行う。
【００４９】
ここで，まず，本実施の形態の分散並列処理によるストリームデータ紐付け手法の想定環境を説明しておく。
【００５０】
図２，図３は，本実施の形態の分散並列処理によるストリームデータ紐付け手法の想定環境を説明する図である。
【００５１】
ここでは，図２（Ａ）に示すような，Ｗｅｂサーバ３１，ＡＰサーバ３２，ＤＢサーバ３３の装置間で送受信される一連のストリームデータの紐付けを例として，ストリームデータ紐付け手法の概要を説明する。
【００５２】
図２（Ａ）において，各装置間で送受信されるＰ（ｘ），Ｑ（ｘ，ｙ），Ｒ（ｙ，ｚ），Ｓ（ｚ）が，一連の処理によって発生するストリームデータを表現したものである。
【００５３】
図２（Ａ）におけるストリームデータの表記において，大文字のアルファベットＰ，Ｑ，Ｒ，Ｓはそれぞれのストリームデータのデータタイプを示す。ストリームデータのデータタイプとは，例えば，ＨＴＴＰ，ＩＩＯＰ等のプロトコルなどのストリームデータの属性を示す情報である。
【００５４】
また，図２（Ａ）におけるストリームデータの表記において，括弧内の小文字のアルファベットｘ，ｙ，ｚは，それぞれのストリームデータが少なくとも有するデータの種別を示す。ストリームデータが有するデータの種別とは，例えば，ユーザＩＤ，パスワード，金額などであり，実際のストリームデータは，それらのデータの値を有する。
【００５５】
なお，複数のストリームデータの表記において，同じ小文字アルファベットが使用されている場合には，データの種別だけでなくデータ自身も共通していることを示す。例えば，上記のＰ（ｘ），Ｑ（ｘ，ｙ）の表記は，一連の処理のストリームデータにおいて，ｘに該当するデータは，データ種別だけではなく，データ自身も同じものである必要がある。また，複数のストリームデータの表記において，種別が同じでもデータが異なる場合には，違う小文字アルファベットを用いて表記している。
【００５６】
図２（Ａ）に示す一連の処理において，Ｗｅｂサーバ３１は，Ｐ（ｘ）で示されるストリームデータをＡＰサーバ３２に送信する。Ｐ（ｘ）で示されるストリームデータを受信したＡＰサーバ３２は，Ｐ（ｘ）で示されるストリームデータに対応するＱ（ｘ，ｙ）で示されるストリームデータをＤＢサーバ３３に送信する。Ｑ（ｘ，ｙ）で示されるストリームデータを受信したＤＢサーバ３３は，Ｑ（ｘ，ｙ）で示されるストリームデータへの応答として，Ｒ（ｙ，ｚ）で示されるストリームデータをＡＰサーバ３２に送信する。Ｒ（ｙ，ｚ）で示されるストリームデータを受信したＡＰサーバ３２は，Ｐ（ｘ）で示されるストリームデータへの応答として，Ｒ（ｙ，ｚ）で示されるストリームデータに対応するＳ（ｚ）で示されるストリームデータをＷｅｂサーバ３１に送信する。
【００５７】
ここで，各紐付けサーバ１は，
｛０，Ｐ，ｘ｝−｛１，Ｑ，ｘ，ｙ｝−｛２，Ｒ，ｙ，ｚ｝−｛３，Ｓ，ｚ｝
で示される紐付けルールを保持しているものとする。
【００５８】
紐付けルールとは，紐付けするストリームデータを定義する情報である。すなわち，紐付けルールは，最終的なストリームデータ紐付けの結果の型を示す情報となる。
【００５９】
例えば，図２（Ａ）に示す例では，各紐付けサーバ１は，一連の処理によって発生するストリームデータＰ（ｘ），Ｑ（ｘ，ｙ），Ｒ（ｙ，ｚ），Ｓ（ｚ）の紐付けが定義された上記の紐付けルールを保有する。
【００６０】
上記の紐付けルールにおいて，各｛｝は，紐付けするストリームデータの型を示している。すなわち，｛｝で括られた１つの情報が，紐付けの対象となるストリームデータを定義する情報である。｛｝内の表記において，数字０，１，２，３は，一連の処理におけるストリームデータの発生順番を示す情報である。ここでは，数値の小さいものから順にストリームデータが発生している。｛｝内の表記において，大文字のアルファベットＰ，Ｑ，Ｒ，Ｓは，ストリームデータのデータタイプを示す。小文字のアルファベットｘ，ｙ，ｚは，ストリームデータが有するデータの種別を示す。
【００６１】
ストリームデータの紐付け順序は，紐付けルールに基づいて決定されるものとする。ここでは，ストリームデータの紐付け順序は，上記の紐付けルールにおけるストリームデータの発生順番に従って，
Ｐ（ｘ）→Ｑ（ｘ，ｙ）→Ｒ（ｙ，ｚ）→Ｓ（ｚ）
となる。
【００６２】
なお，ストリームデータの紐付け順序が，紐付けルールにおけるストリームデータの発生順番に従わない場合もある。
【００６３】
例えば，
｛０，Ｔ，ｘ｝−｛１，Ｕ，ｘ，ｙ｝−｛２，Ｖ，ｚ｝−｛３，Ｗ，ｙ，ｚ｝
という紐付けルールがある場合に，発生順番でストリームデータの紐付け順序が決定されると，紐付け順序は，
Ｔ（ｘ）→Ｕ（ｘ，ｙ）→Ｖ（ｚ）→Ｗ（ｙ，ｚ）
となる。しかし，ストリームデータＶ（ｚ）は，ストリームデータＴ（ｘ），ストリームデータＵ（ｘ，ｙ）と共通するデータを持たない。そのため，ストリームデータＴ（ｘ）とストリームデータＵ（ｘ，ｙ）とを紐付けた後に，その紐付けデータに紐付けるストリームデータＶ（ｚ）を特定することは困難となる。ここでは，発生順番でストリームデータを並べた場合に，隣接するストリームデータ間で共通するデータを持たない状態を，断絶と呼ぶものとする。
【００６４】
ストリームデータＷ（ｙ，ｚ）は，ストリームデータＵ（ｘ，ｙ）と共通するデータｙを持つ。また，ストリームデータＷ（ｙ，ｚ）は，ストリームデータＶ（ｚ）と共通するデータｚを持つ。すなわち，紐付け順序を，
Ｔ（ｘ）→Ｕ（ｘ，ｙ）→Ｗ（ｙ，ｚ）→Ｖ（ｚ）
と決定すれば，断絶があっても，ストリームデータの紐付け処理が容易となる。
【００６５】
紐付けルールの設定作業者は，紐付けルールの設定時に，ストリームデータの紐付け順序も設定する。紐付けルールの設定を行う装置が，設定された紐付けルールから，断絶の有無も考慮して自動的に紐付け順序を決定し，設定する手段を備えていてもよい。
【００６６】
また，紐付けルールであらかじめ紐付け順序が定義されていてもよい。例えば，
｛０，Ｔ，ｘ｝→｛１，Ｕ，ｘ，ｙ｝→｛３，Ｗ，ｙ，ｚ｝→｛２，Ｖ，ｚ｝
といったように，紐付け順序を含めて紐付けルールが定義されてもよい。
【００６７】
図２（Ｂ）は，図２（Ａ）に示す一連の処理において発生するストリームデータのデータ配置ルールを示す。
【００６８】
データ配置ルールは，ストリームデータを各紐付けサーバ１に分散配置するための情報である。図２（Ｂ）に示すデータ配置ルールでは，ストリームデータのデータタイプごとに，ストリームデータが有するどの情報を分散配置のキーとなる情報として用いるかが定義されている。このようなデータ配置ルールの定義情報については，データ分散配置装置２と各紐付けサーバ１とが，共通のものを保持している。
【００６９】
例えば，図２（Ｂ）に示すように，図２（Ａ）に示す一連の処理において発生したデータタイプがＰのストリームデータは，データ分散配置装置２によって，データｘの値を用いたハッシュ関数（ｘ）で特定される紐付けサーバ１に配置される。同様に，データ分散配置装置２によって，データタイプがＱのストリームデータも，データｘの値を用いたハッシュ関数（ｘ）で特定される紐付けサーバ１に配置される。また，データ分散配置装置２によって，データタイプがＲのストリームデータは，データｙの値を用いたハッシュ関数（ｙ）で特定される紐付けサーバ１に配置される。また，データ分散配置装置２によって，データタイプがＳのストリームデータは，データｚの値を用いたハッシュ関数（ｚ）で特定される紐付けサーバ１に配置される。
【００７０】
図３は，図２（Ａ）に示す一連の処理において発生したストリームデータの，実際の紐付け処理の流れを示している。
【００７１】
図３において，紐付けサーバ１ａには，データ分散配置装置２によって，図２（Ｂ）に示すデータ配置ルールに基づいて，ストリームデータＰ（ｘ1 ），ストリームデータＱ（ｘ1 ，ｙ1 ）が配置されるものとする。また，紐付けサーバ１ｂには，データ分散配置装置２によって，図２（Ｂ）に示すデータ配置ルールに基づいて，ストリームデータＲ（ｙ1 ，ｚ1 ）が配置されるものとする。また，紐付けサーバ１ｃには，データ分散配置装置２によって，図２（Ｂ）に示すデータ配置ルールに基づいて，ストリームデータＳ（ｚ1 ）が配置されるものとする。ここで，ｘ1 ，ｙ1 ，ｚ1 は，それぞれ，配置されたストリームデータが有する，データｘ，データｙ，データｚの値であるものとする。
【００７２】
紐付けサーバ１ａは，データ分散配置装置２により配置されたストリームデータＰ（ｘ1 ）が紐付け順序の最初のストリームデータであるので，ストリームデータＰ（ｘ1 ）を紐付ける最初のストリームデータとする，最初の紐付けデータ［Ｐ（ｘ1 ）］を生成する。
【００７３】
紐付けデータは，ストリームデータの紐付け結果となるデータである。図３の例では，紐付けデータは，紐付けられたストリームデータが“−”で結ばれ，［］で括られた形で表記されるものとする。ストリームデータ紐付けの過程において紐付けサーバ１間で送受信される紐付けデータは，ストリームデータ紐付けの途中結果である。紐付けルールで定義された一通りのストリームデータが紐付けられた紐付けデータは，ストリームデータ紐付けの最終結果となる。
【００７４】
次に，紐付けサーバ１ａは，ストリームデータＰ（ｘ1 ）の次に紐付けするストリームデータを検索するための検索子を生成する。
【００７５】
検索子は，ストリームデータ紐付けの途中結果である紐付けデータに次に紐付けするストリームデータを検索し，検出されたストリームデータを途中結果である紐付けデータに紐付けするための情報である。すなわち，検索子は，次に紐付けするストリームデータが配置された紐付けサーバ１に対して，途中結果である紐付けデータに次のストリームデータの紐付け処理を要求する，紐付け要求となる。
【００７６】
検索子は，次に紐付けするストリームデータを検索するための検索条件，ストリームデータ紐付けの途中結果である紐付けデータ等の情報を有する。図３に示す例では，検索子が，
｛検索条件，紐付けデータ｝
の形で表現されている。
【００７７】
紐付けサーバ１ａは，ストリームデータＰ（ｘ1 ）の次に紐付けするストリームデータの検索条件を生成する。このとき，紐付けサーバ１ａは，検索するストリームデータが有するデータｘの値がｘ1 であることがすでに分かっているので，上記の紐付けルールの発生順番に基づいた紐付け順序から，次に紐付けするストリームデータの検索条件Ｑ（ｘ1 ，＊ｙ）を生成する。
【００７８】
ここで，“＊”はワイルドカードを意味し，検索条件における“＊”付きのデータ＊ｙは，紐付けルールにおいてｙで定義されたデータ種別の何らかの値のデータを示す。すなわち，検索条件Ｑ（ｘ1 ，＊ｙ）は，データタイプがＱであり，値がｘ1 のデータｘと何らかの値のデータｙとを有するストリームデータを検索するための検索条件となる。
【００７９】
紐付けサーバ１ａは，生成された検索条件Ｑ（ｘ1 ，＊ｙ）と，ストリームデータ紐付けの途中結果である紐付けデータ［Ｐ（ｘ1 ）］とから，
検索子｛Ｑ（ｘ1 ，＊ｙ），［Ｐ（ｘ1 ）］｝
を生成する。
【００８０】
紐付けサーバ１ａは，生成された検索子を，次に紐付けするストリームデータが配置された紐付けサーバ１に渡す。次に紐付けするストリームデータのデータタイプはＱであるので，紐付けサーバ１ａは，図２（Ｂ）に示すデータ配置ルールから，データｘをキーとして，検索子を渡す相手先の紐付けサーバ１を特定する。ここでは，データｘの値がｘ1 であるので，紐付けサーバ１ａが検索子を渡す相手先の紐付けサーバ１は，紐付けサーバ１ａすなわち自分自身となる。
【００８１】
紐付けサーバ１ａは，自身に配置されたストリームデータが記憶された記憶部から，検索子が有する検索条件Ｑ（ｘ1 ，＊ｙ）を満たすストリームデータを検索する。ここでは，ストリームデータＱ（ｘ1 ，ｙ1 ）が，検索条件Ｑ（ｘ1 ，＊ｙ）を満たすストリームデータとして検出されたものとする。
【００８２】
紐付けサーバ１ａは，検索子が有する紐付けデータ［Ｐ（ｘ1 ）］に，検出されたストリームデータＱ（ｘ1 ，ｙ1 ）を紐付けし，新たな紐付けデータ［Ｐ（ｘ1 ）−Ｑ（ｘ1 ，ｙ1 ）］を生成する。
【００８３】
紐付けサーバ１ａは，上記の紐付けルールで生成された新たな紐付けデータを検証し，紐付けデータがまだ完成していないことを確認する。
【００８４】
紐付けサーバ１ａは，ストリームデータＱ（ｘ1 ，ｙ1 ）の次に紐付けするストリームデータの検索条件を生成する。このとき，紐付けサーバ１ａは，検索するストリームデータが有するデータｙの値がｙ1 であることがすでに分かっているので，上記の紐付けルールの発生順番に基づいた紐付け順序から，次に紐付けするストリームデータの検索条件Ｒ（ｙ1 ，＊ｚ）を生成する。
【００８５】
紐付けサーバ１ａは，生成された検索条件Ｒ（ｙ1 ，＊ｚ）と，ストリームデータ紐付けの途中結果である紐付けデータ［Ｐ（ｘ1 ）−Ｑ（ｘ1 ，ｙ1 ）］とから，
検索子｛Ｒ（ｙ1 ，＊ｚ），［Ｐ（ｘ1 ）−Ｑ（ｘ1 ，ｙ1 ）］｝
を生成する。
【００８６】
紐付けサーバ１ａは，次に紐付けするストリームデータのデータタイプはＲであるので，図２（Ｂ）に示すデータ配置ルールから，データｙをキーとして，検索子を渡す相手先の紐付けサーバ１を特定する。ここでは，データｙの値がｙ1 であるので，紐付けサーバ１ａは，ハッシュ関数（ｙ1 ）で特定される紐付けサーバ１ｂに，生成された検索子を送信する。
【００８７】
紐付けサーバ１ｂは，紐付けサーバ１ａから検索子を受信すると，自身に配置されたストリームデータが記憶された記憶部から，検索子が有する検索条件Ｒ（ｙ1 ，＊ｚ）を満たすストリームデータを検索する。ここでは，ストリームデータＲ（ｙ1 ，ｚ1 ）が，検索条件Ｒ（ｙ1 ，＊ｚ）を満たすストリームデータとして検出されたものとする。
【００８８】
紐付けサーバ１ｂは，検索子が有する紐付けデータ［Ｐ（ｘ1 ）−Ｑ（ｘ1 ，ｙ1 ）］に，検出されたストリームデータＲ（ｙ1 ，ｚ1 ）を紐付けし，新たな紐付けデータ［Ｐ（ｘ1 ）−Ｑ（ｘ1 ，ｙ1 ）−Ｒ（ｙ1 ，ｚ1 ）］を生成する。
【００８９】
紐付けサーバ１ｂは，上記の紐付けルールで生成された新たな紐付けデータを検証し，紐付けデータがまだ完成していないことを確認する。
【００９０】
紐付けサーバ１ｂは，ストリームデータＲ（ｙ1 ，ｚ1 ）の次に紐付けするストリームデータの検索条件を生成する。このとき，紐付けサーバ１ｂは，検索するストリームデータが有するデータｚの値がｚ1 であることがすでに分かっているので，上記の紐付けルールの発生順番に基づいた紐付け順序から，次に紐付けするストリームデータの検索条件Ｓ（ｚ1 ）を生成する。
【００９１】
紐付けサーバ１ｂは，生成された検索条件Ｓ（ｚ1 ）と，ストリームデータ紐付けの途中結果である紐付けデータ［Ｐ（ｘ1 ）−Ｑ（ｘ1 ，ｙ1 ）−Ｒ（ｙ1 ，ｚ1 ）］とから，
検索子｛Ｓ（ｚ1 ），［Ｐ（ｘ1 ）−Ｑ（ｘ1 ，ｙ1 ）−Ｒ（ｙ1 ，ｚ1 ）］｝
を生成する。
【００９２】
紐付けサーバ１ｂは，次に紐付けするストリームデータのデータタイプはＳであるので，図２（Ｂ）に示すデータ配置ルールから，データｚをキーとして，検索子を渡す相手先の紐付けサーバ１を特定する。ここでは，データｚの値がｚ1 であるので，紐付けサーバ１ｂは，ハッシュ関数（ｚ1 ）で特定される紐付けサーバ１ｃに，生成された検索子を送信する。
【００９３】
紐付けサーバ１ｃは，紐付けサーバ１ｂから検索子を受信すると，自身に配置されたストリームデータが記憶された記憶部から，検索子が有する検索条件Ｓ（ｚ1 ）を満たすストリームデータを検索する。ここでは，ストリームデータＳ（ｚ1 ）が検出されたものとする。
【００９４】
紐付けサーバ１ｃは，検索子が有する紐付けデータ［Ｐ（ｘ1 ）−Ｑ（ｘ1 ，ｙ1 ）−Ｒ（ｙ1 ，ｚ1 ）］に，検出されたストリームデータＳ（ｚ1 ）を紐付けし，新たな紐付けデータ［Ｐ（ｘ1 ）−Ｑ（ｘ1 ，ｙ1 ）−Ｒ（ｙ1 ，ｚ1 ）−Ｓ（ｚ1 ）］を生成する。
【００９５】
紐付けサーバ１ｃは，上記の紐付けルールで生成された新たな紐付けデータを検証し，紐付けデータが，図２（Ａ）に示す一連の処理で発行されたストリームデータの紐付けにおける，完成した紐付けデータであることを確認する。
【００９６】
このように，ストリームデータを各紐付けサーバ１に分散配置し，次のストリームデータの検索条件とそれまでの紐付け結果とを有する検索子を，紐付けサーバ１間で送受信し合うことにより，ストリームデータ紐付けの分散処理を行うことができる。
【００９７】
本実施の形態では，このような分散並列処理によるストリームデータ紐付けの想定環境を例として，分散環境における，効率的なストリームデータ紐付けの技術について説明する。
【００９８】
図４は，本実施の形態による紐付けサーバの構成例を示す図である。
【００９９】
図４において，実線の矢印は処理の推移を示し，点線の矢印はデータの格納や参照を示す。
【０１００】
紐付けサーバ１は，ストリームデータ紐付け部１０を備える。ストリームデータ紐付け部１０は，関係するストリームデータ同士の紐付けを行う手段であり，紐付けサーバ１のコンピュータが備えるＣＰＵ，メモリ等のハードウェアと，ソフトウェアプログラムとにより実現される。
【０１０１】
ストリームデータ紐付け部１０は，入力部１１，紐付け部１２，紐付けルール解析部１３，紐付け順序更新部１４，検索子生成部１５，出力部１６，負荷収集部１７，負荷測定部１８を備える。
【０１０２】
また，ストリームデータ紐付け部１０は，データ保管部１１０，検索子格納部１１１，紐付けルール記憶部１１２，データ配置ルール記憶部１１３，負荷情報記憶部１１４を備える。
【０１０３】
データ保管部１１０は，ストリームデータや紐付けデータなどのデータを保管する記憶部である。検索子格納部１１１は，検索子を格納する記憶部である。紐付けルール記憶部１１２は，定義された紐付けルールを記憶する記憶部である。データ配置ルール記憶部１１３は，定義されたデータ配置ルールを記憶する記憶部である。本実施の形態では，紐付けルール記憶部１１２に存在する紐付けルールに対して，１対１に対応するデータ配置ルールがデータ配置ルール記憶部１１３に存在するものとする。負荷情報記憶部１１４は，各紐付けサーバ１の負荷状況を示す情報を記憶する記憶部である。
【０１０４】
なお，本実施の形態では，紐付けルール記憶部１１２が，定義された紐付けルールとその紐付けルールに基づいた初期設定の紐付け順序とを，セットで記憶するものとする。
【０１０５】
入力部１１は，ストリームデータや検索子を入力する。
【０１０６】
具体的には，入力部１１は，データ分散配置装置２により分散配置されたストリームデータを入力する。入力部１１は，入力されたストリームデータをデータ保管部１１０に格納する。また，入力部１１は，紐付けサーバ１から検索子を入力する。入力部１１は，入力された検索を検索子格納部１１１に格納する。
【０１０７】
紐付け部１２は，検索子が有する紐付けデータと，検索子が有する検索条件を満たしたストリームデータとの紐付けを行う。
【０１０８】
具体的には，紐付け部１２は，ストリームデータが入力されると，入力されたストリームデータが，検索子格納部１１１に記憶されたいずれかの検索子が有する検索条件を満たすかを，マッチングにより確認する。紐付け部１２は，入力されたストリームデータが検索条件を満たす検索子が検索子格納部１１１に存在すれば，その検索子が有する紐付けデータと入力されたストリームデータとを紐付けし，紐付け結果を新たな紐付けデータとする。
【０１０９】
また，紐付け部１２は，入力されたストリームデータが検索条件を満たす検索子が検索子格納部１１１に存在しなければ，入力されたストリームデータを最初に紐付けるストリームデータとして定義している紐付け順序が，紐付けルール記憶部１１２に存在するかを確認する。紐付け部１２は，入力されたストリームデータを最初に紐付けるストリームデータとして定義する紐付け順序が紐付けルール記憶部１１２から検出されれば，入力されたストリームデータを最初に紐付けるストリームデータとする，最初の紐付けデータを新たに生成する。
【０１１０】
また，紐付け部１２は，検索子が入力されると，入力された検索子が有する検索条件を満たすストリームデータがデータ保管部１１０に存在するかを，マッチングにより確認する。紐付け部１２は，入力された検索子が有する検索条件を満たすストリームデータがデータ保管部１１０に存在すれば，入力された検索子が有する紐付けデータと検出されたストリームデータとを紐付けし，紐付け結果を新たな紐付けデータとする。
【０１１１】
ストリームデータが先に入力される場合もあれば，検索子が先に入力される場合もある。そのどちらのケースにも対応できるように，紐付け部１２は，ストリームデータが入力されたときには，入力されたストリームデータに対応する検索子を探索し，検索子が入力された場合には，入力された検索子に対応するストリームデータを探索する。
【０１１２】
紐付けルール解析部１３は，新たな紐付けデータと紐付けルール記憶部１１２に記憶された紐付けルールとのマッチングによる解析処理を行う。紐付けルールを用いた解析処理により，紐付けルール解析部１３は，新たな紐付けデータが，紐付けルールに基づいて完成した紐付けデータであるかを確認することができる。また，紐付けルールを用いた解析処理により，紐付けルール解析部１３は，新たな紐付けデータが，どの紐付けルールに基づいて生成された紐付けデータであるかを確認することができる。
【０１１３】
具体的には，新たな紐付けデータが紐付けルール記憶部１１２に記憶されたいずれかの紐付けルールと全体がマッチしていれば，その新たな紐付けデータは，全体がマッチした紐付けルールに基づいて完成していることになる。紐付けルール解析部１３は，完成した紐付けデータを，データ保管部１１０に格納する。
【０１１４】
また，新たな紐付けデータが紐付けルール記憶部１１２に記憶されたいずれかの紐付けルールの一部にマッチしていれば，その新たな紐付けデータは，部分的にマッチした紐付けルールに基づいて生成された紐付けデータであることがわかる。
【０１１５】
紐付け順序更新部１４は，各紐付けサーバ１の負荷状況に応じて，ストリームデータの紐付け順序を決定する。
【０１１６】
具体的には，紐付け順序更新部１４は，新たな紐付けデータに対応する紐付け順序から，次の紐付け対象となるストリームデータを特定する。本実施の形態では，新たな紐付けデータに対応する紐付け順序は，紐付け順序がまだ更新されていなければ，新たな紐付けデータに対応する紐付けルールに基づいた初期の紐付け順序である。紐付け順序が更新されていれば，新たな紐付けデータに対応する紐付け順序は，新たな紐付けデータのもととなった紐付けデータを有する検索子に含まれた紐付け順序である。
【０１１７】
また，紐付け順序更新部１４は，データ配置ルール記憶部１１３に記憶されたデータ配置ルールに基づいて，次の紐付け対象となるストリームデータが配置された紐付けサーバ１を特定する。
【０１１８】
紐付け順序更新部１４は，特定された紐付けサーバ１の負荷情報を，負荷情報記憶部１１４から取得する。紐付け順序更新部１４は，特定された紐付けサーバ１の負荷が，所定の閾値を超えているかを確認する。特定された紐付けサーバ１の負荷が所定の閾値を超えている場合には，紐付け順序更新部１４は，各紐付けサーバ１の負荷状況に応じた紐付け順序の更新を行う。
【０１１９】
なお，紐付けサーバ１の負荷は，例えば，紐付けサーバ１が備えるＣＰＵの使用率やハードディスクの使用量などである。紐付け順序更新部１４による紐付け順序の更新において，どのような負荷の情報を用いるかの設計は，任意である。
【０１２０】
紐付け順序更新部１４は，紐付け順序を決定するための判断要素として，各紐付けサーバ１の負荷を用いる。すなわち，紐付け順序更新部１４は，紐付け順序の更新において，負荷が低い紐付けサーバ１に配置されたストリームデータの紐付け順番が，優先的に早い順番となるような紐付け順序の決定ルールに従って，紐付け順序を決定する。
【０１２１】
また，紐付け順序の更新処理において，紐付け順序更新部１４がストリームデータが発生する順番に応じた重み付けを行うようにしてもよい。すなわち，紐付け順序更新部１４は，紐付け順序の更新において，発生順番が早いストリームデータの紐付け順番が，優先的に早い順番となるような紐付け順序の決定ルールに従って，紐付け順序を決定する。
【０１２２】
また，紐付け順序の更新において，紐付け順序更新部１４が同じ紐付けサーバ１に配置されたストリームデータをできるだけ続けて紐付けするように重み付けを行うようにしてもよい。すなわち，紐付け順序更新部１４は，紐付け順序の更新処理において，同じ紐付けサーバ１に配置されたストリームデータが，優先的に連続して紐付けされるような紐付け順序の決定ルールに従って，紐付け順序を決定する。
【０１２３】
検索子生成部１５は，次の紐付け対象となるストリームデータを検索するための検索子を生成する。
【０１２４】
具体的には，検索子生成部１５は，次の紐付け対象となるストリームデータを検索するための検索条件を生成する。検索子生成部１５は，生成された検索条件と新たな紐付けデータとを有する検索子を生成する。また，紐付け順序が初期設定から変更されている場合には，検索子生成部１５は，さらに変更された紐付け順序の情報を検索子に含ませる。
【０１２５】
なお，紐付け順序の変更に関わらず，紐付け順序の情報を検索子に含ませるようにしてもよい。紐付け順序が初期設定から変更されている場合にのみ紐付け順序の情報を検索子に含ませるようにすれば，通信データ量が少なく済む。
【０１２６】
出力部１６は，生成された検索子を，次の紐付け対象となるストリームデータが配置された紐付けサーバ１に対して出力する。
【０１２７】
具体的には，出力部１６は，データ配置ルール記憶部１１３に記憶されたデータ配置ルールに基づいて，次の紐付け対象となるストリームデータが配置された紐付けサーバ１を特定する。出力部１６は，特定された紐付けサーバ１に対して，生成された検索子を送信する。
【０１２８】
負荷収集部１７は，各紐付けサーバ１の負荷情報を収集し，収集した負荷情報を負荷情報記憶部１１４に記憶する。
【０１２９】
負荷測定部１８は，自装置の負荷を測定する。
【０１３０】
例えば，負荷測定部１８は，定期的に自装置の負荷を測定し，得られた負荷情報をブロードキャストで各紐付けサーバ１に送信する。負荷収集部１７は，各紐付けサーバ１から負荷情報を受け取ると，受け取った負荷情報を負荷情報記憶部１１４に記憶する。
【０１３１】
また，負荷収集部１７が，必要な紐付けサーバ１に対して負荷情報を要求するようにしてもよい。例えば，負荷収集部１７は，紐付け順序更新部１４による紐付け順序更新処理時に，負荷情報が必要となる紐付けサーバ１に対して，負荷情報を要求する。負荷情報を要求された紐付けサーバ１では，負荷測定部１８が負荷を測定し，得られた負荷情報を，負荷情報の要求元の紐付けサーバ１に送る。負荷情報の要求元の紐付けサーバ１では，負荷収集部１７が，負荷情報の要求先から受け取った負荷情報を負荷情報記憶部１１４に記憶する。
【０１３２】
なお，各紐付けサーバ１において負荷測定部１８がどのような負荷を測定するのか，また，各紐付けサーバ１において負荷収集部１７がどのような負荷の情報を収集するのかの設計は，任意である。
【０１３３】
図５は，本実施の形態による各データの構成例を示す図である。
【０１３４】
図５（Ａ）は，ストリームデータのデータ構成例を示す。ストリームデータは，例えば，データタイプ，タイムスタンプ，データ等の情報を有する。データタイプは，例えばＨＴＴＰ，ＩＩＯＰ等のプロトコルなど，ストリームデータの種別を示す情報である。タイムスタンプは，ストリームデータが生成された時間を示す情報である。データは，例えばユーザ名＝小橋，品物＝本，金額＝１０００などのストリームデータ内部に保持された各データである。
【０１３５】
図５（Ｂ）は，検索子のデータ構成例を示す。検索子は，例えば，検索条件，紐付けデータ等の情報を有する。検索条件は，次の紐付け対象となるストリームデータの条件を示す情報である。紐付けデータは，ストリームデータ紐付けの途中結果である。紐付け順序が初期設定から変更された場合には，変更された紐付け順序を示す情報が，検索子に含まれるようにしてもよい。
【０１３６】
検索条件は，例えば，
・（データタイプ＝ＨＴＴＰ，ユーザ名＝小橋）
・（データタイプ＝ＩＩＯＰ，ユーザ名＝小橋，品物＝＊）
などである。“＊”はワイルドカードを示している。
【０１３７】
前段の検索条件は，データタイプがＨＴＴＰで，ユーザ名＝小橋のデータを有するストリームデータを検索する検索条件である。後段の検索条件は，データタイプがＩＩＯＰで，ユーザ名＝小橋のデータ，種別が品物である何らかのデータを有するストリームデータを検索する検索条件である。
【０１３８】
図５（Ｃ）は，紐付けデータのデータ構成例を示す。紐付けデータは，例えば，それまで紐付けられたストリームデータごとに，データタイプ，データ等の情報を有する。データタイプは，紐付けされたストリームデータの種別を示す情報である。データは，紐付けられたストリームデータが内部に有するデータの情報である。
【０１３９】
紐付けデータは，例えば，
・（（ＨＴＴＰ，ユーザ名＝小橋），）
・（（ＨＴＴＰ，ユーザ名＝小橋），
（ＩＩＯＰ，ユーザ名＝小橋，品物＝本），）
などである。
【０１４０】
前段の紐付けデータは，データタイプがＨＴＴＰで，ユーザ名＝小橋のデータを有するストリームデータが最初に紐付けられただけの紐付けデータの例である。後段の紐付けデータは，前段の紐付けデータに，さらにデータタイプがＩＩＯＰで，ユーザ名＝小橋のデータ，品物＝本のデータを有するストリームデータが紐付けられた紐付けデータの例である。
【０１４１】
なお，紐付けデータのデータ形式としては，例えば，ストリームデータをそのまま紐付ける形式，ストリームデータから必要な情報のみを抽出して紐付ける形式，ストリームデータの保管場所へのポインタ情報を紐付ける形式など，さまざまな形式が考えられる。
【０１４２】
図５（Ｄ）は，紐付けルールのデータ構成例を示す。紐付けルールは，ストリームデータの紐付け関係があらかじめ定義された情報である。各紐付けサーバ１は，紐付けルールの定義に従って，ストリームデータ紐付けの処理を行う。このような紐付けルールを用いることにより，ストリームデータ間の関係を明らかにすることができる。
【０１４３】
紐付けルールは，紐付けするストリームデータごとに，発生順番，データタイプ，データ種別等の情報を有する。発生順番は，一連の処理過程でストリームデータが発生する順序を示す情報である。データタイプは，紐付けするストリームデータの種別を示す情報である。データ種別は，紐付けするストリームデータが内部に有するデータの種別を示す情報である。
【０１４４】
紐付けルールは，例えば，
・（１，ＨＴＴＰログイン，ユーザ名，パスワード）
−（２，ＩＩＯＰ認証，ユーザ名，パスワード）
−（３，ＤＢパスワード問い合わせ，ユーザ名）
などである。
【０１４５】
この紐付けルールは，一連の処理において最初に発行された，タイプがＨＴＴＰログインで，ユーザ名，パスワードのデータを有するストリームデータと，そのストリームデータと関係する，２番目に発行された，タイプがＩＩＯＰ認証で，共通のユーザ名，パスワードのデータを有するストリームデータと，そのストリームデータに関係する，３番目に発行された，タイプがＤＢパスワード問い合わせで，共通のユーザ名のデータを有するストリームデータとを，順に紐付けることを定義している。
【０１４６】
図６は，本実施の形態のストリームデータ紐付け部によるストリームデータ紐付け処理フローチャートである。
【０１４７】
各紐付けサーバ１は，データを入力するごとに，図６に示すストリームデータ紐付け処理を実行する。
【０１４８】
紐付けサーバ１において，入力部１１は，データを取得すると（ステップＳ１０），取得されたデータがストリームデータであれば（ステップＳ１１のＹＥＳ），データ保管部１１０に取得されたストリームデータを格納する（ステップＳ１２）。
【０１４９】
紐付け部１２は，取得されたストリームデータと，検索子格納部１１１に格納された検索子が有する検索条件とのマッチングを行う（ステップＳ１３）。紐付け部１２は，取得されたストリームデータにマッチする検索条件を有する検索子が存在すれば（ステップＳ１３のＹＥＳ），検出された検索子に含まれる紐付けデータと取得されたストリームデータとをもとに，新たな紐付けデータを生成する（ステップＳ１４）。
【０１５０】
紐付けルール解析部１３は，生成された紐付けデータと紐付けルール記憶部１１２に保持された紐付けルールとのマッチングを行う（ステップＳ１５）。紐付けルール解析部１３は，生成された紐付けデータがいずれかの紐付けルールを網羅していれば（ステップＳ１５のＹＥＳ），その完成された紐付けデータをデータ保管部１１０に格納し（ステップＳ１６），処理を終了する。
【０１５１】
ステップＳ１５の判定において，生成された紐付けデータがまだ完成されたものでなければ（ステップＳ１５のＮＯ），紐付け順序更新部１４は，後述の紐付け順序更新処理を行う（ステップＳ１７）。
【０１５２】
検索子生成部１５は，次の紐付け対象となるストリームデータの検索条件を生成し，生成された検索条件と新たな紐付けデータとを有する検索子を生成する（ステップＳ１８）。
【０１５３】
検索条件の生成において，検索子生成部１５は，紐付け順序が紐付けルールに基づいた最初の紐付け順序から変更されていなければ，紐付けルールに基づいた最初の紐付け順序に従って，次の紐付け対象となるストリームデータの検索条件を生成する。
【０１５４】
また，検索子生成部１５は，紐付け順序が紐付けルールに基づいた最初の紐付け順序から変更されていれば，変更された紐付け順序に従って，次の紐付け対象となるストリームデータの検索条件を生成する。このとき，検索子生成部１５は，生成された検索条件と，新たな紐付けデータと，変更された紐付け順序とを有する検索子を生成する。
【０１５５】
出力部１６は，データ配置ルール記憶部１１３に記憶されたデータ配置ルールに基づいて特定された，次の紐付け対象となるストリームデータを保持する紐付けサーバ１に，生成された検索子を転送し（ステップＳ１９），処理を終了する。
【０１５６】
ステップＳ１３の判定において，取得されたストリームデータにマッチする検索条件を有する検索子が存在しなければ（ステップＳ１３のＮＯ），紐付け部１２は，取得されたストリームデータと紐付けルール記憶部１１２に保持された紐付け順序とのマッチングを行う（ステップＳ２０）。紐付け部１２は，取得されたストリームデータと最初のストリームデータがマッチする紐付け順序が存在しなければ（ステップＳ２０のＮＯ），処理を終了する。
【０１５７】
紐付け部１２は，取得されたストリームデータが紐付けルール記憶部１１２に保持されたいずれかの紐付け順序で定義された最初のストリームデータとマッチすれば（ステップＳ２０のＹＥＳ），取得されたストリームデータを最初に紐付けするストリームデータとする紐付けデータを生成する（ステップＳ２１）。
【０１５８】
紐付け順序更新部１４は，後述の紐付け順序更新処理を行う（ステップＳ１７）。検索子生成部１５は，検索子を生成する（ステップＳ１８）。出力部１６は，次の紐付け対象となるストリームデータを保持する紐付けサーバ１に，生成された検索子を転送し（ステップＳ１９），処理を終了する。
【０１５９】
入力部１１は，取得されたデータが検索子であれば（ステップＳ２２のＹＥＳ），検索子格納部１１１に取得された検索子を格納する（ステップＳ２３）。
【０１６０】
紐付け部１２は，取得された検索子の検索条件と，データ保管部１１０に保管されたストリームデータとのマッチングを行う（ステップＳ２４）。紐付け部１２は，取得された検索子の検索条件にマッチするストリームデータが存在しなければ（ステップＳ２４のＮＯ），処理を終了する。
【０１６１】
紐付け部１２は，取得された検索子の検索条件にマッチするストリームデータが存在すれば（ステップＳ２４のＹＥＳ），取得された検索子に含まれる紐付けデータと検出されたストリームデータとをもとに，新たな紐付けデータを生成する（ステップＳ１４）。
【０１６２】
紐付けルール解析部１３は，生成された紐付けデータと紐付けルール記憶部１１２に保持された紐付けルールとのマッチングを行う（ステップＳ１５）。紐付けルール解析部１３は，生成された紐付けデータがいずれかの紐付けルールを網羅していれば（ステップＳ１５のＹＥＳ），その完成された紐付けデータをデータ保管部１１０に格納し（ステップＳ１６），処理を終了する。生成された紐付けデータがまだ完成されたものでなければ（ステップＳ１５のＮＯ），紐付け順序更新部１４は，後述の紐付け順序更新処理を行う（ステップＳ１７）。検索子生成部１５は，検索子を生成する（ステップＳ１８）。出力部１６は，次の紐付け対象となるストリームデータを保持する紐付けサーバ１に，生成された検索子を転送し（ステップＳ１９），処理を終了する。
【０１６３】
図７は，本実施の形態の紐付け順序更新部による紐付け順序更新処理フローチャートである。
【０１６４】
以下では，紐付けルールや紐付け順序において，紐付けするストリームデータを定義する情報を，ストリームデータ定義情報と呼ぶものとする。
【０１６５】
紐付け順序更新部１４は，次の紐付け対象となるストリームデータが配置された紐付けサーバ１を特定する（ステップＳ１７０）。すなわち，紐付け順序更新部１４は，現在の紐付け順序に従って，生成された紐付けデータに紐付けする，次の紐付け対象となるストリームデータを特定する。紐付け順序更新部１４は，データ配置ルール記憶部１１３に記憶されたデータ配置ルールに基づいて，次の紐付け対象となるストリームデータが配置された紐付けサーバ１を特定する。
【０１６６】
紐付け順序更新部１４は，負荷情報記憶部１１４から，特定された紐付けサーバの負荷情報を取得する（ステップＳ１７１）。
【０１６７】
紐付け順序更新部１４は，取得された負荷情報から，特定された紐付けサーバの負荷が所定の閾値以上であるかを判定する（ステップＳ１７２）。特定された紐付けサーバの負荷が所定の閾値を下回っていれば（ステップＳ１７２のＮＯ），紐付け順序更新部１４は，紐付け順序更新処理を終了する。
【０１６８】
特定された紐付けサーバの負荷が所定の閾値以上であれば（ステップＳ１７２のＹＥＳ），紐付け順序更新部１４は，紐付け順序から次に探索可能なストリームデータ定義情報を抽出する（ステップＳ１７３）。すなわち，紐付け順序更新部１４は，紐付け順序において，まだ紐付けの順番が決まっていないストリームデータ定義情報のうち，すでに順番が決まったストリームデータ定義情報が有するデータをキー情報として持つストリームデータ定義情報を抽出する。
【０１６９】
紐付け順序更新部１４は，抽出されたストリームデータ定義情報に，それぞれ対応する負荷を割り当てる（ステップＳ１７４）。
【０１７０】
すでに紐付けられたストリームデータ定義情報が有するデータをキー情報として持つストリームデータ定義情報は，キー情報の値が分かっているため，データ配置ルールに基づいて，探索するストリームデータが配置された紐付けサーバ１を特定することができる。すなわち，紐付け順序更新部１４は，すでに紐付けられたストリームデータ定義情報が有するデータをキー情報として持つストリームデータ定義情報には，特定された紐付けサーバ１の負荷情報を負荷情報記憶部１１４から取得し，得られた負荷を割り当てる。
【０１７１】
すでに紐付けられたストリームデータ定義情報が有するデータをキー情報として持たないストリームデータ定義情報は，この段階では探索するストリームデータが配置された紐付けサーバ１を特定することができない。紐付け順序更新部１４は，すでに紐付けられたストリームデータ定義情報が有するデータをキー情報として持つストリームデータ定義情報には，所定の負荷を割り当てる。所定の負荷は，例えば，全紐付けサーバ１の負荷の平均値や，所定のデフォルト値などである。
【０１７２】
紐付け順序更新部１４は，抽出されたストリームデータ定義情報の距離を算出する（ステップＳ１７５）。
【０１７３】
本実施の形態において，紐付け順序更新部１４は，抽出されたストリームデータ定義情報の距離として，抽出されたストリームデータ定義情報と，現時点で決定されている順番が最後のストリームデータ定義情報との発生順番の差を算出する。すなわち，一連の処理で発生するストリームデータにおいて，抽出されたストリームデータ定義情報の発生順番が３で，現時点で決定されている順番が最後のストリームデータ定義情報の発生順番が１であれば，抽出されたストリームデータ定義情報の距離は，３−１＝２となる。
【０１７４】
なお，本実施の形態では，抽出されたストリームデータ定義情報の発生順番が，現時点で決定されている順番が最後のストリームデータ定義情報の発生順番よりも早い場合には，紐付け順序更新部１４は，抽出されたストリームデータ定義情報の距離を１とする。また，紐付け順序更新部１４は，紐付けする２つのストリームデータが同じ紐付けサーバ１に配置されているときには，それら２つのストリームデータ間の距離を０とする。
【０１７５】
紐付け順序更新部１４は，紐付けルールから，抽出されたストリームデータ定義情報の発生順番と，現時点で決定されている順番が最後のストリームデータ定義情報の発生順番とを取得する。紐付け順序更新部１４は，抽出されたストリームデータ定義情報の発生順番と，現時点で決定されている順番が最後のストリームデータ定義情報の発生順番との差を，抽出されたストリームデータ定義情報の距離として算出する。このとき，紐付け順序更新部１４は，抽出されたストリームデータ定義情報の発生順番が，現時点で決定されている順番が最後のストリームデータ定義情報の発生順番より早い場合には，抽出されたストリームデータ定義情報の距離を１とする。
【０１７６】
また，紐付け順序更新部１４は，データ配置ルールを参照し，抽出されたストリームデータ定義情報と，現時点で決定されている順番が最後のストリームデータ定義情報とが，同じ紐付けサーバ１に配置されるストリームデータの紐付けの定義情報であれば，抽出されたストリームデータ定義情報の距離を０とする。
【０１７７】
紐付け順序更新部１４は，抽出されたストリームデータ定義情報のコストを算出する（ステップＳ１７６）。本実施の形態では，抽出されたストリームデータ定義情報のコストは，紐付け順序更新部１４が，抽出されたストリームデータ定義情報に割り当てた負荷に対して，算出されたストリームデータ定義情報の距離で重み付けすることにより，算出される。
【０１７８】
紐付け順序更新部１４は，最もコストが低いストリームデータ定義情報を，次の順番のストリームデータ定義情報として決定する（ステップＳ１７７）。
【０１７９】
紐付け順序更新部１４は，まだ順番が決定されていないストリームデータ定義情報があるかを判定する（ステップＳ１７８）。紐付け順序更新部１４は，まだ順番が決定されていないストリームデータ定義情報があれば（ステップＳ１７８のＹＥＳ），ステップＳ１７３に戻り，処理を繰り返す。紐付け順序更新部１４は，まだ順番が決定されていないストリームデータ定義情報がなければ（ステップＳ１７８のＮＯ），紐付け順序更新処理を終了する。
【０１８０】
なお，図７に示す紐付け順序更新処理は，あくまで一例である。例えば，紐付けサーバ１の負荷状況をより重く判断するか，ストリームデータの発生順序をより重く判断するか等のルールや，加算や乗算等の重み付けの仕方などの設計は，任意である。
【０１８１】
以下，図８〜図１２を用いて，本実施の形態による紐付け順序更新のより具体的な実施例を説明する。
【０１８２】
図８は，一連の処理においてストリームデータが発生する例を示す図である。
【０１８３】
ここでは，図８に示すような，クライアント装置３７，Ｗｅｂサーバ３１，ＡＰサーバ３２，ＤＢサーバ３３の装置間で送受信される一連のストリームデータの紐付けを例として説明する。なお，図８において，ストリームデータのデータタイプ表記中のＲｅｑはリクエスト（Request ）を示し，Ｒｅｓはレスポンス（Response）を示す。
【０１８４】
図８に示す一連の処理において，クライアント装置３７は，ストリームデータＨＴＴＰ−Ｒｅｑ（ｓ）を，Ｗｅｂサーバ３１に送信する。Ｗｅｂサーバ３１は，受信したストリームデータＨＴＴＰ−Ｒｅｑ（ｓ）に応じたストリームデータＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）を，ＡＰサーバ３２に送信する。ＡＰサーバ３２は，受信したストリームデータＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）に応じたストリームデータＤＢ−Ｒｅｑ（ｔ）を，ＤＢサーバ３３に送信する。ＤＢサーバ３３は，受信したストリームデータＤＢ−Ｒｅｑ（ｔ）に応じたストリームデータＤＢ−Ｒｅｓ（ｕ）を，ＡＰサーバ３２に送信する。ＡＰサーバ３２は，受信したストリームデータＤＢ−Ｒｅｓ（ｕ）に応じたストリームデータＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）を，Ｗｅｂサーバ３１に送信する。Ｗｅｂサーバ３１は，受信したストリームデータＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）に応じたストリームデータＨＴＴＰ−Ｒｅｓ（ｖ）を，クライアント装置３７に送信する。
【０１８５】
図９は，紐付けルールの例を示す図である。
【０１８６】
図９では，図８に示す一連の処理で発生するストリームデータの紐付けルールが，テーブル形式で表現されている。図９に示すテーブル形式の紐付けルールを，上記の別の形式で表現すると，
｛０，ＨＴＴＰ−Ｒｅｑ，ｓ｝−｛１，ＩＩＯＰ−Ｒｅｑ，ｓ，ｔ，ｕ｝
−｛２，ＤＢ−Ｒｅｑ，ｔ｝−｛３，ＤＢ−Ｒｅｓ，ｕ｝
−｛４，ＩＩＯＰ−Ｒｅｓ，ｕ，ｖ｝−｛５，ＨＴＴＰ−Ｒｅｓ，ｖ｝
となる。
【０１８７】
図９に示す紐付けルールに基づいた初期の紐付け順序は，ストリームデータの発生順番に従って，
｛０，ＨＴＴＰ−Ｒｅｑ，ｓ｝→｛１，ＩＩＯＰ−Ｒｅｑ，ｓ，ｔ，ｕ｝
→｛２，ＤＢ−Ｒｅｑ，ｔ｝→｛３，ＤＢ−Ｒｅｓ，ｕ｝
→｛４，ＩＩＯＰ−Ｒｅｓ，ｕ，ｖ｝→｛５，ＨＴＴＰ−Ｒｅｓ，ｖ｝
であるものとする。
【０１８８】
図１０は，データ配置ルールの例を示す図である。
【０１８９】
図１０に示すデータ配置ルールは，図８に示す一連の処理において発生するストリームデータを各紐付けサーバ１に分散配置するための配置ルールを示す。
【０１９０】
図１０に示すデータ配置ルールにより，ストリームデータＨＴＴＰ−Ｒｅｑ（ｓ）と，ストリームデータＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）は，データｓの値をキーとして，配置先の紐付けサーバ１が決定される。ＤＢ−Ｒｅｑ（ｔ）は，データｔの値をキーとして，配置先の紐付けサーバ１が決定される。ストリームデータＤＢ−Ｒｅｓ（ｕ），ストリームデータＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）は，データｕの値をキーとして，配置先の紐付けサーバ１が決定される。ストリームデータＨＴＴＰ−Ｒｅｓ（ｖ）は，データｖの値をキーとして，配置先の紐付けサーバ１が決定される。
【０１９１】
このような環境において，図８に示す一連の処理で発生したストリームデータの紐付けが行われるものとする。
【０１９２】
ここで，一連の処理で発生したストリームデータの紐付け処理において，ある紐付けサーバ１が，ストリームデータＨＴＴＰ−Ｒｅｑ（ｓ）にストリームデータＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）を紐付けした時点で，次の紐付け対象となるストリームデータＤＢ−Ｒｅｑ（ｔ）が配置された紐付けサーバ１の負荷が，所定の閾値を超えたものとする。
【０１９３】
図１１，図１２は，紐付け順序の更新の例を説明する図である。
【０１９４】
図１１，図１２に示す紐付け順序において，丸は，それぞれストリームデータ定義情報を示す。矢印は，紐付けする順序を示す。実線は，ストリームデータがすでに紐付け済みであることを示す。破線は，紐付けの順番が決まったストリームデータ定義情報を示す。点線は，まだ紐付けの順番が決まっていないストリームデータ定義情報を示す。
【０１９５】
ストリームデータＨＴＴＰ−Ｒｅｑ（ｓ）にストリームデータＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）を紐付けた紐付けサーバ１において，紐付け順序更新部１４は，以下に説明する手順により，紐付け順序の変更を行う。
【０１９６】
図１１（Ａ）は，紐付け順序変更前の紐付け順序であり，上記に示す最初の紐付け順序である。紐付けルールにおける発生順番に従って，ストリームデータが発生する順番に，ストリームデータ定義情報が並んでいる。
【０１９７】
ここで，次の探索対象であるストリームデータＤＢ−Ｒｅｑ（ｔ）が配置された紐付けサーバ１の負荷が１０であったものとする。なお，図１１，図１２の例では，負荷を単位のない評価値で表現している。例えば，所定の閾値が８であったとすると，紐付けサーバ１は，次の探索対象であるストリームデータＤＢ−Ｒｅｑ（ｔ）が配置された紐付けサーバ１の負荷が閾値を超えているため，紐付け順序の変更を判断する。
【０１９８】
この時点では，すでにストリームデータが紐付け済みの，ストリームデータ定義情報ＨＴＴＰ−Ｒｅｑ（ｓ），ＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）の順番が，それぞれ１番目，２番目で決定されている。すなわち，紐付け順序の変更は，３番目以降のストリームデータ定義情報について行う。
【０１９９】
図１１（Ｂ）に示すように，紐付け順序更新部１４は，まず，順番が決まっている最後のストリームデータ定義情報ＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）の次に探索可能なストリームデータの定義情報を抽出する。
【０２００】
ストリームデータＨＴＴＰ−Ｒｅｑ（ｓ）とストリームデータＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）とはすでに紐付け済みであるので，データｓ，ｔ，ｕの値は，既知となっている。よって，図１０に示すデータ配置ルールから，データｔをキーとするストリームデータＤＢ−Ｒｅｑ（ｔ）と，データｕをキーとするストリームデータＤＢ−Ｒｅｓ（ｕ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）とは，この時点で配置先の紐付けサーバ１の特定が可能なストリームデータである。なお，ストリームデータＨＴＴＰ−Ｒｅｓ（ｖ）は，この時点でキーであるデータｖが不明であるため，配置先の紐付けサーバ１の特定が不可能なストリームデータである。
【０２０１】
紐付け順序更新部１４は，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＤＢ−Ｒｅｓ（ｕ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）を，次に探索可能なストリームデータの定義情報として抽出する。
【０２０２】
紐付け順序更新部１４は，既知のデータｔ，ｕの値を用いて，ストリームデータＤＢ−Ｒｅｑ（ｔ），ＤＢ−Ｒｅｓ（ｕ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）の配置先の紐付けサーバ１を特定する。紐付け順序更新部１４は，負荷情報記憶部１１４から，特定された紐付けサーバ１の負荷の情報を取得する。ここでは，データｔをキーとするストリームデータＤＢ−Ｒｅｑ（ｔ）の配置先紐付けサーバ１の負荷として１０が，データｕをキーとするストリームデータＤＢ−Ｒｅｓ（ｕ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）の配置先紐付けサーバ１の負荷として３が，取得されたものとする。
【０２０３】
紐付け順序更新部１４は，抽出されたストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＤＢ−Ｒｅｓ（ｕ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）に，それぞれ対応する紐付けサーバ１の負荷を割り当てる。ここでは，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ）に負荷１０が，ストリームデータ定義情報ＤＢ−Ｒｅｓ（ｕ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）に負荷３が割り当てられる。
【０２０４】
紐付け順序更新部１４は，抽出されたストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＤＢ−Ｒｅｓ（ｕ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）と，順番が決まっている最後のストリームデータ定義情報ＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）との距離を求める。
【０２０５】
ここでは，ストリームデータ定義情報間の距離は，図９に示す紐付けルールにおけるストリームデータの発生順番の差である。すなわち，紐付け順序更新部１４は，ストリームデータ定義情報ＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）の発生順番１と，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＤＢ−Ｒｅｓ（ｕ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）のそれぞれの発生順番２，３，４との差を算出する。図１１（Ｂ）に示すように，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＤＢ−Ｒｅｓ（ｕ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）の距離は，それぞれ１，２，３となる。
【０２０６】
紐付け順序更新部１４は，抽出されたストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＤＢ−Ｒｅｓ（ｕ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）のコストを算出する。
【０２０７】
ここでは，抽出されたストリームデータ定義情報のコストは，負荷×距離で算出されるものとする。図１１（Ｂ）に示すように，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＤＢ−Ｒｅｓ（ｕ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）のコストは，それぞれ１０，６，９となる。
【０２０８】
紐付け順序更新部１４は，最もコストが低いストリームデータ定義情報を，次の順番のストリームデータ定義情報として決定する。すなわち，図１１（Ｂ）において，最もコストが低いストリームデータ定義情報ＤＢ−Ｒｅｓ（ｕ）が，紐付け順序において３番目のストリームデータ定義情報となる。
【０２０９】
次に，紐付け順序更新部１４は，４番目のストリームデータ定義情報の決定を行う。
【０２１０】
図１１（Ｃ）に示すように，紐付け順序更新部１４は，まず，順番が決まっている最後のストリームデータ定義情報ＤＢ−Ｒｅｓ（ｕ）の次に探索可能なストリームデータの定義情報を抽出する。データｓ，ｔ，ｕの値が既知であるので，紐付け順序更新部１４は，図１１（Ｂ）の場合と同様の手順で，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）を，次に探索可能なストリームデータの定義情報として抽出する。なお，ストリームデータＨＴＴＰ−Ｒｅｓ（ｖ）は，この時点でもキーであるデータｖが不明であるため，配置先の紐付けサーバ１の特定が不可能なストリームデータである。
【０２１１】
また，紐付け順序更新部１４は，図１１（Ｂ）の場合と同様の手順で，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ）に負荷１０を，ストリームデータ定義情報ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）に負荷３を割り当てる。
【０２１２】
紐付け順序更新部１４は，図１１（Ｂ）の場合と同様の手順で抽出されたストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）と，順番が決まっている最後のストリームデータ定義情報ＤＢ−Ｒｅｓ（ｕ）との距離を求める。図１１（Ｃ）に示すように，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ）の距離は，１となる。
【０２１３】
ストリームデータ定義情報ＩＯＰ−Ｒｅｓ（ｕ，ｖ）の距離は，図１１（Ｂ）の場合と同様の手順で求めると，１となる。ただし，ストリームデータＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）は，図１０に示すデータ配置ルールに基づいて，ストリームデータＤＢ−Ｒｅｓ（ｕ）と同じデータｕをキーとして，紐付けサーバ１に配置される。すなわち，互いに関係するストリームデータＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）とストリームデータＤＢ−Ｒｅｓ（ｕ）とは，同じ紐付けサーバ１に配置される。紐付け順序更新部１４は，同じ紐付けサーバ１に配置されるストリームデータ間の距離を０とする。ここでは，図１１（Ｃ）に示すように，ストリームデータ定義情報ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）の距離が，０となる。
【０２１４】
紐付け順序更新部１４は，図１１（Ｂ）の場合と同様の手順で，抽出されたストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）のコストを算出する。図１１（Ｃ）に示すように，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）のコストは，それぞれ１０，０となる。
【０２１５】
紐付け順序更新部１４は，最もコストが低いストリームデータ定義情報を，次の順番のストリームデータ定義情報として決定する。すなわち，図１１（Ｃ）において，最もコストが低いストリームデータ定義情報ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）が，紐付け順序において４番目のストリームデータ定義情報となる。
【０２１６】
次に，紐付け順序更新部１４は，５番目のストリームデータ定義情報の決定を行う。
【０２１７】
図１２（Ａ）に示すように，紐付け順序更新部１４は，まず，順番が決まっている最後のストリームデータ定義情報ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）の次に探索可能なストリームデータの定義情報を抽出する。データｓ，ｔ，ｕの値は，既知である。データｖの値は，ストリームデータＨＴＴＰ−Ｒｅｑ（ｓ），ＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）が紐付けられた時点では既知ではない。しかし，ストリームデータＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）が紐付けられた後では，データｖの値は，既知となっているはずである。すなわち，紐付け順序更新部１４は，図１２（Ｃ）に示すように，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＨＴＴＰ−Ｒｅｓ（ｖ）を，次に探索可能なストリームデータの定義情報として抽出する。
【０２１８】
紐付け順序更新部１４は，図１１（Ｂ）の場合と同様の手順で，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ）に負荷１０を割り当てる。
【０２１９】
しかし，ストリームデータＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）が特定されなければデータｖの値がわからないので，紐付け順序更新部１４は，この時点では，ストリームデータＨＴＴＰ−Ｒｅｓ（ｖ）が配置される紐付けサーバ１を特定することができない。このような場合には，紐付け順序更新部１４は，配置される紐付けサーバ１が特定できないストリームデータ定義情報の負荷を，例えば全紐付けサーバ１の負荷の平均値やあらかじめ定められたデフォルト値などの，所定の値とする。ここでは，紐付け順序更新部１４は，紐付けサーバ１が特定できないストリームデータ定義情報の負荷を全紐付けサーバ１の負荷の平均値とし，その値が１であるものとする。紐付け順序更新部１４は，ストリームデータ定義情報ＨＴＴＰ−Ｒｅｓ（ｖ）の負荷を，１とする。
【０２２０】
紐付け順序更新部１４は，図１１（Ｂ）の場合と同様の手順で，抽出されたストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＨＴＴＰ−Ｒｅｓ（ｖ）と，順番が決まっている最後のストリームデータ定義情報ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）との距離を求める。ただし，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ）の発生順番は，順番が決まっている最後のストリームデータ定義情報ＩＩＯＰ−Ｒｅｓ（ｕ，ｖ）の発生順番より早いので，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ）の距離は１となる。すなわち，図１２（Ａ）に示すように，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＨＴＴＰ−Ｒｅｓ（ｖ）の距離は，それぞれ１，１となる。
【０２２１】
紐付け順序更新部１４は，図１１（Ｂ）の場合と同様の手順で，抽出されたストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＨＴＴＰ−Ｒｅｓ（ｖ）のコストを算出する。図１２（Ａ）に示すように，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ），ＨＴＴＰ−Ｒｅｓ（ｖ）のコストは，それぞれ１０，１となる。
【０２２２】
紐付け順序更新部１４は，最もコストが低いストリームデータ定義情報を，次の順番のストリームデータ定義情報として決定する。すなわち，図１１（Ａ）において，最もコストが低いストリームデータ定義情報ＨＴＴＰ−Ｒｅｓ（ｖ）が，紐付け順序において５番目のストリームデータ定義情報となる。
【０２２３】
次に，紐付け順序更新部１４は，６番目のストリームデータ定義情報の決定を行う。
【０２２４】
図１２（Ｂ）に示すように，この時点で残っているのは，ストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ）だけである。すなわち，紐付け順序更新部１４は，最後に残ったストリームデータ定義情報ＤＢ−Ｒｅｑ（ｔ）を，紐付け順序において６番目のストリームデータ定義情報とする。
【０２２５】
変更後の紐付け順序は，図１２（Ｃ）に示す通りに，すなわち，
｛０，ＨＴＴＰ−Ｒｅｑ，ｓ｝→｛１，ＩＩＯＰ−Ｒｅｑ，ｓ，ｔ，ｕ｝
→｛３，ＤＢ−Ｒｅｓ，ｕ｝→｛４，ＩＩＯＰ−Ｒｅｓ，ｕ，ｖ｝
→｛５，ＨＴＴＰ−Ｒｅｓ，ｖ｝→｛２，ＤＢ−Ｒｅｑ，ｔ｝
となる。
【０２２６】
このように，本実施の形態では，紐付け順序更新部１４は，各紐付けサーバ１の負荷状況に応じて，負荷が低い紐付けサーバ１に配置されたストリームデータが優先的に早い順番で紐付けされるようなロジックで，紐付け順序を決定する。これにより，負荷が低い紐付けサーバ１に配置されたストリームデータから優先的に早い順で紐付けを行うことが可能となり，紐付け処理のレイテンシが向上する。紐付け処理のレイテンシは，一連の処理において発生するストリームデータの紐付け開始から完了までの時間を示す。負荷が高い紐付けサーバ１に配置されたストリームデータの紐付けを後回しにし，負荷が低い紐付けサーバ１に配置されたストリームデータの紐付けを行っている間に，負荷が高い紐付けサーバ１の負荷も落ちる。
【０２２７】
また，本実施の形態では，紐付け順序更新部１４は，発生順序が早いストリームデータのが優先的に早い順番で紐付けされるようなロジックで，紐付け順序を決定する。発生順序が早いストリームデータは，発生順序が遅いストリームデータよりも早く，配置先の紐付けサーバ１に入力され，データ保管部１１０に記憶される。これにより，ストリームデータよりも先に，そのストリームデータを紐付けるための検索子が紐付けサーバ１に到着する可能性が低くなる。
【０２２８】
また，本実施の形態では，紐付け順序更新部１４は，同じ紐付けサーバ１に配置されたストリームデータが優先的に連続した順番に紐付けされるようなロジックで，紐付け順序を決定する。これにより，紐付けサーバ１間での検索子の転送回数が減るため，紐付けサーバ１間を接続するネットワークの負荷が減る。
【０２２９】
また，紐付けルールで定義されたすべてのストリームデータの紐付けが完成しないような場合もある。
【０２３０】
例えば，図８に示す一連の処理において，Ｗｅｂサーバ３１からストリームデータＩＩＯＰ−Ｒｅｑ（ｓ，ｔ，ｕ）が発行された後に，ＡＰサーバ３２で障害が発生し，ストリームデータＤＢ−Ｒｅｑ（ｔ）以降のストリームデータが発行されなかったものとする。この場合には，ストリームデータＤＢ−Ｒｅｑ（ｔ）を検索する検索子が，ストリームデータＤＢ−Ｒｅｑ（ｔ）が配置された紐付けサーバ１に格納された状態で，その一連の処理のストリームデータの紐付けが，完成せずに終わってしまう。
【０２３１】
このような紐付けが完成しない検索子が紐付けサーバ１の検索子格納部１１１に蓄積されると，紐付け部１２によるマッチング処理が無駄に増えてしまい，紐付けサーバ１の負荷が高くなる。紐付け順序を変更することにより，このような完成しない検索子を，負荷が高い紐付けサーバ１に送らないようにすることが可能となり，よりバランスの取れた負荷分散を実現することができる。
【０２３２】
以上説明した紐付けサーバ１のストリームデータ紐付け部１０による処理は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録することも，ネットワークを通して提供することも可能である。
【０２３３】
以上，本実施の形態について説明したが，本発明はその主旨の範囲において種々の変形が可能であることは当然である。
【０２３４】
例えば，本実施の形態では，紐付けサーバ１は，次の紐付け対象となるストリームサーバが配置された紐付けサーバ１が所定の閾値を超えた場合に，紐付け順序の変更を行うようにしている。紐付けサーバ１は，ストリームデータの紐付けが行われ，次の検索子を生成するたびに，紐付け順序の変更を行うようにしてもよい。
【０２３５】
検索子を発行するたびに，各紐付けサーバ１の負荷状況に応じて次の紐付け対象となる紐付けサーバ１を決定すれば，分散効果が高くなる。次の紐付け対象となるストリームサーバが配置された紐付けサーバ１が所定の閾値を超えた場合に，紐付け順序の変更を行うようにすれば，紐付け処理の処理量が少なくなるため，紐付けサーバ１の処理負荷が低くなる。
【図面の簡単な説明】
【０２３６】
【図１】本実施の形態によるシステム可視化構成の概略を示す図である。
【図２】本実施の形態の分散並列処理によるストリームデータ紐付け手法の想定環境を説明する図である。
【図３】本実施の形態の分散並列処理によるストリームデータ紐付け手法の想定環境を説明する図である。
【図４】本実施の形態による紐付けサーバの構成例を示す図である。
【図５】本実施の形態による各データの構成例を示す図である。
【図６】本実施の形態のストリームデータ紐付け部によるストリームデータ紐付け処理フローチャートである。
【図７】本実施の形態の紐付け順序更新部による紐付け順序更新処理フローチャートである。
【図８】一連の処理においてストリームデータが発生する例を示す図である。
【図９】紐付けルールの例を示す図である。
【図１０】データ配置ルールの例を示す図である。
【図１１】紐付け順序の更新の例を説明する図である。
【図１２】紐付け順序の更新の例を説明する図である。
【図１３】システム可視化の技術の概要を説明する図である。
【図１４】システム可視化によって得られた統計情報の表示例を示す図である。
【図１５】システム可視化の技術における紐付けの例を説明する図である。
【図１６】複数の情報処理装置による分散処理でストリームデータの紐付けを行う例を示す図である。
【符号の説明】
【０２３７】
１  紐付けサーバ
２  データ分散配置装置
３  可視化対象システム
１０  ストリームデータ紐付け部
１１  入力部
１２  紐付け部
１３  紐付けルール解析部
１４  紐付け順序更新部
１５  検索子生成部
１６  出力部
１７  負荷収集部
１８  負荷測定部
１１０  データ保管部
１１１  検索子格納部
１１２  紐付けルール記憶部
１１３  データ配置ルール記憶部
１１４  負荷情報記憶部
【図１】
2010134513.tif 000003
【図２】
2010134513.tif 000004
【図３】
2010134513.tif 000005
【図４】
2010134513.tif 000006
【図５】
2010134513.tif 000007
【図６】
2010134513.tif 000008
【図７】
2010134513.tif 000009
【図８】
2010134513.tif 000010
【図９】
2010134513.tif 000011
【図１０】
2010134513.tif 000012
【図１１】
2010134513.tif 000013
【図１２】
2010134513.tif 000014
【図１３】
2010134513.tif 000015
【図１４】
2010134513.tif 000016
【図１５】
2010134513.tif 000017
【図１６】
2010134513.tif 000018