본문으로 건너뛰기

VPC CNI vs Cilium CNI 성능 비교 벤치마크

📅 작성일: 2026-02-09 | 수정일: 2026-02-14 | ⏱️ 읽는 시간: 약 16분

개요​

Amazon EKS 1.31 환경에서 VPC CNI와 Cilium CNI의 성능을 5개 시나리오로 정량 비교한 벤치마크 보고서입니다.

벤치마크 결론

=
≈ 동일
TCP Throughput
NIC 대역폭 포화 (12.5 Gbps), CNI 무관
⚙️
기능 차이
UDP 패킷 손실
Bandwidth Manager 유무 차이 (iperf3 극한 조건, 일반 환경에서 발생 어려움)
🔗
-36% RTT
Multi-hop 추론 파이프라인
Gateway→Router→vLLM→RAG→VectorDB 다단 hop에서 RTT 절감 누적, HTTP/gRPC 실시간 추론 서빙 시 유의미
🔍
기능 > 성능
핵심 선택 기준
L7 정책, FQDN 필터링, Hubble 관찰성, kube-proxy-less
두 CNI의 성능 차이는 실환경에서 미미하며, 선택의 핵심은 eBPF 기반 관찰성·정책·아키텍처 등 기능입니다. 다만 multi-hop 추론 파이프라인에서는 RTT 누적 절감이 체감될 수 있습니다.

5개 시나리오:

  • A VPC CNI 기본 (베이스라인)
  • B Cilium + kube-proxy (전환 영향 측정)
  • C Cilium kube-proxy-less (kube-proxy 제거 효과)
  • D Cilium ENI 모드 (Overlay vs Native Routing)
  • E Cilium ENI + 풀 튜닝 (누적 최적화 효과)

주요 시사점:

지표VPC CNI (A)Cilium ENI+Tuning (E)개선폭
TCP 처리량12.41 Gbps12.40 Gbps동일 (NIC 포화)
UDP 패킷 손실20.39%0.03%Bandwidth Manager 적용
Pod 간 RTT4,894 µs3,135 µs36% 단축
HTTP p99 @QPS=100010.92 ms8.75 ms*20% 감소
서비스 스케일링 (1000 svc)iptables 101배 증가, 연결당 +16%O(1) 성능 일정O(1) vs O(n)

* HTTP p99 개선은 최적화된 네트워크 경로와 감소된 지연시간을 반영

🤖AI/ML 워크로드 관련성 가이드
본 CNI 벤치마크가 EKS 기반 Training 및 Inference에 미치는 영향
-20%
HTTP p99 Latency
Inference 서빙
-36%
Pod-to-Pod RTT
Pipeline hop 누적
O(1)
Service Scaling
Model Endpoint
N/A
EFA Training
CNI 우회
워크로드 유형별 관련성
⚡실시간 Inference 서빙
높음
HTTP/gRPC 기반 · Service Scaling 결과 직접 적용
🔗Inference Pipeline (multi-hop)
높음
RTT 개선이 hop마다 누적
📦Batch Inference
보통
Throughput 중심 · CNI 차이 미미
🧠분산 Training (EFA 미사용)
보통
NCCL TCP/UDP 통신에 일부 영향
🚀분산 Training (EFA 사용)
낮음
Kernel 네트워크 스택 완전 우회
💻단일 노드 Training
없음
네트워크 의존성 없음
참고: 본 벤치마크는 m6i.xlarge (12.5 Gbps, GPU 미탑재) 환경에서 측정되었습니다. GPU 인스턴스(g5, p4d, p5, inf2)는 25–400 Gbps NIC과 EFA를 지원하므로, 프로덕션 사이징을 위해서는 GPU 인스턴스 전용 AI/ML 벤치마크를 별도로 수행하는 것을 권장합니다.

테스트 환경​

🖥️ 테스트 환경
EKS 1.31 · 단일 AZ · 최소 3회 반복 측정 중앙값
EKS 버전
1.31 (Platform: eks.51)
Cilium 버전
1.16.5 (Helm Chart: cilium-1.16.5)
노드 타입
m6i.xlarge (4 vCPU, 16 GB RAM, ENA NIC)
노드 수
3 (단일 AZ: ap-northeast-2a)
OS / Kernel
Amazon Linux 2023 · 6.1.159-182.297.amzn2023
컨테이너 런타임
containerd 2.1.5
Service CIDR
10.100.0.0/16
도구
kubectl 1.31+, Cilium CLI 0.16+, Helm 3.16+, Fortio 1.65+, iperf3 3.17+
측정 방식
최소 3회 반복 측정 후 중앙값 사용

클러스터 구성: scripts/benchmarks/cni-benchmark/cluster.yaml 참조 워크로드 배포: scripts/benchmarks/cni-benchmark/workloads.yaml 참조

테스트 시나리오​

5개 시나리오는 CNI, kube-proxy 모드, IP 할당 방식, 튜닝 적용 여부를 조합하여 각 변수의 독립적 영향을 측정하도록 설계했습니다.

