Post

사이드카, 이제 좀 버리시죠: eBPF가 서비스 매시의 판을 뒤엎는 방식

Posted
Time to Ditch the Sidecar: How eBPF is Disrupting Service Mesh
Time to Ditch the Sidecar: How eBPF is Disrupting Service Mesh
By
18 min read
사이드카, 이제 좀 버리시죠: eBPF가 서비스 매시의 판을 뒤엎는 방식

다들 쿠버네티스 클러스터에 Istio나 Linkerd 같은 서비스 매시를 얹어놓고 “이제 우리도 완벽한 마이크로서비스 아키텍처를 구축했어!” 라며 축배를 들던 때가 있었죠. 저도 5년 전쯤 그랬으니까요. 그런데 실전 프로덕션 환경은 어땠나요? 서비스 파드(Pod) 하나 띄울 때마다 찰싹 달라붙어 올라오는 Envoy 사이드카 때문에, 실제 애플리케이션 트래픽은 늘지도 않았는데 노드 메모리 사용률이 미친 듯이 치솟는 꼴, OOM(Out of Memory) 킬러가 파드를 무참히 썰어버리는 광경을 한 번쯤은 보셨을 겁니다.

“네트워크 가시성 확보하고 mTLS 좀 쓰겠다는데, 인프라 비용을 두 배로 태워야 한다고?” 현업에서 이 질문을 받으면 백이면 백 꿀 먹은 벙어리가 됩니다. 그래서 오늘은 이 비효율의 끝판왕인 사이드카 패턴을 커널 레벨에서 도려내고 있는 기술, eBPF(Extended Berkeley Packet Filter)와 이를 활용한 사이드카 없는 서비스 매시(Sidecarless Service Mesh)에 대해 바닥까지 뜯어보려 합니다.

🎯 한 마디로 요약하면? (TL;DR)

“eBPF는 리눅스 커널에 직접 꽂는 안전한 플러그인입니다. 유저 스페이스에서 낑낑대며 패킷을 복사하던 무거운 사이드카 프록시를 걷어내고, 커널단에서 모든 네트워크 트래픽과 보안 정책을 빛의 속도로 가로채서 처리합니다.”

🛠️ Under the Hood: 커널로 직행하는 하이패스, eBPF

우리가 쓰던 기존 사이드카 방식(예: Istio + Envoy)을 생각해봅시다. 패킷이 물리적 NIC(네트워크 인터페이스 카드)를 타고 들어와 커널의 TCP/IP 스택을 거쳐 유저 스페이스의 사이드카로 올라갑니다. 사이드카가 패킷을 까보고 룰을 적용한 뒤, 다시 커널로 내려보내서 애플리케이션 파드로 전달하죠. 이 과정에서 발생하는 컨텍스트 스위칭(Context Switching)과 메모리 복사(Memory Copy)가 바로 레이턴시의 주범입니다.

솔직히 처음 이 eBPF 아키텍처를 봤을 땐 꽤나 의구심이 들었습니다. “아니, 커널에 직접 코드를 밀어 넣는다고? 커널 패닉 나면 클러스터 노드 전체가 뻗는 거 아냐?”

그런데 막상 까보니 아니더라고요. eBPF는 커널 내부에 완벽히 격리된 샌드박스 VM(Sandboxed Virtual Machine)을 띄웁니다. 우리가 작성한 eBPF 프로그램(보통 C나 Rust로 작성)은 JIT 컴파일러를 통해 커널 바이트코드로 변환되는데, 이때 커널 내의 ‘Verifier(검증기)’가 무한 루프는 없는지, 잘못된 메모리 참조는 없는지 미친 듯이 깐깐하게 검사합니다. 조금이라도 찜찜하면 아예 로드를 거부해버리죠.

추가로 놀라운 점은 eBPF Maps라는 자료구조입니다. 커널과 유저 스페이스 간에 데이터를 효율적으로 공유할 수 있는 해시 테이블과 배열을 제공하죠. 이 Map을 통해 유저 스페이스의 컨트롤 플레인은 실시간으로 보안 정책을 업데이트하고, 커널의 eBPF 프로그램은 이 Map을 O(1) 속도로 참조하여 패킷을 제어합니다. 게다가 Socket Routing 기술은 한술 더 뜹니다. 같은 노드 내의 파드끼리 통신할 때, 기존에는 패킷이 파드 A에서 나와 호스트 브릿지를 거쳐 라우팅 테이블을 타고 다시 파드 B로 들어가는 뻘짓을 했죠. eBPF는 TCP 소켓 연결을 가로채서 패킷 송신자의 소켓과 수신자의 소켓을 커널단에서 다이렉트로 연결해버립니다. 네트워크 스택 자체를 우회(Bypass)해버리는 미친 최적화입니다.

