[2026-07-18] NetEdit An Orchestration Platform for eBPF Network Functions at Scale

Motivation

기존의 한계

기존 운영체제의 호스트 네트워크 스택은 구조가 고정. 성능을 최적화하기 위해 네트워킹 스택 및 프로토콜 설정을 실시간으로 Fine-tuning하기 어려움

• Fine-tuning : 개별 애플리케이션의 트래픽 패턴, Latency 요구 사항 및 기저 하드웨어 특성에 맞게 네트워크 매개 변수(초기 cwnd, rwnd, timeout 등)을 재구성하여 데이터 전송 효율을 극대화하는 과정
  • 필요성 : 대규모 환경에서는 수백만 개의 컨테이너와 수만 개의 서비스, 각 서비스의 특성과 하드웨어 규격 등이 이질적이라 범용 설정이 아닌 각 특성에 맞게 fine-tuning을 해야 함
• eBPF
  • 도입 배경 : 운영체제 커널 코드를 수정하지 않고도 네트워크 기능을 동적으로 주입. 인프라 속도나 커널 업그레이드 능력을 저해 하지 않으면서도 기능을 도입하여 유연성과 세밀한 제어 기능 제공
  • eBPF의 한계 : eBPF는 단일 애플리케이션과 같은 작업에 활용되어 다음과 같은 한계 발생
    • 단일 목적으로 사용되는 애플리케이션에서 주로 사용되어 수많은 서비스와 하드웨어의 변경 사항에 맞추어 임의의 eBPF 코드를 유연하게 교체하고 관리하는 파이프라인이 없음
    • 다수 서비스가 공존하는 고도의 동적 환경에서 필수적으로 요구되는 고가용성 보장(High availability guarantees)과 엄격한 테스트 기능(Rigorous testing capabilities)을 지원하는 기본 요소가 결여
      • 고가용성 : 시스템의 관리 및 제어 프로세스에 장애가 발생하거나 업데이트를 위해 재시작되더라도, 실제 패킷을 처리하는 커널 데이터 평면은 중단 없이 네트워크 정책(튜닝 설정)을 지속 집행할 수 있는 시스템의 복원력. 기존 시스템에서 eBPF 프로그램의 수명 주기는 사용자 공간(User-space)의 관리 프로세스에 의존하여 관리 프로세스가 일시적으로 종료되면, 커널이 연결된 eBPF 객체와 설정 상태를 임의로 초기화 및 제거해버려 지속적인 정책 적용이 불가능
      • 엄격한 테스트 기능 : BPF의 기본 내장 검증기(Verifier)는 코드가 커널을 다운시키지 않는다는 최소한의 안전성(루프, 메모리 범위 제한)만 검사할 뿐, 다중 프로그램이 얽힌 동적 환경에서 발생하는 논리적 충돌이나 교차 기능 간섭(Cross-Feature Interactions)을 검증할 체계가 지원 안함
        • 교차 기능 간섭 : 다중 서비스 환경에서는 동일한 네트워크 연결 및 패킷 상태에 대해 목적이 다른 여러 네트워크 프로그램(예: 방화벽, 대역폭 제한, 혼잡 제어)이 동시에 부착되어 실행. 실행 우선순위 충돌, 제어 로직 덮어쓰기, 공유 메모리(Shared Map) 오염 등의 예기치 않은 부작용이 발생
        • 다중 서비스 환경에서 이러한 결함은 특정 컨테이너를 넘어 호스트 노드 전체의 커널 패닉이나 마비를 유발

→ 서비스와 하드웨어 환경 변화에 맞춰 임의의 eBPF 프로그램을 고속(High velocity)으로 개발 및 배포하고, 대규모 서버 군에 걸쳐 다수 프로그램의 구성과 수명 주기를 중앙에서 안전하게 조율(Orchestration)할 수 있는 통합 시스템인 NetEdit의 개발이 요구

Challenge

1. C1 (다양하고 변화하는 커널 훅 포인트) : 다양한 커널 릴리스에 걸쳐 노출되는 eBPF 인터페이스와 기능은 빠르게 진화함. 다수의 커널 환경에서 기존 애플리케이션을 관리하고 새로운 애플리케이션을 배포하는 복잡성으로 인해 애플리케이션을 커널 훅 포인트로부터 분리하게 됨. 모든 eBPF 프로그램 및 커널 버전에 걸쳐 통일된 인터페이스를 제공하여 임의 애플리케이션의 관리를 단순화함
2. C2 (업그레이드 중 중단) : 업그레이드 중 장애가 발생하더라도 eBPF 프로그램은 계속 작동해야 함.
3. C3 (복잡하고 적응적인 구성): eBPF 프로그램은 서비스 요구 사항과 네트워크 상태에 따라 서로 다른 네트워크 트래픽에 적용될 수 있으며, 이 둘은 모두 빠르게 변화에 적응
4. C4 (동적 서비스 배치): eBPF 프로그램은 특정 인프라에 맞춰질 수 있으며, 이는 eBPF 기능을 인프라 특성(예: 하드웨어)과 결합시킴. 그러나 서비스 배치는 동적이며 eBPF 프로그램 호환성과는 무관함.
5. C5 (상관된 커널 버그): eBPF 프로그램 자체는 검증될 수 있지만, 특정 커널-eBPF 상호작용에서 알려지지 않은 여러 버그가 발견됨. 안전성을 향상하기 위해 eBPF 프로그램을 격리하여 eBPF-커널 인터페이스를 엄격하게 검증하는 테스트 프레임워크를 구축함

Background

eBPF

특정 Hook-point에 도달했을 때 실행되도록 보장되는 stateless 코드 조각. 제한된 코드 크기와 복잡도를 가져 커널이 로딩 전 코드의 유효성을 검증하고 확인하는 기술

• eBPF maps : 외부 데이터 구조. 프로그램 실행 간 상태 유지 또는 프로그램 간 상태 공유의 목적. User-space에서도 시스템 콜로 접근 가능
• 채택 이유
  1. 애플리케이션 코드 수정이 필요하지 않아 투명성(transparency)을 제공
     • 투명성 : 시스템의 특정 기능이 하위 계층에서 작동할 때, 상위 계층의 애플리케이션이 그 존재를 인지하거나 구조를 변경할 필요 없이 기존 상태 그대로 동작할 수 있는 특성
  2. 커널 모듈과 달리 커널 업그레이드 시 코드 재작성이 필요하지 않아 커널 진화에 대한 적응력이 높음
     • 커널 모듈은 내부 API나 메모리 데이터 구조에 의존하여 새로운 버전이 나오면 호환이 되지 않아 코드를 재작성해야 함
     • eBPF는 헬퍼 함수를 통해서 커널과 상호작용하므로 커널 업그레이드에 적응력이 높아 코드를 재작성할 필요가 없음
       • kprobe를 통한 임의 함수 후킹은 최후의 수단으로 간주되며, 일반적으로는 내부 커널 코드가 변경되더라도 식별자가 고정되어 보장되는 안정적인 인터페이스인 Tracepoints를 활용
       • 네트워크 튜닝 영역에서는 패킷 처리 스택에 표준화된 XDP, TC(Traffic Control) 훅 포인트나, 커널 함수 포인터를 구조체 형태로 안전하게 대체하는 struct_ops 등을 활용하여 커널 내부 함수의 명칭 변경으로부터 eBPF 로직을 격리(Decoupling)
       • BPF CO-RE (Compile Once – Run Everywhere) 및 BTF (BPF Type Format) : . CO-RE 기술은 BTF라는 메타데이터를 활용하여, 미리 컴파일된 단일 eBPF 바이너리가 타겟 커널에 적재(Load)될 때 BPF 로더가 대상 커널의 레이아웃 차이를 식별하고 변수 및 구조체의 메모리 오프셋을 런타임에 동적으로 재배치
  3. 세밀한 제어 : IPTable와 같은 지원 도구는 지원하는 기능이 제한적. eBPF는 포트 번호, 특정 NIC 모델 등 다양한 기준에 기반한 매칭을 포함하여 광범위한 네트워킹 기능 제어를 제공
     • 패킷의 헤더와 페이로드를 검사하여 특정 조건과 일치하는 지 식별 - 구글 등은 시용자 공간 스택(userspace stacks)을 도입하여 유연한 네트워크 튜닝을 수행하지만, 이는 종종 복잡한 커널 최적화나 특수 네트워크 카드를 요구
     • 사용자 공간 스택 : 패킷 처리를 운영체제 커널의 기본 네트워킹 스택에 맡기지 않고 커널을 우회(Kernel Bypass)하여, 사용자 공간(User-space) 애플리케이션 계층에서 네트워크 프로토콜을 직접 처리하는 아키텍처

