측정할 수 없는 것을 추정하기

링크 카운터에서 추론한 트래픽 매트릭스, 만들지 않기로 한 플로우 수집기, 그리고 제 랩의 정직한 한계

2026년 8월 22일 Michel Wijnberg

이전 글은 일부러 질문 하나를 남겨 두고 멈췄습니다. Osprey는 nrt1-cr1 ↔ sea1-cr1을 끊으면 경로 56개가 바뀌고 아무것도 고립되지 않는다고 말해 줄 수 있습니다. 운영자가 그다음에 던지는 질문이야말로 그 변경이 안전한지를 결정합니다.

트래픽은 어디로 가고, 어딘가가 넘치지는 않는가?

경로 개수만으로 변경을 승인하는 사람은 없습니다. 결정을 내리는 숫자는 용량입니다. 트래픽을 물려받는 링크에 그것을 담을 자리가 있는가. 이 글은 네트워크 안에서 그 숫자를 직접 재는 것이 아무것도 없을 때 그 숫자에 정직하게 어디까지 다가갈 수 있는지, 그리고 그 답이 어디서부터는 기대면 안 되는 것이 되는지에 대한 이야기입니다.

여기에 답하려면 어느 출발지에서 어느 목적지로 얼마만큼의 트래픽이 흐르는지를 알아야 합니다. 곧 트래픽 매트릭스입니다. 그것을 가진 사람은 거의 없습니다.

만들지 않기로 한 것

트래픽 매트릭스를 얻는 교과서적인 방법은 플로우 익스포트입니다. NetFlow, sFlow, IPFIX. 라우터가 플로우를 샘플링해 레코드를 수집기로 보내고, 그것을 출발지-목적지 수요로 집계합니다.

저는 그것을 계획했었습니다. 이 저장소에는 LSDB를 인지하는 중복 제거를 갖춘 플로우 수집기 설계 문서가 1,139줄 들어 있습니다. 그 문서의 첫 줄에 이렇게 표시되어 있습니다.

Status: SHELVED (2026-03-12). Deferred indefinitely after cross-plan feasibility review.

이유는 다섯 가지가 적혀 있습니다. 실제로 결정을 지은 두 가지는 이렇습니다.

용량. 라우터 500대 기준 주당 70~220 GB로, 데이터베이스의 나머지 전부를 합친 것의 대략 백 배입니다. 이 제품의 데이터 저장소는 의도적으로 PostgreSQL 하나뿐이고, 플로우 파이프라인을 삼킨다는 것은 두 번째 저장소를 두거나 데이터베이스가 무너지거나 둘 중 하나를 뜻합니다.
한계 가치. 실무적인 트래픽 가시성의 약 80%는 이미 수집하고 있던 SNMP 인터페이스 카운터에서 이미 얻고 있었습니다.

이것은 기술적 불가능이 아닙니다. 마지막 20%를 위해 새 서브시스템, 새 운영 부담, 새로운 종류의 저장 리스크를 치러야 하는데 그럴 값어치는 없다는 판단입니다. 합리적으로 다르게 볼 수 있고, 어떤 네트워크는 정말로 플로우가 필요합니다. 여기서 중요한 것은 그 결정이 근거와 함께 적혀 있어서, Osprey를 평가하는 누구든 자기 상황이 제 상황과 맞는지 직접 확인할 수 있다는 점입니다.

그러니 플로우 레코드는 없습니다. 남는 것은 흥미로운 쪽 문제입니다.

링크가 인정하는 것으로부터 매트릭스를 추론하기

Osprey가 실제로 가진 것은 모든 링크의 부하이고, 제대로 측정된 값입니다. 64비트 ifHCInOctets / ifHCOutOctets 카운터를 주기적으로 폴링하고, 차분해서 초당 비트로 만들고, 랩어라운드를 보정하고, 인터페이스 속도로 나눠 사용률 백분율을 냅니다.

그것은 링크 단위 총합의 집합입니다. 우리가 원하는 것은 쌍 단위 수요의 집합입니다. 앞의 것에서 뒤의 것을 복원하는 일은 부족 결정 역문제입니다. 서로 다른 수많은 트래픽 매트릭스가 정확히 같은 링크 부하를 만들어 냅니다. 여기에는 잘 알려진 접근법이 있습니다. Tomogravity(Zhang, Roughan 외, 2003)입니다.

두 수로 진행되고, Osprey는 둘 다 구현합니다.

// computeTrafficEstimate estimates traffic redistribution after topology
// mutations using the gravity model (Zhang/Roughan et al., "Tomogravity" 2003).
//
// Without a full traffic demand matrix, per-pair demands are estimated using
// the gravity model: demand(i,j) ∝ V(i)·V(j)/V_total, where V(i) is the
// total traffic volume at device i (derived from SNMP interface utilization).
// These gravity demands are then calibrated against observed per-link loads
// so that the model's predictions match reality.

