大規模サービスを支えるネットワークインフラの全貌

1. Masayuki Kobayashi LINE Corporation masayuki.kobayashi at linecorp.com NETWORK FOR : ⼤規模サービスを⽀えるネットワークインフラの全貌 LINE Developer Meetup #45 in Kyoto - 2018/09/27

2. Introduction • ⼩林正幸 / Masayuki Kobayashi • LINE株式会社 – IT Service Center – Network dept - Service Network Team • Network Engineer – LINEのプロダクションネットワーク全般の設計・構築 – Peering coordinator@AS38631

3. Agenda • Data Center Network Architecture – L2-Less, BGP Only Design • Data Center Interconnect – Segment Routing Backbone • Next Challenge

4. LINEのネットワーク Data CenterBackbone / DCIPeering EdgeInternetUser ⾃前で設計・構築・運⽤

5. ネットワークを設計する上で必要なこと 1. 膨⼤なトラフィックを処理できるか – Tbps級のサーバ間通信トラフィック – 地理的に分散した複数のDCを⼀つに⾒せる 2. 簡単かつ迅速にスケールアウトできるか – シンプルで、繰り返し可能なアーキテクチャ – Cloud Native時代の展開スピード 3. 安定した運⽤ができるか – Failure domain ≒ L2 domainの最⼩化 – 機器が壊れることを前提としたN+1の設計

6. What’s Next? 2018~ JANOG39 LINEのインフラを運⽤して⾒えてきた課題(Japanese) [Blog] https://engineering.linecorp.com/ja/blog/detail/135 [PDF] https://www.janog.gr.jp/meeting/janog39/application/files/9714/8609/7135/JANOG39_LINE.pdf ネットワークの変遷性能・拡張性・運⽤の限界新しいアーキテクチャが必要

7. 何が問題だったのか 1. 性能：⾼いオーバーサブスクリプションレート – 現在のトラフィック量に対してネットワークがボトルネックに – 同⼀PoD内にHadoopサーバーを配置する要件 2. 拡張性：スケールアップが必要な2N構成 – ⽚⽅の機器障害で、キャパシティが半減 – 簡単にスケールアウトできるネットワークが必要 3. 運⽤：L2ネットワークの運⽤はもう嫌だった – L2はその仕様上、⼤きくなるほど運⽤負荷が⾼くなる Ø BUM Traffic, VLAN管理 Ø Large L2 domain ≒ Large failure domain

8. L2-LESS BGP ONLY DATA CENTER

9. S3 S2 S1 Server A B rack cluster A B rack cluster cluster cluster cluster cluster cluster A B rack cluster A B rack ・・・・・・・・・・・・・・・・・・・・ 10G 100G 100G E1 Data Center Network Overview cluster BB PE InternetGlobal Network FW NAT 100G Data Center 基本構成

10. S3 S2 S1 Server A B rack cluster A B rack cluster cluster cluster cluster cluster cluster A B rack cluster A B rack ・・・・・・・・・・・・・・・・・・・・ 10G 100G 100G E1 Data Center Network Overview cluster BB PE InternetGlobal Network FW NAT 100G Data Center Tbps級のサーバ間通信 East-West Traffic 数百Gbps DCI Traffic & Internet Traffic トラフィックパターン User

11. Tbpsを捌くLINEのネットワークアーキテクチャ CLOS-style, Similar to RFC7938 S3 S2 S1 =ToR A B rack cluster A B rack cluster cluster cluster cluster cluster cluster A B rack cluster A B rack ・・・・・・・・・・・・・・・・・・・・ S = Stratum E1 cluster E = External Switches Servers

12. PoD S1: Top of Rack Switches S3: Top of Spine Switches

13. S3 ServerS2 S1S2S1Server 5-stage CLOS network (Unfolded) AB rack AB rack AB rack ・・・・・ AB rack ・・・・・・・・・・・・・・・最も離れたラックのサーバ間通信も最大5ノード経由すれば到達できる

