· 7696 words · 37 min read

9. 네트워크#

VLAN 자동화가 랩에서 3주간 실행되었다. 스위치 세 대, 각기 다른 벤더, 모든 워크플로우가 통과했다. 팀은 자신감을 느꼈다. 첫 번째 프로덕션 실행에서 800개 캠퍼스 스위치 중 23개가 실패했다. 모두 HPE였다. 모두 아무도 문서화하지 않은 펌웨어 버전을 실행하고 있었다.

플레이북은 VLAN 설정을 푸시한 후 각 장치의 오류 응답을 확인하고 있었다. 최신 HPE 펌웨어에서는 이미 존재하는 VLAN이 오류 코드 duplicate-vlan을 반환한다. 이 오래된 펌웨어 버전에서는 동일한 조건이 vlan-exists를 반환했다. 플레이북은 duplicate-vlan을 멱등성 신호, 즉 “이미 존재하므로 괜찮다"는 의미로 처리하도록 작성되어 있었다. vlan-exists를 처리하도록 작성되지 않아 해당 응답을 실패로 처리했다. HPE 플리트의 3분의 1이 실패를 보고했다. 롤백은 정상적으로 실행되었다. 애플리케이션 팀의 티켓은 네트워크 팀이 실제로 설정된 스위치와 그렇지 않은 스위치를 수동으로 감사하는 동안 3시간 더 열려 있었다.

자동화가 잘못된 것이 아니었다. 네트워크에 아무도 문서화하지 않은 동작 방식이 있었던 것이다.

6개월 후, 같은 팀은 Building B를 반영하는 containerlab 토폴로지를 보유했다: 스위치 24개, 일치하는 벤더 이미지, HPE 노드는 Source of Truth (SoT)에 기록된 프로덕션 펌웨어 버전으로 고정되어 있었다. 해당 토폴로지에 대한 VLAN 워크플로우의 첫 번째 테스트 실행에서 HPE 노드 8개가 바로 그 오류 코드로 실패했다. 팀은 vlan-exists를 HPE 어댑터의 멱등 응답 목록에 추가했다. 재실행: 24개 노드 모두 통과. 프로덕션 배포: 스위치 800개, 실패 없음.

차이는 더 나은 코드가 아니었다. 차이는 현실을 반영한 테스트 환경이었다.

이 챕터는 파트 2 전반에 걸쳐 항상 암묵적으로 존재했던 블록인 네트워크 자체를 다룬다. 지금까지 구축한 모든 빌딩 블록은 자동화 팀이 설계했으며 문서화된 인터페이스에 따라 동작한다. 네트워크는 물려받은 것이다. 네트워크에는 특이한 동작, 다양한 인터페이스, 펌웨어 불일치, 그리고 벤더, 플랫폼, 소프트웨어 세대에 따라 달라지는 기능들이 있다. 챕터 9는 두 가지 질문을 다룬다: 자동화를 신뢰할 수 있게 만들기 위해 네트워크에서 무엇이 필요한가, 그리고 프로덕션에 닿기 전에 자동화 로직을 어떻게 안전하게 검증하는가?

9.1. 기본 개념#

9.1.1. 컨텍스트#

챕터 3은 NAF Framework의 일곱 블록 중 하나로 네트워크를 소개했다: 자동화 팀이 “소유"하지 않는 유일한 블록(네트워크 엔지니어링의 범위에 있다). 팀은 네트워크를 설정하고, 관찰하고, 의도를 모델링하지만, 운영 체제, 데이터 모델, 또는 API 인터페이스를 구축하지는 않았다. 이 의존성이 그 위에 있는 플랫폼의 모든 설계 결정을 형성한다.

챕터 5는 Executor의 쓰기 경로를 상세히 다루었다: 자동화 역할, 매개변수화된 태스크, 멱등성 검사가 어떻게 동작하는지. 챕터 5가 주어진 것으로 처리하는 것은 반대편의 장치가 신뢰할 수 있고 일관된 인터페이스를 노출한다는 것이다. 챕터 9는 그 가정이 성립하는지, 성립하지 않을 때 어떻게 해야 하는지를 다룬다.

챕터 6는 Collector의 읽기 경로를 다루었다: gRPC Network Management Interface (gNMI) 스트리밍 텔레메트리, SNMP 폴링, 그리고 데이터 정규화 파이프라인. 챕터 9는 해당 경로의 장치 측 전제 조건을 다룬다: Collector가 일관되게 읽기를 수행하려면 네트워크 장치에 대해 무엇이 참이어야 하는가.

Executor와 Collector는 동일한 장치에 도달하기 위해 종종 동일한 프로토콜을 사용한다: gNMI와 NETCONF 모두 설정 쓰기와 텔레메트리 읽기가 가능하며, 둘 다 동일한 관리 플레인에 연결된다. 실제로 팀은 종종 운영 강점에 따라 각 작업 유형별로 하나의 프로토콜을 선택한다: 고주파 텔레메트리를 위한 gNMI 스트리밍 구독, 설정을 위한 NETCONF 트랜잭션. 프로토콜이 해당 역할에 독점적인 것은 아니다. 이것이 인터페이스 선택과 장치 호환성이 두 블록에 동시에 중요한 이유다: gNMI 구독을 중단시키는 펌웨어 버전은 Collector에 영향을 미치고, NETCONF edit-config를 중단시키는 버전은 Executor에 영향을 미친다.

챕터 9는 파트 2를 마무리한다. 이전 여섯 챕터는 자동화 플랫폼을 구축했다: 의도를 저장할 곳, 실행할 방법, 결과를 관찰할 방법, 모든 것을 조율할 엔진, 그리고 소비자에게 노출할 인터페이스. 이 챕터는 플랫폼이 항상 가리키고 있던 대상을 다룬다.

9.1.2. 목표#

세 가지 목표가 자동화 플랫폼에 대한 네트워크 블록의 기여를 정의한다:

전체 네트워크 인프라 스펙트럼을 이해하고 탐색한다. 대규모 자동화 플랫폼은 캠퍼스 스위치, 데이터 센터 패브릭, 클라우드 VPC, Kubernetes 오버레이, 오버레이 컨트롤러, 그리고 레거시 장비와 동시에 통신할 수 있다. 각 유형은 서로 다른 프로그래머블 인터페이스를 노출한다. 플랫폼은 단일 최소 공통 분모 추상화로 축소되지 않고 이 모두를 처리해야 한다.
프로덕션에 닿기 전에 자동화 로직을 검증하고 새로운 네트워크 아키텍처 설계를 지원한다. 시뮬레이션 환경은 두 가지 목적을 수행한다: 논리 오류, 인터페이스 계약 위반, 장치별 특이 동작을 프로덕션 인시던트에서 몇 시간이 아닌 랩에서 몇 분의 비용으로 포착하는 사전 프로덕션 게이트이며, 하드웨어를 주문하기 전에 새로운 네트워크 아키텍처를 탐색하고 검증하는 설계 환경이다.
네트워크가 진화함에 따라 자동화 플랫폼을 안정적으로 유지한다. 새 벤더가 추가된다. 펌웨어 버전이 변경된다. 새로운 인프라 유형이 도입된다. 플랫폼은 네트워크가 변경될 때마다 모든 워크플로우에 임시 패치를 적용하는 것이 아니라 추상화 전략을 통해 이 변화를 수용하도록 설계되어야 한다.

9.1.3. 기둥#

세 가지 기둥이 이 목표를 지원하며, 각 기능별로 하나씩이다:

네트워크 인프라 스펙트럼과 프로그래머블 인터페이스: 플랫폼이 자동화해야 하는 네트워크 유형의 전체 범위, 그리고 각 유형이 Executor와 Collector에 노출하는 인터페이스.
시뮬레이션 및 테스팅 환경: 사전 프로덕션 검증을 위한 툴체인. 다양한 랩 환경 유형이 어디에 적합한지, 챕터 7의 Saga 패턴과 어떻게 연결되는지, 그리고 어떻게 확장하는지.
추상화 전략: 벤더, 플랫폼 세대, 인터페이스 프로토콜에 관계없이 기반 네트워크가 변화함에 따라 자동화 플랫폼이 안정적으로 유지될 수 있도록 하는 구조적 접근 방식.

9.1.4. 범위#

범위 내:

Executor와 Collector가 네트워크 장치에 도달하는 인터페이스. NETCONF와 gNMI 모두 설정 및 텔레메트리 작업을 지원하며, 사용 사례별 선택은 프로토콜 독점성이 아닌 운영 강점에 따른다. 프로토콜은 종종 블록 간에 공유되며, 작업 유형이 다를 뿐이다.
프로덕션 전에 자동화를 검증하는 테스팅 환경과 방법론
멀티벤더 및 멀티플랫폼 이기종 환경을 관리하는 추상화 전략
자동화 설계에 대한 클라우드, Kubernetes, 오버레이 네트워킹의 영향

범위 외:

설정 생성 및 템플릿 렌더링 (Source of Truth (SoT), 챕터 4)
실행 메커니즘: 자동화 툴링이 태스크를 실행하는 방법 (Executor, 챕터 5)
텔레메트리 수집 파이프라인: 메트릭이 시계열 데이터베이스로 흐르는 방법 (Observability, 챕터 6)

경계는 일관적이다: 챕터 9는 플랫폼 측이 아닌 각 인터페이스의 네트워크 측을 다룬다.

9.2. 기능#

네트워크 블록은 NAF 프레임워크에서 자동화 플랫폼이 제어하지 않는 유일한 빌딩 블록이다. 네트워크가 허용하는 방식으로만 인터페이스할 수 있다. 이전 다섯 챕터의 모든 설계 결정, 즉 의도가 저장되는 방식, 실행이 실행되는 방식, 텔레메트리가 수집되는 방식, 워크플로우가 조율되는 방식, 소비자에게 서비스가 제공되는 방식은 궁극적으로 연결 반대편의 네트워크 장치가 무엇을 지원하는지에 대한 질문으로 귀결된다. 이 챕터는 그 제약을 직접 살펴본다.

graph LR

    subgraph 목표
        direction TB
        A1[전체 네트워크 인프라 스펙트럼 탐색]
        A2[프로덕션 전 자동화 검증]
        A3[네트워크가 진화함에 따라 플랫폼 안정성 유지]
    end

    subgraph 기둥
        direction TB
        B1[네트워크 인프라 스펙트럼과 프로그래머블 인터페이스]
        B2[시뮬레이션 및 테스팅 환경]
        B3[추상화 전략]
    end

    subgraph 기능
        direction TB
        C1[프로그래머블 인터페이스]
        C2[시뮬레이션 및 테스팅 환경]
        C3[추상화 전략]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

9.2.1. 프로그래머블 인터페이스#

