Topologically-Aware Overlay Construction and Server Selectionの翻訳（introductionまで）

Topologically-Aware Overlay Construction and Server Selectionって論文のABSTRACTとINTRODUCTIONを翻訳してみた。
すぐにめんどくさくなってExcite翻訳に頼った。だめじゃん。

物理トポロジを反映させたオーバレイ構築とサーバ選択

ABSTRACT

多くの大規模分散インターネットアプリケーションは近接するノード群の情報からベネフィットを得る事が出来うる性質を持っている。
例えば、もしノード間の接続をIPレベルのトポロジと一致させれば、大規模なオーバーレイネットワークのパフォーマンスを改善出来る。
これに似た別の例としては、レプリケートされたWebコンテンツがサーバ群にある場合、クライアントがトポロジ情報を最も近隣にあるサーバを選ぶのに利用出来る。
そのようなアプリケーションの場合、必ずしも最適解を得なければならないという訳ではない。
これらのアプリケーションや類似したアプリケーションは厳密なトポロジ情報を必要としておらず、インターネットホスト群に於ける近隣ノードの位置のヒントだけで十分なのである。

この論文では、グループ内のノード間ネットワークレイテンシーが近くなるよう、全てのノード群をグループ分けするbinningスキームを紹介する。
我々のbinning戦略はシンプル（最低限の計測インフラストラクチャで済む）、スケーラブル（ネットワーク全体の情報を必要とせず、それぞれのノードは少数の公開されたランドマークノードのみを知っていれば良い）且つ完全に分散されている（分類されようとしているグループに所属するノードに対し通信や協力を必要としない）。

このbinning戦略をオーバーレイネットワークの構築とサーバ選択に適用し、シミュレーションとインターネットに於ける計測のトレースデータを用いてテストした。
計測結果はbinningスキームから得られるトポロジデータの精度が低いにも関わらずアプリケーションのパフォーマンスがはっきりと向上する事を示している。

I. INTRODUCTION

幾つかの進行中のプロジェクトがアプリケーションレベルかオーバーレイネットワークを利用している[1]〜[9]。
これらのアプリケーションではそれぞれの関連しあうエンドホストノードはオーバーレイネットワークをコンストラクトするため、少数のサブセットの別の関連ノード群へ論理的に接続されている（我々はこれを隣のノードのサブセットと呼んでいる）。
オーバーレイネットワークの経路情報はアプリケーションレベルで構成されており、送信元ノードから送信先ノードへのホップ数に基づくIPレベルではない。
しかしながら、現在のアプリケーションではアプリケーションレベルの接続性がIPレベルネットワークのトポロジと一致している事が殆ど保証されない。
これは、非効率なルーティングに通じる。
例えばバークレイにあるノードの隣のノードはヨーロッパにあり、スタンフォードにあるノードへ到達するには途中でヨーロッパのノードを通らなければならないかもしれない。
理想的には、そのような不要な高レイテンシのホップは避ける事によってルーティング性能を改善したい。
したがって、大規模なオーバーレイネットワークを使用することにおける基本的な挑戦は、ルーティング性能を向上させるためにIPレベルのトポロジ情報をオーバレイネットワークのコンストラクションに組み込む事になる。

但し、トポロジ情報の効用はオーバーレイネットワークのコンストラクション以外にも利用可能である。
インターネットの上のコンテンツ配布は、そのような情報が性能を向上させることができた別の例だ。
近年、ウェブはデータ・オブジェクトが単一起源サーバに位置しているアーキテクチャからオブジェクトが複数の、そして、地理的に分散しているサーバでしばしば模写されるものまで移行した。

コンテンツに関するクライアント要求はオリジンサーバよりむしろ間近のレプリカサーバに向け直される。
クライアントとサーバの両方がインターネット上に於ける両者の位置関係を示すことができるなら、「良い」サーバを選択するプロセス(すなわち、レイテンシ的にクライアントの近くにあるものを選択する処理)はかなり改良されうる。
同様に、ナップスターやグヌーテラなどのピアツーピアのファイル共有アプリケーションには、複数のピアで利用可能な同じファイルが通常ある。
トポロジ情報は近いピアを選択しより速いダウンロードを実現するのに利用出来うる。
我々が本論文で探る問題は実用的でスケーラブルである方法が存在するか、存在するとすれば、どうしたらオーバーレイネットワークやコンテンツ配布システムなどの分散システムのデザインにトポロジ情報を集める機構を組み入れる事が出来るか、という事だ。
ここに、簡潔に上の問題の解決の望ましい特性について議論するのは価値がある。
CDNで使われるような管理者により構築されたオーバーレイネットワーク[10]〜[12]ならば、IPトポロジに合わせて構築する事も可能だ。
しかしながら、一般に、そのようなオーバレイは適切ではない。
手作りで集中管理されたオーバーレイネットワークの構成方法では、大きいオーバレイ(何百万ものノード)とピアツーピアのファイル共有[1],[2],[13]などのオーバレイに利用出来ない(そこには、一人の管理者もいない)。
また、ただ一つのサイトがネットワーク形態とルーティング情報を集める集結されたソリューション[14]がホストの相対的な近接を推論すると想像するかもしれない。
しかしながら、そのようなソリューションは単一障害点と潜在的ボトルネックをもたらす。
また、ピアツーピアのファイル共有などの完全に分散しているアプリケーションのために、第三者がそのようなサービスを提供するどんな明確な経済の、または、そうでない誘因もない。
また、私たちはオーバレイネットワーク構造が時間がたつにつれてゆっくり改良されるソリューションも避けたい[15]。
それは、我々がターゲットにしている多くのアプリケーション[1],[2],[13]のオーバーレイネットワークではノードが短期間にjoin/leaveする事が分かっているからである。
長期間利用可能なソリューションは、不安定にノードメンバが変わり続ける状態で動かなければならない。
したがって、私たちは、望ましい解決策が簡単で、速く、分散されており、何百万ものノードにスケールするべきであると結論する。

