eBPF는 L3/L4 처리와 일부 관측 경로를 커널로 옮길 수 있지만, 모든 사이드카와 L7 프록시를 없애는 보편적 대체재는 아닙니다.
eBPF는 사이드카를 어디까지 대체할까: XDP, Sockmap과 운영 비용의 경계
사이드카 비용 중 무엇을 옮기는가
파드마다 Envoy 같은 프록시가 있으면 애플리케이션 트래픽이 사용자 공간 프록시를 거쳐 다시 커널로 이동합니다. 이 구조는 정책과 관측을 애플리케이션에서 분리하기 쉽지만, 파드 수에 따라 프록시 CPU, 메모리가 늘고 패킷 경로에 사용자 공간 왕복이 추가됩니다. kube-proxy와 iptables 규칙이 큰 환경에서는 서비스 조회 경로도 함께 점검 대상이 됩니다.
eBPF 접근은 일부 처리를 커널 훅과 Map으로 이동합니다. 파드마다 같은 프록시를 반복하기보다 노드 수준의 프로그램과 컨트롤 플레인이 정책을 배포할 수 있습니다. 그러나 절감 폭은 트래픽 형태, 기존 프록시 설정, 커널과 CNI 구현에 따라 달라집니다. 모든 iptables 동작을 단순한 O(N), 모든 BPF 조회를 항상 O(1)이라고 놓고 비용을 계산하면 실제 데이터 경로를 놓치기 쉽습니다.
XDP, Sockmap, BPF Map은 서로 다른 일을 한다
세 용어를 “커널에서 빠르게 처리한다”로 뭉치면 도입 범위를 잘못 잡습니다.
- XDP는 NIC 드라이버와 가까운 지점에서 패킷을 통과, 삭제, 리다이렉트하는 데 적합합니다.
- Sockmap 계열은 소켓 경로에 연결해 특정 로컬 통신을 다른 소켓으로 넘기는 데 쓰입니다.
- BPF Map은 사용자 공간 컨트롤 플레인과 커널 프로그램이 정책, 상태를 공유하는 자료구조입니다.
- kprobe, uprobe 같은 훅은 함수 호출 관측에 활용할 수 있습니다.
XDP 방화벽이 DDoS성 패킷을 일찍 버릴 수 있다는 것과 서비스 메시의 재시도, mTLS, 카나리 라우팅을 구현한다는 것은 다른 문제입니다. Sockmap도 모든 파드 통신에서 TCP/IP 스택을 자동으로 생략하는 마법이 아닙니다. 연결과 키를 채우는 사용자 공간 구성, attach 지점, 실패 시 정상 경로가 함께 설계돼야 합니다.
원문의 XDP C 코드는 해시 Map에서 출발지 IP를 찾고 XDP_DROP 또는 XDP_PASS를 반환하는 설명용 핵심 조각입니다. 로더와 attach, Map 갱신, EtherType, VLAN, IPv6 처리, 엔디언 규약과 빌드 환경이 빠져 있어 사이드카 대체 구현으로 실행할 수 없습니다.
커널로 옮겨도 L7과 운영 책임은 남는다
IP, 포트 정책, 로드밸런싱, 패킷 드롭, 연결 관측처럼 L3/L4에 가까운 문제는 eBPF와 잘 맞습니다. 애플리케이션을 수정하기 어려운 환경에서 네트워크와 함수 호출을 관측하는 것도 강점이 될 수 있습니다.
반면 HTTP 헤더와 body, 복잡한 gRPC 재시도, 인증서 교환, 콘텐츠 기반 라우팅 같은 L7 처리는 사용자 공간 프록시가 더 유연합니다. 그래서 현실적인 구성은 “프록시 0개”가 아니라 L3/L4는 eBPF로, 필요한 L7은 노드 수준 또는 제한된 프록시로 보내는 하이브리드일 수 있습니다.
운영 난도도 이동합니다. BPF Verifier는 안전하지 않다고 판단한 프로그램의 적재를 거부하고, 사용할 수 있는 훅과 기능은 커널 버전에 좌우됩니다. 직접 C 코드를 유지하지 않더라도 Cilium, Pixie, Tetragon 같은 구현의 진단 도구와 업그레이드 경로를 익혀야 합니다. 프록시 로그 대신 커널 데이터 경로를 해석할 사람이 없다면 장애 복구는 오히려 느려질 수 있습니다.
교체가 아니라 병목별로 범위를 정한다
먼저 사이드카별 CPU, 메모리, p50, p99 지연, iptables 규칙과 서비스 수, 네트워크 드롭을 측정합니다. 병목이 DB 쿼리나 애플리케이션 락이라면 데이터 플레인을 바꿔도 해결되지 않습니다.
평가 순서는 다음이 안전합니다.
- 읽기 전용 관측으로 현재 패킷 경로와 드롭 원인을 확인합니다.
- 한 노드 풀과 한 워크로드에서 L3/L4 정책만 옮깁니다.
- 같은 부하로 지연, CPU, 메모리와 장애 복구 시간을 비교합니다.
- 필요한 L7 기능을 목록화하고 남길 프록시 위치를 정합니다.
- 커널 업그레이드와 공급자 종속성까지 총비용에 포함합니다.
eBPF 도입의 판단점은 “사이드카 시대가 끝났는가”가 아닙니다. 측정된 비용 중 커널로 안전하게 옮길 수 있는 부분이 무엇이며, 그 결과 새로 맡게 될 운영 복잡성이 절감액보다 작은가입니다.
비용은 파드 수가 아니라 실제 데이터 경로로 계산한다
사이드카 비용을 산정할 때 모든 프록시의 request 값을 더하면 실제 사용량을 과대평가할 수 있고, 평균 CPU만 보면 짧은 부하에서 생기는 꼬리 지연을 놓칠 수 있습니다. 서비스별 트래픽량, 연결 수, payload 크기, TLS와 재시도 비율을 나눠 프록시 CPU, 메모리와 p95, p99 지연을 함께 수집해야 합니다. 같은 파드 수라도 내부 배치와 대화형 API의 병목은 다릅니다.
eBPF 쪽에도 공짜가 아닌 항목이 있습니다. 노드 에이전트와 컨트롤 플레인의 자원, Map 메모리, flow 로그 수집, 보존, 커널 호환 테스트, 노드 이미지 변경과 교육 시간을 넣어야 합니다. 파드당 메모리가 줄어도 노드 장애의 영향 범위가 커지고 진단 시간이 늘면 총운영비는 기대만큼 낮아지지 않을 수 있습니다.
비교표에는 월 비용만 적지 말고 정상 트래픽 한 건의 경로도 적습니다. 클라이언트에서 NIC, XDP, TC 또는 socket 훅, L7 프록시, 애플리케이션까지 어느 단계를 거치는지 표시하면 “프록시 제거”라는 문구 뒤에 실제로 남은 hop을 볼 수 있습니다. 암호화가 어느 구간에서 종료되는지도 같은 그림에 포함해야 합니다.
기능 배치표가 아키텍처 결정을 대신 말하게 한다
현재 메시 정책을 인증, 암호화, 서비스 발견, 로드밸런싱, 재시도, timeout, rate limit, HTTP 라우팅, 관측으로 분해합니다. 각 기능에 현재 구현 위치와 새 위치, 동일 동작을 증명할 테스트, 담당 팀을 붙입니다. 위치가 정해지지 않은 기능이 하나라도 있으면 ‘sidecarless 완료’로 간주하지 않습니다.
예를 들어 IP, 포트 정책은 커널 데이터 경로로 옮길 수 있지만 사용자 신원 기반 HTTP 권한은 L7 정보가 필요할 수 있습니다. TCP 연결 성공만 확인하면 헤더 기반 카나리나 재시도 예산이 사라진 사실을 놓칩니다. 노드 프록시를 남기는 구성도 실패가 아니라 파드별 중복 비용과 L7 유연성 사이의 절충입니다.
업무마다 요구가 다르면 한 클러스터에서도 여러 경로를 허용할 수 있습니다. 단순 내부 TCP 서비스는 eBPF 경로, 외부 결제 API는 L7 프록시와 명시적 승인 정책을 사용할 수 있습니다. 다만 예외가 많아질수록 운영자가 현재 경로를 즉시 알 수 있도록 label, 정책과 대시보드가 일치해야 합니다.
벤치마크는 기능이 같은 상태에서 수행한다
기존 사이드카에서 mTLS, access log, 재시도를 켜고 새 구성에서는 끈 채 지연만 비교하면 빠른 것이 당연합니다. 동일한 암호화, 정책, 로그 수준과 실패 처리 조건을 맞춘 뒤 정상, 과부하, 장애 구간을 나눠야 합니다. 워밍업 뒤 p50뿐 아니라 p99, CPU per request, 메모리, 연결 오류와 재전송을 측정합니다.
노드 간, 같은 노드, 외부로 나가는 트래픽도 분리합니다. Sockmap 최적화는 특정 로컬 소켓 경로에서 의미가 있을 수 있지만 모든 경로에 같은 이득을 주지 않습니다. 작은 payload와 큰 payload, 짧은 연결과 장기 연결을 섞지 않으면 어느 워크로드에서 개선됐는지 설명할 수 있습니다.
장애 실험에는 BPF 프로그램 적재 실패, Map 동기화 지연, 노드 재부팅, 정책 컨트롤 플레인 단절, L7 프록시 장애가 포함돼야 합니다. 정상 처리량이 좋아도 잘못된 정책을 되돌리는 데 오래 걸리면 배포 범위를 넓히기 어렵습니다. 결과는 커널, CNI, 노드 이미지 버전과 함께 보관해 업그레이드 후 회귀 기준으로 재사용합니다.
커널 업그레이드는 애플리케이션 배포와 다른 위험을 가진다
BPF 프로그램은 verifier를 통과하더라도 커널 helper, attach type와 BTF 정보에 의존할 수 있습니다. 개발 환경에서 적재됐다는 사실이 운영 배포판의 모든 노드에서 같은 동작을 보장하지 않습니다. 지원 커널 행렬을 만들고 canary 노드에서 적재, 정책, 관측 테스트를 통과한 뒤 점진적으로 확장해야 합니다.
CO-RE 같은 이식성 기법은 구조체 차이를 줄이는 데 도움을 주지만 논리와 기능 차이를 자동으로 해결하지 않습니다. 운영 배포 전에 verifier 로그를 수집하고, 실패 시 기존 CNI, 프록시 경로가 유지되는지 확인합니다. 노드 전체 트래픽에 영향을 주는 구성은 애플리케이션 한 파드 롤백보다 피해 범위가 크므로 배포 속도를 따로 제한하는 편이 좋습니다.
롤백은 패키지를 내리는 명령 하나가 아닙니다. 기존 정책 상태, conntrack과 Map, 라우팅 규칙, 노드 프록시와 인증서가 이전 경로에서 다시 일관되는지 시험해야 합니다. 비상 시 새 프로그램 detach, 이전 데이터 플레인 활성화, 연결 배출과 검증 요청까지 걸리는 시간을 실제로 재야 합니다.
함께 읽으면 이해가 이어지는 글
- Cilium으로 사이드카를 줄여도 될까: L4, L7 경계와 마이그레이션 — Cilium이 eBPF로 쿠버네티스 네트워크와 정책을 처리하는 구조를 살펴보고, 사이드카 없는 L4 경로와 L7 프록시가 남는 지점을 구분해 이관 기준을 정리합니다.
- 사이드카를 없애도 될까: eBPF 서비스 메시의 경계와 선택 기준 — eBPF, Cilium이 파드별 프록시의 L3/L4 역할을 어디까지 줄일 수 있는지 살펴보고, mTLS, L7 라우팅, 관측 요구에 따라 사이드카 유지 여부를 판단합니다.
- Istio 사이드카를 없애도 될까: eBPF 서비스 메시와 L7 하이브리드 조건 — 파드별 Istio, Envoy 비용을 eBPF와 노드 단위 프록시로 줄일 수 있는 조건을 살펴보고, mTLS, 재시도, HTTP 라우팅 때문에 남는 L7 기능과 안전한 전환 기준을 정리합니다.
자주 묻는 질문
eBPF를 도입하면 모든 서비스 메시 사이드카를 제거할 수 있나요?
아닙니다. L3, L4 정책과 일부 관측은 옮길 수 있지만 HTTP 라우팅, 재시도, mTLS 같은 L7 기능은 프록시나 애플리케이션에 남을 수 있습니다.
XDP와 Sockmap 중 무엇을 먼저 써야 하나요?
패킷 수신 초기에 차단, 리다이렉트하려면 XDP, 특정 소켓 사이의 전달 경로를 다루려면 Sockmap 계열을 검토하며 작업과 attach 지점에 따라 선택합니다.
eBPF 전환 파일럿의 중단 조건은 무엇인가요?
정책 누락, 허용 트래픽 차단, 진단 불가, 롤백 시간 초과가 발생하거나 측정한 자원 절감이 운영 복잡성보다 작으면 확대를 멈춰야 합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.