14. サーバ間通信にボトルネックが発⽣しない設計 S3 S2 S1 SV A B rack cluster A B rack cluster cluster cluster cluster cluster cluster A B rack cluster A B rack ・・・・・・・・・・・・・・・・・・・・ E1 cluster Top of Rack(ToR)：サーバ48台を接続、1ラックにつき2台で冗⻑ Uplinkは100G x 4port, 2台で最⼤800G ToRを収容, 上下帯域はノンブロッキング：クラスタ内のノード数は4で固定(S1のUplink数) クラスタ数はS1の数(ラック数)で決定最も離れたラック間の通信を処理：クラスタの数は4で固定クラスタ内のノード数は、S2のクラスタ数で決定外部との通信を処理：インターネット、他のDC宛の通信など PoD内で完結する通信はここに到達しない便宜上”クラスタ”と呼んでいるが、クラスタ(同じ階層)の機器同⼠は接続しない。 10G 100G 100G 100G 100G

15. すべての階層でスケールアウト可能なN+1構成 S3 S2 S1 Server A B rack cluster A B rack cluster cluster cluster cluster cluster cluster A B rack cluster A B rack ・・・・・・・・・・・・・・・・・・・・ E1 cluster cluster cluster A B rack A B rack ノード追加クラスタ追加ラック追加リンク追加単⼀故障時の縮退率が⼩さくなる

16. ↑ スイッチ専⽤のラック列(すべて100G) 32port x 100Gのホワイトボックススイッチを採⽤電源投⼊後はほぼ⾃動でネットワークに復帰(ZTP + Ansible)

17. S3 S2 S1 SV A B rack cluster A B rack cluster cluster cluster cluster cluster cluster A B rack cluster A B rack ・・・・・・・・・・・・・・・・・・・・ E1 cluster Goodbye, L2 Extension! サーバからインターネットまでBGP⼀つ ü すべての機器をEBGP接続サービストラフィックを扱う機器すべて 10G 100G 100G 100G 100G EBGP Underlay ü サーバに直接BGPを喋らせる ToRの切替時にトラフィックロスがゼロ ü DC内からL2ドメインを排除 LAG無し、L2オーバーレイ無し、L3のみ ü 4-byte Private ASNを利⽤ Loopback IPから⼀意に算出、管理不要 ü P2Pリンクにアドレスを付けない RFC5549 BGP Unnumbered

18. なぜBGPを採⽤したのか 1. ⼤規模環境で利⽤しやすい – 標準化され使い慣れているプロトコル – IGP(IS-IS, OSPF)はフラッディングメカニズムがスケールの障壁に 2. 経路制御がしやすい – ECMPやAnycastに加えて、迂回や経路フィルタが簡単 – IBGPはその仕様上の制約が多いためEBGPを選択 3. BGPは任意の情報を広報できる – 将来的なAFI(SAFI)/NLRI拡張技術への対応可能性 • 例: Advertising Segment Routing Policies in BGP

19. BGPによるトラフィック制御 S3 S2 S1 =ToR Server A B rack cluster A B rack cluster cluster cluster cluster cluster cluster A B rack cluster A B rack ・・・・・・・・・・・・・・・・・・・・ E1cluster BB PE Internet Global Network FW NAT 10G 100G 100G 100G ECMP Load-Balancing NAT & FW: VRF-Redirect 特定の送信元/宛先IPの通信を専⽤機器宛に捻じ曲げる DC内トラフィックはすべてロードバランシング BGPパス属性が等コスト(Multipath-Relax)

