JP5818262B2

JP5818262B2 - データ配送システム及びデータ配送装置及び方法

Info

Publication number: JP5818262B2
Application number: JP2012108848A
Authority: JP
Inventors: 后宏水谷; 修明石; 健介福田
Original assignee: Nippon Telegraph and Telephone Corp; Inter University Research Institute Corp Research Organization of Information and Systems
Current assignee: Nippon Telegraph and Telephone Corp; Inter University Research Institute Corp Research Organization of Information and Systems
Priority date: 2012-05-10
Filing date: 2012-05-10
Publication date: 2015-11-18
Anticipated expiration: 2032-05-10
Also published as: JP2013235514A

Description

本発明は、データ配送システム及びデータ配送装置及び方法に係り、特に、複数のメタデータ（行動履歴、RFID(Radio Frequency Identification)、センサ情報）を分散管理するDHT（Distribution Hash Table）を用いた構造化オーバレイネットワーク上にて、メタデータを当該オーバレイに対して、データの配置・取得命令を発行する際の通信量を削減するためのデータ配送システム及びデータ配送装置及び方法に関する。

気象センサ情報や人の行動履歴などの莫大なメタ情報（ビッグデータ）を解析することで、天気の予測精度や人の行動予測の精度の向上を図ることができる。図１に示すように、ビッグデータは、おおよそ１秒当り数万から数十万のメタ情報が流通されると予想され、現在１秒あたり数万のメタ情報を分散環境上にて統計処理することができるようになった（例えば、非特許文献１、２参照）。この膨大なメタデータを効率よく分散管理するために、DHTを用いた構造化オーバレイ（以下、「DHT」と記す）という手法が利用されるようになった。DHTは複数のノード（PC）で構造化され、各ノードは自身の識別子（IP address、MAC address）のハッシュ値をIDとして保持する。DHTにおける各ノードは、自身のIDと最も距離が近いノードと隣接関係を持つことで、ID空間を分散管理している。

図２にDHTの概要を示す。図２では、６つのノードによってID空間（IDの範囲0〜999）を管理している。ID:327のノードは自身のID:327から時計回り方向に隣接するノード（ID:515）までのIDを管理する。このDHTに対して、ユーザはPUTとGETの命令を発行することができ、データを保存したり、保存したデータを取得することが可能となっている。例として、図３、図４にDHTに対してデータを保存する手順を示す。ノード(ID:327)がハッシュ値:710のデータをDHTに上に保存するとき、隣接ノードに対してPUTメッセージを発行し、当該ハッシュ値を管理しているノードを探してもらう（ルーティング）。ルーティングを繰り返し、ノード（ID:702）にPUTメッセージが到着すると、当該ノードはPUTメッセージの発行元に対して、自身のアドレスを発行する。ノード(ID:702)のIPアドレスを知ったノード（ID:327）は、ノード(ID:702)に対して、データを転送する。これらのルーティング動作を通して、データをDHT上に保存することができ、同様の手順を、DHT上からデータを取得する方法にも適用することができる。

DHT上で大量のPUT・GET命令を抑制するためには、PUT・GET命令の最終宛先(Destination)のノードまでのルーティングコスト（経路長・ホップ数）を短くする方法（以下、「方法A」と記す）や、似たようなPUT・GET命令を束ねる方法（以下「方法B」と記す）がある。方法Aでは、各ノードに隣接関係を持たせるだけでなく、DHT上の様々なノードに対してショートカットリンクを保持する必要がある。方法Aに関する研究は既に収束しており、DHT空間上で目的のノードに対して、log(n)(nはDHT上のノード数)ホップで到達する手法が発見されている（例えば、非特許文献３、４、５参照）。方法Bでは、ルーティング中に宛先が同じノードに対するPUT・GET命令を束ねる方法がいくつか提案されている。

PUT・GET命令を効率的に束ねるために、方法Aに対して柔軟に実装でき、かつ、PUT・GET命令を束ねる際の待ち時間や計算時間を低減する方法が要求されている。

XCASTと呼ばれるマルチキャストプロトコルは、ルーティング先が同じデータ群をまとめて転送する機能を持っている（例えば、非特許文献６参照）。

