초기의 eBPF 프로그램은 Hook에 직접 Attach하는 방식으로 동작했습니다. 이 방식은 구현은 간단했지만 프로그램을 제거하거나 업데이트하는 과정에서 예기치 않은 문제가 발생하는 경우가 많았습니다.
예를 들어 여러 프로그램이 동일한 Hook을 공유하거나 프로그램이 비정상 종료되면 Hook이 제대로 해제되지 않는 문제가 발생할 수 있었습니다.
이러한 문제를 해결하기 위해 Linux Kernel은 eBPF Link라는 개념을 도입했습니다.
eBPF Link는 Program과 Hook의 연결 자체를 하나의 객체(Object)로 관리하는 기능입니다. Link를 사용하면 프로그램의 연결과 해제를 더욱 안전하고 일관성 있게 처리할 수 있습니다.
이번 글에서는 eBPF Link의 개념과 구조, 동작 원리, 기존 Attach 방식과의 차이, Link Pinning, 실무 활용 방법을 자세히 알아보겠습니다.
Linux eBPF Link란?
eBPF Link는 eBPF Program과 Kernel Hook을 연결하는 독립적인 커널 객체입니다.
기본 구조는 다음과 같습니다.
eBPF Program
↓
BPF Link
↓
Kernel Hook
↓
Event 발생
↓
Program 실행
과거에는 Program이 직접 Hook에 연결되었지만, 현재는 Link 객체를 통해 연결하는 것이 권장됩니다.
eBPF Link가 필요한 이유
기존 방식에서는 다음과 같은 문제가 있었습니다.
- 프로그램 종료 시 Hook 정리 어려움
- 강제 종료 시 Attach 정보 누락
- 여러 Program 관리 복잡
- Hook 교체 과정의 안정성 부족
Link 객체는 이러한 문제를 해결하기 위해 도입되었습니다.
기존 Attach 방식
예전 구조는 다음과 같았습니다.
Program
↓
Attach
↓
Hook
Program이 제거되면 Hook 관리도 함께 처리해야 했습니다.
이 과정에서 관리가 복잡해질 수 있었습니다.
Link 방식
현재 권장 방식입니다.
Program
↓
Link
↓
Hook
Hook 연결을 Link 객체가 담당합니다.
Program과 Hook이 느슨하게 연결되어 관리가 훨씬 쉬워졌습니다.
Link 생성 과정
전체 흐름은 다음과 같습니다.
Program Load
↓
Verifier
↓
Link 생성
↓
Hook 연결
↓
Running
Program과 Link는 서로 다른 Kernel Object입니다.
Link 객체의 특징
Link는 다음과 같은 특징을 가집니다.
- Kernel Object
- File Descriptor 제공
- Pinning 가능
- 자동 해제 지원
- 여러 Hook 지원
- 안전한 Attach 관리
현대적인 eBPF 개발에서는 대부분 Link를 사용합니다.
지원하는 Hook
대표적으로 다음 Hook에서 Link를 사용할 수 있습니다.
- XDP
- Tracepoint
- Kprobe
- Uprobe
- Cgroup
- LSM
- Perf Event
Kernel 버전에 따라 지원 범위는 조금씩 달라질 수 있습니다.
libbpf에서 Link 사용
Skeleton에서는 Link 생성이 자동으로 이루어집니다.
예를 들어
example_bpf__attach(skel);
를 호출하면 내부적으로
- Link 생성
- Hook 연결
- Link 관리
를 모두 자동으로 수행합니다.
개발자가 Link를 직접 생성할 필요가 없는 경우가 많습니다.
Link Pinning
Program뿐 아니라 Link도 Pinning할 수 있습니다.
예를 들어
sudo bpftool link pin id 3 /sys/fs/bpf/xdp_link
이후
/sys/fs/bpf/xdp_link
경로에서 Link를 관리할 수 있습니다.
Link 자체를 유지할 수 있기 때문에 운영 환경에서 매우 유용합니다.
Link 확인
현재 생성된 Link 확인
sudo bpftool link show
출력 예시
1: tracing
2: xdp
3: kprobe
Link의 종류와 상태를 확인할 수 있습니다.
Link 제거
Link를 제거하면 Hook도 함께 해제됩니다.
예를 들어
sudo rm /sys/fs/bpf/xdp_link
또는
sudo bpftool link detach id 3
를 사용할 수 있습니다.
Program 자체는 그대로 유지될 수도 있으며, Hook 연결만 해제됩니다.
기존 방식과 Link 방식 비교
| 항목 | 기존 Attach | Link 방식 |
|---|---|---|
| Hook 관리 | 직접 | Link 객체 |
| 자동 정리 | 제한적 | 지원 |
| Pinning | 제한적 | 가능 |
| 유지보수 | 복잡 | 쉬움 |
| 안정성 | 보통 | 매우 높음 |
Link 방식이 현재 표준으로 권장됩니다.
Link와 Program의 차이
| 객체 | 역할 |
|---|---|
| Program | 실행되는 코드 |
| Map | 데이터 저장 |
| Link | Hook 연결 |
| BTF | 타입 정보 |
| bpffs | 객체 관리 |
Link는 Program을 대신하는 것이 아니라 연결만 담당합니다.
실무에서 자주 사용하는 명령어
Link 목록 확인
sudo bpftool link show
Program 확인
sudo bpftool prog show
Map 확인
sudo bpftool map show
Link Pin
sudo bpftool link pin id 3 /sys/fs/bpf/demo_link
Pinned Link 확인
sudo bpftool link show pinned /sys/fs/bpf/demo_link
bpffs 확인
ls -l /sys/fs/bpf
실무 사례
예를 들어 XDP 기반 DDoS 방어 시스템을 운영한다고 가정해 보겠습니다.
운영 중 새로운 버전의 eBPF 프로그램을 배포해야 하는 상황이라면 다음과 같은 순서로 작업할 수 있습니다.
- 새로운 eBPF Program을 커널에 로드
- 새로운 Link를 생성하여 동일한 Hook에 연결
- 기존 Link를 안전하게 제거
- 기존 Program 정리
- 서비스 중단 없이 새로운 프로그램 적용
이처럼 Link를 사용하면 Program과 Hook을 독립적으로 관리할 수 있어 업데이트와 롤백이 훨씬 안전해집니다.
자주 묻는 질문
Link와 Program은 같은 객체인가요?
아닙니다. Program은 실행되는 eBPF 코드이고, Link는 Program과 Hook을 연결하는 별도의 커널 객체입니다.
모든 Program Type이 Link를 지원하나요?
대부분의 최신 Program Type은 Link를 지원하지만, 일부 오래된 Hook이나 커널 버전에서는 지원하지 않을 수 있습니다. 사용하는 커널 버전의 지원 여부를 확인하는 것이 좋습니다.
Link를 Pinning하는 이유는 무엇인가요?
Link를 Pinning하면 Hook 연결 상태를 유지하고 여러 관리 도구에서 동일한 Link를 재사용할 수 있습니다. 특히 장기간 운영되는 서비스에서 관리가 편리해집니다.
마무리
Linux eBPF Link는 Program과 Hook을 안전하게 연결하기 위한 독립적인 커널 객체입니다. 기존 Attach 방식보다 안정성과 유지보수성이 뛰어나며, Pinning과 함께 사용하면 운영 환경에서도 효율적으로 eBPF 프로그램을 관리할 수 있습니다. 최신 eBPF 개발에서는 Link 기반 연결 방식이 사실상의 표준으로 자리 잡고 있으므로 반드시 이해하고 활용하는 것이 좋습니다.