쿠버네티스와 컨테이너 네트워크를 위한 네트워킹, 관찰가능성, 보안에는 상당한 처리 오버헤드가 따른다. eBPF는 더 높은 효율성과 가시성, 통제력을 약속한다.

작가 존 던은 “아무도 섬이 아니다”라고 썼다. 그러나 컨테이너는 확실히 섬이다. 컨테이너는 본질적으로 섬으로 만들어지며, 독립적으로 작동하는 데 필요한 모든 요소, 즉 코드와 종속 항목, 런타임과 함께 패키징된다. 이 자율성은 보안에는 유리하지만 네트워킹 관점에서는 그다지 좋지 않다.

사람에게 커뮤니티가 필요하듯이 분산 워크로드는 컨테이너 간의 연결에 의존해 작동한다. 아이소밸런트(Isovalent)의 커뮤니티 책임자 빌 멀리건은 “분산 컴퓨팅 세계에서는 모든 것이 네트워크를 통해 이동하므로 애플리케이션이 기능하고 함께 작동하기 위해서는 네트워크가 핵심적인 구성요소가 된다”라고 말했다. 아이소밸런트는 쿠버네티스 및 기타 클라우드 네이티브 환경을 위한 네트워킹 소프트웨어를 제공하는 오픈소스 프로젝트인 실리움(Cilium)을 운영한다.

전통적으로 컨테이너가 워크로드를 연결하기 위해서는 가상 네트워킹이 필요했다. 소프트웨어 기반 네트워크 어댑터, 스위치, 방화벽, 로드 밸런서 등으로 구성된 네트워크에 의존하는 이 방식은 효율성과 유용성, 프로그래밍 가능성이 떨어졌다. 이 경우만은 추상화(가상 네트워크가 물리적 네트워크에서 추상화된 것과 같이)가 아니라 스택에서 한 단계 더 깊이 내려가는 것이 답이다.

리눅스 커널에서 맞춤형 샌드박스 코드를 실행할 수 있게 해주는 기술인 eBPF는 운영체제 내에 네트워킹을 구현하는 길을 열어준다. 이렇게 하면 효율성, 가시성, 통제력을 모두 높일 수 있다. 이 방식은 전반적인 현대 소프트웨어 네트워킹, 특히 컨테이너 네트워킹에 대한 답이 되고 있기도 하다.

IDC의 리서치 관리자 타란비르 싱은 “기존 컨테이너 네트워킹 스택은 주로 iptables와 사이드카 프록시에 의존해 네트워크 트래픽을 관리했다. 이러한 접근 방식은 부가적인 복잡성과 처리 오버헤드로 인해 대규모에서 효율성이 떨어질 수 있다”면서 이와 대조적으로 eBPF는 커널에서 직접 패킷을 처리하고 정책을 시행할 수 있어 리소스 효율성과 세부적인 제어 기능이 더 뛰어나다고 말했다.

커널 수준에서 네트워킹 기능을 생성하는 데 사용되는 eBPF의 혁신성은 네트워크 구성을 변경할 필요가 없고 컨테이너 네트워킹에 대한 오버헤드를 거의 또는 전혀 발생시키지 않는다는 데 있다. 아이소밸런트의 최고 오픈소스 책임자인 리즈 라이스는 “eBPF를 통해 격리를 보완하는 툴을 구축할 수 있다”라고 말했다.

eBPF 이전의 컨테이너 네트워킹

eBPF 이전에는 컨테이너 네트워킹에 대한 명확한 접근 방식이 없었다. 레드햇의 수석 소프트웨어 엔지니어 셰인 우트는 “특히 쿠버네티스 내에서 네트워킹은 다소 불투명한 워크로드의 측면으로 인식되는 경우가 많았다”라고 말했다.

컨테이너 네트워킹을 위한 기존의 임시방편은 운영상의 장애물로 이어졌다. Solo.io의 오픈소스 디렉터이자 이스티오(Istio) 프로젝트와 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)의 기술감독위원회(TOC) 운영 위원이기도 한 린 선은 “전통적인 컨테이너 네트워킹은 네트워크 트래픽 관리를 위해 iptables와 같은 툴에 많은 부분을 의존한다. 이 방법은 컨테이너 수가 증가함에 따라 효율성이 떨어지게 된다”라고 말했다.

