著者の清水周一氏

　オフィスでも学校でも、最近のコンピュータは互いにIP（Internet Protocol）ネットワークで接続されることが大半になってきました。そのコンピュータ・ネットワークを経由してデータを転送・コピーすることは、いまや標準的になりました。コンピュータの処理能力やディスク容量などのリソースが豊かになりました。さらにネットワークの性能も向上するにつれて、転送するデータも、テキスト・ファイルから、e-ラーニングのコンテンツやソフトウエアのアップデータなどへと、そのサイズも大きくなっています。カメラ映像など、リアルタイムのデータを送ることもあります。

　今回は、そのような大量のデータを、コンピュータ・ネットワークを利用して効率的に配信するための技術について解説・紹介します。

1）１対１のダウンロード

　大学や一部のオフィスがインターネットに接続されていった1980年代半ば頃から、ファイルの転送には 「FTP」（File Transfer Protocol）が多く使われていました。これはサーバーとクライアントで構成する、1対1の双方向ファイル転送プロトコルです。FTPサイトを検索するための「ARCHIE」と組合わせて、ソフトウエアのソース・ファイルを探してダウンロードする、といった使い方をしていました。

　ネットワークでは、データは分割されて、さらに送受信のために必要な情報が付け加えられた「パケット」という単位で送られます。IPネットワークは、そのパケットを目的地まで運ぶように動作します。しかし、その到着を保証するものではありません。たとえば、ネットワークの経路上の中継器であるルータで、トラフィックの混雑を回避するために意図的に捨てられたり、あるいは、ネットワークの状態が悪くて転送中にダメージを受けて一部が壊れたりしたものが「パケット・ロス」になります。「ベスト・エフォート型」という（技術的でない）表現がしばしば使われますが、このような確率的に（運が悪ければ）届かない状況を表しています。

　ベスト・エフォート型のIPネットワーク上で信頼性の高いファイル転送を実現するために、FTPでは「TCP」（Transmission Control Protocol）という、エンドからエンドへの配達を保証する、ストリームに基づいたプロトコルを前提にしています。TCP は、ロスしたパケットを再送したり、混雑を避けるためにパケットの流量を調節するなど、自己修復（self-healing）の性質を備えています。

　FTPが使われ始めたのと同じ頃、「NNTP」（Network News Transfer Protocol）を使ったネット・ニュースの配信も盛んでした。FTPと同じく高信頼型ストリームを前提としていましたが、さらに、ニュースの購読者からのアクセスがサーバーに集中して過負荷の状態になることを回避するために、中間サーバー（intermediate servers）あるいはスレーブ・サーバーを導入していました。中央のマスター・サーバーのコピーを持たせた2次サーバーを分散して配置することにより、サーバーへの過負荷の問題だけでなく、ネットワーク上の混雑も減らすことができます。

　同じような考え方は、Webキャッシュにも当てはまります。1次サーバーへのアクセスの前に、最寄のキャッシュ・サーバーからのダウンロードできれば負荷分散に貢献します。また、キャッシュ・サーバーを固定とせずに、キャッシュの状態やサーバの負荷、ネットワークの状況などに応じて、キャッシュ・サーバを動的に割り当てる「CDN」（Content Distribution Network）のサービスも広がっています。分散配置したキャッシュ・サーバーの中から最も良いものを選択することでサービスの質を向上させるのです。

2）1対多の放送--ストリーミング

　1対1のダウンロードでは、サーバーへのアクセスの集中を回避したり、ネットワークでのトラフィックを減らす仕組みが重要でした。そのため、同時にアクセスできる数を制限するなどサーバー側での対策が必要なこともあります。「FTTH」（Fiber To The Home）など、光ファイバーの敷設によってネットワークの性能を向上させることで、その上限の数を増やすこともできますが、それは本質的な解決ではありません。これは、スケーラビリティの問題です。

　サービスを受けるクライアントが多数で、しかも同時にデータを受け取る状況、つまり、放送型のサービスには、「IP Multicast」というIPネットワークにおける多数ホスト向けの配信の方法が提案されてきました。1980年代の最後で、多くの人がまだFTPによるダウンロードに忙しかった時代のことです。これは地上波やケーブルの信号を利用するのではなく、コンピュータ・ネットワークを利用して、パケットで放送を実現しようとする画期的な提案でした。