Motivating Example

• 핵심 개념 정의
  • Migration : 실행 중인 서비스, VM 또는 컨테이너를 현재 구동 중인 물리적 서버에서 다른 물리적 서버로 이동시키는 프로세스.
  • 혼잡 제어 튜닝 (Congestion Control Tuning): 네트워크 경로 상의 병목 현상 및 패킷 손실을 방지하기 위해 송신 측의 혼잡 윈도우(cwnd)를 조절하는 알고리즘 최적화 과정. RTT, 패킷 손실 등의 지표를 기반으로 통신 경로 전체의 대역폭 한계를 종합적으로 반영하는 전역적 특성을 지님.
    • 예를 들어, RTT가 큰 것을 보고 Cross-region이 발생했음을 식별
  • 초기 윈도우 (Initial Window, IW): TCP 연결이 설정된 직후, 수신 측의 확인 응답(ACK)을 대기하지 않고 송신 측이 네트워크로 연속 전송할 수 있는 최대 패킷 허용량.
    • IW가 클 경우 RTT를 최소화함으로써 시작 지연 시간 성능이 향상
  • ToR (Top of Rack) 스위치: 단일 서버 랙(Rack) 내부에 배치되어, 해당 랙에 장착된 물리적 서버들의 트래픽을 상호 연결하고 상위 계층 네트워크로 전달하는 엣지 스위치 장비.
  • 버퍼 축적 (Buffer Buildup): 스위치 버퍼에 누적되는 현상.
• Example
  • 서비스 A : RTT 및 트래픽 패턴을 기반으로 rwnd 크기를 제한하여 burst를 완화하는 튜닝 기능 적용
    • 다른 물리서버로 마이그레이션할 때, RTT와 같은 거시적 네트워크 통신 환경은 동일하게 유지되므로 기존 혼잡 제어 튜닝(예: Cubic 알고리즘)은 변경 없이 유지 가능함. 그러나 NIC 속도와 rwnd의 상관관계로 인해 윈도우 설정은 반드시 재조정되어야 함.
    • 마이그레이션 시, NIC 속도와 rwnd의 상관관계
      • 고속 NIC 환경 : rwnd가 작을 수록 대역폭을 충분히 활용하지 못함
      • 저속 NIC 환경 : rwnd가 클 수록 하드웨어 처리 용량을 초과하는 트래픽 버스트 발생하여 ToR 스위치에서 버퍼 축적 및 경합으로 인한 패킷 드랍 발생
  • 서비스 B : 높은 RTT를 가지는 cross-region 흐름에만 적용되는 특정 혼잡 제어 알고리즘(Cubic)이 적용
    • A의 기존 서버를 서비스 B가 대체할 때, 서비스 구동의 시작 지연 시간(Startup Latency) 향상을 위해 특정 TCP 초기 윈도우 값을 설정하는 튜닝 기능 요구
  • 서비스 A, B 모두 다른 여러 요건들로 트래픽 프로파일이 변화할 수 있음
• 구성 변경의 동적 특성 (Dynamism of Configuration Changes)
  • 위와 같이, 마이그레이션이나 트래픽 프로파일의 변화로 네트워크 설정 (튜닝 정책)이 변화됨
  • 튜닝 정책의 시간적 변경 빈도 및 변동 폭을 수치화한 지표

  • 롱테일적 특성: 1개월간 스토리지(Storage) 및 기계 학습(ML) 서비스에 실제 적용된 네트워크 튜닝 정책(tuningFeatures)의 총개수를 추적

    

    • 인프라의 상태 변화에 따라 운영체제 커널에 동적으로 주입(Load/Attach) 및 제거(Detach)되는 eBPF 프로그램의 개수와 종류가 실시간으로 증감
    • 대부분(평균)에는 소수의 기본적인 네트워크 튜닝 정책(분포의 머리, Head)만이 활성화되지만, 일시적인 트래픽 버스트나 하드웨어 마이그레이션 등 예외적인 엣지 케이스(Edge cases)가 발생할 때마다 고도로 특화된 수많은 세부 튜닝 정책들(분포의 꼬리, Tail)이 산발적으로 활성화되어 p95 수치를 급격히 끌어올리는 비대칭적 통계 분포를 의미
    • 시스템 관리자가 사전에 정의한 범용 프로토콜 설정이나 정적 휴리스틱만으로는 롱테일에 위치한 수많은 예외적 엣지 케이스(Edge cases)와 세부 요구사항을 포괄할 수 없다

Requirement

1. 개발 투명성(C1)
   • eBPF 기술은 네트워크 스택의 여러 지점에 훅 포인트를 제공. 하지만 각 훅 포인트마다 eBPF 프로그램을 커널 메모리에 load하고 특정 이벤트에 attach/detach 하는 데 필요한 커널 API, 시스템 콜, 데이터 구조체 등이 다름
   • 실제 기능의 로직보다 서로 다른 훅 포인트 인터페이스 규격을 맞추고 연동하기 위한 glue-code를 작성하는 데 더 많이 비용이 소모

   → 다양한 훅 포인트를 관리할 체계적인 접근 방식이 필요

2. 고가용성 (C2)
   • 상태 보존 문제
     • 객체 할당 및 참조 유지: 사용자 공간의 데몬 프로세스가 eBPF 프로그램 및 맵(Map)을 커널에 적재하면 FD가 반환되며, 해당 FD가 유지되는 동안 커널 내 eBPF 객체의 참조 카운트가 1 이상으로 보장되어 메모리에 존속

     • 프로세스 종료와 자원 회수: 데몬 프로세스의 크래시 또는 업데이트에 의한 재시작이 발생할 경우, 해당 프로세스가 점유하던 모든 FD를 강제로 닫음

       → FD 회수 결과로 eBPF 맵의 참조 카운트가 0으로 하락하면, 커널은 이를 고아 객체(Orphaned Object)로 간주하여 메모리 누수 방지를 위해 즉각 할당을 해제. 이로 인해 맵 내부에 유지되던 네트워크 세션 및 튜닝 상태 데이터가 모두 소멸.

   • 소급 적용 : 프로그램은 패킷 유입이나 연결 시작(SYN)과 같은 이벤트가 발생될 때 실행됨. 이미 통신이 진행되어 통신 중인 기존의 장기 연결에 대해서도 정책을 갱신하여 적용하기 어려움

   → 커널의 자동 가비지 컬렉션에 의존하지 않고 Control Plane이 현재 네트워크 상태를 바탕으로 eBPF 객체의 보존과 정책 갱신(트리거)을 직접 제어할 수 있는 아키텍처가 필수적

