[OpenStack] OpenStack VXLAN 오버레이 네트워크 성능 벤치마크 가이드

목차

• 1. 왜 OpenStack VXLAN 성능 벤치마크가 중요한가요?
• 2. OpenStack VXLAN과 Neutron VXLAN 개념, 쉽게 정리해보겠습니다
• 2-1. 데이터 경로를 이해하면 벤치마크 포인트가 보입니다
• 2-2. VLAN과 VXLAN 비교
• 3. 벤치마크 설계: 오버레이 네트워크 성능을 정확히 측정하려면
• 3-1. 최소 측정 항목
• 3-2. 테스트 시나리오
• 4. 실전 구현: OpenStack VXLAN 테스트 환경 준비
• 4-1. 테넌트 네트워크 생성
• 4-2. 테스트용 인스턴스 2대 이상 배치
• 4-3. ML2 VXLAN 설정 확인
• 4-4. MTU 확인은 꼭 하셔야 합니다
• 5. 성능 측정 방법: iperf3, ping, 시스템 지표를 같이 보세요
• 5-1. 기본 처리량 측정
• 5-2. UDP와 손실률 확인
• 5-3. 지연시간과 격리 검증
• 5-4. 호스트 측 관찰 포인트
• 6. ⚠️ 트러블슈팅: 실제로 자주 막히는 지점
• 6-1. MTU 불일치
• 6-2. 오프로딩 설정 이슈
• 6-3. 보안 그룹과 conntrack 병목
• 6-4. 같은 노드와 다른 노드 성능 차이
• 7. 검증과 결과 해석: 숫자보다 중요한 것
• 8. 정리와 다음 단계: OpenStack 네트워크 튜닝은 이렇게 이어가시면 됩니다
• 자주 묻는 질문
• Q1. VXLAN이면 무조건 VLAN보다 느린가요?
• Q2. 벤치마크는 어떤 도구부터 쓰면 좋을까요?
• Q3. 테넌트 격리는 어떻게 검증하나요?

OpenStack VXLAN 오버레이 네트워크 성능 벤치마크 가이드

OpenStack VXLAN 환경에서 성능이 얼마나 나오는지 궁금하신 분들 많으실 겁니다. VM은 잘 뜨는데, 막상 테넌트 네트워크를 여러 개 나누고 나면 트래픽 처리량이 생각보다 안 나오거나, 지연시간이 튀는 경우가 있거든요. 저도 처음엔 "VXLAN이면 그냥 캡슐화 하나 더 되는 거니까 조금만 느리겠지" 정도로 생각했는데, 실제로 홈랩과 운영 비슷한 구조에서 만져보니 **MTU, 오프로딩(offloading, NIC 하드웨어 처리), OVS(Open vSwitch, 가상 스위치) 경로**에 따라 체감이 꽤 달라지더라고요.

이번 글에서는 OpenStack VXLAN 기반 오버레이 네트워크를 어떻게 벤치마크하면 좋을지, 그리고 Neutron VXLAN 환경에서 테넌트 격리와 처리량을 어떤 기준으로 봐야 하는지 정리해보겠습니다. 숫자를 지어내는 벤치마크 글은 의미가 없으니까, 이 글은 재현 가능한 측정 방법과 해석 기준에 초점을 맞췄습니다. 지금 OpenStack 네트워크 튜닝 중이시라면 꽤 바로 써먹으실 수 있을 거예요.

컨트롤러, 컴퓨트 노드, 테넌트 네트워크, 터널 엔드포인트가 보이는 OpenStack VXLAN 개요 이미지입니다.

1. 왜 OpenStack VXLAN 성능 벤치마크가 중요한가요?