また、DHT上の各ノードに対して発行されるPUT・GET命令をバンドルという単位で束ねて転送するCollective Routingという手法がある（例えば、非特許文献７参照）。当該手法では、各ノードにPUT・GET命令をプールしておくキューを作成する。キューの先頭のPUT・GET命令を取り出し、当該命令のDestinationをバンドルという空のリストに入れる。次からは、当該バンドルの中のPUT・GET命令のDestinationの平均距離が最短となるようなDestinationを持つPUT・GET命令を、キューの中から探し、バンドルサイズBが満たされるまで、バンドルに追加する。現在、バンドルの中にある各PUT・GET命令のDestinationをp₁，p₂，…，p_i∈Ｐと定義する。このとき、各Destinationの距離を排他的論理和(xor)で表現するKademliaと呼ばれるルーティングアルゴリズムにて、次にバンドルに追加するDestinationがｑのPUT・GET命令は以下の条件を満たす必要がある（例えば、非特許文献４参照）。

上記の式はキューの中の命令群Q個の命令の中から、上記の式を満たす１命令をバンドルに移すことを意味する。すなわち、１つのバンドルを形成するためには、ｂ個の命令をバンドルの中に移す必要があるため、その計算回数はbQとなる。さらに、キューの中にある全ての命令をバンドル化し、送信するためには、バンドルを形成する作業をQ/b回行わなければならないので、Q²の計算回数が必要になる。このように、バンドル化するための計算時間は長すぎるため、PUT・GET命令の発行元しかハンドル化を行わないようする。バンドル化したPUT・GET命令群は、バンドルの一番最初のPUT・GET命令のルーティングに従って転送される。なお、ルーティングの途中にて、バンドル内のPUT・GET命令の転送先が異なる場合が出てくる。このとき、バンドル内のPUT・GET命令群を分割し、転送先が同じものを再度バンドル化し、ルーティングを行う。

Collective Routingの具体的な動作を図５に示す。ノード(ID:327)が自身のキューからバンドルを作成するとき、キューの中にあるPUT・GET命令のDestinationの距離の差が最小になるような命令群をバンドルサイズ分だけ抽出する（バンドルサイズは３とする）。このバンドルを転送するとき、バンドルの先頭にあるPUT・GET命令のDestinationをバンドルDestinationとして、ルーティングを行う。その結果、当該バンドルがノード（ID:600）に達したとする。このとき、当該ノードはバンドルの中のDestinationを全て調べた結果、各命令の転送先が異なると判断したため、これらの命令群を個々に分割し、Destinationが710の命令はノード（ID:702）へ、Destinationが997の命令はノード（ID:910）へ、Destinationが126の命令はノード（ID:123）へ転送する。

URL: http://hadoop.apache.org/ URL: http://jubat.us/ I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger, M. F. Kaashoek, and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Protocol for Internet Applications," in Proc. Annual conference of the Special Interest Group on Data Communication 2001, pp. 149-160 (2001). P. Maymounkov and D。 Mazieres, "Kademlia: A Peer-to-peer Information System Based on the XOR Metric," Lecture Notes in Computer Science, 2002, Volume 2429/2002, 53-65, DOI: 10.1007/3-540-45748-8_5. A. Rowstron and P. Druschel, "Pastry: Scalable, Decentralized Object Location and Routing for Large-scale Peer-to-peer Systems," Lecture Notes in Computer Science, 2001, Volume 2218/2001, 329-350, DOI: 10.1007/3-540-45518-3_18. R. Boivie, N. Feldman, Y. Imai, W. Livens, and D. Ooms, "Explicit Multicast (Xcast) Concepts and Options," RFC 5058, IETF (2007). 首藤一幸,"構造化オーバレイでの一括フォワーディング, " 情報処理学会論文誌, コンピューティングシステム2(3), 39-46, 2009-09-18.

しかしながら、非特許文献１、２の手法では、ビッグデータをDHT上で管理する際、PUT・GET命令が大量に発行されることにより、各ノードに対して大きな負荷がかかる他、ネットワークトラヒックを増大させてしまう危険性がある。