もう一つの問題は、トポロジ情報を引き出すのにどんな方法のネットワーク測定やデータを使用するべきか、という事である。
tracerouteなどのネットワークツールは、ネットワークの診断用途を主として意図しており、ヘビー級であり過ぎ大規模アプリケーションでは邪魔である。
大規模アプリケーションでtracerouteを使えば、過大なネットワークトラフィックが発生するだろう。
さらに、いくつかのエッジのサイトではセキュリティ理由でICMPを無効にしている。
BGPルーティングテーブルの利用[15]も、同様に幾つかの問題がある。
まず、そのような情報は直接エンドユーザアプリケーションに利用可能ではない。
1つは、その結果、ISPから内部のネットワーク情報への特権的アクセスを必要とするか、またはそのような特権的アクセスを持って、コミュニティに対するサービスのようなウェブ情報を発表する第三者モニターサービスによるだろう。
上記のどちらも一般に、正当な選択ではない。
我々はその結果ネットワークレイテンシを使う事を選択した。
なぜなら、レイテンシはダイレクトに性能に繋がる事が多く、簡単に測定出来き、ライトウェイトであり、エンドツーエンドで利用可能であるからだ。

最終的に、どの程度トポロジ情報の精度が必要とされてくるのかという疑問が出てくるかもしれない。
私たちの狙っている２つのアプリケーション(オーバレイ構築とサーバー選択)では、トポロジ認識を組み込むのはパフォーマンスの最適化であり、正しい操作に必要ではない。
より重要に、私たちの測定結果は、サーバー選択とオーバレイ構築の両方が大まかなトポロジ情報だけで大きく性能が上がる事を示している。
これらの理由で、私たちはスケーラビリティと実用性を精度より重要な目標であるとみなす。
したがって、多くの研究計画[16], [17], [18]と異なって、私たちの仕事の焦点は高精度なトポロジモデルか汎用測定サービスを構築しない事にある。
そのような前提の元に、我々はシンプルなトポロジヒントでアプリケーションレベルの問題を解く事にフォーカスしている。

この論文では、私たちはネットワークレイテンシに関して特定のbinの中に分類されるノード同士が比較的お互いの近くにあるように自分たちをbinに仕切るdistributed binning schemeを提案する。
我々のスキームではインターネットに広く拡散されたwell known landmarkノード群を必要とする。
アプリケーションノードは、このランドマークノード群への距離、例えばround trip timeを測定して、自力でこれらの測定値に基づき特定のbinを選択する。
我々のbinning schemeはシンプルで、ほんの少しのインフラストラクチャからのサポートしか必要としない。
必要である唯一のインフラストラクチャが、少ない数(8-12 マシンがインターネットの現在のスケールに十分であるはずであるというインターネットトレースデータを使用すると示される私たちの結果)の比較的安定したランドマークノードである。
これらのランドマークノードはほとんど仕事を要求されない - pingメッセージのエコーバックだけを必要とする。
ランドマークは、測定情報を活発に測定値を収集したり、または広めたりしない。
ノードが独自に他のアプリケーションノードと交信せずに、または調整せずに適切なbinを発見するので、binningはスケーラブルである。

次に、どのような方法でこのbinning戦略を実際の分散アプリケーションへ組み込むかについて考える。
私たちはこのbinning戦略を2つのアプリケーションに適用する: オーバレイネットワーク構築とサーバー選択。
シミュレーションとインターネット測定トレースから得られた結果は、私たちのbinning戦略で提供されたかなり不正確なトポロジ情報さえ、オーバーレイネットワークやCDNsなどのシステムの性能をかなり向上させることができるのを示している。
この論文の残りは以下の通りオーガナイズされている: セクションIIは、私たちのbinning schemeを説明して、評価する。セクションIIIとIVでは、私たちは、私たちがそれぞれオーバレイネットワーク構築とサーバー選択にbinning schemeを用いるアプリケーションを説明して、評価する。最終的に、私たちは、セクションVでrelated workについて議論して、セクションVIで結論を下す。