3. 안전하고 정확한 배포(C5) : 검증기가 논리적 정확성을 보장하지는 않음.
   • 대규모 배포 환경에서는 단일 물리 서버 내에서 동일한 패킷이나 통신 연결(Connection) 상태에 대해 다수의 eBPF 프로그램(예: 방화벽, 로드밸런서, 혼잡 제어 튜닝)이 동시에 개입하는 데, 실행 순서 조정이나 동기화가 보장되지 않으면 race condition이 발생

   → eBPF 커널 인터페이스를 테스트하고 버그를 식별할 수 있는 프레임워크 도입이 필요

4. 컨텍스트 맞춤형 오케스트레이션 (C3/C4) : 애플리케이션의 특성, 트래픽 프로파일, 하드웨어 상태 등 시스템의 실시간 Context을 인지하여, 그에 부합하는 eBPF 프로그램 및 네트워크 튜닝 정책을 자동으로 배포, 갱신, 회수하는 동적 자원 제어 프레임워크
   • 기존 방식의 한계: 모든 서버에 일관된 정책을 강제하거나 수동으로 배포
   • 요구 사항
     • 추상화 : 서비스의 확장 및 마이그레이션 등의 인프라 변동 상태를 상위 계층으로 은닉하고 상황에 맞는 eBPF 프로그램의 배포를 자동 조정하는 매커니즘
     • 정책 언어의 범용성과 튜닝의 특수성 : 이질적인 기저 하드웨어와 트래픽 특성을 처리하기 위해 실제 튜닝 설정은 고도로 특화되어야 하나, 대규모 환경의 관리 오버헤드를 최소화하기 위해 상위 제어 인터페이스(정책 언어)는 추상적이고 범용적으로 설계
     • 프로그램 생명 주기 동적 제어 : 인프라 장애나 서비스 변동과 같은 동적 환경에 대응하기 위해, 프로그램의 적재 및 해제 과정을 실시간으로 처리할 수 있는 신속하고 확장 가능한 오케스트레이션이 요구

COMPARISONOFOPENSOURCE EBPF

ORCHESTRATORS

비교

• 선도적 도입 및 맞춤형 목적 : NetEdit은 eBPF를 조기에 도입. 범용적 제어에 초점을 맞추는 타 도구와 달리 자사의 고유한 서비스 특성 및 물리적 인프라 환경에 고도로 특화된 맞춤형 튜닝 기능 제공을 목표로 설계됨.
• 장기 프로덕션 운영 검증: 최근 2~3년 내에 공개된 범용 오픈소스 eBPF 관리 도구들과 대비하여, NetEdit은 지난 6년간 실제 대규모 상용(Production) 환경에서 운영되며 시스템 안정성과 실효성을 입증
• 오픈소스 기술 기반 제공: 현재 사용되는 다수의 오픈소스 eBPF 오케스트레이터는 NetEdit 측이 리눅스 메인라인에 선제적으로 업스트림(Up-stream)한 커널 수정 사항과 기출판된 기술 문서에 직접적으로 기반하여 구축됨
  • 업스트림(Up-stream): 소프트웨어 개발 조직이 자체적으로 수정하거나 기능 확장을 이룬 리눅스 커널 소스 코드를 공식 리눅스 메인라인 저장소에 제출하여 최종적으로 Merge시키는 기술적 기여 과정을 의미
• 노드 중심 통제 vs 애플리케이션 런타임 기반 전역 제어
  • 기존 오케스트레이터들은 주로 단일 호스트 관리에 중점
  • NetEdit은 수백만 대의 서버 위에서 동작하는 애플리케이션의 생명 주기(시작, 종료, 트래픽 변화)를 실시간으로 인지하여, 각 호스트에 필요한 eBPF 튜닝 정책을 애플리케이션 상태에 맞춰 전역적으로 동기화하고 제어
• 대규모 인프라의 자원 및 정책 충돌 방지
  • 자원을 최적화하는 지연 로딩(Lazy loading)과 정책 적용 범위를 엄격히 격리하는 스코핑(Scoping) 기능을 제공하지 않음.
  • NetEdit은 이 두 가지 추상화 기능을 제공함으로써 대규모 환경에서 필연적으로 발생하는 CPU 오버헤드를 막고, 튜닝 정책들이 엉뚱한 서비스에 적용되는 오류를 차단.
• 통제된 환경의 한계 극복 및 실제 운영 컨텍스트(Operational Context)
  • eBPF 배포를 단순화하려는 기존의 연구나 도구들은 특정 훅 포인트(Attach-points)에 국한되어 있거나, 장애와 이질성이 난무하는 실제 인프라의 복잡성(Operational Context)을 반영하지 못함.
  • NetEdit은 6년간 실제 대규모 프로덕션 환경에서 겪은 한계들을 바탕으로, 튜닝 기능의 개발과 관리를 실질적으로 단순화하는 특화 기능들을 도입.

Design

설계 원칙

• eBPF를 커널 계층으로부터 분리
  • 기존의 한계 : eBPF는 커널이 메모리나 CPU 자원을 자체적으로 배분하는 방식(휴리스틱)과 내부 함수 규격(primitives)에 직접적으로 종속. 이러한 내부 규칙들이 버전에 따라 일관성 없이 빈번하게 변경되어 커널 버전에 따라 다르게 동작하거나 장애를 유발
    • 휴리스틱 : 최적의 완벽한 해답을 수학적으로 보장하지는 않으나, 제한된 시간과 컴퓨팅 자원 내에서 실현 가능하고 수용 가능한 수준의 근사해나 결정에 도달하기 위해 사용하는 경험적 규칙.
      • EX) 커널이 미래의 모든 메모리 접근 패턴을 예측하여 계산하는 대신, 과거의 접근 기록을 바탕으로 ‘최근에 가장 적게 사용된 페이지(LRU)’를 우선적으로 메모리에서 쫓아내는 자원 관리 알고리즘
  • 해결 방안 : 커널의 세부 구현과 eBPF 프로그램 사이에 통제된 독립 계층을 둠
  • 효과 : 하위 운영체제 커널의 기본 동작 방식이나 버전 차이를 크게 고려하지 않고도, 인프라 전역에서 일관된 방식으로 eBPF 프로그램을 배포 및 제어할 수 있으며 향후의 새로운 요구사항에도 유연하게 대응
• 통합된 생명주기 관리 (Integrated Lifecycle Management) : 애플리케이션의 런타임 상태 변화(생성, 스케일링, 마이그레이션, 재부팅 등) 이벤트를 하위 운영체제 커널 계층에서 동작하는 eBPF 프로그램(네트워크 튜닝 정책)의 배포 및 제어 과정과 동적으로 연동하고 동기화하는 시스템 아키텍처 기법
  • 기존의 한계 : eBPF는 서비스가 Migration 하는 지, Scaling 하는 지 등 클러스터 차원의 상위 이벤트를 감지할 수 있는 시야가 없음
  • 해결 방안 : 애플리케이션의 상태 변화 이벤트를 eBPF 프로그램 관리 시스템으로 전달하는 전용 API를 개발
  • 효과 : 상위 서비스의 lifecycle (생성, 확장 소멸)와 하위 튜닝 기능의 lifecycle (주입, 변경, 해제)가 통합되어 조율. 즉, 서비스의 이동이나 확장에 맞춰 필요한 커널 네트워크 튜닝 정책이 자동으로 따라다니며 적용되거나 회수