중력 단계는 두 라우터 사이의 트래픽이 각자가 전체적으로 나르는 양의 곱에 비례한다고 가정합니다. 뉴턴 중력과 같은 형태이고, 두 경제 사이의 교역 모형과도 같은 형태입니다. 이것은 측정이 아니라 사전 가정이며, 특정한 방식으로 틀립니다. 바쁜 이웃 쌍이나 한가한 이웃 쌍이라는 개념이 없습니다.

단층 촬영 단계가 그것을 쓸 만하게 만듭니다. 중력으로 짐작한 값은, 추정된 모든 수요를 IGP가 실제로 선택하는 경로 위로 흘렸을 때 나오는 링크별 부하가 측정된 부하와 맞아떨어지도록 스케일링됩니다. 사전 가정이 근거로 교정되고, 여기서 짐작이 아닌 유일한 것이 바로 그 근거입니다.

그러고 나서야 비로소, 보정된 수요가 장애 이후 경로 위로 다시 흘려집니다(ECMP 가중이므로 트래픽이 네 갈래로 나뉘는 쌍은 각 링크에 4분의 1씩 기여합니다). 그 차이가 예측되는 재분배입니다.

일부러 볼품없게 만든 세 가지 선택

추정기에서 흥미로운 엔지니어링은 전부, 그것이 자신만만해지지 못하게 막는 자리에 있습니다.

링크별이 아니라 전역으로 보정하기. 솔깃한 버전은 링크마다 독립적으로 스케일 인자를 계산합니다. 데이터에는 더 잘 맞고, 훨씬 나쁩니다.

// Compute a GLOBAL calibration factor: total observed bps / total gravity sum.
// Per-link calibration can amplify noise when gravitySumPerLink is small
// relative to observed traffic, producing extreme scaling factors that
// inflate per-pair demands unrealistically. Global calibration distributes
// the error uniformly, producing more stable and realistic results.

중력 합이 거의 0인데 측정된 트래픽이 조금 있는 한가한 링크는 어마어마한 스케일 인자를 만들어 내고, 그 인자는 그 링크를 지나는 모든 쌍을 부풀립니다. 더 촘촘한 적합이 사 주는 것은 이따금씩의 헛소리입니다. 전역 인자 하나는 오차를 고르게 펴고 결코 폭발하지 않습니다.

단일 쌍의 상한을 전체 볼륨의 5%로 두기. 추정된 수요 하나가 네트워크의 얼마만큼을 차지해도 되는지에 대한 단단한 천장입니다. 역문제의 실패 양상이 바로 한 쌍이 모든 것을 빨아들이는 것이기 때문입니다.

작은 변화는 보고하지 않기. 예측된 이동량이 링크 사용률의 0.5% 미만이면 버리고, 코스트 변경 경로에서는 0.1%입니다. 그 경로는 가상 링크와 가상 노드도 함께 다루기 때문에 새 중계 노드의 영향이 여러 링크에 얇게 퍼집니다. 그 아래에서는 그 숫자가 카운터 흔들림과 구분되지 않고, 그것을 찍어 내는 것은 누군가 잡음을 근거로 움직이라고 부추기는 일입니다.

이 셋은 하나같이 출력이 덜 정밀해 보이게 만듭니다. 정밀함은 목표가 아닙니다. 목표는 화면에 뜨는 숫자가 기대어도 되는 숫자라는 것입니다.

그리고 이제, 제 랩이 저를 도울 수 없는 대목

앞의 여덟 편에 나온 모든 것은 저를 반박할 수 있는 랩에 대해 검증되었습니다. 라우터 쌍 4,032개를 실제 라우팅 테이블과 대조했고, 허구의 통로 360개를 찾아냈으며, 세 프로토콜과 세 발견 경로가 같은 단일 장애점에 대해 일치했습니다.

트래픽에 관해서는 이 랩이 거의 쓸모가 없고, 그 이유를 정확히 말하고 싶습니다.

이 랩의 라우터들은 사실상 아무것도 포워딩하지 않습니다. 프로토콜을 돌리고, LSA와 BGP 업데이트를 주고받고, 본질적으로 그게 전부입니다. 측정값은 이렇습니다.

측정	값
사용률 데이터가 있는 인터페이스	1,279
…사용률 0.05% 미만	1,241
전체 최고 사용률	10 Mbps 포트에서 0.431%
전체 최고 인터페이스 속도	약 43 kbps
10 Gbps 정격 인터페이스 368개의 최고치	약 24 kbps, 즉 0.00024%

어디를 봐야 하는지 안다면, 이전 글의 시뮬레이션 스크린샷에서 그 결과를 볼 수 있습니다. 실패한 링크 헤더에는 “2 links, 6Kbps displaced”, 6킬로비트라고 적혀 있고, 패널에는 Traffic Redistribution 섹션도, 혼잡 위험 표시도 전혀 없습니다. 코드가 돌지 않아서가 아닙니다. 예측된 모든 이동이 그 0.5% 잡음 바닥 아래로 떨어져 올바르게 버려졌기 때문입니다.

