ARI

eBPF는 단순한 커널 기능이 아니라 현대 클라우드와 Kubernetes 환경을 구성하는 핵심 기술로 발전했습니다. 과거에는 패킷 필터링이나 커널 추적 정도에 활용되었지만, 현재는 네트워크, 보안, 관찰성(Observability), 성능 분석, 런타임 보안까지 다양한 분야에서 사용되고 있습니다. 특히 CNCF(Cloud Native Computing Foundation) 생태계에서는 eBPF 기반 프로젝트들이 빠르게 증가하고 있으며, Kubernetes 환경에서는 사실상 표준 기술로 자리 잡고 있습니다. 이번 글에서는 대표적인 … 더 읽기

eBPF는 단순히 커널 내부를 추적하는 기술이 아닙니다. 오늘날에는 프로세스 모니터링, 네트워크 분석, 보안, 성능 최적화, 컨테이너 관리, DDoS 방어 등 다양한 분야에서 실제 서비스에 활용되고 있습니다. 특히 Kubernetes와 클라우드 환경에서는 eBPF가 핵심 기술로 자리 잡았으며, Cilium, Falco, Pixie, Katran 같은 유명 프로젝트도 모두 eBPF를 기반으로 동작합니다. 이번 글에서는 실제 현업에서 자주 구현하는 eBPF 프로젝트를 중심으로 … 더 읽기

eBPF를 공부하다 보면 가장 많이 등장하는 기술 중 하나가 XDP(eXpress Data Path) 입니다. XDP는 단순히 빠른 패킷 필터가 아닙니다. Linux 네트워크 스택(Network Stack)에 패킷이 들어오기 전에 eBPF 프로그램을 실행하여 방화벽, DDoS 방어, 로드 밸런싱, 패킷 분석 등을 매우 빠르게 수행할 수 있는 기술입니다. 오늘날 Cilium, Katran, Cloudflare, Meta(Facebook) 등 대규모 서비스에서도 XDP를 적극 활용하고 있습니다. … 더 읽기

최근 eBPF 개발은 대부분 C 언어와 libbpf를 기반으로 이루어지고 있습니다. 하지만 메모리 안전성(Memory Safety)과 생산성을 중요하게 생각하는 개발자들이 늘어나면서 Rust를 이용한 eBPF 개발도 빠르게 확산되고 있습니다. 이러한 흐름을 대표하는 프로젝트가 바로 Aya입니다. Aya는 Rust만으로 eBPF 프로그램과 사용자 공간 애플리케이션을 모두 개발할 수 있도록 만든 프레임워크입니다. C 언어나 libbpf에 의존하지 않으며, Rust의 강력한 타입 시스템과 메모리 … 더 읽기

eBPF 프로그램을 처음 개발하려고 하면 단순히 C 코드만 작성해서 끝나는 것이 아닙니다. 컴파일 환경을 구성하고, libbpf를 설치하고, Skeleton을 생성하며, Makefile과 사용자 공간(User Space) 프로그램까지 준비해야 합니다. 이러한 초기 설정은 초보자뿐만 아니라 숙련된 개발자에게도 번거로운 작업입니다. 이 문제를 해결하기 위해 libbpf-bootstrap 프로젝트가 만들어졌습니다. libbpf-bootstrap은 eBPF 프로젝트를 빠르게 시작할 수 있도록 제공되는 공식 템플릿(Template) 입니다. 기본적인 디렉터리 … 더 읽기

eBPF가 처음 등장했을 당시에는 프로그램을 커널에 로드하기 위해 개발자가 직접 bpf() 시스템 콜(System Call)을 호출하고, Map 생성, Program 로드, Verifier 처리, Hook 연결까지 모두 구현해야 했습니다. 이러한 방식은 매우 복잡했으며 작은 eBPF 프로그램 하나를 실행하기 위해 수백 줄 이상의 코드가 필요했습니다. 이 문제를 해결하기 위해 Linux Kernel 개발자들은 libbpf라는 공식 라이브러리를 만들었습니다. libbpf는 eBPF 프로그램을 … 더 읽기

eBPF 프로그램을 개발할 때 가장 큰 문제 중 하나는 커널 버전마다 구조체의 레이아웃(Layout)이 달라진다는 점입니다. 예를 들어 task_struct, sock, sk_buff와 같은 커널 구조체는 새로운 커널 버전이 출시될 때마다 필드가 추가되거나 삭제되고, 순서가 변경될 수도 있습니다. 예전에는 이러한 차이 때문에 커널 버전이 바뀔 때마다 eBPF 프로그램을 다시 컴파일해야 했습니다. 이 문제를 해결하기 위해 등장한 기술이 CO-RE(Compile … 더 읽기

eBPF가 처음 등장했을 때 가장 큰 문제 중 하나는 커널 버전마다 내부 구조체(Layout)가 달라진다는 점이었습니다. 예를 들어 task_struct나 sock, sk_buff 같은 커널 구조체는 Linux 버전마다 멤버의 위치나 크기가 달라질 수 있습니다. 따라서 특정 버전에서 컴파일한 eBPF 프로그램은 다른 커널에서 제대로 동작하지 않는 경우가 많았습니다. 이 문제를 해결하기 위해 Linux는 BTF(BPF Type Format) 를 도입했습니다. BTF는 … 더 읽기

초기의 eBPF 프로그램은 Hook에 직접 Attach하는 방식으로 동작했습니다. 이 방식은 구현은 간단했지만 프로그램을 제거하거나 업데이트하는 과정에서 예기치 않은 문제가 발생하는 경우가 많았습니다. 예를 들어 여러 프로그램이 동일한 Hook을 공유하거나 프로그램이 비정상 종료되면 Hook이 제대로 해제되지 않는 문제가 발생할 수 있었습니다. 이러한 문제를 해결하기 위해 Linux Kernel은 eBPF Link라는 개념을 도입했습니다. eBPF Link는 Program과 Hook의 연결 … 더 읽기

Linux에서 eBPF 프로그램과 BPF Map은 모두 커널 내부 객체(Kernel Object)입니다. 이러한 객체는 일반적인 파일처럼 디스크에 저장되는 것이 아니라 커널 메모리에 생성되어 관리됩니다. 하지만 운영 환경에서는 생성된 eBPF Program이나 BPF Map을 여러 프로세스가 공유하거나, 프로그램이 종료된 후에도 계속 사용할 수 있어야 하는 경우가 많습니다. 이를 위해 Linux는 bpffs(BPF File System) 라는 전용 가상 파일 시스템을 제공합니다. … 더 읽기