eBPF 활용 사례

원문 보기 위키 갱신 2026.10.11

eBPF 데이터 플레인이 어떤 워크로드에 어울리고, 어떤 경우에는 표준 iptables 데이터 플레인이 더 나은 선택인지 알아봐요. 트래픽 제어, 네트워크 정책 생성, connect-time 로드 밸런싱 같은 대표 활용 사례와 성능 대 비용의 트레이드오프까지 함께 다뤄요. "무조건 eBPF"가 정답은 아니라는 점을 이해하는 데 도움이 될 거예요.

출처: 문서

본문

큰 그림

eBPF를 언제 사용하면 좋은지(그리고 언제 쓰지 말아야 하는지) 알아봐요.

eBPF란 무엇인가요?

eBPF는 Linux 커널에서 사용할 수 있는 기능으로, 커널 안에 가상 머신을 띄울 수 있게 해 줘요. 이 가상 머신 덕분에 커널의 동작을 커스터마이징하는 프로그램을 안전하게 커널에 로드할 수 있어요. 왜 중요할까요?

과거에는 커널을 바꾸는 일이 어려웠어요. 데이터를 얻기 위해 호출할 수 있는 API는 있었지만, 커널 내부에 영향을 주거나 코드를 실행할 수는 없었거든요. 대신 Linux 커뮤니티에 패치를 제출하고 승인되기를 기다려야 했어요. eBPF를 사용하면 프로그램을 커널에 로드하고, 예를 들어 특정 패킷이 보이거나 다른 이벤트가 발생할 때 커널이 여러분의 프로그램을 실행하도록 지시할 수 있어요.

eBPF를 사용하면 커널과 그 동작이 고정된 것이 아니라 높은 수준으로 커스터마이징 가능해져요. 적절한 상황에서 사용하면 극도로 유용할 수 있어요.

Calico와 eBPF

Calico는 표준 Linux 데이터 플레인(iptables 기반)의 대안으로 eBPF 데이터 플레인을 제공해요. 표준 데이터 플레인이 kube-proxy와 여러분의 iptables 규칙과 협력하는 호환성에 초점을 맞추는 반면, eBPF 데이터 플레인은 성능, 지연 시간, 그리고 표준 데이터 플레인으로는 불가능한 기능으로 사용자 경험을 개선하는 데 초점을 맞춰요.

하지만 Calico는 표준 Linux와 eBPF만 지원하는 게 아니에요. Windows HNS를 포함해 현재 총 세 가지 데이터 플레인을 지원하고, 가까운 미래에 더 많은 데이터 플레인을 추가할 계획도 있어요. Calico는 사용자인 여러분이 하려는 일에 가장 잘 맞는 방식을 직접 선택할 수 있게 해 줘요.

Calico에서 eBPF를 활성화했더라도 기존에 있던 iptables 플로우는 건드리지 않아요. connect-time 로드 밸런싱은 사용하면서 iptables는 그대로 두고 싶을 수도 있으니까요. Calico에서는 전부 아니면 전무(all-or-nothing)가 아니에요. 필요에 맞춰 eBPF 데이터 플레인을 쉽게 올렸다 내렸다 할 수 있어서, 결정하기 전에 빠르게 체험해 볼 수 있어요. Calico는 eBPF를 Kubernetes 클러스터 보안을 쌓는 추가 제어 수단으로 필요할 때 활용할 수 있게 해 줘요.

활용 사례

eBPF의 활용 사례는 여러 가지가 있어요. 트래픽 제어, 네트워크 정책 생성, connect-time 로드 밸런싱 등이 대표적이에요.

트래픽 제어

eBPF가 없으면 패킷은 최종 목적지에 이르기까지 표준 Linux 네트워킹 경로를 따라가요. 패킷이 A 지점에 나타났고 그 패킷이 B 지점으로 가야 한다는 것을 알고 있다면, 패킷을 B 지점으로 바로 보내 Linux 커널의 네트워크 경로를 최적화할 수 있어요. eBPF를 사용하면 커널에서 이런 변경을 수행할 추가 컨텍스트를 활용할 수 있어서, 패킷이 복잡한 라우팅을 우회하고 곧바로 최종 목적지에 도착하게 만들 수 있어요.

