eBPF란 무엇인가요?

운영 체제의 커널은 극도로, 그리고 의도적으로 안정된 개체입니다. 커널은 전체 OS를 지원하므로 설계상 수정이나 변경이 복잡하고 노동 집약적일 수 있습니다. 개발자가 OS 커널과 같은 권한 있는 컨텍스트에서 샌드박스가 적용된 프로그램을 실행할 수 있도록 하여 이러한 확장성 문제를 해결하는 것이 바로 eBPF입니다.

OS 스택은 하드웨어 계층, 커널 계층, 사용자 계층의 세 가지 논리적 계층으로 나눌 수 있습니다. 커널 계층은 운영 체제의 핵심입니다. 이는 OS의 모든 물리적 하드웨어, 메모리 및 스토리지 구성 요소를 수용하는 물리적 계층과 OS의 웹 브라우저와 애플리케이션을 수용하는 사용자 계층 사이에 위치합니다.

사용자 공간의 앱과 브라우저는 각각의 작업을 완료하기 위해 물리적 계층의 구성 요소와 통신해야 하지만, 물리적 계층의 각 구성 요소에는 특정 통신 프로토콜과 호환성 요구 사항이 있습니다. 커널 계층(또는 커널 공간)이 그림에 들어오는 곳입니다. 시스템 호출을 해석하고 애플리케이션이 물리적 네트워크 구성 요소와 효과적으로 통신할 수 있도록 합니다.

eBPF 도구를 사용하면 개발자는 커널 소스 코드를 수정하거나, 커널 모듈(커널 기능을 확장할 수 있는 로드 가능한 코드 조각)을 로드하거나, 커널 공간을 방해하지 않고도 런타임에 기존 소프트웨어의 기능을 보다 쉽게 확장할 수 있습니다.

eBPF 기술은 사용자 공간 프로그램에서 네트워크 패킷을 선택하고 분석하는 간단한 방법을 제공했던 오리지널 버클리 패킷 필터(BPF)의 진화를 나타냅니다. 그러나 패킷 필터링 외에도 BPF 프로그램은 커널 내에서 더 복잡한 작업을 처리할 수 있는 유연성이 부족했습니다.

Linux 커뮤니티는 더욱 다양한 기술의 필요성을 인식하여 BPF의 백엔드 기능을 기반으로 하지만 커널 내 프로그래밍 기능을 확장한 eBPF를 개발했습니다. eBPF 프로그램의 고급 기능과 샌드박스 접근 방식을 통해 개발자가 향상된 패킷 필터링 프로세스를 구현하고, 커널 공간 관측 가능성 및 모니터링 기능을 개선하며, 고급 성능 분석을 수행하고, 온프레미스 데이터 센터와 클라우드 네이티브 환경 모두에서 커널 수준 보안 정책을 적용할 수 있습니다.

eBPF 프로그램의 주요 구성 요소는 다음과 같습니다.

eBPF 프로그램은 처음에 제한된 C 하위 집합으로 작성된 다음, Clang과 같은 프런트엔드 프로그래밍 언어를 위한 eBPF의 백엔드 아키텍처 역할을 하는 LLVM과 같은 툴을 사용하여 eBPF 바이트코드로 컴파일됩니다. 바이트코드는 기본적으로 eBPF 명령어 세트 아키텍처를 준수하고 런타임 오류를 방지하는 제한된 명령어 세트입니다.

Linux 커널 기술은 eBPF 바이트코드를 실행 가능한 동작으로 변환할 수 있지만, JIT(Just-In-Time) 컴파일러가 더 뛰어난 성능을 제공합니다. JIT 컴파일러는 필요에 따라 바이트코드를 특정 하드웨어 플랫폼을 위한 기본 기계어로 변환할 수 있습니다.

사용자 공간 로더는 eBPF 바이트코드를 커널에 로드하고 이를 적절한 후크에 연결하여 관련 eBPF 맵을 관리하는 사용자 공간의 프로그램입니다. 사용자 공간 로더의 예로는 BPF 컴파일러 컬렉션(BCC) 및 bpftrace와 같은 툴이 있습니다.

