· 7594 words · 36 min read

6. 가시성(Observability)#

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

세 시간 후, 고객 SLA 위반으로 티켓이 생성되었다. 온콜 엔지니어가 라우터에 SSH로 접속해 로컬 경보 로그에서 팬 고장을 확인하고 팬 모듈을 재시작했다. 팬 컨트롤러가 재가동되자 열 제한이 몇 분 만에 해제되었다. 트래픽이 회복되었고, SLA 위반이 문서화되었으며, 고객에게 통보되고 인시던트가 종결되었다.

근본 원인은 끝내 확인되지 않았다. 조사가 시작될 즈음 라우터는 이미 수 시간째 정상 운영 중이었다. 라인 카드의 열 데이터도, 성능 제한 이벤트의 기록도, 어떤 모니터링 시스템에서도 처리량 감소와 팬 고장을 연관 지을 방법도 없었다. 인시던트 보고서의 결론은 이랬다. “하드웨어 문제로 추정, 하드웨어 재설정으로 해결.” 6개월 후 다른 라우터에서 같은 일이 반복되었다.

문제는 임계값이 없었던 것이 아니었다. 팀에는 수천 개의 임계값이 있었다. 문제는 불완전한 커버리지였다. 모니터링 시스템은 항상 폴링해 온 소스에서만 데이터를 수집했을 뿐, 장치 동작에 영향을 줄 수 있는 모든 소스를 대상으로 하지 않았다. 라인 카드의 열 데이터는 플릿의 세 가지 섀시 유형 모두에서 gNMI를 통해 제공되고 있었다. 팬 고장 대응 절차서가 없어서 아무도 해당 수집 경로를 구성하지 않았던 것이다.

전통적인 네트워크 모니터링은 고장난 것을 찾는다. 인터페이스가 살아 있는가? CPU가 90%를 넘는가? 이 서비스가 응답하는가? 유용하긴 하지만 반응적이다. 이미 장애가 발생한 후에야 감지하는 것이다.

가시성(Observability)은 다르다. 왜 고장 나는지, 또는 곧 고장 날 것인지를 이해하는 것이다. 단순히 “저 장치가 다운되었다"가 아니라, “왜 다운되었고, 그로 인해 무엇이 영향을 받으며, 비즈니스 영향은 무엇인가"를 묻는다. 네트워크 자동화에서 가시성은 피드백 루프가 된다. 네트워크를 관찰하고, 시스템이 이를 감지하며, 어떻게 대응할지 결정하고, 조치를 취하고, 수정이 효과적이었는지 검증한다. 이 반복적인 사이클이 바로 “폐루프 자동화(closed-loop automation)“다.

이 챕터에서는 네트워크에서 무슨 일이 일어나는지 파악하기 위해 필요한 모든 것을 다룬다. 어떤 데이터를 수집할지, 어떻게 수집할지, 어떻게 저장할지, 어떻게 알림을 보낼지, 그리고 실제로 의사결정에 도움이 되는 방식으로 어떻게 보여줄지를 살펴본다.

여기서는 두 가지 구성 요소인 Collector와 Observability를 함께 다룬다. 두 요소가 긴밀하게 연결되어 있기 때문이다.

전통적인 통합형 플랫폼(SolarWinds, LibreNMS), 클라우드 서비스(Datadog, New Relic), 또는 오픈소스 구성 요소(Prometheus, Grafana 등)로 자체 스택을 구축하든 간에 기반이 되는 아키텍처는 동일하다. 이 패턴들을 이해하면 팀의 규모와 상황에 맞는 올바른 접근 방식을 선택하는 데 도움이 된다.

이 섹션에서는 설명을 위해 다양한 벤더와 솔루션을 예시로 언급한다. 이는 어떠한 추천도 아니며, 순전히 설명 목적임을 밝힌다.

이 섹션은 Packt 출판사의 Modern Network Observability에서 큰 영향을 받았다. 이 책은 저자가 David Flores, Josh Vanderaa와 공동 집필한 것으로, Telegraf-Prometheus-Grafana(TPG) 스택과 기타 도구를 활용한 실습 구현을 배우고 싶다면 강력히 추천한다.

6.1. 기초 개념#

세부 사항으로 들어가기 전에, 네트워크 자동화 전략 내에서 네트워크 가시성의 기초를 확립한다. 목표, 지지 기둥, 그리고 범위를 정의한다.

6.1.1. 맥락#

이미 네트워크를 모니터링하고 있을 것이다. Simple Network Management Protocol (SNMP)를 사용하고, System Logging Protocol (Syslog)를 확인하며, 링크 사용률을 보여주는 대시보드도 있을 것이다. 이것이 모니터링이다. 시스템이 제대로 동작하는지 알려준다.

하지만 자동화는 더 많은 것을 필요로 한다. 네트워크가 변경될 때(자동화가 변경했기 때문에), 무언가 문제가 생겼는지 즉시 알아야 한다. 알림을 받았을 때 맥락이 필요하다. 어떤 고객에게 영향을 미치는가? 어떤 서비스가 실패했는가? 피해 범위는 어느 정도인가? 전통적인 모니터링은 경보를 줄 뿐이다. 자동화에는 인텔리전스가 필요하다.

핵심 차이점은 다음과 같다.

모니터링: 인터페이스가 살아 있는가? CPU가 높은가? 단순한 예/아니오 질문.
가시성: 인터페이스가 왜 다운되었는가? 무엇이 영향을 받고 있는가? 어떻게 자동으로 수정할 수 있는가? 이 상황에 이르기까지 역사적으로 무슨 일이 있었는가?

가시성은 자동화에 데이터를 공급한다. 시스템이 네트워크를 관찰하고, 문제를 감지하며, 무엇을 할지 결정하고, 조치를 취하고, 수정이 효과적이었는지 검증한다. 이 사이클이 반복되는 것을 “폐루프 자동화(closed-loop automation)“라고 한다.

전통적인 모니터링 도구(SolarWinds처럼 대형 단일 시스템)는 하나의 제품 안에서 모든 것을 처리하려 한다. 이것으로도 운영이 가능하지만, 필요 없는 기능에 비용을 지불하고 정작 필요한 기능에서 제약을 받는 경우가 많다. 대안은 가시성을 조각으로 구성하는 것이다. 자신의 장치에 맞는 수집기를 고르고, 데이터에 맞게 확장되는 저장소를 선택하며, 자동화 워크플로에 맞는 알림 시스템을 구성한다. 조립이 더 어렵지만 훨씬 유연하다.

이 챕터는 두 가지 접근 방식 모두를 다루며, 어떤 방식을 선택하든 적용되는 패턴을 살펴본다.

초기 선택 중 하나는 플랫폼 운영 방식에 관한 것이다.

단일형(Monolithic) (SolarWinds, LibreNMS): 하나의 제품이 모든 것을 처리한다. 설치하고, 구성하면 바로 사용할 수 있다. 네트워크가 단순하고 DevOps 경험이 없다면 좋은 선택이다. 유연성이 필요하거나 네트워크가 특이한 경우에는 좋지 않다. 그들의 모델에 갇히게 된다.
클라우드 SaaS (Datadog, New Relic, Kentik): 모든 것을 그들이 운영한다. 배포가 빠르고, 인프라 걱정이 없으며, 즉시 사용 가능한 멋진 대시보드를 제공한다. 하지만 볼륨 기반으로 월정액을 지불하고, 데이터가 그들의 서버에 저장되며(일부 컴플라이언스 환경에서 문제가 될 수 있음), 그들의 한계에 부딪히면 선택지가 없다. CFO가 왜 불만스러워하는지 의아해하며 관찰성 SaaS에 월 5만 달러를 지출하는 팀을 본 적이 있다.
직접 구축(Build-it-yourself) (Prometheus + Grafana, 또는 Telegraf-Prometheus-Grafana (TPG) 스택): 완전한 유연성, 벤더 종속 없음, 규모의 경제. 하지만 데이터베이스, 메시지 큐, 수집기 인프라를 직접 운영해야 한다. 이런 것들을 운영할 수 있는 인력이 없다면 네트워크를 고치는 것보다 가시성을 고치는 데 더 많은 시간을 쓰게 될 것이다.

진짜 질문은 이것이다. 운영할 팀이 있는가? 있다면 직접 구축하라. 없다면 구매하라. 자신이 어느 범주에 속하는지 착각하지 마라.

그 선택 이후에 두 가지 질문이 더 나온다.

어디서 운영할 것인가? 온프레미스(모든 것을 통제하지만 직접 운영), 클라우드(그들이 운영하지만 데이터가 네트워크를 떠남), 또는 하이브리드(일부는 로컬, 일부는 클라우드)?
비용 모델은 무엇인가? 장치당? 수집된 메트릭당? 정액 구독? 분당 수백만 개의 데이터 포인트를 수집할 때 이런 결정들이 빠르게 누적된다.

6.1.2. 목표#

가시성 시스템이 수행해야 할 일곱 가지 역할이 있다.

모든 것을 자동으로 관찰한다. 새 장치가 연결되면? 누군가 수동으로 등록하지 않아도 데이터 보고가 시작되어야 한다. 새 서비스가 온라인 상태가 되면? 이미 모니터링되고 있어야 한다. 이를 위해서는 소스 오브 트루스(SoT)와의 통합이 필요하여 가시성 시스템이 무엇이 존재하는지 파악할 수 있어야 한다.
이기종 환경에서 좋은 데이터를 처리한다. 네트워크에는 Cisco, Arista, Juniper, 클라우드 제공업체, Linux 서버, 컨테이너가 있을 것이다. 각각 데이터를 노출하는 방식이 다르다. 그리고 5분 간격은 잊어라. 자동화가 변경을 수행할 때는 거의 실시간 데이터가 필요하다.
여러 계층에 걸쳐 데이터를 상관 분석한다. 서버가 느리다. 네트워크가 혼잡한 것인가, 아니면 데이터베이스 문제인가? 네트워크 장치, 서버, 애플리케이션의 데이터가 필요하며, 모두 같은 언어로 말해야 연결선을 그을 수 있다.
과부하 없이 확장한다. 네트워크는 성장한다. 초당 백만 개의 메트릭을 수집할 때 전통적인 아키텍처는 무너진다. 처음부터 확장을 고려해 설계된 시스템이 필요하다.
사람들이 데이터를 지능적으로 분석할 수 있게 한다. 분석가들이 미리 구축된 대시보드뿐 아니라 강력한 쿼리를 통해 자신만의 질문에 답할 수 있도록 데이터에 접근할 수 있게 해야 한다. 실시간 데이터와 이력(추세, 이상 감지) 모두 필요하다.
문제를 감지하고 자동으로 수정한다. 대부분의 경우 자동화 시스템이 사람을 기다리지 않고 문제에 대응해야 한다. 자동화가 해결할 수 없을 때만 누군가가 호출되어야 한다. 그 알림은 무엇이 잘못되었는지 설명해야 하며, 단순히 원시 숫자를 보여주면 안 된다.
사람들에게 필요한 것을 보여준다. 너무 많거나 잘못된 것을 보여주는 대시보드는 쓸모없다. 네트워크 운영 팀에게는 그들의 뷰를, 비즈니스에게는 그들의 뷰를, 엔지니어에게는 그들의 뷰를 제공하라. 각 사람은 자신의 업무에 도움이 되는 것을 받아야 한다.