네트워크는 본질적으로 이기종이다. 단일한 것이 아니다. 수년에 걸쳐 누적된 인프라 유형의 스펙트럼이며, 종종 서로 다른 팀이 병렬로 구축했고(소유권과 조직적 경계는 챕터 13에서 탐구한다), 각각 고유한 인터페이스 모델, 추상화 수준, 자동화 성숙도를 가진다. 현대 자동화 플랫폼은 캠퍼스 스위치, 데이터 센터 패브릭, 클라우드 VPC, 오버레이 컨트롤러, Kubernetes 클러스터, 서비스 프로바이더 WAN 인프라, 그리고 하이퍼스케일러 관리 포워딩 플레인을 동시에 다룰 수 있다. 플랫폼은 이 모두를 처리해야 한다. 인프라 유형이 사용 가능한 인터페이스를 결정하며, 자동화 플랫폼은 균일한 인터페이스를 요구하는 것이 아니라 그 현실에 적응한다.

9.2.1.1. 네트워크 인프라 스펙트럼#

회사의 성격에 따라 다루어야 할 수 있는 다양한 네트워크 인프라 시나리오의 개요다:

캠퍼스 및 브랜치 스위칭은 파트 2 전반에 걸쳐 예시로 사용한 핵심 시나리오다: 멀티벤더 물리 스위치 (Cisco, Arista, HPE, Extreme). 최신 캠퍼스 장비는 Command Line Interface (CLI), NETCONF, gRPC Network Management Interface (gNMI)를 동시에 노출한다. 최근 5~7년간의 장비에 대한 자동화 성숙도는 높다; 10년 된 펌웨어를 실행 중인 레거시 장비에 대해서는 불균일하다.
데이터 센터 패브릭 토폴로지는 일반적으로 리프-스파인 구조로, 더 적은 벤더 세트에서 나오는 경우가 많다: Arista, Cisco Nexus, 또는 자동화 네이티브 오픈 네트워킹 플랫폼. 인터페이스 균일성은 캠퍼스보다 높고, 변경 관리는 더 엄격하다. EVPN/VXLAN 오버레이는 패브릭 위에 관리 플레인을 추가하며, 개별 장치 인터페이스와 별도의 고유한 API를 가질 수 있다. SONiC 기반 플랫폼(Cisco 8000, Nvidia Spectrum)은 하이퍼스케일러 영향을 받은 DC 배포에서 점점 더 많이 나타나고 있다; 이들의 설정 인터페이스는 CLI나 NETCONF가 아닌 구조화된 데이터베이스이며, 추상화 전략 섹션에서 더 자세히 다룬다.
서비스 프로바이더 및 WAN 인프라 (캐리어급 라우터, MPLS 네트워크, 세그먼트 라우팅 패브릭)는 자체적인 자동화 과제가 있다: 규모, 프로토콜 복잡성, 컨트롤 플레인 설정과 트래픽 엔지니어링 정책의 이중 관심사. NETCONF와 YANG 모델은 이 분야에서 잘 확립되어 있다; Cisco IOS-XR 및 Junos와 같은 벤더는 성숙한 YANG 커버리지를 갖추고 있다. 자동화 플랫폼은 종종 개별 장치가 아닌 컨트롤러(SR-PCE, Crosswork, NSO)를 대상으로 한다.
클라우드 네트워킹: AWS VPC, Azure VNet, GCP VPC 및 기타. 최종 일관성 의미론을 가진 REST API. “설정을 푸시하고 동기 확인을 기다린다"는 개념이 없다. Executor는 비동기 작업을 처리한다: 생성, 폴링, 검증. 코드로서의 인프라(Infrastructure-as-Code) 툴링이 이 모델에 자연스럽게 맞는다. 자동화 플랫폼은 동기적 적용-확인 의미론을 가정하지 않고 다른 일관성 모델을 고려해야 한다.
SD-WAN 및 오버레이 네트워크 (Cisco SD-WAN, Versa, VMware VeloCloud)는 컨트롤러 관리 방식이다. 자동화 대상은 컨트롤러 API이며, 개별 장치가 아니다. 물리적 언더레이는 여전히 존재하지만 오버레이의 추상화를 통해 완전히 관리된다. 이는 실행과 관찰 가능성 모두에 영향을 미친다: Executor는 컨트롤러에 정책을 쓰고, 트래픽, 경로 선택, 정책 시행에 대한 텔레메트리도 물리적 언더레이 장치에서 직접이 아닌 컨트롤러의 노스바운드 인터페이스를 통해 흐른다.
Kubernetes 네트워킹은 CNI 레이어에서 장치 모델을 완전히 역전시킨다. 네트워크는 Kubernetes API 객체를 통해 정의된다: NetworkPolicy, Services, Ingress, 그리고 Cilium, Calico, Flannel과 같은 CNI 플러그인의 커스텀 리소스. 장치가 자동화 대상으로서 사라진다. Kubernetes API가 인터페이스다. 네트워크 정책은 장치 설정이 아닌 코드다. 이것이 다른 플랫폼들이 수렴하는 모델이다: 선언적 의도, 컨트롤러 조정 상태, 직접적인 장치 접근 없음.
DPU와 SmartNIC (Nvidia BlueField, Intel IPU, Marvell Octeon)은 네트워크 처리가 일어나는 위치의 이동을 나타낸다. 현대 데이터 센터에서 DPU는 네트워크 기능을 오프로드하기 위해 모든 서버의 CPU 옆에 설치된다: VXLAN 인캡슐레이션, 암호화, 방화벽 정책 시행, 로드 밸런싱, 마이크로세그멘테이션. 이는 이러한 기능을 호스트 CPU와 네트워크 어플라이언스에서 SmartNIC 펌웨어로 오프로드한다. 자동화에 대한 결과: “네트워크 장치"는 더 이상 랙의 스위치나 라우터만이 아니다. 이전에 전용 네트워크 어플라이언스 API를 통해 관리되던 기능은 이제 DPU 관리 플레인과 벤더 SDK를 통해 관리되며, 이는 표준 NETCONF와 gRPC Network Management Interface (gNMI) 툴링이 아직 깨끗하게 도달하지 못하는 새로운 인터페이스 범주다.
오픈 네트워킹 (SONiC, DENT, OPX)은 범용 하드웨어에서 Network Operating System (NOS) 소프트웨어를 실행한다. SONiC의 설정 인터페이스는 Yet Another Next Generation (YANG) 구조 스키마를 가진 Redis 데이터베이스로, CLI나 NETCONF와 구조적으로 다르며 설계상 프로그래매틱하다. 하이퍼스케일러 영향을 받은 데이터 센터와 대규모 엔터프라이즈 DC 배포에서 점점 더 많이 나타나고 있다. SONiC은 처음부터 자동화를 위해 설계되었기 때문에 주목할 만하다: 인터페이스는 프로그래매틱 접근에 적응된 CLI가 아닌 구조화된 데이터베이스다.
가상 네트워크 함수는 많은 환경에서 물리적 인프라와 공존한다. 정책 정의 경로를 통해 트래픽을 삽입하는 소프트웨어 방화벽, 애플리케이션 클러스터 전반에 걸쳐 트래픽 배포를 관리하는 가상 로드 밸런서, 소프트웨어 기반 BGP 라우트 리플렉터: 이들은 모두 벤더 REST API부터 NETCONF까지 다양한 관리 인터페이스를 사용하는 자동화 대상이다. 이들은 종종 동일한 SoT와 Executor를 사용하여 물리적 인벤토리와 함께 관리되지만, 인터페이스 모델이 물리적 장치와 다르기 때문에 별도의 어댑터 경로가 필요하다.
무선 컨트롤러 (Cisco DNA, Aruba Central, Juniper Mist)는 컨트롤러 기반이며, 자동화 대상은 컨트롤러 API다. VLAN 프로비저닝이 유선 스위치 포트와 함께 무선 SSID까지 확장될 때마다 관련이 있다(캠퍼스 시나리오에서처럼).

핵심은 모든 인프라 유형을 빠짐없이 열거하는 것이 아니다. 비정형적인 네트워크를 자동화하는 플랫폼은 여러 유형과 동시에 상호작용한다는 것을 확립하는 것이다. Executor와 Collector는 각 작업을 올바른 인터페이스 유형으로 라우팅해야 한다. Source of Truth (SoT)는 개별 인터페이스보다 높은 수준에서 의도를 모델링해야 한다. 네트워크의 복잡성은 플랫폼이 수용하도록 구축된 설계 제약이다.

9.2.1.2. 인터페이스 유형#

각 인프라 유형은 자동화 플랫폼에 하나 이상의 인터페이스 유형을 노출한다. 동일한 물리적 스위치가 세 가지 모두를 동시에 노출할 수 있다. 플랫폼은 사용 가능한 것에 적응하며, 신뢰성, 구조, 규모를 반영하는 선호도를 가진다. 어떤 인터페이스 유형도 보편적인 명령이 아니다; 올바른 선택은 장치가 지원하는 것과 작업이 요구하는 것에 따라 다르다.

Secure Shell (SSH)를 통한 Command Line Interface (CLI)는 보편적이고, 레거시이며, 취약하다. 화면 스크레이핑과 텍스트 파싱은 펌웨어가 출력 형식을 변경하거나 새 필드를 추가할 때 중단된다. 오류 코드는 벤더 간, 펌웨어 버전 간에 일관성이 없다. CLI는 여전히 구형 장비에서 유일한 옵션이다. 권장 사항은 사용을 최소화하고 대안이 없는 장치(최후의 수단)에 의존하는 워크플로우 구축을 피하는 것이다. 인터페이스 설명 설정은 다음과 같다:

interface GigabitEthernet0/1
 description uplink-to-core

NETCONF는 구조화되어 있고, 트랜잭션 방식이며, 작동할 때는 정확하다. 원자 작업과 롤백을 지원하며, 데이터 모델은 기계로 파싱 가능하다. 전송 계층은 일반적으로 신뢰할 수 있다; 데이터 모델 계층이 격차가 있는 곳이다. 벤더 YANG 모델 품질은 크게 다양하다: 장치가 NETCONF 지원을 주장할 수 있지만 플랫폼에 필요한 기능에 대해 불완전하거나 독점 모델을 가질 수 있다. IETF와 OpenConfig YANG 모델은 의도 계층을 표준화하며, 벤더 네이티브 YANG 모델이 격차를 채운다. NETCONF를 통한 동일한 인터페이스 설명:

<config>
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>GigabitEthernet0/1</name>
      <description>uplink-to-core</description>
    </interface>
  </interfaces>
</config>

RESTCONF는 NETCONF의 HTTP 기반 동등물로, 동일한 YANG 모델을 사용하지만 REST 의미론으로 노출한다. NETCONF의 XML/SSH 전송보다 HTTP 툴링에 더 편안한 팀에게 유용하다. 데이터 모델은 동일하고, 전송만 다르다. 벤더 지원은 NETCONF보다 덜 균일하다. RESTCONF를 통한 동일한 인터페이스 설명:

PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1
Content-Type: application/yang-data+json

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet0/1",
    "description": "uplink-to-core"
  }
}