eBPF 맵은 키-값 쌍과 읽기/쓰기 액세스가 있는 데이터 구조로, 공유 저장 공간을 제공하고 eBPF 커널 프로그램과 사용자 공간 애플리케이션 간의 상호 작용을 용이하게 합니다. 시스템 호출을 통해 생성 및 관리되는 eBPF 맵은 eBPF 프로그램의 여러 반복 작업 사이에 상태를 유지하는 데에도 사용할 수 있습니다.

eBPF 시스템의 핵심 구성 요소인 베리파이어는 바이트코드가 커널에 로드되기 전에 이를 검사하여 프로그램에 무한 루프, 불법 명령어 또는 범위를 벗어난 메모리 액세스와 같은 유해한 연산이 포함되지 않도록 합니다. 또한 프로그램의 모든 데이터 경로가 성공적으로 종료되는지 확인하는 데 도움이 됩니다.

후크는 커널 코드에서 eBPF 프로그램을 연결할 수 있는 지점을 말합니다. 커널이 후크에 도달하면 연결된 eBPF 프로그램을 실행합니다.

추적점, kprobe, 업로브 및 네트워크 패킷 수신 대기열과 같은 다양한 유형의 후크를 통해 eBPF 프로그램에 광범위한 데이터 접근 권한을 부여하고 다양한 작업을 완료할 수 있습니다. 예를 들어 추적점을 사용하면 프로그램이 커널이나 기타 프로세스에 대한 데이터를 검사하고 수집할 수 있으며, 트래픽 제어 후크를 사용하면 네트워크 패킷을 검사하고 수정할 수 있습니다. 또한 kprobe와 uprobe는 커널 수준과 사용자 수준에서 동적 추적을 용이하게 합니다.

xDP는 드라이버 수준에서 패킷 처리를 가속화하고 통신 계층 간 전송을 용이하게 하는 고성능 데이터 경로입니다. 이를 통해 eBPF 시스템은 데이터 패킷이 커널에 도달하기도 전에 데이터 라우팅 결정을 내릴 수 있습니다.

2010년대 중반에 XDP와 Linux 커널이 통합되면서 개발자는 가장 바쁜 데이터 센터에서도 데이터 트래픽을 관리할 수 있는 eBPF 기반 로드 밸런싱 기능을 배포할 수 있게 되었습니다.

eBPF는 임의의 함수를 생성할 수 없고 가능한 모든 커널 버전과의 호환성을 유지해야 하므로, 때로는 기본 eBPF 명령어 세트가 고급 연산을 수행하기에는 충분히 섬세하지 못한 경우가 있습니다. 헬퍼 함수는 이러한 격차를 해소합니다.

헬퍼 함수는 eBPF가 시스템 내에서 호출할 수 있는 사전 정의된 API 기반 커널 함수의 집합으로, 명령어 집합에서 직접 지원하지 않는 더 복잡한 작업(예: 현재 시간 및 날짜 가져오기 또는 난수 생성)을 eBPF 프로그램이 수행할 수 있는 방법을 제공합니다.

일반적으로 eBPF는 Linux 커널 내부에서 가상 머신(VM)으로 작동하며, 저수준 명령어 집합 아키텍처에서 작동하고 eBPF 바이트코드를 실행합니다. 그러나 eBPF 프로그램을 실행하는 복잡한 프로세스는 몇 가지 주요 단계를 따르는 경향이 있습니다.

개발자는 먼저 eBPF 프로그램을 작성하고 바이트코드를 컴파일합니다. 프로그램의 목적에 따라 적절한 유형의 코드가 결정됩니다. 예를 들어 팀에서 CPU 사용량을 모니터링하려는 경우, 사용량 메트릭을 캡처하는 기능이 포함된 코드를 작성합니다.