• Fail-open
  • 기존의 한계 : 클라우드 환경에서는 기능 개선, 버그 수정 등을 위해 NetEdit을 업데이트하고 재배포를 해야 하며, 이 과정에서 예기치 못한 크래시나 재부팅이 발생
  • 해결 방안 : 중앙 제어 프로세스가 다운되더라도, 이전에 운영체제 커널에 주입해 둔 개별 네트워크 제어 정책(eBPF 튜닝 기능)들이 운영체제에 의해 강제로 삭제되거나 멈추지 않도록 독립성을 부여
  • 효과 : 장애가 발생하더라도 지속적 가용성의 환상을 경험. 개발자는 관리 프로그램이 작동하지 않아도 eBPF 프로그램에 접근하여 내부 상태를 들여다보고 디버깅을 수행할 수 있음
• 최소 오버헤드 : 랭킹, 추천 시스템, 머신러닝 추론 및 프론트엔드 서비스와 같이 지연 시간에 민감한 서비스를 지원하기 위해 효율적인 자원 사용을 염두에 두고 설계

Overview

• 3가지 역할
  • 클러스터 관리 시스템 : 여러 물리 서버를 클러스터링하여 그 안에서 동작하는 eBPF 프로그램을 중앙에서 통제 및 배포
  • 개발 플랫폼 : eBPF 프로그램을 처음부터 끝까지 새로 짜는 대신, 조립할 수 있는 표준화된 부품(재사용 가능한 구성 요소)을 제공하고, 배포하기 전에 테스트하는 환경을 제공
  • 정책 구성 엔진 : 동적인 조건 하에서 발생하는 상위 서비스 요구사항을 정확한 하위 배포로 변환
• 아키텍처
  • Control plane : 정책을 관리하고 이를 eBPF가 이해할 수 있는 primitives로 동적으로 변환
  • Data plane : 실제 트래픽을 처리하는 영역. 커널을 eBPF 관리로부터 decouple 하여 명령을 수행
• 동작 흐름
  1. 부팅 시, 커널 공간(Data plane)을 검사. 이전에 실행된 튜닝 기능(eBPF 프로그램)의 잔여물을 삭제하여 충돌이 없는 초기 상태를 확보
  2. 설정을 분석하여 load할 튜닝 기능의 목록을 결정하고 BPFAdapter 추상화를 사용하여 data palne에 attach
  3. 상위 서비스의 상태를 감시 : Control plane이 서버에서 작동하는 컨테이너 관리 시스템과 통신망을 구축하여 어떤 애플리케이션이 새로 실행했는 지 종료되었는 지 모니터링
  4. 서비스의 변경이 감지되면, NetEdit 내부의 의사결정 모듈인 PolicyEngine이 해당 서비스의 특성에 맞는 네트워크 제어 정책을 결정. BPFAdapter를 통해 커널에 동적으로 load/attach. 서비스가 종료되면 해당 프로그램을 detach
  5. 트래픽이 들어오면 eBPF 프로그램이 패킷을 검사하고 ConfigStore에 저장된 정보를 참조하여 트래픽을 빠르게 통과시킬지, 차단할지, 혹은 최적화할지 튜닝을 수

NETEDIT DATAPLANE

eBPF를 커널과 decoupling하여 제어권을 획득

BPFAdapter을 통한 interface decoupling

• 문제 상황 : 다양한 훅 포인트마다 방법, 규칙, 매개 변수 등이 다름
• 해결 방안 : 다양한 부착 방식의 복잡성을 은닉하기 위해 BPFAdapter라는 인터페이스 배치.
  • attach, detach, execute 등을 함수 호출로 실행 할 수 있게 만듦
• 효과 : Control plane은 훅 포인트의 세부 사항을 알 필요가 없음
• 기존과 차이점
  • Lazy loading
    • 문제 상황 : 모든 eBPF 프로그램을 서버가 켜질 때 커널에 load하면 사용하지 않는 프로그램까지 자원 점유
    • 해결 방안 : Active policy이 발생할 때까지 커널에 load하는 것을 미룸
      • 이는 정책 인터페이스가 튜닝을 적용할 대상 서비스만 지정하는 것이 아니라 해당 서비스로 들어오는 패킷의 프로토콜, 헤더 패턴 등 패킷 분류 기준과 대상 트래픽 속성을 명시적으로 선언
      • 예시 ) {"target_service": "web-frontend", "classifier": {"layer4_protocol": "TCP", "dst_port": 443, "tcp_flag": "SYN"}}
  • 명시적 스토리지 관리 (Explicit Storage Management)
    • 문제 상황 : 커널이 Map을 임의로 관리하여 Map을 임의로 지우거나 접근을 제한하는 경우가 발생. 서로 다른 두 eBPF 프로그램이 하나의 Map을 공유하여 데이터를 전송하는 작업을 수행할 때 데이터 유실이나 시스템 충돌이 발생할 수 있음
    • 해결 방안 : 커널이 자동 관리(암묵적)하는 것을 멈추고 NetEdit이 명시적으로 관리

고가용성을 위한 Heuristics Decoupling

명시적 가비지 컬렉션

• 문제 상황 : 커널은 메모리 관리를 위해 참조 카운팅 기법을 사용. 프로그램 종료 시 카운트가 0으로 떨어져 eBPF 프로그램도 가비지 컬렉션에 의해 삭제. 데몬 재시작되는 시간동안 네트워크 정책이 손실
• 해결 방안
  • eBPF 전용 가비지 컬렉션 수행 시점을 제어할 수 있는 primitives 도입
  • Pinning 사용. eBPF 객체(프로그램이나 Map)를 메모리 상에만 두는 것이 아니라 커널 내부의 특수한 파일 시스템 경로(pin-fs)에 파일 형태로 마운트. 커널 입장에서 파일 시스템에 고정된 객체는 누군가가 사용 중인 것으로 간주하므로 강제로 가비지 컬렉션을 하지 않음
    • Map 역시 Pinning을 하여 상태 정보가 초기화 되는 오류를 막고 재부팅 전후 Context를 동기화

소급적 정책 집행

• 문제 상황 : Event-driven 구조의 eBPF 프로그램은 재부팅 시 다음과 같은 문제가 발생
  • 프로그램이 꺼진 찰나에 새로 맺어진 연결
  • 프로그램이 끄기 전에 맺어진 장기 지속 연결
  • 위 두 연결은 다시 켜진 이후에 연결 생성 이벤트가 발생하지 않아 연결 생성 이벤트에 트리거 되는 eBPF 프로그램이 실행 되지 않음. 새로운 규칙이나 정책이 적용되지 않음

• 해결 방안 : NetEdit이 능동적으로 eBPF를 트리거

  

  • 멱등성이라는 조건이 필요 : 동일한 정책을 여러 번 적용해도 오류가 발생하지 않아야 함
  • bpf-iter라는 기술을 이용해, 제어 시스템이 직접 현재 유지되고 있는 모든 연결 목록을 순회하여 업데이트된 eBPF 정책을 일괄적으로 강제 주입
  • 위의 그림 설명
    • (a) : NetEdit이 다운되면 eBPF 프로그램도 정지되거나 회수.
      • 빨간 막대 부분, 시스템이 재부팅되어 새로운 eBPF 프로그램을 커널에 부착하는 순간까지 정책 공백이 발생
    • (b) : 다운되더라도 여전히 트래픽 제어(Fail-open) 새로운 업데이트를 적용하기 위해 detach하고 다음 attach까지 공백이 발생
      • bpf_iter이 트리거 되어 활성화된 네트워크 세션을 순회하여 정책을 소급하여 집행