gRPC Network Management Interface (gNMI)와 gNOI는 gRPC Remote Procedure Call (gRPC) 기반 프로토콜이다. gRPC Network Management Interface (gNMI)는 텔레메트리와 설정 읽기/쓰기를 처리하며, gNOI는 운영 명령을 처리한다. 현대적이고 규모 친화적이다. 벤더 지원은 Arista와 최신 Cisco 플랫폼에서 성숙해 있으며, HPE와 레거시 장비에서는 불균일하다. 챕터 6은 Collector의 관점에서 gNMI를 다루었다. 챕터 9는 장치 측 전제 조건을 다룬다: 장치는 플랫폼이 대상으로 하는 OS 버전에서 gNMI 구독을 지원해야 한다. SONiC을 실행하는 Nvidia Spectrum 스위치는 CONFIG_DB 인터페이스와 함께 기본적으로 gNMI를 노출하여 설정과 텔레메트리 모두에 대해 가장 자동화 친화적인 플랫폼 중 하나다. gNMI SetRequest를 통한 동일한 인터페이스 설명:

path:  /interfaces/interface[name=GigabitEthernet0/1]/config/description
value: "uplink-to-core"

벤더 REST API (eAPI, NX-API, Cumulus NVUE 및 유사한 것들)는 기계로 읽을 수 있지만 벤더 간에 표준화되어 있지 않다. 특정 작업에 대해 NETCONF나 gNMI가 없거나 불완전할 때 격차를 채우는 용도로 유용하다. Nvidia Cumulus 스위치는 NVUE(일관된 JSON 스키마를 가진 구조화된 REST API)를 기본 프로그래매틱 인터페이스로 노출한다; Arista와 Cisco Nexus는 각각 eAPI와 NX-API를 NETCONF의 대안으로 노출한다. 이를 벤더 중립 플랫폼의 기반이 아닌 어댑터 계층 관심사로 취급하라. Arista eAPI(HTTPS를 통한 JSON-RPC)를 통한 동일한 인터페이스 설명:

{
  "jsonrpc": "2.0",
  "method": "runCmds",
  "params": {
    "version": 1,
    "cmds": [
      "interface GigabitEthernet0/1",
      "description uplink-to-core"
    ],
    "format": "json"
  },
  "id": "1"
}

클라우드 및 컨트롤러 API는 최종 일관성을 가진 REST 패턴을 따른다. 비동기 작업 모델은 극복해야 할 제한이 아닌 설계 요구 사항이다. SD-WAN, 무선, DPU 관리 플레인의 경우 컨트롤러 API가 종종 유일한 사용 가능한 인터페이스다. AWS VPC에 설명을 추가하는 것은 패턴을 보여준다: 비동기적으로 제출되며 변경이 적용되었다는 동기 확인이 없는 태그된 리소스 업데이트:

POST https://ec2.eu-west-1.amazonaws.com/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AWS4-HMAC-SHA256 ...

Action=CreateTags
&ResourceId.1=vpc-0a1b2c3d4e5f67890
&Tag.1.Key=Description
&Tag.1.Value=uplink-to-core
&Version=2016-11-15

Kubernetes API는 선언적이고, 컨트롤러 조정 방식이며, 벤더 간에 일관성이 있다. NetworkPolicy, Services, CNI 커스텀 리소스가 자동화 대상이다. 직접적인 장치 접근이 없으며, API 서버가 유일한 인터페이스다. app-payments 서비스에 대한 네트워크 격리 정책:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-payments-isolation
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: app-payments
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: app-payments

**SONiC CONFIG_DB (Redis)**는 SONiC 기반 플랫폼의 기본 인터페이스다. OS 위에 계층화된 프로토콜이 아니라 OS 자체의 설정 저장소: YANG 구조 스키마를 가진 Redis 데이터베이스다. 자동화는 JSON 항목을 CONFIG_DB에 직접 쓰며, SONiC의 내부 orchagent 데몬이 의도를 하드웨어 포워딩 테이블에 조정한다. gNMI는 텔레메트리 읽기를 위해 병렬로 사용할 수 있다. 이는 CLI, NETCONF, REST와 구조적으로 다르다: 인터페이스가 데이터 저장소 자체다. 섹션 9.2.3.4는 이를 더 깊이 다룬다. config load로 적용된 JSON 패치를 통해 CONFIG_DB에 쓰여진 동일한 인터페이스 설명:

{
  "PORT": {
    "Ethernet0": {
      "description": "uplink-to-core",
      "admin_status": "up"
    }
  }
}

9.2.1.3. 장치별 인터페이스 선택#

장치가 여러 인터페이스를 노출할 때 플랫폼은 작업 유형별로 하나를 선택하고 그 선택을 일관되게 유지해야 한다. Command Line Interface (CLI), NETCONF, gRPC Network Management Interface (gNMI)를 동시에 노출하는 캠퍼스 스위치는 워크플로우나 엔지니어 선호도에 따라 달라지는 혼합 사용 방식이 아닌 결정이 필요하다.

작업 유형별로 적용되는 권장 계층 구조. gRPC Network Management Interface (gNMI)와 NETCONF 모두 설정 쓰기와 텔레메트리 읽기를 지원하며, 아래의 선호도는 프로토콜 독점성이 아닌 운영 강점을 반영한다:

텔레메트리 수집에 gRPC Network Management Interface (gNMI) 선호 (스트리밍 구독, 구조화, 규모 친화적; gNMI Set도 유효한 설정 경로)
설정에 NETCONF 선호 (트랜잭션, 롤백 가능; NETCONF get 및 get-config도 상태 읽기에 동등하게 유효)
특정 기능에 대해 NETCONF가 불완전한 경우 폴백으로 RESTCONF 또는 벤더 REST API
레거시 장비에만 최후의 수단으로 Command Line Interface (CLI)

Executor가 인터페이스에서 필요로 하는 것: Idempotency, 또는 최소한 “이미 존재함"과 “실패함"을 구분하는 신뢰할 수 있는 오류 코드, 구조화된 오류 응답, 적용 후 상태 검증 기능. HPE vlan-exists 대 duplicate-vlan 문제는 정확히 두 번째 조건의 실패였다: 오류 코드 의미론이 펌웨어 버전 간에 변경되었다.

Collector가 필요로 하는 것: 구조화된 읽기, 스트리밍 텔레메트리 구독, 그리고 관찰 가능성 계층이 장치별 파서가 필요 없도록 일관된 데이터 모델. gRPC Network Management Interface (gNMI)는 지원되는 경우 선호하는 구독 프로토콜이다: 구조화되어 있고, 계층적이며, 장치에서 스키마 검증되어 SNMP 시대 수집을 지배했던 장치별 텍스트 파싱을 제거한다. 하지만 구조화되고 적시에 데이터를 제공하는 모든 구독 메커니즘이 동일한 기능을 수행한다. SNMP 폴링은 gNMI를 사용할 수 없는 레거시 장치에 유효하다. Syslog 피드는 로그 기반 관찰 가능성을 위한 구조화된 이벤트를 제공한다. OpenTelemetry(OTel)는 주목할 만한 신흥 표준이다: 원래 애플리케이션 관찰 가능성을 위해 설계되었지만, 네트워크 텔레메트리, 메트릭, 추적을 위한 벤더 중립 전송으로 채택이 늘고 있다. Collector의 프로토콜 선택은 장치가 지원하는 것의 함수다; 관찰 가능성 계층은 어떤 전송이 사용되었는지 알 필요가 없어야 한다.

Source of Truth (SoT)는 플랫폼이 운영하는 모든 장치 속성에 대한 의도된 상태를 기록한다: 의도된 VLAN 설정, 의도된 BGP 이웃 관계, 의도된 인터페이스 설명, 그리고 의도된 OS 버전. OS 버전은 설정 드리프트 감지뿐만 아니라 어댑터 경로 선택 자체에도 영향을 미치기 때문에 여기서 특별히 언급할 가치가 있다: 동일한 벤더의 펌웨어가 릴리스 간에 다르게 동작할 때 Executor는 OS 버전별로 분기한다. 이것은 OS 버전에 대한 특수 경우가 아니다; 플랫폼이 관리하는 모든 속성에 적용되는 동일한 의도 대 현실 패턴이다. 원하는 OS 버전은 운영 팀이 승인한 것이고, 실행 중인 버전은 관찰 가능성이 관찰하는 것이다. 이들이 발산할 때 그 발산은 신호다: 장치가 계획된 업그레이드에 뒤처져 있거나 계획되지 않은 변경이 발생했다. 플랫폼은 계속할지 차단할지 결정하기 위해 두 데이터 포인트가 필요하다.

이 구분은 실제로 중요하다. SoT는 장치가 AOS-CX 10.13을 실행해야 한다고 말한다. Collector는 10.12.1006을 실행 중이라고 보고한다. 플랫폼은 두 가지 옵션이 있다: OS 버전이 조정될 때까지 실행을 차단하거나, 10.12 어댑터 경로를 사용하여 진행한다. 올바른 답은 팀의 변경 관리 정책에 따라 다르지만, 플랫폼은 결정을 내리기 위해 두 데이터 포인트가 필요하다. SoT는 의도를 제공하고, 관찰 가능성은 현실을 제공한다.

9.2.2. 시뮬레이션 및 테스팅 환경#

네트워크는 프로덕션 인프라다. 애플리케이션 백엔드와 달리 기본적으로 테스트할 스테이징 서버가 없다. 하나를 구축하는 것이 이 기능의 역할이다.

네트워크 자동화를 테스트하는 것은 항상 애플리케이션 코드 테스트보다 어려웠다. 네트워크는 자동화 팀이 제어하지 않는 많은 구성 요소가 있는 분산 시스템이다: 피어링 포인트의 인접 AS, 업스트림 트랜짓 프로바이더, 고객 관리 CPE, 무선 클라이언트, 타사가 운영하는 클라우드 인프라. 라우팅 정책 변경을 테스트하는 서비스 프로바이더는 전체 동작을 검증하기 위해 트랜짓 프로바이더의 모의 BGP 피어를 가동할 수 없다. WAN 페일오버 워크플로우를 테스트하는 엔터프라이즈는 MPLS 프로바이더가 어떻게 반응하는지 제어할 수 없다. 이 섹션에서 설명하는 시뮬레이션 환경은 사용 가능한 최선의 대안이다: 팀이 제어하는 것을 재현하고, 제어할 수 없는 것의 한계를 수용하며, 버그가 실제로 존재하는 로직 계층의 검증에 집중한다.

챕터 2의 테스팅 피라미드(단위, 통합, 엔드투엔드)는 여기에 직접 적용된다. 단위 테스트는 일반적으로 모의 장치 응답으로 격리된 개별 자동화 모듈을 검증한다. 통합 테스트는 다단계 상호작용을 검증한다: SoT API가 예상 데이터 구조를 반환하는지, Executor가 올바르게 변환하는지, 장치 응답이 올바르게 처리되는지. 엔드투엔드 테스트는 실제 네트워크 장치처럼 동작하는 것을 대상으로 전체 워크플로우를 검증한다. 시뮬레이션 환경은 엔드투엔드 계층이다.