🧪 테스트 시나리오
CNI, kube-proxy 모드, IP 할당 방식, 튜닝 적용 여부를 조합한 5개 구성
AVPC CNI 기본베이스라인
CNI: VPC CNIkube-proxy: iptablesIP 할당: ENI Secondary IP튜닝: 기본값
BCilium + kube-proxyCNI 전환 영향
CNI: Ciliumkube-proxy: iptables 유지IP 할당: Overlay (VXLAN)튜닝: 기본값
CCilium kube-proxy-lesskube-proxy 제거 효과
CNI: Ciliumkube-proxy: eBPF 대체IP 할당: Overlay (VXLAN)튜닝: 기본값
DCilium ENI 모드Overlay vs Native
CNI: Ciliumkube-proxy: eBPF 대체IP 할당: AWS ENI (native)튜닝: 기본값
ECilium ENI + 풀 튜닝튜닝 누적 효과
CNI: Ciliumkube-proxy: eBPF 대체IP 할당: AWS ENI (native)튜닝: 전체 적용

시나리오 E 튜닝 포인트​

튜닝 항목Helm 값효과적용 여부
BPF Host Routingbpf.hostLegacyRouting=falseHost NS iptables bypass✅적용됨
DSRloadBalancer.mode=dsrNodePort/LB direct return❌미적용
(ENA compat)
Bandwidth ManagerbandwidthManager.enabled=trueEDT rate limiting✅적용됨
BPF Masqueradebpf.masquerade=trueiptables MASQUERADE → eBPF✅적용됨
Socket-level LBsocketLB.enabled=trueLB at connect()✅적용됨
XDP AccelerationloadBalancer.acceleration=nativeNIC driver processing❌미적용
(ENA bpf_link)
BBRbandwidthManager.bbr=trueGoogle BBR congestion✅적용됨
Native RoutingroutingMode=nativeRemove VXLAN✅적용됨
CT Table Expansionbpf.ctGlobalAnyMax/TcpMaxExpand Connection Tracking✅적용됨
Hubble Disabledhubble.enabled=falseRemove observability overhead✅적용됨
XDP 및 DSR 호환성 제약

m6i.xlarge 인스턴스의 ENA 드라이버는 XDP bpf_link 기능을 지원하지 않아 XDP acceleration(native/best-effort)을 사용할 수 없습니다. DSR 모드 또한 Pod 크래시를 유발하여 기본 SNAT 모드로 회귀했습니다. 시나리오 E는 나머지 8개 튜닝을 적용한 결과입니다.

아키텍처​

패킷 경로 비교: VPC CNI vs Cilium​

VPC CNI(kube-proxy)와 Cilium(eBPF)에서 Pod-to-Service 트래픽의 패킷 경로 차이를 비교합니다.

Cilium 아키텍처 개요​

Cilium Daemon이 커널의 BPF 프로그램을 관리하며, 각 컨테이너와 네트워크 인터페이스(eth0)에 eBPF 프로그램을 주입합니다.

Cilium Architecture 출처: Cilium Component Overview

Cilium eBPF 패킷 경로​

Pod-to-Pod 통신에서 eBPF 프로그램은 veth pair(lxc)에 부착되어 iptables를 완전히 우회합니다. 아래 다이어그램은 Endpoint 간 직접 통신 경로를 보여줍니다.

Cilium eBPF Endpoint-to-Endpoint 출처: Cilium - Life of a Packet

Cilium Native Routing (ENI 모드)​

Native Routing 모드에서 Pod 트래픽은 VXLAN 캡슐화 없이 호스트의 라우팅 테이블을 통해 직접 전달됩니다. ENI 모드에서는 Pod IP가 VPC CIDR에서 직접 할당됩니다.

Cilium Native Routing 출처: Cilium Routing

Cilium ENI IPAM 아키텍처​

Cilium Operator가 EC2 API를 통해 ENI에서 IP를 할당하고, CiliumNode CRD를 통해 각 노드의 Agent에 IP Pool을 제공합니다.

Cilium ENI Architecture 출처: Cilium ENI Mode

5개 시나리오별 데이터 플레인 스택​

각 시나리오의 Service LB, CNI Agent, 네트워크 계층 구성과 주요 성능 지표를 비교합니다.

데이터 플레인 스택 비교

테스트 방법​

테스트 워크로드​

  • httpbin: HTTP 에코 서버 (2 replicas)
  • Fortio: HTTP 부하 생성기
  • iperf3: 네트워크 처리량 측정 서버/클라이언트

측정 메트릭​

  1. 네트워크 성능: TCP/UDP Throughput, Pod-to-Pod Latency (p50/p99), Connection Setup Rate
  2. HTTP 성능: QPS별 처리량 및 지연 (Fortio → httpbin)
  3. DNS 성능: 해석 지연 (p50/p99), QPS Capacity
  4. 리소스 사용량: CNI 자체 CPU/메모리 오버헤드
  5. 튜닝 효과: 개별 튜닝 포인트의 성능 기여도

벤치마크 실행​

전체 시나리오 일괄 실행:

./scripts/benchmarks/cni-benchmark/run-all-scenarios.sh

개별 시나리오 실행:

./scripts/benchmarks/cni-benchmark/run-benchmark.sh <scenario-name>

상세 테스트 절차는 스크립트 내부 주석 참조.

벤치마크 결과​

데이터 수집 완료

아래 결과는 2026-02-09 EKS 1.31 환경(m6i.xlarge, Amazon Linux 2023, 단일 AZ)에서 측정되었습니다. 각 메트릭은 최소 3회 반복 측정 후 중앙값을 사용했습니다.

네트워크 성능​

TCP/UDP 처리량​

TCP Throughput (Gbps)

NIC limit: 12.5 Gbps
A: VPC CNI
12.41 Gbps
B: Cilium+kp
12.34 Gbps
C: kp-less
12.34 Gbps
D: ENI
12.41 Gbps
E: ENI+Tuned
12.40 Gbps
All scenarios saturated at NIC bandwidth (~12.4 Gbps). TCP throughput is not a differentiator across CNI configurations.