　IP Multicastでは、パケットは「ホスト・グループ」と呼ばれる1つのIPアドレスで指し示されるクライアントの集団に送られます。サーバーが送り出したパケットは、「マルチキャスト・ルーター」と呼ばれる特別なルーターがリレーすることで転送します。このとき、重複したコピーは作らずに、グループのメンバーがいる方向にだけ無駄なく送り出していきます。2つ以上の方向にメンバーが分かれているときは、それぞれに分岐してリレーします。この配信の経路は、サーバーを幹としてホストを枝葉とした木と捉えることができます。このように、ネットワークのリソースを共有しながら倍々に宛先を増やしていく木構造は、スケーラブルな配信の本質です。1対1のダウンロードを並行に行う方法では、この共有の性質は実現できません。

　1990年代半ばになると、オーディオやビデオのような、連続型でリアルタイムのデータ配信のために「RTP」（Real-time Transport Protocol）が提案され、いわゆるストリーミングが盛んになってきました。IP Multicastと組合わせることで、テレビ放送に匹敵するような、IPネットワークを利用した大規模な放送の実現も期待されました。

　RTPでは、パケットに連番やタイムスタンプが付け加えられていますが、そのプロトコルには時間通りにパケットを届ける仕組みはありませんし、また、QoS（Quality of Service）も保証されません。代わりに下位のレイヤにそれらを期待します。

　一方、IP Multicastは1対多の同時配信を考えるとき、非常に洗練された最適な方法ですが、しかし、いまだいくつか問題も残ります。まず、IPネットワークでの仕組みなので、パケットの配達が保証されないベスト・エフォート型のサービスです。しかし、安易に再送をサーバーに要求すると、多数のホストから同時に要求が集中して内的爆発（implosion）を引き起こすことになり、せっかくのスケーラビリティも破綻します。また、TCP は1対1のコネクションが基本ですから、残念ながら組合わせて使うことはできません。

　ホスト・グループに唯一のアドレスを割り当てるためのネットワーク管理も問題です。広域にわたってその唯一性を保証しなければなりませんが、その仕組みがありませんので競合の危険性もありますし、悪意のある競合などセキュリティ上の問題も深刻です。展開配置の問題もあります。サーバーとホストの間にあるルーターは、すべてマルチキャスト・ルーターにする必要がありますが、この強い制約もIP Multicastの普及を阻害しています。ちなみに、最近のルーターのほとんどはIP Multicastの機能を持って設計されているようですが、実際の運用ではその機能がOFFにされているのが現状のようです。

3） アプリケーション・レイヤのマルチキャスト

　IPレイヤのマルチキャストの問題点を解消するために、2000年前後から活発に提案されてきているのが、アプリケーション・レイヤのマルチキャストです。

　ルーターやスイッチを省いて、サーバーとエンドのホストを直接つなぐ仮想的なオーバレイのネットワークを想定して、その上で配信の木構造を構成します。IPレイヤのマルチキャストでは、中継点がルーターやスイッチでしたが、アプリケーション・レイヤのマルチキャストでは、エンド・ホストが木構造の中間ノード、すなわち配信の中継点となります。P2P型の配信と見ることもできるでしょう。

　ホスト間の接続が基本ですから、エラーやフローの制御をしてもスケーラビリティには影響ありませんし、ネットワーク・アドレスもその接続に閉じた局所的な割り当てでOKです。また、ルーターの機能には依存しませんので、展開配置の問題も解消できます。むしろ、完全なエンド型ソリューションなので、インフラへの追加投資ゼロで実現することができるのです。

　エンド・ホストに階層関係を持たせてリーダーを任命して効率的な配信を実現する方式や、多くのエンド・ホストにあらかじめ専用のプロセスが動いていることを前提としていて、サービスを享受しない場合でもパケットの中継を行なう方式などやり方は様々ですが、いずれもオーバレイ・ネットワークの上の配信木という構成をとっています。

　したがって、実際のネットワーク構成のもとで最適だったIPレイヤのマルチキャストに比べると、ネットワークを流れるトラフィック量は増えますし、末端までの到達距離は伸びますのでパケット到着の遅延も大きくなります。しかし、現実的な制約の範囲の中なら、これは大きな問題にはなりません。たとえば、双方向の会話ではなくて、一方向の放送なら、2〜3秒の遅延も許容されるでしょう。