9.2.2.1. 환경 유형#

올바른 환경은 테스트에서 무엇을 검증해야 하는지에 따라 다르다. 일상적인 CI/CD 파이프라인에 적합한 저충실도, 저비용 환경부터 프로덕션 신뢰도 테스트에 투자할 가치가 있는 고충실도 환경까지 스펙트럼이 있다.

환경 유형	시작 시간	컨트롤 플레인	데이터 플레인	CI/CD 적합성	사용 시기
컨테이너 기반 에뮬레이션	초 단위	예	아니오	기본	자동화 로직, 인터페이스 계약 검증, 워크플로우 테스트
VM 기반 에뮬레이션	분 단위	예	예	제한적	프로토콜 상호 운용성, 설계 검증, 전체 NOS 동작 테스트
물리적 하드웨어 랩	해당 없음 (항상 켜져 있음)	예	예	수동	하드웨어별 동작, 성능 테스트, 에뮬레이션으로 불가능한 시나리오
디지털 트윈	지속적 동기화	예	구현에 따라 다름	커스텀	프로덕션 충실도 테스트; 실제 프로덕션 토폴로지와 상태에 대해 자동화 검증

컨테이너 기반 에뮬레이션은 가상 링크로 연결된 컨테이너로 실행되는 경량 네트워크 OS 이미지를 사용한다. 토폴로지 시작에 초가 걸린다. 일상적인 CI/CD의 실용적인 기본값이다: 자동화 팀은 모든 변경 사항에 대해 컨테이너화된 토폴로지에 대해 동일한 워크플로우 코드를 실행하여 프로덕션 전에 로직 오류를 잡는다. 데이터 플레인 동작은 복제되지 않지만, 컨트롤 플레인 동작과 관리 인터페이스 동작은 자동화 로직 테스트에 충분하다.
VM 기반 에뮬레이션은 가상 머신으로 전체 NOS 이미지를 실행한다. 더 광범위한 벤더 커버리지, 데이터 플레인을 포함한 더 현실적인 NOS 동작을 제공하며, 프로토콜 설계 테스트와 멀티벤더 상호 운용성 시나리오에 적합하다. 트레이드오프: 더 높은 리소스 비용, 느린 시작, 자동화된 파이프라인과의 제한된 통합. 일상적인 커밋 레벨 테스트에는 실용적이지 않다.
물리적 하드웨어 랩은 많은 대규모 조직에서 유지 관리한다: 실제 스위치와 라우터의 랙, 종종 프로덕션 아키텍처 패턴을 반영한다. 하드웨어별 동작, 성능 테스트, 에뮬레이션이 장치 동작을 정확하게 재현하지 못하는 시나리오에 대해 최고의 충실도를 제공한다. 비용이 상당하다: 자본 투자, 전력과 공간, 랩 토폴로지를 프로덕션 아키텍처와 동기화 상태로 유지하는 운영 오버헤드. 프로덕션 패턴에서 벗어난 랩은 거짓 확신을 제공한다. 가치는 실재한다; 유지 관리 규율이 과제다.
디지털 트윈은 소스 오브 트루스(동일한 장치 모델, 토폴로지, 현재 의도된 설정)와 관찰 가능성의 현재 상태가 공급되는 프로덕션 토폴로지의 실시간 복제본이다. 디지털 트윈은 근사치가 아닌 현재 프로덕션이 실제로 어떻게 생겼는지를 반영한다. 운영 비용이 상당하다: 디지털 트윈과 프로덕션 간의 동기화를 유지하려면 지속적인 조정이 필요하다. 이미 플랫폼을 규모에서 검증했고 최고 수준의 사전 프로덕션 신뢰도가 필요한 팀에게 적합한 성숙도 수준 투자다.

컨테이너 기반 에뮬레이션은 대부분의 팀에게 실용적인 시작점이다. 초 단위로 시작되고, CI/CD 파이프라인과 기본으로 통합되며, 대부분의 자동화 사용 사례에서 사용되는 최신 캠퍼스 및 데이터 센터 장비를 지원한다. 이 환경 구축에 대한 투자는 처음 방지하는 인시던트에서 회수된다.

9.2.2.2. 컨테이너 기반 및 VM 기반 에뮬레이션의 툴체인#

컨테이너 기반 생태계는 종종 혼동되는 별도의 역할을 가진 여러 도구가 있다:

**containerlab**은 컨테이너 기반 네트워크 OS 이미지를 인스턴스화하고 연결한다. Roman Dodin이 만들고 네트워크 자동화 커뮤니티에서 널리 채택된 containerlab은 컨테이너 기반 네트워크 랩의 사실상 표준이 되었다. Docker 컨테이너(Arista cEOS, FRR, SONiC, VyOS 등)를 직접 오케스트레이션하고 토폴로지 파일에 정의된 가상 링크로 연결한다. containerlab은 토폴로지를 시작하고 초 단위로 실행 중인 랩을 제공한다. 최소한의 세 노드 토폴로지 파일은 다음과 같다:
팀이 확장함에 따라 단일 머신에서 containerlab을 실행하는 것이 병목 현상이 된다. clabernetes는 Kubernetes 클러스터 전반에 걸쳐 containerlab 토폴로지를 배포하여 여러 시뮬레이션 실행을 병렬로 가능하게 하고 플랫폼이 성장함에 따라 팀이 사전 프로덕션 게이트를 확장할 수 있게 한다.

name: building-b-sim
topology:
  nodes:
    cisco-1:
      kind: ceos
      image: ceos:17.9.4
    arista-1:
      kind: ceos
      image: ceos:4.31.2F
    hpe-1:
      kind: vr-aoscx
      image: vrnetlab/vr-aoscx:10.12.1006
  links:
    - endpoints: ["cisco-1:eth1", "arista-1:eth1"]
    - endpoints: ["arista-1:eth2", "hpe-1:eth1"]

**netlab**은 containerlab 위에서 토폴로지 정의를 추상화한다. Ivan Pepelnjak이 만든 netlab은 엔지니어가 어떻게 연결할지가 아니라 토폴로지가 무엇을 달성해야 하는지를 설명할 수 있게 한다: “이 세 노드는 BGP를 실행한다”, “이 노드들은 동일한 VLAN에 있다”. netlab은 그 설명을 해석하여 containerlab 토폴로지 파일과 벤더별 초기 장치 설정으로 렌더링한다. 랩의 선언적 설명으로 생각하라: 엔지니어가 서비스를 정의하고, netlab이 인프라 정의를 생성한다. 프로덕션 네트워크 모델을 반영하는 토폴로지에 대해 자동화 로직을 테스트하는 것이 목표라면, netlab이 올바른 시작점이고 containerlab이 그것을 인스턴스화한다. 동일한 세 노드 시나리오에 대한 최소 netlab 토폴로지:

nodes:
  cisco-1:
    device: iosxe
    image: ceos:17.9.4
  arista-1:
    device: eos
  hpe-1:
    device: aoscx

links:
  - cisco-1:
    arista-1:
  - arista-1:
    hpe-1:

vlans:
  app-payments:
    id: 210
    links: [ cisco-1, arista-1, hpe-1 ]

**vrnetlab**은 컨테이너 기반과 VM 기반 에뮬레이션 사이를 연결한다. 일부 벤더는 기본 컨테이너 이미지를 제공하지 않는다. vrnetlab은 컨테이너 내에 벤더 VM 이미지를 래핑하여 VM 기반 플랫폼으로 전환하지 않고도 containerlab 토폴로지 내에서 사용할 수 있게 한다. 이것이 containerlab 환경에서 Cisco IOS-XR 또는 Junos 장치를 대상으로 테스트하는 방법이다.
**EVE-NG**와 **GNS3**는 광범위한 벤더 커버리지, GUI 기반 토폴로지 설계, 데이터 플레인 포워딩을 포함한 전체 NOS 동작을 제공하는 VM 기반 에뮬레이션 플랫폼이다. 트레이드오프: 더 높은 리소스 사용, 느린 시작, 제한된 CI/CD 통합. 프로토콜 및 설계 테스트, 레거시 플랫폼, 멀티벤더 상호 운용성 시나리오에 올바른 선택이다.
**Cisco Modeling Labs**는 관리되는 공유 랩에서 IOS-XE, IOS-XR, NX-OS VM에 대한 접근이 필요한 Cisco 중심 환경에 적합한 부분적 CI/CD 통합을 위한 REST API를 갖춘 Cisco의 상업용 VM 랩 플랫폼이다.

9.2.2.3. 검증 프레임워크#

장치가 주어진 인터페이스 프로토콜이나 YANG 경로를 올바르게 지원하는지 검증하는 것은 챕터 5(실행)와 챕터 6(관찰 가능성)에서 설명한 작업의 일부다: 실행 챕터는 프로덕션 워크플로우에 의존하기 전에 설정 인터페이스를 검증하는 것을 다루고, 관찰 가능성 챕터는 수집 경로를 검증하고 구독이 예상 형식으로 데이터를 반환하는지 확인하는 것을 다룬다.

시뮬레이션 컨텍스트에서 특별한 처리를 필요로 하는 하나의 시나리오가 있다: 웨이브 검증. 시뮬레이션이 통과되지만 전체 프로덕션 범위로 커밋하기 전에 일부 팀은 첫 번째 웨이브에 대해 구조화된 검증 패스를 실행한다. **pyATS**는 풍부한 파싱과 상태 비교를 갖춘 구조화된 장치 상호작용 테스트를 작성하기 위한 테스트 프레임워크를 제공한다. **Robot Framework**는 네트워크별 라이브러리를 갖춘 더 광범위한 키워드 기반 테스트 자동화 프레임워크다. 둘 다 팀이 예상 변경 후 상태를 실행 가능한 어설션으로 인코딩할 수 있게 한다: VLAN 210이 Wave 1에 배포된 후, 모든 스위치에 VLAN 210이 존재하는지 확인하고, 인터페이스 연관이 올바른지 확인하고, 관찰 가능성 계층이 예상 상태를 보는지 확인한다. 이는 섹션 9.2.2.4에 직접 연결된다: 통과하는 시뮬레이션 실행을 다음 웨이브로 진행하기 전에 진정한 운영 신뢰도와 분리하는 구조화된 검증 계층.

배포 후 VLAN 존재를 어설션하는 최소 pyATS 테스트:

from pyats import aetest

class VlanValidation(aetest.Testcase):
    @aetest.test
    def verify_vlan_exists(self, device):
        output = device.parse('show vlan brief')
        assert 210 in output['vlans'], f"VLAN 210 missing on {device.name}"

    @aetest.test
    def verify_vlan_name(self, device):
        output = device.parse('show vlan brief')
        assert output['vlans'][210]['name'] == 'app-payments'

