Google Espresso解説(2017年)

Slide 1

Slide 1 text

Googleの論文から読み解く最新DC/NWアーキテクチャ技術開発セミナー 2017.10.20 技術開発部西塚要 Google Espresso編

Slide 2

Slide 2 text

最初に • ACM SIGCOMM 2017 で発表された以下の論文の内容に基づいて、解説します – Taking the Edge off with Espresso: Scale, Reliability and Programmability for Global Internet Peering – 詳細については、元の論文を参照ください • インターネット基礎的な話は割愛いたします • 明日からすぐに使えるアーキテクチャではありません

Slide 3

Slide 3 text

1. イントロダクション

Slide 4

Slide 4 text

背景 • Google/Facebookなどの巨大コンテンツホルダは、ユーザーへコンテンツを提供する上で BGPによる制御だけではネットワークのリンクを有効的に活用できないことを問題視 • Google/Facebookがそれぞれ、独自の最適化手法について、SIGCOMM 2017で発表 – Google: Espresso – Facebook: Edge Fabric

Slide 5

Slide 5 text

Googleの解決したかったこと(1/3) • ユーザ/アプリケーションごとに最適なPathを選択したい – しかし、BGPでは実現できない

Slide 6

Slide 6 text

BGPによる制御の制約問題 • GoogleのTraffic Engineering(以下、TE) – 何百万の個々のユーザとの間で、高帯域/低遅延となるegress ポートをリアルタイム計測している • BGP経路単位での経路の切り替えは、荒すぎる – ユーザセグメントの単位が大きすぎる – アプリケーション単位ではない

Slide 7

Slide 7 text

Googleの解決したかったこと(2/3) • 新しい機能の導入サイクルを早めたい – しかし、ルータの新機能導入サイクルは遅い

Slide 8

Slide 8 text

ルータの機能改善サイクル問題 • 新機能の導入にはベンダのHWやSWの変更が必要 – 少しの変更でも検証に1年かかったり – 標準化に時間がかかったり – 新しいシリコンを待たなければいけなかったり • しかもアップグレードに失敗すると影響が大きい

Slide 9

Slide 9 text

Googleの解決したかったこと(3/3) • ピア用ルータのコストを下げたい – テラbps級のトラフィック • 高画質動画 • クラウドトラフィック – 数百ポート/1筐体のポート密度 – フルルート対応 – 巨大なACL(DoS対策) • エッジ構成において、ピア用ルータの価格がコストの支配項 – エッジルータは、一つ内側のルータのコストの 4-10倍 • 一つ内側のルータのACLや転送に関する要求はそれほど高くない

Slide 10

Slide 10 text

Google WAN構成

Slide 11

Slide 11 text

GoogleのSDN技術 • Jupiter [SIGCOMM 2015] • B4 [SIGCOMM 2013] – GoogleのDC間SDN • Espresso [SIGCOMM 2017] – Jupiter/B4で培ったSDN技術を、対外接続に応用

Slide 12

Slide 12 text

(補足) ISPの立場で ISP-A ISP X ISP Y Googleのどこからダウンロードトラフィックが吐かれるかは、 ISP側からはBGPでも制御できない ISPから見ると、通常のBGPピア

Slide 13

Slide 13 text

2. Espressoの導入

Slide 14

Slide 14 text

Espresso導入箇所: Peering Edge(以下PE)

Slide 15

Slide 15 text

Espresso導入箇所: Peering Edge(以下PE) • 構成要素 – テラビット級ルータ – メガワット級コンピュートノードとストレージ • PEの機能 – 他のASとのpeering – reverse proxy として TCP の終端 – 静的なコンテンツのキャッシュ • PEの効用 – エンドユーザへの latency を小さく – DoS への耐性(被害範囲の限定) – 大容量のバックホールを要しない

Slide 16

Slide 16 text