쉽게 말해 VXLAN(Virtual Extensible LAN, 가상 확장 LAN)은 물리 네트워크 위에 가상 네트워크를 하나 더 얹는 방식입니다. 멀티테넌트 환경에서는 정말 편하거든요. VLAN ID 제한에 덜 묶이고, 테넌트별 네트워크를 유연하게 분리할 수 있으니까요. 근데 여기서 중요한 포인트가 있어요. 편리함과 성능은 항상 같은 방향으로 가지는 않는다는 점 말이에요.

• 캡슐화(encapsulation, 패킷을 한 번 더 감싸는 작업) 오버헤드가 생깁니다.
• MTU 설정이 맞지 않으면 단편화(fragmentation, 패킷 쪼개짐)로 성능이 무너질 수 있습니다.
• OVS나 Linux bridge 경로에 따라 CPU 사용률이 크게 달라집니다.
• east-west traffic(이스트-웨스트 트래픽, VM 간 내부 통신)과 north-south traffic(노스-사우스 트래픽, 외부와의 통신)을 나눠서 봐야 합니다.

실제로 써보니까 성능 저하 자체보다 더 무서운 건 병목 지점을 모른 채 감으로 튜닝하는 상황이었어요. 이게 제일 오래 갑니다. 삽질 좀 했습니다 ㅎㅎ

2. OpenStack VXLAN과 Neutron VXLAN 개념, 쉽게 정리해보겠습니다

OpenStack 네트워크에서 VXLAN은 보통 Neutron(뉴트론, OpenStack 네트워크 서비스)의 오버레이 메커니즘으로 사용돼요. 각 컴퓨트 노드는 터널 종단점 VTEP(VXLAN Tunnel Endpoint, VXLAN 터널 끝점) 역할을 하고, 테넌트 네트워크 트래픽을 UDP 기반 VXLAN 패킷으로 캡슐화해 전달합니다.

2-1. 데이터 경로를 이해하면 벤치마크 포인트가 보입니다

1. VM에서 패킷이 나갑니다.
2. 가상 NIC를 통해 보안 그룹과 가상 스위치를 통과합니다.
3. 로컬 브리지에서 VXLAN 캡슐화가 이뤄집니다.
4. 물리 underlay(언더레이, 실제 네트워크)로 전송됩니다.
5. 상대 노드에서 디캡슐화(decapsulation, 캡슐 해제) 후 대상 VM으로 들어갑니다.

여기서 성능 포인트는 명확해요. 가상 스위치 처리, 터널 캡슐화, 물리 NIC, MTU 이 네 군데를 봐야 합니다.

2-2. VLAN과 VXLAN 비교

항목	VLAN	VXLAN
격리 방식	L2 태그 기반	오버레이 터널 기반
확장성	상대적으로 제한적	멀티테넌트 확장에 유리
설계 복잡도	비교적 단순	터널, MTU, 오프로딩 고려 필요
성능 변수	상대적으로 적음	캡슐화 오버헤드 영향 있음
OpenStack 활용	Provider network에 자주 사용	Tenant network에 자주 사용

벤치마크를 할 때는 "VXLAN이 느리다"가 아니라, 어떤 경로에서 얼마나 손실이 생기는지를 봐야 합니다.

3. 벤치마크 설계: 오버레이 네트워크 성능을 정확히 측정하려면

제가 직접 해보니 벤치마크가 실패하는 가장 흔한 이유는 측정 항목이 너무 단순하다는 거였어요. `iperf3` 한 번 돌려보고 끝내면, 그건 네트워크 테스트라기보다 순간 샘플에 가까우니까요.

3-1. 최소 측정 항목

• 처리량(throughput, 초당 전송량): TCP/UDP 각각 확인
• 지연시간(latency, 왕복 시간): ping 또는 fping으로 확인
• 패킷 손실(packet loss): UDP 테스트에서 특히 중요
• CPU 사용률: 컴퓨트 노드의 `ovs-vswitchd`, `qemu-kvm`, `softirq` 확인
• MTU 일관성: 인스턴스, TAP, 브리지, 물리 NIC가 연결되는지 확인

3-2. 테스트 시나리오

