[구축사례] IPFIX와 Goflow2로 구현한 kt cloud Network 미터링 내재화

KT Cloud가 OpenStack ML2/OVN 전환 이후 iptables 기반 미터링이 불가능해진 상황에서 IPFIX 프로토콜과 Goflow2를 활용해 클라우드 트래픽 과금 미터링 파이프라인을 재구축한 사례다. 단순 도입을 넘어 Goflow2 소스 코드를 직접 수정해 OVSDB 연동 인메모리 캐시를 구현하고, CPU 사용률을 115%에서 4% 미만으로 낮췄다. 오픈소스 네트워크 미터링 도구를 프로덕션 과금 시스템에 적용하는 전 과정을 상세히 다룬다.

핵심 포인트

ML2/OVN 전환 후 iptables 미터링 불가 → IPFIX 프로토콜로 전환
IPFIX vs sFlow 비교: 과금 정합성을 위해 stateful flow aggregation(IPFIX) 선택
Goflow2 소스 수정: OVSDB 3단계 인메모리 캐시로 VM 정보 enrichment 구현
CPU 사용률 115% → 4% 미만, 미터링 정확도 100.4% 달성
OVS IPFIX → Goflow2 → Kafka → 과금 시스템의 전체 파이프라인 설계

상세 정리

배경: OpenStack ML2/OVN 전환으로 기존 iptables 기반 트래픽 집계 불가
IPFIX 선택 이유: sFlow는 패킷 샘플링 기반이라 과금 오차 발생, IPFIX는 flow 완전 수집
IPFIX 동작: OVS가 flow를 캐시, 종료 시 collector로 전송(stateful aggregation)
Goflow2 선택: Go 기반 오픈소스 IPFIX/NetFlow collector, 확장성 우수
문제 1: Goflow2가 VM UUID를 모름 → OVSDB에서 VM 정보 조회 필요
문제 2: OVSDB 실시간 조회 시 CPU 폭증(115%), 과금 파이프라인 지연
캐시 설계 3단계: 1) 초기 전체 동기화(시작 시) → 2) OVSDB 변경 이벤트 실시간 수신 → 3) O(1) 인메모리 lookup으로 enrichment
캐시 키: 포트 UUID → (VM UUID, IP, 프로젝트 ID) 매핑 테이블
CPU 개선: OVSDB 실시간 조회 제거로 115% → 4% 미만
정확도: 샘플링 없는 완전 수집으로 100.4%(오차 0.4%는 flow 타임아웃 경계)
파이프라인: OVS(IPFIX 생성) → Goflow2(enrichment) → Kafka(버퍼) → 과금 시스템
운영 고려: flow 타임아웃 설정, OVSDB 이벤트 유실 시 재동기화 전략