6.1.3. 기둥#

각 목표는 작동하기 위해 특정 구성 요소가 필요하다. 필요한 것들은 다음과 같다.

무엇을 관찰할지 파악한다. SoT에 모든 장치, 서비스, 자격 증명이 있다. 가시성 시스템은 자동으로 해당 데이터를 가져와 수집기가 무엇을 모니터링해야 할지 알 수 있게 해야 한다. SoT에 장치를 추가하면 자동으로 모니터링이 시작된다.
효율적으로 데이터를 수집한다. 다양한 수집 방법이 필요하다. 구형 장치를 위한 Simple Network Management Protocol (SNMP), 현대 장치를 위한 gRPC Network Management Interface (gNMI) 스트리밍, 이벤트를 위한 System Logging Protocol (Syslog), 트래픽을 위한 플로우(NetFlow, IP Flow Information Export (IPFIX)), 심층 문제 해결을 위한 패킷 캡처까지. 도구마다 다르고, 속도도 다르며, 데이터의 풍부함도 다르다. 좋은 소식은 하나만 선택할 필요가 없다는 것이다.
모든 것을 정규화한다. Arista 메트릭은 Cisco 메트릭과 다르게 생겼고, 클라우드 제공업체 메트릭과도 다르다. 로그는 비정형 텍스트이고, 플로우는 바이너리다. 이 모든 것을 공통 언어로 변환하고 맥락(어떤 장치, 어떤 고객, 어떤 서비스)을 추가하는 계층이 필요하다.
규모에서 안정적으로 데이터를 이동한다. 전통적인 모니터링 파이프라인은 순차적이다. 수집기 → 처리기 → 저장소. 규모에서는 이것이 병목이 된다. 각 단계가 독립적으로 확장될 수 있도록 분리하는 메시지 버스와 스트리밍 플랫폼이 필요하다.
스마트하게 저장한다. 시계열 데이터(메트릭)는 이에 최적화된 데이터베이스가 필요하다. 로그는 다른 것이 필요하다. 수백만 개의 데이터 포인트를 밀리초 내에 쿼리할 수 있어야 한다. 모든 데이터베이스가 같지 않다.
데이터를 행동으로 전환한다. 원시 메트릭이 자동화를 트리거하지 않는다. 규칙이 필요하다. “CPU가 90%를 넘으면, 예정된 유지보수인지 확인하고, 아니라면 다음 단계를 수행하라.” 그리고 이 규칙들은 자동화 오케스트레이터나 알림 시스템에 공급된다.
시각적으로 보여준다. 아무도 보지 않는다면 데이터는 쓸모없다. 대시보드가 필요하지만, 스마트한 대시보드여야 한다. 다양한 사람을 위한 다양한 뷰, 드릴다운 가능, 추세와 비교를 보여줄 수 있어야 한다.

마지막으로, 이 일곱 가지 기능을 상세히 설명하기 전에 가시성의 범위가 무엇인지 명확히 하자.

6.1.4. 범위#

위에서 소개한 목표를 확장하여, 가시성의 책임 범위에 속하는 다른 항목들도 있다.

사용자 관점(기술적, 운영적, 비즈니스적)에 맞춰 조정된 다양한 수준의 관찰
CI/CD 파이프라인과의 통합, 자동화된 테스트 및 검증을 위한 피드백 제공
자동화 시스템 자체의 가시성(Collector, 처리기, 알림 시스템의 메타 모니터링)

반면, 아키텍처의 다른 구성 요소에 속하는 기능들도 있다.

네트워크 인텐트 정의: 네트워크가 어떻게 보여야 하는지 (인텐트/SoT의 책임)
네트워크 변경 실행: 실제로 수정을 구현하는 것 (Executor의 책임)
복잡한 워크플로 오케스트레이션: 여러 시스템에 걸친 다단계 수정을 조율하는 것 (Orchestrator의 책임)

이 명확한 경계는 Observability가 감지와 인사이트에 집중하고, 다른 구성 요소들이 인텐트 정의, 실행, 오케스트레이션을 처리하도록 보장한다.

현대적인 가시성으로의 전환에는 신중한 계획이 필요하다. 단순히 하나의 모니터링 도구를 다른 것으로 교체하는 것처럼 간단하게 생각하지 마라. 마인드셋 자체를 변환해야 한다. 더 많은 권한에는 더 많은 책임이 따르며, 선택하고 조정할 것들도 더 많아진다.

이 핵심 개념들을 소개하는 초기 도입부를 마쳤으니, 이제 각 기능으로 들어가 보자.

6.2. 기능#

일곱 가지 목표와 기둥은 일곱 가지 핵심 기능을 통해 실현된다. 각 기능은 하나의 목표와 그것을 뒷받침하는 기둥에 매핑되어, 비즈니스 요구사항에서 기술적 구현까지 직접적인 연결 고리를 만든다.

인벤토리(Inventory): SoT에서 인텐트를 가져와 메타데이터, 장치 목록, 수집 대상을 모든 하위 구성 요소에 제공한다.
Collector: 풀 기반(폴링)과 푸시 기반(스트리밍) 모두를 포함하여 다양한 프로토콜과 수집 방법을 사용해 네트워크에서 관찰 데이터를 가져온다.
처리기(Processor): 이기종 데이터를 공통 스키마로 정규화하고, 맥락 메타데이터(태그, 관계, 비즈니스 맥락)로 풍부하게 만들며, 그 외 다양한 데이터 작업을 수행한다.
분산(Distribution): 분산되고 비동기적인 패턴을 사용하여 데이터 생산자와 소비자를 분리한다. Collector에서 처리기를 거쳐 영속성 및 알림 시스템까지 데이터와 이벤트를 안정적으로 이동시킨다.
영속성(Persistence): 정규화된 데이터를 규모에 맞게 효율적인 수집, 보존, 쿼리를 위해 최적화된 데이터베이스에 저장한다.
알림(Alerting): 유연한 규칙과 임계값을 사용하여 영속화된 데이터를 분석하고 관심 있는 조건을 감지하여, 외부 시스템(자동화 또는 사람에 대한 알림)을 트리거하는 이벤트를 생성한다.
시각화(Visualization): 관찰된 데이터와 트리거된 이벤트를 서로 다른 사용자 대상과 사용 사례에 맞게 조정된 대시보드, 보고서 및 기타 시각적 인터페이스로 렌더링한다.

graph LR

    %% --- Subgraphs ---
    subgraph 목표
        direction TB
        A1[최소한의 인력으로 전체 네트워크 관찰]
        A2[충분한 데이터와 정확도로 이기종 네트워크 환경 지원]
        A3[맥락을 갖춘 다양한 IT 계층 데이터 관찰]
        A4[대규모 네트워크 시나리오 처리]
        A5[거의 실시간으로 정교한 분석을 위한 데이터 접근 제공]
        A6[네트워크 문제를 선제적으로 감지하고 복구 시간 단축]
        A7[사용자 중심의 맞춤형 시각화 제공]
    end

    subgraph 기둥
        direction TB
        B1[모니터링 대상 파악을 위한 SoT와의 긴밀한 통합]
        B2[매우 빈번하거나 온디맨드 업데이트를 지원하는 다양한 프로토콜로 데이터 수집]
        B3[풍부한 분석을 위한 맥락 메타데이터가 포함된 이기종 데이터 정규화]
        B4[스케일아웃 아키텍처를 지원하는 확장 가능한 데이터 분산 시스템]
        B5[시계열 데이터와 강력한 쿼리 언어를 지원하는 영속성 계층]
        B6[외부 시스템 통합이 포함된 유연한 규칙 정의 및 라우팅 시나리오]
        B7[다중 데이터 저장소를 통합하는 맞춤형 시각화]
    end

    subgraph 기능
        direction TB
        C1[인벤토리]
        C2[수집기]
        C3[처리기]
        C4[분산]
        C5[영속성]
        C6[알림]
        C7[시각화]
    end


    %% --- Row connections ---
    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5
    A6 --> B6 --> C6
    A7 --> B7 --> C7

    %% --- Row gradient classes ---
    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;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;
    classDef row6 fill:#80bfff,stroke:#4a90e2,stroke-width:1px;
    classDef row7 fill:#66b2ff,stroke:#4a90e2,stroke-width:1px;

    %% --- Apply classes per row ---
    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;
    class A6,B6,C6 row6;
    class A7,B7,C7 row7;

이 구성 요소들은 데이터 파이프라인 또는 ETL(추출, 변환 및 로드)로 볼 수 있으며, 다음 다이어그램으로 표현된다.

flowchart TB
    A[네트워크] --> B[수집기]

    subgraph Observability
       direction LR
       B --> C[분산] -->  D[영속성]
       B -.-> P[처리]
       C -.-> P
       D -.-> P
       D --> E[알림]
       E -.-> P
       D --> G[시각화]
       X[인벤토리] -.-> B
       X -.-> G
       X -.-> P
    end

    E -.-> F[오케스트레이션]
    G -.-> H[프레젠테이션]
    Y[SoT] -.-> X

그림 1: 가시성 파이프라인.

6.2.1. 인벤토리#

인벤토리 구성 요소는 단순한 질문에 답한다. 무엇을 모니터링해야 하는가?

이 데이터는 이미 어딘가에 있다. SoT에 있다. 장치 이름, IP 주소, 장치 유형, 활성 여부, 자격 증명이 있다. 수동으로 이를 복제하지 마라. 자동으로 가져와라.

SoT에서 필요한 것들:

각 장치 또는 서비스의 고유한 이름 또는 ID (자신이 생각하는 장치임을 알 수 있도록)
접근 방법: IP 주소, 호스트명, 자격 증명 (장치에서 능동적으로 데이터를 가져와야 하는 경우)
장치 유형: 타입과 벤더 (어떤 Collector가 작동하는지 알 수 있도록)
활성 여부: 계획됨, 활성, 또는 폐기 중인지 (예상된 다운타임에 대해 알림이 오지 않도록)