1. 같은 컴퓨트 노드 내 VM 간 통신
2. 다른 컴퓨트 노드 간 VM 통신
3. 같은 테넌트 네트워크 내 다수 VM 동시 통신
4. 서로 다른 테넌트 간 격리 검증
5. floating IP 또는 router를 통한 외부 통신

여기서 두 번째와 세 번째가 핵심이에요. 첫 번째만 보면 터널 영향이 덜 보일 수 있거든요. 반대로 크로스-노드(cross-node, 노드 간) 테스트를 해보면 오버레이 네트워크 성능 차이가 확실히 드러납니다.

4. 실전 구현: OpenStack VXLAN 테스트 환경 준비

이제 실제로 측정 가능한 구조를 만들어보겠습니다. 예시는 OpenStack CLI 기준으로 적겠습니다. 배포판은 다양하지만, 개념은 거의 비슷해요.

4-1. 테넌트 네트워크 생성

openstack network create demo-vxlan-net
openstack subnet create demo-vxlan-subnet \
  --network demo-vxlan-net \
  --subnet-range 10.10.10.0/24

openstack router create demo-router
openstack router add subnet demo-router demo-vxlan-subnet

환경에 따라 외부 네트워크 연결도 필요합니다.

openstack router set demo-router --external-gateway public

4-2. 테스트용 인스턴스 2대 이상 배치

openstack server create vxlan-test-1 \
  --flavor m1.small \
  --image ubuntu \
  --network demo-vxlan-net \
  --key-name mykey

openstack server create vxlan-test-2 \
  --flavor m1.small \
  --image ubuntu \
  --network demo-vxlan-net \
  --key-name mykey

여기서 가능하면 서로 다른 컴퓨트 노드에 올리는 게 좋아요. 스케줄러 힌트나 가용성 영역을 활용하면 더 명확하게 분리할 수 있습니다.

4-3. ML2 VXLAN 설정 확인

배포 환경마다 파일 위치가 다를 수 있지만, 핵심은 ML2 plugin(ML2 플러그인)과 VXLAN 타입 드라이버가 활성화되어 있는지에요.

[ml2]
type_drivers = flat,vlan,vxlan
tenant_network_types = vxlan
mechanism_drivers = openvswitch,l2population

[ml2_type_vxlan]
vni_ranges = 1001:2000

`l2population`은 브로드캐스트/플러딩을 줄이는 데 도움이 되는 기능으로 잘 알려져 있어요. 대규모 환경일수록 의미가 커집니다.

Neutron ML2 설정, VNI 범위, 각 컴퓨트 노드의 VXLAN 터널 연결 관계를 보여주는 이미지입니다.

4-4. MTU 확인은 꼭 하셔야 합니다

VXLAN은 추가 헤더가 붙기 때문에 underlay MTU보다 tenant MTU를 조금 보수적으로 잡는 경우가 많아요. 이 부분을 놓치면 `iperf3`는 애매하게 나오고, 대용량 전송에서만 문제가 재현되기도 합니다. 저도 처음엔 보안 그룹만 의심했는데, 결국 MTU 문제였던 적이 있었어요.

ip link show
ip addr
ping -M do -s 1472 <target_ip>

`-M do`는 경로 MTU를 강제로 확인할 때 유용해요. 패킷 크기를 조금씩 조정해보면 어디서 단편화가 발생하는지 감이 옵니다.

5. 성능 측정 방법: iperf3, ping, 시스템 지표를 같이 보세요

5-1. 기본 처리량 측정

테스트 VM 한쪽에서는 서버를 띄우고, 다른 쪽에서는 클라이언트로 붙습니다.

# server
iperf3 -s

# client
iperf3 -c 10.10.10.20 -t 30 -P 4

여기서 `-P 4`처럼 병렬 스트림(parallel stream, 동시 세션)을 주는 이유는 단일 세션만으로는 경로 활용도를 다 못 볼 수 있기 때문이에요.

