CDN事業者の Egress トラフィック
エンジニアリング- SIGCOMM2017発表から ⼩⾕ ⼤祐 (京都⼤学 学術情報メディアセンター)

{CDN, OTT, コンテンツ} 事業者, Hyper Giantl

コンテンツをインターネットの利⽤者に配信している事業者
u Google, Facebook, Akamai, J-Stream, など
u テキスト、画像、ビデオなど

l

巨⼤なトラフィックを⽣み出す

u Facebook: 数Tbps レベル [Shuff 2015]

u Akamai: 数⼗Tbps レベル (2017/09/15 のプレスリリース)

https://www.akamai.com/uk/en/about/news/press/2017-press/new-akamaipeak-traffic-record-demonstrates-increased-importance-of-live-online-events.jsp
2017/11/9

2

コンテンツ配信の最適化
Webサイトの応答時間 (ページが表⽰されるまでの時間) が重要[Nielsen 2010]
u 時間がかかるとユーザが離れてしまう

https://www.nngroup.com/articles/website-response-times/l

例: プロトコルの改良

u 複数のTCPコネクション → ⼀つの TCP コネクション (SPDY, HTTP/2)
Ø コネクション数の削減

Ø TLS の handshake やヘッダの重複のオーバヘッドの削減
Ø TCP の Slow Start の影響の軽減
Ø プライオリティ

u TCP → UDP (QUIC)Ø TCP の Head of Line Blocking 問題の影響の軽減
2017/11/9

3

⼤規模コンテンツ事業者のコンテンツ配信基盤l

膨⼤なトラフィックを、効率よく⼩さい応答時間で捌く100Gbps/IP 以上までスケールアウトするロードバランサ
ECMP や Consistent Hashing 等を利⽤
Ananta (SIGCOMM ’13), Maglev (NSDI ’16)

データセンター・・・

プライベート
バックボーン
B4, SWAN(SIGCOMM ‘13)

今回はこちら

世界中に PoP (Point of Presence) と Proxy を設置

TCP や TLS の Handshake 時間の短縮, 静的コンテンツのキャッシュ
2017/11/94

例: Google の PoP

出典: ACM SIGCOMM ‘17 の KK Yap ⽒の発表資料より
2017/11/95

BGP の限界
各ルータは Best Path に従ってパケットを転送するので複数の経路があったときに有効活⽤できない
u 例: Best Path ではないが遅延が少ないパスを使う

輻輳していないリンクに少しトラフィックを迂回させる

複数の PoP のサーバの負荷やトラフィックの状況に応じたPoP 間の負荷分散が困難
AS 1

AS 2

AS 3

AS 5

AS 4

2017/11/96

利⽤者のトラフィックの制御
Ingress (利⽤者 → コンテンツ事業者):
広域負荷分散技術による最適な PoP の選択

u Anycast や DNS を活⽤、PoP のサーバの負荷も考慮
u FastRoute [NSDIʼ15] by Microsoft

End-User Mapping [SIGCOMM ʻ15] by Akamai

Egress (コンテンツ事業者 → 利⽤者):
パケットが最適なパスを通るように制御
u Peering /Transit のリンクの選択

u Edge Fabric [SIGCOMM ʻ17] by Facebook

Espresso [SIGCOMM ʻ17] by Google

BGP で得られる経路を活⽤しつつ、従来の経路制御だけには頼らない (ルールを無視した)
トラフィックの制御
2017/11/9

7

本セッションのご講演
CDN のトラフィックエンジニアリング
鍋島 公章 様 (J-Stream)
CDN の価値観や今後の⽅向性
BGPによるドメイン間経路制御の現状と将来：障害事例と対策
⻄塚 要 様 (NTTコミュニケーションズ)
BGPで制御できないトラフィックがある状況で今後の経路制御はどうしていくべきか

2017/11/9

8

Egress トラフィックの制御の例
AS 3

AS 1 への送信:
普段はプライベートピア経由

パブリックピアWhen:l プライベートピアの輻輳AS 4
l プライベートピア経由の通信の品質の悪化
トランジット(遅延の増加や輻輳の発⽣)

AS 2
AS 1
IXプライベートピア
コンテンツ
事業者AS

Then:
l IX/トランジット経由へ
l ビデオはプライベートピア、テキストや画像はIX/トランジット経由へ

2017/11/9

9

Edge Fabric (Facebook)
できるだけ BGP Best Path に従いつつ、それに従わない経路を BGP の経路を注⼊し上書き
BMP (BGP Monitoring Protocol) により各ピアからの経路を収集
Prefix/Peering Router のInterface 毎のトラフィック量を予測

sFlow や SNMP により
Prefix/ Peering Router のInterface 毎のトラフィック量を取得

輻輳が起きないように上書きする経路を⽣成(Prefix の分割を含む: 1 x /20 → 2 x /21)

図は https://research.fb.com/steering-oceans-of-content-to-the-world/ より引⽤、⼀部追記
2017/11/9

10

Espresso (Google)
Host の Packet Processor で Egress の Peer を指定(ラベルづけ) → Edge Fabric より細かな単位で制御可能

Peering Fabric(Label Switch)

PacketPacketPacketPacketProcessor Processor Processor Processor

2017/11/911

Espresso (Google)
トラフィック予測や BGP で得られる経路情報を元に遅延やスループットが同程度の Prefix 単位でどの Service Class がどの Peer を利⽤するか選択<PoP, Prefix, Service Class, Egress Peer>

Application
performance
metrics

出典: ACM SIGCOMM ‘17 の KK Yap ⽒の発表資料より、⼀部追記
2017/11/912

従来の経路制御との違い
Application Performance のためには従来の経路制御の仕組みに従わないことがある
l Edge Fabric の例:

u Peer によっては Longest Prefix Match に従わないことがある
u Peer から広報されてきた経路を細分化して扱う場合がある

lEspresso の例:

u Peer 先から広報されてきた経路を、Prefix 内のホストとの遅延が同程度になるまで Prefix を細分化して扱う

トラフィックを吐き出すサーバと連携して制御できる
l 通信の両端のうち⽚端が意図的に変更される
l BGP によるトラフィックエンジニアリングが効かない
2017/11/9

13

まとめHyper Giant は世界各地に PoP を置いている
l Hyper Giant にとっては Application Performance が重要
l Performance を優先した Egress の選択を⾏い、結果として BGP の Best Path に従わない場合がある
lu BGP が performance aware ではないl

このような制御がインターネットの経路制御に及ぼす影響を懸念
u ミスするとインターネット全体への影響が⼤きい制御をやる

事業者が増えると、経路障害の頻度が増えそう
u 従来のトラフィックエンジニアリングの⼿法が効きづらくなる
2017/11/9

14