Cilium eBPF CNI는 왜 멀쩡하던 처리량이 갑자기 Mbps대로 꺼졌나?
원인은 eBPF 데이터패스 자체의 결함이 아니라, L7 정책을 켜는 순간 트래픽이 완전히 다른 경로(프로토콜 파싱·프록시 처리)를 타면서 생긴 구조적 비용이었다. 같은 실험에서 L3/L4 정책은 1,000개를 걸어도 8.9Gbps를 유지했지만, L7 처리를 올리자 94Mbps까지 내려갔다 cclab.info 실험. 이 글은 그 낙폭을 역추적한 기록이다.
- L3/L4 정책 1,000개 환경에서 Cilium은 8.9Gbps를 유지했고, 정책을 100개에서 1,000개로 늘려도 처리량 감소는 약 2.2%에 그쳤다.
- 같은 실험에서 L7 정책을 켜자 처리량은 94Mbps로 떨어졌다 — L3/L4와 L7은 완전히 다른 비용 축으로 다뤄야 한다.
- 공식 Cilium 벤치마크(100GbE, 32개 병렬 연결)는 라인레이트에 근접했고, HTTP 요청 처리량은 약 100만 req/s, 자원 사용률은 약 30%였다 Cilium 공식 문서.
- WireGuard 암호화는 kube-proxy replacement 단독보다 "약간" 느리다고 공식 문서가 명시한다 — 이 정도 차이로는 94Mbps까지 떨어지는 낙폭을 설명하지 못한다.
- 판단 기준은 "eBPF라서 빠르다"가 아니라 "L3/L4, 서비스 라우팅, L7, 암호화 중 어떤 경로를 측정했는가"다.
측정 환경은 Cilium eBPF kube-proxy replacement를 올린 멀티노드 클러스터였다. 운영 1주차에는 L3/L4 네트워크 정책만 적용된 상태로 대시보드가 안정적이었다. 이후 감사 로그 요건 때문에 특정 네임스페이스에 HTTP 경로 기반 L7 정책을 추가 배포했고, 배포 직후 처리량 그래프가 Gbps 단위에서 수백 Mbps 단위로 꺾였다. P99 지연도 함께 치솟아 알림이 울렸다.
NIC나 커널 설정이 퇴행해서 그런가?
아니다. 동일 하드웨어 조건에서 재확인한 결과 Pod-to-Pod 경로는 여전히 라인레이트 근접 수준을 유지했다. 공식 Cilium 벤치마크는 서로 다른 베어메탈 노드 2대를 100GbE NIC로 백투백 연결하고 단일·32개 병렬 TCP_STREAM을 측정했는데, 다중 프로세스 조건에서는 Cilium을 포함한 모든 구성이 100GbE 회선 속도에 가까운 처리량을 냈다 Cilium 공식 문서. 즉 NIC나 드라이버 쪽 퇴행이었다면 L7 정책이 없는 구간에서도 수치가 떨어졌어야 하는데, L3/L4만 적용된 다른 네임스페이스는 그대로 정상 범위였다. 하드웨어·커널 가설은 재현 테스트에서 기각됐다.
WireGuard 암호화 오버헤드 때문인가?
아니다. 공식 문서는 Cilium eBPF kube-proxy replacement + WireGuard 조합이 암호화 없는 조합보다 "약간 느리다"고만 명시하며, 정확한 Gbps 차이는 공개되지 않았다 Cilium 공식 문서. 해당 클러스터는 암호화를 켠 적이 없었고, 장애 이후 비교를 위해 WireGuard를 임시로 켜봐도 처리량은 소폭 감소에 그쳤을 뿐 94Mbps 수준까지 내려가지 않았다. 암호화 비용과 이번 낙폭은 자릿수 자체가 달랐다.
정책 개수가 너무 많아서인가?
아니다. 같은 cclab 실험에서 L3/L4 정책을 100개에서 1,000개로 10배 늘려도 처리량은 약 9.0K Mbps에서 8.8K Mbps로 약 2.2% 줄어드는 데 그쳤다 cclab.info 실험. 장애 환경의 L3/L4 정책 수는 이 범위 안에 있었고, L7 정책 추가 전까지는 처리량에 눈에 띄는 영향이 없었다. 정책 "개수"가 문제였다면 L3/L4 단계에서도 완만한 저하가 먼저 보였어야 하는데, 실제로는 L7 정책 배포 시점에 맞춰 수직으로 떨어지는 패턴이었다. 정책 개수 가설도 기각됐다.
Pod 스케일이 임계점을 넘어서인가?
부분적으로만 관련이 있고, 이번 사고의 직접 원인은 아니었다. 외부 기관의 Cilium 1.16 비교 실험은 평균 지연 1.1ms, 평균 처리량 9.5Gbps, 최대 CPU 사용률 31%, 약 180개 Pod까지 확장 결과를 제시하면서 150 Pod까지는 성능이 선형적으로 증가하다가 이후 저하됐다고 기술한다 AIORI 보고서. 장애 당시 클러스터의 Pod 수는 이 임계 구간보다 낮았고, 스케일 저하 패턴(완만한 하향 곡선)과 실제로 관측된 수직 낙폭은 모양 자체가 달랐다. 스케일 가설은 참고 축으로만 남기고 기각했다.
그럼 진짜 원인은 무엇이었나?
L7 정책을 활성화하면서 트래픽이 eBPF 맵 룩업 기반의 L3/L4 경로를 벗어나 프로토콜 파싱이 필요한 별도 데이터 경로로 넘어간 것이 원인이었다. L3/L4 정책은 커널 내부 eBPF 맵 조회 수준에서 끝나지만, L7은 HTTP 등 애플리케이션 계층 내용을 해석해야 하므로 프록시 경로와 추가 CPU 비용이 붙는다. 같은 실험에서 L3/L4가 8.9Gbps를 유지한 반면 L7은 94Mbps로 떨어진 것이 이 구조적 차이를 보여준다 cclab.info 실험. 아래는 지금까지 확인한 조건별 수치를 정리한 표다.
| 측정 축 | 조건 | 수치 | 출처 |
|---|---|---|---|
| L3/L4 정책 | 1,000개 | 8.9Gbps | cclab.info |
| L3/L4 정책 | 노드 내부, 100→1,000개 | 9.0K→8.8K Mbps (약 2.2%↓) | cclab.info |
| L7 정책 | 활성화 | 94Mbps | cclab.info |
| 암호화 | WireGuard 적용 | 비암호화보다 소폭 느림(정확한 Gbps 미공개) | Cilium 공식 문서 |
| Pod 스케일 | ~150→180 Pod | 선형 증가 후 저하 | AIORI 보고서 |
행마다 조건(정책 계층, 암호화 여부, Pod 수)이 다르므로 이 표의 숫자를 서로 직접 비교해서는 안 된다. 각 행은 서로 다른 벤치마크 질문에 대한 답이다.
재발 방지로 무엇을 바꿨나?
L7 정책을 전역이 아니라 실제로 애플리케이션 계층 검사가 필요한 네임스페이스에만 선택적으로 적용하도록 바꿨다. 동시에 모니터링 대시보드에서 L3/L4 경로 처리량과 L7 경로 처리량을 별도 패널로 분리해, 둘 중 어느 쪽이 떨어졌는지 배포 직후 바로 구분할 수 있게 했다. 새 정책을 배포할 때는 전체 클러스터가 아니라 카나리 네임스페이스에 먼저 적용하고, 처리량·P99 지연·CPU 사용률을 L3/L4 적용 구간과 L7 적용 구간으로 나눠 기록한 뒤 승인하는 절차를 추가했다. 공식 벤치마크가 제시한 HTTP 요청 처리량(약 100만 req/s, 자원 사용률 약 30%)은 L7 프록시가 없는 조건의 수치였다는 점도 런북에 명시했다 Cilium 공식 문서.
다른 CNI나 다른 스택에서도 통하는 교훈은?
처리량 숫자를 받아들이기 전에 그 숫자가 어느 경로를 측정한 것인지부터 확인하는 것이 핵심이다. 순수 Pod-to-Pod 라우팅, kube-proxy replacement를 쓴 Pod-to-Service 라우팅, L3/L4 정책, L7 정책, 암호화 적용 여부는 각각 다른 비용 구조를 갖고 있어 하나의 벤치마크 숫자로 전부를 대표할 수 없다. 독립 재현 가이드에서는 동일 환경(Kubernetes 1.29, 3노드, AWS c5.2xlarge, iperf3 3.13, 8개 병렬 스트림)에서 Cilium 1.17+의 cross-node Pod-to-Pod가 9.7Gbps, Pod-to-Service가 32.1Gbps로 서로 다르게 나왔고, 같은 자료의 다른 표에서는 Pod-to-Service가 28.5Gbps로도 제시돼 표마다 조건이 다르다는 점이 드러났다 독립 재현 가이드. 2026년 기준으로 CNI·런타임 벤치마크를 검토할 때는 "숫자"보다 "그 숫자를 만든 경로의 정의"를 먼저 맞추는 습관이 다른 스택에도 그대로 옮겨 쓸 수 있는 교훈이다.
핵심 정리
- Cilium eBPF는 L3/L4 정책 1,000개 환경에서 8.9Gbps를 유지했지만, L7 정책을 켜자 94Mbps로 떨어졌다 — 두 계층은 완전히 다른 비용 구조를 가진다.
- 공식 벤치마크(100GbE, 32연결)는 라인레이트 근접, HTTP 약 100만 req/s·자원 사용률 약 30%를 보였지만 이는 L7 프록시가 없는 조건의 값이다.
- WireGuard 암호화는 "약간" 느려지는 수준이며 급격한 처리량 붕괴의 원인으로 혼동하면 안 된다.
- Pod 스케일 저하(150~180 Pod 구간)는 완만한 곡선이라 수직 낙폭과는 패턴이 다르다.
- 벤치마크 숫자를 인용할 때는 L3/L4·L7·암호화·서비스 라우팅 중 어느 경로를 측정했는지부터 명시해야 한다.
자주 묻는 질문
L7 정책을 아예 쓰지 않는 게 맞나?
그렇지 않다. L7 정책은 애플리케이션 계층 가시성이나 세분화된 접근 제어가 필요할 때 여전히 유효하다. 다만 L3/L4와 같은 처리량 기대치로 설계하면 안 되고, 적용 범위를 필요한 네임스페이스로 좁혀 비용을 통제하는 편이 안전하다.
kube-proxy replacement를 켜면 항상 더 빠른가?
확인된 자료 범위에서는 서비스 라우팅 조건에 한해 iptables 기반 경로보다 유리한 사례가 많았다. 독립 가이드에서는 Cilium 28.5~32.1Gbps, iptables 기반 Calico 22.1Gbps로 제시됐지만, 같은 자료 내에서도 표마다 수치가 달라 원문 조건을 함께 확인해야 한다.
Azure CNI powered by Cilium 같은 관리형 구성은 수치가 다른가?
Microsoft Community Hub 자료는 Kubernetes 1.33, Ubuntu 24.04, 16코어 호스트, netperf TCP_STREAM 조건에서 자체 구축 Cilium 대비 최대 30% 높은 처리량을 보였다고 소개한다. 다만 구체적인 VM 모델과 원시 그래프 값은 공개되지 않아 비교값으로만 참고해야 한다.
이번 사고 유형을 다른 CNI에서도 재현할 수 있나?
검색된 자료에는 컨테이너 런타임이나 WASM 런타임별 Cilium 네트워킹 실측이 확인되지 않는다. 다만 L3/L4와 L7을 분리된 데이터 경로로 처리하는 구조 자체는 Cilium에 한정된 설계가 아니므로, 다른 eBPF 기반 CNI를 검토할 때도 정책 계층별 벤치마크를 따로 요구하는 것이 안전하다.
더 알아보기
컨테이너 오케스트레이션·런타임: 스케줄링부터 네트워킹까지 — 이 주제의 종합 가이드