데이터 운명 공동체 현상 제거(Eliminate Data Fate-Sharing)

• 문제 상황 : 기존의 오케스트레이터들은 Control plane에서 관리 및 관측을 하여 다운될 경우 관측을 하지 못하여 가시성 상실
• 해결 방안 : 관리 프로세스와 관측 프로세스를 분리.
  • metrics exporter: 통해 프로그램에서 데이터를 읽어와 DB에 전송하는 경량 에이전트 프로세스
• 효과 : NetEdit이 다운되도 디버깅 데이터나 성능 지표가 외부로 전송 및 기록

정확성을 위한 eBPF 간 Decoupling

여러 eBPF 프로그램이 협력하기 위해 순차적으로 실행되거나 (chaining) Map을 공유해야 하지만 훅 포인트마다 서로 다른 규칙을 적용. 어떤 위치에서는 명시된 ‘우선순위’에 따라 순서가 결정되고, 다른 위치에서는 단순히 커널에 ‘명령어가 입력된 순서(시간순)’에 따라 순서가 무작위로 결정되는 문제 발생

eBPF 프로그램 구성

• 문제 상황 : 하나의 훅 포인트에 여러 프로그램이 부착될 때에는 부착 순서에 따라 실행되는 데 대규모 서버 환경에서는 무작위 순서로 설치. 순서가 엉키거나 예측 할 수 없게 됨
• 해결 방안 : 배열을 만들어 해당 훅 포인트의 실행 논리로 매핑
  • 각 시스템은 부여 받은 고유의 우선순위에 따라 특정 인덱스에 매핑
  • 부착은 무작위 순서로 되지만 배열 구조를 통해 우선 순위가 높은 프로그램이 먼저 처리하여 충돌을 멈춤
    • Index 0: 보안 방화벽 (최우선 순위)
    • Index 1: 트래픽 대역폭 제한 (QoS)
    • Index 2: 패킷 로깅 및 모니터링 (최하위 순위)
    • 모니터링 프로그램이 먼저 설치될 수 있지만 Index 2에 매핑되어 Index 0부터 실행
  • TC 같은 패킷 단위 훅 포인트에서는 Ingress와 Egress 때 적용 순서가 다르므로 각 배열을 거울상처럼 반대로 배치하여 제어 순서 보장
• 효과 : 예측 가능한 순서를 보장하고 충돌을 막음. DevOps (운영 개발팀)이 트래픽의 잠재적 흐름을 유추할 수 있게 보장

Shared Maps

• 문제 상황 : eBPF 프로그램을 메모리에 load할 때 각 프로그램만을 위한 Map을 생성. 데이터 교환을 위해 같은 맵을 사용하려고 프로그램 소스 코드 상 같은 이름이나 속성의 맵을 선언해도 단일 메모리 주소로 연결하지 않고 분리하여 복제가 되는 현상이 발생. 이로 인해 메모리 낭비와 데이터 파편화 문제 발생
• 해결 방안 : BPFAdapter가 eBPF 프로그램 실행 관리와 Map 관리를 decoupling. 오케스트레이터가 자원의 공유 상태 통제
  • 동작 흐름
    1. BPFAdapter가 어떤 프로그램이 어떤 맵을 공유하는 지 추적
    2. 특정 파일 시스템 경로에 명시적으로 공유 Map을 Pinning 시켜 묶어둠
    3. eBPF 프로그램들이 load 될 때 미리 만들어둔 Map을 참조하도록 보장
• 효과 : 불필요한 복제를 차단하고 eBPF 프로그램들이 같은 데이터 저장소를 참조

NETEDIT CONTROLPLANE

1. 어떤 서비스 및 트래픽 흐름에 튜닝 정책을 매칭하는 작업
2. 가시성 확보를 위한 측정 도구 활성화

Policy Store

각 튜닝 기능을 선택적으로 활성화하는 정책들의 저장소

Policy

• Classifier : 정책이 적용될 로컬 및 원격 엔드 포인트
  • 로컬 엔드포인트 : 제어 대상을 고정된 서버나 IP 단위가 아닌, 특정 애플리케이션이나 마이크로서비스를 수행하는 논리적 ‘작업(Job)’의 묶음으로 추상화하여 정의
    • 예시) 결제 승인’ 로직을 담당하는 50개의 컨테이너가 데이터센터 내 수십 대의 물리 서버에 무작위로 분산되어 실행 중이며, 수시로 생성 및 소멸하여 IP 주소가 계속 변경
      • IP 10.0.0.1 ~ 10.0.0.50에 보안 정책 적용”이라고 설정할 경우, IP가 변경될 때마다 정책을 새로 수정하고 배포해야 하는 극심한 관리 오버헤드가 발생
      • 결제 승인 작업을 수행하는 모든 컨테이너 프로세스의 집합 자체를 로컬 엔드포인트로 선언. IP와 상관 없이 정책이 주입
  • 원격 엔드포인트 : 목적지를 특정 서브넷이나 IP 대역으로 하드코딩하지 않고, ‘동일한 서버 랙(Rack)’, ‘동일한 데이터센터’, ‘동일한 대륙’과 같이 출발지 대비 네트워크 토폴로지 상의 상대적인 위치 및 거리로 지정
• Config : 튜닝 기능의 인수 및 매개 변수를 지정하는 필드. Key-value 형태로 저장되어 각기 다른 튜닝 프로그램들이 요구하는 파라미터의 형태나 개수가 달라도 유연하게 저장하고 주입 가능함
• Disable list : local source endpoint에 적용되는 matcher. 정책을 비활성화하게 해주는 블랙리스트
  • 디버깅 시 문제와 관련 없는 정책을 배제하여 용이함.
  • 장애가 발생했을 때 해당 정책 자체를 바꾸면 해당 정책이 적용된 다른 서버에서도 문제가 발생할 수 있음. 또 수정된 정책을 원래 상태로 되돌리는 과정에서 상태 불일치가 발생할 수 있음. 원본 정책을 보존한 상태에서 특정 엔드포인트에서만 예외를 선언하여 테스트 범위를 좁게 설정할 수 있으며 안전하게 복구 가능

PolicyEngine

Design : 트래픽 제어 시 현재 지연 시간을 동적으로 반영하는 방식은 이론적으로는 최적의 성능을 낼 수 있지만 거대한 분산 환경에서는 실시간 변화가 시스템의 예측성을 떨어뜨려 장애 발생시 원인 파악을 불가능하게 만듬

→ 관리자가 설계한 토폴로지에 기반하여 eBPF 프로그램을 켜고 끄는 정적이고 안정적인 방식 사

• 계층적 주소 할당을 통해 대략적인 위치성과 어느 정도의 하드웨어 특성을 추론 가능하게 함
  • 예를 들어, 클러스터 주소는 특정 접두사 내에 그룹화하고 랙의 주소는 하위 접두사로 할당

핵심 모듈

• ScopeResolver : 저수준의 데이터인 IP 주소 접두사을 입력받아 고수준의 논리적 정보인 같은 랙, 데이터 센터, 다른 대륙 등 상대적 거리 개념으로 변환
  • 이런 간결한 상대적 거리 표현은 인접한 레플리카 선택에 유용
    • 인접한 레플리카 : 트래픽 지연을 최소화 하기 위해 물리적으로 가장 가까운 복제 서버
