以下,本発明の実施の形態について,図を用いて説明する。
図1は,本実施の形態によるシステム可視化構成の概略を示す図である。
本実施の形態では,図1に示すように,Web3階層モデルである可視化対象システム3のシステム可視化の例を説明する。
図1の例に示す可視化対象システム3は,スイッチ30,Webサーバ31,AP(Application )サーバ32,DB(Database)サーバ33,LB(Load Balancer )34,FW(Firewall)35,DNS(Domain Name System)36を有する。
図1に示すWeb3階層モデルにおいて,例えば,リクエストのストリームデータは,クライアント装置(図示省略)からWebサーバ31へ,そのWebサーバ31からAPサーバ32へ,そのAPサーバ32からDBサーバ33へと,順に発行される。リクエストに対するレスポンスのストリームデータは,リクエストのときと同じサーバを介して,DBサーバ33からAPサーバ32へ,そのAPサーバ32からWebサーバ31へ,そのWebサーバから最初のクライアント装置へと,返される。
データ分散配置装置2は,各スイッチ30のミラーポートから,ポートミラーリングにより,可視化対象システム3のネットワークを流れるストリームデータを収集する。また,データ分散配置装置2は,収集された各ストリームデータを,所定のポリシに従って,各紐付けサーバ1に分散配置する。
ストリームデータの分散配置を行う手法としては,例えば,ハッシュ関数を用いる手法などがある。データ分散配置装置2は,ストリームデータが有する所定のキーとなる情報の値にハッシュ関数を用い,得られたハッシュ値で分散配置先の紐付けサーバ1を決定する。このようなハッシュ関数を用いた手法は,特定の紐付けサーバ1に集中的にストリームデータが配置されることを防ぎ,効率的なストリームデータの分散配置を実現する。
紐付けサーバ1は,可視化対象システム3から収集されたストリームデータを解析し,関係するストリームデータ同士の紐付けを行う情報処理装置である。本実施の形態によるシステム可視化では,複数の紐付けサーバ1によって,ストリームデータ紐付けの分散処理が行われる。各紐付けサーバ1は,データ分散配置装置2から受け取ったストリームデータを解析し,他の紐付けサーバ1との的確な通信により,関係するストリームデータ同士の紐付けを行う。
ここで,まず,本実施の形態の分散並列処理によるストリームデータ紐付け手法の想定環境を説明しておく。
図2,図3は,本実施の形態の分散並列処理によるストリームデータ紐付け手法の想定環境を説明する図である。
ここでは,図2(A)に示すような,Webサーバ31,APサーバ32,DBサーバ33の装置間で送受信される一連のストリームデータの紐付けを例として,ストリームデータ紐付け手法の概要を説明する。
図2(A)において,各装置間で送受信されるP(x),Q(x,y),R(y,z),S(z)が,一連の処理によって発生するストリームデータを表現したものである。
図2(A)におけるストリームデータの表記において,大文字のアルファベットP,Q,R,Sはそれぞれのストリームデータのデータタイプを示す。ストリームデータのデータタイプとは,例えば,HTTP,IIOP等のプロトコルなどのストリームデータの属性を示す情報である。
また,図2(A)におけるストリームデータの表記において,括弧内の小文字のアルファベットx,y,zは,それぞれのストリームデータが少なくとも有するデータの種別を示す。ストリームデータが有するデータの種別とは,例えば,ユーザID,パスワード,金額などであり,実際のストリームデータは,それらのデータの値を有する。
なお,複数のストリームデータの表記において,同じ小文字アルファベットが使用されている場合には,データの種別だけでなくデータ自身も共通していることを示す。例えば,上記のP(x),Q(x,y)の表記は,一連の処理のストリームデータにおいて,xに該当するデータは,データ種別だけではなく,データ自身も同じものである必要がある。また,複数のストリームデータの表記において,種別が同じでもデータが異なる場合には,違う小文字アルファベットを用いて表記している。
図2(A)に示す一連の処理において,Webサーバ31は,P(x)で示されるストリームデータをAPサーバ32に送信する。P(x)で示されるストリームデータを受信したAPサーバ32は,P(x)で示されるストリームデータに対応するQ(x,y)で示されるストリームデータをDBサーバ33に送信する。Q(x,y)で示されるストリームデータを受信したDBサーバ33は,Q(x,y)で示されるストリームデータへの応答として,R(y,z)で示されるストリームデータをAPサーバ32に送信する。R(y,z)で示されるストリームデータを受信したAPサーバ32は,P(x)で示されるストリームデータへの応答として,R(y,z)で示されるストリームデータに対応するS(z)で示されるストリームデータをWebサーバ31に送信する。
ここで,各紐付けサーバ1は,
{0,P,x}−{1,Q,x,y}−{2,R,y,z}−{3,S,z}
で示される紐付けルールを保持しているものとする。
紐付けルールとは,紐付けするストリームデータを定義する情報である。すなわち,紐付けルールは,最終的なストリームデータ紐付けの結果の型を示す情報となる。
例えば,図2(A)に示す例では,各紐付けサーバ1は,一連の処理によって発生するストリームデータP(x),Q(x,y),R(y,z),S(z)の紐付けが定義された上記の紐付けルールを保有する。
上記の紐付けルールにおいて,各{}は,紐付けするストリームデータの型を示している。すなわち,{}で括られた1つの情報が,紐付けの対象となるストリームデータを定義する情報である。{}内の表記において,数字0,1,2,3は,一連の処理におけるストリームデータの発生順番を示す情報である。ここでは,数値の小さいものから順にストリームデータが発生している。{}内の表記において,大文字のアルファベットP,Q,R,Sは,ストリームデータのデータタイプを示す。小文字のアルファベットx,y,zは,ストリームデータが有するデータの種別を示す。
ストリームデータの紐付け順序は,紐付けルールに基づいて決定されるものとする。ここでは,ストリームデータの紐付け順序は,上記の紐付けルールにおけるストリームデータの発生順番に従って,
P(x)→Q(x,y)→R(y,z)→S(z)
となる。
なお,ストリームデータの紐付け順序が,紐付けルールにおけるストリームデータの発生順番に従わない場合もある。
例えば,
{0,T,x}−{1,U,x,y}−{2,V,z}−{3,W,y,z}
という紐付けルールがある場合に,発生順番でストリームデータの紐付け順序が決定されると,紐付け順序は,
T(x)→U(x,y)→V(z)→W(y,z)
となる。しかし,ストリームデータV(z)は,ストリームデータT(x),ストリームデータU(x,y)と共通するデータを持たない。そのため,ストリームデータT(x)とストリームデータU(x,y)とを紐付けた後に,その紐付けデータに紐付けるストリームデータV(z)を特定することは困難となる。ここでは,発生順番でストリームデータを並べた場合に,隣接するストリームデータ間で共通するデータを持たない状態を,断絶と呼ぶものとする。
ストリームデータW(y,z)は,ストリームデータU(x,y)と共通するデータyを持つ。また,ストリームデータW(y,z)は,ストリームデータV(z)と共通するデータzを持つ。すなわち,紐付け順序を,
T(x)→U(x,y)→W(y,z)→V(z)
と決定すれば,断絶があっても,ストリームデータの紐付け処理が容易となる。
紐付けルールの設定作業者は,紐付けルールの設定時に,ストリームデータの紐付け順序も設定する。紐付けルールの設定を行う装置が,設定された紐付けルールから,断絶の有無も考慮して自動的に紐付け順序を決定し,設定する手段を備えていてもよい。
また,紐付けルールであらかじめ紐付け順序が定義されていてもよい。例えば,
{0,T,x}→{1,U,x,y}→{3,W,y,z}→{2,V,z}
といったように,紐付け順序を含めて紐付けルールが定義されてもよい。
図2(B)は,図2(A)に示す一連の処理において発生するストリームデータのデータ配置ルールを示す。
データ配置ルールは,ストリームデータを各紐付けサーバ1に分散配置するための情報である。図2(B)に示すデータ配置ルールでは,ストリームデータのデータタイプごとに,ストリームデータが有するどの情報を分散配置のキーとなる情報として用いるかが定義されている。このようなデータ配置ルールの定義情報については,データ分散配置装置2と各紐付けサーバ1とが,共通のものを保持している。
例えば,図2(B)に示すように,図2(A)に示す一連の処理において発生したデータタイプがPのストリームデータは,データ分散配置装置2によって,データxの値を用いたハッシュ関数(x)で特定される紐付けサーバ1に配置される。同様に,データ分散配置装置2によって,データタイプがQのストリームデータも,データxの値を用いたハッシュ関数(x)で特定される紐付けサーバ1に配置される。また,データ分散配置装置2によって,データタイプがRのストリームデータは,データyの値を用いたハッシュ関数(y)で特定される紐付けサーバ1に配置される。また,データ分散配置装置2によって,データタイプがSのストリームデータは,データzの値を用いたハッシュ関数(z)で特定される紐付けサーバ1に配置される。
図3は,図2(A)に示す一連の処理において発生したストリームデータの,実際の紐付け処理の流れを示している。
図3において,紐付けサーバ1aには,データ分散配置装置2によって,図2(B)に示すデータ配置ルールに基づいて,ストリームデータP(x1 ),ストリームデータQ(x1 ,y1 )が配置されるものとする。また,紐付けサーバ1bには,データ分散配置装置2によって,図2(B)に示すデータ配置ルールに基づいて,ストリームデータR(y1 ,z1 )が配置されるものとする。また,紐付けサーバ1cには,データ分散配置装置2によって,図2(B)に示すデータ配置ルールに基づいて,ストリームデータS(z1 )が配置されるものとする。ここで,x1 ,y1 ,z1 は,それぞれ,配置されたストリームデータが有する,データx,データy,データzの値であるものとする。
紐付けサーバ1aは,データ分散配置装置2により配置されたストリームデータP(x1 )が紐付け順序の最初のストリームデータであるので,ストリームデータP(x1 )を紐付ける最初のストリームデータとする,最初の紐付けデータ[P(x1 )]を生成する。
紐付けデータは,ストリームデータの紐付け結果となるデータである。図3の例では,紐付けデータは,紐付けられたストリームデータが“−”で結ばれ,[]で括られた形で表記されるものとする。ストリームデータ紐付けの過程において紐付けサーバ1間で送受信される紐付けデータは,ストリームデータ紐付けの途中結果である。紐付けルールで定義された一通りのストリームデータが紐付けられた紐付けデータは,ストリームデータ紐付けの最終結果となる。
次に,紐付けサーバ1aは,ストリームデータP(x1 )の次に紐付けするストリームデータを検索するための検索子を生成する。
検索子は,ストリームデータ紐付けの途中結果である紐付けデータに次に紐付けするストリームデータを検索し,検出されたストリームデータを途中結果である紐付けデータに紐付けするための情報である。すなわち,検索子は,次に紐付けするストリームデータが配置された紐付けサーバ1に対して,途中結果である紐付けデータに次のストリームデータの紐付け処理を要求する,紐付け要求となる。
検索子は,次に紐付けするストリームデータを検索するための検索条件,ストリームデータ紐付けの途中結果である紐付けデータ等の情報を有する。図3に示す例では,検索子が,
{検索条件,紐付けデータ}
の形で表現されている。
紐付けサーバ1aは,ストリームデータP(x1 )の次に紐付けするストリームデータの検索条件を生成する。このとき,紐付けサーバ1aは,検索するストリームデータが有するデータxの値がx1 であることがすでに分かっているので,上記の紐付けルールの発生順番に基づいた紐付け順序から,次に紐付けするストリームデータの検索条件Q(x1 ,*y)を生成する。
ここで,“*”はワイルドカードを意味し,検索条件における“*”付きのデータ*yは,紐付けルールにおいてyで定義されたデータ種別の何らかの値のデータを示す。すなわち,検索条件Q(x1 ,*y)は,データタイプがQであり,値がx1 のデータxと何らかの値のデータyとを有するストリームデータを検索するための検索条件となる。
紐付けサーバ1aは,生成された検索条件Q(x1 ,*y)と,ストリームデータ紐付けの途中結果である紐付けデータ[P(x1 )]とから,
検索子{Q(x1 ,*y),[P(x1 )]}
を生成する。
紐付けサーバ1aは,生成された検索子を,次に紐付けするストリームデータが配置された紐付けサーバ1に渡す。次に紐付けするストリームデータのデータタイプはQであるので,紐付けサーバ1aは,図2(B)に示すデータ配置ルールから,データxをキーとして,検索子を渡す相手先の紐付けサーバ1を特定する。ここでは,データxの値がx1 であるので,紐付けサーバ1aが検索子を渡す相手先の紐付けサーバ1は,紐付けサーバ1aすなわち自分自身となる。
紐付けサーバ1aは,自身に配置されたストリームデータが記憶された記憶部から,検索子が有する検索条件Q(x1 ,*y)を満たすストリームデータを検索する。ここでは,ストリームデータQ(x1 ,y1 )が,検索条件Q(x1 ,*y)を満たすストリームデータとして検出されたものとする。
紐付けサーバ1aは,検索子が有する紐付けデータ[P(x1 )]に,検出されたストリームデータQ(x1 ,y1 )を紐付けし,新たな紐付けデータ[P(x1 )−Q(x1 ,y1 )]を生成する。
紐付けサーバ1aは,上記の紐付けルールで生成された新たな紐付けデータを検証し,紐付けデータがまだ完成していないことを確認する。
紐付けサーバ1aは,ストリームデータQ(x1 ,y1 )の次に紐付けするストリームデータの検索条件を生成する。このとき,紐付けサーバ1aは,検索するストリームデータが有するデータyの値がy1 であることがすでに分かっているので,上記の紐付けルールの発生順番に基づいた紐付け順序から,次に紐付けするストリームデータの検索条件R(y1 ,*z)を生成する。
紐付けサーバ1aは,生成された検索条件R(y1 ,*z)と,ストリームデータ紐付けの途中結果である紐付けデータ[P(x1 )−Q(x1 ,y1 )]とから,
検索子{R(y1 ,*z),[P(x1 )−Q(x1 ,y1 )]}
を生成する。
紐付けサーバ1aは,次に紐付けするストリームデータのデータタイプはRであるので,図2(B)に示すデータ配置ルールから,データyをキーとして,検索子を渡す相手先の紐付けサーバ1を特定する。ここでは,データyの値がy1 であるので,紐付けサーバ1aは,ハッシュ関数(y1 )で特定される紐付けサーバ1bに,生成された検索子を送信する。
紐付けサーバ1bは,紐付けサーバ1aから検索子を受信すると,自身に配置されたストリームデータが記憶された記憶部から,検索子が有する検索条件R(y1 ,*z)を満たすストリームデータを検索する。ここでは,ストリームデータR(y1 ,z1 )が,検索条件R(y1 ,*z)を満たすストリームデータとして検出されたものとする。
紐付けサーバ1bは,検索子が有する紐付けデータ[P(x1 )−Q(x1 ,y1 )]に,検出されたストリームデータR(y1 ,z1 )を紐付けし,新たな紐付けデータ[P(x1 )−Q(x1 ,y1 )−R(y1 ,z1 )]を生成する。
紐付けサーバ1bは,上記の紐付けルールで生成された新たな紐付けデータを検証し,紐付けデータがまだ完成していないことを確認する。
紐付けサーバ1bは,ストリームデータR(y1 ,z1 )の次に紐付けするストリームデータの検索条件を生成する。このとき,紐付けサーバ1bは,検索するストリームデータが有するデータzの値がz1 であることがすでに分かっているので,上記の紐付けルールの発生順番に基づいた紐付け順序から,次に紐付けするストリームデータの検索条件S(z1 )を生成する。
紐付けサーバ1bは,生成された検索条件S(z1 )と,ストリームデータ紐付けの途中結果である紐付けデータ[P(x1 )−Q(x1 ,y1 )−R(y1 ,z1 )]とから,
検索子{S(z1 ),[P(x1 )−Q(x1 ,y1 )−R(y1 ,z1 )]}
を生成する。
紐付けサーバ1bは,次に紐付けするストリームデータのデータタイプはSであるので,図2(B)に示すデータ配置ルールから,データzをキーとして,検索子を渡す相手先の紐付けサーバ1を特定する。ここでは,データzの値がz1 であるので,紐付けサーバ1bは,ハッシュ関数(z1 )で特定される紐付けサーバ1cに,生成された検索子を送信する。
紐付けサーバ1cは,紐付けサーバ1bから検索子を受信すると,自身に配置されたストリームデータが記憶された記憶部から,検索子が有する検索条件S(z1 )を満たすストリームデータを検索する。ここでは,ストリームデータS(z1 )が検出されたものとする。
紐付けサーバ1cは,検索子が有する紐付けデータ[P(x1 )−Q(x1 ,y1 )−R(y1 ,z1 )]に,検出されたストリームデータS(z1 )を紐付けし,新たな紐付けデータ[P(x1 )−Q(x1 ,y1 )−R(y1 ,z1 )−S(z1 )]を生成する。
紐付けサーバ1cは,上記の紐付けルールで生成された新たな紐付けデータを検証し,紐付けデータが,図2(A)に示す一連の処理で発行されたストリームデータの紐付けにおける,完成した紐付けデータであることを確認する。
このように,ストリームデータを各紐付けサーバ1に分散配置し,次のストリームデータの検索条件とそれまでの紐付け結果とを有する検索子を,紐付けサーバ1間で送受信し合うことにより,ストリームデータ紐付けの分散処理を行うことができる。
本実施の形態では,このような分散並列処理によるストリームデータ紐付けの想定環境を例として,分散環境における,効率的なストリームデータ紐付けの技術について説明する。
図4は,本実施の形態による紐付けサーバの構成例を示す図である。
図4において,実線の矢印は処理の推移を示し,点線の矢印はデータの格納や参照を示す。
紐付けサーバ1は,ストリームデータ紐付け部10を備える。ストリームデータ紐付け部10は,関係するストリームデータ同士の紐付けを行う手段であり,紐付けサーバ1のコンピュータが備えるCPU,メモリ等のハードウェアと,ソフトウェアプログラムとにより実現される。
ストリームデータ紐付け部10は,入力部11,紐付け部12,紐付けルール解析部13,紐付け順序更新部14,検索子生成部15,出力部16,負荷収集部17,負荷測定部18を備える。
また,ストリームデータ紐付け部10は,データ保管部110,検索子格納部111,紐付けルール記憶部112,データ配置ルール記憶部113,負荷情報記憶部114を備える。
データ保管部110は,ストリームデータや紐付けデータなどのデータを保管する記憶部である。検索子格納部111は,検索子を格納する記憶部である。紐付けルール記憶部112は,定義された紐付けルールを記憶する記憶部である。データ配置ルール記憶部113は,定義されたデータ配置ルールを記憶する記憶部である。本実施の形態では,紐付けルール記憶部112に存在する紐付けルールに対して,1対1に対応するデータ配置ルールがデータ配置ルール記憶部113に存在するものとする。負荷情報記憶部114は,各紐付けサーバ1の負荷状況を示す情報を記憶する記憶部である。
なお,本実施の形態では,紐付けルール記憶部112が,定義された紐付けルールとその紐付けルールに基づいた初期設定の紐付け順序とを,セットで記憶するものとする。
入力部11は,ストリームデータや検索子を入力する。
具体的には,入力部11は,データ分散配置装置2により分散配置されたストリームデータを入力する。入力部11は,入力されたストリームデータをデータ保管部110に格納する。また,入力部11は,紐付けサーバ1から検索子を入力する。入力部11は,入力された検索を検索子格納部111に格納する。
紐付け部12は,検索子が有する紐付けデータと,検索子が有する検索条件を満たしたストリームデータとの紐付けを行う。
具体的には,紐付け部12は,ストリームデータが入力されると,入力されたストリームデータが,検索子格納部111に記憶されたいずれかの検索子が有する検索条件を満たすかを,マッチングにより確認する。紐付け部12は,入力されたストリームデータが検索条件を満たす検索子が検索子格納部111に存在すれば,その検索子が有する紐付けデータと入力されたストリームデータとを紐付けし,紐付け結果を新たな紐付けデータとする。
また,紐付け部12は,入力されたストリームデータが検索条件を満たす検索子が検索子格納部111に存在しなければ,入力されたストリームデータを最初に紐付けるストリームデータとして定義している紐付け順序が,紐付けルール記憶部112に存在するかを確認する。紐付け部12は,入力されたストリームデータを最初に紐付けるストリームデータとして定義する紐付け順序が紐付けルール記憶部112から検出されれば,入力されたストリームデータを最初に紐付けるストリームデータとする,最初の紐付けデータを新たに生成する。
また,紐付け部12は,検索子が入力されると,入力された検索子が有する検索条件を満たすストリームデータがデータ保管部110に存在するかを,マッチングにより確認する。紐付け部12は,入力された検索子が有する検索条件を満たすストリームデータがデータ保管部110に存在すれば,入力された検索子が有する紐付けデータと検出されたストリームデータとを紐付けし,紐付け結果を新たな紐付けデータとする。
ストリームデータが先に入力される場合もあれば,検索子が先に入力される場合もある。そのどちらのケースにも対応できるように,紐付け部12は,ストリームデータが入力されたときには,入力されたストリームデータに対応する検索子を探索し,検索子が入力された場合には,入力された検索子に対応するストリームデータを探索する。
紐付けルール解析部13は,新たな紐付けデータと紐付けルール記憶部112に記憶された紐付けルールとのマッチングによる解析処理を行う。紐付けルールを用いた解析処理により,紐付けルール解析部13は,新たな紐付けデータが,紐付けルールに基づいて完成した紐付けデータであるかを確認することができる。また,紐付けルールを用いた解析処理により,紐付けルール解析部13は,新たな紐付けデータが,どの紐付けルールに基づいて生成された紐付けデータであるかを確認することができる。
具体的には,新たな紐付けデータが紐付けルール記憶部112に記憶されたいずれかの紐付けルールと全体がマッチしていれば,その新たな紐付けデータは,全体がマッチした紐付けルールに基づいて完成していることになる。紐付けルール解析部13は,完成した紐付けデータを,データ保管部110に格納する。
また,新たな紐付けデータが紐付けルール記憶部112に記憶されたいずれかの紐付けルールの一部にマッチしていれば,その新たな紐付けデータは,部分的にマッチした紐付けルールに基づいて生成された紐付けデータであることがわかる。
紐付け順序更新部14は,各紐付けサーバ1の負荷状況に応じて,ストリームデータの紐付け順序を決定する。
具体的には,紐付け順序更新部14は,新たな紐付けデータに対応する紐付け順序から,次の紐付け対象となるストリームデータを特定する。本実施の形態では,新たな紐付けデータに対応する紐付け順序は,紐付け順序がまだ更新されていなければ,新たな紐付けデータに対応する紐付けルールに基づいた初期の紐付け順序である。紐付け順序が更新されていれば,新たな紐付けデータに対応する紐付け順序は,新たな紐付けデータのもととなった紐付けデータを有する検索子に含まれた紐付け順序である。
また,紐付け順序更新部14は,データ配置ルール記憶部113に記憶されたデータ配置ルールに基づいて,次の紐付け対象となるストリームデータが配置された紐付けサーバ1を特定する。
紐付け順序更新部14は,特定された紐付けサーバ1の負荷情報を,負荷情報記憶部114から取得する。紐付け順序更新部14は,特定された紐付けサーバ1の負荷が,所定の閾値を超えているかを確認する。特定された紐付けサーバ1の負荷が所定の閾値を超えている場合には,紐付け順序更新部14は,各紐付けサーバ1の負荷状況に応じた紐付け順序の更新を行う。
なお,紐付けサーバ1の負荷は,例えば,紐付けサーバ1が備えるCPUの使用率やハードディスクの使用量などである。紐付け順序更新部14による紐付け順序の更新において,どのような負荷の情報を用いるかの設計は,任意である。
紐付け順序更新部14は,紐付け順序を決定するための判断要素として,各紐付けサーバ1の負荷を用いる。すなわち,紐付け順序更新部14は,紐付け順序の更新において,負荷が低い紐付けサーバ1に配置されたストリームデータの紐付け順番が,優先的に早い順番となるような紐付け順序の決定ルールに従って,紐付け順序を決定する。
また,紐付け順序の更新処理において,紐付け順序更新部14がストリームデータが発生する順番に応じた重み付けを行うようにしてもよい。すなわち,紐付け順序更新部14は,紐付け順序の更新において,発生順番が早いストリームデータの紐付け順番が,優先的に早い順番となるような紐付け順序の決定ルールに従って,紐付け順序を決定する。
また,紐付け順序の更新において,紐付け順序更新部14が同じ紐付けサーバ1に配置されたストリームデータをできるだけ続けて紐付けするように重み付けを行うようにしてもよい。すなわち,紐付け順序更新部14は,紐付け順序の更新処理において,同じ紐付けサーバ1に配置されたストリームデータが,優先的に連続して紐付けされるような紐付け順序の決定ルールに従って,紐付け順序を決定する。
検索子生成部15は,次の紐付け対象となるストリームデータを検索するための検索子を生成する。
具体的には,検索子生成部15は,次の紐付け対象となるストリームデータを検索するための検索条件を生成する。検索子生成部15は,生成された検索条件と新たな紐付けデータとを有する検索子を生成する。また,紐付け順序が初期設定から変更されている場合には,検索子生成部15は,さらに変更された紐付け順序の情報を検索子に含ませる。
なお,紐付け順序の変更に関わらず,紐付け順序の情報を検索子に含ませるようにしてもよい。紐付け順序が初期設定から変更されている場合にのみ紐付け順序の情報を検索子に含ませるようにすれば,通信データ量が少なく済む。
出力部16は,生成された検索子を,次の紐付け対象となるストリームデータが配置された紐付けサーバ1に対して出力する。
具体的には,出力部16は,データ配置ルール記憶部113に記憶されたデータ配置ルールに基づいて,次の紐付け対象となるストリームデータが配置された紐付けサーバ1を特定する。出力部16は,特定された紐付けサーバ1に対して,生成された検索子を送信する。
負荷収集部17は,各紐付けサーバ1の負荷情報を収集し,収集した負荷情報を負荷情報記憶部114に記憶する。
負荷測定部18は,自装置の負荷を測定する。
例えば,負荷測定部18は,定期的に自装置の負荷を測定し,得られた負荷情報をブロードキャストで各紐付けサーバ1に送信する。負荷収集部17は,各紐付けサーバ1から負荷情報を受け取ると,受け取った負荷情報を負荷情報記憶部114に記憶する。
また,負荷収集部17が,必要な紐付けサーバ1に対して負荷情報を要求するようにしてもよい。例えば,負荷収集部17は,紐付け順序更新部14による紐付け順序更新処理時に,負荷情報が必要となる紐付けサーバ1に対して,負荷情報を要求する。負荷情報を要求された紐付けサーバ1では,負荷測定部18が負荷を測定し,得られた負荷情報を,負荷情報の要求元の紐付けサーバ1に送る。負荷情報の要求元の紐付けサーバ1では,負荷収集部17が,負荷情報の要求先から受け取った負荷情報を負荷情報記憶部114に記憶する。
なお,各紐付けサーバ1において負荷測定部18がどのような負荷を測定するのか,また,各紐付けサーバ1において負荷収集部17がどのような負荷の情報を収集するのかの設計は,任意である。
図5は,本実施の形態による各データの構成例を示す図である。
図5(A)は,ストリームデータのデータ構成例を示す。ストリームデータは,例えば,データタイプ,タイムスタンプ,データ等の情報を有する。データタイプは,例えばHTTP,IIOP等のプロトコルなど,ストリームデータの種別を示す情報である。タイムスタンプは,ストリームデータが生成された時間を示す情報である。データは,例えばユーザ名=小橋,品物=本,金額=1000などのストリームデータ内部に保持された各データである。
図5(B)は,検索子のデータ構成例を示す。検索子は,例えば,検索条件,紐付けデータ等の情報を有する。検索条件は,次の紐付け対象となるストリームデータの条件を示す情報である。紐付けデータは,ストリームデータ紐付けの途中結果である。紐付け順序が初期設定から変更された場合には,変更された紐付け順序を示す情報が,検索子に含まれるようにしてもよい。
検索条件は,例えば,
・(データタイプ=HTTP,ユーザ名=小橋)
・(データタイプ=IIOP,ユーザ名=小橋,品物=*)
などである。“*”はワイルドカードを示している。
前段の検索条件は,データタイプがHTTPで,ユーザ名=小橋のデータを有するストリームデータを検索する検索条件である。後段の検索条件は,データタイプがIIOPで,ユーザ名=小橋のデータ,種別が品物である何らかのデータを有するストリームデータを検索する検索条件である。
図5(C)は,紐付けデータのデータ構成例を示す。紐付けデータは,例えば,それまで紐付けられたストリームデータごとに,データタイプ,データ等の情報を有する。データタイプは,紐付けされたストリームデータの種別を示す情報である。データは,紐付けられたストリームデータが内部に有するデータの情報である。
紐付けデータは,例えば,
・((HTTP,ユーザ名=小橋),)
・((HTTP,ユーザ名=小橋),
(IIOP,ユーザ名=小橋,品物=本),)
などである。
前段の紐付けデータは,データタイプがHTTPで,ユーザ名=小橋のデータを有するストリームデータが最初に紐付けられただけの紐付けデータの例である。後段の紐付けデータは,前段の紐付けデータに,さらにデータタイプがIIOPで,ユーザ名=小橋のデータ,品物=本のデータを有するストリームデータが紐付けられた紐付けデータの例である。
なお,紐付けデータのデータ形式としては,例えば,ストリームデータをそのまま紐付ける形式,ストリームデータから必要な情報のみを抽出して紐付ける形式,ストリームデータの保管場所へのポインタ情報を紐付ける形式など,さまざまな形式が考えられる。
図5(D)は,紐付けルールのデータ構成例を示す。紐付けルールは,ストリームデータの紐付け関係があらかじめ定義された情報である。各紐付けサーバ1は,紐付けルールの定義に従って,ストリームデータ紐付けの処理を行う。このような紐付けルールを用いることにより,ストリームデータ間の関係を明らかにすることができる。
紐付けルールは,紐付けするストリームデータごとに,発生順番,データタイプ,データ種別等の情報を有する。発生順番は,一連の処理過程でストリームデータが発生する順序を示す情報である。データタイプは,紐付けするストリームデータの種別を示す情報である。データ種別は,紐付けするストリームデータが内部に有するデータの種別を示す情報である。
紐付けルールは,例えば,
・(1,HTTPログイン,ユーザ名,パスワード)
−(2,IIOP認証,ユーザ名,パスワード)
−(3,DBパスワード問い合わせ,ユーザ名)
などである。
この紐付けルールは,一連の処理において最初に発行された,タイプがHTTPログインで,ユーザ名,パスワードのデータを有するストリームデータと,そのストリームデータと関係する,2番目に発行された,タイプがIIOP認証で,共通のユーザ名,パスワードのデータを有するストリームデータと,そのストリームデータに関係する,3番目に発行された,タイプがDBパスワード問い合わせで,共通のユーザ名のデータを有するストリームデータとを,順に紐付けることを定義している。
図6は,本実施の形態のストリームデータ紐付け部によるストリームデータ紐付け処理フローチャートである。
各紐付けサーバ1は,データを入力するごとに,図6に示すストリームデータ紐付け処理を実行する。
紐付けサーバ1において,入力部11は,データを取得すると(ステップS10),取得されたデータがストリームデータであれば(ステップS11のYES),データ保管部110に取得されたストリームデータを格納する(ステップS12)。
紐付け部12は,取得されたストリームデータと,検索子格納部111に格納された検索子が有する検索条件とのマッチングを行う(ステップS13)。紐付け部12は,取得されたストリームデータにマッチする検索条件を有する検索子が存在すれば(ステップS13のYES),検出された検索子に含まれる紐付けデータと取得されたストリームデータとをもとに,新たな紐付けデータを生成する(ステップS14)。
紐付けルール解析部13は,生成された紐付けデータと紐付けルール記憶部112に保持された紐付けルールとのマッチングを行う(ステップS15)。紐付けルール解析部13は,生成された紐付けデータがいずれかの紐付けルールを網羅していれば(ステップS15のYES),その完成された紐付けデータをデータ保管部110に格納し(ステップS16),処理を終了する。
ステップS15の判定において,生成された紐付けデータがまだ完成されたものでなければ(ステップS15のNO),紐付け順序更新部14は,後述の紐付け順序更新処理を行う(ステップS17)。
検索子生成部15は,次の紐付け対象となるストリームデータの検索条件を生成し,生成された検索条件と新たな紐付けデータとを有する検索子を生成する(ステップS18)。
検索条件の生成において,検索子生成部15は,紐付け順序が紐付けルールに基づいた最初の紐付け順序から変更されていなければ,紐付けルールに基づいた最初の紐付け順序に従って,次の紐付け対象となるストリームデータの検索条件を生成する。
また,検索子生成部15は,紐付け順序が紐付けルールに基づいた最初の紐付け順序から変更されていれば,変更された紐付け順序に従って,次の紐付け対象となるストリームデータの検索条件を生成する。このとき,検索子生成部15は,生成された検索条件と,新たな紐付けデータと,変更された紐付け順序とを有する検索子を生成する。
出力部16は,データ配置ルール記憶部113に記憶されたデータ配置ルールに基づいて特定された,次の紐付け対象となるストリームデータを保持する紐付けサーバ1に,生成された検索子を転送し(ステップS19),処理を終了する。
ステップS13の判定において,取得されたストリームデータにマッチする検索条件を有する検索子が存在しなければ(ステップS13のNO),紐付け部12は,取得されたストリームデータと紐付けルール記憶部112に保持された紐付け順序とのマッチングを行う(ステップS20)。紐付け部12は,取得されたストリームデータと最初のストリームデータがマッチする紐付け順序が存在しなければ(ステップS20のNO),処理を終了する。
紐付け部12は,取得されたストリームデータが紐付けルール記憶部112に保持されたいずれかの紐付け順序で定義された最初のストリームデータとマッチすれば(ステップS20のYES),取得されたストリームデータを最初に紐付けするストリームデータとする紐付けデータを生成する(ステップS21)。
紐付け順序更新部14は,後述の紐付け順序更新処理を行う(ステップS17)。検索子生成部15は,検索子を生成する(ステップS18)。出力部16は,次の紐付け対象となるストリームデータを保持する紐付けサーバ1に,生成された検索子を転送し(ステップS19),処理を終了する。
入力部11は,取得されたデータが検索子であれば(ステップS22のYES),検索子格納部111に取得された検索子を格納する(ステップS23)。
紐付け部12は,取得された検索子の検索条件と,データ保管部110に保管されたストリームデータとのマッチングを行う(ステップS24)。紐付け部12は,取得された検索子の検索条件にマッチするストリームデータが存在しなければ(ステップS24のNO),処理を終了する。
紐付け部12は,取得された検索子の検索条件にマッチするストリームデータが存在すれば(ステップS24のYES),取得された検索子に含まれる紐付けデータと検出されたストリームデータとをもとに,新たな紐付けデータを生成する(ステップS14)。
紐付けルール解析部13は,生成された紐付けデータと紐付けルール記憶部112に保持された紐付けルールとのマッチングを行う(ステップS15)。紐付けルール解析部13は,生成された紐付けデータがいずれかの紐付けルールを網羅していれば(ステップS15のYES),その完成された紐付けデータをデータ保管部110に格納し(ステップS16),処理を終了する。生成された紐付けデータがまだ完成されたものでなければ(ステップS15のNO),紐付け順序更新部14は,後述の紐付け順序更新処理を行う(ステップS17)。検索子生成部15は,検索子を生成する(ステップS18)。出力部16は,次の紐付け対象となるストリームデータを保持する紐付けサーバ1に,生成された検索子を転送し(ステップS19),処理を終了する。
図7は,本実施の形態の紐付け順序更新部による紐付け順序更新処理フローチャートである。
以下では,紐付けルールや紐付け順序において,紐付けするストリームデータを定義する情報を,ストリームデータ定義情報と呼ぶものとする。
紐付け順序更新部14は,次の紐付け対象となるストリームデータが配置された紐付けサーバ1を特定する(ステップS170)。すなわち,紐付け順序更新部14は,現在の紐付け順序に従って,生成された紐付けデータに紐付けする,次の紐付け対象となるストリームデータを特定する。紐付け順序更新部14は,データ配置ルール記憶部113に記憶されたデータ配置ルールに基づいて,次の紐付け対象となるストリームデータが配置された紐付けサーバ1を特定する。
紐付け順序更新部14は,負荷情報記憶部114から,特定された紐付けサーバの負荷情報を取得する(ステップS171)。
紐付け順序更新部14は,取得された負荷情報から,特定された紐付けサーバの負荷が所定の閾値以上であるかを判定する(ステップS172)。特定された紐付けサーバの負荷が所定の閾値を下回っていれば(ステップS172のNO),紐付け順序更新部14は,紐付け順序更新処理を終了する。
特定された紐付けサーバの負荷が所定の閾値以上であれば(ステップS172のYES),紐付け順序更新部14は,紐付け順序から次に探索可能なストリームデータ定義情報を抽出する(ステップS173)。すなわち,紐付け順序更新部14は,紐付け順序において,まだ紐付けの順番が決まっていないストリームデータ定義情報のうち,すでに順番が決まったストリームデータ定義情報が有するデータをキー情報として持つストリームデータ定義情報を抽出する。
紐付け順序更新部14は,抽出されたストリームデータ定義情報に,それぞれ対応する負荷を割り当てる(ステップS174)。
すでに紐付けられたストリームデータ定義情報が有するデータをキー情報として持つストリームデータ定義情報は,キー情報の値が分かっているため,データ配置ルールに基づいて,探索するストリームデータが配置された紐付けサーバ1を特定することができる。すなわち,紐付け順序更新部14は,すでに紐付けられたストリームデータ定義情報が有するデータをキー情報として持つストリームデータ定義情報には,特定された紐付けサーバ1の負荷情報を負荷情報記憶部114から取得し,得られた負荷を割り当てる。
すでに紐付けられたストリームデータ定義情報が有するデータをキー情報として持たないストリームデータ定義情報は,この段階では探索するストリームデータが配置された紐付けサーバ1を特定することができない。紐付け順序更新部14は,すでに紐付けられたストリームデータ定義情報が有するデータをキー情報として持つストリームデータ定義情報には,所定の負荷を割り当てる。所定の負荷は,例えば,全紐付けサーバ1の負荷の平均値や,所定のデフォルト値などである。
紐付け順序更新部14は,抽出されたストリームデータ定義情報の距離を算出する(ステップS175)。
本実施の形態において,紐付け順序更新部14は,抽出されたストリームデータ定義情報の距離として,抽出されたストリームデータ定義情報と,現時点で決定されている順番が最後のストリームデータ定義情報との発生順番の差を算出する。すなわち,一連の処理で発生するストリームデータにおいて,抽出されたストリームデータ定義情報の発生順番が3で,現時点で決定されている順番が最後のストリームデータ定義情報の発生順番が1であれば,抽出されたストリームデータ定義情報の距離は,3−1=2となる。
なお,本実施の形態では,抽出されたストリームデータ定義情報の発生順番が,現時点で決定されている順番が最後のストリームデータ定義情報の発生順番よりも早い場合には,紐付け順序更新部14は,抽出されたストリームデータ定義情報の距離を1とする。また,紐付け順序更新部14は,紐付けする2つのストリームデータが同じ紐付けサーバ1に配置されているときには,それら2つのストリームデータ間の距離を0とする。
紐付け順序更新部14は,紐付けルールから,抽出されたストリームデータ定義情報の発生順番と,現時点で決定されている順番が最後のストリームデータ定義情報の発生順番とを取得する。紐付け順序更新部14は,抽出されたストリームデータ定義情報の発生順番と,現時点で決定されている順番が最後のストリームデータ定義情報の発生順番との差を,抽出されたストリームデータ定義情報の距離として算出する。このとき,紐付け順序更新部14は,抽出されたストリームデータ定義情報の発生順番が,現時点で決定されている順番が最後のストリームデータ定義情報の発生順番より早い場合には,抽出されたストリームデータ定義情報の距離を1とする。
また,紐付け順序更新部14は,データ配置ルールを参照し,抽出されたストリームデータ定義情報と,現時点で決定されている順番が最後のストリームデータ定義情報とが,同じ紐付けサーバ1に配置されるストリームデータの紐付けの定義情報であれば,抽出されたストリームデータ定義情報の距離を0とする。
紐付け順序更新部14は,抽出されたストリームデータ定義情報のコストを算出する(ステップS176)。本実施の形態では,抽出されたストリームデータ定義情報のコストは,紐付け順序更新部14が,抽出されたストリームデータ定義情報に割り当てた負荷に対して,算出されたストリームデータ定義情報の距離で重み付けすることにより,算出される。
紐付け順序更新部14は,最もコストが低いストリームデータ定義情報を,次の順番のストリームデータ定義情報として決定する(ステップS177)。
紐付け順序更新部14は,まだ順番が決定されていないストリームデータ定義情報があるかを判定する(ステップS178)。紐付け順序更新部14は,まだ順番が決定されていないストリームデータ定義情報があれば(ステップS178のYES),ステップS173に戻り,処理を繰り返す。紐付け順序更新部14は,まだ順番が決定されていないストリームデータ定義情報がなければ(ステップS178のNO),紐付け順序更新処理を終了する。
なお,図7に示す紐付け順序更新処理は,あくまで一例である。例えば,紐付けサーバ1の負荷状況をより重く判断するか,ストリームデータの発生順序をより重く判断するか等のルールや,加算や乗算等の重み付けの仕方などの設計は,任意である。
以下,図8〜図12を用いて,本実施の形態による紐付け順序更新のより具体的な実施例を説明する。
図8は,一連の処理においてストリームデータが発生する例を示す図である。
ここでは,図8に示すような,クライアント装置37,Webサーバ31,APサーバ32,DBサーバ33の装置間で送受信される一連のストリームデータの紐付けを例として説明する。なお,図8において,ストリームデータのデータタイプ表記中のReqはリクエスト(Request )を示し,Resはレスポンス(Response)を示す。
図8に示す一連の処理において,クライアント装置37は,ストリームデータHTTP−Req(s)を,Webサーバ31に送信する。Webサーバ31は,受信したストリームデータHTTP−Req(s)に応じたストリームデータIIOP−Req(s,t,u)を,APサーバ32に送信する。APサーバ32は,受信したストリームデータIIOP−Req(s,t,u)に応じたストリームデータDB−Req(t)を,DBサーバ33に送信する。DBサーバ33は,受信したストリームデータDB−Req(t)に応じたストリームデータDB−Res(u)を,APサーバ32に送信する。APサーバ32は,受信したストリームデータDB−Res(u)に応じたストリームデータIIOP−Res(u,v)を,Webサーバ31に送信する。Webサーバ31は,受信したストリームデータIIOP−Res(u,v)に応じたストリームデータHTTP−Res(v)を,クライアント装置37に送信する。
図9は,紐付けルールの例を示す図である。
図9では,図8に示す一連の処理で発生するストリームデータの紐付けルールが,テーブル形式で表現されている。図9に示すテーブル形式の紐付けルールを,上記の別の形式で表現すると,
{0,HTTP−Req,s}−{1,IIOP−Req,s,t,u}
−{2,DB−Req,t}−{3,DB−Res,u}
−{4,IIOP−Res,u,v}−{5,HTTP−Res,v}
となる。
図9に示す紐付けルールに基づいた初期の紐付け順序は,ストリームデータの発生順番に従って,
{0,HTTP−Req,s}→{1,IIOP−Req,s,t,u}
→{2,DB−Req,t}→{3,DB−Res,u}
→{4,IIOP−Res,u,v}→{5,HTTP−Res,v}
であるものとする。
図10は,データ配置ルールの例を示す図である。
図10に示すデータ配置ルールは,図8に示す一連の処理において発生するストリームデータを各紐付けサーバ1に分散配置するための配置ルールを示す。
図10に示すデータ配置ルールにより,ストリームデータHTTP−Req(s)と,ストリームデータIIOP−Req(s,t,u)は,データsの値をキーとして,配置先の紐付けサーバ1が決定される。DB−Req(t)は,データtの値をキーとして,配置先の紐付けサーバ1が決定される。ストリームデータDB−Res(u),ストリームデータIIOP−Res(u,v)は,データuの値をキーとして,配置先の紐付けサーバ1が決定される。ストリームデータHTTP−Res(v)は,データvの値をキーとして,配置先の紐付けサーバ1が決定される。
このような環境において,図8に示す一連の処理で発生したストリームデータの紐付けが行われるものとする。
ここで,一連の処理で発生したストリームデータの紐付け処理において,ある紐付けサーバ1が,ストリームデータHTTP−Req(s)にストリームデータIIOP−Req(s,t,u)を紐付けした時点で,次の紐付け対象となるストリームデータDB−Req(t)が配置された紐付けサーバ1の負荷が,所定の閾値を超えたものとする。
図11,図12は,紐付け順序の更新の例を説明する図である。
図11,図12に示す紐付け順序において,丸は,それぞれストリームデータ定義情報を示す。矢印は,紐付けする順序を示す。実線は,ストリームデータがすでに紐付け済みであることを示す。破線は,紐付けの順番が決まったストリームデータ定義情報を示す。点線は,まだ紐付けの順番が決まっていないストリームデータ定義情報を示す。
ストリームデータHTTP−Req(s)にストリームデータIIOP−Req(s,t,u)を紐付けた紐付けサーバ1において,紐付け順序更新部14は,以下に説明する手順により,紐付け順序の変更を行う。
図11(A)は,紐付け順序変更前の紐付け順序であり,上記に示す最初の紐付け順序である。紐付けルールにおける発生順番に従って,ストリームデータが発生する順番に,ストリームデータ定義情報が並んでいる。
ここで,次の探索対象であるストリームデータDB−Req(t)が配置された紐付けサーバ1の負荷が10であったものとする。なお,図11,図12の例では,負荷を単位のない評価値で表現している。例えば,所定の閾値が8であったとすると,紐付けサーバ1は,次の探索対象であるストリームデータDB−Req(t)が配置された紐付けサーバ1の負荷が閾値を超えているため,紐付け順序の変更を判断する。
この時点では,すでにストリームデータが紐付け済みの,ストリームデータ定義情報HTTP−Req(s),IIOP−Req(s,t,u)の順番が,それぞれ1番目,2番目で決定されている。すなわち,紐付け順序の変更は,3番目以降のストリームデータ定義情報について行う。
図11(B)に示すように,紐付け順序更新部14は,まず,順番が決まっている最後のストリームデータ定義情報IIOP−Req(s,t,u)の次に探索可能なストリームデータの定義情報を抽出する。
ストリームデータHTTP−Req(s)とストリームデータIIOP−Req(s,t,u)とはすでに紐付け済みであるので,データs,t,uの値は,既知となっている。よって,図10に示すデータ配置ルールから,データtをキーとするストリームデータDB−Req(t)と,データuをキーとするストリームデータDB−Res(u),IIOP−Res(u,v)とは,この時点で配置先の紐付けサーバ1の特定が可能なストリームデータである。なお,ストリームデータHTTP−Res(v)は,この時点でキーであるデータvが不明であるため,配置先の紐付けサーバ1の特定が不可能なストリームデータである。
紐付け順序更新部14は,ストリームデータ定義情報DB−Req(t),DB−Res(u),IIOP−Res(u,v)を,次に探索可能なストリームデータの定義情報として抽出する。
紐付け順序更新部14は,既知のデータt,uの値を用いて,ストリームデータDB−Req(t),DB−Res(u),IIOP−Res(u,v)の配置先の紐付けサーバ1を特定する。紐付け順序更新部14は,負荷情報記憶部114から,特定された紐付けサーバ1の負荷の情報を取得する。ここでは,データtをキーとするストリームデータDB−Req(t)の配置先紐付けサーバ1の負荷として10が,データuをキーとするストリームデータDB−Res(u),IIOP−Res(u,v)の配置先紐付けサーバ1の負荷として3が,取得されたものとする。
紐付け順序更新部14は,抽出されたストリームデータ定義情報DB−Req(t),DB−Res(u),IIOP−Res(u,v)に,それぞれ対応する紐付けサーバ1の負荷を割り当てる。ここでは,ストリームデータ定義情報DB−Req(t)に負荷10が,ストリームデータ定義情報DB−Res(u),IIOP−Res(u,v)に負荷3が割り当てられる。
紐付け順序更新部14は,抽出されたストリームデータ定義情報DB−Req(t),DB−Res(u),IIOP−Res(u,v)と,順番が決まっている最後のストリームデータ定義情報IIOP−Req(s,t,u)との距離を求める。
ここでは,ストリームデータ定義情報間の距離は,図9に示す紐付けルールにおけるストリームデータの発生順番の差である。すなわち,紐付け順序更新部14は,ストリームデータ定義情報IIOP−Req(s,t,u)の発生順番1と,ストリームデータ定義情報DB−Req(t),DB−Res(u),IIOP−Res(u,v)のそれぞれの発生順番2,3,4との差を算出する。図11(B)に示すように,ストリームデータ定義情報DB−Req(t),DB−Res(u),IIOP−Res(u,v)の距離は,それぞれ1,2,3となる。
紐付け順序更新部14は,抽出されたストリームデータ定義情報DB−Req(t),DB−Res(u),IIOP−Res(u,v)のコストを算出する。
ここでは,抽出されたストリームデータ定義情報のコストは,負荷×距離で算出されるものとする。図11(B)に示すように,ストリームデータ定義情報DB−Req(t),DB−Res(u),IIOP−Res(u,v)のコストは,それぞれ10,6,9となる。
紐付け順序更新部14は,最もコストが低いストリームデータ定義情報を,次の順番のストリームデータ定義情報として決定する。すなわち,図11(B)において,最もコストが低いストリームデータ定義情報DB−Res(u)が,紐付け順序において3番目のストリームデータ定義情報となる。
次に,紐付け順序更新部14は,4番目のストリームデータ定義情報の決定を行う。
図11(C)に示すように,紐付け順序更新部14は,まず,順番が決まっている最後のストリームデータ定義情報DB−Res(u)の次に探索可能なストリームデータの定義情報を抽出する。データs,t,uの値が既知であるので,紐付け順序更新部14は,図11(B)の場合と同様の手順で,ストリームデータ定義情報DB−Req(t),IIOP−Res(u,v)を,次に探索可能なストリームデータの定義情報として抽出する。なお,ストリームデータHTTP−Res(v)は,この時点でもキーであるデータvが不明であるため,配置先の紐付けサーバ1の特定が不可能なストリームデータである。
また,紐付け順序更新部14は,図11(B)の場合と同様の手順で,ストリームデータ定義情報DB−Req(t)に負荷10を,ストリームデータ定義情報IIOP−Res(u,v)に負荷3を割り当てる。
紐付け順序更新部14は,図11(B)の場合と同様の手順で抽出されたストリームデータ定義情報DB−Req(t),IIOP−Res(u,v)と,順番が決まっている最後のストリームデータ定義情報DB−Res(u)との距離を求める。図11(C)に示すように,ストリームデータ定義情報DB−Req(t)の距離は,1となる。
ストリームデータ定義情報IOP−Res(u,v)の距離は,図11(B)の場合と同様の手順で求めると,1となる。ただし,ストリームデータIIOP−Res(u,v)は,図10に示すデータ配置ルールに基づいて,ストリームデータDB−Res(u)と同じデータuをキーとして,紐付けサーバ1に配置される。すなわち,互いに関係するストリームデータIIOP−Res(u,v)とストリームデータDB−Res(u)とは,同じ紐付けサーバ1に配置される。紐付け順序更新部14は,同じ紐付けサーバ1に配置されるストリームデータ間の距離を0とする。ここでは,図11(C)に示すように,ストリームデータ定義情報IIOP−Res(u,v)の距離が,0となる。
紐付け順序更新部14は,図11(B)の場合と同様の手順で,抽出されたストリームデータ定義情報DB−Req(t),IIOP−Res(u,v)のコストを算出する。図11(C)に示すように,ストリームデータ定義情報DB−Req(t),IIOP−Res(u,v)のコストは,それぞれ10,0となる。
紐付け順序更新部14は,最もコストが低いストリームデータ定義情報を,次の順番のストリームデータ定義情報として決定する。すなわち,図11(C)において,最もコストが低いストリームデータ定義情報IIOP−Res(u,v)が,紐付け順序において4番目のストリームデータ定義情報となる。
次に,紐付け順序更新部14は,5番目のストリームデータ定義情報の決定を行う。
図12(A)に示すように,紐付け順序更新部14は,まず,順番が決まっている最後のストリームデータ定義情報IIOP−Res(u,v)の次に探索可能なストリームデータの定義情報を抽出する。データs,t,uの値は,既知である。データvの値は,ストリームデータHTTP−Req(s),IIOP−Req(s,t,u)が紐付けられた時点では既知ではない。しかし,ストリームデータIIOP−Res(u,v)が紐付けられた後では,データvの値は,既知となっているはずである。すなわち,紐付け順序更新部14は,図12(C)に示すように,ストリームデータ定義情報DB−Req(t),HTTP−Res(v)を,次に探索可能なストリームデータの定義情報として抽出する。
紐付け順序更新部14は,図11(B)の場合と同様の手順で,ストリームデータ定義情報DB−Req(t)に負荷10を割り当てる。
しかし,ストリームデータIIOP−Res(u,v)が特定されなければデータvの値がわからないので,紐付け順序更新部14は,この時点では,ストリームデータHTTP−Res(v)が配置される紐付けサーバ1を特定することができない。このような場合には,紐付け順序更新部14は,配置される紐付けサーバ1が特定できないストリームデータ定義情報の負荷を,例えば全紐付けサーバ1の負荷の平均値やあらかじめ定められたデフォルト値などの,所定の値とする。ここでは,紐付け順序更新部14は,紐付けサーバ1が特定できないストリームデータ定義情報の負荷を全紐付けサーバ1の負荷の平均値とし,その値が1であるものとする。紐付け順序更新部14は,ストリームデータ定義情報HTTP−Res(v)の負荷を,1とする。
紐付け順序更新部14は,図11(B)の場合と同様の手順で,抽出されたストリームデータ定義情報DB−Req(t),HTTP−Res(v)と,順番が決まっている最後のストリームデータ定義情報IIOP−Res(u,v)との距離を求める。ただし,ストリームデータ定義情報DB−Req(t)の発生順番は,順番が決まっている最後のストリームデータ定義情報IIOP−Res(u,v)の発生順番より早いので,ストリームデータ定義情報DB−Req(t)の距離は1となる。すなわち,図12(A)に示すように,ストリームデータ定義情報DB−Req(t),HTTP−Res(v)の距離は,それぞれ1,1となる。
紐付け順序更新部14は,図11(B)の場合と同様の手順で,抽出されたストリームデータ定義情報DB−Req(t),HTTP−Res(v)のコストを算出する。図12(A)に示すように,ストリームデータ定義情報DB−Req(t),HTTP−Res(v)のコストは,それぞれ10,1となる。
紐付け順序更新部14は,最もコストが低いストリームデータ定義情報を,次の順番のストリームデータ定義情報として決定する。すなわち,図11(A)において,最もコストが低いストリームデータ定義情報HTTP−Res(v)が,紐付け順序において5番目のストリームデータ定義情報となる。
次に,紐付け順序更新部14は,6番目のストリームデータ定義情報の決定を行う。
図12(B)に示すように,この時点で残っているのは,ストリームデータ定義情報DB−Req(t)だけである。すなわち,紐付け順序更新部14は,最後に残ったストリームデータ定義情報DB−Req(t)を,紐付け順序において6番目のストリームデータ定義情報とする。
変更後の紐付け順序は,図12(C)に示す通りに,すなわち,
{0,HTTP−Req,s}→{1,IIOP−Req,s,t,u}
→{3,DB−Res,u}→{4,IIOP−Res,u,v}
→{5,HTTP−Res,v}→{2,DB−Req,t}
となる。
このように,本実施の形態では,紐付け順序更新部14は,各紐付けサーバ1の負荷状況に応じて,負荷が低い紐付けサーバ1に配置されたストリームデータが優先的に早い順番で紐付けされるようなロジックで,紐付け順序を決定する。これにより,負荷が低い紐付けサーバ1に配置されたストリームデータから優先的に早い順で紐付けを行うことが可能となり,紐付け処理のレイテンシが向上する。紐付け処理のレイテンシは,一連の処理において発生するストリームデータの紐付け開始から完了までの時間を示す。負荷が高い紐付けサーバ1に配置されたストリームデータの紐付けを後回しにし,負荷が低い紐付けサーバ1に配置されたストリームデータの紐付けを行っている間に,負荷が高い紐付けサーバ1の負荷も落ちる。
また,本実施の形態では,紐付け順序更新部14は,発生順序が早いストリームデータのが優先的に早い順番で紐付けされるようなロジックで,紐付け順序を決定する。発生順序が早いストリームデータは,発生順序が遅いストリームデータよりも早く,配置先の紐付けサーバ1に入力され,データ保管部110に記憶される。これにより,ストリームデータよりも先に,そのストリームデータを紐付けるための検索子が紐付けサーバ1に到着する可能性が低くなる。
また,本実施の形態では,紐付け順序更新部14は,同じ紐付けサーバ1に配置されたストリームデータが優先的に連続した順番に紐付けされるようなロジックで,紐付け順序を決定する。これにより,紐付けサーバ1間での検索子の転送回数が減るため,紐付けサーバ1間を接続するネットワークの負荷が減る。
また,紐付けルールで定義されたすべてのストリームデータの紐付けが完成しないような場合もある。
例えば,図8に示す一連の処理において,Webサーバ31からストリームデータIIOP−Req(s,t,u)が発行された後に,APサーバ32で障害が発生し,ストリームデータDB−Req(t)以降のストリームデータが発行されなかったものとする。この場合には,ストリームデータDB−Req(t)を検索する検索子が,ストリームデータDB−Req(t)が配置された紐付けサーバ1に格納された状態で,その一連の処理のストリームデータの紐付けが,完成せずに終わってしまう。
このような紐付けが完成しない検索子が紐付けサーバ1の検索子格納部111に蓄積されると,紐付け部12によるマッチング処理が無駄に増えてしまい,紐付けサーバ1の負荷が高くなる。紐付け順序を変更することにより,このような完成しない検索子を,負荷が高い紐付けサーバ1に送らないようにすることが可能となり,よりバランスの取れた負荷分散を実現することができる。
以上説明した紐付けサーバ1のストリームデータ紐付け部10による処理は,コンピュータとソフトウェアプログラムとによって実現することができ,そのプログラムをコンピュータ読み取り可能な記録媒体に記録することも,ネットワークを通して提供することも可能である。
以上,本実施の形態について説明したが,本発明はその主旨の範囲において種々の変形が可能であることは当然である。
例えば,本実施の形態では,紐付けサーバ1は,次の紐付け対象となるストリームサーバが配置された紐付けサーバ1が所定の閾値を超えた場合に,紐付け順序の変更を行うようにしている。紐付けサーバ1は,ストリームデータの紐付けが行われ,次の検索子を生成するたびに,紐付け順序の変更を行うようにしてもよい。
検索子を発行するたびに,各紐付けサーバ1の負荷状況に応じて次の紐付け対象となる紐付けサーバ1を決定すれば,分散効果が高くなる。次の紐付け対象となるストリームサーバが配置された紐付けサーバ1が所定の閾値を超えた場合に,紐付け順序の変更を行うようにすれば,紐付け処理の処理量が少なくなるため,紐付けサーバ1の処理負荷が低くなる。