旧・無印吉澤

昔はてなダイアリーに書いていた記事のアーカイブです

P2P技術でバックボーンの負荷を軽減することは可能か？

P2P

P2P の誤解：大容量ファイル交換とボトルネック(1)(2)(3)についての感想の続きです。

(1)と(2)の内容については特に疑問はなかったのですが、(3)については、啓蒙のための記事ということで詳細を省いたのではと思いつつも、やはり説明が不足しているように感じました。P2Pをサーバの負荷軽減に使う技術・アプリについては最近よく見かける一方、この記事のように、P2Pをバックボーンの負荷軽減に使う話は（個人的に）あまり見かけなかったこともあって、余計そう感じたのかもしれませんけど……。

そこでこの記事をネタにして、P2P技術でバックボーンの負荷を軽減することは可能か？というテーマについて少し考えてみました。

      • -

P2P の誤解：大容量ファイル交換とボトルネック(3)の「■P2Pによるトラフィックの分散」後半では以下のように書かれています。

中央集中型の仕組みでは、中央である「東京に取りに行く」という行為があらかじめ指定されてしまっているため、このような取得先の選択の実現が難しいのが現状です。

P2P 型の仕組みでは、各パソコンはバケツリレー的に回りのパソコンにファイルの有無を確認していくため、そもそも近くの端末から先にファイルを見つけてくるという、効率的な仕組みになっているわけです。

WinMX のような現在のファイル交換ソフトは、あまりネットワークの負荷は考えずに、ファイルを持っている対象から直接ファイルを持ってこようとします。ネットワーク的に効率的な取得ルートを選択しないため、現在の「P2P ファイルはネットワーク負荷が高い」というイメージを作り上げる原因になってしまっています。

しかし、実際にはパソコンそれぞれがサーバーのように自己判断できる P2P 型のシステムだからこそ、ネットワークの負荷を考慮したコンテンツ配信の仕組みを実現できるのです。

前回リストアップした「気になった点」は主にこの部分に対するものです。

この文章の結論を早めに言ってしまうと、「P2P技術をバックボーンの負荷軽減に使うためには、各地域ネットワーク内で閉じた何らかのサービスをユーザ（クライアント）側に強制する必要があるのではないか」というのが現在の僕の考えです。前述の記事の最後に述べられているような、

現在類似の仕組みでサーバーデータを拠点分散させているケースも出てきていますが、P2P 技術のように各クライアントレベルでこの分散の仕組みをコントロールすることができれば、現在のネットワーク構成を維持した形で、より効率的なブロードバンドコンテンツ配信の仕組みが実現できるようになる、と考えられています。

とは簡単に言えないんじゃないか、と。

P2P型のシステムによってバックボーンにかかる負荷を軽減するということは、イコール、バックボーンにかかるはずだった負荷を各地域ISPのネットワーク全体に分散させるということでもある。これを実現するためには、各地域ネットワークのクライアントから出されるコンテンツ要求が必要以上にその地域外に出ないように強制するための仕組みが必要になります。

しかし、一方で現在のP2P型のアプリケーションは通信速度の速い相手や、持っているファイルの傾向が類似する相手を「近い」と判断して、そういう相手を優先して繋がりを持とうとします。そりゃそうです。その方が便利なんですから。tracerouteコマンドのような仕組みを使えば複数の相手候補の距離的な近さを比較することは出来ますが、結局クライアントレベルでの判断で距離的な近さを優先させるのは難しいと思います……誰だってファイルはさっさと落としたいでしょう？　WindowsUpdateしている時とか、そう思いませんか？

そこで、クライアントが出来るだけ距離的に近い相手からコンテンツをダウンロードするように仕向けるためには、以下のいずれかの強制的な方法が必要になると考えます。いずれの方法も、各地域毎に適切な最初の接続先（エントリーポイント）を簡単に見つけられるようにして、ネットワーク全体に余計な負荷がかからないようにする点が第1のメリットです。

  • （方法1）各地域ネットワーク内のクライアントに対してコンテンツを代理配信するために、地域毎に十分な処理能力を持つプロクシサーバを用意する
  • （方法2）各地域ネットワーク内のクライアントが提供するコンテンツに関するメタデータの交換を援助するために、各地方に十分な処理能力を持つサーバを用意する
  • （方法3）各地域ネットワーク内のクライアントに関するメタデータの交換を援助するために、各地方に十分な処理能力を持つサーバを用意する

このような方法をまとめて、ここでは仮に「配給モデル」と呼ぶことにします。

方法1はクライアント/サーバ型の配給モデルです。接続先がコンテンツ要求先に直結するため、接続先を探すための通信や、接続先の生存確認のための通信が不要で無駄がないのがメリットです。一方、プロクシサーバでキャッシュすべきコンテンツを適切に選択する必要があり、単純なHTTPプロクシとは比較にならない大容量のストレージ装置が必要で、コンテンツ要求が集中するためにsingle point of failureにもなりやすい、などのデメリットがあります。

方法2はHybrid P2P型の配給モデルです。JXTAの用語を使って、コンテンツに関する告知(advertisement)を交換するためのランデブーピアを用意する方法*1、というと分かりやすいかもしれません。接続先から2ホップでコンテンツ要求先に到達するので接続先を探す（接続先が無いと分かる）のにそれほど時間がかからず、クライアントがコンテンツを代理送信するため、サーバに必要なストレージ装置が方法1ほど膨大にならないのがメリットです。しかしデメリットとして、一般的に中央集中型（サーバ）の方がP2P型（クライアント）よりも多くの接続を収容できるため、その時点で実際に接続可能な相手クライアントを確保するまでのトライアンドエラーが発生する可能性があります。

方法3はPure P2P型の配給モデルです。JXTAの用語を使うと、ピアに関する告知を交換するためのランデブーピアを用意する方法と言えます。サーバに必要なストレージ装置が方法2よりも更に少なくなり、その分だけサーバにかかる負荷も低くなるのでsingle point of failureになりにくいのがメリットです。一方、接続先を探すための通信や、接続先の生存確認のための通信、コンテンツ要求の際のトライアンドエラーが上記2つの方法より大幅に増加するのがデメリットになります。わざわざISPがサーバを用意することのメリットを有効利用出来ないので、この方法は方法2に比べるとあまり適切ではないかもしれません。

方法1はHTTPプロクシのように特定ポイントを介した通信を強制する方法で、ファイアウォールと併用することで違法なP2P通信を遮断するのも容易でしょう。これは記事(3)の「■カスケード配信」の内容とほぼ一致するモデルですが、さすがにユーザは抵抗しそうな気がします……。

で、方法2と方法3は、クライアントからのコンテンツ要求を出来る限り地域内でのP2P通信で解決する手助けをする方法です。この手段を使った上で、やむなく地域外に出るしかなくなったコンテンツ要求を優遇するようなQoSが可能なら、他の違法なP2P通信に帯域制御をかけても、まっとうな通信には帯域制御がかからないような環境を作れるのではないでしょうか。

以上が、前回気になった点として書いたコメントの補足です。うーん、無駄にながながと書いてしまった……。

あと、ここまで書いてみて少し気付いたことがあったので、明日は配給モデルの考え方を使った小話を1つ書いてみます。

*1:JXTA 1.0の頃の知識に基づいて話しているため、若干おかしいかもしれません。暇が出来たらJXTA 2.0の仕様を読んで内容確認しますのでご勘弁を……。