• InfraResolver : 서버를 관리하는 컨테이너 오케스트레이터와 직접 통신하여, 현재 서버에서 어떤 작업(Job/Service)이 실제로 실행 중인지, 그 작업이 어떤 IP를 쓰고 있는지 실시간으로 추적
  • 기존에는 새로운 컨테이너가 처음 deploy 될 때에만 eBPF 정책을 밀어 넣었는 데 NetEdit은 끊임 없이 활성화된 서비스를 추적하여 오래된 컨테이너에도 새로운 서비스가 활성화되면 eBPF 프로그램을 동적으로 load/unload 가능

The Initializer

목적

• 튜닝 기능이 결정론적 순서로 적용
  • 일관된 동작을 유지하고 프로그램 실행 순서로 인해 발생할 수 있는 잠재적인 버그를 완화하는 데 도움
• 튜닝 기능 간의 종속성 충족
• 정상적인 재시작, 충돌 후 재시작, 초기 시작 같은 시스템 상태 동안 진행 중인 연결에 정책 적용

1. 프로그램의 detaching을 unpinning하여 이전 인스턴스 정리
2. 새로운 튜닝 기능 load하고 pinning
   • bpf-iter를 사용하여 eBPF 프로그램에 특정 정책 적용
   • 재시작 동안 flow들도 분류 가능

MetricExporter 및 Auditor

MetricExporter

• 커널에서 eBPF 프로그램이 작업을 할 때마다 eBPF Map에 성공 실패 여부를 카운터 형태로 기록
• 이 숫자는 단순한 배열 형태이므로 사용자 공간에서 MetricExporter이 데이터를 주기적으로 읽어와(Polling)하여 해석하고 변환
• NetEdit이 재시작하는 동안에도 수집해야 하므로 NetEdit과 분리
  • NetEdit은 새로운 네트워크 튜닝 기능을 추가했다면, “새로운 BPF 맵이 생성되었으니 여기 데이터를 수집하라”는 메타데이터를 MetricExporter 측에 전달

Auditor

• 목적 : eBPF 정책이 실제로 적용되어 원하는 대로 제어됐는 지 확인
• ‘FBFlow 프레임워크 : 트래픽 전체를 감시하는 것은 불가능 하기에 프레임워크를 사용하여 패킷 샘플링
  • 패킷 헤더 뿐만 아니라 양 서버의 애플리케이션 정보와 OS 내부의 구체적인 연결 상태(MSS, window 등)을 묶어서 수집하여 정책이 잘 적용됐는 지 확인
  • 오버헤드 문제
    • FBFlow의 BPF 내에 이러한 필드를 기록하는 것은 간단
    • MSS 값, 윈도우 크기 같은 필드들은 단순하고 규칙적인 정수이므로 압축 알고리즘을 거칠 때 용량이 크게 줄어드는 저엔트로피 특성이 있음
• MetricExporter : eBPF 코드 자체가 시스템 내부에서 런타임 에러나 충돌 없이 정상적으로 작동했는지를 판단.
• Auditor : 정상적으로 실행된 eBPF 코드가 대상 트래픽을 올바른 규칙에 따라 변환됐는지를 검증.

Application

Diversity

• 2개 제외하고 Transport 계층에서 동작
  • 이유 : 선행 연구들 보면 전송 계층 최적화를 통해 성능 향상이 많이 일어남
• 튜닝 기능의 다양성 : 전송 계층 내에서도 다양한 훅 포인트에 부착
  • 1 ~ 5 : 기존 커널 통신 규칙을 쓰지만 매개변수를 동적으로 설정
  • 6 ~ 8 : 완전히 새로운 혼잡 제어 알고리즘을 작성
    • 커널 모듈이 아닌 eBPF 프로그램으로 작성. 이는
      • eBPF 이점
        • 리눅스 커널 네트워킹 스택의 코드를 직접 수정하고 재컴파일해야 하는 고위험 과정을 생략
        • 런타임 동적 loading하는 특성이 새로운 알고리즘의 실험, 테스트, 배포에서 유연성과 속도를 제공.
        • 물리적인 커널 패치 과정을 배제함으로써 단일 튜닝 기능 개발 및 안정화에 소모되는 시간과 연구 인력을 절감

TuningFeature Building Blocks

• 각각의 튜닝 기능을 밑바닥부터 새로 개발하는 것이 아니라, 프레임워크 내에 미리 구축된 기능 모듈(빌딩 블록)들을 레고 블록처럼 조립하고 재사용하는 구조로 유연성과 강력함을 줌
• 빌딩 블록의 분류
  • Core 기능 : 모든 튜닝 기능에서 사용하는 소규모 기능 그룹
    • BPFAdapter : eBPF 코드를 시스템에 쉽게 연결해 주는 추상화 인터페이스
    • MetricsExporter : 작동 상태를 수치화하여 모니터링하는 도구
    • A/B 테스트 환경 : 안전하게 실제 서버에 코드를 올려보는 환
  • Transport 기능 : Transport 프로토콜의 다양한 측면을 튜닝하는 데 필요한 공통 기능
    • ScopeResolver는 RTT 및 위치를 기반으로 연결 분류를 가능하게 하여 데이터 전송 속도를 제어하는 다수의 튜닝 기능이 이 모듈을 공통으로 호출
  • 신흥(emerging) 기능
    • SharedMaps : 서로 다른 튜닝 기능들끼리 데이터를 주고받을 수 있게 하는 공유 메모리 기능
    • WarmReboots : 프레임워크 자체를 업데이트할 때 네트워크 패킷의 유실을 방지하는 무중단 재부팅 기능

Developer Productivity Improvement

Transport 튜닝 기능에 초점을 맞춰서 세 가지 튜닝 기능를 기준으로, 기존 개발 방식과 NetEdit 도입 이후의 소요 시간을 정량화하여 비교. 6개월 → 몇 주 수준으로 감소

• 이유
  • 단순한 추상화 및 런타임 프레임워크 도입 : 개발자가 복잡하고 위험한 커널 코드나 Low-level 시스템 제어 방식을 조작하지 않고 인터페이스를 통해 개발
  • 공통 유틸리티의 재사용 : 트래픽을 식별하거나 연결 범위를 지정하는 도구(Scope Resolver)처럼 모든 튜닝 기능에 공통으로 요구되는 부가적인 코드를 매번 새로 작성할 필요가 없어 핵심 비즈니스 로직에 집중
  • 자동화된 테스트 및 배포 매커니즘 : 배포의 신뢰성을 높이고 더 빠른 배포를 보장

Design Lessons For Hookpoint Selection