Kubernetes 컨테이너 환경에서는 네트워크가 무수히 많아서 특히 의미가 커져요. (호스트 네트워크 스택 외에 각 컨테이너는 자체 미니 네트워크 스택을 가져요.) 트래픽이 들어오면 보통 컨테이너 스택으로 라우팅되고, 호스트 스택에서 컨테이너 스택에 이르는 복잡한 경로를 거쳐야 해요. 이 라우팅은 eBPF로 우회할 수 있어요.

네트워크 정책 생성

네트워크 정책을 만들 때 eBPF를 사용할 수 있는 경우는 두 가지예요.

eXpress Data Path (XDP) – 원시 패킷 버퍼가 시스템에 들어오는 시점에 eBPF가 그 버퍼를 효율적으로 검사하고 어떻게 처리할지 빠르게 결정하게 해 줘요.
네트워크 정책 – eBPF를 사용하면 파드와 호스트 양쪽에 대해 패킷을 효율적으로 검사하고 네트워크 정책을 적용할 수 있어요.

Connect-time 로드 밸런싱

Kubernetes에서 서비스 연결을 로드 밸런싱하면 포트가 서비스와 통신해야 하므로 네트워크 주소 변환(NAT)이 발생해야 해요. 패킷은 가상 IP로 보내지고, 그 가상 IP가 서비스를 지원하는 파드의 목적지 IP로 변환해요. 그러면 파드가 가상 IP로 응답하고, 반환 패킷은 다시 출발지로 변환돼요.

eBPF를 사용하면 커널에 로드한 eBPF 프로그램으로 연결의 출발지에서 로드 밸런싱해 이런 패킷 변환을 피할 수 있어요. 패킷 처리 경로에서 목적지 네트워크 주소 변환(DNAT)이 일어날 필요가 없어지기 때문에, 서비스 연결의 NAT 오버헤드가 모두 사라져요.

성능의 값

그럼 eBPF가 표준 Linux iptables보다 효율적일까요? 짧게 답하면: 상황에 따라 달라요.

많은 수의 IP 주소(즉, ipset)로 네트워크 정책을 적용할 때 iptables가 어떻게 동작하는지 마이크로 벤치마크를 해 보면, 많은 경우 iptables가 eBPF보다 나아요. 하지만 커널에서 패킷 흐름을 바꿔야 하는 무언가를 하고 싶다면 eBPF가 더 나은 선택이에요. 표준 Linux iptables는 복잡한 시스템이고 분명 한계도 있지만, 동시에 트래픽을 조작할 수 있는 옵션도 제공해요. iptables 규칙을 다루는 법을 안다면 많은 것을 해낼 수 있죠. eBPF는 여러분이 직접 프로그램을 커널에 로드해 필요에 맞게 커스터마이징할 수 있는 동작에 영향을 줄 수 있어서, 하나의 규칙 세트에 갇혀 있지 않은 iptables보다 유연해요.

또 하나 생각할 점은, eBPF로 프로그램을 실행하고 로직을 추가하고 플로우를 리다이렉트하고 처리를 우회하는 것은 분명한 이득이지만, eBPF는 가상 머신이라서 바이트코드로 번역되어야 한다는 점이에요. 비교하자면 Linux 커널의 iptables는 이미 코드로 컴파일되어 있고요.

보시다시피 eBPF와 iptables를 비교하는 것은 단순한 동종 비교가 아니에요. 평가해야 할 것은 성능이고, 여기서 볼 두 핵심 요소는 지연 시간(속도)과 비용이에요. eBPF가 매우 빠르지만 자원의 80%를 쓴다면 그건 람보르기니 같은 거예요. 비싸고 빠른 자동차죠. 그게 여러분에게 맞다면 좋고요 (어쩌면 정말로 비싸고 빠른 차를 좋아할지도 모르죠). 다만 CPU 사용량이 늘면 클라우드 공급자에게 지불하는 비용도 늘어난다는 점을 기억하세요. 람보르기니가 다른 많은 차보다 빠르더라도, 매일 출퇴근길에서 속도 제한을 지켜야 한다면 돈을 가장 잘 쓰는 방법이 아닐 수 있어요.

