eBPF 기초와 실무 활용

지원 버전: Linux Kernel 4.18+, Kubernetes 1.25+ 마지막 업데이트: 2026년 2월 23일

eBPF는 Linux 커널 내에서 샌드박스화된 프로그램을 실행할 수 있게 해주는 혁신적인 기술입니다. 이 문서에서는 eBPF의 기본 개념부터 Kubernetes 환경에서의 활용까지 전반적인 내용을 다룹니다.

목차

실습 환경 설정

이 문서의 예제를 따라하기 위해서는 다음과 같은 환경이 필요합니다.

필수 환경

  • Linux 커널 4.18 이상 (5.10+ 권장)

  • bpftool, bcc-tools

  • Kubernetes 클러스터 (선택 사항)

환경 설정


1. eBPF 소개

1.1 eBPF란 무엇인가?

**eBPF(extended Berkeley Packet Filter)**는 Linux 커널 내에서 안전하게 사용자 정의 프로그램을 실행할 수 있게 해주는 기술입니다. 원래 네트워크 패킷 필터링을 위해 설계되었던 BPF를 확장하여, 이제는 네트워킹, 보안, 추적, 성능 분석 등 다양한 영역에서 활용됩니다.

핵심 개념: eBPF를 사용하면 커널 소스 코드를 수정하거나 커널 모듈을 로드하지 않고도 커널의 동작을 확장하고 관찰할 수 있습니다.

spinner

1.2 전통적인 BPF에서 eBPF로의 진화

초기 BPF (1992년):

  • UC 버클리에서 개발

  • 네트워크 패킷 캡처 및 필터링 전용

  • 2개의 32비트 레지스터

  • 최대 4,096개 명령어 제한

eBPF (2014년~):

  • 64비트 아키텍처 지원

  • 11개의 레지스터

  • 맵(Maps)을 통한 상태 저장

  • 다양한 훅 포인트 지원

  • JIT 컴파일을 통한 네이티브 성능

특성
전통적 BPF
eBPF

레지스터

2개 (32비트)

11개 (64비트)

명령어 수

4,096개

100만+

맵 지원

없음

다양한 맵 유형

용도

패킷 필터링

범용 커널 프로그래밍

호출 기능

없음

헬퍼 함수, BPF-to-BPF 호출

상태 저장

불가능

맵을 통해 가능

1.3 eBPF가 혁신적인 이유

eBPF는 다음과 같은 이유로 혁신적입니다:

  1. 커널 수정 없는 기능 확장: 커널 소스 코드를 변경하지 않고도 커널 기능을 확장

  2. 안전한 실행: 검증기가 프로그램의 안전성을 보장

  3. 높은 성능: JIT 컴파일로 네이티브 코드 수준의 성능

  4. 동적 로딩: 재부팅 없이 프로그램 로드/언로드 가능

  5. 프로덕션 안정성: 크래시나 무한 루프 없이 안전하게 실행

spinner

1.4 eBPF vs 커널 모듈 비교

측면
eBPF
커널 모듈

안전성

검증기가 안전성 보장

커널 크래시 가능

이식성

CO-RE로 커널 버전 독립적

커널 버전별 재컴파일 필요

로딩

동적 로드/언로드

insmod/rmmod 필요

권한

CAP_BPF 또는 CAP_SYS_ADMIN

root 권한 필요

디버깅

제한적

전체 커널 디버깅 가능

성능

JIT 컴파일로 최적화

네이티브 성능

기능 범위

정해진 훅 포인트만

무제한

개발 난이도

상대적으로 쉬움

높은 전문성 필요


2. eBPF 아키텍처

2.1 eBPF 실행 흐름

spinner

2.2 검증기 (Verifier)

검증기는 eBPF의 핵심 보안 메커니즘입니다. 프로그램이 커널에서 실행되기 전에 다음 사항을 검증합니다:

검증 항목:

  • 무한 루프 없음 (DAG 구조 확인)

  • 범위를 벗어난 메모리 접근 없음

  • 초기화되지 않은 변수 사용 없음

  • 올바른 헬퍼 함수 호출

  • 프로그램 종료 보장

2.3 JIT 컴파일러

JIT(Just-In-Time) 컴파일러는 eBPF 바이트코드를 네이티브 머신 코드로 변환합니다:

JIT 컴파일 이점:

  • 인터프리터 대비 4~5배 성능 향상

  • 네이티브 CPU 명령어로 직접 실행

  • 아키텍처별 최적화 적용

2.4 eBPF 맵 (Maps)

eBPF 맵은 커널과 사용자 공간 간 데이터를 공유하고 상태를 저장하는 데이터 구조입니다.

주요 맵 유형:

맵 유형
설명
사용 사례

BPF_MAP_TYPE_HASH

해시 테이블

키-값 저장, 연결 추적

BPF_MAP_TYPE_ARRAY

고정 크기 배열

인덱스 기반 접근, 설정 값

BPF_MAP_TYPE_PERF_EVENT_ARRAY

이벤트 배열

사용자 공간으로 이벤트 전송

BPF_MAP_TYPE_RINGBUF

링 버퍼

고성능 이벤트 스트리밍

BPF_MAP_TYPE_LRU_HASH

LRU 해시

캐시, 자동 항목 제거

BPF_MAP_TYPE_PERCPU_ARRAY

CPU별 배열

락 없는 통계 수집

BPF_MAP_TYPE_LPM_TRIE

LPM 트라이

IP 주소 매칭, 라우팅

2.5 헬퍼 함수 (Helper Functions)

eBPF 프로그램은 커널이 제공하는 헬퍼 함수를 통해 커널 기능에 접근합니다.

주요 헬퍼 함수:

2.6 프로그램 라이프사이클

spinner

3. eBPF 프로그램 유형

3.1 XDP (eXpress Data Path)

XDP는 네트워크 드라이버 레벨에서 패킷을 처리하는 가장 빠른 방법입니다.

spinner

XDP 동작 모드:

모드
설명
성능

Native XDP

NIC 드라이버에서 직접 실행

최고

Offloaded XDP

스마트 NIC에서 실행

최고+

Generic XDP

소프트웨어 에뮬레이션

테스트용

3.2 TC (Traffic Control)

TC 프로그램은 네트워크 스택의 트래픽 제어 계층에서 실행됩니다.

TC vs XDP 비교:

특성
XDP
TC

실행 위치

드라이버 레벨

네트워크 스택

성능

최고

높음

SKB 접근

불가

가능

방향

수신만

송수신 모두

패킷 수정

제한적

자유로움

3.3 Kprobes/Uprobes

Kprobes와 Uprobes는 함수 호출을 동적으로 추적합니다.

3.4 Tracepoints

Tracepoints는 커널에 미리 정의된 정적 추적점입니다.

3.5 LSM (Linux Security Module) BPF

LSM BPF는 보안 정책을 동적으로 적용합니다.

3.6 Socket Filter

소켓 레벨에서 패킷을 필터링합니다.

3.7 Cgroup 프로그램

컨테이너의 리소스와 네트워크를 제어합니다.


4. eBPF 개발 도구

4.1 bpftool

bpftool은 eBPF 프로그램과 맵을 관리하는 공식 도구입니다.

4.2 bpftrace

bpftrace는 DTrace 스타일의 고수준 추적 언어입니다.

유용한 bpftrace 원라이너:

4.3 BCC (BPF Compiler Collection)

BCC는 Python과 Lua를 통해 eBPF 프로그램을 작성할 수 있게 해주는 도구입니다.

주요 BCC 도구:

도구
설명

execsnoop

새로운 프로세스 실행 추적

opensnoop

파일 열기 추적

biolatency

블록 I/O 지연 시간

tcpconnect

TCP 연결 추적

tcpaccept

TCP 수신 연결 추적

tcpretrans

TCP 재전송 추적

runqlat

CPU 실행 큐 지연 시간

profile

CPU 프로파일링

funccount

함수 호출 횟수

trace

범용 함수 추적

4.4 libbpf와 CO-RE

libbpf는 eBPF 프로그램 로딩을 위한 C 라이브러리이며, CO-RE(Compile Once, Run Everywhere)를 지원합니다.

CO-RE의 장점:

  • 컴파일된 eBPF 프로그램을 다양한 커널 버전에서 실행

  • BTF(BPF Type Format)를 사용한 구조체 재배치

  • 커널 헤더 의존성 감소

BTF 생성 및 확인:


5. eBPF와 Kubernetes 네트워킹

5.1 Cilium: eBPF 기반 CNI