また、非特許文献３、４の手法の、PUT・GET命令の最終宛先(Destination)のノードまでのルーティングコスト（経路長・ホップ数）を短くする方法（方法A）では、ルーティング中に同一の宛先を持つ命令をどれだけ束ねるか、また、同一宛先を持つ命令をどれだけ待つか、宛先は同一ではないが宛先が近いと思われる命令をどういったポリシで束ねるか、などの設定が必要になってくる。似たようなPUT・GET命令を束ねる方法（方法B）では、ルーティング中に同一の宛先を持つ命令をどれだけ束ねるか、また、同一宛先を持つ命令をどれだけ待つか、宛先は同一ではないが宛先が近いと思われる命令をどういったポリシで束ねるか、などの設定が必要になってくる。

また、非特許文献６のXCASTはマルチキャストが目的であり、PUT・GET命令がユニキャストで大量に転送される環境下では、利用することができない。また、XCASTはIPプロトコル層に実装されているため、DHTのようなアプリケーション層のルーティングを管理することはできない。

また、非特許文献７のCollective Routingはバンドルサイズの設定方法が難しいことと、バンドル化する際の計算量が多いという問題点を抱えている。ビッグデータのような膨大なデータを効率よく処理するためには、バンドルサイズを大きくしなければならない。しかし、バンドルサイズを大きくすると、バンドルがルーティング中に分割されやすくなる他、バンドル化する際の計算コストがバンドルサイズの２乗で増えてしまう。また、バンドルサイズが到着するPUT・GET命令群に対して十分に大きく設定したとき、バンドルが埋まるまで遅延が発生する。

本発明は、上記の点に鑑みなされたもので、メッセージ数の増大を防ぐのみならず、核ノードにおけるPUT・GET命令の処理を簡素化可能なデータ配送システム及びデータ配送装置及び方法を提供することを目的とする。

上記の課題を解決するため、本発明は、複数のメタデータを分散管理するDHTを用いた構造化オーバレイネットワーク上において、メタデータに対するデータの配置・取得命令（PUT・GET命令）を発行するデータ配送システムであって、
第１のノードと第２のノードを有し、
前記第１のノードは、
前記メタデータに対するPUT・GET命令を蓄積する記憶手段と、
前記記憶手段から前記メタデータに対するPUT・GET命令を取り出して、当該構造化オーバレイネットワークに実装されている配送アルゴリズムに従って、該PUT・GET命令を処理する第２のノードを探索し、配送する命令配送手段と、
前記第２のノードから当該第２のノードが管理しているハッシュ空間の範囲を通知されると、該範囲に該当するPUT・GET命令を集約する集約手段と、
前記集約手段により集約されたPUT・GET命令を前記第２のノードに送出する命令送出手段と、を有し、
前記第２のノードは、
前記第１のノードから前記PUT・GET命令を取得すると、自身が管理しているハッシュ空間の範囲を該第１のノードに通知する範囲通知手段を有する。

上記のように、本発明によれば、膨大なビッグデータを保存・取得する際のPUT・GET命令を抑制するため、複数のPUT・GET命令を一つのバンドル（Bundle）という束にして管理することにより、メッセージ数の増大を防ぐのみならず、各ノードにおけるPUT・GET命令の処理を簡素化することが可能となる。

従来のビッグデータの流通の例である。 DHTの概要を示す図である。 DHTに対してデータを保存する手順（その１）である。 DHTに対してデータを保存する手順（その２）である。 Collective Routingの具体的な動作を示す図である。本発明の一実施の形態における概要動作のシーケンスチャートである。本発明の一実施の形態における概要を示す図（その１）である。本発明の一実施の形態における概要を示す図（その２）である。本発明の一実施の形態における実装例である。本発明の一実施の形態におけるDHTの動作の例（その１）である。本発明の一実施の形態におけるDHTの動作の例（その２）である。

以下、図面と共に本発明の実施の形態を説明する。

前述の従来技術では、ルーティング中に経路が重なる（可能性が高い）PUT・GET命令を束ねることを目指していたが、本発明では、ルーティング中の経路の重なりを考慮しない。

図６は、本発明の一実施の形態における概要動作のシーケンスチャートである。

