Post

🔥 "아직도 iptables 늪에서 허우적대나요?" 10년 차 엔지니어가 eBPF(Cilium)로 갈아탄 진짜 이유

Posted
🔥 "Still Drowning in iptables?" Why a 10-Year Engineer Switched to eBPF (Cilium)
🔥 "Still Drowning in iptables?" Why a 10-Year Engineer Switched to eBPF (Cilium)
By
15 min read
🔥 "아직도 iptables 늪에서 허우적대나요?" 10년 차 엔지니어가 eBPF(Cilium)로 갈아탄 진짜 이유

🔗 Reference Links

🔥 The Hook & TL;DR: 트래픽이 터졌는데 CPU가 네트워크 룰을 읽다 죽어버린다고요?

몇 년 전 대규모 트래픽이 몰리던 블랙 프라이데이 이벤트 때의 일입니다. 노드 100개짜리 쿠버네티스 클러스터에서 트래픽 스파이크를 맞고 파드(Pod)를 미친 듯이 스케일아웃 했죠. 그런데 갑자기 네트워크 레이턴시가 500ms를 뚫고 올라가는 겁니다. APM 도구에는 아무런 병목이 안 잡히는데 고객들은 타임아웃을 겪고 있었어요. SSH로 노드에 붙어 iptables-save | wc -l을 입력하는 순간 등골이 서늘해졌습니다. 무려 5만 줄이 넘는 네트워크 룰이 쏟아져 나왔거든요.

이게 무슨 뜻이냐고요? 패킷 하나가 노드에 들어올 때마다 리눅스 커널이 이 기나긴 체인을 순차적으로(O(N)) 뒤지며 이 패킷을 어디로 보낼지 계산하고 있었다는 뜻입니다. CPU가 비즈니스 로직을 처리하기도 전에 패킷 길잡이 노릇을 하느라 녹아내리고 있었던 거죠. 이 끔찍한 레거시의 굴레에서 벗어나기 위해 저는 미련 없이 eBPF와 Cilium으로 갈아탔습니다.

💡 한 마디로 요약하면? eBPF는 리눅스 커널을 안전하게 프로그래밍할 수 있는 ‘슈퍼파워 치트키’이며, Cilium은 그 치트키를 쿠버네티스 네트워킹에 꽂아 넣어 O(N)의 지옥을 O(1)의 마법으로 바꿔버리는 가장 완벽한 컨트롤러입니다.

🛠️ Deep Dive (Under the Hood): iptables의 한계와 eBPF의 우아한 구원

1. 왜 iptables는 현대 클라우드 네이티브에 안 맞을까요?

쿠버네티스의 기본 네트워크 프록시인 kube-proxy는 설계될 당시만 해도 가장 범용적이고 안정적인 iptables를 채택했습니다. 문제는 iptables가 원래 방화벽 용도이지, 수천 개의 마이크로서비스가 동적으로 생기고 죽는 로드밸런싱 환경을 위해 만들어진 게 아니라는 점입니다. 서비스가 늘어날수록 룰은 선형적으로 증가하고, 패킷 평가 성능은 기하급수적으로 떨어집니다.

IPVS 모드를 쓰면 O(1) 해시 테이블 기반이라 성능이 개선되지만, 여전히 패킷이 리눅스의 무거운 TCP/IP 네트워크 스택을 온전히 통과해야 한다는 근본적인 한계는 극복하지 못합니다.

2. eBPF와 XDP: 커널에 직접 주사하는 바이트코드

eBPF(Extended Berkeley Packet Filter)는 커널 코드를 수정하거나 재부팅하지 않고도, 샌드박스 처리된 커널 공간 내에서 사용자 정의 프로그램을 실행할 수 있게 해주는 혁명적인 기술입니다. 특히 XDP (eXpress Data Path) 훅을 사용하면, 네트워크 카드(NIC)에 패킷이 도착하자마자 (커널이 메모리 구조체인 sk_buff를 할당하기도 전에) 패킷을 조작하거나 드롭시켜 버릴 수 있습니다.