Espressoの特徴(1/2) • Externalizing BGP – 概念としては、control を外だしして、ルータには data-plane だけ残す • ルータの代わりに安価な MPLS switchで済む – BGP はサーバ上のソフトウェアで走らせた(ルータのCPUは貧弱なので) • Externalizing Packet Processing – forwarding table や ACL のパケットプロセッシングをエッジにすでに存在する高性能サーバのソフトウェアパケットプロセッサに移した

Slide 17

Slide 17 text

Espressoの特徴(2/2) • Hierarchical control plane – Metro内(local)での最適化: Location Controller(LC) – Metroを超えた(global)最適化: Global Controller(GC) – 二層のコントローラにより、早い収束時間とフェールセーフを実現 • Application Aware Routing – パケットプロセッシングをするフロントサーバが、アプリケーションごとの品質を、グローバルのトラフィック最適化機構にフィードバック

Slide 18

Slide 18 text

導入の効果 • グローバルトラフィック最適化 – ピアのリンク使用率の向上(後述) • Application-aware TE – End-to-End のQoEの向上(後述) • 開発スピードの向上 • コストダウン – エッジ機器が 75% 安上がり

Slide 19

Slide 19 text

利用状況 • 発表時点(2017/8)で、Googleから吐かれるトラフィック全体の22%がEspresso利用 – 直近2カ月では、トータルトラフィックの伸びよりも2.24倍の伸び

Slide 20

Slide 20 text

3. アーキテクチャ概要

Slide 21

Slide 21 text

サーバ(Reverse Proxy) • Metroには大量のReverse Proxy(L7)が存在する – ユーザのコネクションを終端する • ユーザ向けのレイテンシを抑える – キャッシュコンテンツをさばく • バックボーン向けのトラフィックを減らす • キャッシュできるコンテンツのパフォーマンスを向上させる • Espressoの鍵は、「すでに存在するこれらのサーバにパケット転送やACL処理を肩代わりさせること(リソースの一部を有効活用) 」

Slide 22

Slide 22 text

Incoming Traffic • ISPとの接続は2種類 – 旧来のルータ: PR(Peering Router) – EspressoのMPLS SW: PF(Peering Fabric) • DC内は Spine-Leaf 構成( と考えられる) • パケットは、PRまたはPF から入り、Reverse Proxy で終端される PFから入ったパケットはGREをかぶせられて Reverse Proxyに転送される PRから入ったパケットに関しては言及なし (こっちはGRE無しなのでは？) なぜ？なぜ？

Slide 23

Slide 23 text

Outgoing Traffic • Reverse Proxyが、フルルートのフォワーディングテーブル(FIB)を保持し、どこを出口にするか決める – PRかPFを選択する – PFの場合、どのスイッチのどのポートから転送するかをきめる – 実現方法：PFをGRE、PFの出ポートをMPLSラベルで指定 • FIBはアプリケーションアウェアのロジックで決定される・カプセル化は、Reverse ProxyのHostで実施する・GREのIPは、途中のSWでhash algorithm において十分なエントロピーがあるように考慮されている

Slide 24

Slide 24 text

コントロールプレーン

Slide 25

Slide 25 text

各コンポーネント紹介: (1) Global traffic engineering system • Global TE Controller(GC)と Location controller(LC) から成る – LCは、(経路withdrawなどの)障害に対する迅速な対応(経路切り替え)を実行 • application-aware routing を実現する – 各種要件に基づきアプリケーション(=優先クラス)単位のベストパスを選択 • Reverse Proxyのpacket processor に対して、flow entry(application ごとに egress port を選択)をプログラムする • ACLのプログラム(DoS対策)にも使われる

Slide 26

Slide 26 text

各コンポーネント紹介: (2) Peering “Router” Commodity MPLS switch(PF) • レガシーのPRとは異なり、TCAMも小さく、フルルートは持てないし、ACLも書ききれない • その代わり、IP GRE と MPLS の de-capsule は line rate でできる – MPLSの転送ルールはピアの数だけでOK BGP Speaker • 対外のBGPピアは、内製のBGPスピーカ(Raven)で実装 – こちらも物理的には Proxy Server の Host に間借り – PFとの間でGREを貼ることで、ISPのルータと1hopで接続(=BGPのTCP セッションはBGPスピーカーで終端) – c-planeとd-planeが通常のBGP peerと同様に一致しているメリット(=例えばリンク障害があればBGPピアも落ちるということ) 上記の組み合わせで、既存のルータと同等の機能を(安価に)実現