기본 외에도 다음을 고려할 수 있다.

OS 또는 장치 세부 정보: 일부 장치는 다른 프로토콜을 사용하거나 특수 처리가 필요한 구형 장치임
맥락: 소유자, 위치, 어떤 고객이 의존하는지 (알림 및 대시보드 필터링에 유용)

왜 목록을 수동으로 관리하는 대신 자동화하는가? 사람들은 목록 업데이트를 잊기 때문이다. 장치가 추가되어도 아무도 모니터링에 알리지 않고, 갑자기 가시성이 없어진다. 하지만 가시성 시스템이 SoT에서 읽는다면, SoT에 장치를 추가하면 자동으로 모니터링된다.

푸시(Push) 대 풀(Pull)?

풀: 가시성 시스템이 주기적으로 SoT에서 업데이트를 확인한다. 단순하지만, 간격 중간에 변경이 발생하면 놓치게 된다.
푸시: SoT가 변경될 때 자동으로 가시성 시스템에 신호를 보낸다(웹훅, 메시지 버스). 더 빠르고 안정적이다.

SoT에 좋은 데이터가 있고 실제 통합(수동 복사-붙여넣기가 아닌)이 구현되어 있다면, 인벤토리는 자동화되어 새로운 장치를 절대 놓치지 않는다.

6.2.2. 수집기(Collectors)#

데이터는 어딘가에서 와야 한다. Collector는 네트워크와 Observability 플랫폼 사이의 다리다. 장치에서 데이터를 가져오거나(또는 수신하여) 파이프라인에 공급하는 역할을 한다. 효과적인 Collector가 없으면 하위의 모든 것은 쓸모없다.

데이터 흐름의 주도권 관점에서 두 가지 기본 접근 방식이 있다.

수동(Passive) 또는 푸시(Push): 장치가 수집기에 데이터를 보낸다. 라우터로부터 로그 메시지를 수신하는 syslog 서버, 또는 플로우 레코드를 수신하는 IPFIX 수집기를 생각해 보라. 장치가 무엇을 언제 보낼지 결정한다.
능동(Active) 또는 폴링(Poll): Collector가 장치에 데이터를 요청한다. Simple Network Management Protocol (SNMP), gRPC Network Management Interface (gNMI), Representational State Transfer (REST) Application Programming Interface (API)를 사용하거나 스트리밍 데이터를 구독하여 각 장치에 연결하고 정보를 가져온다. Collector가 주도권을 갖는다. 무엇을 요청할지, 언제 요청할지 결정한다.

배포 방식으로도 수집기를 분류할 수 있다.

에이전트리스(Agentless): 장치에 소프트웨어를 설치하지 않는다. 중앙 수집기 서버(보통 다른 곳에서 실행됨)가 각 장치에 개별적으로 연결한다. 시작하기 쉽지만 규모가 커지면 병목이 될 수 있다.
에이전트 기반(Agent-based): 각 장치나 서비스에 소형 에이전트를 설치한다. 에이전트가 중앙 위치로 데이터를 푸시하거나 로컬 소스에서 직접 가져온다. 더 분산되어 확장하기 쉽지만 관리해야 할 구성 요소가 더 많다.

수집 방법과 관계없이, 네트워크 자동화 환경에서 관심 가질 만한 다양한 데이터 유형을 강조하는 것이 중요하다. 네 가지 큰 범주로 분류한다.

관리 평면(Management plane): 장치의 상태, 또는 구성, 로그, 네트워크 통계에 대한 데이터를 읽는다. 이 그룹의 프로토콜로는 Simple Network Management Protocol (SNMP), System Logging Protocol (Syslog), gRPC Network Management Interface (gNMI), NETCONF, RESTCONF가 있다.
제어 평면(Control plane): 레이어 2 또는 레이어 3 포워딩 테이블과 같은 네트워크의 패킷 포워딩을 결정하는 분산 프로토콜이 실행되는 곳이다. OSPF, IS-IS, BGP가 제어 평면 프로토콜의 몇 가지 예다. Ping이나 Traceroute 같은 기술 또는 BMP 같은 텔레메트리 프로토콜로 관찰할 수 있다.
포워딩 평면(Forwarding plane): 패킷이 이동하는 평면(예: 네트워크 인터페이스)으로, 데이터 볼륨과 속도 측면에서 가장 요구가 많다. 자연스럽게 이를 관찰할 때 패킷을 포워딩하는 평면의 주요 목표에 영향을 미치지 않는 것도 중요하다. 이 그룹에는 TcpDump, IPFIX, sFlow, Netflow, Cisco SLA, PSAMP, eBPF 같은 도구들이 있다.
외부 데이터(External data): 네트워크 장치에 특정하지 않은 모든 것을 포함한다. 예를 들어, 외부 자산 관리 시스템이나 물리적 사물인터넷(IoT) 센서에서 오는 특정 인터페이스의 회선 제공업체 정보 및 담당자 연락처가 이 광범위한 분야에 해당할 수 있다.

flowchart TB
    subgraph Network Device/Service
        direction TB
        A[관리 평면]
        B[제어 평면]
        C[포워딩 평면]
        A --> B
        B --> C
    end

    D[외부 데이터]

그림 2: 수집기의 범위.

Command Line Interface (CLI) 출력을 화면 스크래핑하는 것을 중단하라. 다들 하고 있다는 거 안다. 우리 모두 그랬다. 하지만 2026년이고 이제 모든 주요 벤더가 제대로 된 텔레메트리를 지원한다.

CLI 스크래핑은 취약하고(벤더가 출력 형식을 바꿈), 느리며(화면 스크래핑과 텍스트 파싱은 비용이 많이 듦), 불안정하고(무작위 명령 타임아웃), 확장이 매우 어렵다. 장치가 너무 구식이어서 CLI밖에 없다면, 교체하거나 제한된 가시성을 수용하라. 가장 낮은 공통 분모를 기준으로 전체 모니터링 스택을 구축하지 마라.

실제로 수집하는 것에 대해 두 가지 핵심 질문으로 귀결된다.

무엇을 수집할 것인가: 메트릭? 로그? 플로우 레코드? 각각 데이터 모델이 다르다. SNMP는 MIB가 있고, 현대 장치는 gNMI로 말하며, 애플리케이션은 OpenTelemetry를 사용한다. 모든 것을 상관 분석할 수 있는 보편적인 표준이 꿈이지만 아직 존재하지 않는다. 그래서 다른 형식들을 일관된 것으로 변환하는 자체 변환 계층을 구축해야 할 수도 있다(이것이 다음에 나오는 처리 계층이 하는 일이다).
어떻게 가져올 것인가: 어떤 프로토콜을 쓸 것인가? SNMP는 오래되었지만 안정적이고, gNMI는 현대적이며 데이터를 지속적으로 밀어 넣고, IPFIX는 실제로 흐르는 것을 포착한다. 관찰하려는 것에 따라 다르다.

이 표는 수집할 수 있는 것과 사용 가능한 도구를 요약한다.

데이터 유형	프로토콜 / 수집 방법	비고 / 예시
메트릭	Simple Network Management Protocol (SNMP), Hypertext Transfer Protocol (HTTP) 스크래핑, Command Line Interface (CLI) 폴링, OpenTelemetry (OpenTelemetry Protocol (OTLP)), 스트리밍 텔레메트리 (gRPC Network Management Interface (gNMI))	장치 메트릭, 호스트 메트릭, 애플리케이션 메트릭
로그	OpenTelemetry (OTLP), 파일 테일링, syslog	애플리케이션 로그, 시스템 로그, 구조화된 로그
트레이스	OpenTelemetry (OTLP)	서비스 전반의 분산 추적
네트워크 플로우	NetFlow, IPFIX	트래픽 플로우, 소스/목적지 분석
프로토콜 특정	BMP, BGP, ARP, OSPF	BGP 모니터링(BMP), ARP 테이블, BGP 테이블, OSPF 테이블
패킷 캡처	PCAP (libpcap), SPAN / TAP	전체 패킷 검사, 심층 문제 해결

표 1: 수집할 데이터와 프로토콜.

다양한 옵션에 대한 더 깊은 이해를 위해서는 Modern Network Observability 책을 참조하라.

네트워크 데이터 수집은 데이터센터, ISP 백본, 클라우드 네트워크 서비스, Linux 커널 인터페이스, 또는 원시 패킷에 적용된다. 환경에 따라 다르다.

핵심은 이것이다. 무엇을 수집할지 결정하기 전에 해결하려는 문제에서 시작하라. 그 결정이 다른 모든 것을 이끈다. 인터페이스 포화를 감지하는가? BGP 수렴을 모니터링하는가? DDoS 트래픽을 추적하는가? 문제가 필요한 데이터와 얼마나 자주 필요한지를 결정한다.

최근 채택이 증가하고 있는 몇 가지 패턴들이 있다. 수집 데이터의 빈도를 높이거나(일부 경우 유용) 수집 방법을 통합하기 위한 것들이다.

스트리밍 텔레메트리(Streaming Telemetry)

장치가 YANG 모델을 사용하여 지속적으로 데이터를 푸시한다. 구독을 설정하면 실시간으로 데이터가 흐른다. 두 가지 방식이 있다.

다이얼인(Dial-In): 수집기가 장치에 스트리밍 시작을 요청한다(수집기가 시작).
다이얼아웃(Dial-Out): 장치가 미리 구성되어 데이터를 스트리밍한다(장치가 시작).

폴링보다 훨씬 낮은 지연 시간이며, 장치가 흐름을 제어한다.

flowchart TB
    A[수집기]
    B[장치]
    A -.->|다이얼인| B
    B -->|스트리밍| A
    B -.->|다이얼아웃| A

그림 3: 스트리밍 텔레메트리.

Hypertext Transfer Protocol (HTTP) 노출 메트릭

Hypertext Transfer Protocol (HTTP) 스크래핑(풀 기반 메트릭)은 단순하고 잘 확장된다. Simple Network Management Protocol (SNMP)도 이를 수행하지만, 점점 더 많은 네트워크 OS가 Prometheus 형식으로 Hypertext Transfer Protocol (HTTP)를 통해 직접 메트릭을 노출하고 있다. Collector가 소비하기 더 쉽고, 특별한 Simple Network Management Protocol (SNMP) Management Information Base (MIB) 파싱이 필요 없다. SONiC, Cumulus, Arista EOS 등이 모두 이 방식으로 메트릭을 노출한다.

