본문으로 건너뛰기
DevOpsMar 28, 2026

제로 계측 관측 가능성: eBPF가 Sidecar 함대를 대체한 방법

OS
Open Soft Team

Engineering Team

67%의 Kubernetes 팀이 eBPF 관측 가능성으로 전환

CNCF 2026 연간 설문조사에 따르면 67%의 Kubernetes 팀이 관측 가능성의 최소 하나의 기둥(메트릭, 트레이스 또는 로그)에 eBPF 기반 도구를 사용합니다 — 2024년 29%, 2025년 41%에서 증가. 이 전환은 더 이상 점진적이지 않습니다.

이유는 간단합니다: 전통적인 sidecar 기반 관측 가능성(Envoy 프록시, OpenTelemetry Collector sidecar, Datadog 에이전트)은 막대한 리소스를 소비하고, 모든 요청에 지연을 추가하며, 계측에 코드 변경이나 컨테이너 수정이 필요합니다. eBPF는 커널에서 모든 것을 수행합니다 — 애플리케이션 변경 제로.

eBPF란 무엇이며 왜 중요한가

eBPF(extended Berkeley Packet Filter)는 커널 소스 코드를 변경하거나 커널 모듈을 로드하지 않고 샌드박스 프로그램을 Linux 커널 내에서 실행할 수 있게 하는 기술입니다.

작동 방식

  1. 작은 프로그램 작성 — C 또는 Rust로(또는 고수준 프레임워크 사용)
  2. 커널 훅 포인트에 연결 — 시스콜, 네트워크 이벤트, 트레이스포인트, 함수 진입/종료
  3. 커널의 eBPF 검증기가 안전성 확인(무한 루프 없음, 범위 외 접근 없음)
  4. JIT 컴파일러가 eBPF 바이트코드를 네이티브 머신 명령으로 변환
  5. 프로그램 실행 — 훅 포인트에서 거의 네이티브 성능으로
// HTTP 요청을 추적하는 간단한 eBPF 프로그램
SEC("kprobe/tcp_v4_connect")
int trace_connect(struct pt_regs *ctx) {
    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
    
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    u16 dport = sk->__sk_common.skc_dport;
    u32 daddr = sk->__sk_common.skc_daddr;
    
    struct event_t event = {
        .pid = pid,
        .dport = ntohs(dport),
        .daddr = daddr,
        .timestamp = bpf_ktime_get_ns(),
    };
    
    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
                          &event, sizeof(event));
    return 0;
}

관측 가능성에 왜 중요한가

전통적인 관측 가능성은 계측이 필요합니다. 이 접근 방식에는 세 가지 근본적인 문제가 있습니다:

  1. 리소스 오버헤드 — 각 sidecar가 CPU와 메모리를 소비. Envoy sidecar가 있는 500 pod 클러스터에서 sidecar 자체가 클러스터 총 리소스의 30-40%를 소비할 수 있음.
  2. 커버리지 갭 — 계측한 것만 관찰 가능. 서드파티 바이너리, 커널 레벨 이벤트는 블라인드 스팟.
  3. 유지보수 부담 — 모든 언어, 프레임워크, 런타임에 각각의 계측 라이브러리 필요.

eBPF는 세 가지 모두 해결합니다: 커널에서 실행(애플리케이션 오버헤드 제로), 커널이 보는 모든 것을 봅니다(갭 없음), 언어나 프레임워크에 관계없이 작동합니다.

2026년 eBPF 관측 가능성 스택

Cilium + Hubble: 네트워크 관측 가능성

Cilium은 Kubernetes의 사실상 표준 CNI. Hubble은 다음을 제공합니다:

  • L3/L4 플로우 가시성 — pod 간의 모든 TCP/UDP 연결
  • L7 프로토콜 파싱 — HTTP, gRPC, Kafka, DNS, PostgreSQL(앱 변경 없이)
  • 네트워크 정책 감사 — 실시간으로 트래픽 허용/거부 정책 확인
  • 서비스 의존성 매핑 — 관찰된 트래픽 패턴 기반 자동 서비스 그래프 생성

Pixie: 애플리케이션 성능 모니터링

Pixie(CNCF 샌드박스 프로젝트)는 eBPF로 제로 계측 APM 제공:

  • 자동 프로토콜 트레이싱 — HTTP/1.1, HTTP/2, gRPC, PostgreSQL, MySQL, Redis, Kafka, DNS
  • 지속적 CPU 프로파일링 — eBPF 스택 트레이스의 플레임 그래프
  • 동적 로깅 — 재배포 없이 실행 중인 앱에 트레이스포인트 추가
  • 전체 요청/응답 캡처 — 실제 HTTP 헤더, SQL 쿼리, gRPC 페이로드 확인