명시적인 설정과 읽기 가능한 키워드 이름으로 NAPALM 라이브러리를 사용하는 Robot Framework의 동일한 검사:

*** Settings ***
Library    Collections
Library    napalm    WITH NAME    NAPALM

*** Variables ***
@{DEVICES}    cisco-1    arista-1    hpe-1

*** Test Cases ***
VLAN 210 Is Present On All Switches After Deployment
    FOR    ${hostname}    IN    @{DEVICES}
        Connect And Check VLAN    ${hostname}    210    app-payments
    END

*** Keywords ***
Connect And Check VLAN
    [Arguments]    ${hostname}    ${vlan_id}    ${vlan_name}
    NAPALM.Open    ${hostname}
    ${vlans}=    NAPALM.Get VLANs
    Dictionary Should Contain Key    ${vlans}    ${vlan_id}
    Should Be Equal    ${vlans}[${vlan_id}][name]    ${vlan_name}
    [Teardown]    NAPALM.Close

9.2.2.4. 사전 프로덕션 Saga 게이트로서의 시뮬레이션#

챕터 7은 Saga 패턴을 설명했다: 각 단계가 나중 단계가 실패할 경우 실행되는 해당 보상 액션을 가지는 다단계 워크플로우. Saga는 프로덕션의 실패를 처리한다. 시뮬레이션은 Saga가 시작하기 전의 단계를 추가한다: 먼저 시뮬레이션 환경에 대해 워크플로우를 실행한다. 시뮬레이션 실행이 실패하면 프로덕션 변경이 발생하지 않는다. 시뮬레이션이 통과될 때만 워크플로우가 프로덕션 대상으로 진행된다.

flowchart LR
    SoT["SoT 내보내기 (토폴로지 + OS 버전)"]
    Lab["시뮬레이션 환경 (containerlab 토폴로지)"]
    Workflow["워크플로우 실행 (프로덕션과 동일한 코드)"]
    Pass{통과?}
    Prod["프로덕션 실행 (Orchestrator: 전체 범위)"]
    Fix["조사 및 수정 (프로덕션 영향 없음)"]

    SoT --> Lab --> Workflow --> Pass
    Pass -- 예 --> Prod
    Pass -- 아니오 --> Fix --> Workflow

이것이 사전 프로덕션 게이트다: 프로덕션 Saga 범위가 시작되기 전 첫 번째 검사로서의 시뮬레이션. 시뮬레이션에서의 실패는 프로덕션 장치에 닿기 전에 잡힌다.

실용적인 구현:

소스 오브 트루스는 장치별 OS 버전을 포함하여 대상 범위에 대한 토폴로지 정의를 내보낸다.
시뮬레이션 환경은 일치하는 벤더 이미지로 인스턴스화되며, OS 버전은 SoT 의도 상태와 일치하도록 고정된다.
프로덕션에서 실행될 동일한 워크플로우가 먼저 시뮬레이션 대상에 대해 실행된다.
시뮬레이션에서 실패하는 모든 단계는 프로덕션 실행이 진행되기 전에 조사를 트리거한다.

점진적 롤아웃 웨이브

시뮬레이션 통과가 전체 프로덕션 범위에 한꺼번에 배포하는 것을 의미하지 않는다. 대규모 롤아웃의 경우, 시뮬레이션은 각 웨이브가 다음으로 진행하기 전에 자체 검증 검사가 있는 점진적으로 더 큰 웨이브 시리즈의 첫 번째 게이트다. 이것은 소프트웨어 개발의 인기 있는 카나리(Canary) 패턴과 유사한, 중요한 배포에 대한 신뢰를 쌓는 내가 가장 좋아하는 패턴 중 하나다.

100개 데이터 센터에 새 워크플로우를 배포하는 팀은 다음과 같이 구성할 수 있다: 시뮬레이션(가상 토폴로지) → 파일럿 사이트 1개 → 2개 사이트 → 4개 → 8개 → 16개 → 나머지 사이트. 각 웨이브는 확장하기 전에 이전 웨이브에서 워크플로우가 올바르게 동작했는지 검증한다. 웨이브 4에서 시뮬레이션이 잡지 못한 실패가 발생하면(하드웨어별 동작, 사이트별 상태), 롤아웃이 멈추고 이슈가 수정되며 웨이브 순서가 실패 지점에서 재개된다.

flowchart LR
    Sim["시뮬레이션"] --> W1["웨이브 1 (사이트 1개)"] --> W2["웨이브 2 (사이트 2개)"] --> W3["웨이브 3 (사이트 4개)"] --> W4["웨이브 N (전체 범위)"]
    W1 -- 실패 --> Fix["조사 + 수정"]
    W2 -- 실패 --> Fix
    W3 -- 실패 --> Fix
    Fix --> Sim

Orchestrator가 웨이브 진행을 제어한다. SoT는 사이트, 빌딩, 또는 장치 그룹별로 각 웨이브의 범위를 지정한다. 웨이브 간 검증 게이트는 명시적인 워크플로우 단계다: Orchestrator는 진행하기 전에 예상 상태에 대해 관찰 가능성 계층을 확인한다. 이 패턴은 범위가 100개 데이터 센터이든 캠퍼스 스위치 800개이든 적용된다: 원칙은 각 성공적인 웨이브로 신뢰를 쌓으면서 예상치 못한 실패의 영향 반경을 제한하는 것이다.

점진적 롤아웃은 의도적으로 느리다. 각 웨이브는 시간을 추가한다: 검증 결과를 기다리고, 실패를 검토하고, 진행 여부를 결정한다. 한꺼번에 모든 것을 배포하는 데 익숙한 팀에게는 첫 번째 웨이브가 모든 스위치 800개에 동시에 영향을 미쳤을 버그를 잡을 때까지 속도가 과도하게 느껴진다. 느리고 확실한 것이 빠르고 잘못된 것보다 낫다.

시뮬레이션의 한계: 컨테이너 이미지는 모든 펌웨어 동작을 재현하지 않는다. 컨테이너 이미지는 일반적으로 최신 NOS 코드를 실행하며, 이미지가 특정 버전으로 고정되지 않는 한 오래된 펌웨어별 특이 동작은 재현되지 않을 수 있다. 시뮬레이션은 로직 오류, 인터페이스 계약 위반, Yet Another Next Generation (YANG) 모델 격차, 그리고 토폴로지 레벨 실패를 잡는다. 프로덕션에서 발생할 수 있는 모든 장치 상태가 테스트되었다고 보장하지 않는다. 목표는 완전한 위험 제거가 아니라 상당한 위험 감소다.

스노우플레이크 문제: 시뮬레이션은 프로덕션 네트워크가 일관된 아키텍처 패턴을 따를 때 가장 신뢰할 수 있다. 각각 고유한 상태와 역사를 가진 수백 개의 개별적으로 커스터마이즈된 설정을 가진 네트워크는 시뮬레이션에서 정확하게 나타내기가 더 어렵다. 이것이 자동화 아키텍처 원칙(표준화된 설계 패턴, 황금 템플릿, SoT 기반 설정)이 테스트를 더 효과적으로 만드는 이유 중 하나다: 잘 설계된 네트워크는 더 시뮬레이션 가능하다. 시뮬레이션의 가치는 그것이 나타내는 네트워크 설계의 품질과 함께 증가한다. 이 반복성을 구축하려면 자동화 엔지니어만이 아닌 네트워크 엔지니어와의 긴밀한 협력이 필요하다: 어느 사이트가 진정으로 동일하고 어느 것이 숨겨진 예외를 가지는지 이해하는 네트워크 엔지니어가 시뮬레이션을 대표적으로 만들 수 있다. 시뮬레이션 품질은 네트워크 설계 규율과 자동화 플랫폼의 공동 산출물이다.

9.2.3. 추상화 전략#

네트워크는 본질적으로 이기종이며, 단순히 벤더가 다르다는 의미만이 아니다. 규모에서 운영되는 모든 자동화 플랫폼은 물리적 스위칭, 클라우드 인프라, 오버레이 컨트롤러, 서비스 프로바이더 WAN 인프라, 레거시 장비를 동시에 다룬다. 각각 다른 언어를 사용한다. 자동화 플랫폼은 새로운 인프라 유형이 추가될 때마다 재구축되어서는 안 된다.

이 섹션은 변화로 인해 무너지는 것이 아니라 변화를 수용하도록 자동화 계층을 설계하는 것에 관한 것이다: 단순히 오늘날의 이기종 환경을 처리하는 것이 아니라 내년에 추가될 인프라 유형을 위해 설계하는 것이다.

현대 자동화 플랫폼은 여러 인프라 도메인에 걸쳐 동시에 운영된다. 이를 깔끔하게 처리하는 아키텍처는 운영자가 대규모 엔터프라이즈이든, WAN과 고객 엣지를 동시에 관리하는 서비스 프로바이더이든, 클라우드 네트워킹 오버레이와 함께 데이터 센터 패브릭을 운영하는 하이퍼스케일러이든 적용된다. 핵심 사항: Executor는 쓰고 Collector는 동일한 장치 인터페이스(물리적 장비에는 gRPC Network Management Interface (gNMI)/NETCONF, 클라우드와 컨트롤러에는 REST)를 통해 읽기 때문에 인터페이스 프로토콜은 블록별로 별도의 설계 선택이 아닌 두 블록의 공유 관심사다.

flowchart LR
    SoT["Source of Truth"]
    Orch["Orchestrator"]
    Obs["Observability"]

    subgraph Physical["물리 도메인"]
        PhysIF["네트워크 인터페이스 (NETCONF/gNMI)"]
        PhysNet["캠퍼스, DC 패브릭, WAN 장비"]
        PhysIF --- PhysNet
    end

    subgraph Cloud["클라우드 도메인"]
        CloudIF["네트워크 인터페이스 (비동기 REST)"]
        CloudNet["클라우드 VPC / 네트워킹"]
        CloudIF --- CloudNet
    end

    subgraph Overlay["오버레이 도메인"]
        OvIF["네트워크 인터페이스 (컨트롤러 API)"]
        OvNet["SD-WAN / MPLS PCE / 오버레이"]
        OvIF --- OvNet
    end

    SoT --> Orch
    Orch -->|Executor 쓰기| PhysIF
    Orch -->|Executor 쓰기| CloudIF
    Orch -->|Executor 쓰기| OvIF
    PhysIF -->|Collector 읽기| Obs
    CloudIF -->|Collector 읽기| Obs
    OvIF -->|Collector 읽기| Obs

소스 오브 트루스는 통합 서비스 모델로서 모든 토폴로지 유형에 걸쳐 전체 의도를 모델링한다. Orchestrator는 네트워크 도메인별 분기를 포함한다. Executor는 SoT 데이터에 기반하여 올바른 어댑터로 라우팅한다. 관찰 가능성은 모든 계층에 걸쳐 있으며, 기반 인프라 유형에 관계없이 동일한 데이터 파이프라인에 공급한다.