UDP Throughput (Gbps)

Higher ≠ better · check loss rate
A: VPC CNI
10.00 Gbps
⚠ 20% loss
B: Cilium+kp
7.92 Gbps
C: kp-less
7.92 Gbps
D: ENI
10.00 Gbps
⚠ 20% loss
E: ENI+Tuned
7.96 Gbps
Red bars indicate high throughput with 20%+ packet loss (no Bandwidth Manager). Effective data transfer is lower despite higher raw throughput.

iperf3 · 10s duration · m6i.xlarge (12.5 Gbps baseline) · Median of 3+ runs

UDP 패킷 손실 차이는 기능 차이이지 성능 차이가 아닙니다

TCP는 모든 시나리오에서 NIC 대역폭(12.5 Gbps)에 포화되어 차이가 없으며, 이것이 실제 CNI 성능을 대표합니다. UDP에서 관찰된 패킷 손실률 차이는 다음과 같은 맥락에서 이해해야 합니다:

  • iperf3 테스트의 특수성: iperf3은 가능한 최대 속도로 UDP 패킷을 전송하여 의도적으로 네트워크를 포화시킵니다. 이는 실제 프로덕션 워크로드에서 거의 발생하지 않는 극단적 조건입니다.
  • 버퍼 오버플로우가 원인: 시나리오 A(VPC CNI)와 D(Cilium ENI 기본)에서 20%의 패킷 손실이 발생한 이유는 커널 UDP 버퍼가 고속 전송을 감당하지 못해 오버플로우가 발생했기 때문입니다.
  • Bandwidth Manager는 기능: 시나리오 E에서 손실률이 0.03%로 감소한 것은 Bandwidth Manager(EDT 기반 rate limiting)가 전송 속도를 수신 처리 능력에 맞춰 조절했기 때문입니다. 이는 Cilium의 추가 기능이지, CNI 자체의 성능 우위를 의미하지 않습니다.

결론: 일반적인 프로덕션 워크로드에서는 UDP 패킷 손실 차이가 체감되기 어렵습니다. Bandwidth Manager가 필요한 경우(대용량 미디어 스트리밍 등 극한 UDP 워크로드)에 한해 Cilium의 해당 기능이 유의미합니다.

Pod-to-Pod 지연​

Pod-to-Pod RTT (µs)

Lower is better
A: VPC CNI
4,894 µs
B: Cilium+kp
4,955 µs
C: kp-less
5,092 µs
D: ENI
4,453 µs
E: ENI+Tuned
3,135 µs
✓ Lowest
-36% vs Baseline (A→E)
-9% ENI native routing (A→D)
-30% Tuning effect (D→E)

Median of 3+ measurements · Single AZ (ap-northeast-2a) · m6i.xlarge nodes

UDP 패킷 손실률​

UDP Packet Loss (%)

Lower is better
A: VPC CNI
20.39%
B: Cilium+kp
0.94%
C: kp-less
0.69%
D: ENI
20.42%
⚠ High
E: ENI+Tuned
0.03%
✓ Lowest
Bandwidth Manager + BBR enabled (E)
20%+ loss without Bandwidth Manager (A, D)

UDP Throughput (Gbps)

Higher is better · but check loss rate
A: VPC CNI
10.00 Gbps
B: Cilium+kp
7.92 Gbps
C: kp-less
7.92 Gbps
D: ENI
10.00 Gbps
E: ENI+Tuned
7.96 Gbps
⚠ High throughput with high loss (A, D) means lower effective data transfer. Bandwidth Manager + BBR (E) optimizes for reliable delivery.

iperf3 UDP test · 10s duration · Median of 3+ measurements

상세 데이터 테이블
메트릭A: VPC CNIB: Cilium+kpC: kp-lessD: ENIE: ENI+튜닝
TCP Throughput (Gbps)12.4112.3412.3412.4112.40
UDP Throughput (Gbps)10.007.927.9210.007.96
UDP Loss (%)20.390.940.6920.420.03
Pod-to-Pod RTT p50 (µs)48944955509244533135
Pod-to-Pod RTT p99 (µs)48944955509244533135
TCP Throughput 포화

m6i.xlarge의 기준 네트워크 대역폭은 12.5 Gbps입니다. 모든 시나리오에서 TCP throughput이 이 한계에 도달하여 CNI별 차이가 나타나지 않았습니다.

HTTP 애플리케이션 성능​

HTTP p99 Latency @QPS=1000 (ms)

Lower is better
A: VPC CNI
10.92
B: Cilium+kp
9.87
C: kp-less
8.91
D: ENI
8.75
✓ Lowest
E: ENI+Tuned
9.89

Maximum Achieved QPS

Higher is better
A: VPC CNI
4,104
B: Cilium+kp
4,045
C: kp-less
4,019
D: ENI
4,026
E: ENI+Tuned
4,182
✓ Highest

Measurements at QPS=1000 · Optimal configurations vary by workload

상세 데이터 테이블
QPS 목표메트릭A: VPC CNIB: Cilium+kpC: kp-lessD: ENIE: ENI+튜닝
1,000Actual QPS999.6999.6999.7999.7999.7
1,000p50 (ms)4.394.364.454.294.21
1,000p99 (ms)10.929.878.918.759.89
5,000Actual QPS4071.14012.03986.53992.64053.2
5,000p99 (ms)440.4521.60358.3823.0124.44
MaxActual QPS4103.94044.74019.34026.44181.9
Maxp99 (ms)28.0725.2528.5026.6728.45
QPS=5000 이상 부하 시 변동성