Cilium은 eBPF를 활용한 가장 대표적인 Kubernetes CNI(Container Network Interface)입니다.

spinner

kube-proxy 대체

Cilium은 eBPF를 사용하여 kube-proxy를 완전히 대체할 수 있습니다.

기존 kube-proxy (iptables 모드):

Cilium eBPF 모드:

네트워크 정책

Cilium은 eBPF를 사용하여 L3/L4/L7 네트워크 정책을 적용합니다.

로드 밸런싱

5.2 Calico eBPF 모드

Calico도 eBPF 데이터플레인을 지원합니다.

Calico eBPF 모드 특징:

  • 소스 IP 보존

  • 직접 서버 리턴 (DSR) 지원

  • 호스트 엔드포인트 정책

  • 암호화된 노드 간 통신

5.3 성능 비교: iptables vs eBPF

측면
iptables
eBPF

확장성

O(n) - 서비스 수에 비례

O(1) - 맵 조회

지연 시간

규칙 수에 따라 증가

일정

CPU 사용량

높음

낮음

업데이트

전체 테이블 재작성

맵 항목 업데이트

관찰성

제한적

Hubble 통합

메모리

규칙당 메모리 사용

최적화된 맵 구조

벤치마크 결과 (1000개 서비스 기준):


6. eBPF 기반 관찰성 (Observability)

eBPF는 시스템과 애플리케이션의 동작을 심층적으로 관찰할 수 있게 해줍니다. 기존의 에이전트 기반 모니터링과 달리, eBPF는 커널 레벨에서 데이터를 수집하여 더 낮은 오버헤드로 더 풍부한 정보를 제공합니다.

6.1 Hubble: Cilium 네트워크 관찰성

Hubble은 Cilium에 내장된 네트워크 관찰성 플랫폼입니다.

spinner

Hubble UI 접속:

6.2 Pixie: 자동 계측 관찰성

Pixie는 eBPF를 사용하여 애플리케이션 코드 수정 없이 자동으로 텔레메트리를 수집합니다.

Pixie 특징:

  • 자동 프로토콜 파싱 (HTTP, gRPC, MySQL, PostgreSQL, Kafka 등)

  • 서비스 맵 자동 생성

  • 분산 추적

  • CPU 프로파일링

  • 동적 로깅

PxL (Pixie Query Language) 예제:

6.3 Coroot: "No-Code" 모니터링

Coroot는 eBPF를 사용하여 추가 설정 없이 자동으로 시스템을 모니터링합니다.

Coroot 기능:

  • 서비스 자동 발견

  • 의존성 맵 자동 생성

  • SLO 모니터링

  • 이상 탐지

  • 근본 원인 분석

6.4 Kepler: 에너지 소비 모니터링

Kepler(Kubernetes-based Efficient Power Level Exporter)는 eBPF를 사용하여 컨테이너의 에너지 소비를 모니터링합니다.

Kepler 메트릭:

  • kepler_container_joules_total: 컨테이너별 에너지 소비

  • kepler_container_gpu_joules_total: GPU 에너지 소비

  • kepler_node_core_joules_total: 노드 CPU 에너지

6.5 기존 에이전트 vs eBPF 계측 비교

측면
기존 에이전트
eBPF 계측

오버헤드

높음 (5-15%)

낮음 (<1%)

코드 수정

필요 (SDK/라이브러리)

불필요

커버리지

계측된 부분만

전체 시스템

배포

애플리케이션별

노드별

권한

일반 권한

CAP_BPF 필요

데이터 깊이

애플리케이션 레벨

커널 레벨

프로토콜 지원

명시적 지원 필요

자동 파싱

spinner

7. eBPF 기반 보안

7.1 Tetragon: 런타임 보안

Tetragon은 Cilium 프로젝트에서 제공하는 eBPF 기반 런타임 보안 솔루션입니다.

spinner

TracingPolicy 예제:

7.2 Falco: eBPF 기반 이상 탐지

Falco는 CNCF 프로젝트로, eBPF를 사용하여 런타임 이상 동작을 탐지합니다.

Falco 규칙 예제:

7.3 seccomp-bpf: 시스템 콜 필터링

seccomp-bpf는 BPF를 사용하여 프로세스가 호출할 수 있는 시스템 콜을 제한합니다.

커스텀 seccomp 프로필:

7.4 LSM BPF: 동적 보안 정책

LSM BPF는 Linux Security Module과 eBPF를 결합하여 동적으로 보안 정책을 적용합니다.


8. eBPF 실전 활용 예제

8.1 bpftrace로 시스템 성능 분석하기

TCP 연결 추적:

시스템 콜 지연 시간 분석:

디스크 I/O 분석:

8.2 Cilium Hubble로 네트워크 흐름 관찰

8.3 Tetragon으로 프로세스 보안 모니터링

파일 접근 모니터링 정책:

8.4 eBPF를 사용한 지연 시간 분석

서비스 응답 시간 측정:

애플리케이션 성능 분석 스크립트:


9. eBPF 제한 사항과 주의점

9.1 기술적 제한 사항

제한 사항
설명

스택 크기

512 bytes

로컬 변수 저장 공간 제한

최대 명령어

100만 개

프로그램 복잡도 제한

최대 중첩 호출

8 레벨

BPF-to-BPF 함수 호출 깊이

맵 항목 수

맵 유형별 상이

메모리 제한에 따름

프로그램 크기

맵 유형별 상이

JIT 컴파일 후 제한

스택 크기 제한 우회:

9.2 루프 제한

eBPF 검증기는 프로그램 종료를 보장하기 위해 루프를 제한합니다.

9.3 커널 버전 호환성

기능
최소 커널 버전

기본 eBPF

3.18

XDP

4.8

BTF

4.18

CO-RE

5.2

BPF 링 버퍼

5.8

BPF 루프

5.3

LSM BPF

5.7

bpf_loop 헬퍼

5.17

9.4 디버깅의 어려움

eBPF 프로그램 디버깅은 전통적인 방법과 다릅니다:

디버깅 방법:

9.5 권한 요구사항

권한
용도

CAP_BPF

eBPF 프로그램 로드 (커널 5.8+)

CAP_SYS_ADMIN

전통적인 eBPF 권한

CAP_PERFMON

성능 모니터링 이벤트 연결

CAP_NET_ADMIN

XDP/TC 프로그램 연결

Kubernetes에서의 권한 설정:

9.6 보안 고려사항

eBPF는 강력한 도구이지만 보안 위험도 존재합니다:

  • 정보 유출: 민감한 데이터에 접근 가능

  • DoS 공격: 성능 저하 유발 가능

  • 권한 상승: 잘못된 설정 시 취약점 발생 가능

보안 모범 사례:


10. 다음 단계

10.1 관련 퀴즈

이 문서의 내용을 확인하려면 다음 퀴즈를 풀어보세요:

10.2 심화 학습 자료

공식 문서 및 리소스:

실습 환경:

커뮤니티:

10.3 관련 문서

이 문서와 관련된 심화 내용은 다음 문서를 참고하세요:

주제
문서 링크
설명

Cilium 소개

eBPF 기반 CNI 소개

eBPF 심층 분석

고급 eBPF 기술

네트워킹

eBPF 네트워킹 구현

보안

eBPF 기반 보안

Kubernetes 네트워킹

기본 네트워킹 개념

10.4 실습 체크리스트

eBPF 학습을 위한 실습 체크리스트:


요약

eBPF는 Linux 커널의 동작을 안전하게 확장하고 관찰할 수 있게 해주는 혁신적인 기술입니다. 이 문서에서 다룬 핵심 내용을 정리하면:

  1. eBPF 기본 개념: 커널 내에서 안전하게 실행되는 샌드박스 프로그램

  2. 아키텍처: 검증기, JIT 컴파일러, 맵, 헬퍼 함수로 구성

  3. 프로그램 유형: XDP, TC, Kprobes, Tracepoints, LSM BPF 등

  4. 개발 도구: bpftool, bpftrace, BCC, libbpf

  5. Kubernetes 활용: Cilium, Calico eBPF 모드로 고성능 네트워킹

  6. 관찰성: Hubble, Pixie, Coroot를 통한 깊은 시스템 관찰

  7. 보안: Tetragon, Falco, seccomp-bpf를 통한 런타임 보안

  8. 제한 사항: 스택 크기, 루프, 커널 버전 호환성 고려 필요

eBPF는 클라우드 네이티브 환경에서 네트워킹, 보안, 관찰성의 미래를 이끌어가는 핵심 기술입니다.

마지막 업데이트