Slide 27

Slide 27 text

各コンポーネント紹介: (3) automated configuration • オペレータの意図(intent)に基づきコンフィグを自動生成&検証 – intent というので high level な config を書いて low level な設定をいれていく – Big Red Button(緊急避難)など • BGP Speaker(内製)のGUIで、ボタンをクリックするだけで一時的にpeerをdisableできる • intentの変更だけで、複数のBGP peerのconfigを消すことができる • 夜間に動作テストをしている – 詳細は論文には書いておらず • operator フレンドリーにしているが、SDNをいかに実現するかにおいてまだまだ課題があるところの一つ、だとか

Slide 28

Slide 28 text

4. Application-aware TE system

Slide 29

Slide 29 text

Application-aware TE system

Slide 30

Slide 30 text

FIBのプログラミング • Internet Scale の FIB はReverse Proxy にあり！ – DRAMに保持(評価は後述) • 適用順序 – GCが全てのBGP/品質/コスト情報を集める – application-aware FIBを計算し、結果をLCに渡す – LC が FIB を host のパケットプロセッサにインストール

Slide 31

Slide 31 text

GC: Global TE Controller • GCはレガシーとEspresso両方をサポートしている • GCの出力は、 – に対する – egress mapと呼ぶ – ひらたく言うと、「このPoPの、このユーザprefixの、このサービス (Youtubeとか…)は、このルータのこのportから出力する」というルール • GCの入力は、 – 1) Peering Route – 2) User Bandwidth Usage and performance – 3) Link utilization – と、コストなどのハイレベルなポリシ(論文では強調していないが)

Slide 32

Slide 32 text

1) Peering Route • LCがPoP内のBGP Speaker(PR/PF両方)から経路情報を集め、GCに伝える • GC内の Feed Aggregator がLCからの情報を集約する – AS-PATHなどの通常のBGP attribute 情報を利用して、prefixごとの出口ポートの優先リストを作成

Slide 33

Slide 33 text

2) User Bandwidth Usage and performance • Reverse proxyで計測した client prefix ごとの bandwidth, throughput, RTT, retransmitなどの情報を、GCの Volume Aggregator が集める • client prefix は /24 (IPv6は/48)ごと • Routing情報の中で、/24単位でlatencyに偏りがあった場合、同程度の品質の塊になるように de-aggregation(prefix分割)する – この動作を額面どおり受け取るならば、分割した経路をBGPに乗せたりはしない

Slide 34

Slide 34 text

3) Link utilization ピアリングリンクの使用率 • リンク使用率、パケットドロップ率、リンク速度を計算にいれる • GCの Limit Computer がこの情報をユーザの要求(=ダウンロードトラフィック量)と結びつけて、service class, link ごとに帯域を割り当てる • dropがあるようなリンクはアグレッシブに割り当てを減らす • peering link の利用率を17%改善(後述) エンドツーエンド品質 • end-to-end の path のクオリティをReverse Proxyで計測 – 最良時の品質でclient prefix, AS-path, peering linkをグループ化 • このグループごとに、品質劣化時に混雑しているリンクから動かす • 170%ユーザ体感を改善(後述)

Slide 35

Slide 35 text

Application-aware TE system(再掲)

Slide 36

Slide 36 text

最適化？ • どのような重み付けの計算をしているかは、論文からは不明 • 最適化手法 – 線形計画法(LP)より早いので貪欲法(greedy)を採用 – LPよりもlatencyが3-5%少ないという結果がでたが、 Future Work

Slide 37

Slide 37 text