시나리오 A와 C에서 QPS=5000 테스트 시 p99가 비정상적으로 높게 측정되었습니다(440ms, 358ms). 이는 일시적인 네트워크 혼잡으로 추정되며, Max QPS 테스트(~4000QPS 실측)에서는 정상 수준(25-28ms)으로 회귀했습니다. 재현성 있는 비교를 위해 QPS=1000 결과를 주요 지표로 사용하는 것을 권장합니다.

서비스 수 확장에 따른 성능 영향 (Scenario E)​

Cilium eBPF의 O(1) 서비스 룩업 성능을 검증하기 위해, 동일한 Scenario E 환경에서 서비스 수를 4개 → 104개로 변경한 후 성능을 비교했습니다.

4 Services vs 104 Services — eBPF O(1) hash map lookup
4 Services
104 Services
HTTP p99 @QPS=1000
4 Svc
3.94ms
104 Svc
3.64ms
-8% (within noise)
Max Achieved QPS
4 Svc
4,405
104 Svc
4,221
-4.2%
TCP Throughput (Gbps)
4 Svc
12.3
104 Svc
12.4
~identical
DNS Resolution p50
4 Svc
2ms
104 Svc
2ms
identical
Key Insight
eBPF maintains O(1) performance regardless of service count. With iptables (kube-proxy), service lookup degrades O(n) as rules increase — significant at 500+ services.
상세 데이터 테이블
메트릭4 Services104 Services차이
HTTP p99 @QPS=1000 (ms)3.943.64-8% (측정 오차 범위)
최대 달성 QPS4,4054,221-4.2%
TCP Throughput (Gbps)12.312.4~동일
DNS Resolution p50 (ms)22동일
eBPF O(1) 서비스 룩업 확인

Cilium eBPF 환경에서 서비스 수를 4개에서 104개로 26배 증가시켰음에도 모든 메트릭이 측정 오차 범위(5% 이내)에서 동일했습니다. 이는 eBPF의 해시 맵 기반 O(1) 룩업이 서비스 수에 무관하게 일정한 성능을 유지함을 확인합니다. 다만, 아래 kube-proxy 스케일링 테스트에서 보듯 iptables 방식의 오버헤드도 1,000개 서비스 수준에서는 실질적으로 미미하여, 서비스 수가 수천 개 이상으로 대규모화되지 않는 한 이 차이가 실제 성능에 영향을 미칠 가능성은 낮습니다.

kube-proxy (iptables) 서비스 스케일링: 4 → 104 → 1,000개​

eBPF의 O(1) 장점을 대조 검증하기 위해 VPC CNI + kube-proxy (시나리오 A)에서 서비스 수를 4개 → 104개 → 1,000개로 확장하며 성능 변화를 측정했습니다.

kube-proxy (iptables) 서비스 스케일링
4 → 104 → 1,000개 서비스 — iptables 규칙 증가 vs eBPF O(1)
4개
104개
1,000개
낮을수록 좋음 (Max QPS 제외)

iptables 규칙 증가

NAT Rules+101×
4개
99
104개
699
1,000개
10,059
kube-proxy Sync+31%
4개
~130ms
104개
~160ms
1,000개
~170ms

keepalive HTTP 성능

HTTP p99 @QPS=1000~noise
4개
5.86ms
104개
5.99ms
1,000개
2.96ms
Max QPS~same
4개
4,197
104개
4,231
1,000개
4,178

Connection:close 오버헤드

Conn Setup Avg+16% (+26µs)
4개
164 µs
1,000개
190 µs
HTTP p99+5%
4개
8.11ms
1,000개
8.53ms
HTTP Total Avg+5%
4개
4.399ms
1,000개
4.621ms

Cilium eBPF (비교)

HTTP p99 @QPS=1000-8% (noise)
4개
3.94ms
104개
3.64ms
eBPF Map Lookupconstant
4개
O(1)
104개
O(1)
1,000개
O(1)
핵심 인사이트
1,000개 서비스에서 iptables NAT 규칙이 101배 증가(99→10,059)하며, 연결당 설정 시간이 +26µs(+16%) 추가됩니다. keepalive 연결은 conntrack 캐싱으로 영향 없음. Cilium eBPF는 서비스 수와 무관하게 O(1) 해시 맵 조회를 유지합니다.
⚠️ 스케일링 임계점
5,000개 이상 서비스에서 kube-proxy sync가 500ms를 초과하고, 체인 순회가 연결당 수백 µs를 추가합니다.

keepalive vs Connection:close 비교 분석​

keepalive 모드 (기존 연결 재사용): iptables 규칙이 101배 증가해도 HTTP 성능에 영향 없음. 이는 conntrack이 이미 설정된 연결의 패킷을 캐시하여 iptables 체인 순회를 우회하기 때문입니다.

Connection:close 모드 (매 요청마다 신규 TCP 연결): 모든 SYN 패킷에서 KUBE-SERVICES iptables 체인을 순회하여 DNAT 규칙을 평가합니다. 1,000개 서비스에서 연결당 +26µs (+16%) 오버헤드가 측정되었습니다.

왜 Connection:close 테스트가 중요한가?

