eBPF 프로그램 성능 튜닝 — 맵 조회 비용을 줄이는 실전 기법

관측성 도구를 붙였더니 관측 대상보다 도구가 CPU를 더 쓰는 상황을 본 적이 있다. 초당 수백만 번 호출되는 훅에서 해시맵을 세 번 조회하고 있었다. 문제를 찾고 나니 해결은 단순했다. 조회 결과를 재사용하고, 일부를 per-CPU 구조로 바꾸는 것으로 CPU 사용률이 크게 떨어졌다.

비용이 어디서 나오는지 이해하기

# BPF 프로그램 통계 켜기 (측정 시에만)
sudo sysctl -w kernel.bpf_stats_enabled=1

# 프로그램별 실행 횟수와 누적 시간 확인
sudo bpftool prog show
#  12: kprobe  name trace_sys_enter  tag abc...
#      run_time_ns 4821330012 run_cnt 91234567
#      → 호출당 평균 약 52ns

sudo sysctl -w kernel.bpf_stats_enabled=0

# 맵 사용 현황
sudo bpftool map show
sudo bpftool map dump id 7 | head

기법 1 — per-CPU 맵으로 경합 제거

여러 CPU가 같은 맵 항목을 갱신하면 동기화 비용이 든다. 카운터처럼 합산만 하면 되는 값은 per-CPU 맵에 각 CPU가 독립적으로 쌓고, 읽을 때 합치면 된다.

// 경합이 생기는 방식
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __type(key, u32);
    __type(value, u64);
    __uint(max_entries, 1024);
} counts SEC(".maps");
// 여러 CPU가 같은 키를 갱신 → 원자 연산 비용

// per-CPU 방식: 각 CPU가 자기 슬롯에만 쓴다
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_HASH);
    __type(key, u32);
    __type(value, u64);
    __uint(max_entries, 1024);
} counts SEC(".maps");

// 유저 공간에서 읽을 때 CPU 수만큼 값을 받아 합산한다.
// 트레이드오프: 메모리 사용이 CPU 수만큼 늘어난다.

기법 2 — 조회 결과 메모이제이션

같은 키에 대한 조회가 반복된다면 결과를 재사용할 수 있다. 특히 프로세스 정보나 컨테이너 식별자처럼 짧은 시간 동안 변하지 않는 값이 대상이다.

// per-CPU 배열을 1칸짜리 캐시로 사용
struct cache_entry { u64 key; u64 value; u64 ts; };

struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __type(key, u32);
    __type(value, struct cache_entry);
    __uint(max_entries, 1);
} last SEC(".maps");

static __always_inline u64 lookup_cached(u64 key) {
    u32 zero = 0;
    struct cache_entry *c = bpf_map_lookup_elem(&last, &zero);
    if (c && c->key == key && (bpf_ktime_get_ns() - c->ts) < 1000000000ULL) {
        return c->value;                  // 캐시 적중 — 비싼 조회 생략
    }
    u64 v = expensive_lookup(key);        // 실제 조회
    if (c) { c->key = key; c->value = v; c->ts = bpf_ktime_get_ns(); }
    return v;
}

작업 부하에 시간적 지역성이 있으면(같은 프로세스의 이벤트가 연속으로 오면) 적중률이 매우 높다. 반대로 키가 매번 달라지는 워크로드에서는 캐시 검사 비용만 추가되므로 실측이 필요하다.

기법 3 — 커널에서 집계하고 적게 내보내기

가장 큰 절감은 유저 공간으로 보내는 이벤트를 줄이는 것에서 나온다. 이벤트 하나를 전달하는 비용은 맵 조회 수십 번에 맞먹는다.

// 히스토그램을 커널에서 만들고 주기적으로만 읽는다
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __type(key, u32);
    __type(value, u64);
    __uint(max_entries, 64);          // log2 버킷
} hist SEC(".maps");

static __always_inline void record(u64 delta_ns) {
    u32 slot = log2l(delta_ns);
    if (slot >= 64) slot = 63;
    u64 *cnt = bpf_map_lookup_elem(&hist, &slot);
    if (cnt) (*cnt)++;                // 이벤트 전달 없음
}
// 유저 공간은 1초에 한 번 맵 전체를 읽어 집계한다.

기법 4 — 샘플링과 조기 반환