ピアのリンク帯域の利用方法(貪欲法) • 優先順の高いトラフィックから帯域を割当 – 最良リンクに最優先トラフィックから順に割当 – リンクの容量を超えたら次のリンクに割当 • リンク障害があっても優先度の高いトラフィックが救われるように、割当の余地を残しておく – 余地はパケロスに強い低優先トラフィック(low QoS)で埋める – キューのドロップを起こさないまでのトラフィックレベルを動的に決定して詰め込む • 計測パケット損失率が閾値以上になったら他経路を利用

Slide 38

Slide 38 text

安全性(safety) • 計算結果が前回と異なりすぎる場合は前回結果を用いるなどの保守的な動作をする – last-valid map を信頼する • GCの冗長化 – 複数データセンタに分散 – 分散ロック方式でマスター選出 • GCから通知されたegress map をLCはまずは一部のパケットプロセッサに適用(炭鉱のカナリア) – サービス影響時にはロールバック＆エンジニアへのエスカレーションこれはBGPの制御では難しいこれはBGPの制御では難しい

Slide 39

Slide 39 text

LC: Location Controller • LCはpeering locationごとに存在 – 約1000個のサーバ(Reverse Proxy)を制御 – 全てのpacket processor を config する → scaling メリット • GC 故障の際のフォールバック先になる – GCの破壊的なアウトプットを抑制する – IFの突然のシャットなどのイベントにも対応する • route withdraw といった bad news に対しては素早く反応する(GCの制御ループでは遅い) – LCからは毎秒11.3回経路更新 • 常時、traffic の3%は過去になかったものなので、egress mapが存在しない – defaultはBGP best-path – trickle(細流)を常に、このフォールバック先に流しておいて、フォールバックしたときに大丈夫か保証しておく

Slide 40

Slide 40 text

Example of LC programming packet processors with TE assignments from GC

Slide 41

Slide 41 text

Example of LC programming packet processors with TE assignments from GC ルータAのポート30 から転送する場合は、このGRE-IPと MPLSラベルでカプセル化このユーザプレフィックス(1.0.0.0/24)の、このサービス(App Class1) については、ルータAのポート30から 50%, ルータBのポート10から50%トラフィックを出す、というルール(egress map) がGCから与えられる LCは、BGPでのベストパスをデフォルトとして、各サービスのトラフィックをリンクに割り当てていく

Slide 42

Slide 42 text

Internet ACL • GoogleのACLは商用シリコンでは書ききれない – しかし、計測してみると、5%のACLが99%のトラフィックボリュームを占める – 一部のACLだけPF(MPLS SW)に書いて、残りはホスト (Reverse Proxy)で処理 – 粗いザル→細かいザル • ACLルールもLCからサーバに配布される – ACLのテストのために、一つのLCにだけ適応して様子を見る(これも炭鉱のカナリア) • サーバのパケットプロセッサでのACLは、高度な DoS対策も実現できる

Slide 43

Slide 43 text

モニタリング • データプレーンでの障害は即座にコンロトーラに送られる – 例えば、ピアダウンは BGP timeout を待つことなく、 BGP speaker に伝わる • コントロールプレーンのイベントは全てHTTP/gRPC エンドポイントに送られる • Prometheus で可視化 • end-to-end probeも活用 – ACLの有効/無効を調べる • モニタリングに関する記述は残念ながら少ない

Slide 44

Slide 44 text

5. 評価(効果)

Slide 45

Slide 45 text

Overflow • ベスト経路と異なるpeerに流したトラフィックを overflow と定義 – 同一Metro内の別ピア: 30% – 別のMetroに回されるもの: 70% • 機構がなかった時と比較して、ピーク時により多くのトラフィック(13%)を流せる

Slide 46

Slide 46 text

Overflowの割合 overflowしたトラフィックの割合 ISP ・50%以上のISPで、10%以上のトラフィックが、他に回ったほうがいいとなった・ごく少数のISPでは、ほとんどのトラフィックがOverflowしたこれって迷惑な話これって迷惑な話

Slide 47

Slide 47 text

ピアのリンク使用率の向上使用帯域(95%タイル値) ピアのリンク・使用率50%以上(95%タイル値)のピアが40%程度・使用率80%以上のピアが17% これは、調査によると業界の平均的な使用率より高いかなり詰めてるかなり詰めてる