이 모든 것이 가능한 이유는 eBPF가 리눅스 커널의 거의 모든 이벤트 지점에 훅(Hook)을 걸 수 있기 때문입니다. 네트워크 패킷이 들어오는 XDP 포인트부터, kprobes(커널 함수 호출), uprobes(유저 스페이스 함수 호출), 그리고 tracepoints까지 시스템의 맥박이 뛰는 모든 곳에 관측소를 세울 수 있습니다. 즉, 단순한 네트워킹을 넘어 보안과 프로파일링 영역까지 인프라 생태계 자체를 집어삼키고 있는 것이죠.

아키텍처의 차이를 명확하게 비교해볼까요?

비교 항목📦 기존 Sidecar 패턴 (Istio/Envoy)🚀 eBPF 기반 (Cilium)
데이터 경로NIC -> Kernel -> User Space Proxy -> Kernel -> AppNIC -> Kernel (eBPF) -> App
패킷 처리 위치유저 스페이스 (L7 레벨에서 과도한 파싱)커널 스페이스 (XDP/TC 훅으로 패킷 즉각 처리)
리소스 오버헤드파드당 1개의 프록시 (1000 파드 = 1000 Envoy). 메모리 최악.노드당 1개의 데몬셋(DaemonSet). 리소스 사용량 극도로 낮음.
레이턴시 (지연시간)애플리케이션-프록시 간 핑퐁으로 인해 밀리초(ms) 단위 지연 증가커널 소켓 바이패스로 TCP/IP 스택 생략, 지연시간 최대 40% 감소

💻 코드로 보는 진짜 차이점: 유저 스페이스는 알 필요도 없다

말로만 하면 와닿지 않죠. eBPF가 얼마나 무식하게(?) 빠른 곳에서 트래픽을 통제하는지, XDP(eXpress Data Path) 훅을 사용하는 아주 간단한 eBPF C 코드 스니펫을 준비했습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

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

    // 패킷 길이 검증 (Verifier 통과를 위한 필수 작업)
    if (data + sizeof(*eth) > data_end)
        return XDP_ABORTED;

    struct iphdr *ip = data + sizeof(*eth);
    if (data + sizeof(*eth) + sizeof(*ip) > data_end)
        return XDP_ABORTED;

    // 악의적인 IP 대역 필터링 예시 (하드코딩된 특정 IP)
    if (ip->saddr == bpf_htonl(0xC0A80164)) {
        // 유저 스페이스로 올리지도 않고 NIC 드라이버 레벨에서 즉각 폐기!
        return XDP_DROP;
    }
    return XDP_PASS;
}

위 코드를 보면, 악의적인 트래픽이 커널의 네트워크 스택을 타기도 전에 물리적 NIC 드라이버 단계에서 XDP_DROP을 때려버립니다. 커널은 신경도 안 쓰고 패킷을 휴지통에 처박는 거죠. 기존 IPTables가 수천 개의 룰을 순차 탐색(O(N))하며 CPU를 태울 때, eBPF는 해시맵 기반으로 O(1)의 속도로 필터링을 끝내버립니다. 이 차이는 트래픽이 몰릴 때 엄청난 결과를 만들어냅니다.

🔥 현업 트러블슈팅: 진짜 쓸만할까?

그렇다면 이 강력한 무기가 현업 프로덕션에서 어떻게 빛을 발할까요? 뻔한 예시 말고, 진짜 피눈물 나는 운영 환경을 가정해봅시다.

시나리오 1: 대규모 트래픽 스파이크 시 연결 고갈 문제 제가 예전에 관리했던 대형 이커머스 시스템에서는 블랙 프라이데이 이벤트만 되면 사이드카 프록시의 Connection Pool이 말라버리거나, CPU 스로틀링이 걸려 전체 API 응답이 늘어지는 장애가 잦았습니다. Envoy 자체 성능 튜닝에 며칠을 쏟았죠. eBPF(Cilium 등) 기반으로 전환한 후에는 이런 걱정이 싹 사라졌습니다. L3/L4 계층의 라우팅과 로드밸런싱을 노드 커널에서 직접 eBPF 맵을 통해 분산 처리해버리니, CPU 스파이크가 눈에 띄게 평탄해지고 (기존 대비 약 60% 절감), 노드 전체의 처리량이 물리적 한계치까지 버텨내더라고요.

