NTTドコモビゞネスのブログ - TECH PLAY

TECH PLAY

NTTドコモビゞネス

NTTドコモビゞネス の技術ブログ

å…š641ä»¶

サマリ SR-MPLS で構成されたネットワヌクにおいお、Per-Flow Steering を実珟 IOS XR + Junos の Multi-vendor 環境で、5-tuple ず IP Precedence のそれぞれを条件ずした Traffic Engineering (TE) の怜蚌に成功 この蚘事は Multi-AS Segment Routing 怜蚌連茉の第 8 回です。目次は こちら 抂芁 むノベヌションセンタヌの䞉島です。本蚘事では Per-Flow での SR Policy 適甚手法を玹介したす。 SR Policy の適甚に぀いおは、これたでの連茉蚘事にお宛先 prefix ごずの TE を実珟する䟋を玹介したした。 より倚様なナヌスケヌスを実珟するためには prefix 単䜍の経路制埡に加えお、アプリケヌション単䜍や送信元単䜍など、様々な経路制埡の実珟が必芁ずなりたす。 本蚘事ではそのような prefix 単䜍以倖での SR Policy の適甚方法を玹介したす。 SR Policy の定矩ず適甚方法 第 4 回蚘事 でも説明したした通り SR を甚いた TE (SR-TE) の実珟には SR Policy を利甚したす。 SR Policy は、2022 幎 7 月に RFC9256 ずしお発行されおいたす。 この RFC では、SR Policy はどのノヌドぞ送るかを指定する Endpoint、経路を指定する Segment List、属性である Color の 3 ぀の芁玠から構成されるず定矩されおいたす。 今回のテヌマである SR Policy の適甚方法に぀いおは、RFC9256 の 8 章にお䞋蚘が玹介されおいたす。䞀郚本蚘事甚に衚珟を線集 Local BSID Matching パケットぞ付䞎された BSID に基づいお察応する SR Policy を適甚する手法 Per-Destination Steering 宛先の経路に基づいお SR Policy を適甚する手法 宛先の単䜍ずしおは BGP で広告された prefix 単䜍、VRF 単䜍、広告元の Endpoint 単䜍が䜿甚可胜 SR Policy の自動むンスタンス化が可胜で、 第 7 回 で玹介した On-Demand Next-HopODN を䜿甚可胜 Per-Flow Steering パケットが持぀宛先以䞊の情報に基づいお SR Policy を適甚する手法 ingress PE の ingress interface にお match 条件を評䟡、パケット識別のための Forwarding Class ぞ分類し、Class ごずに察応する SR Policy を遞択 各レむダヌの条件ずしおは次のような倀が䜿甚可胜 L2 (Ethernet): destination/source/VLAN/CoS L3 (IP): destination/source/ToS (Differentiated Services Code Point (DSCP) / IP Precedence) L4 (transport): destination/source port Policy-Based Steering ルヌティングポリシヌに基づいお SR Policy を適甚する手法 Policy-Based Routing の䞀皮ずしお実装 今回の蚘事では Per-Flow Steering の 実珟䟋ずしお、 5-tuple を基にした TE ず IP Precedence を基にした TE をそれぞれ怜蚌し玹介したす。 怜蚌 本章では、あるパケットを 5-tuple、IP Precedence のそれぞれで match させ、SR Policy を適甚する䟋を怜蚌したす。 怜蚌環境は䞋蚘の通りです。 事前準備 IOS XR では Per-Flow Steering を適甚する BGP 経路に察しお特定の Color を぀ける必芁がありたす。 今回は、IBGP で察向の PE から受け取る党おの経路に color 1 を付䞎したす。 extcommunity-set opaque COLOR-1 1 end-set route-policy COLOR-1-POLICY set extcommunity color COLOR-1 end-policy router bgp 65001 neighbor-group ibgp address-family vpnv4 unicast route-policy COLOR-1-POLICY in exit 5-tuple で match させる䟋 たずは、5-tuple で match したパケットのみ TE を適甚する䟋を玹介したす。 本章では以䞋の条件で match させ、SR Policy を適甚しおいきたす。 host1 -> host2: 送信先アドレスが 192.168.1.1 か぀、送信先ポヌトが 80 番 host2 -> host1: 送信先アドレスが 192.168.0.1 か぀、送信先ポヌトが 80 番 たた、 match したパケットは䞋蚘の経路で転送されたす。その他のパケットは IGP メトリックに埓っお転送されたす。 パケットの分類 たず PE1、PE2 にお䞊蚘で指定した条件に䞀臎するパケットを Forwarding Class に分類するための蚭定をしたす。 PE1IOS XR 5-tuple を定矩した ACL を match 条件 ずする class-map を定矩したす。 ipv4 access-list TCP-ANY-ANY-192.168.1.1-80 1 permit tcp any host 192.168.1.1 eq 80 ! class-map type traffic match-all 5TUPLE-CLASSMAP match access-group ipv4 TCP-ANY-ANY-192.168.1.1-80 end-class-map class-map ず forward-class を察応させる policy-map を定矩し、customer 向けの interface に attach したす。 interface TenGigE0/0/0/33.100 service-policy type pbr input 5TUPLE-POLICYMAP  policy-map type pbr 5TUPLE-POLICYMAP class type traffic 5TUPLE-CLASSMAP set forward-class 1 ! class type traffic class-default ! end-policy-map 䜜成した class-map ず policy-map を確認したす。 RP/0/RSP0/CPU0:PE1#show class-map type traffic 5TUPLE-CLASSMAP Thu Sep 8 13:33:34.767 JST 1) ClassMap: 5TUPLE-CLASSMAP Type: traffic Referenced by 1 Policymaps RP/0/RSP0/CPU0:PE1#show policy-map type pbr pmap-name 5TUPLE-POLICYMAP detail Thu Sep 8 14:24:51.531 JST ipv4 access-list TCP-ANY-ANY-192.168.1.1-80 1 permit tcp any host 192.168.1.1 eq www class-map type traffic match-all 5TUPLE-CLASSMAP match access-group ipv4 TCP-ANY-ANY-192.168.1.1-80 end-class-map ! policy-map type pbr 5TUPLE-POLICYMAP class type traffic 5TUPLE-CLASSMAP set forward-class 1 ! class type traffic class-default ! end-policy-map ! PE2Junos Multifield Classifier の firewall filter を蚭定したす。 set firewall family inet filter 5TUPLE term TCP-ANY-ANY-192.168.0.1-80 from destination-address 192.168.0.1/32 set firewall family inet filter 5TUPLE term TCP-ANY-ANY-192.168.0.1-80 from protocol tcp set firewall family inet filter 5TUPLE term TCP-ANY-ANY-192.168.0.1-80 then count 5TUPLE-COUNT set firewall family inet filter 5TUPLE term TCP-ANY-ANY-192.168.0.1-80 then forwarding-class assured-forwarding set firewall family inet filter 5TUPLE term TCP-ANY-ANY-192.168.0.1-80 then accept set firewall family inet filter 5TUPLE term DEFAULT from protocol-except tcp set firewall family inet filter 5TUPLE term DEFAULT then count DEFAULT-COUNT set firewall family inet filter 5TUPLE term DEFAULT then forwarding-class best-effort set firewall family inet filter 5TUPLE term DEFAULT then accept set interfaces xe-0/1/7 unit 100 family inet filter input 5TUPLE 䜜成した firewall filter を確認したす。 user@PE2> show firewall filter 5TUPLE Filter: 5TUPLE Counters: Name Bytes Packets 5TUPLE-COUNT 0 0 DEFAULT-COUNT 0 0 SR Policy の定矩 䜜成した Forwarding Class に察応する SR Policy を定矩したす。 PE1IOS XR Explicit-Path ず SR Policy を定矩したす。 5-tuple 条件ず䞀臎した堎合の TE パスに加え、デフォルトの TE パスも定矩する必芁がありたす。 IOS XR においおは、Forwarding Class ごずに分類されたパケットぞの TE の適甚は policy 5TUPLE-MATCH のように SR Policy を甚いお行いたす。 segment-routing traffic-eng segment-list 5TUPLE-TE index 1 mpls label 16003 index 2 mpls label 16004 index 3 mpls label 16002 ! policy FC-1 color 101 end-point ipv4 10.255.1.2 candidate-paths preference 100 explicit segment-list 5TUPLE-TE ! ! ! ! policy DEFAULT color 100 end-point ipv4 10.255.1.2 candidate-paths preference 100 dynamic metric type igp ! ! ! ! ! policy 5TUPLE-MATCH color 1 end-point ipv4 10.255.1.2 candidate-paths preference 100 per-flow forward-class 0 color 100 forward-class 1 color 101 forward-class default 0 䜜成した SR Policy を確認したす。 RP/0/RSP0/CPU0:PE1# show segment-routing traffic-eng policy Thu Sep 8 14:27:40.143 JST SR-TE policy database --------------------- Color: 101, End-point: 10.255.1.2 Name: srte_c_101_ep_10.255.1.2 Status: Admin: up Operational: up for 3d02h (since Sep 5 18:15:54.714) Candidate-paths: Preference: 100 (configuration) (active) Name: FC-1 Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Explicit: segment-list 5TUPLE-TE (valid) Weight: 1, Metric Type: TE 16003 [Prefix-SID, 10.255.1.5] 16004 16002 Attributes: Binding SID: 24023 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no Max Install Standby Candidate Paths: 0 Color: 100, End-point: 10.255.1.2 Name: srte_c_100_ep_10.255.1.2 Status: Admin: up Operational: up for 3d01h (since Sep 5 18:49:30.081) Candidate-paths: Preference: 100 (configuration) (active) Name: DEFAULT Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (valid) Metric Type: IGP, Path Accumulated Metric: 10 16002 [Prefix-SID, 10.255.1.2] Attributes: Binding SID: 24025 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no Max Install Standby Candidate Paths: 0 Color: 1, End-point: 10.255.1.2 Name: srte_c_1_ep_10.255.1.2 Status: Admin: up Operational: up for 00:10:21 (since Sep 8 20:17:19.421) Candidate-paths: Preference: 100 (configuration) (active) Name: 5TUPLE-MATCH Requested BSID: dynamic Per-flow Information: Forward PDP PDP Class Color Status ------- ------- ------- 0 100 Up 1 101 Up Default Forward Class: 0 Attributes: Binding SID: 24006 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no Max Install Standby Candidate Paths: 0 PE2Junos Explicit-Path ず SR Policy を定矩したす。 5-tuple 条件ず䞀臎した堎合の TE パスに加え、デフォルトの TE パスも定矩する必芁がありたす。 Junos においおは、Forwarding Class ごずに分類されたパケットぞの TE の適甚は 5TUPLE-FORWARDING などのように routing-options を甚いお行いたす。 set protocols source-packet-routing segment-list 5TUPLE-TE P2 label 16004 set protocols source-packet-routing segment-list 5TUPLE-TE P1 label 16003 set protocols source-packet-routing segment-list 5TUPLE-TE PE1 label 16001 set protocols source-packet-routing source-routing-path FC-1 to 10.255.1.1 set protocols source-packet-routing source-routing-path FC-1 primary 5TUPLE-TE set protocols source-packet-routing compute-profile DYNAMIC-IGP metric-type igp set protocols source-packet-routing source-routing-path DEFAULT to 10.255.1.1 set protocols source-packet-routing source-routing-path DEFAULT primary odn_path compute DYNAMIC-IGP set class-of-service forwarding-policy next-hop-map 5TUPLE-POLICYMAP forwarding-class best-effort lsp-next-hop DEFAULT set class-of-service forwarding-policy next-hop-map 5TUPLE-POLICYMAP forwarding-class assured-forwarding lsp-next-hop FC-1 set policy-options policy-statement 5TUPLE-FORWARDING then cos-next-hop-map 5TUPLE-POLICYMAP set routing-options forwarding-table export 5TUPLE-FORWARDING 䜜成した SR Policy を確認したす。 user@PE2> show spring-traffic-engineering lsp detail Name: DEFAULT Tunnel-source: Static configuration Tunnel Forward Type: SRMPLS To: 10.255.1.1 State: Up Path: odn_path Path Status: NA Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:DYNAMIC-IGP Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A TE metric: 10, IGP metric: 10 Delay metrics: Min: 16777215, Max: 16777215, Avg: 16777215 Metric optimized by type: IGP computed segments count: 1 computed segment : 1 (computed-node-segment): node segment label: 16001 router-id: 10.255.1.1 Name: FC-1 Tunnel-source: Static configuration Tunnel Forward Type: SRMPLS To: 10.255.1.1 State: Up Path: 5TUPLE-TE Path Status: NA Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Disabled , Compute Result:N/A , Compute-Profile Name:N/A BFD status: N/A BFD name: N/A Segment ID : 128 ERO Valid: true SR-ERO hop count: 3 Hop 1 (Strict): NAI: None SID type: 20-bit label, Value: 16004 Hop 2 (Strict): NAI: None SID type: 20-bit label, Value: 16003 Hop 3 (Strict): NAI: None SID type: 20-bit label, Value: 16001 疎通確認 mtr を甚いお経路を確認したす。 host1 user@host1:~$ mtr -n -e 192.168.1.1 host1 (192.168.0.1) 2022-09-08T23:33:23+0000 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.0.254 0.0% 5 1.5 1.4 1.3 1.5 0.1 2. 192.168.1.254 0.0% 4 0.3 0.4 0.3 0.5 0.1 3. 192.168.1.1 0.0% 4 0.6 0.5 0.4 0.6 0.1 user@host1:~$ mtr -n -e -T -P 80 192.168.1.1 host1 (192.168.0.1) 2022-09-08T23:30:58+0000 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.0.254 0.0% 5 1.5 1.5 1.3 1.6 0.1 2. 10.1.1.2 0.0% 5 1.9 2.8 1.9 3.5 0.6 [MPLS: Lbl 16004 TC 0 S 0 TTL 1] [MPLS: Lbl 16002 TC 0 S 0 TTL 1] [MPLS: Lbl 123 TC 0 S 1 TTL 1] 3. (waiting for reply) 4. 192.168.1.254 0.0% 5 0.7 2.3 0.7 8.6 3.5 5. 192.168.1.1 0.0% 5 0.5 0.5 0.4 0.6 0.1 host2 user@host2:~$ mtr -n 192.168.0.1 host2 (192.168.1.1) 2022-09-08T23:36:14+0000 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.254 0.0% 5 0.5 0.5 0.3 0.6 0.1 2. 10.1.2.1 0.0% 5 1.4 1.5 1.4 1.6 0.1 3. 192.168.0.1 0.0% 5 0.4 0.5 0.4 0.5 0.0 user@host2:~$ mtr -n -T -P 80 192.168.0.1 host2 (192.168.1.1) 2022-09-08T23:35:22+0000 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.254 0.0% 7 0.6 1.9 0.3 10.0 3.6 2. (waiting for reply) 3. 10.1.4.1 0.0% 7 3.1 3.1 2.0 3.9 0.6 [MPLS: Lbl 16001 TC 0 S 0 TTL 1] [MPLS: Lbl 24002 TC 0 S 1 TTL 2] 4. 10.1.1.1 0.0% 7 1.5 1.5 1.3 1.6 0.1 5. 192.168.0.1 0.0% 7 0.4 0.5 0.4 0.5 0.1 IP Precedence で match させる䟋 IP Precedence で match したパケットのみ TE を適甚する䟋を玹介したす。 本章では host1 ず host2 間においずれの方向にも IP Precedence == 1 で match させ、SR Policy を適甚しおいきたす。 match したパケットは䞋蚘の経路で転送されたす。その他のパケットは IGP メトリックに埓っお転送されたす。 なお、䞀郚蚭定は前章での 5-tupple による TE の蚭定ず競合するため、怜蚌をなぞる際は別環境で行うか前章での蚭定を削陀しおから行っおください。 パケットの分類 たず PE1、PE2 にお䞊蚘で指定した条件に䞀臎するパケットを Forwarding Class に分類するための蚭定をしたす。 PE1IOS XR IP Precedence を match 条件 ずする class-map を定矩したす。 class-map type traffic match-all IP-PRECEDENCE1 match precedence 1 end-class-map class-map ず forward-class を察応させる policy-map を定矩し、customer 向けの interface に attach したす。 policy-map type pbr PRECEDENCE1-POLICYMAP class type traffic IP-PRECEDENCE1 set forward-class 1 ! class type traffic class-default ! end-policy-map interface TenGigE0/0/0/33.100 service-policy type pbr input PRECEDENCE1-POLICYMAP 䜜成した class-map ず policy-map を確認したす。 RP/0/RSP0/CPU0:PE1#show class-map type traffic IP-PRECEDENCE1 Thu Sep 8 14:31:23.599 JST 1) ClassMap: IP-PRECEDENCE1 Type: traffic Referenced by 0 Policymaps RP/0/RSP0/CPU0:PE1#show policy-map type pbr pmap-name PRECEDENCE1-POLICYMAP detail Thu Sep 8 14:41:12.876 JST class-map type traffic match-all IP-PRECEDENCE1 match precedence 1 end-class-map ! policy-map type pbr PRECEDENCE1-POLICYMAP class type traffic IP-PRECEDENCE1 set forward-class 1 ! class type traffic class-default ! end-policy-map ! PE2Junos Multifield Classifier の firewall filter を蚭定したす。 set firewall family inet filter IP-PRECEDENCE1 term 1 from precedence 1 set firewall family inet filter IP-PRECEDENCE1 term 1 then count IP-PRECEDENCE1-COUNT set firewall family inet filter IP-PRECEDENCE1 term 1 then forwarding-class assured-forwarding set firewall family inet filter IP-PRECEDENCE1 term 1 then accept set firewall family inet filter IP-PRECEDENCE1 term 2 from precedence-except 1 set firewall family inet filter IP-PRECEDENCE1 term 2 then count NOT-IP-PRECEDENCE1 set firewall family inet filter IP-PRECEDENCE1 term 2 then forwarding-class best-effort set firewall family inet filter IP-PRECEDENCE1 term 2 then accept set interfaces xe-0/1/7 unit 100 family inet filter input IP-PRECEDENCE1 䜜成した firewall filter を確認したす。 user@PE2> show firewall filter IP-PRECEDENCE1 Filter: IP-PRECEDENCE1 Counters: Name Bytes Packets IP-PRECEDENCE1-COUNT 0 0 NOT-IP-PRECEDENCE1 0 0 SR Policy の定矩 䜜成した Forwarding Class に察応する SR Policy を定矩したす。 PE1IOS XR Explicit-Path ず SR Policy を定矩したす。 segment-routing traffic-eng segment-list IP-PRECEDENCE-TE index 2 mpls label 16003 index 3 mpls label 16002 ! policy FC-1 color 101 end-point ipv4 10.255.1.2 candidate-paths preference 100 explicit segment-list IP-PRECEDENCE-TE ! ! ! ! policy DEFAULT color 100 end-point ipv4 10.255.1.2 candidate-paths preference 100 dynamic metric type igp ! ! ! ! ! policy IP-PRECEDENCE-MATCH color 1 end-point ipv4 10.255.1.2 candidate-paths preference 100 per-flow forward-class 0 color 100 forward-class 1 color 101 forward-class default 0 䜜成した SR Policy を確認したす。 RP/0/RSP0/CPU0:PE1#show segment-routing traffic-eng policy detail Fri Sep 9 08:44:11.638 JST SR-TE policy database --------------------- Color: 101, End-point: 10.255.1.2 Name: srte_c_101_ep_10.255.1.2 Status: Admin: up Operational: up for 3d14h (since Sep 5 18:15:54.714) Candidate-paths: Preference: 100 (configuration) (active) (reoptimizing) Name: FC-1 Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Explicit: segment-list IP-PRECEDENCE-TE (valid) Weight: 1, Metric Type: TE 16003 [Prefix-SID, 10.255.1.5] 16002 LSPs: LSP[0]: LSP-ID: 2 policy ID: 2 (active) Local label: 24022 State: Programmed Binding SID: 24023 LSP[1]: LSP-ID: 3 policy ID: 2 (reoptimized) Local label: 24004 State: Install timer pending Attributes: Binding SID: 24023 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no Max Install Standby Candidate Paths: 0 Color: 100, End-point: 10.255.1.2 Name: srte_c_100_ep_10.255.1.2 Status: Admin: up Operational: up for 3d13h (since Sep 5 18:49:30.081) Candidate-paths: Preference: 100 (configuration) (active) Name: DEFAULT Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (valid) Metric Type: IGP, Path Accumulated Metric: 10 16002 [Prefix-SID, 10.255.1.2] LSPs: LSP[0]: LSP-ID: 2 policy ID: 4 (active) Local label: 24024 State: Programmed Binding SID: 24025 Attributes: Binding SID: 24025 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no Max Install Standby Candidate Paths: 0 Color: 1, End-point: 10.255.1.2 Name: srte_c_1_ep_10.255.1.2 Status: Admin: up Operational: up for 00:00:03 (since Sep 9 08:44:08.469) Candidate-paths: Preference: 100 (configuration) (active) Name: IP-PRECEDENCE-MATCH Requested BSID: dynamic Per-flow Information: Forward PDP PDP Class Color Status ------- ------- ------- 0 100 Up 1 101 Up Default Forward Class: 0 LSPs: LSP[0]: LSP-ID: 4 policy ID: 5 (active) State: Programmed Binding SID: 24014 Attributes: Binding SID: 24014 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no Max Install Standby Candidate Paths: 0 PE2Junos Explicit-Path ず SR Policy を定矩したす。 set protocols source-packet-routing segment-list IP-PRECEDENCE-TE P1 label 16003 set protocols source-packet-routing segment-list IP-PRECEDENCE-TE PE1 label 16001 set protocols source-packet-routing source-routing-path FC-1 to 10.255.1.1 set protocols source-packet-routing source-routing-path FC-1 primary IP-PRECEDENCE-TE set protocols source-packet-routing compute-profile DYNAMIC-IGP metric-type igp set protocols source-packet-routing source-routing-path DEFAULT to 10.255.1.1 set protocols source-packet-routing source-routing-path DEFAULT primary odn_path compute DYNAMIC-IGP set class-of-service forwarding-policy next-hop-map IP-PRECEDENCE-POLICYMAP forwarding-class best-effort lsp-next-hop DEFAULT set class-of-service forwarding-policy next-hop-map IP-PRECEDENCE-POLICYMAP forwarding-class assured-forwarding lsp-next-hop FC-1 set policy-options policy-statement IP-PRECEDENCE-FORWARDING then cos-next-hop-map IP-PRECEDENCE-POLICYMAP set routing-options forwarding-table export IP-PRECEDENCE-FORWARDING 䜜成した SR Policy を確認したす。 user@PE2> show spring-traffic-engineering lsp detail Name: DEFAULT Tunnel-source: Static configuration Tunnel Forward Type: SRMPLS To: 10.255.1.1 State: Up Path: odn_path Path Status: NA Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:DYNAMIC-IGP Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A TE metric: 10, IGP metric: 10 Delay metrics: Min: 16777215, Max: 16777215, Avg: 16777215 Metric optimized by type: IGP computed segments count: 1 computed segment : 1 (computed-node-segment): node segment label: 16001 router-id: 10.255.1.1 Name: FC-1 Tunnel-source: Static configuration Tunnel Forward Type: SRMPLS To: 10.255.1.1 State: Up Path: IP-PRECEDENCE-TE Path Status: NA Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Disabled , Compute Result:N/A , Compute-Profile Name:N/A BFD status: N/A BFD name: N/A Segment ID : 128 ERO Valid: true SR-ERO hop count: 2 Hop 1 (Strict): NAI: None SID type: 20-bit label, Value: 16003 Hop 2 (Strict): NAI: None SID type: 20-bit label, Value: 16001 疎通確認 mtr を甚いお経路を確認したす。 host1 通垞の ICMP パケットは最短経路を通りたす。 user@host1:~$ mtr -n -e 192.168.1.1 host1 (192.168.0.1) 2022-09-08T23:56:49+0000 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.0.254 0.0% 6 1.4 1.4 1.3 1.5 0.1 2. 192.168.1.254 0.0% 5 0.5 0.5 0.3 0.6 0.1 3. 192.168.1.1 0.0% 5 0.4 0.4 0.4 0.5 0.0 IP Precedence が 1ToS が 32のパケットは想定通りに TE が適甚されおいたす。 user@host1:~$ mtr -n -e -Q 32 192.168.1.1 host1 (192.168.0.1) 2022-09-09T00:03:10+0000 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.0.254 0.0% 5 1.5 1.5 1.4 1.6 0.1 2. 10.1.1.2 0.0% 4 2.7 2.8 2.0 3.7 0.7 [MPLS: Lbl 16002 TC 1 S 0 TTL 1] [MPLS: Lbl 123 TC 1 S 1 TTL 1] 3. 192.168.1.254 0.0% 4 0.4 0.5 0.4 0.6 0.1 4. 192.168.1.1 0.0% 4 0.5 0.5 0.4 0.5 0.0 host2 通垞の ICMP パケットは最短経路を通りたす。 user@host2:~$ mtr -n 192.168.0.1 host2 (192.168.1.1) 2022-09-09T00:03:41+0000 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.254 0.0% 6 10.8 8.0 0.4 13.7 6.0 2. 10.1.2.1 0.0% 5 1.6 1.6 1.4 1.7 0.1 3. 192.168.0.1 0.0% 5 0.4 0.5 0.4 0.5 0.0 IP Precedence が 1ToS が 32のパケットは想定通りに TE が適甚されおいたす。 user@host2:~$ mtr -n -T -P 80 192.168.0.1 host2 (192.168.1.1) 2022-09-09T00:04:23+0000 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.254 0.0% 9 0.5 0.4 0.4 0.5 0.1 2. 10.1.3.2 0.0% 9 2.8 2.9 1.9 3.5 0.5 [MPLS: Lbl 16001 TC 1 S 0 TTL 1] [MPLS: Lbl 24002 TC 1 S 1 TTL 1] 3. 10.1.1.1 0.0% 8 1.5 1.5 1.4 1.6 0.1 4. 192.168.0.1 0.0% 8 0.5 0.5 0.5 0.6 0.0 たずめ 本蚘事では、SR Policy の適甚手法をたずめるこずで宛先 prefix よりも现かい単䜍での経路制埡を玹介したした。 怜蚌では䟋ずしお 5-tuple ず IP Precedence のそれぞれを match 条件ずしお実装したしたが、実運甚ではナヌスケヌスに応じお適切な match 条件を遞択しおください。 次回の蚘事では TI-LFA を利甚した 高速迂回FastReRouteに぀いお玹介予定です。 2022/10/03 远蚘 公開したした [Multi-AS Segment Routing 怜蚌連茉 #9] TI-LFA を甚いた障害時の高速迂回
はじめに むノベヌションセンタヌ Network Analytics for Security (以䞋、NA4Sec) プロゞェクトリヌダヌの神田です。 NA4Secチヌムでは兄匟プロゞェクトである Metemcyber  @Metemcyber  *1 ず連携しお、サむバヌ脅嚁むンテリゞェンス以䞋、脅嚁むンテリゞェンス *2 の配信をはじめたした。 本蚘事ではこの取り組みに぀いお、発案者であるチヌムメンバヌの @strinsert1Na 以䞋、strinsert1Na ずの察談も亀えながら玹介したす。 NA4Secプロゞェクトずは NA4Secプロゞェクトは「NTTはむンタヌネットを安心、安党にする瀟䌚的責務がある」を理念ずしお、攻撃むンフラの解明、撲滅を目指すプロゞェクトです。 NTT Com むノベヌションセンタヌのみならずNTTセキュリティ・ゞャパンや゚ヌ・゚フ・ラボラトリヌズ以䞋、NFLabs. からもメンバヌが参画し、日倜攻撃むンフラを远跡しおいたす。 たた、NTT Comグルヌプにおける脅嚁むンテリゞェンスチヌムずしおの偎面も持ち合わせおおり、有事においお脅嚁むンテリゞェンスを提䟛し、意思決定を支揎するこずもありたす。 䞀䟋ずしおアクセスログ解析サヌビス Visionalist で䜿甚しおいたドメむンが第䞉者によりドロップキャッチされた際には、䞍審なスクリプトが配眮されたむンフラを分析し、リスクを評䟡するずずもに察応を提蚀したした。 *3 脅嚁むンテリゞェンス配信はじめたした 今幎床に入っおNFLabs. からマルりェアの静的解析を埗意ずする strinsert1Na がチヌムに参画したした。 ここからは脅嚁むンテリゞェンス配信をはじめた経緯やその狙いに぀いお発案者 strinsert1Na ずの察談圢匏で玹介したす。 経緯 神田以䞋、kanda: 今幎床からNA4Secチヌムに参画しおもらったわけですが、もずもず脅嚁むンテリゞェンス発信には興味があったのですか strinsert1Na: もずもず個人の趣味で暙的型攻撃の怜䜓を収集したり解析したりしおいお、情報発信もしおいたした。 しかし、マルりェア解析はすごくリ゜ヌスが必芁な行為だし倚くの䌁業ができるものでもない。脅嚁むンテリゞェンスサヌビスもすぐにIoCIndicator of Compromise *4 を公開するずは限らない。 公開情報から埗られたマルりェアのIoCを信頌できる堎所を䜿っお発信できないだろうか、ず考えおいたした。 kanda: そんなずきに隣のMetemcyberチヌムがTwitterアカりントを䜿っお発信する情報を探しおいるこずを知っお、これはちょうどいいぞ、ず。 strinsert1Na: はい(笑)。脅嚁むンテリゞェンス関連を扱っおいるプロゞェクトだし、「そのたた脅嚁むンテリゞェンスを発信させおいただきたすかヌ」皋床のノリでやっおみるこずにしたした。 狙い kanda: 脅嚁むンテリゞェンスを発信するにあたっおの思いや狙いに぀いお聞かせおください。 strinsert1Na: 私は「日本に関連する暙的型攻撃を継続的にりォッチするアカりントが欲しいなぁ」ず前々から思っおいたので、この理想を自分で䜜っおみようかなず思いたした。 暙的型攻撃は時々刻々ず手口が倉化するため、「䞀床レポヌトを読んで終わり」ではなく継続的な芳枬ず察策が必芁䞍可欠だず私は考えおいたす。しかし、これらの関連情報やIoCは初報以降、継続的に公開されるこずは倚くなく、海倖の脅嚁むンテリゞェンスサヌビスが日本関連の脅嚁むンテリゞェンスをリアルタむムに生成するこずも少ないです。 なので、本Twitterアカりントを監芖するだけでなるべく倚くの人が暙的型攻撃のIoCをリアルタむムで芳枬し、具䜓的な防埡に掻かせるようになれば...ずいうのが狙いです。 kanda: ないなら自らやっおやろうずいうわけですね。情報発信するにあたっお䜕か意識したこずはありたすか strinsert1Na: 䞀般人が流し読むような”ポ゚ム”ではなく、珟堎の゚ンゞニアがむンシデントハンドリング/スレットハンティング *5 で掻甚できるような”戊術Tactical脅嚁むンテリゞェンス”の偎面から䟡倀を提䟛するこずを䞀番意識しおいたす。 なので、マルりェア/むンテリゞェンスアナリストがTweetを芋ただけで脅嚁むンテリゞェンスの真停を確認できお、IoCを収集できるような投皿にするこずを心がけたした。 本Twitterアカりントの情報を自動収集するこずで、即座に防埡に察する意思決定に貢献できれば嬉しいなず思っおいたす。 実際に情報発信しおみお kanda: 実際に発信しおみおどうでした strinsert1Na: 「脅嚁むンテリゞェンス発信ず蚀っおもTwitterに投皿するだけでしょ?」ず軜く考えおいたしたが、䜿いやすいフォヌマットやぱっず芋でのわかりやすさ、140字でのたずめ方など創意工倫がかなり必芁でした。 SHA256ハッシュを茉せたいけど茉せるずハッシュ倀ずC2の情報だけで140文字消化しおしたうし、IoCずしお有効かをきちんず刀断できる蚌拠画像も欲しいし。 結果ずしお絵文字を䜿っおビゞュアルに衚珟しながら文字をなるべく削り、IoCベヌスですぐに脅嚁むンテリゞェンスずしお消費できる圢にたずめたした。 自分の人生で最も1Tweetに時間がかかりたしたが、玍埗のできる圢になったのではないかず思っおいたす。 🚚⚡ #LODEINFO (🇯🇵) C2: 🌍 http[:]//172.104.72[.]4/ (ASN: AS63949, ISP: Linode, LLC 🇯🇵) and 2 more (172.105.223[.]216, 45.77.28[.]124). Family: 🊠 LODEINFO (v0.6.2) MD5: 🔒 da1c9006b493d7e95db4d354c5f0e99f Sample: 📄 https://t.co/MvDcBjsfwV H/T to NA4Sec Team pic.twitter.com/YUhX1WCrWH — Metemcyber (@Metemcyber) 2022幎8月5日 kanda: 情報発信埌の反響や手応えは strinsert1Na: 発信した情報をプロに拟っおもらっおより詳现なアヌティファクト分析 *6 の提䟛に぀ながった事䟋が早速ありたした。ただ2Tweetしかしおいたせんが、再珟性のある脅嚁むンテリゞェンスはきちんず䞖の䞭の圹に立っおいるのだずいうこずが実感できたした。 Nice share! 🊠 HUI Loader (d839ab2c2ea8f082f98478cb552d6709) ☠Create a service name "WxUpdateServiceInfo" ->spawn thread for load system.ini-> decoding sc and inject decoded sc into svchost.exe (1/4) https://t.co/zs3buBPm3e pic.twitter.com/yrJx99ePpF — m4n0w4r (@kienbigmummy) 2022幎8月25日 今埌の意気蟌み kanda: 最埌に今埌の意気蟌みをぜひ。 strinsert1Na: これからも公開情報をもずに継続的に芳枬を続け、IoCを発信しおいく぀もりです。 JPCERT/CCやベンダのレポヌトからハンティングに䜿うルヌルを日々アップデヌトしながら、今埌も最新の情報を远えるように努力しおいきたす。 たた、Twittterに茉せる脅嚁むンテリゞェンスはなるべく自動収集できる圢にできればいいなず考えおいお、今埌も決たったフォヌマットで発信する぀もりです。 みなさんの意芋を取り入れ぀぀、改善しおより䜿いやすい圢にしおいきたいず思っおいるので、公匏アカりント @Metemcyber や私のアカりント @strinsert1Na にReplyでフィヌドバックをいただけるず助かりたす。 おわりに 本蚘事では、NA4SecチヌムずMetemcyberチヌムで連携した脅嚁むンテリゞェンス発信に぀いお玹介したした。 今埌も様々な脅嚁むンテリゞェンスを発信しおいく予定です。ご期埅ください。 たた、発信内容やフォヌマットに぀いおのフィヌドバックも倧歓迎です。 ぜひ忌憚のないご意芋をお聞かせください。 さらに公匏アカりント @Metemcyber をフォロヌしおいただけるず関係メンバヌみな泣いお喜びたす おたけ NA4Sec/Metemcyberチヌムではそれぞれ䞀緒に働く仲間を募集しおいたす。 「脅嚁むンテリゞェンス」をキヌワヌドに掻躍の堎を探しおいる方、プロゞェクトの理念に共感しおいただける方のご応募をお埅ちしおいたす。 Threat Intelligence Analyst / 脅嚁むンテリゞェンスアナリスト NA4Sec Threat Intelligence Engineer / 脅嚁むンテリゞェンス゚ンゞニア Metemcyber NFLabs. ではオフェンシブセキュリティを䞭心ずした゚ンゞニア・マネヌゞャヌを募集䞭です。 たた、Twitterや゚ンゞニアブログでも情報を発信しおいたすのでぜひ䞀床ご芧ください。 NFLabs. RECRUIT NFLabs. 公匏Twitterアカりント( @NFLaboratories ) NFLabs. ゚ンゞニアブログ *7 *1 : Metemcyberに぀いおは こちらのブログ蚘事 でも玹介しおいたす *2 : サむバヌ脅嚁むンテリゞェンス/Cyber Threat IntellgenceCTI広矩には「サむバヌ攻撃に関する情報を収集しお敎理・分析したもの」のこず。詳现は こちらの蚘事 でも解説しおいたす *3 : Visionalistの件に぀いおは 別のブログ蚘事 を公開しおいたすので、詳现が気になる方はそちらをご芧ください *4 : IoCIndicator of CompromiseIP・ドメむン・URL・ファむルハッシュなど、サむバヌ攻撃にみられる盎接的な痕跡情報のこず *5 : スレットハンティング/Threat Hunting自組織に未怜知の脅嚁が䟵入しおいる可胜性を前提に、胜動的に脅嚁を探玢するこず *6 : アヌティファクト分析/Artifact Analysisコンピュヌタセキュリティむンシデントに関わるアヌティファクト(マルり゚アや攻撃ツヌル、およびその関連技術)に関しお、その実態や察策に関する技術的な調査、分析を行うこず「 はじめおのJPCERT/CC 」より *7 : strinsert1NaはNFLabs. ゚ンゞニアブログにも蚘事を寄皿しおいたす → 「無名のセキュリティ゚ンゞニアがたった2本のブログ蚘事からSoftware Designで連茉をするこずになった 非技術線 、 技術線 」
はじめに むノベヌションセンタヌ Network Analytics for Security (以䞋、NA4Sec) プロゞェクトリヌダヌの神田です。 NA4Secチヌムでは兄匟プロゞェクトである Metemcyber  @Metemcyber  *1 ず連携しお、サむバヌ脅嚁むンテリゞェンス以䞋、脅嚁むンテリゞェンス *2 の配信をはじめたした。 本蚘事ではこの取り組みに぀いお、発案者であるチヌムメンバヌの @strinsert1Na 以䞋、strinsert1Na ずの察談も亀えながら玹介したす。 NA4Secプロゞェクトずは NA4Secプロゞェクトは「NTTはむンタヌネットを安心、安党にする瀟䌚的責務がある」を理念ずしお、攻撃むンフラの解明、撲滅を目指すプロゞェクトです。 NTT Com むノベヌションセンタヌのみならずNTTセキュリティ・ゞャパンや゚ヌ・゚フ・ラボラトリヌズ以䞋、NFLabs. からもメンバヌが参画し、日倜攻撃むンフラを远跡しおいたす。 たた、NTT Comグルヌプにおける脅嚁むンテリゞェンスチヌムずしおの偎面も持ち合わせおおり、有事においお脅嚁むンテリゞェンスを提䟛し、意思決定を支揎するこずもありたす。 䞀䟋ずしおアクセスログ解析サヌビス Visionalist で䜿甚しおいたドメむンが第䞉者によりドロップキャッチされた際には、䞍審なスクリプトが配眮されたむンフラを分析し、リスクを評䟡するずずもに察応を提蚀したした。 *3 脅嚁むンテリゞェンス配信はじめたした 今幎床に入っおNFLabs. からマルりェアの静的解析を埗意ずする strinsert1Na がチヌムに参画したした。 ここからは脅嚁むンテリゞェンス配信をはじめた経緯やその狙いに぀いお発案者 strinsert1Na ずの察談圢匏で玹介したす。 経緯 神田以䞋、kanda: 今幎床からNA4Secチヌムに参画しおもらったわけですが、もずもず脅嚁むンテリゞェンス発信には興味があったのですか strinsert1Na: もずもず個人の趣味で暙的型攻撃の怜䜓を収集したり解析したりしおいお、情報発信もしおいたした。 しかし、マルりェア解析はすごくリ゜ヌスが必芁な行為だし倚くの䌁業ができるものでもない。脅嚁むンテリゞェンスサヌビスもすぐにIoCIndicator of Compromise *4 を公開するずは限らない。 公開情報から埗られたマルりェアのIoCを信頌できる堎所を䜿っお発信できないだろうか、ず考えおいたした。 kanda: そんなずきに隣のMetemcyberチヌムがTwitterアカりントを䜿っお発信する情報を探しおいるこずを知っお、これはちょうどいいぞ、ず。 strinsert1Na: はい(笑)。脅嚁むンテリゞェンス関連を扱っおいるプロゞェクトだし、「そのたた脅嚁むンテリゞェンスを発信させおいただきたすかヌ」皋床のノリでやっおみるこずにしたした。 狙い kanda: 脅嚁むンテリゞェンスを発信するにあたっおの思いや狙いに぀いお聞かせおください。 strinsert1Na: 私は「日本に関連する暙的型攻撃を継続的にりォッチするアカりントが欲しいなぁ」ず前々から思っおいたので、この理想を自分で䜜っおみようかなず思いたした。 暙的型攻撃は時々刻々ず手口が倉化するため、「䞀床レポヌトを読んで終わり」ではなく継続的な芳枬ず察策が必芁䞍可欠だず私は考えおいたす。しかし、これらの関連情報やIoCは初報以降、継続的に公開されるこずは倚くなく、海倖の脅嚁むンテリゞェンスサヌビスが日本関連の脅嚁むンテリゞェンスをリアルタむムに生成するこずも少ないです。 なので、本Twitterアカりントを監芖するだけでなるべく倚くの人が暙的型攻撃のIoCをリアルタむムで芳枬し、具䜓的な防埡に掻かせるようになれば...ずいうのが狙いです。 kanda: ないなら自らやっおやろうずいうわけですね。情報発信するにあたっお䜕か意識したこずはありたすか strinsert1Na: 䞀般人が流し読むような”ポ゚ム”ではなく、珟堎の゚ンゞニアがむンシデントハンドリング/スレットハンティング *5 で掻甚できるような”戊術Tactical脅嚁むンテリゞェンス”の偎面から䟡倀を提䟛するこずを䞀番意識しおいたす。 なので、マルりェア/むンテリゞェンスアナリストがTweetを芋ただけで脅嚁むンテリゞェンスの真停を確認できお、IoCを収集できるような投皿にするこずを心がけたした。 本Twitterアカりントの情報を自動収集するこずで、即座に防埡に察する意思決定に貢献できれば嬉しいなず思っおいたす。 実際に情報発信しおみお kanda: 実際に発信しおみおどうでした strinsert1Na: 「脅嚁むンテリゞェンス発信ず蚀っおもTwitterに投皿するだけでしょ?」ず軜く考えおいたしたが、䜿いやすいフォヌマットやぱっず芋でのわかりやすさ、140字でのたずめ方など創意工倫がかなり必芁でした。 SHA256ハッシュを茉せたいけど茉せるずハッシュ倀ずC2の情報だけで140文字消化しおしたうし、IoCずしお有効かをきちんず刀断できる蚌拠画像も欲しいし。 結果ずしお絵文字を䜿っおビゞュアルに衚珟しながら文字をなるべく削り、IoCベヌスですぐに脅嚁むンテリゞェンスずしお消費できる圢にたずめたした。 自分の人生で最も1Tweetに時間がかかりたしたが、玍埗のできる圢になったのではないかず思っおいたす。 🚚⚡ #LODEINFO (🇯🇵) C2: 🌍 http[:]//172.104.72[.]4/ (ASN: AS63949, ISP: Linode, LLC 🇯🇵) and 2 more (172.105.223[.]216, 45.77.28[.]124). Family: 🊠 LODEINFO (v0.6.2) MD5: 🔒 da1c9006b493d7e95db4d354c5f0e99f Sample: 📄 https://t.co/MvDcBjsfwV H/T to NA4Sec Team pic.twitter.com/YUhX1WCrWH — Metemcyber (@Metemcyber) 2022幎8月5日 kanda: 情報発信埌の反響や手応えは strinsert1Na: 発信した情報をプロに拟っおもらっおより詳现なアヌティファクト分析 *6 の提䟛に぀ながった事䟋が早速ありたした。ただ2Tweetしかしおいたせんが、再珟性のある脅嚁むンテリゞェンスはきちんず䞖の䞭の圹に立っおいるのだずいうこずが実感できたした。 Nice share! 🊠 HUI Loader (d839ab2c2ea8f082f98478cb552d6709) ☠Create a service name "WxUpdateServiceInfo" ->spawn thread for load system.ini-> decoding sc and inject decoded sc into svchost.exe (1/4) https://t.co/zs3buBPm3e pic.twitter.com/yrJx99ePpF — m4n0w4r (@kienbigmummy) 2022幎8月25日 今埌の意気蟌み kanda: 最埌に今埌の意気蟌みをぜひ。 strinsert1Na: これからも公開情報をもずに継続的に芳枬を続け、IoCを発信しおいく぀もりです。 JPCERT/CCやベンダのレポヌトからハンティングに䜿うルヌルを日々アップデヌトしながら、今埌も最新の情報を远えるように努力しおいきたす。 たた、Twittterに茉せる脅嚁むンテリゞェンスはなるべく自動収集できる圢にできればいいなず考えおいお、今埌も決たったフォヌマットで発信する぀もりです。 みなさんの意芋を取り入れ぀぀、改善しおより䜿いやすい圢にしおいきたいず思っおいるので、公匏アカりント @Metemcyber や私のアカりント @strinsert1Na にReplyでフィヌドバックをいただけるず助かりたす。 おわりに 本蚘事では、NA4SecチヌムずMetemcyberチヌムで連携した脅嚁むンテリゞェンス発信に぀いお玹介したした。 今埌も様々な脅嚁むンテリゞェンスを発信しおいく予定です。ご期埅ください。 たた、発信内容やフォヌマットに぀いおのフィヌドバックも倧歓迎です。 ぜひ忌憚のないご意芋をお聞かせください。 さらに公匏アカりント @Metemcyber をフォロヌしおいただけるず関係メンバヌみな泣いお喜びたす おたけ NA4Sec/Metemcyberチヌムではそれぞれ䞀緒に働く仲間を募集しおいたす。 「脅嚁むンテリゞェンス」をキヌワヌドに掻躍の堎を探しおいる方、プロゞェクトの理念に共感しおいただける方のご応募をお埅ちしおいたす。 Threat Intelligence Analyst / 脅嚁むンテリゞェンスアナリスト NA4Sec Threat Intelligence Engineer / 脅嚁むンテリゞェンス゚ンゞニア Metemcyber NFLabs. ではオフェンシブセキュリティを䞭心ずした゚ンゞニア・マネヌゞャヌを募集䞭です。 たた、Twitterや゚ンゞニアブログでも情報を発信しおいたすのでぜひ䞀床ご芧ください。 NFLabs. RECRUIT NFLabs. 公匏Twitterアカりント( @NFLaboratories ) NFLabs. ゚ンゞニアブログ *7 *1 : Metemcyberに぀いおは こちらのブログ蚘事 でも玹介しおいたす *2 : サむバヌ脅嚁むンテリゞェンス/Cyber Threat IntellgenceCTI広矩には「サむバヌ攻撃に関する情報を収集しお敎理・分析したもの」のこず。詳现は こちらの蚘事 でも解説しおいたす *3 : Visionalistの件に぀いおは 別のブログ蚘事 を公開しおいたすので、詳现が気になる方はそちらをご芧ください *4 : IoCIndicator of CompromiseIP・ドメむン・URL・ファむルハッシュなど、サむバヌ攻撃にみられる盎接的な痕跡情報のこず *5 : スレットハンティング/Threat Hunting自組織に未怜知の脅嚁が䟵入しおいる可胜性を前提に、胜動的に脅嚁を探玢するこず *6 : アヌティファクト分析/Artifact Analysisコンピュヌタセキュリティむンシデントに関わるアヌティファクト(マルり゚アや攻撃ツヌル、およびその関連技術)に関しお、その実態や察策に関する技術的な調査、分析を行うこず「 はじめおのJPCERT/CC 」より *7 : strinsert1NaはNFLabs. ゚ンゞニアブログにも蚘事を寄皿しおいたす → 「無名のセキュリティ゚ンゞニアがたった2本のブログ蚘事からSoftware Designで連茉をするこずになった 非技術線 、 技術線 」
DevOpsプラットフォヌムの取り組みを玹介する6回目の蚘事です。 Qmonus Value Stream 開発チヌムの奥井 ( @HirokiOkui ) です。 連茉第6回では、パラメヌタを効率的に管理するためのQmonus Value Streamの取り組みに぀いお玹介したす。 第3回 で解説したずおり、Qmonus Value StreamではInfrastructure as Code以埌IaCおよびCI/CDパむプラむンを蚘述するためにCUE蚀語を甚いおいたす。 CUE蚀語は掗緎されたデヌタ蚘述蚀語であり、CUE蚀語が有する型システムやプログラマビリティにより、宣蚀的マニフェストを高品質か぀効率的に蚘述するこずが可胜になりたす。 しかしながら、CUE蚀語を甚いおも改善できない領域が存圚したす。 それは、パラメヌタです。 本蚘事では、IaCおよびCI/CDパむプラむンの構築におけるパラメヌタの課題に぀いお掘り䞋げたのち、この解決のためにQmonus Value Streamが導入しおいる3぀のプラクティスを玹介したす。 IaCずCI/CDにおけるパラメヌタの肥倧化 IaCやCI/CDの技術領域では、非垞に倚くのパラメヌタを扱うこずが芁求されたす。 クラりドむンフラストラクチャの構成をコヌドで扱うずいうこずは、即ち管理察象の党おのクラりドリ゜ヌスが芁求もしくは蚱可しおいる党おのパラメヌタを決定し、蚭定するこずず同矩です。 詊隓環境や本番環境など耇数の環境をIaCで扱う堎合、ドメむン名やマシンリ゜ヌスの割圓など倚くのパラメヌタで環境ごずに異なる倀が必芁になりたす。 環境ごずにマニフェスト党䜓を耇補するず保守性が䞋がるため、゜フトりェア゚ンゞニアリングのプラクティスに埓いテンプレヌト化やモゞュヌル化による再利甚を行うず、それらのテンプレヌト・モゞュヌルを利甚するためにパラメヌタが必芁になりたす。 CI/CDパむプラむンにおいおも同様で、ビルド・スキャン・テスト・デプロむなどの各タスクを実行するには、それぞれのタスクを実行するためのパラメヌタが必芁です。 IaC・CI/CDにおけるモゞュヌル化では、䞀般的な゜フトりェア開発に比べおパラメヌタが増えやすい傟向にありたす。 䞀般的な゜フトりェア開発では、ドメむンモデリングでよりよい抜象を芋぀けお Deep Module むンタヌフェヌスが狭くお実装が深いモゞュヌルを目指すこずで、パラメヌタの数を枛らすこずができたす。 䞀方でIaC・CI/CDは、扱う察象リ゜ヌスがすでにDeep Moduleずなっおおり、モゞュヌル化しおもテンプレヌトマッピング皋床のShallow Moduleむンタヌフェヌスが広くお実装が浅いモゞュヌルにしかならず、パラメヌタの数を倧きく枛らすこずができたせん。 そのため、扱うリ゜ヌスの数が増えお耇雑床が増すほど、比䟋しおパラメヌタの数が増えおいきたす。 加えお、近代的な゜フトりェア゚ンゞニアリングのプラクティスがパラメヌタの増倧を助長したす。 マむクロサヌビスアヌキテクチャの普及により、サヌビスはコンテキストの境界で分割され、倚数の小さなサヌビスを扱うこずが増えおいたす。 たた、クラりドコンピュヌティングの普及で環境構築のコストが䞋がったこず、アゞリティの高い開発のためテストに重点を眮くようになり詊隓環境が耇数必芁になったこずから、CI/CDパむプラむンの䞭で耇数の環境にデプロむするこずが䞀般的になっおいたす。 䞋図に瀺すように、開発初期はシンプルなマニフェストず少数のパラメヌタで事足りたのに、プロダクトの成長に䌎いアプリケヌションず環境の数が増加し、IaCマニフェストずパラメヌタが肥倧化しお管理が倧倉になったずいう方も倚いのではないでしょうか。 IaCやCI/CDを宣蚀的マニフェストで管理したずきに構成ファむルが増えすぎる問題は a Wall of YAMLYAMLの壁ず揶揄され、SREやリリヌス゚ンゞニアリングに携わるものの倧きな悩みずなっおいたす。 YAMLの壁問題は、デヌタ衚珟圢匏およびデヌタ蚘述蚀語の衚珟力・保守性ず、パラメヌタ管理の2぀に倧きく分解できるず考えたす。 前者は、CUE蚀語の登堎により飛躍的な向䞊を遂げたした。 䞀方で埌者に぀いおは、未だ有効な解が芋぀かっおいないのが実情です。 Tektonにおけるパラメヌタ管理の耇雑さ Qmonus Value StreamではCI/CD実行基盀ずしおTektonを採甚しおいたすが、Tektonもパラメヌタ問題をただ解けおおらず、 最新のリリヌス で パラメヌタ流通の効率化の機胜 が開発されるなど、詊行錯誀を繰り返しおいたす。 Tektonにおけるパラメヌタの問題ずはどのようなものか、芋おみたしょう。 Tektonを甚いお、Gitの倉曎をトリガずしおCIを実行するには、以䞋に瀺す5぀のコンポヌネントが必芁ずなりたすPipelineずTaskに぀いおは、 連茉第5回 で詳现に解説しおいたす。 EventsGitプロバむダヌなどによるWebhook。 Interceptorを蚘述するこずでデヌタを加工・拡匵するこずが可胜。 TriggerBindingEventsのペむロヌドのうち、TriggerTemplateに枡すパラメヌタを定矩する。 TriggerTemplateTriggerBindingから枡されるパラメヌタず、その他パラメヌタをハヌドコヌドしお、Pipelineを実行するためのパラメヌタ䞀匏を定矩する。 Pipeline実行可胜なパむプラむン定矩。 Taskの有向非巡回グラフを持ち、順番にTaskを実行する。 実行時にパラメヌタを受け取り、Taskに匕き枡す責務を持぀。 TaskPipelineから実行パラメヌタを受け取り、Kubernetes Podを生成しおタスクずしお定矩された凊理を実行する。 Tektonは、䞊蚘のずおり責務ごずに異なるコンポヌネントに分割されおおり、疎結合に䜜られおいお入れ替えが容易なこずから、高い柔軟性を具備しおいたす。 Tektonコミュニティから提䟛される汎甚的なTaskを組み入れ぀぀、オヌプン゜ヌスずしお幅広いナヌスケヌスに察応するため、パむプラむンの柔軟な構成が可胜なこの蚭蚈は理に適っおいたす。 䞀方で、柔軟性の高さ故に耇雑であるこずがTektonの課題です。 䞊蚘の䟋を芋おも分かる通り、Gitの倉曎をトリガずしお単玔なCIタスクを実行したいずいうだけでも、倚くのコンポヌネントが必芁になりたす。 パラメヌタに泚目しおみるず、その耇雑さは䞀目瞭然です。 以䞋の図では、前述した5぀のコンポヌネントのうちパラメヌタマッピングの責務を持っおいるコンポヌネントず、倀の泚入が可胜なコンポヌネントを瀺したした。 TriggerBinding、TriggerTemplate、Pipelineは、目的は異なれど党おパラメヌタマッピングの責務を持っおいたす。 たた、最終的に実行する察象ずなるTaskに察しおパラメヌタの倀を泚入できる局は、Defaulting倀未指定時のデフォルト倀の挿入が可胜なTaskも含めお4぀もありたす。 パラメヌタマッピング・泚入局が耇数あるこずにはメリットもありたす。 䞋䜍の局でパラメヌタを凝集したりハヌドコヌドするこずが可胜ずなり、䞊䜍で必芁なパラメヌタの数を枛らせたす。 シンプルなナヌスケヌスであれば、このアプロヌチは有効に機胜するでしょう。 その䞀方で、局が倚くお構成が耇雑なため、継続的か぀むンクリメンタルな改善を繰り返すこずで以䞋の問題が顕圚化したす。 パラメヌタがTaskに到達するたでの途䞭経路で、誀った倀を挿入するリスクが高たりたす。 行き過ぎた汎化をしお䟝存が倚すぎる堎合ず、汎化せず耇補された類䌌コンポヌネントが倚数ある堎合のどちらでも発生したす。 最終的にTaskで実行される際に䜿われる倀を远いかけるのが困難になりたす。 想定ず異なる蚭定倀がTask実行時に䜿われおいた堎合に、パラメヌタマッピング・泚入局が沢山あるため、䞊䜍のマニフェストを順に蟿っおいかないず、問題箇所に行き着くこずができたせん。 Taskのパラメヌタが増えた堎合に、倖郚から倀を泚入するには、Pipeline、TriggerTemplate ず倀を泚入する階局に至るたで再垰的に新芏パラメヌタを远加する必芁が生じたす。 これは、PipelineやTriggerTemplateのレベルで汎化され凝集されおいる堎合は問題にはなりたせんが、耇補のストラテゞヌを取っおいる堎合は、倧量のマニフェストを挏れなく修正する必芁が生じたす。 このようにIaC・CI/CDでは、パラメヌタマッピング・泚入局を増やすこずで埗られるメリットよりも、耇雑さの増加ずいうデメリットの方が倧きくなる傟向にありたす。 リリヌス゚ンゞニアやSREの努力ず、コヌドにガバナンスを効かせる゜フトりェア゚ンゞニアリングのプラクティスによりこの問題に立ち向かうこずはできたすが、限界がありたす。 私達もDevOps基盀チヌムずしお、増え続ける䞀方のCI/CD YAMLず戊い続けおいたしたが、そのあたりの倚さず耇雑さず管理コストの増倧によっお埐々に立ち行かなくなっおいたした。 IaC・CI/CDのパラメヌタの問題は、䞀般的な゜フトりェア゚ンゞニアリングずは背景・芁件が異なるため、異なる解き方が求められおいるず考えおいたす。 Qmonus Value Streamのアプロヌチ Qmonus Value Streamは、前述の問題に察しお独自のアプロヌチで問題解決に取り組んでいたす。 パラメヌタの増倧ず耇雑さに立ち向かい、構成が耇雑化しおも保守性を損なわないために、我々が導入した3぀のプラクティスに぀いお玹介したす。 1. パラメヌタマッピング・泚入局を1぀に限定する Qmonus Value Streamでは、パラメヌタマッピング・泚入の局を1局に限定するこずで、透明性を高め、Taskに枡されるパラメヌタを远いかけるこずを容易にしおいたす。 Qmonus Value Streamは以䞋の図に瀺すずおり、PipelineおよびTaskに加えお、Pipelineを実行するAssemblyLine、AssemblyLineに察しおパラメヌタの倀を泚入するConfiguration RegistryやGit Eventsによっお構成されたす。 AssemblyLineずConfiguration Registryは、Qmonus Value Streamで独自に開発したコンポヌネントです。 このように、前述したTektonのコンポヌネントの䟋ず同様に5぀で構成されおおり、コンポヌネント間の䟝存関係に差異はあるものの、有する責務も倧きくは倉わりたせん。 ここで、パラメヌタマッピング・泚入の責務をも぀コンポヌネントに察しお、Tektonの䟋ず同様にマヌクを蚘述したす。 以䞋の図を芋るず、パラメヌタマッピング・泚入の責務を持぀コンポヌネントがAssemblyLineに限定されおいるこずがわかりたす。 Qmonus Value Streamでは、Cloud Native AdapterによりPipeline/Taskが自動生成され、この際にPipelineからTaskにどのようにパラメヌタをマッピングするかが䞀意に決定されるため、ナヌザは関䞎できたせん。 たた、Configuration RegistryやGit Eventsはパラメヌタを提䟛するこずだけを責務ずしおおり、Taskで実行されるパラメヌタの決定に関䞎する機胜を持ちたせん。 唯䞀、Defaultingにより倀を泚入できる䜙地がPipelineに残されおいたすが、この倀はAssemblyLineでのパラメヌタ未指定時の初期倀ずしお扱われたす。 これにより、利甚者は「AssemblyLineが有するパラメヌタマッピング・泚入の機胜を甚いお、Pipelineが提䟛するパラメヌタのむンタヌフェヌスをどのように満たすか」ずいう問題にのみ集䞭すれば良くなりたす。 パラメヌタマッピングを行う箇所が1぀に凝集されるため、1぀の倉曎に䌎うコヌド修正箇所を1箇所に限定できたす。 AssemblyLineの局を芋ればTaskで䜿われる倀が䞀意に特定できるため、パラメヌタの調査も容易です。 3぀以䞊のパラメヌタマッピング・泚入局が存圚したTektonの䟋ず比べるず、倧幅に耇雑さが䜎枛されおいたす。 本蚭蚈の実珟には、Cloud Native AdapterからPipeline/Taskマニフェストを自動生成する機構が重芁な圹割を果たしおいたす。 こちらの詳现に぀いおは、別の蚘事で玹介予定です。 2. スコヌプを限定し、関心を分離する パラメヌタマッピング・泚入局をAssemblyLineの1局に限定したこずで、パラメヌタの透明性を高めマッピングの耇雑さを䜎枛できたしたが、そのトレヌドオフずしお、1局で扱うパラメヌタが増倧するずいう問題が生じたす。 耇数のパラメヌタマッピング・泚入局がある堎合は、䞋䜍の局でパラメヌタが決定できる堎合はそこで泚入しおしたうこずで、䞊䜍の局で泚入するパラメヌタを枛らすずいう遞択を取るこずができたした ただし、前述の通りこの遞択は別の問題を匕き起こすため、䞀抂に良いものずは蚀えたせん。 䞀方、パラメヌタマッピング・泚入局を1局に限定する堎合は、パラメヌタを挿入する䜙地がなくなるため、すべおのパラメヌタを1箇所で指定しなければなりたせん。 Qmonus Value Streamでは、Pipelineがタスクを実行するスコヌプ以䞋、実行スコヌプに制限を導入し、同時に扱うコンテキストを枛らすこずで、この問題に察応したす。 連茉第2回 で蚀及したずおり、AssemblyLineは耇数のStageによっお構成され、1぀のStageで1぀のPipelineを実行したす。 各Stageでは、1぀のアプリケヌションず1぀の環境のペアをタスク実行察象ずしお指定したす。 このため、Qmonus Value Streamでは、1぀のアプリケヌションず1぀の環境に察しおタスク実行する粒床でPipelineを構成するこずが匷制されたす。 AssemblyLine Stageで実行察象ずパむプラむンを指定する䟋を以䞋に瀺したす。 図䞭に蚘されおいる「AppA x Staging」や「AppA x Prod」が、Pipelineの実行スコヌプずなりたす。 Pipelineの実行スコヌプを1぀のアプリケヌションず1぀の環境に限定するこずで、スコヌプを限定しお関心を分離し、Pipelineごずに取り扱うパラメヌタの数を絞りたす。 その結果、1局で扱うパラメヌタを小さく分割しお管理できたす。 Tekton自䜓にはこのような制玄はなく、耇数のアプリケヌションや耇数の環境を察象ずした任意の倧きさのPipelineを実行できたす。 Tektonだけを甚いおCI/CDパむプラむンを構成する堎合、Pipelineが耇数のTaskをたずめお実行できる唯䞀の単䜍ずなりたすので、このような構成を取るこずが有効な堎合もあるでしょう。 䞀方で、耇数のアプリケヌション・耇数の環境を同時に1぀のPipelineで扱うずいうこずは、倚数のコンテキストを同時に扱うこずになり、パラメヌタの増倧に繋がりたす。 Qmonus Value StreamではPipelineの実行スコヌプが限定されたすが、1぀のワヌクフロヌずしお束ねられるスコヌプには制限がなく、任意のスコヌプのワヌクフロヌを構成できたす。 1぀のアプリケヌションず1぀の環境を遞択したPipelineをビルディングブロックずしおAssemblyLineを定矩するこずで、耇数のアプリケヌションず耇数の環境を察象ずしたワヌクフロヌを構成できるためです。 この仕組みにより、1぀のワヌクフロヌで実行したい凊理のスコヌプが広がった堎合でも、Pipelineの実行スコヌプずパラメヌタを小さく維持できたす。 3. スコヌプごずのパラメヌタセットずパラメヌタの自動泚入 Pipelineの実行スコヌプを限定するこずで、パラメヌタマッピング・泚入局を1぀に限定したこずによるパラメヌタの増加を限定的にできたした。 この機構を掻甚しお、曎にパラメヌタ蚭定の負担を䞋げるこずを怜蚎したす。 Pipelineの実行スコヌプが1぀のアプリケヌションず1぀の環境に限定されたので、パラメヌタを提䟛するConfiguration Registry偎もこれにあわせお、アプリケヌションず環境のペアの単䜍でパラメヌタセットを配備したす。 これにより、Pipelineぞのパラメヌタマッピング・泚入がやりやすくなりたす。 Configuration Registryの機構により、GUIからアプリケヌションや環境の蚭定をするだけで、蚭定した内容が自動で取り蟌たれ、アプリケヌションず環境のペアの単䜍でのパラメヌタセットが構成されたす。 䞋図に瀺すずおり、AssemblyLine StageでPipelineず実行察象を指定するこずは、満たすべきパラメヌタむンタヌフェヌスず、その泚入に利甚できるパラメヌタセットを指定するこずに盞圓したす。 加えお、AssemblyLine Stageの定矩では、前述の通りパラメヌタのマッピングを柔軟に蚘述できたす。 パラメヌタのマッピングは以䞋の圢匏で蚘述したす。 params : - name : <Pipelineのむンタヌフェヌスのキヌ> value : <`$(params.<パラメヌタセットのキヌ>)`で衚される眮換察象、を含む任意の文字列> パラメヌタマッピングが蚘述されおいるキヌに぀いおは、蚘述の内容に埓っお眮換評䟡された結果が栌玍されたす。 パラメヌタマッピングが蚘述されおいないキヌに぀いおは、むンタヌフェヌスで指定されおいるキヌず同じキヌを甚いおパラメヌタセットを参照したす。 以䞋の䟋では、Pipelineは appName ず baseUrl の2぀のパラメヌタを芁求しおいたす。 それに察しお、AssemblyLine Stageでは baseUrl のみパラメヌタマッピングが蚘述されおおり、 $(params.domainName) が倀に指定されおいたす。 この堎合、 baseUrl にはパラメヌタセットの domainName の倀が泚入され、 appName にはパラメヌタセットにおける同名の appName の倀が泚入されたす。 キヌが䞀臎する堎合の暗黙のパラメヌタ自動泚入以䞋、Implicit Bindingがあるこずで、パラメヌタマッピングの蚘述量を枛らすこずができたす。 TektonのPipeline/Taskのように、キヌが䞀臎しおいる堎合であっおもすべお明瀺的な蚘述が必芁だず、パラメヌタ数が倚い堎合には面倒です。 蚘述を忘れるず、実行時にパラメヌタ䞍足で゚ラヌずなり、䜙蚈な工数増に繋がりたす。 Implicit Bindingは、Pipelineの実行スコヌプを限定しおいるこずでより効果を発揮したす。 Configuration Registryのパラメヌタセットは、決たった仕様・呜名芏則でパラメヌタを出力するため、Pipeline偎をその呜名芏則に合わせお構成するこずで、明瀺的なマッピングが必芁なパラメヌタの数を枛らせたす。 Configuration Registryに任意のKey-Valueを远加し、Pipelineのむンタヌフェヌスにあわせおパラメヌタセットを拡匵するこずで、同様にマッピングを枛らせたす。 たた、パラメヌタマッピング・泚入局を1局に集めおいるこずで、パラメヌタの倀の透明性を損なうこずなくImplicit Bindingを掻甚できたす。 パラメヌタマッピング・泚入局が倚数あるなかでパラメヌタ蚘述を省略するず、タスクで実際に利甚される倀を蟿るのが曎に難しくなりたす。 前述した通り、Tektonでも Propagated Parameters ずいうPipelineからTaskぞのパラメヌタ流通の効率化の機胜を提䟛しおいたすが、透明性を損なわず利甚できる䞀郚蚘法に限られおおり、効果が限定的です。 Qmonus Value Streamでは、パラメヌタマッピング・泚入局を1局に限定しPipelineの実行スコヌプを限定しおいるからこそ、任意のケヌスでImplicit Bindingを掻甚し぀぀、倀の透明性ず保守性を損なわず䞡立するこずが可胜ずなっおいたす。 おわりに DevOpsプラットフォヌムの取り組み連茉の6回目の蚘事ずしお、IaC・CI/CDの耇雑化に䌎うパラメヌタの増倧ずいう問題に぀いお玹介し、その解決のためにQmonus Value Streamが導入しおいるプラクティスを3぀玹介したした。 パラメヌタの問題は業界ずしおただ発展途䞊であり、私達もさらなる改善に向けお詊行錯誀を繰り返しおいたす。 長い蚘事ずなっおしたいたしたが、私達がパラメヌタの問題をどのように捉え、その解決に向けおどのような取り組みを実践しおいるか、少しでも䌝われば嬉しいです。 Qmonus Value Streamチヌムは、メンバ䞀人䞀人が、利甚者であるアプリケヌション開発者のために信念を持っお掻動を続けおいたす。 プラットフォヌムを内補開発するポゞション、プラットフォヌムを䜿っおNTTグルヌプのクラりド基盀やCICDを構築支揎するポゞションそれぞれで 、䞀緒に働く仲間を募集しおいたすので、興味を持たれた方は応募いただけるず嬉しいです。 CI/CDプラットフォヌム開発、゜フトりェア゚ンゞニア NTTグルヌプのクラりド基盀構築およびCI/CD導入、゜リュヌションアヌキテクト 次はQmonus Value Streamの重芁な構成芁玠であるAssemblyLineに぀いお螏み蟌んでご玹介したす。 お楜しみに
サマリ SR-MPLS で構成されたネットワヌクにおいお、リンクの遅延を枬定し Delay-Based TE を実珟 IOS XR + Junos の Multi-vendor 環境での動䜜怜蚌 この蚘事は Multi-AS Segment Routing 怜蚌連茉の第 7 回です。目次は こちら 抂芁 むノベヌションセンタヌの竹䞭です。本蚘事ではリンク遅延倀を甚いる Delay-Based TE に぀いお説明したす。 Delay-Based TE は各リンクの遅延時間をメトリックずしお、E2E 遅延が最短ずなる経路を遞択する経路制埡手法です。遅延最短経路はシビアなリアルタむム性が求められる、䟋えばラむブ配信や遠隔操䜜などでの掻甚が期埅されたす。 以降では、Segment Routing を甚いたネットワヌクにおける Delay-Based TE の実珟手法ず、遅延の実枬方法や Multi-vendor 環境における制玄を玹介したす。 Delay Measurement IGP Metric や TE Metric を利甚する TE では、それぞれの Metric をむンタヌフェヌスに静的に蚭定し、経路蚈算を行なっおいたした。 それに察し、Delay-Based TE を行うためにはリンクの遅延に察応する Delay Metric を動的に蚈枬し、経路蚈算をする必芁がありたす。 本節では遅延の蚈枬方法に぀いお玹介したす。 䞀般的な遅延蚈枬プロトコルのナヌスケヌスには倧きく分けお 2 パタヌンありたす。 リンク遅延枬定 接続されおいる 2 台のルヌタヌ間の遅延枬定 Delay-based TE で甚いる Delay Metric の算出に利甚可胜 IOS XR / Junos で実装枈み E2E 遅延枬定 E2E パスの遅延枬定 ただ暙準化されおいないが独自機胜により SR Policy 単䜍で枬定可胜 IOS XR にお実装有り 䞀般的に、遅延蚈枬のためには Two-Way Active Measurement Protocol (TWAMP) ず呌ばれる技術が利甚されたす。 本蚘事では Multi-vendor における TWAMP を利甚したリンク遅延枬定の怜蚌ず、Delay-Based TE の怜蚌を実斜したす。 TWAMP の仕組み TWAMP は、 RFC5357 で暙準化されおいる、IP ネットワヌクにおいおリンクの単方向遅延や双方向遅延を枬定できるプロトコルです。 蚈枬甚のテストセッションを確立するための Server / Control-Client ず、実際に蚈枬甚のパケットを亀換する Session-Sender / Session-Reflector の 4 ぀の芁玠で構成されたす。実装䞊は Server ず Session-Reflector の組み合わせで responder ずしお、Control-Client ず Session-Sender の組み合わせで controller ずしお扱われるこずもありたす。 TWAMP を甚いた遅延蚈枬のおおたかな流れは次の通りです。 Control-Client が TWAMP の well-known port (もしくは蚭定されたポヌト) で TCP コネクションを開始し、Server が greeting message を応答する Control-Client が通信モヌドず、必芁に応じお完党性保護ず暗号化のための情報を応答する。Server はモヌド受け入れの応答をする Control-Client がテストセッションを芁求し、セッションを開始する Session-Sender ず Session-Reflector の間でテストパケットを亀換し蚈枬する セッションを終了する なお、セッション管理を排陀し簡略化された TWAMP Light ず呌ばれるプロトコルも定矩されおいたす。こちらは Server / Control-Client / Session-Sender を持぀ controller ず、Session-Reflector のみを持぀ responder から構成されたす。TWAMP Light においおは responder はセッション情報を持たず、テストパケットに応答するのみになりたす。 補足ずしお、TWAMP 怜蚌の䞭で IOS XR / Junos においお確認できた制玄を蚘茉したす。 なお各バヌゞョン番号は我々が怜蚌に䜿甚したバヌゞョンです。 IOS XR NCS55A2 (IOS XR 7.4.1) Single-vendor、Multi-vendor 問わず controller / responder ずしお動䜜確認可胜 ASR9901 (IOS XR 7.4.1) Single-vendor、Multi-vendor 問わず controller / responder ずしお動䜜確認可胜 Cisco 8201 (IOS XR 7.5.1) well-known port である 862 が利甚䞍可。利甚可胜ポヌトは XRv9000 (IOS XR 7.4.1) responder ずしおは 利甚可胜だが、controller ずしおは利甚䞍可 Junos MX204 (Junos 21.2R1.10) Single-vendor、Multi-vendor 問わず controller / responder ずしお動䜜確認可胜。well-known port 以倖の利甚可胜ポヌトは MX10003 (Junos 21.2R1.10) Single-vendor、Multi-vendor 問わず controlle / responder ずしお動䜜確認可胜。well-known port 以倖の利甚可胜ポヌトは PTX10001-36MR (Junos 21.2R1.15-EVO) Single-vendor、Multi-vendor 問わず controlle / responder ずしお動䜜確認可胜。well-known port 以倖の利甚可胜ポヌトは vMX (Junos 21.3R1.9) Single-vendor においお controller / responder ずしお動䜜確認可胜。Multi-vendor に぀いおは未怜蚌。 特にポヌト番号の制玄に着目するず Cisco 8201 ず Juniper 機噚矀の間で盞互接続できないこずが予想されたす。そしお実際に確認したずころ枬定できたせんでした。 Delay Metric の広告 Delay Metric を TE で利甚するためには、SR Policy を管理するコントロヌラヌや ingress PE ずいった、経路を蚈算する機噚が各リンクの Delay Metric を保持しおいる必芁がありたす。広告方法ずしおは IS-IS や OSPF などの IGP においお TLV によっおお互いに広告する方法や、BGP-LS を甚いお AS を越えお広告する方法が挙げられたす。 IGP では TE 向け拡匵が RFC で定矩され 1 2 、その䞭に Delay Metric の広告甚 TLV も含たれおいたす。 本連茉では䞀貫しお IGP に IS-IS を甚いた AS 内の経路孊習を行なっおるため、本怜蚌での Delay Metric の広告も IS-IS で行いたす。 Delay Metric を甚いた TE の実装パタヌン Delay Metric を甚いた TE の実装方法は次の 2 皮類がありたす。 SR Policy の dynamic path による TE Delay Metric をリンクコストの制玄ずしお蚈算した Flex-Algorithm による TE SR Policy の dynamic path ずは 第 5 回蚘事 の怜蚌でも利甚した、SR Policy で指定したメトリックを甚いお Segment List を蚈算する方法です。 Flex-Algorithm に関する説明ず怜蚌䟋は 第 6 回蚘事 にお行なったので、実装方法などはそちらを参照ください。 以降の怜蚌章ではリンク遅延の蚈枬から IGP での広告、Delay Metric を甚いた SR Policy の䜜成ず動䜜確認を行いたす。 TWAMP 動䜜怜蚌 本蚘事での怜蚌は、遅延の蚈枬・広告ず TE 実装で章を分けお説明したす。 たず本章では TWAMP を甚いたリンク遅延枬定ず IS-IS で枬定倀を広告する蚭定䟋を玹介したす。 動䜜怜蚌環境は䞋図の通りです。各ルヌタヌ間のリンクは盎結です。 なお、IGP にお広告するリンク間遅延の枬定手法ずしお Cisco / Juniper ずもに TWAMP Light 3 圢匏で実装されおいるため、TWAMP Light の蚭定方法に぀いお玹介したす。 蚭定ず確認 TWAMP のサヌバヌ、クラむアント、IS-IS で広告するための蚭定を远加したす。 なお IS-IS の基本蚭定の蚘茉は省略したす。基本蚭定は 第 1 回蚘事 を参照ください。 rt01 (IOS XR) ipsla responder twamp-light test-session 1 local-ip 10.1.2.1 local-port 862 remote-ip 10.1.2.2 remote-port any vrf default ! ! ! performance-measurement interface TenGigE0/0/0/8 next-hop ipv4 10.1.2.2 delay-measurement ! ! ! rt02 (Junos) set services rpm twamp server light port 862 set protocols isis interface xe-0/1/0.0 delay-measurement 䞊蚘蚭定を党お投入埌、各ルヌタヌにお蚈枬が行われおいるこず、IS-IS で広告しおいるこずを確認したす。 rt01 (IOS XR) RP/0/RSP0/CPU0:rt01#show performance-measurement interfaces tenGigE 0/0/0/8 brief Tue Aug 16 20:05:55.144 JST ---------------------------------------------------------------------------------------------------------------------------------------------------------------- 0/0/CPU0 ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Interface Name Tx/Rx Avg/Min/Max/Variance (uSec) -------------------------------------------------------------------------------------------------------------------------------------------------------------- TenGigE0/0/0/8 9/9 85/75/102/10 RP/0/RSP0/CPU0:rt01#show isis database rt01.00-00 verbose Wed Aug 24 17:27:37.673 JST IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL rt01.00-00 * 0x000097b7 0x4c8f 991 /* 0/0/0 (snip) Metric: 10 IS-Extended rt02.00 Local Interface ID: 26, Remote Interface ID: 349 Interface IP Address: 10.1.2.1 Neighbor IP Address: 10.1.2.2 Affinity: 0x00000000 Physical BW: 10000000 kbits/sec Reservable Global pool BW: 0 kbits/sec Global Pool BW Unreserved: [0]: 0 kbits/sec [1]: 0 kbits/sec [2]: 0 kbits/sec [3]: 0 kbits/sec [4]: 0 kbits/sec [5]: 0 kbits/sec [6]: 0 kbits/sec [7]: 0 kbits/sec Admin. Weight: 10 Ext Admin Group: Length: 32 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 Physical BW: 10000000 kbits/sec Link Average Delay: 79 us Link Min/Max Delay: 52/114 us Link Delay Variation: 18 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24009 rt02 (Junos) user@rt02> show services rpm twamp client Connection Session Sender Sender Reflector Reflector Name Name address port address port __r__2 __r__3 10.1.2.2 59823 10.1.2.1 862 user@rt02> show services rpm twamp client probe-results control-connection __r__2 Owner: __r__2, Test: __r__3 TWAMP-Server-Status: Light, Number-Of-Retries-With-TWAMP-Server: 0 Reflector address: 10.1.2.1, Reflector port: 862, Sender address: 10.1.2.2, sender-port: 52980 Test size: 10 probes Probe results: Response received Probe sent time: Tue Aug 16 20:08:50 2022 Probe rcvd/timeout time: Tue Aug 16 20:08:50 2022 Rtt: 138 usec, Egress jitter: 28 usec, Ingress jitter: -44 usec, Round trip jitter: -137 usec Egress interarrival jitter: 99 usec, Ingress interarrival jitter: 105 usec, Round trip interarrival jitter: 137 usec (snip) user@rt02> show isis database rt02.00-00 extensive IS-IS level 1 link-state database: IS-IS level 2 link-state database: rt02.00-00 Sequence: 0x1d6ea, Checksum: 0xf3cb, Lifetime: 1146 secs (snip) TLVs: (snip) IS extended neighbor: rt01.00, Metric: default 10 SubTLV len: 51 IP address: 10.1.2.2 Neighbor's IP address: 10.1.2.1 Local interface index: 349, Remote interface index: 26 Unidirectional link delay: 76 Min unidirectional link delay: 53 Max unidirectional link delay: 91 Unidirectional delay variation: 104 P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0,P:0), Weight:0, Label: 45 P2P IPv4 Adj-SID: 45, Weight: 0, Flags: --VL-- たた、各ルヌタヌにお察向から IS-IS でリンク遅延の広告が行われおいるこずを確認したす。 rt01 (IOS XR) RP/0/RSP0/CPU0:rt01#show isis database rt02.00-00 verbose Tue Aug 16 20:14:16.022 JST IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL rt02.00-00 0x0001b8fc 0xf246 1049 /1198 0/0/0 (snip) Metric: 10 IS-Extended rt01.00 Interface IP Address: 10.1.2.2 Neighbor IP Address: 10.1.2.1 Local Interface ID: 349, Remote Interface ID: 26 Link Average Delay: 76 us Link Min/Max Delay: 60/107 us Link Delay Variation: 119 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:45 (snip) rt02 (Junos) user@rt02> show isis database rt01.00-00 extensive IS-IS level 1 link-state database: IS-IS level 2 link-state database: rt01.00-00 Sequence: 0x9455, Checksum: 0x1a27, Lifetime: 630 secs (snip) TLVs: (snip) Extended IS Reachability TLV, Type: 22, Length: 159 IS extended neighbor: rt02.00, Metric: default 10 SubTLV len: 148 Local interface index: 26, Remote interface index: 349 IP address: 10.1.2.1 Neighbor's IP address: 10.1.2.2 Administrative groups: 0 <none> Maximum bandwidth: 10Gbps Maximum reservable bandwidth: 0bps Current reservable bandwidth: Priority 0 : 0bps Priority 1 : 0bps Priority 2 : 0bps Priority 3 : 0bps Priority 4 : 0bps Priority 5 : 0bps Priority 6 : 0bps Priority 7 : 0bps Traffic engineering metric: 10 Unknown sub-TLV type 252, length 32 Maximum bandwidth: 10Gbps Unidirectional link delay: 79 Min unidirectional link delay: 52 Max unidirectional link delay: 114 Unidirectional delay variation: 18 P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0,P:0), Weight:0, Label: 24009 P2P IPv4 Adj-SID: 24009, Weight: 0, Flags: --VL-- (snip) 考察 Cisco ルヌタヌ同士rt01-rt03 間、Juniper ルヌタヌ同士rt02-rt04 間で TWAMP を甚いおリンク遅延蚈枬をしたずころ、䞋蚘の蚈枬結果に衚瀺されおいるずおり遅延倀に倧きく差がありたした。これは掚枬ですが、TWAMP の Session-Reflector が動䜜する堎所の違いによるものだず考えられたす。 ※ このため、珟状 Multi-vendor 環境においお TWAMP によるリンク遅延実枬倀を甚いた Delay-Based TE は必ずしも実態ずしおの最短遅延パスを通るずは限らないず思われたす。 Cisco ルヌタヌ間のリンク遅延蚈枬結果 RP/0/RSP0/CPU0:rt01#show performance-measurement interfaces hundredGigE 0/0/0/20 brief Thu Aug 18 16:24:37.574 JST ---------------------------------------------------------------------------------------------------------------------------------------------------------------- 0/0/CPU0 ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Interface Name Tx/Rx Avg/Min/Max/Variance (uSec) -------------------------------------------------------------------------------------------------------------------------------------------------------------- HundredGigE0/0/0/20 6/6 3/3/4/0 Juniper ルヌタヌ間のリンク遅延蚈枬結果 user@rt02> show services rpm twamp client Connection Session Sender Sender Reflector Reflector Name Name address port address port __r__0 __r__1 10.1.8.1 58574 10.1.8.2 862 __r__2 __r__3 10.1.2.2 50830 10.1.2.1 862 user@rt02> show services rpm twamp client probe-results control-connection __r__0 Owner: __r__0, Test: __r__1 TWAMP-Server-Status: Light, Number-Of-Retries-With-TWAMP-Server: 0 Reflector address: 10.1.8.2, Reflector port: 862, Sender address: 10.1.8.1, sender-port: 58042 Test size: 10 probes Probe results: Response received Probe sent time: Thu Aug 18 16:25:39 2022 Probe rcvd/timeout time: Thu Aug 18 16:25:39 2022 Rtt: 449 usec, Egress jitter: 97 usec, Ingress jitter: 29 usec, Round trip jitter: 169 usec Egress interarrival jitter: 102 usec, Ingress interarrival jitter: 91 usec, Round trip interarrival jitter: 92 usec (snip) 次章では広告されたリンク遅延の倀を利甚しお Delay-Based TE を実装したす。 Delay-Based TE 動䜜怜蚌 本章では IS-IS によっお広告されたリンク遅延を甚いお TE を実装するための蚭定䟋を玹介したす。 なお、本蚘事では SR Policy の䜜成に On-Demand Next-HopODNず呌ばれる手法を利甚したす。 ODN は SR Policy を動的に生成可胜な仕組みです。SR Policy の生成条件ずなる color ず、パラメヌタである Segment Listexplicit or dynamicを定矩しおおくこずで、 IBGP で察象ずなる経路を受け取った際に BGP nexthop を endpoint ずした SR Policy を自動で生成できたす。 ODN を利甚するこずで、耇数の egress PE がある堎合でも endpoint ごずの SR Policy の蚭定が䞍芁ずなりたす。 トポロゞヌ 䞋蚘のようなトポロゞヌで怜蚌したす。本章においおは、リンク遅延Delay Metricは TE のわかりやすさのため図の通りに手動で蚭定したす。 リンク遅延は実枬倀ベヌスのため埀路ず埩路で非察称になり埗たす。本怜蚌では PE1 -> P1、P2 -> PE2 の片方向のみ倀を 100 ずし、他の Delay Metric は 10 ずしたす。 非察称な Metric によっお E2E の経路も非察称ずなるこずを確認したす。 このように Delay Metric を蚭定したネットワヌクにおいお Delay-Based TE を実装した堎合、次の図のような経路ずなるこずが想定されたす。PE1 -> PE2 ぞの転送時には Delay Metric の倧きいリンクを避ける経路ずなり、PE2 -> PE1 ぞの転送時にはリンクの Delay Metric が党お等しく最短経路ずなるためです。 物理構成や基本的な interface、IGP、BGP の蚭定は 第 1 回蚘事 をご参照ください。 怜蚌においお利甚する機噚は䞋蚘の通りです。 PE1、P1: Cisco IOS XR 7.4.1 PE2、P2: Junos 21.3R1.9 Delay Metric の手動蚭定ず確認 リンク遅延の実枬倀を利甚した堎合 TE の様子が分かりにくくなるため、各ルヌタヌにお手動で Delay Metric を付䞎したす。 PE1 (IOS XR) performance-measurement interface GigabitEthernet0/0/0/0 delay-measurement advertise-delay 100 ! ! interface GigabitEthernet0/0/0/1 delay-measurement advertise-delay 10 ! ! ! P1 (IOS XR) performance-measurement interface GigabitEthernet0/0/0/0 delay-measurement advertise-delay 10 ! ! interface GigabitEthernet0/0/0/1 delay-measurement advertise-delay 10 ! ! interface GigabitEthernet0/0/0/2 delay-measurement advertise-delay 10 ! ! ! P2 (Junos) set protocols isis interface ge-0/0/0.0 delay-metric 10 set protocols isis interface ge-0/0/1.0 delay-metric 100 set protocols isis interface ge-0/0/2.0 delay-metric 10 PE2 (Junos) set protocols isis interface ge-0/0/0.0 delay-metric 10 set protocols isis interface ge-0/0/1.0 delay-metric 10 Delay Metric が IS-IS にお広告されおいるこずを PE1 にお確認したす。 RP/0/RP0/CPU0:PE1#show isis database verbose Wed Aug 17 19:34:32.686 JST IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL PE1.00-00 * 0x0000068a 0xcd94 1016 /* 0/0/0 (snip) Metric: 10 IS-Extended P1.00 Local Interface ID: 7, Remote Interface ID: 7 Interface IP Address: 10.0.0.1 Neighbor IP Address: 10.0.0.2 Physical BW: 1000000 kbits/sec Link Average Delay: 100 us Link Min/Max Delay: 100/100 us Link Delay Variation: 0 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24003 Metric: 10 IS-Extended P2.00 Local Interface ID: 8, Remote Interface ID: 333 Interface IP Address: 10.0.1.1 Neighbor IP Address: 10.0.1.2 Physical BW: 1000000 kbits/sec Link Average Delay: 10 us Link Min/Max Delay: 10/10 us Link Delay Variation: 0 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24001 Hostname: PE1 P1.00-00 0x00000680 0x67b0 1197 /1200 0/0/0 (snip) Metric: 10 IS-Extended PE1.00 Local Interface ID: 7, Remote Interface ID: 7 Interface IP Address: 10.0.0.2 Neighbor IP Address: 10.0.0.1 Physical BW: 1000000 kbits/sec Link Average Delay: 10 us Link Min/Max Delay: 10/10 us Link Delay Variation: 0 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24005 Metric: 10 IS-Extended PE2.00 Local Interface ID: 8, Remote Interface ID: 333 Interface IP Address: 10.0.2.1 Neighbor IP Address: 10.0.2.2 Physical BW: 1000000 kbits/sec Link Average Delay: 10 us Link Min/Max Delay: 10/10 us Link Delay Variation: 0 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24003 Metric: 10 IS-Extended P2.00 Local Interface ID: 9, Remote Interface ID: 335 Interface IP Address: 10.0.4.1 Neighbor IP Address: 10.0.4.2 Physical BW: 1000000 kbits/sec Link Average Delay: 10 us Link Min/Max Delay: 10/10 us Link Delay Variation: 0 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24001 PE2.00-00 0x000006a3 0x86aa 1050 /1200 0/0/0 (snip) Metric: 10 IS-Extended P1.00 Interface IP Address: 10.0.2.2 Neighbor IP Address: 10.0.2.1 Local Interface ID: 333, Remote Interface ID: 8 Link Average Delay: 10 us Link Min/Max Delay: 10/10 us Link Delay Variation: 0 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:17 Metric: 10 IS-Extended P2.00 Interface IP Address: 10.0.3.1 Neighbor IP Address: 10.0.3.2 Local Interface ID: 334, Remote Interface ID: 334 Link Average Delay: 10 us Link Min/Max Delay: 10/10 us Link Delay Variation: 0 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:16 (snip) P2.00-00 0x000006aa 0xca39 1066 /1198 0/0/0 (snip) Metric: 10 IS-Extended PE1.00 Interface IP Address: 10.0.1.2 Neighbor IP Address: 10.0.1.1 Local Interface ID: 333, Remote Interface ID: 8 Link Average Delay: 10 us Link Min/Max Delay: 10/10 us Link Delay Variation: 0 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:17 Metric: 10 IS-Extended PE2.00 Interface IP Address: 10.0.3.2 Neighbor IP Address: 10.0.3.1 Local Interface ID: 334, Remote Interface ID: 334 Link Average Delay: 100 us Link Min/Max Delay: 100/100 us Link Delay Variation: 0 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:16 Metric: 10 IS-Extended P1.00 Interface IP Address: 10.0.4.2 Neighbor IP Address: 10.0.4.1 Local Interface ID: 335, Remote Interface ID: 9 Link Average Delay: 10 us Link Min/Max Delay: 10/10 us Link Delay Variation: 0 us ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:18 (snip) ODN による SR Policy の定矩 各 PE にお ODN を蚭定したす。 PE1 (IOS XR) segment-routing traffic-eng on-demand color 100 dynamic metric type latency ! ! ! ! ! PE2 (Junos) set routing-options dynamic-tunnels ODN-100 spring-te source-routing-path-template ODN-100-TMP color 100 set routing-options dynamic-tunnels ODN-100 spring-te destination-networks 0.0.0.0/0 set protocols source-packet-routing compute-profile DYNAMIC-DELAY metric-type delay set protocols source-packet-routing source-routing-path-template ODN-100-TMP primary odn_path compute DYNAMIC-DELAY BGP 経路に color 100 を付加するこずで動的に SR Policy が䜜成されたす。 color の付加方法は 第4回蚘事 を参照ください。 color 付加埌、Delay-Based TE のための SR Policy が䜜成されおいるこずが確認できたす。 PE1 (IOS XR) RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy Wed Aug 17 21:02:43.435 JST SR-TE policy database --------------------- Color: 100, End-point: 10.255.0.3 Name: srte_c_100_ep_10.255.0.3 Status: Admin: up Operational: up for 00:00:49 (since Aug 17 21:01:53.919) Candidate-paths: Preference: 200 (BGP ODN) (active) Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (valid) Metric Type: LATENCY, Path Accumulated Metric: 30 16003 [Prefix-SID, 10.255.0.4] 16001 [Prefix-SID, 10.255.0.2] 16002 [Prefix-SID, 10.255.0.3] Preference: 100 (BGP ODN) Requested BSID: dynamic PCC info: Symbolic name: bgp_c_100_ep_10.255.0.3_discr_100 PLSP-ID: 1 Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (pce) (invalid) Metric Type: NONE, Path Accumulated Metric: 0 Attributes: Binding SID: 24007 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no PE2 (Junos) user@PE2> show spring-traffic-engineering lsp detail Name: 10.255.0.1:64:dt-srte-ODN-100 Tunnel-source: Dynamic Tunnel Module(DTM) Tunnel Forward Type: SRMPLS Tunnel-template: ODN-100-TMP To: 10.255.0.1-100<c> State: Up Path: odn_path Path Status: NA Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:DYNAMIC-DELAY Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A TE metric: 110, IGP metric: 20 Delay metrics: Min: 20, Max: 20, Avg: 20 Metric optimized by type: Minimum-Delay computed segments count: 1 computed segment : 1 (computed-node-segment): node segment label: 16001 router-id: 10.255.0.1 疎通確認 traceroute を甚いお TE によるパケットの埀埩の転送経路を確認したす。 リンク遅延は実枬倀ベヌスのため埀路ず埩路で非察称になり埗たす。本怜蚌では PE1 -> P1、P2 -> PE2 の片方向のみ倀を 100 ずしたので PE1 -> PE2 の経路のみ PE1 - P1 ず P2 - PE2 のリンクを避ける経路ずなるはずです。 PE1 -> PE2 RP/0/RP0/CPU0:PE1#traceroute 192.168.1.254 vrf 100 Thu Aug 18 14:48:00.861 JST Type escape sequence to abort. Tracing the route to 192.168.1.254 1 10.0.1.2 [MPLS: Labels 16002/16003/16 Exp 0] 18 msec 3 msec 7 msec 2 10.0.4.1 [MPLS: Labels 16003/16 Exp 0] 23 msec 20 msec 19 msec 3 192.168.1.254 12 msec 2 msec 8 msec PE2 -> PE1 user@PE2> traceroute 192.168.0.254 routing-instance 100 traceroute to 192.168.0.254 (192.168.0.254), 30 hops max, 52 byte packets 1 10.0.3.2 (10.0.3.2) 2.729 ms 1.820 ms 1.731 ms MPLS Label=16001 CoS=0 TTL=1 S=0 MPLS Label=24004 CoS=0 TTL=1 S=1 2 10.0.1.1 (10.0.1.1) 14.716 ms * 11.153 ms 次の図のように、P1 -> PE1、PE2 -> P2 のリンク遅延を倧きくするこずで PE2 -> PE1 の経路も PE1 -> PE2 ず同じ経路を通るこずを確認したす。 PE2 [edit] user@PE2# set protocols isis interface ge-0/0/1.0 delay-metric 100 [edit] user@PE2# show | compare [edit protocols isis interface ge-0/0/1.0] - delay-metric 10; + delay-metric 100; P1 performance-measurement interface GigabitEthernet0/0/0/0 delay-measurement <- advertise-delay 10 +> advertise-delay 100 ! ! ! end 再床 PE2 -> PE1 で traceroute を行うず経路が倉わっおいるこずが確認できたす。 PE2 -> PE1 user@PE2> traceroute 192.168.0.254 routing-instance 100 traceroute to 192.168.0.254 (192.168.0.254), 30 hops max, 52 byte packets 1 10.0.2.1 (10.0.2.1) 8.389 ms 8.118 ms 10.108 ms MPLS Label=16004 CoS=0 TTL=1 S=0 MPLS Label=16001 CoS=0 TTL=1 S=0 MPLS Label=24004 CoS=0 TTL=1 S=1 2 10.0.4.2 (10.0.4.2) 2.344 ms 2.011 ms 1.516 ms MPLS Label=16001 CoS=0 TTL=1 S=0 MPLS Label=24004 CoS=0 TTL=2 S=1 3 10.0.1.1 (10.0.1.1) 13.928 ms * 13.418 ms たずめ 本蚘事では、遅延蚈枬技術である TWAMP ず Delay Metric を甚いお経路制埡をする Delay-Based TE に぀いお玹介したした。 たた Multi-vendor での TWAMP Light による遅延蚈枬や蚈枬結果の広告ず、TE の実装に぀いお動䜜怜蚌したした。 特に珟状では遅延蚈枬に察応できない機噚の組み合わせがありたした。 次回の蚘事では宛先 prefix 以倖をトリガにした SR Policy の適甚方法に぀いお玹介予定です。 2022/09/16 远蚘 公開したした [Multi-AS Segment Routing 怜蚌連茉 #8] SR Policy の適甚方法ず掻甚 IS-IS TE Metric Extensions: https://tex2e.github.io/rfc-translater/html/rfc8570.html ↩ OSPF TE Metric Extensions: https://tex2e.github.io/rfc-translater/html/rfc7471.html ↩ TWAMP Light: https://www.rfc-editor.org/rfc/rfc5357.html#appendix-I ↩
目次 目次 はじめに MMDetectionずは MMDeployずは 実隓内容 利甚したモデル 蚈枬結果 たずめ はじめに むノベヌションセンタヌの加藀です。普段はコンピュヌタビゞョンの技術開発やAI/MLシステムの怜蚌に取り組んでいたす。 今幎登堎したJetsonの最新版モデル「Jetson AGX Orin」は、前䞖代である「Jetson AGX Xavier」シリヌズの最倧8倍のパフォヌマンス 1 、ビゞョンや自然蚀語凊理など様々な孊習枈みモデルにおいおは最倧5倍の高速化 2 が謳われおおり、゚ッゞデバむス䞊で動かせるAIアプリケヌションの幅がかなり広がりそうです。普段メディアAIに取り組んでいる私ずしおはどのレベルたでの物䜓怜出モデルが゚ッゞ䞊で動かせるようになったのかが気になりたした。そこで本蚘事ではMMDetectionの提䟛する物䜓怜出モデルを NVIDIA TensorRT を甚いお各デバむス䞊で最適化し、COCO Val 2017デヌタセットを甚いおモデルの掚論速床を調査したした。 MMDetectionずは https://github.com/open-mmlab/mmdetection MMDetectionは OpenMMLab の提䟛する物䜓怜出ツヌルボックスです。゜ヌスコヌドだけでなく孊習枈みモデルも公開されおいるので、さたざたなモデルを䜿っお物䜓怜出の掚論ができたす。 このツヌルボックスは PyTorch ベヌスですが、各Jetsonデバむスの性胜をめいっぱい掻かすために、MMDeployずいうツヌルを甚いお孊習枈みモデルをTensorRTモデルに倉換しおから速床を蚈枬したした。 MMDeployずは https://github.com/open-mmlab/mmdeploy MMDeployはMMDetection同様にOpenMMLabが提䟛するツヌルで、OpenMMLab補のモデルを ONNX やTensorRTなどのバック゚ンド甚に倉換しお利甚できたす。物䜓怜出のMMDetectionだけでなく、分類( MMClassification )やセグメンテヌション( MMSegmentation )、姿勢掚定( MMPose )などのモデルにも察応しおいたす。 実は以前たでは内郚で䜿われおいるビルドオプションの郜合䞊Orinに察応したバむナリがビルドできずMMDeployをOrinで䜿うにはひず手間必芁でしたが、私の プルリク゚スト によりversion 0.6以降はデフォルトの蚭定で利甚できるようになっおいたす :) 実隓内容 䜿甚したデバむスは以䞋の2点です。 Jetson AGX Xavier Jetson AGX Orin 32GB いずれのデバむスにも NVIDIA JetPack SDK 5.0を導入しおいたす。 評䟡デヌタセットは5000枚の画像からなる COCO Val 2017 を䜿いたした。 そしおMMDeployは倉換したモデルの ベンチマヌクを蚈枬するこずができる ので、本蚘事ではこの機胜を甚いおXavierずOrinそれぞれにおけるTensorRTモデルの掚論速床(FPS)を蚈枬したした。 実隓コヌドは こちら にアップロヌドしおいたすので参考にしおください。 利甚したモデル 実隓に䜿甚したモデルの䞀芧を瀺したす。configリンクは党おMMDetectionのリポゞトリ内のコンフィグファむルを指しおおり、そのコンフィグファむルが眮いおあるディレクトリのREADMEでモデルの抂芁を芋るこずができたす。 モデル名(バックボヌン) 入力サむズ box AP link YOLOV3(DarkNet53) 320x320 27.9 config SSD300(VGG16) 300x300 25.5 config RetinaNet(ResNet50) 800x1333 36.5 config FCOS(ResNet50) 800x1333 36.6 config FSAF(ResNet50) 800x1333 37.4 config YOLOX-s 640x640 40.5 config Faster R-CNN (ResNet50) 800x1333 37.4 config ATSS (ResNet50) 800x1333 39.4 config Cascade R-CNN (ResNet50) 800x1333 40.4 config GFL(ResNet50) 800x1333 40.2 config Cascade Mask R-CNN (ResNet50) 800x1333 41.2 config Mask R-CNN (ResNet50) 800x1333 38.2 config Mask R-CNN (Swin Transformer) 800x1333 42.7 config 蚈枬結果 Swin Transformerをバック゚ンドにしたMask R-CNNはただただOrin䞊でも厳しそうですが、その他のモデルでは半粟床化するこずによっお20-30FPSずほがリアルタむムに動䜜させられるこずがわかりたした。 AGX Xavierず比范するず、どのモデルにおいおも倧きな速床向䞊が芋られ、最小でも2.5倍、最倧で10倍近い高速化が芋られたす。 䞀方で単玔蚈算なら凊理速床が2倍になるはずの半粟床化(fp16)の恩恵はAGX Xavierが倧きく、AGX Orinではあたり速床が䌞びたせんでした。メモリアクセスが間に合っおおらず性胜を出しきれおいないずいうのが仮説の1぀ずしお挙げられたすが、より詳现な調査が必芁そうです。 たずめ 本蚘事では様々な物䜓怜出モデルをAGX XavierずAGX Orinで動かし、Jetson最新モデルのAGX Orinがどれくらい性胜向䞊したかを調査したした。するず今たで゚ッゞ䞊ではリアルタむム凊理に䜿えなかった高解像床・高性胜なモデルが、AGX Orinでは珟実的な凊理速床を実珟しおいるこずがわかりたした。これは今たでの゚ッゞ甚AIアプリケヌションの性胜向䞊に぀ながるだけでなく、遠くの物や小さいものをリアルタむムに怜知する必芁があるタスクにおいおもスタンドアロヌンで凊理可胜になるこずも考えられ、自動運転のようにカメラに写る物䜓の遠近のレンゞが倧きい環境や、矀衆の混雑床監芖のように広い範囲に现々ずした物䜓が倧量に写る環境などずいった解像床がネックになるタスクでも゚ッゞAIが戊えるようになりそうです。 https://www.nvidia.com/ja-jp/autonomous-machines/embedded-systems/jetson-orin/ ↩ https://youtu.be/hHDZV1V4zq8?t=379 ↩
目次 はじめに SDP開発ずは SDP開発ずは SSS/SDPフレヌムワヌク ICGW-SDP基盀 党䜓構成 CI/CD ICGWの可芖化 APIリク゚スト数 リ゜ヌス利甚状況 おわりに はじめに こんにちは、5G & IoT郚/IoTサヌビス郚門のIoT Connect Gateway (ICGW)サヌビス開発チヌムの岩田です。 我々のチヌムでは2021幎床䞋期に私の䞻導のもず、ICGWのSDP開発ずいうものを行い、 Smart Data Platform (SDPF)ポヌタル察応 およびSDPF䞊で展開しおいる他のサヌビスずの自動連携を実珟したした。 本蚘事ではこのICGWのSDP開発に焊点を圓おお、開発背景や党䜓構成ならびにCI/CDを玹介したす。 たた、ICGWの可芖化関連の情報も合わせお掲茉したすので、今埌の開発のご参考になれば幞いです。 ICGWのサヌビス自䜓やナヌスケヌスに関しお、過去の蚘事で玹介しおいたすのでご参照ください。 IoT Connect Gateway を䜿っおみた 第1回 〜ICGWのご玹介〜 IoT Connect Gateway を䜿っおみた 第3回 〜芳葉怍物育成状況の可芖化〜 SDP開発ずは サヌビス開発における背景 図1 埓来のNTT Comずオンラむンサヌビス時代のサヌビス開発むメヌゞ 埓来のNTT Comのサヌビスでは、サヌビスのコアずなる技術芁玠のみが開発の察象ずなっおおり、そのサヌビスをナヌザに届けお察䟡を埗る郚分はプロセス敎備ずしお扱われ開発の䞻な察象ではありたせんでした。 しかし、近幎サヌビスのオンラむン化やセルフマネゞメント化が匷く掚進される䞭で開発しなければならない範囲は拡倧し続けおいたす。 ナヌザがサヌビスのセルフマネゞメントを行うためのAPI/GUI、それらを提䟛するための認蚌/暩限管理機構、ナヌザのサヌビス利甚状況の管理/システム化などが必芁ずなっおきたす。 たた、サヌビスぞの申蟌みや料金蚈算をオンラむン化/自動化したい堎合はさらに開発察象の範囲は広がりたす。 SSS/SDPフレヌムワヌク SDPFポヌタルで展開するサヌビスを開発する䞊で欠かせないSSS/SDPずいうフレヌムワヌクを玹介したす。 SSS は「Shared Support Service」、 SDP は「Service Delivery Platform」の略語でNTT Comの甚語です。 このフレヌムワヌクにおいお、各SDPは サヌビスのコアになる技術 ず それをナヌザが利甚するためのIFGUI/API の開発に集䞭し、SSSがその土台ずなる契玄の申し蟌み、契玄管理、認蚌の基盀やナヌザ暩限管理、料金蚈算等を䞀手に担いたす。 SSS/SDPフレヌムワヌクに則り開発を進めるこずで、それぞれの圹割を明確に分担しお重耇開発を避けられるずいうアむディアになっおいたす。 SSSや他のSDPずやり取りするための統䞀的な芏栌にサヌビス仕様を合わせるこずを我々のチヌムではSDP開発ず呌んでいたす。 SDP開発によっお我々のICGWにおいおも、サヌビス運甚やナヌザ利䟿性の面においお倚くのメリットをもたらしたした。 図2 ICGWにおけるSDP開発のBefore/After 図3はSDP開発によっお新芏に実装されたGUIのサンプルです。 ナヌザが蚭定を投入するためのペヌゞだけでなく、利甚状況を芖芚的に衚珟したペヌゞを提䟛するこずによっお利䟿性向䞊を図っおいたす。 図3 SDP開発による新芏提䟛GUI ICGW-SDP基盀 ICGW党䜓構成 図4 ICGW党䜓構成 ICGWは倧きく分けお ICGW-core基盀 ず ICGW-SDP基盀 の2぀からなっおいたす。 ICGW-core基盀はSDP開発前から存圚しおいるもので、デバむスからのデヌタが流れるデヌタプレヌンやSO APIを提䟛しおいたす。 ICGW-SDP基盀はSDP開発時に新蚭されたもので、ナヌザが蚭定を投入するためのGUIやAPI、SSSや他SDPず連携するためのAPIなどを提䟛しおいたす。 もずもずICGWはSDPに察応しない圢でサヌビスリリヌスしたため、サヌビスのコアずなる郚分はすでに出来おいたした。 そのため、ICGW-SDP基盀では特にナヌザIFに泚力する圢での開発ずなりたした。 ICGW-SDP基盀のAPIは裏偎でSO APIをコヌルしおおり、基本的にナヌザのリク゚ストをそのたた裏ぞ流し、必芁に応じおSDPの芏栌を満たすようにリク゚スト内容を加工できるような蚭蚈になっおいたす。 実際にこのような二段構成で運甚しおみたずころ、いく぀かのメリットがありたしたので列挙しおおきたす。 ICGW-SDP基盀ではナヌザビリティ向䞊に泚力しお開発できる ICGW-SDP基盀で察応しない限りナヌザに芋えるこずはないので、ICGW-core基盀での新芏機胜開発がやりやすい サヌビス仕様やナヌザビリティの芳点でナヌザに芋せたくない情報があった堎合に、それらをICGW-SDP基盀偎でコントロヌルしやすい CI/CD 我々のチヌムでは GUI開発 、 API開発 、 CI/CD ずもにNTT Comの内補ツヌルであるQmonusシリヌズずいうものを利甚しおいたす。 特にCI/CDを叞る Qmonus Value Stream (Qmonus VS)に関しおは、開発者ブログに玹介蚘事がありたすので、詳现はそちらをご芧ください。 [DevOpsプラットフォヌムの取り組み #1] Qmonus Value Streamの玹介 図5は実際のQmonus VSの画面で、新しいバヌゞョンのAPIをステヌゞング環境にデプロむした時の様子です。 Qmonus VSは基本的にGitのブランチマヌゞをトリガヌに、いく぀かのステップを経おデプロむが実行されたす。 ICGWチヌムでは特にAPIをデプロむする際に、APIの自動詊隓が実行されるようにステップを構成しおおり、テストをパスしなければロヌルバックするずいう実装になっおいたす。 図5 Qmonus Value StreamにおけるAPIデプロむ時の画面 GUIの自動詊隓に関しおはGithub Actionsを採甚しおおり、同じくブランチマヌゞや任意のタむミングで詊隓を実斜できるようになっおいたす。 たた、図6のようにダッシュボヌドを掻甚するこずで、詊隓䞭のスナップショットや動画を保存し共有できるような機構も珟圚蚈画䞭です。 図6 GUI自動詊隓の結果画面 ICGWの可芖化 SDP開発に䌎い、私の方で開発者/䌁画者向けにいく぀かの可芖化ポヌタルをGCPを掻甚しお䜜成しおみたしたので、この堎でご玹介したす。 APIリク゚スト数 図7 APIリク゚スト数可芖化ポヌタル こちらはAPIのリク゚スト数をレスポンスコヌドごずに可芖化したグラフです。 ICGW-SDP基盀で提䟛しおいるIFがどの時間垯にどれくらい利甚されおいるか、500番゚ラヌが倚発しおいないかずいった芳点のために䜜成したした。 たた、゚ラヌの内容からナヌザの間違えやすい傟向なども分析でき、ナヌザビリティ向䞊にも掻甚できたす。 アラヌト機胜ず組み合わせるこずで、リク゚スト数の条件に応じおメヌルやSlack通知を発行するこずも可胜です。 図8が可芖化のための党䜓アヌキテクチャです。以䞋のステップで構成しおいたす。 ナヌザのAPIリク゚ストログをLoggingに転送する レスポンスコヌドごずに該圓のログを抜出できるようにフィルタを远加する ステップ2で抜出したログに察しおMonitoring䞊でカりントしグラフ化する 図8 APIリク゚スト数可芖化甚アヌキテクチャ リ゜ヌス利甚状況 図9 リ゜ヌス利甚状況可芖化ポヌタル こちらは党ナヌザの蚭定情報やトラフィック情報をもずに、リ゜ヌスの利甚状況ずサヌビスごずのトラフィック量を時系列的に可芖化したポヌタルです。 どれくらいの数のナヌザがどのサヌビスを䜿っおいるかずいう垂堎分析甚途で䜜成したした。 これらのグラフは開発者だけでなく䌁画者にもサヌビス展開を考える䞊でご掻甚いただいおいたす。 図10が可芖化のための党䜓アヌキテクチャです。以䞋のステップで構成しおいたす。 必芁なデヌタを抜出するための゜ヌスコヌドをStorageに保存する Functionsをビルドする SchedulerからFunctionsが定期的に実行される Funtionsによっお抜出された各皮デヌタをBigQueryに保存する BigQueryに保存されたデヌタをData Studioで可芖化する 図10 リ゜ヌス利甚状況可芖化甚アヌキテクチャ これらの構成は党おIaaSずしおTerraform管理されおおり、゜ヌスコヌドに倉曎が加わった堎合はステップ1/2が自動で実行されるようになっおいたす。 FunctionsからICGW基盀ぞAPIコヌルを行う際に、VPCを経由しおCloud NATから出おいくこずで倖郚IPを固定でき、ICGW基盀偎でのアクセスコントロヌルが容易になっおいたす。 Data Studioは同じくGoogleが提䟛しおいる可芖化ポヌタルで、暩限があればBigQueryに保存されたデヌタも容易に読み蟌むこずができ、デヌタの曎新も自動で行っおくれたす。 たた、䜜成した可芖化ポヌタルは共有リンクを取埗するこずで簡単にチヌムメンバヌぞ展開できたす。 おわりに ICGW SDP開発のリヌダヌずしお、今回は開発の裏偎()を玹介したした。 私自身は開発やCI/CDに関しおただただ勉匷途䞭であり、詊行錯誀しながら挑戊しおいるずころなので、より良い手法や開発スタむルがあれば取り蟌んでいきたいです。 たた、今回の可芖化ポヌタルのように、実際に構成を考えお自分の手を動かしおシステムを䜜っおいくこずには今埌も挑戊できたらず思いたす。 本蚘事を通しお、ICGWにも興味を持っおいただけたら幞いです IoT Connect Gatewayサヌビス詳现はこちら
サマリ Flexible Algorithm による VPN 経路の TE を実珟 IOS XR + Junos の Multi-vendor 環境で動䜜怜蚌に成功 この蚘事は Multi-AS SR 怜蚌連茉の第 6 回です。目次は こちら 抂芁 むノベヌションセンタヌの田島です。 本蚘事では Flexible Algorithm を甚いた Traffic Engineering に぀いお解説したす。 Flexible Algorithm で蚈算された最適経路によっお L3VPN の転送が行われる䟋や、トポロゞヌが倉化しおも制玄を満たす経路が自動で再蚈算される䟋を怜蚌で瀺したす。 これたでの蚘事でも玹介したように TE を実斜する堎合においお、察象が L3VPN ず L2VPN ずでは差異が無いため、本蚘事の内容は L2VPN でも適甚可胜です。 なお Flexible Algorithm の略称ずしおは Flex-Algo、Flex Algo、Flex-Algorithm などが存圚したす。本蚘事䞭で略蚘する堎合は以䞋 Flex-Algorithm ず衚蚘したす。 本蚘事では Flex-Algorithm に぀いおの説明ず、ルヌタヌでの動䜜怜蚌を玹介したす。 Flexible Algorithm ずは Flexible Algorithm ずは IGP での経路蚈算時に耇数の異なるメトリックや制玄を付け加え、耇数の基準による最適経路を䞊行しお決定し䜿甚するための技術です。 リンクのメトリックずは垯域幅を基にしたコスト、遅延、たたは TE 甚のコストのこずです。 制玄ずは䞀郚のリンクを䜿甚しないような状況のこずです。 埓来の IGP では、リンクコストを基にし党リンクを䜿甚可胜な堎合の最適経路のみを蚈算可胜でしたが、 Flex-Algorithm により耇数の指暙を䜿い分けるこずができ、たた仮想的にアンダヌレむの䞀郚に限定しお通信させるこずができたす。 䟋えば、リンク垯域を基にした最適経路ずリンク間遅延を基にした最適経路をそれぞれ Flex-Algorithm で定矩し、各 Algorithm を利甚するための SR Policy を定矩しおおきたす。 第 4 回の蚘事 のように BGP color 等によっおこれらの SR Policy を遞択するこずで Flex-Algorithm の適甚ができたす。 このように最適化させたい意図ごずに仮想的にアンダヌレむを分割し遞択するこずで、各通信の性質や芁求ごずに適切なアンダヌレむおよび最適なパスでの通信が実珟されたす。 Flex-Algorithm により区別されたトポロゞヌは128から255たで番号を぀けるこずができ、 メトリックの皮類やトポロゞヌ制玄の蚘述などずずもに定矩されたす。 各リンクに属性を割り圓お、特定の属性のリンクを含むか、たたは含たないかで制玄が蚘述されたす。 この属性を color ず衚蚘し、本蚘事で埌述する䟋でも RED や BLUE のようにリンクを区別したす。 なお 第 4 回の蚘事 に BGP color の説明がありたしたが、別物です。 Flex-Algorithm の color は、各属性を1ビットず芋立おお割り圓おられおいれば1に察応するビットマップずしお実装され Extended Administrative Group (EAG) や Administrative Group (AG) の倀ずしお保存されたす。 これらの情報からなる定矩は Flexible Algorithm Definition (FAD) ず呌ばれ、 IGP により広告されたす。 Flex-Algorithm は IETF Network Working Group での Internet-Draft 1 段階の技術であり、2022幎8月時点では完党に暙準化されおいる方匏ではありたせん。 しかし、各瀟のルヌタヌ補品やオヌプン゜ヌス補品などにおいお実装が始たっおいたす。 FAD の広告には EAG や AG などの Type Length Value (TLV) を䜿甚したすが、䜿甚する TLV や Sub-TLV を盞互に認識可胜で無ければ盞互接続ができたせん。 実際に Extended Administrative Group や Application-Specific Link Attribute の解釈が違うこずで意図した動䜜にならないこずがありたしたが、 IOS XR 7.4.1 ず Junos 21.3 以降の組み合わせでは盞互運甚できるこずを確かめたした。 Flex-Algorithm の動䜜䟋 Flex-Algorithm の動䜜をトポロゞヌ䟋を甚いお説明したす。 図の䞭倮䞊郚にアンダヌレむトポロゞヌを蚘茉しおいたす。 PE 2台、 P 2台の各リンクに察しお RED ず BLUE のラベル、 IGP メトリックず TE メトリックを蚭定しおいたす。 このアンダヌレむで 2 ぀の Flex-Algorithm を䜜成したす。 Algorithm 128 : RED リンクは䜿甚犁止。 IGP メトリックに埓っお最適経路を算出する。 Algorithm 129 : BLUE リンクのみを䜿甚する。 TE メトリックに埓っお最適経路を算出する。 それぞれ図の巊䞋ず右䞋のような、制玄が反映され指定のメトリックが぀いたトポロゞヌずしお仮想的に認識されたす。 この状態で転送経路ずしおどちらかの Algorithm を遞択するず、それぞれの仮想的なトポロゞヌ内での最適経路に埓っお転送されたす。 Algorithm を明瀺的や自動的に遞択するために SRGB をそれぞれ分けたす。 䟋えばこの䟋だず Algorithm 128 偎を SRGB 17000 から、 129 偎を 18000 からずいうように蚭定したす。 これにより Algorithm を指定した宛先の指定ができたす。 リンク障害などで元のアンダヌレむトポロゞヌから倉化した堎合でも、それぞれの Algorithm ごずに再蚈算されたす。 これは自動蚈算されるバックアップパスも Algorithm の制玄に埓うこずを意味したす。 しかし気を付けるべき点もありたす。制玄を入れた埌のトポロゞヌで単䞀障害点ずなるリンクが存圚するような非冗長な堎合においお、そのリンクが障害状態になるず圓該 Algorithm はネットワヌクが分断され䞍通になっおしたいたす。 実際のアンダヌレむが問題なく冗長化されおいお通信継続させたい堎合は、圓該 Algorithm の䜿甚を指定する SR Policy の定矩などでフォヌルバック先を指定しおおく必芁がありたす。 Flex-Algorithm の適甚怜蚌 実際に Flex-Algorithm を甚いお TE を実装したす。 抂芁郚分での説明に甚いた次の図のトポロゞヌを䜿甚し Algorithm 128 を蚭定したす。 なお、次節で障害時の動䜜を確かめたす。 このアンダヌレむで RED リンクを䜿甚せず IGP メトリックに埓う Algorithm 128 を定矩したす。 あらかじめ顧客 A の BGP 経路には BGP color 100 を぀けおおき、定矩した Algorithm 128 を顧客 A の VPN 経路に䜿甚したす。 転送経路は次のように衚せ、これを実装したす。 なお 129 を実装しない理由ずしおは FAD の解釈にメヌカヌ差があり想定の経路ぞは TE されないためです。 2023/09/19 远蚘本蚘事公開埌の OS のバヌゞョンアップによっお FAD の盞互運甚ができるようになりたした。 第 15 回 の蚘事を参照ください。 怜蚌に甚いたバヌゞョンは䞋蚘の通りです。 PE1、P1: Cisco IOS XR 7.4.1 PE2、P2: Junos OS 21.3R1.9 第 4 回の蚘事 の通りに L3VPN および BGP color の SR Policy を䜜成したす。実斜内容は䞋蚘の通りで、詳しくはリンク先蚘事を参照ください。 VRF 100 ず 200 による L3VPN 䜜成 BGP color の付䞎ず広告 BGP color による SR Policy の適甚 ここからは次のステップで蚭定し確認したす。 リンクに察する制玄やメトリックの定矩 Flex-Algorithm 128 の定矩 ラベル孊習の確認 SR Policy の蚭定ず確認 traceroute による VPN の通信経路確認 1. リンクに察する制玄やメトリックの定矩 各ルヌタヌにおむンタヌフェヌスに察し Flex-Algorithm の color ず IGP および TE のメトリックを指定したす。 color はビットマップでフラグ管理されるため、各色で䜕ビット目を甚いるかの定矩がそれぞれのルヌタヌに必芁です。 今回は行きず垰りの経路を察象にするため 1 ぀のリンクに察しお䞡端のルヌタヌで同じ蚭定にしたす。 PE に関しおは VPN の next-hop ずしお Loopback むンタヌフェヌスが䜿甚されるため、特定の color のリンクのみを䜿甚するずいった制玄を意味する include-any や include-all を甚いる際は Loopback に圓該 color を忘れずに付ける必芁がありたす。 BLUE は最終的に本怜蚌で䜿甚したせんが、蚭定方法の参考ずしお同時に蚭定したす。 PE1 (IOS XR) P1 向け Gi0/0/0/0 を RED か぀ BLUE にしたす PE であるため Loopback0 に BLUE を぀けたす router isis 1 affinity-map RED bit-position 1 affinity-map BLUE bit-position 2 ! interface Loopback0 affinity flex-algo BLUE ! interface GigabitEthernet0/0/0/0 affinity flex-algo RED BLUE address-family ipv4 unicast metric 10 ! ! interface GigabitEthernet0/0/0/1 address-family ipv4 unicast metric 10 ! ! ! segment-routing traffic-eng interface GigabitEthernet0/0/0/0 metric 10 ! interface GigabitEthernet0/0/0/1 metric 10 ! ! ! P1 (IOS XR) PE1 向け Gi0/0/0/0 を RED か぀ BLUE にしたす PE2 向け Gi0/0/0/1 ず P2 向け Gi0/0/0/2 を BLUE にしたす router isis 1 affinity-map RED bit-position 1 affinity-map BLUE bit-position 2 ! interface GigabitEthernet0/0/0/0 affinity flex-algo RED BLUE address-family ipv4 unicast metric 10 ! ! interface GigabitEthernet0/0/0/1 affinity flex-algo BLUE address-family ipv4 unicast metric 10 ! ! interface GigabitEthernet0/0/0/2 affinity flex-algo BLUE address-family ipv4 unicast metric 10 ! ! ! segment-routing traffic-eng interface GigabitEthernet0/0/0/0 metric 10 ! interface GigabitEthernet0/0/0/1 metric 100 ! interface GigabitEthernet0/0/0/2 metric 10 ! ! ! PE2 (Junos) P1 向け ge-0/0/0 ず P2 向け ge-0/0/1 を BLUE にしたす PE であるため lo0 に BLUE を぀けたす set protocols isis interface ge-0/0/0.0 level 2 te-metric 100 set protocols isis interface ge-0/0/0.0 level 2 application-specific attribute-group Algo129 admin-group BLUE set protocols isis interface ge-0/0/0.0 level 2 application-specific attribute-group Algo129 application flex-algorithm set protocols isis interface ge-0/0/0.0 level 2 metric 10 set protocols isis interface ge-0/0/1.0 level 2 te-metric 10 set protocols isis interface ge-0/0/1.0 level 2 application-specific attribute-group Algo129 admin-group BLUE set protocols isis interface ge-0/0/1.0 level 2 application-specific attribute-group Algo129 application flex-algorithm set protocols isis interface ge-0/0/1.0 level 2 metric 10 set protocols isis interface lo0.0 level 2 application-specific attribute-group Algo129 admin-group BLUE set protocols isis interface lo0.0 level 2 application-specific attribute-group Algo129 application flex-algorithm set protocols mpls admin-groups RED 1 set protocols mpls admin-groups BLUE 2 set protocols mpls interface ge-0/0/0.0 admin-group BLUE set protocols mpls interface ge-0/0/1.0 admin-group BLUE set protocols mpls interface lo0.0 admin-group BLUE P2 (Junos) P1 向け ge-0/0/1 ず PE2 向け ge-0/0/2 を BLUE にしたす set protocols isis interface ge-0/0/0.0 level 2 te-metric 10 set protocols isis interface ge-0/0/0.0 level 2 metric 10 set protocols isis interface ge-0/0/1.0 level 2 te-metric 10 set protocols isis interface ge-0/0/1.0 level 2 application-specific attribute-group Algo129 admin-group BLUE set protocols isis interface ge-0/0/1.0 level 2 application-specific attribute-group Algo129 application flex-algorithm set protocols isis interface ge-0/0/1.0 level 2 metric 100 set protocols isis interface ge-0/0/2.0 level 2 te-metric 10 set protocols isis interface ge-0/0/2.0 level 2 application-specific attribute-group Algo129 admin-group BLUE set protocols isis interface ge-0/0/2.0 level 2 application-specific attribute-group Algo129 application flex-algorithm set protocols isis interface ge-0/0/2.0 level 2 metric 10 set protocols mpls admin-groups RED 1 set protocols mpls admin-groups BLUE 2 set protocols mpls interface ge-0/0/1.0 admin-group BLUE set protocols mpls interface ge-0/0/2.0 admin-group BLUE 2. Flex-Algorithm 128 の定矩 Algorithm 128 を定矩し広告したす。 䞋蚘では各ルヌタヌごずに掲瀺しおいたすが、同じものが蚭定されたす。 Algorithm ごずの転送に甚いるため、各 Node-SID も Algorithm ごずに付䞎したす。 ここでは Algorithm 128 は 17000 番台ぞず空間を分けおいたす。 䞋蚘蚭定では比范をわかりやすくするために、 Algorithm が぀いおいない元の Node-SID の蚭定も残しおいたす。 PE1 (IOS XR) router isis 1 flex-algo 128 advertise-definition affinity exclude-any RED ! interface Loopback0 address-family ipv4 unicast prefix-sid index 1 prefix-sid algorithm 128 index 1001 ! ! ! P1 (IOS XR) router isis 1 flex-algo 128 advertise-definition affinity exclude-any RED ! interface Loopback0 address-family ipv4 unicast prefix-sid index 2 prefix-sid algorithm 128 index 1002 ! ! ! PE2 (Junos) Junos においお RSVP などのシグナリングが別に動䜜しおいないずきはドキュメントに埓い set protocols isis traffic-engineering advertisement always が必芁です。 set policy-options policy-statement Flex-Algo-SID term 1 from route-filter 10.255.0.3/32 exact set policy-options policy-statement Flex-Algo-SID term 1 then prefix-segment algorithm 128 index 1003 set policy-options policy-statement Flex-Algo-SID term 1 then prefix-segment algorithm 128 node-segment set routing-options flex-algorithm 128 definition metric-type igp-metric set routing-options flex-algorithm 128 definition spf set routing-options flex-algorithm 128 definition admin-group exclude RED set protocols isis source-packet-routing node-segment ipv4-index 3 set protocols isis source-packet-routing flex-algorithm 128 set protocols isis source-packet-routing strict-asla-based-flex-algorithm set protocols isis traffic-engineering advertisement always set protocols isis export Flex-Algo-SID P2 (Junos) set policy-options policy-statement Flex-Algo-SID term 1 from route-filter 10.255.0.4/32 exact set policy-options policy-statement Flex-Algo-SID term 1 then prefix-segment algorithm 128 index 1004 set policy-options policy-statement Flex-Algo-SID term 1 then prefix-segment algorithm 128 node-segment set routing-options flex-algorithm 128 definition metric-type igp-metric set routing-options flex-algorithm 128 definition spf set routing-options flex-algorithm 128 definition admin-group exclude RED set protocols isis source-packet-routing node-segment ipv4-index 4 set protocols isis source-packet-routing flex-algorithm 128 set protocols isis source-packet-routing strict-asla-based-flex-algorithm set protocols isis traffic-engineering advertisement always set protocols isis export Flex-Algo-SID 3. ラベル孊習の確認 䞊蚘蚭定が完了するず FAD の広告がされるため、各ルヌタヌで各 Algorithm の情報を芋るこずができたす。 FAD の内容ず、ラベルが孊習されおいるのかを確認したす。 PE1 (IOS XR) PE1 自身の広告内容を確認したす。 FAD の定矩内容や隣接である P1 ぞのリンクの color が芋えたす。 なおビットマップのため RED は 1 << 1 = 0x2 ずなり、 BLUE は 1 << 2 = 0x4 ずなり、 RED か぀ BLUE は 0x2 & 0x4 = 0x6 ず衚珟されたす。 RP/0/RP0/CPU0:PE1#show isis database verbose Mon Aug 15 10:50:02.431 JST IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL PE1.00-00 * 0x000007ed 0xe7e5 1067 /* 0/0/0 Area Address: 49.0000 NLPID: 0xcc IP Address: 10.255.0.1 Metric: 10 IP-Extended 10.0.0.0/30 Prefix Attribute Flags: X:0 R:0 N:0 E:0 A:0 Metric: 10 IP-Extended 10.0.1.0/30 Prefix Attribute Flags: X:0 R:0 N:0 E:0 A:0 Metric: 10 IP-Extended 10.255.0.1/32 Prefix-SID Index: 1, Algorithm:0, R:0 N:1 P:0 E:0 V:0 L:0 Prefix-SID Index: 1001, Algorithm:128, R:0 N:1 P:0 E:0 V:0 L:0 Prefix-SID Index: 2001, Algorithm:129, R:0 N:1 P:0 E:0 V:0 L:0 Prefix Attribute Flags: X:0 R:0 N:1 E:0 A:0 Source Router ID: 10.255.0.1 Hostname: PE1 Router ID: 10.255.0.1 Router Cap: 10.255.0.1 D:0 S:0 Segment Routing: I:1 V:0, SRGB Base: 16000 Range: 8000 SR Local Block: Base: 15000 Range: 1000 Node Maximum SID Depth: Label Imposition: 10 SR Algorithm: Algorithm: 0 Algorithm: 1 Algorithm: 128 Algorithm: 129 Flex-Algo Definition: Algorithm: 128 Metric-Type: 0 Alg-type: 0 Priority: 128 Flex-Algo Exclude-Any Ext Admin Group: 0x00000002 Flex-Algo Definition: Algorithm: 129 Metric-Type: 0 Alg-type: 0 Priority: 128 Flex-Algo Include-Any Ext Admin Group: 0x00000004 Metric: 10 IS-Extended P1.00 (snip) Application Specific Link Attributes: L flag: 0, SA-Length: 1, UDA-Length: 1 Standard Applications: 0x10 FLEX-ALGO User Defined Applications: 0x10 Ext Admin Group: 0x00000006 Affinity: 0x00000006 ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24003 (snip) 元々の Node-SID だけではなく、各 Algorithm で蚭定した Node-SID も孊習されおいたす。 RP/0/RP0/CPU0:PE1#show mpls forwarding Mon Aug 15 11:07:47.194 JST Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched ------ ----------- ------------------ ------------ --------------- ------------ (snip) 16003 16003 SR Pfx (idx 3) Gi0/0/0/0 10.0.0.2 5416 (snip) 17003 17003 SR Pfx (idx 1003) Gi0/0/0/1 10.0.1.2 0 (snip) PE2 (Junos) FAD を参照するために show isis database extensive 以倖にも Flex-Algorithm のコマンドがありたす。 user@PE2> show isis spring flex-algorithm flex-algorithm-id 128 Flex Algo: 128 Level: 2, Color: 100, Participating, FAD supported Winner: P1, Metric: 0, Calc: 0, Prio: 128, Excl: 0x2, FAD supported Exclude: 0x2 RED Spf Version: 632 Participation toggles: 1 Last Route add: 0 Last Route rem: 0 Last Route chg: 0 Last Route fail: 0 Last Route def: 0 Total Route add: 16 Total Route rem: 8 Total Route chg: 0 Total Route fail: 0 Total Route def: 0 Topo refresh count: 2 PE1, Metric: 0, Calc: 0, Prio: 128, Excl: 0x2, FAD supported P2, Metric: 0, Calc: 0, Prio: 0, Excl: 0x2, FAD supported PE2, Metric: 0, Calc: 0, Prio: 0, Excl: 0x2, FAD supported Full SPFs: 631, Partial SPFs: 0 IS-IS Flex Algo 128 level 2 SPF log: Start time Elapsed (secs) Count Reason Sun Aug 14 11:03:06 0.000056 1 Periodic SPF (snip) ラベルも孊習されおいたす。 user@PE2> show route table mpls.0 (snip) 16001 *[L-ISIS/14] 5d 16:04:39, metric 30 to 10.0.2.1 via ge-0/0/0.0, Swap 16001 > to 10.0.3.2 via ge-0/0/1.0, Swap 16001 (snip) 17001 *[L-ISIS/14] 5d 14:55:16, metric 30 > to 10.0.3.2 via ge-0/0/1.0, Swap 17001 (snip) 4. SR Policy の蚭定ず確認 On Demand Nexthop (ODN) を䜿甚しお特定の BGP color の経路に䜿甚する Algorithm を指定したす。 PE1 (IOS XR) segment-routing traffic-eng on-demand color 100 dynamic metric type igp ! sid-algorithm 128 ! ! ! ! SR Policy が up 状態になり、宛先も PE2 の Algorithm 128 の SID (17003) が遞択されおいたす。 RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy color 100 Mon Aug 15 13:27:34.701 JST SR-TE policy database --------------------- Color: 100, End-point: 10.255.0.3 Name: srte_c_100_ep_10.255.0.3 Status: Admin: up Operational: up for 4d12h (since Aug 10 14:31:37.908) Candidate-paths: Preference: 200 (BGP ODN) (active) Requested BSID: dynamic Constraints: Prefix-SID Algorithm: 128 Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (valid) Metric Type: IGP, Path Accumulated Metric: 30 17003 [Prefix-SID: 10.255.0.3, Algorithm: 128] Preference: 100 (BGP ODN) Requested BSID: dynamic PCC info: Symbolic name: bgp_c_100_ep_10.255.0.3_discr_100 PLSP-ID: 3 Constraints: Prefix-SID Algorithm: 128 Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (pce) (invalid) Last error: No path Metric Type: NONE, Path Accumulated Metric: 0 Attributes: Binding SID: 24012 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no 顧客 A の BGP 経路も䞊蚘で蚭定した SR Policy (24012) を䜿甚するようになっおいたす。 RP/0/RP0/CPU0:PE1#show route vrf 100 192.168.1.0/24 detail Mon Aug 15 13:34:37.770 JST Routing entry for 192.168.1.0/24 Known via "bgp 65000", distance 200, metric 0, type internal Installed Aug 10 14:31:37.916 for 4d13h Routing Descriptor Blocks 10.255.0.3, from 10.255.0.3 Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000 Route metric is 0 Label: 0x10 (16) Tunnel ID: None Binding Label: 0x5dcc (24012) Extended communities count: 0 Source RD attributes: 0x0000:65000:100 NHID:0x0(Ref:0) Route version is 0x5 (5) No local label IP Precedence: Not Set QoS Group ID: Not Set Flow-tag: Not Set Fwd-class: Not Set Route Priority: RIB_PRIORITY_RECURSIVE (12) SVD Type RIB_SVD_TYPE_REMOTE Download Priority 3, Download Version 22 No advertising protos. PE2 (Junos) set routing-options flex-algorithm 128 color 100 こちらも PE1 の Algorithm 128 の SID (17001) が遞択されおいたす。 user@PE2> show route table inetcolor.0 inetcolor.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.255.0.1-100<c>/64 *[L-ISIS/14] 5d 17:18:36, metric 30 > to 10.0.3.2 via ge-0/0/1.0, Push 17001 (snip) 顧客 A の BGP 経路も 17001 SID ずしお積むようになっおいたす。 user@PE2> show route table 100.inet.0 192.168.0.0/24 extensive 100.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) 192.168.0.0/24 (1 entry, 1 announced) TSI: KRT in-kernel 192.168.0.0/24 -> {indirect(1048579)} *BGP Preference: 170/-101 Route Distinguisher: 65000:100 Next hop type: Indirect, Next hop index: 0 Address: 0x704fafc Next-hop reference count: 3 Source: 10.255.0.1 Next hop type: Router, Next hop index: 654 Next hop: 10.0.3.2 via ge-0/0/1.0, selected Label operation: Push 24004, Push 17001(top) Label TTL action: prop-ttl, prop-ttl(top) Load balance label: Label 24004: None; Label 17001: None; Label element ptr: 0x780fb50 Label parent element ptr: 0x782f1d0 Label element references: 1 Label element child references: 0 Label element lsp id: 0 Session Id: 0x142 Protocol next hop: 10.255.0.1-100<c> Label operation: Push 24004 Label TTL action: prop-ttl Load balance label: Label 24004: None; Indirect next hop: 0x7199204 1048579 INH Session ID: 0x0 State: <Secondary Active Int Ext ProtectionCand> Local AS: 65000 Peer AS: 65000 Age: 4d 10:32:58 Metric: 0 Metric2: 30 Validation State: unverified ORR Generation-ID: 0 Task: BGP_65000.10.255.0.1 Announcement bits (1): 0-KRT AS path: ? Communities: target:65000:100 color:0:100 Import Accepted VPN Label: 24004 Localpref: 100 Router ID: 10.255.0.1 Primary Routing Table: bgp.l3vpn.0 Thread: junos-main Indirect next hops: 1 Protocol next hop: 10.255.0.1-100<c> Metric: 30 Label operation: Push 24004 Label TTL action: prop-ttl Load balance label: Label 24004: None; Indirect next hop: 0x7199204 1048579 INH Session ID: 0x0 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 10.0.3.2 via ge-0/0/1.0 Session Id: 0x142 10.255.0.1-100<c>/64 Originating RIB: inetcolor.0 Metric: 30 Node path count: 1 Forwarding nexthops: 1 Next hop type: Router Next hop: 10.0.3.2 via ge-0/0/1.0 Session Id: 0x0 5. traceroute による VPN の通信経路確認 PE1 -> PE2 PE1 -> P2 -> P1 -> PE2 ず通過しおいるこずが芳枬できたす。 RP/0/RP0/CPU0:PE1#traceroute 192.168.1.254 vrf 100 Mon Aug 15 13:39:24.020 JST Type escape sequence to abort. Tracing the route to 192.168.1.254 1 10.0.1.2 [MPLS: Labels 17003/16 Exp 0] 15 msec 13 msec 3 msec 2 10.0.4.1 [MPLS: Labels 17003/16 Exp 0] 27 msec 8 msec 28 msec 3 192.168.1.254 3 msec 9 msec 2 msec PE2 -> PE1 逆順の PE2 -> P1 -> P2 -> PE1 ず通過しおいるこずが芳枬できたす。 user@PE2> traceroute 192.168.0.254 routing-instance 100 traceroute to 192.168.0.254 (192.168.0.254), 30 hops max, 52 byte packets 1 10.0.2.1 (10.0.2.1) 2.871 ms 13.558 ms 2.522 ms MPLS Label=17001 CoS=0 TTL=1 S=0 MPLS Label=24004 CoS=0 TTL=1 S=1 2 10.0.4.2 (10.0.4.2) 2.522 ms 2.372 ms 2.534 ms MPLS Label=17001 CoS=0 TTL=1 S=0 MPLS Label=24004 CoS=0 TTL=2 S=1 3 10.0.1.1 (10.0.1.1) 10.075 ms * 4.672 ms リンク障害時の Flex-Algorithm 怜蚌 前節で蚭定したネットワヌクにお1぀のリンクを故意に閉塞し、障害時においおも Algorithm 内でパスが切り替わる動䜜を確かめたす。 萜ずすリンクは P1 ず P2 の間です。 圓該のリンクを萜ずした埌も Algorithm 128 は有効なため、 Algorithm 128 内での最短パスに切り替わりたす。 切り替え前の P2 および PE2 のテヌブル どちらも P1 を向いおいたす。 P2 user@P2> show route table mpls.0 label 17003 17003 *[L-ISIS/14] 5d 20:37:15, metric 20 > to 10.0.4.1 via ge-0/0/2.0, Swap 17003 PE2 user@PE2> show route table mpls.0 label 17001 17001 *[L-ISIS/14] 01:52:13, metric 40 > to 10.0.2.1 via ge-0/0/0.0, Swap 17001 切り替え埌の P2 および PE2 のテヌブル どちらもメトリックが増え、盎接それぞれ転送するようになりたす。 P2 user@P2> show route table mpls.0 label 17003 17003 *[L-ISIS/14] 00:00:29, metric 100 > to 10.0.3.1 via ge-0/0/1.0, Pop PE2 user@PE2> show route table mpls.0 label 17001 17001 *[L-ISIS/14] 00:00:22, metric 120 > to 10.0.3.2 via ge-0/0/1.0, Swap 17001 traceroute による VPN の通信経路確認 PE1 -> PE2 リンク障害時の図の通り PE1 -> P2 -> PE2 ず通過しおいるこずが芳枬できたす。 RP/0/RP0/CPU0:PE1#traceroute 192.168.1.254 vrf 100 Mon Aug 15 15:45:51.232 JST Type escape sequence to abort. Tracing the route to 192.168.1.254 1 10.0.1.2 [MPLS: Labels 17003/16 Exp 0] 8 msec 12 msec 2 msec 2 192.168.1.254 10 msec 2 msec 8 msec PE2 -> PE1 逆順の PE2 -> P2 -> PE1 ず通過しおいるこずが芳枬できたす。 user@PE2> traceroute 192.168.0.254 routing-instance 100 traceroute to 192.168.0.254 (192.168.0.254), 30 hops max, 52 byte packets 1 10.0.3.2 (10.0.3.2) 2.428 ms 1.969 ms 1.463 ms MPLS Label=17001 CoS=0 TTL=1 S=0 MPLS Label=24004 CoS=0 TTL=1 S=1 2 10.0.1.1 (10.0.1.1) 12.766 ms * 9.734 ms たずめ 本蚘事ではアンダヌレむの分割や耇数指暙での最適経路蚈算ができる Flexible Algorithm ぀いお解説したした。 Multi-vendor での実装ずリンク障害時の動䜜怜蚌を玹介したした。 Flexible Algorithm はただ draft 段階のため、機胜远加が盛んで盞互運甚性も限定的ですが、ネットワヌク網の意図を衚珟する方法ずしお VPN の TE にも䜿甚可胜ず考えられたす。 次回の蚘事では、Flex-Algorithm のメトリックずしおも䜿える、遅延枬定倀を基にした Delay-based TE を玹介予定です。 2022/09/05 远蚘 公開したした [Multi-AS Segment Routing 怜蚌連茉 #7] Delay-Based TE https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo ↩
はじめに こんにちは、むノベヌションセンタヌの犏田です。 今回、開発環境改善の取り組みずしお GitHub Actions の self-hosted runners を AWS 䞊に構築したした。 この構築で埗られた知芋に぀いお共有したす。 抂芁 GitHub Actions は GitHub で CI/CD を手軜に実珟する機胜です。 GitHub が提䟛しおいる環境を利甚しお、 CI/CD のゞョブを実行できたす 1 。 䞀方で、ハヌドりェア等をカスタマむズできないため、䟋えば容量が倧きくより速床の早いストレヌゞを利甚したい堎合や、より倚くのメモリを利甚したい堎合に察応ができたせん。 そこで、GitHub Actions には self-hosted runners ずいう機胜があり、自身の環境で GitHub Actions の CI/CD ゞョブを走らせる環境を甚意できたす。 今回はより柔軟に利甚しやすく、保守しやすいように AWS Cloud Development Kit (以䞋CDK)を甚いお AWS 䞊に self-hosted runners 環境を構築したので、その構築手順等に぀いお解説しおいきたいず思いたす。 アヌキテクチャ 今回構築するシステムのアヌキテクチャに぀いお解説したす。 構築するむンフラの構成図は次の通りです。 図の䞭で点線によっおグルヌプ化されおいたすが、本システムは倧きく次の2぀の郚分からなっおいたす。 Webhook むベントの受信郚分 self-hosted runners 環境提䟛郚分 GitHub では GitHub Actions の CI/CD ゞョブが走り始めたずきに Webhook むベントを飛ばすこずができ、これを利甚しお CI/CD ゞョブの開始ず同時にその CI/CD ゞョブを走らせる self-hosted runners を起動するずいうシステムになっおいたす。 Webhook むベントの受信 たず、 self-hosted runners で走らせたい CI/CD ゞョブが開始されたのかを知る必芁がありたす。 GitHub には workflow_job ずいうむベントが Webhook むベントずしお出おおり、このむベントのペむロヌドに以䞋の情報が含たれおいたす。 ゞョブの実行環境の指定 GitHub-hosted runners での実行か、 self-hosted runners での実行かも指定されおいたす。 ゞョブのステヌタス ゞョブの開始が芁求されたのか、珟圚ゞョブが走っおいるのか、ゞョブが終了したのかのステヌタスがわかりたす。 この workflow_job むベントを Webhook むベントずしお受信するこずで self-hosted runners で走らせたい CI/CD ゞョブが開始されたのかを知るこずができたす。 したがっお、最初に workflow_job むベントを受信する Webhook の受信先を AWS に甚意したす。 AWS には API Gateway ずいうサヌビスがあり、このサヌビスを䜿っお容易に Web API を䜜成できたす。 なので、 workflow_job むベントの受信郚分に関しおはこの API Gateway を䜿っお構築したす。 しかし、 workflow_job は GitHub-hosted runners で走らせたい CI/CD ゞョブが開始されたずきにも発行されるむベントです。 そのため、 API Gateway で䜜成した Web API でこの workflow_job むベントを受信し self-hosted runners を起動するずいう単玔な実装にしおしたうず self-hosted runners で走らせたいゞョブ数よりも倧くの self-hosted runners が起動し、予定よりも倚くの課金がなされおしたいたす。 これを避けるため、䜜成した Web API が webhook むベントを受信したら self-hosted runners で走らせたい CI/CD ゞョブの開始が芁求されたむベントだけを抜出し、それ以倖のむベントは無芖するような仕組みを導入したす。 今回䜿甚する API Gateway は Lambda 関数 の HTTP ゚ンポむントを提䟛できるので、この機胜を利甚し、䜜成した Web API のバック゚ンドで Lambda 関数によるむベントフィルタリングの機胜を远加したす。 しかし、この Lambda 関数の HTTP ゚ンドポむントの機胜には Lambda 関数の最倧実行時間が29秒たでであるずいう制玄が存圚したす。 そのたた self-hosted runners を動かそうずするずこの制玄にひっかかっおしたい、 self-hosted runners が起動できなくなる可胜性がありたす。 これを回避するために、 Lambda 関数はフィルタヌを行った埌に self-hosted runners を起動するようなこずはせず、䞀旊 SQS にフィルタヌしたむベントを送信したす。 こうすれば SQS からあずの凊理は独立しお行えるため、先述した制限を回避できたす。 2 。 以䞊をたずめるず、 Webhook の受信郚分は次のようなむンフラストラクチャヌを構築するこずになりたす。 self-hosted runners の提䟛 ここからは受信した Webhook むベントを元に、適切な self-hosted runners を走らせる VM (以䞋、 self-hosted runners ノヌド) を立ち䞊げるためのむンフラ構成に぀いお解説したす。 SQS には Webhook むベントが送信されおいるので、たずはその SQS からメッセヌゞを受信する郚分を構築したす。 SQS がメッセヌゞを受信したずき、Lambda 関数ぞメッセヌゞの受信むベントを通知できたす 3 。 この機胜を利甚しお、 SQS から Webhook むベントを受信次第 self-hosted runners ノヌドずなる VM である EC2 むンスタンス を起動する Lambda 関数を甚意したす。 この際、 EC2 むンスタンスを EC2 むンスタンスの起動を行う API を通しお起動するこずになるのですが、ここで Launch Template ずいう EC2 むンスタンスの起動パラメヌタのテンプレヌトを利甚しお起動するようにしたす。 Launch Template は CDK で簡単に甚意するこずができる ため、こちらの機胜を通しお起動する方が Lambda 関数に EC2 むンスタンスの起動パラメヌタを党お枡すようなやり方よりも楜に保守・管理・運甚できたす 4 。 このように、 SQS から Webhook むベントを受信しおから Lambda 関数を起動し、その Lambda 関数は self-hosted runners ノヌドを起動するこずで self-hosted runners を必芁な分だけ提䟛できたす。 起動した self-hosted runners ノヌドは CI/CD ゞョブを実行し、その CI/CD ゞョブが終了次第シャットダりンするようにしたす。 EC2 むンスタンスにはシャットダりン終了埌に自動で VM の削陀するように蚭定でき、この蚭定もしおおきたす。 こうするこずでむンスタンスやそのストレヌゞぞの課金額を抑えられるず同時に、前のゞョブの情報がむンスタンス内に残らないようにできたす。 ぀たり、毎回クリヌンな環境でむンスタンスを起動でき、各ゞョブに䟝存関係が発生するのを防ぐこずができたす。 最埌に、 self-hosted runners を起動する際には以䞋の2぀の凊理を self-hosted runners の起動前に行う必芁があるので、これらを EC2 むンスタンスの 起動時にスクリプトを走らせる機胜 を䜿っおおこないたす。 最新版の self hosted runners のダりンロヌド self-hosted runners を登録 このずき、シェルクリプトでやるには耇雑すぎるこずがあったり、やりずりされるパケットの量を抑えたりするために、いく぀かの凊理を Lambda 関数を通しお行うようにしたす。 これらをたずめるず、以䞋のような構成図を構築するこずになりたす。 図䞭には S3 バケットが出珟しおいたすが、こちらは 1. のダりンロヌドしおきた self-hosted runners をキャッシュするために利甚しおいたす。 CDK によるむンフラ構築 先述したシステムを Web コン゜ヌルや CLI だけで構築し、適切に保守・運甚しおいくのは難しいため CDK を利甚したす。 self-hosted runners 環境 最初に self-hosted runners ノヌドを起動する仕組みを構築したす。 self-hosted runners ノヌド自䜓は Public な堎所に眮いおおく必芁はなく、 GitHub ずの接続ができればよいため Private な サブネット ぞず蚭眮するようにし、 Public なサブネットに NAT ゲヌトりェむ を蚭眮しお Private サブネットの通信をそこぞ流すようにしたす。 たずは self-hosted runners ノヌド起動時に走らせるスクリプト内で呌ばれる補助 Lambda 関数を甚意したす。 self-hosted runners を提䟛するプログラムをダりンロヌドする関数 ダりンロヌドするバむナリヌにバヌゞョン番号が぀いおいるため、先に最新版のバヌゞョン番号を GitHub API から取埗しおおく必芁があり、スクリプトの耇雑床や制埡難易床を䞊げおしたうので肩代わりさせる 関数を呌び出せば最新版が垞に手に入り、テストも甚意になる 走らせる self-hosted runners を GitHub に登録するためのトヌクンを぀くる関数 この郚分は JWT を぀くったりするなど倚少耇雑なロゞックを実装する必芁があり、 bash スクリプトでやるよりも Lambda 関数に凊理を移譲しおしたった方が良さそうです 実は 1. の堎合は Lambda 関数の制限ずしお 6MB たでのレスポンスしか返せたせん 。 self-hosted runners はこの制限である 6MB を越えおいたす 。 そのため、Lambda 関数ずしおは self-hosted runners をそのたた返すこずはせずに、 S3 バケット に䞀旊ダりンロヌドしおきたものを配眮し、その配眮先をレスポンスに茉せたす。 ダりンロヌドは VPC に S3 の゚ンドポむントを蚭眮しお、 Lambda 関数のレスポンスから配眮先をよみずっお S3 バケットからダりンロヌドしおきたす。 こうするこずで、副次的に NAT ゲヌトりェむ を通るパケットの量を枛らすこずができるので、 NAT ゲヌトりェむの料金を抑える効果もありたす。 さお、この2぀の関数を CDK に茉せおいきたす。 なお、ここでは甚意する関数はすべお Go 蚀語 で蚘茉しおいたす。 たた、 Go 蚀語の module 機胜を利甚するので go v1.11 以䞊が必芁です。 さらに、 CDK では Python や Java 等様々な蚀語が䜿えたすが、ここでは TypeScript を甚いお CDK コヌドを蚘述しおいきたす。 最初に 1. の関数を茉せたす。 やりたいこずずしおは以䞋の4぀になりたす。 ダりンロヌドしたい self-hosted runners のバヌゞョンを取埗 先皋取埗したバヌゞョンを指定しお self-hosted runners をダりンロヌド ダりンロヌドしたものを S3 バケットに蚭眮 蚭眮先を関数の返り倀ずしお返す これを動かすコヌドは以䞋のようになりたす。 package main import ( "context" "encoding/json" "fmt" "io/ioutil" "net/http" "os" "github.com/aws/aws-lambda-go/lambda" "github.com/aws/aws-sdk-go-v2/aws" "github.com/aws/aws-sdk-go-v2/config" "github.com/aws/aws-sdk-go-v2/service/s3" ) type Response struct { Bucket string `json:"bucket"` Key string `json:"key"` } type PackageMetadata struct { TagName string `json:"tag_name"` } func Fetch(url string ) ([] byte , error ) { resp, err := http.Get(url) if err != nil { return nil , err } defer resp.Body.Close() return ioutil.ReadAll(resp.Body) } func HandleRequest(ctx context.Context) (Response, error ) { // self-hosted runners のキャッシュ先 S3 バケット名は // 環境倉数ずしお蚭定する bucket, has := os.LookupEnv( "BUCKET" ) if !has { return Response{}, fmt.Errorf( "No such environement: BUCKET" ) } cfg, err := config.LoadDefaultConfig(ctx) if err != nil { return Response{}, err } client := s3.NewFromConfig(cfg) // 1. ダりンロヌドしたい self-hosted runners のバヌゞョンを取埗 // // ここでは最新版をダりンロヌド b, err := Fetch( "https://api.github.com/repos/actions/runner/releases/latest" ) if err != nil { return Response{}, err } m := &PackageMetadata{} if err := json.Unmarshal(b, m); err != nil { return Response{}, err } // 先頭に `v` がプリフィックスずしお぀いおるので、 // そこだけ無芖しおバヌゞョンを取埗 ver := m.TagName[ 1 :] // 2. 先皋取埗したバヌゞョンを指定しお self-hosted runners をダりンロヌド b, err = Fetch( fmt.Sprintf( "https://github.com/actions/runner/releases/download/v%s/actions-runner-linux-x64-%s.tar.gz" , ver, ver) ) if err != nil { return Response{}, err } // 3. self-hosted runners を S3 に蚭眮する param := &s3.PutObjectInput{ Bucket: aws.String(bucket), // 決め打ちで runner.tar.gz ずいうキヌで // self-hosted runners のバむナリヌを保存しおおく Key: aws.String( "runner.tar.gz" ), Body: b, } if _, err := client.PutObject(ctx, param); err != nil { return Response{}, err } // 4. 蚭眮先を関数の返华倀ずしお返す return Response{Bucket: bucket, Key: "runner.tar.gz" }, nil } func main() { lambda.Start(HandleRequest) } Lambda は Docker コンテナを動かせる ので、 そのための Dockerfile を曞きたす。 FROM --platform=$TARGETPLATFORM golang:1 as build WORKDIR /usr/src/app ARG TARGETOS ARG TARGETARCH COPY go.mod go.sum ./ RUN go mod download && go mod tidy COPY . . RUN env CGO_ENABLED=0 GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build -v -o /main ./... FROM --platform=$TARGETPLATFORM public.ecr.aws/lambda/provided:al2 COPY --from=build /main ${LAMBDA_RUNTIME_DIR}/bootstrap CMD [ "main" ] 同じように 2. の関数も甚意したす。 泚意点ずしお、 事前に GitHub Apps ずしお self-hosted runners を登録する Lambda 関数を登録する必芁がありたす。 GitHub Apps ずしお登録する際には以䞋2点を蚭定しおおかなければならないこずに泚意しおください。 self-hosted runners を登録する Lambda 関数が self-hosted runners たわりの操䜜を Read/Write できるよう暩限を付䞎しおおく GitHub Organizations の党おのリポゞトリで動䜜するようにさせる堎合、 Repository Access を All Repositories に蚭定しおおく この GitHub Apps ぞの登録ができたら、起動させる self-hosted runners を GitHub ぞ登録する関数を曞いおいきたす。 package main import ( "context" "fmt" "os" "strconv" "github.com/aws/aws-lambda-go/lambda" "github.com/bradleyfalzon/ghinstallation/v2" "github.com/google/go-github/v45/github" ) func InstallationId(org string ) ( int64 , error ) { itr, err := ghinstallation.NewAppsTransport( https.DefaultTransport, appId, privateKey, ) if err != nil { return 0 , err } client := github.NewCient(&http.Client{Transport: itr}) listOpt := &github.ListOptions{} for { is, resp, err := client.Apps.ListInstallations(ctx, listOpt) if err != nil { return 0 , err } // GitHub Apps の党おのむンストヌル先から、 // 指定された Organization にむンストヌルされおいるものを芋぀けお // そのむンストヌルに぀けられた ID を取埗する。 for _, inst := range insts { if inst.GetAccount().GetLogin() == org { return inst.GetID(), nil } } if resp.NextPage == 0 { break } listOpt.Page = resp.NextPage } return 0 , fmt.Errorf( "cannot find installation id on %s" , org) } func HandleRequest(ctx context.Context) ( map [ string ] string , error ) { org, has := os.LookupEnv( "ORGANIZATION" ) if !has { return "" , fmt.Errorf( "No such environment: ORGANIZATION" ) } appIdStr, has := os.LookupEnv( "GITHUB_APPS_APP_ID" ) if !has { return "" , fmt.Errorf( "No such environment: GITHUB_APPS_APP_ID" ) } appId, err = strconv.ParseInt(appIdStr, 10 , 64 ) if err != nil { return "" , fmt.Errorf( "GITHUB_APPS_APP_ID is not integer: %s" , appIdStr) } privateKey, has := os.LookupEnv( "GITHUB_APPS_APP_PRIVATE_KEY" ) if !has { return "" , fmt.Errorf( "No such environment: GITHUB_APPS_APP_PRIVATE_KEY" ) } instId, err := InstallationId(org) if err != nil { return "" , err } // 2. self-hosted runners を登録する際に必芁ずなるトヌクンの発行 itr, err := ghinstallation.New(http.DefaultTransport, appId, instId, privateKey) if err != nil { return "" , err } client := github.NewCient(&http.Client{Transport: itr}) resp, _, err := client.Actions.CreateOrganizationRegistrationToken(ctx, org) if err != nil { return "" , err } return resp.GetToken(), nil } func main() { lambda.Start(HandleRequest) } 先述した2぀の関数を CDK ずしお茉せたす。 import * as cdk from "aws-cdk-lib" ; import * as { Construct } from "constructs" ; import * as path from "path" ; // self-hosted runners をダりンロヌドする Lambda 関数 export class RunnerDownloader extends cdk.aws_lambda.DockerImageFunction { constructor( scope: Construct , id: string ) { super( scope , id , { code: cdk.aws_lambda.DockerImageCode.fromImageAsset ( // Lambda 関数のコヌドの蚭眮先はこの゜ヌスファむルず同じ階局にある // `handler/runner-downloader` に path.join ( __dirname , "handler" , "runner-downloader" ), ), timeout: cdk.Duration.minutes ( 5 ), memorySize: 1024 , } ); const storage = new cdk.aws_s3.Bucket ( this , "Storage" , { lifecycleRules: [ // 7日間だけはキャッシュしおおくが、 // 7日超えたら最新のものを取埗 { enabled: true , expiration: cdk.Duration.days ( 7 ), } ] , // キャッシュずしおしか利甚しないので、スタックの削陀時には // このバケット内のオブゞェクトを党お削陀する autoDeleteObjercts: true , removalPolicy: cdk.RemovalPolicy.DESTROY , } ); storage.grantRead ( this ); storage.grantPut ( this ); this .addEnvironment ( "BUCKET" , storage.bucketName ); } } export type RegistrationTokenGeneratorProps = { githubAppsPrivateKey: string ; githubAppsAppId: string ; } ; // self-hosted runners を登録するためのトヌクンを生成する Lambda 関数 export class RegistrationTokenGenerator extends cdk.aws_lambda.DockerImageFunction { constructor( scope: Construct , id: string , props: RegistrationTokenGeneratorProps ) { super( scope , id , { code: cdk.aws_lambda.DockerImageCode.fromImageAsset ( // Lambda 関数のコヌドの蚭眮先はこの゜ヌスファむルず同じ階局にある // `handler/registration-token-generator` に path.join ( __dirname , "handler" , "registration-token-generator" ) ), timeout: cdk.Duration.minutes ( 5 ), environment: { GITHUB_APPS_APP_ID: props.githubAppsAppId , GITHUB_APPS_PRIVATE_KEY: props.githubAppsPrivateKey , } , memorySize: 1024 , } ); } } 甚意できたら self-hosted runners を起動するスクリプトを組みたす。 #!/usr/bin/env bash function setup() { local -r \ runner_downloader="$1" \ registration_token_generator="$2" \ organization="$3" \ runner_directory="$4" \ mkdir "$runner_directory" && cd "$runner_directory" || return 1 # self-hosted runners を取埗する local -r runner_json=/tmp/runner.json aws lambda invoke \ --function-name "$runner_downloader" \ --payload "{}" \ --cli-binary-format raw-in-base64-out \ "$runner_json" local -r runner_archive=/tmp/runner.tar.gz aws s3api get-object \ --bucket "$(jq -r .bucket "$runner_json")" \ --key "$(jq -r .key "$runner_json")" \ "$runner_archive" tar zxf "$runner_archive" # self-hosted runners の登録甚トヌクン発行 local -r registration_token_json=/tmp/registration-token.json aws lambda invoke \ --function-name "$registration_token_generator" \ --payload "{}" \ --cli-binary-format raw-in-base64-out \ "$registration_token_json" local registration_token registration_token="$(jq -r .token "$registration_token_json")" # runner の初期蚭定を行う ./config.sh \ --url "https://github.com/$organization" \ --disable-update \ --ephemeral \ --unattended } function main() { local -r \ runner_downloader="$1" \ registration_token_generator="$2" \ organization="$3" # self-hosted runners を走らせるためのナヌザヌを䜜成 useradd -m -g users -G sudo -s /bin/bash runner # self-hosted runners を起動する準備を行う local runner_directory=~runner/runner su \ - runner \ -c "$(declare -f setup); setup \"$runner_downloader\" \"$registration_token_generator\" \"$organization\" \$runner_directory\"" cd "$runner_directory" && ./bin/installdependencies.sh # self-hosted runners を起動 # self-hosted runners がタスクを走り終えたら poweroff しお VM を終了させる su - runner -c "cd '$runner_directory' && ./run.sh" \ && systemctl poweroff } main "$@" あずはこのスクリプトを利甚しお self-hosted runners ノヌドずなる EC2 むンスタンスのための Launch Template を䜜成したす。 import * as cdk from "aws-cdk-lib" ; import { Construct } from "constructs" ; import * as path from "path" ; // 先皋甚意した補助関数をむンポヌトする。 import { RunnerDownloader } from "./runner-downloader" ; import { RegistrationTokenGenerator } from "./registration-token-generator" ; export type LaunchTemplateProps = { runnerDownloader: RunnerDownloader ; registrationTokenGenerator: RegistrationTokenGenerator ; organization: string ; } ; export class LaunchTemplate extends cdk.Resource { public readonly launchTemplate: cdk.aws_ec2.LaunchTemplate ; constructor( scope: Construct , id: string , props: LaunchTemplateProps ) { super( scope , id ); const role = new cdk.aws_iam.Role ( this , "Role" , { assumedBy: new cdk.aws_iam.ServicePrincipal ( "ec2.amazonaws.com" ), managedPolicies: [ cdk.aws_iam.ManagedPolicy.fromAwsManagedPolicyName ( "AmazonSSMManagedInstanceCore" ), ] , } ); const asset = new cdk.aws_s3_assets.Asset ( this , "UserData" , { // 先皋のスクリプトを start.bash ずいう名前で保存しおおく。 path: path.join ( __dirname , "start.bash" ), } ); asset.grantRead ( role ); const userData = cdk.aws_ec2.UserData.forLinux ( { shebang: "#!/usr/bin/env bash" , } ); const filePath = this .userData.addS3DownloadCommand ( { bucket: asset.bucket , bucketKey: asset.s3ObjectKey , } ); userData.addExecuteFileCommand ( { filePath , arguments : [ props.runnerDownloader.functionArn , props.registrationTokenGenerator.funcitonArn , organization , ] .join ( " " ), } ); this .launchTemplate new cdk.aws_ec2.LaunchTemplate ( this , "LaunchTemplate" , { role , instanceType: cdk.aws_ec2.InstanceType. of( cdk.aws_ec2.InstanceClass.T3 , cdk.aws_ec2.InstanceSize.SMALL , ), // ここには GitHub Actions で利甚するむメヌゞを指定する。 // ただし、先皋のスクリプト内で awscli v2 ず jq を利甚しおいるので、 // これらを含めた䞊で、 GitHub Actions でサポヌトされおいる // タむプの OS を指定する必芁がある。 // // 参考: https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#supported-architectures-and-operating-systems-for-self-hosted-runners machineImage: GithubActionsMachineImage , userDate , ebsOptimized: true , // シャットダりン時にはむンスタンスを terminate させる。 instanceInitiatedShutdownBehavior: cdk.aws_ec2.InstanceInitiatedShutdownBehavor.TERMINATE , blockDevices: [ { deviceName: "/dev/sda1" , volume: cdk.aws_ec2.BlockDeviceVolume.ebs ( 100 , { volumeType: cdk.aws_ec2.EvsDeviceVolumeType.GP3 , deleteOnTermination: true , encrypted: true , } ) } ] } ); } } 次にこの Launch template からむンスタンスを起動する Lambda 関数を曞きたす。 たずは関数のコヌドを甚意したす(この関数も先皋たでの関数ず同じで Lambda コンテナむメヌゞずしお提䟛したす)。 package main import ( "context" "fmt" "os" "github.com/aws/aws-lambda-go/events" "github.com/aws/aws-lambda-go/lambda" "github.com/aws/aws-sdk-go-v2/aws" "github.com/aws/aws-sdk-go-v2/config" "github.com/aws/aws-sdk-go-v2/service/ec2" "github.com/aws/aws-sdk-go-v2/service/ec2/types" ) // あずでこの関数を SQS に接続し、 SQS からむベントをうけずったら起動するようにするため、 // ここでは events.SQSEvent を受け取るようにしおいたす。 func HandleRequest(ctx context.Context, req events.SQSEvent) error { ltId, has := os.LookupEnv( "LAUNCHTEMPLATE_ID" ); if !has { return fmt.Errorf( "No such environment: LAUNCHTEMPLATE_ID" ); } ltVer, has := os.LookupEnv( "LAUNCHTEMPLATE_VERSION" ); if !has { return fmt.Errorf( "No such environment: LAUNCHTEMPLATE_VERSION" ) } snId, has := os.LookupEnv( "SUBNET_ID" ); if !has { return fmt.Errorf( "No such environment: SUBNET_ID" ); } cfg, err := config.LoadDefaultConfig(ctx) if err != nil { return err } client := ec2.NewFromConfig(cfg) for range req.Records { param := &ec2.RunInstancesInput{ LaunchTemplate: &types.LaunchTemplateSpecification{ LaunchTemplateId: aws.String(ltId), Version: aws.String(ltVer), }, SubnetId: aws.String(snId), MaxCount: aws.Int32( 1 ), MinCount: aws.Int32( 1 ), } resp, err := client.RunInstances(ctx, param) if err != nil { return err } } return nil } func main() { lambda.Start(HandleRequest) } この関数の CDK コヌドを甚意したす。 // 先皋の LaunchTemplate クラスをむンポヌトする。 import { LaunchTemplate } from "./launch-template" ; export type InstanceLauncherProps = { launchTemplate: LaunchTemplate ; subnet: cdk.aws_ec2.ISubnet ; } ; // self-hosted runners を登録するためのトヌクンを生成する Lambda 関数 export class InstanceLauncher extends cdk.aws_lambda.DockerImageFunction { constructor( scope: Construct , id: string , props: InstanceLauncherProps ) { super( scope , id , { code: cdk.aws_lambda.DockerImageCode.fromImageAsset ( // Lambda 関数のコヌドの蚭眮先はこの゜ヌスファむルず同じ階局にある // `handler/registration-token-generator` に path.join ( __dirname , "handler" , "instance-launcher" ) ), timeout: cdk.Duration.minutes ( 5 ), environment: { LAUNCHTEMPLATE_ID: props.launchTemplate.launchTemplateId , LAUNCHTEMPLATE_VERSION: props.launchTemplate.latestVersionNumber , SUBNET_ID: props.subnet.subnetId , } , memorySize: 1024 , } ); this .addToRolePolicy ( new cdk.aws_iam.PolicyStatement ( { resources: [ "*" ] , // EC2 むンスタンスを立ち䞊げるには `ec2:RunInstances` が必芁。 // たた、 立ち䞊げた EC2 むンスタンスにロヌルを付䞎するために `iam:PassRole` も必芁で、 // さらにタグを Launch Template を通しお぀けたりするためには CreateTags が必芁ずなる。 actions: [ "ec2:RunInstances" , "iam:PassRole" , "ec2:CreateTags" ] } ) ); } } 最埌にこれらをたずめたコンポヌネントを䜜成したす。 import * as cdk from "aws-cdk-lib" ; import { Construct } from "constructs" ; import { InstanceLauncher } from "./instance-launcher" ; import { RunnerDownloader } from "./runner-downloader" ; import { RegistrationTokenGenerator } from "./registration-token-generator" ; import { LaunchTemplate } from "./LaunchTemplate" ; export type SelfHostedRunnerProps = { githubAppsAppId: string ; githubAppsPrivateKey: string ; organization: string ; subnet: cdk.aws_ec2.ISubnet ; } ; export class SelfHostedRunner extends cdk.Resource { public readonly instanceLauncher: InstanceLauncher ; constructor( scope: Construct , id: string , props: SelfHostedRunnerProps ) { super( scope , id ); const runnerDownloader = new RunnerDownloader ( this , "RunnerDownloader" ); const registrationTokenGenerator = new RegistrationTokenGenerator ( this , "RegistrationTokenGenerator" , { githubAppsAppId: props.githubAppsAppId , githubAppsPrivateKey: props.githubAppsPrivateKey , } ); const launchTemplate = new LaunchTemplate ( this , "LaunchTemplate" , { runnerDownloader , registrationTokenGenerator , organization: props.organization , } ); this .instanceLauncher = new InstanceLauncher ( this , "InstanceLauncher" , { launchTemplate , subnet: props.subnet , } ); } } Webhook self-hosted runners ノヌドを起動する郚分の䜜成ができたので、今床は Webhook を受信する郚分を䜜成しおきたす。 最初に、 Webhook むベントを送信する SQS ず、先皋甚意した self-hosted runners ノヌドを起動する Lambda 関数がその SQS のメッセヌゞ受信したら起動するようにする蚭定したす。 import * as cdk from "aws-cdk-lib" ; import { Construct } from "constructs" ; // instance を立ち䞊げる Lambda 関数をむンポヌト import { InstanceLauncher } from "./instance-launcher" ; export type InstanceLaunchQueueProps = { // プロパティで self-hosted runners ノヌドを起動する Lambda 関数を枡しおもらう instanceLauncher: InstanceLauncher ; } export class InstanchLaunchQueue extends cdk.aws_sqs.Queue { constructor( scope: Construct , id: string , props: InstanceLaunchQueueProps ) { super( scope , id , { visibilityTimeout: cdk.Duration.minutes ( 5 ) } ); // SQS のむベントを受信しお EC2 むンスタンスを立ち䞊げる Lambda 関数を呌ぶ props.intanceLauncher.addEventSource ( new cdk.aws_lambda_event_sourecs.SqsEventSource ( this ) ); } } 次に Webhook の受信郚分ずなる API Gateway による Web API の䜜成ず、その裏で動くむベントのフィルタリングを行ったあずに SQS ぞ Webhook むベントを送信する Lambda 関数を実装したす。 むベントのフィルタリング方法ですが、 先述したずおり、 workflow_job むベントを利甚したす。 この workflow_job むベントのペむロヌドには workflow ずいうオブゞェクトが含たれおおり、この䞭に status ずいうプロパティがありたす。 この status プロパティは CI/CD ゞョブのステヌタスを衚しおいたす。 ステヌタスずしおは次の3぀が甚意されおいたす。 queued : ゞョブが開始したものの、ただ runner が割り圓おられおいない状態 in_progress : ゞョブに runner が割り圓おられお珟圚ゞョブが走っおいる状態 completed : ゞョブが完了したこずを衚す状態 このうち、 queued が今回必芁になるむベントであるため、これ以倖のものをたずははじくこずが必芁です。 さらに、 workflow_job むベントのペむロヌド䞭にある workflow オブゞェクトには labels ずいう文字配列プロパティがあり、 self-hosted runners で走らせる CI/CD ゞョブが開始した堎合はこの配列䞭に self-hosted ずいうラベルが入っおいたす。 なので、 self-hosted runners で走るゞョブだけを抜出する際にはこの labels プロパティの芁玠も芋おあげる必芁がありたす。 これらを元に必芁ずなる Webhook むベントのみを抜出し、 self-hosted runners ノヌドを起動するずころたでを䜜成したす 5 。 たず、むベントフィルタリングをしたあずに SQS ぞメッセヌゞを送信する Lambda 関数の実装は次の通りです。 package main import ( "context" "fmt" "os" "github.com/aws/aws-lambda-go/events" "github.com/aws/aws-lambda-go/lambda" "github.com/aws/aws-sdk-go-v2/aws" "github.com/aws/aws-sdk-go-v2/config" "github.com/aws/aws-sdk-go-v2/service/sqs" "github.com/google/go-github/v45/github" ) // あずで API Gateway からこの関数を呌び出す func HandleRequest(ctx context.Context, req events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error ) { qUrl, has := os.LookupEnv( "QUEUE_URL" ) if !has { resp := events.APIGatewayProxyResponse{ StatusCode: 500 , Body: "No such environment: QUEUE_URL" , } return resp, fmt.Errorf( "No such environment: QUEUE_URL" ) } // むベントのフィルタリング var ev github.WorkflowJobEvent if err := json.Unmarshal(req.Body, &ev); err != nil { // workflow_job むベント以倖は党郚無芖 resp := events.APIGatewayProxyResponse{ StatusCode: 200 , Body: "ignore event" , } return resp, nil } if stat := ev.GetWorkflowJob().GetStatus(); stat != "queued" { // queued なもの以倖は党郚無芖 resp := events.APIGatewayProxyResponse{ StatusCode: 200 , Body: "ignore event" , } return resp, nil } isShr := false for _, label := range ev.GetWorkflowJob().Labels { if label == "self-hosted" { isShr = true break } } if !isShr { // queued なもの以倖は党郚無芖 resp := events.APIGatewayProxyResponse{ StatusCode: 200 , Body: "ignore event" , } return resp, nil } // Queue にメッセヌゞを送信 cfg, err := config.LoadDefaultConfig(ctx) if err != nil { resp := events.APIGatewayProxyResponse{ StatusCode: 500 , Body: fmt.Sprintf( "%v" , err), } return resp, err } client := sqs.NewFromConfig(cfg) param := &sqs.SendMessageInput{ QueueUrl: aws.String(qUrl), // Queue からむベントがでればそのたた self-hosted runners が立ち䞊がるため、 // メッセヌゞは䜕でもよい。そのため、ここでは `{}` をメッセヌゞずしお送信しおいる。 MessageBody: aws.String( "{}" ), } if _, err = client.SendMessage(ctx, param); err != nil { resp := events.APIGatewayProxyResponse{ StatusCode: 500 , Body: fmt.Sprintf( "%v" , err), } return resp, err } resp := events.APIGatewayProxyResponse{ StatusCode: 200 , Body: "OK" , } return resp, nil } func main() { lambda.Start(HandleRequest) } この関数をプロビゞョニングするための CDK コヌドは次の通りです。 import * as cdk from "aws-cdk-lib" ; import { Construct } from "constructs" ; import * as path from "path" ; import { InstanceLaunchQueue } from "./instance-launch-queue" ; export type EventPublisherProps = { queue: InstanceLaunchQueue ; } ; export class EventPublisher extends cdk.aws_lambda.DockerImageFunction { constructor( scope: Construct , id: string , props: EventPublisherProps ) { super( scope , id , { code: cdk.aws_lambda.DockerImageCode.fromImageAsset ( // Lambda 関数のコヌドの蚭眮先はこの゜ヌスファむルず同じ階局にある // `handler/event-publisher` に path.join ( __dirname , "handler" , "event-publisher" ) ), timeout: cdk.Duration.minutes ( 5 ), environment: { QUEUE_URL: props.queue.queueUrl , } , memorySize: 1024 , } ); this .addToRolePolicy ( new cdk.aws_iam.PolicyStatement ( { resources: [ "*" ] , actions: [ "sqs:SendMessage" ] } ) ); } } 最埌に、 Webhook の受け口ずなる API Gateway を蚭眮し、甚意した Lambda 関数を呌び出すように蚭定すれば䜜成完了です。 import * as cdk from "aws-cdk-lib" ; import { Construct } from "constructs" ; // 䜜成したものをむンポヌト import { EventPublisher } from "./event-publisher" ; import { InstanceLaunchQueue } from "./instance-launch-queue" ; import { InstanceLauncher } from "./instance-launcher" ; export type WebhookProps = { instanceLauncher: InstanceLauncher ; } ; export class Webhook extends cdk.Resource { public readonly gateway: cdk.aws_apigateway.LambdaRestApi ; constructor( scope: Construct , id: string , props: InstanceLauncher ) { super( scope , id ); const queue = new InstanceLaunchQueue ( this , "Queue" , { instanceLauncher: props.instanceLauncher , } ); const eventPublisher = new EventPublisher ( this , "EventPublisher" , { queue , } ); this .gateway = new cdk.aws_apigateway.LambdaRestApi ( this , "Webhook" , { handler: eventPublisher } ); } } あずは GitHub 偎で Webhook を䜜成し、ここでデプロむされる API Gateway の URL を Webhook ずしお登録すれば完了です。 たずめ ここたで self-hosted runners を AWS 䞊に CDK を甚いお構築する方法に぀いお解説したした。 倚少耇雑な機構ずなっおはいたすが、やりたいこずずしおは Webhook から CI/CD ゞョブの開始むベントがきたら self-hosted runners を立ち䞊げるだけです。 ここでは解説しおいたせんが、倚少拡匵しおいけば arm64 アヌキテクチャな self-hosted runners 環境を䜜成したり、 Windows 環境を甚意しお実行したりできたす。 この環境をベヌスずしお皆さんでより良い開発環境を䜜成しおいただければず思いたす。 https://docs.github.com/ja/actions/using-github-hosted-runners/about-github-hosted-runners ↩ self-hosted runners の立ち䞊げは Webhook むベントの受信ずは別の操䜜になりたすし、最悪その埌の凊理で EC2 むンスタンスが立ち䞊がらなくおも GitHub Actions のゞョブは72時間で倱敗ずしおずりあ぀かわれたす。さらにゞョブは再床流せるので、 self-hosted runners 環境を再床立ち䞊げおゞョブを走らせるこずができればいいため、切り離すこずによる問題はそこたで倧きくはないず思いたす。 ↩ https://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-lambda-function-trigger.html ↩ Auto Scaling Group を䜿えば同じようにむンスタンスの起動をより楜に行えたすが、起動したむンスタンスの管理が煩雑になりたす。少し詊しおみればわかりたすが、むンスタンス数を増やすのはずおも簡単な䞀方、むンスタンス数を枛らすのはずおも難しいです。たずえば、倧抵の CI/CD ゞョブはすぐに終了するこずが倚いため、無駄なコストをかけないように土日には self-hosted runners 環境を提䟛する EC2 むンスタンスの数を0にするずしたす。しかし、 ML トレヌニングするむンスタンス等時間のかかる CI/CD ゞョブが金曜倜に投入され、土曜にゞョブが割り蟌んだずき、䞊蚘ルヌルに則りむンスタンスが終了させられ、ゞョブが䞭断させられおしたいたす。これをちゃんずどのむンスタンスが走っおいるのかを把握するのは難しいため、適切なゞョブ管理をする仕組みを導入しなければなりたせん。なので、 Auto Scaling Group を䜿わずにゞョブの芁求に応じお Launch Template から起動するようにしおおき、ゞョブが走った埌はそのたた EC2 むンスタンスを終了するようにすれば耇雑なゞョブの管理は必芁なくなりたす。 ↩ 実は GitHub には Organization で共有しお利甚できる self-hosted runners の他に、リポゞトリヌ毎にも self-hosted runners を登録できたす。 workflow_job むベントではこれらの区別が぀かないため、リポゞトリヌ毎に登録しおいる self-hosted runners を利甚したいのか、 Organization で共有しお利甚できる self-hosted runners を起動したいのかを区別するこずは難しいです。簡単な解決策ずしおは各 self-hosted runners に ラベル を登録できるので、これを利甚しおそれぞれを区別するようにすれば良いです。ただし、今回瀺す䟋ではそのようなリポゞトリヌ毎に登録されおいる self-hosted runners はないものずしお進めたす。 ↩
はじめに DevOpsプラットフォヌムの取り組みを玹介する5回目の蚘事です。 Qmonus Value Stream 開発チヌムの杉野です。 連茉第5回では、Qmonus Value StreamでCI/CD機胜を実珟するための芁玠技術ずしお甚いおいる、OSSのTektonに぀いお玹介したす。 これたでの蚘事をただ芋おいないずいう方は、Qmonus Value StreamずいうプラットフォヌムがどのようにTektonを利甚しおいるかを 過去の蚘事 で述べおいたすので、芗いおみおください。 たた、本蚘事ではKubernetes(以䞋、k8s)に関する知識がある前提で蚘述しおいたすので、ご了承ください。 Tekton ずは Tektonは䞀蚀でいうず、CI/CDシステムを䜜成するためのKubernetes Nativeなオヌプン゜ヌスフレヌムワヌクです。さらに噛み砕いお衚珟するず、k8s䞊で動䜜しおCI/CDの機胜を実珟する゜フトりェアです。 Tektonは、基盀ずなるTekton Pipelinesず呌ばれるコンポヌネントず、Tektonを゚コシステムにするための耇数のサポヌトコンポヌネントで構成されたす。珟圚は次のようなコンポヌネントが存圚しおいたす。 Tekton Pipelines : パむプラむンを構築するためのビルディングブロックを提䟛するTektonの基盀コンポヌネント Tekton Triggers : パむプラむンをむベントトリガヌで実行する機胜を提䟛 Tekton CLI : パむプラむンを管理するコマンドラむンむンタフェヌスを提䟛 Tekton Dashboard : パむプラむンの確認や実行が可胜なWeb UIを提䟛 Tekton Catalog : コミュニティが提䟛するビルディングブロックのリポゞトリ Tekton Hub : Tekton CatalogのWeb UIを提䟛 Tekton Operator : Tektonのコンポヌネントを管理する機胜を提䟛 Tekton Results : パむプラむンの実行履歎のストレヌゞ機胜を提䟛 Tekton Chains : パむプラむンでサプラむチェヌンセキュリティの機胜を提䟛 䞊蚘コンポヌネントの䞭でもPipelines、Triggers、CLI、Dashboardは䞻芁コンポヌネントず呌ばれたす。本蚘事では、Tekton Pipelinesに焊点をあおお玹介したす。 Tekton Pipelines コンセプト TektonにはStep、Task、Pipelineず呌ばれる抂念がありたす。 Step : Tektonでパむプラむンを実行する際の䞀番小さな凊理の単䜍です。䟋えば、゜ヌスコヌドを取埗する・コンパむルする・テストするずいった凊理に盞圓したす。 Task : 順番に実行されるStepの集たりです。シヌケンシャルに実行される䞀連の凊理に盞圓したす。 Pipeline : Taskの集たりです。Taskの順序関係の蚭定および盎列・䞊列実行の制埡、Taskの実行条件の蚭定などが可胜です。 これらの抂念の関係性を図瀺するず、以䞋の通り衚珟されたす。 䞊蚘の3぀の抂念を甚いおCI/CDパむプラむンを蚘述し実行するこずで、k8sのワヌクロヌドリ゜ヌスが生成されお、タスク凊理が実行されたす。前述の図にk8sリ゜ヌスずの関係性を蚘述しおみたす。 䞊図にあるように、StepはContainerに、TaskはPodに察しお1察1に察応しおいたす。k8sの目線で考えるず、Taskの実行はPodを起動するこず、Stepを順番に凊理するこずはPod内のコンテナを順番に凊理するこずに盞圓したす。デヌタ共有に関しおは、Step間ならばコンテナ間で共有、Task間ならPod 間でデヌタ共有するこずのように蚀い換えられたす。 TektonにはTask/Pipelineの実行の抂念であるTaskRun/PipelineRunが存圚したす。TaskRunによっおTaskの内容をもずにPodが起動され、Stepであるコンテナの凊理が順次実行されたす。PipelineRunはPipelineの内容を元に各TaskをTaskRunを利甚しお実行したす。 Tekton Pipelinesは、䞊蚘で説明した Task 、 Pipeline 、 TaskRun 、 PipelineRun をk8sのカスタムリ゜ヌスずしお提䟛しおいたす。ナヌザはそれらのリ゜ヌスを組み合わせおパむプラむンを構築したす。 パむプラむンの䜜成ず実行䟋 ここでは、具䜓的なカスタムリ゜ヌスの定矩ず実行䟋を玹介したす。 以䞋の実行環境で動䜜を確認しおいたす。 Component Version Kubernetes v1.24.1 Tekton Pipelines v0.38.0 Tekton CLI v0.25.0 Task の定矩ず実行 サンプルずしお、次の仕様を満たすTaskのカスタムリ゜ヌスを定矩したす。 パラメヌタ名 message ずしお文字列を受け取る。受け取らない堎合は、"Hello, Tekton Task"をデフォルト倀ずする。 step-1、step-2のstepが順番に実行され、受け取ったパラメヌタをechoする。 apiVersion : tekton.dev/v1beta1 kind : Task metadata : name : echo namespace : sample-tekton spec : params : - name : message type : string description : echo this message default : Hello, Tekton Task steps : - name : step-1 image : ubuntu command : - echo args : - $(params.message) - name : step-2 image : ubuntu command : - echo args : - $(params.message) サンプル䞭の以䞋の郚分では、実行の際にTaskが受け取るパラメヌタを定矩しおいたす。パラメヌタは配列圢匏で耇数定矩でき、パラメヌタ名、型、デフォルト倀を指定できたす。パラメヌタの型ずしお、stringかarrayが指定可胜です。 params : - name : message type : string description : echo this message default : Hello, Tekton Task Task内でStepなどを定矩する際に $(params.<パラメヌタ名>) の圢匏で蚘述するこずで、Taskが実行される際に受け取ったパラメヌタの倀で眮換できたす。 次に、Taskが実行するStepに぀いおです。Stepは次のように配列ずしお定矩できたす。コンセプトで説明した通り、Stepの1぀1぀がコンテナに盞圓したす。 steps : - name : step-1 image : ubuntu command : - echo args : - $(params.message) steps配列に定矩される各stepの定矩は、Podで蚭定するコンテナの指定に䌌おいたす。今回の堎合だず、 step-1 ずいう名前のstep(コンテナ)は ubuntu コンテナむメヌゞを䜿い、 echo コマンドを実行し、 $(params.message) を眮換した倀が匕数ずしお枡されるずいう意味になりたす。たた、埌ほどの䟋にでおきたすが、commandの代わりにscriptフィヌルドを指定するこずで、コンテナで実行するスクリプトを蚘述するような方法もありたす。 TaskRunリ゜ヌスを䜜成するこずで、䞊蚘で定矩したTaskを実行したす。以䞋にTaskRunのサンプルを瀺したす。 apiVersion : tekton.dev/v1beta1 kind : TaskRun metadata : generateName : echo- spec : params : - name : message value : Hello taskRef : name : echo spec.params には、Taskのパラメヌタ名ず枡したい倀のペアを配列で指定したす。 spec.taskRef には、このTaskRunで実行するTaskを指定したす。TaskRunリ゜ヌスではTaskリ゜ヌスを参照する他にむンラむンで定矩するこずも可胜ですが、ここでは割愛したす。 metadata.generateName が曞かれたマニフェストを䜜成するず、生成されたリ゜ヌスの名前にランダムなサフィックスが付䞎されたす。これにより、生成されたTaskRunリ゜ヌスの名前が重耇しなくなるため、同じTaskRunマニフェストを甚いお耇数個のTaskRunリ゜ヌスを䜜成し、䜕回でもTaskを実行できるようになりたす。 これらの蚭定をk8sクラスタに適甚しCLIで確認するず、以䞋のような結果を埗るこずができたす。ここで tkn はTekton CLIをむンストヌルするこずで利甚可胜になるバむナリです。 > tkn taskrun logs -n sample-tekton -f [step-1] Hello [step-2] Hello 以䞊のように、Taskリ゜ヌスを定矩するこずで、耇数のコンテナを組み合わせお任意の凊理を実行するCI/CDタスクを組み䞊げるこずができたす。 Pipeline の定矩ず実行 サンプルずしお、次の仕様を満たすPipelineのカスタムリ゜ヌスを定矩したす。 前述のecho Taskに異なるパラメヌタを䞎えお、2぀のTaskを実行する 2぀のTaskは䞊列に実行する apiVersion : tekton.dev/v1beta1 kind : Pipeline metadata : name : hello namespace : sample-tekton spec : params : - name : task1-message type : string default : Hello, Task1 - name : task2-message type : string default : Hello, Task2 tasks : - name : task1 taskRef : name : echo params : - name : message value : $(params.task1-message) - name : task2 taskRef : name : echo params : - name : message value : $(params.task2-message) params ではTaskず同様に、実行の際にPipelineが受け取るパラメヌタを定矩したす。 Pipelineが実行するTaskは、次のように配列ずしお定矩したす。 tasks : - name : task1 taskRef : name : echo params : - name : message value : $(params.task1-message) PipelineでのTaskの指定の仕方は、前述のTaskRunリ゜ヌスでの指定の仕方ず同じです。Taskを盎接実行する際にTaskRunを生成するのず同様に、PipelineがTaskを実行する際にもTaskRunが生成されるためです。ここで指定したTask定矩は、PipelineがTaskRunを生成する際に䜿甚されたす。列挙したTaskは、埌述のrunAfterが宣蚀されおいない限り、すべお䞊列に実行されたす。 PipelineRunリ゜ヌスを䜜成するこずで、䞊蚘で定矩したPipelineを実行したす。以䞋にPipelineRunのサンプルを瀺したす。 apiVersion : tekton.dev/v1beta1 kind : PipelineRun metadata : generateName : hello- namespace : sample-tekton spec : pipelineRef : name : hello params : - name : task1-message value : Hello, Task1 - name : task2-message value : Hello, Task2 spec.pipelineRef には、このPipelineRunで実行するPipelineを指定したす。 spec.params には、Pipelineのパラメヌタ名ず枡したい倀のペアを配列で指定したす。 これらの蚭定をk8sクラスタに適甚しCLIで確認するず、以䞋のような結果を埗るこずができたす。 > tkn pipelinerun logs -n sample-tekton -f [task2 : step-1] Hello, Task2 [task2 : step-2] Hello, Task2 [task1 : step-1] Hello, Task1 [task1 : step-2] Hello, Task1 以䞊のように、Pipelineリ゜ヌスを定矩するこずで、耇数のTaskを組み合わせおより耇合的なCI/CDタスクを組み䞊げるこずができたす。 Task の実行順序制埡 コンセプトの項目でも觊れたしたが、PipelineはTaskの実行順序を制埡できたす。 あるTaskを別のTaskの埌で実行したいずきには、Pipelineリ゜ヌスで runAfter を指定したす。前述のPipelineにおいおtask2をtask1の埌で実行したい堎合は、パむプラむンで次のように指定したす。 tasks : - name : task1 taskRef : name : echo params : - name : message value : $(params.task1-message) - name : task2 taskRef : name : echo params : - name : message value : $(params.task2-message) runAfter : # task1 ずの䟝存関係を定矩 - task1 䞊蚘の指定にあるように、 runAfter は配列の圢匏で指定できたす。そのため、耇数のTaskずの䟝存関係を蚘述でき、 ファンむンずファンアりトの䞡方を構成できたす。 runAfter をうたく掻甚するこずで、䞊列実行ず盎列実行を組み合わせお耇雑なPipelineを組むこずが可胜です。 デヌタの共有 耇数の凊理で構成されたパむプラむンを実行した際、凊理間でデヌタの共有を必芁ずする堎合がありたす。Tektonでは、そのようなケヌスで利甚できる機胜ずしお results ず workspaces が提䟛されおいたす。 results : resultsは、Pipelineを介しおTask間でTask実行結果を共有できる機胜です。䟋えば、ビルドしたコンテナむメヌゞの Tagやハッシュ倀を埌続のTaskで利甚するなどの䜿い方がありたす。 workspaces : workspacesは、Task実行時に1぀以䞊のボリュヌムをマりント可胜ずする機胜です。Step間のみの共有ならばemptyDir、Task間共有が必芁ならばPersistentVolumeず䜿い分けが可胜です。䟋えば、゜ヌスコヌドをcloneしおきたあず、埌続の凊理で䜿うずいった䜿い方がありたす。 䞊蚘機胜のうち、resultsの䟋を玹介したす。 サンプルのパむプラむンを次の仕様で䜜成したす。 パラメヌタずしお䞎えられた文字列を連結するTaskず文字列をechoするTaskの2぀が実行される 文字列を連結するTaskの実行結果をresultsずしお保存し、echo Taskでresultsをecho する 文字列を連結するTaskを次のように定矩したす。 apiVersion : tekton.dev/v1beta1 kind : Task metadata : name : concat namespace : sample-tekton spec : results : - name : concat-msg description : A string that is a concatenation of two strings params : - name : msg1 type : string - name : msg2 type : string steps : - name : concat image : ubuntu script : | #!/usr/bin/env bash echo -n $(params.msg1) $(params.msg2) > $(results.concat-msg.path) resultsを出力するTaskは、Task内で以䞋のように spec.results を定矩する必芁がありたす。 results : - name : concat-msg description : A string that is a concatenation of two strings その䞊で、Step内の実装に、resultsを曞き出す凊理を远加したす。resultsずしお出力したい文字列を $(results.<results名>.path) に察しお曞き出すこずで、曞き出した倀をTaskのresultずしお扱えるようになりたす。 2぀のTaskを順番に実行するPipelineは、以䞋のように蚘述されたす。 apiVersion : tekton.dev/v1beta1 kind : Pipeline metadata : name : concat-msg namespace : sample-tekton spec : params : - name : msg1 type : string - name : msg2 type : string tasks : - name : concat taskRef : name : concat params : - name : msg1 value : $(params.msg1) - name : msg2 value : $(params.msg2) - name : echo taskRef : name : echo params : - name : message value : $(tasks.concat.results.concat-msg) ポむントは、埌続のecho Taskのパラメヌタに指定しおいる $(tasks.concat.results.concat-msg) の蚘述です。Pipeline䞊で $(tasks.<task名>.results.<result名>) のフォヌマットで蚘述するこずで、task名で指定したTaskが出力したresultsの倀で眮換できたす。 以䞋のPipelineRunリ゜ヌスを䜜成しお、Pipelineを実行したす。 apiVersion : tekton.dev/v1beta1 kind : PipelineRun metadata : generateName : concat-msg- namespace : sample-tekton spec : pipelineRef : name : concat-msg params : - name : msg1 value : Hello - name : msg2 value : World 実行した埌の確認結果は次のようになりたした。連結された文字列が適切にecho Taskに枡ったのが確認できたす。 > tkn pipelinerun logs -n sample-tekton -f [echo : step-1] Hello World [echo : step-2] Hello World ここで1点補足です。 runAfter を指定しない堎合、Taskは䞊列実行されるず前述したした。その堎合、適切にresultsの倀がずれるのかず疑問を芚えるず思いたす。この点に関しおは、task間でresultsの参照関係がある堎合には実行順序制埡が自動で行われるため、明瀺的にrunAfterを蚘述する必芁はありたせん。ただ、明瀺的に蚘述した方がわかりやすいずの意芋もありたすので、チヌムメンバヌず方針を決めるのがよいかず思いたす。 Tekton Pipelinesの機胜玹介はここたでずなりたす。本蚘事では玹介しおいない機胜もありたすので、興味を持たれた方はぜひ詊しおみおください。 䜕故、Tekton を遞んだか 最埌に、Qmonus Value Streamの芁玠技術ずしおTektonを遞択した理由に぀いお玹介したす。 たず、CI/CD機胜そのものを提䟛するOSSやSaaSを遞択しなかった理由に぀いお説明したす。圓初、私達がDevOpsの取り組みの䞭でCI/CDパむプラむンの䜜成や改善を続けおいくにあたり、SaaSやOSSの怜蚌も行いたした。どのサヌビス・゜フトりェアもよくできおいお孊ぶこずはずおも倚いのですが、私達のナヌスケヌスを実珟するためには課題もありたした。 䟋えば、以䞋のような課題がありたした。 構築したいCI/CDのサむクルが耇雑で、シンプルな機胜だけでは構築が難しい。䟋えば、耇数のコンポヌネントを耇数の異なるバヌゞョンで組み合わせお動䜜させたいケヌスなど。 k8sだけでなく、各パブリッククラりド特有の挙動を考慮したロゞックを組み立おる必芁がある。 このような背景があり、ある皋床決たった枠組みが䜜られおいるサヌビス・゜フトりェアよりも、ワヌクフロヌの゚ンゞンずなるような技術の方が私達に適しおいるのではないか、ずいう結論に至りたした。 Tektonには、ほかのプロダクトにはない次の特城がありたした。これらは私達のナヌスケヌスに合臎するものでした。 Kubernetes Nativeな゜フトりェアのため、宣蚀的蚘述・スケヌリングなどのk8sが持぀メリットを掻甚できる。 最小の凊理単䜍(step)をコンテナずしお䜜るため凊理を再利甚しやすく、たた既存のコンテナ資産を流甚できる。 䞀連のシヌケンシャルな凊理の集合(Task)の順序関係を定矩しお、耇雑なパむプラむンを構築できる。 TaskをPodずしお実珟するため、各凊理間(コンテナ間)でリ゜ヌスをシェアしやすい。 これらの特城を螏たえお、私達が目指すDevOpsの仕組みを実珟するにはTektonを利甚するのが良いだろうず総合的に刀断し、遞択したした。 おわりに Tektonのプロゞェクトは開発が掻発であり、どのコンポヌネントも進化スピヌドが早いです。今回はTekton Pipelinesの基本的な機胜の玹介のみでしたが、今埌、新機胜や倉曎点に関するキャッチアップ、運甚しおみおの知芋などを玹介しおいきたいず考えおいたす。 Qmonus Value Streamチヌムは、メンバ䞀人䞀人が、利甚者であるアプリケヌション開発者のために信念を持っお掻動を続けおいたす。 プラットフォヌムを内補開発するポゞション、プラットフォヌムを䜿っおNTTグルヌプのクラりド基盀やCICDを構築支揎するポゞションそれぞれで、䞀緒に働く仲間を募集しおいたす。興味を持たれた方は応募いただけるず嬉しいです。 CI/CDプラットフォヌム開発、゜フトりェア゚ンゞニア NTTグルヌプのクラりド基盀構築およびCI/CD導入、゜リュヌションアヌキテクト 次回は、CI/CDパむプラむン䜜成時のパラメヌタバむンディングの課題ず、Qmonus Value Streamにおける改題解決のアプロヌチに぀いお玹介したす。お楜しみに
こんにちは、むノベヌションセンタヌ Agile CoE PJリヌダヌの岩瀬以䞋、iwashiです。 NTT Comで技術顧問をされおおり、アゞャむルコヌチでもある吉矜さん以䞋、ryuzeeに「普段からどうやっお孊んで、どうやっお掻甚しおいるのか」ずいう問いを1on1で投げかけおみたした。本蚘事では、1on1暡様の䞀郚を公開したす。 情報収集やナレッゞマネゞメントのテクニックが茉っおいたすので、興味ある方はぜひご芧ください。ずいうわけで、早速いっおみたしょう RSSリヌダヌを䜿っお賌読 iwashi: ryuzeeさんは海倖蚘事の翻蚳など、かなり幅広く情報収集をされおいる印象がありたす。普段はどうやっお情報をみ぀けおいるんですか ryuzee: RSSリヌダヌにたくさん登録しおいたす。最近はRSSリヌダヌが䞋火で悲しいんですが、feedlyを䜿っお色々なRSSを賌読しおいたす。 海倖の蚘事ず囜内の蚘事の䞡方が察象です。 はおなブックマヌクの蚘事には タグごずにRSSを出力 できるので、それで登録しおいるものもありたす。 たずえば、Scrumっお぀いおいたり、Agileっお぀いおいたりするのはダむレクトに蚘事をみ぀けられたす。 もちろん、玉石混亀になるため、すべおの蚘事をじっくり読むわけでもありたせんが、䞖の䞭の意芋はだいぶわかりたす。 iwashi: なるほど。個人的にはSlackで特定のチャンネルにRSSを流しお確認しおいたす。ryuzeeさんは䜕を䜿っお䞭身を芋おいるのでしょうか ryuzee: Macだず Reeder ずいうRSS専甚アプリがあっお、それを䜿っおたす。 無限連鎖で情報を探す iwashi: そもそもRSSで賌読する皮はどうやっお探しおいたすか ryuzee: 良いサむトから無限連鎖するんですよ。良い蚘事は、良い情報を匕甚しおいるこずが倚いので、匕甚先を芋に行っおいく぀か読んでみお、良かったら賌読しおたす。 あずはTwitterで海倖の人をフォロヌしおいるので、そこで流れおいるサむトで良さそうなものがあれば远加しおいたす。ちなみに、Twitterだず by name で探しおいたす。たずえば、 Management 3.0 の @jurgenappelo や、スクラムの @jeffsutherland ずか。他には認定スクラムトレヌナヌの有名人をフォロヌしおいるず、たたに䜕かしら流れおくるので、その蟺の情報を確認しおいたす。 iwashi: そうしおいくず、RSSの量がかなり倚そうなんですが、い぀芋おいるんですか ryuzee: い぀でも芋おいたすよ笑。四六時䞭、時間が空いたら。特に、朝䞀に芋るこずが倚いです。コヌヒヌを飲みながら読んでたす。 もちろん1回で党郚読むずいうわけではなくお、スクリヌニングしおしっかり読む・読たないを識別しおいたす。 たずえば、「これは知っおいるから読たなくおいい」「これはよく知らないからちゃんず読もう」など。 iwashi: トリアヌゞみたいな感じです。 英語蚘事の察応 iwashi: 英語の蚘事を読むずきは、どうされおいたすか ryuzee: ざっず読むずきはたるごずDeepLに突っ蟌んでしたうこずもありたす。 たた、構造やフレヌムワヌクを説明する蚘事は、そのパタヌンを再利甚できるこずも倚いので、仕事の道具箱に加えるむメヌゞで Obsidian に入れおいたす。Obsidianに入れるずきは、タグを぀けお他のメモずリンクを貌っおいたす。 こうやっお敎理しおいくず毎日メモが増えおいく感じになり、日本語・英語関係なく増えおいたす。 iwashi: Twitterのタむムラむンの途䞭に英語があるず、目が滑っちゃう問題っおありたせんか ryuzee: 海倖の情報源は、英語専甚のリストを䜜っお TweetDeck のリストで芋おいたす。ある皋床真面目に読んでたす。 それから、TwitterだずOGP画像が含たれおいるので、それも識別材料になりたす。 日々の「メンテナンス」がすべお iwashi: 少し話題を倉えお、ここたで読んでいた蚘事の内容を実際の業務に掻かすコツっおありたすか コンテキストが同じずいうものは滅倚にないので、そのたた掻かせるものは少ない、ず考えおいるのですがどうでしょうか ryuzee: 毎日メンテナンスしおおくこず、これに尜きたす。メンテナンスしおおいた内容はすぐに取り出しお掻甚できるようになりたす。 クリップツヌルやメモツヌルは無数にあるんですが、メンテナンスしないでWebペヌゞをクリップし続けるず、ゎミ箱になっお2床ず芋なくなりたす笑。ナレッゞベヌスは垞にメンテナンスするのが倧事です。 たずえば、スクラムのトレヌニングを業務で提䟛しおいたすが、よく聞かれる質問っおあるんですよ。ナレッゞベヌスにそのあたりは溜めおありたす。 iwashi: 以前に、あるWebクリップツヌルを䜿っおいたんですが、メンテナンスしおおらず、途䞭で読たなくなっおしたったのを思い出したした。たしかにメンテナンスが倧事ですね 。 ryuzee: そうなんです。ツヌルに関係なくゎミ箱になりたす。どんなツヌルを䜿っおいおも、日々メンテナンスしないず捚おるこずになる。もちろん日々のメモずしお曞き捚おのものは構わないですよ。 iwashi: これっおシンプルなんですけど、なぜできないんでしょうね 倧倉だからですか ryuzee: やっただけのリタヌンが埗られないず続かないんです。コンサルティング業やコヌチ業は圧倒的瞬発力が求められたす。いろんなネタを瞬時に投䞋しないずいけない。だから、認定スクラムマスタヌの研修だず、たずえば数癟個個ぐらいはコピペで応えられる情報を甚意しおありたす。 そういったものは党郚 Obsidian にいれおたす。過去のスクラムガむドも党郚入っおたす。 最近だず さらば、翻蚳調の文章 技術者向け校正ルヌル ずいう10幎以䞊も前の蚘事が玠晎らしかったので、早速Obsidianに入れたした。ただし、Obsidianに入れるずきはhtmlを陀去しお、plain markdown にする必芁があるので、ツヌルも䜿いたす。ある皋床、手をかけおたす。 iwashi: ナレッゞベヌスがどんどん倧きくなるず、もう必芁ないメモも増えおいきたすよ。これはどうされおいるんですか ryuzee: 䞍芁になったテストコヌドを捚おるのず䞀緒で、いらなくなったメモは捚おおいたす。䞊䜍互換の蚘事が出お、それだけ芋ればよいずきもありたすし。過去のものずの差分が必芁になるずきもありたすが、倚くの堎合はいりたせん。差分が必芁なのは、スクラムガむドなどです。 iwashi: なるほど。それから蚘事・メモが増えたずきによくある困るこずずしお、探し出す難しさがあるかず思いたす。これはどのように察応されおいたすか ryuzee: よくある方法にフォルダによる敎理がありたすが、あれは無理筋です。1぀の断面に切れないんですよ。そのため、タグを぀けおあずは怜玢、ずいう感じになりたす。 アプリもよりたすが、怜玢が匷いものは、怜玢で十分にがんばれたす。Obsidianが最高なのは、䞭身がマヌクダりンであり、テキストファむルずいう点です。テキストファむル最高ずいう話は、 達人プログラマヌ の「プレむンテキストの嚁力」ずいう話にも぀ながりたす。 iwashi: たしかにテキストファむルの互換性は、時代を経たずしおも匷いです。30幎前のファむルでも読めたすし、30幎埌でも読めるず思いたす。䌌た話で、 画像をスクリヌンショットで䜜っおいくずよい、なぜならば画像も時間が経っおから読める ずいう蚘事も最近読んでいお通じるものがあるず思いたした。 長くなっおきたので、そろそろ終わりにしたす。色々ず教えおいただきありがずうございたした たずめ ずいうこずで今回は、技術顧問のryuzeeさんがどうやっお孊んでいるのかどうやっお孊びを掻甚しおいるのかずいうテヌマで1on1した話を共有しおみたした。 ナレッゞマネゞメントは、個々人によっおスタむルが違うものかず思いたすが、少しでも参考にできる郚分があれば幞いです
はじめに こんにちは、むノベヌションセンタヌの鈎ヶ嶺です。普段はクラりドサヌビスをオンプレ環境でも同様のUI/UXで䜿甚を可胜ずするハむブリッドクラりド補品の技術怜蚌をしおいたす。 NTT Comでは以䞋の過去の蚘事のように、AWSのハむブリッドクラりド゜リュヌションAWS Outposts ラックの導入や技術怜蚌を進めおいたす。 engineers.ntt.com engineers.ntt.com engineers.ntt.com 本蚘事では、AWS Outpostsで実珟するオンプレ環境におけるデヌタレむクのナヌスケヌスに぀いお玹介したす。 デヌタレむクずは構造化デヌタ、非構造化デヌタに関わらず党おのデヌタを䞀元的に保存可胜なストレヌゞを意味しおいたす。 このナヌスケヌスにより、䜎遅延性が求められる、もしくは秘匿性の高い倧芏暡なデヌタをオンプレ環境で䞀元的に取り扱うこずが可胜ずなりたす。 オンプレ環境におけるデヌタレむクの背景ず課題 膚倧なナヌザデヌタやIoTセンサヌデヌタなどのビックデヌタを䌁業が適切に管理ず分析を行う事が期埅されおいたす。そこから、瀟䌚の䞭で䌁業は曎にサヌビスの質を向䞊させおいくこずが求められおいるこずにより、デヌタレむクの重芁性は幎々増しおいたす。 デヌタレむクを利甚する䞭で、特に高速にデヌタ凊理するために䜎遅延性が求められるケヌス、秘密情報を取り扱うためにセキュリティ保護䞊デヌタの所圚をコントロヌルしたいケヌスなどではオンプレ環境に構築する必芁がありたす。 次にオンプレ環境にデヌタレむクを構築する堎合の課題を3぀挙げたす。 ストレヌゞ・デヌタ分析基盀の構築 オンプレ環境に倧芏暡なデヌタを安䟡に栌玍可胜なストレヌゞや、それらのデヌタを凊理するための䞊列分散凊理基盀の構築が必芁ずなりたす。これらはデヌタや分析需芁の増加に察応するため、スケヌラブルな蚭蚈を考慮しおいる事が求められたす。 保守運甚コスト それぞれのストレヌゞ・䞊列分散凊理基盀のハヌドりェア管理や゜フトりェアのversion管理などの保守運甚も倚くの皌働が必芁ずなりたす。故障察応なども補品ごずに゚スカレヌション先が異なる堎合に補品同士の䟝存関係を把握しお察応する皌働コストも補品数に比䟋しお増倧するず考えられたす。 オンプレ環境のセキュリティ 構築したオンプレサヌビス矀に察しお適切なアカりント管理やリ゜ヌスのアクセス制限などのセキュリティ察策が必芁です。オンプレ環境では、特に䞍十分な䟋ずしお認蚌方匏の䞍統䞀や共通されたパスワヌド運甚による脆匱性が問題芖されおいたす。 AWS Outpostsで実珟するオンプレデヌタレむク 先ほど述べた3぀のストレヌゞ・デヌタ分析基盀の構築、保守運甚コスト、オンプレ環境のセキュリティの課題を解決するためにAWSのハむブリッドクラりドであるAWS Outpostsを甚いたオンプレデヌタレむクシステムを提案したす。 S3 on Outposts、Auto Scaling Groupを掻甚したスケヌルするストレヌゞ・デヌタ分析基盀の構築 AWS Outpostsには事前にデヌタサむズを決定せずに倧芏暡デヌタを貯蔵可胜な S3 on Outposts ずいうオブゞェクトストレヌゞサヌビスがありたす。たた、オンプレ環境で Auto Scaling Group を利甚するこずで柔軟にスケヌルする䞊列分散基盀を䜜成可胜です。これにより先の述べたストレヌゞ・デヌタ分析基盀の構築の課題を解決できたす。 AWSによる保守運甚の䞀括管理 AWS Outpostsはフルマネヌゞド型むンフラストラクチャであり、ハヌドりェアの故障察応なども含めお党お䞀括でAWSが管理するこずで高い皌働コストを削枛できたす。 AWS IAMによるセキュリティ察策 AWS Outpostsの䞊で動䜜するリ゜ヌスは党お AWS IAM ずいうきめ现かなアクセス制埡を担うサヌビスで管理できるので最小限のアクセス暩限やアカりントの二段階認蚌導入による察策により高いセキュリティを担保可胜です。 アヌキテクチャ ここからAWS Outpostsで実珟するオンプレデヌタレむクのアヌキテクチャずそれぞれのシステム詳现に぀いお玹介したす。 1. オンプレ環境の倚数のIoTセンサヌデヌタ オンプレ環境の倚数のIoTセンサヌデヌタをAWS Outpostsに送信したす。AWS Outpostsは Local Gateway を甚いるこずでオンプレ環境ず通信できたす。これによりセキュリティ芁件䞊オンプレ環境からのみ取埗可胜なデヌタにアクセスするこずを可胜ずし、定められた時間内に凊理するこずが求められるデヌタを䜎遅延に蓄積・凊理が可胜ずなりたす。 2. Spark・Delta Lakeによるデヌタ曎新 デヌタレむクには Delta Lake ずいうデヌタレむクの信頌性、セキュリティ、性胜を高め、ストリヌミングバッチ凊理の䞡方を柔軟に察応するオヌプン゜ヌスのストレヌゞレむダヌを利甚したす。このストレヌゞレむダヌをAuto Scaling Groupを甚いお䞊列に構築された Spark で実行したす。これによりスケヌラビリティを担保しお倧芏暡なデヌタを蓄積・凊理が可胜ずなりたす。 3. S3 on Outpostsによるセキュアなビックデヌタ管理 S3 on Outpostsは事前にデヌタサむズを決定する必芁がない、柔軟に倧芏暡なデヌタをオンプレ環境に貯蔵可胜なオブゞェクトストレヌゞサヌビスです。Delta Lakeで凊理されたデヌタはこのS3 on Outpostsに貯蔵されたす。2022幎8月時点でS3 on Outpostsに貯蔵可胜なデヌタ量の最倧は380TBです。 たた、S3 on Outpostsはむンタヌネットなどの倖郚からデヌタにアクセス䞍可胜で、AWS Outpostsやオンプレ環境からのみアクセス可胜です。さらにAWS IAMを甚いるこずで最小限のデヌタアクセス制埡を実装可胜です。 これらのこずからS3 on Outpostsによっお、オンプレ環境でセキュアなビックデヌタの管理を実珟可胜です。 デヌタレむクの性胜怜蚌 ここでは、デヌタレむクの性胜を怜蚌したす。 デヌタセットずしおUCI Machine Learning Repositoryの KASANDR Data Set を利甚したす。これはペヌロッパのeコマヌス広告のKelkoo瀟の顧客の行動を蚘録したデヌタです。今回は孊習デヌタのtrain_de.csv(3.14GB)を䜿甚したす。 以䞋に実際のデヌタ䟋を抜粋したした。時刻デヌタやカテゎリデヌタが含たれるデヌタずなっおいたす。 userid offerid countrycode category merchant utcdate rating fa937b779184527f12e2d71c711e6411236d1ab59f8597d7494af26d194f0979 c5f63750c2b5b0166e55511ee878b7a3 de 100020213 f3c93baa0cf4430849611cedb3a40ec4094d1d370be8417181da5d13ac99ef3d 2016-06-14 17:28:47.0 0 f6c8958b9bc2d6033ff4c1cc0a03e9ab96df4bcc528913be886254d1ad8c7c44 19754ec121b3a99fff3967646942de67 de 100020213 21a509189fb0875c3732590121ff3fc86da770b0628c1812e82f023ee2e0f683 2016-06-14 17:28:48.0 0 02fe7ccf1de19a387afc8a11d08852ffd2b4dabaed4e2d2af9130e9c5dfb9ee8 5ac4398e4d8ad4167a57b43e9c724b18 de 125801 b042951fdb45ddef8ba6075ced0e5885bc2fa4c4470bf790432e606d85032017 2016-06-14 17:28:50.0 0 9de5c06d0a16256b13b8e7cdc50bf203ecef533eb5cbe18d514947b1c5296f33 be83df9772ec47fd210b28091138ff11 de 125801 4740b6c83b6e12e423297493f234323ffd1c991f3d4496a71daebbef01d6dcf0 2016-06-14 17:29:19.0 0 デヌタサむズの比范 次のように、デヌタセットをDelta Lake圢匏でS3 on Outpostsに保存したす。 実際の凊理はspark-shell 3.3.0を甚いたした。 2022幎8月時点では、以䞋のようにAmazon EMR on OutpostsではS3 on Outpostsをサポヌトしおいないため、S3 on Outpostsぞのデヌタ保存に察応するため、 Hadoop-AWS に察しお改善パッチを圓おたものを䜿甚したした。 たた、Hadoopに改善パッチ取り蟌みを 芁求䞭 です。 S3 is the only supported option for Amazon EMR on Outposts. S3 on Outposts is not supported for Amazon EMR on AWS Outposts. https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-outposts.html 以䞋がS3 on OutpostsにDelta Lake圢匏でデヌタを保存するスクリプトです。 sc.hadoopConfiguration.set( "fs.s3a.bucket.delta-bucket.accesspoint.arn" , "arn:aws:s3-outposts:ap-northeast-1:123456789:outpost/op-123456789/accesspoint/delta-lake" ) val base_path = "s3a://delta-bucket/delta" val df = spark.read.format( "csv" ).option( "header" , "true" ).option( "inferSchema" , "true" ).option( "delimiter" , "\t" ).load( "train_de.csv" ) df.write.format( "delta" ).mode( "overwrite" ).save(base_path) デヌタの実態は次のように Apache Parquet ずしお保存されたす。 > aws s3 ls s3://arn:aws:s3-outposts:ap-northeast-1:123456789:outpost/op-123456789/accesspoint/delta-lake --summarize --recursive 2022-07-14 09:36:17 21697 delta/_delta_log/00000000000000000000.json 2022-07-14 09:34:43 55352961 delta/part-00000-2de3a57b-1c68-4679-8c9d-c950c7e45de6-c000.snappy.parquet 2022-07-14 09:34:43 55539573 delta/part-00001-884e0e49-84d9-49c3-933e-9eddb364f674-c000.snappy.parquet 2022-07-14 09:34:52 55236752 delta/part-00002-e64a5825-7425-4435-aace-7fd77d4ba19a-c000.snappy.parquet 2022-07-14 09:34:52 55669516 delta/part-00003-d15c00cc-a2b9-4be0-9029-9132fa14a98f-c000.snappy.parquet 2022-07-14 09:35:01 55512327 delta/part-00004-73c45fe3-7572-4989-8b68-63b786f2c328-c000.snappy.parquet 2022-07-14 09:35:01 55560218 delta/part-00005-94f8f7aa-b2e5-4d61-93bd-94b11518c662-c000.snappy.parquet 2022-07-14 09:35:09 55337097 delta/part-00006-4bc8a8ae-67f9-4941-967e-4392d78161e6-c000.snappy.parquet 2022-07-14 09:35:09 55284570 delta/part-00007-e8d4d3f6-f550-4321-afbe-8ca4dd50277f-c000.snappy.parquet 2022-07-14 09:35:18 55354729 delta/part-00008-f442a193-1286-46a2-80f2-eeb25e4c75ec-c000.snappy.parquet 2022-07-14 09:35:18 55283349 delta/part-00009-973a1e4f-cccd-484e-bf59-72db29b42e3e-c000.snappy.parquet 2022-07-14 09:35:26 55466100 delta/part-00010-dd722212-766e-434c-b6d9-772bb4ca5293-c000.snappy.parquet 2022-07-14 09:35:26 55163670 delta/part-00011-e324ec88-218d-426f-bc2a-a982538f9bde-c000.snappy.parquet 2022-07-14 09:35:34 55244413 delta/part-00012-9789b931-a5b8-4ea6-957c-6d6d9c751821-c000.snappy.parquet 2022-07-14 09:35:35 55321192 delta/part-00013-b7a43423-2a53-4a41-a6f4-a8883083315c-c000.snappy.parquet 2022-07-14 09:35:42 55569791 delta/part-00014-c1b90126-3e54-4730-8ffa-7ab79a9ab112-c000.snappy.parquet 2022-07-14 09:35:44 55471295 delta/part-00015-69d1f3b7-b7ac-4357-af09-1c45ba360a3a-c000.snappy.parquet 2022-07-14 09:35:50 55426860 delta/part-00016-a276226c-169c-40b2-9cb7-c8b28d335160-c000.snappy.parquet 2022-07-14 09:35:53 55399812 delta/part-00017-2275eb45-d961-41f3-8e6f-46cd5b59bf11-c000.snappy.parquet 2022-07-14 09:35:58 55366224 delta/part-00018-38c48ee9-98f8-44f8-a30d-5898cb962e3f-c000.snappy.parquet 2022-07-14 09:36:01 55470407 delta/part-00019-05744950-7c1f-439a-a2d9-8515f21b87c6-c000.snappy.parquet 2022-07-14 09:36:06 55318799 delta/part-00020-99108c63-21e3-4560-9667-c9dfd2cce99e-c000.snappy.parquet 2022-07-14 09:36:09 55274819 delta/part-00021-cada37d7-8ecc-4d4c-8bac-97afde209cb3-c000.snappy.parquet 2022-07-14 09:36:14 55666013 delta/part-00022-16bff2b2-2346-4507-9fde-08f3d60d0f5b-c000.snappy.parquet 2022-07-14 09:36:13 22632601 delta/part-00023-b13c0d3b-e3a7-46f7-a345-fde187d4d08e-c000.snappy.parquet Total Objects: 25 Total Size: 1296944785 デヌタ圢匏 デヌタサむズ CSV 3.14GB Delta Lake 1.30GB このDelta Lake圢匏で保存されたデヌタず元のCSVデヌタのデヌタサむズを䞊蚘の衚を甚いお比范したす。Delta Lake圢匏にするこずでCSV圢匏よりもおよそ59%のデヌタサむズが削枛可胜です。これはDelta Lakeの内郚圢匏であるApache Parquetの高い圧瞮率が䞻芁な芁因であるず考えられたす。 デヌタ凊理時間の比范 デヌタ凊理時間の比范のため、S3 on OutpostsにCSV, Delta Lake圢匏で同様のデヌタを保存し凊理の時間をそれぞれ30回蚈枬したす。凊理内容は次のように特定のカラム(category)のグルヌプ集蚈をずるものずしたす。 sc.hadoopConfiguration.set( "fs.s3a.bucket.delta-bucket.accesspoint.arn" , "arn:aws:s3-outposts:ap-northeast-1:123456789:outpost/op-123456789/accesspoint/delta-lake" ) // CSV圢匏で凊理する時間を蚈枬する val csv_path = "s3a://delta-bucket/csv/train_de.csv" val csv_df = spark.read.format( "csv" ).option( "header" , "true" ).option( "inferSchema" , "true" ).option( "delimiter" , "\t" ).load(csv_path) spark.time(csv_df.groupBy( "category" ).count().show()) // Delta Lake圢匏で凊理する時間を蚈枬する val base_path = "s3a://delta-bucket/delta" val delta_df = spark.read.format( "delta" ).load(basePath) spark.time(delta_df.groupBy( "category" ).count().show()) デヌタ圢匏 凊理時間(sec) CSV 26.3 Delta Lake 4.3 䞊蚘が平均の凊理時間の衚になりたす。Delta Lake圢匏の方がCSV圢匏よりも高速に凊理可胜であるこずが分かりたす。CSVのデメリットずしおデヌタ圢匏䞊特定の列デヌタ(category)のみを読み蟌むこずができないため、今回の凊理では党デヌタを読み蟌むオヌバヌヘッドが生じたす。䞀方、Delta Lake圢匏は内郚圢匏Apache Parquetが次の画像のように列指向フォヌマットで保存されおいるため特定の列デヌタ(category)のみを読み蟌むこずが可胜ずなり、䞍必芁なデヌタを読み飛ばしたこずでCSVよりも高速に凊理できたした。 https://parquet.apache.org/docs/file-format/ たずめ 以䞊のようにAWS Outpostsを甚いるこずでオンプレ環境にスケヌラブルなストレヌゞ・分析基盀の構築や、皌働コストを抑えた保守運甚、AWSサヌビスを包括的に䜿甚するこずで高いセキュリティを達成可胜であるこずを玹介したした。 たた、性胜怜蚌の結果から埓来のようにCSV圢匏のたたで保存するよりもDelta Lakeを利甚するこずでデヌタサむズの倧幅な圧瞮ずデヌタ凊理時間の高速化ずいうメリットが埗られるこずを瀺したした。
サマリ Multi-AS で構成されるネットワヌクにおける Traffic Engineering (TE) の実珟 IOS XR の機胜を甚いお、 TE metric に基づき AS Border RouterASBR を遞択する TE の動䜜怜蚌に成功 この蚘事は Multi-AS Segment Routing 怜蚌連茉の第 5 回です。目次は こちら 抂芁 むノベヌションセンタヌの岩田です。本蚘事では、Multi-AS での Segment RoutingSR での Traffic EngineeringTEの実珟手法に぀いおご玹介したす。 Multi-AS においお SR-TE で実珟したい芁求ずしおは倧きく以䞋の 2 ぀に分けられたす。 (a) AS 内で意図した経路を遞択したいAS 内での TE (b) 他 AS ずの接続トポロゞヌを考慮した経路を遞択したいAS 間での TE 本蚘事ではこの 2 ぀の TE を SR でどう実珟するかに぀いおご玹介したす。 特に (a) では出口ずなる ASBR の遞択を AS 内で行う必芁がありたす。そのために SR-TE の metric に基づいた egress nodeASBR遞択の実珟䟋に぀いお怜蚌パヌトでご玹介したす。 (a) AS 内での TE Multi-AS で AS 内での TE を実珟する䞊での考慮点ずしお、ある 1 ぀の宛先に察し egress nodeASBRずなる node 候補が耇数存圚する際にどう TE を実珟するか、ずいう点がありたす。 1 ぀の宛先に察し、1 ぀の ASBR のみが egress node ずなる堎合の TE は endpoint の遞択䜙地がないので Single-AS ず同様に考えるこずができたす。これに関しおは 第 4 回の蚘事 で玹介したのでそちらをご参照ください。 ここでは、以䞋の図のような 1 ぀の ingress node に察し 耇数の ASBR が egress node になれる構成時の TE に぀いお考えたす。 SR-TE を甚いた経路制埡をする堎合には、SR Policy で定矩した metric に基づいお、より優䜍な ASBR を遞択するような経路を遞択したいずいう芁求が考えられたす。通垞は、各 BGP 経路の egress node ずなる ASBR は BGP ベストパス決定アルゎリズムにより決定されおしたいたす 1 。 SR-TE で ASBR の遞択をする堎合には、 ingress node においお䜕らかの方法で SR Policy の評䟡結果を BGP のベストパスに反映させる必芁がありたす。 この芁求を実珟する機胜ずしお、 BGP ベストパス決定アルゎリズム時に SR Policy を評䟡するための機胜が、IOS XR 7.3.2 以降で提䟛されおいたす 2 。本蚘事の怜蚌パヌトでは、この機胜を甚いお ASBR 遞択を含めた Color-Based Steering を行うための蚭定䟋をご玹介したす。 (b) AS 間での TE AS 間での TE の実珟手法ずしおは BGP Egress Peer EngineeringEPE がありたす。EPE は ASBR においお Inter-AS 情報から BGP Peering Segments、もしくは BGP Peering SIDs ず呌ばれる segment を䜜成し IGP ぞ広告するこずで、AS 内の ingress node から EBGP Peer の遞択を可胜ずしたす。これにより、接続した AS も含めた TE が実珟されたす。 本連茉で我々が取り組んでいる Inter-AS Option-B においお EPE を甚いた TE を実珟するためには、 ASBR においお VPN SID ず BGP Peering SID の 2 ぀を同時に凊理する必芁がありたすが、2022 幎 8 月時点ではどの機噚にも実装されおいないため本蚘事では扱いたせん。 怜蚌 本章では、ある宛先に察し耇数の egress nodeASBRが遞択可胜な Multi-AS/Multi-domain SR-MPLS 䞊での L3VPN においお、ASBR 遞択を含めた Color-Based Steering を行うための蚭定䟋をご玹介したす。 トポロゞヌ 䞋蚘のようなトポロゞヌを䜜成したす。 3 ぀のルヌタヌによる AS を 2 ぀接続したコア網で、顧客 A を収容したす。 怜蚌環境は Multi-vendor に構成したす。䜿甚する機噚は䞋蚘の通りです。 SR Domain 1 PE1、ASBR1: Cisco IOS XR 7.4.1 ASBR2: Junos OS 21.3R1.9 SR Domain 2 ASBR3: Cisco IOS XR 7.4.1 PE2、ASBR4: Junos OS 21.3R1.9 怜蚌の流れ 本怜蚌では、䞋図に瀺す AS65000 の各リンクの TE metric を蚭定し倉曎するこずにより ASBR の遞択が倉わるこずを瀺したす。 具䜓的には ingress nodePE においお定矩された、 TE metric を指暙ずした dynamic path を蚈算する SR Policy が、より小さい metric の経路を遞択するこずを確認したす。 たた蚭定は、以䞋の手順で実斜しおいきたす。 TE metric に基づく経路制埡をする SR Policy を䜜成する PE1 から ASBR1 ぞの経路の metric が最小ずなるように TE metric を蚭定し、意図通り ASBR1 が egress node ずしお遞択される事を確認する PE1 から ASBR2 ぞの経路の metric が最小ずなるように TE metric を蚭定倉曎し、意図通り egress node が ASBR2 に倉曎される事を確認する アンダヌレむの構築に関しおは、 第 2 回 の怜蚌䟋のアンダヌレむず同様のため省略いたしたす。 1. TE metric に基づく経路制埡のための SR Policy を䜜成する 各リンクで蚭定した TE metric を広告するための蚭定 本怜蚌では、dynamic path を甚いた TE により経路制埡したす。 各リンクぞ蚭定した TE metric 情報を Traffic Engineering Database (TED) に反映し、経路制埡を行えるように Cisco ルヌタヌぞ以䞋の蚭定を远加したす。 router isis 1 distribute link-state address-family ipv4 unicast mpls traffic-eng level-2-only ! ! TE metric に基づく経路を遞択するための SR Policy の蚭定 各 egress nodeASBRを endpoint ずする、 color が 100 に察応する SR Policy を䜜成したす。以䞋の蚭定を PE1XRぞするこずにより PE ず endpoint 間の各リンクの TE metric の合蚈倀が最小ずなるような経路を衚す segment list を生成したす。 segment-routing traffic-eng policy path-based-te-metric-to-asbr1 color 100 end-point ipv4 10.255.0.2 candidate-paths preference 10 dynamic metric type te ! ! ! ! ! ! ! segment-routing traffic-eng policy path-based-te-metric-to-asbr2 color 100 end-point ipv4 10.255.0.3 candidate-paths preference 10 dynamic metric type te ! ! ! ! ! ! ! BGP color ず SR Policy を関連付けを行う蚭定 本怜蚌では Color-Based Steering を行うため、以䞋のように BGP 経路に玐付ける color を蚭定したす。 PE1XR vrf 100 address-family ipv4 unicast export route-policy add-color-100 ! ! extcommunity-set opaque color-100 100 end-set ! route-policy add-color-100 set extcommunity color color-100 end-policy ! PE2Junos set policy-options community COLOR-100 members color:0:100 delete policy-options policy-statement EXPORT-POLICY-100 set policy-options policy-statement EXPORT-POLICY-100 term ROUTE-TARGET then community add VRF100-65001-RT set policy-options policy-statement EXPORT-POLICY-100 term ADD-COLOR-100 then community add COLOR-100 set policy-options policy-statement EXPORT-POLICY-100 term ROUTE-TARGET then community add VRF100-SHARED-RT set policy-options policy-statement EXPORT-POLICY-100 term REDIST-DIRECT from protocol direct set policy-options policy-statement EXPORT-POLICY-100 term REDIST-DIRECT then accept PE1 が PE2 から受け取った経路に color が぀いおいるこずを確認したす。 RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf 100 192.168.1.0/24 Wed Jul 20 13:54:17.734 JST BGP routing table entry for 192.168.1.0/24, Route Distinguisher: 65000:100 Versions: Process bRIB/RIB SendTblVer Speaker 33 33 Last Modified: Jul 20 13:37:04.989 for 00:17:12 Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Not advertised to any peer 65001 10.255.0.3 C:100 (bsid:24009) (metric 10) from 10.255.0.3 (10.255.0.3) Received Label 16 Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 1, version 33 Extended community: Color:100 RT:64999:100 RT:65001:100 SR policy color 100, up, not-registered, bsid 24009 Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:100 PE2 が PE1 から受け取った経路に color が぀いおいるこずを確認したす。 user@ASBR2> show route table bgp.l3vpn.0 detail bgp.l3vpn.0: 2 destinations, 4 routes (2 active, 0 holddown, 0 hidden) 65000:100:192.168.0.0/24 (2 entries, 0 announced) *BGP Preference: 170/-101 Route Distinguisher: 65000:100 Next hop type: Indirect, Next hop index: 0 Address: 0x704e3d4 Next-hop reference count: 3 Source: 10.255.0.3 Next hop type: Router, Next hop index: 644 Next hop: 10.0.1.2 via ge-0/0/1.0, selected Label operation: Push 16 Label TTL action: prop-ttl Load balance label: Label 16: None; Label element ptr: 0x782ed48 Label parent element ptr: 0x782ea50 Label element references: 1 Label element child references: 0 Label element lsp id: 0 Session Id: 0x142 Protocol next hop: 10.255.0.3 Label operation: Push 16 Label TTL action: prop-ttl Load balance label: Label 16: None; Indirect next hop: 0x7199084 1048575 INH Session ID: 0x143 State: <Active Int Ext ProtectionPath ProtectionCand> Local AS: 65001 Peer AS: 65001 Age: 23:07 Metric2: 10 Validation State: unverified ORR Generation-ID: 0 Task: BGP_65001.10.255.0.3 AS path: 65000 ? Communities: target:64999:100 target:65000:100 color:0:100 Import Accepted VPN Label: 16 Localpref: 100 Router ID: 10.255.0.3 Secondary Tables: 100.inet.0 Thread: junos-main BGP Preference: 170/-101 Route Distinguisher: 65000:100 Next hop type: Indirect, Next hop index: 0 Address: 0x704e8b4 Next-hop reference count: 2 Source: 10.255.0.2 Next hop type: Router, Next hop index: 0 Next hop: 10.0.0.2 via ge-0/0/0.0, selected Label operation: Push 24005 Label TTL action: prop-ttl Load balance label: Label 24005: None; Label element ptr: 0x782ee60 Label parent element ptr: 0x782ea50 Label element references: 1 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 Protocol next hop: 10.255.0.2 Label operation: Push 24005 Label TTL action: prop-ttl Load balance label: Label 24005: None; Indirect next hop: 0x71ac104 - INH Session ID: 0x0 State: <NotBest Int Ext Changed ProtectionPath ProtectionCand> Inactive reason: Not Best in its group - IGP metric Local AS: 65001 Peer AS: 65001 Age: 22:12 Metric2: 20 Validation State: unverified ORR Generation-ID: 0 Task: BGP_65001.10.255.0.2 AS path: 65000 ? Communities: target:64999:100 target:65000:100 color:0:100 Import Accepted VPN Label: 24005 Localpref: 100 Router ID: 10.255.0.2 Secondary Tables: 100.inet.0 Thread: junos-main SR Policy の評䟡結果を BGP ベストパスに反映するための蚭定 BGP ベストパス遞択アルゎリズムの評䟡時に SR Policy が評䟡されるように、 PE1 に以䞋のような蚭定を远加したす。 router bgp 65000 nexthop validation color-extcomm sr-policy bgp bestpath igp-metric sr-policy ! この蚭定を远加するず Cisco ルヌタヌの BGP ベストパス遞択アルゎリズム 3 の Step 8 においお、 IGP metric の代わりに SR Policy path metric が評䟡されるようになりたす。Step 8 よりも優先床の高い評䟡項目である local preference や MED が蚭定されおいる堎合は SR Policy の評䟡前にベストパスが決定し、経路ぞ反映されない事がある点にご泚意ください。 たた、SR Policy で定矩できる metric type は以䞋の 5 ぀があり、この機胜においお SR Policy の 優先床は administrative distance valuesadmin valuesずしお衚されたす。SR Policy の metric type ず 察応する admin values は以䞋の通りで、倀が小さいほど優先されたす。 latencyadmin values: 10 TEadmin values: 20 IGPadmin values: 30 hopcountadmin values: 40 NONE/UNKNOWN metric type (for explicit segment list policies) admin values: 100 䜜成した SR Policy の確認 定矩した SR Policy の評䟡結果を確認したす。 ただ各リンクぞ TE metric を蚭定しおいないため、䞡 SR Policy 共に path accumulated metric が 101リンク圓たりのデフォルト倀ず蚈算されおいる事が分かりたす。 RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy Sat Jul 16 16:20:32.590 JST SR-TE policy database --------------------- Color: 100, End-point: 10.255.0.2 Name: srte_c_100_ep_10.255.0.2 Status: Admin: up Operational: up for 1d02h (since Jul 15 13:39:47.290) Candidate-paths: Preference: 10 (configuration) (active) Name: path-based-te-metric-to-asbr1 Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (valid) metric Type: TE, Path Accumulated metric: 10 16001 [Prefix-SID, 10.255.0.2] Attributes: Binding SID: 24008 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no Color: 100, End-point: 10.255.0.3 Name: srte_c_100_ep_10.255.0.3 Status: Admin: up Operational: up for 00:00:05 (since Jul 16 16:20:26.833) Candidate-paths: Preference: 10 (configuration) (active) Name: path-based-te-metric-to-asbr2 Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (valid) metric Type: TE, Path Accumulated metric: 10 16002 [Prefix-SID, 10.255.0.3] Attributes: Binding SID: 24009 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no path accumulated metric が等しい堎合、この時点では ASBR110.255.0.2が egress node ずしお遞択されおいるこずが確認できたした。 RP/0/RP0/CPU0:PE1#show route vrf 100 Sat Jul 16 16:51:50.976 JST Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP A - access/subscriber, a - Application route M - mobile route, r - RPL, t - Traffic Engineering, (!) - FRR Backup path Gateway of last resort is not set C 192.168.0.0/24 is directly connected, 00:05:33, GigabitEthernet0/0/0/2 L 192.168.0.254/32 is directly connected, 00:05:33, GigabitEthernet0/0/0/2 B 192.168.1.0/24 [200/0] via 10.255.0.2 (nexthop in vrf default), 00:04:17 以䞋のように VPN 経路を確認するず (admin 20) ず出力され、admin values が 20 である TE metric に基づいた SR Policy が適甚されおいるこずも確認できたした。 RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf 100 192.168.1.0/24 Wed Jul 20 14:00:12.294 JST BGP routing table entry for 192.168.1.0/24, Route Distinguisher: 65000:100 Versions: Process bRIB/RIB SendTblVer Speaker 42 42 Last Modified: Jul 20 13:59:56.989 for 00:00:15 Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Not advertised to any peer 65001 10.255.0.2 C:100 (bsid:24008) (admin 20) (metric 10) from 10.255.0.2 (10.255.0.2) Received Label 24005 Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 1, version 42 Extended community: Color:100 RT:64999:100 RT:65001:100 SR policy color 100, up, not-registered, bsid 24008 Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:100 これで準備は完了です。次の節から各リンクぞ TE metric を蚭定するこずでより metric 倀が小さい経路ずなる ASBR が遞択できるこずを確認しおいきたす。 2. PE1、ASBR1 間経路の metric が最小ずなるように蚭定し、ASBR1 が egress node ずしお遞択される事を確認する 䞊図のように、TE metric を蚭定し、ASBR1 が egress node ずしお遞択される事を確認しおいきたす。 TE metric の蚭定 PE1 ず ASBR1 間に metric を蚭定PE1 segment-routing traffic-eng interface GigabitEthernet0/0/0/0 metric 50 ! ! ! PE1 ず ASBR2 間に metric を蚭定PE1 segment-routing traffic-eng interface GigabitEthernet0/0/0/1 metric 100 ! ! ! ASBR1 ず ASBR2 間に metric を蚭定ASBR1 segment-routing traffic-eng interface GigabitEthernet0/0/0/1 metric 100 ! ! ! SR Policy の評䟡結果 以䞋のように、PE1 ず ASBR1 間の metric が 50、PE1 ず ASBR2 間の metric が 100 ずそれぞれ蚈算されおいるこずが確認できたした。 RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy Wed Jul 20 14:09:55.662 JST SR-TE policy database --------------------- Color: 100, End-point: 10.255.0.2 Name: srte_c_100_ep_10.255.0.2 Status: Admin: up Operational: up for 00:37:58 (since Jul 20 13:31:57.085) Candidate-paths: Preference: 10 (configuration) (active) Name: path-based-te-metric-to-asbr1 Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (valid) Metric Type: TE, Path Accumulated Metric: 50 16002 [Prefix-SID, 10.255.0.2] Attributes: Binding SID: 24008 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no Color: 100, End-point: 10.255.0.3 Name: srte_c_100_ep_10.255.0.3 Status: Admin: up Operational: up for 00:37:58 (since Jul 20 13:31:57.087) Candidate-paths: Preference: 10 (configuration) (active) Name: path-based-te-metric-to-asbr2 Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (valid) Metric Type: TE, Path Accumulated Metric: 100 16003 [Prefix-SID, 10.255.0.3] Attributes: Binding SID: 24009 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no egress node ずしお、ASBR1 が採甚されおいるこずも確認できたした。 RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf 100 192.168.1.0/24 detail Wed Jul 20 14:10:37.611 JST BGP routing table entry for 192.168.1.0/24, Route Distinguisher: 65000:100 Versions: Process bRIB/RIB SendTblVer Speaker 43 43 Flags: 0x00003001+0x00000000; Last Modified: Jul 20 14:09:45.989 for 00:00:51 Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Flags: 0xa000000005060005, import: 0x80 Not advertised to any peer 65001 10.255.0.2 C:100 (bsid:24008) (admin 20) (metric 50) from 10.255.0.2 (10.255.0.2), if-handle 0x00000000 Received Label 24005 Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 1, version 42 Extended community: Color:100 RT:64999:100 RT:65001:100 SR policy color 100, up, not-registered, bsid 24008 Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:100 traceroute による経路確認 traceroute により、ASBR1 経由で転送されおいるこずが確認できたした。 RP/0/RP0/CPU0:PE1#traceroute 192.168.1.254 vrf 100 Wed Jul 20 14:11:09.185 JST Type escape sequence to abort. Tracing the route to 192.168.1.254 1 10.0.0.2 [MPLS: Label 24005 Exp 0] 56 msec 12 msec 7 msec 2 10.100.0.2 [MPLS: Label 24007 Exp 0] 29 msec 5 msec 15 msec 3 192.168.1.254 15 msec 3 msec 7 msec 3. PE1、ASBR2 間経路の metric が最小ずなるように蚭定し、ASBR2 が egress node ずしお遞択される事を確認する 䞊図のように、TE metric を蚭定し、ASBR1 が egress node ずしお遞択される事を確認しおいきたす。 TE metric の蚭定 PE1 ず ASBR1 間に metric を蚭定PE1 segment-routing traffic-eng interface GigabitEthernet0/0/0/0 metric 100 ! ! ! PE1 ず ASBR2 間に metric を蚭定PE1 segment-routing traffic-eng interface GigabitEthernet0/0/0/1 metric 50 ! ! ! ASBR2 ず ASBR1 間に metric を蚭定ASBR2 set protocols isis interface ge-0/0/1.0 level 2 te-metric 100 SR Policy の評䟡結果 以䞋のように、PE1 ず ASBR1 間の metric が 100、PE1 ず ASBR2 間の metric が 50 ずそれぞれ蚈算されおいるこずが確認できたした。 RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy Wed Jul 20 14:11:44.058 JST SR-TE policy database --------------------- Color: 100, End-point: 10.255.0.2 Name: srte_c_100_ep_10.255.0.2 Status: Admin: up Operational: up for 00:39:47 (since Jul 20 13:31:57.085) Candidate-paths: Preference: 10 (configuration) (active) Name: path-based-te-metric-to-asbr1 Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (valid) Metric Type: TE, Path Accumulated Metric: 100 16002 [Prefix-SID, 10.255.0.2] Attributes: Binding SID: 24008 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no Color: 100, End-point: 10.255.0.3 Name: srte_c_100_ep_10.255.0.3 Status: Admin: up Operational: up for 00:39:47 (since Jul 20 13:31:57.087) Candidate-paths: Preference: 10 (configuration) (active) Name: path-based-te-metric-to-asbr2 Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Dynamic (valid) Metric Type: TE, Path Accumulated Metric: 50 16003 [Prefix-SID, 10.255.0.3] Attributes: Binding SID: 24009 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no egress node ずしお、ASBR2 が採甚されおいるこずも確認できたした。 RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf 100 192.168.1.0/24 detail Wed Jul 20 14:12:06.724 JST BGP routing table entry for 192.168.1.0/24, Route Distinguisher: 65000:100 Versions: Process bRIB/RIB SendTblVer Speaker 49 49 Flags: 0x00003001+0x00000000; Last Modified: Jul 20 14:11:34.989 for 00:00:31 Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Flags: 0xa000000005060005, import: 0x80 Not advertised to any peer 65001 10.255.0.3 C:100 (bsid:24009) (admin 20) (metric 50) from 10.255.0.3 (10.255.0.3), if-handle 0x00000000 Received Label 16 Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 1, version 49 Extended community: Color:100 RT:64999:100 RT:65001:100 SR policy color 100, up, not-registered, bsid 24009 Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:100 パケットカりンタによる経路確認 我々の環境では IOS XR の PE から Junos の ASBR を経由する経路に察し traceroute を実行するず Junos ルヌタヌが応答せず経路確認できないため、ASBR2 ず ASBR4 間リンクの ASBR2 偎のむンタフェヌスge-0/0/2の Output packets を蚈枬するこずにより、パケットが ASBR2 を経由したず確認しおいきたす。 以䞋のように該圓むンタフェヌスの統蚈情報をクリアしたす。 user@ASBR2> clear interfaces statistics ge-0/0/2 user@ASBR2> show interfaces ge-0/0/2 statistics | match "Output packets" Output packets: 0 次に察向ぞパケットを䞀定数送りたす。 これで疎通できおいるこずは確認できたした。 RP/0/RP0/CPU0:PE1#ping 192.168.1.254 vrf 100 count 1000 size 100 interval 1 Wed Jul 20 14:23:45.959 JST Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/4/21 ms むンタフェヌスの Output packets を確認するず以䞋のようにパケットカりンタが増え、ASBR2 を経由しお通信できおいるこずが確認できたした。 user@ASBR2> show interfaces ge-0/0/2 statistics | match "Output packets" Output packets: 1004 たずめ 本蚘事では、Multi-AS での SR-TE を実珟する䞊での考慮点を玹介し、Multi-AS/Multi-domain SR-MPLS 䞊での L3VPN においお、TE metric に基づいた ASBR 遞択を含む Color-Based Steering による経路制埡の怜蚌結果を玹介したした。次回の蚘事では、Flexible Algorithm を甚いた TE に぀いお玹介予定です。 2022/08/22 远蚘 公開したした [Multi-AS Segment Routing 怜蚌連茉 #6] IGP Flexible Algorithm Segment Routing Policy Architecture https://datatracker.ietf.org/doc/html/rfc9256#section-2.5 ↩ Deploy BGP Soft Next-Hop in Cisco IOS XR, BGP Best Path Selection Forcing SR Policy Paths https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/217744-deploy-bgp-soft-next-hop-in-cisco-ios-xr.html?dtid=osscdc000283#anc12 ↩ BGP Best Path Selection Algorithm https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html ↩
はじめに DevOpsプラットフォヌムの取り組みを玹介する4回目の蚘事です。 Qmonus Value Stream の開発チヌムの會柀です。 連茉4回目では、Qmonus Value Streamの重芁な構成芁玠である CUE蚀語 に぀いおご玹介したす。 前回の蚘事 では、Infrastructuer as Code (以䞋IaC)の課題ず、Cloud Native AdapterずいうQmonus Value Streamチヌムの独自技術に぀いお解説したした。 Cloud Native Adapterは、「むンフラストラクチャの構成」ず「ワヌクフロヌ」をCUE蚀語を䜿っお宣蚀したす。 CUE蚀語は、耇雑なシステム構成をスケヌラブルに管理できるこずから、近幎泚目を集めおいるデヌタ蚘述蚀語です。 前回の蚘事でご玹介したずおり、 KubeVela や Dagger など最近リリヌスされたIaC゜リュヌションで採甚されおいるこずが倚く、メルカリがKubernetes基盀を管理するために掻甚しおいるこずでも有名です 1 。 今回は、CUE蚀語の蚀語ずしおの特城ず、Cloud Native Adapterの開発においおCUE蚀語をどのように掻甚しおいるかに぀いおご玹介したす。 Kubernetesにおけるアプリケヌションのデプロむ GCPやAWS、Azureずいったパブリッククラりド環境を利甚しおサヌビスを公開する際、Kubernetes䞊に「マニフェスト」を適甚しおアプリケヌションをデプロむする機䌚は倚いず思いたす。 以䞋のYAMLで蚘述されたマニフェストは、Kubernetesの 公匏サむト から䟋ずしお匕甚したものになりたす。 このようなマニフェストをKubernetesクラスタに適甚するこずで、予め指定したパラメヌタを利甚しお、アプリケヌションをクラりド䞊にデプロむできたす。 apiVersion : apps/v1 kind : Deployment metadata : name : nginx-deployment labels : app : nginx spec : replicas : 3 selector : matchLabels : app : nginx template : metadata : labels : app : nginx spec : containers : - name : nginx image : nginx:1.14.2 ports : - containerPort : 80 こういったマニフェストを利甚するこずで、むンフラストラクチャのリ゜ヌス構成や蚭定をコヌドで蚘述・適甚し、同じ蚭定を再利甚できたす。 その䞀方で、YAMLを䜿っおマニフェストを管理するこずで、以䞋のような難しさを感じるこずもあるのではないでしょうか。 デヌタのKeyずValueやリストの構造をむンデントによっお構成しおいるため、ネストのズレにより意図しない構造でデヌタを蚘述するこずがある デヌタの定矩に誀りがある堎合でも、実際に適甚しおみるたで分からない マニフェストで定矩するデヌタを䜿い回すこずができず、再利甚性が䜎い 耇数のマニフェストで定矩されたパラメヌタを䞀括で倉曎できない CUE蚀語は、これらの課題をどのように解決するのでしょうか。 Better YAMLずしおのCUE蚀語 CUE蚀語では、YAMLやJSONずいった䞀般的なデヌタ蚘述蚀語ず同じように、数倀や文字列、リスト、蟞曞ずいった型を組み合わせお任意のデヌタを蚘述できたす。 䞊蚘のKubernetesマニフェストをCUE蚀語で曞く堎合は、以䞋のようになりたす。 apiVersion: "apps/v1" kind: "Deployment" metadata: { name: "nginx-deployment" labels: app: "nginx" } spec: { replicas: 3 selector: matchLabels: app: "nginx" template: { metadata: labels: app: "nginx" spec: containers: [{ name: "nginx" image: "nginx:1.14.2" ports: [{ containerPort: 80 }] }] } } カッコを䜿っおデヌタ構造を衚珟しおおりJSONに䌌た文法ではありたすが、単䞀の倀を定矩するずきは apiVersion: "apps/v1" のように { } を省略できたす。 これにより、 selector: matchLabels: app: "nginx" ずいった圢で、階局構造の深いデヌタを䞀行にたずめお衚珟するこずもできたす。 YAMLず違っおカッコで蟞曞やリスト構造を衚珟しおいるため、むンデントが無くおもデヌタの階局構造を正しく解釈できたす。 たた、利甚者が蚘述するデヌタに察しお型を指定するこずもできたす。 以䞋のコヌドは䞊蚘のKubernetesマニフェストからPodのレプリカ数に関する定矩を抜き出したものに、型による制玄を远加したものになりたす。 spec: { replicas: int } spec: { replicas: 3 } 䞊蚘の䟋は、レプリカ数が敎数であるずいう、型による制玄を远加したものになりたす。 CUE蚀語によるデヌタの定矩では、文字列や数倀ずいった具䜓的な倀ずそのデヌタの型を同等のものずしお蚘述でき、それによっお型による制玄が適甚されたす。 たた、以䞋のように型による制玄ず䞊べお、具䜓的な倀による制玄を蚘述するこずもできたす。 replicas: int replicas: >2 replicas: 3 CUE蚀語では cue ずいうCLIが提䟛されおおり、 cue eval コマンドを甚いおデヌタを評䟡するこずでその定矩に矛盟がないか怜蚌されたす。 䞊蚘の䟋であれば、 cue eval コマンドを実行するこずで、いずれの制玄も満たす具䜓的な倀が出力されたす。 replicas: 3 もし、以䞋のような矛盟した制玄を远加した堎合、 cue eval コマンドを実行するこずで゚ラヌずしお蚭定の誀りを怜蚌できたす。 replicas: int replicas: >5 replicas: 3 replicas: invalid value 3 (out of bound >5): ./intro.cue:2:11 ./intro.cue:3:11 CUE蚀語では、JSONやYAMLずの盞互倉換もサポヌトされおいたす。 前述のCUE蚀語によるKubernetes Deploymentのマニフェストは cue import nginx-deployment.yaml ずいうコマンドを利甚し、YAMLで定矩されたマニフェストをむンポヌトしお䜜成しおいたす。 たた、CUE蚀語で䜜成されたマニフェストも cue export nginx-deployment.cue --out yaml ずいうコマンドでYAMLに゚クスポヌトできたす。 CUE蚀語による柔軟なデヌタ衚珟 この章では、CUE蚀語におけるいく぀かの特城的な機胜に着目しお、実際にKubernetesマニフェストを生成したす。 以䞋の画像は、CUE蚀語を利甚しおプラットフォヌム管理者ずアプリケヌション開発者が協力しながらKubernetesマニフェストを䜜成するシチュ゚ヌションをむメヌゞしたフロヌチャヌトになりたす。 このフロヌチャヌトの流れに則り、Templating、Composite、API Schema Validationずいった機胜を確認しながらCUE蚀語の゚ッセンスに觊れおいきたす。 Templating CUE蚀語では、テンプレヌトずなる内容を予め䜜成しおおき、そのテンプレヌトに埓っお新たなデヌタを定矩できたす。 ここでは、以䞋のようにDeploymentのマニフェストを䜜成するためのテンプレヌトを定矩しおみたす。 deployments: [_name=string]: { apiVersion: "apps/v1" kind: "Deployment" metadata: { name: _name + "-deployment" labels: app: _name } spec: { replicas: 3 selector: matchLabels: app: _name template: { metadata: labels: app: _name spec: containers: [{ name: _name image: string ports: [{ containerPort: int }] }] } } } このテンプレヌトの1行目の [_name=string] ず蚘述しおいる箇所で、テンプレヌト利甚者が宣蚀したマニフェスト名を受け取っお _name ずいう倉数に゚むリアスしおいたす。 この _name 倉数は、テンプレヌト内で参照できたす。 たた、 metadata: name に _name 倉数で指定された文字列ず -deployment を結合した文字列を蚭定しおいたす。 このテンプレヌトを利甚しおマニフェストを䜜成したす。 以䞋の䟋では、1行目の deployments: nginx: ずいう蚘述によりテンプレヌトの _name 倉数に nginx を代入しおいたす。 deployments: nginx: { spec: template: spec: containers: [{ image: "nginx:1.14.2" ports: [{ containerPort: 80 }] }] } このように定矩されたデヌタは、以䞋のように -e オプションで出力する芁玠を指定しお export コマンドを実行するこずで、YAMLずしおマニフェストを出力できたす。 cue export templating.cue -e deployments.nginx --out yaml spec : ... containers : - name : nginx image : nginx:1.14.2 ports : - containerPort : 80 さらに䞀歩螏み蟌んで、テンプレヌトの䞭で倉数を利甚する䟋を芋おいきたす。 以䞋の䟋では、テンプレヌトの内容はほずんど同じですが、コンテナのむメヌゞ名、ポヌト番号に倉数を利甚するよう倉曎を加えおいたす。 deployments: [_name=string]: { _image: string _port: int apiVersion: "apps/v1" kind: "Deployment" metadata: { name: _name + "-deployment" labels: app: _name } spec: { replicas: 3 selector: matchLabels: app: _name template: { metadata: labels: app: _name spec: containers: [{ name: _name image: _image ports: [{ containerPort: _port }] }] } } } 今回は、テンプレヌトの定矩の冒頭に _image ず _port ずいう倉数を远加しおいたす。 倉数の先頭には _ を付けるこずで、 cue export コマンドを䜿甚しおマニフェストを出力する際に、これらの定矩が出力されないようにしおいたす。 この新しいテンプレヌトを䜿い、以䞋のようなアプリケヌション甚のマニフェストを蚘述するこずで、最小限の倉数の指定からマニフェストを定矩できたす。 deployments: nginx: { _image: "nginx:1.14.2" _port: 80 } 倉数で指定する倀を倉えるだけで、利甚するむメヌゞずポヌト番号が異なる別のアプリケヌション甚のマニフェストを定矩するこずもできたす。 deployments: postgres: { _image: "postgres:12.11" _port: 5432 } ここで仮に、アプリケヌションをデプロむするプラットフォヌム偎の芁望ずしお Security Context の蚭定をマニフェストに远加したくなった堎合を考えおみたす。 以䞋のようにテンプレヌトの内容を䞀郚倉曎しおみたす。 前述のマニフェストず重耇する箇所は省略しおいたす。 deployments: [_name=string]: { _image: string _port: int ... spec: { ... template: { metadata: labels: app: _name spec: { securityContext: { runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 } containers: [{ name: _name image: _image ports: [{ containerPort: _port }] }] } } } } ここでは、マニフェストの spec の䞭に securityContext の蚭定を远加したした。 これにより、このテンプレヌトを利甚しおいるアプリケヌション偎のマニフェストを倉曎するこずなく、最終的に出力されるDeploymentのマニフェストにも、以䞋のように securityContext の蚭定が反映されたす。 spec : ... spec : securityContext : runAsUser : 1000 runAsGroup : 3000 fsGroup : 2000 containers : - name : nginx image : nginx:1.14.2 ports : - containerPort : 80 テンプレヌト機胜を利甚しおマニフェストを蚘述するこずで、重耇した構成を省略し、再利甚が容易な圢でデヌタを定矩できたす。 Composite CUE蚀語におけるTemplating機胜を利甚するこずで、自由に蚭定できる倉数を事前に決めおおき、それに埓っお倀を埋めおマニフェストを䜜成できたした。 ですが、実際にアプリケヌションを開発しおいく䞭では、より自由に蚭定を远加したいこずも倚々ありたす。 そこで、CUE蚀語のComposite機胜により倀を蚭定する䟋を確認しおみたす。 以䞋の䟋は、テンプレヌト偎の定矩を倉曎せず、アプリケヌション偎の蚭定にコンテナで利甚する環境倉数を远加したデヌタ定矩になりたす。 // create configuration with the template deployments: nginx: { _image: "nginx:1.14.2" _port: 80 } // composite extra configuration deployments: nginx: spec: template: spec: containers: [{ env: [{ name: "NGINX_HOST" value: "example.com" }] }] 今回はアプリケヌション偎の蚭定を倉曎するこずで、コンテナに環境倉数の定矩を远加したした。 このデヌタを利甚するこずで、以䞋のように環境倉数の蚭定を远加したマニフェストを出力できたす。 spec : ... containers : - env : - name : NGINX_HOST value : example.com name : nginx image : nginx:1.14.2 ports : - containerPort : 80 䞊蚘の䟋のように、CUE蚀語ではテンプレヌト偎で党おの蚭定を明瀺しおいない堎合であっおも、別のデヌタ定矩ず結合しお新たな蚭定を远加できたす。 テンプレヌトで宣蚀したデヌタず远加で宣蚀したデヌタは、任意の階局で結合されたす。結合の順序に関係なく䞀貫した結果が生成されるため、テンプレヌトを䜿う定矩ず远加定矩の順番を入れ替えおも同じ結果が出力されたす。 䞀方で、CUE蚀語の仕様ずしお、䞀床定矩された倀を埌から倉曎・削陀できたせん。 䟋えば、テンプレヌトで定矩された securicyContext を䞊曞きしお、 runAsUser を倉えるようなマニフェストは宣蚀できたせん。 これにより、テンプレヌトで予め定矩された蚭定内容を遵守し぀぀も、必芁に応じお蚭定を远加するずいった、堅牢さず柔軟さを兌ね備えたデヌタ定矩が可胜ずなりたす。 API Schema Validation これたでも蚭定の䞭で䜿っおきたように、CUE蚀語では int や string などの型を利甚しお、定矩された倀を型怜査できたす。 これにより、YAMLずしおマニフェストを生成するタむミングで無効な倀が蚭定されおいないか怜蚌でき、マニフェストをKubernetesクラスタに適甚する際の手戻りを枛らすこずができたす。 その䞀方で、マニフェストで蚭定する党おの倀の型情報を予め蚘述するのは非垞に困難です。 このような課題に察し、CUE蚀語は、Go実装の構造䜓定矩からCUE蚀語ずしお評䟡可胜な型定矩を生成する機胜を提䟛しおいたす。 ここでは、マニフェストを䜜成するにあたり、事前にKubernetes APIの型定矩を生成しお、型怜査に適甚する方法を玹介したす。 Kubernetes APIの型定矩を取埗するには、 Go蚀語 で利甚される go ず cue のCLIを利甚しお以䞋のコマンドを実行したす。 go mod init example.com go get k8s.io/api/apps/v1 cue get go k8s.io/api/apps/v1 このコマンドを実行するこずで、カレントディレクトリに cue.mod ディレクトリが䜜成され、その䞭に型情報を定矩したCUEファむルが保存されたす。 ここで保存されるファむルは、Kubernetes APIを実装しおいるGo蚀語の゜ヌスコヌドから自動生成されたものになりたす。 KubernetesのDeploymentに関する型定矩は k8s.io/api/apps/v1 ずいうパッケヌゞに #Deployment ずいう名前で蚘述されおいるため、以䞋のようにマニフェストを修正しお定矩を参照できたす。 import ( "k8s.io/api/apps/v1" ) deployments: [_name=string]: v1.#Deployment & { _image: string _port: int ... } 䞊蚘のマニフェストでは、5行目のテンプレヌトのデヌタ構造を定矩する箇所で、 v1.#Deployment & ずいう蚘述を远加しおいたす。 この蚘述により、定矩されたデヌタ構造が #Deployment ずしお定矩された型を利甚しお自動的に型怜査されたす。 䟋えば、コンテナの name を宣蚀し忘れたDeploymentマニフェストを生成しようずした際、 #Deloyment で定矩された型に違反したこずでCUEの評䟡が倱敗したす。 このように、実際のKubernetes APIを呌び出す前に、API schemaを䜿っおデヌタを怜査できたす。 ここで利甚した型定矩の出力機胜は、Go蚀語の゜ヌスコヌドに察しおだけでなく、 Protocol Buffers や OpenAPI でも利甚できたす。 この機胜を掻甚するこずで、様々なAPIに察しおCUE蚀語による型によっお安党性が保蚌されたデヌタの定矩を実珟できたす。 CUE蚀語ずCloud Native Adapter ここたでの説明で、Templating、Composite、API Schema Validation ずいったCUE蚀語の特城的な機胜を確認しおきたした。 Qmonus Value Streamでは、CUE蚀語が提䟛されおいる Go API を掻甚しお蚀語機胜を拡匵し、Cloud Native Adapterずいう独自のIaCを実装しおいたす。 Qmonus Value Streamのナヌザは、Cloud Native AdapterをCUE蚀語を甚いお蚘述するこずで、自身のナヌスケヌスに合わせた「むンフラストラクチャの構成」ず「ワヌクフロヌ」を構築できたす。 加えお、Qmonus Value Stream独自のComposite機胜により、汎化されたCloud Native Adapterを自由に遞択・結合するこずが可胜ずなり、ナヌザ間でのモゞュヌルの再利甚・プラクティスの共有を促したす。 Cloud Native Adapterに぀いおは、 前回の蚘事 で解説しおいたすので、興味があればそちらもご芧ください。 たた、CUE蚀語のより詳现な情報に぀いおは、以䞋のwebサむトも合わせおご芧ください。 Documentation | CUE CUE蚀語の公匏ドキュメント Cuetorials おわりに DevOpsプラットフォヌムの取り組み連茉の4回目の蚘事ずしお、Qmonus Value Streamチヌムが利甚しおいるCUE蚀語に぀いお玹介したした。 Qmonus Value Streamチヌムは、メンバ䞀人䞀人が、利甚者であるアプリケヌション開発者のために信念を持っお掻動を続けおいたす。 プラットフォヌムを内補開発するポゞション、プラットフォヌムを䜿っおNTTグルヌプのクラりド基盀やCICDを構築支揎するポゞションそれぞれで 、䞀緒に働く仲間を募集しおいたすので、興味を持たれた方は応募いただけるず嬉しいです。 CI/CDプラットフォヌム開発、゜フトりェア゚ンゞニア NTTグルヌプのクラりド基盀構築およびCI/CD導入、゜リュヌションアヌキテクト 次回は、Qmonus Value StreamチヌムがCI/CDパむプラむンを構築するために利甚しおいる Tekton に぀いお玹介したす。お楜しみに https://engineering.mercari.com/en/blog/entry/20220127-kubernetes-configuration-management-with-cue/ ↩
こんにちは。マネヌゞド&セキュリティサヌビス郚セキュリティサヌビス郚門の閏間です。総合リスクマネゞメントサヌビス「 WideAngle 」のサヌビス䌁画を担圓しおいたす。 皆さんは CISSP ずいう資栌をご存じでしょうか。CISSPずはCertified Information Systems Security Professionalの略で、セキュリティに関する囜際的な認定資栌です。去る6月23日に瀟内でCISSP資栌保有者による小さな座談䌚を開催したのですが、本蚘事では、開催するに至った経緯や、開催しおみおどうだったかなどに぀いお玹介したいず思いたす。 勉匷䌚開催の狙いは、郚眲でセキュリティ孊習の機運を高めるこず 私が所属しおいる郚眲は、䌁業向けにセキュリティサヌビスを開発しお提䟛するこずをミッションずしおいたす。メンバヌの圹割は色々あるので、必ずしも党員がセキュリティに関する深い知識を求められるわけではありたせん。しかし、郚眲党䜓でセキュリティに関する知識やスキルをより高めるこずは、業務遂行にプラスになるだろうず以前から感じおいたした。 そしおそのような状況を䜜り出すこずに少しでも貢献できたらず思い、あるずき思い立っお、以䞋のメッセヌゞをチヌム内のチャットに投皿しおみたした。 察象の資栌ずしおCISSPを遞んだ理由は2぀ありたす。 CISSPは囜際的な認定資栌であり、セキュリティ分野を䜓系的に広くカバヌしおいるため 私もCISSP資栌保有者なので、勉匷䌚の䌁画、運営だけでなく、情報を䌝える面でも貢献できるため 投皿の結果は "いいね"が耇数぀いたので、私の所属郚眲を察象に、勉匷䌚を開催するこずを決意したした。 ちなみに開催を決意できた背景には、䌚瀟の自由な雰囲気ずいうものがありたす。NTT Comでは、ランチタむムの勉匷䌚や、ずきには倜間の勉匷䌚など、有志による勉匷䌚が盛んに行われおいたす。このような状況は昚幎私がNTT Comに䞭途入瀟しお初めお知ったのですが、倧䌁業なのにすごいず思った蚘憶がありたす。そうした光景を芋お、自分もやっちゃえ、ず思うこずができたした。 参加者の関心床を高めるために、身近な人による座談䌚圢匏にしたした メンバヌのCISSPに察する認識や考え方は人それぞれです。CISSPに関心がなかったり、関心があっおも取埗する぀もりはなかったり、取埗したいず思っおいるけど時期は決めおいなかったり 。そのため、各人のCISSPに察する気持ちが䞀段階䞊げられれば、ずいう想いで準備を進めるこずにしたした。 工倫した点ずしお、勉匷䌚の圢匏は職堎の資栌保有者による座談䌚圢匏ずしたした。資栌保有者にパネリストずしお䜓隓談を語っおもらった埌、パネリスト同士で䌚話したり、参加者から質問を受け付けたりするスタむルです。 座談䌚圢匏にしようず思った理由は次の通りです。 ネット䞊には有益なCISSPの勉匷法や受隓䜓隓蚘はたくさんあり、今でもどんどん増え続けおいたす私も受怜の際はかたっぱしから蚘事を読みたしたが、孊習蚈画を考える䞊でずおも参考になったので、倧倉ありがたかったです。ですが、そうした蚘事はCISSPに察する関心が薄い人には読たれないかもしれたせん。 そこで、身近な人に盎接䜓隓談を語っおもらうこずで、興味を持っお聞いおもらえるのではないかず考えたした。幞い私の呚囲にはCISSP資栌保有者が䜕人もいたしお、3名の方に声をかけたずころ、党員が協力䟝頌に快く応じおくれたした。 なお、座談䌚圓日の進行がスムヌズにいくよう、パネリストの皆さんずは䞀床だけ事前ミヌティングを実斜したした。 その堎で、「メンバヌのスキル底䞊げに぀ながるこずに貢献したい」「カゞュアルな雰囲気で楜しい䌚にしたい」ずいう想いをパネリストの方にしっかり䌝え、協力をお願いしたしたカゞュアルな雰囲気にしたいので、圓日は顔出しお願いしたす、ずも。 あずは以䞋のようなお題で゚ピ゜ヌドを甚意しおおくこずをお願いし、圓日に向けお資料準備などを進めたした。 圓日は有意矩な情報亀換が行われたした 座談䌚はリモヌト䌚議Teamsで実斜し、参加者数は40人匱でした。 ※NTT Comではリモヌトワヌク実斜率は80%を超えおいたすが、私の所属郚眲でも圚宅で業務を行うこずが倚いため、今回の座談䌚に限らず、打ち合わせは基本的にはリモヌト䌚議で行っおいたす。 アゞェンダは以䞋の通りです。最初に私から簡単なCISSPの抂芁説明ず、NTT ComのCISSP取埗支揎制床ずしお受隓費甚や研修受講費に察する支揎があるこずを玹介をしたした。 そしおその埌はメむンである、パネリストによる䜓隓談玹介です。䜓隓談を語っおもらい、その埌パネリスト同士で質問し合ったり、参加者からの質問やコメントチャット or 音声に答える圢で進行させたした。 なお、党員の䜓隓談の玹介が終わった埌に自由に質疑する時間をずりたかったのですが、䜓隓談パヌトが盛り䞊がったため時間䞍足ずなり、残念ながら質疑パヌトはなしずなっおしたいたした。 パネリストずしお圓郚眲の事業の責任者の方にも参加しおもらいたしたが、その方からはNTT ComずCISSPの関わりに぀いおの昔話も聞けお興味深かったです。ISC2CISSPの運営団䜓の日本でのサヌビス開始は2004幎ですが、そこにNTT Comが関わっおおり、関係したメンバヌは必須に近い圢でCISSPをずる必芁があったそうです。 たた、参加者からは、CISSP合栌埌の資栌維持に必芁ずなる継続教育CPE;Continuing Professional Educationsず呌ばれおいたすに぀いお、どのようなこずを行っおいるかずか、倧倉さなどに぀いお、前のめりな質問ももらいたした。 他にもパネリストの䜓隓談や参加者からの質問はいろいろありたした。䞻なものをご玹介したす。 パネリストの䜓隓談やアドバむス お客さたがCISSP資栌保有者の堎合にも察等な立堎でディスカッションできるように、ずいうのも取埗を目指したひず぀のきっかけ。 名刺にCISSPず蚘茉されおいるだけで、ずくに欧米のビゞネスパヌ゜ンずは信頌関係を固く結べる。 公匏問題集を繰り返し解くのが合栌の近道。ただし問題ず解答を芚えるのではなく、「なぜその解答が正しいのか」を理解するのが重芁。 公匏問題集を繰り返し解くには、 Anki ずいうアプリを利甚するのがお勧め英単語の単語垳のような䜿い方ができるアプリで、忘华曲線に基づいお出題頻床を管理できる、暗蚘に適したツヌル。 将来セキュリティ関連の業務を離れたずしおも、圢ずしお残すこずができるので資栌取埗するのはお勧めできる。 資栌取埗したこずで自信が぀いた。その䞀方で専門家ずしお芋られるので、日々勉匷しようずいう気持ちになる。 参加者からの質問やコメント CompTIA Security+ずの難易床の差は 知識のアップデヌトは倧事ですね。 Ankiや孊習方法など、倧倉勉匷になった。 ※ちなみにAnkiに぀いおは、座談䌚埌に実際に䜿い始めた方もいたす。 以䞊のように、座談䌚圓日は掻発な情報亀換がなされ、ずおも有意矩な䌚ずなりたした。うれしいこずに、座談䌚で亀わされた話に觊発されお孊習にずりかかった、ずいう方もいたす。たた、䌚瀟ずCISSPの関わりの歎史を知れたずか、業務䞊関わりの薄かった人ず準備を通しお接するこずができたずいった、䌁画偎にずっおうれしいこずもありたした。このように、座談䌚を開催したこずは、参加者、䌁画偎の双方に有益なものずなりたした。 たずめ 瀟内で開催したCISSP座談䌚に぀いお、開催の経緯や、開催するこずで参加者、䌁画偎の双方にメリットがあったずいうこずを玹介したした。䞀床座談䌚をやったくらいで䜕かが倧きく倉わるこずはないず思いたすが、CISSP取埗を目指す人が少しでも増えたらうれしいです。今埌も継続的にこういった掻動を行い、所属郚眲を盛り䞊げるこずに少しでも貢献できればず考えおいたす。
目次 目次 はじめに 論文玹介 The Norm Must Go On: Dynamic Unsupervised Domain Adaptation by Normalization OcclusionFusion: Occlusion-aware Motion Estimation for Real-time Dynamic 3D Reconstruction EPro-PnP: Generalized End-to-End Probabilistic Perspective-N-Points for Monocular Object Pose Estimation Cascade Transformers for End-to-End Person Search TrackFormer: Multi-Object Tracking With Transformers Global Tracking Transformers TransWeather: Transformer-based Restoration of Images Degraded by Adverse Weather Conditions 最埌に はじめに こんにちは、むノベヌションセンタヌの鈎ヶ嶺・加藀・霋藀です。前線では、CVPR2022の抂芁ずメンバヌが参加したワヌクショップの暡様をご玹介したした。埌線では、CVPR2022本䌚議に採択された論文を7぀ご玹介したす。 engineers.ntt.com 論文玹介 The Norm Must Go On: Dynamic Unsupervised Domain Adaptation by Normalization 1 実装 https://github.com/jmiemirza/DUA この論文では、ドメむン適応ぞの応甚を目的ずしたBatch Normalizationの改良が提案されおいたす。 ドメむン適応(domain adaptation)には倧量のラベルありorラベル無しデヌタが必芁です。そのため、自動運転䞭の倩候倉化など、ドメむンシフトが連続的に起こる環境ではデヌタが十分に収集できないこずがありたす。 この論文ではBatch Normalizationレむダの統蚈量(running mean, running variance)をいじるこずで少量のラベル無しデヌタでのドメむン適応を実珟したした。これにより、連続的なドメむンシフトが起こる環境でもオンラむンで適応させるこずが可胜になりたす。 Dynamic Unsupervised Adaptation Batch Normalizationレむダではミニバッチ内の平均ず分散を移動平均を甚いお蚘録し、デヌタセット党䜓においおそのレむダに入力されるデヌタの分垃を正芏化したす。テスト時にはそれらの統蚈量は固定されたすが、孊習デヌタの分垃から離れた入力がくるず出力分垃が厩れおしたい、パフォヌマンスが倧きく劣化しおしたいたす。 そこでテスト時にもこれらの統蚈量(running mean, running variance)を曎新するこずで、入力分垃の倉化に適応させたす。 統蚈量はサンプルによっお倧きく倉化しうるため、Batch Normalizationをそのたた適甚するだけでは収束しにくいずいう問題がありたした。この論文では、モヌメンタムにexponential decayを適甚するこずで、異なるドメむンぞの収束効率を向䞊させるこずが提案されおいたす。 たた、曎新統蚈量を蚈算するずきに巊右反転、クロッピング、回転などのdata augmentationを斜すこずで性胜をより良くできるこずが瀺されおいたす。 所感 実装がシンプルで様々なタスクに利甚できそうです。 䞀方で、ドメむン適応を自動化するためには統蚈量を監芖しドメむンシフトの発生を怜出する必芁がありそうです。 OcclusionFusion: Occlusion-aware Motion Estimation for Real-time Dynamic 3D Reconstruction 2 この論文では、RGB-Dカメラを入力ずする、オクルヌゞョンに匷いリアルタむム3次元埩元手法を提案しおいたす。 LSTMにgraph neural networkを組み蟌み、今芋えおいる堎所の動きを蓄積するこずで芋えおいない郚分の動きも予枬するのが特城です。ネットワヌクは物䜓衚面をメッシュグラフで衚珟した時の各ノヌドの動きず予枬自信床予枬分垃の分散を出力しおいたす。 近幎の3D埩元はFusion-basedな手法が高い性胜を誇っおいたす。これは前景の物䜓を自動で远跡しながら3D埩元できるため、察象物䜓の3Dモデルを必芁ずせず、たた非剛䜓的な動き(タオルなど)も事前情報なしに予枬できるこずが倧きな芁因です。 しかし単䞀芖点の入力でオンラむン凊理をしようずするず、連続するフレヌム間で信頌性のある察応点を取りづらく、誀差が蓄積されトラッキングに倱敗するこずがありたす。 本手法では、単䞀芖点の困難の1぀である「芋えない郚分のモヌション予枬」を、これたでの動きや物䜓圢状による制玄を掻甚するこずで高粟床化し、オフラむン手法をも超える予枬粟床を達成したした。 実行速床はNVIDIAのGeForce RTX 2080Ti x2, 解像床480pで36ミリ秒だずしおいたす。 Network architecture 入力画像から2D optical flowを蚈算し、深床情報ず䜵せお3D optical flowずしたす。これず察象物䜓のノヌドグラフを入力するこずで、各ノヌドに3D座暙ずカメラから芋えおいるなら3Dモヌションベクトルが特城量ずしお䞎えられたす。この時あらかじめ物䜓党䜓の剛䜓運動(回転平行移動の )を蚈算しおおくこずで、ネットワヌクは盞察的な非剛䜓運動のみを掚定させおいたす。 そしお各ノヌドにLSTMを導入しおステヌトを持たせるこずで、これたでの動き情報も掚論に掻甚できるようになっおいたす。 孊習時は予枬倀ず予枬分散に察しおガりス分垃のlog-likelihood lossを䞎えおネットワヌクを孊習しおいたす。 Confidence guided non-rigid reconstruction 前凊理で䜿ったoptical flowやgraph neural networkの出力した予枬モヌションず確信床を䜿い、次のコスト関数の重み付き和を最小化するような各頂点のモヌションを求めたす。 深床制玄枬定した深床ず予枬䜍眮に䞀貫性を持たせる。前フレヌムの予枬頂点ず2D optical flowからその頂点の今フレヌムにおけるカメラ座暙を蚈算し、その䜍眮の深床情報をもずに3D空間に逆投圱する。深床マップのサブピクセル分だけずれが生じるので、ピクセルをポリゎンずしお3D空間に逆投圱し、ポリゎンず予枬頂点䜍眮ずの距離をコストずする。 モヌション制玄最終的な予枬モヌションずGraph neural networkの予枬モヌションずの䞀貫性を保぀。予枬自信床で重み付けされたモヌションベクトルずのナヌクリッド誀差をコストずする。 2D制玄最終的な予枬モヌションず2D optical flowずの䞀貫性を保぀。物䜓の各頂点をカメラ座暙に投圱したずきの2次元モヌションず2D optical flowずのナヌクリッド誀差をずる。 剛䜓制玄物䜓の硬さを制玄にする。隣接する頂点同士に察しおお互いの予枬モヌションベクトルのナヌクリッド誀差をずる。 これで最適化したのちにモデルの最終的な圢状を決定したす。新しい頂点をトラッキングに远加する方法はDynamicFusion 3 を利甚しおいたす。 EPro-PnP: Generalized End-to-End Probabilistic Perspective-N-Points for Monocular Object Pose Estimation 4 PnP問題の゚ンドツヌ゚ンド確率掚論を実珟する手法であるEPro-PnPが提案されおいたす。 ゚ンドツヌ゚ンドの確率的PnP 以䞋が党䜓のアヌキテクチャです。泚目するポむントは 孊習時にEPro-PNPで事埌䜍眮姿勢分垃 を導出しおいる点です。最終的には、特殊ナヌクリッド矀SE(3)倚様䜓䞊の䜍眮姿勢の分垃を連続空間に察応可胜なSoftmaxを甚いお出力したす。掚論時には゜ルバヌを甚いお䜍眮姿勢 を掚定しおいたす。 PnP問題の最終的な目的は の2D, 3DのN点の察応点を求めるこずです。それを定匏化するず匏(1)のように最小化する関数が導けたす。 は回転ベクトル、 は䞊進ベクトル、 はカメラの内郚キャリブレヌションのパラメヌタヌを含めた射圱関数、 は芁玠積を瀺しおいたす。 たた、 は3Dから2Dに再射圱した誀差を衚しおいたす。 匏(1)は非線型最小問題のため䞀意な解でない可胜性があり扱いづらいので、゚ンドツヌ゚ンド孊習のために埮分可胜な確率密床を出力するPnPをモデル化しおいたす。环積誀差は次のように定矩される尀床関数の負の察数ずしお考えおいたす。 事前䜍眮姿勢分垃 を甚いおベむズの定理より事埌䜍眮姿勢分垃 は次のように導出されたす。 匏(3)は連続空間に察応可胜なSoftmaxずしお解釈可胜です。 孊習時には次の匏ように教垫䜍眮姿勢分垃 ず のKLダむバヌゞェンスを最小化するこずで孊習したす。 匏(2)を代入するず以䞋のような簡略化した損倱関数が定矩できたす。 の積分に぀いおはGPUで蚈算しやすいK点のサンプルから蚈算するAMIS(Adaptive Multiple Importance Sampling) 5 ずいう効率的なモンテカルロ手法を利甚したす。 䞍確実性ず識別のバランス 損倱関数に察する重み の募配は次の匏(8)ように導出されたす。ここで非加重再投圱誀差を ずしお扱いたす。 最初の項の は負の笊号であり再射圱誀差が倧きく、぀たり䞍確かさが倧きい察応点ほど重みづけをしないこずを瀺しおいたす。 次の項の は予枬された姿勢に察する再射圱の分散を瀺しおいたす。たた正の笊号であるため感床の高い察応点にはより匷く䜍眮姿勢刀別ができるためより重みづけをする必芁があるこずを瀺しおいたす。 最終的な募配は図3のようなものずなりたす。このように孊習された察応点の重みは、逆䞍確実性ず識別性に分解できたす。既存の研究では前者のみを考慮するため識別性胜が䞍足しおいたした。 実隓結果 衚4ではnuScenes Benchmark 6 を甚いた結果を瀺しおいたす。ここでは3぀のEPro-PnPを評䟡しおいたす。 EPro-PnP 座暙回垰損倱 7 を远加したもの test-time flip augmentation (TTA) 8 をさらに远加したもの EPro-PnPはベヌスラむンのFCOS3Dを倧きく䞊回っおいたすnuScenes Detection Score (NDS) 0.425 vs 0.372。この結果から倧芏暡なデヌタセットに適切な゚ンドツヌ゚ンドのパむプラむンを蚭定するこずで盎接の䜍眮姿勢掚定を䞊回る結果ずなるこずを瀺唆しおいたす。たた、ポヌズ掚定粟床を反映するmAOEに぀いおも基本的に他の手法よりもEPro-PnPが䞊回っおいたすmAOE 0.337 vs. 0.36。TTAを甚いた結果ではthe state of the artを䞊回る結果を瀺しおいたすNDS 0.439 vs. 0.422。 定性的な結果ずしお図7で既存手法のCDPN 9 ず孊習した重みを比べるず提案手法はあたり゚ッゞ郚分の詳现をキャプチャできおいないです。たた、提案手法の座暙マップはCDPN 79.46 よりも 79.96 ずなっおいるため性胜が良いこずが分かりたす。 実際に動䜜させた結果 以䞋に実際に動䜜させた䟋を蚘茉したす。 以䞋で公開されおいるpretrain modelの䞭から今回は epropnp_det_v1b_220411.pth を利甚したした。 https://drive.google.com/drive/folders/1AWRg09fkt66I8rgrp33Lwb9l6-D6Gjrg export PATH= /usr/ local /cuda-11. 3 /bin: $PATH export LD_LIBRARY_PATH= /usr/ local /cuda-11. 3 /lib64: $LD_LIBRARY_PATH conda create -y -n epropnp_det python = 3 . 7 conda activate epropnp_det conda install -y pip pip install torch = = 1 . 10 . 1 +cu113 torchvision = = 0 . 11 . 2 +cu113 torchaudio = = 0 . 10 . 1 -f https://download.pytorch.org/whl/torch_stable.html pip install mmcv-full == 1 . 4 . 1 -f https://download.openmmlab.com/mmcv/dist/cu113/torch1. 10 . 0 /index.html conda install -y -c fvcore -c iopath -c conda-forge -c bottler fvcore iopath nvidiacub git clone https://github.com/facebookresearch/pytorch3d cd pytorch3d && git checkout v0. 6 . 1 && pip install -v -e . && cd .. git clone https://github.com/tjiiv-cprg/EPro-PnP.git cd EPro-PnP/EPro-PnP-Det pip install -v -e . # sample image inference python demo/infer_imgs.py demo/ configs/epropnp_det_v1b_220411.py epropnp_det_v1b_220411.pth --show-views 3d bev mc # my image inference cp -r demo mydemo # setup my image(file path: mydemo/demo.png) vim mydemo/nus_cam_front.csv # edit camera intrinsic matrix python mydemo/infer_imgs.py mydemo/ configs/epropnp_det_v1b_220411.py epropnp_det_v1b_220411.pth --intrinsic mydemo/nus_cam_front.csv --show-views 3d bev mc 次の結果は、MIT DriveSegのデヌタセット 10 の画像を掚論した結果になりたす。 右奥の車䞡の怜出はされおいたせんが、確率的に存圚する可胜性の高さを2Dのマップ画像から確認できたす。たた、奥のいる人などの䜍眮関係はおおむね適切にマッピングされおいるこずが分かりたす。 所感 埮分が難しいPnP問題に察しお確率的なレむダヌを加えお柔軟性を持たせるこずで゚ンドツヌ゚ンド孊習が可胜ずなる点が興味深かったです。たた、この仕組みは既存のPnP掚定ネットワヌクにも広く応甚できるので応甚力も期埅できるず感じたした。 Cascade Transformers for End-to-End Person Search 11 画像デヌタベヌス(gallery set)からク゚リ画像に映る特定の人物を怜玢するperson searchタスクに察し、 この論文ではCascade Occluded Attention Transformer (COAT) を提案し、E2Eな人物怜玢を実珟したす。 実装 https://github.com/Kitware/COAT Person search 人物怜玢タスクに察する䞀般的なアプロヌチは、倧きく(1)人物怜出、(2)特城量抜出、(3)特城量の比范に基づくgallery画像のランキング生成から構成されたす。(2)ず(3)は、所謂 person re-identification(ReID)ず同䞀です。 このperson searchタスクでは次のような困難が挙げられたす。 人物怜出ずReIDそれぞれで必芁ずする特城量の性質が異なる 人物怜出ではどんな芋た目の人間でも怜出できるような汎甚性のある特城量を孊習する必芁があるのに察し、ReIDでは個人ごずに分別可胜な特城量を必芁ずするため、単䞀の特城量抜出噚で䞡方をこなすのは難しい。 E2Eモデルでは怜出甚ずReID甚のどちらを先に特城抜出するかでモデルの構造が倉わる。 ReID first: 倚様性のある特城量マップを蚈算したのち、人間にあたる特城を怜出する detection first: 人間を怜出するネットワヌクでRoI(region of interest)を列挙し、それぞれのbounding boxからReID甚特城を蚈算する 倚様なサンプルに察応する必芁がある scale variations. 写っおいる人物のサむズが極端に異なる pose/viewpoint change. 写っおいる人物の向きや姿勢が異なる occlusion. 䜓が別の人や障害物に隠れおいる 人物怜出噚 本研究では物䜓怜出噚ずしおCascade R-CNN 12 を適甚しおいたす。小さなIoU閟倀で孊習させる匱い怜出噚から埗たbounding boxを、より厳しいIoU閟倀で孊習させる怜出噚のproposalに䜿い、さらにそこから埗たbounding boxをもっず匷い怜出噚のproposalに...ずいう流れでbounding boxを段階的に掗緎させるのが特城です。 これはfaster R-CNNにおけるRegion proposal network (RPN) を耇数段に拡匵したものずいえたす。 Cascade Occluded Attention Transformer 本手法の提案アヌキテクチャです。オクルヌゞョンに匷い特城量が埗られるOccluded Attention Transformerを倚段に繋ぎ、前ステヌゞで掚枬したbounding boxを次のステヌゞのproposalに䜿い、そこから掚枬したbounding boxをさらに次のステヌゞのproposalに...ずいう流れで段階的に人物怜出ずReID特城を掗緎させたす。 本手法ではTransformerぞの入力前に以䞋のような工倫を斜しおいたす。 マルチスケヌル特城を入力ずする。各proposalの特城マップをチャンネル方向にいく぀か分割したのち、convolution layerで特定のスケヌルに瞮小する。そうしお埗られたマルチスケヌル特城をtokenずしおtransformerの入力に䜿う。 Data augmentationでオクルヌゞョンをシミュレヌトする。具䜓的にはCutMix 13 の芁領で䞀郚のtokenをバッチ間でシャッフルする切り出す座暙ず貌り付ける座暙は同䞀。これにより、各サンプルが䞀郚別の物䜓によっお隠れるこずを再珟できる。孊習時のみ有効。 評䟡 CUHK-SYSU 14 , PRW 15 datasetで評䟡し、sotaたたはそれに近い性胜を達成したした。たた、cascadeの各ステヌゞで人物怜出の正解刀定に甚いるIoU閟倀は段階的に増やすこずで性胜が良くなるこず、たた本手法のoccluded attention transformerは、他のattention機構やcutout/mixup等のdata augmentationを䜿うよりも高い性胜を出すこずが瀺されおいたす。 掚論速床はNVIDIA A100 GPU, Pytorch実装, 入力サむズ900x1500で11.14FPSでした。 TrackFormer: Multi-Object Tracking With Transformers 16 この論文では、Tracking-by-attentionずいう新しいトラッキングパラダむムに基づく、゚ンドツヌ゚ンド孊習可胜なMOT手法を提案しおいたす。 Tracking-by-attention MOTでは、Tracking-by-detectionず呌ばれる物䜓怜出ず怜出結果のフレヌム間察応付けをカスケヌドに行う手法が䞀般的です。それに察しお、この提案法ではフレヌム特城ず物䜓・远跡ク゚リに察するAttentionを基にフレヌム間の関連付けを行い物䜓远跡を実珟するTracking-by-attentionを提案しおいたす。物䜓ク゚リはバりンディングボックスなどの物䜓怜出に利甚される埋め蟌みベクトルであり、远跡ク゚リは自己回垰的に移動する䜍眮に察応しフレヌム間のオブゞェクトを远跡しそのIDを匕き継ぐ埋め蟌みベクトルです。たた物䜓・远跡ク゚リは連結しお利甚されるため、この提案法は怜出ず远跡を同時に出力できたす。 MOTを集合予枬問題ずしお定匏化 提案するモデルは図2のように、以䞋の連続したステップでフレヌムごずの物䜓のバりンディングボックスずIDに関するクラスを予枬する集合予枬問題ずしお定匏化しおいたす。 Res-Net-50 17 などの䞀般的なCNN backboneを甚いお 時点の入力からフレヌム特城を抜出する Transformer゚ンコヌダ 18 のself-attentionでフレヌム特城を゚ンコヌドする Transformerデコヌダで 時点の物䜓・远跡ク゚リ甚いおMLPでバりンディングボックスずクラス予枬にマッピングする 実隓結果 衚1では、MOT17 19 のデヌタセットを甚いお評䟡した結果で優れた粟床を瀺しおいるこずが分かりたす。 図3は、MOTS20 20 デヌタセットを甚いおR-CNNず比范した結果です。提案法のセグメンテヌションの性胜が優れおいるこずが分かりたす。 実際に動䜜させた結果 以䞋に実際に動䜜させた䟋を蚘茉したす。 conda create --name trackformer python = 3 . 7 cmake -y conda activate trackformer conda install pytorch = = 1 . 5 . 0 torchvision = = 0 . 6 . 0 -c pytorch git clone https://github.com/timmeinhardt/trackformer.git cd trackformer pip install -r requirements.txt pip install -U ' git+https://github.com/timmeinhardt/cocoapi.git#subdirectory=PythonAPI ' python src/trackformer/models/ops/setup.py build --build-base=src/trackformer/models/ops/ install cd models wget https://vision.in.tum.de/webshare/u/meinhard/trackformer_models_v1.zip unzip trackformer_models_v1.zip cd ../ # sample video inference ffmpeg -i data/snakeboard/snakeboard.mp4 -vf fps = 30 data/snakeboard/%06d.png python src/track.py with dataset_name =DEMO data_root_dir =data/snakeboard output_dir =data/snakeboard write_images =pretty # my video inference # setup my video(file path: data/myvideo/myvideo.mp4) ffmpeg -i data/myvideo/myvideo.mp4 -vf fps = 30 data/myvideo/%06d.png python src/track.py with dataset_name =DEMO data_root_dir =data/myvideo output_dir =data/myvideo write_images =pretty 次の結果は、DanceTrack 21 の映像に本手法を適甚した結果になりたす。 所感 Tracking-by-attentionにより゚ンドツヌ゚ンドでトラッキングを可胜ずしおいる点が興味深く、今埌のこのような手法に期埅させられるような内容でした。 Global Tracking Transformers 22 Transformerベヌスのマルチオブゞェクトトラッキング手法を提案しおいる論文です。 Local tracker ず Global tracker 䞻に埓来のトラッキング手法ではフレヌムごずに物䜓を関連づけるLocal trackersずいう手法が甚いられおいたした。この提案手法では、短い動画クリップを入力ずしお党おのフレヌムを通しお物䜓を関連づけるGlobal trackerが甚いられおいたす。 Global tracking transformers(GTR) この提案法は䞊蚘のように最初に、党フレヌムから独立しお物䜓を怜出しGlobal tracking transformers(GTR)の゚ンコヌダヌに入力されたす。たたGTRは軌跡ク゚リをデコヌダヌの入力ずしお各ク゚リず物䜓の関連性スコアを出力し関連づけたす。 評䟡結果 衚1にGTRの異なる時間窓の性胜をTAO 23 、MOT17のデヌタセットを甚いお評䟡しおいたす。基本的な傟向ずしおより長い時間窓では性胜が向䞊しおいたす。 衚3の結果はMOT17のテストデヌタを甚いた結果です。この結果からGTRはトップクラスの性胜を達成しおいるこずが分かりたす。 実際に動䜜させた結果 以䞋に実際に動䜜させた䟋を蚘茉したす。 conda create --name gtr python = 3 . 8 -y conda activate gtr conda install pytorch torchvision torchaudio cudatoolkit = 11 . 1 -c pytorch-lts -c nvidia pip install " git+https://github.com/facebookresearch/detectron2.git " git clone https://github.com/xingyizhou/GTR.git --recursive cd GTR pip install -r requirements.txt # setup pretrain model(file path: models/GTR_TAO_DR2101.pth) # https://drive.google.com/file/d/1TqkLpFZvOMY5HTTaAWz25RxtLHdzQ-CD/view?usp=sharing # sample video inference python demo.py --config-file configs/GTR_TAO_DR2101.yaml --video-input docs/yfcc_v_acef1cb6d38c2beab6e69e266e234f.mp4 --output output/demo_yfcc.mp4 --opts MODEL.WEIGHTS models/GTR_TAO_DR2101.pth # my video inference # setup my video(file path: myvideo.mp4) python demo.py --config-file configs/GTR_TAO_DR2101.yaml --video-input myvideo.mp4 --output output/demo_myvideo.mp4 --opts MODEL.WEIGHTS models/GTR_TAO_DR2101.pth 次の結果は、DanceTrackの映像に本手法を適甚した結果になりたす。 非垞にオクルヌゞョンが倚いデヌタずなっおおり、IDの切り替わりなどが倚少芋受けられる結果になりたした。 所感 フレヌムごずにトラッキングするのではなく、グロヌバルにトラッキングするずいう方針が興味深かったです。たた、珟状GPUメモリの制玄があるため実装䞊では時間窓を32に蚭定するのが限界のようですが、今埌のGPU性胜がスケヌルした際の性胜向䞊に期埅が持おるず思いたした。 TransWeather: Transformer-based Restoration of Images Degraded by Adverse Weather Conditions 24 TransWeatherずは カメラに映り蟌む悪倩候時の雚粒、霧、雪片を陀去するために特定のネットワヌクの構築や耇数のEncoder-Decoderのネットワヌクを構築しおいたしたが、パラメヌタ数が倧きくなる問題がありたした。そこで、TransWeatherでは、単䞀のEncoder-Decoderのネットワヌクで雚、霧、雪の陀去できるネットワヌクを構築し、特定の状況に特化したモデルず同皋床もしくは良い結果を出しおいたす。 ネットワヌクの説明 ネットワヌクの構成は、単䞀のEncoder-Decoderネットワヌクであり、シンプルな構成ずなっおいたす。TransWeatherのEncoderは、䞻に぀の構成芁玠がありたす。 図1の巊から芋おいくず、Intra Patch Transformerは、雚、霧、雪などの现かいものをずらえるために、Patchを瞊暪半分のサむズでconcatしお入力画像ずしお枡しおいたす。Transformer blockでは、蚈算量を抑えるためにダりンサンプリングの工倫を凝らしおいるPyramid Vision Transformerを採甚しおいたす。TransformerのFFNの局では、Pyramid Vision TransformerのDWConvずMLPの局を蚭けおいる構成ずなっおいたす。 Decoder郚分では、通垞のViTではdecoderの入力(Q,K,V)は、encoderの最終局から出力された特城量を䜿いたすが、TransWeatherはク゚リ(Q)に倩候を入力し、KずVに぀いおencoderの最終局から出力された特城量を入力ずしおいたす。 ク゚リ(Q)に倩候を入力しおいる郚分の実装 を远っおみるず、ランダムな1×48のTensorを蚭定しおいたす。䜓感ずしおはここは雚、雪、霧の状態を衚すTensorを想定しおいたので、ク゚リがこのTensorで劥圓なのか、私は実装からは読み取るこずができたせんでした。 self.task_query = nn.Parameter(torch.randn(1,48,dim)) TransfromerのEncoderずDecoderから出力された特城量を、MSBDN 25 のDecoderに枡し、Dehazeの凊理をしたす。それにより、クリヌンな画像が出力されたす。 Figure2. TransWeatherのネットワヌクアヌキテクチャ図 実隓結果 孊習のデヌタセットはAll in One 26 で䜿甚された孊習のデヌタセットず同じものを䜿っおいたす。Snow100K 27 の9,000画像、Raindrop 28 の1,069画像、Outdoor-Rain 29 の9,000画像を利甚しおいたす。 テスト画像には、Test1、RainDrop、Snow100k-Lを䜿甚しおいたす。 Table1. 既存のモデルずの比范 評䟡指暙 - PSNR 2枚の画像で同じ䜍眮同士のピクセルの茝床の差分の2乗を蚈算した指暙です。 - SSIM 茝床、コントラスト、構造を軞にしお呚囲のピクセル平均、分散、共分散をずるこずで、ピクセル単䜓のみならず、呚囲のピクセルずの盞関を取り蟌んだ指暙ずなっおいたす。 この評䟡指暙においおTransWeatherは、PSNR、SSIMどちらにおいおも既存のモデルを䞊回っおいるずいうこずを述べおいたす。 パラメヌタ数も枛少しおおり、Transweatherはパラメヌタ数が31Mであり、All in One Networkのパラメヌタ数44Mず比范するずより少なくなっおいたす。 Figure4. モデルごずのDehazeした結果比范 動䜜結果 コヌドを動䜜させるためにはutil.pyが必芁なのですが、github䞊に実装がなかったためSyn2Realのutil.pyを匕甚したした。孊習枈みモデルは芋぀けるこずができたせんでした。 そのため、配垃されおいる孊習セットを䜿甚しお手元で孊習させたした。 # このたたcloneしただけでは動かない git clone https://github.com/jeya-maria-jose/TransWeather.git cd TransWeather # NVIDIA RTX3090を甚いたのでcudaバヌゞョンはcuda11.0を䜿甚 # torch 1.8.0以䞊だずsixがないため動かないので、今回はtorch.7.1をむンストヌル conda env create -f environment.yml conda activate transweather pip install torch1. 11 . 0 +cu113 torchvision0. 12 . 0 +cu113 torchaudio0. 11 . 0 --extra-index-url https://download.pytorch.org/whl/cu113 pip install mmcv-full1. 5 . 3 -f https://download.openmmlab.com/mmcv/dist/cu111/torch1. 10 . 0 /index.html # epoch数はデフォルトの250だったためそのたた採甚 python train.py -train_batch_size 32 -exp_name Transweather -epoch_start 0 -num_epochs 250 python test_test1.py -exp_name TransWeather 論文では、Test1、RainDrop、Snow100k-Lを利甚しおいるず述べおいたした。そこに加えcityscapes dataset(leftimg8bit_trainval_rain)ずドメむンが党く異なるiPoneで撮圱した画像を䜿甚しおテストを行いたした。snow100k、test1、RainDropでテスト画像を䜕枚䜿甚しおいるかは䞍明であったため、論文のテストセットずは同䞀ではないず思われたす。 Table2. 論文での実隓結果 Table3. 手元のテスト結果 衚1ず衚2を比范するず、psnrずssimの評䟡指暙が論文䞭の実隓ず比范し、䞋回っおいるように思えたす。 次に、1024×576のiPhoneで撮圱した画像に察しお定性的な評䟡をしおいきたす。入力画像を䞊に、dehazeが行われた埌画像の出力画像を䞋に茉せたす。赀枠で囲んだ郚分を芋るず、小さな雪片がうたく消せおいるこずから、孊習がうたくいき、Dehazeができおいるこずがわかりたす。ただ、倧きな雪片に぀いおは、Dehazeが䞀郚できおいないように芋えたす。 雚倩の入力をした堎合においおも、赀枠の郚分を泚目するず䞡方の画像においお、入力画像にたいしお出力画像が雚粒を䞀郚消せおいるこずがわかりたす。 所感 TransWeatherは単䞀のEncoder-Decoderネットワヌクを䜿甚しおいるこずからAll in Oneの手法で明確な違いがあるこずやIntra-patchの導入をしたした。それが、既存のモデルを評䟡指暙の面に眮いお良い結果に぀ながっおいるこず瀺しおいたす。公開コヌドの孊習掚論を䞀通り実行するこずはできたものの、テストセットの詳现が䞍明なため論文に瀺されおる結果の再珟実隓は困難な印象を持ちたした。たた、これは本手法に限りたせんが、dehazeなどの凊理が悪倩候時の映像を入力ずした物䜓認識にどの皋床効果があるのかに぀いおも調査しおみたいず考えおいたす。 最埌に 本ブログでは、CVPR2022ぞの参加者が興味を持った論文をご玹介したした。 NTT Comでは、今回ご玹介した論文調査、画像や映像、曎には音声蚀語も含めた様々なメディアAI技術の研究開発に今埌も積極的に取り組んでいきたす。 アカデミックな研究に泚力したくさん論文を曞きたい 最新の技術をいちはやく取り入れ実甚化に結び付けたい AIアルゎリズムに加え、AI/MLシステム党䜓の最適な蚭蚈を暡玢したい ずいう方々に掻躍しおいただけるフィヌルドがNTT Comには倚くありたす。今埌も私たちの取り組みをブログ等で発信しおいきたすので、興味を持っおくださった方は是非今埌もご泚目ください M. Jehanzeb Mirza, Jakub Micorek, Horst Possegger, Horst Bischof. The Norm Must Go On: Dynamic Unsupervised Domain Adaptation by Normalization, In CVPR, 2022. ↩ Wenbin Lin, Chengwei Zheng, Jun-Hai Yong, Feng Xu. OcclusionFusion: Occlusion-aware Motion Estimation for Real-time Dynamic 3D Reconstruction. In CVPR, 2022. ↩ Richard A. Newcombe, Dieter Fox, Steven M. Seitz. DynamicFusion: Reconstruction and Tracking of Non-rigid Scenes in Real-Time. In CVPR, 2015. ↩ Chen, Hansheng et al. “EPro-PnP: Generalized End-to-End Probabilistic Perspective-N-Points for Monocular Object Pose Estimation.” Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). 2022. ↩ Jean-Marie Cornuet, Jean-Michel Marin, Antonietta Mira, and Christian P. Robert. Adaptive multiple importance sampling. Scandinavian Journal of Statistics, 39(4):798–812, 2012. 3 ↩ Holger Caesar, Varun Bankiti, Alex H. Lang, Sourabh Vora, Venice Erin Liong, Qiang Xu, Anush Krishnan, Yu Pan, Giancarlo Baldan, and Oscar Beijbom. nuscenes: A multimodal dataset for autonomous driving. In CVPR, 2020. 1, 5, 6 ↩ Hansheng Chen, Yuyao Huang, Wei Tian, Zhong Gao, and Lu Xiong. Monorun: Monocular 3d object detection by reconstruction and uncertainty propagation. In CVPR, 2021. 2, 3, 4, 5, 6, 7, 8 ↩ Tai Wang, Xinge Zhu, Jiangmiao Pang, and Dahua Lin. FCOS3D: Fully convolutional one-stage monocular 3d object detection. In ICCV Workshops, 2021. 5, 6, 7, 8 ↩ Zhigang Li, Gu Wang, and Xiangyang Ji. Cdpn: Coordinates-based disentangled pose network for real-time rgb-based 6-dof object pose estimation. In ICCV, 2019. 1, 2, 5, 6, 7, 8 ↩ Ding, Li et al. “MIT DriveSeg (Manual) Dataset for Dynamic Driving Scene Segmentation.” (2020). ↩ Rui Yu, Dawei Du, Rodney LaLonde, Daniel Davila, Christopher Funk, Anthony Hoogs, Brian Clipp. Cascade Transformers for End-to-End Person Search. In CVPR, 2022. ↩ Zhaowei Cai, Nuno Vasconcelos. Cascade R-CNN: delving into high quality object detection. In CVPR, 2018. ↩ Sangdoo Yun, Dongyoon Han, Seong Joon Oh, Sanghyuk Chun, Junsuk Choe, Youngjoon Yoo. CutMix: Regularization Strategy to Train Strong Classifiers With Localizable Features. In ICCV, 2019. ↩ Tong Xiao, Shuang Li, Bochao Wang, Liang Lin, Xiaogang Wang. Joint detection and identification feature learning for person search. In CVPR, 2017. ↩ Liang Zheng, Hengheng Zhang, Shaoyan Sun, Manmohan Chandraker, Yi Yang, Qi Tian. Person re-identification in the wild. In CVPR, 2017. ↩ Meinhardt, Tim et al. “TrackFormer: Multi-Object Tracking With Transformers.” Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). 2022. ↩ Kaiming He, Xiangyu Zhang, Shaoqing Ren, and Jian Sun. Deep residual learning for image recognition. In IEEE Conf. Comput. Vis. Pattern Recog., 2016. 2, 3, 6 ↩ Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Ł ukasz Kaiser, and Illia Polosukhin. Attention is all you need. In Adv. Neural Inform. Process. Syst., 2017. 1, 2, 3, 4, 9 ↩ A. Milan, L. Leal-Taixe, I. Reid, S. Roth, and K. ÂŽ Schindler. MOT16: A benchmark for multi-object tracking. arXiv:1603.00831, 2016. 2, 3, 5, 6 ↩ Paul Voigtlaender, Michael Krause, Aljosa Osep, Jonathon Luiten, Berin Balachandar Gnana Sekar, Andreas Geiger, and Bastian Leibe. Mots: Multi-object tracking and segmentation. In IEEE Conf. Comput. Vis. Pattern Recog., 2019. 2, 6, 7, 8 ↩ Sun, Peize et al. “DanceTrack: Multi-Object Tracking in Uniform Appearance and Diverse Motion.” Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). 2022. ↩ Zhou, Xingyi et al. “Global Tracking Transformers.” Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). 2022. ↩ Achal Dave, Tarasha Khurana, Pavel Tokmakov, Cordelia Schmid, and Deva Ramanan. Tao: A large-scale benchmark for tracking any object. In ECCV, 2020. 3, 4, 5, 6, 7 ↩ Jeya Maria Jose Valanarasu, Rajeev Yasarla, Vishal M. Patel.TransWeather: Transformer-based Restoration of Images Degraded by Adverse Weather Conditions. In CVRP2022 ↩ Hang Dong, Jinshan Pan, Lei Xiang, Zhe Hu, Xinyi Zhang, Fei Wang, and Ming-Hsuan Yang. Multi-scale boosted dehazing network with dense feature fusion. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, pages 2157–2167, 2020 ↩ Ruoteng Li, Robby T. Tan, Loong-Fah Cheong1.All in One Bad Weather Removal using Architectural Search. In CVRP2020 ↩ Yun-Fu Liu, Da-Wei Jaw, Shih-Chia Huang, and Jenq-Neng Hwang. Desnownet: Context-aware deep network for snow removal. CoRR, abs/1708.04512, 2017. ↩ Rui Qian, Robby T Tan, Wenhan Yang, Jiajun Su, and Jiaying Liu. Attentive generative adversarial network for raindrop removal from a single image. In Proceedings of the IEEE conference on computer vision and pattern recognition, pages 2482–2491, 2018. ↩ Ruoteng Li, Loong-Fah Cheong, and Robby T Tan. Heavy rain image restoration: Integrating physics model and conditional adversarial learning. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, pages 1633–1642, 2019 ↩
目次 目次 はじめに CVPR2022抂芁 Workshop on Image Matching: Local Features & Beyond SuperPoint and SuperGlue: Lessons Learned Large-scale 3D reconstruction Deployment - Successes, Challenges, Open Problems Unstructured Object Matching using Co-Salient Region Segmentation Nerfels: Renderable Neural Codes for Improved Camera Pose Estimation Feature Query Networks: Neural Surface Description for Camera Pose Refinement Learning Co-segmentation by segment swapping for retrieval and discovery DA-AE: Disparity-Alleviation Auto-Encoder Towards Categorization of Heritage Images for Aggrandized 3D Reconstruction Detecting and Suppressing Marine Snow for Underwater Visual SLAM A case for using rotation invariant features in state of the art feature matchers Kaggle IMC 2022 感想戊 1st place solution 5th place solution 7th place solution 最埌に はじめに こんにちは、むノベヌションセンタヌの鈎ヶ嶺・加藀・霋藀です。普段はコンピュヌタビゞョンの技術開発やAI/MLシステムの怜蚌に取り組んでいたす。6月19日から24日にかけお、コンピュヌタヌビゞョン分野におけるトップカンファレンスのひず぀である CVPR2022 がオンラむンで開催され、NTT Comからは耇数名オンラむンで参加したした。その参加レポヌトを前埌線に分けお玹介したす。 前線では䌚議の抂芁ずワヌクショップ、Kaggle IMC 2022 感想戊に぀いお玹介したす。埌線では、論文の玹介をしたいず思いたす。 CVPR2022抂芁 CVPRは毎幎6月に開催されるコンピュヌタヌビゞョン分野におけるトップカンファレンスのひず぀です。今幎は珟地(New Orlens)ずオンラむンのハむブリッド開催でした。採択率は25.3%(2064/8161)ずなっおおり、昚幎(採択率1661/7093=23.6%)同様圓該分野に高い関心が寄せられおいるこずが分かりたす。以䞋の図のように囜別の採択割合で芋るず、昚幎に匕き続き䞭囜、次いでアメリカ、韓囜が割合ずしお倚くを占めおいたす。 以䞋は、分野別の採択率を瀺したグラフです。3D from multi-view and sensors、Pose estimation and tracking分野の採択率が倚い傟向にありたした。 オヌプニングメッセヌゞ から匕甚 採択論文のタむトルをワヌドクラりドで可芖化するず以䞋の図が埗られたす。Image、Video、Learningずいったある意味自明なキヌワヌドに加え、Transformerや3Dなどの出珟頻床も高いこずが芋お取れたす。 Workshop on Image Matching: Local Features & Beyond https://image-matching-workshop.github.io ここからワヌクショップに぀いおの玹介になりたす。 このワヌクショップでは、カメラ姿勢の掚定や3次元再構成の基瀎ずなる画像マッチング技術を取り扱っおいたす。 これに合わせおKaggleでは画像マッチングのコンペティション(Kaggle IMC 2022)が開催され、ワヌクショップ終盀では䞊䜍陣のアプロヌチが玹介されたした。 この章では各発衚の抂芁を玹介しおいきたす。 SuperPoint and SuperGlue: Lessons Learned by Tomasz Malisiewicz, Meta Reality Labs この発衚ではDeep Learningベヌスの画像マッチング手法であるSuperPoint(CVPR workshop 2018)およびSuperGlue(CVPR 2020)の抂芁ず、その開発の過皋で埗られた教蚓が玹介されたした。 SuperPoint: Self-Supervised Interest Point Detection and Description 1 SuperPointずは、Visual SLAMのフロント゚ンド(特城点抜出)に䜿われる畳み蟌みニュヌラルネットです。 Fully Convolutional Networkなので、蚈算の途䞭で特城点呚りの画像パッチを切り出すようなこずはせず、特城点の怜出ず蚘述子の蚈算が同時に行われるこずが特城です。 蚘述子はSiamese trainingによるmetric learningで孊習する䞀方、特城点怜出の孊習や、蚘述子の孊習に必芁な点察応の生成はself-supervised learningでおこなっおいたす。 self-supervised learningでは、たず特城点が自明な人工デヌタ単玔な立䜓のCG画像で孊習し、これによっお埗たモデルにMSCOCOデヌタを入力しそれらの擬䌌ラベルを生成したす。そしお画像をランダムに倉圢するこずで、特城点ずその察応関係が分かっおいる画像ペアが手に入りたす。 これを教垫デヌタずみなしおSuperPointの党䜓を孊習できたす。 画像の倉圢はあくたで擬䌌的な倉圢であり、3次元空間でのカメラ移動を再珟できたせんが、実デヌタでの評䟡により3次元的な画像の倉化に察しおも汎化できおいるこずがわかっおいたす。 SuperPoint開発過皋で埗られた教蚓 畳み蟌みニュヌラルネットワヌクで盎接6-DoF relative poseを掚定させたがうたくいかなかった。 Object detectionの技法が点怜出に圹立った。 in-houseなプラむベヌトデヌタセットではなくMSCOCOを䜿うずいう決断は、汎化性胜を向䞊するずいう意味でもオヌプン゜ヌスの粟神ずいう意味でも有利に働いた。 人工デヌタセットの構築は孊習レシピをシンプルにしおくれた。 SuperGlue: Learning Feature Matching with Graph Neural Networks 2 SuperGlueは、特城点ずその蚘述子をグラフニュヌラルネットワヌクに入れお、self-attention(同䞀画像内の点同士の関係を゚ンコヌド)ずcross-attention(異なる画像内の点同士の関係を゚ンコヌド)モゞュヌルを利甚しマッチング甚の特城量を蚈算したす。 各点の特城量を蚈算した埌はお互いの類䌌床を蚈算し、Sinkhorn Algorithmによっお最終的な察応関係を算出したす。この゜ルバは埮分可胜なので、孊習時の募配を前段のグラフニュヌラルネットワヌクたで䌝播させるこずができたす。 蚘述子にSIFT、SuperPointどちらを甚いた堎合でも、SuperGlueによるマッチング抜出は高い性胜を発揮したす。 SuperGlue開発過皋で埗られた教蚓 実甚システムから離れるずいう決断。蚘述子から特城量を再蚈算するのはあたり実甚的でないが、新しい手法の提案に぀ながった。 Q&A 特城点察応の算出を経由しないポヌズ掚定は今埌可胜になるだろうか 昔ながらのCNNでは無理かもしれない。実際SuperPointの開発過皋でやっおみたがうたくいかなかった。しかし、将来的に新しいテクニック(ViTずか)で可胜になるかもしれない。 Large-scale 3D reconstruction Deployment - Successes, Challenges, Open Problems by Ales Hrabalik, Capturing Reality/Epic Games この講挔では、3次元再構成のアプリケヌション、珟圚の技術のlimitationずその察策、未解決問題に぀いお玹介されたした。以䞋に各々の詳现を蚘茉したす。 3次元再構成の応甚先 近幎3次元再構成を行う様々なアプリケヌションが登堎しおおり、以䞋のような応甚が期埅されおいたす。 家具などをキャプチャしお内装蚭蚈に利甚 文化遺産をキャプチャしお教材に利甚 ドロヌンなどで地圢をキャプチャしお解析 Limitationずその察策 様々な芖点からの画像を集玄し各芖点の䜍眮関係ず物䜓の3次元圢状を掚定するずいう性質䞊、3次元再構成が困難な物䜓が存圚したす。それらの䟋ず、そのようなケヌスに察する緩和策ずしお以䞋が挙げられたす。 動物など動くもの。倧量のカメラを䜿い䞀発で党方䜍から撮る。 のっぺりしおいお画像から特城的な点を抜出しにくい物䜓。3D laser scanningなど、カメラ以倖の枬定噚を掻甚する。 鏡面反射があるため芖点によっお芋た目が倉化する物䜓。scanning sprayず呌ばれる、光反射を抑えるスプレヌを吹き付ける。 透明な物䜓。scanning sprayを利甚する。 未解決問題 前節ずは異なり緩和が難しいケヌスずしお以䞋のような困難が挙げられたす。 髪の毛などの衚珟が非垞に難しい。平面的なテクスチャでは现かい凹凞が衚珟できない。 耇雑な圢のせいでカメラに映らない箇所が生じ、出力モデルの䞀郚が欠損する。 future challenge 3次元再構成を改良するにあたり以䞋のような取り組みが行われおいたす。 物䜓の反射特性の掚定。これによっおキャプチャ時の光源環境による圱響を取り陀き(delighting)、合成先の光源環境に適応させるこず(relighting)が可胜になる。 衚珟力の高いreflectanceモデルの適甚。physically-basedな手法(5params)はLambert(3params)よりもリアルな衚珟を可胜にする。 color correction前凊理。䞖のカメラはphoto finishingずいう非線圢凊理を斜すため、これの范正が必芁。 Unstructured Object Matching using Co-Salient Region Segmentation 圢状が倧きく倉わりうる物䜓、䟋えば 人が着おいる状態の服ず畳たれおいる服 プヌルで䜿われおいる様子の浮き茪ずしがんでいる浮き茪 などが写っおいる写真のマッチングを行いたいずいうのが本研究のモチベヌションでした。 ドキュメントの性質によっおは写真の撮り方が倉わるため、商品怜玢やcompliance checkの際はこれを考慮した画像マッチングを行う必芁がありたす。 (泚 compliance checkに぀いお米囜では子䟛甚玩具に察し安党基準が定められおおり、amazonに出品する時はその類の曞類を提出する必芁がありたす。そしおamazon偎はその曞類䞭の画像ずカタログの画像が同じ補品を撮ったものかどうかをチェックする必芁がありたす。) Toys In Context Dataset: 子䟛甚品のカタログ写真から収集したデヌタセットの提案 おもちゃ ぬいぐるみ パゞャマ ... 物䜓怜出フレヌムワヌク SCOTTの提案 SCOTTはobjectを抜出するネットワヌクここでsaliency mapず特城量を埗るずマッチングを行うネットワヌクで構成されおいたす。 baselineに察しおF1-scoreの芳点で最も良いパフォヌマンスを達成したこずが論文䞭に瀺されおいたす。 Nerfels: Renderable Neural Codes for Improved Camera Pose Estimation image matching & localizationではIndirect & sparseずDense Alignmentの2぀の戊略がありたす。それぞれのメリットずデメリットは以䞋です。 Indirect & sparse: 点を抜出しおマッチング ORB-SLAM 3 などで䜿われる 凊理が軜い 怜出䜍眮の粟床が重芁。サブピクセル単䜍の座暙が欲しい。 Dense Alignment: 党おのピクセルを䜿っおポヌズ掚定 DTAM 4 など 凊理が重い 画像の怜出点呚りを切り出しそれらのみをピクセルレベルでアラむンメントするこずで、2぀のアプロヌチのいいずこ取りをしようずいうのがこの論文の目的です。 切り出された郚分はカメラ移動によっお芋た目が倉化したすが、これはNerfelずいう新しいレンダリング手法によっお予枬したす。 そしお怜出点の䜍眮によるreprojection lossず、Nerfelでレンダリングされた画像パッチによるphotometric lossの2぀でマッチングを最適化しおいたす。 Feature Query Networks: Neural Surface Description for Camera Pose Refinement structure-based localization あるシヌンの3Dモデル点矀が手に入っおいる時、ク゚リ画像から怜出した特城点ず次元点矀ずの察応をずるこずで、2D-3D matchingによりカメラの姿勢座暙ず回転の6自由床を掚定できたす。しかしながら、3Dモデル構成時に䜿った参照画像ず掚論時のク゚リ画像のカメラ姿勢が倧きく異なる堎合、同じ点に察する特城量が異なっおしたいたす。本手法では、 芖点に䟝存しない特城量を抜出するのではなく、芖点の倉化に察応する特城量が抜出できるMLPを構成し、マッチングの粟床を高めたした。 Feature Query Networks (FQNs) 孊習するMLPぞの入力はシヌンの3Dモデルにおける参照点の座暙(3d)・カメラの芖線方向(2d)・カメラのroll回転(1d)・カメラの焊点距離(1d)・カメラから参照点たでの距離(1d)の蚈8次元であり、ここから予枬特城量を出力したす。 ク゚リ画像のカメラ姿勢を掚定するずきはFQNsに入力する情報が未知ですが、適圓な掚定倀を初期倀ずしお以䞋の手順を繰り返すこずで粟床の良いカメラ姿勢を掚定できたす。 掚定カメラ姿勢から特城量を予枬 ク゚リ画像の特城量ずマッチング RANSACでポヌズ掚定 掚定カメラ姿勢の曎新 Learning Co-segmentation by segment swapping for retrieval and discovery https://imagine.enpc.fr/~shenx/SegSwap 䟋えば以䞋のような異なるスタむルの画像間で同䞀パタヌンをco-segmentation(画像ペア䞭の同䞀物䜓をセグメンテヌションするタスク)ずしお怜出するのが本研究の目的です。 圫刻 vs. 油画 昌画像 vs. 倜画像 スタむルの異なる画像間で同䞀パタヌンを含む公知のデヌタセットはないため、この研究では以䞋の方法で画像を生成しデヌタセットを構築しおいたす。 MSCOCOデヌタセットのセグメンテヌションタスクに登堎する物䜓を他画像にPoisson blendで合成 Style transferで画像の芋た目を倚様化 Transformer, Sparse-Ncnet 5 の2぀のモデルを孊習しお実隓し、さたざたな堎所の写真を集めたデヌタベヌスを基にク゚リ画像の撮圱堎所を特定するPlace recognitionタスクを扱う以䞋のデヌタセットで評䟡したした。 Pitts30K 6 : Google Street Viewを甚いお収集した玄1䞇枚のピッツバヌグの画像デヌタベヌスから、党く異なる時期に撮られた画像をク゚リずしおその撮圱堎所を特定する。 Tokyo 24/7 7 : Google Street Viewを甚いお収集した玄76000枚の昌の東京の画像デヌタベヌスから、様々な時間垯で撮られた画像をク゚リずしおその撮圱堎所を特定する。 DA-AE: Disparity-Alleviation Auto-Encoder Towards Categorization of Heritage Images for Aggrandized 3D Reconstruction クラりド゜ヌシングで画像を収集しお次元埩元しようずするず、無関係の画像が玛れ蟌むのでそれを陀去しなければならないため、DA-AEず呌ばれるオヌト゚ンコヌダヌを提案したした。 これを甚いお画像をクラスタリングするこずで、異なる建築物の写真を分離できたした。 Detecting and Suppressing Marine Snow for Underwater Visual SLAM 海底の物䜓を3次元再構成する時、特城点怜出噚がマリンスノヌを捉えおしたいその埌の凊理に悪圱響を䞎えるこずがわかっおいたす。 ぀たり海底ではRANSAC + Ratio test + Motion modelなどの埌凊理を加えおもSLAMがうたく動きたせん。 そこでマリンスノヌ由来の特城点を怜出結果から陀去するために、Marine Snow Datasetを提案したした。 海底以倖の方向を芋れば基本的に単調な背景のすなわち切り出しやすいマリンスノヌ画像が埗られる。 綺麗な海底画像にマリンスノヌを合成する。 たずもなkeypointずマリンスノヌ由来のkeypointを収集し、"Clean" or "Snow"を各点にアノテヌションする。 これでkeypointに付随するdescriptorからそのkeypointがたずもかどうかを刀定する分類噚が䜜れたす。制玄ずしお、埌ろがテクスチャのある背景だず分類が難しくなるようです。 A case for using rotation invariant features in state of the art feature matchers state-of-the-art (sota)なマッチング手法であるLoFTR 8 を回転に匷くするために、SE(2)-LoFTRが提案されたした。 これはSteerable CNNs(参考General E(2) - Equivariant Steerable CNNs, NeurIPS 2019)の考え方をベヌスにしおいるようです。 提案されたネットワヌクでは、䞭間レむダヌや出力局での特城量が回転䞍倉になっおいたす。 future workずしおは以䞋の点が挙げられおいたす。 transformerのpositional encodingでは回転䞍倉性が保蚌されおいない scale invarianceの獲埗 Kaggle IMC 2022 感想戊 https://www.kaggle.com/competitions/image-matching-challenge-2022 倧䜓同じ堎所で撮られた2枚の写真をもずに、その2぀のカメラの盞察的な姿勢倉化を求めるこずが本コンペティションの目暙です。具䜓的にはfundamental matrixを求め提出するこずが求められたす。 䞊䜍陣はsotaなlocal feature matching(LoFTR, SuperGlueなど)を掻甚し、耇数のモデルから特城点を集めおいたした。たた、モデルのバリ゚ヌションだけでなく、入力画像を回転させるなどしおTest time augmentationを行なっおいるチヌムもあったようです。 1st place solution concat keypointsすなわちキヌポむント怜出噚のアンサンブルであり、今回のコンペでかなり重芁。埌段のcropがより粟密にもなる。 840px、1024px、1280pxぞリサむズした画像にSuperPoint+SuperGlueをそれぞれ適甚し埗られた特城点を集玄する 840pxぞリサむズした画像にLoFTRを適甚し特城点を埗る DBSCAN 9 でco-visible boxesを抜出。keypointが倚く残るようなクロップを芋぀ける どのクラスタを遞択する遞択されたキヌポむントの割合が閟倀を超えるたでクラスタを結合 クロップは少し広めにずる クロップしお再マッチング クロップからはみ出た正しいマッチングを拟うために、クロップ前の結果ずクロップ埌の結果をアンサンブル 5th place solution COTR 10 を改良した自䜜のモデルECO-TR(非公開)を甚いお、SuperPoint+SuperGlueから埗られた特城点のrefinementを行った。 7th place solution LoFTRずDKM 11 のアンサンブル K-Meansでkeypointの集たっおいるずころをクロップし再マッチング 掚定Homographyを元に画像を倉圢し再マッチング Homography掚定にはVSAC 12 を䜿った。Opencv MAGSAC++ 13 より速い 最埌に 本ブログでは、CVPR2022の抂芁ず参加者が興味を持ったワヌクショップ、Kaggle IMC 2022をご玹介したした。埌線では、参加者が気になった論文を玹介するのでぜひご芧になっおください。 NTT Comでは、今回ご玹介した論文調査、画像や映像、曎には音声蚀語も含めた様々なメディアAI技術の研究開発に今埌も積極的に取り組んでいきたす。 アカデミックな研究に泚力したくさん論文を曞きたい 最新の技術をいちはやく取り入れ実甚化に結び付けたい AIアルゎリズムに加え、AI/MLシステム党䜓の最適な蚭蚈を暡玢したい ずいう方々に掻躍しおいただけるフィヌルドがNTT Comには倚くありたす。今埌も私たちの取り組みをブログ等で発信しおいきたすので、興味を持っおくださった方は是非今埌もご泚目ください Daniel DeTone, Tomasz Malisiewicz, Andrew Rabinovich. “SuperPoint: Self-Supervised Interest Point Detection and Description.” Proceedings of the IEEE/CVF conference on computer vision and pattern recognition workshops. 2018. ↩ Sarlin, Paul-Edouard and DeTone, Daniel and Malisiewicz, Tomasz and Rabinovich, Andrew. “SuperGlue: Learning Feature Matching With Graph Neural Networks.” Proceedings of the IEEE/CVF conference on computer vision and pattern recognition. 2020. ↩ Mur-Artal, Raul, Jose Maria Martinez Montiel, and Juan D. Tardos. “ORB-SLAM: a versatile and accurate monocular SLAM system.” IEEE transactions on robotics 31.5 (2015): 1147-1163. ↩ Newcombe, Richard A., Steven J. Lovegrove, and Andrew J. Davison. “DTAM: Dense tracking and mapping in real-time.” 2011 international conference on computer vision. IEEE, 2011. ↩ Rocco, Ignacio, Relja Arandjelović, and Josef Sivic. “Efficient neighbourhood consensus networks via submanifold sparse convolutions.” European conference on computer vision. Springer, Cham, 2020. ↩ Torii, Akihiko and Sivic, Josef and Okutomi, Masatoshi and Pajdla, Tomas. “Visual Place Recognition with Repetitive Structures.” Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 2013. ↩ Torii, Akihiko and Arandjelovic, Relja and Sivic, Josef and Okutomi, Masatoshi and Pajdla, Tomas. “24/7 Place Recognition by View Synthesis.” Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 2015. ↩ Sun, Jiaming, et al. “LoFTR: Detector-free local feature matching with transformers.” Proceedings of the IEEE/CVF conference on computer vision and pattern recognition. 2021. ↩ Ester, Martin, et al. “A density-based algorithm for discovering clusters in large spatial databases with noise.” kdd. Vol. 96. No. 34. 1996. ↩ Jiang, Wei and Trulls, Eduard and Hosang, Jan and Tagliasacchi, Andrea and Yi, Kwang Moo. “COTR: Correspondence Transformer for Matching Across Images.” Proceedings of the IEEE/CVF International Conference on Computer Vision. 2021. ↩ Edstedt, Johan et al. “Deep Kernelized Dense Geometric Matching”. arXiv preprint arXiv:2202.00667. (2022). ↩ Ivashechkin, Maksym, Daniel Barath, and Jiří Matas. “VSAC: Efficient and Accurate Estimator for H and F.” Proceedings of the IEEE/CVF International Conference on Computer Vision. 2021. ↩ Barath, Daniel, et al. “MAGSAC++, a fast, reliable and accurate robust estimator.” Proceedings of the IEEE/CVF conference on computer vision and pattern recognition. 2020. ↩
はじめに むノベヌションセンタヌの束䞋です。 NTTコミュニケヌションズ株匏䌚瀟 (以䞋、NTT Com) は、Interop Tokyo 2022の ShowNet においお、 䜎遅延ラむブ配信プラットフォヌム Smart vLive による4K䜎遅延ラむブ配信を展瀺したした。 この蚘事では、ShowNetでの展瀺の暡様をお䌝えしたす。 Smart vLive Smart vLiveは、1秒未満の遅延で映像をラむブ配信できるサヌビスです。 ブラりザでの通話やWeb䌚議に甚いられる技術であるWebRTCをラむブ配信に応甚するこずで、既存の技術では難しかった1秒未満の遅延を実珟しおいたす。 これたでWebRTCを甚いたラむブ配信では同時芖聎者数に制玄がありたしたが、Smart vLiveはラむブ配信に特化したシステムずしお蚭蚈され、芖聎者数が1䞇人を超える倧芏暡なむベントにも察応できたす。 たた、耇数のアングルを同時に配信できるマルチアングル機胜により、芖聎者が奜みの映像を遞択しお楜しむこずもできたす。 2021幎7月のサヌビス開始以降、スポヌツ・゚ンタメ・オヌクション・金融など、様々な業界でご掻甚いただいおいたす。 Smart vLiveのシステム構成 Smart vLiveは2段構成のシステムずなっおいたす。 1段目のメディアサヌバは、䞀般的なラむブ配信サヌビスず同様にRTMPで映像を受信したす。 メディアサヌバは受信した映像をリアルタむムで凊理し぀぀、2段目のWebRTC配信サヌバに送りたす。 WebRTC配信サヌバが芖聎者ずの間でWebRTC通信を行い、映像を配信したす。 倚段構成を取るこずで、芖聎者が増加しおもシステムをスケヌルできる構成ずなっおいたす。 各コンポヌネントでの映像凊理では现かいチュヌニングを重ねお䜎遅延を远求しおいたす。 ShowNetにおけるMedia over IPの取り組み 今回のShowNetでは、初めおの取り組みずしお Media over IP Pavilion が蚭眮されたした。 Media over IP Pavilionでは、映像ず音声ずいったコンテンツをIPネットワヌクを䜿っお䌝えるための最新の゜リュヌションが玹介されたした。 IP䞭継車や本栌的な映像関連の機噚が展瀺され、倚くの人が来堎しおいたした。 たた、ShowNetのラックにもMedia over IP関連補品が展瀺され、これたでのShowNetでは芋慣れないような補品に泚目が集たりたした。 ShowNetにおける展瀺内容 NTT Comは、Media over IP Pavilion内に蚭眮された ShowNetスタゞオ の暡様を4Kでラむブ配信するデモを行いたした。 Smart vLiveでは1080pたでの解像床をサポヌトしおいたすが (2022幎6月珟圚)、4K解像床で安定しお䜎遅延ラむブ配信を提䟛し続けられるか怜蚌するこずが今回の課題でした。 今回の実隓では、IP䞭継車から受け取ったShowNetスタゞオの映像を゚ンコヌドし、ShowNetのネットワヌクを通じおクラりド䞊にあるSmart vLiveの配信゚ンドポむントにアップロヌドしおいたす。 ShowNetスタゞオでは、ShowNetに関わる゚ンゞニアによる最新の技術に関するセッションが行われたした。 セッションの内容はSmart vLiveを通じお配信され、䌚堎の内倖で芖聎されたした。 なかには、Interopのブヌス内でSmart vLiveを通じおセッションを芖聎しお簡易的な生䞭継のようにお䜿いいただくなど、䜎遅延を生かした新たな利甚シヌンも芋぀かりたした。 この写真は、ShowNetスタゞオのセッションをラむブ配信しおいる様子です。 写真の右偎のモニタがIP䞭継車から受け取った映像、巊偎がSmart vLiveを通じお芖聎しおいる映像です。 4K解像床でも1秒未満の遅延でラむブ配信できるこずが確認でき、来堎者の方にも遅延の小ささを䜓感いただけたした。 おわりに Interop 2022のShowNetにおける、Smart vLiveによる4K䜎遅延ラむブ配信のデモに぀いお玹介したした。 Media over IPの取り組みは初めおのこずが倚く準備期間䞭は様々な課題に盎面したしたが、関係者の皆様のご尜力によっお無事に䌚期を終えるこずができたした。 今回のデモでは、Smart vLiveを甚いお3日間の䌚期䞭安定しお4K解像床でラむブ配信を実斜できたした。 今埌は、今回埗た知芋を掻かしながらSmart vLiveのさらなる機胜远加や品質向䞊に取り組んでいきたす。 Smart vLiveの開発チヌムでは、新たなラむブ配信・コミュニケヌションのプラットフォヌム開発を担圓いただける゚ンゞニアを 募集しおいたす 。 䜎遅延か぀スケヌラブルなラむブ配信システムの開発は技術的にも倚くの課題があり、゚ンゞニアずしお未知の領域を楜しみながら開発しおいたす。 今回の蚘事を読んでご興味を持っおいただけたしたら、お気軜にお問合せいただければ幞いです。
はじめに こんにちは初めたしお、むノベヌションセンタヌテクノロゞヌ郚門、Smart World 向けAI開発PJの藀原です。 我々は日々 Smart World の実珟に向け、䞻に補造業向けのデヌタ分析、AIの研究開発を行なっおおりたす。 匊チヌムでは孊䌚/論文投皿など積極的な孊術掻動も行なっおおり、IJCAI、KDD、CVPRなどのワヌクショップ採択されたり、最近ではAISTATSの本䌚議にも採択され ニュヌスリリヌス を出したした。 そうした孊術掻動の䞀環ずしお、先日匊チヌムは技術調査 & 研究成果発衚 & 䌁業玹介展瀺を目的に 2022幎床人工知胜孊䌚党囜倧䌚 (JSAI2022) ぞ参加したした( 毎幎匊チヌムではJSAIに数名が登壇しおいたす )。今幎は藀原、朚村、垂川の名(+むンダストリアルセッションにお䌁業玹介1名)がそれぞれ発衚を行ないたした。今回はそれぞれの発衚に぀いお、 因果探玢線 、 異垞怜知線 、 デヌタ拡匵線 の䞉本立おでご玹介したいず思いたす JSAI2022に぀いお 著名なAI関連囜内孊䌚の1぀で、今回は京郜で察面、リモヌトのハむブリッド開催でした。1぀特城ずしお、発衚内容に぀いお募集芁項が以䞋のようになっおいたす。 論文の芁件論文該圓分野に瀺される人工知胜およびその関連分野の孊術論文事䟋報告 このように新芏手法だけでなく事䟋報告も掚奚されおいる点があり、䌁業ずしおは特に参考になるような実斜䟋も数倚く聎講できたした。NTT Com 以倖にも数倚くの䌁業が参加しおおり、䌁業ブヌスなども倧盛り䞊がりでした。 今回の発衚内容 では今回JSAI2022で発衚した Just-In-Timeモデルを利甚した非定垞非線圢デヌタに察する因果探玢 に぀いお、内容をざっくりず説明したいず思いたす 背景 ビゞネスにおけるXAIの重芁性 さお前述のように我々は日々補造業向けにAI゜リュヌションの提䟛や技術開発を行なっおいるのですが、その兞型的な実斜䟋の1぀が以䞋のようなものになりたす(詳しくは、 AIプラント運転支揎゜リュヌション を参照)。䌁業様から工堎のセンサヌデヌタなどを受け取り、以䞋のようにAIでプラント操䜜量の掚奚倀を提瀺するものになりたす。ですが、 䞀般的にAIはその刀断根拠などがブラックボックスになりがちで、ビゞネスではそこが課題ずなりたす。 䞀般的に、AIに察しおそういった解釈性、説明性を持たせる詊みを XAI (explainable AI) ず蚀いたす。 因果探玢ずは たた、特に匊チヌムが泚力しおいる分野に 因果 がありたす。因果の考え方では、盞関や予枬に察する寄䞎床を芋るだけでなくデヌタから倉数間の因果関係を求めたり、求たった因果を利甚しお、他の倉数を固定した䞊である倉数を動かしたずきに(≒介入)どれだけの効果が生たれるか(≒因果効果)などを知るこずができたす。䟋えばプラントデヌタなら因果関係に基づき、生産量やCO2排出量に察しおのある操䜜量の最適化であったり、AI刀断根拠のより匷力な解釈ず、倉数遞択に基づく粟床改善などを行うこずができたす。 今回の発衚はタむトルにあるように、デヌタのみからこのような因果関係を求める、因果探玢に関する新芏手法の提案になりたす。 実時系列デヌタ解析の困難 泚力分野のもう1぀に、 時系列デヌタ解析 がありたす。先述のプラントの䟋などで埗られるデヌタずいうのは基本的に(連続)時系列デヌタが倚いです。時系列デヌタずは、時間的な順序が意味を持぀デヌタになりたす。 珟実の時系列デヌタ解析ではしばしば䞀般的な手法で前提ずされる理想的な仮定などが厩れおいお、安定した解析やAIモデルの䜜成が困難になりたす。 䟋えば、時々刻々システムの状態が倉化しおいる非定垞性や、倉数間の因果関係が簡単に蚘述できない非線圢なものである堎合がありたす。具䜓的に応甚における1぀有名な困難の䟋を挙げるず、 Concept Drift ずいっお、孊習時のデヌタ分垃ず予枬時のデヌタ分垃が異なっおしたうこずによる粟床䜎䞋の問題などが知られおいたす。 研究の目的 以䞊から、本研究の目的は以䞋のようになりたす。 背景 ビゞネスなどの応甚䞊でXAIが重芁になっおいる。さらには螏み蟌んで、因果探玢が重芁。 課題 䞀方で、応甚䞊で珟れる実時系列デヌタでは、因果探玢、時系列解析における理想的な条件が厩れおいる。 目的 実時系列デヌタで頻出の非定垞性、非線圢性、分垃シフトなどに察しお頑健な(≒匷い/安定な)因果探玢手法を開発する。 提案手法 このような非垞に耇雑な珟実の時系列デヌタに察しお、因果関係をデヌタのみから読み取るこずを考えたす。 キヌずなるアむデアは、 Just-In-Timeモデル [ Stenman 96-99 ][ 山本 13 ]ず呌ばれる既存のフレヌムワヌクの応甚です。 Just-In-Timeモデル Just-In-Timeモデルでは、出力を知りたい新しい入力デヌタが来る床に、その近傍デヌタを怜玢したす。 怜玢した結果埗られた近傍デヌタセットを甚いおAIモデルを孊習し、入力デヌタをそこに入力しお、出力を逐次で埗たす。これは、党おのデヌタを䜿い䞀床だけ孊習したAIモデルを䜿い回しお入力を入れお出力を埗る通垞のモデルずは異なるアプロヌチです。 近傍探玢を行うこずで近い状態のデヌタが集たるこずを期埅でき、先ほど述べたような分垃シフトの問題などに察応できるず期埅できたす。 たた、非線圢の関数も入力の近傍を取るこずで線圢関数ずいう単玔&解釈が容易なモデルで近䌌できたす(参考 テむラヌの定理 )。 芁するに、 耇雑な珟象も局所的に切り出せば単玔な珟象でモデル化できるはず 、ずいった感じです。 JIT-LiNGAM 因果探玢には非線圢の手法もいく぀か知られおいたすが、蚈算量や解釈性の芳点で䟝然問題がありたす。たた、実時系列デヌタの解析で起こる前述の問題(非定垞性、非線圢性、分垃シフトなど)に察しお安定性があるかは保蚌されたせん。 そこで、 䞊述のJust-In-Timeモデルを因果探玢に応甚しお、比范的単玔な線圢の因果探玢手法を䜿った局所的に線圢、倧域的に非線圢な因果探玢手法を考えたす 。線圢の因果探玢手法の代衚ずしお、 LiNGAM [ Shimizu 06 ][ Shimizu 11 ]を利甚したす。Just-In-Timeモデルの局所線圢近䌌を䜿うこずで、Additive Noise Model (ANM) [ Hoyer 08 ]ず呌ばれる、ノむズが加法的な広い非線圢のクラスに察しお、LiNGAMのアルゎリズムで解くこずができるようになるこずを定匏化により瀺せたす(論文参照)。アルゎリズムの抂芁は以䞋の通りです。 実隓 では実際にこの手法で人工デヌタに察しお実隓した䟋を芋おみたしょう。今回はたず初期段階ずしお簡単な非時系列/非線圢モデルで実隓したす(図1)。比范察象ずしおは因果探玢アルゎリズムはLiNGAMで、芳枬された党おのサンプルを䜿うもの(Cumulative ALL)、芳枬されたサンプルからK個ランダムに䜿うもの(K-Random)が甚意されおいたす。 提案手法は距離指暙や近傍遞択の方法によっお4パタヌン詊したした。距離指暙はナヌクリッド距離ずマハラノビス距離のもので2皮。 近傍遞択方法は、入力デヌタに察しお近い順にK個のデヌタを抜出する方法(KNN)、入力デヌタを䞭心に半埄 以内にあるデヌタからランダムにK個抜出する方法(ERN)の2皮。2皮×2皮で4パタヌンになりたす。 図2においおSHDずいう因果グラフに察する距離指暙を甚いお確認したずころ、提案手法矀の優䜍性を確認できたす。 考察 近傍の取り方によっお䞀定の傟向が芋られたので、こちらに぀いお考察しおいきたす。 距離指暙は芳枬が増えるごずにKNNだず増加傟向、ERNだず枛少傟向になっおいたす(䜎いほど粟床が高い)。 JIT本来の期埅では、芳枬デヌタが増えるほど䌌通った状態を芋぀けやすくなったり、より詳现な局所モデルを䜜れるようになるため粟床向䞊が期埅されたす。ですが、KNNでは実際にはそうなっおいたせん。 KNNで粟床が悪化しおいる原因ずしお、デヌタ密床の増加による近傍半埄の瞮小が原因ず考察したす。 たず図3を芋るずERNでは半埄 を蚭定した圱響で、近傍で取っおきたデヌタの暙準偏差がほが䞀定倀なのが分かりたす。䞀方で、KNNは暙準偏差(≒半埄)が芳枬増加ず共に瞮小しおいる様子が確認できたす。 次にこれがどのように因果探玢粟床に悪圱響を及がすか考察したす。図3の玫色の線が、0.05で、デヌタ生成の際に加えたラプラスノむズのスケヌルを目安ずしお衚瀺したものになっおいたす。KNNは半埄が瞮小し、最終的にはこの0.05を䞋回るほどにたでなっおいたすが、これが圱響しおいるず考えたす。因果を識別するためには、倉数 の内圚的な揺らぎが因果関係 によっお拡倧され、これによっお発生した揺らぎ を捉えるこずが必芁になりたす。しかし、これを近傍探玢によっおノむズのスケヌルよりも小さい範囲でカットしおしたうず、芳枬ノむズによる揺らぎ ず因果関係による揺らぎ を識別するこずが困難になり、因果探玢アルゎリズムの粟床が枛少するず考えられたす。今回はこのような考察を行いたしたが、この点に぀いおは匕き続き数理的な芳点を含めた怜蚎が必芁です。 たずめ 今回の発衚ではJust-In-Timeモデルの近傍探玢ず線圢の因果探玢手法LiNGAMを組み合わせるこずで、非定垞性、非線圢性、分垃シフトずいった、珟実のデヌタがしばしば抱える困難に察しお安定性のある因果探玢手法、JIT-LiNGAMを提案したした。たた提案手法に぀いお、基瀎的な実隓を行い、埓来のLiNGAMに察しおの優䜍性を瀺すず共に、有効な近傍探玢方法ぞの瀺唆を埗たした。 今埌の発展ずしおは、時系列モデルぞの拡匵、他の非線圢因果探玢モデルずの比范実隓、近傍探玢方法が粟床に䞎える圱響に぀いおより数理的な考察などを行っおいく予定です。 おわりに 以䞊が発衚内容になりたす今回は数匏を抑え目に、あくたで䜕が課題で、䜕ができるのかず、その実珟アルゎリズムの最䜎限の郚分を重芖しおお䌝えしたした。JIT-LiNGAMの詳现や定匏化に぀いおは、 今回の論文 や、 参考文献 をご芧になっお䞋さい。 宣䌝 Node-AI/デヌタ分析コンサルティング 私の所属するむノベヌションセンタヌテクノロゞヌ郚門 Smart World向けAI開発PJ では、日々AI/デヌタ分析に関するアルゎリズムなどの研究開発をしおいたす。これらの技術は同じくむノベヌションセンタヌテクノロゞヌ郚門の Node-AI PJ によっお内補開発されおいるノンコヌディングAIモデル開発ツヌル、 Node-AI (本ブログでの解説蚘事は こちら ) に搭茉されたり、同じく デヌタ分析コンサルティングPJ ず共同で、デヌタ分析案件におお客様に提䟛されおいたす。 特に、Node-AIにはただ今回の発衚のアルゎリズムは乗っおいたせんが、基本的な時系列因果分析機胜が搭茉されおおり、今回の䟋のようにデヌタ間の因果関係を求めグラフ䞊に可芖化できたす。たたこれは時系列因果モデルなので、時間遅れを考慮した倉数間の因果関係を知るこずができ、「センサヌAの倀が5分遅れでセンサヌBに効いおいる」ずいった解析が可胜です 匊チヌムでは、䌁業様ず共同での今回のような因果分析を含め䞻に時系列デヌタ解析/予枬/異垞怜知/最適化を察象ずしたPoC、各皮究機関ずの共同研究案件、Node-AIのご契玄を募集䞭ですので、ご興味があればこちらたでご連絡ください(メヌルai-deep-ic[at]ntt.com) 採甚 匊チヌムではリサヌチャヌ、ML゚ンゞニアを募集䞭です。今回のようにメンバヌの孊䌚発衚も掚奚され、前述のようなチヌム連携により開発アルゎリズムが即座にビゞネスサむドで怜蚌、瀟䌚実装される玠晎らしい環境です。ぜひご応募䞋さい。採甚情報に぀いおは こちら からよろしくお願いしたす。(新卒入瀟をお考えの堎合は新卒採甚情報をご芧䞋さい) 参考文献 [今回の論文] 藀原 倧悟, 小山 和茝, 切通 恵介, 倧川内 智海, 泉谷 知範, 浅原 啓茔, æž…æ°Ž 昌平: Just-In-Timeモデルを利甚した非定垞非線圢時系列デヌタに察する因果探, 人工知胜孊䌚党囜倧䌚論文集, Vol. JSAI2022, pp. 3E4GS205-3E4GS205, (2022), 論文リンク(フリヌ) [Stenman 96-99] Stenman, A., Gustafsson, F., Ljung, L.: Just in time models for dynamical systems, Proceedings of 35th IEEE Conference on Decision and Control, Vol. 1, pp. 1115--1120 (1996) など [山本 13] 山本茂Just-In-Time 予枬制埡: 蓄積デヌタに基 づく予枬制埡, 蚈枬ず制埡, Vol. 52, No. 10, pp. 878–884 (2013) [Shimizu 06] Shimizu, S., Hoyer, P. O., Hyvšarinen, A., Kerminen, A., and Jordan, M.: A linear non-Gaussian acyclic model for causal discovery., Journal of Machine Learning Research, Vol. 7, No. 10 (2006) [Shimizu 11] Shimizu, S., Inazumi, T., Sogawa, Y., Hyvšarinen, A., Kawahara, Y., Washio, T., Hoyer, P. O., and Bollen, K.: DirectLiNGAM: A direct method for learning a linear non-Gaussian structural equation model, The Journal of Machine Learning Research,、 Vol. 12, pp. 1225–1248 (2011) [Hoyer 08] Hoyer, P., Janzing, D., Mooij, J. M., Peters, J., and Schšolkopf, B.: Nonlinear causal discovery with additive noise models, Advances in neural information processing systems, Vol. 21, pp. 689–696 (2008)
サマリ Single-AS で構成されるネットワヌクにおいお、 SR-MPLS + VPNv4 + explicit path による Traffic Engineering (TE) を実珟 IOS XR + Junos の Multi-vendor 環境で動䜜怜蚌に成功 この蚘事は Multi-AS Segment Routing 怜蚌連茉の第 4 回です。目次は こちら 抂芁 むノベヌションセンタヌの竹䞭です。普段の業務では Multi-AS Segment Routing に関する技術怜蚌や、ネットワヌク運甚効率化のためのコントロヌラヌ開発などを行なっおいたす。 本蚘事では Single-AS においお SR-MPLS を甚いた TE に぀いおご玹介したす。 第 0 回の蚘事 でもご玹介した通り、我々は Multi-AS/Multi-domain SR-MPLS における VPN ず TE の実珟手法を怜蚌しおいたす。 第 1 回の蚘事 、 第 2 回の蚘事 、 第 3 回の蚘事 を通しお、 Multi-AS/Multi-domain SR-MPLS における L3VPN、L2VPN に぀いお説明、怜蚌したした。 本蚘事では SR を甚いた TE 手法に぀いおご玹介する䞊で、たずは TE に必芁ずなる SR Policy に぀いお説明したす。 その埌に 第 1 回の蚘事 で䜜成した Single-AS アンダヌレむでの Color-Based Steering の手法を、サンプルトポロゞヌや蚭定䟋を添えながら玹介したす。 Multi-AS での TE は第 5 回の蚘事にお玹介する予定です。 SR Policy SR Policy ずは SR Policy 1 ずは、SR で構成されたネットワヌクにおいお、運甚者の意図に基づいた゜ヌスルヌティングを行うためポリシヌであり、䞋蚘の3぀の芁玠で構成されたす。 SR domain の Tailend である endpoint TE 経路を指定する Segment List ポリシヌず経路を玐づける識別子である color SR Policy の適甚方法はいく぀か存圚したすが、本蚘事においおは MP-BGP で広告された VPN 経路に察しお SR Policy を適甚する流れを玹介したす。 VPN 経路ぞの SR Policy の適甚方法ずしおは、 SR Policy を適甚察象の color ず endpoint を指定しお定矩しおおき、 BGP で受け取った経路のうち Color Extended Community ず nexthop の組み合わせが䞀臎する経路に適甚する方法がありたす。 BGP の color はネットワヌクの運甚意図の䌝達ずしお甚いるこずができ、同じ endpoint に察しお color ごずに異なる SR Policy を定矩可胜です。このように、経路に付加された color に応じお SR Policy を適甚する TE 手法を Color-Based Steering ず呌びたす。 本蚘事においおは color ず endpoint を指定しお SR Policy を適甚したすが、color のみを指定しお endpoint を動的に評䟡し SR Policy をむンスタンス化する On-Demand Next-Hop (ODN) ず呌ばれる技術も存圚したす。ただし、この技術は本蚘事の怜蚌トポロゞヌでは䜿わないため、埌続の蚘事にお玹介・怜蚌したす。 explicit path ず dynamic path SR Policy の持぀経路は、その生成手法によっお explicit path ず dynamic path に分類されたす。 explicit path は、Segment List をあらかじめ蚭定し、静的に経路を指定したす。 䞀方で dynamic path は制玄に基づいた Segment List の蚈算方法を衚珟するもので、SR Policy の蚭定時やトポロゞヌ、メトリックなどの状態倉曎時に Segment List を動的に蚈算したす。 本蚘事においおは、TE の実珟方法ずしお explcit path を甚いた怜蚌を玹介したす。 dynamic path を甚いた怜蚌䟋は埌続の蚘事をご参照ください。たた、我々の dynamic path に関する取り組みに぀いおは NTT Tech Conference 2022 や ENOG74 でも発衚しおいたす。 color の仕組みず利甚䟋 BGP で経路を export たたは import する際に Color Extended Community を経路に付加するこずで、その経路ぞの SR Policy 適甚の可吊、ならびに適甚する SR Policy の決定が可胜です。 BGP 経路に察する Color Extended Community の付加範囲は様々です。特定のネットワヌクの経路に察しお付加するこずで圓該ネットワヌクのみ挙動を倉えたり、特定の Route-Distinguisher (RD) や Route-Target (RT) を持぀経路情報に察しお付加するこずで圓該 VRF 党䜓の挙動を倉えたりできたす。 䞊蚘の図は Color-Based Steering の暡匏図で、Single-AS の SR-MPLS においお VPN 経路ごずの TE を実装する様子を衚しおいたす。なお、TE で利甚するラベルのみ図䞭に明蚘し、各顧客を瀺す VPN ラベルは省略しおいたす。 SR Policy に埓った TE たでの手順は以䞋の通りです。 ingress PE (PE1) にお SR Policy を蚭定する egress PE (PE2) で IBGP による Customer A、B の経路を IBGP で広告する 広告の際に各 VRF の RD ごずに Color Extended Community を付加する IBGP によっお広告された経路を PE1 で受け取り、各 VRF table に import する import の際に経路に察しお color、endpoint の䞀臎する SR Policy を適甚する SR Policy を適甚した経路を参照するパケットを各 Customer から受け取った時に、SR Policy に埓った Segment List を付䞎し SR-MPLS で構成されるコアネットワヌクに送出する 次章の怜蚌䟋では、䞊蚘手順に沿った怜蚌を玹介したす。 怜蚌䟋の玹介 䞋蚘のトポロゞヌを利甚し、 Color-Based Steering の怜蚌䟋を玹介したす。 たた、L3VPN 環境準備たでの蚭定䟋は こちら を参照ください。 以降は Color-Based Steering にお Customer ごずに䞋図の TE を行うための蚭定ず確認方法を蚘茉したす。ingress PE には SR Policy の蚭定、egress PE には VPN 経路に Color Extended Community を付加する蚭定を入れたす。 Customer A の TE Customer B の TE SR Policy の蚭定ず確認 たず SR Policy を蚭定したす。explicit path を利甚する堎合は Segment List の蚭定も必芁です。 PE1 (IOS XR) 偎 segment-routing traffic-eng segment-list vrf-100-segment-list index 10 mpls label 16002 index 20 mpls label 16004 index 30 mpls label 16003 ! segment-list vrf-200-segment-list index 10 mpls label 16004 index 20 mpls label 16002 index 30 mpls label 16003 ! policy vrf-100-policy color 100 end-point ipv4 10.255.0.3 candidate-paths preference 50 explicit segment-list vrf-100-segment-list ! ! ! ! policy vrf-200-policy color 200 end-point ipv4 10.255.0.3 candidate-paths preference 50 explicit segment-list vrf-200-segment-list ! ! ! ! ! ! デヌタベヌスに SR Policy が远加されたこずを確認したす。 RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy Tue Jul 12 11:38:51.837 JST SR-TE policy database --------------------- Color: 100, End-point: 10.255.0.3 Name: srte_c_100_ep_10.255.0.3 Status: Admin: up Operational: up for 00:05:04 (since Jul 12 11:33:47.109) Candidate-paths: Preference: 50 (configuration) (active) Name: vrf-100-policy Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Explicit: segment-list vrf-100-segment-list (valid) Weight: 1, Metric Type: TE 16002 16004 16003 Attributes: Binding SID: 24008 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no Color: 200, End-point: 10.255.0.3 Name: srte_c_200_ep_10.255.0.3 Status: Admin: up Operational: up for 00:00:32 (since Jul 12 11:38:19.552) Candidate-paths: Preference: 50 (configuration) (active) Name: vrf-200-policy Requested BSID: dynamic Protection Type: protected-preferred Maximum SID Depth: 10 Explicit: segment-list vrf-200-segment-list (valid) Weight: 1, Metric Type: TE 16004 16002 16003 Attributes: Binding SID: 24011 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no PE2 (Junos) 偎 set protocols source-packet-routing segment-list vrf-100-segment-list P2 label 16004 set protocols source-packet-routing segment-list vrf-100-segment-list P1 label 16002 set protocols source-packet-routing segment-list vrf-100-segment-list PE1 label 16001 set protocols source-packet-routing source-routing-path vrf-100-policy to 10.255.0.1 set protocols source-packet-routing source-routing-path vrf-100-policy color 100 set protocols source-packet-routing source-routing-path vrf-100-policy primary vrf-100-segment-list set protocols source-packet-routing segment-list vrf-200-segment-list P1 label 16002 set protocols source-packet-routing segment-list vrf-200-segment-list P2 label 16004 set protocols source-packet-routing segment-list vrf-200-segment-list PE1 label 16001 set protocols source-packet-routing source-routing-path vrf-200-policy to 10.255.0.1 set protocols source-packet-routing source-routing-path vrf-200-policy color 200 set protocols source-packet-routing source-routing-path vrf-200-policy primary vrf-200-segment-list デヌタベヌスに SR Policy が远加されたこずを確認したす。 user@PE2> show spring-traffic-engineering lsp name vrf-100-policy detail Name: vrf-100-policy Tunnel-source: Static configuration Tunnel Forward Type: SRMPLS To: 10.255.0.1-100<c> State: Up Path: vrf-100-segment-list Path Status: NA Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Disabled , Compute Result:N/A , Compute-Profile Name:N/A BFD status: N/A BFD name: N/A Segment ID : 128 ERO Valid: true SR-ERO hop count: 3 Hop 1 (Strict): NAI: None SID type: 20-bit label, Value: 16004 Hop 2 (Strict): NAI: None SID type: 20-bit label, Value: 16002 Hop 3 (Strict): NAI: None SID type: 20-bit label, Value: 16001 Total displayed LSPs: 1 (Up: 1, Down: 0) user@PE2> show spring-traffic-engineering lsp name vrf-200-policy detail Name: vrf-200-policy Tunnel-source: Static configuration Tunnel Forward Type: SRMPLS To: 10.255.0.1-200<c> State: Up Path: vrf-200-segment-list Path Status: NA Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Disabled , Compute Result:N/A , Compute-Profile Name:N/A BFD status: N/A BFD name: N/A Segment ID : 128 ERO Valid: true SR-ERO hop count: 3 Hop 1 (Strict): NAI: None SID type: 20-bit label, Value: 16002 Hop 2 (Strict): NAI: None SID type: 20-bit label, Value: 16004 Hop 3 (Strict): NAI: None SID type: 20-bit label, Value: 16001 Total displayed LSPs: 1 (Up: 1, Down: 0) BGP Color Extended Community 付加の蚭定ず確認 BGP で広告する経路に color を付加したす。 PE1 (IOS XR) 偎 vrf 100 address-family ipv4 unicast export route-policy add-color-100 ! ! vrf 200 address-family ipv4 unicast export route-policy add-color-200 ! ! extcommunity-set opaque color-100 100 end-set ! extcommunity-set opaque color-200 200 end-set ! route-policy add-color-100 set extcommunity color color-100 end-policy ! route-policy add-color-200 set extcommunity color color-200 end-policy 察向の PE2 にお、受け取った経路に color が぀いおいるこずを確認したす。 user@PE2> show route table bgp.l3vpn.0 detail bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 65000:100:192.168.0.0/24 (1 entry, 0 announced) *BGP Preference: 170/-101 Route Distinguisher: 65000:100 Next hop type: Indirect, Next hop index: 0 Address: 0x704dfc4 Next-hop reference count: 3 Source: 10.255.0.1 Next hop type: Router, Next hop index: 0 Next hop: 10.0.2.1 via ge-0/0/0.0 Label operation: Push 24004, Push 16001(top) Label TTL action: prop-ttl, prop-ttl(top) Load balance label: Label 24004: None; Label 16001: None; Label element ptr: 0x780fa88 Label parent element ptr: 0x782ea28 Label element references: 4 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 Next hop: 10.0.3.1 via ge-0/0/1.0, selected Label operation: Push 24004, Push 16001(top) Label TTL action: prop-ttl, prop-ttl(top) Load balance label: Label 24004: None; Label 16001: None; Label element ptr: 0x780fa88 Label parent element ptr: 0x782ea28 Label element references: 4 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 Protocol next hop: 10.255.0.1 Label operation: Push 24004 Label TTL action: prop-ttl Load balance label: Label 24004: None; Indirect next hop: 0x7198904 1048576 INH Session ID: 0x144 State: <Active Int Ext ProtectionPath ProtectionCand> Local AS: 65000 Peer AS: 65000 Age: 3:58 Metric: 0 Metric2: 30 Validation State: unverified ORR Generation-ID: 0 Task: BGP_65000.10.255.0.1 AS path: ? Communities: target:65000:100 color:0:100 Import Accepted VPN Label: 24004 Localpref: 100 Router ID: 10.255.0.1 Secondary Tables: 100.inet.0 Thread: junos-main 65000:200:192.168.0.0/24 (1 entry, 0 announced) *BGP Preference: 170/-101 Route Distinguisher: 65000:200 Next hop type: Indirect, Next hop index: 0 Address: 0x704e234 Next-hop reference count: 3 Source: 10.255.0.1 Next hop type: Router, Next hop index: 0 Next hop: 10.0.2.1 via ge-0/0/0.0, selected Label operation: Push 24005, Push 16001(top) Label TTL action: prop-ttl, prop-ttl(top) Load balance label: Label 24005: None; Label 16001: None; Label element ptr: 0x780fd30 Label parent element ptr: 0x782ea28 Label element references: 4 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 Next hop: 10.0.3.1 via ge-0/0/1.0 Label operation: Push 24005, Push 16001(top) Label TTL action: prop-ttl, prop-ttl(top) Load balance label: Label 24005: None; Label 16001: None; Label element ptr: 0x780fd30 Label parent element ptr: 0x782ea28 Label element references: 4 Label element child references: 0 Label element lsp id: 0 Session Id: 0x0 Protocol next hop: 10.255.0.1 Label operation: Push 24005 Label TTL action: prop-ttl Load balance label: Label 24005: None; Indirect next hop: 0x7198a84 1048577 INH Session ID: 0x144 State: <Active Int Ext ProtectionPath ProtectionCand> Local AS: 65000 Peer AS: 65000 Age: 2:42 Metric: 0 Metric2: 30 Validation State: unverified ORR Generation-ID: 0 Task: BGP_65000.10.255.0.1 AS path: ? Communities: target:65000:200 color:0:200 Import Accepted VPN Label: 24005 Localpref: 100 Router ID: 10.255.0.1 Secondary Tables: 200.inet.0 Thread: junos-main PE2 (Junos) 偎 ※ Junos のポリシヌは accept の埌のタヌムが実行されないため順序にご泚意ください set policy-options community COLOR-100 members color:0:100 set policy-options community COLOR-200 members color:0:200 delete policy-options policy-statement EXPORT-POLICY-100 set policy-options policy-statement EXPORT-POLICY-100 term ROUTE-TARGET then community add VRF100-65000-RT set policy-options policy-statement EXPORT-POLICY-100 term ADD-COLOR-100 then community add COLOR-100 set policy-options policy-statement EXPORT-POLICY-100 term REDIST-DIRECT from protocol direct set policy-options policy-statement EXPORT-POLICY-100 term REDIST-DIRECT then accept set routing-instances 100 vrf-export EXPORT-POLICY-100 delete policy-options policy-statement EXPORT-POLICY-200 set policy-options policy-statement EXPORT-POLICY-200 term ROUTE-TARGET then community add VRF200-65000-RT set policy-options policy-statement EXPORT-POLICY-200 term ADD-COLOR-200 then community add COLOR-200 set policy-options policy-statement EXPORT-POLICY-200 term REDIST-DIRECT from protocol direct set policy-options policy-statement EXPORT-POLICY-200 term REDIST-DIRECT then accept set routing-instances 200 vrf-export EXPORT-POLICY-200 察向の PE1 にお、受け取った経路に color が぀いおいるこずを確認したす。 RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf 100 192.168.1.0/24 Tue Jul 12 15:24:30.125 JST BGP routing table entry for 192.168.1.0/24, Route Distinguisher: 65000:100 Versions: Process bRIB/RIB SendTblVer Speaker 28 28 Last Modified: Jul 12 15:01:55.551 for 00:22:34 Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Not advertised to any peer Local 10.255.0.3 C:100 (bsid:24008) (metric 20) from 10.255.0.3 (10.255.0.3) Received Label 20 Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 1, version 28 Extended community: Color:100 RT:65000:100 SR policy color 100, up, not-registered, bsid 24008 Source AFI: VPNv4 Unicast, Source VRF: 100, Source Route Distinguisher: 65000:100 RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf 200 192.168.1.0/24 Tue Jul 12 15:24:46.645 JST BGP routing table entry for 192.168.1.0/24, Route Distinguisher: 65000:200 Versions: Process bRIB/RIB SendTblVer Speaker 29 29 Last Modified: Jul 12 15:01:55.551 for 00:22:51 Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Not advertised to any peer Local 10.255.0.3 C:200 (bsid:24011) (metric 20) from 10.255.0.3 (10.255.0.3) Received Label 21 Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 1, version 29 Extended community: Color:200 RT:65000:200 SR policy color 200, up, not-registered, bsid 24011 Source AFI: VPNv4 Unicast, Source VRF: 200, Source Route Distinguisher: 65000:200 SR Policy が適甚された経路の確認 たず PE1 から PE2 の経路に぀いお確認したす。 PE1 にお、察向の Customer ネットワヌクぞの経路の nexthop が SR Policy の凊理ぞ転送するためのロヌカルラベルずなっおいるこずが確認できたす。 RP/0/RP0/CPU0:PE1#sho cef vrf 100 Tue Jul 12 11:14:45.051 JST Prefix Next Hop Interface ------------------- ------------------- ------------------ 0.0.0.0/0 drop default handler 0.0.0.0/32 broadcast 192.168.0.0/24 attached GigabitEthernet0/0/0/2 192.168.0.0/32 broadcast GigabitEthernet0/0/0/2 192.168.0.254/32 receive GigabitEthernet0/0/0/2 192.168.0.255/32 broadcast GigabitEthernet0/0/0/2 192.168.1.0/24 24008 (via-label) <recursive> 224.0.0.0/4 0.0.0.0/32 224.0.0.0/24 receive 255.255.255.255/32 broadcast RP/0/RP0/CPU0:PE1#sho cef vrf 200 Tue Jul 12 11:16:24.775 JST Prefix Next Hop Interface ------------------- ------------------- ------------------ 0.0.0.0/0 drop default handler 0.0.0.0/32 broadcast 192.168.0.0/24 attached GigabitEthernet0/0/0/3 192.168.0.0/32 broadcast GigabitEthernet0/0/0/3 192.168.0.254/32 receive GigabitEthernet0/0/0/3 192.168.0.255/32 broadcast GigabitEthernet0/0/0/3 192.168.1.0/24 24011 (via-label) <recursive> 224.0.0.0/4 0.0.0.0/32 224.0.0.0/24 receive 255.255.255.255/32 broadcast ロヌカルラベル凊理は以䞋で確認できたす。 RP/0/RP0/CPU0:PE1#show mpls forwarding labels 24008 detail Tue Jul 12 11:18:35.029 JST Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched ------ ----------- ------------------ ------------ --------------- ------------ 24008 Pop No ID srte_c_100_e point2point 0 Updated: Jul 12 07:43:42.409 Version: 18, Priority: 2 Label Stack (Top -> Bottom): { Unlabelled Imp-Null } NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Weight: 0 MAC/Encaps: 0/0, MTU: 0 Outgoing Interface: srte_c_100_ep_10.255.0.3 (ifhandle 0x00000014) Packets Switched: 0 RP/0/RP0/CPU0:PE1#show mpls forwarding labels 24011 detail Tue Jul 12 11:17:27.943 JST Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched ------ ----------- ------------------ ------------ --------------- ------------ 24011 Pop No ID srte_c_200_e point2point 0 Updated: Jul 12 07:43:37.156 Version: 14, Priority: 2 Label Stack (Top -> Bottom): { Unlabelled Imp-Null } NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Weight: 0 MAC/Encaps: 0/0, MTU: 0 Outgoing Interface: srte_c_200_ep_10.255.0.3 (ifhandle 0x0000001c) Packets Switched: 0 次に PE2 から PE1 の経路に぀いお確認したす。 PE2 にお VRF routing table を確認したずころ、SR Policy が適甚された経路ずなっおいないこずが確認できたす。 user@PE2> show route table 100.inet.0 100.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24 *[BGP/170] 00:00:14, MED 0, localpref 100, from 10.255.0.1 AS path: ?, validation-state: unverified to 10.0.2.1 via ge-0/0/0.0, Push 24012, Push 16001(top) > to 10.0.3.1 via ge-0/0/1.0, Push 24012, Push 16001(top) 192.168.1.0/24 *[Direct/0] 00:37:16 > via ge-0/0/2.0 192.168.1.254/32 *[Local/0] 00:37:16 Local via ge-0/0/2.0 user@PE2> show route table 200.inet.0 200.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24 *[BGP/170] 00:00:23, MED 0, localpref 100, from 10.255.0.1 AS path: ?, validation-state: unverified to 10.0.2.1 via ge-0/0/0.0, Push 24013, Push 16001(top) > to 10.0.3.1 via ge-0/0/1.0, Push 24013, Push 16001(top) 192.168.1.0/24 *[Direct/0] 00:37:25 > via ge-0/0/3.0 192.168.1.254/32 *[Local/0] 00:37:25 Local via ge-0/0/3.0 Junos は BGP 経路の nexthop 解決をする際にデフォルトで color を考慮したせん。 次の蚭定を远加するこずで color を考慮しお nexthop を解決するようになりたす。 set policy-options policy-statement BGP-IMPORT-POLICY term VRF-100 from community VRF100-65000-RT set policy-options policy-statement BGP-IMPORT-POLICY term VRF-100 then accept set policy-options policy-statement BGP-IMPORT-POLICY term VRF-100 then resolution-map map1 set policy-options policy-statement BGP-IMPORT-POLICY term VRF-200 from community VRF200-65000-RT set policy-options policy-statement BGP-IMPORT-POLICY term VRF-200 then accept set policy-options policy-statement BGP-IMPORT-POLICY term VRF-200 then resolution-map map1 set policy-options resolution-map map1 mode ip-color set protocols bgp group ibgp import BGP-IMPORT-POLICY 改めお PE2 にお、 SR policy が適甚された経路が採甚されおいるこずが確認できたす。 user@PE2> show route table 100.inet.0 100.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24 *[BGP/170] 02:45:08, MED 0, localpref 100, from 10.255.0.1 AS path: ?, validation-state: unverified > to 10.0.3.1 via ge-0/0/1.0, Push 24012, Push 16001, Push 16002(top) 192.168.1.0/24 *[Direct/0] 03:27:59 > via ge-0/0/2.0 192.168.1.254/32 *[Local/0] 03:27:59 Local via ge-0/0/2.0 user@PE2> show route table 200.inet.0 200.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24 *[BGP/170] 02:45:23, MED 0, localpref 100, from 10.255.0.1 AS path: ?, validation-state: unverified > to 10.0.2.1 via ge-0/0/0.0, Push 24013, Push 16001, Push 16004(top) 192.168.1.0/24 *[Direct/0] 03:28:14 > via ge-0/0/3.0 192.168.1.254/32 *[Local/0] 03:28:14 Local via ge-0/0/3.0 疎通確認 PE1 ず PE2 から VPN 経路の traceroute を行い、TE によっお経路制埡されおいるこずを確認したす。 PE1 → PE2 RP/0/RP0/CPU0:PE1#traceroute 192.168.1.254 vrf 100 Wed Jul 13 19:14:09.683 JST Type escape sequence to abort. Tracing the route to 192.168.1.254 1 10.0.0.2 [MPLS: Labels 16004/16003/16 Exp 0] 17 msec 3 msec 9 msec 2 10.0.4.2 [MPLS: Labels 16003/16 Exp 0] 3 msec 5 msec 12 msec 3 192.168.1.254 3 msec 10 msec 4 msec RP/0/RP0/CPU0:PE1#traceroute 192.168.1.254 vrf 200 Wed Jul 13 19:17:27.790 JST Type escape sequence to abort. Tracing the route to 192.168.1.254 1 10.0.1.2 [MPLS: Labels 16002/16003/17 Exp 0] 13 msec 13 msec 5 msec 2 10.0.4.1 [MPLS: Labels 16003/17 Exp 0] 12 msec 14 msec 5 msec 3 192.168.1.254 11 msec 15 msec 5 msec PE2 → PE1 user@PE2> traceroute 192.168.0.254 routing-instance 100 traceroute to 192.168.0.254 (192.168.0.254), 30 hops max, 52 byte packets 1 10.0.3.1 (10.0.3.1) 3.025 ms 2.434 ms 39.277 ms MPLS Label=16002 CoS=0 TTL=1 S=0 MPLS Label=16001 CoS=0 TTL=1 S=0 MPLS Label=24012 CoS=0 TTL=1 S=1 2 10.0.4.1 (10.0.4.1) 11.748 ms 2.363 ms 2.796 ms MPLS Label=16001 CoS=0 TTL=1 S=0 MPLS Label=24012 CoS=0 TTL=2 S=1 3 10.0.0.1 (10.0.0.1) 11.454 ms user@PE2> traceroute 192.168.0.254 routing-instance 200 traceroute to 192.168.0.254 (192.168.0.254), 30 hops max, 52 byte packets 1 10.0.2.1 (10.0.2.1) 3.372 ms 2.207 ms 2.184 ms MPLS Label=16004 CoS=0 TTL=1 S=0 MPLS Label=16001 CoS=0 TTL=1 S=0 MPLS Label=24013 CoS=0 TTL=1 S=1 2 10.0.4.2 (10.0.4.2) 2.474 ms 2.358 ms 2.206 ms MPLS Label=16001 CoS=0 TTL=1 S=0 MPLS Label=24013 CoS=0 TTL=2 S=1 3 10.0.1.1 (10.0.1.1) 11.859 ms このように、Single-AS SR-MPLS で構成されたネットワヌクでの TE が実珟できたした。 たずめ 本蚘事では、SR における TE の実珟に利甚される SR Policy に぀いお説明し、Multi-vendor 環境における Single-AS SR-MPLS での Color-Based Steering の怜蚌結果を玹介したした。次回の蚘事では、Multi-AS における TE に぀いお玹介予定です。 2022/08/08 远蚘 公開したした [Multi-AS Segment Routing 怜蚌連茉 #5] Traffic Engineering in Multi-AS Internet-Drafts ずしお https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ で議論䞭。 ↩