모든 이벤트가 필요하지 않은 경우가 많다. 훅 진입 직후 필터링해서 빠르게 반환하면, 나머지 로직 비용을 통째로 아낄 수 있다.

SEC("tracepoint/syscalls/sys_enter_read")
int on_read(void *ctx) {
    // 1) 가장 싼 조건부터 검사하고 즉시 반환
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    if (pid == self_pid) return 0;             // 자기 자신 제외

    // 2) 샘플링 — 전수 수집이 필요 없다면
    if ((bpf_get_prandom_u32() & 0x3F) != 0)   // 1/64 확률
        return 0;

    // 3) 비싼 작업은 여기서부터
    do_expensive_work(ctx);
    return 0;
}

기법 5 — 링버퍼와 perf 버퍼 선택

개별 이벤트를 꼭 보내야 한다면 전달 수단도 성능에 영향을 준다. 링버퍼는 CPU별 버퍼를 따로 두지 않고 공유하며, 예약-커밋 방식으로 복사를 줄일 수 있다.

// 링버퍼: 예약 후 직접 쓰기 (중간 복사 제거)
struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 1 << 22);          // 4MB
} events SEC(".maps");

struct event { u64 ts; u32 pid; u32 len; };

SEC("kprobe/...")
int probe(void *ctx) {
    struct event *e = bpf_ringbuf_reserve(&events, sizeof(*e), 0);
    if (!e) return 0;                       // 버퍼 가득 — 드롭 카운터 증가 권장
    e->ts = bpf_ktime_get_ns();
    e->pid = bpf_get_current_pid_tgid() >> 32;
    e->len = 0;
    bpf_ringbuf_submit(e, 0);
    return 0;
}

검증 — 개선을 어떻게 확인하나

마지막 항목은 성능이 아니라 운영 문제다. 프로그램이 복잡해지면 verifier 검증이 오래 걸리고, 커널 버전에 따라 거부될 수 있다. 최적화가 이식성을 깎지 않는지도 함께 봐야 한다.

자주 묻는 질문

eBPF 프로그램의 오버헤드를 어떻게 측정하나요?

kernel.bpf_stats_enabled를 켠 뒤 bpftool prog show로 실행 횟수와 누적 실행 시간을 확인하면 호출당 평균 비용을 계산할 수 있습니다. 측정 자체에 약간의 오버헤드가 있으므로 확인 후에는 끄는 것이 좋습니다.

per-CPU 맵은 언제 쓰나요?

여러 CPU가 같은 키를 갱신하는 카운터나 누적값에 적합합니다. 각 CPU가 자기 슬롯에만 쓰므로 경합이 사라지고, 유저 공간에서 읽을 때 합산합니다. 대신 메모리 사용량이 CPU 수만큼 늘어납니다.

맵 조회를 캐싱해도 되나요?

짧은 시간 동안 변하지 않는 값이고 접근에 시간적 지역성이 있다면 효과적입니다. per-CPU 배열에 최근 조회 결과를 두고 유효 시간을 짧게 잡는 방식이 일반적입니다. 키가 매번 달라지는 워크로드에서는 오히려 손해일 수 있으니 실측하세요.

가장 큰 절감은 어디서 나오나요?

유저 공간으로 보내는 이벤트를 줄이는 것입니다. 커널에서 히스토그램이나 카운터로 집계한 뒤 주기적으로 읽어 가면 전달 횟수가 수천분의 1로 줄어듭니다. 개별 이벤트는 인과 추적이 필요한 경우에만 사용하세요.

샘플링을 하면 데이터가 부정확해지지 않나요?

통계적 분포를 보는 목적에는 충분한 경우가 많습니다. 다만 희귀 이벤트 탐지나 인과 추적에는 적합하지 않으므로, 목적에 따라 전수 수집 구간과 샘플링 구간을 나누는 설계가 필요합니다.

링버퍼와 perf 버퍼 중 무엇을 쓸까요?

신규 구현이라면 링버퍼가 기본 선택지입니다. 공유 버퍼로 메모리 효율이 좋고 이벤트 순서가 보장되며, 예약-커밋 방식으로 중간 복사를 줄일 수 있습니다. CPU별 독립 처리가 꼭 필요한 경우에만 perf 버퍼를 고려하세요.