프로덕션 환경에서 keepalive를 사용하지 않는 워크로드(gRPC 미사용 레거시 서비스, 단발성 HTTP 요청, TCP 기반 마이크로서비스 등)는 매 요청마다 iptables 체인 순회 비용을 지불합니다. KUBE-SERVICES 체인은 확률 기반 매칭(-m statistic --mode random)을 사용하므로 평균 순회 길이는 O(n/2)이며, 서비스 수에 비례하여 증가합니다.

iptables 스케일링 특성

1,000개 서비스 규모에서 연결당 오버헤드는 +26µs(+16%)로 측정 가능하지만, 절대값으로는 매우 미미한 수준입니다. 이는 대부분의 프로덕션 환경에서 체감하기 어려운 차이입니다. 이론적으로 서비스 수에 선형 증가하는 O(n) 특성을 가지므로 수천 개 이상의 서비스에서는 누적 영향이 있을 수 있으나, 일반적인 EKS 클러스터(수백 개 서비스)에서는 iptables와 eBPF 간 실질적 성능 차이를 경험하기 어렵습니다. Cilium eBPF의 O(1) 조회는 대규모 서비스 환경에 대한 미래 대비(future-proofing) 측면에서 의미가 있습니다.

kube-proxy vs Cilium 전체 비교 데이터
메트릭kube-proxy 4개kube-proxy 104개kube-proxy 1000개변화 (4→1000)Cilium 4개Cilium 104개변화
HTTP p99 @QPS=10005.86ms5.99ms2.96ms-49%3.94ms3.64ms-8%
HTTP avg @QPS=10002.508ms2.675ms1.374ms-45%---
최대 QPS (keepalive)4,1974,2314,178~0%4,4054,221-4.2%
TCP 처리량12.4 Gbps12.4 Gbps--12.3 Gbps12.4 Gbps~0%
iptables NAT 규칙 수9969910,059+101배N/A (eBPF)N/A (eBPF)-
Sync 주기 시간~130ms~160ms~170ms+31%N/AN/A-
연결당 설정 시간 (Connection:close)164µs-190µs+16%N/AN/A-
HTTP avg (Connection:close)4.399ms-4.621ms+5%N/AN/A-
HTTP p99 (Connection:close)8.11ms-8.53ms+5%N/AN/A-

DNS 해석 성능 및 리소스 사용량​

🌐 DNS 해석 성능dig · 100회 쿼리 · 중앙값
A: VPC CNI
p50:2 ms
p99:4 ms
B: Cilium+kp
p50:2 ms
p99:4 ms
C: kp-less
p50:2 ms
p99:2 ms
D: ENI
p50:2 ms
p99:4 ms
E: ENI+Tuned
p50:2 ms
p99:3 ms
DNS 해석 지연은 모든 시나리오에서 2–4 ms 범위로, CNI 구성에 따른 차이가 거의 없습니다.
📊 CNI 리소스 사용량 (노드당, 부하 시)Cilium agent · iperf3/Fortio 벤치마크 중 측정
A: VPC CNI
CPU: 미측정
Memory: 미측정
B: Cilium+kp
CPU: 4-6m
Memory: 83Mi
C: kp-less
CPU: 4-6m
Memory: 129Mi
D: ENI
CPU: 5-6m
Memory: 81Mi
E: ENI+Tuned
CPU: 4-5m
Memory: 82Mi
시나리오 C(kp-less)의 메모리가 높은 이유는 VXLAN 오버레이 eBPF 맵(터널 엔드포인트, 캡슐화 상태)과 kube-proxy 대체 eBPF 맵(Service endpoint)을 동시에 유지하기 때문입니다. D/E도 kube-proxy를 대체하지만 ENI native 라우팅으로 오버레이 맵이 불필요하여 메모리가 낮습니다.

튜닝 포인트별 영향도​

개별 튜닝 효과 미측정

본 벤치마크는 시나리오 E에서 모든 튜닝을 동시 적용한 누적 효과를 측정했습니다. 각 튜닝 옵션을 개별 적용하여 단독 기여도를 측정하는 작업은 수행하지 않았습니다. 시나리오 E의 전체 성능 개선(RTT 36%, p99 20%)은 8개 튜닝의 복합 결과입니다.

시나리오 E에서 적용된 튜닝:

  • ✅ Socket-level LB, BPF Host Routing, BPF Masquerade, Bandwidth Manager, BBR, Native Routing, CT Table 확장, Hubble 비활성화
  • ❌ XDP Acceleration, DSR (ENA 드라이버 호환성 제약으로 미적용)

ENA 드라이버 XDP 제약사항: m6i.xlarge의 ENA 드라이버는 bpf_link 기능을 지원하지 않아 XDP native 및 best-effort 모드 모두 실패합니다. DSR 모드 또한 Pod 크래시를 유발하여 SNAT 모드로 회귀했습니다. 향후 NIC 드라이버 업데이트 시 재시도가 필요합니다.

핵심 결론: 성능 차이 vs 기능 차이​

이번 벤치마크의 가장 중요한 결론은 VPC CNI와 Cilium CNI 간에 실질적인 성능 차이는 거의 없다는 점입니다.

항목결과해석
TCP Throughput모든 시나리오 동일 (12.4 Gbps)NIC 대역폭에 포화, CNI 무관
HTTP p99 @QPS=10008.75~10.92ms (시나리오별 변동)측정 오차 범위 내
UDP 패킷 손실VPC CNI 20% vs Cilium 튜닝 0.03%Bandwidth Manager 기능 유무 차이 (iperf3 극한 조건)
서비스 스케일링iptables +26µs/연결 @1,000개측정 가능하나 실환경에서 미미
AI/ML 실시간 추론 워크로드에서의 의미