벤더 / OS	메트릭 유형	예시 메트릭
SONiC	인터페이스 트래픽	`sonic_interface_rx_bytes_total{interface="Ethernet32"} 1.234e+12`
NVIDIA Cumulus	인터페이스 트래픽	`node_network_receive_bytes_total{device="swp1"} 9.21e+10`
Arista EOS	인터페이스 트래픽	`arista_interface_in_octets_total{interface="Ethernet1"} 8.3e+11`

표 2: HTTP 노출 메트릭.

스크래핑 방식은 낮은 지연 시간과 거의 실시간 메트릭, 풍부한 레이블, 풀 기반 수집(속도/타임아웃의 중앙 제어)을 제공하며, 클라우드 규모의 가시성과 잘 연결된다.

OpenTelemetry

OpenTelemetry는 텔레메트리 데이터를 수집, 처리, 내보내기 위한 벤더 중립 표준 및 툴킷이다. 네트워크, 시스템, 애플리케이션 전반에 걸쳐 메트릭, 로그, 트레이스를 통합하는 공통 텔레메트리 언어와 파이프라인으로 생각하면 된다.

SNMP, NetFlow, gNMI, BMP 같은 네트워크 프로토콜을 대체하지 않는다. 대신 수집 후 텔레메트리가 표현되고 전송되는 방식을 표준화한다.

전통적인 네트워크 모니터링에서는 데이터 모델이 다양하고 스키마와 이름 지정에 벤더별 방식을 사용하여 계층 간(네트워크 ↔ 시스템 ↔ 애플리케이션) 상관 분석이 어렵다. 반면 OpenTelemetry는 다음을 제공한다.

메트릭, 로그, 트레이스에 대한 공통 데이터 모델
gRPC Remote Procedure Call (gRPC) 또는 Hypertext Transfer Protocol (HTTP)를 통한 표준 전송 프로토콜(OpenTelemetry Protocol (OTLP))
여러 신호 유형을 위한 단일 처리 파이프라인

Grafana Alloy나 Telegraf는 OpenTelemetry Protocol (OTLP)를 구현한 Collector의 예다. 다양한 익스포터에서 데이터를 수집하고 메트릭(Prometheus 호환 Time Series Database (TSDB)), 로그(Loki, Elasticsearch, ClickHouse) 및 트레이스(Tempo, Jaeger) 같은 다양한 백엔드로 내보낸다.

이는 Input, Processor, Output 단계를 갖춘 현대적인 플러그인 가능한 수집기의 공통 구조로 이어진다. 예를 들어 Telegraf에서 OTLP는 출력 플러그인 옵션이다.

아키텍처 선택으로서의 OpenTelemetry

OpenTelemetry 채택은 단순한 도구 결정이 아니라 가시성 파이프라인을 어떻게 통합할지에 대한 아키텍처 결정이다. 두 가지 접근 방식 중 선택이다.

프로토콜 네이티브(Protocol-native): 각 신호 유형이 처음부터 끝까지 고유한 프로토콜을 통해 이동한다(gNMI → Prometheus, syslog → Elasticsearch, NetFlow → ClickHouse). 각 파이프라인은 해당 신호에 최적화되어 있다. 비용은 공유 데이터 모델 없이 여러 독립적인 파이프라인을 갖게 되어 신호 유형 간 상관 분석이 비용이 많이 든다는 것이다.

OTel 네이티브(OTel-native): 신호가 가능한 한 빨리 OpenTelemetry Protocol (OTLP)로 변환되어 단일 파이프라인을 통해 통합 백엔드로 흐른다. 공통 데이터 모델을 공유하기 때문에 메트릭, 로그, 트레이스 간의 상관 분석이 자연스럽다. 비용은 네트워크 장치의 OTel 지원이 아직 성숙하지 않아서 대부분의 벤더가 OTLP를 기본적으로 내보내지 않아 어댑터 계층(gNMI → OTel, SNMP → OTel)이 필요하고 운영 복잡성이 증가한다는 것이다.

현재 네트워크 자동화 환경을 위한 실용적인 권고사항: 벤더 지원이 강력한 애플리케이션 인접 신호(자동화 플랫폼 텔레메트리, 서비스 상태, 구조화된 애플리케이션 로그)에는 OTel을 채택하고, 장치 측 OTel 지원이 성숙할 때까지 전통적인 네트워크 텔레메트리(SNMP 폴링, gNMI 스트리밍)에는 프로토콜 네이티브 파이프라인을 계속 사용하라. 모든 네트워크 장치에 어댑터가 필요한 성급한 표준화를 강요하기보다는 두 가지 접근 방식을 나란히 수용할 수 있도록 파이프라인을 설계하라.

추세는 명확하다. OpenTelemetry는 결국 모든 가시성 데이터의 표준이 될 것이다. 자동화 플랫폼 자체에 먼저 적용하는 것(챕터 5의 메타 모니터링)은 네트워크 장치로 확장하기 전에 경험을 쌓는 저위험 첫 단계다.

수집기 아키텍처

단순하게 보면, 모든 수집기는 세 부분으로 나눌 수 있다(때로는 플러그인 방식이고, 때로는 더 고정되어 있다).

flowchart LR
    A[입력] --> B[처리기] --> C[출력]

그림 4: 수집기 아키텍처.

입력(Input): 무엇을 관찰해야 하고 어떤 파라미터로 할지 정의한다.
처리기(Processor): 선택적이지만, 데이터가 데이터 파이프라인에 진입하는 순간 데이터 구조 일관성을 보장하는 데 매우 편리하다. 처리는 매우 복잡해질 수 있고 규모에서 성능에 영향을 미칠 수 있으므로 모든 처리를 이 수준에서 할 필요는 없다.
출력(Output): 수집기가 파이프라인으로 데이터를 이동하는 방법을 보여준다. 처리나 영속성 같은 다른 블록으로 직접 보내거나, 분산 구성 요소를 사용하여 확장할 수 있다.

Telegraf, Grafana Alloy, gNMIc, PMACCT, goflow 등 많은 수집기가 있지만(각각 다른 기능을 가짐), 유사한 아키텍처를 사용한다. 따라서 하나를 선택할 때(때로는 여러 개가 필요할 수 있음) 다음과 같이 접근하라.

장치 기능: 장치가 어떤 프로토콜을 지원하는가?
데이터 볼륨: 고볼륨에는 스트리밍, 저볼륨에는 폴링이 적합하다.
지연 시간 요구사항: 거의 실시간 대 전통적인 간격.
팀 스킬 및 백엔드와의 생태계 적합성.

Suzieq, Kentik 등의 “완전한” 네트워크 가시성 솔루션들도 커버하는 관찰성 데이터를 위한 내장 수집기를 구현한다.

데이터가 수집된 후, 소개된 단계 중 하나는 파이프라인의 다양한 단계에서 데이터를 조작하는 처리기다.

6.2.3. 처리기(Processor)#

수집기에서 나온 원시 데이터는 지저분하다. 장치마다 메트릭을 다르게 내보내고, 로그는 비정형 텍스트이며, 값이 서로 다른 단위일 수도 있다. 처리기 계층은 이를 정리하고 유용하게 만든다.

목표: 데이터가 수신되면 여러 소스의 신호를 통합하고, 상관 분석하며, 추가 맥락으로 풍부하게 만들기 위해 공통 표준을 준수해야 한다. 이 처리기 단계 없이는 가시성 파이프라인이 빠르게 단편화되고, 쿼리하기 어렵고, 운영 비용이 많이 든다. 규모, 복잡성, 운영 요구사항에 따라 여러 기회에서 처리할 수 있다.

다음은 가시성 파이프라인에 적용되는 일반적인 처리 작업들이다.

6.2.3.1. 정규화/변환#

데이터는 다양한 형식으로 온다. Arista는 한 방식으로 메트릭을 보내고, Cisco는 다른 방식으로, syslog는 텍스트이며, NetFlow는 바이너리다. 정규화는 이 모든 것을 공통 형식으로 변환하여 백엔드가 50가지 다른 방언을 이해할 필요가 없도록 한다.

구조화(Structuring)

장치는 자신에게 의미 있는 방식으로 데이터를 내보낸다. 이를 분석에 적합한 형식으로 변환하는 것이 우리의 역할이다.

로그 기반:

Mar 18 14:22:11 leaf01 IFACE-5-STATE: swp1 oper-state changed from UP to DOWN

변환 후:

{
"timestamp": "2025-03-18T14:22:11Z",
"level": "INFO",
"device": "leaf01",
"component": "interface",
"event": "oper_state_change",
"interface": "swp1",
"previous_state": "UP",
"current_state": "DOWN"
}

메트릭 기반: <metric name>{<labels>} <value>

interface_admin_state{hostname="leaf01", ifname="swp1"} 1
interface_oper_state{hostname="leaf01", ifname="swp1"} 0
interface_speed_bps{hostname="leaf01", ifname="swp1"} 100000000000
interface_in_errors_total{hostname="leaf01", ifname="swp1"} 0
interface_out_errors_total{hostname="leaf01", ifname="swp1"} 12

테이블 기반: 일부 도구(예: Suzieq)는 데이터를 표 형식의 시간 인덱스 상태 뷰로 구성한다.

| hostname | ifname | adminState | operState | speed | inErrors | outErrors | timestamp |
|----------|--------|------------|-----------|-------|----------|-----------|-----------|
| leaf01   | swp1   | up         | up        | 100G  | 0        | 0         | t1        |
| leaf01   | swp1   | up         | down      | 100G  | 0        | 12        | t2        |

이름 변경 및 정렬(Renaming and alignment)

서로 다른 텔레메트리 소스는 같은 개념을 다른 이름, 경로, 레이블 규칙으로 설명한다. 예를 들어:

Openconfig: /interfaces/interface/state/oper-status value: UP tags: source=192.0.2.1 and interface_name=eth1
SNMP: ifOperStatus{ifName="GigabitEthernet0/1", device="router01"} 1
Native Prometheus: interface_oper_state{interface="swp1", host="leaf01"} 1

정규화는 이를 일관된 모델로 맞춘다. 객체 이름, 레이블 이름 변경, 값(동일한 단위 변환 사용) 포함:

intf_oper_state{name="eth1", device="192.0.2.1"} 1
intf_oper_state{name="GigabitEthernet0/1", device="router01"} 1
intf_oper_state{name="swp1", device="leaf01"} 1

6.2.3.2. 풍부화(Enrichment)#

풍부화는 실제로 관찰된 것 이상의 추가 내용을 가시성 데이터에 더한다. 데이터에 추가된 이 여분의 차원들은 더 정교한 데이터 활용을 가능하게 한다. 예를 들어, 메트릭이 네트워크에서 특정 역할을 하는 장치에 속한다는 것을 이해하고 그에 따라 행동할 수 있다.

