大規模サービスを支えるネットワークインフラの全貌
95 likes22,914 views
9月27日に開催されたLINE Developer meetup #45 in Kyoto での登壇資料です
![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
ネットワークの変遷
性能・拡張性・運⽤の限界
新しいアーキテクチャが必要](https://image.slidesharecdn.com/linedm45networkforlinekobayashi-180927100054/85/-6-320.jpg)
大規模サービスを支えるネットワークインフラの全貌
- 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
- 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
- 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サーバを配置する要件
- 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!
- 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 海外拠点で導⼊検討中のユースケース