다만, HTTP/gRPC 기반 실시간 추론 서빙 환경에서는 RTT 개선(4,894→3,135µs, 약 36%)과 HTTP p99 지연 감소(10.92→8.75ms, 약 20%)가 누적되어 유의미할 수 있습니다. Agentic AI 워크로드처럼 하나의 요청이 여러 마이크로서비스를 거치는 multi-hop 통신 패턴(예: Gateway → Router → vLLM → RAG → Vector DB)에서는 hop마다 절감된 지연이 누적되므로, 전체 end-to-end 응답 시간에서 체감 가능한 차이가 발생할 수 있습니다. 초저지연이 요구되는 실시간 추론 서빙에서는 이 점을 고려할 필요가 있습니다.

두 CNI를 선택할 때 고려해야 할 진짜 차이점은 기능입니다:

  • L7 네트워크 정책 (HTTP 경로/메서드 기반 필터링)
  • FQDN 기반 Egress 정책 (도메인 이름으로 외부 접근 제어)
  • eBPF 기반 관찰성 (Hubble을 통한 실시간 네트워크 흐름 가시성)
  • Hubble 네트워크 맵 — eBPF 기반으로 커널 수준에서 패킷 메타데이터를 수집하므로 사이드카 프록시 방식 대비 오버헤드가 극히 낮으면서도 서비스 간 통신 흐름, 의존성, 정책 판정(ALLOWED/DENIED)을 실시간 시각화할 수 있습니다. 별도의 서비스 메시 없이도 네트워크 토폴로지 맵을 확보할 수 있다는 점은 운영 가시성 측면에서 큰 장점입니다.
  • kube-proxy-less 아키텍처 (운영 복잡도 감소, 대규모 환경 미래 대비)
  • Bandwidth Manager (극한 UDP 워크로드의 QoS 제어)

성능 최적화가 목적이라면 CNI 선택보다 애플리케이션 튜닝, 인스턴스 타입 선정, 네트워크 토폴로지 최적화가 훨씬 큰 영향을 미칩니다. 다만 multi-hop 추론 파이프라인이나 네트워크 가시성이 중요한 환경에서는 Cilium의 기능적 이점이 성능 개선으로 이어질 수 있습니다.

분석 및 권장사항​

벤치마크 핵심 결과 요약

EKS 1.31 · m6i.xlarge × 3 Nodes · 5개 시나리오 실측 데이터 기반

-36%
RTT 지연 개선
시나리오 E vs A
BW Mgr
UDP 손실 완화
Bandwidth Manager + BBR 적용
101×
iptables 규칙 증가
99 → 10,059 (1000 svc)
O(1)
eBPF 서비스 룩업
vs iptables O(n)

주요 발견사항​

1

TCP Throughput은 NIC 대역폭에 포화

모든 시나리오에서 12.34-12.41 Gbps를 달성했으며, m6i.xlarge의 12.5 Gbps baseline 대역폭에 의해 제한됩니다. TCP throughput은 모든 구성에서 사실상 동일합니다.

2

UDP Loss Rate: 핵심 차별화 요소

핵심 차별화 요소
시나리오UDP Loss원인
A (VPC CNI)20.39%Native ENI, eBPF rate limiting 없음
B (Cilium+kp)0.94%eBPF Bandwidth Manager
C (kp-less)0.69%eBPF Bandwidth Manager
D (ENI)20.42%튜닝 미적용
E (ENI+Tuning)0.03%Bandwidth Manager + BBR
Insight: eBPF Bandwidth Manager는 커널 qdisc 오버헤드 없이 pod 수준의 rate limit을 적용하여 고속 throughput 환경에서 UDP 패킷 드롭을 방지합니다.
3

튜닝을 통한 RTT 개선

36% 개선
A: VPC CNI
4,894µs
→
D: ENI
4,453µs
-9%
→
E: ENI+Tuning
3,135µs
-36%
주요 기여 요소: BPF Host Routing (iptables 우회), Socket LB (직접 연결), BBR congestion control
4

kube-proxy 제거의 효과

B vs C 비교
TCP/UDP Throughput
차이 없음
RTT
+3% 악화
4955→5092µs
HTTP p99@1000
-10% 개선
9.87→8.91ms
DNS p99
-50% 개선
4ms→2ms
Insight: 소규모(~10 services)에서는 kube-proxy 제거 효과가 미미합니다. 1,000개 서비스에서 iptables 규칙이 101배(99→10,059개) 증가하며 연결당 +16% 오버헤드가 발생한 반면, Cilium eBPF는 서비스 수에 무관한 O(1) 룩업 성능을 유지했습니다.
5

ENI 모드 vs Overlay 모드

C vs D
지표C (VXLAN)D (ENI)변화
TCP Throughput12.34 Gbps12.41 Gbps+0.6%
RTT5,092 µs4,453 µs-12.5%
HTTP p99@10008.91 ms8.75 ms-1.8%
UDP Loss0.69%20.42%튜닝 필요
Insight: VXLAN overlay는 캡슐화로 인해 ~640µs RTT 오버헤드를 추가합니다. ENI 모드는 낮은 지연시간을 제공하지만 UDP 튜닝이 필요합니다.
6

튜닝 적용의 누적 효과

