[P2P]DHTのグリッドへの応用を考える

□はじめに
プライベートな事ですが、昨日バイオリンの発表会で演奏をしました。弾いたのはハイドンの有名なストリングカルテット（弦楽四重奏）「ひばり」です。ストリングカルテットとはバイオリン×2人、ビオラ×1人、チェロ×1人の構成で演奏を行うのですが、それぞれのパートが有機的に絡み合うので、お互いの演奏を聴きながら弾かないと、きれいな演奏はできません。今回は初めての挑戦だったのか、7割ぐらいの出来でした。やっぱり本番だと緊張してうまく弾けないですね。またチャレンジしてみたいものです。

プログラムの分散処理もストリングカルテットに近いのかもしれません。プログラムを並列化、小さなタスクに分割し、それぞれのノードに渡し、さらに結果を統合します。ノード間の協調がうまく行かないと、処理が滞ってしまいます。

今回はDHTと使ってグリッド（ここでは分散処理と言う意味）への応用を考えてみます。なおグリッドについては、それほど知識がないので、的をはずした指摘をしている可能性があります。

□ノードＩＤとタスクの関係
実はかなり前にＤＨＴとグリッドの関係は私のBlogで指摘しています。

[P2P]DHTとグリッドは結びつくのか？

今回の話は上記の記事の抽象化及び簡潔化をしたものです。

DHTでは（あるいはKBRでは）ノードにノードＩＤと言われる一意のＩＤが振られています。通常、ノードＩＤを使ってデータの格納や入手を行う事になります。

ここで大切なのはノードＩＤが一意のＩＤであることです。

少し発想を飛ばしてみましょう。パソコンのメモリ空間を考えるとメモリ空間もアドレスと呼ばれる一意のＩＤのようなものがあります。メモリ空間の住所です。すると、メモリ空間とノードＩＤの間に類似性が生じます。つまり、ノードの状態がある程度理想的であれば、メモリ空間をノードＩＤに対応できるのではないかということです。つまり、ＤＨＴをうまく利用できれば複数のノードでプログラミング処理が可能となります。

このアイデアに更に応用を加えましょう。せっかく複数のノードがあるので、うまく並列化をすれば、各ノードに対して小さなタスクに分割して処理を与える事が可能です。プログラミングを並列化するのは、単一ノードの方が単純だと思いますが、もしかすると複数ノードでもできるのかもしれません。

さて、あるノードが落ちた場合はどうでしょうか？単純なＤＨＴを使うとそのノードが処理していたタスクは途中で終了してしまいます。そこで、ＤＨＴでよく使われるレプリカの応用をしましょう。

あるノードＩＤ＝Ｘが管理しているタスクTask_ＺをノードID=X+A(Ａはある整数）となるノードにも実行させます。するとノードＩＤ＝ＸがＤＨＴから抜けてもノードＩＤ＝Ｘ＋Ａは処理を終了できます。あるいはノードＩＤ＝ＸかノードＩＤ＝Ｘ＋Ａのどちらかで処理回答が早いノードの結果を採用するという手もあります。タスクのレプリケーションが増えれば、処理が高速化しますし、ノードの離脱に対する耐性にも強くなるでしょう。ただしそれだけシステムとして見た場合のリソース消費に繋がります。

分散コンピューティングで有名なものとしてSETIがあります。実はDHTをうまく使うと、分散コンピューティングアーキテクチャの構築が今までより容易に実現できる可能性があります。

P2Pでファイル共有、あるいは分散ストレージの開発・実装が現在でもホットな状況ですが、このような分散コンピューティングにも開発の視野を広げると意外と世間（特に政府や企業）から注目されるかもしれません。