“운영 중인 시스템에 안전하게 커널 코드를 삽입한다?” 얼핏 들으면 위험한 이야기처럼 보이지만, 바로 이 지점이 eBPF가 클라우드 네이티브 관측(Observability)과 보안에서 혁신으로 평가받는 이유입니다. 특히 최근에는 eBPF로 수집한 프로파일 데이터를 OpenTelemetry 표준(OTLP) 파이프라인에 얹는 스택이 빠르게 확산되며, Software Infra의 핵심 트렌드로 떠올랐습니다.
eBPF가 ‘운영 중 삽입’이 가능한 이유: 커널 확장 모델의 변화 (Software Infra)
기존 커널 확장은 커널 모듈처럼 “잘못 올리면 시스템을 죽일 수 있는” 방식이었습니다. 반면 eBPF는 커널 안에서 실행되긴 하지만, 아무 코드나 실행되지 않습니다.
- eBPF 프로그램은 커널에 로드되기 전에 verifier(검증기)가 정적 분석을 수행합니다.
- 불법 메모리 접근, 무한 루프 가능성, 안정성을 해칠 수 있는 패턴이 감지되면 로드를 거부합니다.
- 덕분에 운영 환경에서도 비교적 안전하게 “핫 패치”처럼 배포할 수 있고, 관측/보안 기능을 커널 레벨로 끌어올릴 수 있습니다.
이 “안전장치가 있는 커널 실행 환경”이라는 특성이, eBPF를 단순 패킷 필터가 아니라 범용 Software Infra 관측 런타임으로 만든 출발점입니다.
왜 ‘프로파일링’이 지금 더 중요해졌나: 4-Pillar Observability의 마지막 퍼즐 (Software Infra)
대부분의 조직은 이미 metrics, logs, traces는 어느 정도 갖추고 있습니다. 하지만 성능 장애의 본질은 종종 이렇게 남습니다.
- CPU가 왜 90%인지(어떤 함수/락/GC가 원인인지)
- 특정 노드에서만 지연이 생기는 이유가 커널/런타임/라이브러리 중 어디인지
- 컨테이너 경계 너머(호스트 커널, 다른 프로세스, 스케줄러)에서 무슨 일이 벌어지는지
이때 필요한 게 profiles(프로파일) 입니다. 프로파일은 “어디에서 시간을 쓰는지”를 함수/스택 단위로 보여주기 때문에, 트레이스만으로는 놓치는 핫스팟과 병목을 직접 겨냥합니다. 최근 Software Infra가 4-pillar(메트릭·로그·트레이스·프로파일)로 수렴하는 이유도 여기에 있습니다.
eBPF + OpenTelemetry 조합이 강력한 이유: ‘수집’과 ‘표준화’를 동시에 해결 (Software Infra)
프로파일링은 도입이 어렵습니다. 언어별 에이전트, 애플리케이션 수정, 배포 부담이 생기기 때문입니다. eBPF 기반 프로파일링은 이 진입장벽을 크게 낮춥니다.
- 애플리케이션 수정 없이 커널 이벤트(예: perf 기반 샘플링)를 이용해 스택 트레이스를 수집할 수 있습니다.
- 쿠버네티스에서는 노드마다 DaemonSet 형태로 배포해 클러스터 전역을 관측합니다.
- 그리고 OpenTelemetry와 결합되면, 수집된 프로파일이 OTLP라는 표준 포맷으로 흘러가면서 관측 파이프라인이 통합됩니다.
최근 Dash0 Operator가 otelcol-ebpf-profiler 같은 특수화된 OpenTelemetry Collector를 활용해 eBPF 프로파일링 파이프라인을 제공하는 것도, 이 “표준 파이프라인으로의 흡수”가 시장에서 요구되고 있음을 보여줍니다.
‘모든 걸 볼 수 있다’는 건 권한이 필요하다는 뜻: 주목과 동시에 경계가 커지는 이유 (Software Infra)
eBPF 기반 프로파일러는 노드 전체를 관측하기 위해 다음과 같은 운영 특성을 가집니다.
- 커널 5.4+ 등 커널 요건이 필요하고,
/proc,/sys접근 및 호스트 프로세스 관측을 위해hostPID: true,- privileged 또는
CAP_BPF,CAP_PERFMON,CAP_SYS_ADMIN같은 강한 권한을 요구하는 경우가 많습니다.
즉, Software Infra 관점에서 eBPF는 “가시성을 극대화하는 기술”이면서 동시에 “강력한 권한을 다루는 기술”입니다. 그래서 Atomic Arch처럼 eBPF가 루트킷의 은폐 수단으로도 쓰일 수 있다는 사례가 등장하면서, eBPF는 이제 관측 도구이자 보안 거버넌스의 대상이 되었습니다.
결론: eBPF 프로파일링은 ‘차세대 운영 기본기’가 되고 있다 (Software Infra)
지금 eBPF 기반 OpenTelemetry 프로파일링이 주목받는 이유는 명확합니다.
- 운영 중에도 비교적 안전하게 커널 레벨 관측을 추가할 수 있고
- 애플리케이션 변경 없이 클러스터 전반의 성능 병목을 찾을 수 있으며
- OpenTelemetry로 표준화되어 기존 관측 파이프라인과 자연스럽게 합쳐지고
- 동시에 강한 권한을 요구하는 만큼, 보안/공급망/정책과 함께 설계해야 하기 때문입니다.
결국 eBPF는 “더 많이 보는 기술”을 넘어, 복잡해진 클라우드 네이티브 환경에서 Software Infra 팀이 성능과 보안을 동시에 운영 가능한 수준으로 끌어올리는 기반 레이어로 자리 잡고 있습니다.
Software Infra에서 보는 OpenTelemetry eBPF Profiler와 Dash0 Operator의 기술 내부 이야기
리눅스 커널 5.4 이상에서 어떻게 ‘호스트 전체 프로세스’를 한눈에 보고, CPU와 메모리 병목 현상까지 ‘커널 수준’에서 포착하는지 궁금하지 않으신가요? 이 섹션에서는 OpenTelemetry eBPF Profiler가 노드 전체를 관측하는 방식과, Dash0 Operator가 그 데이터를 표준 OTLP 파이프라인으로 묶어 “바로 쓸 수 있는 프로파일링”으로 만드는 내부 구조를 풀어보겠습니다.
Software Infra 관점의 핵심: “애플리케이션 수정 없이” 노드 전체를 샘플링한다
전통적인 프로파일링은 보통 라이브러리 삽입, 에이전트 주입, 런타임 옵션 설정 같은 애플리케이션 쪽 변경이 필요했습니다. 반면 eBPF 기반 프로파일링은 출발점이 다릅니다.
- 커널이 이미 알고 있는 것(스케줄링, perf 이벤트, 시스템 콜 등)에 훅을 걸어
- 실행 중인 스레드의 스택을 커널/유저 스페이스 경계에서 안전하게 수집하고
- 이를 OpenTelemetry 형식(OTLP 프로파일)으로 표준화해 관측 스택으로 밀어 넣습니다.
즉, Software Infra에서 가장 까다로운 문제인 “언어/프레임워크/배포 방식이 제각각인 수백 개 워크로드를 한 번에 관측”하는 데 유리합니다.
Software Infra 아키텍처 내부: otelcol-ebpf-profiler가 하는 일
Dash0가 채택한 구성의 중심에는 otelcol-ebpf-profiler라는 프로파일링에 특화된 OpenTelemetry Collector 이미지가 있습니다. 이 컴포넌트는 크게 두 역할을 동시에 수행합니다.
1) eBPF 프로그램 로드 및 이벤트 수집(커널 측 연결)
- 커널에 eBPF 프로그램을 올리고(perf/샘플링 및 관련 훅 사용),
- 주기적으로 스택 샘플을 모아 BPF 맵에 쌓인 데이터를 읽어옵니다.
2) 프로파일 데이터로 변환 후 OTLP로 내보내기(유저 공간 처리)
- 샘플된 스택을 “프로파일”로 재구성하고
- OTLP 프로토콜로 백엔드(혹은 다음 콜렉터 파이프라인)로 전달합니다.
여기서 중요한 점은, 이 모든 과정이 Collector 파이프라인의 일부라는 것입니다. 즉 “프로파일도 traces/logs/metrics처럼 표준 파이프라인으로 흘린다”는 방향이 관측 인프라를 단순화합니다.
Software Infra에서 ‘호스트 전체 프로세스’를 보는 이유: hostPID: true와 특권 DaemonSet
“클러스터 전체”를 보려면, 결국 “노드 전체”를 봐야 합니다. 그래서 eBPF 프로파일러는 보통 DaemonSet으로 노드마다 1개씩 배치되고, 아래 조건을 요구합니다.
hostPID: true- 컨테이너의 PID 네임스페이스가 아니라 호스트 PID 네임스페이스를 직접 관찰합니다.
- 결과적으로 컨테이너 밖에서 돌아가는 프로세스까지 포함해 노드의 전체 프로세스 트리를 볼 수 있습니다.
/proc,/sys접근- 프로세스 메타데이터와 커널 인터페이스를 읽어 스택/심볼/컨텍스트를 해석하는 데 필요합니다.
privileged 또는 커널 capability 요구(
CAP_SYS_ADMIN,CAP_BPF,CAP_PERFMON등)- eBPF 로딩과 perf 이벤트 사용은 강한 권한을 전제로 합니다.
- 운영 관점에서는 “관측을 위해 커널에 손을 댄다”는 의미이므로, 배포 승인·이미지 신뢰·정책 제어가 필수입니다.