기존 방식에는 중복과 오버헤드도 따른다. 컨테이너는 설계상 상호, 그리고 서버와 격리되므로 가상 이더넷 연결과 연결 양쪽 모두에 네트워크 스택이 필요하다. 아이소밸런트의 라이스는 이 중복으로 인해 불필요한 오버헤드와 지연이 발생한다면서 “eBPF를 사용하면 이러한 불필요한 네트워킹 스택의 일부를 생략할 수 있다”라고 말했다.

마지막으로, 네트워킹이 배포 환경에 따라 좌우됐다. 아이소밸런트의 멀리건은 “eBPF 이전에는 커널 바이패스(DPDK) 또는 하드웨어 가속 등을 통해 성능과 유연성을 높였다. 효과는 있었지만 실행되는 위치에 따라 성능이 크게 좌우됐기 때문에 화이트 박스 네트워킹은 포기해야 했다”라고 말했다.

오늘날 대부분의 배포 환경은 컨테이너 네트워크 인터페이스(CNI) 표준 기반의 플러그인으로 마이그레이션되고 있다. 우트는 “이 표준은 기본적으로 특정 요구사항과 선호도에 따라 다양한 기반 기술을 활용해 네트워크를 구성하는 호스트 수준 바이너리 배포를 허용한다”라고 말했다. 인기 있는 CNI 플러그인으로는 플라넬(Flannel), 칼리코(Calico), 위브(Weave), 그리고 가장 최근에 나온 eBPF 기반 실리움이 있다.

eBPF를 사용한 컨테이너 네트워킹

eBPF는 커널 수준에서 작동한다는 면에서 혁신적이다. 라이스의 설명에 따르면 동일한 호스트의 컨테이너는 사용자 공간에 대해 각자 격리된 뷰를 갖지만 모든 컨테이너와 호스트는 동일한 커널을 공유한다. 여기에 네트워킹, 관찰가능성 또는 보안 기능을 적용하면 오버헤드를 거의 유발하지 않으면서 모든 컨테이너화된 애플리케이션에서 즉시 사용할 수 있게 된다. 라이스는 “eBPF 기반 툴을 사용하기 위해 컨테이너를 다시 시작하거나 재구성할 필요도 없다”라고 말했다.

IDC의 싱은 eBPF가 커널 수준에서 작동하면서 패킷 라우팅, 필터링, 로드 밸런싱과 같은 네트워크 정책과 작업을 구현하므로 사용자 공간에서 작동하는 다른 클라우드 네이티브 네트워킹 기술보다 더 유리하다면서 “이를 통해 eBPF는 많은 잠재적 혜택을 얻고 현대 애플리케이션 워크로드의 중요한 네트워킹 요구사항인 더 빠른 패킷 처리 시간과 낮은 리소스 오버헤드를 제공할 수 있다”라고 설명했다. 이 같은 인프라와의 근접성은 부가적인 모니터링 프록시 없이 심층적인 관찰이 가능하다는 이점도 제공한다.

Solo.io의 선은 “eBPF는 컨테이너 간 네트워킹을 개선하는 것으로 입증됐으며, 특히 네트워크 효율성 개선에 도움이 된다”라고 말했다. Seznam.cz은 eBPF 기반 로드 밸런싱 기술로 전환한 후 CPU 사용량이 72배 감소했다는 놀라운 결과를 보고했다. 멀리건은 기업들이 AI 학습을 지원하기 위해 고밀도 클러스터를 통해 시스템의 확장성을 확대함에 따라 eBPF의 성능 혜택이 중요한 요소가 될 것이라고 예측했다.

eBPF를 사용하면 커널 혁신의 속도가 빨라질 수밖에 없다. 몇 년이 걸릴 수 있는 공식 커널 개발 타임라인을 건너뛸 수 있기 때문이다. 또한 모든 커널 PR이 병합되지는 않는다. 멀리건은 “즉석에서 커널에 기능을 추가하게 되면 수십 년 동안 느리게 혁신이 진행된 시스템에 많은 프로그래밍 가능성이 추가될 것”이라고 말했다.

eBPF가 더 빠른 속도로 개발을 진행하는 데 도움이 된다는 데는 다른 사람들도 동의한다. 과거의 네트워킹 혁신은 몇 년에 걸친 하드웨어 수명 주기에 묶여 있었다. 레드햇의 수석 소프트웨어 엔지니어인 데이브 터커는 “소프트웨어 정의 네트워킹(SDN) 혁신에 따라 이 시간이 몇 주 수준으로 단축됐다. SDN이 성숙해지자 이번에는 eBPF가 다시 혁신을 일으키고 있다. 여전히 기대할 부분이 많다”라고 말했다.

하드웨어에서 eBPF 실행하기