Tetragon: 런타임 보안 및 감사

Tetragon(Isovalent/Cilium)은 eBPF 기반 보안 관측 가능성 도구:

  • 프로세스 실행 추적 — 모든 exec, fork, exit 이벤트
  • 파일 접근 모니터링 — 읽기, 쓰기, 권한 변경 추적
  • 네트워크 연결 감사 — 프로세스 컨텍스트와 함께 모든 아웃바운드 연결 로그
  • 보안 정책 적용 — 실시간으로 의심스러운 활동 차단

Grafana Beyla: 자동 계측

Grafana Beyla는 eBPF 기반 자동 계측 에이전트:

  • 커널 레벨에서 HTTP, gRPC, SQL, Redis 요청 감지
  • 트레이스 컨텍스트 전파가 포함된 OpenTelemetry 스팬 발행
  • Grafana Cloud, Tempo, Mimir 및 모든 OpenTelemetry 백엔드와 통합

성능: 중요한 숫자들

500 pod 프로덕션 Kubernetes 클러스터의 실제 벤치마크:

메모리 사용량 비교

컴포넌트Sidecar 접근법eBPF 접근법절감
Envoy sidecar(500 pod)50 GB0(Cilium CNI)50 GB
OTel Collector sidecar(500 pod)15 GB0(Beyla DaemonSet)15 GB
Cilium 에이전트(20 노드)N/A8 GB-8 GB
Beyla 에이전트(20 노드)N/A2 GB-2 GB
합계75 GB12 GB84% 감소

CPU 오버헤드

지표Sidecar 접근법eBPF 접근법
요청당 추가 지연1-5ms<0.1ms
노드당 CPU 오버헤드8-12%<1%
테일 지연 영향(p99)+15-30ms<1ms

마이그레이션 가이드: Sidecar에서 eBPF로

1단계: Sidecar와 함께 eBPF 도구 배포(1-2주차)

  • Cilium을 CNI로 설치
  • Hubble을 네트워크 관측 가능성용으로 배포
  • Beyla를 DaemonSet으로 배포
  • sidecar와 eBPF 관측 가능성을 병렬 운영

2단계: 검증 및 튜닝(3-4주차)

  • eBPF 도구가 동일한 신호를 캡처하는지 확인
  • Beyla의 프로토콜 감지 조정
  • 기존 sidecar 대시보드를 미러링하는 대시보드 설정

3단계: Sidecar 점진적 제거(5-8주차)

  • 비핵심 서비스부터 시작: OTel Collector sidecar 제거
  • 데이터 품질 회귀 모니터링
  • 고급 트래픽 관리가 필요 없는 서비스에서 Envoy sidecar 제거

4단계: 전체 eBPF 스택(9-12주차)

  • 나머지 sidecar 제거
  • Tetragon을 런타임 보안용으로 배포
  • eBPF 기반 신호로 알림 통합
  • 해제된 리소스 회수

자주 묻는 질문

eBPF 관측 가능성은 비Kubernetes 워크로드에도 작동하나요?

네. eBPF는 Linux 커널 레벨에서 실행되므로 컨테이너, VM, 베어메탈, systemd 서비스 등 모든 워크로드에 작동합니다.

eBPF가 분산 트레이싱을 대체할 수 있나요?

많은 팀에게는 그렇습니다. 하지만 eBPF 트레이스는 요청/응답 경계에 제한됩니다. 함수 내의 커스텀 비즈니스 로직 트레이싱에는 여전히 SDK 계측이 필요합니다.

암호화된 트래픽(TLS)은 어떻게 되나요?

eBPF 도구는 TLS 라이브러리 함수(예: OpenSSL의 SSL_read 및 SSL_write)에 연결하여 TLS 트래픽을 추적할 수 있습니다.

eBPF는 안전한가요? 버그가 있는 eBPF 프로그램이 커널을 크래시시킬 수 있나요?

아니요. eBPF 검증기가 로드 전에 모든 프로그램을 검사합니다. 버그가 있는 프로그램은 로드에 실패하지만 커널을 크래시시키지는 않습니다.

eBPF는 고처리량 서비스(100K+ 요청/초)를 어떻게 처리하나요?

eBPF는 커널 내 집계와 샘플링으로 고처리량을 처리합니다. eBPF 프로그램은 커널 맵에서 히스토그램과 카운터를 계산하여 집계 데이터만 사용자 공간으로 전송합니다.

태그
DevOpsDockerKubernetes