[KANS] Cilium CNI - eBPF

이 스터디는 CloudNet@에서 진행하는 KANS 스터디를 참여하면서 공부하는 내용을 기록하는 블로그 포스팅입니다.

CloudNet@에서 제공해주는 자료들을 바탕으로 작성되었습니다.

eBPF

eBPF란?

https://cilium.io/blog/2020/11/10/ebpf-future-of-networking/

 

eBPF는 Extended Berkeley Packet Filter의 약자로 네트워크 패킷 필터링, 성능 모니터링, 보안 등 커널 내에서 실행되는 프로그램입니다. 특히, 운영 체제 커널과 같은 특별한 권한이 있는 환경에서 샌드박스 프로그램을 실행할 수 있습니다. 이때, 커널 소스 코드를 수정하거나  커널 모듈을 로드하지 않고도 기존의 커널 기능을 안전하고 효율적으로 확장시키는 것에 사용됩니다.

샌드박스 프로그램(Sandbox Program)
주로 보안과 관련된 개념으로, 격리된 환경에서 특정 프로그램이나 코드가 실행되도록 하는 소프트웨어입니다. 이 프로그램은 악성 코드나 불확실한 코드가 시스템에 해를 끼치지 않도록, 실제 운영 체제나 주요 시스템 파일과의 상호작용을 차단한 상태에서 실행합니다. 이를 통해 시스템의 안전을 유지하면서도 의심스러운 프로그램을 테스트하거나 분석할 수 있습니다.

 

기존의 한계

Linux Network Stack

 

기존 리눅스 네트워크 스택의 단점은 복잡하고, 변경에 시간이 걸리고, 레이어를 건너뛰기 어려웠습니다.  간단히 설명드리자면, layer 1의 하드웨어 레이어,  물리적인 네트워크 디바이스와 드라이버가 존재하고, L2 이더넷 및 데이터 링크 계층, L3의 IP와 Netfilter (주로 패킷 필터링 및 라우팅 관련), L4의 TCP/UDP 전송 계층, L5의 socket 연결을 통한 세션 계층, L7의 애플리케이션 계층으로 system call interface이 존재합니다. 

 

 

위의 그림처럼 User-Space내에 있는 애플리케이션(Process)이 외부 시스템과 통신한다고 했을 때의 상황입니다. 
sendmsg()라는 system call을 소켓(TCP나 웹 소켓)에게 전달합니다. 그 후 User-Space의 Networking을 타고 Kurnel의 Nerwork Device를 통해 외부로 전달됩니다. 응답을 받을 때는 반대로 동작하며 socket이 recvmsg()라는 system call을 애플리케이션(Process)에게 전달합니다.

iptables의 단점

iptables rule 지옥...

iptables 규칙을 업데이트하려면 모든 규칙을 재생성하고 업데이트해야 하므로, 단일 트랜잭션으로 처리해야 합니다. 또한, rule chain을 linked list로 구현하므로, 모든 작업이 O(n) 복잡도를 갖게 됩니다. 즉, 규칙 수가 많아질수록 엄청난 성능 저하를 초래합니다. 왜냐하면 매번 통신할 때마다 처음부터 계산해야 하기 때문입니다.

iptables rule 예시

 

BPF kernel hooks

BPF는 커널에 삽입하여 패킷을 통제(필터링) 할 수 있으며, 다양한 영역에서 Hook 을 통해서 접근 할 수 있습니다. 즉, 거의 모든 영역에서 hook을 삽입하여 원하는 대로 통제가 가능해집니다.

 

eBPF 등장

1992년에 출시된 BPF를 eBPF가 2014년에 확장하여 출시했고, 다양한 영역 (보안, 추적, 네트워킹, 모니터링)에서 활용하기 시작하였습니다.

 

