Maygh: Building a CDN from client web browsers (EuroSys'13) を読んだ
はじめに
本稿は システム系論文紹介 Advent Calendar 2014 14 日目の記事です。
Maygh: Building a CDN from client web browsers (EuroSys'13) という論文を読みました。ざっくりと内容紹介や所感を記述します。
概要
Maygh は Web ページで要求される静的リソースを、既にそのリソースを持っている他のクライアントから P2P 通信で受け取ることによりサーバ側の帯域使用量を低減するシステムです。 Maygh は JavaScript で記述されたクライアントスクリプトという形でユーザに提供され、 WebRTC などを使ってクライアント間通信を実現します。その他専用のブラウザのプラグインなどを導入する必要はありません。 ただしコンテンツ配信者は coordinator と呼ばれるキャッシュ保持情報と保持するクライアントの IP アドレスを教えるためのサーバを提供する必要があります。 各クライアントはリソースを取得する際にまず coordinator に問い合わせ、それのキャッシュを持つ他クライアントがいれば coordinator からもらった情報を元に WebRTC 接続を確立して要求されるリソースのやり取りを行うことになります。
Maygh の評価として、ショッピングサイト Esty のアクセスログを用いたシミュレーション結果が提示されています。 このシミュレーション結果によると、 Esty のワークロードにおいて約 75 %ほど帯域使用量を削減することができるとのことです。
従来のコンテンツ配信
大規模な Web サービスを運営する上で、コンテンツ配信に伴うネットワーク負荷を捌く方法は悩ましい問題です。 今日ではネットワーク設備を強化する、配信サーバの台数を増やす、静的コンテンツの配信に Akamai や Limelight などの CDN(Contents Delivery Network) を利用するなどの方法が存在します。 しかしながらこれらの方策は大きなコストが発生しがちです。
近年の別のアプローチとして、サーバ側設備を増強するのではなく、クライアント側で静的コンテンツの配信を共有し合ってもらい、サーバ側帯域使用量を提言する手法が現れてきています。 具体的な実装例として Akamai NetSession Interface などが存在します。 しかしながらこれらの既存手法は専用アプリケーションやブラウザのプラグインの導入を強いるものになっており、エンドユーザにとって導入障壁が高いものとなっています。
Maygh のデザイン
Maygh は幾つかのモダンなブラウザの提供する機能の支援を受けて、エンドユーザに専用プラグインなどの導入を強いることなくユーザ参加型のコンテンツ配信を行うシステムです。 Maygh を利用するにあたって、ユーザのブラウザには都合下記のような要件が発生します。
JavaScript が有効になっている
Indexed Database API, WebStorage をサポートしている必要がある
- Maygh はこれら Storage API を用いて各クライアントの LocalStorage にキャッシュを保持する
WebRTC をサポートしている
Maygh は、各クライアントに配布される Maygh クライアントスクリプト と、コンテンツ配信者により提供される coordinator サーバ から構成されます。 Maygh クライアントは小サイズの JavaScript で実装されたスクリプトです。 RTMFP を用いるための小さな Flash オブジェクトも伴います。 coordinator は Maygh クライアントと各クライアントが持つコンテンツの対応関係を管理する client map と、 各コンテンツを持つオンライン状態のクライアントの情報を管理する content location map の二つのデータを持つサーバです。 Maygh の coordinator は性能がスケールできるよう複数台で動作できるよう設計されています。複数の coordinator を動作させる際は、それぞれの coordinator が content location map を持ち、自分にぶら下がっているクライアントの情報を管理するようになります。
Maygh による通信
Maygh によるクライアント間、そしてクライアントと coordinator 間の通信は下図の通りになっています。
図には含まれていませんが、クライアントは Web ページ初回アクセス時に coordinator にコネクションを張り、 Maygh の update メッセージで自身の持つコンテンツ情報を送ります。 各コンテンツの取得時に最初に lookup メッセージを送信し、それに対するレスポンス lookup-response をもって要求する他のクライアント（以降、ピア）の ID を取得します。 その後 coordinator に connect メッセージを送信し、コンテンツを所有するピアとの RTMFP/WebRTC セッションを確立します。 この際、多くの場合ピアの間には NAT デバイスが挟まっていることが想定されるので coordinator に STUN をしゃべってもらい、相手方ピアの IP アドレスとポート番号を教えてもらいます。 その後は RTMFP/WebRTC セッションを確立し、コンテンツの取得を行い、最後にコンテンツを取得完了した旨を update メッセージで coordinator に伝えます。
評価
実装
この論文では Maygh の評価を行う上で下記の実装を行ったとのことです。
Maygh coordinator(RTMFP 版)
- ArcusNode を大きく改変して実装
Maygh client
- JavaScript と ActionScript で実装
Maygh client(コマンドライン版)
- Node.js で実装
また、 Maygh の実装は GitHub に公開されている ようです。
coordinator がスケールするかの検証
複数の coordinator プロセスを1台の検証用マシンで動作させた際と、複数のマシンで動作させた際の transaction/sec が検証されています。 検証の結果、複数マシンで動作させることにより coordinator 数に比例して捌けるトランザクション数が上昇しており、十分スケールするとのことです。
Maygh による帯域使用量削減効果の検証
Esty の 7 日間のアクセスログを用いた、 Maygh の効果のシミュレーション結果が提示されています。 この結果によると、 Maygh 導入により約 75% の帯域使用量削減効果が見られたようです。 また既存の専用プラグインを導入してクライアントサイドでコンテンツ交換を行う手法との比較として、「10% のユーザがそのプラグインを導入する」という想定での帯域使用量の削減効果も検証されていますが、こちらは約 7.8% と Maygh と比較して低い効果しか見られないとのことです。
余談: 最近の関連トレンド
この論文を読んでいて思い出したのですが、昨年に米 Yahoo! が PeerCDN という配信システムを持つ会社を買収した話 があったかと思います。 記事によると WebRTC で P2P 通信することでコンテンツ配信をするらしい話が記載されていることもあり、本論文に近い手法であるものかと推測されます。 PeerCDN のその後の話も気になりますね。 また最近ですと、あまり詳細な情報は出ていないようですが、 BitTorrent 社が BitTorrent を用いてコンテンツ共有を行う Web ブラウザ Maelstrom のアルファテストを開始したとのニュース があったかと思います。
P2P でクライアント間でコンテンツ配信負荷を負担し合ってサーバ側帯域使用量を減らす手法の今後の動向が気になるところです。