D → E 전환
지표D (ENI)E (ENI+Tuning)변화
RTT4,453 µs3,135 µs-30%
UDP Loss20.42%0.03%-99.9%
HTTP QPS@max4,0264,182+3.9%
HTTP p99@10008.75 ms9.89 ms+13%
가장 영향력 있는 튜닝:
  1. Bandwidth Manager + BBR — UDP loss 20% → 0.03%
  2. Socket LB — 직접 연결
  3. BPF Host Routing — iptables 우회
ENI 모드에서는 XDP acceleration 및 DSR 사용 불가
7

1,000개 서비스 스케일링: iptables O(n) vs eBPF O(1)

스케일링
지표4 Services1,000 Services변화
iptables NAT 규칙 수9910,059+101배
Sync 주기 시간~130ms~170ms+31%
연결당 설정 시간 (close)164µs190µs+16%
최대 QPS (keepalive)4,1974,178~0%
Insight: keepalive 연결에서는 conntrack 캐시가 iptables 체인 순회를 우회하여 O(n) 비용이 숨겨집니다. keepalive 없이는 모든 SYN 패킷이 KUBE-SERVICES 체인 전체를 순회합니다. 5,000개 이상 서비스에서는 연결당 수백 µs가 추가되어 실질적 성능 저하가 발생합니다.

워크로드별 권장 구성​

워크로드 특성권장 시나리오근거
소규모, 단순 (<100 Services)A: VPC CNI운영 복잡도 최소
UDP 스트리밍, 비디오E: ENI+Tuning0.03% UDP loss
네트워크 정책 필요C or DL3/L4/L7 policies
고성능, 대규모 (500+ Services)D: Cilium ENIeBPF O(1) vs iptables 연결당 +16% @1000svc
지연 민감 (금융, 실시간)E: ENI+Tuning36% RTT improvement
IP 주소 제약 환경C: kp-lessVXLAN Overlay
멀티테넌트, 관찰성D + HubbleENI + visibility
A: VPC CNI
개발/스테이징
복잡도: 낮음
성능: 기준선
D: Cilium ENI
일반 프로덕션
복잡도: 중간
성능: 높음
E: ENI+Tuning
고성능/지연 민감
복잡도: 높음
성능: 최고
C: kp-less
네트워크 정책/IP 제약
복잡도: 중간
성능: 보통~높음
XDP 지원 확인

XDP Acceleration과 DSR을 활용하려면 인스턴스 타입의 NIC 드라이버가 bpf_link 기능을 지원하는지 확인하세요. m6i.xlarge의 ENA 드라이버는 현재 미지원입니다. 향후 드라이버 업데이트 또는 다른 인스턴스 타입(C6i, C7i 등) 고려 시 재검증이 필요합니다.

구성 시 주의사항​

벤치마크 환경 구성 과정에서 발견된 이슈와 해결 방법을 정리합니다. Cilium을 EKS에 도입하거나 벤치마크를 재현할 때 참고하세요.

eksctl 클러스터 생성​

  • 최소 2개 AZ 필요: eksctl은 availabilityZones에 최소 2개 AZ를 요구합니다. 단일 AZ 노드그룹을 원해도 클러스터 수준에서는 2개 이상의 AZ를 지정해야 합니다.

    # 클러스터 수준: 2개 AZ 필수
    availabilityZones:
      - ap-northeast-2a
      - ap-northeast-2c
    # 노드그룹 수준: 단일 AZ 가능
    managedNodeGroups:
      - availabilityZones: [ap-northeast-2a]

Cilium Helm 차트 호환성​

  • tunnel 옵션 제거됨 (Cilium 1.15+): --set tunnel=vxlan 또는 --set tunnel=disabled는 더 이상 유효하지 않습니다. 대신 routingMode와 tunnelProtocol을 사용하세요.

    # 이전 (Cilium 1.14 이하)
    --set tunnel=vxlan

    # 현재 (Cilium 1.15+)
    --set routingMode=tunnel --set tunnelProtocol=vxlan

    # Native Routing (ENI 모드)
    --set routingMode=native

XDP 가속 사용 조건​

XDP(eXpress Data Path)는 NIC 드라이버 수준에서 패킷을 처리하여 커널 네트워크 스택을 우회합니다. Cilium에서 XDP를 사용하려면 다음 조건을 모두 충족해야 합니다.

요구사항조건비고
Linux 커널>= 5.10bpf_link 지원 >= 5.7
NIC 드라이버XDP Native 지원See compatibility below
Cilium 설정kubeProxyReplacement=truekube-proxy 대체 필수
인터페이스물리 NICbond/VLAN 미지원
드라이버XDP Native최소 커널환경비고
mlx5 (Mellanox ConnectX-4/5/6)✅ 완전 지원>= 4.9Bare Metal최적, 권장
i40e (Intel XL710)✅ 완전 지원>= 4.12Bare Metal안정적
ixgbe (Intel 82599)✅ 완전 지원>= 4.12Bare Metal10GbE
bnxt_en (Broadcom)✅ 지원>= 4.11Bare Metal-
ena (AWS ENA)⚠️ 제한적>= 5.6AWS EC2아래 AWS 참조
virtio-net⚠️ Generic만>= 4.10KVM/QEMUNative 미지원
인스턴스 유형XDP Native이유
Bare Metal (c5.metal, m6i.metal...)✅ 지원하드웨어 직접 접근
Virtualized (m6i.xlarge, c6i...)❌ Unsupportedbpf_link 미구현
ENA Express (c6in, m6in...)❌ UnsupportedSRD 프로토콜, XDP와 무관
Graviton (m7g, c7g...)❌ Unsupported동일 ENA 제약
튜닝 항목효과
Socket-level LBconnect() 시점 직접 연결, per-packet NAT 없음
BPF Host Routing호스트 iptables 완전 우회
BPF Masqueradeiptables MASQUERADE → eBPF
Bandwidth Manager + BBREDT 기반 rate limiting + BBR
Native Routing (ENI)VXLAN 캡슐화 제거
XDP와 DSR 없이 RTT 36% 개선 달성