시나리오 2: 레거시 파드에 투명한(Transparent) 관측성 부여 운영 중인 시스템에 새로운 트레이싱 도구를 넣을 때마다, 개발팀에 “파드 템플릿에 어노테이션 추가해서 사이드카 재시작해주세요”라고 부탁하는 거, 솔직히 서로 피곤하잖아요? 거부감도 심하고요. eBPF를 쓰면 애플리케이션 재시작이나 파드 템플릿 수정이 전혀 필요 없습니다. 노드 레벨에서 커널 이벤트(Syscall)를 낚아채기 때문에, 이미 돌고 있는 레거시 파드의 HTTP 응답 코드, 레이턴시, DNS 쿼리 내역을 그대로 뽑아낼 수 있습니다. 이 ‘비침투성(Non-intrusiveness)’이야말로 기획자와 개발자 모두가 환호하는 진짜 혁신입니다.

💀 시니어의 깐깐한 시선: Trade-offs & 삽질 포인트

물론 세상에 은탄환은 없습니다. eBPF가 만능열쇠처럼 보이지만, 현업 도입을 고려할 때 반드시 짚고 넘어가야 할 치명적인 단점들도 존재하죠. 무턱대고 도입했다간 밤새우기 십상입니다.

  1. 블랙박스 디버깅의 지옥 (Debugging Nightmare): 가장 큰 스트레스는 장애가 났을 때입니다. 기존에는 프록시 로그라도 까보면 트래픽이 어디서 막혔는지 보였는데, eBPF 프로그램이 커널단에서 패킷을 조용히 Drop 시켜버리면? 애플리케이션 레벨에선 왜 통신이 안 되는지 전혀 알 방도가 없습니다. Hubble 같은 eBPF 전용 관측 도구에 100% 의존해야 하고, 인프라 엔지니어들이 커널 네트워킹에 대한 깊은 이해가 없다면 트러블슈팅 기간이 배로 늘어납니다.
  2. 엄격한 커널 버전 의존성: eBPF의 최신 기능(BTF, XDP 등)을 제대로 쓰려면 최소 Linux 커널 4.19 이상, 권장 5.x 이상이 넉넉히 필요합니다. 오래된 CentOS 7 기반의 온프레미스 레거시 서버를 돌리는 환경이라면? 눈물을 머금고 포기하거나 OS 마이그레이션부터 해야 합니다. 커널 버전에 발목 잡히는 경우가 허다하죠.
  3. L7 처리의 한계: eBPF는 커널 레벨에서 놀기 때문에 L3/L4 제어에는 신의 경지지만, HTTP 바디를 뜯어보고 헤더를 변조하는 등 복잡한 L7 로직은 한계가 있습니다. 결국 Envoy 같은 유저 스페이스 프록시를 노드 단위(DaemonSet)로 띄워서 하이브리드로 써야 하는 경우가 많습니다. (최근 Cilium도 이 하이브리드 방식을 채택하고 있습니다).

💡 마치며: 결국 넘어갈 수밖에 없는 미래

사이드카 패턴이 틀렸다는 것은 아닙니다. 마이크로서비스 과도기에서 꼭 필요한 패러다임이었습니다. 하지만 인프라 규모가 커질수록 “애플리케이션마다 프록시를 1:1로 띄운다”는 발상은 물리적 한계와 비용의 벽에 마주할 수밖에 없습니다.

“지금 당장 Istio를 걷어내고 eBPF로 갈아타야 할까요?” 라고 묻는다면, 현재 클러스터 크기가 작고 사이드카 리소스 비용이 부담되지 않는다면 1~2년 정도 생태계(특히 L7 지원과 디버깅 툴) 성장을 더 지켜보셔도 좋다고 현실적인 조언을 드리겠습니다.

하지만, 매월 클라우드 비용 청구서에서 의미 없이 낭비되는 메모리 비용을 보며 한숨을 쉬고 있거나, 네트워크 레이턴시 1ms 최적화에 목숨을 거는 대규모 도메인이라면, 지금 당장 eBPF의 세계로 뛰어드십시오. 커널 레벨의 혁신이 가져다주는 퍼포먼스의 신세계, 그리고 인프라 관리의 패러다임 시프트가 여러분을 기다리고 있을 겁니다.

References

  • https://ebpf.io/
  • https://cilium.io/
  • https://github.com/cilium/cilium
Tech
This post is licensed under CC BY 4.0 by the author.