[Linux Network] Netfilter가 eBPF에게 자리를 내어주는 이유: 완벽 비교 분석 🚀

안녕하세요! 오늘은 리눅스 네트워크의 영원한 터줏대감 Netfilter(iptables)와, 클라우드 네이티브 시대의 새로운 슈퍼스타 eBPF를 깊이 있게 비교해 보려고 합니다.

 

Kubernetes 환경을 운영하다 보면 "iptables가 병목이다", "Cilium(eBPF)으로 전환해야 한다"는 이야기를 자주 듣게 되는데요. 도대체 왜 eBPF가 더 좋다고 하는 걸까요? 단순히 '빠르다'는 말로는 부족합니다.

 

오늘은 성능, 구조, 그리고 시간 복잡도(Time Complexity)의 관점에서 그 이유를 파헤쳐 보겠습니다. 🧐

---

1. 성능의 핵심: 처리 위치와 방식의 차이 🏁

가장 먼저 살펴볼 것은 패킷을 처리하는 위치입니다.

🐢 Netfilter (iptables/nftables)

Netfilter는 "도로 위 검문소"와 같습니다.

1. 패킷이 네트워크 카드(NIC)에 도착합니다.
2. 커널이 메모리를 할당(sk_buff)하고, 네트워크 스택(TCP/IP)을 타고 올라옵니다.
3. 한참을 올라온 뒤, 정해진 훅(Hook) 지점에서 규칙을 검사합니다.
4. 차단해야 할 패킷이라도 이미 메모리 할당과 컨텍스트 스위칭 비용을 지불한 뒤입니다.

⚡ eBPF (XDP/TC)

eBPF, 특히 XDP(eXpress Data Path)는 "고속도로 진입 전 차단"과 같습니다.

1. 패킷이 NIC 드라이버에 도착하자마자(가장 하단) 검사합니다.
2. OS가 메모리를 할당하기도 전에 불필요한 패킷을 버릴 수 있습니다(Early Drop).
3. JIT(Just-In-Time) 컴파일러를 통해 네이티브 기계어 코드로 실행되므로 처리 속도가 압도적입니다.

한 줄 요약: eBPF는 불필요한 커널 오버헤드를 건너뛰고 가장 빠른 경로로 패킷을 처리합니다.

---

2. 시간 복잡도: O(N) vs O(1)의 싸움 ⏱️

이 부분이 오늘 포스팅의 하이라이트입니다. 서비스(규칙) 개수가 늘어날 때 성능이 어떻게 변하는지 알고리즘 관점에서 보겠습니다.

📉 Netfilter: O(N) - "순차적 리스트 검사"

iptables는 규칙을 Linked List(연결 리스트) 형태로 관리합니다.

• 방식: 패킷 하나가 들어오면 1번 규칙부터 N번 규칙까지 하나씩 순서대로 대조합니다.
• 문제점: 규칙이 100개일 땐 빠르지만, Kubernetes 서비스가 늘어나 규칙이 10,000개가 되면? 패킷 하나당 10,000번의 비교 연산을 해야 합니다.
• 결과: 규칙 수에 비례하여 성능이 선형적으로 저하됩니다.

📈 eBPF: O(1) - "즉시 검색 (Hash Map & Trie)"

eBPF는 효율적인 자료구조(Map)를 사용합니다.

• Hash Map (정확한 매칭): Service IP를 Pod IP로 바꿀 때 사용합니다.
  • 키(IP)를 넣으면 값(타겟)이 바로 튀어나옵니다.
  • 규칙이 10개든 1억 개든 찾는 속도는 $O(1)$(상수 시간)로 동일합니다.
• LPM Trie (네트워크 대역 매칭): CIDR(192.168.0.0/16) 매칭에 사용합니다.
  • $O(\log n)$이 아닙니다! IP 주소의 길이(비트 수, IPv4=32)만큼만 깊이를 가집니다.
  • 규칙 개수(N)와 무관하게 탐색 깊이가 고정되므로, 이 또한 실질적인 $O(1)$ 성능을 보장합니다.

비유
- Netfilter: 공항 직원이 금지 물품 리스트 수천 장을 한 장씩 넘겨가며 확인하는 것
- eBPF: 바코드 리더기로 찍자마자 통과/차단 결과가 나오는 것

---

3. 유연성과 관측 가능성 (Observability) 🔍

🛠️ 유연성 (Programmability)

• Netfilter: 정해진 설정(Configuration)만 가능합니다. 복잡한 로직을 넣으려면 커널을 재빌드해야 할 수도 있습니다.
• eBPF: C나 Rust로 코드를 짜서(Programming) 커널에 올립니다. 실행 중에 로직을 바꿀 수도 있고, 특정 프로토콜 헤더만 파싱하는 등 원하는 대로 커널을 프로그래밍할 수 있습니다.

🔭 관측 가능성 (Glass Box)

• Netfilter: 패킷이 허용됐는지, 차단됐는지 정도의 로그만 봅니다. (Black Box)
• eBPF: 커널 내부의 함수 호출, 디스크 I/O, 메모리 사용량, 심지어 암호화된 통신 전 단계의 데이터까지 들여다볼 수 있습니다. 이는 마이크로서비스의 복잡한 트러블슈팅에 혁명적입니다. (X-Ray)

---

4. 안전성: 커널 패닉은 이제 그만 🛡️

"커널 내부에서 코드를 돌린다고? 위험하지 않나?"라고 생각하실 수 있습니다. 하지만 eBPF에는 Verifier(검증기)라는 강력한 안전장치가 있습니다.

• 코드가 커널에 로드되기 전에 무한 루프는 없는지, 메모리 접근은 안전한지 미리 검사합니다.
• 조금이라도 위험해 보이면 실행 자체를 거부합니다.
• 따라서 기존 커널 모듈(Kernel Module) 방식이 가졌던 '잘못 짜면 커널 패닉(BSOD)' 문제를 원천 봉쇄합니다.

---

요약 및 결론 📝

특징	Netfilter (iptables)	eBPF (Cilium 등)
시간 복잡도	$O(N)$ (규칙 많으면 느려짐)	$O(1)$ (규칙 많아도 빠름)
자료 구조	Linked List	Hash Table, Array, Trie
처리 위치	네트워크 스택 중간 (무거움)	드라이버 레벨 (가벼움)
주요 용도	전통적인 방화벽	대규모 클라우드 네트워킹, 가시성 확보

 

결론적으로,

서비스 규모가 작고 변경이 적다면 Netfilter도 훌륭합니다. 하지만 Kubernetes와 같이 IP가 수시로 바뀌고 서비스가 수천 개로 늘어나는 동적인 환경에서는 $O(1)$의 성능과 깊은 관측성을 가진 eBPF가 선택이 아닌 필수가 되어가고 있습니다.

더 이상 iptables의 긴 규칙 리스트 때문에 고통받지 마세요. 이제 eBPF의 세계로 넘어갈 때입니다! 🌊

---