핵심 아키텍처 규율: 분기는 SoT가 아닌 Executor와 Orchestrator에서 발생한다. SoT는 서비스에 대한 단일 의도 모델을 보유한다. 그 의도가 서로 다른 인프라 유형에서 어떻게 실현되는지는 Executor의 관심사다.

9.2.3.1. 이기종성의 차원#

추상화 전략을 선택하기 전에, 해당 전략이 수용해야 하는 이기종성의 축을 이해하는 것이 도움이 된다. 모든 이기종성이 동일한 종류의 문제는 아니다.

차원	무엇이 다른가	플랫폼 설계 대응
멀티벤더 물리	CLI 구문, YANG 모델, 오류 코드가 벤더별로 다름	어댑터 패턴: 벤더당 하나의 모듈, SoT에서 동일한 입력 스키마
펌웨어 세대 (동일 벤더)	벤더 이름을 변경하지 않고 OS 버전 간에 인터페이스 동작이 변경	SoT는 의도된 OS 버전을 추적; Executor는 동작이 다른 경우 버전별로 분기
물리 vs. 클라우드	물리: 동기 적용. 클라우드: 비동기 REST, 최종 일관성	Executor는 인프라 유형별로 작업 모델을 처리; SoT는 통합 의도 유지
물리 vs. 오버레이	SD-WAN/EVPN 컨트롤러는 물리적 언더레이를 추상화; 자동화 대상은 컨트롤러 API	Executor는 장치에 직접이 아닌 컨트롤러로 작업을 라우팅; Collector는 컨트롤러 텔레메트리에서 읽음
엣지 vs. 코어	동일한 아키텍처, 다른 위험 허용도와 변경 속도	동일한 플랫폼 블록; 다른 워크플로우 설정, 승인 게이트, 롤아웃 웨이브 크기

각 행은 SoT가 인코딩하도록 요구하지 않고 플랫폼이 처리해야 하는 차이의 축이다. 의도 모델은 통합된 상태를 유지하고; Executor와 Orchestrator가 변형을 수용한다. 다음 섹션의 전략은 어떻게 하는지를 다룬다.

9.2.3.2. Executor와 Collector의 어댑터 패턴 (Adapter Pattern)#

가장 일반적인 시작점이자 가장 널리 구현된 전략이다. 벤더당 하나의 자동화 모듈, 모두 SoT에서 동일한 입력 데이터 구조를 받는다. SoT는 벤더 중립적 의도를 저장하고; Executor의 어댑터 계층이 실행 시 벤더별로 변환한다. 동일한 원칙이 Collector에도 적용된다: 벤더 또는 프로토콜당 하나의 수집 모듈, 모두 관찰 가능성 파이프라인에 정규화된 데이터 구조를 제공한다. gNMI를 사용하는 벤더는 하나의 어댑터를 사용하고; SNMP 폴링이나 독점 REST가 필요한 벤더는 다른 어댑터를 사용한다. 관찰 가능성 계층은 업스트림 수집 방법에 관계없이 동일한 데이터 스키마를 본다.

flowchart LR
    SoT["SoT 의도 (벤더 중립): vlan_id=210, vlan_name=app-payments"]
    Exec["Executor"]
    CiscoA["Cisco 어댑터: IOS-XE NETCONF"]
    AristaA["Arista 어댑터: eAPI / EOS"]
    HPEA["HPE 어댑터: NETCONF + OS 버전 오류 처리"]
    CiscoD["Cisco Catalyst"]
    AristaD["Arista 7050"]
    HPED["HPE Aruba 6300"]

    CollGNMI["Collector: gNMI 어댑터"]
    CollSNMP["Collector: SNMP 어댑터"]
    Obs["관찰 가능성 파이프라인 (정규화된 스키마)"]

    SoT --> Exec
    Exec --> CiscoA --> CiscoD
    Exec --> AristaA --> AristaD
    Exec --> HPEA --> HPED

    CiscoD --> CollGNMI --> Obs
    AristaD --> CollGNMI
    HPED --> CollSNMP --> Obs

구축하기 실용적이고 잘 이해된다. 장치 인벤토리가 다양화됨에 따라 유지 관리 부담이 증가한다: 새 벤더 또는 OS 버전은 새로운 또는 업데이트된 어댑터가 필요하다. 어댑터 패턴은 정의된 벤더 세트에 잘 확장된다; 플랫폼이 크고 자주 변경되는 장치 카탈로그를 지원해야 할 때 부담스러워진다.

9.2.3.3. 커뮤니티 및 산업 주도 YANG 모델#

두 산업 기관이 벤더당 어댑터 작업을 줄이는 벤더 중립적 YANG 모델을 발행한다. IETF 모델(RFC와 Internet-Draft로 발행)은 기본 데이터 구조를 정의한다: ietf-interfaces, ietf-routing, ietf-bgp. OpenConfig 모델은 운영자 컨소시엄(Google, AT&T, Deutsche Telekom 및 기타)이 개발하며, 더 운영 중심 스키마와 빠른 반복 주기로 유사한 영역을 다룬다. 둘 다 자동화 플랫폼이 표준 모델에 대해 한 번 의도를 작성하고 모든 준수 장치에서 작동할 것으로 기대할 수 있게 한다.

인터페이스를 정의하는 YANG 모듈은 다음과 같다(ietf-interfaces에서 단순화):

module ietf-interfaces {
  container interfaces {
    list interface {
      key "name";
      leaf name      { type string; }
      leaf description { type string; }
      leaf enabled   { type boolean; default true; }
    }
  }
}

동일한 구조가 OpenConfig(openconfig-interfaces)와 벤더 네이티브 모델에 나타나지만, 경로, 리프 이름, 기본 의미론이 다르다. YANG 모듈은 스키마를 정의하고; 프로토콜(NETCONF 또는 gNMI)이 데이터를 전송하며; 어댑터 계층이 표준과 벤더 현실 사이를 매핑한다.

OpenConfig의 실용적 현실: 벤더 구현은 완전성이 다양하다. 장치가 OpenConfig 지원을 주장할 수 있지만 플랫폼에 필요한 모델의 하위 집합만 구현할 수 있다: 읽기는 작동하지만 쓰기는 작동하지 않거나; 인터페이스 모델은 작동하지만 BGP 모델이 없다.

누락된 경로 외에도, 더 은밀한 문제는 일관성 없는 데이터다. 장치가 OpenConfig 경로에 대한 값을 반환하지만 잘못된 단위로, 다른 유형으로, 또는 벤더별 기본값으로 채워진 null이어야 하는 필드로. 동일한 장치에서 SAMPLE 모드로 작동하는 gRPC Network Management Interface (gNMI) 구독이 ON_CHANGE 모드에서 자동으로 실패할 수 있다.

이것은 드문 엣지 케이스가 아니다. 프로덕션에서 OpenConfig에 의존하는 멀티벤더 플랫폼을 운영하는 일상적 현실이다. 표준은 서류상으로 작동하며; 벤더 구현은 표준이 제거하려고 했던 동일한 장치별 조사가 필요하다. OpenConfig는 그 작업을 크게 줄이지만, 제거하지는 않는다. 프로덕션 자동화에서 새로운 OpenConfig 경로에 의존하기 전에 장치별 테스트를 계획하라.

YANG 변환 계층, 예를 들어 Cisco NSO의 Network Element Driver 모델은 벤더 중립적 의도를 받아 벤더별 명령 또는 YANG 편집을 내보낸다. 자동화 팀은 표준 모델에 쓰고; 변환 계층이 모든 벤더별 렌더링을 처리한다. 무거운 투자, 규모에서 높은 수익, 그리고 장치 카탈로그가 크고 다양할 때 높은 운영 비용.

YANG 모델 패밀리에 대한 참고

Yet Another Next Generation (YANG) 모델의 세 패밀리가 프로덕션 네트워크에서 공존하며, 구별을 이해하는 것이 어느 것을 대상으로 할지 선택하는 데 중요하다:

IETF 모델은 IETF 표준 프로세스를 통해 개발되고 RFC 또는 Internet-Draft로 발행된다. 이것이 기본 표준이다: ietf-interfaces, ietf-routing, ietf-bgp. 채택은 광범위하지만 느리다; 프로세스는 철저하지만 몇 년이 걸린다. 벤더 구현은 종종 발행 후 2~4년 후에 도착한다.
OpenConfig 모델은 OpenConfig 컨소시엄, 운영자 주도 그룹(Google, AT&T, Deutsche Telekom 및 기타)이 개발한다. OpenConfig는 IETF보다 빠르게 반복하며 더 운영 중심적이다. IETF 모델과 많은 동일한 기능 영역을 다루지만 다른 스키마 설계 선택을 한다. 대부분의 프로덕션 gNMI 배포는 OpenConfig 경로를 사용한다.
벤더 네이티브 모델은 각 벤더의 고유 확장이다: cisco-ios-xe-native, junos-conf-root, arista-eos-augments. 이들은 표준 모델이 다루지 않는 기능을 노출하며, IETF와 OpenConfig가 다루는 공통 분모 기능 외의 모든 것에 종종 필요하다. Nokia는 극단적인 경우다: SR OS의 거의 모든 운영 데이터는 Nokia별 YANG 모델(nokia-conf, nokia-state)을 통해서만 접근 가능하다. 표준 모델은 얇은 표면을 다루며; 벤더 네이티브 모델은 해당 플랫폼에서 의미 있는 자동화를 위해 필수다.

SNMP에 대한 비유는 직접적이다: IETF와 OpenConfig YANG 모델은 표준 MIB(MIB-II, IF-MIB, BGP4-MIB)에 해당하며, 이는 기본 모니터링을 위해 벤더 간에 공통 기반을 제공했다. 벤더 네이티브 YANG 모델은 표준 MIB가 다루는 것 이상에 필요했던 개인 엔터프라이즈 MIB에 해당한다. 역학은 동일하다: 표준은 일반적인 경우에 상호 운용성을 제공하고; 벤더 확장은 전체 기능 세트에 불가피하다. SNMP MIB에 비해 YANG의 장점은 데이터 모델이 더 풍부하고 계층적이며, NETCONF/gNMI 전송이 폴링 방식이 아닌 트랜잭션 방식이라는 것이다. 단점은 동일하다: 이기종 네트워크는 세 모델 패밀리를 동시에 탐색해야 한다.

추상화는 기능 접근 비용으로 균일성을 얻는다. 모든 벤더는 표준 모델에 동등한 것이 없는 독점 기능을 가진다. OpenConfig를 사용하는 팀은 선택해야 한다: 기능을 무시하거나, 벤더 확장을 추가하거나, 벤더별 오버라이드 경로를 유지한다. 깔끔한 답이 없다. 실제로 대부분의 자동화 작업은 표준 모델이 잘 다루는 기능(VLAN, BGP, 인터페이스)에 집중된다; 독점 기능은 중요하지만 핵심 사용 사례는 드물다. 표준도 채택 지연과 함께 도착한다: 벤더가 발행 후 2~4년 후에 IETF 모듈을 구현할 수 있으며, 최신 플랫폼에서만. 균일한 지원을 가정하는 것이 아니라 SoT에 기록된 OS 버전에 기반하여 기능 사용을 게이트하라.