eBPF 컴파일러가 상위 수준 C 코드를 하위 수준 바이트코드로 변환하면, 사용자 공간 로더는 BPF 시스템 호출을 생성하여 프로그램을 커널에 로드합니다. 로더는 오류를 해결하고 프로그램에 필요한 eBPF 맵을 설정하는 역할도 담당합니다.

프로그램 바이트코드와 맵이 준비되면 eBPF는 프로그램이 커널에서 실행하기에 안전한지 확인하기 위해 검증 프로세스를 실행합니다. 안전하지 않다고 판단되면 프로그램을 로드하는 시스템 호출이 실패하고, 로더 프로그램은 오류 메시지를 받게 됩니다. 프로그램이 검증을 통과하면 실행이 허용됩니다.

eBPF는 인터프리터나 JIT 컴파일러를 사용하여 바이트코드를 실행 가능한 기계어로 변환합니다. 그러나 eBPF는 이벤트 기반 기술이기 때문에 커널 내의 특정 후크 지점이나 이벤트(예: 시스템 호출, 네트워크 이벤트, 프로세스 시작, CPU 유휴 상태 등)에 대한 응답으로만 실행됩니다. 이벤트가 발생하면 eBPF는 해당 바이트코드 프로그램을 실행하여 개발자가 시스템의 다양한 구성 요소를 검사하고 조작할 수 있도록 합니다.

eBPF 프로그램이 실행 중일 때 개발자는 eBPF 맵을 사용하여 사용자 공간에서 프로그램과 상호 작용할 수 있습니다. 예를 들어, 애플리케이션은 주기적으로 맵을 확인하여 eBPF 프로그램에서 데이터를 수집하거나 맵을 업데이트하여 프로그램의 동작을 변경할 수 있습니다.

프로그램 언로드는 대부분의 eBPF 실행 프로세스의 마지막 단계입니다. eBPF가 작업을 완료하면 로더는 BPF 시스템 호출을 다시 사용하여 커널에서 언로드할 수 있습니다. 이때 eBPF는 실행을 중지하고 관련 리소스를 비웁니다. 언로드 프로세스에는 팀에서 더 이상 필요하지 않은 eBPF 맵을 반복하여 유용한 개별 요소를 확보한 다음 맵 자체를 삭제('delete' syscall 사용)하는 작업도 포함될 수 있습니다.

버클리 패킷 필터(BPF)는 원래 Unix 기반 시스템에서 패킷 필터링을 위한 메커니즘으로 개발되었으며, 이를 통해 사용자 수준 코드가 커널 내에서 네트워크 패킷을 효율적으로 캡처하고 처리할 수 있는 필터를 정의할 수 있습니다. 따라서 이 접근 방식은 불필요한 데이터를 사용자 공간으로 전송하는 데 필요한 처리 능력을 최소화하고 컴퓨터 네트워킹을 간소화 및 최적화할 수 있었습니다.

BPF는 커널 에이전트를 사용하여 네트워킹 스택의 진입점에서 패킷을 처리합니다. BPF 프로그램이 개발된 후 BPF 커널 에이전트에 의해 커널 공간에 로드되며, 이는 관련 소켓에 연결하기 전에 정확성을 검증합니다. 따라서 사용자 공간에서는 BPF 프로그램의 필터와 일치하는 패킷만 지정된 소켓에서 데이터를 수신할 수 있습니다. 이 보호 기능은 허용된 메모리 영역에 대한 프로그램의 액세스를 제한하고 잠재적인 커널 충돌을 방지합니다.

eBPF는 2014년에 처음 등장했으며, 당시 원래의 BPF 개념에서 크게 발전한 개념이었습니다. 원래의 네트워킹 사용 사례 외에도 시스템 호출 및 기타 기능을 포함하도록 eBPF 애플리케이션이 확장되었기 때문에 개발자들은 종종 이를 '완전히 확장된 버클리 패킷 필터'라고 불렀습니다.