DSR (Direct Server Return) 호환성​

  • loadBalancer.mode=dsr 설정 시 Cilium Agent Pod 크래시 발생 가능
  • AWS ENA 환경에서는 mode=snat (기본값) 권장
  • DSR은 XDP가 정상 동작하는 환경(Bare Metal + mlx5/i40e 등)에서만 안정적
XDP 지원 여부 확인
# Cilium XDP 활성화 상태 확인
kubectl -n kube-system exec ds/cilium -- cilium-dbg status | grep XDP
# "Disabled" 표시 시 해당 인스턴스에서 XDP 미지원

# NIC 드라이버 확인
ethtool -i eth0 | grep driver

워크로드 배포​

  • Fortio 컨테이너 이미지 제약: fortio/fortio 이미지에는 sleep, sh, nslookup 바이너리가 없습니다. Idle 대기 시 sleep infinity 대신 Fortio 자체 서버 모드를 사용하세요.

    command: ["fortio", "server", "-http-port", "8080"]

  • DNS 테스트용 Pod 선택: DNS 해석 테스트는 sh가 포함된 이미지(예: iperf3)에서 getent hosts를 사용하세요. nslookup은 별도 설치가 필요합니다.

CNI 전환 시 Pod 재시작​

  • Rolling Update 시 CPU 부족: VPC CNI → Cilium 전환 후 워크로드를 재시작할 때, Rolling Update 전략은 Pod 수를 일시적으로 2배로 늘립니다. 소규모 노드에서 CPU 부족이 발생할 수 있습니다.

    # 안전한 재시작 방법: 기존 Pod 삭제 후 재생성
    kubectl delete pods -n bench --all
    kubectl rollout status -n bench deployment --timeout=120s

  • Cilium DaemonSet 재시작: Cilium Helm 값 변경 후 DaemonSet이 자동 재시작되지 않으면 수동으로 트리거하세요.

    kubectl -n kube-system rollout restart daemonset/cilium
    kubectl -n kube-system rollout status daemonset/cilium --timeout=300s

AWS 인증​

  • SSO 토큰 만료: 장시간 벤치마크 실행 중 AWS SSO 토큰이 만료될 수 있습니다. 실행 전 토큰 유효 시간을 확인하거나, aws sso login으로 갱신하세요.

참고: VPC CNI vs Cilium 네트워크 정책 비교​

EKS에서 VPC CNI와 Cilium 모두 네트워크 정책을 지원하지만, 지원 범위와 기능에 큰 차이가 있습니다.

기능VPC CNI (EKS 네트워크 정책)Cilium
Kubernetes NetworkPolicy API✅지원✅지원
L3/L4 Filtering✅지원✅지원
L7 Filtering (HTTP/gRPC/Kafka)❌미지원✅CiliumNetworkPolicy CRD
FQDN-based Policies❌미지원✅toFQDNs rules
Identity-based MatchingIP-based✅Cilium Identity (eBPF, O(1))
Cluster-wide PoliciesNamespace-scoped only✅CiliumClusterwideNetworkPolicy
Host-level PoliciesPod traffic only✅Host traffic control
Policy Enforcement VisibilityCloudWatch Logs (limited)✅Hubble (real-time)
Policy Editor/UI❌미지원✅Cilium Network Policy Editor
Implementation✅eBPF (AWS agent)✅eBPF (Cilium agent)
Performance Impact✅Low✅Low

Highlighted rows indicate features where Cilium provides capabilities not available in VPC CNI.

주요 차이점​

L7 정책 (Cilium 전용): HTTP 요청의 경로, 메서드, 헤더 수준에서 필터링이 가능합니다. 예를 들어 GET /api/public은 허용하고 DELETE /api/admin은 차단하는 정책을 설정할 수 있습니다.

# Cilium L7 정책 예시
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-get-only
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
  - fromEndpoints:
    - matchLabels:
        role: frontend
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/public.*"

FQDN 기반 정책 (Cilium 전용): 외부 도메인에 대한 접근을 DNS 이름으로 제어할 수 있습니다. IP가 변경되어도 정책이 자동으로 업데이트됩니다.

# 특정 AWS 서비스만 허용
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-aws-only
spec:
  endpointSelector:
    matchLabels:
      app: backend
  egress:
  - toFQDNs:
    - matchPattern: "*.amazonaws.com"
    - matchPattern: "*.eks.amazonaws.com"

정책 시행 가시성: Cilium의 Hubble은 모든 네트워크 흐름에 대해 정책 판정(ALLOWED/DENIED)을 실시간으로 표시합니다. VPC CNI는 CloudWatch Logs를 통해 제한적인 로깅만 제공합니다.

선택 가이드
  • 기본 L3/L4 정책만 필요: VPC CNI의 EKS Network Policy로 충분합니다.
  • L7 필터링, FQDN 정책, 실시간 가시성 필요: Cilium이 유일한 선택지입니다.
  • 멀티테넌트 환경: Cilium의 CiliumClusterwideNetworkPolicy와 Host-level 정책이 강력합니다.

참고 자료​