[기술사례] OVN ACL Flow Sampling 기반 VPC Flow Log 서비스 개발

 

 

Tech-Frontier.md  kt cloud

$ whoami --team ❯ kt cloud Cloud플랫폼팀 서준호 님

📋 요약 TL;DR

이 글에서는 OVN ACL Flow Sampling을 기반으로 VPC Flow Log 서비스를 개발한 과정과 아키텍처를 다룹니다. 대용량 트래픽 환경에서 로깅 부하를 줄이고 네트워크 운영 가시성을 높이는 방향을 정리합니다. #OVN #ACLFlowSampling #VPCFlowLog #IPFIX #Goflow2

---

클라우드 환경이 고도화됨에 따라 네트워크 트래픽에 대한 투명성 확보와 보안 감사(CSAP 인증 등) 요건은 점점 더 까다로워지고 있습니다. 본 포스트에서는 클라우드 플랫폼팀, 데이터플랫폼팀, 보안플랫폼팀이 협업하여 7월 릴리즈를 목표로 개발한 VPC Flow Log 서비스의 아키텍처와, 기존 시스템의 한계를 극복하기 위해 적용한 기술적 내용을 공유합니다.

1. 배경: VPC Flow Log 서비스란?

VPC Flow Log는 테넌트(사용자)의 가상 네트워크(VPC) 내 가상 머신(VM) 및 리소스에서 발생하는 인/아웃바운드 IP 트래픽을 캡처하여 기록하는 서비스입니다.

• 비즈니스 요구사항: CSAP 인증 대응 및 보안팀의 감사 요건을 충족하기 위해, ACL(Access Control List)에 매칭된 flow의 통계 정보(flow duration, n_packets, n_bytes, direction, action 등)와 테넌트 식별을 위한 KCP 메타데이터(project_id, tenant_id 등)의 수집이 필수적이었습니다.

이러한 로그는 네트워크 연결 문제를 디버깅하거나, 보안 침해 사고를 분석하고, 대역폭 사용량을 모니터링하는 데 핵심적인 데이터로 활용됩니다.

---

2. OpenStack Packet Logging Framework의 진화와 기존 시스템의 한계

오픈스택 환경에서 트래픽을 로깅하기 위해 기본적으로 고려할 수 있는 두 가지 프레임워크가 있습니다.

① OpenStack Neutron Packet Logging Framework (기존 방식)

현 오픈스택은 Packet Logging Framework를 이용해 ACL audit 기능을 제공합니다. 이는 ACL에 매칭된 flow가 발생할 때마다 각 OVN Chassis(컴퓨트 노드)의 ovn-controller.log 파일에 텍스트 형태로 로그를 남기는 방식입니다.

 

Neutron Packet Logging 시스템의 한계점: I/O 및 가독성 한계: 텍스트 기반의 로그(Syslog 형태)가 로컬 파일에 직접 쌓이기 때문에, 대규모 트래픽 발생 시 컴퓨트 노드의 디스크 I/O에 심각한 부하를 줄 수 있습니다. 중앙 집중화의 어려움: 수많은 컴퓨트 노드에 파편화된 로그 파일들을 실시간으로 수집·가공하기 위한 별도의 무거운 에이전트 파이프라인이 필요합니다. 네트워크 메타데이터 부족: 단순 패킷 매칭 정보 위주로 기록되어, 네트워크 성능 분석에 필요한 고도화된 Flow 통계 데이터를 유연하게 담아내기 어렵습니다.

② OVN ACL Flow Sampling (보완 및 해결책)

이러한 한계를 극복하기 위해 OVN 24.09부터 도입된 ACL Flow Sampling 기능을 활용했습니다. 이 방식은 패킷을 로그 파일에 쓰는 대신, ACL에 매칭된 flow의 메타 정보를 표준화된 IPFIX(Internet Protocol Flow Information Export) 포맷으로 변환하여 네트워크를 통해 외부 Collector로 직접 전송(Sampling)합니다.

개선 효과: 컴퓨트 노드의 로컬 디스크 I/O 부하를 완전히 제거하고, 네트워크 레벨에서 비동기적으로 flow 데이터를 바이너리 형태로 전달하므로 고속/대용량 트래픽 처리에 압도적으로 유리합니다.

---

3. 고성능 구조를 위한 분산형 아키텍처 설계

Scalability(확장성)를 확보하기 위해 중앙 집중형이 아닌 컴퓨트 노드(cnode) 분산 방식의 아키텍처를 채택했습니다.

1. 각 컴퓨트 노드의 OVS(Open vSwitch)는 flow sample 데이터를 외부가 아닌 Local(127.0.0.1)의 IPFIX Collector로만 전송합니다.
2. 로컬 IPFIX Collector는 자기 자신 노드에서 발생한 IPFIX 메타데이터만 파싱하므로 중앙 병목이 발생하지 않습니다.
3. 파싱된 데이터는 데이터플랫폼팀과 협의한 유연한 Protobuf(Protocol Buffers) 포맷으로 가공되어 중앙의 Kafka(Topic: acl) 인프라로 고속 Ingestion됩니다.
4. 추후 특정 컴퓨트 노드의 자원 constraints(CPU/MEM)가 우려될 경우, 해당 에이전트만 독립적으로 격리 및 관리할 수 있도록 설계되었습니다.

---

4. OVSDB Client Cache 기반의 고속 메타데이터 질의

IPFIX Collector를 원활하게 구동하기 위해 오픈소스인 Goflow2를 기반으로 IPFIX collector 개발을 진행했습니다.

 