eBPF는 거의 범용적으로 사용할 수도 있다. 아이소밸런트의 멀리건은 “eBPF는 모든 리눅스 시스템에서 사용할 수 있으므로 그 혜택은 모든 사람에게 돌아가며, 모든 곳에서 빠르고 유연한 컨테이너 네트워킹이 가능하다”라고 말했다. 현재 웹 서버의 약 96%가 리눅스를 실행한다. 리눅스 커널을 사용하는 안드로이드는 전 세계 시장 점유율 47%로 가장 인기 있는 운영체제다.

새로운 전략의 목표는 eBPF 처리 부하를 하드웨어로 넘겨 네트워킹을 더 최적화하고 보안을 강화하는 데 있다. 라이스의 설명과 같이 eBPF는 네트워크 연결을 위해 컴퓨터에 로컬로 설치되는 하드웨어 구성요소인 네트워크 인터페이스 카드(NIC)에서 처리가 가능하다. 이를 위해 패킷 처리를 위한 고성능 프레임워크인 익스프레스 데이터 패스(eXpress Data Path: XDP)를 사용한다.

패킷 처리 부하를 디바이스 자체로 넘기면 해커가 잘못 구성되거나 악의적인 패킷을 전송해 운영체제 커널의 버그를 악용하는 “죽음의 핑(ping of death)” 보안 취약점을 효율적으로 완화할 수 있다. 위험한 코드가 커널의 네트워킹 스택에 도달하기 전에 삭제되면 격리와 보안은 당연히 향상된다.

네트워킹에 eBPF를 사용하는 프로젝트

eBPF는 컨테이너 기반 네트워킹, 보안, 관찰가능성을 위한 다수의 오픈소스 및 상용 프로젝트에 채택됐는데, 가장 대표적인 프로젝트는 클라우드 네이티브 컴퓨팅 재단(CNCF)에서 육성해 클라우드 네이티브 네트워크 분야에서 인기를 얻은 프로젝트인 실리움이다.

라이스는 실리움이 CNCF에서 정식(graduated) 지위를 획득했고 오픈텔레메트리(OpenTelemetry)와 같은 프로젝트와 현대 보안을 위한 자격에 포함되는 만큼 네트워크 정책을 처리하기 위한 사실상의 표준으로 볼 수 있다면서 “CNI를 선택해야 하는 상황에서 사람들은 실리움을 표준으로 선택한다”라고 말했다. 컨플루언트(Confluent)와 이베이는 이 목적으로 실리움을 도입한 과정을 공유하기도 했다.

최근 실리움을 개선한 기술인 넷킷(Netkit)은 기반 커널을 강화해 컨테이너 네트워크의 연결 속도를 높인다. 라이스는 넷킷이 eBPF를 사용해 호스트에서 컨테이너 또는 호스트 네트워크로 패킷을 전환해서 컨테이너 실행을 위한 네트워크 오버헤드를 대폭 줄여준다고 설명했다. 멀리건은 “넷킷은 컨테이너 네트워킹 속도를 호스트 네트워킹만큼 빠르게 해서 가상화 오버헤드를 없애준다”라고 덧붙였다.

실리움을 사용하면 eBPF를 활용해서 클러스터 전반에 범용 네트워크 정책을 동적으로 적용할 수 있다. 예를 들어 정책을 통해 컨테이너가 동일한 유형의 다른 컨테이너에만 연결하고 다른 컨테이너에 대한 액세스는 거부하도록 할 수 있다. 라이스는 “실리움에는 네트워크 보안이 있다. 이제 이것을 확장해서 워크로드가 실행되는 모든 곳에서 네트워크 보안을 제어한다”라고 말했다.

레드햇의 터커는 “실리움과 같은 프로젝트는 쿠버네티스 네트워크 모델에 대한 근본적인 변경 없이 eBPF의 강점을 쿠버네티스 네트워킹으로 가져오는 놀라운 성과를 달성했다”라고 말했다. 다만 터커는 eBPF를 채택하는 프로젝트가 증가함에 따라 상호운용성을 보장하기 위해 이 모델을 수정해야 할 수도 있다면서 “컨테이너 네트워킹에서 CNI가 부상한 것과 같은 방식으로 표준화에 더 많은 초점을 두게 될 것”이라고 말했다.

실리움 외에도 eBPF를 사용해 쿠버네티스 로드 밸런싱의 속도와 프로그래밍 가능성을 높여주는 록시LB(LoxiLB), 플러그형 eBPF 데이터 플레인을 제공하는 컨테이너 네트워킹 및 보안 솔루션인 티제라(Tigera)의 프로젝트 칼리코(Calico), 그리고 eBPF를 사용해 멀티 클라우드 네트워킹 플랫폼에서 데이터 플레인 기능을 강화하는 프로시모(Prosimo)도 있다.