5-2. UDP와 손실률 확인

iperf3 -c 10.10.10.20 -u -b 1G -t 30

UDP는 대역폭을 강제로 밀어붙이니까 손실과 지터(jitter, 지연 변동폭)를 보기 좋아요. 다만 숫자만 보고 "실사용도 이렇다"고 단정하면 안 돼요. 어디까지나 한계 구간을 찾는 용도에 가깝습니다.

5-3. 지연시간과 격리 검증

ping -c 20 10.10.10.20

openstack network create isolated-net
openstack subnet create isolated-subnet \
  --network isolated-net \
  --subnet-range 10.20.20.0/24

서로 다른 테넌트 네트워크에서 직접 통신이 안 되는지 확인해보세요. 테넌트 격리는 보안 기능이자 성능 분석의 기준선이에요. 격리가 흐트러지면 벤치마크 이전에 설계부터 다시 봐야 합니다.

5-4. 호스트 측 관찰 포인트

top
htop
sar -n DEV 1
ip -d link show
ovs-vsctl show
ovs-ofctl dump-ports br-tun

성능이 기대보다 안 나오는데 VM 내부는 멀쩡하다면, 호스트의 softirq나 OVS 포트 카운터를 같이 봐야 해요. 근데 여기서 중요한 건, 네트워크만 보지 말고 CPU를 같이 보라는 점이에요. 오버레이는 생각보다 CPU 영향을 받거든요.

6. ⚠️ 트러블슈팅: 실제로 자주 막히는 지점

이 섹션은 정말 중요해요. 제가 홈랩에서 OpenStack 네트워크 만질 때 제일 오래 잡아먹은 부분들이거든요.

6-1. MTU 불일치

• 증상: TCP는 되는데 대용량 전송에서 처리량이 애매하게 떨어짐
• 원인: VXLAN 캡슐화 헤더를 고려하지 않은 MTU 설정
• 해결: 인스턴스 NIC, TAP, `br-int`, `br-tun`, 물리 NIC까지 경로 전체 MTU 점검

6-2. 오프로딩 설정 이슈

• 증상: CPU 사용률이 과하게 올라가고 처리량이 들쭉날쭉함
• 원인: NIC offload와 가상화 경로 조합 문제
• 해결: `ethtool -k`로 현재 상태를 보고 변경 전후 비교 측정

ethtool -k eth0

이건 환경마다 정답이 달라요. 무조건 켜라, 무조건 꺼라 식으로 가면 위험해요. 그래서 반드시 변경 전후를 같은 조건으로 비교해야 합니다.

6-3. 보안 그룹과 conntrack 병목

• 증상: 연결 수가 늘면 응답이 갑자기 무거워짐
• 원인: stateful filtering(상태 기반 필터링)과 connection tracking 부담
• 해결: 테스트 시나리오를 단순화하고, 보안 정책 영향도 분리해서 확인

6-4. 같은 노드와 다른 노드 성능 차이

같은 컴퓨트 노드 안에서는 생각보다 잘 나오는데, 다른 노드로 넘어가는 순간 성능이 달라지는 경우가 많아요. 이럴 때는 거의 대부분 터널 경로 또는 물리 underlay를 의심하게 됩니다.

VM 간 iperf3 측정, 호스트 CPU 사용률, MTU 점검 포인트가 함께 보이는 실전 운영 이미지입니다.

7. 검증과 결과 해석: 숫자보다 중요한 것

벤치마크 결과를 볼 때 저는 보통 아래 순서로 해석해요. 숫자 하나만 보고 결론 내리면 나중에 꼭 후회하더라고요.

1. 같은 노드와 다른 노드 간 격차가 큰가
2. TCP와 UDP 결과 차이가 과도한가
3. 지연시간 평균보다 편차가 큰가
4. 호스트 CPU 사용률이 병목처럼 보이는가
5. 테넌트 수 증가 시 성능 하락 패턴이 급격한가