이 과정에서 가장 중요한 핵심 과제는 "IPFIX raw 데이터(바이너리)에 KCP(Cloud Platform)의 가상 네트워크 메타데이터(Tenant ID, VM 정보 등)를 어떻게 지연(Latency) 없이 결합하여 Kafka로 보낼 것인가?"였습니다. 매 패킷(Flow)마다 외부 DB나 API를 호출하는 것은 고속 네트워크 환경에서 불가능하기 때문입니다.

 

이를 해결한 IPFIX Collector의 핵심 기술적 강점은 OVSDB client의 Cache 기능입니다.

OVSDB Client Cache 메커니즘

• 실시간 동기화 및 Local Memory Look-up: Collector 내부의 OVSDB 클라이언트는 컴퓨트 노드의 OVSDB(인터페이스, 포트, 매핑 테이블 등)와 커넥션을 맺은 후, 데이터베이스의 변경 사항을 모니터링(Monitor RPC)합니다. 초기 구동 시 데이터를 로컬 메모리에 캐싱(Cache)해 두고, 이후 변경 사항(추가/삭제/수정)만 이벤트 형태로 전달받아 캐시를 최신 상태로 유지합니다.
• Zero-Network Latency 질의: IPFIX 패킷이 Collector에 들어오면, 외부 DB 조회를 위한 네트워크 라운드 트립(RTT) 없이 메모리 내 캐시에서 Interface ID나 Port 값을 기반으로 KCP 메타데이터를 즉시 매핑(Look-up)합니다.
• 고속 파이프라인 실현: 이 캐시 아키텍처 덕분에 인프라에 추가적인 부하를 주지 않으면서도, 초당 수만 건 이상의 Flow Record에 오픈스택 메타데이터를 실시간으로 결합(Enrichment)하여 Kafka로 밀어 넣는 초고속 파이프라인을 완성할 수 있었습니다.

---

5. 향후 로드맵 및 릴리즈 일정

 

클라우드팀과 데이터플랫폼팀의 긴밀한 협업을 통해 프로젝트는 순항 중이며, 서비스 제공을 위한 구체적인 타임라인은 다음과 같습니다.

• 4월 (QA 완료): 클라우드팀 주도로 로그 생성 및 수집 로직에 대한 QA 검증을 완료하고 5/7에 1차 배포를 마쳤습니다.
• 5월 ~ 6월 (파이프라인 구축): 데플팀에서 로그 가공 로직(파이프라인)을 개발 및 검증하고 있으며, 공동으로 데이터 가공을 위한 Query 정의를 완료했습니다.
• 7월 1일 (베타 서비스): 마침내 VPC Flow Log 서비스가 정식 오픈됩니다! 초기에는 mgmt stack에 저장되며 VOC 발생 시 가공 데이터를 추출하는 형태로 지원됩니다.
• 7월 이후 (진화): 사용자가 직접 VOC 및 로그를 조회할 수 있도록 LOKI(Observability 로그 저장소) 연계 개발을 추가 진행하여 사용자 경험을 극대화할 예정입니다.

포스트를 마치며 OVN의 최신 가상화 기술인 Flow Sampling과 Goflow2 기반의 최적화된 캐싱 아키텍처를 도입함으로써, 성능 저하 없는 대용량 VPC 가상 네트워크 로깅 시스템을 구축할 수 있었습니다. 안정적인 7월 출시와 더불어 향후 대시보드 및 고도화 서비스로 찾아뵙겠습니다. 기술적 질문이나 의견은 언제든 환영합니다!

 

 

---

?› 자주 묻는 질문 FAQ

Q. 기존 Neutron Packet Logging 방식 대비 OVN ACL Flow Sampling 방식의 가장 큰 차이점은 무엇인가요?

A. 기존 방식은 ACL 매칭 로그를 각 컴퓨트 노드의 로컬 파일( ovn-controller.log )에 텍스트로 기록하는 구조여서, 대규모 트래픽 시 디스크 I/O 부하가 심각하고 중앙 집중 수집을 위한 별도 에이전트 파이프라인이 필요했습니다. 반면 OVN ACL Flow Sampling 방식은 flow 메타 정보를 IPFIX 바이너리 포맷으로 네트워크를 통해 외부 Collector에 직접 전송하므로, 로컬 디스크 I/O 부하를 완전히 제거하고 고속·대용량 트래픽 처리에 훨씬 유리합니다.

Q. 매 Flow마다 외부 DB를 호출하지 않고 KCP 메타데이터(Tenant ID, VM 정보 등)를 어떻게 결합하나요?

A. OVSDB Client의 Cache 메커니즘을 활용합니다. Collector 내부의 OVSDB 클라이언트가 컴퓨트 노드의 OVSDB와 커넥션을 맺고, 초기 데이터를 로컬 메모리에 캐싱한 뒤 이후 변경 사항만 이벤트로 수신하여 캐시를 최신 상태로 유지합니다. IPFIX 패킷 수신 시 외부 네트워크 호출(RTT) 없이 메모리 내 Look-up만으로 메타데이터를 즉시 매핑(Zero-Network Latency)하기 때문에, 초당 수만 건 이상의 Flow Record도 실시간으로 Enrichment하여 Kafka로 전송할 수 있습니다.

Q. VPC Flow Log 서비스는 언제부터 이용할 수 있으며, 향후 어떤 기능이 추가될 예정인가요?

A. 7월 1일 베타 서비스로 정식 오픈됩니다. 초기에는 mgmt stack에 로그가 저장되며 VOC 발생 시 가공 데이터를 추출하는 형태로 지원됩니다. 7월 이후에는 사용자가 직접 VOC 및 로그를 조회할 수 있도록 LOKI(Observability 로그 저장소) 연계 개발을 진행하여, 대시보드 기반의 셀프서비스 로그 조회 경험을 제공할 예정입니다.

---