멀리건은 eBPF 사례 연구의 증가를 언급하며 “eBPF는 뿌리인 네트워킹을 넘어 관찰가능성, 추적, 프로파일링, 보안을 비롯한 많은 분야로 확장되고 있다. eBPF는 많은 부문에서 커널에 혁신을 되돌려준다. 그 중 일부는 과거 수년, 길게는 수십 년 동안 주요 변화나 업데이트를 이루지 못했던 분야”라고 말했다.

eBPF에서 주의할 점과 우려

우트는 eBPF가 네트워크 성능을 대폭 개선할 기회를 제공하지만 이러한 혜택에는 복잡성 증가라는 대가가 따른다면서 “단기적으로 eBPF를 통해 성능이 향상되지만 운영 측면에서 컨테이너화된 워크로드 관리를 위한 상당한 과제가 뒤따른다. 이로 인해 쿠버네티스의 컨테이너 네트워킹이 더 불투명해질 수도 있다”라고 덧붙였다.

사이드카를 사용해 트래픽을 프록시하는 이스티오와 같이 서비스 메시를 추구하는 측에서는 사용 사례에 따라 제한적으로 eBPF를 수용한다. iptables 규칙을 eBPF로 바꾸면 지연 또는 처리량이 5~10% 향상되는 것으로 나타났는데, 대대적인 교체 작업으로 얻는 효과 치고는 매우 미미한 수준이다. Solo.io의 선은 “커널에서 프로그램을 실행한다고 해서 항상 더 빠른 것은 아니다”라고 말했다.

선은 “eBPF에 따르는 오버헤드와 복잡성을 간과하면 안 된다. 여기에는 새로운 커널을 요구하는 경우가 많은 커널 요구사항, eBPF 프로그램을 실행하기 위한 부가적인 권한, 잘못되는 경우 디버깅 및 문제 해결의 어려움 등이 포함된다”라고 말했다. 이러한 문제 해결에 투입할 수 있는 eBPF 전문가 풀이 제한적이라는 점도 우려되는 부분이다. 선은 “여러 서비스 메시 프로젝트에서 계속 iptables 규칙을 사용하고 권장하는 이유가 여기에 있다”라고 말했다.

메타가 수백만 개의 컨테이너에 실리움 넷킷을 사용하는 것은 eBPF 활용이 증가하고 있음을 보여준다. 그러나 eBPF 기반 네트워킹으로의 업그레이드는 하룻밤 사이에 되지 않는다. 네트워크 디바이스는 런타임에 교체하기가 쉽지 않은 만큼 점진적으로 마이그레이션이 이뤄질 가능성이 높다. 예를 들어 바이트댄스(ByteDance)는 방대한 컨테이너 네트워크 전반에 넷킷을 롤아웃하고 있지만 전환하는 기간 동안 기존의 가상 이더넷(veth) 디바이스도 그대로 유지한다.

eBPF와 실리움의 공동 개발자이자 아이소밸런트의 창립 엔지니어이며 리눅스 커널의 활발한 기여자이기도 한 다니엘 보크만은 “veth 기반 컨테이너/포드가 점진적으로 폐기될 때까지 기존 클러스터에서 두 가상 디바이스가 모두 지원되는 전환 기간을 두는 것이 좋다”라고 말했다. 보크만은 실리움이 관리하는 쿠버네티스클러스터에서 넷킷을 지원하려는 경우 노드별 구성을 적용하는 것이 좋다면서 새로 가입한 노드는 넷킷을 사용할 수 있고 기존 노드는 완전히 폐기될 때까지 계속 veth를 사용할 수 있다고 말했다.

관찰가능성과 보안에 eBPF 적용

네트워킹 외에 eBPF는 보안, 관찰가능성을 비롯한 다른 용도로도 활용된다. 우트는 이러한 사용 사례는 대부분 상태 변경이 아닌 데이터 검색과 관련되므로 네트워킹보다 더 간단하고 쉽다면서 “eBPF는 이러한 종류의 사용 사례에서 게임 체인저 역할을 하면서 고무적일 만큼 성장했다”라고 말했다. 우트는 시스템의 모든 eBPF 프로그램을 위한 범용 로더인 Bpfman에 기여하고 있다.