20. BGP Onlyにしたことによるメリット S3 S2 S1 =ToR Server A B rack cluster A B rack cluster cluster cluster cluster cluster cluster A B rack cluster A B rack ・・・・・・・・・・・・・・・・・・・・ E1cluster BB PE Internet Global Network FW NAT 10G 100G 100G 100G 4. BUM Trafficの範囲を極⼩化: • Failure domainの最⼩化 • VLAN管理からの解放 1. メンテナンス性の向上: • ベンダ依存のプロトコルの排除 • 特定の機器のIsolateが簡単(AS-PATH Prepend) • BFDが不要(Interface down = BGP down) 3. モビリティの向上: VMをどこにでも移動できる 2. 設定の⾃動化: • 個別のパラメータが少ない • BGPの設定を共通化

21. 運⽤⾃動化しやすいBGP設定フォーマットを採⽤ router bgp 4215270229 bgp bestpath as-path multipath-relax bgp router-id 10.233.1.85 bgp max-med on-startup 60 neighbor 10.1.1.1 remote-as 4212364501 neighbor 10.2.2.2 remote-as 4210184442 ... neighbor 10.20.20.20 remote-as 4210966516 router bgp 4215270229 bgp bestpath as-path multipath-relax bgp router-id 10.233.1.85 bgp max-med on-startup 60 neighbor swp1 remote-as external neighbor swp2 remote-as external ... neighbor swp32 remote-as external ⼀般的なBGP設定機器ごとにユニークなパラメータ Unique Unique ü I/FでBGPを有効化 → NeighborのAS番号とIPの指定が不要 ü BGP OPEN MessageのAS番号チェックを緩和(RFC4271違反) ü 個別のパラメータを最⼩限にすることで、設定をテンプレート化 ü サーバとネットワーク機器で共通のオペレーションが可能 LINEで採⽤しているBGP設定(FRR) すべての機器で共通 ASNはrouter-idから⾃動算出

22. 運⽤ S3から⾒たBGP Neighbor • BGPでhostnameを渡す • オペレーターに優しい • LLDPと合わせてトポロジ作成 S1で⾒た経路情報(左:BGPデーモン, 右:Linux Kernel) • /32はサーバのIP • IPv4経路のNext-hopはIPv6 LLA(左) • ダミーIP(169.254.0.1)を経由してカーネルにインストール(右) • 対向のLLAからMACアドレスを割り出しネイバーエントリ作成実際の経路情報

23. 経路フィルタの⾃動制御 • Web UI上でサーバにIPをリクエストした時点で、割り当てと広報が開始 – 設定ミス等で意図しないトラフィックの誘引(ハイジャック)が起きる可能性 • ToRに経路フィルタを設定、許可されたIPのみ⾃動でフィルタ開放 – Controllerが隣接関係情報から対象のToRを特定し、定期的にAnsible実⾏ BareMetal Server hostname: line ToR Switch A BareMetal Controller Network Controller Topology Controller Ansible RabbitMQ Server User 1. Request IP (Web UI) 2. Call filter API 2’. Assign IP: 203.0.113.100 3. Query peer info {hostname:line} 4. Response switch info {hostname:switch A} 5. Update filter data {hostname:switch A, filter-in:203.0.113.100} 6. Add Ansible task {hostname:switch A} 8. Update filter 7. Slack notify

24. 国内拠点事例1 S3 S2 S1 Server A B rack cluster A B rack cluster cluster cluster cluster cluster cluster A B rack cluster A B rack ・・・・・・・・・・・・・・・ E1 cluster 6,720台 280台 56台 20台 4台 100G x 2 links x 5 switches x 4 clusters 4,000 G (6%) 67,200 G (100%) 10G x 48 servers x 140 racks Server Uplink 56,000 G (83.3%) 100G x 4 links x 140 racks S1 Uplink 56,000 G (83.3%) 100G x 10 links x 4 switches x 14 clusters S2 Uplink 140 Racks 14 clusters 4 clusters DR-Site, 同⼀PoD内にHadoopサーバを配置する要件

25. 国内拠点事例2 プロダクションネットワーク, ホワイトボックススイッチ948台

26. DATA CENTER INTERCONNECT