• Control-Overhead Tradeoff : 훅 포인트가 Low-level이면 모든 패킷을 세밀하게 제어할 수 있지만 오버헤드가 커짐. 통신 연결이 맺어지거나 설정이 변경될 때만 실행되는 high-level에 훅 포인트를 설정하면 CPU 부하는 줄어들지만 통제할 수 있는 권한이 제한
• 성공 사례
  • BET-tuner : 스캐빈저(scavenger) 혼잡 제어 구현을 제공.
    • 초기에는 네트워크 상태를 지속적으로 확인하기 위해 빈번하게 확인하기 위해 sockops에 부착되며 QoS 변경을 감지하기 위해 RTT 콜백에 의존
      • 기존의 동작 흐름
        1. 연결 수립 시 eBPF sockops 프로그램을 호출
        2. eBPF 프로그램이 해당 소켓에 대해 RTT 변경시 콜백 이벤트가 발생하도록 설정
        3. ACK 수신 시 마다 RTT 다시 계산. eBPF 프로그램을 반복적으로 호출
        4. eBPF 프로그램이 지연 시간, 대역폭 상태등을 평가한 후 bpf_setsockopt 헬퍼 함수를 호출하여 소켓의 혼잡 제어 알고리즘이나 관련 파라미터를 변경
        5. 3-4 반복
    • 사전 대응적인 socksetopts로 변경하여 수정될 때만 트리거 되어 최대 200배 호출이 감소
      • 동작 흐름
        1. 사용자 공간의 애플리케이션이 QoS를 낮추거나 설정을 변경하기 위해 setsockopt() 시스템 콜을 호출
        2. eBPF socksetopts 프로그램 트리거
        3. eBPF 프로그램이 요청된 옵션을 분석하고, 특정 조건(예: 백그라운드 트래픽)을 만족할 경우 소켓의 혼잡 제어 알고리즘을 스캐빈저(Scavenger) 알고리즘으로 변경
  • 배경 지식
    • scavenger 혼잡 제어 : 대역폭 중 잉여 대역폭만을 활용하여 기본 트래픽의 성능에 영향을 끼치지 않는 혼잡 제어 알고리즘. 대역폭 경합이 발생할 경우 즉시 전송률을 낮춤
    • sockops: 소켓 수준의 이벤트. TCP 상태 변화 및 주요 이벤트(TCP 연결 수립 및 종료, 상태 전환, 재전송 타임아웃) 발생시 eBPF 프로그램이 호출.
    • RTT 콜백 : RTT 값이 계산되거나 갱신될 대마다 호출하도록 정의된 함수.
      • sockops 환경에서는 패킷에 대한 ACK을 수신하고 RTT를 산출하는 매시점마다 콜백
    • socksetopts 응용 프로그램이 소켓의 구성을 변경할 때 사용하는 시스템 콜을 호출할 때 eBPF 프로그램을 실행시키는 훅포인트
• 실패 사례 : RWND 크기를 조작하는 과정
  • 기존에는 TC 훅 포인트를 통해 모든 개별 패킷에 대해 eBPF 프로그램을 실행하여 패킷마다 RWND를 재작성 → CPU 오버헤드 발생
  • sockops로 전환 (연결 수립, 상태 변경 등)에서만 트리거
    • sockops 트리거로 eBPF 프로그램이 실행되어 RWND를 작성해도 그 이후에 tcp_select_window()와 같은 커널 내부 함수를 통해 RWND 값을 재작성.
    • 이를 막으려면 커널의 핵심 TCP 소스 코드를 수정해야 하는 데 커널 코드 수정 없이 안전하게 기능을 확장하려는 eBPF의 존재 의미를 부정
    • TC(Traffic Control) 훅 포인트는 패킷이 완성되어 네트워크 카드(NIC)로 내려가기 직전(qdisc)에 위치하기 때문에 tcp_select_window() 후에 덮어씌울 수 밖에 없음
• 교훈
  1. 요구되는 정확성을 만족하고 필요한 동작을 제공하는 지
  2. 성능 오버헤드를 측정
  3. eBPF 인터페이스가 의존할 수 있는 커널 내부 기능에 대한 이해가 필요
     • 1번은 공식 문서가 있고 2번은 관측 도구가 존재하지만 커널 내부 영향은 메뉴얼이 없기 때문에 깊이 이해해야 함

Evaluation

Deployment Characterization

• 인프라 배포 현황 : 데이터 센터 서버의 약 98.4%에 NetEdit이 설치됨.
  • 특정 커널 패치에 따른 버전 제약으로 인해 100% 배포에는 도달하지 못함.
• 튜닝 기능 분류
  • 전체 적용 그룹 (100%): NetEdit이 활성화된 모든 서버에서 사용되는 필수 전송 기능 (예: InitCWND, BET).
  • 카나리(Canary) 검증 그룹 (10%): 새로운 NetEdit 기본 요소를 테스트하기 위해 소규모 서버에만 활성화되는 단일 특수 기능 (Touchstone)
  • 특수 목적 그룹 (2% 미만): 특정 서비스 요구사항에 맞춰 극소수의 서버에만 제한적으로 배포되는 틈새 기능 (예: MSS Tuner).

Performance Benefits of tuningFeatures

• NetEdit 활성화에 따른 성능 이점
  • 지연 시간 개선: 혼잡 제어 알고리즘, 윈도우 크기, 패킷 크기 조정을 통해 스토리지 및 광고 서비스 등의 꼬리 지연 시간(Tail latency) 최적화.
  • 인프라 효율성 극대화: 네트워크 버스트 병목 없이 특정 스토리지 서버의 적재량(Load)을 2배 증가시킴. 우선순위가 낮은 리전 간 트래픽을 강등 처리하여 대규모 비용 절감 달성.
  • 운영 안정성: 네트워크 패킷 재전송의 유의미한 감소를 통해 자원 활용도를 높이고, 운영 경고(Alarm) 노이즈를 줄여 문제 해결(Troubleshooting) 효율성 증대.
• NetEdit 비활성화 시 발생하는 계층별 성능 저하
  • 서비스 계층 (Service Layer):
    • ML 추론 : 평균 QPS(초당 쿼리 수) 29% 하락, 99분위(Tail) 지표에서 59.21% 급감.
    • 스토리지 : 평균 블록 읽기 성능 37.14% 악화, 99분위 지표에서 65.85%의 치명적 성능 하락.
  • 호스트 계층
    • 전체 트래픽 재전송 발생 4.5배 증가.
    • 타임아웃(Timeout)으로 촉발된 치명적 재전송 29배 폭등.
    • 업/다운링크 처리량(Throughput) 10% 감소.
  • 네트워크 계층
    • 데이터 센터의 ToR(Top-of-Rack) 스위치 다운링크에서 혼잡으로 인한 패킷 폐기(Congestion discards)가 363.7% 폭증.

Overhead

• Control Plane
  • 자원 점유율: CPU 평균 0.00023% (95백분위수 0.00026%), 메모리 평균 26MB (95백분위수 60.5MB)
  • 특징: 생명주기 관리 지원을 위한 최소한의 기능만을 제공하도록 설계되어 사용자 공간(userspace)에서 극도로 낮은 리소스 오버헤드를 유지함.
• Data Plane
  • 풋프린트 최소화: 대규모 프로덕션 환경의 제약에 맞추어 eBPF 프로그램의 리소스 소모를 의도적으로 경량화.
    • 풋 프린트 : 하드웨어나 소프트웨어가 실제로 운영되는 과정에서 점유하는 자원의 총량 (물리적 공간, 전기, 메모리 공간, 디스크 공간, CPU 등등)
  • 최적화 기법: Shared maps 및 Lazy loading을 적용하여 맵을 재사용하고 중복 기능을 방지하며, 매칭되는 정책이 존재할 때까지 로딩을 연기하여 CPU 및 메모리 점유를 명시적으로 감소시킴.
• Lazy Loading 비용 절감 효과
  • 효율성 증명: 요구되는 eBPF 프로그램만 시스템에 Attach하는 지연 로딩 기술의 성능 이점을 교차 검증함.
  • 성능 지표: 10개 데이터 센터에 걸친 실험 결과, 지연 로딩이 적용된 eBPF 프로그램은 미적용 프로그램 대비 평균 14% (99백분위수 기준 27%)의 CPU만을 소비하여 괄목할 만한 자원 절감 효과를 달성함.

EXPERIENCES,OUTAGES,ANDOPEN

SOURCE

Deployment Experiences

