---------------------------------------------------------------- タイトル: CDNにおけるコンテンツルーティング技術 発表者: 小宮博美 さん (ノーテルネットワークスコンテンツネットワーキング事業部) hkomiya@alteon.com logger: 渡辺 直樹 (nabe@iij.ad.jp) 日時等: July 27, 2001, 13:30〜14:00 @JANOG8 meeting ■ 講演概要 □ RTSPロードバランシング + 3つのセッションで構成されるストリーミング(RTSP)を1つの単位で ロードバランシング(SLB)する。 + RTSP SLBの機能により、RTSPサーバにローカル・アドレスを付与する ことができる。 + サーバの台数の増加が見込まれる今後、少量のグローバル・アドレス で大規模サービスが可能となる。 □ 帯域制御フレームワーク + コンテンツは、動画、静止画、テキスト、音声等多種化の傾向がある。 + 特にストリーム系のコンテンツは遅延(揺らぎ)にsensitiveである。 ストリームコンテンツは帯域があればいいというわけではなく、スムースさ (揺らぎetc.)が重要である。 + 一つのアプローチとして、各コンテンツデータに対するアクセス帯域幅を コントロールすることが、ユーザにとってのコンテンツの品質向上に有効 である。 + 品質(Qos)に関してバックボーンネットワークの実装は Priority Queueであると 思われるが、Alteon の製品(Web Switch)ではアドレス、アプリケーション などをキーにして帯域幅をコントロールすることができる。 -- □ ユーザはどのサイトからサービスを受けるのか? CDN(Contents Delivery Network)を利用して、 各地に点在するコンテンツ キャッシュのうち)どのセンタ(サイト)からサービスを受けるのか? が重要と なる。 + 従来のアプローチ(DNS アドレス解決(DNSベースルーティング)) - DNS リゾルバに近いところのキャッシュを static にアドレスを登録して おき、ユーザにとって、"近い"サイトの判断は、DNSにアドレス解決要求が 行ったところで決定する。 1. クライアントからアクセス ローカルDNSに問い合わせ 2. ローカル DNS が www.abc.comのアドレス解決 3. DNSが、もっとも"近い"と思われるところの IP アドレスを解決。 4. 以下手順は、DNS が返答する IP アドレスに支配される。 + 問題点: - 上記の方法ではストリーム等のさまざまなコンテンツに対して、本当に 有効な(あるいは"近い"といえる)サイトを選択することができない。 - ASホップ数。icmpレスポンス応答でみても、ユーザが要求するコンテンツの 中身、品質に対する要求を意識できていないのではないだろうか?。 (実際にはローカルDNSへのホップ数、応答時間で決定されてしまい クライアントからのものではない) + 参考データ: クライアントとアドレスとDNSのアドレスの関係として、参考として a) 60% がDNSと個となるネットワークに位置する。 b) 15%ユーザがDNSと個となるASに存在する。 というデータがある。 -- □ Alteon の新しいアプローチ "インテリジェントコンテンツルーティング" # 新しい言葉なので、広く使われているわけではないが広めて行きたい。 ユーザがアクセスするコンテンツの"近さ、速さ"を、ユーザの真に発行する トラフィックから導出していくアプローチである。この度、Alteon の新製品 PCD (Personal Contents Directer/Alteon) が実装した、 新しい 2 つのモード(Foot Race モード、Refresh モード)を紹介する。 (もちろん従来の方法も利用することはできる。) □ Foot race モード: + 手順: 1. クライアントが DNS にクエリ発行(このとき、default で返されるIP アドレスはどれであってもかまわない) 2. 例えば サイトA が HTTP GET リクエストを受け取る 3. サイト A の PCD がフレームのコピーを生成し、各サイト(B,C)に転送 する。 4. 各サイト、A,B,C は全員一斉にクライアントに対して HTTP GET の replay を送信する。 5. クライアントは返答メッセージとして、一番番最初に届いたサイトのものを 採用し、その後の通信はそのサイトと行われる。 - このモードでは、全ての リクエストで利用される TCP ヘッダは A と通信して いるときと変わらない。 redirect: TCP/IPヘッダの部分は同じデータが利用される。が、 HTTP の中身が違う。 - IPヘッダ部分が同じであることが問題となる可能性: + 全てのサイトから同じIPアドレスで返信が行なわれる。 これは、ネットワークを運用している側から見ると(アドレスの無いはず のネットワークを source とするトラフィックが返信されるので) spoofしているように見えてしまう。 - ソースフィルタかけられると落されてしまう。 -> イントラネット等での利用が推奨。 -- □ refreshモード + refresh モードは、TCP/IP的にも通常のシーケンス/ルールを踏むため インターネットで利用することも問題ない。 + 手順: 1. クライアントから、DNSクエリ。サーバAのIPアドレスを返答。 2. クライアントは defaultであるサーバ AとTCPコネクション確立、 HTTP GET要求。 3. PCD がサイトA、B、C へのイメージリンクを含んだページを応答し、 クライアントに対してリフレッシュ を要求 4. 各サイトは "ACKのターンアラウンドタイム"で、近接サイトを検出。 5. サイトからユーザに対しての距離(時間)が A > B > C だったら、 サイトAはクライアントへサイトC への Redirectionを送る。 6. クライアントは次のクエリからサイトCにコンテンツを要求するように なる。 + TCPのルールに逆らわないredirectは、既にブラウザの常識と考えたい (ユーザは特別な設定を必要としない automatic である)。 + "ユーザに近いサイト"、の定義をRTTが短いサイトとしている。 ユーザに対しての経路リンクが太いか細いか(早いか遅いか)は重要な要素 であり、従来のように、AS数、ホップ数等の数的な近さ/遠さとは限らない だろう。 -- □ まとめ + "インテリジェントコンテンツルーティング" の手法として 2つのモードの 紹介を行なった。今後の CDN の発展に貢献して行く技術であると考えたい。 -------------------------------- ■ Q&A Q1: サイトA、B、C間の通信(連係)はどのようにするのか? A1: 普通にIP reachableであれば、相互にヘルスチェックはできる。 各ABCサイトは、一斉に同じタイミングでかえすことが要求されるため、 サイト間は時刻同期をとっている。 Q2: 本モードはクライアントサーバ間の RTT をキーとするが、最初のシーケンス でのレスポンスや、少ないコンテンツのときには遅くなってしまうのでは ないか? A2: Yes. 初期の処理は遅いことがありうるが、サブネット単位でキャッシュを行なう ため、次に同じサブネットに属するクライアントからのリクエストは速くなる。 サブネットマスクはデフォルト設定で 24ビットである。