다른 사람들 역시 이 분야에서 향후 성장 잠재력이 클 것으로 기대한다. 선은 “eBPF는 네트워킹보다 관찰가능성, 보안, 규정 준수 부문에서 중요한 역할을 하고 있다”면서 케플러(Kepler), 픽시(Pixie), 큐브아머(KubeArmor) 등 CNCF 환경의 많은 관찰가능성, 보안 또는 규정 준수 관련 eBPF 프로젝트를 언급했다. 대부분은 “샌드박스” 수준으로 아직 광범위하게 채택되지 않은 초기 단계인 만큼 성장의 여지가 있다.

빠르게 발전 중인 eBPF 기반 보안 프로젝트 중에는 실리움의 하위 프로젝트인 테트라곤(Tetragon)이 있다. 테트라곤은 프로세스, 시스템 호출, 네트워크 및 파일 활동을 모니터링하고 리눅스 커널에서 직접 정책에 따라 이벤트를 필터링한다. 악의적 활동을 나타낼 수 있는 행동의 불규칙성을 발견해서 사이버보안을 위한 정보를 제공하며, 더 나아가 의심스러운 파일 열기와 같은 등 정책 위반을 직접 차단하기도 한다.

싱은 eBPF의 프로그래밍 기능이 보안과 관찰가능성 전반에서 여러 사용 사례에 도움이 될 수 있다면서 “eBPF는 네트워킹에만 국한되지 않는다. 클라우드 제공업체 IaaS 네트워크 서비스와 부가적인 통합이 가능하다. 이 경우 네트워크 스택 전체로 eBPF 이점을 확장할 수 있다”라고 말했다.

궁극적으로 eBPF는 여러 클라우드에 걸친 가상머신에서 실행되는 레거시 데이터베이스가 포함된 네트워크와 같은 이기종 네트워크에 표준 네트워킹 계층을 제공할 수 있다.

eBPF와 게임 오브 라이프

컨테이너는 여러 중대한 타협에 직면했다. 동적인 네트워크 컨테이너 생태계 설계는 가능했지만 막대한 오버헤드를 일으켰다. 그러나 eBPF와 이를 기반으로 구축된 여러 프로젝트에 힘입어 상황이 바뀌고 있다. 레드햇의 우트는 “실리움은 한계를 계속 넓히고 있으며, eBPF 네트워킹 기술의 최전선에서 리더로서 리눅스 커널을 발전시켜 모두를 지원하고 있다”라고 말했다.

IDC의 싱은 “eBPF는 컨테이너 네트워킹, 보안, 관찰가능성을 강화하는 동시에 시스템 개발과 실행을 단순화한다. 이러한 이득은 더 광범위한 도입과 인프라 회복탄력성 및 반응성의 개선으로 이어진다”라고 말했다.

eBPF의 한계는 계속 확장되고 있다. 최근 아이소밸런트의 라이스는 수학자 존 콘웨이가 고안한 유명한 셀룰러 오토마타인 게임 오브 라이프(Game of Life)를 eBPF가 실행할 수 있음을 시연했다. 라이프는 간단한 초기 조건이 주어지면 복잡한 “살아있는” 유기체 사회를 생산한다.

라이프를 실행하는 능력은 이기종 프로그램을 실행하는 eBPF의 능력에 대한 일종의 리트머스 테스트다. 라이스는 “이는 eBPF에 한계가 없음을 증명한다”라고 말했다.

eBPF가 네트워킹에 대한 기존의 모든 접근 방식을 대체할지 여부를 판단하기는 아직 너무 이르다. Solo.io의 선은 “eBPF는 많은 수의 컨테이너에 대해 iptables를 대체하는 것 이상으로 컨테이너 네트워킹을 혁신할 방법을 증명해야 한다”라고 말했다. 선은 서비스 메시의 미미한 성능 향상과 eBPF 전문 인력 부족을 다시 지적하며 “이러한 여러 요소가 복합적으로 작용해서 eBPF 관련 프로젝트는 여전히 도입 단계의 초기에 머물러 있다”라고 설명했다.

선행 구현 과제, 전반적인 eBPF 전문 인력 부족, 레거시 네트워킹에 대한 막대한 투자 등으로 인해 아직 보류하는 경우도 일부 있지만 eBPF의 잠재력은 부정할 수 없다. eBPF는 강력한 툴과 업계 전반의 긍정적인 시각에 힘입어 클라우드 네트워킹의 주도적인 모델로 부상해 개별 컨테이너 “섬”을 “하나의 대륙”으로 연결하는 과정을 착실히 진행 중이다.