9.2.3.4. SONiC과 오픈 네트워킹#

SONiC의 설정 인터페이스는 YANG 구조 스키마를 가진 Redis 데이터베이스다: 균일하고, 프로그래매틱하며, 처음부터 자동화를 위해 설계되었다. 멀티벤더 물리 환경에서 노력을 소비하는 벤더별 어댑터 작업이 여기서는 적용되지 않는다. 동일한 자동화 로직이 기반 하드웨어 벤더에 관계없이 모든 SONiC 기반 플랫폼에서 작동한다.

SONiC CONFIG_DB의 VLAN 항목은 다음과 같다:

{
  "VLAN": {
    "Vlan210": {
      "vlanid": "210"
    }
  },
  "VLAN_MEMBER": {
    "Vlan210|Ethernet0": {
      "tagging_mode": "untagged"
    }
  }
}

이 JSON은 sonic-cfggen 또는 SONiC 관리 REST API를 통해 Redis에 직접 쓰여진다. 파싱할 CLI가 없고, 구성할 XML도 없다. 자동화 플랫폼이 구조화된 데이터를 쓰고; SONiC의 orchagent가 그것을 하드웨어 포워딩 테이블에 조정한다.

이것이 오픈 네트워킹이 주창하는 설계 방향이다: 자동화에 적응된 것이 아닌 자동화를 위해 설계된 네트워크 인터페이스. 전통적인 장비와 함께 SONiC 기반 플랫폼을 도입하는 팀은 SONiC 어댑터가 가장 간단하게 작성되고 가장 안정적으로 운영됨을 알게 될 것이다.

벤더 제공: SONiC은 Microsoft Azure 기원을 훨씬 넘어섰다. 대부분의 주요 스위치 실리콘 벤더는 이제 SONiC 기반 플랫폼을 제공한다: Microsoft Azure SONiC(업스트림 참조), 특정 플랫폼에서 SONiC 호환 관리 API를 갖춘 Arista, Broadcom 기반 SONiC 지원의 Cisco 8000 시리즈, SONiC 파생 아키텍처를 사용하는 Dell OS10, 1등급 옵션으로 SONiC을 실행하는 Nvidia Spectrum 플랫폼, 그리고 브랜드 SONiC 플랫폼을 출시하는 점점 늘어나는 ODM 벤더(Edgecore, Celestica, UfiSpace). 생태계는 모든 가격 및 성능 계층에서 SONiC 기반 플랫폼을 상업적으로 이용할 수 있는 수준으로 성숙했다.
성숙한 사용 사례: 데이터 센터 리프-스파인 패브릭이 가장 확립된 배포다. 하이퍼스케일러는 10년 이상 규모에서 SONiC을 실행해왔으며; 엔터프라이즈 데이터 센터가 이제 따르고 있다. EVPN/VXLAN 오버레이, BGP 라우팅, ECMP 로드 밸런싱, 400G/800G 인터페이스 지원이 잘 검증되어 있다. 자동화 이야기는 강력하다: gNMI, YANG, Redis 지원 CONFIG_DB가 기본 인터페이스다. SONiC 플리트는 다른 gNMI 활성화 플랫폼을 관리하는 동일한 도구로 관리될 수 있다.
새로운 영역: SONiC은 전통적인 DC 패브릭 외부에서 나타나기 시작하고 있다. 분리된 라우팅 플랫폼(SONiC이 스위치만이 아닌 고포트 카운트 라우터에서 실행되는 곳)은 오픈 NOS 모델을 라우팅 사용 사례까지 확장한다. SONiC은 이제 세그먼트 라우팅 지원을 포함한다: SRv6(IPv6를 통한 세그먼트 라우팅)은 업스트림 SONiC에서 사용 가능하며 트래픽 엔지니어링 및 네트워크 슬라이싱을 위해 SONiC 기반 플랫폼을 실행하는 서비스 프로바이더가 프로덕션에서 사용 중이다. 일부 서비스 프로바이더는 피어링 엣지와 브로드밴드 집계를 위한 SONiC도 평가하고 있다. 캠퍼스 SONiC 배포는 기술적으로 실현 가능하지만 여전히 드물다; 캠퍼스 폼 팩터의 하드웨어 생태계는 덜 성숙해 있다. 오늘날 새 플랫폼을 구축하는 팀에게 DC에서 SONiC이 프로덕션 준비가 되었는지 더 이상 의문이 아니다: 그렇다. 열린 질문은 벤더의 SONiC 포크와 릴리스 주기가 플랫폼 수명 동안 업스트림과 일치하게 유지될지 여부다.

9.2.3.5. 펌웨어 마이그레이션 중 공존 관리#

어댑터 패턴은 장치당 알려진 안정적인 OS 버전을 가정한다. 롤링 펌웨어 업그레이드 중에 그 가정이 무너진다: 동일한 역할의 장치들이 동일한 자동화 플랫폼으로 관리되지만, 며칠 또는 몇 주 동안 다른 OS 버전을 동시에 실행한다. 어제 펌웨어 10.12에서 작동했던 추상화 계층이 새 어댑터 경로가 추가될 때까지 펌웨어 10.13에서 작동하지 않을 수 있다.

SoT는 의도된 OS 버전(마이그레이션 후 대상)을 기록해야 하고 Collector는 현재 OS 버전을 운영 상태로 서피스해야 한다. Executor가 설정을 적용하기 전에 Collector 또는 관찰 가능성 파이프라인에서 현재 OS 버전을 읽고 의도된 버전이 이미 배포되어 있다고 가정하지 않고 적절한 어댑터 경로를 선택해야 한다.

구체적인 메커니즘: Executor는 실행 중인 OS 버전에 대해 관찰 가능성 블록(또는 장치 자체에 대한 경량 사전 실행 확인)을 쿼리한다. 어댑터 레지스트리는 OS 버전 범위를 어댑터 구현에 매핑한다. Executor는 SoT 의도가 아닌 현재 상태를 기반으로 올바른 어댑터를 호출한다. 장치가 업그레이드되고 실행 중인 버전이 의도와 일치하면 어댑터 선택이 안정화된다. 마이그레이션 창 동안 동일한 벤더에 대한 두 어댑터 경로가 동시에 활성화될 수 있다.

섹션 9.3의 구현 예시는 이 패턴을 직접 보여준다: HPE 어댑터 버그는 하나의 펌웨어 버전이 동일한 조건에 대해 vlan-exists를 반환하고 다른 버전이 duplicate-vlan을 반환했기 때문에 발생했다. 수정은 어댑터 레지스트리의 OS 버전별 오류 처리였다. 멀티 버전 플리트를 관리하는 모든 자동화 플랫폼은 이 종류의 문제를 만날 것이다. Collector에서 읽은 현재 OS 버전에 의해 구동되는 버전별 어댑터 로직을 인코딩하는 것이 체계적인 완화 방법이다. 챕터 11은 플레이북별 상수가 아닌 플랫폼 레벨 카탈로그로서 OS 버전 매핑을 유지 관리하는 방법을 다룬다.

조직적 함의: 누군가가 SoT의 OS 버전 추적, 어댑터 버전 레지스트리, 그리고 업그레이드 시퀀싱 워크플로우를 소유해야 한다. 이 세 아티팩트가 업그레이드 자동화 시스템을 형성한다. 명시적 소유권 없이는 독립적으로 드리프트되고 플랫폼의 신뢰성이 모든 펌웨어 릴리스마다 저하된다.

9.2.4. 모든 블록에 대한 제약으로서의 네트워크#

이 섹션에서 다룬 세 영역, 프로그래머블 인터페이스, 시뮬레이션 환경, 그리고 추상화 전략은 고립된 주제가 아니다. 이들은 NAF 프레임워크의 모든 블록에 대한 네트워크의 영향을 설명한다.

네트워크의 인터페이스 기능은 Executor가 할 수 있는 것을 제한한다: CLI만 지원하는 장치는 Executor의 어댑터를 취약한 화면 스크레이핑으로 강제하고; 성숙한 gNMI 지원을 가진 장치는 신뢰할 수 있는 설정과 스트리밍 텔레메트리를 가능하게 한다. 네트워크의 수집 지원은 Collector가 수집할 수 있는 것을 제한한다: 필요한 OpenConfig 경로를 구현하지 않는 장치는 벤더별 해결 방법 또는 수집 격차가 필요하다. 네트워크의 토폴로지는 Orchestrator가 안전하게 병렬화할 수 있는 것을 제한한다: 플랫 액세스 레이어에 안전한 배치 크기가 리프-스파인 패브릭에서는 재앙적일 수 있으며, 여러 스파인 노드에 대한 동시 변경이 네트워크를 분할할 수 있다.

SoT 데이터 모델은 이러한 제약을 반영한다. OS 버전 필드가 어댑터 선택을 게이트한다. 인터페이스 유형 필드가 수집 방법을 게이트한다. 토폴로지 관계가 Orchestrator 동시성 규칙을 게이트한다. 자동화 관련 속성(인터페이스 기능, OS 버전, 토폴로지 역할)을 기록하지 않고 장치 인벤토리만 기록하는 SoT는 실행 시에만 드러나는 방식으로 불완전하다.

파트 2의 각 아키텍처 결정에는 이 챕터가 드러내는 해당 네트워크 계층 제약이 있다. 네트워크는 단순히 자동화의 대상이 아니다. 그것에 작용하는 모든 블록을 형성하며, 그러한 제약은 플랫폼의 데이터 모델, 어댑터 로직, 그리고 워크플로우 설정에 인코딩되어야 한다. 네트워크를 균일한 표면으로 취급하는 자동화는 실패한 배포 하나씩 이기종성을 발견하게 될 것이다.

9.3. 구현 예시#

9.3.1. 시뮬레이션에서 프로덕션까지#

캠퍼스 VLAN 워크플로우가 준비되었다. 8주간의 개발, 세 벤더 모델링, 세 노드 랩에 대한 멱등성 테스트. 팀은 프로덕션에 배포하기를 원한다: 스위치 800개, Building A~F. 그 전에 시뮬레이션에 대해 실행한다.

이 예시는 섹션 9.2.2.4에서 설명한 사전 프로덕션 게이트 시퀀스를 따르며, Building B 범위를 시뮬레이션 대상으로 사용한다: 스위치 24개, Cisco 8개, Arista 8개, HPE 8개.

1단계: 소스 오브 트루스에서 토폴로지 내보내기

SoT는 의도된 OS 버전과 함께 Building B 스위치 인벤토리를 보유한다:

Cisco Catalyst 9300 8대: IOS-XE 17.9.4
Arista 7050 8대: EOS 4.31.2F
HPE Aruba 6300 8대: AOS-CX 10.12.1006 (10.13 이전의 구형 펌웨어 라인)

SoT 내보내기는 netlab 토폴로지 정의를 생성한다: 노드 유형, 의도된 OS 버전에 매핑된 벤더별 이미지 태그, 그리고 시뮬레이션이 시작해야 하는 VLAN 상태(기존 VLAN 100, 150, 200이 이미 모든 스위치에 설정되어 프로덕션 상태와 일치).

2단계: 시뮬레이션 환경 인스턴스화

netlab은 SoT 내보내기를 containerlab 토폴로지 파일로 렌더링한다. containerlab은 팀의 CI 환경의 공유 Linux 시뮬레이션 호스트에서 실행된다(베어 메탈 서버, RAM 64GB, 24개의 경량 cEOS/vrnetlab 컨테이너를 동시에 실행하기에 충분). HPE 노드는 SoT에서 의도된 OS 버전과 일치하여 10.12.1006으로 고정된 vrnetlab 래핑 AOS-CX 이미지를 사용한다. containerlab이 토폴로지를 시작한다. 24개 노드 모두 90초 이내에 NETCONF와 gRPC Network Management Interface (gNMI)에 응답한다.

3단계: 시뮬레이션 대상에 대해 챕터 7 VLAN 워크플로우 실행

Orchestrator는 프로덕션 인벤토리가 아닌 시뮬레이션 인벤토리를 대상 범위로 사용하여 워크플로우를 트리거한다. 처음 네 워크플로우 단계가 문제 없이 완료된다:

ServiceNow 웹훅 수신, 파싱, SoT 스키마에 대한 검증
사전 확인: VLAN 210이 시뮬레이션에 존재하지 않음 (올바름)
VLAN 210 의도로 SoT 업데이트
승인 게이트: 시뮬레이션 모드에서 자동 승인

Executor를 통한 24개 시뮬레이션 스위치 전반에 걸친 팬아웃 실행인 다섯 번째 워크플로우 단계가 실패를 반환한다.

결과: Cisco 노드 8개 통과. Arista 노드 8개 통과. HPE 노드 8개 실패.

HPE 노드의 오류: vlan-exists. HPE 어댑터의 멱등성 검사는 duplicate-vlan을 no-op으로 처리했지만 vlan-exists에 대한 핸들러가 없었다. Executor가 실패를 반환하여 Saga 보상을 트리거했다: VLAN 210이 이미 수신한 모든 노드에서 제거됨.

프로덕션 변경이 발생하지 않았다. 실패 비용은 컨테이너 시작 시간과 30분의 조사다.

4단계: 진단 및 수정

팀이 AOS-CX 10.12 릴리스 노트를 확인한다. vlan-exists 오류는 중복 VLAN 감지를 위해 duplicate-vlan을 대체하여 10.11.1에 도입되었다. 10.13 릴리스는 Aruba 제품 라인의 나머지 부분과의 일관성을 위해 duplicate-vlan으로 되돌렸다.

수정: vlan-exists를 HPE 어댑터의 멱등성 오류 코드 목록에 추가한다. SoT는 OS 버전 경계에 대한 참고 사항으로 업데이트된다(10.11 ~ 10.12.x는 vlan-exists를 반환하고; 10.13+는 duplicate-vlan을 반환한다).

재실행 전에 팀은 예상 변경 후 상태를 pyATS 또는 Robot Framework 테스트로 인코딩한다: 워크플로우가 완료된 후 VLAN 210이 24개 시뮬레이션 노드 모두에 존재하고 Saga 보상이 트리거되지 않았음을 어설션한다. 이 어설션은 시뮬레이션 통과 기준에 추가된다: 시뮬레이션 게이트는 워크플로우가 완료되고 검증 어설션이 통과될 때만 닫힌다.

5단계: 시뮬레이션 재실행

수정된 어댑터가 동일한 containerlab 토폴로지에 대해 실행된다. 24개 노드 모두 통과한다. Saga가 보상 없이 완료된다. SoT는 Building B의 모든 노드에 VLAN 210이 있는 것으로 표시한다.

6단계: 프로덕션 배포

Orchestrator는 전체 프로덕션 범위인 Building A~F의 스위치 800개에 대해 동일한 워크플로우를 트리거한다. 각 단계는 시뮬레이션에서 검증된 동일한 Saga 패턴을 실행한다. HPE 노드에서 실패 없음. Orchestrator가 완료되면 애플리케이션 팀의 ServiceNow 티켓이 자동으로 닫힌다. 관찰 가능성 계층은 예상 시간 창 내에 모든 인터페이스에서 VLAN 210 존재를 검증한다.

이것이 보여주는 것

시뮬레이션 환경은 팀이 자신감을 느낄 때 건너뛸 수 있는 검증 단계가 아니다. 이것은 Saga 패턴의 사전 프로덕션 게이트다. 프로덕션 토폴로지와 OS 버전을 반영하는 시뮬레이션 토폴로지는 캠퍼스 규모에서 자동화를 배포하는 팀에게 최소한의 테스팅 환경이다. 투자는 containerlab 설정, OS 버전 고정 이미지, 그리고 SoT 내보내기 메커니즘이다. 수익은 장치별 버그를 인시던트가 되기 전에 잡을 수 있는 능력이다.

시뮬레이션이 이 버그를 잡은 것은 복잡한 테스트 때문이 아니라, 시뮬레이션의 OS 버전이 프로덕션과 일치하고 플랫폼이 정확히 동일한 워크플로우 코드를 그에 대해 실행했기 때문이다. 프로덕션 상태에 대한 시뮬레이션 환경의 충실도가 잡을 수 있게 만드는 것이다. 최신 벤더 이미지를 실행하는 시뮬레이션 환경은 이것을 놓쳤을 것이다.

챕터 10은 플랫폼의 일부로서 시뮬레이션 환경을 운영화하는 방법을 다룬다: 버전 관리에서 containerlab 토폴로지를 유지 관리하고, 일정에 따라 SoT 내보내기와 동기화하며, 시뮬레이션 게이트가 모든 워크플로우 변경에 자동으로 실행되도록 CI/CD 파이프라인에 통합한다.

9.4. 요약#

챕터 9는 자동화 플랫폼이 항상 가리키고 있던 블록인 네트워크 자체를 다루며 파트 2를 마무리한다.

세 가지 아이디어가 챕터를 고정한다.

네트워크는 균일하지 않다. 모든 대규모 자동화 플랫폼은 캠퍼스 스위칭, 데이터 센터 패브릭, 클라우드 VPC, Kubernetes 오버레이, 오버레이 컨트롤러, 그리고 레거시 장비와 동시에 상호작용한다. 각각은 다른 인터페이스를 노출하고, 다른 일관성 의미론 하에서 운영되며, 다른 자동화 성숙도를 가진다. 플랫폼은 인터페이스 선택 계층 구조(텔레메트리에 gRPC Network Management Interface (gNMI), 설정에 NETCONF, 최후의 수단으로 Command Line Interface (CLI)), 소스 오브 트루스의 OS 버전 추적, 그리고 Executor의 벤더별 어댑터를 통해 이 이기종성을 수용한다.

시뮬레이션 환경은 사전 프로덕션 게이트다. 컨테이너 기반 에뮬레이션은 프로덕션을 반영하는 토폴로지와 OS 버전에 대해 자동화 로직이 테스트되는 현실적이고, 빠르며, CI/CD 통합된 환경을 제공한다. 시뮬레이션의 실패는 저렴하다. 프로덕션의 실패는 비싸다. 프로덕션 상태에 대한 시뮬레이션 환경의 충실도가 게이트를 의미 있게 만드는 것이다.

추상화 전략은 플랫폼 수명을 연장한다. 어댑터 패턴은 오늘날의 멀티벤더 물리 환경을 처리한다. OpenConfig와 YANG 변환은 장기적인 어댑터 유지 관리를 줄이는 벤더 중립적 모델로 향한다. SONiC은 이를 지원하는 플랫폼에 대해 어댑터 작업을 완전히 제거한다. 이러한 전략 중 어느 것도 완벽한 답을 제공하지 않는다; 각각 균일성과 기능 접근 간의 트레이드오프를 포함한다. 올바른 선택은 팀의 장치 카탈로그, 운영 용량, 그리고 자동화 작업이 표준 기능 커버리지 내에 얼마나 해당하는지에 따라 다르다.

챕터 9로 파트 2가 완성되었다. 여섯 챕터가 NAF 프레임워크의 일곱 빌딩 블록 모두를 다루었다: 소스 오브 트루스, Collector와 관찰 가능성(챕터 6에서 함께), 실행, 오케스트레이션, 프레젠테이션, 그리고 네트워크. 이들은 독립적인 도구가 아니다. SoT는 필요한 의도와 함께 Executor를, 그리고 검증할 예상 상태와 함께 Collector를 공급한다. Orchestrator는 둘 다 순서 지정하고, 실패를 처리하며, Presentation 계층에 진행 상황을 서피스한다. 네트워크는 그 아래에 있다: 다른 모든 블록의 설계를 형성한 제약이며, 자동화가 궁극적으로 결과를 생성하거나 실패하는 장소.

파트 3은 블록을 구축하는 것에서 규모에서 플랫폼을 운영하는 것으로 전환한다: 신뢰성 엔지니어링, 보안 및 규정 준수 설계, 그리고 자체 수명 주기와 운영 요구 사항을 가진 제품으로서 자동화 플랫폼 취급.

참고 자료 및 추가 학습#

Network Programmability and Automation, Matt Oswalt, Christian Adell, Scott Lowe, Jason Edelman (O’Reilly, 2nd ed. 2023). NETCONF, gNMI, YANG 모델, 자동화 프레임워크를 심층적으로 다루는 네트워크 자동화 툴링에 관한 가장 포괄적인 실용 가이드.
Network Programmability with YANG, Benoit Claise, Loe Clarke, Jan Lindblad (Pearson, 2019). YANG 데이터 모델링에 관한 결정적 참고서: IETF와 OpenConfig 모델의 구조, YANG 모듈 읽기 및 쓰기 방법, NETCONF와 RESTCONF가 이들을 사용하는 방법.
Cisco pyATS: Network Test and Automation Solution, John Capobianco, Dan Wade (Cisco Press). 네트워크 테스트 자동화를 위한 pyATS와 Genie에 관한 포괄적 가이드: 테스트 스크립트, 파서, 구조화된 상태 검증, CI/CD 파이프라인 통합.
Infrastructure as Code, Kief Morris (O’Reilly, 2nd ed. 2021). 네트워크 특정이 아니지만, 반복 가능하고, 테스트 가능하며, 버전 관리된 인프라 뒤의 원칙이 네트워크 자동화 플랫폼 설계에 직접 적용되는 방법을 이해하는 데 기초가 된다.

💬 Found something to improve? Send feedback for this chapter