eBPF가 탁월한 핵심 영역 중 하나는 네트워크 성능 모니터링입니다. 이를 통해 IT 팀은 네트워크 동작, 성능 지표 및 병목 현상에 대한 세분화된 인사이트를 확보하여 실시간 분석 및 문제 해결을 수행할 수 있습니다. eBPF는 네트워크 보안, 시스템 호출 및 네트워크 활동 모니터링과 필터링, 네트워크 보안 정책 시행, 시스템 이상 탐지 등의 핵심적인 역할을 수행합니다.

또한 eBPF는 개발자에게 커널 및 사용자 공간 애플리케이션을 추적 및 프로파일링하고 데이터가 커널을 통과할 때 사용자 지정 작업 및 데이터 변환을 실행하는 유용한 도구를 제공하여 다용성과 유틸리티를 더욱 향상시킵니다. 패킷 필터링을 훨씬 뛰어넘는 이러한 광범위한 기능으로 인해 eBPF는 이제 확장 버클리 패킷 필터의 약어가 아닌 독립형 용어로 인식됩니다.

eBPF 기술의 발전으로 인해 소프트웨어 개발자는 모든 운영 체제로 애플리케이션을 확장하여 Linux 기반이 아닌 플랫폼에서도 eBPF의 정교한 추적, 네트워킹 및 모니터링 기능을 활용할 수 있도록 했습니다.¹

실제로 Google, Meta, Netflix, Microsoft, Intel, Isovalent 등이 회원사로 있는 Linux Foundation이 확장되어 설립된 eBPF Foundation은 eBPF 프로그램의 OS 호환성 확장에 많은 투자를 하고 있으며, 궁극적으로 eBPF 프로그래밍의 유용성을 확대할 수 있기를 기대하고 있습니다.²

BPF는 효율적인 패킷 필터링의 토대를 마련했지만, eBPF가 그 범위를 확장한 것은 분명합니다. 최신 eBPF는 Linux 시스템에서 최적화된 관측 가능성, 성능 및 보안을 위한 포괄적인 도구를 제공합니다. 커널 내에서 동적 사용자 정의 프로그램을 실행하는 기능은 시스템 모니터링 및 관리를 위한 새로운 가능성을 창출하여 eBPF를 소프트웨어 개발자와 컴퓨터 프로그래머 모두에게 없어서는 안 될 도구로 만들었습니다.

eBPF 기술은 이미 최신 Linux 시스템의 초석이 되어 Linux 커널을 세밀하게 제어하고 기업이 Linux 에코시스템 내에서 더욱 혁신적인 솔루션을 구축할 수 있도록 지원하고 있습니다.

eBPF는 다음과 같은 분야의 발전을 촉진했습니다.

개발자는 eBPF를 통해 더욱 빠르고 맞춤화된 패킷 처리 기능, 로드 밸런싱 프로세스, 애플리케이션 프로파일링 스크립트 및 네트워크 모니터링 관행을 구현할 수 있습니다. Cilium과 같은 오픈 소스 플랫폼은 eBPF를 활용하여 Kubernetes 클러스터와 워크로드, 기타 컨테이너화된 마이크로서비스를 위한 안전하고 확장 가능하며 관측 가능한 네트워킹을 제공합니다.

또한 eBPF는 IT 팀이 보다 효과적인 트래픽 라우팅, 콘텐츠 필터링 및 손실 방지를 위해 이벤트 경로 초기에 간단하고 복잡한 규칙을 적용할 수 있도록 지원합니다. 커널 수준의 패키지 포워딩 로직을 사용하는 eBPF는 지연 시간을 최소화하고 라우팅 프로세스를 간소화하며 전반적인 네트워크 응답 속도를 높일 수 있습니다.

앱이 마이크로서비스로 세분화되면서 사용자 공간에 대한 가시성 확보가 어려워질 수 있습니다. eBPF는 모니터링 도구에 커널 공간 관점을 제공하여 엔드투엔드 가시성을 그대로 유지합니다.