대규모 프로덕션 환경에서의 eBPF 프로그램 배포 경험

• 문제 상황
  • 검증기가 커널 충돌 방지를 보장해도 기저 커널 인터페이스의 버그를 유발하여 대규모 프로덕션 장애를 일으킬 수 있음
    • 기저 커널 인터페이스의 버그 : logic error, race condition 같은 현상
    • 마이크로서비스 테스트 통합하고자 함
      • eBPF와 커널의 강한 결합으로 기존 마이크로서비스 테스트 방법론(A/B 테스트, cgroups 기반 가상화 격리)을 재사용할 수 없음
  • BPP-TCP-CCA와 같은 특정 커널 계층에서는 동일한 이름의 eBPF 프로그램에 대한 다중 인스턴스 격리를 지원하지 않아 충돌이 발생함
• 해결 방안
  • 단위 테스트
    1. 프로그램이 실제로 로드되는 지 확인. packetdrill을 이용하여 가짜 패킷을 쏘아보며 시뮬레이션. 카운터 및 연결 매개변수 같은 eBPF 측정값 분석을 통해 로드 및 동작의 유효성을 1차 검증함.
    2. 다양한 프로덕션 작업 부하와 함께 프로덕션 환경에서 단위 테스트.
       • 기존 방식 : cgroups와 같은 가상화 기술을 통해 동일한 마이크로 서비스의 여러 인스턴스를 격리
         • 이유
           • 동일한 서비스에서 안정된 기존 버전과 신규 버전을 동시에 실행하면서 비교 검증이 가능
           • 격리를 해놓으면 크래시, 무한 루프 등이 발생해도 호스트 전체로 전파되는 것을 차단
             • 예를 들어 무한루프에 빠져 해당 CPU 점유율을 독점하려고 시도하지만 해당 인스턴스에 할당된 사용량이 정의되어 있어 호스트 전체에 영향을 받지 않음
           • 물리적으로 구축하는 것 보다 오버헤드가 최소화
         • 한계 : 동일한 eBPF 프로그램의 여러 인스턴스에 대한 격리 및 가상화를 지원하지 않음
           • 예시 : BPF-TCP-CCA 부착 지점에서는 동일한 이름을 가진 여러 eBPF 프로그램을 지원하지 않음 (TC, XDP는 지원)
       • 해결 방안
         • 동일한 호스트에서 테스트용과 운영용 eBPF 프로그램을 격리하기 위해 더미 cgroups을 사용
           • 프로세스 그룹 단위로 실행 범위를 제한하여 운영 트래픽이 유입되지 않는 더미 그룹을 만듦
           • 테스트용 eBPF는 이 더미 그룹에만 attach
         • 격리가 불가능한 훅 포인트의 경우에는 로드 시 운영 버전과의 충돌을 피하기 위해 테스트용 eBPF 프로그램의 이름을 재작성(Rewrite)하는 것이 포함
           • 커널 global 메커니즘을 변경하여 그룹 단위 분할이 불가능
           • 커널은 메모리에 로드되는 eBPF 프로그램을 ‘이름’으로 식별. 운영 버전과 테스트 버전이 동일한 이름을 가지면 커널이 중복 등록을 거부
           • eBPF 프로그램을 커널에 로드하기 직전, 내부 식별자 이름을 강제로 변환(예: bbr → bbr_test)하여 병렬 테스트 수행 가능

→ 제안된 동적 프로그램 변경 및 격리 메커니즘을 통해 시스템 수정 없이 기존 NetEdit의 A/B 테스트 인프라를 온전히 활용. 프로덕션 워크로드와 병렬로 안전한 eBPF 테스트를 수행하는 환경을 구축

Production Outages

Failure Classification

• 커널/인프라 버그
  1. 커널-eBPF 인터페이스 버그 : 예상치 못한 코드 실행 흐름(예: 무한 반복 호출)이 발생하면, 커널이 오작동하여 메모리가 고갈되고 시스템이 멈추는 현상
  2. 커널 이식성 버그 : 운영체제(리눅스 커널)의 버전에 따라 eBPF를 지원하는 방식이 달라 생기는 문제. 동일한 프로그램을 실행하더라도 어떤 버전에서는 정상 작동하고, 어떤 버전에서는 시스템 전체가 다운(커널 패닉)되는 현상
  3. 기능 간 상호작용 버그 : 동일한 실행 지점(훅 포인트)에 여러 개의 eBPF 프로그램이 동시에 연결될 때 발생합니다. 프로그램 A에서 발생한 사소한 오류가 프로그램 B의 실행 자체를 가로막아 연쇄적인 장애를 일으키는 현상
• 기타 인프라 종속성 : eBPF 프로그램 자체가 아니라, 이를 구동하는 주변 환경(자동화 스크립트, 기존 설정, 트래픽 형태 등)의 변화나 설정 오류로 인해 발생하는 문제
  • 자동화 스크립트의 오류로 인해 pinned objects를 위한 eBPF 파일 시스템(/sys/fs/bpf)이 이중 마운트되어, NetEdit의 초기화 프로그램이 새로운 객체를 연결하려고 할 때 이전 객체가 여전히 연결되어 있어 이전 객체의 고정을 해제(unpin)할 수 없게 되는 버그

Lessons & Future Work

• 통합 테스트 도입: 개별 기능 검사(유닛 테스트)와 실제 환경 테스트(A/B 테스트) 사이에, 여러 기능이 동시에 동작할 때 서로 충돌하지 않는지 확인하는 단계를 추가. 이때 실제 사용자 데이터를 복제한 가짜 데이터(섀도 트래픽)를 활용합니다.
• 추가 연구
  • 퍼징(Fuzzing) 기반 테스트: 시스템에 무작위 데이터를 대량으로 주입하여, 평소에는 발견하기 힘든 깊은 곳의 커널 버그를 강제로 끄집어내는 강력한 테스트 도구가 필요.
  • 동적 계측(Dynamic Instrumentation): 프로그램들이 서로 어떻게 영향을 미치는지 실시간으로 추적하고 자동으로 기록(로그)을 남길 수 있는 정밀한 분석 도구가 필요.

Opensource and Community Engagement

NetEdit의 데이터 평면 구성 요소를 리눅스 커널에 공식 통합(Upstream)하고 오픈소스에 기여

커널 기능 노출 확대 (Exposing more functionality)

• 커널 함수 포인터를 통해 eBPF 내에서 TCP 혼잡 제어 알고리즘(CCA)을 구현할 수 있도록 struct_ops 인터페이스를 도입.
• kfunc(커널 동작 재정의 및 조정) 인터페이스와 bpf_link(원자적 업그레이드 지원)를 추가하여 커널 기능을 확장.

→ 커널 우회(Kernel bypass) 기법을 사용하거나 커널 공식 배포 일정에 종속되지 않고도, CCA를 독립적인 기능으로 취급하여 유연하고 반복적인 개발이 가능.

커널 프리미티브 구조 개선 (Improve kernel primitives)

• 커널 내 코드 중복을 방지하면서 NetEdit의 eBPF 프로그램이 사용자 공간 애플리케이션과 동등한 네트워크 스택 제어 권한을 가질 수 있도록 bpf_setsockopt() 헬퍼 함수를 리팩토링
• 네트워크 정책의 소급 적용을 지원하기 위해 bpf-tcp-iter에 bpf_setsockopt 기능을 추가하였으며, 이를 통해 대역 외(out-of-band) 방식으로 기존 TCP 파라미터를 업데이트할 수 있는 새로운 메커니즘을 구현.