本発明では、各ノードがPUT・GET命令を格納するキューを持っており、キューから順にPUT・GET命令を取り出し（ステップ１）、当該命令のDestinationを目指してルーティングを行う（ステップ２）。当該命令が、Destinationのノードに到達したとき、当該ノードは自身が担当するID空間の管理範囲（Range）を、PUT・GET命令の発行元に対して通知する（ステップ３）。発行元のノードが通知されたRangeを受け取ると、Rangeに該当するPUT・GET命令をキューの中から探し出し、バンドル化する（ステップ４）。そして、当該バンドルをRangeの通知を行ったノードに対して、転送する（ステップ５）。これにより、バンドルサイズを決めなくてもよく、ルーティング途中で分割することなく、PUT・GET命令を纏めて転送することができる。

図７、８は、本発明の一実施の形態における概要を示す図である。

ノード（ID:327）がPUT・GET命令を格納するキューを持っている。この時、キューの先頭にあるDestinationが"710"のPUT・GET命令を取り出し、Destinationの解決を待つためのバッファに格納後、ルーティングを行う。ルーティングの結果、当該命令は、ノード（ID:600）に到着し、当該ノードのキューに格納される。その後、ノード（ID:600）がキューの先頭からDestinationが"10"のPUT・GET命令を取り出し、Destinationの解決を待つためのバッファに格納後、ルーティングを行う。その後、当該命令がノード（ID:910）に到達し、当該ノードはDestinationが"10"のPUT・GET命令が、自身に対する命令であると認識し、当該命令の発行元であるノード（ID:600）に対して、自身のRange（910-999，0-122）を伝達する。Rangeを伝達されたノード（ID:600）は、キューから伝達されたRangeの範囲にある命令群を取り出す。この時、自身が発行した命令をバンドル化し、自身が発行した命令でなければ、当該命令の発行元に対して、Rangeを転送し、同様の手順でノード（ID:327）はキューからDestinationがRangeの範囲内にある命令群のバンドル化を行う（再帰的に行う）。なお、Rangeを発行したノード（ID:910）がDHT上から何らかの原因によって離脱することが考えられるため、Rangeの発行元ノード（ID:910）からk回しか転送しないことにする。もし、ノード（ID:327）がバンドル化を終了し、Rangeの発行元ノード（ID:910）に対してバンドルを転送した際に、当該発行元ノードが離脱している可能性があるため、当該発行元ノードからの返答時間のタイムアウトを設定し、タイムアウト内にAckメッセージを受け取れるか否かで、再送を判断することにする。

上記の機能を実現するために、本発明では既存のDHTの設計概念であるKBR（Key Based Routing）への実装方法を考える（例えば、文献１：F. Dabek, B. Zhao, P. Druschel, J. Kubiatowicz, and I. Stoica, "Towards a Common API for Structured Peer-to-Peer Overlays," Lecture Notes in Computer Science, 2003, Volume 2735/2003, 33-44, DOI: 10.1007/978-3-540-45172-3_3.参照）。

図８に実装方法を記述する。本発明のシステムを実現するモジュールはバンドルマネージャ（Bundle Manager）１０となっており、それ以外はKBRの実装概念に従ったモジュールとなっている。アプリケーションモジュール３０はDHT２０を利用するアプリケーションであり、ビッグデータの解析アプリケーションやファイル共有アプリケーションがこのモジュールに相当する。DHTモジュール２０は、アプリケーション３０に対してputとgetのインタフェースを提供し、アプリケーションに対してDHTモジュール２０を利用するための機能を提供している。ルーティングアルゴリズムモジュール１０では、DHTモジュール２０上で経路長を最短に抑えるための転送方法が実装されており、route関数に対して、DHTモジュール２０はvalueのハッシュ値であるkeyや、検索したいキーワードのkeyを入れることで、DHTモジュール２０上でDestinationに対応するノードまでのルーティングを行う。TCP/UDP コミュニケーションモジュール４０では、TCP(Transmission Control Protocol)やUDP(User Diagram Protocol)を使って、ル−ティングアルゴリズムモジュール１０からセットされたデータ、及び転送先に対して転送を行うモジュールとなっている。

本発明のバンドルマネージャ１１は、ルーティングアルゴリズムモジュール１０に実装され、以下の機能を提供することによって、効率的なメッセージ削減を達成するデータの配送方法の実現が可能になる。