풍부화에는 두 가지 주요 접근 방식이 있다.

데이터 확장(Extending data) 관찰된 데이터에 추가 메타데이터나 레이블을 추가하여 보완한다. 이 데이터는 정적일 수 있고(예: 모든 데이터에 org=my-company 표시), 수집 맥락에 따라 동적일 수 있으며(예: collector_id=1234), 또는 관찰된 데이터 자체를 기반으로 동적일 수 있다(예: hostname=rtr-1이 주어지면 SoT와 상관 분석하여 location=BCN-01 레이블 생성).
```
intf_oper_state{
    name="swp1", 
    device="leaf01",
    role="leaf",
    location="BCN0001"
} 1
```
새 데이터 생성(Creating new data) Prometheus 생태계의 “info metrics” 패턴을 따라, 실제 상태를 나타내지 않지만 의도된 상태를 나타내는 메트릭을 생성할 수 있다. 이러한 메트릭은 이후 가시성 파이프라인 단계에서 분석에 더 많은 차원을 추가하는 데 유용하며, 알림 섹션에서 확인할 수 있다.
```
device_info{
    name="leaf1",
    role="leaf",
    vendor="arista",
    model="7050SX3",
    platform="eos",
    os_version="4.29.2F",
    location="BCN0001",
    rack="AB1",
    rack_unit="U32",
    environment="prod"
} 1
```
info metrics는 관련 데이터가 값(예: 위 메트릭의 1)이 아닌 레이블에 있는 독특한 유형의 데이터다. 이 방식은 문자열 같은 일부 값 유형을 지원하지 않는 Time Series Database (TSDB)를 재사용할 수 있게 해준다.

두 접근 방식 모두 레이블과 맥락을 추가한다. 알림과 분석에 강력하다. 하지만 고려해야 할 비용이 있다.

카디널리티(Cardinality): 모든 새 레이블이 시계열을 곱한다. 장치 × 인터페이스 × 메트릭은 이미 고카디널리티다. 레이블을 부주의하게 추가하면 저장소가 폭발하고 쿼리가 느려진다. 신중하게 생각하라.
업데이트 빈도(Update frequency): 장치 랙과 관리 IP는 매초 바뀌지 않는다. 변동성이 높은 메트릭처럼 풍부화 데이터를 폴링하지 마라. 이벤트 기반 업데이트가 더 잘 작동하며, SoT에 대한 쿼리도 줄어든다.
복원력(Resilience): SoT가 오프라인이 되면 풍부화가 중단된다. 저하된 상태로도 계속 운영할 수 있도록 캐시하라. 자동화가 이 데이터에 의존하므로 안정적으로 만들어라.

6.2.3.3. 변환/파생/집계#

원시 메트릭을 가져와 새로운 것을 도출한다. 예: 리프와 스파인 스위치의 모든 인터페이스 입력 트래픽을 단일 “패브릭 대역폭 사용” 메트릭으로 통합하여 추세 분석에 사용한다. 더 큰 질문에 답하거나 대시보드에 공급하기 위해 기존 데이터를 결합하는 것이다. Prometheus는 이를 “recording rules"라고 부른다.

- record: fabric:interface:in_bps
expr: 
    (
    sum by (fabric, role, hostname, name) (
        rate(interface_in_octets_total{role=~"leaf|spine"}[5m])
    ) * 8
    )
    * on (hostname, name) group_left (fabric, role)
    sot_interface_info{role=~"leaf|spine"}

Prometheus 생태계에서 이것은 recording rules로 알려져 있다.

데이터 양을 줄이기 위한 또 다른 처리 기능은 최종 데이터 사용 목적에 맞게 차원을 줄이는 집계다. 예를 들어 장치별 인터페이스 정보 요약, 또는 사이트별 장치 정보 요약. 카운터 메트릭에서 속도 계산을 생성하거나 히스토그램 버킷팅은 많은 분석에 유용할 수 있다.

6.2.3.4. 필터링(Filtering)#

초기에 불필요한 것을 제거하라. 모든 로그 라인이 저장할 가치가 있는 것은 아니다. 모든 인터페이스 메트릭이 중요한 것도 아니다(루프백은 신경 쓰지 않을 수도 있다). 빨리 필터링할수록 저장소와 처리에 낭비가 줄어든다. 허용 목록(이것만 유지)이 차단 목록(저것은 제거)보다 더 안전하다.

6.2.3.5. 샘플링/조절(Sampling / Throttling)#

필터링 후에도 볼륨이 너무 높을 수 있다. 조절하라. 확률적으로 샘플링하거나(“이 요청의 10% 유지”), 상위 K 메트릭에 집중하거나(“가장 바쁜 인터페이스 100개만 저장”), 소스당 속도 제한을 설정하라(“장치당 최대 1000개 메트릭”). 데이터베이스의 데이터가 오래될수록 롤업하여(5초 단위가 5분 평균이 됨) 공간을 절약한다.

마지막으로, 이 모든 처리기는 사용 사례에 따라 가시성 파이프라인의 다양한 단계에서 실행될 수 있다.

수집기: 가벼운 초기 정규화와 필터링에 최적
전용 처리기: 규모에서 동적 풍부화와 복잡한 변환에 필요
영속성 계층: recording rules 및 장기 롤업에 적합 (정규화는 항상 이 전에 이루어져야 함)
알림 계층: 저장된 데이터에서 이벤트를 도출하고 비즈니스 로직 적용

실제로 효과적인 가시성 파이프라인은 도구, 규모, 운영 제약에 따라 여러 계층에 걸쳐 처리를 분산한다.

6.2.4. 분산(Distribution)#

단순한 선형 파이프라인(수집기 → 처리기 → 데이터베이스)은 확장되지 않는다. 데이터베이스가 느려지면 수집기가 막힌다. 처리기를 업그레이드해야 하면 수집을 멈춰야 한다. 모든 것이 긴밀하게 결합되어 있고 취약하다.

여기서 메시지 브로커가 등장한다.

Apache Kafka나 NATS 같은 메시지 브로커가 중간에 위치한다. 생산자(수집기, 장치)가 토픽에 게시한다. 소비자(처리기, 데이터베이스, 알림)가 자신의 속도에 맞게 가져간다. 완전히 분리된다.

이점:

확장성: 각 구성 요소가 독립적으로 확장된다.
복원력: 소비자가 느리면 데이터가 드롭되지 않고 큐에 쌓인다.
유연성: 소스에서 중복 없이 동일한 데이터가 여러 백엔드에 공급된다. 다른 구성 요소에 영향을 주지 않고 하나를 업그레이드하거나 재시작할 수 있다.

확장 및 안정성 패턴에 대한 자세한 내용은 챕터 11을 참조하라.

6.2.5. 영속성(Persistence)#

데이터가 처리되면 어딘가에 저장되어야 한다. 데이터베이스 계층은 모든 가시성 데이터를 저장한다. 대용량을 처리하고, 빠른 쿼리를 지원하며, 비용을 적절하게 유지해야 한다.

가시성에 적합한 데이터베이스는 공통적인 특성을 공유한다.

시간 인식(Time-aware): 데이터는 본질적으로 타임스탬프가 있다. 데이터베이스는 범위 쿼리와 시간 창 계산에 최적화한다.
높은 쓰기 처리량(High write throughput): 지속적인 메트릭 수집. 데이터베이스는 느려지지 않고 이를 처리한다.
다차원(Multi-dimensional): 메트릭에는 레이블이 있다(장치, 인터페이스, 위치). 효율적으로 쿼리하고 집계한다.
유연한 쿼리(Flexible queries): 미리 정의된 스키마 없이 데이터를 탐색하기 위한 표현적인 언어(PromQL, LogQL)가 필요하다.
생명주기 관리(Lifecycle management): 저장소는 빠르게 증가한다. 비용 통제를 위한 보존, 다운샘플링, 삭제를 지원한다.
스키마 유연성(Schema flexibility): 새로운 메트릭이 지속적으로 나타난다. 데이터베이스는 비용이 많이 드는 마이그레이션 없이 변화를 처리한다.

어떤 데이터베이스 유형이 효과적인가?

단일 데이터베이스가 모든 가시성 워크로드를 완벽하게 처리하지는 못하며, 그렇다고 주장하는 사람은 무언가를 팔려는 것이다. 실제로 효과적인 것들은 다음과 같다.

시계열 데이터베이스(Time Series Database (TSDB)): 여기서 시작하라. Prometheus가 메트릭 전쟁에서 이겼다. 데이터 모델(레이블이 있는 메트릭)이 사실상 표준이 되었고, PromQL이 모두가 아는 쿼리 언어다. 활성 시계열이 1억 개 미만이면 Prometheus를 사용하라. 그 이상이면 VictoriaMetrics(Prometheus 호환, 더 잘 확장, 메모리 덜 사용)를 살펴보라. InfluxDB도 괜찮지만 라이선스가 계속 바뀐다. 이미 그들의 생태계에 종속된 게 아니라면 벤더 특정 솔루션은 피하라.
컬럼형 데이터베이스(Columnar databases): ClickHouse가 여기서 왕이다. 로그 집계와 플로우 분석에 터무니없이 빠르다. 보고나 역사적 분석을 위해 수십억 개의 행을 쿼리해야 한다면 이것이 도구다. InfluxDB v3가 경쟁을 시도하지만 ClickHouse는 수년간의 강화가 이루어졌다. Parquet 파일은 실시간 쓰기가 필요 없는 분석 워크로드에 효과적이다(Suzieq가 하는 것처럼).
텍스트 검색 데이터베이스(Text-search databases): 꼭 필요하다면 Elasticsearch지만, 솔직히 Loki(Grafana에서)처럼 현대적인 대안이 더 단순하고 운영 비용이 적다. Splunk는 다른 누군가가 비용을 내준다면 훌륭하다. 불편한 진실은 대부분의 팀이 로그 검색에 과도하게 투자하고, 검색 자체를 불필요하게 만들 수 있는 구조화된 로깅에는 과소 투자한다는 것이다.

추천: 메트릭에는 Prometheus(또는 유사 솔루션), 로그에는 Loki(또는 유사 솔루션)로 시작하라. 심각한 역사적 분석이 필요할 때 ClickHouse(또는 유사 솔루션)를 추가하라. 그 스택이면 더 복잡한 것이 필요하기 전까지 대규모까지 처리할 수 있다.

이 분류가 절대적인 것은 아니다. 대부분의 도구는 주요 분류가 있지만 다른 특성도 구현한다(특히 시계열).