Slide 48

Slide 48 text

パケットドロップの抑制リンク使用率が100%のリンクでも 2% のパケロスに抑えるしかも、落とされているのは優先度の低い low QoSのパケットのみ

Slide 49

Slide 49 text

End-to-End のQoEの向上 video streaming service の QoEを劇的に高めるリバッファリング(動画の停止)の平均発生間隔(MTBR)が彼らの重要な尺度らしい GoogleとISPでのピアでの輻輳はなかったので、Googleの外部の輻輳を回避できたと主張している

Slide 50

Slide 50 text

リリース速度の改善・新機能のリリース速度は、およそ週単位・商用ルータの50倍以上の速さ

Slide 51

Slide 51 text

BGP Speakerの評価 • ソフトウェアBGP Speakerとして以下を比較 – Quagga/Bird/XORP/Raven(内製) • 最初は Quagga を使ったが以下の問題があった – single thread – C based – limited testing support • 収束時間が決め手でRavenを採用した – 比較は主にB4プロジェクトで実施

Slide 52

Slide 52 text

収束時間(Raven vs Quagga) IPv4 IPv6 ・Ravenは300万経路に対しても、Quaggaより3倍速く収束(IPv4) ・IPv6はそうでもなく、同じくらい・使用メモリおよびCPUも少ない(IPv4 100万経路で半分以下のメモリ) IPv6は？なぜ4000万経路も計測しているのか？ IPv6は？なぜ4000万経路も計測しているのか？

Slide 53

Slide 53 text

収束時間(Raven vs 市販ルータ) IPv4+IPv6(実際のフルルートからの抜粋) ・市販のルータよりも、収束早い・実際のフルルートから抜粋した様々なルートセットで計測・CPU数やメモリサイズが市販ルータの10倍以上だったので、当然の結果 60万経路 60万経路

Slide 54

Slide 54 text

Host での Packet Processing 60万経路 60万経路 • host で Longest Prefix Match(LPM)をする – このデータ構造体はCPUで共有される(Lock-free) – shadow LPMを一つ作ったあとポインタを切り替える • データ構造 – IPv4: multibit トライ木 / IPv6: binary bit トライ木 • 平均で、LPMは190万経路(prefixとservice classの組み合わせ)を持っている – 平均で1.2GB消費 • 37Gbps / 3Mpps の転送性能を発揮 – LPM lookup の CPU使用率は、2.1 – 2.3%程度

Slide 55

Slide 55 text

6. 実運用での経験から

Slide 56

Slide 56 text

(1)Reporting Library のバグ • 全てのソフトウェアが同一のレポーティングライブラリを使っていた – 同ライブラリのバグによるスレッド枯渇でcontrol- plane の全滅 – Espresso経由のトラフィックが全てレガシーのルータにフォールバックした • ワークアラウンドとして有効だったので、ユーザには気づかれなかった • 結合試験にコントロールとマネジメントプレーンのコンポーネントも入れるべき

Slide 57

Slide 57 text

(2) Localized control plane for fast response • Espresso導入当初は2階層モデルではなく、GCだけを使っていた • ピアがアップして新しいprefixを受け取ってもすぐに使われない – (経路揺らぎを抑える機構で)GCへの経路の伝搬に時間を要していたため • LCでデフォルトのトラフィックパターンを計算するように変更した – GCでの上記の計算がなくなり経路反映が早くなった – Metro内でのフォールバックも可能に • 階層型のコントロールプレーンは、全体の最適化と信頼性の向上の両方に寄与することを学んだ

Slide 58

Slide 58 text

(3) Global drain of PF traffic • オペミスで、全ての Espressoからトラフィックを抜く設定をGCに入れてしまった(!) – レガシーのルータにフォールバックしたのでこちらもユーザ影響は最小だった • セーフティチェックの強化 – 試験環境でのシミュレーションにおいて、大きなトラフィック移動が発生する時はエラー扱いにした – さらに追加の仕組みをGCに入れた(具体的には不明) • 中央集権的SDNは危険なので安全チェックが多重に必要 Googleも意外と人間的 Googleも意外と人間的