아래 비교 표를 보시면 왜 현업에서 eBPF에 열광하는지 직관적으로 다가오실 겁니다.

비교 항목kube-proxy (iptables)kube-proxy (IPVS)Cilium (eBPF 기반)
라우팅 복잡도O(N) (룰 개수에 비례)O(1) (해시 테이블)O(1) (eBPF Map 활용)
패킷 조작 시점TCP/IP 스택 통과 후TCP/IP 스택 통과 후NIC 도착 직후 (XDP)
로컬 파드 간 통신네트워크 스택 전체 왕복네트워크 스택 전체 왕복SockOps로 커널 우회 (직접 복사)
L7 관측성 (가시성)불가능불가능eBPF 훅을 통한 HTTP/gRPC 심층 분석

3. 코드로 보는 eBPF의 동작 원리

추상적인 이야기는 이쯤하고, 실제 코드를 뜯어봅시다. 아주 극단적으로 단순화한 XDP 기반의 eBPF C 코드입니다. 패킷이 들어올 때 불필요한 패킷을 어떻게 NIC 레벨에서 바로 버리는지 보여줍니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <bpf/bpf_helpers.h>

SEC("xdp")
int xdp_fast_drop(struct xdp_md *ctx) {
    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;

    // 이더넷 헤더 파싱
    struct ethhdr *eth = data;
    if (data + sizeof(*eth) > data_end)
        return XDP_PASS;

    // IPv4 패킷만 검사
    if (eth->h_proto != __constant_htons(ETH_P_IP))
        return XDP_PASS;

    struct iphdr *iph = data + sizeof(*eth);
    if (data + sizeof(*eth) + sizeof(*iph) > data_end)
        return XDP_PASS;

    // 악성 IP(예: 192.168.1.100) 하드코딩 매칭 시 즉시 DROP
    // 실제 환경에서는 O(1) 조회가 가능한 bpf_map(Hash)을 사용합니다.
    if (iph->saddr == __constant_htonl(0xC0A80164)) {
        // sk_buff 할당? TCP/IP 스택 통과? 그런 거 없습니다. 여기서 바로 폐기됩니다.
        return XDP_DROP; 
    }

    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

위 코드가 커널에 로드되면, 악성 IP에서 오는 패킷은 CPU의 네트워크 스택을 1바이트도 건드리지 못하고 네트워크 카드 드라이버 레벨에서 소멸합니다. Cilium은 이러한 C 코드를 동적으로 컴파일하고 eBPF Map을 구성하여 쿠버네티스의 모든 네트워크, 로드밸런싱, 보안 정책을 처리하는 겁니다. 성능이 압도적일 수밖에 없죠.

🎯 Pragmatic Use Cases: 뻔한 예시 말고, 현업 트러블슈팅 시나리오

시나리오 1: 사이드카(Sidecar) 없는 서비스 메시 구현

보통 Istio나 Linkerd를 쓰면 파드마다 Envoy 프록시가 사이드카 형태로 붙습니다. A 파드가 B 파드로 통신할 때 A -> Envoy(A) -> 네트워크 스택 -> Envoy(B) -> B 라는 미친 홉(Hop)이 발생하죠. 트래픽이 많으면 이 사이드카의 CPU/Memory 오버헤드만으로도 인프라 비용이 수천만 원 단위로 깨집니다.

Cilium은 eBPF의 SockOps 기능을 이용해 소켓 레벨에서 트래픽을 가로챕니다. 만약 A와 B가 같은 노드에 있다면? TCP/IP 스택을 탈 필요도 없이 커널 메모리 내에서 소켓과 소켓을 직접 연결해 버립니다 (Socket Bypass). 실제로 저희 팀은 이 구조를 도입하고 서비스 간 통신 레이턴시를 40% 이상, 인프라 비용을 15% 이상 절감했습니다.

시나리오 2: L7(Application) 계층 보안과 카프카(Kafka) 통제

네트워크 보안 정책(NetworkPolicy)은 보통 IP나 Port(L3/L4) 단위로 이루어집니다. 하지만 현업에서는 “특정 서비스가 Kafka의 ‘order-events’ 토픽에는 Write(Produce)를 할 수 있지만, 다른 토픽은 건드리지 못하게 해줘”라는 요구사항이 들어옵니다. Cilium은 eBPF를 통해 패킷 페이로드를 검사하므로 다음과 같은 정책이 쌩 YAML로 가능합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "lock-down-kafka"
spec:
  endpointSelector:
    matchLabels:
      app: kafka-broker
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: order-service
    rules:
      kafka:
      - role: "produce"
        topic: "order-events" # 이 토픽만 허용! 나머지는 eBPF 레벨에서 차단

이걸 애플리케이션 코드 수정 없이 커널 단에서 통제한다는 건, 기획자와 보안팀 모두를 웃게 만드는 엄청난 무기입니다.

⚖️ Honest Review & Trade-offs: 만능은 아닙니다. 시니어의 깐깐한 시선

자, 이제 뽕(?)에서 빠져나와 차가운 현실을 볼 시간입니다. 블로그 글만 보면 당장 내일 도입해야 할 것 같지만, 실무에서 마주하는 진입 장벽은 꽤 높습니다.

  1. 엄격한 커널 버전 종속성: eBPF의 주요 기능(특히 SockOps나 최신 BPF Type Format)을 제대로 쓰려면 최소 Linux 커널 5.x 이상이 필요합니다. 만약 여러분의 회사가 보수적인 금융권이라 아직 RHEL 7(커널 3.10)을 쓰고 있다면? 도입 자체가 불가능합니다. 레거시 온프레미스와의 혼합 환경에서는 치명적인 제약이 될 수 있습니다.

  2. 악명 높은 BPF Verifier와 디버깅 지옥: 커널 패닉을 막아주기 위해 eBPF Verifier는 코드를 극도로 보수적으로 검증합니다. 무한 루프가 발생할 여지가 아주 조금이라도 있거나, 프로그램 명령어가 제한 수치를 넘어서면 컴파일 자체를 뱉어냅니다. 문제가 생겼을 때 TCPDump 대신 bpftool이나 hubble을 이용해 디버깅해야 하는데, 초기 학습 곡선이 매우 가파릅니다. 장애 났을 때 원인을 파악할 수 있는 시니어 엔지니어가 없다면 클러스터 전체가 블랙박스가 되어버립니다.

  3. 특정 벤더 락인 (Vendor Lock-in) 우려: Cilium은 CNCF 졸업 프로젝트이긴 하지만, 핵심 기술 스택과 엔터프라이즈 기능은 Isovalent(최근 Cisco에 인수됨)라는 특정 기업에 강하게 의존하고 있습니다. 생태계 주도권이 한 곳에 집중되어 있다는 점은 아키텍트로서 한 번쯤 고민해봐야 할 포인트입니다.

💡 Closing Thoughts: 결국 우리가 가야 할 길

처음 쿠버네티스의 네트워킹 아키텍처를 공부할 때만 해도 iptables는 마치 절대 변하지 않을 바이블 같았습니다. 하지만 클라우드 네이티브 생태계는 엄청난 속도로 진화했고, 이제 인프라의 추상화 계층은 유저 스페이스를 넘어 커널 딥(Deep) 한 곳으로 내려가고 있습니다.

비록 디버깅은 까다롭고 커널 버전을 올려야 하는 수고로움이 있지만, 대규모 트래픽 스파이크 상황에서 보여주는 eBPF의 우아함과 퍼포먼스는 그 모든 고생을 상쇄하고도 남습니다. 만약 지금 여러분의 팀이 마이크로서비스 확장에 따른 네트워크 병목이나 사이드카 프록시 오버헤드로 고통받고 있다면, 더 늦기 전에 eBPF와 Cilium을 테스트 환경에 올려보세요. 패킷을 직접 통제하는 그 짜릿한 감각을 경험하는 순간, 다시는 iptables의 늪으로 돌아가고 싶지 않으실 겁니다.

References

  • https://ebpf.io/
  • https://github.com/cilium/cilium
  • https://dl.acm.org/doi/10.1145/3387514.3406591
Tech
This post is licensed under CC BY 4.0 by the author.