・addQueue（key，message，IP address）：PUT・GET命令を格納するキューに対して、PUT・GET命令を格納する関数。キューの中のPUT・GET命令（message）は、当該命令のkey（Destination）と当該命令の発行元のIP addressを1つのオブジェクトとして扱われる。

・boolean isIncluded（key）：転送されてきたPUT・GET命令のkey（Destination）が自身が担当するID空間内にあるか否かを判定する関数。

・void bundle（Range，IP address）：転送されてきたRangeに該当するPUT・GET命令をキューの中から探し出し、バンドル化し、引数のIP addressに対して転送する関数。キューの中のPUT・GET命令のヘッダのIP addressが自身のIP addressであれば、バンドル化し、引数のIP addressに対して転送。自身のIP addressでなければ（他のノードから転送されてきたPUT・GET命令の時）、当該命令のHeaderのIP addressに対して、Rangeを転送する。

これらの機能を用いて、本発明を用いたDHTの詳細な動作例を図１０と図１１に示す。

以下の括弧内の番号と図１０、図１１中の番号は対応している。

（1）ノード（ID:327）がPUT・GET命令を発行し、ルーティングアルゴリズムモジュール１０のroute関数を使って、当該命令をDHT２０上に展開する。route関数の引数のkeyはPUT・GET命令のDestinationを示し、messageはPUTかGETを示し、Headerは自身のIP address（IP:a）を示す。route関数を実行後、バンドルマネージャ１１のaddQueue関数を呼び出し、route関数の引数を入力すると、これらの引数を一つのオブジェクトとしてキューに追加する。

（2）キューの中のPUT・GET命令群がルーティングアルゴリズムモジュール１０を用いて転送されていく。なお、当該命令は、Destinationの解決が終わるまで、バッファに格納される。後に、Destinationが"710"となっているPUT・GET命令がノード（ID:600）に転送されたとする。当該命令はノード（ID:600）のisIncluded関数によって、当該命令のDestinationがノード（ID:600）の担当範囲に含まれるかどうかを検査する（isIncluded関数の引数には当該命令のDestinationが入力される）。ここで、当該命令のDestinationが当該ノード（ID:600）の担当範囲ではないので、再度、当該ノードのaddQueue関数を用いてキューに追加される。

（3）ノード（ID:600）のキューが消化されていき、Destinationが"10のPUT・GET命令が、ルーティングアルゴリズムモジュール１０によってノード（ID:910）転送されるとする。

（4）当該命令を受け取ったノード（ID:910）は、当該命令をisInclude関数を用いて、当該命令のDestinationが自身の担当範囲かどうかを判断する。この時、当該ノードは、当該命令のDestinationが担当範囲であると判断し、当該命令の（発行元である）IP address（IP:b）に対して、自身の担当範囲（Range）を伝達する。

（5）、（6） Rangeを受け取ったノード（ID:600）は、Bundle関数の引数に受け取ったRangeとRangeを発行元のIP addressを入力し、自身のキュー及び、バッファから、受けとったRangeに該当するPUT・GET命令を全てバンドル化する。

（7）もし、PUT・GET命令のIP addressが自身のIP addressであれば、バンドル化するが、そうでない場合は、当該命令のIP addressに対して、受け取ったRangeを転送する。この時、ノード（IP:a）を発行元とするPUT・GET命令がキューに存在していたため、当該ノードに対して、Rangeを転送する。

（8）転送されたRangeをノード（IP:a）が受信し、Bundle関数を用いて、キューの中、およびバッファの中からRangeに該当するPUT・GET命令群をバンドル化し、Rangeの担当ノードに対してバンドルを転送する。

しかしながら、これらの手順を繰り返すことで、RangeがDHT２０上に転送され続ける可能性がある。Rangeの無限転送を防ぐために、Rangeの発行元がRangeに対してTTL（Time To Live）を設定、転送回数を制限する方法も考えられる。また、同一のRangeを何度も受信しないために、Rangeに転送履歴などを添付する方法も考えられる。これらの問題を解決することで、膨大なビッグデータの通信回数や通信処理にかかる負荷を軽減できると考えられる。