예를 들어 처리량이 조금 낮아도 지연시간이 안정적이고 손실이 적다면, 실서비스에서는 충분히 좋은 결과일 수 있어요. 반대로 순간 최대 처리량이 높아도 CPU가 포화되고 지터가 심하면 운영 입장에서는 불안한 구조죠.

검증 항목	좋은 신호	주의 신호
처리량	반복 측정 시 편차가 작음	테스트마다 편차가 큼
지연시간	평균과 최대값 차이가 적당함	간헐적 스파이크 발생
패킷 손실	UDP 부하에서도 통제 가능	부하 시 급격히 증가
CPU 사용률	여유가 있음	ovs-vswitchd 또는 softirq 집중
격리 상태	테넌트 간 통신 차단 명확	정책 누락 또는 라우팅 혼선

오버레이 네트워크 성능은 결국 설계와 운영 습관의 결과물이에요. 그래서 결과 보고서에는 숫자만 넣지 말고, 테스트 조건도 같이 남기시는 걸 권장합니다. 다음에 다시 비교할 때 진짜 큰 도움이 돼요.

처리량, 지연시간, CPU 사용률을 함께 보여주는 OpenStack VXLAN 벤치마크 결과 시각화 이미지입니다.

8. 정리와 다음 단계: OpenStack 네트워크 튜닝은 이렇게 이어가시면 됩니다

정리해보면 OpenStack VXLAN 벤치마크에서 중요한 건 단순 최고 속도가 아니에요. Neutron VXLAN 환경에서 테넌트 격리가 제대로 되는지, 크로스-노드 트래픽이 안정적인지, MTU와 OVS 경로가 일관적인지, 그리고 호스트 CPU가 어디서 쓰이는지를 같이 봐야 합니다.

제가 직접 해보니 가장 효과가 컸던 접근은 이것이었어요.

1. 같은 노드와 다른 노드 결과를 분리해서 기록합니다.
2. TCP, UDP, ping을 각각 따로 봅니다.
3. 문제가 보이면 MTU와 오프로딩부터 확인합니다.
4. 그 다음에 보안 그룹, conntrack, underlay를 봅니다.

이 순서로 가면 삽질을 꽤 줄일 수 있어요. 드디어 됐다! 싶은 순간이 오거든요.

MTU, 오프로딩, OVS, 테넌트 격리, 처리량 검증 항목을 한눈에 정리한 요약 인포그래픽입니다.

자주 묻는 질문

Q1. VXLAN이면 무조건 VLAN보다 느린가요?

무조건 그렇지는 않아요. 캡슐화 오버헤드는 있지만, 실제 체감은 NIC 성능, CPU, OVS 구성, underlay 품질에 따라 달라집니다.

Q2. 벤치마크는 어떤 도구부터 쓰면 좋을까요?

가볍게는 `ping`, `iperf3`, `sar`, `ethtool`, `ovs-vsctl` 정도면 시작하기 좋아요. 도구보다 중요한 건 같은 조건으로 반복 측정하는 습관입니다.

Q3. 테넌트 격리는 어떻게 검증하나요?

서로 다른 테넌트 네트워크에 VM을 두고 직접 통신 가능 여부, 라우터 연결 여부, 보안 그룹 정책을 분리해서 확인하시면 돼요.

다음 글에서는 Open vSwitch 기반에서 `br-int`, `br-tun`, provider network 경로를 좀 더 깊게 파서, 어디서 병목이 생기는지 보는 방법을 다뤄볼 예정입니다. 이전 글에서 다룬 Linux 네트워크 기본기와 함께 보시면 훨씬 이해가 잘 될 거예요.

📚 함께 읽으면 좋은 글

• OpenStack Manila 도입 1년 회고
• OpenStack Floating IP 연결 문제 해결: 보안 그룹 디버깅
• OpenStack 보안 그룹 취약점과 Floating IP 보안 강화 전략