Slide 59

Slide 59 text

(4) Ingress traffic blackholing • 一部のACLしかPFに入っていない状況(PFのTCAMに上限があるため)で、PF経由で全トラフィックを引き込んでしまい、ACL(allow)に書いていないVPN系のトラフィックがブラックホールされてしまった • 一番の大規模障害 – バックボーンルータでの設定変更(no-export か何か?)で、レガシーのPRからの広報が止まった、と読める • ACLの精査と、hostでのACLの展開を進めるきっかけになった • 既存インフラへの少しの変更が大きな障害を引き起こすことがあると認識

Slide 60

Slide 60 text

7. Facebookとの比較

Slide 61

Slide 61 text

Facebook Edge Fabric • シンプルにトラフィック制御を実現するため、従来のベンダールータをそのまま使い、トラフィック量に応じて経路変更を動的にコントローラーから行う手法

Slide 62

Slide 62 text

Facebook Edge Fabric • 従来のベンダー製ルータを利用して外部ASとのピアリングを行う – 今までの運用ノウハウを生かす – 万が一コントローラーで障害が発生したとしても従来通り動き続ける • トラフィック最適化方法 – ピアやIX向けのリンク帯域が不足している場合にトラフィックを分割し、分割したトラフィックを別のリンクへ迂回させるという最適化 • 実現方法 – トラフィック量を監視し経路を最適化するコントローラーを用意し、BGPで経路をルータに注入し、トラフィックを迂回させる

Slide 63

Slide 63 text

Googleからの視点では • 目的が若干異なる – Facebook: 拠点のピアの輻輳をさける – Google: 全体でのトラフィック最適化 • Facebook は、トラフィックの切り替えをBGPに頼っている(のがいけていない) • また、MPLS SWを採用しているのでBGPルータよりも安い • Facebook 対処できていない種類の輻輳問題にも対処できている

Slide 64

Slide 64 text

Facebookからの視点では • 最適化手法のデザインに大きな違いがある – Facebook: 運用コストを考慮したシンプルな手法 – Google: プログラマビリティを重視した手法 • Google は、複雑なコントローラアーキテクチャが必要 – HostでのFIBを全体で同期できないと、ブラックホールになる危険性が高い • 最適化結果の制御をピアリングルータにのみプッシュするので、Hostをルーティングから分離できる(ので運用しやすい)

Slide 65

Slide 65 text

8. まとめ

Slide 66

Slide 66 text

論文のまとめ • 新規性 – エンドユーザのメトリックを導入したセントラライズドなSDNはいままでなかった • 特徴 – 保守的動作(fail safe)、部分的導入、相互運用性、プログラマビリティ、試験のしやすさ • 達成 – グローバルトラフィック最適化、End-to-End のQoE 向上、開発スピードの向上、コストダウン

Slide 67

Slide 67 text

読者視点のまとめ • コストダウンとはいえ、既存のReverse Proxy の余剰計算リソースの活用による効果 • Googleの規模感(複数PoP、ピア)がないと、”グローバル最適化”の旨味がない • Host の Packet Processor のプログラミングの詳細については、論文では明らかにされていない • BGP機能の分離やACLの外部化など、アーキテクチャ設計のヒントになる要素は散りばめられている • ISPの視点では、制御方法の内情が明らかになったので、対Googleの運用のヒントになるのでは • Google でも人為ミスはする

Slide 68

Slide 68 text

FAQ • Espressoピアは見分けられますか？ – 経験はないですが、対向のMACアドレスを見たり、 BGPのOPENメッセージなどの特徴を見ればわかるかもしれません。 • TEはどのようなロジックなのでしょうか。ISP側からコントロールすることはできないでしょうか？ – TEのロジックは外部からはわかりません – ISP側からも品質を測定することで想定外のOverflow を指摘するといったことは可能かもしれません