eBPF를 언제 사용할까 (그리고 언제 쓰지 말까)

eBPF를 사용하면 성능을 얻지만 그만큼 값도 치러야 해요. 성능의 값을 계산해 보고, eBPF 관점에서 그 비용이 받아들일 만한지 판단하며 둘 사이의 균형을 찾아야 해요.

eBPF를 사용하는 것이 합리적인 경우와 그렇지 않은 경우를 몇 가지 살펴봐요.

eBPF를 쓰지 말아야 할 때

✘ 패킷 단위 처리

eBPF를 CPU를 많이 쓰는 작업이나 패킷 단위 처리, 예컨대 암호화된 플로우의 복호화와 재암호화에 사용하는 것은 효율적이지 않아요. 모든 패킷마다 구조체를 만들고 조회를 수행해야 해서 비용이 크거든요.

eBPF를 써야 할 때

✔ XDP

eBPF는 원시 패킷 버퍼가 시스템에 들어오는 시점에 효율적으로 검사해 빠르게 처리 방침을 결정할 수 있는 방법을 제공해요.

✔ Connect-time 로드 밸런싱

eBPF를 사용하면 가상 IP 대신 커널에 로드한 프로그램으로 출발지에서 로드 밸런싱할 수 있어요. 패킷 처리 경로에서 DNAT가 일어날 필요가 없으므로, 서비스 연결의 NAT 오버헤드가 모두 사라져요.

✔ 서비스 메시 컨트롤 플레인 구축

서비스 메시는 Envoy 같은 프록시에 의존해요. 이 프로세스 설계에는 수년간 많은 고민이 담겨 있어요. 이렇게 하는 주된 이유는 클러스터 내부에서 보이는 고속 환경에서 HTTP 같은 애플리케이션 프로토콜을 인라인으로 처리하는 것이 많은 경우 현실적이지 않기 때문이에요. 따라서 프록시 자체를 eBPF로 대체하는 게 아니라, Envoy 같은 프록시로 트래픽을 효율적으로 라우팅하는 용도로 eBPF를 사용하는 것을 고민해 보세요. 다만 사이드카가 서비스 주소를 볼 수 있도록 connect-time 로드 밸런싱(CTLB)은 꺼야 해요. 사이드카로 가는 추가 홉 때문에 이미 성능 저하를 감수하고 있으니, NAT 오버헤드를 피하기 위한 CTLB 성능 최적화를 쓰지 않는 것은 큰 문제가 아닐 가능성이 높아요.

요약

eBPF는 iptables의 대체재일까요? 정확히 그렇지는 않아요. 모든 것이 eBPF에서 iptables만큼 효율적으로 동작한다고 상상하기는 어려워요. 당분간은 둘이 공존하며, 사용자가 가격-성능 트레이드오프를 저울질하고 자신의 요구에 맞춰 언제 어떤 기능을 쓸지 결정하는 몫이에요.

우리는 eBPF와 Linux 커널의 기존 메커니즘을 함께 활용해 원하는 결과를 얻는 것이 올바른 해법이라고 생각해요. 그래서 Calico는 표준 Linux, Windows HNS, Linux eBPF를 포함한 여러 데이터 플레인을 지원해요. eBPF와 iptables 둘 다 유용하다는 것이 확인된 이상, 우리 생각에 유일하게 논리적인 일은 둘 다 지원하는 것이에요. Calico가 선택권을 주기 때문에 여러분은 일에 가장 맞는 도구를 고를 수 있어요.

추가 리소스

더 알아보고 테스트 환경에서 측정한 성능 지표를 보려면 eBPF 데이터 플레인 소개 블로그 글을 참고하세요.

더 알아보기 (Learn more)

eBPF는 만능이 아니고 iptables도 낡은 것이 아니에요. 둘의 트레이드오프를 이해하고 워크로드 성격에 맞게 선택하는 것이 핵심이에요. Calico는 여러 데이터 플레인을 지원하므로 필요에 따라 자유롭게 갈아탈 수 있어요.