なお、本発明の、バンドル化する際の計算量は、Range内のDestinationをキューから探すコストに等しいため、キューサイズをQとすると計算回数はQとなり、Collective Routingのバンドル化する際の計算回数Q²よりも小さい。さらに、Collective Routingではバンドルサイズが固定長であったのに対し、本発明はRange内のDestinationを持つ命令群を一括で送ることから、バンドルサイズを決定する必要がなく、大量のデータのPUT・GET命令が発行されたとしても、バンドル化の処理が軽く、一括で当該大量の命令群を転送できる可能性が高い。

なお、上記の実施の形態における、PUT・GET命令の送出元のノード及び当該命令を実行するノードの各処理をプログラムとして構築し、当該ノード装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることも可能である。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。

１０ルーティングアルゴリズムモジュール
１１バンドルマネージャ
２０ DHTモジュール
３０アプリケーションモジュール
４０ TCP/UDPコミュニケーションモジュール

Claims

複数のメタデータを分散管理するDHT（Distribution Hash Table）を用いた構造化オーバレイネットワーク上において、メタデータに対するデータの配置・取得命令（PUT・GET命令）を発行するデータ配送システムであって、
第１のノードと第２のノードを有し、
前記第１のノードは、
前記メタデータに対するPUT・GET命令を蓄積する記憶手段と、
前記記憶手段から前記メタデータに対するPUT・GET命令を取り出して、当該構造化オーバレイネットワークに実装されている配送アルゴリズムに従って、該PUT・GET命令を処理する第２のノードを探索し、配送する命令配送手段と、
前記第２のノードから当該第２のノードが管理しているハッシュ空間の範囲を通知されると、該範囲に該当するPUT・GET命令を集約する集約手段と、
前記集約手段により集約されたPUT・GET命令を前記第２のノードに送出する命令送出手段と、を有し、
前記第２のノードは、
前記第１のノードから前記PUT・GET命令を取得すると、自身が管理しているハッシュ空間の範囲を該第１のノードに通知する範囲通知手段を有する
ことを特徴とするデータ配送システム。
複数のメタデータを分散管理するDHT（Distribution Hash Table）を用いた構造化オーバレイネットワーク上において、メタデータに対するデータの配置・取得命令（PUT・GET命令）を発行するデータ配送装置であって、
前記メタデータに対するPUT・GET命令を蓄積する記憶手段と、
前記記憶手段から前記メタデータに対するPUT・GET命令を取り出して、当該構造化オーバレイネットワークに実装されている配送アルゴリズムに従って、該PUT・GET命令を処理するデータ配送装置を探索し、配送する命令配送手段と、
前記PUT・GET命令を処理するデータ配送装置から当該装置が管理しているハッシュ空間の範囲を通知されると、該範囲に該当するPUT・GET命令を集約する集約手段と、
前記集約手段により集約されたPUT・GET命令を前記PUT・GET命令を処理するデータ配送装置に送出する命令送出手段と、
他のデータ配送装置から自装置が処理するPUT・GET命令を取得すると、自装置が管理しているハッシュ空間の範囲を該他のデータ配送装置に通知する範囲通知手段と、を有する
ことを特徴とするデータ配送装置。
複数のメタデータを分散管理するDHT（Distribution Hash Table）を用いた構造化オーバレイネットワーク上において、メタデータに対するデータの配置・取得命令（PUT・GET命令）を発行するデータ配送方法であって、
第１のノードにおいて、
前記メタデータに対するPUT・GET命令を蓄積する記憶手段からPUT・GET命令を取り出して、当該構造化オーバレイネットワークに実装されている配送アルゴリズムに従って、該PUT・GET命令を処理する第２のノードを探索し、配送し、
前記第２のノードにおいて、
前記第１のノードから前記PUT・GET命令を取得すると、自身が管理しているハッシュ空間の範囲を該第１のノードに通知し、
前記第１のノードにおいて、
前記第２のノードから当該第２のノードが管理しているハッシュ空間の範囲を通知されると、該範囲に該当するPUT・GET命令を集約し、該第２のノードに送出する
ことを特徴とするデータ配送方法。
コンピュータを、
請求項２記載のデータ配送装置の各手段として機能させるためのデータ配送プログラム。