배관은 검증 가능하게 옳습니다. 카운터를 읽고, 속도를 차분하고, 중력 수요를 만들고, 보정을 돌리고, 장애 이후 ECMP 경로 위에서 재분배를 계산하고, 잡음 바닥이 버려야 할 것을 버립니다. 랩이 저에게 알려 줄 수 없는 것은 그 추정이 좋은지입니다. 추정기를 검증하려면 비교할 기준 진실이 필요하고, 여기서 기준 진실은 출발지-목적지 매트릭스가 알려진 실제 트래픽을 뜻하기 때문입니다.

트래픽이 없는 랩은 그것을 만들어 낼 수 없습니다. 합성 부하를 넣어도 해결되지 않습니다. 제가 고른 매트릭스로 트래픽을 만들어 내고, 방금 먹인 그 매트릭스를 추정기가 복원했다고 스스로 축하하는 꼴이 됩니다. 그것은 검증이 아니라, 제 산수를 아주 느리게 확인하는 방법일 뿐입니다.

그래서 얼마나 믿어야 하는가

숫자가 덜 단단해지는 순서대로 나열한 정직한 사다리입니다.

링크 사용률, 실시간과 이력: 측정값. 64비트 카운터, 차분, 랩어라운드 보정, 인터페이스 속도에 대한 타당성 검사. 이것은 데이터입니다.
변형 이후 어느 경로가 바뀌는가: 토폴로지에서 계산된 값. 결정론적이며, 그 밑의 토폴로지는 라우터 쌍 4,032개로 검증된 바로 그것입니다.
각 링크로 트래픽이 얼마나 옮겨 가는가: 추정값. 측정된 링크 부하로 교정한 중력 사전 가정에서 나옵니다. 방향성으로는 쓸모 있고, 실제 근거로 보정되었으며, 측정은 아닙니다.

3단은 진짜로 값어치가 있습니다. “이 링크 열두 개가 장애를 흡수한다”와 “이 링크 하나가 대부분을 흡수하는데 이미 70%다”의 차이니까요. 동시에 이것은 이 시리즈 전체에서 옆에 검증 숫자를 적을 수 없는 유일한 단이고, 그것을 “4,032 중 4,032”와 같은 목소리로 내놓는다면 정직하지 않을 것입니다.

제품은 가능한 곳에서는 그 선을 긋습니다. BGP 피어의 트래픽이 매칭된 SNMP 인터페이스가 아니라 프리픽스 개수 비율로 유도되어야 할 때, 그 행에는 정확히 그 말을 하는 툴팁이 붙습니다. “Traffic estimated from prefix count ratios (no SNMP interface match)”. 그 옆에는 카운터에서 온 SNMP 배지가 달린 행들이 있습니다. 같은 표에 등급을 매기는 것, 이 시리즈가 계속 도달하는 그 패턴이고, 같은 모양이 나온 것은 이번이 세 번째입니다. 도메인 간 경로는 세그먼트를 resolved / inferred / opaque로 등급 매기고(네 번째 글), 포트 주석은 네 가지 판정을 진술된 사실에서 명시적 모호성까지 등급 매기며(여섯 번째 글), 위의 세 단은 트래픽 숫자에 등급을 매깁니다. 사다리 셋, 습관 하나. 답 아래의 근거가 고르지 않다면, 전체에 대해 하나의 확신도를 내놓는 대신 그 자리에서 등급을 매기라는 것입니다.

랩은 무엇을 위한 것인가, 다시 말하면

일곱 번째 글은 랩이 Osprey를 좋아 보이게 하려는 것이 아니라 Osprey가 틀렸음을 증명하려고 있다고 주장했습니다. 이번 글은 아무도 반기지 않는 그 따름정리입니다. 랩은 자기가 실제로 굴려 볼 수 있는 것만 반증할 수 있습니다.

제 랩은 토폴로지, 프로토콜 의미론, 포워딩에 대해 저를 반박하는 데 유난히 뛰어납니다. 제가 읽고 대조할 수 있는 실제 라우팅 테이블을 가진 진짜 라우터가 192대 있기 때문입니다. 트래픽에 대해서는 저를 반박할 능력이 없습니다. 트래픽을 나르지 않기 때문입니다.

제품이 찍어 내는 숫자 하나하나에 대해 자기가 이 두 상황 중 어디에 있는지를 아는 것, 그것이 믿을 만한 도구와 그저 자신만만한 도구를 가르는 것의 대부분입니다. 저는 Osprey의 어떤 주장이 측정에 기대고, 어떤 것이 검증된 모델 위의 계산에 기대며, 어떤 것이 제가 믿기는 하지만 여기서는 증명할 수 없는 추정기에 기대는지를 정확히 압니다.

이번 글이 세 번째 범주입니다. 그런 것은 정확히 하나뿐이고, 이제 당신은 그것이 어디 있는지 압니다.

다음은 이 시리즈의 마지막 글입니다. 모델은 정확하고, 동시에 지금의 모델이기도 합니다. 망가지기 한 시간 전, 그 네트워크는 어떤 모습이었을까요? 네트워크에는 기억이 있다.