Part 2: Architectural Building Blocks on Designing Network Automation at Scale

04 - 진실의 원천

Mon, 01 Jan 0001 00:00:00 +0000

4. 진실의 원천#

새로운 서비스가 주말까지 가동되어야 했다. 변경은 간단했다: 새 VLAN, 새 서브넷, 업데이트된 방화벽 규칙, 엣지 라우터의 새 BGP 커뮤니티. 네트워크 엔지니어는 정확히 무엇을 해야 하는지 알고 있었다. 이어진 것은 다섯 개의 시스템에 걸친 4일간의 조율이었다: 서브넷을 예약하는 IPAM 도구, 서비스를 등록하는 CMDB, 새 정책을 푸시하는 방화벽 관리 플랫폼, BGP 커뮤니티를 위한 라우터 설정 시스템, 그리고 새 임계값을 추가하는 모니터링 플랫폼. 각 시스템은 고유한 인터페이스, 고유한 데이터 모델, 고유한 승인 워크플로가 있었다. 그리고 공유 레퍼런스가 없었기 때문에 엔지니어는 컨텍스트를 수동으로 가지고 다녀야 했다: 한 시스템에서 다른 시스템으로 값을 복사하면서 단계 사이에 아무것도 드리프트되지 않기를 바라면서.

05 - 실행

Mon, 01 Jan 0001 00:00:00 +0000

5. 실행#

플레이북은 몇 달 동안 완벽하게 실행되고 있었다: 랩의 액세스 스위치 10대, 처음부터 끝까지 2분, 매번 깔끔한 결과. 팀이 800대 스위치의 전체 인벤토리로 출시하기로 결정했을 때, 아무도 문제를 예상하지 않았다. 처음 600대는 문제없이 업데이트됐다. 그다음 작업이 느려졌다. 그다음 멈췄다. 갑자기 150개의 동시 SSH 인증 요청을 받은 RADIUS 서버가 연결을 거부하기 시작했다. Ansible이 150대 장비에서 실행 도중 중단됐다. 엔지니어가 작업을 강제 종료했다.

이어진 것이 더 어려운 문제였다: 어떤 600대가 업데이트됐고 어떤 150대가 안 됐는지 아무도 알지 못했다. 실행 상태가 기록되지 않았다. 플레이북을 재실행하고 멱등성이 구해주기를 바랐다, 그번은 구해줬다. 하지만 이 사고는 중요한 것을 드러냈다: 실행 레이어가 랩을 위해 설계됐지, 네트워크를 위해서가 아니었다. 속도, 병렬성, 오류 경계, 상태 추적, 그 무엇도 고려되지 않았다. 자동화는 작동했지만, 실행 아키텍처는 그렇지 않았다.

06 - 가시성(Observability)

Mon, 01 Jan 0001 00:00:00 +0000

6. 가시성(Observability)#

한 서비스 제공업체의 핵심 라우터에서 팬 모듈이 밤새 조용히 고장났다. 경보는 아무것도 울리지 않았다. 라인 카드의 열 관리 서브시스템이 온도 상승을 감지하고 하드웨어를 보호하기 위해 포워딩 ASIC의 성능을 제한하기 시작했다. 프로덕션 트랜짓 링크의 처리량이 40% 감소했다. 모니터링 시스템은 아무것도 감지하지 못했다. 폴링하는 열 센서가 라인 카드가 아닌 섀시 수퍼바이저에 있었기 때문이다. SNMP 폴링은 5분마다 실행되었고 장치가 정상 상태라고 보고했다. 인터페이스 카운터에는 처리량 감소가 나타났지만, 해당 링크는 항상 용량 이하로 운영되어 왔기 때문에 그 패턴에 대한 임계값이 설정되어 있지 않았다.

07 - 오케스트레이션(Orchestration)

Fri, 20 Mar 2026 00:00:00 +0000

7. 오케스트레이션(Orchestration)#

네트워크 팀은 모든 것을 제대로 해냈다. 견고한 소스 오브 트루스(SoT), 모든 작업에 대한 충분히 테스트된 플레이북, 그리고 이를 실행하는 명확한 대응 절차서가 있었다. 서류상으로는 새로운 VLAN 서비스 배포가 완전히 자동화되어 있었다. 실제로는 반나절이 걸렸고 특정 엔지니어 한 명이 필요했다.

그 엔지니어는 순서를 알고 있었다. 먼저 SoT 데이터가 완전한지 검증한다. 그 다음 사전 점검 플레이북을 실행한다. 출력을 검토하고, 실패한 장치를 찾아 계속할지 결정한다. 그 다음 배포 플레이북을 트리거한다. 기다린다. 검증 플레이북을 실행한다. ServiceNow 티켓을 수동으로 업데이트한다. 중간에 장치가 실패하면 다른 장치들이 알아채기 전에 롤백한다. 그녀는 아무도 완전히 내면화하지 못한 공유 문서에 단계별로 모든 것을 대응 절차서로 작성해 두었다.

08 - 프레젠테이션(Presentation)

Sat, 28 Mar 2026 00:00:00 +0000

8. 프레젠테이션 계층#

VLAN 자동화는 6주째 실행 중이었다. 네트워크 팀은 자랑스러워했다. 매일 아침 애플리케이션 팀에서 서너 개의 새로운 서비스 요청이 들어왔고, 오케스트레이터가 네트워크 팀 누구도 키보드를 건드리지 않고 처리했다. 배포는 작동했다. 스위치는 구성되었다. 네트워크는 건강했다.

에스컬레이션은 목요일에 왔다. 애플리케이션 팀 리더가 포털에 “제출됨"이라고 표시되어 있는데 왜 VLAN 요청이 3~5 영업일이 걸리는지 묻고 있었다. 네트워크 팀이 큐를 확인했다. 대기 중인 요청 없음, 모든 배포 성공. 자동화는 수신 후 20분 이내에 모든 요청을 처리했다. 하지만 ServiceNow 티켓은 여전히 “진행 중"으로 표시되어 있었다. 아무도 티켓을 업데이트하는 통합을 작성하지 않았기 때문이다.

09 - 네트워크

Mon, 01 Jan 0001 00:00:00 +0000

9. 네트워크#

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

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