　しかし、アプリケーション・レイヤのマルチキャストには新たな問題が生じます。ルーターやスイッチは、パケットの転送を専用に行うハードウエアですから、その動作や性能は安定していると考えて良いでしょう。

　しかし一方でエンド・ホストは、たとえば、いつ電源が落とされるかもしれないオフィスのPCで、そのCPUなどの性能も様々です。また、高性能のPCであっても、一時的に、たとえばメールの読み込みなど、他の処理のために忙しくなって、パケットの転送がおろそかになることもありえます。全体的には、配信木での上流のホストに障害が起きたとき、下流のホストにパケットが届かないという問題を引き起こします。配信木を再計算すればよいのですが、オーバヘッドがかかりますし、再計算の間はパケットが途絶えることになるかもしれません。中には、一時的な中断が起こりうることを明記しているサービスもあるようですが、高品質の放送を謳うなら回避すべきでしょう。

4）安定したマルチキャストに向けて

　部分的に再計算できるとしても、配信木が（半）固定されていることが、マルチキャストを不安定にしている要因でした。したがって、配信木が自己修復的に柔軟に変化するとしたら、マルチキャストのサービスを享受している系は安定するでしょう。

　エンド・ホストの役割を固定せずに、たとえばランダムに変化させることができれば、配信木は頻繁に変化します。ひとつのホストで見れば、配信の上流に現れたり下流になったりするのです。ひとつのホストが原因であるような障害は継続しません。逆説的に聞こえるかもしれませんが、このような変化や揺らぎは系を安定にします。

　1つの方法は次の通りです。配信のソースとなるサーバーは、ランダムに転送先ホストを選択します。このとき、送出キューの長さを見て、送出が滞っていないホストを優先的に選ぶのが障害を回避するのに効果的です。パケットを受け取ったホストは、ピア・ホストにそれを転送します。サーバーから見れば、ホスト・グループのうちの誰か一人に、重複なくひとつずつパケットを送信しているので、合計でも一人分の送信です。過負荷はありませんし、途中のネットワーク経路も混雑しません。

　エンド・ホストから見れば、一部がサーバーから届き、残りがピアから届いて、合計で一人分のパケットが揃います。また、自分以外のピアに転送するパケットが約1人分あります。このように、エンド・ホストの役割は頻繁に変化しています。また、その転送の量も平均化されていて、1人分が入って、約1人分が出て行くというバランスになります。固定木の場合には、末端では送出ゼロですが、中間ノードでは2人分以上の送出が必要でした。なお、性能が低いホストは、サーバーから直接パケットを受け取る回数が減り、結果的に配信の下流に追いやられることになります。このようにして、一部で起こりうる障害を広めないようにして系の安定性を優先します。

　ホストの数が多い場合には、ネットワークに階層構造を持たせてスケーラビリティを確保します。ある階層の代表としてパケットを受け取ったホストは、下位のホストにそれを転送します。ただし、階層のリーダは固定ではなく変化します。したがって、配信木もパケットごとに変化することになります。

　なお、性能の低いホストは、下位に留まることになるでしょう。エンド・ホストには各階層の代表候補を知らせてあるので、配信経路の決定も、サーバー中心ではなくて、エンド・ホストに分散されています。つまり、サーバーは一段目を選択するだけで、残りの経路についてはエンド・ホストに任せるのです。

　パケットが縦横無尽にいろいろなホストから届く様子から、われわれはこれを「P2Gグリッド・デリバリ」と呼んでいます。グリッド・コンピューティングと同じく、高圧線送電網の “power grid” のグリッドです。P2Gは「Peer-to-Group」の略称で、サーバー（ピア）からホストのグループへデータ配信をすることを表しています。

5）利用のシナリオ、そして今後の展開

　コンピュータ・ネットワークを利用したマルチキャストは、必ずしも、既存の大規模な放送に置き換わる必要はないでしょう。むしろ、企業の決算報告や小学校の授業風景を放送するなど、地域や企業内に絞った、一部の人にとって価値の高いニッチなメディアを扱うのに非常に適していると考えられます。