운영 체제 커널과 같은 특별한 권한이 있는 환경에서 샌드박스 프로그램을 실행 할 수 있는것이 eBPF가 탄생하게 된 배경 기술입니다. 즉, 커널 내에 (샌드박스 내에서) 자유롭게 프로그래밍하여 적용 할 수 있습니다.

 

Hook

https://ebpf.io/what-is-ebpf/#hook-overview

eBPF는 이벤트 기반으로 동작하고, 커널 또는 애플리케이션이 특정 hook 지점을 지나갈 때 실행됩니다. 이때, hook은 system call, function 진입 및 종료, kernel tracepoints, network events 등으로 사전에 정의됩니다. 

 

Linux 커널에 내장된 eBPF

 

eBPF가 리눅스 커널에 직접 통합되어 있는 점이 주요 강점이며, 네트워크 데이터가 User-Space를 거치지 않고 커널에서 바로 처리되기에 성능이 크게 향상됩니다. 또한, eBPF는 코드 검증 과정을 통해 시스템 충돌을 방지하면서도 높은 성능을 유지하고, JIT(Just-in-Time) 컴파일을 사용해 빠른 실행 속도도 확보할 수 있다는 점도 큰 강점입니다.

eBPF의 성능

Kernel에서 Packet이 전달되는 경로

 

일반적으로 Packet이 전달되는 경로는 위와 같습니다.

패킷 차단 -  UDP packet

 

위와 같이 10Gbe의 Packet을 전달해보겠습니다. 여기서 확인할 것은 패킷 드롭과 처리 속도 간의 관계는 패킷이 얼마나 빠르게 처리(또는 드롭)되는지에 따라 결정되기에 얼마나 많은 양을 처리하는지 확인해보겠습니다. 

 

Userspace 패킷 차단

 

UserSpace Layer에서 패킷을 차단할 경우의 경로를 살펴보면 하드웨어단에서 인입되어 TC Ingress를 걸쳐 Iptable rule에 통해 전달되고 최종으로 애플리케이션단에서 차단됩니다.

 

Netfilter 패킷 차단

 

Netfilter에서 차단할 경우,  하드웨어단에서 인입되어 TC Ingress를 걸쳐 Iptable rule에서 차단됩니다.

 

TC Ingress 패킷 차단

 

TC Ingress에서 차단할 경우의 경로는 하드웨어단에서 인입되어 L3의 TC Ingress에서 차단됩니다.

 

 

XDP 패킷 차단

XDP에서 차단할 경우입니다.

 

패킷 차단 - 결과 

 

결과를 살펴보면 UserSpace에서 차단할 경우 783,063의 속도가 나오고, netfilter는 1,266,730, TC Ingress는 4,083,820, XDP는 무려 6.69Gb의 양으로 확인됩니다. 즉, XDP(eXpress Data Path)에서 더 많은 양이 처리된 이유는 XDP가 커널의 네트워크 드라이버 단계에서 작동하기 때문입니다. 이 방식은 패킷을 사용자 공간이나 Netfilter, tc 같은 상위 계층으로 전달하기 전에 바로 처리하거나 드롭할 수 있어 지연 시간이 줄어듭니다. 반면, Netfilter나 tc에서 패킷을 처리하려면 더 많은 시스템 리소스를 사용하고 상위 레이어까지 패킷이 도달해야 하기 때문에 성능 저하가 발생합니다. 

XDP의 경로

XDP도 Iptables처럼 규칙이 존재하는데, netfilter이상의 계층에서 차단된다면 iptables rule같은 경로를 한번 더 거치게 되는것이니 속도가 느리게 됩니다.

 

XDP Mode

XDP에는 Generic(Linux Kernel Network Stack), Native(Network Driver, Intel 등), Offloaded(Network Hardware, Netronome)의 3가지 모드가 존재합니다.

패킷 차단 - XDP Offload

이때, XDP의 offload 모드로 설정하게 되면 하드웨어단에서 바로 drop이 일어나기 때문에 인입된 모든 10Gb가 처리되게 됩니다.