저장소 설계 시 두 가지 중요한 개념이 있다. 카디널리티(cardinality)(레이블이 취할 수 있는 고유 값의 수)와 차원성(dimensionality)(하나의 메트릭이 가진 레이블 수). 고카디널리티 레이블에 많은 차원을 곱하면 저장 데이터가 폭발적으로 증가하고 쿼리가 느려진다. 이것이 가시성에서 가장 큰 도전 중 하나다. 심화 확장 고려사항은 챕터 11을 참조하라.

각 데이터베이스는 해결해야 하는 사용 사례에 매핑되어야 하는 고유한 특성을 가지고 있다. 예를 들어, Suzieq는 컬럼형 솔루션(Apache Parquet 파일)을 사용한다. 답하려는 질문들이 시계열 기반이 아니라 관계형이기 때문이다. 예를 들어: “스파인에는 존재하지만 모든 리프에는 없는 라우트는?”

요구사항:
- 여러 속성에 걸쳐 필터링
- 장치 간 행 비교
- 테이블 조인 (인터페이스, 이웃, 라우트)
- 특정 시점의 상태 확인 (역사적 변화가 아닌)
해결책: 이것이 컬럼형 분석 솔루션이 설계된 목적이다. Time Series Database (TSDB)는 라우트 수 확인에는 도움이 될 수 있지만, 누락된 라우트를 식별하려면 많은 레이블이 필요하며 이는 주요 강점이 아니다.

모든 데이터 관리 후 두 가지 최종 단계가 있다.

다른 자동화가 사용하거나 사람이 개입할 수 있는 이벤트 생성: 알림
의사결정을 위한 정보를 제공하기 위해 데이터 시각화: 시각화

6.2.6. 알림(Alerting)#

알림은 데이터를 행동으로 전환한다. 목표는 자동화에 데이터를 공급하는 것이다. 자동화가 해결할 수 없을 때만 사람에게 알린다.

알림은 다음 단계를 거친다.

감지(Detection): 데이터에서 문제를 찾는다.
처리(Processing): 맥락으로 풍부하게 만든다. 심각한가? 경미한가? 오탐인가? 관련 알림을 상관 분석하여 노이즈를 줄인다.
라우팅(Routing): 오케스트레이션(워크플로 실행), 팀(Slack), 또는 인시던트 관리(PagerDuty)로 보낸다.
에스컬레이션(Escalation): 자동화가 실패하면 사람이 인계받는다.

flowchart LR
    A[감지] --> B[처리기] --> C[라우팅] --> D[에스컬레이션]

그림 5: 알림 단계.

어려운 부분은 알림 설정이 아니다. 알림 피로(alert fatigue)를 방지하는 것이다. 아무도 더 이상 확인하지 않는 1만 개의 활성 알림이 있는 NOC를 본 적이 있다. 그 시점에서는 모니터링이 아니라 비싼 노이즈가 된다.

실제로 해결하는 방법은 다음과 같다.

알림의 95%를 사람이 아닌 자동화로 라우팅하라. 사람이 알림을 보는 것은 자동화가 시도하고 실패했기 때문이어야 한다. 인터페이스가 플래핑되는가? 자동화가 유지보수 여부를 확인하고, 광학 장치를 재시작하고, 벤더에 티켓을 열어야 한다. 자동화가 해결할 수 없을 때만 사람을 호출한다.
정적 임계값을 없애라. “CPU > 80%” 알림은 쓸모없다. 해당 장치에서 80%가 정상일 수 있다. 동적 기준선을 사용하라. 임의의 숫자가 아닌 역사적 패턴에서 벗어날 때 알림을 보내라.
관련 알림을 그룹화하라. 핵심 스위치가 다운되면 하위 장치에서 500개의 알림이 온다. 하나만 보여줘라. “핵심 스위치 다운, 500개 장치 영향.” 500개의 개별 알림이 아니라.
모든 알림에 대응 절차서를 요구하라. 알림을 받았을 때 누군가가 해야 할 일을 적을 수 없다면, 그 알림을 삭제하라. 진지하게. “조사하라"가 행동이라면 그것은 행동이 아니라 시간 낭비다.
알림 품질을 측정하라. 오탐률을 추적하라. 오탐률이 10%를 넘는 알림은 수정하거나 삭제한다. 확인 소요 시간을 추적하라. 알림이 몇 시간 동안 확인되지 않은 채로 있다면 존재할 만큼 중요하지 않은 것이다.

목표는 “포괄적인 모니터링"이 아니다. 목표는 “사람이 수정해야 하는 것만 사람에게 알림"이다.

6.2.6.1. 가시성에서 AI와 AIOps의 역할#

과대 광고를 걷어내자. 대부분의 “AI 기반 가시성"은 마케팅 예산이 있는 이상 감지일 뿐이다. 그렇긴 해도 올바르게 배포한다면 실제 가치가 있다.

실제로 효과적인 것들:

이상 감지(Anomaly detection): ML이 각 장치의 “정상"을 학습하는 데 정적 임계값보다 진정으로 뛰어나다. CPU 85%가 장치 A에는 괜찮지만 장치 B에는 재앙일 수 있다. ML이 이를 자동으로 파악한다. 이제 기본 기능이지, 마법이 아니다.
알림 상관 분석(Alert correlation): 50가지가 동시에 고장 날 때 ML이 이를 그룹화하고 “핵심 스위치가 아마 근본 원인일 것"을 제안할 수 있다. 몇 시간의 문제 해결을 절약한다. 하지만 ML이 20%는 틀리기 때문에 여전히 사람의 검증이 필요하다.
용량 예측(Capacity forecasting): ML이 “추세를 기반으로 이 링크는 6주 후에 포화될 것"을 예측하는 데 괜찮다. 사람이 그래프를 눈으로 보는 것보다 낫다. 여전히 신경 써야 할지에 대한 사람의 판단이 필요하다.

과대 광고된 것들:

자동 근본 원인 분석(Automatic root cause analysis): 모든 벤더가 이것을 약속한다. 아무도 안정적으로 제공하지 못한다. 제안은 받을 것이며, 때로는 좋은 것도 있지만, “AI가 문제를 진단하고 수정했다"는 95%는 마케팅이고 5%는 엄선된 예시다.
자가 치유 네트워크(Self-healing networks): 자동화는 알려진 솔루션으로 알려진 문제를 수정할 수 있다. 그것은 AI가 아니라 좋은 엔지니어링이다. 새로운 문제에 대한 진정한 “자가 치유"는 아직 존재하지 않는다. 벤더가 시연할 때 실패 사례를 보여달라고 요청하라.
“AIOps가 NOC를 대체한다”: 아니다. AIOps는 NOC가 더 효과적으로 일하도록 돕는다. 사람의 판단, 비즈니스 맥락, 예외적인 상황을 처리하는 능력? 그것은 여전히 사람이다.

결론: ML을 이상 감지와 알림 순위 매기기에 사용하라. 벤더 데모가 아닌 실제 네트워크에서 테스트해보기 전까지 다른 모든 것에는 회의적이어야 한다.

6.2.6.2. 알림-행동 인터페이스(The alert-to-action interface)#

사람이 읽는 알림은 알림(notification)이다. 자동화가 소비하는 알림은 계약(contract)이다. 두 소비자는 서로 다른 요구사항을 가지고 있으며, 이를 혼동하는 것이 오케스트레이터 경계에서 알림 파이프라인이 실패하는 가장 일반적인 이유 중 하나다.

알림이 자동화를 목적지로 할 때, 페이로드는 파싱 없이 기계가 소비할 수 있어야 한다. 즉, 사람이 읽기 좋은 제목 줄이 아닌 구조화된 데이터여야 한다. 최소한 자동화 목적지 알림 페이로드는 다음을 포함해야 한다.

장치 식별자(Device identity): DNS와 CMDB 간에 다를 수 있는 호스트명이 아닌 SoT 레코드와 정확히 일치하는 표준 식별자
알림 클래스(Alert class): 오케스트레이터가 라우팅할 수 있는 안정적이고 열거된 유형 (알림 규칙을 편집할 때 변경될 수 있는 자유 텍스트 설명이 아닌)
심각도(Severity): 정의된 열거형, 숫자 임계값이 아닌
타임스탬프(Timestamp): 알림 전달 시간이 아닌 UTC ISO 8601 이벤트 시간
관련 맥락(Relevant context): 알림을 트리거한 특정 메트릭이나 상태, 오케스트레이터가 직접 읽을 수 있는 필드로 (예: "interface": "Ethernet0/1", 메시지 문자열에 포함된 것이 아닌)
소스 추적(Source trace): 오케스트레이터가 추가 맥락을 위해 재쿼리할 수 있도록 가시성 시스템의 원시 이벤트로 연결되는 링크 또는 참조

이 계약을 충족하는 페이로드는 오케스트레이터가 알림을 올바른 워크플로로 라우팅하고, 장치 식별자를 SoT 조회에 전달하고, 구조화된 파라미터로 실행기(Executor)를 호출하는 것을 가능하게 한다. 문자열 파싱 없이. 이 계약을 충족하지 못하는 페이로드는 오케스트레이터가 사람이 읽을 수 있는 텍스트를 파싱하도록 강요하며, 이는 알림 설명이 변경될 때마다 깨진다.

알림 규칙을 구축하기 전에 이 계약을 정의하라. 사람이 읽기 좋게 작성하는 알림 규칙 작성자는 자동화하기 어려운 메시지를 만든다. 두 대상 모두를 위해 작성하는 알림 규칙 작성자는 어느 쪽도 잘 처리하지 못하는 메시지를 만든다. 가장 깔끔한 해결책은 두 개의 병렬 라우팅 경로다. 사람을 위한 알림 형식(Slack, PagerDuty)과 자동화를 위한 알림 형식(메시지 큐, 웹훅 엔드포인트). 동일한 감지 규칙으로 트리거되지만 서로 다른 소비자를 위한 다른 페이로드 템플릿.

6.2.7. 시각화(Visualization)#

목표: 관찰된 모든 데이터가 의사결정자에게 가치를 제공해야 하므로 사용자 지향적 시각화를 만드는 것이 사용자 필요에 답해야 한다.

마지막 블록은 대시보드/보고서 계층이다. 솔직하게 말하자면, 대부분의 대시보드는 형편없다. 경영진을 기분 좋게 만드는 허영 메트릭이거나(“99.99% 가동 시간!”), 데이터 폭탄(화면당 50개의 그래프, 아무도 그 의미를 모름)이다.

실제로 도움이 되는 대시보드를 만드는 방법은 다음과 같다.