27. SEGMENT ROUTING MPLS 複数のDCを⼀つに⾒せるネットワーク Data Center Site 2 Data Center Site 1Data Center Interconnect EBGP EBGP Underlay BGP Underlay BGPMP-BGP w/ SR 各DCの内部構成を隠蔽する低遅延な共有転送基盤 L3 Reachability DC間を異経路冗⻑の回線で接続

28. セグメントルーティングの導⼊障害のサービス影響を最⼩限にするトランスポート Data Center Interconnect Payload Payload PayloadPayloadPayload VPN Label SR Label VPN Label SR Label VPN Label サーバ間通信ユーザ向け通信 Traffic Engineering SR Label 障害発⽣迂回経路⽤ Adj-SID Label 宛先ノード⽤ Prefix-SID Label 通信識別⽤ Label 迂回経路 TI-LFA SID:16103 SID:16104 SID:16101 SID:16102 Data Center Site 2 Data Center Site 1 ユーザ向けと内部向けで通信を分離各拠点でAS番号を再利⽤可能重要な通信をクラシファイ

29. なぜセグメントルーティングを採⽤したのか 1. 使い慣れたMPLSをデータプレーンに利⽤できる – 拠点間のVPN通信にMPLSのラベルスタックが必要 • シンプルなVPNサービストランスポートとしての役割 – Segment-ID(SID)をIGPで広報するだけで動く 2. シグナリングプロトコルを排除できる – 今後の拡張を考えると、Hop-by-Hopのステート設定は排除したい – Binding SIDの有効活⽤に期待 3. TI-LFA FRR & SR-Policyが利⽤できる – ファイバカットなどの障害の影響を最⼩限にする – Prefixごとの回線使⽤⽐率調整など(未導⼊)

30. まとめ 1. 膨⼤なトラフィックを処理できるか ü サーバ間通信に対してノンブロッキングになるように設計 ü ⾼密度100Gスイッチの採⽤ ü 低遅延・広帯域の回線でDC同⼠を接続 2. 簡単かつ迅速にスケールアウトできるか ü CLOSネットワーク化によりスケールアウトが容易に ü ホワイトボックススイッチの⾃動化で展開スピードが向上 3. 安定した運⽤ができるか ü L2を作らない ü 機器が壊れても影響の少ないN+1冗⻑ ü シンプルな制御のバックボーンネットワーク

31. 最後に • もっと詳しい話は懇親会で! • 技術的な意⾒交換会なども⼤歓迎です • We are hiring – Tokyo: https://linecorp.com/ja/career/position/229

32. THANK YOU!

33. APPENDIX: DESIGN THE FUTURE NETWORK OUR NEXT CHALLENGE

34. これからのLINEのネットワークサービス開始 • Single PoD • Vender Lock-in • Hardware LB 急拡⼤期 • Multi PoD • Vender Lock-in • Hardware LB 安定運⽤期 • Fabric network • L2-less underlay • Disaggregation • Software LB Next Level • Programable Data Plane • NFV • Service Chaining ⼀般的なネットワーク機器だけでは実現できない領域へコモディティ化した機器で構築していたネットワーク標準化され枯れたプロトコル&頻出のユースケース Phase 1 Phase 2 Phase 3 Phase 4 今ここ LINEが求めるデータプレーンとコントロールプレーン実装⼀般的なネットワーク機器と適材適所で組み合わせて運⽤

35. SRv6 Overlay VPN & Service Chaining Segment Routing IPv6 Data Center Server = SRv6 Strategic Node BGP CLOS Underlay = Packet Transit Node BGP CLOS Edge = SRv6 Endpoint Node Tenant #1 Production Tenant #2 Development Tenant #3 Load Balancer LB VRF Target Network 検証中 END.DX4 VRF VRF ü 転送処理に徹底したDCアンダーレイ ü ルーティングヘッダによるサービスオーバーレイ ü Unified Data Plane IPv6 Underlay Stateless, Pure IP ECMP FW 海外拠点で導⼊検討中のユースケース