9月27日に開催されたLINE Developer meetup #45 in Kyoto での登壇資料です

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
海外拠点で導⼊検討中のユースケース