장식이 아닌 결정을 위해 만들어라. 모든 위젯은 특정 질문에 답하거나 특정 행동을 트리거해야 한다. 누군가 그래프를 보고 어떻게 해야 할지 모른다면, 그 그래프를 삭제하라.
단순한 데이터가 아닌 문제를 보여줘라. 녹색/노란색/빨간색 신호가 원시 숫자보다 낫다. “인터페이스 사용률: 45%“는 쓸모없다. “인터페이스 사용률: 정상” 또는 “인터페이스 사용률: 경고, 포화 추세"는 실행 가능하다.
계층적 드릴다운이 하나의 큰 대시보드보다 낫다. 전체 상태 요약으로 시작하라(“3개 사이트에 문제 있음”). 사이트를 클릭하면 장치 상태를 볼 수 있다. 장치를 클릭하면 인터페이스를 볼 수 있다. 집중된 5개의 대시보드가 하나의 복잡한 재앙보다 낫다.
대상에 맞춰라. NOC 직원은 실시간 운영 상태와 드릴다운이 필요하다. 관리자는 추세 요약과 비즈니스 영향이 필요하다. 엔지니어는 원시 데이터 접근과 쿼리 인터페이스가 필요하다. 모든 사람을 위한 하나의 대시보드는 아무도 위한 것이 아니다.
인터랙티브하게 만들지 않으면 만들지 마라. 정적 대시보드는 빨리 낡는다. 사람들이 필터링하고, 확대하고, 시간 범위를 조정할 수 있게 하라. 조사를 지원하고, 단순히 예쁜 그림만 보여주지 마라.

그리고 논쟁의 여지가 있는 관점이 있다. 대부분의 팀에는 대시보드가 너무 많다. 각 사람이 그 중 2개만 보는 200개 이상의 대시보드가 있는 조직을 본 적이 있다. 아무도 보지 않는 대시보드는 삭제하라. 3개월 동안 아무도 보지 않는다면 중요하지 않은 것이다.

시각화와 프레젠테이션의 경계

시각화는 직접 다루는 것이 좋은 아키텍처 경계에 위치한다. 프레젠테이션 계층(챕터 8)은 사용자 대면 인터페이스, 즉 접근 제어, 셀프서비스 포털, ITSM 통합, 사람들이 정보를 요청하고 소비하는 방식의 사용자 경험 설계를 담당한다. 가시성 데이터의 시각화가 여기 챕터 6에 속하는 이유는 설계 결정이 완전히 데이터에 의해 이루어지기 때문이다. 어떤 메트릭이 사용 가능한지, 알림이 어떻게 구조화되어 있는지, 영속성 계층이 지원하는 드릴다운 경로가 무엇인지. 데이터 모델을 이해하지 않고는 효과적인 가시성 대시보드를 설계할 수 없다.

실제로 중요한 구분은 이것이다. 운영 결정을 위해 가시성 데이터 위에 직접 구축된 대시보드(지금 무슨 일이 일어나고 있는가, 이 서비스가 정상인가)는 가시성의 관심사다. 동일한 대시보드가 비기술 사용자에게 노출되거나, 셀프서비스 포털에 내장되거나, 변경 관리 워크플로와 통합되는 방식은 프레젠테이션의 관심사다. 챕터 8은 그 접근 및 워크플로 관점에서 이 도구들을 다시 살펴본다. 대부분의 시각화 도구(Grafana가 가장 일반적)는 둘 다 수행하여 이 경계를 흐리게 만든다. 이는 인위적으로 느껴지지만 그렇지 않다. 같은 도구가 둘 다 수행하더라도 관심사는 진정으로 다르다.

기본 규칙:

명확성: 이해하기 쉽다. 모든 요소에 목적이 있다.
관련성: 결정을 지원하는 데이터만 보여준다. 노이즈는 인사이트를 죽인다.
사용자 중심: 대상을 위해 만들어라. NOC 직원과 관리자는 다른 뷰가 필요하다.
인터랙티브: 사람들이 드릴다운하고, 확대하고, 시간을 조정할 수 있게 하라. 조사를 지원하라.
계층적: 먼저 전체 개요, 그 다음 드릴다운. 집중된 많은 대시보드가 하나의 복잡한 대시보드보다 낫다.

flowchart TD
    A[전체 개요] --> B[사이트 요약] --> C[장치 요약] --> D[장치 상세] --> E[인터페이스 상세]

그림 6: 계층적 드릴다운.

Modern Network Observability 책의 11장(“Application of Your Observability Data”)에서 대시보드 아키텍처에 대한 훨씬 더 많은 세부 사항을 찾을 수 있다.

이 블록은 사용자 인식과 매우 관련이 있으므로 인터뷰하고 프로세스에 참여시키는 것을 잊지 마라.

6.2.8. 자동화 시스템의 가시성#

대부분의 팀이 네트워크를 위한 가시성을 구축한다. 자동화 시스템 자체를 위한 가시성을 구축하는 팀은 거의 없다. 이것은 중요한 사각지대다. 자동화 파이프라인이 고장 나면 그 실패가 종종 침묵 속에 일어난다. 경보가 발생하지 않는 이유는 경보를 생성하는 역할을 하는 시스템이 바로 방금 작동을 멈춘 것일 수 있기 때문이다.

상태 0으로 종료되지만 0개의 장치에 배포된 플레이북은 오류를 생성하지 않는다. 벤더 특정 프로토콜 폴링을 조용히 멈춘 Telegraf 인스턴스는 누락 데이터 알림을 생성하지 않는다. 오전 2시에 실패하여 인벤토리를 12시간 오래된 상태로 남겨놓는 SoT 동기화 작업은 이후 모든 실행이 오래된 장치 목록으로 실행되도록 만들지만 아무것도 이를 알리지 않는다.

자동화 플랫폼에서 모니터링해야 할 것

실행 계층 (AWX, Ansible):
- 시간에 따른 작업 성공률: 천천히 상승하는 실패율은 무언가가 저하되고 있다는 초기 경고
- 실행 시간: 보통 4분 걸리는 작업이 40분 걸린다면 플랫폼, 네트워크 또는 둘 다에 문제가 있다는 신호
- 예상 시간을 초과하여 대기 중이거나 실행 중인 작업
- 롤백 빈도: 상승하는 롤백률은 보통 인텐트 데이터나 템플릿에 결함이 있음을 의미
- 작업당 도달 장치 수 대 예상 장치 수: 800개 대신 10개 장치에 배포하는 경우 인벤토리 동기화가 오류 없이 조용히 실패했을 수 있음
소스 오브 트루스 계층:
- API 응답 시간과 오류율: 느린 SoT API는 이를 쿼리하는 모든 실행 작업을 정체시킴
- 소스별 동기화 작업 상태: 마지막 성공적인 동기화 시간, 연속 실패 횟수
- 데이터 완전성: 실행이 의존하는 필수 필드가 누락된 장치 레코드 수
수집 계층:
- 장치별 마지막 성공적인 수집 타임스탬프: 세 번의 연속 간격 동안 폴링되지 않은 장치는 사실상 모니터링 사각지대
- 플릿 전체의 수집 지연: 평균 데이터 나이가 증가하고 있다면 수집기가 뒤처지는 것
- 프로토콜별 폴링 미스: SNMP 실패와 gNMI 구독 드롭은 별도로 카운트하고 알림을 설정해야 함

침묵의 실패 문제

감지하기 가장 어려운 자동화 실패는 성공적으로 완료되지만 의미 있는 변경을 만들지 않는 작업이다. 인벤토리 필터가 깨진 탓에 0개의 장치에 배포하는 플레이북은 상태 0으로 종료된다. 이 유형의 실패를 잡는 유일한 방법은 결과 수준에서 계측하는 것이다. “작업 프로세스가 정상적으로 종료되었는가?“가 아니라 “예상 수의 장치가 상태를 변경했는가?”

이는 실행 작업에 결과 메트릭을 추가하는 것을 의미한다. 성공적으로 구성된 장치를 위한 카운터, 롤백이 필요한 장치를 위한 게이지, 그리고 작업이 성공으로 표시되기 전에 최소 N개의 장치에 적용되었는지 확인.

아키텍처 권고사항

자동화 플랫폼을 지원하는 주요 가시성 시스템에 의존하지 않는 별도의 최소한의 가시성 스택에서 자동화 플랫폼을 모니터링하라. 메인 Prometheus 인스턴스가 다운되면, 자동화 파이프라인에 대한 알림도 함께 다운되어서는 안 된다. 핵심 자동화 구성 요소(AWX, Telegraf, SoT API, 동기화 작업)의 상태만 커버하는 가벼운 보조 스택(또는 SaaS 알림 서비스)이 주요 가시성 시스템이 자체적으로 제공할 수 없는 안전망을 제공한다.

이것은 챕터 7(오케스트레이션)과 직접 연결된다. 건강한 오케스트레이터는 일급 관심사로서 자신의 운영 상태를 보고해야 한다. 오케스트레이터를 관찰할 수 없다면, 그것이 조율하는 자동화도 관찰할 수 없다.

6.3. 구현 예시#

이 섹션은 Telegraf, Prometheus, Grafana 스택과 기타 도구를 사용하여 실용적인 사용 사례를 통해 가시성 기능들이 어떻게 통합되는지 보여준다.

이것은 도구 추천이 전혀 아니지만, 완전히 오픈소스 구성 요소로 구축되어 있기 때문에 직접 시도해볼 수 있다.

6.3.1. 사용 사례: 캠퍼스 서비스의 배포 후 검증 및 지속적인 모니터링#

챕터 5의 캠퍼스 네트워크를 이어서 사용한다. 새로운 VLAN 서비스가 실행 블록에 의해 building-b의 대상 스위치 전반에 배포되었다. 이제 가시성이 인계받는다. 먼저 배포가 네트워크 상태 관점에서 실제로 성공했는지 검증하고, 이후 전체 캠퍼스에 걸쳐 서비스 상태를 지속적으로 모니터링한다.

시나리오: Cisco, Arista, HPE의 ~800개 캠퍼스 스위치에 새로운 VLAN 서비스 세그먼트를 배포한 후, 운영 팀은 서비스가 모든 대상 장치에서 활성화되어 있고 일관성이 있는지 확인하고, 스위치가 VLAN을 잃으면 구성 드리프트를 감지하고, 시간에 따라 트래픽 상태를 모니터링해야 한다. 장치별 수동 확인 없이.

요구사항:

배포 후 모든 대상 스위치에서 VLAN 멤버십이 활성화되고 일관성이 있는지 검증
구성 드리프트 알림: 스위치에서 VLAN이 누락되거나 예상치 못한 트렁크 멤버십 변경
서비스 트래픽 상태 모니터링: 액세스 포트별 사용률 수준과 오류율
잘못 라우팅된 플로우를 나타낼 수 있는 급격한 트래픽 급증(>50% 변화) 감지
컴플라이언스 및 용량 계획을 위해 30초 해상도로 30일 데이터 유지
장치 인벤토리 및 VLAN 인텐트 데이터를 위해 Nautobot과 통합
드리프트 감지 시 자동화된 수정을 위한 오케스트레이션 워크플로 트리거

6.3.2. 솔루션 아키텍처#

솔루션 분석을 시작하기 전에 시나리오 규모를 추정하는 것이 중요하다. ~800개 캠퍼스 스위치 × 48포트 × 8메트릭 = 약 307K 활성 시계열. 이는 단일 Prometheus 노드가 처리할 수 있는 범위 내에 있지만(최대 ~1M 시계열까지 편안하게 처리), 수집기 계층은 30초 간격으로 800개 장치에 폴링 부하를 분산하기 위해 여러 Telegraf 인스턴스가 필요하다.

구성 요소 선택 이유:

Telegraf는 다중 프로토콜 지원(레거시 HPE와 구형 Cisco 장치를 위한 SNMP, Arista와 신형 Cisco 플랫폼을 위한 gNMI), 광범위한 플러그인 생태계, 데이터 정규화를 위한 내장 처리기 때문에 수집기로 선택되었다. 800개 장치 규모에서 단일 Telegraf 인스턴스는 30초 폴링 간격에서 과부하가 걸리므로, Consul이 각 인스턴스가 소유하는 대상을 조율하며 두세 개의 인스턴스가 배포된다.
Prometheus는 영속성 계층으로, 복잡한 알림 조건을 위한 강력한 PromQL 쿼리 언어와 함께 시계열 데이터에 최적화되어 있다. 32K 시계열에서 충분한 여유를 가지고 작동하며, Alertmanager와 기본 통합을 제공한다.
Grafana는 다중 데이터소스 지원으로 시각화를 제공하며, Prometheus 메트릭과 Nautobot 메타데이터를 동시에 쿼리하여 서로 다른 대상(NOC, 용량 계획, 경영진)을 위한 맥락이 풍부한 대시보드를 만든다.

아키텍처

높은 수준에서 다음 그림은 주요 구성 요소와 역할을 보여준다.

flowchart TB
    subgraph Sources["데이터 소스"]
        NB[Nautobot<br/>소스 오브 트루스]
        SW[네트워크 장치<br/>SNMP/gNMI]
    end

    subgraph Collection["수집 계층"]
        T[Telegraf<br/>수집기]
        SD[Consul<br/>서비스 디스커버리]
    end

    subgraph Storage["저장소"]
        P[Prometheus<br/>TSDB]
    end

    subgraph Alerting["알림"]
        AM[Alertmanager<br/>라우팅]
    end

    subgraph Presentation["시각화"]
        G[Grafana<br/>대시보드]
    end

    subgraph Integration["외부 시스템"]
        ORCH[오케스트레이터<br/>자동화]
        SLACK[Slack<br/>알림]
    end

    NB -->|장치 인벤토리| SD
    SD -->|동적 대상| T
    SW -->|메트릭| T
    T -->|HTTP 노출| P
    P -->|알림 규칙| AM
    P <-->|쿼리| G
    NB -->|메타데이터| G
    AM -->|웹훅| ORCH
    AM -->|알림| SLACK

그림 7: 가시성 솔루션 예시.

이 단순화된 솔루션 아키텍처는 Modern Network Observability 책에서 광범위하게 다루고 있다. 랩 시나리오를 통한 실습 접근을 원한다면 시도해 보라.

6.3.3. 구현 흐름#

인벤토리 통합: Nautobot은 단일 소스 오브 트루스 역할을 하며, 모니터링 프로필과 SNMP 자격 증명으로 어떤 장치를 모니터링할지 정의한다. 경량 동기화 서비스(예: 웹훅을 사용하는 Python 스크립트)가 장치 정보로 Consul의 서비스 레지스트리를 지속적으로 업데이트하여 수집기에서 동적 디스커버리를 가능하게 한다.

데이터 수집: Telegraf는 서비스 디스커버리를 위해 Consul을 사용하여, Nautobot에 나타나는 장치를 자동으로 SNMP 폴링한다. Telegraf 처리기는 데이터를 정규화하고 풍부하게 만들며(상태 코드를 레이블로 변환, 필드를 표준 이름으로 변경, Nautobot의 맥락 정보 추가), HTTP 엔드포인트에서 Prometheus 형식으로 메트릭을 노출한다.

영속성과 분석: Prometheus는 Consul 서비스 디스커버리를 사용하여 Telegraf 엔드포인트를 스크래핑하고, 메트릭을 시계열 데이터베이스에 저장한다. Recording rules는 쿼리 성능을 최적화하기 위해 인터페이스 사용률 백분율과 대역폭 속도를 미리 계산한다.

알림 로직: Prometheus의 알림 규칙이 조건을 정의한다(예: 5분 동안 인터페이스 사용률 >80%, 트래픽 급증 >50% 증가). 조건이 일치하면 Alertmanager가 라우팅을 처리한다. automation: enabled 레이블이 있는 심각한 알림은 오케스트레이터 웹훅으로 가고, 다른 것들은 심각도에 따라 Slack이나 PagerDuty로 라우팅된다.

시각화: Grafana 대시보드는 여러 뷰를 제공한다. 패브릭 전체 대역폭 추세, 상위 포화 인터페이스, 인터페이스 히트맵이 있는 장치별 드릴다운. 템플릿 변수로 사이트, 역할, 또는 장치별 필터링이 가능하다. 대시보드는 Prometheus(메트릭)와 Nautobot(장치 메타데이터) 모두에 쿼리하여 맥락 풍부화를 한다.

폐루프 자동화: 심각한 포화 알림이 발생하면 Alertmanager가 오케스트레이션 플랫폼에 웹훅을 보내고, 이는 가용한 경로에 걸쳐 부하를 재분배하는 자동화된 트래픽 엔지니어링 워크플로를 트리거한다. 이 구성 요소는 챕터 7에서 다룬다.

6.3.4. 솔루션 요약#

운영상의 이점:

SoT 통합을 통한 수동 모니터링 노력 감소
1분 미만의 지연 시간으로 선제적 문제 감지
폐루프 수정으로 MTTR을 몇 시간에서 몇 분으로 단축
메트릭과 인벤토리 데이터를 결합한 풍부한 맥락

확장성 고려사항:

현재 아키텍처는 Consul 뒤에 배치된 2-3개의 분산 Telegraf 인스턴스를 사용하여 ~800개 캠퍼스 스위치를 처리한다. 건물이나 장치를 추가하면 재아키텍처 없이 수집기 인스턴스를 더 추가하면 된다.
Prometheus 용량은 ~307K 시계열에서 충분하며 성장 여유가 있다. 단일 노드는 페더레이션이나 분산 백엔드가 필요하기 전에 최대 ~1M 시계열을 처리한다.

이 간략한 솔루션 연습이 네트워크 자동화 아키텍처 내에서 가시성의 기본 목표와 기능을 정의하는 이 챕터를 마무리한다.

6.4. 요약#

네트워크 자동화에서의 가시성은 전통적인 모니터링을 훨씬 넘어선다. 네트워크 동작을 이해하고, 문제를 선제적으로 감지하고, 규모에서 자동화된 수정을 가능하게 하는 아키텍처 기반을 제공한다. 최소한의 인력으로 자동 디스커버리부터 정교한 실시간 분석과 사용자 중심 시각화까지 일곱 가지 핵심 목표를 기반으로, 가시성은 네트워크 이벤트에 대한 조직의 대응 방식을 변화시킨다. 반응적인 문제 해결에서 선제적이고 데이터 기반의 운영으로.

이 목표들의 실현은 일곱 가지 상호 연결된 아키텍처 기둥과 기능을 필요로 한다. 자동 인벤토리 디스커버리를 위한 SoT 통합, 스트리밍 텔레메트리와 현대적 프로토콜을 통한 거의 실시간 데이터 수집을 지원하는 다중 프로토콜 수집기, 맥락 메타데이터로 이기종 데이터를 정규화하고 풍부하게 만드는 처리기, 대용량에서 확장 가능한 데이터 이동을 위한 분산 시스템, 서로 다른 가시성 워크로드에 최적화된 목적 특화 데이터베이스(시계열, 컬럼형, 텍스트 검색), AI/ML 강화 감지와 오케스트레이션 또는 사람 대응자로의 라우팅이 포함된 지능적인 알림, 그리고 서로 다른 대상에게 적절한 추상화 수준으로 정보를 제공하는 맞춤형 시각화.

가시성 구현은 설계 과정 초기에 아키텍처 결정을 필요로 한다. 조직은 전통적인 온프레미스 플랫폼, 빠른 배포와 AI 기반 분석을 제공하는 클라우드 네이티브 SaaS 솔루션, 또는 최대 유연성을 제공하는 구성 가능한 오픈소스 스택 중에서 선택해야 한다. 각 접근 방식은 비용, 제어, 운영 오버헤드, 기능 면에서 절충점이 있다. 성공은 또한 정규화와 풍부화부터 필터링과 집계까지 데이터 처리 요구사항을 이해하고, 새로운 AIOps 기능이 알림 피로를 줄이고 예측 운영을 가능하게 하는 방법을 이해하는 것에 달려 있다.

가시성은 단일 도구가 아니라 일관된 아키텍처 패턴이다. 성공은 인벤토리가 수집을 이끌고, 수집이 처리를 가능하게 하며, 처리가 분산을 공급하고, 분산이 영속성과 연결되며, 영속성이 알림을 알려주고, 알림이 궁극적으로 시각화와 자동화된 대응을 이끄는 시스템으로 취급하는 것에 달려 있다. 각 구성 요소와 상호 작용 방식을 신중하게 설계함으로써, 조직은 네트워크와 함께 확장되고, OpenTelemetry와 gNMI 같은 현대적 프로토콜과 통합되며, 운영 가시성을 폐루프 자동화를 이끄는 실행 가능한 인텔리전스로 변환하는 가시성 시스템을 구축할 수 있다.

참고 문헌 및 추가 자료#

Modern Network Observability (David Flores, Christian Adell, Josh Vanderaa): Telegraf, Prometheus, Grafana 같은 오픈소스 도구를 사용한 실습 접근법

💬 Found something to improve? Send feedback for this chapter