도커와 쿠버네티스 시대, 모니터링의 한계에 부딪히다
과거에는 서버 한 대에 애플리케이션 하나를 띄워서 운영했지만, 요즘은 마이크로서비스 아키텍처(MSA)와 컨테이너(도커, 쿠버네티스) 기술이 기본이 되면서 시스템이 엄청나게 복잡해졌습니다.
수십, 수백 개의 컨테이너가 서로 통신하는 환경에서는 "도대체 어떤 컨테이너에서 병목이 발생하는지", "누가 네트워크 대역폭을 다 잡아먹고 있는지" 추적하기가 매우 어렵습니다. 이를 해결하기 위해 기존에는 각 컨테이너마다 모니터링 에이전트(사이드카 패턴)를 주렁주렁 달아야 했고, 이는 엄청난 성능 저하(오버헤드)를 불러왔습니다.
이러한 클라우드 네이티브 환경의 골칫거리를 완벽하게 해결하며 구원자로 등판한 최신 기술이 바로 오늘 소개할 eBPF(Extended Berkeley Packet Filter)입니다.
1. eBPF란 도대체 무엇인가? (자바스크립트와 비교하기)
이름만 들으면 복잡한 네트워크 필터 같지만, 개념은 아주 직관적입니다. eBPF는 리눅스 커널(운영체제의 심장부) 내부에서 안전하게 사용자 정의 프로그램을 실행할 수 있게 해주는 기술입니다.
이해가 어렵다면 우리가 매일 쓰는 웹 브라우저의 자바스크립트(JavaScript)를 떠올려 보세요.
과거에는 웹페이지에 새로운 기능을 추가하려면 브라우저 자체(크롬, IE 등)를 업데이트해야 했습니다. 하지만 자바스크립트가 등장하면서 브라우저를 뜯어고치지 않고도 웹페이지 위에서 화려한 기능들을 마음껏 실행할 수 있게 되었죠.
eBPF가 딱 이 역할을 합니다. 리눅스 커널의 소스 코드를 수정하거나 시스템을 재부팅하지 않고도, 커널 내부에서 내가 짠 코드(모니터링, 보안 필터 등)를 샌드박스(안전한 공간) 형태로 실행할 수 있게 해주는 '운영체제용 자바스크립트'인 셈입니다.
2. 왜 지금 IT 대기업들은 eBPF에 열광할까?
최근 넷플릭스, 구글, 메타 등 글로벌 빅테크 기업들이 인프라 관리에 eBPF를 적극 도입하는 이유는 다음과 같은 독보적인 3가지 장점 때문입니다.
① 압도적인 성능 (Zero Overhead): 기존의 모니터링 툴들은 사용자 공간(User Space)과 커널 공간(Kernel Space)을 끊임없이 오가며 데이터를 수집해야 했기에 CPU 낭비가 심했습니다. 하지만 eBPF는 커널 내부에서 직접 데이터를 처리하므로 성능 저하가 거의 제로에 가깝습니다.
② X-ray 급의 깊은 관측성 (Observability): 앱 코드를 단 한 줄도 수정할 필요가 없습니다. eBPF는 운영체제 밑바닥에서 모든 네트워크 패킷, 파일 시스템 접근, 시스템 콜을 지켜보기 때문에 애플리케이션이 무엇을 하고 있는지 엑스레이를 찍듯 훤히 들여다볼 수 있습니다.
③ 철벽 같은 보안 (Security): 악의적인 해킹 시도나 디도스(DDoS) 공격 패킷이 애플리케이션에 도달하기도 전에, 리눅스 커널 단에서 eBPF가 먼저 낚아채어 버려버릴 수 있습니다. 가장 빠르고 효율적인 방화벽 역할을 수행합니다.
3. eBPF가 만들어가는 생태계 (Cilium)
eBPF 기술을 기반으로 만들어진 오픈소스 프로젝트들도 엄청난 속도로 성장하고 있습니다.
가장 대표적인 것이 쿠버네티스의 네트워크와 보안을 책임지는 Cilium(실리움)입니다. 기존 쿠버네티스의 복잡하고 느렸던 네트워킹(kube-proxy)을 eBPF 기반으로 완전히 대체하면서, 엄청난 속도 향상과 보안 가시성을 제공하여 현재 클라우드 네이티브 생태계의 표준으로 자리 잡고 있습니다.