개발자는 eBPF를 통해 커널 및 사용자 공간 애플리케이션을 계측하여 시스템 성능에 큰 영향을 주지 않으면서 상세한 성능 데이터와 메트릭을 수집할 수 있습니다. 이러한 기능을 통해 조직은 각 네트워크 구성 요소(및 해당 종속성)에 대한 실시간 모니터링 및 관측 가능성을 확보하여 앞서 나갈 수 있습니다.

eBPF는 커널 및 소켓 수준 모두에서 시스템 호출, 네트워크 트래픽, 시스템 동작을 모니터링하여 잠재적인 보안 위협을 실시간으로 탐지하고 대응할 수 있습니다. 예를 들어, 클라우드 네이티브 런타임 보안 도구인 Falco는 eBPF를 사용하여 런타임 보안 감사 및 인시던트 대응을 구현하여 시스템의 전반적인 보안을 강화합니다.

많은 eBPF 도구는 시스템 호출을 추적하고, CPU 사용량을 모니터링하고, 리소스 사용량(예: 디스크 I/O)을 추적할 수 있습니다. 이러한 기능을 통해 개발자는 시스템 성능의 병목 현상을 보다 쉽게 조사하고 디버깅 프로토콜을 구현하며 최적화 기회를 식별할 수 있습니다.

eBPF는 커널 수준의 보안 정책(예: 네트워크 트래픽 필터, 방화벽 및 동작 제한)과 안전 검사를 설치 및 시행하여 악의적인 행위자와 권한이 없는 사용자가 네트워크에 액세스하는 것을 방지할 수 있습니다.

마이크로서비스 아키텍처에서는 컨테이너 내의 프로덕션 워크로드에 대한 가시성이 매우 중요합니다. 그러나 기존의 관측 가능성 툴은 컨테이너화된 마이크로서비스를 따라잡는 데 어려움을 겪을 수 있습니다.

컨테이너는 임시로 설계되었습니다. 필요할 때 생성되고 목적을 달성하자마자 파괴됩니다. 각 컨테이너는 개별 호스트처럼 작동하며, 프로덕션 환경에서는 생성되는 지표의 양이 너무 많아 표준 앱, 네트워크 및 인프라 모니터링 툴을 쉽게 압도할 수 있습니다. 가상 머신도 비슷하게 작동할 수 있지만 컨테이너의 빠른 순환 특성 때문에 원격 측정 캡처가 복잡해질 수 있습니다.

게다가 컨테이너는 클라우드 환경에 대량으로 배포되는 경우가 많기 때문에 가시성을 확보하기가 더욱 어렵습니다.

호스트 또는 컨테이너의 커널 수준에서 실행되는 eBPF를 사용하면 개발자가 수명이 짧은 데이터 엔티티에서 원격 분석을 수집할 수 있습니다. 이를 통해 네트워크, 애플리케이션, 인프라 가시성을 하나의 eBPF 기반 서비스로 통합할 수 있습니다. 또한 eBPF를 사용하면 컨테이너가 클라우드에 배포되지 않은 경우에도 컨테이너 수준에서 프로세스, 메모리 사용량, 네트워크 활동, 파일 액세스에 대한 데이터를 캡처할 수 있습니다.

마찬가지로 Kubernetes 기반 컨테이너화된 환경에서 eBPF는 단일 인터페이스와 도구 세트를 사용하여 서로 다른 클러스터에서 데이터를 수집하므로 IT 팀은 네트워크 전반에서 데이터 수집 작업을 완료하기 위해 개별 사용자 공간 에이전트를 배포할 필요가 없습니다. eBPF 도구는 제어 플레인 노드(예: API 서버 모니터링)에서 실행되고 작업자 노드를 모니터링하여 인사이트를 생성하며, 두 노드 유형의 데이터 포인트와 인사이트를 상호 연관시켜 미세 조정된 클러스터 관측 가능성을 제공할 수 있습니다.