eBPF — 커널을 재컴파일 없이 확장하는 기술
eBPF는 "커널을 재컴파일하지 않고도 커널 기능을 확장"할 수 있는 혁신적인 기술입니다. Cilium, Falco, bpftrace 등 현대 인프라 도구의 핵심 기반입니다.
eBPF란
eBPF(extended Berkeley Packet Filter)는 리눅스 커널 내에서 샌드박스된 프로그램을 실행하는 기술 입니다.
기존: 커널 기능 추가/변경 → 커널 모듈 작성 or 커널 소스 수정 + 재컴파일
eBPF: 커널 수정 없이 → eBPF 프로그램을 커널에 로드 → 커널 이벤트에 반응
동작 원리
사용자 공간 커널 공간
┌──────────────┐ ┌──────────────────┐
│ eBPF 프로그램 │ │ │
│ (C로 작성) │ │ eBPF 가상 머신 │
│ │ │ │ ┌────────────┐ │
│ LLVM/Clang │ │ │ 검증기 │ │
│ │ │ │ │ (Verifier) │ │
│ BPF 바이트코드│────로드────→│ └──────┬─────┘ │
│ │ │ │ │
│ │ │ ┌──────▼─────┐ │
│ │ │ │ JIT 컴파일 │ │
│ │ │ │ → 네이티브코드│ │
│ │ │ └──────┬─────┘ │
│ │ │ │ │
│ BPF 맵 │◄──데이터───→│ 커널 이벤트에 │
│ (결과 읽기) │ │ 부착(attach) │
└──────────────┘ └──────────────────┘
- C로 eBPF 프로그램 작성
- LLVM/Clang으로 BPF 바이트코드로 컴파일
- 커널에 로드 → 검증기(Verifier) 가 안전성 검사
- JIT 컴파일러가 네이티브 코드로 변환
- 커널 이벤트(시스템 콜, 네트워크 패킷 등)에 부착
- BPF 맵으로 커널-유저 공간 데이터 공유
검증기 (Verifier)의 역할
eBPF 프로그램이 커널을 크래시시키지 않도록 보장합니다:
- 무한 루프 없음 (루프 횟수 제한)
- 범위 밖 메모리 접근 없음
- 허용된 헬퍼 함수만 호출
- 프로그램 크기 제한
주요 활용 사례
1. 관측 가능성 (Observability)
# bpftrace로 시스템 콜 추적
bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("%s %s\n", comm, str(args->filename)); }'
# 특정 함수의 지연 시간 측정
bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; }
kretprobe:vfs_read /@start[tid]/ { @ns = hist(nsecs - @start[tid]); delete(@start[tid]); }'
2. 네트워킹
Cilium: Kubernetes 네트워킹을 eBPF로 구현합니다.
- iptables 대체 — 성능 10배 이상 향상
- 서비스 메시 기능을 커널 레벨에서 처리
3. 보안
Falco: eBPF로 시스템 콜을 모니터링하여 보안 위협 탐지
- 컨테이너 내부의 의심스러운 프로세스 실행 감지
- 파일 시스템 접근 모니터링
eBPF vs 커널 모듈
| 항목 | eBPF | 커널 모듈 |
|---|---|---|
| 안전성 | 검증기가 보장 | 버그로 커널 크래시 가능 |
| 로드/언로드 | 동적, 즉시 | 동적이지만 위험 |
| 커널 버전 호환 | CO-RE로 이식성 확보 | 버전마다 재컴파일 |
| 성능 | JIT → 네이티브에 가까움 | 네이티브 |
| 권한 | 제한적 (허용된 API만) | 모든 커널 API 접근 |
핵심 포인트
- eBPF가 안전한 이유: 검증기(Verifier)가 로드 전에 프로그램 안전성 검사
- 커널 모듈 대비 장점: 커널 크래시 위험 없음, 동적 로드/언로드
- 활용: Cilium(K8s 네트워킹), Falco(보안), bpftrace(디버깅)
정리
eBPF는 "커널 프로그래밍의 JavaScript"라고 불릴 만큼, 커널 확장을 안전하고 쉽게 만들어주는 기술입니다. 클라우드 네이티브 환경에서 네트워킹, 보안, 관측 가능성의 핵심 기술로 자리 잡았습니다.